AIエージェントのパイロットを実施している企業は78%。でも実際に本番環境で稼働しているのは14%だけです。78社がスタートして、11社しか生き残らない——残りの67社は今もどこかで止まっています。
Accentureの調査はさらにシンプルです。リーダー100人中32人だけが「会社全体でAIが継続的に成果を出している」と答えました。これが技術の問題なら修正できます。でもAccentureの診断は違います。技術の問題ではなく、デプロイ方法論の問題だというのです。
なぜパイロットは死ぬのか？
2026年5月のKnowledge 2026で、ServiceNowとAccentureが発表したのは新技術ではありませんでした。彼らが打ち出したのは方法論でした。
名前はForward Deployed Engineering（FDE）プログラム。このモデルを最初に作ったのはPalantirです。2010年代初頭、情報機関のクライアントが「欲しいものを言葉にできない」状況で、Palantirが考えたのがエンジニアを顧客環境に直接配置することでした。仕様書を受け取って作るのではなく、現場にいながら実際の制約の中で作るやり方です。
このモデルが2026年にAI業界全体に広まっています。AnthropicはこれをベースにBlackstoneら出資の15億ドルJVを組成、OpenAIも同方向で100億ドル規模で動いています。ServiceNow + AccentureのFDEプログラムも同じ流れの中にあります。
Digital Appliedの2026年3月調査（エンタープライズ技術リーダー650人対象）では、パイロットが本番環境に到達できない原因が整理されました。
- レガシーシステム連携の複雑さ
63%が挙げた第1位。AIは作れたのに、既存のERPやCRMへの接続が想定より格段に複雑なんです。 - 実使用時の出力品質低下
58%。テスト環境では問題なくても、本番のエッジケースで崩れるパターンが繰り返されます。 - モニタリングインフラの欠如
54%。エージェントがどんな判断を下しているか追跡できないケースが多いです。 - 組織内の責任所在が不明確
49%。「これ誰の担当？」が決まらないまま本番が進んでいきます。 - ドメイン学習データの不足
41%。汎用モデルが自社特有の状況を処理できないんですよね。
この5つには共通点があります。全部、技術の問題ではなくデプロイプロセスの問題なんです。AIそのものは動く。でも「うちの会社の現実」に合わせて連携する過程がないから、パイロットで止まってしまう。
現場に入ると何が変わるのか？
FDEモデルの核心はシンプルです。エンジニアが顧客環境の内側に入り、実際の業務システムの上でエージェントを構築・稼働させる。ServiceNow AIプラットフォームの上でです。
| 従来の方式 | FDE方式 | |
|---|---|---|
| 開発場所 | ベンダーオフィスでリモート開発 | 顧客環境に直接埋め込み |
| 要件把握 | 仕様書・会議でスペックを伝達 | 現場観察 + リアルタイム反映 |
| 検証環境 | シミュレーション・サンプルデータ | 実際の本番データ |
| デプロイ目標 | パイロット完成 | 初期ビルドから全社展開を設計 |
| ガバナンス | 個別管理システム | AI Control Tower で統合管理 |
ServiceNow SVPのJohn Aisienはこう説明しています：「我々のチームは顧客環境にいて、ServiceNowとサードパーティのビルディングブロックを実装し、価値指標を直接証明します。」 価値を証明してからデプロイが始まるのではなく、デプロイしながら同時に価値を作っていく構造です。
中心にあるのがAI Control Tower。ServiceNowがKnowledge 2026で再定義したこのシステムは、エージェントのパフォーマンス追跡・ガバナンス・セキュリティ・コスト計測を一箇所で処理します。ServiceNow自身がこのシステムで2025年に5億ドルの累積AI価値を確認、Rolls-Royceは12,000人の社員に展開して5,000時間の効率化と54%のリクエスト自動処理を達成しました。
FDEプログラムが提供するもの
ServiceNow + Accentureのクライアントは300以上の既製AIエージェントスキルとワークフローに即座にアクセスできます。ゼロから作らず、検証済みのエージェントを自社環境に合わせて調整する方式です。
AccentureのRam Ramalingamがズバリ言っています：「クライアントが聞くのはAIに投資すべきかどうかではありません。エンタープライズ規模でどう機能させるかです。」 もうみんなパイロットはやっています。戦場はデプロイです。
FDE方式で始めるための整理
- 止まっているパイロットを再診断
5つの原因（連携・品質・モニタリング・責任・データ）のどこで詰まっているかを特定。技術の問題か組織の問題かで対処が全く違います。 - 最初から全社展開を設計する
「パイロット成功」を目標にしない。設計段階から「全社にどう展開するか」を考える。展開範囲が変わるとアーキテクチャ自体が変わります。 - ガバナンスインフラを先に構築
エージェントが何を決定しているか追跡するシステム（モニタリング・監査ログ・成果指標）をデプロイ前に用意。後付けは格段に難しくなります。 - 責任所在を文書化
各AIエージェントに「オーナーは誰か」を明文化。異常信号が来たとき誰が対応するか事前定義がないと、エージェントが止められます。 - 組み込み型パートナーシップを検討
ServiceNow + AccentureのFDEプログラムのように、外部専門家が自社環境の中で一緒に作るモデルを検討。リモートコンサルよりも現場埋め込みの方がパイロット→本番ギャップを縮めるのに効果的です。
