HITL（ヒューマンインザループ）の実践：AIの承認・レビュー・引き継ぎを設計する

AIの操作が失敗したとき、損害が大きい、または元に戻しにくいのであれば、実行前に人が判断する仕組みを置きます。HITL（ヒューマンインザループ）で人が関わる位置は、大きく3つです。実行前に承認する、完了した処理を抽出して確認する、エスカレーションされた案件を引き受ける。操作ごとに適切な位置を決め、定型的な承認を減らすのは、その操作について根拠がそろってからにします。

HITL（ヒューマンインザループ）とは？

人によるレビューを設計することは、権限の範囲を決めることです。人の同意なしに、システムにどの操作まで認めるのでしょうか。 サポートエージェントは、同じ会話の中で注文情報を読み取り、返信を書き、記録を変更し、返金を実行できます。しかし、これらを同じ権限で扱うべきではありません。

人が管理する門のある庭を想像してください。庭師は、歩く人の一歩一歩を確認するわけではありません。傷んだら修復しにくい場所では立ち入りを管理し、日常の作業は終わってから点検し、異変を知らせるベルが鳴れば対応します。考えるべきなのは、その門をどこに置くかです。

ヒューマンインザループの意味と範囲

Human-in-the-loopは通常HITLと略され、フィードバックや介入、意思決定を通じて、人がAIシステムの運用に参加することを指します。承認ボタンを設けることだけではありません。実際の業務では、誰かが提案された操作を承認する、完了した処理を確認する、例外を解決するといった、具体的な責任として定義する必要があります。Stanford HAIによる定義。

この言葉には、学習データへのラベル付け、モデルの出力の修正、学習の方向付けも含まれます。いずれも正しい用法ですが、今日の返金を人が承認したからといって、明日のモデルが自動で再学習されるわけではありません。運用上のレビューから得られるのは、改善の根拠です。それをモデルやワークフローの改善につなげるには、別途、意図的な取り組みが必要です。Google Cloudによる解説。

エージェント型AIに人をどう組み込むか

AIエージェントは、モデルを使って手順を選び、注文情報の取得やメッセージ送信などのツールを呼び出すソフトウェアです。人のレビューは、重大な結果を伴うツール呼び出しの直前に置きます。最初に計画を承認しても、その後エージェントが選ぶ宛先や金額、レコードまでは確認できません。

各手順をつなぐ仕組みも明確にしておきます。AIエージェントのオーケストレーションでは、状態の保存、担当者の割り当て、引き継ぎをエージェントの作業にどう組み込むかを解説しています。

人が関わる3つの位置

承認は特定の操作を実行前に止めるため、サンプリングは完了した処理の傾向をつかむため、エスカレーションはエージェントの権限を超える案件を解決するために使います。 同じワークフローの中で、これらを組み合わせることができます。

実行前：承認する

システムは、実行する操作の詳細を確定させたうえで待機します。レビュアーに提示するのは、宛先や対象レコード、変更内容、判断の根拠、レビューが必要になったルールです。承認されればその操作を実行でき、却下されれば実行を止めます。

返金、慎重な対応が必要な顧客への返信、取り消せない削除などに使います。確認画面に「サポートツールを許可しますか？」としか表示されなければ、業務上の判断内容が見えません。「この理由により、この注文を元の支払い方法へ返金する」と示せば、レビュアーは具体的に確認できます。

実行後：処理結果をサンプリングして確認する

システムはあらかじめ許可された範囲内で処理を実行し、人が後から結果の一部を抽出して確認します。チケットの分類や社内向けの要約など、影響が小さく、まれな誤りを検知でき、許容もできる操作に向いています。

サンプリングでは、抽出した処理ですでに起きた誤りを防げません。顧客に送ったメッセージなら、訂正によってやり取りを立て直せることはあっても、最初の文面を読まなかったことにはできません。自動化を判断するときは、こうした取り戻せない影響も織り込みます。

通常の品質を把握するための無作為抽出と、特殊なケースを狙った抽出は分けて行います。苦情だけを確認しても、分かるのは報告された不具合であり、完了した処理全体の品質ではありません。

エスカレーション時：人に引き継ぐ

根拠、権限、または適用できるルールが足りないときは、案件を人に引き継ぎます。たとえば、アカウントの所有者をめぐって情報が食い違う、注文データがない、ポリシーの例外に当たる、顧客が明確に人による対応を求めている、といった場合です。

引き継ぎ先には、判断の根拠、試みた操作、未解決の論点、現在の状態を渡します。判断が必要な操作は保留します。社内向け要約の作成など、安全だと明確に定められた別の作業は、ポリシーで認められていれば続けられます。

Human Over the Loop：運用を統括する役割

この表現に出会ったら、ルールを定め、権限を変更し、システムを停止できる人が担う、ガバナンスの層を指すものとして捉えてください。用語の使い方には揺れがあるため、呼び名に頼らず、責任を具体的に書きます。業務の成果を監督するマネージャーが、個々の取引を確認しているとは限りません。

同じ理由で、in the loopの承認と、on the loopの監視も区別します。ダッシュボードで問題をすばやく発見できても、次の操作の前に処理を止める仕組みが自動で生まれるわけではありません。その停止は、別途実装する必要があります。

判断の軸は、失敗したときの損害と元に戻せる範囲

問題の発見と復旧までに引き受けられる損害を、想定される被害が上回るなら、承認を必須にします。 モデルの確信度だけでは、この判断はできません。

次の観点から操作を評価します。

• 結果の重大さ： 個人情報を漏らす、金銭を動かす、約束を交わす、アカウントへのアクセスに影響を与える可能性はありますか。
• 復旧： 顧客に修正の負担をかけず、以前の状態をすばやく、完全に復元できますか。
• 影響範囲： 影響するのは社内の下書き、顧客、それとも一括処理するレコード全体ですか。
• 根拠： 本人確認、元データ、ポリシーは、判断できるほど明確ですか。
• 検知： 同じような処理が積み重なる前に、異常を把握できますか。

データベース上では元に戻せる項目でも、その変更が後続の取り消せない処理を引き起こすことがあります。配送先住所の変更は簡単に取り消せても、出荷作業が始まれば話は変わります。データベースに取り消し操作があるかだけでなく、一連の結果を見て判断します。

操作の範囲が限定され、根拠が信頼でき、残る損害を許容できるなら、サンプリングによるレビューを使います。結果が重大、または復旧が難しい操作には、実行前の承認を使います。必要な事実やルールが足りなければ、エスカレーションします。禁止されている操作はブロックします。承認キューを、ポリシーを迂回する抜け道にしてはいけません。

入力、出力、ツール呼び出しを自動で検査するAIガードレールは、この設計を支えます。形式が不正なリクエストや、許可されていない送信先を、人がレビューに時間を使う前に拒否できます。人の判断は、そうした検査を通過してもなお残る、正当に判断が必要な曖昧さに向けます。

ヒューマンインザループの実例：サポートエージェント

サポートエージェントの権限は、操作の種類ごとに分けます。 次の表は、注文対応にエージェントを導入する企業を想定した、初期ポリシーの例です。設計のための仮定であり、ベンダーの初期設定でも、実測結果の報告でもありません。

顧客から「注文した商品が届かないので返金してほしい」と言われたとします。エージェントは注文情報と配送会社の状況を取得し、対応案を作成できます。配達の記録と顧客の説明が食い違う場合は、根拠のない解決策を作らず、判断を人に引き継ぎます。

根拠からポリシーに沿った返金が妥当と判断できる場合は、対象の注文、金額、返金先、理由を具体的に提示し、承認を求めます。実行側は決済システムを呼び出す前に、承認内容と現在の返金状況を確認します。そして、返ってきた取引の証跡を記録します。エージェントが返金の成功を伝えてよいのは、その後です。

返金の承認と返信の承認は、別の権限です。 金銭を動かす操作を承認しても、付随するメールで根拠のない配送の約束をしてよいことにはなりません。同様に、顧客を安心させるメッセージを承認しても、次のツール呼び出しに隠れた返金まで許可したことにはなりません。

営業メールにも同じ区別を適用します。文面の生成は自動化できても、新しい宛先リストへの送信にはレビューを求めます。データ変更なら、「記録を整理しました」という要約ではなく、変更前の値と提案された値の実際の差分を確認します。

レビューキューを、実際に判断できる仕組みにする

レビュアーに必要なのは、判断材料一式と期限、そして却下する権限です。 チャットに承認ボタンを置くだけでは、通知の仕組みしかできていません。

判断材料には、実行する操作、影響を受ける顧客やレコード、提案された引数、元となる根拠、適用されるポリシー、未確認の事実を含めます。編集案には変更前の値を並べて表示します。元の証拠にリンクし、会話全体をたどり直さなくても、エージェントの説明を検証できるようにします。

主担当のレビュアーと、不在時などに引き受ける担当者を決めます。緊急のエスカレーションは通常の承認と分けます。レビュー期限を過ぎたら、保留中の操作を止めたままにするか取り消し、代替の担当者に通知します。返答がないことを、許可とみなしてはいけません。

処理能力には超えられない上限があります。仮に、1時間あたり24件の依頼 × 1件あたり3分のレビュー = 1時間あたり72分のレビュー作業が発生するとします。レビュアーが1人なら、他の業務を考慮する前でも、使えるのは60分だけです。判断がすべて正しくても、このキューは膨らみ続けます。応答時間を約束する前に、不要な承認を減らす、エージェントの範囲を狭める、対応できる人員を増やすといった対策が必要です。

承認は、対象となった成果物と引数そのものにひも付けます。宛先、返金額、レコードのバージョン、メッセージが変わったら、承認を無効にして再レビューを求めます。実行直前には、別の担当者がすでに返金していないかなど、待機中に変わり得る事実も確認し直します。

レビュー結果を重複して受け取っても、安全に扱える必要があります。操作には変わらない識別子を付け、承認結果は一度だけ適用し、外部への書き込みが重複しないようにします。同じ操作を繰り返しても、一度実行したときと同じ結果になる性質を「冪等性」と呼びます。返金リクエストがタイムアウトしたら、別の支払いを試す前に、処理状況を照合します。

現行ツールでAIエージェントを一時停止する仕組み

ツールによって停止の仕組みは異なりますが、業務上の判断ルールを用意するのは利用する企業です。 以下は、2026年10月21日に各開発元の公開ドキュメントで確認した内容です。記載された動作の解説であり、製品を実際に操作した検証ではありません。

OpenAI Agents SDK：保留中のツール呼び出しを承認する

OpenAI Agents SDKは、アプリケーションのコードでエージェントを構築するためのライブラリです。Pythonではneeds_approval=True、JavaScriptではneedsApproval: trueでツールの承認を設定できます。承認が必要な呼び出しでは、中断と再開可能な状態が返されます。アプリケーションが保留中の項目を承認または却下し、同じ実行を再開します。判断を後で行うために、状態をシリアライズすることもできます。OpenAIの承認に関するドキュメント。

サポート用アプリケーションなら、返金ツールや送信ツールの前に承認を置きます。保留中の操作を中心に、レビュー画面を作ります。ドキュメントの短い例では、返された中断をコードで承認しています。その無条件承認のループをコピーしても、人のレビューにはなりません。アプリケーションが先に、人の判断を受け取る必要があります。

LangGraph：状態を保存して中断し、後から再開する

LangGraphは、状態を保持するエージェントワークフロー用のライブラリです。interrupt()で外部からの入力を待つために処理を中断します。実行状態を永続的に保存するチェックポインターと、変わらないthread_idを設定します。再開時には同じスレッドを使い、Command(resume=...)を渡します。LangGraphの中断に関するドキュメント。

本番運用で注意すべき点は、ドキュメントに明記されています。再開すると、中断されたノードは先頭から再実行されます。 中断より前のコードは、再び実行される可能性があります。外部の状態を書き換えるなどの副作用を伴う処理は、レビューを通過した後に置き、繰り返しても安全にします。ドキュメントでも、副作用を伴う処理を専用のノードに分けることが推奨されています。中断は無期限に待機できるため、業務上のレビュー期限とエスカレーション対応を別途組み込みます。

n8n：選んだツールに人のレビューを設定する

n8nは、視覚的にワークフローを構築できる自動化プラットフォームです。AI Agentノードに接続されたツールのうち、選んだものに人のレビューを設定できます。ドキュメント上のフローでは、処理を一時停止して、提案されたツールとパラメーターを表示します。承認されればAIが指定した入力で実行し、却下されれば操作を取り消します。n8nの人によるレビューのガイド。

エージェントのToolsコネクターを開き、Human reviewからチャネルを選んで、レビューが必要なツールをそのステップに接続します。ガイドでは、利用できるチャネルとしてn8n ChatやSlackなどが挙げられています。また、レビュー用メッセージを組み立てるための$tool.nameと$tool.parametersも説明されています。

そのメッセージで、何を承認するのかを明示します。このガイドが説明しているのは承認と却下です。返金内容を編集できるフォームまで用意されていると考えてはいけません。レビュアーが変更を求めたら、提案を修正に戻し、改めて承認を受ける流れにします。

Anthropic Claude Code：権限設定でツールへのアクセスを制御する

AnthropicのコーディングエージェントClaude Codeには、ツールの権限モードがドキュメント化されています。Manualと表示されるdefaultは、許可済みの操作やルールによる例外を除き、許可を求めるプロンプトを表示します。acceptEditsは、許可された作業ディレクトリ内でのファイル編集と、一部のファイルシステムコマンドを自動で許可します。planは、ソースファイルを編集せずに調査します。Claude Codeの権限に関するドキュメント。

autoモードは、シェルコマンドやネットワークリクエストなどの操作に対して、バックグラウンドの分類器を使います。これは自動化されたレビュー判断です。bypassPermissionsは、どのモードでも自動承認しないとドキュメントに定められた操作を除き、許可を求めるプロンプトを省略します。どちらも、人が個々の操作を確認した証拠にはなりません。

これらの設定が制御するのは、Claude Codeの実行時権限です。顧客サポートのサービスには、返金、宛先、データアクセスについて独自のルールが必要です。Claudeのdangerously skip permissionsガイドでは、そのモードが運用上どこまでを制御するのかに絞って解説しています。

ログに何を残すべきか

誰がどの操作を許可し、その後何が起きたかを再現できるだけの、構造化された証跡を残します。 会話の記録だけでは、特に途中で停止したり担当が変わったりする案件を追いにくくなります。

次の項目を個別のイベントとして記録し、案件と操作の識別子で関連付けます。

• 提案： 操作の種類、対象、正確な引数、成果物のバージョンまたはダイジェスト、変更前の値、根拠となる情報源への参照。ダイジェストは、レビューした内容を識別する指紋に当たるものです。
• 判断経路： ポリシーのバージョン、適用されたルール、承認またはサンプリングの要件、エスカレーションの理由、関連する検証結果。
• 人による判断： 認証済みのレビュアー、その操作に対する権限、承認または却下の結果、求められた修正、理由、タイムスタンプ、有効期限。
• 実行： 承認された操作の識別子、ワークフローとモデル設定のバージョン、実行試行の識別子、ツールの結果、外部システムが返した処理の証跡、最終状態。失敗、成功、結果不明を区別します。
• 品質レビュー： サンプリング対象になった経緯、見つかった誤りの種類、重大度、是正措置、権限ルールを変更したかどうか。
• キューの稼働状況： 到着時刻、割り当てられた担当者、待ち時間、実際のレビュー時間、期限超過の有無、引き継ぎの結果。

機微な証拠へのアクセスを制限し、秘密情報をマスキングし、保存期間のルールを設けます。可能であれば、あらゆるログに顧客データをコピーするのではなく、保護された元の記録にリンクします。判断理由と根拠は簡潔に残します。承認を監査するために、モデルの隠れた推論過程は必要ありません。

担当者、禁止する操作、エスカレーションの責任は、AI利用ポリシーに定めます。ログが記録するのは、そのポリシーが守られたかどうかです。誰も書いていないポリシーの代わりにはなりません。

操作の種類ごとに、人の確認を少しずつ減らす

自動実行へ移すのは、狭い範囲で実力が確かめられた機能です。新しい操作や重大な結果を伴う操作には、引き続きレビューを求めます。 全体をまとめた「エージェントの正確性」のスコアは、性質の異なるリスクを混ぜてしまうため、権限変更の根拠としては不十分です。

1. 1

   まずは提案だけを任せる

   エージェントには操作案を作らせ、判断は人が行います。宛先の誤り、根拠のない主張、金額の間違い、証拠の不足、不要なエスカレーションなど、誤りの種類を分類します。それらの案件から業務の実態を反映した評価セットを作り、適切なアクセス制御を設けます。

2. 2

   範囲を限定し、承認後の実行を認める

   承認を受けた場合にだけ、実行できるようにします。却下すれば実行が止まること、引数の変更で承認が無効になること、承認結果が重複しても書き込みを繰り返さないことを確認します。アクセス範囲を広げる前に、タイムアウトや外部処理の成否が不明な状況も試します。

3. 3

   適した操作をサンプリングへ移す

   確認済みのデータを使った定型的な注文状況の返信など、対象を具体的な操作群に絞ります。結果を見る前に、受け入れ基準、サンプルの選び方、レビュー担当者、停止条件を定めます。必須のエスカレーション条件は有効なままにします。

4. 4

   条件が変わったらレビューを戻す

   モデル、プロンプト、ポリシー、ツール、データソースの変更があれば、影響する権限を再評価します。重大なインシデントが起きたときや、サンプリング結果が悪化したときは、調査中、その操作の承認を再び必須にします。

有害な誤り、レビュアーによる修正、エスカレーションの見逃し、復旧に要した作業を、操作の種類ごとに追跡します。見た目だけの修正と、被害を防いだ変更は分けます。レビューした操作の件数と、対象になり得る操作の総数を、両方記録します。サンプルのエラー率はレビューした操作の件数を分母に計算し、無作為抽出と、特定の条件を狙った抽出を混ぜないようにします。少数の成功例を確認しただけでは、システム全体の信頼性は証明できません。

承認率だけでも不十分です。レビュアーが承認する理由は、出来がよいからかもしれませんし、判断材料が乏しいから、あるいはキューに圧倒されているからかもしれません。レビューの判断そのものも、定期的に確認します。人が関われば、誤りを見つける機会は生まれます。しかし、発見が保証されるわけではありません。

過大評価されがちなこと

「人がループに入っています」という説明は、その人が何を見て、何を止められるかが分かるまで不十分です。 返金が終わった後に通知を受け取る人がしているのは、事後の監督であって、実行前の承認ではありません。

「信頼できるようになるまで、すべてを承認制にする」という方針も、それだけでは足りません。基準が明確でなければ、疲労がたまり、権限を広げるかどうかが、待ち時間への苛立ちで決まりかねません。信頼の根拠にすべきなのは、操作ごとの証拠と、確実に復旧できる仕組みです。

また、人のフィードバックだけでシステムが改善することはありません。修正内容を、よりよい元データ、明確なルール、プロンプトの改訂、評価を経たモデル変更につなげる人が必要です。ループの担当者を決めるときは、その作業も含めます。

まず業務で何から始めるか

運用担当者は、エージェントが実行できる操作を洗い出し、それぞれにレビューの位置を割り当てます。 サポートの表を出発点に、実際の承認者を特定し、サービス提供を約束する時間帯にキューを担当する人がいることを確認します。

開発者は、実行時にルールを強制します。 提案された操作を保存し、そのバージョンに承認をひも付けます。却下、期限切れ、承認結果の重複、引数の変更が、想定どおりに扱われるかを確認します。モデルが自分の操作を承認できないようにします。

創業者や導入を検討する人は、操作が却下された場合と、誰もレビューしないまま期限を迎えた場合のデモを求めます。 その挙動を見れば、実運用の制御があるのか、承認通知があるだけなのかが分かります。

エージェントがすでに、明確な制限のないままメッセージを送り、金銭を動かし、顧客データを変更できるなら、すぐに対処します。ポリシーやレビューの処理能力が定まっていないなら、自律的に動ける範囲を広げるのは待ちます。外部に操作できない社内向けの下書きアシスタントであれば、新たな承認システムよりも、通常の編集レビューで足りる場合があります。

人によるレビューについてよくある質問

AIにおけるヒューマンインザループとは何ですか？

レビュー、フィードバック、意思決定を通じて、人がAIシステムの運用に参加することです。業務を行うエージェントでは、実行前に承認するのか、完了した処理を抽出して確認するのか、例外に対応するのかを明確にします。

「人をループに入れる」とは、具体的にどういう意味ですか？

人の判断を、プロセスの明示的な一部にするという意味です。有効な実装では、誰がレビューし、何を決め、どの根拠を確認するのか、そして待機中にシステムがどう動くのかを定めます。

ヒューマンインザループとエージェント型AIは同じですか？

エージェント型AIに組み込むことはできますが、別の概念です。エージェントは手順を選び、ツールを使います。一方、ヒューマンインザループは、その作業のどこに人が関与し、許可を与えるかを表します。

AIの運用に、人の判断を組み込むにはどうすればよいですか？

重大な結果を伴うツール呼び出しの前に承認を置き、エスカレーション先に担当者を配置し、対象となる完了済みの処理から、定めた方法でサンプルを抽出してレビューします。判断と結果を記録し、操作の種類ごとの証拠を使って権限を調整します。

AIがループから抜け出せなくなるのはなぜですか？

エージェントのワークフローでは、再試行の繰り返し、同じツールの反復選択、未解決の引き継ぎによって、処理が進まなくなることがあります。停止条件と、エスカレーションを引き受ける担当者を定めます。このような不具合によるループは、本記事で扱う、意図的に設ける人のレビューループとは別のものです。

AIを業務のワークフローに取り入れるための実践ガイドは、ニュースレターに登録してお読みください。