システム開発の提案書やITニュースで、最近「A2A対応」「マルチエージェント基盤」という言葉を目にする機会が増えていないでしょうか。半年ほど前から「MCP」という単語をようやく整理できたと思ったところに、また別のプロトコル名が出てきて戸惑っている発注者の方は少なくないはずです。
しかも困ったことに、「A2Aとは？」で検索すると、Agent CardやJSON-RPCといった技術用語が並ぶエンジニア向けの解説記事が上位を占めます。「結局のところ、MCPと何が違うのか」「うちの会社は今A2A対応を発注要件に入れるべきなのか」といった、発注者が本当に知りたい判断基準にたどり着けないケースがほとんどです。
結論から言えば、A2AとMCPは競合するものではなく、役割の異なる補完関係にあります。MCPが「AIエージェントと業務ツールをつなぐ縦の接続」を担うのに対し、A2Aは「AIエージェント同士をつなぐ横の連携」を担います。マルチエージェント時代を迎える上では、どちらか一方ではなく両方が必要になる、というのが現在の業界の共通認識です。
本記事では、システム開発の発注意思決定者に向けて、A2Aプロトコルの基本、MCPとの違い、発注時に押さえるべきメリットと判断軸、そして開発会社への具体的な確認質問を整理してお伝えします。読み終えたときには、「うちの会社の状況ではA2A対応をどう扱うべきか」を自分の言葉で説明できる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
A2A（Agent2Agent）プロトコルとは？発注者が知っておくべき要点
まずは全体像から押さえていきます。A2Aは、AIエージェント同士のやり取りを標準化する新しい共通規格です。
A2Aを一言で言うと「AIエージェント同士の共通言語」
A2A（Agent2Agent、エージェント・トゥ・エージェント）とは、異なるベンダーやフレームワークで作られたAIエージェント同士を、安全かつ相互運用可能な形で連携させるためのオープンプロトコルです。Googleが2025年4月に発表し、その後Linux Foundationへ寄贈された仕様で、2026年時点では業界標準化が急速に進んでいます（Linux Foundation公式プレスリリース）。
わかりやすくたとえるなら、A2Aは「AIエージェント同士の共通言語」です。人間の世界で英語が国際共通語として機能するように、A2Aに対応したAIエージェントであれば、提供元のベンダーやフレームワークが違っていても互いに話し合い、タスクを委任し、結果を受け取ることができます。
エージェントは自分の能力（何ができるか）を「Agent Card」と呼ばれる公開情報として提示します。別のエージェントはそれを読み取り、「このタスクは自分ではなく相手にお願いした方が早い」と判断すれば、A2A経由でタスクを委任します。相手の内部実装や記憶、モデルの詳細は開示する必要がなく、標準化されたやり取りだけで協調動作が成立する、というのが基本発想です。
前提として押さえておきたいのは、A2Aは既存のAIエージェント技術を置き換えるものではなく、「複数のエージェントを安全につなぐための共通ルール」にすぎない、という点です。単体のAIエージェントを作る話ではなく、「複数のAIエージェントが協調する時代」に向けたインフラの一部として位置づけると理解しやすくなります。
発表から現在までの経緯
A2Aの登場から2026年現在までの流れを簡単に整理しておきます。
- 2025年4月: GoogleがGoogle Cloud Nextで発表。Salesforce・SAP・ServiceNow・Atlassianなど約50社がローンチパートナーとして名を連ねました
- 2025年6月: Googleが仕様をLinux Foundationへ寄贈。Microsoft・AWSなどの参加でベンダー中立の標準化団体が発足しました（Linux Foundation発表）
- 2026年4月: 発表から1年で参加組織が150を超え、Azure AI Foundry・Amazon Bedrock AgentCore・Google Cloudといった主要クラウドプラットフォームがA2Aをネイティブ統合するに至っています
この短期間で「特定ベンダーの製品」から「業界標準」へと位置づけが変わった点が、A2Aの特徴的な動きです。過去にはある1社が発表した規格が業界全体には広がらず立ち消えになった例も多くありますが、A2AはLinux Foundationへの寄贈と主要クラウド3社の同時サポートによって、一定の永続性が担保された状態にあると評価されています。
なぜ発注者が今このタイミングで知っておくべきか
「業界標準になった話は分かった。ただ、なぜ自分がこのタイミングで知る必要があるのか」という疑問に答えておきます。
理由は大きく2つあります。
1つ目は、多くの企業でAIエージェント活用が「単体導入」から「複数エージェントの連携」へと段階が進んでいることです。社内問い合わせBot・営業自動化エージェント・データ分析エージェントといった個別用途のAIが増えてきた今、それらをどう連携させるかが次の設計テーマになります。ここで連携方法がバラバラだと、後から接続コストが跳ね上がります。
2つ目は、開発ベンダー側の提案書や技術選定に「A2A対応」という選択肢が入ってき始めていることです。「対応・非対応」で費用や設計思想が変わるため、発注者としての判断基準を持たないまま任せてしまうと、あとから「特定ベンダーのAIエージェントに縛られていて他社製品と連携できない」といった状況に陥る恐れがあります。
つまりA2Aは、「今日明日の業務が変わる話」ではなく、「これから1〜2年で組み上げるAIエージェント基盤の設計判断に影響する話」として押さえておくべきテーマになります。
MCPとの違い｜「縦の接続」と「横の連携」の役割分担
ここが本記事で最も重要なセクションです。多くの発注者が混乱している「MCPとA2Aは競合するのか？どちらを選べばいいのか？」という疑問に、正面から答えます。
結論を先に述べます。MCPとA2Aは競合しません。役割が異なるため、両方が必要です。
MCPは「AI ⇄ ツール」、A2Aは「AI ⇄ AI」
MCP（Model Context Protocol）は、2024年11月にAI企業Anthropicが発表したプロトコルで、AIエージェントとSlack・Notion・社内DB・SaaSなどの業務ツールを標準化された方法で接続するための仕組みです。詳細は姉妹記事MCPとは？AIと業務ツールをつなぐ新標準プロトコルを発注者向けに解説で解説しています。
MCPが担うのは、いわば「縦の接続」です。1つのAIエージェントが、複数の業務ツールにアクセスできるようにします。
一方、A2Aが担うのは「横の連携」です。ある業務領域を担当するAIエージェントが、別の業務領域を担当するAIエージェントにタスクを委任したり、情報をやり取りしたりできるようにします。ここでの「エージェント同士」は、同じ組織の中で作った内製エージェントに限らず、他社が提供する業務エージェント（Salesforce Agentforce・Microsoft Copilot・Google Agentspaceなど）も含みます。
図示するなら、こう整理できます。
- MCP: エージェント → ツール（縦の線）
- A2A: エージェント ↔ エージェント（横の線）
「AIエージェントを高機能にする」という目的地は共通ですが、そこに至る接続の方向が異なる、と理解するのが分かりやすいでしょう。
具体シナリオで見るMCPとA2Aの協調
抽象的な説明では腑に落ちにくいので、業務シナリオで両者の協調を見てみましょう。
シナリオ: 月次締めの経理業務を自動化する
ある企業が、月次締めの経理業務を複数のAIエージェントで自動化しているとします。
- 経理エージェント: 会計SaaSと連携し、仕訳・締めを担当
- 在庫エージェント: 在庫管理システムと連携し、月末棚卸データを提供
- 承認エージェント: 経営者への承認依頼を担当
このとき、経理エージェントが月次締めを進めるためには、在庫エージェントから在庫データを受け取る必要があります。ここでA2Aが登場します。経理エージェントは在庫エージェントの「Agent Card」を参照し、「月末在庫データの取得」というタスクを委任します。返ってきたデータをもとに、経理エージェントは会計SaaSへの仕訳作成を進めます。
会計SaaSとの連携部分では、経理エージェントがMCP経由で会計ソフトのAPIにアクセスします。仕訳が完了したら、今度は承認エージェントに対してA2Aで「経営者への承認依頼」というタスクを委任し、承認エージェントがSlack（MCP経由）で経営者に承認リクエストを送信します。
このように、1つの業務フローの中で「エージェント同士のやり取り（A2A）」と「エージェントとツールのやり取り（MCP）」が交互に発生します。どちらか一方だけでは、この業務フローは成立しません。マルチエージェントを本気で運用するには、両方のプロトコルが不可欠だという理由がここにあります。
比較表｜目的・通信対象・データ形式・提唱元
MCPとA2Aの違いを表形式で整理しておきます。
項目 | MCP（Model Context Protocol） | A2A（Agent2Agent Protocol） |
|---|---|---|
主な用途 | AIエージェントと業務ツール・データソースの接続 | AIエージェント同士の相互連携・タスク委任 |
通信対象 | AI ⇄ ツール（SaaS・DB・API等） | AI ⇄ AI（エージェント間） |
発表元 | Anthropic（2024年11月） | Google（2025年4月）→ Linux Foundation移管（2025年6月） |
標準化ステータス | 主要AIベンダー（OpenAI・Google・Microsoft等）が採用済 | Linux Foundationが管理、150組織超が採用 |
データ形式 | JSON-RPC 2.0ベース | JSON-RPC 2.0ベース + Agent Card（能力広告） |
主な機能 | ツール呼び出し・リソース取得・プロンプト共有 | タスク委任・状態同期・SSEによる進捗ストリーミング |
発注者にとっての位置づけ | AIが業務システムと連携する際の「接続規格」 | 複数のAIエージェントを連携させる際の「協調規格」 |
技術基盤としてはどちらもJSON-RPC 2.0という共通の土台を持っており、「MCP対応済みのシステムにA2A対応を後から追加する」ことも設計上は無理のない構成です。ここも「両方使う」を前提にできる根拠の1つです。
A2Aで何が変わるのか｜発注者にとってのメリット3つ
技術的な特徴の羅列では意思決定に結びつきません。ここでは、発注者にとって特に意味のあるメリットを3点に絞って整理します。
メリット1｜特定ベンダーへのロックイン回避
A2Aがもたらす最も分かりやすいメリットは、AIエージェントレイヤーでのベンダーロックイン回避です。
これまで、複数のAIエージェントを組み合わせようとすると、「Salesforce Agentforceの中では連携できるが、Microsoft Copilotとはつながらない」「Google AgentspaceのエージェントはOpen AIの独自エージェントと直接やり取りできない」といった壁がありました。ベンダーごとに独自の連携方式が存在し、壁を越えるには個別開発が必要だったからです。
A2Aに対応したエージェント同士であれば、この壁を越えて連携が可能になります。「今はSalesforce中心だが、来年はMicrosoftの新機能を追加したい」といった選択肢が現実的になります。特定のクラウドやSaaSに閉じ込められることによる将来の身動きの取りづらさが、大きく緩和されます。
ベンダーロックインは表面化しにくいリスクですが、5年・10年単位で見ると乗り換えコスト・交渉力・イノベーション速度に大きな影響を与えます。ロックイン回避の考え方や対策については、ベンダーロックイン回避のポイントも併せて参照してください。
メリット2｜段階的なマルチエージェント導入
2つ目のメリットは、マルチエージェント基盤を段階的に導入できるようになる点です。
多くの企業では、最初から「10種類のAIエージェントが連携する巨大基盤」を構築するのではなく、まず1つの業務（例: 社内問い合わせ対応）にAIエージェントを導入し、成果を見ながら次の業務（例: 営業リード対応）に展開する、という段階アプローチを取ります。
このとき、初期に導入したエージェントがA2A対応であれば、後から追加するエージェントとの連携はプロトコルレベルで担保されます。既存投資（初期エージェント）を捨てずに、新規エージェントを追加できます。逆にA2A非対応の独自方式で作ってしまうと、2つ目のエージェント追加時に「既存部分も含めて全面的な作り直し」が発生しやすくなります。
段階導入の考え方は、マルチエージェントAIの基本と業務活用でも触れられています。マルチエージェント設計の全体像を掴んでおくと、A2Aが必要になるタイミングも判断しやすくなります。
メリット3｜監査ログ・セキュリティの標準化
3つ目のメリットは、監査ログやセキュリティに関する仕様が標準化されていることです。
複数のAIエージェントが自律的にタスクを委任し合う世界では、「誰が誰に何を頼んだのか」「その結果どうなったのか」を追跡できることが極めて重要になります。金融・医療・行政など規制産業ではもちろん、一般企業でも内部統制やSOC2などの認証取得の観点で監査ログの取得は避けて通れません。
A2Aプロトコルでは、エージェント間の通信仕様が標準化されているため、ログの記録・監視・分析を統一的な方法で実装できます。独自方式では、エージェントごとにログの形式や粒度がバラバラになり、監査対応の負担が大きくなりがちですが、A2A対応であればここが一定水準で揃うことが期待できます。
またA2Aは、認証・認可の仕組み（OAuth 2.0互換など）も仕様の一部として組み込まれており、「エージェント間で無条件に情報が流れる」状態を防ぐ設計になっています。セキュリティの観点から見ても、独自方式より標準プロトコルを採用する方がリスクを制御しやすくなります。
「今すぐA2A対応を発注要件に入れるべき」ケースと「様子見でよい」ケース
ここまでの内容を踏まえた上で、「では自社は今A2A対応を要件に入れるべきなのか」を判断できるフレームを示します。企業の状況によって、答えは3つに分かれます。
今すぐ発注要件に入れるべきケース
以下のいずれかに該当する場合、A2A対応を発注要件に入れることを強く推奨します。
- 既に複数のAIエージェントを運用しており、連携ニーズが発生している: 例えば「社内問い合わせBotと営業自動化エージェントが情報を共有できると効率化できる」といった具体シナリオが見えている場合、A2A対応が最も効きます
- 大企業と協業しており、ベンダー間連携が要件になる可能性が高い: 取引先が既にSalesforce Agentforce・Microsoft Copilot・Google Agentspaceなどを導入している場合、自社側もA2A対応にしておくと、将来の連携要求に応えやすくなります
- 業界標準への追随が競争要件になっている: 金融・保険・SaaSなど、新技術対応スピードが顧客獲得や信頼獲得に直結する業界では、標準対応の遅れが競争劣位につながります
- PoCから本番展開への移行を今後1年以内に予定している: 「PoC段階は独自方式で急いだが、本番では標準に揃える」という切り替えを計画している場合、切り替え時期のコストを見込んで最初から標準対応を要件化する方が効率的です
様子見でよいケース
一方、以下のいずれかに該当する場合は、必ずしも今すぐA2A対応を要件化する必要はありません。予算やリソースを他に振り向けることも合理的な選択です。
- AIエージェントは単一用途のみで、複数連携の予定がない: 「社内向けFAQ Botを1つ運用する」だけの用途であれば、A2A対応の必要性は当面発生しません
- 内製せず、既存SaaSで完結する運用が中心: SaaS製品側でAIエージェント連携が完結する場合、発注者としての設計判断の対象になりません
- 予算・リソースが限定的で、段階的導入を優先したい: A2A対応を要件化すると、実装コスト・検証コストが増える傾向があります。まずは単体機能の導入を優先し、A2Aは次フェーズの検討事項として整理するのも現実的です
中間ケース｜将来対応の余地を残す設計を要件化する
現実の多くの発注案件は、上記の両極端の中間に位置します。「今すぐA2A対応を明示的に要件化するほどではないが、将来必要になる可能性は高い」というケースです。
このような場合、以下のような要件化が有効です。
- エージェントの設計を疎結合にする: 個別エージェントが特定ベンダーの独自機能に強く依存しない構成にする
- 通信仕様を標準寄りにする: JSON-RPC 2.0ベースなど、A2A・MCPと共通の基盤で作ることを要件に含める
- Agent Card相当の能力広告を設計に含めておく: 「このエージェントは何ができるか」を機械可読な形で提示する仕組みを最初から入れておく
このアプローチであれば、「今A2A対応の実装コストは払わないが、後から追加する際の改修範囲を最小化する」という中間解が取れます。発注者としては、「A2A対応そのもの」ではなく「将来のA2A対応を阻害しない設計」を要件化する、という判断もぜひ選択肢に入れてください。
開発会社にA2Aについて確認すべき4つの質問
意思決定基準を持ったところで、実際に開発会社との会話でどう確認するかが次のテーマです。ここでは、発注者が開発会社に対して投げかけるべき質問を4つ紹介します。単なるYES/NO判断ではなく、「回答内容から相手の理解度・実装経験を読み取る観点」もセットでお伝えします。
質問1｜「A2Aプロトコルの実装経験はありますか？」
最初の質問はストレートです。実装経験の有無を確認します。
ただしYES/NOだけで判断せず、回答内容の具体度を見てください。
- 良い回答例: 「Agent Cardの設計・タスク委任フロー・SSEストリーミングを含む実装経験があります。〇〇社のプロジェクトでMicrosoft Copilotとの連携を実装しました」
- 注意が必要な回答例: 「A2Aという言葉は知っています。今後対応予定です」「対応可能です」だけで具体性がない
キーワードとして、「Agent Card」「タスク委任」「SSE（Server-Sent Events）ストリーミング」「JSON-RPC 2.0」あたりの用語が自然に出てくるかで、開発会社側の理解度がおおよそ判別できます。
質問2｜「複数のAIエージェントが将来的に増えた場合、追加コストはどのくらいですか？」
次に、拡張性のコストを確認します。
A2A対応の設計がきちんとなされていれば、エージェントを1つ追加する際の追加コストは、既存エージェント数に対して線形に増えるはずです。「エージェントを追加すると既存部分も改修が必要になり、コストが指数関数的に増える」という見積が返ってきた場合、A2A対応の名目はあっても実質的に疎結合設計になっていない可能性があります。
質問の狙いは、単なる金額比較ではなく「設計思想を確認する」ことにあります。追加時の改修範囲・影響範囲についての説明が具体的かどうかを見てください。マルチエージェントの導入や運用の全体像についてはAIエージェント導入ガイドも参考になります。
質問3｜「他ベンダーのAIエージェントと連携する要件が出た場合、対応可能ですか？」
これはA2A対応の実質を判定する質問です。
Microsoft Copilot・Salesforce Agentforce・Google Agentspaceなど、具体的なベンダー名を挙げて質問してみてください。真にA2A対応をしている開発会社であれば、「Agent Cardが公開されていれば連携可能です」「相手側もA2A対応であれば、当社エージェントからのタスク委任は仕様通り実装可能です」といった回答が返ってきます。
一方、「そのベンダーとは連携実績がないので難しいです」「別途カスタム開発が必要になります」と答える場合、A2Aの疎結合性を活かした設計になっていない可能性があります。A2Aの本質は「相手を選ばず連携できる」ことにあるため、この質問での回答は特に重要な判断材料になります。
なお、そもそもAIエージェントとは何かの基本を押さえたい場合は、AIエージェントとは？基本定義と業務活用を先に確認しておくと、開発会社との会話がスムーズになります。
質問4｜「エージェント間通信のログはどう取得・監査しますか？」
最後は、セキュリティ・コンプライアンス観点の質問です。
複数のAIエージェントが自律的にタスクを委任し合う環境では、「誰が誰に何を頼んだのか」を後から追跡できることが業務・監査の両面で重要になります。以下のような回答が返ってくるかを確認してください。
- タスク委任のリクエスト・レスポンス・状態変更が構造化ログとして保存される
- 誰（どのエージェント）が誰（どのエージェント）に何を頼んだかを、監査ログから検索可能
- 認証・認可の記録が残る（誰の権限で通信が行われたかを追跡できる）
- 障害発生時にエージェント間通信のトレースが可能
「そのあたりはこれから検討します」という回答が返ってくる場合、本番運用に向けた設計が十分に詰まっていない可能性があります。金融・医療・行政向けなど規制産業の案件であれば、この質問への回答内容は特に重視すべきです。
A2A発注チェックリスト｜検討段階で押さえる6項目
最後に、発注検討段階で押さえるべき6項目をチェックリストとして整理します。姉妹記事MCPとは？AIと業務ツールをつなぐ新標準プロトコルを発注者向けに解説のチェックリストとセットで使うと、AIエージェント時代の発注準備が一通り揃います。
A2A発注チェックリスト
- 自社のAIエージェント運用状況を整理したか: 単体運用なのか、複数連携が発生しているかを明確にする
- 1〜2年後のマルチエージェント構想を持っているか: A2A対応の必要性は、現在ではなく将来の構想次第で決まる
- 取引先・パートナーの利用エージェントを把握しているか: 相手側の利用状況次第で、連携要件の優先度が変わる
- 「A2A対応そのもの」と「将来対応の余地を残す設計」の使い分けができているか: 全案件で対応を要求する必要はなく、案件ごとに選択できる
- 開発会社への4つの質問（本記事参照）を投げかける準備ができているか: 質問の答えから相手の実装力・設計思想を読み取る
- 監査ログ・セキュリティ要件を最初から含めているか: 後付けが最も高コストになる領域なので、初期要件に組み込む
A2A対応かどうかは、「今日の業務ですぐ使うか」で判断するテーマではありません。むしろ、マルチエージェント時代の入口で自社の選択肢を狭めないための「設計判断」として捉えるのが、発注者にとって最も実利のあるスタンスです。
社内の関連部門（情シス・DX推進・経営企画・法務）と本記事の内容を共有し、「うちの会社はどこに位置するか」を議論する材料としてお使いください。技術トレンドを追いかけることではなく、自社の状況に合った意思決定を早めに固めることが、これからのAIエージェント発注では最大の差別化要因になります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- A2AとMCPはどちらか一方だけ導入すればよいですか？
いいえ、両者は役割が異なるため併用が前提です。MCPはAIとツールをつなぐ「縦の接続」、A2Aはエージェント同士をつなぐ「横の連携」を担うため、複数のAIエージェントを連携させる構成では両方が必要になり、実装順序としてはMCP整備後にA2Aを追加する進め方が現実的です。
- 自社にAIエージェントが1つしかない場合、A2A対応は不要ですか？
はい、単一用途のみで複数連携の予定がない場合や、既存SaaSで完結する運用であれば、当面は不要と判断して構いません。ただし将来複数エージェントの連携を見込む場合は、特定ベンダーに依存しない疎結合な設計にしておくと、後から追加する際の改修コストを抑えられます。
- 開発会社が「A2A対応可能です」と言えば、そのまま信頼してよいですか？
回答だけで判断せず、Agent Cardの設計やタスク委任フロー、SSEストリーミングなど具体的な実装経験を語れるか、Microsoft CopilotやSalesforce Agentforceなど具体的なベンダー名を挙げて連携可否を答えられるかを確認してください。抽象的な回答のみの場合は実装力を疑う材料になります。
- A2A対応を要件に入れると、開発コストは必ず大きく増えますか？
必ずしも増えるとは限りません。今すぐ本格実装せず、エージェントを特定ベンダーの独自機能に依存させない疎結合設計や、Agent Card相当の能力広告の仕組みを要件化するだけであれば、追加コストを抑えつつ後からA2A対応を追加する際の改修範囲を最小化できます。
- A2AはGoogleの製品でしか使えないのですか？
いいえ、A2Aは2025年6月にLinux Foundationへ寄贈されたベンダー中立の標準規格で、Microsoft・AWSなど主要クラウドもネイティブ対応しているため、特定ベンダーの製品には限定されません。
