Datadog の年契約とオンデマンド - 3 つの単価列の読み方

結論 - 3 つの列は「約束の長さ」と「約束の外」を表す

Datadog の料金表で 1 つの SKU に 3 つの値段が並ぶのは、同じ使用量でも「どれだけ先まで約束するか」で単価が変わるためです。年契約は 12 ヶ月分の使用量を約束した場合の単価、月契約は月単位で量を約束する場合の単価、オンデマンドは約束していない分、つまり契約量と割当を超えた使用に適用される単価です。

料金表の 3 列を「安い / 普通 / 高い」と読むと、契約形態の判断を誤ります。正しくは「約束した量までは契約単価、はみ出た量はオンデマンド単価」という 2 段の仕組みで、はみ出す量を減らす設計が本記事の主題です。SKU の積み上げ構造そのものは料金体系の読み解き方に委ねます。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。

差の付き方は SKU の型で変わる

3 列の差は全 SKU で一律ではありません。公式料金ページの 3 列を SKU ごとに見比べると、差の付き方は課金単位の型で 3 つに分かれます。

表から読み取れる型は 3 つです。ホスト単位の SKU (インフラ監視、APM、Database Monitoring) は月契約とオンデマンドが同額で、年契約との差はこの型が最も小さく収まります。ログのインデックス、スパンの索引、Synthetics、RUM のような使用量に比例する SKU は、月契約が年契約より高く、オンデマンドはさらにその上に乗るため、3 列の開きが最も大きい型です。ログ Ingest のように 3 列が同額の SKU もあり、この SKU では契約形態を悩む意味がありません。差の大きさそのものは改定され得るため、契約前に公式料金ページで 3 列を自分の目で確かめてください。

契約量を超えた分は月の途中で紫に見える

契約量を超えた使用は、使用量画面では「オンデマンド」として区別されます (この表示は 2026 年 9 月時点でベータ機能で、利用には担当窓口への申請が要ると公式ドキュメントに記載)。公式ドキュメントによると、使用量の推移グラフには契約分と割当分を示す青い表示と、オンデマンド分を示す紫の表示が付き、破線の Committed 線が製品ごとの契約量を示します (2026 年 9 月時点・出典: Usage Details)。表示を申請していれば、超過は請求書が来て初めて分かるものではなく、月の途中でグラフ上の紫の部分として見えます。契約に入っていない製品を初めて使ったときの通知 (同じくベータ機能で要申請) も用意されており、有効化すると使用開始から約 48 時間後にメールが届きます。意図しない SKU の点灯を早く知る手段として、契約直後に有効化しておく価値があります。使用量画面の具体的な見方と、跳ねやすい費目の確認順序は料金の確認方法に委ねます。

ホスト単位の製品には 2 つの課金プランがある

インフラ監視、APM、Database Monitoring のようなホスト単位の製品には、2 種類の課金プランがあります (2026 年 9 月時点・出典: Pricing (Billing))。High watermark plan (HWMP) は毎時のホスト数を記録し、上位 1% を除いた最大値で月額を決める方式で、月を通して使用量が安定した環境向けと説明があります。Hybrid monthly/hourly plan (MHP) は月間の最低量を約束したうえで、それを超えたホスト時間を時間単価で課金する方式で、オートスケールや短命なワークロードのような増減の激しい環境向けです。「超えた分を月単位でなく時間単位で払う」形の契約と読めます。請求サイクルは契約日にかかわらず毎月 1 日 (UTC) に始まり、初月は日割りです (出典: Billing)。ホストの数え方はそちらに委ね、「台数が動く環境ほど、年契約の量を底に置く判断が重要になる」という点だけを押さえます。

割当は契約量の外側にもう一枚ある

契約量とオンデマンドの間には、割当 (allotment) という層があります。使用量画面で契約分と親製品からの割当分が同じ青い表示にまとめられているのはこのためで、APM ホストには Ingested Spans と Indexed Spans の月間割当が、インフラ監視のホストにはコンテナとカスタムメトリクスの割当が、ホスト数に比例して付きます (2026 年 9 月時点・出典: Usage Details)。オンデマンド単価が適用されるのは、契約量と割当の両方を超えた分だけです。この層があるため、使用量に比例する SKU の見積は契約かオンデマンドかの二択ではなく、「親製品の割当でどこまで吸収できるか」を先に数える手順になります。APM の割当が全ホストで合算される規則と計算例は APM 料金の考え方に、ログのインデックスと Flex Logs の層の選び方はログ料金の 3 層にあります。割当を数えずに契約量を決めると、余るかはみ出すかのどちらかになります。

見積は Free の実測から年契約へ、3 段で進める

契約形態の選び方だけを取り出すと、順序は次の 3 段になります。

実測の段で取る数字は、後で契約量の単位になるものに限ります。ホスト数、ログの GB / 日、Indexed Spans の月間数、セッション数の 4 つを押さえれば、型の表の大半の SKU に対応できます。2 段目を飛ばしたくなる理由は「月契約は年契約より高い」からですが、型の表を思い出すと判断が変わります。ホスト単位の SKU では月契約とオンデマンドが同額なので、月契約で様子を見る期間に「約束しなかった罰」は付きません。使用量に比例する SKU では、月契約はオンデマンドより安いので、実測期間でも月契約で量を約束しておく方が安く済みます。年契約は約束した量を 12 ヶ月使い続ける前提の割引なので、実測より先に結ばないこと、結ぶときは山ではなく底の量にすることの 2 点が、この順序の要点です。

年契約に向く SKU、向かない SKU

「年契約にすれば一律に安くなる」という単純化はホスト単位の SKU にだけ当てはまるので、差の型と割当の両方から向く SKU と向かない SKU を分けます。

使い方は、請求書の上位 3 費目をどの型に当てはめるかを見ることです。ホスト単位の型で考えると、年契約のホスト単価を p、オンデマンドの単価を q (q > p) として、Pro のホストが多い月に 20 台、少ない月に 15 台なら、15 台を年契約、5 台をオンデマンドで持つ月額は 15 × p + 5 × q です。20 台全てを月契約で持つ 20 × q (ホスト単位では月契約 = オンデマンド) より安く、20 台全てを年契約にした 20 × p との差は 5 × (q − p) で、その代わり 5 台を使わない月には払わずに済みます。ホスト単位が上位なら、年契約の判断は台数の底の見極めに集約されます。使用量比例が上位なら、年契約の前に割当と取り込み制御でオンデマンドに出る量を絞る方が、契約形態の選択より請求に効きます。3 列の値段は「安い順に並んだ選択肢」ではなく、自分の使用量の形に合わせて組み合わせる部品です。