この記事の対象: ShopifyでECを運営していて、テーマの変更・リニューアルを検討している事業者
読了時間: 約12分
「テーマを新しいものに変えたい」——Shopifyを運営していると、遅かれ早かれこの話が出ます。デザインが古く見えてきた、今のテーマが更新されなくなった、もっと良さそうな有料テーマを見つけた。理由はさまざまです。
ここで多くの運営者がつまずくのが、「テーマを変える」が想像よりずっと広い範囲に波及するという点です。商品データは残るのでリスクが小さく見えるのですが、実際に切り替えると「トップの構成が全部消えた」「FAQのアコーディオンが表示されない」「レビューが出ていない」といった事態が同時に起きます。
この記事では、Shopifyのテーマ変更で引き継がれるもの・消えるもの・壊れるものを境界線で整理し、やり直しになる範囲を先に見積もるための記録の残し方まで具体的に書きます。制作会社としてShopify構築を手がけ、自社でもDawnベースのストアを運用している立場から、切り替え作業で実際に工数を食う部分を中心にまとめます。
Shopifyのテーマ変更で「消えるもの」と「残るもの」の境界線
まず全体像です。Shopifyのデータは大きく3つの層に分かれていて、テーマ変更で影響を受けるのは一番上の層だけです。逆に言えば、その層に何を積み上げてきたかで作業量が大きく変わります。
ストアデータ層（影響なし）
- 商品・コレクション・在庫
- 顧客・注文履歴
- ページ・ブログ記事の本文
- 配送設定・決済・税
- メタフィールドの値
アプリ層（半分残る）
- アプリ本体とデータは残る
- テーマへの表示だけ消える
テーマ層（全部やり直し）
- セクションの配置と設定
- カスタマイズしたLiquid/CSS/JS
- テーマ設定（色・フォント）
- 翻訳・文言の上書き
「データは消えない」は本当。ただし表示する側は全部作り直しになる。
この図で押さえてほしいのは、ストアデータ層は一切触られないという安心材料と、テーマ層は引き継ぎの仕組みがそもそも用意されていないという現実の両方です。
完全に残るもの
| 対象 | テーマ変更後の状態 |
|---|---|
| 商品・バリエーション・在庫 | そのまま |
| コレクション（自動・手動とも） | そのまま |
| 顧客アカウント・注文履歴 | そのまま |
| ページ・ブログ記事の本文 | そのまま |
| 配送プロファイル・送料設定 | そのまま |
| 決済・税設定 | そのまま |
| メタフィールド・メタオブジェクトの「値」 | そのまま |
| URL構造・リダイレクト設定 | そのまま |
| ドメイン設定 | そのまま |
管理画面の「設定」配下にあるものは、基本的にテーマから独立しています。送料や配送プロファイルの設計を作り込んでいるストアでも、テーマ変更でそこが崩れることはありません。
注意点が1つあります。メタフィールドの「値」は残りますが、その値を画面に出しているのはテーマ側のLiquidです。商品ページに独自の仕様表をメタフィールドで組んでいた場合、データは無事でも表示は消えます。メタオブジェクトを使ったコンテンツ管理をしているストアほど、この復旧に時間がかかります。
消えるもの
ここからが本題です。
1. セクションの配置と設定値
トップページに「スライドショー → 特集コレクション → 画像とテキスト → 商品一覧 → メールフォーム」と並べていたとします。この並び順、各セクションに入れた見出し・本文・画像・リンク先・表示件数・配色設定——これらは全部テーマに紐付いて保存されています。
Shopifyはテーマごとに templates/index.json のようなファイルで「どのセクションをどの順で、どの設定値で置くか」を持っています。テーマAとテーマBではセクションの名前も設定項目も違うので、機械的に移す仕組みが存在しません。
商品ページ、コレクションページ、固定ページのテンプレートも同じです。カスタムテンプレートを複数作って商品ごとに割り当てていた場合、その割り当て自体も作り直しになります。
2. カスタマイズしたコード
コードエディタで直接触った部分は、当然ながら新しいテーマには引き継がれません。よくあるのは次のあたりです。
- 商品ページに独自のタブやアコーディオンを追加した
- カート内で「あと◯円で送料無料」を出すJSを書いた
theme.liquidに計測タグや構造化データを直接書いた- 独自セクションを
sections/に追加した - CSSを追記してデザインを微調整した
特に厄介なのが3つ目です。theme.liquid に書いたGTMやGA4のタグ、Meta Pixel、独自の構造化データ。これらは目に見えないので、切り替え後に計測が止まっていることにしばらく気づかないという事故が起きます。
3. アプリのテーマへの埋め込み
アプリ本体とアプリ側のデータは消えません。しかしアプリの「表示」はテーマ側に埋め込まれているので、テーマを変えると出なくなります。
| アプリの種類 | テーマ変更でどうなるか |
|---|---|
| アプリブロック対応（Online Store 2.0） | セクションへの配置が消える。再配置すれば復活 |
| アプリ埋め込み（theme app extension） | テーマ設定で再度有効化が必要 |
| テーマに直接コードを注入する旧型 | 手作業でコードを入れ直す。アプリによっては再インストールが必要 |
レビューアプリ、レコメンド、定期購入、ポイント、多言語、サイズガイド、FAQ——このあたりは軒並み該当します。特に古いアプリはテーマファイルにコードスニペットを直接書き込む方式のものがあり、新テーマでは同じ場所が存在しないため、どこに入れるかの判断から必要になります。
4. 翻訳・文言の上書き
テーマの「言語を編集」で変えた文言（「カートに追加」を「購入する」にした等）は、テーマに紐付いています。細かく詰めていたストアほど、切り替え後に英語や直訳日本語が顔を出します。
5. テーマ設定
色、フォント、角丸の大きさ、ボタンのスタイル、余白設定。テーマごとに設定項目の構造が違うため、値をコピーできません。ブランドカラーのカラーコードくらいは手元にあるはずですが、「どこをどの色にしていたか」の対応表は自分で作る必要があります。
アプリの埋め込みが一番やっかいな理由
テーマ変更の見積もりで、経験の浅い担当者が一番読み違えるのがこの部分です。セクションの再構築は「手間はかかるが、見ればわかる」作業ですが、アプリの埋め込みは見てもわからないことが多いためです。
なぜ「見てもわからない」のか
現行テーマでレビューが表示されているとします。この表示が実現している経路は、少なくとも3通りあります。
経路によって、新テーマでの復旧手順がまったく違います。Aなら数分、Bならコードの場所を特定して移植、Cならアプリの設定画面で再設定。そしてこの判別は、テーマのコードを実際に見ないとできません。
見分け方は次の順で辿るのが早道です。まずテーマカスタマイザーを開き、該当セクションにアプリブロックが並んでいればA。無ければテーマファイルをダウンロードして、アプリ名やアプリのドメインで全文検索する。ヒットすればBで、そのファイルパスと行の前後を記録します。どちらも空振りならCで、これはアプリの管理画面側に設定が残っているタイプです。この3分岐を全アプリぶん埋めると、復旧手順がそのまま出来上がります。
解約したアプリの残骸も出てくる
もう一つ、テーマ変更のタイミングで初めて発覚するのが「過去に解約したアプリの残骸」です。
コードを直接注入するタイプのアプリは、アンインストールしてもテーマ側のコードが残ることがあります。呼び出し先のスクリプトが存在しないので表示上は何も起きませんが、読み込みエラーだけは発生し続けている。テーマ変更で既存テーマのコードを精査すると、こうした動いていないコードがまとめて見つかります。
これは裏を返せば、テーマ変更は溜まった負債を清算する良い機会でもあります。
月額の積み上がりを見直すタイミングでもある
テーマを変えるときは、全アプリの棚卸しが必然的に発生します。「このアプリ、何のために入れたんだっけ」が出てくるのがこの工程です。
アプリの月額は、無料枠のあるものから継続的な課金が発生するものまで幅があります。1本ずつは小さく見えても、本数が増えると年間では無視できない額になります。テーマ変更で全部を入れ直すなら、入れ直さないという選択肢もその場で検討できます。
なお、各アプリの最新の料金・プラン内容は変動するため、必ず各アプリのShopify App Storeページで確認してください。記事や過去の見積もりの数字をそのまま使うと、計算が合わなくなります。
「アプリで足りる/テーマ改修が必要」の線引き
入れ直すか自前で作るかの判断軸を、条件で整理します。
| 条件 | 妥当な選択 |
|---|---|
| 外部サービスとのデータ連携が必要（レビュー収集、定期課金、在庫同期） | アプリ。自前で作ると運用が破綻する |
| 管理画面から非エンジニアが日常的に内容を更新する | アプリ、またはセクション設定として実装 |
| 表示の出し分けだけ（タグで表示切替、バッジ、ラベル） | テーマ改修。アプリを1本増やす価値が薄い |
| ブラウザ内で完結する（お気に入り、直近見た商品） | テーマ改修で足りることが多い |
| 要件が自社独自で、既存アプリが部分的にしか合わない | テーマ改修。アプリを無理に曲げると次の改修が詰む |
自社でストアを運用していて実感するのは、「アプリでおおよそ解決できるが、一部が合わない」という状態が一番コストが高いということです。月額を払い続けながら、合わない部分を埋めるためにテーマ側にもコードを書くことになり、テーマ変更時には両方を引き継ぐ羽目になります。
変える前に残しておく記録
ここが本題の実務部分です。テーマ変更の失敗は、ほぼ全部「変える前に記録を取らなかった」ことに起因します。新テーマを公開したあとで旧テーマの設定を思い出すのは、想像よりはるかに難しい作業です。
現行テーマは絶対に消さない
大前提です。新テーマを公開しても、旧テーマはライブラリに残したまま何ヶ月か置いておきます。テーマライブラリには保存できる本数の上限があり、上限に達すると削除を求められますが、そのときは旧テーマではなく、もっと古い世代や試作で作ったテーマから消してください。
旧テーマが残っていれば、「あの設定どうなってたっけ」をプレビューで確認できます。これが最強の記録です。
テーマファイルをローカルに落とす
管理画面の「アクション → テーマをダウンロード」で、テーマ一式をZIPで取得できます。メール経由でダウンロードリンクが届く形式です。Shopify CLIが使える環境なら shopify theme pull でも同じことができます。
これをやっておくと、カスタマイズしたコードを後から検索できます。「GTMのコードどこに入れたっけ」がgrep一発で分かる状態は、切り替え作業の工数を大幅に下げます。
検索するキーワードを先に決めておくと、洗い出しが機械的に終わります。gtag、GTM-、fbq、dataLayer、application/ld+json、<script src=、各アプリのドメイン名。この7つを全文検索するだけで、テーマに手書きで埋まっているものはほぼ拾えます。
記録すべき5項目
1と2はすぐできます。工数がかかるのは3〜5で、しかしここを省くと後で必ず詰まります。
3. セクション構成の一覧
テーマカスタマイザーを開いて、ページごとに左側のセクション一覧をスクリーンショットで撮ります。加えて、各セクションを開いて設定値も撮る。地味ですが、これがそのまま新テーマの組み立て手順書になります。
対象にするテンプレートは最低でもこの範囲です。
- トップページ
- 商品ページ（カスタムテンプレートを作っていれば全種類）
- コレクションページ（同上）
- カートページ
- 固定ページ（テンプレート違いがあれば全種類）
- ブログ一覧・記事ページ
- 404ページ
- ヘッダー・フッター（全ページ共通なので必ず）
- パスワードページ（使っていれば）
4. カスタム改修の棚卸し
ダウンロードしたテーマファイルから、手を入れた箇所を洗い出します。制作会社が入っている場合は、改修履歴を出してもらうのが早道です。
洗い出しでよく見落とされるのがこのあたりです。
theme.liquidの<head>内（計測タグ、フォント読み込み、構造化データ）theme.liquidの</body>直前（チャットツール、遅延読み込みするJS）snippets/に追加した独自ファイルassets/に追加したCSS/JS/画像layout/password.liquid（パスワードページを触っていれば）config/settings_data.json（テーマ設定の値そのもの。新テーマでは使えないが、色やフォントの元データとして参照できる）
なお、注文確認メールなどの通知メールテンプレートは「設定 → 通知」にあり、テーマとは独立しています。テーマを変えてもそのまま残るので安心してください。
5. アプリと表示箇所の対応表
インストール済みアプリを全部リストアップし、それぞれ「ストアのどこに何が表示されているか」を書き出します。
| アプリ名 | 表示場所 | 実装方式 | 新テーマでの対応 |
|---|---|---|---|
| （レビュー系） | 商品ページ下部、トップの星評価 | アプリブロック | 再配置 |
| （多言語） | ヘッダーの言語切替 | アプリ埋め込み | テーマ設定で有効化 |
| （サイズガイド） | 商品ページのボタン | コード注入 | 要調査・移植 |
「実装方式」の欄を埋めるには、テーマのコードを見るかアプリのドキュメントを読む必要があります。ここを埋めた時点で、テーマ変更の工数の半分は見えます。
計測タグは別枠でチェックリストを作る
繰り返しますが、切り替え事故で一番痛いのが計測の断絶です。売上への影響が即座には見えず、広告の最適化が静かに壊れます。
移行前に、次を一覧化しておいてください。
- GA4の測定ID / GTMのコンテナID
- Meta Pixel ID、その他の広告タグ
- Search Consoleの所有権確認方法（HTMLタグ方式ならテーマに入っている）
- ヒートマップ・レコーディング系ツールのタグ
- Shopifyの「カスタムピクセル」に入れているもの（※これは設定側なのでテーマ変更の影響を受けない）
新テーマ公開後は、必ず実際にテスト注文を通して、購入完了まで計測が飛ぶか確認します。表示されているかどうかだけでは判断できません。
切り替えの進め方：公開までの手順
記録が取れたら、実作業です。安全に進める順番を示します。
ステップ1〜2で気をつけること
新テーマは「テーマライブラリに追加」した状態で作業します。この状態ならライブストアには一切影響しません。
作業順はヘッダー・フッター → トップ → 商品ページ → その他を推奨します。ヘッダーとフッターは全ページに関わるので、ここを先に固めないと他のページの見え方が判断できません。
ステップ3の検証項目
プレビューでの確認は、「見た目が合っているか」だけでは不十分です。最低限このリストを通してください。
| 確認項目 | 何を見るか |
|---|---|
| カート追加 | バリエーション選択も含めて実際に追加できるか |
| カート内の数量変更・削除 | JSが正しく動いているか |
| 検索 | 予測検索の候補が出るか、結果ページが崩れていないか |
| 絞り込み | コレクションのフィルターが機能するか |
| 会員ログイン | ログイン・新規登録・パスワード再設定 |
| フォーム | 問い合わせ、メルマガ登録 |
| 外部リンク | SNS、特商法ページなどフッター系 |
| スマホ実機 | エミュレータではなく実機。ハンバーガーメニュー、横スクロール |
| 表示速度 | 旧テーマと比較して極端に落ちていないか |
予測検索や絞り込みは、テーマによって挙動と見た目がかなり違います。旧テーマで細かく調整していた場合、同じ体験を新テーマで再現するには追加の改修が要ります。
在庫切れ商品、バリエーションが1種類しかない商品、画像が1枚しかない商品、説明文が極端に長い商品。プレビューで見る商品は、きれいな1点だけで済ませないでください。 崩れるのはいつも例外側のデータです。コレクションも同じで、商品数が少ないもの・多いもの・空のものをそれぞれ開いて確認します。
ステップ4〜5：公開とその後
公開はアクセスの少ない時間帯に行います。深夜である必要はありませんが、セール中やメルマガ配信直後は避けてください。
公開直後にやることは決まっています。
- 実際にテスト注文を1本通す（決済まで。テストモードでなくても、後でキャンセル・返金すればよい）
- GA4のリアルタイムレポートで、ページビューとイベントが飛んでいるか確認
- スマホの実機で主要導線をひと通り触る
- Search Consoleで、公開翌日にクロールエラーが増えていないか確認
公開してから数日は、問い合わせフォームからの着信が普段どおりあるかも見ておきます。フォームが壊れていても画面上はエラーが出ないことがあり、「最近問い合わせが少ない」という形でしか表面化しません。
そして旧テーマは消さない。ここまで来ても、まだ消しません。
テーマ変更のついでに考えたい構造の話
テーマを変えるという判断は、実はストア全体の構造を見直す数少ないタイミングです。どうせ全部を作り直すなら、いま抱えている構造的な問題も一緒に解決できます。
「サイトが2つある」状態の解消
Shopifyで運営していて、別途WordPressのコーポレートサイトを持っている事業者は少なくありません。この状態だと、更新も費用も2系統に分かれます。テーマを変えるタイミングは、これを1つに寄せるかどうかを検討する好機です。
アプリを減らす判断をするなら今
先述のとおり、テーマ変更時はアプリの再設定が必要です。入れ直す手間がかかる以上、入れ直さない判断もこのタイミングでしかできません。
自前実装に置き換えやすいのは、外部とデータをやり取りしない機能です。ブラウザのlocalStorageで完結するお気に入り機能などは、アプリを1本減らせる典型例です。
ただし、全部を自前にすればいいわけではありません。判断軸は前述の表のとおりで、運用する人が管理画面から触れるかどうかが最大の分かれ目です。制作会社しか触れない仕組みを増やすと、日々の運用が止まります。
テーマを選ぶときに見る箇所
最後に、新しいテーマを選ぶ際の判断軸です。デザインの好みだけで選ぶと、切り替え後に苦労します。
| 見る箇所 | 何を判断するか |
|---|---|
| 最終更新日 | 直近1年以内に更新されているか。止まっているテーマは今後のShopify仕様変更に追従しない |
| セクション構成の柔軟性 | 必要なセクションが標準で揃っているか。無いものは全部改修工数になる |
| 日本語表示 | デモではなく、実際に日本語を入れてみる。行間・禁則・フォント指定が日本語向きか |
| アプリブロック対応 | Online Store 2.0対応か。非対応だとアプリの埋め込みが手作業になる |
| サポート体制 | 有料テーマなら、日本語で問い合わせできるか。返答までの目安期間 |
| 表示速度 | デモストアで実測する。重いテーマは改修しても軽くならない |
| 既存の改修との相性 | いま入れている改修が、新テーマの構造でも同じように作れるか |
一番見落とされるのが最後の行です。テーマによってはカート周りの実装方式が根本的に違い、旧テーマで動いていたJSがまったく使えないことがあります。改修が多いストアほど、テーマ選定の段階で技術的な相性を確認すべきです。
無料テーマ（Dawnなど）を選ぶ利点は、Shopify公式が継続的に更新し、仕様変更への追従が最も早いことです。デザインは素朴ですが、そこは改修で作れます。一方、有料テーマは初期状態の完成度が高い代わりに、更新が止まるリスクと、独自構造ゆえの改修のしにくさがあります。
判断の目安
- 改修をほとんど入れず、標準機能で運用したい → 有料テーマの完成度を買う
- 独自の機能・デザインを今後も足していく → 無料テーマ（Dawn等）をベースに作り込む
- 既に大量の改修がある → 移植可能性を技術者に確認してから決める
費用の考え方
テーマ変更にいくらかかるか、という質問には一律の答えがありません。金額を左右するのはストアの規模ではなく、旧テーマにどれだけ改修が積み上がっているかだからです。
費用が膨らむ条件を並べると、見積もりの読み方が分かります。
| 条件 | 費用への効き方 |
|---|---|
| 標準セクションだけで組んでいる | 最も安い。再構築だけで済む |
| カスタムテンプレートが多い | ページ種類ぶんの再構築が必要。点数に比例する |
| テーマ本体に直接手を入れている | 移植の可否調査から必要。見積もり前に調査工程が要る |
| コード注入型のアプリがある | 1本ごとに調査と移植。本数で効く |
| 多言語・通貨を運用している | 翻訳の入れ直しと検証が全言語ぶん発生する |
| デザインも同時に刷新する | テーマ変更ではなくリニューアル。別の工程になる |
見積もりを取るときは、前述の「記録すべき5項目」のうち3〜5を先に自分で作ってから渡してください。 これがあると、制作会社側は調査工程を圧縮でき、見積もりの精度も上がります。逆に、この情報なしで出てきた金額は、調査ぶんのリスクを上乗せした幅の広い数字になります。
よくある質問
テーマを変えると商品データや注文履歴は消えますか？
消えません。商品、在庫、顧客、注文履歴、コレクション、ページの本文はすべてストア側に保存されており、テーマとは独立しています。消えるのは「どう表示するか」の部分だけです。ただし表示の設定は移行の仕組みがないため、実質的に作り直しになります。
現在のテーマ設定を新しいテーマにコピーできますか？
できません。テーマごとにセクション名も設定項目も異なるため、Shopifyには設定を移行する機能がありません。同じテーマの別バージョンへの更新であれば設定が引き継がれる場合がありますが、別テーマへの変更では手作業での再構築になります。事前にスクリーンショットで記録を残してください。
テーマを変えるとSEOに影響はありますか？
URL構造は変わらないため、そこは影響しません。影響するのは見出し構造、内部リンク、構造化データ、画像のalt、表示速度です。旧テーマに手書きで入れていた構造化データは消えるので、移行前に確認が必要です。公開後はSearch Consoleでクロールエラーと表示速度を確認してください。
旧テーマはいつ削除していいですか？
最低でも新テーマの公開から2〜3ヶ月は残してください。「あの設定どうなっていたか」を確認する手段として旧テーマのプレビューが最も確実です。加えて、テーマファイルのZIPをローカルに保管しておけば、テーマライブラリから消しても中身は参照できます。
アプリはテーマ変更のたびに再インストールが必要ですか？
多くの場合は不要です。アプリ本体とデータは残るため、必要なのは「新テーマへの表示の再設定」です。ただし、テーマにコードを直接注入する旧型のアプリは、再インストールやサポートへの依頼が必要になることがあります。アプリごとのドキュメントで確認してください。
テーマ変更の作業はどれくらいの期間がかかりますか？
一律には言えませんが、期間を決めるのは記録した改修とアプリの点数です。標準セクションだけで組んだストアなら再構築と検証で収まり、カスタムテンプレートやコード注入型アプリが多いほど、調査と移植の工程が積み上がります。まず「記録すべき5項目」の3〜5を作り、移植対象の点数を数えてから期間を見積もってください。点数が出る前のスケジュールは、ほぼ外れます。
まとめ
Shopifyのテーマ変更で押さえるべき点を整理します。
- 消えないもの：商品・注文・顧客・ページ本文・設定類。ストアデータ層は無傷
- 消えるもの：セクション配置と設定値、カスタマイズしたコード、アプリの表示、翻訳の上書き、テーマ設定
- 一番危険なのは計測タグ。
theme.liquidに手書きしたものは静かに消えるので、移行前にIDを一覧化する - やることは記録が9割。スクショ、テーマZIP、セクション構成、改修の棚卸し、アプリの対応表。この5つを作れば工数が見える
- 旧テーマは消さない。新テーマ公開後も2〜3ヶ月は残す
- アプリを減らす判断ができる唯一のタイミング。どうせ入れ直すなら、入れ直さない選択も検討する
- 新テーマでは改修を独立させる。本体ファイルを直接書き換えない方針にしておけば、次のアップデートで同じ苦労をしない
テーマ変更は「デザインを変える作業」ではなく、ストアの構造を一度分解して組み直す作業です。そう捉えて記録から始めれば、想定外の事故はほぼ防げます。逆に記録を飛ばして走ると、公開後に何が壊れたのかすら分からなくなります。
急いでいる場合ほど、記録の工程は削らないでください。ここを削って得られる時間より、後で失う時間のほうが確実に大きくなります。
