Googleのユニバーサルカートが米国で開始。UCP対応の2経路と日本側の備え

Googleは2026年10月15日、ユニバーサルカート（Universal Cart）の提供を始めたと公表しました。公式ブログの書き方は「Today, Universal Cart is rolling out in the U.S. across Google Search and in the Gemini app」で、対象は米国、出る場所はGoogle検索とGeminiアプリです。複数の小売店の商品を1つのカートへ入れておけること、値下がりや在庫の復活を通知で知らせること、そしてカートの中で決済まで済ませられることが説明されています。

買い物客の側の話として読むとそれで終わりますが、売り場の側には別の論点があります。公式ブログには「effortless checkout powered by the Universal Commerce Protocol (UCP)」とあり、この決済はユニバーサル・コマース・プロトコル（UCP）という公開仕様の上で動いています。つまり加盟店にとっては、自社の商品が入ったカートの決済を、どの経路で受けるかを選んで申告する作業が発生します。カートが増えたという話ではなく、売り場の接続方式が1つ追加された、という読み方になります。

ただし日本はまだ対象として書かれていません。Merchant Centerのヘルプが挙げている対象国は米国・カナダ・オーストラリアで、申告の入口となる統合ハブについては、米国で段階的に提供し、オーストラリアとカナダは来年初めに続くと書かれています。日本での提供時期の記載はありません。そのため、この記事で扱うのは実装の手順書ではなく、公表された仕様から今日のうちに決めておけることです。出典はGoogleの公式ブログ、Merchant Centerの公式ヘルプ、Google for Developersの公式ドキュメント、Google Developers Blogで、確認日は2026年10月20日です。英語の発表と英語のドキュメントを読んでいるため、日本語の管理画面では語が違うことがあります。

買い物客の画面で何が起きると書かれているか

まず、公式ブログに書かれている動作だけを並べます。ここに自社の期待を混ぜないことが、あとの判断を楽にします。

書かれている動作	発表の記載
複数店舗の商品を1つのカートへ	お気に入りの店の商品を同じカートへ保存できる
値下がり・在庫の通知	背景で先回りして動き、値下がりや在庫の復活を通知する
支払い方法の提案	カードの特典に応じた支払い方法を提案する
カートの中での決済	多くの店について、Google Payで数タップで決済できる
自社サイトでの決済	商品を加盟店のカートへ移送して、その店のサイトで買える
土台になっているデータ	Shopping Graphの「60+ billion」の継続更新される商品リスト

通知の部分は、カートの役割が変わったところだと読めます。これまでのカートは買い物客が戻ってくるまで待つ置き場でしたが、発表の説明では値下がりと在庫を見張って知らせる側に回っています。買い物客が自社サイトを再訪しなくても、Googleの画面の側で「買い直す理由」が提示されるということです。

いっぽうで、流通額や転換率がどう動くかは書かれていません。公式ブログに出てくる具体的な名前は、カートの中での決済を試せる小売店として挙げられたNike、Sephora、Target、Ulta Beauty、Walmart、Wayfair、Steve Madden、Quince、そしてShopifyの加盟店です。対象が「選ばれた加盟店」である点は、ヘルプ側でも select merchants と書かれています。誰でも今日から購入ボタンが出るわけではありません。

決済は2つの経路に分かれる

公式ブログの説明は「You can securely check out with Google Pay in just a few taps with many of your favorite stores right in the cart, or you can transfer your items directly to the merchant’s cart to finish buying on their site」です。前半がGoogleの画面で完結する経路、後半が自社サイトへ移送する経路になります。

重要なのは、そのあとに続く一文です。「Either way, you will receive direct confirmations and customer support from the merchant, and they will remain the seller of record」と書かれています。どちらの経路でも、注文確認とカスタマーサポートは加盟店が行い、加盟店が販売者として残ります。開発者向けのドキュメントでは merchant of record という語が使われており、こちらにも「you own your business logic, and you remain the Merchant of Record」とあります。表記は2通りありますが、販売の責任が加盟店の側にあるという点は共通しています。

移送の経路については、できることの範囲がはっきり限定されています。Cart APIのドキュメントには「This initial release is limited to cart creation and transfer using the CreateCart method. Features like updating, deleting, or synchronizing cart contents between Google and your system are not supported」と書かれています。移送は一方向で、カートの中身を双方で同期する仕組みは用意されていません。Googleの画面でカートを編集し直せば、その結果がまた移送されてくる、という作りだと理解しておくほうが安全です。応答速度についても、1秒未満を目標とし、超えても失敗にはならないが体験が落ちると書かれています。

実務上の分かれ目は、計測と顧客接点です。Googleの画面で決済まで終わる経路では、買い物客が自社サイトを訪れないまま注文が立ちます。自社サイトのカートを前提に作ってきた計測や、カート放棄への追客は、その注文を拾えません。移送の経路なら、決済画面は自社のままなので、既存の計測はそのまま効きます。どちらを選ぶかは、実装の難易度ではなく、注文がどこで立つかの話です。同じ構図は他のプラットフォームでも出ており、TikTokの例はTikTokの広告がエージェント前提へ。Buy Direct・TTAN・MCPで変わることで扱っています。

対応の入口はMerchant Centerの「UCP integration」

ドキュメントによると、入口はMerchant Centerの設定にある「UCP integration」です。ここで申告するのは、自社が対応できる capability（できること）で、挙げられているのは「I support transfer to merchant cart」（自社カートへの移送に対応）、「I support native checkout on Google」（Google上での決済に対応）、そして「I support identity linking」（ID連携。coming soon と記載）の3つです。

このうち移送の経路については、商品フィードを全量そろえる要件を回避できる streamlined path だと説明されています。フィードの整備が終わっていなくても、移送だけなら先に手を挙げられる形になっているということです。逆にGoogle上での決済は、決済用のAPIエンドポイントを実装して初めて選べます。

決済まわりの前提も具体的に書かれています。購入ボタンが出るのは native_commerce(checkout_eligibility) という商品属性を持つ商品リストだけで、支払いはGoogle Walletに保存済みの支払い方法と配送情報を使うGoogle Payです。加盟店側は Google Pay & Wallet Console のアカウントを作る必要があり、決済事業者（PSP）の側にGoogle Pay APIの対応が求められる場合があると書かれています。自社で直接つなぐ場合は、暗号化の設定とPCI準拠の書類が必要だという記述もあります。

準備として挙げられているのは、ステージングと本番で分けたAPIキー、UCPプロファイルの場所（/.well-known/ucp）、テスト用のトークンです。段取りは、仕様と技術要件を理解する、サンドボックスで安全に試す、本番へ移して capability を検証する、という3段構えで、概要ページの側では、Merchant Centerの準備、UCPプロファイルの準備、認証の設定、中核の実装の選択、拡張の capability の追加という順に分けられています。申告してすぐ出るのではなく、本番で動作を検証する段が明示されている点は、社内の工程表を引くときに効いてきます。

土台はUCPという1枚の共通仕様

UCPそのものの設計は、開発者向けブログに説明があります。加盟店は /.well-known/ucp にJSONのマニフェストを置いて自社の capability を公開し、エージェントの側がそれを読んで、何ができるかを動的に把握します。接続の口はRESTのAPIに加えて、Agent-to-Agent（A2A）とModel Context Protocol（MCP）のバインディングが挙げられています。設計の狙いとして書かれているのは「collapses N x N complexity into a single integration point for all consumer surfaces」、つまり接続先ごとに個別対応していた組み合わせを、1つの接続点へ畳むことです。

この狙いは、売り場の側にとっては両面があります。接続の手間が1本にまとまるのは利点ですが、1本にまとまるほど、その1本の仕様に自社の売り方が左右されます。カートの capability は dev.ucp.shopping.cart という名前で、使うには版 2026-04-08 以降が必要だと書かれています。認証はAPIキー、OAuth、相互TLSから選べます。仕様に版が付いているということは、更新に追随する運用が前提になるということでもあります。

関わっている会社の名前も公表されています。Googleが協力したと挙げているのはShopify、Etsy、Wayfair、Target、Walmartで、仕様を支持する over 20 global partners として、Adyen、American Express、Best Buy、Flipkart、Macy’s Inc、Mastercard、Stripe、The Home Depot、Visa、Zalandoなどが挙げられています。決済側とカード会社が並んでいるところが、この仕様の性格を表しています。商品の見せ方の規格ではなく、決済までを含む規格として作られています。

発表とドキュメントに書かれていないこと

推測で埋めないために、確認したかったのに記載がなかった項目を残します。

確認したかった項目	記載	どうするか
日本での提供時期	記載がありません。対象として挙がっているのは米国・カナダ・オーストラリア	日本での提供を前提に工程を組まない
購入ボタンが出る加盟店の選定基準	記載がありません。select merchants とだけ書かれています	自社が対象になる条件を自分で決めつけない
手数料や取り分	記載がありません	費用の試算を社内資料に書かない
流通額や転換率への影響	記載がありません	効果の見込みを数値で置かない
Google上で決済した顧客の情報の扱い	今回読んだ範囲には、受け渡しの詳細な記述がありません	顧客データの前提を仕様で確認してから設計する
検索とGeminiアプリ以外の面	記載がありません	他の面への展開を想定しない

書かれていない項目が多いのは、提供が始まった直後の発表では普通のことです。問題が起きるのは、空欄を社内の要約で埋めてしまうときです。「Googleのカートに載せれば売れる」「日本でも始まった」と要約して回すと、あとで前提から訂正することになります。記載と見立ては、別の行に分けて書いてください。

日本の実務者が先に決める3つのこと

対象国に入っていないため、今日から実装する作業はありません。それでも先に決めておけることが3つあります。

第一に、どちらの経路を望むのかを、計測の観点から先に議論しておくことです。Googleの画面で注文が立つ経路を選ぶと、自社サイトの訪問を前提にした計測や追客の設計が一部そのままでは使えません。移送の経路なら既存の計測が効きますが、決済まで進む場所が1つ増えるわけではありません。これは実装の話ではなく、どこで顧客に会うかという方針の話なので、対象国に入ってから考え始めると間に合いません。レポートの定義が変わるだけで数字の読み方が変わる例はMerchant Centerの計測定義が8月に変わる｜オーガニックが落ちて見える理由で扱っています。

第二に、商品データの正確さを属性の単位で見直すことです。購入ボタンの可否が商品属性で決まる作りになっている以上、価格、在庫、配送、識別子の整合が取れていない商品は、仕組みが来ても対象外のまま残ります。native_commerce のような属性は対象国でなければ使えませんが、価格と在庫の正確さは今日から効きます。エージェントが商品を選ぶ前提での情報整備はAIが買い物をする時代へ。Microsoftが示した3段階の備えでも扱った論点で、プラットフォームが違っても作業の中身は重なります。

第三に、決済事業者（PSP）に確認を取っておくことです。Google上での決済はGoogle Payのトークンを前提にしており、PSP側の対応が求められる場合があると書かれています。契約している事業者がどこまで対応しているかは、自社では決められません。問い合わせの返事を待つ時間は、対象国が増えてから取り始めると、そのまま遅れになります。

最後に、読み間違えやすい点をもう一度書いておきます。今回の発表は、カートの提供開始と、その土台になる仕様の公開です。売上が増えると書かれている箇所はありません。AIの画面からウェブへ出ていく経路そのものの変化はGoogleがAI検索のリンクを前へ。5つの変更と日本側の備えで扱っています。カートの側は、そこから先の決済が自社の画面を通らない場合がある、という変化です。自社で決めるべきことは、対応するかどうかよりも先に、注文をどこで受けたいのかという点にあります。