Shopify運用設計研究所 > Shopify予約販売アプリの選び方|先行予約・受注生産を失敗させない運用設計
2026年7月3日
•約16分で読めます
Shopify予約販売アプリを選ぶ前に、先行予約、バックオーダー、受注生産の違い、決済方式、在庫引当、発送予定、顧客通知、キャンセル、倉庫連携、KPIまでを運用設計として整理します。
Shopifyで予約販売を始めるなら、予約販売アプリを入れて商品ページのボタンを「予約する」に変えれば大丈夫ですか?
入口としては必要です。ただし実務で崩れるのは、ボタン表示ではなく、いつ請求し、どの在庫を押さえ、いつ出荷し、遅延・キャンセル・返金をどう案内するかです。
「予約販売アプリ」を調べると、アプリ比較、料金、日本語対応、予約ボタンの出し方、おすすめランキングが多く見つかります。候補確認には、Shopify公式の予約注文アプリカテゴリが入口になります。
国内では、TsunのShopifyの予約販売アプリ比較が日本語対応、個数制限、注文タグ、同梱制御などの機能軸を整理しています。BiNDecのShopifyでの予約販売の始め方と失敗しない運用法も、オーソリ期限切れやオーバーセルを見る入口になります。
ただし、この記事ではアプリランキングを作りません。料金、レビュー、日本語対応、対応決済、デポジットや後払いの仕様、チェックアウト制限は変わるため、導入時は公式情報と契約条件を確認します。
一方で、アプリを選ぶ前に決めるべき運用論点は大きく変わりません。販売形態、決済方式、予約上限、在庫引当、発送予定、注文タグ、通知、キャンセル、KPIを決めずに入れると、販売開始後に現場が詰まります。
Shopify公式ヘルプのPre-ordersでも、予約販売は注文時に全額、一部、または支払いなしで受け付けられ、予約販売アプリとアプリ側設定が必要だと説明されています。
Shopify予約販売アプリ選定で先に決めるべきなのは、アプリ名ではなく、予約注文を決済・在庫・出荷・通知・返金までどう運用するかです。
Shopify予約販売アプリを比較する前に、販売形態を分けます。予約販売、バックオーダー、受注生産は、どれも「注文から出荷まで時間が空く販売」ですが、必要な決済、在庫、製造、通知、キャンセル規約は違います。
| 販売形態 | 典型例 | 先に決めること | アプリ選定で見ること |
|---|---|---|---|
| 先行予約 | 新商品、限定色、発売前コレクション | 発売日、予約上限、予約価格、発売延期時の連絡 | 発送予定日表示、デポジット、注文タグ、予約専用ボタン |
| バックオーダー | 欠品中だが入荷予定がある定番商品 | 入荷予定、通常在庫との切替、再入荷通知との使い分け | 在庫切れ時の自動切替、入荷通知、予約上限 |
| 受注生産 | 名入れ、サイズオーダー、限定製造品 | 製造開始条件、キャンセル期限、リードタイム | 注文後変更不可の表示、個別項目、製造ステータス連携 |
再入荷通知や抽選販売も近い領域ですが、この記事では「注文を受け、後で出荷する」予約販売に絞ります。再入荷通知は販売前の通知、抽選販売は当選判定が主役になるため、必要なアプリ機能が変わります。
価格やレビューを見る前に、次の表を埋めます。
| 領域 | 決めること | 決めないと起きること |
|---|---|---|
| 商品 | 対象商品、バリエーション、SKU、予約上限、通常販売との切替 | サイズや色ごとに売り越す |
| 表示 | 商品ページ、カート、チェックアウト、メールに出す文言 | 顧客が予約商品だと気づかない |
| 決済 | 全額決済、デポジット、後払い、支払いなしのどれにするか | オーソリ期限や未回収で詰まる |
| 在庫 | 注文時に引き当てるか、出荷時に引き当てるか | 通常販売と予約分が混ざる |
| 通知 | 受付、入荷、遅延、出荷、キャンセル、返金を誰に送るか | 問い合わせが増え、CSが説明できない |
| キャンセル | 発送前、製造開始後、延期時のキャンセル可否 | 返金判断が担当者ごとに変わる |
| 倉庫 | 出荷予定日、保留、同梱、分割発送、WMS連携 | 通常注文と同じタイミングで出荷指示される |
| 計測 | 予約CVR、予約上限消化、キャンセル率、遅延率 | 売れているのか、無理に受けているのか分からない |
Setting up pre-ordersでは、発送できる見込みの根拠、発送予定日の明示、遅延時の修正日とキャンセル・返金権利の説明が求められます。
つまり予約販売は、「売る前にお金をもらえる便利機能」ではありません。発送予定を約束し、遅れた時に説明し、キャンセルや返金まで処理する販売方法です。
予約販売で最初に詰まりやすいのが決済です。
Shopifyの予約販売では、注文時に全額決済するケース、一部デポジットを受けるケース、後日請求するケース、支払いなしで予約受付するケースがあります。ただし、どれが使えるかは、予約販売アプリ、Shopifyのプラン、決済ゲートウェイ、地域、通貨、契約条件で変わります。導入時に必ず公式情報とアプリ側の仕様を確認します。
| 決済方式 | 向いているケース | 確認すること |
|---|---|---|
| 注文時に全額決済 | 発売日が近い、在庫入荷が確実、キャンセルが少ない | 発送遅延時の返金、キャンセル規約、会計処理 |
| デポジット | 高額商品、限定品、購入意思を確認したい商品 | デポジット額、残額請求日、返金可否、未払い時の扱い |
| 後払い・残額後日請求 | 長納期、受注生産、入荷日が変動する商品 | 支払い方法保存、残額請求、失敗時通知、請求責任 |
| 支払いなし予約 | 需要調査、入荷通知に近い予約、B2B商談 | 本当に注文扱いにするか、キャンセル率、連絡手段 |
Shopify.devのAbout pre-order and Try Before You Buyでは、予約販売やTBYBは価格、配送、在庫、請求のポリシーで構成されると説明されています。在庫を注文時にコミットするか、出荷時にコミットするか、一部金額を請求して残額を後日請求するか、といった設計が関係します。
また、Payment authorization and captureでは、Shopify Paymentsの標準的なオーソリ期間は7日と説明されています。長納期の予約販売では、オーソリ期限、追加手数料、対応カード、決済方法の差を導入時に確認します。
決済設計は、別記事のShopifyの決済設定は何を決めてから有効化すべきかとも合わせて見る必要があります。予約販売では特に、通常購入と違って注文日、請求日、出荷日、返金日がズレるからです。
オーソリ期限、デポジット、残額請求、後払い、追加手数料、対応決済は変わります。記事を読んだ段階で決め切るのではなく、導入時に公式ヘルプ、アプリ仕様、決済契約を確認する前提で設計します。
予約販売の在庫は、通常販売よりも扱いが難しくなります。
「在庫がないから予約を受ける」と考えると、売り越しが起きます。予約上限、入荷予定数、通常販売分、モール販売分、店舗分、返品見込み、製造不良を分けて見ないと、予約を受けたのに出荷できない状態になります。
| 在庫設計 | 具体例 | 失敗パターン |
|---|---|---|
| 商品・バリエーション単位の予約上限 | ブラックMは100点、ホワイトLは30点まで予約受付 | 商品全体では足りているが特定サイズだけ不足 |
| 通常販売分と予約分の分離 | 予約枠200、即納在庫50を分ける | 通常販売で予約分まで売ってしまう |
| 入荷予定と安全在庫 | 300入荷予定だが、破損・検品差異を見て280まで予約 | 入荷数のズレで全員へ出荷できない |
| 引当タイミング | 注文時に予約枠を減らす、または出荷時に在庫を減らす | どの数字を見れば残枠が分かるか曖昧 |
| チャネル横断 | Shopify、実店舗、楽天、Amazon、卸を合算 | Shopifyだけ予約停止しても他チャネルで売り越す |
Shopify公式のManaging pre-ordersでは、予約注文の在庫は販売時またはフルフィルメント時に予約され、アプリの設定で選べる場合があると説明されています。選択肢がない場合はアプリ開発元へ確認する必要があります。
この考え方はShopify在庫連携の設計方法とも同じです。在庫の正本がShopifyなのか、WMSなのか、基幹システムなのかを決めないまま予約販売を始めると、予約注文、通常注文、倉庫在庫、会計上の在庫がズレます。
予約販売の在庫設計では、「売り切れ商品を売れるようにする」ではなく、予約枠・通常在庫・入荷予定・倉庫引当を分けて管理することが重要です。
予約販売は、顧客の期待値管理がほぼ成否を決めます。
商品ページだけで「予約販売」と書いても足りません。カート、チェックアウト、注文確認メール、マイページ、発送遅延メール、キャンセルポリシーまで同じ説明にします。
Pre-orders and Try Before You Buy for themesでは、予約販売やTBYBアプリがselling plan groupsとselling plansを作り、商品やバリエーションに紐づけること、テーマ側ではLiquidやJavaScriptで予約販売体験を統合できることが説明されています。
| 表示・通知 | 伝えること | 運用で決めること |
|---|---|---|
| 商品ページ | 予約販売であること、発送予定、支払い条件 | バリエーションごとに予定日が違う場合の表示 |
| カート | 通常商品と予約商品の混在、同梱不可、分割発送 | 混在を許すか、アラートか、購入不可にするか |
| チェックアウト | デポジット、残額、支払い予定、同意文 | アプリとShopify標準表示の確認 |
| 注文確認メール | 予約受付、発送予定、問い合わせ先 | 通常注文メールと文面を分けるか |
| 遅延通知 | 新しい発送予定日、キャンセル・返金の選択肢 | 何日遅れたら誰が送るか |
| キャンセル通知 | 返金予定、再注文案内、在庫戻し | アプリ側とShopify注文の両方を処理するか |
メール運用は、別記事のShopifyのメール設定を運用設計から整えるでも整理しています。予約販売では、注文確認メールだけでなく、入荷、遅延、出荷、返金、支払い方法更新の通知が必要になります。
注文タグも重要です。たとえば、予約注文を抽出する preorder、入荷月を示す preorder-2026-09、残額請求対象の balance-due、出荷保留の fulfillment-hold、遅延連絡済みの delayed-notified などです。増やしすぎず、CS、倉庫、経理、開発が同じ意味で使える名前にします。
予約販売で現場が混乱しやすいのは倉庫です。
通常注文と同じ出荷フローに予約注文が流れると、未入荷なのに出荷指示が出る、予約商品を含む注文全体が止まる、通常商品だけ先に送るか判断できない、といった問題が起きます。
| 倉庫連携の論点 | 決めること |
|---|---|
| 出荷保留 | 予約注文を自動でフルフィルメント保留にするか |
| 入荷後解除 | 入荷・検品後に誰が保留を解除するか |
| 同梱制御 | 通常商品との同時購入を禁止、まとめて発送、分割発送のどれにするか |
| WMS連携 | 予約注文をいつWMSへ渡し、ロットや特典同梱をどう伝えるか |
| 返品・キャンセル | 出荷前キャンセルと出荷後返品を分ける |
同梱制御は特に重要です。通常商品と予約商品を同じカートで買えるようにすると、顧客は「すべて一緒に早く届く」と期待しやすくなります。分割発送を許すなら、送料、会計、通知、倉庫指示まで合わせて決めます。
Shopify予約販売アプリを選ぶときは、商品ページのボタンだけでなく、カート混在、注文タグ、フルフィルメント保留、入荷後の解除、WMSへの引き渡しまで見ます。
Shopify App Storeには多数の予約販売アプリがあります。Built for Shopify、レビュー数、価格、無料プラン、日本語対応、再入荷通知、デポジット、注文タグ、テーマ対応などは候補選定で見ます。
ただし、ここで「一番おすすめ」を決めるのは危険です。商材、決済、地域、在庫連携、倉庫体制、CS体制で正解が変わるからです。
| アプリのタイプ | 向いているケース | 確認ポイント |
|---|---|---|
| シンプルな予約ボタン型 | 小規模に先行予約を始めたい | 商品・バリエーション単位の設定、予約上限、表示文言 |
| 再入荷通知併用型 | 欠品商品を予約または通知で取りたい | 予約販売と通知の切替、通知リスト、入荷時配信 |
| デポジット・分割請求型 | 高額商品、長納期、受注生産 | 残額請求、失敗時処理、返金、対応決済 |
| カスタム連携前提型 | WMS、基幹、会計、CRMまでつなぐ | API、Webhook、タグ、メタフィールド、障害時対応 |
レビュー数が多いアプリでも、決済、在庫、同梱、倉庫連携に合わなければ外します。逆に、見た目は地味でも、注文タグ、同梱制御、残額請求、WMS連携に合うアプリは有力候補になります。
予約販売は、発売前に売上を作れる一方で、未出荷の約束を積み上げる販売です。売れた数だけ見ていると、遅延、キャンセル、在庫不足、問い合わせ増加に気づくのが遅れます。
| KPI | 見る理由 | 悪化した時の確認 |
|---|---|---|
| 予約CVR | 予約商品ページが買われているか | 発送予定、価格、デポジット、説明不足 |
| 予約上限消化率 | 入荷予定に対してどれだけ埋まったか | 上限設定、広告停止、追加発注 |
| キャンセル率 | 期待値と実際のズレを測る | 発送遅延、価格、連絡不足 |
| 支払い失敗率 | 残額請求が回収できているか | 決済方法更新、通知、再請求 |
| 予定日遅延率 | 約束した発送日を守れているか | 仕入、製造、検品、倉庫処理 |
| 引当不足件数 | 予約分の在庫が足りているか | 売り越し、チャネル横断、破損 |
予約販売は、売上を前倒しする仕組みであると同時に、未出荷の約束を管理する仕組みです。売上金額だけでなく、未出荷残、遅延、キャンセル、支払い失敗、在庫不足まで見ます。
最後に、Shopify予約販売アプリを導入する前のチェックリストをまとめます。
| 領域 | 確認内容 |
|---|---|
| 公式情報 | Shopify公式ヘルプ、Shopify.dev、Shopify App Store、各アプリ公式サイトを確認した |
| 販売形態 | 先行予約、バックオーダー、受注生産、再入荷通知のどれかを分けた |
| 商品設計 | 商品・バリエーション・SKUごとの予約上限を決めた |
| 決済 | 全額、デポジット、後払い、支払いなしの方針を決めた |
| 制限 | 対応決済、エクスプレスチェックアウト、B2B、POS、割引の制限を確認した |
| 在庫 | 注文時引当か、出荷時引当か、通常在庫との分離を決めた |
| 表示・通知 | 商品ページ、カート、チェックアウト、メール、遅延連絡を揃えた |
| キャンセル | 発送前、製造開始後、延期時、顧客都合の扱いを決めた |
| 倉庫・CS | 保留、同梱、分割発送、注文タグ、問い合わせテンプレートを決めた |
| 会計 | 注文日、請求日、出荷日、返金日、デポジットを説明できる形にした |
| KPI | 予約CVR、キャンセル率、遅延率、支払い失敗率、引当不足を月次で見る |
この表が埋まっていれば、どのアプリを見るべきか、標準機能で足りるか、Shopify FlowやAPI連携が必要かを現実的に判断できます。
Shopify予約販売アプリは、商品ページに予約ボタンを出すためだけのものではありません。
先行予約、バックオーダー、受注生産を分け、決済方式、デポジット、後払い、オーソリ期限、在庫引当、予約上限、発送予定、注文タグ、通知、キャンセル・返金、倉庫連携、KPIまで設計して初めて、予約販売を実務で回せます。
予約販売アプリ比較というより、先に予約販売の業務フローを作る必要があるんですね。
その通りです。業務フローがあれば、予約ボタン型で足りるのか、デポジット対応が必要なのか、在庫・倉庫・会計まで連携すべきかが判断できます。
Bitlightでは、Shopify予約販売アプリの選定だけでなく、販売形態の切り分け、決済方式、在庫引当、発送予定表示、注文タグ、同梱制御、顧客通知、キャンセル・返金、倉庫連携、KPI監視まで含めて整理します。
「予約販売アプリを入れたいが、決済や在庫が不安」「受注生産をShopifyで始めたい」「倉庫・会計・CS運用とつなぎたい」という場合は、現在の商品、在庫、決済、配送、通知、会計を棚卸しし、導入前の設計表に落とし込むところから支援できます。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。