大企業3社、AIエージェント普及の壁はモデルでなく基盤に

LinkedIn、Walmart、Zendesk——規模も業種も異なる3社が、それぞれ独自にAIエージェントの本番運用に取り組んだ結果、同じ結論に行き着いた。問題はAIモデルの性能ではなく、その下で動くシステム基盤にある、というものだ。この知見は、2026年のカンファレンス「VB Transform 2026」でのパネルディスカッションで共有された。

そもそも企業向けシステムの多くは、人間が操作することを前提に設計されてきた。人間がクリックし、承認し、作業を進める速度に合わせて動けば十分だったからだ。ところがAIエージェントは、人間では到底追いつけないミリ秒単位で処理を進める。この「スピードの根本的なずれ」が、本番環境でさまざまな障害を引き起こした。各社が直面したのは、まさにこのギャップだった。

LinkedInでは、コンテナ管理システムの「Kubernetes」が最初の壁になった。コンテナを必要なときに起動する従来の方式では数秒かかり、エージェントの処理速度に対して遅すぎた。そのため、あらかじめコンテナを用意しておく「事前プール方式」に切り替え、処理をリアルタイムで入れ替えられる仕組みを構築した。さらに難題として浮上したのが、エージェントの制御方法だ。AIが別のAIの出力を評価する構造では、評価する側も同じ失敗をしやすいという欠点があった。LinkedInはこれに対し、ワークフローの約80%を決定論的なスクリプトで処理し、AIによる推論が必要な場面だけに限定する設計へと転換した。

Walmartが直面した課題は、成功に伴う問題だった。社内向けにAIエージェントの開発環境を公開したところ、エンジニア以外の一般社員も独自にエージェントを作り始め、内部で急速に広まった。その結果、同じ目的を持つエージェントが多数重複して生まれ、管理が困難になった。対策として、重複を検出し優れたエージェントを選別して本番環境に昇格させる「ガバナンス」の仕組みを整備した。開発の自由度を制限するのではなく、無秩序に広がったエージェントを整理・統制するための体制を作ったのだ。

Zendesk出身のサミ・ゴーシュ氏は、同社による2026年3月のForethought買収を経て現職に就いている。同氏が指摘したボトルネックはデータ側にあった。大規模なデータ資産を持つことは強みになる一方で、どのデータをエージェントに参照させるかという設計が、実際の応答品質に直結する。データの設計や管理が後回しになると、AIの処理速度がいくら速くても結果の質が伴わないという現実を、同氏は実体験から説明した。

この3社の事例が示すのは、AIエージェントを「試してみる段階」から「実際に組織で使う段階」へと移行させるには、モデルの改良だけでは不十分だという点だ。コンテナの起動速度、評価ロジックの設計、ガバナンス体制、データ管理——こうした地味に見える基盤の問題が、エージェントの本番運用における実質的な制約になっている。

AI投資がモデル開発に集中しがちな中で、これらの事例は「基盤整備こそが普及の鍵」という見方を裏付けるものと言える。今後は、各社のエージェント活用がどこまで横展開できるか、そしてガバナンスや基盤の整備が業界全体でどう標準化されていくかが、注目すべき論点になるだろう。