多くのEC事業者は、月1回、過去販売平均から経験で発注する「定点定量」方式を続けています。Excelで管理しやすく運用ルールもシンプルで、SKU数が50品以下なら経験と組み合わせて十分に回ります。けれど、年商1.4億円規模・SKU 100超になると、定点定量方式は構造的に限界を迎えます。在庫日数の長期化、カラバリ別の欠品と滞留の同時発生、月次レビューでの判断遅延――どれも「経営者の経験」では補えない領域です。問題は担当者の能力ではなく、仕組みそのものが現在の事業規模に合わなくなっているのです。本記事では、定点定量から「予測型 発注」への構造的転換を、年商1.4億円規模で自分で実装できる5ステップに分解して提示します。3〜6か月で実装可能な現実解です。

第1セクション：定点定量 発注の3つの限界

定点定量 発注は、Excelと経験で回せる手軽さが最大の強みです。けれど、SKU 100品を超えた事業者にとって、構造的な3つの限界が顕在化します。

限界1：経験頼みの安全在庫。 「リードタイム × 1.5」のような固定係数で安全在庫を決めるのが定点定量の典型です。「いつも30日分持っている」「リードタイム60日だから90日分あれば安心」――こうした考え方は、需要のばらつき（週次・月次の変動幅）を反映しません。広告施策、レビュー数、季節イベント、競合価格変更などにより販売速度は大きく変動するのに、安全在庫だけが固定値のまま。結果、ばらつきが大きいSKUは欠品、ばらつきが小さいSKUは過剰在庫、という二極化が起きます。

限界2：カラバリ別の見落とし。 モデル単位で在庫を見るため、カラバリ別の偏りが見えません。スーツケースを例にすると、ブラック・シルバー・ネイビー・レッドの4色展開があるとして、商品全体では月200台売れていても、ブラック150台／レッド20台というように偏ることは珍しくありません。モデル単位で「200台売れている」と判断すると、ブラックは欠品、レッドは滞留――両方が同時に進行します。SKU 100超の事業者では、これが日常的に起こります。

限界3：月次の判断遅延。 月1回まとめ発注のスタイルだと、月中の在庫変動に対応できません。Amazonレビュー急増、楽天イベント開始、SNS拡散、広告配信――これだけでも販売数は2〜3倍になることがあります。月初に立てた計画では月末まで対応できず、判断が2〜3週間遅れます。経営者自身が毎回Excelを開いて判断するため、在庫判断だけで月10〜20時間使っているケースも珍しくありません。

数字例： 年商1.4億・SKU 100の事業者で、定点定量を続けた場合の典型的損失額。

合計すると、年商の3〜6%が「定点定量を続けるコスト」として消えている計算です。

自社で見るべき視点は、 SKU 100品超の段階で「定点定量を続けるコスト」を年額で試算し、転換の意思決定材料にすることです。定点定量方式が悪いのではなく、SKU数やチャネル数が増えた結果、昔は機能していた仕組みが現在の規模に合わなくなっているだけです。

第2セクション：予測型 発注とは何か

予測型 発注は、「需要予測モデル × カラバリ別 × 日次更新」で、発注数を毎日算出する方式です。一言で言えば、「未来の需要を前提に発注数量を決める仕組み」です。

予測型と聞くと、「AIが勝手に全部決める」とイメージされることがありますが、実際は違います。経営者の役割は残ります。 変わるのは判断材料の質です。AIが勝手に発注するのではなく、「毎日、最適な候補を提示する」仕組みです。

構成要素は4つ：

  1. データ集計： Amazon・楽天・自社ECの在庫・販売データを日次で集約
  2. 需要予測： 過去販売数・季節指数・トレンド係数から、SKU別・日次の需要を算出
  3. 供給計算： リードタイム・安全在庫・MOQから、最適発注タイミングと数量を算出
  4. 承認フロー： AI/システムが提案した発注数を、経営者が日次で承認

業界相場として、欧米では多くのEC企業が何らかの予測型を導入、日本でも年商1億超の40%が部分導入しているのが現状です。日本の独立系EC物販で年商1.4億円規模なら、予測型は「導入していて当たり前」の水準に近づいています。

重要なのは、「全自動化」が目的ではないこと。 ゴールは「経営者が承認する判断材料を毎日揃える」ことです。最終判断は人が行い、データ準備と提案を機械が担う、という役割分担です。

数字例： 予測型に転換した事業者の典型値

これは大幅な改善宣伝ではなく、業界で確立された構造的改善幅です。

自社で見るべき視点は、 予測型の4構成要素のうち、自社で既に持っているもの（データ集計だけExcelで日次更新中、など）を棚卸しし、欠けている要素を5ステップで埋めていく順序を決めることです。

第3セクション：ステップ1 — 在庫データの日次更新化

予測型 発注の第一歩は、難しい需要予測ではありません。まず取り組むべきは、「在庫データを毎日見られる状態」を作ることです。

多くのEC事業者では、在庫データを月末や発注日の前日にだけ集計しています。けれどその間にも販売状況は大きく変化します。月に一度しか数字を見ない運用では、この変化に対応できません。

自分でやる場合の手順： Amazon Seller Central・楽天RMS・自社EC管理画面のCSVを毎日朝5分で集計し、1枚のサマリーシートに統合します。CSV3本を Claude に貼り付け、「最新の在庫サマリー（SKU別在庫数・直近30日販売数・在庫日数）を作って」と依頼するだけで、5分で集計完了します。

業界相場の所要時間（年商1.4億・SKU 100規模）：

運用方法 月間工数
手動Excel（VLOOKUP・ピボット・グラフ更新） 月10〜15時間
半自動化（Claude併用） 月2時間
SaaS全自動 月5〜10分

「全部見る」ではなく「異常だけ見る」。 毎日100SKUを目視確認する必要はありません。見るべきは異常値だけです。

このようなSKUだけ抽出すれば、毎朝5分で十分です。「毎日すべてを見る」のではなく、「昨日と違うものだけ見る」という発想転換が日次更新化の本質です。

数字例： 年商1.4億・SKU 100の事業者なら、Claude にCSV3本（各300〜500行）を貼って「在庫日数別に3色（赤120日超／黄60〜120日／緑60日未満）で分類した異常値サマリーを」と指示すれば、5分以内に出力されます。1か月20営業日として、月100分の作業に圧縮できます。

Excel在庫表の限界とClaude連携の実装パターンはExcel在庫表3つの壁で詳しく扱っています。

自社で見るべき視点は、 「在庫データを毎日5分で見られる状態」を、まず2週間続けてみることです。続けると、月次では見えなかった変動が肌感覚として掴めます。

第4セクション：ステップ2 — カラバリ別の需要予測を作る

ステップ2は、モデル単位ではなくカラバリ単位で需要予測を作ることです。

ECでは、同じ商品でもカラーやサイズによって販売速度がまったく異なります。スーツケースのブラックは月150台、レッドは月20台――こうした偏りは、モデル単位の集計では完全に消えてしまいます。発注もSKU単位で考えなければ、過剰在庫と欠品を同時に解消できません。

自分でやる場合の計算式：

翌月の予測販売数 ＝ 過去90日販売数 × 季節指数 × トレンド係数

計算例： 過去90日平均 1日5個 × 夏需要 1.4倍 × 広告強化 1.2倍 ＝ 約8.4個/日。経験だけで「6個くらいかな」と決めるより、判断精度は明確に上がります。

ヒートマップ4色で偏りを可視化する。 カラバリ別に算出した予測と現在庫を並べ、4色で塗り分けます。

ヒートマップ化すると、モデル全体ではなくカラー・サイズ別の問題が一目で分かります。

数字例： 年商1.4億・SKU 100で、カラバリ別ヒートマップを月次更新すると、滞留SKU検知率が70%→95%に上がります。モデル単位だと「全体として適正在庫」に隠れていた滞留カラバリが、ヒートマップでは灰一色で浮かび上がります。

実装の難易度は中程度で、Claude にCSVを渡して「カラバリ別の在庫日数を4色（赤90日超／黄60-90日／青60日未満／灰120日超かつ販売ゼロ）で分類して」と頼めば、初版のヒートマップが10分で作れます。

自社で見るべき視点は、 モデル単位の在庫表を捨てずに、カラバリ別の補助シートを月次で1枚追加することです。捨てる必要はなく、補完が現実解です。

第5セクション：ステップ3 — 安全在庫日数の再計算

ステップ3は、安全在庫日数の計算式を「経験則」から「統計式」へ切り替えることです。

定点定量方式では、「リードタイム60日だから90日分」「いつも1.5倍持っている」という経験則で決めているケースが少なくありません。販売が安定しているSKUも、毎日大きく変動するSKUも、同じ係数で計算してしまうため、売れ筋は欠品し売れない商品だけが残るという状況が起こります。

経験則（定点定量）： 安全在庫 ＝ リードタイム × 1.5。シンプルですが、需要のばらつきを反映しません。

統計式（予測型）：

安全在庫 ＝ 需要のばらつき（標準偏差）× サービスレベル係数 ＋ リードタイム中の予想需要

数字例： 年商1.4億・SKU A（平均日販10個、日次標準偏差4個、リードタイム14日、サービスレベル95%）の場合

統計式の方が、需要のばらつきが小さいSKUでは在庫を圧縮でき、ばらつきが大きいSKUでは安全幅を厚くできます。

SKUごとに最適な在庫日数は違う。 定番商品、季節商品、新商品、イベント依存商品では需要の安定性が異なります。同じ60日のリードタイムでも、毎日ほぼ同じ数量が売れる商品と、広告次第で販売数が3倍になる商品では必要な安全在庫は違います。

SKU 100品全部に統計式を適用すると、平均で在庫日数を20〜30%圧縮できる事業者が多いです。

安全在庫の3方法（経験則／統計式／SKU階層別ハイブリッド）の詳細は安全在庫日数 3つの方法を参照ください。

自社で見るべき視点は、 上位売上10SKUだけ統計式に切り替えてみることです。全SKU一気に変えるのではなく、影響の大きい10品から検証するのが現実解です。

第6セクション：ステップ4 — 月次発注を週次に短縮

ステップ4は、発注頻度を月1回から週1回へ短縮することです。

月1回発注では、月初に発注した後、楽天イベント・Amazon広告・SNS拡散などで販売数が急増した場合でも、次の発注は1か月後です。その間に欠品すれば販売機会を逃します。逆に販売が想定より伸びなかった場合は、大量の在庫だけが残ります。月1回発注は「売れすぎ」と「売れなさすぎ」の両方に弱い運用です。

転換のイメージ： 月4,000個発注するなら、毎週1,000個ずつ見直す方が、需要変化に柔軟に対応できます。特に国内仕入や短リードタイム商品では、この効果が大きくなります。

転換効果：

リスクと対策： 発注作業時間が4倍に増えます。月1回1時間が、週1回30分（月2時間）に。発注書をゼロから作るのではなく、ステップ1〜3で構築した「候補を確認して承認する」運用に変えることで、工数を増やさずに高頻度発注が実現できます。手作業のまま週次発注を始めると、3か月で運用が破綻します。

数字例： 年商1.4億・在庫月商比 2.5倍の事業者が、週次発注に転換して在庫月商比 1.8倍に圧縮した場合

この¥800万円は、次のピーク期の追加仕入・新商品開発・与信枠拡大の元手として使えます。発注点の計算式は発注点の計算式 3ステップも併読ください。

自社で見るべき視点は、 上位売上20SKUだけ週次発注に切り替えてみることです。残りのSKUは月次発注のまま、徐々に週次に拡張するのが現実解です。発注頻度を増やすことが目的ではなく、販売変化に合わせて柔軟に数量を調整できる体制を作ることが目的です。

第7セクション：ステップ5 — 継続改善の仕組み化

ステップ5は、月次レビューで「予測 vs 実績」を比較し、予測モデルを補正する仕組みを作ることです。

KPIは3つ：

レビュー会議の型： 30分・5指標・前月比＋業界比較。

このサイクルを6か月続けると、予測精度が3〜5pt改善します。継続改善は「やる/やらない」の二択で、やらないとモデルが陳腐化します。

数字例： MAPE 30%でスタートした事業者が、月次レビューを6か月続けて MAPE 22%まで改善した場合、欠品率は8%→4%、過剰在庫率は15%→9%まで改善する典型値があります。

予測の前提となる適正在庫日数の計算式は適正在庫日数 3つの計算式も参照ください。

自社で見るべき視点は、 月次レビューを30分の固定アジェンダとして経営会議に組み込むことです。「気が向いたらやる」では、3か月で消えます。

まとめ

定点定量から予測型への転換は、自分でやれば3〜6か月で実装可能です。年商1.4億・SKU 100の典型効果として、在庫評価額¥400〜800万解放、欠品−50%、経営者の判断工数 月10〜15時間削減――というのが、業界の実績幅です。

5ステップを順番に実装するのが現実解で、全部同時はリソース的に無理です。ステップ1（日次更新化）→ステップ2（カラバリ別予測）→ステップ3（安全在庫統計式）→ステップ4（週次発注）→ステップ5（継続改善）の順で、各ステップ4〜6週間を目安に進めてください。

定点定量はExcelで回せる手軽さが強みですが、その手軽さゆえに「移行が後回しになる罠」も同居しています。年商1.4億円規模・SKU 100超のラインを超えた事業者は、転換の経済合理性を年額で試算してみてください。「定点定量を続けるコスト」が、年商の3〜6%（年商1.4億なら¥420〜840万）に達している事業者は珍しくありません。

関連記事

CTA

Arke合同会社では、年商1.4億円規模のEC物販事業者向けに、定点定量から予測型 発注への転換を支援しています。自分で5ステップを実装する場合の60分・無料相談、もしくは AI在庫最適化SaaS「S-wallet」での即時自動化、両方の選択肢をご用意しています。詳しくは arkellc.com からお問い合わせください。S-wallet の詳細は arkellc.com/s-wallet もご覧ください。