Incident response & Runbook ─ 6 種のインシデントを 5 分で止める

ここまでの 8 章で、エージェントを動かし続けるための仕組みを揃えた。それでもインシデントは起きる。本章では、起きたときに5 分で止められるインシデント対応を扱う。

エージェント特有のインシデント 6 種

伝統的なシステム障害（DB ダウン、API 5xx 等）に加え、エージェント特有の 6 種のインシデントが頻発する。

#	インシデント	症状	章
1	Tool failure / MCP server outage	エージェントが特定 tool の retry ループに突入	ch6
2	Memory poisoning incident	偽事実を信じて誤った判断を続ける	ch5
3	Runaway loop（暴走）	同じ tool / プロセスを延々繰り返す	ch6
4	Cost spike	コストが想定の 5×、$X,000 焼ける	ch4
5	HITL queue overflow	承認 queue 200 件溜まる、業務側が止まる	ch7
6	Drift incident	eval が突然 -15% など大きく落ちる	ch3

これら 6 種を事前に Runbook 化しておけば、on-call が「今、何をすべきか」を 5 分以内に判断できる。

Runbook の標準フォーマット

各インシデント Runbook は次のフォーマットで書く：

# Runbook: [インシデント名]

## 検知方法
- どの SLI / alert で気づくか
- 典型的な症状

## トリアージ（5 分以内）
- まず何を確認するか（チェックリスト）
- 緊急度判定（Critical / High / Medium）

## 緊急停止（必要なら）
- kill switch の発動方法
- 影響範囲の特定

## 調査
- ログの読み方
- 再現手順

## 復旧
- 修正の手順
- 再発防止

## Post-incident
- audit log の保存
- 振り返り（postmortem）

Runbook 1：Runaway loop（最も多い）

# Runbook: Agent Runaway Loop

## 検知方法
- Tool Invocation Efficiency (TIE) > 5.0
- Per-task token consumption > $10
- 同じ tool が連続 5 回以上呼ばれている
- alert：CostSpikeAlert / TIEThresholdExceeded

## トリアージ（5 分以内）
1. 該当 task_id を特定（dashboard の異常 task）
2. agent_id, session_id, user_id を確認
3. 過去 30 分のトークン消費グラフを見る（指数増加か？）
4. 影響範囲：該当 user 単独 / 全 user / 特定 capability

## 緊急停止
1. 該当 task の kill switch 発動：
   ```bash
   $ agent-cli kill --task-id t-12345

2. cap が機能しているか確認（Token budget enforcer）
3. 該当 capability の rate limit を一時 0 に：

   $ agent-cli ratelimit --capability search --rps 0

調査

1. agent の trace を読む（OpenLLMetry / Langfuse）
2. 同じ tool call が繰り返されている箇所を特定
3. Tool 出力に injection が含まれていないか確認
4. Tool 自体が degraded していないか（Circuit Breaker の状態確認）

復旧

• Tool が degraded → ch6 の Tool failure runbook に従う
• Memory poisoning → ch5 の Memory poisoning runbook に従う
• 単純な loop バグ → 修正 PR + canary deploy

Post-incident

• 暴走中の token 消費を audit log に記録
• 「Cost overrun report」を経理 / リーダーに共有
• Hard cap の閾値を見直し（次回はもっと早く止められるか）

## Runbook 2：Cost spike

```markdown
# Runbook: Cost Spike

## 検知方法
- 1 時間あたりのコストが過去 7 日平均の 3× を超える
- 特定 user / agent / capability のコストが想定値の 5× を超える
- alert：CostSpikeAlert（Datadog / Langfuse）

## トリアージ（5 分以内）
1. spike の原因を特定：
   - どの user / capability / model がコストを消費している？
   - 異常な task が走っている？
   - cache hit 率が突然落ちた？（Drift の可能性）
2. 影響規模：1 user / 1 team / 全社

## 緊急停止
1. spike user の rate limit を即時 0 に
2. 該当 capability の auto-shutoff
3. 月次予算 cap の自動 enforcement が機能しているか確認

## 調査
1. tokens per feature の breakdown を見る
2. 過去 7 日と今日を比較（drift / regression がないか）
3. cache hit 率の推移（Anthropic 2026-03 の TTL silent regression を疑う）
4. モデルルーティングの分布（Frontier 比率が増えていないか）

## 復旧
- cache TTL の明示指定漏れ → 修正
- routing の偏り → vLLM Semantic Router の閾値見直し
- runaway → Runbook 1 へ

## Post-incident
- 「Cost overrun」を経理 + リーダーに報告
- 1 週間の cost trend を週次 review に追加
- Hard cap の閾値を再設計

Runbook 3：Tool failure

# Runbook: Tool / MCP server Failure

## 検知方法
- Tool 5xx エラー率 > 5%
- Tool レイテンシ P95 > 30s
- Circuit Breaker が Open に遷移
- alert：ToolHealthDegraded

## トリアージ（5 分以内）
1. どの tool が degraded か特定
2. その tool に依存する agent / capability の数
3. 代替経路があるか（同じ機能の別 tool）
4. 緊急度：影響 user 数 × ビジネス重要度

## 緊急停止
1. Circuit Breaker を強制 Open に：
   ```bash
   $ agent-cli circuit-breaker open --tool weather_api

2. 依存する agent の rate limit を絞る
3. ユーザーには「メンテナンス中」を表示

調査

1. Tool 提供元のステータスページを確認
2. 自社側の rate limit に当たっていないか
3. credentials の有効期限切れ
4. CVE / セキュリティインシデント（MCPwn 等）の可能性

復旧

• Tool 復旧後、Circuit Breaker を Half-Open に
• 健全性確認後、Closed に戻す
• 代替経路があるなら、復旧前にそちらに routing

Post-incident

• 復旧時間（MTTR）を記録
• 同じ tool への依存度を見直し
• 多重化の検討

## Runbook 4：Memory poisoning

```markdown
# Runbook: Memory Poisoning Incident

## 検知方法
- 「ユーザーの好みを覚えていない」というクレーム急増
- AgentDojo eval の attack success rate が上昇
- 「思い出した事実」と source doc の照合失敗率上昇
- alert：MemoryHealthDegraded

## トリアージ（5 分以内）
1. 影響範囲：単一 user / 単一 session / 全 user
2. 汚染の種別：
   - Indirect prompt injection（外部 URL 経由）
   - Sibling task 漏れ
   - Hallucination の self-feed
3. 緊急度：個人情報 / 金融判断に影響しているか

## 緊急停止
1. 該当 user の memory を read-only に：
   ```bash
   $ agent-cli memory --user-id u-123 --mode readonly

2. 該当 session の隔離（外部経路から resume できないように）
3. memory の書き込み機能を一時停止（全社）

調査

1. 汚染された memory entry の origin tag を追跡
2. 攻撃の入口を特定（どの URL / tool / session か）
3. 既知の injection pattern と照合
4. 影響を受けた他 user の特定

復旧

1. 汚染された memory entry を quarantine に隔離
2. その entry を参照した過去の応答を audit
3. ユーザーに「memory をリセットします」を通知し、reset
4. 攻撃経路を塞ぐ（Bedrock Guardrails / Prisma AIRS の rule 追加）

Post-incident

• audit log に汚染期間を記録（EU AI Act 対応）
• 攻撃経路を CVE 風に文書化
• AgentDojo の eval set に新パターンを追加

## Runbook 5：HITL queue overflow

```markdown
# Runbook: HITL Queue Overflow

## 検知方法
- pending approval 件数 > 50 / reviewer
- SLA 違反率 > 10%
- escalation 発動回数の急増

## トリアージ（5 分以内）
1. 何が大量発生しているか
2. 1 reviewer のせいか / 全員でか
3. ビジネスインパクト：approval 待ちで業務が止まっている user 数

## 緊急停止
1. 該当 capability の rate limit を絞る（新規 approval 要求を減らす）
2. backup reviewer を緊急投入
3. 低リスクの bulk approval UI を解放

## 調査
1. なぜ approval が大量発生したか
   - エージェントが過度に approval 要求を出している（HITL 過多）
   - reviewer が休暇 / 出張で対応できていない
   - capability の risk tier が間違っている（Low なのに synchronous になっている）

## 復旧
- HITL 過多 → risk tier の見直し、auto-approve 化
- reviewer 不足 → 委譲 / backup の自動切替
- queue を捌く → bulk approval

## Post-incident
- 「承認疲れ」の SLI（per-session 件数 etc.）を再測定
- HITL 設計の見直し（ch5 / ch7）

Runbook 6：Drift incident

# Runbook: Drift Incident

## 検知方法
- DQR の急落（baseline -10% など）
- TCR の急落
- daily eval が baseline -3% を超える
- alert：DriftDetected

## トリアージ（5 分以内）
1. drift の種別：
   - モデルドリフト（プロバイダの checkpoint 更新）
   - プロンプトドリフト（最近のプロンプト変更）
   - データドリフト（入力分布の変化）
2. 影響範囲：単一 capability / 全社

## 緊急停止
1. 直近の deploy を rollback（プロンプト / モデル）
2. Drift detection threshold を超えたら自動 rollback の機能が動いているか確認

## 調査
1. モデル ID の確認（pinned snapshot か、evergreen alias か）
2. 直近のプロンプト変更履歴
3. PSI / KS test で入力分布の変化を確認
4. judge LLM 自体の drift（calibration 漏れ）

## 復旧
- モデル更新 → pinned snapshot に固定 + 新モデルの段階的検証
- プロンプト → 直前の版に戻す
- データ → corpus を見直し / Router 閾値の調整

## Post-incident
- Daily Drift Dashboard の閾値を見直し
- pinned snapshot の徹底
- judge calibration の頻度を上げる

On-call ローテーション

エージェントの on-call は 誰が持つかが論争点だ。2026 では 3 つの選択肢がある：

担当	強み	弱み
アプリチーム	プロダクト知識が深い	エージェント特有の知識が薄い
プラットフォームチーム	エージェント基盤の知識が深い	アプリ知識が薄い
AI SRE 専門職（2026 で登場開始）[要検証]	両方	採用が難しい

推奨：プロダクトチームが第一線、プラットフォームチームが第二線（escalation 先）。AI SRE は中規模以上の組織で専門職化。

On-call の要件

✅ Effective on-call の要件
─────────
1. 全 6 種の Runbook が言語化されている
2. Kill switch を発動する権限を持つ
3. Audit log の読み方を訓練済み
4. 主要ツール（Datadog / Langfuse / OpenLLMetry）の操作に習熟
5. ステークホルダーへの通知経路（Slack / PagerDuty）が確立

Audit log の運用

EU AI Act / SOC2 / GDPR 対応として、audit log を運用する。

✅ Audit log の WHO / WHEN / WHAT / WHY
─────────
- WHO：agent_id, session_id, user_id（代理人）
- WHEN：timestamp（UTC）
- WHAT：tool_call, parameters, output_hash
- WHY：reason（HITL approval reason, agent's chain-of-thought summary）

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

検索機能：
- by user_id：「この user に対して何をしたか」
- by capability：「決済を行ったすべての agent」
- by time range：「2026-04-15 の異常時刻」

Replay 可能性：audit log から「事故を再現できる」状態に保つ。これがないと postmortem ができない。

2026 の標準ツール構成

3 つの構成が主流：

構成 A：OSS first
- Phoenix（OSS, eval）
- Langfuse self-host（trace + eval）
- Grafana（dashboard）
- PagerDuty（alert）

構成 B：Datadog 一本化
- Datadog LLM Observability（trace + eval + cost）
- Datadog Workflows（runbook 自動化）
- PagerDuty integration（alert）

構成 C：Eval 専門 + 汎用 APM の二段
- Braintrust / Galileo（eval）
- Datadog APM（infra）
- Langfuse（agent trace）

❌ アンチパターン：「Runbook が無いまま on-call」

症状
─────────
- インシデント発生時、on-call が「何をすべきか」を毎回考える
- 復旧時間（MTTR）が事故ごとにバラバラ
- 同じインシデントが何度も起きる

根本原因
─────────
- 6 種の Runbook が言語化されていない
- Kill switch の発動権限が曖昧
- Postmortem がチーム知識として残らない

脱出法
─────────
1. 6 種の Runbook を上記フォーマットで言語化
2. 月 1 回「Runbook 通読」会で全 on-call に共有
3. インシデント発生のたびに Runbook を更新
4. Postmortem は blameless で、Runbook へのフィードバック必須
5. AI SRE Agent（Azure SRE Agent 等）で Runbook 自動生成 [要検証]

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

1. 6 種のインシデント Runbook を必ず言語化：Runaway / Cost spike / Tool failure / Memory poisoning / HITL overflow / Drift。各 5 分で復旧開始できる手順
2. Kill switch の発動権限を on-call に与える：判断を待たずにプロセスを止められる権限。alert ではなく enforcement
3. Audit log は WHO / WHEN / WHAT / WHY を必ず残し、Replay 可能性を保つ：EU AI Act 対応 + Postmortem の前提

次章への接続

ch10（最終章）では、本作の運用工学を統合し、三部作全体の地図を回収する。第1部（部品）+ 第2部（形）+ 第3部（生かし方）の総合チェックリストを提示し、参考文献と次のステップを整理する。

---

この章のまとめ

• エージェント特有の 6 種のインシデント：Runaway / Cost spike / Tool failure / Memory poisoning / HITL overflow / Drift
• 各 Runbook は 6 セクションで標準化：検知 / トリアージ / 緊急停止 / 調査 / 復旧 / Post-incident
• 5 分以内のトリアージを目標：影響範囲 + 緊急度 + 緊急停止 の判断
• On-call は 2 線体制：アプリチーム第一線、プラットフォームチーム第二線、AI SRE 専門職は中規模以上で
• Audit log は WHO / WHEN / WHAT / WHY：EU AI Act 対応 + Postmortem の前提

＋ － ⟳ ✕