この記事のポイント
- AP2はGoogleが60社超と共同開発した、AIエージェント決済のためのオープン認可プロトコルである
- 暗号署名された3種類のMandate(Cart・Intent・Payment)により、エージェント取引の認可・真正性・説明責任を担保する
- AP2は決済手段に依存しない設計で、A2AやMCPの拡張として既存のエージェントインフラと統合できる
AP2(Agent Payments Protocol)が解決する3つの問い
2025年9月、GoogleはGoogle Cloud BlogでAP2(Agent Payments Protocol)を発表しました。Mastercard、PayPal、American Express、Adyen、Coinbaseなど60社超がパートナーとして名を連ねています。
では、なぜ今「エージェント決済専用のプロトコル」が必要なのか。既存の決済インフラは、画面の向こうに人間がいることを前提に設計されています。3Dセキュア認証もSMS確認コードも、最終的には「人間がボタンを押す」ことで成立する仕組みです。ところがAIエージェントが自律的に購入を実行する場面では、このモデルが根本から崩れます。
AP2が直接向き合っているのは、エージェンティックコマースが避けて通れない3つの問いです。第一に認可(Authorization)。ユーザーがエージェントに特定の購入権限を与えたことを、どう証明するか。第二に真正性(Authenticity)。エージェントのリクエストがユーザーの本当の意図を反映していると、マーチャントはどう確認するか。第三に説明責任(Accountability)。不正取引やエラーが起きたとき、誰が責任を負うのか。
この3つの問いに対して、AP2はVerifiable Digital Credentials(VDC)と呼ばれる暗号署名されたデジタル証明書を軸に、決定論的な信頼モデルを構築しています。推論ベースではなく、暗号学的に検証可能な証拠に基づく仕組みです。
Mandateの仕組み — AP2の技術的核心
AP2を理解する上で最も重要な概念がMandateです。Mandateとは改ざん不可能で暗号署名されたデジタル契約であり、ユーザーの指示内容を検証可能な形で記録します。AP2には3種類のMandateがあり、それぞれ異なる場面で機能します。
| Mandate種別 | 用途 | 署名者 | ユースケース |
|---|---|---|---|
| Cart Mandate | 特定カートの最終承認 | ユーザーのデバイスキー | リアルタイム購入(ユーザー在席) |
| Intent Mandate | 事前条件付き購入権限 | ユーザーのデバイスキー | 委任購入(ユーザー不在) |
| Payment Mandate | 決済ネットワークへのAIエージェント取引通知 | ユーザーのデバイスキー | イシュアー/ネットワークのリスク判定 |
Cart Mandate — リアルタイム購入の承認
「白いランニングシューズを探して」とエージェントに依頼し、エージェントが候補を見つけてカートを構成したとします。この時点でマーチャント側がカート内容(商品、価格、配送先)に暗号署名を付与し、ユーザーのデバイスがそれを承認して署名を追加します。これがCart Mandateです。
Cart Mandateには商品明細、合計金額、通貨、配送条件、返品ポリシーが含まれ、ユーザーのハードウェアキーで署名されます。W3C Payment Request APIの構造に準拠しており、既存のWeb決済インフラとの互換性も確保されています。ユーザーが「在席」している、つまりリアルタイムで承認操作を行うシナリオで使われます。
Intent Mandate — 委任型購入の事前承認
一方、「ビヨンセのニューヨーク公演が発表されたら、200ドル以下のチケットを2枚買って」という依頼はどうでしょう。ユーザーが寝ている間にチケットが発売される可能性があり、リアルタイムの承認を求めるわけにはいきません。
ここで機能するのがIntent Mandateです。商品カテゴリ、価格上限、有効期限(TTL)、判断基準といったパラメータを事前に定義し、ユーザーが署名します。エージェントはこの範囲内で自律的にCart Mandateを生成し、購入を完了できます。Intent Mandateにはエージェントが理解したユーザーの指示内容を再現する「プロンプト・プレイバック」も含まれており、後から「エージェントが何を理解していたか」を検証できる設計です。
エージェンティック決済において最大のリスクは、エージェントの暴走です。OpenAIのショッピングエージェントが卵1ダースに31ドルを支払ったケースは広く知られていますが、Intent Mandateの価格上限や有効期限が設定されていれば、こうした事態は構造的に防止できます。
Payment Mandate — 決済ネットワークへの信号
3つ目のPayment Mandateは、Cart MandateやIntent Mandateとは異なる役割を持ちます。これは決済ネットワークやイシュアー(カード発行会社)に対して「この取引はAIエージェントが開始した」ことを伝えるための信号です。取引がヒューマンプレゼント(ユーザー在席)かヒューマンノットプレゼント(ユーザー不在)かを示すモダリティフラグ、紛争発生時にCart/Intent Mandateを参照するためのエビデンスリンクが含まれます。
イシュアーやネットワークはこの情報をリスク判定に活用します。従来のCNP(Card Not Present)取引とエージェント経由の取引を区別できるようになることで、不正検知の精度向上と、正当なエージェント取引の承認率向上の両立が期待されます。
決済フローの全体像 — 7つのステップ
実際の決済はどのように流れるのか。AP2の技術仕様が定義する、ヒューマンプレゼント型(ユーザー在席)の7ステップを見てみます。
まずユーザーがショッピングエージェントに購入を依頼し、エージェントがIntent Mandateの署名を取得します(ステップ1)。次にエージェントがマーチャントエンドポイントを発見し、カートを交渉・構成します(ステップ2)。マーチャントがカート内容を確定し、Cart Mandateに署名して履行コミットメントを示します(ステップ3)。
ここからが決済固有のフローです。クレデンシャルプロバイダ(決済手段の管理者)がトークン化された決済オプションを提供し(ステップ4)、ユーザーのデバイスが信頼されたサーフェス上でCart MandateとPayment Mandateに署名します(ステップ5)。エージェントがMandateを提出し、クレデンシャルプロバイダとマーチャントが決済を処理します(ステップ6)。最後にPayment Mandateのシグナルを含む取引パケットがネットワーク/イシュアーに到達し、認可が行われます(ステップ7)。
注目すべきは、エージェントが生の決済情報に一切アクセスしない点です。カード番号やCVVはトークン化されたクレデンシャルとしてのみ扱われ、エージェントには決済の「実行権」はあっても「閲覧権」はありません。
他のエージェント決済プロトコルとの位置づけ
AP2は「認可フレームワーク」であり、決済の実行レイヤーそのものではありません。この区別が、競合プロトコルとの関係を理解する鍵になります。
| プロトコル | 開発元 | レイヤー | 対応決済 | 主なユースケース |
|---|---|---|---|---|
| AP2 | Google + 60社超 | 認可フレームワーク | カード・銀行振込・ステーブルコイン | 監査可能なエージェント決済 |
| ACP | OpenAI + Stripe | チェックアウト統合 | 法定通貨(カード・銀行振込) | ショッピングエージェントの購入 |
| MPP | Stripe + Tempo | セッションベースストリーミング | ステーブルコイン + 法定通貨 | リアルタイムマイクロペイメント |
| x402 | Coinbase | 決済実行 | ステーブルコインのみ | M2Mマイクロペイメント |
Stripeが2026年3月に発表したMPP(Machine Payments Protocol)は、セッションベースのストリーミング決済に特化しています。エージェントが事前に支出上限を設定し、ステーブルコインと法定通貨をリアルタイムで流し続けるモデルで、APIコールやデータフィード課金といった継続的なマイクロペイメントに向いています。一方、Coinbaseのx402はHTTPの402ステータスコードを復活させ、ステーブルコインによる即時決済をプロトコルレベルで実現するアプローチです。
では、これらは競合するのか。Crossmintの比較分析が指摘するように、本番環境では4つのプロトコルの要素が組み合わさって機能する可能性が高いとされます。AP2が認可レイヤーを提供し、x402やMPPが実行レイヤーを担い、UCPが商品発見からカート構成までの商取引フローを標準化する。レイヤーが異なるため、補完関係として共存する構図です。
エコシステムの広がり — Revolutの事例
プロトコルの仕様だけでは実際の商取引は動きません。AP2が注目される理由の一つは、発表から4か月で具体的な実装パートナーが動き始めていることです。
2026年1月、Revolut Payが英国およびEEA(欧州経済領域)でAP2対応を発表しました。RevolutはAP2のオープンプロトコルに直接貢献し、口座間(Account-to-Account)決済向けにフローを適合させています。これにより、カードだけでなく銀行口座からの直接引き落としでもAP2のMandate構造が機能することが実証されつつあります。
American ExpressのLuke Gebbは「AI駆動のコマースが拡大するにつれ、信頼と説明責任はこれまで以上に重要になる」と述べています。60社超というパートナー数は、単なる数の問題ではありません。カードネットワーク(Mastercard、American Express、JCB、UnionPay)、決済プロセッサー(Adyen、Worldpay)、コマースプラットフォーム(Salesforce、Shopify、Etsy)、暗号資産(Coinbase、MetaMask、Ethereum Foundation)という、決済エコシステムのほぼ全レイヤーをカバーしている点が重要です。
EC事業者が今知っておくべきこと
AP2は現時点で消費者が直接利用できる段階にはありません。GitHubリポジトリではv0.1.0がリリースされており、PythonとAndroidのサンプル実装が公開されていますが、本番環境での商用利用はこれからです。
とはいえ、EC事業者が準備を始めるタイミングとしては早すぎることはありません。Everest Groupの分析が指摘するように、AP2の統合にはレガシーERP・調達システムとの接続、PCI-DSSやデータレジデンシー規制への対応、エージェント取引エラー時の責任フレームワーク構築といった課題が残っています。
最も現実的な第一歩は、自社の決済サービスプロバイダー(PSP)がAP2ロードマップを持っているかを確認することです。Adyen、Worldpay、Revolutといった主要PSPは既にパートナーとして参画しており、PSP側のAP2対応が進めば、マーチャント側の統合負荷は大幅に軽減される見込みです。MCP・A2A・UCPとの関係を含めたプロトコル全体像を把握した上で、段階的な対応計画を立てることを推奨します。
まとめ
AP2は「AIエージェントが決済を実行する時代」に向けた認可の標準化を目指すプロトコルです。決済手段を選ばず、A2AやMCPの拡張として機能する設計は、エージェンティックコマースのインフラ層に不可欠なピースになり得ます。商用実装はまだ先ですが、60社超のエコシステムが示す方向性は明確です。




