https://github.com/google-agentic-commerce/AP2/blob/main/docs/specification

についてメモる。

AP2とは

Without a common, trusted protocol, the industry faces the prospect of a fragmented and insecure ecosystem, characterized by proprietary, siloed solutions that increase complexity for merchants, create friction for users, and prevent financial institutions from uniformly assessing risk. To address this gap, this protocol proposes an open, interoperable protocol for agent payments. This protocol, designed as an extension for emerging agent-to-agent (A2A) and model-context protocols (MCP), establishes a secure and reliable framework for AI-driven commerce.

Agentic AIによる決済ののためのオープンで相互運用性のあるプロトコル。 A2AやMCPといった他の勃興しているプロトコルの拡張としてデザインされている。

ロードマップ

  • V0.1: コアなアーキテクチャの確立・最も一般的なユースケースの有効化
    • pull型の決済手段のサポート
    • VDCに基づく透明な説明可能性をサポートするための堅牢なデータペイロード
    • 人間込みのシナリオ
    • ユーザーもしくは売り手のステップアップチャレンジ
    • A2Aプロトコルを使ったシーケンス図と参考実装
  • v1.x: コミュニティからのフィードバックやニーズの進化に合わせた拡張。ありえそうなところでいくと
    • push型の決済手段のサポート
    • 定期支払いやサブスクリプションのための標準化されたフロー
    • 人間不在のシナリオのサポート
    • MCPベースのシーケンス図
  • Long-term: よりひろい知性や柔軟性に対応
    • マルチ売り手状況などの複雑な配置に対応
    • 買い手と売り手のリアルタイム交渉をサポート

Section1: コマースの新たな地平：なぜエージェントの支払いが基礎的なプロトコルを必要とするのか

1.1 The Rise of Agent Commerce

  • コマースにおけるAIエージェントの登場

1.2 The Foundational Gap: A Crisis of Trust and Liability

  • 自律型エージェントの決済における課題 -　認可と追跡可能性
    • 意図の正当性
    • エージェントのエラーと「ハルシネーション」
    • 責任の所在の説明可能性
  • これらが整理されないと売り手は氾濫するリスクに曝されることになるし、ユーザーも経済的な権限をエージェントに渡したくはないだろう。

1.3 The Risk of a Fragmented Ecosystem

  • ユーザーにとっては混乱した経験であるとか、一部のエージェントしか使えないみたいな体験をさせる
  • 売り手にとっては標準化されていない複数のエージェントをサポートするのはしんどい
  • 決済エコシステムとしてはエージェントのトランザクションを監督することが困難になる

Section2: 信頼されたエージェントのエコノミーのための原則

  • 2.1 Openness and Interoperability
  • 2.2 User Control and Privacy by Design
  • 2.3 Verifiable Intent, Not Inferred Action
  • 2.4 Clear Transaction Accountability

Section3: アーキテクチャオーバービュー：安全な取引のためのロールベースなエコシステム

  • 登場人物を定義
  • トラスト構築のフローを定義
    • 直近の形
      • 大雑把にいうとallowlist方式
    • 長期的な形
      • MCPとA2Aがエージェントとそれが提示するユーザーのアイデンティティを検証可能にしてくれるといいな

Section4: トラストアンカー：VDCとMandate

  • このプロトコルでは主要なVCとして三つの委任が定義されている

4.1.1 The Cart Mandate

  • ユーザーの購入に対する認可を示す
  • ユーザーの要求によって売り手が発行

4.1.2 The Intent Mandate

  • 人間がリアルタイムでいないシナリオで重要な委任。ユーザーがいなくてもエージェントに購入をさせる認可に署名

4.1.3 The Payment Mandate for AI Agent Visibility to Payments Ecosystem

  • Cart Mandate, Intent Manateにboundされる
  • networl/issuer にも共有され、エージェNTによる取引のトラストを構築することを目的とする

Section 5: Core User Journeys

  • 人間がいるときといないときに分けて取引の流れ、シナリオを記載している

Section 6: Enabling Dispute Resolution

  • 原則三つ
    • 既存の規定やプロセスに可能な限り則り、新しいことは最小限だけにすること
    • 暗号学的なチェーンにより検証可能な照明を辿れること
    • ほとんどのケースにおいて現実のエンティティに着地すること
  • Table6.1 として、一般的に検証を行いたいいくつかのシナリオ（事故）について、用いるべき証拠をまとめている

Section 7: Technical Implementation

  • A2Aプロトコルに則った実装例を書いている
  • シーケンス図やサンプルコードもあり。

Section 8: Looking Ahead: Enabling Dynamic Commerce

  • このプロトコルが実現されるとこんな感じで嬉しいよね！という未来図

Section 9: A Call for Ecosystem Collaboration

  • まだまだ関連する領域が残っているのでみんなも一緒に考えてくれよな！という章
  • Real Time Trust Establishment
    • 最初はallowlistでいくけど、将来的にdiscoveryからverificationの標準は必要になるよね。
  • Delegated Authorization
    • ユーザーの＜代わりに＞エージェントが活動するためのスコープを定められた許可というのを得る方法がちゃんとあってほしいよな
  • Issuracne of Trusted Public Keys
    • 公開鍵はどのように配布されるべきなのか、そしてどのようにして利用者はそれを信用できるのか
    • 「トラストの根」をどう成立させるのか

Glossary

  • 用語集ですね