ホテルの予約の経路・リードタイム・プラン・人数から直前キャンセルとノーショーを見込み、宿泊日ごとの売り越しの枠の案を出す

処理の起点を決める

毎朝5時の定時実行を起点にします。 夜間の予約・取消がPMSに確定した後で、予約課が出社する前に一覧ができている時刻です。予約が入るたびに動かす形にはしません。 枠は1日1回決めれば足り、予約のたびに案が変わると、担当者がどの数字を信じればよいか分からなくなります。

毎朝作る一覧は、見直しの対象の宿泊日だけです。 その朝に30日前・7日前・2日前に当たる宿泊日の3日分を出します。月の初めにまとめて作る形にしないのは、予約の中身が日々変わるからです。 30日前の時点の案は、7日前には古くなっています。

モデルの学び直しは月に1回です。 毎月1日の朝、前月までの24か月分の予約で学ばせ直し、学び直した後のモデルが、前のモデルより当たっているかを確かめてから入れ替えます。 当たり方が悪くなっていれば、前のモデルを使い続けて担当者に知らせます。

入力データを集める

質を決めるのは、予約の履歴です。 PMSの予約一覧は、たいていいまの状態しか出しません。30日前に見直すときの予約は、その時点では取り消されていなかったのに、いまの一覧では「取消」になっています。履歴が無いと、見直しの時点の状態を組み立て直せません。 書き始める前に、PMSが変更の日時を残しているかを確かめてください。

暦の表は担当者が作ります。 近くの会場の催しや学会の日程は、予約の記録からは分かりません。ここに載っていない催しの日は、モデルが去年と同じ傾向で見込みます。 新しい催しを知ったら、表に1行足すのが担当者の仕事になります。

読まない列も決めておきます。 氏名、連絡先、国籍、生年月日は書き出しの段階で外します。国籍で取消の傾向を見込むと、確率の数字がそのまま宿泊客の扱いの差につながりかねません。 見込みに要るのは、予約の条件だけです。

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

PMSから、予約と予約の履歴をそれぞれ書き出します。 多くのPMSは帳票やデータの書き出しの機能を持っていますが、項目と形式は製品ごとに違います。履歴が書き出せない場合は、毎朝の予約一覧をそのまま日付付きで保存し、翌日以降の差から履歴を作ります。 この場合、学ばせられる記録がたまるまで、書き出しを始めてから1年ほど待つことになります。

答えの付け方を先に決めます。 この構成で見込むのは、宿泊日の2日前以降の取消と、連絡の無い不泊です。2日前より前の取消は、2日前の見直しで反映できるので含めません。30日前の見直しでは「30日前から当日までの取消と不泊」、7日前では「7日前から」と、見直しの時点ごとに答えを付け直します。 時点ごとにモデルを分けるか、時点を特徴の1つにするかは、記録の量で決めます。

AIへ渡す前に整形する

1. 見直しの時点への組み立て直し … 履歴を見て、30日前・7日前・2日前の時点で生きていた予約だけを残し、その時点のプランと人数に戻します
2. リードタイムの計算 … 予約を受けた日から宿泊日までの日数と、見直しの時点から宿泊日までの日数の2つを作ります
3. 変更の回数 … 見直しの時点までに、日付・人数・客室タイプが何回変わったかを数えます
4. プランの束ね … OTAごとにばらばらなプラン名を、「無料で取り消せる」「期限付きで取り消せる」「返金不可」の3つに束ねます
5. 団体の除外 … 15名以上の団体の予約は外し、担当者の判断に残します
6. 列の型 … 予約経路・プラン・客室タイプ・決済の方法をカテゴリの型にします
7. 重複の確認 … 同じ予約がOTAと自社の両方で取り込まれていないかを、予約番号の対応表で確かめます

1番目を省くと、モデルは未来を見て学びます。 いまの一覧で学ばせると、30日前の時点ではまだ分からなかった「変更が3回あった」が特徴に入り、検証ではよく当たるのに、本番ではまったく当たらないモデルになります。 この構成でいちばん起きやすい失敗です。

5番目で団体を外すのは、取消の決まりが違うからです。 宿泊約款の取消料の表は、個人と、15名から99名、100名以上の団体に分かれています。団体の一部の取消には、取消料のかからない人数の枠も書かれています。 個人と同じモデルに入れると、団体の1件で客室タイプの見込みが大きく振れます。

AIに処理させる

させるのは、予約1件ごとに「直前に取り消されるか、来ないか」の確率を出すことだけです。 枠の計算と上限の規則は、確率を受け取った後の Python の側で行います。

確率は較正してから使います。 足し上げて室数にするので、「0.2と出た予約のうち、実際に2割が空いた」という意味の確率でなければ、足した数がずれます。 較正には CalibratedClassifierCV を使い、公式の説明では、十分なデータ（約1,000件超）があれば isotonic は sigmoid と同等以上とされています。客室タイプ別に見ると件数の少ないタイプがあるため、最初は sigmoid にします。

足し上げは、確率の平均ではなく分布で行います。 予約1件ごとに「空く・空かない」の2通りがあり、確率がそれぞれ違うので、空く室数が0室、1室、2室……になる確率を順に計算します。 売り越しを k 室にしたとき、空く室数が k 室より少なければあふれます。k を1室ずつ増やし、あふれる確率が上限を超える手前で止めた k が案です。

空く室数の分布 dist[0..n] を 1件ずつ畳み込む
  dist = [1.0]
  for p in 予約ごとの確率:
      dist = [dist[i]*(1-p) + dist[i-1]*p for i in 0..len(dist)]
売り越し k 室のとき あふれる確率 = dist[0] + dist[1] + ... + dist[k-1]
案 = あふれる確率 ≦ 上限 を満たす最大の k（上限の規則で頭を押さえる）

2行目がいちばん大事です。 「この予約は来ない確率が高いから先に取り消す」という使い方は、宿泊約款の決まりと合いません。確率は、宿泊日ごとの空き室数を見込むための部品です。

指示内容を固定する

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

【見込む先】
target: 見直しの時点から宿泊日までの取消、または連絡の無い不泊（=1）
見直しの時点: 宿泊日の30日前・7日前・2日前
学習期間: 前月までの24か月  検証: 直近3か月

【対象から外す予約】
- 15名以上の団体、社員・関係者の利用、無料の招待
- 見直しの時点ですでに取り消されている予約

【読まない列（書き出しの段階で除く）】
- 氏名、連絡先、住所、国籍、生年月日
- 予約の備考欄の自由記述

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

【枠の計算】
あふれる確率の上限: 5％（経営会議で決めた値）
客室タイプごとの売り越しの最大: シングル6室、ダブル4室、ツイン3室、その他1室
売り越さない日: 暦の表で「売り越し不可」とした日
近隣の振替先の空きが無いと担当者が登録した日: 案を0室にする

【一覧に載せる内容】
- 宿泊日、客室タイプ、予約室数、販売できる室数、案の売り越し室数
- 空く室数の見込み（中央の値と、90％の範囲）
- プランの内訳（無料取消・期限付き・返金不可の室数）、経路の内訳
- 前回の見直しの案と、担当者が決めた室数

あふれる確率の上限を設定ファイルに書くのが大事です。 この数字はモデルが決めるものではなく、振替の手間と空室の損を比べて、経営が決める値です。 担当者の手元で変えられないようにし、変えたときは日付と理由を残します。

「近隣の振替先の空きが無い日は0室」を入れているのは、あふれたときの手当てが前提だからです。 宿泊約款では、契約した客室を提供できないときは、宿泊客の了解を得て同じ条件の宿泊施設をあっせんするとされています。振替先が無い日に売り越すと、その手当てができません。

出力形式を固定する

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

{
  "run_at": "2026-10-14T05:00:00+09:00",
  "stay_date": "2026-11-13",
  "checkpoint": "d-30 | d-7 | d-2",
  "room_type": "single",
  "booked_rooms": 0,
  "sellable_rooms": 0,
  "expected_vacancy": { "median": 0, "p05": 0, "p95": 0 },
  "plan_mix": { "free_cancel": 0, "deadline_cancel": 0, "non_refundable": 0 },
  "channel_mix": { "ota": 0, "direct": 0, "agent": 0, "corporate": 0 },
  "overbook_proposal": 0,
  "walk_probability_at_proposal": 0.0,
  "capped_by": "none | room_type_max | no_oversell_day | no_walk_option",
  "model_version": "",
  "decided_rooms": null,
  "decided_by": ""
}

1つ目の理由は、案と決定を同じ行に残せることです。 overbook_proposal は計算が埋め、decided_rooms は担当者が埋めます。宿泊日が過ぎた後、案どおりにしていたらどうなったか、担当者の判断でどうなったかを、同じ行で比べられます。

2つ目は、capped_by で案が小さくなった理由が分かることです。 確率の計算では5室売り越せるのに、客室タイプの最大で3室に押さえられた、という場合に、担当者は計算の結果と規則の結果を分けて読めます。

expected_vacancy の幅を出すのは、平均だけを見せないためです。 中央の値が6室でも、5％の側が2室なら、6室売り越した日は高い確率であふれます。幅を見れば、案がなぜ6室ではなく3室なのかが分かります。

システムへ連携する

PMSへは書き込みません。 予約の確率をPMSの予約画面に出すと、フロントや予約課がそれを見て宿泊客の扱いを変えるおそれがあります。 一覧は営業部の共有フォルダにだけ置き、見られる人をレベニューマネージャーと予約課に限ります。

担当者が決めた室数は、一覧の decided_rooms の列に手で入れてもらいます。 サイトコントローラーで調整した数と同じ数を入れるだけです。この1列が、翌月の振り返りの材料になります。

人が確認する

人が見るのは、毎朝の3日分の一覧です。 1日あたり3宿泊日 × 6客室タイプ = 18行で、そのうち案が前回と変わった行と、capped_by が付いた行を先に見ます。

1. 前回から案が変わった行を見る … plan_mix と channel_mix の変化で、理由が説明できるかを確かめます
2. 暦の表の漏れを確かめる … 一覧の宿泊日に、表に載っていない催しや工事が無いかを思い出します
3. 振替先の空きを確かめる … 2日前の見直しでは、近隣のホテルの空き具合を見て、振替先が無ければ0室にします
4. 室数を決めて記録する … 案と違う室数にしたら、decided_rooms と短い理由を残します

3番目を省かないでください。 案はあふれる確率を5％に収めた数字ですが、5％はゼロではありません。 あふれた日に振替先が無ければ、宿泊約款の手当てができません。

目標は、1件あたりならして2分です。 前回と案が変わらず、規則で押さえられてもいない行は数秒で終わります。案が大きく変わった行と、2日前の行だけに時間を使います。

例外に対処する

2行目を「空かない」側に倒しているのは、誤りの向きを決めるためです。 分からない予約を「空く」側に数えると、案が大きくなり、あふれる側に外れます。外れるなら、空室が残る側に外れるようにします。

最後の行は、責める材料ではありません。 あふれる確率5％で枠を決めていれば、20回に1回ほどはあふれる日がある設計です。 振り返りで見るのは、その日の予約の中身が普段と違っていたか、暦の表に漏れが無かったかです。

記録を残す

• 毎朝のPMSの書き出しと、見直しの時点に組み立て直した予約の一覧
• 予約ごとの確率と、使ったモデルの版
• 宿泊日・客室タイプごとの案、あふれる確率、capped_by
• 担当者が決めた室数と、案と違うときの理由
• 宿泊日が過ぎた後の、実際の取消・不泊の室数と、振替の有無
• 設定ファイルの変更の履歴（あふれる確率の上限、客室タイプの最大）

4つ目と5つ目を並べて残すのが、この構成の振り返りの土台です。 案どおりなら何室あふれ、何室空いたか。担当者の判断ではどうだったか。3か月分たまると、案が小さすぎる客室タイプと大きすぎる客室タイプが分かります。

予約ごとの確率は、営業部の外に出しません。 保存の期間を決め、期間を過ぎたら宿泊日・客室タイプごとの集計だけを残して消します。