【AI駆動開発】AIエージェントに「人間の承認」を残す設計：Human-in-the-Loop超入門

はじめに

こんにちは、エンジニア5年目の嶋田です。
この記事を開いていただき、ありがとうございます！

前回、「MCP・エージェント・ツール」という用語を整理する記事を書きました。

そのときは「AIエージェントは、目標を渡すと自分で計画・実行までしてくれる」という便利さの話が中心でした。

ただ、その後にこんな疑問が浮かびました。

エージェントが「自分で実行まで進める」のはいいけど、
決済とか、ファイル削除とか、重要な操作まで勝手にやられて大丈夫なの？
暴走したらどうするの？

実際、社内で決済導線のE2EテストをPlaywright MCPで自動化した記事を読んだときも、「テスト環境だからいいけど、これが本番の決済処理を直接操作するエージェントだったら、どこまで任せていいんだろう」と気になりました。

調べてみると、この疑問に対する答えが、ちょうど業界としても整理され始めているところでした。

キーワードは Human-in-the-Loop（ヒューマン・イン・ザ・ループ）、略して HITL です。

この記事は、「AIエージェントに、どこまで任せて、どこで人間の承認を挟むべきか」が分からない人 に向けた、超入門ガイドです。

• できるだけ専門用語を使わずに
• 身近なたとえで
• 実務でどう考えればいいかが分かるように

まとめます。

※この記事は2026年8月時点の情報をもとにしています。この分野は動きが速いので、正確な内容は各公式ガイドラインを確認してください。

目次

• まず全体像：なぜ「人間の承認」が必要なのか
• Human-in-the-Loop（HITL）とは
• 人間の関与、4つのレベル
• 「確認してください」だけでは足りない理由
• どこに承認ポイントを置くべきか
• 国内外のガイドラインの動き
• まぎらわしい用語の違い
• まとめ
• 参考文献

まず全体像：なぜ「人間の承認」が必要なのか

細かい話に入る前に、全体像を先に見ておきます。

前回の記事で、AIエージェントは「目標を渡すと、自分で計画・実行・確認まで進める」ものだと説明しました。

これは裏を返すと、人間が細かく指示しなくても、AIが勝手にいろいろ実行してしまう ということでもあります。

• ファイルを削除するツールを呼ぶ
• 外部にメールを送るツールを呼ぶ
• 決済を確定するツールを呼ぶ

こういった 取り消しにくい操作 まで、AIが自律的に進めてしまったらどうなるか。

ここで登場するのが、Human-in-the-Loop（HITL）という考え方です。

イメージとしては、「エージェントの実行フローの途中に、人間の確認ポイントを差し込む」 という設計です。

ここから、それぞれを詳しく見ていきます。

Human-in-the-Loop（HITL）とは

まず「Human-in-the-Loop」からです。

言葉をそのまま訳すと「輪の中に人間がいる」となりますが、これだとピンと来ません。

かみ砕くと、こうなります。

Human-in-the-Loopとは、AIの判断・実行プロセスに、人間の確認・承認・介入をあらかじめ組み込んでおく設計のこと。

たとえば、AIエージェントに「このバグを直して」と頼んだとします。

• コードを読む → 自動でOK
• 原因を調べる → 自動でOK
• 修正案を考える → 自動でOK
• 実際にファイルを書き換える → ここで人間に確認
• 本番環境にデプロイする → ここでも人間に確認

このように、「AIに任せてよい部分」と「人間が確認すべき部分」を、あらかじめ分けておく のがHITLの考え方です。

ここで一つ、調べていて印象的だった観点があります。EU AI Actという、AI規制の代表的な法律の第14条では、高リスクなAIシステムに対して、人間が監督者としてAIの能力と限界を理解し、出力を無視・上書きでき、必要であれば安全に停止できることが求められています¹。

条文では「effectively（効果的に）」監督できることが要件になっており、形だけ人間を配置しても、実質的な監督とはみなされない という点が明記されています。つまりHITLの本質は、「人間が読むこと」そのものではなく、「人間が介入する手段を実際に持っていること」 だと言えそうです。

普通にAIエージェントを使うだけの場合との違いは、次の2点です。

観点	HITLなしのエージェント	HITLありのエージェント
実行の流れ	目標から実行まで全自動	重要な操作の前で一旦停止する
リスク	暴走・誤操作に気づきにくい	取り返しのつかない操作を防げる
速度	速い（人を待たない）	やや遅い（承認待ちが発生する）

人間の関与、4つのレベル

エージェントに対する人間の関わり方は、大きく4段階に分けて整理されます。

イメージとしては、こうです。

人間の関与レベルとは、「AIの実行に、人間がどれだけ・どのタイミングで関わるか」の度合いのこと。

レベル	ざっくり言うと	身近なたとえ
in-the-loop（都度承認）	実行前に、毎回人間が承認する	新人が一つずつ「これでいいですか？」と確認しながら進める
on-the-loop（監視）	基本は自動、異常時だけ人間が介入する	ベテランが横で見守っていて、変だと思ったら止める
out-of-the-loop（完全自動）	人間は基本的に関与しない	完全に一人で任せている状態
in-command（統治）	人間が目的・ルール・停止条件そのものを決める	現場に立ち会わないが、緊急停止ボタンの設置基準を決める管理者

たとえば、

• 「社内文書の要約を作って」→ out-of-the-loopで十分（間違っても被害が小さい）
• 「顧客に送るメールの内容を確認して」→ on-the-loopが妥当（普段は自動、怪しい時だけ人が見る）
• 「決済を確定する」「本番データを削除する」→ in-the-loopが必須（毎回、人間の承認が要る）
• 「エージェントにどこまでの操作を許可するか、そのものを決める」→ これはin-commandの仕事（現場の承認とは別レイヤーの話）

というふうに使い分けます。

先ほどのPlaywright MCPの記事を思い出すと、テスト実行そのものはサンドボックス環境で完結しているので、実質out-of-the-loopで問題ありません。ただ、もし将来「本番環境の決済導線を、エージェントが直接操作する」という話になったら、それは間違いなくin-the-loopの領域に入ってきます。同じ「決済を扱うエージェント」でも、対象が検証環境か本番環境かで、必要なレベルがまったく変わる というのは、記事を書きながら気づいた点でした。

「確認してください」だけでは足りない理由

ここまで、HITLの基本的な考え方を見てきました。ただ、実際に運用を考えたときに、もう一つ引っかかったことがあります。

「AIの出力は、最後に人間が確認してください」というルールだけを決めて、それで安心してしまっていいのか、という点です。

例えば、こんな状況を考えてみます。

あるエージェントが「このコードは仕様通りです」と自信満々に報告してきた。
レビュー担当者は忙しく、AIの説明がもっともらしかったので、深く読まずに承認してしまった。

これは、「人間が確認する」という工程自体は存在しているのに、実質的にはノーチェックで通っている 状態です。

こうなる理由の一つが、自動化バイアス（automation bias） と呼ばれる傾向です。AIがもっともらしい出力を返すと、人間はそれを過信しやすくなります。文章が自然で、専門用語が含まれていて、断定調で書かれているほど、この傾向は強くなります。EU AI Actでも、監督者がこの自動化バイアスを認識していることが、監督の要件として挙げられています¹。

つまり、HITLを「導入した」と言うためには、少なくとも次の3つが揃っている必要がありそうです。

1. 何を確認すればいいのか、レビューする側に分かる基準があること（「確認してください」だけでは基準にならない）
2. 確認した結果、承認以外の選択肢（差し戻す・止める）を実際に取れること（権限がなければ、確認は儀式で終わる）
3. 確認した記録が残ること（記録がなければ、同じ見落としが繰り返される）

前回の記事で紹介したPlaywright MCPの決済テストの例で言えば、「AIがテストを完成させた」で終わらせず、そのテストコードが実際にどう動くかを人間が確認し、問題があれば差し戻す、という工程が入っていたからこそ、安定した回帰テストに仕上がっていたのだと思います。

どこに承認ポイントを置くべきか

「全部の操作を人間が承認する」だと、AIエージェントの良さ（速さ・自動化）が失われます。
かといって「全部自動」だと、暴走や誤操作のリスクを抑えられません。

判断基準は「不可逆性 × 影響範囲」

そこで使われる考え方が、「不可逆性」と「影響範囲」の2軸 です。

• 不可逆性：やり直しがきくか、きかないか
• 影響範囲：影響が自分だけか、他人・外部にまで及ぶか

この2軸で操作を整理すると、こうなります。

操作の例	不可逆性	影響範囲	承認は必要か
ファイルを読み込んで内容を確認する	低い（やり直せる）	狭い（自分の作業だけ）	不要（out-of-the-loopでOK）
ローカルのテストコードを書き換える	低い（Git等で戻せる）	狭い	基本不要
外部にメールを送る	高い（送信後は取り消せない）	広い（相手に届く）	必要（in-the-loop）
本番データを削除する	高い（元に戻せない可能性）	広い（サービス全体に影響）	必要（in-the-loop）
決済を確定する	高い（お金が動く）	広い（顧客・会社に影響）	必要（in-the-loop）

つまり、

「やり直しがきいて、影響が狭い操作」は自動化し、
「やり直しがきかない、または影響が広い操作」だけ、人間の承認を挟む。

というのが、実務での基本方針になります。

具体的な仕組みの例

調べていく中で、実務でよく挙げられている仕組みが、主に3つありました。

1. 監査ログ：エージェントが「何を読み、どのツールを使い、どう判断し、何を実行したか」を記録しておく。事故が起きたときに、後から原因を追えるようにする。
2. サンドボックス（検証環境）：いきなり本番環境につなげず、まずは検証環境・読み取り専用環境で動かしてみる。問題なさそうなら、段階的に権限を広げていく。
3. 停止手段（キルスイッチ）：エージェントが異常な動きをしたときに、すぐに止められる仕組みをあらかじめ用意しておく。

これらは、前回の記事で説明した「MCP」の話ともつながります。

MCPで道具（ツール）とAIをつなぐこと自体は便利になりましたが、「つないだ先で何をしてよいか」までは、MCPという規格そのものは保証してくれません。だからこそ、権限管理・監査ログ・承認フローといった、HITLの仕組みを別途設計する必要がある、ということです。

国内外のガイドラインの動き

ここで、実際の制度面の動きにも触れておきます。

国内：AI事業者ガイドライン

日本では、経済産業省と総務省が「AI事業者ガイドライン」という文書を出しています。これは法律ではなく自主規制ガイダンスですが、調達基準やセキュリティ評価の場面で、実質的な標準として参照されることが多いものです。

• 2024年4月：v1.0 公表
• 2025年3月：v1.1 公表
• 2026年3月31日：v1.2 公表²

このv1.2改訂で、AIエージェントに対して、外部アクションや重要な変更の実行前に「人間の判断（Human-in-the-Loop）」を求める方針が、明確に盛り込まれました。

背景には、企業でのAIエージェント導入が急速に進んだことがあります。「人間が確認してからAIが出力する」という、これまでのチャットボット的な前提だけでは、自律的に行動するエージェントの実態に追いつかなくなってきた、ということです。

海外：EU AI Act

海外では、EU AI Act第14条 が、高リスクAIシステムに対する人間の監督（human oversight）を明確に義務付けています¹。

先ほども触れましたが、条文で「effectively（効果的に）」という言葉が使われている点が、個人的には一番印象に残りました。単に人を配置すればいいのではなく、その人が実際に理解・判断・介入できる状態になっているか まで問われている、という読み方ができます。

つまりHITLは、もはや「あると丁寧」な仕組みではなく、AIエージェントを本番導入するうえで、実質的な前提となりつつある考え方 だと言えそうです。

まぎらわしい用語の違い

ここまで出てきた用語は、似ていて混同しやすいです。
違いを表で整理しておきます。

用語	ひとことで言うと	役割
AIエージェント	自律的に計画・実行するAI	目標を渡すと動く
HITL	人間の承認を組み込む設計思想	どこで人が確認するかを決める
in-the-loop	都度承認するレベル	毎回、実行前に人が見る
on-the-loop	監視するレベル	普段は自動、異常時だけ介入
自動化バイアス	人間がAI出力を過信してしまう傾向	HITLが形だけになる主な原因
監査ログ	実行内容の記録	事後に原因を追跡できるようにする

もうひとつ、よく混同される 「HITLの4レベル」と「エージェントの権限設定」の違い も触れておきます。

• HITLの4レベル：いつ・どのタイミングで人間が関わるかの話
• 権限設定：エージェントにそもそも何をする権限を与えるかの話

「そもそも決済ツールを呼べないようにする」のが権限設定、「決済ツールは呼べるが、実行前に必ず人間が確認する」のがHITL、というイメージです。両方を組み合わせて設計するのが実務的です。

まとめ

今回は、AIエージェントを実務で使ううえで欠かせない、Human-in-the-Loopという考え方を整理しました。

最後に、全体をもう一度まとめます。

用語	覚え方
HITL	AIの実行フローに、人間の確認ポイントを差し込む設計
in-the-loop / on-the-loop	新人のように都度確認する／ベテランのように普段は任せて異常時だけ見る
自動化バイアス	人間はAIの出力を過信しやすい、という前提を持つこと
判断基準	「不可逆性 × 影響範囲」で、承認が要るかを決める

流れとしては、

AIエージェントは自律的に実行まで進められる。
でも、取り消しがきかない・影響が広い操作は、人間の承認を挟むべき。
ただし「確認してください」というルールを置くだけでは、自動化バイアスによって形だけになりやすい。
基準・権限・記録の3つが揃って、初めてHITLは機能する。
この考え方は、国内のAI事業者ガイドラインやEU AI Actでも明確に求められ始めている。

という関係でした。

前回の記事で「MCPはAIと道具をつなぐ共通の差込口」と説明しましたが、つないだ先で何をどこまで自動で任せるか は、また別に設計しないといけない話だと分かりました。

この記事が、「AIエージェントに何を任せて、どこで人間が確認すべきか」を考えるきっかけになれば嬉しいです。

参考文献

• MCP（Model Context Protocol）とは | IBM（前回記事の参考文献、本記事と地続きの内容として再掲）

1. Article 14: Human Oversight | EU Artificial Intelligence Act - EU AI Act（Regulation (EU) 2024/1689）における高リスクAIシステムの人間による監督義務、自動化バイアスの認識、出力の無視・上書き・停止に関する要件の根拠として参照しました。 ↩ ↩² ↩³

2. 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日公表） - 日本におけるAIガバナンス、AIエージェントに対するHuman-in-the-Loop要件の根拠として参照しました。 ↩