Datadogの料金体系と費用が膨らむ課金単位｜抑制策を実装目線で整理

Datadogの見積もりは、ホスト単価に台数を掛けた数字で収まりません。請求書の内訳を見ると、契約時に想定していなかったログのインデックス、カスタムメトリクス、トレースやセッションの従量分が積み上がっている、という相談が続く状況です。この記事では2026年8月時点の公式価格ページとドキュメントを実測し、料金がどの単位で発生するのか、どこで費用が膨らむのか、そして膨らむ前に入れておく設定と設計を、実装する側の手順として整理します。無料プランとトライアルで測っておくべき数値、採用を見送ってよい条件まで踏み込みます。

まとめ：料金が膨らむ三つの課金単位と先に入れる抑制策

結論を先に置きます。Datadogの料金はホスト単位の固定費とモジュール単位の従量費の二層で決まり、見積もりが外れるのは後者です。膨張の発生源はほぼ三つに絞られます。ログの標準インデックス、カスタムメトリクス、そしてホスト数と連動しないAPMのスパンとRUMのセッションでした。

先に入れる抑制策も三つ対応させれば足ります。ログは取り込みとインデックスを切り分けて除外フィルタを敷き、メトリクスはタグの粒度を決めてMetrics without Limitsで絞り、トレースとSyntheticsはサンプリング率と実行頻度を契約前に決めておく。この三点を設計段階で決めておけば、請求が跳ねてから慌てて設定を戻す作業を避けられます。

いずれも年間契約を前提にした2026年8月時点の公表値です。オンデマンド契約に切り替えると単価が二割から五割ほど上がるため、規模が読めない立ち上げ期ほど契約形態の差が効いてきます。

Datadogの料金がホスト課金とモジュール別従量の二層で決まる構造

製品としての全体像はDatadogとは何かの側で整理していますので、ここでは課金の観点だけを取り出します。Datadogの契約は、まずInfrastructure Monitoringのプランとホスト数を決め、そこにAPM・Log Management・RUM・Syntheticsといったモジュールを積む形をとります。前者は台数が読めれば固定費として計算でき、後者はテレメトリの量に比例して動きました。

見積もりの精度が落ちるのは、後者の量を契約前に測っていないケースです。ホスト数は資産管理台帳から数えられますが、1日に出るログのGB数やカスタムメトリクスの系列数は、実際に入れてみるまで誰も把握していません。ここが料金の話を難しくしている本体だと考えてください。

インフラ監視のホスト単価は年間契約とオンデマンドで差が開く構造

2026年8月時点の公式価格ページでは、Infrastructure MonitoringのProプランが1ホストあたり月15米ドル系（年間契約）、同じプランをオンデマンドで使うと18米ドル系と示されています。Enterpriseプランは年間契約で23米ドル系、オンデマンドで27米ドル系でした。APMを併用する場合はインフラと合わせて31米ドル系、単体では36米ドル系という水準です。

年間契約はホスト数のコミットを伴い、コミットを超えた分はオンデマンド単価で精算されます。台数が季節変動する構成では、平常時の台数でコミットしてピーク分を超過扱いにするか、ピーク込みでコミットして余らせるかの判断が発生しました。前者を選ぶなら、超過単価が二割高いことを織り込んだうえで年間の合計額を比べてください。

課金対象になるホスト数の数え方と上位分位で切り捨てられる範囲

請求で使われるホスト数は、月末時点の台数でも月間の最大値でもありません。1時間ごとに観測した同時稼働ホスト数を並べ、上位の一部を切り捨てた分位値を月間の課金値とする方式が採られています。オートスケールで一時的に台数が跳ねても、その時間帯が全体のごく一部であれば請求には乗りにくい、という挙動です。

この仕様は、デプロイ時のBlue/Green構成やバッチ実行時のスポットインスタンスを過度に恐れなくてよいことを意味します。逆に、常時起動している検証環境のホストは分位値の下に隠れず、そのまま課金対象になりました。コンテナ環境ではホストではなくタスクやコンテナの単位で数える体系が別に用意されているため、Fargate中心の構成では課金単位そのものを確認してから台数見積もりに入ってください。

費用が膨らむ課金単位はログとカスタムメトリクスとAPM系に集中する

ここからが本題です。想定を超える請求の原因を分解していくと、ほぼ次の三つに収束します。それぞれ増え方の性質が違うため、抑制の打ち手も別々に用意する必要がありました。

ログは取り込みとインデックスの二段課金で後段が費用を押し上げる

Log Managementの料金は一段ではありません。まず取り込んだ量に対して1GBあたり0.10米ドル系が発生し、そのうち検索対象としてインデックスしたイベントに対して、100万件あたり1.70米ドル系（年間契約・保持15日相当）が別に発生します。オンデマンドでは後者が2.55米ドル系まで上がりました。

単価だけ見ると取り込みが安く感じられますが、実務で効くのは後段です。100GBのログを取り込んだ場合の取り込み費用は10米ドル系にとどまる一方、そのログが1件1KBだとすれば1億件のイベントとなり、全件をインデックスすれば170米ドル系に達します。桁が一つ変わる計算でした。

そして既定の設定では、取り込んだログはインデックス対象になります。アプリケーションのDEBUGログやロードバランサのアクセスログをそのまま流し込むと、検索することのないイベントに対して後段の単価を払い続ける状態になりました。ログ経由の請求超過は、この既定値をそのままにしたことが原因である場合が大半です。

カスタムメトリクスはタグの組み合わせ数だけ課金対象が増えていく

カスタムメトリクスの数え方は直感に反します。公式ドキュメントでは、メトリクス名とタグ値の組み合わせ（ホストタグを含む）で一意に識別される単位を1カスタムメトリクスと数える、と定義されていました。つまりorder.countという1本のメトリクスにregionタグ5種類とstatusタグ4種類を付ければ、それだけで20系列になります。

ここにuser_idやrequest_idのような値域の広いタグを付けると、系列数は制御不能な水準まで跳ね上がりました。無料枠はProプランでホストあたり100、Enterpriseプランでホストあたり200が割り当てられ、この枠はインフラ全体で合算されるため個々のホストで超えても即座に課金されるわけではありません。ただし合算値を超えた分は、Metrics without Limitsを設定している場合にインデックス超過分として100メトリクスあたり0.10米ドル系が加算されます。

タグ追加が必ず系列数を増やすとは限らない点も押さえておいてください。ドキュメントでは最も詳細なタグの粒度で数えるとされており、都市タグで既に分かれているメトリクスに州タグを足しても数が増えない例が挙げられています。タグの順序を入れ替えただけの場合も同一メトリクス扱いです。

APMとRUMはホスト数と切り離された単位で費用が積み上がる

APMのホスト単価には一定量のスパンが含まれますが、取り込んだスパンとインデックスしたスパンには別枠の従量が設定されています。マイクロサービス構成では1リクエストが十数のスパンを生むため、リクエスト数の増加がホスト数の増加と無関係に費用を押し上げました。

RUMはさらにホスト数と無関係です。課金はセッション単位で、公式ドキュメントには1,000セッションごとに課金する旨が明記されています。セッションの数え方には仕様があり、15分の無操作でセッションが終了して次の操作が新しいセッションになること、1セッションの継続時間は4時間で区切られて以降は新しいセッションが自動生成されることが示されていました。

この仕様は、業務システムのように担当者が1日中画面を開いたままにする用途で効いてきます。1人の利用者が1日に複数セッションを生む前提で見積もらないと、実測値が想定の数倍になりました。ネイティブアプリ内にWebViewを持つ構成では、モバイルセッション1つのみが課金対象として扱われる旨も記載されています。Session Replayを有効にするとプラン自体が変わるため、録画が必要な画面を絞る判断を先に済ませてください。

課金単位ごとに費用を抑える設定と設計の手順を実装目線で整理する

増加要因が課金単位ごとに違う以上、抑制策も単位ごとに用意します。ここが本記事の中心です。導入直後にまとめて入れておくべき設定を、実装の順に並べます。

ログは除外フィルタとFlex Storageで課金段を切り分ける

最初にIndexesの除外フィルタを敷きます。status:debugやstatus:infoのうち検索対象にしないものをインデックスから外す、健全性チェックのアクセスログを除外する、といった単位で構いません。除外しても取り込み自体は行われるため、Live Tailでの流し見やメトリクス生成には使えます。捨てているのは後段の検索インデックスだけです。

長期保持が必要なログには、Flex Storageという別の保持層が用意されています。100万件あたり0.05米ドル系（年間契約）で、標準インデックスの1.70米ドル系と比べて桁が違いました。監査要件で1年分を残す必要があるログはこちらへ寄せ、障害調査で高速検索したい直近分だけを標準インデックスに置く、という二段構えが基本形になります。

もう一手として、Log to Metricsで件数やレイテンシの分布をメトリクス化しておくと、ログ本体をインデックスしなくても傾向監視は続けられます。ただしこの変換で生まれるのはカスタムメトリクスであり、タグを付け過ぎると次の項目の課金へ移し替えただけになる点に注意してください。

メトリクスはタグ設計とMetrics without Limitsで絞り込む

カスタムメトリクスの抑制は、送る前と送った後の二段で考えます。送る前は命名とタグの規約です。値域が無限に広がるID系の値をタグにしない、環境・サービス・リージョンなど分析軸として実際に使うものだけをタグにする、この二点を規約として明文化し、レビューで機械的に弾く体制にしてください。

送った後の絞り込みがMetrics without Limitsです。取り込んだ系列のうち、実際にダッシュボードやモニターで参照されているタグの組み合わせだけをインデックス対象として残せます。Datadog側に参照状況の分析画面があるため、稼働から1か月ほど経った時点で未参照の系列を洗い出し、インデックス対象から外す作業を運用サイクルに組み込むとよいでしょう。

トレースのサンプリング率とSyntheticsの実行頻度を決め直す

APMはヘッドベースのサンプリング率を明示的に設定します。全リクエストを対象にする必要があるのは、決済のような取りこぼしが許されない経路だけです。参照系のエンドポイントは低い比率で足ります。エラーと低速リクエストを優先的に残すテールベースサンプリングを挟む構成も選べますが、その場合はCollectorを別途置く前提になりました。

Syntheticsは実行頻度とロケーション数の掛け算で費用が決まります。5分間隔で10ロケーションから叩く設定は、1分間隔で1ロケーションの設定の倍の実行数になりました。監視対象の重要度に応じて、頻度を落とす・ロケーションを絞る・ブラウザテストをAPIテストへ置き換えるという順で削っていくと、検知力を落とさずに実行数を下げられます。

タグ設計と予算の監視をコード管理に載せて費用の増加を検知する

ここまでの設定は、画面上で個別に入れると誰がいつ変えたか追えなくなります。除外フィルタ、モニター、ダッシュボード、タグ規約はコードで管理してください。具体的な手順はTerraformでDatadogを管理する方法にまとめてあります。除外フィルタをリソースとして定義しておけば、誰かが調査のために一時解除したまま戻し忘れる事故を検知できます。

あわせて、Datadog自身の使用量メトリクスに対するモニターを置きます。日次の取り込みGB数、インデックス済みイベント数、カスタムメトリクス系列数に閾値を設定し、平常時の1.5倍を超えたら通知する程度で十分です。請求が確定してから気づくのと、増加した当日に気づくのとでは、対処にかかる費用が一桁変わりました。

無料プランとトライアルで確認できる範囲と本番前に潰すべき前提

検証の入口として無料枠が用意されています。ただし、無料プランで測れるものとトライアルで測るべきものは別物でした。

無料プランの上限は五ホストで保持期間が一日に制限されている点

公式価格ページに記載された無料プランの条件は、最大5ホストまで、メトリクスの保持は1日、そしてコアの収集と可視化の機能に限る、というものです。エージェントを入れてメトリクスが上がってくるところまでは確認できますが、保持1日では週次の傾向も見えず、APMやログの本格的な検証には届きません。

したがって無料プランの用途は、エージェントの導入手順とインテグレーションの疎通確認に限定するのが現実的です。料金の妥当性を判断する材料は、有料機能が開放されるトライアル期間に集める必要がありました。

トライアル期間に測るべき数値はログ量とカスタムメトリクスの数

トライアルで測るべきは機能の使い勝手ではなく、量です。1日あたりのログ取り込みGB数、そのうちインデックス対象となるイベント件数、カスタムメトリクスの系列数、APMのスパン数、そしてRUMを使うならセッション数。この5項目をUsage画面から日次で記録してください。

記録した実測値に、本番の環境数と想定トラフィックの倍率を掛ければ、見積もりの精度は大きく上がります。トライアル環境は本番より小さいことが多いため、単純な台数比ではなくトラフィック比で外挿するほうが実態に近づきました。この作業を挟まずにホスト単価だけで稟議を通すと、初回の請求で説明に窮することになります。

Datadogを採用してよい条件と別の構成に振り替える判断の基準

ここまで費用の話を続けてきましたが、Datadogが高いか安いかは単価では決まりません。判断を言い切ります。

Datadogの費用が見合う条件は運用人数と対象範囲で決まる

採用してよいのは次の条件が揃った場合です。第一に、監視対象が複数のクラウドやオンプレミスにまたがり、単一クラウドの標準監視では横断できないこと。第二に、インフラ・APM・ログ・フロントエンドのうち三つ以上を同じ画面で突き合わせる運用を実際に行うこと。第三に、監視基盤の構築と維持に人を張り付ける余力がないこと。

三つ目が効くのはOSSを自前で組む選択肢との比較です。PrometheusとGrafanaとLokiを組めばライセンス費は消えますが、可用性の確保とバージョン追随に人月が乗ります。年間のライセンス費が人件費1人分を下回るなら、統合SaaSを選ぶ判断は数字の上で通ります。逆にホスト数が二桁前半で単一クラウドに閉じているなら、クラウド標準の監視サービスで足りる公算が高いでしょう。ツールを横断して比べる段階の判断軸はオブザーバビリティツール比較に整理してあります。

見送ってよい場面はクラウド標準の監視だけで足りる小規模の構成

見送ってよい場面も明示します。ホスト数が10台前後で単一のクラウドに閉じ、障害対応が担当者1名で完結している構成では、Datadogの機能の大半が使われないまま費用だけが発生しました。この規模ではCloudWatchやAzure Monitorの標準機能で足り、必要になった時点で移行すれば済みます。

もう一つの見送り条件は、ログの保持要件が長期かつ大量で、検索頻度が低い場合です。年単位で数十TBを残す必要があるなら、オブジェクトストレージへ退避して必要時に復元する構成のほうが費用は下がります。全部をDatadogに寄せる前提を疑ってください。

採用後に費用が読めない、あるいは既に膨らんだ請求を戻したい場合は、除外フィルタとタグ規約の設計から手を入れる必要があります。監視基盤の設計と運用の引き継ぎまで含めて外部に任せる選択肢を検討するなら、システム保守運用・内製化支援で対応範囲を確認いただけます。

よくある質問

Datadogの料金は日本円建てで契約できますか？

公式の価格ページは米ドル建てで表示されており、日本語版のページでも通貨と請求形態によって表示額が変わります。国内の販売代理店経由では円建ての契約形態が用意されている場合があるため、為替変動を予算に織り込みたい場合は代理店の見積もりと直契約の両方を取り寄せて比べてください。本記事の単価はいずれも2026年8月時点の米ドル建て公表値です。

ログの費用だけを下げたい場合はどこから手を付けますか？

Indexesの除外フィルタが最初です。取り込み単価は1GBあたり0.10米ドル系と低く、費用の大半はインデックス側で発生しています。まずUsage画面でインデックス済みイベント数の内訳をサービス別・ステータス別に確認し、件数の多い順に検索対象から外せるものを外してください。長期保持だけが目的のログはFlex Storageへ移すと、標準インデックスに対して大幅に単価が下がります。

カスタムメトリクスの数が急に増えたときは何を見ますか？

Metric Summary画面で系列数の多いメトリクス名を特定し、そのメトリクスに付いているタグのカーディナリティを確認します。値域の広いIDがタグに混入している場合がほとんどでした。原因のタグを特定したら送信側のコードを修正し、既に取り込まれた分はMetrics without Limitsでインデックス対象から外して当月分の増加を止めます。

RUMの料金はページビュー数で決まりますか？

セッション数で決まります。公式ドキュメントでは1,000セッション単位で課金する旨が示されており、ページビューが多くても同一セッション内であればセッション数は増えません。ただし15分の無操作でセッションが終了し、継続時間が4時間を超えると新しいセッションが自動生成されます。長時間の利用が前提の業務システムでは、利用者数ではなくセッション発生数で見積もってください。

無料トライアルの間にどこまで実運用に近い検証ができますか？

有料機能が開放されるため、APM・ログ・RUMの疎通と画面の使い勝手は一通り確認できます。一方で本番相当のトラフィックを流さない限り、費用の見積もりに使える量のデータは得られません。トライアル期間には機能の可否判断ではなく、1日あたりのログGB数・インデックス件数・カスタムメトリクス系列数・スパン数・セッション数という5項目の実測に集中し、本番のトラフィック比で外挿することをおすすめします。

関連記事

• Datadogとは何か：機能構成と導入の背景を製品概要の粒度で確認できます。料金の前提となる製品範囲の理解に使ってください。
• オブザーバビリティツール比較：他ツールを含めた選定軸と課金モデルの違いを横断で整理しています。他社製品との比較検討に進む段階の資料です。
• TerraformでDatadogを管理する方法：除外フィルタやモニターをコードで統制する具体的な書き方をまとめています。
• オブザーバビリティ（可観測性）とは：監視との違いと3本柱の考え方から入りたい場合の前提記事です。
• Bits AI SREの基本概要：Datadog製品群のうち運用自動化側の位置付けを把握できます。