SH.Consulting
Insights

Insights

AX・AIエージェント・ハーネスエンジニアリングに関する視点。LinkedIn 投稿の拡張版・正本を保管しています。

2026-06-15

AXは誰が作れば成功するのか

AX(AI変革)は、外部の開発者ではなく、その業務を毎日こなす現場の人の手で作られたときに成功します。ワークフローに潜む例外や暗黙のルールは、毎日それを回している人にしか分からないからです。だからAX教育の本質は、開発者を増やすことではなく、現場の人がバイブコーディングで自分の仕事を自ら自動化できるようにすることです。財務・経営管理の担当者が毎日の発注業務を自動化した事例が、それを示しています。

続きを読む →
2026-06-14

日常の自動化はなぜAXの最良の出発点なのか

自分が毎日繰り返す小さな仕事を一つ、丸ごと——部分的にではなく——なくしてみることが、AX(AI変革)の最良の出発点です。効率を数パーセント上げるのではなく、その仕事を自分の手から完全に切り離す経験をすると、AIが何を代替でき、どこまで信じて任せられるかを身をもって知るからです。散らばったカカオトークの予定をAIが拾い、カレンダーに登録し、毎朝一枚のブリーフィングにして届ける個人の自動化がその例です。

続きを読む →
2026-06-13

AIの成果物はなぜMarkdownではなくHTMLで受け取るべきか

完成した成果物であれば、MarkdownではなくHTMLで受け取るほうが理解速度が大きく上がります。AIが文書を作る速度はすでに人が読む速度を追い越しており、100行を超えるMarkdownは事実上読まれないからです。AnthropicのClaude Codeエンジニアも「HTMLは新しいMarkdownだ」と述べ、成果物をHTMLで受け取り始めました。動的な画面が必要ならPlaygroundプラグインがその隙間を埋めます。基準はシンプルです。構造を見て理解すべき完成物はHTML、中間生成物はテキストのままにします。

続きを読む →
2026-06-13

AIコーディングの生産性を分けるのはモデルかワークフローか

AI支援によるコーディングの成果物の質は、モデル選びよりワークフローが大きく左右します。本当のボトルネックは弱いモデルではなく、曖昧な仕様とやり残した作業だからです。oh-my-claudecode(OMC)はClaude Codeの上で三つの習慣を道具として固めたオーケストレーション層です。deep-interviewが何を作るかを明確にし、ralplanがどう作るかを検証し、ralphが最後までやり切ることを保証します。"何を・どう・最後まで"を強制されたパイプラインに変えるのが要点です。

続きを読む →
2026-06-12

コールセンターはコスト部門か、新規事業の源泉か

コールセンターはコスト部門としてだけ見る場所ではなく、新しいサービスや事業を発掘する源泉になり得ます。日々寄せられる問い合わせには未充足ニーズの手がかりがすでに含まれており、STT と LLM ウィキで対応記録を資産化すれば、その手がかりを体系的に掘り出せます。残る関門は個人情報のマスキングであり、それを解けばコールセンターはコスト部門から事業発掘エンジンへと変わります。

続きを読む →
2026-06-11

AIがコードを書く時代に、なぜフロントエンドの知識が必要なのか

フロントエンドの知識とは、AIに任せられる仕事のレベルを決める地図です。React、npm、ビルド、SSRといった言葉は暗記の対象ではなく問題解決の連鎖であり、それぞれの技術がどんな問題を解くために生まれたのかを知れば、指示の言葉が変わり、同じAIを使っても成果物が分かれます。バイブコーディング教育でツールの使い方より技術の進化の過程を先に扱うべき理由がここにあります。

続きを読む →
2026-06-11

バックエンドとは何か:1993年のゲストブックから始まった問題解決の系譜

バックエンドとは、サーバーがリクエストを受け取り、データを処理して結果を返す領域であり、1993年にゲストブックの問題を解く中で生まれました。事前に作っておいたHTMLファイルでは、訪問者が残したばかりの書き込みを次の人に見せられないため、サーバーがリクエストのたびにその場でページを組み立て始めたのが出発点です。その後30年の発展史も同じパターンの繰り返しです。問題が生じれば、それを解く技術が登場する。この系譜を知れば、非開発者もAIにバックエンドを具体的に指示できるようになります。

続きを読む →
2026-06-11

バイブコーディングでAIはなぜSupabaseばかり勧めるのか

バイブコーディング中にAIがSupabaseを頻繁に勧めるのは、もともと別々に発展してきたデータベースとストレージという二つの技術の流れが、このプラットフォーム一つに合流したからです。SupabaseはFirebase並みの手軽さの上に本格的なPostgreSQLを載せ、認証とストレージまで束ねたオープンソースのプラットフォームで、別々にセットアップして別々につないでいたものが、最初からつながった状態で手に入ります。この系譜が頭にあると、AIへの指示のレベルが変わります。

続きを読む →
2026-06-11

デプロイとは何か——localhostはなぜ友人のパソコンで開けないのか

デプロイとは、自分のパソコンにしかないコードをサーバーに載せ、インターネット上の誰もが使えるようにする過程です。バイブコーディングの成果物がlocalhost:3000でしか動かない理由、FTPからGit・Docker・CI/CDへと続いたデプロイの進化、Vercelのようなプラットフォームが代行してくれることとその代償を整理しました。この地図が頭にあればAIへ投げる質問が変わり、その具体性が非開発者バイブコーディングの実力を分けます。

続きを読む →
2026-06-11

AIはなぜルールではなく確率を出すのか

今のAIは、人間が書いたルールを実行する機械ではなく、データから自ら見つけたパターンをもとに「スパムである確率93%」のような確率を出力する機械です。送金のように条件が明確な問題はルールベースのコードで完璧に解けますが、画像認識のように例外が多く境界が曖昧な問題ではルールが崩れるからです。機械学習とディープラーニングはルールベースシステムのこの失敗から生まれ、この区別はAXコンサルティングで業務を分解する最初の基準になります。

続きを読む →
2026-06-11

ChatGPTはなぜ会話を記憶しないのか

ChatGPTをはじめとするLLMは会話を記憶しません。毎ターン、それまでの対話全体を再送信すると、モデルはその塊を初めて見るテキストのように読み、次のトークンを予測するだけです。会話が長くなるほどコンテキストウィンドウが埋まり、コストが膨らむ理由がここにあります。トークナイザーの韓国語非効率からハルシネーション、temperature、システムプロンプトまで、すべて数行のコードで画面上に直接確認できます。

続きを読む →
2026-06-11

AIオーケストレーションとは何か:RAGチャットボットが止まる地点から始まる設計

AIオーケストレーションとは、質問を受けて検索し答えるだけの一直線のパイプラインではなく、行き詰まったら引き返すループと状況に応じて道を変える分岐を設計し、AIに複雑な実務を処理させる制御フロー設計です。LangChainが標準部品を、LangGraphが制御フローを、LangSmithが可観測性を担い、三つが揃って初めて一つのシステムになります。ただしAPI一回で済む仕事に使うのは無駄で、ループと分岐が必要なほど仕事が複雑なときに取り出す道具です。

続きを読む →
2026-06-10

ハーネスエンジニアリングとは何か

ハーネスエンジニアリング(Harness Engineering)とは、AIモデル自体を変えるのではなく、モデルにどのツールを持たせ、どんなルールとワークフローの中で動かすかを設計して成果物の品質を引き上げる作業です。同じモデルでもハーネス設計次第で性能が大きく変わるため、より高価なモデルに乗り換える前に、まず点検すべきレイヤーです。

続きを読む →
2026-06-10

AIネイティブとAIアシストの違い — 自社はどちらか

AIネイティブ(AI Native)は、人の介入がほぼないままワークフロー全体がAIで完結する構造。AIアシスト(AI Assisted)は、人の仕事はそのままにAIが横から一部を手伝う構造です。多くの企業の「AIネイティブ宣言」は実際にはAIアシストに留まっており、この違いを区別できなければ、AI導入後も生産性は横ばいのままです。

続きを読む →
2026-06-10

AXプロジェクトはなぜ失敗するのか — チームを助けるな、業務をなくせ

AX(AI Transformation)プロジェクトの最も典型的な失敗パターンは、AXチームが各部署を回って要件を集め、ツールを作って渡す方式です。作っても現場が使わないからです。成功するAXの出発点は「あのチームを助けてください」ではなく「あのチームの業務単位を丸ごとなくしてください」であり、人は切るのではなく新しい職務へ転換させるのです。

続きを読む →
2026-06-10

生成UIとMCPアプリ — エージェント時代のインターフェースはどこへ向かうのか

エージェントUIは、静的(事前構築コンポーネントにデータを流し込む)、宣言的(エージェントがJSON記述を書き、レンダリングエンジンがデザインシステムにマッピング)、生成的(モデルがランタイムでHTML・CSSを即席生成)の3段階で進化しています。現在の均衡点は宣言的方式であり、生成的へ進む鍵はモデルの能力ではなく信頼 — すなわちサンドボックスという安全な流通構造です。MCPアプリがその配布チャネルとして注目されています。

続きを読む →
2026-06-10

K Public Data MCPとは何か — 韓国の公共データをAIにつなぐサーバー

K Public Data MCPは、法制処国家法令情報センター、DART電子公示システム、公共データポータルなど、バラバラに散らばった韓国の公共データAPIをMCP(Model Context Protocol)サーバー一つに統合し、AIチャットで「民法を検索して」「サムスン電子の財務諸表を見せて」「江南区の薬局を探して」がそのまま動くようにするオープンソースのツールです。コネクタURLを登録するだけで使え、APIキーの発行もインストールも不要です。

続きを読む →