PoC は終わったが本番に進めない、を防ぐ
PoC が「達成」で終わったあと、なぜか本番昇格に進めない。よく起きる現象です。原因は、PoC のスコープと本番運用のスコープが一致していないからです。
PoC は 1 業務・5 名以下の小さな範囲で検証します。本番は数十〜数百名で動かします。スケールが 10 倍になれば、品質劣化・運用負荷・コスト構造のすべてが変わります。PoC の数字をそのまま本番に当てはめると、全社展開後に破綻するか、慎重さが過ぎて結局展開しないかのどちらかになります。
本番昇格は、PoC とは別の判定軸で行います。
本番昇格の 5 つの判定軸
PoC が達成で終わっても、本番に進める前に次の 5 つを評価します。
- 1. 効果の再現性：別の担当者・別の月でも同じ効果が出るか
- 2. 失敗のリカバリ性：誤回答や事故が起きたとき、何時間で復旧できるか
- 3. 運用の継続性：担当者が異動／退職しても運用が続くか
- 4. コストの予測性：利用量が 10 倍になったときのコストが計算できるか
- 5. ガバナンスの整合性：全社の AI 運用ルール（許可ツール／禁止データ／監査）に乗っているか
5 軸すべてが「黄」以上で本番昇格、1 つでも「赤」があれば再 PoC か別案検討に戻します。「赤」を残したまま本番に進めると、半年以内にどこかで事故ります。
効果の再現性をどう測るか
PoC は通常、業務を一番把握している担当者と、最も協力的な担当者の組み合わせで進みます。本番では、ベテランも新人も、AI に懐疑的な人も使います。
再現性の確認には、PoC を終えた後に「PoC 不参加の担当者 3 名」で 2 週間の追試をします。結果が PoC と同等なら再現性は確保されています。同等でなければ、PoC で効果が出た要因が「特定の担当者の運用力」に依存していた可能性が高く、本番展開すると効果が下がります。
失敗のリカバリ性
AI は確率的に動くため、誤回答や予期しない出力が必ず発生します。本番昇格前に、次のリカバリ手順を用意します。
- - 誤回答を検知する仕組み（監視ログ／顧客通報／定期サンプリング）
- - 影響範囲を特定する手順（誰に届いたか／どこまで広がったか）
- - 復旧と謝罪の手順（社内通達／顧客連絡／再発防止メモ）
これらの手順を文書化していない状態で本番昇格すると、最初の事故で対応が混乱し、組織として「AI は危ない」という空気が固定化します。
コストの予測性
PoC のコストは少額です。本番では利用量が桁違いになり、トークン料金・人件費・運用工数のいずれかが膨らみます。
本番昇格前に、次の 3 シナリオでコストを試算します。
- - 標準ケース：想定利用量で月額いくら
- - 倍ケース：想定の 2 倍利用された場合いくら
- - 上限ケース：これ以上は予算で止める線をいくらに置くか
上限ケースを最初に決めておかないと、利用が広がり始めたあとで止める判断ができません。「便利になっているのに止められるか」が、半年後の悩みになります。
ガバナンス整合性
部署の本番昇格は、全社の AI 運用ルールに乗っていなければなりません。前シリーズ（部署別 AI 運用）で扱った「許可ツール／禁止データ／承認線／監査／例外プロセス／改定リズム／適用範囲」の 7 項目に整合しているかを最終確認します。
整合していない箇所があれば、ルール側を改定するか、本番昇格を遅らせます。「特例で本番昇格」を許すと、ルールが現場ごとに崩れていきます。
次回予告
次話からは、本番設計の各論に入ります。第4話は既存システム接続パターン（API／ファイル連携／RPA／コピー＆ペースト）を扱います。
この回のまとめ：
- - PoC と本番は判定軸が異なる。本番は 5 軸で評価する。
- - 再現性／リカバリ性／継続性／コスト予測性／ガバナンス整合性。
- - 1 つでも赤があれば再 PoC か別案。
- - PoC 不参加の担当者で追試して再現性を測る。
- - 標準・倍・上限の 3 シナリオでコスト試算する。
- - ガバナンスの「特例本番昇格」は禁じ手。