incident-postmortem

インシデント事後分析スキル

業界標準の形式に沿った、完全で非難のないインシデント事後分析ドキュメントを作成します。出力では、個人の失敗ではなくシステムの不備に焦点を当てた、非難のない表現を徹底し、曖昧なプロセス改善の約束ではなく、具体的で完了可能なアクションアイテムにつなげます。

目的と少し違いますか？ AI エージェントがインシデントを引き起こした場合（ツールの暴走、ハルシネーションを含む機能のリリースなど）は、agent-incident-postmortem を使用してください。

アクションを提案する

アクションアイテムはドキュメントに記載するだけで終わらせる必要はありません。action-runner に渡すと、内容をプレビューし（ドライランでリスクを評価）、接続されたアクション MCP を通じて承認されたものだけを実行し、実施した内容を脳に記録します。一般的な例は、各アクションアイテムについてフォローアップ課題を登録することです（🟡）。担当者と期限を設定します。このスキルは提案し、action-runner は承認を確認して実行します。決してひそかに実行することはありません。

位置づけ — インシデントを修正につなげる

インシデント対応の中核をなす流れの3番目です。/slo-error-budget（状況を整理） → /debugging-log-analyser → incident-postmortem → /oncall-runbook。/debugging-log-analyser から根本原因の診断を受け取り（再診断せず、内容を確認します）、寄与要因と優先順位付きのアクションアイテムを /oncall-runbook に引き継ぎます。また、/slo-error-budget のエラーバジェットによって、それらのアクションの緊急度が決まります。非難のない分析、根本原因と寄与要因、アクションアイテムの定義は、docs/craft/incident-response.md にまとめてあります。非難のない分析は、他のすべてを支える重要な原則です。

手順

誰かに責任を押しつけた時点で、事後分析は失敗です。正直な情報が出てこなくなり、以降のインシデントはすべて過少報告されます。フェーズ1でこの枠組みを定めます。以降のすべては、それを前提とします。

1. まず、非難のない枠組みを確立します。 有能な人がその行動を取れる状況を生み出したシステムを調査するのであり、個人を調査するのではないと、冒頭で明言します。これは単なる礼儀ではありません。このスキルの後続ステップに必要な、真実に基づく時系列を得るための前提条件です。 完了条件： この枠組みが明確に示され、ドキュメント内に個人を非難する文がなく、失敗の原因がシステムの不備に帰属されています。
2. 証拠に基づいて時系列を作成します。 実際のタイムスタンプを使って、発生 → 検知 → 緩和 → 解決の流れを再構成します（記憶ではなく、診断結果とログに基づきます）。検知、緩和、解決はそれぞれ別の出来事です。個別に記録してください。 完了条件： 実際のタイムスタンプを使った時系列で、検知・緩和・解決が分けて記録され、影響（ユーザー数、継続時間、範囲）が定量化されています。
3. 根本原因と寄与要因の両方を特定します。 根本原因は1つです。寄与要因とは、影響がユーザーに及び、その状態が続くことを許した要因（アラートの欠如、カナリアリリースの省略、不明確なランブックなど）です。根本原因だけを記載し、寄与要因を挙げていない事後分析では、十分に調査できていません。 完了条件： 少なくとも重要な寄与要因が特定され、それぞれが修正可能なシステムの不備を指摘しています。
4. エラーバジェットを考慮し、担当者と期限を定めたアクションアイテムにつなげます。 寄与要因を具体的なアクションアイテムに変換し、それぞれに担当者と期限を設定します。「モニタリングを改善する」といった曖昧な項目は、やがて形骸化します。エラーバジェットに照らして優先順位を付けます（消費済みなら今すぐ、健全なら早めに対応）。
   完了条件： すべてのアクションアイテムに担当者と期限が設定され、/oncall-runbook がインシデントを再分析せずに、検知と緩和から得た知見を項目にまとめられる状態です。

必要な入力

提供された情報をもとに作成します。次の項目が不足している場合も、完成した出力を作成してください。不足箇所は妥当な推定で補い、(推定、要確認) と記し、最後に推定内容を列挙してください。中心となる題材そのものが欠けている場合（書くべき内容が何もない場合）に限り、最初に質問してください。

• インシデントのタイトル／ID
• 重大度（P1／P2／P3 または SEV1／SEV2／SEV3）
• インシデントの発生日と継続時間
• 何が起きたか（大まかなメモで構いません。スキルが内容を整理します）
• 影響を受けたサービスまたはシステム
• 顧客への影響（影響を受けたユーザー数、低下した機能など）
• 検知方法
• 解決方法
• 根本原因についての初期見解
• 特定済みのアクションアイテム（任意）
• 対応者（オンコール担当者または対応者。名前または役割。時系列の作成に使用し、責任追及には使用しません）
• 顧客または外部への連絡（任意。ステータスページの更新、メール、サポートメッセージなど。タイムスタンプがあれば記載してください）

Brain からの読み込み／Brain への書き込み

professional-brain（brain/）がある場合は、質問する前に利用してください。

• 先に読む： 影響を受けたシステムの entities/ ファイルと、関連する過去の decisions/ またはインシデントを確認します（繰り返し発生している根本原因を明らかにすることが最も重要です）。
• 作成後に書き込む： アクションアイテムと決定事項を decisions/ に、根本原因から得られた知見を knowledge/ に記録します。測定で確認された原因には [data]、推測された原因には [hunch] を付けます。逆にしてはいけません。

詳細資料

• references/root-cause-digging.md — 適切な「なぜなぜ分析」（変更可能なシステム特性に行き着くまで掘り下げ、原因・検知・対応の各経路を分ける）、確認すべき寄与要因の分類、責任追及につながる表現からシステムに焦点を当てた表現への書き換え方法を説明しています。根本原因のセクションを書く際と、責任追及につながる入力メモを書き換える際に使用してください。
• templates/review-meeting-agenda.md — 45 分間の、ドキュメントを中心としたポストモーテムレビュー会議の議題です。基本ルールとアクションアイテムの品質確認基準が含まれています。完成したポストモーテムとあわせて提示してください。

出力形式

---

インシデントポストモーテム：［インシデントのタイトル］

インシデント ID： ［ID］ 重大度： ［P1／P2／P3］ 日付： ［日付］ 継続時間： ［開始時刻 → 解決時刻 — 合計継続時間］ ステータス： ［解決済み／監視中／継続中］ 作成者： ［ユーザーが記入するため空欄にします］ 最終更新日： ［日付］

---

エグゼクティブサマリー

［3～5 文で記載します。何が起き、誰が影響を受け、解決のために何を行ったかを説明します。技術者以外の関係者向けに、専門用語を使わず、責任追及を避けて記述してください。］

---

影響

項目	詳細
影響を受けたユーザー	［人数または割合］
機能が低下したサービス	［影響を受けたサービスの一覧］
ビジネスへの影響	［収益、SLA 違反、サポートチケットなど。判明している場合］
継続時間	［最初の検知から完全な解決までの合計時間］

---

時系列

イベントを時系列順に列挙します。各項目は「[HH:MM UTC] — [何が起きたか。誰が何をしたか。何が変わったか。]」の形式にします。

時系列の項目に関するルール：

• 受動態またはシステムを主語にした表現を使い、「X がミスをした」のような表現は避けます。
• 次の内容を含めます：最初の兆候、検知、エスカレーション、検証した仮説、適用した修正、解決の確認
• 重要なイベント間の時間を記載します（例：「検知からエスカレーションまで 22 分」）

時系列の図示 — インシデントの時系列を Mermaid のガントチャートでも表し、間隔（例：検知 → エスカレーション）をひと目で確認できるようにします（プレイグラウンドではライブ表示され、PNG としてエクスポートできます）。インシデントの各フェーズをバーで表し、責任追及を避け、システムに焦点を当てた表現にします。

gantt
    title Incident timeline (UTC)
    dateFormat HH:mm
    axisFormat %H:%M
    section Phases
        Undetected impact   :22:00, 18m
        Detection           :milestone, 22:18, 0m
        Investigation       :22:18, 22m
        Mitigation          :22:40, 15m
        Resolved            :milestone, 22:55, 0m

---

根本原因

主な根本原因：［明確な一文。専門的でありながら平易に記述します。「デプロイ設定の誤りにより……が発生した」］

寄与した要因：

• ［要因 1 — 例：カナリアデプロイがなかったため、変更が即座にトラフィックの 100％に適用された］
• ［要因 2 — 例：アラートのしきい値が高すぎたため、初期の劣化を検知できなかった］
• ［要因 3 — 該当する要因を追加します］

既存の安全対策では、なぜこれを防げなかったのでしょうか？ ［監視、テスト、プロセスで、なぜこれをもっと早く検知できなかったのかを率直に説明する段落。非難しない分析が最も重要な箇所です。個人の失敗ではなく、システム上の不備に焦点を当てます。］

---

検知

• 最初にどのように検知しましたか？ ［顧客からの報告／自動アラート／内部監視／手動での観察］
• インシデント発生から検知までの時間： ［X 分］
• もっと早く検知すべきでしたか？ ［はい／いいえ — その理由］

---

解決

何によって修正されましたか？ ［実際に行った修正を明確に説明します — 1 段落］ なぜそれが機能したのでしょうか？ ［簡潔な技術的説明］ 完全に解決する前に、一時的な緩和策を講じましたか？ ［はい／いいえ — はいの場合は説明します］

---

アクションアイテム

#	アクション	担当者	期限	優先度
1	［具体的で検証可能なアクション］	［チームまたは担当者］	［日付］	P1/P2/P3

アクションアイテムのルール：

• 各アクションは「完了」または「未完了」と判定できるほど具体的にします。「監視を改善する」のような曖昧な項目は避けてください
• 次の区分を明確にします：再発防止（根本原因を修正する）、検知の改善（次回はより早く検知する）、対応の改善（次回はより早く解決する）
• 実際の担当者を割り当てます — 避けられる場合、「チーム」や「未定」は使いません
• P1 のアクションは、インシデントを完全にクローズ済みとするうえで、完了が必須の項目として明示します

---

うまくいったこと

［対応について、率直な所見を 3～5 件記載します。迅速な連携、適切なランブックの活用、効果的なエスカレーション、明確なコミュニケーションを含めます。このセクションはチームの自信を育み、良い習慣を強化します。］

---

学んだこと

［このチーム以外にも共有する価値のある、インシデントから得た重要な知見を 3～5 件記載します。他の状況にも応用できる教訓として書きます。例：「データベースのフェイルオーバーに関するランブックでは、リードレプリカの遅延が考慮されていませんでした。データベースのフェイルオーバーに関するランブックをすべて見直す必要があります。」］

---

コミュニケーションログ

［任意 — ステータスページの更新、顧客へのメール、サポートへの回答など、送信した外部向けの連絡を列挙します。タイムスタンプも含めます。］

---

採点基準（0～40）

引き渡す前に、このスキルの出力を採点してください。32 点以上がリリース可能な品質です。

評価項目	0	5	10
非難を避けつつ、事実を伝えているか	個人を名指しで非難する、または話の本質が消えるほど事実を薄めている	非難を避けた表現だが、個人の行動が曖昧になっている	システムの枠組みの中で個人の行動を事実として記述しており、率直さと安全性を両立している
根本原因の深さ	症状または「人為的ミス」の説明にとどまっている	システム上の不備を挙げているが、「なぜ」を 1 段階しか掘り下げていない	根本原因と寄与した要因によって、何が壊れたかだけでなく、なぜシステムがそれを許したのかを説明している
タイムラインの調査精度	情報が少ない、順序が不明、または検知から解決までの出来事が欠けている	情報はそろっているが、タイムスタンプや意思決定の節目がない	タイムスタンプがあり、検知までの遅れ、意思決定の節目、実際に調査した行き詰まりも記録されている
アクションアイテムの説明責任	改善案が曖昧で、担当者がいない	担当者は割り当てられているが、チケット化できない、または期限がない	すべての項目がチケット化でき、担当者と期限が明記され、根本原因または寄与した要因と結び付いている

品質チェック

• タイムラインに非難する表現が含まれていない
• 根本原因が具体的である（「人為的ミス」ではない）
• 根本原因が「何が起きたか」だけでなく「なぜ起きたのか」に答えている。症状ではなく、システムやプロセスの欠陥を示している
• 寄与要因がシステム上の欠陥を説明している
• すべてのアクションアイテムに担当者と期限が設定されている
• 「うまくいったこと」のセクションが形だけではなく、実質的な内容になっている
• 「監視を改善する」「レジリエンスを高める」「テストを改善する」などの曖昧な表現を含むアクションアイテムがない。それぞれに具体的な変更を明記している
• エグゼクティブサマリーが、技術的な知識のない経営陣にも読みやすい

アンチパターン

• 個人を非難しない。ポストモーテムでは、システムやプロセスの不備に焦点を当てる必要があります
• 「監視を改善する」などの曖昧な表現でアクションアイテムを書かない。それぞれに担当者が明確な具体的変更を記載する必要があります
• 寄与要因を省略しない。根本原因だけでは、インシデントの発生を可能にしたシステム上の問題を見落とします
• 検知までのタイムラインを省略しない。解決までにかかった時間と同じくらい、検知までにかかった時間が重要です
• すべてのアクションアイテムに担当者と期限が設定されるまで、ポストモーテムを完了扱いにしない

使用例

• 「[incident name] の障害に関するポストモーテムを作成してください」
• 「P1 インシデントレポートの作成を手伝ってください」
• 「[date] に発生した [service] の停止について、RCA ドキュメントを作成してください」
• 「次のメモをもとに、個人を責めないポストモーテムの草案を作成してください：[paste notes]」

トリガーフレーズの例

• 「ポストモーテムを作成してください。」
• 「インシデントレポートを作成してください。」
• 「P1 レビューを作成してください。」
• 「障害の根本原因分析をしてください。」