A2A vs MCP：違い・使い分け・組み合わせ方

MCP（Model Context Protocol） は、1 つの AI アプリケーションをツール・データ・プロンプトにつなぐプロトコルです。モデルが search_issues のような関数を呼び出し、構造化された結果を受け取ります。A2A（Agent2Agent） は、あるエージェントを別の独立したエージェントにつなぐプロトコルです。内部が見えない相手にタスク全体を任せ、相手が進捗と結果を返してきます。両者は競合しません。A2A を使う実際のシステムのほとんどは MCP も使っており、MCP は各エージェントの内側、A2A はエージェント同士の間で動きます。

A2A プロジェクト自身のドキュメントは一言でこうまとめています：MCP は縦方向、A2A は横方向。MCP は 1 つのエージェントをより有能にし、A2A はそのエージェントが他のチーム・ベンダー・企業のエージェントに手を伸ばせるようにします。MCP 自体が初めてなら、先に MCP とは？ を読んでから戻ってきてください。

A2A vs MCP 早見表

最も重要なのは「相手は何か」の行です。MCP サーバーは入力スキーマ付きの関数を公開するので、モデルは自分が何を呼んでいるかを正確に把握できます。A2A エージェントは自然言語で記述された スキル を公開し、内部は非公開のままです。プロンプト、ツール、メモリ、さらにはどのモデルで動いているかさえ見せません。

MCP がすること

MCP は、AI アプリケーション（Claude Code、Cursor、ChatGPT などのホスト）が、コンテキストやアクションを提供するサーバーとどう通信するかを標準化します。サーバーが公開するプリミティブは 3 種類です。モデルが呼び出せる tools（ツール）、アプリがコンテキストとして読める resources（リソース）、ユーザーが起動できる prompts（プロンプト）。サーバー側については MCP サーバーとは？、メッセージ単位のライフサイクルは MCP はどう動くのか？ を参照してください。

2026 年に押さえておくべき点は 2 つです：

• 現行仕様の 2026-07-28 リビジョン で MCP はステートレスになりました。initialize ハンドシェイクは廃止され、すべてのリクエストが _meta にプロトコルバージョンとクライアント機能を載せ、サーバーは server/discover で自身を通知します。
• Anthropic は 2025 年 12 月 9 日に、Linux Foundation 傘下の指定基金である Agentic AI Foundation に MCP を寄贈しました。

ツール呼び出しは次のようになります（公式アーキテクチャガイド より）：

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

結果は content 配列（任意で structuredContent）で、"resultType": "complete" が付きます。モデルがツールを選び、JSON Schema に沿って引数を埋め、データを受け取る。サーバー側にエージェント的な振る舞いは一切ありません。

A2A がすること

A2A は、あるエージェントが別のエージェントに仕事を頼む方法を標準化します。Google は 2025 年 4 月の Cloud Next で 50 社以上のパートナーとともに 発表し、2025 年 6 月に Linux Foundation へ寄贈しました。最初の安定版 1.0.0 は 2026 年 3 月 12 日にリリースされています。2025 年 8 月には IBM の Agent Communication Protocol（ACP）が A2A に統合され、Linux Foundation のエージェント間標準は 2 つではなく 1 つになりました。1 周年の時点で Linux Foundation は 150 以上の支援組織 を報告しています。

A2A 仕様 の中核オブジェクトは次のとおりです：

• Agent Card：エージェントの名前、スキル、対応インターフェース、機能（ストリーミング、プッシュ通知）、セキュリティスキームを記述した JSON ドキュメント。公開カードは https://{domain}/.well-known/agent-card.json に置かれます。1.0 では署名付きカードにも対応しています。
• Task（タスク）：作業単位。状態には TASK_STATE_SUBMITTED、TASK_STATE_WORKING、TASK_STATE_INPUT_REQUIRED、TASK_STATE_AUTH_REQUIRED、TASK_STATE_COMPLETED、TASK_STATE_FAILED、TASK_STATE_CANCELED、TASK_STATE_REJECTED があります。
• Message と Part：テキスト・ファイル・データのパートで構成される会話のターン。
• Artifact：レポートやファイルなど、リモートエージェントが生成する成果物。

操作は SendMessage、SendStreamingMessage、GetTask、ListTasks、CancelTask、SubscribeToTask、プッシュ通知設定のメソッド群、そして GetExtendedAgentCard です。クライアントは各リクエストに A2A-Version ヘッダー（例：1.0）を付けます。

以下は仕様に載っている HTTP+JSON バインディングの例で、クライアントが質問し、完了済みのタスクを受け取ります。

POST /message:send HTTP/1.1
Host: agent.example.com
Content-Type: application/a2a+json
Authorization: Bearer token

{
  "message": {
    "role": "ROLE_USER",
    "parts": [{"text": "What is the weather today?"}],
    "messageId": "msg-uuid"
  }
}

{
  "task": {
    "id": "task-uuid",
    "contextId": "context-uuid",
    "status": { "state": "TASK_STATE_COMPLETED" },
    "artifacts": [
      {
        "artifactId": "artifact-uuid",
        "name": "Weather Report",
        "parts": [{ "text": "Today will be sunny with a high of 75°F" }]
      }
    ]
  }
}

2 つのペイロードを比べてみてください。MCP は関数名と型付き引数を送ります。A2A は 自然言語のメッセージ を送り、ID・コンテキスト・成果物を持つ タスク を受け取ります。どうやって答えを出すかはリモートエージェントが決めます。

MCP を使うとき、A2A を使うとき

MCP を使うべきケース：

• アシスタントやエージェントに何かを読ませたり変更させたりしたい：リポジトリ、データベース、チケット管理、ブラウザなど。代表例は GitHub MCP サーバー、Postgres MCP、Playwright MCP です。
• 機能の入出力が明確で、それ自体に推論が要らない。
• みんながすでに使っているクライアントで動かしたい。Claude、ChatGPT、Cursor、VS Code、Codex はすべて MCP に対応しています。クライアント一覧 を参照してください。

A2A を使うべきケース：

• 呼び出す相手自体が、独自のモデル・ツール・判断力を持つエージェントで、委任したいのが関数呼び出しではなく目標である。
• 相手のエージェントが別のチーム・ベンダー・企業のもので、内部を公開しない（すべきでない）。
• 処理が長時間またはマルチターンになる：リモートエージェントが追加入力（TASK_STATE_INPUT_REQUIRED）や追加認証を必要としたり、完了まで数時間かかったりし、進捗はストリーミングまたは Webhook へのプッシュで返ってくる。

簡単な見分け方： その機能を関数シグネチャとして書けるなら MCP ツールです。「経理チームのエージェントに対応してもらう」と表現するなら A2A 呼び出しです。

A2A と MCP の組み合わせ方

A2A 仕様の MCP に関する付録 が標準パターンを説明しています。A2A クライアントエージェントが A2A サーバーエージェントに複雑なタスクを依頼し、サーバーエージェントは MCP を使って、タスクを完了するのに必要なツール・API・データにアクセスします。

旅行予約フローを例にします：

1. ユーザーが旅行エージェント（任意のフレームワークで構築）に旅程の作成を頼む。
2. 旅行エージェントは、パートナーが運営する航空券エージェントとホテルエージェントの Agent Card を読み、それぞれに A2A でタスクを送る。
3. 内部では、航空券エージェントが MCP サーバー経由で航空会社の在庫 API と決済サービスを使う。ホテルエージェントも自前の MCP サーバーで同様に処理する。
4. ホテルエージェントが TASK_STATE_INPUT_REQUIRED（「朝食付きにしますか？」）になり、旅行エージェントが同じ contextId で回答する。
5. 両方のタスクが成果物（旅程表）付きで完了し、旅行エージェントがそれらをまとめてユーザーに渡す。

旅行エージェントは航空会社の API を一度も見ず、航空券エージェントもユーザーの会話を見ません。MCP は各エージェントに深さを、A2A はシステムに広がりを与えます。

逆方向も可能です。リモートエージェントを MCP ツールとしてラップすれば、IDE のような MCP 専用クライアントからも呼び出せます。単発の簡単なリクエストならこれで十分ですが、A2A のタスクライフサイクル、マルチターン入力、プッシュ通知は失われます。本格的な委任には A2A を直接使いましょう。

よくある誤解

• 「A2A は MCP を置き換える」 いいえ。Google は A2A を MCP を補完するものとして発表しており、現在はどちらも Linux Foundation のプロジェクトです。スコープはほとんど重なりません。
• 「MCP ではエージェント間通信ができない」 MCP サーバーの裏に LLM を置くことは できます し、MCP には elicitation や長時間ジョブ向けのオプションの Tasks 拡張もあります。しかし MCP には Agent Card も、ピア間のタスクライフサイクルも、スキルを持つ不透明なエージェントという概念もありません。ツールとコンテキストのために設計されています。
• 「最初から両方必要だ」 ほとんどのチームに必要なのは MCP だけです。異なる主体が所有する複数のエージェントが協調しなければならなくなったときに、A2A が重要になります。
• 「どちらも JSON-RPC だから同じものだ」 ワイヤーフォーマットが同じでも、それだけでは何も言えません。MCP はスキーマとモデル主導の呼び出しを中心に、A2A はピア間のタスク・メッセージ・成果物を中心に設計されています。
• 「ACP という 3 つ目の標準にも対応しなければならない」 IBM の ACP は 2025 年に A2A に統合されました。無関係の Agent Client Protocol（エディタとコーディングエージェントをつなぐ）も同じ略称なので、どちらの話か確認しましょう。

次のステップ

有能なエージェントを 1 つ作るなら、まず MCP から始めましょう。MCP.so のサーバーディレクトリ で既製のインテグレーションを探し、MCP vs RAG で MCP と検索拡張生成を比較し、MCP はどう動くのか？ で根底にあるプロトコルを理解してください。エージェントが他者の運営するエージェントにタスク全体を任せる必要が出てきたら、A2A を追加しましょう。