AIエージェント経由の購入完結を可能にするGoogle UCP規格の全体像

AIエージェント経由の購入完結を可能にするGoogle UCP規格の全体像

2026年1月、Googleは全米小売業協会（NRF）の年次カンファレンスにおいて、エージェンティックコマースの基盤となるオープン規格「Universal Commerce Protocol（UCP）」を正式に発表しました。この規格は、AIエージェントが商品の発見から決済・購入後サポートまでを一貫して処理できるよう設計されたもので、EC業界の構造そのものを変える可能性を秘めています。ここではUCPの基本概念から登場背景、従来ECとの違いまでを体系的に整理します。

検索から決済まで離脱ゼロを目指すエージェンティックコマースの定義

エージェンティックコマースとは、AIエージェントがユーザーに代わって商品の検索・比較・選定・決済・購入後サポートまでを自律的に実行する新しい購買体験を指します。従来のECでは、消費者が自らブラウザでサイトを巡回し、商品ページを確認して決済情報を入力する必要がありました。この過程で生じるページ遷移やフォーム入力が、カート離脱率の高さにつながっていたのです。

エージェンティックコマースでは、ユーザーがAIアシスタントに「軽量なスーツケースを探して」と話しかけるだけで、エージェントが複数の小売業者の在庫を横断的に検索し、条件に合う商品を提示します。ユーザーが同意すれば、Google Walletに保存済みの決済情報を用いてそのまま購入が完了する仕組みです。ページ遷移がなく、ブラウザのタブ切り替えも不要であるため、購入プロセス全体の摩擦が大幅に削減されます。Googleはこの一連のフローを「会話型ショッピング」と位置づけ、検索行動の延長線上で購買が完結する世界を目指しています。

2026年1月NRF発表時にGoogleが示した3つのコア機能の具体的範囲

Googleが初期ローンチで提示したUCPのコア機能は、Checkout（チェックアウト）、Identity Linking（アイデンティティ連携）、Order Management（注文管理）の3つです。チェックアウトは、AIエージェントがチェックアウトセッションを生成し、商品の価格計算・税計算・配送オプション提示・決済処理を一気通貫で行う機能を担います。

アイデンティティ連携は、ユーザーのアカウント情報を小売業者側のロイヤリティプログラムやメンバーシップと紐づける仕組みです。これにより、AIを経由した購入でも既存会員としてのポイント加算や優待が適用される道が開かれます。注文管理は、購入後の追跡・返品・交換といったポストパーチェス対応を標準化する機能で、エージェントが「注文した商品の配送状況を教えて」という問いに対して構造化されたデータで回答できるようになります。今後のロードマップでは、複数商品カート、関連商品レコメンド、カスタムショッピング体験への拡張が予定されており、初期の3機能はあくまで基盤としての位置づけです。

AI Modeの検索結果から直接購入ボタンが表示される実際の購買フロー

UCPが最初に実装された環境は、Google検索のAI ModeおよびGeminiアプリです。ユーザーがAI Modeで「旅行用の軽いスーツケースを探して」と入力すると、Geminiが商品情報を分析して候補を提示します。対象商品には「購入」ボタンが表示され、クリックするとUCPを通じてチェックアウトセッションが開始される仕組みです。

セッションが開始されると、Google Walletに保存されたクレジットカード情報と配送先住所が自動的に読み込まれ、ユーザーは内容を確認して最終承認を行うだけで購入が完了します。この一連の処理にブラウザのタブ移動や外部サイトへのリダイレクトは発生しません。初期段階では米国の対象小売業者に限定されていますが、Google PayおよびPayPalによる決済に対応する計画も公表済みです。小売業者側は自社のチェックアウトロジックをUCP経由で提供するため、価格設定やプロモーション条件は各事業者が独自に制御できる設計となっています。

従来のカートページ型ECと比較したUCP経由取引の構造的な違い

従来型のEC取引では、消費者が検索エンジン→商品一覧ページ→商品詳細ページ→カート→決済ページという複数のステップを経由する必要がありました。各ステップでページが遷移するたびに離脱が発生し、一般的なカート離脱率は70%前後とされています。UCP経由の取引では、この多段階プロセスが「AIとの対話→確認→購入完了」に圧縮されます。

注目すべき点は、UCP経由でもMerchant of Record（販売者記録）は小売業者側に留まるという設計思想です。Googleはあくまでプラットフォームとインフラを提供する立場であり、取引の主体や顧客データの所有権は各事業者に帰属します。ただし、ブランド体験の訴求機会が限定される点は、自社サイトでの販売と比較した際のトレードオフとして認識しておく必要があります。

Buy on Googleが2023年に終了した経緯とUCP登場までの戦略転換

Googleは過去にも「Buy on Google（Googleで購入）」というサービスを展開していました。Googleショッピングの検索結果から商品詳細を表示し、そのまま決済まで完結させる仕組みで、米国を中心に一部の国で提供されていたものです。しかしこのサービスは2023年に突如として終了しました。

振り返ってみると、Buy on Googleの終了は、AIエージェントによるエージェンティックコマースの到来を見据えた戦略的な判断だった可能性があります。Buy on Googleは従来型のウェブインターフェースをベースとした仕組みであり、ページ遷移を前提とした設計でした。一方、UCPはAIエージェントとの対話を前提に設計されたプロトコルであり、根本的にアーキテクチャが異なります。個別の画面遷移ベースのサービスに投資を続けるよりも、エコシステム全体で活用できる共通規格の策定にリソースを集中させる方が、長期的な競争優位につながるとGoogleが判断したと考えられるでしょう。この戦略転換の結果として、Shopify・Walmart・Targetなど業界大手との共同開発体制が構築され、20社以上の支持を得る大規模なオープン規格としてUCPが誕生しました。

チェックアウトから注文管理まで支えるUCPの3層アーキテクチャ構造

UCPの技術的な強みは、コマースの各機能を明確に分離した層構造にあります。Shopifyの技術ブログでは、TCP/IPの設計思想になぞらえて「責務を分離し、明確なAPIを定義し、合成を可能にする」というレイヤードプロトコルの原則が強調されています。ここでは各層の役割と、実務上の実装選択肢を詳しく見ていきます。

Shopping Service層が定義するチェックアウトセッションと決済の基本設計

Shopping Service層は、UCPの最も基礎的なトランザクション処理を担う層です。ここでは、チェックアウトセッション、ラインアイテム（商品明細）、トータル（合計金額）、リンク（関連リソースへの参照）といったコマースの基本的なプリミティブが定義されています。これらのプリミティブは、小売業者が日常的に行っているチェックアウト業務と1対1で対応する設計です。

たとえば、エージェントがチェックアウトセッションを作成すると、UCPはセッションIDを発行し、商品情報・価格・数量を構造化されたJSONフォーマットで返します。税額計算や送料の算出は小売業者のビジネスロジックに委ねられ、UCPはその結果を標準化された形式で受け渡す役割を担います。この設計により、数百万規模の事業者がそれぞれ異なる税率や送料体系を持っていても、エージェント側は統一されたインターフェースで処理を進められるのです。セッションのステータスは段階的に遷移し、最終的に「ready_for_complete」状態に達した時点で決済実行が可能となります。

Capability層で実現するロイヤリティ連携やサブスク課金の拡張パターン

Capability層は、基本的なチェックアウト機能の上に積み重ねる拡張機能群を管理する層です。UCPでは、小売業者が自社のサポートする機能（ケイパビリティ）を宣言し、エージェントがそれを発見・交渉するという「ディスカバリーとネゴシエーション」の仕組みが採用されています。

たとえば、ある家具店が「配送日時の指定が必須」というケイパビリティを宣言していれば、エージェントはチェックアウトの過程でユーザーに日時選択を促すことになります。サブスクリプション型の定期購入、ロイヤリティポイントの適用、ギフトラッピングの追加なども、すべてケイパビリティとして拡張的に定義可能です。この設計の利点は、プロトコル本体を改訂することなく新機能を追加できる点にあります。Shopifyの技術チームが指摘するように、モノリシックなプロトコルは複雑性に耐えきれずに崩壊しますが、レイヤード設計であれば責務を分離したまま進化を続けることが可能です。各事業者は自社独自のビスポーク機能すら定義でき、エージェントはそれを動的に発見して対応するという柔軟性が確保されています。

Payment Handler層がトークン化決済で担保するセキュリティ設計の仕組み

Payment Handler層は、決済処理をプロトコル本体から分離して管理する層です。UCPの大きな特徴として、特定の決済プロバイダーに依存しないオープンなモジュラー設計が挙げられます。各決済プロバイダー（Google Pay、Shop Pay、PayPalなど）が独自のハンドラー仕様を公開し、小売業者はどのハンドラーを受け入れるかを宣言します。エージェントはその中から適切なものを選び、ハンドラーの仕様に従って決済処理を進めるという流れです。

セキュリティ面では、すべての支払い承認がユーザーの明示的な同意に基づく暗号化された証明によって裏付けられます。決済情報はトークン化され、クレジットカード番号が直接やり取りされることはありません。この設計により、新しい決済手段が登場しても、プロトコルのコアバージョンを更新する必要なくエコシステムに組み込めます。Shopifyの技術解説では「委員会の投票やコアのバージョンアップなしに、新しい決済方法がエコシステムに成長していく」と表現されており、拡張性を最優先とした設計思想が読み取れます。

REST・MCP・A2Aから選べる3種のトランスポート方式の判断基準

UCPは通信方式として、REST API、Model Context Protocol（MCP）、Agent2Agent（A2A）の3種類のトランスポートをサポートしています。小売業者は自社の技術スタックや開発リソースに応じて、最適な方式を選択できます。

多くのEC事業者にとって、まず検討すべきはREST APIです。既存のECプラットフォームやバックエンドシステムとの親和性が高く、開発チームが使い慣れた技術で統合を進められるためです。MCPはAIエージェントとの双方向通信に最適化されたプロトコルで、エージェントがツールとして直接コマース機能を呼び出すユースケースに適しています。A2Aはエージェント同士が自律的にタスクを委譲し合うシナリオを想定しており、将来的なマルチエージェント環境を見据えた選択肢です。Googleはアダプターによるプロトコル間の互換性も提供しており、初期導入後に方式を切り替える柔軟性も担保されています。

エージェントと加盟店がプロファイル交換で行う動的ネゴシエーションの流れ

UCPの運用において特筆すべき仕組みが、エージェントと加盟店の間で行われるプロファイル交換による動的ネゴシエーションです。エージェント側は自身が提供できるクレデンシャル（決済トークンの種類、対応ウォレットなど）をプロファイルとして宣言します。一方、加盟店側は自社がサポートする決済ハンドラーやケイパビリティをプロファイルで返答する流れです。

Shopifyの技術解説で示された具体例では、エージェントがGoogle PayとShop Payの両方に対応していることを宣言し、加盟店がその両方をサポートしている場合、最終的にどの決済手段を使うかはユーザーの選択に委ねられます。このネゴシエーションは取引ごとに動的に行われるため、カートの内容や購入者の地域、取引金額によって利用可能な決済手段が変化することにも対応可能です。従来のEC統合では、決済手段の追加や変更に開発工数がかかっていましたが、UCPのプロファイルベースの設計では、加盟店側がハンドラー宣言を更新するだけで新しい決済手段を即座に有効化できるという利点があります。

Shopify・Walmart・Visa含む20社超が参画するUCPエコシステムの実態

UCPは単独の企業が策定した規格ではなく、EC業界の主要プレイヤーが共同開発に参加し、20社以上がエコシステムへの支持を表明している点に大きな特徴があります。ここでは参画企業の役割分担から、具体的な実装事例までを整理します。

Google・Shopify・Etsy・Wayfairが共同開発した経緯と各社の役割分担

UCPの共同開発は、Google、Shopify、Etsy、Wayfair、Target、Walmartの6社を中心に進められました。Googleがプロトコルの設計およびAI Mode・Geminiでの初期実装を主導し、Shopifyは数百万のマーチャントを抱えるコマースプラットフォームとしての知見をプロトコル仕様に反映させています。

Shopifyの製品担当VP、Vanessa Lee氏は「Shopifyには数十年にわたり数百万のユニークな小売企業のチェックアウトを構築してきた実績がある。その経験をすべてUCPに反映させた」と述べており、大規模かつ多様な事業者のニーズに対応する堅牢性が設計に組み込まれています。Etsy・Wayfairはハンドメイド商品やインテリアといったニッチ領域の要件を持ち込み、Target・Walmartは大量在庫を持つ大規模小売業の運用要件を反映させました。こうした多様な事業形態の参画が、特定の業種に偏らない汎用性の高いプロトコル設計を実現しています。

Visa・Mastercardなど決済大手5社以上がUCPを支持する理由

UCPのエコシステムには、Visa、Mastercard、American Express、Stripe、Adyenといった決済業界の主要プレイヤーが支持を表明しています。これらの企業がUCPを支持する背景には、Payment Handler層のオープンかつモジュラーな設計思想があります。

従来のEC決済では、各プラットフォームが独自のAPIやSDKを要求するため、決済プロバイダーは個別の統合開発を強いられてきました。UCPのPayment Handler設計では、決済プロバイダーが自社のハンドラー仕様を一度公開すれば、UCP対応のあらゆるエージェントや消費者向けサーフェスからその仕様に基づいて決済を受け付けられます。Googleが決済手段を独占するのではなく、複数のプロバイダーが対等に参加できる設計であることが、業界横断的な支持を集めた要因です。Stripe・Adyenのような決済インフラ企業にとっては、AIコマース時代においても自社の決済レールが活用される保証となり、Visa・Mastercardにとってはカードネットワークのトランザクション量を維持する戦略的意義があります。

Agentforce CommerceにUCPを組み込んだSalesforceの実務例

UCPの早期導入事例として注目されるのが、SalesforceのAgentforce CommerceへのUCPネイティブ統合です。Salesforceは2026年1月にGoogleとのパートナーシップ拡大を発表し、Agentforce Commerceの加盟店がUCPを通じてGoogle AI ModeやGeminiアプリ上でネイティブチェックアウトを提供できるようにしました。

Salesforce側のSVP兼GM、Nitin Mangtani氏は「リーチを拡大しつつ、完全なオペレーション管理と直接的な顧客関係を維持できる」と述べており、UCPのMerchant of Record設計がエンタープライズ顧客の導入判断を後押ししていることがうかがえます。実務上の利点として、Agentforce Commerce加盟店はSalesforceのCRMデータと連携した在庫情報・ロイヤリティ情報・顧客履歴を、UCP経由のチェックアウトフローにリアルタイムで反映できる点が挙げられます。エージェントとの対話中に在庫確認やロイヤリティポイント適用が可能になるため、AIサーフェス上でも従来のECサイトに近い購買体験を提供できるようになっているのです。

PayPalが決済ハンドラーとして参画した背景と想定される手数料構造

PayPalはUCPのローンチ時に決済オプションとしての参画を発表しました。同社のAI担当SVP、Prakhar Mehrotra氏は「相互運用性こそが、小売業者が一度の接続で多くの環境にリーチできる鍵だ」と述べ、オープンな標準規格としてのUCPの価値を強調しています。PayPalの参画により、Google Payに加えてPayPalでの決済が可能になり、消費者の決済手段の選択肢が広がります。

手数料構造については、2026年3月時点で公式な詳細は公表されていません。ただし、UCP自体はオープンソースのプロトコルであり、プロトコル利用に対するライセンス費用は発生しない設計です。決済手数料はPayPalやStripeなど各決済ハンドラーの既存料率体系に準じるとみられます。Google側がUCPを通じた取引に追加手数料を課すかどうかも明示されていませんが、Googleのビジネスモデルを考慮すると、プロトコル自体での課金よりも、AI Mode上での広告枠やDirect Offersなどのマーケティングサービスでの収益化が主軸になると推察されます。

Monos・Gymshark・Everlaneなど初期導入ブランドに見る業種別の傾向

UCP初期導入ブランドとして名前が挙がっているのは、旅行用スーツケースのMonos、フィットネスアパレルのGymshark、サステナブルファッションのEverlaneなどのD2Cブランドです。これらのブランドに共通する特徴は、Shopifyをコマース基盤として利用しており、かつ明確なブランドストーリーを持つ中〜高価格帯の商品を取り扱っている点です。

MonosのCEO、Victor Tam氏は「エージェンティックショッピングは、リアルな意図を持って質問している瞬間に、自社のストーリーと商品情報を届けられる新しいチャネルだ」と述べています。これは、UCPが単なる価格比較の場ではなく、ブランドの文脈を伴った商品提案を可能にする仕組みとして機能し得ることの示唆といえるでしょう。一方で、初期導入ブランドにはラグジュアリーブランドや食品・日用品カテゴリーの事業者は多くなく、まずはD2Cモデルで意思決定が迅速な中規模事業者から導入が進む傾向が読み取れます。今後のグローバル展開や機能拡張に伴い、参画ブランドの業種・規模は拡大していくと見込まれます。

OpenAI ACPとGoogle UCPで異なるエージェントコマースの設計思想

エージェンティックコマースの標準規格は、Googleだけが策定しているわけではありません。2025年9月にはOpenAIとStripeがAgentic Commerce Protocol（ACP）を発表しており、2大プロトコルが並立する状況です。両者の設計思想の違いを理解することが、EC事業者にとって適切な導入判断の前提となります。

ACP「チャットで完結」とUCP「検索起点で全行程」というスコープの違い

ACPとUCPの最も根本的な違いは、カバーするスコープにあります。ACPはChatGPTでの会話内チェックアウトに最適化された設計で、「チャットの中で商品を見つけ、その場で購入する」という直線的な体験が重視されています。一方、UCPは商品の発見から購入、さらに購入後のサポートまで、ショッピングジャーニー全体の標準化が目標です。

わかりやすく表現すれば、ACPはチェックアウトの「会話」を標準化するプロトコルであり、UCPはコマースの「全行程」を標準化するプロトコルです。UCPにはアイデンティティ連携や注文管理が初期機能として含まれますが、ACPの初期スコープはチェックアウトフローに集中しています。この違いは、両プロトコルの背後にある企業のビジネスモデルと密接に結びついたものです。OpenAIはChatGPTを次世代のブラウザと位置づけ、ユーザーを会話内に留めることを重視するため、決済の瞬間に焦点を当てた設計になっています。Googleは検索エンジンとショッピンググラフという既存資産を活かし、発見から購入後まで一貫した体験を提供することで、エコシステム全体の価値を高める戦略を取っているのです。

商品データ登録がプッシュ型かクロール型かで変わる運用負荷の比較

商品データの登録方式も両プロトコルで大きく異なります。ACPは「プッシュ型」を採用しており、加盟店がJSON・XML・CSVなどの構造化データをOpenAIに直接送信する必要があります。OpenAIはこのデータを自社のベクターデータベースに取り込み、ChatGPT内での商品検索に活用する仕組みです。

一方、UCPは「クロール型」の分散型ディスカバリーを基本設計に据えています。加盟店は自社ドメイン上の/.well-known/ucpエンドポイントにUCPマニフェストを公開し、AIエージェントがそれを発見して取引を開始できる仕組みです。ただし、現実的にはGoogleのUCP実装ではMerchant Centerを通じた商品フィード登録が前提となっているため、純粋なクロール型のみで運用する段階には至っていません。運用負荷の観点では、Merchant Centerに既に商品フィードを登録しているEC事業者はUCP対応の追加作業が比較的少なく済みます。ACPへの対応にはOpenAI側への新規データ連携が必要になるため、両方に対応する場合はデータパイプラインの整備が欠かせなくなります。

Stripe中心のACPとマルチPSP対応のUCPで分かれる決済柔軟性の差

決済インフラの設計は、EC事業者にとって導入判断を左右する重要な論点です。ACPの決済フローは、OpenAIとStripeの緊密な連携を前提に構築されています。ユーザーがChatGPT内で購入を承認すると、Stripeが「Shared Payment Token（SPT）」と呼ばれるワンタイムの決済トークンを発行します。このトークンは特定の加盟店・特定の金額・有効期限に暗号的に紐づけられており、セキュリティは高い設計です。

しかし、この仕組みはStripeを主要な決済プロバイダーとして利用する前提で最適化されています。ACPの仕様にはseller_backed_payment_handlerというRFC（提案仕様）も含まれており、Stripe以外のPSPも技術的には対応可能ですが、統合の複雑性はStripe利用時と比較して高くなります。対照的にUCPのPayment Handler層は、特定のPSPに依存しないマルチプロバイダー設計です。Google Pay、Shop Pay、PayPal、Adyen、Stripeなど複数の決済手段を並列で扱え、取引ごとに最適なハンドラーを動的に選択できます。既に複数のPSPとの関係を構築している大規模小売業者にとっては、UCPの方が既存の決済インフラを活かしやすい構造といえます。

分散型ディスカバリーと中央集権型審査で異なる出店ハードルの実態

出店（加盟店として参加する）プロセスも、両プロトコルで異なるアプローチが取られています。ACPでは、加盟店がOpenAIに申請し、審査を通過した事業者のみがChatGPTのショッピング機能に商品を掲載できます。このキュレーション型のアプローチは品質管理には有利ですが、加盟店の規模拡大には時間がかかる構造です。

UCPは設計思想として分散型ディスカバリーを採用しており、加盟店が自社ドメインにUCPエンドポイントを公開すれば、理論上はどのAIエージェントからでも発見・取引が可能です。ただし、Googleの実装においてはMerchant Centerアカウントの保有とチェックアウト対応商品の提供が参加要件として求められます。現実的には、GoogleのUCP実装もMerchant Centerという既存のインフラを通じた参加が主流となっているため、完全なオープンアクセスとはいえません。とはいえ、Merchant Centerには世界中で多数の事業者がすでに登録しているため、ACP型の個別審査と比較すると参入障壁は低いと考えられます。将来的に他のAIプラットフォームがUCPを採用する場合には、分散型ディスカバリーの設計が真価を発揮する可能性があります。

両プロトコル併用が推奨される理由とShopify経由で同時対応する実務例

多くの業界分析が示す結論は、ACPかUCPかの二者択一ではなく、両プロトコルへの同時対応が最適だということです。ACPはChatGPTの会話内で発生する深いファネルの購買意図を捕捉し、UCPはGoogle検索やGeminiを起点とする広いファネルの発見意図をカバーします。片方のみに対応した場合、もう片方のエコシステムで発生する購買機会を逃すことになるのです。

両プロトコルに同時対応する実務的な手段として最も手軽なのが、Shopifyプラットフォームの活用です。Shopifyは「Agentic Storefronts」という機能を通じ、加盟店が一度データを設定するだけでChatGPT、Microsoft Copilot、Google AI Mode、Geminiなど複数のAIサーフェスに商品を配信できる仕組みを提供しています。Shopify以外のプラットフォームを利用している事業者向けには、Mercury GXOやPrestaといったエージェンティックミドルウェアが登場しており、単一の統合で両プロトコルのフィードとマニフェストを自動生成するサービスも出始めています。いずれにせよ、プロトコル固有のコア実装を直接バックエンドに組み込むよりも、抽象化レイヤーを挟む方が将来の仕様変更への耐性が高いでしょう。

EC事業者が直面する販売機会拡大とGoogle依存リスクの両面評価

UCPはEC事業者に新たな販路と高意図ユーザーへのアクセスをもたらしますが、同時にプラットフォームへの依存やブランド体験の制約というリスクも内包しています。導入の損得を正しく判断するには、両面を定量的・構造的に把握することが不可欠です。

AI Mode・Gemini経由の高意図ユーザーへ直接リーチできる集客上の利点

UCPを導入する最大のメリットは、Google検索のAI ModeやGeminiアプリという巨大なトラフィック源に対し、購入可能な商品として直接表示される点にあります。従来のSEO施策では、検索結果で上位表示を獲得してもクリック率は数%程度であり、さらにサイト訪問後のコンバージョンまでに多くの離脱が発生していました。

UCP対応商品は、AIが会話の中でユーザーの意図を解釈した上で「この商品を今すぐ購入できます」という形で提示されるため、従来の検索結果とは質的に異なる接触機会を得られるのが大きな特徴です。Googleのショッピンググラフには500億件以上の商品リスティングが格納されており、毎時20億件以上が更新されているとされています。この巨大なデータベースをAIが横断的に検索した結果として自社商品が推薦されれば、検索広告やSEOでは到達できなかった新規顧客層との接点が生まれる可能性があります。また、UCP経由で購入するユーザーはすでに購買意図が高い状態でエージェントに依頼しているため、一般的な検索トラフィックと比較してコンバージョン率が高くなることも期待できるでしょう。

自社サイト訪問なしで取引完結する場合にブランド体験が希薄化する懸念

UCPの仕組み上、消費者はAIエージェントとの対話画面内で商品を選択し、決済まで完了します。自社ECサイトを訪問することなく取引が成立するため、小売業者がこれまでサイトUI/UXの工夫で実現してきたブランド体験の提供機会が大幅に制限される点は見過ごせません。

eMarketerのシニアディレクター、Jeremy Goldman氏が指摘するように、商品がブランドのストーリーやアイデンティティで選ばれるのではなく、在庫の有無・価格・配送速度といった定量的要素だけでランク付けされる「汎用品化」のリスクがあります。特にプレミアムブランドやD2Cブランドにとって、この懸念は深刻です。自社サイトでは写真の見せ方、商品説明の文体、購入後のフォローメールに至るまで一貫したブランド体験を設計できますが、AI画面内では表示フォーマットがプラットフォーム側に規定されます。UCPにはEmbedded統合という、加盟店独自のチェックアウト体験を維持できるオプションも用意されていますが、会話型インターフェースの制約から、自社サイトと同等のブランド表現を実現するのは現時点では困難といわざるを得ません。

Google仕様変更で売上が左右される検索依存と同構造のプラットフォームリスク

UCPへの対応を進めるにあたり、冷静に評価すべきなのがGoogleへの依存リスクです。過去を振り返ると、多くのウェブパブリッシャーがGoogle検索のアルゴリズム変更によって大幅なトラフィック減少を経験してきました。UCP対応によるAI Mode経由の販売が事業の柱となった場合、Googleの仕様変更や優先表示ロジックの変更がそのまま売上変動に直結する構造が生まれます。

この懸念は理論上のリスクにとどまりません。UCPはオープンソース規格であるものの、最初の主要実装環境はGoogleのAI ModeとGeminiアプリです。Googleが表示アルゴリズムを変更したり、Direct Offersのような広告商品を拡大してオーガニック表示枠を圧縮したりすれば、UCP経由の販売成績に影響が出る可能性は否定できません。対策として重要なのは、UCP経由の販売をあくまで販路の一つとして位置づけ、自社ECサイト・Amazon・実店舗など複数チャネルとのバランスを維持する考え方です。特定のプラットフォームに売上を依存させないマルチチャネル戦略は、UCP以前から有効な基本方針であり、その原則はAIコマース時代においても変わりません。

販売者記録（Merchant of Record）を維持できる設計が持つ法的・財務的意味

UCPの設計で事業者にとって安心材料となるのが、Merchant of Record（販売者記録）が小売業者側に維持される点です。Merchant of Recordとは、取引の法的な売主として税務申告・返品対応・消費者保護規制への準拠義務を負う主体を指します。Googleがこの立場を取らないということは、Googleは取引の仲介インフラを提供するにとどまり、売買契約は消費者と小売業者の間で直接成立する構造だということです。

この設計が持つ実務的な影響は多岐にわたります。まず、売上計上と税務処理は従来と同じく小売業者自身が行うため、新たな会計処理の大幅な変更は不要です。次に、返品・交換対応も小売業者の既存フローで処理でき、Googleに対応を委譲する必要がありません。さらに、顧客データの所有権も小売業者側に帰属するため、CRM施策やリマーケティングへのデータ活用に制約がかからない設計となっています。一方、Amazonマーケットプレイスのように販売者記録がプラットフォーム側に移行するモデルでは、顧客接点の大部分をプラットフォームに握られるリスクが生じます。UCPはこの点で、事業者の自律性を重視した設計がなされているといえるでしょう。

顧客データ保有とリピート施策の自由度から見たUCP活用の損益分岐判断

UCPの導入可否を判断する際、最終的に問われるのは「自社のビジネスモデルにとって、UCP経由の新規顧客獲得とブランド体験の制約のどちらが影響が大きいか」という損益分岐の視点です。顧客データを自社で保有し続けられるUCPの設計は、リピート施策の実行基盤を確保する上で大きな利点があります。

たとえば、UCP経由で初回購入した顧客のメールアドレスを自社CRMに取り込み、購入後のフォローメールやロイヤリティプログラムへの誘導を行うことで、2回目以降は自社ECサイトでの直接購入へ転換させる戦略が考えられます。新規獲得チャネルとしてUCPを活用しつつ、リピート購入は自社サイトで完結させるというハイブリッド型のアプローチです。この場合、UCP経由の顧客獲得コストと、自社サイトでのLTV（顧客生涯価値）を比較して投資判断を行うことが可能です。逆に、ブランド体験が最重要で、価格競争に巻き込まれたくないラグジュアリーカテゴリーの事業者は、UCP対応の優先度を下げるという判断もあり得ます。

Merchant Center連携からAPI実装まで必要なUCP導入の技術要件

UCPの導入に際しては、Googleが提供するMerchant Centerを起点とした商品データの整備と、APIレベルでの技術統合が求められます。ここでは、具体的な実装手順と技術的な選択肢を開発チーム向けに整理します。

Google Merchant Centerのアカウント開設と商品フィード整備の前提条件

UCP導入の第一歩は、Google Merchant Centerアカウントの開設と、チェックアウト対応可能な商品フィードの整備です。Merchant Centerは、Googleのショッピング関連サービスに商品情報を供給するための管理プラットフォームであり、UCP対応の参加要件としてアクティブなアカウント保有が明示されています。

商品フィードには、商品名・価格・在庫状況・画像URL・商品説明・配送情報・GTINやMPNといった識別子を含める必要があります。UCPでは、AIエージェントが商品を正確に識別・比較するために、従来のフィード項目に加えて構造化された属性情報の充実度が重要な差別化要因となるでしょう。Googleは新たにMerchant Center向けの属性として、よくある質問への回答、互換アクセサリ、代替商品の情報などを追加する方針を公表済みです。これらの拡張属性は、AIが商品の適合性を判断する際の材料となるため、可能な限り早期に対応しておくことが望まれます。フィードの更新頻度も軽視できないポイントであり、価格や在庫情報はリアルタイムに近い鮮度の維持が求められるのです。

Native統合とEmbedded統合の2種類から選ぶ実装パスの比較と判断基準

Googleは、UCP実装のアプローチとしてNative統合とEmbedded統合の2種類を提供しています。どちらを選択するかは、事業者の技術リソースとブランド体験へのこだわりによって判断が分かれます。

Native統合は、チェックアウトロジックをGoogle AI ModeおよびGeminiに直接統合する方式で、Google側の標準UIを利用するため実装が比較的容易です。UCPの機能拡張にも自動的に追従できるメリットがあり、Googleは「初日からフルエージェンティック体験を解放する」方式と位置づけています。Embedded統合は、加盟店が独自のチェックアウト体験を維持したままUCPに対応する方式で、ブランド表現の自由度が高い反面、カスタマイズに応じた開発工数が追加で必要になります。まずNative統合で市場の反応を確認し、必要に応じてEmbedded統合に移行するという段階的アプローチも現実的な選択肢です。

Python公式サンプルで確認するチェックアウトセッション作成の実装手順

Googleは、UCP実装の理解を促進するためにGitHub上でPythonによるリファレンス実装を公開しています。この公式サンプルを通じて、チェックアウトセッションの作成から完了までの基本フローを確認可能です。

1. GitHub上のUCPリポジトリをクローンし、README.mdの手順に従ってローカル環境をセットアップする
2. 加盟店側のサーバーを起動し、UCPエンドポイントを公開する
3. エージェント側からチェックアウトセッション作成リクエストを送信する
4. 加盟店サーバーがセッションIDとともに商品情報・価格・配送オプションを返却する
5. エージェントが決済ハンドラーを選択し、トークン化された決済情報を送信する
6. セッションステータスが「ready_for_complete」に遷移し、最終確認後に取引が完了する

公式サンプルでは、ディスカウントコードの適用や配送方法の選択といった実践的なシナリオもカバーされています。開発チームはこのサンプルを起点に、自社のビジネスロジック（税計算・在庫確認・プロモーション適用など）をUCPのインターフェースに接続する形で実装を進めていく流れになるでしょう。RESTベースの通信が前提となっているため、既存のEC APIに慣れている開発者であれば、基本的なフローの理解に大きな障壁はないでしょう。

well-known/ucpエンドポイント公開による分散型ディスカバリー設定の要点

UCPの分散型ディスカバリーを活用するためには、自社ドメイン上に/.well-known/ucpエンドポイントを公開する設定が必要です。この仕組みは、robots.txtやsitemap.xmlと同じ設計思想に基づいており、AIエージェントがウェブをクロールする際に加盟店のコマース機能を自動的に発見できるようにするものです。

エンドポイントには、UCPマニフェストと呼ばれるJSON形式の定義ファイルを配置します。マニフェストには、対応するUCPバージョン、サポートする機能（ケイパビリティ）一覧、利用可能な決済ハンドラー、APIのベースURLなどを記述する形式です。このファイルが正しく公開されていれば、Google以外のAIプラットフォームがUCPを採用した場合にも、追加の統合開発なしで発見・取引対象となる可能性があります。ただし、現時点ではGoogleのUCP実装はMerchant Centerを通じたフィード登録が主要な参加経路であるため、分散型ディスカバリーの実効性はまだ限定的です。将来を見据えた布石として、Merchant Center連携と並行して/.well-known/ucpエンドポイントも整備しておくことが望ましいでしょう。

SDK導入時に発生しやすい認証エラーとJSON-RPCパース失敗の対処パターン

UCP実装の技術的なつまずきポイントとして、SDK導入時の認証エラーとJSON-RPCベースの通信でのパースエラーが挙げられます。Googleはネイティブ SDKを複数の言語バインディングで提供しており、開発環境への統合を迅速化する設計としていますが、初期セットアップ時にはいくつかの注意点があります。

認証エラーの主な原因は、Merchant Centerアカウントの認証情報（OAuthトークン）の期限切れや、APIスコープの設定不備です。UCP固有のAPIスコープが既存のMerchant Center APIスコープとは別途必要になるケースがあるため、権限設定の確認は実装初期に重点的に行うべきです。JSON-RPCに関しては、MCPトランスポートを選択した場合にJSON-RPC 2.0形式でのリクエスト・レスポンスが求められるため、既存のREST APIに慣れたチームではペイロードの構造が想定と異なりパースに失敗する事例があり得ます。対処としては、公式サンプルコードのリクエスト・レスポンスペイロードを正確に再現し、差分を確認するアプローチが有効です。また、UCPの公式GitHubリポジトリにはイシュートラッカーが公開されており、実装上の問題に対するコミュニティベースの知見も蓄積され始めています。

日本のEC事業者が今から着手すべき構造化データ整備とカート対応の優先順位

UCPの日本展開時期は2026年3月時点でまだ未定とされています。しかし、オープンな技術規格として公開されている以上、グローバル展開は時間の問題であり、日本市場への到来に備えた準備は早いほど有利になります。ここでは日本のEC事業者が具体的に何から着手すべきかを整理します。

日本での展開時期は未定でも先行着手が有利になる3つの実務的根拠

日本でのUCPサービス提供時期が未定であるにもかかわらず、今から準備を始めるべき理由は3つあります。第一に、商品データの構造化整備には時間がかかるという現実があります。在庫・価格・仕様情報のリアルタイム同期体制の構築、Schema.orgマークアップの実装、Merchant Centerフィードの最適化は、いずれも一朝一夕では完了しません。

第二に、UCPはGoogleだけの規格ではなく、将来的にあらゆるAIプラットフォームが参照する共通基盤となる可能性を秘めています。Apple Intelligenceも2026年1月にGoogleとの複数年提携を正式発表し、次世代Apple Foundation ModelsにGeminiの技術基盤を採用することが決定しています。UCP対応のデータ整備はGoogle以外のAIエコシステムへの対応にも直結するのです。第三に、構造化データの整備はUCP以前にSEO施策としても有効であり、準備にかけた工数が無駄になるリスクが極めて低い点も見逃せません。Schema.orgによる構造化マークアップの強化は、Google検索のリッチリザルト表示にも好影響をもたらすため、UCP展開の有無にかかわらず投資対効果が見込める取り組みです。

Schema.orgとMerchant Centerフィードの二重整備が必要な理由

日本のEC事業者が最初に取り組むべきは、Schema.orgマークアップとMerchant Centerフィードの両方を整備する「二重整備」です。Schema.orgは、ウェブページ上の情報を検索エンジンやAIが機械的に読み取れるようにする構造化データの標準規格です。Merchant Centerフィードは、Googleショッピング向けに商品データを提供するためのデータ供給パイプラインにあたります。

なぜ両方が必要かというと、それぞれがカバーする範囲と利用される場面が異なるためです。Schema.orgマークアップはウェブページに埋め込まれ、Google以外のAIエージェントやクローラーにも情報を提供できる汎用的な仕組みとして機能します。一方、Merchant Centerフィードは、Googleのショッピンググラフに商品情報を直接供給するパイプであり、UCPのGoogle実装において商品がAIに表示される前提条件となっています。Schema.orgだけ対応してもMerchant Centerに情報がなければGoogleのUCP対応とはならず、Merchant Centerだけ対応してもGoogle以外のAI環境には情報が届きません。世界共通のデータ規格としてのSchema.orgと、Google固有のフィード基盤としてのMerchant Centerの双方を整備することが、全方位的なAIコマース対応の基盤となるのです。

在庫・価格・仕様をリアルタイム同期するデータパイプライン構築の実務例

エージェンティックコマースでは、AIが提示した商品の在庫や価格が実際と異なるという事態は、致命的な顧客体験の毀損につながります。このため、在庫・価格・仕様情報をリアルタイムに近い鮮度でMerchant CenterおよびSchema.orgマークアップに反映するデータパイプラインの構築が不可欠です。

実務的なアプローチとしては、自社の基幹システム（受注管理・在庫管理・商品マスター）からのデータを、APIまたはWebhookで中間処理層に連携し、そこからMerchant Center Content APIおよびウェブサイトのJSON-LDマークアップに自動反映する仕組みを構築します。更新頻度の目安として、OpenAIのACPでは15分間隔でのフィード更新が推奨されており、UCPにおいても同等以上の鮮度が求められると想定しておくべきです。特に在庫切れ商品がAI上で購入可能と表示される事態は、注文キャンセルの発生や顧客信頼の低下を招くため、在庫ステータスの同期は最優先で対応する必要があります。自社で開発リソースが不足する場合は、Shopifyなどフィード自動同期機能を備えたコマースプラットフォームの採用も選択肢です。

国内主要カートがUCP対応ロードマップを公開していない現状と確認すべき質問

2026年3月時点で、日本国内の主要ECカートシステム（Shopify Japan以外）は、UCPへの対応ロードマップを公式に公開していない状況です。この状況は日本のEC事業者にとって不確定要素ですが、受け身で待つのではなく、自社が利用しているカートベンダーに対して積極的に確認の対話を始めることが推奨されます。

• 御社のカートシステムは、UCPやSchema.orgへの対応ロードマップをお持ちですか
• Merchant Center Content APIとのデータ連携は自動化されていますか、それとも手動フィード更新が前提ですか
• 在庫・価格のリアルタイム同期に対応できるWebhookまたはAPIは提供されていますか
• AIエージェントが必要とする拡張属性（FAQ、互換品情報、成分表示など）を商品データに追加する仕組みはありますか
• 将来的に複数のエージェントコマースプロトコル（UCP、ACPなど）に同時対応する設計方針はありますか

これらの質問はクレームではなく、カートベンダーとともにAIコマース時代を生き残るための戦略的対話です。Shopifyは既にUCPネイティブ対応を実装しており、他のカートベンダーの対応状況と比較する判断材料にもなります。自社のカート選定を再検討するタイミングにもなり得るため、中長期のプラットフォーム戦略と合わせて検討することが重要です。

FAQ・互換品・成分情報などAIが判断材料にする拡張属性の整備手順

Googleは、エージェンティックコマース時代に対応するため、Merchant Center向けの新しいデータ属性を発表しています。これらは従来のキーワードベースの属性を超え、AIが商品の適合性を判断するために活用する拡張属性です。具体的には、よくある質問への回答（FAQ）、互換アクセサリや代替商品の情報、使用制約や認証情報などが含まれます。

1. 自社商品に寄せられる問い合わせやレビューを分析し、頻出の質問をFAQ形式で構造化する
2. 互換性情報（この商品と一緒に使えるアクセサリ、この商品の代替になる商品）を体系的に整理する
3. 成分・原材料・アレルゲン・認証マーク（有機JAS、特定保健用食品など）を機械可読な形式で記述する
4. 上記データをMerchant Centerフィードの拡張属性フィールドおよびSchema.orgのJSON-LDに反映する
5. 定期的に属性の網羅性と正確性を監査し、不足があれば追加する

これらの拡張属性は、AIエージェントがユーザーの質問に答える際の判断材料として直接利用されます。「この製品は○○アレルギーでも使えますか」「このケースはiPhone 16に対応していますか」といった具体的な問いに対して、エージェントが正確に回答できるかどうかは、拡張属性の整備状況に左右されるのです。

2026年以降のEC戦略でAIに選ばれる商品となるための実務条件

UCPやACPへの技術的な対応だけでは、AIエージェントに自社商品が選ばれる保証はありません。プロトコルは「どうやって取引するか」を定義しますが、「どの商品をエージェントが推薦するか」は別の問題です。ここでは、AIに選ばれるために事業者が整えるべき実務条件を具体的に解説します。

価格・在庫・配送速度だけでランク付けされる汎用品化リスクへの対抗策

エージェンティックコマースが普及すると、AIが複数の小売業者の商品を横断的に比較し、最適な選択肢をユーザーに提示するようになります。この際、AIの判断基準が価格・在庫の有無・配送速度といった定量的指標に偏れば、ブランド独自の付加価値が評価されず、すべての商品が汎用品として扱われるリスクがあります。

このリスクへの対抗策は、AIが読み取れる形式でブランドの差別化要素を構造化データとして提供することです。たとえば、サステナビリティへの取り組み、独自の製法や素材の特徴、アフターサービスの充実度、顧客レビューの評価傾向といった情報を、Schema.orgやMerchant Centerの属性として明示的に記述します。AIは構造化されたデータを根拠に推薦理由を生成するため、「この商品はリサイクル素材100%で、レビュー評価4.8の高評価」といった文脈をエージェントが提示できれば、価格だけの比較から脱却できる可能性があります。また、独自のサブスクリプションモデルやカスタマイズオプションなど、価格比較が困難な付加価値を商品設計に組み込むことも、汎用品化への構造的な対策となるでしょう。

ロイヤリティ報酬やDirect Offersなどエージェント向け販促の設計指針

Googleは、UCP上での販促手段としてDirect Offersという広告パイロットプログラムを導入しています。これは、購買意図の高いユーザーに対してAI Mode内で特別な割引（例：20%オフ）を直接提示できる仕組みです。従来の検索広告がクリックを誘導するものだったのに対し、Direct Offersは購入の瞬間に値引きを提供するという点で、より直接的な販促手段といえます。

エージェント向け販促を設計する際には、オファーの情報もまた「構造化データとしてAIに読み取らせる」という発想が重要です。割引率・適用条件・有効期限・対象商品といったオファー情報を機械可読な形式で提供することで、AIエージェントがユーザーとの対話の中で適切なタイミングでオファーを提示できるようになるのです。ロイヤリティプログラムとの連携も今後のUCPロードマップに含まれており、「このユーザーはゴールド会員なので追加5%割引が適用されます」といったパーソナライズされた販促がエージェント経由で実行される世界が見えてきています。販促の設計単位が「ページ上のバナー」から「エージェントに渡すデータオブジェクト」に変わるという根本的な転換を意識することが、今後のマーケティング戦略の前提となるでしょう。

UCP・ACP両対応のミドルウェア活用で開発工数を半減させる実装戦略

UCPとACPの両方に対応するとなると、2つの異なるプロトコルに対して個別にデータフィード生成・API統合・決済フロー接続を行う必要があり、開発工数が膨大になるという懸念があります。この問題を解決するアプローチとして注目されているのが、エージェンティックミドルウェアの活用です。

Mercury GXOやPrestaといったミドルウェアプラットフォームは、加盟店が一度自社のコマースバックエンドと統合するだけで、UCPマニフェストとACPフィードの両方を自動生成するサービスを提供し始めています。これにより、プロトコルごとの個別実装を避け、抽象化レイヤーを通じた統一的な管理が可能になります。Shopifyを利用している事業者はAgentic Storefrontsが同様の役割を果たすため、追加のミドルウェアは不要なケースが多いでしょう。独自プラットフォームやレガシーシステムを運用している事業者こそ、ミドルウェアの導入効果が大きくなります。将来的にUCPやACP以外の新しいプロトコルが登場した場合にも、ミドルウェア側のアップデートで対応できるため、プロトコル変遷への耐性を確保するという戦略的意義もあります。

Agent Share of Voiceを指標にしたAI検索可視性モニタリングの始め方

従来のSEOではGoogle検索結果での表示順位やクリック率が主要なKPIでしたが、エージェンティックコマースの時代には新たな指標が必要です。その一つとして注目されているのが「Agent Share of Voice」、すなわちAIエージェントが商品を推薦する頻度や文脈における自社商品の占有率です。

Agent Share of Voiceのモニタリングを始めるには、まず自社商品カテゴリーの主要なクエリに対して、AI Mode・Gemini・ChatGPTがどの商品を推薦しているかを定期的に調査するところからスタートします。手動での確認から始めても構いませんが、規模が拡大すれば専用のAI検索可視性ツールの導入が有効になります。重要なのは、ブランドが言及されること、商品が推薦されること、そして実際に購入につながること、この3段階を区別して計測する視点です。ブランド名がAIの回答に含まれていても、具体的な商品が購入候補として提示されなければ売上にはつながりません。逆に、ブランド名は出なくても商品スペックの合致で推薦されるケースもあります。この3層の可視性を定点観測し、競合との比較を行うことで、データ整備のどこに改善余地があるかが見えてきます。

商品データ品質を月次で監査し改善サイクルを回す運用体制の構築方法

UCPやACPへの対応は、一度実装すれば完了するものではありません。商品データの品質は時間とともに劣化する性質があり、新商品の追加、価格改定、仕様変更、在庫状況の変動が日常的に発生します。AIエージェントに常に正確な情報を提供し続けるには、月次での品質監査と改善サイクルの仕組みが欠かせません。

具体的な運用体制としては、まず月次の監査チェックリストを作成するところから着手しましょう。チェック項目には、Merchant Centerフィードのエラー率、Schema.orgマークアップの検証結果、在庫データと実在庫の乖離率、拡張属性（FAQ・互換品情報・成分データ）の網羅率、そしてAI検索での自社商品の表示状況などを含めます。監査で検出された問題は、優先度をつけて改善タスクとして管理し、次月の監査で改善効果を確認するPDCAサイクルを回していく形が理想的です。この運用はEC運営チーム・商品管理チーム・開発チームの横断的な協力が必要であり、専任の担当者またはチームを配置することが理想的です。エージェンティックコマースが本格化する前に運用体制を確立しておけば、日本展開時に即座に最適化された状態でスタートできる優位性を確保できるでしょう。