0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@engchinaTeam Coffee

A2Aで大事なのは「Agent同士をつなぐこと」ではなく「他のAgentに仕事を安全に委任できること」

0
Posted at

先に結論

を一通り読んで、一番強く感じたのはこれです。

A2A、つまり Agent2Agent Protocol は、単なる「Agent同士のチャット規格」ではありません。

もっと本質的には、

異なるベンダー・異なるフレームワーク・異なる組織で作られたAI Agent同士が、仕事を発見・依頼・追跡・完了できるようにするための標準プロトコル

です。

公式サイトでは、A2A は opaque agentic applications、つまり内部実装を隠したままのエージェント型アプリケーション同士の通信と相互運用を可能にする open protocol と説明されています。また、異なるフレームワークやベンダーで作られた agent のための共通言語だと説明されています。(A2A Protocol)

短く言うと、

MCP が Agent と Tool/Data をつなぐなら、A2A は Agent と Agent をつなぐ

ということです。

前回までに書いた Agent Skills、MCP、Codex Plugin と並べると、役割はこうなります。

技術 本質 AIに渡すもの
Agent Skills 作業手順 instructions、references、scripts
MCP 外部接続 tools、resources、prompts
Codex Plugin 配布単位 skills、apps、MCP servers、hooks
A2A Agent間通信 agent discovery、task delegation、messages、artifacts

つまり、

Skills は仕事のやり方、MCP は道具への接続、Plugin は配布、A2A は他のAgentへの委任

だと思いました。

A2Aとは何か

A2A は、AI Agent 同士が協調するための標準プロトコルです。

たとえば、ユーザーがこう頼んだとします。

海外出張の計画を立てて。
航空券、ホテル、現地移動、為替、観光候補も含めてまとめて。

このタスクは、1つの Agent だけで完結しないかもしれません。

  • Flight Booking Agent
  • Hotel Reservation Agent
  • Currency Conversion Agent
  • Local Tour Agent
  • Expense Policy Agent
  • Calendar Agent

こういう専門 Agent に分けた方が自然です。

でも、各 Agent が別々の会社、別々の framework、別々の runtime で作られていたらどうするか。

毎回カスタム連携を書くのはつらいです。
全部を tool として無理やり包むのも限界があります。
Agent は単なる関数ではなく、会話し、状態を持ち、確認し、成果物を返す存在だからです。

公式ドキュメントでも、A2A が解く問題として、agent を tool としてラップするやり方は agent 本来の交渉能力や複数ターンのやり取りを制限すると説明されています。A2A は、agent を agent のまま公開し、標準化された方法で相互作用できるようにするものです。(A2A Protocol)

ここがかなり大事です。

A2A は「リモート関数呼び出し」ではありません。

より近いのは、

別の専門家に仕事を依頼し、途中経過を受け取り、必要なら追加質問に答え、最後に成果物を受け取るプロトコル

です。

なぜA2Aが必要なのか

AI Agent が1つだけなら、A2A はいりません。

1つの Agent が自分の tools を呼び、自分の memory を使い、自分の判断でタスクを終えるなら、それで十分です。

でも、実務ではだんだんこうなります。

  • 営業 Agent
  • サポート Agent
  • 請求 Agent
  • 契約レビュー Agent
  • セキュリティ Agent
  • データ分析 Agent
  • 社内ナレッジ Agent
  • 顧客対応 Agent

それぞれが別のチームで作られる。
別のSaaSに組み込まれる。
別の権限を持つ。
別のモデルや framework で動く。

この状態で、Agent 同士が協力できないと、AI システムはまたサイロ化します。

公式ドキュメントでも、A2A の利点として interoperability、secure collaboration、agent autonomy、reduced integration complexity、long-running operations と streaming のサポートが挙げられています。(A2A Protocol)

つまり A2A が欲しい場面は、単に「Agentを呼びたい」場面ではありません。

次のような場面です。

  • 別システムの Agent に仕事を委任したい
  • Agent の内部実装を見ずに利用したい
  • 長時間かかるタスクの進捗を追跡したい
  • 途中で追加入力や認証が必要になる
  • 最終成果物を structured artifact として受け取りたい
  • 組織やベンダーをまたいで Agent を組み合わせたい

ここまで来ると、ただの function calling では足りません。

A2Aの登場人物

A2A を理解するには、まず3つの登場人物を押さえるのがよいです。

User
  ↓
A2A Client / Client Agent
  ↓
A2A Server / Remote Agent

User

リクエストやゴールを出す人、または自動サービスです。

人間の場合もあれば、別のシステムの場合もあります。

A2A Client

ユーザーの代わりに A2A 通信を開始する側です。

これはアプリケーションでもよいですし、別の AI Agent でもよいです。

たとえば、ユーザーのメインアシスタント Agent が、専門 Agent に仕事を依頼する場合、そのメインアシスタントが A2A Client になります。

A2A Server

仕事を受ける側の remote agent です。

A2A Protocol を実装した HTTP endpoint を公開し、依頼を受け取り、タスクを処理し、結果や状態更新を返します。

重要なのは、A2A Server は client から見ると black-box、つまり opaque な存在であることです。公式ドキュメントでも、remote agent は内部の memory、tools、実装詳細を client に公開しない opaque system として説明されています。(A2A Protocol)

これはかなり実務的です。

他社の Agent、他部署の Agent、SaaS 上の Agent を使うとき、内部の tool や prompt や memory を全部見せてもらう必要はありません。

必要なのは、

何ができるか
どう呼べるか
どう認証するか
どんな成果物を返せるか

です。

Agent Cardは「Agentの名刺」

A2A でかなり重要なのが Agent Card です。

Agent Card は、その Agent が何者で、何ができて、どこにいて、どう認証すればよいかを説明する JSON metadata document です。

公式ドキュメントでは、Agent Card は agent の identity、capabilities、endpoint、skills、authentication requirements を記述する metadata document であり、client が agent を発見し、安全かつ効果的に通信するために使うものだと説明されています。(A2A Protocol)

たとえば、イメージとしてはこうです。

{
  "name": "Travel Planning Agent",
  "description": "Helps plan international business trips.",
  "provider": {
    "organization": "Example Travel Inc."
  },
  "supportedInterfaces": [
    {
      "url": "https://agents.example.com/travel",
      "protocolBinding": "HTTP+JSON",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "plan_international_trip",
      "name": "Plan International Trip",
      "description": "Plans flights, hotels, local transport, and itinerary options.",
      "inputModes": ["text/plain"],
      "outputModes": ["application/json", "text/plain"]
    }
  ]
}

これは、MCP でいう tool description に少し似ています。

でも同じではありません。

MCP の tool description は「この関数をどう呼ぶか」に近い。
A2A の Agent Card は「この Agent とどう付き合うか」に近い。

ここが違います。

Agent は単発の関数ではなく、複数ターンのやり取り、長時間タスク、成果物生成、認証要求、追加質問を含むことがあるからです。

Agent Discoveryは「どのAgentに頼むか」を決める仕組み

A2A では、Agent 同士が協力する前に、まず相手を見つける必要があります。

公式ドキュメントでは、A2A の discovery には大きく3つの方法が説明されています。

  • well-known URI
  • curated registry
  • direct configuration / private discovery

public agent なら、標準パスに Agent Card を置く方法があります。

https://{agent-server-domain}/.well-known/agent-card.json

enterprise 環境では、Agent Card を中央 registry に登録し、skill、tag、provider、capability などで検索する形が自然です。private agent や開発用途では、設定ファイルや環境変数で Agent Card URL を直接渡す方式もあります。(A2A Protocol)

ここもかなり重要です。

Agent が増えると、「どの Agent に頼むべきか」が問題になります。

全部を人間が覚えるのは無理です。
全部を LLM の context に入れるのも無理です。
だから、Agent Card と discovery が必要になります。

これは Agent 版の service discovery に近いと思います。

A2Aの基本要素

A2A の基本要素は、次の5つで見ると分かりやすいです。

要素 役割
Agent Card Agent の自己紹介、endpoint、capabilities、skills、auth
Message client と agent の1ターンの通信
Task 状態を持つ作業単位
Part Message や Artifact の中身
Artifact Agent が生成した成果物

公式ドキュメントでも、Task は lifecycle を持つ stateful unit of work、Message は role を持つ1ターンの通信、Part は text/raw/url/data のいずれかを保持する content container、Artifact は document、image、structured data などの具体的成果物として説明されています。(A2A Protocol)

ここで特に大事なのは、Task と Artifact です。

普通のチャットだと、返答はただの message です。

でも、Agent に仕事を頼むと、返ってくるものは単なる文章ではありません。

  • 契約書レビュー結果
  • 旅行計画
  • 見積もり
  • コードパッチ
  • 画像
  • 分析レポート
  • JSON形式の判断結果
  • 承認待ち状態
  • 追加質問

こういうものを扱うには、Message だけでは弱いです。

A2A は、そこを Task と Artifact で表現します。

Taskは「長く続く仕事」を扱うための単位

A2A では、Agent は client から message を受け取ったとき、2種類の返し方ができます。

1つは stateless Message。
もう1つは stateful Task。

公式ドキュメントでは、すぐ終わる自己完結したやり取りには Message、長く処理し、進捗管理や追加入力が必要な場合には Task を使うと説明されています。Task は input-required、auth-required のような interrupted state、または completed、canceled、rejected、failed のような terminal state に到達するまで lifecycle を進みます。(A2A Protocol)

たとえば、こういうイメージです。

Client:
  この顧客の契約更新リスクを分析して

Remote Agent:
  Taskを作成
  状態: submitted

Remote Agent:
  状態: working
  CRM、契約履歴、サポート履歴を確認中

Remote Agent:
  状態: input-required
  どの地域の契約条件を使うか確認したい

Client:
  日本リージョンの条件で進めて

Remote Agent:
  状態: working

Remote Agent:
  状態: completed
  Artifact: 契約更新リスク分析レポート

このように、Agent 間の仕事は一発の request/response では終わらないことがあります。

だから Task が必要になります。

contextIdは「同じ話の続き」を表す

A2A では contextId も重要です。

contextId は、複数の Task や Message を論理的にまとめるための識別子です。

公式ドキュメントでは、client が後続 message に同じ contextId を含めることで、前の interaction の続きであることを示せると説明されています。また、同じ context の中で複数の task が並行して進むこともあります。(A2A Protocol)

たとえば、旅行計画ならこうです。

contextId: trip-planning-2026-07

Task 1: 航空券を探す
Task 2: ホテルを探す
Task 3: 現地移動を調べる
Task 4: Task 1の結果をもとに日程表を作る

同じ文脈の中で、複数の仕事が連動します。

これができると、Agent同士の連携はかなり自然になります。

Taskは完了したら再開しない

A2A の設計で面白いのは、Task immutability です。

公式ドキュメントでは、Task が terminal state、つまり completed、canceled、rejected、failed になったら再開できないと説明されています。後続の修正や refinement は、同じ contextId の中で新しい Task として始める設計です。(A2A Protocol)

これは地味ですが、かなり大事です。

なぜなら、仕事の単位が曖昧になると、追跡できなくなるからです。

悪い例です。

Task 1: レポート作成
Task 1: ちょっと修正
Task 1: さらに修正
Task 1: やっぱり前の版に戻す

これだと、どの入力がどの成果物を作ったのか分かりにくいです。

A2A 的には、こうした方がきれいです。

Task 1: 初版レポート作成 → Artifact v1
Task 2: Task 1を参照して修正版作成 → Artifact v2
Task 3: Task 2を参照して要約版作成 → Artifact v3

この方が、監査、デバッグ、再現性、承認に強いです。

StreamingとPush Notificationは実務向け

Agent の仕事は時間がかかることがあります。

数秒で終わるものもあれば、数分、数時間、場合によっては数日かかるものもあります。

A2A はここをかなり現実的に扱っています。

公式ドキュメントでは、A2A は長時間タスク、複数ステップの処理、incremental results、人間の介入が必要な操作を扱うために、Streaming と Push Notifications を提供すると説明されています。(A2A Protocol)

Streaming

Streaming は、client が接続を維持できる場合に使います。

たとえば、長い文書生成、動画処理、分析レポート作成などで、途中経過をリアルタイムに受け取りたい場合です。

A2A では SSE、つまり Server-Sent Events を使って、Task の状態更新や Artifact の incremental update を送れます。server は Agent Card で capabilities.streaming: true を示し、client は streaming message を送って update を受け取ります。(A2A Protocol)

Push Notification

Push Notification は、client が接続を維持できない場合に使います。

たとえば、mobile app、serverless function、数時間かかるバックグラウンド処理などです。

この場合、client が webhook URL を登録し、A2A Server が重要な state change のタイミングで通知します。公式ドキュメントでは、push notification は terminal state、input-required、auth-required などの重要な更新を通知する用途が説明されています。(A2A Protocol)

ここで大事なのは、A2A が「すぐ返すチャット」だけを前提にしていないことです。

実務の Agent は、待つ。
途中で止まる。
人間に確認する。
認証を求める。
後で結果を返す。

A2A はそこをプロトコルとして扱おうとしています。

セキュリティはA2Aの中心

A2A は Agent 同士をつなぎます。

つまり、セキュリティを後付けにすると危ないです。

公式ドキュメントでは、A2A は enterprise requirements を前提に設計されており、新しい独自セキュリティ標準を作るのではなく、既存の enterprise infrastructure、identity management、monitoring、governance と統合する考え方が説明されています。(A2A Protocol)

重要なポイントは次です。

  • 本番環境では HTTPS
  • OAuth2 / OpenID Connect など標準的な Web 認証
  • 認証情報は A2A payload ではなく HTTP header で扱う
  • authorization は skill 単位、data/action 単位で制御する
  • least privilege を守る
  • tracing、logging、metrics、auditing を入れる

公式ドキュメントでも、A2A payload は user/client identity を直接持たず、identity は transport/HTTP layer で確立されると説明されています。また、A2A server は受け取ったすべての request を server-side で認証し、権限不足なら 401 / 403 相当を返す設計が説明されています。(A2A Protocol)

ここはかなり良い設計だと思いました。

AI Agent の protocol と言っても、特別な世界を作るのではなく、Web の実績ある設計に寄せている。

これは enterprise adoption には重要です。

Agent Cardも保護対象

Agent Card は「名刺」ですが、公開してよいとは限りません。

Agent Card には、内部 endpoint、sensitive skill、認証方式、capability 情報が含まれる可能性があります。

公式ドキュメントでも、internal/restricted agents の URL や sensitive skills の説明を含む Agent Card は sensitive information になり得るため、認証・認可で保護すべきだと説明されています。また、静的 secret を Agent Card に埋め込むのではなく、out-of-band dynamic credentials を使うことが強く推奨されています。(A2A Protocol)

これは見落としやすいです。

「Agent Card は discovery 用だから公開してよい」と考えると危険です。

社内 Agent の一覧。
できること。
内部 URL。
権限モデル。
業務フロー。

これらは攻撃者にとって有用な情報になる可能性があります。

だから、Agent Card にも public card と authenticated extended card のような考え方が必要になります。

MCPとの違い

A2A を理解する一番簡単な方法は、MCP と比べることです。

公式サイトでも、MCP と A2A は競合ではなく complementary、つまり補完関係だと説明されています。MCP は agent-to-tool communication、A2A は agent-to-agent communication を扱うものです。(A2A Protocol)

観点 MCP A2A
つなぐ対象 Agent ↔ Tool / Data / API Agent ↔ Agent
相手の性質 比較的 stateless な機能 stateful / autonomous な専門Agent
典型例 DB query、GitHub API、calculator、file search Billing Agent、Travel Agent、Support Agent
主な単位 tools、resources、prompts Agent Card、Message、Task、Artifact
会話の性質 structured input/output multi-turn、delegation、negotiation
目的 Agentが道具を使う Agentが他のAgentと協力する

MCP はとても重要です。

でも、MCP は基本的には「道具を使う」ためのものです。

A2A は「相手も自律的な Agent である」ことを前提にします。

公式ドキュメントでも、MCP の domain は calculator、database query API、weather lookup service のような well-defined input/output を持つ tools/resources であり、A2A の domain は reasoning、planning、multi-turn dialogue、state を持つ agents だと説明されています。(A2A Protocol)

つまり、

MCP:
  この道具を呼んで

A2A:
  この仕事をあなたの専門性で進めて

です。

この違いはかなり大きいです。

Skills / MCP / Plugin / A2A の関係

ここまで読んで、前回までの記事と合わせると、AI Agent の技術スタックが少し見えてきます。

Agent Skills:
  この仕事はこう進める

MCP:
  この外部ツール・データにはこう接続する

Codex Plugin:
  Skills・Apps・MCPを配布可能な形にまとめる

A2A:
  他のAgentを発見し、仕事を依頼し、結果を受け取る

もう少し具体的に言うと、こうです。

契約レビューAgent
  - Skills: 契約レビューの観点
  - MCP: 契約DB、社内規程、過去チケットに接続
  - Plugin: チーム向けに配布
  - A2A: 請求Agentや営業Agentに追加確認を依頼

これらは競合しません。

むしろ、組み合わせるものです。

A2A だけでは、Agent の内部 tools は増えません。
MCP だけでは、他の Agent との長期的な協調は表現しにくい。
Skills だけでは、外部接続や Agent 間通信は定義できない。
Plugin だけでは、通信プロトコルにはならない。

役割が違います。

v1.0で何が重要か

A2A 公式サイトでは、latest released version として 1.0.0 が示されています。v1.0 は protocol maturity、type safety、developer experience、enterprise-ready features を重視したリリースとして説明されています。(A2A Protocol)

特に大事なのは、A2A が「実験的なアイデア」から「本番利用を意識した標準」に寄ってきている点です。

v1.0 の発表記事では、A2A v1.0 は production-ready standard for agent-to-agent communication と説明されています。また、multi-protocol bindings、version negotiation、common semantic model によって、異なる technology stack や組織境界をまたいだ相互運用を目指すと説明されています。(A2A Protocol)

v1.0 で特に目立つのは次です。

  • multiple protocol bindings
  • version negotiation
  • multi-tenancy
  • signed Agent Cards
  • stronger security scheme declarations
  • cleaner model objects
  • standardized operations
  • improved migration path

これは、実務で使うならかなり大事です。

Agent 間通信は、ただ動けばよいわけではありません。

バージョンが違う。
組織が違う。
認証が違う。
権限が違う。
監査が必要。
一部だけ移行したい。

こういう現実を扱う必要があります。

A2Aの仕様は3層で見ると分かりやすい

A2A の仕様は、3層で整理されています。

層 内容
Data Model Task、Message、AgentCard、Part、Artifact、Extension
Operations Send Message、Send Streaming Message、Get Task、List Tasks、Cancel Task、Get Agent Card
Protocol Bindings JSON-RPC、gRPC、HTTP/REST、Custom Bindings

公式仕様でも、A2A specification は Canonical Data Model、Abstract Operations、Protocol Bindings の3層に整理されており、core semantics を protocol binding 間で一貫させること、新しい binding を data model を変えずに追加できることが目的とされています。(A2A Protocol)

ここは実装者にとって重要です。

A2A は単なる JSON-RPC の仕様ではありません。
gRPC だけの仕様でもありません。
HTTP endpoint の形だけでもありません。

まず共通の data model があり、次に abstract operation があり、それを各 transport/binding に落とす。

この設計だから、いろいろな環境に載せられるのだと思います。

Multi-Tenancyは企業利用で効く

A2A では、1つの endpoint で複数の agents や tenants を扱うことも想定されています。

公式ドキュメントでは、single A2A endpoint が multiple agents or tenants を serve でき、routing 実装は protocol が固定せず、operator が infrastructure に合う方式を選べると説明されています。主な方法として、URL path、authentication header、request body の tenant field が挙げられています。(A2A Protocol)

これは企業ではかなり現実的です。

たとえば、こういう構成です。

https://agents.example.com/billing
https://agents.example.com/support
https://agents.example.com/legal

または、同じ endpoint に送って、token の scope や tenant field で routing する。

大規模な Agent platform を作るなら、この考え方は避けられません。

Extensionsは「標準を壊さず広げる」仕組み

A2A は core protocol だけで全部を解決しようとしていません。

domain-specific な要求や advanced use case のために、Extensions という仕組みがあります。

公式ドキュメントでは、extensions は base protocol に新しい data、requirements、RPC methods、state machines を重ねるための仕組みであり、Agent Card で support を宣言し、client が request 時に opt in できると説明されています。(A2A Protocol)

これは良いバランスです。

標準は小さく保ちたい。
でも、実務では拡張したい。
各業界や各組織の要求もある。

そこで extensions です。

ただし、何でも自由に変えてよいわけではありません。

公式ドキュメントでは、core data structures の定義変更や enum value の追加など、core type validation を壊す変更は extension では許されないと説明されています。また、extension activation はデフォルト無効で、client が A2A-Extensions header で有効化を要求し、agent が response で activated extensions を返す流れになっています。(A2A Protocol)

つまり、

core は安定させる
追加機能は extension で交渉する

という設計です。

今からA2Aを触るなら、こう始める

最初から大規模な multi-agent platform を作る必要はありません。

小さく始めるなら、こういう順番がよいと思います。

1. まずAgent Cardを書く

最初に決めるべきは、実装ではなく「この Agent は何者か」です。

  • name
  • description
  • provider
  • endpoint
  • supported interfaces
  • capabilities
  • authentication
  • skills
  • input/output modes
  • examples

Agent Card を書くと、その Agent の境界が見えます。

何をできると言ってよいのか。
何はできないのか。
どんな成果物を返すのか。
認証が必要なのか。

ここを曖昧にしたまま実装すると、Agent はすぐ大きくなりすぎます。

2. Messageだけで返すか、Taskを作るかを決める

次に、依頼に対して Message で返すのか、Task を作るのかを決めます。

すぐ終わるなら Message。
追跡が必要なら Task。
途中で人間入力や認証が必要なら Task。

公式ドキュメントでも、agent は即時応答なら Message、長時間・状態管理が必要な作業なら Task を返すと説明されています。(A2A Protocol)

3. Artifactをちゃんと設計する

Agent の成果物をただの文章にしない方がよいです。

たとえば、

  • risk_report.json
  • contract_review.md
  • itinerary.pdf
  • code_patch.diff
  • analysis_result.csv

のように、成果物として扱える形にする。

A2A では Artifact が tangible output として定義されています。document、image、structured data などを返せるので、実務向けにはここをちゃんと設計する価値があります。(A2A Protocol)

4. Streamingは後からでよい

最初は polling でもよいと思います。

でも、長いレポート生成や進捗が重要なタスクでは streaming を入れる。

さらに数時間以上かかるもの、または client が常時接続できないものは push notification を考える。

5. 最初から認証とログを入れる

A2A は Agent 間通信なので、後からセキュリティを入れるのはつらいです。

少なくとも、

  • HTTPS
  • authentication
  • skill-based authorization
  • taskId / contextId / correlationId のログ
  • audit log
  • metrics
  • tracing

は最初から設計した方がよいです。

公式ドキュメントでも、A2A は HTTP に基づくため、既存の distributed tracing、logging、monitoring tools と統合しやすいと説明されています。OpenTelemetry、W3C Trace Context、taskId、correlation IDs、audit events なども例として挙げられています。(A2A Protocol)

A2Aで失敗しやすいところ

1. AgentをToolとして扱ってしまう

一番ありがちな失敗はこれです。

Agent をただの tool として扱う。

call_billing_agent(customer_id)

これで済むなら MCP tool でよいです。

A2A を使う意味があるのは、相手が自律的に考え、質問し、状態を持ち、成果物を返す場合です。

2. Agent Cardのdescriptionが弱い

Agent Card の skill description が弱いと、client はどの Agent に頼めばよいか判断しにくくなります。

悪い例です。

{
  "name": "Support Agent",
  "description": "Helps users."
}

これでは広すぎます。

よい例はこうです。

{
  "name": "Billing Dispute Agent",
  "description": "Handles invoice disputes, refund eligibility checks, payment status explanations, and escalation preparation for enterprise billing cases."
}

何ができるか。
何ができないか。
どんな input/output に対応するか。
どんな例があるか。

ここを具体的にした方がよいです。

3. Taskの粒度が大きすぎる

1つの Task に全部を詰めると、進捗も成果物も追いにくくなります。

旅行計画なら、

  • 航空券
  • ホテル
  • 日程表
  • 見積もり
  • 最終提案

を分ける方がよいかもしれません。

A2A は contextId で関連 task をまとめられるので、全部を1つの巨大 task にする必要はありません。

4. Artifactをバージョン管理しない

A2A 仕様では artifact mutation の完全な version history は client 側で管理する考え方です。公式ドキュメントでも、refinement task による新しい artifact は古い artifact から作られることがあり、最新の許容版を管理するのは client が最も適していると説明されています。(A2A Protocol)

つまり、server が全部を覚えてくれると思わない方がよいです。

client 側で、

artifact v1
artifact v2
artifact v3
accepted artifact

を管理する必要があります。

5. Push Notificationのセキュリティを軽く見る

Push Notification は便利ですが、危険でもあります。

server が client 提供 URL に POST するからです。

公式ドキュメントでも、A2A Server は client から渡された webhook URL を盲目的に信頼して POST してはいけないと説明されています。悪用されると SSRF や DDoS amplifier になり得るため、allowlist、ownership verification、egress firewall などが推奨されています。(A2A Protocol)

これは本当に大事です。

Webhook は便利ですが、攻撃面も広がります。

まとめ

A2A は、AI Agent 同士をつなぐための標準プロトコルです。

ただし、本質は「Agent同士が会話できる」ことではありません。

本当に大事なのは、

  • Agent を Agent のまま公開する
  • Agent Card で能力と接続方法を説明する
  • Message と Task を分ける
  • 長時間タスクを lifecycle として扱う
  • Artifact を成果物として返す
  • Streaming / Push Notification で非同期処理を扱う
  • OAuth、HTTPS、authorization、observability を前提にする
  • MCP と競合せず、MCP の上位協調レイヤーとして使う

という点です。

Agent Skills は、AI に仕事のやり方を渡します。
MCP は、AI に外部 tool と data への接続を渡します。
Codex Plugin は、それらを配布可能な形にします。
A2A は、AI Agent 同士が仕事を委任し合えるようにします。

これから AI Agent を実務で使うなら、1つの Agent を賢くするだけでは足りません。

重要になるのは、

どの Agent に、どの仕事を、どの権限で、どの成果物を期待して依頼するか

を設計する力だと思います。

A2A は、そのためのかなり重要な標準になりそうです。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?