見出し画像

第6回【2026年7月追補】AP2 / ACP / UCP / x402 / MPP——AIエージェント決済を「4層＋決済レール」で理解する

Meridian House

エージェンティックコマースを調べ始めると、AP2、ACP、UCP、x402、MPP、MCP、A2Aなど、似た名前のプロトコルが次々と登場します。

最初に結論を述べると、これらはすべてが同じ市場を奪い合う競合規格ではありません。

それぞれが、次の異なる問いに答えています。

  • エージェント同士は、どう通信するのか

  • 商品、カート、注文を、どう表現するのか

  • AIに誰が、何を、どこまで許可したのか

  • 支払い要求と支払い証明を、どう受け渡すのか

  • 最後に、どの通貨・決済手段で価値を移すのか

ただし、すべてが完全に分業されているわけでもありません。

UCPとACPは商取引のオーケストレーション、x402とMPPはHTTPを使った機械決済という領域で、一部の機能が重なっています。

したがって、現在のエージェント決済は、**「4層＋決済レール」**として理解するのが適切です。

全体の見取り図

おおまかには、次の構造になります。

重要なのは、AP2やUCPが、それ自体でお金を動かすわけではないということです。

これらは、エージェントが商取引を行うための「言語」「権限」「証拠」を標準化します。実際の資金移動は、その下にあるカードネットワーク、銀行口座、ステーブルコイン、将来のトークン化預金などが担います。

第1層：通信・接続——MCPとA2A

MCP（Model Context Protocol）は、AIエージェントが外部のデータ、API、業務ツールなどを利用するための接続方式です。

A2A（Agent2Agent Protocol）は、異なるAIエージェント同士が、能力を確認し、仕事を依頼し、結果を受け渡すための通信方式です。

例えば、旅行予約エージェントが、航空会社エージェント、ホテルエージェント、決済エージェントと会話する場面を考えると分かりやすいでしょう。

ただし、MCPやA2Aは、原則として「何を買うのか」「誰が支払いを許可したのか」「どの資金で決済するのか」までは定義しません。

あくまで、他のプロトコルを運ぶための通信基盤です。

第2層：商取引——UCPとACP

UCP：商取引全体の共通言語

UCP（Universal Commerce Protocol）は、Google、Shopifyなどが中心となって策定している、エージェントコマースの共通規格です。

対象は商品検索やカートだけではありません。

  • 商品・サービスの検索

  • 商品情報の取得

  • カートの作成・更新

  • 顧客情報の連携

  • チェックアウト

  • 注文確定

  • 配送状況の更新

  • 返品・返金などの購入後処理

まで、商取引のライフサイクル全体を扱います。UCPはREST、MCP、A2Aなど複数の通信方式に対応し、AP2による安全な支払い認証も組み込める設計です。

事業者やエージェントは、UCPプロファイルを通じて、自分が対応している機能や決済方法を公開します。

これによりAIエージェントは、

「この店舗は商品検索に対応しているか」
「カートを作れるか」
「エージェント内で決済まで完了できるか」

を機械的に確認できます。

ShopifyのUniversal Cartも、複数の販売者の商品を一つのカートで管理する機能をUCP経由で提供する構想です。

ACP：ChatGPTと販売者をつなぐ商取引規格

ACP（Agentic Commerce Protocol）は、OpenAIとStripeが共同開発した、AIプラットフォームと販売者の間で商取引を実行するための規格です。

ChatGPTのInstant Checkoutでは、ACPを使って商品情報、配送情報、注文内容などを販売者のシステムへ渡します。

販売者は引き続きMerchant of Record、すなわち販売主体として、決済、配送、返品、顧客対応を管理します。ChatGPTが販売者や決済事業者になるわけではありません。

ACPにはDelegated Payment Specという決済情報の受け渡し仕様もあります。

StripeのShared Payment Token（SPT）は、その最初の実装です。SPTは、特定の販売者、金額、有効期限などに利用範囲を限定した使い捨ての決済トークンです。

カード番号そのものをAIエージェントへ渡さず、限定された支払い権限だけを受け渡します。

UCPとACPは競合なのか

両者は商取引の共通言語という点で重なります。

ただし、現時点では次のように整理できます。

  • UCP：幅広いAIプラットフォーム、販売者、業種を対象とする汎用的な商取引規格

  • ACP：ChatGPTを中心とした商品情報・チェックアウト・注文連携の実装規格

将来は相互接続、機能の収れん、役割分担のいずれも考えられます。

したがって、「まったく別物」でも「完全な競合」でもありません。

第3層：権限と証拠——AP2

AP2（Agent Payments Protocol）が解決するのは、次の問題です。

このAIエージェントは、本当に本人から、この取引を行う権限を与えられているのか。

従来のオンライン決済は、人間が画面を見て「購入」ボタンを押すことを前提としていました。

しかし、自律型エージェントでは、人間がその場にいないまま、価格や在庫などの条件が成立した時点で購入が実行される可能性があります。

そこでAP2は、Mandateと呼ばれる暗号学的に検証可能な権限情報を利用します。

Googleが2025年に発表した当初の説明では、

  • Intent Mandate：何を探し、どの条件で購入してよいか

  • Cart Mandate：どの商品を、いくらで買うか

  • 支払い情報との結び付け

という「意図→カート→支払い」の流れで説明されていました。

その後、FIDO Allianceで進められている現在の整理では、主に次の二つに再構成されています。

  • Checkout Mandate：何を、どの条件で購入するか

  • Payment Mandate：金額、決済手段、時期など、どのように支払うか

さらに、それぞれがOpenとClosedという状態を持ちます。

Openは「予算、対象、期限、利用可能な決済手段などの条件を事前に指定した状態」、Closedは「最終的な商品と金額に結び付けて承認した状態」です。

これは、AP2の仕様が現在も標準化の途上にあり、用語やデータモデルが進化していることを示しています。

AP2は、カード、リアルタイム銀行送金、ステーブルコインなど、特定の決済手段に依存しない設計です。

したがって、設計上はトークン化預金もAP2の権限管理の下に接続可能と考えられます。

ただし、AP2がトークン化預金を直接移転するわけではありません。AP2のMandateを、銀行側のウォレット、預金管理基盤、送金API、Mint／Burn処理などへ接続する実装が別途必要です。

第4層：支払い要求と決済実行——x402とMPP

x402：HTTPに支払いを組み込む

x402は、HTTPの「402 Payment Required」というステータスコードを利用し、Webサイト、API、データ、AIサービスへのアクセスと支払いを一体化するプロトコルです。

例えばAIエージェントが有料APIを呼び出すと、サーバーは価格と支払い条件を含む402レスポンスを返します。

エージェントが支払いを行い、その証明を付けて再度アクセスすると、APIの結果が返されます。

初期のx402はUSDCなどのステーブルコインによる少額・即時決済を中心としていましたが、現在は複数のネットワーク、トークン、法定通貨も視野に入れたオープン規格として開発されています。

Coinbaseが立ち上げたx402は、現在、Linux Foundationの下に置かれた独立財団による中立的な標準化へ移行しています。

AWSなども参加し、WebコンテンツやAPIをAIエージェントに有料提供する仕組みへの実装が始まっています。

MPP：法定通貨とオンチェーンの双方を扱う機械決済

MPP（Machine Payments Protocol）は、StripeとTempoが共同策定した機械間決済のオープン規格です。

MPPもHTTP 402を利用します。

AIエージェントが有料サービスを要求すると、サーバーが決済条件を返し、エージェントが支払いを承認して再度リクエストし、サービスと領収情報を受け取ります。

MPPの特徴は、当初から決済レールに依存しない設計を明確にしていることです。

  • ステーブルコインなどのオンチェーン決済

  • カード

  • ウォレット

  • 後払い

  • Shared Payment Tokenを使った法定通貨決済

などを利用できます。

少額決済だけでなく、継続課金や反復的な機械決済も想定されています。

x402とMPPの違い

x402とMPPは、今回の規格群の中で最も直接的に競合する関係です。

どちらも、

  • HTTP 402を利用する

  • 人間の画面操作を必要としない

  • APIやデジタルサービスの利用と支払いを結び付ける

  • AIエージェントによる少額・高頻度決済に対応する

という共通点があります。

現時点での大まかな違いは、次のとおりです。

  • x402：ステーブルコインとオンチェーン決済から出発し、オープンなインターネット決済標準を目指す

  • MPP：Stripeの既存決済基盤も活用し、法定通貨とオンチェーン決済の双方を扱う

ただし、Stripe自身もx402とMPPの両方に対応しています。

どちらか一方が直ちに他方を排除するというより、決済事業者やAPI提供者が複数規格を併用する期間が続くと考えられます。

一つの取引で、各プロトコルはどう使われるのか

例えば利用者がAIに、次のように依頼したとします。

東京出張に適したホテルを探し、1泊2万円以下で、会社指定カードを使って予約しておいて。

この場合、概念的には次の流れになります。

  1. MCPやA2Aを使い、旅行エージェントがホテルや予約エージェントと通信する

  2. UCPまたはACPを使い、空室、料金、宿泊条件、カート、注文情報を交換する

  3. AP2で、地域、上限金額、日程、利用可能な決済手段をMandateとして証明する

  4. x402やMPP、または既存の決済APIを通じて支払いを要求・実行する

  5. カード、銀行口座、ステーブルコインなどの決済レールで資金を移動する

このように見ると、各プロトコルの役割を区別できます。

日本の金融実務者が読むべきポイント

1．銀行の役割は、決済レールの提供だけではない

AIエージェント時代の銀行には、単なる口座や送金APIの提供に加えて、

  • 利用者本人の認証

  • エージェントへの権限委任

  • 支出上限や利用先のポリシー管理

  • Mandateの検証

  • 不正検知

  • 取消し・異議申立て

  • 監査証跡の保存

といった役割が発生します。

銀行が提供するのは「お金」だけでなく、信頼できる権限と執行の基盤になります。

2．トークン化預金にも接続余地がある

AP2は特定の決済手段に依存しないため、将来の決済レールとしてトークン化預金を接続する余地があります。

例えばPayment Mandateに、

  • 利用可能な預金口座

  • 上限金額

  • 利用可能な相手先

  • 有効期限

  • 対象となる商品・サービス

  • 自動執行の可否

などを組み込み、銀行側で検証してトークン化預金を移転する構造です。

ただし、「AP2があるからトークン化預金がそのまま利用できる」という意味ではありません。

銀行側にはAP2と預金管理、本人確認、ウォレット、オンチェーン基盤を接続する制御基盤が必要です。

3．Mandateは法令対応そのものではない

暗号学的な署名があっても、それだけで本人確認、AML/CFT、消費者保護、電子契約、代理権、チャージバックなどの問題が解決するわけではありません。

特に金融機関は、

  • 誰がエージェントを保有・管理しているのか

  • 委任された権限を誰が取り消せるのか

  • エージェントの誤作動時に誰が責任を負うのか

  • 複数エージェントを経由した場合に証拠をどう連結するのか

  • 国境を越える取引で本人確認情報をどう受け渡すのか

を、プロトコルの外側で制度・契約・業務として設計する必要があります。

「どの規格が勝つか」より重要なこと

現段階で重要なのは、特定のプロトコル名を一つ選ぶことではありません。

見るべきなのは、

  • 商取引データ

  • 権限と同意

  • エージェントの本人性

  • 支払い要求

  • 決済手段

  • 清算・決済

  • 監査と紛争処理

が、どの規格によって、どこまでカバーされるかです。

UCP、ACP、AP2、x402、MPPは、いずれも急速に更新されています。

今後は規格同士の連携だけでなく、Mandateの共通化、エージェントID、ウォレット、KYC、決済事業者の責任分界、複数プロトコル間の変換が主要な論点になります。

日本の銀行、決済事業者、IT企業に必要なのは、一つのプロトコルへ賭けることではありません。

複数の規格と既存金融インフラを接続できる、プロトコル非依存の制御・変換レイヤーを準備することです。

本連載群は個人の見解であり、所属組織を代表するものではありません。
また直近の情報をもとに構成していますが、その正確性を保証するものでありません。ご利用の際には十分ご留意ください。


いいなと思ったら応援しよう！