はじめに

こんにちは、KDDIアイレット株式会社の伊藤です。
2026 年 7 月 30 日に開催された Google Cloud Next Tokyo’26 で、Datadog 社と株式会社プレイド(PLAID)によるセッション「『作れるか』ではなく『持ち続けるべきか』— SRE Agent の Build と Buy の境界線」を聴講しました。

セッションは 2 部構成でした。

  • 前半: Datadog 社による AI 機能「Bits AI」と障害調査エージェント「Bits Investigation」の紹介
  • 後半: 自作 SRE Agent を本番運用しているプレイド社の知見と、Bits Investigation との使い分け

テクニカルサポートの業務で AI による業務改善に取り組んでいる自分にとって示唆の多い内容だったので、要点と学び・共感した点を整理します。

Datadog の Bits AI と Bits Investigation

Datadog の AI 機能は 2 系統

  • AI “で” 監視する: Bits AI、Datadog MCP Server
  • AI “を” 監視する: AI インテグレーション、GPU Monitoring、Agent Observability

今回の主役は前者の Bits AI、その中でも障害調査を担う Bits Investigation でした。

Bits AI と Bits Investigation とは

Bits AI は、Datadog プラットフォーム全体にわたる AI アシスタント機能群の総称です。障害対応の Detect(検知)→ Investigate(調査)→ Remediate(修復)のサイクルに沿って、Bits Detection、Bits Investigation、Bits Remediation のほか、Bits Memory、Bits Chat、Bits Code、Bits Agent Builder といった機能で構成されます。

Bits Investigation は、このうち Investigate を担う障害調査エージェントです。Monitor のアラート発報をトリガーに、次の 3 つを起点として自動で調査を開始します。

  • Runbook: アラートに定義した手順をベースに調査
  • Memory: 過去の調査で学習した内容をもとに調査
  • General Search: Bits が独自に環境をスキャンして調査

初動調査の結果(例: DB の遅延が原因で API エラー)を約 3 分で提示した後、「DB の CPU 使用率は?」「デプロイは正常?」といった仮説を Datadog 内のデータで自動検証し、約 5 分で根拠付きの調査結論を提示します。その先の Code Fix の提案(Preview)や、Chat からの追加調査依頼・Workflow 実行にもつながります。

アラート対応の「あるある」から始まる導入

「決済処理が 20 秒を超える遅延」というアラートを受けた SRE が何をするか、という問いかけから話が始まりました。具体的には以下のような業務が発生いたします。

  • ダッシュボード / メトリクス / ログの確認
  • 影響範囲(影響のあった時間帯)の調査
  • Slack で複数メンバーを巻き込んだ分担調査
  • 過去の報告書から類似事象の対処を調査
  • 暫定的なロールバック

夜間なら孤独な戦いになり、精神衛生上かなりつらいです。過去に監視運用に携わっていた経験から私にとってはとても共感できる内容でした。

Bits Investigation の効果

Bits Investigation は、アラート受信から対応策提示までの一次調査を自動で実行します。

  • 従来: アラート内容確認 → トリアージ → 影響範囲確認 → 実データ調査 → 相関分析 → 根本原因推察 → 対応策提示で 30 分〜数時間
  • Bits Investigation: 数分(自動)+ 人は確認のみ

デモでは、決済サービスの API キー設定ミスに起因する障害の根本原因分析(RCA)を 4 分で完了させる例が紹介されました。

暗黙知をどう扱うかという論点

AI Agent 時代の SRE に必要な要件として、次の 2 つが挙げられました。

  1. 暗黙知を共有できること: AI が人間の直感に頼らず判断できるよう、構造化されたシグナルとコンテキストを渡す
  2. 暗黙知を形式知に変えること: 障害対応で得たナレッジを、機械にも人間にも使える形で組織の記憶として残す

具体的には、Monitor メッセージや Runbook を AI へのコンテキストとして使い、調査結果をポストモーテムとして Notebook に即座に出力する循環が示されました。タグの命名規則や既知のノイズパターンといった組織固有の知識は「Bits.md」というファイルで共有できます。

プレイド社の自作 SRE Agent との併用

自作を選んだ理由は「主導権」

自作の動機は「もう一つの AI が欲しかったのではなく、Agent を『どう動かすか』の主導権が欲しかった」という言葉に集約されます。

  • Cost: 起動条件・利用モデル・実行回数を自分たちで制御したい
  • Integration: Slack 起点の調査フローなど、自社固有の運用に自然に組み込みたい
  • Private Context: 社内コンテキストを、権限を絞って Agent に使わせたい

本番運用の壁

一方で「動かすのは簡単。ただし、任せ続けるのが難しい」という率直な話もありました。

  • ライブな状況把握(ログ・メトリクス・トレース・依存関係)
  • API・認証・権限といった接続の維持
  • リポジトリや Playbook の鮮度
  • 回答の信頼性(評価とフィードバック)

また、スコープは「高頻度 × 既知 × 定型の一次対応」に限定し、前例のない障害と恒久対策は人が担うという「万能は狙わない」設計でした。

コストで見る使い分け

使い分けの判断はコストの実測に基づいていました。

  • 自作 Agent: 約 82〜100 円 / 調査(固定費を月間件数で按分)
  • Bits Investigation: 約 1,000〜1,300 円 / 調査
  • 損益分岐点: 月 195 件前後(同社の実運用は月 2,002 件)

結論は「高頻度・既知・定型は自作、低頻度で未知・複雑な調査は Bits Investigation」。どちらが優れているかではなく、コストと必要なコンテキストで調査ごとに責務を配分する、という整理です。

学びと自分の業務への活かし

自分は現在、テクニカルサポートチームでお客様からの技術質問に回答する業務に携わっており、AI による業務改善にも取り組んでいます。「問い合わせを受け、内容を確認し、過去の類似事例を調べ、根拠とともに回答を組み立てる」という一次調査の構図は障害対応と共通しており、知見はそのまま応用できると感じました。

持ち帰りたい学びは 3 つです。

  1. 万能を狙わないスコープ設計
    AI が担うのは既知・定型の問い合わせに対する回答案の提示までとし、前例のない質問や最終的な回答責任は人が持つ。この責務の線引きを最初に明確にする。

  2. 暗黙知を AI が使える形式知に変える運用
    Bits.md の運用は、コーディングエージェントにおける CLAUDE.md と同じ構図。製品固有の癖や過去の問い合わせの経緯といった現場の暗黙知を、「人向けドキュメント」と「AI 向けコンテキスト」の両方で設計する。

  3. Build or Buy を二択にしない判断軸
    件数と 1 件あたりコストの分岐点を実測し、「どちらを買うか」ではなく「どこまで任せるか」を調査ごとに判断する。

おわりに

障害対応の一次調査は AI に任せられる段階に入りつつあり、論点は「作れるか」ではなく「持ち続けるべきか」、そして「どこまで任せるか」に移っている——それが本セッションの一貫したメッセージでした。

ベンダー製品と自作の両方を本番で回した上での使い分けの知見は説得力があり、自身の業務でも判断軸として活用していきたいと思います。