「Shopifyは自由度が低い」は半分本当で半分誤解です。Shopifyには「自由に触れる層」と「Shopifyが管理して触れない層」があり、この境界線を理解すれば、デザインや独自機能の要望の9割は実現可能。残り1割をどう通すかでコストが大きく変わります。
この記事では、Shopifyカスタマイズを「触れる層／触れない層」の地図として整理し、テーマ・商品ページ・チェックアウトの3領域でどこまで自由でどこから限界なのかを解説します。さらに各要望を「テーマ編集で済む／アプリで足りる／カスタム開発が必要／Plus必須」のどれに仕分けるべきか、判断軸まで踏み込みます。
書いているのは、Shopify Japan設立前から構築・移行を手がけてきた株式会社六（Roku inc.）です。当社の範囲は構築・移行・カスタム開発・チェックアウト/Plus設計（発送・CSのフル人手代行は範囲外）。比較メディアがあまり書かない「やらない判断＝作り込みすぎの保守コスト」まで、実際の経験をもとにお伝えします。
Shopifyカスタマイズの全体像｜「触れる層」と「触れない層」の地図
自由度は「層」の構造で決まります。Shopifyは大きく3つの層に分かれます。
| 層 | 中身 | 自由度 |
|---|---|---|
| フロント層（テーマ） | 商品ページ・トップ・カテゴリの見た目 | 高い（Liquid/HTML/CSS/JSで編集可） |
| 拡張層（アプリ・機能注入） | 独自機能、外部連携 | 中（アプリ／カスタム開発で追加） |
| 基盤層（決済・チェックアウト中核） | 注文処理・決済・チェックアウト | 低い（Shopify管理下。標準では原則不可） |
見た目に近いフロント層ほど自由で、決済・チェックアウトに近い基盤層ほどShopifyが握っている——「自由度が低い」という声は、多くがこの基盤層（特にチェックアウト）を全体に当てはめた誤解です。
逆にフロント層の要望はほぼ通ります。要は「自分の要望がどの層に属するか」を見極めること。これができれば最小コスト・最小保守で実現できます。Shopifyで何ができるかの前提はShopify構築の全体像で解説しています。
テーマカスタマイズの自由度｜Liquid・OS 2.0でできること
テーマは最も自由度が高い領域で、「ノーコードで済む範囲」と「Liquid編集が必要な範囲」に分かれます。
Online Store 2.0（OS 2.0）対応テーマでは、テーマエディタからセクションとブロックを並べ替え・追加・削除できます。商品ページやコレクションページでも、コードを触らずレイアウトを組み替え可能です。重要なのは、OS 2.0テーマでのカスタマイズの多くは設定とコンテンツであり、テーマ更新を生き残る点です（出典：help.shopify.com）。設定で済む要望は、原則ノーコードで対応すべきです。
セクション設定で届かない独自表現は、テンプレート言語Liquidで踏み込みます。Liquidは商品・在庫・顧客情報などをテンプレートに差し込む言語で、自由なフロント表現が可能です。
ただし正直な反証があります。テーマのコードを直接編集すると、テーマ更新時にその編集は引き継がれません。Templatesフォルダとsettings_data.json以外のコード編集（HTML/CSS/JS/Liquid）は、更新版に反映されず設計上失われます（出典：help.shopify.com）。直編集が親テーマから乖離するほどアップデートが事実上不可能になり、パフォーマンスも劣化します（出典：fuelthemes.net, kahunam.com）。
つまり「自由＝なんでもコードで書けばいい」ではありません。凝った直編集ほど将来の保守コストとして跳ね返るのが落とし穴です。設定で済む要望とコードが必要な要望を設計段階で切り分けることが、後の更新コストを左右します。
商品ページカスタマイズの実際｜できること・つまずく点
Shopify商品ページカスタマイズの肝は、メタフィールドとアプリ・テーマ実装の使い分けです。
バリエーション表示（色・サイズ）は標準対応ですが、見せ方を凝るとテーマ実装が必要です。「洗濯方法」「モデル身長」「成分表」といった商品ごとの独自項目は、メタフィールドで対応するのが定石です。
朗報として、OS 2.0対応テーマなら、メタフィールドの独自項目はアプリ不要・ノーコードで表示できます。管理画面の「動的ソースを接続」でメタフィールドをテーマに差し込めるため、従来のLiquid直編集が不要になりました（出典：proteinum.co.jp, rewired.cloud）。
つまずくのは、ここで安易にページビルダーアプリに頼るケースです。判断の目安は次の通りです。
- メタフィールド＋テーマ実装で済む：独自項目の表示、簡単なレイアウト変更
- ページビルダーアプリが有効：非エンジニアが頻繁にLPを量産・改変する運用
- カスタム開発が必要：独自ロジック（条件分岐表示、外部データ連携など）
アプリの選択肢はShopifyアプリ開発の活用法で解説しています。
チェックアウトカスタマイズの限界｜標準プランとShopify Plusの差
Shopifyチェックアウトカスタマイズは標準プランでは大きく制限され、本格的な改修はShopify Plusの領域です。ここが最も誤解と限界が集中します。
標準プランでもチェックアウトの「ブランディング」は可能です（出典：help.shopify.com, shopthemedetector.com）。
- ロゴ・色・フォント（Shopifyフォントライブラリ内）の変更
- 1列／2列のレイアウト選択
- 任意項目（会社名・住所2行目・電話番号など）のON/OFFと必須設定
一方、次はPlusでなければ触れません（出典：help.checkoutbuilder.com, blackbeltcommerce.com）。
- Checkout Editor（ドラッグ&ドロップによる項目編集）
- Checkout Branding APIによる細かな見た目制御
- チェックアウトへのカスタム拡張・ポストパーチェス拡張の追加
- 高度な決済カスタマイズ
重要な前提として、かつてチェックアウトを直接編集できたcheckout.liquidは廃止されました。情報・配送・支払いページ用は2024年8月13日に廃止済み。Thank you／Order statusページはPlusが2025年8月28日に期限を迎え、非Plusの期限は2026年8月26日＝今夏が期限です（出典：help.shopify.com, flatlineagency.com）。主因はPCI DSS v4のセキュリティ要件強化で、2021年以降のcheckout.liquid方式では新基準を満たせません（出典：greysharkmedia.com, shopify.dev）。
現行の正しい方法はCheckout Extensibilityです。コードを直接編集せず、Shopifyがホストする安全なUIに、ブロックやアプリ拡張、Functionsとして機能を「注入」する方式です（出典：shopify.dev）。ただしFunctionsはサンドボックス制約があり外部API接続ができないなど、技術的な線引きがあります。
要件がこのPlus領域に踏み込むかは、構築の早い段階で見極めるべきです。当社はGIVENCHY（LVMH傘下）のオンラインストアで、百貨店のPOSとShopify APIを連携するカスタマイズを3ヶ月で完了した実績があります（出典：自社実績）。チェックアウトや基幹連携が絡む要件こそ、「標準で足りるのかPlusが必要か」の切り分けが投資額を左右します。お問い合わせ（無料モックアップ）から切り分けをご相談ください。
アプリ導入 vs カスタム開発の使い分け｜判断フロー
「アプリを入れるか、作り込むか」の判断には順序があります。
- まずアプリで実現できないか検討（最小コスト・最短）
- アプリで足りなければカスタム開発（独自ロジック・連携）
- チェックアウト中核はPlus（Checkout Extensibility／Functions）
ただし2つの正直な但し書きがあります。
但し書き1：アプリは「入れるほど良い」ではありません。アプリスタックの肥大化は、Shopifyで起きる速度問題の最大要因です。平均的なストアは6〜10個のアプリで読み込みに2〜3秒が上乗せされ、最大40%のコンバージョン機会を失うとされます。30個以上を抱えるストアは計測可能な性能問題を持つことが多いと報告されています（出典：shopexperts.com, debugbear.com）。
但し書き2：カスタム開発が常に高いわけではありません。多くの機能はアプリなしでサイト内に直接構築でき、月額が積み上がるアプリより、一度きりの費用でカスタム機能を作るほうが総額で安くなる場合があります（出典：speedboostr.com, shopexperts.com）。標準機能やワンタイム実装で済むものを、わざわざ月額アプリで賄う必要はありません。
「カスタム開発こそ正義」でも「アプリこそ正義」でもありません。当社はAI駆動開発で細かなこだわりに高速対応できますが、それでも「作り込みすぎは保守コストになる」と正直にお伝えしています。詳細はShopifyアプリ開発の活用法もご覧ください。
カスタマイズで失敗しないための設計の考え方｜将来の保守を見据えて
ここまでを設計原則に落とし込みます。
- 要件をPlus領域とそれ以外に先に切り分ける：チェックアウト中核に触れるかを最初に判定。後から発覚すると設計をやり直すことになる。
- テーマの直編集を避け、変更箇所を局所化する：設定・メタフィールドで済むものはコード化しない。
- アプリは目的から逆算して最小限に：累積コスト（速度・月額・保守）を見て採否を決める。
当社はこの考え方を構築だけでなく移行でも実践しています。EC-CUBEからShopifyへの大規模移行では、フリュー「Mew contact」で顧客7万件・注文16万5千件を移行（出典：自社実績）。reine-de-fleur（レンデフロール）ではShopify構築に加えギフト診断機能をカスタム実装し、CVR向上につなげました（出典：自社実績）。こうした実績を通じ、当社は運用コスト40%削減・CVR2.3倍・ハイブランド構築といった成果を積み重ねてきました（出典：自社実績）。実現可否の見極めから、EC構築・移行支援としてご一緒できます。
よくある質問
Q. Shopifyの標準プランでチェックアウトはどこまで変えられる？
ロゴ・色・フォント（Shopifyフォントライブラリ内）・1列/2列レイアウト・任意項目（会社名・住所2行目・電話番号など）のON/OFFと必須設定までです（出典：help.shopify.com）。ドラッグ&ドロップの項目編集、Checkout Branding APIによる制御、カスタム拡張の追加などはShopify Plusが必要です。Plus料金は契約年数や流通額で変動するため断定は避けますが、3年契約で月額2,300ドル前後からが代表値です（出典：shopify.com/plus, elogic.co）。正確な金額は要見積もりです。
Q. テーマを直接編集しても大丈夫？アップデートで壊れない？
凝った直編集はアップデートで失われるのが仕様です。Templatesフォルダとsettings_data.json以外のコード編集（HTML/CSS/JS/Liquid）は、テーマ更新版に引き継がれません（出典：help.shopify.com）。OS 2.0テーマなら、多くのカスタマイズは設定・コンテンツで実現でき、これらは更新を生き残ります。直編集は避け、必要な場合も変更箇所を局所化するのが安全です。
Q. やりたいことがアプリにない場合、カスタム開発の費用感は？
日本での目安は、オリジナルデザイン・カスタマイズが約100〜300万円、カスタムアプリ開発が約100〜300万円〜、大規模フルカスタムが約300〜1,500万円が一般的な相場帯です（出典：web-kanji.com, imitsu.jp）。これは単一媒体の集計値で、要件により大きく変動します。費用の考え方はShopify構築の費用で解説しています。月額アプリの累積と比べ、ワンタイムのカスタム開発のほうが総額で安くなる場合もあるため、両者を比較して判断するのがおすすめです。
Q. 作り込みすぎると後で困ることはある？
あります。アプリの入れすぎは表示速度を直接削り、平均的なストアでは6〜10個で2〜3秒の遅延、最大40%のCV機会損失につながると報告されています（出典：shopexperts.com, debugbear.com）。テーマの過度な直編集はアップデートを困難にします。「できること」を全部やるのではなく、要件に対して最小の手段を選ぶことが、長期的な運用コストを抑える最大のコツです。
Shopifyのカスタマイズで本当に問われるのは「何ができるか」ではなく、「その要望を、テーマ編集／アプリ／カスタム開発／Plusのどこに仕分けるか」です。仕分けを誤ると、保守コストとして何年も跳ね返ります。「この要望は通るのか」「Plusが必要なのか」の切り分けから、当社がご一緒します。EC構築・移行支援、またはお問い合わせ（無料モックアップ）からご相談ください。
