監視アラートのエスカレーション設計｜誰に・何分後・どの経路で通知するか
「自分が休みの日に障害が起きたら？」という不安に答える
死活監視を導入してアラートを飛ばせるようになっても、次にぶつかるのが「誰に・いつ・どの経路で通知するか」というエスカレーション設計の問題です。担当者が1人で全クライアントを抱えている制作会社では、「自分が休みの日や寝ている間に障害が起きたらどうなるのか」という不安がつきまといます。
本記事では、監視アラートのエスカレーション（段階的な通知の引き上げ）を制作会社向けに整理し、夜間・休日・担当者不在時でも障害を取りこぼさない仕組みをMiterlで作る方法を解説します。通知先の設定そのものは「SlackとChatworkに死活監視アラートを飛ばす設定方法」で扱っているので、本記事は「設定した通知をどう段階設計するか」に焦点を当てます。
なぜエスカレーション設計が必要なのか
通知先を1つ登録しただけの状態には、3つの穴があります。
| 穴 | 起きること |
|---|---|
| 一次担当者が気づかない | 寝ている・運転中・別作業に集中していて通知を見逃す |
| 通知経路が1本しかない | Slackが落ちている・スマホが圏外だと通知が届かない |
| 重大度の区別がない | 軽微な瞬断も致命的なダウンも同じ通知音で、本当の障害が埋もれる |
エスカレーション設計とは、これらの穴を「一定時間応答がなければ次の担当者・次の経路へ自動的に引き上げる」ルールで塞ぐことです。クライアントを10件・20件と抱える制作会社にとっては、SLAを守るための生命線になります（複数サイトの通知整理は「複数サイトを効率的に監視するコツ」も参照）。
エスカレーション設計の3要素
エスカレーションは「誰に・いつ・どの経路で」の3要素で組み立てます。
1. 誰に（通知先の階層）
- 一次: 主担当エンジニア（普段サイトを触っている人）
- 二次: チームリーダー／別のエンジニア（一次が応答できないとき）
- 三次: 経営者・代表（重大障害が長時間続くとき）
2. いつ（時間によるトリガー）
- 障害検知から 0分: 一次担当へ即時通知
- 5〜10分応答なし: 二次担当へ引き上げ
- 30分以上未解決: 三次（責任者）へ引き上げ
3. どの経路で（チャネルの多重化）
緊急度が上がるほど、より「無視できない」経路へ切り替えます。
| レベル | 推奨チャネル | 理由 |
|---|---|---|
| 一次 | Slack / Chatwork | 業務時間中は最も気づきやすい |
| 二次 | メール + Slackメンション | 経路を分散して見逃しを防ぐ |
| 三次 | 電話 / SMS（手動） | 確実に人を起こせる最終手段 |
レベル別エスカレーションの設計例
制作会社の現実的なテンプレートとして、以下のような3段階を基本形にすると運用が安定します。
=== エスカレーションルール（例）===
【レベル1】障害検知 → 即時
通知先: 主担当（Slack #alerts-clientA）
目的: まず本人が気づいて初動を始める
【レベル2】10分応答なし → 引き上げ
通知先: チームリーダー（メール + Slackメンション）
目的: 一次が対応できない場合のバックアップ
【レベル3】30分未解決 → 引き上げ
通知先: 代表（電話・SMS）
目的: 重大障害をクライアントより先に把握し、初動連絡を判断する
復旧後の事後対応（クライアントへの報告）まで含めた全体の流れは「Webサイト障害対応フロー｜制作会社のための初動から報告まで」で解説しています。
夜間・休日のエスカレーション設計
エスカレーション設計でもっとも悩むのが「夜間・休日」です。ここには相反する2つの要求があります。
- 取りこぼしたくない: 決済サイトやECサイトの夜間ダウンは売上に直結する
- 疲弊したくない: 軽微な瞬断で毎晩起こされてはチームが持たない
この矛盾は、**「重大度でフィルタしてからエスカレートする」**ことで解決します。
| サイト種別 | 夜間の方針 |
|---|---|
| EC・決済・予約系 | 夜間も即時エスカレーション（売上影響が大きい） |
| コーポレート・ブログ系 | 夜間はサマリ通知に留め、翌朝対応 |
| 全種別共通 | 「1分の瞬断」はリトライ確認後のみ通知（誤検知を除外） |
軽微な通知を夜間に鳴らさない設定（quiet hours・リトライ・メンテナンスウィンドウ）の具体的な組み方は「アラート疲れを防ぐ監視設定」で詳しく解説しています。エスカレーションは「鳴らすべきものを確実に鳴らす」設計、アラート疲れ対策は「鳴らすべきでないものを黙らせる」設計で、両輪で機能します。
二次担当がいない少人数・ひとり体制の場合
エスカレーションの解説は、複数人のオンコール体制を前提にしたものがほとんどです。しかし制作会社の実態としては「そのサイトを分かっているのは自分ひとり」という体制が珍しくなく、二次担当に引き上げても対応できる人がいない、という状況が起こります。この場合でもエスカレーションが無意味になるわけではなく、各レベルに載せるものが変わるだけです。
| 不在のレベルを代替する方法 | 実際に得られるもの |
|---|---|
| 人ではなくチャネルを引き上げる | 一次はSlack、二次は夜間に挙動が異なる経路（おやすみモードを貫通するメール、電話レベルの通知）へ。同じ人に対して気づく機会を2回作る |
| 他社との相互バックアップ | ひとり体制の制作会社どうしで「アラートに気づいたら相手に電話する」検知だけの相互協定を結ぶ。相手は復旧作業をせず、起こす役に徹する |
| クライアントを三次に置く | 長時間化した場合にN分後で直接連絡する、と事前に取り決めておく。抵抗を感じる設計だが、30分時点で知らされたクライアントは90分後に自分で気づいたクライアントよりはるかに冷静である |
| ステータスページによる受動的な通知 | 誰も起きていない時間帯でも、自動更新されるステータスページなら深夜2時のクライアントの疑問に答えられる（ステータスページの費用対効果） |
守るべきは人数ではなく応答確認（acknowledgment）のタイマーです。ひとり体制であっても「10分応答がなければ通知経路を引き上げる」というルールがあるだけで、障害が朝まで放置される事態を防げます。人員は後から各レベルに足せます。いま設計しておくべきなのは時間の構造のほうです。
ルールを形骸化させない文書化
エスカレーションのルールが担当者の頭の中にしかない場合、その担当者と連絡が取れなくなった瞬間に機能しなくなります——それはまさに、このルールが備えていたはずの状況です。クライアントごとに1ページの文書を、作業する場所の近くに置いてください。
=== エスカレーションルール: ○○様 ===
重要度: 高（EC・売上影響あり）
夜間方針: 24時間即時エスカレーション
一次: ◇◇ / Slack #alerts-clienta / 即時
二次: ◇◇ / メール + SMS / 応答なし10分後
三次: ◇◇ / 電話 / 未解決30分後
クライアント連絡: ○○様 / 000-0000-0000 / 30分経過で直接架電
メンテナンス枠: 日曜 02:00-04:00 JST（アラート抑止）
最終見直し: 2026-07-01
見た目以上に重要なのが「最終見直し」の行です。半年前に退職した担当者が残っているルールは、ルールが無い状態よりも危険です。誰にも届いていないのに「誰かに通知されている」と信じ込ませてしまうためです。
Miterlでのエスカレーション実装
Miterlでは「アラート連絡先」を複数登録し、モニターごとに紐付けることでエスカレーションの土台を作ります。
通知先（アラート連絡先）をレベル別に用意する
ダッシュボードで「一次（Slack）」「二次（メール）」といった連絡先を作成しておき、APIで一覧とIDを取得します。
# 登録済みのアラート連絡先一覧とIDを取得する
curl -s "https://miterl.com/api/v1/alert-contacts" \
-H "Authorization: Bearer YOUR_API_KEY" \
| jq -r '.data[] | "\(.id)\t\(.type)\t\(.name)"'
出力例：
1 slack 一次：主担当Slack
2 email 二次：チームリーダー宛メール
3 slack 三次：代表メンション
モニターに複数の連絡先を紐付ける
重大度の高いモニター（EC・決済系）には、一次〜三次のすべての連絡先を紐付けて多重化します。
# ECサイトのモニターに一次〜三次の通知先をまとめて紐付ける
curl -s -X PATCH "https://miterl.com/api/v1/monitors/1" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"alert_contact_ids": [1, 2, 3]}'
夜間の軽微アラートを抑制する
会社全体の静音時間（quiet hours）を設定すると、夜間は重大なダウンのみが通知され、軽微なアラートは翌朝に回せます。これにより「夜間も即時エスカレートすべき重大障害」だけを夜間チャネルに残せます。
# 現在の監視対象と通知先の対応を一覧で確認する
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
-H "Authorization: Bearer YOUR_API_KEY" \
| jq -r '.data[] | "\(.name)\t→ contacts: \(.alert_contact_ids // [])"'
API経由で通知先そのものを新規作成することはできませんが、ダッシュボードで作成した連絡先のIDを使えば、「どのサイトを・どのレベルの誰に飛ばすか」をプログラムから一括設定できます。
エスカレーションを形骸化させないために
ルールを作っても運用されなければ意味がありません。次の3点を定期的に見直すことで、エスカレーション設計を機能させ続けられます。
- 連絡先の棚卸し: 退職・担当変更で無効になった通知先が残っていないか
- テスト通知: 四半期に一度、二次・三次まで実際に通知が届くか試験する
- しきい値の調整: 「10分／30分」の引き上げ時間が現場の対応速度に合っているか
エスカレーションの実行ログ（いつ・誰に通知が飛んだか）は、障害報告書の客観的な根拠としても使えます。報告書のまとめ方は「障害報告書テンプレート」を参照してください。
よくある質問
何分でエスカレーションすべきですか？
二次は「応答なし10分」、三次は「未解決30分」が出発点の目安です。そのうえで現場の対応速度に合わせて調整してください。一次が常に2分で応答している体制なら10分は緩すぎますし、逆に応答に15分かかるのが普通なら10分での引き上げは無駄な通知を増やすだけです。
エスカレーションとアラート疲れ対策はどう違いますか？
同じ仕組みの両輪です。エスカレーションは「鳴らすべきものを確実に鳴らす」設計、アラート疲れ対策は「鳴らすべきでないものを黙らせる」設計です。必ずセットで設計してください。ノイズの多いアラートの上にエスカレーションを重ねると、ノイズがエスカレートするだけになります（アラート疲れを防ぐ監視設定）。
担当者が自分ひとりでもエスカレーションは組めますか？
組めます。人ではなくチャネルを引き上げてください。一次はSlack、二次は夜間に挙動が異なる経路へ振り分け、加えて他社との検知だけの相互バックアップも有効です。重要なのは応答確認のタイマーであり、人数は後から足せます。
クライアントをエスカレーション先に含めてよいですか？
長時間化した場合に限り、事前の取り決めとして含めるのが適切です。「30分経過で直接架電する」と決めておけば、復旧作業をしながらその判断を迫られずに済みます。その場の判断に委ねないことが肝心です。
夜間の通知を減らしつつ重大な障害は逃さないには？
一律に黙らせるのではなく、重大度でフィルタしてからエスカレートします。EC・決済・予約系は時間帯を問わず即時、コーポレート・ブログ系は翌朝までサマリに留めます。全種別共通で、リトライ確認を必須にして1分の瞬断では誰も起こさない設定にします。
エスカレーションルールはどのくらいの頻度で見直すべきですか？
四半期に一度、二次・三次まで実際に届くテスト通知とあわせて見直します。最も多い失敗はタイマーの設定ミスではなく、退職した担当者の連絡先が残っていることです。誰にも届いていないのに「届いている」と思い込む状態が生まれます。
まとめ
監視アラートのエスカレーション設計は、「誰に・いつ・どの経路で」の3要素で組み立てます。
- 誰に: 一次（主担当）→二次（リーダー）→三次（責任者）の階層を作る
- いつ: 検知0分→10分応答なし→30分未解決、の時間トリガーで引き上げる
- どの経路で: 緊急度が上がるほど無視できないチャネル（Slack→メール→電話）へ切り替える
- 夜間・休日: 重大度でフィルタしてからエスカレートし、軽微な通知はquiet hoursで黙らせる
- 二次担当がいない場合: 人ではなく通知経路を引き上げ、応答確認のタイマーだけは必ず残す。障害が朝まで放置される事態を防ぐのはこの部分である
担当者が1人でも、エスカレーション設計があれば「休みの日に障害が起きても誰かに届く」体制を作れます。まずは無料プランで通知先を複数登録し、設定の詳細はドキュメントをご覧ください。制作会社向けの運用例はユースケース一覧で、よくある質問はFAQにまとめています。
エスカレーションを正しく機能させるためには、「障害を早い段階で捕捉できる監視設定」が前提になります。特にHTTP応答の異常——レスポンスタイムの遅延・ステータスコードの変化——を素早く検知する仕組みを整えておくと、エスカレーションのタイマーがより早いタイミングから始まります。「レスポンスタイム監視ガイド：HTTP応答障害を早期検知する方法」で監視設定の具体的な手順を確認してください。ステータスコード別（4xx/5xx）のアラート判定の組み方は「HTTP応答障害を検知する監視設定ガイド」もあわせてご覧ください。