ヒューマンインザループ（Human In The Loop、略称HITL）とは、AIや自動化システムの学習・判断・実行の流れの中に人間を組み込み、人の判断を通じて正確性と安全性の向上を図る設計のことです。読み方は「ヒューマン・イン・ザ・ループ」。AIの出力を全件そのまま使うのでも、全件を人が見るのでもなく、どの判断を人に戻すかを決める設計だと捉えると実装に落とし込めます。この記事では、Human On The Loop・Out Of The Loopとの違い、人に回す件数をしきい値で決める方法、AIエージェントのツール実行を承認制にするコード、EU AI法第14条の要件、そして人を挟んでも安全にならない条件までを、実行して確かめたコードと一次情報で整理します。
まとめ：ヒューマンインザループの意味と設計の要点
- 意味：AIの学習データ作成・推論結果の確認・実行前の承認に人を組み込み、人の判断をモデルや運用の改善へ戻す設計です。
- HOTL・HOOTLとの違い：実行時の制御では、In The Loopは対象操作に人の判断を挟み、On The Loopは自動処理を人が監視・介入し、Out Of The Loopは人の入力なしで動きます。
- 件数の決め方：確信度しきい値で人に回す割合を決めます。乳がん診断データの検証では、しきい値0.90で13.0%を人に回すと自動確定分の誤りが6件から0件になりました。
- エージェントでは承認：LangGraphの
interrupt()やOpenAI Agents SDKのneeds_approvalで、ツール実行の直前に止めて人の判断を待てます。 - 規制：EU AI法第14条が高リスクAIに人間の監督を求めます。附属書IIIの高リスク用途への適用は2027年12月2日、附属書Iは2028年8月2日です。
- 落とし穴：人を置いても、人がAIを信じ切れば監督は形だけになります。自動化バイアスへの対策まで設計して初めてHITLが機能します。
ヒューマンインザループの意味・読み方と「ループ」が指すもの
Human In The Loopは「ヒューマン・イン・ザ・ループ」と読み、略称はHITL（エイチアイティーエル）です。日本語では「人間参加型」「人間介在型」と訳されます。ループは、データを集めてモデルが判断し、その結果を見て改善するという繰り返しの輪のことで、人がその輪の内側にいて判断の一部を担う状態を指します。
機械学習の文脈で人が入る場面は3つあります。学習データに正解を付ける場面、モデルの出力を本番で使う前に確かめる場面、そして本番で起きた誤りを直して再学習に戻す場面です。生成AIとAIエージェントが普及してからは、これに「エージェントがメール送信や決済などの操作を実行する前に人が承認する場面」が加わりました。検索で「ヒューマンインザループ AI」と調べる人が知りたいのは、多くの場合この4つのどこに人を置くかという設計の話です。
HITL・HOTL・HOOTLの違い：実行前承認と監視・介入
人の関与を3段階に分ける呼び方は、Human Rights Watchが2012年11月に公表した報告書「Losing Humanity」の定義が原典としてよく参照されます。同報告書は兵器の自律性を論じたもので、人間の命令があって初めて標的を選び武力を使うものをHuman-in-the-Loop、人間のオペレーターが動作を上書きできる監視下で動くものをHuman-on-the-Loop、人間の入力や相互作用なしに動くものをHuman-out-of-the-Loopと定義しました。以下では、この区分を業務システムの実行時の制御に当てはめて比較します。機械学習でのHITLには、実行前承認に限らずラベル付けや出力修正も含まれます。
| 区分 | 人の位置 | AIが動く条件 | 業務での例 |
|---|---|---|---|
| Human In The Loop（HITL） | 判断の内側 | 人の承認後 | 送金・契約・医療診断の確定 |
| Human On The Loop（HOTL） | 監視役 | 常時。人は止められる | 不正検知の自動ブロック |
| Human Out Of The Loop（HOOTL） | 関与なし | 常時。人は止めない | 迷惑メール振り分け |
違いを分けるのは「人が動かないと処理が止まるか」です。HITLは人が承認しなければ処理が進まないので安全側に倒れますが、人の処理能力が上限になります。HOTLは処理を止めずに済む代わりに、人が見落とせばそのまま実行されます。後述するUberの自動運転事故は、HOTLで監視役が機能しなかった例です。誤りの代償が大きく取り消せない操作はHITL、件数が多く後から取り消せる操作はHOTLという分け方が実務の基準になります。
機械学習で人を組み込む3か所：ラベル付け・推論時の振り分け・事後レビュー
ラベル付け品質の評価：一致率とCohenのκ係数
学習データの正解を人が付ける工程では、作業者によって判断がばらつくこと自体が最大の品質リスクです。同じデータを2人に付けさせ、一致の度合いを測ってからガイドラインを直します。このとき単純な一致率だけを見ると、偶然の一致を実力と取り違えます。次の例は10件中8件が一致していますが、両者とも「ok」を7割付けているため偶然でも一致しやすく、偶然分を差し引くCohenのκ係数は0.52まで下がります。
from sklearn.metrics import cohen_kappa_score
a = ["ok","ok","ok","ng","ok","ok","ng","ok","ng","ok"]
b = ["ok","ok","ng","ng","ok","ok","ok","ok","ng","ok"]
agree = sum(x == y for x, y in zip(a, b)) / len(a)
print(f"単純一致率: {agree:.2f}")
print(f"κ係数: {cohen_kappa_score(a, b):.2f}")単純一致率: 0.80
κ係数: 0.52「一致率80%を目標にする」と決める場合は、どちらの指標で測るかを先に決めておきます。ラベル設計や作業者の割り振りまで含めた手順はデータラベリングの設計と一致率の測り方で、作業の種類と外注時の品質管理はアノテーションの種類とやり方で扱っています。
推論時のレビュー件数：確信度しきい値による振り分け
本番の推論でHITLを入れるときの基本形は、モデルの確信度がしきい値以上なら自動で確定し、未満なら人のレビューキューへ回す振り分けです。しきい値を上げるほど人に回る件数は増え、自動確定の誤り件数は減るか横ばいになります。ただし誤りがどこで0件になるか、それ以上上げても減らなくなるかはデータ次第です。この関係は机上では決められないので、検証データで実測します。次のコードは、scikit-learn同梱の乳がん診断データ（569件）を半分に分け、ロジスティック回帰の確信度で振り分けた例です（Python 3.12・scikit-learn 1.9.1で出力を確認）。
from sklearn.datasets import load_breast_cancer
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
X, y = load_breast_cancer(return_X_y=True)
X_tr, X_te, y_tr, y_te = train_test_split(X, y, test_size=0.5, random_state=0, stratify=y)
model = make_pipeline(StandardScaler(), LogisticRegression(max_iter=1000)).fit(X_tr, y_tr)
proba = model.predict_proba(X_te)
conf = proba.max(axis=1) # 予測クラスの確信度
pred = proba.argmax(axis=1)
print(f"全件自動の誤り: {(pred != y_te).sum()}件 / {len(y_te)}件")
for th in (0.80, 0.90, 0.95, 0.99):
auto = conf >= th # しきい値以上は自動確定
review = (~auto).sum() # 残りは人間レビューへ
miss = (pred[auto] != y_te[auto]).sum()
print(f"しきい値{th:.2f}: 人間レビュー {review:3d}件({review/len(y_te):5.1%}) / 自動確定の誤り {miss}件")全件自動の誤り: 6件 / 285件
しきい値0.80: 人間レビュー 19件( 6.7%) / 自動確定の誤り 2件
しきい値0.90: 人間レビュー 37件(13.0%) / 自動確定の誤り 0件
しきい値0.95: 人間レビュー 53件(18.6%) / 自動確定の誤り 0件
しきい値0.99: 人間レビュー 93件(32.6%) / 自動確定の誤り 0件全件を自動で確定すると285件中6件を誤りますが、しきい値0.90で37件（13.0%）を人に回すと、自動確定した248件の誤りは0件になりました。0.95以上に上げても誤りはそれ以上減らず、人の作業だけが増えます。今回試した4候補では、誤り0件を満たす最も低いしきい値が0.90でした。本番の採用値は、レビュー工数と誤りの損失も考慮して選び、選定に使っていないデータで評価します。
人に回す割合が決まれば、必要な人員も計算できます。1日1万件を処理する業務で13%を人に回すと1,300件、1件30秒で確認するなら約10.8時間で、1人日を8時間とすると約1.4人日分です。これは確認作業だけの工数で、休憩や再確認、到着件数の偏りは含みません。レビュー待ちが処理全体を止めないよう、この見積もりはモデルを作る前に出しておきます。
事後レビューの運用：再学習への還元と抜き取り監視
人が直した判定は監査や改善のために記録します。再学習に使う場合は、ラベルの品質や利用条件を確認してから学習データへ組み込みます。MLOpsの運用基盤に、レビュー結果の保存、一定件数がたまった時点での再学習、旧モデルとの比較評価、昇格判定までを用意します。
注意したいのは、人が見るのが確信度の低い案件だけだと、再学習データが「迷う案件」に偏ることです。自動確定した側の誤りは誰も見ないので、モデルが自信を持って間違える領域は直りません。自動確定分からも一定割合を無作為に抜き出して人が確認し、自動確定の誤り率そのものを監視します。上の例で0.90のしきい値が本番でも妥当かどうかは、抜き取り検査に加え、後日確定する正解や苦情・訂正の記録などでも継続して評価します。
RLHF・アクティブラーニングとHITLの関係
RLHFもアクティブラーニングも、HITLの考え方を特定の工程に当てはめた手法です。HITLは人をどこに置くかという設計全般を指す上位の概念で、個々の手法はその実装の一つにあたります。
| 用語 | 人が入る工程 | 人がすること |
|---|---|---|
| HITL | 学習・推論・実行の全般 | 承認・修正・ラベル付け |
| アクティブラーニング | 学習データ作成 | モデルが選んだ迷う事例に正解を付ける |
| RLHF | LLMの調整 | 複数の回答を比べて順位を付ける |
| LLM-in-the-loop | 人の代わりにLLMが入る | LLMが評価や修正を担う |
アクティブラーニングは、学習に有用な事例を選んでラベルを取得する手法です。不確実性に基づく選択はその一方式で、少ないラベルでの性能向上を目指しますが、効果はデータや選択方法に依存します。RLHFの3段階の仕組みはRLHFの仕組みと採用判断で、人の代わりにLLMを評価役に置く設計はLLM-in-the-loopの3類型で解説しています。
AIエージェントのツール実行を人が承認する実装
AIエージェントでは、HITLの対象が出力の確認から行動の承認へ広がります。MCP（Model Context Protocol）の仕様（2026-07-28版）はツールの項で「For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.」と書き、ツール呼び出しを拒否できる人を置くよう求めています。実装では、エージェントの処理を途中で止めて状態を保存し、人の判断を受け取ったら同じ状態から再開する仕組みが必要です。
LangGraphの承認制御：interruptによる中断と再開
LangGraphでは、ノードの中でinterrupt()を呼ぶと（公式ドキュメント）グラフが止まり、渡した値が呼び出し側へ返ります。人の判断はCommand(resume=...)で同じthread_idに渡すと再開します。次のコードは、固定テンプレートで作った請求書メールの文面を承認・修正・却下する模擬例です。AIによる文面生成や実際のメール送信は行いません（langgraph 1.2.14、Python 3.12で実行）。
from typing import TypedDict
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, START, END
from langgraph.types import interrupt, Command
class State(TypedDict):
to: str
body: str
result: str
def draft(state: State):
return {"body": f"{state['to']} 様、請求書を再送します。"}
def approve(state: State):
# ここで停止し、承認画面に出す値を返す。再開時はこのノードの先頭からやり直す
decision = interrupt({"to": state["to"], "body": state["body"]})
if not isinstance(decision, dict) or decision.get("action") != "approve":
return {"result": "却下: 送信しない"}
body = decision.get("body", state["body"]) # 人が文面を直した場合
return {"result": f"送信: {body}"}
g = StateGraph(State)
g.add_node("draft", draft)
g.add_node("approve", approve)
g.add_edge(START, "draft")
g.add_edge("draft", "approve")
g.add_edge("approve", END)
app = g.compile(checkpointer=InMemorySaver()) # 中断状態を保存し、後から再開するために必要
cfg = {"configurable": {"thread_id": "invoice-42"}}
first = app.invoke({"to": "株式会社A"}, cfg)
print(first["__interrupt__"][0].value) # 承認待ちの内容
final = app.invoke(Command(resume={"action": "approve", "body": "株式会社A 様、修正版の請求書を送ります。"}), cfg)
print(final["result"]){'to': '株式会社A', 'body': '株式会社A 様、請求書を再送します。'}
送信: 株式会社A 様、修正版の請求書を送ります。実装で押さえる点は2つです。1つ目はcheckpointerで、これを渡さずにcompileしてもinterrupt()で止まる値は返りますが、状態が保存されないため再開できません。実際にCommand(resume=...)を渡すと「RuntimeError: Cannot use Command(resume=…) without checkpointer」で落ちました。本番ではメモリ上のInMemorySaverではなく、PostgreSQLなどの永続化先を使います。2つ目は、再開時に中断したノードが先頭から実行し直されることです。interrupt()より前にメール送信やDB更新を書くと二重に実行されるため、副作用は承認の後ろに置きます。
LangChain・OpenAI Agents SDK・Vercel AI SDKの承認指定
グラフを自分で組まない場合は、エージェントのフレームワークが用意する承認指定を使います。どれも「ツールごとに承認の要否を指定し、止まった実行を人の判断で再開する」点は共通です。
| フレームワーク | 承認の指定 | 再開のしかた |
|---|---|---|
| LangChain 1.4系 | HumanInTheLoopMiddlewareのinterrupt_on | Command(resume=…) |
| OpenAI Agents SDK 0.23系 | @function_tool(needs_approval=True) | state.approve/rejectの後にRunner.run |
| Vercel AI SDK 7系 | generateTextのtoolApproval | 承認応答をmessagesに足して再呼び出し |
LangChainのHumanInTheLoopMiddlewareは、interrupt_onに書かなかったツールを既定で自動承認します。承認が必要なツールを書き漏らすとそのまま実行されるので、新しいツールを足すたびに一覧を見直します。Trueを指定したツールは承認・編集・却下・返答の4種類の判断を受け付けます。Vercel AI SDKは7系で、v6で入ったツール定義のneedsApprovalを非推奨にし、generateTextやstreamTextに渡すtoolApprovalへ移しました（AI SDKのツール呼び出しドキュメント）。旧コードは動きますが、新規に書くならtoolApprovalを使います。また、プロバイダ側で実行されるツールはこの承認設定の対象外です。ミドルウェアの全体像はLangChain v1.0のcreate_agentとミドルウェア、v6からの移行はVercel AI SDK v6とv7の違い、ツール定義からトレースまで通しで組む手順はAIエージェントの作り方にまとめています。
EU AI法第14条とAI事業者ガイドラインが求める人間の監督
EU AI法（Regulation (EU) 2024/1689）第14条は、高リスクAIシステムを人が実効的に監督できるよう設計することを求め、第4項で監督を担う人ができるようにすべきことを5つ挙げています。
- (a) システムの能力と限界を理解し、異常や予期しない挙動を監視できる
- (b) 出力を自動的に、あるいは過度に信頼してしまう傾向（automation bias）を自覚できる
- (c) 出力を正しく解釈できる
- (d) システムを使わない、出力を無視・上書き・取り消すと判断できる
- (e) 停止ボタンなどで安全な状態のままシステムを止められる
第5項は、附属書IIIの1(a)にあたる遠隔生体識別システムについて、識別結果に基づく措置の前に、必要な能力・訓練・権限を備えた少なくとも2人による個別の検証・確認を原則として求めています。ただし、法執行・移民・国境管理・庇護の用途では、EU法または国内法がこの要件を不相応と判断する場合に例外があります。適用時期は2026年7月27日に発効したAI Omnibus（Regulation (EU) 2026/1744）で後ろ倒しされ、附属書IIIの高リスク用途（雇用・教育・信用評価など）は2027年12月2日から、附属書Iの製品に組み込まれる高リスクAIは2028年8月2日から適用されます。リスク分類と域外適用の考え方はEU AI Actのリスク分類と日本企業の対応、日本のAI法との違いはAI法の日EU比較を参照してください。
日本では、総務省と経済産業省の「AI事業者ガイドライン（第1.2版）」（2026年3月31日）が、公平性の項目で「適切なタイミングで人間の判断を介在させる利用を検討する」としたうえで、「人間の判断が自動化バイアスに左右されないような対策（脚注省略）を講じるべきである」と書いています。EUの法的義務と日本のガイドライン上の指針では位置付けが異なりますが、人を置くだけでなく、自動化バイアスへの対策も扱う点は共通しています。社内の統制にどう落とすかはAIガバナンスの枠組みで整理しています。
人を挟んでも安全にならない条件：自動化バイアスと形だけの承認
HITLを入れれば安全になるという期待は、監督役の人が注意を払い続けることを前提にしています。この前提が崩れた例が、2018年3月に米アリゾナ州テンピでUberの自動運転試験車が歩行者をはねた死亡事故です。米国家運輸安全委員会（NTSB）の報告書HAR-19/03は、事故の推定原因を、車両オペレーターが走行環境と自動運転システムの動作を監視しなかったことと認定しました。オペレーターは個人の携帯電話に目を向けており、NTSBはこの長時間の注意散漫を「automation complacency（自動化への慢心）の典型的な影響」と位置づけ、Uberがこの慢心に対処する仕組みを持っていなかったことも事故の要因に挙げています。
業務システムの承認画面でも同じことが起きます。AIの判定がほぼ毎回正しいと、人は中身を読まずに承認ボタンを押すようになり、HITLは記録上だけのものになります。EU AI法第14条第4項(b)がautomation biasを名指ししているのはこのためです。設計で打てる手は次のとおりです。
- 承認画面にAIの判定だけでなく根拠（参照した文書、確信度、変更前後の差分）を出し、人が判断材料を見ずに押せない構成にする
- 正解が分かっている確認用の案件を一定割合で混ぜ、見落とし率をレビュー担当ごとに測る
- 1人が1日に承認する件数に上限を置き、前章の人員見積もりと合わせて超えたらしきい値か人員を見直す
- 承認者と承認時刻、承認までの所要時間をログに残す。所要時間が極端に短い承認が続けば形骸化のサイン
逆に言えば、これらを用意できない体制で「最後は人が確認する」と書くのは、責任の所在を人に移すだけで安全性は上がりません。人を置くなら、その人が機能しているかを測る仕組みまでを一組で設計します。
HITLを採用すべき業務と見送ってよい業務の判断基準
次のいずれかに当てはまる業務はHITLを採用します。
- 誤りが人命・健康・安全に直結する（診断支援、設備制御、自動運転の遠隔監視）
- 誤りが法的責任や取り消せない金銭移動につながる（送金、契約締結、採用・与信の判定）
- EU AI法の附属書IIIなど、規制で人間の監督が義務になる用途にあたる（第14条が求めるのはリスクと利用状況に見合った監督で、全処理の実行前承認を一律に求めるものではありません）
- AIエージェントが外部へ送信・削除・決済など取り消せない操作をする
反対に、誤りの代償が小さく後から直せて、件数が膨大な業務（迷惑メール振り分け、商品のおすすめ表示、社内文書の自動タグ付け）では、全件のHITLは見送ってHOTLか完全自動で構いません。この種の業務に人の承認を入れると、承認待ちが積み上がるうえ、前章の自動化バイアスで承認が形だけになりやすいからです。人に回す割合は一律に決めず、検証データ上の誤り、誤判断の損失、担当者の処理能力から設定し、本番では自動確定側の抜き取り検査で見直します。
どの判断を自動にしてどこに承認を残すかは、要件定義の段階で承認画面とレビューキューまで含めて決めておくと後戻りが少なくなります。承認フローを組み込んだAIシステムの設計・開発は生成AI開発・AI受託開発でご相談いただけます。
よくある質問：ヒューマンインザループの意味・違い・導入
ヒューマンインザループとは簡単に言うと何ですか？
AIに任せきりにせず、AIの判断の流れのどこかに人の確認や承認を組み込む設計のことです。人が直した結果をモデルや運用の改善に戻す設計もありますが、実行前の承認だけを行う設計もHITLに含まれます。
Human In The LoopとHuman On The Loopの違いは何ですか？
実行時の制御を比べる場合、In The Loopは対象操作に人の承認や判断を挟む方式、On The Loopは自動処理を人が監視して必要に応じて介入する方式です。取り消せない操作はIn The Loop、件数が多く後から直せる操作はOn The Loopが向いています。
ヒューマンインザループはAIの自動化と矛盾しませんか？
矛盾しません。確信度が高い案件は自動で確定し、低い案件だけを人に回すのが基本形です。本記事の検証では、13.0%を人に回すだけで自動確定分の誤りが0件になりました。
生成AIやAIエージェントにもヒューマンインザループは必要ですか？
出力をそのまま外部に出す用途や、エージェントが送信・決済・削除を実行する用途では必要です。MCPの仕様も、ツール呼び出しを拒否できる人を置くよう求めています。LangGraphのinterrupt()やOpenAI Agents SDKのneeds_approvalで実装できます。
ヒューマンインザループの事例にはどんなものがありますか？
医療画像診断で医師が最終判断する運用、金融の不正検知で疑わしい取引だけを担当者が確認する運用、製造業の外観検査でAIが迷った品だけを検査員が見る運用が代表的です。人に回す範囲は用途によって異なり、確信度や金額で絞る場合も、対象となる判断をすべて専門家が確認する場合もあります。
