要点
MCP、A2A、AG-UI が AI エージェントの接続層を三層に分け始めた
2026年3月末までに公開された MCP、A2A、AG-UI の仕様と、OpenAI、Anthropic、Google、Microsoft、AWS の docs と announcement を並べると、 AI エージェントの接続面は 1 つの巨大な製品面ではなく、別々の責務へ分かれ始めていることが見えてくる。 MCP はツールとデータ接続、A2A はエージェント間委任、AG-UI は人間向けの進捗表示、割り込み、承認導線を主に担う。 今週の変化は、これが抽象的な構想ではなく、ランタイム、フレームワーク、アプリ、企業向け docs の実装面として見え始めた点にある。
3層
接続責務の分離
ツール接続、エージェント間委任、人間向け操作面が別の protocol に分かれ始めている。
5系統
主要な実装面
OpenAI、Anthropic、Google、Microsoft、AWS がそれぞれ別の層で公開面を出している。
27件
公開根拠
仕様、公式 docs、公式 announcement だけで層の分離と成熟度の差まで比較できる。
1含意
全部を一製品に閉じ込めなくてよい
アクセス、委任、監督を別々に設計し直せることが、実務上の最大の変化である。
なぜ今週か
2026年3月末の公開情報で、「1つのフレームワークが全部を持つ」構図が崩れ始めた
これまでのエージェント用ツール群は、ツール接続、下位エージェント連携、利用者向け画面を同じ製品の中に抱え込むことが多かった。 しかし 2026年3月の公開情報では、少なくとも3つの責務が分離して見え始める。MCP 側では認証方式を含むツール接続が protocol 化され、 A2A 側では agent card、task、非同期処理、進捗更新が明示され、AG-UI 側では event stream、state 同期、人の確認を前提にした操作がフロントエンド契約として出てきた。 さらに AWS は AgentCore Runtime に stateful MCP と AG-UI を追加し、Google は MCP と A2A を docs で整理し、Microsoft は Agent Framework で A2A と AG-UI 連携を公開し、OpenAI と Anthropic は MCP を製品面側に持ち込んでいる。つまり今週の主論点は、「protocol の名前が増えた」ことではなく、 役割分担が各社の実装面で確認できるようになったことだ。
MCP はツール接続と認証条件の事前把握を担う
どのサーバーに何のツールや resource があり、どの認証方式が必要かを、個別連携ではなく protocol で扱う方向である。
A2A は専門 agent への委任を担う
Agent card、task、message、非同期完了の扱いが明文化されることで、orchestrator と専門 agent の分業を製品外へ開きやすくなる。
AG-UI は状態表示と承認導線を担う
長時間動く agent に必要な progress、artifact、interrupt、approval を、単なる chat log ではなく UI 契約として持てるようになる。
三層で読む
各 protocol は別々の欠落を埋めている
1. MCP: ツール接続とデータ接続の層
- 何を標準化するか: ツール、resource、prompt、認証条件、通信方式
- 向いている場面: 社内文書、SaaS、data warehouse、社内 API への接続
- 実務上の利点: 接続先を差し替えても、エージェント側のツール呼び出し設計を大きく崩さずに済む
- まだ弱い点: 実装ごとの差が大きく、stateful 対応や認証の扱いはプラットフォームごとに成熟度が違う
2. A2A: orchestrator と専門 agent の層
- 何を標準化するか: agent 発見、skill 宣言、task 受け渡し、進捗と完了通知
- 向いている場面: 調査 agent から法務、購買、support、finance 向け専門 agent へ仕事を振る構成
- 実務上の利点: 1つのエージェントが全機能を抱えず、責務ごとに分解しやすい
- まだ弱い点: 実運用では skill 記述、認証、評価、追跡連携を別途そろえる必要がある
3. AG-UI: agent-to-user の層
- 何を標準化するか: event stream、state 同期、artifact 表示、利用者割り込み、承認
- 向いている場面: 長時間処理、レビュー付き自動化、成果物編集、approval-heavy な業務
- 実務上の利点: chat だけでは見えない状態を UI 側で受け取り、利用者の監督を入れやすい
- まだ弱い点: MCP より新しく、実装層の厚みはまだ薄い
まとめると
重要なのは、3つの protocol が競合しているわけではない点である。MCP だけでは専門 agent への委任を表しにくく、A2A だけでは人間向けの監督 UI を表しにくい。AG-UI だけでは安全なツール接続を表せない。
つまり、接続、委任、監督は別々に設計した方が、企業導入ではむしろ扱いやすくなる。
各社の収束
ベンダーごとに強い層は違うが、公開面の分け方は似てきた
OpenAI と Anthropic は MCP を製品面側へ持ち込む
OpenAI の apps と developer mode、Anthropic の MCP connector と Claude Code は、ツール接続をフレームワーク内部の話ではなく利用者や開発者が扱う画面に押し出している。
この層では、接続先 discovery と権限制御が app 体験の一部になり始めている。
Google は MCP と A2A を同時に docs 化している
Google Cloud は企業向け MCP サーバー認証を整理し、Google ADK は MCP ツールと A2A を並べて扱っている。
読み取れるのは、社内 system 接続と専門 agent 連携を同じ開発面で分けて考える方向である。
Microsoft は Agent Framework で A2A と AG-UI を前面に出す
Microsoft は Agent Framework overview に加え、A2A と AG-UI integration を個別の docs として出している。
これは multi-agent と人の確認を、単なる sample ではなくフレームワークの接続面として扱う姿勢と読める。
AWS はランタイム側で protocol を受け止める
AWS は AgentCore Runtime に stateful MCP と AG-UI support を追加し、任意のエージェント用フレームワークを受け止める立場を明確にした。
ここでは protocol は app の表現だけでなく、長時間実行 agent の配備契約としても使われ始めている。
何が変わったか
各社が 1つの protocol を全面採用したわけではない。しかし、接続面を「ツール接続」「agent 間委任」「人間向け操作」の別々の面として出し始めた点では方向がそろっている。
この収束は、製品間の比較軸を model quality だけでなく「どの層をどこまで開いているか」に広げる。
具体シナリオ
三層がそろうと、approval を伴う長時間業務が現実的になる
社内調査 agent が専門 agent を呼び分ける
起点となる agent は MCP で文書、data、社内 API に接続し、法務や購買の専門 agent には A2A で task を委任する。 利用者は AG-UI で進捗、根拠、未完了タスクを見ながら、外部送信や high-risk な操作だけ承認する。
support と請求確認をまたぐ問い合わせ対応
受付 agent は利用者の依頼を整理し、billing specialist や policy specialist に A2A で依頼を振る。 それぞれの agent は必要な system だけ MCP で参照し、返答前の確認や返金承認は AG-UI で人間が止められる。
コードや運用の変更を伴う作業
実行 agent が build、log、ticket、repo に MCP で触れ、分析 agent や検証 agent に A2A で作業を分ける一方、 write、deploy、権限変更の前では AG-UI で差分、理由、影響範囲を見せて承認を取る構成が自然になる。
まだ早い点
protocol がそろっても、そのまま相互運用が完成するわけではない
認証と policy は protocol の外でも設計が必要
MCP に認証 metadata があり、A2A に security の記述があっても、最小権限、失効、監査、承認基準は企業ごとに設計する必要がある。
追跡と評価の横断はまだ難しい
ツール呼び出し、agent 間 handoff、利用者承認が別層に分かれるほど、評価と監査には correlation ID と共通の追跡設計が必要になる。
AG-UI は MCP より若い
AG-UI は人間向けの操作面として有望だが、実装の厚みと利用基盤はまだ薄い。短期的にはベンダー独自 UI と混在する前提で見る方が現実的である。
1つの protocol で全部を済ませようとしない方がよい
今見えているのは、勝者 1 本を決める競争より、層ごとに責務を分ける方向である。導入時は「どの protocol が何を解くのか」を先に切り分ける方が失敗しにくい。
結論
AI エージェントの比較軸は、モデル性能だけでなく接続層の開き方へ広がる
今週の公開情報から読み取れるのは、agent が finally interoperable になったという結論ではない。むしろ、接続、委任、監督を別々の層として扱う設計が 現実味を帯びてきたという点である。企業導入の論点としては、「どの model を使うか」と同じくらい、「どの層を protocol で開き、どの層を自社 policy で閉じるか」を 先に決めることが重要になりつつある。