Shopifyテーマ開発の実務設計｜Online Store 2.0・Liquid・メタフィールド・Git運用

「shopify テーマ 開発」で調べる人の多くは、テーマをゼロから作りたいわけではありません。

既存テーマの商品ページを直したい。セクションを増やしたい。商品ごとに成分表やサイズ表を出したい。レビューアプリや診断アプリを自然に埋め込みたい。制作会社に頼んだ改修が、次のテーマ更新で壊れないか不安。こうした実務上の悩みを持っています。

Shopify公式のTheme architectureでは、テーマは標準のディレクトリ構造で整理され、layout、templates、sections、snippets、config、assetsなどが役割を持つと説明されています。また、sections and blocksのベストプラクティスでは、マーチャントがテーマを編集できるように、どの機能をsectionやblockとして提供するかを慎重に設計する必要があると示されています。

つまりShopifyテーマ開発は、Liquidの記法だけではなく、売場改善をどこに実装し、どの情報をメタフィールドやメタオブジェクトに逃がし、どこから先をtheme app extensionやカスタムアプリ/APIに分けるかを決める仕事です。

Shopify APIの種類と選び方では、Admin API、Storefront API、Webhook、Functionsなどの選定を整理しました。この記事では、APIに進む前のストアフロント側、つまりOnline Store 2.0テーマを保守可能な実務フローとして改修する方法を整理します。

Shopifyテーマ開発で先に決めるべきなのは、どのLiquidファイルを触るかではなく、要件をテーマ構造、メタデータ、アプリ拡張、外部APIのどこに置くかです。

先に結論：テーマ改修は実装先を分ける

Shopifyテーマ開発では、すべてをLiquidへ直書きしないことが重要です。表示の枠組みはテーマ、商品ごとに変わる情報はメタフィールドやメタオブジェクト、アプリ由来のUIはapp blocks、外部システムとの同期や自動処理はカスタムアプリ/APIに分けます。

やりたいこと	第一候補	避けたい実装	判断のポイント
商品ページの構成を変えたい	templates/product.jsonと商品系section	商品ごとにLiquidを複製	商品タイプ別テンプレートで足りるかを見る
成分表、サイズ表、注意事項を商品ごとに出したい	メタフィールド	商品説明HTMLへ手入力	入力者が管理画面で安全に更新できるか
複数商品で共通の比較表やFAQを使いたい	メタオブジェクト	section内に固定文言を直書き	共通データとして再利用できるか
レビュー、診断、予約、チャットを表示したい	app blocks / app embed blocks	テーマコードへのアプリ用snippet直貼り	アプリ削除・更新時にテーマを汚さないか
外部在庫、会員ランク、独自レコメンドを表示したい	カスタムアプリ、app proxy、API連携	Liquidだけで外部データを扱う	認証、キャッシュ、失敗時表示を設計できるか
ヘッダーやフッターを調整したい	layout、section groups、theme settings	各テンプレートへ同じHTMLを追加	全ページ共通要素として管理できるか
CSSやJSを追加したい	assetsとsection単位の読み込み	グローバルJSを無制限に追加	パフォーマンスと競合を確認できるか
公開前に確認したい	development themes、preview、Theme Check	本番テーマを直接編集	差分、承認、戻し方を残せるか

この切り分けを最初に行うだけで、テーマ改修の失敗はかなり減ります。逆に、要件を聞いた瞬間に「Liquidでできます」とだけ返す開発は、短期的には速く見えても、半年後に保守不能になりやすいです。

Online Store 2.0の前提を押さえる

Shopifyの現在のテーマ改修では、Online Store 2.0を前提に考えます。Online Store 2.0テーマでは、JSONテンプレート、sections、blocks、メタフィールドの動的ソース、app blocksなどを使って、管理画面から構成を調整しやすくなっています。

テーマは、ざっくり次の階層でページを組み立てます。

階層	主なファイル・機能	実務での役割
layout	layout/theme.liquid	HTML全体、head、共通ヘッダー・フッター、全ページ共通の土台
templates	templates/*.json、一部Liquidテンプレート	商品、コレクション、ページ、ブログなど、ページ種別ごとのsection構成
sections	sections/*.liquid、section groups	管理画面で追加・削除・並べ替えできる大きな表示単位
blocks	section内のblock定義、blocksディレクトリ	sectionの中で追加・削除・並べ替えできる部品
snippets	snippets/*.liquid	複数箇所で再利用する小さなLiquid部品。マーチャントには直接見えにくい
settings	config/settings_schema.json、section/block schema	色、余白、表示オプション、選択肢など、テーマエディタで触る設定
assets	assets/*.css、assets/*.js、画像など	見た目と挙動。読み込み範囲とサイズを管理する
locales	locales/*.json	テーマ内文言の翻訳・差し替え

公式ドキュメントでも、JSON templatesはsectionsのラッパーとして働き、sectionsは再利用可能でカスタマイズ可能なコンテンツモジュール、blocksはsection内で追加・削除・並べ替えできる部品、snippetsはどこからでもrenderできる再利用Liquid部品として整理されています。

この構造を理解しないまま改修すると、商品ページだけの変更のつもりが全ページに影響したり、1商品だけのキャンペーン文言がテーマコードに残り続けたりします。

Liquidは「表示の組み立て」に使う

LiquidはShopifyテーマの中心ですが、Liquidだけで何でも解決しようとしない方がよいです。Liquidは、Shopifyが持っている商品、コレクション、カート、顧客、メタフィールドなどの情報を使って、HTMLを組み立てるためのテンプレート言語です。

Liquidで向くこと	Liquidだけでは無理が出ること
商品情報、価格、画像、在庫状態、タグによる表示切り替え	外部DBのリアルタイム照会
メタフィールドを使った商品ごとの注意文、スペック、FAQ表示	認証が必要な個別会員データの取得
section/blockの設定値に応じたレイアウト変更	複雑な在庫同期、会計連携、CRM更新
カートボタン、バリエーション選択、簡単な条件分岐	失敗時の再実行や監査ログが必要な自動処理
snippet化された表示部品の再利用	管理画面側のデータ更新

たとえば「商品ごとに素材、原産国、洗濯方法、アレルゲンを出したい」なら、Liquidで表示するのは正しいです。ただし値をLiquid内へ直接書くのではなく、商品メタフィールドとして管理し、テーマはそれを表示するだけにします。

一方、「顧客の会員ランクを外部CRMから取得して価格表示を変えたい」なら、Liquidだけでは足りない可能性があります。Shopify内に同期された顧客タグやメタフィールドで判定できるのか、外部APIが必要なのか、そもそも価格やチェックアウトに影響するなら別のShopify機能が必要なのかを分けます。

sections/blocksは編集しやすさから設計する

Online Store 2.0の価値は、エンジニアだけでなくEC担当者がテーマエディタで売場を調整できることです。ただし、blockを増やせば便利になるわけではありません。

公式のsections/blocksベストプラクティスでも、blockを細かくしすぎるとテーマコードと編集体験の両方が複雑になるため、適切な粒度でグループ化することが勧められています。

要件	sectionにするか	blockにするか	設計メモ
商品詳細の主要情報	商品ページのmain section	タイトル、価格、購入ボタン、説明などをblock化	並び替えたい要素だけblockにする
FAQ一覧	専用section	質問・回答をblock化	少数ならblock、多商品共通ならメタオブジェクトも検討
サイズ表	sectionまたはsnippet	行ごとblockは細かすぎる場合が多い	商品メタフィールドやメタオブジェクトでデータ化する
比較表	section	比較項目をblock化するか、メタオブジェクト参照	表構造が複雑なら管理データ側へ寄せる
レビューアプリ表示	app block対応section	@app blockを許可	レイアウトが壊れない位置だけ許可する
キャンペーンバナー	section	テキスト、リンク、画像を設定化	表示期間と戻し方を台帳に残す
複数ブランド共通の説明	sectionではなくメタオブジェクトを検討	block直書きは避ける	共通文言の更新漏れを防ぐ

sections/blocks設計で大事なのは、「EC担当者が自由にできる範囲」と「崩してはいけない範囲」を分けることです。

たとえば商品ページでレビュー、配送案内、FAQ、成分表、関連商品を自由に並べ替えたいなら、block設計は有効です。しかし、購入ボタン周辺に何でも挿入できるようにすると、コンバージョンや表示崩れに影響します。app blocksも同じで、商品レビューやサイズ診断のように購入判断を補強する場所には向きますが、どのsectionにも無制限に入れられる設計は危険です。

メタフィールドとメタオブジェクトで「データ」をテーマから分ける

テーマ改修でよくある失敗は、商品ごとに違う情報をLiquidやHTMLへ直接書いてしまうことです。これを避けるために、メタフィールドとメタオブジェクトを使います。

情報	メタフィールドが向く場合	メタオブジェクトが向く場合
商品ごとの注意事項	1商品に1つの短いテキストを持つ	複数商品で共通の注意事項セットを参照する
サイズ表	商品ごとに簡単な表や画像を持つ	サイズ表を複数商品・複数ページで再利用する
成分・素材	商品に紐づく固定項目として持つ	成分辞書や素材説明を別データとして持つ
FAQ	商品ごとに少数のQ&Aを持つ	共通FAQ群をカテゴリ別に管理する
比較表	商品ごとの比較用属性を持つ	比較軸や比較グループをデータとして管理する
店舗・ブランド情報	商品やページに単純な参照を持つ	店舗、スタッフ、ブランド、レシピなど独立したページ化も見込む

判断基準は単純です。商品にぶら下がる1項目ならメタフィールド、複数箇所で再利用する独立データならメタオブジェクトを検討します。

商品説明のHTMLに成分表を手入力すると、表示はすぐ作れます。しかし、表記ゆれ、更新漏れ、検索・絞り込みへの利用不可、テーマ変更時の移行難易度が残ります。メタフィールドやメタオブジェクトに分けておけば、テーマは表示部品に徹し、データ更新は管理画面側で行えます。

Shopify API連携の設計方法で整理した商品マスタ連携でも、販売文言、SKU、JAN、在庫、原価、出荷条件を同じ場所に混ぜないことが重要でした。テーマ開発でも同じで、見た目とデータを分けるほど、あとから運用しやすくなります。

theme app extensionsとapp blocksの境界

レビュー、星評価、予約、チャット、診断、会員表示など、アプリの機能をテーマへ出す場合は、theme app extensionsとapp blocksを理解しておきます。

Shopify公式のtheme app extensionsでは、マーチャントがLiquidテンプレートやコードを直接触らずに、動的要素をテーマへ追加できる仕組みとして説明されています。app blocksはページ内に表示するUI、app embed blocksはチャット、トラッキング、SEOメタタグのようにページ全体へ埋め込む要素に使われます。

要件	向く実装	注意点
商品レビューを商品情報の近くに置く	app block	sectionが@app blockを受け入れる必要がある
チャットバブルを全ページに出す	app embed block	有効化状態と表示位置を運用で確認する
診断結果を商品ページに表示する	app blockまたはカスタムsection	外部データ参照が必要ならアプリ側の責任も設計する
広告タグや計測タグを入れる	app embed block、販売チャネル、タグ管理	二重計測、同意管理、速度影響を見る
外部DBの在庫・納期を表示する	app proxy、カスタムアプリ、API	キャッシュ、失敗時表示、認証を決める

公式のapp block設定でも、app blocksは互換性のあるsectionに追加でき、テーマ側はJSON templatesと@app block対応が必要と説明されています。テーマがapp blocksを支えるかは、verify theme supportの観点で、JSONテンプレートか、対象sectionが@appを持つかを確認します。

ここで避けたいのは、アプリの案内に従ってテーマコードへsnippetやscriptを直接貼り続けることです。アプリ削除後に不要コードが残り、表示速度やテーマ更新の邪魔になることがあります。Online Store 2.0では、できる限りtheme app extensions、app blocks、app embed blocksで扱える形を優先します。

カスタムアプリ/APIに逃がす境界

テーマはストアフロントの表示を作る場所です。外部連携、業務処理、管理データ更新、失敗時の再実行は、テーマではなくカスタムアプリ/APIの領域です。

テーマで留める要件	アプリ/APIに分ける要件
商品メタフィールドを読み、商品ページに表示する	外部PIMから商品メタフィールドを同期する
商品タグや在庫状態で注意文を出す	WMS在庫を取得し、Shopify在庫を更新する
カート内の商品条件で案内文を出す	注文作成後に会計、CRM、倉庫へ連携する
アプリのapp blockを置く場所を用意する	独自アプリを作り、テーマへapp blockを提供する
JavaScriptでUIを少し補助する	認証が必要な外部データを安全に取得する

たとえば「商品ページに納期を出したい」という要件でも、実装先は分かれます。Shopifyの商品メタフィールドに納期を持ち、Liquidで表示するだけならテーマ改修です。WMSや基幹在庫から日々納期を取得してShopifyへ反映するなら、Admin APIやWebhookを含む連携設計です。顧客ごとに表示を変え、外部会員DBを参照するなら、カスタムアプリやapp proxyも検討します。

テーマの外に出す判断は、技術的に大げさな選択ではありません。むしろ、テーマを表示責務に絞ることで、公開テーマを壊さず、ログや再実行を持てる場所に業務処理を置けます。

Shopify CLI、development themes、Theme Check、GitHub連携

本番テーマを管理画面のコードエディタで直接触る運用は、できるだけ避けます。Shopify公式のShopify CLI for themesでは、テーマの開発、プレビュー、テスト、共有をCLIで行えることが説明されています。shopify theme devはdevelopment themeへアップロードしてプレビューでき、ローカル変更を確認しながら作業できます。

また、Shopify CLIのtheme commandsには、Theme Checkを実行するtheme check、development themeでプレビューするtheme dev、テーマ一覧を見るtheme list、テーマをpush/pull/publishするコマンドなどがあります。公式のtheme toolsでも、GitHub連携はGitでテーマ変更を追跡し、Theme Checkはテーマコードのエラー検出とベストプラクティス確認に使うツールとして紹介されています。

実務では、次のような開発フローにします。

段階	使うもの	確認すること
要件整理	改修台帳、画面キャプチャ、対象URL	どのページ、どの商品、どの担当が困っているか
実装先判断	テーマ、メタフィールド、メタオブジェクト、アプリ/API	Liquid直書きで済ませてよいか
ローカル作業	Shopify CLI、Git、エディタ	差分が追える状態で編集する
開発プレビュー	development theme、preview link	実ストアデータに近い状態で確認する
静的確認	Theme Check、Liquid整形、不要JS確認	エラー、非推奨、読み込み過多を減らす
承認	preview、テーマエディタ、スマホ確認	EC担当、CS、マーケが実画面で見る
公開	publish、GitHub連携、公開テーマ切替	公開時刻、担当、対象テーマIDを残す
ロールバック	旧テーマ、Git差分、変更台帳	戻す条件と戻し先を明確にする

GitHub連携を使う場合でも、管理画面側のテーマエディタ変更とGit上のコード変更が混ざることがあります。色や余白などtheme settingsで変えるもの、コードとして管理するもの、メタフィールド定義として管理するものを分け、変更台帳に残します。

preview、publish、rollbackは公開手順として設計する

Shopifyテーマ開発では、公開前にpreviewできることが強みです。しかし、preview linkを送るだけでは公開手順になりません。

公開前チェック	確認内容
対象ページ	トップ、商品、コレクション、カート、固定ページ、ブログ、検索
対象商品	通常商品、予約商品、在庫切れ、バリエーション多数、メタフィールド未入力
表示端末	PC、スマホ、主要ブラウザ
app blocks	レビュー、診断、チャット、計測タグが想定位置に出るか
メタフィールド	空欄時、長文時、画像未設定時に崩れないか
購入導線	バリエーション選択、カート追加、カート表示、購入ボタン周辺
パフォーマンス	画像サイズ、不要JS、遅延読み込み、Lighthouseの大きな悪化
SEO	title、description、構造化データ、canonical、見出し崩れ
計測	GA4、広告タグ、Meta、LINEなどの二重発火や消失
戻し方	旧テーマに戻すか、Git差分を戻すか、対象sectionだけ戻すか

公開は「ボタンを押す作業」ではなく、承認済みの差分を本番テーマに反映し、問題があれば戻せる状態にする作業です。公開直後は、主要ページ、カート、計測、アプリ表示を再確認します。

ロールバックも決めておきます。旧テーマを残すのか、Gitで戻すのか、テーマエディタ設定を戻すのかによって、復旧時間は変わります。特にテーマエディタ上で変更したsection設定は、コード差分だけでは戻せない場合があります。だからこそ、公開前に「どのテーマIDを元にしたか」「どの設定を変えたか」「どの商品メタフィールドを追加したか」を台帳に残します。

改修台帳を作る

テーマ改修を保守できる会社は、コードだけでなく改修台帳を残します。台帳は大げさなドキュメントではなく、あとから原因を追える最低限の記録です。

台帳項目	内容
改修ID	theme-20260703-001のような管理番号
要件	誰のどの業務課題か。見た目変更か、入力運用変更か、連携前提か
対象	テーマID、テンプレート、section、商品タイプ、対象URL
実装先	Liquid、section/block、メタフィールド、メタオブジェクト、app block、API
変更ファイル	sections/main-product.liquidなど
追加データ	メタフィールド定義、メタオブジェクト定義、テーマ設定
確認条件	対象商品、スマホ、在庫切れ、未入力時、アプリ表示
公開情報	公開日、公開者、承認者、preview link
戻し方	旧テーマへ戻す、Git revert、設定値を戻す、アプリを無効化
影響範囲	表示速度、SEO、計測、購入導線、CS問い合わせ

台帳があると、外注先が変わっても引き継ぎやすくなります。逆に台帳がないと、管理画面で誰かが直したsection設定、テーマコード内の一時対応、アプリ追加時のsnippetが混ざり、次の改修で壊れます。

パフォーマンスと保守性を見る

テーマ改修では、見た目が合っていても、表示速度や保守性が落ちることがあります。特にECでは、商品画像、アプリ、計測タグ、レビュー、動画、診断UIが積み重なります。

見る観点	よくある問題	改修時の方針
画像	大きすぎる画像、PC用画像をスマホにも配信	Shopifyの画像変換、適切なサイズ、遅延読み込み
JavaScript	アプリや独自JSが全ページで動く	必要なページ・sectionに絞る
CSS	使わないスタイルが増え続ける	section単位で責務を分け、命名を整理する
Liquid	条件分岐が深く、商品ごとの例外が増える	データをメタフィールド化し、snippetで再利用する
app blocks	想定外の位置に入ってレイアウトが崩れる	受け入れるsectionを限定する
計測タグ	GA4、広告、SNSタグが重複する	タグの正本と発火条件を台帳化する
テーマ更新	直書き改修が多くアップデートできない	Git差分、section化、app extension化を優先する

Theme CheckやLighthouseだけで全ては判断できませんが、最低限の確認としては有効です。大切なのは、速度改善を抽象的に語ることではなく、「どのアプリが重いのか」「どの画像が大きいのか」「どのJSが全ページで動いているのか」を特定し、改修台帳へ残すことです。

Shopifyテーマ改修の品質は、公開日に崩れないことだけではなく、次のキャンペーン、次のアプリ追加、次のテーマ更新でも説明できる状態を残せるかで決まります。

外注依頼テンプレート：Liquid実装ではなく運用成果物を依頼する

制作会社やフリーランスへShopifyテーマ開発を依頼する場合、「商品ページをいい感じに直してください」では不足します。依頼時点で、実装範囲、データ管理、公開手順、戻し方を明示します。

依頼項目	書く内容
目的	例：商品ごとの成分表、FAQ、サイズ表をEC担当が更新できるようにする
対象	テーマ名、テーマID、対象テンプレート、対象商品タイプ、対象URL
実装方針	section/block、メタフィールド、メタオブジェクト、app block対応のどれを使う想定か
編集者	EC担当がテーマエディタで触るのか、商品管理画面で触るのか
データ	追加するメタフィールド・メタオブジェクトの定義、入力例、未入力時表示
アプリ	既存アプリ、app blocks、app embed blocks、削除時の影響
API境界	外部連携や自動処理が必要なら別見積もりに分ける
確認	preview link、スマホ、在庫切れ、長文、未入力、対象外商品
納品	変更ファイル、改修台帳、公開手順、ロールバック手順
運用	今後EC担当が更新する項目、開発者へ依頼する項目

このテンプレートで依頼すると、「Liquidを書いたら終わり」になりにくくなります。特に、メタフィールド定義やメタオブジェクト定義、section/blockの編集範囲、app blocksの対応可否は、制作側と運用側の認識がズレやすい部分です。

外部システム連携や受注・在庫・会計まで関わる場合は、テーマ開発とは別にShopify API連携の設計方法の観点で、正本、同期イベント、失敗時の再実行を整理します。購入後の通知文面やCS対応まで変わる場合は、Shopifyのメール設定を運用設計から整える記事も合わせて確認します。

まとめ

Shopifyテーマ開発は、Liquidを書けるかどうかだけで判断する仕事ではありません。

Online Store 2.0の構造を前提に、layout、templates、sections、blocks、snippets、settingsの役割を分けます。商品ごとに変わる情報はメタフィールド、共通データや再利用データはメタオブジェクトに逃がします。レビューや診断などアプリ由来のUIはapp blocksやtheme app extensionsで扱い、外部連携や自動処理はカスタムアプリ/APIへ分けます。

さらに、Shopify CLI、development themes、Theme Check、GitHub連携、preview、publish、rollback、改修台帳まで含めて運用すると、テーマ改修はその場限りの見た目変更ではなく、売場改善を継続できる仕組みになります。

Bitlightでは、Shopifyテーマの見た目だけでなく、商品データ、メタフィールド設計、アプリ埋め込み、API連携の境界、公開・ロールバック手順まで含めて整理します。テーマが保守不能になる前に、まずは今ある改修要望を「テーマで直すもの」「データ設計で直すもの」「アプリ/APIに分けるもの」へ切り分けることが重要です。