要点: Datadogのホスト単位・GB単位の課金モデルは、Kubernetesネイティブなクラウド運用を支える動的でエフェメラルなインフラと相性が悪く、コスト面で不利に働きます。オブザーバビリティのコストがインフラ以上のペースで膨らんでいるなら、本当の問題は支払い先のプラットフォームではなく、その土台となるアーキテクチャにあります。本記事では、2026年に検討すべき5つの代替ツール、DoiT、SigNoz、Grafana、New Relic、Dynatraceを取り上げ、CloudOpsチームが押さえるべき機能と、運用を止めずに移行する方法を解説します。
Datadogの請求額が膨らんだ原因は、チームがホストを増やしたからではありません。Kubernetesが本来の役割をきちんと果たしているからです。
Podのスケールアウト、エフェメラルなコンテナ、OpenTelemetryパイプラインに追加される新しいタグディメンション——こうしたイベントひとつひとつが、実際の運用の複雑さとはかけ離れた形でDatadogの課金対象を増やしていきます。Datadogのカスタムメトリクス課金は、カーディナリティ、つまりメトリクス名と関連タグのユニークな組み合わせ数に基づいて算出されます。値のバリエーションが多いタグをひとつ追加しただけで(OpenTelemetry計装ではよくあるパターンです)、課金対象となるメトリクスの時系列数が爆発的に増え、大規模環境ではDatadog請求額全体の半分以上を占めることも珍しくありません。
これが、2026年のDatadog代替論議の根底にある構造的な問題です。Datadogのオブザーバビリティが劣っているわけではありません。問題は、ほとんどの「Datadog代替」がDatadogと同じ形をしていることです。言語別エージェントの仕組みも、SaaS専用のデータプレーンも、GB単位の課金マトリクスも同じ——違うのは価格設定が少しだけずれている点くらいです。乗り換えればその年の請求は下がっても、いずれ同じコスト構造が再現されてしまいます。
本当に方程式を書き換えるのは、アーキテクチャや価格モデルが根本的に違うアプローチ、あるいはDoiTのように、そもそも問題との向き合い方そのものが異なるアプローチです。
CloudOpsチーム向けDatadog代替ツール5選
個別のツールに入る前に、CloudOpsという文脈で「最適」が何を意味するのかを整理しておきましょう。一般的なオブザーバビリティのランキングは、統合の幅、UIの洗練度、APMの深さを重視しがちです。しかしCloudOpsチームに必要なのはもっと具体的な要素です。オートスケーリングを罰しないKubernetesネイティブな可視化、再計装を強いられないOpenTelemetry互換性、インシデント対応とつながるSLOワークフロー、そしてトラフィックが急増しても予測可能なコストモデルです。
この基準を踏まえて、主要な代替ツールを比較していきます。
DoiT
DoiTはこの議論で根本的に異なる立ち位置を取ります。Datadogを置き換えるのではなく、DoiTのDatadog Intelligenceモジュールがテレメトリ量、メトリクスのカーディナリティ、ログ保持パターンをマッピングし、無駄を洗い出してオブザーバビリティのworkloadsを適正化し、すでにクエリされなくなったメトリクスの自動クリーンアップを実行します。Datadogを大規模に運用するCloudOpsチームにとって、この発想転換は重要です。コスト問題を解決するために、必ずしも移行が必要なわけではないのです。
DoiT Cloud Intelligenceは読み取り専用APIでDatadog組織に接続し、製品別(APM、Logs、Infrastructure)、チーム別、環境別、タグ別の支出を、クラウドインフラのコストとあわせて単一のビューで可視化します。具体的には、環境別に分解されたプラットフォームコスト、Datadogエージェントが稼働しているホストごとのコスト、使われていない資産を特定するためのダッシュボード利用傾向、請求に跳ね返る前に異常な利用パターンを検出するアノマリーディテクションなどが含まれます。
DoiTが従来のオブザーバビリティツールと一線を画すのは、インサイトを示したあとに何が起こるかという点です。DoiT Cloud Intelligenceは、偏ったSparkジョブ、インデックスのないクエリ、半分アイドル状態のGPU推論といった隠れた無駄を可視化したうえで、ダッシュボードに推奨事項を残すだけで終わらせず、実際の修正までコミットするForward Deployed Engineeringチームをセットで提供します。そもそも移行が必要かを見極めようとしているチームにとって、自動化されたインサイトとエンジニアリング支援の組み合わせは判断材料そのものを変えるはずです。
主な機能:
- Datadogとクラウドインフラのコストを単一画面で統合的に可視化
- カーディナリティとログ保持の分析、取り込みの無駄を削減する自動推奨
- チーム、サービス、環境別のショーバック・チャージバック配賦
- Datadog利用量のアノマリーディテクションと、実行に移せる改善策
- Kubernetes、FinOps、CloudOpsの実行を支援するForward Deployed Engineering
制約: DoiTはDatadogのオブザーバビリティ機能を置き換えるものではなく、最適化とガバナンスを担います。プラットフォーム全体の移行を望むチームは、DoiTの管理レイヤーと並行して、以下の代替ツールのいずれかを評価する必要があります。
最適な対象: Datadogを大規模に運用するCloudOpsおよびFinOpsチームで、コストの予測可能性、プラットフォーム横断の可視化、そして推奨を「見える化」するだけでなく実行に移すためのエンジニアリング支援を求めている組織。
SigNoz
SigNozは、ClickHouseをベースに構築されたオープンソースのOpenTelemetryネイティブなオブザーバビリティプラットフォームです。シグナルごとに別々のバックエンドを用意する必要がなく、ログ、メトリクス、トレースを単一の製品でカバーします。Loki、Tempo、Mimirを連結するGrafanaのLGTM構成に比べ、運用上の大きなアドバンテージとなります。
SigNozはOpenTelemetryを中核に据えてゼロから設計されており、OTelのセマンティック規約とデータモデルを完全に理解しています。Grafanaスタックとは違い、3つのシグナルすべてに対して本当に統合された体験を提供します。コンテキスト切り替えや異なるクエリ言語の習得を強いられることなく、メトリクスからトレース、ログへとシームレスに行き来できます。
主な機能:
- 変換レイヤーやデータモデル変換を介さないネイティブOTLP取り込み
- メトリクス、ログ、トレースを単一のクエリインターフェースに統合
- 高カーディナリティデータの高速な取り込みと集約を実現するClickHouseバックエンド
- Apache 2.0ライセンスで、セルフホストとSaaSのいずれかを選択可能
- CNCFエコシステムとの積極的な連携と活発なコミュニティサポート
制約: SigNozスタックを自前で運用するということは、管理、スケーリング、セキュリティをすべて自社で抱えるということです。大規模運用が複雑になりがちなClickHouse依存も含まれます。比較的新しいプラットフォームのため、機能セットやUI/UXは10年来の老舗プロダクトと比べるとまだ成熟途上です。
最適な対象: ベンダーロックインを避けて真のOTelネイティブなオブザーバビリティを実現したい、そしてセルフホストやSaaSデプロイを自前で運用できるプラットフォームEngineersのリソースを持つチーム。
Grafana
Grafana Labsは、すでに多くのKubernetes監視スタックで採用されている可視化レイヤーを生み出してきました。フルLGTMスタック——ログのLoki、ダッシュボードのGrafana、トレースのTempo、メトリクスのMimir——により、各コンポーネントが独立してスケール・進化できるコンポーザブルなアーキテクチャを提供します。Grafana Labsは2025年9月時点でARR4億ドル超、顧客数7,000社に到達しており、OTelはプラットフォームのオブザーバビリティ戦略の中核を担っています。AlloyがGrafana版OpenTelemetry Collectorとして機能し、BeylaがeBPFベースのゼロコード計装を実現しています。
主な機能:
- シグナルタイプごとにベストオブブリードのバックエンドを組み合わせるコンポーザブルなLGTMスタック
- Kubernetes監視の標準言語であるPromQLによるPrometheusネイティブメトリクス
- 従量課金で利用できるGrafana CloudのマネージドSaaSオプション
- Grafana Cloudでのカーディナリティ制御とコスト管理を担うAdaptive Metrics
- 豊富な統合ライブラリとコミュニティプラグインのエコシステム
制約: Grafanaでは、ログ、メトリクス、トレースごとに別々のバックエンドを選定し、デプロイし、連携させる必要があります。よくある悩みとして、LGTMスタックを4つの別システムとして運用する手間、Lokiの高カーディナリティ上限、ラベルが揃わないときに崩れやすい相関、そしてGrafana Cloudの複雑な価格体系が挙げられます。
最適な対象: すでにKubernetesメトリクスでPrometheusとGrafanaに標準化済みで、既存のツール投資を活かしたままフルスタックのオブザーバビリティへ拡張したいチーム。
New Relic
New RelicのDatadogに対する最大の差別化要因は、その課金モデルです。New RelicのNRDBはすべてのシグナルタイプを統合テレメトリデータベースに格納し、ホストは課金対象外のディメンションとして扱われます。ホスト、エージェント、コンテナ、デバイス、クラウドファンクションは台数無制限・追加コストなしで含まれ、月100GBの無料取り込み枠が初期評価を後押しします。オートスケーリングでノード数が常に変動するKubernetesクラスタを運用するCloudOpsチームにとって、この構造的な違いは予算に直接効いてきます。
New RelicはGartner Magic Quadrantで13年連続でリーダーに選出されており、ホスト単位の課金なしに従量課金を求める中堅から大企業まで、堅実な選択肢となっています。
主な機能:
- ホスト単位・コンテナ単位の課金がないユーザーベースの価格モデル
- メトリクス、イベント、ログ、トレースを統合的に扱うNRDB
- 評価用に提供される月100GBの無料取り込み枠
- NRQLクエリ言語に加え、PromQL互換も提供
- APM、インフラ、デジタルエクスペリエンス監視まで広くカバー
制約: New RelicのNRQLは新規ユーザーにとって学習コストがあります。多数の製品を単一インターフェースに統合する流れが進んでおり、情報量に圧倒されると感じるチームもあります。高カーディナリティデータや大量のログ取り込みは依然としてコストを押し上げます——ただし、Datadogとは違うメーターを通じて、です。
最適な対象: ホスト単位の課金が予測しづらいコスト負担を生んでいる大規模Kubernetes環境を抱える中堅から大企業のチームで、コストの予測可能性と同じくらい、幅広いAPMとインフラのカバレッジを重視する組織。
Dynatrace
Dynatraceは、大規模環境で自動化されたAI支援のオブザーバビリティを必要とする大企業チームをターゲットにしています。OneAgentテクノロジーが、手動の計装設定なしに環境内のすべてのコンポーネントと依存関係を自動検出・マッピングし、Davis AIエンジンがシグナルを相関させて根本原因分析を自動化します。Dynatrace Full-Stack Monitoringの料金はメモリGiB時間あたり0.01ドルで、監視対象ホストのメモリフットプリントと稼働時間に応じてコストが増減します。ノードサイズ、メモリ割り当て、ワークロード密度が頻繁に変動するKubernetes環境では、予測が難しくなる場合があります。
主な機能:
- 依存関係を自動マッピングするOneAgentによる自動計装
- 複雑なマイクロサービス環境全体で根本原因分析を自動化するDavis AI
- インフラ、APM、ログ、デジタルエクスペリエンス、セキュリティまで網羅するフルスタックカバレッジ
- クラスタとworkloadsの深い可視化を備えた強力なKubernetes監視
- RBAC、監査証跡、コンプライアンス機能などのエンタープライズガバナンス
制約: 高度な自動化は、Dynatraceを「ブラックボックス」のように感じさせることがあります。AIが正しいときは強力ですが、誤ったときには理由を理解しにくくなります。OneAgentはプロプライエタリで、OTelサポートはネイティブではなく後付けの位置づけ、料金体系も大企業向けに振られているため、小規模で機敏なクラウドネイティブなチームにはオーバースペックになりがちです。
最適な対象: 複雑で異種混在の環境を持ち、運用負荷を下げるためにAI支援の自動化を求め、プレミアムなマネージドプラットフォームに相応の対価を払う意思のある大企業チーム。
Datadog代替で重視すべき機能とは?
オブザーバビリティプラットフォームの乗り換えは、本番に関わるすべてのチームに影響します。評価基準を最初に正しく設定しておかないと、別ベンダーから同じ構造的問題を抱えたプラットフォームに乗り換えるだけの数ヶ月にわたる移行作業に終わりかねません。
OpenTelemetryネイティブなアーキテクチャか?
OpenTelemetryはベンダーニュートラルなテレメトリ計装のデファクトスタンダードとなっており、オブザーバビリティのバックエンドを何にするかで、その投資が活きるか、プロプライエタリなデータモデルに飲み込まれるかが決まります。
OTelをネイティブに扱うプラットフォームは、変換レイヤーを介さずにOTLPデータを取り込めます。DatadogとDynatraceもOTel取り込みには対応していますが、コアバリューはあくまでプロプライエタリエージェントに紐づいています。これらのプラットフォームでOTelデータを使うチームは、ネイティブ計装を使うチームとは異なる、しばしばより劣った体験を強いられがちです。
CloudOpsチームにとって、これは運用上の死活問題です。再計装はプラットフォーム移行で最もコストのかかる作業だからです。OTelをファーストクラスシチズンとして扱うバックエンドを選んでおけば、計装への投資はベンダー選定の変化を超えて生き残ります。さらに、移行時に2系統のエージェント構成を抱え込むことなく、複数のバックエンドを同時に走らせることもできます。
Kubernetesファーストなオブザーバビリティか?
従来のホストベース監視は、Kubernetes環境では破綻します。ノードはエフェメラルで、Podは水平にスケールし、課金単位であるホストは、その上で動くworkloadsと安定した関係を持ちません。CloudOpsチームに必要なのは、ネームスペース単位の可視化、Podやコンテナ単位のコスト配賦、オートスケーラーの挙動追跡、そして共有クラスタ全体でのノイジーネイバー検出です。
DoiT Cloud Intelligenceは、PerfectScale for Kubernetesを通じて、高度なrequests/limits管理、ノードプール最適化、オートスケーラーのチューニング、ビンパッキング分析、ノイジーネイバー制御を提供し、workloadsの挙動とコスト結果を切り離さずに結びつけます。運用の健全性とコスト責任を結びつけるこの設計こそが、Kubernetesファーストなオブザーバビリティを、たまたまクラスタビューを備えた汎用監視ダッシュボードと隔てる本質的な差です。
代替ツールを評価する際は、Kubernetesラベルから生じるメトリクスのカーディナリティをそのプラットフォームがどう扱うかを必ず確認してください。Pod名、ネームスペースID、デプロイメントハッシュは高カーディナリティなラベルの組み合わせを生み出し、ストレージとクエリのコストを劇的に押し上げます。カーディナリティを管理する明確な戦略を持たないプラットフォームでは、価格モデルが表面上は違って見えても、結局はDatadogと同じコスト構造を再現してしまいます。
コストが予測可能な価格モデルか?
プラットフォームの乗り換えは、コストを別のコストに置き換える行為です。移行には6〜12ヶ月かかります。その間、ダッシュボード、モニター、統合、チームのワークフローを再構築することになります。完了する頃にはデータ量が伸びており、節約分の多くが相殺されます。
これは移行に反対する理由ではなく、着手前にコスト全体像をモデル化すべき理由です。問うべきは「今日どの代替が一番安いか?」ではなく、「インフラがスケールしても予測可能性を保てる価格モデルはどれか?」です。
ホスト単位の課金(Datadog、Dynatraceの一部)はオートスケーリングを罰します。GB単位の取り込み課金(Grafana Cloud、New Relic)は冗長なロギングを罰します。ユーザー単位の課金(New Relicのシートモデル)は大規模チームへの幅広いプラットフォーム提供を罰します。どのコストドライバーが自社の実利用パターンに合致するかを理解することは、単価そのものよりも重要です。
DoiTのアプローチは、すでにDatadogを使っているチームにとってこのトレードオフを回避する道です。実際にコストを牽引しているメトリクス、ログ、ダッシュボードを可視化し、不要なものを自動でクリーンアップすることで、プラットフォーム移行なしにDatadogのコストを予測可能なものに変えます。
運用を止めずにDatadogから移行するには?
移行リスクは3つに集中します。移行期間中のアラートカバレッジの抜け、サービス境界でのトレースコンテキストの欠落、そして新プラットフォームが本番負荷で力不足だった場合のロールバックの複雑さです。
並行デプロイのアプローチはこの3つすべてに対処できます。両プラットフォームを同時に稼働させ、まずは非本番環境から始めます。新プラットフォームが同じシグナルを同じ忠実度で捉えられることを検証し、本番のいかなる箇所でもDatadogを廃止する前に、アラート条件が正しく移植されていることを確認します。
うまくいく移行は「ステージング → 本番1リージョン → クリティカルなサービス → 全体」の順で進みます。「金曜の夜にすべてを切り替える」ではありません。段階的に進めることで、新ツールのデータパリティを測定し、特にIngressプロキシ、キュー、非同期フロー周辺で起きやすいトレース伝播の抜けを発見し、Datadogを廃止する前に実ボリュームに対してコスト試算を検証できます。両ツールを並行稼働し、請求が下がる前に一時的に増える重複期間も計画に織り込んでください。通常は30〜90日です。重複コストを節約しようと並行稼働フェーズを省くチームは、たいてい6週間後にロールバックする羽目になります。
アラートパリティの検証は独立したワークストリームとして扱う価値があります。新しいプラットフォームで同じアラート条件を再現すれば同じ挙動になる——そう思い込んではいけません。クエリ言語の違い、データモデルの差、保持ウィンドウのデフォルト値は、いずれもインシデント発生時にしか露見しない静かなカバレッジの穴を生みかねません。
OpenTelemetryパイプラインを運用しているチームには構造的なアドバンテージがあります。OTel Collectorから既存のDatadogエンドポイントと新しいバックエンドの両方に同時に二重送信できるのです。これにより、2系統のエージェント構成を保守することなくシグナルパリティを検証でき、ロールバック経路もクリーンに確保できます。コレクタの出力先を切り戻すだけで元の状態に戻せます。
DoiTのエンジニアリングチームは、こうした移行をCloudOps契約の一環として支援し、自動化ツールと現場でのハンズオン支援を組み合わせて、移行期間のリスクを下げます。
CloudOps環境に合うDatadog代替をどう選ぶか?
率直に言えば、最適な代替は、解決したい具体的な課題によって変わります。
課題がコスト——カーディナリティ、ログ取り込み、ホスト数によって暴走するDatadog支出——であれば、最短の解決ルートは必ずしも移行ではありません。DoiTのDatadog Intelligenceモジュールは、既存のDatadog環境内で無駄削減作業を可視化し、自動化します。これは上述のプラットフォーム代替群とは異なる価値提案であり、6〜12ヶ月の移行に踏み出す前の正しい第一手となるチームも少なくありません。
課題がベンダーロックインやデータ主権——ベンダー変更を超えて活きるOTelネイティブな計装が欲しい、あるいはテレメトリをVPC内にとどめる必要がある——であれば、SigNozやセルフホストのGrafanaスタックが最大のポータビリティをもたらします。代償は、ストレージとクエリレイヤーの運用責任を自分たちで背負うことです。
課題がKubernetes中心の環境におけるホスト単位の課金——オートスケーリングのせいでDatadogの請求が予測不能になっている——であれば、New Relicのホスト非依存の価格モデルがその構造に直接効きます。Dynatraceは別の角度から対処します。AIによる自動運用でチームが対応すべきアラート量そのものを減らし、エンタープライズ予算に合わせたプレミアム価格帯で提供します。
CloudOpsチームが一貫して過小評価しているのは、移行コストそのものです。再計装、ダッシュボード再構築、アラートパリティの検証、そして両プラットフォームが並走する30〜90日の重複期間。これらを総所有コストに織り込むと、ランキングの順位が大きく変わることも珍しくありません。
DoiTは、意思決定を下す前にこの分析を一緒に進めます。オブザーバビリティのコストデータを実際のクラウド支出と接続し、プラットフォーム変更のインパクトをモデル化し、どの道を選んでも実行までやり切るエンジニアリング支援を提供します。目的はコストを別の場所に移すことではありません。クラウド運用を本当の意味で予測可能にすることです。
DoiTとともに、コストを別の場所に移すだけでなく、実際にクラウド請求額を引き下げるDatadog代替を選びましょう。DoiTに相談する
Datadog代替に関するよくある質問
Datadogの最良の無料代替は? SigNozはCloudOpsチームにとって最も有力な無料オプションです。Apache 2.0ライセンスのオープンソースで、ネイティブなOTelサポートを備え、メトリクス、ログ、トレースを単一のセルフホストプラットフォームで統合的にカバーします。GrafanaのLGTMスタックもセルフホストなら無料ですが、シグナルタイプごとに別コンポーネントを組み上げて運用する必要があります。マネージドSaaSで評価したいチーム向けには、New Relicが月100GBの無料取り込み枠を提供しています。
OpenTelemetryをDatadog代替で使えますか? はい。むしろOTel互換性は、CloudOpsチームが代替を評価する際に最も重要な基準のひとつです。SigNozとGrafanaはOTelをネイティブに扱い、OTLPを変換なしで直接取り込みます。New RelicとDynatraceもOTelデータを受け入れますが、プロプライエタリなデータモデルを経由してルーティングされるため、ネイティブエージェントを使う場合と比べてクエリ挙動や機能パリティに差が出ることがあります。
Datadogの移行には通常どれくらいかかりますか? 並行デプロイ、アラートパリティの検証、ダッシュボード再構築、チームワークフローの変更まで含めると、本番移行はおおむね6〜12ヶ月かかります。両プラットフォームが並走する重複期間は通常30〜90日です。重複コストを抑えようとこの期間を圧縮したチームは、ロールバックを余儀なくされるカバレッジの抜けに遭遇しがちです。
DatadogはKubernetes環境で使う価値がありますか? DatadogはKubernetes向けに深いオブザーバビリティを提供しますが、その課金モデルはKubernetes本来の設計思想とぶつかる場面があります。ホスト単位の課金とカスタムメトリクスのカーディナリティ課金は、オートスケーリング挙動や、OTelで計装されたKubernetes環境が自然に生み出す高次元ラベルを罰してしまうのです。移行を決める前に、CloudOpsチームはDoiT Datadog Intelligenceのようなツールによるコスト最適化で、プラットフォーム変更なしに問題を解決できないかを評価すべきです。
CloudOpsチームがDatadog代替で見るべきポイントは? 最も重要なのは次の3点です。OpenTelemetryネイティブなアーキテクチャ(計装投資を守り、将来の移行時に再計装コストを背負わずに済む)、Kubernetesファーストなオブザーバビリティ(ネームスペース単位の可視化、Podごとのコスト配賦、カーディナリティ管理)、そしてオートスケーリングや冗長なロギングを罰するのではなく、実際のスケーリング挙動に沿って動くコスト予測可能な価格モデルです。