A2Aプロトコル: オープンなエージェント相互運用

1. プロジェクト概要

A2A（Agent2Agent）は、オープンでベンダーに依存しないプロトコルであり、異なるフレームワーク、異なるチームや企業によって構築されたAIエージェントが互いに発見し合い、直接通信できるようにします。これにより、LangGraph、CrewAI、Semantic Kernel、その他のスタックで構築されたエージェントが、他に共通の通信手段を持たないという問題を解決します。

2. 背景と位置づけ

AIエージェントが普及するにつれ、各フレームワークやベンダーは独自の閉じたエージェント間通信手段を構築する傾向があり、サイロ化を生み出しています。あるプラットフォームで構築されたエージェントは、一般的に別のプラットフォームで構築されたエージェントに作業を委任したり、結果を受け取ったりすることができません。A2Aは、エージェントに共有のオープンなコラボレーションプロトコルを提供することで、これらのサイロを打破するために作られました。これにより、エージェントは「エージェントとして」（独自の状態、メモリ、推論を持つ自律的なピアとして）情報を交換し、タスクを調整できるようになり、固定されたAPIを介して呼び出される単純なツールに格下げされることはありません。

プロジェクトの中心的な使命は、ドキュメントに記載されているように、複雑なマルチエージェントコラボレーションを可能にし、エージェントが相互運用する方法に関するオープンな標準を促進することです。エージェントは、内部メモリ、独自ロジック、特定のツール実装を共有する必要なく連携できます。各エージェントは、標準化された「エージェントカード」を通じて選択したものだけを公開し、内部の残りは不透明なままです。

A2Aは、Model Context Protocol（MCP）と意図的に補完関係にあり、競合するものではありません。MCPは、単一のエージェントがツール、データソース、APIに接続する方法を標準化します。A2Aは、独立したエージェントが組織やフレームワークの境界を越えて互いに発見し、通信する方法を標準化します。両方を使用して構築されたシステムは、MCPを使用して個々のエージェントにツールを提供し、A2Aを使用してそのエージェントが他のエージェントと連携できるようにします。

このプロトコルはLinux Foundationプロジェクトとして管理されており、テクニカルステアリングコミッティにはAWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNowからメンバーが参加しており、単一ベンダーの製品ではなく、真に業界横断的な標準となることを意図していることが反映されています。

3. 機能カテゴリ

📜 プロトコル仕様

A2Aのメッセージ形式、トランスポート、動作の正式な定義。リポジトリの/specificationで管理されています。

ワイヤーフォーマットとしてのHTTP(S)上のJSON-RPC 2.0
機能発見のためのエージェントカードスキーマ
タスクのライフサイクルと状態遷移ルール
ストリーミングおよびプッシュ通知のメッセージ形式
新しい機能を時間の経過とともに追加するための段階的な拡張プロモーションプロセス

目的: 実装者に単一のバージョン管理された信頼できる情報源を提供し、独立したA2A実装が相互運用可能であり続けるようにすること。

🧰 言語SDK

開発者がワイヤープロトコルを手作業で実装する必要がないようにするための公式クライアントおよびサーバーライブラリ。

Python SDK（a2a-sdk）
JavaScript/TypeScript SDK（@a2a-js/sdk）
Go SDK（a2a-go）
Java SDK
.NET / C# SDK
Rust SDK

目的: チームがプロトコル処理を手作業で行うことなく、エージェントスタックで既に使用している言語でA2Aを採用できるようにすること。

📚 ドキュメントとガイド

プロジェクトのドキュメントサイトで公開されている概念資料とリファレンス資料。コアコンセプト、タスクライフサイクル、エージェント発見、エンタープライズ機能、ストリーミング、マルチテナンシーをカバーしています。

SDKごとの入門ガイド
コアコンセプト（エージェントカード、タスク、メッセージ、アーティファクト）
エンタープライズ対応ガイダンス（認証、可観測性）
プロトコル拡張メカニズム

目的: プロトコル実装者とアプリケーション開発者の両方がA2Aの概念を理解し、正しく適用できるように支援すること。

🧪 サンプルとリファレンス実装

コンパニオンのa2a-samplesリポジトリで管理されているサンプルエージェントとクライアント/サーバーペア。フレームワーク間の実際の相互運用シナリオを示しています。

目的: 採用者が仕様だけから始めるのではなく、動作する実行可能なリファレンスコードを入手できるようにすること。

4. 主なハイライト

標準化されたエージェント間メッセージング — 通信は、独自プロトコルではなく、広くサポートされ理解されているトランスポートであるHTTP(S)上のJSON-RPC 2.0で実行されます。
発見のためのエージェントカード — 各エージェントは、その機能を説明する機械可読なカードを公開するため、他のエージェント（またはオーケストレーター）は、帯域外の調整なしにエージェントを見つけて正しく呼び出すことができます。
複数の対話モード — 単純な同期リクエスト/レスポンス、長時間実行されるレスポンスのストリーミングのためのServer-Sent Events（SSE）、および単一の接続を超えて存続するタスクのための非同期プッシュ通知をサポートします。
リッチなコンテンツ交換 — メッセージは、チャットスタイルの文字列だけでなく、プレーンテキスト、ファイル、構造化されたJSONペイロードを運ぶことができます。
設計による不透明性 — エージェントは、内部メモリ、ツール、独自ロジックを公開せずにタスクで連携します。これは、関与するエージェントが異なる組織に属している場合に重要です。
多言語、マルチベンダーガバナンス — 公式SDKは6つの言語に及び、プロトコル自体はLinux Foundationの下でクロスカンパニーのテクニカルステアリングコミッティによって運営されており、単一ベンダーロックインのリスクを低減します。

5. 役割別のユースケース

一般開発者: 選択したフレームワークでエージェントを構築し、エージェントカードを介して公開することで、相手ごとにカスタム統合コードを書くことなく、他のエージェントやオーケストレーションレイヤーから発見され、呼び出されるようにします。
プラットフォーム/インテグレーションエンジニア: A2Aを社内エージェントとサードパーティまたはパートナーエージェント間の相互運用レイヤーとして使用し、各側の内部実装をプライベートに保ちながら、サブタスクの委任を可能にします。
マルチエージェントアーキテクチャを評価するプロジェクトマネージャー/テクニカルリード: A2Aのタスクライフサイクルとストリーミングモデルを使用して、チームやベンダー間で長時間実行される多段階のエージェントワークフローを調整および監視する方法を計画します。

6. はじめに

必要なものを見つける — プロトコルドキュメントサイトとリポジトリの仕様ディレクトリから始めて、SDKを選択する前にコアコンセプト（エージェントカード、タスク、メッセージ）を理解します:

https://a2a-protocol.org/latest/

インストール/統合 — スタックに一致するSDKを選択します:

pip install a2a-sdk          # Python
npm install @a2a-js/sdk      # JavaScript / TypeScript
go get github.com/a2aproject/a2a-go   # Go

次に、コンパニオンのサンプルリポジトリで実行可能な例を確認します:

https://github.com/a2aproject/a2a-samples

貢献 — プロジェクトのCONTRIBUTING.mdに従って、問題を報告したり、ディスカッションに参加したり、仕様またはSDKに対してプルリクエストを開いたりします:

https://github.com/a2aproject/A2A/blob/main/CONTRIBUTING.md

7. プロジェクト構造

A2A/
├── specification/        # 正式なA2Aプロトコル仕様（信頼できる情報源）
├── docs/                 # ドキュメントサイトのコンテンツとガイド
├── scripts/              # ユーティリティおよびメンテナンススクリプト
├── CONTRIBUTING.md        # 貢献ガイドライン
├── LICENSE                # Apache-2.0ライセンス
└── README.md

主要ディレクトリ: specification/は、すべてのSDKと実装が従わなければならないバージョン管理されたプロトコルコントラクトを定義します。docs/は、a2a-protocol.orgの公開ドキュメントサイトを支えています。言語SDKとサンプルエージェントは、同じa2aproject GitHub組織の下で、別々のコンパニオンリポジトリ（例: a2a-python、a2a-js、a2a-samples）で管理されています。

8. 関連エコシステム

Model Context Protocol（MCP） — 単一のエージェントをそのツールとデータソースに接続するための補完的な標準。A2AとMCPは、同じシステムで一緒に使用されることが一般的です。
エージェントフレームワーク — LangGraph、CrewAI、Semantic Kernel、および類似のフレームワークは、A2Aが相互運用できるように設計されている種類のシステムです。
Linux Foundation — プロジェクトをホストおよび管理し、複数企業のテクニカルステアリングコミッティを擁しています。
DeepLearning.AI — A2Aプロトコルをカバーする教育コースを公開しています。
a2a-samples — サポートされている言語での実行可能なサンプルエージェントとクライアントのコンパニオンリポジトリ。

9. ライセンス

✅ Apache License 2.0の下で、商用製品を含め、自由に使用、変更、配布できます。
✅ すべてのApache-2.0ライセンスプロジェクトと同様に、特許許諾が含まれています。
✅ GitHub Issues、Discussions、プルリクエストによる貢献を受け付けています。
❌ 保証は提供されません。ソフトウェアは「現状のまま」配布されます。
ℹ️ 再配布または変更されたバージョンは、Apache-2.0で要求されるように、元の著作権、ライセンス、およびNOTICEファイルの帰属表示を保持する必要があります。

10. よくある質問

Q: A2AとMCPの違いは何ですか？
A: MCPは、単一のエージェントが独自のツールとデータソースに接続する方法を標準化します。A2Aは、独立したエージェントが互いに発見し、通信する方法を標準化します。多くのシステムは両方を一緒に使用します。

Q: A2Aを使用するには、すべてのエージェントを同じフレームワークで構築する必要がありますか？
A: いいえ — それがA2Aが解決する中心的な問題です。異なるフレームワーク（LangGraph、CrewAI、Semantic Kernel、カスタムスタックなど）で構築されたエージェントは、それぞれがA2A準拠のエージェントカードとエンドポイントを公開している限り、相互運用できます。

Q: A2Aはどのトランスポートを使用しますか？
A: HTTP(S)上のJSON-RPC 2.0で、ストリーミング用のServer-Sent Events（SSE）と、長時間実行されるタスク用の非同期プッシュ通知をサポートしています。

Q: 公式SDKがある言語はどれですか？
A: Python、JavaScript/TypeScript、Go、Java、.NET/C#、Rustです。

Q: A2Aを自分のエージェントに統合する前に、動作する例はどこで確認できますか？
A: a2a-samplesリポジトリ（https://github.com/a2aproject/a2a-samples）には、実行可能なリファレンスエージェントとクライアントが含まれています。

11. クイックリンク

リポジトリ: https://github.com/a2aproject/A2A
公式ドキュメント: https://a2a-protocol.org/latest/
貢献ガイド: https://github.com/a2aproject/A2A/blob/main/CONTRIBUTING.md
サンプルリポジトリ: https://github.com/a2aproject/a2a-samples

12. まとめ

A2Aは、AIエージェントに、フレームワーク、ベンダー、組織を越えて互いに発見し、連携するための共通のオープンな言語を提供し、フレームワーク固有のツールだけでは解決できないギャップを埋めます。これは、自分たちが制御できないエージェントと相互運用する必要があるマルチエージェントシステムを構築するチーム、つまり社内プラットフォームチーム、インテグレーションエンジニア、および複数のベンダーやスタックにまたがるエージェントアーキテクチャを設計するすべての人に最適です。