Datadog On-Callのスケジュールとエスカレーション設計：少人数運用の実装手順

Datadog On-Callを有効にする作業そのものは半日で終わります。詰まるのはその後です。誰がいつ当番なのかをレイヤーでどう表すか、応答が無かったときに何分で次へ回すか、深夜のマナーモードをどう越えて着信させるか。この3点を決めないまま既定のポリシーで走らせると、届いてほしい相手には届かず、起きなくていい人が全員起きます。この記事では、Team・Schedule・Escalation Policy・Pageの関係から、交代時刻と時間帯制限の置き方、モニターからの呼び出し連携、通知チャネルの優先順位、3〜5人体制の現実解までを、2026年8月時点の公式ドキュメントの設定名と制約値に沿って整理します。

まとめ：Datadog On-Call導入で先に決める3つの設計判断

第一に、当番表は人の一覧ではなくレイヤーで組みます。公式ドキュメントのスケジュールはレイヤー構造で、下位のレイヤーが上位に優先される仕様。平日日中の一次受けを上に置き、夜間休日の輪番を下に重ねると、1つのスケジュールで両方を表現できます。人を並べ替えるのではなく、時間帯の条件を重ねる。ここを取り違えると、祝日のたびに手作業でシフトを書き換える運用になります。

第二に、エスカレーションポリシーは段数ではなく待ち時間で効きます。設定できる段数は最大10、1段あたりの宛先も最大10まで用意されていますが、実務で機能するのは2段か3段。応答待ちの下限は1分で、ここを短くしすぎると起きた本人が端末を触る前に次の人が叩き起こされます。5分前後を起点に実際の一次応答時間を見て動かす設計が扱いやすい。

第三に、通知チャネルを緊急度で分けます。高緊急度の設定が空のままだとメール通知へフォールバックする仕様のため、導入直後に「電話が鳴らない」と感じる原因の多くはここにある。設定は利用者本人のプロフィールに紐づくので、当番に入る全員が個別に済ませたかを開始前に確認してください。

Datadog On-Callの構成要素とPageが担当者に届くまでの経路

設定画面はメニューが分かれているため、どこから触るか迷います。実際の依存関係は一方向で、Teamを作り、Scheduleを作り、それをEscalation Policyから参照し、最後にPageがそのポリシーを辿る。この順で作れば手戻りは出ません。製品全体のなかでのOn-Callの位置はDatadogとは何か？機能やメリット、導入の背景で整理しています。

Team・Schedule・Escalation Policyの3層とPageの流れ

公式ドキュメントが挙げる構成要素は、Pages・Teams・Escalation Policies・Schedules・Routing Rulesの5つです。Teamは「専門性と運用上の役割に基づいて特定種別のPageを処理するためにDatadog内に構成されたグループ」と定義され、当番設計の単位になります。ScheduleはTeamのメンバーがいつ対応するかの時間割、Escalation Policyはそれらをどの順で呼び出すかの経路。

権限は3段階です。Viewerは閲覧のみ、Overriderはスケジュールにのみ付与でき当番の入れ替えを作成できる権限、Editorは変更全般。当番交代の申請だけを現場に開放したいなら、Editorを配らずOverriderで足ります。オンボーディング時には既定のエスカレーションポリシーが自動生成されます。

Triggered・Acknowledged・Resolvedの遷移と停止条件

Pageのステータスは3つです。Triggeredは「Pageは送信されたが誰も対応を引き受けていない」状態で、この間はエスカレーションポリシーが設定どおりに進行します。Acknowledgedへ移った時点でエスカレーションの追撃は止まり、Resolvedで完了。誰かが受領ボタンを押すまで次の段へ進み続ける、という一点さえ押さえれば挙動は読めます。

担当の付け替えはTriggeredとAcknowledgedの2状態でのみ可能です。もう一点、Pages・エスカレーションポリシー・スケジュールはいずれも削除に対応していない仕様。対応履歴を残す設計思想によるもので、試験運用で作った当番表もそのまま残ります。検証用のTeamは本番と判別できる接頭辞を決めてから作ってください。

Routing Rulesで緊急度と対応時間帯を条件分岐させる設定

Routing RulesはTeamが受け取るイベントの種類ごとに反応を調整する仕組みで、緊急度の上書きや対応時間帯の指定ができます。全てのPageを同じ経路に流すと、日中なら業務時間内に片付く事象で夜間の電話が鳴る。「特定のタグを持つPageは低緊急度に落とす」分岐をここに入れると、ポリシー側を複雑にせずに済みます。なお、この製品はapp.ddog-gov.comとus2.ddog-gov.comでは非対応と明記されている点も、導入検討の前段で確認してください。

オンコールスケジュールのレイヤー構成と交代時刻・時間帯制限の設定

当番表を作る作業は、Datadogでは「レイヤーを何枚重ねるか」を決める作業に置き換わります。1枚では足りず、5枚も重ねると誰が当番か画面を見ないと分からなくなる。実務では2枚から3枚に収まります。

レイヤーの重ね方と平日日中・夜間休日を分ける時間帯制限の設定

公式ドキュメントはスケジュールを「それぞれのレイヤーが週の異なる部分や特定の責務をカバーする」層構造と説明し、下位レイヤーが上位に優先されると記載しています。この優先関係を使えば、ベースとなる24時間365日の輪番を上のレイヤーに置き、その上から平日9時から17時だけ有効な日中担当のレイヤーを下に重ねる組み方が取れる。時間帯の条件は「月曜から金曜の9:00から17:00」のような形で指定します。

タイムゾーンはスケジュールごとに選択する設定項目です。国内単一拠点なら迷いませんが、オフショア拠点や海外子会社を輪番に含めるとスケジュールのタイムゾーンと各メンバーの生活時間がずれ、夏時間の切り替わり週に当番が1時間分空きます。拠点をまたぐ場合はレイヤーを拠点ごとに分け、それぞれのタイムゾーンで組むほうが破綻しません。

交代時刻をどこに置くかと1日交代・1週間交代・カスタム期間の選び方

シフト長として用意されているのはOne Day（24時間）、One Week（168時間）、カスタム期間の3種類です。交代日時は「シフトが次の人へ引き渡される日時」として明示的に設定します。ここを0時に置く設計をよく見かけますが、引き継ぎが必要な事象を抱えたまま深夜に担当が変わることになる。朝10時など、両者が起きている時刻に置くほうが引き継ぎは成立します。

オーバーライドとwebcal書き出しで当番の入れ替えを回す運用

オーバーライドは一時的なシフト調整と休暇に対応するための機能で、スケジュール本体を書き換えずに特定期間だけ担当を差し替えられます。SlackやMicrosoft Teamsからoverrideの申請コマンドを打てるため、体調不良の当日交代も画面を開かずに回せる。Overrider権限だけを配れば、当番表の構造を触らせずに交代だけを現場へ委譲できます。

スケジュールはwebcal形式のリンクとして書き出せます。書き出しは2種類あり、自分のシフトだけのものと、参加者全員を含むスケジュール全体のもの。前者を個人のカレンダーアプリへ登録すれば、当番週が予定表の上に見えます。リンクは再生成でき、生成し直すと以前のリンクは無効になるため、退職者が持ち出した購読リンクはこの操作で切れます。

エスカレーションポリシーの多段構成と応答待ち時間・繰り返し回数の設定

ポリシーの設定項目は名前とオーナーTeam、そして段（ステップ）の並びです。各段で「誰に」「どう」「何分待って次へ」を決めます。ここが当番運用の心臓部で、ここだけは既定のまま本番に入れないでください。

エスカレーション1段目から3段目までの通知先の並べ方と待ち時間

各段の通知先には、個々のユーザー、Team全体、スケジュールの当番者の3種類を単独または組み合わせで指定できます。1段目に当番者、2段目に副当番か別スケジュール、3段目にTeam全体という並びが最も破綻しにくい。1段目からTeam全体を指定すると、初回から全員の電話が鳴り、数回で誰も出なくなります。

応答待ち時間は「受領して次の段へ上がるのを止めるまでに与える分数」として設定します。1分では、着信に気づいて端末のロックを解除しアプリを開くだけで超える。運用が回り始めてから実測値で詰めてください。

Notify AllとRound Robinの使い分けと繰り返し回数の上限

各段の通知方法は2つから選びます。既定のNotify Allは対象すべてへ同時に通知し、Round Robinは対象を順に回して1人ずつ呼び出す方式。夜間の一次受けはNotify Allで確実に届け、日中の低緊急度の受け口はRound Robinで負荷を分散する、という使い分けが噛み合います。Round Robinを夜間に使うと、順番待ちのぶん一次応答が遅れます。

繰り返し回数は「誰も受領しなかった場合に段の並びを何周するか」の設定です。加えて、全ての段と繰り返しを実行し終えた時点でPageを自動的にResolvedへ落とすオプションがある。これを有効にすると未対応のまま静かに閉じるため、夜間の呼び出し経路では有効化しないでください。

役員や管理職を最終段に入れるかは判断が分かれます。入れる場合は「3段目まで到達した事実そのものが異常」という合意を先に取ってください。合意が無いまま入れると、鳴った側は状況が分からず、当番へ電話を折り返すだけの中継役になる。呼び出しの前段にあたる閾値そのものの決め方はDatadogモニターのタイプ選定と閾値設計で扱っています。

モニターからPageを起こす通知ハンドルの書き方と緊急度の切り分け

当番表とポリシーが組めたら、次は呼び出し元との接続です。専用の連携設定を作るのではなく、モニターの通知先にチームのハンドルを書くだけでPageが立ちます。

モニターのメッセージ欄に書くoncall-のハンドルと復旧文の扱い

チームハンドルはoncall-の接頭辞を付けた形式です。公式ドキュメントの例では、Checkout Operations Teamを呼び出す場合に @oncall-checkout-operations と記述します。この記法はモニターだけでなく、Incident Management、セキュリティの検出ルール、Event Managementでも同じように使えます。

復旧時の挙動には条件があります。モニターが復旧するとPageは自動的に解決されますが、これは復旧メッセージにチームのメンションが含まれている場合に限られる仕様。条件変数で通知文を出し分けているモニターでは、復旧側の分岐からハンドルが抜け落ちていることがあり、「障害は直ったのに電話が鳴り続ける」という現象の大半はこれです。導入時に復旧側の分岐を一度は目視してください。

ALERTとWARNで緊急度が変わる仕様を踏まえた閾値の置き方

Pageの緊急度は2種類で、判定は呼び出し元の状態に紐づきます。Datadog上での手動発報、およびモニターのALERT閾値の超過は高緊急度。WARN閾値の超過は低緊急度として扱われます。つまり、緊急度の切り分けは通知設定側ではなく、モニターの閾値設計の段階で半分決まっているということです。

この仕様を踏まえると、夜間に起こしてよい事象だけをALERT閾値に載せ、翌朝の確認で足りる劣化はWARN閾値へ置く整理ができます。すべてをALERTに寄せてOn-Callを繋ぐと、当番の電話が実質的に全アラートの受け口になる。通知が増え続ける構造そのものはアラート疲れの原因と対策で整理しています。

通知チャネルの優先順位とDo Not Disturb下での着信設計

ここまでの設定が正しくても、最後の数十メートルで届かなければ意味がありません。通知設定は利用者本人のプロフィール配下にあり、管理者がまとめて設定するものではない、という前提から始まります。

プッシュ・電話・SMS・メールを高緊急度と低緊急度で分ける設定

用意されている連絡手段は4つです。Datadogモバイルアプリのプッシュ通知、メール（HTML形式またはテキスト形式）、SMS、電話。SMSと電話には対象外の番号や国があるため、登録した番号で実際に着信するかを先に確かめてください。

公式ドキュメントは高緊急度のPageに対してプッシュ通知と電話を主たる手段とし、追撃の間隔を短く置くことを推奨しています。設定した連絡手段は、受領するか次の段へ上がるまで循環し続ける仕組み。低緊急度はメールのみに絞ります。

未設定時にメールへ落ちる挙動とDo Not Disturbの回避設定

高緊急度の通知設定が空の場合、Datadogは自動的にメール通知へフォールバックします。届きはするので障害としては表面化しませんが、当番はメールに気づかない。導入直後に3段目まで上がる事象が続くなら、ここを疑ってください。

もう一段の落とし穴がスマートフォン側の設定です。プッシュ通知はDo Not Disturbモードを迂回させる設定が可能で、公式のモバイル設定手順にその方法が示されています。この設定を入れないまま夜間当番に入れば、端末は静かなまま朝を迎える。当番に入る前の確認項目として、通知設定・電話番号の登録・Do Not Disturbの迂回・テスト発報の4点を手順書に固定しておくと事故が減ります。

3〜5人のチームでOn-Callを回すときの当番設計と見送る条件

ここからは判断を書きます。On-Callは大規模なSREチームを前提に説明されがちですが、国内の受託開発や情シスの現場は3人から5人で回している。その規模で何を削るかが勝負どころです。

3人で24時間365日を回すときの現実的なレイヤーと交代周期

3人体制なら、レイヤーは2枚、交代は1週間、エスカレーションは2段に固定してください。1枚目に平日9時から18時の日中担当を時間帯制限つきで置き、2枚目に24時間の輪番を置く。1段目は当番、2段目は残り2人へのNotify Allにして、3段目は作らない。3人しかいない組織で3段を作っても、実態は同じ2人が2回鳴らされるだけです。

この構成なら1人あたりの当番は3週に1週で、当たり週は他の予定を入れない前提が作れます。そのうえで祝日と長期休暇はオーバーライドで先に埋める。直前の調整手段としてではなく四半期の頭にまとめて入れる運用にすると、当番表の見た目と実態がずれません。人員が5人へ増えたら、レイヤーを増やすより交代周期を保ったまま輪番の人数だけ増やすほうが安定します。

On-Callを導入しない方がよい体制と先にモニターを削る判断

導入を見送るべき体制は明確に2つあります。1つ目は、夜間に手を動かせる人が実質1人しかいない場合。エスカレーションの行き先が無く、通知の宛先が増えるだけになる。まず夜間に鳴らす対象を「サービス全断」相当の1本か2本まで削り、それ以外は翌営業日の確認へ回す設計に変えるのが先です。

2つ目は、現状のアラートが1日20件を超え、その大半が対応不要な状態。ここにOn-Callを繋ぐと電話が鳴る回数だけが増え、1か月で当番は受領ボタンを押さなくなります。モニターの整理が先、当番設計が後。対応プロセス全体の型はインシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装で扱っています。監視の整理から当番体制の設計までを外部の手を借りて進める場合は、保守運用・内製化支援で運用設計と内製化の伴走まで対応しています。

シート課金が発生する条件と当番外メンバー・専用ツールの線引き

費用の見積もりでずれるのは単価ではなく人数です。シートが発生する条件は「Datadogにログインする人数」ではありません。

シートが発生する3つの条件と当番外メンバーを課金から外す設計

公式の課金ドキュメントによれば、On-Callのシートが必要になるのは次の3条件のいずれかに当てはまる利用者です。

• 当番スケジュールに参加している
• エスカレーションポリシーに含まれている
• ページを受け取るための通知設定を済ませている

裏を返せば、当番表にも経路にも入らず通知設定もしていない人はシートを消費しません。Pageを画面で見るだけのメンバーは対象外です。最終段に「念のため」で管理職を並べる設計は、そのまま費用に跳ねます。請求はその期間中の同時利用シートの最大値で計算され、契約したシート数を超えた分はオンデマンド扱い。四半期に一度ポリシーの宛先を棚卸しすると差が出ます。課金単位の全体像はDatadogの料金体系と費用が膨らむ課金単位で整理しています。

Datadogに監視を寄せている場合と専用ツールを残す場合の線引き

結論から書くと、監視の主軸がすでにDatadogにあるならOn-Callへ寄せる判断が合理的です。理由は費用より導線で、モニターの通知先にハンドルを1行書くだけで当番へ繋がり、Pageから元のモニターやダッシュボードへそのまま辿れる。別製品を挟むと、状況把握のために画面を移動する手数が残ります。

逆に、専用ツールを残すべき場面もあります。Datadog以外の監視基盤が併存していて当面の統合予定が無い場合、呼び出しの受け口を2つ持つことになり、当番が「どちらの通知に出るか」を判断する状態になる。この場合は、どちらか一方に呼び出しを集約できるまで移行しないほうが安全です。判断の材料としては、夜間に鳴る事象の何割がDatadogのモニター由来かを1か月分数えるのが早い。7割を超えていれば寄せる価値があります。

よくある質問

導入検討と初期設定で問い合わせが多い点を、公式ドキュメントの記載に沿って整理します。

Datadog On-Callだけを単体で契約できますか？

On-Callはシート単位のSKUとして提供され、当番に入る人数分のシートで課金されます。ホスト単位で課金されるInfrastructure Monitoringとは課金軸が別のため、監視対象の台数が増えてもOn-Call側の費用は動きません。ただし呼び出し元としてモニターを使う以上、実務上はモニターを作れる製品との組み合わせが前提になる。見積もりでは当番に入る人数を先に確定させてください。

作成したスケジュールやエスカレーションポリシーは削除できますか？

削除には対応していません。公式ドキュメントは、Pages・エスカレーションポリシー・スケジュールといったリソースの削除を対応外とし、その理由をインシデント履歴の保全と説明しています。検証で作ったものも残るため、本番と区別できる命名規約を決める前に量産しないでください。運用から外すときは、参照しているポリシーから外して退役扱いとします。

当番の担当者が電話に出られないときはどうなりますか？

設定した応答待ち時間を過ぎると、エスカレーションポリシーの次の段へ自動的に進みます。1段目が当番スケジュール、2段目が副当番という並びなら、当番が反応しない場合に副当番の端末が鳴る流れ。受領された時点で追撃は止まります。全ての段と繰り返しを消化しても誰も受領しなかった場合の挙動は自動解決オプションの有無で変わるため、夜間の経路では無効にしておいてください。

サードパーティの監視ツールからもPageを起こせますか？

可能です。Teamごとに発行される専用のメールアドレス宛に通知を送ると、そのTeamのエスカレーションポリシーを通って当番へ届きます。Datadog以外の監視製品を併用している環境では、その製品の通知先設定にこのアドレスを追加するだけで接続できる。ほかにEvent Management経由の取り込みや、Live Call Routingの専用電話番号を使う方法もあります。

電話やSMSの通知はどの国の番号でも受け取れますか？

すべての国で同じように使えるわけではありません。電話通知の対応可否は国ごとに異なり、対応状況は国番号の一覧から確認する必要があります。SMSについては、固定電話・VoIP・仮想番号が対象外と明記されている。転送用の050番号やクラウドPBXの番号を登録しても届かない場合があるため、本番の当番へ組み込む前にテスト発報で着信を確認してください。

関連記事

• Datadogモニターのタイプ選定と閾値設計：Pageを起こす側の閾値と評価ウィンドウの決め方を扱っています。
• インシデント管理とは｜ITIL準拠のプロセスと監視・オンコールの実装：当番設計の前提となる対応プロセス全体を整理しています。
• アラート疲れとは｜原因と対策を監視の実装視点で解説：呼び出しを減らすためのモニター整理の順序をまとめています。
• Datadog運用のベストプラクティス｜タグ設計とコスト抑制：通知先の型とタグ命名規約を解説しています。
• Datadogの使い方｜アカウント作成から最初の監視までの手順：On-Callを繋ぐ前段の初期導入を扱っています。