障害対応の手順とポストモーテムの書き方｜一次対応から再発防止まで

障害対応とポストモーテムの基本

障害対応とポストモーテムは地続きですが、目的が違います。前者は止血、後者は学習です。ここを混ぜると、対応中に原因究明を始めて復旧が遅れたり、振り返りが犯人探しになったりします。

障害対応（インシデント対応）とは

障害対応とは、サービスに影響が出ている（または出そうな）事象を検知し、影響を最小化して正常状態に戻す活動です。ゴールは原因の特定ではありません。ユーザー影響を止めることが最優先で、原因究明はその後に回します。

この順序を取り違える現場は、驚くほど多いです。ログを読み込んで原因を突き止めてから直そうとすると、その間ずっとサービスは落ちたままになります。ロールバックで5分で戻せるなら、まず戻す。理由は後から調べられます。

ポストモーテムとは｜障害報告書との違い

ポストモーテム（postmortem）は、障害の事後分析ドキュメントです。時系列・影響・要因・再発防止策を記録し、組織の学習資産にします。

障害報告書と混同されがちですが、読み手と目的が異なります。

両方を求められる現場もあります。その場合はポストモーテムを先に書き、そこから顧客向けの報告書を起こすと手戻りが減ります。

ポストモーテムを書く基準（トリガー）

全障害に書いていては続きません。だからこそ、事前に基準を決めておくことが要になります。Google SRE Book の Postmortem Culture 章では、トリガーの例として次を挙げています。

• ユーザーに見えるダウンタイムや、一定のしきい値を超える品質低下

• 種類を問わないデータ損失

• オンコール担当者による介入（リリースのロールバック、トラフィックの切り替え等）

• 一定のしきい値を超える復旧時間

• 監視の失敗（＝障害を人手で発見してしまったケース）

あわせて、誰でもポストモーテムの作成を要求できる、とも書かれています。監視の失敗がトリガーに入っているのが示唆的です。「気づけなかったこと」自体を障害として扱う発想は、日本の現場では抜けがちな観点でしょう。

ミニFAQ：軽微な障害でもポストモーテムは必要ですか

基準を満たさないなら不要です。ただし同じ軽微障害が月3回以上繰り返すなら、まとめて1本書く価値があります。頻度そのものが問題の兆候だからです。

障害対応の全体フロー｜検知から収束までの5段階

結論として、障害対応は5段階に分けて考えます。段階を明示すると「今どこにいるか」が共有でき、指示待ちの時間が減ります。

1. 検知

監視アラート、ユーザーからの問い合わせ、他チームからの連絡のいずれかで始まります。理想は監視による検知です。問い合わせで気づいた時点で、監視設計に穴があります。

検知基盤そのものについては、OpenTelemetryとは｜可観測性標準の仕組み・導入の流れ・案件動向やDatadogとは｜統合監視SaaSの特徴・Sentryとの違い・案件単価を徹底解説で整理しています。

2. 一次対応

事実確認、影響範囲の特定、暫定復旧の判断を行います。ここが最も差が出る局面です。詳細は次章で扱います。

3. エスカレーションと体制づくり

自分で復旧できないと判断したら、速やかに人を呼びます。判断基準を持っておくと躊躇がなくなります。

• 15分試して復旧の見通しが立たない

• 影響範囲が自分の担当領域を越えている

• データ損失の可能性がある

• 顧客対応や広報判断が必要になりそう

規模が大きい障害では役割を分けます。PagerDutyのIncident Responseドキュメントでは、指揮を執るIncident Commander、その代理となるDeputy、記録を残すScribe、技術面を担うSubject Matter Expert、社外対応のCustomer Liaison、社内調整のInternal Liaisonという役割が定義されています。

小規模チームで全役割を置くのは非現実的ですが、「指揮」と「記録」だけは別の人が持つと対応の質が変わります。手を動かす人が同時に記録も取るのは、まず無理です。

4. 復旧

暫定対処と恒久対処を区別します。暫定は「今の出血を止める」措置で、恒久は「同じ出血を起こさない」措置です。

暫定で止めたまま恒久対処を忘れる。これが最もよくある負債の作り方です。

5. 収束宣言

「終わった」を明示的に宣言します。宣言がないと、関係者はいつまでも張り付いたままになります。宣言時には、影響が止まったこと・残っている暫定措置・次のアクションの3点を伝えます。

一次対応の型｜最初の15分で決めること

一次対応は時間との勝負です。だからこそ、考えることを減らす型が要ります。

以下の時間は、本記事が実務の進め方として整理した目安です。公的な標準や特定フレームワークが定めた基準ではなく、SLAや契約上の義務でもありません。システムの特性や契約内容によって適切な間隔は変わるため、現場の運用規程がある場合は必ずそちらを優先してください。

この表は、時間軸ごとの到達点を1枚にまとめたものです。手元に置いておくと、対応中に次を考える負荷が下がります。

最初の5分：事実を確定する

やることは3つだけです。

1. アラートが本物か確認する。 監視の誤検知は珍しくありません。実際にサービスに触って再現するかを見ます

2. 一次応答を出す。 「私が見ています」の一言をチャンネルに流します。これがないと複数人が同じ調査を始めます

3. 開始時刻を記録する。 後でタイムラインを書くとき、ここが起点になります

短くていい。「◯◯のアラート、確認中です」で十分です。

5〜15分：影響範囲と暫定復旧を判断する

次に、誰が・何を・どの程度できなくなっているかを確定します。全ユーザーか一部か。書き込みだけか参照もか。代替手段はあるか。

影響範囲が固まったら、暫定復旧の可否を判断します。判断材料はシンプルです。

• 直前にリリースがあったか → あればロールバックを第一候補にする

• 特定のノード・リージョンに閉じているか → 閉じていれば切り離す

• 負荷起因か → スケールアウトや流量制御を検討する

• どれにも当てはまらない → エスカレーションする

そして初報を出します。初報に原因は不要です。「何が起きていて、いつ次の報告をするか」だけ書きます。

やってはいけないこと

• 黙って調べ続ける。 15分無言の調査は、周囲から見れば「対応していない」のと同じです

• 原因を特定してから直そうとする。 止血が先、解剖は後です

• 復旧を優先して証拠を消す。 再起動の前に、可能な範囲でログとメトリクスのスナップショットを取ります。消えた証拠は戻りません。ただし影響が拡大している最中に保全を優先すべきではなく、ログが外部基盤に転送済みの構成なら手元での退避は不要です。保全にかかる時間と被害の拡大を見比べて判断します

• 推測を確定情報として報告する。 「たぶんDBです」が独り歩きし、無関係なチームが動き出します

ミニFAQ：一次対応中、原因調査は一切してはいけないのですか

いいえ。暫定対処の選択肢を絞るための調査は必要です。禁じ手は「根本原因が判明するまで手を打たない」という進め方です。目的が止血なら調べてよく、目的が解明なら後回しにします。

原因究明の進め方｜タイムラインから掘る

収束したら原因究明に移ります。ここでの結論は、要因分析より先にタイムラインを作るです。順序を逆にすると、思い込んだ原因に合う事実だけを拾ってしまいます。

まずタイムラインを作る

時刻・出来事・情報源の3列で、淡々と並べます。解釈は入れません。

情報源の列が効きます。「たしか15分くらいだった」という記憶ベースの記述が混ざらなくなるからです。

単一の根本原因に決めつけない

大きな障害に原因が1つだけ、ということはまずありません。デプロイが引き金でも、テストで検知できなかったこと、カナリアリリースがなかったこと、アラートのしきい値が緩かったこと、これらすべてが寄与要因です。

「なぜ」を5回繰り返す手法は有名ですが、1本道で掘ると分岐を取りこぼします。なぜを木構造で広げるほうが実態に合います。Atlassianのインシデントポストモーテム解説でも、複数の寄与要因を扱う考え方が整理されています。

「人為ミス」で止めない

「担当者が設定を間違えた」は原因ではありません。そこで止めると、対策が「気をつける」になります。一段掘ります。

• なぜ間違えられる設計だったのか

• なぜレビューで気づけなかったのか

• なぜ適用前に検証する仕組みがなかったのか

• なぜ間違いが即座に本番へ反映されたのか

人ではなく仕組みに着地させると、対策が具体物になります。

ポストモーテムの書き方｜7項目テンプレート

結論、7項目あれば足ります。長さより、埋まっていることのほうが大事です。1ページで構いません。

項目5を軽視しないでください。うまくいったことを書き残すのは、次の障害で同じ判断を再現するためです。ロールバックが4分で完了したなら、それは仕組みが機能した証拠であり、記録する価値があります。

blameless（非難しない）で書く

Google SRE Bookは、blamelessに書かれたポストモーテムを「関係者全員が善意で、その時点で持っていた情報のもとに正しいことをしたと想定する」ものと説明しています。焦点は、個人やチームを非難せずに寄与要因を特定することに置かれます。

書き分けは、主語を人から事象・仕組みに移すだけです。

右列は責任の所在を曖昧にしているのではありません。修正できる対象に言い換えています。人は直せませんが、仕組みは直せます。

レビューを必ず通す

同書は「レビューされないポストモーテムを残さない」ことを原則に挙げ、定期的なレビュー会で議論を閉じ、アイデアを拾い、文書を確定させる運用を示しています。シニアエンジニアのレビュー後、エンジニアリング組織全体へ共有する流れです。

書きっぱなしのドキュメントは、3か月後には誰にも読まれません。レビューの場を設けることは、形骸化を防ぐ最も有効な対策の1つです。検索できる場所への集約やテンプレートの統一と組み合わせると、さらに効きます。

ミニFAQ：ポストモーテムはどのくらいの分量が適切ですか

1ページで十分です。分量より頻度と鮮度が効きます。詳細な報告書を年1回書くより、短いものを都度残すほうが資産になります。

再発防止アクションを実行に乗せる

ポストモーテムが形骸化する最大の理由は、アクションが実行されないことです。原因は決まっていて、オーナーと期限がないからです。

オーナーは1名、期限は30日以内

チーム名をオーナーにすると、誰も着手しません。個人名を1つ書きます。期限は30日以内を目安にします。それ以上先の期限が必要なアクションは、たいてい粒度が大きすぎます。分割してください。

実行可能な粒度に落とす

• 避けたい例：監視を強化する

• 望ましい例：注文APIのエラー率が5分平均で1%を超えたらアラートを発報する設定を追加する（オーナー：◯◯／期限：◯月◯日）

前者は永遠に終わりません。後者は完了判定ができます。

定期的に棚卸しする

アクションの一覧をチームで定期的に見直します。週次のふりかえりに5分だけ枠を取れば足ります。期限切れが積み上がり始めたら、それ自体が「ポストモーテムが機能していない」という信号です。

なお、再発防止の実装はSREやプラットフォーム領域の仕事と重なります。役割の全体像はSREとは？仕事内容・年収・必要スキルとDevOpsとの違いをエンジニア視点で解説、プラットフォームエンジニアとは｜仕事内容・年収・SRE/DevOpsとの違いで整理しています。

フリーランスが障害対応で押さえる契約・稼働の論点

ここからは外部人材としての観点です。社員と同じ動きをしていると、責任範囲と稼働の両面で損をすることがあります。

準委任契約で負うのは善管注意義務

準委任契約で受任者が負うとされるのは善管注意義務（善良な管理者の注意をもって業務を処理する義務）です。民法は委任契約について民法644条でこれを定めており、準委任には656条により準用されます。一般に、請負のような仕事の完成義務とは性質が異なるものと整理されます。

一方、請負契約は仕事の完成を目的とし、契約不適合責任を負うのが原則です。両者の違いは準委任契約と請負契約の違い｜フリーランスエンジニアが知るべきリスクと注意点で詳しく扱っています。

ここで重要な留保があります。上記はあくまで民法上の原則的な整理であり、実際にどこまでの責任を負うかは個別の契約内容で決まります。契約書の名称が「準委任」でも、実質的な内容や特約によって扱いが変わることがあります。SLA・損害賠償の上限・免責範囲・オンコール義務の有無は、契約書と発注書の条項次第です。

また、契約類型の判断や個別条項の効力は法的な評価を伴うため、本記事の内容だけで自己判断しないでください。気になる条項があれば締結前に確認し、責任範囲や賠償条項に不安がある場合は弁護士等の専門家に相談することをおすすめします。

オンコール・深夜対応と精算幅の関係

障害対応は稼働時間が読めません。そのため、契約上の扱いを事前に握っておく必要があります。確認すべきは次の点です。

• 時間外・深夜・休日の対応が契約に含まれるのか、別途手当があるのか

• オンコール待機そのものに手当が付くのか、実対応時間のみの計上か

• 障害対応分の時間が、準委任の精算幅（例：140〜180時間）の対象時間に含まれるのか

3つめは見落としやすい論点です。精算幅の考え方は準委任の精算幅とは｜140-180hの意味と超過・控除の計算方法で解説しています。手当や単価の実情は運用保守・オンコール案件のフリーランス実情｜単価相場・手当・契約、SREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安にまとめてあります。

自分がどの程度の単価を狙えるか確認したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。単価の上げ方を体系的に整理したい場合は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？も参考になります。

参画時に確認する8項目チェックリスト

オンコールに入る前、できれば参画から1週間以内に確認しておきます。

1. 障害のレベル定義（SEV-1〜3等）と、それぞれの連絡先・連絡手段

2. エスカレーション先と、その連絡がつく時間帯

3. ランブック（障害時の手順書）の所在と、最終更新日

4. 本番環境への自分の権限範囲（どこまで自己判断で操作してよいか）

5. ロールバックの手順と、実行に必要な承認

6. 監視ダッシュボードとアラートの通知先

7. 顧客への連絡は誰が行うか（自分が窓口になることはあるか）

8. ポストモーテムを書く文化があるか、テンプレートは存在するか

3の「最終更新日」が要点です。1年以上更新されていないランブックは、そのまま信じると事故になります。参画直後に気づいた古い記述を直すのは、信頼を得る近道でもあります。立ち回り全般はフリーランス常駐で評価される立ち回り｜参画後の行動と契約継続のコツを参照してください。

blameless文化がない現場での書き方

理想を説いても、明日の現場は変わりません。責任追及の空気がある環境では、次の順で進めると角が立ちにくくなります。

• 事実（タイムライン）と解釈（要因分析）を、見出しレベルで明確に分ける

• 人名を書かず、役割名（リリース担当、オンコール担当）で記述する

• 「うまくいったこと」の項目を必ず設け、機能した仕組みを先に挙げる

• 対策は個人の行動変容ではなく、仕組みの変更として提案する

外部人材の立場だからこそ、しがらみなく仕組みの話に寄せられる面があります。そこは強みとして使えます。

ミニFAQ：参画したばかりで、過去の障害の経緯がわからない状態でオンコールに入るよう言われました

断る前に、過去3か月のアラート履歴とポストモーテム（あれば）を見せてもらうよう依頼してみてください。それが提供されない、ランブックもないという状態なら、オンコール参加の時期をずらす交渉には十分な理由があります。

ケース別の関わり方

常駐で運用チームの一員として入る場合

社員とほぼ同じ動きを求められます。だからこそ、権限範囲と手当の扱いを最初に明文化しておくことが重要になります。

フルリモート・週2〜3日稼働の場合

稼働日外のアラートをどう扱うかが最大の論点です。「稼働日外は一次対応をしない」のか「電話のみ受ける」のかを決めておきます。曖昧なまま始めると、実質的に24時間待機になりがちです。

開発案件で、自分が作った機能の運用も見る場合

開発と運用が地続きになるため、ポストモーテムを書く側になる可能性が高くなります。自分の実装が引き金になったケースでも、blamelessの原則は自分自身にも適用します。自責的に書きすぎると、仕組みの問題が見えなくなります。

よくある失敗と対策

復旧を焦って証拠を消す

再起動やコンテナの入れ替えでログが揮発し、原因究明が不可能になる。復旧操作の前にログとメトリクスを退避できないかを一度確認する習慣をつけます。ログ基盤へ転送済みの構成なら不要ですし、被害が広がっている局面では復旧を優先すべき場面もあります。判断の分かれ目は、保全に何分かかるかです。

報告が途絶える

対応に集中するあまり、30分以上無言になる。周囲の不安は増幅し、確認の割り込みが入って余計に遅れます。タイマーを30分でセットし、進展がなくても「進展なし、継続調査中」と流します。

ポストモーテムが反省文になる

謝罪と決意表明で埋まり、再現性のある知見が残らない。テンプレートの項目を埋める形式にすれば、構造的に防げます。

アクションが完了しない

期限とオーナーがない、または粒度が大きすぎる。完了判定ができる粒度まで割ります。

同じ障害を繰り返す

前回のポストモーテムが検索できない場所にある、という単純な理由がほとんどです。障害の種類でタグ付けし、検索できる場所に集約します。

障害対応・ポストモーテム実践チェックリスト

対応中に上から順に確認できるよう並べました。

検知〜一次対応

• アラートが誤検知でないことを確認したか

• 一次応答（誰が見ているか）を5分以内に出したか

• 開始時刻を記録したか

• 影響範囲（対象・機能・程度）を特定したか

• 初報を15分以内に出したか

• 復旧操作の前に、可能な範囲でログとメトリクスを保全したか（外部基盤へ転送済みなら不要）

エスカレーション〜復旧

• 15分で見通しが立たない場合、エスカレーションしたか

• 指揮役と記録役を分けたか（規模が大きい場合）

• 暫定対処と恒久対処を区別したか

• 30分間隔で定時報告を出したか

• 収束を明示的に宣言したか

ポストモーテム

• 48〜72時間以内に初稿を書いたか

• タイムラインに情報源を併記したか

• 単一原因で締めず、寄与要因を複数挙げたか

• うまくいったことも記録したか

• 全アクションにオーナー（個人名）と期限を付けたか

• 1週間以内にレビューを完了したか

• 検索できる場所に保存したか

まとめ

障害対応は「止血が先、解剖は後」。ポストモーテムは「人ではなく仕組みに着地させる」。この2点を押さえれば、大きく外しません。

• 対応フローは検知・一次対応・エスカレーション・復旧・収束宣言の5段階で回す

• 5分以内に一次応答、15分以内に初報、以後30分間隔で定時報告を目安にする

• 復旧操作の前に、可能な範囲でログとメトリクスを保全する。消えた証拠は戻らない

• ポストモーテムは収束から48〜72時間以内に初稿、1週間以内にレビューを完了する

• 7項目テンプレートを使い、うまくいったことも必ず記録する

• 再発防止アクションにはオーナー1名と30日以内の期限を付ける

• フリーランスは参画1週間以内に、責任範囲・権限・手当・ランブックの4点を確認しておく

次のアクションとしては、参画中の案件でランブックの最終更新日を確認するところから始めるのが手軽です。更新が止まっていれば、それ自体が改善提案の種になります。運用保守やSRE領域の案件を探している場合は、インフラエンジニアの案件一覧も確認してみてください。

参照した一次情報

• Google SRE Book - Postmortem Culture: Learning from Failure

• Google SRE Workbook - Postmortem Culture

• PagerDuty Incident Response Documentation

• Atlassian - Incident postmortem

• 民法（e-Gov法令検索）