何が起きたか
VB Transform 2026のセッションで、LinkedInのAnimesh Singh氏、WalmartのDesiree Gosby氏、ZendeskのSami Ghoche氏の3人が、AIエージェントをパイロットから本番へ移す際に「壊れた」ものを共有しました。3人が一致したのは、ボトルネックはいずれもモデルの問題ではなかったという点です。共通の前提は「企業インフラの多くは、エージェントの働き方ではなく人間の働き方に合わせて作られている」こと。この速度差を埋める作業こそがエンジニアリングの中心だった、という指摘です。
なぜ重要か
生成AIの議論はモデルの賢さに集中しがちですが、実際に本番運用を止めるのは足回りの基盤である、という現場の証言だからです。裏を返せば、最新モデルに乗り換えても基盤が旧来のままなら成果は出ないということでもあります。
三者三様のボトルネック
LinkedInが最初にぶつかったのはKubernetesでした。コンテナを都度起動する前提は数秒かかり、エージェントには遅すぎる。そこで都度プロビジョニングをやめ、事前確保したコンテナのプールにエージェントの処理をリアルタイムで出し入れする方式へ切り替えました。さらにエージェントに自律的なオーケストレーションを任せると、5段階の評価システムを設けてもハルシネーションが消えなかった。LLMが別のLLMの出力を評価しても同じ弱点を共有するためです。
そこでLinkedInは自前のハーネスと制御フローを構築し、「LLMをループの司令塔にせず、末端（leaf）に押し込む」設計に変えました。Singh氏は「独自のハーネスと制御フローを作り、LLMがループを回すのではなく末端へ押しやった」と述べています。現在はワークフローの約80%が決定論的なスクリプトで、推論が必要な箇所だけLLMを使い、各ステップの根拠を進行前にディスクへ記録します。
Walmartのボトルネックは「成功」から生まれました。従業員に直接配ったエージェントのハーネスが社内でバイラル化し、「市民開発者」が自作エージェントを乱立させ、調整のないまま数十の重複エージェントが生まれた。同社はガバナンスを構築し、重複を検知して最良版を選び、エンジニアリングを詰まらせずに本番投入する仕組みで対応しました。Gosby氏の狙いは「エンジニアリングを再びボトルネックにしないこと」です。
Zendeskはデータ側で詰まりました。Forethought(2026年3月に買収完了)や200億件の顧客対話を抱える同社のGhoche氏は、大きなコンテキストウィンドウを持つLLMに会話履歴をそのまま渡す方法は機能しないとし、「基盤となるデータパイプラインとデータ基盤にこそ投資しなければならない」と語りました。
モデル独立をどう作るか
3人はオープンソースについても一致しました。企業は自前で持てるものは持ち、フロンティア推論のようにラボに明確な優位が残る領域だけ頼ればよい——しかもGhoche氏によれば、その領域はAI活用全体に対して相対的に縮小している。LinkedInは独立性のため、外向きの全モデル呼び出しを通す単一インターフェース「AIゲートウェイ」と、モデル提供元に依存せずコンテキストを保持する「メモリ基盤」を構築しました。Walmartも自前の内部ゲートウェイで3種類のワークロード(完全な決定論型、計画・推論型、ハイブリッド)にまたがりベンダー非依存を保ち、コンプライアンス重視の処理は決定論型に留めています。
💼 事業会社視点：これは自社にどう効くか
日本企業にとって示唆は明快です。PoCで動いたエージェントが本番で止まる原因は、GPTの世代ではなく、人間業務前提で組んだ既存システムにある可能性が高い。ECやSaaS事業者は、まず自社のジョブ実行基盤(コンテナ起動やAPI設計)がエージェントの秒単位の要求に耐えるかを点検すべきです。受託開発企業にとっては、決定論スクリプト8割・LLM2割という設計思想が受注要件を変えます。「全部LLMに任せる」提案は品質と説明責任で不利になり、制御フローを握る実装力が差別化になります。経営者が今動くべきは3点——(1)評価(evals)への先行投資、(2)エージェントのハーネスを初日から自社保有、(3)モデルとコンテキストの独立性設計。特にWalmart型の「市民開発者による重複乱立」は、生成AIを現場開放した日本企業でも早晩起きます。禁止ではなくガバナンスで最良版を選ぶ運用を、拡大前に用意しておくことが実務上の分かれ目になります。