ヒューマン・イン・ザ・ループとは、エージェントを完全に監督なしで動かすのではなく、それ以外は自動化されたエージェントのワークフローに人間を意図的に組み込んでおく設計を指す。情報源全体を通じて、この用語は 7 つの異なるパターンに用いられている。開発者がエージェントとリアルタイムでペアを組むこと、より長い自律的な実行の途中に置かれる非同期の承認ゲート、エージェントが提案する内容を人が確認・編集するための構造化されたレビュー画面、エージェントが単独でタスクを完了できないときにたどるエスカレーション経路、エージェントとそれが操作する対象システムとのあいだのネットワーク経路に置かれる強制ポイント、どの行動でそもそも人間を呼び込むかを決める選択の仕組み、そして AI が提案し、何を恒常的なルールとするかは人間だけが決める承認のステップである。
用法
リアルタイムの意味では、Osmani はコーディングエージェントと働くための 2 つのモードからなるメンタルモデルの一方に、ヒューマン・イン・ザ・ループのセッションを置いている。それは、開発者が関与し続け、エージェントの作業中に軌道修正を行い、エージェントに欠けているコンテキストを要する判断 — アーキテクチャの決定、厄介なリファクタリング、プロダクトの微妙なニュアンス、曖昧な要件 — を下す、ローカルで手厚く関わるセッションである。これと対比されるのが、単純な機能追加、明確なパターンを持つマイグレーション、テスト生成、ドキュメントの更新、依存関係の更新、対象を絞ったリファクタリングといった、範囲が限定され十分に仕様化されたタスクを非同期に実行するクラウドやバックグラウンドのセッションである。
長時間稼働するエージェントについての後の投稿は、同じ用語を別のパターンに用いている。それは、それ以外は何時間、何日も監督なしで動くエージェントの内部での、委任された承認である。この投稿はこれを、「ヒューマン・イン・ザ・ループ」のよくあるが弱い実装と呼ぶものと対比している — 状態を JSON にシリアライズし、Webhook を発火させ、誰かが応答してくれることを願う。その後、状態は古くなり、通知は埋もれ、エージェントは少しだけ異なる世界へと再デシリアライズされる。これに対して長時間稼働向けのランタイムは、エージェントが完全な実行状態（推論の連鎖、ワーキングメモリ、ツールの履歴、保留中の行動）を保ったままその場で一時停止し、人間の時間が何時間も過ぎるあいだ計算資源をまったく消費せず、判断が下されれば 1 秒未満のレイテンシで再開できるようにするものだと説明されている。Google の Mission Control がこのパターンをあるベンダーが実装した例として挙げられており、投稿は根底にあるパターンはベンダーを問わず機能すると述べている。
AgentClick: ターミナル AI エージェントのためのスキルベースのヒューマン・イン・ザ・ループ・レビュー層 は第 3 の力点を加える。人間が名目上ループの中にいるかどうかよりも、インターフェースがその人に実際に何をさせてくれるかのほうが重要だ、というものである。著者らは、ターミナルの出力は推論のトレース、ツールのログ、提案された行動を 1 つのストリームに交互に並べるため、何がレビューを必要としているのかを見分けにくいこと、小さな局所的な編集であってもユーザーが自由形式の修正を入力しなければならないためフィードバックが煩わしいこと、そして重大な行動が不透明なイベントや二者択一のプロンプトとして提示されるため、的を絞った確認や修正の余地がほとんどないことを論じている。彼らの答えである AgentClick は、単に実行をゲートで止めるのではなく協働を改善することを目標として掲げるレビュー層である。ユーザーはレビュー対象の成果物の単位で、承認、直接の編集、内容の削除、制約の調整、的を絞った書き直しの要求を行うことができ、著者らはこれがエージェントの出力がおおむね正しいが局所的な変更を必要とする場合に最も重要になると論じている。彼らはまた、レビューを選好を捕捉するチャネルとしても説明している。理由のタグが付いた編集は、エージェントが後の実行で読むメモリファイルに書き込まれるため、修正は一度きりの上書きとしてではなく、将来の振る舞いを形づくるものとして機能する。
エージェント構築の実践ガイド は、ガードレール の扱いの最後の項目として、第 4 の方向からこの用語に行き着く。そこでは人間による介入は、エージェントがタスクを完了できないときに制御を円滑に引き渡せるようにする仕組みである — カスタマーサービスであれば人間の担当者へエスカレーションし、コーディングエージェントであればユーザーに制御を戻す。OpenAI はこれを、デプロイの初期段階で特に重要なものとして提示しており、そこでは失敗の特定、エッジケースの発見、評価サイクルの確立に役立つとし、ユーザー体験を損なうことなくエージェントの実世界での性能を改善する方法として位置づけている。
第 5 の立場は、ゲートはエージェントの中にもレビューツールの中にもなく、両者のあいだのデータ経路に属するというものである。ベンダーの hoop.dev は、エージェントが Git サーバー、コンテナレジストリ、CI/CD オーケストレーターに直接認証すると、本人確認はできても、ポリシーが一時停止、検査、あるいは人間の判断の要求を行えるポイントがなく、その操作は記録されるとしても対象側のログにしか残らないと論じる。また、事後的なプルリクエストのレビューでは遅すぎるとも論じる。成果物はすでにバージョン管理に存在しており、誰かが目を通す前にシークレットを露出させたり下流のジョブを起動させたりしている可能性があるからである。その答えは、リクエストを受け取り、プロトコルレベルでペイロードを検査し、ポリシーが求める場合には権限のあるレビュアーに回し、同意があったときにだけ転送する — その過程でセッションと判断を記録しながら — レイヤー 7 のゲートウェイである。この議論はベンダー自身の hoop.dev ゲートウェイを宣伝する投稿の中で示されているため、ここでは枠組みと製品を切り離すことはできない。
第 6 の立場は、定義はそのままに問いを変える。Port の 本当にすべてのループに人間が必要か？ は、この用語に狭い作業上の定義 — エージェントが作業を行うが、人間の承認なしには不可逆な変更を行えない監督モデル — を与えたうえで、この言葉はオンにする単一の設定として扱われがちだが、実際には足元で変化し続けてきたパターンだと論じる。エージェントが変更を提案するだけだった間は、すべての出力をレビューすれば十分だった。エージェントがサービスをデプロイし、ワークロードを再起動し、インシデントを解決するようになると、すべての行動をレビューすることはスケールしない。そのため重要なのは、もはや人間がループの中にいるかどうかではなく、何が人間を呼び込むのかである。その答えは、正反対の仕方で判断する 2 種類のガードレールである。1 つは ルールベースのゲート、つまり事前に書かれ、毎回同じように発動する決定論的な条件であり、もう 1 つは リスクベースのゲート、つまりエージェントがライブのコンテキストに照らして特定の行動をスコア化し、設定された閾値を超えた場合にだけ人間が呼び込まれるものである。どちらを選ぶかの判断基準は、その判断が参照（ルックアップ）なのか判断（ジャッジメント）なのかである。この議論はベンダー自身の Port プラットフォームを推奨する投稿の中で示されているため、第 5 の立場と同様に、ここでは枠組みと製品を切り離すことはできない。
第 7 の立場は、ゲートをエージェントの行動から完全に外し、エージェントが後に評価の基準とされるルールの側に移す。コーディングガイドライン運用をAIで自動化し、レビュー知見を資産化する では、CyberAgent のチームが AI にプルリクエストのレビューコメントを収集させてコーディングガイドラインの候補にまとめさせ、それをプルリクエストとして提示し、どれを採用するかは人が決める。著者が人間を介在させる理由として挙げるのは、コーディングガイドラインは要約ではなくチームの規範であり、「もっともらしいことが書いてある」だけでは十分ではない、ということである。具体的に挙げられている危険は、レビューコメントがその時々の文脈 — そのリポジトリ特有の事情、当時のリリースの優先順位、例外として許容された実装、意図的に選んだトレードオフ — に大きく依存しうること、そしてその文脈を持たない AI が候補を確定させると、誤ったガイドラインが残り続けるおそれがあることである。そのためこの投稿が引く分担は、リスクによるものではなく役割によるものである。AI には候補を生み出す仕事が、人間にはそれを規範として残すかどうかを決める仕事が割り当てられ、著者はこれによって判断の妥当性を保ちながらスピードを維持できると論じている。
適用される場面
リアルタイムの意味は、センスと判断が支配的で、エージェントには欠けていて人が作業の進行に合わせて補わなければならないコンテキストがある作業 — アーキテクチャの決定、厄介なリファクタリング、曖昧な要件、微妙なプロダクト上の判断 — に適用され、タスクを投げて後で戻ってくるのではなく、エージェントと積極的にペアを組める開発者がいることを前提とする。
委任された承認の意味は、それ以外は自律的に動く長時間稼働のエージェントが人間の承認を必要とする判断ポイントに達した場合に適用され、状態を外部にシリアライズし、通知を発火させて返事を待つランタイムではなく、完全な実行状態 — 推論の連鎖、ワーキングメモリ、ツールの履歴、保留中の行動 — を保ったままエージェントをその場で一時停止させておけるランタイムを前提とする。そのようなランタイムがない場合の失敗モードは、人間が対応する前に状態が古くなったり、Webhook の通知が埋もれたりすることである。
成果物レビューの意味は、行動する前に提案を提出して結果を待つようにさせられるエージェントと、それを表示するためのターミナル以外の画面を前提とする。AgentClick の著者らは、自分たちが特定した障壁は専門家でないユーザーに最も重くのしかかり、エージェントがリモートやヘッドレスのインフラ上で動く場合にはさらに深刻になると論じる。そこではターミナルは協働の媒体として不十分であるだけでなく、しばしばアクセスすることすらできないからである。この研究はデモ論文であり、3 つのウォークスルーは著者ら自身が統制されたユーザー調査ではなく能力の例示として提示しているため、主張されている利点は測定されたものではなく実演されたものである。
エスカレーションの意味は、作業のフェーズではなくそのトリガーによって定義される。OpenAI は 2 つを挙げている。1 つは失敗の閾値を超えること — エージェントのリトライや行動に設定された上限であり、例えば複数回試みても顧客の意図を理解できない場合 — であり、もう 1 つは機微な、不可逆な、あるいは重大な結果を伴う高リスクの行動で、その例としてユーザーの注文のキャンセル、大口の返金の承認、支払いの実行が挙げられている。OpenAI は 2 つ目のトリガーを、それらの行動の恒久的な性質としてではなく、エージェントの信頼性に対する確信が高まるまでの常設の要件として提示している。
強制ポイントの意味は、エージェントのトラフィックを、それが話すプロトコル — ベンダーは Git、HTTP、「関連する API」を挙げている — を読み取るプロキシ経由でルーティングできること、そしてエージェントではなくゲートウェイが対象サービスの認証情報を保持できることを前提とする。ベンダーはこれを認証情報の漏洩リスクを減らすものとして提示している。この意味が移し替えるのは、人間にいつ尋ねるかではなく、その問いかけがどこで強制されるかである。ベンダーの主張は、エージェントから対象への直接のアクセスには、ポリシーが一時停止、検査、あるいは判断の要求を行えるデータ経路上のポイントがない、というものである。また、これはその見返りが開発の観点ではなく監査の観点 — セッションのログ、各変更を誰が承認したかの記録、コンプライアンス報告のためにエクスポートできる保存済みのマスクされた差分 — で述べられている意味でもある。
選択の意味は、エージェントが単に提案するだけでなく、すでに実際に状態を変える行動を取っていることを前提とする。そこで述べられている失敗例は、コードのマージとプルリクエストだけをゲートで止め続けるチームであり、Port は自社のミートアップでエンジニアリングリーダーに調査したところ、会場の半数がいまだにそうしていたと報告している。どちらのゲートも、参照するための、組織のシステムについてのライブでつながった視点を前提としている。投稿自身のまとめによれば、確認すべき実データのないルールは当て推量にすぎず、薄いコンテキストに基づくリスクスコアは悪い当て推量を数値の陰に隠してしまうため、古いコンテキストや部分的なコンテキストを読むゲートは自信たっぷりに誤った判断を下す。リスクベースの側はさらに、時間をかけて調整される閾値、モデルが何をどのコンテキストに基づいてスコア化したかを含むあらゆる判断のトレース、そしてモデルが確信を持てない場合に人間によるブロッキングレビューへフォールバックすることを前提とする。これらの主張はベンダー自身のものであり、測定は添えられていない。
承認の意味は、出力が行動ではなくルールであるものであり、そのためゲートで止める対象が他とは異なる。判断は、エージェントが行動しようとする時点ではなく、過去のレビューコメントの期間 — CyberAgent のワークフローではデフォルトで 7 日間であり、呼び出し元のリポジトリが設定するスケジュールに従う — を対象にまとめて行われる。前提となるのは、候補が人が低コストで判断を下せる形で届くことであり、その実装はそれを、各候補を優先度、背景、引用とともに一覧にし、除外用のチェックボックスを添えたプルリクエストとして提供している。述べられている失敗モードは、観察されたものではなく、それを避けるために作られたものである。すなわち、コメントを状況依存のものにしていた文脈が判断の時点で見えなかったために採用されてしまった誤ったガイドラインである。報告されている効果 — チームの視点が AI レビューの指摘に現れ始めたこと、人間によるレビューが仕様の妥当性やビジネスロジックへと移っていったこと — は、最近導入された仕組みについての著者の初期の観察であり、測定は示されていない。
関連用語
サンドボックス化、チェックポイントと再開、長時間稼働エージェント、承認疲れ（Approval Fatigue）、ガードレール、エージェント構築の実践ガイド、ルールベースのゲート、リスクベースのゲート、エージェント型コードレビュー