Shopify TIPS Blog

Horizon UI Kit の使い方 ― 要件定義からFigmaデザイン、ストア構築までを約2時間で通してみた
Horizon UI Kit の使い方 ― 要件定義からFigmaデザイン、ストア構築まで
この記事は、以前公開したHorizon テーマの UI デザインキット(Horizon UI Kit)を使って、架空のアパレルストアを要件定義 → Figma で画面デザイン → 実際の Shopify ストア構築まで、実際に通しで作ってみたサンプル事例です。要件定義が済んでいれば、そこから先は約2時間で一気に作成できます。 UI Kit にはこういう使い方がある、という一例として、どんな順番で何を決め、Figma で何をして、ストアにどう反映したのか。実際の画面を見ながら順に紹介します。この流れの中で、人がやったのは「何を作るか」を決めることと、できたものの確認だけです。決めた内容をもとに Figma 上に画面デザインのテンプレートを組んだのも、その Figma を読み取ってテーマファイルを作ったのも AI です。今回は Claude Code(Claude や Codex のような、パソコン上のファイルやツールを操作できる AI のコーディングエージェント)に任せました。... 続きを読む...
Shopify Horizon v4.2.0 アップデート ― RTL言語への対応・カート不具合の修正
Shopify Horizon v4.2.0 アップデート解説 ― RTL対応とカート「戻る」ボタン不具合の修正
Shopify公式テーマ「Horizon」が v4.1.5 から v4.2.0 に進みました。本記事では、コードの差分を読み解きながら、v4.1.5 から v4.2.0 への変更内容と、ストア運営者が押さえておくべきポイントをまとめます。 前回の「v4.1.5 アップデート解説」ではセーフエリア対応を取り上げましたが、今回の目玉はRTL(右から左に書く言語)対応です。加えて、カートの「戻る」ボタン周りの実用的なバグ修正も入っています。 変更サマリー ― 「181ファイル変更」の中身 差分は 181ファイル変更、+1,590行 / −712行。新規・削除ファイルは無く、既存ファイルへの変更のみです。 ストア運営者が気にすべき変更は、大きく次の通りです。 変更 影響範囲 対応の要否 ① RTL(右から左に書く言語)対応 アラビア語・ヘブライ語等での多言語展開 該当言語で展開しているストアのみ確認。それ以外は不要(自動で適用) ② カートの「戻る」ボタンで古い内容が表示される不具合の修正 カートドロワー・カートページの表示の正確性 不要(自動で適用) ③... 続きを読む...
ShopifyのチェックアウトがWebMCPに対応。日本のストアでAIエージェントに注文確定まで任せてみた
ShopifyのチェックアウトがWebMCPに対応。日本のストアでAIエージェントに注文確定まで任せてみた
2026年9月28日、Shopify のチェックアウトが WebMCP に対応しました。8月から商品検索やカート操作は WebMCP で公開されていましたが、これで「商品を探す」から「注文を確定する」までが、ブラウザで動く AI エージェントから操作できるようになります。この記事では、日本のストア(1ページのチェックアウト・日本語)で、エージェントに実際に注文確定まで進めてもらった結果をまとめます。 検証は自社の検証用ストアで、決済をテストモードにして行いました。図版の画面はすべて再現図で、ストア名・商品・氏名・住所はサンプルです。 先に結論・日本のストアでも、エージェントが注文確定まで進められました。ゲストの場合、連絡先・住所の入力から注文確定までをツールで操作でき、人が操作したのはカード番号の入力だけです。・Shop Pay にログインしている購入者なら、画面の操作はゼロでした。保存済みのカードと住所が使われ、エージェントがチェックアウトへの移動と注文確定を呼ぶだけで、購入者は承認するだけです。・ただし 普段使いの Chrome では、チェックアウトのツールはまだ現れません。WebMCP を有効にしたブラウザ(試験機能をオンにした Chrome など)が必要でした。・チェックアウトのツールが返す中身は、UCP のチェックアウトそのものでした。WebMCP は、UCP をブラウザの中から使うための経路という位置づけです。・日本語のストアでは、WebMCP の商品検索が0件になる状態が続いています。コレクションをたどれば商品にはたどり着けます。 WebMCP のおさらい WebMCP(Web Model Context Protocol)は、ブラウザで開いているページが、自分の機能を AI エージェント向けの「ツール」(呼び出せる関数)として登録しておく仕組みです。エージェントは画面のボタンを探してクリックする代わりに、ページが用意したツールを呼んで操作します。仕組みの全体像は以前の記事にまとめています。... 続きを読む...
Sidekickにステップメールをおまかせで作らせる|Flow作成からメール本文までの実装例とプロンプト
Sidekickにステップメールをおまかせで作らせる|Flow作成からメール本文までの実装例とプロンプト
Shopify の Sidekick に、新規購読者向けのステップメール(3通)をおまかせで作らせた実装例です。Flow のワークフロー作成からメール本文・写真の入力まで、実際のやり取りと使ったプロンプトを紹介します。 続きを読む...
Shopifyのストアフロントが最大29%高速化 ― Liquidテーマ開発者が気をつけるべき3点
Shopifyのストアフロントが最大29%高速化 ― Liquidテーマ開発者が気をつけるべき3点
2026年9月22日、Shopifyのパフォーマンス専門ブログ「Performance @ Shopify」に「Liquid storefronts now start loading 29% faster」という記事が公開されました。 結論から言うと、マーチャント側の作業は一切不要で、対象のページは自動的に速くなっています。ただしテーマのコードを触る人(テーマ開発者・カスタマイズ担当者)は、書き方次第でこの恩恵を丸ごと逃す、あるいは既存のスクリプトが壊れる可能性があります。この記事では、何が変わったのか・対象範囲・気をつけるべき点を整理します。 何が変わったか ― TTFB最大29%高速化の仕組み まず数字から。全ストアフロントのページビューを対象に測定した結果、中央値ストアのTTFB(Time to First Byte/サーバーが最初の1バイトを返すまでの時間)が、p75で約29%、p90で21%短縮されました。より重要な指標であるFCP(First Contentful Paint/最初のコンテンツが描画されるまでの時間)とLCP(Largest Contentful Paint/最大コンテンツの描画完了までの時間)も、2〜6%改善しています。「より重要」とShopify自身が書いているのは、TTFBは技術者向けの指標だが、FCP・LCPは購入者が実際に体感する速さだからです。 仕組みはシンプルです。Liquidのページは大きく2つの部分でできています。 <head> ― meta タグ・スタイルシートのリンク・フォントのプリロード・少数のスクリプトなど、ほぼ静的なマークアップ。レンダリングに数ミリ秒しかかからない テンプレート内のセクション群 ― 処理時間の大部分がここで消費される これまでは、両方のレンダリングが完了してから初めてブラウザに送信されていました。ブラウザは<head>が届くまで何もできず、届いて初めてスタイルシートやスクリプトの存在に気づき、ダウンロードを開始していたのです。... 続きを読む...
新しくなった Shopify Rollouts ― ローンチ・イベント・実験の使い分け
新しくなった Shopify Rollouts ― ローンチ・イベント・実験の使い分け
2026年9月22日、ShopifyのRollouts(ロールアウト)の設定画面がリニューアルされました。changelogでの分類は「Feature(新機能)」ではなく「Improvement(改善)」。告知文も5行ほどの短いもので、一見すると見逃してよさそうなアップデートです。 ただ、実際に管理画面を触ってみると印象が変わります。「テーマの切り替え」「期間限定の差し替え」「A/Bテスト」という別物だった3つが、同じ画面に同居していて区別がつかない——これがリニューアル前の状態でした。今回のアップデートはそこを整理したもので、結果としてRolloutsは「触ってみて何となく分かる」機能になっています。 この記事では、①何がアップデートされたか → ②それによって何が変わったか → ③具体的にどう使うかの順に、実際の管理画面の画像とともに解説します。検証はGrowプランのテストストアで実施しました。 何がアップデートされたか 前提:Rollouts とは Rollouts は、ストアの変更を「いつ・誰に・どれだけ」出すかを制御するShopify標準の仕組みです。管理画面の マーケット > ロールアウト にあります。2026年6月5日に、テーマとチェックアウト/顧客アカウント設定のスケジュール公開・段階公開・A/Bテストに対応しました。 対象にできる変更は2領域です。 領域 対象になるもの オンラインストア メインテーマ(現在のテーマへの編集、または別テーマへの置き換え) チェックアウトとアカウント チェックアウト構成(チェックアウト/サンキュー/注文状況/お客様アカウントの各ページ設定) 一覧画面はこのようになっています。作成したロールアウトが、ステータス・期間・対象オーディエンス・変更内容・トラフィック割り当てとともに並びます。 ステータスは 下書き → スケジュール済み → アクティブ... 続きを読む...
Shopify Horizon v4.1.5 アップデート解説 ― セーフエリア対応とカート数量入力の不具合修正
Shopify Horizon v4.1.5 アップデート解説 ― セーフエリア対応とカート数量入力の不具合修正
Shopify公式テーマ「Horizon」が v4.1.4 から v4.1.5 に進みました。本記事では、コードの差分を読み解きながら、v4.1.4 から v4.1.5 への変更内容と、ストア運営者が押さえておくべきポイントをまとめます。 前回の「v4.1.4 アップデート解説」では複数ファイルで使うCSSの共通化を取り上げましたが、今回は毛色が違います。iPhoneのノッチ・ホームインジケーターに配慮した「セーフエリア」対応が横断的に入ったほか、カート数量入力の実用バグ修正など、体験に直結する改善が中心です。 変更サマリー ― 「54ファイル変更」の中身 差分は 54ファイル変更(新規1・削除1・変更52)。前回・前々回と比べると規模は小さいですが、1つの技術的な仕込み(セーフエリア対応)が十数ファイルに波及した点は同じ構造です。 ストア運営者が気にすべき変更は、大きく次の通りです。 変更 影響範囲 対応の要否 ① セーフエリア(ノッチ・ホームインジケーター)対応 ドロワー・モーダル・カート・商品ギャラリー等のiPhone表示 不要(自動で適用) ② カート数量入力の値が消える不具合の修正 カート内での数量編集の正確性 不要(自動で適用) ③ ブログ記事カードの画像読み込み最適化 ブログ一覧ページの表示速度(LCP)... 続きを読む...
Judge.me Emailを触ってみた
Judge.me Emailを触ってみた
プロダクトレビューアプリとしてよく紹介しているJudge.meが、メールマーケティングアプリ「Judge.me Email」をリリースしていました。Shopifyアプリストアでのレビューはまだ5件と少ないものの、すべて星5・平均評価5.0という結果だったので気になり、実際にdevストアへインストールして一通り触ってみました。この記事は、そのときに確認できた機能の洗い出しです。 全体像 実際に管理画面を開いてみると、左メニューに Subscribers / Campaigns / Popups / Flows / Templates / Settings の6項目が並んでいました。実際に一通り触ってみると、購読者管理・セグメント配信・ポップアップ設置・自動化フロー・テンプレート編集・配信の詳細設定まで、CRMツールとして現場で必要とされる機能がひと通り網羅されているという印象です。順番に見ていきます。 Subscribers(購読者管理) Subscribers はShopify側の顧客データからそのまま同期される仕組みで、Judge.me側での直接編集や、CSVでのインポート・エクスポートには対応していませんでした。追加・削除はあくまでShopify管理画面側(顧客の購読設定)で行う形です。 Campaigns(キャンペーン配信) キャンペーン作成は「Audience → Content → Review & send」の3ステップです。ここで一番驚いたのが、Audience(配信先)の選択肢の広さでした。 Audience選択画面。Shopify標準セグメントとJudge.me独自のエンゲージメントセグメントを横断選択できる(画面はサンプル) 選択肢は大きく2種類に分かれています。 Shopify... 続きを読む...
Shopify Horizon v4.1.4 アップデート解説
Shopify Horizon v4.1.4 アップデート解説
Shopify公式テーマ「Horizon」が v4.1.1 から v4.1.4 に進みました。本記事では、コードの差分を読み解きながら、v4.1.1 から v4.1.4 への変更内容と、ストア運営者が押さえておくべきポイントをまとめます。 前回の「v4.1.1 アップデート解説」ではカラーシステムの全面刷新を取り上げましたが、今回はその続きです。v4.1.1 から最新の v4.1.4 までの3リリース分(v4.1.2 は公式リリースノートが存在せず、実質 v4.1.1 → v4.1.3 → v4.1.4 の流れ)で何が変わったのかを整理します。 変更サマリー ― 「168ファイル変更」の中身 差分は 168ファイル変更(新規32・変更136)、+9,083行 / −4,237行。前回のカラーシステム刷新(322ファイル)よりは小規模ですが、これも中身を見ると「複数のファイルで使うCSSを共通化した」という1つの設計変更が全体に波及した結果でした。 その証拠に、新規追加された32ファイルのうち20個が「〇〇-styles.liquid」という名前のスニペットです。ボタン・チェックボックス・スウォッチ・数量セレクター・ダイアログ・カート文字組など、これまで特定のファイルの中に埋め込まれていたCSSが、独立したファイルに切り出されました。 ストア運営者が気にすべき変更は、大きく次の通りです。 変更... 続きを読む...
ShopifyのユーザーをCSVで一括作成する ― Admin/POSの違いと実践パターン集
ShopifyのユーザーをCSVで一括作成する ― Admin/POSの違いと実践パターン集
2026年8月21日、Shopifyのchangelogで、ユーザーアカウントをCSVで一括作成・停止・再開できる機能が公開されました。季節雇用やイベント出店で人の入れ替わりが多いストアには特に効きます。ただ、実際に触ってみると「Adminユーザーとは何を指すのか」「POSユーザーはどう認証されるのか」といった、CSVの列だけでは分からない前提知識が必要でした。この記事では、その前提整理と、公式サンプルCSVを使った実践パターンをまとめてみました。 そもそも、ユーザーには2種類ある CSVには user_type という列があり、値は Admin か Point of sale の2択です。ここが最初につまずきやすいポイントでした。 「Admin」という名前ですが、権限の広さとは関係ありません。「カスタマーサポート業務だけ」「商品登録だけ」のような、権限を絞ったロールのスタッフであっても、メールアドレスとパスワードでShopify管理画面にログインする以上は Admin に分類されます。分岐点は権限の広さではなく、「管理画面にログインするかどうか」です。 一方の Point of sale は、レジ端末(POSアプリ)だけを使うスタッフ専用のカテゴリです。管理画面にはログインできず、メールアドレスも不要。4〜6桁のPINだけで認証します。 Admin Point of sale ログイン先 Shopify管理画面 POSアプリのみ 認証方法 メールアドレス+パスワード 4〜6桁のPIN 権限が絞られたスタッフ... 続きを読む...
AI検索とオーガニック検索は、トラフィックを奪い合っていない ― 同じ商品データが両方を支えている
AI検索とオーガニック検索は、トラフィックを奪い合っていない ― 同じ商品データが両方を支えている
2026年8月11日、Shopify が AI検索とオーガニック検索の役割の違いについての記事を公開しました。2026年Q2の自社データをもとにした内容です。読んでみると「AIが検索のトラフィックを奪う」という話ではなく、両方が同時に伸びていて、買い手が用途で使い分けているという整理でした。そして両者は、同じ商品データを参照して動いています。 記事の内容を追いながら、実際に手を動かして確かめてみて、記事だけでは分からなかった部分を補って整理してみました。 前提:どちらも伸びている まず数字の確認です。 AI経由のセッションは前年同期比197%増(約3倍)。注文数も3倍 一方でオーガニック検索のセッションも12%増。こちらは母数がはるかに大きい AI経由のコンバージョン率は、オーガニック経由より約80%高い AI経由は新規顧客をオーガニックの1.3倍の割合で連れてくる AI経由が増えたぶんオーガニックが減った、という関係にはなっていないとのことです。絶対量ではAI経由はまだまだオーガニックに遠く及ばないという但し書きも付いており、伸び率だけを見て即座にAIに全振り、みたいな判断はしないほうがよさそうです。 AIは「調べてから買う」カテゴリに集中している カテゴリ別に見ると差がはっきり出ています。記事は2種類に分けています。 仕様重視のカテゴリでは、AI経由のコンバージョン率がオーガニックの約2倍。腕時計は2.4倍、ネックレスは2.3倍、アパレル全体でも1.6倍という数字が挙げられています。仕様・互換性・使用例・レビュー・トレードオフを購入前に比較検討するようなカテゴリです。「自分の条件に合う商品を探す」という作業に、AIの強みが噛み合っています。 対して嗜好主導のカテゴリ、つまりブランドやスタイルを自分で決めていて、買い物体験そのものを自分でコントロールしたい場合は、発見・回遊のフェーズで今もオーガニック検索が広く使われているようです。ただし「自分のニーズに合致するかを確認する必要がない」場面では、知らないブランドと出会う手段としてAIが機能する、とも書かれています。 ジャーニーの圧縮が起きている AI経由のコンバージョン率が高い理由は、着地の仕方にあります。 In Q2, 50% of AI-referred sessions landed directly on product pages. AI経由のセッションの半分が、いきなり商品詳細ページに着地しているということです。AI検索が発見と検討を1つのプロセスに統合した結果、購買意欲が高い状態の人が、ファネルの深い段階からブランドに接触してくる。これがコンバージョン率と平均注文額の高さにつながっています。 実務上の意味は明確で、商品ページがトップページの代わりに「最初のブランド接点」になるということです。商品の説明だけでなく、ブランドとして何者かも、その1ページで伝わる必要が出てきます。記事も、明確な説明・仕様・使用例・互換性の詳細・レビュー・配送と返品の情報・FAQ・比較しやすい情報を揃えるべきだと挙げています。... 続きを読む...
Shopifyに新たに搭載されたWebMCPを調べてみた
Shopifyに新たに搭載されたWebMCPを調べてみた
2026年8月5日、Shopify が Liquid / Hydrogen の全ストアフロントに WebMCP を自動搭載したという告知がありました。設定は不要で、対応済みのストアなら今日この瞬間から動いています。実際に自分のストアと、無関係の大手ストアで動かしてみたので、その記録です。特に結論はありません。調べてみた内容をそのまま書きます。 WebMCPとは何か WebMCP(Web Model Context Protocol)は、Webページがブラウザに対して「この操作ができます」という道具(ツール)を登録できる、策定中のWeb標準です。ページ側が document.modelContext.registerTool() を呼ぶと、その場でブラウザに道具が生まれます。ブラウザ内のAIエージェントは、そのページのHTMLを読んでクリックを再現する代わりに、道具を直接呼び出せます。 Shopify側の公式ドキュメントには、対応済みストアで自動搭載される10種の道具が挙げられています。 search_catalog / browse_store / get_product / show_variant — 検索・閲覧・商品詳細 get_cart / update_cart / cancel_cart... 続きを読む...
Shopifyの新タグ {% partial %} で、Horizonの描画コードを削減
Shopifyの新タグ {% partial %} で、Horizonの描画コードを削減
2026年7月、Shopifyの developer preview(Liquid July '26)で、テーマの新しいタグが試せるようになりました。その中の {% partial %} は、ページの一部だけをサーバー側で再描画できるタグです。 触っているうちに気になったのが、「これでテーマのコードが大幅に削減できる」という話でした。Horizonのように高機能なテーマは、動きを実現するためにかなりの量のJavaScriptを抱えています。それが本当に減るのか——実際に同じ機能を書き直して、行数を比べてみました。 結果は、ページャーと並び替えが 537行 → 27行、バリアント切替が 866行 → 27行。なぜここまで変わるのか、実装したコードとあわせて整理します。 まず、Horizonが抱えているJavaScriptの量 比較の出発点として、Horizon 4.1.3 の assets/ にあるJSファイルを数えてみました。 項目 実測値 JSファイル数 81ファイル 総行数 22,610行 高機能なテーマなので、量が多いのは当然です。ただ中を見ていくと、「Liquidで書いた表示ルールを、JavaScriptでもう一度実装している」箇所が繰り返し出てきます。これが今回の主題です。... 続きを読む...
Shopifyテーマの「自由と制約」は、AIでどう変わるか ― Liquidへの原点回帰が示す過渡期
Shopifyテーマの「自由と制約」は、AIでどう変わるか ― Liquidへの原点回帰が示す過渡期
2026年7月、Shopifyの Online Store 担当プロダクトディレクター Ben Sehl 氏が「Liquid: Back to the Future」という一文を公開しました。要点はシンプルで、テーマのページ構造を、JSONテンプレートから“読めるLiquidコード”へ戻すという方向性の宣言です。あわせて developer preview(Liquid July '26)が公開され、新しい {% block %} や {% partial %} といったタグを実際に触れるようになりました。 この動き、機能の話として読むこともできますが、日々Shopifyテーマを触っている立場からすると、もっと大きな「テーマ設計の思想の揺り戻し」に見えます。この記事では、公式が示す未来像を紹介しつつ、実際に構築の現場でコードと格闘してきた視点から、「これは何を変えるのか/変えないのか」を考えてみます。 Shopifyテーマは「自由と制約」の綱引きで進化してきた Shopifyテーマの歴史は、マーチャントの自由度とコードの可読性という、しばしば相反する2つのバランスを取り直し続けてきた歴史でもあります。ざっくり3つの時代に分けられます。 時代 マーチャントの自由度 コードの可読性 テーマ設定のみ(〜2016頃)... 続きを読む...
Shopifyの商品データ設計:バリアント/メタフィールド/プロパティの使い分け(AI時代の発見性まで)
Shopifyの商品データ設計:バリアント/メタフィールド/プロパティの使い分け(AI時代の発見性まで)
Shopifyでストアを作るとき、意外と後回しにされがちなのが「商品の情報を、どこに・どう持たせるか」という設計です。色やサイズはバリアント、素材やケア方法はメタフィールド、名入れやギフトメッセージはラインアイテムプロパティ——同じ「商品ページに載る情報」でも、適した“入れ物”はそれぞれ違います。 ここを最初に間違えると、バリアントが爆発して管理不能になったり、本来「表示するだけ」でよい情報を購入時に選べてしまったり、といった事故につながります。しかも最近は、AIエージェント(ChatGPTやShopのAI)が商品を発見・購入する時代に入り、商品データの構造そのものが「AIに見つけてもらえるか」を左右し始めています。 この記事では、「〇〇をするにはこのメタフィールド」という個別レシピではなく、「こういう種類のデータだから、これで持つ」という判断の原則を、アパレルの具体例と公式ドキュメントをもとに整理します。例外は多々ありますが、まずは“標準の考え方”として押さえておくと、設計の迷いが大きく減ります。 商品情報の「入れ方」は大きく3種類 Shopifyで商品に情報を持たせる方法は、性格の異なる次の3つに分けて考えると整理しやすくなります。 バリアント(オプションで作る):色・サイズなど「買う対象そのもの」を分ける値。在庫・価格・SKU・画像をそれぞれ独立して持つ メタフィールド:素材・原産国・スペックなど「商品を説明する」付加情報。表示専用で、購入では選ばせない ラインアイテムプロパティ:名入れ・ギフトメッセージなど「お客様がその場で入力する」値。注文単位で保持される それぞれの性格の違いを1枚にまとめると、次のようになります。同じ商品ページの中でも、要素ごとに“持たせる場所”が違うのがポイントです。 同じ商品ページ上の ①②③ が、3種のデータにそのまま対応する 判断の原則:「在庫・価格・SKUが変わるか」で切り分ける 迷ったときの基準はシンプルです(例外はありますが、まずはこの原則で)。 問い 使うもの アパレルTの例 在庫・価格・SKUが変わる?(別の購入単位) バリアント カラー(黒/白)× サイズ(S/M/L) 表示するだけの付加情報? メタフィールド 素材・原産国・ケア方法/サイズ別の実寸 購入時に指定するが在庫管理は不要? ラインアイテムプロパティ 名入れ・ギフトメッセージ・ラッピング やりがちなNG:「素材」や「実寸」をオプション(=バリアントの軸)にすると、色 × サイズ... 続きを読む...
Shopifyコレクションが多ソース対応——バリアント&ネストも可能に
Shopifyコレクションが多ソース対応——バリアント&ネストも可能に
2026年7月16日、Shopifyのコレクション機能に大型アップデートが入りました。これまでコレクションは「自動(smart collection)か手動(custom collection)か、どちらか一方」を選ぶ排他的な仕組みでしたが、今回のアップデートで1つのコレクションの中に複数の「ソース(商品の供給元)」を混在させられるようになりました。さらに、商品単位だけでなくバリアント単位でコレクションを組めるようになり、コレクションの中に別のコレクションを入れる(ネストする)こともできます。 「コレクション制御のためだけのタグ」を大量に運用してきたストアほど恩恵が大きいアップデートです。この記事では、公式チェンジログとヘルプドキュメントをもとに、何ができるようになったのか・設計時に効いてくる上限や注意点を具体的に解説してみたいと思います。 従来モデルの制約:自動か手動かの二者択一 従来のコレクションは、作成時に2択でした。 自動コレクション(smart collection):「タグが organic」「価格が5,000円以下」などの条件にマッチした商品が自動で入る。ただし、条件に合わない商品を後から手動で1個だけ足すことはできない 手動コレクション(custom collection):商品を1つずつ手作業で選ぶ。条件による自動追加は使えない そのため実務では「基本は自動条件で回したいが、条件に合わない商品を数点だけ足したい/外したい」というニーズに応えられず、コレクション制御専用のタグを商品に付けて条件側を無理やり合わせる、という運用回避が定番でした。今回のアップデートは、まさにこの制約を解消するものです。 新モデル:4種類のソースを1つのコレクションに混在できる 新モデルでは、1つのコレクションに以下4種類のソースを同時に追加できます。まず、新しいコレクション追加画面を見てみましょう。右側のパネルが「ソース」で、下の「+」枠から2つ目以降のソースを追加していく構成です。 新しいコレクション追加画面。右側が「ソース」パネルで、点線の「+」から複数のソースを追加できる ソース 内容 Products(商品) 自動条件 または 手動選択で「商品」を追加 Variants(バリエーション) 自動条件 または 手動選択で「バリアント」を追加 Collection(コレクション) 既存の別コレクションを丸ごとソースとして追加(=ネストコレクション) App(アプリ) アプリが提供する商品セットを追加 ソースの種類はプルダウンで切り替える。「商品・バリエーション・コレクション・アプリ」の4択... 続きを読む...
Horizon カラーパレット徹底解剖 ― 1色決めると何が自動導出され、どのパーツに適用されるのか
Horizon カラーパレット徹底解剖 ― 1色決めると何が自動導出され、どのパーツに適用されるのか
Shopify公式テーマ「Horizon」の v4系では、配色の仕組みがカラースキーム方式からカラーパレット方式へ全面刷新されました。旧方式は6つの固定スキームに対して約50項目の色を1つずつ手で指定するものでしたが、新方式は「パレット」を1つ決めるだけで、各UI要素の色が自動的に導出されます。 この記事では、その「1色決めると、何が自動で設定され、どのパーツに適用されるのか」という波及構造を、3つの層に分けて解剖します。(v4.1.1全体の変更点は「v4.1.1 アップデート解説」をご覧ください。) まずは要点を1枚で。「パレットとは何か」「変更すると何が影響を受けるか」「自動で設定される色の正体」「旧方式から何が一番変わったか」「メリット・デメリット」の5つの疑問に沿って整理しました。 ▲ カラーパレットの早わかり。この5点を頭に入れてから、以下で仕組みを層ごとに見ていきます。 全体像 ― 3層のカスケード カラーパレットは、上流から下流へ3段階で色が流れていきます。 ① あなたが設定する層 ― カラーパレット(背景・メインカラー+任意の色)。ここだけを触る ② 自動で導出される層 ― 各要素の色を「パレット参照」で割り当て + color-palette.liquid が計算(コントラスト・ホバー色など)→ CSS変数に展開 ③ 適用されるUIパーツ ― ボタン・入力欄・バリアント・カートなど。各コンポーネントはCSS変数を参照するだけ ▲ ①パレット(狭い=少数)から、②導出・③パーツ(広い=多数)へと波及していくピラミッド構造。 層①... 続きを読む...
Shopify Horizon v4.1.1 アップデート解説 ― メジャーアップの目玉は「カラーシステムの刷新」
Shopify Horizon v4.1.1 アップデート解説 ― メジャーアップの目玉は「カラーシステムの刷新」
Shopify公式テーマ「Horizon」が、ついに v4系(メジャーバージョン) に到達しました。本記事では、コードの差分を読み解きながら、v3.5.1 から v4.1.1 への変更内容と、ストア運営者が押さえておくべきポイントをまとめます。 前回の「v3.5.1 アップデート解説」に続く内容です。今回は、前回取り上げた v3.5.1 から最新の v4.1.1 までで何が変わったのかを整理し、アップデートを取り込む際の判断材料をお伝えします。 変更サマリー ― 「322ファイル変更」の正体 差分は 322ファイル変更(新規32・削除2・変更288)、+14,056行 / −8,074行。数字だけ見ると非常に大きなアップデートに見えます。 しかし中身を精査すると、変更の大半は「ある1つの設計変更」がテーマ全体に波及した結果でした。その設計変更とは、カラーシステムの全面刷新です。 その証拠に、テーマ設定(settings_schema.json)で 追加された31項目はすべて色関連、削除された47項目もほぼすべて旧カラースキーム関連でした。ボタン・バリアント・入力欄・カート・ポップオーバーなど、色を扱うほぼ全コンポーネントが新方式に書き換わったため、変更ファイル数が膨らんでいます。 ストア運営者が気にすべき変更は、大きく次の通りです。 変更 影響範囲 対応の要否 ① カラーシステムの刷新(color_schemes → color_palette)... 続きを読む...
Shopify Editions Spring ’26 開発者
Shopify Editions Spring ’26 開発者
← Shopify Editions Spring ’26 全まとめ CATEGORY 10 / 開発者 開発者カテゴリーは 全54項目で全10カテゴリー中いちばん多い更新群です。一本に貫く流れは 「開発そのものをAIエージェント前提に作り直す」こと。お気に入りのAIコーディングエージェントから Shopify を正確に扱える AI Toolkit、フレームワークを選ばない 新しい Hydrogen、テーマとアプリ・AIが確実につながる 標準ストアフロントイベント——いずれも「人が手で書く/AIが書く」のどちらでも壊れにくい土台づくりに向いています。開発者向けAPI・ツールが中心のため、ごく一部(Shop 消費者アプリ・WhatsApp 依存の項目)を除き、原則すべて日本でも使えます。 検証ステータスについて:本カテゴリーは 公式ドキュメント(shopify.dev/changelog)ベースで整理しています。Developer Preview(先行公開)や 2026-07 以降提供の項目を含み、実機での挙動確認は限定的です。数値・正式な提供時期は出典先で最新をご確認ください。日本可否は「開発者向けAPIは原則グローバル提供」という前提に基づく判断です。 HIGHLIGHT 見どころ:開発が「エージェントファースト」に作り直された 54項目を並べると、個々の機能改善の奥に一貫した設計思想が見えます。それは「AIエージェントが... 続きを読む...
Shopify Editions Spring ’26 財務
Shopify Editions Spring ’26 財務
← Shopify Editions Spring ’26 全まとめ CATEGORY 09 / 財務 財務カテゴリーは Shopify Balance(事業用口座)・Shopify Capital(資金調達)・Shopify Tax(税計算) まわりの更新で、全7項目が日本では基本的に使えません(提供地域=米国5・カナダ1・フランス1)。理由はバラバラの地域ロックではなく、土台となる Balance・Capital が日本未提供/今回の Tax 拡大はカナダ向けだから。日本のストアがそのまま導入できる項目はありません。とはいえ、読み取るべきは個々の機能より、Shopify が決済の外(入金・送金・融資・税務)まで取り込む“金融プラットフォーム化”の方向性です。 検証ステータスについて:本カテゴリーは公式ヘルプ(help.shopify.com)が bot ブロック(403/429)されやすく、公式 Editions の記述および一般知識ベースで整理しています。還元率・手数料などの数値は出典未取得のため断定しません。いずれも日本未提供で、実機確認は対象外です。 HIGHLIGHT 見どころ:Shopify の「金融プラットフォーム化」 7項目はバラバラの小機能に見えて一本の線でつながっています。Shopify... 続きを読む...
Shopify Editions Spring ’26 決済
Shopify Editions Spring ’26 決済
← Shopify Editions Spring ’26 全まとめ CATEGORY 08 / 決済 決済カテゴリーは、地味だが効く「不正対策・チェックアウト最適化」と、地域・通貨ごとの拡大が混在しています。読み解いていくと、日本のストアにそのまま即効で効くもの(カードテスト攻撃の自動ブロック、チェックアウト改善、住所オートコンプリート等)と、地域が限定されて日本には直接関係しないもの(メキシコの分割払い、UAE 展開、USDC 決済など)の温度差がはっきり出ています。この記事では、その「日本で使えるか」の見極めを各項目に添えながら整理しました。 検証ステータスについて:このカテゴリーは、各機能の公式ヘルプ/Editions ページ(多くは日本語版)を取得してドキュメントベースで整理しています(一部を除き実機での挙動確認は行っていません)。そのため断定を避け、公式記述に基づく箇所は「公式によると」「〜とされています」と明記しています。「日本可否」も出典記述からの判断で、実機での提供開始時期・表示の細部は別途確認が要る前提です。 SECTION 不正・リスク対策:このカテゴリーの目玉 #13 カードテスト攻撃に対する不正注文防止の強化 機械学習が取引リスクをスコアリングし、攻撃を自動ブロック(公式によると約90%)。 + 日本:即効で使える このカテゴリーで唯一の重要度S。カードテスト攻撃(Card Testing Attack)とは、攻撃者が不正入手した大量のカード番号が「まだ使えるか」を確かめるため、チェックアウトで少額決済を高速・大量に試す行為です。ストアが「カードの生死判定機」として悪用され、被害は決済額そのものより手数料の積み上がり・チャージバック急増・チャージバック率の悪化といった付随コストが重くなります。 今回、Shopify は教師あり機械学習モデル(正解ラベル付きデータで学習させた予測モデル)でチェックアウト時の取引リスクをリアルタイムにスコアリングし、攻撃と判定したものを自動ブロックします。判定には ①行動パターン(試行の速度・タイミング・操作の癖)②ネットワークレベルのシグナル(マーチャント横断・決済代行横断の活動、デバイスフィンガープリント)③取引コンテキスト(決済方法・業種・購入履歴)の3系統を使うとされています。 ▲ ML が3系統のシグナルでリスクをスコアリングし攻撃を自動ブロック(公式記述に基づく概念図)... 続きを読む...
Shopify Editions Spring ’26 Shopアプリ
Shopify Editions Spring ’26 Shopアプリ
← Shopify Editions Spring ’26 全まとめ CATEGORY 07 / Shopアプリ Shopify が運営する消費者向けの買い物アプリ(Shop)関連のアップデートです。マーチャントが自分で持つストアフロント(テーマ)とは別に、巨大な Shop アカウントと Shop Pay(保存済みの住所・クレジットカード情報)をベースに、全世界のShopifyストアを跨いで購入できるチャネルです。この記事では、実際に Shop を使い、買い手AIエージェントでの自律購入まで実機で確認しながら、解説しています。 SECTION 発見:探し方が変わる #01 買い物客の視点で設計された検索 会話で見つけ・比較・検討。好みとShop履歴でパーソナライズ。 + キーワードを正確に打ち込む「お店の都合の検索」ではなく、「会話を通じて商品を見つけ、比較し、検討する」買い物客視点の検索です。Ask anything… に話しかけると、AIが意図をくんで商品群と解説を返し、好みや Shop での履歴に基づいておすすめがパーソナライズされます。 実際に試すと、日本語で「日本で購入できるものある?」と尋ねるだけで、AIが「日本に配送できるショップ(配送対象国にJPが含まれる)」まで判定し、商品群+解説+絞り込み候補(浅煎り/深煎り/エスプレッソ向け等)まで返してきました。ただしこの会話検索モードは現状アメリカ先行で、日本の... 続きを読む...
Shopify Editions Spring ’26 オペレーション
Shopify Editions Spring ’26 オペレーション
← Shopify Editions Spring ’26 全まとめ CATEGORY 06 / オペレーション オペレーションは、ストア運営の裏側——分析・自動化・在庫・注文・配送、そしてAI連携——を支える50項目です。この記事では、日本のストアで実際に使えて効く機能を実機で確認しながら深掘りし、在庫まわりは公式動画・ドキュメントに基づく紹介、Shopify Shipping や Managed Markets など日本対象外のグローバル機能は末尾に出典リンクのみでまとめています。画面図は実機を確認したうえでの概念図(ダミーデータ)です。 SECTION AIと自動化の入口 #01 より多くのバイブコーディングパートナー Lovable・Manus 等のAIツールでフロントを生成し、裏側はShopify。 + 「バイブコーディング」=作りたいものを自然言語でAIに伝えて生成する開発スタイルです。Lovable・Manus・V0・Replit などでストアフロント(見た目)だけを生成し、商品・在庫・カート・決済といった商取引基盤は Shopify が Storefront API 経由で担う——いわゆるヘッドレスコマースの連携先が増えました。... 続きを読む...
Shopify Editions Spring ’26 マーケティング
Shopify Editions Spring ’26 マーケティング
← Shopify Editions Spring ’26 全まとめ CATEGORY 05 / マーケティング 「マーケティング」は、集客と販促をAIで底上げするアップデート集です。広告運用をAIが継続的に学習・最適化する Campaign Autopilot、メール・SMS・WhatsApp を束ねる Shopify Messaging、そして計測・同意まわりの整備が柱になっています。※本カテゴリは、検証ストアで実機確認できた項目(各項目に「実機確認」と明記)と、公式情報(Editions 発表・changelog・ヘルプ)に基づく項目が混在します。日本では使えない項目(Shop Campaigns・WhatsApp・SMS 等)はその旨を明記しています。 日本で使える6項目(実機確認)を本編に掲載 / 日本対象外の6項目は末尾にまとめて紹介 GROUP 1 / AIマーケティングと配信 AIが広告を回し、メール配信を最適化(2項目) #01Campaign Autopilot AIが広告キャンペーンを継続的に学習・最適化し、チャネルをまたいで運用。... 続きを読む...
Shopify Editions Spring ’26 小売(POS)
Shopify Editions Spring ’26 小売(POS)
← Shopify Editions Spring ’26 全まとめ CATEGORY 04 / 小売(POS) 小売(POS)カテゴリーは、実店舗での販売を支える Shopify POS(Point of Sale/店頭レジ)まわりの強化が中心です。なお、POS Pro / Shopify Plus / 特定地域に限定され、こちらで実機確認できなかった機能は、不正確な説明を避けるため末尾に割愛理由とともにまとめて掲載しています(各公式ドキュメントへのリンク付き)。 実機・公式動画で確認できた6項目 / 開いて詳細を表示 史上最速のPOS(V11) 常時表示カートで会計を短縮し、1分以上の時間を節約。 + 正式名称:Shopify POS version... 続きを読む...
Shopify Editions Spring ’26 オンライン
Shopify Editions Spring ’26 オンライン
← Shopify Editions Spring ’26 全まとめ CATEGORY 03 / オンライン 「オンライン」は、あなたのオンラインストアそのものに関わるアップデート集です。接客・検索・テーマ編集・お客様アカウント・海外販売(マーケット)・B2B(企業間取引)・Shopify Collective(ストア間の仕入れ)まで、全25項目と幅広いのが特徴です。全体を貫くのは ①AIが店を賢くする ②世界中・どんな相手にも売りやすくする という2つの流れです。本記事では25項目を6つのテーマに整理し、出典つきで一つずつ解説してみました。 全25項目 / 6テーマ / 開いて詳細を表示 GROUP 1 / AIがストアを賢くする 接客・分析・検索・価格づけをAIが底上げする(4項目) #01 AI販売スタッフ(Shopify Inbox) 近日公開・要アップグレード チャット接客のShopify... 続きを読む...
Shopify Editions Spring ’26 Sidekick
Shopify Editions Spring ’26 Sidekick
← Shopify Editions Spring ’26 全まとめ CATEGORY 02 / Sidekick Sidekick は、Shopify 管理画面に最初から組み込まれている AI アシスタントです。今回の Editions では、その Sidekick もまた進化したようです。純粋に Sidekick の性能が向上し、より正確に回答やタスクを実行してくれるようになりました。さらにマルチタスクや顧客の作成などもこなし、対応済みのアプリについては、Sidekick がアプリの操作まで行ってくれるようになっています。本記事では全9項目を、出典つきで一つずつ見ていきます。実際に検証ストアで触って確かめた項目には、その様子も添えています(※ストア固有の数値・名称は伏せています)。 全9項目 / 開いて詳細を表示 Sidekickがアプリと連携開発者プレビュー・招待制 Klaviyo・Judge.me・Smile・Loop 等のアプリについて質問に答え、アプリ内アクションまで実行。 + 正式名称:Sidekick... 続きを読む...
Shopify Editions Spring ’26 エージェンティック|AIコマース基盤の開放
Shopify Editions Spring ’26 エージェンティック|AIコマース基盤の開放
← Shopify Editions Spring ’26 全まとめ CATEGORY 01 / エージェンティック 今回の Editions の中心テーマが、この「エージェンティック」カテゴリーです。ChatGPT・Copilot・Gemini・Perplexity といったAIアシスタントの会話の中で商品が発見・推薦され、対応チャネルではそのまま購入へとつながっていく——いわゆる「エージェンティックコマース」へ、Shopify が商品・決済の基盤を開放していく11項目が並びます(チャットでの決済完結まで対応するかはチャネルごとに異なります)。技術的な土台は Catalog API と UCP(Universal Commerce Protocol/統一コマースプロトコル)。本記事では全11項目を、出典つきで一つずつ見ていきたいと思います。 全11項目 / 開いて詳細を表示 AI向けに最適化された商品 AIチャネルに商品を自動出品し、パフォーマンス確認・売上追跡・改善ガイダンスまで一括管理できる。 + 正式名称:Agentic storefronts /... 続きを読む...
Shopify Editions Spring ’26 全まとめ
Shopify Editions Spring ’26 全まとめ
公式は「150以上」とうたう半期アップデート集ですが、2026年6月18日時点の日本語ページから数えると10カテゴリー・218項目、かなりのボリュームです。全体を通して見えてくるのは、コマースが「Shopify の中」から あらゆる場所(AIとの会話・外部サイト・店頭)へ広がっていく大きな流れのように思います。タイトルの “Everywhere” は、まさにその方向性を言い表しているのかもしれません。 今回の5つの大きな流れ / KEY SHIFTS 01Shopify の商品・決済基盤を AIエージェントへ開放(Catalog API / UCP) 02Sidekick や外部AIから ストアを操作 03Shop Pay を Shopify 外へ拡張 04B2B・POS・運用機能の裾野を拡大 05開発を AIエージェント前提に再設計 今回の見どころ / HIGHLIGHTS 01... 続きを読む...
Shopifyストアの agents.md.liquid でAI向け情報をカスタマイズ
Shopifyストアの agents.md.liquid でAI向け情報をカスタマイズ
2026年5月29日、Shopify は /agents.md、/llms.txt、/llms-full.txt のカスタマイズ機能をリリースしました。これらは AI エージェント(ChatGPT、Claude、Copilot 等)がストア情報を取得するための「指示書」です。 何もしなくても Shopify が自動生成してくれますが、テーマの Liquid テンプレートで完全にカスタマイズできるようになりました。 テンプレートの読み込み順序 3つのファイルはそれぞれ専用テンプレートを持てますが、なければ agents.md.liquid にフォールバックします。 /agents.md → agents.md.liquid → Shopify自動生成 /llms.txt → llms.txt.liquid → agents.md.liquid → Shopify自動生成 /llms-full.txt →... 続きを読む...
chrome-devtools-mcpを使ってモバイル実機に近い形でAIブラウザテスト
chrome-devtools-mcpを使ってモバイル実機に近い形でAIブラウザテスト
AIにブラウザを操作させてShopifyストアをモバイル確認するとき、Chrome拡張でウィンドウ幅を390pxにリサイズしていました。chrome-devtools-mcpに切り替えてから、User Agent・タッチイベント・メディアクエリも含めて実機に近い状態で確認できるようになりました。 見た目は似ていますが、ウィンドウリサイズとデバイスエミュレーションは動作が全然違います。 ウィンドウリサイズとデバイスエミュレーションの違い Chrome拡張でウィンドウを390pxに縮めると見た目はモバイルっぽくなりますが、変わるのは表示幅だけです。chrome-devtools-mcpのエミュレーションはもう少し深いところまで切り替わります。 項目 ウィンドウリサイズ デバイスエミュレーション 表示幅 ✅ 変わる ✅ 変わる User Agent ❌ PCのまま ✅ iPhoneに変わる タッチイベント ❌ マウスイベントのまま ✅ タッチイベントに切替 Device Pixel Ratio ❌ 1xのまま ✅... 続きを読む...
Shopifyテーマ改修後のAIを使ったブラウザ確認のポイント
Shopifyテーマ改修後のAIを使ったブラウザ確認のポイント
Shopifyのテーマを改修した後、「どこか壊れていないか」の確認をAIに任せることができます。ClaudeやCodexなど主要なAIツールはChrome拡張を通じてブラウザを直接操作できるので、ページを開いて・スクロールして・クリックして・確認する、という作業をそのままやらせることができます。 本記事では、Shopifyストアのブラウザテストにどう使えるか、実際に動くプロンプト例とともに紹介します。 AIがChromeを操作するとはどういうことか Claude(Claude in Chrome拡張)やCodex(Chrome拡張)は、Chrome拡張を通じてブラウザを操作できます。ストアテストに使う場合、AIは次のことをやります: 実際にページを開いて、レンダリングされた画面を「見る」 スクロールして、画面外の要素を確認する クリック・入力・ウィンドウサイズ変更などの操作を実行する 気になる点を言語化して報告する Chrome拡張経由で動くため、普段使っているChromeのセッションやCookieがそのまま使われます。ログイン済みのストアプレビューにもそのままアクセスできます。 DOMの存在確認だけでなく、実際に画面として表示された状態を評価できるのが従来の自動テストとの大きな違いです。 使えるプロンプト例 購入フロー確認 テーマ改修後に最初に走らせる基本テストです。 Shopifyストア(https://xxx.myshopify.com)の購入フローを確認してください。 以下の順番で実際に操作し、各ステップで気になる点があれば指摘してください: 1. トップページを開き、レイアウト・ヘッダー・フッターに問題がないか確認 2. コレクションページで商品一覧を確認(画像の読み込み・価格表示・グリッドの崩れ) 3. 商品詳細ページを開く(画像・バリアント選択・カートボタンの視認性) 4. カートに追加し、カートページを確認(商品情報・数量・合計金額の表示) 5. チェックアウトに進む(この先は操作せず、画面の状態だけ確認) 特に以下の観点で確認してください: - ボタン・リンクが視覚的に押せる状態か(色・サイズ・重なり)... 続きを読む...
Shopify が公開した UCP CLI と Global Catalog ── AI エージェント向け商品検索インフラを試してみた
Shopify が公開した UCP CLI と Global Catalog ── AI エージェント向け商品検索インフラを試してみた
2026年5月19日、Shopify の開発者公式アカウントから、AI エージェント向けの新しい仕組みが本格稼働したというアナウンスがありました。具体的には、UCP CLI と呼ばれるコマンドラインツール、そして Global Catalog という新しい商品検索インデックスの公開です。 ユニバーサル・コマース・プロトコルがすべての加盟店向けに本格稼働しました。Shopify Catalog で数十億の商品を検索し、カートを作成し、新しい UCP スキルでチェックアウトする方法をエージェントに教えます。 — Shopify Developers のアナウンス(2026-05-19) 先日の記事で、Shopify が全ストアに対して AI エージェント向けのエンドポイント(/llms.txt / /agents.md / /.well-known/ucp)を自動配備していたことを取り上げましたが、その続報にあたる内容になります。本記事では、今回公開された UCP CLI と Global Catalog... 続きを読む...
Google公式 AI検索ガイドが示す、ECサイトがやるべきこと・やめていいこと
Google公式 AI検索ガイドが示す、ECサイトがやるべきこと・やめていいこと
Google が「Optimizing your website for generative AI features on Google Search」という公式ガイドを公開しました。AI Overviews や AI Mode といった生成AI機能に向けて何をすべきか、Google が直接説明したものです。 このガイドを受けて、Shopify マーチャントはどう動けばいいのか。本記事では「続けること / やめていいこと / 新たに取り組むこと」の 3 つに整理してまとめてみました。 まず結論:3 つのアクション 分類 具体的な内容 ✅... 続きを読む...
Shopifyが全ストアに自動配備していたAI Commerce対応エンドポイント — llms.txt / agents.md / UCP / MCP の中身
Shopifyが全ストアに自動配備していたAI Commerce対応エンドポイント — llms.txt / agents.md / UCP / MCP の中身
きっかけは、ある海外Shopifyストア(Mudminnow Clothing)の https://mudminnowclothing.com/llms.txt を見たことでした。AI エージェント向けに「サイトの自己紹介」を Markdown で配信するという新しい標準フォーマットで、UCP(Universal Commerce Protocol)対応もうたっていました。 「先進的なストアだな」と思ったのですが、その後あるエンジニアの一言が目に留まりました。 "And... Shopify has already replaced one of our features. On launch day, lol." (llms.txt 提供アプリを作っていたら、Shopify が launch day で標準対応してきた、という嘆き) 気になって自社のShopifyストアで実際に叩いてみたところ、何も設定していないのに、AI... 続きを読む...
AIエージェントは商品ページの何を見ているのか — Shopify Agentic Readinessから読み解く11項目
AIエージェントは商品ページの何を見ているのか — Shopify Agentic Readinessから読み解く11項目
Shopifyが Agentic Readiness という検証ツールを公開しました。これはECサイトの商品ページが「AIエージェントから商品としてどれだけ正しく認識されるか」をチェックするツールです。 ShopifyJPの告知ポスト によると、ChatGPT・Gemini・Copilot・PerplexityといったAIエージェント経由で商品を発見・購入される時代に向けて、商品ページがAIから「見える」ものになっているかをセルフチェックできるようになっています。 興味深いことに Shopifyストアは検証対象外 です。Shopifyを使っていれば標準で要件を満たしているという前提で、検証する必要が無いということかと思われます。逆に言えば、Shopify以外のサイトで試せば、Shopifyが何を「あらかじめやってくれているか」が見えてきます。 そこで実際に試してみたところ、その結果から、AIエージェントが商品ページをどう見ているか、そして何がNGになるかが具体的に見えてきました。本記事では検証ツールが見る11項目を、「AIは何を見ているか / 何がNGになるか」 という視点で深掘りします。 検証ツールでは「エージェントの『見つけやすさ』スコア」(100点満点)と、11個の要素ごとの判定(合格 / 不合格 / 改善が必要 / 未検出)が表示されます。スコアが低い場合、どの要素がNGになっているのかを1つずつ確認していきます。 結論を一言で AIエージェントは「ページを読んでいる」のではなく「構造化データを解析している」。 schema.org の Product マークアップと Organization マークアップを起点に商品を理解しているため、これらが欠けているとAIには商品の存在自体がうまく認識されません。ユーザーには見えていてもAIには見えていない情報 があるということですね。 AIが見ている11項目の全体像... 続きを読む...
【Horizon】カラムレイアウトブロックで幅比率を自由に設定する独自ブロック
【Horizon】カラムレイアウトブロックで幅比率を自由に設定する独自ブロック
Horizonテーマでページを作り込んでいると、「ここに2カラムのサイドバー付きレイアウトが欲しい」「3カラムで商品を並べたい」という場面に必ず出くわします。 Horizonには group ブロックがあり横並びレイアウト自体は可能ですが、各カラムの幅比率を直接指定する手段がありません。たとえば「左にメインコンテンツ、右にサイドバー(2:1)」を作ろうとすると、間接的な方法で調整するしかなく、思い通りの比率を出すのに苦労します。 この記事では、この課題を解決するカスタムカラムレイアウトブロックを紹介します。テーマエディタでプリセットを選ぶだけで柔軟なカラムレイアウトが実現でき、既存ファイルへの変更も不要です。 groupブロックの限界 Horizonの group ブロックは汎用的なコンテナで、子ブロックを横並びや縦並びに配置できます。しかし、カラムレイアウトとして使おうとすると以下の壁にぶつかります。 幅比率を指定できない ― 「左2:右1」のように明示的な比率指定ができない。子ブロックの幅設定を個別に調整して近似する必要がある デスクトップ/モバイルの独立制御が難しい ― デスクトップでは3列、モバイルでは1列に積む、といったレスポンシブ制御が直接はできない カラム間の余白調整が限定的 ― 横方向・縦方向のgapを個別にpx単位で指定する仕組みがない こうした制限を回避するために、PageFlyなどの外部ページビルダーアプリを使うケースもあります。ただ、アプリを追加するとJavaScriptの読み込みが増えて表示速度に影響が出たり、テーマのカラースキームやデザインシステムとの一貫性が崩れやすくなります。 カラムレイアウトブロックでできること 今回紹介するカラムレイアウトブロックは、CSS Gridをベースにしたテーマネイティブのカスタムブロックです。テーマエディタからノーコードで操作でき、以下のことが可能です。 14パターンのプリセット + カスタム自由入力 テーマエディタのドロップダウンから、よく使うカラムパターンをワンクリックで選べます。 プリセットで選べるカラム比率の一覧。デスクトップ/モバイルを個別に設定できる パターン 用途例 2列均等(1:1)... 続きを読む...
Shopify AI Toolkitを本番ストアで使う前に整えておきたいこと
Shopify AI Toolkitを本番ストアで使う前に整えておきたいこと
Shopifyが公式リリースした「Shopify AI Toolkit」は、Claude CodeやCursorなどのAIツールから、Shopifyストアを直接操作できるプラグインです。商品の追加や在庫調整、割引作成など、管理画面でできることの多くをAIに任せられる、かなり強力な仕組みです。 ただ、便利さの裏返しとして気になるのが「AIが誤った操作をしたら何が起こるのか」という点です。Shopifyには「ゴミ箱」も「元に戻す」機能もありません。商品を削除すればその瞬間に完全に消え、価格を上書きすれば元の値は戻せません。 そこで、起こりうる事故の具体例とあわせてAI Toolkitを使い始める前に整えておきたいことをまとめてみました。 なぜここまで警戒が必要なのか 管理画面を手で触っている時は、削除ボタンを押すと「本当に削除しますか?」という確認ダイアログが出てきます。これが最後の砦として、うっかりミスを止めてくれていました。 ところがAI経由で直接操作する場合、この確認ダイアログがありません。さらにShopifyの仕様として、次の3点を押さえておく必要があります。 削除は即完全削除:ゴミ箱も元に戻すもありません 上書きは即永久上書き:元の値はどこにも保存されません AIは間違いに自信を持つ:コードとしては正しく見える操作でも、条件指定が間違っていれば全商品に影響しうる つまり、最後の砦は自分で用意するしかないというのが前提になります。 起こりうる事故の例 「何が起こりうるか」を具体的に見ておきます。代表的なものを並べました。 商品の削除(戻しにくさ★★★): 商品データの画像・バリアント・在庫情報がまとめて消えてしまうケース。GoogleにインデックスされていたURLは404になり、広告リンクや外部リンクが無効になります。バックアップから戻しても商品IDが変わるため、外部ツール(Klaviyo・GA4・広告)との連携が壊れる可能性が高いです。 価格の誤変更(戻しにくさ★★): 全商品の価格が意図せず書き換わってしまうケース。発覚までの数時間の間に注文が入れば、極端な安値で販売成立してしまい、出荷義務が発生する可能性があります。 在庫の破壊(戻しにくさ★★): 在庫数が誤った値に上書きされ、実在庫とサイト表示がずれてしまうケース。売り切れ表示で販売機会を失ったり、逆に欠品状態のまま販売してクレームになるリスクがあります。 顧客データの削除(戻しにくさ★★★): 顧客アカウント・注文履歴・住所・メルマガ配信同意が全部消えてしまうケース。個人情報は一度消してしまうと再取得することができません(本人から再同意を取るしかない)。個人情報保護の観点でも事故扱いになりえます。 カスタム情報の上書き(戻しにくさ★★★): 商品に紐づけている原産地・成分・ブランド情報などのメタフィールドが誤った値で上書きされてしまうケース。テーマがこの情報を参照している場合、商品ページの表示がその場で崩れてしまう可能性があります。 ページやブログの削除(戻しにくさ★★★): ストアのページやブログ記事が消えてしまうケース。すぐに復帰できれば良いのですが、しばらくたって気づいた後では、Googleに再インデックスされるまで数週間かかってしまうことがあります。 誤った割引の作成(戻しにくさ★): 全商品100%... 続きを読む...
【Horizon】ドロワーメニューにバナー画像を表示するカスタマイズ
【Horizon】ドロワーメニューにバナー画像を表示するカスタマイズ
「ドロワーメニューにキャンペーンバナーを表示したい」 モバイルのハンバーガーメニューを開いたとき、ナビゲーションの下にバナー画像を表示してクーポン配布やセール告知の導線にしたい、というのはよくある要望です。Dawn/Riseテーマには設定例がありますが、Horizonではどうでしょうか。 結論から言うと、Horizonでも実装可能ですが、ファイル構造の違いによりベンダーファイルの編集が必要になります。本記事では、ファイル追跡の過程から、テーマエディタで画像とリンクを設定できるようにするまでの具体的な手順を紹介します。 なお、本記事ではHorizonのカスタマイズ方針で推奨されている custom.* ファイルの新設は敢えて行わず、ベンダーファイルを直接編集する方法を掲載しています。その理由についても詳細に述べていますので、併せてご確認ください。 完成イメージ ドロワーメニューのナビゲーション下部にバナー画像が表示され、テーマエディタのメニューブロック設定から画像とリンク先を自由に変更できるようになります。画像を設定しなければ何も表示されないため、元の見た目は一切変わりません。 Dawnでの対応 Dawn/Riseテーマの場合、ヘッダーセクションとドロワーメニューは同じファイルに収まっています。 // Dawn/Riseの場合 sections/header.liquid ← schema定義もドロワーの描画コードも全てここ header.liquid のschemaに image_picker(画像選択)と url(リンク先)の設定を追加し、同じファイル内のドロワー描画部分にバナー表示コードを追加するだけで完了です。変更は1ファイルで完結します。 Horizonでのドロワーメニュー:ファイルの分離 Horizonでは、ドロワーメニューの機能が3つのファイルに分かれています。 // Horizonの場合 sections/header.liquid ← セクション本体 └─ blocks/_header-menu.liquid ← メニューブロック(schema定義はここ)... 続きを読む...
AIが商品を選ぶ時代に備える ― Shopify Agentic Commerce対応について
AIが商品を選ぶ時代に備える ― Shopify Agentic Commerce対応について
Shopifyが「Agentic Storefronts」をローンチしました。ChatGPTやGoogle Gemini、Microsoft Copilot、PerplexityといったAIエージェントが、Shopifyストアの商品を直接発見・推薦・購入できるようになる仕組みです。 この記事では、AIエージェントが商品データをどう読み取っているのかを技術的なソースをもとに調べ、ストア運営者としてどのようなアクションをとるべきか整理してみたいと思います。 AIエージェントは「構造化フィールド」で商品を選ぶ ChatGPTのショッピング機能の裏側では、OpenAIが定義した「Agentic Commerce Protocol(ACP)」というプロトコルが動いているようです。このプロトコルの技術仕様を見ると、商品データはCSV・TSV・JSON等の構造化フィードとして15分ごとに同期される仕組みになっています。 Shopifyの場合、この商品フィードは「Shopify Catalog」が自動生成してくれるようです。フィードに含まれるのは以下のようなフィールドです。 フィールド 内容 AIでの用途 title 商品名 クエリとの一次マッチング price 価格 予算フィルタリング availability 在庫状況 在庫切れ除外 category 商品カテゴリ カテゴリベースの検索・分類 image_url 商品画像 ビジュアル表示・マルチモーダル解析 description... 続きを読む...
Horizon UIデザインキットからShopifyテンプレートJSONを自動生成する
Horizon UIデザインキットからShopifyテンプレートJSONを自動生成する
先日公開したHorizonテーマのUIデザインキットには、デザイン検証以外にもう一つの意図があります。テーマエディタで設定可能なセクション名やブロック名をFigmaのコンポーネント名と1:1で対応させることで、AIが各要素を正しく判別し、テンプレートJSONとして出力できるようにしています。 キット内のセクションやブロックのパーツを並べれば、Figma MCPのget_design_contextで構造データを取得し、命名規則に基づいてShopifyのテンプレートファイルに変換する、という流れです。 テンプレートJSONとLiquidコードについて Shopifyのテーマには「テンプレートJSON」と「Liquidコード」の2つのレイヤーがあります。 テンプレートJSON(templates/*.json):どのセクションをどの順番で配置し、各設定をどうするか。テーマエディタで編集する部分 Liquidコード(sections/*.liquid):セクション自体の見た目や動きを定義するコード。開発者が書く部分 今回自動化するのはテンプレートJSONの方です。テーマのコードには一切触れないので、テーマのアップデートとも干渉しません。 コード改修せずテンプレート設定にとどめる理由 Horizonは従来のShopifyテーマとは構造がかなり異なります。ロジックファイルと描画ファイルが複雑に分散されており、CSSとJavaScriptによる疎結合のイベント制御が随所に使われています。この特殊な設計のため、中途半端にコードをいじると思わぬところに影響が出るリスクがあります。 それ以上に、Horizonはアップデートのたびに性能やUIが改善されているテーマなので、コードを直接変更してしまうとその恩恵を受けられなくなります。テーマ更新時にコンフリクトが発生し、更新を見送り続けるか、差分を手作業でマージし続けるか、という運用負荷を抱えることになります。 そう考えると、カスタマイズのレベルをテーマエディタで設定可能な範囲にとどめておく方が、長期的には健全な運用になるのではないかと思っています。テンプレートJSON(セクションの構成と設定値)だけを自動化するアプローチは、この考え方に基づいています。 ワークフロー全体の流れ Figmaデザインキット上でテンプレートを組む Figma MCPでデザインの構造データを取得(Claude Code) 命名規則に基づいてテンプレートJSONに変換(Claude Code) 画像をShopify Filesにアップロード(Claude Code) 商品・コレクション・ブログを割り当て(Claude Code) テーマに反映(Claude Code) つまりFigmaでデザインを行なったあとの工程はすべてClaudeが担います。これをClaude Codeのスキルとして定義し、コマンドで実行できるようにしています。 命名規則がすべてを決める この仕組みの精度を決めるのは、Figma上のコンポーネント名です。get_design_contextは各要素のレイヤー名やコンポーネント名を構造データとして返してくれます。... 続きを読む...
Shopifyテーマ「Horizon」のUIデザインキット for Figmaを公開しました
Shopifyテーマ「Horizon」のUIデザインキット for Figmaを公開しました
Shopifyの最新テーマ「Horizon」のUIデザインキットをFigmaで作成しました。テーマカスタマイズの設計やクライアントへの提案時に、実際のテーマ構造に基づいたデザイン検証ができるようにすることが目的です。 無料で公開していますので、Horizonテーマを使ったストア構築やリニューアルを検討されている方はぜひご活用ください。 【Horizon】Shopifyテーマ「Horizon」UIデザインキット for Figma なぜUIデザインキットを作ったのか Shopifyのテーマカスタマイズを設計する際、テーマエディタはプレビューの読み込みがやや重く、セクションの入れ替えや設定変更のたびに待ちが発生するため、スピーディーにデザインを検証しづらい面があります。また、Horizonはセクションとブロックの組み合わせパターンが豊富で、レイアウトの自由度が高い分、事前にデザインを固めておく価値があります。 しかし、Figmaでゼロからデザインを起こすと、テーマの実際の構造との乖離が生まれやすく、「デザインでは良かったけど、テーマエディタでは再現できない」という問題が起こります。そこで、Horizonのセクション&ブロック構造に準拠したFigmaコンポーネントとして設計することで、デザイン段階からテーマの制約を意識した検証ができるようにしてみました。 キットの構成 セクション&ブロック構造への準拠 Shopifyのテーマエディタでは、ページは「セクション」の縦積みで構成され、各セクションの中に「ブロック」と呼ばれる編集可能なパーツが配置されます。このキットでは、Figmaのコンポーネント階層をこの構造にできる限り合わせています。 Templates:トップページ、コレクションページ、商品詳細ページの基本テンプレート Sections:Horizonテーマの各セクション(Featured collection、Image banner、Slideshow など)をパーツとして配置 Components:ブロック単位のUIパーツ。セクション内で入れ替えや追加が可能な単位で分割 つまり、Figma上でセクションを並べ替えたりブロックを差し替えたりする操作が、そのままテーマエディタでの編集操作に対応するイメージです。 ⚠ ブロックのネスト構造について Horizonテーマではブロックが最大8段階までネストされる構造を持っています。このキットではFigmaコンポーネントとしてこのネスト構造を表現していますが、深くネストされたブロックの組み合わせをそのままテーマエディタで再現できるとは限りません。Figmaでのデザインと並行して、テーマエディタ上でも同じ構成が実現可能かを検証しながら進めることを強くおすすめします。Figmaだけで完結せず、必ず実機確認をセットで行ってください。本デザインキットはあくまでも参考用としてお使いいただくことを前提としています。必ずしも本番再現可能なデザイン表現を担保しておりませんのでご注意ください。 ⚠ 複数カラムセクションの構成について 特集商品(Featured collection)や特集コレクション(Collection list)など、複数カラムを設定できるセクションについては、カラム数ごとに別のセクションコンポーネントとして用意しています。Figmaのオートレイアウトで回り込み(Wrap)を有効にすると、画面サイズに応じて意図しないカラム落ちが発生し、設定したカラム数どおりの表示を維持できないためです。カラム数を固定したセクションを選択することで、デザイン意図に沿った正確なレイアウト検証が可能です。 組み合わせによるデザイン検証 セクションやブロックをパターンとして用意しているため、それらを自由に組み合わせてページ構成を検討できます。バリアント切替を使えばフレームを複製する必要もなく、カルーセル表示とグリッド表示の比較なども即座に行えます。 また、既存コンポーネントの組み合わせで新規セクションを構築できるため、ゼロからフレームを作る必要がありません。たとえば: トップページのヒーローを「Image... 続きを読む...
Google Stitchで作成したデザインをShopifyページに一気に実装するskillを試してみました
Google Stitchで作成したデザインをShopifyページに一気に実装するskillを試してみました
GoogleのAIデザインツール「Stitch」が3月に大型アップデートを発表しました。AIネイティブキャンバス、プロジェクト全体を記憶するデザインエージェント、音声操作、即席プロトタイプ、そしてデザインルールをMarkdownで持ち運べるDESIGN.md。Figma株が8%下落するほどのインパクトです。 デザインの思考過程をたどりながら文脈を維持してブラッシュアップしていける「AIネイティブなデザインプラットフォーム」としての進化、キャンバスに置いた素材すべてがAIへの文脈情報になり、指示を重ねるほど精度が上がっていく。多くの方が述べられているように今回のアップデートによる価値はここにあると感じています。 今回はそのうちの実装との接続面、Stitch MCPサーバーとTypeScript SDKの公開、React/Tailwindコードの直接生成への対応といった部分を活用して、Shopifyのテーマ実装まで一気通貫で完了するClaude Codeのskillを作って試してみました。 試してみたこと StitchでデザインしたECサイト用の特集ページを、Shopifyのテーマエディタで編集可能なLiquidテンプレートに変換しページ公開まで、Claude Codeのskillを使って一気通貫で完了させる仕組みです。(すでにFigmaで実装済みなのですが、同じdesign to codeが可能なツールとして同じことができるかどうかを試してみました) 目指したのは、デザインが確定したら一気にShopifyページまで生成する状態です。Stitch上で生成される画像はすべてイメージ画像となっていますが、商品画像やあらかじめ用意しておいたイメージ画像への差し替えなどを含めて、実際に公開可能な状態のページとして一気に実装します。 ※Claude CodeがShopifyのテーマファイルなどを操作できるようにする必要があるため、Claude CodeにAPIを操作させるカスタムアプリなどの実装を前提としています。 ポイントは「情報ソースの判断」 Stitchで生成されたデザインにはダミーの画像や商品データが含まれているため、公開にあたっては本番用のデータへの差し替えが必要です。このとき、assets/にハードコーディングしてしまう方法もありますが、それだとコンテンツを変更するたびにコードを触ることになります。 AIにShopifyテーマのschema設計を正しく理解させ、デザイン上の各要素を適切なリソースタイプに紐づけて実装すれば、テーマエディタからの編集が可能になります。つまり、デザインHTMLの各要素が「何のデータを表示しているか」を正確に判断させることが、Shopifyらしい運用可能なページになるかどうかの分かれ目です。 例えば同じ画像でも: ブランドのイメージ写真 → image_picker(テーマエディタでアップロード差し替え) 商品画像 → product picker から自動取得(商品を変えれば画像も変わる) コレクションのカバー画像 → collection... 続きを読む...
Shopifyテーマの新入力設定「article_list」の特徴と使い分け ― blog.articlesとの違いを整理
Shopifyテーマの新入力設定「article_list」の特徴と使い分け ― blog.articlesとの違いを整理
2026年1月にShopifyテーマの入力設定に新しいタイプ article_list が追加されました。従来の article(単一記事の選択)に対して、複数の記事をまとめて選択できるピッカーが利用できるようになっています。 実際にこの設定を使ってみたところ、従来の blog.articles とは性質が異なる点がいくつかありました。その違いと、ユースケースに応じた使い分けについてまとめます。 article_list 設定の概要 article_list は、テーマのセクションやブロックの {% schema %} 内で使用できる入力設定タイプです。テーマエディタ上に記事ピッカーが表示され、マーチャントが公開済みの記事を複数選択できます。 schemaの記述例 以下はDawnテーマの featured-blogs.liquid に article_list 設定を追加した例です。左側がschema定義、右側がLiquidテンプレートでの参照コードです。 { "type": "article_list", "id": "featured_articles", "label": "Featured articles", "limit":... 続きを読む...
【Horizon】商品カードのバッジ表示をカスタマイズする ― ファイル追跡から設定項目の追加まで
【Horizon】商品カードのバッジ表示をカスタマイズする ― ファイル追跡から設定項目の追加まで
「特集コレクションの商品カードに割引率を表示したい」 セール商品のバッジに「SALE」だけでなく「20% OFF」のように具体的な割引率や割引額を表示し、お客様の目に留まりやすくしたいというご要望をいただくことがあります。残念ながらHorizonには標準ではその機能はありません。 そこで、その機能を実装するための手順を具体的なファイル調査から含めて行ってみます。 Dawn/Riseテーマの場合、特集コレクションのセクションから描画を担当する snippets/card-product.liquid が読み込まれているだけなので、1ステップで変更対象先に到達できます。 一方、Horizonテーマでは修正するファイル自体は数ファイルで済むものの、そのファイルにたどり着くまでに複数のファイルを読み解くことになります。Horizonのブロックアーキテクチャならではのファイル追跡の流れと具体的なカスタマイズ方法について順を追って紹介します。 なお、本記事ではHorizonのカスタマイズ方針で推奨されている custom.* ファイルの新設は敢えて行わず、ベンダーファイルを直接編集する方法を掲載しています。その理由についても詳細に述べていますので、併せてご確認ください。 完成イメージ 変更前後の比較です。SALEバッジのテキストを「セール」以外に割引率や割引額を表示できるように変更します。なお、セール時の価格表示(取り消し線付きの元値と割引後価格の併記)はHorizonの標準機能として既に実装されているため、今回変更するのはバッジ部分のみとなります。 Dawnでの変更対象の探し方 まず比較のために、Dawn/Riseテーマでの対応を確認しておきます。 Dawn/Riseでは、特集コレクションのセクション sections/featured-collection.liquid を開くと、商品カードの描画を担当する snippets/card-product.liquid が直接呼び出されています。このスニペットを開けば、画像、バッジ、商品名、価格――すべてが1ファイルに書かれているので、バッジ部分のLiquidコードを数行書き換える形となります。 // Dawn/Riseの場合 sections/featured-collection.liquid ← セクション └─ snippets/card-product.liquid ← 画像・バッジ・商品名・価格すべてここ セクションからスニペットへ1ステップ。影響範囲もそのファイル内で完結する形となっており、Dawnの設計思想である「1つのスニペットに商品カードの全責任を持たせる」アプローチが、カスタマイズの容易さに直結しています。... 続きを読む...
Prestige開発者のHorizonテーマブロック対応方針から考える、テーマアーキテクチャの選択
Prestige開発者のHorizonテーマブロック対応方針から考える、テーマアーキテクチャの選択
Prestige開発者がテーマブロックアーキテクチャへの対応方針をコメント Shopifyのテーマ「Horizon」がリリースされ、テーマブロックの多重ネスト構造やAIセクション生成など、テーマのアーキテクチャがかなり変わりました。 こうした中、有料テーマ「Prestige」の開発元であるMaestroooの開発者の方が、Redditのr/shopifyスレッドで自社テーマの今後の対応方針についてコメントされていました。(Prestigeは多機能かつ高性能で様々なユースケースに対応しやすいテーマなので、私自身も最もカスタマイズ実績があり数多くのマーチャント様に導入いただいています) テーマアーキテクチャの今後を考える上で非常に参考になる内容だったので、個人的な見解も交えながらご紹介したいと思います。 開発者の方のコメントの要点 コメントの内容をざっくりまとめると、以下の3点です。 現時点では、Horizonのようなテーマブロックアーキテクチャへのアップグレードは行わない方針。ShopifyはDawnをアップグレードせず新テーマ(Horizon)を作ったが、有料テーマ側は既存マーチャントのデータ互換性を維持する必要がある。全セクションをテーマブロックに移行すると既存ストアに影響が出るリスクがあり、Shopifyがマイグレーションツールなどを整備するまでは慎重に対応するとのこと。 テーマの方向性としては、柔軟性の拡大よりもシンプルさを重視。Horizonの柔軟性は大きな進歩だが、マーチャントがデザインを整えるための労力も増える。Prestigeとしては、視覚的な一貫性と優れたデザインを手軽に実現できることに価値を置き、その方針を継続する。 AI生成機能についても慎重な姿勢。現時点では生成されるコードの品質に課題があり、テーマ全体との統一感を保つのが難しい。具体的なユースケースがまだ明確ではない中で、不足している機能があればテーマ側でしっかりしたセクションを提供する方がよいという考え。 Horizonの自由度がもたらすメリットと課題 開発者の方の考え方は一つの合理的なアプローチとしてとてもよく理解できます。テーマ開発者の判断として十分に納得できるものだと思います。 Horizonが導入したテーマブロックの多重ネスト構造は、レイアウトの表現力という点では確かに大きな進歩です。セクションの中にブロックを入れ子にして、さらにその中にブロックを配置できる。理論上はかなり自由にレイアウトが組めます。 ただ、この自由度はそのままマーチャントに高度なレイアウト調整スキルを要求することにもなると感じています。 FlexboxやGridの概念に不慣れな場合、ブロックを並べ替えても意図通りにレイアウトできない、という状況は普通に起こり得ます。テーマカスタマイザーのUIがいくら綺麗でも、レイアウトの手法を把握していないと使いこなせないことも多いかと思います。 レイアウトの自由度と売上の関係 表現力が上がること自体は良いことだと思います。ただ、そもそもストアの「構造」ってそんなに頻繁にいじるものではないですよね。トップページのメイン画像や商品一覧、特集コレクション、FAQ——こういった基本構成は一度決めたらほぼ固定です。その「めったに触らない構造」に対して高度なアレンジ機能が用意されていたとして、それが売上アップに貢献するかというと、それはまた別の話かなと思います。 実際のところ、マーチャント様の時間とリソースは限られています。レイアウトをあれこれいじるよりも、商品写真の質を上げたり、商品説明文を改善したり、カート導線を見直したりする方が、よほど売上には直結するはずです。 ですので、テーマ側で一貫性のあるデザインが担保されていれば、マーチャント様が自由なレイアウト作成に時間を費やすよりも、商品そのものの魅力をアップするための本質的な作業に集中できるとも言えます。 「設定項目でカスタマイズする」という従来のやり方 開発者の方が示している方向性は、あらかじめ設計された一貫性のあるセクションを提供して、その「設定項目」を通じてカスタマイズしてもらう、というものです。 Horizonの「何でも自由に組み替えられる」とは対照的ですが、実際のところ実用面ではこちらの方が理にかなっているケースも多いです。(個人的にも従来のテーマの方が、実はセクション単位で処理が閉じているので画面デザインに即してカスタマイズしやすいと感じています。Horizonの場合、コードカスタマイズせずにデザインを意図通りに仕上げるためのブロックパズルを組み立てる作業が必要になりますので。) Horizon型とPrestige型の比較 観点 自由構造(Horizon型) 従来構造(Prestige型) デザインの一貫性 マーチャントのスキル次第 テーマ側で担保 操作の難易度 高い(レイアウト概念の理解が必要)... 続きを読む...
Horizonテーマのセクション&ブロック構造を俯瞰できるツール
Horizonテーマのセクション&ブロック構造を俯瞰できるツール
Horizonは、Shopifyが推進するテーマブロック(Theme Blocks)アーキテクチャが本格的に採用されたテーマです。従来はセクション単位で完結していた構成が、Horizonではブロック単位に細分化されています。 ただ、柔軟なレイアウト設計が可能になった一方で、ひとつのセクションの挙動を理解するために複数のブロックファイル・スニペット・アセットを横断して読み解く必要があり、カスタマイズの難易度は従来テーマと比べて格段に上がったと感じています。 そこで、自分自身がカスタマイズする際に「どのファイルが何を担当しているのか」「この設定はどのブロックに影響するのか」を毎回コードを追って確認するのが辛くなってしまったので、セクションとブロックの関連ファイルを俯瞰して確認できるツールを(あくまでも個人用としてですが)作成してみました。 ツールはこちらでご確認いただけます:https://store-dojo.com/pages/horizon_section_inventory 主な機能 1. セクション / ブロックのカード一覧表示 すべてのセクション・ブロックがカード形式で一覧表示されます。各カードには以下の情報がまとまっています。 サムネイル ― セクションの実際の表示をキャプチャしたプレビュー画像 カテゴリラベル ― 「コレクション」「バナー」などの用途別カテゴリ セクション名 ― テーマエディタに表示される日本語名 ファイル名 ― 対応するLiquidファイル名 プリセット一覧 ― そのセクションで利用可能なレイアウトバリエーション 解説文 ― セクションの役割や機能の説明 メタ情報バッジ... 続きを読む...
Horizon全39セクションを解析して整理した呼び出しパターン3分類
Horizon全39セクションを解析して整理した呼び出しパターン3分類
Horizonで何が変わったのか Shopifyの Summer '25 Edition で登場した新テーマ「Horizon」ですが、見た目だけでなく、テーマの内部構造——つまりアーキテクチャそのものが、従来のテーマとはかなり違っています。 その中心にあるのがテーマブロック(Theme Blocks)です。従来のテーマ(DawnやRiseなど)では、ブロックはセクションの中にローカル定義されていて、そのセクションの外には持ち出せませんでした。レイアウトもフラットな1階層構造で、入れ子にはできません。 テーマブロックではこのあたりが大きく変わっています。ブロックは/blocksフォルダに独立したLiquidファイルとして置かれ、セクションをまたいで使い回せます。さらに、ブロックの中にブロックを入れるネスト構造が最大8階層まで可能(セクションレベルを除く)になっていて、テーマエディタ上でかなり自由にレイアウトを組めるようになりました(公式ドキュメント: Theme blocks)。 セクションブロックとテーマブロックの違い セクションブロック(従来): セクション内にローカル定義。そのセクションの中でしか使えず、ネスト不可 テーマブロック(Horizon): /blocksフォルダに独立ファイルとして配置。セクション横断で再利用可能、最大8階層ネスト対応(セクションレベル除く) Shopifyのエディションカンファレンスでは、この設計思想を「anything anywhere」——あらゆるコンポーネントをどこにでも配置できる——と表現していました。実際にHorizonのテーマエディタを触ってみると、従来テーマとは自由度がまったく違うことがわかります。まだこのアーキテクチャを採用しているテーマはごく一部ですが、Shopifyがこの方向に力を入れていることは伝わってきます。 ただ、この自由度の裏側には、コード構造の複雑さがあります。Horizonテーマにはv3.3.1時点で39のセクションと94のブロックが存在し、ブロックの呼び出し方も複数のパターンが混在しています。カスタマイズしようとしたとき、「このブロックはどうやって呼ばれているのか」がまず気になるところでした。 本記事では、Horizonの全セクションコードと公式ドキュメントをもとに、ブロックの呼び出しパターンを自分なりに整理してみました。同じようにHorizonのコードを追っている方の参考になればうれしいです。(また、もしここが違う、という点などありましたらご指摘いただけるとありがたいです) 本記事の分類について 本記事で使用している「動的ブロック」「静的ブロック」「セクションブロック(従来方式)」の3分類は、Shopify公式ドキュメントの用語ではなく、筆者がHorizonの全セクションコードを読み解く中で整理した個人的な分類です。公式ドキュメントでは theme blocks / section blocks / app blocks... 続きを読む...
Horizon v3.4.0アップデート解説 ― アカウント管理の刷新と単一バリアント表示の改善
Horizon v3.4.0アップデート解説 ― アカウント管理の刷新と単一バリアント表示の改善
2月18日、Shopify公式テーマ「Horizon」のv3.4.0がリリースされました。 前回の記事「Shopify新テーマ『Horizon』を安全にカスタマイズする方法」では、テーマアップデートに備えた仕組みづくり ― upstream/horizonブランチによるバージョン管理 ― について解説しました。 今回は、その仕組みを実際に扱う実践編です。v3.4.0で何が変わったのかを解説しつつ、アップデートを取り込む際の判断材料をお伝えします。 v3.4.0の変更サマリー 94ファイルが変更され、差分は +1,828行 / -1,364行。数字だけ見ると大きな変更に見えますが、その多くはロケールファイル(翻訳)の更新や、ヘッダーの内部的なCSS最適化です。 今回のアップデートでストア運営者が気にすべき変更点は、大きく分けて下記の2つかなと思われます。 変更 影響範囲 設定変更 アカウント管理方式の刷新 アカウントのログイン・サインインUI全体 不要(自動で切り替わる) 単一バリアント商品の表示変更 バリアントが1つしかない商品のバリアントピッカー 不要(自動で切り替わる) どちらも設定変更なしで自動的に適用されます。つまり、アップデートするだけで恩恵を受けられます。 変更点① ― アカウント管理方式の刷新 これがv3.4.0最大の変更です。 何が変わったのか v3.3.1まで、ヘッダーのアカウントボタンをクリックすると、テーマ側で独自に実装されたポップオーバー(デスクトップ)やドロワー(モバイル)が表示されていました。「Sign in... 続きを読む...
Shopify新テーマ「Horizon」を安全にカスタマイズする方法
Shopify新テーマ「Horizon」を安全にカスタマイズする方法
⚠️ 訂正(2026年5月):sections/ のファイル名にドットは使えない Shopify公式ガイドでは sections/custom.main-product.liquid のようにドット区切りのファイル名を推奨していますが、現行の Shopify CLI(v3.94.3 時点)では sections/ フォルダのみ、ドットを含むファイル名が「illegal characters」として拒否され、実際にファイルが強制削除されます。 snippets/ や blocks/ はドット名称を受け入れるため影響はありません。本記事のフェーズ3に記載しているセクションファイル名については、custom.(ドット)ではなく custom-(ハイフン)に読み替えてください。 Shopify公式のGrowth Servicesで昨年の11月に公開されたHorizonテーマの安全なカスタマイズガイドでは、アップグレード可能性を維持しながらカスタマイズを行うための体系的なアプローチが紹介されています。 ここでは、そのガイドの要点を整理しつつ、実務でストアテーマを管理・運営する立場としての観点から「どこまでやるべきか」「何を優先すべきか」について個人的な見解を交えながら解説してみたいと思います。 根本にある考え方:「ベンダーファイルを触らない」 公式ガイドが一貫して主張しているのは、テーマのオリジナルファイル(ベンダーファイル)を直接編集しないという原則です。この方針を守ることで、自分のカスタムファイルが影響を受けることなく、最新テーマの機能を反映することができます。 6段階のカスタマイズフェーズ 公式ガイドでは、カスタマイズを6つのフェーズに分けて段階的に進めることを推奨しています。 フェーズ0:準備と基準設定 カスタマイズを始める前に、以下の準備を行います。 GitHubとテーマを接続し、upstream/horizon(オリジナル追跡用)とmain(カスタマイズ用)のブランチを構築 Theme Checkの設定 変更ログ(docs/changes.md)の作成... 続きを読む...