Agent プロトコルの全体像：MCP・A2A・AG-UI の責務境界と相互運用

はじめに：2026 年、Agent プロトコルはなぜ独立した課題になったのか

2023 年に Agent のコードを書いていた方なら、当時の做法を思い出すはずです。ツール関数をプロンプトに直接書くか、自前の functions 配列に押し込むか――どちらでも動きます。ただし、モデルベンダーを変える、フロントエンドを変える、チームを置き換える。どれかひとつが変わっただけで、ツールの説明、呼び出しログ、コンテキスト注入をすべて書き直すことになります。2026 年になり、この問題は最終的に三つの独立した標準化課題へ分解されました。対応する三つの仕様も、すでに相当な完成度まで到達しています。MCP がモデルと外部機能との標準的な接続を、A2A が Agent 間の発見と協調を、AG-UI が実行中の Agent とフロントエンドの間のリアルタイム相互作用を解決します。

この三つの仕様はよく一緒に語られると同時に、完璧に混同されてもいます。三択の関係ではなく、競合する三つの製品でもありません。正確に言えば、智能体スタックの下位の接続層、中間の協調層、上位の相互作用層をそれぞれが占めており、解く問題はまったく異なり、境界は重複しないほど明快です。とはいえ実際のエンジニアリングでは、ほぼ確実に互いに触れ合うことになります。

三つの仕様を一つずつ読み解いていくだけの内容では、読んでも記憶に残らず、それほど価値もありません。私がやりたいのは三つです。第一に、各プロトコルが本当に解決しているエンジニアリング上の痛点を、仕様書では語られていないトレードオフも含めて、突き詰めて解説することです。第二に、三つのレイヤリング関係とブリッジ(protocol bridging)の方式を明示することです。「リモートの A2A Agent を MCP ツールとしてラップするにはどうすればいいか」―これが実際のプロジェクトでは毎日出てくる問題だからです。第三に、プロトコルの進化の過程で表面化したつまずき点を、capability negotiation、バージョン互換性、セッションと認証、エラーセマンティクス、transport(伝達層)の選択といった項目も含めて、公開して話すことです。どのプロトコルにも完全な設計など存在しません。選定する際は、自分が何を買っているのかを正確に把握しておく必要があります。

マルチ Agent システムを構築している、社内機能を MCP 基準で標準化すべきか検討している、フロントエンドと Agent の間のストリーミングプロトコルを設計している―いずれの場合にも、この記事はまさにあなたのためのものです。ただ「どれを使えばいいのか」を手早く知りたいだけなら、最終節の選定ガイドにそのまま飛んでください。それより前の章は、その判断の根拠を追った部分です。

---

一、まず問題を整理する：三つのプロトコルはそれぞれ何に答えているのか

仕様の詳細に潜る前に、三つのプロトコルの位置づけを一文で釘付けにしておきましょう。この手順は非常に重要です。「Agent プロトコルの優劣」についての議論のほとんどは、位置づけを取り違えていることから生まれています。たとえば「MCP と A2A はどちらが優れているのか」という問いは、それ自体に意味がありません。「HTTP と TCP はどちらが優れているのか」と問うのと同じです。

MCP：機能アクセスを自分のコードの外へ出す

MCP が答える問いは、Agent が、外部世界のツール・データ・プロンプトに統一された方法でアクセスするにはどうすればいいか。

MCP が登場する前、あなたの Agent がデータベースを引いたり、チケットシステムを読んだり、通知を送ったりするなら、ツールの入力引数の構造は Agent 側に書かれ、認証ロジックも Agent 側に書かれ、ツールの説明文書も Agent 側に書かれていました。ツール自体の保守者と Agent の保守者は往々にして別の人間で、インターフェースが変われば相手を呼んでコードを書かせ直す必要があります。これは典型的な暗黙の結合です。コンパイル時にはエラーにならず、ある日インターフェース変更の後の早朝、沈黙した誤った呼び出しとなって初めて表面化します。

MCP はこの構造を標準化しました。ツールの提供側が MCP Server を実装し、クライアントは同じプロトコルでそれを発見して呼び出します。ツールの実装詳細、依存関係の管理、認証方式はすべてサーバー側に封じ込められます。この一歩がもたらす成果は複利的です。同じ Server を任意の数のクライアントが再利用できるからです。クライアントごとに個別に書き直す必要がありません。

決定的な認知の転換は、制御権の方向が反転するという点にあります。従来の関数呼び出しでは、モデルは受動的です。アプリケーションがツール定義をモデルに渡し、モデルは呼び出し要求を返し、実行はアプリケーションが担当します。MCP では、Server が機能の保有者になり、クライアントは接続の確立、機能の列挙、呼び出しの転送だけを担当します。この反転の直接的な帰結は、ツール説明の書き方が逆転するということでした。あなたが制御していないモデルに向けて書く必要が生じ、しかもそのモデルはどのベンダーの出身でありうるか分からないからです。

A2A：Agent 同士が互いを見つけ、仕事を委ねられるようにする

A2A が答える問いは、ある Agent が別の Agent の提供する機能を発見し、タスクを渡し、結果を得るまでをどうすればいいか。

MCP が扱うのは「Agent がツールを呼ぶ」という範囲までです。しかしツールはふつう stateless(無状態)で、リクエスト／レスポンス型で、均質(spec同一)です。それに対して現実の Agent は stateful(有状態)で、非同期で、均質ではありません。法務 Agent の 1 回の実行には 10 分かかり、途中で人手による確認が必要になることもあります。別のチームの Agent は、他社のクラスタ上で独自の認証体系、独自 Invocation の癖、独自のモデル選択で動いています。それをきれいな同期ツール関数にパッケージして自分のプロセスへ押し込み、あたかも同期であるかのように振る舞わせることは不可能です。

A2A はまさにこの種のシナリオのために設計されました。中核となる抽象化は Agent Card(規定されたパスに置かれる JSON 名刺で、相手側がどんなスキルを提供しているかを自動発見できるようにするものと、Task(状態を持つタスクオブジェクト。明示的な状態機械をもち、ストリーミング更新、プッシュ通知、人間による介入に対応する)です。この二つはそれぞれ「見つけられるかどうか」と「見つけた後どう協働するか」に対応します。

AG-UI：実行中の Agent のプロセスをフロントエンドへ届ける

AG-UI が答える問いは、実行中の Agent は、その一歩ごとの推論、ツール呼び出し、状態の変化、インクリメンタルな出力を、リアルタイムかつ構造化された形でフロントエンドへ配信するにはどうすればいいか。

このことは簡単そうに思えますが、実際にやるのはたいへんな苦痛です。どの Agent フレームワークも独自のイベント形式を持っています。独自の状態イベントコールバックを持つもの、混在したテキストの流れが 1 本あるだけのもの、コルーチンジェネレータを 1 つ渡してくれるだけなものもあります。フロントエンドが 3 つのフレームワークの Agent に対応しようとすれば、フロントエンド側に 3 通りの解析ロジックを書く必要があります。ユーザーから見えるステップ表示、ツール呼び出しの承認、状態の巻き戻しを実現しようとすれば、ほぼすべてのフレームワークをもう一度適合させる必要があります。

AG-UI が行っているのは、共有のイベントモデルを定義し、Agent ランタイムの内部状態を十数種のイベントタイプとして記述し、サーバーからのプッシュストリーム経由でフロントエンドへ届けることです。内容フィールドについては、意図的に OpenAI 形式の会話メッセージ構造をそのまま流用しています。これで既存のモデルストリームから移行するコストが極めて低くなります。CopilotKit はその主要な推進者であり、実装者でもあります。

---

二、MCP 仕様を読み解く：ハンドシェイク、原語、そして現実的な使い方

2.1 トランスポート層：stdio と Streamable HTTP の分かれ目

MCP は 2 種類のトランスポートを定義しています。初期のバージョンでは、標準入出力と「HTTP に加えて 1 本の追加 SSE ストリーム」という二重構成でした。クライアントが Server の子プロセスを起動し、標準入出力で改行区切りの JSON-RPC メッセージをやり取りします。リモート構成では HTTP でメッセージを送信し、別途ストリームを開いて応答を受け取ります。后来 Streamable HTTP がこの旧方式に取って代わり、リモート配備の推奨となりました。

この変化の実質は、旧方式では 1 セッションごとに 2 本の接続(上り 1 本、下り 1 本)が強制されていたが、新方式はそれを 1 本に圧縮したということです。仕組みはこうです。クライアントが Server の単一エンドポイントに POST を送り、リクエストボディは JSON-RPC メッセージで、Accept ヘッダが JSON とイベントストリームの両方のレスポンス形式を受け付けることを宣言します。その呼び出しがストリーミング出力を生む場合は Server がイベントストリーム形式で返し、そうでなければそのまま JSON を返します。Server はさらに同じエンドポイントの GET を提供してサーバ起点のプッシュ用ロングコネクションを確立できるようにし、レスポンスヘッダで受信テンプレートを返します。

この設計には踩みやすい点がいくつかあり、工程上は注意が必要です。

一つ目はセッション識別子です。Server は初期化時にセッション ID を発行し、その後のすべてのリクエストがそれをそのまま返さなければなりません。つまり MCP Server をリバースプロキシやコンテナオーケストレーションプラットフォームの後ろでマルチレプリカのロードバランシング対象にしているなら、セッション粘着(sticky session)は硬い制約になります。整合性ハッシュでセッションを 1 つのレプリカに固定するか、Server 側が本当にステートレスであることを保証するかです。この落とし穴は、生産環境で初めて踏む人が非常に多い。

二つ目は切断後の再接続です。クライアントは再接続時に最後に受信したイベント ID を持ち込み、Server 側が欠落したメッセージをリプレイする役割を持ちます。その間にレスポンスバッファを有効にしているリバースプロキシがあると、リプレイは機能せず、「たまに成果物が丸ごと欠ける」という現象として現れます。対応策はプロキシのレスポンスバッファを無効にすることです。

三つ目はローカルの信頼境界です。標準入出力トランスポートのセキュリティモデル全体は「プロセス境界が信頼境界である」というものです。パッケージマネージャから MCP Server を入れて自分のマシンで実行させれば、それはほぼあなたのユーザー権限を持つことになります。これがローカル開発で非常に良い体験になる理由であると同時に、企業環境で明確に禁止されている理由でもあります。企業環境は Streamable HTTP と OAuth を通すことを一般に要求し、開発機でパッケージを適当に実行させることを許しません。

2.2 ハンドシェイク：initialize は唯一の交渉の場

MCP のすべてのメッセージは JSON-RPC 2.0 です。この選択は重要で、JSON-RPC は本質的に 3 つのセマンティクスを区別するからです。リクエストは ID を持ち応答を待ち、レスポンスは ID かエラーを持ち、通知は ID を持たないため応答が不要です。この区別は Agent のシーンでは非常に有用です。通知によってサーバはログや進捗を一方向にプッシュでき、応答チャンネルを汚すこともなく、クライアントがリクエストの対応表を管理する必要もなくなるからです。

接続が確立した後の最初のことが初期化リクエストです。これは双方が正式に能力ネゴシーション(capability negotiation)を行う唯一の機会であり、双方が 1 つのメッセージの中でそれぞれの身元と能力を宣言します。完全な往復は次のようになります。

// C -> S
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
  "protocolVersion":"2025-06-18",
  "capabilities":{"roots":{"listChanged":true},"sampling":{},"elicitation":{}},
  "clientInfo":{"name":"my-agent-runtime","version":"0.9.3"}}}

// S -> C
{"jsonrpc":"2.0","id":1,"result":{
  "protocolVersion":"2025-06-18",
  "capabilities":{"tools":{"listChanged":true},"resources":{"subscribe":false},"prompts":{},"logging":{}},
  "serverInfo":{"name":"corp-knowledge","version":"2.3.0"},
  "instructions":"优先使用 search_docs；引用结果时必须带上 doc_id。"}}

ここには非常に見落とされがちだが、威力の大きいフィールドがあります。サーバが返す instructions です。これはモデルに向けた自然言語の説明であり、MCP 版のシステムプロンプトに相当します。多くの Server 作者はこのフィールドの価値に気づかず、ツールの説明をぐちゃぐちゃに書いてしまい、その結果としてモデルがツールを頻繁に選び間違えます。Server 実装者にとっては、instructions を書くこととツールを実装することは同じくらい重要であり、その投資対効果はプロジェクト全体で 1 番高い可能性があります。

もう一つ見落とされがちなのはクライアントの sampling 能力です。そのセマンティクスは直感に反します。sampling メソッドは、サーバ側が逆にクライアントに対して大モデルを 1 回呼んでもらうように頼むというものです。これは「ツールそのものが知能を必要とする」要件を解決します。たとえばコード解析ツールが、まずモデルにコードの構造を読ませてから解析方針を決めたいといった場合です。MCP 以前の世界でこれを実現するには、ツールの内部にこっそりモデル SDK を埋め込むしかありませんでした。それは深刻な結合をもたらし、受け入れられないレベルのサイズ肥大を招きます。MCP はこの呼び出し方向を正式なものにしました。

2.3 三大原語：機能ではなく支配権の帰属で分ける

MCP の設計には、見過ごされやすいが非常に讲究な点があります。三つの原語は機能ではなく支配権の帰属で分けられているのです。仕様は、モデルを「モデルに支配される原語の発起者」と呼び、アプリケーションを「アプリケーションに支配される側」と呼び、ユーザーを「ユーザーに支配される側」と呼び分けています。

• ツールはモデルに支配される。モデル自身がいつ呼び出すかを決める。最も自律的で、最も危険であると同時に、最も価値が高い能力です。
• リソースはアプリケーションに支配される。クライアントがどのファイル、どのデータベースレコード、どの社内ドキュメントをモデルに公開するかを決める。通常は統一リソース識別子でアドレス指定します。モデルは自発的に読み取れますが、自分で作り出すことはできません。
• プロンプトはユーザーに支配される。ユーザーがクライアント内で明示的に起動するテンプレートです。たとえば「今週の業務週報を生成する」というプリセットです。

この区分は学問的な純度のためではなく、実際の結果を生みます。誰が安全とプライバシーの審査を担うのかという問題だからです。リソースはアプリケーションが主动的に押し込むものなので、責任はアプリケーション側にあります。ツールはモデルが発火しますが、実行権はアプリケーションにあるので、やはりアプリケーションの責任範囲です。プロンプトはユーザーが明示的に起動するので、ユーザー知情確認が必要です。この区分を混同すれば、権限モデル全体がズレます。最も典型的な事故は、誰かがユーザーの個人ファイルをモデルが自発的に呼び出せるツールとして登録してしまうことで、それはモデルに万能キーを渡したようなものです。

リソースは購読の仕組みにも対応しており、リソースが変更されるとサーバが更新通知をプッシュします。リソース自体、具体的なアドレスでもよいし、テンプレート化されたアドレス(プレースホルダを持ち、テンプレート列挙インターフェース経由で発見する形式)でもよく、後者はデータベース系のバックエンドにとって特に便利です。

2.4 ツール呼び出しと構造化出力

ツール呼び出しの完全な往復を示します。結果に含まれたエラーフラグフィールドに注意してください。これはツールレベルのエラーの表現方法であり、JSON-RPC 層のエラーオブジェクトとはまったく異なるセマンティクスです。後述するプロトコルをまたぐエラーマッピングにおける重要な分岐点になります。

// 成功：正文给模型看，结构化数据给程序用
{"jsonrpc":"2.0","id":7,"result":{
  "content":[{"type":"text","text":"找到 3 篇相关文档：..."},
             {"type":"resource_link","uri":"file:///runbooks/gray-release.md",
              "name":"灰度发布回滚手册"}],
  "structuredContent":{"hits":[{"doc_id":"rb-2211","score":0.91}]},
  "isError":false}}

// 失败：仍然是 JSON-RPC 成功，但 isError 为 true
{"jsonrpc":"2.0","id":7,"result":{
  "content":[{"type":"text","text":"upstream search cluster unreachable"}],
  "isError":true}}

構造化出力とリソースリンクという 2 つの特性は、方向性の強い強化です。構造化出力によって、ツールは「人間あるいはモデルに見せるテキスト」と「プログラムが使う構造化データ」を同時に返せるようになり、ツール記述の中の出力構造の宣言と対応します。従来の痛点は、ツールが JSON 文字列を返すため、モデル自身がその文字列から構造を解析しなければならず、コンテキストを無駄にしながら失敗もしやすく、下流のコードももう一度解析を迫られていたことです。如今この二つは分離されたので、モデルはテキストを読み、プログラムは構造を読む、それぞれが最適になります。

リソースリンクは、ツールの結果が直接リソースを指せるようにし、モデルが詳細を引き続き読み取れるようにします。これにより、大量の内容を一度にツールの戻り値に詰め込むことを避けられます。これはコンテキスト予算に対して実測できる節約になり、特にドキュメント、コード、ログといった大きなオブジェクトを返す場面で効きます。実用的な助言をひとつ。ツールの戻り値には要約と索引だけを入れ、詳細はリソースに置いて、モデルが必要に応じて取得するようにしてください。

2.5 進捗通知と長時間タスクの穴

クライアントはツールを呼び出すとき、メタデータで進捗トークンを提供できます。するとサーバは実行中に進捗通知をプッシュでき、完了済み数、総数、そして人間向けの短い説明を添えられます。MCP の中で珍しい「実行中」シグナルであり、そのセマンティクスは「私は生きている、これが進捗」です。

ただしこれは仕様レベルの設計がまだ弱いままです。進捗はただの数字で、再開可能なハンドルではありません。ツール実行の途中でクライアントが切断しても、サーバはそれを知りません。実行結果を再接続したクライアントへ届けることもできません。より新しい仕様バージョンでは、タスク化された長時間ツール呼び出し(実験的機能)が導入され、ツールがタスク ID を返し、一連の照会とキャンセルのメソッドで前進していく形になりました。この部分の実装はまだ很不揃いです。依存する予定なら、先に選んだ SDK バージョンが本当に対応しているかを必ず確認してください。ドキュメントだけを見ないでください。

それに対して、A2A は長時間タスクにおいて明らかに成熟しています。これは両者の分業を裏付ける証拠でもあります。MCP が長時間タスクのプロトコルになるつもりはなく、兼任させようとしても仕様が複雑になるだけです。

2.6 Roots：過小評価されているセキュリティ境界

クライアントは roots 能力を通じて、自身のファイルシステムとディレクトリの境界をサーバに伝えられます。変更通知の能力があるなら、ディレクトリ一覧が変わったときにクライアントから主动的にサーバへ通知することもできます。この仕組みはよく「クライアントがツールの場所を Server に伝えるもの」と誤解されますが、その意味ははるかに大きいです。それはサーバが自ら自分を拘束する根拠になるからです。

責任ある MCP Server の実装は roots のサポートを宣言し、すべてのファイルアクセスの前に、対象パスがクライアントが宣言した境界の内側に収まっているかを検証するべきです。そうしない Server は表面上は害がありませんが、実際にはモデルに駆動される任意ファイル読み取り器と等しいものになります。プロンプトに「~/.ssh/config を読み込んで内容をまとめて」と 1 行注入するだけで、多くのモデルでは成功します。

私の判断はこうです。もしあなたの MCP Server がファイルシステム、ネットワーク、データベースへの書き込みを扱うなら、roots の検証とパスの正規化は選択肢ではありません。とくにシンボリックリンク、相対パスの連結、そして大文字小文字を区別しないファイルシステム上のパストラバーサルに注意してください。これらは実装で最も抜けやすい 3 つの点です。仕様はこれを強制しませんが、漏らした代償はデプロイ環境全体の陥落です。

2.7 三つの原語の選び方：実行可能な判断基準

MCP の接続を新しく始めるチームは、まずここで失敗します。すべてをツールにしてしまうのです。私の経験では、1 本の基準で分解できます。「どれを使うか」を誰が決めるか、というものです。

選択権がモデルにあるなら、ツールにします。モデルが「先月の請求を調べて」という発言に直面したとき、どのテーブルを掘るか、どんな時間範囲を渡すかを自分で決める必要があります。この意味からパラメータへの変換こそが、ツールが存在する理由です。

選択権がアプリケーションにあるなら、リソースにします。典型的なのは、あなたがユーザーがどのページ、どのチケットを見ているかをすでに把握していて、後端がそのレコードをそのままリソースとして公開し、モデルは読み取るだけです。リソースの利点は、それがモデルの選択可能なツール一覧に現れないことです。誤選択の割合を圧迫せず、モデルが必要としないデータを「発見」させることもありません。

選択権がユーザーにあるなら、プロンプトにします。「催金のメールを書いて」のようなことは、開始権が人側にあります。テンプレートも UI 上に明示的な入口を持つべきで、モデルが裏でこっそり選んで使うようにしてはいけません。

選択権に加えて、副作用も見てください。読み取り専用の原語と外部の状態を変える原語は、実装上もデプロイ上も認可上も分けておくのが望ましいです。コードベース全体を読むプロセスに、外部システムへメッセージを送る能力まで持たせるのは、多くのセキュリティ事故の標準シナリオです。この助言は 2.6 節の境界検証と対をなします。境界検証は「どこにアクセスできるか」を、プロセス分離は「何を起こしうるか」を管轄します。

また忘れられがちなトレードオフが発見性です。ツールとリソースではプロンプト内での見え方が異なり、モデルから見たツールの「可視性」は通常そちらが高いです。ツールには使用説明が付随するからです。これは人気は低い一方で重要な能力にはプラスに働きます。よって判断基準に加え、もう 1 つ確認したいことがあります。この能力はモデルに自発的に使わせたいのか、それともアプリケーションに名指しで使わせたいのか。前者ならツール寄り、後者ならリソース寄りです。

三、A2A 仕様を読み解く：Agent Card、Task、そしてプッシュ

3.1 Agent Card：発見可能な能力名刺

A2A の入口は、規定されたパスに置かれた 1 枚の JSON ファイルです。仕様では標準の well-known パスでホストすることを定めており、初期のバージョンでは別の名前を使っていました。実装上は両方のパスに置いておくのがいちばん手間がありません。このカードが A2A のサービスディスカバリの仕組みです。登録センターは必要ありません。相手があなたのベース URL のあとの名刺さえ知っていれば十分です。

{
  "protocolVersion":"0.3.0",
  "name":"ContractReviewAgent",
  "description":"审查采购合同条款，标注风险并给出修改建议。",
  "url":"https://legal-agent.corp.example/",
  "preferredTransport":"JSONRPC",
  "additionalInterfaces":[{"url":".../rpc","transport":"JSONRPC"}],
  "version":"1.7.2",
  "capabilities":{"streaming":true,"pushNotifications":true,
                  "stateTransitionHistory":true,
                  "extensions":[{"uri":"https://corp.example/ext/audit",
                                 "required":false}]},
  "securitySchemes":{"corp-sso":{"type":"oauth2",
      "flows":{"authorizationCode":{
        "authorizationUrl":"https://sso.corp.example/authorize",
        "tokenUrl":"https://sso.corp.example/token",
        "scopes":{"a2a.tasks":"创建与查询任务"}}}}},
  "security":[{"corp-sso":["a2a.tasks"]}],
  "supportsAuthenticatedExtendedCard":true,
  "defaultInputModes":["text/plain","application/json"],
  "defaultOutputModes":["text/markdown"],
  "skills":[{
    "id":"clause-risk-review","name":"条款风险审查",
    "description":"逐条审查合同，输出风险等级与修改建议。",
    "tags":["legal","risk"],"examples":["这份 MSA 的责任条款有问题吗"],
    "inputModes":["text/plain"],"outputModes":["text/markdown"]}]}

このカードの情報量は大きいですが、単独で触れる価値のある設計が 3 つあります。

複数インタフェースの宣言と推奨トランスポートは、A2A がトランスポート層に縛られないことを示しています。仕様は JSON-RPC、gRPC、HTTP+JSON の 3 種類のインタフェースマッピングを同時に定義しており、同じ Agent が複数のインタフェースを公開し、相手が自分の技術スタックに合わせて選べるようにすることができます。これは MCP との最大の構造的な違いのひとつです。MCP はトランスポート層を仕様書に書き込んでいますが、A2A はそれを意図的に開いています。すでに gRPC に大量の投資をしているバックエンドチームにとって、この違いは極めて現実的な意味を持ちます。

拡張カードの宣言はスクレイピングを防ぐ設計です。公開名刺には機密ではない能力の概要だけを載せ、クライアントはまず認証情報なしで一度リクエストし、「認証が必要」というレスポンスを受けたら今度は認証情報を付けてもう一度リクエストして、ようやく完全なカードを受け取ります。こうすることで公開エンドポイントをどこに置いても、内部のスキル一覧やパラメータ構造が漏れる心配がなくなります。

拡張フィールドは実務的な設計です。コア仕様を変えずにプライベートなフィールドを追加でき、必須かどうかもマークできます。必須でない拡張は古いクライアントが無視してよい、と規定されています。企業内ネットワークのシーンでは、これは「仕様がフィールドを追加するのを待ってから SDK をアップグレードする」よりずっと効率的です。私が見てきた成功した A2A の内部実践は、ほぼすべてこの仕組みを使っていました。

3.2 Task の状態機械：A2A の真の中核

A2A の中核オブジェクトはタスクであり、7 つの状態を持ち、明示的な状態機械を構成します。この点は MCP よりはるかに優れています。MCP のツール呼び出しには「実行中」と「終了」の 2 つしかなく、「失敗」すら余計な真偽値のフラグで表現しなければならないからです。

状態	意味	典型的な次状態
提出済み	受信してキューに入り、まだ実行を開始していない	実行中
実行中	動作中で、複数回報告されることがある	完了、失敗
入力待ち	人間またはクライアントが追加情報を提供する必要がある	実行中へ戻る
完了	成功。成果物は成果物リストに含まれる	終端状態
キャンセル済み	能動的に中断された	終端状態
失敗	実行中にエラーが発生した	終端状態
拒否	リクエスト自体が不正。認証失敗や機能非対応など	終端状態

入力待ちの状態は単独で取り出す価値があります。これは A2A が human-in-the-loop を正式に扱う仕組みです。タスクの途中で情報が足りないことがわかったとき、サーバはそのタスクをこの状態に置き、流やプッシュを通じてクライアントに「何かを補ってください」と伝えます。クライアントが補って返すと処理が続きます。これを例外ではなく状態としてモデル化したことで、多ターンの相互作用がプロトコルの一等市民になります。あとから貼り付けるパッチではなく。

この設計は、そのままブリッジ層の書き方を決めます。多くの人が A2A を MCP ツールに変換するとき、最初の反応は「完了しなければ失敗」となり、相手が持つ最も価値のある協働能力を壊してしまいます。正しいマッピングは、入力待ちを正常な戻り値としてモデルに渡し、モデル自身がユーザーに尋ねるのか、戦略を変えるのかを決めるようにすることです。

もう 2 つの識別子は分けておく必要があります。タスク ID は 1 回のタスクを特定し、コンテキスト ID は会話のセッション全体を特定します。クライアントが後続のリクエストにコンテキスト ID を付けると、Agent はこれが同じ会話の後続ターンだとわかります。これは MCP にまったく存在しない概念です。MCP のツール呼び出しはステートレスなので、「このターンの会話」というものは完全にアプリケーション自身が維持しなければならず、MCP で記憶のある Agent を動かすなら、この概念を自分で作り上げる必要があります。

3.3 メソッド集とプッシュ通知

A2A のメソッド集は MCP より簡潔です。同期メッセージ送信、ストリーミングメッセージ送信、タスク照会、タスクキャンセル、流の再購読、プッシュ設定。メッセージの中身はメッセージオブジェクトで、そのパートはテキスト、ファイル、データの 3 種類をサポートしています。MCP のコンテンツブロックとも一致しており、Agent プロトコルの分野ではこれが一般的になりつつある慣習です。

プッシュ通知の流れはこうです。クライアントがまず自分のコールバックアドレスを登録し、Server はタスクの状態が変わるとそのアドレス宛に POST を送り、本文は状態更新イベントまたは成果物更新イベントです。このパターンは WebSocket が企業のネットワークポリシーでブロックされている内網環境に特に親切で、MCP に対する現実的な優位点のひとつです。

しかし、プッシュには避けられない技術的な問題があります。それは信頼できないということです。コールバック配送の失敗、ネットワークの揺らぎ、相手サービスの一時的な停止、リトライ嵐で相手を叩き壊すこと。仕様はいずれも定義していないので、実装は三者三様で、重試すら行わないものまであります。

実務的な方法はこうです。プッシュは加速のシグナルとしてのみ扱い、決して真実の情報源として扱わない。プッシュを受けた後も、タスク照会で権威ある状態を一度取得して検証します。このパターンは分散システムでは常識ですが、Agent プロトコルの実装ではよく忘れられ、「たまに状態が進まないまま止まる、クライアントを再起動すれば治る」という極めて排查しづらい問題として現れます。

3.4 よく聞かれる質問：A2A と MCP は統合されるのか

これはコミュニティで繰り返し聞かれる質問です。2025 年末から、主な推進者のいくつかは関連仕様を中立の財団に托管するようになりました。ガバナンスの层面上「誰が決定権を持つのか」という議論は減りましたが、2 つの仕様の設計哲学の根本的な違いは消えていません。

私の判断は統合されないし、統合すべきでもないということです。理由は単純で、抽象化のレベルが違うからです。MCP の原語はステートレスで、同期的で、「能力」志向です。A2A の原語はステートフルで、非同期で、「委託」志向です。両者を無理に統一しようとしても、唯一の方法は一方を他方の特殊ケースへ降格させることだけで、それは両方を同時に傷つけます。

より現実的な方向は、統合ではなく相互運用性です。「A2A の Agent は MCP Server を通じてどう能力を公開するか」「MCP Server はどう A2A の Agent に包まれるか」を明確に約束する。実際、ブリッジのニーズはすでに十分に現実的で、多くの人が同じ場所で失敗しています。統合された仕様でこれを駆動する必要はありません。必要なのは、この做法を突き詰めた記事と、気に入ったツールライブラリ群です。それが本記事後半で届ける内容です。

3.5 拡張カードとプッシュ通知の実装要点

拡張カードの 2 段階フローは仕様では数行しか書かれていませんが、実装の詳細が成否を分けます。正しいフローはこうです。クライアントはまず匿名でベース名刺のパスをリクエストし、サーバは未承認のレスポンスを返し、認証チャレンジヘッダにリソースサーバのアドレスを入れます。クライアントはそのヒントに従って認可を完了し、トークンを持って同じパスを再リクエストし、このときは完全な名刺が返ります。

ここでいちばんよくある実装の誤りは、パスが一致していないことです。ベース名刺は well-known パスにあり、完全な名刺がトークンなしでは入れない別のパスに置かれています。仕様は両者が同じアドレスであることを求め、資格情報の有無だけで区別します。パスの不一致は、クライアントライブラリが自動処理しないことがほとんどで、その結果、デグレード機構が形だけになり、呼び出し側は能力を得られないか、自分でリトライロジックを書くかのどちらかになります。

2 つ目の誤りはステータスコードです。資格情報が欠けているか無効なら、403 ではなく 401 を返さなければなりません。403 はクライアント側の意味では「認証済みだが権限がない」であり、その結果クライアントはリトライループの中で止まってしまい、ログインも表示せずエラーも出さず、ただハングします。仕様はこの点の要求が明確です。実装時に手抜きをしてはいけません。

プッシュ通知の実運用上の要点は 5 つあり、どれか 1 つでも欠けると、ある深夜に問題が起きます。

• 送信元検証：コールバックのリクエストは送信元を検証できなければなりません。もっとも簡単なのは共有鍵で署名して、サーバ側で署名の検証に失敗したらそのまま捨てることです。通すだけにしてログに残す、という降格はしません。
• バックオフ再試行：プッシュの失敗は指数バックオフで再試行し、総時間の上限を設けます。相手が落ちているときにバックオフをしないのは、あなたの側でサービス拒否攻撃を発生させることに等しいからです。
• プッシュの重複：同じ状態が複数回プッシュされてもよく、受信側はタスク識別子と状態で重複を除去しなければなりません。少なくとも 1 回の配信(at-least-once)セマンティクスとして実装するのが、唯一稳妥な方法です。
• キープアライブ：長時間実行されるタスクは定期的にハートビートを送り、間のロードバランシング装置が接続をアイドルと判定して切断するのを防ぎます。ハートビートの間隔は装置のアイドルタイムアウトより明確に短くしてください。さもないと、あなたの閾値は常に相手より遅れます。
• 保険としてのポーリング：プッシュがどれだけ信頼できても、定期ポーリングを保険として用意しなければなりません。さもないと、1 回失われたプッシュがタスク状態を永久に古い値で止めることになります。

最後に拡張フィールドの使い方についてです。これを、コンプライアンスを満たす唯一の拡張経路として扱ってください。監査ログ、課金レポート、コンプライアンス証跡の 3 つのニーズはいずれも拡張として紐付けられ、必須性を true にしておけば、対応しない相手がハンドシェイクの時点で明確に拒否してくれます。

四、AG-UI 仕様を読み解く：イベントモデルと状態同期

4.1 なぜリクエスト／レスポンスではなくイベントストリームなのか

AG-UI の出発点は明確です。Agent の実行プロセスそのものが本質的にイベントストリームです。モデルが一文字ずつ出力するのはイベント、ツールを呼び出すと決めるのはイベント、ツールの実行が始まるのはイベント、ツールが結果を返すのもイベント、状態変化もなおイベントです。従来のフロントバックの相互作用モデルにはリクエスト／レスポンスという 2 つの意味しかないので、このプロセスを表現できません。各種の姑息な手段に頼るしかないからです。たとえば中間過程をすべて 1 本のストリーミングテキストに連結して、フロント側が正規表現でどこにツール呼び出しがあり、どこが最終回答なのかを推測する、ということです。

この推測による方法は、フロントエンドでは次のように見えます。ツール呼び出しが JSON の塊として描画される、状態が決して更新されない、ユーザーが誤ったツールをクリックしても止められない。AG-UI が選んだのは、このイベントモデルを明示的に定義することです。トランスポートにはサーバー送信イベント(SSE)を使い、各イベントが 1 つの JSON オブジェクトで、最も重要なフィールドはタイプです。

4.2 コアイベント群

イベントの命名は非常に整っているので、実際のデバッグでよく見る順に並べておきます。

RUN_STARTED / RUN_FINISHED / RUN_ERROR   运行生命周期
STEP_STARTED / STEP_FINISHED             步骤边界
TEXT_MESSAGE_START / _CONTENT / _END     助手文本流
THINKING_START / _CONTENT / _END         模型推理流
TOOL_CALL_START / _ARGS / _END / _RESULT 工具调用四段式
STATE_SNAPSHOT / STATE_DELTA             状态全量与增量
MESSAGES_SNAPSHOT                        消息列表快照
CUSTOM                                   业务自定义事件

この三段構成の命名の規律正しさは、美に対する潔癖ではなく、実際の価値があります。フロントエンドは任意のストリームを描画する汎用コンポーネントを 1 つ書けるようになり、知らない拡張イベントに遭遇してもクラッシュしません。イベントの命名が「テキスト増分」「ツールパラメータの断片」「ツール実行完了」のような説明的なものだと、イベント種別が 1 つ増えるたびにフロントに分岐が 1 つ増え、十几個になった時点でもうコードは保守できません。

ツール呼び出しの 4 段構成は殊に見る価値があります。「どのツールを呼び出すかが分かった」「パラメータはまだストリームで組み立て中」「パラメータが組み上がった」「実行結果が届いた」という 4 つの意味を明確に分けているからです。これによりフロントは 2 段目でツールカードの描画とローディング表示を始められ、4 段目の前まで新しい指示の送信を禁止できます。あなたのフレームワークが「ツール実行中」という曖昧なイベントを 1 つ流すだけなら、これはいずれもできません。

4.3 コンテンツアドレッシング：AG-UI が「汎用」になれる理由

AG-UI のイベントにおける内容フィールドは、OpenAI のチャット補完のメッセージ構造をそのまま採用しています。メッセージ ID、親メッセージ ID、ツール呼び出し ID、ツール名です。この選択は手抜きのように見えますが、実は熟慮の結果です。あらゆる主要モデルベンダーのストリーミング出力フォーマットは、すでに OpenAI の形状に収束しつつあるため、その形状を流用すれば、あらゆるモデルストリームから AG-UI への移行コストはほぼゼロになるからです。プロトコル設計者が抵抗の最小の経路を選んだ、これは非常に成熟した工学的判断です。

もう 1 つの重要な設計は、状態スナップショットと状態デルタの役割分担です。スナップショットは新しく加わった相手を素早く同期させる担当です。たとえばユーザーがページを再読み込みした、別のデバイスに替えた、イベントストリームが切断されて再接続した、といった場合です。こちらは全量同期を行います。デルタはリアルタイム更新を担当し、トラフィックを減らします。これは従来のフロントエンドの状態管理における成熟したパターンをストリーミングのシーンに移植したもので、新しくもないことです。とはいえ、最初からこの点を明確に考え込んでいた Agent フレームワークはごく少なく、ほとんどはまず全量再送で済ませ、メッセージが長くなってから、デルタの仕組みを後から補っています。

4.4 状態同期の 2 方向、片方だけをやらない

多くのチームが AG-UI を導入するとき、サーバからフロントへという一方向しか実装していません。サーバがイベントをプッシュし、フロントは受動的に描画するだけです。ユーザーが実行を中断したい、入力を変えたい、ツール呼び出しを承認したいという望むことができません。

完全な実装には双方向が必要です。フロントはイベントストリームを購読するだけでなく、ユーザーの操作(中断、承認、状態の変更)をサーバへ戻す経路も必要です。ここには踩みやすい並行性の罠があります。ユーザーがツール呼び出しを承認している最中に、Agent 自身も状態を変更することがあり、両者が同時に書くと上書きされます。AG-UI がこれに対処する方法は、状態更新を無条件の書き込みではなくバージョンに基づく書き込みにすることです。フロントが変更を送信するときに、自分が見たバージョン番号も付け、バージョン不符なら拒否して再同期させます。

私の提案はこうです。状態の一致性はサーバ側で裁定する、というものです。フロントが自分で楽観的に更新してからロールバックを試みてはいけません。Agent の状態は強一貫性が求められる領域であり、ここでの楽観的更新は失敗モードが得られる利益よりずっと大きくなります。フロントは「あたかも即座に」見せることはできますが(表示をすぐ変える)、実際の状態はサーバが確認したイベントを基準にすべきです。

4.5 AG-UI の境界

強調しておきたいことがあります。AG-UI は実行時の相互作用という層だけを担当します。ツールをどう発見するか、Agent をどう発見するか、認証をどうするかは定義しません。MCP を使わず、A2A を使わず、社内で自前のイベントストリームに AG-UI のイベント命名を組み合わせるだけで、これは完全に合法です。実際、多くのチームがそうしており、そのほうが最適解であることが多いのです。

これが同時に長所(軽量、段階的に導入でき、移行コストが低い)でも短所でもある(複数 Agent の協働の問題を何も解決しない)ということです。AG-UI は「Agent プロトコルの UI 層」と理解するのが最も正確であり、それ以上のことは期待できません。

4.6 切断からの復帰、バックプレッシャ、フロント側の再送

ストリーム配信システムで難しいのは配信ではなく、途切れたらどうするかです。スマホのバックグラウンドへの切り替え、地下鉄での電波の悪さ、ロードバランシングの再接続、いずれも日常的なことです。完全な復旧フローは 3 ステップです。

最初のステップはローカルバッファです。クライアントは再接続期間中もイベントを受け取れる必要があり、すぐに失敗して再接続してはいけません。そのためサーバは接続ごとに上限付きのバッファキューを持たせます。新しいイベントはまずキューに入り、接続が復旧したら順序どおりに補完します。ここで「上限付き」という 2 つの字が鍵です。上限のないバッファはバックエンドではメモリリークになり、フロントではタブのクラッシュになります。

2 つ目のステップはシーケンス番号による位置合わせです。サーバは実行ごとに単調増加するシーケンス番号を持ち、クライアントは既に見た最大のシーケンス番号を記憶します。再接続時にその最大値を送れば、サーバはそれより大きい部分だけを補完します。サーバがクライアントの番号がバッファ容量をはるかに超えて遅れていることを検出した場合は、补完できません。クライアントにスナップショットによる位置合わせを要求しなければなりません。この規則により、復旧戦略は勘ではなく判定可能なものになります。

3 つ目のステップはスナップショットによるフォールバックです。シーケンス番号の差が大きすぎる場合やプロトコルバージョンが変わった場合、クライアントは状態スナップショットを一度要求し、歴史のデルタを再生しようとはせず、最新状態からやり直します。ほとんどのシーンではこのほうが良好です。ユーザーは途中で抜け落ちた文言いは気にせず、今の状態が正しいかだけ気にします。

バックプレッシャも忘れられがちな問題です。モデルの出力がネットワークの送信速度を超えたり、フロントのレンダリング速度が追いつかない場合、イベントはサーバに滞留します。SSE には組み込みのフロー制御がないため、唯一の手段は能動的な制限です。接続ごとに最大キュー長と最大生存時間を設け、超えたら自分から接続を切ってクライアントに復旧フローを走らせます。遅いコンシューマを能動的に切断する方が、サーバのメモリを使い潰させるよりよほどよいです。後者は他のすべてのユーザーに被害を及ぼします。

フロント側の再送について、1 つ規律があります。ユーザーのメッセージを Agent へ再び投入して「会話を復旧」させてはいけません。ツールが二重に実行され、課金が二重に請求され、レコードが二重に作られます。正しいやり方は、状態スナップショットから UI を復旧し、ユーザーが現在の状態を見たうえで継続するかどうか自分で決められるようにすることです。この規則は自明に聞こえますが、「リトライ」ボタンを実装するときに非常に犯しやすいルールです。

最後は増分レンダリングの問題です。モデルが一文字ずつ出力するとき、1 秒間に数十件の増分イベントが来る可能性があり、1 件ずつ DOM を更新すると体感できるカクつきが出ます。フロントはレンダリングのまとめ込みを行うべきです。フレーム単位か固定間隔でまとめてフラッシュし、状態計算には完全なイベント列を保持したうえで、レンダリング層だけでスロットリングします。この最適化をするかしないかでの手触りは大きく違いますし、工数は数十行です。

五、層の関係：上にいるもの、下にいるもの、1 つだけでよいとき

3 つのプロトコルを並べてみると、その関係は非常に明快です。

軸	MCP	A2A	AG-UI
解決するもの	ツールとデータの接入	Agent 間の発見と委託	フロントからの観測と操作
両端は誰か	モデルクライアントと能力提供側	Agent と Agent	ランタイムと画面
中核オブジェクト	ツール、リソース、プロンプト	名刺、タスク、メッセージ	実行、イベント
呼び出しの形	同期中心、リクエスト／レスポンス	非同期、長時間タスク、状態機械あり	一方向のストリーミングプッシュ
状態管理	基本的にステートレス	サーバ側でタスクを永続化	共有状態を双方向同期
トランスポートの開放度	仕様内で 2 種類を定義	意図的に 3 種類以上を開放	仕様内で 1 種類を推奨
認証の姿勢	リモートでは OAuth 2.1 必須	名刺で宣言、強制しない	仕様の対象外
human-in-the-loop	ユーザー入力の照会は比較的新しい	状態機械の一等市民	フロントでの承認と状態戻し

層関係を一言でまとめるとこうです。MCP は下方向和能力接入の層、A2A は横方向の協働の層、AG-UI は上方向の相互作用の層。完成した本番システムは、通常は 3 者を重ねたものになります。

5.1 具体的なシーンでの組み合わせ方

あなたが購買申請のアシスタントを作ると仮定します。ユーザーがフロントで「開発用のノート PC を 1 台申請したい、予算は 1 万 2 千円」と言います。システムの実態は次のようになります。

1. フロントは AG-UI のイベントストリームを購読し、モデルの推論、ツール呼び出し、中間確認リクエストを見て、「資産台帳を調べている」カードをリアルタイムに描画します。
2. 主 Agent は IT 資産カタログの照会と部門予算残高の照会を必要とします。どちらも社内システムなので MCP で接続します。
3. 主 Agent は承認フローを回す必要があります。承認体は別チームが保守している単独の Agent で、A2A で接続します。
4. 承認 Agent は 2 分走ります。その途中で予算管理者の確認が必要になることがあります。これは A2A では入力待ちの状態です。主 Agent は照会かプッシュでそれを察知し、「承認待ち」という情報を AG-UI イベントに変換してフロントへプッシュします。
5. プロセス全体のすべての中間状態が AG-UI のイベントストリーム経由でフロントへ送られるので、ユーザーが見るのは進捗のある手順です。くるくる回るアイコンではありません。

この例では 3 つのプロトコルがそれぞれ役割を担っており、どれも余分ではありません。逆に言えば、内部の IT システムを「統一するため」に A2A の Agent としてパッケージ化する必要はありません。同期的システムに無理に非同期化を被せるだけなので、誰も得しません。自作の SSE イベント形式を一から作る必要もありません。既存の仕様で十分です。

5.2 1 つだけでよいとき

• MCP だけでよい：単体 Agent で、ツールはすべて自チームの後端サービスにあり、チームをまたぐ協働がありません。もっとも一般的なケースで、保守的に見積もっても多くのプロジェクトはここまでで足ります。
• MCP と AG-UI だけでよい：単体 Agent ですが、ユーザーにプロセスを見せたい場合です。フロントの体験における投資対効果は高く、イベント層を別途導入する価値があります。
• 3 つとも必要：本当に複数 Agent の協働があり、チームの境界を越える場合です。このとき初めてアーキテクチャのコストが割に合います。

A2A を慎重に検討する価値があるシーンは 1 つだけあります。他者が提供する Agent を利用したい、あるいは自分の Agent を他者に利用させたい、しかも双方がコードベースとデプロイを共有できない場合です。もしすべての Agent が同じリポジトリ、同じオーケストレーションフレームワークの中にあるなら、A2A がもたらすプロセス境界は完全な負担です。あなたは、一度の関数呼び出しをプロトコルでエミュレートしていることに気づきます。

5.3 混在させるときに多い 4 つのアーキテクチャ臭

3 つのプロトコルを重ねたとき、最も踏みやすいのは技術的な難しさではなく構造の置き方の誤りです。以下 4 つは複数のプロジェクトで見てきました。症状はいずれも「動くが、保守コストが指数的に増える」というものです。

1 つ目は、MCP Server をマイクロサービスのゲートウェイとして扱うことです。よくある動機は「MCP が標準のインターフェースなら、ゲートウェイ層でまとめて抽象化すれば、どの Agent も同じものを使える」からです。問題は、ツールの境界と業務の境界がまったく違うものだという点です。きれいなツール一覧を揃えるために、もともと内聚していたサービスを十几個の断片化された呼び出しに分解し、パラメータをサーバとクライアントとの間で往復させ、最後に誰も敢えて変更できなくなります。私の判断はこうです。MCP Server は能力の提供側に寄り添ってデプロイすべきで、中央の層に集中させるべきではありません。それはゲートウェイではなくアダプターです。

2 つ目は、Agent の推論ループの中で A2A の長時間タスクを同期的に待つことです。順調に動いていたのに、負荷試験を掛けるとモデルの応答時間が爆発します。理由は、モデルが 3 分も要するタスクを待っているだけで、並行スロットを掴んだまま離さないからです。モデルのループは短いリクエスト駆動で回っているため、そこに長時間のタスクを押し込むと、非同期の問題を同期的な思路で処理することになります。正しいやり方は、ツールが直ちにタスクハンドルを返し、待機をオーケストレーション層に任せることです。オーケストレーション層は待機中に別の処理を行い、最終的な結果は新しいツール結果として会話に注入します。

3 つ目は、Agent ごとに 1 本ずつイベントストリームを開くことです。システムに Agent が 5 つあれば、フロントは 5 本のストリームを購読し、5 通りの接続管理と 5 通りの状態マージが必要になります。もっと悪いのは、この 5 つの Agent が同じ会話履歴を共有していて、それぞれが持つ状態が互いに衝突することです。正しい粒度はセッション単位の集約であるべきです。セッション全体を 1 本のストリームとして公開し、各 Agent の内部イベントをサーバ側でまとめてから配信します。フロントは背後に Agent が何個動いているかを知る必要がありません。

4 つ目は、ブリッジ層に業務ロジックを生やすことです。ブリッジ層でもっとも危険な誘惑は、「とにかくコードを変えるなら、ついでにここでこのエラーをどう扱うか判断しておこう」というものです。一旦そうすると、ブリッジ層は意味翻訳役から業務コンポーネントに変わってしまいます。すると下流を交換するときに業務を読み直し、ブリッジを再利用するときに業務ロジックを再読し、テストでは業務分岐のケースを書かなければならなくなります。もっとも悪いのは、そのデプロイのリズムが下流に支配されてしまうことです。ブリッジ層は業務を持たない状態を保つべきで、判断ロジックは文脈を本当に持っている層に置いてください。

六、プロトコルをまたぐブリッジ：3 つの世界を縫い合わせる

これが記事全体でもっとも実践的な部分です。現実のプロジェクトで 1 つのプロトコルだけで完結することはまずなく、ブリッジは必修科目です。以下 2 つの方向の実装が、私がもっとも実用的だと考える骨格です。

6.1 方向その 1：遠隔の A2A Agent を MCP ツールにパッケージ化する

これはもっとも一般的な需要です。遠隔に A2A の Agent があるけれど、自分の Agent フレームワークは MCP のツールしか受け付けない、という状態です。やり方は MCP Server を 1 つ書き、その各ツールが遠隔 Agent Card 内の 1 つのスキルに対応するようにします。

"""A2A -> MCP 桥接骨架

关键映射：技能 -> 工具；任务状态 -> 结果语义；
待补充输入 -> 正常返回而非错误；执行中 -> 显式任务句柄。
"""
import json, time, uuid, httpx
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("a2a-bridge")
BASE = "https://legal-agent.corp.example/"
CARD = httpx.get(BASE + ".well-known/agent-card.json").json()


def text_of(task: dict) -> str:
    """把产物里的各类片段压成给模型读的一段文本。"""
    out = []
    for art in task.get("artifacts", []):
        for p in art.get("parts", []):
            if p.get("kind") == "text":
                out.append(p["text"])
            elif p.get("kind") == "data":
                out.append(json.dumps(p["data"], ensure_ascii=False))
    return "\n\n".join(out) or "(无输出)"


def _rpc(method: str, params: dict) -> dict:
    body = {"jsonrpc": "2.0", "id": uuid.uuid4().hex,
            "method": method, "params": params}
    r = httpx.post(BASE, json=body, timeout=30)
    return r.json()["result"]


for skill in CARD["skills"]:
    @mcp.tool(name=skill["id"].replace("-", "_"), description=skill["description"])
    def _run(query: str, _sid: str = skill["id"]) -> dict:
        task = _rpc("message/send", {"message": {
            "role": "user", "messageId": uuid.uuid4().hex,
            "parts": [{"kind": "text", "text": query}]}})
        state = task.get("status", {}).get("state")

        if state == "completed":
            return {"text": text_of(task), "isError": False}

        if state == "input-required":
            # 关键判断：这不是错误，把缺口交回给模型去决策
            return {"text": "远端需要补充信息：" + text_of(task),
                    "isError": False, "needsInput": True}

        if state in ("failed", "rejected", "canceled"):
            return {"text": f"远端未成功，终态为 {state}", "isError": True}

        return {"text": "任务已受理仍在执行，请轮询 await_task。",
                "isError": False, "taskId": task["id"]}


@mcp.tool(name="await_task", description="轮询尚未完成的远端任务，最多等待若干秒。")
def await_task(task_id: str, timeout: float = 300.0) -> dict:
    deadline, state = time.time() + timeout, "submitted"
    while time.time() < deadline:
        task = _rpc("tasks/get", {"id": task_id})
        state = task["status"]["state"]
        if state == "completed":
            return {"text": text_of(task), "isError": False}
        if state in ("failed", "rejected", "canceled"):
            return {"text": f"任务终态为 {state}", "isError": True}
        time.sleep(3)
    return {"text": f"等待超时，当前仍为 {state}", "isError": False}


mcp.run(transport="streamable-http")

この骨格にはいくつかの決定点があります。テンプレートではなく判断を反映しているからです。

決定その 1：入力待ちをエラーにマップしてはいけない。最も直感的な書き方は「完了しなければ失敗」ですが、それでは A2A もっとも価値のある能力を壊してしまいます。正しいやり方は、これを正常な戻り値としてモデルに公開し、テキストの中で「遠隔が何を補足してほしいのか」を明示し、モデル自身にユーザーに尋ねるか戦略を変えるかを決めさせることです。「入力が必要」を例外として扱うと、組織をまたぐ人機協業は終わります。

決定その 2：上限のあるポーリングツールが必要。これがなければ、ツール呼び出しが際限なく吊り下がり、多くの MCP クライアントはツールのタイムアウトを乱暴に扱います。接続を切って結果を見失い、失敗としてマークすることもあります。明示的にポーリングツールを提供して、オーケストレーション層に待機時間を自分で決めさせるほうが、誠実なやり方です。同時に、ポーリング間隔にはバックオフを入れる必要があります。固定 3 秒のポーリングを数時間続ければ、下流を叩き壊します。

決定その 3：冪等性は自前で実装すること。A2A の仕様はメッセージ配信の冪等性を保証しません。呼び出しごとに新しいメッセージ識別子が生成される以上、呼び出しの繰り返しは実行の重複を生みます。ブリッジ対象のスキルに書き込み操作(チケットの起票、メール送信、注文など)が含まれていれば、これは効率の問題ではなく安全性の問題です。実務的な方法は、上流に業務の冪等キーを要求し、ブリッジ層で重複排除のキャッシュを持ち、キャッシュに明確な有効期限を設定することです。

6.2 方向その 2：MCP Server を A2A の Agent として公開する

逆方向の需要も同じくらいよくあります。外部のシステムからあなたにタスクを任せたいけれど、あなたの能力は実は一続きの MCP ツールにすぎない、という状態です。このときに必要なのは Agent Card を 1 つ生成して A2A のエンドポイントを 1 層足すことです。名刺そのものは手作業で作っても構いませんが、よりよいのはツール一覧から動的に生成して、同期が崩れないようにすることです。

ここでの最初の落とし穴は、MCP のツール説明は Agent Card のスキル説明ではないという点です。MCP のツール説明はモデルに向けたもので、正確であること、制約条件やパラメータの説明を含むことが求められます。A2A のスキル説明は「別の Agent のスケジューラ」に向けたもので、この能力が何ができるのか、いつ使うべきなのか、他の能力とどう区別するのかを説明する必要があります。直接流用すると、構文的には正しいのに情報量の何もない名刺が得られ、スケジューラは使っていいのか判断できません。

工学的に稳妥なのは、説明を 2 つ維持することです。1 つは呼び出しの契約(モデル向け)、もう 1 つは能力の説明(スケジューラ向け)です。あるいは MCP のツール説明の中で最初から 2 段書きにして、1 段目に呼び出しの契約、2 段目に適用シナリオを書き、ブリッジ層が後者を取り出して名刺を生成する方法もあります。後者の方が楽ですが、モデルには余分な文字が見えてしまうという代償があります。

2 番目の落とし穴は、タスクのセマンティクスとツール呼び出しのセマンティクスが本質的に噛み合わないという点です。MCP のツール呼び出しは同期的で短く、A2A のタスクは長時間でステートフルです。MCP Server を A2A の Agent として公開すると、大部分のスキルは 1 回の呼び出しの中で同期的に完了し、タスクは「提出済み」から「完了」へ直接飛びます。途中の「実行中」は瞬き而过るだけです。これは完全に合法であり、「タスクらしく見せる」ために人為的な遅延や状態遷移、プッシュを足す必要はありません。そうすると、インターフェースは本来あるべき姿より遅く、複雑になるだけです。

3 番目の落とし穴は粒度です。ツール 1 つをスキル 1 つにマップするのか、ツールのグループをスキル 1 つにマップするのか。私は業務能力ごとにまとめるほうに傾きます。「資産照会」を囲む一堆のツールは 1 つのスキルであるべきです。呼び出し側が考えているのは「資産を調べたい」のであって、「インタフェース 3 つを呼びたい」ではないからです。ツール粒度で名刺を公開すると、スケジューラが別のオーケストレーションエンジンになってしまいます。複雑さを他人に押し出すだけです。

6.3 方向その 3：AG-UI のイベントストリームの翻訳層

MCP と A2A を同時に使うなら、フロントは 1 本のイベントストリームだけ購読するのが望ましいです。そのために翻訳層が必要になり、MCP の通知と A2A の状態変化をどちらも AG-UI のイベントに変換します。中核となるマッピング関係は実際にごく素直です。

元のイベント	AG-UI への変換	要点
ツール呼び出しの開始	ツール呼び出し開始	後続の断片を統合できるよう呼び出し ID を付ける
ツール引数のストリーミング到着	引数の増分	断片をそのまま転送し、連結はフロントが担う
ツール実行の終了	引数終了と結果	結果には必ずエラーフラグを付け、落とさない
進捗通知	カスタムイベント	低頻度で転送し、画面を流さない
サーバからのモデル逆呼び出し	推論イベント	主モデルではなくツール内部の処理であることを明記する
タスクの状態変化	カスタムイベントと状態	状態名をユーザーが理解できる言葉に変換する
入力待ち	状態変更とユーザーへの質問	人間による介入が必要なシグナルである

翻訳層の価値は疎結合にあります。バックエンドがプロトコルを替えた、Agent フレームワークを替えたとしても、フロントのレンダリングロジックは 1 行も変えなくていい。逆句话说、この層がなければ、新しい Agent フレームワークを 1 つ導入するたびにフロントを直すことになります。多くのチームが踏んでいる穴で、しかも 3 つや 4 つのフレームワークを同時にサポートするようになったときに初めて発見され、そのときにはもう直せないのです。

翻訳層はイベントの並び順と重複除去の責任も担うべきです。MCP の通知は再接続をまたぐ順序を保証しません。A2A のプッシュは順不同で届いたり重複したりします。翻訳層は各イベントに単調増加のシーケンス番号を付け、フロントは番号に従って古いイベントを破棄し、切断後の再接続時には状態スナップショットを一度要求して位置を合わせ直すべきです。この層がないと、症状は「再接続後にメッセージの並び順が乱れる」「同じメッセージが 2 回表示される」という形になり、デモでは出ず、実際のネットワークの揺らぎのときにだけ露出します。

6.4 ブリッジサービスの可観測性と負荷試験

ブリッジ層は、システムの中で「幽霊障害」が最も発生しやすい層です。ユーザーは「AI アシスタントが壊れた」と言います。運用者がブリッジサービスを見るとすべて 200 で、ログにも正常なリクエストと応答しか残っていません。本当の失敗は下流で起きていて、ブリッジ層が忠実にそれを「成功」に翻訳してしまったからです。

したがってブリッジ層には、HTTP の指標だけでなく業務側の指標が必要です。最低でも 4 つ必要です。ブリッジの変換におけるエンドツーエンドのレイテンシ分布(上下游それぞれの報告値ではなく)、最終状態で分類したタスク数(完了、入力待ち、失敗、拒否がそれぞれ何件か)、プロトコル層のエラーコード分布、そして冪等キーのヒット率です。とくに最後の 1 つは重要です。冪等ヒット率が突然跳ね上がるなら、通常は上流が異常なリトライを続けていることを意味し、あなたの重複排除キャッシュがその問題を覆い隠しています。

トレースの関連付け方は前に述べましたが、具体的に 1 つ補足します。ブリッジ層は入口でトレース識別子を生成するか引き継ぎ、下流へのリクエストとイベントストリームの両方に注入すべきです。イベントストリームの経路はよく忘れられます。結果として、フロントはエラーを見られるのに、対応するサーバ側の呼び出しを追えず、両者のログが合わなくなるのです。

長時間タスクの負荷試験は通常のインタフェースの負荷試験とは別物です。通常のインタフェースは同時リクエスト数を測ります。長時間タスクは在途タスク数、つまり同時にいくつのタスクが実行中かを測ります。この 2 つの数字が背景で消費するリソースはまったく違います。10 分実行されるタスクは接続、メモリ、下流のクォータを消費し続ける一方、その HTTP リクエストは数秒しか続かないからです。リクエスト単位の負荷試験で長時間タスクを測ると、システムの実際の負荷を厳しく過小評価し、得られた並列数の数字を本番に持ち込めば雪崩になります。

負荷試験では意図的に障害を注入してください。下流をタイムアウトさせる、プッシュを落とす、イベントストリームを途中で切る。ブリッジ層が優雅に劣化できるのか、それとも単純に 500 を返すだけなのかを確かめます。正常系の経路だけで試験されたブリッジサービスは、ネットワークの揺らぎに初めて遭遇した時点で問題をそのまま押し付けることになります。

サーキットブレーカーについて、私の見方はやや保守的です。ブリッジ層が下流を遮断することは必要ですが、閾値は広く取り、下流が利用できない場合と遅いがまだ稼働している場合を必ず区別しなければなりません。Agent 類の下流が遅いのは常态です。そもそも考えている最中だからです。タイムアウト時間で乱暴に発動するサーキットブレーカーは、システムがもっとも忙しいときに正常な下流をすべて遮断し、かえって障害を拡大します。判断基準はレイテンシではなくエラー率であるべきです。

七、プロトコルの進化が露呈させた本当の問題

この節が記事の中核的な価値です。前の 6 節では「どうすべきか」を述べましたが、この節では「なぜあなたの実装が、ある月曜の朝に落ちるのか」を述べます。

7.1 能力ネゴシエーションの半成功の罠

MCP の初期化は唯一のネゴシエーションの機会であり、それ以降は互いに、宣言された能力が使えると双方みなします。現実には 3 種類の半成功状態がよく現れます。

1 つ目は宣言したはいが実装していない場合です。サーバが能力フィールドにモデル逆呼び出しを書いているものの、実際に呼ぶと「メソッドが存在しない」と返ってくることです。これは実装品質の問題であり、クライアントは防御的に捕捉するしかありません。さもないと 1 回の呼び出し失敗が要求チェーン全体を巻き倒します。

2 つ目は実装してはいるが宣言していない場合です。サーバはユーザー入力の照会を確実にサポートしているのに、能力に書き忘れたのです。仕様に厳密に従うクライアントはまったく呼ばないので、この機能は霧のように消えたことになり、理由を教えるログも出ません。バグの特定はきわめて困難です。すべてが「正常に動いている」ように見えるだけで、ただある周辺機能が絶対に出てこないだけだからです。

3 番目がもっとも厄介です。デグレードの契約がないということです。サーバの特定のツールは「できれば」モデル逆呼び出しをしますが、クライアントは対応していません。仕様はこの場合の挙動を定義していないので、実装はばらばらです。明確なエラーを返すもの、黙って自分でモデルを呼び出すもの、不思議な結果を返すものまであります。私の提案は、これをツール設計の硬い原則として扱うことです。選択的な依存関係にある能力には、必ず明確で文書化されたデグレード経路を持たせるという原則です。さもないとモデルは予測できない選択をし、原因の特定に長時間を要します。

A2A はこの点で扱いがよく、成果を出しています。名刺の中のストリーミングとプッシュのフラグは明確な能力宣言であり、クライアントは必要な分だけデグレードします。「能力スイッチ」ではない「複数インタフェース」という表現を使ったので、拡張性も明らかによくなります。

7.2 バージョン互換：日付バージョンとセマンティックバージョンの乖離

2 つのプロトコルのバージョン戦略は異なり、この違いはプロトコルをまたぐブリッジで実際に噛み合います。

MCP は日付バージョンを使います。利点は、バージョンとリリース時期が 1 対 1 に対応し、クライアントは自分がどの時代の仕様と対話しているかを正確に知れており、問題が起きても当時の挙動の定義を引きやすいことです。欠点はセマンティックバージョンの情報がない点で、バージョン番号だけからその変更が破壊的かどうかを知ることはできず、変更履歴を引くしかありません。初期化のときに双方でそれぞれのバージョンを報告しますが、多くの実装ではサーバ側が片手でどのバージョンを使うかを決める戦略を取っており、クライアントのバージョンが古いと問題が出ます。

A2A はセマンティックバージョンを使います。利点は、破壊的変更が理論的にはメジャーバージョンに反映されることです。欠点は、0.x の段階ではセマンティックバージョンの実際の拘束力が弱く、仕様もそれを明言しています。アップグレードで破壊が起きる可能性は残ります。

ブリッジ層における具体的なリスク：あなたのブリッジサービスは 2 つの SDK に同時に依存し、それぞれが独自のバージョン進行を持っています。MCP が新しい機能(例えばタスク化された長時間呼び出し)を導入し、ブリッジ層が「ツール呼び出しは必ず同期で返る」ことを前提にしている場合、あるいは A2A がタスクの状態集合を変更した場合、どのテストも事前に検出できません。エンドツーエンドテストで現れる症状は「ある遠隔 Agent がたまに反応しなくなる」だけだからです。

実務的な提案はこうです。ブリッジ層にバージョン表明を追加する。起動時に実際にネゴシエーションされたプロトコルバージョンを記録し、利用している機能についてホワイトリスト検証を行い、検証していない組み合わせに遭遇したら速やかに失敗させます。問題を起動時に露出させ、本番環境の片隅で静かに腐らせるようにするためです。この作業は 2 時間かかりますが、将来の数えきれないデバッグの夜を省いてくれます。

7.3 セッションと認証：3 つの非互換モデル

これはプロトコルをまたぐブリッジでもっとも厄介な部分です。3 つのプロトコルの認証モデルがまったく異なるからです。

MCP はリモートトランスポートに対して強い認証を要求します。仕様は明示的に、リモート HTTP トランスポートは OAuth 2.1 をサポートしなければならないと定めています。Server はリソースサーバとして、未認可のときに認証チャレンジヘッダ付きの 401 を返し、その中のリソースメタデータのアドレスが保護されたリソースメタデータの仕様を指し、クライアントはそれに従って認可サーバのメタデータを辿って認可フローを進めます。この仕組みは MCP コミュニティにとってプラスです。強制的に統一する方が各自で発明するよりずっとよいからです。ただし代償として、企業内ネットワークでもっとも簡単な 1 回の認証を実装するためにも、OAuth の一式を通し切る必要があるのです。やらないと非適合になります。多くのチームはこの点で妥協を選び、その後二度と戻ることはありませんでした。

A2A はこの点で完全に中立です。名刺のセキュリティスキームの宣言がそのまま現実になります。単純な API Key でもかまいません。A2A の前提は「Agent 間の認証は企業のインフラ基盤が決める」というもので、双方向 TLS とネットワーク分離などを組み合わせます。この前提は制御された内網では成立しますが、内網の外では危険です。相手が信頼されていることを前提にしているからです。

ブリッジにおける二重認証は頻出灾区です。ブリッジ。MCP を通じて遠隔の A2A Agent を公開するなら、2 つの認証を両方処理する必要があります。入向着は MCP 仕様に従ってトークンを検証し、出向着は相手の名刺の宣言に従って自分の身分を証明します。これでも面倒ですが、トークンの透過がさらに厄介です。受け取った MCP トークンは通常、下流の Agent ではそのまま使えません。トークン交換が必要か、最悪サービスアカウントで代用するしかない。

後者には安全上の問題が伴います。ブリッジ層が権限増幅器になるということです。権限の低いユーザーがあなたの MCP ツールを呼び出し、サービスアカウント経由で，本来アクセスすべきでない遠隔 Agent の能力に到達してしまう。設定の疏忽ではなくアーキテクチャの問題であり、「下流にどの身分でアクセスするか」を設計時に決めなければなりません。私の提案はこうです。入向着ではユーザーの身元トークンで認可を判断し、出向着ではサービスアカウントで実行し、認可判断はブリッジ層に残して、身分変換のたびに明示的に記録してください。身分が暗黙に貫通するようにしないでください。

セッション粘性はもう 1 つの高頻度事象点です。MCP のセッション識別子はサーバ側の状態です。Server を 3 つのレプリカにすると、クライアントの 2 番目のリクエストが別のレプリカへルーティングされ、セッションは直接失効します。対策は 3 つあります。整合性ハッシュによる粘性、セッション状態を共有ストレージへ外側化すること、あるいは単純にステートレスとして実装することです。もしあなたの Server が論理的にもともとステートレスなら、3 つ目がもっとも楽です。セッション識別子を、どのレプリカでも認識できるトークンとして扱い、状態を保持するハンドルとして扱わないのです。

7.4 エラーのセマンティクスが不統一：地雷を埋めるもっとも一般的な場所

3 つのプロトコルは「誤り」をまったく違う方法で表現します。これらを混同することは、プロトコルをまたぐシステムでもっとも頻出するバグの原因です。

MCP には 2 つのエラー体系があります。プロトコルレベルのエラーは JSON-RPC のエラーオブジェクトを通り、パース失敗、メソッドが存在しない、引数が不正、内部エラーなどを含みます。ツールレベルのエラーは結果の中のエラーフラグフィールドを通り、内容はその結果のコンテンツに置かれます。両者のセマンティクスはまったく違います。前者は「呼び出しが成功しなかった」、後者は「呼び出しは成功したが業務が失敗した」です。この区別は極めて重要です。リトライ戦略がまったく違うからです。前者は通常リトライすべきではなく、後者はしばしばリトライすべきだからです。

A2A の場合はこうです。プロトコルレベルのエラーは JSON-RPC のエラーオブジェクトを通り、業務上の失敗はタスク状態の中の失敗状態として表現され、理由はステータスメッセージに置かれます。さらに「拒否」は独立した終端状態で、リクエスト自体が不正であることをたとえば、タスクが既に存在する、能力が非対応、などを表します。

AG-UI には出口が 2 つしかありません。エラーコードと説明を持つ実行エラーイベント、そしてツール結果の中のエラーフラグです。途中の回復可能なエラーにはまったく表現の手段がありません。

マッピングのときにもっともよくある誤りは次の 3 つです。

誤り 1：MCP のツール失敗を A2A の成功にマップしてしまう。MCP がエラーフラグ true を返したとき、ブリッジ層が JSON-RPC 層にエラーオブジェクトがあるかどうかしか見ていないと、呼び出しは成功したと判断し、結果を通常の成果物として返してしまいます。相手の Agent はタスクが成功したと思い込み、エラーメッセージを結論として受け取ります。業務上は直接エラーを出すより悪いことです。エラーが後続のフローに本物として扱われるからです。ブリッジ層はエラーフラグを必ず確認し、失敗または拒否の状態へマップしなければなりません。

誤り 3：エラーメッセージをそのままモデルへ透過してプロンプトインジェクションを起こす。ツールのエラーメッセージ、特に外部システムから来たものは、そのまま会話の文脈に連結されます。遠隔サービスが指示を含むテキストを返した場合、モデルはそれをユーザーの命令として実行する可能性が高いのです。信頼境界をまたぐすべてのツール戻り値は、エスケープと出所の注記を施し、それが命令ではなくツール出力であることを明示しなければなりません。これはプロトコルの問題ではなくセキュリティのベースラインですが、ブリッジを作るときは容易に漏らします。コードの上では単なる文字列連結にしか見えないからです。

7.5 トランスポート層の選択：2 つのイベントストリームの罠

MCP のストリーミング HTTP と AG-UI のサーバー送信は、どちらも「イベントストリーム」に見えますが、挙動の違いは大きく、混在させると非常に紛らわしい現象が起きます。

MCP のストリーミング HTTP は双方向です。クライアントが POST で上り、サーバがイベントストリームで下り、切断からの復旧はクライアントが最後のイベント ID を携えて再送を要求します。しかも再接続をまたぐ順序は保証されません。セッション粘性が絡み、リバースプロキシはバッファを無効に、読み取りタイムアウトを大きくする必要があります。

AG-UI のイベントストリームは主に一方向です。サーバがフロントへ送り、ユーザーの指示は別の経路を通します。復旧は通常、状態スナップショットを引き直すことで位置を合わせます。順序は実装側がシーケンス番号フィールドで自力で保証します。

A2A のストリーミングメソッドは 3 つ目で、ここでもセマンティクスが違います。したがってツールをデバッグするときは、必ず心の中で「今つないでいるのはどのプロトコルのストリームか」を明示してください。半日かけて調べた問題が、実際にはフロントのポートを間違えていただけだったという例も見てきました。2 つのプロトコルのイベントストリームが同じドメイン名下にあり、ルーティング規則を 1 つ書き間違えていたのです。

もう 1 つは純粋に運用レベルの落とし穴です。同じシステムの中に MCP のストリームと AG-UI のストリームが同じリバースプロキシを抜けると、バッファ設定と読み取りタイムアウトはパスごとに別々に設定する必要があります。既定の読み取りタイムアウトは長時間タスクのシーンでは接続を直接断ち切ります。この種の問題はローカルの開発機では再現しません。そこにプロキシがないためです。内網にデプロイすると「しばらく動いたのち切れる」ようになります。

7.6 長時間タスク：3 つのプロトコルともあまり良くない

率直にいって、長時間タスクはプロトコルの進化の中で露呈した最大の工学的な穴です。

MCP には一等のタスク抽象がありません。ツール呼び出しは同期で返すか、進捗通知でクライアントに「まだ生きています」と知らせるかのどちらかです。より新しい仕様バージョンでは、この穴を埋めるために実験的なタスク化呼び出しが導入されました。ただし実装の対応度はまだ高くなく、来年までにエコシステムが統一するとは期待できません。

A2A のタスクが正解にもっとも近い形态です。識別子があり、状態機械があり、照会とプッシュのメソッドがあります。問題は状態がサーバ側にあり、クライアントはしばしば持続接続を確保できないため、「タスクの作成には成功したけど、ポーリングのリクエストが別のレプリカに飛んだ」という事態が起きることです。

AG-UI はこの問題をまったく解決しません。Agent ランタイムがクライアントからいつでも再接続できる存在だという前提に立っています。この前提自体に文句はありませんが、すでに 5 分動いているタスクの文脈を回復してくれるわけではありません。

実務的なやり方は 2 つあります。1 つ目は長時間タスクを「タスクの作成」と「タスクのポーリング」のツールの組として明示的にモデル化することです。待機ロジックはオーケストレーション層に自分で持たせ、プロトコルがレジューム機能を提供することを期待しなくてよいのです。

もう 1 つの道は、キューを使うことです。ツール呼び出しを受けたブリッジ層は実際の実行をメッセージキューへ投げ、直ちにタスクハンドルだけを返します。クライアントは別のポーリングツールで結果を受け取ります。この設計は、プロトコルの外側に自分用のタスク管理を持ち込むことに他なりません。見通しが立つ限りの将来、これは必須であり続けるでしょう。プロトコルの解決を待つより、今すぐ自分で解くほうがよいです。待つ余裕がないからです。

7.7 可観測性：3 つのプロトコルとも穴を残している

最後に、3 つをまたぐ工学的な問題を 1 つだけ挙げます。可観測性です。

MCP のツール呼び出しは、サーバ側の視点では単なる JSON-RPC メソッド呼び出しであり、クライアント側の視点では 1 回のツール実行です。トレースの中で「なぜモデルがこのツールを呼び、どんな引数を渡したのか」を復元するには、その時点の文脈(当時の会話、当時のシステムプロンプト)を紐付ける必要があります。仕様はトレース文脈を渡す標準的な方法を用意していません。メタデータのフィールドはトレース識別子を仕込むのによい場所ですが、あなたが明示的に実装して初めて機能します。

A2A のコンテキスト ID とタスク ID は本質的にトレースの関連付けに適していて、MCP より優れています。AG-UI のセッション ID と実行 ID も同じです。

推奨するやり方はこうです。ブリッジ層に識別子の対応表を作り、1 回のユーザー操作から生まれた MCP の呼び出し、A2A のタスク、フロントのイベントストリームが、同じトレースの根を共有するようにします。このことは早ければ早いほど楽です。プロトコルの実装が 3 つのフレームワークに散らばってから統一トレースを考えた時点ですでに手遅れです。3 つのフレームワークの内部構造をすべて把握しないと、計測を差し込むことができないからです。

7.8 サプライチェーンリスク：MCP Server は新たな攻撃面です

この節はセキュリティと直接は関係しませんが、現実のプロジェクトでは相互運用性そのものよりも事故起こりやすいことが相場です。MCP Server の本質はモデルに駆動される任意のコード実行面です。モデルが信頼できないテキストを読み、どのツールを呼ぶかを決め、そのツールが実システムを操作します。ウェブページやメール、チケットに隠れた注入命令は、理論上、あなたのファイルシステムやデータベースまで届きます。

防御は 3 層で必要で、1 つでも欠ければ足りません。

第 1 層は能力の最小化です。読み取り専用のツールと外部の状態を変えるツールを分けてデプロイし、分けて認可し、できれば別のプロセスで動かします。そうすれば読み取り側が完全に侵害されたとしても、攻撃者が得られるのは読み取り権限だけです。この層のコストはプロセス分割による複雑さですが、「最悪の場合」を「全面的な陥落」から「情報の漏えい」にまで引き下げられる唯一の措置です。

第 2 層は入出力の双方向検証です。内側に対しては、パスを必ず正規化し、クライアントが宣言した境界の内側に収まっているかを確認します。シンボリックリンクと相対パスの連結に注意してください。外側に対しては、すべてのツールの引数を宣言どおりの構造で厳格に検証し、すべての戻り値に出所を付記して、命令として読み戻されることを防ぎます。戻り値の出所付記はとくに重要です。「ツールの戻り値に命令を仕込む」というもっとも隠れた攻撃経路を塞いでくれるからです。

第 3 層は人間によるゲートです。削除、決済、外部の人へのメッセージ送信、権限変更。这类不可逆で外から見える操作は、モデルがどれだけ実行したくても、必ず確認を通さなければなりません。重要なのは確認画面が「Agent の操作を許可しますか」のような情報量ゼロのボタンではなく、何が起きるのかを示すことです。ユーザーが確認を押すときに何を承認しているのかを必ず知っていなければ、このゲートは形式にすぎません。

サプライチェーン自体のガバナンスも省けません。MCP Server は最新版を引くのではなくバージョンを固定し、公開時には署名とチェックサムを付け、インストール前に依存ツリーをレビューするべきです。コードベースを読み書きできるパッケージを最新版でインストールすることは、多くのチームが開発機に残している時限爆弾です。ローカルにパスの境界保護があればまだよいのですが、CI の自動実行環境には何も設定されていないことがほとんどです。

A2A 側のリスクは対称的ですが、姿が異なります。遠隔の名刺は信頼できない入力であり、サービスアドレスは出向きホワイトリストを通さなければなりません。そうしないとあなたのシステムはリクエスト偽造の増幅器になります。相手が返したタスクメッセージにデータ断片が含まれていても同様に出所を付記し、そうでなければそれがユーザーの命令に偽装してあなたの Agent に影響を与えられます。より隠蔽された種類は、相手の Agent の行動が汚染されたうえで、通常のタスク結果を通して悪意ある内容を「正当に」あなたのシステムへ持ち込むというものです。この経路のどの信頼境界でも、信頼の前提が壊れます。

最後の赤線は、私がすべてのセキュリティの議論のなかでもっとも重要だと思う一文です。「自然言語の入力を受け付ける」ことと「システムの操作を実行する」ことの組み合わせには、必ず人間のゲートが要ります。このルールはプロトコルとは無関係で、MCP であれ A2A であれ自前のフレームワークであれ同様に適用されます。そして、現実にもっともこのルールを破りやすいのは、認証もサンドボックスもプロトコルの整合性もすでに済ませたつもりでいるチームです。認証が管理するのは「誰が呼んでいるか」で、ゲートが管理するのは「やってよいか」です。この 2 つはまったく重なりません。

7.9 キャンセル、タイムアウト、リソース回収：もっとも忘れられがちな輪

Agent プロトコルに関する議論はほとんど「どう開始するか」と「どう返すか」を扱っており、どう止めるかを話す人はほとんどいません。まさにそこが、本番環境でもっとも事故が起きやすい部分です。

長時間タスクのライフサイクル之中には、少なくとも 4 つの層でキャンセルを考える必要があります。ユーザーが中止ボタンを押した、オーケストレーション層がタイムアウトを判断した、クライアントの接続が切れた、そして上流のサービス制限が自己保護を発動した。その 4 層のキャンセルシグナルが最下層の実際の実行まで届くかどうかは、まったく別の問題です。

よくあるのはこういう状況です。ユーザーが中止した、フロントは確かに表示を止めたが、下流のタスクは動き続け、モデルのクォータとデータベースの接続を消費し続けている。数分後、運用者が「幽霊タスク」の山を見つけて手作業で片づける。この種の漏えいはトラフィックのピーク時に急速に積み上がり、しかも監視の上では見えません。それらのタスクの呼び出し経路上では、すべてのノードが「成功」と表示しているからです。

改善点は 3 つあります。1 つ目はキャンセルをすべての層で明示的に通すことです。中止シグナルはイベントストリームから A2A のキャンセル API まで、さらにツール内部の実行文脈まで届かなければなりません。ある層が下流に通知せずに「待機をやめる」だけなら、それは諦めており、キャンセルではありません。

2 つ目は、タイムアウトはサーバ側で強制実行し、クライアントの待ち時間ではないことです。クライアントが接続を切れたら待ちをやめる、という実装はよく見られるものです。しかしそれでは、サーバのタスクは決して自分で止まりません。正しいやり方はサーバ側にも独立したハードタイムアウトを設け、期限が来たら自分で終了してリソースを解放することです。誰も待っていなくても同じです。

3 つ目は、在途タスクに総量の上限を設けることです。同時に在途しているタスク数がある閾値を超えたら、新しいリクエストは速やかに失敗するかキューに並ぶべきです。全部を受け付けてから一斉に遅くなるのではありません。これはデータベースのコネクションプールの保護ロジックとまったく同じもので、しかし多くの人は Agent のシナリオにこのゲートを足すことを忘れます。下流を叩き壊してから気が付くのです。

忘れられがちな細部が 1 つあります。キャンセル自体の戻り値もツールが転述できる必要があります。ユーザーが会話の中で「やめて、まず変更しないで」と言ったとき、モデルが受け取るのは「タスクはキャンセルされ、いかなる変更も発生していない」という明確なメッセージでなければなりません。空白のエラー説明ではありません。この区別はモデルのその後の判断にとても重要です。モデルはこのことを根拠に「前回の操作は確かに反映されていない」とユーザーへ伝えられます。ユーザーが中間状態なのかどうかを不安にならなくて済むからです。

最後の経験談です。キャンセルとタイムアウトを正常系としてテストしてください。成功系だけをテストしないでください。テストケースに「実行の途中でキャンセル」を 1 組加え、下流のリソースが本当に解放されたか、状態が整合しているか、帳尻が合っているかを確認します。この種のテストはたいてい本質的な問題を即座に見つけます。そしてそれは、チームが自分のシステムにキャンセルのセマンティクスを設計する必要があると初めて気づく瞬間でもあります。

八、実務的な選定の助言

8.1 制約からプロトコルを逆引きする、プロトコルから制約を引き返さない

「どのプロトコルがよいか」から出発しないでください。あなたの具体的な状況から出発してください。

あなたの状況	助言	理由
単体 Agent、ツールは自社バックエンドのみ	MCP だけ入れる	他のプロトコルは純粋なコスト
ツールを他のチームが保守している	相手に MCP Server を提供してもらう	Agent ごとの個別接続より桁違いに安い
ユーザーに過程を見せる必要がある	イベントストリーム層を加える	フロント体験への重要な投資
第三者の Agent と接続する必要がある	A2A でブリッジを書く	まさに A2A が存在する理由
他者に自分の能力を呼び出してほしい	相手のプロトコルで公開する	エコシステムは広く MCP を使い、相手が Agent なら A2A を使う
すべての Agent が同じリポジトリと同じフレームワーク	A2A を使わない	プロセス内で直接呼べばよい
会社や組織をまたいで協働する	A2A に厳格なセキュリティモデルを足す	内網の前提が成り立たず、明示的な認証が必須
Agent がファイルやネットワークに触れる	どのプロトコルでも境界検証を行う	プロトコルがその作業を代行してはくれない

8.2 3 つとも使うなら、推奨する進め方

第 1 歩、まず MCP の接続層を作ります。コードに散らばったツール呼び出しを MCP Server にまとめます。消費者が自分 1 人しかいなくてもやる価値があります。ツールの説明をはっきり書かざるを得なくなるからです。それ自体が AI コードの品質を大きく引き上げるからです。私が見てきた MCP をうまく使いこなしているチームは、例外なくツールの説明に費やした労力が、実装そのものよりずっと多かったです。

第 2 歩、次にフロントのイベント層を作ります。AG-UI のイベントモデル、あるいはそれと等価な自前のものを用いて、Agent ランタイムを公開します。この一歩でフロントと Agent フレームワークが切り離され、以降のすべての進化の土台になります。

第 3 歩、最後に A2A です。本当にプロセスやチームをまたぐ Agent の境界に直面したときだけ入れてください。早くに A2A を入れると、システムの複雑さは 2 倍になり、成果はゼロです。これは複数 Agent のプロジェクトで見てきた、もっとも一般的な誤った意思決定です。

全工程を通して：ブリッジ層の接口は初日から用意しておく。今は MCP だけでも、ツール呼び出しを内部の統一表現に変換するという工程を抽出しておいてください。後から A2A を接続するときにはアダプターを 1 つ増やすだけで、呼び出しの連鎖全体を書き直す必要がなくなります。この抽象のコストはおよそ 100 行から 200 行のコードで、得られるものは、プロトコルを拡張するときに省ける数日の作業です。

8.3 明確にやってはいけないこと

• 見栄を張りたいがために MCP で包まない。すべての内部関数を MCP Server で包み、さらに自分で大量のプロセスを立ち上げてそれを呼ぶ。これは純粋な自傷です。MCP の価値は境界の横断に 있으며、境界の内側では間接層にすぎず、レイテンシと障害面を増やすだけです。

• 単一の Agent に十几個の MCP Server を掛けない。ツール数が増えると、モデルの誤選択率が大幅に上昇します。加えて各 Server は独立した接続、認証、ライフサイクルを持つため、管理コストは掛け算になります。十几個の厳選したツールだけを外部に公開する、ツール集約 Server を 1 つ作るほうがよいです。

• Agent Card を信頼可能な入力として扱わない。遠隔の名刺は对方が提供した設定であり、本質的に信頼できません。中のサービスアドレスをそのまま従うことはできず、必ず出向きホワイトリストで検証しなければなりません。そうしないとあなたのシステムはリクエスト偽造の増幅器になります。スキル一覧とセキュリティスキームも同様で、相手が自由に書くと仮定すべきです。

• ブリッジ層で暗黙のリトライをしない。ブリッジ層がタイムアウトを見たらリトライする、という実装は、下流が書き込み操作の場合、重複した副作用を生み出します。加えてリトライは下流の本当の健康状態を覆い隠します。問題が露出したときには、もうトラフィックが増幅された後です。すべてのリトライは明確な冪等キーで保護し、既定では無効にしてください。

• フロントをあるイベント形式に縛りつけない。AG-UI を採用すると信頼できるとしても、サーバ側の集約層に独自のイベントモデル変換を置くことを勧めます。理由は単純です。Agent フレームワークの更新頻度は、プロトコルの進化頻度よりはるかに高い。遅かれ早かれ適合層を書き直す日が来る。そのときフロント動かせるかどうかは、今日この抽象を残したかどうかで決まります。

8.4 自分で点検できる成熟度モデル

L0：裸奔期。ツールが Agent にハードコードされ、エラーはログを刷って対処する。――この段階では MCP を作り、他のことを考えなくてよいです。一度で済ませてください。

L1：接続期。MCP Server が揃い、ツールの説明がはっきり書かれており、バージョン管理があり、基本的な構造化出力がある。――この時点でイベントストリーム層を作り、ユーザーが過程を見られるようにします。

L2：可視化期。イベントストリームがあり、状態スナップショットがあり、フロントが中間状態を表示でき、ツールの承認ができる。――この時点で実際に複数 Agent のニーズが出てきたなら、A2A の評価を始めます。まず読み取り専用の名刺プローブを 1 つ書いて、相手のエコシステムとツールチェーンの成熟度がどの程度かを見てみましょう。

L3：協働期。本物の組織をまたぐ Agent 協働があり、冪等性の保護、明確な認証境界、エンドツーエンドのトレースがある。――この水準に達していれば、本文で議論した落とし穴は少なくとも一度踏んでいるはずです。まだ踏んでいないものが残っているなら、まだそのシナリオに遭遇していないだけです。

8.5 着手前の自己点検リスト

最後に、そのまま持っていく使えるリストを 1 枚。それは「問題が起きたときの損失の深刻さ」で並べたもので、先にあるものほどうまくいなければ代償が大きくなります。

ツール説明の質。各ツールの説明は、引数の名前の復唱ではなく、何の問題を解決するかを書いていますか。このツールが適用されないシーンも書いていますか。この一文は、正面の説明より誤選択を減らすことがあります。説明の中に実在する呼び出し例が 1 つ以上入っていますか。「必ず」「ただし」「使うな」のような語があれば、作者が境界を考えていたという証拠です。

ツール数は収束していますか。1 つの Agent が見えるツールが 20 個を超えていれば、集約層を検討すべきです。これは潔癖ではありません。ツールのリストが長いほどモデルの注意は散り、誤選択率が上がるうえ、リクエストごとのコンテキストコストも同時に増えます。

境界とセキュリティ。ファイル系のツールはパスの正規化と境界検証を行い、シンボリックリンクと相対パスは妥善に処理されていますか。読み取り能力と書き込み能力は別のプロセスに配置していますか。読み取り専用ツールの戻り値には、注入を防ぐ出所の注記が付いていますか。高リスクの操作には人間のゲートがあり、ゲート画面が具体的な動作を表示していますか。MCP Server の依存はバージョンを固定し、レビュー済みですか。

外部の Agent と接続しているなら、相手の名刺にあるサービスアドレスは出向きホワイトリストを通っていますか。ブリッジ層は身元の変換をすべて明示的に記録していますか。入向着のユーザーの権限は、本物の下流の認可範囲に収まっていますか。最後の一問は自分自身に必ず突きつけてください。もっとも権限の低い社員があなたのブリッジツールを呼んだとき、サービスアカウントを通じて何に手が届くのか。

エラーとデグレード。各ツールは失敗時に何を返すか、モデルはそれでどう対応すればいいかを知っていますか。エラーメッセージはリトライ可能と不可能を区別していますか。ツールが依存する選択的な能力には明確なデグレード経路があり、クライアントが非対応でもそのまま例外を投げずに済みますか。プロトコルをまたぐブリッジで、3 つの終端状態はすべて正しくマップされていますか。とくに「入力待ち」を誤って失敗として扱っていませんか。

長時間タスクのタイムアウトとキャンセルは伝播しますか。ユーザーが中止したとき、下流のタスクは本当に止まったのか、それともフロントの表示だけが止まったのか。モデルが待機中に割り込まれた場合、その在途タスクは孤児になりませんか。

可観測性。1 回のユーザー質問から出発して、全体の連鎖を復元できますか。モデルがなぜそのツールを呼び、その後に何が起こり、イベントストリームがどうフロントへ配信されたのか。連鎖上の 3 つのプロトコルの識別子は、同じトレースの根に相互にマップされていますか。ブリッジ層の業務指標(終端状態の分布、冪等ヒット率)を見ていますか。HTTP のエラー率だけを見ていませんか。

プロトコル互換性。起動時に実際にネゴシエーションされたバージョンを検証しましたか。使っている高度な機能はサポートマトリクスに載っていますか。クライアントが選択的な能力を サポートしないとき、システムは依然として利用可能ですか。プロトコルのアップグレードに、すぐにロールバックできるバージョンはありますか。

このリストの前 3 グループは「やないと事故になる」もので、第 4 グループは「やると痛い」ものです。時間が 1 つしかないなら、まずツール説明の質の監査から始めることを勧めます。コストがもっとも低く、効果がもっとも速く、それでいて以降のすべてのデバッグ体験に反映されます。

おわりに

最初の問いに戻ります。MCP、A2A、AG-UI はどう選ぶべきか。

私の答えは 1 文字で「全部」です。ただし、同時に全部を入れろという意味ではありません。それぞれがスタックのどの段を占めるのかを見極め、必要な段で真摯に守ることです。

MCP は能力を再利用できるようにし、A2A は Agent を委託できるようにし、AG-UI は過程を見えるようにします。この 3 つは地味に聞こえますが、それぞれが解決しているのはゼロから 1 へというアーキテクチャ上の問題です。プロトコルの価値は、仕様書がどれだけ完備に書かれているかにはなく、異なるチームがそれぞれに進化しながら、毎回会議をしなくても済むようにすることにあります。午前 3 時に「なぜロードバランシングの後でセッション識別子が失効するのか」を追跡しているとき、これらの仕様の些細に見える条項がいかに重要かが痛感されます。

最後に、実務的な忠告を 1 つ。プロトコルは手段であり、相互運用性が目的です。プロトコルを使うがためにプロトコルを使ってはいけません。境界の内側では、プロセス内の関数呼び出しがいつだってもっとも速いです。プロトコルの価値は境界の上でのみ現れます。「あるプロトコルを正当に使う」ために、得られるものをはるかに超える工学的コストを払っていることに気づいたら、たいていはアーキテクチャが境界を間違えたのであって、プロトコルを間違えたのではありません。