本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第12弾として、インシデント対応について解説する記事です。
インシデントは必ず起きます。起きないことを祈る設計は、起きてから崩れます。本記事では発見・検知・通知・対応・復旧・振り返りの一連プロセス、オンコール体制、Severity定義、ポストモーテム文化（GitLab 2017の教科書的事例）まで、速く気づき早く復旧する仕組み化を扱います。
本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。
この記事の結論
- 重要度（SEVレベル）で対応体制を切り替える
- ポストモーテムはBlameless（個人を責めない）で学習に徹する
- Runbookをコード化し、オンコール負荷はアラート削減で下げる
この記事を読む前に
本記事は開発・テスト・リリース・監視といった、サービスを作って動かし続ける工程の話が中心です。IT用語にあまり馴染みがない方は、基礎編の「開発から運用までの流れ」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもインシデント対応とは何か
消防署の出動体制を想像してください。火事はいつ起きるかわかりませんが、消防署には24時間体制の当番・出動手順・担当エリアの地図・過去の火災記録が整備されています。個人の勇敢さではなく、仕組みで確実に消火するのが消防署の強さです。
インシデント対応はシステム運用における消防署です。障害や異常事態が起きた時に、検知・通知・初動対応・復旧・振り返りまでの一連のプロセスを仕組み化する活動です。誰が当番でも一定品質で動けるプロセス・ツール・訓練を持ち、同じ障害を二度起こさない学習のサイクルを回します。
もしインシデント対応の仕組みがなければ、障害のたびにベテランが徹夜で英雄的に直す頼みになります。その人が休暇中なら復旧は何時間も遅れ、同じ障害が何度も繰り返されます。
なぜインシデント対応が必要か
第一に、対応の遅れが被害を拡大するからです。1分のダウンが数万人に影響するSaaSでは、対応の1分が数百万円の損失に直結します。第二に、属人化は再現性を失うからです。「ベテランが徹夜で直した」系の対応は、次回同じ人がいないと崩壊します。第三に、インシデント対応の真の目的は再発防止だからです。1回のインシデントから学んだ教訓をシステム改善に反映できるかが分かれ目です。
インシデント対応のフェーズと重要度レベル
インシデント対応は、Detection（検知）→Triage（初期評価）→Response（対応）→Communication（連絡）→Resolution（復旧）→Post-mortem（事後検討）の6フェーズに分けて設計します。各フェーズで明確な責任者・手順を持つことで、属人性を減らせます。
全障害を同じ熱量で対応すると人材が消耗するため、深刻度（Severity）で対応体制を切り替えるのが必須です。
| レベル | 内容 | 対応 |
|---|---|---|
| SEV 1 | 全停止・重大データ損失 | 全員集合・24時間対応 |
| SEV 2 | 主要機能の障害 | オンコール + SRE 即対応 |
| SEV 3 | 一部機能の障害 | 業務時間内に対応 |
| SEV 4 | 軽微な不具合 | 通常のバックログ |
重要度の判定基準を事前に文書化しておかないと、現場判断でバラついて混乱します。なお全アラートがインシデントではありません。自動回復するものは記録のみ、業務時間内対応で済むものはチケット化し、即対応が必要なものだけインシデント宣言する──宣言は「通常運用を止めて集中する」スイッチを入れる明示的な行為です。
オンコール体制とコマンドセンター
オンコールは消防署の当番制と同じ考え方です。週次〜2週次のローテーションで24/7対応の当番を決め、プライマリ・セカンダリの2段階バックアップを置き、一次応答SLA（何分以内か）と夜間・休日の手当を定めます。オンコールは負担が大きいため、アラート削減・自動復旧で呼び出し頻度を下げるのがSREの継続的努力です。月2回以上の深夜呼出は過剰負荷のサインです。
重大インシデント（SEV 1〜2）では、役割を分けたIncident Command Centerを立ち上げます。Incident Commander（IC）が全体指揮・判断、Operations Leadが技術対応、Communications Leadが顧客・社内連絡、Scribeがタイムライン記録を担当します。ICは技術判断をしないのが重要で、全体の状況把握と意思決定に専念し、技術調査はOperations Leadに任せる分業が効率的です。
情報伝達は対応そのものと同じくらい重要です。対応チームにはSlackチャンネルで技術詳細を、経営層には影響範囲と復旧見込み（ETA）を、顧客にはステータスページ（Statuspage.io等）で状況を、サポートにはFAQと回答テンプレを──誰に・何を・いつ伝えるかを事前に決めておかないと、情報がバラバラになり信頼を失います。
ポストモーテムとRunbook
インシデントが収束したら、必ず振り返りを行うのがGoogle SREの鉄則です。概要・タイムライン・根本原因・緩和策・再発防止策・改善アクション（Who by When）を文書化し、組織の資産にします。大原則は人を責めない（Blameless）こと。個人の過失ではなく、システム・プロセスの欠陥として扱います。
根本原因分析（RCA）では「なぜ」を5回繰り返す5 Whysが有名です。
症状: DBが落ちた
├─ なぜ? 接続数が溢れた
├─ なぜ? 新機能でコネクションリークがあった
├─ なぜ? コードレビューで気づかれなかった
├─ なぜ? レビュー観点に「接続管理」が無い
└─ なぜ? レビューガイドが古いまま真の原因は「コードバグ」ではなくレビュー文化の欠陥という結論になり、それが改善対象になります。
Runbookは典型的なインシデント対応手順の文書化です。発報条件・初動チェック・診断手順・復旧コマンド・エスカレーション基準を書いておき、誰でも同じ品質で対応可能にします。Gitリポジトリ等に置き、アラートから直接リンクされるようにするのが標準運用です。
3つのシナリオで考える
個人開発・小規模社内ツールの場合
UptimeRobotとメールやSlackの通知だけで十分だと思います。オンコール制度は不要で、業務時間の対応で問題ありません。RunbookはNotionに簡易版を置いておき、個人の知識を文書化して属人化だけ防いでおきましょう。
中小SaaS企業の場合
PagerDutyにStatuspage.io、Slackチャンネルという組み合わせの段階です。オンコールは2〜3名の週次ローテーションにして、BlamelessなポストモーテムをGoogle Docsで運用します。SEV基準はSEV 1／2／3の3段階に絞ってシンプルにしておくのがコツです。チームが成長してきたら、Runbook as Code（Git管理でPRレビュー）と四半期ごとのゲームデー訓練（障害演習）を追加していきます。
大企業・グローバルの場合
ServiceNowやJira Service Managementに、地域を跨いで昼勤帯をリレーするFollow-the-Sunのオンコール体制、AIOpsまで組み合わせる形になります。SEV 1は経営層まで自動通知して、地域別オンコール（東京・欧州・北米）でハンドオフし、規制当局への報告プロセスも組み込んでおく必要があります。
インシデント対応の数値Gate・SLA
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
インシデント対応は「何分で何をするか」を数値で定義しないと機能しません。以下が業界定番のSLAです。
| 指標 | SEV 1 | SEV 2 | SEV 3 | SEV 4 |
|---|---|---|---|---|
| 一次応答（MTTA） | 5分以内 | 15分以内 | 1時間以内 | 翌営業日 |
| 復旧（MTTR）目標 | 1時間以内 | 4時間以内 | 1日以内 | 1週間以内 |
| 通知チャネル | PagerDuty + 電話 | PagerDuty | Slack | Jira |
| ポストモーテム | 必須（1週間以内） | 必須（2週間以内） | 任意 | 不要 |
| ステータスページ | 即更新 | 更新 | 必要に応じて | 不要 |
オンコール健全性の指標として、月2回以上の深夜呼び出しは過剰負荷のサイン、アラート発報の50%以上が誤検知ならアラート棚卸し、再発率10%超えはポストモーテムの質を見直します。一次応答5分以内は信頼性の命綱で、Runbookとオンコール体制で仕組み化します。
AI判断軸 ― 初動とポストモーテムをAIに委ねる
AIによる障害対応の初動自動化
障害発生時の初動（影響範囲の特定・関連ログの収集・直近のデプロイ変更の洗い出し）は、AIが自動化できる領域です。PagerDutyやOpsgenieのアラートをトリガーに、AIが以下を自動実行する構成が普及しつつあります。
人間のオンコールエンジニアが覚醒して状況を把握するまでの数分間をAIがカバーすることで、MTTRを短縮できます。前提はRunbookがコード（Markdown + スクリプト）で管理されていることです。
ポストモーテムのドラフトをAIが生成する
障害対応後のポストモーテム作成は、タイムラインの構築・影響範囲の整理・根本原因の記述に時間がかかる作業です。障害対応中のSlackログ・アラート履歴・デプロイログをAIに渡し、ドラフト（タイムライン・影響範囲・直接原因・根本原因・アクションアイテム案）を自動生成する運用は、記述負荷を大幅に下げます。人間はAI生成のドラフトをレビューし、正確性の確認とアクションアイテムの優先度付けに集中する形になります。
やってはいけないこと
インシデント対応で事故る典型を、特に危険な6つに絞ります。どれも再発率を高める・組織を疲弊させる結果を招きます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| ポストモーテムで犯人探し | 情報隠蔽の温床、次の障害が見えなくなる → Blamelessを鉄則にする |
| ベテラン1人に全部任せる | 退職・休暇で崩壊し組織の対応力が育たない → Runbook化 + ローテーション |
| SEV基準を現場判断に委ねる | 重要度がバラつき対応体制が混乱 → 判定基準を事前文書化する |
| ICが技術調査もする | 全体把握ができず対応遅延 → 指揮と調査を分業する |
| ポストモーテムを書いて終わり | 同じ障害が3か月後に再発 → アクションアイテムに期限と担当を付けて追跡する |
| ステータスページを更新しない | 問い合わせ殺到・信頼失墜 → SEV 1は即更新をルール化する |
なお「再発防止策を全部やる」と欲張るのも失敗パターンです。リソースが分散して全部中途半端になるため、最も効果の高い1〜2施策に絞ります。
筆者メモ — 隠さなかったGitLabと、隠したUber
2017年1月31日のGitLab DB削除事件（エンジニアが本番と開発を取り違えて rm -rf、5種類のバックアップのうち4種が機能せず）は、復旧作業のライブ配信 + 詳細ポストモーテムの全公開という「隠さず学ぶ」姿勢が業界で高く評価された事例です。事故そのものより、その後の透明性がBlameless文化の教科書になりました。
対照的にUber 2016年データ流出は、当初事実を隠蔽し、攻撃者に10万ドルを払って口封じした結果、後の訴訟で1.48億ドルの和解金に発展しました。隠蔽の代償は事故そのものよりはるかに大きい──インシデントは起きる前提で、仕組みと文化で受け止める準備が全てです（詳細は付録「重大インシデント事例集」）。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 重要度基準（SEV 1〜4の定義）
- オンコール体制（ローテーション・SLA）
- 通知ツール（PagerDuty / Opsgenie）
- コマンドセンターのルール（宣言基準・役割）
- ステータスページ（顧客への情報発信）
- ポストモーテム規定（Blameless・公開範囲）
- Runbook管理方法（場所・更新ルール）
この記事に関連する記事
まとめ
本記事はインシデント対応について、フェーズ・SEVレベル・オンコール・コマンドセンター・Blamelessポストモーテム・Runbook・AIOpsまで含めて解説しました。如何だったでしょうか。
重要度で体制を切り替え、オンコール負荷をアラート削減で下げ、Blamelessポストモーテムで学習し、RunbookをコードでAIに委ねる。これが2026年のインシデント対応の現実解です。
次回はSREプラクティス（Toil削減・カオスエンジニアリング）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は PagerDuty も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（71/95）