Datadog と Sentry の比較 - エラートラッキングの境目と併用の型

同じ土俵ではない - アプリ特化の Sentry と統合監視の Datadog

Sentry と Datadog の比較で最初に押さえるべきは、両者が同じ問題を解く製品ではないことです。Sentry は公式の入門ドキュメントが「アプリケーションからエラー、ログ、トレース、リプレイ、プロファイル、メトリクスを捕らえ、分散トレーシングでつなぐ」と説明するとおり、アプリケーションのコードの中で起きたことを開発者に届けることに特化した製品です。最初の設定手順として案内されるのもソースコードリポジトリの接続で、エラーの原因になったコミットの推定 (Suspect Commits) やスタックトレースからリポジトリの該当行へのリンクがその中心にあります (2026 年 9 月時点・出典: Getting Started With Sentry)。Datadog はインフラ監視、ログ管理、APM、RUM を 1 つの製品群として提供する統合監視で、エラートラッキングはその中の 1 機能 (Error Tracking) です。したがって「エラートラッキングだけが要る」なら Sentry で足り、料金も安く済みます。Datadog が意味を持つのは、エラーを「どのホストで、どのデプロイの後に、どのログと一緒に起きたか」までつなげて見たいときです。この線引きを認めたうえで、結論を先に書くと、APM や RUM を Datadog で運用しているチームは Error Tracking を Datadog に寄せると調査の導線が 1 本になり、そうでないチームは Sentry を残して Datadog にイベントを流す併用が費用対効果の高い形です。以下、重なる面、課金の差、Sentry が勝る点、Datadog が活きる条件の順に材料を並べます。

重なる面はエラートラッキング、トレーシング、RUM の 3 つ

両者の機能名を docs の表記どおりに対応させると、重なる面は 3 つに整理できます。Sentry の料金ページに並ぶ製品は Error Monitoring、Tracing、Session Replay、Logs、Application Metrics、Uptime Monitoring、Cron Monitoring、Profiling です。Datadog 側でこれに対応するのは Error Tracking、APM のトレース、RUM の Session Replay、ログ管理、メトリクス、Synthetics です (2026 年 9 月時点・出典: Sentry Pricing、Datadog Error Tracking)。

Datadog の Error Tracking は、似たエラーの数千件を 1 つの Issue に束ね、影響を受けたユーザー数、初回発生時刻、原因と推定されるコミットを示します。エラーの出所は Browser SDK、Mobile SDK、ログ、トレース、RUM イベントの 5 つで、出所によって使える機能が変わります。たとえば APM トレース由来のエラーでは Exception Replay が本番環境の変数の値を自動で捕らえます (出典: Datadog Error Tracking)。Sentry と同じ「Issue に束ねる」体験が Datadog 側にもある、というのがこの表の第一の読みどころで、第二の読みどころは、その Issue から トレースとホストとログへ同じ画面で降りられるかどうか、という統合の深さの差です。

課金の差 - 席とイベント量で払う Sentry、監視対象の量で払う Datadog

課金単位の違いは、両者の設計思想がそのまま表に出た部分です。Sentry の料金は 2026 年 9 月時点で、無料の Developer (1 ユーザー)、組織単位の月額で払う Team と Business (契約形態で単価が変わる場合があり、既定の前払いデータ量込み) の 3 段階と、個別見積もりの Enterprise で構成されます。各有料プランには月あたり一定量のエラー、スパン、ログ、アプリケーションメトリクス、リプレイ、Uptime モニターなどが込みで、Developer にはそれより少ない量のエラーとスパンが含まれます。込み量を超える分は、前払いで割引のある Reserved volume か、全カテゴリで共有される Pay-as-you-go (PAYG) 予算から消費され、両方を使い切ると以後のデータは破棄されて課金もされません (出典: Sentry Pricing、Sentry Pricing & Billing)。

Datadog の監視の中核 SKU (インフラ / APM / ログ / RUM) にはユーザー数課金がなく (On-Call など一部製品はシート課金)、監視対象の量で払います。APM は 1 ホストあたりの月額 (インフラ監視のホスト単価に上乗せ)、RUM は 1,000 セッションあたりの単価で、RUM には集計中心の Measure と、絞り込んだセッションを深掘りする Investigate、Session Replay の追加という段があります (出典: Datadog Pricing)。Error Tracking はこれらの APM / RUM / ログ管理を経路として使う機能なので、本記事では単独の単価を扱わず、経路となる SKU を契約している前提で比べます。単位が「席 + イベント件数」と「ホスト + セッション」で違うため、同じ金額を並べる意味は薄く、比べるべきは「自分のチームでどちらの単位が増えるか」です。開発者が 30 人いても Datadog の請求は変わらず、ホストが 30 台あっても Sentry の請求は変わりません。料金の読み解きで扱う SKU 積み上げの構造と、Sentry の込み量 + PAYG の構造は、この点で正反対の形をしています。本記事は課金の仕組みを解説するものです。具体的な単価や料金は各社の公式の料金ページで確認してください。

Sentry が勝るのは開発者向けの体験、無料枠、低い入口価格

先に認めるべき事実として、Sentry が明確に勝る点が 3 つあります。第一に開発者向けの体験です。Sentry はソースコードリポジトリの接続を最初の手順に置き、原因コミットの推定、スタックトレースからリポジトリの該当行へのリンク、ソースマップやデバッグシンボルの適用による読みやすいスタックトレースを標準の導線にしています。AI による根本原因分析と修正 PR の自動生成 (Seer) も追加課金の形で用意されています (2026 年 9 月時点・出典: Getting Started With Sentry、Sentry Pricing)。「エラーを見た開発者が次にどこを直すか」までの距離が短い設計は、エラートラッキング専業の強みです。第二に無料枠で、Developer プランは 1 ユーザーながら一定量のエラーとスパンを含み、Error Monitoring と Tracing を無料で使えます。個人開発や小さなサービスでは、これだけで運用が完結します。第三に入口価格で、Team プランは組織単位の月額 1 本でユーザー数が無制限です。開発者が 20 人いるチームがエラートラッキングだけを求めるなら、Sentry の月額は人数に関係なく Team の基本料から始まり、同じ範囲を Datadog で持つには APM や RUM のホスト / セッション課金が先に立ちます (出典: Sentry Pricing)。加えて、PAYG 予算を使い切ると以後のデータを破棄して課金を止める設計と、急増時に自動でイベントを落とす Spike Protection は「請求の上限を決めてから使う」運用を可能にします (出典: Sentry Quota Management)。監視を失う代わりに請求を守る、という割り切りですが、予算の天井を先に決めたい組織にはこの明快さが効きます。

Datadog が活きるのはエラーをインフラ、ログ、トレースと 1 画面でつなぐ場面

Datadog 側の価値は、Error Tracking 単体の機能比較では見えにくく、相関の場面で現れます。まず切り分けの導線です。Datadog の Issue から該当トレースの スパンへ、スパンからそのホストのメトリクスへ、同じ時刻のログへ、と 1 つの画面の中で降りていけます。エラーが「コードのバグ」なのか「そのホストのメモリ枯渇」なのか「依存先の DB の遅延」なのかを、ツールを切り替えずに判定できることが調査時間を縮めます。APM トレース由来のエラーで Exception Replay が本番変数の値を自動で捕らえる機能も、この導線の上に載っています (2026 年 9 月時点・出典: Datadog Error Tracking)。次に通知の一元化で、Error Tracking のイベントにはモニターを設定でき、「新しい Issue が出た」「エラー量が閾値を超えた」をインフラや SLO のアラートと同じ経路、同じ当番表で受けられます。最後にタグの一貫性で、env / service / version の 3 タグがメトリクス、ログ、トレース、RUM を横断して同じ意味を持つため、「このバージョンをデプロイした後にエラーが増えたサービスはどれか」という問いを 1 つのクエリで書けます。費用の面では、すでに APM や RUM を Datadog で契約している環境なら、Error Tracking はその経路の上で使えるので、Sentry を別契約で持つより請求書が 1 枚減る、という実務上の単純さがあります (Error Tracking の課金条件は料金ページで確認してください)。逆に、Datadog に APM も RUM も入れていないチームが Error Tracking だけのために Datadog を契約するのは、ホストやセッションの課金が先に立つため向いていません。Datadog が活きるのは「監視の中心がすでに Datadog にある」場面だと言い切って差し支えありません。

併用の型と、置き換えに踏み切る条件

現実の選択肢は「置き換え」と「併用」の 2 つで、併用には確立した型があります。Datadog の Sentry インテグレーションは、Sentry の Internal Integrations の Webhook で Sentry のイベントを Datadog のログ / イベント取り込み口へ転送する方式で、旧来の Webhook 連携は非推奨になっています (2026 年 9 月時点・出典: Sentry Integration)。転送されたイベントは Datadog 側でデプロイイベントやインフラのメトリクスと並べて見られ、モニターの対象にもなるので、「エラーの詳細は Sentry で、相関と通知は Datadog で」という分業が成立します。

置き換えに踏み切る条件は、次の 4 つが揃ったときです。1 つ目は、バックエンドの APM が Datadog に入っていること。これが無ければ Datadog 側にエラーの経路がありません。2 つ目は、フロントエンドのエラーを見る必要があるなら RUM も Datadog にあること。3 つ目は、開発者が Sentry の Issue 画面で頼っている機能 (原因コミット、リポジトリへのリンク、AI 修正) の代替が Datadog 側で用意できていること。Datadog にも JetBrains IDE の Error Tracking 連携がありますが、チームが使う言語と IDE で実際に試してから判断します。4 つ目は、Sentry の契約更新のタイミングが近いこと。監視の乗り換えは並走期間が必要なので、更新の 2〜3 か月前に型 B を始めるのが現実的です。4 条件のうち 1 と 2 が満たせないなら、型 A の併用で相関と通知だけを Datadog に集める形に留めるのが、費用と効果の釣り合う選択です。

5 つの問いで置き換えか併用かを決める

最後に、置き換えか併用かを決めるための 5 つの問いをまとめます。

5 つの問いのうち 3 つ以上が Datadog 側に傾くなら置き換えの検討に進み、そうでなければ併用の型 A に留める、という単純な基準で十分です。どちらを選んでも、Sentry のイベントを Datadog に流す Webhook 連携は最初に入れておく価値があります。相関の効果を実測してから次を決められるからです。無料で試す手順は無料プランとトライアルで、導入全体の損得は導入判断チェックリストで扱っています。