小売チェーンA社のAI需要予測：既存WMSに月次の入荷提案を組み込んだ導入事例

課題：欠品と過剰在庫、そして「そのままでは使えない」販売データ

A社は小売チェーンで、導入前は欠品と過剰在庫の両方による損失を抱えていました。一般に、欠品は売れたはずの売上を逃し、過剰在庫は保管の負担や売れ残りのリスクを増やします。どちらか一方を抑えようとするともう一方が悪化しやすいため、需要の見通しを数字で持てるかどうかが改善の出発点になります。

そこでバイナリテックジャパンは、A社に蓄積された4年分の日次販売データを学習に使う方針で分析を始めました。ところが、データは連続しておらず、ところどころ日付が途切れていたうえ、生データのままでは周期もはっきり読み取れませんでした。時系列の予測モデルは通常、等間隔に並んだデータと繰り返し現れるパターンを手がかりにするため、整えないまま投入すると、途切れや雑音まで需要の動きとして覚えてしまいます。

体制と役割：バイナリテックジャパンが担当した範囲

本案件は、バイナリテックジャパンがA社と契約し、プロジェクトの責任を負って実施しました。A社との窓口もバイナリテックジャパンが務め、担当範囲は次のとおりです。

• 業務分析
• データ処理（欠損の判定と補完、特徴量の作成、周期の分析）
• 予測モデルの構築と選定
• A社のWMSへの組み込み
• 定期的な再学習

バイナリテックジャパンは、既存システム（WMS/TMS/MES/ERP）を活かしたまま段階的にAIを導入することを基本の考え方にしています。本案件でもこの考え方に沿って、予測結果はA社が使っているWMSに組み込む形をとりました。

データの欠損と周期をどう扱ったか：前処理の4つの手順

本案件の成否を大きく左右したのが、データの前処理です。バイナリテックジャパンは、欠損の種類を見分けて種類ごとに対処し、その系列からラグと移動平均の特徴量を作り、周期を確かめて季節性を分離してから予測する、という順番で処理を組み立てました。全体の流れは次の図のとおりです。

手順1：欠損を「祝日の休業」「悪天候」「記録漏れ」に分ける

A社の日次販売データの途切れを調べると、原因は三つに分かれました。祝日に店舗が休業した日、悪天候の日、そして販売の記録漏れです。祝日と悪天候による途切れは2〜3日程度、記録漏れは平均で3〜5日連続しており、欠損した日数は全体の約5%でした。

欠損率だけでなく、欠損の原因を区別する必要がありました。三つはいずれも販売データが残っていない日ですが、意味が異なります。祝日の休業と悪天候の日は、データがない理由が分かっている日です。これに対して記録漏れは、売上があったはずなのに数字だけが残っていない日です。一般に、理由の分かっている欠損と記録の不備を同じように補間すると、実際には起きなかった売上を系列に書き込むことになり、本当の需要の動きと記録の不備が一つの系列の中で混ざってしまいます。

実際、本案件の初期には欠損を機械的に補間してから予測モデルの学習に使う方法を試しましたが、予測精度は非常に低い結果にとどまりました。そこでバイナリテックジャパンは、欠損の種類ごとに扱いを変える方針に切り替え、学習データに特徴量を加えました。祝日の休業には、日本の祝日を表す特徴量を加えました。悪天候については、A社が事業を行う地域の天候データを抽出し、その中から悪天候の日を絞り込んで特徴量にしました。補間の対象にしたのは記録漏れの日だけです。休業や悪天候の日を通常の売上で埋めず、祝日や悪天候の日であることを特徴量として明示しておけば、一般にモデルはそうした日の前後の動きを、記録の不備とは区別して学習できます。

判断の対応関係を表にまとめます。理由の列は一般的な考え方として整理したもので、自社のデータに当てはめる際の目安になります。

手順2：ラグと移動平均で直近の動きを特徴量にする

欠損への対処を終えた系列から、バイナリテックジャパンは基本の特徴量を作りました。ラグはLag 7、Lag 14、Lag 21、Lag 28の4つで、いずれも1〜4週前の同じ曜日の実績を参照します。移動平均にはMA 7とMA 28、つまり7日間と28日間の移動平均を使いました。日次の販売データは一般に曜日で動きが変わるため、7日単位のラグで同じ曜日どうしを比べ、移動平均で日々のばらつきをならして水準の変化をつかみます。

本案件では、記録漏れの補完にも、時間のラグや平均を使う手法を用いています。ただし補完と特徴量は役割が別で、一般には補完を先に済ませてから特徴量を計算します。欠けた日を含んだままラグや移動平均を計算すると、特徴量そのものがゆがんでしまうためです。

手順3：フーリエ変換とSTLで周期を確かめる

周期を確かめるため、バイナリテックジャパンはフーリエ変換でデータに含まれる周期を調べました。フーリエ変換は、時系列をさまざまな周期の波の重ね合わせとして捉え、どの周期の波が強く含まれているかを調べる手法です。一方のSTL（Seasonal and Trend decomposition using Loess）は、時系列をトレンド、季節成分、残差に分ける手法で、季節の周期をあらかじめ指定して使います。指定した周期が実際の繰り返しと合っていなければ、一般に季節の動きがトレンドや残差に紛れ込んでしまうため、本案件では先にフーリエ変換で周期を確かめてからSTLの周期を設定しました。

この図は、A社の2つの商品（図中のItem B、Item C）の販売データにフーリエ変換をかけた結果で、横軸が周期（日）、縦軸が振幅です（振幅の数値は匿名化のため非表示）。どちらの商品も最も大きなピークは331.5日に現れ、50日より短い周期の側にも小さなピークが多数見られます。この図は説明のために4年分のデータから約663日分を切り出して計算したもので、検出できる周期は系列の長さを整数で割った飛び飛びの値（約663日、331.5日、221日…）になります。年周期の365日にちょうど当たる候補はないため、年周期は最も近い331.5日のピークとして現れており、本案件ではこれを1年（365日）の季節周期と判断しました。

図はあくまで一部期間の例示です。STLの周期を365日に設定した根拠は、本案件のフーリエ変換の分析で1年周期が確認され、想定外の周期が見つからなかったことにあります。一般に長い周期ほど候補の間隔が粗くなるため、年単位の周期を調べるときは、ピークの位置を候補値の刻みと照らし合わせて読む必要があります。

この図は、A社の別の商品（図中のItem A）の日次販売データをSTLで分解したもので、上から原系列、トレンド、季節成分、残差を並べています（縦軸の数値は販売規模が分からないよう非表示）。原系列には、期間の初めに販売量がほぼゼロに近い低い水準の区間があり、その後に水準が上がって日々の上下が大きくなっています。トレンドはこの水準の変化を滑らかな曲線として捉え、季節成分と残差には日々の細かい上下が分かれて現れています。原系列だけでは読み取りにくい水準の変化と細かな変動を、別々の成分として扱えるようになるのがSTLの利点です。

手順4：季節性を外して予測し、最後に戻す

STLで分解したあとは、季節成分を取り除いた系列を予測し、予測値に季節成分を足し戻す手順をとりました。一般に、ARIMAのような時系列モデルは、日次データで365日のような長い季節周期をモデルの中で直接表現するのが得意ではなく、組み込もうとすると推定すべき要素が増えて計算も重くなりがちです。季節性を先に外しておけば、モデルはトレンドと短期の変動の予測に集中でき、季節性はSTLで推定した形のまま戻せます。前処理の前後で変わった点は次のとおりです。

予測モデルの選定：ARIMA・Prophet・DeepAR+を比べた理由

前処理を終えたデータで、バイナリテックジャパンはARIMA、Prophet、DeepAR+の3つのモデルを比較しました。直近3か月より前のデータで学習し、直近3か月のデータをテストに充てました。時系列の予測では、学習に使っていない直近の期間をテストに残すことで、実際に未来を予測する場面に近い条件で精度を測れます。データをランダムに分けると、テスト期間の前後の情報が学習に入り込み、精度を実際より高く見積もるおそれがあります。

評価指標には、直近3か月の実績との乖離をMAPE（平均絶対パーセント誤差）で測ったものを使っています。MAPEは、予測値と実績値の差の絶対値を実績値で割って平均した指標で、値が小さいほど予測が実績に近いことを示します。比率で表すため販売規模の違う商品どうしでも比べやすい一方、一般に実績がゼロに近い日が多い系列では値が大きく振れやすい点に注意が必要です。本記事では、1からMAPEを引いた値を予測精度として併記します（MAPE 0.13なら精度87%）。

比較の結果、データ量が多くない条件では、機械学習モデルであるARIMAとProphetのほうが、深層学習モデルのDeepAR+より良い結果になりました。深層学習モデルは多くのデータから複雑なパターンを学ぶことに強みがある一方、一般にデータが少ないと学習が安定しにくい傾向があります。加えて、手順3で1年周期が確認でき、A社のデータは季節性が比較的はっきりしていたため、バイナリテックジャパンはSTLで季節性を分離し、残りをARIMAで予測する「ARIMA＋STL」の構成を採用しました。

手順1・2で作った祝日・悪天候・ラグ・移動平均の特徴量は、ARIMAの学習の入力として使いました。一般に、特徴量をモデルに渡すときは、予測する時点でその値が手に入るかどうかを確かめておく必要があります。祝日のように前もって分かる情報、天候のように予報に頼る情報、ラグのように予測の先の長さによっては実績がまだない情報とでは扱いが変わるため、設計の早い段階で整理しておくと手戻りを防げます。

既存WMSとの連携：月次の入荷提案として届ける

予測結果は、A社のWMSに組み込む形で業務につなげました。システムが出すのは、月ごとの倉庫への入荷提案です。予測結果を既存の業務システムの中で受け取れるようにすると、担当者は新しい画面やファイルを行き来せずに済み、一般に予測が日々の業務に定着しやすくなります。システム構成とデータの流れは次のとおりです。

連携の方式やセキュリティ、運用監視の具体的な内容は、この事例では扱っていません。需要予測の仕組みと既存システムとの連携の考え方は、需要予測・在庫最適化AIとAI × WMS / ERP強化のページで紹介しています。

期間と運用：MVP3か月と、3か月ごとの再学習

本案件では、MVP（最小限の機能を備えた最初の版）のフェーズに3か月をかけました。運用に入ってからは、予測モデルを3か月に1回再学習し、精度の改善を図っています。この間隔は、A社が定期的に行っている評価のスケジュールに合わせて決めたものです。品ぞろえや売り方、顧客の行動が変わると、過去のデータから学んだパターンと実際の需要との間にずれが生じるため、需要予測モデルは一般に作って終わりではなく、定期的な再学習を前提に運用します。

結果：運用6か月後の前年同期比

学び：精度を決めたのはアルゴリズムより前の工程だった

よくある質問