「需要予測を入れれば、在庫は減るはずだ」
そう考えて機能を使い始め、予測の数字は出たのに、在庫が変わらない。
珍しい話ではありません。
NetSuiteの需要予測とは、過去の販売や商談のデータから、品目ごとの将来の需要を計算する機能です。
手法は、移動平均・線形回帰・季節平均・販売予測の4つあります。
4つから1つを選ぶのではなく、商品の売れ方ごとに手法を分けて使います。
在庫は、形を変えた現金です。
多く持てば資金が寝て、足りなければ販売の機会を逃します。
予測の数字は、発注につながったときに初めて、この現金を動かします。
では、予測と発注のあいだで、何が途切れているのか。
この記事で分かること
- NetSuiteの需要予測で使える4つの手法の仕組み
- 商品の売れ方に合わせた手法の選び方
- 使う前に整える機能とデータ
- 需要予測を含む導入で、費用と期間を左右するもの
- 手法選びでよくある3つの失敗と、予測を発注につなげる進め方
SKU（エスケーユー）は、在庫を管理する最小の単位です。
同じ商品でも、色やサイズが違えば別のSKUになります。
NetSuiteの需要予測とは
Oracleのヘルプでは、需要計画を「過去の需要か、見込みの需要にもとづく、品目の将来の需要」を示すものと説明しています。
計算の方法は2つです。
- 販売の履歴を見て、似た傾向で将来を見立てる
- 商談・見積・受注など、いまの需要から見立てる
（出典：Oracle NetSuiteヘルプ（Demand Planning）、2026年9月確認）
予測した需要は、その先の供給計画につながります。
発注書、作業オーダー（製造の指示）、拠点をまたぐ移動。どれも予測が土台です。
流れを図にすると、次のとおりです。
全体の流れは、NetSuiteの需要予測（Demand Planning）完全ガイドで扱っています。
日本では、2024年7月に日本の製造業向けのSuiteSuccess Manufacturing Editionが発表されました。
その中で需要計画は、過去の需要・季節性・商談中の案件・販売予測から、在庫の必要量を予測する機能と紹介されています。
（出典：日本オラクル発表、2026年9月確認）
4つの手法をひと目で比較
仕組みは、Oracleのヘルプの説明にもとづきます。
（出典：Oracle NetSuiteヘルプ（Calculating Item Demand）、2026年9月確認）
| 手法 | 仕組み | 向く商品 | 履歴の目安 |
|---|---|---|---|
| 移動平均 | 過去の需要の平均を、先のすべての期間に同じ値で当てる | 安定して売れる定番品 | 3〜6か月 |
| 線形回帰 | 過去の需要に最小二乗法で直線を当て、延ばす | 伸びている・縮んでいる商品 | 6〜12か月 |
| 季節平均 | 過去の需要から季節の傾向を読み、先に当てる。予測の間隔は月次 | 季節で売れ方が変わる商品 | 12〜24か月 |
| 販売予測 | 営業の将来の予測データを使う | 受注型の商品・新商品 | 履歴は不要 |
履歴の目安は、NetSuite認定パートナー（Solution Provider）であるベンチャーネットが、手法の仕組みから考えた目安です。
Oracleのヘルプに、推奨の期間の記載はありません。
実際の期間は、計算のたびに「過去の分析期間」として指定します。
最小二乗法とは、過去の点に最もよく合う直線を引く計算の方法です。
手法ごとの特徴
移動平均｜安定して売れる定番品に
過去の需要を平均し、その水準を先の期間に当てます。
ヘルプでは、需要のばらつきをならす働きがあると説明されています。
向くのは、消耗品や標準の部品など、波の小さい商品です。
山と谷が予測に出ないため、季節商品や急成長の商品には向きません。
線形回帰｜伸びている・縮んでいる商品に
過去の需要から傾向を読み、直線で延ばします。
移動平均との違いは、増えているか減っているかの「向き」を捉える点にあります。
成長期の商品や、終売に向かう商品に合います。
ただ、急な変化の直後は、直線が現実に追いつきません。
季節平均｜季節で売れ方が変わる商品に
過去の需要から季節の傾向を読み、先の期間に当てます。
ヘルプでは、この手法を使うときは予測の間隔を月次にする必要があるとしています。
季節の山谷を読むには、1年分以上の履歴を目安にする。これがベンチャーネットの考えです。
履歴が足りない間は、移動平均か線形回帰で回します。
履歴がそろってから切り替えても遅くはありません。
販売予測｜受注型・新商品に
営業の将来の予測データから需要を見立てます。
ヘルプでは、現金売上・請求書・見積・商談・受注・出荷の取引が使われると説明されています。
ほかの3つは、過去の実績を使います。
販売予測だけが、これからの商談を使う。
そのため、過去の分析期間の指定は要りません。
商談の確度をAIで補正する余地があるのも、この手法です。
営業側の予測の精度は、NetSuite SFAで実現する販売予測で扱っています。
売れ方で手法を選ぶ
自社のSKUを、次の4つの売れ方に分けてみてください。
- 安定して売れる定番品→移動平均
- 伸びている・縮んでいる商品→線形回帰
- 季節で売れ方が変わる商品→季節平均
- 受注型・履歴がない新商品→販売予測
ヘルプの手順では、需要の計算の画面で手法を1つ選び、対象の品目を選んで計算します（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
そこで、売れ方ごとに品目をまとめ、グループごとに計算を分けて回します。
たとえば、日用品を扱う卸売の会社（架空の例）なら、次のように分けます。
| グループ | 例 | SKUの数（架空） | 手法 |
|---|---|---|---|
| 定番の消耗品 | 洗剤・ティッシュ | 300 | 移動平均 |
| 伸びている商品 | 新しい詰め替え品 | 40 | 線形回帰 |
| 季節商品 | 虫よけ・カイロ | 60 | 季節平均 |
| 法人の大口の案件 | 施設向けの一括納品 | 20 | 販売予測 |
計算は4回に分けて回します。
グループを増やしすぎると、回す手間が増えます。
最初は4つ程度に抑えるのが現実的です。
新商品には、もう一つの手があります。
ヘルプでは、別の品目の履歴を使って需要を計算する設定（Alternate Source Item）が紹介されています。
同じ種類の品目である必要があります。
似た既存の商品の履歴を借りれば、実績ベースの手法も使えます。
見分けにくい商品もあります。
安定して見えて、ゆるやかな季節性が隠れている商品です。
月ごとの販売数をグラフにすれば、たいていは見分けがつきます。
使う前に整える機能とデータ
ヘルプでは、次の設定が案内されています。
（出典：Setting Up Demand Planning／Demand Planning on Item Records、2026年9月確認）
- 高度な在庫管理（Advanced Inventory Management）を有効にする
- Demand Planningの機能を有効にする
- 組立品目に使う場合は、作業オーダーの機能もオンにする
- 品目ごとに補充の方法を設定する
補充の方法には、注意点があります。
ヘルプでは、MRP（資材所要量計画）の品目も需要計画は使えるが、旧来の方式の供給計画とは組み合わせないと説明しています。
あわせて、MRPが旧来のTime-Phased Planningを置き換えるとしています。
供給計画の選び方は、NetSuiteのSupply Planning（MRP）とはを参照してください。
データの土台は、品目ごとの販売履歴とリードタイムです。
欠品で売れなかった期間は、需要が少なく見えます。
この点は、履歴を読むときに差し引いて考えます。
予測のずれを記録する
手法が合っているかは、予測と実績の差で見ます。
月ごとに、次の表を品目のグループ単位でつけます。
| 月 | 予測 | 実績 | 差（差の率） |
|---|---|---|---|
| （架空の例）4月 | 100 | 80 | +20（+25%） |
| （架空の例）5月 | 100 | 120 | −20（−17%） |
見るのは、差の大きさより向きの偏りです。
毎月プラスなら、予測がいつも多すぎます。
季節商品で夏にマイナス、冬にプラスが続くなら、季節平均への切り替えを考えます。
差の率は、差を実績で割って出します（数字はすべて架空の例です）。
判断の物差し｜予測の仕組みを入れる段階か
| 条件 | NetSuiteの需要予測が合う | いまは入れなくてよい |
|---|---|---|
| SKUの数 | 数百以上で、人の目で追えない | 数十で、担当者が把握できる |
| 履歴 | NetSuiteに販売の履歴がたまっている | 履歴がExcelに散らばっている |
| 使い道 | 発注や生産の判断につなげる人がいる | 予測を見る人がいない |
| 需要の性質 | 売れ方に一定の型がある | 一品ごとの受注生産で、型がない |
右の列に当てはまる項目が多いなら、予測の機能より先にやることがあります。
販売の履歴を1か所に集めること。
考え方をそろえるなら、需要予測とはが入口になります。
在庫と生産の仕組みそのものを比べるなら、Odoo、国産の在庫・生産管理、AIスクラッチ開発での予測も候補です（NetSuiteとOdooの在庫・購買・製造）。
需要予測を含む導入の、費用と期間
需要予測は、高度な在庫管理を前提に、在庫・購買・販売と一緒に動く機能です。
そのため、費用と期間は導入全体で考えます。
ベンチャーネットが支援したNetSuite導入の費用では、3名程度で購買・販売だけの事例が150万円程度・1.5か月でした。
20名程度で購買・販売・在庫・会計まで入れ、情シスがいない事例は、3,000万円程度・2年です。
100名程度で外部システム連携を含めた事例は、2億円程度（うち開発約7割）・1.5年でした。
差を生むのは、機能範囲・開発（特に外部連携）・社内の体制・ユーザー数の4つです。
予測と実績の差の一覧など、開発で補う部分が増えれば、開発の要因が効いてきます。
4つの事例の詳しい条件は、NetSuiteの料金・費用・価格で扱っています。
これから使う会社と、いま使っている会社
これから使う会社は、小さく始めます。
- 主要なSKUを50ほど選び、売れ方で4つに分ける
- グループごとに手法を決め、計算を分けて回す
- 1〜2か月、予測と実績の差を記録してから対象を広げる
いま使っていて見直す会社は、まず全品目に同じ手法を当てていないかを見ます。
予測と実際の発注が離れていないかも、あわせて点検します。
見直すのは、次の3点です。
- 手法ごとに、どのSKUを計算しているか
- 過去の分析期間が、いまの売れ方に合っているか
- 予測と実績の差を見る人と、見る時期
2つの進め方を並べると、次のとおりです。
供給計画に旧来のTime-Phased Planningを使っている場合は、MRPへの移行もあわせて検討します。
手法選びでよくある3つの失敗
失敗1：すべてのSKUに移動平均を当てる
起きること：季節商品の山谷が予測に出ず、繁忙期に欠品、閑散期に過剰在庫になる。
原因：「とりあえず」で、売れ方を見ずに一律の手法にした。
避け方：先にSKUを売れ方で分け、それから手法を割り当てます。
失敗2：最初から全SKUの設定を仕上げようとする
起きること：履歴の整理や設定の議論が続き、運用が始まらない。
原因：需要予測を「一度決めれば終わり」の設定作業と考えた。
避け方：主要な品目に絞って回し、ずれを見て直します。
まず回して直す。それで十分に前へ進みます。
失敗3：予測を発注や在庫の判断につなげない
起きること：予測の数字は出るが、発注は勘のまま。在庫が減らない。
原因：予測を見て発注を決める人と手順を決めていない。
避け方：予測から供給計画、発注までの流れを業務に組み込みます。
担当者の判断の移し方は、需要予測の属人化を解消するにはで扱っています。
3つとも、原因は手法の中にはありません。
売れ方と発注の流れを見ないまま、設定から入ったことにあります。
ベンチャーネットならこう見る｜予測より先に、発注の流れを見える化する
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
需要予測の相談でも、手法の話から始めません。
いまの発注が、どう決まっているかを先に描きます。
型1：見える化→整理整頓→Fit&Gap
需要予測に当てはめると、3つの段はこうなります。
- 見える化：誰が、どの数字を見て、いつ発注を決めているか。現場に聞いて流れを描く
- 整理整頓：SKUを売れ方で4つに分ける。動いていない品目や、重複した品目を片付ける
- Fit&Gap：グループごとの計算と、予測から供給計画への流れを、NetSuiteの標準に照らす
見える化の段で、答えの出る問いが3つあります。
- 在庫で一番お金が寝ている商品はどれか
- その商品の売れ方は、どの型か
- 予測を見て発注を決めるのは誰か
3つ目が決まらなければ、どの手法を選んでも在庫は減りません。
型2：標準に合わせる／開発する／残す
Fit&Gapの後は、ずれた部分ごとに3つから選びます。
| 選び方 | 需要予測での例 |
|---|---|
| 標準に合わせる | 4つの手法を、グループごとの計算で回す |
| 開発する | 予測と実績の差の一覧や、計算の自動化をNetSuiteリブート（ベンチャーネットのアドオン開発）で補う |
| 残す | 売れ方が「ばらばら」の商品は予測に乗せず、担当者の判断に残す |
開発を選ぶほど、導入費用と稼働後の保守の手間は増えます。
まず標準で回し、ずれの記録を見てから開発を決めても遅くありません。
新しい予測の機能は順次提供されるため、提供の時期を確かめてから計画に入れます。
自社のアカウントで使える範囲は、アカウントの担当に確認してください。
今日できること
在庫の金額が大きい上位20のSKUについて、過去12か月の月ごとの販売数を並べてください（1時間以内）。
| SKU | 月ごとの販売数の形 | 当てはまる売れ方 | 手法の候補 |
|---|---|---|---|
| （例）A-001 | ほぼ横ばい | 定番品 | 移動平均 |
形が「横ばい」「右肩上がり・下がり」「山谷」「ばらばら」のどれかを書くだけで足ります。
「ばらばら」が多いなら、販売予測か、予測を使わない運用を考えます。
表ができたら、手法の候補ごとにSKUの数を数えます。
それが、最初に回す計算のグループです。
あわせて、その20品目の発注を誰が決めているかも、横に書き添えてください。
よくある質問
Q1. 履歴が少ない新商品は、どの手法を使えばよいですか
販売予測が第一の候補です。
商談や見積から需要を見立てられます。
似た既存の商品の履歴を使う設定（Alternate Source Item）もあります。
Q2. 手法は途中で変えられますか
計算のたびに手法を選ぶため変えられます。
需要の振る舞いは、時間とともに変わります。
新商品が定番品になったら、手法を見直します。
Q3. 全SKUを同じ手法でまとめてはいけないのですか
おすすめしません。
商品ごとに売れ方が違うためです。
売れ方でグループに分け、グループごとに計算を分けます。
Q4. 需要予測を始めるには何が要りますか
高度な在庫管理とDemand Planningの機能を有効にします。
そのうえで、品目ごとの販売履歴とリードタイムを整えます。
組立品目に使う場合は、作業オーダーの機能も要ります。
Q5. 季節平均で注意することはありますか
予測の間隔を月次にする必要があります。
ベンチャーネットは、1年分以上の履歴を目安にしています。
足りない間は、ほかの手法で回します。
Q6. 予測を入れれば在庫は減りますか
予測だけでは減りません。
予測が供給計画と発注の判断につながって、初めて在庫が減ります。
予測を見て発注を決める人と手順を、先に決めておきます。
Q7. 需要予測を含む導入の費用と期間はどのくらいですか
導入全体の中身で決まります。
ベンチャーネットが支援したNetSuite導入では、3名程度・1.5か月で150万円程度から、100名程度・1.5年で2億円程度までの例があります。
差を生むのは、機能範囲・開発・社内の体制・ユーザー数の4つです（6-1）。
まとめ
- NetSuiteの需要予測は、移動平均・線形回帰・季節平均・販売予測の4つ
- 手法は売れ方で分けて使う。計算はグループごとに回す
- 季節平均は月次、販売予測は履歴が不要、新商品は別の品目の履歴も使える
- 使う前に、高度な在庫管理とDemand Planningの機能を有効にする
- 予測は、発注につながって初めて在庫を減らす
予測と発注のあいだで途切れているのは、多くの場合、手法ではなく「誰が決めるか」です。
上位20品目の表に、発注を決める人の名前を書き込む。
そこから、在庫という現金が動き始めます。
もう少し詳しく知りたい方へ
どの商品にどの手法を当てるか、予測をどう発注につなげるか。
SKUの分け方から、ご相談をお受けしています。
- SaaS型クラウドERP NetSuite導入支援（これから使う方）
- NetSuiteパートナーリプレイス（導入の立て直し・引継ぎ・伴走保守）（使っていて見直す方）
- お問い合わせ
