この記事の対象: Shopifyテーマを直接編集していて、事故が怖くなってきた制作者
読了時間: 約12分
Shopifyのテーマを管理画面のコードエディタで直接編集していると、保存した瞬間に本番へ反映されます。カートのボタンが消えた、商品ページが真っ白になった、という事故はここから起きます。しかもShopifyのコードエディタには、ファイル単位の履歴はあってもテーマ全体を丸ごと巻き戻す仕組みがありません。
この記事では、複製テーマとShopify CLIを使ってローカルに開発環境を作り、確認してから公開するまでの手順を、コマンドとファイルパスつきで通します。CLIのバージョンで変わる箇所には、その場で確認する方法も添えました。
前提と必要な権限を先に確認する
手を動かす前に、環境と権限を揃えます。ここが揃っていないと途中で止まります。
対象テーマの前提
この記事は Online Store 2.0 のテーマ を対象にしています。判定は簡単で、テーマのファイル構成に templates/*.json と sections/ があり、config/settings_schema.json が存在すればOS 2.0です。旧来の templates/product.liquid のようにLiquidテンプレートが直に置かれている（Vintageテーマ）場合、セクションの追加やJSONテンプレートの扱いが異なるため、この記事の手順のうちCLI関連はそのまま使えますが、テンプレート編集の部分は読み替えが必要です。
必要なもの
| 項目 | 条件 | 確認方法 |
|---|---|---|
| Node.js | LTS版（CLIが要求する下限は公式ドキュメントで確認） | node -v |
| Shopify CLI | 3.x 系 | shopify version |
| ストア権限 | テーマの編集・作成権限を持つスタッフアカウント | 管理画面 → 設定 → ユーザー |
| Git | 任意だが強く推奨 | git --version |
Node.jsの必要バージョンはCLIの更新で上がります。インストール時にバージョン不足のエラーが出たら、その場でメッセージに書かれた下限に合わせてください。
CLIのインストールはnpm経由が扱いやすいです。
# グローバルにインストール
npm install -g @shopify/cli
# バージョン確認（3.x であること）
shopify version
Homebrewを使っている環境ではこちらでも入ります。
brew tap shopify/shopify
brew install shopify-cli
shopify version
CLIのメジャーバージョンによってコマンド体系が変わっています。3.x 未満では shopify theme dev ではなく古い呼び方になるため、shopify version が 3 から始まらない場合はアップデートしてください。
npm install -g @shopify/cli@latest
権限で引っかかる場合
コラボレーターアカウントでは、テーマの編集権限が個別に割り当てられていないと shopify theme pull が失敗します。ストアオーナーに「テーマ」の権限付与を依頼してください。上位プランのストアではユーザー権限がさらに細かく分かれていることがあるので、失敗したら「何の権限が足りないのか」を管理画面のユーザー設定で一緒に確認するのが早道です。
管理画面での直接編集をやめる理由
「1行だけだから」と管理画面のコードエディタで直すのが、いちばん多い事故の入口です。何が危ないのかを具体的に並べます。
保存＝即公開になっている
コードエディタの「保存」は、公開中テーマに対しては本番反映と同義です。プレビューも確認もありません。閲覧者がちょうどその瞬間にページを開いていれば、壊れた状態を見ます。
巻き戻しが部分的にしかできない
Shopifyには編集履歴の機能があり、ファイル単位で以前の版に戻せます。ただし、
- 複数ファイルをまたいだ変更をまとめて戻すことはできない
- 履歴には保持の範囲があり、古い版は残らない
templates/*.json（セクションの配置と設定を持つファイル）は、テーマエディタでの操作でも中身が書き換わるため、コード編集と操作の履歴が混ざる
つまり「昨日の朝の状態に丸ごと戻す」ができません。
誰が何を変えたか残らない
制作者が複数いる案件や、クライアント側の担当者もエディタを触る案件では、変更の理由が一切残りません。数ヶ月後に「このCSS、なぜこう書いた？」を追う手段がなくなります。
複製テーマ＋CLI
- 作業中は誰にも見えない
- Gitで差分と理由が残る
- 戻すのは公開テーマの切り替えだけ
- プレビューURLで事前確認できる
管理画面で直接編集
- 保存した瞬間に本番反映
- まとめて巻き戻せない
- 変更の理由が残らない
- 複数人だと上書きが起きる
右側の項目は、どれも「壊してから気づく」形になっています。左側に移すだけで、壊れる場所が本番から手元に移動します。
Shopify CLIで開発環境をローカルに作る
ここから実作業です。空のディレクトリを用意して進めてください。
ストアに接続してテーマを取得する
# 作業ディレクトリを作る
mkdir -p ~/work/mystore-theme
cd ~/work/mystore-theme
# ストアにログイン（ブラウザが開く）
shopify auth login --store your-store.myshopify.com
your-store.myshopify.com は自分のストアの .myshopify.com ドメインに置き換えてください。独自ドメイン（例：shop.example.com）ではなく、管理画面のURLに出ている方です。管理画面 → 設定 → ドメイン で確認できます。
次に、公開中テーマを手元へ落とします。
# 公開中テーマを取得
shopify theme pull --store your-store.myshopify.com --live
特定のテーマを指定したいときは、まず一覧を出します。
shopify theme list --store your-store.myshopify.com
出力にテーマIDが並ぶので、IDを指定します。
shopify theme pull --store your-store.myshopify.com --theme 123456789012
123456789012 は自分のストアのテーマIDに差し替えてください。
取得直後にGitで初期化する
pullが終わったら、何も変更しないうちにコミットします。この「触る前の状態」があるかどうかで、後の安心感がまるで違います。
git init
git add -A
git commit -m "chore: 公開中テーマの取得時点"
.gitignore はテーマ直下に置きます。
ファイルパス: .gitignore（テーマのルート）
# Shopify CLI
.shopify/
node_modules/
# OS
.DS_Store
Thumbs.db
# エディタ
.vscode/
.idea/
# 環境変数
.env
.env.*
.shopify/ にはCLIが作るローカルの状態ファイルが入ります。コミットすると他の担当者の環境と衝突するため除外します。
ローカルプレビューを起動する
shopify theme dev --store your-store.myshopify.com
起動すると http://127.0.0.1:9292 が案内されます。ここで開くのは、手元のファイルをストアのデータ（商品・コレクション・顧客）と組み合わせてレンダリングした画面です。ファイルを保存すると自動でリロードされます。
theme dev は裏で開発用テーマ（Development theme）をストアに作ります。テーマ一覧に見慣れない名前が出ますが、これは一時的なもので、一定期間アクセスがないと自動的に消えます。公開テーマには影響しません。
ポートを変えたいときは指定できます。
shopify theme dev --store your-store.myshopify.com --port 9393
CSSやJSの変更が反映されないとき
theme dev はファイル変更を検知して同期しますが、assets/ 配下のファイルはブラウザキャッシュが効くことがあります。開発者ツールを開いて「キャッシュを無効化」にチェックを入れるか、スーパーリロード（Windowsは Ctrl + Shift + R、Macは Cmd + Shift + R）を使ってください。
複製テーマで作業して、公開は切り替えだけにする
theme dev は開発中の確認用です。クライアントに見せる・複数人で確認する段階では、ストア上に複製テーマを置きます。
複製テーマを作る
管理画面からでも作れますが、CLIで作ったほうが名前を制御できて確実です。
# 手元のファイルを、新しい未公開テーマとして push する
shopify theme push --store your-store.myshopify.com --unpublished --theme-name "作業用_20260907_商品ページ改修"
--unpublished を付けると未公開テーマとして作られます。--theme-name の中身は、自分の案件に合わせて変えてください。日付と作業内容を入れておくと、テーマ一覧が増えたときに助かります（ストアが保持できるテーマ数には上限があるため、増えすぎたら古いものを削除します）。
pushが終わると、プレビューURLが出力されます。形式はこうなります。
https://your-store.myshopify.com/?preview_theme_id=123456789012
このURLはパスワードのかかっていない公開ストアなら誰でも開けます。クライアント確認に使えますが、逆に言えばURLを知っていれば見られるということです。未公開の施策を載せている場合は、共有範囲に注意してください。
2回目以降のpushは差分を確認してから
shopify theme push は、指定しないと全ファイルを上書きします。テーマエディタ側でクライアントが設定を変えていた場合、その変更が消えます。
# 何が変わるかだけ見る（実際には送らない）
shopify theme push --store your-store.myshopify.com --theme 123456789012 --dry-run
--dry-run オプションはCLIのバージョンによって挙動が異なることがあります。手元で shopify theme push --help を実行して、使えるオプションを必ず確認してください。使えない場合は、次の「特定ファイルだけ送る」方法を使います。
# 触ったファイルだけ送る
shopify theme push \
--store your-store.myshopify.com \
--theme 123456789012 \
--only sections/main-product.liquid \
--only assets/custom.css
--only は複数指定できます。ここで指定しているファイル名は例なので、自分が編集したファイルに差し替えてください。
テンプレートJSONは原則pushしない
templates/*.json と config/settings_data.json は、テーマエディタでの操作結果が保存されるファイルです。ここをローカルからpushすると、クライアントがテーマエディタで組んだレイアウトが手元の古い状態に戻ります。
pushから除外する運用にするなら、こう書きます。
shopify theme push \
--store your-store.myshopify.com \
--theme 123456789012 \
--ignore "templates/*.json" \
--ignore "config/settings_data.json"
新しくセクションを追加してテンプレートへの配置も必要な場合は、pushで送るのではなく、テーマエディタ側で追加してもらってから shopify theme pull で手元に取り込むほうが安全です。
この順序を守ると、「開発者はコードを持ち、クライアントは配置を持つ」という分担が崩れません。逆にやると、クライアントが半日かけて組んだトップページが一瞬で消えます。復旧手段はテーマエディタの操作履歴しかなく、確実に戻せる保証はありません。
公開への切り替え
確認が終わったら、複製テーマを公開に切り替えます。ここが唯一「本番が変わる」瞬間です。
公開の直前に、いま動いている公開テーマを手元に落として残しておきます。これが戻り先になります。
# 現在の公開テーマを手元に落として保存（戻り先のバックアップ）
mkdir -p ../backup-live-20260907
shopify theme pull --store your-store.myshopify.com --live --path ../backup-live-20260907
あわせて、公開中テーマのIDを控えておきます。切り替えたあとは「どれが元のテーマだったか」が一覧から読み取りにくくなるためです。
shopify theme list --store your-store.myshopify.com
そのうえで切り替えます。
shopify theme publish --store your-store.myshopify.com --theme 123456789012
切り替え後に問題が見つかったら、控えておいた元のテーマIDを指定して同じコマンドを打つだけで戻ります。ファイルを直す必要はありません。これが複製テーマ運用のいちばんの利点です。
# 元のテーマに戻す
shopify theme publish --store your-store.myshopify.com --theme 999999999999
切り戻しにかかる時間は、コマンド1本ぶんです。「原因を調べてから直す」ではなく「先に戻してから原因を調べる」ができる状態を作るのが、この運用の目的になります。
戻せる状態を保つ運用ルール
仕組みだけ作っても、運用が緩いと結局壊れます。決めておくと事故が減るルールを挙げます。
テーマの命名を統一する
テーマ一覧が「Dawnのコピー」「Dawnのコピーのコピー」で埋まると、どれが何なのか誰にもわかりません。命名は3要素で固定します。
| 要素 | 例 | 理由 |
|---|---|---|
| 状態 | [LIVE] [作業用] [退避] |
一覧で役割が即座にわかる |
| 日付 | 20260907 |
新旧の判断がつく |
| 内容 | 商品ページ改修 |
何のためのテーマか残る |
つなげると [作業用]20260907_商品ページ改修 になります。
公開テーマを直接pushしない
CLIを使っていても、--theme に公開中テーマのIDを指定すれば本番が即座に変わります。管理画面で編集するのと同じ危険です。ルールとして「公開中テーマのIDをpush先に書かない」を徹底してください。
安全策として、公開テーマへのpushを止めるラッパースクリプトを置けます。
ファイルパス: bin/safe-push.sh（テーマのルートに bin/ を作る）
#!/usr/bin/env bash
set -euo pipefail
STORE="your-store.myshopify.com"
TARGET_THEME="${1:-}"
if [ -z "$TARGET_THEME" ]; then
echo "使い方: ./bin/safe-push.sh <テーマID>"
exit 1
fi
# 公開中テーマのIDを取得
LIVE_ID=$(shopify theme list --store "$STORE" --json \
| python3 -c "import sys,json; print(next((t['id'] for t in json.load(sys.stdin) if t.get('role')=='main'), ''))")
if [ -z "$LIVE_ID" ]; then
echo "公開中テーマの判定に失敗しました。手動で確認してください。"
exit 1
fi
if [ "$TARGET_THEME" = "$LIVE_ID" ]; then
echo "指定されたテーマ $TARGET_THEME は公開中です。push を中止します。"
exit 1
fi
echo "公開中テーマ: $LIVE_ID / 送信先: $TARGET_THEME"
shopify theme push --store "$STORE" --theme "$TARGET_THEME"
STORE の値を自分のストアに書き換えてから、実行権限を付けます。
chmod +x bin/safe-push.sh
./bin/safe-push.sh 123456789012
shopify theme list --json の出力形式はCLIのバージョンで変わる可能性があります。初回は shopify theme list --store your-store.myshopify.com --json を単体で実行し、role というキーで公開中テーマが main と表現されているかを目視で確かめてください。キー名が違っていたらスクリプト内のPython行を合わせて直します。
判定に失敗したときにpushを止める（exit 1 で抜ける）作りにしてある点が重要です。「判定できなかったから、とりあえず送る」にすると、安全装置の意味がなくなります。
変更内容をコミットメッセージに残す
Gitのコミットは、後から自分を助けるためのメモです。
git add sections/main-product.liquid assets/custom.css
git commit -m "feat(product): 商品ページに配送目安の表示を追加
- sections/main-product.liquid に配送目安ブロックを追加
- ブロックの表示切替はテーマエディタの設定で行う
- assets/custom.css に .ts-delivery-note を追加"
「何を」だけでなく「なぜ」を1行入れておくと、半年後の自分が読めます。
Dawn本体のファイルを直接書き換えない
Dawnや購入したテーマをベースにする場合、本体のCSSやJSに手を入れると、テーマのアップデートで上書きされます。追加分は自分のファイルに分けます。
ファイルパス: assets/custom.css（新規作成）
/* 独自スタイルはこのファイルにまとめる。
クラス名の接頭辞を付けてテーマ本体との衝突を防ぐ。
ts- の部分は自分のプロジェクト名の略称に変えてよい。 */
.ts-delivery-note {
margin-block-start: 1.2rem;
padding: 0.9rem 1.1rem;
border: 1px solid rgb(var(--color-foreground) / 0.16);
border-radius: 0.4rem;
font-size: 1.4rem;
line-height: 1.7;
}
.ts-delivery-note__label {
display: block;
margin-block-end: 0.3rem;
font-weight: 600;
}
--color-foreground はDawn系テーマが定義しているCSS変数です。別のテーマを使っている場合はこの変数が存在しないので、#333 のような具体的な値に置き換えるか、そのテーマの変数名を config/settings_schema.json と assets/base.css で確認してください。
読み込みは layout/theme.liquid に1行追加します。
ファイルパス: layout/theme.liquid（</head> の直前）
{{ 'custom.css' | asset_url | stylesheet_tag }}
外部のCSSフレームワークを追加読み込みするより、必要な数十行を自分で書いたほうが表示は速く、テーマ更新時の衝突も起きません。
Shopifyのセクション実装をもう少し踏み込んで見たい場合は、ライブラリを使わずに組む例をこちらにまとめています。
複数人・複数環境で作業するときの追加ルール
ひとりで作業しているうちは事故が起きても自分で気づけますが、人数が増えると事情が変わります。
同じテーマIDに複数人でpushしない
CLIは「誰が先にpushしたか」を管理しません。AさんとBさんが同じ複製テーマにpushすると、後から送ったほうが前の変更を消します。
対策は2つです。
- 担当ファイルを分ける：セクションごとに担当を決め、
--onlyで自分のファイルだけ送る - 作業テーマを分ける：各自が自分の複製テーマを持ち、Gitでマージしてから代表者が1つのテーマへ送る
案件の規模が小さければ前者、3人以上なら後者が現実的です。前者を選ぶ場合でも、layout/theme.liquid と config/settings_schema.json のように全員が触りたくなるファイルだけは、誰か1人の担当に固定してください。ここが共有されていると、--only を守っていても衝突します。
環境変数でストア名を持たせる
コマンドに毎回ストア名を書くのは、打ち間違いの原因になります。テーマのルートに設定ファイルを置けます。
ファイルパス: shopify.theme.toml（テーマのルート）
[environments.development]
store = "your-store.myshopify.com"
theme = "123456789012"
ignore = ["templates/*.json", "config/settings_data.json"]
[environments.staging]
store = "your-store.myshopify.com"
theme = "234567890123"
ignore = ["config/settings_data.json"]
store と theme は自分のストア・テーマIDに差し替えてください。これを置くと、環境名を指定するだけで済みます。
shopify theme dev -e development
shopify theme push -e staging
この設定ファイルの形式はCLI 3.x 系で使えます。使えないバージョンではエラーになるので、shopify theme push --help で -e / --environment オプションの有無を確かめてください。ファイル自体はGitにコミットして構いませんが、公開テーマのIDは書かないでください。書いてしまうと、うっかり -e で本番に送る事故が起きます。
検証用に別ストアを持つ
大きな改修や、アプリの追加を伴う変更は、開発ストア（Development store）で先に試します。Shopifyパートナーアカウントがあれば作成でき、追加の利用料はかかりません。本番ストアの商品データが必要な場合は、CSVエクスポート／インポートで最小限を移せば十分検証できます。
ただし開発ストアには制限があり、決済まわりの挙動は本番と完全には一致しません。カートやチェックアウトに関わる改修は、開発ストアで構造を確認したうえで、最終確認は本番ストアの未公開テーマのプレビューで行ってください。
計測タグの設置を伴う改修では、テーマの切り替えでタグが外れることがあります。公開前後で計測が動いているかまで確認する運用にしておくと安心です。
公開前チェックリスト
切り替えボタンを押す前に、この順で確認します。全部で5分もかかりません。
| # | 確認項目 | 見る場所 |
|---|---|---|
| 1 | 商品ページのカートに入れるが動く | プレビューURL＋実機 |
| 2 | カート→チェックアウトへ進める | プレビューURL |
| 3 | スマホ幅で崩れていない | 実機 or 開発者ツール |
| 4 | 検索・コレクション絞り込みが動く | プレビューURL |
| 5 | コンソールにJSエラーが出ていない | 開発者ツール Console |
| 6 | 現在の公開テーマを手元に保存済み | ローカルのバックアップ |
| 7 | 公開中テーマのIDを控えてある | shopify theme list の出力 |
特に2番目は忘れがちです。テーマのJSを触るとカートのAjax処理が壊れることがあり、商品ページだけ見ていると気づきません。
プレビューURLの落とし穴
?preview_theme_id= を付けたURLでサイトを見ていると、ページ内リンクをたどってもプレビューが維持されます。ただし、
- 別タブで開き直すとプレビューが切れて公開テーマに戻る
- ブラウザのキャッシュが効いて古いHTMLが返ることがある
「直したのに変わらない」と思ったら、URLに ?preview_theme_id= が付いたままか、シークレットウィンドウで開き直して確かめてください。クライアントから「変わっていない」と言われたときも、まずここを疑うと早く片付きます。
ブログ周りを触ったときは、記事一覧と記事詳細の両方を見ます。一覧のカード表示だけ直して詳細ページが崩れているケースが多いためです。
うまくいかないとき
shopify theme pull で認証エラーになる
ログインセッションが切れている可能性があります。ログアウトしてから入り直してください。
shopify auth logout
shopify auth login --store your-store.myshopify.com
ブラウザが自動で開かない環境（SSH越しの作業など）では、ターミナルに表示されるURLを手元のブラウザにコピーして開きます。
theme dev は起動するが商品が表示されない
ローカルプレビューはストアの実データを参照します。商品が表示されないときは、その商品が「オンラインストア」販売チャネルに公開されているか確認してください。管理画面の商品編集ページ → 販売チャネル で公開状態を見ます。
保存してもブラウザに反映されない
3段階で切り分けます。
- ターミナルに同期のログが出ているか（出ていなければCLIがファイル変更を拾えていない）
- 拾えていないなら、いったん
Ctrl + Cで止めてshopify theme devを起動し直す - 反映されているのに見た目が変わらないなら、ブラウザキャッシュ。スーパーリロード
assets/ 直下でないディレクトリにCSSを置いた場合、Shopifyは配信しません。テーマのアセットは必ず assets/ のフラットな階層に置きます（assets/css/custom.css のようなサブディレクトリは使えません）。
pushしたのにテーマエディタで設定が出てこない
セクションに新しい設定を足したのに、テーマエディタに項目が出ない場合、{% schema %} のJSONに構文エラーがある可能性が高いです。JSONは末尾カンマを許しません。
{% schema %}
{
"name": "配送目安",
"settings": [
{
"type": "text",
"id": "delivery_note",
"label": "配送目安のテキスト",
"default": "ご注文から3〜5営業日で発送します"
}
]
}
{% endschema %}
"settings" 配列の最後の要素の後ろにカンマを置くと、セクション全体が読み込まれません。もうひとつ多いのが id の重複で、同じセクション内で同じ id を2回使うと、後ろの設定だけが表示されないという中途半端な壊れ方をします。どちらも派手なエラーが出ないまま無視されるので、「増やした設定が出ない」と感じたら真っ先にこの2つを疑ってください。
複製テーマとライブテーマで見た目が違う
config/settings_data.json と templates/*.json の中身が違っているのが原因です。これらはテーマエディタでの操作結果なので、複製元が古ければ設定も古いままです。ライブテーマから該当ファイルだけ取り直します。
shopify theme pull \
--store your-store.myshopify.com \
--live \
--only config/settings_data.json \
--only "templates/*.json"
取り直した後、必ずローカルで見た目を確認してから複製テーマへ送ってください。取り直しは手元のファイルを上書きするので、先に git commit を済ませておくと、何が変わったかを git diff で読めます。
アプリが埋め込んだコードが消えた
一部のアプリは、インストール時にテーマファイルへ直接コードを書き込みます（App embed 形式でないアプリ）。複製テーマにはそのコードが入っていないことがあり、公開切り替え後にアプリの機能が消えます。
App embed（テーマエディタの「アプリ埋め込み」）に対応しているアプリなら、テーマごとに有効化する必要があるので、公開前にテーマエディタでオンになっているか確認してください。レビュー表示・チャット・ポップアップなど、画面に何かが出るタイプのアプリは、プレビューURLで実際に表示されるかを目で見るのが確実です。
テーマの上限に達してpushできない
ストアが保持できるテーマ数には上限があります。上限に達すると新しい複製が作れません。古い作業用テーマを削除してください。
shopify theme delete --store your-store.myshopify.com --theme 345678901234
削除は元に戻せません。実行前に shopify theme pull で手元に落としておくか、Gitのブランチとして残しておいてください。
よくある質問
Shopify CLIは無料で使えますか
Shopify CLI自体は無料で公開されているツールです。利用にあたって追加費用は発生しません。ただし操作対象のストアが必要で、ストアのプラン料金は別に発生します。開発ストアはShopifyパートナーアカウントを作れば追加費用なしで用意できます。
管理画面のコードエディタは今後まったく使わないほうがいいですか
緊急時の応急処置には使えます。表示が完全に壊れていて即座に止める必要がある場合、コードエディタで1行コメントアウトするのが最速です。ただしその変更は必ず後からローカルへ shopify theme pull で取り込み、Gitに残してください。手元とストアで中身がずれたまま次の作業に入るのが、いちばん危険な状態です。
Vintage（Online Store 2.0 以前）のテーマでもCLIは使えますか
shopify theme pull / push / dev は使えます。ファイルの同期という点では同じです。違うのはテンプレートの構造で、Vintageテーマには templates/*.json がなく、セクションの配置をテーマエディタで自由に変えられません。この記事のうち「テンプレートJSONをpushしない」という注意はVintageテーマには当てはまりません。
複製テーマを作るとSEOに影響しますか
未公開テーマはプレビューURLでしかアクセスできず、通常の検索エンジンのクロール対象にはなりません。公開テーマを切り替えた場合も、URL構造やコンテンツが変わらなければ影響はありません。ただしテーマ変更に伴ってページ構成や見出し構造を変えた場合は、その変更自体が評価に関わります。
ローカルで作業しても、商品データは本番のものを使いますか
shopify theme dev はストアの実データを参照して画面を描きます。商品・コレクション・顧客データは本番のものです。テーマファイルだけがローカルのものに差し替わる、という理解が正確です。商品の登録内容を変更したい場合は、それは管理画面での操作になり、テーマ開発とは別の作業になります。
開発環境を作るのにどれくらい時間がかかりますか
CLIのインストールと初回ログイン、テーマのpullとGit初期化までで、環境が整っていれば長い作業ではありません。時間がかかるとすれば権限まわりで、コラボレーター権限の付与をストアオーナーに依頼する必要がある場合は、その返答待ちが実質のリードタイムになります。着手前に権限の確認を先に済ませておくと、待ち時間が発生しません。
まとめ
Shopifyテーマの開発環境を安全にする要点は、突き詰めると3つです。
- 公開中テーマを直接編集しない — 複製テーマを作り、そこで作業する
- 本番反映はテーマの切り替えだけにする — ファイルを直すのではなく、公開先を変えるだけで戻せる状態を保つ
- 触る前の状態をGitに残す — 取得直後にコミットしておけば、いつでも比較できる
Shopify CLIは、この3つを実行するための道具です。導入コストはインストールと初回ログインだけで、それ以降は pull → dev → push → publish の4コマンドで回ります。
今日から始めるなら、まず公開中テーマを shopify theme pull --live で手元に落として git commit してください。それだけで「壊れても戻せる状態」が手に入ります。あとは複製テーマを1つ作り、次の修正からそちらで作業を始めれば、管理画面のコードエディタを開く機会は自然になくなります。
Shopifyでどこまで作り込めるか、構造的な制約を先に把握しておきたい場合はこちらもどうぞ。
