「障害報告書は書いたけど、同じトラブルがまた起きた」——ITシステムを運用する企業なら、一度は経験があるのではないでしょうか。IPA（情報処理推進機構）の調査によると、システム障害の約35%が過去に類似事例のあるインシデントの再発です。

原因は「振り返り」の質にあります。単なる経緯報告ではなく、根本原因を深掘りし、具体的な再発防止策まで落とし込むポストモーテム（振り返り）を実施できているかが分かれ道です。

本記事では、GoogleやMeta（旧Facebook）など世界的IT企業が実践するポストモーテムの書き方を、そのまま使えるテンプレート付きで解説します。障害対応チームの初動から、経営層への報告、再発防止策の立案まで、中小企業でも今日から実践できる内容です。

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

ポストモーテム（Postmortem）とは、システム障害やインシデント発生後に行う構造化された振り返りプロセスです。日本語では「事後検証」「振り返り」とも呼ばれます。

一般的な障害報告書が「何が起きたか」の記録にとどまるのに対し、ポストモーテムは以下の点で異なります。

  • 犯人探しをしない（Blameless）文化を前提とする
  • 根本原因（Root Cause）を技術・プロセス・組織の3軸で分析する
  • 具体的なアクションアイテムを担当者・期限付きで設定する
  • ナレッジとして組織に蓄積し、同種の障害を予防する

なぜ「犯人探しをしない」が重要なのか

障害の原因を個人の責任に帰すと、次からメンバーが障害を隠したり報告を遅らせたりするインセンティブが生まれます。Googleの SRE（Site Reliability Engineering）チームが提唱する「Blameless Postmortem」は、システムとプロセスの改善にフォーカスすることで、組織全体の信頼性を底上げする考え方です。

ポストモーテムテンプレート

以下のテンプレートをそのまま社内で活用できます。

基本情報

項目内容
インシデントIDINC-2026-XXXX
発生日時YYYY/MM/DD HH:MM
復旧日時YYYY/MM/DD HH:MM
影響範囲対象システム・ユーザー数・ビジネスインパクト
重大度Critical / Major / Minor
対応リーダー氏名
記録者氏名

タイムライン

時刻イベント対応者
HH:MMアラート検知監視チーム
HH:MM初動対応開始オンコール担当
HH:MMエスカレーションマネージャー
HH:MM暫定対応完了開発チーム
HH:MM完全復旧確認QAチーム

根本原因分析（5 Whys）

  1. なぜ障害が発生したか？ → （直接原因を記載）
  2. なぜその状態が発生したか？ → （技術的原因を記載）
  3. なぜ事前に検知できなかったか？ → （監視・テストの不備を記載）
  4. なぜその不備が放置されていたか？ → （プロセス・リソースの問題を記載）
  5. なぜプロセスが整備されていなかったか？ → （組織的原因を記載）

再発防止策（アクションアイテム）

優先度アクション担当者期限ステータス
高（即時対応が必要な施策）氏名MM/DD未着手
中（中期的な改善施策）氏名MM/DD未着手
低（長期的な改善施策）氏名MM/DD未着手

良かった点（What went well）

  • 対応で上手くいった点を記録する
  • 次回も継続すべきプラクティスを明確にする

改善すべき点（What could be improved）

  • 対応で改善が必要だった点を記録する
  • 具体的な改善方法を記載する

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

ステップ1：48時間以内にドラフトを作成する

記憶が新鮮なうちにタイムラインと事実関係を整理します。この段階では「何が起きたか」の事実記録に集中し、原因分析は次のステップで行います。

ステップ2：根本原因分析を実施する

5 Whys（なぜなぜ分析）を用いて、直接原因から組織的原因まで深掘りします。技術的な原因だけでなく、プロセスやコミュニケーションの問題にも目を向けることが重要です。

ステップ3：アクションアイテムを設定する

根本原因ごとに再発防止策を設定します。各アクションには必ず担当者と期限を設定し、曖昧な「気をつける」ではなく、具体的で検証可能な施策にします。

ステップ4：レビューミーティングを実施する

関係者を集めて30〜60分のレビューミーティングを行います。ドラフトの内容を確認し、抜け漏れがないか、アクションアイテムが現実的かを議論します。

ステップ5：ナレッジベースに登録・共有する

完成したポストモーテムをWikiやConfluenceなどのナレッジベースに登録し、チーム全体で共有します。定期的にアクションアイテムの進捗を確認する仕組みも合わせて整備しましょう。

よくある失敗パターンと対策

失敗1：犯人探しになる

対策：ミーティングの冒頭で「このポストモーテムは個人の責任を追及する場ではない」と宣言する。ファシリテーターを事前に決めておく。

失敗2：アクションアイテムが実行されない

対策：各アクションにJiraチケットやBacklogの課題を紐づけ、次のスプリントレビューで進捗を確認する仕組みにする。

失敗3：形骸化して書くだけになる

対策：四半期ごとにポストモーテムの棚卸しを行い、アクションアイテムの完了率を可視化する。完了率が低い場合はプロセス自体を見直す。

まとめ

ポストモーテムは「障害を二度と起こさない」ための最も効果的な仕組みです。ポイントを整理します。

  1. 犯人探しをしないBlameless文化が前提
  2. 48時間以内にドラフト作成、記憶が新鮮なうちに記録
  3. 5 Whysで根本原因を深掘り、技術・プロセス・組織の3軸で分析
  4. アクションアイテムは担当者・期限付きで具体的に設定
  5. ナレッジベースに蓄積し、組織の学習資産にする

テンプレートを活用して、まずは次の障害対応から実践してみてください。

GXO実務追記: AI開発・生成AI導入で発注前に確認すべきこと

この記事のテーマは、単なるトレンド紹介ではなく、業務選定、データ整備、セキュリティ、PoCから本番化までの条件を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。

まず決めるべき3つの論点

論点確認する内容未整理のまま進めた場合のリスク
目的売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか成果指標が曖昧になり、PoCや開発が終わっても投資判断できない
範囲対象部署、対象業務、対象データ、対象システムをどこまで含めるか見積もりが膨らむ、または重要な連携が後から漏れる
体制自社責任者、現場担当、ベンダー、保守運用者をどう置くか要件確認が遅れ、納期遅延や品質低下につながる

費用・期間・体制の目安

フェーズ期間目安主な成果物GXOが見るポイント
事前診断1〜2週間課題整理、現行確認、投資判断メモ目的と範囲が商談前に整理されているか
要件定義 / 設計3〜6週間要件一覧、RFP、概算見積、ロードマップ見積比較できる粒度になっているか
PoC / MVP1〜3ヶ月検証環境、効果測定、リスク評価本番化判断に必要な数値が取れるか
本番導入3〜6ヶ月本番環境、運用設計、教育、改善計画導入後の運用責任と改善サイクルがあるか

発注前チェックリスト

  • AIで置き換える業務ではなく、成果が測れる業務を選んだか
  • 参照データの所有者、更新頻度、権限、機密区分を整理したか
  • PoC成功条件を精度、時間削減、CV改善、問い合わせ削減などで数値化したか
  • プロンプトインジェクション、個人情報、ログ保存、モデル選定のルールを決めたか
  • RAG/エージェントの回答を人が監査する運用を設計したか
  • 本番化後の費用上限、API使用量、障害時フォールバックを決めたか

参考にすべき一次情報・公的情報

上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。

GXOに相談するタイミング

次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。

  • 見積もり依頼前に、要件やRFPの粒度を整えたい
  • 既存ベンダーの提案が妥当か第三者視点で確認したい
  • 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
  • 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
  • PoCや診断で終わらせず、本番導入と運用改善まで進めたい

システム障害のポストモーテム（振り返り）テンプレート｜再発防止に効く書き方【具体例付き】を自社条件で診断したい方へ

GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。

AI/RAG導入診断を相談する

※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。

関連記事

セキュリティ対策でお困りですか？

GXOは中小企業のIT課題を解決するプロフェッショナル集団です。まずは無料相談から。

無料相談はこちら →