Human-in-the-Loopとは — AI Agentの承認と例外処理の設計

Human-in-the-Loopは、AI Agentの実行ループへ人間の判断点を組み込む設計です。

すべての出力を人が見張る、という話ではありません。どの操作の前で止めるか、そのとき人へ何を見せるか、誰が決め、その記録をどう残すか。この設計を持たないまま「人が確認するから大丈夫」と言っても、確認は成立しません。

このGuideは、2026年7月14日時点の一次情報を基準にしています。ProtocolやSDKの中断・承認APIは整備が進んでいる途中のため、実装時には利用する基盤の最新仕様を確認してください。

人が入る点は一種類ではない

全部をまとめて「人間のチェック」と呼ぶと、設計が曖昧になります。承認は権限の問題、確認は情報の問題、Reviewは品質の問題、移譲は例外処理の問題。それぞれ置く場所も記録も違います。

実装の部品は揃い始めている

MCPのElicitation仕様は、Serverが利用者へ追加情報を求める流れを定義しています。構造化した入力を求めるFormモードと、外部URLへ誘導するURLモードがあり、応答はAccept・Decline・Cancelの三つに分かれます。Credentialのような機密情報はFormモードで求めてはならず、URLモードを使います。この区別は仕様上の要件です。

MCPのTools仕様も、Toolはmodel-controlledであるとしつつ、人間が呼び出しを拒否できる仕組みを持つことを推奨しています。

OpenAI Agents SDKのHuman-in-the-Loopガイドは、Tool実行前の承認で実行を中断し、状態をSerializeして保存し、承認後に再開する流れを示しています。承認待ちが数時間や数日になっても成立するよう、中断と再開を前提にした状態設計が実装の中心になります。

承認は情報が揃って初めて機能する

承認画面に「Agentがメールを送ろうとしています。許可しますか」とだけ出ても、判断できません。承認者に渡すべき情報があります。

• 何を実行するか (Tool名と引数の要約)
• 誰のための実行か (対象の利用者・データ)
• 何を根拠に選んだか (参照した文書・状態)
• 実行するとどうなるか (影響範囲、取り消せるか)

そして承認の記録は、承認者・対象操作・入力・期限を結び付けて残します。IdentityとAuthorizationで扱ったApproval tokenの形です。誰かがいつか許可した、では監査に使えません。

承認の一番の敵は形骸化

承認点を増やすほど安全になる、とは言えません。低リスクな操作にまで承認を付けると、承認者は内容を読まずに通し始めます。全部に鍵を掛けた結果、全部素通りになる。これが一番避けたい状態です。

• 承認対象は、取り消せない操作と影響の大きい操作へ絞る
• 読み取りや下書き生成は承認なしで流す
• 承認までの時間と差し戻し率を記録する

差し戻し率がゼロに近づいたら、承認が機能しているのではなく、読まれていない可能性を疑います。

よくある誤解

人が見るから安全になる

見せる情報が不足していれば、承認は儀式になります。安全性は承認の有無ではなく、承認者が判断できる情報設計から来ます。

すべての操作に承認を付ければよい

承認疲れで全件素通りになります。Toolの分類に合わせ、リスクの高い操作へ絞ります。

承認は同期処理で実装できる

人間の応答は数時間かかることがあります。実行を安全に中断し、状態を保存し、再開できる設計が本体です。Loop Engineeringの停止・移譲条件とも接続します。

Human-in-the-Loopは過渡期の仕組みで、いずれ外せる

外すかどうかは評価の結果で決める判断です。また、承認点は人間が失敗例を観測する点でもあり、評価セットの供給源として残す価値があります。

EastBraver Labsの判断基準

EastBraver Labsでは、取り消せない操作 (送信・削除・支払い・公開) を承認対象の初期値にします。外すのではなく、外せる根拠を評価で作る側に置きます。

承認そのものも観測対象です。承認までの時間、差し戻し率、差し戻し理由を記録し、形骸化の兆候を監視します。差し戻された実行は、そのまま評価セットへ戻します。

人を入れる目的は、Agentを遅くすることではありません。失敗が業務へ届く前に、人間が観測して止められる点を設計することです。どこで止まるかを説明できないAgentは、まだ本番前だと考えています。

関連記事

• モデル運用の選択肢が広がる
• GPT-5.6とAI実行基盤の境界
• モデル選定とエージェント運用が接続