AIエージェントが『PoC止まり』で終わる本当の理由——日本は14カ国中最下位

「もう後戻りできない」——ある化学メーカー幹部のひとこと

「AIエージェント PoC止まり」「AIエージェント 本番運用」と検索してこのページにたどり着いた方も多いはずです。私たちも商談の場で「AI導入 PoC 抜け出す方法」や「FDE PoC 本番化」についての相談を、繰り返し受けています。冒頭の企画業務部長の言葉には、続きがあります。全社へのAI展開について、こう漏らしていました。「今使えているのは自分のパソコンの中まで。なぜ他の人のところまで広げられないのかが分からない」。個人のPCでは便利に使えている。しかし、それが部署を越えて広がらない。この感覚は、多くの企業に共通しています。

Confluentの「Data Streaming Report 2026」によれば、日本の回答者が挙げた最大の課題は「AIおよびデータに関するスキルと専門知識の不足」で80%に達しました。データ出力の課題は71%、リアルタイムデータの課題は69%という数字も並びます。私たちの現場経験では、この数字はスキル不足というより「PoCと本番運用の間にある溝」を測る指標に近いと感じています。個人のPCで動くプロトタイプを作る力はある。ですが、それを組織のインフラに接続し、複数人が安心して使える形にする力が、別に求められるからです。

VibeCoding内製化の現場でも、似た壁にぶつかる企業を数多く見かけます。担当者が個人的に触っているうちは驚くほど早く動くものができます。ところが「これを全社で使えるようにしよう」となった瞬間、権限設計・データ連携・運用体制といった、それまで意識してこなかった課題が一気に噴き出します。PoC止まりとは、技術力の問題である以前に、この「個人の成功」と「組織の成功」の間にある段差の問題だというのが、私たちの見立てです。

PoCは「成功」しているのに、なぜ本番に進まないのか

ある重工・製鋼メーカーのシステムグループマネージャーは、私たちにこう打ち明けたことがあります。「開発にAIを入れてコールを30%削減しました、とQC発表で報告したが、全然評価が悪くて、あまり響かなかった。どうやってやっていいのかな、と思う」。技術的には成功しているのです。数字も出ている。それでも社内で評価されない。この状況は、決して珍しくありません。

私たちの現場経験では、この種のPoCには共通点があります。「コールが30%減った」という数字が、経営や現場の誰の課題にも直結していないのです。削減できたコール対応時間は、誰の評価につながるのか。空いた時間で何をするのか。そこまで設計されていなければ、どれほど技術的に優れたPoCでも「面白い実験」で終わってしまいます。

成功指標を曖昧にしたままPoCを始めてしまう背景には、「まず作ってから考えよう」という善意のスピード感があります。動くものを早く見せたい気持ちは理解できますが、私たちが最初に確認しているのは「このPoCが成功したら、誰の、どの数字が動くのか」という一点です。ここが決まっていないPoCは、成功しても評価されず、失敗しても学びが残らないという、二重に厳しい結果を招きます。

「自分のパソコンの中」で止まる構造

冒頭の化学メーカー企画業務部長の疑問——「なぜ他の人のところまで広げられないのか」——には、はっきりした理由があります。個人のPCで動くプロトタイプは、その人の業務フローの中だけで完結しています。ファイルの置き場所、承認の順番、他部署への連携。これらは本人の頭の中にしかなく、システムには組み込まれていません。

私たちがVibeCoding内製化の現場でよく見るのは、まさにこのパターンです。ある担当者が個人的に作ったツールが素晴らしく便利で、周囲から「うちの部署でも使いたい」と声が上がります。ところが実際に横展開しようとすると、業務フローが部署ごとに微妙に異なり、そのままでは動きません。個人の工夫を、組織の仕組みに翻訳する作業が別途必要になるのです。

ある大手化学メーカーの生産DXグループリーダーは、この壁をこう表現していました。「基本、システムではつながっていない。繋げようとしても縦割りが強く、事業ごとに顧客も機能も全然違う。一つのシステムでは使いづらい」。全社で統一しようとするほど、現場の実情から離れていく。かといって個人任せにすれば、組織としての資産にならない。この緊張関係を設計段階で織り込んでおかないと、PoCは「自分のパソコンの中」から一歩も出られません。

データが「動くデモ」止まりを生む

PoCのデモは驚くほどきれいに動くのに、本番になると急に精度が落ちる——これも私たちがよく相談を受けるパターンです。理由の多くは、デモ用に整えられた綺麗なデータと、現場で日々発生する乱雑なデータとの差にあります。

ある化学メーカーの工場担当者は、記録の実態をこう語っていました。「手書きのメモを事務所に戻ってきてから入力しているが後回しになることもあり、データとして活用しきれていない」「単一のデータとしては存在しても、トレンド管理に落とし込めていない」。PoCの段階では、この種のデータの穴を人力で補って見せることができます。ですが本番運用では、その手当てを毎回誰かがやり続けるわけにはいきません。

私たちの経験では、データ整備を「PoCが終わってから考える後工程」に位置づけている企業ほど、本番化で足踏みします。逆に、PoCの設計段階から「このデータは誰が、いつ、どう入力するのか」を業務フローとセットで決めている企業は、本番移行がスムーズです。技術的な精度よりも、データが継続的に流れ込む仕組みがあるかどうかが、分水嶺になっています。

ある化学メーカーの保全担当者は「点検スパンを伸ばせるような予測ができれば効率化に繋がる」と期待を語っていました。一方で新システムの定着については、「若手社員に『記録が未来に役立つ』という意識を持たせることが重要」とも話しています。どれほど優れたAIエージェントを用意しても、記録を残す人の納得感がなければ、データは細り、精度は落ちていきます。私たちがデータ整備の設計と同じくらい重視しているのは、この「なぜ記録するのか」を現場の言葉で伝える工程です。

「誰が責任者か」が曖昧なまま進む怖さ

技術やデータの問題以上に見落とされがちなのが、責任の所在です。ある大手建材・シャッターメーカーの情報システム部長は、複数システムを別々に作る方針について「よろしくない。最適なやり方とセキュリティ要件を見定めないと、正直、一時の投資になってしまう」と警戒し、「一社集中がいいのか、数社で組む方がいいのか、正直悩ましい」と繰り返し口にしていました。

PoCの段階では、多くの場合、担当者1人の裁量で進められます。ところが本番運用となると、セキュリティ・権限管理・障害対応など、組織として引き受けなければならない責任が一気に増えます。この時に「誰が本番運用の責任者か」が決まっていないと、稟議の途中で止まったまま、誰も次の一歩を踏み出せなくなります。

私たちの現場経験では、本番化の直前で止まるプロジェクトの多くが、実はここでつまずいています。技術的には準備ができているのに、承認する人、運用を引き取る人、障害時に責任を持つ人が明確でない。だからこそ私たちは、PoCを始める前の段階で「本番化したら誰が運用責任者になるか」を仮でも決めておくよう勧めています。後から決めようとすると、たいてい間に合いません。

PoC止まりの正体は、技術ではなく「分断」にある

ここまでの原因——成功指標の曖昧さ、業務フローとの接続不足、データ整備の後回し、責任者不在——には共通点があります。いずれも、PoCを「作る人」と本番運用を「引き取る人」が分かれていることから生まれる分断です。

正直に言えば、これはAIエージェント特有の問題ではありません。従来型のシステム開発でも、同じ構造の失敗は起きてきました。ただしAIエージェントの場合、確率的に出力が揺れるという性質上、「作った人にしか分からない勘所」が特に多く残りがちです。ここは意見が分かれるところですが、私たちはこの「作る人と引き取る人の分断」こそが、日本のPoC止まり率の高さの根本にあると考えています。

paiza創業者の片山良平氏がnoteで指摘している内容も、私たちの実感と重なります。PoCの現場では、業務モデル全体の定義や制約条件の管理があいまいなまま進み、判断基準・意味文脈・ガバナンスといった「本番で初めて問われる要素」が後回しにされやすいという指摘です。これはつまり、PoCの段階で見えている景色と、本番運用で必要になる景色がそもそも違う、ということを意味しています。

コンサルが提案書を書いて終わり、実装は別のSIerに委ねる、という従来型の分業モデルでは、この分断は構造的に埋まりません。知見は報告書の中に閉じ込められ、実装した人は現場の意図を知らないまま手を動かします。私たちがFDE(フォワードデプロイドエンジニア)モデルにこだわっているのは、この分断を最初からなくすためです。PoCの段階から本番化までを同じ人間・同じチームが担うことで、「作った人にしか分からない勘所」が引き継ぎの過程で失われずに済みます。より詳しい違いはFDE・コンサル・SIerの比較記事でも触れていますが、ここではPoC止まりという文脈に絞ってお伝えします。

なぜFDEモデルだとPoCで終わらないのか

FDEは、顧客の現場に入り込み、本番コードを書き、成果まで責任を持つ人材です。私たちがこの働き方を続けているのは、PoCを作った人がそのまま本番運用まで伴走すれば、「作る人と引き取る人の分断」がそもそも発生しないからです。

具体的には、月次の技術顧問契約に移行した後も、現場からのフィードバックをイシューとして登録し、翌週にはプロトタイプに反映するというサイクルを回し続けます。ある大手化粧品メーカーとの技術顧問定例では、5月末までに現場情報をシステムに投入し、一連の業務フローが動く状態を目指しました。そして6月からは、本番運用の伴走として技術顧問契約にシフトするという進め方を実際に取っています。PoCと本番運用の間に切れ目を作らないのです。

誤解のないように言えば、コンサルやSIerが「悪い」わけではありません。役割が違うだけです。ただし、PoC止まりという課題に対しては、作る人と引き取る人を同じ人物・同じチームにするという単純な工夫のほうが、複雑な統制の仕組みを後から足すよりも効果的だというのが、私たちの実感です。

「1日でプロトタイプを作る」がPoC疲れを防ぐ

私たちの商談での成約率は9割を超えていますが、これは動くプロトタイプを見せることで実現しています。構想策定の段階から、実際に動くものを1日で作り、それを叩き台に議論します。報告書やモックアップではなく、触って確かめられるものを最初から見せるのです。

これには理由があります。PoCが何ヶ月もかかると、その間に現場の熱意は冷め、担当者は異動し、経営の優先順位も変わります。私たちが相談を受ける企業の7割以上が、PoCの途中で「そもそも何を検証していたのか」を見失った経験を持っています。1日というスピードは、単なる自慢ではなく、この「PoC疲れ」を防ぐための設計です。

もちろん、1日で作るのは最初のプロトタイプであり、それがそのまま本番システムになるわけではありません。そこから現場の要望を反映しながら育てていきます。ですが、最初の一歩を1日で示せることで、「思っていたのと違う」という手戻りを早い段階で解消できます。従来のAs-Is/To-Be整理が「網羅的だが複雑すぎて使えない」資料に終わりがちなのに対し、動くものを基に要望を積み上げていくほうが、結果的に本番までの距離が縮まるというのが私たちの結論です。

この進め方を支えているのが、VibeCoding(自然言語でAIに指示を出しながらシステムを組み上げる開発手法)です。従来なら見積もりと要件定義だけで数週間かかっていた工程が、対話しながらその場で形になっていきます。ただし、正直に言えば、スピードだけを追い求めると別の問題が生まれます。非エンジニアの担当者がデータベースを直接触ってしまい、後戻りできない変更を加えてしまうケースです。私たちは、まずデータベースをいじらない範囲から内製を始めてもらい、変更はプルリクエストを経由させ、AIによるレビューを挟むというガードレールを設けています。速さと安全さは、両立できないものではありません。

私たちが実践しているPoC止まりからの抜け出し方

私たちが最近、顧客に提示しているのは「PoCではなく、500万円程度の予算で現場の課題解決から始める」という進め方です。受託ではなく共同事業として取り組むという位置づけにしています。無料のPoCは検証で終わりやすい一方、一定の予算をかけた共同事業は、双方に「本番まで進める」という前提が生まれるからです。

ロードマップとしては、まず難易度がそこまで高くないが影響範囲が大きい業務から着手します。現場の疲弊を解消する目先のテーマで結果を出しつつ、並行して中長期の仕組みを整えていくという両輪です。小さく始めて、成功体験を積み重ねる。これは私たちがVibeCoding内製化全般でお勧めしているやり方と同じです。

具体的な進め方は次の3ステップです。まず、PoCを始める前に成功指標と運用責任者を仮決めします。次に、動くプロトタイプを早期に見せながら、業務フローへの接続を最初から設計に含めます。そして、PoCを作ったチームがそのまま本番運用の初期段階まで伴走する体制を組みます。この3つを外さなければ、PoC止まりの大半は回避できるというのが、私たちが現場で積み重ねてきた実感です。

自己診断: 自社のPoCを止めているのはどれか

ここまでの内容を、自社に当てはめてチェックしてみてください。

1. このPoCが成功したら、誰の、どの数字が動くかを説明できるか
2. PoCで使うデータは、本番運用でも継続的に入力される仕組みになっているか
3. 本番化したときの運用責任者は、PoCを始める前から決まっているか
4. PoCを作った人と、本番運用を引き取る人は同じチームか
5. 動くものを、企画から1〜2週間以内に見せられているか

私たちの現場経験では、5つのうち3つ以上に「いいえ」がつく企業ほど、PoC止まりのリスクが高い傾向にあります。逆にいえば、この5つは特別な技術力がなくても、明日から手をつけられる項目です。技術的な検証そのものよりも、検証の前と後をどう設計するかで、PoCが本番化まで到達するかどうかの大半が決まるというのが、私たちがFDEとして数多くの現場に入って得た結論です。

余談ですが、この自己診断を社内で共有してもらったとき、意外な反応が返ってくることがあります。「責任者は決まっているつもりだったが、担当者に聞くと誰も知らなかった」というケースです。決めたつもりで終わっていて、現場まで伝わっていない。これもまた、分断のひとつの形だと私たちは捉えています。

よくある質問

Q1. PoCと本番運用の間に、明確な期間の目安はありますか。 目安として、PoC通過までが3〜6ヶ月、本番化と運用の社内引き渡しまでを含めて6〜12ヶ月が一つの基準です。期限を切らない契約は、依存が永続化しやすい傾向があります。私たちが最初の打ち合わせで期限を確認しているのは、この永続化を避けるためです。

Q2. 小規模な会社でもFDEモデルは使えますか。 使えます。むしろ人員に余裕のない中小企業ほど、作る人と引き取る人を分けない体制のほうが、後々の引き継ぎコストを抑えられます。

Q3. 内製化を目指す場合、外部のFDEは不要になりますか。 最終的には不要になることを目指しています。技術顧問契約を通じて顧客チームへの技術移転まで責任を持つのが、私たちの伴走の終わり方です。マニュアル作成と勉強会・機能横断説明会を通じて、DBを直接いじらないところから段階的に権限を渡していく進め方を取っています。

Q4. PoCで失敗した場合、何が失敗と呼べるのでしょうか。 技術的に動かなかったことよりも、成功指標を決めずに始めたことのほうが、私たちは本質的な失敗だと考えています。指標さえあれば、失敗からも次に使える学びが残ります。

Q5. 経営層の後押しがない場合、どこから始めればよいですか。 難易度が低く、影響範囲が大きい1つの業務から始めることをお勧めします。小さな成功体験が、次の予算獲得の材料になります。

まず試すなら

• 現在進行中、または検討中のPoCについて、成功指標と本番運用の責任者を1つずつ言葉にしてみること
• PoCで使っているデータが、本番でも継続的に入力される仕組みになっているかを確認すること
• 自己診断の5項目に自社を当てはめ、「いいえ」がいくつつくかを数えてみること

AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。PoCで止まっている取り組みがあれば、何が本番化を妨げているのかを一緒に見極めませんか。

参考リンク

• 「AIエージェントを本番運用中」日本が最下位 “PoC止まり”の原因と、抜け出す方法は？

• FDE・コンサル・SIer──AI導入パートナーの選び方と、3者の根本的な違い