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