AIエージェント障害対応ランブック｜4系統の判断基準と停止・再開テンプレート

結論: AIエージェントのRunbookは、障害が起きてから書くのでは遅い。権限逸脱・幻覚連鎖・外部呼び出し異常・承認タイムアウトの4系統に分けてテンプレートを先に置き、判断基準を属人化させないことが本番運用の前提になる。

この記事の要点:

• 2026年の企業調査で88%がAIエージェント関連のセキュリティインシデントを経験または疑いありと報告。Gartnerは2027年末までにエージェントAIプロジェクトの40%以上が中止になると予測している
• 障害を4系統に分類し、系統ごとに一次受け→エスカレーション→復旧確認のRunbookテンプレートをそのまま使える形で提供する
• 止め方にも段階的停止（サーキットブレーカー）と即時停止（キルスイッチ）の2種類があり、障害の影響範囲で使い分ける

対象読者: AIエージェントを本番導入した、または導入を検討しているSRE・DevOps・情シス・開発リーダー。エージェントは動いているが「止まったときの手順」がまだない方。

読了後にできること: 4系統のRunbookテンプレートを自社環境に置き、障害発生時に「誰が・何を見て・どう判断するか」を30秒で伝えられる状態を作れる。

この記事では、OWASPのAgentic Applications Top 10とAzure・PagerDutyの公式ドキュメントをベースに、4系統の障害分類からRunbookテンプレート、キルスイッチ設計までを整理します。

Runbookが要る理由 — テスト段階から出られない企業が多い

AIエージェントの本番投入は、2026年に入って急速に進んでいます。MicrosoftはAzure SRE Agentを2026年3月にGA化し、1,300以上の内部サービスで稼働し、35,000件以上のインシデントを緩和した実績を公表しました（参照日: 2026-08-31）。PagerDutyもエンドツーエンドのAIエージェントスイートをリリースし、インシデント解決時間の最大50%短縮を報告しています（参照日: 2026-08-31）。

一方で、本番運用にたどり着けていない企業は多いです。Gartnerは2027年末までにエージェントAIプロジェクトの40%以上がコスト超過・事業価値の不明確さ・リスク管理の不備で中止になると予測しています（参照日: 2026-08-31、二次報道経由）。テスト段階で止まる理由の多くは「止まったときに誰がどう動くか決まっていない」という運用設計の欠如に帰着します。

Runbookはその穴を埋めるための文書です。止める・戻す・承認する・再開する条件を事前に明文化した運用設計として位置づけます。

4系統のインシデント分類 — 何が起きたかを30秒で判別する

AIエージェントの障害パターンは多岐にわたりますが、初動の判断を速くするために4系統に分類すると、対応フローを標準化できます。

A. 権限逸脱

OWASPのAgentic Applications Top 10では、ASI03: Identity & Privilege Abuseが主要リスクに挙げられています。LLM Top 10でもExcessive Agency（LLM03）が上位です（参照日: 2026-08-31）。エージェントが設計時に想定していない操作を実行するケースが該当します。

Gravitee社「State of AI Agent Security 2026」調査の対象は900人以上です。88%の組織がAIエージェント関連のセキュリティインシデントを経験または疑いありと報告しました（参照日: 2026-08-31）。具体例として、エージェントがリクエスタのアクセスレベルを誤認し、権限チェックを経由せずアクセスを承認した事例が文書化されています。

B. 幻覚連鎖

誤った出力が次のエージェントやツールに渡り、連鎖的に誤ったアクションを実行するパターンです。LLMベースのエージェントでは構造的に発生する可能性があり、LLMの特性として扱う必要があります。

厄介なのは、HTTPステータスコードは200を返すのに、出力の内容が間違っている場合です。トランスポートエラーだけを監視していると検知できません。

C. 外部呼び出し異常

エージェントが依存するAPIやツールの障害、タイムアウト、想定外のレスポンスによる停滞です。分散システムでは以前から知られたパターンですが、AIエージェントでは非決定論的な出力と組み合わさるため、リトライの判断が単純ではありません。

D. 承認タイムアウト

Human-in-the-loopの設計で、人間の承認が返らないケースです。承認者が不在、通知に気づかない、判断基準が曖昧で保留になるなど、運用の隙間から起きます。

系統別Runbookテンプレート — コピーして自社の値を入れる

各系統のRunbookに共通するのは、検知→初動→エスカレーション→復旧確認→事後報告の5段階です。以下のテンプレートを自社の担当者名・ツール名・閾値に書き換えて使ってください。

系統A: 権限逸脱Runbook

## 権限逸脱 Runbook

### 検知条件
- 許可リストにないツール・APIの呼び出しログ
- データアクセスの権限チェック失敗ログ
- 監査ログに記録されない操作の検出

### 初動（発見から5分以内）
1. 該当エージェントを即時停止する
2. 影響を受けたデータ・システムの範囲を特定する
3. 一次受け担当: [担当者/チーム名]

### エスカレーション基準
- 外部データへのアクセスが確認された → セキュリティチームへ即時連絡
- 顧客データに接触した可能性 → インシデントマネージャ＋法務

### 復旧確認
- 権限設定を修正し、再発しないことをステージング環境で確認
- 監査ログの完全性を検証
- 復旧判定者: [担当者名]

### 事後報告
- 報告期限: 発生から24時間以内
- 必須記載: 時系列、影響範囲、根本原因、再発防止策

系統B: 幻覚連鎖Runbook

## 幻覚連鎖 Runbook

### 検知条件
- 出力の信頼度スコアが閾値（例: 0.7）を下回る
- 後続エージェントへの入力に事実と矛盾する内容
- ユーザーからの「結果がおかしい」報告

### 初動（発見から10分以内）
1. 該当エージェントの出力を隔離し、後続処理への伝播を止める
2. 直近の出力を人間がレビューし、影響範囲を確認する
3. 一次受け担当: [担当者/チーム名]

### エスカレーション基準
- 誤った出力が外部に送信済み → 対象顧客への通知判断
- 誤った出力に基づく意思決定が実行済み → 事業責任者へ

### 復旧確認
- プロンプト・コンテキストの修正または再設計
- 修正後に同じ入力で正しい出力を確認
- 復旧判定者: [担当者名]

系統C: 外部呼び出し異常Runbook

## 外部呼び出し異常 Runbook

### 検知条件
- API呼び出しのエラー率が閾値（例: 連続3回失敗）を超過
- レスポンスタイムが閾値（例: 30秒）を超過
- レスポンスの構造が想定と異なる

### 初動
1. サーキットブレーカーを発動し、該当ツールへの呼び出しを一時停止
2. 依存先のステータスページを確認する
3. フォールバック処理（手動実行 or 代替API）に切り替える
4. 一次受け担当: [担当者/チーム名]

### エスカレーション基準
- 30分以内に復旧しない → インフラチームへ
- 業務フローが完全に停止 → 事業責任者へ

### 復旧確認
- 依存先APIの正常稼働を確認
- サーキットブレーカーをhalf-openに移行し、段階的に負荷を戻す

系統D: 承認タイムアウトRunbook

## 承認タイムアウト Runbook

### 検知条件
- 承認リクエストが[N分/N時間]を経過しても応答なし
- 承認キューに滞留件数が閾値を超過

### 初動
1. 承認者へリマインド通知を送信する
2. タイムアウト後のフォールバック: [安全な既定動作に切り替え / 処理を中断して報告]
3. 一次受け担当: [担当者/チーム名]

### エスカレーション基準
- 代理承認者が必要 → あらかじめ定めた代理承認者リストから指名
- フォールバック実行で業務影響が出る → 事業責任者へ

### 復旧確認
- 滞留していた承認を処理
- 承認フローのSLAを見直し（タイムアウト値の調整）

承認フローの設計 — 誰が裁くかを先に決める

Runbookを書いても、承認者が決まっていなければ障害時に動けません。次の3点を先に設計します。

一次受けが見るもの

一次受け担当は、検知アラートを受けて30秒以内に系統を判別できる必要があります。そのために、アラートに含めるべき情報は最低4項目です。

エスカレーションの基準

エスカレーションの判断基準は「影響が組織の外に出たかどうか」を最初の分岐にするのが実用的です。内部完結なら一次受けで対応。外部送信済み・顧客影響ありならセキュリティチームまたは事業責任者へ。

代理承認者の事前指定

承認者が1人だと、その人が不在の場合にRunbookが機能しません。最低2名の代理承認者を事前に指定し、連絡先と権限範囲をRunbookに記載します。

キルスイッチとサーキットブレーカー — 止め方を使い分ける

エージェントを「止める」にも2つのパターンがあります。

キルスイッチ（即時全停止）

データ漏洩、権限逸脱、安全性に関わる障害に使います。該当エージェントのセッション・トークンを即座に無効化し、全処理を停止します。

設計のポイントは、粒度の細かい停止を可能にすることです。特定のトークンだけを無効化する、特定のツール連携だけをブロックする、特定のセッションだけを停止する——エージェント全体を止めるのは最後の手段にします。全停止は業務への影響が大きいためです。

サーキットブレーカー（段階的停止）

外部API障害、一時的なエラー率上昇が対象です。分散システムで実績のあるサーキットブレーカーパターンをAIエージェントに適用した形式になっています。

ただし、AIエージェント特有の注意点が1つあります。LLMベースのツールはHTTPステータス200を返しながら、内容が誤っているケースです。トランスポートエラーだけでサーキットを判定すると品質劣化を見逃すため、出力の信頼度スコアやバリデーション結果をサーキットの判定基準に加えてください。

障害報告テンプレート — 事後の学びを次のRunbookに戻す

障害が収束したら、以下のテンプレートで報告を作成します。報告の目的はRunbookの改善です。

## 障害報告

### 基本情報
- 発生日時: YYYY-MM-DD HH:MM（JST）
- 検知日時: YYYY-MM-DD HH:MM（JST）
- 復旧日時: YYYY-MM-DD HH:MM（JST）
- 系統: A / B / C / D
- 影響範囲: [内部のみ / 外部送信あり / 顧客データ接触]
- 対応者: [名前]

### 時系列
| 時刻 | 出来事 | 対応 |
|---|---|---|
| HH:MM | [検知内容] | [初動] |
| HH:MM | [エスカレーション] | [判断] |
| HH:MM | [復旧確認] | [完了条件] |

### 根本原因
[なぜ起きたか。設定ミス / プロンプトの不備 / 外部APIの仕様変更 / 承認フローの設計漏れ]

### 再発防止策
- [ ] Runbookの更新箇所: [具体的に]
- [ ] 監視の追加・変更: [具体的に]
- [ ] 権限設定の見直し: [必要なら]

本番投入前に見落としやすい3つの穴

穴1: 監視がトランスポートエラーしか拾わない

エージェントの出力品質を監視していないと、200 OKで内容が間違っている障害を見逃します。出力バリデーション（スキーマチェック、事実整合チェック、信頼度スコア）をアラート条件に含めてください。

穴2: Runbookはあるが読まれていない

Runbookを書いて共有フォルダに置くだけでは、障害時に誰も開きません。対策は四半期に1回のドライラン（模擬障害を起こして対応手順を実行する）です。Azure SRE Agentのチームも社内で定期的にドライランを回し、手順の実効性を確認しています。

穴3: 代理承認者がいない

承認フローの設計で最も多い見落としです。承認者1名だと、その人の不在時に業務が止まります。最低2名の代理承認者を事前に指名し、Runbookに連絡先と権限を書いておきます。

導入でよく出る5つの疑問

Q1. Runbookはどのツールで管理するのがよいですか？

ConfluenceやNotionなどのWiki、GitHubリポジトリのMarkdownファイル、またはPagerDutyのRunbook Automation機能が選択肢です。障害時に15秒でアクセスできる場所に置くことが最も大切です。

Q2. 4系統以外のインシデントはどうしますか？

4系統はあくまで初動の判別を速くするための分類です。該当しないインシデントは「未分類」として受け付け、事後に新しい系統を追加します。まず始めて、運用しながら分類を育てます。

Q3. 小規模チーム（3〜5人）でも必要ですか？

必要です。小規模チームこそ属人化のリスクが高いです。テンプレートを埋めるだけなら1〜2時間で完了します。

Q4. エージェントが複数ある場合はRunbookも分けますか？

共通テンプレートは1つにして、エージェント固有の検知条件・閾値・担当者を別表で管理するのが実用的です。エージェントごとに独立したRunbookを作ると更新が追いつかなくなります。

Q5. OWASPのAgentic Top 10と合わせて使えますか？

はい。本記事の系統AはOWASP Agentic Top 10のASI03: Identity & Privilege Abuseに対応しています。権限設計とRunbook運用をセットで整備すると効果的です。

テンプレートを置いた翌週にドライランを回す

1. 今日: この記事の4系統テンプレートをコピーし、自社の担当者・ツール名・閾値を埋める
2. 今週中: 承認フローの代理承認者を指名し、Runbookに記載する
3. 来週: 系統Cの外部呼び出し異常を想定したドライランを1回実行し、手順の抜け漏れを洗い出す

社内ルール全体を整備するなら「生成AI社内ルールの作り方｜9項目テンプレートと3段階の導入手順」も参照してください。

参考・出典

• OWASP Top 10 for Agentic Applications 2026（https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/） — OWASP GenAI Security Project（参照日: 2026-08-31）
• Announcing general availability for the Azure SRE Agent（https://techcommunity.microsoft.com/blog/appsonazureblog/announcing-general-availability-for-the-azure-sre-agent/4500682） — Microsoft Tech Community（参照日: 2026-08-31）
• PagerDuty Expands AI Ecosystem to Supercharge AI Agents（https://www.pagerduty.com/newsroom/pagerduty-expands-ai-ecosystem-to-supercharge-ai-agents/） — PagerDuty（参照日: 2026-08-31）
• Best Practices for Automated Incident Handling（https://www.pagerduty.com/resources/automation/learn/best-practices-automated-incident-handling/） — PagerDuty（参照日: 2026-08-31）
• DevOps ランブック テンプレート（https://www.atlassian.com/ja/software/confluence/templates/devops-runbook） — Atlassian（参照日: 2026-08-31）
• AWS セキュリティインシデント対応ガイド — Runbook章（https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-security-incident-response-guide/runbooks.html） — AWS（参照日: 2026-08-31）
• State of AI Agent Security 2026 — Gravitee（参照日: 2026-08-31、88%統計の原典）
• Resilience Circuit Breakers for Agentic AI（https://medium.com/@michael.hannecke/resilience-circuit-breakers-for-agentic-ai-cc7075101486） — Medium（参照日: 2026-08-31）