「年4200時間の入力」「経験と勘」からの脱却 旧マルハニチロは「販売計画」をどう自動化した？：「3カ月先を当てなければならない」

Umios（旧マルハニチロ）が全国の支社が手作業で入力していた月次の販売計画業務を自動化した。業務用流通事業部の全支社で年間約4200時間の作業削減を見込む。自動化の鍵は何だったのか。

[＠IT]

　Umiosは創業146年の食品メーカーで、2026年3月にマルハニチロから社名を変更した。冷凍食品を中心に、業務用流通事業と市販用冷食事業を展開している。

　同社では、全国支社の営業担当者が毎月、事業や商品、倉庫ごとに翌月以降の販売計画を手作業で入力しており、「業務用流通事業部の全支社で年間約4200時間を要する」と試算されていた。販売計画管理システム「PPPlan」上の管理データは約470万セルに上り、人手による管理は限界を迎えていたという。

　業務フローをAIによる自動化の観点で整理したところ、3つの構造的な課題が浮かび上がった。

　1つ目は販売増減情報の入力が徹底されていないことだ。システムに入力する支社、独自のExcelファイルで管理する支社、運用が停止している支社の3パターンに分かれていた。2つ目は入力精度が担当者の経験に依存していたことだ。計画値が担当者の「経験と勘」に基づいて入力され、属人化していた。3つ目は「3カ月先を当てなければならない」構造になっていることだ。計画策定から生産計画への反映までのリードタイムによって予測対象が2〜3カ月先となっており、精度の確保が構造的に困難だった。

現運用の課題洗い出し（提供：Amazon Web Services）

「経験と勘」の販売計画をどう自動化したのか

　こうした状況を改善するために、Umiosは業務用流通事業部とDX推進部、Umiosテック、Amazon Web Services（AWS）の4者協業体制でプロジェクトを進めた。3つの課題をどのように解消したのか。

　当初、Umiosは社内で全社展開している生成AIチャット基盤「UmiChat」（「Claude Sonnet 4」ベース）を用いて需要予測のPoC（概念実証）を始めていたが、大規模言語モデル（LLM）によるワンショット予測には再現性やシステムへの組み込みの面で課題があった。

　そこでAWSが提案したのが、Amazon Scienceが開発した時系列基盤モデル「Chronos-2」だ。膨大な時系列データで事前学習済みなので個別のモデル構築が不要。推論はAPI呼び出しのみで完結する。機械学習モデルの導入を支援する「Amazon SageMaker JumpStart」から数クリックで実行環境を準備できる。UmiChatと同じデータで比較したところChronos-2が上回る予測精度を示したので、Umiosは本格的なPoCの実施を決めた。

　3つの課題には、AI導入と並走する形で打ち手を講じた。

　入力の非徹底に対しては簡易入力アプリを内製し、得意先ごとの販売増減情報を全国共通フォームで入力できる受け皿を整備。毎月20日に締め切って連携する運用ルールを設け、データの欠損とばらつきを排除した。

　経験依存に対しては、予測業務をChronos-2に置き換えた。設計上のポイントは、現行運用を変えないまま属人性を排除した点にある。支社の計画策定担当者が最終確定するフローは維持し、AIは「ロジカルなたたき台」を提供する位置付けとした。Chronos-2は、P10、P50、P90の確率（パーセンタイル）予測を返すことで、それぞれ下振れ値、中央値、安全圏値の3点を提示し、担当者が10日間の確認期間で点検、修正して最終確定する。

　計画精度の構造的な困難に対しては、予測値を日次で更新する仕組みを構築した。締め切り直前の最新実績まで取り込むことで、2〜3カ月先の予測でも精度を底上げできる。既存のBIツール上で予測値、計画値、実績値を並べて可視化し、予測値と計画値の乖離（かいり）アラート機能も付与した。

　AWS構成は、既存の実績データベースとBIツールには手を加えず、その外側にAI予測を追加するシンプルな形を採った。

　推論基盤はAmazon SageMaker JumpStart上のChronos-2エンドポイント、バッチ処理の制御は「AWS Step Functions」、日次の定期実行は「Amazon EventBridge」、実績データと予測結果の保管は「Amazon S3」（Amazon Simple Storage Service）が担う。既存資産を生かしたサーバレス構成によって運用負荷を最小化している。

AWS構成図（提供：Amazon Web Services）

定番商品の予測精度は95％、Month列の追加でWMAPEが62.57％から20％へ

　Chronos-2を採用するかどうかの判断基準には予測精度を用いた。初めから「完璧」を求めず、事業部が許容できるラインの60〜70％（商品別、倉庫別、販売課別の月次粒度）を超えていれば採用し、その後に特徴量エンジニアリングで80〜90％を目指す計画とした。結果として、PoCで対象とした定番商品の年累計総計ベースで95％の予測精度が得られたという。

　PoCの初期には、一部の季節性商品で予測精度が想定を下回る課題も生じた。毎年2〜4月にピークが来る商品についてChronos-2が周期的なパターンを捉え切れず、WMAPE（加重平均絶対パーセント誤差）は62.57％だった。周期性を明示的に示す「Month」列を特徴量として追加したところ、WMAPEは20％になり、大幅に改善した。データ範囲を1年から3年に拡張したことも、季節品の精度改善に効いた。

特徴量に「Month」列を加えた場合の予測結果（提供：Amazon Web Services）

　データの扱いに関する知見も得られた。販売実績データは「売れた量」であって「本当の需要」ではない。在庫を消化するために、通常100円の商品を20円で販売する処分販売はスパイクとして現れるが、これは在庫余剰の結果だ。学習データに含めたままだと将来もその異常値が繰り返されると誤認するので、処分販売データは学習対象から除外した。

　食品業界特有の課題として、規格変更のたびにJANコードが世代交代し、販売履歴が分断される問題もある。ある冷凍食品では2010年、2012年、2015年、2021年、2025年と5世代もコードが変わっていた。現場では手作業で新旧コードをひも付けて対処したが、抜本的にはマスターデータの整備が必要だとしている。

　営業担当者の月次計画入力作業は大幅に自動化され、全商品に展開すると年間4200時間の作業削減が見込まれる。予測値と計画の乖離をリアルタイムで可視化できるようになり、事業部の生産計画と在庫調整にも効果が広がる設計だという。

　Umiosは次のステップとして、AIに「説明」と「行動」まで任せることを目指す。

　「Chronos-2は予測の結果しか返さない」という現場の声に対しては、「Amazon Bedrock AgentCore」を用いたエージェントの構築を予定している。予測の実行と結果の自然言語による考察をチャット形式で実現し、既存のUmiChatに組み込めることを実証中だ。乖離がしきい値を超えた場合のアラートと推奨アクションの自動提示、定番品からスポット品や新商品への予測対象の拡大も計画している。本事例はAWSが2026年9月10日、Umiosと共同で執筆したブログで公開した。