生成AI PoCの本番移行チェックリスト｜Go/No-Goを決める35項目

生成AIのPoCが動いたあと、最も難しいのは「本番へ進めてよいか」を決めることです。

デモが成功した、回答精度が高かった、利用者の反応がよかった。それだけでは本番化の判断材料として足りません。本番では、業務価値だけでなく、失敗時の影響、参照データ、権限、監視、費用、責任分界まで同時に成立させる必要があります。

このページは、生成AI PoCをGo / 条件付きGo / No-Goのどれにするかを、会議でそのまま確認できる35項目に落とした実務用チェックリストです。

詳しい背景を先に読みたい場合は「生成AIのPoCが本番導入で止まる7つの理由」を参照してください。このページでは説明より判定を優先します。

使い方

各項目を ○ / △ / × で評価します。

○：根拠と担当があり、本番運用できる
△：条件または期限付きで解消できる
×：本番前に解消が必要

重大事故につながる項目に×が1つでもある場合、総合点だけでGoにしないことが重要です。

1. 業務価値

[ ] 対象ユーザーと対象業務が明確である
[ ] 現行業務の時間・コスト・品質を基準値として持っている
[ ] AI導入後に改善させるKPIを1〜3個に絞っている
[ ] AIを使わない代替案と比較している
[ ] PoCの成功条件ではなく、本番の成功条件を定義している

2. 回答品質・評価

[ ] 代表ケースだけでなく失敗しやすい境界ケースを評価している
[ ] 正答率以外に、重大誤答の種類と件数を把握している
[ ] 出典が必要な業務では、回答と根拠を追跡できる
[ ] モデルやプロンプト変更後に同じ評価を再実行できる
[ ] 人が最終確認すべき回答範囲を決めている

3. 安全性・責任

[ ] AIが実行してよい操作と禁止操作を明文化している
[ ] 誤回答・誤操作時に止める方法がある
[ ] 最終的な業務責任者が決まっている
[ ] インシデントの報告先と初動手順がある
[ ] 高リスク判断をAIだけで確定させない設計になっている

4. データ

[ ] AIが参照してよい情報源を限定している
[ ] 古い文書・重複文書を識別できる
[ ] 情報ごとの更新責任者または更新ルールがある
[ ] アクセス権を無視して検索・回答しない
[ ] 参照データ更新後に再評価する手順がある

5. 権限・セキュリティ

[ ] 最小権限で接続している
[ ] read / create / update / delete / send 等の操作権限を分けている
[ ] 秘密情報や認証情報をプロンプト・ログへ残さない
[ ] 外部サービスへ送信されるデータ範囲を把握している
[ ] 退職・異動・権限変更時にアクセスを止められる

6. 運用

[ ] 誰が日常監視するか決まっている
[ ] モデル・API・料金・仕様変更を検知する方法がある
[ ] 障害時にAIなしの業務へ戻せる
[ ] ログから「誰が・いつ・何をしたか」を追跡できる
[ ] 本番後の品質を定期的に再評価する

7. コスト・継続性

[ ] 1回・1ユーザー・1業務あたりの費用を把握している
[ ] 利用量が増えた場合の月額上限を試算している
[ ] 人による確認・運用コストも含めている
[ ] ベンダーやモデル変更時の移行難易度を把握している
[ ] 効果が出ない場合の停止条件を決めている

Go / No-Go判定

Go

重大項目に×がなく、残った△に担当・期限・検証方法がある状態です。

条件付きGo

限定ユーザー、限定データ、read-onlyなど、事故範囲を明確に小さくしたうえで本番相当の利用を始めます。△を放置したまま対象だけ拡大しないことが条件です。

No-Go

次のいずれかが未解決なら、原則として本番化を急ぐべきではありません。

責任者がいない
機密情報のアクセス制御ができない
重大誤答を検知・停止できない
本番効果を測るKPIがない
障害時に業務を戻せない

会議で最後に確認する5問

このAIが間違えたとき、最大で何が起きるか？
その事故を誰が検知し、誰が止めるか？
本番化で改善する業務KPIは何か？
3か月後に続ける／止めるを何で判断するか？
AIを使わない方法より本当に優れているか？

このチェックリストは、AIの性能を採点するためではなく、業務として本番運用できる状態かを確認するためのものです。PoCの完成度を上げ続けるより、責任・データ・権限・運用・停止条件を明確にするほうが、本番移行の判断は速くなります。

生成AI PoCの本番移行チェックリスト｜Go/No-Goを決める35項目