この投稿は Datadog Advent Calendar 2025シーズン2の9日目の記事です🐶
はじめに
みなさんの組織ではどのようにDatadogを活用していますか？
株式会社グロービスのデジタルプラットフォーム部門（以下、GDP）では、プロダクトのオブザーバビリティ関連をDatadogに一元集約し、ダッシュボード、モニター、APMなどを利用しています。
個別のメトリクスやダッシュボードに並ぶ客観的な数値から深いインサイトを得るのは意外と難しく、常々そう感じていた最中、Datadog MCPに出会いました。「これを使えば、データから新しい気づきが得られるのでは？」という期待を込めて、プロダクトチームとSREが共同で素振り会を開催しました。
本記事では、その実践内容と得られた気づきをご紹介します。
前提
Datadog MCPとは
MCP（Model Context Protocol）は、LLMアプリケーションが外部データソースやツールと連携するための標準化されたプロトコルです。Anthropic社が提唱しており、Claude CodeなどのAIアシスタントから統一されたインターフェースで様々なサービスにアクセスできます。
Datadog MCPは、このMCPを活用してDatadogのメトリクス、ログ、ダッシュボード情報にアクセスするツールです。Claude Codeなどから直接Datadogのデータを問い合わせると、AIがデータを解釈して洞察を提供してくれます。
従来は「ダッシュボードやログ、メトリクスを開いてグラフを見て、自分で解釈する」というプロセスでした。しかし、Datadog MCPを使えば「AIに問いかけて、データの意味を一緒に考える」という新しいアプローチが可能になります。
グロービスGDP SREの目指す方向性
SREが所属するグロービスGDPでは、部門内で複数のプロダクトを展開しており、それぞれが独立したチームで開発・運用を行っています。
一方、SREチームは1チームのみのため、SRE業務をすべてSREが担当すると組織のボトルネックになってしまいます。
そのため、各プロダクトチームが主体的にプロダクトの改善を進められるよう、SREプラクティスとPlatform SREが開発する共通基盤・仕組みを、各チームの状況に合わせて適用するサポートを行っています。
素振り会の実施
「どの程度のことを、どの程度の精度で実現できるのか？」「現在の運用の中で、どのようなケースで役立つのか？」こうした勘所を探ることを目的に、プロダクトチームとSREでハンズオン形式の会を企画しました。また、プロダクトチームごとに関心事が異なるため、チームごとに個別に開催しました。
ディスカッションを通じた試行錯誤
画面共有をしながらハンズオン形式で進めました。プロダクトチームが普段どのようにDatadogを使っているのか、何に興味があるのかをディスカッションしながら試行錯誤しました。
プロダクトごとに扱うトピックは異なりましたが、例えば以下のような問いを投げました。
- 特定プロダクト（product:foo）に紐づくAWS WAFについて、過去N日間のBlockログをまとめてください
- 特定プロダクト（product:foo）の既存のモニターに加えて、追加したほうがよい監視観点について教えてください
- 特定モニターについて、過去N日間の傾向と改善ポイントを教えてください
- 特定APMについて、過去N日間の傾向とその原因となりそうな点について教えてください
最初のうちは、プロンプトの出し方に戸惑うこともありました。「どう聞けば欲しい情報が得られるのか」を参加者で議論しながら、徐々にコツをつかんでいきました。
また、AIが返してくれた解釈に対して「これは本当にそうなのか？」「別の見方もできるのでは？」といったディスカッションが生まれました。ダッシュボードやメトリクスを眺めるだけでは出てこなかった会話が、AIの解釈をきっかけに活発になりました。
プロダクトチームに画面シェアをしてもらい、一緒にわいわいしました。
素振りした一例として、APMの分析をしてみました。利用するAIモデルに依存する部分は大きいと思いますが、想像していたよりも具体的にアドバイスをしてくれました。
Datadog MCPを使って、[APMトレースID]のAPMトレースを調べて
Datadog APM トレース分析:
📊 全体概要
対象Mutation: xxxxxxxx.graphql
調査期間: 過去1時間
サンプルトレース数: 45件（一部サンプリング）
⏱️ パフォーマンス統計
取得した22件のサンプルトレースから:
- 最速: xxms
- 最遅: xxxxms
- 典型的な範囲: xxx-xxxms
- 中央値付近: 約xxxms
🔍 詳細トレース分析 (Trace ID: xxxxxxx)
このトレースは xxxms で完了し、xxxx個のspanで構成されています:
リクエストフロー
1. Rack Request (xxxms)
- HTTPエンドポイント: POST /graphql
- サービス: fooooo
- ステータス: 200 OK
2. GraphQL Controller (xxxms)
- コントローラー: HooBar
- DB実行時間: xxxms
- View実行時間: xms
3. GraphQL XXXXXX XXXX (xxxms)
- リソース: xxxxxxxx
主要なデータベースクエリパターン
トレースから確認できる繰り返しクエリ:
1. xxxの取得:
# SQLが表示される
2. xxxの取得:
# SQLが表示される
⚠️ パフォーマンスの懸念点
1. N+1クエリの可能性
2. DBクエリキャッシュへの依存
- キャッシュミス時は大幅に遅延 (xxxms)
💡 推奨事項
1. クエリの最適化
- 選択肢データを一括取得
2. バッチ処理の検討
- 複数の問題の回答を一度に処理
3. データベースインデックスの確認
- xxxxxxテーブルのJOINに対するインデックス
得られた気づき・インサイト
ハンズオン会とアンケートを通じて、多くの気づきを得られました。
一緒に手を動かすことの重要性
ゆるふわな雰囲気で参加しやすかった
ハンズオン形式が良かった（情報提供だけでは後手に回りがち）
日常的に使わない技術領域に手を伸ばすには、きっかけが必要です。「とりあえず一緒に触ってみよう！」と誘うことで、その最初の一歩を後押しできると感じました。
使い始めるきっかけになり、意外と使えそうなことがわかった
Datadogに関することはDatadog MCP使ってみようかなーというざっくりとしたイメージを持った
一度手を動かすことで、次回以降の心理的ハードルが下がったと感じます。
プロダクトチームにとってのDatadogのメリットを布教することの重要性
Datadog自体の理解が足りず、アラート内容を貼り付けて聞く程度の活用しかできなさそう
Datadogの利用頻度が低い人は一定数存在しており、そうした人にはDatadogを活用するメリットを伝え、実感してもらう施策が必要だと感じました。
一般論ですが、単に「これは便利だから使ってください」では人はなかなか動いてくれません。利用者が「自分にとってどのようなケースで、どう役に立つのか」をイメージでき、かつその使用感を理解していないと、自発的な利用にはつながりにくいと思います。
今後の施策では、プロダクトチームが自分事としてメリットをイメージできる水準を目指して伝えるよう心がけようと思います。
AIの回答精度
AIがそれっぽいサマリーを返してくるが、ハルシネーションの可能性が心配。
ハルシネーションであるかの検証するためのコストが掛かりそう...
AI活用において避けられない課題の一つが、AIのハルシネーションです。
会の中で決定的な解決策は見つかりませんでしたが、以下のような検証方法が議論に挙がりました。
- Datadog Notebookにアップロードできる形で出力し、Notebookで検証する
- Notebook化に適したQueryを生成してもらうには工夫が必要そう...
- AIが思考過程で作成したQueryを使って検証する
- 結局、集計作業は自分で行う必要があり手間がかかる...
チームを超えた共通認識の構築
この会を通じて、チーム間のコミュニケーションが活性化しました。
プロダクトチームとSREは密に連携していますが、コミュニケーションのきっかけは課題やプロジェクト駆動になりがちです。そのため、SREが普段見ている視点と、プロダクトチームが気にするポイントは微妙に異なります。
今回のようなゆるっとしたトピックでの素振り会を通して、それぞれの視点から「こういうことも聞いてみたい」「こういうことができると開発効率が上がって嬉しいかも！？」という提案が出て、多角的にデータを見ることができました。
また、AIの解釈に対して「実はこういう背景があって…」とプロダクト側から補足が入ることもあり、データと現場の知見を組み合わせた深い理解につながりました。
まとめ
今回の素振り会を通じて、Datadog MCPは単なるデータ取得ツールではなく、データから気づきを得るきっかけになることを実感しました。
従来、Datadogのクエリやダッシュボードのカスタマイズには習熟が必要でした。しかし、自然言語で問いかけられることで、プロダクトチームも気軽にデータを探索できるようになりました。これは、オブザーバビリティの民主化につながる可能性を感じます。
もちろん、AIの解釈がすべて正しいわけではなく、最終的な判断は人間が行う必要があります。しかし、「問いかける」「仮説を立てる」「検証する」というサイクルを回すきっかけとして、非常に有効だと感じました。
監視データは「見る」ものから「対話する」ものへ——Datadog MCPを通じて、オブザーバビリティの新しい可能性を感じた素振り会でした。
みなさんも、ぜひ組織のみんなでわいわい触ってみてください！
Discussion