オブザーバビリティ基礎編：New Relic / Datadog / AWS CloudWatch の実践的な選び方

こんにちは、練馬区旭丘で個人事業主として AI コンサル兼 AWS 構築をやっている野口です。

最近、クライアントから「うちの監視、見直したいんですけど、New Relic と Datadog と CloudWatch って何が違うんですか？」という相談を立て続けに受けました。これ、現場で本当によくある質問です。

正直に言うと、この 3 つは「比較表で並べて選ぶもの」ではありません。クラウド構成、運用チームの体制、コスト感、何を観測したいかで答えがまるごと変わります。今回は基礎編として、ツール選定で迷わないための判断軸を、現場目線で整理します。

実践編（次回）では、Terraform で実際に CloudWatch / New Relic / Datadog を連携させる書き方に踏み込みます。

そもそもオブザーバビリティとは何か — 「監視」とは別物

まず言葉の整理から。日本の現場では「監視」と「オブザーバビリティ」がほぼ同じ意味で使われがちですが、実務上はまったく違います。

• 監視（Monitoring）：想定済みの異常を検知する。CPU 90% 超え、ヘルスチェック失敗、5xx 増加など、「壊れ方を事前に決めてアラートを張る」もの。
• オブザーバビリティ（Observability）：想定外の異常が起きた時に、外から観測したデータだけで内部状態を推定して原因に到達できる性質。

たとえば「先週金曜の 21 時、特定ユーザーグループだけレスポンスが遅かった」みたいな話を、ログとメトリクスとトレースを行き来して 30 分以内に原因まで辿れるか。これがオブザーバビリティの本質です。

つまり、オブザーバビリティとは「障害時に原因へ到達する力」です。ツール選定はこの軸でやらないと、後で必ず痛い目を見ます。

まず結論 — ざっくり選定指針

長い記事になるので、最初に結論だけ書いておきます。

• AWS 中心・まず安く確実に始めたい → CloudWatch
• アプリ性能 / APM・ユーザー体験まで深く見たい → New Relic
• マルチクラウド / コンテナ多用 / 横断監視 / チーム運用を回したい → Datadog

この 3 択でだいたい片付きます。以下、その判断根拠を順に説明していきます。

比較表 — 観点別マトリクス

カタログ的になりますが、現場で議論する時の叩き台として置いておきます。あくまで「一般的な傾向」であり、最終判断は自社環境でやってください。

繰り返しますが、表だけ見て決めないでください。次以降の各論を必ず読んでから判断してください。

New Relic — アプリの中身まで追いたいなら本命

特徴

New Relic は APM の老舗で、コードレベルでのトランザクション分析が他より一段深いです。エージェントをアプリに入れると、「どのエンドポイントのどの SQL が遅いか」「どの N+1 で詰まっているか」みたいなのが即座に見えます。

データはすべて NRDB という独自テレメトリ DB に集約され、NRQL（SQL ライクなクエリ言語）で横断的に検索できます。これが慣れると恐ろしく強力です。

強み

• APM / トレースが深い。アプリチームが原因切り分けに使うなら一番ハマる
• NRQL による横断検索。メトリクスもログもトレースも同じ言語で叩ける
• 料金体系がデータ取り込み量＋ユーザー数でシンプル（後述の通り取り込み量管理は要注意）
• RUM / Browser / Mobile / Synthetics まで一気通貫で揃う

弱み

• NRQL の学習コストが地味に高い。最初の数週間はチームの誰かが詰まる
• インフラ・コンテナ系の運用機能は Datadog に一歩譲る印象
• 取り込みデータ量が増えると一気にコストが伸びる。後述のコスト失敗パターンに直結する

向いているケース

• Web アプリや API のレスポンス品質を最優先で改善したい
• 開発チームが性能改善に直接コミットする文化がある
• AWS も GCP もオンプレも、とにかくアプリの中身を見たい

向いていないケース

• 純粋にインフラだけ見たい、アプリには手を入れない
• Kubernetes 上で数百ホスト動いていて、ホスト / コンテナの可視化が主目的

Datadog — マルチクラウド・コンテナ運用の本命

特徴

Datadog は「インフラ監視 SaaS の定番」から始まって、APM、ログ、RUM、セキュリティまで全部乗せに進化したプラットフォームです。統合数が異常に多く、AWS / GCP / Azure / Kubernetes / 各種ミドルウェアまで対応しています。

特に Kubernetes / コンテナ環境での運用機能は頭ひとつ抜けていて、Container Map や Live Container でホスト・Pod・コンテナをリアルタイムで把握できます。

強み

• マルチクラウド・コンテナで一番強い。EKS / GKE / AKS を跨いでも統一して見られる
• ダッシュボード / Monitor が直感的。UI で触って覚えられる
• インテグレーションの数が圧倒的。とりあえず繋げば見える、が成立しやすい
• チーム運用機能（Incidents、Notebooks、SLO）が成熟していて、組織で回せる

弱み

• コスト構造が複雑。Infra / APM / Logs / RUM…と機能別にホスト課金やインデックス課金が積み上がる
• ホスト数が増えるとリニアに高くなる。スケールアウトが多い構成だと予算管理が難しい
• カスタムメトリクスの高カーディナリティで爆発しがち

向いているケース

• Kubernetes でマイクロサービスを多数動かしている
• マルチクラウド、あるいはオンプレ＋クラウドのハイブリッド
• 運用チームが独立していて、SRE が主導で監視を組み立てる
• インシデント運用のオペレーションごと整備したい

向いていないケース

• 監視対象が小規模で、コスト最優先
• AWS 単一クラウドで、AWS Native 機能で十分間に合うケース

AWS CloudWatch — AWS オンリーなら最初の選択肢

特徴

AWS がネイティブで提供する監視サービス群です。CloudWatch Metrics / Logs / Logs Insights / Alarms / Dashboards / Synthetics / RUM / Container Insights / Application Signals…と機能はかなり広い。

最大の強みは AWS サービスとの統合がゼロコンフィグに近いこと。EC2、RDS、Lambda、ECS、ALB あたりは何もしなくてもメトリクスが飛んできます。

強み

• AWS 統合がネイティブ。IAM ロールベースで他 SaaS のような外部連携設定が要らない
• 既存の AWS 請求にまとめられる。稟議が通りやすい
• Logs Insights が意外と強力。最近は SQL 構文にも対応
• Application Signals で APM 相当の機能も提供されている（成熟度は New Relic / Datadog に比べるとまだ追いつき中）
• データを社外に出さない。コンプライアンス要件が厳しい現場で楽

弱み

• マルチクラウドや非 AWS サーバには弱い
• UI と UX が SaaS 勢に比べて素朴。ダッシュボード作り込みは手間
• アラートのロジック表現が固い（Metric Math、Composite Alarm で頑張る必要あり）
• 長期保持のログコストが地味に重い

向いているケース

• 100% AWS で構成されている
• まず最低限の監視を低コストで立ち上げたい
• データを外部 SaaS に送りたくない（金融・医療・公共系）
• まだチームが小さく、専任の監視担当がいない

向いていないケース

• 「アプリ性能改善」をデータドリブンで本気でやりたい
• マルチクラウド、ハイブリッド構成
• チーム横断で運用を統一したい

実装パターン比較 — 現実的な 4 つの組み合わせ

3 ツールの「どれか 1 つ」を選ぶ必要はなく、組み合わせるのが実務では普通です。代表的なパターンを 4 つ挙げます。

パターン 1：CloudWatch 中心の AWS ネイティブ監視

• 構成：CloudWatch Metrics + Logs + Alarms + Dashboards、必要に応じて X-Ray と Application Signals
• 向き：AWS オンリー、小〜中規模、コスト最優先
• メリット：立ち上げが速い、AWS 請求に統合、社外データ送信なし
• デメリット：UI の作り込みが大変、アプリ深部の可視化が弱い

「とりあえず監視を始める」段階の現場では、まずこれで十分です。 ここから不足を感じたら次のパターンへ進む、というのが王道。

パターン 2：CloudWatch + New Relic / Datadog 連携

• 構成：CloudWatch は AWS サービスメトリクスとログの収集基盤、SaaS 側で可視化・アラート・APM
• 向き：AWS 中心だがアプリ性能やトレースも深く見たい
• メリット：既存の CloudWatch を捨てずに段階移行できる
• デメリット：二重課金になりがち、データの重複に注意

CloudWatch Metric Stream や Kinesis Firehose 経由で SaaS に流すと、エージェント未導入の AWS サービスのメトリクスも一気に揃います。実務では一番採用されているパターンです。

パターン 3：SaaS 側を主、CloudWatch はイベント / ログ基盤として最小利用

• 構成：New Relic か Datadog を主軸、CloudWatch は「AWS が勝手に吐くログの一時バッファ」として割り切る
• 向き：マルチクラウド、コンテナ多用、運用を一元化したい
• メリット：SaaS 側の UI とアラートで統一できる、SRE の認知負荷が下がる
• デメリット：SaaS 側のコストが青天井になりやすい。取り込み量と保持期間の設計が命

パターン 4：小さく始めて段階的に拡張するパターン【推奨】

実は多くの現場でこれが現実解です。

1. まず CloudWatch で基本メトリクスとログ
2. APM が必要になったら New Relic（または Datadog APM）を本番アプリに導入
3. コンテナ運用が増えてきたら Datadog で Kubernetes 可視化
4. RUM が必要になったら SaaS 側を追加

「最初から完璧な構成を組まない」のがポイント。オブザーバビリティは育てるものです。

選定フローチャート風の判断ガイド

質問に上から順に答えていけば、たどり着ける場所が決まります。

• Q1. 監視対象は 100% AWS か？
  • YES → Q2 へ
  • NO（マルチクラウド・オンプレ含む） → Datadog or New Relic（コンテナ多用なら Datadog 寄り）
• Q2. アプリのコード深くまで見たいか？（APM / トレース重視）
  • YES → New Relic（CloudWatch 併用） がよい
  • NO → Q3 へ
• Q3. データを外部 SaaS に送れるか？（コンプライアンス的に）
  • 送れない → CloudWatch で完結（X-Ray + Application Signals まで使う）
  • 送れる → Q4 へ
• Q4. 専任の SRE / 監視チームはいるか？
  • いる → Datadog（運用機能を活かせる）
  • いない → CloudWatch + 必要な部分だけ SaaS（小さく始める）
• Q5. Kubernetes / ECS でコンテナを大量に動かしているか？
  • YES → Datadog が最も馴染む
  • NO → New Relic または CloudWatch で十分なケースが多い

これだけで 9 割の現場は答えが出ます。残り 1 割は「組織の好み」と「過去の負債」で決まる、というのが正直なところです。

ありがちな失敗 — 現場で本当に見た 5 パターン

ここが基礎編で一番大事です。ツール選定よりも、運用設計の失敗の方が圧倒的に多い。

失敗 1：とりあえず全部送ってコスト爆発

「データを送らなければ意味がない」と思って DEBUG ログから高カーディナリティのカスタムメトリクスまで全部 SaaS に送る と、月末の請求で経営に呼び出されます。

• 対策：取り込み前にフィルタする。CloudWatch Logs から不要なログを除外、メトリクスのディメンション数を制限、サンプリングを入れる
• 判断軸：「これは障害調査で本当に見るか？」と自問する

失敗 2：ログだけ集めてトレースがない

ログ基盤だけ立派になって、「で、この API が遅い原因はどこから来てるんですか？」が分からないパターン。マイクロサービス化したらトレースは必須です。

• 対策：OpenTelemetry を最初から入れる。ログだけのフェーズで止まらない
• 判断軸：サービス間呼び出しが 3 層以上あるなら分散トレーシングは前提

失敗 3：アラートが多すぎて誰も見ない

アラート疲れ。これは 100% 発生すると言ってよい問題で、対策しないと監視チーム全員が壊れます。

• 対策：SLO / SLI ベースでアラートを再設計する。「ユーザー影響があるもの」だけ PagerDuty / Slack に飛ばす
• 判断軸：1 日 10 件以上アラートが出ているなら、もうそれは情報ではなくノイズです

失敗 4：ダッシュボードを作って満足する

「立派なダッシュボードができました」で終わり、誰も見ない。よくある。

• 対策：ダッシュボードは「障害時の調査導線」として設計する。トップ画面から原因まで 3 クリックで辿れるか
• 判断軸：そのダッシュボードを、深夜の障害対応で 5 分以内に使えるか

失敗 5：本番障害時の調査導線が決まっていない

これが一番痛い失敗。ツールはあるのに、いざ障害が起きると誰がどこから見るか決まっていない。

• 対策：ランブック（playbook）を書く。「5xx 急増 → このダッシュボード → このログクエリ → このトレース」と手順化
• 判断軸：ランブックがなければオブザーバビリティはまだ完成していません

コストで気をつけるべき 4 つの変動要因

具体的な金額は省きますが（料金体系は頻繁に変わります）、どのツールでもコストはこの 4 つに連動して増減します。

1. データ量（Ingest）：1 日に取り込むログ・メトリクス・トレースのバイト数。圧倒的に支配的
2. ホスト数 / コンテナ数：Datadog 型のホスト課金に効く。スケールアウト系の現場で爆発しがち
3. 保持期間（Retention）：ログを何日残すか。90 日と 13 か月で桁が変わる
4. カーディナリティ：メトリクスのタグ組み合わせ数。user_id をタグにすると即終了

「とりあえず全部送って、長期保持して、細かくタグ付けする」をやると、どのツールでも破綻します。この 4 軸で取捨選択するのが、コスト管理の本質です。

基礎編としての結論 — まず観測対象を決めよ

ここまで長々と書きましたが、基礎編の結論は以下です。

1. まず「何を観測したいか」を決める。SLI / SLO から逆算する。ツール選定はその後
2. メトリクス / ログ / トレース / APM / RUM の責務を分ける。1 ツールで全部やろうとせず、テレメトリ種別ごとに最適解を考える
3. 小さく始めて、不足を感じたら拡張する。最初から完璧な構成を組もうとしない
4. コストは「データ量・ホスト数・保持期間・カーディナリティ」の 4 軸で管理する
5. ツールよりランブック（調査導線）が大事。これがないとツールが揃っても障害は止まらない

そして、最初のツールを選ぶときの実用的な目安は以下です。

• AWS オンリーで小規模・コスト最優先 → CloudWatch で始める
• アプリの性能改善を本気でやる → New Relic を足す
• コンテナ・マルチクラウド・チーム運用 → Datadog に寄せる

迷ったら CloudWatch で始めて、不足を感じたところから New Relic か Datadog を足す、これでだいたい間違えません。

次回予告：実践編

次回は 実践編として、Terraform で CloudWatch / New Relic / Datadog 連携を書きます。

• CloudWatch Metric Stream → Kinesis Firehose → New Relic / Datadog の構成
• New Relic AWS Integration の最小 Terraform
• Datadog AWS Integration の最小 Terraform
• ログのフィルタリングとサンプリングの実装例

「現場で動かすコード」だけ書くので、次回もぜひ。

まとめ

• オブザーバビリティとは「障害時に原因へ到達する力」。監視とは別物
• New Relic / Datadog / CloudWatch は比較表で選ぶものではなく、AWS 依存度・アプリ深度・チーム体制で選ぶ
• 実務では複数併用が普通。小さく始めて段階的に拡張するのが王道
• コストは「データ量・ホスト数・保持期間・カーディナリティ」の 4 軸で管理する
• ツール選定よりも、ランブック整備とアラート設計の方が成果に効く

「うちはまず CloudWatch で始めて、APM が必要になったら New Relic を足そう」とか、「Kubernetes を本格運用するから Datadog に寄せよう」とか、読後に方針が決まることを目指して書きました。

次回の実践編で、コードに落としていきます。

関連キーワード

• オブザーバビリティ（Observability）
• New Relic / NRQL / NRDB
• Datadog / APM / Container Map
• AWS CloudWatch / Application Signals / X-Ray
• OpenTelemetry
• SLI / SLO
• 分散トレーシング
• Kubernetes 監視
• マルチクラウド監視
• ランブック / インシデント運用