2026年6月17日

監視アラートのエスカレーション設計｜夜間・休日障害を誰に・どう通知するか

エスカレーションアラート設定制作会社インシデント対応運用ノウハウ

「自分が休みの日に障害が起きたら？」という不安に答える

死活監視を導入してアラートを飛ばせるようになっても、次にぶつかるのが「誰に・いつ・どの経路で通知するか」というエスカレーション設計の問題です。担当者が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・リトライ・メンテナンスウィンドウ）の具体的な組み方は「アラート疲れを防ぐ監視設定」で詳しく解説しています。エスカレーションは「鳴らすべきものを確実に鳴らす」設計、アラート疲れ対策は「鳴らすべきでないものを黙らせる」設計で、両輪で機能します。

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分」の引き上げ時間が現場の対応速度に合っているか

エスカレーションの実行ログ（いつ・誰に通知が飛んだか）は、障害報告書の客観的な根拠としても使えます。報告書のまとめ方は「障害報告書テンプレート」を参照してください。

まとめ

監視アラートのエスカレーション設計は、「誰に・いつ・どの経路で」の3要素で組み立てます。

誰に: 一次（主担当）→二次（リーダー）→三次（責任者）の階層を作る
いつ: 検知0分→10分応答なし→30分未解決、の時間トリガーで引き上げる
どの経路で: 緊急度が上がるほど無視できないチャネル（Slack→メール→電話）へ切り替える
夜間・休日: 重大度でフィルタしてからエスカレートし、軽微な通知はquiet hoursで黙らせる

担当者が1人でも、エスカレーション設計があれば「休みの日に障害が起きても誰かに届く」体制を作れます。まずは無料プランで通知先を複数登録し、設定の詳細はドキュメントをご覧ください。制作会社向けの運用例はユースケース一覧で、よくある質問はFAQにまとめています。