Shopify の新しい Agentic Commerce Platform（エージェンティック・コマース・プラットフォーム） は、AI 搭載エージェントをマーチャントのストアに直接接続することで、開発者がショッピング体験を構築する方法を大きく変えつつあります。
従来のようにユーザーが UI を操作して商品を閲覧するのではなく、AI アシスタントがユーザーに代わって、商品探索からチェックアウトまでの一連の処理を担えるようになります。
本記事では、Shopify のエージェンティック・エコシステムを構成する中核要素――Shopify Catalog、Storefront MCP、UCP（Universal Commerce Protocol）、Checkout MCP、Checkout Kit――を分解して解説し、開発者がそれらをどのように活用できるのかを探ります。
各コンポーネントの役割、使用すべきタイミングやユースケース、ヘッドレス構成やマルチリージョン統合におけるパターン、そしてそれらを組み合わせることで効果を最大化する実践的な構成例についても取り上げます。
※ 注記：ここで言う「MCP」とは、AI エージェントに対してコマース機能を公開する Shopify の Model Context Protocol サーバーを指します。「Multi-Currency Pricing（複数通貨価格設定）」とは別物ですが、複数通貨に関する考慮事項についても後ほど触れます。
Shopify エージェンティック・コマースとは何か？
エージェンティック・コマースとは、買い物客のニーズを理解し、会話型インターフェースの中で購買体験の全工程を実行できる AI アシスタントを指します。
Shopify の目標は、すべてのストアを「デフォルトでエージェント対応（agent-ready by default）」にすることです。そのために、数百万のマーチャントと強力な AI プラットフォームを接続するための「インフラ」を提供しています。
Google の Gemini、Microsoft の Copilot、OpenAI の ChatGPT といった主要な AI チャネルは、実質的に新しいコマースのストアフロントになりつつあります。
ユーザーは Web サイトを探しに行く代わりに、AI に対して
「200ドル以下で、カナダに配送可能な防水ジャケットを探して」
と尋ねるだけで、エージェントが Shopify ストア群を横断的に検索し、選択肢を提示し、さらにはチャット内で購入まで完了させることが可能になります。
このようなシームレスな体験を実現するために、Shopify は一連の技術群とオープンプロトコルを導入しました。その中核にあるのが UCP（Universal Commerce Protocol） です。
UCP は Google と共同開発されたオープンスタンダードであり、AI エージェントとコマースシステムの間をつなぐ「ユニバーサル翻訳機」 の役割を果たします。
UCP は、エージェント、マーチャント、決済プロバイダーなどが、一貫性とセキュリティを保った共通言語・基本要素（プリミティブ）で通信できるように定義されています。
UCP がなければ、マーチャントや開発者は AI プラットフォームごとに個別の連携を実装しなければなりません。しかし UCP を使えば、一度の統合で、あらゆる場所で動作します。
Shopify は、この UCP を MCP サーバー（総称） と呼ばれる独自ツール群を通じて実装しており、ショッピングフローの主要な各段階を担っています。
エージェンティックな取引には、通常次の 4 つの主体が関与します。
プラットフォーム／AI エージェント
マーチャントのシステム
決済サービスプロバイダー
認証情報プロバイダー（ID、決済認証情報など）
UCP は、これらの主体間で行われるすべてのやり取りをカバーします。具体的には以下が含まれます。
商品探索（Product Discovery）
マーチャントを横断した商品検索、フィルタリング、詳細情報の取得。カート＆チェックアウト（Cart & Checkout）
カートやチェックアウトセッションの作成、購入者情報の収集、割引やロイヤルティポイントの適用、安全な決済処理。注文＆購入後（Orders & Post-purchase）
注文確定、配送状況の追跡、返品などの対応。
Shopify のエージェンティック・スタックは、これらすべてに対応する機能を提供します。
開発者は、AI エージェントが商品探索から購入、購入後対応までを一貫して担うエンドツーエンドのコマースフローを構築できます。しかも、それらはすべて会話の中で完結します。
特に重要なのは、UCP が複雑な小売シナリオを扱えるよう設計されている点です。
割引コードの適用、ロイヤルティ報酬の利用、サブスクリプションオプションの選択、予約販売条件などのストアポリシー確認といった処理も、すべてチャット経由で実行できます。
さらに、標準化された決済ハンドラ（後述）を通じて、あらゆる決済プロバイダーと決済手段をサポートしており、エージェントは柔軟に支払い処理を行えます。
要するに、Shopify エージェンティック・コマースとは、AI や任意のヘッドレス UI の中に、最小限のカスタム実装でショッピング体験を組み込めるための基盤です。
次は、これを可能にしている主要コンポーネントと、それらを開発者がどのように利用できるのかを詳しく見ていきます。
Shopify Catalog：スケールするグローバル商品探索
商品探索フェーズの中核にあるのが Shopify Catalog です。これは、すべての Shopify マーチャントにまたがる商品を集約した、巨大で構造化されたプロダクトインデックスです。
世界中に存在する数十億点規模の商品を、リアルタイムで検索可能なカタログだと考えると分かりやすいでしょう。
これは、開発者が自前でデータを集約したりスクレイピングしたりすることなく、エージェントが「優れたマーチャントによる最適な商品」を見つけるための基盤となります。
実際、これ以前は、Shopify 全体を横断する商品検索を構築しようとする第三者は、何千ものストアをクロールし、不整合なデータを処理しなければならず、極めて困難な作業でした。
現在では Shopify Catalog が 低レイテンシの API を提供しており、「1 回のクエリで、Shopify エコシステム全体の膨大なデータ」にアクセスできます。
Shopify Catalog が提供するもの
Shopify Catalog を使うことで、AI エージェント（または任意のアプリ）は以下を行えます。
商品検索
フィルタリング（価格帯、カテゴリ、配送先など）
特定商品の詳細情報取得
検索結果は統合された形式で返却されます。
例えば、検索結果は UPID（Universal Product ID） によって重複排除されます。
同一商品が複数のストアで販売されている場合でも、1 件として表示され、統合ビューが提供されます。
各検索結果には以下が含まれます。
商品の基本情報（タイトル、説明、画像）
全販売者を横断した価格レンジ
利用可能なバリアント／オプション
その商品を販売しているストア一覧（各ストアの価格とチェックアウト URL）
これにより、エージェントは即座にユーザーへ選択肢を提示でき（最安値や最短配送の店舗を示すなど）、どのように購入へ誘導すべきかも把握できます。
ユーザーが商品を選択すると、エージェントは Lookup 機能を使って、UPID またはバリアント ID からバリアント単位の詳細情報を取得できます。
Lookup の結果には以下が含まれます。
すべてのバリアントオプション
各ストアごとのバリアント価格
説明文、特徴、仕様などのリッチな情報
これらの情報の多くは、Shopify によって AI（LLM）で補完・強化されています。
Shopify は独自の LLM を用いて商品データを分類・拡張し、属性を標準化することで、検索結果がより関連性が高く、分かりやすいものになるようにしています。
ただし、これらの AI 推論フィールドは常に完全であるとは限らない点も明記されています。
利用方法（How to use it）
開発者は、用途に応じて複数の方法で Shopify Catalog にアクセスできます。
1. Catalog MCP
Shopify が提供する JSON-RPC API エンドポイントで、UCP に準拠したディスカバリー機能を実装しています。
エージェンティック・コマースにおける 主要ツールです。
以下のような「ツール（関数）」が提供されます。
search_global_productsget_global_product_details
Catalog MCP は JWT トークンによる認証が必要で、Shopify 開発者資格情報から取得します。
これにより、承認されたパートナーやアプリのみがグローバルカタログへアクセスできます。
MCP サーバーを利用する最大の利点は、エージェンティックなワークフローおよび UCP の構造と密接に統合されている点です。
2. Catalog REST API
Catalog を支える RESTful API です。
実際には MCP サーバーは、この REST API の上に被せた薄いレイヤーに過ぎません。
/catalog/search や /catalog/lookup といったエンドポイントを直接利用することも可能です。
返却されるデータ（UPID、商品情報など）は MCP と同一です。
AI エージェント文脈外（例：Web マーケットプレイス）で利用する場合、REST API の方が扱いやすいケースもあります。
認証やレート制限の考え方は MCP とほぼ同じです。
3. Storefront MCP
Catalog の考え方を 単一ストアに限定したものです。
すべての Shopify ストアは、以下の URL に 認証不要の MCP エンドポイントを公開しています。
https://{store_domain}/api/mcpStorefront MCP では、以下のようなツールが利用できます。
search_shop_catalog（そのストア内の商品検索）search_shop_policies_and_faqs（ポリシーや FAQ の検索）
結果には、商品タイトル、説明、画像、ストア固有のバリアント ID、通貨付き価格などが含まれます。
これは、特定ブランド向け AI アシスタント（自社サイトやアプリ内のチャットボットなど）を構築する場合に非常に有用です。
グローバル検索を行う必要がなく、API 資格情報も不要です。
また、プロトタイピング用途にも適しています。
認証の手間やグローバルレート制限を気にせず、テストストアの MCP を直接呼び出せます。
どれを使うべきか（When to use which）
一般的には、**Catalog MCP（グローバル）**がほとんどのユースケースで推奨されます。
特に、ユーザーが特定のマーチャントを決めていない状態で商品探索を支援する場合に最適です。
主なユースケース例：
複数ストアを横断するショッピングアシスタント
価格比較ツール
マーチャント非依存の商品発見体験
一方で、Storefront MCP が優れるケースもあります。
単一マーチャントにフォーカスしている場合
（ブランド専用チャットボット、ストア内 AI コンシェルジュなど）認証を避けて素早く検証したい場合
（デモ、ハッカソンなど）グローバルレート制限を避けたい場合
初期段階では、Catalog MCP は（特に小規模パートナーに対して）レート制限が厳しくなる可能性があります。
特定ストアのみを扱うなら、そのストアの MCP の方が自由度が高い場合があります。
さらに、エージェンティック用途以外や、より細かい制御が必要な場合（カスタムマーケットプレイス構築など）は、Catalog REST API も選択肢になります。
ただし、多くのエージェンティック・シナリオでは、**MCP インターフェース（事前定義ツール＋UCP 準拠）**が最も簡単な道となります。
開発者向けの注意点（Developer tips）
キャッシュは禁止
商品データや画像をサーバー側に長期間保存してはいけません。
価格や在庫は頻繁に変わるため、またポリシー上の理由からもキャッシュは不可です。画像の再ホスティング不可
提供された URL をそのまま使用し、ダウンロードや再配信は行えません。柔軟な検索条件指定
キーワード、価格帯、カテゴリ（タクソノミー ID）、配送先などを指定できます。保存済みクエリ
Shopify Dev Dashboard 上で Catalog クエリを保存し、特定条件を事前に組み込んだカスタムエンドポイントを生成できます
（例：特定カテゴリや特定ストア群に絞ったニッチ向け検索）。
マルチ通貨とロケールについて
Catalog の検索結果は、特に指定しない限り、マーチャントのデフォルト通貨で価格が返却されます。
グローバル向けアプリを構築する場合は、ユーザーのロケールや希望通貨を取得することが重要です。
チェックアウト時（次章）には、取引通貨を指定でき、Shopify が通貨変換やマーチャントの国際価格設定を適用します。
この点については、チェックアウトのセクションでさらに詳しく解説されます。
UCP、ユニバーサルカート、マルチストア・チェックアウトフロー
Shopify のエージェンティックなアプローチの中でも、特に画期的なのが、UCP の柔軟なカートおよびチェックアウトモデルによって実現される 「ユニバーサルカート（Universal Cart）」 という概念です。
従来の EC では、カートはマーチャントごとに分断されており、ユーザーは一度に一つのストアでしか買い物ができませんでした。
ユニバーサルカートでは、ユーザー（を代行するエージェント）が、複数の異なる Shopify ストアの商品を、一つの論理的なカートに追加できます。しかも、それは単一の会話やインターフェースの中で行われます。
例えばユーザーが「ストア A のジャケットと、ストア B のブーツをカートに入れて」と言えば、エージェントがそれを処理します。そしてユーザーは、すべての商品について 一度だけチェックアウトできます。
ユーザー視点では、これは完全にシームレスな 1 回の取引に見えます。商品は異なるマーチャントから提供されているにもかかわらず、統一されたチェックアウト体験が提供されるからです。
開発者側では、これは UCP の カートおよびチェックアウトの抽象化によって実現されています。エージェントは、裏側では個別のチェックアウトセッションを調整しつつ、表向きには単一のフローとして提示します。
各マーチャントは引き続き 販売主体（seller-of-record） であり続けます（これは法務・コンプライアンス上非常に重要です）。
ただし、エージェントがプロセス全体をオーケストレーションすることで、ユーザーとマーチャント間の切り替えは最小限に抑えられます。
実際の仕組み
UCP は、標準化されたカートのセマンティクスと 「統合チェックアウト（unified checkout）」 機能を定義しています。
エージェントは、UCP を通じてマーチャントのバックエンドに認識されるカートセッションを作成できます。
複数ストアが関与する場合、通常は マーチャントごとに別々のカートやチェックアウトセッションが作成されます。ただし、エージェントはそれらを並行して管理し、ユーザーを 1 つの統合 UI の中で案内できます。
Shopify のプロトコルは、カートのコンテキストに応じて動的にハンドオフを行うことで、「すべての取引が完了へ至る経路を見つける」ことを保証します。
例えば、ある商品でユーザー入力が必要な場合（刻印内容の指定や配送日の選択など）、エージェントはそれを検知し、適切な入力を促したり、そのマーチャント固有の UI へ誘導したりします。
ユニバーサルカート＆チェックアウトの実例
仮に、ユーザーが 2 つのストアの商品をカートに入れているとします。
エージェントは、ストア A と ストア B のそれぞれに対して、API 経由でチェックアウトセッションを開始します（次章で説明する Checkout MCP を使用）。
情報を収集する過程で、次のような違いが見つかるかもしれません。
ストア A の商品はカナダから発送され、電話番号の入力が必須
ストア B の商品には、事前注文（プレオーダー）に関する免責事項への同意が必要
エージェントは、これらを 順番に、または並行して処理できます。
必要な情報や確認事項をユーザーに提示し、それぞれのチェックアウトを更新します。
最終的に、エージェントは各ストアの注文に対する continue_url やチェックアウトリンクを取得します（または Checkout Kit を使って埋め込みます）。
ユーザーは「今すぐ支払う」を 1 回クリックするだけで、裏側ではエージェントが各注文の確定処理をトリガーします。
ユーザー視点では、これは 1 回のチェックアウトに感じられます。
特に Shop Pay のようなウォレットを利用している場合、支払い情報は 1 回の入力で済み、それが安全に複数注文へ分割されます。
一方で、内部的には マーチャントごとに別々の注文が作成されます。
これにより、マーケットプレイス型の中間事業者が資金を預かる必要がなくなり、Shopify のモデル（顧客が各マーチャントに直接支払う）を維持したまま、法的・会計的な整合性が保たれます。
開発者視点での意味
このようなオーケストレーションの大部分は、UCP と Shopify のツール群が肩代わりしてくれます。
開発者は、複数商品・複数チェックアウトを扱う会話フローを設計する必要はありますが、新しい統合チェックアウトシステムをゼロから構築する必要はありません。
支払いの分割や精算計算を自前で実装する必要もなく、各注文の処理は Shopify のバックエンドに委ねることができます。
本質的には、エージェントが「複数のサイトで協調的にチェックアウトを行うスーパー・クライアント」として振る舞うイメージです。
マーチャント側の制御と参加可否
マーチャントは、このようなクロスストア体験への参加を 自ら制御できます。
Shopify では管理画面に Agentic Storefronts セクションが追加され、AI チャネル上での商品表示方法を管理できるようになりました。
マーチャントは、ChatGPT や Google AI などのチャネルへの露出をオン／オフできます。
また、Catalog への参加も制御可能です（デフォルトでは多くのストアが検索対象となっていますが、オプトアウトも可能です）。
そのため、開発者としては 膨大な商品群を最初から扱える一方で、すべてのマーチャントがエージェントによるチェックアウト完了を許可しているとは限らない点を理解しておく必要があります。
ブランド方針に合わない場合など、初期段階では特定チャネルを無効化するマーチャントも存在し得ます。
UCP はオープンプロトコルであり、複数のプラットフォームから支持を受けています。そのため将来的には、Shopify 以外のコマースシステムでも採用される可能性があります。
とはいえ、Shopify Catalog と Checkout ツールを使えば、すでに何千ものマーチャントが利用可能な状態でスタートできる点は大きな強みです。
まとめると、UCP の 「統合カート＆チェックアウト」 機能により、開発者は どのストアの商品でも、どこからでも、1 つのフローで購入できる体験を構築できます。
ただし、この強力な仕組みは 慎重に使うべきです。
例えば、商品が別々に発送され、送料も別々にかかる可能性があることは、ユーザーに明確に伝える必要があります。
LinkedIn 上でのユニバーサルカートに関する議論でも、「小さな注文が複数の荷物として届くことに驚くユーザーがいるかもしれない」と指摘されています。
そのため、エージェントが
「2 つのストアから発送されるため、荷物は 2 個届きます」
といった形で事前に説明するのが望ましいでしょう。
ユーザー体験がスムーズで分かりやすいものである限り、ユニバーサルカートは利便性におけるゲームチェンジャーとなります。
Checkout MCP：API によるプログラム可能なチェックアウトセッション
チェックアウトフェーズに移ると、Checkout MCP はエージェントがチェックアウトセッションをプログラム的に作成・管理できるようにする Shopify の API エンドポイントです。ここでは、エージェントがユーザーの欲しい商品を受け取り、ユーザーに代わって実質的に 「カートに追加 → 必要情報の提供 → 注文確定」 のステップを進めます。開発者としては、Checkout MCP を使うことで、チェックアウトフローを制御された形で、段階的にスクリプト化できます。
Checkout MCP の主要機能
Checkout MCP は以下の「ツール（API メソッド）」を提供します。
create_checkout
ラインアイテム（ユーザーが欲しい商品／バリアント）と、分かっている範囲の購入者初期情報を渡して、新しいチェックアウトセッションを開始します。これにより チェックアウトセッション ID と、通常は continue_url（チェックアウトを完了するための Web URL） が返ります。get_checkout
進行中のチェックアウトの現在状態を取得します（ポーリングやステータス表示が必要な場合に有用）。update_checkout
不足情報を追加したり、詳細を変更したりしてチェックアウトを更新します。
例えば作成後、チェックアウトが未完成で配送先住所が必要な場合、エージェントは住所を指定してupdate_checkoutを呼び出したり、割引コードを追加したりできます。complete_checkout
チェックアウトを最終確定し、注文確定を試行します（＝決済を実行し、注文を作成します）。cancel_checkout
ユーザーが気が変わった場合やタイムアウトした場合に、セッションを中止します。
仕組み：状態機械（ステートマシン）／ステータス駆動のワークフロー
Checkout MCP は ステートマシン（状態機械）、つまり ステータス駆動のワークフローに従います。セッションを作成すると、レスポンスには status フィールド（および不足がある場合はメッセージ一覧）が含まれます。典型的なステータスは以下です。
incomplete（追加データが必要）requires_escalation（UI 上でユーザー操作が必要）ready_for_complete（最終確定可能）complete_in_progresscompletedcanceled
エージェントは基本的にループします。つまり、各呼び出し後に status を確認し、次に何をすべきか判断します。
1) チェックアウトの作成（Create the checkout）
最低限、ラインアイテムと通貨（加えて、もしあれば初期の配送先住所やメール）を渡します。API は例えば status = incomplete として、次のようなメッセージを返すことがあります。
「配送先住所が不足」
「連絡先メールが必要」
各メッセージには severity（深刻度）があり、エージェントが自力で解決できるか（recoverable）あるいは購入者の入力が必要か（requires_buyer_input）が示されます。
例えば配送先不足なら recoverable であり、ユーザーから住所を聞いて update_checkout を呼べば解決できます。
一方、商品が在庫切れ（MERCHANDISE_NOT_AVAILABLE）の場合は requires_buyer_input となり、ユーザーに別の商品を選んでもらう必要があります。
2) チェックアウトの更新（Update the checkout）
エージェントは収集できた不足情報（住所、電話番号、配送方法の選択など）を update_checkout で送信します。更新後に再度 status を確認し、status が ready_for_complete になるか、あるいは requires_escalation になるまで繰り返します。
3) エスカレーション対応（Handle escalations）
requires_escalation は「API では処理できないものがある」ことを意味します。これは、例えば次のようなケースです。
マーチャント独自のチェックアウト拡張
（例：年齢確認が必須、独自アップセルなど）安全性の観点からユーザーが UI 上で行う必要がある決済ステップ
この場合、Checkout MCP のレスポンスには continue_url が含まれます。これは「入力が必要な正確な段階の Web チェックアウト」へのリンクです。ここでエージェントは、ユーザーが必要な操作を完了できるよう、制御を信頼できる UI に引き渡すべきです。方法は 2 つあります。
ブラウザまたは WebView で Web チェックアウトを開く
（単純にcontinue_urlのページを表示するだけ）Checkout Kit または Embedded Checkout Protocol（ECP）による埋め込みチェックアウト
これによりエージェントのアプリがチェックアウト UI をネイティブに表示でき、特定イベントの監視も可能になります（Checkout Kit については後述）。
いずれの方法でも、ユーザーが必要なステップ（例：決済認証の完了、フォーム入力）を終えるとチェックアウトは進行します。Checkout Kit を使う場合は完了検知が可能で、ブラウザの場合はリダイレクト／コールバックに依存することがあります。
4) チェックアウトの完了（Complete the checkout）
status = ready_for_complete（必要情報が揃い、ユーザー側で追加操作が不要）になったら、エージェントは API 経由で complete_checkout を呼び出して注文を確定できます。これが実際の購入トリガーです。レスポンスは complete_in_progress（バックエンドが課金処理中／何かを待っている）を経て、成功すれば completed になります。その時点で注文確認（注文 ID など）を得られるので、ユーザーに通知できます。
認証要件とエンドポイント
この一連のプロセスを通じて、Checkout MCP は認証が必須です。Shopify Partner ダッシュボードで OAuth の client ID/secret を取得し、JWT トークンへ交換します。このトークンを各 API 呼び出しで（Authorization ヘッダーとして）使用します。
各 Shopify ストアのチェックアウト用エンドポイントは、UCP ベースの呼び出しの場合、通常以下です。
https://{shop-domain}/api/ucp/mcp
これは、商品検索用の 未認証 /api/mcp（ストアフロントの MCP）とは別で、チェックアウト用は /api/ucp/mcp 配下にあり、認証を要求します。
Checkout MCP のユースケース
エージェント／アプリがチェックアウトを細かく制御したい場合や、複数ステップのフローを扱う必要がある場合は、MCP アプローチを使うべきです。例えば：
エージェントが詳細（住所、配送オプション、支払い方法など）を 1 つずつ会話で聞き、
「郵便番号が不正です。修正してください」のようなエラーも処理する会話型チェックアウトを実装したい場合複数マーチャントのカートをサポートするなら、Checkout MCP でマーチャントごとのチェックアウトセッションを並行管理し、ステータスを追跡することになる場合が多い
割引コード、ギフトカード、受け取り方法（店頭受取 vs 配送）などを、注文確定前にプログラム的に適用したい場合
在庫切れや「カート追加後に価格が変わった」などの条件を検知し、対話で処理したい場合
（ステータスメッセージがそのためのフックになります）
よりシンプルな代替：Checkout URL（カートパーマリンク）
一方、ユースケースが単純（例：エージェントが単品を一度で購入させるだけ）なら、フルの MCP 手順が不要な場合もあります。簡易フローでは Checkout URL（Cart パーマリンク） が代替になります。実際、Catalog の検索結果には、各ストアのオファーに対して checkoutUrl が含まれています。
この checkoutUrl は実質的に「そのマーチャントのストア上で、該当商品のチェックアウトへ直行するカートパーマリンク（通常は数量 1）」です。開発者はこの URL を（WebView または Checkout Kit で）開くだけで、ユーザーに支払いをさせられます。これにより、エージェントが住所を収集したり API を呼んだりする必要がなくなり、マーチャント標準のチェックアウトフローが処理します。
欠点は、追加商品を入れたり、プロセスに介入したりしにくい点です（ページのスクレイピングは非推奨）。したがって、複数商品や対話的フローは MCP、単品のワンクリック購入は checkoutUrl でも十分、という整理になります。
マルチ通貨・地域（リージョン）の考慮
MCP でチェックアウトを作成する際には、使用する通貨（ISO コード）を指定する必要があります。これは購入者のロケール／希望通貨に合わせるべきです。マーチャントが Shopify Markets によりその通貨の価格を設定している場合、API はそれを使います。設定がない場合は、Shopify が現行レートで通貨換算して注文に反映します。
また、商品が購入者の国へ配送できない場合、チェックアウト API は通常、住所入力段階でそれを指摘します（そのためエージェントは Catalog の配送先フィルタで事前に除外すべき場合があります）。開発者は配送国を早めに収集し、検索クエリにも使うことで、配送できない商品を提案してしまう事態を避けるべきです。
国際注文の税金・関税は通常どおり Shopify がチェックアウト中に計算します。必要であれば、最終価格に反映された内容をエージェントがユーザーへ提示すべきです。
現在の制約とベータ機能
Winter ’26 時点では、「ユーザーへの引き渡しなしにエージェントだけで完全にチェックアウト完了する」機能は、選定パートナー向けのプレビューです。多くの場合、セキュリティと UX の都合で、最終的な支払い入力や特定の確認（例：規約同意）は UI でユーザーに行ってもらうことになります。
ただし構想としては、保存カードや Shop Pay のような資格情報が利用可能なら、エージェントがチャット内で注文を完了できる未来を目指しています。Shopify が API 経由で可能な範囲を拡張していくにつれ、Checkout MCP の更新を追うべきです。UCP 仕様はロイヤルティポイントの利用、カスタムフィールド等も許容しますが、初期段階ですべてが完全に提供されるとは限りません。
重要事項：決済セキュリティ
大きな注意点が 1 つあります。決済のセキュリティです。エージェントは API 経由で、クレジットカード番号のような生の決済情報を直接見たり扱ったりしません。これは設計上意図されたものです。代わりに、Shop Pay などの支払いトークンを使うか、ユーザーが安全な Shopify のチェックアウトフォーム（Web または埋め込み）に情報を入力します。
これにより PCI 準拠とユーザーの信頼が担保されます。Checkout MCP は、必要情報が揃うと利用可能な支払い手段を payment.handlers 配列で提示します。例えば、クレジットカード、Shop Pay、PayPal などです。高度なエージェントはこれを使って「以前使った Shop Pay で支払いますか？」のように提案し、Shop Pay の payment handler で支払いトークンや承認を取得できます（Shopify はエージェント向けに Shop Pay の特定統合も提供しています）。これらの payment handler 統合は本概要の範囲外ですが、ウォレット決済等を標準化して扱えるようにするために存在します。
Checkout Kit：Shopify のチェックアウト UI をどこにでも埋め込む
強力な API があっても、購入を完了する最短ルートは、Shopify の実戦投入済みのチェックアウト UI をそのまま使うこと、という場合があります。Checkout Kit は、開発者が Shopify のチェックアウトインターフェースを、アプリ／Web サイト／エージェントへ最小限のコードで直接埋め込めるツールキットです。
本質的には、マーチャントの実際のチェックアウト（ブランド、カスタマイズ、決済手段を含む）を、コンポーネント内で表示する「出来合いの WebView／iframe ソリューション」です。これはコンバージョン面で非常に大きい要素です。Shopify のチェックアウトは高度に最適化されており（業界でも高水準のコンバージョン率を誇るとされます）、自前フォーム構築で性能や信頼性を犠牲にしないためにも、再利用する価値があります。
提供内容
Checkout Kit（旧称 Checkout Sheet Kit）は複数プラットフォームをサポートします。iOS、Android、React Native、Web アプリは、提供されるライブラリまたは Web コンポーネントを通じて利用できます。
基本は、Checkout URL またはカートパーマリンクを Checkout Kit に渡すと、それをロードする モーダル型チェックアウトウィンドウ または インラインフレーム をレンダリングし、デバイス差異を跨いで、Cookie、ローカルストレージ、認証などの厄介な要素を処理します。さらに Shopify の Web チェックアウトへ「橋渡し」しつつ、ホストアプリが状態（チェックアウト完了、ユーザーが閉じた等）を把握できるコールバックも提供します。
例として、モバイルアプリでは Shopify ドキュメントにあるようにShopifyCheckoutSheetKit.present(checkoutURL, from: viewController)
のような関数を呼ぶと、チェックアウトページをロードするネイティブビューがポップアップします。Web では、小さな JS ライブラリが用意されており、<shopify-checkout> Web コンポーネントを組み込むだけで、カート URL のリンクをクリックするとページ上で埋め込みチェックアウトウィジェットが開きます。
なぜ使うか
ヘッドレスコマースアプリやカスタムフロントエンドを構築する場合、Checkout Kit を使うことでチェックアウト再実装を避けられます。配送／決済フォームやバリデーションを自作する必要がなく、マーチャントの既存チェックアウトフローがそのまま再利用されます。これには以下が含まれます。
ストアのカスタマイズ（ロゴ、配色など）
Checkout UI extensions（アプリが追加するフィールドやアップセル）
Shopify Functions（独自の価格・配送ロジック）
つまり、Web サイト上で動くのと「まったく同じチェックアウト」を、あなたの文脈（アプリ内など）に埋め込むだけです。マーチャントにも顧客にも機能面の妥協がなく、開発者はドロップインで導入できます。
いつ使うか
AI エージェントのシナリオ：前述の
requires_escalation（ユーザー入力が必要）に到達したら、Checkout Kit でcontinue_urlを提示すると、文脈内でスムーズに完了できます。メッセージングアプリ等で WebView が使えるなら、外部ブラウザへ飛ばさず、その場でチェックアウトを開けます。Microsoft の Bing Chat（Copilot）と Shopify の統合は、ユーザーがチャットウィンドウから離れずに買えるよう、この種の埋め込みチェックアウトを用いています。モバイルアプリ（iOS/Android）：Shopify ストア（単一または複数）から商品を販売するアプリで、Safari に追い出さずネイティブにチェックアウトしたい場合。ゲームやライフスタイルアプリが、アプリ内で物販を行う例が考えられます。
コンテンツサイト／ブログ：「購入」ボタンを埋め込み、Checkout Kit のオーバーレイを開く用途。Winter ’26 の発表では、軽量 JS ライブラリで任意の Web ページにマーチャントのチェックアウトを配信できる点が強調されています。メディアサイトやインフルエンサーブログなら、記事内で「Buy now」を押すとその場でチェックアウトが開く導線を作れます（商品はカートパーマリンクで事前選択されている想定）。
要するに、ユーザーをストアサイトへ送るのではなく、ユーザーがいる場所にチェックアウトを置きたいときは Checkout Kit が有効です。
統合例
都市内の Shopify マーチャントの商品を Catalog 経由で提案する旅行アプリを考えます。ユーザーがパリを見ていると、ローカルショップのワインのおすすめが表示される。購入したくなったら、Checkout Kit でアプリ内購入できます。
フローは次のようになります。Catalog で商品と、そのマーチャントの checkoutUrl を取得し、その URL を Checkout Kit コンポーネントに渡して表示します。ユーザーはチェックアウト画面を見て数量や住所を入力し、支払いを行います。完了すると Kit が閉じ、コールバックでアプリ側が注文確認を表示できます。ユーザーはアプリから離れた感覚がありませんが、マーチャントには Shopify バックエンドで通常どおりの注文が入り、開発者は機微データを扱わずに済みます。
Checkout Kit は、サードパーティ Cookie やクロスサイトスクリプティング制限など、ブラウザによって埋め込みチェックアウトがブロックされ得る問題も賢く処理します。Safari（サードパーティ iframe に厳しい）や Chrome などでも、チェックアウトが安定して読み込めるように設計されています。これは自前実装だと頭痛の種になりがちな部分です。
（以下、原文の図解キャプション）
モバイルで Checkout Kit がストアのブランドを維持しつつ、Shop Pay や Apple Pay のようなウォレットをサポートする様子の簡易図：
埋め込みシート内で、ブランディング、配送、支払い手段を含む完全なチェックアウト体験が維持される。
このとおり、マーチャントのチェックアウト（例：「Plant」ストア）がアプリ内に自然に表示され、Apple Pay／Shop Pay のような高速決済も利用でき、必要な統合コードは数行で済みます。
開発者向け tips
Kit に渡すための 有効なカート／チェックアウト URL を取得してください。
Storefront API（ヘッドレス構成）でカートを作った場合はカートパーマリンクを使うか、Cart API からチェックアウト URL を生成できます。Checkout MCP を使っている場合は、エスカレーションが必要になった時点でcontinue_urlが得られるので、それを Checkout Kit に渡せます。Kit は必要ならユーザーのログインも処理します（Shopify のチェックアウトがメール認証や Shop Pay ログインを促す場合でも、それは埋め込み UI 内で完結します）。
完了後は Kit のビューを閉じ、得られる情報（注文番号など）を使ってユーザー確認を行ったり、アプリ内の遷移に使ったりします。
最後にもう 1 点：Embedded Checkout Protocol（ECP）。これは Checkout Kit が実装する標準で、ホストアプリがチェックアウトからのイベント（例：「配送先住所が変更された」「注文が送信された」）をプログラム的に受け取れるようにします。より深い統合（配送オプションのロードに合わせてアプリ UI を更新する等）が必要なら、ECP のイベント仕様が役立ちます。これは高度な用途で、基本フローでは通常必須ではありませんが、ユーザー体験を微調整したい場合に存在を把握しておく価値があります。
統合パターンとユースケース
ここまで個々の要素を見てきたので、次は開発者がそれらを現実のシナリオでどう組み合わせられるか、全体像を描いてみましょう。重要なのは、自分のシナリオに合うツールを選び、それぞれがどう補完し合うかを理解することです。典型的なパターンをいくつか挙げます。
1. AI ショッピングアシスタント／マルチストア型マーケットプレイス
ユースケース：
多くのブランドを横断して商品を見つけ、各サイトに行かずに購入までできる（テキスト／音声の）ショッピングアシスタントを作りたい。メッセージングアプリ内のチャットボット、音声スキル（Alexa / Google Assistant）、スーパーアプリ内の一機能などが想定されます。
統合パターン：
広範な商品ディスカバリーには Shopify Catalog（MCP または API） を使います。ユーザーは自然言語で検索し、エージェントがそれを Catalog クエリ（価格帯やカテゴリなどのフィルタ付きの可能性あり）に変換します。結果は見やすい UI（チャット内の商品カードのカルーセル等）で提示します。
ユーザーが商品を選んだら、Catalog Lookup でバリアント詳細と、その商品を提供しているマーチャント一覧を取得します。ユーザーに「どのマーチャントから買うか」を選ばせることもできます（最安値、最短配送などの理由で）。
選択が決まったら、Checkout MCP でそのマーチャントの商品を使ってチェックアウトを開始します。異なるマーチャントの商品を複数買いたい場合は、リストを保持し、各マーチャントごとに Checkout MCP で別々のチェックアウトセッション を開始します（ユニバーサルカートの考え方）。必要情報の入力を会話で誘導し、どこかの段階で視覚的 UI（例：決済情報入力）が必要なら、Checkout Kit でチャットアプリ内に埋め込みます。完了後、注文確定を伝えます。
このパターンは基本的に Catalog MCP → Checkout MCP → Checkout Kit を直列につなぎ、マーチャントが複数ならそれを繰り返す構成です。つまり、フルのエージェンティック・コマースフローです。
Storefront MCP を使うべきとき：
アシスタントが単一ストア向けにブランディングされている場合（例：「Ask BrandX Bot」）は、Catalog を省略してそのストアの MCP だけでディスカバリーできます。ただし、マーケットプレイス型のアシスタントでは Catalog が主役です。
例：
買い物を可能にする ChatGPT プラグインを想像してください。呼び出されると、プラグインは Shopify Catalog を使って回答を取得します。ユーザーが「5歳児向けで50ドル以下のギフトが欲しい」と言うと、エージェントが検索して玩具をいくつか見つけます。ユーザーが1つ選ぶと、エージェントは50ドル以下で売っているストアを確認し、該当ストアを見つけ、チェックアウトへ進みます。その際「プロフィールの住所に送りますか？」と聞き、OK ならチェックアウトを作成して住所を反映し、「決済情報入力のための安全なチェックアウトを開きます」と言って Checkout Kit で決済画面を表示します。ユーザーが支払えば完了。会話の中だけで完結します。
このシナリオはまさに Shopify が構想していたもので、Microsoft の Bing Chat（Copilot）でインライン購入できるデモも行われましたし、Google も Google 検索の AI 結果に統合しようとしています。
2. 単一ブランド向け AI コンシェルジュ
ユースケース：
マーチャントが、自社サイトまたはモバイルアプリ上で AI チャットアシスタントを提供し、商品探索やポリシーに関する質問対応をしつつ、同じサイト内で購入へ誘導したい。
統合パターン：
そのマーチャントの Storefront MCP で、ディスカバリーと Q&A を扱います。例えば、「オーガニックコーヒーはありますか？」にはストアの MCP の search_shop_catalog を呼んで回答できます。「返品ポリシーは？」には search_shop_policies_and_faqs を呼んで回答できます。
これらのツールは、ストア固有の文脈を取り込みやすい点が利点です。チェックアウトは単一ストアなので選択肢があります。
選んだ商品に対して カートパーマリンク を生成し、通常のチェックアウトページへリダイレクトする（Web 上のチャットならこれで十分な場合もある）
よりシームレスにするなら、チャットウィジェット内で Checkout Kit を使い、チャットから離れず購入完了させる
さらに会話的な制御をしたい（例：サイズ・色の選択をチャットで収集）場合は、Checkout MCP でカートを作成・投入し、決済段階でエスカレーションして Checkout Kit を開く
既存ストア技術との統合タイミング：
ストアがすでにヘッドレス構成だったり、サイトが Shopify の Storefront API を使っていても、AI 部分だけ Storefront MCP を使うことはできます。衝突しません。MCP 呼び出しは GraphQL の Storefront API 呼び出しと並行して動かせます。利点は、MCP が自然言語クエリに最適化されている点（例えば「オーガニックコーヒー」の検索をより賢く扱える可能性）です。また、認証不要なので、必要ならクライアントサイド統合もしやすいです。
例：
アパレルブランドのサイトにチャットボットがあり、「こんにちは、StyleBot です。何かお探しですか？」と挨拶します。ユーザーが「赤のサマードレス、M サイズが欲しい」と言うと、StyleBot は search_shop_catalog を呼び、結果を画像と価格付きで数点表示します。ユーザーが「2番目がいい。M サイズ在庫ある？」と聞けば、検索結果に含まれる情報（バリアント在庫）から回答できるかもしれません。OK ならユーザーが「買う」と言い、ボットは (a) 事前に用意したカートで Checkout Kit を開く、または (b) チャットでメールと配送先を聞き（既存顧客ならすでに知っている可能性もある）、Checkout MCP で反映し、最後に Checkout Kit で決済を開きます。注文はユーザーが通常クリックしたのと同様に、そのストア上で作成されます。
このパターンは、エージェンティック機能が単一マーチャントのストアを強化し得る点を示します。マルチストア市場だけの話ではなく、サイト内検索の改善（「チャット型検索」）や、ガイド付き販売にも使えます。特に高級小売や複雑な商品カテゴリのように、顧客が多くの質問を持つ領域で有用です。
3. 埋め込みチェックアウト付きヘッドレスコマースアプリ
ユースケース：
Shopify をバックエンドに使う（あるいは複数バックエンドを持つ）カスタムのモバイル／Web アプリを持っている。外部ブラウザへリダイレクトせず、アプリ内でチェックアウトを完結させたい。チェックアウト実装の開発コストも最小化したい。
統合パターン：
ここでは Checkout Kit が有効です。AI 文脈でなくても、Checkout Kit は単純に「チェックアウトの埋め込み」に使えます。例えば、Shopify の Storefront API（GraphQL）でカタログとカートを実装したモバイルアプリなら、その API でカート（またはチェックアウト）を作成し、得られた Checkout URL を Checkout Kit に渡して表示できます。ヘッドレス実装では、決済の最終段階で Shopify の Web チェックアウトへリダイレクトするのが歴史的に一般的でしたが、Checkout Kit はそれをネイティブにポップアップすることで回避します。
統合の要点：
ユーザーが支払いに進む段階で Checkout URL を取得する（Shopify の Cart API は Web チェックアウト URL を返せます）
Kit でその URL を表示する
成功コールバックを購読し、注文完了を検知する
複数 Shopify ストアの商品を 1 つのアプリで売る（複数ベンダーの集約）場合でも Checkout Kit は使えますが、ベンダーごとにチェックアウトを分けて順次処理する必要が出るかもしれません。UI 側で「2件中1件完了」のような進捗を見せる形になります。UCP で協調すれば結合できる可能性もありますが、AI エージェント外だと単純に順番に処理する方が実装は簡単な場合があります。
例：
ファッションインフルエンサーのアプリが、複数の Shopify ブティックのアイテムをキュレーションしている。ユーザーがブティック A のトップスとブティック B のパンツをカートに入れた。チェックアウトで 2 マーチャントと判定されたら、アプリは「まずブティック A、次にブティック B の順で決済します」と表示できます。各ブティックの Checkout URL を Kit に渡して順に表示し、ユーザーが A を支払って注文確定したら、次に B の URL を表示して支払い、という流れです。二段階にはなりますが、2つのサイトへ手動で行くよりははるかにスムーズです。両方の注文確認を保存し、アプリ内で統合レシートを表示するとよいでしょう。
これはユニバーサルカートを手動で実装しているに近い状態です。UCP／エージェンティックを使えば一部自動化できますが、既にヘッドレスアプリがあるなら、段階的に取り込むのが現実的です。
4. マルチリージョン／マルチ通貨対応
ユースケース：
世界中のユーザーにサービスを提供し、各ユーザーに関連性の高い商品とローカル通貨での価格を提示し、配送可能性も担保したい。
統合パターン：
Shopify のグローバル Catalog は、配送先国／地域でフィルタでき、ユーザーの地域に配送できるマーチャントが含まれるようにできます。クエリ時にこのフィルタを使います（例：ユーザーが日本にいるなら、日本へ配送できるマーチャントに絞る、または少なくとも優先順位を上げる）。
通貨については複数のアプローチがあります。
Shopify の為替レート（FX）で換算し、表示だけユーザー通貨に寄せる
Catalog API はデフォルトでマーチャント通貨で価格を返し、どの通貨かも明示されます。比較目的なら為替レートで概算のユーザー通貨表示も可能です。ただし、チェックアウトで重要なのは「そのマーチャントがその通貨で課金できるか」です。Shopify Markets によりマルチ通貨が有効な場合、顧客通貨でチェックアウトする
Checkout MCP を使う場合、希望通貨（例：EUR、JPY）を指定します。マーチャントが対応していれば、その通貨で（マーチャント定義の価格または換算価格で）チェックアウトが進みます。対応していない場合は、API エラーになるか、ストアの基軸通貨にフォールバックする可能性があります。購入者のロケール情報を使う
エージェントが早い段階で配送先住所を収集すれば、国コードから通貨の推定ができます。また Catalog のsearch_global_productsが「コンテキスト」や通貨パラメータを受け付ける可能性もあります（ドキュメント上は検索で通貨が明示されていないが、実装によっては可能、または今後の拡張で入るかもしれない）。少なくとも、詳細取得やチェックアウト構築時には開発者側で制御できます。
例の考慮点：
ヨーロッパのユーザーなら、ユーロ建て価格で、ヨーロッパ発／ヨーロッパ向け配送の商品を望む可能性が高い（高額な送料回避）。対応していれば shipping_origin=EU のようなフィルタを自動適用してもよいですし、結果取得後に同一大陸のマーチャントを優先してもよいでしょう。商品が決まったら currency: EUR でチェックアウトを作成します。通貨換算や関税表示は Shopify がチェックアウトで処理します。ユーザーは EUR で支払い、マーチャントは（EUR の受取／支払設定があれば）EUR で、そうでなければ Shopify Payments の FX で基軸通貨に換算された形で受け取ります。
注意点：
地域ごとの税制や規制差です。特定国に送れない商品（特定電子機器、植物など）もあり得ます。Catalog がそれを本質的に除外しない場合でも、マーチャント側の配送ゾーンで後からブロックされます。そのため、フィルタで早期確認するか、Checkout MCP で住所設定時に返るエラーメッセージを想定して、対話で適切に処理できるようにするのが望ましいです。
5. 外部システムとの統合（AI、検索、CDP）
ここはより概念的ですが、Shopify のエージェンティック要素が他ツールとどう連携できるかは触れておく価値があります。
LLM／AI プラットフォーム
ChatGPT プラグインを作る、音声アシスタントに統合する等、AI プラットフォーム上で開発するなら、Shopify の UCP と MCP ツールは「プラグイン API」として機能します。例えば ChatGPT プラグインがユーザーの問い合わせに応じて Catalog と Checkout MCP を呼ぶ、という形です。
Shopify 外の LLM であっても、Model Context Protocol（MCP）標準を使って Shopify 機能を LLM に公開できます。実際、UCP は REST または MCP（AI ツール呼び出し向けの JSON-RPC ベース標準）経由で使えるよう設計されています。Shopify の実装は UCP 準拠の MCP インターフェースを提供するため、MCP を話せる Anthropic Claude や OpenAI 系のシステムが tools/search_products や tools/create_checkout を呼ぶと、背後で Shopify が適切に処理します。つまり、独自 AI エージェントを作る場合も、これらの HTTP エンドポイントを JSON ペイロード付きで LLM の「アクション」として直接呼べる、ということです。
検索エンジン
Google の UCP 統合は、将来的に検索結果から直接購入できる可能性を示唆します。検索／発見プラットフォームを運営しているなら、Catalog を統合して検索結果に購入可能な商品を補強できます。UCP がオープン仕様なので、他（Bing やニッチ検索エンジン等）も Shopify マーチャントからコマース結果を取得するのに使える可能性があります。開発者にとって、Shopify Catalog を組み込むとアプリを「コマース対応」にできます。例えばレシピアプリの検索結果に、Shopify ストアの食材や調理器具を出して、そのまま買えるようにする、といった使い方です。
CDP（カスタマーデータ基盤）／パーソナライズエンジン
エージェンティックフローはパーソナライズで強化できます。例えば CDP が過去購入や嗜好（サステナブル嗜好、サイズ M など）を把握しているなら、それをエージェントの検索に文脈として渡せます。Storefront MCP の検索が context 文字列を受け付けるならそれを使う、あるいはクエリ後にフィルタリングする方法もあります。会話自体も「先月ランニングシューズを買っていましたね。似たものを探しますか？」のように最適化できます。これは Shopify ツール自体の範囲外ですが、上に重ねるレイヤーとして適用できる柔軟性があります。
Shopify の他コンポーネント（Commerce Components など）
Shopify には、エンタープライズ向けに、チェックアウトや在庫など個別サービスをヘッドレス利用できる Commerce Components という製品があります。エージェンティックコマースはこれを補完します。Commerce Components を使うエンタープライズでも、商品フィードを Catalog に接続し（Shopify は非 Shopify マーチャントが Catalog に掲載するための Agentic Plan も開始した）、UCP で自社スタックを接続することで、エージェンティックエコシステムを活用できます。UCP はオープンなので、理論上は Commerce Components のマーチャントが自社インフラ上で UCP エンドポイントを実装することも可能です。
ただし Shopify は、（Shopify 外のブランドも含めて）どのブランドでも Catalog に参加でき、エージェンティックチャネル向けに Shopify のチェックアウトをサービスとして使えるようにして、導入を容易にしています。つまりヘッドレスのエンタープライズは、オンラインストアを Shopify で運用しなくても、Catalog と Checkout Kit の部分だけを活用できます。このモジュール性は強力で、必要なものだけ使えます。例えば Web サイトや商品 DB は自前のまま、Shopify Catalog にフィードを送って AI エージェントが商品を発見できるようにする、といった構成が可能です。
まとめると、本質的に、Shopify のエージェンティック要素は、現代的なコンポーザブルアーキテクチャに統合できるよう設計されています。構成要素（ビルディングブロック）として
商品検索
カート／チェックアウト
UI 埋め込み
を扱えます。AI 駆動アプリ、ヘッドレスコマース、あるいはゲーム／ソーシャルコマース等の新しいマッシュアップに組み込む場合でも、重たいコマースロジックは Shopify 側が担い、開発者はユーザー体験に集中できます。
課題・制約・注意点
以下はご提示テキストの全訳です（段落構造は維持しつつ、日本語として自然になるように訳しています）。
この技術は非常に魅力的ですが、開発者は現時点の制約とベストプラクティスを意識しておくべきです。
アクセス制限とレート制限
初期展開（ローンチ初期）では、Shopify Catalog へのアクセスが申請して承認されたパートナーに限定される可能性があり、さらにレート制限の対象になります。高トラフィックを想定する場合は Shopify と調整するか、Saved Catalog（保存済みカタログ）を使って頻出クエリを最適化してください。また、レート制限の応答を受けたときに適切に処理できるようにしておくべきです（例：指数バックオフ、許可される範囲でセッション単位の短期キャッシュなど）。
データ鮮度とキャッシュ
前述の通り、データを長期にキャッシュしてはいけません。在庫や価格は変動し、プロトコル上も古い情報の利用が禁じられています。チェックアウト直前には必ず最新の詳細を再取得してください。たとえば Catalog 検索で得た価格があっても、Checkout API が最終的に最新価格を確定します。時間が空いた場合は ID（UPID、バリアント ID）を使って更新データを取り直します。
マーチャントの参加（Opt-in/Opt-out）
すべての Shopify マーチャントがすぐに Catalog に載る、またはエージェントによるチェックアウトを許可するとは限りません。デフォルトでは何百万点もの商品が含まれる一方で、エンタープライズやセンシティブなカテゴリのマーチャントは参加しない可能性があります。Catalog 検索ツールが「eligible（対象）」なマーチャントを返すという点は、インデックスされないマーチャントがいることを示唆します。さらに、一部マーチャントは「ブランドの誤表現をしない」など、エージェント側に一定のルール遵守を求めるかもしれません。マーチャントと連携するエージェントを作るなら、Shopify が提示するコンテンツ利用やマーチャント表現に関する開発者規約を順守してください。
未完了取引とフェイルセーフ
UCP は「取りこぼしがない（no transaction is left behind）」よう設計されています。つまり、エージェントが何かを完了できない場合は、人間が読める手段（Web チェックアウト）に引き継ぐ必要があります。開発者としては、そのフォールバックを必ず実装してください。チェックアウト途中でエージェントがクラッシュしたり文脈を失ったとしても、ユーザーが復帰できるようにしておく（例：該当カートへのリンクを渡す）ことが重要です。最悪なのは、ユーザーが「買えた」と思ったのに実際は成立していない状態なので、決済後にエージェントが落ちるなどのエッジケースをテストすべきです。通常、complete_checkout が成功するか、ユーザーが Web チェックアウトを完了しない限り、注文は作成されません。失敗した場合は、説明して再試行させる必要が出ます。
UI/UX の考慮
チャット／音声コマースは強力ですが、ユーザーにとっては新しい体験でもあります。会話フローは明確に設計してください。複数商品シナリオでは、何が起きているのかをユーザーが理解できるよう補助します（例：「2つの別ストアから3商品をカートに追加しました。チェックアウトに進みますか？」）。利用しているプラットフォームで可能なら、リッチカードやクイックリプライを使うと選択が容易になります（Shopify Catalog はチャット UI に表示できる画像 URL も返します）。
ベータ機能
ドキュメント上で「近日公開」またはベータ扱いの機能もあります。例として、エージェントによる注文追跡（購入後）が今後拡張される可能性があります（「注文どこ？」に対して注文ステータスを問い合わせて回答するなど）。利用可能なら UCP の注文 API 経由になるはずです。一般提供のタイミングは Shopify の変更履歴や Editions の更新を追ってください。現状の主眼はディスカバリーとチェックアウトです。
セキュリティとプライバシー
ユーザー情報（住所など）を保存するエージェントを作る場合、そのデータの扱いは慎重にすべきです。決済は Shopify の安全なチャネルで行われますが、個人情報はエージェントを経由します。Shopify のガイドラインに従い、保存・利用に際しては適用されるプライバシー法にも準拠してください（例：次回の自動入力のために住所を保持するなら、プライバシーポリシーで明確にする）。
マーチャントとの関係性
マルチマーチャント集約（アグリゲータ）では、どのマーチャントをどう見せるかを考慮してください。エージェントは中立性を保つか、ランキングルールに従う必要があります（Shopify は不当な偏りを禁止する可能性が高い）。また、マーケットプレイス的なアプリを作る場合、複数注文にまたがるカスタマーサポートを扱う必要があり、これは難しくなり得ます。LinkedIn のコメントでも「小口注文が増えるとマーチャントの CS 負荷が上がる」点が指摘されました。これはビジネス上の論点ですが、開発者としては、ユーザー向け情報を束ねたり、各注文の連絡先を明確に提示したりすることで緩和できるかもしれません。
将来展望
Shopify のエージェンティックコマースは急速に進化しています。いまやオープン標準になったため、Shopify の枠を超えて UCP を採用するプラットフォームや小売業者が増えることが見込まれます。つまり、Shopify の UCP に対応したエージェントが、将来的には Walmart のカタログや他ネットワークと取引したり、その逆が起きたりする可能性があります。現時点では、Shopify の実装と巨大なマーチャント基盤が強いネットワーク効果を持っており、開発者が今参入して革新的体験を作ろうとしている理由にもなっています。
今後、注目すべき（あるいは想像できる）進展は次のとおりです。
AI の理解の深化
LLM が進歩すれば、エージェントはより複雑な要求（例：「ビーチでの結婚式に合う服、アクセもコーデして」）を理解できるようになります。Shopify が付与する拡張商品データはここで役立ち、開発者は Catalog 結果の関連性のために AI リランキングを活用するかもしれません。さらに Shopify が「類似商品 API」や「差分要約 API」など追加の AI サービスを提供する可能性もあります（すでに説明文の補完をしているため、より多くを公開することは自然な流れです）。
エージェント同士の商取引（A2A）
Shopify の発表で短く触れられたのが、Agent to Agent（A2A）プロトコルです。複数のエージェントが協調する世界観で、たとえば旅行エージェントがフライト予約をしつつ、別の小売エージェントに「顧客のためにスーツケースを買って」と委任するようなケースが想定されます。UCP や関連プロトコルは、そのような相互作用を安全に実現する可能性があります。まだ初期段階ですが、個人アシスタントがマーチャント側エージェントと直接やり取りし、交渉するようなシナリオも考えられます。
小売以外への拡張
UCP は小売だけでなく、サービス、デジタル商品など他のコマースにも適用可能な設計です。チャット内でサービス予約やサブスクリプションを扱う方向への適用があり得ます。Shopify の現時点の焦点は物理商品ですが、プロトコルが柔軟であること（例：チャットでサブスクの課金周期選択をサポート）から、今後の拡張が示唆されます。
Shopify 自身のアプリ／チャネル
Shop アプリや Shopify のエコシステムにもエージェンティック機能が入っていく可能性があります。例えば Shop アプリに、Catalog を使ってストア横断比較するチャットボットが入るかもしれません。Shopify はマーチャント向け AI の Sidekick も推進しており、買い手向けとは直接関係しないものの、全方位で AI にコミットしていることを示します。開発者にとっては、Sidekick を拡張するアプリや、マーチャントの AI ワークフローに組み込むツールなど、統合機会が増えることを意味します。
Commerce Components との相乗効果
大手ブランドが Shopify のモジュール型コンポーネントを採用するほど、エージェンティックコマースは標準要素になり得ます。例えばあるブランドが、自社サイトでは主に Shopify の checkout コンポーネントを使い、同時に UCP を通じて在庫を外部エージェントに公開するといった形です。Instagram 投稿、ChatGPT 会話、Google 検索結果など、あらゆる「接点」がこの技術で購買ポイントになり得ます。これら API を使える開発者は、そうした統合を作る人材として需要が高まるでしょう。
コミュニティと実例の増加
オープンソース例、SDK、事例が増えることも期待されます。Shopify 自身がサンプルエージェントコード（参照実装の ChatGPT プラグインなど）を出すかもしれませんし、コミュニティが共通フロー実装のテンプレートを共有するでしょう。Shopify Engineering blog（「Building the Universal Commerce Protocol」）や開発者フォーラムを追うと、ヒントやベストプラクティスの更新が得られます。
結論
Shopify の Agentic Commerce プラットフォームは、コマースを新しい UI／チャネルへ持ち込むための強力なツールキットを開発者に提供します。Shopify Catalog（グローバルな商品探索）、Storefront MCP（ストア固有の問い合わせ）、UCP とユニバーサルカート概念（複数ストア・複数ステップ取引）、Checkout MCP（API 駆動チェックアウト）、Checkout Kit（埋め込みチェックアウト UI）の役割を理解すれば、ユーザーがいる場所（チャット、モバイルアプリ、AI プラットフォーム等）で体験を成立させる設計ができます。
「いつ何を使うべきか？」を決めるときは文脈で判断します。
Catalog：広範囲・強化済み・重複排除済みの商品検索が必要なとき
Storefront MCP：単一ストアに深く入り込みたいとき
Checkout MCP：カスタムロジックでチェックアウトをプログラム的に誘導したいとき
Checkout Kit：少ない手間で実績あるチェックアウト UI を素早く組み込みたいとき
多くの場合、答えは「組み合わせて使う」です。これらは、ここまで説明した通り噛み合うよう設計されています。
私たちは「会話型コマース」が大規模に現実化する時代の入口にいます。早期導入者はすでに AI アシスタントやメッセージングアプリ等に買い物を埋め込み始めています。開発者として Shopify のエージェンティック技術に接続すれば、コマースエンジンをゼロから作る必要はなく、ユーザー体験作りに集中でき、重いコマースロジックは Shopify に任せられます。Shopify CEO の Tobi Lütke の言葉を借りれば、このアプローチは「コマースが会話に自然に接続され、シームレスに感じられる」ことを意味し、「人がいるあらゆる場所にコマースがあるべきなので、AI 時代にそれをできるだけ簡単にする」という狙いがあります。
Shopify Agentic とそのコンポーネントを活用すれば、この波に乗って次世代の購買アプリケーション（知的で文脈理解があり、チャネル横断で摩擦が少ない）を作れます。ツールはすでにあなたの手元にあります。あなたがこれで何を作るのか、私たちは楽しみにしています。