SRE は AI に何を任せるべきか。Plaid が Datadog で出した答え / what -should-SREs-delegate-to-AI? Plaid’s-answer-powered-by-Datadog

Google Cloud Next Tokyo 2026 での PLAID との 登壇内容。

Transcript

1. SRE は AI に何を任せるべきか。 PLAID が Datadog で出した答え Google Cloud Next Tokyo 2026, Sponsored Session Speaker Datadog : Annosuke Yokoo PLAID : Taisuke Okamoto(a.k.a BigBaBy）/ Rui Hakamata
2. 今日の全体感について 10分 前座: Datadog や Bits AI について Annosuke（Datadog） 10分 本編1: 「作れるか」ではなく「持ち続けるべきか」 BigBaby さん（PLAID） SRE Agent の Build と Buy の境界線 10分 本編2: Bits Investigationをさらに賢く Rui さん（PLAID）
3. 自己紹介 横尾杏之介 (Annosuke Yokoo) Sales Engineer （Datadog） • Google Cloud Next 2025 に引き続き 2 回目の Next 登壇 • Google Cloud Partner Top Engineer Fellow 2025 • アイコンはよく見ると怖い PENGEN（嫁作） 2025
4. 会社概要 クラウド時代の モニタリング＆セキュリティ プラットフォーム 企業情報ハイライト （※2026年7月現在） 2010 年 $96.5B(約15.7兆円) 8,100+ 30% ニューヨークにて創業 グローバルの従業員数 33,200 エンタープライズのお客様社数 財務ハイライト ($DDOG) -2019/9/19:NASDAQ上場 -2025/7/9:S&P 500採用 $4.30B (+26%) サブスクリプションの 年間経常売上 (ガイダンス） non-GAAPベースの研究開発投資比率 35ヶ国 事業展開している国 84% Datadog製品を2製品以上 お使いのお客様 4
5. Datadog のプラットフォーム 開発 コード ビジネス テスト リリース 監視 稼働 運用 最適化 セキュア ユーザー 理解 ユーザー サポート ビジネス 分析 ビジネス 成長 開発からビジネスまで広範囲に支援 ソフトウェア開発 監視 & 運用 最適化 セキュリティ • CI/CD 可視化 • テスト最適化 • Continuous Testing • インフラ監視 • ユニバーサル サービス監視 • Continuous Profiler • クラウドコスト管理 • クラウド セキュリティ管理 • ワークロード 保護 • リアルユーザー 監視 • オブザーバビリティパイ プライン • データベース監視 • コードセキュリティ • App and API 保護 • プロダクト分析 • データストリーム監視 • クラウド SIEM • ログ管理 • データジョブ監視 • 機密データスキャナ • LLM オブザーバビリティ • データ オブザーバビリティ • ネットワーク監視 • APM • 合成監視 • オンコール • Cloudcraft - ヒートマップ - クリックマップ - スクロールマップ - ファネル分析 • モバイル アプリテスト • セッション リプレイ クラウドサービスマネジメント Cloud Service Management • インシデント管理 分析 • ワークフロー オートメーション • App Builder • 内部開発者ポータル (IDP) • ケース管理 • リソースカタログ • イベント管理 • SLO AIOps 機能群 ( Bits AI, Watchdog, ML based Monitor, NL Search ) 5
6. Datadog が提供している AI 関連の機能 Datadog プラットフォーム 全体にわたる AI 機能 お客様自身の AI の開発と 監視を支援するツール AI for オブザーバビリティ オブザーバビリティ for AI • Bits AI • Datadog MCP Server • AI インテグレーション ◦ Gemini, Bedrock,••• • GPU Monitoring • Agent Observability
7. Datadog が提供している AI 関連の機能 AI "を" 監視 AI "で" 監視 Datadog プラットフォーム 全体にわたる AI 機能 お客様自身の AI の開発と 監視を支援するツール AI for オブザーバビリティ オブザーバビリティ for AI • Bits AI • Datadog MCP Server • AI インテグレーション ◦ Gemini, Bedrock,••• • GPU Monitoring • Agent Observability
8. Datadog が提供している AI 関連の機能 AI "を" 監視 AI "で" 監視 Datadog プラットフォーム 全体にわたる AI 機能 お客様自身の AI の開発と 監視を支援するツール AI for オブザーバビリティ オブザーバビリティ for AI • Bits AI • Datadog MCP Server • AI インテグレーション ◦ Gemini, Bedrock,••• • GPU Monitoring • Agent Observability
9. もしこんなアラートがなった時、あなたが SRE ならどうしますか？
10. 一般的な対処としては ... １次対応 • 決済時の ダッシュボード / メトリクス / ログ を見る （ex. Datadog , Cloud Monitoring etc.） • 影響範囲（あるいは影響のあった時間帯）を調査する • Slack で複数のメンバーを巻き込んで、分担して調査を頑張る • 過去の報告書から同様の事象でどのように対処したか調査する • 暫定的なロールバック ※ 夜間なら孤独の戦い 😢（これが精神衛生上ツライ ...）
11. 一般的な対処としては ... １次対応 • 決済時の ダッシュボード / メトリクス / ログ を見る （ex. Datadog , Cloud Monitoring etc.） • 影響範囲（あるいは影響のあった時間帯）を調査する • Slack で複数のメンバーを巻き込んで、分担して調査を頑張る • 過去の報告書から同様の事象でどのように対処したか調査する • 暫定的なロールバック ※ 夜間なら孤独の戦い（これが精神衛生上ツライ ...） 2次対応 / 恒久対応 • 根本原因（ RCA）の追求と修正 PR • ポストモーテム（障害報告書）の作成
12. 一般的な対処としては ... １次対応 • 決済時の ダッシュボード / メトリクス / ログ を見る （ex. Datadog , Cloud Monitoring etc.） • 影響範囲（あるいは影響のあった時間帯）を調査する • Slack で複数のメンバーを巻き込んで、分担して調査を頑張る • 暫定的なロールバック それ全部、Bits が出来ます SRE にも Agentic な考え方を！ • 過去の報告書から同様の事象でどのように対処したか調査する ※ 夜間なら孤独の戦い（これが精神衛生上ツライ ...） 2次対応 / 恒久対応 • 根本原因（ RCA）の追求と修正 PR • ポストモーテム（障害報告書）の作成
13. 一般的な対処としては ... １次対応 • 決済時の ダッシュボード / メトリクス / ログ を見る （ex. Datadog , Cloud Monitoring etc.） • 影響範囲（あるいは影響のあった時間帯）を調査する • Slack で複数のメンバーを巻き込んで、分担して調査を頑張る • 暫定的なロールバック それ全部、Bits が出来ます “SRE Agent” という手段 • 過去の報告書から同様の事象でどのように対処したか調査する ※ 夜間なら孤独の戦い（これが精神衛生上ツライ ...） 2次対応 / 恒久対応 • 根本原因（ RCA）の追求と修正 PR • ポストモーテム（障害報告書）の作成
14. Bits AI
15. Bits AI の全体像 Bits Detection Bits Remediation Bits Investigation Bits Code Bits Memory Bits Agent Builder Bits Chat Datadog MCP Server
16. Bits Investigation のお話しが中心 Bits Detection Bits Remediation Bits Investigation Bits Code Bits Memory Bits Agent Builder Bits Chat Datadog MCP Server
17. Bits Investigate の 日本 における 利用実績 月平均 60 社以上 https://www.datadoghq.com/product/ai/bits-investigation/ https://www.datadoghq.com/product/ai/bits-investigation/ 17
18. Bits Investigation による１番の効果 アラート受 信 アラート内 容確認 初期 トリアージ 影響範囲 確認 対応手順 確認 対応履歴 確認 問題特定 実データ調 査 相関分析 根本原因 推察 対応策 提示 対応策 レビュー 30分 ~ 数時間 18
19. Bits Investigation による１番の効果 アラート受 信 アラート内 容確認 初期 トリアージ 影響範囲 確認 対応手順 確認 対応履歴 確認 問題特定 実データ調 査 相関分析 根本原因 推察 対応策 提示 対応策 レビュー 30分 ~ 数時間 数分 (自動) 確認のみ 19
20. MONITOR ALERT アラート発報 RUNBOOK アラートに定義した内 容をベースに調査 MEMORY 過去の調査で学習し た内容を元に調査 GENERAL SEARCH Bitsが独自に調査 INITIAL FINDINGS 初動調査の結果 例：DBの遅延が原因で APIエラー 約3分 Hypothesis Investigation 自動でDatadog内のデータを調べて仮説検証 DBのCPU使用率 は？ アプリのデプロイは 正常？ 他の連携先APIで エラーはない？ Investigation Conclusion 最終的な調査結果を根拠と合わせて提示 SUGGESTED CODE FIX (Preview) Code Fixを推奨 約5分 Chat Chatを活用して追加調査依頼や、 Action、Workflow実行が可能
21. AI Agent 時代における SRE Agent に対する 2つの基本要件 【前提】 Agent により作成されたシステムは動いているが、なぜそう動いているかを十分に理解しずらい。 従来はコードを書いた人間に聞けば手がかりが得られたが、 AI Agent が書いたコードには「なぜこの設計にしたのか」「このエッジ ケースをどう考慮したのか」という暗黙知が存在しずらい。
22. AI Agent 時代における SRE Agent に対する 2つの基本要件 【前提】 Agent により作成されたシステムは動いているが、なぜそう動いているかを十分に理解しずらい。 従来はコードを書いた人間に聞けば手がかりが得られたが、 AI Agent が書いたコードには「なぜこの設計にしたのか」「このエッジ ケースをどう考慮したのか」という暗黙知が存在しずらい。 ① 暗黙知を共有できること • Agent 自身が人間の直感に頼らず判断できるよう、十分に構造化されたシグナルと、 人が持つような様々なコンテキストが必要 ② 暗黙知を形式知に変えること • インシデントやエラー対応で得られたナレッジを、機械にも人間にも使える形で保存し、 組織の記憶として残す能力が必要
23. ① 暗黙知を共有できること Bits.md により暗黙知を Bits Investigate へのコンテキストとして共有可能 プラットフォームルール ## スコープに関するルール - ユーザーから明示されたスコープ（ env、service、team、region、namespace）は必ず引 き継ぐこと。 - 明示された値はすべてのクエリにおいてハードフィルターとして扱うこと。 - 明示的に指示されない限り、スコープを広げないこと。 --## タグおよび命名規則 ### 環境（env）の正規化 環境の値は、テレメトリソース（モニター、 APM、ログ、チケット）ごとに異なる場合がある。 例： - アラート／APM: `env:blue-prod` - ログ: `env:prod` ルール：データソースを切り替える際は、クエリを実行する前に、そのソースに対応する正し いenv値へ正規化すること。 --### サービス名の正規化 サービス／アプリケーション名は、システム（アラート、ログ、チケット、アセット管理システム） ごとに表記が異なる場合がある。 ## Kubernetesの簡易チェック Podの問題については、まずKubernetesのイベントを確認する： 例： `source:kubernetes pod_name:<pod> kube_namespace:<namespace>` - アラートのタグ: `checkout_prd` - チケット管理システム: `CHECKOUT` よくある原因： - ログ: `checkout-service` - `FailedMount` → Secret／ConfigMapの不足 - `ImagePullBackOff` → イメージまたはレジストリの問題 ルール： - `OOMKilled` → メモリ不足（メモリプレッシャー） - 正規のサービス名を導き出すこと。 - システム間で紐付けを行う際は、大文字小文字を区別しないマッチング、またはワイルド ## 既知のノイズおよび誤検知 カードマッチングを使用すること。 インシデントのように見えるが、実際は想定された挙動であるパターンを記録する。 - ツール間で命名が同一であるとは限らないことを前提とすること。 サービス特有のルール 例： - 夜間バッチジョブにより、UTC 02:00〜02:30の間にCPUスパイクが発生する。 - 合成モニタリングテストにより、短時間の 5xxエラーが意図的に発生する。 - カナリアデプロイのロールアウト中、一時的にエラー率が上昇する。 - オートスケーリングイベントにより、一時的にレイテンシがスパイクすることがある。 ルール： - 発生している事象が、既知のノイズパターンに一致するか確認すること。 - パターンに一致する場合は、追加の影響が観測されない限り「想定内の挙動」として分類する こと。 23
24. ① 暗黙知を共有できること Monitor メッセージや Runbook から過去のナレッジもコンテキストとして使用可能 24
25. ② 暗黙知を形式知に変えること 暗黙知を体系化された Runbook (形式知) へとにすぐに出力 25
26. 先ほどの例で見てみると ... 26
27. 先ほどの例で見てみると ... 27
28. 先ほどの例で見てみると ... 28
29. 前座のまとめ • Datadog には Bits AI という Observability のための AI がある そして SRE にも Agentic な考え方 が必要 • Bits Investigation により、工数削減・時間削減的な観点から 大きく SRE の対応を変えられる可能性がある • よく議論される自作 SRE Agent と比較をした取り組みを PLAID さんから Bits Investigation の事例を話してもらいます！
30. 「作れるか」ではなく「持ち続けるべきか」 SRE Agent の Build と Buy の境界線 © PLAID, Inc. 2026.07.30 ｜ Google Cloud Next 2026
31. 話す前に.....自己紹介 岡本泰典 (Taisuke Okamoto) KARTE AI Transformation(Dept) Core Platform(Dept) • • • • 開発者体験向上のためのよろず屋 最近は「Mila」という OLAP DB を開発しています CloudNative Days というカンファレンスの Chair #〆のラーメンまである倶楽部 メンバー Google Cloud Next は初登壇🎉 © PLAID, Inc. Inc 31
32. 会社概要 ｜ © PLAID, Inc. 32
33. Webサイト/アプリの訪問者の行動を 顧客ごとにリアルタイムに解析 CX(顧客体験)プラットフォーム 一人一人に合わせた 顧客体験を提供 ｜ © PLAID, Inc. 33 33
34. CX Platform KARTE 累計ユーザー数 ※1 年間解析流通⾦額 ※2 199億UU 2.59兆円 秒間トラッキング数 ※3 解析速度 0.x 秒/解析 ⽉間解析データ量 134,000over 180over ペタバイト サイトやアプリの訪問顧客のリアルタイム解析‧セグメンテーションを⾏い、そ れに応じたアクションやコミュニケーションを実 現するためのクラウド上のソフ トウェア ※1 ローンチ〜2023年2⽉までのユニークユーザー数の実績 ｜ © PLAID, Inc. ※2 EC領域における解析流通⾦額。2022年3⽉〜2023年2⽉までの単年の実績 ※3 閲覧、クリック、購⼊などKARTEで計測しているユーザーの全イベントが対象。ローンチ〜2023年3⽉までにおける最⼤値 34 34
35. Bits Chat で気軽にダッシュボード作成 Datadog 使用歴1年程度の自分でも「求めているもの」をすぐアウトプットできるのが便利 © PLAID, Inc.
36. Bits Investigation も活用 アラートから迅速に原因を特定し、Next Action を教えてくれるので調査コストも大幅減少 © PLAID, Inc.
37. Bits AI を利用・検証をしていくなかで... プロダクトに特化した SRE Agent も 自作した © PLAID, Inc. Inc 37
38. このパートで話すこと 自作 SRE Agent か Bits Investigation か、の2択ではない © PLAID, Inc.
39. 自作を選んだ 3つの理由 © PLAID, Inc. 39
40. 自作を選んだ3つの理由 運用の『 Control』を自分たちで持ちたいという欲求 自作したかったのは、もう一つの AI ではなく、 Agent を「どう動かすか」の主導権。 © PLAID, Inc.
41. リポジトリを直接読む SRE Agent © PLAID, Inc. 41
42. Agent の設計思想 最初に見つけたエラーが、原因とは限らない。 © PLAID, Inc.
43. 実際に動作している図 Datadog の Monitor をトリガーに、 SRE Agent が自動で分析を開始 © PLAID, Inc.
44. 実際に動作している図 症状をもとに 3つの仮説を立て、そして推奨アクションを提示 © PLAID, Inc.
45. 自作 SRE Agent がうまく機能した領域 © PLAID, Inc. 45
46. 自作 SRE Agent がうまく機能した領域 万能は、狙わない。 © PLAID, Inc.
47. 作って初めて分かった、本番運用の難しさ © PLAID, Inc. 47
48. 作って初めて分かった、本番運用の難しさ 動かすのは簡単。ただし、任せ続けるのが難しい。 © PLAID, Inc.
49. 作って初めて分かった、本番運用の難しさ どちらが優れているかではなく、どこで使い分けるか。 ※ 数字はあくまで概算です。現状は全調査をOpus4.6で実施しているので、モデルの変更によっては分岐ラインが変動する可能性があります。 © PLAID, Inc.
50. 自作して見えた、Build と Buy の境界線 © PLAID, Inc. 50
51. 自作して見えた、Build と Buy の境界線 「育てるか」ではなく「力を借りるか」を見極める コストと必要なコンテキストで、調査ごとに責務を配分する © PLAID, Inc.
52. 自作して見えた、Build と Buy の境界線 使い分けの軸は、 2つ。 自作か Bits Investigation かの2択ではなく、調査ごとに責務を分けて併用する。 © PLAID, Inc.
53. Bits Investigation をさらに賢く © PLAID, Inc. 2026.07.30 ｜ Google Cloud Next 2026
54. 自己紹介 袴田 類 Platform Engineer / SRE DevOps 領域が得意 © PLAID, Inc. 54
55. 背景 Bits Investigation は大量の Telemetry を活用し、 RCA を高速に実行できる Metrics Log Trace システム固有の Knowledge や運用 Context を与えることでさらに賢く高速に © PLAID, Inc. Root Cause Analytics 55
56. 事例1: ログ増加アラート © PLAID, Inc. 56
57. 事例1: ログ増加アラート ログ出力量 期待する RCA • • • メトリクスを組織タグで切り分ける テスト環境で発生していることが分かる 定期的に行われている負荷試験が疑わしい ✅ 想定内のログ増加 組織タグによる切り分け テスト環境 本番環境 © PLAID, Inc. 57
58. 事例1: ログ増加アラート ログ出力量 実際の Bits Investigation の RCA • • • テスト環境ではなく本番環境のError に着目 DB Timeout を調査 DB Latency を原因候補として提示 🟡 異常は発見したが、今回のログ増加の直接的な原因ではなかった エラーログの確認 エラーログ数 Error Pattern: Database Timeouts © PLAID, Inc. 58
59. 事例1: ログ増加アラート 改善方法 : Knowledge と Context を Bits.md に追加 knowledge context 以下を Bits.md に追加する • • • メトリクスに組織タグが含まれる場合、調査開始時に組織タグで調査対象を切り分ける 組織タグにはテスト環境と負荷試験環境がある テスト環境では定期的に負荷試験が実施される 🎯 適切な切り分けと運用コンテキストを加味して、正しいRCA を行えるようになった Bits.md © PLAID, Inc. 59
60. 事例2: API Error 数の増加 © PLAID, Inc. 60
61. 事例2: API Error 数の増加 エラーログ数 期待する RCA Error Pattern: Database Timeouts Databaseのメトリクス確認 • • • エラーログを確認 API Server の接続先の DB で Timeout が 発生 DB の負荷増加 Database リクエスト数 ✅ DB 起因 Database Latency © PLAID, Inc. 61
62. 事例2: API Error 数の増加 エラーログ数 実際の Bits InvestigationのRCA • • • エラーログを確認 API Server の接続先の DB で Timeout が 発生 別リージョンの分析用 DB の負荷増加 🟡 別リージョンかつ API サーバと依存関係のない分析用DB の遅延を原 因候補として提示 Error Pattern: Database Timeouts location: asia Databaseのメトリクス確認 Database Return Rows Count location: us Database DatabaseLatency レイテンシー悪化 © PLAID, Inc. location: us 62
63. 事例2: API Error 数の増加 改善方法 : Knowledge と Context を Bits.md に追加 knowledge context 以下を Bits.md に追加する • • • • System はマルチリージョン構成になっている リージョンを識別するためのタグの命名規則 メトリクスの相関からシステムの関係性を構築するのではなく、 Service Map を依存関係の起点として参照 プロダクトへの影響が無い分析用DB の存在 🎯 適切なシステムの依存関係とリージョンを利用して、正しいRCA を行えるようになった © PLAID, Inc. Bits.md 63
64. まとめ Metrics Telemetry だけでは足りない Bits AI には Knowledge と Context が必要 Log knowledge © PLAID, Inc. Trace context 64
65. まとめ Metrics コンテキスト プラットフォームと しての可能性 Log Trace Bits AI • • Bits Investigation を賢くする過程 で得られたKnowledge と Context をDatadogに蓄積 Bits AI を含む様々な Coding Agent が参照することで、開発体 験を向上 Context Pla orm Coding Agent knowledge © PLAID, Inc. context 65
66. Thank you Let's meet at “Ask The Speaker” 👋 © PLAID, Inc.