需要予測は、小売、製造、食品、物流、SaaSの利用量見積もりまで、幅広い現場で意思決定の土台になるテーマです。しかし、実際に機械学習で導入しようとすると、モデル選定より前の段階でつまずくことが少なくありません。たとえば、売上データが日別と週別で混在している、欠品なのに需要がゼロとして記録されている、販促情報が表計算にしか残っていない、といった状況です。AWSは需要予測の実務で、在庫切れや過剰在庫の抑制、補充判断の改善に予測が直結すると説明しています。また、scikit-learnの時系列サンプルでも、ラグ特徴量や時間特徴量を適切に作ることが予測性能に大きく効くことが示されています。つまり、需要予測は「高度なモデルを使えば当たる」という話ではなく、業務データを予測可能な形へ整え、現場の意思決定に耐える運用へつなげることが本質です。この記事では、基本的な考え方からデータ準備、特徴量設計、販促や欠品などの外部要因の取り込み、現場で使えるモデルへ育てる手順までを整理します。
最初に押さえたい前提
- 需要予測では、モデル精度より先にデータの意味づけを揃える必要があります。
- 売上は需要そのものではなく、欠品や販促の影響を受けた観測値です。
- 本番で使える予測にするには、再学習、評価、例外対応まで含めて設計することが重要です。
需要予測の基本と代表ユースケース
需要予測の目的は、単に未来の売上を当てることではありません。実務では、発注量の最適化、欠品の予防、廃棄の削減、人員配置、配送計画、販促計画の見直しなど、意思決定に使える形で未来を見積もることが求められます。たとえば小売では、店舗別・SKU別の日次予測が補充や棚割りに直結しますし、食品では曜日や天候によって大きく変動するため、当日朝の予測精度が重要になります。製造業であれば、部材の調達リードタイムを踏まえた週次や月次の予測が必要です。さらに、サブスクリプション型サービスでも、問い合わせ件数、API利用量、サーバー負荷の予測が運用コストと品質に影響します。AWSの事例でも、需要予測は在庫切れの低減や過剰在庫の圧縮に役立つとされています。まず押さえたいのは、どの粒度で、どの先の期間を、何の意思決定に使うかで設計が変わる点です。日次で翌日分を予測するのか、週次で8週間先を予測するのかによって、使うデータも評価指標も変わります。したがって、プロジェクト開始時には「予測そのもの」ではなく、「誰が、いつ、何を決めるために使うか」を先に定義することが重要です。
必要データと前処理の考え方
需要予測で最低限そろえたいのは、時点、対象、実績値の三つです。具体的には、日付または週、商品や店舗などの識別子、そして販売数や出荷数です。ただし、ここで注意したいのは、記録されている数値が“真の需要”とは限らないことです。たとえば在庫が切れて販売できなかった日は、売上がゼロでも需要がゼロとは言えません。そのため、在庫数量や欠品フラグが取れるなら、欠品期間を別扱いにすることが大切です。AWSの需要計画関連資料でも、stockout の把握は補充判断に重要な要素として扱われています。前処理では、まず日付粒度の統一、重複レコードの解消、欠損補完、商品マスタや店舗マスタとの結合を行います。さらに、店舗移転、価格体系変更、商品コード統合のような業務上のイベントも見落とせません。ここを放置すると、モデルは制度変更を需要変動だと誤解します。つまり、前処理の中心は単なる欠損埋めではなく、売上データを業務文脈と結びつけて、学習可能な時系列へ変換することです。最初の実装では、全商品を一括で扱うより、まずは動きが安定した主要SKUや主要店舗に絞るほうが、品質も説明性も確保しやすくなります。
| データ種別 | 具体例 | 確認ポイント |
|---|---|---|
| 実績データ | 日次販売数、出荷数、受注数 | 粒度の統一、重複、欠損 |
| 商品・拠点マスタ | 商品カテゴリ、店舗種別、地域 | コード変更、統廃合の有無 |
| 在庫・欠品情報 | 在庫数量、欠品フラグ、入荷日 | ゼロ売上との切り分け |
| 販促・価格情報 | 値引き率、チラシ、クーポン、広告配信 | 開始日・終了日、対象商品の一致 |
| 外部データ | 天気、祝日、イベント、気温 | 地域対応、取得頻度、欠損 |
特徴量設計と季節性の扱い方
特徴量設計では、時系列らしい情報をモデルへどう渡すかが重要です。scikit-learnの時系列サンプルでは、前日、前週同曜日、24時間前、7日前などのラグ特徴量を作ることで予測に必要な履歴情報を表現しています。また、曜日、月、祝日前後、月初月末といった時間特徴量も、需要の周期性を捉えるうえで有効です。特に日次データでは、月曜に強い、週末に弱い、月末に伸びるといったパターンが出やすいため、曜日だけでなく週番号や営業日フラグも候補になります。さらに、季節性を直線的な数値で持たせるより、sin・cos 変換や周期特徴量として表現すると、年末と年初のような循環を滑らかに扱いやすくなります。重要なのは、将来時点でも利用できる特徴量だけを使うことです。たとえば“当日の実売”や“翌日の在庫”のような未来情報が混ざると、検証時だけ精度が高く見えるリークが起きます。つまり、特徴量設計は単に列を増やす作業ではなく、予測時点で本当に分かっている情報だけで、季節性や直近傾向を再現する作業です。まずはラグ、移動平均、曜日、月、祝日といった基本セットから始め、その後にカテゴリ別や店舗別の特徴を足していくと、実装と説明のバランスを取りやすくなります。
販促・欠品・外部要因をどう組み込むか
需要予測が現場で外れやすい原因の一つは、販促や欠品の影響を通常需要と同じように扱ってしまうことです。たとえば大幅値引き中の売上急増を平常時の需要として学習すると、次回以降の通常予測が過大になります。逆に、欠品中のゼロ売上をそのまま学習させると、本来は売れる商品を「売れない」と覚えてしまいます。そのため、販促はキャンペーンフラグ、割引率、広告出稿量、ポイント還元率などを特徴量として持たせ、欠品は在庫切れフラグや除外ロジックで切り分けることが重要です。さらに、天候、気温、降水量、祝日、大型イベント、学校休暇、地域催事のような外部要因も、商品によっては強く効きます。たとえば飲料やアイスは気温、雨具は降水確率、弁当はオフィス出社率や曜日要因の影響を受けやすいでしょう。ただし、外部要因は何でも入れればよいわけではなく、取得コストと予測時点での入手可能性を見極める必要があります。つまり、実務での勘所は、説明できる変動要因から順に組み込み、効果が確認できたものだけを残すことです。最初から複雑にしすぎるより、価格、販促、欠品、祝日、天気のような主要因を優先すると、改善効果を測りやすくなります。
外部要因を入れるときの注意
予測時点で未来の天候実績は分からないため、必要なら天気予報値を使う設計にします。実績値で学習し、予測時は入手不能という状態になると、本番精度が想定より落ちやすくなります。
現場で使える予測モデルに育てる方法
現場で使える予測モデルにするには、単発の精度検証で終わらせず、評価と運用を回し続ける仕組みが必要です。まず評価では、ランダム分割ではなく時系列順に学習期間と検証期間を分けます。scikit-learnでも、時系列では通常のランダム分割ではなく時間順の検証が重要です。さらに、指標もRMSEだけでなく、業務で解釈しやすいMAEやWMAPEを併用すると、現場と会話しやすくなります。たとえば高単価商品の少量誤差より、定番商品の大量誤差の方が業務影響が大きいなら、重み付きの見方が有効です。モデル自体は、まず移動平均や前年同週比のようなベースラインを置き、その後に勾配ブースティングやツリーモデル、必要に応じて時系列専用モデルへ広げる流れが現実的です。scikit-learnの例でも、ラグ特徴量と HistGradientBoostingRegressor を組み合わせた実装が紹介されています。加えて、本番運用では再学習頻度、予測失敗時の代替ルール、データ欠損時のフォールバック、需要急変のアラートも設計しておくべきです。つまり、良い需要予測モデルとは、コンペで高得点を出すモデルではなく、データ更新に耐え、説明でき、外れた時にも業務が止まらないモデルです。まずは小さく始め、予測値だけでなく発注や補充の結果まで振り返ることで、現場で信頼される仕組みに育てやすくなります。
導入前後に確認したいチェック項目
- 予測対象、粒度、予測期間、利用部門が明確になっているか
- ゼロ売上と欠品を切り分けられているか
- 販促、価格変更、祝日、天候など主要要因をデータ化できているか
- 特徴量に未来情報のリークが混ざっていないか
- ランダム分割ではなく時系列順で評価しているか
- ベースライン予測と比較して改善を確認しているか
- 再学習、フォールバック、監視指標を運用設計へ組み込んでいるか
需要予測の精度を左右するのは、派手なアルゴリズムよりも、データの意味づけと現場運用に合った設計です。まずは主要SKUや主要拠点に絞ってデータを整え、ベースラインと比較しながら特徴量を増やしていくと、精度と運用性の両方を確かめながら前進しやすくなります。
情シス実務のまず読むまとめ
このカテゴリを読むなら、まずこのまとめ記事から入るのがおすすめです。



コメント