投稿者 投稿日: カテゴリー EC×AI活用
UCPとは、Googleが2026年1月に公開したエージェント商取引の共通規格のことです。
Merchant Centerの管理画面に「UCP」という単語が出てきて調べに来た、という方が増えています。日本語の解説はまだ「AIが代わりに買ってくれる時代が来ます」という抽象論が中心で、自社のフィードやチェックアウトを実際にどう触るかまで書いたものが見当たりません。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が、UCPの仕様を一次情報で確認したうえで、日本の楽天・Yahoo!・自社EC事業者が今週から動ける5手順に落とし込みます。日本国内での提供時期については公式に明示がないため、後半で「今やる意味がある準備」と「待つべき投資」を分けて整理します。
UCPが2026年1月から半年で何を変えたのか
UCPは2026年1月11日、全米小売業協会の年次カンファレンスに合わせてGoogleが発表したオープンソース規格です。Google Developers Blogによると、共同開発にはShopify、Etsy、Wayfair、Target、Walmartが加わり、Adyen、American Express、Best Buy、Flipkart、Macy’s、Mastercard、Stripe、The Home Depot、Visa、Zalandoなど20社を超えるパートナーが賛同しています。決済側はAgent Payments Protocol（AP2）と互換で、通信の入口はREST API、A2A、MCPの3方式から選べます。
規格が生まれた背景はシンプルです。会話型のAIが買い物の入口になると、AI側は在庫の有無、いまの価格、送料、クーポンの適用可否を会話の途中でリアルタイムに知る必要があります。ところが各社が独自に接続を作ると、事業者数×AIサービス数の組み合わせだけ実装が必要になります。Googleはこれを「N×Nの統合ボトルネック」と表現し、抽象レイヤーを1枚かませることで解消しようとしています。
技術的な入口は拍子抜けするほど地味です。事業者は /.well-known/ucp にJSONのマニフェストを置き、自社が対応しているサービスと機能（capability）を宣言します。現時点で公開されている買い物系の機能は、チェックアウト（dev.ucp.shopping.checkout）、割引（discount）、配送（fulfillment）の3つで、割引と配送はチェックアウトの拡張として定義されています。エージェントはこのマニフェストを読み、ハードコードなしで「この店は何ができるか」を判定します。
決済の設計も押さえておく価値があります。UCPは、消費者が使う支払い手段（instruments）と、それを処理する決済事業者（handlers）を分離しています。この分離があるため、既存の決済プロバイダをそのまま残したまま規格に乗れます。そして全ての承認には、ユーザーが同意したことの暗号学的な証明が付きます。エージェントが勝手に決済した、という事故を構造的に防ぐ設計です。
事業者にとって一番効くのは、Merchant of Record（販売主体）が引き続き自社であるという点です。Googleは「事業者が自社のビジネスロジックを保持する」と明記しており、初日から完全にカスタマイズされたチェックアウト体験を維持できる「embeddedオプション」も用意されています。プラットフォームに顧客を握られる形の統合ではありません。
半年後の2026年5月20日、Google Marketing Live 2026でUCPの適用範囲が一気に広がりました。Search Engine Landの報道によると、複数小売店の商品をまたいで保存できるUniversal Cartが拡張され、Google Payまたは小売店側のチェックアウトで購入できるようになります。対応予定にはNike、Sephora、Target、Walmart、Wayfair、そしてShopify上のFentyやSteve Maddenが挙がっています。UCPはDirect Offers、Demand Genキャンペーン、AI Modeの買い物体験、YouTube上のショッピング広告にも組み込まれます。Google Pay内でのAffirmとKlarnaの後払い連携、ホテル予約やフードデリバリーへの領域拡大も発表されました。
日本のEC事業者にできること、まだできないこと
先に結論を書きます。2026年7月時点で、日本のEC事業者がUCPの購入体験そのものに乗れる保証はありません。Search Engine Landは、UCP由来の機能の多くが米国で先行し、カナダ、オーストラリア、その後に英国へ広がると報じています。日本の提供時期は明示されていないため、ここは要確認の領域です。
一方で、準備の大半は日本にいながら進められます。Googleの実装に参加する条件は、有効なMerchant Centerアカウントを持ち、チェックアウト対象として適格な商品情報を提供していること。この「商品情報の適格性」こそが、いま日本で手を付けられる部分です。GTIN、価格、在庫、配送、返品条件といったフィード属性の精度は、UCPが来る前から広告とショッピングタブの成績に直結しています。
現場で繰り返し見るのは、フィード・自社サイト・モール掲載の3か所で価格や在庫がずれている状態です。自社ECのセール価格を反映し忘れた、楽天だけクーポンを走らせている、Yahoo!ショッピングの在庫連携が数時間遅れている。人間の買い物客は多少のズレを許容しますが、エージェントは「いま買える価格と在庫」を前提に会話を組み立てるため、不一致はそのまま信頼の低下として効きます。ここは日本にいても今日から直せます。
Google Marketing Live 2026では、Merchant CenterにAI Performance Insights、商品説明向けのConversational Attributes、Ask Advisor連携が加わることも示されました。会話型の買い物では「軽い」「静か」「敏感肌向け」といった、従来のフィード属性に収まらない表現が検索の入口になります。商品説明の情報量そのものが評価対象になる方向です。
楽天市場やYahoo!ショッピングだけで運営している事業者はどうするか。この2つのモールはモール側が独自の検索・決済基盤を持つため、店舗単位でUCPのエンドポイントを立てる余地は現状ありません。取れる打ち手は2つに絞られます。1つは、自社ECを小さくてもよいので立ち上げ、Merchant Centerに接続してGoogle経由の導線を自社で持つこと。もう1つは、モール内の商品情報の解像度を上げ、外部の生成AIが商品を説明できる材料をウェブ上に置くことです。後者はAI経由の購買が接点をどう変えるかという論点と地続きです。
規模感の話もしておきます。自社ECの月商が300万円に満たない段階でUCPのエンドポイント実装に開発費を投じるのは、現時点では早すぎる判断だと考えます。日本での提供時期が未定である以上、投資回収の見通しが立ちません。逆に、フィード品質の改善は提供時期に関係なく効くので、こちらを先に片付けるのが合理的です。
Merchant Centerフィードを整える5手順とプロンプト5本
ここからは実装パートです。UCPが日本に来たときに即座に乗れる状態を作るための5手順と、それぞれに対応するプロンプトを5本用意しました。プロンプトはChatGPT、Claude、Geminiのいずれでも動きます。2026年7月時点の各社フラッグシップは、OpenAIがGPT-5.6系（Sol／Terra／Luna、2026年7月9日公開）、GoogleがGemini 3.6 Flash（2026年7月21日公開）、AnthropicがClaude Opus 5（2026年7月24日公開）です。商品データの一括処理はコンテキスト長が効くので、大量のCSVを一度に読ませるならGPT-5.6かOpus 5、コスト重視ならGemini 3.6 Flashという振り分けが現実的です。
手順1：フィード・サイト・モールの3点照合
最初にやるのは、価格と在庫の不一致を洗い出すことです。Merchant Centerの商品データをCSVで書き出し、自社サイトの実売価格と突き合わせます。
（用途タイトル：フィードとサイトの不一致検出）
プロンプト1：Merchant Centerフィードと自社サイトの不一致検出
あなたはGoogle Merchant Centerのフィード品質に精通したECコンサルタントです。
以下の2つのデータを突き合わせ、不一致を検出してください。
データA（Merchant Centerフィード抜粋）：
{id, title, price, sale_price, availability, gtin, shipping を含むCSV}
データB（自社サイトの実売情報）：
{商品ID, 表示価格, セール価格, 在庫状態 を含むCSV}
検出すべき不一致：
1. price と表示価格の差（1円でも差があれば報告）
2. sale_price の有無とサイト上のセール表示の食い違い
3. availability（in_stock / out_of_stock）と実在庫の食い違い
4. gtin の欠損または桁数異常（JANは13桁、UPCは12桁）
5. shipping 情報の欠落
出力：不一致した商品IDごとに「項目名／フィード値／サイト値／想定される影響」を1行で列挙し、
最後に不一致件数を項目別に集計してください。修正の優先順位も3段階で付けてください。
手順2：GTINと商品識別子の穴埋め
エージェントは商品の同一性をGTINで判定します。ここが欠けていると、複数店舗を横断した比較の土俵に乗りません。既存カタログのGTIN充足率を出し、欠損を埋める作業を優先度付きで進めます。
（用途タイトル：GTIN欠損の棚卸しと優先順位付け）
プロンプト2：GTIN欠損の棚卸しと補完計画
あなたはEC商品マスタの整備を担当するデータ管理者です。
以下の商品リストからGTIN（JAN/EAN/UPC）の欠損状況を分析してください。
商品リスト：
{商品ID, 商品名, ブランド, カテゴリ, GTIN, 月間売上, 在庫数 を含むCSV}
分析内容：
1. GTIN充足率を全体とカテゴリ別で算出
2. GTIN欠損商品のうち、月間売上が上位20%に入るものを抽出
3. GTINが13桁でない、チェックディジットが不正、重複しているものを検出
4. 自社製造品などGTIN取得が必要なものと、メーカー品でGTINを問い合わせれば済むものを分類
出力：
- 充足率のサマリ
- 補完優先度A（売上上位かつ欠損）／B（売上中位）／C（低売上）に分けた商品リスト
- Aの各商品について、GTIN入手経路の想定（メーカー問い合わせ／流通BMS／新規取得）
手順3：会話で拾われる商品説明への書き換え
Conversational Attributesが示す方向は、属性の羅列ではなく「どんな場面で誰に向くか」を言語化することです。従来のSEO用の商品説明とは最適解がずれます。
（用途タイトル：会話型検索を意識した商品説明の再生成）
プロンプト3：会話型検索に拾われる商品説明の再生成
あなたは日本のEC事業者向けに商品説明を書くコピーライターです。
以下の商品について、AIエージェントが会話の中で引用しやすい商品説明を作成してください。
商品情報：
- 商品名：{商品名}
- カテゴリ：{カテゴリ}
- 素材・成分：{値}
- サイズ・容量：{値}
- 価格：{値}
- 想定利用シーン：{値}
- 既存レビューでよく出る言葉：{値}
条件：
1. 冒頭1文で「誰の、どんな場面に向く商品か」を言い切る（40字以内）
2. 「軽い」「静か」「敏感肌向け」のような、ユーザーが会話で使う形容表現を、
根拠となる数値やスペックとセットで書く（例：本体重量1.2kgで、片手で持てる軽さ）
3. 薬機法・景品表示法に抵触する表現（治る、効く、日本一、絶対、No.1）を使わない
4. 数値は必ず単位付き
5. 全体で250〜400字
出力：商品説明本文と、その中で使った「会話語×根拠」のペア一覧
手順4：構造化データとフィードの整合チェック
自社ECサイトにProduct構造化データを入れている場合、フィードと値がずれると評価を下げる要因になります。両者を1つのソースから生成する設計に寄せるのが定石です。
（用途タイトル：構造化データとフィードの整合監査）
プロンプト4：Product構造化データとフィードの整合監査
あなたはテクニカルSEOの監査担当者です。
以下の2つを比較し、整合していない項目を検出してください。
入力A：商品ページのJSON-LD（Product schema）
{JSON-LDをそのまま貼り付け}
入力B：Merchant Centerフィードの該当商品行
{該当行のCSVまたはJSON}
チェック項目：
1. name と title の実質的な一致
2. offers.price と price の一致（通貨単位含む）
3. offers.availability と availability の一致
4. gtin / sku / brand の一致
5. aggregateRating・review の有無と、その値が実データに基づくか
6. Product schema の必須プロパティの欠落
出力：項目名、JSON-LD側の値、フィード側の値、判定（一致／不一致／欠落）、
修正案を1行ずつ。最後に「今すぐ直すべき3件」を理由付きで提示。
手順5：エージェント経由の流入を計測する設計
準備が終わったら、効果測定の型を先に決めます。AI経由の流入はリファラが取りにくく、後から遡って測るのが難しいためです。
（用途タイトル：AI経由流入の計測設計）
プロンプト5：AIエージェント経由の流入計測プランの設計
あなたはEC事業者のアナリティクス設計を担当するコンサルタントです。
以下の環境で、AIエージェント経由の流入と売上を切り分けて計測する設計を作ってください。
環境：
- 自社EC：{Shopify / 自社構築 / その他}
- 解析ツール：{GA4 / その他}
- Merchant Center：{接続済み / 未接続}
- 月間セッション数：{値}
- 主要な流入元の現状比率：{値}
設計に含めること：
1. リファラで判別できるAI系トラフィックの一覧と、判別できないケースの扱い
2. GA4で作るべきカスタムディメンションとイベントの具体名
3. 「AI経由らしさ」を推定する代替指標（直帰率、セッションあたり閲覧商品数、
検索クエリの長さなど）の候補
4. 月次で見るKPIを5つ、算出式付きで
5. 計測開始から3か月後に判断すべきこと
出力：計測設計書（見出し付き）と、初月にやるタスクのチェックリスト
失敗例と回避策
現場でよく見る失敗を3つ挙げます。
1つ目は、UCPを「新しいSEO施策」と誤解して、商品説明にキーワードを詰め込むパターンです。UCPは検索順位を上げる仕組みではなく、在庫と価格を機械が読める形で渡す仕組みです。キーワードの詰め込みは、会話型の引用ではむしろ不利に働きます。回避策は、手順3のプロンプトのように「会話語と根拠のペア」で書くことです。
2つ目は、フィードだけ直してサイト側を放置するケース。Merchant Centerの管理画面でエラーが消えたことに満足し、サイトの構造化データが古い価格のままという状態です。アパレル系の単一店舗で試したケースでは、セール終了後にJSON-LDのpriceだけ旧価格で残り、フィードとの不一致が3週間続いていました。手順4の整合監査を月次のルーチンに入れるのが対策です。
3つ目は、日本での提供が確定していない段階で外部ベンダーに数百万円規模のUCP実装を発注してしまう判断です。UCPは開発が続いているオープンソース規格で、capabilityも拡張の途中です。仕様が動くうちに作り込むと、手戻りのコストを自社で被ることになります。当面はフィードとデータ品質という、どの規格が来ても無駄にならない部分に投じるのが安全です。
4つ目として、レビューの構造化データを「あるように見せる」ためだけに入れてしまうケースを挙げておきます。aggregateRatingを実データなしで記述するのは、Googleの構造化データポリシー上も危険ですし、エージェントが引用したときに実際のレビュー本文と齟齬が出ます。ある食品ジャンルの中規模店舗の事例では、レビュー件数を親商品と子商品で二重計上していたために、商品ページの評価件数がモール側の表示と合わなくなっていました。件数と平均点は、必ず1つのソースから機械的に出す設計にしてください。
5つ目は、商品説明を生成AIで一括更新した際に、旧モデル名や終売サイズが残るパターンです。プロンプトに「入力にない情報を追加しない」という制約を明示していないと、モデルが一般知識で補ってしまいます。生成した説明文は、必ず元のスペック表と照合してから反映する運用にしてください。編集部で実際に運用しているプロンプトでは、出力の末尾に「入力データのどの項目を根拠にしたか」を列挙させ、根拠のない記述を機械的に弾いています。
KPI設計と費用・工数目安
追う指標は4つで足ります。フィードのGTIN充足率、フィードとサイトの価格不一致件数、Merchant Centerの商品不承認率、そして商品説明の平均文字数と会話語の含有率です。いずれも自社で測れるうえ、UCPの提供時期に左右されません。
工数の目安を出します。商品点数1,000点規模で、手順1から手順4までを一巡させると、初回は担当1名で20〜30時間程度かかるのが現場感覚です。2回目以降はプロンプトを使い回せるので、月次の維持は3〜5時間に収まります。ここは自社のデータ整備状況で大きく振れるため、目安として扱ってください。
ツール費用は月額で見ると小さい部類です。ChatGPT Plusが月20米ドル、Claude Proが月20米ドル、Google AI Proが月20米ドル前後という水準で、1アカウントあれば手順1から5までは回せます。商品1万点規模でAPIを使って一括処理する場合は別途トークン費用が乗りますが、それでも数千円から数万円のオーダーです。
改善効果は保証できる性質のものではありません。ただ、商品不承認率が下がればショッピング広告の配信対象が増えるという因果は明確で、フィード整備の投資回収はUCPを抜きにしても説明がつきます。
指標の見方も具体化しておきます。GTIN充足率は、まず売上上位20%の商品群で100%を目指してください。全商品での充足率を追うと、低回転の商品に時間を吸われて手が止まります。価格不一致件数は「ゼロが正常」で運用し、週次で件数を記録します。件数が増えるタイミングはたいていセール開始日と終了日の翌日に集中するので、そこを重点的に見るだけで検出漏れは大きく減ります。
商品不承認率は、Merchant Centerの診断画面で確認できる数字をそのまま使います。全商品に対する不承認商品の割合を月初に1回記録し、原因コード別に内訳を持っておくと、次に直す対象が自動的に決まります。現場感覚では、不承認の理由は「画像の品質」「価格の不一致」「必須属性の欠落」の3つで大半が説明できます。
商品説明の平均文字数と会話語の含有率は、少し工夫が要る指標です。文字数は単純に平均を取ればよいのですが、会話語のほうは「軽い」「静か」「乾きやすい」といった自社カテゴリで想定される表現をあらかじめ辞書として用意し、その語が説明文に含まれる商品の割合を測ります。この辞書はレビュー本文から抽出すると精度が上がります。顧客が実際に使っている言葉が、そのままエージェントに問い合わせる言葉になるためです。
今後の展望と独自考察
注目しているのは、UCPが小売以外の領域へ広がっている点です。ホテル予約とフードデリバリーへの拡張が発表されており、Googleマップの会話から食事を注文する体験も示されています。これは「商品を売る」以外のビジネスにも同じ規格が降りてくることを意味します。
もう1つ、決済とマーケティングの境目が溶けていく流れがあります。UCPがDirect Offers、Demand Gen、YouTubeのショッピング広告に組み込まれ、Google Pay内でAffirmやKlarnaの後払いが選べるようになる。広告を見た瞬間から決済完了までが1本の流れになると、従来の「集客→サイト誘導→カート→決済」というファネル前提のKPI設計は組み替えが必要になります。
日本市場について1つ予想を書いておきます。Googleの実装が日本に来る前に、楽天やYahoo!が自前のエージェント商取引の枠組みを出す可能性は十分あると考えています。国内のモールは決済も物流も自社圏内に抱えているため、外部規格に乗るより自前で閉じるほうが合理的だからです。その場合、日本のEC事業者は複数規格への同時対応を迫られます。だからこそ、規格に依存しない「正確な商品データ」という資産の価値が上がる、という見立てです。この論点は自社ショッパーエージェントを持つ小売の成長率とあわせて読むと立体的になります。
よくある質問
UCPとは結局なんですか
UCPとは、AIエージェントと事業者のシステムが商取引をやり取りするための共通規格のことです。事業者がマニフェストで自社の対応機能を宣言し、エージェントがそれを読んで在庫確認からチェックアウトまでを実行します。2026年1月11日にGoogleが公開し、オープンソースで開発が続いています。
日本のEC事業者はもう使えますか
いいえ、2026年7月時点で日本での提供は公式に案内されていません。Search Engine Landは米国先行、その後カナダ、オーストラリア、英国という順序を報じています。日本の提供時期は要確認の扱いです。
楽天市場だけで運営していますが対応は必要ですか
現時点で店舗単位の対応は不要です。UCPはGoogleのMerchant Centerを入口とする仕組みで、楽天市場の店舗ページを直接つなぐ経路は用意されていません。自社ECを持っている場合のみ、フィード整備の意味があります。
Merchant Centerに登録するだけで参加できますか
いいえ、Merchant Centerアカウントに加えて、チェックアウトの対象として適格な商品情報を提供する必要があります。Googleは統合ガイドを公開しており、事業者向けの申込フォームを経てから実装に進む流れです。
費用はどれくらいかかりますか
規格自体はオープンソースなのでライセンス費用は発生しません。かかるのは自社側の実装工数と、フィード整備の人件費です。フィード整備だけなら生成AIのサブスクリプション月20米ドル程度と、担当者の作業時間で始められます。
ChatGPT・Claude・Geminiのどれを使うべきですか
商品データの一括処理ならコンテキスト長の大きいGPT-5.6系かClaude Opus 5、コストを抑えたいならGemini 3.6 Flashが現実的です。1つに絞る必要はなく、同じプロンプトを2モデルに投げて出力を比べる運用のほうが精度は安定します。
今日から何を始めればいいですか
売上上位100商品について、Merchant Centerフィードの価格・在庫・GTINを自社サイトの実値と突き合わせてください。この照合で不一致が1件も出ない店舗はほとんどありません。ここが起点です。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Google Developers Blog｜Under the Hood: Universal Commerce Protocol (UCP)
- Universal Commerce Protocol 公式サイト
- Google｜Merchant Center向けUCP統合ガイド
- Search Engine Land｜Google expands Universal Commerce Protocol and launches new agentic shopping tools
- UCP GitHub リポジトリ
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
