重大インシデント対応プレイブック
社内システムの 重大インシデント発生時に、検知から事後対応までを定型化して進めるためのプレイブックです。日常のヘルプデスク事例とは別の、業務影響が大きい事案を扱います。
📋 想定環境 / 用途
| 項目 |
想定 |
| 想定読者 |
IT 管理者・社内SE・運用責任者 |
| 適用範囲 |
業務影響が複数ユーザー or 1 部署以上に及ぶ事案 |
| 補足 |
単一ユーザーの問い合わせは 障害対応事例集 を参照 |
🚨 インシデント重大度（Severity）の定義
| Sev |
定義 |
例 |
初動目標時間 |
| P1 |
全社業務停止または重大なデータ漏洩リスク |
メールサーバ全停止、ランサムウェア検知、認証基盤ダウン |
検知から 15 分以内に対応開始 |
| P2 |
1 部署以上の業務停止、または重要システムの著しい劣化 |
営業部のファイルサーバ不可、特定店舗の VPN 切断 |
30 分以内 |
| P3 |
複数ユーザーに影響する継続性ある不具合（業務継続は可能） |
印刷キュー詰まり全社、特定アプリの認証遅延 |
1 時間以内 |
| P4 |
個別ユーザーの問い合わせレベル |
1 名のメール不可、PC 不調 |
通常チケットフロー |
👥 役割分担（インシデント体制）
P1〜P2 で発動します。1 名で兼務することもありますが、役割を明示することが重要です。
| 役割 |
主な責務 |
| Incident Commander (IC) |
全体指揮、優先順位決定、エスカレーション判断 |
| Tech Lead |
技術的な原因調査・復旧作業の主担当 |
| Communications (Comms) |
経営層・関係部署・ユーザーへの状況報告 |
| Scribe（記録係） |
時系列記録、後の事後分析（ポストモーテム）の元資料作成 |
⏱ 標準タイムライン（P1 想定）
T+0:00 検知（監視アラート / ユーザー報告）
T+0:05 IC 任命、Sev 判定、Slack/Teams インシデントチャネル作成
T+0:10 Tech Lead が初期切り分け開始
T+0:15 Comms が「調査中」として一次報告（経営・全社）
T+0:30 Comms が中間報告（30分毎に更新）
T+x:00 根本原因特定 → 復旧作業開始
T+y:00 復旧完了 → 動作確認 → 「終息」を Comms から共有
T+1日 ポストモーテム会議
T+3日 再発防止策の決定とナレッジ化
1️⃣ 検知 / 受付
検知経路
- 監視ツール（PRTG / Zabbix / Azure Monitor / Microsoft 365 サービス正常性）からのアラート
- 同時複数ユーザーからの問い合わせ
- セキュリティ製品（Defender / EDR）の高深刻度アラート
- 経営層・部署長からの直接連絡
受付時に必ず確認
2️⃣ 重大度判定 → IC 任命
判定マトリクス
影響ユーザー数 × 業務影響度 × データリスク
↓
P1 / P2 / P3 / P4 を決定
↓
P1〜P2 → IC を任命して体制発動
P3〜P4 → 通常チケットフロー
IC 任命
3️⃣ 初期対応（封じ込め）
被害拡大を止めるため、根本原因が判明する前でも実施します。
一般原則
シナリオ別の即時対応
| シナリオ |
即時対応 |
| 全社メール不可 |
M365 サービス正常性確認、ハイブリッド構成ならオンプレ Exchange 確認、外部 DNS の MX 確認 |
| ランサムウェア疑い |
該当端末を 物理的にネットワークから切断（LAN 抜く・Wi-Fi オフ）、AD アカウント無効化 |
| ファイルサーバ高負荷 |
接続中ユーザー数確認、不要セッション切断、ディスク残量確認 |
| 認証基盤（AD/Azure AD）不可 |
DC 健全性確認、AAD Connect 同期状態確認、サービス障害情報を確認 |
| 不審メール大量送信 |
送信元アカウントのパスワード変更＋セッション失効、送信ルール確認 |
4️⃣ 調査と根本原因特定
情報収集の優先順位
- 時系列の整理: いつから・どこから・どう広がったか
- 直前の変更: パッチ、設定変更、リリース、人事異動
- ログ取得: イベントログ・アプリログ・ファイアウォールログ・SaaS 監査ログ
- 再現性確認: 別端末・別ユーザー・別拠点で再現するか
想定される根本原因
| カテゴリ |
例 |
| 設定変更ミス |
GPO 変更、DNS 変更、ファイアウォールルール変更 |
| ハードウェア故障 |
サーバ HDD 故障、スイッチ電源故障、UPS 切替失敗 |
| ソフトウェア不具合 |
OS パッチ不具合、アプリのバージョン不適合 |
| 容量不足 |
ディスク満杯、メールボックス上限、ライセンス枯渇 |
| 外部要因 |
クラウドサービス障害、ISP 障害、DDoS |
| セキュリティ事案 |
マルウェア、不正アクセス、内部不正 |
5️⃣ 復旧 / 動作確認
復旧パターン
| パターン |
内容 |
| 設定戻し |
直前の設定変更を切り戻す（最も安全） |
| 再起動 |
サービス・サーバの再起動（影響時間と引き換え） |
| 代替経路 |
副系切替、代替メール経路への切替 |
| 容量増設 |
ディスク追加、ライセンス追加割当 |
| 復元 |
バックアップからの復元（最後の手段） |
復旧後の確認
6️⃣ 終息宣言と一次報告
7️⃣ ポストモーテム（事後分析）
復旧の翌営業日〜3 日以内に実施。犯人探しではなく、再発防止の仕組みを作るための会議 であることを冒頭で明示します（ブレームレス）。
📄 このプレイブックを実例に当てはめた書式:
postmortem-example.md に、共有フォルダ I/O 飽和（P2、架空事案）を題材にした
Postmortem の完成例を置いています。MTTA / MTTR / 5 Whys / 応急 → 恒久 → 中期対応までを実際にどう書くかが分かります。
議事の構成
- タイムラインの確認（Scribe の記録を読む）
- 影響範囲・ビジネスインパクトの確定（時間 × 人数）
- 何が良かったか（Worked Well）
- 何が課題だったか（Did Not Work Well）
- 是正アクション（Action Items）— 担当・期限を必ず決める
- ナレッジ化（手順書・障害対応事例集・バックアップ Runbook の更新）
Action Items の例
- 監視追加: ディスク使用率 90% で警告アラートを設定（Monitoring Stack で
HostLowDisk 相当）
- 手順整備: GPO 変更時のレビュアー必須化
- 訓練: 半期に一度、模擬インシデント訓練を実施
- ドキュメント: 障害対応事例集にケース追加、必要なら新規 Postmortem を作成
📨 報告テンプレート
一次報告（検知から 15 分以内）
【一次報告 / SEV1】メール送受信不可
発生時刻: 2026-05-XX 09:32 ごろ
事象 : Outlook でメールの送受信ができない（全社）
影響 : 推定 800 名 / 全社業務メール
原因 : 調査中
対応 : Tech Lead がログ確認中、復旧見込み未定
次回報告: 30 分後（10:15）または変化があり次第
連絡先 : IC 山田 (内線 XXXX)
終息報告
【終息報告 / SEV1】メール送受信不可 → 復旧
発生時刻 : 2026-05-XX 09:32
終息時刻 : 2026-05-XX 10:48
所要時間 : 1 時間 16 分
影響範囲 : 全社 約 800 名
根本原因 : Exchange Online 側のサービス障害（Microsoft 障害番号 XXXXXX）
対応概要 : Microsoft 障害情報を確認、自社側の操作なし、Microsoft 復旧を待機
再発防止 : Microsoft Service Health の通知を Teams チャネルに自動投稿する設定を追加
詳細 : ポストモーテム議事録を後日共有予定
⚠️ よくある落とし穴
| 症状 |
原因 |
対策 |
| IC と Tech Lead が同一人物で両方とも疲弊する |
体制が定義されていない |
プレイブックで役割を明示し、夜間オンコール体制を整備 |
| 関係部署が状況を知らないまま対応している |
Comms 不在 |
Comms 役を必ず立てる |
| 復旧したが原因不明のまま終わった |
時間優先で調査スキップ |
復旧後にログ取得→ポストモーテムで分析 |
| ポストモーテムが犯人探しに終始 |
ブレームレス文化が浸透していない |
冒頭で「仕組みの問題を探す」と宣言 |
🔗 関連リソース
注意: 本書はサンプルです。実運用では自社の BCP / DRP / セキュリティポリシー、契約 SLA、所属業界の法規制に応じてカスタマイズしてください。