はじめに

この連載では、一つのAIエージェントをどう設計するかという視点で、Harness、Loop Engineering、Memoryといった要素を扱ってきました。ここまでは基本的に、一つのエージェントの内側の話でした。

今回は少し視点を変えて、複数のAIエージェントが、異なる企業や異なるフレームワークをまたいで、どうやって互いに会話し、仕事を頼み合うのかというテーマを取り上げます。その中心にあるのが、Agent2Agent Protocol、通称A2Aです。ちょうど2026年8月、A2Aの運営体制が大きく動いたタイミングでもあるので、このあたりの経緯も含めて整理してみます。

1. A2Aとは何か

A2Aは、異なるベンダーやフレームワークで作られたAIエージェント同士が、互いを発見し、安全に情報をやり取りし、仕事を委任し合うための、オープンな通信規格です。Googleによって開発され、2025年4月に発表されました。

A2Aの大きな特徴は、エージェントが互いの内部実装を公開しなくても連携できる点にあります。あるエージェントが、別のエージェントの内部メモリやツール、独自のロジックを知らなくても、A2Aという共通の言語を通じてタスクを依頼し、結果を受け取ることができます。異なるフレームワーク上に構築されたエージェント同士でも相互運用できる、という設計思想です。

2. なぜA2Aが必要とされたのか

これまでの連載で扱ってきたAgentic Workflowの設計パターンでは、Multi-Agentという構成に触れました。複数の専門化されたエージェントが協調して動く、という考え方です。

しかし実際には、異なる企業が、異なるフレームワークで、それぞれ独自にAIエージェントを開発しています。あるエージェントを別のエージェントと連携させたいとき、両者の間に個別のカスタム連携を作り込む必要があるとしたら、その組み合わせの数だけ開発コストがかかってしまいます。

A2Aは、この問題に対する解決策として位置づけられています。共通のプロトコルを使うことで、開発者は特定のベンダーにロックインされることなく、複数のソースやプラットフォームのエージェントを組み合わせられるようになります。

3. MCPとの違い

AIエージェントの文脈でよく一緒に語られるのが、Anthropicが開発したMCP、Model Context Protocolです。この2つは役割が異なります。

MCPは、一つのエージェントが、自分の使うツールやデータソースにどう接続するかを標準化するプロトコルです。以前の記事で扱ったTool Engineeringの領域に近い話です。

A2Aは、エージェントとエージェントが、互いにどう通信するかを標準化するプロトコルです。あるエージェントが別のエージェントを発見し、タスクを委任し、結果を受け取る、というやり取りを扱います。

つまりMCPは「エージェントとツールをつなぐ」規格であり、A2Aは「エージェントとエージェントをつなぐ」規格です。この2つは競合するものではなく、補完し合う関係にあるとGoogleは説明しています。大規模なマルチエージェントシステムを構築するために、両方のインフラが必要になる、という位置づけです。

4. 「自分のエージェント同士」だけでなく「他人のエージェント」ともつながる規格

ここで一つ、誤解しやすいポイントを補足しておきます。A2Aは、自分のパソコンやプロジェクトの中で動く複数のエージェント同士をつなぐためだけの規格ではありません。異なる会社、異なる開発者、異なる組織が、それぞれ独自に運用しているエージェント同士をつなぐことを、最初から前提として設計されています。

例えば、自分が作ったエージェントが、取引先の会社が運用しているエージェントにタスクを依頼する。あるいは、あるサービスのエージェントが、まったく別のベンダーが提供しているエージェントの能力を借りて、複数のサービスをまたいだ処理を組み立てる。こうした、組織の境界を越えたやり取りこそが、A2Aが解決しようとしている本来の課題です。

これができる背景には、A2Aがエージェントの内部実装を公開せずに連携できる設計になっている、という点があります。相手のエージェントがどんなモデルを使い、どんな内部ロジックで動いているかを知らなくても、A2Aという共通の言語さえ話せれば、タスクを依頼し、結果を受け取ることができます。だからこそ、社内で完結する話ではなく、インターネットを介して他社や他者のエージェントとつながる、という使い方が成立します。

もちろん、見ず知らずのエージェントに何でも任せられるわけではありません。以前触れたA2A 1.0で追加された、署名付きのエージェントカードのような身元確認の仕組みは、まさに「相手が本当に信頼できるエージェントなのか」を確認するために存在しています。他人が運用するエージェントとつながる以上、なりすましや不正な相手をどう見分けるかという課題は、この規格にとって避けて通れない部分です。

つまりA2Aは、社内向けの便利な連携ツールというより、インターネット上でエージェント同士が国境や企業の壁を越えて協調する、いわば「エージェントのためのインターネット」を作ろうとする試みに近いと捉えると、規模感がつかみやすいかもしれません。

5. A2Aの運営体制の変化

A2Aは発表当初、Googleが単独で開発を主導していました。2025年6月には、Amazon Web Services、Cisco、Google、Microsoft、Salesforce、SAP、ServiceNowといった企業とともに、Linux Foundationのもとで独立したプロジェクトとして運営される体制に移行しました。特定のベンダーに依存しない、中立的なガバナンスのもとで発展させる狙いがあったとされています。

そして2026年8月、A2Aはさらに、Linux Foundationの中でもエージェント型AIに特化したAgentic AI Foundationという組織へ移管されることが明らかになりました。この移管により、A2Aは同じ枠組みの中で、MCPや、Blockのgoose、OpenAIのAGENTS.mdといった関連プロジェクトと並ぶ形になります。

この一連の流れは、A2Aが一企業のプロジェクトから、業界全体で育てていくインフラへと位置づけを変えてきた過程だと見ることができます。

6. A2A 1.0で強化された点

Agentic AI Foundationへの移管にあわせて、A2Aの仕様バージョン1.0では、マルチテナンシー、プロトコルのネゴシエーション、署名付きのエージェントカードといった機能が追加されました。これらは、企業がA2Aを実運用の環境に導入する際の、身元確認や利用範囲の管理を強化するための仕組みです。

以前の記事で扱ったRecovery EngineeringやHuman-in-the-loopの考え方を、複数エージェント間の連携という文脈に広げると、こうした身元確認や権限管理の仕組みの重要性が見えてきます。一つのエージェントの中での安全設計だけでなく、エージェント同士がやり取りする際の信頼性をどう担保するかも、これから重要になっていく領域です。

7. A2Aが機能する仕組み

A2Aを使うと、あるクライアント側のエージェントが、リモートのエージェントを発見し、サブタスクを委任し、情報を交換し、行動を調整できます。それぞれのエージェントは、自分の内部メモリやツール、独自のロジックを外部に公開しません。

これは、以前の記事で扱ったTool Engineeringの考え方と似た側面があります。良いツールは、内部の複雑さを隠しながら、明確なインターフェースだけを外部に見せる、という話をしました。A2Aは、この発想をエージェント同士の関係にまで拡張したものだと捉えることができます。

対応するSDKは、Python、JavaScript、Java、C#、Goと複数の言語で提供されており、LangGraph、CrewAI、Semantic Kernelといった、異なるフレームワーク上に構築されたエージェントの相互運用が想定されています。

8. この連載の文脈でA2Aをどう位置づけるか

これまでこの連載で扱ってきたHarness、Loop Engineering、Memory、Observabilityといった要素は、基本的に一つのエージェントの内側を設計する話でした。

A2Aは、その一つ外側のレイヤーにあたります。複数のエージェントが協調するAgentic Workflowを実際に構築しようとしたとき、それぞれのエージェントがどのフレームワークで作られていても連携できる、という前提を提供してくれるのがA2Aだと言えます。

以前の記事で扱ったMulti-Agentという設計パターンを、実際に複数のベンダーやチームをまたいで実現しようとするなら、こうした標準規格の存在が土台になってきます。

9. 組織の壁を越えたエージェント連携は、どんな社会を生むのか

ここから先は、確定した事実というより、私の見立てを含む話になります。A2Aのように、自社の中だけでなく他社のエージェントとも当たり前に連携できる世界が本当に広がっていったとき、どんな変化が起きるのかを考えてみます。

まず一つ目は、プロジェクトの進め方そのものが軽くなるだろう、という点です。これまでは、別の会社のシステムと連携しようとすると、API仕様のすり合わせや個別の連携開発が必要で、それだけで数週間から数ヶ月かかることも珍しくありませんでした。A2Aのような共通規格が普及すれば、エージェント同士が発見し合い、タスクを委任し合う部分は標準化されるため、この摩擦がかなり減っていくと予想されます。プロジェクトのボトルネックが「連携の実装」から「何を任せるかの設計」に移っていく、というイメージです。

問題は、二つ目の「お金の稼ぎ方はどう変わるのか」という点です。ここは正直、いくつかの方向性が考えられ、どれか一つに断定するのは難しいと感じています。

一つの見立ては、稼ぎ方の単位が細かくなっていく、というものです。これまでソフトウェアは、月額のサブスクリプションや、まとまった単位のライセンス販売で収益化されることが多くありました。A2Aの世界では、あるエージェントが別のエージェントに、タスク単位で処理を依頼し、その都度対価を払う、という取引が技術的にはやりやすくなります。実際、A2Aには決済のやり取りを想定した拡張仕様も用意されており、エージェント同士が自動的に対価をやり取りする、という将来像が見込まれています。これが実際に普及すれば、「使われた分だけ、自動的に細かく課金される」という経済圏が生まれる可能性があります。

もう一つの見立ては、専門特化したエージェントを持つことの価値が上がる、というものです。何でもできる巨大なプラットフォームより、特定のタスクを非常に精度高くこなせる小さなエージェントの方が、他のエージェントから頻繁に指名され、結果として稼ぎやすくなる、という構造です。これは、以前の記事で扱ったTool Engineeringの発想、目的が明確で扱いやすいツールほど選ばれやすい、という話と地続きです。エージェント単位でも、同じ力学が働いていくのではないかと考えています。

一方で、楽観視ばかりもできません。タスクが標準化され、細かく取引されるようになるということは、価格競争が起きやすくなるということでもあります。誰でも似たようなエージェントを立てられる領域では、価格が急速に下がっていくリスクがあります。そこで重要になってくるのが、以前触れた署名付きエージェントカードのような信頼性の証明です。同じ機能でも、実績があり、信頼できると確認されているエージェントの方が選ばれやすくなる、という「信頼の経済」が、これから重要な差別化要因になっていくかもしれません。

もう一つ付け加えておきたいのは、こうした変化が起きるとしても、それは自動的に良い方向にだけ進むわけではない、という点です。以前の記事で扱ったHuman-in-the-loopの考え方がここでも重要になります。エージェント同士が自律的に契約し、対価をやり取りするようになるほど、どこまでを自動化し、どこから人間の承認を必要とするかという線引きが、ビジネス上のリスク管理として欠かせなくなっていくはずです。

以上はあくまで現時点での見立てであり、実際にどうなるかは、規格の普及度合いや、各企業の採用スピードに大きく左右されます。ただ、プロジェクトの摩擦が減る方向へ進むこと自体は、かなり確度が高いのではないかと感じています。

10. 導入を検討する上で意識したいこと

A2Aはまだ発展途上の規格であり、業界全体でどこまで定着していくかは、これから見えてくる部分も大きいと感じています。とはいえ、以下の点は意識しておく価値があります。

まず、A2AとMCPは役割が異なるため、両方を組み合わせて使うことを前提に設計を考えることです。エージェント内部のツール接続はMCP、エージェント間の連携はA2A、という役割分担です。

次に、エージェント同士が内部実装を公開しない設計であるため、連携先のエージェントが本当に信頼できるかどうかを判断する仕組みが必要になることです。A2A 1.0で追加された署名付きのエージェントカードのような機能は、この信頼性の確保に関わってきます。

そして、標準規格である以上、まだ仕様が変化していく可能性がある点も踏まえておく必要があります。中立的なガバナンスのもとで運営されているとはいえ、実運用に組み込む際は、バージョンの動向を継続的に追っておくのが安全です。

11. まとめ

A2Aは、異なるベンダーやフレームワークで作られたAIエージェント同士が、互いを発見し、安全に連携するための、オープンな通信規格です。Googleが開発し、Linux Foundationのもとで中立的な運営に移行した後、2026年8月にはAgentic AI Foundationへの移管という新しい局面を迎えました。

MCPがエージェントとツールをつなぐ規格であるのに対し、A2Aはエージェントとエージェントをつなぐ規格です。この2つが揃うことで、この連載で扱ってきたAgentic Workflowの設計パターン、特にMulti-Agentという構成を、企業やベンダーの垣根を越えて実現していく基盤が整いつつあります。

一つのエージェントをどう賢く働かせるかという視点から、複数のエージェントがどうつながり合うかという視点へ。この連載も、少しずつその外側のレイヤーへ視野を広げていく段階に来ていると感じています。

関連記事

AIエージェントで本当に重要なのはLLMではない？Harness EngineeringとLoop Engineeringから考える次世代AI開発
AIエージェントのTool Engineering入門
Agentic Workflowの設計パターン
自己改善型コーディングエージェントとは何か？Claude Codeの「自動モード」から考える

Tags

AI A2A AIエージェント MCP AgenticAI