2026年7月9日

PagerDutyでオンコール通知を設定する方法｜スケジュール・エスカレーション・Events API

バックアップ・監視

PagerDuty でオンコール通知を動かすには、「ユーザーの通知ルール」「オンコールスケジュール」「エスカレーションポリシー」「サービスとインテグレーション」の4つを順につなぐ必要があります。どれか1つが欠けると、アラートは届いても誰にも電話が鳴らない、という状態になります。この記事では、それぞれの役割と設定の考え方、Events API v2 を使ったテスト送信、監視ツールや WordPress からの連携、通知疲れを防ぐコツまでを説明します。

通知が届くまでの流れを先に押さえる

PagerDuty の設定画面は項目が多いので、まず全体の流れを頭に入れておくと迷いません。

監視ツールなどが、サービスに付けたインテグレーションへイベントを送る
サービスがイベントを受け取り、インシデントを作る
サービスに割り当てたエスカレーションポリシーが、最初に連絡する相手を決める
ポリシーの第1段階にスケジュールが入っていれば、その時刻のオンコール担当者が選ばれる
選ばれた人の通知ルールに従って、アプリのプッシュ通知、SMS、電話などが順に送られる
一定時間内に誰も応答（Acknowledge）しなければ、次の段階の人へエスカレーションする

設定は逆順、つまり「人 → スケジュール → ポリシー → サービス」の順に作るとスムーズです。画面の名称や配置は更新で変わることがあり、使える機能は契約プランによって異なります（2026年10月現在）。ここでは役割を中心に説明します。

手順1：ユーザーの連絡方法と通知ルールを設定する

各ユーザーはプロフィールで連絡方法（メール、電話番号、SMS、モバイルアプリ）を登録し、「インシデントが起きたら何分後にどの方法で知らせるか」という通知ルールを決めます。

夜間のオンコールを想定すると、次のような段階を組むことが多いです。

発生直後：モバイルアプリのプッシュ通知
数分後：SMS
さらに数分後：電話

ここでのつまずきは、スマートフォン側の設定です。おやすみモードや集中モードで通知が止まると、PagerDuty の設定が正しくても気づけません。モバイルアプリには、マナーモード中でも鳴らすための設定が用意されている場合があるので、OS の通知設定と合わせて確認してください。電話番号は国番号付きで登録し、登録後にテスト通知を送って、実際に鳴ることを確かめておきます。

インシデントには緊急度（High / Low）があり、通知ルールも緊急度ごとに分けて設定できます。夜中に電話で起こすのは High だけ、Low はメールのみ、と分けておくと、オンコールの負担を抑えられます。

手順2：オンコールスケジュールを作る

スケジュールは「いつ誰が担当か」を表すカレンダーです。作成時に決めるのは主に次の項目です。

ローテーションの参加者と順番：2〜3人以上で回すのが現実的です
交代の周期：1週間交代が一般的。日次交代は引き継ぎの手間が増えます
交代の時刻：月曜の朝など、引き継ぎをしやすい時間にする
タイムゾーン：チームの所在地に合わせる。メンバーの表示タイムゾーンと混同しない

平日の日中と夜間・休日で担当を分けたい場合は、レイヤーを重ねて表現します。休暇などで一時的に交代するときはオーバーライドを使い、元のローテーションは崩さないのが運用のコツです。

作成後はスケジュールのプレビューで、担当者のいない空白の時間帯がないかを確認してください。空白があると、その時間に起きたインシデントは第1段階で誰にも通知されません。

手順3：エスカレーションポリシーを作る

エスカレーションポリシーは「最初に誰へ知らせ、応答がなければ次に誰へ回すか」の決まりです。典型的な構成は次のとおりです。

第1段階：プライマリのスケジュール
第2段階：セカンダリのスケジュール、または責任者
各段階で応答を待つ時間：数分〜十数分程度
最後まで応答がない場合に、最初から繰り返す回数

第1段階に個人を直接入れると、その人の休暇中に通知が止まります。段階には個人ではなくスケジュールを入れるのが基本です。

手順4：サービスとインテグレーションを作る

サービスは「監視対象のまとまり」です。たとえば「本番 WordPress サイト」というサービスを作り、手順3のエスカレーションポリシーを割り当てます。

次に、サービスへインテグレーションを追加します。汎用的に使えるのは Events API v2 で、追加するとインテグレーションキー（ルーティングキー）が発行されます。Prometheus の Alertmanager、Uptime Kuma、Healthchecks.io など、多くの監視ツールはこのキーを貼るだけで連携できます。

混同しやすいのが、REST API 用の API キーです。イベントを送るのはインテグレーションキーで、PagerDuty の設定を操作する API とは別物です。どちらも秘密情報なので、リポジトリに含めないでください。

手順5：Events API v2 でテスト送信する

設定がつながったかは、curl でイベントを送ると確認できます。

curl -sS -X POST https://events.pagerduty.com/v2/enqueue \
  -H 'Content-Type: application/json' \
  -d '{
    "routing_key": "your-integration-key",
    "event_action": "trigger",
    "dedup_key": "example-com-http-500",
    "payload": {
      "summary": "example.com がHTTP 500を返しています",
      "source": "monitor-01",
      "severity": "critical"
    }
  }'

受け付けられると、"status":"success" と dedup_key を含むJSONが返ります。数秒〜数十秒でインシデントが作られ、オンコール担当者のスマートフォンが鳴れば、手順1〜4の設定がすべてつながっています。

dedup_key は重複をまとめるための値です。同じキーでイベントを何度送っても、未解決のインシデントは1件にまとまります。復旧したら同じキーで resolve を送ります。

curl -sS -X POST https://events.pagerduty.com/v2/enqueue \
  -H 'Content-Type: application/json' \
  -d '{
    "routing_key": "your-integration-key",
    "event_action": "resolve",
    "dedup_key": "example-com-http-500"
  }'

severity には critical、error、warning、info を指定できます。イベントオーケストレーションなどのルールで重大度に応じて緊急度を変えられる場合があり（使える機能はプランによります）、そうしておくと warning で夜中に電話が鳴ることを避けられます。

監視ツールや WordPress からつなぐ

Alertmanager の場合、受信先の設定は次のようになります。

receivers:
  - name: pagerduty-critical
    pagerduty_configs:
      - routing_key: your-integration-key
        send_resolved: true

WordPress の死活監視は、WordPress の外から行うのが原則です。サイトやサーバーが落ちていれば、WordPress 自身は通知を送れないためです。外形監視ツールや Healthchecks.io から PagerDuty へつなぎます。

一方、「バックアップの失敗」「決済連携のエラー」のように、WordPress が動いている状態で起きる異常は、WordPress 側から送る方法もあります。キーは wp-config.php の定数に置き、コードに直接書かないでください。

<?php
// wp-content/mu-plugins/pd-notify.php
// wp-config.php で define( 'MY_PD_ROUTING_KEY', 'your-integration-key' ); を設定しておく
function my_pd_trigger( $summary, $dedup_key, $severity = 'error' ) {
    if ( ! defined( 'MY_PD_ROUTING_KEY' ) ) {
        return false;
    }
    $response = wp_remote_post( 'https://events.pagerduty.com/v2/enqueue', array(
        'timeout' => 10,
        'headers' => array( 'Content-Type' => 'application/json' ),
        'body'    => wp_json_encode( array(
            'routing_key'  => MY_PD_ROUTING_KEY,
            'event_action' => 'trigger',
            'dedup_key'    => $dedup_key,
            'payload'      => array(
                'summary'  => mb_substr( $summary, 0, 1000 ),
                'source'   => wp_parse_url( home_url(), PHP_URL_HOST ),
                'severity' => $severity,
            ),
        ) ),
    ) );
    return ! is_wp_error( $response ) && 202 === wp_remote_retrieve_response_code( $response );
}

呼び出す側では dedup_key を固定の文字列にし、同じ異常で何十件ものインシデントが作られないようにします。通知本文に個人情報や秘密情報を含めないことも大切です。導入はステージング環境で試してから本番へ反映してください。

通知疲れを防ぐ

オンコールが続かない最大の原因は、対応不要なアラートで起こされることです。

緊急度を分け、High は「今すぐ人が動く必要があるもの」に限る
dedup_key で同じ障害をまとめる
計画メンテナンス中は、メンテナンスウィンドウなどで通知を止める
毎週、鳴ったインシデントを振り返り、不要なアラートは監視側の閾値を見直す

まとめ

通知は「人の通知ルール → スケジュール → エスカレーションポリシー → サービス」の順につながっている
スケジュールには空白を作らず、ポリシーの段階には個人ではなくスケジュールを入れる
監視ツールとは Events API v2 のインテグレーションキーでつなぎ、curl のテスト送信で通知まで確かめる
dedup_key と緊急度の使い分けで、通知の重複と夜間の不要な呼び出しを減らす
WordPress の死活監視は外部から行い、WordPress 側から送るのは動作中に起きる異常に限る