AI PoCは何をもって成功とする？評価データ・合格基準・運用移行条件

AI PoCが失敗する理由の一つは、最初に「何をもって成功とするか」を決めず、最後に自然なデモを見て判断することだ。デモは質問を選べば良く見える。だが本番で使う業務業務課題、データ、利用者、例外、費用、時間を代表しているとは限らない。

成功条件は、PoCを始める前に業務責任者と決める。AWSやMicrosoftの評価ガイドも、評価データセット、正解データやレビュー方法、指標、反復評価を扱う。NIST AI RMFの測定も、主張でなく根拠・証跡を評価へ結ぶ考え方を取る。

開始前のPoC 評価票

合格基準、許容する費用・待ち時間、責任者、停止条件は評価を始める前に決める。一方、実測値、観察結果、合否判定は実行後に記入し、未実行の結果を埋めない。

項目	決める内容	責任者	合格/停止の条件
業務業務課題	何を誰の代わりに助けるか	業務責任者	業務課題外のデモを含めない
評価用データ	代表例、難例、禁止例	業務・データ担当	参照元と版を残す
正しさ	正解、引用、形式、レビュー方法	評価担当者	人が判定できないなら止める
安全性	出してはいけない内容、権限、外部送信	セキュリティ	一件でも重大違反なら停止
速度・費用	許容待ち時間、1件当たりの上限	業務・調達	超過時の縮小案
運用	ログ、例外、サポート、復旧手順	IT	責任者がいないなら本番へ進まない

評価指標は一つにしない。回答の正しさが高くても、引用が追えない、費用が読めない、禁止データが出るなら、業務導入の合格にはならない。

デモは、関係者に業務の可能性を見せるために使える。ただし合否用評価用データとは分ける。合否用には、うまく答えられる例だけでなく、答えてはいけない例、情報が足りない例、古い文書、矛盾した指示、長い入力を入れる。

評価担当者も実装者だけにしない。業務の正しさを判断する人、セキュリティ・プライバシーを確認する人、運用できるかを見る人が、何を確認するかを分ける。

停止は失敗の印ではない。次のどれかが起きたら、規模を広げず原因を調べる。

次の表は組織が採用できる判定ルールの例であり、実行済みPoCの成績ではない。評価前に基準と判定者を確定し、評価後は生の観察記録へたどれる結果だけを記入する。

判定	条件の例	次の行動
継続：限定導入へ進む	必須の業務・安全・費用基準を満たし、重大欠陥がなく、運用担当者と復旧方法が決まった	対象業務と利用者を限定して導入し、監視を続ける
PIVOT：条件を変えて再評価	業務価値は残るが、入力範囲・構成・利用方法の変更が必要。重大な安全上の問題を放置していない	変更理由と再評価対象を記録し、別の版として試験する
停止：中止または保留	許可がない、重大違反がある、価値を説明できない、費用や運用責任を解決できない	利用拡大を止め、原因と再開条件を残す

結果欄には評価データの版、構成・設定、実行日時、観察結果、根拠ファイル、判定者をひも付ける。合格基準を結果を見た後に都合よく変えない。基準を変更する場合は変更理由を承認し、別版として再評価する。未実行の速度、費用、正答率、合否は入力しない。

PoCの成果は「AIがすごい」と示すことではない。どの業務で、どの根拠・証跡がそろえば進め、どの条件なら止めるかを組織が判断できる状態である。