AIエージェントに本番運用を任せてよいか｜Google SRE・Uberに学ぶ7つの統制

AIエージェントは、アラートを読み、ログを調べ、原因候補をまとめ、復旧コマンドまで提案できるようになりました。では、そのまま本番環境の操作まで任せてよいのでしょうか。

結論から言えば、調査を任せられることと、本番変更を任せられることは別問題です。

AIによるコード生成で変更量が増えれば、レビューの次に詰まるのは運用です。障害の兆候を見つけ、影響範囲を判断し、復旧し、関係者へ説明する仕事は残ります。むしろ、変更の速度とシステムの複雑さが上がるほど、運用判断の難易度は高まります。

GoogleはSREの現場で、プレイブックの改善、異常検知、アラートの整理、インシデント調査、引き継ぎ、ポストモーテム作成などへAIエージェントを広げています。一方で、既存の決定論的な自動化を無理にAIへ置き換えず、エージェントにもID、権限、SLO、監査、代替手段を持たせる方針を示しています。

Uberも、複数のエージェントが連携する環境では、共通のサービスアカウントだけでは「誰の依頼で、どのエージェントが、なぜ操作したか」が失われると説明しています。同社はエージェントID、短命な権限、操作経路の記録、ゲートウェイでのポリシー適用を組み合わせています。

この記事では、両社の公開情報をもとに、AIエージェントを本番運用へ導入するための7つの統制と、SIerの運用保守ビジネスがどう変わるかを整理します。

最終更新：2026年9月26日

AI時代は「開発の高速化」だけでは終わらない

AIコーディングによって実装時間が短くなると、Pull Requestとリリース候補が増えます。しかし、変更が増えるほど、本番では次の仕事も増えます。

• どの変更が障害に関係しているかを特定する
• ログ、メトリクス、トレースを横断して調べる
• 依存サービスと顧客影響を確認する
• 復旧手順を選び、実行可否を判断する
• 長時間の障害で担当を引き継ぐ
• 事後検証を次の予防策へつなげる

前回の記事では、コード生成が速くなるとレビューがボトルネックになり、決定論的な検査、AI、人間の判断をリスクに応じて組み合わせる必要があると整理しました。

本番運用でも考え方は同じです。AIエージェントを一人の万能な運用担当者として置くのではなく、観測、調査、提案、承認、実行を分け、失敗しても被害を限定できる仕組みにします。

Google SREはAIに何を任せようとしているのか

Google Cloudが2026年5月に公開した「AI in SRE」では、生成AIによるコード増加が信頼性上の機会と課題の両方を生むと説明しています。そのうえで、AI活用を障害の原因分析だけに限定せず、ソフトウェアライフサイクル全体へ広げています。

参考：Google Cloud「AI in SRE」

公開されている用途は、次のように整理できます。

重要なのは、AIが既存の運用プロセスの上に置かれていることです。Googleは、従来の自動化で十分な処理までAIへ置き換える必要はないとしています。また、AIエージェントにも明確なIDと権限、信頼性目標、説明可能性、監査、AIが失敗したときの代替手段を求めています。

つまり「AIを入れてから運用を考える」のではありません。先に運用の責任と安全策を定義し、その範囲でAIの役割を増やします。

Uberが示した「誰が操作したか」という問題

Uberが公開した例では、オンコール担当者の依頼を受けた調査エージェントが、別の監視エージェントへ作業を渡し、そのエージェントが設定変更のPull Requestを作ります。

各システムに共通のサービスIDしか残らなければ、最後に見えるのは「何らかのサービスがAPIを呼んだ」という記録だけです。依頼した人、途中で判断したエージェント、操作の目的を一続きで追えません。

参考：Uber Engineering「Solving the Identity Crisis for AI Agents」

Uberは、この問題に対して次の構成を示しています。

• エージェントを登録し、実行環境とひも付ける
• 呼び出し先ごとに短命で用途限定のトークンを発行する
• 人から複数エージェントを経由した委任経路を記録する
• MCP Gatewayでツール呼び出しの認証と認可を行う
• AI Gatewayでモデル接続、情報のマスキング、安全制御を集約する
• 下流システムでも通常の監視・監査・ポリシーを適用する

これはUberの内部環境に合わせた実装であり、そのまま導入できる製品ではありません。ただし、エージェントを単なるプログラムではなく、権限と責任を持つ主体として扱う考え方は、企業の本番運用にも応用できます。

AIを監視ツールにつなぐだけでは足りない

LLMへログを渡せば、障害調査の文章は作れます。しかし、本番運用には文章生成以外の基盤が必要です。

観測データ

ログだけでなく、メトリクス、トレース、デプロイ履歴、設定変更、問い合わせ、クラウド事業者の障害情報を時刻と対象システムで関連付けます。データが欠けていれば、エージェントはもっともらしい仮説を作れても、原因を確定できません。

システムの地図

サービス、データベース、外部API、担当チーム、顧客機能の依存関係が必要です。どのサービスが落ちたかだけでなく、どの業務へ波及するかを判断するためです。

実行可能なプレイブック

「状況を確認する」のような抽象的な手順ではなく、確認するデータ、正常条件、次の分岐、復旧コマンド、切り戻し条件、連絡先まで定義します。

権限と承認

調査用の読み取り権限と、再起動、設定変更、データ修復などの書き込み権限を分けます。高リスク操作には承認を入れ、承認なしで実行できる範囲を明文化します。

評価と停止手段

正しい原因候補を出せたかだけでなく、誤った復旧を提案しなかったか、権限外操作を拒否したか、監査記録が残ったかを継続評価します。異常時には、モデル呼び出しだけでなく、ツール権限を即時に止められる必要があります。

本番運用へ入れるための7つの統制

1. 観測・提案・実行を分離する

最初から一つのエージェントにすべてを任せません。

• 観測：データを読み、状況を整理する
• 提案：原因候補と復旧案を作る
• 実行：承認された操作だけを行う

この境界をAPIと権限で分けます。プロンプトに「勝手に実行しない」と書くだけでは、技術的な制御になりません。

2. 人とエージェントのIDをつなぐ

監査ログには、最低でも依頼者、エージェント、セッション、ツール、操作、対象、結果、承認者を残します。複数のエージェントが連携する場合は、途中の委任経路も追跡できるようにします。

3. 短命・用途限定の権限を使う

長期間有効な共有APIキーを渡さず、対象、操作、呼び出し先、有効時間を絞ります。読み取り、提案、変更実行で権限を分け、通常時は書き込み権限を持たせない設計が安全です。

4. ゲートウェイを統制点にする

各エージェントへ認証、マスキング、監査、レート制限を個別実装すると、抜け漏れが生まれます。モデル接続と業務ツール接続の境界に統制点を置き、共通ポリシーを適用します。

5. 根拠を添えて判断させる

「CPU負荷が原因です」ではなく、参照したアラート、ログ、トレース、変更履歴、プレイブックと、棄却した仮説を残します。根拠が足りない場合は、結論を出さず人へエスカレーションさせます。

6. 操作リスクで人の承認を変える

すべてを承認制にすると速度が出ず、すべてを自動化すると危険です。可逆性、影響範囲、データ変更、顧客影響で操作を分類します。

• 低リスク：ログ検索、情報収集、チケット作成
• 中リスク：限定環境の再試行、事前定義済みのスケール変更
• 高リスク：本番設定変更、データ修復、権限変更、対外通知

高リスク操作は、人が根拠と切り戻し方法を確認してから実行します。

7. AIが止まっても運用を続けられるようにする

モデル障害、誤判定、ツール障害、ネットワーク分断を前提にします。人が使えるプレイブック、従来の監視、手動操作経路を残し、AIエージェント自身にもSLOと停止条件を設定します。

自律度は5段階で上げる

本番運用では「導入するか、しないか」の二択にしない方が安全です。

いきなり段階4を目指す必要はありません。要約と調査だけでも、情報収集や引き継ぎの時間を減らせます。重要なのは、段階を上げる条件と、戻す条件を事前に決めることです。

インシデント対応ではAIと人をどう分担するか

Google Cloudは2026年9月の障害対応ガイドで、準備に加えて「Verify → Investigate → Report → Resolve → Review」という流れを示しています。

参考：Google Cloud「Best practices for handling cloud reliability incidents」

これをAIエージェントへ当てはめると、役割分担は次のようになります。

Prepare：平時に準備する

AIは過去障害からプレイブックの不足を探し、訓練シナリオや更新案を作れます。人は責任者、連絡網、SLO、復旧優先順位を決めます。

Verify：事象を確認する

AIは複数の監視データとクラウド通知を集約します。人は、技術的な異常が顧客影響を伴うインシデントかを判断します。

Investigate：原因を調べる

AIは変更履歴、依存関係、ログ、トレースから仮説を並べます。人は証拠の質を確認し、追加調査と復旧方針を決めます。

Report：状況を共有する

AIはタイムラインと報告文を下書きできます。インシデント指揮者が内容、公開範囲、表現に責任を持ちます。

Resolve：復旧する

AIは承認済みプレイブックの操作を支援します。不可逆なデータ変更や広範囲な設定変更は、人が影響と切り戻しを確認します。

Review：再発を防ぐ

AIは記録からポストモーテムを下書きし、類似障害を検索します。人は組織、設計、優先順位を含む根本要因と改善投資を決めます。

SIerの運用保守ビジネスはどう変わるか

従来の運用保守は、監視、一次切り分け、定型報告、手順書に沿った復旧へ多くの工数を使ってきました。これらの一部はAIで短縮できます。

だからといって、運用保守が不要になるわけではありません。価値の中心が、作業人数から次へ移ります。

「監視要員」から「安全な自律運用の設計者」へ

売るものは、AIチャットの画面ではありません。観測データ、依存関係、プレイブック、権限、承認、監査、評価を一体にした運用基盤です。

月次報告から継続的な信頼性改善へ

障害件数だけでなく、検知時間、復旧時間、誤検知、エスカレーション率、切り戻し成功率、SLO達成率、手作業時間を測り、改善を契約に含めます。

人月から運用品質のサービスへ

人数を減らした分だけ売上が減る契約では、AI活用のインセンティブが働きません。基本運用料に、対象サービス数、SLO、改善バックログ、リスク分担を組み合わせます。ただし、障害ゼロのように受託側が制御できない成果だけへ報酬を連動させるのは危険です。

成果物も変わる

これから重要になる成果物は、次のようなものです。

• サービスと依存関係の台帳
• SLI・SLO・エラーバジェット
• 機械実行可能なプレイブック
• 操作リスク分類と承認表
• エージェントID・権限設計
• 評価データと回帰テスト
• 監査ログ仕様と証跡
• ロールバック・事業継続計画

これは、生成AI時代のSIerはどうなる？で述べた「顧客が安全に変わり続けられる仕組みを設計し、運営する会社」という方向を、運用保守へ具体化したものです。

90日で始める導入ロードマップ

1〜30日：読み取り専用で土台を作る

対象サービスを一つに絞り、ログ、メトリクス、トレース、変更履歴を接続します。エージェントには読み取り専用権限だけを与え、要約と調査を担当させます。

同時に、過去障害、正しい切り分け、誤った対応、エスカレーション条件を評価データにします。プレイブックの欠落や古さも洗い出します。

31〜60日：Shadow運用で比較する

人間の運用と並行してAIに判断させ、実際の操作はさせません。

• 原因候補に正解が含まれた割合
• 根拠が正しかった割合
• 調査時間の短縮
• 不要なアラートや提案の割合
• 人へ適切にエスカレーションできた割合

平均値だけでなく、重大な失敗例を確認します。

61〜90日：承認付きの限定操作を試す

可逆で影響範囲が小さい操作を一つ選びます。事前検証、承認、実行、結果確認、ロールバック、監査を一つのワークフローにします。

権限外操作、古い手順、観測データ欠損、モデル停止を意図的に発生させ、エージェントが安全側へ止まるかを確認します。

本番へ進める判断には、AIエージェントを本番で任せる前の10問と生成AI PoCの本番移行チェックリストも利用できます。

SaaS・クラウド基盤・自社開発をどう選ぶか

SaaS型の運用支援

導入が速く、監視製品との連携も用意されていることがあります。一方で、運用データの送信先、保存期間、モデル学習への利用、権限委任、監査ログ、障害時の利用可否を確認する必要があります。

クラウド事業者のエージェント基盤

既存の監視、IAM、ログと統合しやすいのが利点です。複数クラウドやオンプレミスを含む場合は、権限とデータ形式が一社のサービスへ閉じないかを確認します。

OSSを組み合わせた自社開発

制御を細かく設計できますが、エージェントの品質、認証、監査、可用性、アップデートまで自社で運用します。

公開実装では、GoogleのAgent Development Kitがエージェント構築の部品を、SPIFFE Workload APIとSPIREがワークロードIDの部品を提供しています。2026年9月26日時点で両リポジトリの開発、リリース、テストは継続しています。

ただし、これらを導入するだけでUberと同じ統制が完成するわけではありません。業務上の委任経路、ツール認可、承認、監査、緊急停止は、自社の運用責任に合わせて設計する必要があります。

導入前チェックリスト

運用基盤

• [ ] 対象サービスのSLI・SLOが定義されている
• [ ] ログ、メトリクス、トレース、変更履歴を関連付けられる
• [ ] サービス間の依存関係と担当チームが分かる
• [ ] プレイブックに分岐、正常条件、切り戻し条件がある

権限と監査

• [ ] 人とエージェントを別のIDで識別できる
• [ ] 読み取り権限と変更権限が分かれている
• [ ] トークンの対象、有効時間、呼び出し先を限定できる
• [ ] 依頼者からツール実行まで追跡できる
• [ ] 高リスク操作に人の承認が入る

品質と継続性

• [ ] 過去障害を使った回帰評価がある
• [ ] 根拠不足時に推測せずエスカレーションできる
• [ ] 誤操作を止めるkill switchを実測した
• [ ] モデルやエージェント停止時の手動経路がある
• [ ] 自律度を上げる条件と戻す条件がある

権限、承認、監査ログの詳細は、AIエージェントのセキュリティ設計で確認できます。MCP経由で既存システムをつなぐ場合は、旧クライアントが残るMCP移行で、先に変える構成と残す責任も参考になります。

結論：運用を任せる前に、任せ方を設計する

AIエージェントは、障害対応に必要な情報収集、要約、仮説作成を速くできます。しかし、賢いモデルを接続しただけでは、本番運用の責任を移せません。

必要なのは、観測と実行の分離、エージェントID、短命な権限、根拠、承認、監査、ロールバック、代替手段です。

導入は読み取り専用から始め、Shadow運用で失敗を測り、可逆な操作だけを承認付きで開放する。安全性を実証できた範囲で、自律度を一段ずつ上げます。

SIerにとって、これは運用保守が縮小するだけの話ではありません。監視要員を提供するビジネスから、顧客のシステムが安全に自律化できる運用基盤を設計し、継続改善するビジネスへ移る機会です。

AIに本番運用を任せてよいか。その答えは、モデルの性能ではなく、間違えたときに止まり、戻り、説明できる設計があるかで決まります。

関連記事

• AIコードレビューの設計方法 — 本番へ入る前の変更を、決定論・AI・人間でリスクベースに検証する方法です。
• 生成AI時代のSIerはどうなる？ — 人月ビジネスから、継続的な変化を運営するビジネスへの移行を整理しています。
• AIエージェントのセキュリティ設計 — 権限、承認、監査ログ、緊急停止の実務チェックリストです。
• AIエージェントを本番で任せる前の10問 — 受入条件、責任分担、採算、撤退条件を案件単位で確認できます。
• 生成AI PoCの本番移行チェックリスト — Go／条件付きGo／No-Goを35項目で判定できます。

参考資料

以下は2026年9月26日に本文と公開状況を確認しました。

• Google Cloud：AI in SRE
• Google Cloud：Best practices for handling cloud reliability incidents
• Uber Engineering：Solving the Identity Crisis for AI Agents
• Google：Agent Development Kit
• SPIFFE：Workload API
• SPIRE：GitHub repository