AIエージェントプロトコル（MCP・A2A）とは？マルチエージェント連携の仕組みを解説

MCP（Model Context Protocol）とA2A（Agent-to-Agent Protocol）は、AIエージェントがツールや他のエージェントと連携するための通信規約だ。

マルチエージェントシステムでは、複数のエージェントが役割を分担して複雑なタスクを処理する。そのためにはエージェント間の「共通言語」が欠かせないが、仕組みを体系的に解説したリソースはまだ少なく、設計段階で判断に迷うエンジニアは多い。

本記事では、MCPとA2Aそれぞれの役割・アーキテクチャ・使い分けの判断基準を整理する。マルチエージェントシステムの設計を検討しているエンジニアや、AIエージェント連携の基礎を押さえたい方に向けて、具体的な構造とともに解説していく。

AIエージェントが単独で動作する時代から、ツール呼び出しや他エージェントへのタスク委譲まで担う時代へと移行した。この複雑な連携を成立させる「共通の取り決め」がAIエージェントプロトコルであり、代表例がMCP（Model Context Protocol）とA2A（Agent-to-Agent Protocol）だ。

かつてAI活用の主流は「単一モデルへの問答」でした。しかし業務の複雑化とともに、ファイル読み込み・外部API呼び出し・検索参照を組み合わせた一連の処理が求められるようになります。

各ツールが独自インターフェースを持っていたことで、以下の課題が生じました。

• AIと外部システムをつなぐたびに個別のアダプター実装が必要
• あるチームのコネクターが別チームで再利用できない
• 同様の実装が組織内で重複・増殖する

さらに、AIエージェントが複数ツールを自律的に呼び出したり、別のエージェントへタスクを委譲したりするマルチエージェントシステムが現実的な選択肢になったことで、問題の次元が変わりました。単なる「APIの呼び方の違い」ではなく、エージェント同士が意図やタスク状態をどう共有するかという、より深いレベルの合意が必要になってきたのです。こうした背景から、共通仕様を定める動きが業界全体で加速しています。

「ツール呼び出し（Function Calling）」と「エージェント間通信」は混同されやすいですが、役割がまったく異なります。MCPとA2Aの使い分けは、この区別が土台になります。

ツール呼び出しは、エージェントが外部機能に処理を依頼する操作です。ウェブ検索・DB参照・カレンダー登録などが典型例で、ツール側は意思決定を行わず決まった処理を返すだけです。

エージェント間通信は、相手もまた推論・判断・計画を行えるエージェントです。タスクの委譲・進捗報告・中間フィードバックといった双方向のやり取りが発生します。

両者の主な違いは以下のとおりです。

• 自律性: ツールは受動的に動作し、エージェントは自ら判断して行動する
• 状態保持: ツール呼び出しはステートレスが基本、エージェント間通信はセッションや文脈が維持されうる
• 通信方向: ツールは一方向、エージェント間通信は非同期・双方向になりうる

この区別が、次以降で解説するMCPとA2Aの役割分担に直結します。

AIエージェントの活用が広がるほど、ツール間の「つなぎ目」の設計コストが課題として浮き彫りになる。個々のエージェントが高性能でも、連携の仕組みがバラバラなままではシステム全体の生産性は伸び悩む。標準化が注目される理由は、まさにこの点にある。

複数のAIツールを並行導入すると、連携のたびに専用のグルーコードを書く必要が生じる。各ツールが独自のAPIスキーマ・認証方式・データ形式を持つためで、これが「AIツールのサイロ化」だ。

サイロ化が引き起こす主な問題は3点ある。

• 統合コストの増大: ツール数が増えるほど、ペアワイズ統合の組み合わせは急増する。管理すべき接続コードの量も比例して膨らむ傾向がある
• コンテキストの断絶: 共通フォーマットがない状態でエージェント間に情報を渡すと、変換ミスや情報欠落が起きやすい。後続エージェントが誤った前提で動作し、エラーが連鎖するリスクが高まる
• 保守・監視の困難さ: 独自実装の接続コードはツールのバージョンアップのたびに修正が必要になる。標準化されたログ形式がなければ、障害原因の特定も難しい

単一ツールの時代には許容できた「個別対応」のアプローチが、マルチエージェントシステムでは技術的負債として積み上がっていく。プロトコル標準化の議論は、こうした現場の痛みを背景に生まれている。

標準プロトコルが整備されると、「一度作った連携をどこでも再利用できる」恩恵が生まれる。USB規格の統一が「つなぐだけで動く」状態をもたらしたように、AIエージェントの世界でも同様の変化が進みつつある。

主なメリットは以下の3点だ。

• 開発コストの削減: 標準インターフェースに準拠したアダプターを一度用意すれば、対応ツールが増えても同じ呼び出し方で統合できる。個別にグルーコードを書き続ける手間が減る
• エコシステムの拡大: 仕様が公開されると、ツールベンダーやOSSコミュニティが独自コネクターを開発・公開するようになる。MCP仕様の公開後、サードパーティ製サーバー実装が短期間で複数登場したのはその好例だ
• デバッグ・監視のしやすさ: 通信フォーマットが統一されるとログ構造が一貫し、どのツール呼び出しでエラーが発生したかをトレースしやすくなる

ただし、相互運用性のメリットを享受するには「プロトコル準拠の実装を維持し続ける」前提がある。仕様バージョンアップへの追従やセキュリティ対応は、標準化後も継続的に求められる点として押さえておきたい。

MCP（Model Context Protocol）は、AnthropicがオープンソースとしてリリースしたAIモデルと外部ツール・データソースをつなぐ接続規格だ。アーキテクチャの構造から実際の連携例まで、順を追って解説する。

MCPは「ホスト」「クライアント」「サーバー」の3層で構成され、役割を明確に分離した設計が特徴です。

• ホスト: ユーザーが操作するアプリケーション層。Claude DesktopやVS Code拡張など、AIアシスタントが動作する環境そのもの
• クライアント: ホスト内に組み込まれ、JSON-RPCベースでサーバーと通信する仲介役。ツールの一覧取得・呼び出し・結果受け取りを担う
• サーバー: ファイルシステム・外部API・データベースなど、実際のツールやデータソースへのアクセスを提供する層

重要なのは、サーバーが呼び出し元のホスト内部を知らなくてよい点です。MCP仕様に沿ったレスポンスを返すだけで、どのホストからの呼び出しにも対応できます。

通信の流れは次の順序で進みます。ホストがタスクを受け取り、クライアントがサーバーへツール一覧をリクエスト。LLMが使用ツールを判断し、クライアントが呼び出しを送信、サーバーが結果を返します。起動時のケイパビリティ交換により、ホストは接続先のツール構成を動的に把握できます。

MCPが対応できる範囲を把握しておくと、設計時の認識ずれを防ぎやすくなります。

MCPでできること

• ツール呼び出し（Function Calling）: ファイル読み書き・DBクエリ・外部API呼び出しを「Toolsプリミティブ」として定義し、モデルが動的に呼び出せる
• リソース提供: ファイルやドキュメントなどの静的コンテキストを「Resourcesプリミティブ」でモデルへ渡せる
• プロンプトテンプレート管理: 「Promptsプリミティブ」でよく使う指示をサーバー側で一元管理し、再利用できる

MCPでできないこと

MCPはモデルとツール・リソースをつなぐ「縦の通信」に特化したプロトコルです。複数のAIエージェント同士がタスクを委譲し合う「横の通信」には対応していません。

セッション管理や長期タスクの状態保持もMCPの担当外であり、アプリケーション側で別途設計が必要です。MCPは「ツール接続のインターフェース標準」として位置づけるのが適切です。

Claude CodeはAnthropicが提供するコーディング特化のAIエージェントです。MCPを通じて外部ツールと接続することで、ファイルシステムの読み書き・シェルコマンド実行・Gitリポジトリ操作などをエージェントから直接呼び出せます。

実際の動作イメージは次のとおりです。

• 「失敗したテストだけ修正して」という指示に対し、MCPサーバー経由でファイル参照→テスト実行→結果受信→コード修正を自律的に処理
• 各操作がツール定義に従って構造化されるため、「何をどう呼び出すか」が明示的に宣言できる

OpenClawはMCPのオープンソース実装の一つで、MCPサーバーの構築・管理を簡略化するために設計されています。既存のAPIエンドポイントをMCPツールとしてラップし、Claude Codeをはじめとする対応クライアントから呼び出せる形に変換できます。

どちらの連携でも鍵になるのがツール定義の精度です。ツール名・パラメータ・説明文が曖昧だと、エージェントが誤った呼び出しを行うリスクが高まる傾向があります。スキーマを丁寧に記述することが、意図通りの動作を引き出す近道です。

MCPがAIとツールをつなぐ「縦の接続」なら、A2A（Agent-to-Agent Protocol）はエージェント同士をつなぐ「横の接続」です。異なるフレームワーク間でのタスク委譲・実行・報告の仕組みを以下で解説します。

A2A（Agent-to-Agent Protocol）はGoogleが提唱したオープン仕様で、「エージェント同士が対等に通信できる共通言語を作る」思想を根底に持ちます。MCPがAIとツールをつなぐのに対し、A2Aはエージェント自体を通信の主体として扱う点が特徴です。

設計の核心はAgent Cardと呼ばれるJSON形式のメタデータです。以下の情報が記述されます。

• 対応するスキルの種類
• 受け付けるエンドポイント
• 対応する認証方式

呼び出し側はまずAgent Cardを取得し、相手の能力を確認してからタスク委譲を判断します。いわば「自己紹介カードを交換してから仕事を依頼する」流れです。

タスク委譲はHTTP経由でタスクオブジェクトを送信して開始し、処理が長引く場合はServer-Sent EventsやWebSocketでストリーミング配信します。テキスト・ファイル・構造化データを混在させたマルチパートメッセージにも対応しています。

仕様はまだ新しいため、採用時は公式ドキュメントで最新の更新動向を確認することを推奨します。

エージェントオーケストレーションとは、複数のAIエージェントにサブタスクを割り当て、成果物を統合して全体目標を達成する仕組みです。A2Aはこの「委譲と応答」の流れを標準化します。

A2Aがオーケストレーションで担う主な機能は以下の通りです。

• オーケストレーターがAgent Cardを参照し、適切なスペシャリストエージェントを選択する
• タスク内容と期待する出力形式を指定してリクエストを送信する
• submitted → working → completed のステータス管理で長時間タスクの進捗を追跡する

内部実装を互いに知らなくてよいため、異なるフレームワークや言語で構築されたエージェント同士でも連携できる点が大きな強みです。

一方、タスクの粒度が細かすぎると委譲のオーバーヘッドが積み重なり、処理が遅くなる傾向があります。どこまでを1つのエージェントが担い、どこから委譲するかという境界設計が、パフォーマンスと保守性を左右します。

MCPとA2Aは「通信の粒度」が根本的に異なります。ツールを呼び出すのかエージェントにタスクを委譲するのかという設計判断が、どちらを選ぶかの分かれ目になります。

判断の起点は「実行の主体が変わるかどうか」です。

MCPを選ぶ場合：

• データベース検索・ファイル操作・外部API呼び出しなど、1ステップで完結するアクション
• エージェントが指揮権を手放さず、ツール結果を受け取って自ら判断を続ける場合

A2Aを選ぶ場合：

• タスクの所有権ごと別エージェントへ移譲する場合
• 実行中に追加の意思決定が発生する可能性がある場合
• 呼び出し先が会話履歴や中間成果物などの状態を保持する必要がある場合

両者は競合しません。A2Aで委譲を受けたサブエージェントが、自身のタスクを遂行するためにMCPでツールを呼び出す階層構造は自然に生まれます。「A2Aで役割を分け、MCPで能力を補う」というイメージが、設計の見通しを立てやすくします。

マルチエージェントシステムの代表的な設計パターンと、MCP・A2Aの対応関係を整理します。

オーケストレーター／ワーカー型 中央エージェントが複数ワーカーにタスクを割り振る構成。オーケストレーター→ワーカーへの指示にA2A、各ワーカーが外部ツールを使う際にMCPという二層構造が自然にフィットします。責務の分離が明確にしやすく、導入の出発点として扱いやすい傾向があります。

パイプライン型 エージェント間の受け渡しにA2Aを使いつつ、各ステップでの外部データアクセスをMCPが補完します。処理が単純なデータ変換のみであれば、MCPだけで完結するケースもあります。

フラット協調型 A2Aの設計思想と最も親和性が高いパターンです。対等なエージェント同士がAgent Cardを参照しながら動的にタスクを委譲し合い、個別のツールアクセスはMCPが担います。柔軟性が高い反面、どのエージェントがどの判断をしたか追跡しづらくなる点に注意が必要です。

MCPやA2Aを実運用に持ち込む際、機能設計と同様にセキュリティ設計が不可欠です。外部ツール呼び出しやエージェント間のタスク委譲経路は、そのままアタックサーフェスになり得るため、適切な対策が求められます。

MCPやA2Aを通じた外部連携では、プロンプトインジェクション（Prompt Injection）が現実的な脅威です。悪意あるテキストがツール出力に紛れ込み、LLMの挙動を書き換える攻撃手法で、マルチエージェント構成では汚染された出力が次のエージェントへ連鎖しやすい点に注意が必要です。

対策の基本は、ガードレール（AI Guardrails）を入力・出力の二層で設計することです。

• 入力側: 外部取得コンテンツを「信頼できないデータ」として扱い、システムプロンプトと明示的に分離する
• 出力側: エージェントが実行しようとするアクションを許可リストと照合し、リスト外の操作を自動ブロックする

加えて最小権限の原則も重要です。読み取り専用タスクに書き込み権限を付与しないなど、MCPサーバーのスコープ設計やAgent Skillsの定義段階から権限の粒度を絞ることで、ガードレールの実効性が高まります。

マルチエージェント環境では、認証・認可の設計を後回しにしがちです。しかし「誰が・どのリソースに・どの権限でアクセスできるか」を曖昧にすると、意図しない権限昇格やツール呼び出しが発生するリスクがあります。

A2A仕様では、エージェント間の認証手段としてOIDC トークン（OIDC Token）の利用が想定されています。オーケストレーターがサブエージェントにタスクを委譲する際、JWTベースのトークンをリクエストヘッダーに付与することで、受け取り側が呼び出し元の正当性を検証できます。MCPサーバーへのアクセス制御にも同様のアプローチが有効です。

実装時に見落とされやすいポイントは以下の3点です。

• 有効期限管理: 長時間稼働するワークフローではタスク中にトークンが失効するケースがある
• 自動更新フロー: リフレッシュトークンの更新処理をエージェントのライフサイクルに組み込んでおく
• 最小権限の原則: エージェントごとにスコープを絞り、不要な権限を持たせない

ロールベースの権限設計は初期段階で固めておくと、後からの手戻りを大幅に減らせます。

MCPやA2Aへの関心が高まる一方、現場では的外れな思い込みも散見されます。よく聞かれる2つの誤解を、ここで整理しておきます。

MCPはREST APIやGraphQLの「置き換え」ではなく、役割がそもそも異なります。

既存APIはアプリケーション間のデータ交換を担う汎用インターフェースです。MCPは、AIエージェントが「どのツールを使えるか」「どう呼び出すか」をLLMが解釈できる形式で記述・伝達することに特化しています。

実装上の関係を整理すると、次のようになります。

• 既存のAPIエンドポイントはそのまま残す
• MCPサーバーがAPIの上に薄いラッパーとして乗る
• エージェントとの接点だけを標準化する

たとえばGitHubのAPIを活用する場合、API自体を書き直すのではなく、「リポジトリを検索する」「PRを作成する」といった操作をエージェントが解釈しやすいツール定義として記述し直す作業が中心になります。

この誤解を放置すると、MCPとAPIの二重管理という無駄なコストが生じやすくなります。MCPはAPIを補完するアダプター層として位置づけるのが、現実的な導入アプローチです。

「A2Aは特定のLLMやフレームワークに縛られた仕様ではないか」という先入観は、よく見られる誤解のひとつです。

A2AはHTTPベースのJSONメッセージで通信が成立する設計を採用しており、内部で動くLLMの種類を問いません。主なポイントは以下のとおりです。

• GPT・Gemini・Claudeやオープンウェイトモデルなど、異なるバックエンドを持つエージェント同士でもAgent Cardの仕様に沿えば相互通信が可能
• オーケストレーター側は相手のモデル実装を意識せず、タスクの入出力インターフェースだけを見て委譲を判断できる
• コスト・精度・レイテンシの観点から複数モデルを使い分けるマルチベンダー環境を強く意識した設計

ただし「モデルに依存しない」ことと「どんな環境でもそのまま動く」ことは別です。Agent Cardの記述精度や各エージェントの実装品質によって、タスク委譲の成否は変わります。プロトコルは共通言語を提供しますが、それを正しく活用できるかどうかは実装側の責任です。

MCPの概念を理解したら、実際に手を動かして体感するのが理解を深める近道です。ローカル環境でのサーバー起動手順と、Agent Skillsの定義・テスト方法を順に解説します。

ローカルでMCPを試すなら、Python SDKを使った最小構成が出発点として適している。

起動までの流れ

• Python 3.10以上の環境を用意し、pip install mcp でSDKをインストール
• @mcp.tool() デコレータを付けた関数を定義すると、ツールとして自動登録される
• python server.py でサーバーを起動。デフォルトのトランスポートは stdio（標準入出力）

動作確認のコツ

起動後は公式CLIツール MCP Inspector を使うと、ブラウザ上でツール一覧の確認や手動呼び出しができる。「設定は正しいはずなのに応答がない」という初期トラブルの切り分けに有効だ。

ホストアプリとの接続

Claude Desktopなどのホストアプリと繋ぐには、設定ファイルに起動コマンドとパスを記述するだけで認識される。まずstdioで疎通を確認し、必要に応じてHTTP+SSE方式へ移行する順序が、問題の特定をしやすくする観点から現実的な進め方といえる。

MCPサーバーが起動したら、Agent Skills の定義に進みます。スキルはエージェントが外部から呼び出せる機能の単位で、以下の3要素で構成されます。

• 名前: ルーティング時の識別子
• 説明文: LLMが「いつ使うべきか」を判断する根拠
• 入出力スキーマ: JSON SchemaまたはPydanticモデルで型を明示

説明文は「何ができるか」だけでなく「どんな場面で使うべきか」まで記載すると、オーケストレーターの選択精度が上がります。説明が曖昧なままだと、タスク委譲の誤選択につながる傾向があります。

テストは2段階で進めると整理しやすいです。

1. 単体テスト: curl やPythonの httpx でMCPエンドポイントに直接リクエストを送り、レスポンスの型・エラーハンドリングを確認する
2. 統合テスト: テスト用プロンプトを使い、LLMが正しいスキルを選択してパラメータを埋め、結果を解釈できるかを一連の流れで検証する

スキル数が増えたら、説明文が互いに似すぎていないか定期的に見直すことも重要です。類似した説明文は誤選択の温床になります。

MCPやA2Aを学ぶ中で「既存の仕組みと何が違うのか」という疑問は自然に湧く。実務でとくに挙がりやすい2つの質問に絞って整理する。

ツール呼び出し（Function Calling）は、LLMが「この関数を実行してほしい」という意図をJSON形式で出力し、アプリ側が処理する仕組みだ。各LLMプロバイダーが独自に実装しているため、スキーマ定義やエラーハンドリングの仕様はプロバイダーごとに異なる。

MCPとの主な違いは以下の3点にまとめられる。

• 独立レイヤーの有無: MCPはツール定義・通信・認証をLLMプロバイダーから切り離して標準化。Claude・GPT・Geminiなど対応ホストから同一インターフェースで呼び出せる
• ステート管理: Function CallingはリクエストごとにステートレスだがMCPはセッションを維持し、複数ターンにわたる状態保持が設計上考慮されている
• スキーマの再利用性: Function Callingではプロバイダーごとにスキーマを書き直す必要があるが、MCPではその手間が大幅に減る傾向がある

両者は競合しない。MCPホストの内部でFunction Callingを使ってMCPサーバーへの呼び出しを生成するケースも多く、実態は補完的な関係だ。「LLMが何を呼ぶかを伝える手段」がFunction Calling、「ツールをどう提供・管理するかの共通基盤」がMCPと整理すると理解しやすい。

チーム規模よりも「何をやらせたいか」で判断するのが適切だ。A2Aが本領を発揮するのは、複数の専門エージェントが並列・連鎖して動く場面に限られる。

A2Aを検討すべきケース

• 「調査→要約→レポート生成」のように工程ごとに別エージェントを分担させたい
• エージェントが別のエージェントへ指示を出す必要がある
• 人間の承認なしにタスクを引き継がせたい

MCPで十分なケース

• 単一エージェントが外部ツールを呼び出すだけで業務が完結する
• 設計・運用リソースが限られている

A2Aを導入すると、Agent Skillsの定義やタスク状態管理など運用の複雑さが増す傾向がある。小規模チームでは維持コストが見合わないケースも報告されている。上記の判断軸でいずれかにYesと答えるなら設計を視野に入れ、そうでなければMCP環境の安定を優先し、A2Aは将来の拡張オプションとして温めておくのが現実的な選択といえる。

ここまでの内容を3つのポイントに整理します。

ポイント1：MCPは「エージェントとツールをつなぐ共通言語」

MCPが解決するのは、AIエージェントが外部ツールやデータソースを呼び出す際の接続コストです。一度MCPサーバーを実装すれば、対応するあらゆるエージェントからそのツールを再利用できます。

ポイント2：A2Aは「エージェント同士が協調するための作法」

MCPがツール呼び出しの縦の連携を担うとすれば、A2Aはエージェント間の横の連携を可能にします。特定のLLMや実行環境に縛られない設計思想が、マルチエージェントシステムの柔軟なスケールアップを支えます。

ポイント3：セキュリティと設計は後回しにできない

プロトコルを導入するほどシステムの攻撃対象領域は広がります。OIDCトークンによるアクセス制御とAIガードレールの設定は、パフォーマンスチューニングと同等かそれ以前に検討すべき事項です。

仕様はまだ進化の途上にあります。まずローカル環境でMCPサーバーを一つ動かしてみることが、抽象的な概念を実感に変える近道です。