AI導入がPoCで止まる理由を仕様と運用に分ける¶

対象 / ポイント

対象: AI導入をPoCから本番へ進めたいが、現場定着、承認、運用負荷で止まりたくない推進担当者。

ポイント:

PoCは「AIが答えを出せるか」を見る場で、本番は「仕事として回るか」を見る場だ。
仕様で証明したことと、運用で決めることを混ぜると、承認直前で止まる。
本番化の判断には、成功条件だけでなく停止条件と撤退条件を入れる。

問い合わせ文をAIが分類した。正答率は高い。デモも通った。現場の反応も悪くない。

それでも本番化の会議で、話が止まる。

「誰が毎朝ログを見るのか」「分類体系が変わったら、誰がプロンプトと評価データを直すのか」「誤分類が増えたとき、どの時点で止めるのか」

これはモデル精度の問題ではない。PoCで証明した仕様と、本番で必要な運用がずれている。

この記事の問いは1つ。AI導入がPoCで止まるとき、何を仕様に書き、何を運用として決めれば本番へ進めるのか。

先に結論を置く。PoC脱出に必要なのは、より大きなデモではない。「AIが何をできるか」という仕様と、「誰が、いつ、どう直すか」という運用を分けることだ。この分離がないPoCは、成功しても本番に移らない。

PoCは仕様を証明するが、運用を証明しない¶

PoCの合格は、本番化の合格ではない。PoCは限られたデータ、限られた利用者、限られた失敗パターンの中でAIの可能性を見る。本番は、データの揺れ、担当者の交代、例外処理、監査、コストを含む。

問い合わせ分類のPoCなら、評価対象は「カテゴリを当てられるか」になりやすい。しかし本番では、未定義カテゴリ、季節要因、製品名変更、顧客クレーム、監査ログが出てくる。ここで必要なのは精度表だけではない。運用表である。

観点	PoCで見えること	本番で決めること
入力	サンプルデータで動くか	例外データを誰が拾うか
出力	正答率が十分か	誤りを誰が修正するか
評価	テストセットで勝てるか	いつ再評価するか
変更	初期設定が機能するか	業務変更時に誰が更新するか

OpenAIのEnterprise AIレポートは、企業利用が実験から本番デプロイへ移るにつれて、API利用が自動化された業務フローに接続される傾向を示す¹。接続先が業務フローになるほど、AIの品質はモデル単体では測れない。入力、承認、例外、ログまで含めて初めて、仕事として評価できる。

仕様と運用を混ぜると、承認者が増えるだけになる¶

仕様と運用を混ぜたPoCは、承認会議で質問を増やす。精度、UI、プロンプト、監査、担当、費用が同じ資料に並び、どの論点が未決なのか見えなくなるからだ。

仕様に書くのは、AIシステムが何をするかである。運用に書くのは、人と組織がどう回すかである。この2つを分けると、止まっている理由が見える。

項目	仕様として書く	運用として決める
対象業務	問い合わせ分類を行う	分類体系の変更者
出力形式	カテゴリ、根拠、例外フラグを返す	例外フラグの確認担当
品質基準	正答率、再現率、禁止出力	月次評価と改善サイクル
連携範囲	CRMへ候補を渡す	誤登録時の差し戻し手順
コスト	1件あたりの推論コスト	予算超過時の停止判断

この表は責任の押し付け合いを防ぐためではない。未決事項の種類を分けるために使う。仕様が未決なら開発チームが詰める。運用が未決なら業務責任者、情報システム、監査担当で決める。

McKinseyの2025年調査は、企業が生成AIの実験から大規模展開へ移る過程で、価値を出すにはワークフロー再設計や管理実務が必要だと整理する²。これは「ツールを入れれば定着する」という話ではない。 PoCの外側にある管理の仕事を設計できるか、という話である。

本番化Gateは「合格条件」ではなく「停止条件」まで持つ¶

本番化の判断に成功条件だけを置くと、運用開始後に止め方がなくなる。必要なのは、Go / Hold / Stop の3つを最初から持つGateだ。

問い合わせ分類なら、次のように置ける。

Go: 主要カテゴリの正答率が基準を満たし、例外フラグの確認担当が決まっている。
Hold: 未定義カテゴリが一定数を超え、分類体系の更新が必要である。
Stop: 顧客影響のある誤分類が連続し、承認前の人間確認に戻す。

この3つがないと、AI導入は「始める判断」だけを持ち、「止める判断」を持たない。本番で怖いのは、初日の失敗よりも、小さな失敗が日次処理に混ざり続けることだ。

NIST AI RMFは、AIリスク管理を Govern、Map、Measure、Manage の4機能で整理する³。 PoC脱出で特に効くのは Manage だ。測定したリスクに対して、受容、緩和、移転、回避などの処置を決める段階だからだ。

この考え方を現場に落とすなら、本番化Gateには次の4列を置く。

Gate	見る指標	判断者	次の動き
Go	品質、運用担当、ログ確認	業務責任者	限定範囲で開始
Hold	未定義カテゴリ、例外率	業務責任者と開発者	仕様と運用を修正
Stop	顧客影響、法務影響	責任者と監査担当	手動運用へ戻す

Gateは稟議の飾りではない。AIを止められる権限を、開始前に作るための設計である。

PoC脱出の最小単位は1業務、1出力、1改善サイクル¶

AI導入をPoCから出す最小単位は、全社展開ではない。 1業務、1出力、1改善サイクルである。

たとえば問い合わせ分類なら、最初の本番範囲を「法人顧客の一次分類」に絞る。出力は「カテゴリ候補、根拠、例外フラグ」だけにする。改善サイクルは「毎週20件の例外を見て、分類体系と評価データを更新する」に固定する。

この狭さには意味がある。本番化の初期段階で広げるべきなのは対象範囲ではなく、運用の観測点だ。誰が見るか、何を直すか、いつ止めるかを小さく回せる状態を作る。

ISO/IEC 42001は、AIマネジメントシステムの国際規格として、組織がAIの方針、目的、リスク、統制を管理する枠組みを示す⁴。規格そのものをそのまま小規模PoCへ持ち込む必要はない。ただし、AIを単発プロジェクトではなく管理対象として扱う発想は、PoC脱出の設計と相性がよい。

最後に、PoC資料に残すべき1枚を決める。

1枚で示すこと	書く内容
仕様	AIが受け取る入力、返す出力、使わない用途
運用	確認者、改善担当、ログ確認周期
Gate	Go / Hold / Stop の条件
学習	例外から何を更新するか

この1枚が書けないなら、まだ本番化の前ではない。 AIが動くことは分かった。仕事として回るかは、まだ分かっていない。

まとめ: PoCの成功を本番の設計に変換する¶

AI導入がPoCで止まる理由は、失敗したからとは限らない。むしろPoCが成功した後に、仕様と運用の差が見える。

PoCで示すのは、AIが特定の入力に対して有用な出力を返せることだ。本番で必要なのは、その出力を誰が確認し、どう直し、どの条件で止めるかである。ここを混ぜると、承認者が増え、資料が厚くなり、導入は止まる。

Enterprise AIの導入で問うべきなのは、「このAIは賢いか」だけではない。「このAIを業務として直し続けられるか」である。 PoC脱出は、技術の勝利宣言ではない。運用を引き受ける組織設計の開始点だ。