第1回でAP2のマンデート構造を、第2回で6つの決済プロトコルが4層のスタックに収斂する構造を見てきた。
しかし、決済は買い物の最終工程に過ぎない。エージェントが「白いランニングシューズを探して」と指示されてから、靴が玄関に届くまでの間には、決済の前後にもう1つの巨大なプロトコル群が動いている。
商品を発見するプロトコル。マーチャントと対話するプロトコル。カートを構築するプロトコル。注文を追跡するプロトコル。これらは当ブログのNLWeb連載、WebMCP連載、エージェンティックWebの完全スタックで個別に解説してきた。
最終回では、これらのアプリケーション層プロトコルと決済層プロトコルを1枚の地図に統合する。マーチャントのWebサイトにエージェントがアクセスし、商品を発見し、カートを構築し、決済を完了し、注文を追跡する。この一連のジャーニーを、プロトコルスタックの完全な見取り図として提示する。
2つのスタックは1つだった
当ブログでは、エージェンティックWebのプロトコル群を5層のアプリケーションスタックとして整理した。Schema.org（基盤）→ MCP/A2A（通信）→ llms.txt（案内）→ NLWeb（対話）→ WebMCP（実行）。
前回の記事では、決済プロトコル群を4層の決済スタックとして整理した。Visa TAP（認証）→ AP2/Verifiable Intent（認可）→ UCP/ACP（コマースフロー）→ カードレール/x402（決済レール）。
この2つのスタックは、実はUCPを結節点として1つに繋がっている。
UCPは「コマースフロー」のプロトコルであると同時に、AP2マンデートをdev.ucp.shopping.ap2_mandateというエクステンションとして統合している。通信レイヤーではMCPとA2Aの両方をトランスポートとしてサポートする。つまりUCPは、アプリケーション層と決済層の橋だ。
以下は、2つのスタックが統合された完全な見取り図だ。
靴を1足買う ― 10のプロトコルが動く全行程
「白いランニングシューズを探して。予算は1万5千円以内で。」
ユーザーがGeminiにこう話しかけてから、靴が玄関に届くまでの全行程を、プロトコルの発火順に追ってみよう。
フェーズ1：発見（Discovery）
ステップ1 ― llms.txt / Schema.org で「存在を知る」。
Shopping Agentがまず参照するのは、マーチャントのWebサイトが公開している機械可読な構造化データだ。llms.txtはAIエージェント向けのサイトマップとして機能し、サイトの概要、取り扱い商品カテゴリ、関連ページへのリンクを提示する。Schema.orgのProduct、Offer、availabilityマークアップは、個別の商品情報を構造化する。
ここがすべての起点だ。llms.txtもSchema.orgマークアップもないサイトは、エージェントにとって「存在しない」のと同じだ。
ステップ2 ― NLWeb で「会話する」。
llms.txtで靴を取り扱っていることを把握したAgentは、マーチャントのNLWebエンドポイント（/ask）に自然言語で問い合わせる。「白いランニングシューズで1万5千円以内のものはありますか？」。NLWebはSchema.orgの構造化データをRAG（検索拡張生成）の知識ベースとして使い、マーチャントのカタログから候補を返す。
NLWebの応答はSchema.orgのProductスキーマに準拠しているため、Agentは返ってきた商品情報をそのまま処理できる。人間向けのHTMLをスクレイピングする必要がない。当ブログのNLWeb連載で詳しく解説している。
フェーズ2：対話と選択（Interaction）
ステップ3 ― MCP / WebMCP で「深掘りする」。
候補が3足見つかった。ユーザーは「このうち、レビュー評価が一番高いのはどれ？」と追加質問する。Shopping AgentはMCP（Model Context Protocol）経由でマーチャントのMCPサーバーに接続し、レビューデータやサイズ別在庫など、NLWebの応答だけでは得られない詳細情報を取得する。
さらにWebMCPが有効なサイトであれば、Agentはブラウザ上のDOMにバインドされたツールを直接実行できる。「お気に入りに追加」「サイズを選択」「カートに入れる」といったアクションが、人間がボタンをクリックするのと同じインターフェースでプログラム的に実行可能になる。WebMCPはGoogleとMicrosoftが共同開発し、W3C Web Machine Learning Community Groupで標準化が進んでいるWeb APIだ。当ブログのWebMCP連載で詳しく解説している。
ステップ4 ― A2A で「他のエージェントと協調する」。
Shopping Agentが単独で完結しない場合もある。配送日の見積もりにロジスティクスエージェントに問い合わせたり、ユーザーの過去の購入履歴を管理するパーソナルエージェントと連携したりする。A2A（Agent2Agent）プロトコルがこのエージェント間通信を標準化する。
フェーズ3：チェックアウトと決済（Transaction）
ステップ5 ― UCP でチェックアウトセッションを開始する。
ユーザーが「この白いNikeのランニングシューズにする」と決定すると、Shopping Agentはマーチャントの/.well-known/ucpプロファイルを参照し、チェックアウトセッションを作成する。UCPのチェックアウトAPIは、カート内容、税額計算、配送オプション、利用可能な決済手段を標準化されたJSON構造で返す。
ここでUCPのケイパビリティ・ネゴシエーションが機能する。マーチャントのプロファイルがdev.ucp.shopping.ap2_mandateを宣言していれば、このセッションはAP2マンデート付きのセキュアチェックアウトに自動的にアップグレードされる。
ステップ6 ― Visa TAP でエージェントを認証する。
チェックアウトに進む前に、マーチャントはShopping Agentが正規のエージェントであることを確認する必要がある。Visa TAPの暗号署名付きHTTPヘッダが、「このエージェントはVisa認定であり、購入意図を持ってアクセスしている」ことをマーチャントに証明する。第2回で詳しく解説している。
ステップ7 ― AP2マンデートで「認可を証明する」。
第1回で詳しく解説したVDCマンデートのフローがここで発火する。マーチャントがカート内容に暗号署名（Cart Mandate）し、ユーザーがデバイス鍵で署名する。「この商品を、この価格で、この配送先に」という合意が暗号学的に固定される。
UCPとAP2の統合の具体的な流れは以下の通りだ。マーチャントがチェックアウトレスポンスにap2.merchant_authorization（マーチャント署名のJWT）を埋め込む。プラットフォーム（Gemini等）がこの署名を検証した上で、ユーザーの同意を得てCheckoutMandateとPaymentMandateの2つのVDCを生成する。プラットフォームが両方のマンデートをマーチャントの/completeエンドポイントに送信し、取引が実行される。
ステップ8 ― 決済レールで「支払う」。
AP2のPayment Mandateが決済ネットワークに送信され、実際の資金移動が実行される。クレジットカード、デビットカード、またはx402経由のステーブルコインのいずれかだ。決済ネットワークはPayment Mandateの「AIエージェントが関与している」「ユーザーはHuman Present」というシグナルを使って、リスク評価モデルを調整する。
フェーズ4：購入後（Post-Purchase）
ステップ9 ― UCP Order Managementで「追跡する」。
UCPのOrder Management機能が、注文確認、配送ステータス、追跡番号の通知をAgentに提供する。Agentはユーザーに「靴が発送されました。明後日届く予定です」と報告する。
ステップ10 ― 返品・紛争が発生したら。
もし届いた靴がサイズ違いだった場合、UCPの返品フローが起動する。AP2マンデートの監査証跡が「ユーザーは26.0cmを指定していた」「マーチャントのCart Mandateには26.0cmと記録されている」ことを証明し、責任の所在を明確にする。Mastercard Verifiable Intentがカードネットワークレベルでの紛争解決に暗号学的証拠を提供する。
UCPが「橋」である理由
なぜUCPがこのスタックの結節点になるのか。それはUCPの設計が意図的にレイヤー横断型だからだ。
UCPは3つの通信方式をサポートしている。REST API（従来型HTTP）、MCP（AIモデルとのネイティブ統合）、A2A（エージェント間通信）。マーチャントは同一のチェックアウト機能を、どの通信方式でも公開できる。
さらにUCPはケイパビリティ・ネゴシエーションの仕組みで、マーチャントとエージェントが「何ができるか」を動的に交渉する。マーチャントが/.well-known/ucpに公開するプロファイルには、対応するチェックアウト機能、注文管理機能、AP2マンデート対応状況、受け入れ可能な決済ハンドラーが宣言される。エージェントもリクエスト時に自身のプロファイルURLを渡し、両者の対応能力が交差計算（インターセクション）される。
この設計により、UCPは「上流」のアプリケーション層プロトコル（NLWeb、WebMCP、MCP）と「下流」の決済層プロトコル（AP2、TAP、Verifiable Intent）を自然に接続する。商品を見つけてカートに入れる行為と、そのカートに暗号署名して決済する行為が、1つのセッション内でシームレスに連鎖する。
マーチャントの実装ロードマップ ― 4段階で完全スタックに至る
この完全スタックを見て、「うちの会社には到底無理だ」と思った経営者もいるかもしれない。しかし、このスタックの優れた点は段階的に実装できることだ。各レイヤーは独立しており、下のレイヤーから順に積み上げれば、途中段階でも効果がある。
ステージ1：発見される（即日〜1週間）
やること。 Schema.orgのProduct・Offerマークアップ整備。llms.txtの公開。robots.txtでのAIエージェントアクセス許可。
効果。 AIエージェントの商品検索結果にサイトが表示されるようになる。Google AI ModeやChatGPT Searchからの流入が始まる。
参考。 当ブログのllms.txt解説記事とNLWeb連載 第1回。
ステージ2：対話する（1〜4週間）
やること。 NLWebエンドポイント（/ask）の実装（自社カタログをRAG化）。MCPサーバーの公開（商品データ・在庫データのAPI化）。
効果。 エージェントがサイトと自然言語で対話し、商品を絞り込める。「26cmの在庫はありますか？」に即答できる。
参考。 当ブログのWebMCP連載とエージェンティックWebの完全スタック。
ステージ3：売る（1〜3ヶ月）
やること。 UCP /.well-known/ucp プロファイルの公開。チェックアウトAPI（UCP準拠）の実装。StripeやAdyenなどPSPのAgentic Commerce Suite / UCP対応プランを有効化。
効果。 エージェント経由の直接購入が可能になる。Google AI Mode、Geminiアプリ内での「Buy」ボタン表示。
注意。 ShopifyマーチャントはプラットフォームレベルでのネイティブUCP対応が進んでいるため、独自実装は不要な場合が多い。自社構築のECサイトの場合はPSPのSDKを介した統合が現実的。
ステージ4：信頼される（PSP対応待ち → 自動適用）
やること。 AP2マンデート対応（dev.ucp.shopping.ap2_mandate ケイパビリティの宣言）。Visa TAP認証の受け入れ。
効果。 エージェント取引に暗号学的な認可証明が付与される。チャージバックリスク軽減。Visa TAP対応取引のオーソリゼーション率向上。
現実的な見通し。 AP2マンデートの処理は第2回で述べた通り、Stripe、Adyen、Checkout.comなどのPSPがミドルウェアとして吸収する方向にある。マーチャント側の直接実装は限定的で、PSPのエージェント決済機能を有効化するだけで済むケースが多くなる見込みだ。
このロードマップの要点は、ステージ1は今日から始められるということだ。Schema.orgとllms.txtの整備は、サイトのSEOにも直接貢献する。エージェントコマースのためだけの投資ではなく、既存のWebマーケティングとの相乗効果がある。
3つの記事で見えた風景
この連載で描こうとしたのは、「AIエージェントに財布を渡す」という行為が、単一のプロトコルや単一のプレイヤーでは実現できないということだ。
第1回では、AP2のマンデートが認可・真正性・責任の所在をどう暗号学的に証明するかを見た。第2回では、Visa TAP、Mastercard Verifiable Intent、ACP、x402を含む6つのプロトコルが、対立ではなくレイヤードスタックとして収斂に向かっていることを確認した。そしてこの第3回では、決済スタックとアプリケーションスタックがUCPを結節点として1つの完全なジャーニーマップに統合される姿を描いた。
この風景から見えるのは、エージェントコマースの勝者はプロトコルを作った企業ではなく、プロトコルスタック全体を最速で実装した企業だということだ。プロトコルはすべてオープンで、誰でも利用できる。差がつくのは実装のスピードと深度だ。
エージェントに発見され、対話され、信頼され、支払いを受ける。その準備は、llms.txtを1ファイル公開するところから始まる。
この記事はシリーズ「AIエージェントに財布を渡せますか」の第3回（最終回）です。
参考情報
AP2 Mandates Extension — UCP Specification — UCP公式（2026年1月）
UCP and AP2 — UCP公式ドキュメント
Universal Commerce Protocol — UCP公式サイト
UCP Core Concepts — UCP公式
Google Universal Commerce Protocol (UCP) Guide — Google Developers（実装ガイド）
AP2 Specification — AP2公式仕様書
Visa Intelligent Commerce Connect — Visa（2026年4月8日）
Visa Trusted Agent Protocol — Specifications — Visa Developer Center
Mastercard Verifiable Intent — Mastercard（2026年3月5日）
NLWeb: Natural Language Web — Microsoft / GitHub
WebMCP — Google / Microsoft（W3C Web Machine Learning Community Group）
WebMCP Specification — W3C Community Group Draft（2026年4月）
Model Context Protocol — Anthropic（2024年11月）
A2A Protocol — Linux Foundation — Linux Foundation
この記事をシェアする
