BtoB SaaSで障害が起き、復旧した。顧客へお詫びを伝え、担当者も無事に業務へ戻った。しかし、次の障害を減らすために何を変えるべきか、社内で共有できているでしょうか。
障害対応には、利用者を守りサービスを復旧させる仕事と、後から事実を調べて学びを仕組みに戻す仕事があります。後者を体系化するのがポストモーテム（postmortem、障害事後レビュー）です。「担当者がなぜミスしたか」を追及する会議ではありません。利用者への影響、発見と復旧の経過、技術的・組織的な要因、改善策の責任と完了条件を記録する取り組みです。
この記事は、Google SREの公式資料、Google CloudのWell-Architected Framework、米国NISTの2025年版インシデント対応資料を参照します。ただしGoogleやNISTが、ここで示すBtoBマーケティング向けの説明表や日程を正式な標準として認めたという意味ではありません。
ポストモーテムとは何か――復旧作業と分けて考える
Google Cloudの「Conduct thorough postmortems」は、インシデントの内容、利用者への影響、軽減・解決のために取った行動、原因、再発を防ぐためのフォローアップを残す書面としてポストモーテムを説明しています。目的は責任追及ではなく、障害から学ぶことです。
復旧の最中に最優先されるのは、影響の把握、安全の確保、利用者への必要な通知、復旧の判断です。一方、ポストモーテムでは復旧後にログや対応記録へ戻り、実際に何が起き、なぜ障害が拡大し、どの対応が機能したかを整理します。
ただし事実の記録は復旧後にゼロから始める必要はありません。障害中も対応者が安全に残せる範囲で、時刻、判断、作業、顧客への影響を記録しておけば、後から記憶だけで経緯を再現する負担を減らせます。
Google SREが重視する「Blameless」は、責任が消えることではない
GoogleのSRE書籍や公式インシデント管理ガイドは、blameless postmortem（個人を責めない事後レビュー）を重視しています。手順が複雑だった、監視が効かなかった、変更が大きすぎた、ロールバックできなかったといった、システムと仕事の構造に目を向けます。
「誰がボタンを押したか」を一切記録しないという意味ではありません。どの操作がいつ実行され、それがなぜ合理的に見えたのか、どのような警告や制約があったのかを、事実に基づいて確認します。個人を処罰することより、似た状況でも安全に動ける仕組みを設計することが狙いです。
また、「故意の不正や深刻な規程違反まで見逃す」という意味でもありません。その判断や調査は適切な専門部門・手続きで扱い、事故学習のための場と混同しないことが大切です。
どの障害でポストモーテムを実施するか
すべての小さなアラートについて同じ長さの報告書を作れば、現場は疲弊するかもしれません。一方、利用者から見える停止やデータ損失があったのに、担当者の口頭説明だけで終わらせれば、学びが残りません。
Google Cloudのガイドは、ポストモーテムの実施条件を事前に定めるよう勧め、利用者に見える停止・劣化、データ損失、オンコール担当者の介入、復旧時間が閾値を超えた場合、監視の失敗などを候補に挙げています。
実際の運用では、顧客への影響、重要なデータへの影響、検知の遅れ、復旧の難しさを基準にして実施対象を決めます。発生件数が多い軽微な障害には簡潔なレビュー、大きな障害には複数部門のレビューを使い分ける方法もあります。
一枚の報告書に残すべき八つの項目
以下はGoogle SREの考え方を参考にした、本サイトの実務用ひな型です。技術チームだけでなく、サポートや顧客対応の担当者も読むことを想定しています。
- 1. 概要：何が起き、どの機能が、いつからいつまで影響を受けたか。
- 2. 顧客への影響：誰がどの作業をできなかったか。人数・件数の推計は確定値と分ける。
- 3. 検知：監視、顧客からの通報、社内確認のどれで発見したか。検知の遅れはあったか。
- 4. 時系列：変更、発生、検知、一次対応、影響の拡大・軽減、復旧、確認の時刻。
- 5. 要因：直接のきっかけ、検知を遅らせた条件、復旧を難しくした仕組み。
- 6. 良かった対応・難しかった対応：何が役立ち、どこで判断・手順が詰まったか。
- 7. 改善策：対応する担当者、期限、検証可能な完了条件、優先順位。
- 8. 追跡：改善が実施された証拠、残るリスク、顧客向け説明の更新日。
「原因を特定できない」場合は推測で埋めず、未確認と記録します。事実・観測された兆候・仮説を異なる欄へ分けることが重要です。
時系列は印象ではなく、確認できる証拠へ戻す
インシデントの時系列を作る際は、アプリケーションログ、クラウド監視、変更履歴、サポート記録、社内チャット、顧客への告知を突き合わせます。ただし、各システムの時刻が一致しているとは限りません。タイムゾーン、収集遅延、再送、ログ欠損などを確認します。
例えば「10:05に警告が発生」「10:12に担当者が認識」「10:20に切り戻し判断」「10:31に復旧を確認」という記録を作る場合、どの時刻が計測値で、どれが担当者の報告による推定かを明示します。時刻は説明用の架空例です。
「担当者が気づくのが遅かった」で終わらせず、アラートが適切な人に届いたか、必要な権限と手順があったか、顧客への影響を早く把握できたかを調べます。
原因を「設定ミス」だけで終わらせない
たとえば、公開前の設定変更が直接のきっかけだったとしても、その変更をレビューできる仕組みがなかった、検証環境と本番が違った、影響範囲を小さくする仕組みが不足した、といった要因が重なっているかもしれません。
Google Cloudの事後レビュー解説は、直接的な原因だけでなく根本の構造的な問題を確認し、複数のチームから情報を集めることを勧めています。
「直接のきっかけ」「影響を大きくした条件」「検知と復旧を難しくした条件」を分けると、一人の操作や単一のプログラムにすべての責任を押し付けず、改善できる点を見つけやすくなります。
一方で、原因の候補が多すぎると行動できなくなる場合があります。事実と関連性の強さを確かめ、重要な条件から調べることが必要です。
改善策を「注意する」「再教育する」で止めない
Google SREの公式ガイドは、ポストモーテムの改善項目に責任者と完了条件を設け、通常の仕事のバックログへつなげることを重視します。
- 曖昧な改善：「手順に注意する」「監視を強化する」「周知徹底する」。
- 検証できる改善：「重要APIの失敗率が閾値を超えた場合にオンコール担当者へ通知し、テスト環境で通知が届くことを確かめる」。
- 復旧を容易にする改善：「切り戻しの手順を文書化し、所要時間と権限を確認する訓練を実施する」。
- 顧客への影響を減らす改善：「特定のバッチだけを停止できる設計を検討し、影響の範囲を計測する」。
これらは説明用の例です。実際の改善内容は障害原因、優先順位、実装可能性に合わせます。改善項目を無制限に増やすより、重大な再発リスクを減らすものを確実に完了させることが重要です。
架空例――帳票出力が止まったBtoB SaaS
次は架空のサービス障害です。ある業務SaaSで、帳票出力が不安定になりました。監視ではアプリケーション全体の稼働率は正常に見えましたが、帳票作成の一部の処理だけ失敗していました。
復旧時には問題の処理を停止し、顧客へ影響範囲と次の更新予定を案内しました。事後レビューでは「サービス全体の稼働率だけを見ていた」「帳票処理の失敗を直接監視していなかった」「処理を切り離す手順が明確でなかった」という三つの条件を確認したとします。
この場合の改善候補は、帳票処理の失敗率を監視すること、異常時に影響を局所化する仕組みを検討すること、顧客向け案内を素早く出せる体制を整えることです。
これは実在の企業や成功実績ではありません。障害に対する一つの原因物語を作るのでなく、確認すべき要因を分ける説明例です。
顧客向け報告と社内ポストモーテムは同じ文書でなくてよい
社内のポストモーテムには、非公開の構成情報、ログ、個人情報、第三者との契約、未確定の原因仮説が含まれる場合があります。これをそのまま外部公開すると、顧客や関係者の安全を損なう可能性があります。
一方で「詳細は社内で調査中」という文だけでは、影響を受けた顧客は何が起き、どの程度回復したかを判断できません。顧客向けには確認済みの影響、復旧状況、必要な顧客側の対応、次の連絡時期、判明した範囲の原因と改善策を、守秘・安全上の条件を確認して説明します。
顧客への一次案内はBtoBサービス障害時の案内方法、復旧目標はRTO・RPOの解説で整理しています。社内の責任ある学習と、外部の読者に伝える説明責任を分けて考えましょう。
インシデント対応と、セキュリティ上の調査はどう関係するか
NISTは2025年4月、SP 800-61 Rev.3「Incident Response Recommendations and Considerations for Cybersecurity Risk Management」を最終公開しました。この改訂は2012年のRev.2を置き換え、インシデント対応を、準備、発見、対応、復旧だけでなく、組織全体のサイバーセキュリティリスク管理へ組み込む考え方を示しています。
ただしこのNIST文書は、すべての一般的なSaaS障害について同じポストモーテムの書式を義務づけるものではありません。また、情報漏えいなどが疑われる場合は、証拠保全、法令上の通知、調査手続きが必要になることがあります。通常の技術レビューを優先して調査記録を不用意に改変しないよう、セキュリティ・法務の関係者へ確認する必要があります。
いつ振り返り、いつ改善が完了したとするか
Google SRE Workbookのポストモーテム実践解説は、情報が新しい間にレビューを書き、改善項目の実施を追跡する重要性を説明しています。障害が復旧した日をもってすべての対策が完成するわけではありません。
小さなチームなら、次のような流れが考えられます。
- 復旧直後：対応記録、顧客への影響、未解決の問題を保全する。
- 早い段階：ログと関係者の情報を照合し、事実と仮説を分けてレビューをまとめる。
- 優先順位の判断：再発リスクと実装の費用・副作用を確認し、担当者・期限・完了条件を決める。
- 実装後：テストや運用で効果を確認する。未解決リスクは閉じずに追跡する。
- 定期的：複数の事故に共通する監視や組織の弱点がないか見直す。
これは当サイトによる実務の整理であり、一律に何日以内に完了しなければいけないという世界共通ルールではありません。
マーケティング・広報の役割――障害を販促の物語にしない
BtoB企業のマーケティングや広報は、顧客向けの製品説明、公開情報の更新、営業資料の整合性などを担う場合があります。事後レビューで技術部門が確認したことと、営業やWebサイトの説明が食い違わないようにすることが重要です。
障害から改善した実績を紹介する場合は、実際に何を修正し、どの範囲で検証したかを示します。「障害を乗り越えたので信頼性が高くなった」と成果だけを物語化し、未解決の課題を隠すことは避けます。
心理的安全性と一般的なマーケティング業務の振り返りはマーケティングの失敗を学習につなげる方法に整理しています。技術的な事後レビューと役割の違いを意識して使い分けましょう。
まとめ――報告書を作ることより、障害を減らす仕組みに戻す
ポストモーテムは、障害後に責任者を探すための文章ではなく、利用者に起きたことを正しく理解し、システム・手順・判断の仕組みを改善するための記録です。
事実を整理し、影響を確かめ、複数の要因を分析し、実行できる改善を完了させる。 報告書を公開することや会議を行うことそのものを成果とせず、次の障害でどの対応が変わるかを確認しましょう。
主な出典・確認範囲
- Google SRE Book「Postmortem Culture: Learning from Failure」：個人を責めない障害レビュー、学習と組織への共有。
- Google SRE Workbook「Postmortem Culture: Learning from Failure」：実例とレビューの品質、行動項目の書き方。
- Google SRE「Incident Management Guide」：改善項目の責任者、追跡、組織的な学習。
- Google Cloud「Conduct thorough postmortems」：レビューの構成と実施条件。
- NIST SP 800-61 Rev.3（2025年最終版）：サイバーセキュリティのインシデント対応をリスク管理へ組み込む指針。一般障害のポストモーテム様式そのものではない。
本文の八項目、架空障害例、進行手順は当サイトによる編集上の提案です。NIST・Googleが同じ形式を義務づけたという意味ではありません。事故・漏えいの法的義務は、影響と適用法令に応じて別途確認してください。