ECサイトの開発・運用

定期購入で在庫不足になる？次回注文・欠品・在庫連携の判断基準

執筆・編集：ENOL

定期購入の次回注文で在庫不足や欠品が起き、補充後の再処理や顧客連絡を手作業で行っている中小EC事業者向けの記事です。

在庫の置き場所が複数に分かれたままだと、次回注文の作成時に在庫不足へ気づく、補充したのに別画面へ反映されない、といった確認作業が残ります。

まず1商品だけ選び、「在庫数を最終的に正とする場所」と「次回注文で在庫を確認する時点」を書き出してください。ここが分かると、標準機能で足りるのか、外部連携が必要なのかを切り分けやすくなります。

結論：在庫不足そのものより、在庫をどこで・いつ見るかを先に決める

定期購入の在庫不足は、すぐにシステム開発が必要という意味ではありません。利用中のECや定期購入機能に在庫追跡、不足時の保留、補充後の再処理が用意されているなら、まずその標準機能で運用できるかを確認します。

一方で、EC、店舗、倉庫、在庫管理サービスなど複数の場所で在庫数を更新し、どれが正しい数か分からない場合は、設定だけでは手作業が残ることがあります。その場合も、EC全体を作り直すのではなく、在庫を受け渡している部分だけを整理します。

在庫の正本、次回注文で在庫を見る時点、標準機能で足りる範囲を順に確認し、二重更新が残る場合だけ連携を検討します。

同じ商品在庫を、EC管理画面、店舗の販売管理、倉庫、別の在庫管理サービスなど複数の場所で持っている場合は、最初にどこを正本にするか決めます。

この答えが曖昧なまま連携を増やすと、同じ在庫を複数画面から更新して数がずれる原因になります。

定期購入では、初回購入時だけでなく、次回注文を作るタイミングでも在庫の扱いが重要です。サービスによって、注文作成時、請求時、出荷準備時など在庫を確認する場面が異なります。

Shopify Subscriptionsの例では、在庫追跡を有効にし、在庫切れ販売を許可していない商品について、次回配送時に在庫が不足していると注文が作成されず、「Inventory error」として確認できます。補充後は再請求でき、在庫が足りれば次の注文作成を進められます。

これはShopify Subscriptionsの例です。別のECサービスや定期購入アプリでは動きが異なるため、利用中サービスの「次回注文」「在庫不足」「再請求」の手順を提供元で確認してください。

次の条件なら、まず標準の在庫管理と社内の補充手順で運用できる可能性があります。

この状態なら、提供元の標準機能を使い、補充担当とEC担当の確認タイミングを決めるだけで足りることがあります。

標準機能で在庫不足を検知できても、倉庫や店舗の在庫を別途入力し直しているなら、手作業は残ります。たとえば次のような状態です。

この場合は、最初にCSVなど既存の出力・取込で二重入力を減らせないか確認します。リアルタイム連携が必要かどうかは、売り切れや欠品が起きる頻度、更新の遅れが業務へ与える影響を見て決めます。

倉庫や在庫管理サービスを正本にできていても、ECへの反映が人手で遅れる場合は、必要な在庫情報だけをつなぐ方法が候補です。

検討するのは「すべての在庫機能を作る」ことではなく、どの在庫数を、どのタイミングで、どこへ反映するかです。たとえば、利用可能在庫だけをECへ渡す、キャンセル時だけ在庫を戻す、といった必要範囲に絞ります。

連携を増やす場合は、接続先の仕様変更、通信失敗時の扱い、二重更新を防ぐルールも保守範囲になります。これらを決めずに自動化すると、エラー時の確認先が増えるため注意が必要です。

方法	向いている状態	確認すること
今の補充運用を整理	在庫の正本が1つで、不足時の対応件数が少ない	誰が不足を確認し、いつ補充するか
EC・定期購入の標準機能	不足時の保留や補充後の再処理が用意されている	在庫を確認する時点と再処理手順
CSVなど既存の受け渡し	在庫数の手入力が残るが、定期的な更新で足りる	正本、更新頻度、全件更新か差分更新か
必要部分だけ外部連携	倉庫・店舗・在庫管理サービスとの反映遅れが受注に影響する	更新元、反映先、エラー時の戻し方