GoogleのAIで商品を売るには？UCPの申請から注文まで

GoogleのAIで見つけた商品を、そのまま購入してもらうための連携がUCPです。 お店は商品情報をGoogleへ届け、注文と支払いを自社の通販システムへつなぎます。商品登録だけで購入機能が使えるわけではなく、Googleの承認も必要です [1][3]。

この記事は、自社ECの商品登録や販売を担当する人向けです。

読むと、自社が今申し込める条件、入力する情報、承認後に設定するものが分かります。後半は実装担当者向けに、注文APIのデータ例も載せています。

2026年9月10日時点の申込フォームは、米国・カナダ・オーストラリア・英国のいずれかから発送し、現地の銀行口座を持つ販売者を対象としています。日本からの発送だけで運営する店は、この条件を満たしません。まず商品掲載の準備を進め、UCPの対象地域が広がったかを確認する方針になります [11]。

進める順番は、商品登録 → 参加条件の確認と申請 → Google Payの設定 → 注文APIの接続 → テストと利用承認です。本稿は9月9日に作成した導入解説を9月10日に更新したもので、今日の新発表ではありません。

1. Merchant Centerに商品を登録する

Google、UCP、お店は何をする？

水筒を売る店を例にします。Googleへ商品名や価格を渡しておくと、買い物中の人に商品を見つけてもらう材料になります。Googleの画面で注文まで受けるには、UCPという共通ルールに沿って、店の注文処理を接続します [1][3][4]。

名前	何のために使うか
Merchant Center	商品名・画像・価格・在庫などをGoogleに登録し、更新する場所
Googleの購入画面	購入者が商品や配送先、支払い方法を確認する画面
UCP	Googleと店が、注文内容や金額をやり取りするための共通ルール
Google Pay	購入者が選んだ支払い方法の情報を、安全な形で店に渡す仕組み
店と決済サービス	在庫と金額を確認し、決済を処理する。店が受注と発送を行う

UCPの正式名はUniversal Commerce Protocolです。商品を登録する管理画面や、決済代行会社の名前ではありません。Google Payも、商品一覧を登録する場所ではありません [4][7][13]。

最初に開く画面と操作

1. Merchant Centerを開き、管理に使うGoogleアカウントでログインします。すでに自社のアカウントがあれば、それを使います。未作成なら、会社情報と販売方法を入力して作成します [15]。
2. 利用中のECサービスとの連携、商品ファイル、Googleスプレッドシートなどから、商品情報を渡す方法を選びます。すでにECから自動連携している場合は、その更新元を確認します [15][16]。
3. ファイル等で登録する場合は、公式ヘルプの「設定（Settings）→ データソース（Data sources）→ 主なソース（Primary sources）→ 商品ソースを追加（Add product source）」の順に進みます。登録方法を選び、販売国・言語などを入力します。表示名はアカウントの言語や画面の更新で異なる場合があります [16]。
4. 商品の読み込み結果を確認し、エラーや不承認の理由があれば直します。GoogleのUCP案内では、良好な状態のMerchant Centerアカウントと、無料リスティングで承認された商品が必要です [12]。

ここまでの確認結果として、Merchant CenterのアカウントID、登録した商品ID、無料掲載の承認状況を残します。商品が登録されても、UCPで購入できる状態になったとは扱いません。

返品条件と問い合わせ先もそろえる

返品にかかる費用、返品できる期間、詳しい条件を載せたURLを設定します。問い合わせ先は、窓口ページ・メール・電話のうち少なくとも一つを登録します。購入者が注文後に困ったときの案内に使われます [12]。

まず一つの商品について、ECの商品ページとMerchant Centerの登録を並べて読みます。色や容量が同じか、価格・在庫・配送条件がそろっているかを確かめます。自動連携している情報が違う場合は、更新元も直します。画面上だけ直すと、次の同期で古い情報に戻ることがあります。

2. 発送国と商品を確認し、UCPの待機リストに申し込む

日本の店が、今申し込める条件は？

GoogleのUCP申込フォームを開き、最初の発送国の質問を読みます。2026年9月10日時点では、米国・カナダ・オーストラリア・英国からの発送と、現地銀行口座が条件です [11]。

判断するのは会社名や本社の国だけではありません。日本の会社でも対象国に発送拠点と銀行口座があるなら、実際の運営状況を伝えて参加可否を確認します。日本からしか発送しない場合は、対象国から発送しているとして申告しません。

フォームには、関心のある発送国として「Japan」を選ぶ項目もあります。これは将来の希望を伝える欄で、日本が現在の提供対象という意味ではありません。条件を満たさない場合は、その状況を正しく回答し、表示される案内に従います [11]。

対象外の商品を先に外す

Googleの購入機能には、扱えない商品の案内があります。たとえば定期購入、名入れ等の個別加工、中古・再生品、予約販売などです。UCPという規格で表現できることと、Googleの購入機能で販売できることは一致するとは限りません [12]。

通常販売する新品の水筒で試す場合も、公式の対象外商品の一覧を確認します。「自社ECで売っているから、同じものを全部UCPでも売れる」と判断しないようにします。

フォームに入力するもの

対象条件と商品を確認したら、同じ申込フォームで次の情報を入力します。ここでは、ログインなしで確認できた公式フォームの項目を整理しています [11]。

入力欄	用意する情報
Contact name / Contact email	担当者の名前と連絡先
Company/Merchant Name / Website URL	店や会社の名前、ECサイトのURL
Merchant Center Account ID	手順1で確認したアカウントID
Active offers	Merchant Centerで現在有効な商品数の区分。在庫の個数ではない
Product categories	販売する商品のカテゴリ
Integration providers	現在使っているECや連携サービス。使っていなければその選択肢を選ぶ
Googleの営業担当に関する項目	担当者がいるかと、該当する連絡先
Implementation plan	接続するEC、実装担当、確保できる人員や予定

最後に、選定後30日以内に実装を始める旨などの同意内容を読みます。対応できる計画があることを確かめてから同意し、Submit で送信します。30日は実装を始める条件で、承認や完成までの日数ではありません [11]。

送信後は、表示された受付案内や届いたメールに従います。申請日、連絡先、伝えた内容を残し、Googleからの案内を確認します。本稿ではフォームの閲覧までを行い、申請の送信はしていません。

この手順の完了は「申請を送った状態」です。Googleの購入機能で本番公開するには、連携の承認が必要です [3]。

3. 対象商品と、Google Payの支払い設定を用意する

UCPで販売する商品に印を付ける

連携の準備では、Googleに「どの商品を購入対象にするか」も渡します。公式案内の native_commerce(checkout_eligibility) は、そのための商品項目です。未設定や FALSE なら対象になりません。参加条件を満たす商品について、Googleとの導入手順に沿って設定します [12]。

既存の商品情報へ項目を足すには、補助データソースを使う方法が案内されています。これは登録済みの商品に追加情報を付ける仕組みです。商品のIDを合わせないと、別の商品へ正しく反映できません [12][16]。

1. Merchant Centerの「設定 → アドオン」で、高度なデータソース管理（Advanced data source management）を有効にします。
2. 「設定 → データソース → 補助ソース（Supplemental sources）」から補助の商品データを追加します。
3. 商品IDと追加する項目を用意し、対応する主なデータソース、言語、データソースラベルを合わせます。
4. 読み込み後、対象の商品に情報が反映されたかを確認します。項目をTRUEにするだけで、参加承認や購入機能の接続が完了するわけではありません [12][16]。

Googleへ送る商品IDと、ECの注文処理で使う商品IDもそろえます。違う場合は、公式案内の merchant_item_id で対応付ける方法があります。設定すると、注文時にはこちらの値が優先されます [12]。

Google Payは何を提供する？

購入者はGoogleの画面で支払い方法を選びます。Google Payは、その支払い用情報を店へ安全に渡します。実際の請求は、店が契約している対応決済サービスなどで処理します。Merchant Centerに商品を登録しただけでは、この支払い設定は完成しません [13]。

すでにGoogle Payの販売者アカウントがあれば、UCPでも再利用できます。自社サイトへ先にGoogle Payのボタンを設置することは、UCP利用の必須条件ではありません [17]。

決済サービス経由で処理する場合は、次の順で準備します。

1. Google Pay & Wallet Consoleを開き、販売者用のビジネスアカウントを作成するか、既存のアカウントを確認します。会社情報を登録し、販売者IDを控えます。
2. 利用中の決済サービスがGoogle PayのUCP用情報を処理できるか確認し、接続に使うサービス名と販売者IDを用意します。Merchant CenterのID、Google PayのID、決済サービスのIDを取り違えないようにします。
3. 公式の本番準備ガイドに沿い、Consoleの Google Pay API → Add an integration → Web Integration へ進み、表示される規約を確認します。UCPだけで使う場合、規約同意後に自社ドメインを追加する必要はないと案内されています [17]。
4. Google PayのUCP設定ジェネレーターで項目を開き、自社の設定を入れます。必須項目や入力エラーを確認し、生成されたJSONを実装担当者が点検します。このツールはbetaであり、設定の生成が本番の承認を意味するわけではありません [18]。

まずテスト環境の設定を作り、本番の支払いには本番利用が認められたGoogle Payアカウントの販売者IDを使います。カード情報を自社で復号するDirect方式には別の条件があるため、ここでは決済サービス経由の手順を説明しています [13][17]。

この手順では、対象商品とIDの対応、Google Payと決済サービスの設定、テスト・本番それぞれの利用状態を確認します。次に、その設定と注文APIの場所をGoogleへ伝えます。

4. 注文APIの場所と支払い設定を公開する

店側は「注文の連絡先」と「対応する機能」をJSONファイルで公開します。 公開する場所は、自社ドメインの /.well-known/ucp です。Googleはこのファイルを読み、どこへ注文のデータを送ればよいかを確認します [5]。

ここからはGoogleの 2026-04-08版 の案内に沿って説明します。UCP全体の新しい版と、Googleの接続で使う版は分けて確認します。商品・住所・金額・IDは説明用の例です。Googleの公開例に合わせて米国住所と米ドルを使い、日本での提供可否を示すものではありません。

次は、接続先と機能だけを抜き出した学習用の例です。本番で必要な設定がすべて入っているわけではありません。endpoint を自社の注文APIのURLへ置き換えます。dev.ucp.shopping.checkout は購入手続き、dev.ucp.shopping.fulfillment は配送などの受け取り方法を扱う機能の名前です [5][6]。

{
  "ucp": {
    "version": "2026-04-08",
    "services": {
      "dev.ucp.shopping": [{
        "version": "2026-04-08",
        "transport": "rest",
        "spec": "https://ucp.dev/specification/overview",
        "schema": "https://ucp.dev/2026-04-08/services/shopping/rest.openapi.json",
        "endpoint": "https://merchant.example.com/ucp/v1"
      }]
    },
    "capabilities": {
      "dev.ucp.shopping.checkout": [{
        "version": "2026-04-08",
        "spec": "https://ucp.dev/specification/checkout",
        "schema": "https://ucp.dev/2026-04-08/schemas/shopping/checkout.json"
      }],
      "dev.ucp.shopping.fulfillment": [{
        "version": "2026-04-08",
        "extends": "dev.ucp.shopping.checkout",
        "spec": "https://ucp.dev/specification/fulfillment",
        "schema": "https://ucp.dev/2026-04-08/schemas/shopping/fulfillment.json"
      }]
    },
    "payment_handlers": {}
  }
}

payment_handlers は支払い方法の設定です。この例では空なので、決済を受け付けるための設定はまだできていません。Google Payの設定と署名確認用の公開鍵は、Googleのプロフィール作成例に沿って追加します [6]。例に載っている店のIDや鍵を、自社のものとして使わないようにします。

設定後は、自社の https://自社ドメイン/.well-known/ucp を開き、HTMLのログイン画面ではなくJSONが返ること、APIのURLと対応する版が正しいことを確認します。これだけでGoogleが自社を承認したとは扱いません [3][5]。

このファイルはログインなしで読める必要があります [5]。そのため、秘密鍵やAPIの認証用パスワードは入れません。プロフィールの公開と、注文APIを誰でも呼べる状態にすることは分けて考えます。

5. 商品が選ばれると、Googleから作成APIが呼ばれる

購入者が「買う」を選ぶと、Googleから店のAPIへ商品IDと数量が届きます。 店が商品を調べて購入手続きを作り、そのIDと金額を返す流れです。GoogleのAPIを店が呼んで注文する、という向きではありません [7][8]。

先ほどの endpoint に、次のパスを組み合わせます。たとえば作成先は https://merchant.example.com/ucp/v1/checkout-sessions になります。

店側に作るAPI	何のために使うか
POST /checkout-sessions	商品を指定して購入手続きを作る
GET /checkout-sessions/{id}	途中の状態や注文結果を確認する
PUT /checkout-sessions/{id}	配送先や支払い方法を更新する
POST /checkout-sessions/{id}/complete	最終確認後に支払いと注文を確定する
POST /checkout-sessions/{id}/cancel	完了前の手続きを取り消す

更新は PUT、パスの区切りは checkout-sessions です。ACPの checkout_sessions や更新用のPOSTとは異なるため、別の規格のサンプルを混ぜないようにします [8][9]。

データには、通信のヘッダーも付けます。UCP-Agent は呼び出し側のプロフィールURL、Request-Id は調査に使う番号です。書き込みの Idempotency-Key は、同じ依頼が再送されたときに重複処理を防ぐ番号です [9]。認証や署名、本文のダイジェストも、採用する接続方式に合わせて設定します。

商品が選ばれたときの作成データは、次のようになります。item.id は商品フィードのIDと一致させます。merchant_item_id で対応付けている場合は、その値が優先されます [8][12]。

{
  "line_items": [{
    "item": {"id": "bottle_001"},
    "quantity": 1
  }],
  "context": {"language": "en-US"},
  "fulfillment": {
    "methods": [{
      "type": "shipping",
      "destinations": [{
        "address_locality": "Sunnyvale",
        "address_region": "CA",
        "postal_code": "94089",
        "address_country": "US"
      }]
    }]
  }
}

店のシステムでは、bottle_001 を商品データから検索し、販売中か、在庫があるか、現在の価格はいくらかを調べます。存在しない商品IDを受け取ったときに、代わりの商品で注文を進めないようにします。

作成した手続きには、たとえば checkout_demo_001 というIDを付けて保存します。商品そのもののID、手続きのID、手続き内の明細IDは別です。更新時にどの商品を変えるか迷わないよう、対応関係を保存します。

店から返すのは、現在の手続き全体

応答には、手続きID、状態、通貨、商品明細、金額の内訳、配送の候補、対応する支払い方法などを入れます。Google向けでは、利用規約の terms_of_service とプライバシーポリシーの privacy_policy のリンクも必要です [8]。

応答に入れる項目	この例での意味
id	checkout_demo_001。以降の更新に使う手続きID
line_items[].id	line_001。今回の水筒の明細ID
currency	USD。店が取引条件から決めた通貨
totals	商品代金・送料・税などの内訳と合計
status	情報不足なら incomplete。注文完了とは扱わない
messages	足りない情報や、買えない理由

この表は応答の要点で、完成したJSONの代わりではありません。応答全体はGoogleの作成APIの例と自社の条件を照らし合わせて実装します。画面に出すためだけの値を作らず、保存した手続きと同じ内容を返します。

6. 配送先が変わったら、店が送料を計算し直す

購入者が住所を入力・変更すると、Googleが同じ手続きを更新します。 店は配送できる住所かを確かめ、送料と税を再計算して、更新後の手続き全体を返します [2][8]。

次は PUT /checkout-sessions/checkout_demo_001 に送る住所更新の例です。line_001 は、前の作成応答で店が返した明細IDです。住所だけを別の注文として新規作成するのではありません。

{
  "line_items": [{
    "id": "line_001",
    "item": {"id": "bottle_001"},
    "quantity": 1
  }],
  "context": {"language": "en-US"},
  "fulfillment": {
    "methods": [{
      "type": "shipping",
      "line_item_ids": ["line_001"],
      "destinations": [{
        "address_locality": "Mountain View",
        "address_region": "CA",
        "postal_code": "94043",
        "address_country": "US"
      }]
    }]
  }
}

たとえば水筒が30ドルで、新しい住所への送料が5ドルなら、税など他の条件も含めて最終額を計算します。金額は通貨の最小単位で返すため、米ドルの30ドルは 3000、5ドルは 500 です。日本円の3,000円と同じ意味ではありません [9]。

配送候補は fulfillment.methods[].groups[].options に返します。購入者が配送方法を選んだら、その候補のIDが selected_option_id に入った更新を受け付けます [8]。表示していない配送方法のIDを渡された場合も、そのまま採用しない確認を入れます。

Googleの案内では、住所と送料の計算後は ready_for_payment、支払い方法を含む必要な情報の確認後は ready_for_complete を使います [7]。この二つを「注文完了」と数えないことが大切です。

冷蔵品や配送地域の制限がある場合も、店側のルールで判断します。配送できない住所なら address_undeliverable、在庫がなければ out_of_stock などの理由を返します [2]。Googleがすべての販売条件を先回りして判定してくれる、とは考えないようにします。

7. 購入者の最終確認後に、支払いと注文を確定する

支払い処理を始めるのは、完了APIの依頼を受けてからです。 GoogleのNative checkoutでは、購入者がGoogleの画面で配送先や支払い方法を確認します。この入力・支払いの段階にAIエージェントは関与しない、と案内されています [7][8]。

つまり、AIが商品を見つけた時点で勝手に請求する仕組みではありません。支払い方法まで含む最終更新が成功し、購入者が支払いを選ぶと、POST /checkout-sessions/checkout_demo_001/complete が呼ばれます。

次は支払いデータの形を示す例です。トークンはカード番号の代わりに決済へ渡す情報で、ここに書いた TEST_TOKEN_NOT_PAYABLE では決済できません。handler_id は店が設定したGoogle Payの支払い方法のIDと一致させます [8]。

{
  "payment": {
    "instruments": [{
      "id": "instrument_demo_001",
      "handler_id": "google_pay_demo",
      "type": "CARD",
      "selected": true,
      "credential": {
        "type": "PAYMENT_GATEWAY",
        "token": "TEST_TOKEN_NOT_PAYABLE"
      }
    }]
  },
  "signals": {}
}

このJSONは支払い部分を簡略化した例です。実際には請求先住所や購入者情報など、自社と決済サービスが必要とする項目もそろえます。トークンは payment.instruments の中から、選択済みの支払い方法の credential.token を取り出します。配列の先頭を無条件に使う実装にはしません。

店側の処理は、次の順で組み立てます。

1. 手続きの所有者・状態・最終金額を確認する。完了済みなら新しい請求を作らず、既存の結果を返す。
2. 支払い方法のIDと設定を照合し、対応する決済サービスにテスト用トークンを渡すところから接続を試す。
3. 決済結果を保存する。成功を確認できたら、注文を一度だけ作り、手続きIDと注文IDを結び付ける。
4. status: completed と注文情報を含む、手続き全体を返す。注文の id と permalink_url で、購入者が結果を確認できるようにする。

実装時には、同じ依頼の再送で二重請求しない仕組みも入れます。結果が不明なら、注文と決済を照会してから次の処理を決めます。支払いに成功した後で注文の保存に失敗した場合も、決済結果をもとに復旧できるようにします。

Google Payを既に導入していても、この接続の設定は必要です。GoogleのFAQでは、利用する決済サービスがトークンを処理できることと、UCPのプロフィールに設定を明示することが説明されています [2]。既存サイトの設定が自動的にすべて引き継がれるとは考えません。

8. 注文成立・発送・配達の結果をGoogleへ送る

購入APIで注文完了を返した後も、店からGoogleへ注文の更新を送ります。 Googleの案内では、注文成立、発送、配達の通知が必須です。購入者の注文一覧に、実際の配送状況を反映するためです [14]。

1. 導入時にGoogleから案内される PARTNER_ID と API_KEY を確認します。一般公開の仕様を読んだだけでは、自社用の値は手に入りません。
2. 店の受注・配送処理から、注文全体の最新データをGoogleの通知先へPOSTする処理を用意します。通知先は https://shoppingdataintegration.googleapis.com/v1/webhooks/partners/{PARTNER_ID}/events/order、APIキーは X-Goog-Api-Key ヘッダーで渡せます [14]。
3. 注文成立時、発送時、配達時に通知します。発送時には追跡番号と追跡URLもそろえ、発送から配達の順を守ります。実際に配送していない注文を配達済みにしません。
4. 送信結果を記録し、失敗した更新を検知できるようにします。注文ID・購入手続きIDの欠落や古い更新日時は、公式案内にある拒否理由です [14]。

この通知先はGoogle側のAPIです。第5〜7章の「Googleから呼ばれる店側のAPI」と向きが逆になります。

9. 公開前に、一つの注文を最後まで試す

JSONの形が正しいことと、購入者が最後まで買えることを別々に確かめます。 まずテスト用の商品と決済環境で、作成・住所更新・支払い方法の更新・完了・結果の照会を順に実行します。

接続時はHTTPSを使い、Googleと取り決めた認証方式を設定します。GoogleはOAuth 2.0を推奨し、APIキーにも対応する案内を公開しています [7]。User-Agent などの文字列がGoogleらしいだけで、正規の依頼と判断しないようにします。

試す場面	確認できればよいこと
商品を指定して作成	商品IDが登録情報と一致し、店の価格・在庫が返る
配送先を変更	同じ手続きIDで、送料と税が再計算される
支払い方法を選ぶ	必要情報を確認してから ready_for_complete に進む
支払いを確定	決済と注文が各一つ作られ、注文確認URLを返せる
同じ依頼を再送	注文や請求が増えず、同じ結果を確認できる
在庫切れ・配送不可	理由を返し、成立していない注文を発送しない
通信が途中で切れる	注文と決済を照会し、不明なまま再注文しない

この表は実装後の受け入れ確認に使う例です。単にHTTPの成功応答が返っただけで注文成立とせず、応答内の状態と実際の注文記録を照合します。取り消しは完了前の別の手続きで試し、購入後の返品・返金とは分けます。

掲載したJSONは、2026-04-08版の定義を使い、プロフィールと作成・更新・完了リクエストの項目をローカルで検査しています。Google固有の状態名や画面の動きは、Googleの案内と照合しました。Googleとの接続や実決済を実行した結果ではありません。自社のAPIができたら、GoogleのNative checkout案内から案内されるSDKや適合性テストも使い、接続先と確認します [7]。

本番へ進む前に、Googleの連携承認と、Google Payの本番利用状態を確認します。テスト成功だけで利用開始とは判断しません [3][13]。

導入後は、注文が止まった場所を調べる

売上を見る前に、注文の受付から完了までを追えるようにします。 接続できたことだけでは、お客さんが最後まで買えたかは分かりません。

確認する数字は、同じ期間と同じ集計条件でそろえます。受け付けた手続き、注文が成立した件数、失敗した件数、取り消しや返品をそれぞれ分けます。一人が何度も試した場合をどう数えるかも、最初に決めておきます。

たとえば、購入の失敗が多い商品だけを見たら、配送できない住所からの依頼が集中していたとします。この場合は、商品説明の追加より、販売地域の案内と配送判定を見直す候補になります。これは分析方法の例であり、特定の店で確認した結果ではありません。

GoogleはUCP経由の通信を見分ける方法も案内しています [2]。ただし、通信の件数を注文数に置き換えてはいけません。一つの購入でも、途中の確認で複数のやり取りが発生します。売上は最終的な注文記録で確かめます。

10. 今日やることを、自社の状態で選ぶ

まず、Merchant Centerの登録状態と、UCPの申込フォームの対象条件を確認します。次の表から、自社の一歩を選べます。

自社の状態	今日行うこと	確認できれば一区切り
商品をまだ登録していない	Merchant Centerのアカウントと商品情報を準備する	商品の登録結果と、不承認があればその理由が分かる
日本からの発送のみ	商品情報・返品条件・連絡先を整え、提供条件の更新を確認する	今はUCPの発送国条件を満たさないと判断できる
対象国から発送し、現地口座がある	アカウントIDと実装計画を用意して申請する	送信した内容と受付案内を残せる
Googleとの導入調整が進んでいる	Google Pay・接続情報・注文処理をテストする	認証、金額、二重請求防止、注文後の通知を確認できる
テストが終わった	Googleと利用承認・本番設定を確認する	公開してよい状態と、利用する設定が明確になる

AgentSignalのAIO診断では、商品ページのHTMLや構造化データなどを確認できます。UCPの申請、Googleでの商品掲載、購入APIの動作を検証する機能ではありません。この記事の申込・接続手順と、ページ自体の改善に使い分けてください。