欠品と過剰在庫を減らす発注点の決め方

ノートや紙小物を8SKU（色や仕様ごとの最小管理単位）扱うネットショップを、店主1名で運営している場面を想像してみてください。週に60分ほど在庫確認の時間を確保し、今回の仕入れに使える上限予算を税込10万円（現金支出枠）と設けていても、売れ行きが良い商品の在庫が急に切れて慌てて手配したり、欠品を避けようと多めに仕入れて保管棚や手元資金を圧迫したりすることがあります。

こうした在庫の偏りを抑え、仕入れの手配を始める基準となるのが「発注点（はっちゅうてん）」です。発注点は「仕入先へ注文を出す合図」であり、1回に何個注文するかという発注数量や、仕入予算の総額を決める数字ではありません。まずは全体の合計数ではなく代表的な1商品（1SKU）に絞り、日々の販売数量や手元に届くまでの期間を同じ単位にそろえて、どのタイミングで合図を出すべきかを考えます。

本稿ではこの架空店を例に、発注点の計算手順を順を追って見ていきます。なお、本稿に登場する数値は計算の考え方を説明するための仮定であり、特定の業種や店舗の推奨値や需要予測ではありません。

どのSKUを、何個・何日で見る？

全商品をまとめた合計数ではなく、色や仕様ごとに分けたSKUを1つ選び、数量は「個」、期間は「暦日」にそろえて計算します。

SKUとは、色やサイズ、仕様ごとに在庫と販売を個別に追跡する商品単位です。8SKUを扱う文房具店であれば、全体の数字でまとめて発注点を出すのではなく、まずは基準を作りたい代表の1SKUを取り出します。仕入先とのやり取りでは箱やダースなどの単位が使われることもありますが、販売実績に合わせてすべて「個」に換算します。また、販売期間と調達期間の日数の数え方も、営業日かカレンダー通りの暦日かのどちらかにそろえます。

発注の判断に使う販売可能在庫は、注文に確保済みの在庫や販売不可の在庫、未着の入荷予定と分けて確認します。Shopifyの在庫レポート定義（2026年10月10日確認）では、2026年10月1日以降の月末在庫スナップショットは手元総数（On hand）を使い、確保済みと販売不可を含み、未着分を含みません。9月30日以前の履歴は販売可能数のままです。そのため、月末レポートの数量をそのまま「今売れる数」として発注点に当てはめず、同じ時点の販売可能数を確認します。以下の架空例の54個は、その販売可能数です。

1日販売数は、どの期間から出す？

同じSKUの販売数量を、そのSKUが販売対象として有効だった期間の日数（暦日）で割って算出します。

Shopifyの在庫レポートにおける在庫残日数（Inventory remaining）の仕様では、1日あたりの販売数量（Quantity sold per day）を算出する際、対象期間（過去28日間基準）の中で当該バリエーションが有効（active）だった日数で販売数量を割る計算式がとられています（同レポートの日次販売率とは別指標です）。全商品を一律に固定の28日で割るのではなく、対象期間に有効だった日数で計算されます。なお、これは販売可能在庫があった日数そのものと同一ではなく、また販売数量には返品や手動調整、倉庫間の振替受領などの在庫調整は含まれません。注文手続きの件数ではなく、実際に販売された商品個数をもとに計算します。

本稿の架空店では簡易モデルとして、代表SKUが過去28暦日のあいだ常に有効で欠品等による調整もない前提を置き、「84個 ÷ 28暦日 ＝ 1日あたり3個」と計算します。もし期間中に在庫切れの日があった場合、その日を単純に「需要がゼロだった日」として扱うと実態より販売ペースを低く見積もってしまいます。集計対象にした期間や除外した条件を把握し、通常の販売実績と一時的な欠品などの要因を分けて整理することが大切です。

販売可能になるまで、何日かかる？

仕入先に注文書を送った日から、店舗に荷物が届き、検品や在庫反映を終えて販売可能になるまでの全日数（暦日）で測ります。

Oracle NetSuiteの在庫管理マニュアルでは、発注点の計算方式として「平均リードタイム日数 × 需要 ＋ 安全在庫数量」が案内されています。Oracleの製品定義では発注から受領までの期間をリードタイムとして扱いますが、今回の架空店モデルでは、自店の運用に合わせて荷受け・検品・システムへの在庫反映を経て、顧客が購入できる状態になるまでの日数を含めて考えます。

架空店では、発注から販売可能になるまでの期間を10暦日と仮定します。仕入先の案内納期だけでなく、自店の受入や検品にかかる日数、仕入先の休業日を含めたカレンダー通りの暦日で計算します。天候や繁忙期によって到着が遅れる可能性も考慮し、直近の実績をもとに日数を設定します。

安全在庫12個は、どう決める？

全SKUで同じ数量にするのではなく、販売ペースや納期のばらつき、欠品時の影響、保管期限や保管容量、手元資金のバランスを見てSKUごとに仮置きします。

Oracle NetSuiteの在庫最適化機能では、発注点を「安全在庫 ＋ 平均リードタイム × 平均日次需要」とし、需要やリードタイムのばらつきから安全在庫を統計的に算出する手法も案内されています。

本稿の架空店では、こうしたばらつきの計算をすべて厳密に行うのではなく、自店の運用条件に合わせて代表1SKUの安全在庫を12個と仮定して進めます。これは1日3個の販売ペースに対して約4日分に相当しますが、4日分という期間や12個という数量は架空の仮定であり、全店舗共通の推奨値や最適値として計算された確定値ではありません。安全在庫を多く持ちすぎると保管スペースや仕入資金を圧迫するため、商品の保管容量や資金の余裕と照らし合わせながら数量を置き、設定した根拠と次回の見直し日を記録しておきます。

発注点42個を、どう計算する？

発注点は「1日あたりの平均販売数 × 販売可能になるまでの日数 ＋ 安全在庫」で計算します。手配を始める水準を示す合図であり、一度に注文する発注数量ではありません。単位をそろえた架空店の数値を当てはめると、次の計算表のようになります。

現在の販売可能在庫54個は注文引当済みを除外した数量のため、ここからさらに引当分を二重に差し引く必要はありません。未入荷の発注残が0個の状態で今後も1日3個のペースで売れ続けた場合、約4日後（12個 ÷ 3個/日）に発注点へ達する試算になります。ただし、この4日後という試算は売れ行きが一定と仮定した目安であり、販売の増減によって到達時期は前後するため、特定の日付での発注を保証するものではありません。

発注点と発注量・発注残はどう分ける？

発注点は手配を始めるタイミングの合図であり、発注量（何個注文するか）は発注残や仕入条件を確認して別の計算で決めます。

発注量を考える際に確認が必要なのが「発注残（未入荷の注文数量）」です。すでに仕入先に注文済みで、まだ手元に届いていない商品がある場合、その数量を確認せずに発注点に達したからと追加発注すると、後から商品が重なって届き過剰在庫になってしまいます。

Shopifyの発注書機能では、商品、数量、費用、支払条件、仕入先情報を記録でき、注文後は在庫転送機能で輸送や受領状況を追跡できます。仕入先への発注量を決める際は、仕入先ごとの最低注文数やケース入数（箱単位の入数）、送料、支払条件を自店で確認します。

架空店では、今回の仕入れ上限予算を税込10万円（現金支出枠）と仮定しています。この10万円は資金繰りの上限であり、予算を使い切るために注文量を増やしたり、予算額だけで発注量を決めたりするものではありません。発注残が0個であることを確かめた上で、需要の予測、保管棚の空き状況、仕入単位、そして税込の支出上限を合わせて検討し、発注量を判断します。

いつ数字を更新し、アラートを変える？

販売ペースの変化、納期のブレ、実在庫とのズレ、発注残の状況に合わせて、定期的に設定数値を見直します。

Squareの在庫少アラートは、在庫数が設定した閾値を下回った際に店舗へ通知する機能です。ここで注意したいのは、「在庫が閾値を下回ったとき」に通知されるツールの条件と、「在庫が42個に達したとき」という自店の発注合図では判定の条件が異なる点です。閾値を42と設定しても42個ちょうどで通知されるわけではないため、利用するツールの通知条件と自店の合図を照合した上で設定値を決める必要があります。また、このアラートは通知を行う仕組みであり、仕入先への自動発注や入荷の完了を行うものではありません。通知を受け取った際や日々の確認時には、発注残と現在の在庫状況を確かめて発注判断を行います。

架空店では、店主が週に60分の作業枠を確保して8SKU全体の前提条件を見直しています。この週60分の枠は条件を振り返るための作業時間であり、日々の在庫確認や発注を週1回に限定するものではありません。売れ行き次第では数日で発注点に達する可能性もあるため、翌週の確認枠を待たずに日々の動きに合わせて手配を判断し、週の作業枠では「実際の調達日数は10日だったか」「販売ペースや安全在庫12個の仮定にズレがないか」を実績と照らし合わせて数値を更新します。

---

• Shopifyの在庫レポート定義を確認する
• 在庫の発注点計算機を使う

関連記事

• ネットショップの発注量の決め方｜販売予測・発注残・仕入れ単位で計算する
• ECの在庫回転率と滞留在庫対策｜販売率・在庫日数の見方