飲食チェーンの本部が、店舗ごとの過去の売上と天気・祝日・行事から Python で翌週の日別売上を幅つきで予測し、店舗の人時の上限とセントラルキッチンの製造量の計画に使う

処理の起点を決める

起点は3つです。 毎日の書き出し、毎日の天気予報の取得、毎週木曜の予測です。

1つ目は、POSレジの毎日の書き出しです。 閉店後の売上の締めの後に、店舗・日ごとの売上・客数・営業時間を CSV で書き出し、本部の置き場所に入れます。書き出しの仕組みが POS にあるかは、POS の会社に確かめます。 無ければ本部の集計の画面から週に1回書き出します。

2つ目は、毎日の天気予報の取得です。 防災情報XMLの長期のフィードを毎朝見に行き、府県週間天気予報の電文を、店のある地域の分だけ取り出して保存します。公式のページでは、1つのURLで1日に10GB以上のダウンロードがあると、その送り元はアクセスを止められるとされています。 すでに持っている電文を取り直さないよう、取った電文の識別子を記録しておきます。

3つ目は、毎週木曜の朝の予測です。 5時に動かし、店長が出勤する時刻には予測と印が表に並んでいるようにします。日曜の朝にもう一度動かし、天気予報が新しくなった分で製造量だけを見直します。 人時の上限はシフトが組まれた後なので、日曜には変えません。

入力データを集める

質を決めるのは、天気予報を「発表の日時ごと」に残すことです。 学ばせるときに、その日に実際に降った雨を使うと、モデルは「雨と分かっている日」の動きを覚えます。予測するときに手元にあるのは予報だけです。 学ばせる側も、木曜の時点で出ていた予報で学ばせないと、本番で外れ方が大きくなります。

そのため、天気の列は貯め始めてから効きます。 予報を貯め始めて1年ほどは、天気の列を入れたモデルと入れないモデルの両方で確かめる期間の外れ方を比べ、入れたほうが当たるようになってから天気の列を使います。

祝日は、内閣府のCSVから取ります。 公式のページには、昭和30年から令和9年までの国民の祝日のCSVが載っており、令和10年の祝日は前年の2月に載せるとされています。毎年2月に取り直す手順を入れておきます。手元で読んだ限り、CSVは Shift_JIS 系の文字コードでした。

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

天気予報は、木曜の朝の時点で最新の発表を使います。 学ばせるときも同じで、過去の各週について、その週の木曜の朝に出ていた発表を選びます。 発表の日時ごとに保存しておく理由はここにあります。

週間天気予報の範囲の外の日は、天気の列を空のまま渡します。 木曜に翌週の日曜までを見込むと、後ろの数日は予報の範囲の外になることがあります。LightGBM の公式のページでは、欠けた値の扱いが既定で有効とされています。平年の値で埋めずに空のまま渡し、その日に「天気予報の範囲外」の印を付けます。

AIへ渡す前に整形する

1. 休業日と短縮営業を分ける … 休業日は学ばせる記録から外し、営業時間の短い日は「営業時間」の列で持たせます
2. 改装の期間を外す … 改装の前後の数週は売上が普段と違うので、店舗の台帳の期間で外します
3. 新店を扱う … 開店から1年に満たない店は、店舗の番号の列を空にし、立地の型と席数で学ばせた動きを使います
4. 曜日と連休の列を作る … 曜日、祝日、連休の何日目か、連休の最終日か、年末年始・お盆の印
5. 直近の動きの列を作る … 予測を出す週の水曜までの売上だけから、同じ曜日の直近4週の平均と前年の同じ週の売上を作ります
6. 販促と行事の列を作る … 予定表を店舗と日付で引き、種類ごとの印にします
7. 目的の値を決める … 税抜の売上を目的の値にし、客数は列に入れません（予測する日には分からないため）

3番目は、LightGBM の決まりを使います。 公式のページでは、予測のときに学ばせたときに無かった区分の値は、欠けた値として扱われるとされています。新店の番号はモデルにとって知らない区分なので、立地の型と席数から近い店の動きで見込まれます。 新店には必ず印を付け、店長に確かめてもらいます。

5番目で「水曜まで」に限るのは、木曜の朝に手元にあるのが水曜までの売上だからです。 翌週の月曜は5日後、日曜は11日後になります。学ばせるときに前日の売上を列に入れると、本番では使えない列で学ばせたことになります。 過去の各週についても、その週の水曜までで列を作ります。

AIに処理させる

させるのは、店舗・日ごとの税抜の売上を、少なめ・真ん中・多めの3本で予測することだけです。

人時の上限を真ん中で組むのは、人を多く入れすぎた日の人件費と、足りなかった日の客の待ちの両方を見たうえでの選び方です。 どちらを重く見るかは会社が決めることで、多めの側で組む会社もあります。

製造量は、品目の持ちで使い分けます。 当日中に使い切る品目は真ん中で、冷凍で持つ品目は多めで作ります。どの品目をどちらにするかは、製造の担当が品目の一覧に書きます。

4行目を混ぜないでください。 予測を目標として店に渡すと、店長は予測に届くように販促を足し、次の週の記録が「予測に合わせた動き」で汚れます。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、モデルの設定と換算・印付けの規則を書いておきます。

【モデル】
- LightGBM、objective="quantile"、alpha を 0.2／0.5／0.8 で3つ学ばせる
- 区分の列 = 店舗の番号、立地の型、曜日、祝日の種類、販促の種類、行事の種類
  （0以上の整数に置き換えて渡す。新店の店舗の番号は空にする）
- 目的の値 = その日の税抜の売上（休業日は学ばせる記録から外す）
- 天気の列は、木曜の朝の時点で最新の予報。予報の範囲の外は空のまま渡す
- 直近の動きの列は、予測を出す週の水曜までの売上だけから作る

【確かめ方】
- TimeSeriesSplit で、週を単位に過去から順に確かめる
- 学ばせる期間の末尾と確かめる期間のあいだに gap を置く（木曜から月曜までの分）
- 比べる相手 = 前年の同じ週の同じ曜日、直近4週の同じ曜日の平均
- 店ごとの外れ方（実績の合計に対する外れの合計の割合）が、
  比べる相手より小さい店だけ、予測を使う。大きい店は店長の見込みのまま

【換算】
- 人時の上限 = 真ん中 ÷ 店ごとの目標の人時売上高（30分単位に切り捨て）
- 製造量 = 全店の売上（真ん中か多め）× 品目ごとの構成比 ÷ 品目の単価の目安
  （日持ちの短い品目は真ん中、冷凍で持つ品目は多め）

【印を付ける条件】
- new：開店から1年に満たない
- event：行事の予定表に記入がある
- wide：多め − 少なめ が、真ん中の5割を超える
- jump：前年の同じ週の同じ曜日から3割以上違う
- no_weather：天気予報の範囲の外
- 印の無い日は、店長の確認なしで表に載せる

比べる相手より当たらない店は、予測を使いません。 40店のうち何店かは、近くの競合の開店や駅の工事で、過去の記録が今の動きを表していないことがあります。その店は店長の見込みのままにし、なぜ当たらないかを本部が店長と話します。

gap を置くのは、本番と同じ条件で確かめるためです。 scikit-learn の公式のページでは、TimeSeriesSplit は時間の順に並んだ記録を分け、ほかの分け方では未来の記録で学ばせて過去で確かめることになるとされ、gap は各学ばせる期間の末尾から除く件数とされています。木曜に予測して翌週の月曜から当たるなら、学ばせる記録の最後と確かめる最初の日のあいだに、その日数を空けます。

区分の列を0以上の整数にするのは、LightGBM の決まりです。 公式のページでは、区分の値は0以上の整数で渡す必要があり、負の値は欠けた値として扱われるとされています。店舗の番号のように区分の数が多い列は、数値として扱うほうがよいことが多いとされ、min_data_per_group や cat_smooth で学びすぎを抑えるよう案内されています。 40店なら区分として渡し、確かめる期間で両方を比べて決めます。

出力形式を固定する

店舗ごと・日ごとに1行の表で出します。 店長には自分の店の7行を、本部には全店の280行を渡します。

store_id, date, weekday, p20, p50, p80, labor_hours_cap, flags, model_version
S012, 2026-10-19, 月, 412000, 468000, 531000, 117.0, "", 2026-10-15
S012, 2026-10-24, 土, 655000, 742000, 868000, 185.5, "event;no_weather", 2026-10-15
S031, 2026-10-24, 土, 380000, 455000, 590000, 113.5, "new;wide;no_weather", 2026-10-15

あわせて、セントラルキッチンには品目ごとの製造量の表を渡します。

item_id, item_name, shelf_type, basis, qty_mon, qty_tue, ... qty_sun
K-104, だし（1L）, 当日, p50, 520, 498, ... 760
K-221, 冷凍の唐揚げ（1kg）, 冷凍, p80, 64, 61, ... 95

1つ目の理由は、3本を並べて渡せることです。 店長は真ん中だけでなく幅を見て、幅の広い日にはシフトの「声をかけておく人」を厚めにします。

2つ目は、flags で確かめる日を絞れることです。 印の無い日は確認なしで使い、店長が開くのは印の付いた日だけになります。

3つ目は、model_version で後から照らせることです。 モデルを学ばせ直した週と、外れ方が変わった週を突き合わせられます。

店長が直すときは、p50 の横に manager_p50 と reason の列を足して書きます。 予測の列は書き換えません。予測と直しを別の列に残すと、翌週にどちらが当たったかを比べられます。

システムへ連携する

シフトの仕組みにも製造計画の表にも、直接は書き込みません。 予測が大きく外れた週に、そのまま人時の上限や製造量が確定すると、誰も止める場所がありません。 本部の確定を挟みます。

店長への予測の表は、店舗ごとに見られる範囲を分けます。 他の店の売上が見えると、店どうしの比べ合いになり、直しの理由に他店の数字が入ってきます。

人が確認する

店長が見るのは、印の付いた日だけです。

1. new と event を先に見る … 新店と行事の日は、モデルの知らないことが多い日です。行事の規模や人の流れを知っているのは店長です
2. wide と no_weather を見る … 幅が広い日と天気予報の外の日は、シフトの「声をかけておく人」を厚めにするかを決めます
3. jump を見る … 前年から大きく違う日です。前年に特別な事情（改装・催し）が無かったかを思い出します
4. 直すなら理由を書く … manager_p50 と reason に書きます。理由は「近くの店が閉店」「店の前の道路工事」のように事情で書きます

本部の担当者は、店長の直しの大きさを見ます。 真ん中から3割以上動かした直しは、理由を読んで、本部が知っている事情（販促の変更、近くの競合の動き）と合うかを確かめてから確定します。

翌週が終わったら、予測と直しと実績を並べます。 店長の直しが当たった事情は、行事の予定表の種類に足して、次に学ばせるときの列にします。 予測のほうが当たった事情は、店長に伝えて、直さなくてよい日を増やします。

例外に対処する

最後の行は、分位点を別々のモデルで出すときの性質です。 3つのモデルはそれぞれ独立に学ぶので、記録の少ない日には少なめの見込みが真ん中を上回ることがあります。並べ直せば表としては使えますが、その日はモデルが自信を持てていない日です。 wide と同じく、店長に回します。

6行目は、モデルに任せないでください。 大きな天気の崩れは記録に少なく、モデルは過去の数回からしか学べません。 公共交通の計画運休や自治体の呼びかけのような事情は、列にありません。

記録を残す

• 毎日の POS の書き出しの原本と、取り込んだ日時
• 天気予報の電文の原本と、発表の日時・取った日時
• 学ばせたときの記録の期間、列の一覧、設定、model_version
• 毎週の予測（3本と印）と、そのとき使った天気予報の発表の日時
• 店長の直しと理由、本部の確定の値
• 実績と、予測・直し・確定のそれぞれの外れ方
• 店ごとの、比べる相手と予測の外れ方の比べ

2つ目と4つ目で「発表の日時」を残すのが、この構成の土台です。 天気予報は発表のたびに変わるので、どの発表で予測したかが分からないと、外れた理由を天気のせいにできるかが分かりません。