Agent2Agentについて

AI関連プロトコル勉強会 No.1
登壇資料
https://428lab.connpass.com/event/374766/
配信アーカイブ
https://www.youtube.com/live/BldGwDzLPVg

Transcript

1. Agent2Agentについて
 kojira 
 四谷ラボ AI関連プロトコル勉強会 No.1
2. 自己紹介
 kojiraです。
 • 居酒屋出身の元組み込みエンジニア
 • Android普及に努めていた
 • 現在はAI関係のフルスタックエンジニア
 • 対話型デジタルクローン作ったり
 • 主にNostrに生息
 • 趣味はプログラミング、カラオケ、歌ってみた投稿
 

3. 目次
 • Agent2Agentの出自
 • Agent2Agentの機能
 

4. Agent2Agentの出自 
 Google が主導しオープン化 
 Google が中心となり、Salesforce、SAP、Workdayなどのエンタープライズ企業パートナーと共に開発 
 2025年4月にGoogle Cloud Nextなどで正式に発表 
 
 生成AIブームにより、「旅行手配エージェント」「経費精算エージェント」など多数のAIエージェントが生まれた が、これらは開発基盤（LangChain, CrewAI, Google Vertex AIなど）が異なると互いに連携できない「サイロ化」 の問題を抱えていた。 
 A2Aはこの壁を壊すために作られた。 
 
 現在は特定の企業の持ち物ではなく、Linux Foundationの下でオープンソースプロジェクトとして運営されてお り、中立的な立場が保たれている。 
 
 Anthropic社が提唱したMCPと対をなす存在。 
 MCP: AI ⇔ ツール/データ（縦の連携） 
 A2A: AIエージェント ⇔ AIエージェント（横の連携） 

6. Agent2Agentの機能 
 エージェント同士が「発見」し、「信 頼」し、「仕事を依頼する」ための仕 組みを提供。
 おおまかに以下の4つの機能がある
 
 1. エージェント・ディスカバリー（発 見機能）
 2. 相互運用性（ベンダーフリー）
 3. タスク委譲とステータス管理
 4. セキュリティと認証

7. エージェント・ディスカバリー 
 A2Aにおいて最も革新的なコア機能。 
 エージェントが、自分の知らないエージェントを 動的に見つけ出し、その使い方を勝手に学習 する仕組み。
 これまでエンジニアが手動で行っていた「APIド キュメントを読んで連携コードを書く」という作業 を、AI自身が自律的に行えるように設計されて いる。
 
 ディスカバリーには以下の3つのステップがあ る。
 • 名刺の公開 (Publishing)
 • 探索と照合 (Searching & Semantic Matching)
 • 動的バインディング (Dynamic Binding) 

8. エージェント・ディスカバリー 名刺の公開 (Publishing) 
 すべてのA2A対応エージェントは、「エージェ ントカード (Agent Card)」と呼ばれる自己紹介 ファイルを、Web上の決まった場所に公開す る。 これはWebサイトにおける robots.txt の ようなもので、誰でもアクセス可能なメタデー タ。
 
 配置場所: https://example.com/.well-known/agent.json
 中身: JSON形式で記述された「プロファイル」
 
 

9. エージェント・ディスカバリー 探索と照合 (Searching & Semantic Matching) 
 依頼側のエージェント（Seeker）は、ユーザーからタス クを受け取ると、適切な能力を持つエージェントを探 す。
 
 ここが従来のAPI検索と違う点で、キーワード一致では なく、LLMを用いた意味的な照合（Semantic Matching） が行われる。
 
 ユーザーの依頼: 「来週の東京の天気が知りたい」
 エージェントAの説明: 「気象データの提供が可能」
 エージェントBの説明: 「株価予測が可能」
 判断: 依頼側エージェントはLLMの能力で「エージェン トAが適切だ」と判断します。
 
 

10. 動的バインディング (Dynamic Binding) 
 適切なエージェントを見つけたら、依頼側は その「エージェントカード」に書かれているイ ンターフェース定義（OpenAPI仕様など）を 読み込む。
 
 「どのURLに、どんなパラメータ（日付、場所 など）を送ればいいか」をその場で理解し、 リクエストを組み立てて送信する。

11. エージェントカードの中身(openapiに近い) 
 { "agent_id": "weather-pro-v1", "name": "Weather Pro Agent", "description": "世界中の現在および将来の気象情報を提供し、旅行計画の支援も 可能です。", "auth": { // 認証方法（OAuth2など、どうやってログインするか） "type": "oauth2", "token_url": "https://api.weather-pro.com/oauth/token" }, "capabilities": [ // 能力（Capabilities）：何ができるか { "name": "get_forecast", "description": "指定された緯度経度の7日間の天気予報を取得する", "input_schema": { ... }, // 必要なデータの型 "output_schema": { ... } // 返ってくるデータの型 } ], "servers": [ // コミュニケーションのエンドポイント { "url": "https://api.weather-pro.com/v1/agent" } ] }
12. 発見のアプローチ：中央集権 vs 分散型 
 ディスカバリーには2つの運用パターンがある。 
 
 分散型（Decentralized）:
 Webサイトのクローリングのように、エージェントがURL （.well-known）を直接叩いて確認する方法。 
 小規模な連携や、特定のパートナー間での利用に向いてい る。
 
 ディレクトリ型（Directory Service / Registry）: 
 企業内やプラットフォーム内に「エージェント版イエローページ （電話帳）」を用意する方法。 
 エージェントは起動時にこのディレクトリに自分を登録する。 
 依頼側はまずディレクトリに「天気予報ができるやついな い？」と聞きに行く。
 エンタープライズ環境では、セキュリティ管理の観点からこち らが主流。

13. ディスカバリーの効果 
 項目
 従来のAPI連携 (Before)
 A2A ディスカバリー (After)
 接続作業
 人間がドキュメントを読み、コード を書く
 エージェントがメタデータを読み、即座に接続 
 変更対応
 相手のAPIが変わるとエラーで止 まる
 メタデータの変更を検知し、リクエスト方法を自動修正 
 柔軟性
 事前に決められた相手としか繋 がれない
 「目的」さえ合えば、今日生まれた新しいエージェントとも繋 がれる

14. リスクと対策 
 「勝手に見つけて繋がる」ことにはリスクがある。 
 リスク回避のため、A2Aには以下の概念が含まれる。 
 
 信頼の連鎖 (Chain of Trust) 
 いくら機能がマッチしても、「署名がない」「認証されていない」 怪しいエージェントには接続しない。 
 
 人間による許可 (Human in the Loop) 
 「新しい『格安航空券エージェント』を見つけました。価格は安 いですが、ここに依頼していいですか？」と、初めて接続する 相手の場合のみ人間に許可を求める設定が可能。 

15. ご視聴ありがとうございました