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年10月25日時点のリリース済み最新版は v2026-08-25 です。

店舗は /.well-known/ucp に対応機能を書いたプロファイルを置き、エージェントはそれを読んで取引を進めます。日本向けのShopifyストアでも、このプロファイルはすでに返ってきます。一方で、Google検索のAIモードやGeminiでUCPを使って購入できるのは米国などの対象商品だけで、日本での提供時期は発表されていません。この記事では、仕様書と公式サンプルの実行結果、実在ストアのプロファイルをもとに、仕組み・試し方・ACPとAP2との違い・日本の事業者の判断を整理します。

まとめ：UCPとは何か、仕組みと日本での位置付けの要点

• 定義：AIエージェントなどの「Platform」と、店舗などの「Business」の間で、商品検索から決済・注文後の管理までをやり取りする共通規格。GoogleとShopifyが常任席を持つGoverning Councilが管理する
• 仕組み：店舗が /.well-known/ucp にcapability（機能）と接続先を宣言し、エージェントのプロファイルと突き合わせて使える機能を決める。運び方はREST・MCP・A2A・Embeddedの4つ
• 試し方：公開プロファイルは認証なしのGETで取れる。公式サンプルのサーバーは手元で数分で動くが、2026年10月25日時点では1つ前の版（v2026-04-08）のまま
• ACPとの違い：ACPはOpenAIとStripeが主導する同じ層の規格。商品データをUCPはエージェントが取りに行き、ACPのFeed APIは店舗がエージェント側へ送る
• AP2との関係：AP2は支払いの承認を証明する別の規格で、UCPは拡張でAP2のマンデートを受け取る
• 日本の状況：Google上の購入は日本では未提供。ただしShopifyの国内ストアはプロファイルを公開済みで、GMOペイメントゲートウェイはUCP採用の決済ソリューションを構築し、国内のECカート8種との連携を予定している

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

UCPが解こうとしているのは、エージェントと店舗の連携が組み合わせの数だけ必要になる問題です。エージェントが10種類、店舗が1万あれば、個別連携では組ごとに実装が発生します。UCPでは店舗が対応機能を共通の形式で宣言し、エージェントはそれを読んで同じ手順で注文を進めます。ただし、注文まで進めるかどうかは店舗側の認証やアクセス条件でも決まります。Shopifyは、エージェントの識別の強さに応じてUCPのアクセスを3段階に分け、使えるツールと流量の上限を変えています。

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

AIエージェントが利用者に代わって商品を探し、比べ、購入まで進める取引はエージェンティックコマースと呼ばれます。そこで要る取り決めは「どの店が何をどう売っているか」「本人が支払いを承認したとどう証明するか」「何の通信方式で話すか」に分かれ、UCPが受け持つのは1つ目です。支払いの証明はAP2、通信方式はMCPやA2Aに任せます。

共同開発企業と賛同企業

Googleの発表記事（2026年1月11日、全米小売業協会の年次イベントNRFに合わせて公開）によると、共同開発は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・トランスポートの3要素

/.well-known/ucp のプロファイルと配信ルール

店舗はドメイン直下の /.well-known/ucp にJSONのプロファイルを置きます。次は構造を示す省略例で、各項目の spec・schema のURLや鍵の値を省いているため、そのまま配信できるものではありません。

{
  "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" } ]
}

配信方法にも決まりがあり、外すとエージェントから接続されません。

• 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の管理組織だけが使う名前空間で、独自機能を作る事業者は自社ドメインを逆順にした名前空間（Shopifyなら dev.shopify.*）を使います。

表の名前はすべて dev.ucp. で始まります。permalink は https://merchant.example/buy/sku_123:2,sku_456:1 のように商品IDと数量をURLに並べてカートを初期化する機能で、仕様書はpermalinkを開いたことを注文確定や課金の承認として扱ってはならない（MUST NOT）と定めています。Identity LinkingはOAuth 2.0とRFC 8414に沿い、認可コード交換ではPKCE（S256）が必須です。

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

同じ機能を複数の方式で公開でき、どれを使うかはPlatformが選びます。MCPの仕組みはMCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説、A2AはA2A（Agent2Agent）プロトコルとは？v1.0の仕組み・MCPとの違い・実装手順で扱っています。

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

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

requires_escalation があるため、年齢確認や独自の規約同意のようにAPIで表せない手続きがある店舗でも、そこだけ人の操作に戻せます。すべての購入をエージェント内で完結させる設計ではありません。

payment handlerと支払い手段

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

UCPを試す：公開プロファイルの検査と公式サンプルの実行

Pythonによる公開プロファイルの配信ルール検査

公開プロファイルは認証なしのGETで取れます。次のスクリプトは、リダイレクト禁止・Cache-Control・ETag または Last-Modified を検査し、版・トランスポート・capability・payment handlerを一覧にします。標準ライブラリだけで動き、必須（MUST）の違反があれば終了コード1を返し、推奨（SHOULD）の ETag などが無いときは警告だけを出します。定期ジョブにも組み込めます。

import json
import re
import sys
import urllib.error
import urllib.request


class NoRedirect(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, *args, **kwargs):
        return None  # 3xxを追わずにエラーとして受け取る


def check(domain):
    url = f"https://{domain}/.well-known/ucp"
    opener = urllib.request.build_opener(NoRedirect)
    req = urllib.request.Request(url, headers={
        "Accept": "application/json", "User-Agent": "ucp-profile-check/0.1"})
    try:
        res = opener.open(req, timeout=20)
    except urllib.error.HTTPError as e:
        print(f"NG: status={e.code} Location={e.headers.get('Location')}")
        return 1

    problems = []
    cc = (res.headers.get("Cache-Control") or "").lower()
    m = re.search(r'(?:^|,)\s*max-age\s*=\s*"?(\d+)"?\s*(?=,|$)', cc)
    if not re.search(r"(?:^|,)\s*public\s*(?=,|$)", cc):
        problems.append("Cache-Controlにpublicがない")
    if not m or int(m.group(1)) < 60:
        problems.append("max-ageが未指定または60秒未満")
    for bad in ("private", "no-store", "no-cache"):
        if bad in cc:
            problems.append(f"Cache-Controlに{bad}が付いている")
    if not (res.headers.get("ETag") or res.headers.get("Last-Modified")):
        print("WARN: ETagとLast-Modifiedがない（SHOULD）")

    ucp = json.load(res)["ucp"]
    services = ucp.get("services", {})
    print("version:", ucp.get("version"))
    print("transports:", sorted({s.get("transport") for v in services.values() for s in v}))
    print("capabilities:")
    for name in sorted(ucp.get("capabilities", {})):
        print("  ", name)
    print("payment_handlers:", sorted(ucp.get("payment_handlers", {})))
    for p in problems:
        print("NG:", p)
    return 1 if problems else 0


if __name__ == "__main__":
    sys.exit(check(sys.argv[1]))

ucp_check.py として保存し、python ucp_check.py jp.bonaventura.shop のようにドメインを渡します。2026年10月25日に日本向けのShopifyストアで実行した結果は次のとおりで、違反はなく終了コードは0でした。UCPを公開していないドメインでは NG: status=404 と表示して1を返します。

version: 2026-08-25
transports: ['embedded', 'mcp']
capabilities:
   dev.shopify.catalog
   dev.ucp.common.identity_linking
   dev.ucp.shopping.buyer_consent
   dev.ucp.shopping.cart
   dev.ucp.shopping.catalog.lookup
   dev.ucp.shopping.catalog.search
   dev.ucp.shopping.checkout
   dev.ucp.shopping.discount
   dev.ucp.shopping.fulfillment
   dev.ucp.shopping.order
   dev.ucp.shopping.permalink
payment_handlers: ['com.google.pay', 'dev.shopify.card', 'dev.shopify.shop_pay']

公式サンプルサーバーのローカル実行

取引の流れまで確かめるなら、公式のサンプル集にある花屋のサーバー（Python・FastAPI）が手早い方法です。READMEの手順は次の4つで、パッケージ管理ツールのuvが要ります。

git clone https://github.com/Universal-Commerce-Protocol/samples.git
cd samples/rest/python/server
uv sync
mkdir -p /tmp/ucp_test
uv run import_csv.py --products_db_path=/tmp/ucp_test/products.db \
  --transactions_db_path=/tmp/ucp_test/transactions.db \
  --data_dir=../test_data/flower_shop
uv run server.py --products_db_path=/tmp/ucp_test/products.db \
  --transactions_db_path=/tmp/ucp_test/transactions.db --port=8182

別の端末で samples/rest/python/client/flower_shop に移り、uv run simple_happy_path_client.py --server_url=http://localhost:8182 を実行すると、プロファイル取得→カート作成→商品追加→割引コード適用→チェックアウト作成→配送先と配送方法の選択→確定の順に進みます。2026年10月25日に実行したところ、合計は3,500→6,500→5,850セント（10%割引）と変わり、確定の応答で status: completed と注文IDが返りました。

ここで注意が要るのは版です。このサンプルのプロファイルは "version": "2026-04-08" を返し、署名鍵を signing_keys に載せていました。依存しているPython SDKも ucp-sdk 0.4.6（>=0.4.6,<0.5 の指定）です。signing_keys は最新版のv2026-08-25で廃止され、keys に一本化されています。サンプルをそのまま土台にすると1つ前の版の実装になるので、最新版で作るならPyPIのucp-sdkの0.5.0（2026年8月27日公開）以降と仕様書を基準にしてください。JavaScript版の @ucp-js/sdk は0.5.1（2026年9月2日公開）が最新です。仕様への適合は適合性テスト（UCP Conformance Test Suite）で確かめます。

チェックアウトAPIの必須ヘッダとエラーの返り方

仕様書のCheckout REST Bindingでは、作成は POST /checkout-sessions、更新は PUT /checkout-sessions/{id}、確定は POST /checkout-sessions/{id}/complete です。サンプルのサーバーに標準ライブラリだけのスクリプトでリクエストを送り、ヘッダや本文を変えて応答を記録しました（2026年10月25日）。

この結果から、実装で押さえる点は3つに絞れます。

• UCP-Agent は全リクエストで必須。値は自社Platformのプロファイルの場所（profile="https://…"）で、店舗はこれを取得して対応範囲を突き合わせる
• 状態を変える操作には Idempotency-Key を付ける。仕様は、対応する店舗が結果を24時間以上保持し、同じキーで本文が違えば409を返すと定めており、サンプルもそのとおりに動いた
• エラーの返り方は実装で揃っていない。仕様は在庫切れなどの業務上の結果をHTTP 200と messages 配列で返し、全商品が買えないときも200のエラー応答とする。サンプルは存在しない商品IDに400を返した。Platform側は200の messages と4xxの両方を処理する作りにしておく

更新（PUT）は差分ではなく全体の置き換えで、RESTのエンドポイントはTLS 1.3以上のHTTPSで提供することも仕様に書かれています。

実在ストアの公開プロファイル：米国と日本のShopifyストアの比較

仕様書の例だけでは、実際にどこまで実装されているかが分かりません。Shopifyで運営されている米国のAllbirds（www.allbirds.com）のプロファイルを2026年9月28日・10月15日・10月25日の3回取得し、10月25日には日本向けのShopifyストア2店（jp.bonaventura.shop・www.kakimori.com）も取得しました。

日本向けの2店は、capabilityもpayment handler（Google Pay・Shopifyのカード・Shop Pay）も同じ内容でした。Allbirds米国には10月15日から25日までの間に dev.ucp.common.location.search と .lookup（実店舗の検索）が加わり、日本向けの2店より2つ多くなっています。Etsy、Wayfair、Target、Walmartのドメイン直下は、9月28日と10月25日のどちらも404でした。

ここから読み取れることは4つです。

• Shopifyのストアは、店舗が何もしなくてもプロファイルを公開している。日本向けのストアも例外ではなく、旧版2つ（2026-04-08・2026-01-23）も supported_versions で並行して受け付けている
• プロファイルがあることと、Googleで買えることは別。日本向けのストアがプロファイルを返していても、Google上の購入ボタンは対象国と承認の条件で決まる
• RESTは公開されていない。載っているのはMCPとEmbeddedだけで、Googleの実装ガイドが求めるRESTのエンドポイントは見えない。どのPlatformとつながっているかは、公開プロファイルでは判断できない
• 中身は数週間単位で変わる。capabilityは1か月で9から13に増えた。プロファイルは固定の設定ではなく、カートシステムの更新に合わせて変わる前提で監視する

UCPとACP・AP2・MCPの違いと取引・支払い・通信の役割分担

層で分けると、UCPとACPは同じ層で競合する取引の規格、AP2は支払いの証明、MCPとA2Aは通信の方式です。

UCPとACPの違い

ACP（Agentic Commerce Protocol）は、OpenAIとStripeが2025年9月29日に初版を出した規格で、仕様はagenticcommerce.devで公開されています。どちらもApache-2.0で日付形式の版を使いますが、次の点が異なります。

実装で影響が大きいのは商品データの向きです。ACPの2026-04-17版で入ったFeed APIは、仕様書に「push model」と明記されており、店舗がエージェント側のフィードへ商品を送ります。UCPのcatalog.searchとcatalog.lookupは、エージェントが店舗のエンドポイントへ問い合わせる方式です。UCPでは問い合わせの負荷と応答速度を店舗が引き受けることになります。

ChatGPT側の購入導線は変わりました。OpenAIは2026年3月24日の公式発表「Powering Product Discovery in ChatGPT」で、商品の発見に力を入れ、購入には販売者自身のチェックアウトを使えるようにすると説明しています。OpenAIのプラグイン指針は、ChatGPT内のInstant Checkoutを一部のマーケットプレイス向けのbetaとしています。ACPでChatGPT内の即時購入を前提にした計画は、申請時点の提供形態を確かめてから進めてください。

UCPとAP2の関係

AP2（Agent Payments Protocol）は、エージェントによる購入・支払いについて、利用者の承認と取引条件との結び付きを暗号学的に検証するための規格です。UCPの仕様書はAP2との互換を掲げ、拡張 dev.ucp.common.payment.ap2_mandate で次の流れを定めています。

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

署名とマンデートの結び付きを検証することで、承認後の取引条件の改ざんを検出できます。AP2そのものはAP2（Agent Payments Protocol）とは？v0.2のマンデートとx402・ACP・UCPとの違い、機械同士の少額決済の規格はMPP（Machine Payments Protocol）とは？HTTP 402の仕組みとx402との違い・Stripeでの実装【2026年10月】で解説しています。

UCPとMCP・A2Aの関係

MCPとA2Aは、UCPと同じ層で比べる相手ではありません。プロファイルで "transport": "mcp" を宣言すると、checkoutなどの操作がMCPのツールとして公開され、MCPクライアントを持つエージェントはそのまま呼び出せます。選ぶのは「UCPかMCPか」ではなく「UCPの取引をMCPで運ぶか、RESTで運ぶか」です。上の実測のとおり、Shopifyのストアはエージェント向けにMCP、Webの購入画面にEmbeddedを出しています。

UCPに対応した購入面：Google・Microsoftの対象国と参加条件

GoogleのAIモードとGemini：対象国と日本の状況

Googleの開発者向けトップページは、UCPの利用面をGoogle検索のAIモードとGeminiのWeb版とし、Geminiアプリは「coming soon」と書いています。対象国の書き方はページで異なります。Merchant Centerヘルプの「ユニバーサル コマース プロトコル（UCP）について」は、米国・カナダ・オーストラリアで対象となる商品と参加販売者を対象にしています。一方、2026年10月19日に更新された開発者向けのUCP integration hubの解説は、管理画面のintegration hubを米国で段階展開中、オーストラリアとカナダは来年初めとしています。前者は購入機能、後者は管理画面の説明なので、カナダ・オーストラリア向け商品の参加可否は申請時にGoogleへ確認が必要です。

日本については、Google日本法人のGoogle Marketing Live 2026の告知が「本発表は米国向けのものであり、日本国内における導入時期および展開詳細につきましては、現時点では未定」と書いています。発表内容はGoogle Marketing Liveとは？2026年の発表内容と日本で使える時期の見極め方にまとめました。複数の店舗の商品を1つのカートにまとめる消費者向けの機能は、Universal Cartとは？Googleの買い物カートの機能と米国での提供状況・販売店の対応【2026年10月】で扱っています。

Merchant Center側の参加条件

• 一部の販売者が対象の早期アクセス方式。配送・返品・商品フィードを整えてからウェイトリストに登録し、Googleの承認を受けて公開する
• 購入ボタンが出るのは、商品データに native_commerce(checkout_eligibility) 属性を設定した商品だけ
• Google Pay & ウォレット コンソールのアカウントが必要。自社サイトにGoogle Payボタンを置く必要はない
• 決済代行会社を使わず直接処理する場合は、暗号化の設定とPCI準拠文書の提出が必要
• 技術面では、プロファイルの公開、セッションの作成・更新・確定のREST、Googleのwebhookへ注文状態を送る処理の3つを実装する

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

Microsoft Copilot CheckoutのUCP対応

Microsoftは2026年4月21日の発表で、Microsoft Merchant CenterのUCP-ready feedsへの対応を米国で一般提供したと公表しました。Copilot Checkoutは1月の開始時にACPを採用していたので、Microsoftは両方の規格を受ける側に回ったことになります。Microsoftの案内ページによると、Copilot CheckoutはCopilot.comとモバイルアプリで提供され、対象は米国の購入者にUSDで販売する英語対応の販売者です。設定の詳細はCopilot Checkoutとは？Brand Agentsとの違い・Shopifyでの設定と日本からの利用条件を参照してください。

仕様のバージョン履歴と未リリースの変更候補

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.* へ移った

正式版にはまだ入っていない変更も、mainブランチに追加されています（2026年10月25日時点）。次の版に収録されるかは確定していません。9月24日に宿泊予約のcapability（dev.ucp.lodging.booking）とキャンセルポリシーの拡張が草案として入り、仕様書はデータモデルや処理フローに破壊的変更がありうると断っています。10月7日（UTC）には自然言語の質問に答える dev.ucp.common.ask、10月23日には機械可読な返品条件を表す拡張（dev.ucp.shopping.policy.return）が加わりました。返品条件をカタログから注文まで構造化データで持てるようになるため、返品条件を商品ページの文章だけで示している店舗は、データとして整える準備を始める価値があります。

ガバナンス：Governing CouncilとTech Councilの体制

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

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

ACPの管理者であるStripeとMetaがUCP側にも席を持っています。決済事業者と大手プラットフォームが両方の規格に関与しているため、UCPとACPはどちらかが他方を置き換える関係にはなっていません。

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

国内でも決済の土台は動いています。GMOペイメントゲートウェイは2026年8月6日、「PGマルチペイメントサービス」でUCPを採用した独自の決済ソリューションの構築を2026年6月に完了したと発表しました。連携予定のECカートとして、ecbeing、カラーミーショップ、makeshop、GMOクラウドEC、ecforce、F.ACE、W2 Commerce、メルカートの8種を挙げています（対応範囲と時期はカートごとに順次案内）。カード会社側では、Visaが2026年4月30日にイシュア向けの検証プログラム「Visa Agentic Ready」を始め、日本ではSBペイメントサービス、クレディセゾン、三井住友カード、三菱UFJニコス、楽天カードの5社が参加を表明しています。

ただし、日本の消費者がGoogle上でUCPを使って買える時期は未定です。その前提で、優先順位ははっきりしています。

• 今やる：価格・在庫・送料・返品条件の元データを整え、Merchant Centerの登録情報と将来のUCP応答が食い違わないようにする。返品条件の構造化拡張が未リリースの仕様に加わっているため、正式採用の動向を確認しつつ、返品条件を画像やPDFだけで示している場合は文章とデータに起こす
• 今やる：Shopifyを使っているなら、自社ドメインの /.well-known/ucp を上の検査スクリプトで確認する。独自ドメインへのリダイレクトやキャッシュ設定で違反していないか、何が公開されているかを把握しておく
• 今やる：上の8種のカートを使っているなら、カート事業者とGMOペイメントゲートウェイの案内を確認する。自前で実装するより、カート側の対応を待つほうが移行の手間が少ない
• まだやらない：自前のUCPサーバーをゼロから作ること。v2026-08-25には破壊的変更が入り、公式SDKは0系、公式サンプルも最新版に追いついていない。国内提供の時期が決まる前に作ると、使われないまま移行作業だけが発生する
• まだやらない：UCPとACPのどちらか一方に賭けること。MicrosoftのCopilotは両方を受け、Stripeは両方の管理に加わっている。複数規格に対応する決済やカートの製品を使うか、両方の差分を自社で追うかを先に決める

例外は米国向けの越境ECです。米国内で販売する対象商品なら早期アクセスの対象になりうるので、Merchant Centerの準備を済ませてウェイトリストに登録する価値があります。UCPに対応しても売り手は店舗のままで、requires_escalation やpermalinkでは購入者を店舗の画面へ戻すため、自社ECサイトが不要になるわけではありません。

自社でUCPを実装するか判断する条件

カートシステムの標準機能に任せず、自社で実装に踏み込む価値があるのは2つの場合です。1つは、UCP対応のカートを使わず、独自開発のEC基盤や基幹システムと在庫・価格を直結している場合です。ECサイトの構造そのものに関わるので、ECサイト構築とは？5つの構築方法の費用相場と、自社に合う進め方の判断軸を解説で整理している構築方式の選び直しとあわせて検討します。もう1つは、自社の購買エージェントや社内調達システムから取引先のUCPエンドポイントを呼ぶ側（Platform）になる場合です。プロファイルの取得、capabilityの交渉、チェックアウトの往復とエラー処理を扱うエージェント側の設計になり、一創のAIエージェント開発でも相談を受け付けています。

国内だけで販売していて、Shopifyなど対応済みのカートを使っている事業者は、自前実装を急ぐ理由がありません。プロファイルの監視と商品データの整備にとどめ、Googleの国内提供条件が発表された段階で、カート事業者の対応予定と必要な準備期間を確認して判断できます。

よくある質問

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

Universal Commerce Protocolの略で、ユニバーサルコマースプロトコルと読みます。Googleの日本語ヘルプも「ユニバーサル コマース プロトコル」と表記しています。電気や食品の分野にも「UCP」という略語がありますが、2026年に話題になっているのはこのコマース規格です。

UCP対応とはどういう意味ですか？

店舗が /.well-known/ucp にプロファイルを公開し、UCPの手順でカートやチェックアウトの操作を受け付けられる状態を指します。決済事業者やカート事業者が「UCP対応」と言う場合は、その製品を使う店舗がこの状態になれるという意味です。UCPに対応していても、GoogleのAIモードで購入ボタンが出るかは、対象国とGoogleの承認という別の条件で決まります。

UCPとAIはどういう関係ですか？

UCPはAIエージェントが買い物を進めるときの共通の手順です。AIエージェントが利用者の依頼を受けて店舗のプロファイルを読み、商品を検索し、チェックアウトを作って確定まで進めます。AIそのものではなく、AIと店舗のシステムをつなぐ取り決めにあたります。

GoogleはUCPを廃止したのですか？

廃止されていません。英語圏の投稿の「Google just dropped UCP」（GoogleがUCPを公開した）が「廃止」と機械翻訳された例があります。仕様は2026年8月25日に最新版が出て、その後もmainブランチへの変更が続いています。

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

プロファイルの公開という意味では対応しています。2026年10月25日に確認した日本向けのShopifyストア2店は、どちらもv2026-08-25のプロファイルを返しました。ただし、日本のストアがGoogle上で購入ボタンを表示できるかは、UCPの対応とは別にGoogle側の対象国の条件で決まります。

関連記事

• AP2（Agent Payments Protocol）とは？v0.2のマンデートとx402・ACP・UCPとの違い
• Universal Cartとは？Googleの買い物カートの機能と米国での提供状況・販売店の対応【2026年10月】
• Copilot Checkoutとは？Brand Agentsとの違い・Shopifyでの設定と日本からの利用条件
• A2A（Agent2Agent）プロトコルとは？v1.0の仕組み・MCPとの違い・実装手順
• MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説