セッションタイトル

SRE は AI に何を任せるべきか。PLAID が Datadog で出した答え

はじめに

AIエージェントが開発の現場で当たり前に使われるようになった今、「運用の仕事はどこまでAIに任せられるのか？」そして、「自分の仕事はどう変わるのか？」と気になっている方も多いのではないでしょうか。

私はMSP2年目の監視保守メンバーとして、日々アラート対応をしています。だからこそ、「調査までAIがやるようになったら、運用の現場はどう変わるのか？」という問いに強い関心を抱いています。

Google Cloud Next Tokyo 2026に参加し、本セッションを聞いてこの問いに対するひとつの明確な答えが示されました。

それは、AIに任せられるのは調査そのものであり、人の仕事は「調査すること」から「AIの調査を確認し、任せ続けるための運用をすること」に変わっていくということです。

本記事では、この重要なテーマについてセッションで学んだ内容を整理し、監視保守メンバーとしての自身の学習に繋げていきたいと思います。

なぜ今「SREエージェント」なのか？— アラート対応は孤独な戦い

セッションは「決済処理が20秒を超える遅延となりました」というアラートを例に、「あなたがSREならどうしますか？」という問いかけから始まりました。

一般的な対処は以下のような流れです。

  • 1次対応：ダッシュボード / メトリクス / ログの確認（Datadog、Cloud Monitoring etc.）、影響範囲（あるいは影響のあった時間帯）の調査、Slackで複数のメンバーを巻き込んだ分担調査、過去の報告書から同様事象の対処方法を調査、暫定的なロールバック
  • 2次対応 / 恒久対応：根本原因（RCA）の追求と修正PR、ポストモーテム（障害報告書）の作成

夜勤で深夜のアラートを受け取ることもある身として、あの緊張感はよく分かります。エスカレーション後も手順書の範囲で監視・経過観察を続け、分かる範囲で状況を整理して共有に備える——スライドの「夜間なら孤独の戦い（これが精神衛生上ツライ…）」の一文には思わず頷いてしまいました。

この課題に対して、コーディングエージェントで当たり前になったエージェンティックな考え方をSREにも適用しよう、というのが本セッションのキーワード「SREエージェント」です。

Bits AI：Datadogが提供するSREのためのAIエージェント

Datadogは、Observabilityのための AI として「Bits AI」を提供しています。全体像は「Detect（検出）→ Investigate（調査）→ Remediate（修復）」のサイクルで整理されています。

  • Bits Detection：異常の検知
  • Bits Investigation / Bits Memory：アラートの自律調査と、調査で得られた知見の記憶
  • Bits Remediation / Bits Code / Bits Agent Builder：修復アクションやコード修正の提案
  • Bits Chat / Datadog MCP Server：対話やエージェント連携の入口

今回の主役は、この中のSREエージェント機能「Bits Investigation」です。

調査の「30分〜数時間」が「数分＋確認のみ」に

従来、アラート受信から、内容確認 → 初期トリアージ・影響範囲確認 → 対応手順・対応履歴確認 → 実データ調査 → 相関分析 → 根本原因推察 → 問題特定 → 対応策提示 → 対応策レビュー、までを人間が行うと30分〜数時間かかっていました。

Bits Investigationはこの一連の調査を自律的に行い、数分（自動）＋人は確認のみに変えてくれます。

実際のデモでは、冒頭の決済遅延アラートに対してBits Investigationがログ・トレース・メトリクスの実データを調査し、「決済サービスにおけるAPIキーの設定ミス」という根本原因とタイムライン、根拠データまでをわずか4分（Completed in 4m）で提示していました。

エスカレーションの先で行われていた調査が数分で終わるなら、障害対応全体の景色は大きく変わります。深夜でも即座に調査が始まるのは、夜間対応のある現場にはありがたい点です。そしてこれは「仕事がなくなる」話ではなく「人の仕事が『調査』から『確認・レビュー』に移る」話です。AIが数分で出してきた仮説と根拠を正しく評価できるだけの知識は、むしろこれまで以上に必要になります。

暗黙知をBits.mdでコンテキストとして共有する

AI Agentが書いたコードには「なぜこの設計にしたのか」という暗黙知が存在しづらい。だからこそ、AI Agent時代のSRE Agentには2つの基本要件が求められます。

  • 暗黙知を共有できること：Agent自身が人間の直感に頼らず判断できるよう、十分に構造化されたシグナルと、人が持つような様々なコンテキストが必要
  • 暗黙知を形式知に変えること：インシデントやエラー対応で得られたナレッジを、機械にも人間にも使える形で保存し、組織の記憶として残す能力が必要

Bits AIでは「Bits.md」というファイルに、タグ・命名規則の正規化、Kubernetesの簡易チェック、既知のノイズ・誤検知パターンといった運用の暗黙知を記述して、Bits Investigationへコンテキストとして共有できます。MonitorメッセージやRunbook、過去のポストモーテムといった既存のナレッジもコンテキストとして活用可能です。

ここで思い浮かんだのが、私が日々頼っている手順書のことです。手順書はまさに、暗黙知を形式知に変えたもの。案件担当が作成した手順書がそのままAIのコンテキストになる時代が来ていると考えると、手順書を書き、更新し続けるという日々の営みの価値はさらに高まりそうです。

PLAIDの答え①：「作れるか」ではなく「持ち続けるべきか」

後半は、自作SRE Agentを実際に作って運用しているPLAIDさんによる、Bits Investigationとの比較のパートです。

自作を選んだ3つの理由：運用の「Control」を持ちたい

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

共通項は、能力より「いつ・どこに・何を使わせるか」＝運用のControl。自作したかったのは、もう一つのAIではなく、Agentを「どう動かすか」の主導権だったそうです。

万能は、狙わない

自作SRE Agentの設計思想は「最初に見つけたエラーが、原因とは限らない」。疑って、潰して、残ったものが真因という消去法ベースの調査フロー（症状の洗い出し → 原因候補を3つ以上 → 消去法で潰す → 全症状を説明できたら真因を確定）で、症状・仮説・推奨をSlackに返します。

そして重要なのが、AIが担う領域を「高頻度×既知×定型的」な一次対応だけに絞り込んでいること。それ以外（前例のない障害と恒久対策）は人が対応する、と明確に分けています。

この整理にはハッとさせられました。「高頻度×既知×定型的」な一次対応——これはまさに、私が手順書に沿って日々行っている仕事の領域です。そして「前例のない障害は人が対応」という分け方は、手順書にない事象を案件担当へエスカレーションする、今のMSPの運用体制と同じ構造です。

実際に、DatadogのMonitorをトリガーにSRE AgentがPubSub Indexer Queueの滞留を自動分析し、3つの仮説を消去法で検証して推奨アクションまでSlackに提示する様子が紹介されました。

作って初めて分かった、本番運用の難しさ

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

個人的に、今回のセッションで一番刺さったのがこのスライドです。

リポジトリを読める・MCPを呼べる・Slackへ返せる「作れるAgent」と、障害のさなかでも信頼して任せられる「任せられるAgent」の間には、本番運用の壁があります。

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

これを見て気づいたのは、AIエージェントもまた「運用・保守の対象」になるということです。接続は維持されているか、参照している情報は古くなっていないか、回答の品質は落ちていないか——項目を並べてみると、これは私たちが日々システムに対してやっている監視・保守そのものです。

「AIに仕事を奪われる」のではなく、「監視・保守すべき対象にAIエージェントが加わる」。運用者としてのスキルや心構えは、むしろAI時代にこそ活きるのだと、この一枚のスライドに励まされた気がしました。

コスト分岐点は「月195件」

どちらが優れているかではなく、どこで使い分けるか。コスト面では以下の数字が示されました。

結論：2択ではなく、調査ごとに責務を分けて併用する

使い分けの軸は【COST】と【CONTEXT】の2つです。

  • 自作SRE Agent：既知・高頻度の定型的な一次調査を繰り返し実行。Code / PlaybookなどのPrivate Context・独自Integrationが強み
  • Bits Investigation：低頻度・スポットの未知・複雑な調査へ重点注入。Live Telemetry / Topologyによる仮説検証のAutonomyが強み

コード、Playbook、DB、サポートケース、Telemetryといったコンテキストは両方に渡せるため、責務の境界は固定ではなく、調査ごとに動かすという運用です。

PLAIDの答え②：Bits InvestigationをBits.mdでさらに賢くする

続いて、Bits Investigationの誤ったRCAをどう改善したかという実例パートです。誤るケースを調べてみると、エンジニアなら必ず知っているコンテキストやナレッジが与えられていないことがほとんどだったそうです。

事例1：ログ増加アラート

期待するRCAは、メトリクスを組織タグで切り分け、テスト環境で発生していること、定期的に行われている負荷試験が疑わしいことから「想定内のログ増加」と判断する流れです。

しかし実際のBits Investigationは、本番環境のErrorに着目してDB Timeoutを調査し、DB Latencyを原因候補として提示。異常自体は実在するものの、今回のログ増加の直接的な原因ではありませんでした。

改善方法はシンプルで、KnowledgeとContextをBits.mdに追加するだけ。「メトリクスに組織タグが含まれる場合、調査開始時に組織タグで調査対象を切り分ける」「組織タグにはテスト環境と負荷試験環境がある」「テスト環境では定期的に負荷試験が実施される」を追記したところ、正しいRCAを行えるようになったそうです。

事例2：APIエラー数の増加

期待するRCAは、エラーログからDB Timeoutを特定し、APIサーバーの接続先DBの負荷増加から「DB起因」と判断する流れです。

しかし実際は、別リージョンかつAPIサーバーと依存関係のない分析用DBの遅延を原因候補として提示してしまいました。

こちらもBits.mdに「システムはマルチリージョン構成になっている」「リージョンを識別するためのタグの命名規則」「メトリクスの相関からシステムの関係性を構築するのではなく、Service Mapを依存関係の起点として参照する」「プロダクトへの影響が無い分析用DBの存在」を追加することで、適切なシステムの依存関係とリージョンを利用した正しいRCAを行えるようになりました。

この2つの事例は、AIの間違いを「AIがまだ賢くないから」で片付けず、「自分たちが暗黙知を渡せていなかったから」と捉えて改善する姿勢そのものが学びでした。誤ったRCAを見抜き、足りなかったコンテキストを言語化して渡す——これこそが「確認・レビューする人」の仕事なのだと思います。

Telemetryだけでは足りない。コンテキストプラットフォームへ

まとめとして示されたのは、TelemetryだけではBits AIには足りず、KnowledgeとContextが必要というメッセージです。

さらに、Bits Investigationを賢くする過程で得られたKnowledgeとContextはDatadogに蓄積され、Bits AIを含む様々なCoding Agentが参照できます。Datadogを「コンテキストプラットフォーム」として活用することで、開発体験そのものを向上させられるという展望が語られました。

まとめ

今回のセッションは、「AIに運用を任せられるか？」という漠然とした問いを、監視保守メンバーである私にとって「これからの運用の仕事は何か？」という自分ごとの問いに変えてくれました。

特に印象に残ったのは以下の3点です。

  • 30分〜数時間かかっていた調査が「数分＋確認のみ」になる。そしてAIが最初に担うのは「高頻度×既知×定型」の一次対応——まさに一次対応をしている私たちの領域から、仕事の形が変わっていく
  • 動かすのは簡単。ただし、任せ続けるのが難しい。接続の維持、情報の鮮度、回答の信頼性——AIエージェント自身が新たな運用・保守の対象になる
  • 誤ったRCAの原因はコンテキスト不足がほとんど。暗黙知をBits.mdのような形式知に変えて渡すことが、AIを「任せられる存在」に育てる

手順書どおりの対応であっても、「なぜこの手順なのか」を理解しながら一次対応を重ねること。手順書にない事象を見極めて、正しくエスカレーションする判断力を磨くこと。そうした日々の積み重ねこそが、AIの調査を確認・レビューし、AIエージェントを任せ続けられる状態に保つ力の土台になるはずです。仕事を奪われる不安よりも、「監視・保守の対象にAIエージェントが加わる時代の運用者」としてやるべきことが明確になった、そんなセッションでした。

「AIエージェントに調査を任せ、人がそれを支える」——この新しい運用のかたちを肌で感じられた、非常に濃いセッションでした。私自身も日々の業務に活かせるよう精進していきたいと思います。