Shopifyテーマカスタマイズの実務手順｜既存テーマを壊さず改修する方法

「shopify テーマ カスタマイズ」で調べる人の多くは、単に色やフォントを変えたいだけではありません。

運用中の商品ページを壊さずに改修したい。レビューアプリや予約販売アプリを入れたら表示が崩れた。商品ごとのサイズ表や注意事項を、商品説明HTMLへ直書きし続けている。キャンペーン用にCSSやJavaScriptを足したが、どのファイルを戻せばよいか分からない。テーマ更新後に、以前のカスタマイズが消えないか不安。こうした実務上の悩みがあります。

Shopify公式ヘルプのCustomizing themesでは、テーマエディタでプレビュー、テーマ設定の変更、コンテンツの追加・削除・並び替えができる一方、カスタマイズ前にはテーマを複製してバックアップを作ることが推奨されています。変更を捨ててやり直せる状態を先に作る、という考え方です。

また、Sections and blocksでは、sectionsとblocksを使ってコード編集なしにコンテンツの配置や設定を調整でき、対応するsection/blockではメタフィールドやメタオブジェクトなどのdynamic sourcesも接続できると説明されています。さらにapp blocksは、インストール済みアプリが追加する表示領域を、テーマ内の特定位置へ配置するための仕組みとして扱われます。

一方、Shopify公式ブログのサイトデザインをカスタマイズする5つの方法は、テーマ設定、テンプレート、アプリ、アプリ埋め込みを使う入門寄りの説明です。これから社の記事は、テーマ複製によるバックアップやコード編集手順まで触れています。Tsun社の記事は、テーマエディタ、Liquid/CSS/JSのコード編集、アプリ活用の具体例を整理しています。

これらは初期理解には役立ちます。ただし運用中ストアでは、「どのボタンを押すか」よりも「どこで直すと、次の改修・次のアプリ追加・次のテーマ更新でも壊れにくいか」が重要です。

Shopifyテーマ開発の実務設計では、Online Store 2.0、Liquid、メタフィールド、Git運用まで含めたテーマ開発全体を整理しました。この記事ではさらに実務寄りに、既存テーマを対象としたカスタマイズの判断、作業前チェック、QA、保守ルールに絞って整理します。

Shopifyテーマカスタマイズで最初に決めるべきなのは、コードを触るかどうかではなく、変更を「管理画面」「section/block」「データ」「Liquid」「CSS/JS」「app block」のどこに置くかです。

先に結論：本番テーマを直接直さない

Shopifyテーマカスタマイズは、作業そのものよりも作業前の切り分けで品質が決まります。既存テーマを壊さず改修する基本は、次の順番です。

順番	やること	目的
1	現行テーマを複製する	失敗時に戻せるバックアップを作る
2	対象ページと現象を棚卸しする	トップ、商品、コレクション、カート、モバイルの影響範囲を見落とさない
3	実装先を決める	管理画面、section/block、メタフィールド、Liquid、CSS/JS、app blockを分ける
4	差分を残す	どのファイル、どの設定、どのアプリ、どのメタフィールドを変えたか追えるようにする
5	previewで確認する	本番公開前に実ストアに近い商品・データで見る
6	公開後に回帰確認する	商品ページ、カート、アプリ表示、速度、計測を再確認する
7	保守ルールへ反映する	次回以降の変更で同じ判断を再利用できるようにする

テーマエディタで変更するだけでも、sectionの並び、blockの追加、app blockの配置、theme settingsの値は本番表示に影響します。コードを触らない変更でも、差分メモと確認条件は必要です。

逆に、すべてをコードで直す必要もありません。Online Store 2.0では、JSONテンプレート、sections、blocks、dynamic sources、app blocksを使って、管理画面側で保守できる変更が増えています。公式のTheme architectureでも、テーマは標準ディレクトリ構造とLiquid、設定、assetsで構成され、マーチャントがテーマエディタで調整できるconfigも含むものとして整理されています。

改修方針：管理画面・section/block・Liquid・CSS/JS・アプリの境界

最初に、要望を実装先で分けます。ここを曖昧にすると、「商品説明HTMLに表を直書き」「CSSで構造問題を隠す」「アプリ用scriptをテーマに貼りっぱなし」といった保守しにくい状態になります。

変更したいこと	第一候補	触る場所	避けたい実装
色、フォント、余白、ボタン角丸などの全体調整	テーマ設定	Theme settings、section settings	各sectionのCSSへ個別に上書きし続ける
トップや商品ページの構成を変える	section/block	テーマエディタ、JSON template、sections	本番Liquidに固定HTMLを増やす
商品ごとに注意事項やサイズ表を出す	メタフィールド、メタオブジェクト、dynamic sources	商品管理、custom data、対応section	商品説明HTMLやLiquidへ商品別文言を直書き
商品ページの表示ロジックを変える	Liquid	sections/main-product.liquid、snippets	CSSだけで表示/非表示を制御する
見た目だけを調整する	CSS	assets、section固有CSS	JavaScriptでレイアウトを無理に作る
タブ、開閉、カート数量変更などの挙動を足す	JavaScript	assets、section単位のJS	全ページで不要なJSを読み込む
レビュー、診断、予約、チャットを置く	app block / app embed	テーマエディタ、対応section	アプリ指定のsnippet/scriptをテーマへ直貼り
外部在庫や会員データを反映する	カスタムアプリ/API	Admin API、Storefront API、app proxyなど	Liquidだけで外部連携を抱える

判断基準は「EC担当者が安全に更新できるか」「次回テーマ更新時に差分を説明できるか」「商品データと表示ロジックが混ざっていないか」です。

たとえば「商品ごとに成分表を表示したい」なら、成分表の値は商品メタフィールドやメタオブジェクトに置き、テーマは表示するだけにします。「レビューアプリを購入ボタン下へ置きたい」なら、app blockを受け入れるsectionに配置できるかを確認します。「外部WMSの納期を日次で反映したい」なら、テーマではなくAPI連携や商品メタフィールド同期の設計です。

作業前チェック：テーマ複製、棚卸し、差分記録

Shopifyヘルプが示す通り、テーマカスタマイズ前にはテーマ複製によるバックアップを作ります。これは初心者向けの注意ではなく、運用中ストアでは必須の作業です。

チェック項目	確認すること	記録する場所
テーマ複製	現行公開テーマを複製したか。複製テーマ名に日付と目的を入れたか	改修台帳
現行テーマID	どのテーマを元にしたか	改修台帳、チケット
対象URL	トップ、商品、コレクション、固定ページ、カートなど	URL一覧
対象商品	通常商品、在庫切れ、バリエーション多数、メタフィールド未入力商品	QAリスト
既存アプリ	レビュー、予約、ポイント、チャット、計測、ページビルダー	アプリ棚卸し
既存カスタマイズ	テーマエディタ設定、コード編集、外部ベンダー修正	差分メモ
追加データ	メタフィールド、メタオブジェクト、商品タグ、テンプレート割当	データ定義
戻し方	旧テーマへ戻すか、設定値を戻すか、コード差分を戻すか	公開手順

コード編集を行う場合は、GitやShopify CLI/GitHub連携で差分を追える状態が望ましいです。ただし、テーマエディタで変更したsection設定やapp block配置は、コード差分だけでは説明しにくい場合があります。だからこそ、変更ファイルだけでなく「管理画面で何を変えたか」も記録します。

小さな文言変更でも、対象ページ、変更箇所、確認商品、戻し方を残します。特にキャンペーン用のバナー、送料無料表示、期間限定の注意文は、撤去日と撤去方法まで決めておかないと、古い訴求がテーマ内に残ります。

Online Store 2.0のsections/blocksで対応する変更

Shopify Dev DocsのSectionsでは、sectionsはマーチャントがカスタマイズできる再利用可能なコンテンツモジュールであり、blocksを含めることでsection内のコンテンツを追加・削除・並び替えられると説明されています。

また、Building with sections and blocksでは、Online Store 2.0テーマはJSON templatesとsection groupsを使い、sections/blocks、app blocks、metafieldsを組み合わせて拡張できる前提で設計されています。仕様や上限は更新される可能性があるため、実装時は対象テーマと公式ドキュメントで確認します。

要件	section/blockで対応しやすい	コード・データ設計も必要
トップページのバナーを増やす	既存sectionを追加、並び替え	固定HTMLを増やす必要は薄い
商品ページのFAQを追加する	FAQ section/block	商品別FAQならメタフィールド/メタオブジェクトも検討
配送案内を商品ページに出す	rich text blockやcustom liquid block	商品条件で変わるならメタフィールド
レビューアプリを商品情報下へ移動する	app block対応section	対象sectionがapp blocksを受け入れるか確認
サイズ表を商品ごとに出す	dynamic sources対応block	共通サイズ表ならメタオブジェクト
購入ボタン周辺の構成を変える	main product sectionのblocks	CVRに関わるためQAを広げる
カート内の注意文を条件表示する	section設定だけでは不足しがち	Liquidでcart/itemsを見る、必要ならアプリ/API

section/block設計では、自由度を増やしすぎないことも重要です。購入ボタン周辺に任意HTMLを入れられるようにすると、短期的には便利ですが、表示崩れやコンバージョン低下の原因になります。EC担当者が触るべき項目は設定化し、崩してはいけない構造はテーマ側で守ります。

メタフィールド・メタオブジェクトで商品情報を構造化する

テーマカスタマイズでよくある失敗は、商品ごとに違う情報を商品説明HTMLやLiquidへ直書きすることです。見た目はすぐ整いますが、更新漏れ、表記ゆれ、テーマ移行時の破綻が残ります。

Shopifyメタフィールド設計ガイドでも整理した通り、商品にぶら下がる属性はメタフィールド、複数商品や複数ページで再利用する構造データはメタオブジェクトを検討します。dynamic sourcesに対応するsection/blockであれば、コードを直接触らずにテーマエディタからメタフィールドやメタオブジェクトを接続できる場合があります。

情報	置き場所の候補	テーマ側の役割	注意点
素材、原産国、成分	商品メタフィールド	仕様表として空欄時は行ごと隠す	商品説明HTMLに混ぜない
サイズ表	商品メタフィールド、メタオブジェクト	表、画像、モーダルなどで表示	共通表なら再利用データにする
商品別FAQ	商品メタフィールド、FAQメタオブジェクト	Q&A sectionで表示	block直書きだと商品追加時に漏れる
ブランド説明	メタオブジェクト	商品や固定ページから参照	同じ文章の複製を避ける
配送温度帯、出荷注意	商品/バリエーションメタフィールド	商品ページ・カートで注意表示	カートでも必要ならLiquid設計を確認
社内管理ID、原価、仕入先	原則ストアフロント非公開	テーマに出さない	Storefront公開範囲を分ける

Liquidで表示する場合も、値を直接書くのではなく、データを読んで空欄時に隠します。コード断片はこれくらいの小ささで十分です。

{% assign material = product.metafields.spec.material.value %}
{% if material != blank %}
  <p class="product-spec__item">素材：{{ material | escape }}</p>
{% endif %}

重要なのは、この1行をどこに書くかではありません。spec.materialという項目の意味、入力責任、未入力時の扱い、テーマでの表示場所、将来のCSV/API更新まで決めることです。

Liquid/CSS/JavaScriptを触るべきケース

テーマエディタやdynamic sourcesで足りない場合は、Liquid、CSS、JavaScriptを触ります。ただし、それぞれの責務を混ぜない方がよいです。

領域	触るべきケース	避けるべきケース	レビュー観点
Liquid	商品・コレクション・カート・メタフィールドを使ってHTMLを組み立てる	商品IDやhandle直書きの例外を増やす	空欄、在庫切れ、長文、バリエーション多数
CSS	余白、表示幅、レスポンシブ、見た目の調整	CSSで本来出すべきでない情報を隠す	PC/スマホ、タップ領域、折り返し
JavaScript	開閉、タブ、数量変更、軽いUI補助	外部業務データ取得や購入制御を抱える	全ページ読み込み、エラー時表示、重複イベント
Snippets	商品カード、価格、バッジ、仕様行を再利用する	1箇所だけの特殊HTMLを無理に共通化する	呼び出し元依存、引数、命名
JSON templates	ページごとのsection構成を持つ	商品ごとの差分を大量テンプレートで管理する	テンプレート割当、戻し方

Shopify Liquid入門でも扱った通り、Liquidは表示の組み立てに向きます。外部DBのリアルタイム照会、管理データ更新、失敗時再実行、監査ログが必要な処理は、テーマではなくアプリ/API側へ分けるべきです。ヘッドレスや外部フロントに進む場合は、Shopify Storefront APIで作るヘッドレスEC設計のように、Storefront APIとテーマの責務も分けます。

CSS/JSの追加では、ページ単位・section単位で読み込み範囲を意識します。商品ページだけに必要なタブUIを全ページで読み込む、レビューアプリのscriptと独自JSが同じDOMを取り合う、計測タグが二重発火する、といった問題は運用中ストアで起きやすいです。

app blocksの競合、速度低下、アクセシビリティを確認する

Online Store 2.0では、対応するsectionにapp blocksを配置することで、テーマコードを直接触らずにアプリ由来のコンテンツを追加・移動できる場合があります。レビュー、予約販売、ポイント、チャット、診断、FAQ、ページビルダーなど、アプリが関わるカスタマイズではまずapp block/app embedで扱えるかを見ます。

ただし、アプリを置けることと、運用に耐えることは別です。

観点	確認すること	よくある問題
app block配置	対象sectionがapp blockを受け入れるか	app blockを置きたい場所に対応sectionがない
app embed	全ページ表示が必要か、対象ページだけでよいか	チャット、計測、ポップアップが全ページで重い
アプリ競合	予約、レビュー、ポイント、在庫通知が購入ボタン周辺で干渉しないか	ボタン位置、価格表示、在庫表示が崩れる
表示速度	アプリJS、外部フォント、画像、レビューウィジェットの読み込み	商品ページの主要表示が遅くなる
アクセシビリティ	キーボード操作、フォーカス、alt、コントラスト、フォームラベル	タブやモーダルが操作できない
テーマ更新	アプリ用snippet/scriptの直貼りが残っていないか	アプリ削除後も不要コードが残る
計測	GA4、広告タグ、アプリ計測が二重発火しないか	CVやカートイベントの重複

速度とアクセシビリティは、見た目の最終チェックではなく、改修方針の段階で見ます。たとえば、動画付きバナー、レビューウィジェット、チャット、離脱防止ポップアップをすべて商品ページに足すと、個別には正しくても購入導線としては重くなります。

Shopifyテーマ改修の品質は、公開直後の見た目だけではなく、アプリ追加・テーマ更新・商品追加のあとも、購入導線を説明できる状態が残っているかで決まります。

商品・コレクション・カート・モバイルのQAチェックリスト

テーマカスタマイズのQAは、変更したページだけを見ても足りません。Shopifyでは、商品ページ、商品カード、コレクション、検索、カート、アプリ表示、計測がつながっています。

QA対象	見ること	テスト条件
商品ページ	購入ボタン、バリエーション、価格、画像、メタフィールド、app block	通常商品、在庫切れ、予約商品、バリエーション多数、未入力商品
コレクション	商品カード、価格、バッジ、絞り込み、ページネーション	画像なし、長い商品名、比較価格あり、タグなし
カート	数量変更、カート内注意文、アプリ表示、配送案内	複数商品混在、在庫切れ、予約商品、ギフト商品
トップ/固定ページ	追加section、CTA、画像、リンク	PC/スマホ、リンク切れ、長文時
モバイル	ヘッダー、ドロワー、購入ボタン、固定CTA、タップ領域	iPhone幅、Android幅、縦長商品名
アクセシビリティ	キーボード操作、フォーカス順、フォームラベル、alt	タブ、モーダル、アプリウィジェット
速度	画像サイズ、不要JS、app embed、CLS	商品ページ、トップ、コレクション
計測	GA4、広告、Meta、LINE、アプリCV	カート追加、購入導線、フォーム送信
SEO	title、description、canonical、見出し、構造化データ	商品テンプレート、固定ページ、コレクション

特に商品ページは、1商品だけで判断しない方がよいです。売れ筋商品、在庫切れ商品、バリエーションが多い商品、メタフィールド未入力の商品、画像枚数が少ない商品、アプリ表示対象外の商品を含めます。

また、カートまで確認します。商品ページに配送注意を出しても、カートで消えると問い合わせが増えます。予約販売や温度帯配送など、購入前に理解してほしい情報は、商品ページとカートの両方で表示方針を決めます。

テーマ/アプリ更新後も壊れにくい保守ルール

テーマカスタマイズは、公開して終わりではありません。Shopifyテーマ、アプリ、Shopify本体の仕様は更新されます。公式ドキュメントの内容も将来変わる可能性があるため、実装前・更新前には対象テーマのバージョンと公式情報を確認します。

保守ルール	内容
改修台帳を残す	目的、対象URL、対象テーマ、変更ファイル、管理画面変更、app block、戻し方を書く
商品データと表示を分ける	商品別情報はメタフィールド/メタオブジェクト、表示はsection/Liquidへ分ける
例外を直書きしない	商品handleやIDの分岐は一時対応にし、撤去条件を残す
app blockを優先する	対応アプリではテーマコード直貼りよりapp block/app embedを優先する
CSS/JSの読み込み範囲を限定する	商品ページ用の処理を全ページで読み込まない
更新前に複製テーマで見る	テーマ更新、アプリ更新、Shopify設定変更は複製テーマやpreviewで確認する
公開後の回帰QAを固定する	商品、コレクション、カート、モバイル、速度、計測を毎回見る
四半期で棚卸しする	使っていないsection、app embed、メタフィールド、CSS、計測タグを確認する

保守ルールは大げさなドキュメントである必要はありません。スプレッドシート、チケット、GitHub issue、Notionの1ページでもよいです。大事なのは、次の担当者が「なぜこのsectionがあるのか」「なぜこのCSSが残っているのか」「このapp blockを外してよいのか」を追えることです。

外部ベンダーへ依頼する場合も、納品物を「変更後の見た目」だけにしない方がよいです。変更ファイル、管理画面変更、追加したメタフィールド、app block配置、公開手順、ロールバック手順、QA結果まで含めて受け取ります。

依頼時に渡すべき情報

Shopifyテーマカスタマイズを依頼するときは、「いい感じに直してください」では不足します。運用中テーマでは、実装前に次の情報を渡すだけで、事故がかなり減ります。

依頼項目	書く内容
改修目的	例：商品ごとの注意事項をEC担当が更新できるようにする
対象範囲	テーマ名、テーマID、対象URL、対象テンプレート、対象商品タイプ
希望する編集者	EC担当が管理画面で触るのか、開発者がコード管理するのか
データ	メタフィールド、メタオブジェクト、商品タグ、アプリ設定の有無
アプリ	既存レビュー、予約、ポイント、チャット、計測、ページビルダー
表示条件	空欄時、長文時、在庫切れ、予約商品、モバイルでの表示
公開手順	preview確認者、公開日、戻し方、公開後チェック
納品物	変更ファイル、設定変更メモ、QA結果、保守メモ

この粒度で依頼すると、制作側も「Liquidを少し直す仕事」ではなく、「運用できる売場UIを作る仕事」として設計しやすくなります。結果として、見た目だけでなく、商品追加、キャンペーン追加、アプリ更新、テーマ更新に耐えやすくなります。

まとめ

Shopifyテーマカスタマイズは、テーマエディタで色やsectionを変えるだけの作業ではありません。運用中ストアでは、現行テーマを複製して戻せる状態を作り、管理画面、section/block、dynamic sources、メタフィールド、メタオブジェクト、Liquid、CSS、JavaScript、app blocks、外部APIの境界を先に決める必要があります。

Online Store 2.0では、sections/blocksやdynamic sourcesによって管理画面で保守できる範囲が広がっています。一方で、商品ごとの例外、アプリの干渉、表示速度、アクセシビリティ、カート横断のQA、テーマ/アプリ更新後の回帰確認を無視すると、既存テーマは少しずつ保守しにくくなります。

Bitlightでは、Shopifyテーマを「その場のデザイン変更」ではなく、売場改善と運用保守が両立する仕組みとして整理します。既存テーマの改修範囲、メタフィールド/メタオブジェクト設計、app block配置、Liquid/CSS/JSの責務、公開・ロールバック手順、QA台帳まで含めて、壊さず育てられるテーマ運用に落とし込みます。

既存テーマを触る前に、まずは「管理画面で直すもの」「データ設計で直すもの」「Liquid/CSS/JSで直すもの」「アプリ/APIへ分けるもの」を棚卸しすることが、長く保守できるShopifyカスタマイズの出発点です。