AIエージェントとSRE - o11yをどう見直すか

著者：ryuichi_1208
目次

はじめに

ryuichi1208（ @ryuichi_1208 ）です。

ここ数ヶ月、SREの文脈で「AIエージェント」という言葉を聞かない月はなくなりました。各社のモニタリングSaaSはこぞってAI機能を載せ、インシデント対応をまるごと自動化しようとするスタートアップも次々と現れています。筆者自身も cherry-bomb という小さなインシデント対応ツールを自作しながら、「結局このAIたちはSREの何を、どこまで肩代わりしてくれるのか」を手を動かして確かめています。

本稿では、まずSREにAIエージェントを取り込むアプローチを3つに整理し、実在するプロダクトやOSSがそれぞれどこに位置するのかを地図のように眺めます。そのうえで本題として、「AIエージェントが当たり前になる時代に、Observability（以下o11y）基盤をどう見直すべきか」 を掘り下げます。AIを賢くする以前に、AIが推論できるだけのインプットが整っているか——というのが本稿の問いです。

3行まとめ

  • これからのo11yは「人間が見る画面」ではなく、「AIエージェントが推論するためのインプット基盤」として再定義していく必要がある
  • AIの力を引き出すには、断片的なツール群を統合し、ビジネス影響からシステム深部までを一貫したコンテキストで機械的に辿れる設計が不可欠
  • ログの構造化やノイズ削減を徹底し、「AIがいかに探索しやすく、質の高い情報を段階的に取得できるか」が運用の成否を分ける新たな評価軸となる

SRE×AIエージェントの現在地

AIを活用したSREの進化は、大きく3つのアプローチに分類できると考えています。

Copilot型 — 人間の調査と意思決定を支援する

ログやトレースの横断的な分析、クエリ生成、インシデント要約などを通じて、従来人間が行っていた調査作業を高速化するアプローチです。あくまで判断するのは人間で、AIはその手前の「探す・まとめる」を肩代わりします。

AIOps型 — 検知と相関・因果分析を主軸にする

システムの依存関係やトポロジーをもとに、単なる相関ではなく因果関係の特定を目指すのがこのアプローチです。従来の監視の延長線上にありながら、より高度な自動化と抽象化を実現しようとする方向性といえます。

Automation型 — 対応そのものを置き換える

Runbookやオペレーション手順をコード化し、インシデント発生後の診断や復旧を自動で実行する仕組みが中心です。予兆検知によって障害そのものを未然に防ごうとするアプローチもこの文脈に含まれます。単なる支援ではなく「意思決定と実行の自動化」を目指しており、SREの役割そのものを再定義する可能性を持っています。

エージェントの実例マップ

上記の3分類に、実在するプロダクトやOSSを当てはめてみます。

Copilot型

  • New Relic AI — LLMベースのクエリ生成（NRQL）、インシデントの要約、ログ・トレース横断の調査支援ができる、典型的なCopilot型です。
  • Bits AI — Datadogが提供するアシスタント。観測データの上に会話的な調査体験を載せています。
  • Rootly — SlackベースのIncident管理を軸に、AIが状況整理・ステータス更新・ポストモーテムの自動生成を担います。インシデント運用の効率化に特化していて、War Roomの進行役に近いイメージです。

AIOps型

  • Dynatrace（Autonomous Operations） — 「因果関係AI」が強みです。単なる相関ではなく、システム間の依存関係を理解して「なぜ起きたか」を高い精度で特定することを目指しています。

Automation型

  • Grepr（Proactive AI SRE Agent） — 「問題が起きてから対処する」リアクティブな運用から、「問題が起きる前に防ぐ」プロアクティブな運用への転換を目指しています。データ効率化と予兆に特化したスタートアップで、個人的に一番気になっている存在です。
  • Shoreline.io — Runbookのコード化、自動修復（Auto-remediation）、オペレーションの再現性が軸。「人間のコマンド操作」を置き換えることが目的で、NVIDIAが買収しました。
  • elida — LLMエージェントでRunbookを実行し、自動診断＋自動復旧を行うOSS。「アラートを見て、ログを検索し、原因を特定して、コマンドを打つ」というワークフローを、検知後のアクションごとLLMに置き換えようとしています。

どの型にも効く土台 — 観測データの最適化

  • Observo.ai — ログ／メトリクスの最適化、ノイズ削減、コスト削減を担います。SREというよりData Engineering寄りですが、観測基盤そのものの最適化はSREの関心事でもあり、後述するo11y本論とも深く関わってきます。

自作OSS：cherry-bomb で見えてきたこと

筆者の cherry-bomb は、Slackネイティブで完結する設計（Rootlyのような専用UIの代わりにSlackスレッドで完結）、プラグイン式で監視ツールを横断できる構成（Datadog・PagerDuty・AWS等を統合可能）、そして承認フローによって「人間のループ」を明示的に組み込んでいる、という3点を特徴にしています。

まだどの方向に尖らせるかを決めきっておらず、それぞれを中途半端にできる状態ではあるのですが、実際に作って触ってみた感覚として、自分の使い方ではCopilot型で進めるのがしっくりくると感じました。AIに全部任せて自動復旧まで走らせるより、調査の初動をAIに支えてもらい、最後の判断は人間が握る——その分担が現実的だと思えたのです。

ここで重要なのは、Copilot型であれAutomation型であれ、AIの出力の質は、AIが読みに行くo11y基盤の質に完全に依存するという点です。ここからが本稿の本題です。

本論：o11yを「人間が見る画面」から「AIが推論する基盤」へ

目指したいのは、障害調査を属人化させず、AIと人間が役割分担しながら、誰でも・素早く・根拠を持って動ける状態です。

役割 担当
o11y基盤の横断的な調査と推論・証拠の提示 AI
提示された情報をもとにした意思決定・対処 人間

AIがすべてを自律解決するのではなく、co-pilotとして調査の初動を支える関係です。そのために必要なのが、AIが探索しやすい「o11y基盤の設計」と、「調査の型の標準化」です。

graph TD
    Alert[アラート / 異常検知] --> AI

    subgraph AIの担当
      AI[AIエージェント]
      AI -- 横断クエリ --> O11y[統合されたo11y基盤]
      O11y -- 構造化データ --> AI
      AI --> L1[レイヤー1: ビジネス影響]
      L1 --> L2[レイヤー2: アプリケーション動作]
      L2 --> L3[レイヤー3: システム状態]
      L3 --> Evidence[根拠つきの仮説・証拠]
    end

    Evidence --> Human[人間]
    Human --> Decision[意思決定・対処]

AIが探索しやすいo11y基盤の設計

1. テレメトリのサイロ化を脱し、単一コンテキストを構築する

個別最適化されたツール群を人間が行き来するだけでは、AIを活用した高度な障害調査には限界があります。AIにとって重要なのは、複数のテレメトリを横断して一つの文脈として扱えることです。以下の情報は、本来分断されるべきではありません。

  • CPU・メモリ・ネットワークなどのインフラメトリクス
  • エラートラッキング
  • ログ（DFAログ、CUJログ、システムログなど）
  • アプリケーション言語レイヤーでのプロファイル
  • トレース
  • デプロイ履歴・Feature Flagの変更履歴

AIエージェントはMCPなどを通じてこれらをクエリし、異常の兆候をたどりながら原因調査や影響ユーザーの特定を進めます。o11y基盤には、機械的に探索・関連付けしやすい形での統合が求められます（Sentryなどは便利なので、Datadogでいう Integration を使って一箇所に集約していくイメージです）。

2. コンテキストは量より質

何も考えずに大量のログやイベントを渡すと、コンテキストウィンドウをあっという間に埋めてしまいます。重要なのは「AIに全部を渡すこと」ではなく、ノイズを減らし、調査に必要な情報だけを段階的に渡せることです。

テレメトリ設計に求められる要素は次のとおりです。

  • エラーや異常イベントを高い粒度で集約できる
  • 時系列・サービス・テナント・ユーザー単位で素早く絞り込める
  • 関連するトレース・ログ・プロファイルへ自然にドリルダウンできる
  • AIが扱いやすい構造化データとして取得できる

AI時代のo11yでは、「多く取れること」より必要な単位で切り出せることの価値が高くなります。

3. 設計原則チェックリスト

観点 内容
構造化 ログは単なる文字列ではなく client_id・request_id 等で検索・集約できる形にする
横断的な関連付け 一つの異常イベントから、関連トレース・ログ・デプロイ・ユーザー影響へ辿れる
ノイズ削減 重複ログ・意味のないエラー・コンテキストのないメッセージを排除する
ビジネスコンテキスト 「どの顧客に」「どの機能で」「どの程度の失敗が起きたか」を結びつけられる

調査の型：レイヤーごとに探索空間を絞る

障害対応において、AIにいきなり「原因を調べて」と指示しても、良い結果にはなりにくいものです。調査はレイヤーを分け、それぞれで得た情報を別の探索条件に変換していくことが重要です。この型を定義しておくことで、誰が対応しても同じ精度で初動調査ができるようになります。

レイヤー1: ビジネス影響の確認

まず確認すべきは「何が壊れているか」ではなく、誰にどの程度の影響が出ているかです。

  • どのユーザー・プランに影響があるか
  • 特定顧客のみの問題か、全体的な問題か
  • 売上や継続利用に影響する可能性はあるか

影響範囲が「全体の障害」なのか「一部顧客の問題」なのかが分かるだけで、その後の探索空間を大きく絞れます。またビジネス上の情報にアクセスできれば、クライアントへの報告なども手動の調査が不要になる世界があり得ます。

レイヤー2: アプリケーション動作の確認

  • 影響が出ている機能・ユースケース
  • エラー率が高いエンドポイント
  • レイテンシが悪化している処理
  • 特定バージョン・デプロイとの相関

「特定プランの顧客で、特定機能だけが失敗している」と分かれば、調査対象を関連する処理に絞れます。

レイヤー3: システム状態の確認

  • CPU・メモリ・ディスク・ネットワークの異常
  • コンテナ再起動・OOM Kill
  • 外部APIのレート制限・エラー増加
  • インフラ変更・デプロイとの相関

予測と予防のための「学習データ」としてのo11y

AI時代のo11y基盤は、インシデント対応の道具であると同時に、組織の失敗から学ぶための学習データセットであるべきだと考えます。インシデント対応だけが手段であれば、システムは常に受動的なままです。蓄積されたo11yデータをAIが継続的に参照できる状態にすることで、次の3つの能動的なアプローチが可能になります。

  • マージ前のリスク分析
    • 過去のインシデントを特定のコードパターン・サービス・デプロイメント特性と関連付けることで、リスクの高いPRをマージ前に検出できる
    • 一般的なヒューリスティックではなく、本番環境の履歴から直接学習されるため、チームの実態に即した精度が期待できる
  • 障害の予兆検知
    • 過去の障害時に実行されていたクエリをバックグラウンドで継続的に走らせ、同じパターンが再び現れた場合に障害発生前にエンジニアへ通知できる
  • 顧客中心の優先順位づけ
    • テレメトリを顧客・ビジネス影響と同じ基盤に保存することで、一般的なエラー数ではなく実際のユーザーの不満を基準に信頼性対策の優先順位を決定できる
    • 「今四半期に上位10社の顧客に影響を与えた問題はどれか」「最も多くのサポートチケットが発生しているサービスはどれか」といった問いに答えられるようになる

導入ロードマップ

以下の順序には依存関係があります。集約先が決まらないとテレメトリ設計が宙に浮き、設計が整わないとMCPで何を公開すべきかも定まりません。土台から順に進めることを推奨します。

Step 1: テレメトリの集約先を決める

メトリクス・ログ・トレース・エラーが散在している状態では、AIの横断的な探索は成立しません。ツール選定よりも「一箇所から横断クエリできる状態を作る」という目標を、チームで先に合意することが重要です。

Step 2: テレメトリ設計の見直し

client_id・request_id などの構造化フィールドが揃っているか、重複や無意味なイベントが流れていないかを棚卸しします。全部作り直す必要はなく、「あれば助かった」フィールドから優先的に追加していくのが現実的です。

Step 3: MCPサーバの整備

テレメトリの品質が一定以上になったら、AIエージェントからアクセスできる口を作ります。「ビジネスレイヤーの影響確認」「エラー集計」「トレース取得」など、障害調査でよく使う操作から優先的に公開すると効果が出やすいです。

Step 4: 調査方法の標準化と普及

ツールが整っても、チームに使われなければ意味がありません。本稿で整理したレイヤー構造をRunbookやプロンプトテンプレートとして文書化し、誰が対応しても同じ品質で初動調査ができる状態を目指します。

Step 5: 障害訓練の定期実施

ツールと型が整ったら、意図的に対応筋を維持する仕組みも必要です。AIが初動を担うようになると、人間が手を動かす機会は自然と減っていきます。定期的なゲームデーやカオスエンジニアリングを通じて、AIの推論が正しいかを人間が判断できる状態を維持しましょう。訓練の中でAIと一緒に動くことは、「co-pilotとして使いこなせるチーム」を育てる場にもなります。

まとめ

SREにAIエージェントを取り込むアプローチをCopilot型・AIOps型・Automation型に分け、実在するプロダクトを地図に置いたうえで、o11y基盤の見直しを論じてきました。

結論として、当面のSREにとって現実的なのは、AIをco-pilotとして調査の初動に据え、最後の意思決定は人間が握るという分担だと考えます。そしてその分担を成立させる前提は、AIに賢いモデルをあてがうことよりも、AIが探索しやすいo11y基盤を用意することにあります。

AI時代のo11yの評価軸は、「どれだけ多く取れるか」から「必要な単位でどれだけ的確に切り出せるか」へと移っていきます。テレメトリを統合し、構造化し、ノイズを削り、ビジネス影響まで一貫して辿れるようにする——地味ですが、この土台づくりこそが、AIエージェントを本当に役立てるための最短経路だと思います。

この記事が、みなさんのo11y基盤を見直すきっかけになれば幸いです。🙏