AI Agents 調査対象日 2025年5月1日最終更新 2026年10月11日

A2Aで別のAIエージェントへ依頼するとき、何を引き継ぐか

読了目安 8分

A2A、Google ADKとAgent Engine、Semantic Kernel Agents、Bedrockの休暇申請例を比較。別基盤への接続から、人の編集後の再検証、承認待ち、保存結果まで依頼を引き継ぐ条件を考える。

依頼を引き継ぐ

担当がつながっても、利用者には仕事の行き先が見えない

「来月、3日間休みたい」。社内アシスタントが残日数を調べ、申請内容を整えてくれる。それでも、利用者が知りたいのは、申請案ができたのか、上長に届いたのか、休暇が承認されたのかという違いだ。これは複数システムを組み合わせる設計の想定例である。応答を返す担当が増えても、この違いが消えれば、利用者は人事システムを開き直して確かめることになる。

4月9日にGoogleが発表したAgent2Agent（A2A）は、異なる基盤のエージェントへ依頼を渡す方法を提示した。同じ日のVertex AIの発表は、開発の枠組みと管理された実行環境を示している。 MicrosoftのSemantic Kernel Agentsの一般提供、AWSの人による確認の実装例も合わせると、開発、接続、配備、確認を組み合わせる選択が具体的になる。

本稿の判断は、組み合わせやすさを仕事の引き継ぎやすさへ変えるには、依頼の意味と完了条件も受け渡す必要があるということだ。相手を呼べること、応答を待てること、変更を確認することは、それぞれ前進になる。その間で利用者の意図が変わった場合に、誰が検証し直すかまで設計すると、接続の価値を説明できる。

相手に仕事を依頼する

A2Aは、呼び出す方法に加えて依頼の進み方を扱う

A2Aの発表では、依頼側と実行側のエージェントが、能力、タスク、メッセージ、成果物をやり取りする。能力を知らせるAgent Cardには、相手が何をできるかを記述する。タスクは短時間で終わる場合も、人の参加を含めて長く続く場合もあり、その間の状況を伝えられる。結果は成果物として返す。この設計は、単に一度の応答を受け取るAPI接続から、仕事を預けて進捗を追う接続へ考える範囲を広げる。

Googleは候補者探索を説明例にしている。利用者の条件を受けた担当が別の専門担当へ探索を依頼し、候補を利用者へ示した後、面接日程の調整へ進む構成だ。これは紹介された利用場面であり、採用業務の時間短縮を測定した結果ではない。意味があるのは、候補の一覧と日程調整の依頼が、別の担当の仕事として区別されている点である。

同じ区別を休暇申請へ持ち込むと、残日数の照会が終わっても申請は完了していないと分かる。接続先が返す「完了」が何の完了かを、利用側の画面に結び付ける必要がある。タスクの進捗を運ぶ形式があっても、申請案と承認済みの記録の意味をそろえる作業は残る。

発表は仕様を草案として公開し、本番向けの版を年内に提供する予定を示す。参加企業の広がりは接続を共通化する意欲を示すが、すべての製品間で依頼を確実に引き継げる証拠にはならない。採用時には、使う実装と接続先の対応を確認する必要がある。

道具と担当の違い

MCPによるデータ接続とA2Aによる依頼は組み合わせられる

ここで、道具へ接続する仕組みと、別の担当に仕事を依頼する仕組みを分けたい。 AnthropicのModel Context Protocol（MCP）の発表は、データや業務の道具をサーバーから公開し、AIアプリケーションが接続する構成を説明している。 A2Aの発表はMCPを補完するものと位置付け、相手が同じ道具や記憶を共有していなくても、担当同士が協調する設計を示す。

休暇申請の想定例では、残日数を読み出す機能を道具として呼ぶ構成と、人事側の担当に申請の作成を依頼する構成を選べる。後者の担当が内部でMCPの道具を使うことも考えられる。接続方式の名称だけでは、どちらが日数を検証し、どちらが記録を保存するかは決まらない。

依頼側は、相手に必要な情報だけを渡し、返された結果を自分の業務の条件と照合する。データの閲覧範囲や、別組織へ渡せる内容も定める。これはプロトコルの存在を否定する話ではない。接続形式を共通にすることで省ける実装と、業務の意味を合わせるために必要な実装を分ける話である。

開発と配備

オープンな枠組みを使っても、実行先は一つに決まらない

GoogleのVertex AIの発表は、この分け方を製品構成で示す。 Agent Development Kit（ADK）は、エージェントを開発するためのオープンソースの枠組みだ。 Pythonで提供され、ローカルでの確認やCloud Run、Kubernetes、Vertex AIなどの実行先を選ぶ構成を説明している。 Agent Engineは、配備と実行基盤の管理を引き受けるサービスとして示される。

この組み合わせなら、動作を定義するコードと、動かす環境の管理を分けて考えられる。ただし、移せるコードがあることと、接続先の認証、保存済みの会話、監視設定まで同じまま移せることは違う。 Googleは開発から配備への負担を減らすと説明するが、発表だけで自社の移行工数が分かるわけではない。実行先を替える比較では、依頼と結果が保たれる範囲を確かめたい。

Semantic Kernel Agentsの4月4日の発表も、枠組みと実行先を分けて読む必要がある。中核のAgent APIを.NET 1.45とPython 1.27で一般提供し、APIの品質への確信と今後の保守を説明している。他の基盤への接続例も載るが、SDKは管理された実行サービスそのものではない。紹介された新しい協調機能や接続先すべての品質を、一般提供という一語から推定しない。

二つの発表は、開発の枠組みと管理サービスを併用する道を示す。比較するなら、APIの安定性、動作を定義する場所、配備後に管理してもらう内容を別々に見る。「オープンか管理型か」という二択より、変更したい部分をどこまで独立させられるかが重要になる。

人が途中で変更する

確認してから実行する仕組みでも、検証をやり直す場所は必要になる

AWSの人による確認の実装例は、休暇申請を使ってこの問題を具体化している。残日数の取得や過去の申請の一覧は、その例では自動で進める。作成、更新、取り消しはデータベースを変更するため、実行前に利用者へ確認を求める。確認する画面には、呼ぶ機能と引数を示す。

単純な利用者確認は、示された操作を承認するか拒否するかを扱う。これに対し、制御返却はアプリケーションへ操作の情報を戻し、アプリケーションが実行を引き受ける。 AWSの例では、利用者が開始日を日曜日にしてしまったと気付き、フォームで日付を直せる。意図の確認を、誤りの修正まで広げられる点に違いがある。

修正できるからこそ、前の検証をそのまま信用できない。同じ資料は、残日数が5日ある利用者の3日間の申請を、利用者が100日間へ変更する場合を説明する。最終的な検証と制限の適用はAPI側で行う。エージェントが最初の入力を検証済みでも、編集後の内容が妥当とは限らない。

制御返却には、編集画面と実行処理をアプリケーションで作る負担がある。毎回、細かい編集が必要とは限らず、内容が明確なら承認か拒否だけで足りる場合もある。人を途中に置く設計は、停止する場所に加えて、その後の入力を誰が再検証するかで選ぶ必要がある。

複数システムの想定例

利用者の確認、上長の承認、保存結果を別々に引き継ぐ

AWSの例を出発点に、上長承認が別のシステムにある場合を考える。ここからは本稿の設計上の想定であり、発表された実装実績ではない。社内アシスタントが残日数を読み、人事側の担当へ申請案を依頼する。利用者が日付を直したら、最終内容を検証して申請を保存し、上長の承認待ちと表示する。

利用者が確認したことは、上長が承認したことを意味しない。上長の応答が遅い場合も、依頼自体の失敗とは限らない。申請の識別子、現在の処理段階、次に必要な判断を保てば、利用者は申請を重ねて送らずに待てる。後から承認されたときに保存結果を照合し、初めて承認済みとして知らせる。

この設計では、接続の障害、利用者の拒否、承認待ち、保存の失敗を分ける。待っているだけの仕事を再実行すると、別システムに重複した申請を作るかもしれない。相手の進捗を運べるA2Aと、実行前に入力を直せる確認の仕組みは、この区別を表現するための部品になる。重複を防ぐ処理や業務規則は、利用側で実装して確かめる必要がある。

組み合わせる条件

必要な担当が別の場所にいるとき、接続の共通化が生きる

すべての仕事に複数のエージェントが必要なわけではない。一つのアプリケーションから固定した人事APIを呼ぶだけなら、直接接続するほうが確認箇所を減らせる場合がある。 AnthropicのBuilding effective agentsも、問題に合う単純な構成から始め、必要に応じて複雑さを増やすよう勧めている。

接続を共通にする意味が増すのは、担当が別の基盤に存在し、応答が長く続き、成果物や人の入力を途中で受け渡す場合だ。その場合も、依頼の受付から保存結果まで、一件の仕事を通して検証したい。通常の依頼だけでなく、利用者の編集、相手の応答待ち、途中の接続切断を加え、どこから再開できるかを確認する。