プロダクト横断の監視統合で開発者体験を向上させた Datadog 活用事例

参考になった

レビュー投稿日の情報になります

株式会社ヌーラボ / Yuki Yoshiiwa

テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 101名〜300名

最終更新日2026/02/03投稿日2026/02/10

利用プラン

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

Enterprise

Bits AI SRE Agent / Dashboards / Notebooks / Monitoring (Monitors, SLOs, Event Management, Watchdog, External Provider Status) / Incident Response (On-Call, Incident Management) / Internal Developer Portal (Software Catalog, Teams) / Infrastructure (Hosts, Serverless, Kubernetes Explorer, ECS Explorer) / Cloud Cost Management / APM (Traces, Profiler) / Synthetic Monitoring / Security (Cloud SIEM, Cloud Security Management, App & API Protection) / Logs

101名〜300名

2025年3月

B to B

B to C

利用プラン	Enterprise
利用機能	Bits AI SRE Agent / Dashboards / Notebooks / Monitoring (Monitors, SLOs, Event Management, Watchdog, External Provider Status) / Incident Response (On-Call, Incident Management) / Internal Developer Portal (Software Catalog, Teams) / Infrastructure (Hosts, Serverless, Kubernetes Explorer, ECS Explorer) / Cloud Cost Management / APM (Traces, Profiler) / Synthetic Monitoring / Security (Cloud SIEM, Cloud Security Management, App & API Protection) / Logs
ツールの利用規模	101名〜300名
ツールの利用開始時期	2025年3月
事業形態	B to B B to C

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

ヌーラボでは、Backlog や Cacoo といったプロダクトを提供していますが、プロダクトごとに監視の手法やインシデント対応のやり方が大きく異なり、これが「見えない壁」となって開発者体験とオブザーバビリティを阻害していました。

監視ツールの断片化

Prometheus、Grafana、CloudWatch、OpenSearch、Zipkin、SaaS など複数の監視ツールがプロダクトごとに独立して運用されていました。これにより、システム全体の健全性を一元的に把握することが困難で、インフラとアプリケーション間のデータ相関分析が容易にできない状況でした。これは、Dev と Ops の間に壁を作る要因でもありました。また、特定のツールに関する知識が、特定の個人に偏る属人化が進行していました。

SRE / SWE の負担増大

運用負荷: 複数ツールの維持・管理（アップデート、設定変更、各ツールの障害対応など）が SRE の大きな負担になっていました。これは、価値創造に直結しない活動に対する大きな運用コストとなっていました。
認知負荷: 新規メンバーのオンボーディング時に多種多様なツールの使い方を習得する必要がありました。これにより、学習曲線が急峻になり、人材の流動性低下や生産性への悪影響が出ていました。

インシデント解決の遅延

MTTR の悪化: 障害発生時に複数の監視ツールを個別に確認し、情報を手動で突き合わせる必要がありました。これは、インシデント対応というストレスの高い場面で頻繁なコンテキストスイッチを必要とし、バーンアウトのリスクとなっていました。
事後対応的な運用: オブザーバビリティが不十分で、潜在的な問題を事前に特定することが困難でした。

どのような状態を目指していたか

監視ツールの統合により、以下の状態を目指していました。

監視情報の一元化による運用効率化： 複数ツールを使い分ける手間をなくしたり、テレメトリーデータのサイロ化を解消することで、SRE が本来取り組むべき信頼性の向上活動や、SWE がプロダクトの課題解決および価値創造に集中できる環境を目指しました。
認知負荷軽減による開発者体験の向上： 誰でも特別なトレーニングなしに利用を開始でき、必要な情報を迅速に取得・活用できる状態と、複数のツールを横断調査する時間を削減し、本来の開発業務に集中できる時間を増やすことを目指しました。
オブザーバビリティの民主化と DevOps 文化の醸成： SWE と SRE が共通の言語（同じダッシュボードや指標）で会話できる状態を作り、コミュニケーションとコラボレーションを促進することを目指しました。これは、SRE だけでなく全ての SWE が、システムの状態を把握し、自律的に問題解決できる組織文化への変革を意図していました。

比較検討したサービス

Datadog
New Relic
Mackerel
セルフホスト (Grafana LGTM スタックなど)

比較した軸

オブザーバビリティツールの選定にあたり、ツールの断片化による組織的課題を解決するために、4つの評価軸を設定しました。これらの評価軸に基づき、比較したサービスについてそれぞれ2週間〜1ヶ月のトライアルを実施しました。トライアル実施後に参加者へアンケートを実施し、定量的・定性的な評価を収集しました。

1. オブザーバビリティの民主化

経験の浅いメンバーでも、ツールの UI や機能を活用して問題を解決できるか。ドキュメントやコミュニティは問題解決に役立つか。チーム全体のオブザーバビリティに関する知識を向上させられるか。

2. MTTR の短縮

インシデントを含む問題の発生時に、問題の原因を迅速に特定できるか。実際に MTTR を短縮できるか。

3. 効果的な DevOps 文化の醸成

開発チームと運用チーム間のコミュニケーションを促進できるか。ダッシュボードやグラフは、チーム全体で共通の状況認識を持つ上で役立つか。

4. 開発生産性の向上

トレースやプロファイリングなどの開発サポート機能は、開発効率の向上に役立つか。デバッグにかかる時間を短縮できるか。

選定理由

1. トライアルにおける高い満足度

社内トライアルの結果、Datadog の総合評価は5点満点中4.46点と高く評価されました。参加者からは「短期間でボトルネックを特定しやすくなった」「調査効率が向上した」といった声が多く寄せられました。

2. 直感的な UI と操作性

トライアル参加者の多くが「全体的に直感的な操作ができる」「複雑なクエリを書かずにデータを可視化できる」と評価しました。グラフのコピー&ペースト機能や、事前定義されたダッシュボードの豊富さも好評でした。誰にとっても使いやすいツールであることは、オブザーバビリティの民主化を目指す上で必須と考えます。

3. Go 言語の継続的プロファイリング対応

ヌーラボでは JVM 系の言語と Go 言語を多く利用しており、JVM / Go 対応の継続的プロファイラーがあると嬉しいと考えていました。Datadog は JVM / Go の継続的プロファイリングをサポートしており、トライアル中に継続的プロファイラーを用いてボトルネックを特定でき、大幅にパフォーマンスを改善することができました。この体験により、継続的プロファイラーは開発効率に強く寄与すると確信でき、決め手の1つとなりました。

4. 包括的な機能セットと統合力

メトリクス、ログ、トレース、プロファイルといったオブザーバビリティにおける 4 pillars をサポートする上、フロントエンドやコストのオブザーバビリティを高める機能も存在します。フルスタックオブザーバビリティに必要な機能を単一プラットフォームで提供している点を評価しました。また、ヌーラボのプロダクトの実行基盤として採用する AWS および Kubernetes との親和性が高く、豊富なインテグレーションがあり、AWS インテグレーションであれば数クリックで連携が完了する容易さも決め手になりました。

5. ドキュメントやコミュニティの充実度

日本語訳が丁寧であること、知識を深めやすいように動線が設計されていることから、ドキュメントが非常に読みやすく、サポートに頼らずとも独力で問題を解決しやすいです。JDDUG (Japan Datadog User Group) といったユーザーコミュニティが活発である点も悩みの共有が行えて良かったです。また、Learning Center などの自学コンテンツが充実していたり、ユーザーサポートの回答も早いので困る点がほとんどなかったです。

6. 機能開発のスピードと将来性

機能開発のスピードが非常に早く、Datadog Product Preview Program でプレビュー機能が多くリリースされています。このことから、将来的な技術進化への期待値において Datadog の優位性が高いと評価しています。

導入の成果

改善したかった課題はどれくらい解決されたか

監視ツールの分散解消

複数の監視ツールを Datadog に統合することで、情報のサイロ化が解消されつつあります。ログ、メトリクス、トレース、プロファイルを統合・一元化したことで、問題の全体像把握から根本原因特定までのプロセス効率化を実感しています。

認知負荷の軽減

Datadog の導入以前では、ログやアラートを確認する際には、どのツールを利用するか暗記しておく必要がありました。Datadog の導入により、とりあえず Datadog を見て調査できるようになり、認知負荷を軽減できました。システム構成を把握していない経験の浅いメンバーでも、Service Map やトレースを通じてシステム間の依存関係を視覚的に理解できるようになり、学習コストが下がりました。

インシデント対応の効率化

複数のシステムをまたぐリクエストの問題を、APM でドリルダウンして調査できるようになりました。内部通信で発生したエラーや、明示的にログを出力していない例外も Datadog から参照できるようになり、潜在的な問題に気づけるようになりました。また、関連するテレメトリーデータが自動で紐づくことで、調査の心理的ハードルが下がりました。

どのような成果が得られたか

Cloud Cost Management によるコスト最適化

複数の AWS アカウントを跨いだコスト分析とクイックな最適化により、AWS 費用の削減に寄与しました。削減自体も CCM の Recommendations を活用することで、短期間に実現でき、FinOps の取り組みを推進する上で必須の機能と感じます。

パフォーマンス改善の効率化

継続的プロファイラーのフレームグラフとコールグラフを活用し、ボトルネックの特定とパフォーマンス改善を短期間で実施できるようになりました。

技術的な課題解決への貢献

主要サービスのランタイムアップグレード（JDK アップグレードなど）時に、新旧環境のパフォーマンス（レイテンシやエラーレート）を APM でリアルタイムに比較・分析しました。これにより、潜在的なリグレッションを早期に検知・対処でき、自信を持って本番リリースを行うことができました。

開発者体験の向上

サービスに関するテレメトリーデータが一画面で見られることや、テレメトリーデータが期待通りに紐づいていることで掘り下げて調査しやすく、開発者体験の向上に寄与しています。また、週次ミーティングでのパフォーマンス分析において、以前はログ検索のクエリ待ち時間が長くストレスでしたが、Datadog のダッシュボードは高速に応答するため、分析や準備にかかる時間が大幅に短縮されました。

導入時の苦労・悩み

機能の豊富さゆえの戸惑い

Datadog は取り扱っているデータや機能が多いため、最初の1歩を踏み出すまでに手間取ることがありました。何をどう試せばよいか分からないという状況を避けるため、Datadog の導入推進者を中心にドキュメントを読み込んで使い倒し、勉強会を実施してつまづきを減らせるように工夫しました。また、いきなり全機能ではなく、「まずはここを触ればOK」というガイドラインを整備したり、ベンダートレーニングを活用してハンズオンセッションを開催したりすることで、段階的に習熟度を上げました。

価格体系の複雑さ

Datadog の料金表は機能ごとに細かく分かれており、コストを正確に見積もるのが難しかったです。数量の算定に必要なコマンドを配布し、各プロダクトの SRE に実行してもらった結果を精査するという泥臭い手法を取りました。実際に導入を進めると、AWS インテグレーションにより CloudWatch の GetMetricData API の利用料が増えるという点で、インテグレーションの隠れたコストがわかりました。AWS インテグレーションの設定を必要なリソースやリージョンに絞るといった最適化の対応が必要となりました。

導入に向けた社内への説明

上長・チームへの説明

ADR（Architecture Decision Records）を活用した透明な意思決定

ヌーラボでは ADR を活用して意思決定プロセスを記録・共有しています。オブザーバビリティツールの選定においても、トライアル対象ツールの絞り込み、最終的な導入ツールの決定という2つの ADR を作成し、決定プロセスと理由を記録・公開することで、組織全体の納得感を醸成しました。

費用対効果の説明

運用コスト削減: 現状の監視ツール群を改善しフルスタックオブザーバビリティを実現するためには3〜5人の高スキルメンバーが必要と判断しており、SaaS ツールに役割を担ってもらうことでこの工数を削減できると説明しました。
- 高スキルメンバーがより本質的な仕事に向き合えるようになれば、価値創造を阻害するような複雑なシステムの改善といった、重要性の高い業務に人を割けるようになります。
- 特に、小規模の開発組織でフルスタックオブザーバビリティツールを運用することは、短期的には安く済むというコストメリットはあれど、長期的には属人化の進行やテレメトリーデータの肥大化によるコスト上昇といった弊害を生み、結果的に高くつくと感じています。
生産性向上: ツールの分散によるコミュニケーションコストの軽減、APM 導入によるソフトウェアパフォーマンス改善の効率化、全社員へのアカウント発行による「全員が同じものを見て話せる」環境の実現といったことで、組織全体のフロー効率の向上に寄与すると説明しました。
退職リスクの軽減: セルフホストだと属人化されやすいため、SaaS ツール利用によりツール維持の懸念を解消

意思決定会議の実施

関係各部門（SRE、開発チーム、マネージャー層）を集めた意思決定会議を開催し、トライアル結果、アンケート結果、評価の比較資料を共有しました。参加者全員での議論を経て、コンセンサスに基づいて Datadog の導入を決定しました。

トライアル結果の活用

トライアル参加者によるアンケート結果を根拠として提示しました。定量的な満足度評価だけでなく、「APM によって複数サービスの関連が可視化された」といった開発チームの課題が解決された例も共有しました。

活用方法

インシデント対応: Service Page でレイテンシーやエラー率を一覧し、異常があれば APM トレースへドリルダウンして根本原因（特定の SQL クエリや外部 API 呼び出しなど）を特定し、サービス復旧時間の短縮に役立てています。
パフォーマンス分析: ダッシュボードで定期的にパフォーマンス指標をチェックしています。継続的プロファイラーでボトルネックを特定し、改善しています。
コスト最適化: Cloud Cost Management で AWS コストを可視化し、最適化の機会を特定し、改善しています。
リリース時の影響確認: デプロイ後のパフォーマンス変化を APM とメトリクスで確認し、リグレッションの有無を確認しています。

よく使う機能

Infrastructure Monitoring: EC2、EKS (Kubernetes)、ECS (Fargate) のリソース監視
APM: 分散トレーシングによるリクエスト追跡、Service Map による依存関係の可視化
Log Management: アプリケーションログの収集・検索・分析（開発環境3日、本番環境15日保持）
Cloud Cost Management: AWSコストの可視化と最適化推奨（Recommendations）の活用。Kubernetesのコスト配賦
Synthetic Monitoring: APIテストによる外部からの生存監視
Watchdog & Error Tracking: 設定不要で異常を検知する機能（Watchdog）や、エラーの自動グルーピング（Error Tracking）によるノイズ削減

ツールの良い点

直感的な操作性

全体的に直感的な操作ができます。グラフをコピーし自分のダッシュボードにペーストして編集できるような直感的な操作性は、ツールの習熟にかかる学習コストを低減してくれたと感じます。

充実したドキュメント

ドキュメントが網羅的に書かれており、ほぼ独力で Datadog に関する問題を解決できます。また、Datadog MCP サーバーの `search_datadog_docs` ツールを用いることで、任意のコーディングエージェントから最新のドキュメントを引ける点も良いです。

事前定義されたダッシュボードの豊富さ

インテグレーションを有効にすると、すぐにダッシュボードが利用可能な点は良いです。また、前述したグラフのコピー&ペーストは、Datadog 側で用意されたダッシュボードについても有効であり、サービスごとのダッシュボードを非常に作りやすいです。

テレメトリーデータをすべて送れる点

Datadog では Ingest の料金が非常に安く設定されているため、とりあえず Datadog にすべてのテレメトリーデータを送ることができます。その後、Metrics without Limits などの機能を用いてメトリクスのカーディナリティを下げたり、ポリシーに応じて保存するテレメトリーデータを取捨選択できるため、送る側で考えることが少ない点が魅力です。 Datadog 導入以前は OpenTelemetry Collector から AWS X-Ray にトレースを送信していましたが、コスト最適化のためにコレクター側の Tail Sampling Processor で絞る必要があり、苦労していました。

ツールの課題点

価格体系の複雑さ

機能の豊富さゆえに料金表が複雑で、コストの見積もりに時間がかかります。コスト管理には利用状況のモニタリングとアラート設定が必須です。また、標準インテグレーションに含まれないメトリクス（自分で定義したサービス固有のメトリクスなど）はカスタムメトリクスとして課金対象になり、コストも嵩みやすいため、以下のような対応が必要な点もコスト管理の難しさにつながっています。

標準インテグレーションに含まれるメトリクスの場合: 標準インテグレーションに置き換える
カーディナリティが高いメトリクスの場合: Metrics without Limits で適切なカーディナリティを設定する

ヌーラボでは、コストのアノマリーモニターを設定したり、月1に Datadog 担当者とのコストレビュー会を実施したりして、予定外の大きなコストが発生しないように気をつけています。

機能の多さによる学習コスト そもそもの機能が多い上、機能追加の速度が早いため、学習コストはそれなりに高いです。使い始めればすぐに慣れる範囲ではあるため、学習コストは充分に許容できる範囲と考えています。とはいえ、初学者にとって学習が難しいという面はあるため、Datadog の推進者がバーチャルチームを組み、日常的な困りごとの解決やガイドラインの充実といった支援体制を組んでいます。

ツールを検討されている方へ

1. トライアルを必ず実施する

実際に自社のサービスでトライアルを行い、現場の SRE / SWE からフィードバックを収集することが重要です。機能比較だけでなく、「使いやすさ」「問題解決への貢献」を評価軸に含めることをおすすめします。

2. Datadog チャンピオンを設置する

導入を成功させるには、推進者（チャンピオン）の存在が不可欠です。事前にドキュメントを徹底的に読み込み、トライアル中の問い合わせに迅速に対応できる体制を構築しましょう。

3. 目的と評価軸を明確にする

「何のために導入するのか」を明確にし、評価軸を事前に定義することで、トライアルの方向性やツールの導入目的が定まり、納得感のある意思決定につながります。

4. 段階的に導入する

いきなり大規模ではなく、限定的な範囲からスタートし、小さな成功体験を積み重ねることで、全社展開への自信と組織全体の納得感を醸成できます。

5. コミュニティに参加する

ユーザーコミュニティ主催のミートアップが活発に開催されています。私たちも導入初期から参加しており、新しい機能のキャッチアップや、他社事例を知るのに非常に役立ちました。

今後の展望

Datadog への継続投資により、以下の3つの領域で活用を拡大していく予定です。現在は開発チームを中心として Datadog を見ていますが、ビジネスサイドも巻き込んで、全社員が同じものを見て会話できるようにしていきたいと考えています。

1. Full-Stack Observability

RUM の導入により、フロントエンドからバックエンドまでトレースが繋がる環境を構築します。現状、フロントエンドのエラー情報やトレースは取得できておらず、ユーザーが体験する問題の原因特定が困難でした。RUM によりフロントエンドエラーからバックエンドのトレース、インフラメトリクスまでシームレスに調査できるようになり、ユーザー体験に影響する問題の根本原因を迅速に特定できるようになります。また、Product Analytics を活用し、プロダクトマネジメントチームとの連携も視野に入れています。

2. Autonomous Operation

SLO ベースのアラート戦略を全社展開し、本当に重要な問題に集中できる環境を整備します。現在利用している PagerDuty から Datadog On-Call への移行により、オブザーバビリティとインシデント管理を単一プラットフォームに統合し、運用の複雑性を削減します。また、Bits AI SRE Agent の導入により、AI が根本原因分析を支援し、SWE は調査作業から解放され、より価値の高い活動に時間を使える状態を目指します。Kubernetes Autoscaling による自動リソース最適化 (Rightsizing) も進め、エンジニアが手動でのリソース調整から解放される環境を構築します。