Datadog の料金体系の読み解き方 - SKU 別の課金単位と課金事故の防ぎ方

料金表が読みにくい理由 - SKU の積み上げと 3 つの単価

Datadog の料金表を初めて開いた人がまず戸惑うのは、「Datadog の月額はいくら」という 1 つの答えが存在しないことです。インフラ監視・APM・ログ管理といったプロダクトごとに課金単位の異なる SKU (課金項目) が定義されており、実際の請求は使ったプロダクトの SKU を積み上げた合計になります。2026 年 8 月時点の公式料金ページでは 100 を超える SKU がリージョン別に定義されています (出典: Datadog 料金ページ)。さらに同じ SKU に対して、年契約 (annual)・月契約 (month-to-month)・オンデマンド (on-demand) という複数の単価が併記されます。料金ページの脚注の定型文は「Billed annually or $X on-demand」で、年契約の単価とオンデマンドの単価が常にセットで示される構造です。この構造を知らないまま「1 ホスト 15 ドル」といった単一の数字だけで見積もると、請求とのずれが必ず生まれます。本記事では、この料金体系をどの順番で読めば実際の請求額を予測できるようになるかを、2026 年 8 月時点の公式一次情報だけを根拠に整理します。なお、本記事の価格は各時点の実例であり、執筆後の価格改定を反映するものではありません。

第 1 段階 - 課金単位を SKU 別に確認する

読み解きの第 1 段階は、金額の前に「何を数えて課金されるか」= 課金単位の確認です。Datadog では同じ監視対象でもプロダクトによって数える物が変わります。ホスト単位・GB 単位・イベント数単位・セッション数単位・テスト実行数単位が混在しており、これを取り違えると桁単位で見積もりを外します。2026 年 8 月時点の主要 SKU の課金単位と単価 (US リージョン・USD・月額) は次のとおりです。

この表から読み取るべきは個々の金額よりも「単位の設計」です。インフラ監視と APM は台数に比例し、ログとトレースは流量に比例し、Synthetics は実行回数に比例します。つまり構成が同じでもトラフィックが増えれば流量系 SKU だけが伸び、テスト頻度を上げれば Synthetics だけが伸びる、という独立した伸び方をします。自分の環境で「どの軸が伸びやすいか」を先に見極めることが、料金表を読む出発点になります。

第 2 段階 - 「数え方」の規則まで読む

第 2 段階は、課金単位の裏にある「数え方」の規則です。実はここが請求額を最も大きく左右します。公式の課金ドキュメントには、単価表には現れない計数規則が定義されています (2026 年 8 月時点・出典: Datadog 課金ドキュメント)。代表的なものを挙げると、まずホスト数は毎時計測した使用時間のうち上位 1% を除いた最大値 (下位 99% の high-water mark) で月末に確定します。つまり瞬間的なスパイクで台数が跳ねても、その上位 1% は請求から除外されます。一方でオートスケールが日常的に効いている環境では「よくある最大値」がそのまま請求台数になるため、平均台数で見積もると外れます。次にカスタムメトリクスは、時間ごとの重複しない系列数を月間平均した値で数えられ、送信頻度は課金に影響しません (出典: カスタムメトリクス課金ドキュメント)。さらに請求サイクルは登録日に関係なく毎月 1 日 (UTC) に始まります。ここから導ける実務上の教訓は、「単価 × 台数」の掛け算より先に「その台数・その量がどう数えられるか」を確認せよ、ということです。同じ 100 ホストでも、常時 100 台と、日中 100 台・夜間 20 台では請求の意味が変わります。また、公開料金表に単価が載っていない SKU が存在する点も知っておく価値があります。たとえばカスタムメトリクスの割当超過分は「超過 100 個ごとに契約プラン記載の単価」とだけ定義され、公開単価はありません。見積もり段階で確定できない項目がどれかを知っておくと、契約交渉で確認すべき点が明確になります。

課金事故の典型 5 型

Datadog の請求が想定を超えるとき、原因はほぼ次の 5 型に分類できます。

特に危険なのが 1 と 5 です。カスタムメトリクスは「メトリクス名とタグ値 (ホストタグ含む) の組み合わせ」ごとに 1 つと数えられます (2026 年 8 月時点・出典: カスタムメトリクス課金ドキュメント)。つまりメトリクスを 1 本追加したつもりでも、ユーザー ID のような値の種類が多いタグを付ければ、その値の数だけ課金対象の系列が生まれます。割当 (Pro でホストあたり 100 個・アカウント全体で合算) はこの膨張の前では簡単に尽きます。Synthetics は公式ページ自体が掛け算の例を示しています。ブラウザテストは 25 ステップごとに 1 実行と換算されるため、60 ステップのテスト (3 実行分) を 15 分ごとに 5 ロケーション × 2 デバイスで回すと、それだけで 1 時間に 120 実行、単純計算で月に 8 万実行を超えます。1,000 実行あたり年契約 12 ドルという単価は安く見えますが、掛け算の後では月 1,000 ドル規模になり得ます。

守りの設定 - 見えるようにしてから絞る

課金事故の予防は「使用量を見えるようにする」ことから始まります。Datadog には管理画面に使用量 (Usage) の確認ページが用意されており、請求関連ページへアクセスできるのは管理者ロールまたは課金閲覧権限を持つロールに限られます (2026 年 8 月時点・出典: Datadog 課金ドキュメント)。導入初日にやるべきことは 2 つです。第 1 に、使用量の確認を週次の運用に組み込むこと。請求書が届いてから気づくのでは 1 か月分の事故が確定しています。モニターとアラートで監視の仕組み自体は揃っているのですから、監視対象に「Datadog 自身の使用量」を含めるのが筋の良い使い方です。第 2 に、流量系プロダクトの取り込み制御を設計してから本格導入すること。ログは全量を取り込みつつインデックスを絞る二段構えが可能で、その設計手順はログ管理の解説で扱っています。トレースも同様に、取り込みのサンプリング制御と保持対象の選択で流量を調整できます (APM の解説を参照)。ここで押さえておきたい判断軸は、「絞る」のは見えるようになってからでよい、ということです。導入直後から強く絞ると、そもそも自分の環境がどれだけのテレメトリを生むのかという実測値が手に入らず、次の節で述べる見積もりの精度が上がりません。

見積もりの手順 - 最小構成の実測から伸ばす

以上を踏まえると、精度の高い見積もりは机上の計算ではなく実測から作るのが合理的です。手順は次の 5 段階に整理できます。

この手順の肝は 5 番目です。年契約の単価はオンデマンドより 0〜3 割強安くなります。ホスト系はおおむね 1 割台、ログや RUM のような流量系は 3 割前後で (たとえばログの 30 日インデックスは 2.50 ドル対 3.75 ドルと年契約が 33% 安い一方、ログ取り込みのように差が無い SKU もあります)、コミットする経済的動機は単価表で確かめられます。しかし実測の裏付けなくコミットすると、使わなかった場合のコミット割れと、超過した場合の割高精算の両方のリスクを抱えます。「確実に使う床の部分を年契約、変動する天井の部分をオンデマンド」という分け方が、料金体系の 3 建て構造を味方に付ける読み方です。構成の比較まで踏み込むなら、CloudWatch との使い分けと New Relic との比較、導入自体の判断には導入判断チェックリストが続きの読み物です。最後にもう一度だけ注意を繰り返すと、本記事の単価はすべて 2026 年 8 月時点の US リージョンの公開値であり、執筆後の価格改定を反映するものではありません。契約前には必ず公式料金ページでその時点の値を確認してください。