Datadogのカスタムメトリクス費用を減らす — 使用量APIとClaude Codeで特定

Datadogのカスタムメトリクスとログの費用は、使用量APIで上位を出せば原因が見えます。カスタムメトリクスはtop_avg_metrics、ログはlogs_by_indexが入口です。その出力をClaude Codeに渡し、タグ削減とログ除外ルールを「現在の設定との差分」で作らせます。適用は人が行う、という分担が安全です。

費用が膨らむ原因は、メトリクスなら名前よりもタグの組み合わせ数、ログなら取り込み後に索引されるイベント数です。どちらも画面の合計値だけでは犯人が分かりません。ここでは使用量APIの出力から上位を絞り、設定変更案を作り、適用前に確認するところまでを順に進めます。Datadog MCPの接続自体はDatadog MCPをClaude Codeに接続する方法にまとめています。

カスタムメトリクスの費用はどう数えられるか — 時系列数とログ

カスタムメトリクスは、メトリクス名とタグ値(ホストタグを含む)の組み合わせごとに1つと数えます。同じ名前でもタグ値の組み合わせが増えるほど、本数が増えます。

請求に使われるのは、月内の各時間の本数を合計し、時間数で割った月平均です。データポイントの送信頻度や、メトリクスに対するクエリ回数は請求量に影響しません。

契約が「Metric Name pricing」のSKUの場合は、数え方が別のページで定義されています。契約書の項目名を先に確かめてから、以下の読み替えを判断してください。

ログ側は、インデックス済みログの費用が、索引に入ったイベント数で決まります。除外フィルターで捨てられたログは索引から消えますが、Live Tailには流れ、ログからのメトリクス生成とアーカイブにも使えます。削っても失わないものが何かを、先に押さえておけます。

Metrics without Limitsで本数が変わる仕組み

タグ構成を絞ると、インデックス済み本数だけが減ります。公式の例では、request.Latencyの4通りの組み合わせからendpointとstatusだけを残すと、3本のインデックス済みと4本の取り込み済みになります。

注意点は2つあります。

• タグ構成を設定したメトリクスだけが、取り込み済みの本数としても数えられます。設定していないメトリクスは、インデックス済みの本数だけの課金です
• 設定済みメトリクスの取り込み超過分は、100本あたり0.10ドルです

つまりタグを絞っても、取り込み側の本数は残ります。送信側のコードでタグ自体を減らす対応と、費用の出方が違います。

準備 — 権限とClaude Codeに渡す範囲

使用量APIはusage_read権限が必要です。公式のcurl例は、Personal Access TokenかService Access TokenをAuthorization: Bearerヘッダーに載せる形です。APIキーとアプリケーションキーを環境変数で渡すSDK例もあります。

タグ構成の変更APIはmetric_tags_write権限を要求し、Manage Tags for Metrics権限を持つユーザーのアプリケーションキーでしか使えません。ガバナンスのガイドでは同じ権限がmetrics_tags_writeと書かれています。ページ間で綴りが違うため、ロールに権限を付けるときは画面上の名前で探してください。

Claude Codeには、読み取りだけのトークンを渡すのが基本です。調査用のスクリプトを1本置き、その実行だけを許可すると、設定変更のリクエストは人間の手元に残ります。

{
  "permissions": {
    "allow": ["Bash(./scripts/dd-usage.sh *)", "Bash(jq *)"],
    "deny": ["Bash(curl *)"]
  }
}

ただし、Bashの引数を絞る許可ルールは、オプションの順序やリダイレクトで抜けやすいと公式が注意しています。許可ルールだけを防御線にせず、トークンの権限そのものを読み取りに限る方が確実です。

手順1 — カスタムメトリクスの上位を出す

最初に、月内の平均本数が大きいメトリクス名を取ります。top_avg_metricsは、monthかdayのどちらか一方を必ず指定します。limitは1〜5000で、省略時は500件です。

export DD_SITE="datadoghq.com"
curl -s "https://api.${DD_SITE}/api/v1/usage/top_avg_metrics\
?month=2026-10&limit=1000" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer ${DD_BEARER_TOKEN}" \
  > usage/top_metrics.json

DD_SITEには契約サイトのドメインを入れます。datadoghq.euならapi.datadoghq.euになります。

応答のusage配列には、metric_name、avg_metric_hour(その名前が現れる時系列数の時間平均)、max_metric_hour(時間あたり最大)が入ります。結果がlimitを超える場合は、pagination.next_record_idを同じ条件に足して続きを取ります。

jq -r '.usage | sort_by(-.avg_metric_hour) | .[:20][]
  | [.metric_name, .avg_metric_hour, .max_metric_hour] | @tsv' \
  usage/top_metrics.json

出力は、例えば次のような3列のタブ区切りになります(項目名はAPIの応答に沿った例で、数値は架空です)。

app.request.latency     182400   190100
batch.job.duration       61200    88000

平均と最大の差が大きいメトリクスは、特定の時間帯にタグ値が急増している可能性があります。まず平均の大きい順に見て、次に差の大きい順で見直すと、定常的な肥大と突発的な暴れを分けられます。

どのタグがカーディナリティを押し上げているか

上位が決まったら、メトリクスごとにタグ値の数を調べます。画面では、メトリクスの詳細パネルにある「Custom Metrics Tags Cardinality Explorer」が、増加の大きいタグキーを示します。APIではGET /api/v2/metrics/{metric_name}/tag-cardinalitiesの「Get tag key cardinality details」が同じ目的です。

絞り込み後の本数は、GET /api/v2/metrics/{metric_name}/estimateで試算できます。

curl -s -g "https://api.${DD_SITE}/api/v2/metrics/app.request.latency/estimate\
?filter[groups]=endpoint,status" \
  -H "Authorization: Bearer ${DD_BEARER_TOKEN}"

filter[groups]に残したいタグキーを並べます。filter[exclude_tags_mode]=trueを付けると、並べたキーを「除外するタグ」として扱います。-gは、角括弧をcurlのURL展開と取り違えないための指定です。

手順2 — ログのどこが費用を押し上げているか

ログは、インデックス単位の取り込み量から入ります。logs_by_indexはstart_hrが必須で、end_hrはその時刻の直前までを含みます。index_nameでインデックスを絞れます。

curl -s "https://api.${DD_SITE}/api/v1/usage/logs_by_index\
?start_hr=2026-10-01T00&end_hr=2026-10-28T00" \
  -H "Authorization: Bearer ${DD_BEARER_TOKEN}" \
  > usage/logs_by_index.json
jq '.usage | group_by(.index_name)
  | map({index: .[0].index_name, events: (map(.event_count) | add)})
  | sort_by(-.events)' usage/logs_by_index.json

応答にはevent_count、hour、index_name、retention(保持日数)が入ります。インデックス別の合計が分かれば、次は中身の内訳です。ここはDatadog MCPのcoreツールが向いています。analyze_datadog_logsはSQLで件数を集計し、search_datadog_logsは条件に合うログを返します。必要な権限はどちらもLogs Read DataとLogs Read Index Dataです。

「サービス別・ステータス別の件数を上位10件」のように指示すれば、除外候補になるDEBUGログや死活監視ログが浮かびます。

手順3 — Claude Codeに差分で提案させる

使用量の数字だけでは、どのタグを消してよいかは決まりません。そこで、Claude Codeに渡す材料を3つに分けます。

Claude Codeへの依頼は、出力の置き場所と禁止事項を先に決めると安定します。

usage/top_metrics.json の上位10件について、estimate API の結果と
現在のタグ構成を比べ、残すタグキーの案を proposed/tags-<metric>.json に
出力してください。APIへの書き込みリクエストは実行しないでください。
各ファイルの先頭に、削るタグと理由を1行ずつ書いてください。

タグ構成の変更は、POST /api/v2/metrics/{metric_name}/tagsの本文に次の形で書きます。

{
  "data": {
    "type": "manage_tags",
    "id": "app.request.latency",
    "attributes": {
      "tags": ["endpoint", "status"],
      "metric_type": "gauge"
    }
  }
}

ログの除外は、インデックス更新APIのexclusion_filters配列に書きます。1件ごとに名前、有効・無効、クエリ、sample_rateを持ち、sample_rateが1.0なら該当ログをすべて除外します。

{
  "name": "drop-debug-health",
  "is_enabled": true,
  "filter": { "query": "status:debug service:web", "sample_rate": 1.0 }
}

更新APIの本文では、インデックスのfilterが必須項目です。除外ルールだけを送るのでなく、GETで保存した現在の定義にexclusion_filtersだけを足したものを作らせ、diffで前後を並べて読みます。

diff <(jq -S . snapshot/index-main.json) \
     <(jq -S . proposed/index-main.json)

差分が除外ルールの追加だけに収まっていれば、本文のその他の項目を書き換えていない証拠になります。

MCPで足りるところと足りないところ

Datadog MCPのcoreツールには、get_datadog_metric_context(メトリクスのタグと値の一覧)や、上のログ集計ツールがあります。coreツールには、使用量APIのtop_avg_metricsやlogs_by_indexに当たるものがありません。cost toolsetのcost_recommendationsはクラウド費用の節約提案を返すもので、Datadog自体の請求内訳は返しません。請求に直結する数字は、使用量APIをスクリプト経由で取る分担になります。

もう1つ、MCPの出力量にも上限があります。Claude Codeは1回のツール出力が10,000トークンを超えると警告を出し、既定では25,000トークンで切ります。上限はMAX_MCP_OUTPUT_TOKENSで変えられますが、上位数千件のメトリクス一覧は、ファイルに落としてからjqで絞る方が確実です。

適用前に確認すること

次の3点を適用前に押さえます。

• 誰がいつ変えたか: タグ構成の変更は監査証跡に残ります。イベントエクスプローラーでtags:audit "Queryable tag configuration"を検索すると、設定内容と変更者が見えます
• 誰が変えられるか: metrics_tags_writeを持つロールを限ると、意図しない構成変更を防げます
• ログ除外の順序: 一致した最初の有効な除外フィルターだけが適用され、一致した時点で後続は無視されます。サンプリングしないルールを先頭に置くと、後ろの除外が効きません

使われていないメトリクスから始めると、影響を抑えられます。Query Activityのファセットで「クエリされていない」ものを探し、さらに関連アセットがないものに絞ります。Datadogは、クエリされていないメトリクスにMetrics without Limitsを使うと平均的な顧客で最大70%減らせたと説明しています。

効果の確認 — 翌日の再実行とアラート

月平均で課金されるため、変更した日に請求が下がるわけではありません。確認は2段階です。

1. 同じスクリプトで、変更後にtop_avg_metricsとlogs_by_indexを取り直し、対象の本数とイベント数が下がっていることを見る
2. 推定使用量のメトリクスdatadog.estimated_usage.metrics.custom.by_metricで、メトリクス名ごとの本数をモニターにする

後者は、本数が急増したときに気づく仕組みです。調査から運用に移すと、再び費用が膨らむ前に検知できます。アラート閾値の調整はDatadog×Coworkで障害時のアラート閾値を調整するも参考になります。

調査用のスクリプトと提案ファイルをリポジトリに置き、CIやスケジュール実行に載せる流れは、Claude CodeでGitHub Actionsを高速化と同じ構造です。数字を取り、原因を絞り、差分を提案させるところまでを自動化し、適用は人が承認する分担になります。