AIエージェントの仕様地図｜MCP・A2A・Agentic AIをどう切り分けるか

AIエージェント領域では、覚えた知識の一部が数か月で腐ります。今日読んだ仕様のうち、どれが半年後もそのまま使える地図で、どれが参照した瞬間から古くなっていく時価情報なのか。この線引きを最初にやらないまま情報を集めると、対応クライアント一覧やleaderboard順位のような時価情報まで、MCPやA2Aの役割分担と同じ重みで記憶してしまいます。

本記事は、姉妹記事にあたる「AIエージェント開発に役立つ一次文献11選」と役割を分けています。あちらは「どの一次文献を読むか」の選定を担い、本記事はMCP・A2A・Agentic AIという3つの語彙を、レイヤー地図として固定する側を担当します。読む対象を選ぶ記事と、選んだ後にどう位置づけるかを決める記事、という組み合わせです。

“

この記事の前提

• 2026-04-14時点で確認しやすい公式docs/公式blog/公式leaderboardを優先して書いています
• MCP・A2A・Agentic AIの役割分担はレイヤー地図として固定して読んでよい部分、対応クライアントやleaderboard順位は参照のたびに引き直すべき時価情報として扱います

結論

・監査を先に固め、A2Aは観測に留める

私は、2026年時点でこれからAIエージェント導入を検討する企業は、A2A・マルチエージェント構成を実装対象から外し、MCPによる接続整理と承認・監査ログの設計だけを先に固めるべきだと考えています。

A2Aは2025年6月にLinux Foundation配下のプロジェクトへ移管され、単一企業の提唱から中立ガバナンスの標準化プロジェクトへ移行しつつあると見るのが自然です(詳しくは後述します)。観測する価値は明確に上がりました。ただし、仕様とSDKがまだ動いている段階のプロトコルの上に、複数エージェントが権限を委譲し合う構成を組むのは、権限管理の負債を先に積み上げる順序だと思っています。

この立場には境界があります。すでに複数エージェントを並列運用しているチームや、標準化プロジェクトにベンダー側の当事者として関わっている立場には当てはまりません。そういうチームは、観測ではなくとっくに実装のフェーズにいるはずです。逆に、これから検討を始める企業であれば、事業規模の大小にかかわらず同じ順序が成り立つと考えています。小さく始めるべきなのは中小企業だけの話ではなく、複数エージェントを扱う組織全般に共通する話です。

前提

、時価の情報

この記事では2つの言葉を道具として使います。

レイヤー地図とは、MCPは外部への接続、A2Aはエージェント間の協調、Agentic AIは計画・実行・再計画の振る舞い、という役割分担の地図です。数か月で仕様が変わっても、この役割分担そのものが崩れることは考えにくく、固定して覚えてよい知識として扱います。

時価情報とは、leaderboardの順位、対応クライアントの一覧、SDKの構成など、参照した時点を添えないと意味を持たない変動値です。覚える対象ではなく、参照するたびに引き直す手順だけを決めておく対象として扱います。

この2つを道具に、MCP・A2A・Agentic AIをそれぞれ一行で定義しておきます。反論できる形にしておくことが目的なので、異論があれば歓迎です。

• MCP: AIアプリケーションが外部のツールやデータへ接続するための、クライアント-サーバー型のプロトコル
• A2A: 異なるエージェント同士が能力を発見し、タスクを委譲し、結果をやり取りするためのプロトコル
• Agentic AI: 特定の製品名ではなく、目標に対して計画し、実行し、結果を見て再計画するという振る舞いを指す設計パターン

全体像

・協調・振る舞い・横串の4層

2025年AIエージェント研究トレンド概念図

3つのプロトコル・概念と、それを横断するガバナンス・評価を1枚の表に集約すると、以降の節で何を固定して読み、何を引き直して読むべきかが先に見えます。

以降の節は、この表の4行をそれぞれ掘り下げます。

MCP

MCP(Model Context Protocol)は、Anthropicが2024年11月に公開したオープンプロトコルです。AIアプリケーションが外部のツールやデータソースへ、一貫した形で接続できるようにすることを狙っています。

MCPは3つの核心概念で整理されています。API呼び出しや外部機能の実行を担うTools、ファイルやデータベースなど外部情報の取得を担うResources、再利用しやすいテンプレートの共有を担うPromptsです。

[AI Application] <---> [MCP Client] <---> [MCP Server] <---> [External Service]

クライアントとサーバーを分離するこの構造は、AIアプリ側の実装と外部サービス側の実装を切り離せるという利点につながります。ここまでがレイヤー地図、つまり固定して読んでよい部分です。

エコシステムの見方

ここから先は時価情報です。MCP公式サイトでは、Claude、ChatGPT、Cursor、Visual Studio Codeなど複数のクライアント/サーバー実装が案内されていますが、この一覧は今後も増減します。重要なのは「MCP対応」という一言よりも、Toolsだけ使えるのか、Resourcesや認証フローまで揃っているのか、ローカルMCPとリモートMCPのどちらを想定しているのか、という実装範囲です。「MCP対応済み」という看板は、導入判断の材料としては粗すぎます。

MCPが重要なのは、ツール連携をベンダー固有実装から切り離せること、モデル呼び出しと外部接続ロジックを分離できること、権限・接続先・監査対象をひとまとめに整理できることの3点です。ただしMCPは「何でもすぐつながる魔法の規格」ではありません。ツール接続を整理するための共通インターフェース、という程度に捉えておくほうが実務では扱いやすくなります。

A2A

、しかしまだ組む対象ではない

A2A(Agent-to-Agent Protocol)は、Googleが2025年4月に公表したオープンプロトコルです。狙いは、異なるエージェント同士が能力を発見し、タスクを委譲し、結果をやり取りできるようにすることです。

2025年6月には、GoogleがA2Aの仕様・SDK・開発ツール群をLinux Foundation配下のAgent2Agentプロジェクトへ移管したと公表しました。単一企業の提唱段階から、中立ガバナンスを持つ標準化プロジェクトへ移行しつつあると見るのが自然です。

ここから先は私の立場です。私は、この移管を観測する価値は明確に上がったが、まだ「組む対象」ではないと考えています。仕様とSDKが中立組織のもとで固まっていく途中の段階で、複数エージェントが権限を委譲し合う構成を先に組んでしまうと、後から権限境界を絞り直すコストのほうが高くつくと見ているからです。

この立場は、私が実際にマルチエージェント構成を検証して撤退した経験から導いたものではありません。むしろ、Claude Coworkプラグインガイドで先に示した「組織配布はデフォルト拒否から始め、送信・投稿・支払い・契約操作の前には必ず人間承認を残す」という権限境界の原則を、単一エージェントか複数エージェント連携かという設計判断にそのまま延長したものです。エージェント同士がタスクを委譲し合う構成は便利ですが、「誰が何を実行できるか」という境界を先に固めないまま組むと、権限の抜け穴を先に量産する順序になります。A2Aを追う価値と、A2Aで組む判断は、私の中では別のタイマーで動いています。

MCPが「外部世界へつなぐ標準」なら、A2Aは「エージェント同士をつなぐ標準」です。競合ではなく、レイヤーが違います。単一エージェントの外部実行が主課題ならMCPを先に整理し、複数エージェント間の責務分担が主課題になった段階でA2Aの検討に進む、という順序が崩れにくいと考えています。

Agentic AIとComputer Use

Agentic AIは、単発の応答生成ではなく、目標に対して計画し、実行し、結果を見て再計画するワークフロー全体を指すことが多い概念です。特定企業の製品名というより、目標指向・計画・ツール使用・自己修正という4つの特徴を持つ設計パターンとして捉えると整理しやすくなります。

AIエージェント進化の比較 vs 2026年

振る舞いの型はレイヤー地図として固定できますが、それを実装するSDKやフレームワークの層は時価情報です。実例を1つ挙げます。OpenAIの開発者ドキュメントでは、Agents SDKとResponses APIが現行のエージェント系スタックとして整理される一方、以前の中核だったAssistants APIはLegacy APIsに移っています。数か月前の比較記事がそのまま参照されると、すでに退役した前提で議論することになりかねません。記事や比較表を見るときは、この更新差分を意識しておく必要があります。

同じ振る舞い層でも、実世界に作用する機能は運用リスクが一段上がります。Anthropicの公式ドキュメントでは、Computer use toolはスクリーンショット取得、マウス操作、キーボード入力を通じてデスクトップ環境へ作用するbeta機能として説明されています。同じドキュメントは、専用VM/コンテナ、最小権限、ドメインallowlist、人間承認、監査ログをあわせて推奨しています。つまりComputer Useは、便利な新機能であると同時に、ガバナンス込みで設計すべき機能だということです。beta機能を先に触ってから権限設計を後付けする順序は、この機能に関しては取らないほうがいいと考えています。

音声入出力やリアルタイム対話も、振る舞い層を広げる要素として注目されています。ただしモデル対応、遅延、課金、UXの差は短期間で変わるため、これも時価情報として扱い、「音声対応の有無」より、音声認識・合成の品質、ツール実行や状態管理との接続、通話中の安全確認とログの残し方を都度確認するほうが実務的です。

安全性と評価

自律的に動くAIエージェントには、目標解釈のズレによる意図しない行動、本来不要なデータや操作への過剰な権限行使、一つのミスが後続タスクへ波及する連鎖的エラー、誰が何を承認したのか追えなくなる説明責任の曖昧さという、4種のリスクがついて回ります。

NIST AI Risk Management Frameworkは、AIの設計・開発・利用・評価へtrustworthinessの観点を組み込むためのvoluntaryな枠組みとして公開されています。voluntaryという位置づけである以上、これを抽象論のまま持ち帰っても現場では機能しません。実装側の制御へ落とし込む必要があります。

評価の側でも同じ考え方が成り立ちます。SWE-benchはコード生成・バグ修正の実務性能、GAIAは複合的な推論と実行力、WebArenaはブラウザ操作の実行能力、AgentBenchは幅広いエージェント挙動という具合に、それぞれ評価対象が異なります。ただしこれらの外部leaderboardは比較の出発点であって、数値そのものは時価情報です。特にSWE-benchのような公開leaderboardは日々更新されうるため、モデル比較を固定値として覚えるより、最新leaderboardと自社タスク向けの内部evalを併用するほうが実務向きだと考えています。

結び

、引き直すもの、判断保留のもの

ここまでの素材を、扱ったトピック順ではなく、扱い方の軸で並べ直します。

固定してよいものは、MCPが外部への接続を規定し、A2Aがエージェント間の協調を規定し、Agentic AIが計画・実行・再計画という振る舞いを規定する、という役割分担そのものです。加えて、承認・隔離・監査・最小権限という4つの実装制御を先に置くという順序も、数か月で変わるとは考えにくい原則です。

毎回引き直すものは、MCPの対応クライアント一覧、A2Aの標準化がどこまで実装に落ちているか、Agentic AIを組む際のSDK・フレームワークの選択肢、leaderboardの順位です。これらは参照した日付を添えて扱うべき時価情報であり、記憶する対象にはしていません。

判断保留のものは、A2Aを実装対象に含めるべきタイミングです。私は今の時点では観測に留めるべきだと考えていますが、Linux Foundation配下での実装が進み、対応クライアントとSDKが揃ってくれば、この判断は変わります。判断を変える条件を先に決めておくほうが、変えないと決め打つより誠実だと思っています。

導入支援を事業とする立場としては、確認すべき順序もこれと同じだと考えています。最初に確認すべきは接続対象、つまり何と何をつなぐ必要があるかです。次が権限、誰が何を読み書きできるかです。その次が承認で、送信・実行の前にどこで人間が止めるかを決めます。評価、つまり何を成功条件とするかを決めるのは最後でいい、というのが本稿の帰結です。技術選定やベンダー比較から入りたくなる場面があるとしても、この4つが固まっていない状態でMCPやA2Aの実装に進むと、後から権限を絞り直すコストのほうが高くつきます。

2026年後半は、A2Aの実装がLinux Foundationのもとでどこまで進むか、Computer Useのようなbeta機能がガバナンス込みでどこまで標準実装に落ちるか、単一leaderboard比較から業務別の内部eval設計へどこまで移れるかを、観測し続けるつもりです。判断保留にしたA2Aの扱いも、この観測次第で私自身の立場を変えるかもしれません。この記事を、データや仕様そのものではなく、今の時点でどこまで言い切れるかの記録として読んでもらえるとうれしいです。

関連記事

• AIエージェント開発に役立つ一次文献11選。同じ日に書いた姉妹記事です。あちらは「どの一次文献を読むか」の選定を担い、本記事はMCP・A2A・Agentic AIの役割分担、つまりレイヤー地図の固定側を担っています。
• Claude Coworkプラグインガイド。MCPを含むプラグインの権限設計について、「組織配布はデフォルト拒否、送信・投稿・支払い・契約操作の前に人間承認を残す」という境界をすでに書きました。本記事のA2Aに対する立場は、その境界をエージェント間協調の設計判断へ広げたものです。
• AIエージェントセキュリティ入門
  。安全性と評価の節で触れたsecurity lifecycleを、identity・権限制御・eval/red team・監視の4層でさらに深掘りしています。本記事は、その4層のうちどこから着手すべきかという順序の判断を加えています。

参考リソース

• Model Context Protocol
• A2A protocol (Google)
• Google Cloud donates A2A to Linux Foundation
• Computer use tool - Claude API Docs
• Agents SDK - OpenAI API Docs
• AI Risk Management Framework - NIST
• SWE-bench Leaderboard