10月28日、The Pragmatic Engineerが「AI SRE: what is it, how could it change on-call – and does it work?」と題した記事を公開した。深夜のアラートに叩き起こされ、眠い目をこすりながらダッシュボードを掘り下げる——そんなオンコール対応の風景を、AIが変えようとしている。コードを大量生成するAIがインシデントをも増やしている今、インシデント対応にAIを使うという逆説的な流れが加速している。本記事では、AIを活用したオンコール・インシデント対応ツール「AI SRE」の実態と、実際の運用現場での有効性について詳しく紹介する。

なぜ今「AI SRE」が注目されているのか

背景にあるのはシンプルな「信頼性の数式」だ。記事内で示された考え方によると、インシデントの発生率は以下のように整理できる。

インシデント発生率 = 変更頻度 × 1回の変更が障害を起こす確率

AIエージェントの普及により、多くのテック企業でPR（プルリクエスト）の頻度が1年で2倍以上に増加している。変更頻度が上がれば、それだけインシデントも増える。Rootlyのデータによると、ページ（オンコール呼び出し）の件数は1年前より増加しており、業務時間外のページはほぼ2倍になっている。

コードを大量に生成・デプロイするAIが、インシデントも増やしている。だからこそ、インシデント対応にもAIを使おう、という流れが自然に生まれてきた。

「AI SRE」という名称への違和感

取材に応じた3社（Rootly、incident.io、ResolveAI）はいずれも、この名称が好きではないと答えている。SRE（Site Reliability Engineer）はオンコール対応だけでなく、システム全体の信頼性設計を担う職種であり、「AI SRE」という呼び方は実態より大げさだ。「自律型信頼性エージェント」「自動修復エージェント」といった代替案も試されたが、定着しなかった。本記事でもこの用語を使うが、実態はAIによって強化されたオンコール・インシデント対応ツールと理解した方が正確だ。

実際に何をしているのか：調査フェーズの自動化が主戦場

AI SREツールが最も力を発揮するのは、アラートが発火してから根本原因を特定するまでの「調査フェーズ」だ。従来、オンコールエンジニアは以下を手動で行っていた。

• アラート内容の確認
• ダッシュボードでの影響範囲の把握
• ランブック（障害対応手順書）の参照
• Datadog、Sentry、Honeycombなどのログ・オブザーバビリティツールの確認

incident.ioのエージェントは、これを並列化する。メインのオーケストレーターが調査の方向を決め、複数のサブエージェントに調査を振り分け、5分後にはオンコールエンジニアがSlackのインシデントチャンネルに参加した時点でAIによる調査サマリーが出揃っている、という仕組みだ。

3社はすべてSlackをメインのインターフェースとして使用している。エンジニアはSlack上でAIエージェントに指示を出し（「このサービスのステータスを確認して」「このログを掘り下げて」）、エージェントはSlack上で結果を返す。従来であれば複数のツールを行き来しながら手動でかき集めていた情報が、会話の流れの中に集約されるという点で、オンコールエンジニアの認知負荷を大きく下げる可能性がある。

自動修復はどこまで進んでいるか

調査フェーズの自動化が着実に進む一方で、AIが自律的にコードを修正してPRを出すという「自動修復」の領域は、各社のアプローチが明確に分かれる。現時点では、いずれのベンダーも人間の承認なしに本番環境を変更するところまでは踏み込んでいない。

• incident.io：自律的なPR作成は技術的に実証済みだが、顧客は自社の既存コーディングエージェントを使いたがる傾向がある。そのため、インシデントのコンテキストをエンジニアに渡すことに注力している。
• ResolveAI：小規模な修正は自社ツールでPRを作成し、大きな変更は顧客のコーディングエージェントに引き渡すハイブリッド方式。
• Rootly：エージェントがPRを作成し、別のエージェントがマージの安全性を判断して自動マージする、という完全自律化を目指している。現時点では人間の承認が必要。

約1年半前の2025年5月に開催されたMicrosoft Build 2025でデモされた「Azure SRE Agent」のように、人間の介入なしにAIが本番環境を変更するシナリオは話題を集めたが、現時点ではいずれのベンダーもその水準には達していないというのが実情だ。

エージェントの精度をどう担保するか

調査フェーズの自動化が有効であっても、エージェントが誤った根本原因を提示すれば、エンジニアの判断を誤った方向に誘導しかねない。精度の担保は、AI SREにとって最も難しい課題のひとつだ。各社が採用しているのが以下のアプローチで、単純に高性能なモデルを使えば解決するという話ではないことが見えてくる。

• 敵対的エージェントによる仮説検証：調査エージェントが立てた仮説を、別のエージェントが意図的に反論・検証する。複数の視点を強制的に持ち込むことで、結論の偏りを抑える。
• 複数モデルの組み合わせ：単一モデルへの依存を避け、それぞれの強みを活かす構成をとる。
• バックテスト：過去のインシデントデータで精度を評価し、継続的に改善する。

ただし「精度」の定義は企業ごと・チームごとに異なり、汎用的な指標は存在しないと各社は認めている。3社はいずれも調査エージェントを少なくとも1度は作り直したと明かしており、AIをオンコールフローに統合することの難しさを示している。現場ごとのシステム構成や文化に応じたチューニングが不可欠であり、「導入すれば即効く」という性質のツールではないことが伝わってくる。

自社開発か、ベンダー利用か

AI SREツールが有効に機能するには、テレメトリ、ログ、オブザーバビリティデータ、場合によってはソースコードリポジトリへのアクセスが必要になる。この「信頼の問題」が、中規模以上の企業が自社開発に踏み切る主な理由だ。実際、OpenAIは「Sevbot」という独自のAI SREボットを構築しており、ING銀行のエンジニアも自社開発中と著者は報告している。

ゼロデータ保持（ZDR）を提供するベンダーでも、システム侵害のリスクはゼロではなく、また自社インシデントデータでの継続的な学習という面ではハンデを背負う。一方で、AI SREスタートアップはこれを専業としており、長期的な機能の充実度では自社開発を上回る可能性が高い、というのが記事の見解だ。

オンコールエンジニアへの影響

AI SREの普及によって変わること、変わらないことが整理されている。

• AIが起因するインシデントという新カテゴリの出現：AIエージェントが引き起こした障害の調査は、従来とは異なる難しさがある
• ページ数は減るが、残るインシデントは難しくなる：単純なアラートはAIが処理し、人間に届くのはより複雑な問題になる
• スキルの低下リスク：インシデント対応スキルが鈍らないよう、Uptime Labsのような障害対応シミュレーションツールを活用することが有効と記事では提案されている

完全自律型エージェントはまだ現実ではないが、アラートのトリアージ（優先度判断）や不要なアラートの抑制は着実に進んでいる。

詳細はAI SRE: what is it, how could it change on-call – and does it work?を参照していただきたい。