PoCを終わらせるために、成功条件と停止条件を先に決める
試作品が動いたことと、導入できることを分けて判断します。
試作品が動いても、本番へ進めるとは限りません。この記事では、検証する仮説・評価項目・終了日・停止条件をそろえ、継続・再検証・終了を判断するメモを作ります。PoCはここでは、本番化の前に限定した条件で実現性や価値を確かめる検証として扱います。
「AIが賢いか」ではなく、1つの仮説を置く
架空の社内FAQ支援なら「担当者が根拠文書を探して確認する時間を減らせる」が仮説です。生成だけでなく原文照合と修正を含め、従来の探し方と比較します。許可された架空資料と例題を使い、社内公開や本番データへの接続は含めない試験案にします。
英国政府のアルファ段階のガイドは、難しい前提を検証するのに必要な範囲へ絞り、次へ進む案を判断する考え方を示しています。PoCとアルファが同じ制度という意味ではありません。本稿では、機能を増やす前に判断材料をそろえる視点を参考にします。
条件を先に決め、結果を見てから変更しない
| 評価 | 確認すること | 判断への扱い |
|---|---|---|
| 必須条件 | 権限外情報を返さない、根拠原文へ戻れる | 違反時は試験停止・調査。速さで相殺しない |
| 回答品質 | 原文にない条件を足さない。対象外は答えを創作しない | 誤りの内容・重大度を記録し、事前基準と照合 |
| 仕事の時間 | 準備・検索・確認・修正の総時間 | 同程度の例題と従来手順で比較。不足なら判断保留 |
これは基準の作り方の例で、共通の合格数値ではありません。品質と時間の閾値、評価件数、権限試験の範囲は関係者が合意してください。試験で違反が見つからなくても、あらゆる入力や本番環境で安全と証明したことにはなりません。
コピーして使う:検証計画
検証名・版/検証する仮説1つ:
範囲:資料・例題・役割・環境・実施しないこと
従来の比較手順:
評価セット:正常/答えなし/旧版/権限なし
必須条件・品質条件・時間条件と合意者:
記録:各ケースの入力、原文、出力、確認結果、時間、費用
開始日・終了日(実際の日付を設定):
費用・時間の上限と計測方法:
実施担当/確認者/停止を判断する人:
停止条件:未許可情報、権限外の表示、重大な誤り、上限到達等
停止後:接続・共有を止める方法、影響確認、社内報告先
戻し方:従来手順・原本を保持。結果ログの取扱いは社内ルールに従う
終了時の判断者・判断日:
終了時の到達例
結果の判断メモ
実施した範囲・件数/未実施の範囲:
必須条件:満たした/違反/未確認(証跡:)
品質と総時間の結果:
失敗・例外・停止の履歴:
仮説について分かったこと/分からないこと:
結論:次段階を検討/条件変更して再検証/終了
理由と次に必要な承認・確認:
再検証する場合の変更点と、新しい終了日:
架空の判断例は「通常の質問では時間が短くなったが、権限試験が未実施なので次段階は保留」です。成功例だけで導入可としません。再検証するなら条件の変更を別の版に残し、元の結果を書き換えないようにします。本番化には運用・権限・保守・障害時対応など別の確認と承認が必要です。
結果の確認ポイント
- 終了日と判断者があり、判断保留の理由まで残せるか。
- 品質・時間を測る対象範囲が同じか。失敗ケースを除外していないか。
- 止める人と止め方、影響確認・報告先を具体的に決めたか。
- 検証範囲の合格を、本番や全社への適用保証と混同していないか。
今日試すこと
試したい案の仮説を1つに絞り、未実施なら判断を保留する項目を1つ書きます。次に終了日・停止担当・停止後の行動を埋め、関係者に確認してから試行してください。
参考資料
GOV.UK:アルファ段階の進め方(公式資料、2026年10月3日確認)。FAQの検証例・評価表・計画と判断メモはTOMONIの編集上の提案で、実際のPoC結果ではありません。