Datadog 契約更改前 30 日のコスト見直し - 削減チェック 10 項目
年契約の更改が 1 ヶ月後に迫った組織のために、請求を下げる作業を「30 日前 / 14 日前 / 7 日前 / 当日」の 4 区切りに並べ替えました。削減 10 項目は要点と委譲先だけを示し、数字の確認手順は既存の解説に委ねます。削る前に通すべき 1 つの問いも先に置きます。
結論 - 更改前 30 日は 4 つの区切りで回す
年契約の更改日が近づいてから請求の内訳を眺めても、削れる項目に当たりを付け、設定を変えて効果を測り、契約量の案に落とすまでには日数が要ります。本記事は更改前の 30 日を 4 つの区切りに分け、それぞれで「何を決めるか」だけを固定します。数字の確認手順は使用量とコストの確認に、料金表の読み方は料金体系の読み解きに委ね、ここでは順番と判断だけを扱います。土台の数字は 2 つで、Usage Trends 画面から CSV で落とせる組織別 / 製品別の 1 時間単位の使用量と、Usage Attribution が集計するタグ別の内訳です (2026 年 9 月時点・出典: Usage Details)。
| 時期 | 決めること | 手に持つ材料 | 出口 | この区切りを飛ばすと |
|---|---|---|---|---|
| 30 日前 | 契約量と実績の差を出し、使っていない製品を洗い出す | 過去 12 ヶ月分の使用量 CSV と契約中の製品一覧 | 棚卸し表 1 枚 | 削る対象を印象で選ぶことになる |
| 14 日前 | 削れる SKU に当たりを付け、設定変更を本番の一部で試す | ログ / メトリクス / APM / RUM / Synthetics の内訳 | 削減候補と見込み量 | 見込み量に実績の裏付けが無い |
| 7 日前 | SKU ごとの契約量の案を書く | 設定変更後 1 週間の実績と Usage Attribution の内訳 | 契約量の再設定案 | 当日に数字を作る羽目になる |
| 当日 | 更改条件の文面と再設定案を突き合わせる | 見積書と再設定案 | 合意した契約量 | 単位や割当の食い違いが翌月の請求で判明する |
4 つに区切る理由は 1 つで、削減の設定変更は効果が実績に現れるまで日数を要するからです。ログの除外を 14 日前に入れれば、7 日前には 1 週間分の実績で削減量を裏付けられます。7 日前に初めて設定を触ると、更改日に持ち込めるのは見込みだけになります。
削る前に「跳ねた原因」を 1 つ言えるか
見直しの最初に置くのは削減項目の一覧ではなく、1 つの問いです。過去 12 ヶ月で請求が伸びた月について、伸びた費目とその原因を 1 つ言えるでしょうか。言えないまま契約量を切り下げると、原因が残ったまま超過分だけがオンデマンド単価で請求され、更改の翌月から前より高くなる筋道が生まれます。インフラ監視 Pro のホスト単価は年契約とオンデマンドで異なり、契約量を外れた分にはこの差がそのまま掛かります (出典: Datadog Pricing)。原因の候補は多くありません。ホスト数の増減、ログのインデックス量、カスタムメトリクスのカーディナリティ、APM の索引率、RUM のセッション数、Synthetics の実行回数のどれかに帰着します。このゲートを通ってから次の区切りに進みます。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。
30 日前は実績の突合と棚卸しから始める
最初の区切りでやることは、契約量と実績の突合と、製品の棚卸しの 2 つです。材料は Usage Trends の CSV で、組織ごとに製品別の使用量が 1 時間単位で並び、グラフの表示間隔は日 / 週 / 月 / 年から選べます (2026 年 9 月時点・出典: Usage Details)。契約量を下回り続けた SKU と上回り続けた SKU を色分けしておくと、次の区切りで触る対象が絞れます。棚卸しでは、12 ヶ月で一度も画面を開いていない製品と、同じマシンが 2 つの名前で数えられているホストを探します。
- 項目 1: 契約量と 12 ヶ月実績の突合。SKU ごとに「契約量 / 月別の実績 / 超過した月の数」を 1 行にまとめる。数字の取り方は使用量とコストの確認へ
- 項目 2: 使っていない製品と重複ホストの整理。ログインの無い製品は更改時に外す候補に入れ、複数の連携経路で二重に数えられたホストは名寄せする
- 項目 3: コンテナと Lambda の数え方の再確認。コンテナはホストあたり Pro 5 台分 / Enterprise 10 台分が割当として含まれ、超えた分だけ別 SKU になる。Lambda はアクティブ関数数で数える別 SKU (2026 年 8 月時点・出典: Datadog Pricing)。コンテナ監視の課金節を参照
3 項目のうち、更改の交渉に最も効くのは項目 1 の表です。「上回り続けた月が 12 ヶ月中 9 ヶ月」のような事実が 1 行あるだけで、契約量を上げる議論と下げる議論のどちらを先にすべきかが決まります。
14 日前に当たりを付ける 5 つの SKU
2 つ目の区切りでは、流量に比例して請求が動く 5 つの SKU に当たりを付け、設定変更を本番の一部で試します。ここで 2 週間の余裕を取るのは、見込み量を実績で裏付けるためです。使用量メトリクスは近い時間で見積もった値であり、請求対象の使用量とは平均で 10〜20% の差があると公式ドキュメントが明記しています (2026 年 9 月時点・出典: Estimated Usage Metrics)。見込みだけで契約量を切ると、この幅の分だけ外れます。
- 項目 4: ログのインデックス除外と Flex 移行の判断。検索に使っていないログインデックスを洗い、除外フィルターで落とすか保持の安い層へ移すかを決める。2 段課金の読み方はログ料金の仕組みへ
- 項目 5: カスタムメトリクスの高カーディナリティ整理。割当はホストあたり Pro 100 個 / Enterprise 200 個で、超えた分が別 SKU になる (2026 年 8 月時点・出典: Datadog Pricing)。タグの組み合わせを増やしている送信元を止めるか、タグを減らす
- 項目 6: APM の取り込み率と索引率。取り込みコントロールで取り込み量を、保持フィルターで索引する割合を見直す
- 項目 7: RUM のサンプリング。全セッションを取る必要がある画面と、傾向だけで足りる画面を分ける
- 項目 8: Synthetics の頻度とロケーション。実行間隔とロケーション数の掛け算を、テストの重要度で 3 段階に分け直す
5 項目を同時に触らず、請求への効き目が大きい順に 1 つずつ変えて実績を取ると、7 日前に「何がどれだけ効いたか」を分けて言えます。順番の目安は、30 日前の突合で超過した月の数が多かった SKU からです。超過が常態の SKU ほど、設定変更 1 つで契約量の案そのものが変わります。
7 日前、契約量の再設定案はこう書く
3 つ目の区切りでは、SKU ごとの契約量を数字にします。案の骨格は「12 ヶ月の実績から、14 日前の設定変更で減る見込み分を引いた値」で、超過が常態になっている SKU と、ほとんど使っていない SKU を別の扱いにします。年契約とオンデマンドの単価差の読み方と、契約量を超えた分の見え方は年契約とオンデマンドの違いで扱っているので、ここでは案の書式と交渉材料に絞ります。
- 項目 9: オンデマンド超過が常態の SKU を年契約へ。12 ヶ月中の超過月が半数を超える SKU は、超過分の中央値を契約量に足す案を書く
- 項目 10: 交渉材料は Usage Attribution の内訳。タグ別に使用量を分解するこの機能 (2026 年 9 月時点・出典: Usage Attribution) の出力を「どのチームのどの環境が何割か」の 1 枚にして持ち込む。設定と読み方は使用量とコストの確認へ
- 案の書式: SKU / 12 ヶ月実績の中央値と最大値 / 設定変更後 1 週間の実績 / 提案する契約量 / 根拠の 1 行、の 5 列
内訳を持ち込む意味は 2 つあります。伸びた使用量が特定の事業の拡大によるものだと示せれば、契約量を上げる案は費用増ではなく事業計画の裏付けとして通ります。逆に伸びの主因が 1 つのチームの設定に帰着するなら、その項目は契約量ではなく設定変更で受けるべきで、案から外せます。内訳が無いまま合計だけで交渉すると、この 2 つの区別が付かず、上げるか下げるかの二択に追い込まれます。
当日は更改条件の文面と案を突き合わせる
最後の区切りは更改日そのものです。ここでの仕事は交渉ではなく照合で、見積書に並ぶ SKU と単価と契約量を、7 日前に書いた再設定案と 1 行ずつ突き合わせます。見るべき点は 4 つです。案に無い SKU が見積書に残っていないか、契約量の単位 (ホスト / 月、100 万イベント / 月など) が案と同じか、契約量を超えた分に適用される単価が年契約単価かオンデマンド単価か、そして割当 (コンテナやカスタムメトリクスのホストあたりの含み分) が契約量の内側か外側か、です。
| 照合点 | 見比べる場所 | 食い違いの例 | その場の対処 |
|---|---|---|---|
| SKU の有無 | 見積書の行と再設定案の行 | 30 日前に外す候補に入れた製品が見積書に残っている | 行を指して削除を依頼し、削除後の合計を再提示してもらう |
| 契約量の単位 | 見積書の単位表記と案の 5 列目 | 案は「100 万イベント / 月」、見積書は「GB / 月」 | 単位を揃えた案を翌日までに書き直す (その場で換算しない) |
| 超過分の単価 | 見積書の脚注と契約条件 | 超過分がオンデマンド単価で、案の見込みは年契約単価で計算していた | 超過が常態の SKU だけ契約量を上げる案を再提示する |
| 割当の位置 | ホスト系 SKU の脚注 | コンテナの割当がホスト数ではなく別行で数えられている | 割当の含み分を確認し、別行の量を差し引いた案に直す |
単位と割当の読み方は料金体系の読み解きの「数え方の規則」を参照してください。照合で食い違いが出たら、その場で契約量を動かさず、食い違いの行だけを持ち帰って翌日までに詰めます。当日に新しい数字を作らないことが、この 30 日の設計の要点です。
やってはいけない削減は「見えなくする」型
削減の議論で必ず出るのが、監視そのものを止めて請求を下げる案です。Agent をアンインストールする、モニターを消してアラート疲れごと無くす、ログの保持を極端に短くして調査ができない状態にする、の 3 つが典型で、いずれも請求は下がりますが、下がった額と引き換えに障害の検知と調査の手段を失います。更改前の見直しで削るのは「見ているが使っていない量」であり、「見る手段」ではありません。
| 出てくる案 | 請求は下がるが失うもの | 代わりに触る項目 |
|---|---|---|
| 使用頻度の低いホストから Agent を外す | そのホストで起きた障害の一次情報。復旧後に原因を追う手段が無くなる | 項目 2 の重複ホストの名寄せと、項目 3 のコンテナ割当の確認 |
| 鳴りすぎるモニターをまとめて消す | 本当に人を呼ぶべき事象の通知。静かになった理由が「直った」か「見ていない」か区別できない | モニターの整理は請求に効かないため本記事の対象外。しきい値の見直しはモニターの解説へ |
| ログの保持を最短にして全量を索引し続ける | 数日前の事象を調べる手段。保持を縮めると単価は下がるが、索引するイベント数は減らず、調べられる期間だけが失われる | 項目 4 の除外フィルターと Flex 移行 (索引する量そのものを減らす) |
項目 4 から 8 の設定変更は、いずれも見える範囲を保ちながら数える量だけを減らす設計になっています。見えるようにしてから絞る、という順序の考え方は料金体系の読み解きの「守りの設定」の節が扱っているので、ここでは繰り返しません。更改が済んだら、30 日後に同じ Usage Trends の CSV を開いて、案に書いた見込み量と実績の差を 1 行ずつ確かめます。その差が次回の更改で最初に見る数字になります。