A2A プロトコルは、エージェント間通信のための堅牢で標準化されたフレームワークを提供しますが、一律のアプローチですべてのシナリオに対応できるわけではないことも認識しています。そこで役立つのが拡張機能です。拡張機能を使用することで、デベロッパーはその領域に固有のカスタム機能やメソッドを A2A サーバーに追加することができるので、コアプロトコルを超えた対応が可能になります。さらに、クライアントはリモート エージェントがサポートすべき要件を追加できます。これは、エージェントが特殊な機能を提供する必要がある場合に非常に便利です。
導入は簡単です。今回は、A2A フレームワーク内のメッセージやアーティファクトにタイムスタンプを追加するように設計された「helloworld」拡張機能を紹介します。エージェントは、自身がサポートする拡張機能を「Agent Card」で宣言するだけです。これは機能を概説する JSON ファイルです。誰もが一意の URI によって識別される拡張機能を定義、公開、実装できるため、このエコシステムは非常にオープンかつコミュニティ主導型です。このアプローチにより、A2A プロトコルが高い柔軟性と適応性を維持することが保証され、デベロッパーがはるかに強力で専門的なマルチエージェント システムをビルドできるようになります。
A2A の導入が続くにつれて、拡張機能のユースケースも多様化しています。
多様な AI エージェントを信頼性の高い方法でエラーなく連携させるためには、その通信を評価することが重要です。トレーサビリティ拡張機能は、インタラクションを追跡して問題を効果的に診断するために必要となる詳細な可視性を提供することで、この評価を可能にします。
ResponseTraceこの拡張機能の中核にあるのは、エージェントが実行する一連のアクションを記録する構造化ログである ResponseTrace メッセージです。軽量で、メインの A2A プロトコルに依存しない設計になっており、エージェントが実行したリクエストの記録のみに特化しています。
ResponseTrace は一連の Step で構成されています。各 Step は 1 つの操作を表し、次の 2 つのタイプのいずれかになります。
ToolInvocation: 関数や API などの特定のツールへの呼び出し。
2. AgentInvocation: 別のエージェント（別の A2A エージェントまたは別のタイプのエージェント）への呼び出し。
重要なのは、これらのステップが階層的であることです。あるエージェントが、同様にトレーサビリティをサポートする 2 番目のエージェントを呼び出す場合、2 番目のエージェントのトレースは 1 番目のエージェントの内部にネストされます。これにより、ワークフロー全体をエンドツーエンドで詳細に把握できるようになります。
詳細については、こちらをご覧ください。
Twilio は A2A 向けに、Twilio ConversationRelay 上に構築された音声エージェントのモデル選択を支援するレイテンシ認識型の拡張機能を構築しました。これは、領域固有機能の典型例です。エージェントのレイテンシ情報を公開することは、コアプロトコルの Agent Card の仕様の一部ではありません。しかし Twilio は、最適なエージェントの選択やスムーズな適応を支援するというまさにその目的で拡張機能を構築しました。
詳細については、Twilio のドキュメントをご覧ください。
Identity Machines は、A2A 拡張機能を介してエージェント間通話にゼロトラスト ハンドシェイクを実装しています。Identity Machines はこの実装で、信頼と独立したポリシーゲートに基づいてどのようにエージェントのタスク委任を支えるのかを示しました。このケースでは、エージェントがタスクを受け入れる前に、目的、予算、機能、モデル、PII ステータスなどのカスタムを強制できるようになっています。
詳細については、こちらのドキュメントをご覧ください。
同様に、Ethereum は、AI エージェントのための信頼レイヤーを作成し、組織間の境界を越えて対話できるようにすることを目的とした ERC-8004 を提案しています。この標準では、さまざまなエコシステムのエージェント間でセキュアかつ相互運用可能な通信を行えるように、ID、評価、検証のためのオンチェーン レジストリを導入しています。
