Datadog と Splunk の比較 - ホスト単価と課金構造はどこで違うか

比較対象を Splunk Observability Cloud に絞る理由

Splunk と Datadog の比較が噛み合わない最大の理由は、「Splunk」が 2 つの製品群を指すことです。1 つは Splunk Enterprise と Splunk Cloud Platform からなるデータプラットフォームで、ログ検索と SIEM を主戦場とし、オンプレミスやデータセンターを含むハイブリッド環境で使える製品として案内されています (2026 年 9 月時点・出典: Splunk Enterprise)。もう 1 つが Splunk Observability Cloud で、インフラ監視、APM、RUM、外形監視を束ねた SaaS です。前者の料金は取り込み量や検索の計算資源に基づく方式 (Workload Pricing) で、料金ページに単価表はなく「Contact Us」で見積もる形になっています (出典: Splunk Pricing FAQs)。公開されていない単価を推測で比べることはできないので、本記事はログ製品の金額を一切扱いません。比べるのは、料金ページにホスト単価が明記されている Splunk Observability Cloud と、同じくホスト単価を公開している Datadog です。結論を先に置くと、インフラ + APM の範囲では、APM が要るホストだけに SKU を足す Datadog の積み上げ方が、全ホストを APM 込みの段に上げるパッケージ型より請求を抑えやすい構造を持つ一方、すでに Splunk Platform でログを集めている組織では、Observability Cloud がそのログ資産に接続できる点で Splunk 側に実利があります。どちらが得かは「ログの置き場所がどこか」で決まる、というのが本記事の骨子です。

課金構造の差 - 段階パッケージと SKU の積み上げ

Splunk Observability Cloud の料金ページは、ホスト単価の段階パッケージで組まれています。2026 年 9 月時点で Infrastructure、App & Infrastructure、End-to-End の 3 段があり、いずれも 1 ホストあたりの月額 (年契約・Starts at 表記) で示されます。Infrastructure にはインフラ監視のほか Log Observer Connect、Network Explorer、Synthetic Uptime Monitoring、Incident Intelligence が含まれ、App & Infrastructure ではそこに APM (Always On Profiling 込み) が加わります。End-to-End は Database Monitoring までを含む最上位です (出典: Splunk Observability Cloud Pricing)。同じページには単品の価格も並び、APM 単独もホストあたりの月額で示されています。Datadog は逆に SKU の積み上げです。2026 年 8 月時点でインフラ監視は Pro と Enterprise の 2 段のホスト月額、APM を併用するとホストあたりの APM 単価 (Continuous Profiler 込みの APM Enterprise は別単価) が加算され、ログやネットワーク監視は別 SKU として必要な分だけ足します (出典: Datadog Pricing)。

構造の違いは請求書の形に現れます。Splunk はホスト数 × パッケージ単価で月額がほぼ決まり、料金ページも「ピーク使用量に基づく想定外の超過が無い予測可能な価格」を掲げています。Datadog はホスト数 × 基本単価に、ログやスパンの流量に比例する部分が乗るので、見積もりには流量の実測が要ります。予測しやすさは Splunk、要らないものを買わない自由度は Datadog、という配分です。

並べて比べられる費目と、単位が違って換算できない費目

公開単価で 1 対 1 に並ぶのはホスト単位の費目だけです。下の表はホスト単位で対応づけられる費目の対応表で、Datadog は組み合わせて同等の範囲にした構成を示します。実額は各社の料金ページで、同じ単位 (1 ホスト / 月 / 年契約) に揃えて埋めてください。

一方、単位系が違うため換算できない費目もはっきりさせておきます。ログは Splunk 側が Platform のライセンス (単価非公開) に依存し、Datadog 側は取り込み GB とインデックス済みイベント数 (保持日数別の単価) の 2 軸なので、数字を並べる土台がありません。外形監視は Splunk が uptime リクエストの回数、Datadog が API テストの実行回数と、どちらも回数課金ですが uptime リクエストと API テストは検証内容が異なるため同列には置けません。Database Monitoring は Splunk では End-to-End パッケージに含まれ、Datadog ではデータベースホストあたり月額の別 SKU で、含む / 含まないの構造が違います。本記事は課金の仕組みを解説するものです。具体的な単価や料金は各社の料金ページで確認してください。

Splunk が勝るのはログ資産、全量トレース、価格の予測しやすさ

Splunk 側に明確な実利がある点を 3 つ挙げます。第一に既存のログ資産です。Splunk Platform を SIEM やログ検索の基盤として運用している組織では、Observability Cloud の Log Observer Connect がその Splunk 上のログに接続して監視画面から参照できるよう設計されている点がそのまま実利になります (2026 年 9 月時点・出典: Splunk Observability Cloud Pricing)。ログを二重に取り込まず、既存ライセンスの範囲で相関できるのは、ログ主体の組織にとって費用と運用の両面で大きな差です。第二にトレースの扱いで、Splunk APM は「NoSample full-fidelity trace ingest」、つまりサンプリングせず全量を取り込むことを製品の特徴として掲げ、AlwaysOn の継続プロファイリングも APM 単価に含まれます。Datadog の APM は取り込みスパンを GB で計測し (APM ホストあたり月 150 GB の割当)、保持するスパンは retention filter でインデックスする設計なので、「全量を長く残す」用途では Splunk 側の設計が素直です。第三に価格の予測しやすさで、ホスト数 × パッケージ単価で月額がほぼ決まり、料金ページも超過課金の無さを前面に置いています。Datadog の流量比例の部分は、使い方次第で請求を大きく動かす (それゆえに使用量の監視が必須になる) 側面があり、この点は Splunk の設計の方が経営層への説明が簡単です。加えて Splunk Enterprise というオンプレミスを含むハイブリッド環境向けの製品群を持つことは、データを外に出せない組織にとって選択肢の広さになります。

Datadog が活きるのは必要な SKU だけを公開価格で始められる場面

Datadog の強みは、上の表の並びそのものより、その並びに差を生む構造にあります。1 つ目は「必要なものだけ買う」自由度です。APM が要るのは 200 台のうち 20 台だけ、という環境では、Datadog は 20 台分の APM SKU だけを足せばよく、残り 180 台はインフラ監視 Pro のままで済みます。パッケージ型では APM を含む段に上げる単位が問題になり、料金ページの「Starts at」表記が示すとおり、詳細な条件は個別見積もりに委ねられています。2 つ目は価格の透明性です。Datadog は年契約 / 月契約 / オンデマンドの 3 価格を公開し、クレジットカード払いで始めることも (2026 年 9 月時点・出典: Credit Card Billing)、無料プラン (5 ホストまで) で試すこともできます。Splunk の料金 FAQ は、ホスト単価による Entity Pricing の提供地域を 2026 年 9 月時点で「アメリカ大陸の民間組織」に限ると明記しており、日本の組織は問い合わせベースの見積もりが前提になります (出典: Splunk Pricing FAQs)。日本の組織が「まず 10 台で 1 か月試して実測を取る」という進め方をしやすいのは Datadog 側です。3 つ目に、インフラ監視、APM、ログ管理が最初から 1 つの製品の中で同じタグと同じ画面を共有している点です。Splunk 側では Observability Cloud と Splunk Platform という 2 つの製品の接続で実現する相関が、Datadog では 1 つの請求書と 1 つの UI の中で完結します。ログの置き場所を新しく決められる組織、つまり既存の Splunk ライセンスを持たない組織では、この一体性がそのまま運用コストの低さになります。

ログ主体か APM 主体か - 損得を分ける 4 つの変数

ここまでの材料で、損得が逆転する条件を変数の形に整理します。月額を式で書くと、Splunk 側は「APM 対象ホスト数 × App & Infrastructure 単価 + 残りのホスト数 × Infrastructure 単価」、Datadog 側は「全ホスト数 × インフラ監視 Pro 単価 + APM 対象ホスト数 × APM 単価 + 取り込み GB × 取り込み単価 + インデックス済みイベント数 × インデックス単価」です (単価は各社の料金ページの年契約の値を入れる。Splunk Platform 側のログライセンスは式に含めない)。式を眺めると、どちらが低くなるかを動かす変数は 4 つに絞れます。

変数が示す分岐は明快です。ログの量が小さいか、あるいはログを Datadog 以外 (S3 アーカイブなど) に置く設計なら、APM 対象を絞れる Datadog の積み上げ方が効いて Datadog が低くなりやすい。逆にログが月数 TB に達し、しかもそのログを既に Splunk Platform に入れている組織では、Datadog に移す側だけにログ費用が新規発生するため、総額は Splunk 側が下回り得ます。ここで重要なのは、ログ主体の環境で Datadog 側の請求を押し上げるのは取り込みよりインデックスの費用だという点です。Datadog は取り込みとインデックスを分けて課金する設計なので、取り込んだログのうちインデックスする割合を絞れます。インデックス率を下げれば、ログ主体の環境でも Datadog 側の総額はその分だけ下がります。つまり「ログ主体なら Splunk」は、Datadog でログを全量インデックスする前提のときに成り立つ結論で、インデックス設計を前提に入れると分岐点は大きく動きます。自分の環境で答えを出すには、上の式に 4 つの変数の実測値と各社の料金ページの単価を入れるだけで足ります。料金全体の読み方は料金の読み解きで扱っています。

移行か併用か - Splunk インテグレーションと OpenTelemetry という現実解

Splunk を使っている組織が Datadog を検討するとき、いきなり置き換えを選ぶ必要はありません。現実的な段階は 3 つあります。第一段階は併用で、Datadog には Splunk インテグレーションが用意されており、Splunk 側で作ったレポート (アラート) を Datadog にイベントとして送り、ほかのメトリクスと相関させたりチームで共有したりできます。設定は Splunk サーバーに datadog の Python ライブラリを入れる形です (2026 年 9 月時点・出典: Splunk Integration)。これで「ログ検索は Splunk、メトリクスと APM は Datadog、通知は Datadog に集約」という分業が成立します。第二段階は計装の共通化で、双方とも OpenTelemetry のデータ取り込みを掲げています (Splunk 側の出典: Splunk Observability)。アプリの計装を OpenTelemetry で書いておけば、送り先を切り替えるコストが小さくなり、比較検証 (同じトレースを両方に送って画面を比べる) も現実的になります。Datadog 側の取り込み経路は OpenTelemetry 対応で扱っています。第三段階が置き換えで、判断の条件は次の 4 点に集約できます。

4 条件のうち 1 と 2 がどちらも Datadog 側に傾くなら、置き換えの検討に進む価値があります。逆に 1 が Splunk 側なら、併用で相関だけ手に入れる第一段階に留まるのが費用対効果の高い選択です。