🐼

HITL（Human-in-the-Loop）で“暴走しないエージェント”を作る ― 任せる前に合意、動かす前に確認

に公開
llm
zennfes2025ai
idea

はじめに――自動化の前に“相棒にする”

エージェントをつないだ初日は快感です。ところが、権限を広げるほど想定外の操作や根拠のあいまいな判断が混じり始める。ここで効くのがHITL（Human-in-the-Loop）、つまり人が対話で介入する仕組みです。各社のガイドや運用事例でも、人が承認・中断・修正できる経路を最初から組み込むことが強調されています。たとえば、実行前にユーザーが操作を確認・承認できる設計や、低信頼時だけ審査を起動する仕組みが公開されています。(Amazon Web Services, Inc.)

1. HITLは“緊急停止ボタン”ではなく“合意を作る会話”

HITLというと“最後に人が止める”印象になりがちですが、実務では前工程が肝です。

  • 提案→合意→実行の順番にする（いきなり実行しない）。
  • 依頼は目標・文脈・期待する出力形式の三点をセットで渡す（人への依頼と同じ）。主要ベンダのプロンプト作法とも合致します。(OpenAI Help Center)
  • 口調は命令より相談。「〜したほうが良いと思う。どう？」で代替案と前提不足が自然に出てきます。
    この“小さな合意づくり”が、後段の承認負荷を大きく下げます。(OpenAI Help Center)

2. 介入ポイントは3か所だけ覚える

HITLの挿しどころは増やし過ぎると回らない。まずは3点固定が現実的です。

  1. 行動の前：外部APIやファイル操作など不可逆な処理の直前に要約付きの確認を出す（理由・影響範囲・取り消し方法）。主要クラウドは利用者承認のUIパターンを提供しています。(Amazon Web Services, Inc.)

  2. 信頼が落ちた時：スコアやルール違反の兆候で人の審査にフォールバック（しきい値＋抽出サンプルの定期監査）。この“低信頼だけ人へ”は運用コストを抑える基本設計として整理されています。(AWS ドキュメント)

  3. 出力の表現：内容がOKでも表現がNG（攻撃的・機微情報の露出など）なケースは表現段階で人が整える。専用の安全・モデレーション機能を併用するのが標準です。(Microsoft Learn)

3. ワークフローに“待つ”を教える

HITLは人が承認するまで待てる構造でないと意味がありません。

  • フレームワーク側には**割り込み／一時停止（interrupt）**のプリミティブが用意されており、人の入力を受けたら再開する、という流れを簡単に書けます。(LangChain Blog)
  • “承認が来ない”ケースも設計に入れる（タイムアウト→安全側に倒す／再提案に戻す）。
  • 監査のため、誰が・何を見て・どう判断したかを記録する（後述の測り方で使用）。

4. 権限は“人”ではなく“用途”で分ける

HITLを楽に回すコツは、用途＝責任境界で接続を分けること。

  • 例：情報照会用（読取のみ）、下書き生成用（書込は仮ディレクトリ）、実行用（要承認）
  • 人の役割は“承認者”と“実行者”を分ける。権限の粒度は最小限から始め、審査データを見ながら育てる。
    規制・法務の視点でも、「人が介在できる」を示せる構造が求められています。(Reuters)

5. “人の判断”を増やしすぎないための2つの逃げ道

HITLは万能ではありません。人手が詰まると機能不全になります。逃げ道を用意しましょう。

  • しきい値駆動のレビュー：信頼スコアやルール違反検知で自動オン／オフ（低信頼のみ人へ）。(AWS ドキュメント)
  • 事前の安全レール：プロンプトや出力の安全フィルタで人に載せる前にノイズを落とす。(マイクロソフト アジュール)
    さらに、人の好みを学習させる（RLHF 等）ことで審査の総量を減らす方向も有効です。(IBM)

6. 小さく測る――“承認が価値を生む場所”だけ残す

毎週固定の5ケースで次を計測します。

  • 手戻り率：HITLを入れた操作のうち、差し戻し無しで完了した割合
  • 承認リードタイム：通知→承認までの平均（分）
  • 抜け漏れ検知：自動で通ったものの中からサンプリング監査でNGだった比率
    数値が見えれば、どの承認が価値を生むか／要らないかが判断できます。これは各種ガイドラインや法務解説でも推奨される“継続モニタリング”の考え方に沿います。(Reuters)

7. すぐ使える“承認ダイアログ”の書き方（置き換え例）

  • 命令型：「取引先Aへ請求書を送信します。送信しますか？」
  • HITL型：「これから何を**（請求書送付）、どこへ（A社経理アドレス）、なぜ（期日◯/◯）、影響（取消は××）を実行予定です。代案：ドラフト保存のみ。どうしますか？」**
    → 理由と影響を添え、代案を提示。確認に必要な文脈を一画面で渡します（各社の“明確・具体・反復”ガイドと一致）。(OpenAI Help Center)

8. これだけは避ける

  • 承認の乱立：すべての操作に承認を掛ける（人がボトルネックになります）。
  • 後付けの監査：誰が何を見て承認したか記録が残らない。
  • “最後は人が見るからOK”：しきい値・安全レール・用途分離なしの丸投げは、リスク低減になりません。(NIST)

参考（一次情報）

  • 行動前の承認・フィードバックを備えたエージェントの実装パターン。(Amazon Web Services, Inc.)
  • 低信頼時だけ人へ回すワークフロー（人手審査の自動起動）。(AWS ドキュメント)
  • 割り込み／停止→再開で人が介入できるフレームワーク設計。(LangChain Blog)
  • 安全・モデレーションの組み込み（人の前段でのフィルタ）。(マイクロソフト アジュール)
  • 人の介在の法務・リスク観点（on-the-loop / in-the-loop の意義）。(Reuters)
  • 人の好みを学習させて審査量を下げる（RLHF 等）の基礎。(IBM)

Discussion