Datadog MCP Serverの接続手順｜toolsets選択と権限スコープの設計

AIクライアントからDatadogのログやメトリクスを直接参照させたいとき、最初の判断は「どこまで見せて、どこから書かせないか」です。Datadog MCP Serverはリモートホスト型で提供されるため、サーバーを自前で立てる工程はありません。代わりに、接続URLに付けるtoolsetsの選び方と、Datadog側のロール設計が実装の中身になります。2026年8月時点の公式ドキュメントをもとに、接続手順・権限の二層構造・障害調査での任せどころを順に整理します。

まとめ：Datadog MCP Server導入前に決めるtoolsetsと権限の線引き

先に結論を置きます。着手前に決めるのは3つです。どのツールセットを接続URLに載せるか、mcp_writeを付与するか外すか、そして書き込み系の操作を人の承認なしに許すか。この3点を後回しにすると、全ツールを開いた状態でAIが本番のモニターを書き換える構成が、検証のまま本番へ流れます。

既定値の扱いから述べます。多くのチームはcoreだけで足ります。エンドポイントにtoolsetsを付けなければ、ログ・メトリクス・トレース・ダッシュボード・モニターの参照が揃う構成です。toolsets=allを最初から指定する理由は、実務ではほぼありません。

権限は二層です。mcp_readとmcp_writeというMCP専用の権限に加えて、Monitors ReadやLogs Read Dataといったリソース側の権限が要ります。読み取り専用で運用したいなら、リソース権限を細かく削るより、mcp_writeそのものをロールから外すほうが素直です。理由はツール一覧の見え方が変わるためで、根拠は権限章に書きます。

そして書き込み。ノートブック作成やモニター作成を常時許可する運用は勧めません。調査は読み取りで完結させ、恒久的な設定変更はコード管理側に残す。この線引きが、AIに観測基盤を触らせるうえでの安全弁になります。

Datadog MCP Serverが提供する接続形態とツールセットの構成

MCPサーバーには、ローカルでプロセスを起動する方式とベンダーがホストする方式があります。Datadogは後者です。この違いが、導入工数と運用責任の両方を変えます。

リモートホスト型という提供形態とセルフホスト構築が不要になる理由

Datadog MCP Serverは、Datadog側がホストするリモートサーバーとして提供されます。クライアントはmcp.datadoghq.com宛のHTTPエンドポイントを登録するだけで、コンテナの配置もランタイムの用意も不要です。US1既定のエンドポイントは https://mcp.datadoghq.com/api/unstable/mcp-server/mcp で、パスにunstableが含まれる点は仕様変更の余地として頭に置いてください。

公式ブログでのプレビュー告知は2025年6月10日付、一般提供の開始は2026年3月10日とAP Communicationsの技術ブログ（2026年3月17日）が伝えています。プロトコル側の前提はMCPがAIと外部ツールをつなぐ標準規格として何を決めているかを先に読むと、toolsetsやツール名の意味が通りやすくなります。製品としてのDatadogが何を計測しているかはDatadogの機能構成と導入の背景で扱いました。

coreツールセットに含まれる読み取り19本と書き込み2本の内訳

既定で読み込まれるcoreは、2026年8月時点の公式リファレンスで読み取り19本と書き込み2本という構成です。読み取り側にはsearch_datadog_logs、analyze_datadog_logs、get_datadog_metric、search_datadog_spans、get_datadog_trace、search_datadog_monitors、search_datadog_incidents、search_datadog_hosts、search_datadog_servicesなどが並びます。障害調査で使う参照系はここでほぼ揃う設計です。

見落としやすいのが書き込み2本の存在。create_datadog_notebookとedit_datadog_notebookはcoreに含まれます。「既定のまま接続したから読み取り専用」ではありません。許可したくないなら、権限側かomit_tools側で落としてください。

apm・kubernetes・securityなど製品別ツールセットの追加指定

製品ごとのツールは、toolsetsで明示しない限り読み込まれません。2026年8月時点で指定できる値には apm、alerting、audit-trail、cost、dashboards、dbm、ddsql、error-tracking、feature-flags、kubernetes、llmobs、networks、profiling、rum、security、software-delivery、synthetics、workflows があります。用途と書き込みの有無を整理すると次のようになります。

apmはPreview表記のまま提供され、apm_latency_bottleneck_summaryのように調査を要約する専用ツールを含みます。複数使うならtoolsets=apm,alertingとカンマ区切りで並べる形です。

対応サイトの一覧とGovCloud環境が接続対象外になる前提条件

対応サイトは app.datadoghq.com（US1）、us3、us5、app.datadoghq.eu、ap1、ap2、uk1 です。一方で app.ddog-gov.com と us2.ddog-gov.com は非対応と明記されており、GovCloud互換もありません。政府系・規制系のテナントを使っているなら、検証を始める前にここで止まります。

クライアント側にも地域制限があります。ChatGPT AppはプレビューかつUS1のみ、Codex PluginもUS1のみ。EUサイト前提の組織がChatGPTで計画を立てると、接続段階で行き詰まります。接続元をIP allowlistで絞る運用も可能です。

MCPクライアント別の接続設定とOAuth認証・キー認証の使い分け

接続設定そのものは短時間で終わります。判断が要るのは認証方式で、ここを間違えると権限の絞り込みが効かなくなります。

エンドポイントURLとtoolsetsクエリパラメータの組み立て方

URLは「エンドポイント＋クエリパラメータ」の形です。何も付けなければcore、toolsets=allで一般提供済みの全ツールセット、個別指定はカンマ区切り。既存のクライアント設定ファイルに書く場合は、typeにhttpを指定し、urlへ組み立てたURLをそのまま入れる形式になります。

詰まりやすいのはサイトの取り違えです。EUサイトのアカウントでUS1のエンドポイントを登録すると、認証は通るのに目的のデータが出てきません。ログ検索が空振りしたら、まず接続先サイトを疑ってください。

OAuth 2.0による接続とアクセストークン方式の使い分け基準

認証は3通りあります。OAuth 2.0、Personal/Service Access Tokenをオーソライゼーションヘッダーへ載せる方式、そしてDD_API_KEYとDD_APPLICATION_KEYをヘッダーで渡す方式です。人が対話的に使う場面では、ブラウザ認証で完結するOAuthが既定解になります。長期の認可情報を端末に置かずに済むためです。

キー方式を選ぶのは、CIやバッチのように対話的な認証を挟めない経路。この場合はアプリケーションキーの持ち主が権限の実体になるので、個人アカウント名義を避けてサービスアカウントに持たせます。2種類のキーの役割分担とスコープの絞り方はDatadog APIでの認証キー設計と権限分離で扱った内容がそのまま当てはまります。

OAuthを選ぶと専用のOAuthアプリケーションが登録され、要求スコープが自動で設定されます。このスコープは編集できません。OAuth接続で権限を絞る手段は、ユーザー側のロール設計だけです。

Claude Code・Cursor・VS Code各クライアントの登録手順

主要クライアントには専用の導線が用意されています。手作業でJSONを書く前に、公式のインストーラがあるかを確認したほうが早く終わります。

1. Claude Code：スラッシュコマンドの /plugin install datadog@claude-plugins-official を実行し、認証フローを完了する
2. Cursor：Marketplaceから追加し、/ddsetup でセットアップを開始する
3. VS Code：Datadog拡張を入れ、「Datadog: Open MCP Configuration Assistant」を実行する
4. Claude（デスクトップ・Web）：Connectors DirectoryからDatadogを有効化し、OAuthを完了する
5. JetBrains系：設定ファイルのmcpServersにtypeとurlを書き、再読み込みする

手動設定に切り替えた直後は、プラグインの再読み込みや再認証が要る場合があります。ツール一覧が空のままなら、認証の失敗ではなく読み込みのタイミングを疑ってください。

omit_toolsによる不要ツール除外とコンテキスト消費の抑制

ツールを増やすほど、クライアントの初期コンテキストにツール定義が積まれます。50本規模のツール定義は無視できない量です。使わないものは落としてください。

omit_toolsにツール名をカンマ区切りで並べると、個別に除外できます。全文検索系のように定義が大きいものから外すと効果が出やすい構成です。ツールセット単位で足し、ツール単位で引く。この順で調整すると、必要な参照系だけが残ります。

mcp_readとmcp_writeによる二層の権限設計と書き込み抑止の手順

権限まわりは、MCP専用の権限とリソース権限が重なる二層構造です。ここを理解しないまま「読み取り専用にしたつもり」が一番危ない状態を作ります。

mcp_readとmcp_writeがツール一覧そのものを増減させる仕組み

Datadog側の権限には mcp_read と mcp_write があり、前者が読み取りツール、後者が作成・変更ツールの利用条件です。Standard Roleには既定で両方が含まれます。つまり標準的なロールを当てたユーザーがOAuthで接続すると、その時点で書き込み系まで開きます。

この2つは、単なる実行時のチェックではありません。クライアントへ提示されるツール一覧そのものが変わります。公開されている検証記事では、mcp_writeを外したロールで接続するとツール数が50本から42本へ減り、モニター作成ツールが一覧から消えたと報告されています。ツールが存在しなければ、AIはそれを呼ぶ選択肢を持ちません。

カスタムロールでmcp_writeを外す読み取り専用構成の作り方

マネージドロールは権限を編集できないため、クローンして調整します。手順は次のとおりです。

1. Organization Settings のRolesで対象のマネージドロールをクローンする
2. 「Automatically Receives Permissions」に親ロールを指定して差分管理にする
3. クローンしたロールから mcp_write のチェックを外す
4. 対象ユーザーまたはサービスアカウントへ新しいロールを付け替える
5. クライアントを再認証し、ツール一覧から書き込み系が消えたことを確認する

カスタムロールを使う場合、mcp_read と mcp_write は既定で入らないため、読み取りだけを許すなら mcp_read を明示的に有効化する必要があります。加えて Logs Read Data や Monitors Read といったリソース側の権限も要ります。片方だけではツールが動きません。

リソース権限だけを外した構成で残る実行時エラーという失敗パターン

よくある誤りが、mcp_writeは付けたままモニターの書き込み権限だけを外す構成です。前掲の検証記事によると、この場合ツール数は50本のまま変わらず、モニター作成を試みた段階で権限不足のエラーになったとされています。止まるので事故にはなりませんが、AIは呼べると判断して実行し、失敗し、代替手段を探して再試行します。

結果として消費するのはトークンと時間です。禁止したい操作は、実行時に弾くのではなく一覧から消す。同じ「書けない」でも、コスト面で差が出ます。読み取り専用を目指すなら mcp_write を外す方針を既定にしてください。

障害調査でAIクライアントに任せる範囲と人が判断を残す工程の線引き

接続できた後に問われるのは、何を任せるかです。全部任せる前提で設計すると、権限も監査もすぐ破綻します。

異常検知から原因仮説の提示までをMCP経由で辿る障害調査の進め方

MCP経由の調査が効くのは、複数の画面を往復する探索フェーズです。エラー率の上昇を掴み、対象サービスの遅いスパンを絞り、関連ログを引き、直近のデプロイイベントを確認する。この一連をひとつの対話で辿れると、画面の持ち替えが減ります。

具体的にはsearch_datadog_spansでエラースパンを取り、get_datadog_traceで該当トレースを開き、search_datadog_logsで同一トレースIDのログを引く流れです。apmツールセットを足せば、遅延要因の要約を返すツールも使えます。ここまでは読み取りだけで完結します。

モニター作成やノートブック編集を書き込み系ツールに任せる境界

書き込み系で実務に耐えるのは、失われても復旧できる対象に限られます。調査ノートブックの生成は、間違っていても消せば済むので許容範囲です。一方でモニター作成は、本番のアラート体系に直接影響します。

判断基準は「その変更が夜間の呼び出しに影響するか」。影響するならAIに直接実行させず、定義の草案だけ出させて人がレビューする。alertingにはvalidate_datadog_monitorという検証専用ツールがあり、作成権限を渡さずに定義の妥当性だけ確認させられます。

恒久的な設定管理をTerraformとAPIに残す運用上の切り分け

モニターやダッシュボードのように存在し続ける設定は、コード管理に残してください。MCP経由の書き込みと宣言的管理が併存すると、applyのたびに設定が往復します。MCPは調査、Terraformは定義、APIは一過性の一括操作。この三分割が破綻しにくい構成です。

ダッシュボードのupsert_datadog_dashboardとdelete_datadog_dashboardは特に注意が要ります。upsertは既存の定義を丸ごと置き換えるため、コード管理下のダッシュボードをAIが更新すると差分が消えます。コード管理しているリソースが多い組織ほど、dashboardsツールセットの追加は慎重に判断してください。

Datadog MCP Serverの採用条件と見送るべき運用体制の判断基準

ここからは判断を言い切ります。接続が簡単なことと、入れるべきことは別の話です。

採用してよい条件はタグ設計と権限運用が整っている組織であること

採用してよいのは、envやserviceのタグが揃っていて、ロール設計が個人任せになっていない組織です。AIはタグを頼りに対象を絞ります。タグが揃っていない環境では、検索が広すぎて的外れなスパンを拾い、調査時間が短くなりません。前提となるタグ設計と監視対象の絞り込みはDatadog運用のベストプラクティスとして整理したタグ命名とアラート設計を先に通してください。

逆に言えば、この2つが整っているなら導入の障壁は低いです。読み取り専用ロールで小さく始め、効果が出た調査パターンだけを定着させる進め方を勧めます。

見送るべき場面は本番データの持ち出し統制が未整備な運用チーム体制

見送るべき場面を条件で示します。本番ログに個人情報や決済情報が入っており、外部LLMへの送信範囲を統制する仕組みが無いなら、この段階では接続しないでください。MCPは参照した内容をクライアント側のモデルへ渡す仕組みです。ログ検索の結果は、そのまま推論のコンテキストに載ります。

もう1つ。誰がどのツールを呼んだかを追えない体制も見送り対象です。制御点はロールしかないため、棚卸しが年単位で止まっている組織では、権限設計が実態と乖離したまま接続だけが広がります。この2条件のどちらかに当たるなら、統制を先に整えるほうが結果的に早いです。

コンテキスト消費と応答時間から見た常時接続の是非と代替する手段

常時接続すべきかという問いには、条件付きで「しない」と答えます。全ツールセットを読み込ませる構成は、調査以外の作業でも毎回ツール定義の分を負担します。障害調査用のプロファイルとして接続し、平時は外す。この運用のほうが軽く済みます。

調査の自動化そのものを製品側に寄せる選択肢もあります。どこまでを自社の運用設計として組み立て、どこからをAIエージェントの実装として作り込むかで迷う場合は、AIエージェント開発の相談から要件を整理するところから始められます。観測データの参照範囲と権限設計は、実装より先に決めるべき項目です。

よくある質問

Datadog MCP Serverの接続と権限まわりで、検証時に問い合わせが集まる5点をまとめます。

Datadog MCP Serverの利用に追加料金はかかりますか？

2026年8月時点の公式ドキュメントには、MCP Server自体の課金についての記載がありません。実務上の費用は、参照するデータ側の課金に従うと考えるのが安全です。インデックス済みログの検索やカスタムメトリクスの参照は、通常のDatadogの課金単位で計上されます。AIに広い期間を繰り返し検索させると、検索そのものより、対象を広げるために保持設定やインデックスを増やす方向で費用が動きます。

読み取り専用で使うにはどう設定すればよいですか？

マネージドロールをクローンしたカスタムロールを作り、mcp_write を外したうえで mcp_read と必要なリソース読み取り権限を付けます。リソース側の書き込み権限だけを外す方法でも操作は失敗しますが、ツール一覧には書き込み系が残るため、AIが呼びに行って失敗する分のトークンを消費します。coreのノートブック作成・編集も書き込み系なので、この2本が一覧から消えたかを確認してください。

どのMCPクライアントから接続できますか？

公式ドキュメントには Cursor、Claude Code、Gemini CLI、VS Code、Warp、Devin、JetBrains IDEs、OpenAI Codex、ChatGPT、Claude、Goose、OpenCode、Copilot CLI、Kiro などが挙がっています。ただし地域制限があり、ChatGPT AppはプレビューかつUS1のみ、Codex PluginもUS1のみです。EUやAP1のサイトなら、クライアント選定の前に対応状況を確認してください。一覧に無い汎用クライアントでも、typeにhttpを指定してURLとヘッダーを渡せば接続できます。

toolsets=allを指定すると何が起きますか？

一般提供済みのツールセットがすべて読み込まれ、ツール定義がクライアントの初期コンテキストへ積まれます。security や dashboards のように書き込み系を含むものも入るため、権限が広いユーザーで接続すると検知ルールの作成やダッシュボードの削除まで到達できる状態になります。調査目的で足りるのは core、あるいは core に apm を足した構成です。まず狭く開き、不足が分かってから足す順序を勧めます。

既存のDatadog APIやTerraform管理とどう使い分けますか？

用途で分けます。MCPは人が対話しながら観測データを探索する経路、APIはスクリプトから一過性の操作を行う経路、Terraformはモニターやダッシュボードの定義を恒久的に管理する経路です。同じリソースをMCPとTerraformの両方から書き換えると設定が往復するため、コード管理下にあるリソースはMCP側で書き込み対象から外してください。読み取りに限れば三者は競合しないので、調査だけをMCPへ寄せる構成から始めるのが無難です。

関連記事

• Bits AI SREの基本概要とDatadog製品群内での位置付け：調査の自動化を製品側で担う、MCP接続とは別レイヤの選択肢です。
• Datadog LLM Observability実装：llmobsツールセットが参照する側のデータをどう作るかを扱っています。
• Datadogの料金体系と費用が膨らむ課金単位：MCP経由の検索が跳ねる先となるインデックスと保持の課金を整理しています。
• Datadog OpenTelemetry連携の4方式：参照対象のテレメトリをどの経路で集めるかを扱っています。