# ポストモーテムの教科書 SRE とインシデント管理の分野で蓄積されてきた 30 以上の文献を横断し、ポストモーテムとインシデント分析の理論、実践、研究を体系的に構成した。 初学者が基礎から読み進め、実践者が深化し、研究者が未解決の問いを探索できる構成を目指す。 --- ## 第 I 部　ポストモーテムの基礎 ### 第 1 章　定義と目的 **ポストモーテム**（postmortem）とは、インシデント発生後に行う非難なき事後振り返りである。 何が起きたか、なぜ起きたか、どう対応したか、再発をどう防ぐかを構造化して記録し、個人でなくシステムの欠陥に焦点を当てる。 語源はラテン語の「死後の検査」だが、ソフトウェアの文脈では組織としての学習を行う営みを指す。 Google の SRE Book（2016）がこの用語を業界に広め、多くの組織が採用した [1]。 Sidney Dekker（2015）はポストモーテムの目的を 4 層に定式化した[^dekker-purpose]。 | 目的 | 内容 | SRE での位置づけ | |---|---|---| | 認識論的 | 何が起きたかを確立する | タイムライン、ログ、影響範囲の記録 | | 予防的 | 回避への経路を特定する | 再発防止策、アクションアイテム | | 道徳的 | 逸脱を跡付け境界を強化する | 運用規範の再確認 | | 実存的 | 発生した苦痛への説明を見つける | 関係者の心理的クロージャー | 従来の SRE ポストモーテムは認識論的目的と予防的目的に集中し、道徳的目的と実存的目的を「非難文化になるから避ける」として抑制する傾向がある。 しかし後者を全否定するのではなく、非難でなく学習に向けることが現代的な理解である。 [^dekker-purpose]: Dekker の定式化は Lund の講演 [4] で紹介されている。 ### 第 2 章　三つの柱 「ポストモーテム」は以下の三つの柱で成り立つ。 #### ブレームレス文化 人でなくシステムの欠陥に焦点を当てる。 ポストモーテムを書いた人を賞賛し、広く共有する。 ただし「ブレームレス（非難なし）」という表現には落とし穴がある。 Will Gallego（Etsy）は、この表現が「責任の否定」と誤解されやすく、「誰がどのような判断をしたか」という必要な情報が隠蔽される問題を指摘した。 代替概念として**ブレーム・アウェア**（blame-aware、非難認識）を提唱している。 非難感情の存在を認めつつ、それを指差しとして表出させない姿勢である [3]。 #### 構造化プロセス タイムライン中心の文書作成、重大度別の会議スケジュール、ステータスワークフロー（Draft → In Review → Reviewed → Closed）、アクションアイテムの追跡。 PagerDuty は重大度別に 15〜30 分の会議を処方する [18]。 #### ツーリングと発見可能性 データの一元化、自動生成テンプレート、リビングドキュメントとしての運用、タグベースの検索。 Datadog はこれら 4 つの実践（データ一元化、自動テンプレート、リビングドキュメント、発見可能性）を提示した [19]。 ### 第 3 章　基本プロセス 典型的なプロセスは以下の通りである。 1. **インシデントの終了判定**：緩和と復旧が完了し、サービスが安定している 2. **ポストモーテム文書の作成**：タイムライン、影響範囲、寄与因子、対応内容、再発防止策を記録 3. **レビュー会議の実施**：関係者が集まり、文書の内容を議論する 4. **アクションアイテムの設定と追跡**：再発防止に必要な具体的作業を特定し、所有者と期限を設定 5. **共有と発見可能性の確保**：関係者以外も含めて広く共有し、検索可能にする #### 再発防止策の 4 分類 mixi が示した構造化フレームワークは、再発防止策を場当たり的に列挙するのではなく、4 つのカテゴリで網羅的に検証する [20]。 | カテゴリ | 問い | |---|---| | 予防 | この障害の発生自体を防げるか | | 検出 | もし発生したら、より早く検知できるか | | 緩和 | 検知した後、影響をより早く小さくできるか | | 修正 | 根本的な修正を行い、同種の問題を解消できるか | --- ## 第 II 部　事故はなぜ起きるのか ### 第 4 章　事故モデルの進化 ポストモーテムでどのような分析を行うかは、意識するしないにかかわらず「なぜ事故が起きるのか」に関する**事故モデル**に依存する [16]。 #### Bad Apples モデル 最も原始的なモデルである。 「システムは基本的に安全であり、信頼性のない人間が障害を引き起こす」と仮定する。 「悪いリンゴを取り除けばよい」という結論に至るため、個人への制裁（懲罰、解雇、降格）が改善策となる。 Amazon、NASDAQ、ドイツ鉄道の公開インシデント報告がすべて "Human Error" と結論づけていた事実が、このモデルの根強さを物語る [16]。 #### ハインリッヒのドミノ理論（1931） 事故を「社会環境 → 人間の欠陥 → 不安全行為 → 事故 → 怪我」の連鎖ドミノとして説明する。 直線的因果連鎖を前提とし、1 つのドミノを除去すれば連鎖が止まるという楽観的仮定を持つ。 #### スイスチーズモデル（Reason, 1990） 組織の防御層（チーズのスライス）には穴（能動的失敗と潜在的条件）があり、すべての穴が揃った瞬間に危険が貫通するというモデルである。 Bad Apples より洗練されているが、依然として「障壁の欠陥」という静的な構造に注目し、動的なシステム適応を捉えにくい。 Reason 本人も後に改訂を要求している [16]。 #### Normal Accidents（Perrow, 1984） 密接に結合した複雑系では、想定外の相互作用による大規模事故は避けられないとする。 悲観的だが、サプライズが設計に内在するという洞察は現代のマイクロサービスアーキテクチャにも通じる。 #### Systems Theory と CAST Nancy G. Leveson が提唱した**CAST**（Causal Analysis based on Systems Theory）は、線形因果論を離れ、「制御構造」「コントローラーの意思決定とメンタルモデル」「文脈要因」「システム的要因」を析出する。 Google Maps の「都市名誤り」インシデントでは、RCA が「ツールの不備」「サンプリング戦略の欠如」と結論したのに対し、CAST は「チームのメンタルモデルの誤り」「責任拡散」「データセット変化による既存ポリシーの陳腐化」を追加で特定した [14]。 #### 事故モデルの選択がポストモーテムを規定する どのモデルを採用するかが、何を「原因」として記録し、何を「改善策」として立案するかを変える。 Bad Apples モデルでは個人の処分がアクションアイテムになり、スイスチーズモデルでは防御層の追加が、CAST ではメンタルモデルと組織構造の改善が改善策となる。 ### 第 5 章　Cook の 18 命題 Richard I. Cook（1998）の "How Complex Systems Fail" は、ポストモーテム実践者にとっての正典テキストである [15]。 ここでは特にポストモーテムに直結する 5 つを取り上げる。 **命題 4：潜在的障害の混合を常に内包する** 複雑システムは、障害の前兆をすでに含んだ状態で日常的に稼働している。 問題は「潜在的障害があるかどうか」ではなく「いつ顕在化するか」である。 **命題 5：劣化モードで稼働する** 完全に健全な複雑システムは存在しない。 常にどこかが劣化している状態で動いている。 **命題 7：根本原因帰属は根本的に誤りである** 複数故障が必要条件を構成するため、単一の「根本原因」は存在しない。 RCA は技術的理解ではなく、「特定の原因に責任を帰属させる社会的、文化的必要性」を反映する行為である。 **命題 8：ヒンドサイトバイアス** 結果を知っていることが、事故前の実践者の視点を再現する能力を損なう。 「あの時こうしていれば」は事後だから言えることであり、当時の限定的な情報のもとでは判断は合理的だった可能性が高い [15]。 **命題 12：人間は複雑システムの適応的要素** 人間は障害源であると同時に、脆弱部の再構成、リソースの集中投入、回復経路の確保、劣化の早期検知という 4 形態の適応で安全を生み出す存在でもある。 ### 第 6 章　ローカル合理性とヒューマンエラー批判 「ヒューマンエラー」をポストモーテムの結論にすることは、分析の行き止まり（analytical dead end）である。 この観察は 3 人の実践者が独立に到達した収束点である。 - Gallego（Etsy, 2018）：「人はその時点の情報において最善と信じる行動をとる」。**ローカル合理性**（local rationality）と呼ばれる原則 [3] - Lund（Microsoft, 2019）：「Human Error は analytical dead end」[4] - Eckhardt（Heroku, 2019）：「ヒューマンエラーは調査を終わらせる場所でなく、始める場所」[5] いずれも Sidney Dekker の New View（人間は機能不全の源泉ではなく、システムの適応的要素）を SRE 実践に翻訳したものである。 ポストモーテムで「ヒューマンエラー」と書きたくなった時は、以下の問いに展開する。 1. その人間はどうエラーを起こしたか 2. エラーが起きやすかった条件は何か 3. エラーがシステムに影響した経路は何か 4. 人間がエラーに気づくまでどのくらいかかったか --- ## 第 III 部　ポストモーテムの運営 ### 第 7 章　ファシリテーション技術 ポストモーテム会議の質は、ファシリテーターの言語選択と会議運営に大きく依存する。 #### Why/You を How/What に変換する Gallego、Lund、Eckhardt の三者が独立に収束した言語規律である。 | 避けるべき | より良い代替 | |---|---| | 「なぜあなたは X したのか」 | 「X が行われた経緯をもう少し詳しく聞かせてください」 | | 「なぜ前回直さなかったのか」 | 「この問題が以前にも見えていたとしたら、当時どういう状況だったか教えてください」 | | always, never, should, just | 具体的な事象、数値、条件の記述 | 「なぜ前回これが起きたとき直さなかったのか？」という問いには 5 つの後知恵バイアスの前提が埋め込まれている。 (1) 以前に起きた、(2) 前回直せた、(3) 容易に直せた、(4) あなたが直す人間だった、(5) 直さない正当な理由がなかった [5]。 #### デブリーフィングの 7 カテゴリ Gallego が体系化した問いかけフレームワーク [16]。 1. **Cues**：何を見ていたか 2. **Interpretation**：状況をどう理解していたか 3. **History**：この状況は見覚えがあるか 4. **Goals**：何を達成しようとしていたか 5. **Action**：どう行動を選んだか 6. **Communications**：どのコミュニケーション手段を使ったか 7. **Help**：誰かに助けを求めたか この配列は「その時点で世界がどう見えたか」を段階的に再構築するよう設計されている。 #### 会議の心得 **個別インタビューを先行させる**。 グループ設定で誰かの記憶が他者に上書きされることを防ぐ。 インシデント当日ではなく前週から問い起こし、疲労、プレッシャー、文脈を引き出す [4]。 **ユーモアを管理する**。 「喜劇は悲劇＋時間」である。 ポストモーテムには十分な時間が経っていない。 ジョークの代わりに温かさ、誠実さ、感謝を示す。 **沈黙者を観察する**。 沈黙は「言うことがない」ではなく「割り込む機会を得られない」ことが多い。 **会議の目標を明示する**。 Lund は次のように述べた。「この会議の目標は、このインシデントを二度と起こさないことではない。学ぶことだ。アクションアイテムがゼロで終わっても、価値のある議論だったと感じられるべきだ」[4]。 #### Miller's Law 「相手の言葉を理解するには、それが真だと仮定してどういう状況なら真になるかを想像しなければならない」（George A. Miller）。 自分の直接経験の外にある発言（同一インシデントに関わった別の人間の体験）を理解する手法である [5]。 ### 第 8 章　インシデントレポートの書き方 #### テンプレート型とナラティブ型 多くのインシデントレポート（IR）がテンプレートを機械的に埋める形で書かれ、関係者以外に読まれないまま学習機会が失われる。 Laura Nolan（Stanza Systems, 2022）はナラティブ型 IR を提唱した [9]。 | 側面 | テンプレート型 | ナラティブ型 | |---|---|---| | 構造 | 定義済みセクションへの箇条書き | 謎 → 調査の試行錯誤 → 解決の 3 部構成 | | 読者性 | 関係者以外はほぼ読まない | 関心あるエンジニアなら誰でも引き込まれる | | 学習の深さ | 「何が起きたか」の事実記録 | 「その時点で何が見えていたか」の再現 | | 長期価値 | 形骸化しやすい | 年単位で語り継がれる知識になりうる | Lorin Hochstein（Airbnb, 2026）はさらに踏み込み、ポストモーテムテンプレートの中で本当に気にすべきはナラティブ記述のセクションだけであると述べた。 時系列で書き、意味のある区切り（エピソード）に小見出しを付け、インシデント開始より前（数ヶ月〜数年前）から書き始めることを推奨する [13]。 #### 良い IR の 4 軸 1. **ナラティブ重視**：ストーリーとして書く。不確実性や「まだ分かっていなかった」状態を率直に記述する 2. **読者サポート**：すべてのエンジニアが読めるよう、ジャーゴンとシステム名を説明する 3. **視覚化**：アーキテクチャ図、グラフ、タイムライン、スクリーンショットを惜しまず使う 4. **分析の共有**：技術的修正だけでなく、システム運用の洞察まで踏み込む #### 文体の原則 - **印象的なタイトル**：読者が後で参照できる記憶に残るタイトルを付ける（例："Cascade of doom: JIT, and how a Postgres update led to 70% failure on a critical national service"） - **シンプルで明確な言語**：専門的手順も「通常であれば簡単なはずなのに」という文脈から始める - **セールスピッチにしない**：誠実、謙虚、正直が信頼を生む #### SRE 主導の執筆会議 KATO Toshiya（LINE）は、当事者のみで執筆、共有する既存プロセスの 5 つの構造的問題を指摘し、全体共有前の 30 分執筆専用会議を SRE が主導する手法を実践した。 黙読 → 質問 → 提案 → Kudo wall → 会議後編集の流れで、副次効果として共有会議が短時間で終わるようになった [25]。 ### 第 9 章　プロセスの実装パターン 各組織の実装を比較する。 | 側面 | PagerDuty | Datadog | mixi | Hatena | カヤック | |---|---|---|---|---|---| | 文書の中核 | タイムライン | インタラクティブグラフ | テンプレート 5 項目 | 報告 5 項目 | Slack 月次投稿 | | 再発防止策 | フォローアップチケット | タグベース検索 | 4 分類 | 予防策＋備考 | sre-advisor | | 会議体 | 15–30 分 SEV 別 | 明示なし | 明示なし | 明示なし | 月刊ポストモーテム | | 共有範囲 | IC＋対応者 | チーム | 関係者 | 全社エンジニア | 全社 Slack | | 文化的強調点 | ブレームレス | 効率化 | 賞賛文化 | 横展開学習 | 知見のコード化 | #### Blameless の 6 要素 Ashar Rizqi（Blameless 社、300 社以上の事例）が体系化した成功要件 [23]。 1. **Ownership**：サービスオーナー = ポストモーテムオーナー 2. **Context & Key Details**：コンテキストと詳細情報の記録 3. **On Time Completion**：期日内の完了（Slack 上での非同期実施で負荷軽減） 4. **Follow-up Action Items Tracked to Completion**：完了までの追跡 5. **Blameless Language**：ブレームレスな言語 6. **Referenceability**：再参照性（未解決の問題として残る） --- ## 第 IV 部　「修復」から「学習」への転換 ### 第 10 章　Repeat Incident Fallacy 「このインシデントが二度と起こらないよう……」というポストモーテムの定型結語は、誤った前提に立つ。 Emily Ruppe（Jeli.io, 2022）はこれを **Repeat Incident Fallacy**（再発インシデントの誤謬）と名づけた [8]。 Laura Maguire の命題がその論拠である。 CI/CD = 継続的変化ゆえに、規模のある複雑社会技術システムで「同一インシデント」は二度と起きない。 この認識は 4 人の実践者が独立に収束した同一のパラダイムシフトである。 | 実践者 | 定式化 | |---|---| | Gallego (2018) | 修復をポストモーテムの定義に含めない [3] | | Lund (2019) | 「このインシデントの再発防止」を会議目標から外す [4] | | Ruppe (2022) | Repeat Incident Fallacy [8] | | Partington (2022) | learning > fixing [7] | 代替目標として Ruppe が提案するのは "Insights from the Past = Options in the Future" である。 「修復の保証」でなく「選択肢の蓄積」を目標にする。 ### 第 11 章　根本原因、アクションアイテム、MTTx の除外 Tom Partington（ANZx, 2022）は、根本原因の特定、アクションアイテムの作成、MTTx 指標の追跡をすべて意図的に除外した Post Incident Review（PIR）プロセスを、高度規制産業（金融）で 1,000 人超の組織に適用し、再発インシデントがまれであると報告した [7]。 Lesson セクションの 5 問は修復を問わず経験的知識の抽出を促す。 1. What surprised us?（何が驚きだったか） 2. What went well?（何がうまくいったか） 3. What was difficult?（何が困難だったか） 4. Where did we get lucky?（どこで幸運だったか） 5. What don't we understand?（何がまだ分かっていないか） これは John Allspaw の "How learning is different from fixing" と同一テーゼを設問構造レベルで具現化したものである。 ### 第 12 章　インシデント法律主義 Will Larson（Calm CTO）は、プロセスが信頼性でなくコンプライアンスに焦点を移す病理パターンを **Incident Legalism**（インシデント法律主義）と名づけた [17]。 症状は以下の通りである。 - 繰り返しのレビュー質問 - 過度な重篤度分類の議論 - メタデータ収集への過度の注力 - 実行不可能な修復提案の積み上げ 処方はポストモーテムの数を増やすことではなく、対応、分析、修復への投資バランスを是正することである。 --- ## 第 V 部　メトリクスの功罪 ### 第 13 章　MTTR 批判と TTX メトリクス MTTR（Mean Time To Recovery）は DORA の 4 指標の 1 つとして広く使われてきた。 しかしモンテカルロシミュレーション（有名インターネット企業 3 社、10 万回）により、各インシデントの修復時間を 10% 短縮しても MTTR が 10% 以上改善されるのは 49〜64% のケースのみと判明した。 分布がべき乗則に近く、外れ値 1 件で平均が大きく動くためである [30]。 この MTTR 批判は 3 つの異なる立場から一致する。 1. Davidovič（Google SRE, 2021）：定量的シミュレーションで実証 [30] 2. Takamura（Topotal, 2025）：日本語圏で展開し TTX 代替指標を体系化 [31] 3. Nash（Verica, 2023）："shallow data" として定性的に批判 [26] 代替として **TTX メトリクス**はインシデントのライフサイクルを複数フェーズ（TTDetect, TTAcknowledge, TTEngage, TTInvestigate, TTIdentify, TTMitigated, TTFix, TTRecovery）に分解し、改善対象フェーズを特定する。 ### 第 14 章　定量データの限界 ポストモーテムの定量データには構造的な限界がある。 **サンプルサイズの問題**。 Byrum（Spotify）は、インシデントデータは統計的相関分析に「非常に問題が多い」と指摘した。 サンプルサイズが小さく母集団が不明であるため、「センサスに近い」アプローチになる [11]。 **重大性バイアス**。 Spotify のポストモーテム完了率は影響度 5 で 100%、影響度 1 で 50% であった。 重大インシデントほど丁寧に振り返られ、軽微なインシデントは記録が残りにくい [11]。 **数値はコンテキストなしでは意味がない**。 集計値はコンテキストなしで提示すると組織目標に転化しやすく、数値を操作する動機を生む [12]。 --- ## 第 VI 部　個別インシデントを超えた学習 ### 第 15 章　インシデントストーリーテリング 「ポストモーテム」の上位概念として、**インシデントストーリー**がある。 技術要素のみに焦点を当てた線形記述ではなく、豊かな社会技術的詳細を含む長形式のインシデント記録である [26]。 4 つの特性を持つ。 1. 豊かな社会技術的詳細（人間、組織、文化、感情的側面を含む） 2. 複数の異なる視点（単一の権威ある記述ではない） 3. テーマとパターンの開示（構造的課題を明らかにする） 4. 全体システムのズームイン/アウト 有用なインシデントストーリーには **anomalous**（異常性）と **immutable**（細部の保全）の 2 条件が必要である。 異常性がなければ学習は起きず、細部が失われるとモラルストーリー（単純な blame 話）に退化する [13]。 Airbnb の "Once Upon an Incident"（四半期ごと、3 名、キャンプファイア形式、アクションアイテム不要）は組織的ストーリーテリングの場として実証された。 古いインシデントでも参加者の関心は持続し、アクションアイテムが過去のものになっても学習価値は残る [13]。 ### 第 16 章　クロスインシデント分析 個別インシデントの学習を超え、複数インシデントを横断して共通パターンを発見する実践が**クロスインシデント分析**である。 Vanessa Huerta Granda（Enova、10 年の実践）がスケールに必要な 3 要素を示した [12]。 1. **専任チーム**：インシデントレビューを集中型ローテーションで行い、プロダクト作業との優先度競合を回避する 2. **構造化アーティファクト**：定量フィールドとナラティブな定性フィールドを同一アーティファクトに持つ 3. **組織計画サイクルとの連動**：四半期計画、年次計画に合わせて分析と推奨事項を提示する アクションアイテムと推奨事項の分離が鍵であり、アクションアイテムだけを作り続ける「アクションアイテムファクトリー」はアンチパターンである。 最も効果的な単一変革は部門横断の関係者招待である。 エンジニアリングだけでなくオペレーション、マーケティング、法務、コンプライアンスをレビューに招くことで視点が広がる [12]。 ### 第 17 章　インシデント考古学 Clint Byrum（Spotify, 2023）が提唱した手法である。 過去のインシデント記録を「アーティファクト」として考古学的に発掘、分析する [11]。 8 ステップの手順を取る。 (1) アーティファクトの発見 → (2) 時間的コミットの決定 → (3) 仮説の立案 → (4) タイムボックス方法論の設計 → (5) データサイエンティストとの協働 → (6) アーティファクトのリスト化 → (7) データ分析 → (8) まとめ、学習、共有。 最も価値ある発見は、探していなかった知見であった。 設定した仮説よりも副産物（起動、終了時刻の 75% がデフォルト放置、業務時間中に 80% 宣言、変更起因は 30% のみ）の方が組織に大きなインパクトをもたらした [11]。 「クロスインシデント分析」（継続的蓄積、自走プログラム）と「インシデント考古学」（過去遡及、タイムボックス探索）は相補的であり、「まず考古学で現状把握 → プログラムを整備して継続蓄積」という順序で組み合わせられる。 ### 第 18 章　知見のコード化 藤原俊一郎（面白法人カヤック）は「インシデント → ポストモーテム → sre-advisor → 事前検出 → インシデント予防」の閉ループを実践した。 ポストモーテムの振り返りから「設定不備が発生要因として多い」という傾向を発見し、その知見を AWS リソース設定の静的チェック CLI（sre-advisor）に書き込んだ [24]。 ポストモーテムで得た設定ベストプラクティスを「リリース前チェックシート」として運用すると、サービスが増えるたびにトイルが発生する。 チェックシートはトイルであり、エンジニアリングで自動検出すべきだという洞察が、このツール化の動機である [24]。 Ruppe が目標定式として提唱した "Insights from the Past = Options in the Future" を、ツール化によって具体的に実装した事例と見なせる。 --- ## 第 VII 部　インシデント対応の構造 ### 第 19 章　インシデント管理ライフサイクル インシデント管理は検知 → トリアージ → 診断 → 緩和の 4 段で処理されるライフサイクルである。 Google SRE の 8 フェーズタイムラインはより細粒度であり、Root Cause → Hits Production → Detect → Escalate → Mitigate → Resolve → Retrospect → Action Items を定義する。 修正機会は 3 方向に分類される [1]。 1. **STOP**：根本原因が本番に到達する前に止める 2. **FASTER**：Detect → Mitigate を高速化する 3. **PREVENT and FIX CULTURE**：Resolve 後に予防と学習文化を醸成する #### 緩和フェーズが TTR を支配する クラウド三社（AWS、Azure、Google Cloud）の 354 件のポストモーテム分析では、MTTD=16.9 分、MTTI=77.8 分、MTTM=304.2 分、MTTR=572.8 分であった。 緩和フェーズが TTR の 53% を占める [22]。 ### 第 20 章　調査戦略 インシデント調査には 2 種の戦略がある。 **体系的戦略**：症状から根本原因まで段階的に調査する。 「なぜ」を繰り返しシステムの挙動の連鎖を追跡するか、テクノロジースタックを層ごとに下る。 **日和見的戦略**：根本原因に概念的に直接ジャンプしようとする。 過去の経験に基づく典型的な原因の確認と、時間的相関のある異常の探索を行う。 実際のインシデント調査では両戦略を組み合わせる。 日和見的戦略が調査の出発点をより特定的にし、そこから体系的調査を継続するパターンが多い。 相関の発見だけでは不十分で、因果の理解が伴わなければ調査は失敗する。 ### 第 21 章　安全工学からの根本原因再定義 Laura de Vesine（Datadog, 2022）は、安全工学の System/Environment 境界モデルを提案した [10]。 - **根本原因**：システムの脆弱性（自分たちが制御できるもの） - **トリガー**：環境条件（自分たちが制御できないもの） この整理は「どこに修正を施すべきか」を直接指示する点で、Dekker の哲学的命題「原因は構築される」よりも実用的である。 5 Whys の病理（トリガーで止まる傾向）も診断した [10]。 --- ## 第 VIII 部　研究のフロンティア ### 第 22 章　AI とポストモーテムの自動化 Google SRE はインシデント対応中の情報を自動集約してポストモーテム下書きを生成するエージェントを運用している。 4 種のエージェント（コミュニケーション監視、ハンドオフ文書生成、ポストモーテム下書き、内外コミュニケーション管理）はいずれも人間 IC を置き換えない補助層である [29]。 LLM によるポストモーテム自動生成には以下の課題がある。 **ヒンドサイトバイアスの模倣**。 LLM は事後データ（ログ、アラート）を入力とし、既に「障害が起きた」という結果知識を含む形で分析する。 ヒンドサイトバイアスを強化するリスクは未検討である。 **"Cause is something you construct"**。 Dekker のテーゼに従えば、LLM が生成する RCA は特定のフレームを前提にした構築物である。 どのフレームが暗黙に選択されているかの検証が必要である。 **ブレームレス言語の維持**。 自動生成テキストが規範的言語（should, just, always）を含まないことの保証が求められる。 ### 第 23 章　定量研究 ポストモーテムは個別の学習文書であるだけでなく、系統分析のデータソースとしても使われ始めている。 **クラウド三社分析**。 Li ら（2022）は AWS、Azure、Google Cloud の公開ポストモーテムから TTX 値を実測し、設定ミスが最多根本原因（31.6%）であること、9 種の緩和手段分布を定量化した [22]。 **Google 内部**。 SRE Workbook Appendix C はポストモーテムの集計分析から変更起因障害やプロセス失敗の傾向を抽出した [2]。 **GQM フィードバックモデル**。 Sue Lueder（Google SRE PM, 2015）は Goal Question Metric → Collect → Organize → Analyze → Socialize の 5 段サイクルを全プロダクション障害に適用した [32]。 ### 第 24 章　逸脱の正常化 Diane Vaughan がスペースシャトル Challenger 事故の分析で提唱した概念である。 既定の許容範囲を超えた状態が繰り返し発生し、「実害がない」として受け入れられることで、逸脱が通常規範として定着していく。 SRE の文脈ではアラート閾値の繰り返し緩和が典型例である。 Hochstein はこれが「私たちが普通にやっていること」であり、特殊な病理ではなく合理的意思決定の副産物であることを強調した [13]。 ### 第 25 章　未解決の問い 本教科書が集約した知見から浮かび上がる未解決の研究課題を以下にまとめる。 #### 文化と組織 - 日本企業のポストモーテム実践（mixi、Hatena、カヤック）は中小規模の事例である。数千人規模でブレームレス文化が定着する条件は何か - ポストモーテムギルド（Rizqi 提案）は組織内スケールの手段として実際に機能するか - ナラティブ型 IR のコスト（時間、スキル）と学習効果のトレードオフ #### 測定と評価 - ナラティブ型 IR とテンプレート型 IR で「読まれた率」「組織学習への貢献」を定量比較した研究は存在するか - ポストモーテムのアクションアイテム完了率と信頼性改善の相関 - Spotify の 62% という完了率は業界平均と比べてどうか #### 自動化と AI - LLM 生成ポストモーテムの品質評価。「ブレームレス記述」と「根本原因の正確な特定」の両立 - LLM はヒンドサイトバイアスを模倣、強化するか。その緩和手法は何か - sre-advisor のような静的チェックと LLM による動的 RCA の組み合わせ方 #### 方法論 - CAST の大規模マイクロサービスへの適用。コントローラーの粒度と組み合わせ爆発の管理 - Human Factors アプローチ（個別インタビュー → デブリーフィング）の定量的効果検証 - 非同期（Slack）と同期（ミーティング）の適用条件（重大度、チーム規模、心理的安全性の成熟度） --- ## 付録 ### A. 用語集 - **ポストモーテム**：インシデント後の非難なき事後振り返り - **ブレームレス**：個人でなくシステムの欠陥に焦点を当てる文化原則 - **ブレーム・アウェア**：非難感情の存在を認めつつ表出させない姿勢 - **ローカル合理性**：人はその時点の情報において最善と信じる行動をとる - **ヒンドサイトバイアス**：結果知識が事前の視点再現を妨げる認知的バイアス - **Contributing Factor**：根本原因の代替概念。複数の寄与因子が組み合わさって障害を生む - **Incident Legalism**：プロセスが信頼性でなくコンプライアンスに焦点を移す病理 - **Repeat Incident Fallacy**：「同じインシデントの再発防止」が不可能な前提に立つ誤謬 - **CAST**：Systems Theory に基づく因果分析手法（Leveson） - **TTX メトリクス**：インシデントフェーズ別経過時間指標群（MTTR の代替） - **IR**：Incident Report（インシデントレポート） - **PIR**：Post Incident Review（インシデント後レビュー） - **逸脱の正常化**：許容範囲超過が繰り返し受容され通常化する過程（Vaughan） ### B. 参考文献 [1] John Lunney, Sue Lueder. "Postmortem Culture: Learning from Failure." *Site Reliability Engineering*, O'Reilly, 2016. https://sre.google/sre-book/postmortem-culture/ [2] Daniel Rogers, Murali Suriar, Sue Lueder, Pranjal Deo, Divya Sudhakar, Gary O'Connor, Dave Rensin. "Postmortem Culture: Learning from Failure." *The Site Reliability Workbook*, O'Reilly, 2018. https://sre.google/workbook/postmortem-culture/ [3] Will Gallego. "Architecting a Technical Post Mortem." SREcon18 Americas, USENIX, 2018. https://www.usenix.org/conference/srecon18americas/presentation/gallego [4] Tanner Lund. "A Tale of Two Postmortems: A Human Factors View." SREcon19 Asia, USENIX, 2019. https://www.usenix.org/conference/srecon19asia/presentation/lund-postmortem [5] Courtney Eckhardt. "Retrospectives for Humans (a crash course)." SREcon19 Asia, USENIX, 2019. https://www.usenix.org/conference/srecon19asia/presentation/eckhardt [6] Courtney Eckhardt, Lex Neva. "Running Excellent Retrospectives: Talking for Humans." SREcon19 Americas, USENIX, 2019. https://www.usenix.org/conference/srecon19americas/presentation/eckhardt [7] Tom Partington. "A Post Incident Review Review." SREcon22 APAC, USENIX, 2022. https://www.usenix.org/conference/srecon22apac/presentation/partington [8] Emily Ruppe. "The Repeat Incident Fallacy: What Jurassic Park Can Teach Us about Incidents." SREcon22 EMEA, USENIX, 2022. https://www.usenix.org/conference/srecon22emea/presentation/ruppe [9] Laura Nolan. "Ditch the Template: How to Write Incident Reports They Want To Read." SREcon22 EMEA, USENIX, 2022. https://www.usenix.org/conference/srecon22emea/presentation/nolan-break [10] Laura de Vesine. "Principled Identification of 'Root Causes' Using Techniques from Safety Engineering." SREcon22 EMEA, USENIX, 2022. https://www.usenix.org/conference/srecon22emea/presentation/devesine [11] Clint Byrum. "Incident Archeology: Finding Value in the Paperwork and Narratives of the Past." SREcon23 Americas, USENIX, 2023. https://www.usenix.org/conference/srecon23americas/presentation/byrum [12] Vanessa Huerta Granda. "Learning from Incidents at Scale: Actually Doing Cross-Incident Analysis." SREcon25 Americas, USENIX, 2025. https://www.usenix.org/conference/srecon25americas/presentation/granda [13] Lorin Hochstein. "The Power of Stories." SREcon26 Americas, 2026. https://www.youtube.com/watch?v=Nd0xfNmkgRI [14] Ruben Barroso. "The Case of the Misnamed Cities: CAST Analysis of a Google Maps Incident." SREcon26 Americas, USENIX, 2026. https://www.usenix.org/conference/srecon26americas/presentation/barroso [15] Richard I. Cook. "How Complex Systems Fail." Cognitive Technologies Laboratory, 1998. https://how.complexsystems.fail/ [16] Will Gallego, Nathan Hoffman, Miriam Lautner. "Accident Models in Post Mortems." SREcon16 Europe, USENIX, 2016. https://www.usenix.org/conference/srecon16europe/program/hoffman-pm [17] Will Larson. "Move Past Incident Response to Reliability." GitHub ReadME Project. https://github.com/readme/guides/incident-response [18] PagerDuty. "Post-Mortem Process." PagerDuty Incident Response Guide. https://response.pagerduty.com/after/post_mortem_process/ [19] Stephanie Niu, Paul Gottschling. "Best Practices for Writing Incident Postmortems." Datadog Blog, 2021. https://www.datadoghq.com/ja/blog/incident-postmortem-process-best-practices/ [20] mixi developers. "インフラ障害対応とポストモーテム." mixi developers ブログ. https://mixi-developers.mixi.co.jp/fault-handling-and-postmortem-6f46547b9b13 [21] shiba_yu36. "社内障害情報共有のススメ." Hatena Developer Blog, 2018. https://developer.hatenastaff.com/entry/2018/02/19/180000 [22] Xiaoyun Li et al. "Going through the Life Cycle of Faults in Clouds: Guidelines on Fault Handling." ISSRE 2022, IEEE. https://ieeexplore.ieee.org/document/9978764 [23] Ashar Rizqi. "Getting More out of Postmortems and Making Them Less Painful to Do." SREcon19 Asia, USENIX, 2019. https://www.usenix.org/conference/srecon19asia/presentation/rizqi [24] 藤原俊一郎. "1年間のポストモーテム運用とそこから生まれたツール sre-advisor." SRE NEXT 2022, 2022. https://speakerdeck.com/fujiwara3/1nian-jian-falseposutomotemuyun-yong-tosokokarasheng-maretaturu-sre-advisor [25] KATO Toshiya. "Postmortem as a textbook." LINE, SpeakerDeck, 2023. https://speakerdeck.com/line_developers/postmortem-as-a-textbook [26] Courtney Nash. "Far from the Shallows: What We Can Learn From Deeper Incident Stories." SREcon23 Americas, USENIX, 2023. https://www.usenix.org/conference/srecon23americas/presentation/nash [27] Eddie Redick. "Human Factors in the Age of AI Ops: Re-Engineering Trust Between Humans and Machines." SREcon26 Americas, USENIX, 2026. https://www.usenix.org/conference/srecon26americas/presentation/redick [28] Matt Davis. "Human Observability of Incident Response." SREcon23 Americas, USENIX, 2023. https://www.usenix.org/conference/srecon23americas/presentation/davis [29] Stevan Malesevic, Christopher Heiser. "AI in SRE: Where and How Google Is Deploying Agentic AI to Improve Operations." Google Cloud Blog, 2026. https://cloud.google.com/blog/products/devops-sre/how-google-sre-is-using-agentic-ai-to-improve-operations [30] Stepan Davidovic. "Incident Metrics in SRE: Critically Evaluating MTTR and Friends." O'Reilly / Google SRE, 2021. https://static.googleusercontent.com/media/sre.google/ja//static/pdf/IncidentMeticsInSre.pdf [31] Narimichi Takamura. "インシデントキーメトリクスによるインシデント対応の改善." SRE Kaigi 2025, 2025. https://speakerdeck.com/nari_ex/improving-incident-response-using-incident-key-metrics [32] Sue Lueder. "What Brought Us Down? Outage Trend Analysis at Google." SREcon15, USENIX, 2015. https://www.usenix.org/conference/srecon15/program/presentation/lueder