こんにちは。クラウド事業部の遠見です。
- 本記事は「Datadog MCP Server」と「AWS DevOps Agent」の連携を実際に検証したエンジニアが、内容をできる限り客観的に共有することを目的に作成しました。
今回は、2026年3月10日に一般提供（GA）が開始された「Datadog MCP Server」を、AWSから現在プレビュー版として提供されている「AWS DevOps Agent」を使って利用するハンズオンを行いました。
独自の検証や工夫したポイントも含めて、オリジナルな体験記として参考にしていただければ幸いです。
目次
はじめに：Datadog×APC共催ランチセミナー開催
本編に入る前に、Datadogにご興味のある方へお知らせです。
4/21(火)に、Datadog×APC共催ランチセミナーを開催いたします！
参加者を募集しておりますので、監視・運用環境の改善や効率化に関心がある方は、ぜひ以下のリンク（X、Linkedin）から詳細をチェックしてみてください。
www.linkedin.com少人数の情シスでも「攻めのIT」は実現できる？
— エーピーコミュニケーションズ公式🌈 (@apc_tweet) 2026年3月16日
4/21(火) 11:00〜
【無料セミナー ＠ Datadog Japanオフィス】豪華お弁当付き
AI×オブザーバビリティ×パートナー活用で、次世代クラウド運用の実践戦略を解説。
事例紹介やデモンストレーションも
※先着50名申込みはお早めにhttps://t.co/dDQzbeXFa8
検証の前提：AWS DevOps Agentと構成アーキテクチャ
検証に入る前に、今回利用する「AWS DevOps Agent」とは何か、どのようにDatadogと連携するのかを整理しておきます。
AWS DevOps Agent とは
...経験豊富な DevOps エンジニアと同じようにインシデントを調査し、運用上の改善点を特定します。
AWSによって作られてサービスとして提供されており、「経験豊富な DevOps エンジニアと同じように」動いてくれるAIエージェントです。
たとえば、システムで障害（インシデント）が起きた際、人間のかわりにログやメトリクスを調査し、「何が原因か」「どう直すべきか」を特定して教えてくれます。
Amazon Bedrock AgentCore との違い
Amazon Bedrock AgentCore は、効果的なエージェントを大規模かつ安全に構築、デプロイ、運用するためのエージェントプラットフォームです。
つまり、「自分たちで独自のAIエージェントを作りたい」という開発者のための実行基盤です。
両者の使い分けのイメージとしては、
- 「AWSの運用やトラブル対応をAIに助けてほしい」なら AWS DevOps Agent
- 「自社専用の特定の仕事をするAIエージェントを開発して、本番環境で動かしたい」なら Amazon Bedrock AgentCore
という感じです。
今回は、Datadogとも組み込みが可能で、すぐに試せるAWS DevOps Agentを利用しました。
組み込みの詳細は以下のAWS公式ドキュメントをご確認ください。
Built-in integrations
また、セキュリティについては、エージェントのソースを利用してモデルのトレーニングなどは行わない旨が記載されています。
セキュリティの詳細は以下のAWS公式ドキュメントをご確認ください。
AWS does not use agent data, chat messages, or data from integrated data sources to train models or improve the product. The AWS DevOps Agent Space uses customer in-product feedback to improve the agent’s responses and investigations, but AWS does not use it to improve the service itself.
では、さっそくDatadog MCP ServerをAWS DevOps Agent経由で触ってみましょう。
今回の構成
AWS DevOps Agentから、Datadog MCP Serverを呼び出して連携させます。
Datadog側が公式でDatadog MCP Serverを提供・管理してくれているので、こちら側での管理は不要です。
環境構築
AWS DevOps Agentの構築（設定）
エージェントスペースの作成
AWSコンソールの検索窓に「DevOps Agent」と入力し、「AWS DevOps Agent」サービスをクリックします。
「エージェントスペース」に移動し、「エージェントスペースを作成」をクリックします。
「エージェントスペース名」は任意の名前を入力します。
「このエージェントスペースにAWSリソースへのアクセスを許可」では、デフォルトで「新しい DevOps エージェントロールを自動作成」が選択されています。
「作成されるエージェントスペースロール名」は自動で任意の値が入っていましたが、後でクリーンアップするときにわかりやすいように、ここでは末尾に「tomi」を付けています。
「ウェブアプリを有効化」の「作成されるウェブアプリロール名」も同様に「tomi」を付けています。
「作成」をクリックすると、上部に「Agent Space create successfully」と表示され、エージェントスペースの作成が完了します。
Capability Providersの設定
ここが、Datadog MCP Serverを設定する箇所になります。
「Capability Providers」を選択し、「Registration」タブに移動します。
そこに、利用可能（Available）なソースが表示されますが、検証時は「Datadog」が一番上にあったのですぐ見つかりました。
「Register」をクリックします。
「Datadog MCP サーバーの詳細」で値を設定します。
- 「サーバー名」は任意の名前にします。
- 「エンドポイント URL」は利用するDatadogリージョンによって変更が必要です（下に参考リンクあり）。
- 今回の検証ではUS1（デフォルト）を利用しているため、そのままでOKです。
入力が確認できたら「次へ」をクリックします。
「レビューして送信」で確認し、問題なければ「追加」をクリックします。
Datadogとの認証・認可のダイアログが表示されます。
全て確認して、問題なければ「Allow」をクリックします。
次のダイアログも確認します。
問題なければ「Authorize as ...」をクリックします。
「Capability Providers」の「Currently registered」に、今回設定したDatadogのプロバイダー名が表示されていればOKです。
ここに、先ほど作成したエージェントスペースを登録します。
そうすることで、エージェントスペースがこのDatadogの「Capability Providers」を利用できるようになります。
「エージェントスペース」から今回作成したエージェントスペースの詳細を表示し、下にスクロールしていきます。
「MCP サーバー」の「ソースの追加」をクリックします。
デフォルトではDatadogが表示されないため、「すべてのソースタイプ」を選択します。
すると、今回登録した「Datadog」が表示されるので、「追加」をクリックします。
「Datadogを関連付ける」で内容を確認し、問題なければ「保存」をクリックします。
「関連付けが正常に作成されました」と表示されればOKです。
「閉じる」をクリックします。
「Currently registered」のDatadogのプロバイダーの「エージェントスペース数」がカウントアップし、該当のエージェントスペースが登録されていることが確認できます。
以上で、設定は完了です。
参考リンク
Datadogで他のリージョンをお使いの方は、以下のドキュメントでエンドポイントURLの詳細が書いてあったので、参考にしてください。
（こちらはMicrosoftのAzure SRE AgentでDatadog MCP Serverを利用する記事です）
Determine your regional endpoint
検証
エージェントスペースの全体像
エージェントスペースの「オペレータアクセス」をクリックします。
AWS DevOps Agentの画面に遷移します。
左上が調査、右側にチャット画面が表示されていることがわかります。
今回は右側のチャットを利用します。
検証1：envタグが付いていないリソースを列挙して
Datadogには「Unified Service Tagging（統合サービスタグ付け）」という標準的なルールがあります。
その柱となるタグが env、service、version の3つです。
このタグがないと、情報の整理が難しくなります。
そこで、以下のように質問してみました。
Datadog MCP Serverのツールを使用して、現在Datadogで認識されているホストの一覧を取得して。その中から env:dev タグが付いていないものを抽出してほしい。
すると、以下のように回答が来ました。
申し訳ありませんが、現在利用可能なDatadogツールでは、ホストの一覧を直接取得する機能がありません。
利用可能なDatadogツールは以下の通りです：
ツール 機能
datadog_get_datadog_metric メトリクスのタイムシリーズデータを取得
datadog_search_datadog_logs ログの検索
datadog_search_datadog_spans APMトレース/スパンの検索
datadog_search_datadog_events イベントの検索
datadog_search_datadog_incidents インシデントの検索
datadog_search_datadog_monitors モニターの検索
datadog_search_datadog_metrics 利用可能なメトリクス名の検索
代替案
いくつかの方法でホスト情報に近づけるかもしれません：
メトリクスからホストを特定する - system.cpu.user などのシステムメトリクスを by {host} でグループ化して、アクティブなホストを確認できます
タグでメトリクスをフィルタリング - env:dev タグが付いていないホストのメトリクスを検索することは可能です
例えば、env:dev 以外の環境のホストを確認したい場合：
avg:system.cpu.user{NOT env:dev} by {host}
このようなメトリクスクエリで確認してみますか？または、Datadog UIのInfrastructure Listで直接ホスト一覧を確認するのが最も確実かもしれません。
現在のMCPツールの仕様上、ホスト一覧の直接取得は未対応との回答がありました。
回答は得られなかったものの、動作確認はできました。
提案してもらった内容を追撃で送ってみます。
なるほど、ツールの制約を教えてくれてありがとう。じゃあ代替案に乗るよ！ datadog_get_datadog_metric を使って、直近30分で system.cpu.idle のメトリクスを送信しているホストをリストアップして。 その際、各ホストに付いているタグも一緒に表示して、env:dev が漏れているものがないか確認してほしい。
すると、以下のように思考して、結果を出してくれました。
（都合上、小さなチャット画面のみとなります）
envタグがないリソースを発見し、対応方法まで指定してくれています。
検証2：モニター一覧を取得して
シンプルに今の設定状況を確認してもらいました。
数秒で回答が返ってきます。
これはあくまで一例ですが、こういった確認も瞬時に可能です。
クリーンアップ
エージェントスペースを削除します。
Capability Providers の登録を解除します。
今回作成したAgentSpace用とWebappAdmin用のIAMロールを削除します。
まとめ
今回は、AWS DevOps AgentとDatadog MCPの連携ハンズオンに挑戦しました。
すべてクラウドで完結するため、簡単に実践できました。
また、検証を通してAIを活用した新しい運用（AIOps）の大きな可能性を感じました。
お知らせ
弊社では、Datadogの導入支援から運用サポートまでをトータルでご支援するサービスを提供しています。
初期設計・エージェント展開・モニタリング設定・ダッシュボード構築まで、お客様のニーズに合わせた支援が可能です。
「自社だけでの導入が不安」「もっと効率的に監視環境を整えたい」という方は、ぜひお気軽にご相談ください。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
