UCP 完全ガイド 2026：仕様と使い方をわかりやすく解説

UCP(Universal Commerce Protocol)は、AI アシスタントと店舗が事前の契約なしに取引するための共通ルールです。Google が 2026年1月11日に発表し、Shopify と共同で仕様を書いています。

このページは、その UCP を初めて読む人向けに 1 か所へまとめたガイドです。用語と買い物の流れから入り、全仕様の地図、使い方別の対応表、コード、安全性の仕組み、版の変遷まで扱います。仕様は 2026年8月25日版に準拠し、更新のたびに末尾の更新履歴へ追記します。

途中にはブラウザで動くシミュレータを 2 つ置きました。読むだけでなく、押して確かめられます。

UCP を 3 分で知る

「3,000 円以内で焼き菓子のギフトを実家へ送って」と AI に頼んだとき、AI はどの店で、どうやって買えばよいのでしょうか。店が 100 万軒あれば、100 万通りの注文画面と決済手順があります。AI ごとに全店へ個別対応するのは現実的ではありません。

UCP はこの問題を、店側が「自分は何ができるか」を決まった場所に公開し、AI がそれを読んで決まった形で注文する、という約束で解きます。言い換えると、店は名刺を出し、AI は名刺を読んでから話しかけます。

発表の場は全米小売業協会(NRF)の年次イベントで、Google の CEO スンダー・ピチャイ氏が壇上で紹介しました(経緯は全体マップに整理)。Shopify の技術解説によれば、仕様は Google と Shopify が共同で書き、Etsy・Target・Walmart・Wayfair などの小売が支持を表明しています。

UCP が決めるのは「取引データをどんな形で受け渡すか」だけです。考えるのは AI モデル、運ぶのは通信経路で、どちらも UCP の外にあります。この切り分けは公式サンプルを動かした記事で実測ログとともに確かめました。

似た名前の規格との位置関係は全体マップに譲り、ここでは 1 点だけ押さえてください。

OpenAI と Stripe の ACP(Agentic Commerce Protocol)は、同じ「注文」の層で競合する相手です。Google の AP2(Agent Payments Protocol)は、UCP の中で「決済の証拠」を担う相棒です。

登場人物と 8 つの用語を比喩で覚える

Google の公式文書が読みにくいのは、用語に日常の対応物が無いまま積み上がるからです。このガイドでは主要な概念に比喩を 1 つずつ固定し、最後まで同じ言葉で通します。

まず登場人物は 4 者です。AI アシスタントなど利用者の代理で店と話す側を Platform、注文の責任を持つ店側を Business と仕様は呼びます。ここに、カード情報を預かってカード番号の代わりになる文字列(トークン)に変える決済事業者(Payment Credential Provider)と、利用者本人が加わります。

用語の正式な定義は仕様書の用語集にあります。

ふくふく堂で 1 回の買い物を試す 7 段階

架空の焼き菓子店「ふくふく堂」と AI アシスタントの 1 回の買い物を、7 段階に分けました。左が会話、右が裏で流れている通信です。「次へ」で進めてください。前の段階から増えた行は青で示します。

(本文なし)

{
  "ucp": {
    "version": "2026-08-25",
    "services": {
      "dev.ucp.shopping": [
        {
          "version": "2026-08-25",
          "transport": "rest",
          "endpoint": "https://fukufuku.example/ucp",
          "schema": "https://ucp.dev/2026-08-25/services/shopping/rest.openapi.json"
        }
      ]
    },
    "capabilities": {
      "dev.ucp.shopping.checkout": [
        {
          "version": "2026-08-25",
          "spec": "…/shopping/checkout",
          "schema": "…/shopping/checkout.json"
        }
      ],
      "dev.ucp.shopping.catalog.search": [
        {
          "version": "2026-08-25",
          "spec": "…/shopping/catalog/search",
          "schema": "…"
        }
      ],
      "dev.ucp.shopping.order": [
        {
          "version": "2026-08-25",
          "spec": "…/shopping/order",
          "schema": "…"
        }
      ],
      "dev.ucp.shopping.fulfillment": [
        {
          "version": "2026-08-25",
          "spec": "…",
          "schema": "…",
          "extends": "dev.ucp.shopping.checkout"
        }
      ],
      "dev.ucp.shopping.discount": [
        {
          "version": "2026-08-25",
          "spec": "…",
          "schema": "…",
          "extends": [
            "dev.ucp.shopping.checkout",
            "dev.ucp.shopping.cart"
          ]
        }
      ],
      "dev.ucp.common.identity_linking": [
        {
          "version": "2026-08-25",
          "spec": "…",
          "schema": "…",
          "config": {
            "scopes": {
              "dev.ucp.shopping.order:read": {}
            }
          }
        }
      ]
    },
    "payment_handlers": {
      "com.google.pay": [
        {
          "id": "gpay_fukufuku",
          "version": "2026-08-25",
          "spec": "…",
          "schema": "…",
          "config": {
            "merchant_id": "BCR2DN…"
          }
        }
      ]
    }
  },
  "keys": [
    {
      "kid": "fukufuku-2026-09",
      "kty": "EC",
      "crv": "P-256",
      "alg": "ES256",
      "use": "sig",
      "x": "f83OJ3D2…",
      "y": "x_FEzRu9…"
    }
  ]
}

7 段階は、名刺の交換(1・2)、探して買う信号機のレジ(3〜6)、買った後の逆向き通知(7)の 3 つに分かれます。TLDR の 3 語と同じ区切りです。

最初の 2 段階は名刺の交換です。店の名刺を読み、AI 側の名刺 URL を UCP-Agent という項目(HTTP ヘッダ)で添え、店が双方に共通する機能だけを有効にします。割引(discount)のように片方だけが知っている機能は落ちます。

段階 3 の検索で商品 ID を得て、段階 4 から 6 が Checkout の信号機です。作った直後は赤(incomplete)で、店は「お届け先が無い」を、文章ではなく通信データ(JSON)の中の場所 path で示します。情報が揃うと青(ready_for_complete)になり、確定すると注文番号が出ます。

年齢確認のように人が要る場面では黄(requires_escalation)になり、店の画面へ引き継ぎます。段階 5 の切り替えで試せます。

最後の段階だけ、通信の向きが逆です。出荷や返品は店から AI へ、封蝋つきの通知(webhook)で届きます。

この 7 段階は仕様書の記述を本ラボが並べ替えた机上の例で、実在のサーバーとは通信していません。実際に動くサンプルは「動かしてみる」の章で案内します。

仕様の地図で機能・通信経路・業種の関係をつかむ

UCP の機能は Capability という単位で分かれ、店の名刺に列挙されます。基本機能に上乗せする拡張(Extension)は名刺の裏面に当たり、extends でどの基本機能に付くかを示します。

名前は dev.ucp.shopping.checkout のように、ドメイン名を逆順にした形式で付きます。Google や Shopify の承認なしに、自社ドメインで com.example.points のような独自機能を足せる設計です。

2026-08-25 版で仕様書に載っている Capability と拡張を、役割ごとにまとめました。「入った版」は、その機能が最初に公開された版です。

表は仕様書 2026-08-25 版の目次と各版のリリースノートから本ラボが起こしました。仕様書が「標準 Capability」と呼ぶのは Cart・Checkout・Identity Linking・Order の 4 つで、残りは業種や決済の都合で足していく設計です。

同じ機能を、どの経路で話すかも名刺に書きます。経路(transport)は 4 種類あり、店は複数を併記できます。

業種の広がりも 2026年後半の特徴です。仕様書にあるのは Shopping(物販)と業種共通の Common だけです。7月に Food(飲食)、8月に Lodging(宿泊)の技術評議会が発足し、8月25日版で仕様の構造を多業種向けに組み替えました。

公式サイトの飲食・宿泊のページは「詳細仕様は近日公開」の段階です(2026年9月10日参照)。ロードマップには、飲食ならメニューの選択からチップ・配達メモまで、宿泊なら部屋と料金プランの選択から予約までを標準化すると書かれています。

Capability 別にコードで確かめる要求と応答

ここからは各 Capability を 1 節ずつ見ます。主読者の方は各節の冒頭の要約だけを拾い、コードは読み飛ばして構いません。コードを試したい方は「動かしてみる」の章にあるサンプルサーバーを起動すると、そのまま叩けます。

Checkout の状態を 3 色の信号機で読む

Checkout は取引の入れ物で、作る・更新する・確定する、の 3 操作で進みます。状態は 6 つあり、信号機の 3 色に対応づけると覚えやすくなります。

店が「何が足りないか」を文章ではなく messages[] の path(JSON の中の場所)で返す点が、AI にとって重要です。AI は自然言語を解釈せずに、次に何を聞くべきかを決められます。

各メッセージには深刻度(severity)も付きます。会話で聞いて送り直せば済む recoverable は赤のままです。

店の画面でしか受け取れない入力が要る requires_buyer_input と、利用者本人の確認が要る requires_buyer_review は黄に当たります。やり直しが効かない unrecoverable で取引は止まります。

curl -X POST https://fukufuku.example/ucp/checkout-sessions \
  -H 'Content-Type: application/json' \
  -H 'UCP-Agent: profile="https://assistant.example/.well-known/ucp"' \
  -H 'Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000' \
  -d '{
    "line_items": [ { "item": { "id": "var_gift_12" }, "quantity": 1 } ],
    "buyer": { "email": "hanako@example.com" }
  }'

// 応答(抜粋)。status が incomplete で、足りない項目が path で示される
{
  "ucp": { "version": "2026-08-25", "capabilities": { "dev.ucp.shopping.checkout": [ { "version": "2026-08-25" } ] } },
  "id": "chk_001",
  "status": "incomplete",
  "currency": "JPY",
  "line_items": [ { "id": "li_1", "item": { "id": "var_gift_12", "title": "季節の焼き菓子ギフト 12 個入り", "price": 2800 }, "quantity": 1 } ],
  "totals": [ { "type": "subtotal", "amount": 2800 } ],
  "messages": [ { "type": "error", "code": "missing", "path": "$.fulfillment.methods[0].destinations", "content": "お届け先を指定してください", "severity": "recoverable" } ],
  "continue_url": "https://fukufuku.example/checkout/chk_001"
}

Catalog で探し、Cart に貯めて、Checkout に渡す

4月版で加わった Catalog は店内検索(search)と商品詳細(lookup)です。返ってくる商品 ID をそのまま Checkout に入れられるので、AI が商品名を言い換えて取り違える事故が減ります。価格や在庫はこの時点の提示で、確定は Checkout です。

Cart は確定前のかごです。複数の店を回りながら候補を貯める、家族で相談してから買う、といった場面で Checkout より前に置きます。割引(discount)は 4月版で Cart にも適用できるようになりました。

curl -X POST https://fukufuku.example/ucp/catalog/search \
  -H 'Content-Type: application/json' \
  -H 'UCP-Agent: profile="https://assistant.example/.well-known/ucp"' \
  -d '{ "query": "焼き菓子 ギフト", "filters": { "price": { "max": 3000 } }, "context": { "intent": "実家へのギフト" } }'

// 応答(抜粋)。variants[].id をそのまま Checkout の line_items[].item.id に入れられる
{
  "products": [ {
    "id": "prod_gift", "title": "季節の焼き菓子ギフト",
    "price_range": { "min": { "amount": 2800, "currency": "JPY" }, "max": { "amount": 3800, "currency": "JPY" } },
    "variants": [
      { "id": "var_gift_12", "title": "12 個入り", "price": { "amount": 2800, "currency": "JPY" }, "availability": { "available": true } },
      { "id": "var_gift_18", "title": "18 個入り", "price": { "amount": 3800, "currency": "JPY" }, "availability": { "available": true } }
    ]
  } ],
  "pagination": { "has_next_page": false }
}

購入後の変化を店から通知する Order

注文後の出荷・配達・返品・返金は、店が AI 側の webhook(通知の受け口 URL)へ POST します。受け口の URL は AI 側の名刺に webhook_url として書いておきます。通知には必ず封蝋(署名)が付き、AI は店の名刺の公開鍵で検証します。

通知の中身は「いま注文がどうなっているか」の全体像(スナップショット)で、差分ではありません。品目ごとの出荷済み数、出荷や配達の出来事(events)、追跡番号が 1 通に入っているので、AI は前の通知を覚えていなくても最新の状態を伝えられます。

返品や返金は、注文に対する調整(adjustments)として同じ経路で届きます。AI は「ふくふく堂から発送されました」「1 点が返金されました」と利用者に伝えられます。

Identity Linking で会員としての利用を許可する

会員価格・保存済み住所・注文履歴のように、利用者本人でなければ見せられない情報があります。UCP はこれを「AI が利用者の代理として店の会員として振る舞う許可」として扱い、許可の取り方に OAuth 2.0 を使います。「Google でログイン」などに使われている認可の標準です。

仕様はアクセスの段階を 3 つに分けます。誰でも見られる公開情報、AI 自身の資格で使えるゲスト購入、利用者本人の証明(identity token)が要る会員向け情報です。ログインは体験を格上げするもので、関門ではない、と仕様は明記しています。

店は名刺の config.scopes に「注文履歴の閲覧には本人の証明が要る」のように、縛る操作だけを列挙します。

8月25日版では識別を連鎖させる流れ(Accelerated IdP Flow)が加わりました。AI が既に Google などの ID 事業者でログイン済みなら、店のログイン画面を飛ばせます。利用者が店ごとにログインし直す手間が減ります。

"dev.ucp.common.identity_linking": [
  {
    "version": "2026-08-25",
    "spec": "https://ucp.dev/2026-08-25/specification/common/identity-linking",
    "schema": "https://ucp.dev/2026-08-25/schemas/common/identity_linking.json",
    "config": {
      "scopes": { "dev.ucp.shopping.order:read": {}, "dev.ucp.shopping.order:manage": {} },
      "providers": {
        "app.example.login": [ { "type": "oauth2", "auth_url": "https://accounts.example-login.app/", "required_claims": [ "email" ] } ]
      }
    }
  }
]

実店舗・会員・配送に対応する Location・Loyalty・Fulfillment

8月25日版の目玉は食料品への対応です。実店舗の検索と営業時間(Location)、量り売りに使う数量の刻み、配送・店舗受取・車での受取を区別する届け先の型が入りました。数量は「1 ポンドを 0.25 ポンド刻みで」のような売り方を、小数を使わずに整数と桁数で表します。

同じ版で Loyalty(会員ポイント)が独立した拡張になり、割引で代用していた実装が正式な形を得ました。

Fulfillment は配送と受取の方法と届け先、Buyer Consent は規約やメール配信への同意です。8月25日版で同意の項目は固定の項目から、dev.ucp.consent.* のようにドメイン名で名付けた一覧に変わり、店ごとの同意項目を足せるようになりました。

Python SDK で JSON の型を検証する

公式の Python SDK(ucp-sdk)は、仕様の JSON スキーマから生成した Pydantic モデルの集まりです。通信そのものは含まず、受け取った JSON を型付きで検証・参照する用途に使います。SDK の版と仕様の版は対応しており、0.5 系が 2026-08-25 版です。

pip install ucp-sdk

from ucp_sdk.models.schemas.shopping.checkout import Checkout

# 店から返ってきた Checkout の JSON を検証して読む
checkout = Checkout.model_validate(checkout_data)
print(checkout.status)   # "incomplete" | "ready_for_complete" | ...
print(checkout.currency)
for item in checkout.line_items:
    print(f"{item.item.title}: {item.quantity}")

上の例は SDK の README の使用例です。仕様に無い項目が混ざれば ValidationError で止まるので、店の実装が仕様どおりかの簡易検査にも使えます。

売り方に合わせて Capability を組み合わせる

事業者の関心は「自分の売り方が UCP で表現できるか」に尽きます。代表的な 6 つの場面を、必要な Capability の組み合わせに対応づけました。

飲食と宿泊は、仕様がまだ策定中です。評議会には飲食で DoorDash・Uber Eats・Toast・Square、宿泊で Booking.com・Expedia・Marriott・Hilton が並びます。ロードマップの記述と合わせて、物販と同じ骨格に業種固有の項目を足す形になると本ラボは見ています。

封蝋・条件書・委任状にたとえて知る 3 層の署名

初対面の相手と取引するのですから、「本当にその AI か」「途中で金額が書き換えられていないか」「利用者が本当に許可したか」を、契約書なしに確かめる必要があります。UCP はこれを 3 種類の署名で層にして解きます。

封蝋で送り主と改ざんの有無を確かめる

1 層目は、要求や通知そのものに付ける署名です。手紙の封蝋のように、差出人が本人であることと、開封されていないことを一度に示します。仕様は HTTP メッセージ署名の標準 RFC 9421 を採用し、4月版で正式に入りました。

署名の対象は、メソッド・宛先ホスト・パス・本文のダイジェスト(要約値)・UCP-Agent・Idempotency-Key です。本文を 1 文字でも変えるとダイジェストが変わり、署名が合わなくなります。下のデモで試してください。鍵はこのページを開いた瞬間にブラウザ内で作られ、どこにも送られません。

鍵を生成しています…

鍵の公開場所は名刺です。店は /.well-known/ucp の keys[] に、AI は UCP-Agent で示した名刺の keys[] に公開鍵を置きます。名刺が機能の宣言と鍵の配布を兼ねるので、事前に鍵を交換する契約が要りません。仕様はこれを permissionless onboarding(事前登録なしの参加)と呼びます。

再送攻撃(同じ要求をもう一度送る)への対策は、署名ではなく Idempotency-Key が担います。このキー(要求ごとの通し番号)は署名の対象に含まれるので改ざんできず、同じキーの要求には同じ応答が返るだけで、二重注文にはなりません。

適用範囲にも濃淡があります。店から AI への webhook 通知は署名が必須(MUST)です。AI からの要求は推奨(SHOULD)で、API キーや OAuth など事前契約のある認証で代えてもよい、とされています。

8月25日版では Web Bot Auth との相互運用が入りました。Cloudflare などが進める「良いボット」の身分証明の仕組みで、同じ鍵と署名形式を流用できます。

店が「この価格で売る」と署名する条件書

2 層目と 3 層目は、AP2 Mandates 拡張(dev.ucp.common.payment.ap2_mandate)を店と AI の双方が名刺に載せたときだけ有効になります。有効になった取引は「安全ロック」され、署名なしの確定要求は拒否されます。

店は Checkout の応答本文に ap2.merchant_authorization という署名を埋め込みます。店が Checkout の本文そのものに署名したもので、価格や品目が途中で書き換わっていないことを AI と利用者が確かめられます。

ここで 1 層目と違うのは、署名の前に JSON を正規化(JCS・RFC 8785)する点です。通信の封蝋はその場で検証して終わります。条件書と委任状は証拠として保存され、数日から数か月後に決済事業者やカード会社が検証することがある、と仕様は書いています。

途中で JSON の並びや空白が変わっても同じ署名で検証できるように、正規化が要ります。

利用者の「この条件で買ってよい」という許可を示す委任状

利用者が「お願いします」と言った瞬間、AI は 2 通の委任状(Mandate)を作ります。Checkout 委任状は、店の条件書ごと包んだ Checkout 全体に対する許可です。支払い委任状は、支払いの許可そのものです。

どちらも利用者本人の鍵に結び付いた証明書で、後から第三者が検証できます。

入れ子の構造が要点です。店の署名を AI の署名が包むので、店は「利用者が見たのは自分が署名した条件だ」と、利用者は「AI が勝手に条件を変えていない」と、後から証明できます。店は Checkout 委任状を、決済事業者は支払い委任状を検証し、両方が通って初めて決済が走ります。

委任状の中身(主張の項目や鍵の結び付け方)は AP2 の仕様が定め、UCP はそれを「どこに置くか」だけを定めます。AP2 そのものは本ラボの決済担当が別記事で分解します。

POST /ucp/checkout-sessions/chk_001/complete
{
  "payment": {
    "instruments": [ {
      "id": "pi_ap2", "handler_id": "ap2_234352", "type": "card",
      "credential": { "type": "card", "token": "eyJhbGciOiJ…" }   // payment_mandate(SD-JWT)
    } ]
  },
  "ap2": { "checkout_mandate": "eyJhbGciOiJ…" }                     // checkout_mandate(店の署名を包む)
}

決済事業者が取扱説明書を書き、店と AI が使う

署名の話を支えるのが、決済の役割分担です。UCP は、AI がカード番号などの生の決済情報に触れないことを前提に、3 者の三角形で決済を組みます。

店と決済事業者には契約があり、店は決済事業者の鍵を持っています。AI は決済事業者と直接やり取りしてトークン(カード番号の代わりになる文字列)を受け取り、それを店に渡します。店はトークンを決済事業者に送って請求します。AI にも店の窓口にも、カード番号は流れません。

Payment Handler は「決済事業者」ではなく「決済事業者が書いた取扱説明書」です。決済事業者が「うちのトークンはこう取る」というスキーマを書き、店は名刺で「Google Pay をこの設定で受ける」と選び、AI は説明書どおりに実行します。

賛同企業には Google Pay・Shop Pay に加え、Adyen・Stripe・PayPal・Checkout.com などの決済事業者が並びます。

8月25日版は決済の安全性を 2 つ強化しました。1 つは actions[] で、店が AI に「この確認をして」と頼む仕組みです。カードの本人認証 3D セキュア(3DS2)を、店の画面に頼らず AI 側で進められます。

もう 1 つは $requestConstraints で、店が「このカードには請求先住所が要る」のような条件を応答に載せます。

9月2日には決済の技術評議会(Payments TC)が発足しました。メンバーは Adyen・Ant International・Coinbase・Global Payments・Google・PayPal・Shopify・Stripe の 8 社で、この層の設計はそこが担います。

8 か月で公開された 4 つの版と、運営を担う 5 つの評議会

UCP の版は日付です。2026-08-25 のように書き、新しい版が出るたびに店と AI は名刺の version を更新します。1月の発表から 9月までに 4 つの版が出ました。

版の意味は 8月25日版で明確になりました。日付は「互換性の系統」を名付けるもので、ソフトウェアの長期サポート版(LTS)に近い考え方です。後方互換な修正は同じ日付のまま追記され、互換性を壊す変更は次の日付に入ります。古い版しか話せない AI 向けに、店は supported_versions で版ごとの名刺を併置できます。

8月25日版の互換性を壊す変更は 10 項目以上ありますが、事業者に効くのは 3 つです。署名鍵の置き場所が keys[] に一本化されたこと。決済系の拡張の名前が dev.ucp.shopping.* から dev.ucp.common.payment.* に移ったこと。配送(fulfillment)の項目名と構造が整理されたことです。

残りは同意の辞書化や共通型の置き場所の変更で、実装している人以外には影響しません。

評議会は 5 つあります。常任の統治評議会(Governing Council)は Google と Shopify で、4月に Stripe が加わりました。

その下に業種・領域別の技術評議会が Shopping・Food・Lodging・Payments の 4 つあります。Shopping には Etsy・Target・Wayfair の小売に加えて Amazon・Meta・Microsoft・Salesforce が席を持ちます。

仕様の変更は技術評議会が承認します。互換性を壊す変更は 2 週間前に公開の場で告知する、と運用ルールに書かれています。

4 つの入口から動かしてみる

読むだけでは掴めない部分は、動かすのが早道です。入口は 4 つあり、上から順に手軽です。

いちばん手軽なのはこのページのシミュレータです。「1 回の買い物を追う」の 7 段階と、「封蝋」の署名デモは、サーバーなしでブラウザだけで動きます。JSON の形と信号機の遷移を掴むのが目的です。

次に公式サイトの Playground です。名刺の選択から webhook の模擬まで 8 段階を、実際の JSON スキーマで検証しながら進められます。ブラウザ内の模擬で、本番コードの参照用ではないと注記があります。

本物のサーバーを動かすなら公式サンプルです。A2A 版は Gemini の API キーだけで動き、本ラボが注文完了まで通した記録があります。REST 版は Python(FastAPI)の店舗サーバーで、署名の検証まで実装しています。

git clone https://github.com/Universal-Commerce-Protocol/samples.git
cd samples/rest/python/server
uv sync
mkdir /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

起動後は http://localhost:8182/.well-known/ucp で花屋の名刺が読めます。--require_signatures を付けると、署名の無い要求を拒否する本番相当の動きになります。同じリポジトリでも A2A 版と REST 版で準拠する版が違う点は、先の記事で確かめたとおりです。

最後が Python SDK で、前章のとおり pip install ucp-sdk で入ります。自作の店舗サーバーを作るなら、応答の JSON をこの SDK で検証しながら進めると仕様からのずれに早く気づけます。

日本から試せるか・事業者は何を準備するか

仕様・SDK・サンプルはすべて公開されており、日本からそのまま試せます。一方、Google 検索の AI モードで実際に「買える」対象は限られます。Google Merchant Center のヘルプによれば、米国・カナダ・オーストラリアの商品と参加販売者だけです。

Google の購入手続きに日本の店舗が参加する入口は、2026年9月時点ではありません。他の AI アシスタント経由の受注も、本ラボが確認した範囲では公表されていません。

それでも準備は前倒しできます。このガイドの比喩で言えば、事業者が用意するのは名刺・封蝋・会員証・決済の取扱説明書の 4 点です。

順番に意味はありません。名刺と封蝋は数日で試作でき、会員証と決済は社内の既存資産次第です。実際に自作の EC を UCP 対応にする過程は、本ラボの連載で 10月に前後編で扱います。

よくある質問

UCP と ACP はどちらを選べばよいか: 同じ「注文」の層で競合する 2 規格で、店側は両対応が現実解です。位置関係は全体マップに整理しました。

MCP と UCP はどう違うか: MCP は AI とツールをつなぐ通信の規格、UCP は取引データの形と手順の規格です。UCP は MCP を経路の 1 つとして使えます。

AP2 は必須か: 任意の拡張です。店と AI の双方が名刺に載せたときだけ有効になり、有効になると署名なしの確定は拒否されます。

費用はかかるか: 仕様は Apache 2.0 ライセンスで公開され、読むのも実装するのも無料です。Google 側の購入手続きに参加する条件や手数料は Merchant Center のヘルプと申込フォームに従います。

このガイドの更新方針

UCP は数か月ごとに版が出ます。新しい版が公開されたら、Capability 一覧・年表・破壊的変更の節を更新し、末尾の更新履歴に日付と内容を残します。日本での本番提供が始まったときも同様です。

執筆後記WRITER'S NOTE

私は UCP を、AI に買い物を任せる未来につながる重要な規格だと考えています。Google の UCP 紹介動画で描かれた買い物体験には、とても魅力を感じました。

いま注目しているのは、その体験を実現する仕組みが、具体的な仕様としてどこまで整っているかです。この記事では、仕様をいち早く読み解き、実装を通じて確かめながら、何ができるのかをわかりやすく伝えていきたいと思います。

伊藤 輝
全記事に執筆後記を掲載しています(編集方針)