ポストモーテムの書き方｜障害振り返りテンプレと再発防止の落とし込み
障害がやっと直って、ふうっと息をつく。すると「振り返りまとめておいて」と頼まれる——。 対応は走れたのに、書類にすると筆が止まる。弱く書けば「次は大丈夫？」と聞かれ、強く書けば自分が責められる気がする。そんなときの拠り所が、ポストモーテム（障害報告）です。
結論：ポストモーテムは、経緯→原因→影響→再発防止の4つが書ければ十分はじめられます。「誰が悪いか」ではなく「何が起きやすかったか」で書き、対策は担当・期限・追跡先まで落とす。まずは対応時の1行ログを時系列に並べるだけでOKです。
現場には現場の事情があります。この記事の型を出発点に、いまの体制で回せるレベルに合わせて使い分けましょう。
ポストモーテムは「反省文」ではない
ポストモーテムは始末書ではなく、次に被害を小さくするための申し送りです。過去の誰かを裁く紙ではありません。未来の自分や引き継いだ誰かが同じ穴に落ちないよう、事実と学びを置いておく作業です。
「人」ではなく「仕組み」を責める
良いポストモーテムの合言葉はBlameless（誰も責めない）。人を責めると肝心の構造的な原因に届かず、対策が「気をつける」で止まりがちです。仕組みに目を向ければ、次に効く手当てになります。なお、是正指導や個別の責任の取り扱いは、別トラック（別プロセス）で行います。ポストモーテムは改善のための場に保ちます。
| 観点 | 責める書き方（避けたい） | 仕組みで見る書き方（おすすめ） |
|---|---|---|
| 原因 | 担当者が確認を怠った | 確認なしで本番反映できる手順だった |
| 表現 | ◯◯さんのミス | 誰がやっても起きうる作業だった |
| 対策 | 以後、気をつける | 反映前チェックを手順に組み込む |
| 焦点 | 過去の人 | 未来の仕組み |
ポストモーテムに入れる4つの軸
- 経緯（時系列）：いつ気づいて何をしていつ直ったか
- 原因：直接の引き金と、その奥の「起きやすかった事情」
- 影響：誰に・どれくらい・どのくらいの時間
- 再発防止：防ぐ／早く気づく・早く直すための具体策
頭に概要、末尾に残課題を添えると読みやすくなります。全部を一気に埋めなくてOK。書けるところから。
軸1：経緯（時系列）
対応中の記録を並べ替えればほぼ完成します。検知・対応・復旧の時刻を基準に1行ずつ。
2026-06-24 の障害 経緯
01:31 利用者から「画面が表示されない」と連絡
01:33 別回線でも再現を確認。自分だけの問題ではないと判断
01:35 第一報を送信（影響範囲：全ユーザー、原因調査中）
01:40 サーバーのディスク使用率が100%に達していたことを確認
01:48 肥大化していた古いログを退避し、空き容量を確保
01:50 画面の表示が回復したことを確認
01:55 復旧の連絡を送信
02:10 再発しないことを30分ほど見守り、対応終了検知までの時間／復旧までの時間／第一報や復旧連絡など節目の時刻が押さえどころ。ログが散らばっていても、チャットやメール、コマンド履歴の時刻を拾い集めれば復元できます。
AIにチャットやコマンド履歴を渡して時系列ドラフトを起こさせると初稿が速くなります。ただし出力は必ず原記録と突き合わせて事実確認してください。機微情報は渡す前に伏せ、確定は人の判断で。
AI活用の最小ルール
- 機微情報は匿名化してから渡す（氏名・顧客名・具体IDなどは伏せる）
- 社外サービスへの原文データ持ち出しは禁止（社内規程に従う）
- 出力は原記録と必ず突合せレビューし、事実と推測を明示する
軸2：原因（直接の引き金と、その奥）
「なぜ？」を仕組みに向けて2回ほど繰り返すと、表面の引き金の奥にある事情まで届きます。
- 直接の引き金：ディスク使用率が100%で書き込み失敗、アプリ停止
- なぜ満杯に？ → ログが肥大化
- なぜ肥大化を放置？ → ローテーション未設定
- なぜ気づけなかった？ → ディスク監視なし
ライト版では「直接の引き金＋最も有力な仮説」だけでも可。特定しきれないときは断定せず、「現時点の仮説／次回確認するログ」を残しましょう。
軸3：影響（誰に・どれだけ）
- 対象：全ユーザー／一部会員／社内のみ など
- 範囲：サイト全体／決済のみ／管理画面のみ など
- 時間：◯時◯分〜◯時◯分（約◯分）
- 実害：わかる範囲の件数や具体影響
数字が未集計のときは、分かっている形で置きます。
- 上限のみ分かる場合：「最大◯件以下（未確定。後追い集計中）」
- 下限のみ分かる場合：「少なくとも◯件以上（未確定。後追い集計中）」
- 推定レンジが置ける場合：「◯〜◯件の見込み（未確定。後追い集計中）」
必ず「影響件数の後追い集計」タスクを再発防止欄に1件入れておきます。
軸4：再発防止（ここが本番）
「防ぐ」と「早く気づく／早く直す」の両輪で。タスクに落として、現場の流れに乗せるのがコツです。
- 誰が（担当者）
- いつまでに（期限）
- どこで追うか（チケット／改善台帳URL／紙ファイル棚番号など）
- さらに実行しやすくする補助情報（優先度S/M/L、工数目安、決裁要否）
担当未確定なら一時的に「オーナー＝チーム名」「期限＝次回定例日」で置き、後から差し替えます。チケット運用がない現場は、改善台帳や紙ファイルで代替してOKです。
ライト／標準／重大：3段階の使い分け
テンプレは3段階で運用できるようにしています。基準は「顧客影響」「継続時間」「影響範囲」の3点で現実的に判断します。
- ライト：軽微。外部顧客の実害がない、範囲が限定的、短時間（目安：影響5分未満かつ外部顧客影響なしはライトで完了可）
- 標準：影響が限定〜中程度。外部顧客や主要機能に一定の影響、または15分超などの継続
- 重大：広範囲・長時間・外部報告が必要になりうるもの、SLO/SLAに影響する可能性が高いもの
優先順位（時間がないときはこの順で最低を確保） 1) 再発防止を1件、担当・期限・追跡先まで入れる 2) 経緯に時刻を入れる（検知／主要対応／復旧） 3) 影響の対象と時間を入れる 4) 原因を「仕組みの言葉」でひとこと置く
代替・免除条件
- 夜間一人体制は「初稿＝経緯のみ」で可。翌営業日に原因・影響・対策を追記
- 数字が出ない場合は「未確定」と明記し、集計タスクを入れる
- 心理的安全性が低い場合は「社外向け要約」と「詳細版」を分離
- チケット運用なしは改善台帳／紙で代替
そのまま使えるポストモーテム・テンプレート
以下をコピーして、わかるところから埋めてください。冒頭で公開レベルや配布先を決めておくと、共有時の不安が減ります。ライト／標準／重大のどれで行くかも最初に明記します。
# 障害ポストモーテム：（障害の短い名前）
【公開と管理】
- 公開レベル：社外共有可／社内限定／チーム内（いずれか）
- 配布先： （例）運用G全員、サポート、関係PM
- 承認者： （例）運用Mgr
- 版数： v1.0（更新したら上げる）
- インシデント種別： ライト／標準／重大（顧客影響・継続時間・範囲で判断）
## 概要
- 発生日時：2026-06-24 01:31 ごろ
- 復旧日時：2026-06-24 01:50（約19分）
- 影響：全ユーザーがサイトを閲覧できなかった（未確定なら「未確定（後追い集計中）」）
- 直接原因：ディスク使用率100%によるアプリ停止（仮説可）
- 状態：復旧済み／再発防止 対応中
## 経緯（時系列）
01:31 検知（例：利用者から表示不可の連絡）
01:33 主要対応（例：別回線で再現確認）
01:50 復旧（例：表示回復を確認）
（必要に応じて詳細を追記）
## 原因
- 直接の引き金：（例）ログ肥大化でディスクが満杯
- 奥にある事情：（例）ログローテーション未設定／ディスク監視なし
（ライトは仮説1段でも可）
## 影響
- 対象：全ユーザー／一部／社内のみ
- 範囲：サイト全体／機能名
- 時間：◯◯〜◯◯（約◯分）
- 実害：◯件（未確定時は「上限◯件以下／下限◯件以上／◯〜◯件見込み」などで置き、後追い集計タスクを立てる）
## 再発防止（タスク化）
[ ] （対策1） 担当: 期限: 追跡先: #チケット／改善台帳URL／紙=棚◯段
優先度: S/M/L 工数目安: （例）0.5日 決裁要否: 要／不要
[ ] （対策2） 担当: 期限: 追跡先:
優先度: S/M/L 工数目安: 決裁要否:
（担当未確定のときは一時的に「オーナー=チーム名」「期限=次回定例日」で置く）
## うまくいったこと
- （例）別回線での再現確認が早く、影響範囲をすぐ握れた
## 残課題・分からなかったこと
- （例）肥大化が始まった時期は未特定。次回は◯◯のログを取得して確認
（重大の場合は以下も必須）
- 外部報告リンク： （例）ステータスページURL
- SLO/SLA影響： （例）対象SLOと影響の有無
- レビュー者： （例）運用Mgr／開発リード「うまくいったこと」を入れるのは、次回に再現したい行動を言葉にして残すためです。
影響：振り返りを残すと、何が変わるか
- 同じ障害に2度ハマらない（検知も復旧も速くなる）
- 説明がラクになる（報告の往復が減る）
- 属人化がほどける（休みの日でも最低限たどれる）
- 改善が前に進む（担当・期限・追跡先があるタスクになる）
明日やること：30分で「初稿」を作る
- 記録（チャット・メール・コマンド）から時刻を集める
- 経緯欄に「検知／主要対応／復旧」を1行ずつ入れる
- 原因を「仕組みの言葉」で1〜2行（ライトは仮説で可）
- 影響の「対象・範囲・時間」を埋める（数字は未確定でも置く）
- 再発防止を1件、担当・期限・追跡先まで入れる
これで30分あれば初稿になります。難しい場合の代替案として、翌営業日に「経緯だけ10分で起こす」を先にやり、原因・対策は週次定例で確定して追記でも構いません。夜間一人体制なら「初稿＝経緯のみ」でOK、翌営業日に整えましょう。
ポストモーテム チェックリスト（現場で回る版）
ライト版（最低ライン：ここだけで完了可）
- 概要に「発生・復旧・対象・時間」が入っている
- 経緯が3行（検知／主要対応／復旧）で時刻つき
- 原因が1段（仮説可）で「仕組みの言葉」になっている
- 再発防止が1件以上、担当・期限・追跡先（チケット／台帳URL／紙=棚番号）つき
- 公開レベルが指定され、配布先が明記されている
標準版（ライトに加えて）
- 「なぜ？」を2回くり返し、奥の事情まで記載
- 影響の範囲（機能・対象）を具体化
- 「早く気づく」対策（監視・アラート・手順の見直し）を追加
重大版（標準に加えて）
- 外部報告リンク（ステータスページ等）を記載
- SLO/SLAへの影響の有無を明記
- レビュー者（少なくとも1名）を記載
- 全項目を通読し、責める表現がない
優先順位（時間がないとき）
- 1) 再発防止1件（担当・期限・追跡先）
- 2) 経緯の時刻
- 3) 影響の対象と時間
- 4) 原因の仕組み表現
できないときの代替
- 担当未確定→オーナー=チーム名、期限=次回定例日で一時設定
- 数字が出ない→「未確定」と明記し、後追い集計タスクを追加
- チケットなし→改善台帳URL／紙=棚番号で追跡
- 心理的安全性が低い→社外向け要約と詳細版を分離
全部に○でなくて大丈夫。最低ラインを守れれば、次は確実に軽くなります。
最後に
障害のあとに振り返りを書くのはしんどい仕事です。だからこそ、完璧を狙わず回る仕組みに寄せましょう。今日は、時系列を3行並べるところからで十分。その1枚が、次の自分を助けます。
障害対応の備えは、つながると一段強くなります。あわせて障害対応runbookテンプレート｜初動・切り分け・連絡・記録を1枚にもどうぞ。第一報の出し方は障害の第一報テンプレート、原因の切り分けは「サイトが重い」の切り分け手順が役に立ちます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。