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) テーマ全体の配色・カスタマイザーの色設定 要確認(カスタムCSS利用時は表示崩れに注意)
② Disclosures(FAQ/アコーディオン)ブロック追加 任意のセクションに折りたたみコンテンツを設置可能 不要(使いたい時に追加)
③ Shopify Inbox チャットのテーマ統合 チャット接客のドロワー表示 不要(Inbox導入時に自動)
④ カート/ドロワーの再設計 カートドロワー・各種ドロワーのUX 不要(自動で適用)
⑤ 計測(アナリティクス)の強化 ページビュー・要素表示イベント 不要(自動で適用)

①だけはメジャーアップらしい構造変更で、ストアによっては確認が必要です。順に解説します。

変更点① ― カラーシステムの全面刷新(v4最大の目玉)

これが v4系で最も大きな変更です(カラーパレット自体は Horizon v4.0.0 で導入されました)。

何が変わったのか

v3.5.1まで(旧:カラースキーム方式)
6つの固定カラースキーム(scheme-1〜6)があり、それぞれに対して背景色・文字色・ボタン色・ボタンのホバー色・バリアント色・入力欄の色…と、約50項目の色を1つずつ手動で指定する方式でした。ホバー時の色やコントラストも、原則すべて手で決める必要がありました。

v4.1.1から(新:カラーパレット方式)
「カラーパレット(color_palette)」を1つ定義するだけで、各UI要素の色はそのパレットを参照して自動的に導出される方式に変わりました。Shopify公式も「マーチャントが編集できる1つの色のグリッドで、変更がテーマ全体に反映される」と説明しており、これが新方式の本質です。

カスタマイザーの「Colors(色)」セクションも統一され、各要素の色はパレットへの参照として設定されます。文字色にはコントラスト不足を知らせる警告も追加され、アクセシビリティへの配慮が組み込まれました。

技術的な変更内容

設定データ(config/settings_data.json)の中身が、固定値から Liquid参照 へと置き換わっています。

v3.5.1(固定値を直書き):

"scheme-1": {
  "settings": {
    "background": "#ffffff",
    "primary_button_background": "#000000",
    "primary_button_text": "#ffffff"
  }
}

v4.1.1(パレットを参照):

"color_palette": {
  "background": "#ffffff",
  "foreground": "#000000",
  "color1": "#333333",
  "color3": "#dfdfdf"
},
"palette_primary_button_background": "{{ settings.color_palette.foreground }}",
"palette_primary_button_text": "{{ settings.color_palette.background }}"

色の解決ロジックは、新設された snippets/color-palette.liquid(約237行)が担います。注目すべきは「スマートコントラスト」の仕組みで、パレット内の最も明るい色・最も暗い色を color_brightness で自動判定し、ホバー時の文字色などを自動で選びます。

{% comment %} パレットの最明色・最暗色を一度だけ算出してコントラストに使う {% endcomment %}
for palette_color in settings.color_palette
  if palette_color != blank and palette_color.alpha == 1
    assign b = palette_color | color_brightness
    ...
  endif
endfor

ホバー色も snippets/util-palette-hover-shift.liquidパレット色から自動生成されます。つまり、これまで手作業だった「ホバー色・コントラストの調整」がテーマ側に肩代わりされたわけです。

旧方式の実装ファイル snippets/color-schemes.liquid削除され、color-palette.liquid 一式に置き換わりました。

カスタマイズへの影響(要確認)

ここが今回のアップデートで最も注意すべき点です。

  • テーマカスタマイザーの既存の色設定は、Shopify側で新方式へ移行されます。
  • カスタムCSSやセクションで、旧カラースキームの変数(例:--color-foreground など)を直接参照している場合、表示が崩れる可能性があります。旧スキーム由来のCSS変数名が変わっている/なくなっているためです。
  • 逆に、デフォルトのカラー設定のみを使っているストアであれば、パレットへの移行は自動で行われ、見た目の大きな破綻は起きにくいはずです。

対応の目安:カスタムCSSで色を上書きしているストアは、アップデート前に開発テーマ(shopify theme dev)で配色を必ず確認してください。

変更点② ― Disclosures(FAQ/アコーディオン)ブロックの追加

blocks/disclosures.liquid(約611行)という新しいコンテンツブロックが追加されました。

クリックで開閉する「折りたたみコンテンツ(アコーディオン)」を、商品ページや一般ページなど任意のセクションに設置できます。設定項目として 見出し(heading)・見出しの大きさ(heading_preset)・開閉アイコン(caret等)・デフォルトで開いた状態にするか(open_by_default) を持ちます。

商品の「素材・お手入れ方法」や「よくある質問(FAQ)」を、アプリを使わずテーマ標準でスッキリ表示できる、実用性の高い追加です。

変更点③ ― Shopify Inbox チャットのテーマ統合(chat-drawer)

snippets/chat-drawer.liquid が新設され、Shopify公式のチャット要素 <shopify-chat>テーマのドロワー基盤でホストするようになりました。

ポイントは「マークアップは常に存在し、Shopify Inbox アプリが導入されているときだけチャットが起動する」という設計です。Inbox未導入なら要素は不活性のまま邪魔をしません。チャット接客のUXがテーマの世界観に統合された形です。

変更点④ ― カート/ドロワーの再設計

カートドロワーが セクション化sections/cart-drawer-section.liquid / snippets/cart-drawer.liquid の新設)され、サイドから出てくる各種ドロワーは汎用コンポーネント theme-drawerassets/theme-drawer.js)に統一されました。

カート・メニュー・チャットといった「引き出し系UI」の実装が一本化され、挙動の一貫性とカスタマイズ性が向上しています。基本的に設定変更なしで適用されます。

その他の変更

変更 概要
計測(アナリティクス)の強化 page-view-event.js / view-event-elements.js / standard-events 群を新設。Web Pixels・標準イベント計測が拡充され、コンバージョン計測の精度向上に寄与
ブログ記事のブロック化 記事タイトルなどがブロック化(_blog-post-title 等)。ブログ編集の自由度が向上
商品まわりのスニペット刷新 product-form.js / buy-buttons.liquid / product-price などが新方式(カラーパレット参照)に追従
削除ファイル snippets/color-schemes.liquid(旧カラー実装)/assets/product-title-truncation.js(商品タイトル省略JS)

アップデート手順

安全カスタマイズ記事で構築した upstream/horizon ブランチ運用を使っている場合の流れです(タグは「取り込み元バージョン」と「自社版」の2系統で管理)。

1. upstream/horizon ブランチを更新

git checkout upstream/horizon
# Shopify から v4.1.1 のテーマを取得し、ファイルを上書き後:
git add -A
git commit -m "Update upstream Horizon theme to v4.1.1"
git tag upstream/v4.1.1   # 取り込んだ upstream バージョン
git tag horizon-v4.1.1    # 自社リリース版
git push origin upstream/horizon upstream/v4.1.1 horizon-v4.1.1

2. 本番テーマへ反映(GitHub連携 / PR経由)

カスタムファイル(custom.css 等)でカスタマイズを分離していれば、コンフリクトはほとんど発生しません。コンフリクトが出た場合はテーマ本体を直接編集していた箇所なので、v4.1.1側の変更を採用し、カスタマイズはカスタムファイルへ移行することをお勧めします。

3. 動作確認(特に配色)

今回はカラーシステムが刷新されているため、開発テーマで配色(特にボタン・バリアント・カート・ポップオーバー)とカスタムCSSの効き具合を必ず確認してください。

つまずきやすいポイント ―「配色を定義する必要があります」エラー

GitHub連携でマージした場合、テーマエディタで次のバナーが出てプレビューできなくなることがあります。

⚠️ 変更をプレビューするには、settings_data ファイルと settings_schema ファイルで配色を定義する必要があります。

原因は設定値ファイル(config/settings_data.json)側にカラーパレットの定義が揃っていないことです。v4.1.1 のテーマ本体(settings_schema.json)は新しいカラーパレットを前提にしていますが、マージ時に既存の設定値を保持すると、color_palette が背景・前景の2色だけになり、各パーツの色を割り当てる palette_*page_background_color / page_text_color が未定義のまま取り残されます。この状態はテーマエディタで色を触っても手作業では埋めきれません。

対処は、settings_data.jsoncurrent に v4.1.1 が想定する配色キー一式を追加すること。palette_* は基本的にパレットを参照させ、color_palette には color1〜 まで色数を揃えます(背景・前景は現行の色をそのまま維持すればトーンは変わりません)。

// config/settings_data.json の "current" に追加
"page_text_color": "{{ settings.color_palette.foreground }}",
"page_background_color": "{{ settings.color_palette.background }}",
"palette_primary_button_background": "{{ settings.color_palette.foreground }}",
"palette_primary_button_text": "{{ settings.color_palette.background }}",
// … 入力欄・バリエーション等の palette_* を同様に定義 …
"color_palette": {
  "background": "#FDFDFD",
  "foreground": "#000000",
  "color1": "#333333",
  "color3": "#dfdfdf",
  "color4": "#f5f5f5"
}

加えて、バッジ・ドロワー・ポップオーバー・クイック追加の色キーbadge_sale_background_color / drawer_text_color など)も v4.1.1 では必要です。逆に、旧方式の color_schemes ブロックや 〜_color_scheme が残っていると不整合になるため、削除してかまいません(セクション側がスキームを参照していないことを確認のうえで)。

💡 個別に埋めるより、取り込み元である v4.1.1 標準テーマの settings_data.json の配色キー一式をそのまま移植するのが確実です。新規に v4.1.1 テーマを入れた場合は最初から定義済みのため、このエラーは「既存設定を保ったまま移行したとき」に限って起こります。

それでも消えないとき ― 独自セクション/ブロックの「カラースキーム設定」を疑う

設定値を揃えてもバナーが残る場合、独自に追加したセクションやブロックが、旧方式の「カラースキーム」設定をスキーマに残していることが原因です。v4.1.1 はセクション/ブロックからカラースキームの仕組みを完全に廃止したため、スキーム機構が無いのに "type": "color_scheme" の設定だけが残っていると、配色の検証に恒常的に引っかかります(テンプレートに残るスキーム値のほうは、未知の設定として無害に無視されます)。

📌 チェック方法:sections/blocks/ の各 .liquid"type": "color_scheme" で検索。1件でも残っていればそれが原因です。

対処は、その color_scheme 設定を {% schema %} から削除し、Liquid 側で色を当てていた color-{{ ... }} クラスも外すこと。多くの場合 CSS は既に var(--color-foreground) / var(--color-background) を参照しているので、クラスを外せばページのカラーパレットをそのまま継承します。個別スキームでの色上書きはできなくなりますが、これが v4.1.1 の設計どおりの挙動です。

解消手順のまとめ(チェックリスト)

既存設定を保ったまま GitHub 連携でメジャーアップした場合、上から順に確認・修正すると確実です。settings_data.json の値は、テーマエディタの「色」からは埋めきれない部分があるため、ファイルを直接編集するのが早道です。

  1. カラーパレット本体を定義settings_data.jsoncurrent.color_palettebackground / foregroundcolor1〜 まで色数を揃える。
  2. 要素色マッピングを追加page_text_color / page_background_color と、ボタン・入力欄・バリエーション・バッジ・ドロワー・ポップオーバー等の palette_* / *_color キーを、v4.1.1 標準テーマの settings_data.json からそのまま移植。
  3. 旧スキームの残骸を削除color_schemes ブロックと 〜_color_scheme キーを settings_data から除去。
  4. 独自テーマファイルの型宣言を除去(多くの場合これが最後の犯人) ― 下記で検索し、ヒットした .liquid{% schema %} から color_scheme 型設定を削除し、対応する color-{{ ... }} クラス出力も外す。
# 手順4: 型宣言が残る独自ファイルを洗い出す
grep -rn '"type": "color_scheme"' sections/ blocks/ snippets/
# → 0件になれば「配色を定義する必要があります」バナーは消える

✅ ポイントは、この問題が「1つの原因」ではなく複数層の積み重ねだということ。settings_data を直しても消えないときは、必ず手順4の独自ファイルの型宣言まで確認してください。GitHub 連携テーマなら修正を push すれば反映され、テーマ側のバナーが消えます(反映されない場合はエディタを再読み込み)。

まとめ

v4.1.1 は アップデート推奨 です。ただし v3.4.0 のような「設定不要で全自動」とは少し性格が異なります。

  • カラーシステムの刷新は、配色管理を「1色ずつ塗る」から「パレットを決めれば自動で調和する」へ進化させる、前向きで大きな改善です。
  • 一方で、カスタムCSSで色を上書きしているストアは、移行前に配色確認が必要です。これが今回唯一の注意点と言えます。
  • Disclosures(FAQ)ブロックやチャット統合など、設定不要で恩恵を受けられる追加も揃っています。

カスタマイズの少ないストアはそのまま、色を作り込んでいるストアは「開発テーマで一度確認してから本番反映」がおすすめです。ファイル構成がバージョンごとに変わりうるテーマだからこそ、「どこを触ったか」を常に把握できるGit管理(upstream/horizon ブランチでのオリジナル追跡)が、今回のようなメジャーアップでこそ効いてきます。

Back to blog