Claude Media
Dynatrace MCPをClaudeにつなぐ手順 — ローカル版は終了、移行先で障害調査

Dynatrace MCPをClaudeにつなぐ手順 — ローカル版は終了、移行先で障害調査

Dynatrace MCPをClaude Codeにつなぐ手順です。ローカル版は非推奨になったため、リモートMCPサーバーとプラグインの設定、必要な権限、障害調査の頼み方を説明します。

DynatraceのデータをClaude Codeから読みたいとき、検索で最初に出てくるのはOSSの「Dynatrace MCP Server」です。ただしこのローカル版はすでに非推奨で、2.1.2が最終リリースです。今から接続するなら、Dynatrace自身がホストするリモートMCPサーバーか、Claude Code用プラグインを使います。

この記事では、移行先の選び方、Claude Codeへの接続コマンド、必要な権限、障害調査の頼み方を順に説明します。

ローカル版のDynatrace MCP Serverは非推奨になった

dynatrace-oss/dynatrace-mcp のREADMEには「DEPRECATED」の見出しがあり、「Version 2.1.2 was the final release — no further updates will be made」と書かれています。移行ガイドのほうは、2.1.1から非推奨という書き方です。どちらにせよ、新しい機能は入りません。

READMEは移行先を2つ挙げています。

  • ローカルの開発環境(Claude Code、VS Code、Cursorなど)向けには、Dynatrace-for-AIとdtctlの組み合わせ
  • エージェント間・リモート利用向けには、Dynatrace Remote MCP Server

ローカル版と、後継のリモート版の違いは次のとおりです。

項目ローカル版リモート版
動く場所ローカル版手元のマシン(npx / Node.js)リモート版Dynatrace環境の中
認証ローカル版ブラウザのOAuth、Platform Token、OAuthクライアントリモート版Platform Tokenが基本
更新ローカル版利用者が@latestなどで管理リモート版Dynatraceが自動更新
サポートローカル版コミュニティ(GitHub Issues)リモート版Dynatraceの正式サポート
通信方式ローカル版stdio(既定)またはHTTPリモート版Streamable HTTP

READMEには「This product is not officially supported by Dynatrace」とも明記されています。障害調査のように本番データに触れる用途では、サポートの有無が選定の分かれ目になります。

Claude Codeにつなぐ3つの経路

Claude Codeからは、次の3経路があります。

接続方法

Claude CodeからDynatraceに入る入口

  • プラグイン

    claude plugin install dynatrace@claude-plugins-officialで、スキルとMCP設定がまとめて入ります。最短の経路です。

  • リモートMCPのURLを直接登録

    claude mcp add --transport httpでURLとトークンを渡します。設定をリポジトリで共有したいときに向きます。

  • dtctlとスキル

    MCPを使わず、kubectl風のCLIをClaudeに操作させる構成です。MCPと併用もできます。

どれを選んでも、先に必要なのはDynatrace側の準備です。URLはapps.dynatrace.comドメインの環境URLを使います。READMEはlive.dynatrace.comのクラシックURLを使わないよう注意しています。

プラグインで接続する

Dynatraceのドキュメントが案内している手順です。環境変数を先に設定してからClaude Codeを起動します。

claude plugin install dynatrace@claude-plugins-official
export DT_ENVIRONMENT=https://abc12345.apps.dynatrace.com
export DT_PLATFORM_TOKEN=<your-platform-token>
claude

abc12345は環境IDの例です。起動後に/plugin listでプラグインが読み込まれたかを確かめられます。Dynatrace-for-AIのREADMEには、接続確認としてclaude mcp login plugin:dynatrace:dynatraceも載っています。

このプラグインにはスキルとMCPサーバーの設定が入っています。MCPサーバーの設定は、Dynatrace-for-AIリポジトリのmcp.jsonで公開されています。

リモートMCPのURLを直接登録する

プラグインを使わず、チームの.mcp.jsonで管理したい場合は、リモートMCPのURLを直接登録します。URLの形はDynatraceのドキュメントにあります。

https://{environment-name}.apps.dynatrace.com/platform-reserved/mcp-gateway/v0.1/servers/dynatrace-mcp/mcp

ドキュメントのVS Code向けの例は、このURLにAuthorization: Bearerヘッダーを付ける形です。Claude Codeの書式に当てはめると、たとえば次のようになります(2つのドキュメントを組み合わせた例で、Dynatrace側にClaude Code用のコマンド例はありません)。

claude mcp add --transport http dynatrace \
  "https://abc12345.apps.dynatrace.com/platform-reserved/mcp-gateway/v0.1/servers/dynatrace-mcp/mcp" \
  --header "Authorization: Bearer $DT_PLATFORM_TOKEN"

この書き方だと、トークンの実値が~/.claude.jsonなどの設定ファイルに残ります。チームで共有する場合は、.mcp.jsonに環境変数展開を使うほうが安全です。Claude Codeはurlとheadersで${VAR}と${VAR:-default}の展開に対応しています。

{
  "mcpServers": {
    "dynatrace": {
      "type": "http",
      "url": "https://${DT_ENVIRONMENT_HOST}/platform-reserved/mcp-gateway/v0.1/servers/dynatrace-mcp/mcp",
      "headers": {
        "Authorization": "Bearer ${DT_PLATFORM_TOKEN}"
      }
    }
  }
}

DT_ENVIRONMENT_HOSTはabc12345.apps.dynatrace.comのようなホスト名だけを入れる、この例用の変数名です。変数が未設定だと、Claude Codeはclaude mcp listと/mcpに警告を出し、${VAR}の文字列のままサーバーを読み込みます。接続に失敗したときは、まずこの警告を見ます。失敗したサーバーをまとめて再接続する方法は/mcp reconnect allの記事にあります。

OAuthで接続したい場合

Dynatraceのドキュメントでは、OAuthクライアント経由の認証も選べます。ただし条件があります。機密クライアント(confidential client)を作り、クライアントIDとシークレットの両方をMCPクライアントに渡す必要があります。CIMD、公開クライアント、動的クライアント登録にはまだ対応していません。シークレットがないと、トークン期限切れで接続が切れます。

Claude Code側には、事前登録した認証情報を渡す--client-idと--client-secretのフラグがあります。Dynatraceの条件を満たすクライアントなら、この経路で接続できる構造です。手間とトークンの短命さを考えると、ドキュメントが推奨するPlatform Tokenのほうが設定は単純です。

必要な権限(スコープ)

リモートMCPには、トークンとユーザーの両方に必要な権限があります。ドキュメントによれば、共通で次の2つが要ります。

  • mcp-gateway:servers:invoke
  • mcp-gateway:servers:read

これに加えて、使うツールごとの権限が必要です。障害調査でよく使うのは次のあたりです。

やりたいこと必要になる権限の例
ログを読む必要になる権限の例storage:logs:read
スパン(トレース)を読む必要になる権限の例storage:spans:read
問題・イベントを読む必要になる権限の例storage:events:read
自然言語からDQLを作る必要になる権限の例davis-copilot:nl2dql:execute
異常検知アナライザーを動かす必要になる権限の例davis:analyzers:read / davis:analyzers:execute

ドキュメントの動作確認では、Show me last 10 logsと頼み、「ユーザーとトークンの両方にstorage:logs:readが必要」と注記しています。トークンだけ権限を足しても、ユーザー自身に権限がなければ読めません。

トークンは調査用に権限を絞って作ります。読み取り専用の調査なら、書き込み系(storage:events:writeなど)は付けません。

障害調査をClaudeに任せる流れ

接続できたら、プロンプトの出発点はDynatraceが用意したものを使います。Dynatrace-for-AIには、障害調査向けのプロンプトが公開されています。

  • dt-investigate-error: Davisの問題を入り口に、ログ、トレースの順にたどる
  • dt-troubleshoot-problem: 既存の問題を、ログとトレースで構造的に調べる
  • dt-incident-response: 本番障害の切り分け、根本原因、共有用レポートまで

これらは、スキル(dt-obs-problems、dt-obs-logs、dt-obs-tracingなど)を先に読み込む前提で書かれています。スキルはDQLの書き方や問題エンティティの読み方を教える知識パッケージで、プラグインを入れれば同梱されます。

リモートMCPが持つツールには、問題の取得(query-problems、get-problem-by-id)、DQL実行(execute-dql)、障害対応ガイドの検索(find-troubleshooting-guides)があります。Claudeには、次のように頼めます。

dynatrace MCPで、直近2時間の本番(namespace: shop)の問題を
query-problemsで一覧にして。影響が大きいものを1件選び、
関連ログを直近1時間に絞ってERRORだけ読んで、原因の仮説を3つ挙げて。
DQLを実行する前に、使うクエリと対象期間を見せて。

最後の1行が実務上の肝です。DQLはGrailのスキャン量で課金されうるため、実行前にクエリと期間を確認させます。

プロジェクトのCLAUDE.mdにルールを書く

READMEには「Rule File」という節があり、コーディングエージェント向けに、自分のサービスを絞り込むフィルターを書いておくよう勧めています。この考え方をClaude CodeのCLAUDE.mdに置く例です(READMEの例を元にした書き方で、サービス名は差し替えてください)。

## Dynatraceでの調査ルール
- 対象サービスは `contains(entity.name, "checkout")` で絞る。
- ログは `fetch logs | filter contains(container.name, "checkout")`
  から始め、まず直近1時間だけ読む。
- 期間を24時間より広げるときは、先に理由を私に伝える。

READMEの別のコーナーでも、Grailの課金は「スキャンしたデータ量(GB)」に依存し、「12〜24時間のような短い期間から始める」ことが推奨されています。期間の上限をCLAUDE.mdで固定しておくと、聞かれるたびに指示しなくて済みます。

コストの管理 — ローカル版と同じ予算管理は期待しない

ローカル版は、DT_GRAIL_QUERY_BUDGET_GB(既定1000GB)でセッション単位のGrailクエリ予算を追跡し、80%に近づくと警告しました。移行ガイドのツール対応表では、reset_grail_budgetに対応するリモート側のツールは「—」です。

リモート版でも、execute-dqlはGrailにクエリを投げます。予算の警告に頼れない前提で、次の3点を運用に組み込みます。

  1. プロンプトまたはCLAUDE.mdで、期間とフィルターを必ず指定させる
  2. DQLの実行前に、クエリを人が確認する
  3. ローカル版のREADMEにあるdt.system.eventsのクエリのように、Notebookで自分のスキャン量を定期的に見る

3点目のクエリはローカル版のクライアント識別子(dynatrace-mcp)で絞っているため、リモート版にそのまま使えるかは保証されません。

ローカル版を使い続けるときの注意

リモート版にないツールを使っている場合は、移行ガイドが「ローカル版を併用する」ことを案内しています。ローカル専用のツールは、send_slack_message、send_email、send_event、create_dynatrace_notebookなどです。障害調査のあとにSlack通知やNotebookの作成まで任せていたなら、この部分が影響を受けます。

ローカル版をClaude Codeに追加する場合は、READMEのnpxコマンドをClaude Codeのstdio形式に当てはめます。Node.js v24以降が必要です。

claude mcp add dynatrace-local \
  --env DT_ENVIRONMENT=https://abc12345.apps.dynatrace.com \
  -- npx -y @dynatrace-oss/dynatrace-mcp-server@latest

@latestは最終版の2.1.2に固定されて更新されなくなるため、バージョンを明示する運用に向きます。認証は、DT_ENVIRONMENTだけを渡すと、初回にブラウザが開いてDynatraceのSSOにログインする流れです。トークンはOSのキーチェーンに保存されます。キーチェーンが使えないコンテナ環境ではDT_MCP_TOKEN_STORAGE=fileを設定します。

もう1つ知っておくべき点がテレメトリです。ローカル版は、サーバー起動、接続元のMCPクライアント、ツールの使用状況とエラーを、DynatraceのBizEventsとして送ります。既定で有効で、DT_MCP_DISABLE_TELEMETRY=trueで止められます。

つまずいたときの切り分け

症状見る場所
ログやスパンが空見る場所ユーザーとトークンの両方にstorage:*:readがあるか
接続できない見る場所DT_ENVIRONMENTがクラシックURL(live.dynatrace.com)になっていないか
数時間後に切れる見る場所OAuthクライアントで接続している場合、クライアントシークレットを渡したか
${VAR}がそのまま見える見る場所環境変数が未設定か。claude mcp listの警告で変数名が分かる

ローカル版の認証エラーは、スコープ不足かトークンの無効が大半だとREADMEは説明しています。トークンの動作確認として、環境情報を返すAPI(/platform/management/v1/environment)を直接呼ぶ手順も載っています。

他の可観測性ツールとの違い

同じ障害調査でも、ツールごとに接続の作法が違います。ログ起点ならGrafana Loki、アラート起点ならDatadogやSentryが先に候補に挙がります。設定の考え方はDatadog MCPのOAuthとtoolsetsの記事やmcp-grafanaのRBAC設計の記事が参考になります。Dynatraceは、Davisによる問題の自動検出と、DQLによるログ・スパン・メトリクスの横断が特徴で、「問題から入ってログとトレースへ降りる」順番がプロンプトにも反映されています。

まとめ

Dynatrace MCPをClaudeにつなぐなら、ローカル版のnpxではなく、リモートMCPかプラグインから始めるのが筋です。入口はプラグインが最短で、チーム共有なら.mcp.jsonの環境変数展開が向きます。

障害調査の質は、接続よりも運用で決まります。権限を読み取りに絞ること、期間とフィルターをCLAUDE.mdで固定すること、DQLを実行前に見ること。この3つが、Grailの課金と本番データの扱いの両方に効きます。

この記事を共有:XはてブLinkedIn