A2Aとは｜相手のエージェントを調べずに繋ぐための、名刺のような仕組み

A2Aは何のための規格なのか

別々に作られたAIエージェント同士を、共通の手順で繋ぐための規格です。相手の作りを知らなくても会話できる状態を目指しています。

A2A（Agent2Agent Protocol）は、AIエージェント同士がやり取りし協調するためのオープンな規格です。公式サイトはそう定義しています。

背景にあるのは、エージェントの作り方がばらばらだという事実です。LangGraph、CrewAI、独自実装と、基盤も開発元も異なります。繋ごうとするたびに相手ごとの調べ物が発生していました。

中身を見せずに繋ぐ

A2Aの特徴は、相手の中身が分からないままでも繋げることです。公式はこれを、中身が見えないエージェント同士の相互運用を可能にする規格、と表現しています。

これは実務上、重要な性質です。他社のエージェントを使うとき、相手の実装を知る必要も、公開してもらう必要もありません。決まった手順で話しかければ済みます。

MCPとは役割が違う

よく混同されるのがMCPとの関係です。公式は両者を並べて、MCPで道具やデータに繋ぎ、A2Aで他のエージェントに繋ぐと説明しています。競合する規格ではありません。

カードを見るだけで、条件に合う相手を選べた

A2Aの中心にあるのがAgent Cardです。相手の能力を機械が読める形で書いておく仕組みで、実際に扱って探索してみました。

A2Aで最初に理解すべきなのがAgent Cardです。仕様書はこれを、エージェントの自己記述的な設定書と定義しています。名前、説明、できること、通信方法、必要な認証がここに書かれます。

置き場所も決まっていて、仕様書の例では /.well-known/agent-card.json を取得しています。場所を知っていれば中身は読めるという作りです。

実験: 独自の繋ぎ込みと比べる

手元で試しました。独自仕様で繋ぐ場合、相手ごとに窓口の場所・送る項目名・応答の読み方を把握する必要があります。A2Aならカードの場所だけで済みます。

下のコードは読み飛ばして大丈夫です。3体のエージェントのカードを用意して、「文字を受け取って文字を返せる相手」をカードだけから探しています。

// 仕様の必須項目がそろっているかを確かめる
function validateCard(card) {
  const missing = ['name', 'description', 'skills'].filter((k) => card[k] === undefined);
  return missing.length ? `不備（不足: ${missing.join(', ')}）` : '利用可能';
}

// 入力と出力の形式から、条件に合う相手を探す
function findByCapability(inputMode, outputMode) {
  return Object.entries(agentCards)
    .filter(([, c]) => c.skills.some(
      (s) => s.inputModes.includes(inputMode) && s.outputModes.includes(outputMode)))
    .map(([id]) => id);
}

--- 独自仕様: 相手を1つ増やすときに書くもの ---
  既存の繋ぎ込み: 2件
  1件あたりに必要: エンドポイント・入力の項目名・応答の読み方 の3つ
  3つ目を足すと合計: 9項目を把握する必要がある
--- A2A: 相手を1つ増やすときに書くもの ---
  必要なのは Agent Card の場所だけ。中身は取得して読む
  translator  利用可能 — 文章を指定言語へ翻訳する
  summarizer  利用可能 — 長文を要約する
  ocr         利用可能 — 画像から文字を読み取る
--- カードだけを見て「文字→文字」ができる相手を探す ---
  該当: translator, summarizer
  画像→文字ができる相手: ocr

選べました。translator と summarizer の2体です。それぞれの実装は一切見ていません。カードに書かれた入力と出力の形式だけで判断しています。

なぜ相手が増えても手間が増えないのか

画像を入力できる相手を探すと、今度は ocr だけが返ります。相手が増えても、探し方は変わりません。カードの形式が同じなので、読む処理を書き足す必要がないからです。

いま自分が使う場面はあるのか

判断は単純です。繋ぎたい相手が道具ならMCP、自分で判断して動くエージェントならA2A。そして相手が対応しているかを先に確認します。

A2Aを採用するかどうかは、規格の優劣ではなく何に繋ぐかで決まります。公式の説明どおり、道具とデータはMCP、他のエージェントはA2Aという分担です。

切り分けは「道具か、相手か」

判断の基準は、繋ぐ先が呼べば決まった結果を返すものか、自分で判断して手順を決めるものかです。前者は道具なのでMCP、後者はエージェントなのでA2Aになります。

検索やファイル操作は前者です。「この資料をまとめて、必要なら追加で調べて」と頼めるものは後者になります。同じ処理でも、判断が相手側にあるかどうかで分かれます。

個人開発ではまだ先の話が多い

現時点で個人開発に必要になる場面は限られます。1つのアプリの中で完結する構成なら、エージェント間の通信は発生しないためです。

必要になるのは、自分のエージェントを外部に公開する場合か、外部のエージェントに作業を頼む場合です。どちらも相手が存在してはじめて意味を持つので、繋ぎたい先が決まってから調べれば足ります。

エージェントに道具を持たせる仕組みについては、MCPの解説記事で扱う予定です。あわせてAPI連携の記事も、繋ぎ込みの考え方として参考になります。