インシデント対応とポストモーテムの書き方｜障害を再発させないための手順とテンプレート

「障害が起きると全員がSlackに集まって騒ぎになり、誰が何をしているのかわからなくなる」「復旧はしたが、結局原因が何だったのか記録が残っていない」「同じ障害が半年後にまた起きた」――障害そのものより、障害への「対応の仕方」が決まっていないことが、被害を大きくし、再発を許します。

この記事では、検知から初動、影響範囲の特定、暫定対処、恒久対策までの流れを型として整理し、少人数でも機能する役割分担（指揮者・記録係）、社内外への連絡文例、そして「誰が悪いか」を探さないポストモーテム（事後検証）の書き方とテンプレート、再発防止策を確実に完了させる追跡の仕組みまで解説します。読み終えると、次の障害で「まず何をするか」が迷わず決められるようになります。

インシデント対応の流れ：検知から恒久対策まで

障害対応は、次の5段階に分けると混乱しません。各段階で「今はどの段階か」を宣言するだけでも、チームの動きは大きく変わります。

段階	目的	やること	やらないこと
1. 検知	異常に気づく	アラート・ユーザー報告・自分の目視のいずれかで異常を認識し、対応を開始すると宣言する	「様子を見る」で放置
2. 初動	体制を作る	指揮者と記録係を決め、専用チャンネルを立て、関係者に第一報を出す	全員が同時に原因調査を始める
3. 影響範囲の特定	誰がどう困っているかを知る	影響を受ける機能・ユーザー・件数・開始時刻を確認する	根本原因の追求（この段階ではまだ不要）
4. 暫定対処	ユーザー影響を止める	ロールバック、再起動、機能の一時停止、フェイルオーバーなど「一番速く止まる手」を打つ	原因を完全に理解してから直そうとする
5. 恒久対策	再発を防ぐ	ポストモーテムで原因と対策を整理し、対策の完了を追跡する	「気をつける」で終わらせる

「直す」より「止める」を優先する

もっとも重要な原則は、暫定対処と恒久対策を分けることです。障害の最中に根本原因を突き止めて正しい修正をしようとすると、その間ずっとユーザーは困り続けます。「直前のデプロイを戻す」「問題の機能をフィーチャーフラグで止める」「レプリカに切り替える」のように、原因がわからなくても影響を止められる手を先に打ちます。原因調査は、影響が止まってから落ち着いて行えばよいのです。5xxエラーの切り分け手順は502・503・504エラーの原因と切り分けを参照してください。

役割分担：指揮者と記録係を必ず置く

指揮者（インシデントコマンダー）

障害対応で最初に決めるべきは「誰が指揮を執るか」です。指揮者の仕事は、自分で調査することではなく、次を決めることです。

• 今どの段階にいるかを宣言し、次に何をするかを決める
• 誰が何を調べるかを割り振り、同じことを複数人がやらないようにする
• 暫定対処を「やる／やらない」を判断する（ロールバックの決断など）
• 定期的（例：15分おき）に状況を整理して共有する

指揮者は必ずしも一番技術に詳しい人である必要はありません。むしろ詳しい人は調査に専念させ、指揮者は全体を見る役に徹する方が機能します。3人のチームでも、1人は手を止めて指揮に回る価値があります。

記録係（スクライブ）

記録係は、「何時に何がわかり、誰が何をしたか」を時系列で書き留めます。この記録がなければ、後のポストモーテムは記憶頼りになり、正確なタイムラインが復元できません。専用のSlackチャンネルに「HH:MM 〇〇を確認」「HH:MM △△をロールバック開始」と書き込むだけで十分です。人手が足りなければ指揮者が兼ねますが、調査担当が兼ねるのは避けてください。

# 記録係の書き込み例（インシデント用チャンネル）
14:02 アラート: api-prod 5xx率 12%（通常0.1%）
14:04 指揮者: 田中 / 記録: 佐藤 / 調査: 鈴木・山田。ステータス: 調査中
14:06 影響範囲: 決済APIの約3割が500。ログインは正常
14:09 13:55にv2.14.0をデプロイ済みと判明（鈴木）
14:11 指揮者判断: 原因未確定だがv2.13.2へロールバック実施
14:15 ロールバック完了。5xx率 0.2%まで低下
14:20 ステータス: 暫定復旧。監視継続、原因調査へ移行

社内外への連絡：テンプレートを先に用意する

第一報は「わからないこと」を含めて速く出す

連絡は、内容が固まってからではなく、「まだ調査中」の段階で出します。関係者が一番困るのは「何が起きているか誰も教えてくれない」状態です。第一報・続報・復旧報の3つの文例を用意しておき、埋めるだけにしておくと、障害の最中に文面で悩まずに済みます。

【第一報】社内向け
件名: [障害] 決済機能に影響が出ています（対応中）
- 発生時刻: 14:00頃〜
- 影響: 決済完了時にエラーが表示される場合があります（全体の約3割）
- 現状: 原因調査中。暫定対処として直前のリリースを切り戻し中です
- 次回更新: 14:30 または状況が変わり次第
- 対応チャンネル: #incident-20260902-payment
- 問い合わせ対応: 「現在対応中、復旧見込みは30分以内」とご案内ください

【復旧報】顧客向け
件名: 決済機能の不具合について（復旧済み）
本日14:00頃から14:15頃にかけて、決済完了時にエラーが表示される事象が発生しておりました。
現在は復旧しており、正常にご利用いただけます。
この間にエラーが表示された決済については、二重に課金されることはございません。
ご迷惑をおかけしましたことをお詫び申し上げます。
原因と再発防止策については、確認が完了次第あらためてご報告いたします。

顧客向けの文面では、技術的な詳細より「今使えるか」「二重課金などの実害はないか」「次にいつ連絡があるか」を優先します。SLAを結んでいる顧客には、契約で定めた報告期限と形式に従います（SLAとは？意味・書き方・具体例）。

ポストモーテム：非難しない（blameless）文化で原因を掘る

「誰が」ではなく「なぜその判断が合理的だったか」を問う

ポストモーテムの目的は、犯人を見つけることではなく、「同じ状況で誰がやっても同じ結果になる仕組み」を見つけて変えることです。「山田さんが設定を間違えた」で終わらせると、次に設定を間違えるのは別の人であり、再発は防げません。「なぜ間違えられる状態だったのか」「なぜレビューで気づけなかったのか」「なぜ本番に出る前にテストで検出できなかったのか」と、仕組みの側に問いを向けます。

これをblameless（非難しない）と呼びます。非難されないとわかっているからこそ、当事者は「実はこの手順が曖昧だった」「あの警告は以前から出ていた」といった、再発防止に本当に必要な情報を正直に話せます。逆に一度でも個人を責めれば、次の障害からは情報が出てこなくなります。

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

次の項目をそのまま社内のドキュメント（Notion、Confluence、リポジトリのMarkdownなど）に用意しておきます。障害から1週間以内、記憶が新しいうちに書きます。

# ポストモーテム: 決済API 5xx増加（2026-09-02）

## 概要（3行以内）
v2.14.0のデプロイ後、決済APIの約3割が500エラーを返した。
15分後にロールバックで復旧。影響を受けた決済は約120件、二重課金なし。

## 影響
- 期間: 2026-09-02 13:55〜14:15（20分）
- 影響範囲: 決済API（/api/checkout）。ログイン・閲覧は正常
- ユーザー影響: 決済失敗 約120件。うち再試行で完了 98件、離脱 22件
- SLOへの影響: 決済可用性のエラーバジェット 月間残量の35%を消費

## タイムライン（記録係のログから転記）
- 13:55 v2.14.0 本番デプロイ完了
- 14:02 5xx率アラート発報
- ...

## 根本原因
新バージョンで追加した決済プロバイダーAPIの呼び出しにタイムアウトが未設定で、
プロバイダー側の遅延時にワーカーが枯渇し、後続リクエストが500になった。

## なぜ検出できなかったか
- ステージングでは決済プロバイダーのモックを使っており、遅延を再現していなかった
- タイムアウト未設定を検出するlintルール・レビュー観点がなかった

## うまくいったこと
- アラートから7分で指揮体制が立ち、原因未確定でもロールバックを決断できた

## 改善できること
- ロールバック手順が口頭伝承で、担当者以外は実行できなかった

## アクションアイテム（担当・期限・チケット）
| 対策 | 担当 | 期限 | チケット | 状態 |
|---|---|---|---|---|
| 外部API呼び出しに共通タイムアウトを強制するHTTPクライアントラッパー導入 | 鈴木 | 9/16 | #412 | 未着手 |
| ステージングにプロバイダー遅延を注入するテストを追加 | 山田 | 9/23 | #413 | 未着手 |
| ロールバック手順をRunbook化しCIから1コマンドで実行可能にする | 田中 | 9/9 | #414 | 着手 |

「根本原因」の欄では、「なぜ」を最低3回繰り返して仕組みまで掘り下げます。上の例なら、「500が出た」→「ワーカーが枯渇した」→「外部APIの応答を無限に待った」→「タイムアウトを設定する仕組みがなかった」という具合です。タイムアウトの設計そのものはタイムアウト・リトライ・サーキットブレーカーで解説しています。

再発防止策の追跡：書いて終わりにしない

アクションアイテムは必ず「担当・期限・チケット」を付ける

ポストモーテムが形骸化する最大の原因は、対策が「気をつける」「注意して確認する」という行動の変化に頼った内容になることと、書かれた対策が誰にも追跡されないことです。対策は「仕組みの変更」（自動チェック、テスト、設定の強制、手順書）として書き、1つずつ担当者と期限を決め、通常の開発タスクと同じ課題管理システムにチケットとして登録します。

# GitHub Issueとして登録し、ラベルで追跡できるようにする例
gh issue create \
  --title "[postmortem-20260902] 外部API呼び出しの共通タイムアウト強制" \
  --label "postmortem,reliability" \
  --assignee suzuki \
  --milestone "2026-09" \
  --body "ポストモーテム: docs/postmortems/2026-09-02-payment-5xx.md
根本原因: 外部API呼び出しにタイムアウト未設定
対策: 全外部HTTP呼び出しを共通ラッパー経由にし、接続5秒/読み取り10秒をデフォルト強制する"

# 未完了の再発防止策を毎週確認する
gh issue list --label postmortem --state open

月に1回、未完了の対策を棚卸しする

再発防止策は、目の前の機能開発より優先度が下がりがちです。週次のチーム定例でpostmortemラベルの未完了Issueを確認する、期限を過ぎた対策はエラーバジェットの議論と同じ場で扱う、といった仕組みを作ると継続します。エラーバジェットとの関係はSLO・SLI・エラーバジェット入門を参照してください。

トラブル事例：全員が調査に没頭し、復旧が1時間遅れた

症状

本番DBのディスク使用率が100%に達し、書き込みがすべて失敗しました。エンジニア4人全員がSlackの雑談チャンネルで「ログを見る」「クエリを調べる」と各自で調査を始め、45分後にようやく「不要なログテーブルを削除して空きを作る」という暫定対処が実行されました。その間、経営層からの「どうなっているのか」という問い合わせに誰も答えられませんでした。

原因

役割分担がなく、全員が「原因の特定」を目指したため、「まず書き込みを復旧させる」という暫定対処の判断が誰にも委ねられていませんでした。実際には、ディスクが埋まった原因（監査ログの肥大化）は後から調べればよく、最初の5分で「一時的にログテーブルを退避して容量を空ける」または「ディスクを拡張する」という手を打てました。また記録係がいなかったため、後日のポストモーテムでタイムラインを復元するのに、各自のSlack履歴を突き合わせる作業が必要になりました。

対処

1. 障害検知時に最初に反応した人が指揮者になり、専用チャンネル#incident-YYYYMMDD-概要を立てるルールを定めた。
2. 指揮者は「調査担当1名、それ以外は暫定対処の準備」と最初に割り振り、15分以内に暫定対処を判断すると決めた。
3. 「ディスク逼迫」「DB接続枯渇」「デプロイ起因の5xx」など頻出パターンについて、暫定対処の手順書（Runbook）を用意した。
4. ディスク使用率80%でアラートするようにし、そもそも100%に達する前に対応できる状態にした。監視設定は監視とオブザーバビリティ入門を参照。

その後、同種の障害が起きた際は、検知から暫定対処まで12分で完了しました。技術力は変わっていません。変わったのは「型」だけです。

まとめ

インシデント対応は、検知→初動→影響範囲→暫定対処→恒久対策という段階を意識し、「直す」より「止める」を優先することで被害を最小化できます。指揮者と記録係を必ず置き、第一報は内容が固まる前に出す。ポストモーテムは非難せずに「なぜその状況が起こりえたか」を仕組みの側から掘り、対策は担当・期限・チケット付きで追跡する。この型を一度作っておけば、少人数のチームでも障害のたびに消耗せず、同じ障害を二度と起こさない組織に近づけます。

障害対応の体制づくりやRunbookの整備、監視とアラートの見直しは、Harmonic Societyのシステム開発・インフラ支援にご相談ください。