Google Cloud Next Tokyo 26（2026年7月30日 – 31日、東京ビッグサイト）で聴講した、スポンサーセッション「SRE は AI に何を任せるべきか。プレイドが Datadog で出した答え」のレポートです。
AI エージェントを「自作するか、既製品を買うか」で迷っている方に向けて、このセッションで示された判断軸を中心にまとめました。
なお、本記事に掲載しているスライド写真は、いずれも私が会場で撮影したものです。

セッション情報

項目 内容
セッション ID D1-PLA-01（スポンサーセッション）
日時 2026年7月30日（木）12:00 – 12:30
会場 Room 9
登壇者 横尾 杏之介さん（Datadog Japan / Sales Engineer）
岡本 泰典さん（プレイド / DX&PE・Software Engineer）
袴田 類さん（プレイド / SRE・Platform Engineer）

前半は Datadog の横尾さんによる Bits AI の解説。
後半はプレイドの岡本さん、袴田さんの順で登壇し、「自作 SRE Agent と Bits Investigation を、どう使い分けているか」を実データつきで話す構成でした。

本記事が軸に据えるのは使い分けの判断軸です。
Agent の設計思想、実際の動作画面、Bits Chat でのダッシュボード作成といったパートは扱っていません。

プレイドパートのタイトルが、このセッションの主題をそのまま言い表しています。
「作れるか」ではなく「持ち続けるべきか」。

結論から

セッションの結論は明快でした。

自作か Bits Investigation かの2択ではなく、調査ごとに責務を分けて併用する。

そして、その使い分けを決める軸が2つ示されました。コストと必要なコンテキストです。
以下、この2つの軸にたどり着くまでの道筋を追っていきます。

前提：Bits Investigation は何をするのか

判断軸の話に入る前に、比較対象である Datadog の Bits Investigation が何をするものかを押さえておきます。

Monitor のアラート発報をトリガーに、Runbook（アラートに定義した内容）・Memory（過去の調査で学習した内容）・General Search（Bits が独自に調査）の3方向から調査を開始します。

約3分で初動の所見（Initial Findings）を出し、そこから「DB の CPU 使用率は？」「アプリのデプロイは正常？」「他の連携先 API でエラーはない？」といった仮説を自動で検証していき、約5分で根拠つきの結論を提示します。

人手であればアラート内容の確認から実データ調査・相関分析・原因推察を経て対応策を提示するまでに30分から数時間かかる工程が、数分の自動処理と人による確認だけになる、というのが Datadog 側の説明です。

つまり Bits Investigation はアラートから根本原因の推定までを、自前で作り込まずに動かせるプロダクトです。
ではなぜプレイドは、それとは別に自作の SRE Agent を持っているのでしょうか。

なぜプレイドは自作したのか

理由は3つ挙げられていましたが、興味深いのはどれも「AI の性能」の話ではないことです。

  • Cost｜実行を Control：安定化フェーズでは高頻度・既知のアラートが繰り返し発火する。そこに Bits Investigation の単価は利用形態に合わない。起動条件・利用モデル・実行回数を自分で選びたい
  • Integration｜調査フローを Control：自社固有のシステムや運用フローへ Agent を自然に組み込みたい。たとえば Slack で起動してスレッドの Context を取得し、同じスレッドへ回答する
  • Private Context｜情報と権限を Control：Datadog の外にある社内 Context も、必要な範囲だけ Agent に使わせたい。最新リポジトリと sre.md を直接探索させ、allowedTools で操作範囲を限定する

3つに共通するのは「いつ・どこに・何を使わせるか」という運用の Control でした。
スライドの締めの一文が的確です。

自作したかったのは、もう一つの AI ではなく、Agent を「どう動かすか」の主導権。

動かすのは簡単。任せ続けるのが難しい

とはいえ、自作すれば万事解決というわけではありません。

図は【作れるAgent】（リポジトリを読める・MCP を呼べる・Slack へ返せる）と【任せられるAgent】（障害のさなかでも、信頼して任せられる）を左右に置き、その間に4つの壁を挟む形になっていました。

  • ライブな状況把握（ログ・メトリクス・トレース／依存関係）
  • 接続の維持（API・認証・権限）
  • 情報の鮮度（リポジトリ同期・Playbook 更新）
  • 回答の信頼性（回答評価・フィードバック）

任せる範囲そのものも、別のスライドではっきり区切られていました。

「万能は、狙わない。」

障害対応・オンコール全体のうち、自作 Agent が担うのは高頻度 × 既知 × 定型的の「一次対応」だけ。Slack に症状・仮説・推奨を投げるところまでです。
前例のない障害と恒久対策は人が対応する、と明確に線を引いていました。

コスト：固定費先行と従量課金が交差する点

自作 SRE Agent は固定費が先行するためグラフはほぼ横ばい、Bits AI は従量課金なので右肩上がり。
この2本が交差する件数より調査が多ければ自作が安く、少なければ Bits AI が安い、という構造です。

プレイドの試算では、その交点は月195件でした。単価の内訳は次のとおりです。

単価 補足
自作 Agent 82 – 100円 / 調査 月2,002件で固定費を按分
Bits Investigation 1,000 – 1,300円 / 調査 参考消費量 約6.5 AI Credits / 調査

（1 Credit = 1.00 – 1.30 USD、1 USD = 150円で換算）

そしてプレイドの実運用は月2,002件（2026年7月23日時点）。
試算上の交点を大きく上回っているので、高頻度・既知の一次対応は自作 Agent に寄せている、という話がここで数字とつながります。

ただし、この「月195件」はどの現場にも当てはまる基準値ではありません。
これはプレイドが自作した SRE Agent の固定費と、同社のアラート発火頻度・調査単価を前提に置いた比較です。
自作側の固定費、選ぶモデル、Bits AI のクレジット消費量、為替のいずれかが変われば交点は動きます。
登壇者自身も「数字はあくまで概算」「現状は全調査を Opus 4.6 で実施しているので、モデルの変更によっては分岐ラインが変動する可能性がある」と但し書きを添えていました。

持ち帰るべきは195という数字ではなく、固定費先行と従量課金の交点を、自社の条件で一度引いてみるという手順のほうです。

コストだけでは決まらない – もう一つの軸

コストだけで見れば交点を大きく上回る件数を回しているプレイドは全部自作にすればよいのでは、と思うところですが、そうはなりません。

もう一つの軸が CONTEXT（必要なコンテキスト） です。

  • 自作 SRE Agent：Code / Playbook を根拠にできる。プレイド固有の Private Context と独自 Integration が強み
  • Bits Investigation：Live Telemetry と Topology を持っている。仮説を立てて検証し、違えば棄却して次の仮説へ進む Autonomy が強み

未知で複雑な調査には、あらかじめ Playbook を書いておくことができません。
そこは「その場でテレメトリを掘って仮説検証を回せる」Bits Investigation の領域だ、という切り分けです。

この2軸を重ねた結論が「責務の境界は、調査ごとに動く」。
Build か Buy かをプロダクト単位で決めるのではなく、調査単位で責務を配分するという考え方です。

コストと必要なコンテキストで、調査ごとに責務を配分する

Buy 側も「育てる」必要がある

セッション後半では、Bits Investigation のチューニング事例が2つ紹介されました。
どちらも、最初の調査では期待した結論にたどり着かなかったケースです。

事例1はログ増加アラート。期待していたのは「組織タグで切り分ければテスト環境で起きていると分かり、
定期的に行われている負荷試験が疑わしい＝想定内のログ増加」という判断でした。

しかし実際の Bits は、テスト環境ではなく本番環境の Error に着目し、DB Timeout を調査してDB Latency を原因候補として提示しました。スライドには「異常は発見したが、今回のログ増加の直接的な原因ではなかった」と書かれています。

事例2の API エラー増加でも、別リージョンにあって API サーバと依存関係のない分析用 DB の遅延を、原因候補として提示しました。どちらも、事象と関係のない異常が原因候補に挙がったケースです。

対処は、Bits.md にシステム固有の知識と運用コンテキストを書き足すことでした。

事例1に追加したのは「メトリクスに組織タグが含まれる場合、調査開始時に組織タグで調査対象を切り分ける」「組織タグにはテスト環境と負荷試験環境がある」「テスト環境では定期的に負荷試験が実施される」の3点。

事例2に追加したのは「System はマルチリージョン構成になっている」「リージョンを識別するためのタグの命名規則」「メトリクスの相関からシステムの関係性を構築するのではなく、Service Map を依存関係の起点として参照する」「プロダクトへの影響が無い分析用 DB の存在」の4点です。

Telemetry だけでは足りない
Bits AI には Knowledge と Context が必要

ここは Build vs Buy の判断に直接効いてきます。
少なくともこのセッションで紹介された運用では、Buy を選んでも「買って終わり」にはならなかったからです。
自社固有の Knowledge と Context を追加する工程を織り込んでコストと工数を見積もる、この事例からはそういう学びが得られました。

おわりに

セッションの最後は、Bits Investigation を賢くする過程で蓄積した Knowledge と Context をDatadog 側に貯め、Bits AI に限らずさまざまな Coding Agent がそれを参照する「コンテキストプラットフォーム」への展望で締めくくられました。

30分のセッションでしたが、持ち帰れる判断軸がはっきりしていました。

  1. 頻度で見る – 高頻度・既知・定型的なら自作が効き、低頻度・未知・複雑なら既製品が効く
  2. 必要なコンテキストの所在で見る – 判断材料が自社の内側（コード・Playbook・社内システム）にあるか、テレメトリ側にあるか
  3. 境界はプロダクト単位ではなく調査単位 – どちらか一方を選ぶ問題ではない

そしてこの事例では、既製品を選んだあとにも自社の運用コンテキストを教え込む工程が必要でした。
AI エージェントの導入を検討する際、「作れるか」だけでなく「持ち続けられるか」を最初に問う。
プレイドパートのタイトルが、そのまま自分たちへの問いになりそうです。