AIエージェント人間エスカレーション設計ガイド - 迷ったrunをどう止めて戻すか

AIエージェントに実務を任せると、難しいのは「人間に聞くかどうか」です。毎回止まれば遅い。一方で、判断不能なまま進むと、依頼外のファイルを書いたり、外部サービスへコメントしたり、承認されていない MCP tool を呼んだりします。

この記事では、AIエージェントの 人間エスカレーション設計 を扱います。tool call 直前の approve / reject は AIエージェント承認フロー設計ガイド、入口で依頼を分類する話は AIエージェント依頼受付設計ガイド、作業後に何を返すかは AIエージェント出力契約設計ガイド、稼働中の異常検知は AIエージェント本番監視設計ガイド に分けています。

今回の論点は、run の途中で agent が進めるべきでない状態になったとき、何を根拠に止め、何を人間へ返し、どの条件で再開するかです。

先に結論: escalation は「質問」ではなく状態遷移にする

AIエージェントが迷ったときに、ただチャットへ質問させるだけでは運用になりません。

どうしますか？

これでは、何に迷っているのか、どの選択肢が危険なのか、今どこまで作業済みなのか、放置すると何が起きるのかが分かりません。

私なら、エスカレーションを次の状態遷移として扱います。

状態	意味	次に許すこと
running	agent が自力で進めてよい	read / draft / low-risk write
needs_clarification	依頼や完了条件が曖昧	質問だけ
needs_approval	操作は明確だが権限が必要	approval flow
needs_owner_decision	業務判断が必要	人間 owner に返す
needs_escalation	scope / risk / evidence が崩れた	escalation packet を返して停止
stopped	これ以上進めない	再開条件が満たされるまで待つ

重要なのは、needs_escalation を agent の失敗扱いにしないことです。むしろ、危ない推測を止められたなら設計は機能しています。

承認フローとの違い

人間エスカレーションと承認フローは似ていますが、同じではありません。

承認フローは、操作が明確なときに使います。

requested_action: mcp.github.create_pr
target: repo:nidoneko/HP
risk_level: write
reason: 記事差分をPR化するため

一方で、エスカレーションは、操作そのものを決められないときに使います。

escalation_reason: scope_conflict
observed_problem: "依頼は記事作成だが、既存SEOファイルに未コミット差分がある"
agent_options:
  - "rootを触らずfresh worktreeで続行"
  - "既存差分を取り込む"
  - "作業を停止して依頼者に確認"
recommended_option: "fresh worktreeで続行"

承認は「この操作をしてよいか」。エスカレーションは「この状況でどの方針を選ぶべきか」です。ここを混ぜると、承認者が業務判断まで背負うことになります。

どの条件で人間へ戻すか

AIエージェントを止める条件は、気分ではなく表にします。最初は次の7つで十分です。

条件	例	戻し方
scope_conflict	依頼外ファイル、別PR、別顧客へ広がる	scopeを再指定してもらう
missing_business_rule	料金、法務、顧客通知、公開判断が必要	owner decisionへ戻す
evidence_conflict	docs、ログ、既存コードが矛盾する	根拠差分を提示する
permission_gap	必要toolやMCP scopeがない	approval flowへ送る
irreversible_action	deploy、削除、外部送信、課金変更	原則停止または二者承認
sensitive_data_boundary	secret、個人情報、未公開顧客情報が絡む	扱うデータ境界を確認
low_confidence_high_impact	confidenceは低いが影響が大きい	推奨案付きで止める

特に大事なのは最後です。confidence が低いだけなら、追加調査で進められることがあります。影響が小さいなら draft として返せます。しかし、confidence が低く、外部影響が大きいなら止めます。

escalation packet に入れる項目

人間へ戻すときは、長い作業ログを投げない方がよいです。人間が判断できる最小情報に圧縮します。

human_escalation:
  escalation_id: esc-20260707-blog-001
  agent_run_id: run-20260707-automation-3
  status: needs_escalation
  reason: scope_conflict
  current_goal: "nidoneko.dev の新規ブログ記事を作成してPR化する"
  observed_state:
    branch: "article/ai-agent-human-escalation-20260707"
    completed:
      - "keyword-plan と既存記事を確認"
      - "重複しないテーマを選定"
    pending:
      - "記事作成"
      - "llms更新"
      - "build"
      - "PR作成"
  decision_needed: "rootの未コミットSEO差分を取り込むべきか"
  options:
    - id: "A"
      action: "origin/mainから作ったworktreeだけで続行"
      risk: "root側の未コミット学習を反映しない可能性"
    - id: "B"
      action: "root差分を読むが、必要部分だけ手動で反映"
      risk: "unrelated diffをPRへ混ぜる可能性"
  recommendation: "A"
  resume_when:
    - "選択肢A/Bが決まる"

この packet は、出力契約の途中版です。最終成果物ではありませんが、再開するための契約になります。

実務でよくあるエスカレーション

1. 依頼が途中で別タスクに変わる

最初は「記事を書いて」だったのに、調査中に既存記事の大規模リライトが必要に見えることがあります。ここで agent が勝手にリライトへ広げると、PR の意図が崩れます。

この場合は、次のように返します。

reason: scope_expansion
finding: "新規記事候補は既存記事と近い"
safe_next_step: "新規記事は見送り、既存記事rewrite案を別PR候補として返す"
requires_user_decision: true

2. approval では足りない業務判断が出る

MCP write の承認は、tool 実行を止めるには十分です。しかし「この顧客へ返答してよいか」「この価格条件を提示してよいか」は tool の問題ではありません。

この場合は needs_approval ではなく needs_owner_decision へ送ります。承認者に tool payload だけを見せても、業務判断はできません。

3. 根拠が割れている

公式 docs、既存実装、社内運用が食い違うことがあります。AIエージェントは、もっとも最近読んだ情報へ寄りがちです。

この場合は、どちらが正しいかを勝手に決めず、根拠を並べます。

reason: evidence_conflict
evidence:
  - source: "official_docs"
    says: "approval state can be serialized and resumed"
  - source: "current_repo"
    says: "automation memory does not store pending approval state"
decision_needed: "今回の設計記事では理想設計として書くか、現行実装制約として書くか"

4. agent が自分の検証結果を信用しきれない

build は通ったが、UI は未確認。unit test は通ったが、MCP 側の外部状態は見ていない。こういうときに「完了」と言わせると事故ります。

この場合は完了ではなく needs_review または needs_escalation です。最終回答で「未検証リスク」として返すだけで足りる場合もありますが、外部副作用があるなら止めます。

OpenAI Agents SDK から見る設計ポイント

OpenAI Agents SDK の human-in-the-loop は、sensitive tool call の前で run を pause し、RunState を保存して approve / reject 後に resume できる設計です。RunState は durable に保存でき、長時間の承認にも使えます。

これはエスカレーション設計でも参考になります。ただし、HITL の approval は「tool call を実行してよいか」を扱います。人間エスカレーションでは、それより前に次を固定します。

• なぜ agent が止まったのか
• どの選択肢があるのか
• どれを推奨するのか
• 再開時に同じ state を使ってよいのか
• policy / tool / prompt version が変わっていないか

承認待ちをただのチャット通知にせず、状態として保存する。この考え方はそのまま使えます。

Claude Code permissions / hooks から見る設計ポイント

Claude Code の permissions は allow / ask / deny を分け、deny が優先されます。PreToolUse hook は permission prompt の前に実行でき、hook の結果で tool call を止めたり、prompt を強制したりできます。

ここから言えるのは、エスカレーションを prompt だけに任せないことです。

• deny: 絶対に進めない操作
• ask: 操作は明確だが人間承認が必要なもの
• hook block: ルール違反や scope 逸脱を機械的に止めるもの
• escalation packet: 機械的に決めきれない判断を人間へ戻すもの

たとえば git push origin main は deny でよいです。gh pr create は ask か per-run approval でよいです。dirty root で新規記事を作るかどうかは、状況によっては escalation packet にします。

NIST / OWASP から見る設計ポイント

NIST AI RMF は、AI システムのリスクを組織や社会への影響まで含めて管理する枠組みです。OWASP Agentic AI の脅威整理も、agentic system では自律性と tool 使用によりリスクが広がることを前提にしています。

実務に落とすなら、「最終判断は人間」と書くだけでは足りません。

• どの状態で人間へ戻すか
• どの owner が判断するか
• 人間が見る情報は何か
• 判断後に agent が再開してよい条件は何か
• 誤った判断をどう監査ログへ残すか

ここまで決めて初めて、人間の関与が責任の押し付けではなく統制になります。

再開条件を決める

エスカレーション後に一番危ないのは、曖昧な返答でそのまま再開することです。

了解です。いい感じに進めてください。

これは再開条件ではありません。再開時には、少なくとも次を確認します。

項目	確認内容
decision	どの選択肢が選ばれたか
scope	追加で許可された範囲、禁止された範囲
state	前回 state を再利用してよいか
version	policy / tool schema / prompt / branch が変わっていないか
expiry	承認や判断の有効期限
fallback	再度同じ問題が出たら止めるか、別案へ進むか

これを確認せずに再開すると、古い前提で外部操作を実行することがあります。長時間止まった run は、再開前に state reconciliation も必要です。

escalation を減らす方法

エスカレーションは必要ですが、多すぎると運用が詰まります。減らすには、止める条件を弱めるのではなく、事前契約を強くします。

1. task intake で scope と done_when を固定する
2. tool risk tier で read / write / external action を分ける
3. approval flow で操作直前の承認を整える
4. output contract で未検証リスクを返す形を決める
5. runtime monitoring で loop や approval wait を検知する

この5つが揃うと、agent は低リスク作業を止まらず進め、高リスク作業だけを適切に人間へ戻せます。

AGENTS.md に置く最小ルール

repo で AIエージェントを使うなら、エスカレーション規則を AGENTS.md に短く置きます。

## Human escalation rules

- Escalate when scope, business owner, data boundary, or rollback path is unclear.
- Do not convert an escalation into a tool approval request.
- Escalation packets must include current goal, observed state, decision needed, options, recommendation, and resume conditions.
- If the user response does not resolve the decision, ask one clarification question or stop.
- Never proceed with external actions, customer-visible changes, billing, production data, or token changes under ambiguous approval.

長い規程を書くより、この5行を全 agent が守る方が効きます。

導入チェックリスト

最初に導入するなら、この順番で十分です。

1. needs_clarification / needs_approval / needs_owner_decision / needs_escalation を状態として定義する
2. scope conflict、missing business rule、evidence conflict、permission gap、irreversible action を停止条件にする
3. escalation packet の YAML テンプレートを作る
4. 再開条件に decision、scope、state、version、expiry を入れる
5. エスカレーション履歴を監査ログや decision log と agent_run_id でつなぐ
6. 1か月後に、よく出る escalation reason を task intake や approval flow へ戻して減らす

エスカレーションは、最後に足す非常ボタンではありません。AIエージェントが自力で進めてよい範囲と、人間へ責任を戻す範囲を分ける通常運用の一部です。

参考にした一次情報

• OpenAI Agents SDK: Human-in-the-loop
• Claude Code: Configure permissions
• Claude Code: Automate actions with hooks
• NIST AI Risk Management Framework
• OWASP Agentic AI - Threats and Mitigations

まとめ

AIエージェントの人間エスカレーションは、単なる質問機能ではありません。判断不能、scope逸脱、根拠衝突、外部影響、業務owner不明を状態として検出し、判断に必要な情報だけを packet にして人間へ戻す設計です。

承認フローは tool call 直前、task intake は入口、output contract は完了時、人間エスカレーションは run 中の迷いどころを扱います。この役割を分けると、AIエージェントを「止まりすぎる自動化」にも「勝手に進む自動化」にもせず、責任ある作業フローとして組織に入れやすくなります。