インシデント対応

情報共有じょうほうきょうゆう

インシデント対応エスカレーションステークホルダーコミュニケーション報告連絡相談タイムライン

情報共有について教えて

簡単に言うとこんな感じ！

トラブルが起きたとき「自分だけ知ってる」状態はめちゃくちゃ危険なんだ！情報共有とは、関係する人たちに「今何が起きているか・何をしているか」を正しく・素早く伝え合うことだよ。チームで火事を消すには、誰がどこで何をしてるか全員が知ってないとダメでしょ？それと同じ！

情報共有とは

インシデント対応における情報共有とは、障害・セキュリティ事故・システム障害などの問題が発生した際に、対応に関わるすべての関係者（担当者・マネージャー・経営層・顧客など）へ、状況・進捗・影響範囲・対応方針を適切なタイミングで伝達し続けるプロセスのことです。

情報共有が不十分だと、「担当者は対応しているのに上司は何も知らない」「同じ作業を二人がバラバラにやっている」「顧客への説明が後手に回る」といった二次被害が起きます。インシデントそのものの被害より、情報の遅延・断絶が組織の信頼を損なうケースも少なくありません。

「報・連・相（ほうれんそう）」という言葉が示す通り、日常業務でも重要なスキルですが、インシデント対応ではスピード・正確性・対象者の選定がより厳しく問われます。誰に・何を・いつ・どう伝えるかを事前に設計しておくことが、被害を最小化する鍵です。

情報共有の構造と種類

インシデント対応での情報共有は、伝える方向（縦・横）と目的（報告・指示・協力）によって分類できます。

種類	方向	主な相手	目的
上方報告（エスカレーション）	縦（上へ）	上司・管理職・経営層	意思決定・リソース確保
下方指示	縦（下へ）	担当者・チームメンバー	役割分担・行動指示
横連携	横	他部門・他チーム	協力依頼・影響確認
外部通知	外へ	顧客・取引先・監督官庁	説明責任・信頼維持
記録・ログ	時系列	後から関わる全員	再発防止・証跡

「5W1H」で伝える

情報共有の内容が曖昧だと「で、結局どうすればいい？」となります。以下の6点を意識すると漏れが減ります。

What（何が） — どのシステム・どのデータに何が起きているか
When（いつ） — 発生時刻・検知時刻・現在の状況
Where（どこで） — 影響範囲（サーバー・拠点・ユーザー数）
Who（誰が） — 現在誰が対応しているか
Why（なぜ） — 判明している原因・推定原因
How（どう対応するか） — 次のアクション・完了見込み

情報共有の頻度の目安

フェーズ	頻度の目安
発生直後（最初の30分）	発生確認後できるだけ早く（5〜10分以内）
対応中	30〜60分ごとに進捗報告
収束後	収束報告 → 24〜72時間以内に速報レポート
事後	1〜2週間以内に再発防止報告書

歴史と背景

1980年代以前 — 情報共有は主に「紙の報告書」「電話」による。インシデント発生時の伝達は非常に遅く、組織内での情報の孤立が常態化していた
1990年代 — 企業内LANの普及により、メール・社内掲示板での情報共有が始まる。ただし「誰に送るか」の設計は属人的だった
2000年代 — ITILなどのITサービス管理フレームワークが普及。インシデント管理プロセスの中で「ステークホルダーへの通知」が正式に定義されるようになった
2010年代 — SlackやMicrosoft Teamsなどのビジネスチャットが普及し、リアルタイムの情報共有が一般化。インシデント対応専用チャンネルを立てる文化が広まった
2020年代 — リモートワークの常態化により、情報共有の仕組みづくりがさらに重要に。PagerDutyなどのインシデント管理ツールと連携した自動通知・エスカレーションが標準的になっている

情報共有の流れと関係者マップ

インシデント発生時、誰に・何を・どの順番で伝えるかを整理したのが以下の図です。

情報共有ツールの選び方

ツール種別	向いている用途	注意点
ビジネスチャット（Slack / Teams）	リアルタイムの状況共有・作業ログ	流れやすいので重要事項は別途記録
インシデント管理ツール（PagerDuty / Jira）	タイムライン管理・エスカレーション自動化	初期設定コストあり
メール	正式な外部通知・記録	速報には遅すぎる場合あり
電話・口頭	緊急度が極めて高い場面	記録が残らないので必ず後でメモ
ステータスページ（Statuspage など）	顧客への公開通知	誰でも見られる情報に絞る

情報共有でよくある失敗

インシデント対応の現場で繰り返される「情報共有の失敗パターン」を押さえておきましょう。

【よくある失敗パターン】

❌ 「まだ原因調査中だから報告しない」
   → 上司・顧客は何も知らないまま時間が経つ。
     「わからない」という状態も共有するのが正解。

❌ 「とりあえず全員にCC」
   → 情報の重要度が伝わらず、誰も動かない。
     誰に何を決めてほしいかを明示する。

❌ 「口頭で伝えた」
   → 後からの確認・証跡がゼロ。
     必ずテキストで記録を残す。

❌ 「収束したから終わり」
   → 再発防止につながらない。
     事後報告書・ポストモーテムまで完結させる。

規格・番号	内容
ISO/IEC 27035	情報セキュリティインシデント管理の国際規格。情報共有・エスカレーション手順を含む
ITIL v4	インシデント管理プロセスの中でステークホルダーへの通知・コミュニケーション計画を定義
NIST SP 800-61	コンピュータセキュリティインシデント対応ガイド。通知・報告の手順を詳述