AIエージェント同士を連携させる｜A2A Protocolで他エージェントの自動発見を検証【AI活用検証vol.31】

AIエージェントを1つ作って動かすところまでは、多くの企業が到達しています。次の段階は、役割の違う複数のエージェントが互いに連携して、人が介在せずにタスクを完遂するという形です。

この「A2A（Agent to Agent）」の実現可能性を、MastraとA2A Protocolで検証しました。結果として、エージェントが他のエージェントを自動で発見し、依頼して、成果物を受け取るという一連の流れの動作を確認できています。

この検証の概要

本記事は自社での検証記録です。実業務への適用は行っていないため、効果の数値はありません。

結論：エージェントが他のエージェントを見つけて呼べる

この検証で確認できた最も重要な挙動がこれです。

エージェントが、利用可能な他のエージェントを自動で発見（discovered_agents）し、メッセージを送信して成果物を受け取るという一連のフローが動きました。

ポイントは「どのエージェントに頼むか」を人間が指定していない点です。使える相手を自分で見つけて、依頼する。これが成立すると、専門特化した小さなエージェントを並べておくだけで、必要な組み合わせが自動的に作られる可能性が出てきます。

今回は俳句を生成する専門エージェントを、クライアント側から呼び出す構成で確認しました。

HTTPS通信で繋がることの意味

技術的に見逃せない発見がこれです。

ローカル環境であっても、HTTPS通信を介したエージェント同士の疎通が確立できれば、将来的に異なるプラットフォームやサーバー間でのAI連携が可能になります。

同じアプリケーションの中で完結する連携ではなく、ネットワーク越しに別々のシステムのエージェントが会話するという構図です。自社のエージェントと取引先のエージェントが直接やりとりする、といった将来像に繋がります。

課題：コンテキスト共有の深度

一方で、明確な課題も見えました。エージェント間のコンテキスト共有の深度です。

今回の検証は単発の呼び出しでした。「このテーマで俳句を作って」と依頼し、結果を受け取る。この範囲であれば問題ありません。

しかし複雑なタスクになると、やりとりの途中経過や前提を、エージェント間でどこまで共有するかという設計が必要になります。何度も往復するタスクでは、状態（State）を保持するための設計が要るというのが今回の想定です。

人間のチームでも、都度ゼロから説明していては仕事になりません。エージェント間の連携でも、同じ問題が形を変えて現れます。

現時点での位置づけ

A2Aはまだ実業務に投入する段階ではありませんが、基本動作が確認できたことには意味があります。

• 専門特化した小さなエージェントを並べる設計が現実味を帯びる
• プラットフォームを跨いだAI連携の土台になる
• ただし複雑なタスクには状態管理の設計が必要

よくある質問

A2Aとは何ですか？

Agent to Agent の略で、AIエージェント同士が直接連携してタスクを完遂する仕組みです。人間が「次はこのAIに聞いて」と指示するのではなく、エージェントが自分で必要な相手を見つけて依頼します。

実業務で使えますか？

現時点では基本動作の確認段階です。単発の呼び出しは問題なく動きましたが、複雑なタスクではエージェント間の状態保持の設計が必要になると想定しています。

MCPとは何が違いますか？

MCPはAIと外部ツールを繋ぐ規格ですが、A2Aはエージェント同士を繋ぐものです。前者は「AIが道具を使う」、後者は「AIがAIに頼む」という構図の違いがあります。

何が課題として残りましたか？

エージェント間のコンテキスト共有の深度です。今回は単発の呼び出しでしたが、複雑なタスクでは状態（State）を保持する設計が必要になります。

まとめ

• エージェントが他エージェントを自動発見（discovered_agents）し、依頼して成果物を受け取るフローを確認
• 「どのエージェントに頼むか」を人間が指定しない点が、従来の連携との大きな違い
• HTTPS通信で疎通できれば、プラットフォームやサーバーを跨いだAI連携に繋がる
• 課題はコンテキスト共有の深度。複雑なタスクには状態保持の設計が必要

AIエージェントの次の段階は、1体を賢くすることではなく、複数体をどう連携させるかに移りつつあります。その入口を確認した検証でした。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。