導入事例2026/3/1713分で読めます

SRE/IT運用のポストモーテム実践ガイド｜障害から学ぶ組織を作る

ポストモーテムSRE障害報告書なぜなぜ分析インシデント管理Blameless Culture根本原因分析

システム障害が発生したとき、チームが最初に問うべき問いは「誰が悪いのか」ではありません。「何が、なぜ起きたのか」です。犯人を探しても同じ障害は繰り返されます。しかし、障害が起きた仕組みやプロセスの問題を正確に掘り下げれば、組織は確実に強くなります。SRE（Site Reliability Engineering）の世界で標準的な実践となっているポストモーテムは、その問いに体系的に答えるための手法です。本記事では、ポストモーテムの書き方から根本原因分析のフレームワーク、Blameless Cultureの醸成、ツールを使った効率化まで、SRE/IT運用エンジニアが現場で即活用できる形で解説します。

1. ポストモーテムとは：Googleが広めた「非難なき」障害振り返り

ポストモーテム（postmortem）は、もともと医学用語で「死後の解剖」を意味します。IT・SREの文脈では、インシデント収束後に実施する事後検証プロセスのことを指します。Googleが自社のSRE文化を体系化した書籍『Site Reliability Engineering』（通称：SREブック）の中でこの概念を広め、現在では世界中のIT組織が採用しています。

障害報告書とポストモーテムの違い

従来の「障害報告書」は「何が起きたかを記録し、対外的に報告する」ことを主目的とした文書です。一方でポストモーテムは、組織が障害から学ぶための内部プロセスです。この目的の違いが、記述内容と組織への効果に大きな差を生みます。

比較項目	障害報告書	ポストモーテム
主な目的	事実の記録・対外報告	組織学習・再発防止
主な読者	経営層・顧客	SRE/開発チーム
焦点	何が起きたか	なぜ起きたか
主語	特定の担当者・システム	システム・プロセス
文化的前提	責任の所在を明確にする	誰も責めない（Blameless）

なぜ「非難なし」が重要なのか

Googleのエンジニアリング文化では「複雑なシステムで働くエンジニアは、その時点で入手できた情報をもとに最善の判断をした」という前提を置きます。誰かの行動を責める文化では、エンジニアは障害の詳細を報告することを恐れ、問題が隠蔽されがちです。Blameless（非難なき）なポストモーテムは、心理的安全性を確保することで、障害の全貌が正確に記録される環境を作ります。

これは医療・航空業界が長年実践してきたアプローチでもあります。ミスを報告しやすい文化が、より大きな事故を防ぐ——この知見をソフトウェア開発に持ち込んだのがSREのポストモーテム文化です。

2. ポストモーテムの書き方：5要素で構造化する

ポストモーテムの品質は、テンプレートの構造によって大きく左右されます。以下の5要素を網羅することで、分析の抜け漏れを防ぎ、アクションにつながる文書を作ることができます。

要素1：タイムライン

インシデントの全経緯を時系列で記録します。「いつ、何が、誰によって（または何によって）起きたか」を客観的な事実として並べます。

記述のコツは主語を「システム」や「プロセス」にすることです。「Aさんがコマンドを実行した」ではなく「14:32にデプロイパイプラインが本番環境へのリリースを実行した」という表現が適切です。個人を主語にすると、無意識に責任追及の文脈を生み出してしまいます。

タイムラインに含めるべき主なイベントは以下のとおりです。

障害の発生推定時刻（ログベースで特定）
最初のアラート発火時刻（TTD：Time to Detect）
オンコールエンジニアへの通知時刻（TTR：Time to Respond）
各対応ステップとその結果
暫定復旧（止血）の完了時刻
完全復旧の確認時刻（MTTR：Mean Time to Recovery）
ユーザーへの影響開始・終了時刻

要素2：影響範囲

障害がどの範囲に、どの程度の影響を与えたかを定量・定性の両面で記録します。

定量的な影響例：

影響を受けたユーザー数・リクエスト数
エラーレートの最大値（例：エラーレート0% → 87%）
影響継続時間（例：45分間）
SLO違反の有無（エラーバジェットの消費量）

定性的な影響例：

影響を受けた機能・サービス（例：注文処理が停止）
地理的・コンポーネント的な影響範囲
ビジネスへの影響（売上損失の推定、CSへの問い合わせ件数など）

影響範囲を正確に記録することで、インシデントの深刻度を客観的に評価でき、対策への投資判断の根拠にもなります。

要素3：根本原因

「直接的な原因」と「根本的な原因」を区別して記述します。

直接原因とは障害を引き起こした直接のトリガーです（例：設定ファイルの誤記）。根本原因とは、その直接原因がなぜ存在したかを掘り下げた結果として特定される、組織的・プロセス的な問題です（例：デプロイ前の設定値バリデーションが自動化されていなかった）。

根本原因の特定には次のセクションで解説する「なぜなぜ分析」が効果的です。

要素4：対策（アクションアイテム）

根本原因に直接対処する具体的な改善策を列挙します。重要なのは**「仕組みで防ぐ」対策を設計すること**です。「次回は注意する」「ダブルチェックを徹底する」という対策は、疲労やプレッシャーのかかる状況では機能しません。

アクションアイテムには必ず以下を含めます。

項目	内容
アクション内容	何をするか（具体的な実施内容）
担当チーム/担当者	誰が責任を持つか
優先度	High / Medium / Low
期限	いつまでに完了するか
ステータス	未着手 / 対応中 / 完了

要素5：教訓（Lessons Learned）

このインシデントを通じてチームが学んだことを記録します。失敗だけでなく、「うまくいったこと」も必ず含めます。アラートが適切に機能した、オンコールの連絡が迅速だった、ランブックが役に立った——こうした成功事例を記録することで、チームのモチベーションを維持しながら、再現すべきプラクティスも明確になります。

3. なぜなぜ分析の適用：SRE的根本原因分析のフレームワーク

ポストモーテムの核心は根本原因の特定です。表面的な原因で分析を止めると、アクションアイテムが「技術的修正」だけで終わり、同じ問題が繰り返されます。SREの現場では、「5 Whys（なぜなぜ分析）」を根本原因特定のフレームワークとして活用します。

なぜなぜ分析の実践例

以下は、本番データベースのコネクション枯渇障害を例にした分析です。

インシデント：深夜バッチ処理によるDBコネクション枯渇、注文処理45分停止

なぜ1：なぜサービスが停止したのか？ → DBへのコネクションが枯渇し、新規接続を確立できなくなったため
なぜ2：なぜコネクションが枯渇したのか？ → 深夜バッチ処理がコネクションを長時間占有し、コネクションプールが上限に達したため
なぜ3：なぜバッチ処理がコネクションを長時間占有したのか？ → 対象データ件数の増加により、バッチの実行時間が想定の3倍以上に膨らんでいたため
なぜ4：なぜ実行時間の増加が把握されていなかったのか？ → バッチ処理の実行時間をメトリクスとして収集・監視する仕組みがなかったため
なぜ5：なぜそのような監視の仕組みがなかったのか？ → バッチ処理の実装時に非機能要件（実行時間上限・監視項目）を設計に含める文化とチェックリストがなかったため

根本原因：非機能要件をシステム設計の段階で定義するプロセスが組織として存在しなかった。

なぜなぜ分析でよくある落とし穴

「人のせい」で止まるケース

「担当者がチェックを怠った」「オペレーターがミスをした」といった答えが出た時点で分析を止めるのは、最も多い失敗パターンです。SRE的な問いはその先にあります。「なぜチェックを怠らざるを得ない状況だったのか」「なぜミスが表面化しない仕組みになっていたのか」と続けることで、仕組みの問題に辿り着きます。

単一の根本原因を探しすぎるケース

複雑なシステムの障害は、多くの場合「複数の要因が重なった結果」として発生します。1つの根本原因を特定してアクションアイテムにするだけでなく、「なぜ1」「なぜ2」の各レベルにも改善余地があれば、それぞれにアクションを設定することが有効です。

なぜなぜ分析をAIで体験してみよう

ここまでの解説を踏まえて、AIによるなぜなぜ分析を体験してみましょう。事象を入力するだけで、AIが自動的に原因を深掘りします。

なぜなぜ分析 AI体験ツール

事象を入力するだけで、AIが原因を自動分析

業界別のサンプル事象を選ぶか、自由に入力してください。

または

4. ポストモーテム文化の醸成：心理的安全性とBlameless Culture

優れたテンプレートとプロセスを用意しても、チームに「正直に書くと怒られる」という空気がある限り、ポストモーテムは形式的な儀式になります。文化の醸成こそが、ポストモーテムを機能させる前提条件です。

エンジニアリングリーダーの役割

Google SREの知見では、Blameless Cultureはマネジメント層の行動によって形成されると明言しています。シニアエンジニアや管理職がポストモーテムのレビューに積極的に参加し、「このシステム設計の問題は私が気づくべきでした」と自ら発言する姿勢が、チーム全体の文化を作ります。

反対に、ポストモーテムの議論の中で特定の個人への批判的な発言が出たとき、それを即座に「システムの問題として捉え直す」ファシリテーションができるかどうかが、文化定着の分岐点になります。

ポストモーテムミーティングのファシリテーション

効果的なポストモーテムミーティングには、中立的なファシリテーターが不可欠です。直接インシデントに関わったエンジニアが自らファシリテーターを兼務すると、議論が主観的になりやすいため避けることが望ましいです。

ミーティングは以下の構成で進めます。

タイムラインの共有（事実の確認のみ、批判なし）
影響範囲の確認（定量データの確認）
根本原因の深掘り（なぜなぜ分析の実施）
アクションアイテムの設定（担当・期限を明確に）
うまくいったことの共有（ポジティブな振り返り）

「ポストモーテムを書いた人をたたえる」文化

一部の先進的なSRE組織では、ポストモーテムを詳細に書いたエンジニアを公に称えるプラクティスを取り入れています。障害の詳細を正直に記録することは、組織全体への貢献であるという認識を広めることが、文化定着を加速します。

Blameless Cultureが根付いた組織では、障害が発生した際に「早くポストモーテムを書きたい」という空気がチームに生まれます。障害を隠したいのではなく、学びを組織に蓄積したいという動機が、チームを内発的に動かすようになります。

5. ツールでの管理：インシデント管理→自動タイムライン→ナレッジ化

ポストモーテムをスプレッドシートやWikiだけで運用していると、規模が大きくなるにつれていくつかの典型的な問題が顕在化します。ツールを活用することで、これらの課題を構造的に解決できます。

スプレッドシート運用の限界

分析の深さにばらつきが生じる：担当者によってなぜなぜの深さが異なり、「なぜ2」で分析が止まるケースが散見されます。

過去インシデントとの接続不足：同じ根本原因を持つ障害が繰り返されても、それを検索・参照する仕組みがなければ気づけません。前回のポストモーテムに記録された同種の問題が参照されずに、同じアクションアイテムが再び設定される——これは多くのSREチームが経験するパターンです。

アクションアイテムの追跡漏れ：ポストモーテムで設定した改善策が日常業務の中で優先度を下げられ、実施されないまま終わることがあります。

WhyTrace Plusが提供するSREワークフロー

WhyTrace Plus は、SREチームのポストモーテムと根本原因分析を支援するAIプラットフォームです。

SREフレームワークの構造的サポート：インシデント登録から自動的にポストモーテムのテンプレートが生成され、タイムライン・影響範囲・根本原因・アクションアイテムの各セクションが標準化されます。チームに新しいメンバーが加わっても、一定水準の分析品質を維持できます。

AI 5Why（AI支援のなぜなぜ分析）：根本原因の掘り下げをAIが支援します。「なぜ1」を入力すると、次の「なぜ」への問いをAIが提案し、分析が「人のせい」で止まることを防ぎます。ベテランSREの思考プロセスをAIが補完することで、経験の浅いエンジニアでも深い分析が可能になります。

ナレッジベース（RAGチャット）：蓄積されたポストモーテムをRAG（検索拡張生成）技術でナレッジ化します。新しいインシデントが発生した際に「過去に類似した障害はあったか」「そのときの根本原因とアクションは何だったか」をチャット形式で即座に参照できます。同じ根本原因による障害の繰り返しを防ぐ、実用的なナレッジマネジメントを実現します。

SREチームが月に複数件のインシデントに対応するようになった段階で、ツールによる効率化を検討するタイミングです。ツールに任せることで、チームは「テンプレートの記入」ではなく「分析の質を上げること」に集中できるようになります。

まとめ

ポストモーテムは、システム障害を「組織の学習機会」に変えるための体系的なプロセスです。本記事で解説した内容を整理します。

ポストモーテムの本質は、「誰が悪いか」ではなく「何がなぜ起きたか」を探ることにあります。Googleが広めたBlameless（非難なき）アプローチは、心理的安全性を確保し、障害の全貌が正確に記録される環境を作ります。

書き方の基本は5要素（タイムライン・影響範囲・根本原因・対策・教訓）の構造化です。特に根本原因の記述では、なぜなぜ分析を活用して「技術的修正」だけで終わらない深い分析を実施することが重要です。

文化の醸成こそが最も難しく、最も重要な要素です。エンジニアリングリーダーが自らBlamelessな姿勢を示し、ポストモーテムを詳細に書くことを称えるプラクティスが、文化を定着させます。

ツールの活用は、分析の一貫性と過去ナレッジの活用を組織として担保するための手段です。スプレッドシートで始めても構いませんが、チームとインシデントの規模が大きくなるにつれて、専用ツールへの移行が分析品質とチームの生産性を大きく向上させます。

障害が発生するたびに「また同じことが起きた」と感じているとすれば、それはポストモーテムの文化とプロセスが機能していないサインです。次のインシデントから、本記事で紹介した5要素の構造と、なぜなぜ分析のフレームワークを試してみてください。その積み重ねが、システムの信頼性と組織の対応力を着実に高めていきます。

よくある質問（FAQ）

Q1. ポストモーテムはどのタイミングで実施すればよいですか？

インシデント収束後、できるだけ早く（通常は24〜72時間以内）実施することが推奨されます。記憶が鮮明なうちに詳細なタイムラインを記録することが、分析の精度を高めます。軽微なインシデントは週次のレビューにまとめて組み込む運用も有効です。

Q2. どの程度の規模のインシデントにポストモーテムが必要ですか？

Google SREの基準では「ユーザーへの影響があったすべてのインシデント」が対象とされますが、チームの規模や運用状況に合わせて閾値を設定して構いません。最初はSLO違反や一定時間以上の障害を基準に始め、文化が定着してきた段階で対象を広げる方法が現実的です。

Q3. ポストモーテムのアクションアイテムが実施されない問題をどう解決しますか？

アクションアイテムをJiraなどのタスク管理ツールに即座に登録し、スプリントに組み込むことが有効です。ポストモーテム文書の中に「アクションアイテムの追跡」セクションを設け、次回のポストモーテムミーティングで前回の進捗を確認するルールを設けることも有効です。

Q4. 小規模なSREチームでもポストモーテム文化は作れますか？

2〜3人の小規模チームでも実施できます。むしろ小規模チームほど、フレームワークを使って分析の抜け漏れを防ぐことが重要です。形式を簡略化したライトポストモーテム（タイムライン・根本原因・アクションのみ）から始めて、徐々に深掘りする習慣を作ることをお勧めします。

Q5. なぜなぜ分析で「設計上の問題」に辿り着いた場合、アクションアイテムはどう設定すればよいですか？

設計上の問題は短期的修正と中長期的改善を分けて設定します。短期：該当機能の監視強化・ランブック更新。中長期：アーキテクチャレビュープロセスの整備・設計段階での非機能要件チェックリストの導入。優先度と期限を明示し、担当チームを明確にすることが実行につながります。