2025/12/16 に開催された Datadog Live Tokyo に参加しました。
本記事では、公式レポートではなく、実際に現地で聞いた内容をもとに、

Datadog が描く AI × オブザーバビリティの未来像
国内企業による 具体的な活用・導入パターン
そこから見えてきた、今後の 実務レベルでの示唆

をまとめていきます。

1. オープニング

オープニングでは、Datadog Japan 合同会社日本法人社長の正井氏から、Datadog の成長とプロダクト戦略が共有されました。

顧客数：32,000社
売上：8.86 億ドル
Gartner レポートで マーケットシェア 1 位
S&P 500 採用企業

参考：Q3 2025 の公式発表
www.datadoghq.com

1-1. Datadog における 3 つの AI エージェント

Datadog は「AI 組み込み」を単なる付加機能ではなく、エージェント型 AI として位置づけていました。

Bits AI SRE
- アラートを自律的に調査し、自動対応 まで行う
- 調査・判断の過程が E2E でトレース可能
Dev Agent
- エラーの原因特定と 修正案の提案 を行う開発者向け AI
- Error Tracking Assistant などと連携し、デバッグの壁打ち相手になる
Bits AI Security Analyst
- SIEM のセキュリティイベントを自動調査
- 自律的トリアージにより、対応までのリードタイムを短縮

1-2. AI エージェントのロードマップ

Datadog が描く AI 活用のステップは、かなり明確でした。

Bits が 日常的なアラート対応 を支援
Bits が 複雑なインシデントに共同で対応
Bits が 運用全体を担う存在 になる

現時点では、1 と 2 の間にある「共同対応」フェーズにいる、という位置づけのようです。

1-3. 生成 AI 時代に向けた「AI オブザーバビリティ」とセキュリティ

生成 AI をプロダクトに組み込む企業向けに、Datadog は以下の価値を強調していました。

LLM パフォーマンス向上とコスト削減
品質・安全性・セキュリティリスクの低減
変更の確実なリリースと影響検証

特に「AI 時代のガードレール」というフレーズが印象的で、Datadog を 「監視ツール」から「AI 付き運用基盤」へ シフトさせたい意図を強く感じる内容でした。

2. 国内企業の事例(オブザーバビリティ定着のパターン)

ここからは、来場企業の事例セッションの中でも特に示唆が大きかったものをピックアップします。

2-1. 株式会社AbemaTV様

ABEMA の開発スピードと安定性を両立ー Datadog と描く O11y 戦略

サービス特性とスケール

FIFA ワールドカップ時：WAU 3,400 万
トラフィック：20 PB / Akamai 4.5 Tbps
トラフィックは数倍〜数十倍のスパイク
マイクロサービス：300+
開発エンジニア：約 100 名
デプロイ：1 日 50〜100 回

抱えていた課題

マイクロサービス化で構成が複雑化し、「どこから調べるか」すら分かりにくい
メトリクス / トレース / ログ / プロファイルが バラバラに存在
「このメトリクスなに？」「どこがボトルネック？」といった一次調査に時間がかかる

アプローチ：O11y 戦略と「民主化」

予算戦略
- AS-IS：インフラ費としての「絶対額」
- TO-BE：インフラの 7％を O11y 予算 として相対的に確保
オブザーバビリティの民主化
- 「見たい人が、見たいときに、見たいものを見られる」状態
- すべてのシグナルが Datadog 上でつながる ことを重視

導入プロセスでの工夫

アーリーアダプター制度で 先行導入チームを育てる
ハンズオン・勉強会、TEM プログラムの活用
社内ドキュメント整備、Slack での Tips 共有
MCP Server の共有 など、AI 連携の足場も整備

導入後の成果と今後

DAU（Datadog 利用者）：80％超
APM 利用サービス：100+
数百万メトリクスを Datadog に集約

今後は、

監視・検知だけでなく、障害対応〜改善までのフローを Datadog でカバー
Notebook / Case Management / On-Call / Incident Management の活用
AI for Observability（Bits AI Observability 等）前提で DevOps フローを再設計

といった方向を目指していました。

Note

ポイント：
導入そのものより、「どう使われるか」「どう文化にするか」にかなりの比重を置いているのが印象的でした。

2-2. DNP 大日本印刷株式会社様

DNP 現場主導で進める Datadog によるオブザーバビリティ定着化への道

背景：CCoE と Datadog 共通サービス

DNP グループ全体でクラウド活用を推進する CCoE 組織 が存在
マルチオーガナイゼーションで プロジェクト単位に Datadog を提供 していた
- 「提供しても使われない」という課題が顕在化

課題の捉え方

個別プロジェクトの問題ではなく、開発現場共通の課題 と定義し直した
- 運用と開発の垣根をなくす
- 品質担保とスピード両立
- システムオーナーとの関係性改善
- DevOps 実現

3 本柱の推進戦略

デフォルト化
- 「使いたいけど使えない」状態から
  「いつでも、どの環境でも使える」状態へ
- 運用フェーズだけでなく 開発・検証・本番すべてに Datadog
フレームワーク化
- Web システム開発用の 標準フレームワーク に Datadog を組み込み
- アプリ、IaC、ルール・ワークフロー、ドキュメントをセットで提供
社内コミュニティ
- 社内外の活用事例共有、新機能の使い方ディスカッション
- Datadog を「コミュニケーションのハブ」として位置づけ

段階的導入と IaC

Terraform でフレームワークをコード化し、段階的に機能を提供
1. クラウド標準監視 + Datadog APM
2. ＋ RUM / SIEM
3. ＋ログ / メトリクス
4. Datadog APM/RUM/SIEM/ログ/メトリクス/モニターフルセット
プロジェクト単位では
標準実装 + オプション + 個別対応 というレイヤー構成で柔軟性を確保

普及活動

社内 GameDay（クイズ形式）で Datadog の価値を体感してもらう
社内ミートアップで活用事例を共有
プロジェクトへの伴走支援 → 得た知見をフレームワークに還元

Note

ポイント：
「テンプレ＋コミュニティ＋伴走」の 3 点セットで、"使えるようにする" から "使われるようにする" までを設計しているのが非常に参考になりました。

2-3. 株式会社NTTドコモ様

ドコモのスマートライフ事業を支える Observability の取組み

スケール

年間リリース数：12,000
Datadog 利用システム：全体の 54％

特徴的な取り組み

BizDevOps を掲げ、障害が起きにくい設計と自動復旧を重視
Slack 上の 「マルチ部長エージェント」 で、質問に AI 幹部が回答
Datadog の LLM Observability を活用し、
コンポーネント間でリクエストを追跡

外形監視と Updog

https://updog.ai/ を活用し、AWS や SaaS の外形監視をリアルタイムに可視化
2025/11 の CDN 事業者障害発生時も、
- AWS 起因かそうでないかを 一目で切り分け可能だった とのこと
Down Detector が見られなかった（という噂）状況でも有効だった、というコメントもありました。

2-4. 株式会社SBI証券様

Datadog と歩む IT オペレーション効率化
3000 万口座を目指すシステム運用の挑戦と現在

スケール

システム数：250+
サーバ数：3,500 ホスト超
IT 部門従業員：750 名
AWS への全面移行中、すべてのシステムで Datadog を採用

導入ロードマップ

導入済み：外形監視（Synthetics）
対応中：監視ツール統合（Infra / Network / DB / Logs）と 顧客視点でのインシデント検知
着手：On-Call / Incident Management
未着手：Bits AI SRE など AI 自動診断

大規模インシデントの変化

導入前：
- チームごとに別々の監視ツール
- 他チームの監視情報が見えず、「誰が何を見ているか」すら不透明
導入後：
- Datadog を共通基盤にし、関係者全員が同じ情報を見ながら議論
- 原因仮説の立案が 圧倒的にスピーディに

On-Call 導入の効果

月間アラート：12,000 件
導入チーム：約 20 チーム / 60％
MTTA：11.5 分 → 1 分（85％削減）
通知件数：165 件/月 に集約

一方で、On-Call 機能の課題として

コールの Ack 機能がない（Datadog に相談中）
そのため、PagerDuty との比較でルーティング柔軟性に差分あり
発信元が海外番号になってしまう、という運用上の悩みも共有されていました。

Bits AI への期待

試験運用では
- アラートからの 自動調査〜原因仮説提示 がかなり有用という手応え
今後は
- APM / Logs の適用拡大
- サービス依存関係の整理
- イベント対応履歴の蓄積

といった 土台作りを先に進めてから本格適用 していく方針とのことでした。

2-5. 株式会社TimeTree様（TimeTree, Inc.）

7,000 万ユーザーの信頼を守る「TimeTree」のオブザーバビリティ実践

timetreeapp.com

サービス規模と技術スタック

ユーザー数：7,000 万
14 言語対応
メインは GCP（元 AWS）＋ Terraform
バックエンドは Ruby on Rails
CI/CD は GitHub Actions
共有カレンダー / 公開カレンダーのモノレポ構成

Datadog 導入理由

インテグレーションの多さ
サンプリング機能の柔軟さ
2025/10/01 から本格導入

週次の「定点観測会」

SRE チームと Backend チームが 週 1 回の合同会議
メトリクスを一緒に確認しながら
- 先週比
- 異常や気になる傾向
- パフォーマンス改善のネタをディスカッション

ダッシュボード設計のポイント

先週比 をパッと見で分かる構成
フィルター による絞り込みで、会議時間内に全体を俯瞰できるように
観測対象は、
- LB リクエスト・レスポンス / CDN Cache 状況
- Cloud Run レスポンスコード・レイテンシ
- クライアント別リクエスト比率（Custom Metrics）
- エンドポイント別レイテンシ・エラー推移（APM）
- 非同期 / 定期実行 Job のレイテンシ
- DB（Spanner）のスロークエリ
- AI 機能（OCR / カレンダー登録）のパフォーマンス

効果

SRE がパフォーマンス状況を 短時間で俯瞰
SRE × BE の会話が定期的に生まれる
トラブルシューティングの精度向上
パフォーマンス意識が開発側にも根付く

Note

ポイント：
「ダッシュボードの作り込み」＋「それを見る定例の場」のセットで、
オブザーバビリティを “運用作業” ではなく “チーム活動” にしているのが印象的でした。

2-6. 株式会社ベネッセコーポレーション様

授業支援アプリのサクサク・ワクワク向上のための Datadog RUM 活用事例

RUM 導入前の課題

あるサービスでネットワーク障害が発生したが、監視から検知できなかった
実際に学校現場を回り、営業・先生からヒアリングして原因を特定するしかなかった
- WAF / 既存 APM では監視できていない領域があった

RUM 導入後

Error Tracking / Monitor によるエラー検知を仕組み化
RUM で ユーザー行動がほぼすべて可視化
- Session Rate 設定でコストコントロール
- 特別な実装なしにユーザー行動分析が可能
Session Replay / Frustration Signals の活用で、
- 「ユーザーがどこで不満をもっているか？」が分かる
- 例：サムネイルをクリックしているが、アプリ側で何も用意しておらず、無駄なクリック になっていた UI を発見

ビジネスサイドへのインパクト

ユーザー要望に対し、定量的な根拠を持って優先順位づけ ができるように
「やる意味あるのか？」という議論がほぼ発生しなくなり、判断スピードが向上

普及の工夫

1 日で企画立案まで行う Datadog 合宿 を開催
RUM の分析手法をレクチャーしつつ、その場で企画を考えるワークショップ形式

2-7. 株式会社ヌーラボ様(Nulab inc.)

AI Agent で実現する AIOps ― Bits AI SRE 国内活用事例 ―

背景

Backlog / Cacoo などを提供するヌーラボ
巨大・複雑化するシステムに対し、「すべてを把握する」ことは不可能
認知負荷と属人化を抑えつつ 高信頼性運用を持続させる ために Bits AI を検証

Bits AI 検証とインシデント対応

2025/10 から約 1 ヶ月検証
深夜 4 時に DDoS 攻撃（毎分 170 万リクエスト）を受けた際、
- Bits AI で 4 分で結論に到達
- 数百万ログから傾向分析・原因特定までやり切った
モニターメッセージに十分なコンテキストを渡していなくても、
- Env / タグ情報から AI 側が情報を補完して調査 してくれる

日常的な問い合わせ対応への展開

インシデントだけでなく、
- 「ちょっと調べてほしい」「この指標どうなってる？」といった問い合わせを Bits AI にオフロード
- Datadog アプリを Slack に常駐させ、チャット形式で調査依頼

課題＆期待

Bits AI でも解けないケース
- 必要なデータが Datadog に入っていない
- 独自コンテキストを渡していない（現状は Notebook や自然言語などで補う必要あり）
今後の期待
- 「SRE が頑張らない世界」を目指し、
  - アラートの発火自体を AI が最適化
  - 複数アラートの中から、AI が自動的に優先度の高いものを選別
コスト面では
- 障害対応や調査にかかる工数、人件費、機会損失とのトレードオフで見ると 十分に安い という評価

Bits AI SRE の GA 公式情報：

www.datadoghq.com

3. 全体を通じて見えたトレンドと実務への示唆

共通していた 3 つのキーワード

各社の事例を並べてみると、共通するキーワードが浮かび上がってきます。

デフォルト化
- フレームワークや、「全システム Datadog 前提」
民主化
- 「見たい人が見たいときに見られる」、社内コミュニティ活動、定点観測会
AI 前提
- Bits AI SRE / Dev Agent / Security Analyst
- LLM 活用、RUM + Session Replay / Frustration Signals

特に AI 系の機能（Bits AI 等）については、複数社が口を揃えて、

APM / Logs / Metrics / Traces / 依存関係 などの土台がないと、AI は力を発揮できない
AI 導入は、「監視基盤整備 → フレームワーク標準化 → 普及・定着」の ネクストステップ

という順番を強調していました。

4. これから取り組むなら、何から始めるか

Datadog Live Tokyo 全体を踏まえると、次のようなステップが現実的なアプローチに思えます。

監視・メトリクスの共通フレームワーク化
- Terraform 等で「これを入れれば最低限のオブザーバビリティが担保される」テンプレートを用意
- プロジェクトは 標準＋オプション＋個別対応 で柔軟性を持たせる
「見る場」を用意する
- 「定点観測会」を週 1 で設定
- SRE × 各開発チームの 対話のハブ としてダッシュボードを育てる
ビジネスサイドへの橋渡し
- RUM / Session Replay / Frustration Signals を活用し、UX やユーザー要望の議論に 定量的な根拠 を与える
AI 機能の試験運用
- Bits AI SRE や Dev Agent
  - まずは 既に Observability が整っているサービス から PoC 的に導入
- インシデント対応／問い合わせ対応のどちらに寄せるか、ユースケースを決めて始める