動物園が過去の入園の記録・曜日・天気・催しから Python で日別の入園者数を予測し、ゲートと売店のスタッフの配置と売店の仕入の目安を出す

処理の起点を決める

毎週水曜の8時、開門の前に動かします。 運営課の担当が水曜の午後に翌週のシフトを組む前に、翌週の見込みと人数の案ができている状態にします。

毎日13時に、翌日分だけ作り直します。 売店の責任者が14時に弁当・パンの数を業者に伝える前に、翌日の天気の見通しで作り直した仕入の数の案を出します。 業者に数を伝える期限は契約によって違うので、取引のある業者に確かめ、作り直しの時刻を期限の1時間前に合わせます。

アイスと飲み物は次の配送まで、土産の菓子は次の発注までの合計を、発注の日の作り直しでまとめて出します。

ゲートの仕組みの書き出しが届かない、または前の開園日の入園者が0のときは、動かしません。 書き出しの失敗を「入園者が0人の日」として学ばせないためです。担当者に知らせ、ゲートの仕組みの保守の会社に書き出しのやり直しを頼みます。

入力データを集める

質を決めるのは、団体の予約の台帳です。 過去の記録から団体の分を引くには、その日に実際に来た団体の人数が要ります。予約の人数と当日の人数がずれることは多いので、ゲートの団体の券種の数を正とし、台帳は予定の側だけに使います。

雨天の扱いの列も必ず持ちます。 遠足は雨で中止や延期になるので、雨の予報の日に予約の数をそのまま足すと、見込みが上にずれます。

売り切れの時刻と廃棄の数が、仕入の側の質を決めます。 販売の数だけを記録していると、昼前に売り切れた日の「本当は売れた数」が分かりません。 売り切れた日を印にして、学ばせる記録から外すか、売り切れの時刻から1日分を見積もる列を作ります。

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

ゲートの仕組みからは、前日までの入園の記録を、30分ごと・券種ごとの人数の形で毎日書き出す設定を作ります。1人ずつの記録ではなく、30分ごとの人数の集計で受け取ります。 年間パスポートの番号や氏名は書き出しません。

過去の天気は、最初に3年分をまとめて取り、その後は毎週1週間分を足します。 地点は、園にいちばん近いアメダスの地点にします。見込みの資料には「出典：気象庁ホームページ」と、加工したことを書いておきます。

天気の見通しを担当者の入力で済ませる場合は、「晴れ・曇り・雨・雪」の4つと、最高気温と降水の確率の数字だけを入れてもらいます。 自由な文で書くと、プログラムが読めません。

AIへ渡す前に整形する

1. 団体の分を引く … 日ごとに、ゲートの団体の券種の数を入園者数から引き、一般の入園者数を作ります
2. 異常の日を外す … 臨時の休園、台風で早く閉めた日、ゲートの機械の止まりの日を印にします
3. 催しの種類をそろえる … 予定表の自由な書き方を、「動物の公開の始まり」「ガイドの催し」「夜間の開園」「無料の日」「近くの行事」の5つの区分にそろえます
4. 公開の始まりからの日数を作る … 動物の赤ちゃんの公開は、始まりの週に強く効き、その後に薄れていきます。始まりからの日数を項目にします
5. 項目を作る … 曜日、祝日、連休の何日目か、年末年始、学校の長期休み、催しの区分、降水量、最高気温、前年の同じ週の一般の入園者数
6. 入園の時刻の形を作る … 曜日の種類と天気の区分ごとに、直近12週の30分ごとの入園の割合を作ります
7. 品目ごとの販売の割合を作る … 品目ごとに、一般と団体を合わせた入園者100人あたりの販売の数を、最高気温の帯と曜日の種類で出します。売り切れの日は外します

1番目を省かないでください。 第3章の（a）のとおり、団体を含めたまま学ばせると、団体の多い季節の平日に、一般の客が多い日だとモデルが覚えます。 引いた後の一般の入園者数を学ばせ、翌週の見込みに団体の予約の数を足します。7番目で最高気温の帯を使うのは、アイスと飲み物の売れ方が気温で大きく変わるからです。

AIに処理させる

させるのは、「開園日ごとの一般の入園者数」を、真ん中と5つの分位点で見込むことだけです。 団体の加算、30分ごとの入園の数、人数の案、仕入の数の案、印付けは、決まった計算で行います。

分位点を5つも作るのは、品目ごとに使う位置が違うからです。 売り切れたときの損を「売れたはずの利益」、売れ残ったときの損を「仕入の値段から戻る分を引いた額」とすると、仕入の数は、売り切れの損 ÷（売り切れの損 ＋ 売れ残りの損）の分位点に置くのが筋です。 売店の責任者が品目ごとに2つの損を表に書けば、使う分位点が決まります。

4行目を必ず守ってください。 入園者が多い見込みの日でも、赤ちゃんの公開の時間を延ばす判断に、見込みを使ってはいけません。

指示内容を固定する

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

【モデル（一般の入園者数。団体の券種の分を引いた値を学ばせる）】
- scikit-learn の HistGradientBoostingRegressor
  ・真ん中           … loss="poisson"
  ・分位点 0.1〜0.9  … loss="quantile", quantile=0.1 / 0.3 / 0.5 / 0.7 / 0.9（5つのモデル）
  ・曜日の種類、催しの区分、天気の区分は pandas の Categorical にする
- 学ばせる記録 = 過去3年の開園日。臨時の休園・早い閉園・ゲートの止まりの日は外す
- 確かめ方 = TimeSeriesSplit（n_splits=4, test_size=56, gap=7）
  ・未来の記録で学ばせて過去を確かめることを防ぐ
  ・gap=7 は、水曜に翌週を見込むときに直近の1週の記録がまだ無いことに合わせる
- 学ばせ直しは月に1回

【団体の分】
- 団体の分 = Σ（予約の人数 × 団体の種類ごとの来園の割合）
- 来園の割合は、天気の見通しが雨なら「雨の日に来た割合」、それ以外は「晴れ・曇りの日に来た割合」
- 雨天の扱いが「中止」の団体は、雨の見通しなら0にする

【人数の案（配置の決まりの表から）】
- ゲート = 30分ごとの入園の数（一般の分位点0.9 ＋ 団体の分）÷ ゲート1か所がさばける数（切り上げ）
- 売店   = 時間帯ごとの入園の数の真ん中 × 売店に寄る割合 ÷ レジ1人がさばける数（切り上げ）、最少1人
- 駐車場 = 開門から2時間の入園の数の分位点0.9 × 車で来る割合 ÷ 誘導1人が受け持つ台数（切り上げ）
- さばける数・寄る割合・車で来る割合は、担当者が決めて表に置く

【仕入の数の案】
- 品目ごとの使う分位点 = 売り切れの損 ÷（売り切れの損 ＋ 売れ残りの損）に近い分位点
- 仕入の数 = （一般の入園者数の分位点 ＋ 団体の分）÷ 100 × 気温の帯の販売の割合 － 持ち越せる在庫
- 何日分をまとめて出すかは、品目の表（弁当・パン＝1日、アイス・飲み物＝次の配送まで、菓子＝次の発注まで）

【印を付ける条件】
- new_event … 催しの区分が初めて、または前回から1年以上空いた
- wide      … 分位点0.9と0.1の差が、真ん中の6割を超える
- group     … 団体の分が一般の真ん中の5割を超える
- weather   … 翌日の見通しの最高気温が水曜の時点から5度以上違う、または雨・雪に変わった
- mix_shift … 品目の販売の割合が前月の同じ気温の帯から2割以上動いた
- 印の無い日は、人数と仕入の数の案をそのままシフトと発注の表の下書きに載せる

gap=7 を置くのは、使うときの条件で確かめるためです。 水曜に翌週を見込むときは見込む週との間に空きがあり、空きを置かずに確かめると、当たり方を良く見積もります。

ゲートに上側の分位点を使うのは、開門直後の行列がいちばん困るからです。 真ん中で人を置くと、10日に1日の混む日にゲートが足りません。さばける数と寄る割合は季節で変わるので、プログラムに書き込まず表に置きます。

出力形式を固定する

開園日ごとに、次の形のJSONを作り、表にしてシフトの表と発注の表の横に載せます。

{
  "date": "",
  "day_type": "weekday | saturday | holiday | long_holiday",
  "events": [""],
  "weather_input": { "sky": "", "tmax": 0, "pop": 0, "issued_at": "" },
  "general": { "mean": 0, "q10": 0, "q30": 0, "q50": 0, "q70": 0, "q90": 0, "last_year_same_week": 0 },
  "group": { "reserved": 0, "expected": 0, "rain_cancel": 0 },
  "arrivals": [ { "time": "09:30", "q50": 0, "q90": 0 } ],
  "staff_draft": [ { "time": "09:30", "gate": 0, "shop": 0, "parking": 0 } ],
  "purchase_draft": [ { "item": "", "quantile_used": 0.5, "qty": 0, "carry_over": 0 } ],
  "flags": ["new_event | wide | group | weather | mix_shift"],
  "model_version": "",
  "override": { "staff": null, "purchase": null, "by": "", "reason": "" }
}

1つ目の理由は、general と group を分けて残せることです。 外れたときに、一般の客の見込みが外れたのか、団体の予約が当日に変わったのかを分けられます。団体の外れは台帳の雨天の扱いを直す話で、モデルを直す話ではありません。

2つ目は、purchase_draft に quantile_used を残すことです。 どの分位点で数を出したかが分かれば、売れ残りが続いたときに、品目の損の表を直すべきか、見込みが外れているのかを分けられます。 同じ弁当でも、使う位置を変えれば数は変わります。

3つ目は、override で人の直しと理由が残り、次の同じ催しのときの材料になることです。

システムへ連携する

シフトの表と発注の表へは、書き込みません。 案は見込みの表に並べ、担当者がシフトの表に、売店の責任者が業者への連絡に、自分で写します。 業者に送る数を自動で送る作りにすると、前日の在庫を見ずに数が飛びます。

通知には、入園者数そのものを流しません。 流すのは「印の付いた日」と「見込みの表の場所」だけにします。入園者の数は、設置者への報告に使う数字でもあるからです。

人が確認する

担当者が見るのは、毎週の人数の案と、印の付いた日の理由です。 印の無い日は、人数の案を流し見てシフトに写します。全日を前の方法で足し引きし直す運用にすると、第10章の5.0時間には収まりません。

1. group を先に見る … 団体の予約の多い日です。雨の見通しなら、学校に延期の連絡が来ていないかを台帳で確かめます
2. new_event を見る … 初めての催しや公開の始まりの日です。担当者の見立てを並べ、どちらで組むかを決めます
3. wide と weather を見る … 見込みの幅が広い日と天気の変わり目です。ゲートを上側で組み、売店は品目の表のとおりにするかを決めます
4. 直したら理由を書く … override に値と理由と直した人を残します

売店の責任者が見るのは、毎日13時の仕入の数の案です。 前日の売れ残りと、業者が作れる数を見て数を決めます。mix_shift が付いた品目は、売れ方が変わった理由（値段を変えた、新しい商品を置いた）を確かめてから数を決めます。

2番目で、見込みより担当者の見立てを採る日があって構いません。 見込みは、初めて公開する動物の人気を知りません。

例外に対処する

上から5行目の紹介の直後は、記録の傾向が当てはまりません。 この期間は見込みをゲートの人数の下限として使い、上側の判断は担当者に任せます。

7行目を忘れると、売り切れた日を「その数で足りた日」と覚え、仕入が減っていきます。

記録を残す

• 読み込んだ入園の記録の件数と、団体の券種の分を引いた後の一般の入園者数
• 開園日ごとの見込み（真ん中と5つの分位点）と、そのとき使った天気の見通し
• 団体の予約の数と、雨の日の割合で見込んだ団体の分
• 人数の案、品目ごとの仕入の数の案と使った分位点、印
• 担当者と売店の責任者が直した値と理由（override）
• 実際の一般の入園者数・団体の数、品目ごとの販売・売り切れの時刻・廃棄の数
• モデルの版、学ばせた期間、配置の決まりの表と品目の損の表の値

6つ目の廃棄と売り切れは、毎週品目ごとに数えます。 廃棄が続くなら使う分位点を下げ、売り切れが続くなら上げます。