Datadog × ServiceNow で作る「プロアクティブ運用」入門
この記事は ServiceNow アドベントカレンダー 2025 の参加記事 第13日目です
はじめに：なぜ今「プロアクティブ運用」なのか
アラートは大量に飛んでくるのに本当に対応すべきインシデントがどれなのか分かりにくい💦💦
結局、いつもあの人に頼るしかない💦💦💦
このようなシステム運用を行っているチームによく遭遇します。
ServiceNowではYokohama以降Now Assist for ITSM や AI Agentsといった生成AI機能が本格的に提供され、インシデントの要約・解決メモ作成・チャットサマリーといった機能が使えるようになってきました。
またDatadog側でもITインフラ・アプリを統合的に監視し、チームがインシデントを効果的に識別して解決できる機能や簡易にServiceNowと連携できる機能等が揃っています。
そこで本記事では、
「Datadog で検知した異常」→「ServiceNow のインシデント」→「Now Assist でインテリジェントに対応を支援」
という流れを前提に“プロアクティブ運用”に近づくための設計パターンを整理してみます。
実装の細かい手順というよりは「どこまで自動化して、どこから人が考えるか？」という設計の考え方にフォーカスします。
登場人物の整理：Datadog / ServiceNow / Now Assist
Datadog（Observability）の役割
Datadogはインフラ・アプリケーション・ログ・RUMなどを横断的にモニタリングするオブザーバビリティ・プラットフォームです。
さらに、ServiceNowとのインテグレーションによりDatadogのアラートからServiceNowのインシデント/イベントチケットを自動作成することができます。
ServiceNow（ITSM）の役割
ServiceNow IT Service Management (ITSM)はインシデント・問題・変更などのITサービス運用のハブです。
「誰が・何を・どのように対応したか」の履歴を一元管理することで運用の標準化と見える化を実現します。
Now Assist / AI Agents の役割
Now Assist for ITSMはインシデントの詳細やチャットログを元にインシデント内容の要約や解決メモ作成などを自動で生成する機能を提供します。
YokohamaではさらにAI Agents for ITSMが追加され、
インシデント管理のワークフローの中でタスク実行や判断の一部をエージェントに任せることができるようになりました。
本記事ではNow Assist / AI Agentsをひとまとめに「ServiceNow側の“頭脳”」として扱い、
人に任せて運用していくとカオスになる部分（サマリ・解決メモ・初動プランの案出し）やルール化しやすいタスクの自動実行を任せていく方向性で考えます。
全体アーキテクチャ：Datadog → ServiceNow → Now Assist の流れ
これまでの「リアクティブ運用」の課題
よくある運用はこんな感じです（ここまでひどくはないかもしれませんが,,,）：
・Datadogでメトリクスやログのモニターを設定
・アラートをメール or チャットに通知
・オンコール担当者がアラートを見て手動でServiceNowにインシデントを起票
・調査や切り分けは、担当者の経験と気合いに依存
この場合、
・アラートを見てからインシデント初動対応までのタイムラグ
・インシデントに必要な情報（関連ホスト・タグ・ログなど）がバラバラ
・解決メモや事後分析が属人化（解決メモが残っていないケースもよく見受けられます）
といった問題がよく起こりがちです。
DatadogとServiceNowの連携アーキテクチャの全体像
・Datadog → ServiceNowの連携によるインシデントチケット自動起票
・ServiceNow上でNow Assist / AI Agentsがオンコール担当者を支援
・将来的にはAI AgentsがRunbook実行やエスカレーション等を自律的に判断する運用高度化へ!!
公式ドキュメント上もDatadogとServiceNowのITSM連携ではDatadogのアラートやインシデントを中間テーブル経由でServiceNowのインシデント/イベントレコードへ連携する構成が推奨されています。
ユースケース：エラーレート急増インシデントの Before / After
Before：よくある手動対応フロー
例として「特定APIのエラーレートが急増したケース」を考えます。
Before（連携・AIなし）の流れ：
- Datadogでエラーレートモニターが発火しSlack/メールに通知
- オンコール担当者がSlack/メールを見て影響範囲や担当サービスを確認
- ServiceNowを開き、手動でインシデントチケット起票
- 関連ホスト・タグ・ログをDatadogから貼り付け
- 自己解決できない場合はどのチームにエスカレーションすべきか判断
- エスカレーションまでの対応状況について手書きでまとめて担当者に引継ぎ（エスカレーション実施）
このやり方だと、
- 「アラートを見た人」のスキル依存
- インシデントチケット記載内容がバラバラ（テンプレートが守られない）
- ポストモーテムでログを追い直す手間
などが発生します。
After：Datadog × ServiceNow × Now Assist での自動化フロー
After（Datadog × ServiceNow連携＋Now Assist活用）では：
-
Datadogでエラーレートモニターが発火
アラートにはservice名, env, teamタグなどが付与されている -
アラートを受信しServiceNowの中間テーブルを経由してインシデントチケットを自動作成
-
変換マップで以下情報がインシデントチケット作成時に反映されている
・タイトル：[DD][service名] エラーレート急増
・説明：Datadog アラート本文＋リンク
・CI：Datadog情報から対応するCIに紐づける -
インシデントチケットが作成されるとNow Assist for ITSMが
インシデントの詳細や過去の類似インシデント・関連ナレッジを元に要約や解決候補をパネル上に提示する -
オンコール担当者はNow Assistの提示するサマリ・類似インシデント・Runbookを見ながら、影響範囲を確認し初動対応開始（リトライ抑制、スケールアウト etc.）
-
インシデント解決後、Now Assistによる解決メモの自動生成をベースに必要な追記・確認だけしてチケットをクローズ
このフローでは、人間がやっていた
- 「インシデント起票」
- 「対応状況等の整理」
- 「過去事例探し」
- 「解決メモ作成」
といった “書く・探す” 系の作業をNow Assistにオフロードすることで、オンコール担当者は本来価値の高い判断と実行に集中できます。
設計のポイント
ここからはこの構成を構築する際に設計で悩みそうなポイントを3つに絞って整理します。
1. どのアラートをServiceNowでインシデントチケット化するか
Datadogの全アラートを無条件にServiceNowでチケット化すると、インシデントスパムになります。
おすすめは、
- 「SLO違反」や「ユーザー影響のあるモニター」だけをインシデント化
- それ以外は Datadog Incident Management内でハンドリング
という整理で、“インシデントとは？” を最初に定義しておくことです。
2. タグとCMDB連携で「意味のある」インシデントにする
Datadog 側では、
- service, env, team, region などのタグ設計
- ホストやサービスとCMDB（CI）との対応関係
を揃えておくことで、ServiceNow側で
- どのサービス / システムの障害か
- どのチームが対応すべきか
- どのCI（サーバ・アプリ）に紐づくか
を自動判定しやすくなります。
Service Graph Connector for Observability - Datadogを使うと、Datadogの情報をServiceNow CMDBに取り込み、CIとして管理することができます。
タグ設計とCMDBクラス設計はセットで考えるのがポイントです。
3. Now Assist に任せるところ / 任せないところ
Now Assist for ITSMはインシデントサマリ・解決メモの自動生成など、テキスト生成タスクに強みがあります。
一方で、
- どのモニターをインシデント化するか
- どのチームにエスカレーションするか
- どのRunbookを「自動実行」まで許すか
といった責任分界に直結する部分は人間＋運用プロセス側でしっかり設計すべきところです。
おすすめは、
Step1：サマリ / 解決メモの「提案」だけを使う（自動保存しない）
Step2：一部の単純なRunbookだけAI Agentに自動実行を許可
Step3：重要度の高いインシデントでの自動実行範囲を予め議論
というように、徐々に任せる範囲を広げる設計です。
まとめ：プロアクティブ運用への一歩目としての設計パターン
本記事では、
- Datadogでの検知
- ServiceNowでのインシデント管理
- Now Assist / AI Agentsによる担当者支援
を組み合わせて“プロアクティブ運用” に近づくための設計パターンを整理しました。
先ずは以下のような観点でシステム運用そのもののプロセスを見直してはいかがでしょうか。
・いきなり全部を自動化しようとせず、「1サービス」「少数モニター」から始める
・Datadogのタグ設計とServiceNowのCMDB/インシデント設計をセットで考える
・Now Assistには“書く仕事”を任せ、人間は判断と改善に集中する