---
title: "AIエージェント同士を連携させる｜A2A Protocolで他エージェントの自動発見を検証"
excerpt: "複数のAIエージェントがHTTPS通信で連携しタスクを完遂する「A2A（Agent to Agent）」を、MastraとA2A Protocolで検証しました。エージェントが利用可能な他エージェントを自動発見し、依頼して成果物を受け取るフローの動作を確認。一方でコンテキスト共有の深度という課題も見えた記録です。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2025-10-11T00:00:00+00:00
verified_at: 2025-10-11T00:00:00+00:00
tools: ["GitHub"]
tasks: ["AIエージェント", "ツール検証"]
canonical_url: https://ai-katsu.jp/articles/a2a-agent-communication
---
# AIエージェント同士を連携させる｜A2A Protocolで他エージェントの自動発見を検証

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

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

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2025年10月（10/11〜10/17） |
| 使用ツール | Mastra（A2A Protocol）/ Python / GitHub Codespace |
| やりたかったこと | 複数のAIエージェントがHTTPS通信で対話・連携し、人が介在せずタスクを完遂する仕組みの検証 |
| 確認できたこと | **他エージェントの自動発見（discovered\_agents）→ メッセージ送信 → 成果物の受け取り**という一連のフロー |
| 検証内容 | クライアント側から俳句エージェントを呼び出し、特定テーマ（ゲーム「Strands」）に沿った出力を得る |
| 課題 | エージェント間のコンテキスト共有の深度 |
| 判定 | 完了（基本動作確認済み） |

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

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

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

**エージェントが、利用可能な他のエージェントを自動で発見（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導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。