UCPとは？Universal Commerce Protocolの仕組みとACP・AP2との違い【v2026-08-25対応】

UCP（Universal Commerce Protocol：ユニバーサルコマースプロトコル）は、AIエージェントやアプリが小売事業者の商品検索・カート・決済・注文管理を共通の手順で呼び出せるようにするオープン規格です。Googleが2026年1月11日に発表し、Shopify、Etsy、Wayfair、Target、Walmartと共同で開発しました。仕様はGitHubのUniversal-Commerce-Protocol/ucpリポジトリでApache-2.0ライセンスとして公開されており、2026年9月28日時点の最新版は v2026-08-25 です。

事業者は /.well-known/ucp に対応機能を書いたプロファイルを置き、エージェントはそれを読んで取引を進めます。Google検索のAIモードとGeminiでは、UCPを使ったチェックアウトが米国の対象商品から段階的に提供されています。Merchant Centerヘルプはカナダとオーストラリアも対象に挙げていますが、管理画面のUCP integration hubは両国で2027年初めの提供予定です。日本での提供時期は発表されていません。この記事では、仕様書と実在ストアの公開プロファイルをもとに、仕組み、ACP・AP2との違い、最新版の変更点を整理します。

まとめ：UCPの要点

• 定義：プラットフォーム（AIエージェント・アプリ）と事業者の間で、商品検索から決済・注文後の管理までをやり取りする共通規格。Google主導で、GoogleとShopifyが常任席を持つGoverning Councilが管理している
• 仕組み：事業者が /.well-known/ucp にcapability（機能）と接続先を宣言し、事業者はプラットフォームのプロファイルと自社の対応範囲を突き合わせ、有効な機能を決めて応答する。接続方式はREST・MCP・A2A・Embeddedの4つ
• ACPとの違い：ACPはOpenAIとStripe（とMeta）が管理するベータ版の規格。商品データをUCPはエージェントが取りに行き、ACPのFeed APIは事業者がエージェント側へ送り込む
• AP2との関係：AP2は支払いの証明を担う別の規格。UCPは拡張 dev.ucp.common.payment.ap2_mandate でAP2のマンデートを受け取る
• Googleでの提供：AIモードとGeminiの購入ボタンは米国の対象商品から段階提供中で、参加はGoogleの承認を受けた一部の販売者のみ。Merchant Centerヘルプはカナダ・オーストラリアも対象に挙げる一方、両国のUCP integration hubは2027年初めの予定。日本の提供時期は未定
• 最新版：v2026-08-25で店舗検索・3Dセキュア・複数の支払い手段の併用・ロイヤルティを追加。フルフィルメントや同意のスキーマに破壊的変更がある

UCP（ユニバーサルコマースプロトコル）の定義と発表の経緯

UCPが解こうとしているのは、エージェントと店舗をつなぐ実装が組み合わせの数だけ必要になる問題です。エージェントが10種類、店舗が1万あれば、個別連携ではそれぞれの組で実装が発生します。UCPは店舗側が1回だけ機能を宣言し、どのエージェントもその宣言を読んで同じ手順で注文できるようにします。

仕様書のCore Conceptsの用語では、機能を使う側をPlatform（AIエージェント、アプリ、調達システムなど）、機能を公開する側をBusiness（小売、航空会社、ホテルなど）と呼びます。役割は業種ではなく機能の流れる向きで決まるため、B2CだけでなくB2Bやエージェント同士の取引にも同じ枠組みを使えます。取引の法的な売り手（Merchant of Record）はBusiness側に残ります。

共同開発企業と賛同企業

Googleの発表記事（2026年1月11日、全米小売業協会の年次イベントNRFに合わせて公開）は、UCPを「ショッピングの全行程で機能するエージェントコマースの新しいオープン標準」と説明しています。共同開発はShopify、Etsy、Wayfair、Target、Walmartの5社で、ほかにAdyen、American Express、Best Buy、Flipkart、Macy’s Inc.、Mastercard、Stripe、The Home Depot、Visa、Zalandoなど20社以上が賛同しました。既存のA2A、AP2、MCPと互換であることも同じ記事で明言されています。

UCPの仕組み：プロファイル・capability・トランスポート

/.well-known/ucp に置くビジネスプロファイル

事業者はドメイン直下の /.well-known/ucp にJSONのプロファイルを置きます。次は構造を示す省略例です。必須のURLやpayment handlerのversion、公開鍵の値などを省いているため、そのまま配信できるプロファイルではありません。

{
  "ucp": {
    "version": "2026-08-25",
    "services": {
      "dev.ucp.shopping": [
        { "version": "2026-08-25", "transport": "rest",
          "endpoint": "https://business.example.com/ucp/v1" },
        { "version": "2026-08-25", "transport": "mcp",
          "endpoint": "https://business.example.com/ucp/mcp" }
      ]
    },
    "capabilities": {
      "dev.ucp.shopping.checkout": [ { "version": "2026-08-25" } ],
      "dev.ucp.shopping.discount": [
        { "version": "2026-08-25", "extends": "dev.ucp.shopping.checkout" }
      ]
    },
    "payment_handlers": {
      "com.example.processor_tokenizer": [ { "id": "processor_tokenizer" } ]
    }
  },
  "keys": [ { "kty": "OKP", "crv": "Ed25519", "use": "sig", "alg": "EdDSA" } ]
}

実際のプロファイルでは各項目に spec と schema のURLが付きます。配信方法にも仕様上の決まりがあり、見落とすと接続されません。

• HTTPSで配信する（MUST）
• 3xxのリダイレクトを使わない（MUST NOT）。example.com から www.example.com へ飛ばす構成はそのままでは違反
• Cache-Control に public と60秒以上の max-age を付け、private・no-store・no-cache を付けない（MUST）
• ETag か Last-Modified を付ける（SHOULD）

主要なcapabilityとextensionの役割

capabilityは「チェックアウトできる」「注文を照会できる」といった機能の単位で、逆ドメイン形式の名前と日付形式の版を持ちます。extensionはcapabilityに後付けする機能で、親のcapabilityが交渉で外れると自動的に無効になります。dev.ucp.* はUCPの管理組織だけが使える名前空間で、独自機能を作る事業者は、自社が管理するドメインを逆順にした名前空間を使います。

Identity Linkingは、OAuth 2.0（RFC 6749）とメタデータ公開のRFC 8414に沿ったアカウント連携です。スコープは dev.ucp.shopping.order:read のようにcapability名から作られ、認可コード交換では、公開クライアントに限らずPKCE（S256）が必須です。注文（Order）は、購入された明細、配送の約束と実際の出荷イベント、返金や返品などの調整の3つで構成され、履歴は追記型で残すよう推奨されています。

REST・MCP・A2A・Embeddedの4つのトランスポート

同じ機能を複数の方式で公開できます。どれを使うかはプラットフォーム側が選びます。

MCPとA2Aは、UCPの競合ではなく「運び方」として使われます。MCPの仕組みはMCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組み、A2AはA2A（Agent2Agent）プロトコルの仕組みとMCPとの違いで扱っています。

チェックアウトの状態遷移と人への引き継ぎ

チェックアウトのセッションは、事業者が付ける status で次の段階へ進みます。

• incomplete：情報が足りない。プラットフォームは messages を読み、更新リクエストで埋める
• requires_escalation：APIでは渡せない情報や購入者の判断が要る。continue_url で購入者を事業者の画面へ渡す
• ready_for_complete：必要な情報がそろい、プラットフォームが確定を呼べる
• complete_in_progress：確定を受け付けて処理中。この段階の応答に注文は含まれない
• completed：注文成立。応答に order が入る
• canceled：セッションが無効または期限切れとなった終了状態。購入完了後の注文取消とは別

requires_escalation があるので、年齢確認や独自の規約同意などAPIで表現できない手続きがある店舗でも、そこだけ人の操作に戻せます。すべての購入をエージェント内で完結させる設計ではない点は、導入可否を判断するうえで押さえておくべきところです。

payment handlerによる支払い処理の分離

payment handlerは、支払い手段の処理方法を定めた仕様です。com.google.pay や dev.shopify.shop_pay のように決済事業者が作成し、事業者はプロファイルで使える手段を列挙します。カード番号などの生データはプラットフォームを通らず、トークンでやり取りする設計です。複数の支払い手段を併用する拡張（split_payments）を有効にしない限り、1回の購入で使える支払い手段は1つに限られます。

実在ストアの公開プロファイルで見るUCPの実装

仕様書の例だけでは、実際にどこまで実装されているかが分かりません。そこで、Shopifyで運営されている米国のAllbirds（www.allbirds.com）が公開している /.well-known/ucp を2026年9月28日に取得しました。同じ日に試したEtsy、Wayfair、Target、Walmartのドメイン直下は404で、公開は確認できませんでした（各社は別の経路で接続している可能性があります）。

capabilityは、checkout・cart・order・catalog.search・catalog.lookup・identity_linking・discount・fulfillmentの8つと、Shopify独自の dev.shopify.catalog です。この結果から読み取れることは3つあります。1つ目は、最新版が出た8月25日から約1か月で本番の店舗が新しい版を宣言し、旧版2つも並行して受け付けていることです。版の移行は切り替えではなく併存で進みます。2つ目は、公開プロファイルに載っているトランスポートがMCPとEmbeddedだけで、RESTがないことです。Googleの実装ガイドはRESTのエンドポイントを求めているので、公開プロファイルを見ただけではどのプラットフォームとつながっているかは判断できません。自社の接続状況は、Merchant Centerなど接続先の管理画面で確認してください。3つ目は、dev.shopify.catalog のように自社の名前空間の独自capabilityを dev.ucp.* と並べていることです。拡張は名前空間で分ける、という仕様の設計がそのまま使われています。

UCPとACP・AP2・MCPの違い

UCP・ACP・AP2の違いは、取引の手順と支払いの承認を分けると整理できます。層で分けると、UCPとACPは同じ層で競合する取引の規格、AP2は支払いの証明、MCPとA2Aは通信の方式です。

UCPとACPの違い

ACP（Agentic Commerce Protocol）は、OpenAIとStripeが2025年9月29日に初版を出した規格です。どちらもApache-2.0で日付形式の版を使い、カートやディスカバリの追加で機能は近づいていますが、次の点が異なります。

実装で影響が大きいのは商品データの向きです。ACPの2026-04-17版で追加されたFeed APIは、仕様書に「push model」と明記されており、事業者がエージェント側のフィードへ商品を送り込みます。UCPのcatalog.searchとcatalog.lookupは、エージェントが事業者のエンドポイントへ問い合わせる方式です。UCPでは問い合わせ時点の在庫や価格を返せますが、ACPのFeed APIにも差分更新の操作があり、鮮度はどちらも更新頻度とキャッシュ設計しだいです。違いが出るのは運用の負担で、UCPでは問い合わせを受ける自社エンドポイントの負荷と応答速度を事業者が引き受けます。

採用面の状況は流動的です。OpenAIは2026年3月24日の公式発表「Powering Product Discovery in ChatGPT」で、商品発見に注力し、購入には販売者自身のチェックアウトを使えるようにすると説明しました。より深いネイティブ体験には、ChatGPTアプリという選択肢も示しています。一方、OpenAIの開発者向け資料は現在も「ACPでの開発は誰でも可能、ChatGPTのInstant Checkoutは承認されたパートナーのみ」とし、参加申請のフォームを載せています。ChatGPT内の即時購入を前提にACPを実装する計画は、申請時点の提供形態を確認してから進めてください。なお、StripeはACPの管理者であると同時に、2026年4月28日にUCPのGoverning Councilにも加わっています。決済事業者は両方の規格に関与しているため、どちらか一方が消えるという前提で判断しないほうが安全です。

UCPとAP2の関係

AP2（Agent Payments Protocol）は、エージェントが利用者の代わりに支払ったことを暗号学的に証明する規格です。UCPの仕様書は「UCPはAP2と完全に互換」とし、拡張 dev.ucp.common.payment.ap2_mandate で次の流れを定めています。

1. 事業者はチェックアウトの状態に署名した ap2.merchant_authorization（ペイロード分離形式のJWS）を返す
2. 利用者が同意すると、プラットフォームは事業者の署名を含むチェックアウト応答全体に結び付いた CheckoutMandate と、支払い承認のSD-JWT-VCである PaymentMandate を作る
3. 2つのマンデートを確定リクエストで送り、事業者がCheckoutMandateを、決済代行会社がPaymentMandateを検証する

署名とマンデートの結び付きを検証することで、承認後の取引条件の改ざんを検出できます。トークンの再利用対策には、有効期限や対象取引との対応などの検証も必要です。AP2そのものの仕組みはAP2 (Agent Payments Protocol)とは何か？で解説しています。

GoogleのAIモードとGeminiでのUCP決済：対象国と参加条件

対象国と日本の状況

1月の発表時点では米国だけで、2026年5月20日のGoogle Marketing Liveで「今後数か月でカナダとオーストラリア、その後英国へ展開」と予告されました。現在の公式資料は、ページによって書き方が違います。Merchant Centerヘルプの「ユニバーサル コマース プロトコル（UCP）について」は、冒頭で「米国、カナダ、オーストラリアで対象となる商品、および参加している販売者とパートナーのみを対象としています」としています。一方、2026年9月16日に更新された開発者向けのUCP integration hubの解説は、米国で段階的に展開中でオーストラリアとカナダは「来年初め」、対象は米国内で販売する商品に限る、と書いています。これらは購入機能と管理画面という異なる対象の説明であり、カナダ・オーストラリア向け商品の参加可否はGoogleへの申請時に確認が必要です。英国は両資料の対象国一覧に記載されていません。

日本については、Google日本法人のGoogle Marketing Live 2026の告知が冒頭で「本発表は米国向けのものであり、日本国内における導入時期および展開詳細につきましては、現時点では未定」と書いています。発表の詳細はGoogle Marketing Liveとは？2026年の発表内容と日本で使える時期の見極め方にまとめています。

Merchant Center側の参加条件

• 現時点では一部の販売者のみが対象の早期アクセス方式。Merchant Centerで配送・返品・商品フィードを整えてからウェイトリストに登録し、Googleの承認を受けて公開する
• 購入ボタンが出るのは、商品データに native_commerce(checkout_eligibility) 属性を設定した商品だけ
• Google Pay & ウォレット コンソールのアカウントが必要。自社サイトにGoogle Payボタンを置く必要はない
• 決済代行会社を使わず直接処理する場合は、暗号化の設定とPCI準拠文書の提出が必要
• 現在使える支払い情報は、利用者がGoogleウォレットに保存したカード番号（FPAN）
• 購入はGoogleの画面で完結するが、売り手（Merchant of Record）は販売者のまま

技術面では、Googleの実装ガイドが求めるのは、プロファイルの公開、セッションの作成・更新・確定を担うRESTの3エンドポイント、Googleのwebhookを呼んで注文状態を送る処理の3つです。購入者の識別はゲスト購入が既定で、会員情報を連携する場合だけOAuth 2.0を実装します。

同じヘルプは、Googleの「エージェントによる購入手続き」機能とUCPを区別しています。前者はエージェントが販売者のウェブサイト上で代わりに購入する機能、UCPはエージェントと販売者のバックエンドがAPI・MCP・A2Aで情報を交換する規格です。

Universal Cartとの関係

2026年5月のGoogle I/Oで発表されたUniversal Cartは、複数の店舗の商品を1つのカートにまとめる消費者向けの機能です。UCPはその裏側で店舗とつながる規格にあたり、Universal Cartは米国の検索とGeminiアプリから展開されています。機能の詳細はUniversal Cartの基本定義とGoogleが狙う買い物体験の全体像を参照してください。

仕様のバージョン履歴とv2026-08-25の変更点

UCPの版は YYYY-MM-DD の日付で表し、Tech Councilが承認するたびに release/YYYY-MM-DD ブランチを切ります。旧版のブランチは保守用に残り、原則として後方互換のある変更がバックポートされます。例外的な破壊的変更にはGoverning Councilの承認が必要です。

v2026-08-25は、飲食・宿泊への展開に向けてリポジトリを業種別（shopping・payment・common）に再編した版です。食料品の量り売りに対応する小数の数量、店舗の営業時間、店舗受取の場所情報も入りました。旧版から移行する実装者は、次の破壊的変更を確認してください。

• 配送（fulfillment）の設定名から allows_ 接頭辞が外れ、multi_destination はマップから配列に変わった
• 購入者の同意（buyer consent）が固定の真偽値から、dev.ucp.consent.* をキーにしたマップに変わった
• プロファイルの signing_keys[] が廃止され、署名鍵は keys[]（JWK Set）に一本化された
• 支払い関連の拡張が dev.ucp.shopping.* から dev.ucp.common.payment.* へ移った
• 金額や明細などの共通スキーマが common/types/ に移り、$id のURLが変わった

ガバナンス：Governing CouncilとTech Council

UCPは「Googleの独自規格」と紹介されることがありますが、2026年に入って管理体制が広がっています。UCPのGOVERNANCE.mdによると、最終的な権限を持つGoverning Councilは5席で、GoogleとShopifyが常任の各1席、残り3席は選出制です。Googleはucp.devドメインの管理者を務め、空席分の代理投票権を2028年12月まで持ちます。仕様の中身は業種別のDomain Tech Council（各16席）が決めます。公式の告知ページに載っている変更は次のとおりです。

• 2026年4月24日：Tech Councilを16席に拡大し、Amazon・Meta・Microsoft・Stripe・Salesforceから各1名が加入
• 2026年4月28日：StripeがGoverning Councilに加入
• 2026年7月16日：Food TC発足（Block・DoorDash・Google・Toast・Uber Eats）
• 2026年8月11日：Lodging TC発足（Amadeus・Booking.com・Expedia・Google・Hilton・Marriott・Trip.com）
• 2026年9月2日：Payments TC発足（Adyen・Ant International・Coinbase・Global Payments・Google・PayPal・Shopify・Stripe）

ACPの管理者であるStripeとMetaが、UCPのGoverning CouncilやTech Councilにも席を持っている点は重要です。規格の主導権はGoogleとShopifyにありますが、決済と大手プラットフォームが両方の規格に関与しているため、UCPとACPは片方が他方を置き換える関係にはなっていません。現行ロードマップはインド・アジア太平洋・中南米などへの段階展開を挙げていますが、日本の具体的な提供時期は示していません。

日本のEC事業者・開発者が今やること、まだやらなくてよいこと

日本国内向けのGoogle上のUCPチェックアウトは、提供時期が未定です。その前提で、優先順位ははっきりしています。

• 今やる：価格・在庫・送料・返品条件の元データを整え、Merchant Centerへの登録情報と将来のUCP応答が食い違わないようにする。Google上の購入ボタンも商品データの属性で出し分けられるため、提供開始後もここが前提になります
• 今やる：ShopifyなどUCPに対応したカートシステムを使っている場合は、自社ドメインの /.well-known/ucp が返るか確認する。リダイレクトやキャッシュ設定で仕様違反になっていないかも同時に見る
• まだやらない：自前のUCPサーバーをゼロから実装すること。v2026-08-25には破壊的変更が含まれており、公式SDKもまだ0系です。日本での提供時期が決まる前に作ると、使われないまま移行作業だけが発生します
• まだやらない：UCPとACPのどちらか一方に賭けること。Stripeは2026年1月16日のブログで、Agentic Commerce Suiteの利用者はUCPへの対応に追加の統合が不要で、1回の設定でエージェント向けの規格に対応すると説明しています。こうした複数規格対応の製品を使うか、両方の仕様の差分を自社で追うかを先に決めるほうが、規格の勝ち負けを予想するより確実です

例外は、米国向けに販売している越境ECです。米国内で販売する対象商品であれば早期アクセスの対象になりうるので、Merchant Centerの準備を済ませてウェイトリストに登録する価値があります。カナダ・オーストラリア向けは、購入機能への参加条件とUCP integration hubの利用可否を分けてGoogleに確認してください。

よくある質問

UCPは何の略ですか？読み方は？

Universal Commerce Protocolの略で、日本語ではユニバーサルコマースプロトコルと読みます。Googleの日本語ヘルプも「ユニバーサル コマース プロトコル」と表記しています。電気や食品の分野にも同じ「UCP」という略語がありますが、この記事で扱っているのはAIエージェント向けのコマース規格です。

UCPで使える支払い方法は何ですか？

Google上のチェックアウトで現在使えるのは、Googleウォレットに保存されたカード情報によるGoogle Pay決済です。1月の発表ではPayPalへの対応が予告されていました。規格としては、決済事業者がpayment handlerを作れば支払い手段を追加できる設計で、Allbirdsのプロファイルには com.google.pay と並んでShopifyのカード決済とShop Payが載っていました。

UCPを試すための公式SDKやサンプルはありますか？

GitHubの Universal-Commerce-Protocol 組織に、Python SDK（PyPIの ucp-sdk 0.5.0、2026年8月27日公開）とJavaScript SDK（npmの @ucp-js/sdk 0.5.1、2026年9月2日公開）、サンプル、適合性テスト、スキーマ検証ツールがあります。どちらのSDKも0系なので、仕様の版が上がると互換性が崩れる前提で版を固定して使ってください。

ShopifyのストアはUCPに対応していますか？

ShopifyはUCPの共同開発企業で、Governing Councilの常任メンバーです。Shopifyで運営されているAllbirdsは、実際にUCPプロファイルを公開していました（上の実測の章を参照）。ただし、日本のストアがGoogle上で購入ボタンを表示できるかは、UCPの対応とは別にGoogle側の対象国の条件で決まります。

UCPに対応すると自社ECサイトは不要になりますか？

なりません。UCPでも売り手は事業者のままで、requires_escalation の状態では購入者を事業者の画面へ戻します。Google上のチェックアウトは一部の国と販売者に限られており、UCPは自社サイトに加わる販売チャネルとして考えるのが現実的です。

関連記事

• AP2 (Agent Payments Protocol)とは何か？ 新たな決済プロトコルの概要と意義と背景
• A2A（Agent2Agent）プロトコルとは？v1.0の仕組み・MCPとの違い・実装手順
• Universal Cartの基本定義とGoogleが狙う買い物体験の全体像
• エージェンティックコマースとは何か？次世代のEコマースとしてのAIエージェント購買の全貌を詳しく解説
• AIエージェントが自律決済する時代に登場したMPPの全体像と設計背景