システム障害のレベル（重大度）定義の考え方

システム障害の「レベル（重大度）」を定義しておくと、発生時にどの体制でどれだけ急いで対応すべきかを、担当者の勘に頼らず判断できるようになります。本記事では、レベルを定義する目的、影響範囲×緊急度で整理する一般的な考え方、実際の運用に落とし込む際の注意点、そしてPMOが整備を支援する際の進め方を、具体的なレベル定義マトリクスの例とともに解説します。

障害レベルを定義する目的

障害レベルを定義する目的は、発生した障害への対応体制と対応スピードを、担当者の経験や勘に頼らず即座に判断できるようにすることです。

ITSM（ITサービスマネジメント）の実務では、障害は毎回同じ深刻さで発生するわけではありません。全社の基幹システムが停止する障害と、一部の利用者だけに影響する軽微な不具合とでは、動かすべき体制も報告のスピードもまったく異なります。しかし、この判断をその場の感覚だけで行っていると、軽微な障害に過剰な人員を投入してしまったり、逆に重大な障害への気づきが遅れて経営層への報告が後手に回ったりする事態が起こり得ます。

あらかじめ障害レベルを定義しておくことで、こうした判断のばらつきを抑え、初動対応・エスカレーション・報告のいずれについても、レベルに応じた一貫した動きを組織全体で取れるようになります。

対応優先度とエスカレーション基準の明確化

レベル定義の中心的な役割は、対応優先度とエスカレーション基準を明確にすることです。

独立行政法人情報処理推進機構（IPA）が公開している「ITサービスマネージャ試験（レベル4）シラバス」（2020年公表のVer.5.0）でも、インシデント管理の実施事項として「影響及び緊急度を考慮して、優先順位付けをする」「必要であれば、エスカレーションする」ことが明記されており、優先順位付けとエスカレーションは障害対応の標準的なプロセスとして位置づけられています。エスカレーションには、技術的な難易度に応じて対応者を上位の担当者へ引き継ぐ「機能的エスカレーション」と、影響の大きさに応じて管理者・経営層へ報告を上げる「階層的エスカレーション」の2種類があるとされ、どちらもレベル定義と紐づけて運用するのが一般的です。

たとえばレベルが高い障害では「発生から15分以内に一次対応、30分以内に上長へ報告」、レベルが低い障害では「当日中に記録し、翌営業日の定例会で共有する」のように、対応の速さと報告先をレベルごとに固定しておくと、現場の担当者は「このレベルなら何をどこまで急ぐべきか」を都度悩まずに動けます。

一般的なレベル分けの考え方

障害レベルは、影響範囲と緊急度という2つの軸を掛け合わせて判定する考え方が広く使われています。

影響範囲は「どれだけ広く、どれだけ重要な業務に影響が及んでいるか」を示す軸で、対象ユーザー数・対象システムの重要度・代替手段の有無などから判断します。緊急度は「どれだけ早く手を打つ必要があるか」を示す軸で、放置した場合の被害の拡大速度や、業務上の締め切りとの近さなどから判断します。

IPAが2012年に公表した「情報システム障害の再発防止のための組織的マネジメントの調査WG報告書」では、複数の事業者が障害の重大さを3段階程度の等級に区分し、等級ごとに「年あたりの障害発生数の上限」を目標として設定している実態が紹介されています（出典：IPA、2012年4月）。同報告書は、ある障害が「重大な障害」に該当するかどうかを「（影響・迷惑のあった時間）×（影響の及んだ業務の量・迷惑を受けた利用者の数）」という考え方で指標化して判断していたと説明しており、これは影響範囲×緊急度でレベルを判定する現在の一般的な整理と本質的に同じ発想だといえます。

影響範囲×緊急度によるマトリクス

実務では、影響範囲を3段階、緊急度を2〜3段階に分けて掛け合わせ、レベルを機械的に判定できるマトリクスを用意する方法が広く使われています。

以下は、レベル定義マトリクスの一例です（架空の数値を用いたサンプルであり、実際の基準値は組織の事業内容やシステム構成に応じて個別に設計する必要があります）。

マトリクスを設計する際の勘所は、レベルの数を欲張らないことです。区分が5段階を超えると、現場の担当者が発生した障害をどのレベルに当てはめればよいか迷う場面が増え、結局は運用されなくなりがちです。3〜4段階程度に絞り、各レベルの境界を「〇〇分以上」「〇〇人以上」のように数値で示しておくと、判定のブレを抑えられます。

なお、影響範囲・緊急度の基準値を検討する際は、社外の制度が参考になる場合があります。たとえば総務省は、電気通信事業者に対して、緊急通報を扱わない音声伝送サービスで継続時間2時間以上かつ影響利用者数3万人以上の障害などを「重大な事故」と定め、総務省への速やかな報告と発生から30日以内の詳細報告を義務付けています（出典：総務省「重大な事故の報告」）。この基準はあくまで電気通信事業者向けのものであり、自社にそのまま適用できるわけではありませんが、「時間」と「影響を受けた人数」という2軸で客観的な線引きを行っている点は、社内向けのレベル定義を設計する際の参考になる考え方です。

レベル定義を運用に落とし込む際の注意点

レベル定義を実際の運用に定着させる際の注意点は、判定基準を数値で固定し、レベルごとの対応フローとセットで運用することです。

まず避けたいのが、「影響が大きい場合」「緊急性が高い場合」のように、定性的な言葉だけでレベルを定義してしまうことです。基準が曖昧だと、同じような障害でも判定者によって異なるレベルが付けられてしまい、レベル定義そのものへの信頼が失われかねません。前述のマトリクスのように、対象ユーザー数や継続時間といった数値の閾値を明記し、判定に解釈の余地を残さないようにする必要があります。

次に重要なのが、レベルと対応フロー・報告フローを1対1で紐づけておくことです。レベルを決めただけで、誰が・いつまでに・何をするかが決まっていなければ、現場では結局「このレベルのときはどうすればいいのか」を都度確認することになり、レベル定義の意味が薄れてしまいます。レベルごとの初動対応・エスカレーション先・報告様式まで一体で整備しておくことで、レベル定義後の報告実務もスムーズになります。

また、レベル定義は一度作って終わりにせず、定期的な見直しが必要です。組織の体制やシステム構成は変化するため、半年〜1年に一度は過去の障害実績を振り返り、レベルの境界値が実態に合っているかを確認することが望ましいといえます。

PMOがレベル定義の整備を支援する際の進め方

PMOがレベル定義の整備を支援する際は、現状把握、合意形成、マトリクス設計、試行運用という順序で進めるのが基本的な流れです。

1. 現状把握：過去の障害対応ログやエスカレーションの実態をヒアリングし、現在どのような基準で（あるいは基準なく）対応が判断されているかを整理します。
2. 関係者間の合意形成：情報システム部門だけでなく、影響を受ける事業部門や経営層も交えて、「何をもって重大とするか」の目線合わせを行います。ここでの合意が甘いと、後で運用が形骸化しやすくなります。
3. マトリクス設計：影響範囲・緊急度の軸と閾値を具体的な数値で定義し、レベルごとの初動対応・エスカレーション先を紐づけます。
4. 試行運用と調整：一定期間、実際の障害にレベルを当てはめて運用し、判定に迷うケースが多い境界値を洗い出して調整します。

この整備は、ITILが体系化しているインシデント管理プロセスの土台部分にあたる作業でもあります。インシデント管理プロセスとの関係を押さえておくと、レベル定義を既存のITSMプロセス全体の中に位置づけやすくなります。

実務上、こうした障害レベル定義の整備支援は、社内の情報システム部門が単独で担うだけでなく、独立系のPMO・ITコンサルタントがプロジェクト単位でアサインされて進めるケースも少なくありません。独立コンサルタントの多くは、大手企業と直接契約するのではなくエージェントを介した契約形態で案件に参画するのが実務上の基本形とされており、この種の整備支援もその例に漏れません。

まとめ

障害レベルの定義は、対応優先度とエスカレーション基準を組織全体で揃えるための土台になります。

影響範囲×緊急度のマトリクスで判定基準を数値化し、レベルごとの対応フロー・報告フローとセットで運用することで、担当者ごとの判断のばらつきを抑えながら、重大な障害への対応漏れを防げます。整備後は障害報告書の作成実務にもつながるため、レベル定義と報告書の書式は合わせて見直しておくと、運用全体の一貫性を保ちやすくなります。

本記事は2026年9月時点の情報に基づいています。

出典・参考情報

1. 独立行政法人情報処理推進機構（IPA）「ITサービスマネージャ試験（レベル4）シラバス Ver.5.0」（2026-09-12参照）
2. 独立行政法人情報処理推進機構（IPA）「情報システム障害の再発防止のための組織的マネジメントの調査WG報告書」（平成24年4月5日）（2026-09-12参照）
3. 総務省「重大な事故の報告」（2026-09-12参照）

制度・基準は変更される場合があるため、最新情報は各公的機関の公式情報をご確認ください。