AIエージェント、88%が本番に届かない——PoC止まりを突破する組織の共通点

企業の78%がAIエージェントのパイロットを回している。だが本番環境で安定稼働しているのは、わずか14%。この数字の意味するところは明快だ——技術検証と本番運用の間に、巨大な断層がある。

2026年3月、テクノロジーリーダー650名を対象とした調査が公開された（出典: Digital Applied, AI Agent Scaling Gap Survey, March 2026）。そこに並ぶ数字は、AIエージェントに期待を寄せる経営者にとって冷水のようなものだ。

本記事では、88%がつまずく5つの断層と、14%の成功企業が共有する設計原則を、私たちLat91自身の10体運用経験を交えて解説する。

「動くデモ」と「動き続けるシステム」は別物である

パイロットでAIエージェントが成果を出すのは、実はそれほど難しくない。整った検証データ、限定されたユースケース、関心の高いチームメンバー。条件が揃えば、数週間で「おお、すごい」と言わせるデモは作れる。

問題は、その「おお、すごい」を日常業務に組み込む段階で起きる。調査によると、パイロットが停滞するまでの平均期間は4.7ヶ月。64%の組織がスケールを試みたが、72%が6ヶ月以上のブロッキングイシューに直面した。

なぜか。テスト環境のデータはきれいだ。本番のデータは汚い。レコードの欠損、フォーマットの不統一、古い情報の混在——エージェントの信頼性は、その土台となるデータの品質で決まる。にもかかわらず、多くの組織はモデル選定やプロンプト設計に投資を集中させ、データ基盤の整備を後回しにする。

図1: パイロットから本番環境への移行で生じる5つの断層

88%の内訳——失敗パターンは7つに集約される

88%という数字をもう少し分解してみよう。別の分析（出典: Digital Applied, AI Agent Production Failure Framework, 2026）によれば、本番到達前に頓挫するプロジェクトの94%は、7つの失敗パターンのいずれかに該当する。

最大の敵はスコープクリープだ。全体の34%を占める。最初は「見積書の自動分類」だったものが、いつの間にか「取引先との交渉メール自動生成」にまで膨張する。正式なスコープ管理なしに要件が拡大し、境界のある作業が「なんでもやるAI」に変貌する。

次に多いのがデータ品質問題で27%。セキュリティレビューでの停滞が14%、統合の複雑さが9%と続く。

興味深いのは、組織的抵抗——つまり「現場が使いたがらない」——は全体のわずか4%だという点だ。一般に語られるほど人間側の抵抗は大きくない。むしろ問題は、技術的な準備不足と管理プロセスの欠如にある。

この構造は、1990年代後半のERP導入ブームと驚くほど似ている。当時も「技術は使えるのに、なぜ現場で定着しないのか」と多くの企業が嘆いた。答えは同じだ。ツールの性能ではなく、ツールを組織に組み込むプロセスの設計が足りていなかった。

Klarnaの事例が示す「成功の条件」と「語られない代償」

成功事例として必ず名前が挙がるのがKlarnaだ。スウェーデンのフィンテック企業である同社は、AIアシスタントを顧客対応に本番投入し、初月で230万件の問い合わせを処理。これは700名のフルタイムエージェントに相当する業務量だった（出典: Klarna AI Case Study, 2024-2025）。

数字だけを見れば圧倒的な成果に映る。解決時間は平均11分から2分未満に短縮。再問い合わせ率は25%減少。年間4,000万ドルのコスト削減。

ただし、この華やかな数字の裏側にも目を向ける必要がある。Klarnaの成功にはいくつかの特殊な条件があった。

第一に、同社はRAG（検索拡張生成）型システムをそれが一般的になる前から構築しており、統合知識グラフという強固なデータ基盤を持っていた。第二に、カスタマーサービスという比較的パターン化しやすい業務領域に集中した。第三に、テック企業としてAI人材の厚みがあった。

Klarnaの教訓は「AIを入れれば成功する」ではない。「データ基盤を先に整え、スコープを絞り、段階的に拡大する」ことの有効性だ。規模も業種も異なる日本の中堅企業が同じ結果を期待するなら、この順序を守ることが前提になる。

14%の成功企業は何が違うのか——3つの設計原則

650社調査のデータを深掘りすると、本番運用に到達した14%の企業に共通するパターンが浮かび上がる。

原則1: 評価インフラへの先行投資

成功企業は、モデル選定やプロンプト設計よりも、評価基盤・モニタリングツール・運用体制への投資を重視していた。評価インフラを省略した組織は、安定稼働に至るまでに3倍の時間を要した。

これは直感に反する。多くの企業は「まず良いモデルを選び、良いプロンプトを書けば成果が出る」と考える。だが現実には、出力の品質をどう測り、どう改善し、どう監視するかの仕組みの方が、最終的な成果に対する影響がはるかに大きい。

原則2: 90日間の安定運用ルール

成功企業はスコープ拡大を急がない。本番投入後、最低90日間の安定稼働を確認してから、初めて対象業務を広げていた。これが「PoC止まり」と「本番定着」を分ける決定的な違いだった。

私たちLat91でも、AIエージェント10体の構築にPhase制を採用している。Phase 1のChief of Staffが安定してからPhase 2に進む。この設計は、まさに「90日ルール」と同じ発想だ。全部を同時に動かしたい誘惑は強い。だが一度に複数のエージェントを立ち上げると、問題が起きたとき原因の切り分けができなくなる。

原則3: 明確なオーナーシップ

専任のAI運用オーナーを設けていない組織は、本番環境でのインシデント発生時にロールバックする確率が6倍高かった。逆に、事前にオーナーシップを確立した組織は、ロールバックの確率が5.7倍低い。

「AIは誰の仕事か？」——この問いに明確に答えられない組織は、どれほど技術的に優れたエージェントを作っても、遅かれ早かれ運用が止まる。

図2: 本番運用に到達した14%の企業に共通する3つの設計原則

「でも結局、技術が追いつけば解決するのでは？」——この反論に向き合う

ここで予想される反論がある。「LLMの性能は日進月歩で上がっている。いずれ技術が追いつけば、88%という数字は自然に改善するのでは？」

この指摘には一部正しい面がある。実際、モデルの推論能力は2025年から2026年にかけて劇的に向上した。ハルシネーション率は低下し、ツール使用の精度は上がり、マルチステップの計画能力も改善されている。

だが、失敗原因のトップ2を思い出してほしい。スコープクリープ（34%）とデータ品質（27%）。これらはモデル性能とは無関係の、組織とプロセスの問題だ。モデルがどれほど賢くなっても、要件が際限なく膨張する組織文化は変わらないし、汚いデータは汚いままだ。

もう一つ。技術の進歩は、しばしば期待値のインフレも引き起こす。モデルが賢くなるほど「もっとできるはずだ」と要求が拡大し、結果としてスコープクリープはむしろ加速する。Gartnerは2028年までに業務上の意思決定の15%がAIエージェントによって自律的に行われると予測している（出典: Gartner, 2025）。この期待と現実のギャップこそが、次のPoC止まりの温床になる。

月曜日から始められる3つのアクション

データと事例を踏まえた上で、読者が自社で実行できるアクションを3つに絞った。

1. 失敗コストを可視化する。AIエージェントプロジェクトの失敗コストは平均34万ドル（約5,100万円）。さらに機会損失を含めると57万ドル（約8,500万円）に膨らむ（出典: Digital Applied, 2026）。経営会議で「PoCが止まっている」と報告するのと、「毎月この金額が溶けている」と伝えるのでは、意思決定のスピードが変わる。

2. スコープを紙に書いて壁に貼る。パイロットの対象業務を3行以内で記述し、それ以外の機能追加はすべて別プロジェクトにする。原始的だが、スコープクリープの最も効果的な対策は「物理的に目に入る場所に境界を書く」ことだ。

3. 「このエージェントの持ち主は誰か」を決める。IT部門でも事業部門でもいい。名前が1人決まるだけで、ロールバック確率は6分の1になる。逆に言えば、オーナーが決まらないプロジェクトは始めない方がいい。

まとめ——AIエージェントの壁は、AIの壁ではない

88%が本番に届かない。この数字は一見すると悲観的だが、裏を返せば構造は明確だということだ。失敗パターンは7つに集約され、成功企業の共通点は3つの原則に絞られる。

私たちLat91がAIエージェント10体をPhase制で構築しているのも、この構造を踏まえた判断だ。一度に全部を動かす誘惑を断ち、1体ずつ安定運用を確認してから次に進む。地味だが、88%の側に落ちないための最も確実な方法だと実感している。

AIエージェントの壁は、AIの壁ではない。組織設計の壁だ。そして組織設計の問題は、技術の進歩を待たなくても、今日から取り組める。

Lat91では、AIエージェントの設計から本番運用までを一貫してサポートしています。PoC止まりでお悩みの方は、お気軽にご相談ください。