こんにちは。ジェダイパンくず☁️ です。

Google SRE チームが公開したレポート「AI in SRE: How Google is Engineering the Future of Reliable Operations」を読んで、その内容を体系的にまとめました。著者は Ioannis Papapanagiotou、Stevan Malesevic、Chris Heiser、Ruslan Meshenberg の4名です。

読んでみて感じたのは、これは単なる「AI でアラートを減らそう」という効率化の話ではない、ということです。SRE そのものが AI によって構造的に変容していく過程を、具体的なシステム名・フレームワーク・測定結果を交えて論じた内容になっています。以前 2026年6月現時点において SRE がどう AI に向き合っているか調べてみた という記事で業界全体の動向を俯瞰しましたが、この Google のレポートはその中でも「いつ・どこまで自律度を上げるか」をデータで決める仕組みまで踏み込んでいる点で抜きん出ています。本記事ではその設計思想を順を追って整理します。

なお本記事の後半、具体的な方法論を扱う章には「自分たちの現場での実践方法考案」という節を添えました。自分たちの現場では現時点では Google Cloud + Datadog + AWS というプラットフォームで構成されていて、Google ほどの規模はありません。なので Google が内製した仕組みを、なるべくプロダクトを利用する方向に反転させて考えています。その最有力候補が、DASH 2026 で AI 機能を大きく広げた Datadog の Bits シリーズです。後半の具体論に対して「これは Google だから出来ることなのか？日本のスタートアップでも現実的に回せるのか」を考えていきます。

AI SRE とはどのような概念なのか

AI 支援開発によって生産性が最大4倍向上することを目指す組織が急増しています。それ自体は良いことなのですが、問題はその先にあります。コードレビューや運用プロセスという「人間がボトルネック」になる部分は、コード生成と同じ速度では4倍速になりません。機械生成コードの量に対して従来のコードレビュー手法はスケールせず、システム複雑性の急速な増加に標準的な運用プロセスが追いつかない、という歪みが顕在化します。

Google SRE はこの課題に対して、AI を既存業務に貼り付けるのではなく、信頼性の基盤そのものを作り直すという立場を取っています。

“SRE is architecting a new foundation for reliability”

その新しい基盤として、3つの中核コンポーネントを開発しています。本記事の後半で詳しく扱いますが、まず全体像として以下を押さえておくと読みやすくなります。

コンポーネント 役割
AI Operator 本番アラートに自動対応するオペレータ
Actus 厳密なガードレール
IRM Analyzer 人間の運用知識を継続的に取り込む評価パイプライン

AI Operator が「考える」エンジン、Actus が「実行する」ゲート、IRM Analyzer が「学習素材を供給する」パイプライン、という分担です。この3者が分離されている点が後述する安全設計の肝になるようです。

6つのリスク領域

本番環境で AI を動かすにあたり、Google はまず何が危険なのかを6つのリスク領域として明示しています。

  1. 進化する人間の専門知識：オペレータが「手動で直す人」から「AI エージェントを監督するアーキテクト」へシフトする変化への対応
  2. 説明可能性と信頼の構築：自律エージェントの判断をリアルタイム追跡し、すべての意思決定を監査可能にする必要性
  3. データ整合性とバイアス軽減：本番環境データの品質と完全性、そして公平性の確保
  4. 動的環境でのモデルドリフト：進化し続けるシステム行動へ AI モデルが適応できるか
  5. セキュリティベクトル：敵対的攻撃・データポイズニング・プロンプトインジェクションへの対策
  6. 意図しない自動化の結果：フィードバックループや連鎖障害の防止

安全保障の三要素

これら6つのリスクに対し、Google SRE は Safety Trifecta と呼ぶ3本柱のモデルを採用しています。透明性・リアルタイムリスク評価・段階的認可の3つで、いずれもすべてのエージェントシステムに対するアーキテクチャ上の必須要件として位置づけられています。

(1) 透明性（Transparency）

「AI のアクションと判断は観測可能かつ理解可能でなければならない」という原則です。

“AI actions and decisions must be observable and understandable”

エージェントは使用したシグナル、検討した仮説、行動選択の理由、信頼度レベルをすべて記録します。

(2) リアルタイムリスク評価（Real-time Risk Evaluation)

提案されるすべての自動アクションは、現在の本番状態・エラーバジェット残量・進行中のデプロイメント・時間帯といった文脈に基づいてリスクが評価されます。同じ操作でも「深夜・デプロイ直後・エラーバジェット枯渇寸前」なら危険度は跳ね上がる、という当たり前の感覚をシステムに織り込んでいるわけです。

(3) 段階的認可（Progressive Authorization)

自律性レベルを段階的にスケールさせる仕組みで、後述の L0〜L4 モデルと連動します。エージェントは限定された権限から始まり、信頼性を実証するにつれて権限が拡大します。

アーキテクチャ上のガードレール

Safety Trifecta が思想だとすれば、それを実装レベルで担保するのが以下のガードレールです。

ガードレール 内容
アンビエント・アクセスなし エージェント固有の認証と最小権限の原則。開発者の credential を流用させない
エージェント・サーキット・ブレーカー エージェント固有のレート制限と自動遮断。暴走ループを止められるようにする
ドライラン必須化 dry_run=true モードの標準実装。本番を変更する前に影響を予測する
ゼロトラスト実行 安全機構を備えたツール経由のみ本番操作を許可。エージェントが本番を落とせない

SRE 自律性の5段階モデル（L0〜L4）

自律性を5段階で定義した SRE Autonomy Levels です。自動車の自動運転レベルと同じ発想ですが、SRE 文脈に合わせて「監視・調査・承認・実行・自己主導」という5軸で各レベルを評価しています。

レベル 監視 調査 承認 実行 自己主導
L0：手動 人間 人間 人間 人間 人間
L1：支援 自動 自動 人間 人間 人間
L2：部分自律 自動 自動 人間 自動 人間
L3：高度自律 自動 自動 自動 自動 人間
L4：完全自律 自動 自動 自動 自動 自動

各レベルの位置づけを言葉で補足すると、以下のようになります。

  • L0（手動実行）：すべてが人間駆動の、従来の SRE スタイル。
  • L1（支援）：AI が分析と提案を提供し、人間が承認・実行する。後述のアラート充実化や Incident Hypothesis がここに該当する。
  • L2（部分自律）：AI が実行前に人間の明示的承認を必要とする。ステージングや安全なパスが確立されている操作向け。
  • L3（高度自律）：十分に定義されたシナリオで AI が独立実行する。Google の AI Operator は軽微インシデントに対してこの L3 を達成している。
  • L4（完全自律）：複数ステップの解決と複雑なシナリオ管理までを AI が担う。障害発生から安定状態の確認までインシデントライフサイクル全体を回す段階で、現時点では研究段階。

ここで注目すべきところはレベルの昇格が自動でも主観でもなく、統計的な成功績に基づいて決まる点です。前述の記事でも書きましたが、エージェントは人間が検証した過去インシデントに対して統計的に有意な成功率を示して初めて、次のレベルに上がれます。

昇格 ゲート条件
L0 → L1 監視・調査を自動化できるツールの整備
L1 → L2 正確な提案生成と、安全な実行パスの確立
L2 → L3 高精度・高信頼性の実証。リスクに比例した、より厳格な検証
L3 → L4 マルチステップ解決能力と、動的な戦略適応の実証

「いつ自律度を上げるか」を推測ではなく計測値で決める。なのでここも計測する必要がありそうです。

人間の運用知識を継承する評価フレームワーク

自律性をデータで判定する以上、その判定の物差しとなる「人間の理想的な対応」データを大量に集める必要があります。Google は人間の運用経験を「ゴールデンデータ」として継続的に収集・評価する仕組みを構築しています。

IRM-Analyzer

インシデント管理ツールのチャット、インシデント記録、コマンドラインエントリといった断片的なソースから、AI が以下を自動抽出します。

  • 主要イベント（タイムライン）
  • 実施したアクション
  • 使用したツール
  • 検討した仮説

これをもとに、各インシデントで「人間が実際にどう動いたか」という操作軌跡を時系列に再構成し、構造化します。この軌跡がエージェントの学習・強化ループ・プレイブック改善の素材になります。

3階層のデータ品質分類

集めたデータはすべて同じ品質ではありません。Google は生成方法と信頼度に応じてデータを3階層に分類しています。

階層 生成方法 信頼度・特性
Bronze 自動ラベラーによる発見的生成 低〜中。高速だが品質は粗い
Silver プログラム生成 + Gold データとの数学的キャリブレーション 中。品質と量を両立
Gold 人間専門家による検証済みデータ 高。キャリブレーションの基準となる

ここで問題になるのが、品質の粗い Bronze データでエージェントを評価すると「精度ギャップ（accuracy gap）」が生じることです。これを埋めるために、層化サンプリング（stratified sampling）で多様なインシデントを選び出して人間がレビューし、Gold データを継続生成します。そして Gold データを基準に Silver データを数学的に較正し続けることで、安価に量を確保しつつ精度のギャップを縮めていく、という流れになっています。

Golden データの生成フロー

問題は、こうした高品質ラベルをどうやって追加負担なく集めるかです。Google の答えは、収集作業を通常のインシデント対応ワークフローに溶け込ませることでした。

オンコーラーがインシデント解決を宣言する際、システムが構造化された緩和提案を自動生成します。オンコーラーはそれを承認・修正・拒否するだけで、結果的にシームレスに高品質ラベルが収集される仕組みです。普段の作業の延長で済むため、ラベリングのための追加負担がほとんど発生しません。

継続的夜間評価（Nightly Evals）

集めた Golden データは、毎晩の自動評価でエージェントの品質計測に使われます。直近の実インシデントからなる動的なデータセットに対して、2種類の評価手法を組み合わせる点がポイントです。

  1. LLM-as-a-Judge：推論の妥当性・調査軌跡・ツール呼び出しといった定性的な側面を、Golden 軌跡と照らして採点する
  2. 決定論的スコアリング：最終出力の精度・再現率を機械的に測定する。緩和アクションのパラメータ（対象バイナリやバージョンまで含む）が Golden Data と完全一致する場合のみ「正確」と判定する

2つ目の判定基準が厳しいのが特徴です。「だいたい合っている提案」は不正解扱いで、実際にそのまま実行可能な正確なパラメータまで一致して初めて正解とみなされます。曖昧な提案を評価上の合格にしないことで、自律実行に耐える精度を担保しているわけです。

SRE ライフサイクル全体への AI 統合

AI を単一のツールとして捉えるのではなく、SRE のライフサイクル全体に段階的に組み込むロードマップを示しています。観察 → アラート充実化 → 調査支援（L1) → 自律緩和（L3) という順で、人間の関与を少しずつ減らしていく構成です。

1. 本番環境の観察：Detectr

従来のメトリクス・ログ・トレースベースの監視には「既知の障害モードしか検出できない」「実際の顧客体験を捉えられない」という根本的な限界があります。Google が開発した Detectr は Gemini を活用し、以下のような非構造化のユーザーシグナルを分析することで、テレメトリには現れない未知の障害を早期検出します。

  • カスタマーサポートチケット
  • 外部フォーラムへの投稿
  • ソーシャルメディア

ただ大量のユーザー投稿をそのまま読むだけではノイズに埋もれてしまいます。Detectr はマルチパスの AI パイプラインでこれを処理します。

パス 処理内容
Filter 無関係な投稿を除去し、データを分類する
Cluster 関連する報告をグループ化し、障害候補を特定する
De-Noise ノイズの多いクラスタを除外する
Report トリアージ用の構造化された障害通知を生成する

関連フィードボリュームそのものが信号となり、ノイズは段階的にフィルタリングされます。Cloud・Ads・YouTube・Search の複数チームで採用され、早期検知と深い状況理解によって累計で数百時間の顧客影響削減を達成しています。

2. アラート充実化：AI Alert

AI Alert は、未加工のアラートが人間に届く前に横取りし、リッチなコンテキストで補強して初期調査時間を削減します。約2分という厳密な実行時間枠の中で、以下を並列クエリします。

  • モニタリングシステム
  • ロギングプラットフォーム
  • 本番変更ログ
  • 依存関係グラフ

設計上重要なのは、AI Alert があくまで読み取り専用モードで動作し、推測的な結論ではなく検証可能なファクトとエビデンスベースの洞察だけを提示する点です。すべての所見にはソースへのリンクが付き、人間が裏取りできるようになっています。本番を変更する AI Operator とは役割をはっきり分けているわけです。

3. インシデント調査支援（L1）

ここからは人間が承認・実行する前提で、AI が調査を支援する L1 のツール群です。

Incident Hypothesis（インシデント仮説）

LLM と RAG（検索拡張生成）を組み合わせ、以下を総合分析して根本原因の有力候補と、それを検証するための具体的な手順を提示します。

  • リアルタイム異常
  • サービスプレイブック
  • アプリケーションログ
  • インシデント管理データ
  • 類似過去インシデントのパターン

A/B テストで MTTM（平均緩和時間）を10% 削減することが確認されています。結果はオンコーラーが普段使う調査・監視ツールの中に直接表示され、コンテキストスイッチを最小化しています。

Investigation Dashboard（調査ダッシュボード）

インシデント調査では、複数の静的ダッシュボードを行き来してデータを探し回る「宝探し（scavenger hunt）」が認知負荷を押し上げます。Investigation Dashboard はこれを解消するもので、動的な AI 駆動システムがインシデント固有の「統一ビュー（single pane of glass）」をオンデマンド生成します。オンコーラーと障害の性質の両方に合わせて中身が変化するのも特徴です。

分析は4段階の能力で構成されます。

  1. 異常検知：ML モデルが時系列の視覚的偏差をフラグ化する
  2. 変化の相関：異常をアラート信号と関連付ける
  3. 調査価値評価：その異常が深掘りに値するかを判定する
  4. 根本原因特定：ロールアウト・実験・容量変更などの候補が真の原因かを見極める、最も高精度な分析

このダッシュボードは100以上のドメイン固有「トラブルシューター」を並列実行する拡張可能なエコシステムになっています。結果として、ML 駆動の異常検知だけで検出数が195%増加し、ダッシュボード全体では対象インシデントの MTTM を約44%削減しています。

Antigravity CLI（Gemini 駆動 CLI）

SRE がターミナルから自然言語で本番環境を操作できるインターフェースです。内部では Model Context Protocol（MCP）を使った Production Agent サーバーが動作し、以下のツールカテゴリを提供します。

カテゴリ 機能
可観測性 時系列データクエリ、ログ検索、異常検知
インシデント管理 インシデント詳細取得、ステータス更新、バグ起票やポストモーテム出力
トラフィック制御 トラフィックシフト、容量変更
インフラストラクチャ コンピュートジョブ検査

モジュール化された Skills ライブラリにより、ドメイン固有の問題解決と、ポリシー準拠で安全なミティゲーション（トラフィックドレインなど、後述の Actus でゲートされる操作）を実現します。複雑なデバッグ作業の参入障壁を下げ、仮説検証を高速に回せるようにするのが狙いです。

自分たちの現場での実践方法考案

我々のようなスタートアップ企業で AI SRE を始めるなら、インシデント発生から対応オペレーションまでのイベント情報をどこで収集出来るかを整理する事かと思います。我々の場合の情報源は社内 Slack, Datadog になります。

フィルタし過去のインシデントと照らし合わせ人間に通知する。過去のデータをパイプライン処理して有用なデータを検索可能な状態にし通知の際に LLM 自信に検索させる。難易度が高そうですが、今の時代なら各社の SRE エンジニアでも出来そうです。

あとは Datadog Bits AI SRE を用いるパターン。Bits AI SRE を主要サービスの重要モニターにだけ先に紐付け、アラート発火時に自律調査を走らせて「競合する仮説 + 根拠データへのリンク」をインシデントチャンネルへ自動投稿する、という運用を想定しています。メトリクス・ログ・トレース・RUM がすでに Datadog に揃っているので、レポートの言う Investigation Dashboard 的な「単一ビュー」は実質ほぼ設定だけで手に入ります。一方 Detectr のような「ユーザーの声から未知障害を検知する」仕組みは Synthetic 監視とサポートチケットの定期トリアージで代替するべきかなぁと感じています。

自律型ミティゲーション（L3）：AI Operator と Actus

L1 の支援ツールは認知負荷を確かに下げますが、運用スケーラビリティを本質的に解決するには、AI が直接本番環境を変更する「実行（actuation）」まで踏み込む必要があります。ここからが L3、つまり AI Operator と Actus の領域です。

AI Operator

本番アラートの最初のレスポンダーとして機能する自律エージェントです。すでに数千件規模のインシデントで運用されています。

調査と根本原因分析（RCA）

AI Operator はアラートを受け取ると、以下のように多角的な調査を進めます。

  • 並列型拡張モジュール群（Enrichers）による複数の同時調査
  • 類似インシデントにおける過去の専門家調査事例に基づく推論ガイダンス
  • 仮説の形成と検証サイクル

緩和選択

調査の結果、コンテキストの構造化カタログから適切な緩和策を選択します。選択の際に使うコンテキストは大きく3種類です。

要素 役割
Enrichers 可観測性の所見やプレイブックなど確実な情報を自動収集する
Skills 問題固有の緩和メソッド
Few-shot prompts 調査戦略のガイダンス

現在の自律性レベル

AI Operator はインシデントの重大度に応じて動作レベルを使い分けます。

  • 重大運用インシデント：L2（人間 SRE の承認が必須）
  • 軽微インシデント：L3（自律実行）

Chain of Thought の可視化

すべての推論ステップが中央集約された UI で可視化され、各段階で人間がコメントしたり方向を指示したりできます。必要に応じて専門サブエージェントを起動して深掘りすることも可能です。長時間に及ぶインシデントでも、厳密なトークン管理によってコンテキストの喪失やハルシネーションを防いでいます。なお、すべての実行トレースは Spanner に保存され、デバッグと継続的改善に使われます。

エスカレーション

根本原因を特定できない場合、またはセーフティー境界を超える操作が必要な場合は、即座に人間オペレータへエスカレーションします。その際、調査履歴全体をインシデント UI に集約し、人間がスムーズに引き継げるようにします。

LLM-as-a-Judge による自己改善ループ

AI Operator は自分の対応を自分で採点する仕組みを持ちます。自動でインシデントメタデータを分析し、エージェントのアクションを Golden Data（理想的な人間対応）と比較評価します。そして改善すべき領域を特定すると、具体的な実装計画とともにバグとして自動登録する、という「自己改善ループ」を回します。エージェントが自らの欠点をチケット化していくイメージです。

Actus（Mitigation Safety Verification Agent）

Actus は、AI Operator の推論能力と本番インフラ実行のギャップを安全に橋渡しする役割を担います。設計上の最大のポイントは、AI Operator（推論エンジン）と Actus（実行エンジン）を分離していることです。これにより、モデルがいくら進化しても、実行ガバナンスは常に決定論的で人間の制御下にある境界の内側に留まります。

Actus は3段階のライフサイクルで動作します。

Phase 1：標準化された Discovery & Planning

  • 利用可能な緩和ツール（トラフィックドレイン、容量アップサイズ等）を、動的にフィルタリングしたレジストリとして提供する
  • EvaluateAction リクエストで必要なパラメータをハイドレートする
  • LLM のあいまいなインテントを、検証可能な具体的実行計画へ変換する

Phase 2：動的自律性とセーフティーガードレール

Actus は段階的認可（Progressive Authorization）を物理的に強制する層でもあります。実行前のプリフライト安全検証として、以下を必須実行します。

  • 強制的ドライラン（dry_run=true）
  • 正当化検証（そのアクションがオープンされたインシデントに対応するものか）
  • 並行アクション確認（競合する操作が同時に走っていないか）

そして高リスクと判定した L3 リクエストや、本番状態が異常なときは、自動で L2 にダウングレードして、人間へ承認リクエストを転送します。

Phase 3：Post-Action Guardian

  • Long Running Operation（LRO）の状態を保持する
  • インフラをポーリングして、ミティゲーションの成功・失敗を確認する
  • 緊急時には人間オペレータが実行中のエージェントアクションを即座に停止し、新規アクションをブロックし、L3 権限をグローバルに取り消せる

どれだけ自律化しても「人間が一発で全部止められる」非常停止装置を残しているのがポイントかもしれません。

自分たちの現場での実践方法考案

レポートの肝である「推論と実行の分離」に関してはそのまま自分たちの設計原則として採用出来そうと思っています。推論は Datadog（Bits AI SRE）に任せても、実行は必ずうちが管理する経路を通すという事になるかなぁと。

具体的には、Actus に相当する Bits Remediation / Bits Infrastructure Operations にいきなり広い権限を渡すのではなく、許可する操作を「タスク再起動・オートスケールスケール修正」程度の操作に限定し(ホワイトリスト管理に近いかも)そしてそれぞれを、GCP / AWS の最小権限サービスアカウントと、Terraform 実行のバックエンドに置く等。当面はすべて承認ベース（L2）で運用し、完全自動（L3）は「誤っても影響が局所的かつ即復旧できる」操作にだけ、十分な実績を見てから段階的に拡張していくイメージは持てそうです。

自分たちの現場は現時点では GCP と AWS のマルチクラウドなので、Google のような単一基盤前提の構成はそもそも作れません。だからこそ Actus 的な役割は自作せず Datadog 側のガードレールに乗せつつ、最後の非常停止は「エージェントの IAM ロール剥奪 / ワークフロー無効化」というクラウド側の操作で握る、という二段構えにするのが現実的だと思っています。重大インシデントでの自律 L3 を Google に倣って追うのはでは筋が悪いと思っていて、これははっきり線を引いておきたいところです。

AI SRE を支える技術基盤

ここまで説明したシステムはいずれも以下の技術基盤の上に成り立っていいます。リストアップします。

高品質な本番データとメタデータ

  • リアルタイムテレメトリ（メトリクス・ログ・トレース)
  • 正確なサービストポロジーと依存グラフ
  • 歴史的インシデントデータ
  • エンジニアリングプレイブックと技術ドキュメント
  • SLO とエラーバジェットの状態
  • 本番ツールカタログ（各ツールがもたらす効果も含む)

Google はこれらを実時間でクエリできるようにする部分に多大な投資をしてきた、と述べています。AI 以前のデータ基盤がなければ AI-Ops は成立しない、という順序です。

RAG プラットフォーム

LLM を訓練データではなく「現在の本番状態」にグラウンドさせるための基盤です。リアルタイムのデータソースや内部ドキュメントを LLM がクエリできるようにすることで、文脈に即した応答とアクションを可能にします。

Fine-Tuning

汎用 LLM に対し、Google 内部ツール・本番運用の原則・典型的な障害パターンといったドメイン知識を学習させ、AI 支援の精度と関連性を引き上げます。RAG が「最新の文脈を外から与える」のに対し、Fine-Tuning は「ドメインの素養をモデル自体に染み込ませる」役割で、両者は補完関係にあります。

Model Context Protocol（MCP）

AI が安全かつ効果的に本番環境と相互作用するための標準インターフェース。エージェントがツールを動的に発見して呼び出せるようにする点が肝で、単純な診断コマンドから複雑な緩和アクションまでを同じ枠組みで扱えます。MCP サーバーを通じて、可観測性・インシデント管理・トラフィック制御・インフラ検査の各ツールを提供します。

ロバストなエージェントアイデンティティ管理

エージェントは人間とは別の一意でマシン識別可能なアイデンティティを持つそうです。これにより「人間のみが実行できるアクション」を厳格に区別でき、エージェントのすべての操作を完全な 情報として記録できます。監査可能性と否認防止、そして後から権限行使の履歴を再構成できることが、自律化の前提として重視されています。

A2A（Agent-to-Agent）通信プロトコル

モニタリング・ロールアウト・容量といったドメインに特化した複数のエージェントが協調して動くための通信プロトコルです。マイクロサービス同士が連携するように、専門エージェント同士が連携して複雑なインシデントを解決する、という構図を目指しています。A2A はオープン仕様として公開されています。

自分たちの現場での実践方法考案

この章の教訓は、派手な仕組みより地味な前提のほうが大事だ、ということです。RAG も MCP も A2A も Datadog が担いでくれるので作らないというシナリオが現実路線かと。代わりに自分たちがやるべきことは2つに絞れます。

1つは健全性を保ったデータ管理です。タグ付け、SLO の定義..等かもしれません。これらが雑だとエージェントは誤った情報を根拠に推論する思います。

要するに「Actus を作る」のは無理でも、「Actus に渡せるきれいなデータと、安全に渡すための権限設計」は各現場で出来ることかなと。AI SRE の実質的な前提条件はこの地味な2つだと割り切って、ツール導入より先に手を付けるべきだと考えています。

SRE の未来

AI 統合の最終系は運用だけでなく SDLC（ソフトウェア開発ライフサイクル）そのものの包括です。AI が計画・実装・レビュー・提出までを担うエージェント型 SDLC へ移行し、その大部分がブラックボックス的な高速開発になります。SRE はこの高速・不透明なプロセスをどう管理するかを問われます。

人間の監視を「左にシフト」する

4倍のコード量に対して、行単位のコードレビューはスケールしません。続ければレビュアーの疲弊を招くだけです。Google SRE の答えは、レビューの抽象度を一段引き上げることでした。

  • 設計・意図・ポリシーのレビュー：エンジニアが詳細仕様を AI と共同執筆・承認し、コード生成の前にアーキテクチャとセーフティー制約を検証する
  • Independent Harnesses：コードを生成するエージェントと、テストケースを定義・レビューするエージェントを厳格に分離する。両者を分けることで未検証の要件が機械的に検出されるようにする

Adaptive Progressive Rollouts

変更率が高い環境では、従来の Canary リリースがかえって障壁になります。そこで、機械速度でシステムの健全性を評価できる「継続的本番検証」技術へ投資する、という方向が示されています。

Intervening Pull Request Problem と AI-Assisted Fix-Forward

急速な AI 生成デプロイメント環境では、従来の「ロールバック」が逆に危険になります。短時間に大量の変更が積み重なった状態で「最後の既知の正常状態」へ単純に巻き戻すと、その間に入った重要なバグ修正やセキュリティパッチまで巻き添えで失われかねないからです。これをレポートでは Intervening Pull Request Problem（介在プルリクエスト問題）と呼んでいます。

対策として2つのアプローチが挙げられています。

  • 動的設定・フィーチャーフラグによって、問題のあるコードパスだけを即座に無効化する
  • AI-Assisted Fix-Forward：巻き戻すのではなく、ターゲットを絞ったパッチを自動生成・デプロイし、並行して進む他の変更を保護したままインシデントを解決する

SRE の役割の進化

これらを総合すると、SRE の仕事は次のように移っていきます。

従来 これから
システムを手動で運用する 自律エージェントが安全に継続イノベーションできる境界を設計する
手動緩和・オペレーター アーキテクチャ的な意図と、機械速度の補償制御
既知の障害モードへの対応 エージェントエコシステムのガバナンス設計

レポートの言葉を借りれば、人間の監視をアーキテクチャ的な意図へとシフトし、機械速度の補償制御を構築することで、SRE は「システムを運用する」役割から「自律エージェントが継続的にイノベーションできる安全な境界を設計する」役割へ移っていく、ということになります。

まとめ

Google SRE の AI 統合戦略が示すのは、「AI ツールを追加する」という発想ではなく、本番環境ガバナンスの根本的な再構想です。読み終えて印象に残ったのは、技術そのものより「どう安全に権限を渡すか」に多くを割いている点でした。要点を改めて整理すると以下になります。

  • Safety Trifecta（透明性・リアルタイムリスク評価・段階的認可）による段階的な信頼構築
  • Bronze / Silver / Gold の評価データ階層と Nightly Evals による継続的な品質担保
  • AI Operator + Actus という、推論と実行を分離した責任あるアーキテクチャ
  • L0〜L4 の自律性モデルによって、統計的成功実績に基づき段階的に自律性を拡大

4倍の開発速度でも信頼性を維持するための枠組みとして、また AI 時代の SRE エンジニアが「何を設計すべきか」の指針としてこのレポートは非常に有用だと思います。個人的には、こうした基盤を各社が独自に作り込むよりも、近い将来に出てくるデファクトな仕組みへ寄せていく流れになると見ています。それが Datadog になるのか Anthropic の基盤になるのか .. といったところでしょうか。

参考