公開日:
公式ドキュメント・公式発表などの一次情報を確認したうえで、株式会社Nexaが執筆・更新しています。AIツールの仕様や料金は変わることがあるため、導入判断の前に各公式サイトの最新情報もご確認ください。運営会社について
A2A プロトコルは独立したAIエージェントをつなぐ規格で、企業は必要性・互換性・責任分界の3要素を確認してから導入を判断します。
- 役割: MCPがツールやデータへの接続を担うのに対し、A2Aは独立したエージェント同士の連携を担います。
- 仕組み: Agent Cardで能力を確認し、Messageで依頼します。状態の追跡にはTaskを使います。
- 導入判断: 対応バージョンと機能を合わせ、誰の権限で何を実行するかを業務側でも定めます。
対象読者：DX推進担当者。
今日やること: 別システムへ引き継いでいる業務を1つ選び、渡す情報と責任者を書き出す
A2Aプロトコルは、異なる仕組みで動くAIエージェント同士が、依頼や進捗、成果物をやり取りするための共通ルールです。ただし、A2Aに対応するだけで業務が自動化されるわけではありません。相手に任せる仕事と、実行を許す範囲を決める必要があります。
MCPとの使い分けから通信の仕組み、企業向けの導入手順までを整理します。細かな実装コードではなく、自社に必要かを判断するための解説です。
確認日: 2026年10月11日に公式ページで確認。 A2A公式ドキュメントの1.0系仕様を参照しています。仕様やSDKは更新されるため、実装時には接続する双方の対応版を確認してください。
A2Aプロトコルとは何か
A2Aは、独立したAIエージェント間の通信方法を共通化するオープンな規格です。 正式名称はAgent2Agentです。AIエージェントとは、与えられた目的に応じて処理を選び、必要なツールを使って仕事を進めるシステムを指します。
A2Aでは、相手の内部メモリや独自ロジックを共有せずに連携できます。たとえば受付側が「この問い合わせを調べて」と専門エージェントに任せ、結果を受け取る構成です。どのAIモデルを使い、内部でどう処理するかまで統一するものではありません。
公式の概要は、A2Aをエージェント開発キットと区別しています。Googleで開発され、Linux Foundationへ寄贈された規格ですが、特定の開発フレームワークを必須としません。「AIを作る仕組み」と「AI同士をつなぐ規格」を分けて捉えてください。
A2AとMCPの違いを早見表で比較
A2Aは独立したエージェントとの連携、MCPはツールやデータとの接続を主に扱います。 MCPはModel Context Protocolの略です。AIアプリが外部システムを共通の方法で利用するための標準であり、A2Aの旧版や代替品ではありません。
| 比較項目 | A2A | MCP |
|---|---|---|
| 主な接続相手 | 独立したAIエージェント | 外部ツール、データ、システム |
| 依頼のイメージ | 問い合わせの調査を担当してもらう | 必要な情報を検索する機能を呼ぶ |
| 着目する内容 | 能力の発見、依頼、仕事の状態、成果 | 利用可能な外部機能とその呼び出し |
| 企業での判断 | 別の担当システムに仕事を任せたいか | 自分のAIに外部機能を持たせたいか |
| 関係 | MCPを内部で使う相手とも連携できる | A2A連携する各エージェント内部でも使える |
この整理はA2A公式の比較とMCP公式の定義に基づきます。「MCPは単純、A2Aは高度」と優劣をつける比較ではありません。
想定例として、受付エージェントから在庫確認担当へA2Aで依頼し、その担当がMCP経由で在庫データを取得する構成が考えられます。MCPの併用は必須ではなく、接続先の実装によって変わります。基本構成を補足したい場合は、MCPの仕組みと始め方も参考にしてください。
図1: A2AとMCPは異なる接続を担い、必要に応じて併用します。
A2Aが必要な企業と不要な企業
A2Aを検討する目安は、別々に運用するエージェントへ仕事を任せる必要があることです。単に複数のAI処理を順番に動かすだけなら、既存のアプリやワークフローで足りる場合があります。
次の表は、規格の役割を踏まえた本記事の判断基準です。
| 自社の状態 | 最初に検討する方法 |
|---|---|
| AIから社内データを検索したい | MCPや既存APIによる接続 |
| 同じアプリ内で処理を分担したい | 開発フレームワーク内の連携 |
| 別部門や外部提供のエージェントへ仕事を引き継ぎたい | A2Aによる接続 |
| 何を自動化するか決まっていない | 業務の棚卸しと責任範囲の整理 |
採用を急ぐ必要はありません。引き継ぎ先が存在しない段階で通信基盤だけを作ると、検証する業務上の利点も曖昧になります。まず「誰が、どの仕事を、どの相手に任せるか」を書き出します。
AI導入に関するお困りごとは、株式会社NexaのAI顧問がサポートします。「何から始めればいいか分からない」という段階からご相談いただけます。
最新バージョンと旧仕様の見分け方
確認時点の公式GitHubの最新リリースはv1.0.1です。一方、通信で使う版はメジャーとマイナーの組み合わせで示します。仕様のバージョン規則に従うと、1.0系では「1.0」として互換性を確認します。
旧v0.3.0の説明やコードを、現行仕様へそのまま流用してはいけません。v1.0の変更点には、次の違いがあります。
| 確認箇所 | 旧v0.3.0 | 現行1.0系 |
|---|---|---|
| JSON-RPCのメッセージ送信名 | message/send |
SendMessage |
| Agent Cardの接続情報 | トップレベルのURL等に分散 | supportedInterfacesに集約 |
| Taskの状態表現の例 | working |
TASK_STATE_WORKING |
| Partの内容識別 | kindフィールドを使用 |
内容を表すフィールドで識別 |
これは移行時の確認表であり、置換だけで動作するコード例ではありません。導入資料には、仕様の版とSDKの版を別々に記録しましょう。
クライアントとサーバーは何を担当するか
A2Aのクライアントは依頼を送る側、サーバーは依頼を受けるエージェント側です。公式の基本概念では、クライアントは別のエージェントだけでなく、アプリやサービスでも構いません。
たとえば社内ポータルが依頼を送り、調査用エージェントが処理を引き受ける構成です。ここでいうサーバーは役割を示す言葉であり、特定のクラウド製品名ではありません。
設計時は、依頼内容を組み立てる責任と、実行可否を判断する責任を分けます。依頼側が「実行してよい」と書いても、受ける側の権限確認を省略しない構成が必要です。同じ会社のシステム同士でも、この境界は残してください。
Agent Cardで接続相手の能力を確かめる
Agent Cardは、エージェントの能力と接続条件を記す機械可読な文書です。 JSONというデータ形式で表され、名前、説明、得意な仕事、対応機能、接続先、セキュリティ要件などを確認できます。現行のAgentCard定義で各項目が定められています。
現行仕様の接続情報は、supportedInterfacesの各要素にあるurl、protocolBinding、protocolVersionで確認します。接続先だけでなく、通信方式と仕様の版を合わせるためです。
公式の発見方法には、共通パス/.well-known/agent-card.json、管理されたカタログ、直接設定があります。社内用カードを一般公開する必要はありません。説明に機密情報を含めず、カードに能力が書かれていることと実行を許可することも区別します。
＼ AI活用の「次の一手」を一緒に考えませんか ／
AI顧問の無料相談はこちらTaskは仕事の状態を管理する単位
Taskは、進捗や追加対応を追跡するための、状態を持つ仕事の単位です。 識別子を使って同じ仕事を参照し、受付、処理中、追加入力待ち、完了や失敗などを区別します。現行の正確な名称はTaskStateの定義で確認できます。
追加入力が必要な状態は失敗と同じではありません。依頼の条件が足りなければ、相手の入力を待ってから処理を続ける設計ができます。一方、完了や失敗などの終端状態になったTaskは再開しません。修正依頼は新しい仕事として扱います。
ただし、システム上の完了と業務上の合格は別です。「処理は終了したが、回答に必要な根拠が欠けている」という結果も検収で見つける必要があります。状態の管理だけで品質確認を代替しないでください。
MessageとPartは依頼や追加情報を運ぶ
Messageは依頼や質問、回答などの一度のやり取りを表し、Partはその中身を表します。Partは文章だけでなく、ファイルへの参照、バイナリデータ、構造化データを扱えます。現行1.0系では、text、raw、url、dataのうち内容に合うフィールドを使います。
たとえば「対象期間を教えてください」という質問と、期間を返す回答はMessageで表現できます。ファイルを添える場合は、その内容や参照先をPartで渡す形です。基本概念のMessageとPartの説明を参照してください。
すべての依頼でTaskを作る必要はありません。 即座に完結する回答なら、Messageだけを返せます。会話の内容を運ぶ役割と、仕事の状態を追う役割を分けると、過剰な状態管理を避けられます。
Artifactは作業の成果物を受け渡す
Artifactは、エージェントが作った文書や構造化データなどの成果物です。Messageが会話や依頼を担うのに対し、Artifactは納品する結果を表します。内容はPartで構成されます。公式のArtifact解説でも、この区別が示されています。
たとえば「調査を続けています」は進捗の連絡で、「調査結果をまとめた一覧」は成果物です。業務システムへ渡すなら、何が返れば受け入れるかを事前に決めます。
文書なら必須項目と根拠、集計データなら対象期間や単位、ファイルなら形式と保存先が確認項目です。A2Aは受け渡しを共通化しますが、社内で使える品質かどうかの基準までは決めません。
A2Aのやり取りは5ステップで理解する
Taskを使う連携は、相手の確認から成果物の検収までの5ステップに分けると整理できます。以下は公式仕様の共通ワークフローを基に、業務向けにまとめた概念的な流れです。
- 相手を見つける: Agent Cardを読み、依頼したい仕事に対応しているか確かめます。
- 接続条件を合わせる: 仕様の版、通信方式、必要な認証と権限を確認します。
- 仕事を依頼する: Messageで目的、入力、完成条件を伝えます。
- 進捗と追加情報を交換する: Taskの状態を追い、不足情報や承認が必要なら対応します。
- 成果物を受け取り検収する: Artifactと終了状態を確認し、業務側で合否を判断します。
単純な質問なら、TaskやArtifactを伴わずMessageで返る場合もあります。常に同じ順序の通信が必須という意味ではありません。実務では各段階について、失敗したときに誰へ戻すかも決めておきます。
図2: 通信上の処理完了とは別に、業務側の検収を設けます。
長時間処理はポーリングと通知を使い分ける
長時間の仕事では、結果の受け取り方を利用環境に合わせます。A2Aには定期的な状態取得や、ストリーミング、プッシュ通知を使う方法があります。ただし、接続相手が必要な機能に対応していることが前提です。
| 方式 | 受け取り方 | 検討する場面 |
|---|---|---|
| ポーリング | 一定間隔で状態を問い合わせる | 即時の進捗表示が不要な処理 |
| SSEによるストリーミング | HTTP接続を保って更新を受け取る | 画面に進捗や部分結果を表示する処理 |
| プッシュ通知 | 指定した受信先へ更新を通知する | 常時接続を維持しない処理 |
SSEは、サーバーから更新を継続的に送る方式です。プッシュ通知の受信先であるWebhookは、通知を受け付ける窓口を指します。公式の非同期処理ガイドを基に、接続維持の可否や通知先の管理負担で選んでください。どの方式でも、通信切断だけを仕事の失敗と決めつけず、状態を確認する設計にします。
A2A対応だけでは互換性を保証できない
「A2A対応」という表示だけで、任意の組み合わせが動くとは判断できません。 双方の仕様の版、通信方式、追加機能、入出力形式を確認する必要があります。
現行の公式仕様には、JSON-RPC、gRPC、HTTP+JSON/RESTの通信方式への対応付けが定められています。この対応付けをbindingと呼びます。すべてのエージェントが全方式を実装しているとは限りません。
接続試験では、通常の依頼だけでなく、入力待ち、取消、権限不足、通信中断も扱います。形式が一致しても、「金額」が税込か税抜か、「完了」が下書き作成か送信済みかで業務は変わります。プロトコルの一致と、仕事の意味の一致を別々に確かめましょう。
認証と認可を分けて設計する
認証は「誰からの依頼か」、認可は「その相手に何を許すか」の確認です。A2Aでは標準的な認証の仕組みを利用しますが、業務データや操作に対する権限の強制は実装側に残ります。
公式の認可範囲の規定は、利用者に許された範囲でTaskの取得や一覧表示などを行うよう求めています。Taskの識別子を知っているだけで、別の利用者の結果を読める設計にはできません。
企業では、検索、更新、外部送信を同じ権限にまとめないことを推奨します。見積もり案を作る権限と、顧客へ送る権限も分けます。依頼側の文章ではなく、受信側と連携先システムの両方で実行権限を確認してください。
データと成果物の安全性は別途確認する
内部ロジックを公開せずに連携できても、渡す依頼や成果物まで外部に出ないという意味ではありません。 MessageやArtifactに含める情報、保存先、保持期間、閲覧できる相手を別途確認します。
公式のセキュリティ事項は、本番通信の暗号化、入力検証、秘密情報の保護、監査などを求めています。HTTP系ならHTTPS、gRPCならTLSによる暗号化を使う前提です。
運用設計では、次の確認を組み込んでください。
- 依頼に不要な個人情報や顧客情報を含めない。
- 結果やログに認証トークンを保存しない。
- 外部から返った文章やファイルを、実行許可の代わりに扱わない。
- 成果物の形式や参照先を検査し、想定外の内容を拒否する。
- プッシュ通知の送信先と、受信する通知の送信者を検証する。
情報を減らす判断は業務側、技術的な制限は開発側と情報システム部門が担当するなど、責任者も具体化します。
企業での活用は部門間の引き継ぎから考える
活用候補は、部署やシステムをまたいで情報を引き継ぐ業務です。以下は仕組みを説明するための想定例であり、特定企業の導入実績や成果ではありません。
| 想定業務 | エージェント間で任せる仕事 | 人が残す判断 |
|---|---|---|
| 問い合わせ対応 | 受付から専門担当へ調査を依頼 | 対外回答の承認、例外対応 |
| 見積もり準備 | 営業側から在庫や納期の調査を依頼 | 価格条件の確定、正式な提示 |
| 文書レビュー | 作成側から別の確認担当へ点検を依頼 | 修正の採否、最終承認 |
たとえば見積もり準備なら、最初から受注確定まで任せる必要はありません。必要情報を集める範囲に絞れば、依頼と成果物の条件を定義しやすくなります。相手の担当領域が曖昧な仕事より、入力と完成条件を書ける仕事から試すことを推奨します。
A2Aを導入する5ステップ
企業の導入は、対象業務、責任設計、仕様確認、限定検証、運用判定の順で進めます。以下は本記事が提案する計画で、特定SDKの実行手順ではありません。
1. 引き継ぐ業務を選ぶ
依頼元と依頼先が明確な仕事を選びます。現在の入力、成果物、確認者、例外時の戻し先を整理してください。読み取りや下書き作成から始め、送信や確定操作は切り離します。
2. データと責任者を決める
渡す情報と実行できる操作を一覧にします。誰の権限で処理するか、どこで人の承認を挟むか、結果を誰が受け入れるかを決めます。認証情報の保管と失効の担当も必要です。
3. 接続する双方の仕様を確認する
Agent Card、通信方式、仕様とSDKの対応版を確認します。必要な通知方式やファイル形式も対象です。双方の提供元に、対応と未対応を分けた一覧を求めると判断しやすくなります。
4. 限定したデータで検証する
機密情報を避けたテストデータで、通常処理と異常系を試します。情報不足、権限不足、遅延、切断、再送時の動作を確認します。成果物を人が点検し、期待した入力と結果が対応するか記録してください。
5. 運用へ移す条件を判定する
業務の合格基準に加え、ログ、監視、停止方法、問い合わせ先がそろっているかを確認します。公式の企業向け実装ガイドも参照し、不具合を検出して止められる状態になってから対象範囲を広げます。
費用対効果は規格ではなく業務単位で測る
A2Aの規格を採用したこと自体を効果とせず、引き継ぐ仕事が改善したかを測ります。規格はApache License 2.0で公開されていますが、モデル利用、サーバー、開発、監視などの費用は別です。
検証時には、従来の作業と同じ条件で次の項目を記録する方法を推奨します。
- 依頼から検収までの所要時間
- 人が確認や修正に使った時間
- 結果の不備、再依頼、未完了の件数
- モデルや基盤の利用費、保守作業の負担
処理が速くても、確認作業や例外対応が増えれば全体の改善とは限りません。削減率を先に置くのではなく、自社で測った結果から、従来の方法と比べて継続する価値があるか判断します。
障害時に止められる運用を先に決める
A2A連携を本番へ進める前に、止まった仕事の発見方法と、再開する責任者を決めます。 正常に応答することだけでは、運用の準備ができたとはいえません。
たとえば返事がないときは、相手が未受付なのか、処理中なのか、完了した通知だけが届かなかったのかを切り分けます。確認せずに同じ依頼を再送すると、業務の二重実行につながるためです。再送を許す条件と、重複を判定する仕組みを実装側で用意します。
追加入力待ちを誰が解消するか、期限を過ぎた仕事を誰が調べるかも決めます。なお、終端状態のTaskをそのまま再開する扱いは、公式のTaskライフサイクルと区別してください。再実行が必要なら、新しい仕事として管理します。
図3: 対応表記だけで判断せず、限定データの検証と停止方法を先に決めます。
あわせて読みたい
- MCPの仕組みと始め方: AIと外部システムをつなぐ基本を整理できます。
- MCPサーバーの仕組みと安全な選び方: ツール接続側の権限や運用を補足できます。
よくある質問
A2Aは、MCPを置き換える製品でも、安全性を一括保証する仕組みでもありません。導入時によく迷う点を整理します。
Q. A2AがあればMCPは不要ですか？
不要にはなりません。A2Aは独立したエージェント間の連携、MCPはツールやデータとの接続を主に扱います。必要に応じて併用できますが、すべてのA2AシステムにMCPが必須という意味でもありません。
Q. Google以外のAIエージェントでも使えますか？
使えます。A2Aは特定のモデルや開発フレームワークに限定されない規格です。ただし、利用するアプリやエージェントが対応しているか、接続する双方で通信方式や機能が一致するかは個別に確認します。
Q. Agent Cardはインターネットへ公開する必要がありますか？
必須ではありません。社内カタログや直接設定による発見も可能です。社内用の接続先や機密性の高い能力説明を扱う場合は、カードの取得にもアクセス制御を設けます。
Q. すべてのやり取りでTaskを作る必要がありますか？
ありません。即座に完結する応答ならMessageだけを返せます。進捗や追加対応の追跡が必要な仕事でTaskを使い、会話の単位と仕事の単位を分けて設計します。
Q. A2A対応製品同士なら設定なしで連携できますか？
そうとは限りません。仕様の版、通信方式、対応機能、認証と認可、入出力形式の確認が必要です。技術的に接続できても、依頼の意味や成果物の合格条件は別途合意します。
Q. A2Aは無料で利用できますか？
規格はオープンソースとして公開されています。ただし、採用したサービスやモデルの料金、開発、運用の費用が無料になるわけではありません。対象業務に必要な構成で費用を確認してください。
まとめ
A2Aプロトコルは、独立したエージェント同士の依頼や進捗、成果物の受け渡しを共通化します。MCPとは補完関係にあり、通信をそろえることと、業務を安全に任せることは別の設計課題です。
企業では、必要性、互換性、責任分界の3要素で判断してください。Agent Cardで接続条件を確かめ、Message、Task、Artifactを役割に応じて使い分けます。旧仕様のサンプルを現行仕様へ混ぜない注意も必要です。
最初の行動は、別システムへ引き継ぐ業務を1つ選ぶことです。渡す情報、完成条件、確認者を明確にし、限定検証で効果と運用負担を測ってから広げましょう。
AI導入に関するお困りごとをサポートします
株式会社NexaのAI顧問は、ツール選定から業務への適用、社内定着までを月額制でサポートします。特定のツールに限らず、「AIをどう使えばいいか分からない」という段階からご相談いただけます。
この記事で参照した外部情報
- A2A公式ドキュメントa2a-protocol.org
- 公式の概要a2a-protocol.org
- A2A公式の比較a2a-protocol.org
- MCP公式の定義modelcontextprotocol.io
- 公式GitHubの最新リリースはv1.0.1github.com
- 仕様のバージョン規則a2a-protocol.org
- v1.0の変更点a2a-protocol.org
- 公式の基本概念a2a-protocol.org
- 現行のAgentCard定義a2a-protocol.org
- 公式の発見方法a2a-protocol.org
- TaskStateの定義a2a-protocol.org
- 基本概念のMessageとPartの説明a2a-protocol.org
- 公式のArtifact解説a2a-protocol.org
- 公式仕様の共通ワークフローa2a-protocol.org
- 公式の非同期処理ガイドa2a-protocol.org
本文中でリンクしている外部ページの一覧です（自動生成）。最終確認日は本記事の最終更新日 2026-10-11 で、リンク先の内容はその後変わることがあります。
AI導入を検討中の方へ
