Universal Commerce Protocolとは、AIエージェントが利用者に代わり購買するための新しいコマース標準です。
本記事ではUCPの活用方法や、使い方ガイドとしてUniversal Commerce Protocolの全体像、基本機能等を解説します。
導入時の検討ポイントやロードマップ情報をもとに、Universal Commerce Protocol導入準備の参考としてご活用ください。
Universal Commerce Protocolとは？AIエージェント時代の新しいコマース標準
Universal Commerce Protocol（UCP）は、ECによる購買体験を「AIが手続きを理解して買い進める」ものにするための共通仕様です。これまでのECは、検索結果から商品ページに入り、カートに入れ、フォームを埋めるという「画面操作」を中心に設計されてきました。Universal Commerce Protocolでは、ECでの購買をAIエージェントが主導できるように共通ルールを定めます。
本章ではUniversal Commerce Protocolの位置づけを押さえたうえで、Googleが描く次世代の購買体験と、類似アプローチであるAgentic Commerce Protocol（ACP）との比較を踏まえて新しいプロトコルへの理解を深めます。
Universal Commerce Protocolの定義とGoogleが目指すビジョン
Universal Commerce Protocol（UCP）は、AIエージェントが購買プロセスに関与することを前提に、事業者とAIサーフェスを統合するための共通仕様です。従来のECのように「人が画面を操作すること」を前提にするのではなく、事業者が提供可能な手続きや条件をコンピューターが理解できる形で提示し、AIエージェントがそれを読み取って購入手続きを組み立てられるようにします。特定のUIやアプリケーションに依存せず、複数の接点で再利用できるオープンな標準を目指している点が特徴です。
Universal Commerce Protocolは、ShopifyやWalmartなど、ECの業界リーダーが共同開発に参加しており、AdyenやAmerican Express、Visaなど、20社以上の関連企業が賛同しています。共同開発企業・賛同企業が多く、業界標準としての普及の土台がある状態です。
これまで、ショッピングは「人間が画面を見て判断する」プロセスによって実現されていました。しかし、Universal Commerce Protocol を活用することで、AIエージェントが利用者の嗜好を理解し、最適な取引を代行する自律的な購買モデルへと変化していくことが見込まれます。
AIエージェントとECサイトにおける「共通言語」としての役割
AIエージェントが従来のECで購買を行う際には、「人間向けのUI」が一つの障壁となっています。サイトごとに異なるHTML構造や画面遷移を解析したり、各サイト独自のAPI仕様への対応が必要なためです。AIエージェント側・事業者側ともに調整コストが高く、スケールしにくいという問題を抱えていました。
Universal Commerce Protocolでは、事業者が「何ができるか」「どのエンドポイントで呼び出せるか」等を決まったフォーマットによって宣言・公開します。このような共通ルールを設けることで、これまでの「ECごとの個別調整の負荷が高い」という問題を解消し、AIエージェントが主導する安全な取引が実現できます。また、機械的に解釈可能な形で公開することにより、Webブラウザなどの画面理解・画面操作をスキップして購買フローを進めることが特徴です。
具体的には、事業者は自社の提供機能を「Business Profile」や「Capabilities」として公開し、AIエージェントはそれを発見・解釈して購買フローを構築する設計です。
- Business Profile … 事業者が提供するCapabilitiesや、Capabilitiesを利用するためのアクセス情報など
- Capabilities … 実行可能な操作のリスト（購入商品やそのチェックアウト、購入後の更新など）
Business Profile、Capabilitiesの詳細については「Universal Commerce Protocolの使い方：エンジニア向け実装ガイド」にて説明します。
重要なポイントはUniversal Commerce Protocolを利用する場合、AIエージェントによる操作は事業者が許可した範囲に限定されるということです。そのためUniversal Commerce Protocolの導入には、「購買体験のどの範囲をAIに委ねたいか」を明確にすることが重要です。すべてのプロセスをAIエージェント経由にする必要はなく、検索や比較など一部のプロセスから段階的に導入する選択肢もあります。Universal Commerce Protocolは柔軟な枠組みを提供しますが、その自由度を魅力的な購買体験に活かせるかどうかは事業者側の設計次第です。
【比較表】Universal Commerce ProtocolとAgentic Commerce Protocolの違い
AIエージェントが商品購入を代行するプロトコルとして、「Agentic Commerce Protocol（ACP）」がOpenAIとStripeによって開発されています。
類似したプロトコルですが、Universal Commerce Protocol（UCP）とAgentic Commerce Protocol（ACP）の違いは以下の通りです。
| 項目 | Universal Commerce Protocol（UCP） | Agentic Commerce Protocol（ACP） |
|---|---|---|
| 主な目的 | AIプラットフォームと事業者の相互運用 | 会話型購入のオープン標準 |
| 実装の特徴 | 事業者が機能を公開 AIエージェントが参照・実行 | 会話型購入が起点 任意のAIエージェントで利用可 任意の決済事業者で利用可 |
| 想定サーフェス | AI検索 AIアシスタント 複数AIサーフェス 複数統合方式 | ChatGPTが先行事例 互換AIアプリに展開可 AIエージェントに展開可 |
| 購買体験の成立場所 | 複数サーフェス 複数方式 | AIチャット中心 |
両者の大きな違いは、「どこで購買体験を成立させるか」です。UCPは「複数サーフェス/複数方式で共通する購買ルール」の実装を想定しているのに対し、ACPは「AIチャット内での購買ルール」を提供します。
まずはAIチャット内で会話から購入までの購買体験を実現したい場合は、ACPの方がシンプルに実装できます。一方で、複数のAIサーフェス（AI検索・AIアシスタントなど）で一貫した購買体験を実現し、購入後のフォローアップまでAIサーフェスでカバーしたい場合には、UCPの利用を検討すると良いでしょう。
Universal Commerce Protocol導入前のチェックリストと今後の拡張方針
Universal Commerce Protocolを導入し、AIを活用した購買体験を魅力的なものにするためには、決済・返品・カスタマーサポートといった運用領域の設計が重要です。また、今後もUniversal Commerce Protocolは機能拡張が見込まれるため、適切な導入判断のために最新情報のキャッチアップも必要となります。
導入前のチェック観点とUniversal Commerce Protocolのロードマップを確認しましょう。
責任分界の明確化（決済/返品/サポート）
事業者としてUniversal Commerce Protocolを導入する際には、「事業者にどの責任が残るか」を確認しておく必要があります。
公式ドキュメントでは以下の通り、Business（事業者）はMerchant of Record（販売責任者）として注文・管理などについて責任を持つことが明記されています。
The entity selling goods or services. In the UCP model, businesses act as the Merchant of Record （MoR）, retaining financial liability and ownership of the order.
出典：Universal Commerce Protocol（UCP）
【参考訳】
商品またはサービスを販売する主体。UCPモデルでは、企業は販売責任者（MoR）として機能し、注文の財務責任と所有権を保持します。
Merchant of Recordとして、以下のような「購入後を含めた責任」を明確に定義し、契約・運用・システムにおいて整合性を持たせることが求められます。
- 返金に関するポリシー
- 購入後の問い合わせの窓口
- 購入に関する補償範囲
上記を踏まえて、Universal Commerce Protocolの導入を検討しましょう。
Universal Commerce Protocolのロードマップ
戦略的優先度の透明性を目的として、Universal Commerce Protocolのロードマップが公開されています。具体的な機能拡張の計画ではなく、あくまでもUniversal Commerce Protocolの今後の方向性を示す文書です。掲載内容は確約されたものではなく、状況やフィードバックで変更される可能性がある点にご注意ください。
ロードマップでは、大きく2つの方向性が示されています。
1つ目は「消費者ジャーニー全体の深掘り」です。購買体験を、一つ一つの単発の体験に閉じないものへ拡張することを掲げています。今後取り組まれる予定のものとして、以下があげられています。
- 注文額の最大化を支援する購入プロセス全体の円滑化
- 複数アイテムのチェックアウト、複雑なルール （プロモーション、税金、配送など）を反映したさまざまな配送処理のサポート
- ロイヤルティとメンバー特典を有効にする機能
- パーソナライズされた推奨事項やアップセルを提供する機能
2つ目は「グローバル市場対応」です。「シンプルでオープン」な業界標準として、誰もが利用可能であることを目指しています。ロードマップではインドやインドネシア、ラテンアメリカ等を例に、地域固有の要件やローカル決済の相互運用に対応していく方針が述べられています。
当面はすでに提供されている機能の活用を検討しつつ、将来のマルチカート・ロイヤルティ・購入後サポートなどの拡張を見据えて、データ/運用/契約に拡張性を持たせた設計を行うのがよいでしょう。
Universal Commerce Protocolの活用方法と予想される事業インパクト
Universal Commerce ProtocolがEC事業にもたらす変化は、単なる「購入導線の短縮」だけではありません。AI検索やAIチャットのような新しい接点が増えるほど、購入の起点はECサイトのトップページではなく、会話や検索結果の中に溶け込んでいきます。このような変化に備えて、どのような準備をするべきでしょうか。
ここでは、Universal Commerce Protocolの活用によるCV改善や購買体験（UX）の拡張、チェックアウトの統合方式についてポイントを解説します。
AIアシスタントやマルチストア購入による顧客体験（UX）の拡張
Universal Commerce Protocolが想定する購買体験は、単一のECサイト内に閉じたものではありません。Web検索やAIアシスタントといった複数のインターフェース上で共通ルールが適用されるため、利用者は「どこで買うか」を意識せず、自然な会話や検索の流れで購入を完了できます。
また、Universal Commerce Protocolはマルチストア環境にも対応できます。具体的には、AIエージェントは複数の事業者が公開する「Business Profile」を参照し、それぞれの「Capabilities」を比較することで、利用者にとって最適な選択肢を提案する仕組みです。これは単純に価格比較を自動化するものではなく、リアルタイムな在庫状況・価格、利用者の趣味嗜好などを踏まえて「AIエージェントが購入体験をオーケストレーションする」というUXの進化と言えるでしょう。
以下は、Google AIアシスタントとの会話の中でショップから商品を購入する際のサンプル動画です。
事業者にとってこの変化は、UIや広告に依存しない新しい接点が生まれる一方で、AIエージェントや利用者に選ばれるための情報整備・運用品質が重要になります。
AI検索やAIアシスタントなどの購入インターフェースが増えるほど、事業者は「画面設計」だけでなく「機械が理解できる情報の品質」で選ばれる場面が増えるでしょう。また、AIエージェントによるマルチストアの比較提案が進むほど、配送条件・返品条件・会員特典・対応速度など、価格以外のサービス内容と、その内容を正確に提供するための情報整備が差別化ポイントになります。
コンバージョン率向上とカート放棄率低減のためのポイント
Universal Commerce Protocolの導入により、カート画面への遷移や入力など、購買のためのプロセスを減らすことで利用者の途中離脱を抑制する効果が見込まれます。例えば、ログインや配送先入力などの「購入前の手間」は、チェックアウト離脱の原因になりやすいとされています。Universal Commerce Protocolでは、「Identity Linking」と呼ばれる機能を使ったアカウント連携により、これらの操作を最小限にする設計が可能です。
このように、Universal Commerce Protocolの仕組み・機能を活用することで、購買体験を最適化し、コンバージョン率の改善につながることが期待できます。ただし入力情報や手続きの簡略化は、事業者側の適切なポリシー整備やアカウント連携の設計が前提になります。これらが不十分な場合、AIエージェントが利用者に確認すべき内容が増え、かえって購買体験を損なうリスクもあるでしょう。
注意すべき点として、Universal Commerce Protocolを導入するだけで、顧客の購買体験が改善されるわけではありません。Universal Commerce Protocolはあくまでも既存のEC運用に、AIエージェント経由での購買チャネルを追加するものです。
Universal Commerce Protocolを活用して魅力的な購買体験を実現するためには、以下のような設計が重要です。
Universal Commerce Protocol活用のポイント
- AIエージェントが参照する情報（商品・価格・在庫・配送条件・ポリシーなど）を、既存の管理システムと整合させ最新に保つ
- チェックアウトの統合方式など、魅力的な購買体験を実現する機能の選択・利用
- 購入後（注文ステータス更新・問い合わせ・返品など）も含めた、AIエージェント経由の購入でも破綻しない運用
【比較表】チェックアウトの統合方式（Native/Embedded）の選び方
AIアシスタントなどの接点に、購入手続きをどう組み込むかは「チェックアウトの統合方式」によって決まります。Google向け実装では、チェックアウトの統合方式として「Native統合」と「Embedded（埋め込みの購入手続き）」の2つが選択できます。
| 項目 | Native統合 | Embedded（埋め込みの購入手続き） |
|---|---|---|
| 概要 | デフォルト方式 Google AI Mode / Geminiに直接統合 | 任意実装 Webチェックアウトを埋め込み |
| 実装のポイント | 購入手続きセッションを作成 購入手続きセッションを管理 REST APIを構築 | iframeで購入UIを実装 |
| ユーザー体験 | AIエージェント主導に拡張しやすい | ユーザー操作が必要 |
なお、Google AI Mode・Gemini上で公開するには待機リスト登録とGoogleの承認が必要です。当初の対象は米国のeligible retailersが中心となっています。
Universal Commerce Protocolを最短で始めたい場合や既存のチェックアウトがシンプルな場合、Native統合のみで対応できるケースが多いです。一方で年齢確認のプロセスがあるなど、既存のチェックアウトフローが複雑な場合はEmbedded（埋め込みの購入手続き）の実装を検討する必要があるでしょう。
Universal Commerce Protocolの使い方：エンジニア向け実装ガイド
Universal Commerce Protocolでは、AIエージェント、事業者、決済事業者など複数のロールが登場します。全体像を概観したうえで、Universal Commerce Protocolの基本的な機能や扱われるデータ、プロトコルについて紹介します。
全体アーキテクチャ（Platform/Business/Credential Provider/PSP）
Universal Commerce Protocolでは、商取引に関わる主体をPlatform/Business/Credential Provider/PSPの4つに分けて定義します。それぞれの役割は以下の通りです。
- Platform … ユーザーと対話する主体（検索やAIアシスタントなど）で、購入の意思決定・手続き等をオーケストレーションする
- Business … 商取引の主体であり、「Merchant of Record（MoR）」としての責任をもつ
- Credential Provider（CP） … 機密性の高いユーザーデータを安全に管理・共有する責任を負う信頼できる組織（Google Wallet、Apple Payなど）
- Payment Service Provider（PSP） … PayPal等のようにBusinessに代わって支払いを処理する金融インフラストラクチャプロバイダー
この分離により、AIエージェントが購買を代行する場合でも、責任の所在が明確になり、既存の商取引ルールが維持されます。
Universal Commerce Protocolの設計では、Businessが最終的な注文管理・請求・返金について責任を持ちます。そのため、Platformは「何を・どの順で実行するか」を調整する役割に留まり、CP/PSPやBusinessの内部ロジックに踏み込みません。既存ECや決済基盤を大きく変更しないまま、AIエージェント経由の購買チャネルを追加できます。
Business Profile（/.well-known/ucp）の公開
Universal Commerce Protocolを使用する場合、「自社が何を提供するか」をAIエージェントに伝えるために、Business（事業者）は「Business Profile」を設定します。具体的には、事業者は自社ドメイン配下の /.well-known/ucp にJSON形式でBusiness Profileを公開する仕組みです。
Platform（AIエージェントなど）はBusiness Profileを参照することで、「この事業者はチェックアウト可能か」「購入後の注文更新に対応しているか」といった能力を理解し、利用可否を判断します。Business Profileでは、以下のような情報を表現しています。
- 提供する基本機能（Capabilities）や拡張機能（Extensions）
- 対応するトランスポート
- サポートする認証方式
Universal Commerce Protocolを利用するための仕様を、事前に決められた場所（/.well-known/ucp）で公開しておくことで、各Platform（AIエージェントなど）とBusiness（事業者）が個別に連携する負担を軽減できる点が特徴です。
Universal Commerce Protocolの基本機能（Capabilities）と拡張機能（Extensions）
Universal Commerce Protocolでは、事業者が提供する操作を「Capabilities」として定義します。Capabilitiesは「チェックアウトできる」「注文状態を更新できる」など、AIエージェントが実行可能な機能を意味しています。実行可能なCapabilitiesは事業者ごとにBusiness Profileで公開され、Platformはその範囲内で取引を進める設計です。
「Extensions」はCapabilitiesを補完・拡張するための仕組みです。業界固有の要件や段階的な機能追加が想定されています。現時点では、以下のようなExtensionsが利用可能です。
- Discount Extension … チェックアウトで割引コードを適用する
- Fulfillment Extension … 商品の配送、集荷に関するオプションを選択
- Buyer Consent Extension … データ利用やコミュニケーションに関する購入者の同意状況について、企業に伝達
Capabilities/Extensionsのポイントは「AIエージェントが何をしてよいかを明示的に制限する」ことです。AIが自由に画面操作やAPIを実行するのではなく、AIエージェントの操作を事業者が許可した範囲に制限することで、セキュリティや予測可能性を高めます。
Universal Commerce Protocolにおける接続点とデータの流れ
Universal Commerce Protocolでは、Platform/Business/Credential Provider/PSPの4つのロール間で、発見→購入開始→決済処理（購入完了）→購入後というプロセスが実行されます。各プロセスの詳細は以下の通りです。
Businessが公開した「Business Profile」をPlatformが発見します。
このとき、以下のようなデータがやりとりされます。
- 事業者が提供する能力（Capabilities）
- 呼び出し先（エンドポイント）
- セキュリティ検証に必要な情報（公開鍵）など
チェックアウト機能を使って、商品の選択など購入手続きを進める流れです。
このプロセスを通じて、以下のようなデータを確定させる流れです。
- カートの内容
- 配送先/配送手段
- 支払い方法など
チェックアウト機能では、以下の画像の通り支払い方法（クレジットカード、電子マネーなど）や税金の計算などのロジック実装もサポートしています。
Platformが購入プロセスを「完了」すると、Business側で注文確定と決済関連処理が進む流れです。決済についてはBusiness・Platform・Credential Providerを中心に進み、その後Business側でPSP連携が行われます。
AIアシスタントなどのPlatformは決済資格情報の取得には関与する点に注意が必要ですが、PSPによる実決済は主にBusiness側で行う設計です。
購入が完了したあとも、BusinessはPlatformに対して配送状況や返品・返金の受付を提供します。
このとき、以下のようなデータが扱われる流れです。
- 注文ID/ステータス
- 配送状況
- 返金/問い合わせなどのイベント情報など
Business側のデータ変更がPlatformに同期されることで、以下の画像のように利用者はAIサーフェス経由で購買状況を確認できます。
Universal Commerce Protocolの統合方式（REST/MCP/A2A/EP）
Universal Commerce Protocolは、単一の通信方式に依存しない点が特徴です。現在、REST API、MCP（Model Context Protocol）、A2A（Agent-to-Agent）、EP（Embedded Protocol）といった、複数のプロトコルによる統合がサポートされています。
それぞれのプロトコルの違いは以下の通りです。
| プロトコル | 概要 | メリット | 注意点 |
|---|---|---|---|
| REST | HTTP API連携 JSON送受信 | 一般的な実装方式 既存APIを流用しやすい | 機能追加で複雑化しやすい |
| MCP | AIエージェント向け連携 LLMツールとして公開 | AIエージェントから呼び出しやすい | MCPサーバ構築が必要 |
| A2A | AIエージェント同士の連携 | 役割分担しやすい 協調動作に向く | 双方の対応が必要 |
| EP | 既存UIの埋め込み | 既存UIを活用しやすい 既存ロジックを残しやすい | UI操作が前提 AI主導は限定的 |
それぞれのプロトコルの違いを踏まえると、以下のような使い分けが考えられます。
- REST … 既存ECや決済基盤を活用する
- MCP … AIエージェントとの連携性を重視
- A2A … 利用者側AIエージェントと事業者側AIエージェントが連携するケース
- EP … 複雑/高度にカスタマイズされた既存のチェックアウトUIを利用したい
Universal Commerce Protocolの基本機能：実装のポイント
Universal Commerce Protocolの「基本機能（Capabilities）」として、Checkout、Order、Identity Linkingが用意されています。それぞれの概要や役割について、Universal Commerce Protocol導入の際のポイントを抑えながら説明します。
Checkout機能による購入プロセス
Checkoutは、AIサーフェス上で「購入に必要な情報を確定し、注文を確定させる」ための機能です。「Checkout Session」を作成し、その中で購入に関するデータやステータスを取り扱います。
以下の基本操作により、Checkout Sessionを管理します。
- セッション作成（create）… Checkout Sessionを作成
- 取得（get） … 作成したCheckout Sessionの「現在の状態（current state）」を取得
- 更新（update） … ユーザーの入力・選択情報の変更に応じて、税・送料・合計などを再計算
- 完了（complete） … 注文を確定する。この操作をトリガーとして後続の「決済処理」が開始される
- キャンセル（cancel）… Checkout Sessionを取り消し、状態を「canceled」に変更する
Platformが購入を開始する段階でCheckout Sessionが作成され、取得・更新の繰り返しにより購入情報を確定させていきます。最終的にCheckout Sessionを「完了（complete）」にすることで注文確定となり、次の決済処理が開始されます。利用者によるキャンセルや事業者側の制約（在庫切れなど）で購入が継続できない場合には、状態を正しく保持するためにキャンセル操作が必要です。
Orderによる購入後のフォローアップ
Orderは、購入後の状態管理と情報連携を行うための機能です。Checkoutで注文が確定すると、商取引は完了したように見えますが、実際のEC運用ではその後も「発送」「配送」「返品」「返金」といった複数のプロセスが続きます。Orderはこうした購入後の一連の状態変化を管理し、Platformへの情報連携を実現する機能です。
Universal Commerce Protocolでは、注文についてはBusiness（事業者）が所有権を持ち、注文状態の管理も担っています。注文作成、支払い確定、発送開始、配送完了、キャンセル、返金完了など、事業者の既存業務フローに基づいて、注文の状態が変更される仕組みです。Order機能によって、この状態変更をPlatformに同期する役割を果たしています。
Universal Commerce Protocolの仕様では、状態変更が発生したタイミングでWebhookベースで状態変更をPlatformに通知する仕組みが定義されている点も特徴でしょう。これにより、利用者はECサイトに逐一アクセスしなくても、AIエージェントとの会話で注文状況を確認できるようになります。
購入後の注文管理・利用者へのフォローアップ
- 注文のステータス：事業者の既存業務フローによって変更
- 利用者へのフォローアップ：Order機能により注文ステータスをPlatformに同期し、Platformが利用者に提示
注意点として、Universal Commerce Protocolはカスタマーサポート業務そのものを代替するわけではありません。返品可否の判断や返金承認、問い合わせ対応のポリシーは、あくまで事業者の責任範囲にあります。Order機能は、その判断結果や状況をAIエージェント経由で連携するための仕組みです。
Identity Linkingによるセキュアなユーザー管理
Identity LinkingはAIサーフェス上の利用者と、事業者（Business）が保有する既存アカウントを安全に紐付けるための機能です。
AIエージェントが購入を代行する場合でも、最終的な取引主体である事業者は「誰が購入しているのか」を正しく識別する必要があります。Identity Linkingはこの識別を行うために、標準的な認可プロトコルであるOAuth 2.0をベースにした設計です。
Identity Linkingを実装すると利用者はAIサーフェスから、事業者側に存在する自身のアカウントにログインしたり、ポリシーへの同意などの操作に対応しています。OAuth 2.0をベースにしているため、アカウント連携後の操作は「事業者がユーザーに対して許可した範囲」のみに限定される仕組みです。これにより、AIエージェントが自由に操作するのではなく、事業者が許可した操作に限定した形で取引を成立させられます。
Identity Linkingによるアカウント連携・ポリシー同意の実装画面サンプルは以下の通りです。
Identity Linkingは「何を・どこまで許可するか」を決める設計が重要です。必要最小限のスコープ設計、同意文言、連携解除時の扱い、監査ログなどを含めて、契約・運用・システムの整合性を持って実装することが、セキュアなAIコマース体験の前提となります。
まとめ
Universal Commerce Protocolについて、定義やこれまでの購買体験との違いなどを紹介しました。また事業者で想定される活用方法や、使い方を検討する際の要点となる機能（Business Profile、Capabilities、Checkout、Order、Identity Linking）を整理しました。
Universal Commerce Protocolの導入により、顧客の購買体験が大きく変化する可能性があります。ただし、導入すれば勝手に購買体験が改善されるわけではなく、AIサーフェス経由という新しい購入チャネルに適した運用設計が重要です。
Google向け実装を検討する事業者は「順番待ちリスト」への登録をご検討ください。また、UCPの仕様そのものは公式仕様書・公開リポジトリでも確認できます。