AP2（Agent Payments Protocol）とは？EC決済の対応と日本事業者の備え

AP2（Agent Payments Protocol）とは？EC決済の対応と日本事業者の備え

この記事の結論: AP2はGoogleが2025年9月に60社以上のパートナーと公開した、AIエージェントによる決済を安全に成立させるためのオープンプロトコルである。中核は暗号署名された3種類の「Mandate（マンデート）」で、「誰がこの購入を承認したのか」を、加盟店・決済代行・カードネットワークが後から検証できる形で標準化した点に価値がある。Salesforce・Shopify・Etsyなどがすでに導入し、PayPal・Mastercard・American Express・JCBなどが支持を表明している。日本のEC事業者は、商品データと注文APIをエージェントが読める形に整え、Mandateを検証・保管する運用体制を早期に設計しておくことが競争力を左右する。

最終更新日: 2026年7月11日

はじめに

AIエージェントが人間に代わって商品を探し、比較し、カートに入れ、決済まで実行する「エージェントコマース（Agentic Commerce）」が2026年の実用フェーズに入った。ChatGPTやGemini上で「白いランニングシューズを2万円以内で買っておいて」と頼めば、エージェントが候補を絞り込み、条件に合致した瞬間に購入を完了させる。この体験は魅力的だが、決済の現場には従来のオンライン取引にはなかった難問を持ち込む。

最大の問題は「本当にこのユーザーがこの購入を承認したのか」を、加盟店側がどう確認するかである。人間がブラウザでボタンを押す従来のフローでは、CVV入力や3Dセキュアの本人認証が本人の意思を担保していた。しかしエージェントが自律的に動くと、その「意思」の証拠が曖昧になる。誤発注が起きたとき、その責任は利用者にあるのか、エージェント提供者にあるのか、加盟店にあるのか。この責任分界の空白こそが、AIエージェントによる決済普及を阻んできた壁だった。

Googleが公開した**AP2（Agent Payments Protocol、エージェント決済プロトコル）**は、この壁を「暗号署名された委任の証拠」で乗り越えようとする試みだ。本記事では、AP2の仕組みとMandateの署名・検証フロー、対応する決済事業者、A2AやMCPといった隣接プロトコルとの関係、ACPやUCPとの違いを整理したうえで、日本のEC事業者が具体的に何を準備すべきかを掘り下げる。エージェント経由の流入をどう可視化し最適化するかという観点は、LLMO完全ガイドやAI検索最適化ガイドとあわせて読むと理解が立体的になる。

AP2とは何か：発表の背景と全体像

AP2は、Googleが2025年9月16日に発表したオープンなプロトコルである。発表時点でPayPal、Mastercard、American Express、Adyen、Coinbase、Salesforce、ServiceNow、Worldpay、JCB、UnionPay International、Etsyなど60社を超える決済・技術パートナーが名を連ねた。プロトコル仕様はap2-protocol.orgで公開され、Apache 2.0ライセンスのリファレンス実装がGitHubで配布されている。特定企業の囲い込みではなく、業界横断の共通言語を目指す姿勢がここに表れている。

AP2が解こうとしている課題を一言でまとめると、**「エージェント経済における信頼の欠落」**だ。Googleはこの信頼を3つの問いに分解して説明している。

• Authorization（承認）: このエージェントは、本当にユーザーからこの購入を任されているのか。
• Authenticity（真正性）: エージェントが提示するリクエストは、ユーザーの本当の意図を反映しているか。改ざんされていないか。
• Accountability（説明責任）: 取引に問題が起きたとき、誰が責任を負うのかを追跡できるか。

従来のカード決済ネットワークは「支払いが有効か」には答えられるが、「この購入をユーザーが承認したか」には答えられない。AP2はこの後者の問いに、検証可能なデジタル証拠で答えることを役割としている。重要なのは、AP2自体はお金を動かさないという点だ。実際の資金移動はカードネットワークやリアルタイム銀行振込、ステーブルコインといった既存レールが担う。AP2はその上に「承認の証明」というレイヤーを一枚重ねる設計になっている。

この設計思想は、決済のパイプそのものを置き換えるのではなく、パイプに流す前の「合意の記録」を標準化するという発想だ。だからこそ既存のカードブランドや決済代行が反発せず、むしろ支持側に回れている。

AP2の心臓部：3種類のMandate（マンデート）

AP2を理解する鍵は、**Mandate（マンデート、委任状）**という概念にある。Mandateとは、改ざん不能な暗号署名付きのデジタル契約であり、ユーザーの指示を検証可能な形で記録した証拠だ。AP2はこのMandateを3種類チェーン状に連結することで、意図から決済までの一連の流れを追跡可能にする。

Intent Mandate（意図マンデート）

利用者がエージェントに与える最初の委任状だ。「白いランニングシューズを2万円以内で」といった購入条件、価格上限、有効期限、対象カテゴリなどのルールを記述する。人間がその場に立ち会わない委任タスク（例：「発売と同時にコンサートチケットを買っておいて」）では、この Intent Mandate に利用者が事前署名し、エージェントが単独で動く根拠とする。いわば「エージェントに与えた行動範囲の憲法」である。

Cart Mandate（カートマンデート）

エージェントが具体的な商品を特定し、確定した価格でカートを構成した段階で生成される委任状だ。「この商品を、この価格で、この加盟店から買う」という具体的な内容が確定する。人間が立ち会うリアルタイム購入では、この Cart Mandate をユーザーが最終承認して署名する。Intent Mandate が抽象的な意図なら、Cart Mandate は具体的な合意だ。この2段構えにより、条件に合致したときだけ確定購入へ進む制御が可能になる。

Payment Mandate（決済マンデート）

カートの合意から派生し、決済ネットワークや発行会社（イシュア）が受け取る委任状だ。これは「この取引がエージェント経由であること」を決済側に伝えるシグナルを含む。発行会社が Payment Mandate を受理したあと、実際の決済は標準的なカードレールを通って処理される。支払い手段がステーブルコインの場合は、GoogleがCoinbase、Ethereum Foundation、MetaMaskと共同で策定したA2A x402拡張を通じて決済される。

この3つのMandateは、Intent → Cart → Payment という順で暗号的に鎖状に結ばれる。各Mandateは検証可能なクレデンシャル（Verifiable Credentials、VC）で署名されるため、後から改ざんすれば署名検証が失敗する。結果として「ユーザーが何を意図し、何に同意し、何を決済したか」の全履歴が、加盟店・決済代行・カードネットワークのいずれからも独立に検証できる監査証跡（audit trail）として残る。

Mandateの署名と検証フロー：取引はどう成立するか

具体的な取引の流れを、人間が立ち会うリアルタイム購入のケースで追ってみる。

1. 意図の捕捉: 利用者がエージェントに「白いランニングシューズを2万円以内で」と依頼する。エージェントはこれを Intent Mandate として記録する。委任タスク型なら、この時点でユーザーが署名する。
2. 商品探索と提示: エージェントが加盟店の商品カタログを横断的に探索し、条件に合致する候補を利用者に提示する。ここで加盟店側の商品データがエージェントに読める形で整っているかどうかが、そもそも候補に載るかを左右する。
3. カート確定: 利用者が特定の商品を選ぶと、エージェントは確定価格・在庫・配送条件を含む Cart Mandate を生成する。利用者はこのカート内容を確認し、署名して承認する。
4. 決済マンデートの派生: Cart Mandate から Payment Mandate が派生する。ここには決済手段の情報と、取引がエージェント主導であるシグナルが含まれる。
5. 決済実行: Payment Mandate が発行会社に渡り、承認されると、資金は既存のカードネットワークやリアルタイム銀行振込を通じて移動する。
6. 証跡の保管: 3つのMandateのチェーンが署名付きで保存され、後日の紛争解決や監査に使える証拠となる。

検証の仕組みで肝になるのが、各Mandateの署名を独立に確認できる点だ。加盟店は「ユーザーが確かにこのカートに署名した」ことを、エージェント提供者の主張に依存せず暗号的に確認できる。逆にエージェント提供者は「加盟店が提示した価格に対してユーザーが同意した」ことを証明できる。この相互検証性が、誤発注や不正時の責任分界を明確にする土台になる。従来の決済では取引後の突合が「言った・言わない」に陥りがちだったが、AP2では署名済みMandateが客観的な事実として機能する。

なお委任タスク型（ユーザー不在）では、Cart Mandate の生成をエージェントが自動で行う。このとき Intent Mandate に記した価格上限や条件が厳格なガードレールとなり、それを超える購入はプロトコル上成立しない。ユーザーが与えた枠の外にエージェントが踏み出せない構造になっている。

対応するEC・決済事業者：エコシステムの現在地

AP2のエコシステムは、役割の異なるプレイヤーが層状に参加しているのが特徴だ。2026年7月時点の主要な参加状況を整理する。

とりわけ日本のEC事業者にとって注目すべきは、JCBが早期から参加している点と、Shopifyが導入企業に含まれる点だ。JCBの参加は、日本国内のカード決済がAP2の枠組みに乗る道筋が制度面で開けていることを示す。Shopifyの対応は、同プラットフォームを使う国内EC事業者が、比較的低い実装コストでエージェント決済に対応できる可能性を意味する。

Salesforce、Shopify、Etsyがすでに導入済みという事実は、AP2が仕様書だけの構想段階ではなく、実際の商流に接続され始めていることを裏づける。Googleは、AP2が企業にとって課題になりやすい「信頼性・説明責任・セキュリティ」の3点を解決に導くと説明しており、この3点はまさにエンタープライズがエージェント決済導入をためらう理由そのものだった。

A2A・MCPとの関係：AP2はどこに位置するのか

AP2を正しく理解するには、隣接するプロトコルとの役割分担を押さえる必要がある。エージェント関連のプロトコルは、それぞれ担当する層が異なる。

• MCP（Model Context Protocol）: AIモデルと外部ツール・データソースを接続する層。エージェントが商品データベースや在庫APIといった「文脈」にアクセスするための規格だ。詳しくはRAGやグラウンディングの考え方とも接続する。
• A2A（Agent2Agent Protocol）: エージェント同士が対話・協調するための層。あるエージェントが別のエージェントにタスクを委譲したり、情報をやり取りしたりする通信規格である。
• AP2（Agent Payments Protocol）: 上記の上に乗る「決済の承認と信頼」の層。誰が何に同意して支払ったかを証明する。

AP2はA2Aの拡張として設計されており、A2Aの通信基盤の上で決済メッセージをやり取りする。さらにステーブルコイン決済のためのx402拡張がA2A上で動く。つまり、MCPが「エージェントに知識を与え」、A2Aが「エージェント同士をつなぎ」、AP2が「取引に法的・技術的な信頼を与える」という三層構造だ。これらは競合ではなく補完関係にあり、実運用のエージェントは複数のプロトコルを同時に使い分ける。

この構造を理解すると、EC事業者が対応すべき論点も層ごとに分解できる。MCP層では商品・在庫データをエージェントに読める形で公開し、AP2層ではMandateを検証・保管する体制を整える、という具合だ。

ACP・UCPとの違い：3つの標準の棲み分け

エージェントコマースの標準はAP2だけではない。OpenAIとStripeが主導するACP（Agentic Commerce Protocol）、そして**UCP（Universal Commerce Protocol）**が並立している。これらは競合するように見えて、実は担当領域が異なる。

要点を整理すると、ACPは「チェックアウトの流れ」を標準化し、AP2は「承認と信頼の枠組み」を標準化する。両者は排他ではなく、あるエージェントシステムが承認にAP2を、EC決済のチェックアウトにACPを、機械間の少額決済にx402やMPPを使う、という組み合わせが現実的だ。実際、業界の分析でもこれらは「競合ではなく、それぞれがエージェントコマースの異なる問題を解く補完的な部品」と評価されている。

なお、OpenAIは2026年3月上旬にChatGPT内の直接購入機能を縮小し、アプリベースのモデルへ軸足を移した。この動きはACPの立ち位置を変えつつあり、標準の勢力図はなお流動的だ。UCPとACPの詳細な違いはUCPとACPの違いとは？EC事業者が2026年に取るべき対応で個別に掘り下げているので、あわせて確認してほしい。

日本のEC事業者にとっての実務的な示唆は明快だ。どれか一つの標準に賭けるのではなく、商品データと注文フローをプロトコル非依存の形に整えることが、どの標準が主流になっても対応できる最も堅実な備えになる。

日本のEC事業者が今すべき備え

AP2は米国主導のプロトコルだが、JCBの参加やShopifyの対応により、日本のEC事業者にとっても他人事ではない。エージェント経由の購買が国内で本格化する前に、以下の準備を段階的に進めておきたい。

1. 商品データをエージェントが読める形に整える

エージェントの候補に載らなければ、AP2以前に取引が始まらない。商品名・価格・在庫・配送条件・返品ポリシーを構造化データとして明示し、JSON-LD形式でSchema.orgのProductスキーマに沿って提供する。エージェントが在庫と価格をリアルタイムに取得できるAPI整備も、候補入りの前提条件になる。この基盤はLLMOやAEO、GEOといったAI検索最適化の取り組みと地続きだ。

2. Mandateの検証・保管体制を設計する

AP2に対応するなら、受信したMandateの署名を検証し、取引ごとに3種のMandateチェーンを保管する仕組みが必要だ。これは紛争解決や監査に直結する。既存の注文管理システムに「署名付き委任状の保存フィールド」を追加する改修を、早めにベンダーと検討しておく。

3. 責任分界とチャージバック方針を再定義する

エージェント経由の誤発注や不正が起きたときの責任範囲を、社内規程と加盟店契約の両面で見直す。AP2のMandateは証拠として機能するが、それをどう運用ルールに落とすかは各社の判断だ。返品・返金のコンバージョンへの影響も試算しておきたい。

4. エージェント流入を計測できるようにする

エージェント経由のトラフィックと通常の人間経由を区別して計測しないと、施策の効果が見えない。GA4のセグメンテーションやクローラーログの分析で、GPTBotやClaudeBotなどのAIクローラーとエージェント決済の流入を可視化する。詳しい計測設計はAI検索最適化ガイドを参照してほしい。

5. 決済パートナーの対応状況を追う

自社が使う決済代行（PayPal、Adyen、Stripeなど）やカードブランド（JCB含む）がAP2にどう対応するかを、四半期ごとに確認する。プロトコルの実装は決済パートナー側が担う部分が大きいため、パートナーのロードマップが自社の対応可否を左右する。

これらは一度に全部やる必要はない。まず1と4の「エージェントに見つけてもらい、流入を測る」から着手し、取引量が見えてきた段階で2と3の「決済の信頼と責任」へ進むのが現実的な順序だ。

よくある質問

Q1. AP2とは何の略で、誰が作ったものですか？

AP2はAgent Payments Protocol（エージェント決済プロトコル）の略で、Googleが60社以上の決済・技術パートナーとともに2025年9月に公開したオープンプロトコルである。AIエージェントが人間に代わって決済を行う際に、「誰がこの購入を承認したか」を暗号署名で証明する枠組みを提供する。仕様はap2-protocol.orgで公開され、Apache 2.0ライセンスのリファレンス実装も配布されている。特定企業に閉じない業界共通規格を志向している点が特徴だ。

Q2. AP2は実際にお金を動かすのですか？

いいえ、AP2自体は資金を移動させない。AP2が標準化するのは「ユーザーが購入を承認したという証明」であり、実際の決済は既存のカードネットワーク、リアルタイム銀行振込、ステーブルコインといったレールが担う。たとえばPayment Mandateを発行会社が受理したあと、決済は標準的なカードレールを通って処理される。AP2は決済パイプそのものを置き換えるのではなく、その手前に「合意の記録」というレイヤーを一枚重ねる設計だと理解するとわかりやすい。

Q3. Mandate（マンデート）とは具体的に何ですか？

Mandateとは、改ざん不能な暗号署名付きのデジタル契約で、ユーザーの指示を検証可能な形で記録した証拠を指す。AP2はIntent Mandate（意図）、Cart Mandate（カート確定）、Payment Mandate（決済）の3種類を暗号的に鎖状に連結する。各Mandateは検証可能なクレデンシャルで署名されるため、改ざんすれば署名検証が失敗する。結果として、ユーザーが何を意図し、何に同意し、何を決済したかの全履歴が独立に検証できる監査証跡として残る仕組みになっている。

Q4. 日本のEC事業者もAP2に対応する必要がありますか？

現時点で必須ではないが、備えは始めておくべきだ。JCBがAP2に参加し、Shopifyが導入企業に含まれるため、日本市場にも波及する道筋が見えている。まず商品データを構造化データで整え、エージェントが在庫と価格を取得できるAPIを用意することが、AP2以前の前提条件になる。エージェント経由の購買が国内で本格化してから慌てるより、データ整備と流入計測から段階的に進めるのが賢明である。

Q5. AP2とACPはどちらを選ぶべきですか？

二者択一で考えないほうがよい。ACP（OpenAIとStripe主導）は加盟店とエージェント間のチェックアウトフローを標準化し、AP2は決済の承認と信頼の枠組みを標準化する。担当する層が異なるため、承認にAP2を、チェックアウトにACPを同時に使う組み合わせが現実的だ。両者は競合ではなく補完関係にある。EC事業者としては、どちらか一方に賭けるより、商品データと注文フローをプロトコル非依存の形に整えるのが最も堅実な対応になる。

Q6. ステーブルコインでの決済にはどう対応していますか？

支払い手段がステーブルコインの場合、GoogleがCoinbase、Ethereum Foundation、MetaMaskと共同で策定したA2A x402拡張を通じて決済される。x402はエージェント間の決済に特化した拡張で、V2が2025年12月に公開され、Stripeが2026年2月にBase上でx402を統合するなど実装が進んでいる。AP2はカード決済とステーブルコイン決済の両方を、同じMandateの枠組みの下で扱える設計になっている点が柔軟性の源泉だ。

Q7. AP2はMCPやA2Aと何が違うのですか？

担当する層が異なる。MCP（Model Context Protocol）はAIモデルと外部ツール・データを接続する層、A2A（Agent2Agent）はエージェント同士が対話・協調する層、AP2はその上に乗る決済の承認・信頼の層である。AP2はA2Aの拡張として設計され、A2Aの通信基盤上で決済メッセージをやり取りする。三者は競合せず、MCPが知識を与え、A2Aがエージェントをつなぎ、AP2が取引に信頼を与えるという補完的な三層構造をなしている。

Q8. エージェントが誤発注したら責任は誰にありますか？

AP2はこの責任分界を明確にするために設計されている。3種類の署名付きMandateが「ユーザーが何を承認したか」の客観的証拠として残るため、誤発注時に「言った・言わない」の水掛け論を避けられる。委任タスク型では、Intent Mandateに記した価格上限や条件がガードレールとなり、枠を超える購入はプロトコル上成立しない。ただし最終的な責任範囲は、各社の運用規程や加盟店契約でどう定めるかに依存するため、AP2導入時には社内ルールの再定義が欠かせない。

Q9. AP2に対応するとAI検索での露出は増えますか？

直接の因果ではないが、下地は共通する。AP2に対応するために商品データを構造化データで整え、在庫・価格をAPI化する作業は、AIエージェントやAI検索に商品を見つけてもらうための基盤整備そのものだ。エージェントの購入候補に載る条件と、AI検索で引用・推薦される条件は多くが重なる。したがってAP2対応の準備は、結果としてLLMOやAEOの取り組みと相乗効果を生む。露出向上を狙うなら、決済対応とAI検索最適化を切り離さず一体で設計するとよい。

関連用語

• LLMO
• AEO
• GEO
• 構造化データ
• JSON-LD
• Schema.org
• RAG
• グラウンディング
• コンバージョン

関連記事

• LLMO完全ガイド
• AI検索最適化ガイド
• UCPとACPの違いとは？EC事業者が2026年に取るべき対応
• ChatGPTショッピングとMerchant Centerで進めるAI検索対応
• Amazon RufusとRakuten AIショッピングアシスタント最適化
• GeminiとChatGPTのAIショッピング商品最適化比較
• Google Marinerの終了とGeminiエージェント時代のLLMO
• ChatGPTショッピングリサーチと商品可視性
• Mastercard Agent Pay とは｜EC事業者が今準備すべきこと【2026年】
• LLMOコンサル依頼の流れ完全ガイド｜相談から契約・初月成果まで6ステップ
• A2Aプロトコル時代にAIエージェントへ自社を発見させる準備【2026年版】