はじめに——「実証では動いた」のに、なぜ本番に進めないのか
「PoC（実証実験）は好評だった。現場のデモでも『これは使える』と声が上がった。なのに、半年経っても本番展開の話が一向に進まない」——AI導入を推進してきた情シス・DX推進・経営企画の方から、いま最も多く聞こえてくる悩みがこれです。動くものは作れた。効果も見えた。それでも、本番に乗らない。この「実証と量産の間に横たわる谷」を、本記事では「PoC死（PoC で止まる）」問題として正面から扱います。
本連載は第1回「導入したのに誰も使わない」問題（?p=758）で定着の壁を、第2回「効果が説明できない／ROIが見えない」問題（?p=766）で効果測定の壁を扱ってきました。第2回の最後で予告したとおり、今回はその次に必ず来る関門——「で、本番にいつ・どう乗せるのか」に答えられないまま塩漬けになる問題を、運用・責任・コスト・スケールの4つの壁に分解します。
筆者はネットワークの世界で、検証環境（lab）で動いた構成を本番ネットワークへ投入（production cutover）する場面に長年携わってきました。「ラボで動いた」と「本番で回り続ける」はまったく別の難易度であり、その間を埋めるのは技術ではなく、変更管理・ロールバック設計・段階展開・SLA設計といった運用の作法です。本記事の核心は、このNOC/TAC的な本番投入の勘所が、そのままAIのPoC死回避に転用できるという点にあります。
なぜPoCは死ぬのか——PoCと本番は「目的」が違う
PoC死の根本原因は、PoCと本番がそもそも別の問いに答えるものだという点を見落とすことにあります。PoCは「動くか？」を検証する場であり、本番は「運用に乗り続けるか？」を勝負する場です。問いが違うのに、「動いたんだから本番もいけるだろう」と地続きで考えてしまう——ここに谷が生まれます。
| 観点 | PoC（実証実験） | 本番（プロダクション） |
|---|---|---|
| 問い | そもそも動くか／効果が出そうか | 運用に乗り続けるか／障害時に耐えるか |
| 利用者 | 協力的な少数の有志 | 全社の不特定多数（ITリテラシーもまちまち） |
| データ量・負荷 | 限定的・きれいなサンプル | 実運用の大量・乱雑なデータ、同時アクセス |
| 失敗の許容 | 失敗してもOK（学びが成果） | 誤動作が業務・顧客・信用に直結 |
| コスト | 無料枠・試用で収まる | 従量課金が利用量に比例して膨張 |
| 担当 | 推進担当が手厚く面倒を見る | 「誰が日々回すか」が宙に浮きがち |
この表の右側にある困難こそが、次章で分解する4つの壁です。PoC死とは、技術的に失敗したのではなく、この4つの壁を越える意思決定が組織内で進まないまま、案件が宙吊りになる現象だと理解するのが出発点です。
本番を阻む4つの壁——運用・責任・コスト・スケール
PoCから本番への谷は、漠然とした「なんとなく進まない」ではありません。分解すると、必ず次の4つのいずれか（または複数）でつまずいています。壁を名指しできれば、打ち手も具体化できます。
壁① 運用——「誰が日々回すか」が決まっていない
PoC中は推進担当が手厚く面倒を見ているため見えませんが、本番では日々の運用主体が必要です。プロンプトの更新、精度劣化の監視、ユーザー問い合わせへの一次対応、モデルやAPIのバージョン変更追従——これらを「誰の業務として、どの工数で」担うのか。ここが空白だと、本番GOの判断が下りません。NOCでいえば、システムを作ったあとに運用設計（Runbook・当番・エスカレーション経路）がなければ本番投入できないのと同じです。
壁② 責任——誤動作したとき、誰が責任を負うのか
PoCでは「実験だから」で済んだ誤出力が、本番では顧客・取引先・社内の意思決定に影響します。AIが誤った回答を返した、機密を含む出力をした、差別的な表現を生成した——そのとき責任の分界点はどこか。最終確認は人間が行うのか、AIの判断をどこまで自動適用してよいのか。この責任分界（responsibility boundary）が曖昧なまま、現場も法務も本番GOにサインできません。
壁③ コスト——PoCの「無料枠」は本番で崩壊する
PoCは無料枠や試用ライセンスで収まっていることが多く、コストが見えていません。しかし本番では利用量に比例して従量課金が膨張します。全社展開で月間トークン消費が10倍・100倍になれば、PoC時の感覚は通用しません。「いくらまでなら本番投資として妥当か」の上限と、コストが想定を超えたときの制御策（レート制限・モデルの使い分け・キャッシュ）を設計しておかないと、財務側がGOを止めます。コストの見える化についてはROI・TCO・Build vs Buy の数値判断モデル（?p=708）が土台になります。
壁④ スケール——同時利用・データ量に耐えられるか
少人数のPoCでは問題にならなかった同時アクセス・レイテンシ・大量データ処理が、全社展開では一気に顕在化します。ピーク時間帯にレスポンスが遅延する、APIのレート上限に当たる、RAGの検索対象が増えて精度が落ちる——これは技術的な検証項目であり、本番投入前テスト（?p=517）で品質保証として詰めるべき領域です。本連載は技術手順そのものではなく、「スケール検証を本番GO判断の前提条件として組織が要求できているか」という意思決定の側を扱います。
| 壁 | つまずきの正体 | 越えるための問い |
|---|---|---|
| 運用 | 日々の運用主体が空白 | 誰が・どの工数で・どの手順で回すか（Runbook化） |
| 責任 | 誤動作時の責任分界が曖昧 | 人間の最終確認をどこに置くか／自動適用の範囲は |
| コスト | 無料枠前提が本番で崩壊 | 許容上限はいくらか／超過時の制御策は |
| スケール | 同時利用・データ量で破綻 | ピーク負荷・レイテンシ・精度を検証したか |
第2回の「効果数字」を、本番GOの根拠に使う
ここで効いてくるのが、第2回（?p=766）で作った効果の数字です。本番GOの意思決定は、最終的に経営判断であり、判断には根拠となる数字が要ります。第2回で「時間削減○時間／月＝人件費換算○円」「ミス削減○件」といった検証に耐える数字を用意できていれば、それがそのまま「本番投資をペイさせられる」根拠の弾になります。
逆に言えば、第2回の効果測定を飛ばしてここに来てしまうと、本番GOの判断材料がなく、「効果はありそうだが投資判断ができない」という、もう一つのPoC死に陥ります。効果測定（第2回）→ 本番GO判断（第3回）という橋渡しを意識的に設計してください。コストとの両睨みで、「本番化に必要な追加投資 ＜ 全社展開で得られる効果」を、レンジ（幅）で示せれば、経営は判断に踏み出せます。
段階展開の設計——カナリア → 部分 → 全社
本番GOが下りたとして、いきなり全社一斉展開（ビッグバン・カットオーバー）は禁物です。これはネットワークの本番投入でも鉄則で、段階展開（フェーズドロールアウト）でリスクを刻みます。AI導入でも同じ作法が有効です。
| 段階 | 対象 | 狙い・確認すること |
|---|---|---|
| カナリア | 協力的な少人数（PoC参加者＋α） | 本番データ・本番権限での挙動確認。問題があってもすぐ戻せる規模に限定 |
| 部分展開 | 1部署・1業務に限定 | 運用主体が回せるか、コストが想定内か、スケールに耐えるかを実地で検証 |
| 全社展開 | 対象業務の全ユーザー | 各段階の合格基準をクリアした上で拡大。監視と運用体制が前提 |
各段階の間には「次に進む合格基準（go/no-go）」を先に決めておきます。「カナリアで重大インシデントゼロ・主要KPIが目標の○割」のように、感覚ではなく数字で判定する。そして全段階を通じて、すぐ前の状態に戻せるロールバック手順を用意しておくこと。NOCのカットオーバーで「切り戻し手順のない変更は実施しない」のと同じで、戻せない展開は本番に出してはいけません。展開後の継続監視はAIエージェントのObservability（?p=698）の発想が土台になります。
「撤退基準」も先に決めておく
段階展開の合格基準とセットで決めておくべきなのが、撤退基準（kill criteria）です。PoC死の隠れた原因の一つは、「いつ諦めるか」が決まっていないために、効果の出ない案件をズルズルと延命してしまうことにあります。これも逆方向のPoC死——「死なせるべきものを死なせられない」状態です。
本番GO判断の前に、「○ヶ月運用して主要KPIが目標の○割に届かなければ撤退・再設計する」「重大インシデントが○回起きたら一旦停止する」といった撤退ラインを明文化しておきます。撤退基準があると、現場は安心して挑戦でき、経営は安心して投資判断ができます。進む基準と退く基準の両方を先に置くことが、塩漬けを防ぐ最大の防御です。過去の失敗事例集（?p=444）も、撤退ラインを引く際の参考になります。
PoC死回避チェックリスト
本番GO判断の前に、4つの壁と展開設計が埋まっているかを確認するためのチェックリストです。
| 分類 | 確認項目 |
|---|---|
| 運用 | 日々の運用主体・工数・手順（Runbook）が決まっている |
| 運用 | ユーザー問い合わせの一次対応・エスカレーション経路がある |
| 責任 | 誤動作時の責任分界点が明文化されている |
| 責任 | 人間の最終確認をどこに置くか（自動適用の範囲）が決まっている |
| コスト | 本番の想定利用量でのコスト試算と、許容上限がある |
| コスト | コスト超過時の制御策（レート制限・モデル使い分け・キャッシュ）がある |
| スケール | ピーク負荷・レイテンシ・大量データでの精度を検証した |
| 効果根拠 | 第2回の効果数字で本番投資をペイさせられる根拠がある |
| 展開 | カナリア→部分→全社の段階と、各段階のgo/no-go基準がある |
| 展開 | 各段階でのロールバック（切り戻し）手順がある |
| 撤退 | 撤退基準（kill criteria）を先に明文化している |
次回予告——第4回「現場とIT部門の温度差・対立」
本番GOの判断ができ、段階展開も設計できた。それでも導入が進まないとき、最後に立ちはだかるのが「人」の問題です。「現場は早く使いたいのにIT部門が慎重すぎる」「IT部門はガバナンスを守りたいのに現場が勝手に使い始める」——この温度差・対立が、本番化の最後のボトルネックになります。次回・第4回では、この現場とIT部門の対立を、どちらかを悪者にせず、両者の正当な懸念を制度設計で橋渡しする方法を扱います。
よくある質問（Q&A）
Q1. PoCが好評だったのに本番に進まないのは、何が足りないからですか？
多くの場合、技術ではなく意思決定の材料が足りていません。「動くか」は証明できても、「誰が日々回すか（運用）」「誤動作時に誰が責任を負うか（責任）」「いくらまで投資できるか（コスト）」「全社負荷に耐えるか（スケール）」の4つが空白のままだと、経営も法務もGOを出せません。まずこの4つの壁のどこでつまずいているかを名指しすることが出発点です。
Q2. 4つの壁のうち、最初に手をつけるべきはどれですか？
組織によりますが、多くは「運用（誰が回すか）」と「責任（誤動作時の分界）」が先送りされがちです。コストとスケールは試算・検証で数字を出せば前進しますが、運用と責任は「誰かが決めないと決まらない」組織判断のため、宙吊りになりやすいからです。本番GO会議の前に、この2つの担当と決裁ラインを先に押さえておくと進みます。
Q3. いきなり全社展開してはいけないのはなぜですか？
本番では、PoCでは現れなかった同時利用・乱雑なデータ・想定外の使われ方が一気に出るためです。一斉展開で問題が起きると影響範囲が全社に及び、戻すのも困難になります。カナリア→部分→全社と影響範囲を刻んで広げ、各段階で合格基準を確認し、問題があればすぐ戻せる状態を保つのが、リスクを抑えた本番投入の作法です。
Q4. 撤退基準を先に決めると、最初から失敗を想定しているようで言い出しにくいのですが。
逆です。撤退基準は挑戦を後押しする安全装置です。「ダメならここで止める」と決まっているからこそ、現場は思い切って試せ、経営は安心して投資判断ができます。撤退ラインのない案件は、効果が出なくても誰も止められず塩漬けになり、それ自体が組織の損失になります。進む基準と退く基準は必ずセットで置いてください。
Q5. 本番化に必要な効果の数字は、どこで用意すればよいですか？
本連載第2回「効果が説明できない／ROIが見えない」問題（?p=766）で扱った、現場が無理なく続けられる軽量計測の数字がそのまま使えます。時間削減を人件費に換算し、ミス削減や品質向上を金額・リスクに翻訳した数字を、レンジ（幅）で示す。これを本番投資のコストと突き合わせれば、本番GOの判断材料になります。
まとめ——「動いた」と「乗り続ける」の谷を、意思決定で越える
PoC死は技術の失敗ではありません。「実証では動いた」を「本番で回り続ける」へ橋渡しする意思決定が組織内で進まないがゆえに、案件が宙吊りになる現象です。要点は3つです。
1. 谷を4つの壁に分解する。運用（誰が回すか）・責任（誤動作時の分界）・コスト（無料枠の崩壊）・スケール（同時利用・データ量）。漠然とした停滞を、名指しできる壁に分けることが第一歩です。
2. 効果数字を本番GOの弾にする。第2回で作った検証に耐える数字を、本番投資をペイさせる根拠として使う。効果測定と本番判断は地続きで設計します。
3. 段階展開と撤退基準を先に置く。カナリア→部分→全社と影響範囲を刻み、各段階のgo/no-go基準とロールバック手順、そして撤退基準を先に決める。これはNOCの本番投入（切り戻し前提・段階展開）の作法そのものです。
PoCは「動くか」のゴール。本番は「運用に乗り続けるか」のスタート。両者は別の問いだと理解し、4つの壁を越える意思決定プロセスを先に設計しておく——これが、好評だったPoCを塩漬けにしないための分かれ目です。
参考リンク（連載・関連記事）
- 【連載①】企業AI導入「つまずき」解決シリーズ——「導入したのに誰も使わない」問題（?p=758）
- 【連載②】企業AI導入「つまずき」解決シリーズ——「効果が説明できない／ROIが見えない」問題（?p=766）
- AIシステムの本番投入前テスト・品質保証ガイド（?p=517）
- AIエージェントのObservability・監視基盤ガイド（?p=698）
- ROI・TCO・Build vs Buy——AI導入の数値判断モデル（?p=708）
- AIプロジェクト失敗パターン集（?p=444）
免責事項：本記事は2026年6月時点の一般的な情報提供であり、特定のAI導入プロジェクトの成功・効果・投資対効果を保証するものではありません。また、法務・会計・税務上の助言ではありません。本番展開の判断基準・責任分界・コスト管理・撤退基準は、自社の業務・体制・関連法令・契約条件に照らして設計し、必要に応じて社内の情報システム・法務・経営企画部門や専門家にご相談ください。
コメント