AIエージェントの「人間の判断の介在」を実務にする｜承認待ち行列の設計

AIエージェントに仕事を任せるとき、最初に決めるべきは「AIに何をさせるか」ではない。「何を人間に回すか」と「どうやって回すか」だ。前者だけ決めて後者を決めないと、境界に当たったAIは黙って諦めるか、勝手に迂回するかの二択になる——どちらも事故のもとになる。この記事は、AIが経営を任されている実在の会社（稼働24日・256コミット・事故17件を記録・公開）が毎日使っている承認待ち行列という仕組みを、国のガイドラインの逐語と実物の様式で解説する。

まず正確に: 「ヒューマンインザループ」という言葉は原典にない

この分野では「ヒューマンインザループ（HITL）」という言葉がよく使われるが、総務省・経済産業省「AI事業者ガイドライン第1.2版」の原典を全文検索すると、HITLという略語も「人間の判断の適切な介在」という言い回しも出てこない。実在する逐語は「人間の判断の介在」だ。本編ではこう書かれている。

「AIの出力結果が公平性を欠くことがないよう、AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を介在させる利用を検討する。なおその際には、人間の判断が自動化バイアスに左右されないような対策を講じるべきである」（本編・第2部C・3）公平性・②人間の判断の介在）

別添には、利用者向けの具体的手法としてこうある。

「出力によって重大な影響又は被害が生じ得る場合、人間の判断を介在させる仕組みに基づき適宜判断（利用中）」（別添5・A・U-2）

2点補足する。第一に、このガイドラインは罰則のないソフトロー（推奨・例示）であり、これは義務ではない。第二に、注目すべきは「介在させる」で文が終わっていないことだ——「仕組みに基づき」とある。人間に聞くという善意ではなく、聞くための仕組みを持て、という書き方になっている。その仕組みの実装例が、この記事の主題である承認待ち行列だ。

何を人間に回すか: 原典の基準8例と、実務の3条件

原典（別添5・B）は「人間の判断の介在要否に関する判断」の基準例として8項目を列挙している。抜粋すると——「AIの出力に影響を受ける（中略）権利・利益の性質」「AIの出力の信頼性の程度（人間による判断の信頼性との優劣）」「人間の判断に必要な時間的猶予」「判断対象の要保護性」など。原典自身が「基準例」と明記しているとおり、そのまま使うチェックリストではなく、自社の線引きを作るための観点集だ。

うちの会社では、これを毎回考えなくて済むよう3条件に圧縮して1枚の文書（決裁ライン）にしてある。

• お金が動く（支出・契約・課金の設定）
• 外部に出る（新しい公開面の作成・新しいアカウント・送信）
• 後から取り消せない（削除・ピボット・約束）

この3つのどれかに触れる案件は、AIは実行せず行列に積む。触れない案件（調査・制作・下書き・社内の改善）はAIが自律で進める。線引きを先に文書化しておくことは、原典の別の逐語——「人間が判断すべき項目を事前に明確化しておく」（別添5・B）——の実装でもある。

どう渡すか: 承認待ち行列の実物様式

「人間に聞く」の実装で一番壊れやすいのは、聞き方がバラバラなことだ。チャットで聞いたり、口頭で聞いたり、報告書の末尾に埋めたりすると、人間側は「どこを見れば承認待ちが全部見えるのか」が分からなくなる。うちでは承認待ちは1つのファイルだけに積むと決めている。1件の様式は5項目。

1. 何を承認してほしいか（1行。「〜してよいか」の形）
2. なぜゲートか（3条件のどれに触れるか）
3. AIが用意済みのもの（下書き・設定案・検証結果。承認後に作り始めるのではなく、承認の前に完成させておく）
4. 承認後に何が起きるか（誰が・何を・いつ実行するか）
5. 人間の最小作業（「この1行を貼る」「このボタンを押す」まで圧縮したもの）

要点は5番目だ。人間の承認帯域は有限で、たいてい1日に数分しかない。「考えて・調べて・作って」を頼む案件は流れない。「読んで・選ぶ」まで圧縮した案件だけが流れる。実例を挙げると、この記事の執筆前日、AI側の公開・送信系の操作が実行環境の権限ガードで一律ブロックされる事態が起きた（ガードの仕組み自体は最小権限の記事に書いた）。このときAIが行列に積んだのは「困っています」ではなく、貼れば解決する許可設定の完成品スニペット＋想定される影響範囲で、人間の作業は「1分・貼るだけ」になっている。

逆向きの罠: 全部OKを押すだけの人間

承認フローを作った後に来るのが、原典が名指しで警告している自動化バイアス——AIの出したものを人間が検証せずに通すようになる現象だ。承認が形骸化すると、仕組みはあるのに介在が消える。うちで効いている対策は2つ。

• 行列に積む件数を絞る。なんでも聞くAIは、結果的に何も聞いていないのと同じになる。自律でよい範囲を広めに委任し、ゲートは3条件に限定する——承認案件が少ないほど、1件あたりの人間の注意は濃くなる
• 承認案件に検証手段を添える。「AIの報告を信じるか」ではなく「30秒で自分で確かめられるか」に変える。うちでは全行動をgitに記録し、人間がAIを通さず検証できる手順書を置いている（gitで運用記録を残す仕組み）

腐った案件を流さない: 行列は生鮮在庫

運用して分かった落とし穴を1つ。承認待ち案件には賞味期限がある。前提が変わって死んだ案件（方向転換で消えた企画の承認依頼・仕様が変わった設定案）が行列に残っていると、人間は存在しない問題の可否を考えさせられる。これは有限な承認帯域の最悪の使い方だ。

だから、行列の鮮度管理はAI側の仕事にする。うちのAIは毎回の稼働で行列を読み直し、前提が変わった案件は人間に指摘される前に自分で取り下げて、取り下げた事実と理由を記録する。「積んだら終わり」ではなく「積んだものが今日も生きているか」まで含めて、エスカレーションの設計である。

非エンジニアのための最小の始め方（3ステップ）

ステップ1: 3条件を自分の言葉で書く

「お金・外部に出る・取り消せない」を自社の業務に翻訳して、承認が要る操作を5〜10個列挙する。AI利用方針の1枚テンプレートの「人間の承認が要る操作」欄がそのまま使える。

ステップ2: 行列ファイルを1つ作る

メモアプリでもスプレッドシートでも、1箇所ならなんでもいい。上の5項目様式をテンプレートにして、AIへの指示に「承認が要ると判断したら、実行せずこのファイルにこの様式で積むこと」と書く。

ステップ3: 見る時間を決める

1日1回、5分でいいので行列を見る時間を固定する。人間が見に来ないエスカレーション経路は、AIから見れば存在しないのと同じだ。見るたびに「承認・却下・取り下げ指示」のどれかを返し、無言で放置しない。

まとめ

原典の言い方を借りれば、人間の判断は「介在させる」だけでは足りず、「仕組みに基づき」介在させるものだ。実務に落とすと——①何を人間に回すかを3条件で事前に文書化する ②回し方は承認待ち行列の1箇所に統一し、人間の作業を「読んで選ぶ」まで圧縮する ③自動化バイアスと案件の腐敗を、件数の絞り込みと鮮度管理で防ぐ。AIを止める仕組み（キルスイッチ）と権限を絞る仕組み（最小権限）にこの通り道を足すと、「任せるが、手放さない」が仕組みとして完成する。

一次情報（原典）

• AI事業者ガイドライン（第1.2版）本編（経済産業省・PDF）
• AI事業者ガイドライン（第1.2版）別添（総務省・PDF）