A2Aとは？MCPとの違い・v1.0の変更点と導入の判断基準

A2Aとは、独立して運用される別のエージェントに仕事を委任するためのプロトコルです。ツールやデータにアクセスしたい場合は、Model Context Protocol（MCP）を使います。A2A v1.0ではシステム間の連携仕様が変わるため、導入時には、どの境界を越えて連携するのかと、接続先がどのバージョンに対応しているのかを併せて判断する必要があります。

MCPとA2Aの違い：ツールへのアクセスと仕事の委任

MCPはエージェントが外部の機能を利用するための仕組みです。A2Aでは、別のエージェントに仕事の一部を任せ、その遂行を引き受けてもらいます。 同じシステムで両方を使うこともできます。

Model Context Protocol（MCP）は、AIアプリケーションがツールやデータソースなどの外部システムに接続する方法を標準化します。Agent2Agent（A2A）が標準化するのは、独立したエージェント同士の通信です。公式ドキュメントでも、両者は補完関係にあると説明されています。MCPの概要、A2AとMCPの関係。

MCPの利用例：注文情報を照会する

配送に関する問い合わせに答えるカスタマーサポート用エージェントを考えてみます。MCPサーバーが注文照会ツールを公開し、エージェントは注文IDを渡して注文データを受け取り、顧客への回答を作成します。

業務上の利点は、注文管理システムへの接続を再利用できることです。レコードを取得するだけなら、別のエージェントを導入する必要はありません。ツールへの接続という観点での選び方は、MCPサーバーガイドで解説しています。

A2Aの利用例：サプライヤーの候補選定を任せる

条件に合うサプライヤーの候補リストが必要な購買アシスタントを考えてみます。調査のワークフローは、別のベンダーが運用する調達エージェントが担当します。購買アシスタントは要件を伝え、配送条件についての確認に答え、構造化された候補リストを受け取ります。

購買アシスタントは、調達エージェントの検索方法や使用モデル、内部の処理手順を知る必要はありません。必要なのは、双方で合意した依頼内容と、役に立つ結果です。A2Aは、こうした役割の境界をまたぐ連携を支えるために設計されています。

調達エージェントは、内部でMCPを使ってカタログデータを取得しても構いません。この構成では、A2Aが仕事の委任を担い、MCPがデータへのアクセスを担います。

違いを判断する軸は、必要なインターフェースです。MCPツールの背後にも、高度な処理ロジックを実装できます。内部処理がどれほど賢そうかで選ぶのではなく、相手のシステムを、スキルを発見でき、仕事の進行を追跡できるエージェントとして公開したい場合にA2Aを選びます。

A2Aとは？独立したエージェントをつなぐ共通の通信仕様

A2Aは、異なるベンダーやフレームワークで構築されたエージェントがやり取りするための共通の通信仕様です。 呼び出し側は、相手の内部メモリやツール、意思決定ロジックにアクセスしなくても、そのエージェントとやり取りできます。公式サイトでは、こうした内部構造を外から見えないものとして説明しています。A2Aの概要。

呼び出し側がA2Aクライアント、依頼を受け付ける側がA2Aサーバーです。後者はリモートエージェントとも呼ばれます。専門機能の外部調達を考える創業者にとっては、専門エージェントの実装を自分たちで再現せず、サービス間の接点に絞って連携を設計できるという意味があります。

A2Aを開発したのは誰で、現在は誰が管理していますか？

公式サイトには、「A2Aは当初Googleが開発し、Linux Foundationに寄贈されました」と明記されています。また、プロジェクトはTechnical Steering Committeeが維持管理すると説明されています。つまり、当初の開発元だけにとどまらないガバナンス体制があります。ガバナンスとオープンソース。

仕様やSDKへのリンク、サンプルを探す際の入口は、a2aproject/A2Aリポジトリです。A2A自体はプロトコルなので、エージェントの構築と運用に使うソフトウェアは別途選ぶ必要があります。

A2Aの仕様を読むために押さえたい用語

まず区別したいのは、会話、進捗を追跡する仕事、その成果物です。 この違いを整理すると、プロトコルに沿った設計がしやすくなります。

Agent Card：エージェントの提供機能を知るための情報

Agent Cardは、エージェントの識別情報、スキル、機能、接続情報、認証要件を記述したJSON形式のメタデータ文書です。クライアントはこれを基に、そのエージェントに接続するか、どのように接続するかを判断できます。基本概念。

調達の例なら、カードにはサプライヤーの調査スキルが記載されているかもしれません。ただし、カードは連携の出発点であり、出来上がる候補リストが自社の購買基準を満たす証明ではありません。

ドキュメントで定められたwell-knownの探索パスは、/.well-known/agent-card.jsonです。カードは、直接設定した接続情報や、登録内容が管理されたレジストリから取得することもできます。A2Aは、こうしたレジストリ向けの標準APIを規定していません。エージェントの探索。

Task、Message、Part、Artifactの違い

**タスク（Task）**は、識別子とライフサイクルを持ち、状態を管理する仕事の単位です。**メッセージ（Message）**は、やり取りの中の一回の発言に当たります。Partには、実際のテキスト、ファイルの内容や参照、構造化データを格納します。**アーティファクト（Artifact）**は、タスクの実行中に生成される具体的な成果物です。基本概念。

サプライヤーの例では、「配送先はどの地域ですか？」という確認が会話です。進捗を追跡する調達業務がタスクで、完成した候補リストがアーティファクトです。購買ワークフローでは、会話履歴から完成品らしいものを探すのではなく、候補リストを成果物として受け取って処理する設計にします。

エージェントは、単独で完結するメッセージを返すことも、タスクを作成することもできます。関連するやり取りはcontextIdでまとめられます。タスクが終端状態に達した後で修正を依頼する場合は、以前のタスクを再開するのではなく、新しいタスクを開始します。タスクのライフサイクル。

この区別は、納品後に購買側が要件を変更したときに重要になります。元の候補リストを識別できる状態で残し、その改訂を新しい仕事として扱えば、後続の利用者はどの結果を承認したのか確認できます。

トランスポート：共通の仕様をどの方式で通信するか

トランスポート、またはプロトコルバインディングは、接続上で各操作をどのように伝送するかを定めます。仕様では、JSON-RPC、gRPC、HTTP+JSON/RESTのバインディングが定義されています。Agent Cardのインターフェース情報には、エンドポイント、バインディング、プロトコルのバージョンが記載されます。A2A仕様。

ポーリング、ストリーミング、プッシュ通知は、タスクの更新情報をどう受け取るかという選択です。バインディングとは別に考えます。購買ダッシュボードならポーリングで十分かもしれませんが、対話的な体験では逐次更新が重要になることもあります。画面や操作を設計する前に、実際のエンドポイントが対応している機能を確認してください。

A2A v1.0では何が変わりましたか？

既存の連携には互換性の確認が必要です。バージョン文字列を書き換えるだけでは足りません。 以下は、公式の更新内容ページが示す、v0.3.0からv1.0への変更点です。

• 共通の定義： a2a.protoがプロトコルの正本となり、各プロトコルバインディングの正式な仕様が定められます。
• 通信データ形式の変更： 個別のコンテンツ型が統一されたPartに置き換わります。kindによる型の識別はメンバー名による識別に変わり、列挙値にはSCREAMING_SNAKE_CASEを使います。
• Agent Cardの再構成： 接続情報をsupportedInterfacesにまとめ、プロトコルのバージョンはインターフェースごとに宣言します。
• 操作の更新： message/sendはSendMessageに変わります。ListTasksにより、フィルタリングとカーソルベースのページネーションに対応した一覧取得が加わります。
• エンタープライズ向けの変更： テナント用フィールド、Agent Cardの署名検証ルール、OAuthフローの更新が、連携の設計に影響します。

これらの変更点は、2026年10月12日にプロジェクトのv1.0の更新内容ページで確認しました。

既存のコネクターでは、シリアライズされたリクエスト、レスポンスの解析、カードの探索、使用する操作をまとめて見直してください。接続に成功しただけでは、すべてのやり取りが引き続き正しく動くとは確認できません。

A2Aに対応するフレームワークとプラットフォームは？

対応を明記した実装はありますが、対応バージョンや機能の範囲はそれぞれ異なります。 自分たちのワークフローに必要な動作を基準に選んでください。以下の対応状況と制約は、2026年10月12日に各提供元の公開ドキュメントで確認したものです。製品にログインしての動作検証は行っていません。

Google Agent Development Kit

エージェント開発用フレームワークのGoogle Agent Development Kit（ADK）は、エージェントを公開し、Agent Cardを生成するためのto_a2aをドキュメントで説明しています。PythonのA2A連携機能は**実験的機能（Experimental）**という位置付けです。ドキュメントではa2a-sdkの0.3.xと1.x.xに対応し、新規の連携には1.x.xを案内しています。ADKでエージェントを公開する方法。

ADKには、リモートエージェントを利用するためのRemoteA2aAgentも記載されています。ADKで開発する場合、仕事を依頼する側と受ける側の両方に、文書化された連携手段があるということです。ラッパーが便利でも、デプロイの判断には実験的機能である点を織り込む必要があります。ADKでリモートエージェントを利用する方法。

LangSmith Agent Serverを介したLangGraphの連携

LangGraphのデプロイ向けサービング基盤として説明されているLangSmith Agent Serverは、/a2a/{assistant_id}でA2Aエンドポイントを公開します。ドキュメントでは、v1.0のJSON-RPCバインディングを使用し、v0.3のメソッド名も受け付けると明記されています。グラフの状態にはmessagesフィールドが必要です。LangSmithのA2Aドキュメント。

同じページには制約も記載されています。gRPCとHTTP+JSONは実装されておらず、SubscribeToTaskとプッシュ通知の設定も未対応です。メッセージのストリーミングには対応していますが、すべての購読操作や通知操作が使えるわけではありません。バックグラウンドジョブの設計を決める前に、必要な操作への対応状況を調べるべき具体的な理由です。

CrewAIとCrewAI AMP

エージェントを連携させるフレームワークのCrewAIでは、リモートへの委任にA2AClientConfig、エージェントの公開にA2AServerConfigを使う方法が記載されています。同じエージェントに両方の役割を設定することもできます。CrewAIのエージェント委任ドキュメント。

デプロイ用プラットフォームのCrewAI AMPでは、A2Aサーバーエージェントを早期リリース（early release）と位置付け、対応プロトコルのバージョンを0.2と0.3としています。また、オープンソース実装のインメモリ状態管理に代わり、永続的な分散ストレージを使うと説明しています。CrewAIにA2A対応機能があるからといって、AMPのエンドポイントもv1.0に対応すると考えてはいけません。AMPでのA2A利用。

Microsoft Foundry Agent Service

マネージド型のエージェントプラットフォームであるMicrosoft Foundry Agent Serviceは、プロトコル1.0に対応するa2aツール型を一般提供機能として説明しています。従来のa2a_previewツール型は0.3に対応し、現在もプレビュー段階です。Microsoftは、新規の連携には一般提供のツール型を推奨しています。FoundryのA2Aドキュメント。

同じページには、接続先となるFoundryエージェントはテキストのみに対応し、ストリーミングレスポンスには対応していないと記載されています。マルチメディアの成果物をストリーミングで受け取る必要があるワークフローでは、この制約を考慮しなければなりません。プロトコル上で扱えるコンテンツ型が、そのまますべてのホスティング基盤で実装されているとは限りません。

フレームワークを広く比較して選ぶ際は、AIエージェントフレームワーク比較を参照してください。ここで扱う連携上の確認点は、「エージェントを提供するシステムが、どのA2Aインターフェースをドキュメントで示しているか」という、より絞った問いに答えるものです。

開発者・運用担当者・導入側にとって何が変わるのか

追加するサービスを運用する価値があるなら、連携の接点を再利用しやすくなることが利点です。 具体的な意味は、誰が判断するかによって変わります。

開発者： 通信方式を追加する前に、何を委任するかを決めます。「出典と選定理由を添えた候補リストを作る」はサービスの役割を定める依頼です。「このデータベースを検索する」はツールの役割です。どちらも最終的にモデルを呼び出すとしても、この区別を保ってください。

運用担当者： 引き渡した後のタスクに責任を持つ担当者を決めます。購買の例なら、調達側が追加情報を求めた場合、応答しなくなった場合、受け入れ基準を満たさない候補リストを返した場合にどうするか、誰かが判断しなければなりません。メッセージ形式を共通化しても、こうした責任分担は決まりません。

導入担当者・創業者： 対応プロトコルのバージョン、バインディング、操作、コンテンツ型、デプロイ機能の提供段階を確認してください。それぞれを自社のワークフロー要件と照らし合わせます。詳細のない「互換性あり」という説明だけでは、連携を決定する根拠として不十分です。

A2A導入の予算はどう考えればよいですか？

A2Aには、月額費用を一律に算出できる単一のデプロイ構成はありません。外部でホスティングされた専門エージェントを使う場合と、自社でサービスを運用する場合では、費用を左右する項目が異なります。プロトコルのドキュメントにも、共通のプラットフォーム料金は定められていません。

計画時には、同じ予算期間にそろえて次の式で考えます。

連携による純便益＝削減できるコネクター費用－移行費用－追加のインフラ費用－継続的な運用費用。

モデルの利用、ホスティング、タスクの保存、監視、障害対応の責任を担うための費用も、運用費用に含めます。各項目には、自社の実際のコストを当てはめてください。維持管理すべき接点が新たに増えても、それを上回るだけの繰り返しの連携作業を減らせるなら、A2Aを導入する価値があります。

A2Aに期待しすぎてはいけないことは？

共通のプロトコルがあっても、よく知らないエージェントが信頼できるようになったり、分散した仕事の信頼性が自動的に確保されたりするわけではありません。 標準化には価値がありますが、アプリケーション側で判断すべきことは残ります。

Agent Cardが示すのは、そのサービスが何を提供するかです。運用主体を信頼するか、出力を受け入れるかは、利用側が判断します。A2Aのエンタープライズ向けガイダンスでは、背後で実行される操作の権限も含め、認証・認可の適用は実装側の責任とされています。エンタープライズ向け実装ガイダンス。

調達ワークフローでは、調査を許可する際に、購買権限まで暗黙に与えないようにします。候補を推薦する権限と、実際に発注する権限は、アプリケーションで分けるべきです。

返されたアーティファクト、タスクの状態、自社での受け入れ記録は、それぞれ別の管理対象として扱ってください。委任したワークフローから発注書を作成できるようにする前に、業務操作の重複をアプリケーションでどう検出し、結果が確定できない状態からどう復旧するかを決める必要があります。

内部のサブエージェント呼び出しすべてにA2Aを追加するのも、適用範囲を広げすぎです。プロジェクト自体が、エージェント内部のサブエージェント呼び出しやツール呼び出しの規定を、明示的に対象外としています。構成要素が同じアプリケーション内の仕様に従うなら、フレームワークに備わった組み合わせの仕組みで、すでに目的を果たせるかもしれません。A2Aの対象範囲。

A2AとMCP、どちらが必要ですか？両方使うべきですか？

まずは、現在のプロダクトに実在する連携の境界から考えます。

エージェントが再利用可能なツールインターフェースを通じて、業務システム、ファイル、APIにアクセスする必要があるなら、MCPを選びます。自分で機能を公開する場合は、PythonでMCPサーバーを構築するガイドを参照してください。接続先をまたぐアクセス管理が課題になったら、MCPゲートウェイの解説でその層を扱っています。

独立して運用される別のエージェントが、意味のある仕事を一まとまりで担い、そのインターフェースの探索、指示のやり取り、仕事の進行確認に共通の仕組みが必要なら、A2Aを選びます。その連携要件がすでに存在し、接続する両側のドキュメントで互換性のある機能を確認できるなら、導入に進む段階です。

自分のエージェントが専門エージェントに仕事を任せ、その専門エージェントにもツールやデータが必要なら、両方を選びます。調達の例がこれに当たります。調査業務の委任にはA2Aを使い、エージェント内部のカタログ参照にはMCPを使います。

外部の専門エージェントの利用がまだ構想にすぎないなら、A2Aの導入は待って構いません。 現在のツールで十分に機能するエージェントは、新しいエージェント間プロトコルが登場しただけで変更を迫られるものではありません。また、内部の関数呼び出しすべてに、いずれかの標準が必要なわけでもありません。実際の連携課題を解決する接続仕様を採用してください。

次に実装する前に決めておくこと

周辺の技術スタックを移行する前に、範囲を絞った業務成果について、引き渡しの取り決めを書き出してください。 購買アシスタントなら、まずサプライヤーの候補リストを対象とし、発注の実行は初期スコープから外します。

1. 1

   受け入れられる成果物を定義する

   候補リストに必須の情報、受け入れられない条件、承認した結果を記録するアプリケーションを定めます。リモートエージェントの責任範囲を明確に区切ってください。

2. 2

   公開されたインターフェースを照合する

   クライアントとサーバーのプロトコルバージョン、バインディング、認証要件、必要な操作を記録します。ワークフローにストリーミングやプッシュ配信が必要か、接続する両側が対応しているかも確認してください。

3. 3

   仕事が完了しない場合の扱いを設計する

   確認の問い合わせ、タイムアウト、拒否、再試行後も結果が確定できない応答を誰が扱うか決めます。処理待ちの間にユーザーへ何を表示するか、改訂版の成果物で以前の成果物をどう置き換えるかも定義してください。

この取り決めが、A2Aを追加する具体的な判断材料になります。書き出してみて、専門エージェントと考えていた相手の仕事がレコードの取得だけだと分かったなら、先にツールとの接続を実装してください。

A2A導入前によくある質問

MCPを使わずにA2Aだけを利用できますか？

はい。A2Aは、リモートエージェントが自身のツールやデータにアクセスする方法を規定していません。ツールとの接続も標準化したい場合に、MCPが役立ちます。A2AとMCPの組み合わせ。

両方のエージェントで同じフレームワークを使う必要がありますか？

いいえ。異なるフレームワーク間での相互運用は、A2Aの主要な目的です。そろえる必要があるのは、公開するインターフェースと、そのやり取りに必要な機能です。エージェントの内部実装をそろえる必要はありません。A2Aの概要。

実用的なエージェントシステムを構築するためのガイドは、ニュースレターに登録してお受け取りください。