---
title: "サブスクリプションボックス向けShopify：注文締め切りとサイクルごとの受付枠上限（2026年版）"
description: "課金アプリはサブスク会員に請求してくれますが、サイクルごとの新規申込を制限したり、ボックスが売り切れたときにカートを閉じたりはできません。Shopifyで締め切り、サイクルごとの受付枠、「残り枠」を運用する方法を解説します。"
contentType: "blog"
locale: "ja"
localized: true
source: "https://orderrules.com/ja/blog/shopify-for-subscription-boxes"
slug: "shopify-for-subscription-boxes"
date: "2026-08-02"
tags:
  - "shopify"
  - "subscription box"
  - "capacity limits"
  - "order cutoff"
  - "per customer limit"
  - "waitlist"
---
サブスクリプションボックスには、サブスクアプリが解決しない問題があります。Recharge、Appstle、Seal、Shopify Subscriptionsは*課金*には優れていて、継続課金を実行し、顧客がスキップ・一時停止・キャンセルできるようにします。しかし、どれもボックス販売者が毎月実際に抱える運用上の問いには答えてくれません。*「ボックスが尽きる前に、このサイクルで何人の新規会員を受け入れられるのか。そしてその人数に達したときにどうやってカートを閉じるのか」*という問いです。

Shopifyにもネイティブな答えはなく、検索結果もこの点については奇妙なほど静かです。「サブスクボックスの申込を月ごとに制限する」と検索しても、出てくるのは一般的な「ボックスの始め方」チュートリアルばかりで、受付枠と締め切りの仕組みではありません。このガイドでは、その欠けているレイヤーを扱います。サイクルごとの新規申込の制限、申込締め切りの設定、そして「残り枠」やキャンセル待ちの表示です。その間、課金アプリは得意なことを続けてくれます。

## クイックアンサー：Shopifyでサブスクボックスの申込を制限する方法

**Shopifyでサブスクボックスの申込をサイクルごとに制限するには、課金アプリの前段に注文受付ウィンドウのレイヤーを追加します。サブスク商品またはコレクションへのサイクルごとの受付枠上限、申込締め切り日、顧客ごとの制限を、すべてチェックアウトで適用します。** OrderRulesはこれをProプランで実現します。重要なのは、これがコントロールするのは*新規申込と単発注文*であって、既存の更新ではないという点です。Shopifyのチェックアウト検証Functionsは新規チェックアウトでは動作しますが、継続サブスク注文では動作しません。そのため、あなたが新規受付の扉を閉じている間も、既存会員は更新を続けられます。更新も上限にカウントされるため、上限は総キャパシティに合わせて設定してください。

## サブスクボックスの2つのレイヤー

サブスクボックスには実際には2つの異なるシステムが必要で、それらを混同することが、販売者が行き詰まる原因です。

- **課金レイヤー** — サブスクを作成し、継続課金を実行し、スキップ・一時停止・キャンセルを処理します。これはShopify Subscriptions、Recharge、Appstle、Seal、またはLoopです。
- **入り口レイヤー** — *このサイクルで誰がボックスを開始できるか、いつカートを閉じるか、何件まで受け付けるか*を決めます。これは受付枠上限、締め切り、顧客ごとの制限、そして「残り枠」メッセージです。

どの課金アプリも第1のレイヤーを担います。**第2のレイヤーを担うものはほとんどありません**。だからこそ販売者は、大ざっぱな在庫制限、手作業での商品の開閉、別のキャンセル待ちアプリを寄せ集めて何とかしようとするのです。OrderRulesはその入り口レイヤーのために作られており、あなたがすでに使っているどの課金アプリの前段にもきれいに収まります。

これはエンジンルームと玄関のようなものだと考えてください。あなたの課金アプリはエンジンルームで、すでに中にいる全員の継続課金を回し続けます。OrderRulesは玄関で、このサイクルに何人の新しい人が入れるか、いつ鍵をかけるかを決めます。この2つは決してぶつかりません。作用する瞬間が違うからです。玄関は申込時に、エンジンルームは更新時に働きます。きれいにスケールするボックスビジネスは、両方を運用し、それぞれを自分のレーンに保ちます。

## Shopifyと課金アプリにできないこと

そのままでは、Shopifyも課金アプリも次のことはできません。

- **サイクルごとに新規申込を制限する。**「今月の新規ボックスは200件まで」という制御はありません。Shopify Subscriptionsは在庫追跡や請求の再試行は提供しますが、申込のしきい値は提供しません。
- **サイクルが売り切れたときにカートを閉じる**。サブスクのサイクルに紐づいた「今月は売り切れ、キャンセル待ちに登録」というネイティブな状態はありません。
- **申込締め切りウィンドウを適用する**。20日以降の申込を翌月のサイクルに繰り越すネイティブなルールはありません。
- **これらを回避不可能な形で実現する**。テーマ側の小細工はShop Payやエクスプレスチェックアウトでは素通りされます。

唯一のネイティブな手段、つまりサブスク商品に低い在庫数を設定するというやり方は、大ざっぱで危険です。新規申込*と*更新の*両方*に影響するため、新規を制限しようとして既存会員の分をうっかり枯渇させてしまうおそれがあります。必要なのは、更新に触れずに受付を制限できる制御です。それが次のセクションで正確に説明する違いです。

| 機能 | 課金アプリ（Recharge、Seal、Shopify Subscriptionsなど） | OrderRules |
| --- | --- | --- |
| 継続課金とサブスク契約 | あり | なし — 課金アプリはそのまま使う |
| サイクルごとの**新規**申込の制限 | なし | あり |
| サイクルが売り切れたときにカートを閉じる | なし | あり |
| 申込締め切り／出荷ウィンドウのゲート | なし | あり |
| 顧客1人につき1ボックス（新規申込） | なし | あり |
| 商品ページの「残り枠」バッジ／キャンセル待ちメッセージ | なし | あり（商品の上限） |
| **既存**の更新を絞る | 一時停止／スキップ／在庫で | なし（設計上） |
| Shop Payを含むチェックアウトで適用 | — | あり（Shopify Functions） |

## 重要：OrderRulesがコントロールするもの、しないもの

構築する前にスコープを明確にしておきましょう。これは設計の核心そのものだからです。

**OrderRulesがコントロールするのは入り口、つまり新規チェックアウトです。**

- 新規サブスク**申込**（申込はセリングプランを伴う通常のShopifyチェックアウトなので、Shop Payやその他の加速チェックアウトを含め、ルールがそこに適用されます）。
- **単発注文とアドオン注文**（ビルド・ア・ボックスの追加品や、単発購入のギフトボックスなど）。

**OrderRulesがコントロール*しない*のは更新や課金です。**

- 継続課金を作成したりサブスク契約を管理したりはしません。それはあなたの課金アプリの役割です。
- 既存会員の**更新**を絞ったり、一時停止したり、制限したりはしません。Shopifyのカート・チェックアウト検証Functionsは「サブスクリプション（継続注文）」を明確に**サポート対象外**として挙げています。更新は課金アプリが（請求試行を通じて）チェックアウトを介さずに作成するもので、ストアフロントを通らないためです。検証Functionは更新に対しては一切動作しません。

これは弱点どころか、まさにあなたが望むものです。**すでにいる顧客に支障をきたすことなく、新規受付を制限して閉じる**ことができます。もし更新を保留したり絞ったりする必要もある場合、それは課金アプリの側にあります（契約の一時停止・スキップ、あるいはその在庫設定）。注文ルールアプリの側ではありません。

## サイクルごとに新規ボックス申込を制限する（「今月は売り切れ」）

これが目玉の使い方です。**サイクルごとの受付枠上限**（月次または週次）を、サブスク商品に、あるいは共通の生産上限に対して複数のボックスティアを運用しているならコレクションに設定します。上限は新規申込の分だけでなく、そのサイクルで梱包できる総数に設定します。更新注文はブロックされませんが、上限にはカウントされるためです。上限に達すると、商品ページに上限到達メッセージが表示され、新規チェックアウトがブロックされます。

これは大手ボックスが運用しているのと同じ、売り切れ＋キャンセル待ちのモデルです。たとえばOwlCrateはボックスを「Sold Out（売り切れ）」と表示し、キャンセル待ちでメールを集め、期間限定の購入リンク付きで少しずつ枠を放出します。さらに、それ以降のはみ出し購入はキャンセルされるという厳格な締め切り日も設けています。この仕組みはShopifyでも再現できます。受付枠上限が売り切れ状態を作り出し、ストアフロントのメッセージが買い物客をキャンセル待ちへ誘導します。上限はチェックアウトで適用されるため、バズった月でも生産ラインが埋まった時点で新規申込の受付を停止します。

サイクルを健全に保つ計算はこうです。月に500個のボックスを梱包できるなら、月次の上限を500に設定します。1日に350件の更新が課金されると、それが上限にカウントされて新規申込には150件の枠が残り、ラインが埋まった時点でカートが閉じます。更新は決してブロックされないため、新規申込が上限を埋めた*あと*に更新が課金されると、その更新も処理されて上限を超えてしまいます。更新はサイクルの早い時期に課金するか、後から来る更新の分の余裕を残しておきましょう。更新のベースが増えても、数え直すことなく上限は機能し続けます。

詳しい仕組みは[週次・月次上限のドキュメント](/docs/order-limits/weekly-monthly-caps)にあります。また[数量限定ドロップの手引き](/blog/create-limited-drop-shopify-without-chaos)では、同じ考え方をカートを閉じる希少性ローンチ版として扱っています。

## オープン型とクローズド型のサブスクモデル

ボックスの売り方には2つの方法があり、受付枠上限はより収益性の高い方法を可能にします。

- **オープン型** — 申込は常に受付中。シンプルですが、生産計画が立てられず、好調な月は梱包ラインをあふれさせかねません。
- **クローズド型** — 申込を期間限定で開き、サイクルに上限をかけ、カートを閉じてキャンセル待ちを運用します。手間はかかりますが、受付枠を希少性に変えられます。会員は枠が限られていると知り、ローンチはイベントのように感じられ、作れる数以上のボックスを約束することもありません。

クローズド型の「上限→キャンセル待ち」モデルが人気なのには理由があります。希少性はコンバージョンにつながることがあるのです。ただし問題は、Shopifyには「クローズド」を*適用する*手段が一切ないことです。あなたが目標数に達した後でも、買い物客がサブスクに加入するのを止めるものは何もありません。クローズド型を本物にするのがサイクルごとの上限です。あなたが間に合うように商品を引っ込めるのに頼るのではなく、上限で実際にカートが閉じます。クローズド型を恒久的に運用することも、需要の高いサイクルだけそれに切り替え、余力ができたら再開することもできます。

## 月次の締め切りと出荷ウィンドウを設定する

ボックスはリズムで動きます。締め切り日までに申し込み、全員がまとめて出荷されます。販売者は「20日に課金／申込を締め切り、28日に出荷」といったことをどう適用すればよいか繰り返し尋ねており、これはShopifyコミュニティで何度も出てくる質問です。Shopifyがネイティブには対応しないからです。

締め切り日の翌日以降をカレンダーで**休業日**にし、新規申込が、すでに梱包に向けて締めたサイクルへ加わるのではなく、次のサイクルを待つようにします。オンボーディングを行わない期間（休暇による停止、在庫の入れ替えなど）にも同じ休業日を使います。休業日は申込だけでなく、ストアのすべてのチェックアウトをブロックする点に注意してください。既存会員の継続課金の基準日は依然として課金アプリが担います。OrderRulesは新規に対して入り口をいつ開けるかを管理するだけです。[締め切り時間の設定](/blog/setting-up-cutoff-times-shopify)をご覧ください。

## キャンセル待ちと次のサイクルに対処する

売り切れさせるのは戦略の半分にすぎません。あふれた需要をどう扱うかがもう半分です。サイクルが上限に達してボックスのチェックアウトが閉じたら、その関心を失うのではなく取り込みましょう。

- **売り切れ状態をキャンセル待ちへ向ける**。商品の上限到達メッセージの文言を変え、満枠のサイクルでは行き止まりではなく「売り切れ — キャンセル待ちに登録」と表示し、メール登録フォームにリンクします。そのリストは次サイクルに向けた温かい需要です。
- **次のサイクルを計画的に放出する**。再開するときには、提供できる枠数と、誰が先頭にいるかがすでにわかっています。OwlCrateのようなボックスがそうしているように少しずつ放出すれば、梱包しきれない殺到に向けて再開してしまうことがありません。
- **その間ずっと更新を流し続ける**。上限が更新をブロックすることはないため、既存会員は売り切れ期間中もそのまま更新を続けます。キャンセル待ちはあくまで*成長*のためであり、既存のベースには関係しません。

その結果、予測可能なリズムが生まれます。上限をかけ、売り切れさせ、キャンセル待ちを集め、受付枠まで再開する。今月さばききれない需要は、返金と謝罪ではなく、来月への助走になります。

## 顧客1人につき1ボックス（とアドオン制限）

数量限定や公平なアクセスを重視したローンチでは、新規申込を**顧客1人につき1ボックス**に制限し、1人の購入者が希少なサイクルを5個もかき集められないようにします。その商品に顧客ごとの制限を設定します。カウントされるのはログイン中の顧客だけで、顧客ごとの制限が有効な間はストア全体でゲストチェックアウトがブロックされます。もう1点、事前に考えておくことがあります。**更新注文も顧客ごとの制限にカウントされます**（OrderRulesではタグやチャネルで除外できません）。そのため、更新される商品に制限をかけると、顧客自身の更新で枠を使い切ってしまいます。制限は限定品や単発購入のボックス商品に設定し、継続するサブスク商品とは分けておきましょう。同じ顧客ごとの上限は、単発のアドオン注文にも適用できます。

これはより広範な[顧客ごとの制限ガイド](/blog/per-customer-order-limits-shopify-guide)と重なります。そちらでは期間やスコープを深く掘り下げています。このセクションはそのサブスクボックス版の切り出しにすぎないので、設定の全体像はまずそちらから始めてください。

## アドオン、ギフトボックス、単発注文

ボックスがサブスク*だけ*を売ることはめったにありません。ビルド・ア・ボックスのアドオン、単発のギフトボックス、会員向けグッズドロップは、いずれも通常のチェックアウトを通ります。つまり、これらは更新ではなく普通の注文なので、同じルールが適用されます。

- **アドオンの受付枠**。季節限定のアドオンが数量限定なら、ボックスと同じようにサイクルごとに上限をかけ、アドオンがベースのサブスクとは独立して売り切れられるようにします。
- **ギフトボックスの制限**。単発の年末年始ギフトボックスには、独自の顧客ごとの制限と週次上限を持たせ、贈答需要の急増を、更新と並行して梱包できる範囲に収められます。
- **グッズドロップの公平なアクセス**。会員限定のグッズドロップは顧客1人につき1個に制限でき、転売業者に一掃されるのを防げます。

これらは普通のチェックアウトなので、OrderRulesはShop Payを含む販売時点でそのすべてを適用します。あなたの申込を制限するのと同じエンジンがアドオンを守るので、思いがけずヒットした追加品が静かにサイクルをあふれさせることはありません。

## 週単位のミールプレップの受付期間

ミールプレップは週単位のリズムで動きます。月曜〜水曜に注文を受け、木曜に仕入れ、金曜に調理・梱包し、週末に配送します。リストを確定したあとに入った注文は仕入れに間に合わないため、代替品か遅延になります。次の3つのルールで、受付期間を自動で回せます：

| ルール | 設定 | プラン |
|---|---|---|
| 週単位の注文受付期間 | 営業時間：月曜8:00から、火曜は終日、水曜18:00まで、木曜〜日曜は休業 | 全プラン |
| 週ごとの注文上限 | ストア全体の注文数の上限、月曜〜日曜、月曜の午前0時にリセット | Pro |
| メニューごとの週の上限 | 料理ごとの商品上限。全買い物客を合わせた食数の合計 | Pro |

水曜の締め切りと上限のうち、先に達したほうが注文受付を閉じます。受付期間外には「来週分の注文は月曜の午前8時に受付開始」というバナーが表示され、各週のカウンターはそれぞれ自動でリセットされます。

**例（複数の事例を組み合わせたもの）。** 8品のメニューで、週の上限は120件。サーモンの仕入れ先からは30食分が届くため、サーモンボウルは週30食で上限に達して売り切れ、チキンシーザー（60）とヴィーガンキヌア（25）は受付を続けます。感謝祭の週と8月の1週間は、休日カレンダーで休業にしています。

**更新はカウントされるが、ブロックはされない。** 会員の更新はチェックアウトを介さずに作成されるため、検証で止まることはありませんが、週ごとの上限とメニューごとの上限にはカウントされます。各上限は、キッチンで作れる総数に設定してください。その週に課金された更新が自分の分を使い、新規申込と単発注文が残りを受け取ります。プランごとの食数（あるティアは週5食、別のティアは週10食）はサブスクアプリで管理してください。顧客ごとの制限は、ログイン中のすべての顧客に同じ数を適用するためです。

## OrderRulesでの設定方法

1. **課金アプリはそのまま使います**（Shopify Subscriptions、Recharge、Appstle、Seal）。継続課金のためです。OrderRulesはその前段に立つもので、課金を置き換えるものではありません。
2. **OrderRulesをインストール**して**Pro**プランを開きます（[料金](/pricing)）。サイクルごとの上限と顧客ごとの制限はProで、営業時間による締め切りはどのプランでも動作します。
3. サブスク商品またはコレクションに**サイクルごとの新規申込の上限を設定**します（例：月200）。
4. カレンダーの休業日で**申込締め切りを設定**し、遅れた申込が次のサイクルを待つようにします。オンボーディングを停止する期間にも同じ方法を使います。
5. **顧客ごとの制限を追加**し、商品バッジと上限到達メッセージの文言を変えて「残り枠」やキャンセル待ちの案内を表示します。
6. **チェックアウトでテスト**します。上限と締め切りが（Shop Payを含めて）新規申込をブロックすること、そして既存の更新は引き続き処理されることを確認します。

## どのサブスクアプリと組み合わせるか

OrderRulesはどの課金アプリの前段でも動作します。主な選択肢は次のとおりです。

- **Shopify Subscriptions** — 無料、ネイティブ、シンプルな継続プラン。1〜2種類のボックス商品に最適です。
- **Recharge** — エンタープライズの標準。深い連携と分析機能。
- **Appstle** — 機能が豊富で、ビルド・ア・ボックスや高度なロジックも含みます。
- **Seal Subscriptions** — コストパフォーマンスに優れ、寛大な無料枠。
- **Loop** — リテンション重視で、解約防止やキャンセルのフローを備えています。

いずれも課金とリテンションを担いますが、どれもサイクルごとに新規申込を制限したり、しきい値でカートを閉じたりはしません。それがOrderRulesが埋めるギャップです。だから正直におすすめするのは、それぞれを1つずつ運用し、各自の仕事をさせることです。

## サブスクボックスのよくあるシナリオ

これらの制御が可能にするいくつかのパターンです。

- **創設メンバーのコホート** — 最初のサイクルを低く制限し（たとえば100ボックス、顧客1人につき1個）、実際に満足させられる少数の創設グループでローンチしてから、梱包キャパシティの拡大に合わせて上限を引き上げます。
- **クローズドカートのローンチ** — 1週間だけ申込を開き、サイクルに上限をかけ、閉じて翌月のキャンセル待ちを作ります。設計としての希少性です。
- **数量限定ボックス** — 500個に制限したテーマ付きボックス。顧客1人につき1個で、満枠になれば売り切れ。
- **基準日サイクル** — 20日に申込を締め切り、28日にすべて出荷。ストアは1日に翌月分の申込受付を再開します。
- **アドオン付きビルド・ア・ボックス** — ベースのボックスはサブスク。顧客ごとと受付枠の制限で、単発アドオンの需要を梱包できる範囲に保ちます。

## まとめ

あなたの課金アプリは、新規申込を制限したり、サイクルが売り切れたときにカートを閉じたり、遅れた申込を翌月まで保留したりはしません。それはその役割ではないのです。それらは入り口の判断であり、Shopifyはネイティブには行いません。注文受付ウィンドウのレイヤーを追加し、そして境界線を明確にしましょう。あなたが制限しスケジュールするのは**新規受付**であり、その間も課金アプリは既存会員の更新を予定どおり続けます。

[OrderRulesを無料で始めて](/pricing)、各サイクルを実際に梱包できる数に制限し、締め切りを設定して、「またボックスを売りすぎた」を「売り切れ — キャンセル待ちに登録」に変えましょう。