ゴルフ場の予約記録から直前のキャンセルが出やすい予約を予測し、空き枠の再販売とキャンセル待ちへの連絡の順番を出す

処理の起点を決める

毎朝6時の定時実行を起点にします。 前日の夕方から夜に入った取消が記録に確定し、予約担当が出社する前に一覧ができている時刻です。取消が入るたびに動かす形にはしません。 案が日中に何度も変わると、どの順番で電話しているのかが分からなくなります。

毎朝作るのは、3日後と翌日のプレー日の2日分です。 3日後の分は前日確認の連絡の対象とキャンセル待ちの名簿の順番、翌日の分は予約サイトに出す枠の案が中心です。3日前を選ぶのは、確認の連絡に答えてもらい、取消が出たら名簿に電話する時間が残るからです。 自社のキャンセル規定で取消料がかかり始める日があれば、その前日を見直しの日にそろえます。

モデルの学び直しは月に1回です。 毎月1日に直近24か月の予約で学ばせ直し、前のモデルより当たっているかを較正曲線で確かめてから入れ替えます。

入力データを集める

質を決めるのは、予約の履歴と、見直しの時点で出ていた天気予報です。 いまの予約一覧では、3日前の時点では生きていた予約が「取消」になっています。履歴が無いと、3日前の状態を組み立て直せません。 天気も同じで、プレー日の実際の天気ではなく、3日前に出ていた予報を特徴にします。 実際の天気で学ばせると、3日前の時点では分からないことを知って当てるモデルになります。

予報は毎朝保存しておきます。 過去の予報は後から取り直せないことが多いので、この構成を始めると決めた日から、毎朝の予報をプレー日ごとに保存します。 保存が無い期間は、天気の列を欠けた値のまま学ばせます。

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

答えの付け方を先に決めます。 3日前の見直しでは「3日前から当日までの取消、または無断の不来場」、前日の見直しでは「前日から当日まで」を1とします。人数が4名から3名に減っただけの変更は取消に数えません。 組が残れば枠は空かないからです。

AIへ渡す前に整形する

1. 見直しの時点への組み立て … 履歴を見て、3日前・前日の時点で生きていた予約だけを残し、その時点の人数に戻します
2. リードタイム … 予約を受けた日からプレー日までの日数と、見直しの時点からプレー日までの日数を作ります
3. 人数の変更の回数 … 見直しの時点までに人数が減った回数を数えます。減り続けている組は、そろわなくなりかけています
4. プランの束ね … 予約サイトのプラン名を「昼食付き」「セルフ」「早朝・薄暮」「コンペ」に束ねます
5. 取消の回数の扱い … 予約者の過去2年の取消の回数を、0回・1〜2回・3回以上の区分にします。初めての予約者は欠けた値のまま渡します
6. 天気の区分 … 降水確率を「30％未満・30〜60％・60％以上」に束ね、カテゴリの型にします
7. 重複の確認 … 同じ組が予約サイトと電話の両方で取られていないかを、日時と代表者で確かめます

学ばせる記録の1行は、次のような形にします。1行が「ある予約の、ある見直しの時点の状態」です。 同じ予約が3日前と前日の2行になります。

{
  "booking_id": "B-2025-108812",
  "course": "east",
  "play_date": "2025-11-08",
  "checkpoint": "d-3",
  "time_band": "morning",
  "weekday": "sat",
  "channel": "booking_site",
  "plan_class": "lunch_included",
  "groups": 1,
  "players": 4,
  "player_decrease_count": 1,
  "lead_days_at_booking": 41,
  "member_class": "visitor",
  "competition": false,
  "past_cancel_class": "1-2",
  "rain_prob_class": "30-60",
  "temp_forecast_c": 14.0,
  "label": 1
}

booking_id は突き合わせのために持つ列で、特徴には入れません。 氏名や電話番号はこの段階ですでに外れています。label は、3日前の時点からプレー日までに取り消されたかどうかです。

1番目を省くと、モデルは未来を見て学びます。 いまの一覧で学ばせると、3日前の時点ではまだ分からなかった「人数が2回減った」が特徴に入り、検証ではよく当たるのに、本番では当たらないモデルになります。

5番目で初めての予約者を0回にしないのは、「記録が無い」と「取消が無い」が違うからです。 0で埋めると、初めての予約者がいちばん取り消さない人に見えます。

AIに処理させる

させるのは、予約1件ごとに「見直しの時点からプレー日までに取り消されるか」の確率を出すことだけです。 足し上げ、確認の連絡の対象の選び方、名簿の並べ直しは、Python の側の決まった規則で行います。

確率は較正してから使います。 足し上げて組数にするので、「0.3と出た予約のうち実際に3割が取り消した」という意味の確率でなければ、足した数がずれます。 較正には CalibratedClassifierCV を使います。公式の説明では、十分なデータ（約1,000件超）があれば isotonic は sigmoid と同等以上で、少ないと過学習しやすいとされています。コース別・時間帯別には件数が少ないので、sigmoid から始めます。

時間帯ごとの空きの幅は、予約1件ずつの確率を順に重ねて出します。 空く組数が0組、1組、2組……になる確率を求め、中央の値と、9割の範囲の上の端を一覧に出します。 平均だけを出すと、「平均1.2組」が「必ず1組空く」に読まれます。

空く組数の分布 dist[0..n] を 予約1件ずつ畳み込む
  dist = [1.0]
  for p in その時間帯の予約ごとの確率（組数が2以上の予約は組ごとに分けない）:
      dist = [dist[i]*(1-p) + dist[i-1]*p for i in 0..len(dist)]
  中央の値 = 累積が0.5を超える最初の組数
  上の端   = 累積が0.9を超える最初の組数

2組以上をまとめた予約は、1件として畳み込みます。 同じ予約の2組は一緒に取り消されることが多いので、組ごとに独立に数えると空きの幅が狭く出ます。その予約が取り消されたら組数ぶん空く、として数えます。

前日確認の連絡の対象は、確率の上位から選びますが、上限を置きます。 1つのプレー日で、確率が0.3以上の予約のうち最大8組までです。電話をかけられる数には限りがあり、確率の低い予約まで電話すると、取り消すつもりのない来場者に手間をかけます。

1行目と2行目がいちばん大事です。 過去の取消の回数を特徴に入れている以上、確率の高い予約者を断る使い方をすると、確率が予約者の扱いの差に直結します。 確率を見られるのは予約担当だけにし、使い道を確認の連絡の対象に限ります。

指示内容を固定する

この構成は生成AIを使わないため、プロンプトはありません。 代わりに、学習・計算・一覧の作成を決める設定を、ひとつのファイルにまとめます。

【見込む先】
target: 見直しの時点からプレー日までの取消、または無断の不来場（=1）
        人数の減少だけの変更は 0
見直しの時点: プレー日の3日前・前日の朝
学習期間: 前月までの24か月  検証: 直近3か月

【読まない列（書き出しの段階で除く）】
- 氏名、電話番号、メールアドレス、住所、生年月日
- 予約の備考欄の自由記述

【モデル】
estimator: HistGradientBoostingClassifier(class_weight="balanced")
categorical_features: from_dtype
calibration: CalibratedClassifierCV(method="sigmoid")
入れ替えの条件: 検証の期間で、前のモデルより較正曲線のずれが小さいこと

【前日確認の連絡の対象（3日前の見直し）】
確率 0.3 以上、1プレー日あたり最大 8 組
会員の予約は対象から外し、一覧に「会員」と別枠で出す

【キャンセル待ちの名簿の並べ直し】
1. 空きの見込みの中央の値が1組以上の時間帯を希望する人を前へ
2. 同じ時間帯の中では、希望の人数が空きそうな組の人数に合う人を前へ
3. 同じ条件の中では、受け付けた日時の早い順（この順は崩さない）

【予約サイトに出す枠の案（前日の朝）】
前日の朝の時点で空いている枠のうち、名簿で埋まらない見込みの枠
出す時刻: 名簿の連絡を始めてから2時間後

会員の予約を前日確認の対象から外すのは、会員との関係を予約担当の判断に残すためです。 会員の取消の傾向は担当者がよく知っていて、確率で電話の対象を決めると、長く通っている会員に「来ますか」と聞くことになります。 一覧には別枠で確率を出し、電話するかは予約担当が決めます。

名簿の並べ直しの3番目を「崩さない」と書いているのは、キャンセル待ちの公平さが苦情の種になるからです。 時間帯と人数が合う人を前に出しても、同じ条件の中で後から受け付けた人を先に案内することはしません。

出力形式を固定する

一覧は表で出し、同じ内容を JSON でも残します。 表は予約担当が読むため、JSON はプレー日が過ぎた後の突き合わせのためです。

{
  "run_at": "2026-10-14T06:00:00+09:00",
  "course": "east",
  "play_date": "2026-10-17",
  "checkpoint": "d-3 | d-1",
  "slots": [
    { "time_band": "morning", "booked_groups": 0,
      "expected_open": { "median": 0, "p90": 0 } }
  ],
  "confirm_calls": [
    { "booking_id": "", "time_band": "", "group_size": 0,
      "probability": 0.0, "member": false }
  ],
  "waitlist_order": [ { "waitlist_id": "", "rank": 1, "matched_band": "" } ],
  "online_release": { "groups": 0, "release_at": "" },
  "model_version": "",
  "decided_by": ""
}

1つ目の理由は、booking_id と waitlist_id だけで個人を指せることです。 一覧に氏名や電話番号を書かず、予約担当は番号から予約の管理の仕組みを開いて連絡します。 一覧が誤って共有されても、連絡先は出ません。

2つ目は、expected_open の幅で名簿の連絡の深さを決められることです。 中央の値が1組でも、上の端が3組なら、名簿の上から3組分の人に心づもりを伝えておけます。

システムへ連携する

名簿の表計算には書き込みません。 並べ直した順番は別の列として一覧に出し、名簿そのものは予約担当が管理します。 連絡した日時と結果は、名簿の側にいままでどおり記録します。

人が確認する

1. 前日確認の対象を見る … 会員の別枠と、常連の組を見て、電話するかを決めます
2. 名簿の順番を見る … 同じ条件の中で受け付けた順が逆転していないかを確かめます
3. 天気の急な変化を足す … 朝の予報が一覧を作った後に大きく変わったら、確認の連絡の対象を手で足します
4. 予約サイトに出す枠を決める … 名簿の連絡の結果を見て、出す枠と時刻を決めます

2番目を省かないでください。 並べ直しの規則は受け付けた順を守る形にしていますが、希望の時間帯の書き方が名簿の中でそろっていないと、規則が意図どおりに働きません。

目標は、180件をならして1件6分です。 空きの見込みが無い日は一覧を流し見て終わり、週末の雨の予報の日は確認の電話の対象を読むのに時間がかかります。

例外に対処する

3行目でコンペを外すのは、取消の決まり方が違うからです。 コンペは幹事の判断で組数がまとめて変わり、1件で時間帯の見込みが大きく振れます。

5行目を末尾に回さないのは、書き方の問題で順番が下がることを防ぐためです。 読めないのは名簿の側の問題で、その人の受け付けた順は変わりません。

記録を残す

• 毎朝の書き出しと、見直しの時点に組み立てた予約の一覧
• 毎朝の天気予報（プレー日ごと）
• 予約ごとの確率と、使ったモデルの版
• 時間帯ごとの空きの見込み、前日確認の対象、名簿の順番、予約サイトに出す枠の案
• 予約担当が電話した組と、その結果（取消・継続）
• プレー日の実際の取消、名簿で埋まった枠、予約サイトで埋まった枠、空いたまま残った枠

最後の行が、この構成の効き目を測る記録です。 空いたまま残った枠の数が、見直しを始める前より減っているかを毎月見ます。確率の当たり外れより、こちらが目的の数字です。