技術トレンド

AIプロジェクトはなぜ止まるのか。PoCから本番運用へ至れない構造

AIを試した企業は約8割に達する一方、本番運用に到達したのは1〜2割程度という報告があります。この差は技術力ではなく、進め方の設計から生じています。この記事では、公開されている調査データで現状を確認し、どこで止まるのか、なぜ止まるのか、そして越えるために何が必要かを整理します。

数字で見る現実

複数の調査が、同じ方向を示しています。

McKinseyの2025年11月のGlobal AI Surveyによれば、88%の組織が少なくとも1つの業務でAIを利用している一方、EBIT（営業利益）への影響を確認できているのはわずか39%でした。

MITのNANDAイニシアチブによる2025年の調査では、生成AIのパイロットプログラムの95%が、測定可能な財務インパクトを生み出せずに終わると結論づけられています。

S&P Global Market Intelligenceの2025年調査では、42%の企業が大半のAI施策を放棄したと報告されています。

本番化した後も安泰ではありません。ある調査では、本番化したAIシステムの80%が失敗し、承認から停止までの中央値はわずか14か月とされています。

日本国内の報告でも、試験導入する企業は約8割に達する一方、本番運用に到達するのは1〜2割程度という数字が出ています。

調査によって数字は幅がありますが、「試す企業は多く、続く企業は少ない」という傾向は一致しています。

どこで止まるのか

失敗のパターンは、大きく3段階に整理できます。

← 横にスクロールしてご覧いただけます →

最も多いのが最初の段階です。「AIエージェントを試してみたが、結局あれはどうなった？」という状態で立ち消えになる。2026年、多くの企業の会議室でこの言葉が聞かれるようになったと指摘されています。

重要なのは、2024〜2025年に「AIは動くのか」という問いはすでに解決しているという点です。勝負は「業務に着地するか」に移りました。

止まる4つの原因

失敗の典型として、次の4つが挙げられています。

1. データを把握していない。 どんなデータが、どこに、どんな形で存在するか。期間見積もりのぶれの最大要因は、モデルではなくデータだという指摘があります。サンプルではなく、現場で実際に流れているファイルを最初に確認しなければ、整備の重さは測れません。

2. 評価基準を決めていない。 何が達成されたら本番化するのか。この基準がないまま始めると、「精度は上がったが、これで十分かどうか分からない」という状態に陥ります。

3. スコープを盛り込みすぎる。 あれもこれもと対象を広げた結果、どれも中途半端に終わる。期間を左右するのは技術の難易度より、スコープの広さとデータの整い具合です。

4. 1つのAIに丸投げする。 複雑な業務をそのまま1つの仕組みに任せようとすると、精度が安定しません。処理を分解し、計算はプログラム、解釈はLLMというように役割を分ける設計が求められます。

いずれも技術の問題ではなく、進め方の設計の問題だという点が共通しています。

本番運用の3つの壁

PoCを越えても、本番運用には別の壁があります。ある報告では、本番運用に到達した企業とPoC止まりの企業の違いは技術的な能力ではなく、次の3点を設計していたかどうかだとされています。

ガバナンス。 AIエージェントが自律的に業務を実行する場合、「誰がその実行を承認するのか」が明確でなければ本番に出せません。判断の責任が宙に浮いたままでは、経営が承認しません。

セキュリティ。 どのデータにアクセスさせるか。外部に送信される情報はあるか。誤って機密情報が流出した場合の影響範囲は。

信頼性。 出力が誤っていたとき、どう検知し、どう戻すか。「たまに間違える」ことを前提とした運用設計が必要になります。

ここで有効とされるのがHuman-in-the-Loop、つまり人の承認を挟む設計です。完全自動化を目指すより、結果的に本番化への最短ルートになるという指摘があります。

越えるための進め方

実務的な手順として、次の流れが示されています。

1. テーマを棚卸しする。 「AIで何かできないか」ではなく、発生頻度、1件あたりの工数、データの有無で候補業務を並べる。そしてオーナーの顔が浮かぶものを選ぶ。誰の課題かが曖昧なテーマは進みません。

2. 実データを現物で確認する。 サンプルではなく、現場で実際に流れているファイルを最初の打ち合わせで見る。ここでしかデータ整備の重さは測れません。

3. 本番の絵を先に描く。 誰が使い、誰が運用し、費用が何にかかるのか（構築・API・監視・更新）を一枚にまとめる。本番の絵がないままPoC予算だけを確保することは避けるべきとされています。

4. 撤退条件を含む判断基準に合意する。 どの数字が出たら進み、出なかったらやめるのか。やめる基準を先に決めておくと、PoCは「失敗できる安全な実験」になり、かえって前に進みやすくなります。

5. 小さく本番に出す。 完璧を目指して長期化させるより、限定範囲で運用を始め、効果を数字で経営に示しながら広げる。

なお、「本番化しなかった＝失敗」ではありません。 やめる判断ができたこと自体が、PoCの成果のひとつだという考え方も示されています。

この領域で求められる人材

ここまでを踏まえると、何が不足しているかが見えてきます。

興味深い指摘があります。PoCに必要なのはAI技術者ではなく「業務課題を言語化できる担当者」だというものです。業務フローや現場の実態を把握している人が関わることが、成功の鍵とされています。

実際、求められる能力を整理するとこうなります。

• 業務を理解している／どの業務が対象になるか、なぜその手順なのかを知っている
• データの所在が分かる／何がどこにどんな形であるか。整備にどれだけかかるか
• AIで解くべきかを判断できる／BIで足りるのか、AIが必要なのか。この見極めが最初の分岐点です
• 評価基準を設計できる／何をもって成功とするかを、事前に数字で定義する
• 運用まで設計できる／作った後、誰がどう回すか
• やめる判断ができる／続けるべきでないときに、止める決断をする

いずれも「AIを作る技術」ではなく「AIを使えるようにする力」です。そして、この部分こそ人手が足りていません。

AI関連の案件が増えているにもかかわらず、多くのプロジェクトが止まっている。この矛盾の中心にあるのが、技術と業務をつなぐ人材の不足だと言えます。