Datadog 公式 MCP サーバーで APM 調査と CloudFormation からの推奨モニター作成を試してみた

こんにちは。オペレーション部のしいなです。

はじめに

待望の Datadog 公式 MCP サーバーの Preview リクエストがようやく承認されました。
MCP サーバーを使うと、Claude Code などの AI エージェントから Datadog のオブザーバビリティデータへ直接アクセスできます。
「直近のエラートレースを調べて」「この構成に合うモニターを作って」といった自然言語の指示だけで、APM トレースの分析やログ調査、モニター作成をこなしてくれます。
セットアップ手順に加え、APM トレース分析・エラー調査と CloudFormation テンプレートをもとにした推奨モニター作成のユースケースを試してみました。

Datadog MCP サーバーとは

Datadog MCP サーバーは、Datadog のオブザーバビリティデータと AI エージェントをつなぐ橋渡し役です。
Claude Code や Cursor などの MCP 対応クライアントから、Datadog のログ・トレース・モニターといったデータやツールに直接アクセスできるようになります。

主な免責事項

Preview 利用にあたり、以下の点に注意が必要です。

• 本番環境での使用はサポートされません
• 許可リストに登録された Datadog 組織のみ利用可能です
• AI ツールのコンプライアンス要件の確認はユーザー自身の責任となります
• Datadog が MCP サーバーの使用状況に関する情報を収集する場合があります

ツールセット

Datadog MCP サーバーはツールセットという仕組みをサポートしています。
必要なツールセットだけを有効にすることで、コンテキストウィンドウの消費を抑えられます。

利用可能なツールセットは以下のとおりです。

利用方法

Claude Code で利用する場合は~/.claude.jsonに MCP サーバの設定を行います。
ツールセットはエンドポイント URL に対して、クエリパラメータで指定します。

• core ツールを利用する場合（デフォルト）

{
  "mcpServers": {
    "datadog": {
      "type": "http",
      "url": "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp"
    }
  }
}

• core、apm、alerting ツールを利用する場合

{
  "mcpServers": {
    "datadog": {
      "type": "http",
      "url": "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp?toolsets=core,apm,alerting"
    }
  }
}

認証設定

MCP サーバの認証に OAuth 2.0 を利用できます。
ブラウザ認証が可能なため、API キーと APP キーを定義する必要はありません。
ローカル環境に認証情報を保存せず利用できるため、安心です。

権限スコープ

OAuth 2.0 認証で付与されるスコープは参照系がメインです。
APM、ログ、メトリクス、ダッシュボード、モニターなど幅広いデータを読み取れます。
一方、モニターの作成やダッシュボードの編集といった更新操作を行う場合は、API キーと APP キーを使用した Datadog API を利用する必要があります。

セットアップ

US1 サイトのエンドポイントを利用し、ツールセット（core、apm、alerting）を有効化してみます。

1. MCP サーバーの設定

1. mcp addコマンドで設定を追加します。

claude mcp add -s user --transport http datadog "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp?toolsets=core,apm,alerting"

ファイルが修正されました。

Added HTTP MCP server datadog with URL: https://mcp.datadoghq.com/api/unstable/mcp-server/mcp?toolsets=core,apm,alerting to user config
File modified: /Users/shiina.yuichi/.claude.json

~/.claude.json を確認してみると、設定が追加されています。

  "mcpServers": {
    "datadog": {
      "type": "http",
      "url": "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp?toolsets=core,apm,alerting"
    },

2. MCP リストを確認します。

claude mcp list

リストに datadog の設定が追加されていれば完了です。

Checking MCP server health...

claude.ai Slack: https://mcp.slack.com/mcp - ✓ Connected
claude.ai Gmail: https://gmail.mcp.claude.com/mcp - ! Needs authentication
claude.ai Google Calendar: https://gcal.mcp.claude.com/mcp - ✓ Connected
awslabs.aws-documentation-mcp-server: uvx awslabs.aws-documentation-mcp-server@latest - ✓ Connected
awslabs.aws-iac-mcp-server: uvx awslabs.aws-iac-mcp-server@latest - ✓ Connected
datadog: https://mcp.datadoghq.com/api/unstable/mcp-server/mcp?toolsets=core,apm,alerting (HTTP) - ! Needs authentication

2. MCP サーバーの認証

1. Claude Code を起動します。

claude

2. /mcpコマンドで確認します。
   認証前のため、 "needs authentication" と表示されます。

    User MCPs (/Users/shiina.yuichi/.claude.json)
  ❯ awslabs.aws-documentation-mcp-server · ✔ connected
    awslabs.aws-iac-mcp-server · ✔ connected
    datadog · △ needs authentication
    pencil · ✔ connected

    claude.ai
    claude.ai Gmail · △ needs authentication
    claude.ai Google Calendar · ✔ connected
    claude.ai Slack · ✔ connected

3. カーソルを datadog に移動し、Enter キーを押します。

4. 詳細情報より「1. Authenticate」を選択します。
   

5. ブラウザ画面の Authorize access にて「Allow」を選択します。
   

6. Datadog の organization を選択します。
   

7. アクセス権限を確認のうえ、認可を行います。
   

8. 成功すると "Authentication Sucessful!" と表示されます。
   

9. Claude 側には "Authentication successful. Connected to datadog." と表示されます。

10. 再度/mcpコマンドでステータスを確認してみます。
    datadog のステータスが "connected" となれば認証完了です。

   User MCPs (/Users/shiina.yuichi/.claude.json)
  ❯ awslabs.aws-documentation-mcp-server · ✔ connected
    awslabs.aws-iac-mcp-server · ✔ connected
    datadog · ✔ connected
    pencil · ✔ connected

    claude.ai
    claude.ai Gmail · △ needs authentication
    claude.ai Google Calendar · ✔ connected
    claude.ai Slack · ✔ connected

3. 利用可能ツールの確認

Datadog MCP サーバーで使用できるツールを確認してみます。

 Datadog MCPでどんなツールを利用できますか

確認したところ、24 のツールが利用可能でした。
ログ検索やトレース分析、モニター操作など、日常的な運用タスクを幅広くカバーしています。

検証シナリオ

Claude Code（Opus 4.6 モデル）を利用し、次の 2 つのシナリオで検証しました。

1. ショッピング Web アプリケーションの APM 調査

   • トレース分析、エラースパン・遅延スパンの特定、推奨対応事項の提案

2. サーバーレスアプリケーションの監視モニター作成

   • DynamoDB・API Gateway・Lambda が定義された IaC テンプレートをもとに、推奨モニターを自動作成

ショッピング Web アプリケーションの APM 調査

意図的に遅延ロジックやランダムエラーを仕込んだショッピングサイトを対象に、MCP サーバー経由で APM トレースの分析・エラー調査・遅延原因の特定を行ってみます。

トレースの分析

Webサイト「shopping-site」のレスポンス遅延の報告が上がりました。
直近のAPMトレースを分析してください。

自然言語で指示するだけで、サービス構成の把握からスパンの検索・分析まで自動で実行してくれました。
エラースパン8件の検出と遅延スパンの上位ボトルネックを特定できました。

エラースパンの調査

在庫があるにもかかわらず、カート追加時にエラーが発生する場合があるようです。
スパンとログから原因を特定して

調査を進め、2つの根本原因を特定してくれました。

• ランダムエラー生成ロジックにより、DB 到達前に商品取得が失敗しカート追加がエラーになるケース
• POST /api/cart/add で DB 操作は合計約 19ms なのに、未計装の処理で約 5.3 秒の空白が発生している遅延

いずれもアプリに意図的に仕込んだ不具合ですが、スパン属性やトレースの時系列から根本原因を特定しています。

遅延スパンの調査

GET /api/products で1秒以上かかっているものがある。
根本原因を特定して

DB クエリ処理時間の事実を突き合わせ、遅延がアプリケーション層で意図的に追加されていることを見抜きました。
さらに、ログの delay_ms と search_length の相関から「検索文字列の長さ × 200ms」という遅延ロジックまで推定しています。

推奨事項の提案

このアプリケーションを最適化するための提案はありますか?

これまでの分析結果を踏まえ、緊急度別に整理された最適化提案が出力されました。
アプリケーションコードの問題（遅延ロジック・ランダムエラーの削除）、アーキテクチャの改善（ログ送信の非同期化・コネクションプーリング最適化）の対応が網羅されています。
改善後の期待効果として各エンドポイントのレイテンシ比較も提示されており、対応の優先順位を判断しやすい内容です。

サーバーレスアプリケーションの監視モニター作成

CloudFormation テンプレートで定義したインフラリソースに対する推奨モニターの設計から作成、ステータス確認を実施します。
Datadog のクエリ構文やメトリクス名は独自仕様のため、AI が生成した定義にハルシネーションが含まれるリスクがあります。
バリデーション用のツール validate_monitor_definition が用意されているため、こちらを活用して作成してみます。

モニターの設計

ディレクトリ内の template.yaml に定義されたインフラリソースに対して、Datadogによる監視モニターを作成してください。

- template.yaml の解析：ファイルを読み込み、定義されているインフラリソース（AWS Lambda、DynamoDB、API Gateway、SQS、SNS など）を特定する。
- リソースごとの推奨監視項目の洗い出し：Datadogのベストプラクティスに基づき、各リソースタイプに適した監視モニター（エラー率、レイテンシ、スロットリング、キュー深度など）を選定する。
- クエリ構文・メトリクス名の検証：モニター定義を作成する前に、Datadogで使用するクエリ構文やメトリクス名が正しいことを確認・検証する。
- モニター定義の作成：検証済みのクエリを使い、Datadogモニターを作成する。
- アラート通知先：example@example.com
- 通知テンプレート：ベストプラクティスに従ってください。

template.yaml から Lambda 8関数・DynamoDB 3テーブル・API Gateway を特定し、全7件のモニター定義が生成されました。
処理の流れとしては、まず List Metrics ツールで環境内に実在するメトリクス名を確認し、次に各モニター定義を validate_monitor_definitionでバリデーションしています。

実際に API Gateway の2件で new_group_delay のバリデーションエラーが発生しましたが、自動でオプションを修正し再検証を通過させていました。

Lambda の Duration モニターでは、template.yaml に定義されたタイムアウト値（scan/ai-analysis は900秒、API 系は30秒）を読み取り、その80〜83%をしきい値として設定しています。
通知テンプレートには Alert / Warning / Recovery 各状態の対応手順が含まれており、実運用にそのまま使える品質です。

モニターの作成

MCP サーバー経由ではモニターの作成は行えないため、Datadog API を利用します。
API キーと APP キーを環境変数に設定する必要があるので、一度 Claude Code を終了しシェルからセットします。

export DD_API_KEY=""
export DD_APP_KEY=""
export DD_SITE=datadoghq.com

claude --resume コマンドを使って再開します。

最初の curl 実行時に JSON パースエラーが発生したのの、レスポンス確認からテストモニター作成・削除を実行しています。
Python スクリプトでの一括作成に切り替えながら、全7件のモニターを作成してくれました。

モニターの確認

作成したモニターの現在の状態を詳細に教えて

service:key-inventory タグで作成済みモニターを検索し、全7モニター・11グループの状態を取得してくれました。
10グループが OK、1グループが No Data という結果です。

モニター作成直後は No Data が表示されると「ちゃんと監視できているのか？」と不安になりがちです。
各モニターの No Data の理由まで解説してくれるのは助かります。
モニターが意図どおりに機能していることがわかりました。

まとめ

Datadog 公式 MCP サーバーを Claude Code と組み合わせて、APM 調査と監視モニター作成のシナリオを試してみました。
APM 調査では、自然言語の指示だけでスパン分析からボトルネック特定、根本原因の推定まで一気通貫で完結しました。
コンソールで複数画面を行き来する従来の調査と比べ、効率の向上を実感できます。
監視モニター作成では、CloudFormation テンプレートからリソースを読み取り、ベストプラクティスに沿ったモニター定義を生成してくれました。
Datadog のクエリ構文は独自仕様のため、validate_monitor_definitionツールでバリデーションを挟み、ハルシネーションによる誤設定を防ぐことが重要です。
Preview 段階ではありますが、オブザーバビリティ運用を AI エージェントで効率化できる手応えを十分に感じられました。
今後の GA が楽しみですね。

本記事が参考になれば幸いです。

参考

https://docs.datadoghq.com/bits_ai/mcp_server/
https://docs.datadoghq.com/bits_ai/mcp_server/setup?tab=cursor
https://github.com/datadog-labs/mcp-server