概要
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によって、エージェント事業者同士で契約する形になるのかも？
- セキュリティ上の懸念は？使って良いエージェント一覧を提供する形になるか？ → 現状では該当する情報はなし。ただし、認証フリーで作った悪意のあるサーバーエージェントを利用させられて問題が起こることも考えられるので、何らかのガードレールは必要かも
- サーバーエージェントにはタスク実行に対する拒否権はあるのか？ → これはありそう