「PoCまでは、うまくいったんです」
AI導入の相談で、この言葉を何度聞いたか分からない。デモは動いた。役員会でも好評だった。それから半年、プロジェクトは止まったままだ——という話が、驚くほど多くの会社で、ほとんど同じ筋書きで起きている。
これは個々の会社の失敗ではない。構造の問題だ。
95%が成果を出せていない、という数字
MITのプロジェクトNANDAが2025年に発表した調査「The GenAI Divide: State of AI in Business 2025」は、300件超のAI導入事例の分析から、企業の生成AIパイロットの95%が測定可能な事業成果（P&Lインパクト）を出せていないと報告した（Fortune報道）。カスタム開発されたエンタープライズAIツールのうち、本番に到達するのは約5%にすぎない。
日本でも、IPAの「DX白書2023」によれば、DXに取り組む企業の約4割が「成果が出ていない」と回答している。生成AIの導入だけが特別に難しいのではない。「試す」と「業務が変わる」の間の溝が、一貫して埋まっていないのだ。
見落とされがちだが、MITの同じ調査にはもう一つ重要な数字がある。外部パートナーが関与した導入は、内製の約2倍の成功率を示した。失敗の原因は技術ではなく、導入の方法論にある——そう読むべき数字だ。
PoCで止まる5つの構造的原因
現場に入って多数の導入を見てきた経験と、各種調査が指摘する内容は、ほぼ一致している。整理すると5つになる。
第一に、PoCの目的が「技術検証」で終わっている。 「LLMでこれができるか」を確かめるPoCは、成功しても次につながらない。削減される工数、変わる業務、それが利益にどう効くか——事業インパクトの定量化が設計に入っていないため、経営者は本番投資を判断できない。
第二に、Go/No-Goの基準が最初に決まっていない。 本番移行の判断基準をPoC開始時に定義していないプロジェクトは、「良さそうだけど決め手に欠ける」まま漂流する。PoCの延長が繰り返され、予算と熱量だけが減っていく。
第三に、現場の業務フローに組み込まれていない。 デモ環境では動くが、実業務では使われない。もっとも典型的な失敗だ。ツールを「渡す」ことと、業務が「変わる」ことの間には、業務フローの書き換えと現場トレーニングという地味な工程がある。ここを担う人が計画にいない。
第四に、実データ・既存システムに触れていない。 PoCはきれいなサンプルデータで行われがちだが、本番で待っているのは表記のゆれた実データ、レガシーシステム、権限とセキュリティの制約だ。この環境差を最初から見積もれる技術者が入っていないと、本番化のコストが読めず頓挫する。
第五に、「作る人」と「使わせる人」が分断されている。 開発はベンダー、推進は情シス、利用は事業部。この分業では、現場の「ここが使いにくい」が実装に反映されるまで数週間かかる。改善の遅いツールは、現場に静かに見放される。
なぜ従来の外注では解けないのか
5つの原因を眺めると、共通の根が見える。AI導入は「要件が最初に確定しない」仕事だということだ。何をAIに任せられるかは、現場で動かしてみないと分からない。ところが従来の外注モデル——提案して終わりのコンサルも、要件確定を前提とするSIerへの一括発注も、課題定義の責任を持たないSESも——はすべて、要件が決まっていることを前提に組まれている。探索的な仕事を、確定的な契約の型に流し込んでいる。止まるのは当然と言えば当然なのだ。
FDEが埋めるもの
FDE（Forward Deployed Engineer）は、顧客の現場に入り込み、課題定義・実装・導入・定着までを一貫して担うエンジニアだ（職種の詳しい解説はこちら）。FDEの型は、5つの原因に一つずつ対応している。
業務KPIを成果指標にしてPoCを設計する（原因1）。Go/No-Go基準を初週に定義する（原因2）。現場に入り、業務フローごと書き換えて組み込む（原因3）。初日から実データと既存システムで作る（原因4）。そして、作る人と使わせる人が同一人物になる（原因5）。
本質は最後の一つ、フィードバックループの短さにある。現場の「ここが違う」が、その日のうちに実装に反映される。この速度は、分業型の外注では構造的に出せない。外部パートナー関与型が内製の2倍成功するというMITの数字も、こうした導入の方法論の有無で説明がつくと私は考えている。
前提と反証
FDE型がすべてに勝るわけではない。要件が固まった大規模システムの構築は従来型に分があるし、長期的には自社にAIを扱う筋肉をつける内製化が理想だ。現実的なのは、外部のFDEと一緒に最初の成功パターンを作り、型を自社チームに移管していく形だろう。移管まで含めて設計されているかは、FDE型支援を選ぶときの見極めどころだ。
95%と5%を分けるもの
PoC止まりは、技術の問題ではなく体制の問題だ。だからこそ、直せる。派手なツールの乗り換えではなく、「作る」と「使われる」の間の溝を誰が埋めるのかを決めること。まずは止まっているPoCを一つ選び、「この検証は、どの業務の何時間を削るためのものか」を言葉にしてみてほしい。それが言えないなら、止まっている原因はたぶん技術ではない。
あなたの会社のAIプロジェクトは、いま95%の側にいるだろうか、5%の側にいるだろうか。
自社のAI活用がどの段階にあるかを確かめたい方は、無料のAI診断から始めてみてほしい。
