ポストモーテムは、本番障害が収まったあとに、影響・対応の経過・原因・再発防止策を文書にまとめ、チームで振り返る取り組みです。Google SRE本は、利用者に見える停止やデータ損失などをきっかけに書くものと定め、PagerDutyは重大度1の障害なら3暦日以内に振り返り会議を開く社内方針を公開しています。この記事では、障害報告書やKPTとの違いを整理したうえで、タイムライン・根本原因・アクションアイテムの書き方を一次情報に沿って解説する構成です。Markdownのテンプレート、GitHub Issue FormsのYAML、放置されたアクションを洗い出すgh CLIのコマンドまで載せているので、そのまま自社の運用に組み込めます。
まとめ：ポストモーテムを書き続けられるチームにするための結論
書き方より先に決めるのは、どの障害で書くか、いつまでに書くか、誰が書くかの3つです。対象はGoogle SRE本の5つのトリガーを自社の重大度に置き換えて決め、期限は重大度1なら3暦日、重大度2なら5営業日を目安にします。オーナーは1人に絞ります。
文書は、時刻と出典つきのタイムライン、トリガーと根本原因を分けた分析、種別・担当者・チケット番号を持つアクション表の3部で組み立てます。非難しない運用は心構えではなく、「人為的ミス」で原因欄を閉じさせないテンプレートと、アクションの放置を週次で機械的に拾う仕組みで支える運用です。少人数のチームでは、全障害に書くのではなく対象を絞る方が長続きします。
ポストモーテムの意味と障害報告書・KPT・なぜなぜ分析との違い
同じ「振り返り」でも、対象と読み手が違えば書く中身が変わります。
Google SRE本とPagerDutyの定義から読むポストモーテムの目的
Google SRE本の「Postmortem Culture」は、ポストモーテムを、インシデントとその影響、緩和・解決のために取った対応、根本原因、再発を防ぐための後続アクションを記録した文書と定義しています。英語のpost-mortemは本来「検死」の意味で、障害が終わった後に原因を調べる行為に転用された言葉です。
PagerDutyの解説は、組織によってLearning Review、After-Action Review、Post-Incident Review、RCA（根本原因分析）とも呼ぶと書いています。呼び名は違っても、成果物に「何が起きたか」と「次に何をするか」の両方が入っていればポストモーテムです。原因の説明だけで終わる文書は、再発防止の役に立ちません。
障害報告書・KPT・なぜなぜ分析とポストモーテムの対象と読み手の違い
現場で混同されやすい3つの手法と並べると、ポストモーテムの位置づけがはっきりします。
| 手法 | 対象 | 主な読み手 | 成果物 |
|---|---|---|---|
| ポストモーテム | 個別の障害 | 開発・運用チーム、社内 | 時系列・原因分析・アクション表 |
| 障害報告書 | 個別の障害 | 発注者・顧客・経営層 | 影響範囲・原因の要約・再発防止の約束 |
| KPT | スプリントや期間 | チーム自身 | 続けること・問題・試すこと |
| なぜなぜ分析 | 1つの問題 | 品質・製造の担当者 | 原因の連鎖 |
ポストモーテムは社内で学ぶための技術文書で、障害報告書は外部に説明するための文書です。先にポストモーテムで事実と原因を固め、その要約を報告書に転記する順にすると、両者の内容が食い違いません。期間全体の振り返りはKPT法の進め方とテンプレート、原因を掘る手法そのものはなぜなぜ分析のやり方と向かない場面で扱っています。
ポストモーテムを書く障害の基準と期限・担当者を事前に決める手順
基準が無いと、書くかどうかを毎回議論することになり、忙しい時期ほど書かれなくなります。
Google SRE本の5つのトリガーを自社の重大度基準に置き換える方法
Google SRE本が挙げるトリガーは次の5つです。加えて、関係者は誰でもポストモーテムを要求できるとしています。
- 利用者に見える停止や性能劣化が一定の閾値を超えた
- 種類を問わずデータが失われた
- オンコール担当がロールバックや経路の切り替えなどで介入した
- 解決までの時間が一定の閾値を超えた
- 監視が障害を検知できず、人が見つけた
同書は、この基準をインシデントが起きる前に決めておくよう求めています。自社に置き換えるときは「閾値」を数字にします。たとえば「主要画面のエラー率5%超が10分以上」「復旧まで60分超」のように書けば、障害の最中でも対象かどうかを迷いません。5番目の監視漏れは影響が小さくても対象に入れます。次の障害を見逃す原因がそこにあるからです。重大度の決め方やオンコールの体制はインシデント管理のプロセスとオンコールの実装で解説しています。
PagerDutyの3暦日・5営業日の期限とオーナーを1人に絞る理由
PagerDutyは、重大度2以上の障害では必ずポストモーテムを行い、誤報だった場合でもインシデント対応を起動したなら実施するとしています。社内方針として公開している期限は、重大度1が3暦日、重大度2が5営業日です。記憶が新しいうちに書くことと、計画済みの作業より優先することを明記しています。
オーナーは、障害対応の指揮役（インシデントコマンダー）が対応の終わりに1人だけ指名します。チーム全員に頼むと、誰かがやると全員が思い込んで誰も書かない、という傍観者効果が起きるからです。オーナーは1人で書き上げる係ではなく、関係者を集めて期限内に完成させる取りまとめ役です。PagerDutyの手順書では、オーナーの責任はフォローアップのチケットを作るところまでで、完了まで追いかけることは含めていません。完了の追跡は別の仕組みで担います（後述）。
ポストモーテムの書き方をタイムライン・根本原因・アクションの順で解説
文書の中心は、事実を並べるタイムライン、原因の分析、次の行動の3部です。この順に書くと、推測で原因を決めつける失敗を防げます。
障害記録の時刻の基準を決めて出典つきで並べるタイムラインの書き方
最初に書くのはタイムラインです。Google SRE本の例は日付の横に「all times UTC」と明記し、24時間表記で並べています。国内向けのサービスならJSTで揃えても構いませんが、どちらを使うかを見出しに明記する必要があるため、記載を忘れないでください。クラウドのログはUTC、チャットの履歴はJSTで残ることが多く、混ぜると9時間ずれた順序で原因を読み違えます。
PagerDutyの手順書は、タイムラインの各項目に、根拠となるメトリクスや外部ページへの参照を付けるよう求めています。「14:05 エラー率が上昇」とだけ書かず、ダッシュボードのURLやログの検索条件を添えると、後から読む人が事実を確かめられます。記録すべき時刻は、異常の開始、検知、担当者の呼び出し、ステータスページの更新、緩和、完全な復旧の6点です。この区間の長さがそのままMTTR（平均修復時間）の計測の元データになります。
根本原因とトリガーを分けて書き寄与要因を複数挙げる分析の進め方
Google SRE本の例では、「Root Causes」と「Trigger」が別の見出しになっています。トリガーは障害の引き金になった出来事（例では急に増えたアクセスで潜在的な不具合が表に出たこと）で、根本原因はその出来事で壊れる状態を作っていた条件（例では、極端な高負荷と、検索が失敗したときに起きるリソースのリークの組み合わせ）です。引き金だけを直しても、同じ条件があれば別の引き金で再発します。
原因は1つに絞らなくて構いません。PagerDutyのテンプレートは見出しを「Contributing Factors（寄与要因）」としており、問題を起こした条件に加えて、復旧の途中で事態を悪化させた行動も書く欄を設けています。分析の対象は、技術の要因と手順の要因の両方です。たとえば「設定ファイルの誤り」に対しては、「レビューで差分を確かめる仕組みが無かった」「本番に反映する前の検証環境が無かった」まで掘ります。
種別・担当者・チケット番号を持つアクションアイテム表の作り方
Google SRE本の例では、アクションアイテムを表にまとめ、列を「Action Item」「Type」「Owner」「Bug」の4つにしています。種別は、影響を小さくするmitigate、再発を防ぐprevent、手順を変えるprocess、その他のotherです。
| アクション | 種別 | 担当 | チケット |
|---|---|---|---|
| 連鎖障害の対応手順をRunbookに追記 | mitigate | 運用リーダー | #412 |
| 設定変更に差分レビューを必須化 | prevent | 開発リーダー | #413 |
| 障害訓練を四半期に1回実施 | process | SRE担当 | #414 |
担当者とチケット番号の無いアクションは、まず実行されません。逆に、全部をpreventで埋めると工数が膨らみ、どれも終わらない計画になります。影響を早く小さくするmitigateを先に終わらせ、根本的な対策は優先度を付けて順に進める方針です。Lessons Learnedの欄には、Google SRE本の例と同じく「うまくいったこと」「うまくいかなかったこと」に加え「運が良かったこと」も書きます。運に救われた箇所は、次の障害で同じ幸運が無ければ被害が広がる場所です。
そのまま使えるポストモーテムのテンプレートとGitHubでの設定例
テンプレートは、書く人の負担を下げると同時に、抜けやすい項目を必須にする道具です。
Google SRE本の例を下敷きにしたMarkdownテンプレートの全項目
Google SRE本の例とPagerDutyのテンプレートの見出しを合わせ、国内の開発チーム向けに並べ替えたものです。リポジトリのdocs/postmortems/などに置き、障害ごとに複製して使います。
# ポストモーテム：（障害の要約を1行で）
- 発生日：YYYY-MM-DD
- 重大度：Sev-1 / Sev-2
- オーナー：（1人）
- 状態：下書き / レビュー中 / レビュー済み
- 振り返り会議：YYYY-MM-DD HH:MM（30〜60分）
## 概要
（何が起き、どれだけの影響があり、どう収まったかを2〜3文で）
## 影響
- 影響を受けた利用者数・機能：
- 影響の継続時間：
- データ損失の有無：
## タイムライン（すべてJST）
| 時刻 | 出来事 | 出典（ダッシュボード・ログ・チャット） |
|---|---|---|
| 14:02 | 異常の開始 | |
| 14:05 | 監視が検知 | |
| 14:40 | 緩和（ロールバック） | |
| 15:10 | 完全復旧 | |
## トリガー
## 根本原因と寄与要因
## 検知（どう気づいたか・監視は機能したか）
## 解決（暫定対応と恒久対応を分けて）
## アクションアイテム
| アクション | 種別 | 担当 | チケット |
|---|---|---|---|
## 学んだこと
### うまくいったこと
### うまくいかなかったこと
### 運が良かったこと
## 社外への説明文（必要な場合）最後の「社外への説明文」は、PagerDutyのテンプレートにある「External Message」にあたります。ここをポストモーテムの中で下書きしておくと、障害報告書やステータスページの文面と技術的な事実がずれません。
GitHubのIssue Formsでポストモーテムの記入漏れを防ぐYAML設定
Markdownのテンプレートは、見出しを消せば空欄のまま提出できてしまいます。GitHubを使っているチームなら、Issue Formsで入力欄を必須にする設定が可能です。.github/ISSUE_TEMPLATE/にYAMLを置き、name・description・bodyの3つを必ず書きます。
# .github/ISSUE_TEMPLATE/postmortem.yml
name: ポストモーテム
description: Sev-1・Sev-2の障害の後に作成する振り返りの記録
title: "[Postmortem] "
labels: ["postmortem"]
body:
- type: markdown
attributes:
value: |
原因欄に個人名や「人為的ミス」だけを書かず、その操作ができた仕組みを書いてください。
- type: dropdown
id: severity
attributes:
label: 重大度
options:
- Sev-1（3暦日以内に会議）
- Sev-2（5営業日以内に会議）
validations:
required: true
- type: input
id: owner
attributes:
label: オーナー（1人）
description: GitHubのユーザー名
validations:
required: true
- type: textarea
id: impact
attributes:
label: 影響
description: 利用者数・継続時間・データ損失の有無を数値で
validations:
required: true
- type: textarea
id: timeline
attributes:
label: タイムライン（時刻の基準を明記）
value: |
| 時刻(JST) | 出来事 | 出典 |
|---|---|---|
validations:
required: true
- type: textarea
id: root-cause
attributes:
label: トリガーと根本原因・寄与要因
validations:
required: true
- type: textarea
id: actions
attributes:
label: アクションアイテム（種別・担当・チケット番号）
validations:
required: true
- type: checkboxes
id: blameless
attributes:
label: 提出前の確認
options:
- label: 原因を個人の注意不足で終わらせていない
required: true各入力欄の書き方はGitHubのフォームスキーマの仕様に沿っています。GitHubのドキュメントは2026年11月時点でIssue Formsを「public preview」としており、仕様が変わる可能性がある点は覚えておいてください。labelsに書いたラベルは、リポジトリに同名のラベルが無いと付与されないので、先に作っておきます。
放置されたアクションアイテムをgh CLIで週次に洗い出すコマンド例
アクションごとのIssueにpostmortem-actionのラベルを付けておけば、GitHub CLIのgh issue listで、作成から30日を過ぎても開いたままのものを一覧にできます。
# 30日より前に作られ、まだ閉じていないアクションを表示する（GNU dateの例）
SINCE=$(date -d '30 days ago' +%F)
gh issue list --label postmortem-action --state open --limit 100 \
--search "created:<${SINCE}" \
--json number,title,assignees,createdAt \
--jq '.[] | [.number, .title, ([.assignees[].login] | join(",")), .createdAt] | @tsv'--limitの既定値は30件なので、件数が多いリポジトリでは指定を忘れないようにします。macOSのdateではdate -v-30d +%Fに置き換える必要があるため、実行環境に合わせて変更してください。このコマンドをCIの定期実行に組み込み、結果をチャットに投稿すれば、オーナーが追いかけなくても放置が見える状態になります。
非難しないポストモーテムを形だけで終わらせない書き方と運用の型
「誰も責めない」と宣言するだけでは、原因欄に個人の行動が並ぶ文書は無くなりません。
原因分析を「人為的ミス」で止めず操作が通った仕組みに書き換える表現例
PagerDutyのブレームレスの解説は、Sidney Dekkerの整理を引き、人の誤りを失敗の原因と見る旧来の見方と、システムの問題の症状と見る新しい見方を対比しています。罰を恐れる組織では、障害が起きても担当者が声を上げなくなり、検知と復旧が遅れると指摘しています。焦点は「誰が」ではなく「どのように」です。
| 書き換え前 | 書き換え後 |
|---|---|
| 担当者が本番DBで誤ってDELETEを実行 | 作業用アカウントに本番DB書込権限が常時付与 |
| 確認不足で設定ミスを反映 | 設定ファイルの差分を第三者が確認する工程が無かった |
| アラートの見落とし | 夜間アラートが1日40件超で重要通知が埋没 |
書き換えた後の文は、そのまま対策の形になっています。権限を分ける、レビューを必須にする、アラートを減らす、です。原因欄が人の注意力の話で終わっている文書は、レビューで差し戻します。夜間のアラートの絞り方はDatadog On-Callのエスカレーション設計で具体例を示しています。
振り返り会議の議題と前日共有、Prime Directiveの使い方
PagerDutyの会議ガイドは、文書へのリンクを会議の24時間前に参加者へ送るよう勧めています。会議の時間を文書の読み上げに使わないためです。会議の成果として最も大事なのは、アクション計画への合意だとしています。
会議の冒頭で、Norm KerthのRetrospective Prime Directive（誰もがその時点の知識・技能・資源・状況の中で最善を尽くした、と理解し信じる）を読み上げるチームもあります。議題は次の3つに絞ります。
- オーナーが原因とタイムラインを要約し、なぜこの状態に至ったかを議論する
- オーナーがアクション案を示し、再発の可能性を下げられるか、追加の作業が要るかを議論する
- リーダー層がアクションの優先度にコミットし、やらないと決めた作業とその影響も記録する
Google SRE本は「レビューされないポストモーテムは、存在しなかったのと同じ」と書いています。会議は形式ではなく、書いた内容を組織の決定に変える工程です。
ポストモーテムを導入すべきチームと形骸化させる失敗パターンの判断
ポストモーテムは書くこと自体が目的になると、すぐに続かなくなります。
少人数チームで全障害に書くのは過剰になる条件と最小構成の線引き
開発者が5人以下で、障害の大半が利用者に見えない軽微なものなら、全件に書くのは過剰です。対象は、利用者への影響が出たもの、データが失われたもの、監視が気づけなかったものの3種類に限ります。それ以外はチャットのスレッドに時系列と対処を残すだけで十分です。
逆に、受託開発で発注者に障害報告をする立場なら、件数が少なくても書きます。社外向けの報告書の根拠になるのは社内のポストモーテムだからです。SREの考え方そのものを組織に入れるかどうかはSREの原則とDevOpsとの違い、障害の振り返りを含めた開発と運用の成果の測り方はDevOpsとDORA 5指標の解説を参照してください。
再発防止のアクションが完了しないまま溜まる失敗パターンと期限の付け方
形骸化の典型は3つあります。期限の無いアクションが積み上がる、同じ原因の障害が2度目のポストモーテムで初めて見つかる、文書が個人のフォルダに散らばって誰も読み返さない、の3つです。
1つ目は、全アクションに期限を付け、先に示したgh CLIの一覧を週次の定例で必ず見ることで防げます。2つ目は、ポストモーテムを1か所のリポジトリに集め、ラベルや原因の分類で検索できるようにすることが、同じ原因の再発に気づくための対策です。3つ目について、Google SRE本はよく書けたポストモーテムを月1回社内に紹介する「Postmortem of the month」や、過去の障害を役割分担して再演する「Wheel of Misfortune」を紹介しています。読まれる仕組みが無いと、書く動機も続きません。
障害の振り返りと、デプロイ・監視の自動化はつながっています。アクションの多くは「レビューを必須にする」「ロールバックを自動化する」といったパイプラインの改修になるからです。ポストモーテムで出た対策を開発の流れに組み込みたい場合は、DevOps・CI/CD導入支援で、今のパイプラインの棚卸しから相談を受け付けています。
よくある質問
ポストモーテムを始めるとき、現場でよく出る質問に答えます。
ポストモーテムとポストモータムはどちらの表記が正しいですか？
英語のpostmortem（post-mortem）をカタカナにしたもので、IT分野では「ポストモーテム」の表記が広く使われています。ポストモータムと書く例もありますが、指しているものは同じです。社内の文書では表記を1つに揃えておくと、検索で過去の文書を探しやすくなります。PagerDutyが挙げるように、Post-Incident ReviewやIncident Reviewと呼ぶ組織もあるので、英語の資料を探すときはこれらの語でも検索します。
ポストモーテムと障害報告書は両方作る必要がありますか？
社外に説明する相手がいるなら両方作ります。ポストモーテムは開発・運用チームが原因を深く分析し、次の行動を決めるための社内文書です。障害報告書は発注者や顧客に影響と対策を説明する文書で、内部の分析の細部や担当者の情報は載せません。先にポストモーテムで事実を固め、その要約を報告書に移す順にすると、2つの文書で時刻や原因の記述が食い違う事故を避けられます。
ポストモーテムはどのツールで書けばよいですか？
Google SRE本は、Google Docsの社内テンプレートで書き、同時編集とコメントで共同作業していると紹介しています。チームが日常的に使っている場所で書くのが、一番続けやすい方法です。GitHubで開発しているならIssue FormsかリポジトリのMarkdown、ConfluenceやNotionを使っているならそのテンプレート機能で足ります。なおPagerDutyは、同社のPostmortems機能を2026年10月31日に提供終了したと案内しており、同社製品の中ではPost-Incident Reviewを使うよう案内しています。
生成AIにポストモーテムを書かせてもよいですか？
チャットの履歴やログからタイムラインの下書きを作る作業は、生成AIに任せても効果があります。ただし根本原因の判断と、どのアクションに工数を割くかの決定は人が行います。AIがまとめた時刻を確定する前には、必ず元のログやダッシュボードでの確認が必要です。SRE本の第2版で扱われるAI支援の範囲はSRE本第2版の変更点、障害の調査をAIエージェントで自動起動する構成はAWS DevOps Agentの使い方で解説しています。
ポストモーテムは社外や利用者に公開すべきですか？
全文を公開する必要はありません。社内向けのポストモーテムには、システム構成や権限の設定など、攻撃の手がかりになる情報が含まれます。公開するのは、影響の範囲、原因の要約、再発防止策の3点を、セキュリティ上の問題が無い粒度に書き直した文面です。PagerDutyのテンプレートも、社内向けのメールと社外向けのメッセージを別の欄に分けています。公開版はポストモーテムのレビューが終わってから出し、技術的な事実とずれないようにします。
関連記事
- インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装を運用目線で解説【2026年版】：ポストモーテムの前段にあたる、検知から終結までの障害対応の流れです。
- SREとは？サイト信頼性エンジニアリングの意味と原則、DevOpsとの違いをGoogleの原典で解説：ポストモーテムを含むSREの原則全体の解説です。
- MTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策を実装目線で解説【2026年版】：タイムラインの時刻から復旧時間を計測する方法です。
- KPT法とは？読み方・進め方とテンプレート・記入例、欠点と続かない原因：障害ではなく期間を対象にする振り返りの手法です。
- なぜなぜ分析とは？やり方5ステップと記入例・事例、トヨタの原典と向かない場面：根本原因を掘り下げる分析手法の詳細です。
