KubeCon Europe 2026の初日、2026年3月23日の午後に開催されたミニカンファレンス「Agentics Day:MCP + Agents」から、Adobeのクラウド運用チームが解説するAIOpsに関するセッションを紹介する。
●動画：Is AIOps the Future of Operations? Real Use Cases From the Trenches
プレゼンテーションを行ったのはAdobeのDanilo Banjac氏だ。タイトルは「Is AIOps Future of Operation? Real Use Case from the Trenches」、意味としてはAIOpsは運用の未来か？ 本当のユースケースを現場での経験を元に解説するという内容だ。戦場における塹壕を意味するTrenchという単語で現場の状況を表現しているのが興味深い。
運用における障害発生時のオンコールをAIで効率化する仕組みを解説
Adobeのクラウドサービスについて解説を行ったスライドでは、Adobeが運用するどのクラウドサービスなのかは明らかにしなかったが、70以上のクラスター、20,000以上のネームスペース、20万以上のサービスが稼働しているクラウドであることを説明した。
運用しているクラウドサービスの概要を解説
ここでオンコールシステムにAIを使う前提として、目指すゴールについて解説。スケールすることについては大量のアラートに対応できること、障害からの復帰にかかる時間を減らすこと、オンコールに必要な労力を削減することなどを挙げた。
運用全体をカバーする効果をあげることをゴールとして設定
AIを使うことについてはすべてを移行するわけではなく、システムから発生するオブザーバビリティデータの収集、集約、異常値の発見から、定型化したアラートに対するスクリプトによる処理の上にエージェントを使ったAIによる処理が上乗せされる形でシステム化され、最終的には運用担当エンジニアによるレビューと承認によって処理が行われると説明した。
オブザーバビリティからアラート発生、スクリプトによる定型処理の上にエージェントが追加されるフロー
そして月間15,000件のアラートが70を超えるクラスターから発生するという状況に対して、30％程度のアラートが自動的に処理され、エンジニアの労力も20％程度削減されたことを説明。アラートの原因解明についても71.4％の正解率を達成したという。
オンコールによる自動化の結果を解説
オンコールエージェントを開発するにあたって運用に使うツールの機能と過去の事例データ、経験則に生成AIによる推論が追加されて自動化が完成すると説明。ここでは定型化した対応から生成AIによる補助によって自動化が推進されると説明した。
オンコールエージェントの構成
エージェントについてはすべて一つのエージェントで処理されるわけではなく、さまざまな専用分野を持つエージェントが存在するとして、エージェントマーケットプレイスを開発したと説明。この機能はMicrosoftの協力によって開発が行われたと語り、Azure AI FoundryなどのMicrosoftのクラウドサービスであるAzureの機能が効果的に使われていることを示した。
エージェントマーケットプレイスを使ってエージェントを利用
またスライドには現れていないが、エージェントの利用についてはエージェントが権限を超えた情報にアクセスしてしまうことで本来実行不可能な操作を行ってしまうことを抑制するためにAPIゲートウェイを利用していることも解説した。社内で利用する生成AIのリスクとして情報に対するアクセスリスクは指摘されるが、運用を支援する生成AIにおいては許可されたコマンドやツールだけを利用させるというガイドラインを実行させるためにAPIゲートウェイを使うというのは現実的な解答だろう。
オンコールエージェントの設定はMarkdownで書かれたプロンプトのようだ
オンコールエージェントの動作を解説するスライドではPrometheusが収集したKubernetesクラスターのオブザーバビリティデータからアラートをすると稼働している運用担当エンジニアに通知を行った上で定型的な自動化ツールが実行される場合と、エージェントによる処理が実行される場合に分かれるが、どちらの場合もSlackに通知が残されるという。
オンコールエージェントの構成
オンコールエージェントのゴールについて解説し、アラートをサマライズすること、原因を見つけること、その結果に至った過程を提示することなどを挙げた。
オンコールエージェントのゴール
そしてオンコールエージェントについて汎用的な知識を持っているツールよりも、ドメインに特化したエージェントを選択したことを説明。汎用的なエージェントと比較して予測がつきやすいこと、推論の出力結果が構造化されることなどを利点として挙げた。
汎用的なエージェントよりも特化したエージェントを選択
また決定論的にツールを使うという発想でアラートの発生したシステムの領域を限定して大規模言語モデルを利用することで、大規模言語モデルを信頼できないクライアントと位置付けることを説明。汎用ではなく領域特化でピンポイントにアラートの原因を突き止めるというやり方であることを説明した。
汎用的にLLMを使わずに領域を限定して使う発想
オンコールエージェントに関しては継続的に改善を行うとしてエンジニアによる原因分析とAIによる原因分析を比較して評価すること、エンジニアからのフィードバックを継続して収集することを説明した。目的はより正しい知識ベースを作ることだが、インシデントのポストモーテムを知識ベースの中に挿入することや実際に対応した記録なども活用することで品質を向上させる努力を続けるという。
オンコールエージェントの継続的改善を訴求
エンジニアをサポートするという生成AIの使い方として推論の結果の中に引用したデータ（ログ、メトリクス、対応のために実行されたスクリプトなど）を必ず残すこと、エンジニアがエージェントから引き継いで作業が行えるようにコマンドラインやIDEなどのツールを整備することなどを挙げた。
全体としてやや概念的な解説が多く具体的にどうやってツールが連携しているのか、定型的なアラート対応と生成AIによって推論された非定型なアラート対応の例などが乏しいのが残念だ。またコストセンターとみなされる運用エンジニアにとって、生成AIを使うためのコストは気になるところだろう。全体のコスト、どのモデルを使ったのか、プロンプトの量なども一切説明されなかったのは意図的に省略したとは思いたくないが、このユースケースを参考にしたい運用エンジニアにとっては欲求不満が残る内容となった。「塹壕からリアルなユースケースをレポートする」というタイトルからすれば、リアルな痛みや苦しみが感じられない内容となってしまった。次回以降に期待したい。