テックエイド
AI・業務自動化

Claude Codeでインシデントplaybook/postmortemを型化｜炎上PMの初動と振り返り実装レシピ

#Claude Code #インシデント #playbook #postmortem #炎上対応
Claude Codeでインシデントplaybook/postmortemを型化｜炎上PMの初動と振り返り実装レシピ

夜中にインシデントの第一報が入る。慌てて関係者を招集し、状況把握、暫定対応、エスカレーション、報告——一晩でPMが消耗し、収束した翌週にはpostmortemを書く気力が残らない。多くのチームが「インシデントを乗り切ったが教訓が積み上がらない」状態に陥ります。

「AIで効率化」と聞きますが、インシデントの判断はAIには任せられません。求められるのは、初動の動き出しを定型化し、postmortem下書きを自動生成して、PMが判断と教訓抽出にだけ集中する運用です。

この記事では、Claude Codeでインシデントplaybookとpostmortemを型化する実装を、現場で動かせる粒度で解説します。

なぜpostmortemは書かれないのか

インシデント対応で疲弊したPMが、postmortemを書かないのは怠慢ではなく構造的な問題です。

  • 動き出しが毎回ゼロから：誰を呼ぶか、何を確認するか、毎回考えるため対応指揮で消耗する
  • 時系列ログが分散：Slack・電話・メール・通話メモにバラバラで、後から事実関係を再構築できない
  • postmortemの型が決まっていない：書き始めの負荷が大きく、結局先送りになる

Claude Codeは、Skillで「初動playbook」と「postmortem下書き」を型化し、PMが判断と教訓抽出に集中できる運用を素直に組めます。

Claude Codeを「インシデント対応支援器」にする全体像

必要な要素は次の3つです。

  1. インシデントログMCP：Slack・PagerDuty・JIRAなどのインシデントチャンネルを読み取り
  2. playbook & postmortem Skill：初動の動き出しガイドと、収束後のpostmortem下書きを生成
  3. CLAUDE.md炎上対応運用ルール：重大度区分、エスカレーション基準、postmortem運用ルール

これが揃えば、PMはインシデント発生時に「何を確認し、誰を呼ぶか」が即座にわかり、収束後は下書きを校正するだけでpostmortemが揃います。

ステップ1：playbook定義をYAML化する

docs/incident/playbook.yaml に重大度別の初動手順を定義します。

severity_levels:
  - level: "P1"
    definition: "本番停止／顧客影響広範"
    response_sla: "15分以内"
    initial_actions:
      - "Incident Commanderを宣言"
      - "Slack #incident-war-room を作成"
      - "重大度・影響範囲・暫定対応方針を5分以内に投稿"
      - "経営エスカレーション（本部長・CTO）"
    required_roles:
      - "Incident Commander（PM）"
      - "技術リード"
      - "顧客対応窓口"
      - "広報担当"
  - level: "P2"
    definition: "機能不全・代替運用で凌げる"
    response_sla: "1時間以内"
    initial_actions:
      - "Slack #incident で第一報"
      - "影響範囲とETAを30分以内に共有"
      - "部長へエスカレーション"
    required_roles:
      - "PM"
      - "技術リード"
postmortem_template:
  sections:
    - "1. 概要（発生・検知・収束時刻）"
    - "2. 顧客影響（範囲・件数・損失）"
    - "3. 時系列（事実のみ）"
    - "4. 直接原因"
    - "5. 根本原因（5 Whys）"
    - "6. 再発防止策（短期/中期/長期）"
    - "7. 教訓"

「重大度ごとの動き出し」を構造化することで、判断の遅延を最小化します。

ステップ2：playbook & postmortem Skillを定義する

.claude/skills/incident-support/SKILL.md を作成します。

---
name: incident-support
description: インシデント発生時に初動playbookを表示し、収束後はSlackタイムライン等から事実を集約してpostmortem下書きを tmp/incidents/{incident-id}/postmortem-draft.md に出力する
disable-model-invocation: true
allowed-tools: Read, Write, Bash, mcp__slack__*, mcp__jira__*
---

# インシデント対応支援Skill

## モード
- mode=initial：playbookを参照し、severity別の初動手順を表示
- mode=postmortem：Slackタイムラインを集約し、下書きを生成

## 初動モード（mode=initial）の処理
1. severity入力を受け取る
2. docs/incident/playbook.yaml の該当levelを読む
3. initial_actionsとrequired_rolesをチェックリスト形式で表示
4. PMが各項目をチェックする運用

## postmortemモード（mode=postmortem）の処理
1. Slackの該当チャンネル（#incident-XXX-war-room）を全件取得
2. 時系列でメッセージを整理し、決定・行動・観測事実を抽出
3. JIRAから該当インシデントチケットの情報を取得
4. playbook.yamlのpostmortem_templateに沿って下書きを生成
5. 「直接原因」「根本原因」「再発防止策」「教訓」は **空欄** で出力

## 出力フォーマット
- ファイル：`tmp/incidents/{incident-id}/postmortem-draft.md`
- セクション：playbookテンプレに従う

## 厳守
- 時系列は事実のみ。AIによる解釈を含めない
- 顧客影響の数字は元データを引用、推計しない
- 「直接原因」以降は人間が書く（AIに書かせない）

「直接原因以降は人間が書く」が運用の核心です。原因と再発防止策は事業判断・組織判断であり、AIに書かせると的外れになります。

ステップ3：CLAUDE.mdに炎上対応運用ルールを書く

## 炎上対応・postmortem運用ルール

### 重大度の自動判定基準
- P1：本番停止／顧客100名以上に影響／復旧見込み2時間以上
- P2：機能不全（代替あり）／顧客10名以上／復旧見込み1時間以上
- P3：軽微な不具合／顧客10名以下／代替手段あり

### Incident Commander原則
- P1のIncident Commanderは必ずPMが担う（技術リードに任せない）
- Commanderは指揮に専念し、自分で技術対応をしない
- 5W（What/When/Where/Who/Why）の最新版を15分ごとに war-room に投稿

### postmortem運用
- 収束から72時間以内に下書き完成
- 1週間以内にpostmortem会議
- 教訓と再発防止策は docs/incident/learnings/ に蓄積

### AIに任せないこと
- 直接原因・根本原因の判定（事業文脈と技術文脈の両方が必要）
- 再発防止策の選定（コスト・組織影響を含むため）
- インシデント中の意思決定（必ず人間が判断）

CLAUDE.mdは「人間が判断する境界」を明示する場所。AIに任せていい範囲を逸脱しないようガードします。

ステップ4：実際の運用フロー

インシデント発生時の動きは次の通りです。

  1. 第一報受領：PMが claude を起動し /incident-support mode=initial severity=P1 を実行
  2. 初動チェックリスト：表示された手順に従って動く（Commander宣言、war-room作成、エスカレーション）
  3. 対応中：war-roomに15分ごとに5W更新、決定事項をJIRAに記録
  4. 収束後72時間以内：/incident-support mode=postmortem incident-id=INC-2026-005 で下書き生成
  5. postmortem会議：下書きをベースに「直接原因」以降を議論、確定版を作成

慣れれば、postmortemを書く心理的ハードルが下がり、教訓が組織に蓄積され始めます。

期待効果と運用上の注意点

導入チームから報告される効果は3点です。

  • 初動の動き出しが定型化：PMが指揮に専念でき、対応の質が上がる
  • postmortemが本当に書かれる：下書きが自動で揃うため、書く心理的負荷が下がる
  • 教訓が組織に蓄積する：postmortemが運用されると、再発防止が効き始める

落とし穴は3つ。

  • playbook.yamlのメンテを怠らない：組織変更や技術変更時に必ず更新する
  • 直接原因をAIに書かせない：事実誤認が混じる
  • インシデント中の意思決定を急がない：playbookは型であり、状況次第で外す勇気も必要

まとめ

  • インシデント対応の属人化は動き出しの定型化不足とpostmortemの先送りで起きる
  • Skillで初動playbookとpostmortem下書きを型化すれば、PMは指揮と教訓抽出に集中できる
  • 「直接原因以降は人間が書く」境界を守ることで、postmortemの質を担保できる
  • 教訓が積み上がる組織は、再発防止の手数が増え、炎上が起きにくくなる

ここまでで「動くインシデント対応支援器」は手に入ります。実務でこれを“炎上に強い組織運用”に育てるには、エスカレーション戦略、CCB（Change Control Board）連携、組織横断のpostmortem共有設計といった上位設計が必要です。

FFF-103『炎上対応の初動設計』 と FEX-106『postmortem運用』 を組み合わせると、本記事のSkillをベースに、炎上時の指揮と教訓蓄積を体系で学べます。「インシデントを乗り切るが教訓が積み上がらない」PMが、最短で“組織で炎上を学習する運用”に到達するための導線です。