時間貸し駐車場の運営会社が、入出庫の記録とイベント・天気から Python で駐車場ごと・時間帯ごとの満車を予測し、料金の見直しの材料にする

処理の起点を決める

毎月1日の定時実行を起点にします。 その月に順番の回ってくる90か所の材料を、前月までの記録で作ります。材料は月初の3営業日のうちに担当者の手元にそろえ、月の中ごろの部長の会議に間に合わせます。

モデルの学び直しも、毎月1日にまとめて行います。 全270か所の直近24か月の記録で学ばせ、前のモデルより当たっているかを確かめてから入れ替えます。 駐車場ごとに別のモデルを作らず、駐車場を列として渡します。区画の少ない駐車場や、記録の短い駐車場の見込みが不安定になるからです。

入力データを集める

質を決めるのは、満車の表示の記録です。 入出庫の記録から在車の台数を作っても、区画の数と在車の台数が一致した時刻が満車とは限りません。 故障で使えない区画や、工事で閉めている区画があるからです。満車の表示を出していた時刻を、満車の答えにします。 表示の記録が残らない駐車場は、在車の台数が区画の数から1台を引いた数以上になった時刻で代えます。

催しの表は、担当者が作ります。 競技場の試合、会館の公演、花火、祭りなど、催しの会場から歩いて行ける範囲の駐車場に番号を結び付けます。会場ごとに一度作れば、毎月は日程を足すだけです。

読まない列も決めます。 ナンバーを読み取るカメラのある駐車場でも、ナンバーの記録は書き出しません。提携の割引の区分は、どの店の割引かまでは要らず、「提携の割引あり」だけで足ります。

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

駐車場の管理の仕組みから、前月までの入出庫の記録、満車の表示の記録、料金の設定の履歴を書き出します。書き出しの列の名前と数は、毎月の処理の最初に決めたとおりかを照らし、違えばそこで止めます。

精算機ごとの時計のずれを確かめます。 精算機の時計が数分ずれていると、入庫と出庫の時刻がずれ、15分ごとの在車の台数が隣の15分に流れます。 管理の仕組みが時刻を合わせているかを最初に確かめ、合わせていない精算機は書き出しの段階で補正します。

料金の列は、その時刻に効いていた料金の表から作ります。 料金の設定の履歴の適用の開始日で、どの日のどの15分にどの料金だったかを引きます。過去に料金を変えた駐車場では、変える前と後で列の値が変わります。

AIへ渡す前に整形する

1. 在車の台数を作る … 入庫の時刻から出庫の時刻までの車を、15分ごとに数えます。営業時間の外の15分は行を作りません
2. 長く停まっている車を分ける … 72時間を超えて停まっている車は、別の列に数えます。放置された車が区画を埋めているのか、需要なのかを分けるためです
3. 満車の答えを作る … 15分のうち満車の表示が出ていた時間が半分を超えれば「満車」とします
4. 閉めていた区画を引く … 工事や故障で閉めていた区画の数を、その日の区画の数から引きます
5. ずらした列を作る … 1週間前・2週間前・前年の同じ曜日の、同じ15分に満車だったかを列にします
6. 催しの印を付ける … 催しの開始の2時間前から終了の1時間後までを「催しの時間」とします
7. 異常な日を外す … 精算機が止まっていた日、災害で閉めた日は学ばせる記録から外します

学ばせる記録の1行は、次のような形にします。1行が「ある駐車場の、ある日の15分」です。

{
  "lot_id": "P-0142",
  "location_type": "hospital",
  "capacity": 24,
  "closed_spaces": 0,
  "date": "2026-09-16",
  "slot": "11:15",
  "weekday": "wed",
  "holiday_flag": "none",
  "event_window": false,
  "rain_class": "none",
  "temp_c": 27.0,
  "price_per_30min": 300,
  "daily_max_price": 1200,
  "full_lag_7d": true,
  "full_lag_14d": true,
  "full_lag_364d": false,
  "long_stay_cars": 1,
  "occupied": 24,
  "full": true
}

occupied と full は答えを作るための列で、見込みには入れません。 long_stay_cars は、見込む月の前月の値を入れます。見込む時点で手に入る値だけを列にするためです。

2番目を省くと、放置された車が多い駐車場が「よく満車になる駐車場」に見えます。 料金を上げても放置の車は減らず、普段の利用者だけが他へ流れます。 長く停まっている車の多い駐車場は、料金ではなく見回りの頻度の話です。

AIに処理させる

させるのは、駐車場 × 日 × 15分ごとに、満車になる確率を見込むことだけです。 普段の日の表、候補の時間帯の印、料金を変えた前後の比較は、確率を受け取った後の Python の側で決まった規則で行います。

料金の列には monotonic_cst で -1 を付けます。 公式の説明では、カテゴリの列には単調の制約を付けられないとされているので、料金は数値の列として渡します。 制約が無いと、たまたま料金を上げた時期に近くで再開発が進んでいた駐車場の記録から、「料金が高いほど満車になる」という形を学ぶことがあります。

普段の日の確率は、同じモデルに「催しの時間ではない」「雨ではない」という行を作って見込みます。 順番の回ってきた駐車場について、来月の曜日 × 15分の枠ごとに、催し無し・雨無しの行を並べてモデルに通し、その確率を表にします。催しのある日の確率は、別の表に分けて出します。

候補の時間帯の印は、決まった式で付けます。

上げる候補の時間帯 = 普段の日の満車の確率 ≥ 0.6 の15分が、同じ曜日の区分で連続して1時間以上
下げる候補の時間帯 = 普段の日の在車の割合（直近3か月の平均）≤ 0.3 の15分が、連続して3時間以上
最大料金の見直しの候補 = 最大料金で精算した車の割合が直近3か月で上位1割の駐車場

2行目が大事です。 単調の制約を付けたモデルに料金を変えた行を通せば、確率は動きます。しかしその動きは、料金を変えた記録が少ない中で形を整えただけの値で、料金の効き方を見込んだものではありません。 材料には出しません。

当たり方は、満車の確率の当たり方で見ます。 学ばせる期間と確かめる期間は TimeSeriesSplit で分けます。公式の説明では、時刻の順に並んだ記録で、前の期間で学ばせて後の期間で確かめる分け方で、通常の交差検証では未来の記録で学んで過去で確かめてしまうとされています。gap で学ばせる期間の末尾を除けるので、1週間前の列が確かめる期間にかからないよう、1週間分を空けます。

指示内容を固定する

この構成は生成AIを使わないため、プロンプトはありません。 代わりに、学ばせ方・普段の日の作り方・候補の印の線・材料に載せる内容を、ひとつの設定ファイルにまとめます。

【見込む先】
full: 15分のうち満車の表示が半分を超えた（表示の記録が無い駐車場は 在車 ≥ 区画の数 − 閉めた区画 − 1）
単位: 駐車場 × 日 × 15分
学習期間: 前月までの24か月（全270か所をまとめて1つのモデル）
検証: TimeSeriesSplit（日付の単位で5つに分け、gap で1週間分を空ける）

【モデル】
HistGradientBoostingClassifier(loss="log_loss", categorical_features="from_dtype")
monotonic_cst: {"price_per_30min": -1, "daily_max_price": -1}
入れ替えの条件: 検証の期間で、前のモデルより確率の当たり方が良いこと

【普段の日】
event_window: false  rain_class: none  holiday_flag: none
来月の曜日 × 15分の枠ごとに見込み、同じ曜日の区分（平日・土曜・日祝）でまとめる

【候補の印】
上げる候補: 満車の確率 0.6 以上が1時間以上続く
下げる候補: 在車の割合 0.3 以下が3時間以上続く
最大料金の見直し: 最大料金で精算した車の割合が上位1割

【材料に載せる内容】
- 曜日の区分 × 15分の、普段の日の満車の確率の表
- 曜日の区分 × 15分の、在車の割合の表（直近3か月）
- 催しのある日の満車の確率（別の表）
- 候補の時間帯の印と、印を付けた理由の式
- 長く停まっている車の台数の推移
- 料金を変えた駐車場の、変える前と後の3か月の比較
- 駐車場法の届出の対象かどうか（台帳の印）

「普段の日」の決め方を設定ファイルに書くのが大事です。 担当者によって「雨の日も普段の日に入れる」「祝日の前の金曜は外す」と分かれると、同じ駐車場の材料が人によって違う形になります。 決め方を1か所に書き、変えるときはその履歴を残します。

「駐車場法の届出の対象かどうか」を材料に載せるのは、変えると決めた後の手配を漏らさないためです。 駐車場法では、都市計画区域の中で駐車の用に供する部分が500平方メートル以上の、料金を取る路外駐車場の管理者は、駐車料金に関する事項を含む管理規程を届け出ることとされ、管理規程に定めた事項を変更したときは10日以内に届け出なければならないとされています。

出力形式を固定する

材料は駐車場ごとの1枚の表と図で出し、同じ内容を JSON でも残します。 表と図は担当者と部長の会議で読むため、JSON は翌月以降の振り返りのためです。

{
  "run_at": "2026-10-01T06:00:00+09:00",
  "lot_id": "P-0142",
  "review_month": "2026-10",
  "capacity": 24,
  "normal_day_full_prob": [
    { "day_type": "weekday", "slot": "11:15", "p_full": 0.0 }
  ],
  "occupancy_rate": [
    { "day_type": "weekday", "slot": "21:00", "rate_3m": 0.0 }
  ],
  "event_day_full_prob": [
    { "event_id": "", "slot": "", "p_full": 0.0 }
  ],
  "flags": [
    { "type": "raise | lower | max_price", "day_type": "weekday",
      "from": "11:00", "to": "14:00", "rule": "" }
  ],
  "long_stay_trend": [ { "month": "2026-09", "cars": 0 } ],
  "price_change_compare": null,
  "parking_act_filing": true,
  "model_version": "",
  "decision": "keep | raise | lower | null",
  "decided_by": "",
  "reason": ""
}

1つ目の理由は、印と決定を同じ行に残せることです。 flags は計算が埋め、decision と reason は担当者が埋めます。3か月後に同じ駐車場の順番が回ってきたとき、前回の印と決定を読み直せます。

2つ目は、rule で印の根拠が読めることです。 「満車の確率0.6以上が平日の11時から14時まで続いた」と式のまま残すので、部長の会議で「なぜ上げる候補なのか」を数字で説明できます。

システムへ連携する

駐車場の管理の仕組みへは書き込みません。 料金の設定を自動で変えると、看板の料金と精算機の料金が食い違う時間ができます。 利用者にとっては、表示と違う料金を取られることになります。

人が確認する

1. 催しの日と普段の日の違いを見る … event_day_full_prob だけが高い駐車場は、料金の表を変えずに、催しの日の扱いを考えます
2. 長く停まっている車を見る … long_stay_trend が増えていれば、料金より先に見回りを考えます
3. 競合の料金を確かめる … 近くの競合の駐車場の料金を、いまと同じ方法で確かめます
4. 地権者との取り決めと届出を確かめる … 料金を変えるときの取り決めと、parking_act_filing を見ます
5. 候補を付けて理由を書く … decision と reason を埋めます

1番目を省かないでください。 普段の日の表と催しの日の表を並べて見るのは、料金の表を上げても催しの日の満車は変わらず、普段の日の利用者だけが減ることがあるからです。

目標は、90件をならして1件12分です。 印の無い駐車場は表を流し見て据え置きにし、印のある駐車場は競合と取り決めを確かめるので時間がかかります。 その配分でならすと12分です。

例外に対処する

4行目で印を付けないのは、誤りの向きを決めるためです。 開業したばかりの駐車場は、まだ知られていないだけで空いていることがあります。その時期に下げる候補の印を付けると、知られる前に料金を下げることになります。

記録を残す

• 毎月の書き出しと、15分ごとの在車の台数と満車の答え
• 見込み（満車の確率）と、使ったモデルの版
• 駐車場ごとの材料と、印と印の式
• 担当者の決定と理由、部長の会議の結論
• 料金を変えた駐車場の、変えた日と新しい料金の表
• 設定ファイルの変更の履歴（普段の日の決め方、印の線）

4つ目と5つ目を並べて残すのが、この構成の振り返りの土台です。 料金を変えた駐車場の3か月後の材料には、変える前と後の比較が自動で載ります。 何回か一巡すると、印の線が高すぎるか低すぎるかが見えてきます。