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

> Human-in-the-Loopの定義、承認・確認・Review・移譲の使い分け、MCP ElicitationやAgent SDKの中断再開と、承認を形骸化させない設計を整理します。

Canonical URL: https://labs.eastbraver.com/guides/human-in-the-loop
Published: 2026-07-14
Updated: 2026-07-15
Category: field-guide
Tags: ai-agent, governance, safety

Human-in-the-Loopは、[AI Agent](/guides/ai-agent)の実行ループへ人間の判断点を組み込む設計です。

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

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

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

| 判断点 | タイミング | 主な対象 |
| --- | --- | --- |
| 承認 (Approval) | 実行の直前 | 取り消せない操作、送信、支払い |
| 確認 (Elicitation) | 実行の途中 | 曖昧さの解消、不足情報の入力 |
| Review | 実行の後 | 成果物の抜き取り確認、評価への還流 |
| 移譲 (Handoff) | 継続不能の時点 | 例外、権限不足、想定外の状態 |

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

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

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

[MCPのTools仕様](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)も、Toolはmodel-controlledであるとしつつ、人間が呼び出しを拒否できる仕組みを持つことを推奨しています。

[OpenAI Agents SDKのHuman-in-the-Loopガイド](https://openai.github.io/openai-agents-js/guides/human-in-the-loop/)は、Tool実行前の承認で実行を中断し、状態をSerializeして保存し、承認後に再開する流れを示しています。承認待ちが数時間や数日になっても成立するよう、**中断と再開を前提にした状態設計**が実装の中心になります。

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

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

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

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

## 承認の一番の敵は形骸化

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

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

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

## よくある誤解

### 人が見るから安全になる

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

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

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

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

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

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

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

## EastBraver Labsの判断基準

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

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

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

## 関連記事

- [モデル運用の選択肢が広がる](/digest/ai-digest-20260707)
- [GPT-5.6とAI実行基盤の境界](/digest/ai-digest-20260710)
- [モデル選定とエージェント運用が接続](/digest/ai-digest-20260714)

## 検証範囲

- 一次情報: 公式ドキュメント / 仕様書 / 設計面からの分析
- ローカル検証: コードは動かしていません
- 実運用: 関連するWeb業務システムの設計・運用経験をもとにしています

## 変更履歴

- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-14: 初版公開