システム障害のポストモーテム完全ガイド2026｜非難なき振り返り・障害報告書の読み方【テンプレ付】

「障害報告書は受け取ったが、同じトラブルがまた起きた」「ベンダーから届いた報告書が薄くて、本当に再発しないのか判断できない」——システムを外部委託している中小企業の経営者・情シスから、こうした声を数多く聞きます。障害そのものより厄介なのは、振り返りが形だけで終わり、同じ穴に二度落ちることです。

本記事は、GoogleのSRE(Site Reliability Engineering)が体系化したポストモーテム(振り返り)の考え方を土台に、(1)自社で障害を振り返って書く側、(2)ベンダーから届いた障害報告書を読んで良し悪しを判断する側、両方の立場で使える実務ガイドとしてまとめました。テンプレート、根本原因分析の手順、再発防止が絵に描いた餅になる失敗パターン、そして発注者が障害報告書のどこを見抜くべきかまで、経営判断に使える形で解説します。

---

この記事の結論(先に要点)

• ポストモーテム = 犯人探しをしない「学習のための振り返り」。担当者を責めるのではなく、システムとプロセスの弱点を直すことに集中する(Google SRE Book 第15章の定義)。
• 障害報告書とポストモーテムは別物。障害報告書は顧客・経営・監督官庁への「説明責任」の文書、ポストモーテムは社内が二度と繰り返さないための「学習」の文書。読者も目的も違うので、混同すると両方が中途半端になる。
• 良い振り返りは3層で原因を掘る。技術(なぜ壊れたか)・プロセス(なぜ検知/防止できなかったか)・組織(なぜその不備が放置されたか)。技術原因で止めると必ず再発する。
• 発注者(経営者)にとっての本丸は「ベンダーの障害報告書を見抜く力」。表面的な謝罪と暫定対応だけで根本原因と再発防止が書かれていない報告書は、次の障害を予約しているに等しい。読むべき7項目は本文の「障害報告書の読み方チェックリスト」に。
• 再発防止策は「担当者・期限・完了条件」がなければ実行されない。アクションアイテムの実行率を四半期で可視化する仕組みまで作って、はじめて振り返りが投資対効果を生む。

---

この記事を読むべき人

• システム開発・運用をベンダーに委託していて、障害報告書が届いても妥当性を判断できない経営者・事業責任者
• ひとり情シス・兼任情シスで、社内に振り返りの型がなく、障害のたびに場当たり対応になっている担当者
• 過去に障害が再発した経験があり、**「今度こそ再発防止を仕組みにしたい」**と考えている運用責任者
• ベンダー選定・契約更新を控えていて、契約に障害報告義務やSLAをどう入れるかを整理したい発注担当
• PoC・内製・外注を問わず、障害対応の体制を経営として設計したい意思決定者

技術者向けのSRE解説記事は世の中に多くありますが、本記事は「振り返りを受け取り、判断し、ベンダーに説明責任を求める側」の視点を主軸に置いています。ここが、エンジニア向けの一般的なポストモーテム記事との最大の違いです。

---

ポストモーテムとは何か——障害報告書との決定的な違い

ポストモーテム(Postmortem/事後検証)とは、システム障害やインシデントが収束したあとに行う構造化された振り返りプロセスです。医療の「病理解剖」に語源を持ち、IT運用の世界ではGoogleのSREチームが体系化したことで広く知られるようになりました。

多くの企業がつまずくのは、「障害報告書を書く」ことと「ポストモーテムをやる」ことを同じだと思っている点です。この2つは目的も読者も違います。混同すると、顧客説明用の文書に技術的な学習を詰め込みすぎて読み手に伝わらず、逆に社内学習用の文書を対外的な言い訳に流用して本音の分析ができなくなります。

実務では、すべての障害に両方を作る必要はありません。顧客影響や金銭影響が出た障害は障害報告書が必須、深い学びと本質的な再発防止が見込める障害はポストモーテムを重ねる、という使い分けが現実的です。小さな障害まで両方フル装備で回すと、書くこと自体が目的化して形骸化します。

なぜ「非難なき(Blameless)」が経営問題なのか

Google SRE Bookは、ポストモーテムが真に非難なきものであるためには「インシデントに関わった全員が善意で、その時点で持っていた情報をもとに正しいことをしようとした、と前提を置く」ことが必要だと述べています(第15章)。

これは単なる「優しさ」の話ではなく、情報の質を守るための合理的な設計です。障害の原因を個人の過失に帰す文化では、次から現場は障害を隠し、報告を遅らせ、都合の悪い事実を語らなくなります。そうなると、本当の根本原因——たとえば「そもそも一人しか手順を知らない体制だった」「テスト時間を確保できないスケジュールだった」——にたどり着けません。表面上は「担当者の確認漏れ」で片付き、翌月に別の担当者が同じ穴に落ちます。

経営者にとって非難なき文化は、「悪い情報が早く正確に上がってくる組織」への投資です。ベンダーに対しても同じで、報告書に犯人を書かせるより、契約と運用のどこに構造的な弱点があったかを一緒に洗い出せる関係のほうが、長期的な安定運用につながります。

---

ポストモーテム実施の5ステップ

振り返りは思いつきでやると必ず抜け漏れます。以下の順番を固定すると、誰がファシリテートしても一定の品質が出ます。

1. 事前準備——目的(何のための振り返りか)、参加者、必要なログ・アラート・チャット履歴を集める。対象にする障害の重大度も先に決める。
2. タイムライン作成——検知から復旧までの事実を時系列で並べる。この段階では原因分析や評価を一切書かず、「いつ・何が起きた・誰が何をした」の事実だけに徹する。
3. 根本原因分析——タイムラインを土台に、5 Whysで技術・プロセス・組織の3層まで掘る。
4. 再発防止策(アクションアイテム)の設定——原因ごとに、担当者・期限・完了条件つきの具体策を置く。「気をつける」は禁止。
5. 文書化と共有——ナレッジベースに登録し、関係者へ共有。アクションの進捗を追う仕組みまでセットで作る。

48時間ルールを推奨します。記憶が新鮮なうちにドラフトを作らないと、タイムラインの精度が落ちます。ただしドラフト段階では事実整理に集中し、原因分析はレビューミーティングで議論するのが実務的です。

---

そのまま使えるポストモーテム・テンプレート

以下はGoogle SRE Bookの例(Shakespeare Sonnet++ Postmortem, incident #465)の構成を、日本の中小企業でも書きやすい粒度に調整したものです。社内Wiki・Confluence・Notion・Backlogなどに雛形として登録して使ってください。

基本情報(メタデータ)

サマリー(3行で)

• 何が起きたか、誰にどの程度の影響が出たか、最終的にどう収束したかを非エンジニアが読んで分かる言葉で3行。

タイムライン

根本原因(3層で記載)

• 直接原因(技術): 何が壊れたのか
• 検知/防止できなかった原因(プロセス): 監視・テスト・レビュー・手順のどこが機能しなかったのか
• 放置されていた原因(組織): なぜその不備が事前に潰されていなかったのか

検知・トリガー・対応

• トリガー: 障害を引き起こした直接の引き金(例: 高負荷、設定変更、リリース)
• 検知: どうやって気づいたか(監視アラート/顧客連絡/たまたま)——「顧客に言われて初めて気づいた」なら監視の穴が重大原因
• 対応: 応急処置と恒久対応の内容

再発防止策(アクションアイテム)

教訓(Lessons Learned)

• うまくいったこと: 継続すべき対応・仕組み
• うまくいかなかったこと: 具体的な改善点
• 幸運だったこと: たまたま助かった点(次は運に頼れないので要対策)

「幸運だったこと」を必ず1項目書くのがコツです。運で助かった障害は、次に同じ運がなければ大事故になる——ここを言語化できるチームは強い。

---

根本原因分析——「5 Whys」を技術で止めない

再発防止の質は、根本原因をどこまで掘れたかで決まります。よく使われるのが**5 Whys(なぜなぜ分析)**ですが、多くの現場は「なぜ」を技術の層で止めてしまい、そこが最大の落とし穴です。

以下は、設定ミスで本番DBに接続できず障害になった例を、3層まで掘った具体例です。

1. なぜ障害が起きたか? → アプリが本番DBに接続できなかった(直接原因・技術)
2. なぜ接続できなかったか? → デプロイ時に環境変数の接続情報が欠落していた(技術)
3. なぜ欠落に気づけなかったか? → デプロイ後の疎通確認(ヘルスチェック)が自動化されていなかった(プロセス)
4. なぜ自動化されていなかったか? → 手順書はあったが手動運用で、担当者依存だった(プロセス/組織)
5. なぜ担当者依存が放置されたか? → 運用改善の工数が事業計画に組まれておらず、後回しにされ続けた(組織)

技術の層(1〜2)で止めれば「環境変数を確認する」で終わり、次の担当者が同じミスをします。3層目(組織)まで掘って「運用改善の工数を計画に組む」まで到達して、はじめて再発防止になります。経営者が振り返りに関与すべきなのは、まさにこの組織層です。技術者だけでは「予算をつける」「体制を変える」という結論は出せません。

なお、5 Whysは「なぜを5回」に固執する必要はありません。3層(技術・プロセス・組織)に到達したかどうかが本質で、3回で組織原因に届くこともあれば7回かかることもあります。

---

タイムライン整理のコツ——ここで多くの振り返りが崩れる

タイムラインは「事実だけを、解釈を混ぜずに」書くのが鉄則です。ところが実際の振り返りでは、ここに感情や評価が混入して、後の分析が歪みます。

• 悪い例: 「無理なスケジュールのせいで確認が漏れた」→ 評価が入っている
• 良い例: 「11:20 リリース実施。リリース前のテスト時間は確保されていなかった」→ 事実のみ

事実と解釈を分けると、「テスト時間を確保できない計画だった」という組織原因が浮かび上がり、犯人探しではなく仕組みの議論に移れます。タイムラインを作るときは、ログ・アラート・チャット履歴・電話メモなど一次記録から復元し、記憶だけで書かないこと。記憶は無意識に自分に有利な順序へ並べ替えます。

もう一つ重要なのが**「検知の遅れ」を必ずタイムラインに刻むことです。「発生10:00・検知11:30(顧客連絡)・復旧12:00」なら、実は復旧の速さより90分気づけなかった監視の穴**のほうが重い問題です。ここを見落とすと、次も顧客に指摘されるまで気づけません。

---

GXOが見てきた「再発防止が絵に描いた餅になる」失敗パターン

振り返りの形は整っているのに再発が止まらない組織には、共通の失敗パターンがあります。テンプレートを埋めることより、これらを避けることのほうが重要です。

失敗1: アクションアイテムに「担当者・期限・完了条件」がない

「監視を強化する」「レビューを徹底する」——主語も締切も完了の定義もない施策は、100%実行されません。**「誰が・いつまでに・何が満たされたら完了か」**を必ず書き、タスク管理ツール(Jira/Backlog/Asana等)の課題に紐づけます。ポストモーテムのアクションが宙に浮くのは、日々の業務タスクと分断されているからです。

失敗2: 技術原因で分析を止めている

前述のとおり、組織層まで掘らないと同じ穴に落ちます。「確認漏れ」「うっかり」で終わっている報告書は、根本原因に到達していないサインです。

失敗3: 振り返りが「個人反省会」になっている

非難なき前提が崩れると、現場は本音を出さなくなり、分析の材料が痩せます。ミーティング冒頭で「これは責任追及の場ではない」と明言し、ファシリテーターを事前に決めておきます。

失敗4: アクションの実行率を誰も追っていない

作った再発防止策の何%が実際に完了したかを、四半期で可視化していますか。完了率が低い場合、問題は個々の障害ではなくプロセスそのものです。実行率という一つの指標を経営会議に載せるだけで、振り返りの実効性は大きく変わります。

失敗5: 重大度に関わらず全部フル装備でやる

小さな障害まで詳細ポストモーテムを課すと、書くことが目的化して形骸化します。重大度で運用を分け(Criticalは詳細+レビュー会、Minorは簡易記録)、リソースを重い障害に集中させます。

失敗6: 一度きりで、ナレッジが横に広がらない

同種の障害は別チーム・別システムでも起きます。振り返りをナレッジベースに蓄積し、定期的に「今月のポストモーテム」として共有する仕組みがないと、組織としては学習しません。

---

【発注者の本丸】ベンダーから届いた障害報告書の読み方チェックリスト

システムを外部委託している経営者・情シスにとって、最も実務的な問いは「自分で振り返りをどう書くか」ではなく「ベンダーから届いた障害報告書をどう見抜くか」です。ここは一般的なSRE解説記事が踏み込まない領域なので、詳しく扱います。

薄い障害報告書には共通の特徴があります。謝罪と暫定対応は丁寧に書かれているのに、根本原因と恒久的な再発防止が曖昧——これは「次の障害を予約している報告書」です。以下の7項目で受け取った報告書をチェックしてください。

• タイムラインに検知時刻があり、検知の遅れが明示されているか(顧客に言われて気づいた場合、そう書いてあるか)
• 根本原因が技術だけでなくプロセス/組織まで掘られているか(「確認漏れ」で止まっていないか)
• 暫定対応(応急処置)と恒久対応(再発防止)が区別されているか(「再起動しました」だけで終わっていないか)
• 再発防止策に担当者・期限・完了条件があるか(「今後注意します」は再発防止ではない)
• 同種障害の横展開が検討されているか(他システム・他機能で同じことが起きないか)
• 影響範囲が具体的な数字で書かれているか(影響ユーザー数・停止時間・データ影響)
• 報告のスピードと透明性は妥当か(発生を隠していなかったか、事実を後出しにしていないか)

チェックが埋まらない報告書が届いたら、遠慮なく追加質問を返してください。良いベンダーは追加質問を歓迎します。逆に「詳細は社内情報なので開示できない」と壁を作るベンダーは、根本原因の分析力そのものに不安が残ります。

発注者からベンダーへの追加質問リスト(コピペ可)

• この障害と同じ原因で影響を受ける可能性のある他の機能・システムはありませんか
• 応急処置ではなく、恒久的に再発を防ぐ対応の具体内容と完了予定日を教えてください
• 今回検知が遅れた/顧客連絡で気づいたのであれば、監視をどう改善しますか
• 再発防止策の進捗を、いつ・どの形で報告してもらえますか
• 今回の障害は、**契約上のSLA(稼働率・復旧目標)**に照らしてどう扱われますか

---

契約・発注前チェックリスト——「障害の説明責任」を先に取り決める

障害報告書の質は、障害が起きてから交渉するものではなく、契約と発注の段階で先に取り決めておくものです。契約書に何も書かれていないと、いざ障害が起きたときに「報告義務があるのか」「どこまで原因を開示させられるのか」が曖昧になり、泣き寝入りにつながります。発注・契約更新の前に、以下を確認してください。

これらは、要件定義やRFPの段階で明文化しておくのが理想です。契約前の論点整理が甘いまま発注すると、手戻りと追加費用、そして障害時の説明責任の空白を招きます。要件定義やRFPの粒度に不安がある場合は、要件定義とRFP設計を含むDXシステム開発の進め方を早い段階で整理しておくと、契約後のトラブルを大きく減らせます。

---

第三者検証——ベンダー報告を鵜呑みにしないという選択肢

障害報告書を受け取る側が同じベンダーに依存している場合、「その原因分析が本当に正しいのか」を自社だけで判断するのは困難です。特に、障害の原因がベンダー自身の設計・運用にある場合、報告書は無意識にベンダーに有利な方向へ書かれがちです。犯人探しをしないという非難なき文化は社内では正しくても、対外的な説明責任の場面では、発注者が事実を検証する視点を持っておく必要があります。

第三者検証が有効なのは、次のような場面です。

• 同じ原因の障害が短期間に複数回起きている(報告書の再発防止が機能していない疑い)
• 障害報告書の根本原因が技術層で止まっており、腑に落ちない
• ベンダー変更や契約更新を控えていて、現行運用の妥当性を客観評価したい
• セキュリティインシデントが絡み、原因究明と証拠保全に専門性が必要

セキュリティ由来の障害や不正アクセスが疑われる場合は、平時の運用改善とは別に、インシデント対応・原因究明の専門支援のような専門体制が必要になります。障害の性質(単なる運用障害か、セキュリティ事案か)を早期に見極めることが、その後の対応方針を分けます。

---

中小企業・ひとり情シスのための「最小ポストモーテム」

「SREのような体制はうちにはない」——そのとおりで、中小企業に大企業のフルプロセスは不要です。ひとり情シスや兼任情シスでも回せる最小構成を用意しました。まずはこの3つだけで十分です。

1. 1ページのタイムライン——発生・検知・復旧の時刻と、その間に何をしたかを事実で箇条書き。
2. 3層の原因メモ——技術1行・プロセス1行・組織1行。組織層(体制・予算・優先順位)を必ず1行書く。
3. 1つのアクション——今回から確実に潰す再発防止策を1つだけ、担当者と期限つきで。欲張らない。

大事なのは網羅性より継続です。障害のたびに1ページ書いて溜めるだけで、半年後には自社の弱点マップができます。ツールもConfluenceやNotionでなくてよく、共有ドキュメント1本で始められます。内製で回すのが難しい、あるいは体制そのものを設計し直したい場合は、DXシステム開発の進め方と体制設計の相談から現状整理を始めるのが近道です。AI・自動化の導入可否を含めて投資判断を整理したい場合は、AI導入可否のアセスメントと見積もりで要件を先に固めておくと、体制と予算の議論がぶれません。

---

GXOに相談すべきタイミング

以下のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに第三者へ相談したほうが安全です。

• ベンダーから届いた障害報告書が薄く、再発防止が本当に機能するのか判断できない
• 同じ原因の障害が繰り返し起きているのに、根本原因が技術層で止まっている
• 契約更新やベンダー変更を控えていて、SLA・障害報告義務・RCAをどう契約に入れるか整理したい
• ひとり情シス・兼任情シスで、障害対応と再発防止の型を社内に作りたいが着手できていない
• 経営会議で、障害の費用対効果・リスク・再発防止ロードマップを説明する必要がある

GXOが重視するのは、話題性ではなく「自社の業務・データ・権限・予算・運用責任にどう影響するか」です。障害の振り返りにおいても、担当者だけで判断を閉じず、経営・現場・情シス・外部パートナーの役割を早い段階で分けることを推奨します。

---

よくある質問(FAQ)

障害報告書とポストモーテムは、両方作らないといけませんか?

すべての障害に両方は不要です。顧客影響・金銭影響が出た障害は説明責任のための障害報告書が必須、深い学びが見込める障害はポストモーテム(社内学習)を重ねる、という使い分けが現実的です。小さな障害まで両方フル装備にすると形骸化します。

5 Whysは必ず5回やるべきですか?

回数は本質ではありません。技術・プロセス・組織の3層に到達したかが重要で、3回で組織原因に届くこともあれば7回かかることもあります。「確認漏れ」など技術・人為の層で止まっていたら、まだ掘り足りないサインです。

ベンダーの障害報告書が薄いと感じたら、どうすればいいですか?

本文の「障害報告書の読み方チェックリスト」7項目で確認し、埋まらない項目は追加質問で返してください。良いベンダーは追加質問を歓迎します。開示を渋る場合は、分析力や透明性そのものに注意が必要です。契約にRCA(根本原因報告)の提出義務があるかも確認しましょう。

犯人探しをしないと、責任の所在が曖昧になりませんか?

非難なき文化は「責任を問わない」ことではなく、「個人の処罰より、システムとプロセスの改善を優先する」考え方です。個人を責めると悪い情報が隠れ、かえって再発します。責任は「誰のミスか」ではなく「どの仕組みが人にミスをさせたか」で捉え直します。

中小企業でも本格的な振り返りは必要ですか?

フルプロセスは不要ですが、最小構成(1ページのタイムライン+3層の原因メモ+1つのアクション)は規模を問わず有効です。継続して溜めることで、自社の弱点が見える化されます。

GXOにはどの段階で相談できますか?

障害が起きた直後の原因究明から、平時の体制設計、契約・SLAの見直し、ベンダー選定まで、どの段階でも相談できます。要件定義・RFP設計・第三者検証を入口に、実装や運用改善まで整理できます。

---

公式・一次情報(最終確認: 2026年7月16日)

• Google SRE Book 第15章 Postmortem Culture: Learning from Failure — https://sre.google/sre-book/postmortem-culture/
• Google SRE Book 付録 Example Postmortem(テンプレート例) — https://sre.google/sre-book/example-postmortem/
• NIST SP 800-61 Computer Security Incident Handling Guide(インシデント対応の公式ガイド) — https://www.nist.gov/privacy-framework/nist-sp-800-61
• IPA 情報処理推進機構(情報セキュリティ・障害関連の公的情報) — https://www.ipa.go.jp/

上記は社内稟議やベンダーとの交渉の根拠として使えます。仕様・価格・法令・脆弱性情報は改定されるため、契約・対応の直前にリンク先の最新版と適用条件を再確認してください。本記事のうちGoogle SREの引用は同社公開書籍(一次情報)に基づき、統計的な再発率などの数値は出典が確認できるもののみを扱い、未確認の数値は記載していません。

---

関連記事

• セキュリティインシデント対応フロー — 72時間初動チェックリスト
• 中小企業のセキュリティ対策費用 — 予算計画ガイド