Agent2Agent プロトコルを試して見えてきたGoogleの戦略
概要
この記事では、Googleが先日発表したAgent2Agent プロトコル (A2A) について、基礎知識を解説した後、公式のデモコードを動かす方法を記載します。
さらに、Agent2Agent プロトコルを見て、私がGoogleの戦略について感じたことについて述べます。
Agent2Agent プロトコル
基礎知識
Agent2Agent プロトコルは以下の要素から成り立っています。
-
AI Agentができることを表す共通規格であるAgent Card
-
AI Agent間の同期/非同期通信のルール
個人的なキモはAgent Cardで、公式ドキュメントから引用すると以下のようなjsonをhttps://${base_url}/.well-known/agent.jsonで公開することになっています。エージェントのURL、できること、認証方法などがまとまっています。
// An AgentCard conveys key information:
// - Overall details (version, name, description, uses)
// - Skills: A set of capabilities the agent can perform
// - Default modalities/content types supported by the agent.
// - Authentication requirements
interface AgentCard {
// Human readable name of the agent.
// (e.g. "Recipe Agent")
name: string;
// A human-readable description of the agent. Used to assist users and
// other agents in understanding what the agent can do.
// (e.g. "Agent that helps users with recipes and cooking.")
description: string;
// A URL to the address the agent is hosted at.
url: string;
// The service provider of the agent
provider?: {
organization: string;
url: string;
};
// The version of the agent - format is up to the provider. (e.g. "1.0.0")
version: string;
// A URL to documentation for the agent.
documentationUrl?: string;
// Optional capabilities supported by the agent.
capabilities: {
streaming?: boolean; // true if the agent supports SSE
pushNotifications?: boolean; // true if the agent can notify updates to client
stateTransitionHistory?: boolean; //true if the agent exposes status change history for tasks
};
// Authentication requirements for the agent.
// Intended to match OpenAPI authentication structure.
authentication: {
schemes: string[]; // e.g. Basic, Bearer
credentials?: string; //credentials a client should use for private cards
};
// The set of interaction modes that the agent
// supports across all skills. This can be overridden per-skill.
defaultInputModes: string[]; // supported mime types for input
defaultOutputModes: string[]; // supported mime types for output
// Skills are a unit of capability that an agent can perform.
skills: {
id: string; // unique identifier for the agent's skill
name: string; //human readable name of the skill
// description of the skill - will be used by the client or a human
// as a hint to understand what the skill does.
description: string;
// Set of tagwords describing classes of capabilities for this specific
// skill (e.g. "cooking", "customer support", "billing")
tags: string[];
// The set of example scenarios that the skill can perform.
// Will be used by the client as a hint to understand how the skill can be
// used. (e.g. "I need a recipe for bread")
examples?: string[]; // example prompts for tasks
// The set of interaction modes that the skill supports
// (if different than the default)
inputModes?: string[]; // supported mime types for input
outputModes?: string[]; // supported mime types for output
}[];
}
MCPとA2Aの違い
MCPはAI <--> Toolの通信を、A2AはAI <--> AIの通信を司るプロトコルで相互補完的であるとのことです。
また、以下のようにA2Aで用いるAgentCardをMCPリソースとして公開することが推奨されています。
MCPとA2Aの関係 出典: https://google.github.io/A2A/#/topics/a2a_and_mcp?id=intersection
これはつまり、以下のようなフローで利用する想定であるということです。
-
ユーザーは自身のAIエージェント (Agent A) に対して、MCPリソースとして他のAIエージェント (Agent B, C, …, Z) を登録するタスクをお願いする
-
ユーザーはAgent Aにタスクをお願いする
-
Agent AはMCPリソースに登録されたAgent B, C, …, ZのAgent Cardの情報から適切なAIエージェントにタスクを移譲する
-
移譲されたAIエージェントが再帰的に移譲することでタスクをこなす
デモコード実行
ここまでわかったところで公式のデモコードを動かしてみましょう。
実行手順
まずはコードをcloneします。
git clone https://github.com/google/A2A.git
cd A2A
次に必要になるuvというツールを導入します。
pip install uv
あとは公式のdemo/ui/README.mdに従って実行するだけです。
まずはこちらからGeminiのAPIキーを取得します。
先にAgentを立ち上げましょう。
cd samples/python
echo "GOOGLE_API_KEY=[ここに取得したキーを入れる]" > agents/langgraph/.env
uv run agents/langgraph
にアクセスすると実際にAgent Cardを確認することができます。テキストで為替レートを返すエージェントのようですね。
{
"name": "Currency Agent",
"description": "Helps with exchange rates for currencies",
"url": "http://localhost:10000/",
"version": "1.0.0",
"capabilities": {
"streaming": true,
"pushNotifications": true,
"stateTransitionHistory": false
},
"defaultInputModes": [
"text",
"text/plain"
],
"defaultOutputModes": [
"text",
"text/plain"
],
"skills": [
{
"id": "convert_currency",
"name": "Currency Exchange Rates Tool",
"description": "Helps with exchange values between various currencies",
"tags": [
"currency conversion",
"currency exchange"
],
"examples": [
"What is exchange rate between USD and GBP?"
]
}
]
}
その後UIを立ち上げます。別窓で以下を実行します。
cd ../../demo/ui
echo "GOOGLE_API_KEY=[ここに取得したキーを入れる]" > .env
uv run main.py
にアクセスするとUIを確認できます。左のメニューのAgentsから先程の為替レートエージェントのアドレスを登録しましょう。
今日のドル円を聞いてみましょう。
どうやら上手く取得してくれたようです。
Googleが考えていそうなこと
ここまででAgent2Agent プロトコルの概要とデモを見てみました。
Googleはなんだかんだ言って情報検索の企業です。世界中の情報を整理して提供することをミッションとしています。
今回のAgent2Agent プロトコルを見て、私はGoogleがAIエージェントの検索エンジンになろうとしているのだと思いました。
検索サービスとはWebページをぺっと一覧にして出すだけではありません。ユーザーが入力した検索クエリから本当は何がしたいのかを想像し、適切な情報を提示し、アクションを起こしてもらう事が重要です。例えば購買、ホテルや飲食店の予約、追加のリサーチなどです。Googleはそこまでを既に実現しています。必要な部分はWebの検索結果として他のサービスに移譲しながら。
それをAIエージェントに対しても広げようとしているのではないでしょうか。キモはAgent Cardだと冒頭に言いましたが、これがhtmlで言うheaderタグのようになり、Googleがそれを見て適切なAIエージェントへと仲介する、そのような世界を想像しました。自身のAIエージェントに客を呼び込んでもらうべく、SEOならぬAI Agent OptimizationとしてAgent Cardをリッチにする取り組みが流行るかもしれません。
また、仲介先のAgentがAIとは限りません。A2Aは非同期でのタスクが考慮されているので、AIに言われて人間がリサーチするランサーズとタイミーの間の子みたいなサービスも生まれるかもしれません。なんだか怖い世界になってきました。
終わりに
Agent2Agent プロトコルは認証認可が想定されていたり、レジストリの追加なども検討されているようで、上記の想像に留まらない幅広い活躍が見込まれます。
もし一気に標準化が進むことがあれば、AIエージェントが混沌としたネットで協業し続けるといういかにもSFな展開になってきそうです。
今後も注視しつつ、食いっぱぐれないように立ち回りに気をつけようと思います。
Discussion