PagerDuty Event Orchestration の学び方と留意点

目次

• はじめに
• 学ぶ順番: 5段階に分け、手を動かすのは3段階目から
• ステップ1: イベントの流れを掴む
• ステップ2: 画面の全体像を掴む
• ステップ3: 最小構成で1本だけ作って動かす
• ステップ4: 実践パターンを見る
• ステップ5: 自分の環境に設計を落とす
• 触る前に知っておきたい3つの留意点
• おわりに
• 参考リンク

はじめに

こんにちは。
KDDIアイレットの松﨑です。

PagerDuty の Event Orchestration は、アラートの振り分けやノイズ削減を PagerDuty 側で完結させられる機能です。
監視ツール側の設定を触らずにノイズを減らせるため、運用改善の打ち手として強力です。

一方で、どこから手を付ければいいのか分かりにくい機能でもあります。

理由は2つあると思っています。
公式ドキュメントは機能ごとに整理されているため、初めて触る人は読む順番を自分で組み立てる必要があること。
そして画面の階層が深く、どのタブで何を設定するのかが最初は掴みづらいことです。

私は監視自動化の案件でこの機能を本番導入まで進めました。
その過程で「先にこれを知っていれば早かった」と思った点がいくつもあります。

この記事では、公式ドキュメントのどれをどの順で読むか、各段階で何に注目するかを整理します。
PagerDuty Event Orchestration をテーマにしたシリーズの第1回です。

この記事のゴール

• 公式ドキュメントのどれを、どの順で読めばいいかが分かる
• 各段階で何に注目すべきかが分かる
• 触る前に知っておきたい留意点が分かる

対象読者

• PagerDuty を運用に入れていて、アラートのノイズ削減や振り分けをこれから設計する人
• Event Orchestration の存在は知っているが、手を付けられていない人

なお、この記事は「学ぶ順番」に絞ります。
個々の機能の設定手順は公式ドキュメントが充実しているので、そちらへのリンクを示します。

前提

• 記載内容は 2026年10月時点の公式ドキュメントに基づきます
• 全プランで使えるのは、Service Orchestration・Service Routes（ルーティング）・Global Integration Keys・優先度と重要度の設定までです。
  抑止、時間帯や件数の条件、変数、動的ルーティング、Global Orchestration は PagerDuty AIOps アドオンが必要です（出典: Event Orchestration Pricing Tiers）

学ぶ順番: 5段階に分け、手を動かすのは3段階目から

先に全体像です。

大事なのは、いきなり本番のルールを書き始めないことです。
ステップ3で「1条件・1アクション」の最小構成を1本作り、動くことを確認する段階を必ず挟みます。

この段階を踏んでいれば、条件式でつまずいたときに「条件が悪いのか、そもそもイベントが届いていないのか」を切り分けられます。
踏んでいないと、疑うべき箇所が一気に増えます。

ステップ1: イベントの流れを掴む

読むものは3本です。

• Event Orchestration
• Event Management
• PagerDuty AIOps Quickstart Guide

この段階で押さえるのは3点だけです。

1. イベント（event）からアラート（alert）、アラートからインシデント（incident）という流れ

PagerDuty に送られてくるのはイベントです。
イベントはアラートになり、アラートはインシデントになります。
Event Orchestration が触るのはこの一番手前のイベントの段階です。

ここを掴んでおくと、後で「なぜインシデントが作られないのか」を段階ごとに追えるようになります。

2. 「イベントをどう処理するか」が Orchestration の役割

通知先を決めるのはエスカレーションポリシーの仕事です。
Orchestration が決めるのは「そのイベントをインシデントにするのか、どのサービスに送るのか、内容を書き換えるのか」です。

役割の境界を混ぜないことが、後の設計で効いてきます。

3. 構成要素の違い

構成要素には Global Orchestration・Service Routes・Service Orchestration の3つがあります。
それぞれ、書ける場所と適用範囲が違います。
このうち Global Orchestration は PagerDuty AIOps アドオンが必要です。
使い分けはシリーズの第3回で詳しく扱います。

ここまでの3点を1枚にすると、次のようになります。

図: Event Orchestration でのイベントの流れ（筆者作成）

この段階でやっておくと後が楽になること

現在の監視ツールから PagerDuty へ、どういう経路でイベントが飛んできているかを図にしておくことを勧めます。

理由は、Orchestration をどこに置くかがこの経路で変わるからです。
特にメール経由の流入があるかどうかで、判断が変わります（第3回で扱います）。

ステップ2: 画面の全体像を掴む

PagerDuty University に Event Orchestration のコースがあります。
約50分で、無料の登録で受講できます。

注目したいのは3点です。

• Conditions（条件）をどこに、どう書いているか
• Routing（ルーティング）でサービスの振り分けをどこで行っているか
• どの条件にもマッチしなかったイベントがどう扱われるか

3つ目が特に重要です。
ここの既定値を知らないまま設定すると、アラートが上がらない状態を作りかねません（後述します）。

視聴後は、イベントの受信からルールの評価・ルーティングまでの流れを人に説明できるレベルで図に描いてみるといいです。
描けない部分が、まだ理解できていない部分です。

ステップ3: 最小構成で1本だけ作って動かす

ここから手を動かします。
やることは次の4つです。
画面ごとの詳しい手順は、次回（第2回）のハンズオンで紹介します。
ここでは、迷わないための道筋だけを示します。

メニューの名前は 2026年10月時点の公式ドキュメントに合わせています。
Event Orchestration は AIOps というメニューの下にありますが、ここで使う Service Routes は AIOps アドオンが無くても使えます。
プランによって表示が違う場合があります。

手順1: テスト用サービスを作る

インシデントが立っても誰にも迷惑がかからないサービスを1つ作ります。
ポイントは3つです。

• エスカレーションポリシーは自分だけに通知するものにする（本番の当番に通知が飛ばないようにする）
• Integrations の画面では、何も選ばずに「Create service without an integration」で作ってよい（イベントは Orchestration 経由で届けるため）
• PagerDuty AIOps が有効なアカウントでは、Alert Grouping と Auto-pause を切っておく

Alert Grouping はテストイベントを1つのインシデントに束ね、Auto-pause は通知を一時的に止めます。
どちらも、テストの結果を見分けにくくする原因になります。
詳しくは第2回で扱います。

手順2: Orchestration を作り、Integration Key を控える

「+ New Orchestration」で名前を付けて保存し、Integrations タブに表示される Integration Key を控えます。
これがテストイベントの送り先になります。

手順3: ルーティングのルールを1本作る

Service Routes で「New Service Route」を選び、次のように設定します。
1条件・1アクションのルールです。

• 送り先（What service should events route to?）: 手順1のテスト用サービス
• 条件（When should events be routed here?）: 「If events match certain conditions」を選び、severity が critical に一致する条件にする（PCL で書くと event.severity matches 'critical'）

ここでは Service Routes だけを使うので、PagerDuty AIOps アドオンが無くても試せます（Global Orchestration のルールは使いません）。

手順4: テストイベントを送って結果を確かめる

テストイベントは Events API v2 で送れます。
手順2で控えた Integration Key を routing_key に指定します。

curl --request POST \
  --url https://events.pagerduty.com/v2/enqueue \
  --header 'Content-Type: application/json' \
  --data '{
    "routing_key": "<INTEGRATION_KEY>",
    "event_action": "trigger",
    "payload": {
      "summary": "test event",
      "source": "test-source",
      "severity": "critical"
    }
  }'

続けて "severity": "critical" を "severity": "warning" に変え、もう1回送ります。
期待する結果は次のとおりです。

届いたイベントは、Orchestration の画面の Recent Events（直近10件）で確認できます。
インシデントが立ったかどうかは Incidents の画面で見ます。

この段階で押さえる3点

• 条件は payload（イベントの中身）に対して評価される。
  画面に見えているインシデントのタイトルではなく、送られてきた JSON の中身が判定対象です
• 条件にマッチしなかったイベントは catch-all rule に落ちる
• 最初から複雑にしない。
  1条件・1アクションで動くことを確認してから足していく

手順4でマッチしないイベントも送ったのはこのためです。
マッチしない側を試さないと、次章の留意点1にはまります。

ステップ4: 実践パターンを見る

動くことを確認できたら、実務で使うパターンを見ます。

• Examples of Event Orchestration

優先して見ておくと役に立つのは次の3つです。

自分の環境に近いものを1つ選び、ステップ3（第2回のハンズオン）で作ったテスト環境で再現してみるのがおすすめです。
読むだけでは条件式の細かい書き方が身に付きません。

3つ目は、次章の留意点1への備えとしても役に立ちます。

実例集には、インシデントに対して復旧処理を自動で走らせる「Automated Remediation for Specific Incidents」もあります。
ただし Automation Actions のアドオン（Runbook Automation の契約）が別に必要です。

インシデントのタイトルやフィールドを整形したい場合は、弊社の記事「PagerDuty の Event Orchestration でインシデントのタイトルとフィールドを編集する」が具体的です。

本記事は学ぶ順番に絞っているので、整形の手順はそちらを参照してください。

ステップ5: 自分の環境に設計を落とす

最後に実運用へ組み込みます。
ここで明確にするのは2点です。

1. どの監視項目の、どのアラートを、どう処理するか

手動でトリアージしているイベントと、対応不要なノイズを洗い出して表にします。
列はこの5つで足ります。

※ 抑止と時間帯の条件は PagerDuty AIOps アドオンが必要です。

「Orchestration での処理」は、ルーティング・抑止・優先度付けのどれかに分けて書きます。
「そう決めた根拠」の列を空けないことが大事です。
後でルールを見直すとき、なぜ抑止したのかを説明できなくなるからです。

この表が、そのまま「ルーティング条件」と「ノイズ削減条件」の設計書の元になります。

2. 運用がどう変わるかを二次対応チームと合意しておく

ここを飛ばすと、作ったルールが使われません。
「これまで来ていたアラートが来なくなる」のは、受け手にとっては仕様変更です。
合意しておくのは次の3つです。

• 来なくなるアラートの一覧: 上の表のうち「抑止」にしたもの
• 困ったときの問い合わせ先: 「来るはずのアラートが来ない」と感じたときに誰に聞くか
• 元に戻す方法: ルールを止めて元の流れに戻す手順と、その判断をする人

事前の周知とマニュアル化まで含めて、設計の一部として扱っておきます。

設計を進めるときに役立つ話は、シリーズの後半で扱います。

• 抑止ルールの設計で踏みやすい点: 第6回
• 条件式が送信元のペイロードに左右される話: 第7回
• 作ったルールをどう検証するか: 第8回

触る前に知っておきたい3つの留意点

ここからは、私が実際につまずいた点と、つまずきかけた点を挙げます。

1. ルーティングの catch-all rule は、既定でインシデントを作らない

Service Routes（ルーティング）で、どのルールにもマッチしなかったイベントの扱いは catch-all rule で決まります。
公式ドキュメントでは、既定の選択肢がこう書かれています（出典: Event Orchestration）。

Events not matching a previous rule should not be sent to a specific service & should never create an incident (Default)

つまり既定のままでは、どのルーティングルールにもマッチしなかったイベントはサービスに送られず、インシデントにもなりません。
trigger イベントは suppressed alert として残りますが、インシデントにならないので通知は飛びません。

抑止のルールを1本も書いていなくても、通知が1件も飛ばない状態になり得ます。
条件の書き方を誤って、すべてのイベントが未マッチになった場合です。

最初に確認すべきは自分が書いたルールではなく、この catch-all rule がどちらに設定されているかです。
未マッチのイベントも見落としたくない場合の方法は2つあります。
catch-all rule の送り先にサービスを指定する方法と、trigger イベントだけを拾うルーティングルールを catch-all rule のすぐ上に置く方法です。
ステップ4で紹介した公式の実例「Capture Unrouted Trigger Events」は後者で、resolve イベントの既定の扱いを保てます。

2. Integration Key ごとに 120 events/min の上限がある

Events API v2 のレート制限は、標準では Integration Key ごとに 120 events/min です。

PagerDuty AIOps を利用している場合は、キーあたり最大 10,000 events/min まで引き上げられます。
引き上げはアカウントチームかサポートに依頼します（出典: PagerDuty AIOps / Signal Intelligence）。
上限を超えたイベントは 429 で返されるので、送信側で再送する前提にしておきます。

ここが効いてくるのは、既存の監視を1つの Integration Key に集約する構成にしたときです。
それまで複数の入口に分散していた流量が1点に集まります。

集約する前に、ピーク時の流量を見積もっておく必要があります。

3. 検証環境では Global Orchestration が選べないことがある

Global Orchestration は PagerDuty AIOps アドオンが必要な機能です。
そのため AIOps が有効になっていない検証用のアカウントでは、Global Orchestration のオプションが出てきません。
このとき、AIOps が有効な本番アカウントで作ることになります。

ただし Global Orchestration は、自分のインテグレーション（Integration Key・メールアドレス・HTTP エンドポイント）に送られたイベントだけを評価します。
誰もそこに送信しない限り、作っただけでは既存のサービスに届いているイベントの流れは変わりません。
私の環境でも、本番アカウントで Global Orchestration を作った時点では、既存のアラートの流れに変化はありませんでした。
このため、既存の運用に影響しない状態のまま検証を進められます。

このあたりの安全な確認手順は、次回以降で扱います。

おわりに

Event Orchestration の学び方を5段階に分けて整理しました。

• ステップ1〜2で概念と画面を掴み、ステップ3で最小構成を1本動かす
• ステップ4で実践パターンを見て、ステップ5で自分の環境に落とす
• 触る前に catch-all rule の既定・流量の上限・検証環境の制約を押さえておく

一番お伝えしたいのは、ステップ3を飛ばさないことです。
ここを踏んでおくと、後で条件式に詰まったときの切り分けが楽になります。

次回（第2回）はハンズオンです。
通知が飛ばないテスト環境を作り、ステップ3のルールを画面付きで1本動かします。
第3回では、Global Orchestration・Service Routes・Service Orchestration の使い分けを扱います。
メール経由のイベントだけ挙動が違うという、実務上の落とし穴も一緒に紹介します。

参考リンク

• Event Orchestration
• Event Management
• PagerDuty AIOps Quickstart Guide
• PagerDuty AIOps / Signal Intelligence（レート制限の記載あり）
• Events API v2 Overview
• PagerDuty University: Event Orchestration
• Examples of Event Orchestration
• Event Orchestration Pricing Tiers