UCP（Universal Commerce Protocol）とは — Googleが推進するエージェンティックコマースの共通言語

UCP（Universal Commerce Protocol）とは何か

2026年1月11日、GoogleのCEOサンダー・ピチャイは全米小売業協会（NRF）の年次カンファレンスで、エージェンティックコマースの基盤となる新しいオープン標準を発表しました。UCP（Universal Commerce Protocol）です。

背景にあるのは、AIエージェントがECサイトと取引するための「共通言語」が存在しないという問題でした。Google検索、Gemini、Shopifyのエージェント、サードパーティのAIアシスタント。エージェントが増えるたびにマーチャントは個別のAPI統合を行い、マーチャントが増えるたびにエージェント側も個別対応を迫られる。Google開発チームはこの構造を「N x N統合のボトルネック」と呼んでいます。

UCPはこのボトルネックを解消するために設計されました。Google Developers Blogの技術解説によれば、UCPは「N x Nの複雑さを、すべてのコンシューマーサーフェスに対する単一の統合ポイントに集約する」プロトコルです。商品発見、カート構成、チェックアウト、注文管理、決済まで、購買フロー全体を一つの標準でカバーします。

注目すべきは、UCPが単なるGoogleのプロダクトではないことです。Shopify、Etsy、Wayfair、Target、Walmartが共同開発に参加し、Adyen、American Express、Best Buy、Flipkart、Macy's、Mastercard、Stripe、The Home Depot、Visa、Zalandoなど20社以上がエコシステムを支持しています。仕様はucp.devで公開され、GitHubリポジトリでオープンソースとして開発が進んでいます。

.well-known/ucp — Web標準の発想をコマースに持ち込む

UCPの設計思想を最も端的に表しているのが、.well-known/ucpマニフェストの仕組みです。

robots.txtはクローラーにサイトのアクセス許可を伝え、sitemap.xmlは検索エンジンにページ構造を伝えます。同じ発想で、UCPではマーチャントが自社ドメインの/.well-known/ucpにJSON形式のプロファイルを公開します。このプロファイルには、対応するサービス（ショッピング等）、利用可能なCapability（チェックアウト、カタログ等）、決済ハンドラの設定が記述されます。

UCP公式仕様によると、マニフェストの基本構造は次のようになっています。バージョン情報、サービスレジストリ（RESTエンドポイントとOpenAPIスキーマへの参照）、Capabilityリスト、そして決済ハンドラの構成です。名前空間にはリバースドメイン方式（dev.ucp.shopping.checkout等）が採用されており、公式Capabilityと第三者による拡張を明確に区別できます。

この設計がもたらす最大のメリットは、事前の登録申請やプラットフォームの承認が不要であることです。マーチャントがマニフェストを公開すれば、あらゆるAIエージェントがそれを発見し、対応するCapabilityに基づいて取引を開始できます。Shopifyのエンジニアリングブログはこの仕組みを「HTTPのコンテンツネゴシエーション」に例えています。エージェントとマーチャントが互いの対応機能の「交差集合」を計算し、共通のCapabilityで通信するモデルです。

では、なぜGoogleは集中型のマーケットプレイスモデルではなく、この分散型アプローチを選んだのか。答えはWebの歴史にあります。Webが成功したのは、Webサイトの公開にGoogleの許可が不要だったからです。UCPは同じ原則をコマースに適用しています。マーチャントが自社のデータを自社サーバーで管理し続けられること。特定のプラットフォームに依存しないこと。この「マーチャント主導」の設計思想が、ACPとの根本的な違いでもあります。

技術アーキテクチャ — 4つのレイヤーで構成されるプロトコル

UCPはモノリシックなシステムではありません。Google Developers Blogの技術解説が詳述するように、Discovery、Communication、Execution、Paymentの4つのレイヤーに分離された階層型アーキテクチャです。各レイヤーが独立して進化でき、明確に定義されたインターフェースを通じて連携します。

Discoveryレイヤー

前述の.well-known/ucpマニフェストがこのレイヤーの中核です。エージェントはマーチャントのドメインにアクセスし、マニフェストを取得することで、そのマーチャントが何を販売し、どのCapabilityに対応しているかを把握します。仕様では、エージェントとマーチャント双方が対応するCapabilityの交差集合を算出する「サーバーセレクト」アルゴリズムが定義されています。

Communicationレイヤー

UCPが他のコマースプロトコルと一線を画すのが、複数のトランスポートプロトコルへの対応です。プライマリはHTTP/1.1以上のRESTful API（JSON形式）ですが、MCP（Model Context Protocol）やA2A（Agent2Agent）にもバインディングが用意されています。

具体的には、RESTはOpenAPI 3.x、MCPはOpenRPC、A2AはAgent Card Specificationでそれぞれ定義されます。さらにShopifyが開発したEmbedded Protocol（EP）は、エージェントがマーチャントのチェックアウトUIを埋め込み表示するためのJSON-RPC 2.0ベースの双方向通信プロトコルです。

Executionレイヤー

ここが購買フローの実体です。Checkout、Cart、Catalog、Order Management、Discount、Identity LinkingといったCapabilityが定義されており、それぞれが独立してバージョニングされます。Capabilityはextendsフィールドで親Capabilityを拡張できる設計になっており、例えばDiscountはCheckoutの拡張として機能します。

Paymentレイヤー

決済は「Payment Instrument（消費者が使う決済手段）」と「Payment Handler（決済を処理するプロバイダー）」を分離する設計です。UCP仕様が定義する「Trust Triangle」モデルでは、ビジネスとクレデンシャルプロバイダー、プラットフォームとクレデンシャルプロバイダー、プラットフォームとビジネスの3つの信頼関係が構成されます。クレデンシャルは一方向（プラットフォーム→ビジネス）にのみ流れ、エージェントが生のカード番号に触れることはありません。

Capability の全体像 — 2026年1月から3月への進化

UCPの初期リリースはCheckout、Identity Linking、Order Managementの3つのCapabilityで構成されていました。2026年3月19日のアップデートで、プロトコルの対応範囲は大幅に拡張されます。

Cart API — 「1商品1セッション」からの脱却

初期バージョンでは、各商品のインタラクションが個別のイベントとして扱われていました。SearchEngineJournalの報道によると、3月のアップデートで追加されたCart APIは、永続的でステートフルなカートセッションオブジェクトを導入しました。

エージェントは複数の商品を一度にカートへ追加し、数量の変更やディスカウントコードの適用を行った上で、チェックアウトに移行できます。「シャンプーとコンディショナーをまとめて買う」という、人間にとっては当たり前の行動が、プロトコルレベルで標準化されたわけです。

Catalog API — フィードからライブクエリへ

従来のECプラットフォーム統合では、商品データを事前にフィードとして「提出」するモデルが一般的でした。Catalog APIはこのモデルを逆転させます。エージェントがマーチャントのサーバーに直接クエリを送り、バリアント、在庫数、リアルタイム価格を取得する「プル型」のアプローチです。

この違いは実務上、大きな意味を持ちます。フィードベースのモデルでは、価格変更や在庫切れの反映にタイムラグが生じます。Catalog APIでは、エージェントが購入を検討するまさにその瞬間のデータが返されるため、「カートに入れたら在庫切れだった」という体験を構造的に防止できます。

Identity Linking — ロイヤルティプログラムとの接続

エージェント経由で購入したにもかかわらず、会員割引が適用されない。送料無料の特典が使えない。このような体験は消費者のエージェント離れを招きます。Identity Linkingは、OAuth 2.0ベースでマーチャントの会員システムとエージェントを連携させ、ログイン状態と同等の特典をエージェント経由でも提供する仕組みです。

チェックアウトフロー — エージェントが購入を完了するまで

UCPを通じた購買がどのように流れるか、具体的なフローを見てみます。

まず、エージェントがマーチャントの/.well-known/ucpにアクセスし、対応するCapabilityと決済ハンドラを確認します。次にCatalog APIで商品情報を取得し、ユーザーの要件に合う商品を選定します。

商品が決まると、エージェントはPOSTリクエストでチェックアウトセッションを作成します。マーチャントはセッションIDとラインアイテムの詳細（商品名、価格、税額）を返します。ディスカウントコードがあればPUTリクエストで適用し、マーチャントが合計金額を再計算します。

ここからが決済フローです。UCPの決済はCheckoutのステートマシンに基づいて管理されます。Shopifyの実装によると、セッションには3つのステータスがあります。incomplete（情報が不足）、requires_escalation（人間の介入が必要、continue_url経由でブラウザにハンドオフ）、ready_for_complete（完全自律で完了可能）。

requires_escalationは重要な設計判断です。住所の確認、3Dセキュア認証、年齢確認など、人間の判断が必要な場面ではエージェントがブラウザを開き、マーチャントのチェックアウトUIに遷移させます。完全自律型の購入だけでなく、人間とエージェントのハイブリッドフローを標準仕様としてサポートしている点がUCPの現実的な強みです。

AP2との連携 — 決済認可をどう担保するか

UCPが商品発見からチェックアウトまでの「商取引フロー」を標準化するプロトコルであるのに対し、AP2（Agent Payments Protocol）は「決済認可フロー」を標準化するプロトコルです。両者は補完的に機能します。

UCP仕様にはdev.ucp.shopping.ap2_mandateという拡張が定義されています。これはAP2のMandate（暗号署名されたデジタル契約）をUCPのチェックアウトフローに統合する仕組みです。具体的には、ユーザーがエージェントに購入権限を委任したことを暗号学的に証明するVerifiable Digital Credentials（VDC）が、チェックアウトセッションに添付されます。

この統合により、マーチャントは「このエージェントが本当にユーザーの承認を得て購入しているか」を検証可能な形で確認できます。決済手段はGoogle Payをベースにしたトークン化方式が採用されていますが、PayPalなど他の決済手段への対応も設計上想定されています。

コスト面では、UCPを通じた決済はプロセッサー手数料のみの約3.2%です。プラットフォーム手数料は発生しません。月商100万ドルのマーチャントにとって、プラットフォーム手数料4%が上乗せされるACPとの差額は月額約4万ドルに達します。

パートナーエコシステム — 誰が参加し、何を担っているか

UCPのエコシステムは「共同開発パートナー」「エンドースメントパートナー」「オンボーディングパートナー」の3層で構成されています。

最もインパクトが大きいのはShopifyの参画です。Shopifyは単にUCPをサポートするだけでなく、プロトコルの共同開発者としてEmbedded Protocol（EP）を設計しました。Shopifyプラットフォーム上の数百万ストアがUCP対応になることで、中小のマーチャントは自社でプロトコル実装を行う必要がなく、プラットフォーム側の対応だけでエージェンティックコマースに参入できます。

小売業界からは、Walmartが共同開発パートナーとして参画しています。NRFの報道によれば、WalmartはAIエージェント「Sparky」を通じたUCP活用を進めており、Targetも初期実装パートナーとして名を連ねています。2026年2月時点で、EtsyとWayfairが米国のGoogle検索AI ModeおよびGeminiアプリでのUCPパワードチェックアウトを開始しました。

決済エコシステムでは、Visa、Mastercard、American Express、Stripe、Adyen、PayPalが支持を表明しています。特にStripeは、UCPのオンボーディングパートナーであると同時にACPの共同開発者でもあり、両プロトコルに跨がるユニークな立場にあります。

2026年3月のアップデートでは、Merchant Center経由の簡易オンボーディングが発表されました。ローンチパートナーはShopify、Salesforce、Stripe、BigCommerce、Adobe、Commerce Incの6社です。これらのプラットフォームを利用するマーチャントは、プラットフォーム側の統合を通じて、自社での技術的な実装負荷を大幅に軽減できます。

従来のEC統合との違い — なぜUCPが必要なのか

この比較表が示す最も重要なポイントは、スケーラビリティの構造的な違いです。

従来のEC統合モデルでは、新しい販売チャネルが登場するたびにマーチャントは個別のAPI統合を行う必要がありました。Amazon、楽天、Google Shopping、Instagram Shopping。チャネルが増えるほど統合コストは線形に増大します。

UCPはこの「N x N問題」を根本から解決します。マーチャントがUCPマニフェストを公開すれば、そのマニフェストを読めるあらゆるエージェントが取引を開始できます。Google以外のAIエージェントも、UCPに準拠していればマーチャントとの取引が可能です。SearchEngineLandの報道が伝えるように、UCPは特定のプラットフォームへのロックインを回避し、オープンなエージェントエコシステムを実現する設計になっています。

商品データの構造化がこの世界への入り口です。マーチャントの既存バックエンド（商品カタログ、在庫管理、決済システム）がAPI化されていれば、UCPエンドポイントの追加は8〜16時間程度で完了します。

ACPとの関係 — 競合ではなく補完

UCPの理解を深める上で避けて通れないのが、OpenAIとStripeが共同開発したACP（Agentic Commerce Protocol）との関係です。両プロトコルの詳細比較は別記事で解説していますが、要点だけ整理します。

UCPは分散型・マーチャント主導のアプローチです。マーチャントが自社サーバーでデータを管理し、エージェントがそこにアクセスします。ACPは集中型・プラットフォーム仲介型で、マーチャントがOpenAIのインデックスに商品データを提出し、ChatGPT上で発見・購入されるモデルです。

設計思想は対極にありますが、捉える需要が異なるため共存しています。UCPはGoogle検索やGeminiという「購買意図が明確な」チャネルで機能し、ACPはChatGPTの会話という「意図が曖昧な」接点から購買機会を創出します。Google自身もUCPが「ACPと共存するように設計されている」と明言しています。

EC事業者のためのUCP実装ガイド

では、EC事業者はUCPにどう対応すればよいのか。現時点で最も現実的なアプローチを段階別に整理します。

ステップ1: 商品データの機械可読化

UCPの前提として、構造化された商品データが不可欠です。Schema.orgのProduct型マークアップ、Google Merchant Centerへのフィード登録がまだであれば、これが最優先です。UCP Catalog APIは既存のMerchant Centerフィードとも連携できるため、この投資は無駄になりません。

ステップ2: プラットフォーム経由か自社実装かを判断する

Shopify、BigCommerce、Salesforce Commerce Cloud、Adobeを利用しているマーチャントは、プラットフォーム側のUCP対応を待つのが最も効率的です。2026年3月のオンボーディングパートナー発表により、これらのプラットフォームはMerchant Center経由のUCP統合を簡素化する仕組みを構築中です。

自社でECバックエンドを構築している場合は、ucp.devの仕様書とGitHubリポジトリを参照し、/.well-known/ucpマニフェストの公開から始めます。最低限必要なのはCheckout Capabilityの実装です。

ステップ3: 決済ハンドラの設定

決済面では、自社のPSP（Payment Service Provider）がAP2ロードマップを持っているかを確認します。Stripe、Adyen、PayPalは既にUCPエコシステムに参画しており、PSP側の対応が進めばマーチャント側の統合負荷は大幅に軽減されます。

ステップ4: デュアルプロトコル戦略の検討

中長期的には、UCPとACPの両方に対応する「デュアルプロトコル戦略」が標準になりつつあります。共通のバックエンドAPI（商品カタログ、在庫、決済）を整備した上で、両プロトコルのエンドポイントを実装するモデルです。

今後の展望

UCPはまだ進化の初期段階にあります。2026年1月のローンチから3か月で、Capability数は3から6以上に拡大し、オンボーディングの簡素化も進んでいます。EtsyとWayfairでの本番チェックアウトが稼働し、Shopify・Target・Walmart・Best Buy・Home Depotの統合も控えています。

プロトコルの設計上、ショッピング以外の業種（旅行、サービス予約、B2B調達など）への拡張も想定されています。名前空間の仕組みがこれを可能にしており、dev.ucp.travelやdev.ucp.b2bといった新しいサービス定義が、既存のインフラを壊すことなく追加できます。

エージェンティックコマースが「AIエージェントが購買を代行する時代」だとすれば、UCPはその時代のHTTPになろうとしているプロトコルです。オープンで、分散型で、マーチャントがデータの管理権を保持できる。Webが成功した原則をそのままコマースに適用する。この設計思想に20社以上が賛同しているという事実が、UCPの方向性の正しさを示唆しています。

まとめ

UCPはGoogleが主導し、業界全体が支えるエージェンティックコマースのオープン標準です。.well-known/ucpマニフェストによる分散型発見、REST・MCP・A2Aの複数トランスポート対応、AP2との決済連携。これらの設計は「特定のプラットフォームに依存しない、マーチャント主導のエージェント対応」という明確なビジョンに基づいています。EC事業者にとっての第一歩は、商品データの構造化と自社プラットフォームのUCP対応状況の確認です。エージェントが購買の主役になる時代に向けた準備は、今始める価値があります。