Shopify商品ページカスタマイズ設計ガイド｜メタフィールド・納期表示・レビューまで

「shopify 商品ページ カスタマイズ」で調べる人の多くは、単に色や余白を変えたいだけではありません。

商品の仕様を分かりやすく見せたい。サイズ表を商品ごとに出したい。配送日数や予約販売の納期を誤解なく表示したい。レビューやUGCを購入判断の近くに置きたい。在庫・クロスセル・GA4計測まで直したいが、商品説明HTMLの直書き地獄には戻したくない。こうした実務上の悩みがあります。

競合記事を見ると、プレイビットのShopify商品ページのカスタマイズ方法はDawnの商品ページ構成、セクション編集、アプリ、Liquid、商品別テンプレートを広く紹介しています。MakeGiftの商品ページカスタマイズ完全ガイドは、商品情報ブロック、セクション追加、動画、迅速な注文リスト、テンプレート割り当てを画面操作寄りに説明しています。2flockの商品ページにカスタムデータを表示させる方法は、商品説明欄を分けたいケースでメタフィールドを使う基本手順を扱っています。

これらは初期理解には役立ちます。ただし、運用中のShopifyでは「どのボタンを押すか」よりも、「商品ページをどんな情報設計にし、その情報をどのデータモデルで持ち、どの実装先で表示するか」の方が重要です。

Shopify公式ヘルプのSections and blocksでは、sectionsとblocksはコンテンツの配置や設定をコード編集なしに調整するための構造であり、互換性のあるsections/blocksではcustom dataから動的な情報を表示できると説明されています。Shopify Dev DocsのDynamic data sourcesでも、dynamic sourcesはsection/block settingsを、商品・コレクション・ページなどのリソース属性や、metafields/metaobjectsの値に接続する仕組みとして整理されています。

一方で、すべての項目がテーマエディタだけで理想通りに出せるわけではありません。Displaying metafields on your online storeでは、テーマがmetafieldsをサポートしている場合、dynamic sourcesに対応するsections/blocksからmetafieldsを接続できる一方、どのmetafieldsが使えるかはテーマのドキュメントやテーマ開発者への確認が必要だと説明されています。実務上は大半の一般的な商品表示用metafieldsをテーマエディタから接続できますが、テーマ、section/block settings、metafield typeの互換性に依存します。

Shopify商品ページカスタマイズで最初に決めるべきなのは、見た目ではなく、購入判断に必要な情報を「商品データ」「テーマ編集」「Liquid」「アプリ」「計測」のどこで管理するかです。

先に結論：商品ページは情報設計から作る

商品ページは、商品名、画像、価格、購入ボタンを並べるだけのページではありません。購入前の不安を減らし、比較判断を助け、購入後の認識違いを減らし、CSや返品の負荷を下げる売場です。

まず、商品ページに載せたい要素を「誰のどんな判断を助ける情報か」で分けます。

情報領域	代表項目	購入者の判断	設計上の注意
基本情報	商品名、価格、画像、バリエーション、販売元	何を買うか、いくらか、選択肢は何か	テーマ標準を崩しすぎない
仕様	素材、寸法、容量、成分、対応機種、同梱物	自分の用途に合うか	商品説明HTMLに混ぜず、構造化する
サイズ・適合	サイズ表、測り方、適合表、モデル着用情報	サイズ違いを避けられるか	商品別かカテゴリ共通かを分ける
配送・納期	通常出荷日、予約販売、温度帯、配送不可地域	いつ届くか、条件はあるか	商品ページとカートの両方で見る
保証・返品	保証期間、返品条件、初期不良対応、修理	購入リスクを許容できるか	法務・CSの正式文言と同期する
信頼材料	レビュー、UGC、認証、受賞、導入実績	他者の評価を確認できるか	表示速度と構造化データを確認する
比較・回遊	関連商品、セット、よく一緒に買われる商品	他の選択肢と比較できるか	押し売りで購入導線を邪魔しない
計測	CTAクリック、サイズ表閲覧、レビュー閲覧、カート追加	どの改善が効いたか	GA4イベントとShopify注文を分けて見る

Shopifyテーマカスタマイズの実務手順でも整理した通り、Online Store 2.0ではsections/blocks、dynamic sources、app blocksを組み合わせて管理画面で保守できる範囲が広がっています。ただし、商品ページの情報そのものが整理されていなければ、便利な編集機能は直書きの置き換えにしかなりません。

テーマ編集・アプリ・Liquid・メタフィールドの使い分け

商品ページの要望は、実装先で分けます。ここを誤ると、後から商品追加、アプリ入れ替え、テーマ更新、広告計測のたびに壊れます。

やりたいこと	第一候補	使うもの	避けたい実装
商品ページの並びや見出しを変える	テーマ編集	sections/blocks、JSON template	本番テーマのLiquidに固定HTMLを追加し続ける
商品ごとの素材や仕様を出す	メタフィールド	商品メタフィールド、dynamic sources、Liquid	商品説明HTMLに表を直書きする
共通サイズ表やブランド情報を使い回す	メタオブジェクト	metaobject、reference metafield	商品ごとに同じ文章や表を複製する
サイズ表をポップアップで出す	dynamic sources	page reference metafield、Pop-up block	全商品共通のリンクを出して空ポップアップを作る
レビューや星評価を出す	アプリ/app block	review app、app block、構造化データ確認	アプリsnippetをテーマへ雑に貼る
在庫・納期を条件表示する	Liquid + データ	商品/バリエーションmetafield、inventory、タグ	CSSだけで見た目上隠す
外部WMSやPIMの値を反映する	API/アプリ	Admin API、メタフィールド同期、Webhook	Liquidだけで外部業務データを扱う
CTAクリックやサイズ表閲覧を測る	計測設計	GA4、GTM、顧客イベント、テーマJS	改修後に「なんとなく売れた」で判断する

Metafieldsでは、metafieldsは商品、顧客、注文など既存のShopifyデータモデルを独自データで拡張するものと説明されています。つまり、商品ページのカスタマイズで本当に重要なのは「入力欄を増やすこと」ではなく、「商品ページに表示する情報をShopifyのデータモデルとして管理すること」です。

Shopifyメタフィールド設計ガイドで扱った通り、商品全体に属する情報は商品メタフィールド、SKUごとに違う値はバリエーションメタフィールド、複数商品で使い回す構造データはメタオブジェクトを検討します。

メタフィールド・メタオブジェクトで管理する項目例

商品ページを保守できる状態にするには、商品説明本文から情報を分離します。本文は読み物として使い、仕様・納期・保証・サイズ表のような更新対象は構造化します。

項目	推奨データ	namespace/key例	表示場所	更新責任
素材	商品メタフィールド	spec.material	仕様表	商品登録担当
寸法・重量	商品/バリエーションメタフィールド	spec.dimension、spec.weight_note	仕様表、配送案内	商品登録担当
サイズ表	page reference metafield、metaobject reference	fit.size_chart	ポップアップ、詳細セクション	商品企画/EC担当
適合機種	メタオブジェクト、list metafield	compatibility.models	適合表	商品企画
出荷目安	商品/バリエーションメタフィールド	shipping.lead_time	購入ボタン周辺、カート	物流/EC担当
予約販売文言	商品メタフィールド、予約アプリ	shipping.preorder_note	購入ボタン直下	EC担当
保証・返品	メタオブジェクト、page reference	policy.warranty	折りたたみ、ポップアップ	CS/法務
商品別FAQ	メタオブジェクト、商品メタフィールド	content.faq_set	FAQセクション	CS/商品担当
構造化データ補助	商品メタフィールド	seo.condition、seo.model_number	theme Liquid/schema	開発/EC担当
内部管理ID	管理用メタフィールド	integration.external_product_id	原則非表示	システム担当

Shopify公式のAdding a pop-up size chart to your product pagesでは、商品にpage reference metafieldを作成し、商品ページのPop-up blockへdynamic sourceとして接続するサイズ表の例が示されています。サイズ表は、商品説明HTMLへ表を直書きするより、page referenceやメタオブジェクトで管理した方が、商品ごとの出し分けと更新がしやすくなります。

ただし、page referenceを空のままにすると、テーマや設定によってはリンク文言だけが残り、ポップアップが空になる可能性があります。商品数が多いストアでは、未入力商品の表示をLiquid側で隠す、テンプレートを分ける、QAで空欄商品を確認する、といった設計が必要です。

ブロック別に実装先を決める

商品ページは、すべてを1つの「商品説明」に押し込まない方がよいです。購入判断に近い情報、詳しく読みたい情報、信頼を補強する情報、回遊を促す情報を分けます。

ブロック	表示する内容	実装候補	QA観点
ファーストビュー	画像、商品名、価格、バリエーション、購入ボタン	テーマ標準、main product section	画像比率、長い商品名、在庫切れ、モバイル固定CTA
購入前注意	出荷目安、予約販売、返品不可、温度帯	商品/バリエーションmetafield + Liquid	カートでも必要か、空欄時に隠れるか
仕様表	素材、寸法、容量、同梱物、対応機種	metafield + dynamic sources、Liquid	未入力行、長文、単位、表記ゆれ
サイズ表	サイズガイド、測り方、比較表	page reference、metaobject、Pop-up block	スマホで表が崩れないか、空ポップアップが出ないか
保証/返品	保証期間、返品条件、初期不良対応	page reference、metaobject、accordion block	法務/CSの正式文言と一致するか
レビュー/UGC	星評価、本文、画像、Q&A	review app、app block	速度、schema重複、低評価対応、画像許諾
在庫/再入荷	在庫あり、残りわずか、再入荷通知	Shopify在庫、アプリ、Liquid	煽り表示の根拠、在庫切れ時CTA
クロスセル	関連商品、セット、付属品、代替品	product reference、collection、アプリ	購入ボタンを邪魔しないか、在庫切れ商品を出さないか
計測	CTA、サイズ表、レビュー、FAQ閲覧	GA4、テーマJS、GTM	イベント重複、商品ID、改善前後比較

Shopify Dev DocsのBuilding with sections and blocksでは、sectionsとblocksはマーチャントがテーマをカスタマイズ・拡張できるモジュールであり、app blocksやmetafieldsも取り込めるものとして説明されています。つまり、商品ページの編集性を上げるなら、自由HTML欄を増やすのではなく、意味のあるblockへ切り分ける方が安全です。

たとえば「購入前注意」blockには、手入力の自由文ではなく、shipping.lead_time、shipping.temperature_zone、shipping.preorder_noteのような決まった項目を接続します。EC担当者は値を更新できるが、購入ボタン周辺の構造は崩せない。この状態が望ましいです。

Liquidコードは短く、データ設計を厚くする

メタフィールド表示にLiquidを使う場合でも、コードは複雑にしすぎない方がよいです。Liquidは、すでに設計された商品データを、空欄や型に注意して表示する場所です。

{% assign lead_time = product.selected_or_first_available_variant.metafields.shipping.lead_time.value %}

{% if lead_time != blank %}
  <p class="product-notice">
    出荷目安：{{ lead_time | escape }}
  </p>
{% endif %}

この例で重要なのは、Liquidの書き方そのものではありません。出荷目安を商品単位で持つのか、バリエーション単位で持つのか。予約販売アプリの表示と競合しないか。カートや注文確認メールでも必要か。物流担当が更新するのか。未入力時は何も出さないのか。これらを決めることです。

Shopify Liquid入門でも整理した通り、Liquidは表示の組み立てに向いています。外部WMSへのリアルタイム照会、在庫引当、購入可否の最終判定、CS対応履歴の取得までLiquidに押し込むべきではありません。

Liquidで持つのは、空欄時の非表示、テーマ内の初期表示、商品データの読み出し、軽い表示条件までです。レビュー収集、購入可否の制御、外部在庫の即時照会、purchase計測の正本管理は、アプリ、API、Shopify設定、計測基盤へ分けます。

レビュー、UGC、構造化データはセットで見る

レビューやUGCは商品ページの説得力を上げます。ただし、レビューアプリを入れて星を出せば完了ではありません。いつ依頼するか、配送完了前の注文を除外するか、低評価を誰が見るか、写真や動画をLP/SNS/広告へ再利用してよいか、商品ページの表示速度をどこまで許容するかを先に決めます。

Shopifyレビューアプリの選び方と運用設計でも扱った通り、レビューは装飾ではなく、購入後接点、CS、商品改善、SEO、CRMへ流れる運用データです。商品ページカスタマイズの文脈では、レビューを「どこに表示するか」だけでなく、「低評価で分かったサイズ不安を、サイズ表やFAQに戻す」流れまで設計します。

構造化データも同じです。テーマがProduct schemaを持っていて、レビューアプリもaggregateRatingを出す場合、重複や不整合が起きることがあります。テーマ側、アプリ側、商品データ側の値が食い違わないように確認します。

クロスセルと構造化データは「関連性」をデータで持つ

商品ページに関連商品を置くこと自体は簡単です。問題は、何を関連と呼ぶかです。付属品や適合品はproduct reference metafieldやメタオブジェクトで明示し、単純な季節訴求やランキングはコレクションやアプリの自動推薦で足ります。セット販売は在庫、割引、返品条件まで設計し、在庫切れ時の代替品は価格帯や用途がズレないようにします。構造化データも、レビュー、価格、在庫、商品識別子がテーマ・アプリ・商品データで食い違わないように確認します。

モバイル速度・A/Bテスト・GA4計測

商品ページの改善は、実装して終わりではありません。表示速度、モバイルの見やすさ、計測の整合性を確認します。

計測対象	GA4/計測イベント例	見る理由	注意点
商品閲覧	view_item	商品詳細ページに流入しているか	item_idとShopifyの商品ID/SKUを対応させる
バリエーション選択	select_itemまたは独自イベント	サイズ・色の選択で迷っていないか	イベント名を増やしすぎない
サイズ表閲覧	size_chart_open	サイズ不安の強さを見る	表示だけでなくカート追加率と合わせる
FAQ開閉	product_faq_open	どの不安が強いかを見る	個人情報や検索語を送らない
レビュー閲覧	review_section_view	レビューが購入判断に効いているか	アプリ側計測との重複に注意
カート追加	add_to_cart	改善後に購入導線へ進むか	Shopify標準計測と独自計測を重複させない
購入	purchase	最終成果を見る	Shopify注文とGA4 purchaseの差分を見る

ShopifyのGA4設定を計測運用まで設計するでも整理した通り、GA4の数字はShopify注文の正本ではありません。商品ページ改善では、Shopify注文、GA4、広告CV、レビューアプリの指標を混同しないことが重要です。

A/Bテストでも、購入率だけを見ない方がよいです。サイズ表閲覧、レビュー閲覧、問い合わせ、返品理由、ページ速度を合わせて見ないと、短期CVRだけ高いが運用負荷が増える変更を見落とします。

モバイルでは、ファーストビューで価格・バリエーション・CTAが見つかるか、仕様表やサイズ表が横幅で破綻しないか、レビュー画像や固定CTAがチャット・アプリウィジェットと重ならないかを確認します。

商品ページ改善は、CVRだけで判断すると危険です。仕様・納期・保証・レビューの見せ方が、問い合わせ、返品、ページ速度、計測の整合性までどう影響するかを一緒に見ます。

商品数が多いストア向けQAチェックリスト

商品数が多いストアでは、1商品だけ確認して公開すると危険です。データ未入力、バリエーション差、在庫切れ、アプリ対象外、長文、画像不足で崩れます。

QA対象	確認条件	見ること
通常商品	売れ筋、標準的な商品	基本レイアウト、CTA、仕様表
バリエーション多数	サイズ/色/容量が多い商品	選択UI、納期切替、価格差
メタフィールド未入力	新規商品、旧商品	ラベルだけ残らないか、空sectionが出ないか
サイズ表対象外	サイズ表不要商品	Pop-upリンクが空で出ないか
予約/受注生産	納期が通常と違う商品	出荷目安、カート内注意、メール文言
在庫切れ	売り切れ、再入荷予定あり/なし	CTA、再入荷通知、代替品表示
返品条件が特殊	衛生商品、セール品、名入れ商品	保証/返品block、購入前注意
レビューなし	新商品	星評価の空表示、schema不整合
画像が少ない	1枚商品、画像なし商品	レイアウト、サムネイル、alt
モバイル	iPhone幅、Android幅	固定CTA、表、ポップアップ、アプリ重なり

QAでは、ページ単体だけでなく、商品カード、コレクション、検索、カートも見ます。商品ページに出した配送注意がカートで消えると、購入直前の誤解が残ります。関連商品が在庫切れを出し続けると、回遊は増えても購入体験は悪くなります。レビューアプリを入れたら、商品カードの星評価、商品ページのschema、ページ速度も一緒に確認します。

まとめ

Shopifyの商品ページカスタマイズは、テーマエディタの操作やアプリ追加だけでは完結しません。最初に、商品ページで購入者が何を判断するのかを整理し、仕様表、サイズ表、配送/納期、保証/返品、レビュー/UGC、在庫表示、クロスセル、構造化データ、速度、GA4計測、QAまでを一つの設計として扱う必要があります。

Online Store 2.0のsections/blocksとdynamic sourcesを使えば、コード編集なしに管理画面で保守できる範囲は広がります。一方で、metafields/metaobjectsの型、テーマ側の対応、app blockの配置、Liquidでの空欄処理、アプリの速度影響、計測重複を見ないと、商品ページは少しずつ保守しにくくなります。

Bitlightでは、Shopify商品ページを「見た目の変更」ではなく、商品データ、売場UI、レビュー運用、配送/納期表示、計測、QAがつながる実務システムとして設計します。商品説明HTMLの直書きを減らし、EC担当者が更新でき、開発者がレビューでき、商品数が増えても壊れにくい商品ページに落とし込みます。

商品ページを触る前に、まずは「この情報はどこが正本か」「誰が更新するか」「どの実装先で出すか」「どう測るか」を表にすることが、長く保守できるShopifyカスタマイズの出発点です。