TL;DR
- AI コーディング運用のインシデントは 「AI 暴走」「AI 起因の本番障害」「観測欠落」「オンコール疲弊」 の 4 種別に分類できる（経験則）。
- Runbook の最小構成は owner / timeline / detection / mitigation / postmortem owner の 5 セクション。Atlassian 公式と Google SRE 公式に準拠[公式値]。
- 本記事は SRE / Platform / EM 向けに、既存 5 記事（runbook-design / escalation-policy / change-failure-analysis / oncall-fatigue / agent-observability）を 5 軸で束ねるハブとして機能する。
はじめに
AI コーディング運用で「インシデントが起きた」と感じる事象は、種類が混在しています。AI が想定外のコードを書いたケース、AI 生成コードが本番障害を引き起こしたケース、観測が抜けて気付きが遅れたケース、結果としてオンコール担当が疲弊するケース、これらは別々に Runbook を作る必要があります（経験則）。
本記事は 5 軸 × 既存記事 5 本 を束ねる ハブ として機能します。各軸の深掘りは既存記事に譲り、本記事はナビゲーションと最小テンプレを提供します。
CFR 計測との連動は AI変更後のCFR再定義ガイド、組織展開の段階設計は AIコーディング組織展開の段階設計 を参照してください。
1. AI コーディング運用で起きるインシデント分類
4 種別に分けると、Runbook の宛先が明確になります。
| 種別 | 症状例 | 一次対応の優先度 |
|---|---|---|
| AI 暴走 | エージェントが想定外のファイル削除 / 大量コミット / 認証情報の露出 | 高（即時 kill switch） |
| AI 起因の本番障害 | AI 生成コードが production deploy 後に rollback、SLO 違反 | 高（rollback + CFR 計測） |
| 観測欠落 | エージェントが黙って止まり気付きが遅い、ログが取れていない | 中（観測基盤強化） |
| オンコール疲弊 | アラート量増加、ローテ崩壊、レビュー待ち滞留 | 中（運用設計見直し） |
4 種別を混ぜない
「AI 暴走」と「AI 起因障害」は対応速度・責任範囲が違います。Runbook は 種別ごとに別ファイルで持つのが現実解（経験則）。
2. Runbook の最小構成（ai-agent-runbook-design 軸）
Atlassian 公式 Postmortem ハンドブック[公式値]（Atlassian Incident Management Handbook）と Google SRE Postmortem Culture[公式値]（Google SRE Postmortem Culture）を参考にした、AI コーディング運用 Runbook の最小 5 セクション。
- Metadata: owner / status / severity / incident date / detection time
- Timeline: detection → mitigation → resolution → recovery のファクト時系列
- Detection: 検出経路（PR ラベル / CI シグナル / ユーザー報告 / アラート）
- Mitigation: 一次対応手順（kill switch / rollback / hotfix / feature flag off）
- Postmortem: blameless 原則 + action item owner + tracking ID + 共有範囲
詳細な Runbook テンプレは AIエージェント運用Runbook設計 で扱います。本記事ではハブとしてセクション項目だけ示します。
AWS Well-Architected との整合
AWS Well-Architected Operational Excellence pillar も Runbook を 「desired outcome に向けた documented process / checklist」 と定義し、central location / error handling / permissions / exceptions / escalations / 更新を要件としています[公式値]（AWS Well-Architected - Use Runbooks）。本記事の 5 セクションはこれと矛盾しません。
3. エスカレーション設計（ai-escalation-policy-design 軸）
AI コーディング運用のエスカレーションは、「人間の判断が必要な閾値」を事前に決めるのが要点です。具体的なポリシー設計は AIエスカレーション設計 で扱いますが、ハブとして要点だけ整理します。
エスカレーション 3 段階
- L1（自動）: AI 自身で retry / fallback。閾値を超えたら L2 へ
- L2（オンコール）: SRE が判断、kill switch / rollback の一次決断
- L3（管理層）: SLO 違反継続 / 顧客影響 / 法務関連で発動
閾値の例
- 連続 retry 3 回失敗 → L1 → L2
- SLO 違反 5 分継続 → L2 → L3
- 認証情報の意図しない露出 → 即 L3
エスカレーション疲弊回避は オンコール疲弊を防ぐ運用設計 を参照。
4. Change Failure と Incident の連動（ai-change-failure-analysis 軸）
Incident の事後分析は CFR 計測に直結します。Incident → CFR 計測 → 改善打ち手 のループを確立すると、運用が回り始めます。
連動の 3 ステップ
- Incident 発生 → 事象タグ（AI / human / hybrid）を付与
- CFR 計測時に AI/human ラベルで集計（AI変更後のCFR再定義ガイド のフレーム）
- ΔCFR_ai が継続して悪化なら、AI レビュー強化 / Issue テンプレ刷新
詳細な原因分析は AI Change Failure 分析 を参照。CFR 公式定義は DORA Metrics 公式ガイド[公式値]。
5. オンコール疲弊を増やさない設計（oncall-fatigue-reduction 軸）
AI コーディング導入後、PR 数 1.5-3 倍 → アラート量も連動増加 → オンコール疲弊、というドミノが起きます（経験則）。
3 つの設計原則
- アラート粒度の再設計: symptom-based alerting + multi-window multi-burn-rate（Google SRE Workbook - Alerting on SLOs 準拠）[公式値]
- AI triage の段階導入: PagerDuty AIOps / Datadog Bits AI / Watchdog で重複 page を集約[公式値]
- ローテ周期と連続シフト長の分離: Google SRE 公式（multisite 24/7 で 5 名/site）[公式値]を参考に
詳細は オンコール疲弊を防ぐ運用設計 を参照。
6. 観測の設計（agent-observability 軸）
観測なしのインシデント対応は迷走します。最小スキーマと 5 ステップ解析フローを AIエージェントの可観測性と障害解析 で定義しています。本記事はハブとして接続点を示します。
観測の最小要件
- 3 階層 span: User Request → Agent Loop → Tool Call
- 構造化ログ: severity / agent_id / tool_name / duration / outcome を必須
- error taxonomy: AI failure を 5 分類で扱う（プロンプト / ツール / 外部 / モデル / 環境）
詳細な実装は AIエージェントの可観測性と障害解析、durable workflow との統合は agent loop を durable workflow で安定化する実装 を参照。
7. チェックリスト：AI コーディング運用 Runbook の整備状況
最低限以下が整備されているか、Tech Lead / Platform Lead で確認します（経験則）。
- インシデント 4 種別ごとに別 Runbook が存在する
- Runbook 最小 5 セクション（Metadata / Timeline / Detection / Mitigation / Postmortem）を満たす
- エスカレーション 3 段階（L1 自動 / L2 オンコール / L3 管理層）が明文化されている
- CFR と Incident の連動ループ（タグ付け → 集計 → 改善）が回っている
- アラート粒度が symptom-based + multi-window で設計されている
- 観測の最小要件（3 階層 span / 構造化ログ / error taxonomy）を満たす
- AI triage（PagerDuty AIOps / Bits AI / Watchdog 等）が段階導入されている
- ローテ設計が Google SRE 公式値（5 名/site）を参考に評価されている
- 6 ヶ月ごとに Runbook を見直す owner が決まっている
8 項目以上 ✓ なら一旦 OK、未満なら次節の優先順序で整備を進めます。
8. 整備順序（30-60-90 日）
Day 1-30: 分類 + 最小 Runbook
- インシデント 4 種別を整理し、種別ごとに 5 セクション Runbook を 1 本ずつ作成
- Atlassian / Google SRE 公式に準拠
Day 31-60: エスカレーション + 観測
- L1/L2/L3 閾値を明文化
- 3 階層 span + 構造化ログ + error taxonomy を最低限実装
Day 61-90: CFR 連動 + AI triage
- Incident → CFR 連動ループの構築
- AI triage の段階導入
FAQ
Q1. Runbook を 4 種別に分ける必要がありますか？
「AI 暴走」と「AI 起因障害」は対応速度・責任範囲が違うため、種別を混ぜた Runbook は実運用で混乱します（経験則）。最低限 4 種別に分け、運用が安定してから統合を検討するのが現実解。
Q2. 既存の SRE Runbook と AI コーディング Runbook は統合すべきですか？
統合より 「AI 起因の差分セクション」を追加するのが現実解（経験則）。既存 Runbook の構造を活かしつつ、AI 暴走 / AI 生成コードの遠隔影響を AI 専用セクションで補強します。
Q3. AI triage（PagerDuty AIOps / Bits AI 等）はいつ導入すべきですか？
アラート量が 週 50 件超 で、かつ重複 page が 20% 以上 あるチームから検討が現実解（経験則）。それ未満なら「アラート粒度の再設計」が先で、AI triage は段階導入の 3 段目以降。詳細は オンコール疲弊を防ぐ運用設計。
Q4. blameless postmortem は AI 起因にも適用できますか？
適用可能です（経験則）。「人を責めない / システムを問う」原則は AI でも同じで、プロンプト・Runbook・観測の 3 層で再発防止策を組み立てます。Google SRE 公式の Postmortem Culture[公式値] と整合します。
Q5. CFR と本ハブの関係は？
CFR は計測指標、本ハブは 対応 Runbook の集約。Incident 発生 → 4 種別に分類 → 該当 Runbook で対応 → CFR にタグ付けで集計、というループで連動します。CFR の AI 時代再定義は AI変更後のCFR再定義ガイド を参照。
References
- Atlassian Incident Management Handbook - Postmortems — Postmortem の 5 セクション準拠
- Google SRE Postmortem Culture — blameless 原則の原典
- Google SRE Workbook - On-Call — Sustainable on-call の設計指針
- Google SRE Workbook - Alerting on SLOs — symptom-based + multi-window
- AWS Well-Architected - Operational Excellence — Runbook 整備の成熟度モデル
- PagerDuty State of Digital Operations — AIOps の業界調査
- DORA Metrics 公式ガイド — CFR 公式定義
