猶予は5分 Googleは生成AIで障害対応をどう効率化しているか：障害対応に生成AIを活用

Googleは、「Gemini CLI」を活用してインシデント対応を高速化する実践手法を公開した。アラートの受信から緩和策の実行、根本原因の特定、事後検証報告（ポストモーテム）の作成までの全工程にわたって活用しているという。

[＠IT]

　Googleは2026年1月22日（米国時間）、同社のSRE（Site Reliability Engineering）チームが大規模言語モデル（LLM）「Gemini」をターミナルで利用できる「Gemini CLI」を活用し、障害対応を省力化・効率化している実践手法を公式ブログで公開した。

　GoogleのSREチームが日常的に直面している障害と、Gemini CLIを用いた対応について、そのワークフローを解説したものだ。

初動の猶予は5分　Gemini CLIをどう活用しているのか

　公開されたワークフローは、コアSREが直面する障害への対応だ。GoogleにおいてコアSREは、安全性、セキュリティ、アカウント管理、データバックエンドなど、Google全製品の基盤インフラを支えている。

　このレイヤーでの障害は、Googleのほとんど全てのサービスに波及するため、平均緩和時間（MTTM：Mean Time to Mitigation）の短縮が最重要指標になっているという。

　通常、アラート（ページ）を受信してから5分以内に確認するというSLO（サービスレベル目標）が設定されており、SREは極限のプレッシャーの中で即座に緩和策を実行することが求められている。

　コアSREのインシデント対応は主に以下の4ステップで構成されている。

1. アラート通知（ページング）
   • SREがアラートを受信する
2. 緩和策の実行
   • 根本原因が判明する前に影響を止める
3. 障害原因の特定
   • 障害の原因を特定し恒久的に修正する
4. ポストモーテム（事後検証）の実施
   • インシデントを文書化し、再発防止策を策定する

Step 1：AIが初動調査と緩和策を提示

　アラート受信後の最優先事項はコードの修正ではなく、ユーザーへの影響を緩和することだ。GoogleのSREチームは、トラフィックのドレイン（退避）、ロールバック、再起動、容量追加といった標準的な対応パターンを「汎用（はんよう）的緩和策」として体系化している。

　SREチームがターミナルでGemini CLIを起動すると、同社内のエージェントフレームワーク「ProdAgent」からfetch_playbook関数を呼び出す。この関数は複数のツールを連鎖させてコンテキストを構築する。

• 「get_incident_details」
  • インシデント対応管理システムからアラートデータを取得する
• 「causal_analysis」
  • 異なる時系列データの振る舞いと汎用的緩和策ラベルの間の因果関係を発見する
• 「timeseries_correlation」
  • 相関する時系列のペアを発見し、根本原因と緩和策の特定を支援する
• 「log_analysis」
  • ログパターンとボリューム分析を使用して、サービスのログストリームから異常を検出する

　シナリオでは、上記の分析に基づき、Gemini CLIが「borg_task_restart playbook」（タスクの再起動）を即時緩和策として提案する。SREがプランを確認し、再起動を承認すると、安全な再起動プロセスが即時実行される。

　ヒューマンインザループ（人間による確認）を維持することで、緩和策が適切かつ安全であることを検証しているという。

Step 2：緩和策の実行と安全性チェック

　本番インフラでは自律エージェントの動作は制限される。ある条件で安全なコマンドが、別の状況では安全でない場合があるためだ。下記の取り組みを通じて、Gemini CLIをオートパイロット（自動操縦）ではなくコパイロット（副操縦士）として機能させているという。

• 厳密に型付けされたツールの使用
  • エージェントは自由なbashスクリプトの実行ではなく、MCP（Model Context Protocol）経由で「borg_task_restart」など厳密に型付けされたツールから選択する
• 操作リスクの自動評価
  • 各ツール定義に潜在的な影響に関するメタデータ（安全、可逆、破壊的など）が含まれており、高リスクアクションは自動的にフラグが立つ
• ポリシーによる実行制御
  • エージェントが有効なコマンドを実行しようとしても、ポリシーレイヤーが現在のコンテキストで許可されているかどうかを確認する（ピークトラフィック中のグローバル再起動禁止、2人による承認の要求）
• ヒューマンインザループ
  • Gemini CLIは全ての提案に対し、人間による承認ステップを強制する
• 監査証跡
  • 全てのアクションがGemini CLI経由で代理実行される。AIが何を提案し人間が何を承認したかが自動的に記録されるため、コンプライアンス要件も満たすことができる

　再起動が失敗した場合、手作業による対応では大きなコンテキストスイッチが発生する。別のダッシュボードを開き直し、手作業でログを検索（grep）しなければならず、その間に貴重な時間が失われてMTTMは悪化する。しかし、Gemini CLIは再起動エラーをキャッチしてもワークフローを中断せず、即座に障害の分析を継続する。

　分析の結果、Gemini CLIはあるパターンを発見する。対象のセル内において、自分たちのジョブだけが失敗しており、他のジョブは正常稼働していた。これは極めて重要な事実となる。特定のバイナリや設定に起因する障害だと切り分けられるからだ。

　Gemini CLIがこの切り分けを数分ではなく数秒で完了させることで、SREチームは見当違いの調査に時間を奪われるのを回避できる。

Step 3：2分でコードのバグを特定、パッチ生成まで

　単純な再起動では解決しない場合、アプリケーションロジックにあるバグを探す必要がある。Gemini CLIにソースコードの調査を指示する際、Googleのような巨大なモノレポ（モノリシックリポジトリ）を運用している環境では、特定のフォルダだけをコンテキストとして渡せる機能が極めて有効に働くという。

　Gemini CLIはファイルを取得し、最近の変更を分析し、先ほど取得した本番ログと照合する。2分以内に原因（シナリオでは、最近の設定プッシュにおけるロジックエラー）を特定する。

　SREチームが修正のCL（Changelist：GitHubのプルリクエストに相当）の作成を依頼すると、Gemini CLIは不正な設定を元に戻し、セーフガードを適用するパッチを生成する。CLのレビューと承認、提出、自動ロールアウトの待機という手順が示され、コードが修正されてサービスが復旧する。

Step 4：ポストモーテムの自動生成

　障害は収束したが、SRE文化の根幹となる「ポストモーテム」のプロセスが残っている。タイムスタンプの収集、ログへのリンク、具体的な対応の記録といった作業は手間がかかる。

　そこで、ProdAgent内にポストモーテム作成を支援するカスタムコマンドが、この作業を大きく簡略化させているという。このツールは以下の処理を実行する。

• インシデントの会話履歴、メトリクス、ログをスクレイピングする
• 関連イベントのCSVタイムラインを生成する
• SREの標準ポストモーテムテンプレートに基づくMarkdownドキュメントを生成する
• 再発防止のためのアクションアイテムを提案する

　さらにGemini CLIは、MCPを使用して課題追跡システムと連携し、アクションアイテムをバグとして登録し、担当エンジニアにアサインする。最終的なポストモーテムはGoogle ドキュメントにエクスポートする。

Google ドキュメントにエクスポートされたポストモーテムのイメージ（提供：Google）

過去のインシデントをAIに学習させる　「自律的運用」の展望

　Googleは、Gemini CLIを使用することで、「Gemini 3」の推論能力を運用データに接続し、ライブログの分析、コードパッチの生成、本番環境へのロールアウトまでを一貫してターミナル上で完結できると説明している。この直接的な統合により、MTTMの短縮が可能になるという。

　「4つのステップはGoogle内部の障害対応手法だが、汎用的なものであり、誰でもGemini CLIを通じて取り組むことができる。MCPサーバを通じて、『Grafana』『Prometheus』『PagerDuty』『Kubernetes』との連携も可能だ」（Google）

　日々の障害対応を経て生成されたポストモーテムがトレーニングデータとなり、AIにフィードバックすることで、「これまで起きたインシデントが明日のソリューションに活用される」という好循環が生まれると、Googleは今後の展望を語っている。