人が確認するから安全、では足りない――AI例外キューの設計

月曜の朝、担当者が画面を開くと、AIが夜間処理した案件の「要確認」が180件並んでいる。重要な案件も、入力形式が少し違うだけの案件も、同じ順番で積まれています。自動化したはずなのに、締め切りが近づくほど確認は粗くなり、最後はまとめて承認する。こうなれば、人間による確認は安全策ではなく、処理待ちを隠すラベルです。

AI運用で本当に設計すべきなのは、「人を介在させるか」という二択ではありません。どの案件を、どの根拠とともに、誰へ、いつまでに渡すかです。本稿では、人に戻す案件を扱う仕組みを「例外キュー」と呼びます。結論を先に言えば、例外キューは画面の機能ではなく、優先順位、判断材料、権限、期限を束ねた業務プロセスとして設計する必要があります。

「人が見る」を統制に変える

デジタル庁の生成AIガイドライン第2.0版は、出力の適切さを職員が判断するかどうかをリスク判定の軸に置き、確認なしの自動返信を高リスクの例として示しています。一方で、出典を容易に参照できるといった利用の具体像も含め、リスクを総合判断するよう求めています。[1] つまり、確認者を置くだけでは足りず、確認が実際に機能する条件まで問われています。

経済産業省・総務省の「AI事業者ガイドライン」は2026年3月に第1.2版へ更新され、危害の大きさと発生可能性に応じて対策の程度を変えるリスクベースの考え方を掲げています。[2] これはレビュー業務にもそのまま当てはまります。影響の小さい案件まで全件を同じ深さで読むと、重大案件に使う時間が減ります。

現実的な選択肢は三つあります。全件確認は説明しやすい反面、件数が増えると追認になりがちです。信頼度の閾値だけで振り分ける方法は実装しやすいものの、低確率でも損失が大きい案件を拾えません。最も扱いやすいのは、業務上の影響を先に分類し、その中でモデルの信頼度や検証結果を使う方法です。

振り分けは「確信度」より業務影響から始める

例外キューへ送る条件は、少なくとも次の四つに分けます。

1. 結果の重大性

誤りが顧客への通知、支払い、契約、権限変更に直結するなら、モデルが高い確信度を返しても自動確定の対象にしません。反対に、社内文案の言い換えで、送信前に編集できるなら、標本確認から始められます。確信度はモデル内部の尺度であり、損失額や顧客影響を表す数字ではありません。

2. やり直し可能性

取消や再送ができ、影響範囲を特定できる処理は、自動化の余地があります。いったん公開すると回収が難しい情報、取り消しても相手の判断に残る通知、物理作業を伴う指示は、先に人へ回します。ここで見るべきなのは「失敗する確率」だけでなく、「失敗後に戻せるか」です。

3. 期限と滞留コスト

同じ重要度でも、10分以内に判断が必要な不正検知と、翌営業日までに確認すればよい報告書では、キューを分ける必要があります。期限を過ぎたときは自動承認せず、手作業へ戻す、処理を止める、上位担当へ通知する、のいずれかを事前に決めます。

4. 根拠の充足度

入力原文、参照資料、適用した規則、検証結果がそろわない案件は、出力の見た目が自然でも保留します。たとえば請求書の処理なら、抽出値だけを見せるのではなく、該当箇所の画像、単位、取引先マスターとの照合結果を同じ画面に出します。判断材料を探しに別画面を往復する設計では、確認時間を短くできません。

レビュー画面には「判断の理由」を運ぶ

担当者へ渡す最小単位は、AIの回答文ではなく「レビューカード」です。カードには、元の入力、AI出力、例外になった理由、参照根拠、システムとモデルの版、影響を受ける対象、選べる操作をまとめます。操作は承認と却下だけでなく、修正して続行、担当変更、追加資料の要求、処理停止を用意します。

NISTのAIリスク管理フレームワークの実践資料は、人間による監督の程度、上書き操作、報告された誤り、応答時間、エスカレーション、実行可否の決定を記録・測定するよう提案しています。[3] 例外キューでも、正解率だけでなく、到着件数、滞留時間、差し戻し率、修正理由、期限超過を残すべきです。これらがなければ、閾値を変えた結果が改善なのか、単に人へ負担を移したのか判断できません。

GoogleのPeople + AI Guidebookも、利用者が出力を編集したり機能を止めたりできること、導入初期には通常の手作業を安全な退避経路として残すことを勧めています。[4] ただし、手作業への退避は無制限の受け皿ではありません。誰が引き受け、どの期限で処理し、容量を超えたら何を止めるかまで定めて初めて機能します。

本番化の前に、キューの容量を測る

最初の試行では、AIの精度より先に「1日あたり何件が例外になるか」「1件の判断に何分かかるか」を測ります。たとえば1日300件が到着し、20％が例外、1件3分なら、確認には合計180分が必要です。担当者が通常業務の合間に処理する前提なら、平均値だけでなく時間帯の集中も見なければなりません。これは仮想例であり、実際には案件種別ごとに計測します。

キューは、緊急・通常・分析待ちの三つ程度から始めると運用しやすくなります。緊急は期限と代替手順を固定し、通常は先入れ先出しを基本とし、分析待ちは同じ原因をまとめて開発側へ返します。細かく分類しすぎると、振り分け規則そのものの保守が増えるため、追加は滞留データを見てからで十分です。

導入順序は、①過去データで振り分け条件を検証する、②本番と並行して人が全件を処理し、AIの判定との差を記録する、③低影響で取り消せる処理だけ自動化する、④例外率と滞留時間が上限内であることを確認して対象を広げる、です。平均精度が良くても、月末だけ例外が集中するなら、その時点では範囲を広げません。

この設計は、法令や契約上、専門家が全件を最初から確認しなければならないという場合には向きません。その場合、AIは判断者ではなく、資料整理や見落とし候補の提示に限定します。また、正誤を判断する根拠が社内に存在しない業務では、キューを作る前に判断基準を整備する必要があります。

実務への示唆

推奨1： 「人が確認する」を要件にせず、例外条件、担当、期限、容量超過時の動作を一つの表にしてください。

推奨2： モデルの確信度だけでなく、結果の重大性、やり直し可能性、期限、根拠の充足度で振り分けてください。

推奨3： レビューカードに判断材料と操作を集約し、到着件数、滞留時間、修正理由、期限超過を測ってください。

推奨4： FDE（Forward Deployed Engineering）の進め方では、現場担当者と一緒に実際の例外を分類し、限定運用でキューの容量を測ってから、自動化範囲を広げるのが有効です。例外処理を後付けにせず、最初の業務設計に含めることが、本番で止まらないAI活用につながります。

参考資料

1. デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（第2.0版）」
2. 経済産業省「AI事業者ガイドライン（第1.2版）」
3. NIST AI RMF Playbook
4. Google People + AI Guidebook: Feedback + Control

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-09-25。