重大インシデント管理とは？対応フローと役割

結論から： 重大インシデントとは、業務への影響が大きく、通常のチケットの順番待ちではなく、別立ての迅速なプロセスで対応する必要があるインシデントです。流れは、宣言する、1人のインシデントマネージャーのもとにチームを集める、決めた間隔で連絡する、まずサービスを復旧する、最後に振り返る、です。根本原因を突き止めて取り除く作業は別のもので、その後に問題管理が担当します。

ITのインシデントの大半は日常的なものです。プリンターが使えない、PCが重い、パスワードをリセットしたい、といった類いです。ごく一部はそうではありません。全社のメールが止まった、本社のネットワークが落ちた、決済システムが停止した、といったケースです。こうした障害には、別の進め方が必要です。この記事では、重大インシデントとは何か、どう段階を踏んで対応するか、誰が何を担当するか、どう連絡するか、そしてインシデント管理と問題管理の境界線を解説します。

用語は、AtlassianのITインシデント管理のガイドと問題管理のガイドを参照しています。Atlassianは、ITILやITSMのプラクティスに従うチームは、緊急対応が必要なインシデントを「重大インシデント（major incident）」と呼ぶことがあると説明しています。また、ITILにおける既知のエラー（known error）の定義として、根本原因と回避策が文書化されている問題、という説明を引用しています。2026年10月28日に両方を確認しています（確認日：2026-10-28）。以下のしきい値や時間は、調整して使うための例であり、業界標準ではありません。

重大インシデントとは？

Atlassianは、インシデントを、サービスを中断させる、またはその品質を下げる（あるいはそのおそれがある）あらゆる出来事、と説明しています。重大インシデントは、そのうち業務への影響が大きく、通常の順番待ちでの対応では足りないものです。「影響が大きい」は会社によって異なるため、万国共通の数字はなく、あらかじめ自社で定義しておく必要があります。

代表的な発動条件は次のとおりです。

中核サービスが、多数の利用者または拠点全体で止まった：メール、ネットワーク、ID基盤、ERP、顧客ポータル。
収益を生むシステム、または安全に関わるシステムが止まった。
ランサムウェアや管理者アカウントの乗っ取りの疑いなど、重大な結果をもたらすセキュリティ事案。
複数の顧客や拠点に同時に影響する障害。
小規模な障害だが、その優先度で許容される時間を超えて長引いている。

重大インシデントは、単なるP1ではありません。多くの組織では、重大インシデントのプロセスを発動せずに、複数のP1チケットを同時に抱えています。違いは、重大インシデントでは複数のチームの人が1人の調整役のもとで協力し、経営層への報告も続くという点です。

優先度そのものは、影響度と緊急度から決まります。決め方は重大度と優先度の違いで、各レベルの実際の意味はP1〜P4の解説で説明しています。

重大インシデントはいつ宣言するべきか

宣言の基準を書き出し、プレッシャーのもとでも当てはめやすくしておきます。長い規程より、短いチェックリストのほうが役に立ちます。

影響を受けているサービスが重要サービスの一覧にある、または影響を受ける利用者や拠点の数が決めた値を超えている。
利用者が現実的に取れる回避策がない。
想定される影響が深刻：売上の損失、安全、法令や契約上の問題、信用の毀損。
最初のエンジニアが、短い制限時間（たとえば30分）では直せない、または復旧の見込みを立てられない。

サービスデスクの誰もが重大インシデントを提案でき、指定された1人（通常は当番のインシデントマネージャー）が確定できるようにします。実際は小さかった障害を重大インシデントとして宣言しても、失うものはわずかです。一方、本物の重大インシデントの宣言が1時間遅れる代償は大きくなります。

重大インシデント管理のプロセスは？

中小規模のIT部門でも使える流れを、順番に示します。

検知と記録。 監視アラート、電話、似たチケットの集中などで問題が見えてきます。発生時刻、影響範囲、報告者を記録します。
宣言。 基準を当てはめ、インシデントに名前を付け、すべての情報を紐付ける単一のインシデント記録を作成します。共有の連絡チャネルを1つ用意します（たとえば会議のブリッジとチャットルーム）。
インシデントマネージャーを任命。 調整の責任者を1人決めます。この人は技術作業はしません。
対応チームを招集。 影響を受ける領域の技術リーダー、ベンダーや回線事業者、業務部門と話せる人を集めます。
影響を評価。 誰が業務できないのか、どの業務プロセスが止まったのか、業務上の期限はいつかを確認します。
まずサービスを復旧する。 最も早く安全に使える状態に戻せる手段を選びます。変更のロールバック、フェイルオーバー、再起動、回避策の適用などです。停止中に完璧な原因説明を探してはいけません。
決めた間隔で連絡する。 進展があってもなくても、約束した間隔で更新を出します。詳しくは後述します。
復旧を確認する。 ダッシュボードが緑なだけでなく、実際の利用者や業務責任者に確認してもらいます。
クローズして引き継ぐ。 タイムライン、回避策、未解決の疑問を記録し、根本原因の調査を問題管理に渡します。
振り返り。 記憶が新しいうちに、数営業日以内にインシデントのレビューを開きます。

重要な原則は、サービスの復旧と原因の究明は別の活動だということです。両方を一緒にすると、停止が長引きます。

重大インシデントでの役割分担

役割は少なく、明確にします。小さなチームでは1人が2つの役割を兼ねてもかまいませんが、インシデントマネージャーが障害の修復作業まで担当してはいけません。

インシデントマネージャー： ブリッジ会議を仕切り、優先順位を決め、タイムラインを管理し、技術チームの妨げになるものを取り除きます。
技術リーダー： 調査と修復の作業を指揮し、わかっていること、わかっていないこと、試していることをインシデントマネージャーに伝えます。
連絡担当： 更新連絡を書いて送り、エンジニアが連絡に時間を取られないようにします。小さなチームではインシデントマネージャーが兼ねることもあります。
専門のエンジニア： 対象のシステム、ネットワーク、セキュリティ、アプリケーションを実際に扱う担当者です。
業務または顧客の代表： 影響、業務上の期限、どの状態になれば受け入れられるかを確認します。
書記： 時刻、決定、アクションを記録します。振り返りの素材になります。

IT運用を外部に委託している場合は、事前にベンダーとこれらの役割を取り決めておきます。お客様側で、フェイルオーバーや緊急変更を承認できるのは誰かも含めてです。誰を、いつ呼ぶかについては、L1・L2・L3のサポートレベルとエスカレーションマトリクスの記事をご覧ください。

重大インシデント中の連絡はどうする？

悪い知らせよりも、沈黙のほうが被害を大きくします。何も聞こえてこなければ、誰も動いていないと受け取られ、電話や上位へのエスカレーションが相次いで、エンジニアが復旧作業から引き離されます。

最初の通知を早く出す。 影響を受けているもの、発生時刻、調査中であること、次の連絡の時刻を伝えます。原因がわかるまで待ちません。
連絡の間隔を固定する。 たとえば緊急障害なら30分ごと。状況に応じて調整してかまいません。「変化なし、調査継続中」という内容でも、時間どおりに送ります。
平易な言葉で書く。 利用者が今できること、できないこと、回避策を説明します。社内のチケット番号や専門用語は避けます。
情報源を1つにする。 チャネルは1つ、ステータスの文面は1つ、責任者は1人。3人が3通りの見込みを出しません。
見込みは慎重に。 自信がない限り、復旧の約束時刻ではなく、次回の更新時刻を伝えます。
復旧の通知を出す。 何が戻ったのか、利用者に確認してほしいこと、振り返りを行うことを伝えます。
振り返りのあとにフォローする。 何が起きて、何を変えるのかを、短くまとめて共有します。

相手に合わせて内容を変えます。経営層には影響と事業上の結果、利用者には今できること、技術チームには詳細が必要です。

インシデント管理と問題管理の違いは？

最もよくある混同で、答えはそれぞれの目的にあります。

インシデント管理は、通常のサービス運用をできるだけ早く回復させることが目的です。重視するのはスピードと影響の最小化で、回避策でサービスが戻れば成功です。
問題管理は、インシデントの背後にある根本原因を見つけて対処し、再発を防ぐことが目的です。重視するのは深さと予防で、回避策はあくまで途中経過です。

Atlassianは、問題管理を、ITサービス上のインシデントの原因を特定し管理するプロセスと説明しています。既知のエラーは、根本原因と回避策が文書化された問題です。

具体例で比べてみます。月曜の朝、ファイルサーバーのディスクが満杯になり、共有ファイルを誰も開けなくなりました。

インシデント対応： 空き容量を作るか増設し、利用者がファイルを開けることを確認して、インシデントをクローズします。
問題調査： ディスクがなぜ一杯になったのか、バックアップジョブなのか、暴走したログなのか、誰かが大容量ファイルをコピーしたのか。そして、なぜ監視が事前に知らせなかったのかを調べます。その上で、アラート、クォータ、容量を整備して再発を防ぎます。

2つはつながっています。重大インシデントは通常、問題レコードにつながり、似たインシデントが複数あれば1つの問題に紐付けられます。根本原因が見つからない場合は、回避策を既知のエラーの記録に残し、次のエンジニアがより早くサービスを戻せるようにします。

事後レビュー（振り返り）の進め方

振り返りは非難しない（ブレームレス）形で行います。目的は仕組みを改善することで、誰かを責めることではありません。次の内容を扱います。

最初の症状から完全復旧までのタイムライン。検知、宣言、主要な判断、復旧の時刻を含みます。
うまくいったこと、対応を遅らせたこと、運が良かっただけのこと。
業務への影響を、平易な言葉で。
わかっている範囲の原因と、まだわかっていないこと。
担当者と期限を明確にしたアクション。問題レコード、変更依頼、監視の改善として登録します。
宣言の基準、役割分担、連絡先一覧の更新が必要かどうか。

このタイムラインは、MTTR・MTBF・MTTAの解説で紹介した平均指標の実測データにもなります。データの損失や長い復元があった場合は、RTOとRPOの違いの目標と結果を比べてみてください。

最初の重大インシデントの前に準備しておくこと

効果の大半は事前の準備から得られます。

重大インシデントとは何か、誰が宣言できるのかを定義します。
チーム、ベンダー、回線事業者、主要な業務責任者の連絡先一覧を最新に保ち、システムが止まっていても手元にあるようにします（紙や携帯電話に入れておくなど）。
最初の通知、更新、復旧通知のテンプレートを作成します。
常設の連絡チャネルまたは会議ブリッジの番号を決め、その場で考えなくて済むようにします。
重要サービス、その責任者、依存関係を文書化します。
緊急変更のルールをあらかじめ合意し、承認待ちで修復が遅れないようにします。
少なくとも年1回、短い訓練を行います。

IT運用を委託している場合は、委託先の重大インシデント対応プロセスと連絡経路を文書で示してもらってください。BrocentのSLAのページでは優先度別の応答目標を公開しており、マネージドITサポートのプランとユーザー単価にはマネージドITサポートの公開価格と、契約上のサービス時間帯内での緊急インシデントの15分の初回応答が掲載されています。ご自身の環境に合った重大インシデント対応について相談したい方は、お問い合わせください。