生成AI受託開発 ／ ブログ ／ 生成AIのPoCが本番に載らない5つの理由と、進むプロジェクトの共通点
生成AI導入PoCプロジェクトマネジメント

生成AIのPoCが本番に載らない5つの理由と、進むプロジェクトの共通点

生成AIのPoCは動いたのに本番導入で止まる——その原因は精度ではなく、評価基準・運用体制・投資判断の欠落にあります。止まる型と進む型の違いを実務目線で整理しました。

「PoCではうまく動いたのに、その先に進まない」——生成AIの導入相談で、私たちが最も多く聞く言葉です。

この記事は、社内で生成AIのPoC（実証実験）を実施した、あるいはこれから始めようとしている企業の担当者・経営者に向けて書いています。PoCが本番運用に到達しない原因はどこにあるのか、逆に本番に載ったプロジェクトは何が違ったのか。技術的な話よりも、意思決定と体制の話が中心です。

結論を先に書くと、止まる原因の多くはモデルの精度ではありません。「何をもって成功とするか」を事前に決めていないことと、運用する人が決まっていないことの2つに集約されます。

PoCが「成功」しても本番に載らない構造

まず、よくある流れを整理します。

  1. 経営層から「生成AIで何かできないか」と指示が出る
  2. 情報システム部門や事業部が候補業務を挙げる
  3. ベンダーに声をかけ、数百万円規模のPoCを実施する
  4. デモを見て「すごい」となる
  5. 本番化の稟議を上げようとして、止まる

5番で何が起きているか。稟議を書こうとした担当者が、次の質問に答えられないのです。

PoCの段階でこれらを設計していないと、答えは全部「わかりません」になります。そして稟議は通りません。技術検証は成功したのに、事業判断の材料が何も揃っていない。これが「PoC死」の実態です。

止まるプロジェクトに共通する5つのパターン

1. 評価基準が「印象」で終わっている

最も多いパターンです。PoCの報告書に「概ね良好な回答が得られた」「実用に耐えうる品質」と書かれている。しかし「概ね」が何%なのかが定義されていない。

本番化を判断する側からすると、これでは判断できません。80%の正答率で十分な業務もあれば、95%でも不足する業務もあります。先に「このラインを超えたら本番化する」という数値と、その測り方を決めておく必要があります。

具体的には、業務担当者が実際に使う想定質問を50〜100件用意し、正解を人手で作り、それに対する一致率を測る。これだけで議論の土台が変わります。地味な作業ですが、ここを飛ばしたPoCは高い確率で止まります。

2. 対象業務の選定が「やりやすさ」だけで決まっている

「まずは社内問い合わせ対応から」というスタートは非常に多いですが、実はこれが曲者です。

社内問い合わせは技術的には実装しやすい一方、削減効果を金額換算しにくい。「情シスの問い合わせ対応が減った」と言っても、その人が別の業務に回っただけでは、財務上のインパクトはゼロと見なされます。

本番化まで進みやすいのは、時間が明確に計測でき、かつその時間が別の収益活動に転用できる業務です。たとえば、営業担当が提案書のドラフト作成に週4時間かけている場合、これを1.5時間に短縮できれば、差分の2.5時間は商談に回せます。この換算ができる業務を選ぶかどうかで、稟議の通りやすさが変わります。

3. 「運用する人」が決まっていない

生成AIの仕組みは、作って終わりではありません。

これらを誰がやるのか。PoCの段階ではベンダーがやっているので問題が表面化しませんが、本番運用ではここが継続的なコストになります。

私たちが提案フェーズで必ず確認するのは「運用担当者の名前」です。部署名ではなく個人名。ここが空欄のまま進むプロジェクトは、リリース後3ヶ月で放置される傾向があります。

4. コスト構造をPoC時点で把握していない

PoCは利用者が5人、質問数が1日20件程度で回ります。これが全社500人、1日3,000件になったときのAPI利用料を試算していないケースが目立ちます。

RAG構成の場合、1回の質問で参照文書を数千トークン分投入することは珍しくありません。回答生成分も含めれば、1問あたりのトークン消費はそれなりの規模になります。PoC段階で「1問あたりの平均トークン数」と「実際にかかった費用」を記録しておけば、スケール時の試算はそのまま掛け算でできます。この記録がないと、本番化の予算を組めません。

なお、モデルの単価は各社とも改定が続いているため、試算時点の公式価格ページを都度確認することをお勧めします。

5. 業務プロセスに組み込まれていない

「専用のチャット画面を作りました。ここから質問してください」——この形式は、PoCでは機能しますが、本番では使われなくなります。

理由は単純で、業務の動線から外れているからです。営業担当はSalesforceを、経理担当は会計システムを、開発者はSlackを見ています。そこから離れて別の画面を開く行為は、それだけで利用率を下げます。

本番に載ったプロジェクトは、既存ツールへの組み込みを最初から前提にしています。SlackやTeamsのボット、既存業務システムのサイドパネル、あるいはExcelのアドイン。「新しい画面を作らない」という制約を最初に置いたほうが、結果的に定着します。

進むプロジェクトの型：PoCの前に決めておくこと

ここまでの裏返しですが、本番化まで進んだプロジェクトには共通の準備があります。

撤退基準を先に書く

「精度が◯%に届かなければ本番化しない」と、開始前に文書化しておきます。これを決めておくと、結果が悪かったときに「もう少し調整すれば」と延命せずに済みます。撤退も立派な成果です。300万円のPoCで「この業務には向かない」と判明したなら、3,000万円の本番投資を回避したことになります。

業務担当者をPoCに参加させる

ベンダーと情シスだけでPoCをやると、実際の業務で使う質問がわかりません。現場の担当者に、普段の業務でそのまま使ってもらう期間を最低2週間は取る。このとき「うまくいった例」より「うまくいかなかった例」を集めることに重点を置きます。失敗例のリストが、本番設計の要件そのものになります。

間違えたときの運用を設計する

生成AIは一定の確率で誤った出力をします。これは前提条件であり、なくすことはできません。したがって設計すべきは「間違えない仕組み」ではなく「間違えても問題にならない業務フロー」です。

こうした制約を明示することで、法務・リスク管理部門の承認が取りやすくなります。逆に「AIが自動で処理します」と説明すると、確実に止まります。

具体例：見積書作成支援での分かれ道

製造業で見積書の作成支援を検討したケースを想定します。過去の見積データと製品仕様書を参照し、条件を入力すると見積のたたき台を出す、という構想です。

止まるパターンは、「過去の見積を全部読み込ませて、それらしい見積を出す」で終わるものです。精度は7割程度、残り3割は担当者が直す。デモは動きますが、担当者からすれば「直す手間を考えると自分で作ったほうが早い」となり、使われません。

進むパターンは、業務を分解するところから始めます。見積作成には、（a）類似案件の検索、（b）製品の型番と仕様の特定、（c）価格の算出、（d）文面の作成——といった工程があります。このうち（c）の価格算出は既存システムに正確なロジックがあるので、AIは使いません。AIが担うのは（a）と（d）に絞り、（b）はプルダウン選択にする。

この切り分けをすると、AIの出力に誤りがあっても価格は間違わない構造になります。そして担当者の作業時間は、検索と文面作成の部分だけ確実に減ります。範囲を狭めたほうが、本番化の判断はしやすくなります。

この考え方が向かないケース

正直に書いておくと、以上の進め方が適さない場面もあります。

探索段階では厳密な基準がかえって邪魔になることがあります。「生成AIで何ができるか、まだ社内の誰も知らない」という段階では、まず触ってみることに価値があります。この段階でKPIを求めると、誰も手を挙げなくなります。ただしその場合は、最初から「これは学習目的であり、本番化は前提としない」と宣言しておくべきです。本番化するつもりのPoCと、学習のための試行を、同じ言葉で呼ばないことが重要です。

また、規制産業や人命に関わる領域では、ここで書いた程度の設計では不十分です。医療、金融の与信判断、法的助言などは、業界固有の規制要件を踏まえた検討が別途必要になります。

まとめ

PoCが本番に載らない原因は、技術ではなく設計と体制にあります。整理すると次の通りです。

これらはすべて、PoCを始める前に決められることです。私たちがご相談を受ける際も、最初の打ち合わせで確認するのはモデル選定ではなく、この6項目です。逆に言えば、ここが埋まっていれば、技術的な選択肢は後からいくらでも調整できます。

すでにPoCを実施して止まっている場合も、上記のどこが欠けているかを特定すれば、やり直しではなく追加の検証で前に進められることが多くあります。まずは手元のPoC報告書を、この6項目で点検してみてください。