TL;DR
- 優秀な AI エージェントは「全部やる」より「危ないときに止まる」ことで信頼を得る
- エスカレーション条件は 権限・信頼度・影響範囲 の3軸で設計できる
- 判断を人に戻す閾値を事前に決めると、事故半径（Blast Radius）を最小化できる
- 人間側にも「受け皿」を用意しなければ、止めた意味がない
はじめに ── なぜ「止まる設計」が必要か
AIエージェントの自律性が高まるほど、「何でもやってくれて便利」と「暴走して取り返しがつかない」の距離は縮まります。 この記事では、AIエージェントが自ら判断を保留し、人間へ正しくエスカレーションするための 条件設計と運用ルール を整理します。
:::message 狙いは自律性を下げることではありません。危険な場面でだけ確実に人間へ戻し、それ以外では速度を落とさないことです。 :::
エスカレーション設計は、AIエージェント開発のデリバリー統治における「安全装置」の中核です。速度と安全を両立するために、まず「どこで止めるか」を明確にしましょう。
1. どんな場面で止めるべきか
エスカレーション判定の3軸
エスカレーションの条件は、大きく3つの軸で分類できます。
| 軸 | 判定基準 | エスカレーション例 |
|---|---|---|
| 権限 | 操作がエージェントの許可範囲を超える | 本番DBへの書き込み、外部APIへの課金操作 |
| 信頼度 | モデルの出力確信度が閾値を下回る | confidence < 0.8 の判断、曖昧な入力 |
| 影響範囲 | 操作の影響が広範囲に及ぶ | 全ユーザーに影響するデプロイ、不可逆な削除 |
この3軸は独立ではなく、組み合わせで評価します。たとえば「権限内だが影響範囲が大きい操作」は、信頼度が高くてもエスカレーション対象にすべきです。
権限の境界を明文化する方法については、権限マトリクスとガードレール設計で詳しく解説しています。権限表が先にないと、エスカレーション条件も曖昧になるため、セットで設計してください。
代表的な閾値の設定例
実際にチームで運用する場合、以下のような閾値テーブルを用意すると判断がブレにくくなります。
| 条件 | 閾値 | アクション |
|---|---|---|
| confidence スコア | < 0.8 | 人間にレビュー依頼 |
| リスクレベル | high | 即時エスカレーション |
| 影響ユーザー数 | > 100 | 承認フロー必須 |
| 操作の可逆性 | 不可逆 | ダブルチェック必須 |
閾値は固定ではなく、運用データを見ながらチューニングするものです。最初は「厳しめ」に設定し、過剰エスカレーションが多ければ緩める方向で調整します。
2. エスカレーションの実装パターン
基本パターン：条件関数による判定
最もシンプルな実装は、判定関数をエージェントのアクション実行前に挟む方法です。
type RiskLevel = 'low' | 'medium' | 'high'
interface EscalationContext {
confidence: number
risk: RiskLevel
affectedUsers: number
reversible: boolean
}
function shouldEscalate(ctx: EscalationContext): boolean {
if (ctx.risk === 'high') return true
if (ctx.confidence < 0.8) return true
if (ctx.affectedUsers > 100 && !ctx.reversible) return true
return false
}
この関数を通らない限りエージェントが次のアクションに進めない設計にすることで、「必ず止まる」ことを保証します。
応用パターン：段階的エスカレーション
すべてのケースで即座に人間へ戻す必要はありません。段階を分けることで、軽微な不確実性はエージェント同士で解消し、本当に人間の判断が必要な場面だけ通知できます。
- Level 1 ── セルフリトライ: 別のアプローチで再試行
- Level 2 ── ピアレビュー: 別のエージェントに検証を依頼
- Level 3 ── 人間エスカレーション: Slack通知やPRコメントで人間に判断を委ねる
この段階設計は、AIをチームメンバーとして働かせる運用で解説しているエージェント間 handoff の仕組みと組み合わせると効果的です。エージェント同士で解消できる問題を人間に持ち込まないことで、人間側の負荷を下げられます。
3. 人間側の受け皿をどう作るか
エスカレーションは「止める側」だけでなく、「受け取る側」の設計も同じくらい重要です。エージェントが正しく止まっても、人間が気づかなければ意味がありません。
受け皿設計の3要素
- 通知チャネル: エスカレーションがどこに届くか（Slack、メール、PRコメントなど）
- コンテキスト提示: 何が起きて、なぜ止まったのか。人間が判断するための情報が揃っているか
- 対応手順: 承認・却下・修正の各パターンでどう操作するかが明文化されているか
特に「対応手順」は見落とされがちです。エスカレーションが来ても、人間が何をすればよいか分からなければ放置されます。これは AIエージェント運用Runbook設計 で整理している「異常時に人間が迷わない手順書」と同じ考え方です。
エスカレーション通知のテンプレート例
## エスカレーション通知
- **エージェント**: article-writer
- **トリガー**: confidence 0.62（閾値 0.8 未満）
- **操作内容**: 記事の公開ステータス変更
- **影響範囲**: 公開記事1本
- **推奨アクション**: 内容を確認し、公開可否を判断してください
- **期限**: 24時間以内に対応がない場合、自動キャンセル
通知に「期限」と「未対応時のデフォルト動作」を入れておくことで、対応漏れによるタスク滞留を防げます。
まとめ ── 「止まれる AI」が信頼される AI
エスカレーション設計のポイントを振り返ります。
- 3軸で条件を定義する: 権限・信頼度・影響範囲の組み合わせで判定
- 段階的に設計する: すべてを人間に戻すのではなく、レベル分けで効率化
- 受け皿を用意する: 通知・コンテキスト・手順の3点セットで人間が迷わない仕組みを作る
- 閾値は運用で調整する: 最初は厳しめに、データを見ながら緩める
エスカレーション設計は単体で完結するものではありません。権限マトリクスで境界を引き、Runbookで手順を整え、人間の承認ワークフローで最終判断を担保する。これらを組み合わせて初めて、速度と安全を両立できるAIエージェント運用が成立します。
まずは 「AIが迷ったら誰に・何を・どう戻すか」 を一覧化するところから始めてください。
