2026年10月10日、Microsoft の Satya Nadella 氏が X への投稿で、AI のモデルには「緊急ブレーキ」が要ると述べました。
TechCrunch の報道によると、権限のある人がモデルの作業をいつでも途中で止められることと、重要な行動を人が読める改ざんできない記録に残すことを挙げています。
同じ投稿には、モデルは侵害されている前提で、最初から封じ込めるべきだという一文もありました。
参考: Microsoft's Satya Nadella says AI models need an 'emergency brake'（TechCrunch）
個人の使い方にも、同じ発想が出てきています。
Anthropic の Cowork に副業の定型作業を任せている人の note には、投稿すること・お金を使うこと・ファイルを消すことは、必ず選択肢の形で聞いてもらうと書かれていました。
参考: AIに「聞く」のをやめて「任せる」にしたら、朝起きると仕事が進んでいた（note）
作業は AI に任せつつ、決めどころにだけ人の判断を残す設計を、ヒューマン・イン・ザ・ループ（Human-in-the-Loop、略して HITL）と呼びます。
どこに人を挟み、どうすれば形だけの承認にならないかが分かると、エージェントに任せる範囲を決めやすくなります。
ヒューマン・イン・ザ・ループは人が判断の輪に入る設計
ヒューマン・イン・ザ・ループとは、AI が処理を進める流れの途中に、人の確認や判断を必ず通る段階を組み込むことです。
ここでの「ループ」は、入力を受けて判断し、行動するまでの一巡を指しています。
その輪の中に人が入っていて、人が決めないと先へ進まない状態が「イン・ザ・ループ」です。
似た名前の RLHF も人の評価を使いますが、こちらはモデルを学習させる段階の話でした。
HITL が扱うのは、学習を終えたモデルが実際に動いている最中の、人の関わり方になります。
入力と出力を機械的に検査するガードレールとも、役割が違います。
ガードレールは人の判断を待たずに自動で通すか止めるかを決め、HITL は人が決めるまで待ちます。
人の関わり方は3段階に分けられる
人がどこまで関わるかを、in・on・out の3段階に分ける言い方があります。
この3段階をはっきり定義した例に、Human Rights Watch が2012年に公開した、自律型兵器についての報告書「Losing Humanity」があります。
報告書の定義を、AI エージェントの場面に置き換えると次のようになります。
| 段階 | 報告書の定義（要約） | エージェントに置き換えた例 |
|---|---|---|
| Human-in-the-Loop | 人の命令があって初めて行動する | 実行の前に毎回、人が承認する |
| Human-on-the-Loop | 人の監督の下で行動し、人が覆せる | 自動で進み、人は見ていて止められる |
| Human-out-of-the-Loop | 人の入力も関与もなく行動する | 承認も監視もなく最後まで進む |
同じ報告書は、監督が限られていて実質的に人が関われない on-the-loop は、out-of-the-loop と同じだと位置付けています。
人が「いる」だけでは、輪に入っていることにならないという見方は、後で触れる落とし穴にもつながります。
参考: Losing Humanity: The Case against Killer Robots（Human Rights Watch）
規則の側でも人の関与が求められている
人を挟む設計は、法律や利用ポリシーの条件にもなり始めています。
EU の AI 法は第14条で、高リスクの AI システムに「人による監督」を求めました。
条文には、監督する人が出力を無視・上書き・取り消しできることや、「停止」ボタンなどで安全な状態に止められることが並んでいます。
参考: Article 14: Human Oversight（EU Artificial Intelligence Act）
Anthropic の利用ポリシーも、法律・医療・金融などの高リスク用途では、資格のある人が提案を確認してから本人に届けることを条件にしています。
人を挟む場所は4つある
人の判断を入れる場所は、大きく分けて4つあります。
Nadella 氏が挙げた「途中で止める」と「記録に残す」も、この中に含まれます。
承認ゲート
承認ゲートは実行の前に立てる関所で、人が許可するまで次の操作に進みません。
置く場所は、取り消しのきかない操作の直前が基本になります。
冒頭の note の線引きにある投稿・支払い・削除は、どれも後から元に戻しにくい操作でした。
Claude Code の default モード（画面上の表示は Manual）も、ツールを初めて使うときに許可を求める作りです。
中断
中断は、動いている最中の AI を人が止められるようにしておく仕組みです。
EU の AI 法が挙げた「停止」ボタンも、Nadella 氏の「作業の途中で一時停止か停止ができること」も、この層に当たります。
止めた後に、作業が中途半端な状態で残らないことも欠かせません。
条文も、止まった後に安全な状態になることまでを求めていました。
差し戻し
差し戻しは、許可か却下かの二択に加えて、理由や修正を添えて返す道を用意しておく方法です。
OpenAI の Agents SDK では、却下するときに rejection_message で、モデルに返す説明を指定できます。
LangGraph の公式ドキュメントには、止めた時点のツール呼び出しの引数を人が書き換えてから再開する使い方が載っています。
冒頭の note のように、選択肢の形で聞かせるのも、二択を避ける工夫の1つでしょう。
監査ログ
監査ログは、AI が何をして、誰が何を承認したかを残す記録です。
Nadella 氏は、意味のある行動はすべて、改ざんできず人が読める証拠として残すべきだと述べています。
記録があれば、毎回は承認しない on-the-loop の運用でも、後から人が確かめられます。
承認ゲートは事前、中断は最中、差し戻しは判断の時点、監査ログは事後と、受け持つ時間が分かれていると考えると整理しやすくなります。
開発の道具ではこう実装されている
主なエージェントの開発の道具は、HITL を部品として用意しています。
ここでは、2026年10月12日時点の公式ドキュメントで確かめた3つを取り上げます。
OpenAI Agents SDK
ツールに needs_approval=True を付けると、そのツールの呼び出しは実行前に止まります。
needs_approval には関数も渡せるため、引数を見て「件名に返金を含むときだけ承認を求める」といった条件も書けます。
公式ドキュメントの例から、該当部分を抜き出すと次のとおりです。
@tool(needs_approval=True)
async def cancel_order(order_id: int) -> str:
return f"Cancelled order {order_id}"
async def requires_review(_ctx, params, _call_id) -> bool:
return "refund" in params.get("subject", "").lower()
@tool(needs_approval=requires_review)
async def send_email(subject: str, body: str) -> str:
return f"Sent '{subject}'"
# 以下、Agent の定義は省略止まった実行は RunResult.interruptions に承認待ちの一覧として返り、各項目にはツール名と引数が入っています。
人は result.to_state() で状態を取り出し、state.approve() か state.reject() で答えてから、Runner.run() で再開します。
状態は state.to_json() などで保存できるので、承認を後回しにして別のプロセスで再開することもできます。
ただし、保存した状態を読み戻す関数は、その中身も送ってきた人も認証しないと、ドキュメント自身が注意を促していました。
承認する人が本当に権限を持っているかは、アプリの側で確かめる必要があります。
参考: Human-in-the-loop（OpenAI Agents SDK）
LangGraph
LangGraph では、処理の途中で interrupt() を呼ぶと、グラフの状態を保存して止まります。
再開には Command(resume=…) を使い、渡した値がそのまま interrupt() の戻り値になります。
状態を保存するチェックポインタと、どの実行かを示す thread_id が必要です。
再開したときは、止まった行からではなく、そのノードの先頭からやり直します。
そのため、interrupt() より前に書いた API の呼び出しは、再開のたびにもう一度走ってしまいます。
公式ドキュメントは、副作用のある処理を interrupt() の後ろに置くか、別のノードに分けるよう勧めています。
参考: Interrupts（LangGraph）
Claude Code
Claude Code は、どこまで人に聞くかを権限モードで切り替えます。
主なモードを、人の関わり方と並べると次のようになります。
| モード | 人の関わり方 |
|---|---|
| default | ツールを初めて使うときに許可を求める |
| acceptEdits | 作業ディレクトリ内のファイル編集と一部のファイル操作は、聞かずに通す |
| auto | 定型の確認を出さず、実行の前に分類器が依頼と合っているかを確かめる |
| bypassPermissions | 一部の操作を除いて、許可の確認を飛ばす |
default は in-the-loop、bypassPermissions は out-of-the-loop に近い位置にあります。
auto はその間で、人の代わりに機械が見張る形です。
公式ドキュメントは bypassPermissions を、コンテナや仮想マシンのような隔離した環境でだけ使うよう求めています。
参考: Configure permissions（Claude Code Docs）
落とし穴は承認疲れと形だけの承認
人を挟めば、それだけで安全になるわけではありません。
Anthropic は2026年3月25日のエンジニアリングブログで、Claude Code の利用者は許可の確認の93%を承認していると書きました。
同じ記事は、承認を重ねるうちに中身を見なくなる状態を「承認疲れ」と呼んでいます。
既存の逃げ道はサンドボックスと、確認をすべて飛ばすフラグの2つで、その間を狙って分類器に判断を任せる auto モードを作ったという説明でした。
参考: How we built Claude Code auto mode: a safer way to skip permissions（Anthropic）
承認疲れとサンドボックスの関係は、別の記事で詳しく扱っています。
EU の AI 法の第14条は、もう一つの落とし穴として「自動化バイアス」を名指ししています。
自動化バイアスとは、AI の出力を自動的に、あるいは過度に頼ってしまう傾向のことです。
監督する人がこの傾向を自覚していられるようにすることが、条文の求めの1つに入っています。
承認ボタンを押す人が出力をそのまま信じているなら、その承認は Losing Humanity が指摘した「実質的な out-of-the-loop」に近づきます。
形だけにしないための手がかりは、ここまでの一次情報からいくつか拾えます。
- 承認ゲートは、冒頭の note の投稿・お金・削除のように、取り消しのきかない操作に絞る
- 承認を求める画面には、何をどの引数で実行するかを出す（OpenAI の承認待ちの項目はツール名と引数を持つ）
- 二択にせず、選択肢や理由つきの差し戻しの道を用意する
- 承認する人に権限があるかを、アプリの側で確かめる
- 人が見ていない間の失敗に気づけるよう、出力が届いたかを確かめる仕組みを別に持つ
最後の項目は、冒頭の note の筆者が、エラーが出ないまま朝の出力が無かった日があったと書いていたことに基づいています。
out-of-the-loop の区間を残すなら、そこが黙って止まったときに気づける仕掛けも、人の関わり方の一部です。
最後に
ヒューマン・イン・ザ・ループは、AI の処理の途中に、人の判断を必ず通る段階を置く設計でした。
人を挟む場所は承認ゲート・中断・差し戻し・監査ログの4つで、主な開発の道具はどれも部品を用意しています。
一方で、承認の93%が通る実態や自動化バイアスを考えると、人を置いただけで輪に入ったことにはなりません。
人に聞く場面を取り返しのつかない操作に絞り、聞くときは判断の材料を添えることが、承認を形だけにしないための近道です。
以上です。
コメントを残す