Datadogとは｜統合監視SaaSの特徴・Sentryとの違い・案件単価を徹底解説

Datadogとは？統合観測SaaSの全体像

Datadogは、インフラ・アプリ・ログ・セキュリティを横断して可視化できるSaaS型の統合観測プラットフォームです。Datadog社（米国・ニューヨーク本社、NYSE: DDOG）が提供しており、サーバ・コンテナ・APM・ログ・セキュリティ・ユーザー体験までを共通のタグと相関で串刺しに見られる点が特徴です。AWS・GCP・AzureやKubernetes、Dockerを中心としたクラウドネイティブ環境で採用例が多く見られます。

Datadogの基本定義

Datadogは、メトリクス・トレース・ログ・イベントを1つのプラットフォームで時系列に紐づけて可視化するSaaS型の観測ツールです。「サーバが落ちた」「APIが遅い」「ユーザーがエラーに遭遇している」といった異なるレイヤーの事象を、ホスト名・サービス名・環境名といったタグで横断的に突合できるところが、単機能の監視ツールとの大きな違いです。

公式には数百種類以上のインテグレーションが用意されており、AWS・Azure・GCPの各種マネージドサービス、Linux、ミドルウェア、CI/CDツール、SaaSアプリケーションからメトリクスを取り込めます。最新の対応サービスはDatadog DocumentationのIntegrations一覧で確認できます。

なぜ「統合観測」と呼ばれるのか

監視ツールは長く、サーバ監視（Zabbix系）、APM（New Relic系）、ログ（ELK系）、エラー追跡（Sentry系）と用途別に分かれてきました。Datadogはこの複数領域をひとつの製品群に統合し、共通のクエリ言語とタグで分析できることを売りにしています。「サーバCPUのスパイクと、APIのレイテンシ悪化と、エラーログの増加が同時刻に起きた」を1画面で並べられるのが、現場で評価される代表的なポイントです。

提供形態とプラン構成

Datadog本体は基本的にSaaSとして提供され、セルフホスト型の選択肢は一般的ではありません。一方、Datadog Agent自体はクラウド・オンプレ・物理サーバなど幅広い環境に配置できます。料金プランはInfrastructure・APM・Logs・Security Monitoringなど機能単位で契約して積み上げる体系で、Pro/Enterprise相当の有償ティアと、限定的な無料利用枠が組み合わされています（執筆時点。詳細は公式のPricingページを必ず確認してください）。

ミニFAQ

• Q. 個人で試せますか？　A. 無料トライアルや一部の無料利用枠が用意されることがありますが、提供条件は時期で変更されます。最新の条件は公式のPricingページで確認してください。

• Q. 国内リージョンはありますか？　A. AP1（東京）を含む複数リージョンが選択肢にあります。実際のデータ保存先や監査・法務要件への適合性は、利用機能・契約条件・公式ドキュメントを社内要件と照らし合わせて確認する必要があります。

Datadogでできること｜主要機能の整理

主要機能はおおむね5系統に分けて理解すると、案件の要件定義と紐づけやすくなります。

Infrastructure Monitoring

サーバやAWS EC2、Kubernetesノードなどにエージェントを入れ、CPU・メモリ・ディスク・ネットワーク・カスタムメトリクスを収集します。タグ（環境/サービス/チーム）を付けて束ねられるため、「本番のAPIサーバだけ」「特定のチームが運用するサービスだけ」といった切り口で素早く絞り込めます。

APM（アプリケーション性能監視）

APMはリクエスト単位の分散トレースを収集し、どのサービス・どのSQL・どのHTTPコールに時間がかかっているかを階層で表示します。Node.js・Python・Java・Goなど主要言語のSDKが用意され、エージェント経由でトレースを送る構成が一般的です。Continuous Profilerを併用すれば、本番のCPU/メモリ使用箇所をコード行レベルで継続的に取得できます。

Log Management

アプリログ・nginxアクセスログ・CloudTrailなどを取り込み、Live Tail/検索/集計が可能です。重要な設計ポイントは「Indexed」と「Archive」の使い分けで、検索対象にするログだけインデックス課金、それ以外はS3アーカイブに流すと費用が抑えられます。

Synthetic Monitoring と RUM

Syntheticは世界各地のロケーションからAPI/Webサイトを叩く外形監視。RUM（Real User Monitoring）はブラウザやモバイルアプリにSDKを入れ、実ユーザーの体感パフォーマンス・エラーを記録します。フロントエンド寄りの計測にはRUMが向きます。一方、例外イベントの詳細追跡はSentryを併用する構成もよく見られます。

Cloud SIEM / セキュリティ系

ログを起点に、不正なAPIコールやIAM変更を検知するCloud SIEM、IaC・クラウド設定の逸脱を監視するCSPM（Cloud Security Posture Management）などが用意されています。SREチームが運用主導で導入する例もあれば、セキュリティチームが要件を握って導入する例もあります。

ミニFAQ

• Q. 1機能だけ使うことはできますか？　A. 機能単位で契約できるため、まずLog Managementだけ、まずAPMだけ、といった部分導入も可能です。

• Q. オンプレ環境でも使えますか？　A. データ送信先はSaaSですが、エージェントはオンプレサーバ・VMware・物理機にも入れられます。

Datadogの料金体系｜ホスト課金とログ取り込みの落とし穴

Datadogの料金は「機能ごとに別課金、ホスト数とログ量と保持期間でスケールする」のが基本構造です。執筆時点の公式Pricingを必ず一次情報として参照してください。

料金モデルの基本

• Infrastructure：ホスト課金（Pro/Enterpriseで単価が異なる）

• APM：ホスト課金（Infraと別建て）

• Logs：取り込み（GB）＋インデックス保持（million events × 保持日数）

• Synthetic / RUM：実行回数・セッション数ベース

• カスタムメトリクス：100メトリクス/ホストの無料枠超過分を従量

ホスト課金は一見シンプルですが、Kubernetesのpodを多数稼働させる環境ではコンテナ数の超過課金（Container Monitoring）が発生するケースがあり、見積もりとずれやすいポイントです。

コストが膨れる典型パターン

• ログを「とりあえず全部Indexedにする」設定でログ取り込みが暴発する

• カスタムメトリクスのタグ次元を増やし、メトリクス基数（カーディナリティ）が爆発する

• 短命コンテナの集計設定を誤り、ホスト換算が想定より大きくなる

• 開発環境にも本番と同じ保持日数を適用してしまう

コスト最適化のチェックリスト

• ログは「検索したいもの」だけIndexed、それ以外はArchiveに回す

• インデックスの保持日数を環境別（本番15日／検証3日など）に切る

• カスタムメトリクスのタグは「サービス・環境・リージョン」など分析に必要な軸に絞る

• Container Monitoringの対象ホスト数を月次でレビューする

• Synthetic/RUMは「監視対象のクリティカルパス」だけに絞り、全画面に貼らない

公開案件や実務事例を見る限りでは、Datadogのコスト最適化はSREやDevOpsエンジニアが継続的なレビューを担う前提で募集されるケースが目立ち、フリーランスの参画案件でも頻出のテーマです。

Datadogと他観測ツールの違い

「Datadogか、他のツールか」という議論はそれ単体では決まりません。何を観測したいか、社内に運用リソースがどれだけあるかで適正解が変わります。

Datadog と Sentry の違い（用途の重なりと住み分け）

Sentryは、アプリケーション例外と性能を細粒度で追跡する用途に強いツールです。フロントエンドのJSエラー、スタックトレース、リリースとの紐づけといった切り口はSentryが扱いやすく設計されています。一方、サーバメトリクスやログ・インフラ全体の相関までは想定の中心にありません。

Datadogも例外追跡やRUMでフロント計測ができますが、「障害が起きたときにアプリ層からインフラ層まで突き合わせたい」需要が強いか、「特定のエラーを開発チームに即時に届けたい」需要が強いかで使い分けるのが実務的です。両方を併用し、SREがDatadog、開発チームがSentry、と分担している現場もあります。

Datadog と New Relic の比較

New RelicはAPMの老舗で、現在は「ユーザー数課金＋取り込み量課金」のシンプルなモデルに切り替えています。社内に多数の小さなサービスがあり、ユーザー数あたりの単価で見積もりたい場合はNew Relicが当てはまるケースもあります。Datadogはホスト・機能単位の積み上げで予算化しやすい反面、機能を増やすほど見積もりが複雑化する傾向があります。

Datadog と Prometheus + Grafana の比較

Prometheus＋GrafanaはOSSの定番組み合わせです。SaaS課金がなく、ストレージ・運用は自前で抱える代わりに自由度が高いのが特徴です。Kubernetes中心の環境で内製能力があるチームなら成立しますが、長期保管・APM・ログ集約まで含めると周辺コンポーネント（Thanos、Loki、Tempo等）を自前で運用する必要があり、運用コストとSaaS課金のバランスで意思決定することになります。

Datadog と CloudWatch / Azure Monitor の比較

クラウド純正のCloudWatch・Azure Monitorは、各クラウド内の標準メトリクスとログを安価に扱えます。マルチクラウド・マルチサービスを束ねる横串の可視化が必要になると、Datadogのような独立SaaSに寄せる判断が出やすい構図です。

ミニFAQ

• Q. Datadog一本に寄せるべきですか？　A. 監視対象がマルチクラウド・複数言語に広がっているなら寄せる価値が出ます。逆に1クラウド・小規模ならCloudWatch＋必要箇所だけSentryのような構成のほうが安く済むこともあります。

• Q. SentryとDatadog APMの違いを一言で？　A. Sentryは「個別の例外イベントを追う」、Datadog APMは「リクエストの流れと性能を追う」と整理すると噛み合いやすいです。

フリーランスエンジニアのDatadog案件動向

ここで紹介する単価レンジは、主要フリーランスエージェントの公開案件のうち、業務委託・週3〜5日・首都圏中心のSRE/DevOps系募集を目視集計した目安です。Datadog単独の募集はほぼ存在せず、Kubernetes/IaC/CI/CDなど周辺スキルとの組み合わせでSRE・プラットフォームエンジニア・DevOps系の案件に含まれる形が中心です。

募集職種と単価レンジの目安

上位レンジは、Kubernetes運用・IaC・SLO設計・オンコール改善まで一貫して担える中上級者を想定した目安です。数値は公開案件ベースの観測で、実案件は商流・スキル・常駐有無・時期で大きく変わります。フリーランスの単価相場全般はフリーランスエンジニアの単価相場で整理しています。

案件で求められやすいスキルセット

• Kubernetes/EKSの運用経験（最低でもPodベースの観点でメトリクス・ログを扱える）

• TerraformなどのIaCで監視リソースをコード化できる

• GitHub Actions等のCIにDatadogのデプロイ通知やCI Visibilityを組み込める

• SLO/SLIの考え方とアラート設計（バーンレート・チケット駆動）の経験

• ログ・メトリクスのコスト最適化を運用フェーズで継続できること

よくある業務内容

• ダッシュボード設計（サービスごとのSLI/SLO・障害時の初動視点）

• アラート設計（重複・誤発火の整理、PagerDuty/Slack連携）

• ログパイプラインの整備（Indexed/Archiveの切り分け、アラート用ログ抽出）

• カスタムメトリクスの整理とコスト見直し

• IaCによる監視リソースの管理（ダッシュボード・モニタ・SLOをコード化）

案件を獲得しやすい職種カテゴリ

Datadogが必須スキルに挙がるのは、SRE・DevOpsエンジニア・クラウドエンジニア系の募集が中心です。バックエンド・データ基盤領域でも「自分でアラート設計まで担う」案件で必須に挙がるケースが増えてきました。

Datadog導入・運用でよくある失敗と対策

実案件でフリーランスが入って整理するパターンの多い「詰まりどころ」をまとめます。

アラート疲れ（Alert Fatigue）

• 全メトリクスにアラートを貼り、夜間のSlackが鳴り止まない

• 対策：SLOベースのバーンレートアラートに絞り、低優先度はインシデント外のチケット起票に回す

タグ設計の崩壊

• env/service/teamの命名がチームごとに揺れ、横串の集計ができない

• 対策：タグ命名規約をTerraform/Helmで強制し、レビュー対象に含める

コスト爆発

• 開発環境でも本番と同じログ保持日数になっており、ログコストの大半が開発由来

• 対策：環境別のIndex設定、Container Monitoringの月次レビュー、不要なカスタムメトリクスの棚卸

「導入したが運用に乗らない」状態

• 監視SaaSを入れたものの、ダッシュボードが個人作成のまま属人化し、誰も見ないダッシュボードが残る

• 対策：SLOとサービスカタログを軸にダッシュボードを再編し、オンコールが必ず最初に見る画面を1つに決める

Datadog学習ロードマップ

ツール単体ではなく、Kubernetes・IaC・CI/CDなどの周辺スタックと一緒に学ぶのが、案件単価への接続を考えるうえで近道です。

基礎フェーズ

• 公式のLearning Centerの無料コースで主要機能を一周する

• 個人AWSアカウントにEC2/EKSを立て、Infrastructure・APM・Logsを試す

• ダッシュボード・モニタ・SLO・ServiceCatalogをUIから一通り作る

実務寄りフェーズ

• TerraformのDatadog Providerでモニタ・ダッシュボード・SLOをコード化する

• GitHub ActionsからDatadog CI Visibilityにテスト結果を送る

• ログをS3アーカイブ＋必要分だけIndexedに振り分ける構成を作る

案件接続フェーズ

• SLI/SLOを定義してバーンレートアラートを設計できる

• インシデント対応のRunbookとDatadog Notebookを連携させる

• コスト最適化の月次レビューを自分のフォーマットで回せる

認定資格

Datadog社は認定資格プログラムを提供しています。試験名や対象範囲は更新されるため、最新の試験体系・申し込み条件はDatadog Certificationページで確認してください。資格そのもので単価が跳ねるわけではありませんが、案件提案時のスキルシートで「公式ラーニング修了」「認定資格取得」と書けると、体系的に学んでいるシグナルとして使えます。

まとめ

Datadogは、サーバ・コンテナ・APM・ログ・セキュリティを共通のタグで束ねて見るための統合観測SaaSです。ツール単体の学習よりも、Kubernetes・IaC・CI/CDと組み合わせて「監視基盤を運用設計できる人」へ寄せると、フリーランス案件の単価レンジに直結します。

実務でつまずきやすいのは、ホスト課金とログ取り込みのコスト管理、タグ設計の崩壊、アラート疲れの3点。「導入して終わり」ではなく、月次レビューと棚卸を回し続ける運用フェーズの設計まで含めて担える人材が、SRE・DevOps系の上位案件で重宝されています。

学習の入口は公式Learning Centerと個人クラウド環境での実機検証で十分です。そのうえで、SLO・バーンレート・IaCによる監視リソース管理など、案件単価に効く論点に時間を投下していくと、案件提案時の説得力が安定します。

監視基盤を含むSRE・DevOps系の案件を探す場合は、フリコンで公開案件の傾向や求められるスキルを確認したうえで、自分のスキルセットを当てはめる流れがおすすめです。

主な参照元

• Datadog 公式サイト

• Datadog Pricing

• Datadog Documentation

• Datadog Learning Center

• Datadog Certification