ナビゲーション全体を読み込み中です。

Elevate 2026へのカウントダウンが始まりました。 今すぐ登録 シカゴ、ロンドン、またはシドニーで私たちと一緒に過ごしませんか。

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

ロジックモニターブログ

マルチエージェントAIワークフローを監視する方法

A2AはAIエージェントを分散システムへと変革します。追跡すべきテレメトリ信号を把握することで、部分的な障害や隠れた依存関係がユーザーに影響を与えることを防ぎます。

7〜10分
デントン千倉

ニュースレター

最新情報のメール配信を登録

最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

シェア

クイックダウンロード:

GoogleのA2Aプロトコルは、マルチエージェントAIを分散システムのように動作させるため、分散システムとして観察する必要がある。

  • A2Aは現在、Linux Foundationの下で安定した1.xオープンスタンダードとなっており、エージェントカード、HTTP経由のJSON-RPC、ストリーミング、および長時間実行タスクを使用して、エージェントがサービス間で連携することを可能にします。

  • マルチエージェントチェーンは、分散システム特有の問題、すなわちファンアウト呼び出し、部分的な障害、再試行、タイムアウト、そしてユーザーエクスペリエンスを低下させる隠れた依存関係などを継承する。

  • 旅行予約フローにおける外部天気予報サービスのような、処理の遅い下流のエージェントが1つでも存在すると、他のエージェントは正常に動作していると報告しているにもかかわらず、タスクが停止し、ユーザーを苛立たせる可能性がある。

  • エージェントごとのレイテンシ、タスクのライフサイクル状態、下流APIの障害、認証エラー、依存関係マップなどを、エージェントワークフローが本番規模に達する前に計測しましょう。

AIエージェントは、その短い歴史のほとんどを孤立した状態で過ごしてきた。Googleの エージェント間（A2A）プロトコル これにより、専門エージェント間で共通のコミュニケーション、委任、およびコラボレーション手段が提供される。これは、多くの協調する部品から構築されるモジュール型AIシステムへの道を開く一方で、新たな運用上の問題も生み出す。ユーザーからのリクエストがエージェントの連鎖を通過する際、チームは各段階で何が起こったかを把握する方法を必要とするのだ。

このガイドでは、A2Aの仕組み、マルチエージェントワークフローが分散システムのように動作する理由、およびエージェント依存関係チェーンを本番環境で実行する際に監視する必要のあるシグナルについて説明します。

マルチエージェントの可観測性が今なぜ重要なのか

Googleは2025年4月9日にA2Aを導入しました。それ以来、Linux Foundationが管理するオープンプロトコルに移行し、リポジトリは github.com/a2aproject/A2A そして、Googleからの初期貢献。このプロジェクトは2026年3月12日にv1.0.0をリリースし、最新リリースは2026年5月28日付けのv1.0.1です。A2Aは現在、安定した1.xオープンスタンダードとなっています。

その成熟度によって、状況は一変します。チームは本番環境でエージェントワークフローを構築し、他のエージェント、内部サービス、サードパーティAPIを呼び出すエージェントを連携させています。これらのワークフローが実際のユーザーリクエストを処理するようになると、盲点によるコストはデモ的な興味の対象からビジネスへの影響へと変わります。だからこそ、エージェント依存関係チェーンの可観測性が今、重要になっているのです。

MCPとA2Aは異なる問題を解決する

ほとんどのエージェントは モデルコンテキストプロトコル (MCP) リアルタイムで外部ツール、API、または関数を呼び出すことで、応答をより充実させることができます。MCPはエージェントをナレッジベース、分析ダッシュボード、GitHubやJiraなどのサービスに接続し、トレーニングデータに保存されている情報よりもはるかに多くのコンテキストを提供します。

MCPは主に、単一のエージェントがツールやコンテキストにアクセスする方法を標準化します。A2Aは、エージェント同士が通信する方法を標準化します。両者は異なるレイヤーで動作します。MCPはエージェントがツールにアクセスする処理を担当し、A2Aはエージェント同士が互いを検出し、タスクを委任し、結果を返す処理を担当します。多くの実稼働システムでは、両方が使用されます。

A2Aの内部：テレメトリに関する質問を生み出す仕組み

A2Aは、エージェントが互いのクエリを発見、理解、連携する方法に関する標準を導入し、クエリの一部を最も解決能力の高いエージェントに委任します。この仕組みはいくつかのコアコンセプトに基づいており、それぞれが注目すべき点を提起します。

  • エージェントカード：エージェントが自身の機能とエンドポイントを公開するために公開する、JSONベースのメタデータ記述子です。チームは、どのエージェントが検出可能か、エージェントがどのような機能を提供しているか、そして公開されているエンドポイントに実際にアクセスできるかどうかを追跡する必要があります。
  • HTTP(S)上のJSON-RPC：エージェント間呼び出しのトランスポート。ここでは、チェーン内の各ホップにおけるリクエストの遅延、エラーコード、ペイロードサイズを監視できます。
  • ストリーミング：エージェントは、完全な応答を待つのではなく、部分的な結果をストリーミングで返すことができます。最初のトークン取得までの時間、ストリームの停止、接続の切断などを監視する必要があります。
  • プッシュ通知：エージェントは、作業完了時にクライアントに非同期で通知できます。つまり、コールバックの配信、再試行、および届かない通知を監視する必要があります。
  • 長時間実行されるタスク：A2Aは、作業の進行状況に応じてタスクのライフサイクルを状態変化とともにモデル化します。タスクの状態遷移を観察することで、タスクが停止しているのか、タイムアウトしているのか、あるいは途中でサイレントエラーで失敗しているのかを把握できます。
  • エージェント間の認証と認可：エージェントは作業を委任する前に相互に認証を行います。認証失敗やトークンの有効期限切れは、それぞれ独立したインシデントとして扱われるため、それらがどこで、なぜ発生したのかを把握する必要があります。

A2Aは分散システムの動作を生み出す

エージェント間の通信は、分散システムにおいてチームが既に管理しているのと同様の動作を生み出します。1つのリクエストが複数の下流エージェントに分岐し、それらのエージェントのいずれかが部分的に失敗する一方で、他のエージェントが成功することもあります。依存関係は、遅延が発生するまで隠されたままです。リクエストはキューに入れられ、呼び出しは再試行され、各レイヤーには独自のタイムアウト予算があります。チェーンが複数のチームにまたがると所有権が曖昧になり、トラブルシューティングはベンダーの境界を越えてサードパーティのAPIにまで及ぶことがよくあります。

エージェントとのやり取りはすべて、本質的にはサービス呼び出しです。これは遅延を増加させ、障害発生箇所を増やし、何らかの不具合が発生した際の原因究明を複雑化させます。

マルチエージェントワークフローにおける障害発生経路

旅行予約アシスタントを考えてみましょう。ユーザーがフライトの予約を依頼します。リクエストの流れは次のようになります。

  • ユーザーからのリクエストは、ワークフローを調整するオーケストレーションエージェントに到達します。
  • オーケストレーションエージェントは、フライトエージェントに旅程の検索と確保を委任します。
  • フライトエージェントは、内部決済APIを呼び出して料金の承認を行います。
  • また、ワークフローでは、A2A経由で外部の気象・状況エージェントを呼び出し、障害の有無を確認します。
  • 気象エージェントの応答が遅く、オーケストレーションエージェントがそれを待つため、ユーザーは劣化した遅延応答を受け取ることになる。

ユーザーが予約処理の遅延を一度経験した場合、その原因は3段階離れた外部エージェント（チームが管理していないもの）にある。各段階の状況を把握できないため、遅延の原因となっている下流側の呼び出しを特定するのは難しく、チームはどの部分を最初に調査すべきかを推測するしかない。

エージェント依存チェーンで監視すべきシグナル

マルチエージェントワークフローを安心して運用するには、チェーンに計測機能を組み込み、リクエストの劣化を説明するシグナルを確認できるようにする必要があります。基本事項は以下のとおりです。

  • エージェントごとのレイテンシなので、遅いホップを特定できます。
  • タスクのライフサイクル状態を把握することで、停止しているタスクや完了しないタスクを特定できます。
  • 下流のAPI障害を把握することで、エージェントの問題と依存関係の問題を切り分けることができます。
  • エージェント間の認証エラーが発生するため、トークンや権限の問題が早期に顕在化する。
  • 依存関係マップにより、どのエージェントがどのサービスを呼び出しているかを確認できます。
  • 再試行ループを使用することで、負荷や遅延を静かに増大させる呼び出しを捕捉できます。
  • 外部エンドポイントの健全性を監視することで、サードパーティのエージェントやAPIを常に把握できるようにします。
  • ユーザーエクスペリエンスへの影響を把握することで、技術的な不具合とユーザーが実際に感じたことを結びつけることができます。

業界は既にマルチ化しており、次はAIだ。

DNS、CDN、クラウド、そして今やAIに至るまで、チームは単一のプロバイダーから、パフォーマンス、コスト、信頼性、そしてユースケースへの適合性を最適化するマルチベンダーのエコシステムをオーケストレーションする方向へと移行している。

  • DNS：多くの企業は、より高速な名前解決、より広い地理的範囲のカバー、および組み込みのフェイルオーバーを実現するために、マルチDNS戦略を採用しています。
  • CDN：マルチCDNアーキテクチャは、遅延、地域、またはコストに基づいてトラフィックをルーティングし、エッジにおける冗長性とパフォーマンスを向上させます。
  • クラウド：AWS、Azure、GCPなどが差別化されたサービスを提供しているため、マルチクラウドは戦略的な選択肢となっている。

これらの動きは、専門化、最適化、リスク管理をもたらしました。同時に、厳しい教訓も教えてくれました。可視性のない冗長性は、インシデントの解決を容易にするどころか、むしろ困難にするということです。複数のDNSやCDN構成で障害が発生した場合、プロバイダー間の状況を把握できないチームは、単一プロバイダーの場合よりも障害の特定に時間がかかります。マルチエージェントAIも、最初から監視体制を整えておかない限り、このパターンを繰り返すでしょう。

マルチエージェントシステムにおけるエンドツーエンドの可視性の実現

多くの監視手法は、インフラストラクチャ、アプリケーション、または単一サービスの境界で停止します。A2Aの世界では、単一のユーザーリクエストが、それぞれ異なるシステム上で動作し、異なるチームが所有し、異なるAPIに依存するエージェントの連鎖を通過する可能性があります。可視性は、リクエストをそのすべての段階にわたって追跡する必要があります。

LogicMonitorは、自律型IT向けのAIファーストプラットフォームであり、インフラストラクチャ、合成データ、インターネットパフォーマンス監視を1つの接続システムに統合しています。エージェント型の依存関係チェーンにおいて、各機能はそれぞれ異なる運用上の課題に対応します。

  • LogicMonitorによる合成データおよびインターネットパフォーマンス監視、 とともに インターネットスタックマップこれにより、問題が外部インターネット経路にあるのか、外部エージェントAPIにあるのかを判断するのに役立ちます。依存関係チェーンをサードパーティのエンドポイントにマッピングすることで、外部の遅延と内部の遅延を区別できます。
  • LMエンビジョン 内部サービスやインフラストラクチャが正常かどうかを判断します。インフラストラクチャ、クラウド、アプリケーション、ログなど、お客様が所有するエージェントやサービスが実際に実行される場所全体にわたるハイブリッドな可観測性を提供します。
  • エドウィン AI チェーン全体にわたるシグナルを相関させ、アラートノイズを削減し、ビジネスへの影響度に基づいて優先順位を付け、根本原因の特定を迅速化します。複数のエージェントやAPIが同時に障害を起こした場合でも、すべてのアラートを追跡するのではなく、重要な障害に集中できるよう支援します。

これらの機能を組み合わせることで、エージェント型ワークフローにおけるユーザーからコードまでの可視性が実現します。デジタル体験からインターネット経路、クラウド依存関係、インフラストラクチャの状態に至るまでリクエストを追跡し、問題が発生した際にはコンテキストと修復策を取り込むことができます。

A2Aは、クライアントエージェントとリモートエージェント間のコミュニケーションを円滑にします。

キャッチポイントLogicMonitor傘下の企業は、Googleの基本的なA2Aインタラクションをローカルで実装しました。 オープンソース仕様これはモジュール式で拡張性があり、APIがサービス間の通信を変革した方法と似ています。

リモートエージェントはポート8001で待機し、タスクを受信する準備ができています。エージェントカードを通じて自身の機能を通知し、受信したリクエストに応じて処理を実行します。

リモートエージェントはポート8001で待機し、エージェントカードを通じてその機能を通知します。

ホストエージェントはまずリモートエージェントを検出し、その機能を取得した後、エージェントカードで定義されたエンドポイントにクエリプロンプトを送信します。そして、最終的な応答を受信して​​返します。

ホストエージェントはリモートエージェントを検出し、そのエンドポイントにクエリを送信し、応答を返します。

インターネットスタックマップは、リクエストが内部コンポーネントを経由して、依存する外部エージェントAPIにどのように流れるかを視覚化します。このビューにより、エージェントの連鎖が複数のチーム、システム、サードパーティサービスにまたがる場合に発生する盲点を減らすことができます。

エージェントワークフローを監視するための次のステップ

チームはシングルCDNからマルチCDNへ、モノリシックアプリケーションからマイクロサービスへと移行し、その都度、監視の基準が引き上げられてきました。マルチエージェントシステムも同様に厳格な監視が必要です。エージェントワークフローを本番環境に導入する場合は、まずここから始めましょう。

  • 内部エージェント、サービス、サードパーティ製エージェントAPIなど、エージェントの依存関係をすべて洗い出します。
  • Instrumentエージェントが呼び出しを行うため、各ホップで遅延、エラー、タスクの状態が報告されます。
  • 所有していないエージェントであってもユーザーエクスペリエンスを低下させる可能性があるため、外部エンドポイントを監視してください。
  • ユーザーの行動経路をプロセス全体を通してマッピングすることで、技術的な不具合と実際の影響を結びつけることができます。
  • エージェント障害の責任者を明確に定義することで、共有チェーン内のインシデントに対して明確な対応者を定めることができます。

このアプローチにより、サプライチェーン全体の可視性が向上し、ホップの劣化が発生した場合の迅速な位置特定と、何らかの障害が発生した場合の迅速な根本原因の特定が可能になります。

A2Aワークフロー全体におけるすべてのエージェント、依存関係、およびユーザーへの影響を1つの画面で確認できます。

ユーザーエクスペリエンスから外部依存関係、内部インフラストラクチャに至るまで、エージェントのワークフローを追跡します。顧客に影響が出る前に、劣化したタスクや障害が発生したエンドポイントを特定します。

よくあるご質問

Googleのエージェント間プロトコル（A2Aプロトコル）とは何ですか？

A2Aは、Linux Foundationの下でバージョン1.xとして安定しているオープンスタンダードであり、独立したAIエージェント同士が互いを検出し、連携することを可能にします。エージェントはエージェントカードを通じて自身の機能を記述し、HTTP上のJSON-RPCを使用して通信します。ストリーミング、プッシュ通知、長時間実行タスクもサポートされています。これにより、マルチエージェントシステムは、サービスやベンダーを問わず、共通の方法で連携できるようになります。

A2AはMCPとどう違うのですか？

A2AとMCPは、エージェントスタックの異なるレイヤーを解決します。MCPは、単一のエージェントを、動作に必要なツール、データ、コンテキストに接続します。A2Aは、複数のエージェント間の通信と調整を処理します。マルチエージェントワークフローを構築するチームは、多くの場合、両方を併用します。

マルチエージェントワークフローに可観測性が必要な理由は？

エージェントが他のエージェントを呼び出すと、ワークフローは分散システムのように動作し、リクエストの分岐、部分的な失敗、再試行、隠れた依存関係が発生します。下流のエージェントが1つでも遅い、または障害が発生すると、各エージェントが単体では正常に見えても、ユーザーエクスペリエンスが低下する可能性があります。エージェントごとのレイテンシ、タスクのライフサイクル状態、下流APIの障害、認証エラー、依存関係マップを監視することで、チームはユーザーが問題を感じる前にこれらの問題を特定して修正できます。

デントン千倉著

テクニカルライター

デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。

関連ブログ

統合クラウド監視がハイブリッドITの盲点を解消する方法
Blog クラウド

統合クラウド監視がハイブリッドITの盲点を解消する方法

現代のITは、パブリッククラウド、データセンター、コンテナ、SaaS、ネットワーク、AIサービスなど、複数の環境にまたがって運用されています。これらの環境が同じ可観測性コンテキストを共有することで、クラウド監視はより大きな価値を発揮します。これにより、チームはサービスの問題をより明確にトラブルシューティングし、クラウド支出を管理し、AIを活用した運用をサポートできるようになります。
2026 年 9 月 30 日
さらに詳しく
WebMCP監視：AIエージェントにとってウェブサイトの稼働時間だけでは不十分な理由
Blog WebMCPモニタリング

WebMCP監視：AIエージェントにとってウェブサイトの稼働時間だけでは不十分な理由

ウェブサイトが正常に見えていても、AIエージェントが誤動作する可能性があります。WebMCPのモニタリングでは、ツール検出からバックエンド応答まで、エージェントの動作全体を検証するために合成テストがどのように使用されるかをご覧ください。
2026 年 9 月 18 日
さらに詳しく
LogicMonitor Syntheticsとインターネットパフォーマンスモニタリングで、あらゆるデジタルジャーニーをより効果的に監視する方法
Blog 総合モニタリング

LogicMonitor Syntheticsとインターネットパフォーマンスモニタリングで、あらゆるデジタルジャーニーをより効果的に監視する方法

LogicMonitor Syntheticsとインターネットパフォーマンスモニタリングは、アプリケーション、ネットワーク、API、SaaS全体にわたる外部からの可視性を提供することで、IT運用チームがデジタルエクスペリエンスの問題を早期に発見するのに役立ちます。
2026 年 9 月 14 日
さらに詳しく