HITL の SLA 設計 ─ 承認遅延・エスカレーション・フォールバック

2026/05/10

HITL の SLA 設計 ─ 承認遅延・エスカレーション・フォールバック

第2部 ch5 で HITL の 6 箇所 × 6 実装 × 4 リスクを扱った。本章では、それらを運用フェーズで動かし続けるための SLA 設計を扱う。

運用で起きる HITL の問題

業務エージェントを 6 ヶ月運用すると、HITL に関して次の問題が必ず立ち上がる：

承認 queue overflow：エージェントが大量に approval を要求し、人間側で捌ききれない
承認遅延：reviewer が出張・休暇で承認が止まる
承認疲れ：rubber-stamp 化で実質 HITL なし（第2部 ch5 で扱った）
承認情報のリーク：「誰が何を承認したか」が SOC2 / GDPR の audit に残せていない
エージェント側の暴走：HITL 待ちでセッション state が消える、メモリが膨らむ

これらは設計時には見えにくい。運用が始まって初めて表面化する。

SLA の 4 軸

HITL の SLA は 4 つの軸で設計する。

軸	内容	例
応答時間 SLA	承認要求から人間応答までの目標時間	High risk 4h、Medium 8h、Low 24h
エスカレーション	SLA 違反時に上位者へ自動 escalate	reviewer → team lead → executive
フォールバック	SLA 違反時のシステム挙動	auto-reject / auto-approve（低リスク）/ tasks pause
監査ログ	「誰が・いつ・何を・なぜ承認したか」の永続化	EU AI Act 対応、7 年保存（金融）

軸 1：応答時間 SLA

リスクティアごとに目標を分ける。

✅ 推奨初期値（業務性質次第で調整）
─────────
Critical（不可逆操作）：
  応答時間 SLA: 1h（業務時間内）
  Escalation: 30 min で reviewer → 1h で team lead

High（顧客影響あり）：
  応答時間 SLA: 4h
  Escalation: 2h で reviewer → 4h で team lead

Medium（社内操作）：
  応答時間 SLA: 8h
  Escalation: 6h で reviewer → 8h で team lead

Low（推奨・suggestion）：
  応答時間 SLA: 24h
  Escalation: 16h で reviewer → 24h で auto-handle

これらの SLA は 観測可能でなければならない。Datadog / Hyperping / Prefactor などの監視ツールで HITL queue を可視化する。

軸 2：エスカレーション

SLA 違反が起きたら、自動的に上位者へ通知する。

graph TB
    Req[Approval Request<br/>Risk: High]
    R1[Reviewer<br/>応答 SLA: 4h]
    R2[Team Lead<br/>応答 SLA: 8h]
    R3[Executive<br/>応答 SLA: 24h]
    Auto[Auto-reject after 48h]

    Req --> R1
    R1 -.4h 経過, 応答なし.-> R2
    R2 -.8h 経過, 応答なし.-> R3
    R3 -.24h 経過, 応答なし.-> Auto

重要な設計：

各 tier の応答 SLA は明示的
Escalation 通知は Slack + email + PagerDuty で多重化
最終的な auto-handle（reject / pause）の挙動を事前に決めておく

軸 3：フォールバック ── SLA 違反時の挙動

「承認が来ない」とき、システムは何をすべきか？

リスク	フォールバック挙動
Critical	Auto-reject（安全側に倒す）、HITL 担当者にインシデント通知
High	Pause until 承認、ユーザーに「処理中です」を表示
Medium	Pause → 24h 経過で auto-reject
Low	Auto-approve（risk が許容範囲内なら）

✅ Low risk の auto-approve 例
─────────
- 軽微な typo 修正の PR
- 内部通知メールの送信
- アクセスログの集計
→ SLA 24h 経過で auto-approve（spot check で 5% を事後レビュー）

✅ Critical の auto-reject 例
─────────
- 本番 DB の DROP TABLE
- 顧客への送金
- データの export
→ SLA 違反で auto-reject、人間が手動で再起動する必要

「auto-handle の挙動」を事前に明文化することが運用工学の核心。「承認が来ないときどうするか」を曖昧にすると、業務側で混乱が起きる。

軸 4：監査ログ

EU AI Act / SOC2 / GDPR に対応するには、HITL の監査ログを永続化する必要がある。

✅ 必須項目
─────────
- approval_id（一意）
- agent_id（どのエージェントが要求したか）
- task_id（どのタスクで）
- requested_at（要求時刻）
- approver_id（承認者）
- approved_at / rejected_at（応答時刻）
- decision（approve / reject / escalated / auto）
- decision_reason（自由記述、required）
- risk_tier（Critical / High / Medium / Low）
- context_hash（タスク context の hash、後から再現可能に）

保存期間（規制依存）：

金融：7 年
医療：5-10 年
一般：3 年（GDPR の最長保管期間に準拠）

重要：「decision_reason」を required にする。ch5 の rubber-stamp 化を防ぐため、承認者は理由を書かなければ approve できない。

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

第2部 ch5 で示した原則を、運用フェーズで再強調する。

AstraSync の試算：AI 50ms vs 人間 180,000ms = 3,600 倍速度減

HITL を「verification（検証）」のためにすべて使うと、scale しない。**「accountability（責任）」**に絞ると設計が収束する。

graph LR
    LR[Low Risk<br/>93% を auto + spot check] --> Done[Done]
    MR[Medium Risk] --> Retro[Retroactive review<br/>事後 spot check]
    HR[High Risk] --> Sync[Synchronous<br/>必須承認]
    UR[Critical / Self-doubt] --> HITL[Tier-based escalation]

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

Queue overflow の対処

承認 queue が大量に溜まると、システム全体が止まる。これを防ぐには：

1. Queue の hard cap

✅ Queue size cap
─────────
- 1 reviewer あたり pending 50 件まで
- 超過したらエージェント側で「承認 queue 満杯のため 1 時間後に再試行」を返す
- 業務側に visibility（「いま 50 件溜まっています」を可視化）

2. Bulk approval / bulk reject

似た性質のリクエストをまとめて処理できる UI を用意。

例：内部通知メール送信の承認 30 件
→ 1 件ずつ確認するのではなく、
  「送信先一覧を見て、1 クリックで全 approve / 全 reject / 個別選択」

3. 承認権限の委譲

reviewer の出張・休暇時に、自動的に他 reviewer へ委譲する仕組み。

✅ Reviewer status
─────────
- Active：通常モード
- Busy：閾値超過。escalate を即時起動
- OOO（out of office）：すべて backup reviewer へ自動 forward

「承認疲れ」を運用で測る

第2部 ch5 で「1 セッション 10 件以下が rubber-stamp 化の閾値」と示した。これを SLI として実装する。

SLI：Approver workload
─────────
- 1 reviewer の per-session 承認数
- 1 reviewer の daily 承認数
- 承認時間中央値（短すぎると rubber-stamp の疑い）
- decision_reason の文字数中央値（短すぎると同上）

閾値：
- per-session 10 件超過：⚠️ Bulk approval UI を提案
- 承認時間 中央値 < 5 秒：⚠️ rubber-stamp 化の疑い
- decision_reason 文字数 中央値 < 20 字：⚠️ 形だけの承認の疑い

これらの閾値超過は、運用の品質劣化の早期警告だ。

SLA を満たし続けるための実装パターン

Durable execution（第1部 ch7）との組み合わせ

HITL gate は durable な step として書く：

# ✅ LangGraph での HITL（第2部 ch5 で示した例の再掲）
def review_payment(state):
    decision = interrupt({  # ← workflow を pause、durable に保存
        "question": "$5,000 の支払を承認しますか？",
        "context": state["payment_details"],
        "risk_tier": "Critical",
        "sla_hours": 1,
    })
    return {"approved": decision == "approve"}

# 別のセッションから再開
graph.invoke(
    None,
    config={"configurable": {"thread_id": "..."}},
    resume_command=Command(resume="approve")
)

これで 承認待ちで sandbox / プロセスが消えても OK な構造になる。

SLA 監視

✅ Daily SLA dashboard
─────────
- 各 risk tier の SLA 達成率（Critical 99%、High 95%、Medium 90% など）
- Escalation 発動回数（増えていないか）
- Auto-handle 発動回数（増えすぎていないか）
- 承認者別の workload
- decision_reason の文字数分布

2026 の主要事例

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

Sonnet 4.6 ベースの transcript classifier、2 段階フィルタ、3 連続拒否 or 20 累計でエスカレーション。false-negative 17% を「許容可能だが慎重審査の代替ではない」と正直に開示

これは「自動化された HITL の前段フィルタ」。classifier が「危険」と判定したものだけ人間に渡す。これにより人間の承認件数は大幅に減る。

OpenAI Codex Auto-Review（2026-04）

約 99% を auto-approve、200× ユーザー承認削減。「メインエージェントは task 完遂最適化、Auto-review は narrower job」と責任分離（OpenAI alignment 公式、ただし Devin retrospective の数字ではないので注意）

「メイン agent の出力を別 agent が retroactive に review」する設計。Auto-Review は narrower な job に特化することで、コスト効率と品質を両立。

ChatGPT Agent watch mode

sensitive sites（メール・金融）で常時監視を要求

これは「人間が常時画面を見ている」モード。SLA は「0 秒」（即時介入可能）。

❌ アンチパターン：「承認待ち中に sandbox が消える」

症状
─────────
- HITL 承認を 6 時間待っている間に sandbox / プロセスが消えて state 喪失
- 承認後に「最初からやり直し」になる
- リソース消費が累積（特に Daytona / Modal の長命 sandbox）

根本原因
─────────
- HITL gate を durable な step として書いていない
- in-process state に依存している
- セッションを 1 プロセスで保持しようとしている

脱出法
─────────
1. LangGraph の interrupt() / Temporal の Signal / Restate の Virtual Object を使う
2. state は外部 storage（postgres / R2）に書き出し
3. 承認後の resume を「セッション外からの API call」として設計
4. Sandbox は短命にし、承認時に新しい sandbox を立ち上げ直す

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

SLA は 4 軸で設計：応答時間 / エスカレーション / フォールバック / 監査ログ。1 つでも欠けると運用が破綻する
「承認疲れ」を SLI として測る：per-session 10 件超過、承認時間 < 5 秒、decision_reason < 20 字を rubber-stamp 化の早期警告に
HITL gate は durable な step として書く：承認待ちで sandbox / プロセスが消えても OK な構造に。interrupt() / Signal / Virtual Object

次章への接続

ch8 では、エージェントの品質を継続的に検証するContinuous evaluation を扱う。Production traffic 上の eval、tail-based sampling、judge LLM の月次 calibration、A/B テストとカナリアを実装の解像度で扱う。

この章のまとめ

HITL の SLA は 4 軸で設計：応答時間 / エスカレーション / フォールバック / 監査ログ
応答時間 SLA はリスクティア別：Critical 1h、High 4h、Medium 8h、Low 24h
フォールバック挙動を事前明文化：Critical は auto-reject、Low は auto-approve（spot check 付き）
監査ログは法的義務：EU AI Act、SOC2、GDPR。decision_reason を required に
承認疲れを SLI として測る：per-session 10 件超過、承認時間 < 5 秒、reason 文字数 < 20 字
HITL gate は durable な step として書く：承認待ちで sandbox / プロセスが消えても OK