概要

MCPを補完するプロトコルであって、エージェント同士が協働するためのプロトコルとのこと。

疑問

全く見知らぬエージェント同士が協働するようになるのか？
契約などお金関連はどう解決する？
セキュリティ上の懸念は？使って良いエージェント一覧を提供する形になるか？→MCPとあまり変わらないような🤔
サーバーエージェントにはタスク実行に対する拒否権はあるのか？

Specificationを読み進める

The A2A protocol has three actors:

User The end user (human or service) that is using an agentic system to accomplish tasks.

Client The entity (service, agent, application) that is requesting an action from an opaque agent on behalf of the user.

Remote Agent (Server) The opaque ("black box") agent which is the A2A server.

サーバーがローカル実行前提のMCPの仕様とは異なり、こちらは"Remote"であることを明言している。

Agent Card

JSON形式で所定の場所にAgent Cardを公開すると、サーバーエージェントになれる模様。

Agent Cardの項目に、認証の項目があった。この辺りで、サーバーエージェント利用に係る契約情報が渡るのかも。

  // 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
  };

Agent-to-Agent Communication

クライアントエージェント側でタスクを作成し、サーバーエージェントがステータスを決定する。
タスク作成時に任意のセッションIDを設定することで、タスクを後で実行させたり、対話しながら情報を渡したりできるようになる。reject the requestとあるのは、サーバー側でリクエストを拒否できるのかな👀
タスク完了後にも、同じセッションIDを使用すればコンテキストを引き継いで次の作業を行える模様。

Tutorialを読む

Specificationを一通り読んだが、上記疑問の最後の項目以外は未解決なので、Tutorialも読んでみる。

Tutorialでも、得られる情報はサーバーを作るところが中心のよう。

ここまででわかったこと

全く見知らぬエージェント同士が協働するようになるのか？→ おそらくそのとおり
契約などお金関連はどう解決する？ → サーバー側のAgent CardにあるAuthenticationによって、エージェント事業者同士で契約する形になるのかも？
セキュリティ上の懸念は？使って良いエージェント一覧を提供する形になるか？　→ 現状では該当する情報はなし。ただし、認証フリーで作った悪意のあるサーバーエージェントを利用させられて問題が起こることも考えられるので、何らかのガードレールは必要かも
サーバーエージェントにはタスク実行に対する拒否権はあるのか？ → これはありそう