エージェントがエージェントをオーケストレーションする時、誰が監視するのか？

かつて、あなたが監視していたのはサービスでした。

その後、サービス内部で動く AI 呼び出しを監視するようになりました。

そして今では、AI エージェント自身がタスクを完了するために別の AI エージェントを立ち上げるようになっています。これまでの監視に対する感覚は、もはや通用しなくなりつつあります。

これは仮定の話ではありません。エージェント型アーキテクチャは、すでに本番環境で動いています。コーディングエージェントが検索エージェントを呼び出し、オーケストレーターが検索、計画、実行のための専門サブエージェントを生成しています。チームは、それらをどう監視するかを理解するよりも早いスピードで、こうしたシステムを出荷しています。

問題はエージェントが失敗することではありません。問題なのは、失敗した時にどのエージェントが原因だったのか、あるいはそもそも技術的に「失敗」と呼べるものが起きていたのかすら分からないことです。

従来のトレーシングはこの世界のために作られていない

従来のスタックでは、リクエストをデバッグするとは、エントリーポイントからデータベースまで、1本の流れを追跡することを意味していました。1つのサービス、1人の責任者、1か所の調査対象です。

しかしマルチエージェントシステムでは、1回のユーザー操作によって、プランナーエージェント、3つのツール呼び出しエージェント、検証エージェント、書き込みエージェントが動作するかもしれません。つまり5つのアクターが関与し、それぞれ異なるモデル、異なるプロンプト、そして大きく異なるレイテンシ要件を持っている可能性があります。

しかも、エラーは必ずしも例外として表面化しません。サブエージェントによる不適切な出力は、エラーを投げることなく、単に問題の連鎖を始めるだけかもしれません。その破損したコンテキストは、後続のチェーンへと伝播していきます。オーケストレーターは成功したと思っている。しかしユーザーはおかしな結果を見る。そしてログを開いても、明らかに壊れているものは何も見つからないのです。

これが実際にどのようなものかを見たいなら、実際のマルチエージェントデバッグセッションを分解した事例を見るとよいでしょう。2段階上流で発生した静かなツール障害が、1つのエラーも発生させないまま最終出力を破壊していく様子が示されています。「ログを読めば分かる」という感覚が、このレベルの複雑さでは通用しなくなる理由をよく表しています。この世界では、小さなズレが積み重なり、やがて雪崩のように広がっていくのです。

この投稿では、チーム横断かつエンタープライズレベルの信頼性が求められる大規模運用環境において、その複雑さがどのように現れるのかに焦点を当てます。

可視性の問題はスケールとともに増幅していく

1つのエージェントなら把握できます。2つでも管理可能でしょう。しかし、5つのエージェントが条件分岐しながら互いを呼び出し、コンテキストを共有している状態になると、それはもはやまったく別の種類の問題になります。

あなたがデバッグしているのは、もはやコード実行ではありません。分散した意思決定グラフ全体にわたる、創発的な振る舞いです。かつてマイクロサービスによって、「スタックのどこかが遅い」という言葉が、トレースなしでは意味を持たなくなったように、マルチエージェントシステムでは、適切なインストルメンテーションなしに「AI が何かおかしなことをした」と言われても、ほとんど対処不能になります。

多くのチームは、それを痛みを伴って学びます。たとえば、原因不明のユーザー離脱率の急増かもしれません。あるいは、チェーンの3段階下流で、LLM が静かに誤ったデータを返しているケースかもしれません。ある日突然、トークンコストが3倍になっていることもあるでしょう。しかし、単一コンポーネントとして閾値を超えていないため、アラートは何も発火しません。

分散トレーシングは、マイクロサービスにおいて、まさにこの問題を解決してきました。今問われているのは、あなたの AI パイプラインが、その次の世代の問題に対応できるようインストルメントされているかどうかです。

実際に役立つマルチエージェント監視とは

マルチエージェントシステムの可視化は、新しい製品カテゴリの話ではありません。重要なのは、適切な粒度で、適切な基本要素を適用することです。Sentry の AI オブザーバビリティ機能は、分散トレーシングと同じ基盤の上に構築されています。そのため、複雑さが増しても、基本的な考え方は変わりません。実際には、次のようなものが必要になります。

エージェント間ハンドオフをまたぐトレース継続性

トレース ID は、エージェント呼び出しごとにリセットされるのではなく、タスク全体を通して引き継がれる必要があります。必要なのは、誰が何を、どの順番で、どの入力と出力を伴って呼び出したのかを示す完全なツリー構造です。すべてのスパンが同じ親を持つフラットな一覧では、チェーン途中のどのエージェントが不正な状態を生み出したのかを理解するには不十分です。

エージェント単位でのスパン属性付け

レイテンシ、トークン使用量、モデルバージョン、プロンプトハッシュ、出力シグナルなどは、トップレベル呼び出しへまとめるのではなく、各エージェント単位で把握できる必要があります。「オーケストレーターが 4.2 秒かかった」という情報だけでは、ほとんど意味がありません。しかし、「低信頼度の結果を返した検索サブエージェントを 3.8 秒待っていた」と分かれば、調査箇所は明確になります。このレベルの属性付けは、モデルバージョン、トークン数、プロンプト識別子などのメタデータを、インストルメンテーション時に各スパンへ付与することで実現できます。

障害モードの区別

エージェントのタイムアウト、不正なツール出力、コンテキストウィンドウのオーバーフロー、モデル拒否、技術的には正常な応答の下流で発生するハルシネーション。これらはすべて異なる問題であり、必要な対処法もまったく異なります。それらをすべて「AI エラー」と一括りにするのは、すべての 500 エラーを「server error」とだけ記録するようなものです。技術的には間違っていなくても、運用上は役に立ちません。

タスク単位でのコストとトークン使用量の属性付け

6つのエージェントを生成して 40K トークンを消費したタスクは、4K トークンしか使っていないタスクとは、まったく別物です。この情報は、月末の請求集計の中に埋もれていてはいけません。クエリ時に、トランザクション単位、ユーザー単位、機能単位で分解できる必要があります。そのためには、各エージェント境界で、コストと使用量のメタデータをスパンへタグ付けしておく必要があります。

エージェント関係を示すネストされたスパンツリー

Sentry のトレースビューでは、エージェント呼び出しはネストされたスパンとして表示されます。これにより、どのエージェントが、どの順番で、どのエージェントを呼び出し、何を消費したのかが分かります。複数エージェントが同じツールを共有して呼び出している場合や、下流エージェントが複数の親から呼び出されている場合も、その構造はトレース上で可視化されます。

もし使用しているフレームワークがサポート対象に含まれていなくても、手動インストルメンテーションはそれほど大変ではありません。Sentry の gen_ai.* スパン規約、たとえば gen_ai.invoke_agent、gen_ai.execute_tool、gen_ai.request などを使えば、スパンタイプごとにおよそ10行程度のコードで対応できます。

セットアップ前に知っておくべき点があります。AI 統合では、recordInputs と recordOutputs がどちらもデフォルトで true になっているため、プロンプトとレスポンスの内容は標準で収集されます。もしプロンプトやレスポンスに機密データが含まれる場合は、両方を false に設定してください。また、本番環境でデフォルト設定のまま運用する前に、こうした内容の収集がプライバシーポリシー上許可されていることを確認する必要があります。

いずれの場合でも、最終的には、ネストされたエージェント呼び出し、ツール実行、LLM 呼び出しを子スパンとして含むトレースツリーが得られます。これによって、実行状況やパフォーマンスの可視性は確保できます。ただし、出力の正確性や意思決定の品質を理解するには、その上にさらに検証レイヤーを追加する必要があります。

Seer はトリアージまでの時間短縮にも役立ちます。たとえば、5つのエージェントにまたがるマルチエージェントタスクが失敗した場合、Seer はエラーコンテキストを分析し、最も可能性の高い劣化原因を提示できます。5つの「どれもあり得そうな候補」から手探りで始めるのではなく、実際の本番データに基づいた調査開始地点を提供してくれます。

対応フレームワーク全体にわたる詳細なセットアップについては、AIエージェントオブザーバビリティガイドでインストルメンテーション方法が詳しく解説されています。初めて導入する場合は、まずそこから始めるのがよいでしょう。

実践的な最初の一歩としては、まずオーケストレーターをインストルメントすることをおすすめします。トップレベルタスクをトランザクションとして扱い、それぞれのエージェント呼び出しを子スパンとして記録します。深夜2時に本番環境の劣化対応を迫られた時、部分的な可視性であっても、何も見えない状態よりははるかにましです。

これは、「準備できているか」という問い

エージェント型システムを導入するチームは、かつて SRE チームがモノリスからマイクロサービスへ移行した時と同じ問いに直面することになります。

「正しく動いていると、どうやって確認するのか？」

この問いは、すぐに現実の問題になります。エージェントによるワークフローが大規模に誤答を返した時。誰も原因を特定できないまま、トークンコストだけが膨れ上がった時。どの個別スパンも異常を示していないのに、システム全体が劣化した時。その瞬間、この問いは急に切実なものになります。その時点で、すでにインストルメントしていたチームはトリアージを始めています。そうでないチームは、推測することしかできません。

実際のトレース、実際の属性付け、実際のアラートによって、この問いへ最初に答えられたチームだけが、エージェントを本番で運用し続けられます。説明できない最初のインシデントでロールバックするのは、それ以外のチームです。

マルチエージェントオブザーバビリティは、大規模運用において「あれば良い」ものではありません。エージェントをプロトタイプ段階の先へ進めるなら、それは最低条件です。複雑さは、本番環境に現れる前に許可を求めたりはしません。すでに、そこに存在しているのです。