この記事でわかること
- Umios（旧マルハニチロ）が、全国の支社で手作業だった月次の販売計画づくりを、時系列基盤モデル「Chronos-2」の予測で自動化した
- 生成AIチャットで予測を試したあと、予測専用のモデルに切り替えた。AIは「たたき台」までで、確定は人が行う
- 自動化の前に確かめたいのは、学習に使うデータが「本当の需要」か、商品コードで履歴が切れていないか、人の確認をどこに残すか
何が発表されたか
Umiosは2026年6月25日、AWS Summit Japan 2026の講演で、販売計画の自動化の取り組みを説明しました。講演資料によると、全国の支社の営業担当者が毎月、事業・商品・倉庫ごとに販売計画を予測して入力しており、全支社で年間約4,200時間を費やしていました。この4,200時間は業務用の事業だけの数字で、本番稼働後に削減できる見込みとして示されています。実績ではなく見込みです。
進め方は次のとおりです（講演資料のタイムライン）。
- 2025年上半期: 社内の生成AIで予測を検証
- 2025年12月: AWSから時系列基盤モデル「Chronos-2」の提案
- 2026年2月: 予測の検証を本格化
- 2026年4月: 事業部と運用を設計
- 2026年6月: 本番稼働
＠IT（2026年10月16日）も、この事例を詳しく報じています。
なぜ今これが問題になっているのか
販売計画は、生産計画と在庫の土台になる数字です。Umiosの資料は、課題を3つ挙げています。
- 営業が持つ「販売の増減の見込み」の入力が徹底されていない（システムに入れる支社、独自のExcelで管理する支社、運用が止まっている支社に分かれていた）
- 計画の精度が担当者の経験に頼っている
- 計画から生産への反映に時間がかかるため、「3カ月先」を当てなければならない
生成AIを社内に入れた会社では、「需要予測もチャットに聞けばいいのでは」という声が出やすいはずです。Umiosも最初はそこから始めました。結果は不採用です。＠ITの報道では、社内の生成AIチャット（Claude Sonnet 4ベース）で予測を試しましたが、再現性とシステムへの組み込みに課題があったといいます。
仕組み
- 入力: 過去の販売実績と、営業が入れる販売の増減の見込み。増減の見込みは、内製した簡易入力アプリの全国共通フォームで集め、毎月20日に締めて連携する
- 予測: Chronos-2を毎日1回のバッチで動かす。既存の実績DBとBIツールには手を加えず、その外側に予測を足した構成（AWS Step Functions、AWS Lambda、Amazon SageMaker AI、Amazon Redshift など）
- 出力: 下振れ・中央・安全側の3つの値（P10／P50／P90）。BIで予測・計画・実績を並べ、予測と計画の乖離にはアラートを出す。毎月20日に予測値を計画システムへ反映する
- 確定: 支社の担当者が10日間で確認・修正し、営業が最終的に確定する
Chronos-2は、Amazonが公開している時系列予測用の基盤モデルです。公式のモデルカードでは、約1億2,000万パラメータで、事前学習済みのまま（追加の学習なしで）予測でき、結果を幅のある値（分位点）で返すと説明されています。Umiosの資料は、学習モデルを自前で作らずに済むので、学習と運用のコストを抑えられる点を選んだ理由に挙げています。AIを「作る」より「使う」を選んだ形です。
95％という数字は、読み方に注意が要ります。資料の「予測一致率95％」は、定番品の年累計の合計で見た値で、品目ごとの精度ではありません。季節によって売れ方が変わる商品では誤差が大きく、データの期間を1年から延ばし、「月」の情報を加えて改善したといいます。採用の基準は事前に事業部と決めていて、受け入れられる線を一致率6〜7割、自動化に使う線を80％以上としていました。
データの扱いでも2つの学びが書かれています。在庫を減らすための処分販売は「売れた量」であって需要ではないので、予測に使うデータから外しました。もう1つは失敗例で、規格が変わるたびにJANコードが変わり、ある冷凍食品では2010年から2025年までに5世代に分かれて販売履歴が途切れていました。マスターデータの整備は今後の課題とされています。まだ解決していません。
導入前に確かめること
- 予測したいのは「売れた量」か「需要」か。値引き処分、欠品、特売で数字がゆがんだ期間を見分けられるか
- 商品コードの付け替え（規格変更、リニューアル）で、同じ商品の履歴が途切れていないか。新旧コードの対応表はあるか
- 営業の見込みなど、人が持っている情報を同じ形式で集める仕組みはあるか。支社や部署ごとにExcelがばらばらになっていないか
- 生成AIチャットで予測を試すなら、同じ入力で同じ答えが返るかを先に確かめたか
- 「何％なら使う」を、事業部と事前に決めたか。全体の合計で見るか、品目ごとに見るか
- AIの予測をどこまで任せ、人はどこで確認・修正するか。確認の期間と、最終的に確定する人は決まっているか
- 既存のDBや計画システムを作り直さずに、外側に足す形にできるか
- 季節品・新商品・スポット品など、予測が外れやすい商品を最初の対象から外すか
向いている現場／向いていない現場
| 向いている | 向いていない |
|---|---|
| 定番品が多く、数年分の販売実績がそろっている | 新商品やスポット品が中心で、履歴が短い |
| 人手の計画づくりに毎月まとまった時間がかかっている | 計画を立てる人が少なく、手間が問題になっていない |
| 人が確認して確定する流れを残せる | 予測値をそのまま発注や生産に使いたい |
まとめ
Umiosの事例は、数値の予測には予測専用のモデルを選び、生成AIチャットを無理に使わなかった例です。資料の結びは「勝負どころは、予測モデルじゃなく、データと運用」で、実際に手間がかかったのも入力の統一や処分販売の除外、商品コードの問題でした。95％は定番品の年累計という条件つきの数字で、季節品や新商品を含めた精度は公開されていません。自社で検討するときは、上のチェックリストのうち、データの項目から先に確かめると進めやすくなります。
この記事では、Chronos-2を自分で動かして試してはいません。内容はUmiosの講演資料、Amazonのモデルカード、＠ITの記事に基づきます。
コメント