この記事のポイント
- マルチエージェントシステムの開発してみたよ
- MCPとA2Aプロトコルの立ち位置を確認したよ
- 複数のエバリエーション（評価）を実行できるマルチエージェントシステムを作ってみたよ
はじめに
この記事ではこれまでの登壇内容を振り返る内容となっています。具体的には今年の1月から3月までの内容を振り返る内容です。※資料の補足で過去の資料を引用することもあります。
振り返る資料は以下のとおりです。
A2Aを使ってエージェントシステムを作ってみよう
まずはAgent2Agent プロトコル（A2A）について簡単に振り返りたいと思います。
A2Aは2025年4月にGoogle Cloud Nextで発表されたエージェント向けプロトコルです。
最大の特徴はエージェント同士がシームレスに繋がるプロトコルであり、マルチエージェントシステム導入に必要なプロトコルです。MCPとは思想が異なるプロトコルです。
どうしてA2Aを使うのか
AIエージェントを強化するだけならMCP利用すれば良いことになりますので、A2Aを使う理由が見つからないと思います。しかし、これは考え方の違いです。
結論から説明するとMCPは「ツール中心的な考え方」であり、A2Aは「対話・組織中心的な考え方」であることです。具体的には以下のとおりです。
MCPとA2Aそれぞれのポジション
各プロトコルのポジションを簡単に整理すると以下のとおりです。
- MCPはAIエージェントに道具を与える（ツール中心的な考え方）
- A2AはAIエージェントにワークフローを与える（対話・組織中心的な考え方）
分かりにくいと思うので図解しつつ、プロトコルにおける課題も見ていきます。
MCPはAIエージェントに道具を与える（ツール中心的な考え方）
まずはMCPです。MCPはエージェントを賢くするための通信プロトコルとして表現できます。
要するに、道具を与えるということになるのでMCP的発想では「購入のAPIを叩くツールをエージェントに渡す」といった発想になります。
ツールが足りないならMCPで追加するとも言えます。しかし、この構造には課題があります。
この構造の課題というのはつまり、ツールをたくさん持つことでAIエージェントの性能評価・試験は難しくなるということです。AIエージェントがいくつのツールを持っているのかを観測できないとも言えます。
余談ですが、AIエージェントの評価にはさまざまな項目があります。詳細は以下のスライドで解説していますので参照していただければと思います。
A2AはAIエージェントにワークフローを与える（対話・組織中心的な考え方）
つぎにA2Aプロトコルは、エージェントを「ただのプログラム」ではなく、「自律的な意志を持つ主体」として扱います。
つまり、A2A的発想ではエージェントの役割を定義して、エージェント同士の相互の対話を実現することを想定しています。
基本としては司令塔となるAIエージェントは道具を持たず、他のエージェントが役割を担い、AIエージェント同士が対話するワークフローシステムとなるところがポイントです。
しかし、この構造を実現するためのインフラを考えようと思うといくつかの課題があるかなと考えています。
なにが課題なのか結論から説明するとエージェントがエージェントを呼ぶという構成をアプリケーションとして提供する場合
テストのカバレッジを担保するのが難しいということです。これはマイクロサービスをテストするかのような難しさがあります。エージェントそれぞれをサービスとして捉えるとこの構成はマイクロサービスになりえます。
A2Aの特徴にフォーカスしてみていこう
A2Aの概念と課題を見てきたところでポイントを絞ってA2Aの特徴を表にまとめると以下のとおりです。
| 項目 | 説明 |
|---|---|
| 機能 | エージェントオーケストレーション (A2A) |
| 最小単位 | Agent (Task / Artifact) |
| 発見 (Discovery) | Agent Card (能力のメタデータ) |
| 通信規約 | JSON-RPC 2.0 over HTTP |
| スケーリング | 専門性の分担 (タスク分解ベース) |
| 宣言的定義 | Agent Card / Task Definition |
A2Aの特徴をまとめるとA2Aの機能を活用するために必要なことが見えてきます。
- マイクロサービスアーキテクチャ
- サービスディスカバリ
- オブザーバビリティ
- RPC
マイクロサービスアーキテクチャやサービスディスカバリを見ていくとKubernetesの特徴をなぞっているようにみえます。また、RPCという部分においては.NETの得意分野でもあります。
※この登壇は.NETラボ勉強会の資料なので.NETを前提に話していますが、他の言語でも構いません。
つまり、A2AはKubernetesと組み合わせると活用が捗るのではないかと考えました。
KubernetesとA2Aの関係性
ここでKubernetesとA2Aの関係性について見ていきましょう。
| 機能 | Kubernetes | A2A |
|---|---|---|
| 最小単位 | Pod / Container | Agent (Task / Artifact) |
| 発見 | Service / DNS | Agent Card (能力のメタデータ) |
| 通信規約 | HTTP / gRPC / Service Mesh | JSON-RPC 2.0 over HTTP |
| スケーリング | HPA (負荷ベース)/ VPA | 専門性の分担 (タスク分解ベース) |
| 宣言的 | YAML (Manifest) | Agent Card / Task Definition |
まずはKubernetesですが、Kubernetesを知る人であれば、A2Aの特徴を聞いたときになにかしらピンと来たはずです。
表にもあるとおり、怖いくらいA2Aにフィットしているんです。どちらもマイクロサービスということを考えるとたしかに共通点はあるかなと思います。
※ちょっとこじつけ感あるかもしれませんが
実際にA2AとKubernetesを使ってマルチエージェントシステムを作ってみる
※ここから.NETラボ2月の資料から引用
では、.NET/AzureでA2Aのエージェントシステムを実現するにはどうすれば良いかというところですが、大きく分けて現実的な話、KubernetesかPaaSになると思います。
ただ、実際のところ、Kubernetesで補えないところをPaaSにオフロードするというのが良いのかなというのが最近いろいろやってみての答えになるかなとは思うのでPaaSは使いようだなと思うところです。
PaaSによるマルチエージェントシステムについてはMicrosoftのブログでいくつか説明されていますのでこの記事ではA2AとKubernetesを使った話を中心に紹介します。
A2AとKubernetesによるマルチエージェントシステムの実装
A2AとKubernetesによるマルチエージェントシステムを実装するうえで重要なポイントとしてはA2Aによって接続したAIエージェントをKubernetes上でどのように動かすかというところです。
つまりはAIエージェントを可視化したうえで、マルチエージェントシステムを実現する必要があるということです。
なお、Kubernetes環境でA2A（Agent2Agent）エージェントを自動的に検出する方法についてはzennに書いていますので参考にしていただければと思います。
Kubernetesによるマルチエージェントシステムの設計
zennに示したとおり、いくつかA2A とKubernetesを使ったマルチエージェントシステムを構築してみてわかったことがありますのでどんな感じだったかを共有しようと思います。
もちろん、課題としてはKubernetes 特有のServiceとPodをどう配置するかというところやエージェントが使うのはA2AなのかMCPなのかというエージェントシステムの課題についてです。
具体的には以下のとおりです。
- ServiceとPodをどう配置するか
- エージェントが使うのはA2AかMCPのどちらなのか
- 他、生成AIを導入時に気をつけるべき点も交えて解説
- 内容を踏まえるとこういうのできる
今回の知見を踏まえてどんなことができるのかを話したいと思います。
ServiceとPodをどう配置するか
まずはマルチエージェントシステムが動作するKubernetesではServiceとPodをどう配置するかという部分について説明していきたいと思いますが、表で簡単に説明するとこんな感じです。
Kubernetesなので名前空間の話もあると思いますが、今回はKubernetesのService、Pod、エージェント という3つの単位で説明します。
1 Pod = 1 エージェント
まず最初に接続先が単一Serviceで複数Pod、1Pod = 1エージェントという形です。
今回はDispatcherを開発してKubernetesのサービスをもとにAIエージェントを探すということを実際にやりました。
Dispatcherはサービスディスカバリや内部DNSをもとにA2AのAgentCardを参照してエージェントを探すというものです。
1 Service = 1 エージェント
次の構成として1Service = 1エージェント、エージェントがそれぞれエンドポイントを持つようになる構成です。Dispatcherは各Kubernetesサービスのエンドポイントからエージェントを知るということが可能になります。
1 Pod = 複数エージェント
最後の構成として同じサービスの中にAIエージェントを閉じ込めた構成です。
この構成の場合、AIエージェントのポート番号を変えないとポート番号の衝突が発生してしまいます。ただし、Pod内でポート番号を変えたうえで起動する場合は各AIエージェントのポート番号をDispatcherに教える必要があり、エージェントディスカバリが難しくなります。
エージェントが使うのはA2AかMCPのどちらなのか
こんな形でいくつか構成を考えました。ここでDispatcherの接続先にいるAIエージェントが使うのは
A2AかMCPのどちらなのかそんな疑問が出ると思います。
結論から説明するとエージェント同士をつなぐならばA2A、エージェントを強化するならMCPということです。しかし、実現するにあたってはいくつか課題があります。具体的には以下のとおりです。
- A2Aの課題をMCPで解決
- A2Aの課題（メモリーやセッションなど）
A2Aの課題をMCPで解決
まずはA2Aの課題をMCPで解決についてです。
A2Aはエージェントを増やすことでエージェントシステムあるいはワークフローを強化するという思想です。AIエージェントを増やさないことにはそのワークフローは貧弱ということになります。
つまり、逆に考えると他にエージェントがいないと何もできないというのがA2Aになります。
そこで各エージェントの得意領域をMCPで定義してエージェントが強化することでワークフローを強化するというのが良いということになります。
くしくもA2AとこのMCPとの組み合わせはGoogle Cloudさんも話していたところなのでぐぬぬと思ったところです。ここはツールでも良いですが、インフラで解決するならMCPが良いと考えています。
メモリーに関するA2Aの課題
AIエージェントの課題でもありますが、メモリーに関する課題があると思います。
A2Aによるマルチエージェントシステムでは実行のたびに別のエージェントが呼ばれてしまい、応答が変わってしまう可能性があります。
たとえば、１回目は皆さんからみて上のSimpleAgentが呼ばれ、2回目では下のSimpleAgentが呼ばれるといった場合です。
こういった場合、先程話した内容を覚えていないということがおきますので会話履歴を保存してあげる必要があります。
※前提：同一エージェントかつ会話履歴が同じであること
セッションに関するA2Aの課題
次にセッションの課題です。
AIエージェントが記憶したあと記憶はしたんだけども
たとえば、1回目はSimpleAgentがレスポンスを返して、次に話しかけたときはEchoAgentが反応するといった、いわゆる本当の本当に別のエージェントが動いてしまったというパターンです。
つまりは別のエージェントが呼ばれる場合はセッション単位でエージェントを固定しないと会話履歴は同じ、喋っている人は違うみたいなそんな状態に陥ります。
※ちなみにGoogleのフレームワーク、Google ADKの実装ではセッションIDとUserIdを保存して接続するということになっています。
A2Aの課題はどう解消すべきか
ここまで話を聞くともうご存知のとおりこういった複雑になりがちな実装はマネージドサービスに落とし込んだほうが良いかもしれません。
たとえば、呼び出し元はKubernetes、呼び出し先をAzure AI系のサービスという
つまりはPaaSにすることでメモリーやセッションがマネージドにするということです。
内容を踏まえるとこういうのできる
A2AとKubernetesの構成ではフレームワークとランタイムに依存しないところが特徴になります。
つまり、特徴にうまく使っていくと以下のようなことができるようになります。
- 複合エバリュエーター、Multi-Agent Evaluation Systemの開発
- Azure AI Evaluation SDKを利用
- GitHub Copilotを活用したマルチコーディングエージェントシステム
- GitHub Copilot CLIとGitHub Copilot SDKの利用
順番に見ていきましょう。
Multi-Agent Evaluation Systemの開発
まずはMulti-Agent Evaluation Systemです。複数の評価を実行するあるいは場合によっては特定の評価者(エバリュエーター)を同じ環境にまとめたうえで利用できるそんな仕組みです。
Kubernetesのサービス単位でユーザーの発言を評価することが可能で評価者はKubernetesサービス単位で増やせます。※この構成は.NETラボ3月で紹介しました。後述します。
GitHub Copilotを活用したマルチコーディングエージェントシステム
GitHub Copilot CLIにはサーバーモードというものがありますので複数のCopilotサーバを起動してGitHub Copilot SDKでアクセスし、それぞれに対して作業を開始するといったことが可能です。
この構成のPoCについては以下のハンズオンで検証済みです。Dockerではありますが、Kubernetesでも試して実行可能であることは検証済みです。
補足：GitHub Copilot CLIのサーバモードをどう認証させるか
DockerやKubernetesを使って認証を試したみたところ、やはり認証をどうするかがネックになりそうなところです。もし認証をするのであれば、GitHub Copilot CLIの認証を環境変数ベースで行うか、gh auth loginを実行するなどの方法があります。KubernetesではKubernetes Secretを使う方法もあると思いますが、いまいちベストな方法を見つけられていません。
MCPとA2Aプロトコルによるマルチエージェントシステムの開発
※ここから.NETラボ3月の資料からの引用になります
3月の.NETラボでは実際にA2AプロトコルとKubernetesを使ってMulti-Agent Evaluation Systemを作ってみましたのでその知見を共有したいと思います。
A2AとMCPでマルチエージェントシステムを作るとどうなるか
A2AとMCPによるマルチエージェントシステムを作るとどうなるか
結論から説明すると接続元がA2Aエージェントである必要やA2A以外の接続口を用意する必要があります。具体的には以下のとおりです。
- A2Aクライアントを作成する
- Agent Client Protocolを活用する
しかし、マルチエージェントシステムは作り方を間違えるとも分散モノリスになってしまう可能性があります。なぜなのか見ていきましょう。
そもそもの話：マルチエージェントシステムとは
そもそもの話、マルチエージェントシステムとはエージェント同士が相互に通信するサービスメッシュとなります。エージェント同士がつながるのでエージェントメッシュと言えます。
こういったマルチエージェントシステムは作り方を間違えると分散モノリス的なシステムになるよということです。さらに具体的に見ていく前に分散モノリスについて見ていきましょう。
用語解説：分散モノリスとは
そもそも分散モノリスって何ですかというところですが、簡単に説明するとサービスの独立性を失ったマイクロサービスのことです。すべてのAPIが密結合になっているシステムでいわゆる全部集まって1つのシステムというものです。
1つデプロイしたら他も全部デプロイしないと整合性が保てないダメなタイプと言えます。これはマルチエージェントシステムでも同じことが言えます。
分散モノリス的なマルチエージェントシステム
では、具体例として分散モノリス的なマルチエージェントシステムについて見ていこうと思います。
分散モノリス的なマルチエージェントシステムはもちろん複数のAIエージェントを接続したマルチエージェントシステムです。この例ではA2Aで接続していることを前提に説明しています。
全体像をみるとエージェント同士が疎結合であるために外部のAIエージェントから接続できるように見えます。しかし、実際はサブエージェントがrootエージェントに最適化されているので外部から接続ができるようになっていないことがあります。あるいは繋がってもうまくいかないということが起こります。
分散モノリス的なマルチエージェントシステムの問題
多様なAIエージェントを作成したとしてもエコシステムが成長しないというところにあると考えています。
- マルチエージェントシステム内のエージェントにアクセスできない
- A2Aの最大のメリットは異なるエージェントがシームレスにつながること
マルチエージェントシステムは専業のエージェントを組み合わせて構成することが前提であるために特定のマルチエージェントシステムに特化してしまうことはアンチパターンとなりえます。
もちろんこれは、設計次第であえて分散モノリスにしているというのであれば、問題はないと考えています。
マルチエージェントシステムの課題となることはなにか
この構造、マルチエージェントシステムの課題はつなぎ方やエージェントの構成になると思います。
エージェントの構成というのはシステムのドメインがどのようなものであるかがあると思いますが
これはドメイン駆動開発の話も絡んでくるので割愛します。
今回は接続方法にフォーカスして話します。具体的にはA2AとMCPとおまけでACPです。プロトコルをどのように利用するかという前提については以下のとおりです。
- A2AはAIエージェントが接続元（エージェント同士の通信、組織の構成）
- MCPはAIエージェントが使う（エージェントの強化、ツールの構成）
という感じです。ACPに関してはMCPやA2Aとの関係性を図解しようと思います。
どんな接続パターンが考えられるか
A2Aを起点にいくつか接続方法が考えられます。
- inbound A2A + A2A
- inbound A2A + MCP
- inbound A2A + A2A and MCP
順番に見ていきましょう。
inbound A2A + A2A
inbound A2A + A2Aです。
A2AプロトコルでAIエージェントに接続します。A2Aで接続するので接続元はA2Aエージェントが前提です。他にエージェントがいることで疎結合的にシステムを強化できます。
もちろんこの構成では他にエージェントがいないとシステムを強化できないという課題があります。
inbound A2A + MCP
つぎにinbound A2A + MCPという構成です。MCPで強化されたAIエージェントをA2Aプロトコルで接続するというものです。AIエージェントはMCPを使ってAPIから情報（DBなど）を取得します。
この構成の場合はシングルエージェントを強化して他のAIエージェントにつなぐということになるのでMCPを増強しない限りは強いシステムにはなりません。
inbound A2A + A2A and MCP
最後にinbound A2A + A2A and MCPというつなぎ方です。
A2AプロトコルでAIエージェントに接続してAIエージェントはA2A/MCPを使って情報を取得するというものです。MCPを利用したうえでレスポンス得るあるいは他のエージェントの能力を借りるといったことが可能です。
この場合はA2A/MCPの両方でエージェントが強化されますが、どういうときにA2Aを利用してどういうときにMCPを使うかということが課題になります。
補足：MCPで他のエージェントに接続する方法はどうか
ここまで来るとMCPを使ってエージェントを接続しないのかと思われるかもしれませんが
そもそもMCPはツールへのアクセスを提供するものなのでエージェントを接続するというのはプロトコルドメインの混在が懸念されるかなと考えられます。
それはMCPのGitHubを見るとわかります。
要するに間違った用途で使っているように見えるかなと思えるところです。ただ、Agent as Toolといったエージェントをツールとした考え方もあるのでなんともいえないところがあります。
余談：ACPも使ってみると？
これは余談ですが、A2Aでもなければ、MCPでもない。でもAIエージェントを接続したいという場合にはAgent Client Protocolが利用できます。
たとえば、入口をA2AとACPの2つで利用できるようにしてA2Aではシステム接続、ACPではユーザー環境の接続ができます。そして、AIエージェントはA2A/MCPを使って情報を取得するといったことをすれば、万能で汎用的なエージェントが構築できます。
補足：そもそもACPとは
エージェントクライアントプロトコル（ACP）は、Zedさんが開発したプロトコルであらゆるエージェントがあらゆる編集環境（エディタや開発環境）とシームレスに統合できるオープンスタンダードプロトコルです。
※ https://agentclientprotocol.com/get-started/introduction
※“Agent Communication Protocol”というのもありますが、それとは別物です。
マルチエージェントエバリュエーションシステムを作ってみた
.NETラボ3月では実際にマルチエージェントシステムの例として
Microsoft Foundry ベースのChatbotをAzure Evaluation SDK とAzure AI Content Safetyで評価するマルチエージェントエバリュエーションシステム を紹介しました。
利用しているクラウドサービスとしては以下のとおりです。
- Microsoft Foundry
- Azure AI Content Safety
- ViolenceとSexualの2つを評価
- Azure Evaluation SDK
言語とフレームワーク
- .NET10
- Microsoft.Extensions.AI
- Blazor
オブザーバビリティ
- Aspire
- 過去は .NET Aspireと呼ばれていたものです
ざっくりした構成としては以下のとおりです。
今回のシナリオとしてはユーザの質問とChatbotの回答をペアにしてEvaluatorAgentが参照、適切なEvaluatorに振り分けるという内容です。具体的には以下のとおりです。
1.ユーザがChatbotに質問を投げる
2.Chatbotが回答を作成してユーザの質問とペアにし、EvaluatorAgentに送信します
3.EvaluatorAgentはChatbotに入力された質問と回答のペアを判定し、適切なEvaluatorに振り分け
4.振り分けられたEvaluatorが内容をAzure Content Safetyを使って評価します
5.評価内容をEvaluatorAgentを通してユーザにレスポンスします
また、当日のデモでは紹介しきませんでしたが、EvaluatorAgent単体で利用することも可能です。前述の分散モノリスを回避をしている構成になります。
このマルチエージェントシステムはAspireとも連携しているのでどのようにしてエージェントが連携しているのかが可視化されています。
※実行結果についてはスライド資料p23参照
他のサービスやツールとの組み合わせを紹介
マルチエージェントエバリュエーションシステムについては以上です。
ここからは別の方法について模索したいと思います。具体的には以下のとおりです。
- KubernetesとHosted Agentによるマルチエージェントシステム
- GitHub Copilot SDKとGitHub Copilot CLIを活用したマルチコーディングエージェントシステム
順番に見ていきましょう。
KubernetesとHosted Agentによるマルチエージェントシステム
まずは2026年3月12日の「AI Agent Builders Meetup #2 AIエージェント構築/運用の知見を、ベンダーフリーで共有しよう！」の登壇資料で紹介したMicrosoft FoundryのHosted Agentを使った構成です。
この構成ではエッジのAIエージェントがMicrosoft FoundryのHosted Agentを使う構成です。Microsoft FoundryのHosted AgentはAgentを作成するとIDが発行されるのでエッジのエージェントに持たせておくことでAgent2Agentが構成できます。
GitHub Copilot SDKとGitHub Copilot CLIを活用したマルチコーディングエージェントシステム
これは.NETラボ2月でも紹介しましたが、プロトコルを使った具体例をまだ出していなかったので説明しようと思います。
この構成を理解するにはまずはAgent Client Protocol(ACP)を理解する必要があります。そもそもCopilot CLIがACPに対応しているところがポイントです。
ですが、A2Aの場合はA2AのSDKとCopilot SDKの組み合わせでA2A接続を実現する必要があります。
※GitHub Copilot CLIとACPを接続するハンズオンもあります。
まとめ
2026年1月から3月までの.NETラボ勉強会の資料を振り返りました。
マルチエージェントシステムをテーマに評価システムを試しに開発してみたところ、違う世界が見えてきたという印象があります。また、いろんな機能をMCPではなくAgentで用意するというそんなシステムはいろんなことが想像できる反面、扱いが難しいという側面があります。
今回の開発をとおしてわかったことの中で「これは良い」と思ったこととしては
Kubernetesの内部DNSを使うことでA2AのAgent Cardを探すというエージェントディスカバリが実現できるということです。
※AWSの場合はAgentCore Runtimeで実現していたと思います
最後に4月の.NETラボではGitHub Copilotをテーマとしたセッションが盛りだくさんですので次回は「マルチエージェントシステムとGitHub Copilot CLI/SDK」について話しますのでご興味のある方はご参加いただけますと幸いです。