Shopify Editions Spring ’26 エージェンティック｜AIコマース基盤の開放（全11項目）

AIチャネル経由の出品から成果の可視化までを、管理画面（Agentic home）側でまとめて扱えるようにする「エージェンティックコマースの入口」と言えそうです。

ChatGPT・Copilot・Gemini・Perplexity・Shop アプリなど、AIが買い物を仲介する場所のこと。従来の「自分のオンラインストアに人を集める」から、これからは AIアシスタントの会話の中で商品が見つかり、購入につながっていく——その“出品先”がAIチャネルです。なお「発見（探す）」はこれら各チャネルで広く起きますが、「会話の中で決済まで完結」できるかはチャネルによって異なります（後述の「より多くの場所でチェックアウト」参照）。

1. マーチャントがShopifyに商品を登録（通常の商品データ）。
2. Shopify Catalog がそのデータを自動で標準化・拡充し、グローバルカタログに載せる。
3. AIチャネル／外部エージェントが Catalog API（UCP）越しに商品を発見・推薦・販売。
4. 注文・成果は管理画面の Agentic home 等で確認できる。

公式のデモ動画では、単なる「自動出品」にとどまらず、管理画面側で運用・最適化まで回せる様子が示されています。要点は次のとおりです。

• 自動掲載と注文同期：ChatGPT・Copilot などのAIチャネルに商品が自動掲載され（発見）、決済まで対応するチャネルでは購入者が会話の中で購入。注文はそのまま Shopify 管理画面に同期されます。なお ChatGPT は ACP（Agentic Commerce Protocol／OpenAI・Stripe 主導の別系統。詳細は後述「より多くの場所でチェックアウト」）系統で発見が中心、Shop Pay でのチャット内決済完結は UCP 対応チャネル（Copilot 等）という違いがあります。
  関連：Shopifyが全ストアに自動配備していたAI Commerce対応エンドポイント ／ AIが商品を選ぶ時代に備える
• Agentic overview（一元ダッシュボード）：主要AIチャネルの売上・セッション数・注文数・コンバージョン率を1箇所で追跡できます。

  

• 高品質データで高CVR：Shopify カタログが商品の文脈を整理・翻訳し、スクレイプではない正確な構造化データを提供。これによりコンバージョン率は通常の約2倍とされています（数値は前提条件を出典でご確認ください）。
• 検索インサイト＋Sidekick の提案：購入者がAIチャットで実際に何を検索しているかを把握でき、AIが使う検索を再現して自社商品がランクインしているかを確認。改善が必要な箇所にはフラグが立ち、Sidekick が具体的な変更内容を提案します。
• 掲載プレビューとチャネル制御：ワンクリックで事前入力済みの検索を開き、購入者から商品がどう見えるかをプレビュー。さらにどのAIチャネルにデータを提供するか／自動配信か個別制御かを管理画面から設定できます。

「AI向け出品」は個別の最適化作業というより、商品データの質に集約されるように見えます。やることは結局「説明・スペック・画像・taxonomy を充実させる」こと。AIチャネル対策＝特別な何か、ではなく「商品データ整備＝AI対策」という一本化したメッセージにできそうです。

前項（AI向けに最適化された商品）の技術的な土台にあたる仕組みです。マーチャントがバラバラに書いた商品データを、Shopify が統一フォーマットに正規化し、さらに機械学習で情報を補う（拡充）——「AIが正しく商品を理解できるよう、裏でデータを整えるレイヤー」と言えそうです。

Catalog API の返却データには、マーチャントの入力そのものに加えて metadata（ML推論メタデータ）が付きます。実際に確認できたキーは次のとおりです。

• tech_specs（技術仕様）
• top_features（主要機能）
• unique_selling_points（独自の強み）
• attributes（素材・スタイル・利用シーン等の正規化属性）

これらが機械学習による推論だと分かるのは、まず公式の拡張仕様（Global Catalog extension）に明記されているためです。同ドキュメントは product.metadata 配下の各フィールドを、いずれも先頭に “ML-inferred”（機械学習で推論）と付けて定義しています。

• attributes：“ML-inferred product attributes such as material, style, and occasion.”
• tech_specs：“ML-inferred technical specifications.”
• top_features：“ML-inferred top product features.”
• unique_selling_points：“ML-inferred unique selling propositions.”

いずれも「マーチャントが直接編集する欄」としては書かれておらず、Shopify が自動生成する読み取り側データであることが読み取れます。そのうえで実際にAPIを叩いても同じキーが返ることを確認しました（次のコードブロック）。＝「仕様にそう書いてある」だけでなく「本当にそう返る」の両面で裏が取れています。
※ 仕様上 tech_specs 等は文字列配列と定義されていますが、実返却では改行区切りの1文字列で返るケースも見られました（このあたりは実データで要確認）。

グローバルカタログAPI（POST catalog.shopify.com/api/ucp/mcp の search_catalog）を実際に叩くと、各商品の metadata にこのデータが入って返ってきます。下はあるワイヤレスヘッドホン（Sennheiser MOMENTUM 4）に対する実際の返却を、見やすく一部省略したものです。

// search_catalog の返却 → products[].metadata（実データ・一部省略）
{
  "unique_selling_points": [
    "Hybrid adaptive noise cancellation and transparent mode for
     seamless situational awareness and immersive sound."
  ],
  "top_features": "Hybrid adaptive noise cancellation: ...\n
     Customizable sound modes and EQ presets: ...\n
     Premium comfort design: ...\n
     Up to 60 hours battery life: ...\n
     Smart Pause and auto on/off: ...",
  "tech_specs": "Wearing Style: Headband, around the ear (Circum)\n
     Connectivity: Bluetooth 5.2, 3.5 mm, USB, 2.5 mm\n
     Speaker Type: 42 mm dynamic transducer\n
     Frequency Range: 6 Hz to 22 kHz\n
     Battery Life: Up to 60 hours (Bluetooth + ANC)\n
     Charging Interface: USB Type-C\n
     Microphone: MEMS, 2-microphone beamforming"
}

参考までに、上記の日本語訳は次のとおりです（返却自体は英語）。

注目したいのは、これがマーチャントが書いた素の説明文そのままではないこと。要点が箇条書き化され、tech_specs は「項目名: 値」形式に整形されています。説明文・スペック表・画像などから機械が再構成したのが見て取れます。型もキーごとに異なり、unique_selling_points は配列、top_features／tech_specs は改行区切りの文字列でした。

Shopify は「Shopify 経由で構造化されたデータは AIチャットでのコンバージョン率（CVR）を2倍にする」としています。AIが「同じ“ミッドセンチュリー”を同じ意味で扱える」「真鍮ランプが一貫してタグ付けされる」といったように、正規化された一貫性のあるデータの方がマッチ精度が上がるためと考えられます（数値の前提は出典でご確認ください）。

1. マーチャントが商品を登録 → Shopify が taxonomy・属性へマッピング（標準化）。
2. ML が説明文・画像などから tech_specs / top_features 等を推論（拡充）。
3. 統合されたデータがグローバルカタログに載り、UPID（共通商品ID）で名寄せ（別々の店が登録した同じ商品を1つにまとめること）されて返る。

「AI最適化」の正体は、結局のところ商品データの整備に行き着くように感じます。ML推論である以上、キーワードを詰め込む発想は効きにくく、効くのは素材（説明・スペック・画像・分類）の質。逆に言えば、商品データの健全化そのものがAIコマース対応の第一歩になりそうで、taxonomy 整備・属性入力・画像/スペックの拡充は、そのまま取り組むべき施策に見えます。

買い物の「決済」を、自社サイトに来てもらわなくても、AIの会話の中で完結させる仕組みです。Copilot 等の対応チャネルでは「これ買って」と言えば、その場で Shop Pay を使って購入まで完結する——エージェンティックコマースの“最後のピース”と言えそうです。

エージェンティックコマースは「発見 → カート → 決済」の3段構成で、この項目はその最後の“決済”段にあたります。土台は UCP（次項参照）の各 MCP です。

私が公開した3デモ（コンシェルジュ／画像で探す／URL価格チェック）は checkout_url までを出して各店のチェックアウト画面へ送る形でした。この項目はさらに進んで、チャットから離れずに決済までいく世界です。

「まもなく・予定」表記です。Copilot 等の対応や Meta 広告連携は段階提供とされています。「今すぐどのチャットでも Shop Pay で買える」と断定はできず、方向性として確実だが時期は流動的、と読むのが正確でしょう。

これが揃うと「AIに買わせる」が文字どおり成立します（発見→決済まで会話内で完結）。鍵は Shop Pay の普及で、Shop Pay を有効化している店ほどこの恩恵を自動で受けやすいように見えます。一方で自前の完全自動決済は実装難度が高い（Token ティア＋権限）ため、当面は「Shopify／AIチャネル側が用意する決済導線に乗る」のが現実解になりそうです。

これまで Shopify は「オンラインストアを作るためのプラットフォーム」でした。Agenticプランは、オンラインストアを持たなくても、商品データだけ Shopify に入れて AIチャネルで売れる新しい入口です。Shopify が「ストア構築ツール」から「AIコマースの商品供給インフラ」へ広がる、かなり大きな方針転換と言えそうです。

1. オンラインストアは作らない。ただし Shopify アカウントは作る。
2. 商品を追加（手動／CSV／Admin API、または自社の PIM（Product Information Management／商品情報管理システム）と連携）。
3. Shopify が商品を AIチャネル（ChatGPT / Gemini / Copilot / Perplexity / Shop 等）へリアルタイム同期。
4. 注文は自社の OMS（Order Management System／受注管理）へルーティング、税は税システム連携で処理。

つまり「フロント（ストア）は持たず、Shopify を“AI向けの販売チャネル＆カタログ”としてだけ使う」構成です。

月額なし・決済手数料のみ。日本のオンライン取引は 3.55%＋0円（地域により率は異なります）。月額固定費がゼロなので「まず AIチャネルだけ試す」ハードルは低そうです。

• すでに自社EC や基幹システムを持つ中〜大規模事業者が、「Shopify に全面移行はしないが、AIチャネルへの露出だけ欲しい」ケース。
• メーカー／卸が自社 PIM の商品を AIコマースに流すチャネルとして。

「Shopify＝ストアを作る」という固定観念を壊す項目に見えます。提案の場で「ストア移行は不要、商品データだけで AIチャネルに出せます」と言えるのは大きいかもしれません。肝は PIM 連携で、商品データ基盤を持つ事業者にとってはデータ整備の価値が直結します。一方で「フロントを持たない＝ブランド体験の作り込みが薄くなる」点はリスクで、本命ストアと Agenticプランの併用など、設計の議論余地がありそうです。

UCP は、AIエージェントが買い手の代理として安全に商取引を行うためのオープンプロトコル（共通規格）です。Shopify と Google が共同開発し、Amazon／Meta／Microsoft／Salesforce／Stripe／Etsy 等も支持。「AIコマースの共通言語」を目指すもので、他のエージェンティック項目はすべてこの上に乗っています。カタログ（発見）・カート・チェックアウトの3つの MCP（Model Context Protocol）として実装され、特定の AI に縛られない“共通言語”を Shopify が用意した、と捉えるとよさそうです。

エンドポイントは2層あります。全マーチャント横断・発見専用のグローバル（POST https://catalog.shopify.com/api/ucp/mcp）と、単一店で発見＋カート／チェックアウトまで扱うストアフロント（https://{shop}.myshopify.com/api/ucp/mcp）。各店の /.well-known/ucp にビジネスプロファイルが自動生成されます（STORE DOJO にも存在しました）。

• JSON-RPC 2.0。method:"tools/call"、params.name にツール名、arguments.meta["ucp-agent"].profile にエージェントプロファイル URL（必須）を渡します。
• 承認不要・API キーすら不要で発見系は使えます（これが Spring ’26 の「一般開放」の核心）。
• ブラウザ直叩きは Content-Type: text/plain にします。application/json だと CORS プリフライト（OPTIONS）が弾かれますが、text/plain なら 200＋ACAO:* で読めます（サーバーは JSON として解釈）。
• テスト用プロファイル：shopify.dev/ucp/agent-profiles/2026-04-08/valid-with-capabilities.json（公開ページ常設では自前プロファイル推奨）。

この知見で、STORE DOJO の3デモ（コンシェルジュほか）をサーバーレスで実装・公開できました。

発見系（Catalog）は一般提供（GA 相当）で、承認不要で叩けます。一方、カート／決済の自動確定（complete_checkout）は Token ティア＋権限が必要です。

エージェンティックの戦略の中心に見えます。Shopify が「オーケストレーション層（指揮者）」になり、外部 AI はこのプロトコルで商取引を行う構図です。一社の囲い込みではなくオープン標準である点が大きく、業界の事実上の共通規格になりつつあるように感じます。しかも実装は意外と軽い（API キー不要・ブラウザから叩ける）ので、PoC（Proof of Concept／概念実証）の心理的ハードルが低いのも実務上の利点と言えそうです。

1. search_catalog に placements:["affiliate"] を渡すと、宣伝対象の商品が通常（オーガニック）の検索結果に混ざって返ります。
2. 各商品の placement.commission で「これはプロモート品」と識別できます（オーガニックは placement フィールド無し）。
3. URL に shdid（開発者ID）／shclid（クリックID）が付与され、クリックから7日以内の購入を成果として計測 → KYC（本人確認）後に月次払い。

実測：テスト用プロファイルで placements:["affiliate"] を投げたところ、promoted は 0件でした。＝Developer Preview（招待制）に未参加だと出ない、ということのようです。

「やったもん勝ちで出し放題では？」——そうではないようです。関連度ゲートがあり無関係な商品は出ません。報酬率はマーチャント側がコントロールし、そもそもカタログ検索の候補に入る商品データでないと意味がありません（商品データの構造化が前提）。リスティング広告（CPC 入札）とは異なり、あくまで成果報酬寄りです。

開発者プレビュー（招待制）。一般のマーチャント／開発者がすぐ使えるわけではありません。

「比較・推薦するエージェント体験」を作れば収益化の道がある——メディア／比較サイトのアフィリエイトの“AI版”という位置づけに見えます。ただし大前提は「まず候補に入る商品データ」で、結局はデータ整備の話に着地します。現状はプレビューなので、記事では「将来の収益モデル」として紹介し、今すぐ稼げる施策と誤読させないのが誠実だと考えました。

「Shopサインイン対応」の正体は、認証3ティアの最上位 Token ティアで使える buyer-linked token（買い手連携トークン）という仕組みです。だから出典が「認証」ページになっています。

かんたんに言うと、「この人は誰か」という Shop 顧客の情報を載せた“ログイン済みトークン”です（Shop 顧客＝accounts.shop.app の利用者。Shop Pay の利用者を含み、全世界2.5億人規模）。これをカタログ検索に渡すと、検索が「相手が誰か分かった状態」になり、その人向けにパーソナライズできるようになります。取得の流れは、①Shop でログイン許可をもらう → ②それを引き換え用の短いトークンに交換する → ③Shopify で本トークンに引き換える、の3ステップ（OAuth の標準仕様に沿った“委任方式”）。2回目のログイン画面を出さずに済む（既存の Shop ログインをサーバー側で引き継ぐ）のが利点で、得られるトークンは60分有効・再発行不可です。

「AIコマース版のログイン後レコメンド」を、自社で ML を持たず Shopify のカタログに委ねられる仕掛けに見えます。ただしサーバー＋Dev Dashboard アプリが前提で、すぐ全マーチャントに、とはいきません。今は「配管（サーバー＋アプリ）の設計を固める」段階で、パーソナライズ提供開始と同時に価値を出せるよう準備しておく、というスタンスが現実的そうです。

「Catalog API ＋ UCP で実際にどんな体験が作れるか」のショーケースです。Shopify 公式が複数のデモアプリを紹介しています。

この項目を自分のストアで実証しました。いずれもグローバルカタログをサーバーレス（ブラウザ直叩き・text/plain）で叩いています。

• おまかせコンシェルジュ（シチュエーション → コーデ提案）
• 画像で探す（Visual Search）
• URL で価格チェック（Price Lookup）

正直な注記として、これらは「探す」のは Shopify カタログ、「選ぶ（並べる）」のは単純なクエリ＋ルールで、LLM 判断は入れていません。それでも精度が出るのは Shopify カタログ側の性能によるところが大きい、と感じています。

発見系で作れる体験は今すぐ実装可能（承認不要）で、実際に公開できました。決済まで会話内で完結（より多くの場所でチェックアウト）やパーソナライズ（Shopサインイン対応）は、サーバー＋認証が必要です。

「触れるデモ」は最強の営業資料だと実感しました。抽象的な AIコマースを、実際に動くページで見せられます。サーバーレスで作れる＝制作コストが低いのも利点です。一方で“案内するだけのページ”は誰でも作れて差別化しにくいので、価値は結局 自社商品データの質と体験設計に宿る、というところに行き着きそうです。

search_catalog に画像そのものを渡すと、見た目が近い商品を返してくれる機能です。テキストで言い表しにくい「この雰囲気の服」「この形のバッグ」を画像で探せます。

• パラメータは catalog.like（配列・最大2要素）。各要素は {image:{content_type, data(base64)}}（または既知商品の {id}）。
• query（テキスト）と併用すればマルチモーダル検索（画像＋言葉）になります。
• 画像の特徴の抽出・類似計算は Shopify のサーバー側で行われます（画像を特徴量＝数値の並びに変換して照合する仕組み。専門的には embeddings と呼ばれます）。＝こちら側で AI／機械学習を持つ必要はなく、base64 は単に画像をテキストに置き換えた送信用の形式にすぎません。

画像は送信前に縮小するのが安全です（最大1024px・JPEG 化）。大きすぎると Service error になります（実測：4000×4000 → 縮小して base64 約12KB → 200 OK）。日本配送・日本円で絞るなら、返り値を price.currency==='JPY' && availability.available でクライアント側で再フィルタするのが確実です。

「写真で探す」UX が自前 ML 無しで作れるのは大きいと感じます。アパレル・雑貨・インテリアと相性がよさそうです。精度の源は Shopify カタログ側なので、結局は自社商品が“視覚的に正しく”載っているか（良い画像・正規化データ）が効いてきます。動画／SNS／雑誌の写真 → 似た在庫商品、という導線が成立し、実店舗の「これに似たの探して」をデジタル化できる可能性がありそうです。

search_catalog（条件から探す）に対して、lookup_catalog は「すでに分かっている商品を最新化する」変換器（リゾルバ）です。商品 ID か Shopify 商品 URL を渡すと、現在の価格・在庫・バリエーション・購入リンクが返ります。ページをクロール／解析しているのではなく、識別子 → カタログデータの変換をしているだけ、という点が肝です。

catalog.ids（1〜50件）に渡せるのは gid://shopify/p/{upid} ／ gid://shopify/ProductVariant/{id} ／ http(s) の Shopify 商品 URL（独自ドメイン店でも可）です。

商品 URL を渡すと price{amount,currency} ／ availability{available} ／ seller ／ checkout_url ／ condition が即返却され、解決不能 ID は not_found へ。通貨の注意として、context.address_country を JP に固定すると日本に出荷しない店舗が黙って除外される（サンプル4件→2件）ため、価格チェッカー用途では国指定を付けず各店の現地通貨で表示するのが正しい、と分かりました（価格チェックデモで確認）。

人間が URL を貼るより、AIエージェント向けの裏方 API としての価値が本命に見えます。AI がレビュー／SNS／YouTube 概要欄に貼られた商品リンクを、スクレイピングせず構造化データに即変換 → 比較・推薦 → Cart／Checkout MCP へ繋いで「買っておいて」まで。公式の想定用途も「検索結果や、商品ページへ直接飛ぶリンク（ディープリンク）から ID を解決する」「カートに入っている商品が今も正しい価格・在庫かを確認する」です。

エージェントの“商品特定”の部品、という位置づけです。発見（search）の後、または外部リンクからの起点として効きます。デモページは「裏方 API の可視化ショーケース」で、人間向けの価値は限定的ですが、AI 連携の説明素材としては有用だと感じました。UPID 名寄せにより同一 URL 群が1商品にまとまる点は、次項の「充実した商品データ」と直結します。

新しいツールではなく、Catalog API が返す商品データが、エージェントが判断・比較・購入まで完結できるだけの情報量を持つという“データの質”の話です。Shopify の Editions 発表でこの項目に挙げられていた4要素（メディア・バリエーション・出品状況・複数販売元のオファー）は、単なる宣伝文句ではなく、そのまま Catalog API が返すデータのフィールドに対応しています（下表）。

公式定義では、検索結果は「Universal Product ID（UPID）で名寄せされ、複数販売元のオファーを含む」とされています。＝世界中の店がバラバラに登録した「同じ商品」を、Shopify が1つに統合して返すということです。実測でも、同一の "AirPods Pro 3rd Gen"（1つの UPID）の中に、複数販売元の価格が並びました。

1商品エントリの中に複数社の値段が並ぶ → エージェントがそのまま最安比較できる（Amazon の出品者一覧のカタログ版）。加えて各商品には ML 推論の metadata（tech_specs / top_features / unique_selling_points。本記事の「商品データを構造化」項で詳説）が付きます。

検索で見つけた後、get_product（id 必須）に渡すと1商品の全詳細＋バリエーション絞り込みになります。selected（選択中オプション、例 Color=Blue, Size=10）と preferences（妥協する順序、例 ["Color","Size"] なら Size から緩める）を使い、「サイズ M で在庫がある色は？」を解いていく、という設計です。

エージェント時代の商品ページは、「複数オファー一覧の1行」として戦うことになりそうです。価格・在庫・データ充実度で選ばれる構図です。top_features 等は手入力ではなく ML 推論なので、勝ち筋は結局元データ（説明・スペック・画像・taxonomy・属性）の充実に尽きそうです。私の3デモが seller / price / availability / checkout_url を表示しているのは、まさにこの“充実した商品データ”の可視化実例と言えます。