ブログ /
Shopify の在庫切れを防ぐ需要予測の基本｜SMA から始めて段階的に高度化する
TL;DR
- 需要予測は「将来の販売数を当てるゲーム」ではなく 「在庫が切れる前にアラートを出す仕組み」 と理解するのが現実的。
- 最初は 単純移動平均（SMA、Simple Moving Average） で十分。複雑な統計モデルに振り回されない。
- 再注文ポイント = リードタイム期間中の予測販売数 + 安全在庫。これだけで在庫切れの大半を防げる。
- 日本の EC は お中元・お歳暮・GW・お盆 など季節係数が大きい。海外発のモデルは要調整。
- 高度化（Prophet / 機械学習）は「SMA で困ってから」考える。最初から複雑にすると保守不能。
- ここに書いた計算を全 SKU ぶん自動で回すのが、本サイトが運営する UreyukiBox（Shopify App Store で公開中・Free プランあり）です。
「予測」という言葉に振り回されない
需要予測 / Demand Forecasting というと、「機械学習で未来を当てる」 イメージを持つ方が多いですが、現実はもっと地味です。
実用上の需要予測は:
- 過去の販売実績から「この SKU は週に N 個売れる」というベースラインを出す
- そのベースラインに季節性・トレンドを掛け合わせる
- 再注文ポイントを設定して、在庫がそれを下回ったらアラート
この 3 ステップで、在庫切れの 8 割以上は防げます。残り 2 割は突発的な需要急増（バズ・テレビ放映・季節外れの天候等）で、これは予測モデルでは捉えきれない領域。
単純移動平均（SMA）から始める
最もシンプルかつ有効なベースライン算出方法は Simple Moving Average（単純移動平均）:
過去 N 日間の販売数 / N = 1 日あたりの平均販売数
例: 過去 30 日で 60 個売れた → 1 日あたり 2 個
これだけです。難しい数式不要。
N（窓）の選び方
| 窓 | 使い分け |
|---|---|
| 7 日 | 直近の傾向に敏感、ノイズも拾いやすい。テスト・検証用 |
| 14 日 | 短期トレンド対応、日次変動を吸収 |
| 30 日 | 一般的、月次サイクルを 1 周期含む |
| 90 日 | 季節性の影響を平均化、安定だが新商品には不向き |
最初は 30 日で十分。ストア成長期は短い窓（14 日）で機敏に反応、安定期は長い窓（90 日）に切替える流れが定石。
UreyukiBox が実際に使っている手法
本格的な業務でも、まずは SMA をベースに次の補正を足すだけで実用十分です。UreyukiBox が現に動かしているのもこの組み合わせです。
- 新商品のコールドスタート補正（掲載から 30 日経っていない商品は、窓 30 日ではなく実際の在籍日数で割る。そうしないと新商品の需要がゼロ方向に薄まる）
- たまにしか売れない商品は別手法（5 日おきに 1 個売れる商品を SMA で見ると、窓の端を 1 個が出入りするだけで推定が跳ねる → Croston/SBA に自動で切り替え。詳しくは後述の FAQ）
- 店の国の暦から引く季節係数（販売履歴が1日も無くても効くのがこの手法の要点。統計モデルと違って「去年の山」を学習する必要がありません）。ストアの国コードでカタログを引きます＝日本13（お正月・バレンタイン・ホワイトデー・入学・GW・母の日・父の日・お中元・お盆・敬老の日・ハロウィン・ブラックフライデー・お歳暮）／カナダ10（ボクシングデー・感謝祭ほか）／英国9（マザリングサンデー＝英国の母の日は3月）／フランス9（冬と夏のソルド）／米国8／オーストラリア8（ボクシングデー）／ドイツ7（父の日＝昇天祭）。暦はその国のタイムゾーンで切ります。🔴 カタログの無い国は無補正（1.00 倍）＝知らない国に他国の暦を当てはめることはしません
- 安全在庫は目標サービス率から計算（日次需要のばらつきとリードタイムのばらつきを実データから測って上乗せする。測れるだけの実績が無いときは上乗せせず、従来どおりの決定論的な発注点へ自然に縮退します＝データが無いのに数字を作らない）
なお「在庫 0 の日を需要ゼロと見なしてしまう」問題（欠品期間の除外）は、Shopify 側に在庫の履歴が残らないため どのアプリでも厳密には解けません。UreyukiBox はこれを「解けている」とは書かず、精度の数値をうたわない根拠のひとつとして扱っています。
再注文ポイントの計算
再注文ポイント（Reorder Point、ROP）は 「これ以下になったら発注する」しきい値:
再注文ポイント = 1 日あたりの予測販売数 × リードタイム日数 + 安全在庫
例
- SKU: T シャツ
- 1 日あたりの平均販売数: 2 個（直近 30 日）
- リードタイム: 14 日（仕入先 → 入荷まで）
- 安全在庫: 7 日分 = 14 個
ROP = 2 × 14 + 14 = 42 個
→ 在庫が 42 個を下回ったら発注、42 個以下のうちに新ロット入荷で在庫切れ回避。
この計算を毎回手でやらない方法
UreyukiBox は、この式を全 SKU ぶん自動で回します。平均日販は自店舗の販売実績から、安全在庫は目標サービス率から。リードタイムは過去の入荷実績（発注 → 入荷）を仕入先ごとに集計した実測値を提示するので、空欄のまま勘で埋める必要がありません（採用するかは人が決めます＝勝手には書き換えません）。発注点を下回ったらメール / Slack / LINE に通知し、発注数量を入れた発注書の下書きまで作ります（目標在庫 − 手元在庫 − 入荷予定 − 発注済み、なので二重発注になりません）。
Shopify App Store で公開中。Free プランから試せます。
安全在庫（Safety Stock）の決め方
「在庫切れの確率をどこまで許容するか」で決まります。
| 戦略 | 安全在庫 | 在庫切れリスク |
|---|---|---|
| 強気 | 3 日分 | 中（突発需要で切れる） |
| 標準 | 7 日分 | 低（推奨） |
| 慎重 | 14-30 日分 | 極低（資金繰り・倉庫負担増） |
完全な数式（z 値・標準偏差ベース）もありますが、初期は「リードタイムの半分」を安全在庫にしておくのが実用的。
季節性係数を掛ける
日本の EC は 1 年を通じて販売が均一ではありません。
主要な季節要因
| 時期 | 影響 SKU 例 | 倍率の目安 |
|---|---|---|
| お正月（12 月下旬-1 月） | おせち食材 / 正月飾り / 干支グッズ | 5-20× |
| バレンタイン（2 月） | チョコ / ギフト | 3-10× |
| ホワイトデー（3 月） | 同上 | 2-5× |
| 入学・新生活（3-4 月） | 文具 / 家電 / 家具 | 1.5-2× |
| GW（5 月） | アウトドア / 旅行用品 | 1.5-3× |
| 父の日 / 母の日 | ギフト | 2-5× |
| お中元（7 月） | ギフト食品 | 3-10× |
| お盆（8 月） | 帰省土産 / 仏花 | 2-5× |
| ハロウィン（10 月） | 仮装 / お菓子 | 2-8× |
| ブラックフライデー / クリスマス（11-12 月） | EC 全般 | 1.5-3× |
| お歳暮（12 月） | ギフト食品 | 5-15× |
自店舗の販売実績で「先月比 ×N」のパターンを見つけて、来年の同月に その係数を SMA に掛ける のが基本ロジック。
簡易な実装
季節調整済み予測 = SMA × 季節係数
季節係数は前年同月の販売数 / 前々月の販売数から逆算する手もあれば、業界レポートから流用する手もある。自店舗データが 1 年分溜まってから本格導入で十分。
高度化を急がない
需要予測界には Prophet（Facebook）/ LSTM / XGBoost といった統計・機械学習モデルが揃っています。これらは強力ですが、以下の問題があります:
- 学習データが必要: 1 年分以上ないと意味のあるモデルが作れない
- 保守コスト: モデル再学習・パラメータ調整が継続発生
- 解釈不能: なぜこの予測が出たか説明しづらい
- 精度の伸びは限定的: SMA に対して 5-15% 改善程度がよくある相場
SMA でうまくいかない症状（在庫切れが頻発、過剰在庫が増える）が出てから検討すべき領域です。最初から ML を入れると保守できずに「前のシステムに戻す」が起こりがち。
「予測」と書くか「リマインダー」と書くか
UreyukiBox は 「販売速度に基づくリマインダー」 という表現を使っています。
「需要予測」と書くと:
- ユーザーが精度に過度な期待を持つ
- 当たらなかった時のクレームが「予測精度が悪い」と機能批判になる
- 法令上「データ分析」と「予測」の責任範囲が曖昧
「販売速度に基づくリマインダー」と書くと:
- 過去のペースに基づく示唆であることが明確
- ユーザー側の判断責任が明示される
- 機能としての過剰な期待を抑える
これは v1 設計判断として明示してます（Stocky 終了 ガイド記事も同じ表現）。
v1 → v2 の発展ロードマップ
| フェーズ | アプローチ | データ要件 | UreyukiBox の状況 |
|---|---|---|---|
| 入口 | SMA（30 日）+ 固定の安全在庫日数 | 30 日以上の販売実績 | 稼働中 |
| +α | + 新商品のコールドスタート補正 | 販売開始からの日数 | 稼働中 |
| +α | + 間欠需要（Croston / SBA）の自動切替 | 疎な販売履歴 | 稼働中 |
| +α | + サービス率ベースの安全在庫（需要・リードタイムのばらつき） | 入荷実績が数件 | 稼働中 |
| +α | + 店の国の暦による季節係数（7カ国・日本は年間13イベント） | 不要＝履歴ゼロの初日から効く | 稼働中 |
| 先の話 | 前年同月比からの季節係数の自動算出 | 1 年分 | 検討中 |
| 先の話 | Prophet / 統計モデル・ML | 1〜2 年分 + 検証期間 | 予定なし（費用対効果で判断） |
多くの店舗は上段の組み合わせで困らないのが実態です。統計モデル / ML は「これで困ってから」で十分間に合います。
FAQ
Q. 既に Stocky を使ってきたが、UreyukiBox に移行したら予測精度はどう変わる？
A. ベースラインは Stocky と同じ SMA なので、移行直後は Stocky で見ていた数字とほぼ一致します（販売実績は Shopify から直接同期するので、移行作業も要りません）。差が出るのはその先——季節係数（日本のストアなら お正月〜お歳暮の年間13イベント。海外ストアはその国の暦）、間欠需要の別手法、サービス率ベースの安全在庫が乗る部分で、これらはすべて稼働中です。
Q. 1 日あたり 0.1 個しか売れない SKU はどう扱う？
A. SMA だと窓の端で 1 個が出入りするたびに推定が跳ね、発注点が日ごとに動きます。UreyukiBox は 販売パターンを判定して、間欠・散発型の SKU だけ Croston 系（SBA）に切り替えます。需要を「1 回あたりの数量」と「需要が起きる間隔」に分けて平滑化する手法で、疎な系列でも推定が安定します（SBA は Croston の既知の過大バイアスを補正した版なので、過剰発注側に倒れません）。
Q. 仕入先のリードタイムが日によって違う場合は？
A. 最大値（保守側）を使うのが基本。例: 通常 14 日だが繁忙期は 21 日 → 21 日でセット。ROP が大きくなって資金繰り圧迫があるなら、仕入先別に係数を分ける運用にする。
Q. SMA より EMA（指数移動平均）の方が良い？
A. 直近の変動に敏感に反応させたい場合は EMA の方が優れます。ただし運用上の差は小さく、窓の長さ（7 / 14 / 30 / 90 日）を変えるほうが効きます。UreyukiBox は SMA を基本に、疎な SKU だけ指数平滑を使う Croston/SBA へ切り替える設計です。
Q. 機械学習で予測したい
A. 機械学習エンジニア（社内 or 外注）が居なければ やめておくのが安全。モデル運用は「学習・評価・パラメータ調整・再学習」の継続コストが大きい。SMA でルール化してから、本当に必要なら専門家に相談。
まとめ
需要予測は「シンプルなロジック + 運用での磨き込み」が王道です。
- SMA（30 日）でベースライン
- 安全在庫 = リードタイム / 2
- 再注文ポイントを設定
- 季節性は 自店舗データ で 1 年分溜めてから
これだけで多くの問題は解決します。複雑なモデルは「SMA で困ってから」。
UreyukiBox を始める
この記事の内容を、全 SKU ぶん自動で回すのが UreyukiBox です（Shopify App Store で公開中）。
- ベースライン——販売実績から平均日販を算出（新商品はコールドスタート補正、疎な SKU は Croston/SBA へ自動切替）
- 発注点——平均日販 × リードタイム + 安全在庫。リードタイムは過去の入荷実績から仕入先ごとに提示、安全在庫は目標サービス率から計算
- 季節性——ストアの国の暦から係数を引きます（日本は年間13イベント＝お正月からお歳暮まで。ほか米・加・英・豪・独・仏の計7カ国）。「1 年分のデータが溜まるまで待つ」必要がありません＝履歴から季節性を学習する方式では原理的に読めない「その店が初めて迎える山」に、初日から備えられます
- アラート——発注点を下回るとメール / Slack / LINE に通知
- その先——発注数量を入れた発注書の下書き（インボイス対応の PDF / CSV・仕入先へメール送信）、入荷登録、在庫調整・棚卸し、実原価と粗利レポートまで同じアプリの中で
料金は Free（商品 100 点まで）／ Starter ¥2,980 ／ Pro ¥5,980 ／ Business ¥12,800（月額・税抜、有料プランは 14 日間の無料トライアルつき）。インストールはこちら。
Stocky からの乗り換えで、まずはデータを救出したい方は Stocky データ移行の実務ガイドもあわせてご覧ください（移行は無料プランのまま実行できます）。