A2A導入前に確認したい7項目とSDK検証結果
- •A2Aが2026年8月17日にエージェンティックAI財団のホステッドプロジェクトに移行
- •公式SDKの12項目検証で仕様どおり動作したのは5項目、認証も標準では未確認
- •導入前に認証、バージョンヘッダー、キャンセル時のエラー、プッシュ通知、保存先など7項目を点検
A2A（エージェント間で作業を依頼し、進捗を確認するプロトコル）は2026年8月17日、エージェンティックAI財団（AAIF）のホステッドプロジェクトになりました。先行する実験では、公式SDKで構築したサーバーを12項目で検証し、MCPおよび純粋なHTTPと比較しました。A2Aは作業の進捗確認とキャンセルの規約を提供しますが、応答データ量と遅延が増え、12項目のうち仕様どおり動作したのは5項目でした。SDKの標準設定では、エージェントカードに宣言された認証を確認しませんでした。
A2Aの管理権について、Googleは公開から2か月後の2025年6月にLinux Foundationへ移管すると発表し、2026年8月に財団傘下のAAIFが引き継ぎました。執筆時点で財団はA2AをGrowth段階に分類しており、その上にImpact段階があります。財団の発表によると、A2Aはサプライチェーン、金融、モバイルプラットフォームの運用環境で利用され、参加組織は150を超えています。中立的な財団に管理主体が移ることで、1社の戦略変更によって仕様の維持や改定が止まるリスクを減らせると筆者は説明しています。リポジトリのアドレスもgoogle/A2Aからa2aproject/A2Aに変わりました。
AAIFは2025年12月に設立され、A2Aの参加翌日にはAgent Routerも承認されました。執筆時点で財団は6つのプロジェクトを管理していました。ツール呼び出しの規約、プロジェクトのルールファイル、インフラ、エージェントツールを持つ財団に、エージェント間の作業引き継ぎ規約が加わりました。筆者は、複数組織が従う規格文書は標準になり得る一方、それを使う製品が標準の実利用を示すと区別しています。Claude Code v2.1.277以降は、CLAUDE.mdがない場合にAGENTS.mdを読み、設定すれば両方を読み込みます。ただし財団のガバナンスや中立性は、個々のSDKが仕様に従うことを保証しません。
A2Aは相手のエージェントを見つけて作業を依頼し、進捗確認やキャンセルを行う規約です。認証確認、リクエストの中継と記録、作業を担うエージェントのツール呼び出しは、別のプロジェクトが補います。A2Aで依頼を受けたエージェントはMCPでツールを呼び出せますが、依頼側には内部で使ったツールが見えません。KubernetesのサービスにappProtocol: agentgateway.dev/a2aを指定すると、agentgatewayがA2A通信を処理し、エージェントカードのアドレスをゲートウェイのアドレスに置き換えます。また、呼び出しメソッド、結果、JSON-RPCエラーコードをアクセスログに記録します。未対応のメソッドでも、HTTP 200の応答内にJSON-RPCエラーが含まれる場合があるため、ステータスコードだけを見る監視では成功と数えられる一方、ゲートウェイのログにはエラーが残ります。
2つのバージョンを提供するサーバーは、カードにv0.3とv1.0の両方のアドレスを記載できます。しかしagentgatewayはv1.0のアドレスだけをゲートウェイのアドレスに置き換え、v0.3のアドレスはバックエンドのままにします。そのため、v0.3クライアントがゲートウェイを迂回し、バックエンドへ直接リクエストする事例が確認されました。また、agentgateway v1.5.0にはA2Aリクエストの認可機能がありません。認証は呼び出し元の身元を確認し、認可は特定のメソッドやスキルを使う権限があるかを判断します。MCPにはツール名や引数にルールを適用する仕組みがありますが、A2Aにはまだなく、現状は観測にとどまります。認証と認可はアプリや別のレイヤーで担う必要があります。
エージェントの事例であるGooseは2025年12月、MCP、AGENTS.mdとともにAAIFの創設時寄贈プロジェクト3件の一つになりました。2026年4月7日にはBlockの組織からaaif-goose/gooseへリポジトリを移しました。執筆時点でスターは54,500を超え、最新バージョンは2026年9月17日公開のv1.51.0でした。MCPで接続する拡張機能は70種類を超え、コンテキストファイルとしてAGENTS.mdを優先して読み込みます。筆者は、Gooseのようなエージェントがカードから別組織のエージェントを見つけて作業を依頼する機能を標準搭載すれば、A2Aが実務の規約として使われると説明しています。当時、そのようなツールはまだ見当たりませんでした。
導入前の点検事項は7つです。1つ目は認証で、エージェントカードに方式が記載されていてもSDKの標準設定は確認しないため、アプリや前段で認証を設定する必要があります。2つ目は拡張エージェントカードです。仕様上は認証済みリクエストにのみ提供されますが、SDKの標準設定は身元を確認しないため、アドレスを知る人なら誰でも取得でき、公開可能な情報だけを載せる必要があります。3つ目はA2A-Versionヘッダーで、省略するとエラーなしにv0.3として処理されます。4つ目はカードに記載されたインターフェース一覧で、記載をそのまま信じず実際に呼び出して確認します。5つ目は完了済み作業のキャンセルです。仕様上のコード-32002ではなく、サーバー内部エラーコード-32603が返ることがあり、サーバー障害と誤認して再試行しないよう個別に処理します。6つ目はプッシュ通知で、設定の保存と送信機能を直接つなぐ必要があり、送信失敗はサーバーログにしか残らないためログも確認します。7つ目はタスク保存先で、標準ではPodのメモリが使われ、再起動で状態が失われるため、永続ストレージに変更します。
今後確認する指標は3つです。公式SDKが認証確認とプッシュ送信を標準提供するか、ゲートウェイがA2Aでも呼び出し元ごとの権限を確認するか、A2AがAAIFのGrowth段階からImpact段階へ上がるかです。AAIFは2026年9月1日、新しいプロジェクト向けにSandbox段階を設け、各段階の基準を整理しました。筆者はImpactへの昇格が、採用、コミュニティ、財団の関与の増加を意味すると説明しています。
A2Aは作業の進捗確認や処理中のキャンセルが必要な場合に役立ち、相手のエージェントが変わっても同じクライアントを使えます。時間がかからず、途中経過の確認や管理も不要な呼び出しにはMCPで十分だと筆者は説明しています。MCPは先の7月の改定で、リクエストをそれぞれ独立して処理する構造になりました。一方、作業中に追加質問をしたり、依頼を拒否したりできるエージェントとの通信では、A2A規約に意味があります。ただしA2Aは応答データ量が増え、呼び出しごとに1.2〜2.1ms余計にかかりました。12項目の検証で仕様どおり動作したのは5項目です。2026年9月時点で仕様はv1.0に固定されましたが、仕様への準拠を強制する機能は利用者側で整える必要があると筆者は指摘しています。9月更新のロードマップにはv1.1の準備が記され、タスクのタイムライン改善と双方向ストリーミングが含まれています。そのため、今回の検証内容も今後再確認する必要があるとしています。測定スクリプト、マニフェスト、判定表、ゲートウェイの測定結果は公開リポジトリにまとめられています。筆者はAAIFアンバサダーであり、A2Aとagentgatewayが財団プロジェクトであることを明らかにしたうえで、仕様に合わない点も自ら確認したと説明しています。