Human-in-the-loop（ヒューマンインザループ）とは、AIが作業を進める途中に人間が確認・判断・承認する地点を残す設計手法です。AIが得意な生成と、人間が担うべき事実確認や取り返しのつかない決定を分け、事故を減らすために使われます。OECDのAI原則も、AIシステムに「人間中心の価値」と「説明責任」を組み込むことを求めています[1]。
Human-in-the-loopの基本
AIはパターン処理や生成に強い一方、事実の真偽や「公開してよいか」のような価値判断は苦手です。Human-in-the-loopは、AIが下書きや候補を出し、人間がその都度確認する構成を想定します。学術分野でも、AIシステムの安全性や説明責任を論じる際に、人間の監視を含める枠組みとして扱われます。
定義
Human-in-the-loop は、AIの処理プロセスの中に人間の判断節点を組み込み、その節点で処理を止めて人間の入力（確認・修正・承認）を待つ方式です。単にAIの出力を後から見るのではなく、プロセスの一部として人間を置きます。
Human-on-the-loop等との違い
似た言葉に次のものがあります。
- Human-in-the-loop：処理の中に確認地点を置く。止めて人間の入力を待つ。
- Human-on-the-loop：AIが処理を回し、人間は後から監視・介入する。
- Human-in-command：人間が主導し、AIは補助にとどまる。
本サイトでは、工程の中に確認地点を置く「in-the-loop」の設計に絞って説明します。用語の使い分けにこだわるより、「AIの出力を人間がどこで見るか」を決めることが先です。
AIが作業し、人間が判断する設計
AGENT WORKBENCHでは、この関係をカードの担当で表します。
- AI：調査・下書き・分類・提案
- HUMAN：出典確認・事実照合・最終承認
- SHARED：表現調整・保存・ログ（AI下書き＋人間仕上げ）
人間確認を残すべき場面
| 場面 | なぜ人間か |
|---|---|
| 事実 | AIの引用や数値が誤っていることがある |
| 公開 | 取り返しがつかない |
| 削除 | 復元困難 |
| 支払い | 金銭的影響が大きい |
| 個人情報 | 漏えいリスク |
| セキュリティ | 破壊的変更のおそれ |
| 外部への連絡 | 誤送信の影響が広い |
automation bias（自動化バイアス）
automation bias とは、人間がAIの出力を過信し、自分の判断を它に任せてしまう傾向です。確認地点を置いても、人間が「AIが言っているから正しいだろう」と流してしまえば、確認は形だけになります。NISTのAIリスク管理でも、人間の監督が実効性を持つよう、過信を防ぐ設計が求められます[2]。
meaningful human control（実質的な人間統制）
「人間が関与している」ことと「人間が実質的に統制している」ことには差があります。実質的統制の条件は、概ね次の通りです。
- 人間が見るべき内容を前もって決めている
- 確認できる情報（出典・根拠・差分）が提示されている
- 承認しない選択肢（reject）が実際に効く
- 誰がいつ承認したかが記録に残る
EUのAI規則でも、高リスクAIには「人間の監視（human oversight）」が要件の一つとされています[3]。
形骸化する確認
確認地点が形骸化する典型パターンです。
- 承認ボタンはあるが、何を確認すべきか書かれていない
- AIの出力が長文で、人間が読み通せない
- reject しても次の工程が進んでしまう
- 誰が承認したか記録に残らない
これらを防ぐには、確認すべき項目を設計図に先に書き、承認の記録を残します。
高影響操作
特に人間の承認を分離すべきは「高影響操作」です。以下は代表例です。
- 公開・削除・上書き（情報の不可逆変化）
- 外部送信・公開API呼び出し（第三者への影響）
- 支払い・契約（金銭・法的影響）
- 権限変更・本番反映（システムへの影響）
過剰承認の問題
確認を多く置きすぎると、かえって形骸化します。人間は多数の承認を流すうち感覚が麻痺します。確認は「内容・リスク・最終承認」の3地点に絞り、AIが連続して得意な作業はまとめるのが現実的です。
承認地点の設計表
| 工程の種類 | 確認地点 | 確認内容 |
|---|---|---|
| 事実を伴う生成 | 生成直後 | 出典・数値・意図 |
| コード変更 | 差分の直後 | 危険な変更・秘密情報 |
| 公開・削除 | 直前 | 範囲・影響・rejectの有無 |
| 外部送信 | 直前 | 宛先・内容・同意 |
3種類のチェックポイント
内容確認
意図通りか、事実かを確認します（出典確認・事実照合・意図チェック）。
リスク確認
壊れる・漏らす・公開範囲のミスがないかを確認します（危険な変更確認）。
最終承認
公開・実行の直前の承認サインです。
記事作成の実例
- 目的を決める（HUMAN）
- 必要な情報を集める（AI）
- 出典を確認する（HUMAN）
- 比較表を作る（AI）
- 下書きを作る（AI）
- 事実を照合する（HUMAN）
- 表現を整える（SHARED）
- 最終承認する（HUMAN）
- 公開する（HUMAN）
AIコーディングの実例
- コードを生成する（AI）
- 差分を見る（HUMAN）
- テストする（HUMAN）
- 危険な変更がないか確認する（HUMAN）
- 最終承認する（HUMAN）
確認地点が多すぎる場合
往復が極端に多いと、どこで何を確認したかが曖昧になります。「内容・リスク・最終承認」の3地点に絞り、AIが連続して得意な作業はまとめるのが現実的です。
よくある誤解
- 「Human-in-the-loop = 人間が全部やる」ではない
- 「AIが間違えない前提」ではない
- 「承認ボタンがあれば十分」ではない（見るべき内容が決まっている必要がある）
FAQ
- Human-in-the-loopは日本語で何と言いますか？
- 「人間参加型」や「人間フィードバック型」と訳されることもありますが、本サイトでは「AIに人間の確認を残す設計」として説明します。
- SHAREDはHuman-in-the-loopですか？
- SHAREDはAI下書き＋人間仕上げの共有作業です。確認地点としては「内容確認」に近い位置づけです。
- 承認ボタンを用意すれば十分？
- 不十分です。何を確認すべきかを事前に決め、rejectが効き、記録が残ることが実質的統制の条件です[2]。
- 確認を多く置くほど安全？
- 過剰な確認は形骸化を招きます。高影響操作に絞って配置します。
- AI/HUMAN/SHAREDは公的基準？
- いいえ。AGENT WORKBENCH独自の実務モデルです。公的文書は「人間監視を組み込む」方向を示します[1][3]。
- Webアクセシビリティとの関係は？
- 確認UIは操作可能・理解可能である必要があり、WCAGの要件（キーボード操作、ラベル等）と整合します[4]。
Workbenchで承認地点を設計する
参考資料
- OECD AI Principles — OECD 原文を確認 確認日：2026-07-13
- AI Risk Management Framework (AI RMF 1.0) — NIST 原文を確認 確認日：2026-07-13
- Regulation (EU) 2024/1689 (AI Act) — EUR-Lex (EU) 原文を確認 確認日：2026-07-13
- WCAG 2.1 Quick Reference — W3C 原文を確認 確認日：2026-07-13
- ワークフロー設計のガイド
- AIコーディングのガイド
- AGENT WORKBENCH ツール：https://agent-workbench.kawaii-girl.com/
最終確認日：2026-07-13