【ITニュース解説】Agentic AI Operations: Evidence-Carrying Handoffs for Multi-Agent Diagnosis

現代のITシステムは非常に複雑で、多くの異なるサービスやコンポーネントが連携して動作している。このような複雑なシステムで何か問題が発生したとき、その原因を特定し解決することは、システムエンジニアにとって大きな課題となる。最近では、この課題解決に人工知能（AI）を活用する「AIOps（AI for IT Operations）」という考え方が注目を集めている。特に、複数のAIが連携して問題を診断する「マルチエージェントシステム」が、より高度な自動運用を目指す上で重要な役割を果たす。

マルチエージェントシステムとは、システム運用におけるさまざまなタスクを、それぞれ専門の能力を持つ複数のAIエージェントに分担させ、それらが連携して処理を進める仕組みのことである。例えば、システム全体の挙動を監視する「オーケストレーターエージェント」が、人間のオペレーターからの「システムが遅い」といった要求を受け取ると、その要求を分析し、「インシデント診断エージェント」や「Q&Aエージェント」、「レポーティングエージェント」といった専門のAIエージェントに適切なタスクを割り振る。これにより、複雑な問題を効率的に解決しようとするのが狙いだ。Bonreeが提供するSage AIのようなシステムも、まさにこのマルチエージェントワークベンチの一例として紹介されている。

しかし、このようなマルチエージェントシステムでは、各専門エージェントがタスクを完了した後にオーケストレーターエージェントに結果を「ハンドオフ（引き渡す）」する際に、ある大きな課題がある。それは、その引き渡される情報の「信頼性」と「検証可能性」だ。もし専門エージェントが「データベースが不健全に見える」という漠然とした結果を返してきた場合、オーケストレーターはその情報をそのまま受け入れるしかない。人間の担当者が後から確認しようとしても、その結論がどのようなデータに基づいているのか、データベースへのクエリ結果なのか、特定の運用手順書（ランブック）によるチェックなのか、あるいは単なる推測なのかが全く分からないのである。

このような不確かな情報に基づいた判断は、特にAIエージェントに自律性が与えられ、複数のエージェントが連携して多段階のワークフローを実行する場合に、非常に大きなリスクとなる。検証されていない主張が次のステップの入力となり、それが連鎖的にシステムの誤った判断を引き起こす可能性もあるため、結果としてシステム全体の信頼性が低下してしまうのだ。そこで、この記事では、このハンドオフの弱点を克服し、マルチエージェント診断の監査性と改善を容易にするための四つの重要なパターン（設計思想）を提案している。

一つ目のパターンは「エビデンス（証拠）を伴うハンドオフ」である。これは、専門エージェントが単なる文章ではなく、構造化された形で回答を返すことを求める考え方だ。具体的には、以下の要素を含むようにする。まず、結論となる「主張（Claim）」を簡潔な一文で提示する。次に、その主張に対する「確信度（Confidence）」を「低・中・高」といった大まかな段階で示す（厳密すぎるパーセンテージはかえって誤解を招くため避ける）。そして最も重要なのが「証拠（Evidence）」だ。これは、その主張がどのようなデータソースから、どのようなクエリや参照を使って、どの時間範囲の、どのシステムエンティティ（特定のサーバーやアプリケーションなど）について、何が観測されたのかを具体的に示す。さらに、「除外されたもの（Ruled out）」として、検証の結果問題がないと判断された項目やチェックしたシグナルを明記する。最後に、もしその主張が間違っていた場合に次に何をチェックすべきか「提案される次のチェック（Suggested next check）」を添える。この証拠には、例えばシステムの動作を追跡するOpenTelemetryのトレース情報、各種メトリクス、ログなど、後から再現・検証可能な情報源を含める。これにより、オーケストレーターや人間は、エージェントの判断が妥当であるかを検証しやすくなるのだ。

二つ目のパターンは「トポロジー（システム構成）全体での排除による推論」だ。大規模なシステムでは、すべてのサービスやコンポーネントのすべてのメトリックを一つずつチェックするのは時間とリソースがかかり、ノイズも多くなる。そこで、システム全体の構成（トポロジー）を理解し、そのコールチェーン（サービス間の呼び出し関係）に沿って問題箇所を絞り込む効率的な推論を用いる。例えば、システムへの入り口となるサービスでエラーが発生しているにもかかわらず、そのサービスが呼び出している下流のサービスではエラーが全く発生していない場合、問題は入り口のサービスにある可能性が高いと判断できる。この場合、下流のサービス群を詳細に調べる必要はなくなり、調査範囲を大きく絞り込むことが可能になる。Bonreeの事例では、エントリポイントサービスでわずかな失敗があったが、その下流の二つのサービスではエラー率がゼロだったため、調査はエントリポイントノードに絞り込まれた。さらに、この三つのサービスが同じホストにデプロイされており、そのホスト自体に未解決のアラートがあるという単一障害点のリスクも特定された。ただし、「エラー率がゼロだから健全」とは限らない点には注意が必要で、レイテンシ（遅延）や飽和（リソース不足）といった別の問題がないか、どのシグナルをチェックしたかを記録することが重要だ。

三つ目のパターンは「ツール層の共有と推論の専門化」である。もし各専門エージェントがそれぞれ独自のデータコネクタやツールを持つと、新しいエージェントを追加するたびに連携のためのコストが増大してしまう。この問題を解決するためには、エージェントが利用するモデル、ツール、知識を共通のプールとして管理し、エージェント間ではその利用方法や推論ロジックの部分で専門性を持たせる設計が望ましい。Bonree Sage AIもこの考え方に基づいており、エージェントは共通のプールからリソースを利用するため、新しいシナリオに対応する際に接続設定などを重複させる必要がない。

さらに、三つ目のパターンに関連して、「共有層をフレームワーク非依存にする」という設計思想も重要である。AIエージェントのオーケストレーションには様々なフレームワーク（例: LangChain, Difyなど）が存在し、チームが複数のフレームワークを利用する可能性もある。もし共有ツール層が特定のフレームワークのAPIに直接結合されていると、別のフレームワークを導入するたびにコネクタを再配線する手間が発生する。これを避けるため、ツール関数、スキーマ、そしてパターン1で定義したエビデンス形式を、特定のオーケストレーターフレームワークから独立して定義し、薄いアダプター層を介して各フレームワークにマッピングする設計が推奨される。これにより、共通の契約（ツールやエビデンスの形式）を維持しつつ、エージェントを構築するフレームワークの選択肢を広げることができる。

四つ目のパターンは「過去のインシデントを回帰テストスイートとして再生する」ことだ。これは、過去に発生し解決済みのインシデントの情報を「テストケース」として蓄積し、新しい診断システムやエージェントの変更があった際に、それらの過去のインシデントを再現して診断の精度を評価する仕組みである。過去のインシデントは、アラートの内容、その時のシステムトポロジーのスナップショット、問題が発生した時間帯、そして人間が確認した根本原因といった情報を含んでいる。これらの情報を入力として現在の診断システムに与え、以下の項目を測定する。根本原因のヒット率（最終的な主張が確認された原因と一致するか）、エビデンスの妥当性（提示されたクエリが主張された内容を再現するか）、除外された項目の精度（問題ないとされた部分が本当に無実だったか）、そして最初の有用な仮説にたどり着くまでのステップ数（エージェントがどれだけ早く検索範囲を絞り込んだか）である。これにより、診断システムの改善効果を客観的に評価し、信頼性を継続的に高めることができる。

もちろん、これらのアプローチにはいくつかの制限もある。エビデンスのチェックは、引用された情報が再現可能であることを証明するが、それに基づいて導き出された推論が常に正しいとは限らない。また、エビデンスを再実行するには、安定してクエリ可能なツールインターフェースが不可欠だ。排除による推論も、参照するシステムトポロジーの正確性に依存する。そして、少数の過去のインシデントから構築されたリプレイスイートは、特定のケースに過剰に適応してしまう（オーバーフィット）リスクがある。フレームワーク非依存のツール契約は、複数のフレームワークを使うチームにはメリットがあるが、単一フレームワークのチームにとっては一時的なオーバーヘッドとなる可能性もある。

しかし、これらのパターンは、マルチエージェントAIシステムが、現在の複雑なIT運用において信頼性高く、効率的に問題を診断し、解決していく上で非常に重要な指針となる。エビデンスに基づく透明性の確保、システム構成の理解による効率化、共通ツール層の活用、そして過去の経験からの継続的な学習は、システムエンジニアがより高度な自動化された運用システムを構築する上で不可欠な要素となるだろう。これらの考え方を理解し、活用することで、AIがIT運用に貢献する未来がより確実なものになる。