GoogleのA2Aプロトコル登場と次なる課題「オブザーバビリティ」

観測せよ、AIの連携網

2025年3月31日
著者: Ankit Kumar
翻訳: 逆井 晶子

この記事は米Catchpoint Systems社のブログ記事「Google’s Agent-to-Agent (A2A) Protocol is here—Now Let’s Make it Observable」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

あなたのAIツールは本当に連携して動作していますか？
それとも、いまだにエージェントが孤立して動作していますか？
Googleの新しいAgent-to-Agent (A2A)プロトコルの導入によって、もはやAIエージェントが単独で動作する時代ではなくなろうとしています。

この新しい標準は、専門特化したエージェント同士が通信し、委任し、協力できるようにするもので、モジュール化され、スケーラブルなAIシステムの新時代を切り開きます。
A2Aがどのようにワークフローを変革する可能性があるのか、そしてそれを「可能にする」ことと同じくらい「観測可能にする」ことが重要である理由を解説します。

協調型AIにおける画期的なA2Aの意義

A2Aがなぜ画期的なのかを理解するには、AIエージェントの進化を振り返るとよくわかります。
これまでの多くのエージェントは、Model Context Protocol（MCP）に依存してきました。
MCPは、リアルタイムで外部ツールやAPI、関数などを呼び出すことで応答を強化できる仕組みです。

MCPは、ナレッジベースや分析ダッシュボード、GitHubやJiraのような外部サービスとエージェントを接続し、学習データ以上のコンテキストを与える点で大きな進歩でした。
とはいえ、MCPは根本的に単一エージェントのアーキテクチャであり、エージェント自身が外部ツールを呼び出して自己強化する仕組みに過ぎません。

GoogleのA2Aプロトコルは、さらに一歩進んでいます。
複数のAIエージェントが相互に発見し合い、理解し合い、協力し合えるような標準仕様を定めています。
また、クエリの一部を最適なエージェントに委任することが可能です。

金融、医療、カスタマーサポート、DevOpsなど、専門特化型のエージェントが普及している現代において、このようなマルチエージェントの協調モデルは、インテリジェントなアプリケーションの構築方法を再定義する可能性があります。
マルチエージェントシステムは、モジュール化され、スケーラブルで、高い専門性を備えています。

業界はすでに「マルチ」化している——AIも次に続く

A2Aの意義を理解するには、近年のインフラストラクチャ全体に見られる大きな流れを見てみましょう。
DNS、CDN、クラウド、さらにはAIにおいても、単一ベンダーからマルチベンダーのエコシステムへと移行しています。
パフォーマンス、コスト、信頼性、ユースケースへの適合性を最適化することを目的としています。

DNS

以前は単一のDNSプロバイダを使うのが主流でしたが、今では多くの企業が、応答速度の向上や地理的冗長性、障害時の切り替えを目的に、マルチDNSの導入を進めています。

CDN

単一CDNからマルチCDNへの移行により、レイテンシーや地域、コストに応じてトラフィックをルーティングし、冗長性とエッジでのパフォーマンスを向上させています。

クラウド

AWS、Azure、GCPなどが独自サービスを提供しており、マルチクラウド戦略が主流です。
チームはベストなサービスを選び、特定のベンダーへの依存を減らしています。

この「マルチ」戦略は、単なるリスク管理にとどまらず、専門化と最適化を実現するための選択でもあります。

AI分野でも、同様の動きが見られます。
初期の導入企業はGPT-4、Gemini、Claudeなどの単一の基盤モデルを選んでいましたが、今後はマルチエージェントシステムが主流になるでしょう。
あるエージェントはデータ解釈に特化し、別のエージェントは意思決定に、さらに別のエージェントは特定業界向けのコンプライアンス対応に特化するようになります。

A2Aの内部構造：リアルタイムでのエージェントの発見と委任

GoogleのA2Aプロトコルは、エージェント同士が動的に連携できるフレームワークを提供します。
例えば、次のようなシナリオを想像してください。

ユーザーが「ニューヨークの天気は？」と尋ねたとします。

エージェント1がそのクエリを受け取りますが、リアルタイムの天気データにはアクセスできません。
しかし、A2Aプロトコルを通じて、エージェント2が天気情報に特化していることを知っています。
エージェント1はエージェント2に問い合わせ、正確なデータを取得してユーザーに返します
ユーザーは、複数のエージェントが連携していることを意識することなく、自然に回答を得られます。

このインタラクションを支える概念は以下の通りです。

ホストエージェント（クライアントエージェント）

ユーザークエリを受け取り、必要に応じて他のエージェントに委任する発信元のエージェント

リモートエージェント

他のエージェントから呼び出された際に、専門タスクを実行できるエージェント

エージェントカード

エージェントの機能やエンドポイントを記述したJSON形式のメタデータ。
これにより他のエージェントが発見・ルーティングを行いやすくなります。

筆者はGoogleのオープンソース仕様を使って、ローカル環境で基本的なA2Aインタラクションを実装してみました。
そのモジュール性と拡張性は非常に高く、APIがサービス間通信を変革したように、A2Aはエージェント間オーケストレーションを変える可能性があります。

以下はローカル実装の例です。

リモートエージェントはポート8001で待機し、タスクの受信に備えています。
Agent Cardを通じて自身の機能を公開し、受け取ったリクエストをそれに応じて実行します。

ホストエージェントはリモートエージェントを発見し、その機能情報を取得し、Agent Cardに定義されたエンドポイントへクエリを送信して、最終レスポンスを受け取ります。

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

マルチエージェントAIシステムは、強力な新機能を提供する一方で、新たなリスクももたらします。
従来のシステムでは、スタックの外側に出ると可観測性が途切れていました。
ですが、A2Aでは1件のリクエストが複数のエージェントを通過するため、より広範な可視化が求められます。
各エージェントは異なるシステム上で動作し、異なるチームが所有し、異なるAPIに依存していることもあります。

エージェント同士のやりとりは、基本的にはサービス間のAPIコールと同様のものです。
つまり、以下のような課題が新たに生じます。

• レイテンシーの追加
• 障害ポイントの増加
• トラブル時の複雑性の増加

例えば、チケット予約アプリのチャットボットを考えてみてください。
このボットは、空席情報や決済のために社内マイクロサービスを使いながら、天気情報やフライト状況の取得にはA2Aで外部エージェントに依存しています。
どれか1つでも遅延や応答なしになれば、全体の体験が悪化します。
そして、可視化されていなければ問題の特定も困難です。

ここで「可観測性」が重要になります。
サービスやエージェント間の依存関係（社内・外部ともに）をマッピングすることで

• 遅延やエラーの発生箇所を特定
• エージェント間の連携の理解
• 障害時の根本原因の迅速な特定

が可能になります。

CatchpointのInternet Stack Mapのようなツールは、こうしたフローを可視化するのに役立ちます。
これは、Internet Performance Monitoring（IPM）を活用して、リクエストが内部コンポーネントから外部エージェントAPIにどう流れるかを示し、依存関係や潜在的な問題箇所を明確にします。

CDNが単一からマルチへ、アプリがモノリシックからマイクロサービスへと移行してきたように、いま、マルチエージェントの時代が幕を開けようとしています。
そして、そうした分散システムを監視する方法を学んできたように、マルチエージェントシステムも同じように監視していく必要があります。

なぜなら、未来は単なるAIではなく、協調するAIなのです。
モジュール化され、分散され、協働するAI——そして、その可視化を可能にするのがIPMなのです。

詳細はこちら
Internet Stack Mapが障害の兆候をどのように先取りできるのかをご覧ください。
また、詳細をご希望の方は、以下のフォームよりお問い合わせください。