1. なぜ「生成AIで作れる」で数百万が溶けるのか

生成AIのいちばん怖いところは、「それらしく動くもの」が、あまりにも簡単にできてしまうことです。きれいに整えたサンプルデータを渡せば、要約も、分類も、下書きも、その場でうなずける結果を返します。この最初の手応えが「これはいける」という確信を生み、投資判断のアクセルを踏ませます。
ところが、デモと本番のあいだには深い谷があります。しかもその谷は、「ちゃんと動くかどうか」ではありません。デモは、こちらが選んだきれいな入力に、一回それらしく答えれば成立します。でも本当に問われるのは、動くことではなく、それで解きたかった業務の本質的な課題が実際に解決し、時間やコストという成果が生まれるかです。よくできたデモができても、現場の困りごと――たとえば「問い合わせ対応に毎日何時間も取られる」――が実際に減っていなければ、それは一円も生んでいません。この「ただ動くもの」と「課題を本当に解決するもの」の距離が、多くの人の見積もりより桁違いに遠い。ここを甘く見たまま予算とスケジュールを引くと、AI利用料と工数だけが積み上がり、成果が出る前に息切れします。
もうひとつの落とし穴が、目的が「AIを使うこと」になっているケースです。「AIで何かやれ」という号令から始まったプロジェクトは、解くべき業務課題と、その解決でいくら得(そん)をするのかが曖昧なまま進みます。すると、デモは動いても「で、これを入れると結局いくら儲(もう)かる・浮くの?」に答えられず、本番投資の決裁が通りません。動くものはある、でもGOが出せない。これがPoC止まりのもっとも多い姿です。
要するに、数百万が溶けるのは技術力が足りないからではありません。「動いた」と「課題を解決できた」を同じものだと思い込み、そのあいだにある本番化の作業量とコストを見積もっていないからです。次章から、その谷の正体を具体的に分解します。
2. PoCが本番に届かない、7つの落とし穴
デモから本番への谷は、ぼんやりした「なんとなく難しい」ではありません。つまずく場所はほぼ決まっています。代表的な7つを、心当たりを確かめながら読んでみてください。
- ① 目的とROIが曖昧:解く業務課題と、削減できる工数・金額が数字で決まっていない。だから本番の価値を示せない。
- ② データが整っていない:本番のデータは、汚れていて、あちこちに散らばり、権限もバラバラ。きれいなサンプルで動いただけでは、本番では途端に精度が落ちる。
- ③ 合格ラインがない:「なんとなく良さそう」で評価している。何%当たれば合格か、どこまでの間違いを許すかを決めていないので、本番GOの判断ができない。
- ④ 運用の担い手が未定:誰が結果を監視し、間違えたら誰が直し、更新は誰が回すのかが決まっていない。作った瞬間から古くなっていく。
- ⑤ コスト設計がない:試作の少量なら安く見えたAI利用料が、本番の件数では跳ね上がる。試算のまま載せて赤字になる。
- ⑥ 既存システムとつながっていない:単体では動くが、CRMや基幹システムに接続して初めて業務になる。実はこの「つなぐ」部分が本番工数の大半を占める。
- ⑦ 現場が使わない:現場の実際の業務フローに組み込まれておらず、操作も面倒。結局、誰も使わずに消えていく。
見てのとおり、7つのうちAIの賢さそのものの問題は多くありません。大半は、目的の決め方・データ・運用・連携・現場という、AIの周りの設計の話です。ここがPoCと本番を分ける本丸です。
3. 【自己診断】あなたのAI導入、PoC止まり予備軍?

自社の構想やプロジェクトが谷に落ちやすいかを、先に確かめておきましょう。次の10項目のうち、自信を持って「はい」と言えないものがいくつあるかを数えてください。
- このAIで解く業務課題を、一文で言える(「〜を〜する時間を減らす」など)
- 成功したら、月あたり何時間・何円が浮くのかを試算している
- 「何%当たれば合格」「どこまでの間違いは許す」という合格ラインを、数字で決めている
- 検証に、きれいなサンプルではなく、本番の汚いデータ・例外も入れている
- 本番の件数で回したときのAI利用料(月額)を試算している
- 間違えた結果を誰がどう直すか、更新は誰が回すかが決まっている
- 既存システム(CRM・基幹・チャットなど)のどこにつなぐかを把握している
- 現場の実際の業務フローの、どの操作を置き換えるかが具体的に描けている
- まず1業務・1チームの本番運用から始める、と範囲を絞っている
- うまくいかなかったときに撤退・見直しをする条件を、先に決めている
目安
- 「いいえ」が 0〜2個:本番化の設計がかなりできています。あとは実装と運用の作り込みに集中する段階です。
- 「いいえ」が 3〜5個:PoC止まり予備軍です。着手前に、埋まっていない項目を設計に足しておくと、溶ける費用を大きく減らせます。
- 「いいえ」が 6個以上:いま走り出すと、高い確率でPoCで止まります。作るより先に、第4章の設計をそろえるのが先決です。
ここで大事なのは、「いいえ」が多い=AIに向いていない、ではないということです。多くの場合、足りないのはAIの性能ではなく、その周りの設計です。設計を先に埋めれば、同じAIでも本番に届く確率がまるで変わります。
4. PoCを「本番」に変える、4つの設計原則
谷を越えるためにやることは、突きつめると4つに整理できます。派手さはありませんが、ここを踏むかどうかが、費用が溶けるか成果になるかを分けます。
原則1. 先に「合格ライン」と「回収額」を数字で決める
作り始める前に、何%当たれば合格か・どこまでの間違いを許すかと、成功したら月に何時間・何円が浮くかを決めます。これがあると、デモの手応えではなく数字でGO/NOGOを判断でき、「動いたのに決裁が通らない」を防げます。回収額は、たとえば「1件30分の作業 × 月400件 × 時給換算」のように、粗くても構わないので必ず出します。
原則2. 本番の「汚いデータ」で検証する
きれいなサンプルではなく、実際に現場が扱う、誤字や表記ゆれ・欠けのある・例外を含んだデータで試します。ここで精度が落ちるのが普通で、その落ち幅こそが本番化に必要な作り込みの量です。早めに直面しておけば、本番リリース後に「思ったより使えない」で信頼を失う事故を避けられます。
原則3. 「運用」と「監視」をセットで設計する
AIは作って終わりではなく、運用し続けて価値が出ます。誰が結果を監視し・間違いを誰が直し・内容を誰が更新するかを、公開前に決めます。あわせて、AIの出力をそのまま使わず、重要なところは人が最終確認する経路や、確信度が低いときは人に回す仕組みを入れておくと、大きな事故を防げます。ログを残し、間違いから改善し続けられる形にしておくことが、長く効く条件です。
原則4. 小さく本番投入し、コストを設計しながら広げる
全社一斉ではなく、まず1業務・1チームで「本番運用」します。試作の延長ではなく、実際の業務で回して数字で効果を確かめ、そこで初めて横展開します。同時に、本番の件数でAI利用料がいくらになるかを設計します。すべてに高性能モデルを使うのではなく、難しい処理だけ高性能・単純な処理は軽量モデルや従来手法に振り分ける、繰り返す処理は結果を使い回す、といった工夫で、費用は何分の一にもできます。
この4原則のうち、原則2〜4の「本番の作り込み」は、AIを触るスキルとは別の、実装と運用の勘所が要る領域です。ここが、社内だけで進めるといちばん時間を溶かしやすいところでもあります。
5. 着手前に一度、構想の穴を突いておく
大きく投資する前に、自分たちの構想がこの谷に落ちないかを、AIに壁打ち相手として点検させておくと安上がりです。次のプロンプトは、あなたのAI導入構想の弱点を、投資前に洗い出すためのものです。
# 役割 あなたはAI導入プロジェクトを何件も本番化・失敗の両方で見てきた、辛口のアドバイザーです。私のAI導入構想が「PoCで止まらないか」を、投資判断の視点で厳しく点検してください。 # 私の構想 (解きたい業務課題/使いたいAI/対象の業務量/今の進め方を書く。分かる範囲でよい) # 進め方 1. まず、この構想の目的とROIが数字で語れているかを確認する。曖昧なら、何を決めるべきかを問い返す 2. 本番化でつまずきやすい観点(データ・合格ライン・運用と監視・既存システム連携・本番のコスト・現場定着・撤退条件)ごとに、私の構想のリスクを指摘する 3. 各リスクを「致命的/要注意/許容範囲」で仕分けし、致命的なものから対処案を示す 4. 情報が足りず判断できない点は、憶測で埋めず、私への質問として挙げる # 出力 - リスク一覧を表で(観点/想定される失敗/重大度/先に打つ手) - 最後に「このまま進める前に、最低限決めるべき3つ」を挙げる
なぜこのプロンプトが効くのか
- 先に「辛口のアドバイザー」という役割と、点検すべき観点を渡しているので、褒めるだけの当たり障りない回答ではなく、投資前に知りたい弱点が出てきます。
- リスクを重大度で仕分けさせるので、「全部大事」で終わらせず、致命的なものから手を打てます。
- 足りない情報を憶測で埋めさせず質問として返させるので、あなた自身が「まだ決めていないこと」に気づけます。ここに気づくことが、PoC止まりを防ぐ最初の一歩です。
このプロンプトで構想の穴が見えたら、それがそのまま、本番化のためにそろえるべき設計リストになります。
6. 自前で行ける範囲と、任せたほうが速い範囲
第5章までの、目的とROIを決める・合格ラインを引く・小さく試すところまでは、社内で十分に進められます。むしろ、業務をいちばん分かっている現場が主導すべき部分です。ここを外に丸投げすると、かえってずれた仕組みができあがります。
一方で、原則2〜4の作り込み――本番の汚いデータに耐える精度づくり、誤りを防ぐ仕組み、CRMや基幹システムとの連携、確信度による人への引き継ぎ、本番コストの最適化、公開後のログ分析と継続改善――は、AIを使えることとは別の、実装と運用の専門性が要ります。ここを社内だけで手探りすると、まさに冒頭の「数百万を溶かしてPoC止まり」に近づきます。
目安はシンプルです。「解くべき課題は何か」「解決できたと言える成果の基準は何か」は自社で決める。「それを実際に課題解決・成果まで届かせる作り込み」は、勘所を持つ相手と組む。この線引きができていると、投資は溶けずに成果へ向かいます。まずは自己診断と壁打ちで構想を固め、本番化の作り込みで谷を感じたら、そこが相談のタイミングです。
まとめ
「生成AIで作れる」で数百万が溶けるのは、技術力ではなく、「動いた」と「本質の課題を解決できた」のあいだにある本番化の作業量を見積もっていないことが原因でした。
- 「動いた」はゴールではない。大事なのは、本質的な業務課題を解決して成果(時間・コスト)を生めるか。この谷は見積もりより桁違いに遠い
- つまずく場所はほぼ決まっている(目的・データ・合格ライン・運用・コスト・連携・現場)
- 自己診断で危険度を測り、「合格ラインと回収額を数字で決める/本番データで検証/運用と監視をセットで/小さく本番投入」の4原則で谷を越える
- 「何をやるか・成功基準」は自社で、「本番で回す作り込み」は勘所を持つ相手と
まずは第3章のチェックリストで自社の構想を採点し、第5章の壁打ちで穴を洗い出してみてください。溶ける前に設計を固めることが、AI投資をいちばん安く成功させる近道です。

