この記事のポイント

  • Google Cloudにおけるエージェント型システム運用（Agentic Operations）の取り組みを紹介
  • 筆者が考える自律型運用（Autonomous Operations）との共通点や違いを整理
  • AIエージェントによるシステム運用の課題と今後の展望について考察

この記事を画像1枚で表現(グラレコ風)

はじめに

AIエージェントの流行とともにあらゆる分野でAIエージェントの活用が進んでいます。
システム運用の分野でも、AIエージェントを活用した「エージェント型システム運用（Agentic Operations）」や「自律型運用（Autonomous Operations）」といったテーマが注目されています。

今回はGoogle Cloudにおけるエージェント型運用（エージェント型システム運用）の取り組みを紹介しつつ、筆者が考えている自律型運用との共通点や違い、そして今後解決しなければならない課題についてこれまでのシステム運用の経験を踏まえて考えてみたいと思います。

また、他のクラウドではありますが、筆者もこれまで「エージェント型システム運用（Agentic Operations）」というテーマでAIエージェントをシステム運用にどのように組み込めるのかについて検討し、実際に検証しましたのでその経験も交えながら、Google Cloudの取り組みと比較していきたいと思います。

※9月は上記の続きを検証する予定です。検証結果は随時公開していきます。

Google Cloudでも進むエージェント型システム運用

まず、Google Cloudではデータベース運用を支援するDatabase Operations Agentsをはじめ、AIエージェントによるモニタリング、トラブルシューティング、原因分析、修復といった取り組みが進んでいます。

Google Cloudでは2026年、システム運用へのAIエージェントの活用がかなり具体的になってきました。その一例が、Database Operations Agentsです。

Database Observability AgentではDatabase Insights、Cloud Monitoring、Cloud Logging、Cloud Traceなど複数のテレメトリを関連付けて問題を調査し、根本原因を分析します。

問題に対する修復方法を提案し、人間の承認を得たうえで検証済みのアクションを実行するところまで踏み込んでおり
監視 → 調査 → 原因分析 → 対応方法の提案 → 承認 → 実行という、これまで人間のSREや運用担当者が行ってきた一連の作業にAIエージェントが参加し始めています。

Google自身のSREでも、Agentic AIをインシデント調査や仮説生成、Mitigation、Playbookの利用などへ適用する取り組みが進んでいます。
※ブログではAI in SREという表現で紹介されています。

ここまで成熟するとAIエージェントは単なる「質問すると答えてくれるAI」ではなく、実際のシステム運用プロセスの一部を担当する存在になりつつあります。

筆者が考えているAIエージェントによるシステム運用（エージェント型システム運用）

筆者もこれまでAIエージェントによるシステム運用（エージェント型システム運用）について検証を進めてきました。
エージェント型システム運用の説明に入りたいところですが、まずはエージェント型システム運用の定義について触れておきたいと思います。

明確にこれといった定義はありませんが、「AIエージェント（エージェント型 AI）がシステム運用の一部あるいは全部を担当すること」だと考えています。

  • 人間とAIエージェントが協調してシステムを運用する段階を「伴走型運用」
  • AIエージェントが人間の判断を必要とせずにシステム運用を行う段階を「自律型運用」

具体的には「AIエージェントが調査や対応案の作成を行い、人間が必要に応じて判断する。」これは伴走型運用として定義しており、現在提供され始めている多くのAIエージェントによる運用機能もこの形に近いと考えています。

一方で自律型運用は「AIエージェントが人間の判断を必要とせずにシステム運用を行う」と定義しています。AIエージェントが調査や対応案の作成だけでなく、実際の対応まで行うことを指します。

自律型運用はいかにAIを使わなくて済むようにするかである

AIエージェントによる自律型運用を研究しているのに、AIを使わないことを目指す。
一見すると矛盾しているように聞こえるかもしれませんが、自律型運用において重要な考え方だと見ています。

エージェント型システム運用について考えると、すべての処理にAIが必要なわけではないことやAIを使うことが最適解ではない場合もあることに気づきます。たとえば、既知の障害であり、原因も復旧手順も明確なのであれば、従来のルールベースのAutomationで十分です。

一方で、複数のログやメトリクスを調査しなければ原因が分からない場合や状況に応じて対応方法を変える必要がある場合には、AIエージェントの推論能力が役立つ可能性があります。
リスクが高い処理については人間が判断したほうがよいケースもあるため、人/自動化/AIエージェント、それぞれを競合するものとしてではなく、それぞれの得意領域に配置することが重要だと考えています。

ではAIエージェントはどんな役割を担えば良いか

人、自動化については従来のシステム運用でも十分に活用されてきましたのでイメージがつきやすいと思います。
では、AIエージェントはどのような役割を担えばよいのでしょうか。

個人的な意見としてはAIエージェントは「人間が判断するには感覚、時間や判断力の問題で現実的ではない。その一方で自動化するにはロジックが複雑になりすぎる」ような状況で活躍できるのではないかと考えています。

具体的にはルールベースによるインシデント対応ではインシデント発生後にルールに従って自動で対応を進められますが、インシデント対応ルールを作るためには過去のインシデント対応の経験や知見を整理し、ルール化する必要があります。また、時間が経過するにつれてシステム構成や運用ルールが変化することもあるため、ルールのメンテナンスも必要です。

よって、実際のインシデント対応以外においてAIエージェントの役割を挙げるとするならば「インシデント対応の経験や知見を整理し、ルール化する」ことにあると考えています。

エージェント型システム運用の落とし穴

ここまでで、AIエージェントをシステム運用に導入することの意義やAIエージェントが担うべき役割について考えてきました。
エージェント型システム運用は一見して魅力的に見えますが、実際に導入する際にはいくつかの落とし穴があります。
そのひとつとしてAIエージェントを導入すること自体が目的になってしまうことです。

アプローチ自体に問題があるわけではなくむしろ、本番システムへAIエージェントを導入する最初の段階としては非常に現実的です。
ただ、その先を考えたときに一つ疑問が生まれます。
それは「AIエージェントを導入したことでシステム運用は本当に良くなったのか。運用成果は挙げられたのか」という点です。

AIエージェントを導入した効果をどう測るのか

単なる自動化であれば、どれだけのインシデント対応に時間を使っているかを計測し、Automationによってどれだけの時間を削減できたかを測定することで運用成果を評価できます。しかし、AIエージェントの場合は少し複雑です。

AIエージェントを利用すれば、インシデントを解決できるかもしれません。しかし、AIエージェントを導入する前にも人間や既存のAutomationによってインシデント対応は行われていました。すると、本当に比較しなければならないのは「従来の運用成果と、AIエージェント導入後の運用成果との差」です。

たとえば、次のような観点があります。

  • インシデントの解決時間は短くなったのか
  • 原因特定までの時間は短くなったのか
  • 人間が対応する時間は減ったのか
  • エスカレーションは減ったのか
  • 誤った判断や操作は増えていないか
  • AIエージェントの利用コストはいくらだったのか。コストに見合う運用成果を得られたのか

単純に「AIエージェントがインシデントを解決できた」だけでは、AIエージェントを導入した価値を判断できません。
10円で解決できる処理を100円かけてAIエージェントに実行させているのであれば、技術的には成功していても運用として成功しているとは限りません。

よって、「このインシデントにはAIエージェントを使わない」という判断こそが最適化の結果になる可能性もあります。
これは前述の「自律型運用はいかにAIを使わなくて済むようにするかである」という考え方にもつながります。

インシデント対応に「実験管理」を持ち込む

そこで私が取り入れたいと考えているのが、機械学習で使われてきた「実験管理」の考え方です。
機械学習ではモデル、パラメータ、データセット、評価結果などを記録し、複数の実験を比較します。
同じようにAIエージェントによるインシデント対応についても、実行結果を一つの「実験」として管理できるのではないかと考えています。

具体的にはWebアプリケーションで404エラーが発生したとします。モデルAを利用したエージェントでは、ログを3回取得し、設定ファイルを確認し、5分で原因を特定した。一方、モデルBのエージェントでは別のツールを利用し、異なる調査経路を通って3分で原因を特定した。

結果だけを見ればどちらも「解決」ですが、その過程は大きく異なります。
この過程を以下のような観点で記録することでどのエージェントがどんな手順でインシデントを解決できたかだけではなく「どの構成が最も効率的に問題を解決できたか」を比較できるようになります。

  • 使用したモデル
  • 利用したツールと回数
  • 推論のステップ
  • 入出力Token
  • レイテンシ
  • 原因特定までの時間
  • 復旧までの時間
  • 人間による承認回数
  • エスカレーションの有無
  • 最終的な対応結果
  • 推論および実行コスト

ここで注意しておくべきこととしてはこれは単なるモデル評価ではなく、インシデント対応の「実験管理」であるという点です。
モデル評価の場合はモデルの精度や推論速度などを評価することが目的です。しかし、インシデント対応の実験管理では、モデルの精度や推論速度だけでなく、最終的な運用成果までを含めて評価する必要があります。

つまり、インシデント対応の実験管理では「最終的に運用成果を改善できたか」が重要な評価指標になるため、モデルの賢さは必ずしも最重要ではないということです。

エージェント評価と運用成果を接続する

現在のAIエージェント基盤でも、エージェントそのものを評価する仕組みは充実しつつあります。
たとえば、期待した回答を生成できたか、正しいツールを選択したか、決められた手順を実行したか、といった評価です。
これらは非常に重要な技術ですが、システム運用で知りたいことは「そのエージェントが行動した結果、運用がどれだけ改善したのか」という点です。

エージェントとして正しく動作していてもMTTRが変わっていなければ、運用上の価値は限定的かもしれません。
逆に多少高価なモデルを利用したとしても、重大インシデントの復旧時間を大幅に短縮できるのであれば、十分な価値があるかもしれません。

つまり、エージェント評価（Agent Evaluation）と運用成果（Operational Outcome）を接続する必要があるということです。
ここが今後のエージェント型システム運用（Agentic Operations）における重要なテーマになると考えています。

自律型運用で重要になる「推論効率」

従来の運用成果とエージェント型システム運用の運用成果を比較するためにインシデント対応の実験管理をするということですが
この実験管理によって最終的に改善したいものとして「推論効率」があります。ここでいう推論効率とは、単純なモデルの応答速度だけではありません。
主に以下の観点で評価することを考えています。

  • どのモデルを使ったのか
  • 何回推論したのか
  • 何回ツールを呼び出したのか
  • どれだけのTokenを消費したのか
  • どれだけ時間がかかったのか
  • どれだけのコストが発生したのか
  • 最終的にどのような運用成果につながったのか

高性能なモデルを使えば、必ず優れたシステム運用になるとは限りません。単純な問題なら、小さなモデルや既存のAutomationのほうが速く、安く、確実かもしれません。
逆に複雑な問題であれば、より高い推論能力を持つモデルへ処理を切り替える価値があるかもしれません。
重要なのは「最も賢いモデルを使うこと」ではなく、「インシデントを解決するために必要十分な推論能力を必要なタイミングで使うこと」です。

インシデント対応では「たくさん推論すれば良い」とは限らない

次に行く前に、余談としてフロンティアモデルを使ったインシデント対応のベンチマークについて紹介します。
これは今年、2026年5月にHugging Faceによって公開されたITBench-AAというベンチマークです。

このベンチマークではKubernetesインシデントレスポンスにおけるモデルのパフォーマンスを評価するというものです。
結果としてフロンティアモデルは50%未満のスコアしか出せないことやターン数が多いからといってスコアが高くなるわけではないことなどが示されています。

引用：ITBench-AA: Frontier Models Score Below 50% on the First Benchmark for Agentic Enterprise IT Tasks — by Artificial Analysis and IBM

自律型運用のゴールはAIエージェントで運用することではない

ここまで考えると前述のとおり、自律型運用の究極形はAIエージェントで運用することではないという奇妙な話に帰結します。
自律型運用のゴールは「推論しなくても解決できる問題」を増やすことです。

AIエージェントによるインシデント対応を継続的に評価する。そこから再現可能な対応が見つかったのであれば、ルールやPlaybook、従来型Automationへ落とし込む。
曖昧さが残る処理だけをAIエージェントへ任せる。重大な判断だけを人間へエスカレーションする。

何度も書くようですが、人 → エージェント → 自動化という方向へのフィードバックが重要です。AIエージェントによって運用を自動化するだけではなく、AIエージェントの経験から運用そのものを改善し、最終的には「推論しなくても解決できる問題」を増やしていくことであり、それが継続可能な自律型運用の一つの姿ではないかと考えています。

Google CloudのAgentic Operationsとその先

Google Cloudの取り組みを見ると、この方向への重要な部品はすでに揃い始めています。
Database Observability Agentでは、Cloud MonitoringやCloud Loggingなどのテレメトリを横断して問題を調査し、根本原因を分析したうえで、承認を伴う修復まで踏み込んでいます。

従来の運用成果とエージェント型システム運用の運用成果を比較するためにインシデント対応を実験管理するという話をしました。この実験管理によって最終的に改善したいものとして「推論効率」があります。

ここでさらにGoogle Cloud上で考えて実現してみたいものとしては「Agenticな運用が従来の運用と比較して本当に優れていたのかをどう継続的に証明するのか」という部分です。
つまり、Google CloudでAgentを開発・活用・評価し、そのAgentをエージェント型システム運用へ組み込み、インシデント対応によって得られた運用成果を継続的に評価する。ここまでを1つのサイクルとして考えています。

従来運用との比較 → 運用成果の評価 → 推論効率の評価 → Agent/Model/Automationの再選択までを継続的なサイクルとして回すということです。
ここまでできて初めてAIエージェントを「導入する」ことからAIエージェントを含むシステム運用そのものを「最適化する」段階へ進めるのではないでしょうか。

Google Cloudで考える自律型運用

ここまでの内容を踏まえて、筆者がGoogle Cloud上で実現したい自律型運用を整理します。
自律型運用というと、AIエージェントが監視から復旧までをすべて自動で行うシステムを想像するかもしれません。しかし、筆者が目指しているものは少し異なります。
重要なのは、すべてをAIエージェントに任せることではなく、インシデントの性質に応じて「Automation」「AI Agent」「Human」を選択できることです。

  • 既知かつ再現性の高いインシデントはAutomationで処理する
  • 未知あるいは複雑なインシデントはAI Agentが調査する
  • リスクの高い判断はHumanへエスカレーションする

さらに、AI Agentが対応したインシデントについては、その対応過程と運用成果を記録します。
そこで得られた知見から再現可能な対応を発見できた場合には、PlaybookやAutomationへフィードバックします。

つまり、Google Cloudでも同様に以下のサイクルを回すことが自律型運用の実現につながると考えています。

Incident
↓
Automation / Agent / Humanの選択
↓
Incident Response
↓
Operational Outcomeの評価
↓
Experiment Management
↓
推論効率の評価
↓
Automation / Agent / Humanの再選択

このサイクルを継続的に回すことで、AIエージェントを増やすのではなく「AIエージェントが推論しなければならないインシデント」を減らしていきます。
これが筆者がGoogle Cloud上で検証してみたい自律型運用です。

Google Cloud上でどのように実現するか

この考え方をGoogle Cloud上で実現する場合、単一のAIエージェントですべてを処理するのではなく、「観測」「判断」「実行」「評価」「改善」という複数の役割に分けて考えることができます。まだ実装していないため、あくまで筆者の考えですが、以下のような構成を想定しています。

まず、Cloud MonitoringやCloud Loggingからシステムの状態やインシデントに関する情報を取得します。
既知のインシデントであれば、あらかじめ定義されたAutomationによって処理します。一方、未知または複雑なインシデントについては、Geminiを利用したAI Agentへ調査を委譲します。

AI Agentはログやメトリクスなどの情報を参照しながら原因を調査し、必要に応じてGoogle Cloud APIやToolを利用して追加情報を取得します。
対応方法が決まった場合も、リスクに応じてAI Agent自身が実行するのか、人間の承認を要求するのかを切り替えます。

そして、ここからが筆者の考える自律型運用において重要な部分です。

インシデントが解決したら処理を終了するのではなく、Agentが利用したモデル、Tool Call、Token、処理時間、コストなどの情報と、MTTRや対応結果といった運用成果を記録します。

これらをBigQueryなどへ蓄積することで、インシデント対応そのものを「実験」として分析できるようにします。
その結果、「この種類のインシデントはAI Agentを利用するよりAutomationの方が効率的だった」「この種類の調査にはより小さなモデルでも十分だった」といった知見が得られれば、次回以降の処理方法へフィードバックします。

このようにGoogle Cloud上の各サービスを単にAI Agentから利用するのではなく、Observe → Decide → Act → Evaluate → Optimizeという継続的なサイクルとして構成することを考えています。

ここまでの考えをまとめると、Google Cloudで実現するには以下のOSS、サービスの組み合わせが有効だと考えています。

  • Google Agent Development Kit（ADK）
  • Gemini Enterprise Agent Platform
  • Google Cloud Observability
  • BigQuery
  • Looker

なお、Lookerにおいては弊社の運用分析で導入されており、会話分析によってインシデント対応の改善点を見つけることができるため、AIエージェントによるインシデント対応の分析にも活用できると考えています。また、BigQueryに関しては最近になって内製システムの次世代監視基盤の監視設定を参照できるようにしたため、監視設定の変更履歴や監視設定の会話で分析することも可能になりました。これらの情報をAIエージェントが参照することで、より効率的なインシデント対応が可能になると考えています。

まとめ

  • AIエージェントによるインシデント対応が現実的になってきた。しかし、AIエージェントがインシデントを解決できることと、AIエージェントを導入する価値があることは同じではない
  • エージェント評価だけでなく、従来運用との比較やOperational Outcomeまで含めて継続的に評価し、推論効率を改善していく必要がある
  • そして、その結果として既知の対応をAutomationへ移管し、「AIエージェントが推論しなくても解決できる問題を増やしていく」ことが、筆者の考える自律型運用である

以上の内容を踏まえて、今後はGoogle Cloudの各種サービスを使いながら、この考え方を実際のAgentic Operationsとしてどこまで実装できるのか検証していきたいと思います。

参考