つながった後に、誰が何を待つのか

返金の問い合わせを受け、請求書を探し、例外規定を調べ、利用者に金額を提示する。 この想定業務を複数のサービスへ分けると、通信が成功しても「どこまで終わったか」が分からなくなる。 調査担当から返金案が届いた段階なのか、利用者が承認したのか、実際に返金されたのか。 同じ完了表示でも、次に動く人の仕事は違う。

AWSは3月13日、AgentCore Runtimeで、既存のMCPとA2Aへの対応に加えてAG-UIをサポートすると発表した。 ツール、別のエージェント、利用者の画面を、共通仕様で接続できる範囲が広がっている。 ただし、この発表は各接続の機能を説明するもので、返金業務が速くなったという測定ではない。

本稿の判断は、共通プロトコルの価値を、対応する名称の数よりも、仕事の途中と結果を別の実装へ渡せることに置く、というものだ。 その価値を得るには、呼び出し、調査、表示のそれぞれが伝える完了の範囲をそろえ、利用者が待つ理由と次の行動を理解できるようにする必要がある。

MCPはツールの入出力をそろえる

MCPの2025-11-25版のツール仕様は、ツールの一覧、入力の形式、呼び出し、結果の返却を定める。 請求書検索なら、依頼側は必要な検索条件を渡し、接続先の結果を受け取る。 内部でデータベースを読むかAIで調べるかは、ツールの実装次第である。 相手がAIを使っているという理由だけでは、A2Aを選ぶ根拠にならない。

結果の形式を示すoutputSchemaは任意だが、指定する場合、サーバーはそれに合う構造化結果を返す必要がある。 また、呼び出し自体の形式の問題と、ツールが実行中に返すisErrorによるエラーは区別される。 受け取り側がこの違いを保てば、検索で何も見つからなかった場合と、検索サービスを呼べなかった場合を別に扱える。

それでも、金額欄が数値であることは、正しい請求書を選んだことを証明しない。 想定例では、請求番号、対象期間、通貨と金額を確かめ、検索結果を返金の根拠へ結び付ける処理が必要になる。 ツールの返却を、返金全体の完了に読み替えてはいけない。

A2Aは、相手の作業をタスクとして追う

請求書の取得だけでなく、例外規定を調査する担当へ依頼するなら、途中で不足情報を求められるかもしれない。 3月12日に公開されたA2A 1.0は、こうしたエージェント間のやり取りの安定版として発表された。 以前の0.3系からは変更があり、告知は両版を提示して段階的に移行する方法も説明する。 安定版という位置付けは、あらゆる接続相手との互換性を保証するものではない。

1.0.0の仕様では、Agent Cardが相手の能力や接続方法を記述し、タスクの状態と成果物を受け渡す。 追加情報を待つ状態もあり、同じタスクへの回答を、タスクと会話の識別子で結び付けられる。 調査担当の内部実装を直接操作せずに、依頼、確認、結果の受け取りを続けられる構成である。

想定業務で「どの契約条項を適用するか」を聞かれたなら、利用者の回答をその調査へ戻す。 別の新規依頼として送り直すと、前の調査が残ったまま二つの作業が進む可能性がある。 一方、調査タスクの成功は、調査としての成功を示す。 返金案の成果物を受け取っても、送金まで済んだとは限らない。

Agent Cardに「請求調査」と書かれていることも、調査品質の証明ではない。 利用者の依頼をどの担当へ渡すかを選ぶ情報と、その担当の結果を採用できるかの検査は別になる。 共通形式は相手を呼ぶための足場を作り、結果の意味は業務側で確かめる。

長時間処理だけで仕様を選ばない

MCPにも、処理状況を追って後から結果を取得する実験的なTasks機能が2025-11-25版で導入されている。 対応する能力を両端で確認する必要があり、同じ版を名乗るすべてのサーバーが、一覧取得や取消まで実装しているとは限らない。 したがって「長く待つならA2A」という単純な分け方はできない。

決められた請求書検索の結果を後で受け取るだけなら、タスクに対応したツールで足りる場合がある。 相手の能力を調べ、途中の質問へ答え、会話と成果物を伴う調査を任せるなら、A2Aのやり取りが比較対象になる。 これは本稿の選択の視点であり、三つのプロトコルが重なりのない三層を定めているという説明ではない。

取消にも注意が必要だ。 MCP Tasksは、有効な取消要求に対して取消済みの状態へ移すことを要求する一方、実行が続いてしまった場合もその状態を維持すると定める。 画面で「取消済み」と表示されても、外部への返金が取り消されたとは言えない。 停止の要求、処理が止まった証拠、済んだ処理を戻す手続きは、それぞれ確認する必要がある。

AG-UIは、画面に届く出来事をそろえる

利用者にとって、調査が動いていることと、判断できる結果が届いたことは違う。 AG-UIの3月28日時点のイベント文書は、処理の開始や終了、文章の断片、ツール呼び出しと結果を画面へ伝える出来事を定義する。 重要なのは、ツール呼び出しの引数を送り終えたTOOL_CALL_ENDと、実行結果を届けるTOOL_CALL_RESULTが別だという点だ。

想定例で画面が前者だけを見て「返金完了」と表示すれば、利用者は手続きを終えたと思ってしまう。 処理単位の終了も、依頼全体の成功に直結するとは限らない。 調査結果が届いたときには「返金案を確認してください」、追加情報を待つときには「契約を選択してください」と示せるよう、出来事を業務の状態へ対応させる必要がある。

承認ボタンの表示からも、実行側の認可は生まれない。 返金する請求、金額、宛先と、承認した人を実行側で対応させる設計が要る。 画面への表示、利用者の回答、返金の実行結果をつなぐ部分は、アプリケーションが引き受ける。

同じ返金依頼を、四つの受け渡しで追う

請求情報を取得する

MCPのツールへ検索条件を渡し、請求番号、期間、通貨と金額を受け取る。取得失敗と該当なしを分け、後の調査が同じ請求を扱えるようにする。

例外規定を調べる

A2Aで担当へ調査を依頼し、タスクと会話を追う。不足情報への回答を元の調査へ戻し、返金案と判断の根拠を成果物として受け取る。

利用者の次の行動を示す

AG-UIの出来事と状態を、調査中、回答待ち、案の確認へ対応させる。利用者が待つだけでよい場面と、入力すべき場面を区別する。

実際の返金結果を確かめる

アプリケーションが承認内容と実行を結び付ける。結果が不明なら確認中として扱い、画面を閉じたことや返却メッセージだけで成功や失敗を決めない。

この四つは、仕組みの比較を説明する想定例だ。 四つのエージェントや、三つすべてのプロトコルを導入する要件ではない。 同じ請求と依頼を追える情報を渡すと、担当者は各サービスのログを最初から突き合わせる負担を減らせる可能性がある。 その効果は、実際の処理と担当者の確認時間で確かめたい。

切断後も、結果を確かめられるか

利用者が画面を閉じたり通信が切れたりしたとき、途中の表示がすべて再送されると考えてはいけない。 A2A 1.0の仕様は、再接続後にすべての状態メッセージを受け取れるとは限らず、メッセージを重要情報の確実な配送手段として扱ってはいけないと定める。 想定業務では、調査の識別子から現在のタスクや成果物を再取得し、業務の記録と照合する設計が必要になる。

AG-UIの状態の同期には、現在の全体を置き換えるスナップショットと、順番に適用する差分がある。 画面と実行側の状態が食い違った場合には、新しい全体状態を取り直す考え方が説明されている。 ただし、取り直した画面の状態が、外部の返金結果まで正しく含むかは別に確かめる必要がある。

返金の応答だけが届かなかった場合、失敗と決めて新たに返金すると、二重処理になり得る。 再接続した利用者には、元の依頼の結果を確認していることを伝える。 請求や金額を変えた提案については、前の承認をそのまま使わない。 共通の通信形式を使っても、依頼の継続と新しい処理を区別する仕事は残る。

必要な接続から始め、変更の影響を測る

既存の検索APIと画面で請求書を見つけられるなら、それを基準にする。 別の担当へ調査を任せる必要があるときにA2Aを、複数の実行環境から同じ画面へ進捗を届けたいときにAG-UIを比較する。 AWSの対応発表もA2Aの版を指定していないため、A2A 1.0への対応まで推定せず、両端の版と任意機能を確認する。

試行では、通常の調査に加え、不足情報への回答、途中の切断、取消、接続相手の変更を含めたい。 最終結果が正しいかとともに、人が待った時間、入力をやり直した回数、結果を再調査した時間を見る。 担当エージェントを交換したとき、画面や請求検索までどこを直す必要があるかも確かめる。 これは検証案であり、特定製品で改善を実測した結果ではない。

共通仕様によって、接続先の変更を限られた範囲で扱えるなら、利用者の仕事を保ったまま仕組みを更新しやすくなる。 逆に、途中の状態が曖昧で人が確認し直すなら、接続が増えても負担は減らない。 プロトコルを選ぶ際は、何を受け渡せるかに加え、その受け渡しによって次の人が迷わず仕事を進められるかを判断したい。