猛暑で発注が当たらない夏｜需要予測を入れる前に、社内の販売データが使える状態か確かめた食品卸の話

この記事の事例は、実際にいただくご相談をもとにした想定ケースです。特定の企業を指すものではありません。

7月の廃棄が58万円、同じ月に欠品が32件出ていました

大分県内で業務用食品を扱う卸売業のA社（従業員28名、取引先は飲食店と宿泊施設が中心）の話です。2026年7月、最高気温が35度を超える日が続き、冷やし麺と炭酸飲料の受注が読めない形で伸びました。反対に、前年実績をもとに積んでいた温かい惣菜は動かず、賞味期限切れの廃棄が58万円分出ました。同じ月に、在庫切れで受注を断った件数は32件ありました。

社長からのご相談は「AIで需要予測を入れたい」でした。発注担当は3名で、いずれもExcelの発注表と前年実績と経験で数量を決めています。ただ、予測の話に入る前に、渡せるデータがあるのかを先に見ることにしました。

「売れなかった」と「売る物がなかった」が、同じ0で残っていました

最初に分かったのは、販売実績として残っているのが出荷数だけだという点でした。在庫切れで断った32件は、営業担当の電話メモにしか残っていません。データの上では、その商品はその日「0本しか売れなかった」ことになります。

需要が伸びたときほど欠品は起きますから、伸びた事実だけがデータから抜け落ちます。この状態のまま予測モデルに学習させると、猛暑日の需要を実態より低く見積もる方向に寄っていきます。そこで受注明細に項目を足しました。

受注明細に追加した項目
  order_qty      : お客様から引き合いのあった数量です
  shipped_qty    : 実際に出荷した数量です
  shortage_reason: 在庫切れ／販売終了／取引先都合から選びます

商品コードの振り直しで、前年同週と比べられなくなっていました

次に、2024年のパッケージリニューアルで商品コードが振り直されていることが分かりました。中身が同じ商品でも旧コードと新コードに分かれ、集計すると別商品として並びます。名寄せの必要があるものは約90SKUありました。

-- 同じ商品名で商品コードが複数あるものを数えます
SELECT product_name, COUNT(DISTINCT product_code) AS code_count
FROM products
GROUP BY product_name
HAVING COUNT(DISTINCT product_code) > 1
ORDER BY code_count DESC;

前年同週と比べられない状態では、猛暑の影響を切り出すこともできません。過去データをどこまで揃え直すかは、新システムへのデータ移行費が見積もりで一番膨らむ理由で書いた線引きと同じ考え方で決めました。

あわせて読みたい新システムへのデータ移行費が見積もりで一番膨らむ理由｜過去データをどこまで持っていくかの判断基準

特売の実施日と、気温を並べる日付を決めました

3つ目は、特売や催事の記録です。実施日と対象商品は販促担当の個人Excelにあり、2年前の分は残っていませんでした。需要が跳ねた日について「暑かったから」なのか「特売をかけたから」なのかを、後から説明できません。

気温は気象庁の過去の気象データ検索から地点別・日別で取得できますので、外から持ってこられます。ただし並べる相手の日付を決める必要がありました。A社の伝票には受注日と納品日が混在しており、暑さに反応するのは受注日のほうです。ここを区別して持つように直しました。

確認した項目	7月時点の状態	予測に渡せる状態
欠品時の受注	電話メモにしか残っていない状態	引合数と欠品理由が伝票に残る状態
商品コード	リニューアル前後で分裂している状態	名寄せキーで前年とつながる状態
特売・催事	販促担当の個人Excelにある状態	実施日と対象商品を全社で参照できる状態
日付の持ち方	受注日と納品日が混在している状態	どちらの日付かを区別して持つ状態

3か月貯めてから、予測の話に戻ることにしました

A社が8月中に着手したのは、受注画面への欠品理由の追加、商品コードの名寄せテーブルの作成、販促カレンダーをシステム側に持たせることの3つです。いずれも既存の受発注システムへの追加で、大掛かりな入れ替えはしていません。

予測モデルの検討は、この形で3か月分が貯まる11月以降に回しました。先に効いたのは別の点で、欠品理由が残るようになったことで「断った受注」が週次で見えるようになり、発注担当が翌週の積み増しを判断できるようになっています。数字が出るタイミングの話は月次の数字が出るのは翌月20日過ぎにも書きました。在庫の数え方そのものに不安が残る場合は、9月末の棚卸しで在庫が合わないのほうが先に読む内容になります。

えらびの道は、卸売の受発注・請求や出張販売の管理など、業務システムをオーダーメイドで開発しています。データの可視化やレポートの自動化から、機械学習による予測、リアルタイムなデータ収集基盤までを扱います。今回のようなケースでは、受注画面への項目追加、商品マスタの名寄せ、気温などの外部データを日次で取り込む仕組みといった、予測の手前にある地味な部分から手を付けます。小さく作って動かしながら育てる進め方をとっていますので、予測モデルまで一度に決めきる必要はありません。

販売データを需要予測に渡せる状態にするまで、えらびの道でお手伝いできること

合同会社えらびの道は、中小企業向けのシステム受託開発と、データ活用・DXのご支援をしています。卸売の受発注や請求、介護のシフト管理、出張販売の管理、EC・決済、業務データを集めて予測に使う基盤づくりなどを手がけてきました。実際に予測へ渡すデータを扱う立場から、モデルより前に何を整える必要があるかをお伝えしています。

この記事で挙げた整え方についても、御社の販売データに合わせたかたちでお手伝いできます。引き合いと出荷を分けて欠品を記録に残す項目の追加、リニューアルで分かれた商品コードの名寄せ、特売や催事の実施日を全社で参照できるようにする作業、受注日と納品日を分けて持つ設計まで、受発注の実務に沿って進めます。

進め方としては、全部を一度に置き換えることはしません。止まると困る1業務から動かし、残りは様子を見ながら移していきます。打ち合わせから開発まで同じ人間が担当しますので、現場で伺った発注の事情がそのまま設計に入ります。

まずは、いまの販売データがどんな形で残っているかを伺うところからで構いません。えらびの道ではオンラインで30分ほどのご相談をお受けしており、費用はかかりません。

よくある質問

需要予測の仕組みを入れるには、どのくらいのデータ期間が必要ですか？

商材によりますが、季節変動を扱うなら最低でも2年分の日次データが目安になります。ただし期間より状態が先で、欠品や商品コードの分裂が残ったままの3年分より、整った1年分のほうが役に立ちます。まず今のデータが説明できる形かを確かめてください。

Excelの発注表しかなくても需要予測はできますか？

発注表には「いくつ頼んだか」しか残らないことが多く、実際に売れた数や断った数が分かりません。予測に使うには受注と出荷の実績が日次で必要ですので、まず受発注のデータをシステム側で残す形に変えることが出発点になります。

気温データは自社で用意する必要がありますか？

気象庁が地点別・日別の観測値を公開していますので、自社で計測する必要はありません。日次で取り込む仕組みを組めば、自社の受注データと並べて使えます。手間がかかるのは気温側ではなく、突き合わせる自社データの日付や商品コードを揃えるほうです。