ITエスカレーションマトリクスのテンプレート：機能的・階層的エスカレーションと連絡先、時間制限

結論から： エスカレーションマトリクスは、どんなときに障害をエスカレーションし、各レベルで誰が対応するかを定めた文書です。機能的エスカレーション（より高いスキルや別の専門を持つ人にチケットを渡す）と、階層的エスカレーション（より大きな権限を持つ人に知らせる）という二つの考え方を組み合わせます。下のテンプレートは、記入すべき項目を番号付きリストで示しているため、どんな文書やチケット管理ツールにも貼り付けて使えます。

ITの障害が長引いているとき、最も困る問いは「誰に連絡すればいいのか」です。エスカレーションマトリクスは、その答えを事前に用意しておくものです。各段階の責任者、チケットが次へ移るまでの持ち時間、知らせるべき相手を一覧にします。マトリクスがなければ、エスカレーションはたまたま当番だった人に左右され、遅れがちになります。

この記事では、エスカレーションマトリクスとは何か、機能的エスカレーションと階層的エスカレーションの違い、文書に何を書くべきかを説明します。そのうえで、コピーして使える番号付きリストのテンプレート、架空の名前を使った実例、マトリクスを生きたまま保つための短いチェックリストを示します。マネージドITの提供会社に、彼らのマトリクスについて何を尋ねるべきかにも触れます。

エスカレーションマトリクスとは何か

エスカレーションマトリクスは、いつエスカレーションを行い、各エスカレーションレベルで誰が障害に対応するのかを定めた文書、またはシステムです。これはAtlassianが、インシデント管理ガイドの「エスカレーションポリシー」のページで述べている定義です（2026年10月28日に確認）。同じページは、詳細さの度合いは組織によって大きく異なるとも述べています。単純な階層図で、各担当者がより高いスキルを持つ人にエスカレーションする組織もあれば、障害の種類や重大度ごとにどのチームに連絡するかを示す状況別のマトリクスを持つ組織もあります。万能な正解はなく、エスカレーションポリシーは厳格な規則ではなく指針として扱うよう勧めています。

ITサポートでは、マトリクスは通常、優先度ごとに次の五つの問いに答えます。

1. 最初にチケットを担当するのは誰か。
2. チケットを次へ移すまでの持ち時間はどれだけか。
3. 次に引き受けるのは誰か。
4. 対応に加わらなくても、知らせておくべき相手は誰か。
5. それぞれにどう連絡するか。営業時間外も含めて。

サポートの階層モデルとは別のものです。階層（L1・L2・L3）はスキルの段階を表し、マトリクスはそれらの間をいつ、どう移るか、そして誰がその上にいるかを定めます。先に階層モデルを知りたい方は、L1・L2・L3サポートレベルのガイドをご覧ください。

機能的エスカレーションと階層的エスカレーションの違い

この二つの用語は、ITILに沿ったサービスマネジメントで使われます。今回の記事では、有償のITIL公式文書を読み直してはいません。したがって以下の説明は、一般的な実務についての私たちの記述であり、引用ではありません。

機能的エスカレーション

機能的エスカレーションは、より専門的な知識や別のスキルを持つ人やチームにチケットを渡すことです。スキルの面で横または上への移動であり、職位の移動ではありません。

1. きっかけ：現在のレベルで解決できない、または、ネットワーク、セキュリティ、特定のアプリケーションチームなど、専門家が必要な場合。
2. 方向：L1からL2へ、L2からL3へ、L3からベンダーへ。
3. 知らせる相手：チケットを受ける専門家。正式に移管しない限り、チケットの責任者は変わりません。
4. 例：サービスデスクの担当者が、ファイアウォールの障害をネットワークエンジニアにエスカレーションする。

階層的エスカレーション

階層的エスカレーションは、情報、ときには判断を、より大きな権限を持つ人に上げることです。スキルではなく、職位の上への移動です。

1. きっかけ：障害が深刻、時間がかかりすぎている、または、費用の支出、外部の関与、顧客への通知など、現在の担当者の権限を超える判断が必要な場合。
2. 方向：チームリーダーからサービスマネージャーへ、IT責任者へ、役員へ。
3. 知らせる相手：状況を把握し、判断する必要があるかもしれないマネージャーや業務の責任者。
4. 例：サービスマネージャーが、合意した時間を過ぎてもP1が復旧しておらず、ベンダーの訪問には追加費用がかかることを、IT責任者に伝える。

実際のエスカレーションの多くは、この二つを同時に使います。P1の障害は、横に専門チームへ渡されると同時に、上にもマネージャーへ伝わり、対応の妨げになっている問題を取り除けるようにします。よいマトリクスは、二つの経路を紙面で分けて示し、自分がどちらを進んでいるかが分かるようにしています。

エスカレーションマトリクスに入れる項目

形式が何であれ、すべてのマトリクスで同じ基本項目を記録してください。

1. 優先度または重大度：SLAで定義したもの。設定に迷う場合は、重大度と優先度の違いのガイドをご覧ください。
2. サービスまたはシステム：適切な専門チームは、何が壊れているかで決まるためです。
3. レベル番号：第一線から最終レベルまで。
4. 役割と氏名：各役割に、指名した代理を置く。
5. 連絡手段：試す順に並べる。電話、チャット、メール。
6. 対応可能な時間帯：およびその時間外の待機体制。
7. このレベルでの制限時間：超えるとチケットが自動的に次へ移ります。
8. 通知先リスト：チケットがこのレベルに達したときに知らせる相手。
9. 決裁権限：このレベルが、相談せずに決めてよいこと。
10. 最終見直し日と、文書の責任者。

エスカレーションマトリクスのテンプレート

コピーして記入するためのテンプレートです。角括弧の中は、自分で選ぶ値です。例示した時間を標準だと受け取らないでください。自社のSLA、人員、事業へのリスクに基づいて決めます。

パート1：文書管理

1. マトリクスの名称：[会社名またはサービス名] ITエスカレーションマトリクス。
2. 責任者：[役割。例：IT責任者、サービスデリバリーマネージャー]。
3. 版数と日付：[版数と日付]。
4. 見直しの周期：[例：四半期ごと、および重大インシデントのあと]。
5. 適用範囲：[対象のサービス、拠点、顧客の一覧]。

パート2：優先度ごとの時間のきっかけ

優先度ごとに、初回応答の目標、最初のエスカレーションまでの制限時間、次のエスカレーションまでの制限時間を記録します。SLAの目標を使ってください。

P1（クリティカル）

1. [分。SLAから] 以内に初回応答する。
2. [分] 以内に解決しなければ、次のレベルへエスカレーションし、サービスマネージャーに通知する。
3. さらに [分] 以内に解決しなければ、IT責任者と業務の責任者に通知する。
4. 解決するまで、[分] ごとに影響を受けるユーザーへ状況を更新する。

P2（高）

1. [分。SLAから] 以内に初回応答する。
2. [時間] 以内に解決しなければ、次のレベルへエスカレーションする。
3. さらに [時間] 以内に解決しなければ、サービスマネージャーに通知する。
4. [時間] ごとに影響を受けるユーザーへ状況を更新する。

P3（中）

1. [分。SLAから] 以内に初回応答する。
2. [営業日] 以内に解決しなければ、次のレベルへエスカレーションする。
3. 少なくとも [営業日] ごとにユーザーへ状況を更新する。

P4（低）

1. [分。SLAから] 以内に初回応答する。
2. [営業日] 以内に解決しなければ、毎週のサービス会議で見直す。

パート3：機能的エスカレーションの経路

サービス領域ごとに、対応に入る順に担当者を並べます。領域ごとにこのブロックを繰り返します。

サービス領域：[例：エンドユーザー端末]

1. レベル1：[役割と氏名]、[連絡手段]、[対応時間帯]。
2. レベル2：[役割と氏名]、[連絡手段]、[対応時間帯]。
3. レベル3：[役割と氏名]、[連絡手段]、[対応時間帯]。
4. ベンダーまたは外部：[会社名、契約番号またはケース番号、サポート窓口、サポートレベル]。

サービス領域：[例：ネットワークとセキュリティ]

1. レベル1：[役割と氏名]。
2. レベル2：[役割と氏名]。
3. レベル3：[役割と氏名]。
4. ベンダーまたは外部：[詳細]。

サービス領域：[例：業務アプリケーション]

1. アプリケーション責任者：[役割と氏名]。
2. 技術リード：[役割と氏名]。
3. ベンダーサポート：[詳細]。

パート4：階層的エスカレーションの経路

障害が大きくなるにつれて知らせるべき人を、職位の低い順に並べます。

1. チームリーダー：[役割と氏名]。[条件。例：すべてのP1、または制限時間を過ぎたP2] のときに知らせる。
2. サービスデリバリーマネージャー：[役割と氏名]。[条件] のときに知らせる。
3. IT責任者または技術担当役員：[役割と氏名]。[条件。例：P1が二つ目の制限時間を超えた] ときに知らせる。
4. 影響を受けるサービスの業務責任者：[役割と氏名]。[条件。例：サービスが顧客に提供できない] ときに知らせる。
5. 経営スポンサー：[役割と氏名]。[条件。例：データ消失やセキュリティ事故、または法務・契約上のリスクを伴う停止] のときに知らせる。

パート5：時間に関係なく自動で発動する条件

1. セキュリティインシデントの疑い：直ちに [セキュリティ責任者] に通知し、セキュリティインシデントの手順に従う。
2. データ消失または漏えいの確認：直ちに [経営スポンサーとデータ保護の窓口] に通知する。
3. 同じ障害を [人数] 人以上のユーザーが報告：重大インシデントとして扱い、重大インシデントマネージャーを呼ぶ。
4. 人の安全または拠点の物理的なリスク：まず [施設または緊急連絡先] に連絡する。

パート6：時間外の体制

1. サービス時間帯：[例：8×5または24×7。契約から]。
2. 待機のローテーション：[保管場所、更新者、引き継ぎの確認方法]。
3. 時間外の連絡手段：[電話番号またはページングツール。メールだけにしない]。
4. 時間外に呼び出してよい条件：[例：P1とP2のみ]。
5. 待機担当者が [分] 以内に応答しない場合のバックアップ：[代理、その次にマネージャー]。

パート7：コミュニケーションのルール

1. 影響を受けるユーザーへの連絡担当：[役割]。
2. 上級管理職への連絡担当：[役割]。
3. 顧客や第三者への連絡担当：[役割。誰の承認が必要か]。
4. 更新の手段：[例：ステータスページ、チャットチャネル、メーリングリスト]。
5. 更新の形式：分かっていること、いま行っていること、次の更新の予定時刻。
6. 完了の連絡：判明している原因、適用した修正、今後の対応を記す。

パート8：障害のあと

1. すべてのエスカレーションを時刻とともにチケットに記録する。
2. [レベル] に達した障害は、次のサービス会議で振り返る。
3. 原因が不明、または再発している場合は、問題管理の記録を作成する。
4. 連絡先が誤っていた、制限時間が非現実的だった、手順が抜けていた場合は、このマトリクスを更新する。

架空の名前を使った実例

この例は架空のものです。各パートがどうつながるかを示すためだけのものです。

1. 09:02：サービスデスクのSamが、本社の誰も会計アプリケーションを開けないというチケットを登録します。Samはマトリクスに従って優先度をP1とし、パート4の定めどおり、チームリーダーのPriyaに知らせます。
2. 09:15：Samは基本項目を確認し、ユーザー側に問題はないと判断します。パート3では、このアプリケーションは業務アプリケーション領域に属するため、試した内容を列記した引き継ぎメモを付け、技術リードのDevへ機能的エスカレーションを行います。
3. 09:40：Devは、アプリケーションのデータベースサーバーが応答していないことを突き止め、パート3に載っているベンダーのサポート窓口に電話します。
4. 09:45：P1の最初の制限時間が来ます。パート4に従い、サービスデリバリーマネージャーのMariaに通知が入り、Priyaがユーザーへ最初の状況更新を送ります。
5. 10:30：二つ目の制限時間が来ます。MariaがIT責任者と、このアプリケーションの責任者である経理担当役員に知らせます。経理担当役員は、ベンダーの緊急対応費用を承認します。これはDevの権限を超える判断でした。
6. 11:20：ベンダーがサービスを復旧します。すべてのエスカレーションとその時刻を記した備考とともに、チケットが完了されます。原因を調べるために問題管理の記録も作られます。

各段階でマトリクスがどう役立ったかに注目してください。Samは誰に電話するかを迷わず、Devは承認を待たずにベンダーへ連絡でき、経理担当役員は適切なタイミングで状況を知って判断できました。

エスカレーションマトリクスを使えるまま保つには

一度書いて放置されたマトリクスは有害です。人々がそれを信じ、すでに退職した人のところへ誘導されてしまうからです。短い定例作業で、生きた状態を保ってください。

1. 四半期ごとに見直し、重大インシデントのあとにも見直す。
2. すべての連絡先を確認する。見直しの際に、一人ずつ電話またはメッセージで確かめる。
3. 時間外の経路を試す。待機用の電話を含めた計画的な訓練を行う。
4. 最新版を一つだけ公開し、主要システムが止まっても全員が見られる場所に置く。
5. マトリクスどおりに行われなかったケースを記録し、理由を尋ねる。理由は通常、マトリクスの抜けにあります。
6. 提供会社と共有し、先方のマトリクスも見せてもらう。

よくある失敗

1. 役割ではなく個人名で書く。人は異動します。役割と担当者、そして代理を置いてください。
2. 連絡手段が一つしかない。飛行機に乗っている人へのメールでは、何もエスカレーションできません。
3. 誰も守れない制限時間。いつも破られる制限時間は、無視することを皆に教えてしまいます。
4. 階層的な経路がない。技術チームは横にエスカレーションし、マネージャーは障害をユーザーから初めて知ります。
5. 解除の方法がない。サービスが復旧したあと、マトリクスをどう解除するかを書いておきます。
6. マトリクスがサービスデスクのツールの中にしかない。そのツール自体が止まっていれば、誰も読めません。

マネージドITの提供会社に、エスカレーションについて尋ねること

提供会社がITサポートの一部を担当する場合、先方のエスカレーションマトリクスは、自社のマトリクスの一部になります。契約前に尋ねる価値のある質問は次のとおりです。

1. マトリクスと、優先度ごとの制限時間を見せてもらえますか。
2. その中に自社のどの担当者が入り、呼び出されたら何をすることになりますか。
3. 提供会社のチームで、階層ごとのマネージャーは誰ですか。
4. 時間外にどう連絡し、何が時間外のエスカレーションにあたりますか。
5. 提供会社はいつベンダーにエスカレーションし、追加費用は誰が承認しますか。
6. 月次レポートで、エスカレーションの履歴をどう確認できますか。

Brocentは、SLAページで応答目標を公開しています（2026年10月28日に確認）。初回応答は、P1とP2が15分、P3が30分、P4とP5が60分で、標準の8×5またはプレミアムの24×7というサービス時間帯に適用され、契約条件に従います。P1の応答時間は公開されており、マネージドITサポートのプランとユーザー単価でも確認できます。各優先度の意味は、ITサポートSLAのP1からP4の優先度で、また24×7のヘルプデスクIT支援の概要でも説明しています。自社のチームにとってエスカレーションがどう機能するか相談したい場合は、お問い合わせください。

よくある質問

エスカレーションマトリクスとは何ですか？

障害をいつエスカレーションすべきか、各レベルで誰が対応するか、各レベルの持ち時間、誰に知らせるか、どう連絡するかを定めた文書です。

機能的エスカレーションと階層的エスカレーションの違いは何ですか？

機能的エスカレーションは、より専門的なスキルを持つ人へチケットを渡すことです。階層的エスカレーションは、判断を下したり、対応の妨げになっている問題を取り除いたりできる、より大きな権限を持つ人に知らせることです。深刻な障害では、通常この二つが同時に必要です。

エスカレーションマトリクスには何段階必要ですか？

ITでは、第一線、第二線、第三線またはベンダー、それに管理職のレベルを加えた三から五段階が一般的です。段階が多いと判断が遅くなり、少ないとエンジニアと役員のあいだに空白が生じることがあります。

制限時間はどう決めればよいですか？

自社のSLAと対応能力に基づいて決めます。この記事を含め、どのテンプレートの数字も仮の値です。公開している応答目標から出発し、引き継ぎごとに余裕を加えます。

エスカレーションマトリクスの責任者は誰にすべきですか？

役割として明確に指名します。通常はサービスデリバリーマネージャーかIT責任者で、見直しと、すべての連絡先が最新であることに責任を持ちます。

エスカレーションマトリクスと待機（オンコール）のスケジュールは何が違いますか？

待機スケジュールは、ある時刻に誰に連絡がつくかを示します。マトリクスは、どの順番で、いつ人を呼ぶかを示します。二つは互いに参照し合うようにします。

セキュリティインシデント用に別のマトリクスは必要ですか？

多くの場合は必要です。少なくとも別のパートを設けてください。セキュリティ事象では、セキュリティ責任者やデータ保護の窓口など関わる人が異なり、通知の義務も異なるためです。

マトリクスは表にできますか？

できます。スプレッドシートや文書では、格子状に表示されることがよくあります。構造は同じです。この記事は、どのツールにもコピーできるよう、番号付きリストを使いました。

次に読む記事

優先度の決め方は、重大度と優先度の違いをご覧ください。マトリクスがつなぐスキルの階層は、L1・L2・L3サポートレベルで説明しています。P1が大規模な障害に発展したときの次の段階は、重大インシデント管理プロセスです。自社チームと提供会社の責任分担を考えている方は、SLAとOLAの違いをご覧ください。

*2026年10月28日に確認した出典：Atlassianインシデント管理ガイド「エスカレーションポリシー」のページ（atlassian.com/incident-management/on-call/escalation-policies）、BrocentのSLAページ（brocent.com/sla）。*

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