この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、既存ストアの在庫まわりで困っている運用担当者
読了時間: 約14分
Shopifyの管理画面で商品を登録するとき、在庫のところに小さなチェックボックスが2つ並んでいます。「在庫を追跡する」と「在庫切れの場合でも販売を続ける」。ここを何も考えずに通り過ぎたストアが、あとで「注文が入ったのに在庫がない」「気づいたら人気商品が何週間もカートに入らない状態だった」という事故を起こします。
このチェックボックスは、単なる設定項目ではありません。そのストアが在庫をどう扱う商売なのかを宣言する場所です。手元にある分だけ売るのか、受注してから作るのか、入荷を待たせるのか。商売のかたちが違えば、正解も違います。
この記事では、Shopifyの在庫管理における在庫追跡・オーバーセル許可・予約販売の設定を、機能の説明ではなく「どのケースでどれを選ぶか」の判断軸として整理します。あわせて、アプリで足りる範囲とテーマ改修が必要になる境界、導入したあとに効いてくるコストについても書きます。
まず、在庫設定を間違えると何が起きるのか
在庫設定の話は、正しく設定できたときの気持ちよさより、間違えたときの損害から入ったほうが早く理解できます。起きることは大きく2つです。
売り越し（オーバーセル）
在庫が1個しかないのに2件注文が入る状態です。Shopifyの在庫追跡がオフになっている、あるいは「在庫切れでも販売を続ける」がオンになっているとき、システムは注文を止めません。
売り越しが厄介なのは、損失がキャンセル対応の手間だけで終わらないところです。
- 購入者に謝罪連絡をして返金する（決済手数料の扱いは契約や決済手段によって異なる）
- 「買えたはずのものが買えなかった」体験を、いちばん熱量の高い顧客に与える
- レビューやSNSでの言及が、商品ではなく在庫管理の話になる
- モール併売をしていれば、モール側の評価にも影響しうる
とくにセール開始直後やSNSで拡散された瞬間は、短時間で在庫数を超える注文が入ります。普段は起きないから気づかず、いちばん売れている日にだけ壊れる。これが売り越しの性格の悪いところです。
もうひとつ見落とされやすいのは、売り越しが後工程を全部巻き込むことです。出荷指示は出ているのに現品がない。倉庫が制作会社や運用担当に問い合わせる。担当者が管理画面を見て在庫数を直す。その間も注文は入り続ける。1件のキャンセルで終わらず、その日の出荷業務全体が止まることがあります。
機会損失
逆に、在庫を厳密に追跡しすぎて起きる損失もあります。
在庫0になった瞬間に商品ページが「売り切れ」のグレーのボタンになり、そこから先の導線が何もない。ユーザーは戻るボタンを押して、そのまま離脱します。入荷は来週なのに、その情報がページのどこにも書いていない。在庫が戻ったことを、その人に伝える手段が存在しない。
この損失は、売り越しと違って苦情が来ません。誰からも報告されないまま、静かに積み上がります。だからこそ気づきにくい。アクセス解析で「商品ページのPVはあるのにカート追加率が低い商品」を探すと、たいてい品切れ期間が長い商品が出てきます。
売り越し（追跡が緩い）
- 注文が通ってしまう
- キャンセル・返金の手間
- 苦情という形で表面化する
- 熱心な顧客ほど当たる
機会損失（追跡が硬い）
- 売り切れ表示で行き止まり
- 再入荷を伝える手段がない
- 誰からも苦情が来ない
- 数字を見に行かないと気づかない
売り越しは目立つので対策されやすく、機会損失は目立たないので放置されます。設計するときは、後者を意識的に拾いにいく必要があります。
Shopifyの在庫追跡のオン・オフを、商材で決める
Shopifyの在庫追跡は、商品ごと・バリエーションごとに切り替えられます。すべての商品で同じ設定にする必要はありません。まずは自社の商材をこの表に当てはめてみてください。
| 商材のタイプ | 在庫追跡 | 在庫切れでも販売 | 補足 |
|---|---|---|---|
| 仕入れ物販・完成品の在庫販売 | オン | オフ | 基本形。数が正であることが最優先 |
| ダウンロード販売・デジタル商品 | オフ | ―（追跡オフなら無関係） | 数の概念がない |
| サービス・チケット・予約枠 | オン | オフ | 枠の上限＝在庫数として扱う |
| 受注生産・オーダーメイド | オフ | ― | 注文を受けてから作るので上限がない |
| 予約販売（入荷が確定している） | オン | オン | 数量を管理しつつ先に売る形 |
| 定期便・サブスクリプション | 商材次第 | 商材次第 | 原材料に上限があるかで変わる |
判断の分かれ目は、「その商品に、売れる上限が存在するか」の一点です。上限があるなら追跡する。無いなら追跡しない。ここを商材ごとに言語化しておくと、担当者が変わっても設定がブレません。
同じストアの中で混在してかまいません。物販商品は追跡オン、オーダー品は追跡オフ、イベントチケットは枠数を在庫数として追跡オン。この3つが同居していても運用は成立します。むしろ「全商品を同じ設定に揃える」ほうが、どこかの商材で無理が出ます。
「在庫切れでも販売を続ける」を使ってよい条件
この設定はオーバーセル許可とも呼ばれ、危険な機能として説明されがちですが、条件を満たせば正しい選択肢です。使ってよいのは次のどれかに当てはまるときです。
- 入荷日と入荷数が確定している（発注済みで納期が出ている）
- 受注してから調達・製造する前提で、顧客にもそう伝わっている
- 在庫数を「予定在庫」として運用する取り決めがある（実在庫とは別に管理している）
逆に、次の場合は使ってはいけません。
- 「たぶんまだ倉庫にあると思う」という理由でオンにしている
- 実店舗と在庫を共有していて、店頭で売れた分が反映されるまでラグがある
- 入荷の見込みが立っていない商品
この設定をオンにするというのは、在庫数の管理責任をシステムから人間の側へ引き取るという意味です。引き取れる体制があるかどうかで決めてください。
体制があるかどうかは、次の3つで判定できます。①在庫数を確認・更新する担当者が決まっているか、②確認の頻度が決まっているか（毎朝か、注文都度か）、③上限を超えたときに販売を止める操作が誰でもできるか。この3つが埋まらないままオンにすると、実質的に「誰も管理していない状態」になります。
見落とされやすい「複数ロケーション」
店舗と倉庫、あるいは複数の倉庫から出荷しているストアでは、Shopifyのロケーション設定が在庫の見え方を左右します。オンラインストアの販売チャネルにどのロケーションを割り当てているかで、同じ在庫数でも「買える／買えない」が変わります。
実店舗の在庫をECに出す設計は、リアルタイム連携の精度を考えると、たいてい思っているより難しいものです。POSと連携していない状態で店頭在庫をEC在庫として出すのは、売り越しの温床になります。連携させるか、安全在庫を差し引いた数だけECに出すか、最初に決めておく話です。
安全在庫を引く方式は、実装が要らないぶん現実的な折衷案です。店頭に10個あっても、ECには数個少ない数字を出す。その差分が店頭でのタイムラグを吸収します。引く数は商材の回転速度で決まるので、最初は多めに引いて、運用しながら詰めるのが安全です。
Shopifyで品切れ時に何を見せるか
在庫が0になったあと、商品ページに何が残っているか。ここが機会損失の分かれ目です。「SOLD OUT」とだけ出て終わるページは、来訪者を全員取りこぼしています。
品切れページの設計は、次の4段階で考えると整理しやすくなります。
上の段ほど実装が軽く、効果も確実です。4を作り込む前に、1と2を書けているかを先に確認してください。
1と2は、テキストだけで解決する
「入荷未定」なのか「◯月上旬入荷予定」なのかは、それだけで離脱の起きかたが変わります。しかもこれは、商品のメタフィールドに入荷予定のテキストを持たせて、商品ページで在庫0のときだけ表示する、という程度の実装で済みます。アプリは要りません。
やってはいけないのは、日付を確定値として書くことです。「10月3日入荷」と書いて遅れると、その1行が問い合わせを生みます。「10月上旬入荷予定」「入荷が決まり次第このページで更新します」くらいの粒度が、運用にも耐えます。
もうひとつ、この文言は誰が更新するかまで決めてから設置してください。入荷予定テキストは、更新されなくなった瞬間に嘘になります。「8月下旬入荷予定」が10月まで残っているページは、何も書いていないページより信用を落とします。更新できないなら、最初から「入荷が決まり次第このページで更新します」だけを固定文言で置くほうが安全です。
3の再入荷通知は、アプリか自前かの判断が要る
再入荷通知（バックインストック通知）は、品切れ対策の中でいちばん費用対効果が読みやすい機能です。品切れの瞬間にいちばん買う気がある人の連絡先を受け取れるので、通知を送った時点で見込みの高いリストになっています。実装の選択肢は3つあります。
| 方式 | 向くケース | 注意点 |
|---|---|---|
| 専用アプリを入れる | 品切れが頻繁に起きる、通知メールのデザインや配信履歴まで管理したい | 月額が積み上がる。テーマ改修が必要なアプリもある |
| メール配信ツールの機能を使う | すでにメール配信基盤を持っている | 在庫の変化を検知する部分の設定が要る |
| フォームで受けて手動配信 | 品切れが年に数回、対象商品が少ない | 送り忘れる。件数が増えると破綻する |
品切れが「たまに」なら3で始めて構いません。ただし手動運用は、担当者の記憶に依存した仕組みです。月に何度も発生するなら、最初からアプリか配信ツール側に寄せたほうが安全です。
どの方式でも、送るタイミングの設計は必要です。入荷した瞬間に全員へ一斉送信すると、登録者数が在庫数を大きく上回っているときに「通知が来たのに買えなかった」人を大量に作ります。在庫が少ない商品では、登録の早い順に分けて送るか、通知文面に「数に限りがあります」と明記しておく。この配慮がないと、機会損失を潰すはずの機能が不満を生みます。
4の代替導線は、作り込みすぎない
「この商品は品切れです。こちらはいかがですか」というレコメンドは、Shopifyの関連商品機能である程度まかなえます。ここに凝ったロジックを入れるより、同じ商品の別バリエーションが在庫ありなら、そちらを選択済みの状態で見せるほうが効きます。Mサイズが売り切れでLは在庫があるのに、ページを開いた瞬間にMが選ばれていて「売り切れ」ボタンが出ている、という構成は珍しくありません。
このあたりは商品ページのバリエーション表示をテーマ側で調整する話になります。Dawnベースのテーマをどこまで触るかの考え方は、別記事にまとめています。
Shopifyの予約販売・受注生産をどう表現するか
予約販売は、在庫設定の話の中でいちばん要件がバラけるところです。「予約販売をやりたい」という一言の裏に、まったく違う商売が入っています。
まず、どの型なのかを分ける
| 型 | 決済のタイミング | 在庫の扱い | 実装の重さ |
|---|---|---|---|
| 先行予約（入荷確定） | 注文時に全額 | 追跡オン＋オーバーセル許可 | 軽い |
| 受注生産 | 注文時に全額 | 追跡オフ | 軽い |
| 数量限定の予約 | 注文時に全額 | 追跡オンで上限を切る | 中 |
| 内金・デポジット | 一部を先に、残りを後で | 商材次第 | 重い |
| 定期予約・頒布会 | 定期課金 | 商材次第 | 重い |
上の3つは、Shopifyの標準機能とテーマ側の表示調整でほぼ実現できます。アプリが本当に必要になるのは、下の2つ、つまり決済が2回に分かれるときからです。
分割決済や内金は、Shopifyの決済フローの外側に手を入れる話になるため、自前実装は現実的ではありません。ここは素直にアプリの領域です。
「軽い予約販売」を標準機能でやる
先行予約や受注生産の実体は、実はとてもシンプルです。
- 在庫の設定を、その商材に合わせて決める（上の表のとおり）
- カートに入れるボタンのラベルを「予約する」「受注生産で注文する」に変える
- 発送予定時期を、商品ページとカートの両方に出す
- 注文確認メールにも、通常商品と違う旨を書く
このうち2と3は、テーマのLiquidを触る作業です。商品にメタフィールドで「予約商品フラグ」と「発送予定テキスト」を持たせておき、フラグが立っている商品だけボタンのラベルと注記を差し替える。この形にしておくと、運用側は商品登録画面でチェックを入れるだけで済みます。
4を忘れているストアが多くあります。予約商品と通常商品を同時にカートへ入れられる設計にしているなら、「一緒に注文したら全部予約品の発送日まで届かない」のか「分けて発送する」のかを、注文する前に伝えなければいけません。ここを曖昧にしたまま走ると、発送遅延の問い合わせが増えます。
加えて、予約販売ではキャンセル規定を先に決めて表示する必要があります。発送まで期間が空くほど、購入者の事情も気持ちも変わります。いつまでならキャンセルできるのか、入荷が遅れたときはどうするのか。この2つを商品ページに書いておくかどうかで、問い合わせの量が変わります。受注生産のように途中でやめられない商材なら、なおさら注文前に明示が要ります。
予約と通常在庫を混ぜるかどうか
これが設計上いちばん重い判断です。
- 混ぜない：予約商品は予約商品として別に登録する。カートに同居させない。実装は軽い
- 混ぜる：同じカートに入る。分割発送か一括発送かを決めて、そのルールを表示と業務の両方に通す
混ぜる場合、影響は表示だけでは終わりません。送料計算、ピッキング、発送通知、返品対応まで、業務フローの全部に「これは予約分」という属性が伝わっていく必要があります。アプリを入れれば解決する話ではなく、社内の運用ルールを決める話です。
とくに送料は見落とされます。分割発送にすると、1つの注文で2回配送が発生します。その2回目の送料を誰が負担するのか。店舗負担にするなら、予約商品の価格設計にその分を織り込んでおかないと、予約が売れるほど利益が削れます。一括発送にするなら、通常商品まで待たせることを購入前に伝える必要がある。どちらを選んでも、決めごとが1つ増えます。
制作側の立場から言うと、この判断を後回しにしたまま構築を始めた案件は、ほぼ確実に後で作り直しになります。要件定義の段階で必ず決めてください。
アプリで足りる範囲と、テーマ改修が必要になる境界
Shopifyアプリストアには、在庫管理・予約販売まわりのアプリが数多くあります。ただ「アプリを入れれば済む」と考えて進めると、思っていたのと違う結果になることがあります。境界を整理します。
アプリが向く
- 決済が2回に分かれる（内金・分割）
- 再入荷通知の配信と履歴管理
- 複数チャネルの在庫同期
- 倉庫・POS・基幹との連携
テーマ改修が向く
- ボタンのラベル・注記の出し分け
- 入荷予定テキストの表示
- 売り切れ時のバリエーション制御
- 一覧での在庫状態の見せ方
大づかみに言えば、データや決済の流れを変えるものはアプリ、見え方を変えるものはテーマ改修です。見え方の調整をアプリでやろうとすると、月額を払い続けながら細かいところで痒いところに手が届かない、という状態になりやすくなります。
アプリを選ぶときに見る4か所
アプリストアの評価点とレビュー件数だけで決めないでください。実際に確認すべきなのは次の4つです。
最終更新日。Shopifyのテーマ構造やAPIは更新され続けています。長期間更新が止まっているアプリは、次のテーマアップデートで壊れる可能性があります。
日本語対応の実態。管理画面が英語なのは我慢できても、購入者に見えるテキストが英語のままなのは致命的です。文言をこちら側で自由に書き換えられるかを、導入前に必ず確認します。日付表記が「Oct 3」形式のままになるアプリもあります。
サポートの応答。日本時間で返ってくるか、日本語で通じるか。トラブルが起きるのはたいていセール中や繁忙期で、そのときに何日も待たされると事業が止まります。
自社テーマとの相性。アプリの多くは、テーマのLiquidにコードを埋め込む形で動きます。カスタマイズ済みのテーマだと、想定した場所にコードが入らないことがあります。App Blocks（テーマエディタから配置できる形式）に対応しているかは重要な判定点です。
なお、料金は変動するので断定しません。無料で使えるものから月額課金のものまで幅があります。最新の料金は各アプリのページで確認してください。
導入前に、開発ストアか本番のコピーテーマで一度試すことも勧めます。とくにカスタマイズ済みのテーマでは、アプリの埋め込みコードが想定と違う場所に入ることがあります。ライブテーマに直接入れて崩れると、営業中の店の棚を崩しながら直すことになります。
導入後に効いてくる4つの論点
アプリの検討で見落とされがちなのは、入れた瞬間ではなく半年後に効いてくるコストです。
月額の積み上がり。1つひとつは小さくても、在庫通知・予約販売・レビュー・ポイント・翻訳……と積むと、年間で無視できない固定費になります。ここは維持費全体の中で見る話です。
表示速度。アプリはたいていJavaScriptを読み込みます。数が増えるほど商品ページが重くなります。在庫表示のためだけに読み込まれるスクリプトが、コンバージョンを削っていないか。導入前後で計測しておくと判断できます。
解約時に残る要素。アプリを外しても、テーマに埋め込まれたコードや、商品に付いたメタフィールドが残ることがあります。残骸がエラーを出したり、レイアウトを崩したりする。解約したときにテーマがどう戻るかを、入れる前に聞いておくのが安全です。
管理画面を触る人の負担。Shopifyの標準管理画面とは別に、アプリごとの管理画面が増えます。予約商品を1つ登録するのに3つの画面を行き来する運用は、担当者が変わった瞬間に崩れます。日々触る人の手数が何回増えるかは、機能そのものと同じくらい重要な評価軸です。
実際に運用している側から見ると
受託でShopifyを構築するだけでなく、自社でもDawnベースのストアを運営していると、この「触る人の負担」がいちばん効いてきます。機能としては魅力的でも、商品登録のたびに追加の入力が3つ増えるなら、忙しい日には確実に抜けます。
だから自社のストアでは、見え方に関わる部分はアプリを入れずにテーマ側で実装しているものがあります。理由は費用より運用で、商品を登録する画面から離れずに完結する形にしたかったからです。メタフィールドのチェックを1つ入れるだけで表示が切り替わるようにしておけば、覚えることが1つで済みます。
ウィッシュリストのように、アプリを使わずに実装できる機能もあります。何を自前にして何をアプリに任せるかは、機能の難しさではなく「毎日誰が何回触るか」で決めるのが現実的です。
在庫設定を、サイト全体の設計の中で位置づける
在庫設定は商品ページだけの話に見えますが、ストア全体の情報設計に波及します。
一覧ページでの見せ方
商品一覧で売り切れ商品をどう扱うかは、ストアの性格を決める判断です。
| 方針 | 向くストア | 副作用 |
|---|---|---|
| 一覧から非表示にする | 品数が多く、回転が速い | 売り切れの人気商品が完全に消える。SEO上も惜しい |
| 「売り切れ」バッジを付けて残す | 品数が中程度、再入荷がある | 買えない商品が並んで見える |
| 最後尾に並べ替える | どちらも取りたい | 並び替えの実装が要る |
| 「予約受付中」として前に出す | 予約販売が主力 | 予約であることが明確に伝わる必要がある |
いちばん惜しいのは、売り切れ商品をコレクションから外してしまう運用です。商品ページのURLごと検索結果から消えることになり、再入荷したときに評価をゼロから積み直すことになります。在庫0でも公開したまま、状態を正しく伝えるほうが長期的には得です。
なお、恒久的に取り扱いを終える商品は話が別です。二度と入荷しないものを在庫0で並べ続けても、購入できないページが増えるだけになります。その場合は、後継商品やカテゴリページへリダイレクトを設定して、集めた評価を移すほうが筋がいいです。「一時的な品切れ」と「取り扱い終了」は別の処理だと決めておいてください。
コーポレートサイトと兼用しているとき
Shopifyをコーポレートサイトと兼ねて運用しているストアでは、在庫の扱いがさらに設計に効いてきます。会社紹介のページから商品に流れてきた人と、広告から直接商品ページに着地した人とでは、品切れに出会ったときの期待値が違うからです。前者は「どんな会社か」を見に来ていて、後者は「これを買えるか」を見に来ています。
Shopifyを1つのサイトとしてどう組み立てるかは、こちらの記事で扱っています。
会社の顔として使うページで「SOLD OUT」が並んでいると、それ自体がメッセージになります。売れている証拠に見えることもあれば、放置されているように見えることもある。どちらに見せたいかを決めて、表示を設計してください。
数字で確かめる
在庫設定の良し悪しは、感覚では判断できません。次の3つを見ると当たりが付きます。
- 商品ページのPVに対するカート追加率（品切れ期間の長い商品で落ちていないか）
- 再入荷通知の登録数と、通知後の購入率
- 予約商品のキャンセル率（発送までの期間が長すぎないか）
見るときは、品切れになる前と後で同じ商品を比べてください。商品ごとに元の数値が違うので、他の商品と横に比べても差が出ません。同じ商品の時系列で見ると、品切れ表示が何を奪っているかがはっきりします。
計測環境が整っていないと、この判断ができません。GA4と補助ツールの組み合わせ方はこちらに整理しています。
構築前に決めておくチェックリスト
Shopifyでの新規構築・リニューアルを発注する前に、次の項目を自社で答えておくと、制作会社との認識がずれません。逆に言えば、これを決めずに見積もりを取ると、後から追加費用が発生する典型的なポイントです。
在庫について
- 商材ごとに、在庫追跡をオンにするかオフにするか決めているか
- 「在庫切れでも販売を続ける」を使う商品はあるか。あるなら、その在庫数は誰が管理するか
- 実店舗・倉庫・モールと在庫を共有するか。するならリアルタイムか、日次か
品切れ時について
- 品切れ商品を一覧に残すか、外すか
- 入荷予定を出すか。出すならその文言は誰が更新するか
- 再入荷通知は必要か。必要なら想定される登録件数はどのくらいか
- 取り扱いを終了する商品の処理を決めているか（在庫0で残すか、リダイレクトするか）
予約販売について
- どの型か（先行予約・受注生産・内金・定期）
- 予約商品と通常商品を同じカートに入れられるようにするか
- 入れられるようにするなら、発送は分けるか、まとめるか。2回目の送料は誰が持つか
- 発送予定時期はどこに表示するか（商品ページ・カート・注文確認メール）
- キャンセル可能な期限と、入荷が遅れたときの対応を決めているか
運用について
- 商品登録をするのは誰か。その人が触る画面はいくつまで許容できるか
- アプリの月額を含めた年間の運用費の上限はいくらか
このリストのうち、決まっていない項目が多いほど、見積もりの幅は広くなります。制作会社が幅のある金額を出してくるとき、その幅の大半はここの不確定さです。先に決めるほど、見積もりは絞れます。
予算そのものの立て方は、こちらで整理しています。
よくある質問
Shopifyの在庫追跡はオンにしておけば安全ですか
安全側ではありますが、商材によっては機会損失を生みます。受注生産やダウンロード商品のように売れる上限が存在しないものは、追跡をオフにするのが正しい設定です。判断基準は「その商品に売れる上限があるか」の一点で、すべての商品を同じ設定にする必要はありません。同じストア内で商品ごとに設定が違っていて構いません。
「在庫切れの場合でも販売を続ける」は使わないほうがいいですか
入荷日と数量が確定している、あるいは受注生産であることが顧客に伝わっている場合は、正しい選択肢です。危険なのは「たぶんまだあるはず」という理由でオンにするケースです。この設定は在庫管理の責任をシステムから人へ移す操作なので、誰がその数を管理するか・どの頻度で確認するか・上限に達したとき誰が販売を止めるかを決めてからオンにしてください。
Shopifyの予約販売にはアプリが必要ですか
決済が2回に分かれる場合（内金・分割・定期課金）はアプリが必要です。注文時に全額を決済する先行予約や受注生産であれば、Shopifyの標準的な在庫設定とテーマ側の表示調整で実現できます。まず自社の予約がどの型なのかを分けてから、アプリの検討に進んでください。
売り切れた商品はサイトから消したほうがいいですか
再入荷の可能性があるなら残すことを勧めます。商品ページを非公開にするとURLが検索結果から消え、再入荷したときに評価を積み直すことになるためです。在庫0のまま公開し、入荷予定と再入荷通知の導線を置いておくほうが、長期的には得になります。ただし取り扱いを恒久的に終える商品は別で、後継商品やカテゴリページへのリダイレクトを検討してください。
予約商品と通常商品を同じカートに入れられるようにすべきですか
購入体験としては入れられるほうが親切ですが、実装と運用の負荷は明確に上がります。分割発送にするなら2回目の送料負担、一括発送にするなら通常商品を待たせる旨の事前告知が必要です。予約販売が主力でないなら、まずは混ぜない設計で始めて、必要になってから広げるほうが安全です。
在庫まわりのアプリを入れるとサイトは重くなりますか
多くのアプリはJavaScriptを読み込むため、数が増えれば商品ページは重くなります。とくに全ページで読み込まれる作りのアプリは影響が出やすいので、導入の前後で表示速度を計測しておいてください。表示の出し分けだけが目的なら、テーマ側で実装したほうが軽く済むことが多いです。
まとめ
Shopifyの在庫管理設定は、機能の話ではなく商売のかたちを設定に落とす作業です。整理するとこうなります。
- 在庫追跡のオン・オフは「売れる上限があるか」で決める。商品ごとに違ってよい
- 「在庫切れでも販売を続ける」は、管理責任を人が引き取る宣言。担当・頻度・止め方の3つが決まっているときだけ使う
- 品切れページは4段階で設計する。状態を伝える・時期を示す・連絡先を受け取る・代替へ送る。上から順に軽くて効く
- 予約販売はまず型を分ける。決済が2回に分かれるところから、アプリの領域になる
- アプリとテーマ改修の境界は「データを変えるか、見え方を変えるか」。見え方はテーマ側が有利
- アプリ選定は最終更新日・日本語対応・サポート・テーマとの相性の4か所を見る。料金は変動するので各アプリのページで確認する
- 導入後に効くのは、月額・速度・解約時の残骸・運用の手数の4つ
そして最後にもう一度。予約商品と通常商品を同じカートに入れるかどうか。この1つの判断が、実装のボリュームも運用の手間も大きく変えます。要件定義の初日に決めてください。
