ここ1年で、企業のAIエージェント導入は「1体のエージェントに道具を繋ぐ」段階を越えはじめた。MCP（Model Context Protocol）で社内のツールやデータに接続できるようになると、次に必ず出てくるのが「別の部署・別のベンダーが作ったエージェントと、どう連携させるか」という問いだ。homula が日々の構築で直面しているのも、まさにこの“エージェント間の境界”の設計である。
その横の連携を担う標準として急速に存在感を増しているのが A2A（Agent2Agent）プロトコル だ。n8n は2026年6月17日に A2A の仕様と実装トレードオフを掘り下げた解説を公開し（n8n Blog）、エンタープライズでの本番運用が現実の論点になっていることを示した。本稿では A2A とは何か、MCP とどう役割が違うのか、そして日本企業が導入時に握るべき統制を整理する。
A2A とは何か——Googleが生み、Linux Foundationが中立に守る標準
A2A は、異なるベンダー・フレームワークで作られた自律エージェント同士が、互いを発見し、タスクを委譲し、協調して仕事をするための共通仕様だ。Google が2025年4月9日の Google Cloud Next で発表し（Google Developers Blog）、Apache 2.0 ライセンスで公開した。その後2025年6月に Linux Foundation へ寄贈され、特定ベンダーに依存しない中立な枠組みとして運営されている（Google Developers Blog）。
発表から1年の節目（2026年4月）には、賛同組織が 50超から150団体超に拡大したと報告された。名を連ねるのは AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNow など主要プレイヤーで、サプライチェーン・金融・保険・IT運用といった領域で本番稼働に入っているとされる（Linux Foundation）。1年の更新では、暗号署名付きのエージェントカードやエンタープライズ向けのマルチテナンシーなど、本番投入の障壁を下げる強化も加えられた。
A2A は「ベンダーをまたいで AI エージェントを協働させる」ための土台だ。1社のスイートで完結しない現実——SAP・Salesforce・ServiceNow が並走する日本企業の基幹環境——だからこそ、横断の標準が効いてくる。
MCPとA2A——「縦」と「横」、2つの相互運用レイヤー
A2A はしばしば MCP と比較されるが、両者は競合ではなく役割が直交する補完関係にある。MCP が「エージェント↔ツール・データ」という縦の接続を標準化するのに対し、A2A は「エージェント↔エージェント」という横の協調を標準化する。
| 観点 | MCP（Model Context Protocol） | A2A（Agent2Agent） |
|---|---|---|
| 主眼 | 1体のエージェントが外部の道具・データにアクセス | 複数エージェントが互いに発見・委譲・協調 |
| 方向 | 縦（agent → tools / data） | 横（agent ↔ agent） |
| つなぐ相手 | ファイル・API・DB・SaaS など | 別チーム・別ベンダーのエージェント |
| 代表概念 | サーバー / ツール / リソース | エージェントカード / タスク / アーティファクト |
| 関係 | A2A の各エージェントが内部で MCP を使う | MCP で道具に繋いだエージェント群を束ねる |
実務での結論はシンプルだ。スケールするマルチエージェント基盤は両方を使う——個々のエージェントは MCP で道具と社内データに繋ぎ、それらを A2A で横に編成する。homula の構築でも、この「縦は MCP、横は A2A」の二層で設計の見通しが一気に良くなる。
仕組み：エージェントカード・タスク・アーティファクト
A2A は特別なランタイムを要求しない。トランスポートは HTTP + JSON-RPC 2.0 を基本とし、長時間タスクの進捗は Server-Sent Events（SSE） でストリーミングする。中核となる3要素を押さえておくとよい。
- エージェントカード（Agent Card）：エージェントの身元・能力（skills）・接続エンドポイント・認証要件を記述した JSON。通常
/.well-known/agent-card.jsonに公開され、他のエージェントはこれを読んで相手を発見する。エンタープライズでは中央レジストリで一元管理し、スキルやタグで検索する運用が想定される。 - タスク（Task）：A2A が管理する仕事の最小単位。一意の ID を持ち、
submitted → working → input-required → completed / failedという状態遷移をたどるステートフルな存在だ。 - アーティファクト（Artifact）：タスクの成果物（文書・データ・画像など）。複数の「パート（Part）」で構成される。
つまり A2A は「内部実装を晒さずに、能力を名乗り合い、タスクを渡し合い、成果物を返す」ための共通言語である。相手が LangGraph 製でも、Microsoft 製でも、外部 SaaS のエージェントでも、同じ手順で会話できる点に価値がある。
企業が握るべき3つの統制論点
標準が整っても、本番運用の難所は「つなげること」ではなく「安全に・統制下でつなぐこと」にある。導入時に必ず設計すべき論点を3つに絞る。
1. アイデンティティとなりすまし
A2A 通信は TLS/HTTPS で暗号化され、認証は OAuth 2.0 / OIDC / JWT といった標準に沿う。ただし仕様は資格情報の管理を実装者に委ねているため、対策を怠るとエージェントのなりすまし・カード改ざん・リプレイ攻撃が現実のリスクになる。エージェントカードに静的なシークレットを埋め込まず、署名付きカード・相互TLS（mTLS）・PKIに基づく機械アイデンティティで「相手が本物か」を機械的に検証する設計が要る。
公開されたエージェントカードに機微情報や悪意ある指示が混入すると、クライアントが更新版を取得するまで影響が続く恐れがある。エージェントカードは「公開する API 仕様書」であると同時に「攻撃面」でもある——誰が発行・更新でき、署名をどう検証するかを最初に決めること。
2. N²問題とオーケストレーション層
A2A はエージェント間の直接接続を可能にするがゆえに、素朴に組むとエージェント数の二乗（N²）で接続が膨れ上がる。依存関係や管理イベントも指数的に増え、調整が破綻しやすい——n8n が実装トレードオフとして指摘するのもこの点だ（n8n Blog）。総当たりのメッシュではなく、オーケストレーション層を1枚挟んで経路と委譲を集約するのが現実解になる。
3. 監査・承認・第三者リスク
エージェントが他のエージェントへ自律的にタスクを委譲しはじめると、「誰が・どの権限で・何を依頼し・何を返したか」を後から追える状態が前提条件になる。外部ベンダーのエージェントを呼ぶ場合は第三者リスク管理の対象であり、ID/アクセス管理、継続的な監視、監査証跡、自律判断に適応したリスク評価をセットで整える必要がある。
homula の観点——「縦はMCP、横はA2A」を統制つきで実装する
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化を一気通貫で支援している。A2A 時代の勝ち筋は、技術を入れることではなく二層を統制つきで設計し、現場に根付かせることにある。
- 縦（道具接続）は Agens：MCP を活用した統合プラットフォーム Agens は、200以上のツールと構築ゼロで接続できる。A2A で束ねる前に、各エージェントが安全に社内データへ繋がる土台をここで整える。
- 横（エージェント連携）の統制は Agens Control：A2A の3論点——なりすまし防止・承認・監査——は、そのまま Agens Control の領分だ。承認フロー・DLP・5年分の監査ログ・RBAC により、「どのエージェントが誰の権限で他のエージェントを呼べるか」を運用レベルで縛れる（Agens Control）。
- オーケストレーションは n8n / LangGraph：N²問題を避ける編成層は、homula が日常的に使う n8n / Dify / LangGraph で実装する。総当たりにせず、経路と委譲を1枚に集約する。
- 入口は AIエージェント・ブートキャンプ：業務棚卸し・プロトタイプ構築・ROI試算を 3〜5日で完結させ、「どの業務間でエージェント連携が効くか」を小さく検証してから広げる。
新しい標準そのものより、自社のエージェントが他社のエージェントとどこまで・どんな権限で会話してよいかを定義し、監査できる体制こそが差を生む。MCP の基礎はMCP（Model Context Protocol）入門も参照されたい。
まとめ
- A2A は Google 発・Linux Foundation 管理のエージェント間連携標準で、1年で150団体超に拡大し本番運用に入りつつある。
- MCP が「縦（道具・データ接続）」なら A2A は「横（エージェント協調）」。両方を使う二層設計がスケールの前提になる。
- 中核は エージェントカード・タスク・アーティファクト。HTTP + JSON-RPC + SSE で、実装を晒さず協調できる。
- 本番の難所は接続ではなく統制——なりすまし防止（署名・mTLS）／N²を避けるオーケストレーション／監査・承認・第三者リスクの3点を最初に設計する。
エージェントは「単体で賢いか」から「安全に協働できるか」へと評価軸が移った。横の連携を統制つきで設計できる企業が、マルチエージェント時代の主導権を握る。
A2A の二層設計と統制（誰が・どの権限で・どのエージェントを呼べるか）を、自社の業務に落とし込みたい方は、まず小さく検証するところから始めましょう。