powered by TechFeed
表示モード
Deep Dive

AIエージェントの本当のコストはエージェントではなく「配管」にある — デモが動いても本番で失敗する企業が続出する理由

11月5日、Praveen Guntakaが「Companies Are Shopping for AI Agents. The Real Bill Is for the Plumbing.」と題した記事を公開した。この記事では、エンタープライズ向けAIエージェント導入における「見えないコスト」、すなわちインフラ整備と契約リスクの問題について詳しく論じている。

11月5日、Praveen Guntakaが「Companies Are Shopping for AI Agents. The Real Bill Is for the Plumbing.」と題した記事を公開した。この記事では、エンタープライズ向けAIエージェント導入における「見えないコスト」、すなわちインフラ整備と契約リスクの問題について詳しく論じている。


デモは動く。本番では動かない

エンタープライズ向けのソフトウェアピッチは今や決まった結末を迎える——「AIエージェントが自動で処理します」。伝票照合、チケットトリアージ、決算締め。デモは確かに見栄えがいい。だが、本番環境の数字はそうではない。

元記事によると、Gartnerは2025年6月、2027年末までにAIエージェントプロジェクトの40%以上がキャンセルされると予測した。理由はコストの膨張、ビジネス価値の不明確さ、リスク管理の甘さだ。同じく元記事が引用するGoogle Cloudの「2026 State of AI Infrastructure」レポート(1,400人以上のITリーダー対象)では、83%が「エージェント対応にはインフラのアップグレードが必要」と回答し、「ミッションクリティカルなエージェントをスタックが支えられる」と自信を持って言えるのは17%にとどまる。

問題はエージェント自体ではない。その下に敷かれた「配管(plumbing)」だ。そしてその配管が整備されていない企業が、本番投入後に失敗を重ねている——これが記事全体を貫く主張である。


チャットボットとエージェントの根本的な違い

チャットボットは「答える」。エージェントは「動く」。

レコードを引き出し、台帳を確認し、数十年前に導入されたシステム間でエントリを転記する。1つのプロンプトが数百のダウンストリーム呼び出しを引き起こすこともある。だが、ほとんどの業務システムは人間がスクリーンをクリックする前提で設計されている。

情報システム研究の世界には、この問題を整理する古典的な概念がある。ITインフラ柔軟性だ。1995年にNancy Duncanが情報システム論文で定式化し、2000年にTerry ByrdとDouglas Turnerがエンタープライズ研究においてさらに精緻化した以下の3軸は、LLM登場以前の議論でありながら、今のAIエージェントが要求するものをほぼそのまま記述している:

  • コネクティビティ:任意のコンポーネントが他と接続できるか
  • コンパチビリティ:コンポーネント間で情報が自由に移動できるか
  • モジュラリティ:一部を追加・変更・削除しても全体が壊れないか

この3軸のいずれかが欠けた状態でエージェントを本番投入すると、統合コストと障害対応コストが雪だるま式に膨らむ。デモ環境では表面化しなかった問題が、本番の複雑なシステム連携の中で一気に顕在化するのはこのためだ。


「借りている配管」のリスク

記事の中で最も実務的な示唆を含むのが、ベンダーモデルへの依存にまつわる2つの実例だ。著者のGuntaka自身が経験したケースとして紹介されている。

ケース1:バージョン廃止問題。あるチームがベンダーのLLMを使って業務指標を構築した。ベンダーがそのバージョンを廃止すると、チームはマイグレーションを余儀なくされた。新モデルの性能は上がったが、業務指標のアップグレードスケジュールがベンダー側に移ってしまった。さらに深刻な問題がある——スコアが変動したとき、それはビジネスが動いたのか、モデルが変わったのか判別できない。

ケース2:データ利用の盲点。ある組織がリサーチワークフローをAIベンダーにアウトソースしたところ、ベンダーが匿名化した入力データを自社エージェントの学習に利用していた。契約は事後的に書き直されたが、後の祭りだ。コネクティビティは双方向に機能する。

いずれのケースも、アーキテクチャ図上には存在しない弱点が、契約書の中に潜んでいた。デモ段階では見えず、本番稼働後に初めてコストとリスクとして顕在化するという構造が、ここでも共通している。


エージェント予算を承認する前の4つの問い

Guntakaは、次のエージェントパイロットを承認する前に経営層が確認すべき4点を提示している:

  1. エージェントはガバナンスされたインターフェース経由でデータにアクセスできるか? 「カスタムコネクタを作る」が答えなら、能力を買っているのではなく技術的負債を引き受けている。

  2. どこかのシステムが変更されたとき何が起きるか? ベンダーアップグレードやスキーマ変更でエージェントが壊れるなら、そのアーキテクチャはモジュラーではなく、コストはエージェントが触るシステムの数に比例して膨らむ。

  3. エージェントの行動を誰が確認し、誰が取り消せるか? 金融・医療では監査証跡は任意ではない。規制当局は必ず問う。

  4. モデルを誰がコントロールし、データはどこへ行くか? モデル廃止前の事前通知、新旧バージョン比較の猶予期間、データ利用条件の事前合意——これらを署名前に確定させる。

「レガシーシステムをモダンなインターフェースでラップすれば段階的に移行できる」というベンダーの主張には留保が必要だ。ラッパーはそれ自体が所有・管理すべき追加レイヤーになり、インフラ問題を解決するのではなく先送りにするだけだとGuntakaは指摘する。


2027年に利益を出すのはどこか

派手なパイロットを走らせた企業ではない。インターフェースの整理、システムの疎結合化、ベンダー契約をアーキテクチャ図と同じ精度で読み込んだ企業だ——Guntakaはそう結論づける。

タイトルが問う「本番で失敗する企業が続出する理由」への答えは、記事全体を通じて一貫している。エージェント自体の性能ではなく、それを支えるインフラの柔軟性と契約上のガバナンスの欠如が根本原因だ。デモ環境は理想的な配管を前提に動く。本番環境は数十年分の技術的負債と、見落とされた契約条項の上に動く。この非対称性を事前に織り込んでいない企業が、投資回収の見通しが立たないまま撤退を余儀なくされる——Gartnerの40%超キャンセル予測が示すのはその現実だ。

エージェントは誰もが見える部分だ。配管(所有しているものも、借りているものも)は、利益が生まれるか損失が膨らむかを決める部分だ。


詳細はCompanies Are Shopping for AI Agents. The Real Bill Is for the Plumbing.を参照していただきたい。