ユニバーサルコマースプロトコル（UCP）の設計思想

コマースは人類が最も長く続けてきた取引であり、あらゆる場所に存在します。しかし、その形は決して一様ではありません。Shopifyは20年以上にわたり、数十億件の取引と数百万のマーチャントを通じて、コマースの複雑さを学び続けてきました。そして今もなお、その奥深さに謙虚な姿勢で向き合っています。

例えば、決済オプションやルールは、カートの内容、購入者の属性、マーケットの特性によって変化します。ディスカウントの積み上げや組み合わせには、税法に匹敵するほど複雑なルールが存在します。フルフィルメントの選択肢は、配送方法、タイミング、地域などの組み合わせで膨大な数に膨れ上がります。そして、これらはほんの一例に過ぎません。こうした複雑さは、システムのバグではありません。むしろ、多様な小売事業者のニーズが生み出した、自然な特性なのです。

ユニバーサルコマースプロトコル (UCP) は、こうしたコマースの複雑な現実に対応するため、柔軟性を重視して設計されました。ShopifyはGoogleと共同でUCPを開発し、AIエージェントがあらゆるマーチャントとスムーズに接続・取引できるオープンスタンダードを実現しました。

UCPの仕組みはシンプルです。まず、マーチャントは自社がサポートする機能（独自のカスタム機能を含む）を宣言します。次に、AIエージェントはその機能を発見し、自身が対応できる範囲を確認した上で、取引を進めます。UCPは、このようなマーチャントとエージェント間の「発見」と「すり合わせ」の仕組みを標準化し、さらにエージェントと人間の両方がコマースをプログラムできるようにするコア機能を提供します。

機能と拡張

モノリシックなプロトコルは、最終的に複雑さに押しつぶされます。変化に対応しようとしても柔軟性がなく、新しい要件に追従するにはスピードが足りません。一方、適切に階層化されたプロトコルは、役割を明確に分離し、APIを整理し、コンポーザビリティ（機能を組み合わせて使える性質）を実現することで、長く生き残ります。TCP/IPがその好例です。UCPもこの設計思想をコマースに応用し、役割を以下のレイヤーに分けています。

Shopping service（ショッピングサービス）：取引の基本要素を定義します（チェックアウトセッション、商品項目、合計金額、メッセージ、ステータスなど）
Capabilities（機能）：主要な機能領域を追加します（Checkout、Orders、Catalogなど）。それぞれ独立してバージョン管理されます
Extensions（拡張機能）：特定の業務に特化したデータ構造を組み合わせることで、機能をさらに強化します

フルフィルメントを例に見てみましょう。実際の商取引では、配送、店舗受取、ローカルデリバリー、分割発送、予約注文、配達時間指定、サブスクリプションスケジュールなど、多様なフルフィルメント方法が使われています。

UCPにはdev.ucp.shopping.fulfillmentという拡張機能があり、よく使われるケースに対応しています。ただし、この拡張機能がすべてのケースに対応する必要はありません。なぜなら、特殊な要件を持つマーチャントは、独自の拡張機能を自由に定義できるからです。そして、ある拡張機能が多くのマーチャントに使われるようになれば、それをUCPの標準機能として取り込むこともできます。このように、プロトコルは柔軟に進化していきます。

拡張機能は、コアのデータ構造に追加で組み込まれます。フルフィルメント拡張が有効な場合のチェックアウトレスポンスは次のようになります。

{
"status": "incomplete",
"line_items": [...],
"totals": [...],
"fulfillment": {
"methods": [{
"id": "shipping",
"type": "shipping",
"line_item_ids": [...],
"groups": [{
"id": "pkg_1",
"line_item_ids": [...],
"selected_option_id": "standard",
"options": [
{ "id": "standard", "title": "Standard Shipping", "description": "5-7 days", "total": 500 },
{ "id": "express", "title": "Express Shipping", "description": "2-3 days", "total": 1200 }
]
}]
}]
}
}

コアのチェックアウトスキーマは、すべての取引に共通する基本要素のみを定義しており、フルフィルメントの詳細については関知しません。フルフィルメント拡張機能が、配送グループや配送オプションといった情報を追加します。新しい機能、例えば配達時間指定を追加したい場合はどうでしょうか？各拡張機能は独立して更新できるため、コアに影響を与えることなく機能を追加できます。

つまり、マーチャントは自社に必要な機能だけを実装すればよく、エージェントは対応できる機能だけを選んで処理します。こうして、プロトコルは既存の機能を壊すことなく、柔軟に進化し続けることができるのです。

機能のオープンマーケット、承認委員会は不要

マーチャントとエージェントの両方が、サポートする内容を宣言するプロファイルを公開します。ディスカバリーはこれらのプロファイルを取得するプロセスです。ネゴシエーションは、それらの共通部分を計算します。

マーチャントのサイトの/.well-known/ucpに公開されるマーチャントプロファイルの例：

{
"ucp": {
"version": "2026-01-11",
"services": {
"dev.ucp.shopping": {
"version": "2026-01-11",
"spec": "https://ucp.dev/specs/shopping",
"mcp": {
"schema": "https://ucp.dev/services/shopping/mcp.openrpc.json",
"endpoint": "https://merchant.example.com/ucp/mcp"
},
"embedded": {
"schema": "https://ucp.dev/services/shopping/embedded.openrpc.json"
}
}
},
"capabilities": [
{
"name": "dev.ucp.shopping.checkout",
"version": "2026-01-11",
"spec": "https://ucp.dev/specs/shopping/checkout",
"schema": "https://ucp.dev/schemas/shopping/checkout.json"
},
{
"name": "dev.ucp.shopping.fulfillment",
"version": "2026-01-11",
"spec": "https://ucp.dev/specs/shopping/fulfillment",
"schema": "https://ucp.dev/schemas/shopping/fulfillment.json",
"extends": "dev.ucp.shopping.checkout"
},
{
"name": "com.loyaltyprovider.points",
"version": "2026-02-01",
"spec": "https://loyaltyprovider.com/specs/points",
"schema": "https://loyaltyprovider.com/schemas/points.json",
"extends": "dev.ucp.shopping.checkout"
}
]
},
"payment": {
"handlers": [...]
}
}

エージェントプロファイル：エージェントも機能を宣言します：

{
"ucp": {
"version": "2026-01-11",
"capabilities": [
{
"name": "dev.ucp.shopping.checkout",
"version": "2026-01-11",
"spec": "https://ucp.dev/specs/shopping/checkout",
"schema": "https://ucp.dev/schemas/shopping/checkout.json"
},
{
"name": "dev.ucp.shopping.fulfillment",
"version": "2026-01-11",
"spec": "https://ucp.dev/specs/shopping/fulfillment",
"schema": "https://ucp.dev/schemas/shopping/fulfillment.json",
"extends": "dev.ucp.shopping.checkout"
}
]
},
"payment": {
"handlers": [
{
"id": "gpay",
"name": "com.google.pay",
"version": "2024-12-03",
"spec": "https://ucp.dev/handlers/google_pay",
"config_schema": "https://ucp.dev/handlers/google_pay/config.json",
"instrument_schemas": ["https://ucp.dev/handlers/google_pay/card_payment_instrument.json"]
}
]
}
}

エージェントがリクエストを送る際、自身のプロファイルURLも一緒に渡します。マーチャント側では、双方が対応できる機能（サポートしている機能、使えるハンドラー、共通の拡張機能）を照合し、その結果を返します。この仕組みは、実はHTTPでもよく使われています。HTTPでは毎回、acceptヘッダー、コンテンツタイプ、エンコーディングなどを使って同様の調整を行っています。

具体例：ロイヤリティプログラムの拡張機能

マーチャントプロファイルに含まれるcom.loyaltyprovider.pointsを例に見てみましょう。これは、マーチャントがロイヤリティプロバイダーから導入した拡張機能です。

この拡張機能に対応していないエージェントの場合、ロイヤリティ関連の情報は単純に無視されます。一方、対応しているエージェントであれば、リワードオプションの提案、会員情報の入力、ポイント交換といった機能を提供できます。

重要なのは、同じマーチャント、同じエンドポイントを使いながら、エージェントの対応状況に応じて機能が自動的に調整される点です。もしエージェントが対応できない機能があっても問題ありません。エージェントは自分ができる部分だけを処理し、残りは購入者に引き継ぎます。このシームレスな引き継ぎは、UCPに標準で組み込まれている機能です（詳細は後述）。

承認不要の仕組み

では、loyaltyproviderはどうやってcom.loyaltyprovider.pointsを定義する権限を得たのでしょうか？実は、承認申請は一切不要でした。中央レジストリも、承認委員会も存在しません。

UCPは逆ドメイン命名規則を採用しています：

dev.ucp.shopping.* → ucp.devが管理
com.loyaltyprovider.* → loyaltyprovider.comが管理

つまり、ドメインを所有していれば、そのネームスペースを自由に使えます。各参加者は、宣言された機能がどこから提供されているかを確認するだけです。中央の管理組織による承認プロセスではなく、ドメイン所有権によって信頼性を担保する仕組みです。

こうして実現するのが、コマースそのものと同じように自由に進化する、機能のオープンマーケットです。

まとめ

真のオープンプロトコルは、仕様書を読むだけでなく、誰でも自由に拡張できることが重要です。コマースは常に変化し、多様な形態をとり続けます。UCPはこうした現実に対応できるよう設計されており、会議や承認プロセスなしに改善を重ね、エージェント型コマースとともに進化し続けます。

コマースには協働が必要

UCPは、人間とAIエージェントが協力して取引を完了できるように設計されています。なぜなら、すべての取引をエージェントだけで処理できるわけではないからです。

チェックアウトには大きく分けて2つのパターンがあります。1つ目は、完全にAPI経由で自動完了できるもの。2つ目は、人間の関与が必要なものです。人間の関与が必要になる理由は、規制上の制約、マーチャントのポリシー、あるいはエージェントがまだ対応していない機能があるためです。

ここで重要なのは「まだ対応していない」という点です。今日は人間に引き継がれた（エスカレーションされた）取引でも、エージェントの機能が進化すれば、将来的には自動で処理できるようになる可能性があります。ただし、規制や複雑な判断が必要な取引など、常に人間の参加が必要なケースも存在します。

UCPは、シンプルなチェックアウトのステートマシンを使って、この協働の仕組みを実現しています。チェックアウトは次の3つの状態を経て進行します：

incomplete（未完了）：必要な情報がまだ揃っていません。エージェントはAPIを使って不足情報の取得を試みます
requires_escalation（人間への引き継ぎが必要）：購入者の直接入力が必要です。エージェントはまずAPI経由での解決を試み、対応できない場合はcontinue_urlを使って購入者に引き継ぎます
ready_for_complete（完了準備完了）：必要な情報がすべて揃いました。エージェントはこの状態になれば、プログラムで自動的にチェックアウトを完了できます

人間への引き継ぎ方法

エージェントだけでは取引を完了できない場合、マーチャントのレスポンスには、状況を説明する構造化されたコンテキスト情報と、continue_url（継続URL）が含まれます。

{
"line_items": [...],
"totals": [...],
"status": "requires_escalation",
"continue_url": "https://merchant.com/checkout/session_abc123",
"messages": [{
"type": "error",
"severity": "requires_buyer_review",
"code": "high_value_order",
"content": "Orders over $1000 require additional verification before completion."
}]
}

購入者はこのcontinue_urlにアクセスすることで、エージェントが中断した場所から正確に購入手続きを再開できます。つまり、取引が途中で放置されることはありません。エージェントが対応できない機能に遭遇しても、プロトコルが自動的にスムーズな引き継ぎを実現します。

スムーズな引き継ぎで実現する協働

Embedded Checkout Protocol (ECP) は、人間への引き継ぎをシームレスに実現します。ECPが提供する主な機能は以下の通りです：

エージェントとマーチャント間の双方向メッセージング
エージェントの画面内に埋め込まれるチェックアウト
認証情報とコンテキスト情報の安全な双方向共有

これにより、購入者は使い慣れたUIでサポートを受け続けられ、マーチャントは取引完了に必要な構造化データを確実に取得できます。

人間への引き継ぎが必要になった場合、エージェントは提供されたcontinue_urlを読み込んで、埋め込みチェックアウトを表示します。

ECPは、JSON-RPC 2.0を使ってマーチャントとエージェント間の通信チャネルを確立します。このチャネルを通じて、マーチャントからは処理状態の更新情報が送られ、エージェントからは認証情報やコンテキスト情報が送られます。また、一部の機能をホスト（エージェント）のサービスに委任することもできます。例えば、決済情報の収集にはホストのネイティブ決済画面を使い、住所選択にはエージェントのウォレットに保存された情報を活用できます。

実績のある技術基盤

この仕組みは、ShopifyのCheckout Kitをベースにしています。Shopifyは長年にわたり埋め込みチェックアウトを大規模に運用してきた実績があり、その経験をオープンプロトコルとして標準化しました。

さらに、高度なブランディング機能とPCIv4コンプライアンスに準拠した強固なサンドボックス環境を組み合わせることで、エージェントとマーチャントが真に協力できる仕組みを実現しています。

開発者は、UCPの仕様に沿って実装するか、Checkout Kitを活用することで、わずか数行のコードでこの高度な体験をすべてのShopifyマーチャントに提供できます。

双方のニーズに応える柔軟な決済

決済に関わるステークホルダーには、それぞれ異なるニーズがあります。

マーチャントの視点：マーチャントは、決済サービスプロバイダー (PSP) との関係を何年もかけて最適化してきました。ルーティングルール、不正検知モデル、地域ごとの対応範囲などを調整しています。

購入者の視点：購入者にも独自の好みがあります。保存済みのカード情報、デジタルウォレット、後払い決済など、好みの決済方法は人それぞれです。

UCPは、双方のニーズを柔軟に表現できるようにし、取引ごとに最適な決済方法を動的に選択できます。決済ハンドラーの選択は、カートの内容、購入者の所在地、取引金額などの条件によって変わります。UCPプロファイルでマーチャントとエージェントがそれぞれ対応できる決済方法を宣言し、チェックアウト時に実際に利用可能な方法を提示する仕組みです。

エージェントプロファイルでは、エージェントが対応できる決済方法を宣言します：

{
"payment": {
"handlers": [
{
"id": "shop_pay",
"name": "com.shopify.shop_pay",
"version": "2026-01-11",
"spec": "https://shopify.dev/ucp/handlers/shop_pay",
"config_schema": "...",
"instrument_schemas": [...]
},
{
"id": "gpay",
"name": "com.google.pay",
"version": "2024-12-03",
"spec": "https://ucp.dev/handlers/google_pay",
"config_schema": "...",
"instrument_schemas": [...]
}
]
}
}

マーチャント側のレスポンスでは、そのカートで実際に利用可能な決済ハンドラーを返します：

{
"line_items": [...],
"totals": [...],
"payment": {
"handlers": [
{
"id": "shop_pay",
"name": "com.shopify.shop_pay",
"version": "2026-01-11",
"spec": "https://shopify.dev/ucp/handlers/shop_pay",
"config_schema": "...",
"instrument_schemas": [...],
"config": { "shop_id": "example-shop-123" }
},
{
"id": "gpay",
"name": "com.google.pay",
"version": "2024-12-03",
"spec": "https://ucp.dev/handlers/google_pay",
"config_schema": "...",
"instrument_schemas": [...],
"config": { "gateway": "stripe", "gateway_merchant_id": "acme_stripe_123" }
}
]
}
}

この例では、Shop PayとGoogle Payの両方がマーチャントとエージェントの双方でサポートされています。そのため、購入者はどちらの決済方法を使うか選択できます。

ここで重要なのは、決済オプションが状況に応じて動的に変わるという点です。カートの内容を変更したり、購入者の地域が変わったり、その他の条件が変わると、利用可能な決済ハンドラーも変化する可能性があります。すべての取引において、マーチャントとエージェントが双方向で最適な決済方法をすり合わせる仕組みです。つまり、決済が本来あるべき柔軟な形で機能しています。

従来の統合方法との違い

決済ハンドラーの仕組みは、拡張機能と同様に、従来の統合作業の考え方を根本から変えます。

従来は、プロトコル側があらゆる決済方法を定義し、対応する必要がありました。UCPでは異なるアプローチを取ります。各決済プロバイダー（Google、Shopify、地域のPSPなど）が、それぞれ独自のハンドラー仕様を公開します。マーチャントは受け入れたいハンドラーを宣言するだけで、エージェントがその中から対応できるものを選び、その仕様に従って処理します。

この仕組みにより、新しい決済方法をエコシステムに追加する際、中央の承認委員会による投票や、プロトコルのコアバージョンの更新を待つ必要がありません。各プロバイダーが自由に新しいハンドラーを追加でき、エコシステム全体が自然に成長していきます。

UCPでビルドする

ここまでの内容は、UCPのすべての機能を網羅的に説明したものではありません。むしろ、UCPが「なぜ」このように設計されたのかという背景にある考え方を説明してきました。

UCPの設計を形作った主要な原則は以下の通りです：

ディスカバリーとすり合わせ：マーチャントとエージェントが互いの機能を発見し、対応可能な範囲を調整する
階層化された拡張性：コアを安定させながら、拡張機能で柔軟に機能を追加できる
スムーズなハンドオフ：エージェントと人間が協働できる仕組み
柔軟な決済：状況に応じて最適な決済方法を選択できる

これらの原則により、UCPはコマースの複雑さを適切に表現し、プログラムから操作できるようにしています。

すでに広がるエコシステム

UCPはShopifyとGoogleが共同で開発しました。現在、Etsy、Target、Walmart、Wayfair、そして数百万のShopifyマーチャントがサポートしています。

UCP仕様はすでに公開されており、今すぐ開発を始められます。ぜひ仕様を読んで、GitHubでコントリビュートし、私たちと一緒にコマースの未来を構築してください。

オープンなエコシステムは、あなたの参加を待っています。

本記事は Shopify Engineering ブログの英語記事（著者：Ilya Grigorik, Distinguished Engineer at Shopify）を日本語に翻訳したものです。