スーパーの毎週のチラシに載せる特売品の販売数を、過去の特売の実績・売価・曜日・天気から店舗ごとに見込み、発注量の案を出す

処理の起点を決める

毎週火曜の朝に、社内のサーバーで1回動かします。 チラシの掲載は2週間前に決まり、発注は特売の前週の金曜に締めます。火曜の朝に一覧が出れば、バイヤーは水曜と木曜で直し、金曜の締めに間に合います。

天気予報は、動かす時点で手に入るものを使います。 特売の木曜から日曜は、火曜から見て2〜5日先です。予報は先の日ほど外れやすいので、日曜の気温の見込みが外れることを前提に、天気で大きく動く品目には印を付けます（前処理の6番）。金曜の締めの直前にもう一度だけ動かし、天気で動く品目の見込みだけを差し替える運用もできます。

学び直しは月に1回です。 毎週の特売の結果（実績と売り切れの有無）がたまるのを待ち、月初に過去2年分で学び直します。学び直したモデルは、直近8週の特売で前のモデルと成績を比べ、良くなったときだけ入れ替えます。

入力データを集める

質を決めるのは、掲載の記録と時間帯別の販売数です。 掲載の記録が無ければ、どの日が特売だったかを売上の跳ね上がりから推測することになり、値引き無しで売れた日と特売の日が混ざります。 時間帯別の販売数が無ければ、売り切れを見分けられません（前処理の3番）。

品目の区分は、最初はカテゴリ単位で付けます。 「飲料は日持ちする」「刺身は日持ちしない」をカテゴリで決め、例外の品目だけをバイヤーが直します。

データの取得方法を決める

掲載の記録は、表計算のファイルからそのまま読みます。 列の名前と書き方（売価は税込みか税抜きか、期間は開始日と終了日）を決め、バイヤー全員が同じ書き方で入れるように、入力の欄を固定します。 書き方がばらばらの過去分は、最初に一度だけそろえます。

POSの売上は、POSの書き出しの機能で、品目・店舗・日別と、品目・店舗・時間帯別の2種類を書き出します。 書き出しの形はPOSの製品ごとに違うので、この部分は利用中のシステムに応じた個別の対応が要ります。

過去の天気は、気象庁の「過去の気象データ・ダウンロード」でCSVを取ります。 地点・項目・期間を選び、データを画面に表示せずにCSVファイルとしてダウンロードできます。地点は全国の気象台やアメダス、約1,500地点（観測を終えた約200地点を含む）から選べ、店舗ごとに最寄りの地点を決めます。 日別値で、日最高気温と日降水量を取ります。

CSVを読むときは、品質情報の列を必ず見ます。 表示オプションで「CSVファイルのデータ仕様はすべて数値で格納」を選ぶと、品質情報が値と別の列に入ります。品質情報が8（正常値）と5（準正常値）以外の値は使わず、欠損（NaN）として扱います。 4は資料不足値、2は疑問値、1は欠測です。

均質番号にも気をつけます。 番号の違いは観測環境の変化を表し、番号の違う値同士は単純に比べられないとされています。また、均質番号はCSVを取るたびに古いものから振り直されるので、期間の違う複数のCSVをつなぐときは、番号をそのまま比べないでください。

AIへ渡す前に整形する

1. 特売の回の切り出し … 掲載の記録の期間で、品目×店舗の特売期間の販売数を合計します
2. ふだんの売れ方の算出 … 特売の直前4週の、同じ曜日の平均販売数を出します。特売でどれだけ伸びたかを見るための基準です
3. 売り切れの推定 … 時間帯別の販売数で、閉店の3時間以上前から販売数が0の日を売り切れの疑いとします。疑いのある回は、販売数を「少なくともこれだけ売れた」値として印を付けます
4. 値引き率の計算 … （通常の売価 － 特売の売価）÷ 通常の売価。点数の制限があれば別の特徴量にします
5. 天気の付け合わせ … 店舗ごとに最寄りの観測地点の日最高気温と日降水量を付けます
6. 天気で動く品目の印 … 過去の特売で、気温や雨の有無で販売数が大きく違った品目に印を付けます
7. 初めての品目の扱い … 過去の特売の実績が無い品目は、バイヤーが「似た品目」を1つ指定し、その品目の過去の回を参考に使います

3番目が、この構成でいちばん大事な前処理です。 売り切れた回をそのまま学ぶと、欠品した店舗ほど見込みが低くなります。 印を付けた回は、学習から外すか、上側のモデルにだけ使います。最初は学習から外すほうが分かりやすく、件数がたまってから扱い方を決め直します。

3番目の「閉店の3時間以上前」は、最初の目安です。 夕方に売れる品目と朝に売れる品目で違うので、カテゴリごとに見直します。売り切れの疑いは、たとえば次のように見えます。

合計だけを見ると、B店はA店より売れていないように見えます。 実際には、午前の売れ方はB店のほうが速く、15時に売り切れています。B店の140は「少なくとも140」で、需要はA店より大きかった可能性が高いので、この日のB店の値は学習から外します。

AIに処理させる

モデル（scikit-learn）にさせるのは、品目×店舗ごとに特売期間の販売数を、中央と上側の2つの値で見込むことです。

店舗とカテゴリを Categorical 型で渡すのは、categorical_features の既定値が "from_dtype" で、この型の列をカテゴリとして扱うからです。 店舗番号を数字のまま渡すと、番号の大小に意味があるものとして学びます。

発注量の案は、モデルの見込みから規則で作ります。 モデルに発注量を直接見込ませないのは、在庫やケースの入数はその週の事情で、過去の販売数からは学べないからです。

上側を0.8にしているのは、最初の目安です。 どの分位点を使うかは、1個足りなかったときの損（売り逃した粗利と、チラシを見て来た客の失望）と、1個余ったときの損（値下げと廃棄）の釣り合いで決まります。足りない損が余る損の4倍なら、見込みの8割の点で発注するのが釣り合う、という考え方です。この比率はカテゴリごとに違うので、バイヤーと一緒に決め、0.8で始めて欠品と売れ残りを見ながら動かします。 分位点ごとにモデルを学習するので、0.7や0.9を足すのは簡単です。

指示内容を固定する

この構成では生成AIを使わないので、プロンプトはありません。 代わりに、学習と見込みのプログラムの要点を示します。

from sklearn.ensemble import HistGradientBoostingRegressor
from sklearn.metrics import mean_pinball_loss

FEATURES = ["discount_rate", "sale_price", "base_sales", "flyer_face",
            "days_weekend", "max_temp", "precip", "store", "category",
            "qty_limit", "weeks_since_last"]
MONO = {"discount_rate": 1, "sale_price": -1, "base_sales": 1}

# 売り切れの疑いのある回は学習から外す（前処理の3番）
train = rows[(rows.week < cutoff) & (~rows.stockout_suspected)]
test  = rows[rows.week >= cutoff]

models = {}
for q in (0.5, 0.8):
    m = HistGradientBoostingRegressor(loss="quantile", quantile=q,
                                      monotonic_cst=MONO, max_iter=400)
    m.fit(train[FEATURES], train.sales)
    models[q] = m
    pred = m.predict(test[FEATURES])
    print(q, mean_pinball_loss(test.sales, pred, alpha=q))

成績はピンボール損失で測ります。 scikit-learn の mean_pinball_loss は分位点回帰のための損失で、alpha を0.5にすると平均絶対誤差と同じになります。上側（0.8）のモデルは alpha=0.8 で測り、さらに「実績が上側の見込み以下に収まった割合」が8割前後になっているかを見ます。 8割を大きく下回れば、上側の見込みが低すぎて欠品が出ています。

比べる相手は、バイヤーが実際に入れた発注量です。 過去8週の特売で、バイヤーの発注量とモデルの案のどちらが、欠品と売れ残りが少なかったかを品目のカテゴリごとに数えます。

出力形式を固定する

バイヤーごとに、次の形の一覧（CSV）を出します。 1行が品目×店舗です。

根拠の回を1つ添えるのは、バイヤーが数字を確かめる手がかりにするためです。 条件の近い過去の回は、値引き率と掲載面が同じで、時期が最も近い回を規則で選びます。モデルの中身を説明するものではありませんが、バイヤーが「前回こうだった」と照らせます。

一覧のほかに、品目ごとの店舗のまとめを1枚付けます。 20店舗の案を横に並べ、中央と上側の見込みの差（幅）が大きい店舗に色を付けます。幅が大きいのは、その店舗の過去の特売の売れ方がばらついている印です。 バイヤーが店長に事情を聞くべき店舗が、ここで分かります。

「直した理由」を選択式にしているのは、後で数えるためです。 自由記述にすると集計できません。「その他」が多ければ、選択肢に足すべき理由があります。

システムへ連携する

天気予報の取り方は、自社の環境で決めます。 契約している気象情報サービスがあればそこから取り、無ければ発注の担当が予報を見て、特売期間の各日の最高気温と降水の有無を入力の欄に入れます。どちらの場合も、入れた予報と入れた時刻を残します。 予報の取り方を途中で変えると、見込みの外れ方が変わるからです。

発注システムには書き込みません。 一覧からバイヤーが入れます。発注システムが一括の取り込みに対応していても、最初の半年は手で入れます。 手で入れる段階で、バイヤーがどの品目を直すかの傾向が見えます。

人が確認する

バイヤーが見るのは、印の付いた品目と、案が前回の発注量から大きく離れた品目です。

1. 印の付いた品目を先に見る … 「天気で動く」「初めての品目」「売り切れの疑いが続いている店舗」
2. 前回の発注量から3割以上離れた案を見る … 根拠の回を見て、理由が分かるかを確かめます
3. 店舗の事情で直す … 改装、競合店の開店、地域の行事。直したら理由を選びます
4. 残りは案のまま入れる … 一覧で流し見て、発注システムに入れます

2番目を省かないでください。 案が大きく離れるのは、モデルが正しく変化を拾った場合と、掲載の記録の入れ間違い（売価の桁、税込みと税抜き）の場合があります。後者はモデルでは見分けられません。

目標は、320品目をならして1品目6分です。 印の付いた品目は根拠を読んで十数分、残りは数分です。

店長が発注量を直せる運用の会社では、店長の修正も同じ一覧に残します。 バイヤーの修正と店長の修正を分けて記録すると、店舗の事情（近くの催し、改装）を誰が知っているかが分かります。

例外に対処する

1行目と5行目は、推測で埋めないでください。 実績の無い品目や店舗に全体の平均を当てると、それらしい数字が出るだけに、バイヤーが疑わずに入れてしまいます。

記録を残す

• 毎週の見込み（品目×店舗、中央・上側）と、使ったモデルの版
• 使った特徴量の値（特に、その時点の天気予報）
• 発注量の案と、バイヤーが入れた発注量・直した理由
• 特売の後の実績と、売り切れの疑いの有無
• 店舗への問い合わせで分かった売り切れの時刻

2つ目の天気予報は、実際の天気とは別に残します。 見込みを外した理由が予報の外れなのか、モデルなのかを分けるためです。学び直しには、予報ではなく実際の天気を使います。

3つ目は、モデルの改善の材料です。 同じ理由で同じ方向に直す品目が続けば、その理由を特徴量に足す候補になります。残す期間は2年以上にします。 学び直しに過去2年分を使うので、それより短いと同じ時期の特売を比べられません。