この記事の音声は準備中です。
音声の一覧・再生リストへHuman-in-the-Loop 設計
この記事の目的
人間の確認・介入(Human-in-the-Loop)を Agent の実行フローのどこに置くかを、リスクと運用負荷のバランスで設計できるようになります。「承認を増やせば安全」ではないこと — 承認疲れが安全装置を形骸化させること — を踏まえた設計がゴールです。
対象読者
- 副作用のある操作(送信・更新・削除・購入)を行う Agent を設計するエンジニア
- Agent の自動化範囲と人間の責任分界を決める立場のテックリード・プロダクトオーナー
前提知識
- AI Agent とは何か — 自律性は程度の選択であること
- Agent ループ — 停止条件としての人間の介入
- ツール使用 — アプリ実行型とプロバイダー実行型の実行主体・制御点の違い
本文
概要
Human-in-the-Loop(HITL)とは、人間の判断を Agent の実行フローに組み込む設計です。ツール使用で区別したアプリ実行型では、自社アプリがツール要求を受け、実行前の承認をコードで強制できます。組み込みツールや API 経由のリモート MCPツールやデータソースを LLM アプリケーションに接続するための標準プロトコル。概要は ツール使用、接続の実務は ツール接続標準(MCP とエコシステム) などのプロバイダー実行型では、プロバイダー基盤が呼び出すため、自社コードが毎回実行直前に挟まるとは限りません。HITL を置く場所は、実行主体と製品が提供する承認・停止機能を確認して決めます。
詳細: 実行主体ごとに承認の制御点を選ぶ
| 構成 | 承認を置く制御点 | 導入前に確認すること |
|---|---|---|
| アプリ実行型(関数呼び出し(function calling)・自社 MCP クライアント) | 自社アプリのツール実行ゲート | 承認前は呼び出さず、実引数・認可・有効期限を実行時に照合すること |
| プロバイダー実行型で対象操作の承認が有効 | 製品の承認要求・応答機能 | 対象ツールに承認を要求する設定、承認対象の引数、拒否・中断時の挙動を確認すること |
| プロバイダー実行型で承認を省略 | 対象呼び出しには事前承認ゲートがない | 許可ツール・資格情報スコープ・送信先で影響を制限し、事前承認が必要な操作を含めないこと |
| 必要な承認・停止を製品機能で強制できない | 必要な制御点を確保できていない | 副作用の実行を自社アプリに移すなど、方式を見直してから対象操作を許可すること |
具体例として、OpenAI Responses API のリモート MCP では、require_approval: "always" が承認要求を返し、アプリはツール名・引数を確認して mcp_approval_response で許可または拒否を返せます。承認は呼び出し 1 回ごとです。"never" やツールごとの省略設定を使う対象では、この承認待ちを経由しません。allowed_tools で公開するツールを絞り、接続先の認証・権限も別に制限します(公式資料確認: 2026-10-08)。この例の承認機能を、すべての組み込みツールや他製品にもあるものとして扱いません。
製品が返す承認要求に対象の版・差分・期限まで含まれるとは限りません。必要な承認条件を自社アプリや接続先でも強制できるか確認し、満たせない場合はその操作の実行方式を変更します。プロンプトで「実行前に聞く」と指示するだけでは制御点の代わりになりません。
詳細: 介入の 4 形態
| 形態 | タイミング | 向く場面 |
|---|---|---|
| 事前承認(approval) | 行動の実行前 | 不可逆・影響の大きい操作(送信・削除・支払い) |
| 事後レビュー(review) | 成果物の公開・反映前 | 品質責任が人間にある成果物(顧客向け文書・コード) |
| 例外エスカレーション(escalation) | 規定外・低信頼のときのみ | 大量処理の中の少数の難しいケース |
| 監視と中断(oversight) | 実行中いつでも | 長時間タスク。進捗の可視化と停止手段をセットで |
「全部承認」か「全自動」かの二択ではなく、操作ごとにこの 4 形態を使い分けます。
詳細: どこに承認を置くか — リスクベースで決める
承認の要否は「不可逆性 × 影響範囲」で整理します。
| 影響が小さい | 影響が大きい | |
|---|---|---|
| 可逆な操作(下書き作成・取り消し可能な更新) | 自動実行 | 事後レビュー |
| 不可逆な操作(外部送信・削除・支払い) | 事後レビュー または 許可リスト化 | 事前承認(必須) |
「可逆にできないか」を先に検討する価値があります。直接送信ではなく下書き作成にする、削除ではなくアーカイブにする — 操作自体を可逆に設計できれば、承認そのものを減らせます。
詳細: 承認疲れ(approval fatigue)が安全装置を壊す
承認が多すぎると、人間は内容を読まずに承認するようになります(ラバースタンプ化)。こうなると承認は安全装置として機能していないのに、機能している前提で運用されるため、承認なしより危険な状態にすらなりえます。対策:
- 承認対象を絞る — リスクの低い操作は許可リストに移し、自動実行にします
- 判断材料を要約して出す — 何を・なぜ・影響範囲(宛先・件数・金額)を示し、モデルが作る要約と、実行コードが使う実引数・差分を区別して表示します。要約だけを承認の対象にしません
- 実績に応じて自動化範囲を広げる — 立ち上げ期は承認を厚くし、承認ログで拒否率が十分低い操作から自動化へ移します(信頼の段階的拡大)
詳細: 実装上の要点
以下は必要な条件を強制できる実行ゲートの設計です。アプリ実行型では自社コードへ実装し、プロバイダー実行型では製品の設定と接続先の制御で各条件を満たせるか個別に照合します。
- 保証の範囲を決める — 強制ゲートが保証するのは、未承認または承認条件と一致しない操作を拒否することです。人が危険な操作を承認する誤判断は残るため、承認済みであることを被害防止の保証にしません。最小権限と監査を重ねます
- 承認を実行内容に結び付ける — 操作・対象・実引数・差分・対象の版を固定し、有効期限と再使用条件(例: 1 回限り)を記録します。承認後に内容や対象の版が変われば再承認し、実行時にも権限とポリシーを再確認します。承認は認可の代わりにはなりません
- 承認待ちの永続化 — 承認は数時間〜数日かかりえます。Agent の作業状態をチェックポイント長時間タスクの「ここまで完了した」を再開可能な形で永続化したもの。ツール実行の完了やフェーズ境界などの意味のある単位で切る。信頼性とトークンコスト制御の両方の仕組み。として保存し、承認後に再開できる構造にします(メモリと状態管理)
- タイムアウトはデフォルト拒否 — 応答がない場合に「実行して先へ進む」実装は、承認の意味を無効化します
- 拒否はモデルへのフィードバック — 拒否の事実と理由を返し、許可済みの代替案だけを検討します。正規の追加承認が必要なら引き継ぎ、許可されなければ停止して報告します。別のツールやアカウントで拒否を回避させません
- 監査ログ — 誰が・何を・いつ承認/拒否したかを記録します。事故調査と自動化範囲拡大の判断材料になります
| ケース | 強制ゲートの処理と限界 |
|---|---|
| 未承認 | 実行を拒否します。待機・正規の承認依頼・停止と報告のいずれかへ進みます |
| 承認後の引数・差分・対象の版の変更 | 元の承認では実行せず、変更内容を提示して再承認します |
| 期限切れ、1 回限りの承認の再使用 | 拒否します。再承認前に前回実行の成否を照合し、重複実行を防ぎます |
| 危険操作を人が承認 | 一致する承認と認可があれば実行され得ます。人の誤判断による被害は残り、最小権限・レビュー・監査で抑えます |
実務での注意点
アンチパターン
- すべての操作に承認を要求する → 承認疲れでラバースタンプ化し、本当に危険な操作が素通りする → リスクマトリクスで承認対象を不可逆 × 影響大に絞る
- 判断材料のない承認画面(「ツール X を実行します。OK?」)→ 人間は判断できないまま承認し、責任だけを負う → 何を・なぜ・影響範囲に加えて実引数と差分を提示する
- 承認済みフラグだけで任意の操作を実行する → 承認した内容と実行内容が変わり、期限切れや再使用も素通りする → 実行内容・対象の版・期限・再使用条件に結び付け、変更時に再承認する
- 拒否後の挙動が未定義 → Agent が同じ操作を再試行し続ける、または黙って停止する → 拒否を理由付きでモデルに返し、代替案の提示または報告で終わるフローにする
- 実行主体を確認せず自社コードで必ず承認できると考える → プロバイダー側の承認省略設定や不足する制御点を見落とす → 製品の承認・許可ツール・認証設定を照合し、必要な制御点がない操作は方式を見直す
チェックリスト
- 不可逆な操作をすべて列挙し、承認要否をリスクマトリクスで決めた
- ツールごとの実行主体と、承認・拒否・停止を強制できる制御点を確認した
- プロバイダー実行型では対象ツールの承認設定・許可ツール・認証スコープを照合し、必要な条件を強制できない操作の方式を見直した
- 操作を可逆化する設計(下書き化・アーカイブ化)を検討した
- 承認画面に判断材料と実引数・差分・対象の版が表示され、モデルの要約と区別できる
- 操作・対象・実行内容・有効期限・再使用条件を承認に結び付けた
- 変更時は再承認し、実行時に認可を再確認し、未承認・期限切れ・不正再使用を拒否する
- 危険操作への誤承認の残余リスクを最小権限・レビュー・監査で抑えている
- 承認待ち状態が永続化され、タイムアウトはデフォルト拒否になっている
- 拒否がモデルにフィードバックされる
- 承認・拒否の監査ログがあり、自動化範囲の見直しに使われている
関連トピック
- ツール使用 — 実行主体と承認を置ける制御点の区別
- Agent ループ — 人間の介入という停止条件
- コンピュータ操作型・マルチモーダル Agent — 不可逆操作の承認が特に重要な類型
- エラー処理・リトライ・フォールバック設計 — エスカレーションはエラー処理の最終段
- ガードレール — 人間の判断の手前に置く自動チェック層
- 信頼度と較正(calibration) — 低信頼を人間へのエスカレーションの発火条件にする
- AI プロダクトの UX パターン — 承認・自動化レベルの「見せ方」side(本記事の UX 面)
- オートメーションバイアスとスキル退化 — 承認が形骸化する認知的背景(なぜ人は「押すだけ」になるか)
参考資料
- Building Effective Agents(Anthropic) — 人間のチェックポイントを含む Agent 設計の原則(アクセス日: 2026-07-05)
- OWASP LLM01:2025 Prompt Injection — 最小権限と高リスク操作の承認を組み合わせる原則(アクセス日: 2026-10-03)
- MCP servers / Calling tools・Approvals(OpenAI) — Responses API のリモート MCP の承認要求・応答、承認省略と許可ツールの設定(アクセス日: 2026-10-08、取得: 2026-10-08T04:33:51Z)
TODO・未確認事項
なし