HITL承認頻度¶

このダイヤルは何か¶

HITL（Human-in-the-Loop）承認頻度は、エージェントの処理中に人間の承認を求める頻度を制御するダイヤルです。全操作に承認を求めるか、高リスク操作のみに絞るか、あるいは事後の標本監査に留めるかを決めます。

AIエージェントシステムは本質的に人間との協働が前提（F17）です。しかし「人間が関与する」ことと「全操作に人間が承認する」ことは同義ではありません。全件承認はエージェントのスループットを人間の応答速度にまで引き下げ、自動化のメリットを消失させます。逆に承認を完全に排除すると、ハルシネーション（F4）やツールの副作用（F8）による被害を防ぐ最後の砦が失われます。

このダイヤルが特に難しいのは、承認の頻度が高すぎると承認の質が下がるという逆説的な関係があるためです。1日に100件の承認要求が来ると、承認者は内容を精査せずに機械的にOKを押すようになります（承認疲れ / approval fatigue）。結果として、本当に危険な操作もスルーされてしまいます。承認頻度のダイヤルは、安全性だけでなく承認者の認知負荷まで考慮して設定する必要があります。

効かなすぎる害 ⇔ 効きすぎる害¶

効かなすぎる害（承認頻度が低すぎる）¶

承認をほとんど求めないと、危険な操作がチェックされずに実行されます。

不可逆な操作（本番DBの削除、メール送信、決済）がLLMの判断だけで自動実行され、ハルシネーションによる誤操作が発生した場合に手遅れになります
長時間のエージェント実行が終わってから結果を見て初めて問題に気づき、途中で止められたはずの被害が拡大しています
監査（[accountability]）が求められる環境で「誰がいつ承認したか」の記録が残らず、コンプライアンス違反になります
エージェントの判断が段階的に劣化している（モデルドリフトなど）ことに気づけません

効きすぎる害（承認頻度が高すぎる）¶

承認を頻繁に求めすぎると、自動化の効果が消失し、さらに承認の質が下がります。

承認疲れ（approval fatigue） — 1日に何十件も承認要求が来ると、承認者は内容を読まずに「承認」を押すようになります。これは承認なしよりも危険な状態です。承認があるという形式的な安心感がありながら、実質的なチェックが行われていないためです
スループット低下 — 承認待ちの間エージェントは停止するため、処理速度が人間の応答速度に律速されます。5分に1回の承認で、本来30秒の処理が30分に延びます
人的リソースの浪費 — 承認者の時間が低リスクの判断で消費され、本来時間をかけるべき高リスクの判断に割ける時間が減ります
エージェント離れ — 頻繁な割り込みにストレスを感じ、ユーザーがエージェントの利用を止めてしまいます

決め方¶

このダイヤルは主に [failure_cost] で決めます。失敗時の損害が大きい操作ほど承認を求め、損害が小さい操作は承認を省きます。

リスクゲート方式（推奨）¶

全件承認ではなく、リスクの高い操作にだけ承認ゲートを設置します。具体的には操作を以下の3層に分類します。

自動実行（auto） — 読取操作、可逆な小規模書込。承認不要です
事前承認（approval） — 不可逆な操作、金銭移動、外部通知。実行前に人間が確認します
禁止（forbidden） — 本番データの一括削除など。エージェントには実行権限を与えません

この分類は E1 リスクベース人間承認のリスクスコア（[reversibility] × [failure_cost]）で機械的に判定します。

バッチ承認¶

承認を1件ずつ行うのではなく、複数の操作をまとめて承認する方式も有効です。たとえば「メール送信3件」をまとめて一覧表示し、承認者が一括で承認・却下できるようにします。これにより承認の回数を減らしつつ、チェックの網は維持できます。

標本監査¶

すべての自動実行操作を事後的に全件チェックするのではなく、一定の割合（概ね5〜10%）をランダムにサンプリングして品質を監査する方式です。[failure_cost] が低い操作カテゴリに適しています。異常が検出されたら、そのカテゴリの自律性レベルを下げます。

目安値（出発点）¶

操作カテゴリ	承認方式	頻度
読取操作（検索・参照）	承認不要	自動実行、事後ログのみ
可逆な書込（下書き・ステージング）	標本監査	概ね5〜10%をランダムサンプリング
金銭・不可逆な操作	事前承認	全件。ただしバッチ承認を検討
高額金銭移動・本番一括変更	多重承認	2人以上の承認者

[failure_cost] が中程度の操作は、段階的に標本監査→事前承認→自動実行とシフトさせます。最初は事前承認で始め、実績が蓄積されたら標本監査に移行し、十分な信頼が得られたら自動実行に昇格させます。

具体的なシナリオ¶

シナリオ1：メール送信エージェント¶

顧客へのメールを自動生成し送信するエージェントです。メール送信は不可逆（送信後の取消不能）であり、[failure_cost] は中〜高です。

下書き生成: 承認不要（自動実行、社内プレビューのみ）
社内メール送信: 標本監査（概ね10%を事後チェック）
顧客向けメール送信: 事前承認（全件）
一括メール送信（100件以上）: 多重承認（2人以上）

初期は全メール送信に事前承認を求めますが、社内メールについて成功実績が蓄積されたら標本監査に移行します。顧客向けメールは原則として常に事前承認を維持しますが、定型的な内容（注文確認メールなど）はテンプレートベースの自動実行に昇格できます。

シナリオ2：データベース管理エージェント¶

データベースのクエリ実行や保守作業を支援するエージェントです。

SELECT（読取）: 承認不要
INSERT/UPDATE（個別レコード）: 事前承認 → 実績でバッチ承認に移行
DELETE（個別レコード）: 事前承認（常に）
DDL操作（テーブル変更）: 多重承認
本番DBへの操作: すべて事前承認（降格なし）

本番環境と開発環境で承認ポリシーを分けることが重要です。開発環境のDELETEは標本監査で済ませられますが、本番のDELETEは常に事前承認です。

シナリオ3：24時間運用のバッチエージェント¶

夜間に自動的にデータ処理を行うバッチエージェントです。人間の承認者がリアルタイムで対応できない時間帯があります。

定型的なデータ変換: 承認不要（自動実行＋事後全件ログ）
異常値検出時のアラート送信: 承認不要（自動実行）
異常値に基づくデータ修正: 事前承認（ただし承認者不在の場合はキューに積んで翌営業日に処理）
承認タイムアウト: 翌営業日10:00まで待機、それでも応答がなければ自動却下

夜間運用では承認タイムアウトの設計が特に重要です。タイムアウト後のデフォルトを自動承認にすると、人間のチェックが形骸化します。

実践的なアドバイス¶

承認疲れを定量的に監視してください。承認にかかった時間（承認要求から応答までの時間）を記録し、短くなりすぎていないか確認します。承認応答が平均2秒以下であれば、内容を読まずに承認している可能性が高いです。
承認要求には十分なコンテキストを添えてください。「メール送信を承認しますか？」だけでは判断できません。「宛先：tanaka@example.com、件名：契約書の修正、操作理由：ユーザーの依頼による修正」のように、承認者が判断に必要な情報をすべて提示します。C3 ドライランで実行結果のプレビューを見せるのも有効です。
承認タイムアウトのデフォルトは安全側（自動却下）にしてください。承認者が不在で応答がない場合、自動承認ではなく自動却下にします。自動承認にすると、承認プロセスが形骸化します。
承認のバッチ化は効果が大きいです。10件を個別に承認するよりも、10件の一覧を見て一括承認する方が承認者の負荷が小さく、かつ内容を比較しやすいためチェックの質も上がります。ただし、バッチ内の1件の却下が他の件に影響しない設計にする必要があります。
承認頻度の適切さは定期的にレビューしてください。事業環境やリスクプロファイルの変化に応じて、承認対象の操作カテゴリを見直します。半期に1回程度のレビューが目安です。