重大度と優先度の違い：IT障害対応の影響度×緊急度マトリクスの使い方

結論から： 重大度（severity）は、その障害がどれだけ深刻かを表します。優先度（priority）は、どの障害から、どれだけ速く対応するかを決めるものです。重大度は被害に関する事実、優先度は影響度・緊急度・業務上の事情を合わせた判断、と考えると整理しやすくなります。多くのサービスデスクは「影響度×緊急度マトリクス」で優先度を算出し、例外的な場合に限って、責任者が手動で変更できるようにしています。

ITのサービスデスクでは、二つの言葉が思わぬ摩擦を生みます。利用部門は「これは緊急です」と言い、エンジニアは「重大度は低い」と言い、チケットはキューに積まれたまま。どちらも自分の基準では間違っていません。原因は、重大度と優先度を同じ物差しとして扱っていることにあります。この二つは別々の問いに答えるものです。サポートのプロセスは、両方を尋ね、両方を記録するほうがうまく回ります。

この記事では、両者の違いをやさしく整理し、影響度と緊急度の二つの判断がどのように優先度になるのかを説明します。例として使うのは、Brocentが自社のSLAページで公開しているマトリクスです（2026年10月28日に確認しました）。あわせて、具体的なシナリオ、マトリクスが失敗しやすい場面、そして社内の情シスでもマネージドITサービスの提供会社を選ぶ場面でも使える導入手順を紹介します。

重大度と優先度の違いは何か

重大度は「どれだけ深刻か」に、優先度は「何を先に、どれだけ速くやるか」に答えます。

重大度は、問題そのものの大きさを表します。何が壊れているのか、何人（いくつのシステム）に影響しているのか、データ・セキュリティ・売上にリスクがあるのか、といった点です。通常は障害の内容が分かった時点で決まり、事実が変わったときにだけ変更します。たとえば、調査の結果、障害の範囲が当初より広いと分かった場合です。

優先度は、対応の順番を表します。同じ事実から出発しますが、そこに時間と状況が加わります。期限はあるか、回避策で十分か、月末か、影響を受けているのは一人か経理部全体か、といった点です。優先度は、重大度が変わらなくても、障害の途中で上がったり下がったりします。

二つを分けて考えるには、次のたとえが役に立ちます。

• 重大度は診断です。 医師は、待合室に何人並んでいるかを知らなくても「重いけがだ」と判断できます。
• 優先度はトリアージの順番です。 診断に基づきますが、誰が待っているか、手が空いているスタッフは誰か、それぞれの症例がどれだけ急ぐかにも左右されます。

どちらの言葉も業界で広く使われていますが、使い方が完全に揃っているわけではありません。Atlassianのインシデント管理ガイド（重大度レベルのページ。2026年10月28日に確認）は、障害の深刻さを表すのに「SEV」レベルを使っています。SEV 1は影響が非常に大きい重大なインシデント、SEV 3は影響の小さい軽微なインシデントです。また同ページは、自社のビジネスを理解したうえで、自分たちに合う重大度と優先度の定義を選ぶことが大切だと述べています。ITILの流れをくむサービスデスクでは、「優先度」を主なフィールドとし、影響度と緊急度から導くのが一般的です。どちらの使い方も間違いではありません。大切なのは、それぞれの言葉が何を意味するかを文書にし、毎回同じ使い方をすることです。

なぜ重大度と優先度を分けて持つのか

二つがいつも同じなら、フィールドを二つ持つ意味はありません。しかし実際には食い違うことが多く、一本化すると本当の判断ミスにつながります。

1. 重大な問題が低い優先度になることがあります。 広がれば深刻になるものの、今は封じ込められていて、回避策があり、来週まで誰も使わないシステムの障害であれば、計画変更の枠まで待てます。
2. 軽微な問題が高い優先度になることがあります。 一人がログインできないだけなら小さな障害です。しかしその人が一時間後に顧客へプレゼンするなら、障害自体が悪化していなくても、期限が対応の順番を変えます。
3. フィールドごとに担当者が違います。 障害を理解しているエンジニアが重大度を判断し、業務の期限を知っているサービスオーナーが緊急度を判断するのが自然です。フィールドが一つだと、片方の担当者がもう片方の判断を推測することになります。
4. レポートには両方が必要です。 優先度だけを記録していると、P1チケットの急増が、基盤が本当に壊れているせいなのか、「急ぎです」と言うことに皆が慣れたせいなのか区別できません。重大度も記録すれば、その二つを分けられます。

影響度と緊急度とは

影響度×緊急度マトリクスは、二つの入力から成ります。どちらも技術ではなく、業務についての判断です。

影響度は、影響の広がりです。何人、いくつのシステム・拠点・業務プロセスに、どれだけ深く影響しているかを問います。表現は「全社」から「一人のユーザー、回避策あり」まで幅があります。

緊急度は、時間的な切迫です。影響がどれだけ早く悪化するか、業務がどれだけ早くサービスの復旧を必要とするかを問います。同じ故障でも、明らかな回避策があれば緊急度は低く、給与計算の日であれば高くなります。

ITILは、ITサービスマネジメントで最もよく知られたプラクティス集で、優先度はこの二つの組み合わせで決まる、と広く説明されています。今回の記事では、有償のITIL公式文書を読み直してはいません。そのため、原文の引用ではなく、一般的な実務として紹介しています。ITILに沿って正式なプロセスを作る場合は、公式のITILガイダンスの記述を確認してください。

影響度のレベルをどう定義するか

多くの中小規模の組織では、四段階あれば十分です。サービスデスクが一分以内に判断できる表現にしてください。

1. クリティカル： 全社または顧客向けのサービスが止まっている、あるいはセキュリティ事故やデータ消失が進行中。
2. 深刻： 部門、拠点、または重要なシステムが使えない、もしくは大きく低下している。
3. 中： ユーザーのグループや、重要度の低い一つのシステムに影響があり、縮小した形で業務を続けられる。
4. 軽微： 一人のユーザー、または見た目や価値の低い機能に影響がある。

緊急度のレベルをどう定義するか

緊急度は時間に左右されるため、文章にするのが難しい項目です。こちらも四段階が扱いやすいでしょう。

1. クリティカル： 業務が今止まっている、または一時間以内に止まる。回避策がない。
2. 高： 当日の営業時間中に影響が悪化する、または今日が期限である。
3. 中： 影響は数日待てる、または使える回避策がある。
4. 低： 期限がなく、影響も悪化しない。

影響度×緊急度マトリクスは、どう優先度を導くのか

マトリクスは、早見表を引く作業です。影響度を選び、緊急度を選び、交点から優先度を読み取ります。研修資料では表の形で描かれることが多いため、マトリクスには表が必要だと思われがちですが、そうではありません。単純なルールの集まりですので、見出しと番号付きリストだけで書けます。この記事もその形で示します。

手順は三つです。

1. 上の定義で、影響度を決める。
2. 上の定義で、緊急度を決める。
3. 交点を調べて、優先度フィールドに入れる。責任者が結果は妥当でないと判断した場合は、手動で変更できる。ただし理由を記録する。

チケットを起票した人は優先度を直接設定せず、影響と期限を説明するだけにして、サービスデスクがマトリクスを当てはめる、というルールを加えるチームも多くあります。こうすると、すべてのチケットが「至急」で届く状況を避けられます。

公開されている障害優先度マトリクスの実例

Brocentは、マトリクスをSLAページで公開しています。作り話ではなく、実際に使われているものを見られます。2026年10月28日に確認した内容では、優先度は業務への影響度と緊急度を組み合わせて決まり、サービスデスクは受け付けた各チケットの仕分けでこのマトリクスを適用する、とされています。業務への影響度は、クリティカル（Critical）、深刻（Serious）、中（Medium）、軽微（Minor）の四段階、緊急度は、クリティカル（Critical）、高（High）、中（Medium）、低（Low）の四段階です。

公開されているマトリクスを、影響度ごとに順に読むと次のようになります。

業務への影響度が「クリティカル」のとき

1. 緊急度がクリティカルなら、優先度はP1。
2. 緊急度が高なら、優先度はP1。
3. 緊急度が中なら、優先度はP2。
4. 緊急度が低なら、優先度はP4。

業務への影響度が「深刻」のとき

1. 緊急度がクリティカルなら、優先度はP1。
2. 緊急度が高なら、優先度はP2。
3. 緊急度が中なら、優先度はP3。
4. 緊急度が低なら、優先度はP4。

業務への影響度が「中」のとき

1. 緊急度がクリティカルなら、優先度はP2。
2. 緊急度が高なら、優先度はP2。
3. 緊急度が中なら、優先度はP3。
4. 緊急度が低なら、優先度はP4。

業務への影響度が「軽微」のとき

1. 緊急度がクリティカルなら、優先度はP2。
2. 緊急度が高なら、優先度はP3。
3. 緊急度が中なら、優先度はP3。
4. 緊急度が低なら、優先度はP4。

注目したい点が二つあります。一つ目は、影響が小さくても、緊急度によって優先度が上がることです。影響が軽微でも緊急度がクリティカルなら、P4ではなくP2になります。二つ目は、このマトリクスでは、緊急度が低いとすべてP4で頭打ちになることです。時間的な切迫がなければ、作業は計画に組み込めるからです。

同じSLAページには、第五のレベルとしてP5も載っています。これは障害ではない定型の依頼、たとえば新規の機器設置、退職に伴う作業、パスワードのリセットなどに使われます。故障ではなくサービス要求にあたるため、影響度×緊急度マトリクスの対象外です。

優先度ごとの応答時間はどうなっているか

優先度は、約束を伴ってはじめて役に立ちます。同じSLAページでは、各レベルの初回応答、リモート対応、オンサイトまたは解決の目標が公開されています。初回応答は、P1とP2が15分、P3が30分、P4とP5が60分です。これらは初回応答の時間であって、復旧までの時間ではありません。また、サービス時間帯によって変わります。標準の8×5は平日（月曜から金曜）に一日9営業時間、プレミアムの24×7は終日です。ページには、応答時間は契約条件に従う、とも書かれています。

P1の応答時間は公開されていますので、ご相談の前に、SLAページとマネージドITサポートのプランとユーザー単価で確認できます。四つのレベルがそれぞれ何を約束するのかを平易に知りたい方は、関連記事「ITサポートSLAのP1からP4の優先度」をご覧ください。

具体例：重大度と優先度を並べて見る

以下のシナリオは説明用の例であり、実際の顧客の事例ではありません。同じマトリクスが場面ごとにどう働くか、そのとき重大度と優先度がどう違うかを示します。

1. 月曜の朝、全社でメールが使えない。 影響度はクリティカル、緊急度もクリティカル。マトリクスの結果はP1です。重大度も、使っている尺度の最上位です。全員がまずこれに取りかかります。
2. 月末の二日前、経理部の会計システムが極端に遅い。 影響度は深刻、緊急度は高。結果はP2です。システムは動いているので、エンジニアは重大度を「中」とするかもしれませんが、月末という期限が優先度を引き上げます。
3. 明日の会議の前に、一人のユーザーが印刷できない。 影響度は軽微、緊急度は高。結果はP3です。重大度は低く、優先度は中位です。
4. 来四半期にソフトウェアライセンスの更新が必要。 影響度は軽微、緊急度は低。結果はP4で、チケットは計画に入れます。
5. 予備サーバーで障害が起きているが、フェイルオーバーは正常に動いている。 エンジニアのメモでは、フェイルオーバーまで失われると拡大するため、重大度は「重大」と書かれるかもしれません。ただし今日の影響度は軽微、緊急度は低なので、結果はP4です。変更枠を予約し、重大度は記録に残ります。

五つ目のシナリオは、二つのフィールドを持つ価値をよく示しています。優先度のフィールドしかなければ、記録には「低」としか残らず、リスクは忘れられてしまいます。

どんなときにマトリクスの結果を手動で変更するか

どんなマトリクスも、すべてのケースを網羅はできません。よい運用では、指名された担当者が計算結果を変更でき、その理由を書き残すことが求められます。変更の理由として妥当なのは、次のようなものです。

1. セキュリティ上の兆候。 乗っ取られたアカウントのような挙動があれば、見かけの影響より高い優先度に値します。
2. 外部の固定された期限。 決まった時刻までに申告や納品が必要なら、緊急度を上げます。
3. 繰り返し起きる障害。 同じ原因のP4チケットが五件あれば、それは五つの小さな件ではなく、一つの大きな問題です。問題管理の記録として扱ってください。
4. 回避策の失効。 回避策が使えなくなれば、他に何も変わっていなくても緊急度は変わっています。
5. 影響を受けやすい役割。 決まった時刻に支払い処理をする担当者のように、人数から想像されるより中断に弱い役割があります。

手動の変更は、まれであるべきです。かなりの割合のチケットが変更されているなら、定義が合っていないのですから、一件ずつ手直しせず、定義を書き直してください。

優先度マトリクスはどう導入するか

午後一回で作れて、最初の一か月で磨き込めます。この手順は、規模を問わず社内IT部門に向いています。マネージドITサービスの提供会社に見せてもらうべき内容でもあります。

1. 影響度四段階と緊急度四段階の定義を、自分たちの言葉で書き、各レベルに例を一つずつ付ける。
2. マトリクスをリストで書き、影響度ごとに見出しを立て、全担当者が見られる一ページにまとめる。
3. 各優先度に応答目標を付け、営業時間で測るのか、実時間で測るのかを明記する。
4. 誰が手動で変更できるかを決め、チケットに理由を書くことを求める。
5. 障害の深刻さを報告したいなら、重大度の項目を別に設け、そのレベル（たとえば三段階か四段階）を定義する。
6. 一か月後に見直す。変更されたチケットや再オープンされたチケットを確認し、定義を直す。
7. 依頼者には、評価ではなく説明をしてもらう。何が影響を受けているか、どんな期限があるかを尋ねる短いフォームを用意する。

ITサービス提供会社に、重大度と優先度について何を尋ねるか

マネージドITを購入する場合、契約には優先度のレベルが書かれています。その定義がどれだけ明確かで、サービスがどう運営されているかがかなり分かります。確認したい質問は次のとおりです。

1. 契約ではどの言葉を使い、重大度と優先度は分かれていますか。
2. 優先度を決めるのは、依頼者ですか、サービスデスクですか。
3. マトリクスは公開されていて、契約前に見られますか。
4. 各レベルの初回応答と解決の目標はいくつで、どの時間帯に適用されますか。
5. 優先度を変更できるのは誰で、理由は記録されますか。
6. 優先度の状況は、毎月どのように報告されますか。

契約への落とし込みについては、24×7のヘルプデスクIT支援の概要をご覧いただくか、自社のサービスレベルについてお問い合わせください。

よくある質問

重大度と優先度の違いを一文で言うと？

重大度は障害の深刻さを測るもの、優先度は影響度・緊急度・状況に基づいて、対応の順番と速さを決めるものです。

P1とSEV 1は同じですか？

必ずしも同じではありません。どちらも各尺度の最上位を指すのが普通ですが、SEVは深刻さ、Pは対応の順番を表すのが一般的です。一つの尺度を兼用しているチームもあります。その場合は、定義を明確にし、一貫して使ってください。

影響度×緊急度マトリクスとは何ですか？

業務への影響の広がりと時間的な切迫という二つの判断を組み合わせ、優先度を導く早見表のルールです。表で描くことも、この記事のように見出しと番号付きリストで書くこともできます。

チケットの優先度は誰が決めるべきですか？

合意したマトリクスに従って、サービスデスクが決めます。依頼者は影響と期限を説明します。指名された担当者は結果を変更でき、理由はチケットに記録します。

優先度のレベルはいくつ必要ですか？

障害用の四段階と、定型の依頼用の一段階で、たいていの組織には足ります。段階が多いと担当者が迷い、選択がぶれます。

障害対応の途中で優先度は変わりますか？

変わります。影響が広がったとき、回避策が効かなくなったとき、期限が現れたときは、優先度を上げて変更を記録します。回避策が見つかれば、下げられます。

ITILは影響度×緊急度マトリクスを必須としていますか？

ITILのガイダンスでは、優先度を影響度と緊急度の関数として説明するのが一般的です。ただしITILはプラクティスのフレームワークであり、そのまま写さなければならない規則集ではありません。自社の業務に合わせてレベルを調整してください。

次に読む記事

重大度と優先度が、サポート全体のプロセスのどこに位置づけられるかは、L1・L2・L3サポートレベルとITエスカレーションマトリクスのテンプレートの記事で詳しく説明しています。契約面については、「ITサポートにおけるSLAとは」をご覧ください。

*2026年10月28日に確認した出典：BrocentのSLAページ（brocent.com/sla）、Atlassianのインシデント管理ガイド重大度レベルのページ（atlassian.com/incident-management/kpis/severity-levels）。*

これらの指標をスライドではなく契約に盛り込みたい場合は。 Brocent のマネージドITサポートでは、SLA とユーザー単価の月額料金を香港・シンガポール・中国本土・米国について並べて公開しています。プランと料金を見るか、コンサルタントに相談してください。