Umios（旧マルハニチロ）が、時系列基盤モデル「Chronos-2」を活用して販売計画の作成を支援し、年間4,200時間の作業削減を実現した事例が紹介されています。注目すべき点は、単に予測精度の高いモデルを導入したことではありません。販売計画という既存業務の中に予測AIを組み込み、人が判断すべき部分と、機械に任せられる部分を整理したことにあります。
時系列基盤モデルが販売計画にもたらす変化
従来の需要予測では、商品や店舗、顧客などの単位ごとにモデルを構築し、欠損値処理、特徴量設計、ハイパーパラメータ調整、再学習の運用まで個別に作り込む必要がありました。商品数や販売拠点が増えるほど、モデル開発よりもデータ整備と保守の負荷が大きくなります。
時系列基盤モデルは、大規模な時系列データで事前学習されたモデルを、個別企業のデータに適用する考え方です。Chronos-2のようなモデルを利用すると、従来のように対象ごとにゼロから予測モデルを開発せず、過去の販売実績などを入力して将来値を推定できます。データ量が十分でない商品や、頻繁に入れ替わる商品にも適用しやすい可能性があります。
ただし、基盤モデルを導入すれば自動的に高精度になるわけではありません。現場で価値を生むには、予測結果を販売計画の作成画面や承認フローに接続し、担当者が確認・修正できる状態にする必要があります。モデルそのものより、業務プロセスへの接続設計が成否を左右します。
実装で最初に整理すべき「予測対象」
販売計画では、予測対象が単純な売上数量とは限りません。商品、販売チャネル、拠点、期間、在庫、販促施策など、複数の粒度が関係します。最初に次の項目を明確にすることが重要です。
・何を予測するのか：受注数、出荷数、売上金額など ・どの粒度で予測するのか：商品別、拠点別、顧客別など ・どの期間を予測するのか：日次、週次、月次など ・いつ予測を行うのか：計画作成日の時点で利用可能な情報は何か ・予測後に誰が何を判断するのか
特に注意が必要なのは、予測時点では存在しない情報を学習データに混入させる「データリーク」です。確定後の売上や、予測対象期間に実施された販促結果を誤って入力すると、検証時だけ精度が高く見えてしまいます。実際の業務と同じ時点で利用可能なデータだけを使って、時系列に沿ったバックテストを行う必要があります。
Chronos-2を業務システムに組み込む構成
実務では、モデルを直接業務画面から呼び出すのではなく、データ連携、予測実行、結果保存、承認・修正を分離すると運用しやすくなります。
例えば、次のような構成が考えられます。
- 販売実績、商品マスタ、カレンダー、販促情報をデータ基盤に集約する
- 予測対象期間と対象商品を確定する
- 前処理済みの時系列データを推論用の形式へ変換する
- Chronos-2を利用して予測値や予測区間を生成する
- 予測結果を販売計画システムへ保存する
- 担当者が例外や販促要因を確認し、必要に応じて修正する
- 修正前後の値と最終実績を蓄積し、継続的に評価する
ここで重要なのは、AIが出した予測値だけでなく、入力データ、モデルのバージョン、実行日時、担当者による修正理由を記録することです。後から「なぜこの計画になったのか」を説明できなければ、現場での信頼性や監査対応に問題が生じます。
また、推論処理は毎回リアルタイムで実行する必要がない場合もあります。日次や週次でバッチ実行し、計画担当者が確認するタイミングに合わせて結果を準備する方が、コストや障害対応の面で適切なことがあります。モデルの性能だけでなく、実行頻度、推論コスト、再実行方法、タイムアウト時の代替処理まで設計対象になります。
評価指標は予測精度と業務効果を分けて考える
年間4,200時間の削減という成果を評価する際、予測誤差だけを見てはいけません。販売計画業務では、予測を作るためのデータ収集、表計算ソフトへの転記、部門間の調整、例外商品の確認などに多くの時間が費やされています。AIによる価値は、誤差の改善だけでなく、これらの作業を短縮できることにもあります。
評価は少なくとも次の三層に分けると整理しやすくなります。
・モデル評価：MAE、RMSE、MAPE、WAPEなどの予測誤差 ・業務評価：計画作成時間、手作業の件数、修正回数、締め切り遵守率 ・事業評価：欠品率、過剰在庫、廃棄、売上機会損失など
商品によって販売数量の規模が異なる場合、単純な平均誤差では重要商品の影響を適切に評価できません。ゼロ売上が多い商品や、季節変動が大きい商品では、指標の選択にも注意が必要です。さらに、精度が向上しても、担当者が予測を信用せず全件を手作業で作り直しているなら、業務上の効果は限定的です。
導入前に一定期間のベースラインを測定し、AI導入後と同じ条件で比較することが重要です。削減時間も、単なる担当者の体感ではなく、対象業務、人数、作業頻度、繁忙期の扱いを定義して算出するべきです。
人間の確認は「失敗」ではなく業務設計の一部
需要予測には、価格変更、販促、天候、供給制約、取引先都合など、過去データだけでは捉えにくい要因が含まれます。そのため、AIの出力をそのまま計画値にするのではなく、人が確認する仕組みが現実的です。
ただし、全商品を同じ粒度で確認すると、AI導入後も作業量が減りません。予測区間から大きく外れた商品、前月比の変動が大きい商品、在庫制約がある商品などを「要確認」として抽出し、人は例外対応に集中する設計が有効です。これは、人間を最終承認者として残しつつ、確認対象を絞り込むヒューマン・イン・ザ・ループの考え方です。
他社が応用する際の条件と限界
Chronos-2の導入を検討する企業が、最初から全社・全商品を対象にする必要はありません。まずは、過去実績が安定して蓄積され、業務手順が比較的標準化されている領域で検証するのが現実的です。対象を限定して、ベースラインとの比較、担当者の受容性、データ更新の安定性を確認します。
一方で、次のようなケースでは追加の工夫が必要です。
・新商品で過去データが存在しない ・欠測や商品コード変更が多い ・販売実績が在庫不足の影響を強く受けている ・販促や価格変更の予定が予測時点で確定していない ・予測単位と意思決定単位が一致していない
この場合、基盤モデルだけで解決しようとせず、在庫制約や販促計画、商品ライフサイクルに関する業務ルールと組み合わせる必要があります。AIは需要を推定できますが、供給可能量や経営上の優先順位まで自動的に決定するものではありません。
Umiosの事例から学べるのは、時系列基盤モデルを導入すること自体ではなく、モデルを既存業務の中で使える形に落とし込み、作業時間と判断品質の両方を測定する姿勢です。エンジニアにとっての課題は、モデル選定だけではありません。データの時点管理、再現可能な推論、現場向けの例外表示、監査可能なログ、そして導入効果の定量化までを一つのシステムとして設計することです。
販売計画AIの成功条件は、「最も精度の高い予測を出すこと」ではなく、「人がより少ない時間で、より妥当な計画を作れること」にあります。
出典： AWS公式ブログ