概要：PoCの精度があっても承認で止まる理由と解決の方向性
PoCの精度が良好でも、本番稟議や承認で必ず止まることが現場ではよくあります。現場は「出力をそのまま使えば効率化できる」と言い、法務・監査は「説明できなければ人の最終承認が必要」と言う。どちらかの極に寄せた二択では現場運用は回りません。本稿では「業務影響」「改変余地」「説明性（監査性）」の3軸でAI出力を階層化し、会議で即答できる短いルールと数値例を提示します。
よくある誤解：『全部自動化』か『全部人レビュー』か
結論：二択は現場で機能しない。黒箱をそのまま運用すれば監査で差し戻しが発生し、全件人レビューにすればSLAとコストが破綻します。実務的には業務ごとに受け継ぎルールを作り、会議の出口で一行宣言（レビューレベル）を出せるようにするのが現実的です。
判断軸：業務影響×改変余地×説明性で短いルールを作る
3軸を定量化し、各軸に少なくとも1つの数値閾値を置くと「誰が何をするか」を即答できるようになります。軸の定義（会議・PoCでの使い方）は以下の通りです。
- 業務影響：被害想定額×想定頻度（月間）で算出。例：30,000円/件×10件/月＝300,000円/月。閾値例：影響額>100万円/月は高影響。
- 改変余地：出力をどこまで現場で修正できるかを3段階で定義（微修正のみ／手順変更を伴う修正／フロー再設計）。運用ルール例：微修正は運用担当で可（ログ必須）、手順変更は承認必須。
- 説明性（監査性）：ログ取得率（成功取得数/総試行数）、ログ応答時間の中央値、再現性（同一入力での出力一致率）で評価。閾値例：ログ取得率≥95%、応答中央値<10秒、再現性>95%を目安。
レビュー分類（運用で使う短い定義）
- レベルA（自動実行）：低影響・改変余地小・説明性十分。自動化＋週次モニタリング（担当者とチェック件数を明記）。
- レベルB（ライトチェック）：影響中・改変余地限定・説明性確保可能。サンプリング監視（日次/週次）と閾値超過時の自動昇格ルールを設定。
- レベルC（承認必須）：影響大または説明性不十分。承認者・承認手順を明記し、必須ログ保存・差し戻し手順を定義。
- レベルD（停止／要改修）：影響甚大または説明不能。運用停止か設計改修を要求。
各セルに具体的な数値閾値（例：例外率<0.5%、被害額<100k/件、ログ取得率>95%）を入れて、PoC時は信頼区間を意識したサンプル設計（最低数十〜百件）で測定することが重要です。
実務テンプレ集（そのまま使える1ページフォーマット）
場面別の1ページテンプレを用意しておくと合意形成が早まります。下は現場で即コピー＆利用できるフォーマット例です。
会議合意シート（1枚） — 埋めた例
- 業務名／業務オーナー：カスタマー返金判定（顧客サポート部長）
- 対象プロセス：問い合わせ受領→AI一次判定（返金/不返金）→運用担当が例外のみ確認
- レビュー分類→レビューレベル：影響中（想定被害額30,000円/件、想定頻度40件/月→1,200,000円/月）、改変余地：微修正可（ログ記録必須）、説明性：ログ取得率98% → レベルB（ライトチェック）
- 判定根拠（数値）：期待削減コスト：月50万円、例外率（PoC）=0.8%、説明ログ取得率=98%、ログ応答中央値=1.2秒
- 工数見積り（例）：平均レビュー時間＝1件あたり5分。想定例外件数＝40件/月 → 月間レビュー時間＝200分（約3.3時間）→ 0.02 FTE（160h/月換算）。
- 次アクション：PoC→本番移行（前提：週次サンプリング50件で例外率<0.5%を3週連続で確認）責任者：運用マネージャー、期日：30日以内
稟議テンプレ（承認用、1ページ）
- 件名・目的：返金判定自動化による処理効率化・期待削減コスト月50万円
- レビューレベル：B（ライトチェック）と理由：被害想定30k/件、PoC例外率0.8%（目標0.5%以下）、説明ログ取得率98%
- 承認責任者：業務オーナー（常時）／代行：部長、承認基準：例外率<0.5%かつ説明ログ取得率>95%
- SLA・ログ保持：通常応答2営業日、例外対応24時間内、ログ保持期間：1年、エスカレーション経路明記
- 注記（工数根拠）：月想定処理件数×例外率×平均レビュー時間で月間工数を明記
問い合わせ返信テンプレ（利用者向け）
- 標準返信（短文）：本件はAIによる一次判定に基づく提案です。判定根拠はログID=XXXXで参照可能です。異議は受領から7営業日以内に申請ください。
- 参照ログ提示：ログID・参照画面・担当者連絡先を即提示する手順を明記（ワンライナーで操作手順を記載）。
- 異議申立て時の暫定措置：人による再評価（対応期限：5営業日）を実施する旨を明示
PoC評価シート（1ページ）
- 評価対象業務・期間・データ量：例：30日・1,000件
- 主要指標：精度（F1等）、例外率、平均処理時間、説明ログ取得率（成功数/総試行数）
- 閾値（採用基準・例）：例外率<0.5%、被害想定額<100k/件、説明ログ取得率>95%
- 合否判定と次ステップ：閾値満たせばレベルA/Bへ、未達は設計改修またはレベルC判定
運用設計チェックリスト（1ページ）
- ロール：運用担当／承認者／監査連絡先の明記（氏名・代行）
- SLA：通常処理時間・例外処理時間・エスカレーション時間（例：例外対応24時間内）
- ログ方針：何を・どの粒度で・どれだけ保持するか（保存場所・保持期間を明記）
- 改変ルール：微修正は運用担当で可（ログ記録）、フロー変更は承認必須
- モニタリング計画：サンプリング頻度・閾値超過時の自動アクション（レベル引上げ）
テンプレは配布してその場で埋めること。空欄のまま出すと差し戻しの温床になります。
失敗パターン：現場でよく止まる2つの事例
結論：停滞の主因は「判定軸の未定義」と「運用コストの過小評価」です。事前に閾値と工数見積りを用意すれば多くの停止を防げます。
事例A：PoC高精度だが説明ログ不足
PoCで精度90%を確認したが、ログの粒度が不十分で監査が承認せず本番化が頓挫。回避策はPoC設計段階で最低限の説明ログ（誰が、いつ、入力、AI根拠スニペット）を定義し、ログ取得率をPoCで測ることです。
事例B：全件人レビューでSLA違反
リスク回避で全件人レビューにした結果、例外が集中して処理遅延が常態化。対策は例外率を測り、レビュー工数を数値化すること。例：月処理件数20,000件、例外率0.5%→例外100件/月、平均レビュー時間5分→500分/月（約8.3時間）=0.05 FTE。これで人員計画とSLAが立てられます。
まとめ：現場で回すための実行3ステップと見送り条件
導入判断：レビュー分類表で各業務を「自動化可／ライトチェック／承認要／禁止」に分類する。判定は業務影響、改変余地、説明性の3軸で行い、各セルに最低1つの数値閾値を置いてください。
実行3ステップ
- レビュー分類表を1枚作る（会議合意シート形式で業務ごとに埋められるように）。
- 低影響・改変余地小・説明性確保可能な業務を選びPoCで閾値と例外率を測る（PoC評価シートを使用）。
- 測定結果とSLAに基づき段階的にスコープ拡大。改善が確認できなければ拡張を保留する。
見送る条件（中止判断）
- 説明性を確保するための追加コストが期待便益を上回ると判断される場合。
- 継続的に例外率が閾値を超過し、運用工数を確保できない場合。
- 重大な業務影響が想定され、かつ説明性・改修余地が確保できない場合（設計改修か別方式を検討）。
自己採点チェック（0〜5で評価）
- ① レビュー分類表が1枚ある（0:なし〜5:現場で常時使える）
- ② PoCで例外率・ログ取得率を測定済み（0:未測定〜5:閾値下回り3週連続確認）
- ③ 例外レビューの平均時間を見積り、月間工数を算出済み（0:未算出〜5:運用予算に反映）
- ④ 稟議テンプレに承認基準（数値）とSLAが明記されている（0:未記載〜5:決裁済）
- ⑤ 問い合わせ時のログ参照手順と異議申立て手順が定義されている（0:未定〜5:現場で運用中）
合計20点満点で、15点以上なら「実装フェーズに進める目安」、10点未満は設計やPoC測定を再実施してください。
最後に一言：たった一枚の「レビュー分類表」と数値での工数見積りが、稟議の差し戻しと承認停滞を防ぎ、AI導入を現場で前に進める鍵になります。
コメント