MCPの次はA2A——AIエージェントどうしが「話し合う」新標準プロトコルと、n8nへの影響

MCPから始まった「AI接続の標準化」が次の段階へ

2025年以降、AIを業務に組み込もうとする企業の多くがMCPという言葉に出会っています。MCP（Model Context Protocol）とは、AIが外部のツールやデータソースに接続するための通信規格で、Anthropicが提唱しました。MCPがあることで、AIはkintoneのデータを読み書きしたり、Googleカレンダーに予定を登録したり、slackにメッセージを送ったりといった「ツール操作」を自律的に行えるようになります。

MCPが「AIとツールの接続」を標準化した規格だとすると、A2A（Agent2Agent）プロトコルは「AIエージェントどうしの接続」を標準化する規格です。2025年4月にGoogleが発表し、2026年初頭にv1.0がリリースされました。現在はLinux Foundation傘下のAgentic AI Foundation（AAIF）という独立した組織が管理しており、特定の企業の独占にならない形で標準化が進められています。

「MCPもA2Aも似たようなもの？」と思われる方もいるかもしれませんが、両者は用途が根本的に異なります。それぞれが異なる「問題」を解決するために設計されており、実際の業務自動化では両方を組み合わせて使うことが想定されています。

MCPとA2Aの違い——「ツール接続」と「エージェント委託」

MCPは、1つのAIが複数のツールを「操作する」ときに使います。たとえば、営業支援AIが「CRMから顧客リストを取得→Excelで集計→Slackで報告」という一連の作業をする場合、MCPを通じて各ツールに接続します。この場合、AIは「ひとつの中央」にいて、複数のツールに命令を出す構造です。

A2Aは、1つのAIが別のAIに「仕事を委託する」ときに使います。例えば「受注処理AIエージェント」が新規注文を受け取ったとき、在庫確認は「在庫管理AIエージェント」に委託し、請求書発行は「経理AIエージェント」に委託し、顧客への確認メールは「コミュニケーションAIエージェント」に依頼する——という形で、専門化された複数のAIエージェントが協力して一連の業務を完結させます。

比較項目	MCP（Model Context Protocol）	A2A（Agent2Agent）
接続対象	AIとツール・データ	AIエージェントどうし
主な役割	ツールの操作・データの読み書き	タスクの委託・結果の受け取り
提唱者	Anthropic	Google
管理主体	Anthropic（OSS公開）	Linux Foundation傘下AAIF
使い方	「どのツールを使うか」を定義	「どのエージェントに何を頼むか」を定義
組み合わせ	A2Aと併用が前提	MCPと併用が前提

重要なのは「どちらが優れているか」ではなく、「用途が違う」という点です。MCPとA2Aは競合ではなく補完関係にあり、本格的なAI業務自動化では両方を適切に組み合わせることが標準的になっていきます。

150社超が支持する理由——「ベンダー中立」の重要性

A2Aプロトコルの特徴の一つが、支持企業の幅広さです。2026年5月時点で、Google・Microsoft・AWS・Salesforce・SAP・ServiceNow・Workday・IBM・Anthropic・OpenAIを含む150社超が参加・支持を表明しています。この顔ぶれを見ると、通常は競合関係にある企業が同じ規格を採用していることがわかります。

なぜ競合同士が同じ規格を採用するかというと、「接続コストの削減」という共通利益があるからです。例えばA社のAIエージェントとB社のAIエージェントが連携しようとしたとき、共通規格がなければ両社のエンジニアが専用の接続コードを書く必要があります。A2Aという共通規格があれば、「A2A対応済み」同士であれば比較的容易に連携が実現します。これはHTTPというWebの通信規格が世界中のサーバーを繋いでいるのと同じ発想です。

また、A2AはgRPC（Googleが開発した高速な通信方式）に対応しており、リアルタイムでの大量通信に強い設計になっています。エージェントが別のエージェントに仕事を委託するとき、その結果を待ちながら処理を進める「非同期通信」にも対応しています。さらに署名付きAgent Cards（各エージェントの能力と認証情報を記述した電子証明書のようなもの）と、マルチテナント対応（1つのシステムで複数の会社・組織のデータを安全に分離して扱う仕組み）も規格に含まれており、企業での実用に耐える設計です。

実際の業務でどう使われるか——「全自動の受注処理フロー」で考える

A2Aが実際の業務フローにどう組み込まれるか、具体的なシナリオで考えてみます。製造業の受注処理を例に取ります。

現在の典型的なフローは「顧客からメールで注文が届く→担当営業が内容を確認→在庫担当に確認の連絡→在庫確認ができたら受注確定メールを顧客に送る→経理に請求書発行を依頼→発送手配を物流部門に依頼」という流れで、各ステップで人間の確認・転記・連絡が必要です。

A2Aが普及した環境では、このフローが次のように変わります。まず「受付エージェント」が顧客のメールから注文情報を抽出し、「在庫確認エージェント」に在庫チェックを委託します（A2A通信）。在庫確認エージェントはWMSシステムに接続して（MCP通信）在庫データを確認し、結果を受付エージェントに返します。受付エージェントは在庫ありと確認したら「請求書エージェント」に請求書発行を委託し（A2A通信）、同時に「顧客対応エージェント」に確認メールの送信を依頼します（A2A通信）。請求書エージェントはfreeeなどの会計ソフトと接続して（MCP通信）請求書を発行します。

この一連のフローで人間が関与するのは、例外処理（在庫不足、特別割引の承認など）の判断だけです。定型的な受注の多くは、担当者の確認なしに自動で処理される世界になります。

n8nとA2A——「エージェントの指揮者」としての役割

n8nは、複数のツールやサービスを繋ぐワークフロー自動化ツールで、日本でも業務効率化を目的に多くの企業が導入を進めています。n8nの強みは「異なるツール間の連携を、コーディングなしで設定できる」点にあります。

A2Aの普及によってn8nの役割も変化します。これまでのn8nは「AのシステムでトリガーされたらBのシステムにデータを送る」という「データパイプライン」としての使い方が中心でした。A2A対応が進むと、n8nは「複数のAIエージェントを調整する指揮者（オーケストレーター）」として機能できるようになります。

具体的には、n8nがA2Aを通じて「顧客対応エージェント」「在庫管理エージェント」「経理処理エージェント」それぞれに指示を送り、各エージェントからの結果を受け取って次のステップを判断するという構成が現実的になります。n8nはビジネスロジック（「在庫が少ない場合は承認を要求する」などのルール）を管理し、AIエージェントは各専門領域の実行を担当する——という役割分担です。

すでにn8nを社内で運用している企業は、A2Aの普及に備えてn8nのノードの整理と、AIエージェントとの接続ポイントの設計を今から始めておくと、移行コストを最小化できます。n8nでの業務自動化に取り組んでいるはてなベースでも、こうしたA2A対応を見据えた構成設計の支援を進めています。

A2Aと人間の関係——「全自動」だけが正解ではない

A2Aによってエージェント連携が進むと、「すべての業務が全自動化される」という印象を持つ方もいるかもしれません。しかし実際のビジネスでは、人間の判断が不可欠な場面は必ず残ります。A2Aを設計する上での重要な視点は「どこで人間が介在するか」を明確にすることです。

例えば受注処理の場合、定型的な注文（在庫あり・支払い条件が標準・金額が一定範囲内）はエージェント間の自動連携で完結させ、例外的な注文（特別割引・大口・新規取引先）は人間の承認を経由するルートに分岐する設計が現実的です。「全部AIに任せる」のではなく「定型はAIが処理し、例外は人間が判断する」という役割分担が、実務に即した活用のかたちです。

A2Aのアーキテクチャには、エージェント間の通信にチェックポイントを設けて人間の確認を挟む仕組みが設計段階から組み込まれています。これを「ヒューマン・イン・ザ・ループ（人間が監督に介在する構造）」と呼びます。この設計思想は、AIエージェントを使う際の基本的な安全原則として、主要ベンダーが一致して推奨しています。

今、企業が準備しておくべきこと

A2Aプロトコルはまだ普及の初期段階ですが、Google・Microsoft・Salesforceといった主要ベンダーが揃って支持していることを考えると、今後1〜2年で主要な業務ツールへの実装が加速することは確実視されています。では、今の時点で中小・中堅企業が準備しておくべきことは何でしょうか。

最初にやるべきは「業務フローの可視化」です。A2Aによるエージェント連携の恩恵を受けるためには、自社の業務フローが整理されていることが前提になります。「誰が何をして、次の誰に何を渡すか」が整理されていない業務をそのままAIに渡しても、AIが混乱するだけです。業務フローを可視化して、どこに判断が必要でどこが定型作業かを整理することが、エージェント活用の土台になります。

次に「現在使っているツールのA2A対応状況の確認」が必要です。使用中の業務ツールがA2A対応を予定しているかどうかは、各ベンダーのロードマップで確認できます。特に、複数のツールをまたいで業務が流れている領域（例えば受注からCRMへの登録、CRMから請求書システムへの転記など）は、A2A対応によって大きく変わる可能性があります。

「今すぐA2Aを導入する」必要はありませんが、MCPによる現行の業務自動化を進めながら、A2Aへの移行を見据えた設計にしておくことで、将来の技術投資を無駄にしない準備ができます。はてなベースではn8nを活用した業務自動化の設計・構築支援を行っており、A2A時代を見据えた拡張性のあるフロー設計のご相談にも対応しています。

MCPとA2Aを組み合わせた実装のイメージ

MCPとA2Aは「組み合わせて使う」ことが前提の規格です。実際の業務自動化システムでは、A2Aが「指揮系統」を担い、MCPが「ツール接続」を担う役割分担になります。これを受注処理を例に整理すると、次のような構成になります。

顧客からの注文メールを受け取る「受注エージェント」は、A2Aを使って「在庫確認エージェント」に在庫チェックのタスクを委託します。在庫確認エージェントは、MCPを使って在庫管理システムに接続し、リアルタイムの在庫データを取得します。結果を受注エージェントに返すときはA2Aを使います。受注エージェントは在庫ありと確認したら、A2Aを使って「請求書エージェント」に請求書発行を依頼し、請求書エージェントはMCPでfreeeと接続して請求書を発行します。

このように、A2AとMCPが階層的に使われることで「エージェントが別のエージェントに仕事を委託しながら、各エージェントがそれぞれのツールと接続する」という多層構造の自動化が実現します。n8nはこの全体の流れを監視・制御するオーケストレーターとして機能し、例外処理や人間への確認ポイントを管理します。

この構成は現時点では先進的ですが、主要ツールのA2A対応が進む2026〜2027年にかけて、段階的に実現可能なものになっていきます。「MCP対応の業務自動化を今から進めておく」ことが、A2A時代への最も現実的な準備です。MCP導入の経験が、A2Aへの移行をスムーズにする土台になります。