インシデント対応 ― 英雄ではなく仕組みで収束させる ― 生成AI時代のアーキテクチャ超入門

flowchart LR
    D[Detection<br/>検知<br/>監視/アラート] --> T[Triage<br/>初期評価<br/>深刻度判定]
    T --> R[Response<br/>対応<br/>緩和・復旧]
    R --> C[Communication<br/>連絡<br/>ステークホルダー]
    C --> RES[Resolution<br/>復旧<br/>根本原因除去]
    RES --> PM[Post-mortem<br/>事後検討<br/>振り返り・再発防止]
    PM -.|学びを反映| D
    classDef detect fill:#fee2e2,stroke:#dc2626;
    classDef respond fill:#fef3c7,stroke:#d97706;
    classDef comm fill:#dbeafe,stroke:#2563eb;
    classDef recover fill:#dcfce7,stroke:#16a34a;
    classDef learn fill:#fae8ff,stroke:#a21caf;
    class D,T detect;
    class R respond;
    class C comm;
    class RES recover;
    class PM learn;

フェーズ	内容
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 等でルーチン対応を自動化します。

よくある勘違い

ベテランが直せば早い

「システムに一番詳しい一人が夜中に全部直す」という働き方は、短期的には最速に見えます。ところがその人が転職した翌週に同じ症状の障害が出て誰も手が出せず、顧客への一次応答に3時間かかった、という事例は現場で繰り返し語られています。属人化は失うときに一番コストが高い働き方で、誰でも同じ手順で動ける仕組みが長期的には強い、という教訓です。

ポストモーテムで犯人探し

最悪のアンチパターン。Blamelessが鉄則。犯人探しが始まると誰も正直に話さなくなります。

再発防止策を全部やる

リソースが足りない。優先順位を付ける。影響大・再発率高いものから。

SEV1は滅多に起きない

定期的に訓練しないといざという時に動けない。ゲームデーで訓練します。

インシデント対応の数値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）が技術調査もする	全体把握ができず、対応遅延

2017年1月31日の GitLab DB削除事件（エンジニアが本番と開発を取り違えて rm -rf、5種類のバックアップ全滅）は、復旧作業のライブ配信 + 詳細ポストモーテム公開という隠さず学ぶ姿勢が評価された事例。対照的に Uber 2016年データ流出（当初隠蔽、攻撃者に10万ドル払って口封じ → 後の訴訟で1.48億ドル和解金）は、隠蔽の代償の大きさを示しました。

インシデントは起きる前提。仕組みと文化で受け止める準備が全てです。

AI時代の視点

AI 駆動開発（バイブコーディング）と AI 活用が前提になると、インシデント対応はAIエージェントが一次対応する領域に進化しつつあります。Datadog Bits AI・PagerDuty AIOps・Resolve AI 等が初期トリアージ・根本原因候補の提示を自動化しています。

AI時代の変化	内容
初期診断の自動化	AIがログ・メトリクスを分析
Runbookの自動実行	AIがよくある対応を自動実施
ポストモーテム草稿	AIがタイムラインを生成
異常予測	障害前に兆候検知

人間は重大な判断と再発防止に集中し、ルーチンの一次対応は AI に委ねる分業が始まっています。Runbook をコード化・構造化しておくと、AI が自動実行できる未来が近いです。

AI 時代はルーチン対応をAIに、判断と学習を人間に分業します。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

重要度基準（SEV 1〜4の定義）
オンコール体制（ローテーション・SLA）
通知ツール（PagerDuty／Opsgenie）
コマンドセンターのルール（宣言基準・役割）
ステータスページ（顧客への情報発信）
ポストモーテム規定（Blameless・公開範囲）
Runbook管理方法（場所・更新ルール）

最終的な判断の仕方

インシデント対応の核心は個人の英雄ではなく、仕組みで収束させるという発想です。誰が当番でも一定品質で動ける Runbook・オンコール・コマンドセンターを持ち、重要度別に対応体制を切り替えるのが現代の設計です。ベテラン依存の対応は短期的に速くても、長期的には属人化・知識流出・燃え尽きの温床になります。Blameless ポストモーテムで1回の障害から最大の学びを引き出し、再発防止に還元する学習サイクルを回すのが最大の価値を生みます。

もう一つの決定的な軸はAIエージェントが一次対応、人間は判断と学習という分業です。Datadog Bits AI・PagerDuty AIOps・Resolve AI がログ解析・根本原因候補提示・Runbook 自動実行を担う時代に、人間の付加価値は重大判断と再発防止の設計に集中します。そのためには Runbook をコード化・構造化し、AI が読んで実行できる形で整備しておくことが前提になります。

選定の優先順位

重要度で対応体制を切り替える — SEV 1〜4を事前文書化、全障害を同じ熱量で対応しない
オンコール負荷をアラート削減で下げる — 月2回以上の深夜呼出は過剰負荷、自動復旧で予防
Blamelessポストモーテムで学習する — 犯人探し禁止、システム・プロセスの欠陥として扱う
Runbookをコード化してAIに委ねる — ルーチン対応はAI、判断と再発防止に人間を集中

「英雄ではなく仕組みで収束させる」ルーチンは AI に、判断と学習を人間に任せます。

まとめ

本記事はインシデント対応について、フェーズ・SEVレベル・オンコール・コマンドセンター・Blamelessポストモーテム・Runbook・AIOpsまで含めて解説しました。如何だったでしょうか。

重要度で体制を切り替え、オンコール負荷をアラート削減で下げ、Blamelessポストモーテムで学習し、RunbookをコードでAIに委ねる。これが2026年のインシデント対応の現実解です。

次回はSREプラクティス（Toil削減・カオスエンジニアリング）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。