「この靴を買っておいて。予算は1万5千円以内で。」
もしあなたがAIエージェントにこう指示したとき、実際にクレジットカードが切られるまでの間に、何が保証されるべきだろうか。
エージェントが見つけた靴は、あなたが望んだものと本当に一致しているのか。途中で価格が変わっていないか。配送先は正しいか。そもそも、あなたがこの購入を「承認した」という事実を、誰がどう証明するのか。エージェントのハルシネーションで的外れな商品を買ってしまった場合、責任は誰にあるのか。あなたか、エージェントの開発元か、店舗か、カード会社か。
これらの問いに答えるプロトコルが、2025年9月にGoogleが60以上の組織と共同で発表したAgent Payments Protocol（AP2）だ。
当ブログではA2Aシリーズ第3回でAP2の概要に触れた。しかしあの記事の時点では、AP2はプロトコルスタックの1要素として紹介するに留まっていた。あれから状況は急速に動いた。2026年4月にはA2Aプロトコルが150以上の組織に支持され、AP2はその決済拡張として本格的な採用フェーズに入りつつある。Visa、Mastercard、American Expressといったクレカ各社も独自のエージェント決済プロトコルを打ち出し、プロトコル群は「乱立」と「収斂」の両面を見せている。
この連載では3回にわたって、AP2を中心としたエージェント決済の全体像を解剖する。第1回の本記事ではAP2の仕組みを深掘りし、第2回ではクレカ各社のプロトコル戦略と収斂のメカニズムを、第3回ではNLWeb・WebMCP・UCP・AP2が織りなすプロトコルスタックの完全な見取り図を描く。
「クリックして購入」の前提が崩壊する
過去20年間、オンライン決済システムは1つの暗黙の前提の上に設計されてきた。「人間が、信頼されたWebサイト上で、自ら"購入"ボタンをクリックする」ということだ。
3Dセキュア、カード番号のトークン化、不正検知AIといった決済セキュリティの進化は、すべてこの前提を起点にしている。人間が存在し、ブラウザを操作し、最終的な意思決定を行っているという暗黙の合意があるからこそ、成立するセキュリティモデルだ。
AIエージェントがこの行為を代行した瞬間、3つの根本的な問いが発生する。
認可（Authorization）。 ユーザーがエージェントに「この特定の購入」を許可した事実を、どう証明するか。従来のOAuthやセッションベースの認証は、同期的な人間の存在を前提にしている。エージェントが深夜にチケットを自動購入する場面では、この前提は成り立たない。
真正性（Authenticity）。 マーチャントは、エージェントのリクエストがユーザーの真の意図を正確に反映していることを、どう確認するか。LLMにはハルシネーションのリスクがある。「赤い靴」と指示されて「青い靴」を買ってくるかもしれない。エージェントの出力は確率的であり、従来の決定論的なAPIコールとは本質的に異なる。
責任の所在（Accountability）。 不正取引や誤注文が発生した場合、誰が責任を負うのか。ユーザーか、エージェントの開発者か、マーチャントか、カード発行会社か。AP2の公式仕様はこの点について、「決済エコシステムがエージェントコマースを受け入れるためには、取引の説明責任に曖昧さがあってはならない」と明記している。
AP2は、この3つの問いに対して暗号学的な証明で回答するプロトコルだ。推論や信頼ではなく、数学で解決する。
AP2の核心 ― マンデートという「デジタル委任状」
AP2の中核的イノベーションは「マンデート」と呼ばれる仕組みにある。マンデートとは、暗号署名された改ざん不能なデジタル契約だ。AP2の公式ドキュメントでは「Verifiable Digital Credentials（VDC）」と呼ばれ、エージェント間で信頼を構築するための「共通言語」と位置づけられている。W3CのVerifiable Credentials（VC）と名称が似ているが、AP2ではVDCという独自の表記が使われており、改ざん防止性・否認不能性・可搬性を備えた暗号署名済みデジタルオブジェクトとして定義されている。
マンデートには3つの種類がある。それぞれの役割を、先ほどの「靴を買う」シナリオで見てみよう。
Intent Mandate ― 「この範囲で探してくれ」
あなたが「1万5千円以内のランニングシューズを探して、良いのがあれば買って」とエージェントに指示する。このとき生成されるのがIntent Mandateだ。
Intent Mandateには、商品カテゴリ、予算上限、タイミングの制約、エージェントが自然言語の指示をどう解釈したかの記録、そして有効期限（TTL）が含まれる。ユーザーがこれに暗号署名することで、「この条件の範囲内でエージェントが行動する権限を与えた」という否認不能な証拠が生まれる。
特にこのマンデートが威力を発揮するのは、ユーザーが不在のとき（Human Not Presentシナリオ）だ。「コンサートチケットの発売開始と同時に購入して」という委任は、ユーザーが寝ている深夜に実行されるかもしれない。Intent Mandateが事前に署名されていれば、エージェントはその範囲内で自律的に行動できる。
Cart Mandate ― 「これを、この値段で買う」
エージェントが候補を見つけ、ユーザーに提示する。ユーザーが「この1足にする」と承認したとき生成されるのがCart Mandateだ。
ここで重要なのは署名の順序だ。まずマーチャントがカート内容に暗号署名する。これは「この商品を、この価格で、確実に履行します」というマーチャント側の約束だ。次にユーザーのデバイス鍵でユーザーが署名する。これは「この内容で購入を承認しました」という否認不能な記録になる。
Cart Mandateに含まれるのは、確定した商品と価格、支払者・受取者の検証可能なID、トークン化された決済手段、配送先情報、リスク関連シグナルだ。「ユーザーが見た内容」と「実際に決済される内容」が暗号学的に同一であることが保証される。
Payment Mandate ― 「AIが関与しています」
3つ目のPayment Mandateは、決済ネットワーク（Visa、Mastercardなど）とカード発行会社に向けたシグナルだ。
このマンデートの目的は、取引にAIエージェントが関与していること、そしてユーザーが取引時点で立ち会っているか否か（Human Present / Not Present）を明示的に通知することだ。決済ネットワークはこの情報を使って、リスク評価モデルを調整できる。
ここが従来の決済との重要な違いだ。従来のオンライン決済では、「人間がブラウザで操作している」ことが暗黙の前提だった。AP2では「AIエージェントが操作しており、人間はこの時点で立ち会っている/いない」という情報が明示的に伝達される。決済ネットワーク側にとって、不正検知の精度を維持するために不可欠な情報だ。
この3つのマンデートが連鎖することで、Intent → Cart → Paymentという否認不能な監査証跡（Non-repudiable Audit Trail）が形成される。認可（誰が許可したか）、真正性（何を承認したか）、責任の所在（証拠はどこにあるか）のすべてに回答する構造だ。
誰も「全部」を見ない ― ロールベースアーキテクチャ
AP2のもう1つの設計上の重要な原則が、関心の分離だ。1つのエンティティが決済の全情報にアクセスすることを、構造的に防いでいる。
AP2の仕様は6つのロールを定義している。
ユーザー。購入意図と資金の源泉。最終的な権限者だ。
Shopping Agent（SA）。ユーザーの指示を受けて商品を検索し、カートを構築するAIエージェント。GeminiやChatGPTがこの役割を担う。ここで決定的に重要なのは、Shopping Agentはユーザーのクレジットカード番号やPCI情報に一切アクセスできないことだ。商品を探して提案することが仕事であり、決済情報の取り扱いは構造的に排除されている。
Credentials Provider（CP）。ユーザーの決済手段を安全に管理する専門エンティティだ。デジタルウォレットがこの役割を担う。マンデートの検証後にのみ、決済トークンを発行する。
Merchant Endpoint（ME）。マーチャント側のエージェントだ。商品情報の提示、カートの構築、Cart Mandateへの暗号署名を行う。
Merchant Payment Processor（MPP）。決済認可メッセージを構築し、決済ネットワークに送信するエンティティ。StripeやAdyenがこの役割を担う。
Network & Issuer。Visa/Mastercardなどの決済ネットワークと、カードを発行した金融機関。最終的な不正検知と資金移動を実行する。
この分離が意味するのは、Shopping Agentが乗っ取られたとしても、ユーザーの決済情報は漏洩しないということだ。Shopping Agentの仕事は商品を見つけてカートを提案することだけであり、実際の決済プロセスにはCredentials Providerしかアクセスできない。これは「関心の分離」という設計原則が、セキュリティモデルとして直接機能している例だ。
リアルタイムの買い物 ― Human Presentフロー
AP2がカバーする2つのシナリオのうち、まずHuman Present（ユーザーがリアルタイムで参加する）フローの全体像を追ってみよう。
ユーザーがGeminiに「白いランニングシューズを探して」と指示するところから始まる。
① Shopping Agentがこの指示を受け取り、Intent Mandateとしてユーザーの意図を記録する。
② Shopping AgentがMerchant Endpointに商品検索リクエストを送る。ここがA2Aシリーズ第3回で解説したUCPやACPの領域だ。
③ Merchant Endpointが候補商品リストを返す。リアルタイムの在庫状況と正確な価格が含まれる。Instant Checkoutが失敗した原因の1つが、スクレイピングによる古い情報の表示だった。AP2/UCP構成では、マーチャント自身のエージェントが自社システムをリアルタイムに照会して回答する。
④ Shopping AgentがCredentials Providerに問い合わせ、ユーザーの利用可能な決済手段を確認する。マーチャントが受け入れる決済手段との互換性もここで検証される。
⑤ Shopping Agentがユーザーにカートを提示する。ユーザーが「これにする」と承認すると、ユーザーのデバイス鍵でCart Mandateが暗号署名される。
⑥ 署名済みのCart MandateとPayment Mandateが、Credentials Provider経由で決済トークンとともにMerchant Endpointに送られ、取引が実行される。
⑦ 必要に応じて、既存の3DS2やOTPなどのチャレンジが発動する。AP2は既存の認証メカニズムを破壊しない。その上に信頼層を追加する拡張プロトコルだ。
⑧ 取引完了。全ステップの暗号署名が監査証跡として保存される。
以下のシーケンス図は、この8ステップにおける各ロール間のやり取りを時系列で示したものだ。Shopping Agentがすべての通信を仲介しつつも、決済情報には一切触れない構造が見て取れる。
このフロー全体を通じて、Shopping Agentはユーザーのカード番号を一度も見ていない。マーチャントは、ユーザーが確かにこの内容を承認したことを暗号学的に検証できる。決済ネットワークは、AIエージェントが関与していることを認識した上でリスク評価を行える。
「留守中に買っておいて」― Human Not Presentフロー
もう1つのシナリオは、委任型の購入だ。ユーザーが事前に条件を指定し、エージェントが自律的に実行する。
「来月のBeyoncéの東京公演、チケットが発売されたら2枚買っておいて。1枚2万円以内、隣同士の席で。」
この場合、ユーザーは発売開始の瞬間に立ち会っているとは限らない。従来の決済モデルでは、こうした委任型の購入に対して明確な認可メカニズムが存在しなかった。
AP2のHuman Not Presentフローでは、ユーザーがIntent Mandateに事前署名する。このマンデートには、商品カテゴリ（コンサートチケット）、価格上限（2万円/枚）、追加条件（隣同士の席）、有効期限が暗号署名で記録される。
エージェントは発売開始を監視し、条件を満たすチケットが出現したらCart Mandateを自動生成して購入を実行する。このとき、Cart Mandateの内容がIntent Mandateの制約範囲内であることが暗号学的に検証される。もし予算を超えるチケットしかなければ、エージェントは購入を実行できない。
この「Intent → Cart → Payment」の暗号チェーンが、「エージェントが勝手に買った」と「ユーザーが確かに委任した」を明確に区別する。紛争が発生した場合、マーチャントはCart Mandateを証拠として提出でき、ユーザーはIntent Mandateで「自分はこの範囲でしか委任していない」と主張できる。
何かが起きたとき ― マンデートが証明する責任の所在
AP2のマンデートは、平時の取引を安全にするだけでなく、紛争時の責任分界をも構造化する。AP2の仕様は、典型的な障害シナリオごとに、どの証拠が責任を判定するかを定義している。
以下は、マンデートの監査証跡がどのように責任判定に使われるかを示すフローだ。
たとえば、ユーザーが「この商品は注文していない」と主張した場合、マーチャントはユーザー署名済みのCart Mandateを証拠として提出できる。逆に、エージェントがIntent Mandateの予算上限を超える商品を購入してしまった場合、Intent Mandateの制約とCart Mandateの内容を比較することで、エージェント開発者側の責任であることが明らかになる。
この構造は、現行のチャージバック紛争解決プロセスを置き換えるものではなく、そこに追加の暗号学的証拠を提供するものだ。決済ネットワーク各社が独自の責任ルールを定義することは変わらないが、AP2のマンデートがその判定材料を格段に明確にする。
決済レールの選択 ― カードかステーブルコインか
AP2自体は「決済レール非依存」（Payment-Agnostic）に設計されている。AP2の仕様によれば、マーチャント側が受け入れる決済手段と関連手数料を定義し、ユーザーの決済手段との互換性をShopping AgentとCredentials Providerが交渉する。AP2プロトコル自体が手数料を課すことはない。
では、どの決済レールが使われるのか。現時点では3つの選択肢がある。
クレジットカード/デビットカード。 V0.1で対応済み。手数料は従来と同じ（約2.9% + $0.30）、決済完了までT+2日。ECサイトでの通常の商品購入はこのレールが中心になる。
リアルタイム送金。 V1.xで対応予定。インドのUPI、ブラジルのPIXのような即時送金。手数料構造は地域に依存する。
ステーブルコイン（x402拡張）。 Coinbase、Ethereum Foundation、MetaMaskとの協業で開発されたA2A x402拡張により、USDC等のステーブルコインでの即時決済に対応する。手数料はほぼゼロ、決済完了まで2〜5秒。ただし、主な用途はAPIコール課金やデータアクセスなどのマイクロペイメントであり、消費者向けEC決済の主流になるのはまだ先だ。2026年3月時点でのx402の実際の日次取引量は約$28,000であり、大部分がテスト的な取引だとするオンチェーン分析もある。
ユーザーへの請求構造は、従来のECと変わらない。Cart Mandateに確定金額が暗号署名されるため、「ユーザーが見た金額 ＝ 支払う金額」だ。決済手数料はマーチャント側の負担構造であり、商品価格への内包か別途表示かはマーチャントの裁量という、現行のEC決済と同じモデルが維持される。
「従来の決済の上に載る」ということ
AP2を理解する上で最も重要なポイントは、AP2は既存の決済インフラを置き換えるものではないということだ。
AP2の実装ガイドではこう解説されている。AP2の実装は、既存のチェックアウトプロセスに「高度に安全なデジタル公証サービス」を追加するようなもの、と。公証人（AP2）が購入者のエージェントのIDと権限を検証し、注文内容を認証する。認証が済むと、取引は既存の配送サービス（StripeやWorldpayなどの決済プロセッサ）に引き渡される。
つまり、既存の決済ゲートウェイ、不正検知システム、3DS2認証フローはそのまま機能し続ける。AP2はそれらに対して、「この取引にはAIエージェントが関与している」「ユーザーの認可は暗号署名で証明されている」という追加の信頼コンテキストを提供するに過ぎない。
AP2の仕様も、「既存のリスク/不正処理システムへの変更は一切必要なく、決済ネットワーク、発行会社、マーチャントがリスクをより適切に評価・管理するための追加シグナルとデータポイントを提供する」と明記している。
この「既存の上に載る」という設計思想が、AP2の採用障壁を大幅に下げている。
今、あなたのサイトに必要なこと
「AP2の仕組みはわかった。で、うちのサイトは何をすればいいのか？」
直感に反するかもしれないが、答えは「AP2自体への対応」ではない。
AP2のMerchant Endpoint構築やマンデート検証ロジックの実装は、多くの企業にとってまだ時期尚早だ。AP2は仕様としては確定しているが、大規模な商用実装は初期段階にある。StripeやAdyenなどのPSP（Payment Service Provider）がミドルウェアとしてマンデート処理を吸収し、マーチャント側のAPI統合を最小限にする方向に進んでいる。
今すぐ着手すべきは、AP2の前提条件を整えることだ。
AP2を含むすべてのエージェントコマースプロトコル ― UCP、ACP、A2A ― は、マーチャントのWebサイトが機械可読な構造化データを公開していることを前提にしている。Schema.orgのProduct、Offer、availability、returnPolicyのマークアップ。llms.txtによるAIエージェント向けのサイト案内。MCPサーバーとしてのツール公開。
エージェントに「発見」されなければ、マンデート署名以前の問題だ。
この「発見可能性」の基盤整備が、AP2時代の最優先アクションである。当ブログのNLWeb連載とWebMCP連載で解説した技術が、まさにこの基盤にあたる。
次回予告 ― 6つのプロトコルが同時に動き出した
AP2はGoogleが主導するオープンプロトコルだ。しかし、決済の世界ではGoogleだけがプレイヤーではない。
Visaは「Trusted Agent Protocol（TAP）」で、エージェントの身元を暗号署名で証明する仕組みを打ち出した。MastercardはGoogleとの共同開発で「Agent Pay」と「Verifiable Intent」を発表した。Verifiable IntentはAP2およびUCPと互換性を持つように設計されたオープンなプロトコル非依存の信頼層であり、ユーザーの認可を暗号学的に記録・証明する役割を担う。AP2が決済フローの安全な実行を担うのに対し、Verifiable Intentはその認可記録の真正性を補強する関係にある。OpenAIとStripeのACP、GoogleのUCP、CoinbaseのMPP。2026年第1四半期だけで、6つ以上のプロトコルが同時に動き出している。
乱立か、収斂か。マーチャントはどう構えればいいのか。第2回で掘り下げる。
この記事はシリーズ「AIエージェントに財布を渡せますか」の第1回です。
参考情報
Announcing Agent Payments Protocol (AP2) — Google Cloud Blog（2025年9月16日）
AP2 — Agent Payments Protocol Documentation — 公式ドキュメント
AP2 Specification — 公式仕様書
Core Concepts — AP2コアコンセプト
AP2 GitHub Repository — リファレンス実装
AP2 Roadmap — ロードマップ（V0.1 → V1.x）
Google launches new protocol for agent-driven purchases — TechCrunch（2025年9月16日）
Google's new Agent Payments Protocol (AP2) allows AI agents to complete purchases — VentureBeat（2025年12月22日）
Google's AP2: A new protocol for AI agent payments — Vellum AI（2025年12月3日）
Agent Payment Protocol (AP2) Complete Guide — PixelPlex（2025年11月24日）
Secure Use of the Agent Payments Protocol (AP2) — Cloud Security Alliance（2025年10月6日）
A2A Protocol Surpasses 150 Organizations — プレスリリース（2026年4月9日）
Agentic Payments Explained: ACP, AP2, and x402 — Orium（2025年9月29日）
Coinbase-backed AI payments protocol wants to fix micropayment but demand is just not there yet — CoinDesk（2026年3月11日）
Google Agentic Payments Protocol + x402: Agents Can Now Actually Pay Each Other — Coinbase（2025年9月15日）
Trusted Agent Protocol — Visa Developer Center（TAP仕様・サンプル実装）
How Verifiable Intent builds trust in agentic AI commerce — Mastercard（2026年3月5日）
Mastercard Unveils Open Standard to Verify AI Agent Transactions — PYMNTS（2026年3月6日）
Verifiable Intent — Open-source specification and reference implementation — Mastercard / GitHub
この記事をシェアする
