HITL 設計の体系 ─ 6 箇所 × 6 実装 + 4 リスク

業務に投入できるエージェントとデモエージェントの最大の違いは、人間との接点が設計されているかだ。完全自律のエージェントは、責任を取れる業務には乗せられない。一方、すべて承認待ちのエージェントは、承認疲れで結局形骸化する。

本章では、自律と監視のスペクトルを業務シナリオに合わせて設計するための HITL 設計マトリクスを提示する。

HITL の 3 つの設計軸

HITL（Human-in-the-Loop）の設計は、3 つの軸で整理できる。

軸	内容
どこに差し込むか（6 箇所）	不可逆操作前 / 高信頼度判断 / 低信頼度出力 / 自己申告 / 監査要件 / 異常検知
どう実装するか（6 パターン）	Synchronous / Asynchronous / Watch mode / Spot check / Tier-based / Retroactive
何に注意するか（4 リスク）	承認疲れ / Rubber-stamp / 承認者ボトルネック / 自動化バイアス

軸 1：差し込み箇所のタクソノミ（6 箇所）

OpenAI Operator System Card、Anthropic Auto Mode、Galileo / Prefactor / Strata の各資料を横断して帰納した 6 つの差し込み箇所。

1. 不可逆操作の前

• 決済・データ削除・本番デプロイ・force push・リモートブランチ削除
• Operator は銀行送金を 100% 確認
• Anthropic Auto Mode は「シェルコマンド・外部 API・プロジェクト外 FS 操作」を分類器審査対象に置く

2. 高信頼度が必要な判断

• VIP 顧客・契約承認・人事評価
• Galileo「VIP clients or public-facing decisions demand executive review」

3. 低信頼度の出力

• 信頼スコア閾値以下
• Strata の time-boxed lanes（Eric Olden, 2026-04-14）：低リスク 15 秒 / PII 2 分 / 金融出金 15 分の制限時間制。具体的な信頼スコア閾値は自社で定める

4. エージェント自身の自己申告

• Claude Code Auto Mode の「3 連続拒否 / 累計 20 回拒否」での自動エスカレーション
• 「自分は確信が持てない」と LLM が言ったときに HITL に渡す

5. 監査要件のチェックポイント

• EU AI Act 2026 年 8 月施行で healthcare / credit / employment / critical infrastructure は high-risk 義務
• 規制業界では HITL が法的要請

6. 異常検知のフィードバック

• Cursor mission control、Replit Agent 3 self-healing 後の偏差検知
• 通常からの逸脱が検出されたときに人間にエスカレーション

軸 2：実装パターン 6 種

#	パターン	内容	代表例
1	Synchronous approval	状態をシリアライズして人間承認を待つ。durable step	Claude Code 手動承認・Operator の sensitive sites
2	Asynchronous approval	並行作業しつつログを残し事後審査。SLA 4-8h でバックアップへエスカレーション	OpenAI Codex Auto-Review
3	Watch mode	人間が常時画面を見ているモード。take-over 可能	ChatGPT Agent watch mode（メール・金融サイト自動発動）
4	Spot check	ランダム抽出で事後抜取	大量低リスク PR の auto-merge 後の抽出レビュー
5	Tier-based escalation	リスクレベルで承認者切替（4h で reviewer、8h で team lead）	Hyperping 標準・Prefactor の risk-based triage
6	Retroactive review	完全自律後の事後レビュー。決定理由ログとセット	OpenAI alignment auto-review、AstraSync の blockchain 監査

各パターンの詳細

1. Synchronous approval：第1部 ch7 で扱った durable step として書く。state をシリアライズし、人間が承認したら resume する。承認待ちで sandbox が消えても OK な構造が必須。

2. Asynchronous approval：エージェントは仮で実行してログを残し、人間が後から審査する。SLA を必ず設定（例：4 時間以内に reviewer、8 時間で team lead にエスカレーション）。

3. Watch mode：人間が常時画面を見ているモード。ChatGPT Agent では sensitive sites（メール・金融）で自動的に watch mode を強制発動する。

4. Spot check：100 件の auto-merge PR からランダム 5 件を選んで人間がレビュー。承認疲れを避けつつ品質保証する。

5. Tier-based escalation：リスクレベルに応じて承認者を切り替える。低リスクは reviewer、中リスクは team lead、高リスクは executive、というふうに。

6. Retroactive review：完全自律で実行した後、決定理由ログを必ず残し、後から人間または別エージェントが審査する。OpenAI Codex Auto-Review が代表例で、約 99% を auto-approve、200× ユーザー承認削減（OpenAI 公式は “200× less often than manual approval” と表記、OpenAI alignment 公式）。

6 パターンの組み合わせ：Anthropic Auto Mode の 2 段階分類器

Claude Code Auto Mode は 6 パターンのハイブリッドを実装している（2026-03-24 リリース）。

graph TB
    Input[エージェントの操作要求]
    C1{ホワイトリスト?}
    C2{リポジトリ内編集?}
    C3{危険操作?}

    Auto[即承認]
    Retro[Retroactive review<br/>VCS 追跡で事後審査]
    Sync[Synchronous classifier 審査<br/>分類器が自動判定]
    HITL[人間 HITL]

    Input --> C1
    C1 -->|Yes| Auto
    C1 -->|No| C2
    C2 -->|Yes| Retro
    C2 -->|No| C3
    C3 -->|分類器が安全と判定| Sync
    C3 -->|分類器が危険と判定| HITL

Auto Mode の正直な情報開示：「false-negative 17% を許容可能だが慎重審査の代替ではない」。これは HITL を完全に置き換えるのではなく、人間の承認頻度を下げることを目的とした設計だ。

軸 3：4 つのリスク

HITL を入れるだけでは安全にならない。HITL 自体に固有のリスクがある。

1. 承認疲れ（Approval Fatigue）

20 件目以降は、reviewer が表層パターンに頼って中身を吟味しなくなる（Franklin et al., Google DeepMind, 2025 を引用）。承認は 1 キーストロークで済むが、却下は理解と説明が必要という非対称性が、承認に流れる方向に働く。 ── aipatternbook: Approval Fatigue

経験則：原典の Franklin et al. の指針は「ten is a number a human can evaluate honestly」── つまり 1 セッション 10 件以下に保つのが honest review の限界線で、20 件を超えると pattern-match に頼って中身が読まれなくなる。

2. Rubber-stamp 化

承認者が中身を理解せずに「approve」だけ押す現象。技術的には「human reviewed」だが実質的には自律と変わらない。Curve Labs は「emotionally legible decision summaries」を提唱：承認者が読める形で意思決定理由を要約する。

3. 承認者ボトルネック

AstraSync の試算（Tim Williams, AstraSync CEO, 2025-07-03、自社の blockchain 検証サービスの正当化文脈である点に注意）：

AI 50ms vs 人間 180,000ms = 3,600 倍速度減

AI コード生成の加速で、制約が下流（人間レビュー）に移動する。HITL を verification（検証）のためだけに残すと、scale しない。

4. 自動化バイアス

承認連続成功で独立検証が止まる。攻撃者が悪意ある操作を routine の流れに紛れ込ませる攻撃面になる（Molten.bot の指摘）。

✅ 4 リスクへの対処
─────────
1. 承認疲れ → bounded autonomy + steering loop（バッチ単位で論理的作業をまとめてレビュー）
2. Rubber-stamp → emotionally legible decision summaries、決定理由を読める形で
3. 承認者ボトルネック → HITL を「速度」ではなく「責任」に絞る
4. 自動化バイアス → spot check + retroactive review で抜き打ち

「全自律 vs 全承認」の二者択一は罠

Auto Mode の 93% 自動承認実態は、業界の方向を示している：「ユーザーが手動承認の 93% を実際に許可している」という事実から、Anthropic は Auto Mode を作った。

つまり、現実は二者択一ではなく、リスクティアベースのハイブリッドだ。

graph LR
    LR[Low Risk<br/>93% を auto] --> Spot[Spot check<br/>抽出]
    MR[Medium Risk] --> Retro[Retroactive<br/>事後レビュー]
    HR[High Risk] --> Sync[Synchronous<br/>同期承認]
    UR[Unknown / Self-doubt] --> HITL[HITL<br/>人間判断]

設計の出発点として、Strata の HITL ガイド（Eric Olden, 2026-04-14）は time-boxed lanes（low-risk 15 秒、PII 2 分、金融出金 15 分）を提示している。「不可逆 0.85 / 可逆 0.70 / 30 日後リキャリブレーション」のような閾値はソース確認できないため、自社で定めるのが現実的[要検証 0.85/0.70/30 日 の出典は再特定できず]。

HITL は「速度」ではなく「責任」のために残す

ここが重要な設計哲学だ。HITL を入れる目的を **「verification（検証）」**ではなく 「accountability（責任）」 に絞ると、設計が収束する。

❌ 検証のための HITL
─────────
- 全部承認させる → ボトルネック化、承認疲れ、rubber-stamp
- 「人間がチェックしているから安全」と思い込む → 17% を見逃す

✅ 責任のための HITL
─────────
- 「誰が、いつ、なぜ承認したか」を残す
- audit trail に WHY approved を記録
- EU AI Act / SOC2 / 内部監査の要件に応える
- 検証は eval / spot check / classifier に分散させる

これが EU AI Act 対応の本筋だ。

2026 の主要事例

ChatGPT Agent watch mode（2025-07-17 launch）

• sensitive sites（メール・金融）で常時監視を要求
• take-over 自由
• prompt injection monitor + user confirmation との 3 層防御の一部

Anthropic Claude Code Auto Mode（2026-03-24）

• Sonnet 4.6 ベースの transcript classifier
• 2 段階フィルタ（fast token / chain-of-thought）
• 3 連続拒否 or 20 累計でエスカレーション
• classifier が agent の自己メッセージと tool 出力を見ない設計（「説得的な正当化」回避 → 推論盲だが攻撃耐性高）

OpenAI Codex Auto-Review（2026-04）

• 約 99% を auto-approve、200× ユーザー承認削減
• 「メインエージェントは task 完遂最適化、Auto-review は narrower job」と責任分離
• メインとは別の独立エージェントが境界判定

Sema4.ai Control Room

• Build → Publish → Deploy → Work の lifecycle 管理
• enterprise VPC 内、versioning / observability
• HITL 機能の具体的記述は公開ドキュメント上は限定的[要検証]

Devin の human review

• タグ付けで Devin に PR を作らせる
• Claude Code が review コメントを書き、Devin が応答ループ（agent on agent review）
• 「unit testing playbook」を人間が書き fleet of Devins が大量実行

❌ アンチパターン：HITL 過多 / HITL 放棄

❌ HITL 過多
─────────
症状：
- 全承認でエージェントの意義消滅
- 承認疲れ → rubber-stamp → 実質 HITL なし
- ユーザーが「なぜ 1 件ずつ承認させるんだ」と離脱

根本原因：
- リスクティアを設定していない
- 低リスク操作にも synchronous approval を付けている

脱出：
- 承認を 4 ティア（auto / spot / retroactive / synchronous）に分ける
- 低リスクは auto + spot check、高リスクのみ synchronous
- 「1 セッション 10 件以下」が rubber-stamp 化の閾値

❌ HITL 放棄
─────────
症状：
- 全自律で暴走
- 「Auto Mode の 17% false-negative」を「人間レビューの代替」と誤認
- インシデント発生時に「誰が判断したか」が追えない

根本原因：
- HITL を「速度の足枷」と誤解している
- 監査要件・EU AI Act を理解していない

脱出：
- 不可逆操作・高信頼度判断・規制対象操作は必ず synchronous
- retroactive review を必ず組み込み（決定理由ログ）
- audit trail に WHO + WHY を残す

業務投入の観点で重要な 3 点

1. 「全自律 vs 全承認」は二者択一ではなくスペクトル：Strata の time-boxed lanes（低リスク 15 秒 / PII 2 分 / 金融出金 15 分）を出発点にリスクティアを設計
2. HITL は「速度」ではなく「責任」のために残す：AstraSync の 3,600× 速度差。「WHO approved」+「WHY approved」の audit trail が EU AI Act 対応の本筋
3. 6 パターンを組み合わせて使う：Anthropic Auto Mode の 2 段階分類器が、6 パターン（auto / retroactive / synchronous / classifier / 異常検知）のハイブリッド実装の好例

次章への接続

ch6 では、ここまでの 8 パターン × 6 トポロジー × 5 古典 × HITL 設計を踏まえて、最も頻出するアンチパターン集を扱う。Premature multi-agent、HITL 過多 / 放棄、Pipeline SPOF、Swarm 合意ループ、Router 分類精度天井 ── 業務投入で「やってはいけない」を症状・根本原因・脱出法でまとめる。

---

この章のまとめ

• HITL の 3 軸：6 箇所（差し込み）× 6 実装 × 4 リスク
• 「全自律 vs 全承認」は罠：93% 自動承認 + 7% HITL のリスクティア設計
• HITL は「速度」ではなく「責任」のために残す：AstraSync の 3,600× 速度差、EU AI Act 対応
• 「1 セッション 10 件以下」が rubber-stamp 化の閾値
• Auto Mode の 2 段階分類器は 6 パターンのハイブリッド実装の好例
• 「諦め」の設計：どの本番エージェントも何かを諦めている。Devin は mid-task 要件変更、Operator は銀行送金、Cursor は plan 不経由の実行

＋ － ⟳ ✕