エージェンティック決済プロトコル図：なぜ乱立しているのか

• AIエージェントが自律的に購入・支払い・精算を行うために、複数の決済プロトコルが並行して登場している
• ACP、UCP、AP2、x402などはいずれも決済を扱うが、コマース・B2B・エージェント間決済のように、それぞれ異なる問題領域を狙っている
• インターネットはもともと情報伝達を目的に設計されており、決済レイヤーが存在しなかった。HTTP 402ステータスコードは1997年に定義されたが、実際には実装されていない
• エージェント取引では、信頼レイヤーが決済以前の前提条件として浮上しており、ERC-8004やVisa TAPのようなプロトコルがこの役割を担う
• コマース領域では、OpenAI・StripeのACPとGoogle・ShopifyのUCPが中核を成し、それぞれChatGPTとGemini環境で活用されている
• エージェント間決済は、コンピューティング・データ・API利用に対する大規模なマイクロペイメントの可能性を開き、自律的なリソース取引構造を予告している
• 今後のエージェント経済は単一標準ではなく、役割の異なるプロトコルが階層的に結合されたスタック構造へ進化する可能性が高い

---

エージェンティック決済プロトコル乱立の背景

• ACP、UCP、A2P、AXTP、x402など多様な略語が登場し、エージェンティック決済領域は混乱した状態にある
• プロトコルが増えた理由は、すべてが同じ問題を解いているわけではないから
• コマース、B2B決済、エージェント間決済は、要件と制約がそれぞれ異なる
• これをひとつの問題として扱うとかえって構造を理解しにくくなる

インターネットプロトコルの構造と決済レイヤーの不在

• インターネットはTCP/IP、DNS、HTTP/Sのような複数のプロトコルが連携して動作し、ひとつの滑らかなユーザー体験を形作っている
  • TCP/IP: アドレス指定とルーティング、データの安定的な伝送を担当
  • DNS: 人が読めるドメイン名をIPアドレスに変換
  • HTTP/S: Webページやメディアの要求・転送を担当し、HTTPSは暗号化によってセキュリティを強化
• gRPC、WebSocketなど新しいプロトコルが継続的に追加され、インターネットは静的な構造ではなく進化するシステムとなっている
• HTTPステータスコード402(Payment Required) は1997年に定義されたが、実際に使われたことはない
• インターネットは最初から情報伝達を目的に設計されており、決済は別個の金融システムを通じて事後的に接続されてきた
  • ブラウザで始まったリクエストは、販売者、決済ゲートウェイ、Visa・ACHのような金融ネットワークへ順に渡される
• 「カートに入れる」から「決済精算」までの全工程を包括的に扱う単一の決済プロトコルは存在しない

エージェントがあらわにした決済レイヤーの空白

• キーボードと画面を前提に設計された既存インフラは、機械の速度で判断し行動するソフトウェアエージェントには適していない
• エージェントが人の代わりに購入を行うとき、新たな問題が露出する
  • 新しい顧客タイプ: エージェントがどの店舗と商品を選ぶかを自ら決定しなければならず、販売者は人間ではなくエージェントを対象に最適化する必要がある
    → Agent Engine Optimization(AEO) という概念が浮上
  • 新しい決済チャネル: チャットインターフェースがそのまま決済窓口となり、従来のコンバージョンファネル・A/Bテスト・カート離脱メールの意味は薄れる
  • 新しい不正リスク: エージェントが承認済みユーザーと正当な決済手段を用いているのか、盗まれた認証情報を自動で悪用しているのかを即座に検証する必要がある

信頼レイヤー：取引相手の確認

• MCPとA2Aはエージェント間通信を担うが、ERC-8004仕様ではエージェントの発見と信頼を本質的には扱えないことが明記されている
• エージェント間取引に先立って正当性の確認が必要であり、販売者は無差別なボットではなく信頼できるエージェントだけを許可しなければならない
• これを解決するために2つのアプローチが登場している
  • ERC-8004(Trustless Agents): MetaMask、Google、Coinbase、Ethereum Foundationが参加するオンチェーン基盤の身元・評判・検証レジストリで、Draft EIP段階にある
    • エージェント登録情報にはMCPエンドポイント、A2Aエージェントカード、ENS名、DIDなどを併記できる
    • 既存のエージェント通信プロトコルを置き換えるのではなく、信頼とアイデンティティ情報を補完する構造
  • Visa Trusted Agent Protocol(TAP): Visaが開発中のプロトコルで、販売者が信頼できるエージェントを一般的なボットと区別できるよう、検証可能な署名を提供する
    • コマース目的を持つVisa信頼エージェントであることを証明
    • ロイヤルティアカウントやデバイス識別子を通じて、特定の消費者を代理していることを確認
    • 販売者が検証可能な有効決済資格情報も合わせて確認できる
• 要点: 信頼は決済の出発点であり、「どう支払うか」より先に「このエージェントを信頼できるか」を解決する必要がある

コマースプロトコル：最も速く拡大している領域

• エージェンティックコマースは、商品探索・選択・支払いという購買の瞬間全体をエージェントに委ねる構造
• これを標準化するため、2つの中核プロトコルが浮上している
  • Agentic Commerce Protocol(ACP): OpenAIとStripeが共同開発したプロトコルで、カートを構成し、PSPに渡す決済トークンを生成する方式を定義する
    • ChatGPT環境でWalmart、Etsy、Instacartとともに実運用中
    • カート構造、決済トークン生成、チェックアウト完了手順を明確に定めた取引中心の標準
  • Universal Commerce Protocol(UCP): GoogleとShopifyが主導するプロトコルで、販売者がエージェントに公開するサーバーを自ら構成する
    • Google SearchとGeminiに順次適用予定
    • 販売者がcapability manifestを公開し、エージェントがそれを発見・交渉するオーケストレーションフレームワーク
    • コマース領域でDNSに似た役割を果たす
• 構造的な違い: UCPは初期実装負荷が大きいが全工程で高い柔軟性を提供し、ACPは既存決済システムとの連携が比較的容易
• ChatGPTとGeminiの両方で露出するには、ACPとUCPの両方をサポートしなければならない状況になっている

決済ネットワークレベルのプロトコル

• Visa Intelligent Commerce(VIC): Visaが開発したプロトコルで、エージェントがVisaネットワーク上で決済を完了できるよう、カードに類似したセキュアトークンを生成する
  • 現在はテスト段階で、2026年下半期のリリース予定
• Mastercard Agent Pay(MAP): Mastercardが開発したプロトコルで、Mastercardネットワーク上で使えるセキュアトークンを生成する
  • テスト段階で、2026年下半期のリリース予定
• 両標準は構造と目的がほぼ同一で、主な違いはそれぞれ自社の決済ネットワークでしか動作しない点にある
• ネットワークレベルで発行されるトークンにより、消費者保護、チャージバック処理、不正対応は既存のカード決済と同じ方式で維持される

B2B決済フローの差別化された要件

• 消費者向けコマースが注目されているが、実際の取引規模はB2B決済のほうがはるかに大きい
  • 請求書支払い、サプライヤー支払い、給与支払いなど、企業間精算が大半を占める
• B2B決済フローの特性
  • 決済金額が大きく、実行後の取り消しが難しい
  • 請求書照合、承認手続き、監査証跡のような内部統制が必要
  • ACHや電信送金のように、速度は遅いが構造的に柔軟なレールを利用
• この領域では、エージェントが中間レイヤーを経由するより決済レールと直接通信するケースが多い
• 利用される決済レール
  • ステーブルコイン(USDC, USDT): オンチェーンで直接決済が行われ、トランザクション内にルールやロジックを組み込める
    • Catena Labs、Paymanのような企業で実際に使われている
  • 従来型レール(ACH, Wire): エージェントが決済情報を準備した後、既存の金融レールへ送信する
• ステーブルコインはカード決済に近い成功保証と高いプログラマビリティを提供するが、業界全体で通用する明確な標準はまだ形成されていない

エージェント間決済：最大の潜在力

• インターネット上の価値あるリソースの大半は、APIキーとサブスクリプションモデルの背後に縛られている構造になっている
• 従来のアクセス方式では、アカウント作成、前払いチャージ、キー発行を経て初めてサービスを利用できる
• 数十億のエージェントがコードを書き、相互に取引し、必要な時点でリソースを利用する環境では、このモデルはスケールしない
• 現在明らかになっている2つの主要な摩擦点
  • トークン枯渇問題: エージェントが作業中に上限へ達すると、人が直接チャージしなければ作業を継続できない
  • APIキー問題: エージェントが新しいサービスを必要とするたびに、ユーザーが直接登録し、認証情報を生成して渡さなければならない
• これらの制約により、エージェントは完全な自律性を持てず、法人カードや重要な認証情報を任せられないジュニア開発者に似た立場にとどまる

エージェントネイティブなプロトコル

• Google Agent to Pay(AP2): A2Aフレームワークの一部で、人がエージェントに決済権限を委任するためのmandate構造を定義する
  • x402、UCPとともに動作するよう設計された抽象レイヤーのプロトコルであり、相互排他的な関係ではない
  • 検証可能な資格情報を基盤に、次のようなmandateを区別する
    • cart mandate: エージェントが購入できる範囲
    • intent mandate: 人が実際に望む目的
    • payment mandate: 保存された決済資格情報
• HTTP x402: CoinbaseとCloudflareが開発した方式で、アクセス制限されたリソースへのリクエスト時にHTTP 402を返し、ステーブルコイン決済へ誘導する
  • BaseネットワークとCloudflare環境でテストが進行中
• Agent Transaction Protocol(AXTP): CircuitとChiselが開発中のプロトコルで、エージェントがMCPサーバー利用料を支払ったり、その対価として収益を得たりできるよう設計されている
  • まだ初期段階
• コンピューティング資源、データ、API呼び出し単位で即時に細分化される大規模マイクロペイメントが可能になり、これまで十分に収益化されてこなかった領域で膨大な新規取引量が生まれる可能性がある

全体のプロトコル構造と展望

• 現時点のエージェンティック決済エコシステムは整理されていない混在状態にある
• Google中心のスタック形成: A2A → AP2 → UCPへと続く構造が登場し、コマースと非コマース決済の両方を包含する
• 各プロトコルは異なる抽象化レイヤーで役割を分担している
  • エージェント通信レイヤー: エージェント間メッセージ交換方式を標準化 (MCP, A2A)
  • 信頼レイヤー: エージェントの身元と信頼性を判断し、身元・評判を管理 (ERC-8004, Visa TAP)
  • 委任レイヤー: 決済権限と資格情報の保有有無を確認 (AP2 mandates, VIC/MAP tokens)
  • 取引フローレイヤー: 何を買い、どう支払うかについての発見・交渉・チェックアウトを管理 (ACP, UCP)
  • 認証レイヤー: 取引の正当性検証、セキュリティ維持、不正防止、取り消し処理
  • 決済レールレイヤー: 実際の支払い実行。カード・ACH・ステーブルコインを活用

主な示唆

• 現在の標準はまだ形成段階にあり、不完全で採用も限定的
  • 今後、WAPやBetamaxのように消える可能性も排除できない
• ただしそれは、AIエージェント自体が消えるという前提に立つ話であり、その可能性は低い
• 販売者、決済事業者、金融機関が注目すべき点
  1. Googleの影響力: 過去にインターネット標準を主導してきた前例があり、A2A・AP2および関連スタックが長期的に維持される可能性が高い
  2. コマース優先戦略: ACPとUCPをサポートすれば、ChatGPTとGeminiという2大消費者向けLLM環境の両方に露出できる
  3. 信頼インフラの重要性: エージェントトラフィックが増えるほど身元と評判の問題は複雑化し、ERC-8004とVisa TAPはこの点を狙っている
  4. B2B決済の機会: 取引規模が大きく、まだ標準が整理されていない領域であり、ステーブルコイン導入は進んでいるものの明確な基準はない
  5. エージェントネイティブ決済の潜在力: 高速・低コスト・常時稼働・プログラマブルなステーブルコインが有力な解決策で、x402は出発点ではあるが、まだ成熟段階ではない
• 次の段階のエージェンティック決済環境は、プロトコル同士の組み合わせとレイヤー間の機能継承を通じて形成される可能性が高い
• リソースを自ら発見し、条件を交渉し、対価を支払うソフトウェアへの移行は、どの標準が生き残るにせよ、すでに進行中