会話から、使える仕事の記録へ
ポストモーテムの書き方。障害の振り返りと記録テンプレート
システム障害の後に行うポストモーテム（障害の振り返り）の書き方です。テンプレートの項目、タイムライン、影響範囲、原因分析、ブレームレスな書き方、再発防止策の検証まで架空の記入例で説明します。
公開日：更新日：執筆・運営：Klang AI AB
ポストモーテムのテンプレート：書く項目と記入例
Google SREの資料を参考に、項目を10個にまとめた例です。記入例は架空の予約受付サービスの障害（INC-01）です。
| 項目 | 書く内容 | 記入例 |
|---|---|---|
| 概要 | 何が起きたかを2〜3文で | 予約確認メールの一部が送信できなかった |
| 影響 | 件数・人数・時間を単位つきで | 送信試行120回中30回失敗。影響人数は調査中 |
| タイムライン | 時刻・出来事・根拠 | 10:00 設定変更（変更記録L01） |
| きっかけ | 直接のきっかけの候補 | 10:00の設定変更（関連を確認中） |
| 寄与した条件 | きっかけが障害になった背景 | 変更前の確認表に別経路の項目がない |
| 検出 | どう気付いたか、遅れはあったか | 10:05に監視で検出 |
| 対応 | 復旧までに行ったこと | 10:15に変更を戻し、10:40に受付再開 |
| うまくいったこと | 次も続けたい対応 | 検出から5分で対応担当が集まった |
| 再発防止策 | 担当・期限・確認方法 | 確認表に経路一覧を追加（運用担当・10月20日） |
| 未確認の事項 | まだ分からないこと | 発生開始の時刻、影響した人数 |
ポストモーテム会議の進め方（60分の例）
下書きを作ってから関係者で読み合わせる流れです。会議の前に下書きを共有しておくと、時間を事実の確認に使えます。
- 01
事前：担当者が下書きを作る
ログ、対応中のチャット、障害対応会議の記録からタイムラインと影響の下書きを作り、参加者に共有します。
- 02
0〜20分：タイムラインを確かめる
時刻ごとに根拠を読み合わせ、記憶だけの時刻には「ごろ」と残します。人の判断は、当時見えていた情報と一緒に確かめます。
- 03
20〜40分：寄与した条件を挙げる
きっかけ・事前条件・検出の課題を分けて挙げます。原因を一つに決めつけず、根拠のない候補は仮説として残します。
- 04
40〜60分：再発防止策と担当を決める
予防・検出・影響の縮小のどこに効く対策かを書き、担当・期限・効果の確かめ方を決めます。
ポストモーテムと障害報告の違い：3つの成果物
架空の予約受付サービスで、一部の送信が失敗した事例を使います。復旧連絡と学習用の記録は目的が違います。
以下の人物・案件・会話・数値は、説明用の架空の例です。
| 確認するもの | 記録した内容 | 次の扱い |
|---|---|---|
| 対応中の状況メモ | 影響の分かる範囲、実施中の対応、次の更新 | 未確定でも状態と時点を示す |
| 社内ポストモーテム | 時系列、根拠、寄与要因、今後の検証 | 復旧後に関係者が確認 |
| 関係部署への要点 | 業務への影響、現状、担当部署が必要とする対応 | 内部の詳細を無条件に転載しない |
Google SREの資料を記録の方法として参照しています。このページは障害復旧の操作手順や原因の自動判定ではありません。
確認後に残す記録の例
事例INC-01／架空 成果物A：対応状況メモ、10:40時点で受付再開。 成果物B：社内振り返りv0.1、影響・原因の確認中。 成果物C：業務担当向け要点、確認できた受付範囲と問い合わせ先。 復旧済みと再発防止完了を区別する。
タイムラインの書き方：ログ・会話・記憶を時系列に並べる
後から思い出した時刻を、ログと同じ精度にしません。この例の時刻は全て日本時間です。
以下の人物・案件・会話・数値は、説明用の架空の例です。
| 確認するもの | 記録した内容 | 次の扱い |
|---|---|---|
| 10:00／変更記録L01 | 設定を変更 | システムの記録 |
| 10:05／監視記録L02 | 送信失敗を検出 | 検出時刻。発生開始と同じとは未確認 |
| 10時ごろ／担当者メモM01 | 問い合わせを受けた記憶 | 概算のまま。正確な分は不明 |
| 10:15／連絡記録C01 | 変更の戻しを開始 | 実施開始を確認 |
| 10:35／確認記録L03 | テスト送信が成功 | 確認した経路のみ |
| 10:40／連絡記録C02 | 受付再開を共有 | 全ての再発防止完了ではない |
資料が別の時刻帯なら元の時刻と換算後を両方残します。会議で語られた時刻が違っても、根拠なく片方へそろえず照合対象にします。
確認後に残す記録の例
INC-01時系列：全時刻JST。L01/L02/L03は確認用の架空ログ、C01/C02は連絡記録、M01は後日の回想。「10時ごろ」は正確な発生時刻に使わない。発生開始は追加調査中。
影響範囲の書き方：件数・人数・時間を分ける
120回の送信のうち失敗30回があっても、30人が影響したとは限りません。
以下の人物・案件・会話・数値は、説明用の架空の例です。
| 確認するもの | 記録した内容 | 次の扱い |
|---|---|---|
| 送信試行 | 120回のうち失敗30回 | 試行の失敗率30÷120＝25% |
| 同じ人の再試行 | 含まれるが個人別の重複は未集計 | 影響人数は未確定 |
| 確認できる期間 | 10:05に検出、10:35にテスト成功 | この二点は30分間。全障害時間と断定しない |
| 未確認 | 開始時刻、別経路の影響、重複を除いた人数 | 後続調査へ渡す |
件数、人数、取引数、時間を別々に書きます。概算には根拠と範囲を付け、都合のよい正確な数字を作りません。
確認後に残す記録の例
INC-01影響：対象ログの送信試行120回中30回失敗（25%）。再試行を含むため影響した人数は未確定。検出からテスト成功まで30分。発生開始と全経路の回復時刻は未確認。
原因分析の書き方：きっかけ・事前条件・検出の課題
会話に出た一つの操作だけで、全ての原因を説明しようとしません。
以下の人物・案件・会話・数値は、説明用の架空の例です。
| 確認するもの | 記録した内容 | 次の扱い |
|---|---|---|
| きっかけの候補 | 10:00の設定変更 | 失敗との関連をログで調べる |
| 事前条件の候補 | 変更前の確認項目に別経路がない | 確認表v1を照合 |
| 検出の課題 | 正常な1経路だけの確認で再開を判断しかけた | どの経路を確かめたか点検 |
| まだ言えないこと | 担当者が注意を怠った、変更だけが唯一の原因 | 意図や単一原因を推測しない |
候補は根拠が揃うまで仮説です。原因を断定するための追加の確認と、先にできる安全な改善を分けて決めます。
確認後に残す記録の例
INC-01検証課題：設定変更と失敗の対応、確認表が対象にしていた経路、再開確認の範囲。現時点で個人の意図は評価しない。原因候補ごとに根拠と未確認点を残す。
ブレームレスな書き方：責める文章の書き直し例
判断の経緯を消すことと、人を責めないことは別です。
以下の人物・案件・会話・数値は、説明用の架空の例です。
- 元の文章： 担当者が無責任に変更したため、全てが止まった。今後は注意する。
- レビュー担当： 確認できる操作は何ですか。「無責任」と「全て」は何が根拠ですか。
- 記録者： 変更記録はありますが、意図と全経路の停止は確認していません。
- レビュー担当： 操作、当時の確認表、影響の確認範囲に書き直し、不明点を残しましょう。
修正版には実際に行った操作と確認範囲を残します。動機を決めつけず、当時参照できた情報を確かめる質問を追加します。
確認後に残す記録の例
【修正版・架空】10:00、担当者は確認表v1の項目を確認して設定を変更した。v1には別経路の確認項目がなかった。10:05に失敗を検出した。変更と失敗の関係は対象ログで照合中。 追加確認：v1を利用した理由、当時表示されていた注意事項、別経路を確認できる仕組みの有無。
再発防止策の立て方：予防・検出・影響の縮小
一つの「確認を徹底する」で終わらず、失敗のどこへ働きかけるかを示します。
以下の人物・案件・会話・数値は、説明用の架空の例です。
| 確認するもの | 記録した内容 | 次の扱い |
|---|---|---|
| 予防／運用担当 | 変更前チェックに対象経路一覧を追加 | 架空の変更計画で未確認経路を検出できるか |
| 検出／監視担当 | 確認結果に経路名を残す | 一経路だけ失敗する試験で見落とさないか |
| 影響縮小／対応担当 | 戻し判断の連絡先と判断条件を整える | 机上演習で判断・連絡の抜けを確認 |
実施操作は各システムの担当者が判断します。ここでは作業を追跡する方法を示し、技術的な修復を自動実行しません。
確認後に残す記録の例
INC-01改善セット：予防は対象経路の確認漏れ、検出は一部失敗の見落とし、影響縮小は判断連絡の遅れを対象にする。各担当は完了資料だけでなく検証結果をレビューに提出。期限だけで完了へ移さない。
再発防止策の効果を確かめる方法
資料の追加や作業完了の報告だけでは、同じ失敗への備えを確認できません。
以下の人物・案件・会話・数値は、説明用の架空の例です。
| 確認するもの | 記録した内容 | 次の扱い |
|---|---|---|
| 対策A：確認項目を追加 | 文書改訂と、抜けのある架空計画による確認を実施 | 対象ケースでは機能を確認 |
| 対策B：連絡先を更新 | 一覧の変更だけ完了。代替担当との演習は未実施 | 効果確認は未完了 |
| 終了判断 | 対策Bの演習を終えるまで振り返りは継続 | 受付再開とは別の状態 |
この検証で見ていないケースへの効果は主張しません。誰が何を試し、どこまで確認できたかを記録します。
確認後に残す記録の例
INC-01対策レビュー：Aは改訂版と試験票をレビュー済み。Bは文書更新済み・連絡演習待ち。復旧は済んでいるが、再発防止レビューは未完了。次回は不在担当の代替連絡を確認する。
経営・関係部署向けの要約の書き方
読み手向けに短くしても、分かっていない影響や対策の状態は落としません。
以下の人物・案件・会話・数値は、説明用の架空の例です。
| 確認するもの | 記録した内容 | 次の扱い |
|---|---|---|
| 影響 | 対象送信120回中30回失敗 | 影響人数は未確定 |
| 対応 | 10:40受付再開を共有 | 全経路の確認記録は別途点検中 |
| 原因 | 設定変更との関連を確認中 | 個人の責任や唯一の原因は未確定 |
| 今後 | 対策Aは検証済み、Bは演習待ち | 復旧と改善完了を区別 |
元の時系列・影響表・対策票へ戻れる参照を付けます。短い報告でも、根拠のない安心や責任判断を追加しません。
確認後に残す記録の例
INC-01要点（架空） 確認した送信120回のうち30回失敗。利用者数は調査中。10:40に受付再開を共有した。設定変更と失敗の関連を確認している。対策Aは対象ケースの検証済み、Bは連絡演習待ち。 参照：時系列INC-01、影響表、対策レビュー。次回は未確定の影響とBの検証を確認する。
障害対応の会議を、タイムラインの根拠にする
障害対応中のZoom・Teams・Google Meetの会議をKlangで自動録音すると、「誰がいつ何を判断したか」を後から文字で確かめられます。ポストモーテムの下書きでは、会議の発言の時刻とシステムのログを並べ、記憶だけの時刻と区別します。
- 障害対応会議の発言を、時刻つきで読み返せる
- AIチャットで「戻す判断をした発言」を探し、元の音声で確かめる
- 振り返り会議そのものも記録し、決まった対策と担当を残す
よくある質問
ポストモーテムとは何ですか？
システム障害などの後に、何が起きたか、なぜ起きたか、どう対応したか、再発をどう防ぐかを文書にまとめる振り返りです。個人の責任を追及するためではなく、組織として学ぶために書きます。この考え方はブレームレスと呼ばれます。
ポストモーテムと障害報告書の違いは何ですか？
障害報告書は、影響や対応状況を顧客や関係部署に伝える文書です。ポストモーテムは社内で学ぶための文書で、タイムライン、寄与した条件、うまくいったこと、再発防止策の検証まで詳しく書きます。同じ事実を使いますが、読み手と目的が違います。
ポストモーテムはいつ書けばよいですか？
復旧した後、関係者の記憶が新しいうちに下書きを始めます。このページの例では、担当者が下書きを作り、数日以内に関係者で読み合わせる会議を開く流れにしています。
ブレームレスに書くには、どうすればよいですか？
「担当者が無責任に変更した」のような評価ではなく、「担当者は確認表v1の項目を確認して設定を変更した。v1には別経路の確認項目がなかった」のように、実際の操作と当時参照できた情報を書きます。意図や性格を推測で書かないことが要点です。