MCPだけじゃ足りない？ エージェント同士が「会話」する時代
ミドリ(nodding)： タツヤさん、前にMCP（Model Context Protocol）について教えてもらったじゃないですか。あれで「AIがツールを使える」ってのはわかったんですけど、最近GoogleのA2Aってプロトコルが話題ですよね。
タツヤ： よく追ってるね。A2Aは2025年4月にGoogleが発表して、2025年後半にv1.0が正式リリースされた。2026年に入ってからは企業導入が本格化してる。
ミドリ： MCPとA2A、何が違うんですか？ 似たようなものに見えるんですけど。
タツヤ： 全然違う。たとえで言うと、MCPは「USB-C」、A2Aは「インターネット」。USB-Cはデバイスに周辺機器を接続する規格。インターネットはデバイス同士が通信する規格。レイヤーが違うんだよ。
MCPとA2Aの根本的な違い
ミドリ(thinking)： もう少し具体的に教えてください。
タツヤ： こう整理するとわかりやすい。
| 項目 | MCP（Anthropic） | A2A（Google） |
|---|---|---|
| 目的 | エージェントがツール・データにアクセス | エージェント同士が連携 |
| 関係性 | エージェント → ツール（上下関係） | エージェント ↔ エージェント（対等） |
| 通信パターン | リクエスト/レスポンス | 双方向・非同期・ストリーミング |
| 発見メカニズム | なし（事前設定） | Agent Card（自己紹介） |
| 状態管理 | なし | タスク単位で状態管理 |
| 認証 | トランスポート層に依存 | OAuth 2.0 / OpenID Connect標準 |
| 長時間タスク | 非対応 | ネイティブ対応 |
| 人間の介入 | なし | 承認フロー組み込み可能 |
| 標準化団体 | — | Linux Foundation AAIF |
ミドリ： あ、対等関係ってのがポイントですね。MCPは「親分がツールを使う」けど、A2Aは「エージェント同士が対等に協力する」。
タツヤ： 鋭い。たとえば営業エージェントが「このリードの信用調査して」ってリスク分析エージェントに依頼する。リスク分析エージェントは独立して動いていて、社内の信用データベースにアクセスして結果を返す。これがA2Aの世界。
A2Aのアーキテクチャ
ミドリ： A2Aの仕組みを詳しく知りたいです。
タツヤ： A2Aには4つの核心コンセプトがある。
1. Agent Card（エージェントの名刺）
タツヤ(smiling)： これが一番画期的な概念だと思う。各エージェントは /.well-known/agent.json にJSON形式の自己紹介を公開する。
ミドリ： 自己紹介？
タツヤ： 「自分は何ができるか」「どんなデータを扱えるか」「認証方法は何か」を機械可読な形式で宣言する。ちょうどWebサイトの robots.txt みたいなものだね。
ミドリ(nodding)： なるほど、他のエージェントがAgent Cardを読んで「このエージェントに頼めるな」って判断できるわけか。
タツヤ(nodding)： その通り。人間がAPIドキュメントを読んでコードを書く必要がなくなる。エージェントが自動的に適切な相手を見つけて連携できる。
2. タスク管理
タツヤ： A2Aのやり取りは「タスク」単位で管理される。タスクには明確なライフサイクルがある。
- submitted — タスク送信済み
- working — 処理中
- input-required — 追加情報が必要
- completed — 完了
- failed — 失敗
- canceled — キャンセル
ミドリ： input-required が面白いですね。途中で「ここ確認させて」って聞き返せるんだ。
タツヤ(smiling)： そう。これが実務では超重要。「この契約書を翻訳して」→「法務レビューも必要ですか？ コスト追加になりますが承認しますか？」みたいなやり取りが自然にできる。
3. メッセージとパート
タツヤ： エージェント間のやり取りは「メッセージ」で行われて、各メッセージは複数の「パート」を含められる。テキスト、ファイル、構造化データを一度に送れる。
4. ストリーミング（SSE）
タツヤ： 長時間かかるタスクの場合、Server-Sent Events（SSE）でリアルタイムに進捗を返せる。5分かかる分析タスクが終わるまでじっと待つ必要がない。
実践ユースケース
ミドリ(nodding)： 理論はわかりました。実際どういう場面で使うんですか？
タツヤ： 3つの代表的なユースケースを見てみよう。
ユースケース1：サプライチェーンのマルチエージェント
タツヤ： 製造業での例。
- 需要予測エージェント — 過去データと外部要因から需要を予測
- 在庫管理エージェント — 現在の在庫状況を把握
- 発注エージェント — サプライヤーへの発注を実行
- 物流エージェント — 配送の最適化
タツヤ： これまでは4つのシステムを人間が橋渡ししてたのが、A2Aで自動連携する。需要予測エージェントが「来月の需要が30%増加」→在庫管理エージェントが「現在在庫では不足」→発注エージェントが「サプライヤーXに追加発注」→物流エージェントが「配送スケジュール調整」。全部自動で回る。
ミドリ： 人間は最終承認だけすればいいんですか？
タツヤ： タスクの input-required 状態を使って、金額が一定以上の発注だけ人間に承認を求める設計にできる。
ユースケース2：カスタマーサポートの多段階処理
タツヤ： 顧客から「注文した商品がまだ届かない」って問い合わせが来たケース。
- フロントエージェント — 問い合わせ内容を解析、注文番号を特定
- 配送追跡エージェント — 物流システムから配送状況を取得
- 補償判定エージェント — 遅延日数に基づいて補償ポリシーを確認
- 対応実行エージェント — 顧客への回答を生成し、必要なら返金処理
ミドリ： 今までコールセンターのオペレーターが4つのシステムを画面切り替えながらやってた作業が全部つながるわけか。
タツヤ： 対応時間が平均12分→2分に短縮された事例も報告されてる。
ユースケース3：採用プロセスの自動化
タツヤ： HR領域でも注目されてる。
- 書類選考エージェント — 履歴書と求人要件のマッチング
- スケジューリングエージェント — 面接官と候補者のカレンダー調整
- バックグラウンドチェックエージェント — 外部サービスと連携した経歴確認
- オファー生成エージェント — 市場データに基づく報酬パッケージの提案
Linux Foundation AAIFと標準化の動き
ミドリ： A2AってGoogleだけのものなんですか？
タツヤ： 最初はGoogleが主導したけど、2025年末にLinux Foundationの傘下にAAIF（AI Agent Interoperability Forum）が設立されて、業界標準としての地位を固めた。
ミドリ： どんな企業が参加してるんですか？
タツヤ： 主要メンバーを見ると本気度がわかるよ。
| カテゴリ | 参加企業 |
|---|---|
| クラウド | Google Cloud, AWS, Microsoft Azure |
| LLMプロバイダ | Anthropic, OpenAI, Cohere |
| エンタープライズ | Salesforce, SAP, ServiceNow |
| SIer | Accenture, Deloitte, Capgemini |
| プラットフォーム | LangChain, CrewAI, AutoGen |
ミドリ： AnthropicもMicrosoft も入ってるんですね。MCPと競合してるのに？
タツヤ： 競合じゃないからね。MCPとA2Aは補完関係。Anthropicは「エージェントがツールを使うにはMCP、エージェント同士の連携にはA2A」って公式に述べてる。両方のプロトコルが共存する設計なんだ。
MCPとA2Aの共存アーキテクチャ
ミドリ(thinking)： 具体的にどう共存するんですか？
タツヤ： 実装パターンを見せよう。
┌─────────────────────────────────────────┐
│ マルチエージェントシステム │
│ │
│ ┌──────────┐ A2A ┌──────────┐ │
│ │営業 │◄─────────►│分析 │ │
│ │エージェント│ │エージェント│ │
│ └────┬─────┘ └────┬─────┘ │
│ │ MCP │ MCP │
│ ┌────▼─────┐ ┌────▼─────┐ │
│ │CRM │ │BIツール │ │
│ │Slack │ │データベース│ │
│ │メール │ │API │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────┘タツヤ： 横方向（エージェント間）はA2A、縦方向（エージェント→ツール）はMCP。役割が明確に分かれてるから干渉しない。
ミドリ： きれいに棲み分けてますね。
企業がいま準備すべきこと
ミドリ： A2Aの導入って、企業はいつ頃から考えればいいんですか？
タツヤ： タイムラインを整理しよう。
| 時期 | フェーズ | やるべきこと |
|---|---|---|
| 2026年前半 | 学習・検証 | A2Aの仕様理解、PoC構築 |
| 2026年後半 | 初期導入 | 社内の2〜3エージェント間連携 |
| 2027年 | 本格展開 | 部門横断のマルチエージェントシステム |
| 2028年〜 | エコシステム | 企業間エージェント連携 |
ミドリ： 今はまだ「学習・検証」フェーズなんですね。
タツヤ： そう。ただし「2027年から考えよう」だと遅い。A2Aに対応するには前提としてMCPでエージェントがツールを使える状態になってないといけない。つまり今やるべきは以下の3つ。
1. 社内業務のエージェント化ロードマップ作成
タツヤ： 「どの業務をエージェントに任せられるか」をリストアップする。一番手は定型的な業務プロセス。経費精算、レポート生成、顧客問い合わせの一次対応あたりだね。
2. MCPインフラの整備
タツヤ： 社内ツールのMCPサーバー化を進める。データベース、CRM、プロジェクト管理ツール。エージェントがこれらにアクセスできる基盤がないと、A2Aで連携しても意味がない。
3. Agent Card設計の検討
タツヤ： 将来的にエージェントを外部に公開するなら、Agent Cardの設計が重要になる。自社のエージェントが「何をできて」「どのデータにアクセスでき」「どんな認証が必要か」を定義する。API設計と同じ発想で取り組むといい。
ミドリ(smiling)： API設計の経験がそのまま活きるのは嬉しいですね。
セキュリティとガバナンス
ミドリ： エージェント同士が勝手に連携するって、セキュリティ的に怖くないですか？
タツヤ(nodding)： いい質問。A2Aは最初からエンタープライズのセキュリティ要件を織り込んで設計されてる。
- 認証 — OAuth 2.0 / OpenID Connectによるエージェントの身元確認
- 認可 — Agent Cardで公開するスコープを制限できる
- 監査ログ — 全タスクのやり取りがトレース可能
- 人間の承認フロー — 重要な意思決定には人間の承認を挟める
- レート制限 — エージェント間のリクエスト頻度を制御
ミドリ： 人間がちゃんと監督できる設計になってるんですね。
タツヤ： 「AIに任せきり」じゃなくて「AIに任せつつ人間が監督する」。これがエンタープライズAIの大原則だよ。
まとめ：マルチエージェント時代のインフラが整った
ミドリ： 今日の話をまとめるとどうなりますか？
タツヤ： 3つに集約できる。
- MCPとA2Aは競合ではなく補完関係。 MCPはエージェント→ツール、A2Aはエージェント→エージェント。両方揃って初めてマルチエージェントシステムが成立する
- A2Aの最大の革新はAgent Card。 エージェントが自分の能力を機械可読な形で公開する仕組みにより、動的なエージェント発見と連携が可能になった
- 今すぐA2Aを導入する必要はないが、準備は今日から。 まずMCPで社内ツールのエージェント対応を進め、エージェント化する業務のロードマップを作ること
ミドリ： 結局、「エージェントが当たり前の世界」に向けて基盤を整えておくのが大事なんですね。
タツヤ： そういうこと。A2Aの登場で、マルチエージェントの「プロトコル」は揃った。あとは「何を」「どう」エージェント化するかっていう業務設計の勝負。技術ではなくビジネス理解が差別化要因になるよ。
次のアクション
マルチエージェント時代への準備を始めましょう。
- A2Aの公式ドキュメント（google.github.io/A2A）でAgent Cardの仕様を確認する
- 自社の業務プロセスで「エージェント同士が連携すると効率化できる」領域を3つ挙げてみる
- MCP/A2Aを活用したマルチエージェント設計のご相談は、Shimanto AI SolutionsのAIアーキテクチャコンサルティングへ