予約の入り方と曜日と天気予報から翌日の来店客数を見込み、生鮮食材の発注量の案を店舗ごとに出す

処理の起点を決める

毎日15時に、Python のプログラムを定時で動かします。 サーバーの定時実行の仕組み（タスクスケジューラや cron）で起動します。

15時にするのは、仕入先の締めから逆算した時刻です。 発注の締めが17時なので、店長が案を見て直す時間を1時間以上取れる時刻にします。予約は15時以降にも入りますが、15時の時点の数で予測し、それ以降の分は「当日までに上乗せされる予約」として学習の側に含めます。 実行時刻を日によって変えると、この上乗せの量が変わり、予測がずれます。

実行の時刻は、学習にも使います。 過去のデータを作るときも、毎日15時の時点で見えていた予約の数を取り出して学習させます。ここが第1章で述べた、この構成のもう一つの中心です。

翌日の閉店後にも、1日1回、実績を取り込む処理を動かします。実際の客数と出数を取り込み、予測との差を記録します。

入力データを集める

予約の状況は、毎日15時に保存しておく必要があります。 予約台帳は、後から開くと最終的な予約の状態しか見えないことが多く、「前日15時に何人入っていたか」は、その時点で保存しておかないと残りません。 過去の分が残っていない場合は、予約台帳の「予約を受けた日時」の記録から、各日15時の時点の数を組み立て直します。

天気予報も、その日に取得した予報を保存します。 学習に実際の天気を使うと、予測の時点では分からない情報で学ぶことになります。発注の時点で店長が見ていたのと同じ「予報」で学習させます。 天気予報をどの提供元から取るかは、利用する気象情報のサービスに応じた個別の実装になります。

在庫は、いま行っている閉店時の棚卸しを使います。 主な生鮮食材の在庫を、品目と数量の表に入れる形にそろえるのが準備作業です。

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

POSの書き出しは、文字コードと日付の列に気をつけます。 read_csv の encoding で文字コードを、parse_dates で日付の列を、dtype で店舗コードを文字列として読むよう指定します。店舗コードを数値として読むと、先頭の0が落ちて別の店舗になります。

取り込んだデータは、毎日の写しを残します。 予約台帳もPOSも、後から修正が入ることがあります。予測に使ったその日のデータを残しておかないと、予測が外れた理由を後から確かめられません。

AIへ渡す前に整形する

1. 日付をそろえる … 深夜0時をまたぐ営業の売上は、営業日にそろえます。 POSの日付が暦日のままだと、土曜の深夜の客が日曜に入ります
2. 臨時休業と貸切を印にする … 臨時休業の日と、貸切で通常の営業をしなかった日は、学習から外すか印を付けます
3. 予約の特徴を作る … 15時時点の予約の人数、組数、コースの予約数、過去4週の同じ曜日の「15時時点の予約」に対する「最終的な客数」の比を作ります
4. 暦の特徴を作る … 曜日、祝日、連休の何日目か、給料日の前後を列にします
5. メニューの出数の割合を出す … 店舗ごとに、過去4週の同じ曜日について、客1人あたりの各メニューの出数を出します
6. メニューの入れ替えに備える … 新しいメニューは、出数の割合が過去に無いため、似たメニューの割合を仮に置き、2週間たったら実績に切り替えます
7. 欠けた値はそのままにする … 天気予報を取り損ねた日は、値を埋めずに欠けたまま渡します。HistGradientBoostingRegressor は欠けた値をそのまま扱えます

3番目の「比」が、店長の頭の中にあった知識です。 第3章の（b）で、予約30人を多いと読むか少ないと読むかは、当日の予約と飛び込みがどのくらい上乗せされるかで決まると書きました。この上乗せの具合を、曜日と店舗ごとの数字として持たせます。

7番目で値を埋めないのは、埋めた値が実際の予報と違うからです。 前日の予報で埋めると、予報が変わった日の予測を、変わる前の予報で行うことになります。

AIに処理させる

させるのは、翌日の来店客数を、店舗ごとに2つの見込みで予測することです。

品目で見込みを使い分けるのは、外れたときの損が品目で違うからです。 刺身用の鮮魚は、余れば翌日には使えず全量が廃棄になります。多めに見込むほど廃棄が増えるので、中央の見込みで発注します。 一方、看板メニューのハンバーグのひき肉は、翌日の仕込みにも回せますが、足りなければ看板メニューが売り切れになります。こちらは多めの見込みで発注します。 どちらの見込みを使うかは、購買部の品目の表に持たせます。

予測したあとの計算は、規則で行います。

1. 食材ごとの必要な量 ＝ 予測した客数 × 客1人あたりの各メニューの出数 × そのメニューの1人前の使用量（メニューについて合計）
2. 発注までの期間の分を足す … 翌日の納品が無い曜日がある品目は、次の納品日までの日数分を足します
3. 在庫を引く … 閉店時の在庫を引きます
4. 発注単位に切り上げる … ケースや束の単位に切り上げます。0以下なら発注しません

4行目は、予測の限界をはっきりさせるためです。 大みそかや店舗の周年の催しのように、1年に1回しかない日は、学習に使える例がほとんどありません。 そういう日は、案に「過去の例が少ない日」と印を付け、店長の見込みを優先します。

指示内容を固定する

この構成には生成AIへの指示文がありません。 そのかわりに、予測と計算の手順をプログラムとして決めます。中心になる部分は次のとおりです。

import pandas as pd
from sklearn.ensemble import HistGradientBoostingRegressor
from sklearn.model_selection import TimeSeriesSplit

df = pd.read_csv("daily_features.csv", encoding="utf-8",
                 parse_dates=["business_date"], dtype={"store_code": "string"})
df["store_code"] = df["store_code"].astype("category")
df["weekday"] = df["weekday"].astype("category")

features = ["store_code", "weekday", "is_holiday", "holiday_seq", "payday_near",
            "resv_people_15h", "resv_groups_15h", "resv_course_15h",
            "walkin_ratio_4w", "forecast_rain_prob", "forecast_max_temp"]
train = df[~df["closed_or_private"]].sort_values("business_date")

models = {}
for q in (0.5, 0.8):
    m = HistGradientBoostingRegressor(loss="quantile", quantile=q,
                                      categorical_features="from_dtype")
    models[q] = m.fit(train[features], train["guests"])

# 検証：未来のデータで過去を評価しないよう、時間の順に分ける
tscv = TimeSeriesSplit(n_splits=5, gap=1)

categorical_features="from_dtype" は、カテゴリ型の列を自動でカテゴリとして扱う既定の指定です。 店舗と曜日の列をカテゴリ型にしておけば、店舗ごと・曜日ごとの違いを数値の大小としてではなく、別々のまとまりとして学びます。

検証には TimeSeriesSplit を使います。 scikit-learn のドキュメントでは、時間の順に並んだデータに通常の交差検証を使うと、未来のデータで学習して過去のデータで評価することになるとされています。TimeSeriesSplit は、前のほうを学習、その次を評価に使い、学習に使うデータは回を追うごとに前の回を含む形で増えていきます。 gap で、学習と評価の間を空けることもできます。

評価で見るのは、当たり外れの平均だけではありません。 過去の同じ期間について、「この案どおりに発注していたら、廃棄と欠品はどうなっていたか」を、実際の店長の発注と並べて計算します。平均の誤差が小さくても、週末に少なめに外れ続けるモデルは、欠品を増やします。

出力形式を固定する

店長が見る表は、店舗ごとに次の形にします。

上段：翌日の見込み

下段：発注量の案

プログラムの内部では、同じ内容を次のJSONで持ちます。

{
  "store_code": "007",
  "business_date": "2026-10-03",
  "guests": { "p50": 148, "p80": 166 },
  "basis": { "resv_people_15h": 52, "resv_groups_15h": 14,
             "walkin_ratio_4w": 2.8, "forecast": "晴れ 10%" },
  "flag": "none | rare_day | missing_stock",
  "orders": [
    { "item_code": "V-012", "quantile_used": "p50", "need_kg": 4.1,
      "stock_kg": 1.0, "unit": "2kg箱", "proposal": 2,
      "manager_qty": null, "reason": "" }
  ]
}

根拠の欄を必ず出すのは、店長が案を直すかどうかを判断するためです。 「148人」とだけ出ても、店長には直すかどうか決められません。「15時時点で52人、土曜の上乗せ2.8倍」と出れば、「明日は団体が抜けたから少ない」と自分の知識と比べられます。

manager_qty と reason は、店長が直した値と理由です。 翌日の実績と並べて残し、店長の修正が当たったか、案のままのほうが近かったかを後から比べられるようにします。

システムへ連携する

受発注システムには、自動で書き込みません。 案を確定するのは店長で、入力も店長が行います。自動で発注まで進めると、在庫の入力漏れや特別な日の読み違いが、そのまま翌日の納品になります。

人が確認する

店長は、毎日15時すぎに案の表を開き、次の順に見ます。

1. 上段の根拠を読む … 予約の数と上乗せの比が、自分の知っている翌日の様子と合っているかを見ます
2. 印を見る … 「要判断」の日は、案を参考にとどめて自分の見込みで決めます。「在庫の入力なし」の品目は、在庫を数えてから決めます
3. 知っていることで直す … 団体の予約の見込み、近くのイベント、仕入先から聞いた入荷の事情などで直し、理由を一言で書きます
4. 受発注システムに入力する

購買部は、毎週、店長の修正と実績を見ます。

• 店長が直した品目と、その結果が実績に近づいたかどうか
• 案のまま発注して、廃棄や欠品が出た品目
• 同じ理由の修正が続いている店舗

目標は、300件をならして1件6分です。 案を読んで直さずに入力する日は数分で終わり、要判断の日や在庫の入力が抜けた日は、従来に近い時間がかかります。

例外に対処する

上の1行目を守ってください。 在庫は予測で埋めてよいものではありません。在庫の入力が無いまま案を出すと、冷蔵庫にあるものをもう一度発注することになります。

最後の行は、仕組みが止まっても発注は止めないためです。 案が無い日は従来どおりに店長が決めます。案は、あれば店長の時間が減るものであって、無ければ発注できないものにはしません。

記録を残す

• その日の取り込みデータの写し（POS、15時時点の予約、天気予報、在庫）
• 予測に使ったモデルの版と学習の期間
• 見込み客数（中央・多め）と、発注量の案の全品目
• 店長が直した値と理由
• 翌日の実際の客数と出数、予測との差
• 購買部が月に一度集計する、店舗ごとの廃棄と欠品の件数

モデルの版を残すのは、学習し直したときに比べるためです。 月に一度、直近までのデータで学習し直します。新しい版で予測がよくなったかを、同じ期間の差で確かめてから切り替えます。