飲食店の30分ごとの来店客数を予約・曜日・天気・近隣の催しから見込み、翌週のシフトに要るホールと厨房の人数の案を店長へ出す

処理の起点を決める

本体は毎週水曜の朝6時に動かします。 シフトの確定が金曜なので、店長が水曜と木曜のうちに印の付いたところを確かめ、勤務の希望と合わせる時間を残せる時刻にします。前日の閉店後の締めの処理が終わり、POSレジの記録が書き出せる時刻を選びます。

天気の電文の取得は、それとは別に毎日動かします。 長期のフィードを1日数回読み、自店の地域の府県週間天気予報の電文が新しく載っていれば取って保存します。フィードに載る電文は数日で消えるので、取りこぼすと、その日の予報は二度と手に入りません。

見込む先は、翌週の月曜から日曜までの7日分です。 金曜の確定の後、日曜の夕方にもう一度動かし、週間天気予報が新しくなった日だけ見込みを出し直して、確定した人数との差が大きい時間帯を店長に知らせます。

入力データを集める

質を決めるのは、会計の記録の入店時刻と会計時刻です。 この2つが無いと、30分ごとの入店も在席も作れません。 POSレジによっては、会計時刻しか残らず、入店時刻は注文の最初の時刻で代わりにすることがあります。どちらが残るかを最初に確かめます。

予約の記録は「予約を受けた日」が要ります。 翌週の予約は、水曜の時点ではまだ全部入っていません。過去の各日について「7日前の時点で何人の予約が入っていたか」を作れないと、 予約の入り方を特徴として使えません。

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

POSレジと予約台帳は、帳票の書き出しの機能で表の形のファイルを出し、共有フォルダに置かれたものを読みます。製品によって書き出しの方法と列の名前が違います。 APIを持つものなら定時に取りに行きます。

天気の電文は、地域で選びます。 府県週間天気予報は府県ごとの電文に、地域ごとの予報が入っています。店ごとに、どの電文のどの地域を使うかの対応表を持たせます。 隣の県との境に近い店でも、1つの地域に決めます。

過去の予約は、取消も含めて取ります。 取消された予約を除いて書き出すと、「7日前には入っていたが、後で取り消された」という動きが消え、 取消の多い宴会の時期を多めに見込みます。

AIへ渡す前に整形する

1. 入店を30分の枠に落とす … 入店時刻を30分単位で切り捨て、店・日・枠ごとに人数を足します。来店のなかった枠は0として作ります
2. 滞在の時間を出す … 会計時刻から入店時刻を引き、店・曜日の区分・枠ごとに中央値を取ります。3時間を超える伝票は、締め忘れとして外します
3. ある時点の予約済みの人数を作る … 過去の各日・枠について「7日前の時点で、取り消されずに入っていた人数」を作ります
4. 当時の天気予報をつなぐ … 対象日ごとに、7日前の時点で最も新しかった週間天気予報の降水確率と気温をつなぎます。予報の範囲の外の日は空のままにします
5. 学ばせる組を作る … 「店」「曜日」「枠」「祝日・連休」「予約済みの人数」「降水確率」「最高気温」「催しの有無と規模」「催しの終了からの経過」を特徴に、その枠の入店客数を答えにします
6. 異常な日を外す … 臨時休業、貸し切り、改装の前後、POSレジの入れ替えの前後は、学ばせる組から外します
7. 検証の分け方を決める … 時系列を崩さないよう TimeSeriesSplit で、過去で学んで後の期間で確かめる組を作ります

4番目で、実際の天気をつながないでください。 実際に雨だった日を学ばせると、モデルは天気が確実に分かっている前提で学びます。本番で渡せるのは予報だけなので、当時の予報で学ばせます。 保存を始めて間もない期間は、天気の列を空のまま学ばせ、たまるにつれて効き方を見ます。

7番目で gap を使います。 TimeSeriesSplit の gap は、学ばせる期間の終わりから確かめる期間の前に除く数です。同じ日の別の枠が両側に入ると、答えが漏れて当たりすぎます。 少なくとも7日分を空けます。

AIに処理させる

させるのは、店・日・30分ごとの入店客数を、真ん中と多めの2本で見込むことだけです。 在席への換算、人数への換算、印付けは、決まった計算で行います。

右端の列が、店長が見るところを決めます。 low_history は、開店して日の浅い店や、過去に例の無い規模の催しの日です。モデルの見込みを信じる根拠が薄いところだけを、店長に回します。

4行目がいちばん起きやすい失敗です。 日曜の出し直しで客数の見込みが下がったからといって、確定したシフトを自動で減らすと、働くつもりで予定を空けていた人の勤務が前日に消えます。 出し直しの結果は、店長への知らせにとどめます。

指示内容を固定する

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

【モデル】
- HistGradientBoostingRegressor(loss="poisson")                 真ん中
- HistGradientBoostingRegressor(loss="quantile", quantile=0.8)  多めの側
- categorical_features = ["store", "weekday", "slot", "holiday_type"]
- monotonic_cst = {"booked_7d": 1}  予約済みの人数が多いほど、入店も多い向き
- 目的変数 = その30分の枠の入店客数（0以上）
- 天気の列は予報の範囲の外なら空のまま渡す（埋めない）

【在席への換算】
- 在席の客数(t) = Σ 入店客数(s) × [ s ≦ t < s + 滞在の時間(s) ]
- 滞在の時間は 店・曜日の区分・枠 ごとの中央値（30分単位に丸める）
- 予約の宴会は、予約台帳のコースの時間を滞在の時間とする

【人数への換算】
- ホール = 在席の客数 ÷ 1人が受け持てる在席の客数（切り上げ）
- 厨房 = 入店客数 ÷ 1人がさばける入店の客数（切り上げ）
- どちらも、時間帯ごとの最低人数を下回らない
- 真ん中の人数 = 確定のシフトの目安、多めの人数 − 真ん中 = 声をかけておく人

【印を付ける条件】
- low_history：その店・曜日・枠で学ばせた組が 30 未満、または催しの規模が過去の最大を超える
- wide：多めの入店 − 真ん中の入店 が、真ん中の 4 割を超える
- event：催しの予定表で、終了の時刻から 2 時間以内の枠
- jump：先週の同じ日の見込みから、ホールか厨房が 2 人以上変わった
- late：22時以降の枠（18歳以上で組む必要があることを店長に示す）
- 印の無い日は、店長の確認なしで表に載せる

「天気の列を埋めない」を書いておかないと、平年の値で埋める実装になりがちです。 埋めると、予報が無い日をモデルは「平年並みの天気と分かっている日」として扱います。分からないことは、分からないまま渡します。

monotonic_cst の向きは、学ばせる前に記録で確かめます。 宴会の多い時期は、予約が多い日ほど予約なしの客が入れず、入店の合計が予約ほどには増えない店もあります。 向きの制約を付けた場合と付けない場合の両方で、確かめる期間の外れ方を比べてから決めます。

late の印は、人数を変えるための印ではありません。 22時以降の枠に、18歳以上のスタッフで人数がそろうかを、店長が名簿と照らして確かめるための目印です。

出力形式を固定する

店・日ごとに、次の形のJSONを作り、表にしてシフト作成の仕組みへ渡します。

{
  "store": "",
  "date": "",
  "weather_forecast": { "issued_at": "", "pop": null, "temp_max": null },
  "slots": [
    { "slot": "11:30",
      "arrivals": { "booked": 0, "p50": 0, "p80": 0 },
      "seated": { "p50": 0, "p80": 0 },
      "hall_staff": { "p50": 0, "p80": 0 },
      "kitchen_staff": { "p50": 0, "p80": 0 },
      "flags": ["low_history | wide | event | jump | late"] }
  ],
  "model_version": "",
  "manager_override": [ { "slot": "", "hall": null, "kitchen": null, "reason": "" } ]
}

1つ目の理由は、booked と p50 を並べて見せられることです。 いま入っている予約の人数と、見込みの入店の差が、そのまま「予約なしで来る人」と「これから入る予約」の分です。店長は、この差が店の感覚と合うかを見れば足ります。

2つ目は、arrivals と seated を分けて持てることです。 ホールの人数は seated から、厨房の人数は arrivals から出ています。どちらが人数を押し上げたのかが、表の上で分かります。 宴会の日は在席が長く伸び、昼の山は入店が鋭く立ちます。

3つ目は、weather_forecast で見込みの前提が残ることです。 どの発表時刻の予報を使ったかを残すので、外れた日に「予報が外れたのか、モデルが外れたのか」を後から分けられます。 予報の範囲の外の日は pop が null のまま残ります。

4つ目は、manager_override で直した記録が残ることです。 店長が人数を直したら、枠と人数と理由を書きます。シフトに渡るのは直した後の値で、モデルの値も残ります。

システムへ連携する

シフト作成の仕組みには、人数の表を渡すだけです。 取り込みは店長が行い、取り込んだ後に誰を入れるかは、勤務の希望と労働時間、年齢を見て人が決めます。 必要人数の列を自動で書き換える経路があっても、確定したシフトに触れる経路は作りません。

モデルの学ばせ直しは、月に一度、別の処理として動かします。 毎週の見込みは、その月に決めた版のモデルで出します。学ばせ直した版は、直近の8週を確かめる期間にして前の版と外れ方を比べ、良くなっていたときだけ切り替えます。 毎週学ばせ直すと、見込みが変わった理由が記録の変化なのかモデルの変化なのか、店長にも人事部にも分からなくなります。

人が確認する

店長が見るのは、印の付いた日と時間帯だけです。 印の無いところはそのまま表に載ります。7日分の全部の枠を開く設計にすると、第10章の16.0時間には収まりません。

1. event と low_history を先に見る … 催しの終演の後と、記録の少ないところです。会場の催しの客層が、この店に来る客層かを考えます
2. wide を確かめる … 見込みの幅が広い時間帯です。真ん中で組み、声をかけておく人を多めに持ちます
3. jump を確かめる … 先週から人数が大きく変わった日です。大口の宴会の予約や取消が入っていないかを、予約台帳で見ます
4. late を名簿と照らす … 22時以降の枠に、18歳以上のスタッフで人数がそろうかを確かめます
5. 直したら理由を書く … manager_override に枠と人数と理由を残します

確認の期限は木曜の15時に置きます。 それを過ぎた店は例外処理のとおり「未確認」として表に載り、人事部が店長に電話で確かめます。

1番目の催しの日は、モデルより店長の知っていることのほうが確かなことがあります。 同じ会場の催しでも、子ども向けの催しの帰りは家族連れが昼に来て、夜の公演の帰りは遅い時間に少人数で来ます。直すことはためらわず、直した理由を必ず残します。

目標は、240件をならして1件4分です。 印が付くのは一部の日という想定で、それより多い週は、催しの予定表が細かすぎるか、wide の閾値が狭すぎます。

例外に対処する

上から2行目が、最初の数か月でいちばん起きます。 電文の取得の処理が止まっていても、見込みは天気の列を空にして出てしまいます。取れなかった日の数を毎週の報告に載せ、続けて空の日があれば取得の処理を疑います。

記録を残す

• 実行ごとに、書き出したPOSと予約台帳のファイル名と書き出し日時
• 取得した天気の電文の発表日時と、店ごとに使った地域
• 学ばせたモデルの版（学ばせた期間、特徴の列、monotonic_cst の有無）
• 確かめる期間での外れ方（真ん中と多めの側を、それぞれ枠ごとに）
• 店・日ごとの出力のJSON（booked、p50、p80、flags）
• 店長が直した記録（manager_override の枠・人数・理由）
• 日・枠ごとの実際の入店客数と、見込みとの差

外れ方は、真ん中と多めの側を別々に見ます。 多めの側は「10日のうち8日はこれを下回る」水準なので、実際がそれを上回った枠が2割前後に収まっているかを数えます。真ん中だけを当たり外れで測ると、多めの側が当たっているかが分かりません。

直した記録は、モデルを学ばせ直す材料になります。 同じ会場の催しで毎回同じ方向に直しているなら、催しの規模の列の付け方が実態と合っていません。