Universal Commerce Protocol（UCP）とは？AIエージェント時代の購買規格を解説

2026年、Googleを中心としたAIプラットフォームとEC事業者を横断的につなぐ新たな標準仕様「Universal Commerce Protocol（UCP）」が注目を集めています。 <br<これは、AIエージェントがユーザーに代わって商品の発見から購入手続き、注文追跡までをスムーズに行えるようにするための共通プロトコルであり、既存のECシステムを大きく改修することなくエージェントコマースへの参入を可能にします。

本記事では、UCPの中核機能であるCheckout、Identity Linking、Order Managementの仕組みや、ACPやAP2といった関連プロトコルとの位置づけ、さらに企業が導入する際の責任分界やセキュリティ設計について、最新情報を基に体系的に解説します。

Universal Commerce Protocol（UCP）とは？エージェント購買の共通プロトコル

Universal Commerce Protocol（UCP）は、**AIエージェントや各種アプリから、ECサイト・決済サービス・IDプロバイダなどを横断して利用できるようにする共通プロトコル（オープンスタンダード）**です。

検索結果、チャット画面、ECサイト、ウォレット、決済事業者など、いまはバラバラに存在している世界をつなぎ、**「発見 → 比較 → 購入（最終確定） → 追跡」**までを一つの言語で表現できるようにすることを狙っています。

ポイントは、「エージェントが買い物を代行しやすくする“共通の枠組み”」を作ることにあります。

UCPが標準化する範囲

UCPが直接標準化するのは、在庫計算や税計算といった“内側のロジック”そのものではなく、「エージェントやアプリ」と「ビジネス側」がどうやって会話するか、という**インターフェースと、その結果表現（例：税・送料・割引を含む合計＝totals など）**です。

UCPが扱う対象は大きく3つです。

• どの機能（Capabilities）を提供しているか。
  例：Checkout（注文手続き）、Identity Linking（ID連携）、Order（注文管理）など。
  
  
• どの拡張機能（Extensions）をサポートしているか。
  例：割引（Discounts）、フルフィルメント（配送・店舗受け取り）、AP2 Mandates など。
  
  
• どの通信手段（Services）でやり取りするか。
  REST（HTTP） / MCP / A2A / Embedded（埋め込み）など。

ビジネス側は、既存のECシステムを大きく作り替える必要はなく、「自分たちのECがどんなことに対応しているか」をUCPのスキーマで説明するイメージです。

想定されている利用シーン

UCPは、特にAIエージェントを介した購買体験を前提に設計されています。

代表的なユースケースは次のとおりです。

• Googleの AI Mode in Search や Gemini から、商品を発見 → 比較し、そのまま購入（※最終確定は信頼できるUI）まで進める。
• Shopifyや大手小売（Walmart、Etsy、Wayfair、Target など）と連携した、マルチマーチャント横断のエージェント購買。
• 将来的には、OpenAI側の ACP（Agentic Commerce Protocol） をはじめとした他社エージェントとの相互運用（エージェント間コマース）。

UCPは、こうした場面で**「それぞれのエージェント・決済・ID管理サービスが、同じ言葉でしゃべるための共通レイヤー」**として動きます。

Universal Commerce Protocol（UCP）がもたらす勝ち

ここでは、UCPがもたらす変化を、ユーザー視点とマーチャント（EC事業者）視点の2つの軸で整理します。

ユーザー：会話の延長線上で“最後まで”進める

UCPのわかりやすい価値は、「会話ベースの検討」から「最終確定」までの距離を縮めることです。

例として、ヘッドセット購入のケースを考えます。

- ユーザー 
  「1万円以下でノイズキャンセリング付きのヘッドセットが欲しい。来週の出張までに届くものがいい」  

- エージェント（Geminiなど）：  
  - UCP経由で複数マーチャントの在庫・価格・配送条件を取得。  
  - レビューや配送日を含めて候補を提示。  

- ユーザー：  
  「2番目のやつでいい。会社の住所に送って」  

- プラットフォーム：  
  - UCP Checkoutに必要な情報を渡す。  
  - **信頼できるUI（プラットフォーム側の画面や埋め込みCheckout）でユーザーが最終確認・購入ボタンを押す。**

このように、「AIが勝手に決済まで完結させる」のではなく、エージェントが段取りを整え、購入者が信頼できるUIで最後のOKを出す設計になっている点が重要です。

マーチャント：既存ECを“エージェント対応”にする

マーチャント側のメリットは、既存のEC基盤を活かしたまま、エージェント経由の購買に参加できるところにあります。

• すでに利用している PSP（Stripe / Adyen / PayPal など）を、そのままバックエンドとして使える。
• Google Payなどのウォレットや、独自の決済フローを「Payment Handler」として宣言できる。
• 在庫・価格・税・配送ロジックは既存システムの責任範囲のまま、UCPマニフェストで「どの機能に対応しているか」を公開するだけで済む。

ざっくり言えば、UCPは**「コマース版のUSB規格」**のような立ち位置です。

次に、これらを実現するために最低限押さえておきたい仕様を、3つのCapabilityに分けて整理します。

Universal Commerce Protocol（UCP）の仕様：3つのコア機能

ここからは、実装側の目線で 「最低限押さえておきたい仕様」を簡潔に整理します。

1. Checkout：共通の状態モデルとAPI

Checkout Capabilityは、HTTP/REST・MCP・A2Aといったトランスポートに関わらず、共通の状態モデルに沿って動きます。

典型的な流れは次のとおりです。

1. 「create」
   カートを作成し、商品・数量・価格・通貨などを確定します。

2. 「get」
   現在のCheckout状態を取得します。合計金額や選択済みオプション、次に必要なアクションを確認します。

3. 「update」
   配送先・配送方法・クーポン・支払い手段などを更新します。

4. 「complete」
   購入確定です。多くの場合は、信頼できるUIでユーザーが最終確認した上でcompleteに進みます。

5. 「cancel」
   ユーザーまたはマーチャントによるキャンセルです。

エージェント側は、「どのマーチャントか」に関わらず、この一連の状態遷移を同じモデルで扱えるようになります。

2. Identity Linking：OAuth 2.0ベースのアカウント連携

Identity Linking Capabilityは、OAuth 2.0 Authorization Code Flowをベースにしたアカウント連携のルールを定めています。

• 「ucp:scopes:checkout_session」のようなUCP専用スコープで、Checkout関連の権限をまとめて要求します。
  
  
• 「.well-known/oauth-authorization-server」にメタデータを公開し、プラットフォームが自動的にエンドポイントを発見します。

一方で、UCPでは**「IDをリンクしない場合でも、購入はできるべき」**という前提が置かれています。

つまり、Identity Linkingを実装しない場合でも、ゲストチェックアウトを提供する義務があるイメージです。

3. Order Management：Webhook中心のステータス同期

Order Capabilityは、注文のライフサイクルを、ビジネスからプラットフォームへ標準的に共有するための仕組みです。

重要なのは、「エージェントがOrder APIをポーリングする」のではなく、
マーチャント側がWebhookで注文イベントをプッシュする設計が中心になっている点です。

• 注文確定時は、**Order Created イベント（注文作成）**のような形でイベントを送信します。
• 出荷準備中・発送済み・配達完了・返品受付など、状態変化のたびにイベントを送信します。
• プラットフォームは受け取ったイベントを元に、Geminiなどの会話UIで「いまの状態」を説明します。

これにより、ユーザーは「先週買ったヘッドセット、いまどこ？」と聞くだけで、どのサイトで買ったかを意識せずに最新の注文状況を確認できるようになります。

Extensions：業界ごとの差を吸収する仕組み

UCPのもう一つの特徴が先ほど、Extensions（拡張）による機能追加です。

代表例としては、次のようなものがあります。

• Discounts Extension
  クーポンコード、キャンペーン割引などの取り扱いを標準化します。
  
  
• Fulfillment Extension
  通常配送／お急ぎ便／店舗受け取りなどのオプションや、ラストマイル連携の扱いです。
  
  
• AP2 Mandates Extension
  AP2を用いた**Mandate（同意の拘束／署名付きの支払い許可）**など、支払いに関する“信頼レイヤー”を扱う拡張です。

Extensionsはコア仕様から独立しており、業種・リージョンごとの商習慣や規制に合わせて拡張しやすい構造になっています。

Universal Commerce Protocol（UCP）の始め方

GoogleのAI Mode / Gemini上でUCPの購買体験を動かすまでの流れは、公式ガイドでは「5ステップ」で示されています。

ここでは読みやすさのために、それを「3つのまとまり」に束ねて整理します。

1. 商品データと前提条件（Merchant Center）

まずは「そもそも購入を成立させるための前提」をMerchant Center側で満たします。ガイド上も、API実装に入る前にこの要件を完了するよう求めています。

設定面では、返品ポリシーとカスタマーサポート情報が必須です。返品ポリシーはMerchant of Record要件としてチェックアウト画面から参照され、サポート情報は注文確認ページの「Contact Merchant」導線に使われます。

商品データ側では、UCP経由の購入対象かどうかを示すフラグ（native_commerce）や、規制対応が必要な商品の注意喚起（consumer_notice）などをフィードに載せます。

これらは、エージェントが購入可否を判断し、合計金額を正確に計算し、必要な警告を表示するための情報として扱われます。

参考：Merchant Center アカウントを準備する(Google UCP Guide)

2：接続の宣言（Business profile）

次に「Googleがあなたのサーバーを発見し、どんな機能を提供できるかを理解できる状態」を作ります。その中核がBusiness profileです。

Business profileは、ドメイン配下の /.well-known/ucp に公開します。ここで、提供するサービス（エンドポイント）や対応Capabilities、支払いハンドラなどを宣言します。
あわせて、Webhook等の認証付きメッセージの署名検証に使う公開鍵（signing_keys）も掲載します。

参考：ビジネス概要(Google UCP Guide)

3：体験を動かす実装（ネイティブ チェックアウトと注文同期）

最後に「購入→購入後の追跡」が実際に動くところを実装します。公式の最短ルートは、Native checkoutと注文ステータス同期です。

「ネイティブ チェックアウト」は、チェックアウトセッションを取得し、更新し、確定まで進めるためのRESTエンドポイント群を実装します。
ガイドでは、セッション取得（GET）や更新（PUT）などの具体例が示されており、住所変更時には税や配送オプションを再計算して返すことが求められます。

購入後は、注文ステータスの更新をGoogleへWebhookでプッシュします。ポーリングではなく、マーチャント側が状態変化のたびにイベントを送る前提です。これにより、会話UI側で配送状況などを一貫して扱えるようになります。

参考:
ネイティブ チェックアウト(Google UCP Guide)
注文のライフサイクル(Google UCP Guide)

Universal Commerce Protocol（UCP）のユースケース

ここでは、UCP導入後の具体的なイメージを3パターンに分けて整理します。

1. 対話で条件を詰めてから購入する

一番イメージしやすいのが、会話しながら条件を絞り込み、そのまま購入まで進むパターンです。

• ユーザー：「10万円以下で4K対応、リモート会議向けのモニターが欲しい。2日以内に届くものがいい」
• エージェント：UCP経由で、複数マーチャントの在庫・価格・配送条件を取得→候補を提示。
• ユーザー：「2番目でOK。自宅に送って」
• プラットフォーム：UCP Checkoutを使ってカートを作成し、配送先・支払い手段を反映。
• ユーザー：信頼できるUIで最終確認→購入完了。

ユーザー側から見ると、「どのECサイトで買うか」ではなく「何を、どんな条件で買うか」を会話で決める体験になります。

2. AI検索結果からそのまま購入に進む

もう少し「検索寄り」のパターンでは、AI検索の結果画面から、そのまま購入フローに入るケースが想定されています。

• AI Modeの検索結果に「この商品を今すぐ買う」ボタンを表示します。
• バックエンドでは、UCP CheckoutとPayment Handlerでセッションを進行します。
• ユーザーは、プラットフォームのUI上で最終確認し、購入を完了します。

従来のように、

検索結果 → 別タブでECサイト → カート投入 → 会員登録 → 決済

と何ステップも踏む必要がなくなり、離脱ポイントを大幅に減らせるのが狙いです。

3. 追跡・返品・交換を会話で完結させる

Order Capabilityを使うと、購入後のコミュニケーションもエージェントに寄せやすくなります。

• 「先週買ったヘッドセットの配送状況を教えて」
• 「サイズが合わなかったから返品・交換したい」

といった問い合わせに対して、プラットフォームはマーチャントからWebhookで受け取った注文イベントを元に回答します。

返品・交換の申請フロー自体はビジネス側の実装に依存しますが、
少なくとも結果としての状態（受付中／完了など）を共通フォーマットで同期できるため、

購入前はAI／購入後はメールと電話

という断絶を小さくしていくことができます。

Universal Commerce Protocol（UCP）と関連プロトコルの関係

UCPは単体で完結するわけではなく、ACP / AP2 / MCP / A2A といった他のプロトコルと組み合わせて使われることを前提にしています。

ここでは、役割の違いをざっくり整理します。

ACPとの違い：プラットフォームの前提が異なる

ACP（Agentic Commerce Protocol） は、OpenAIとStripeが共同開発したオープンスタンダードで、買い手・AIエージェント・事業者が購入を完了するための対話モデル（相互作用モデル）を定義します。最初の実装例がChatGPTのInstant Checkoutです。

• ACP

  • Instant Checkout（ChatGPT）を起点に公開されたオープン標準です。
  • 「ユーザーが最終確認して購入ボタンを押す」ことが明確に組み込まれています。
  • 登場人物は Buyer / Agent / Seller / Payment Processor などです。

• UCP

  • Googleを含む複数のプラットフォームをまたいで使われることを前提とした設計です。
  • 住所や決済情報などの資格情報について、保管主体・同意フロー・共有範囲を分離して設計しやすいです。
  • ACP以外のエージェントやウォレットとも連携しやすい、よりベンダーニュートラルな枠組みです。

かなりラフに言えば、UCPは**「広い意味でのエージェントコマースの共通語」です。
ACPは「購入フローを会話で進めるための相互作用モデル」**という位置づけになります。

AP2との役割分担：支払いの“信頼レイヤー”を任せる

AP2（Agent Payments Protocol） は、エージェント取引における支払いを安全に成立させるための、**信頼レイヤー（Mandate等による同意の拘束／署名検証）**を担うプロトコルです。

• AP2
  • 「誰が誰のために、どの支払い手段で支払うか」を検証可能にするレイヤーです。
• UCP
  • 「どのビジネスに、どの商品を、どの条件で購入するか」というコマースの文脈全体を扱うレイヤーです。

UCPはAP2をExtensionとして取り込めるようになっており、
「支払いの信頼レイヤー」はAP2に任せ、それ以外のコマース文脈はUCP側で標準化する構成が想定されています。

MCP / A2Aとの関係：運び手として使う

• MCP（Model Context Protocol）
  • LLMと外部ツール・データソースをつなぐ「ツール呼び出し」の標準です。
    
    
• A2A（Agent2Agent）
  • エージェント同士がやり取りするためのプロトコルです。

UCPそのものは、これらの上に載る「ペイロードの形式」を定義する側であり、以下のような構成が想定されています。

• 「UCPのCheckoutをMCPツールとして公開する」
• 「A2A上で、UCP形式のメッセージをやり取りする」

イメージとしては、レイヤーを分けて考えると整理しやすいです。

• UCP：何を・どう買うか（コマースの言語）
• AP2：支払いを成立させる（信頼レイヤー）
• MCP / A2A：それらのメッセージをどう運ぶか（トランスポート）

Universal Commerce Protocol（UCP）導入時のポイント

最後に、企業目線でUCPを導入する際に検討すべきポイントを、責任分界・同意／データ・不正対策の3つに分けて整理します。

1. 責任分界と契約

UCPでは、ビジネス側が引き続き Merchant of Record（販売記録の所有者） であることが前提です。

つまり、エージェントやプラットフォームが間に入っても、責任の所在は消えません。
契約やSLAのレベルで、次の点を明確にしておく必要があります。

• 誰がMerchant of Recordになるか。
• 返品・返金・チャージバックが発生したとき、誰がどこまで責任を負うか。
• Checkout失敗やAPI障害が起きたとき、どのようにフォールバックするか。

「ユーザー体験」と「責任の所在」の整合性を取ることが、導入時の大きな論点になります。

2. 同意とデータ統制

Identity Linking や AP2 を併用する場合、ユーザーの同意とデータフローの設計が重要になります。

運用上の検討点は次のとおりです。

• どのデータが、どの主体の間で共有されるのか。
  • 例：エージェント ⇔ ウォレット／ID連携基盤 ⇔ PSP ⇔ マーチャント。
• OAuth 2.0の同意画面で、何をどこまで説明するか。
• GDPR / CCPA / 電子決済指令など、地域ごとの規制との整合。

UCP自体は「最小限のデータ共有」を前提に設計されていますが、
実際の運用では、自社のプライバシーポリシーや利用規約、DPAなどにどう落とし込むかを詰める必要があります。

3. 不正対策と監査・ログ

エージェントがユーザーに代わってプロセスを進める世界では、不正検知と監査性の重要度がさらに高まります。

設計時に押さえておきたい観点は次のとおりです。

• UCPの Risk Signals（リスクシグナル）をどう扱うか。
• 既存の不正検知サービスと、どのレイヤーで連携させるか。
• 「誰が／いつ／どの権限で／どの決済を行ったか」をどの粒度でログに残すか。

従来の「誰がボタンをクリックしたか」に加えて、
「どのエージェントが、どの同意に基づいて行動したか」 を追跡できるようにしておくことが重要です。

Universal Commerce Protocol（UCP）のFAQ

最後に、企業から出やすい疑問をQ&A形式で簡単に整理します。

Q. UCP自体の利用に料金はかかりますか？
A. UCPはオープンソースのプロトコルで、仕様の利用自体にライセンス費用は発生しません（Apache 2.0ライセンス）。
　ただし、実際の連携にはプラットフォームとの契約やPSP手数料、開発ベンダーへの支払いなど、別途コストがかかります。

Q. UCPを導入すると、自社ECサイトは不要になりますか？
A. いいえ。UCPはECサイトを置き換えるものではなく、**自社ECをエージェントや外部プラットフォームに“公開するためのインターフェース”**です。
　在庫・価格・フルフィルメントの責任は、基本的にこれまでどおりマーチャント側に残ります。

Q. まず何から手をつければよいでしょうか？
A. 現実的には、次の3ステップから始めるのが無理がありません。

• UCP仕様とGoogle UCPガイドのキャッチアップ。
• 自社ECのAPI整備状況（Checkout / Order（Webhook）/ ID連携）の棚卸し。
• 1ブランド・1リージョンなど小さなスコープでのPoC設計。

その上で、「どのプラットフォームと組むか」「どのレイヤーまで内製するか」を検討していく流れになります。

まとめ

Universal Commerce Protocol（UCP）は、

• AIエージェントや検索・チャットインターフェースから
• 既存のEC・決済・ID基盤をまたいで
• 「発見〜購入（最終確定）〜追跡」までのプロセスを一つの共通言語で表現する

ためのオープンなコマース標準です。

Checkout / Identity Linking / Order の3つのCapabilityに加え、Discounts・Fulfillment・AP2 MandatesなどのExtensionsを組み合わせることで、業種やリージョンごとの違いにも対応しやすい柔軟な枠組みになっています。

企業としては、

• 既存のEC・PSPを前提にしつつ、エージェント経由の新しい購買導線を開く
• UCP・AP2・MCP・A2Aなどの標準を組み合わせ、責任分界とログ設計を明確にしたアーキテクチャを組む

といった方向性が、現実的な第一歩になるはずです。

今後、エージェント経由のコマースが一般化していく中で、
「自社はどのレイヤーまでを担い、どこから標準プロトコルに委ねるのか」 を考える際、UCPはその議論の土台となるプロトコルになっていくでしょう。