Datadog 料金の確認方法 - 使用量画面と Usage Attribution

請求は「月末に知る」ものではない - 3 つの確認口

Datadog の請求で事故が起きる組織に共通するのは、金額を月末の請求書で初めて知ることです。課金は 1 日 (UTC) に始まる月単位のサイクルで、ホストとカスタムメトリクスは 1 時間ごとに計測され、月末にまとめて請求額が決まります (2026 年 9 月時点・出典: Billing)。つまり月の途中でも「ここまでの使用量」は毎時積み上がっており、それを見る窓口が 3 つ用意されています。1 つ目は管理者が開く Plan & Usage の使用量画面で、月初からの累計 (Month-to-Date) を製品別に確かめる場所です。2 つ目は Usage Attribution で、同じ使用量をチームや環境のタグで割って「誰がいくら使ったか」に変える仕組みです。3 つ目は datadog.estimated_usage.* という名前で提供される使用量メトリクスで、ほかのメトリクスと同じように モニターに載せ、跳ねた瞬間に通知を出せます。この 3 つは役割が違います。画面は「確定に近い数字を月次で読む」、配賦は「チームに返す」、メトリクスは「日々の変化を機械に見張らせる」ためのもので、どれか 1 つでは足りません。本記事はこの順に使い方を追い、最後に週 1 回の運用に落とし込みます。料金体系そのものの読み方は料金の読み解きで扱っているので、本記事は「どこを見れば分かるか」に集中します。

Plan & Usage の使用量画面で見えるもの、見えないもの

使用量画面は管理者 (Administrator ロール) が左下のアカウントメニューから Plan & Usage を開き、Usage タブに進むと表示されます。製品カテゴリ別のタブがあり、All タブでは当月のインフラホスト、コンテナ、カスタムメトリクス、APM ホスト、ログなどの Month-to-Date 使用量が並びます。ここで最初に理解しておきたいのが、数字の「数え方」が製品ごとに違う点です。インフラホストと APM ホストは当月の全時間帯のうち 99 パーセンタイル値、カスタムメトリクスは全時間帯の平均、取り込みログはバイト数の合計、インデックス済みログとスパンはイベント数の合計、Synthetics はテスト実行数の合計、と定義されています (2026 年 9 月時点・出典: Usage Details)。ホストが 99 パーセンタイルなのは、上位 1% の時間帯を除いた最大値で請求するという課金規則の反映で、短時間のオートスケールで台数が跳ねても請求には乗りにくい設計です (出典: Billing)。

見えないものも押さえておきます。第一に、この画面の更新には最長 72 時間かかると案内されており、「今この瞬間」の値ではありません。第二に、All 表示にはトライアル中の製品など請求に乗らない使用量が含まれ、請求に乗る分だけを見るには Billable 表示に切り替える必要があります (Billable 表示は多くのアカウントで利用でき、コミット分 / 割当分 / オンデマンド分に分解されます)。第三に、契約外の製品を初めて使ったときにメールで知らせる First-time usage notifications と、オンデマンド分を紫のラベルで強調する表示は 2026 年 9 月時点でベータ扱いで、担当者への申請が必要です (出典: Plan & Usage、Usage Details)。

Usage Attribution はタグで「誰がいくら使ったか」に変える

使用量の総額が分かっても、チームに返せなければ削減は進みません。Usage Attribution は Plan & Usage のタブの 1 つで、使用量を最大 3 つのタグキー (team や env、service など) で分解し、月次と時間別の CSV を生成する機能です。管理者または Usage Read 権限を持つユーザーが開け、タグを設定してから最初のレポートが出るまで 24 時間かかり、以後は日次で更新されます。月次レポートは Month-to-Date の集計で、値と割合の両方を表に出せ、CSV には使用量と百分率の両方が含まれるため、そのまま部門別の配賦 (チャージバック) の元データにできます (2026 年 9 月時点・出典: Usage Attribution)。前提として知っておくべき制約が 3 つあります。まず、計装時にタグを付けられない製品は対象外で、公式ドキュメントは Incident Management のユーザー数、CI Pipeline / Test のユーザー数、並列テストスロット、Audit Trail を例に挙げています。次に、月の途中でタグキーを変えると、その月は期間ごとの部分レポートに分かれます。最後に、配賦したい単位のタグがそもそも全リソースに付いていなければ、レポートには「タグなし」の行が太く残るだけです。タグの設計が配賦の精度をそのまま決めるので、team タグを Agent の設定とデプロイの雛形に焼き込む作業が先になります。直接請求の契約では、月末に前月分のコスト配賦レポートも生成され、翌月 19 日までに参照できるようになります。使用量ではなく金額で配賦したい場合はこちらを使います。

使用量メトリクスでモニターを組み、跳ねた瞬間に知る

画面と配賦は「読む」道具です。人が見なくても気づける仕組みにするには、使用量メトリクスを使います。Datadog は当月の推定使用量をほぼリアルタイムで datadog.estimated_usage.* 系のメトリクスとして提供しており、グラフに描く、閾値でモニターを組む、コード変更の影響を即日確かめる、という用途を公式ドキュメントが挙げています。名前は用途ごとに決まっていて、主なものを表に整理します。

モニターの条件式には、この名前をそのまま使います。

avg:datadog.estimated_usage.metrics.custom{*}
sum:datadog.estimated_usage.logs.ingested_bytes{env:prod}

注意点が 1 つあり、これらは推定値で、請求に使われる値とは平均で 10〜20% の差があり、使用量が小さいほど誤差は大きいと明記されています。したがって使い方は「金額の確定」ではなく「変化の検知」です。たとえばカスタムメトリクス数の 1 時間値に前週比で閾値を置く、ログ取り込みバイト数の日次合計に上限を置く、といった形です。.by_tag 系でチーム別に分けたいときは、Usage Attribution 側で同じタグキーを設定しておく必要があります (Pro プランでは担当者経由の申請が必要と案内されています)。まず全体を見張るモニターを 1 本ずつ作り、ダッシュボードのプリセット一覧にある Estimated usage のダッシュボードを複製して眺める、という順で始めると、名前を全部覚える前に運用が回り始めます。

跳ねやすい 4 費目はこの順に確かめる

請求が想定を超えるとき、原因はほぼ決まった 4 費目に集中します。カスタムメトリクス、ログ取り込み、スパン取り込み、Synthetics の実行回数です。共通点は「ホスト数が変わらなくても、コードや設定の 1 行で量が跳ねる」ことで、ホスト単価の見積もりだけでは捕まえられません。確認の順序は、跳ねたときの金額の振れ幅が大きいものからです。

1 位にカスタムメトリクスを置く理由は、原因が「1 本のメトリクス」に集中しやすく、Top 5000 の一覧で寄与率を見れば数分で原因のメトリクスを特定できるからです。カスタムメトリクスの個数はタグ値の組み合わせで増えるので、カーディナリティの高いタグを 1 つ付けただけで数十倍になります。ログはインデックス別の内訳で「どのインデックスが伸びたか」を見てから、取り込み制御で絞る、という順序です。4 費目を月初と月中の 2 回この順に眺めるだけで、月末の驚きは大半が消えます。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。

「先読み」の運用は週 1 回、誰が何を見るかを決める

仕組みが揃っても、見る人と頻度が決まっていなければ請求は元に戻ります。ここまでの 3 つの確認口を、無理なく続く運用に落とし込むと次の形になります。

ポイントは、日次を機械に任せて人は週次に絞ることです。使用量画面は最長 72 時間遅れ、推定メトリクスには 10〜20% の誤差があるので、両方を毎日人が見ても判断の精度は上がりません。週 1 回、前週との差分だけを見る方が、変化の発見は早く、負担は軽くなります。もう 1 つは「増えた理由を 1 つ言える」ことをゴールにする点です。使用量が増えること自体は監視対象が増えた健全な結果かもしれません。問題なのは説明できない増加で、Usage Attribution の team 別 CSV があれば「先週から増えた 30% は決済チームの新サービス分」と即答できます。この説明責任がチームに戻ると、開発者自身がメトリクスのタグ設計やログレベルを気にし始め、管理者が後から削る作業が減っていきます。

確認した数字をどう使うか - 契約量の見直しと料金体系の理解へ

使用量が読めるようになると、次に効くのは契約の形です。Plan & Usage の Subscription Details には、コミットしている各製品の数量、契約単価、オンデマンド単価が並びます (2026 年 9 月時点・出典: Billing)。Billable 表示でオンデマンド分が毎月安定して出ているなら、その床の分を年契約に移すと単価が下がり、逆にコミット量を大きく下回っているなら次回の更新で減らす材料になります。請求書払いの契約では、請求書は Billing 画面に登録した請求先連絡先へ届くので (出典: 前掲 Billing)、月初の週次確認で当月分の傾向を先に掴み、届いた請求書は「確認済みの数字の答え合わせ」にする、という順序が理想です。使用量の確認は、どの SKU が何を単位に課金されるかを知っているほど速くなります。カスタムメトリクスが「個数の平均」で、ログが「取り込みはバイト、インデックスはイベント数」で数えられる理由は料金体系の側にあり、その全体像は料金体系の読み解き方で、導入前の損得判断は導入判断チェックリストで扱っています。まだ有料契約の前なら、無料プランとトライアルで実測量を取る手順も参考になります。