ホテルの予約ごとに当日の取消と不泊のおそれを見込み、売り止めの判断と確認の連絡の優先順を出す

処理の起点を決める

毎日15時の定時実行を起点にします。 翌日到着の予約の売り止めを決めるには、夕方の予約が動く時間帯の前に材料がそろっている必要があります。同じ処理を翌々日の到着分にも回し、2日前から見込みが動いていくのを見られるようにします。

満室に近い日だけ、21時にもう一度回します。 15時から21時のあいだに直前の予約と取消が入り、見込みが変わるからです。回すたびに結果を上書きせず、時刻付きで残します。 15時と21時で見込みがどう動いたかが、売り止めの判断に効きます。

入力データを集める

質を決めるのは、2行目の「結果」の記録です。 過去の予約が、宿泊したのか、当日に取り消したのか、連絡なく来なかったのかが分からなければ、学ぶものがありません。事前取消（前日までの取消）は、当日の見込みの対象から外します。 すでに部屋が戻っているからです。

3行目の鍵は、ハッシュ化して持ちます。 結び付けに使うのは「同じ人かどうか」だけで、氏名や電話番号そのものはモデルに要りません。

国籍、性別、年齢は特徴量に使いません。 来ないおそれと統計的に関係が出たとしても、属性で予約者を扱い分けることになり、連絡の順番に偏りが出ます。 予約の行動（経路、決済、日数、変更）だけで組みます。

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

予約管理システムから、到着日が翌日と翌々日の予約と、過去の予約の結果をCSVで書き出し、Python で読み込みます。書き出しは予約管理システムの定時出力の機能か、API の提供があればそれを使います。

学習用のデータは「到着の前日15時の時点で分かっていたこと」だけで作ります。 過去の予約の記録には、到着日の夜の取消や、チェックインの記録まで入っています。それを特徴量に混ぜると、学習では高い成績が出て、本番では当たらないモデルになります。 予約日時と変更の日時を見て、前日15時より後の情報を落とす処理を必ず入れます。

AIへ渡す前に整形する

1. 同じ人の結び付け … 会員番号があれば会員番号で、無ければハッシュ化したメールアドレスで結び付けます。どちらも無い予約は「初めての人」として扱い、過去の回数は欠けた値にします
2. 過去の回数の数え方 … 過去の取消と不泊は、その予約の予約日時より前に到着日が来た予約だけで数えます
3. 予約からの日数 … 予約日時から到着日までの日数を出します。当日予約は0です
4. 欠けた値の扱い … 到着時刻の入力が無い、人数の内訳が無いなどは、0で埋めずに NaN のまま渡します
5. 区分の値の型 … 経路、館、部屋タイプ、プランの区分は、データフレームで Categorical 型にします
6. 対象外の除外 … 団体の手配、社員の利用、事前取消の済んだ予約は外します
7. 目的の値の定義 … 「当日取消」と「不泊」をまとめて来なかった（1）、宿泊を来た（0）とします

7番目で当日取消と不泊をまとめるのは、売り止めの判断にとってはどちらも「部屋が空く」からです。 ただし記録には区別して残し、確認の連絡で取消の申し出を受けた件数を後から数えられるようにします。

AIに処理させる

この構成の「AI」は3つの部品に分かれます。 確率を出すのは勾配ブースティングのモデル、確率を実績に合わせるのが較正、連絡文を作るのが生成AIです。生成AIは確率も売り止めの数も作りません。

較正の方法は、まず method="sigmoid" で始めます。 ドキュメントでは、sigmoid は少ないサンプルで効きやすく、isotonic はより一般的な歪みを直せるものの、およそ1,000件を超える十分なデータが無いと過学習しやすいとされています。館ごと・部屋タイプごとに細かく分けると件数が足りなくなるので、3館をまとめて1つのモデルにし、館は区分の特徴量として入れます。 1年分がたまったら isotonic と比べます。

較正には、学習に使っていないデータを使います。 ドキュメントでは、較正の器は分類器の学習に使ったデータとは独立したデータで作るのが理想とされています。CalibratedClassifierCV は交差検証で分けて作るため、分け方には TimeSeriesSplit を渡します。 ドキュメントでは、時間順のデータにほかの分け方を使うと、未来のデータで学習して過去を評価することになるため不適切とされています。

class_weight='balanced' は使いません。 来ない予約は少数なので重みを付けたくなりますが、重みを付けると確率が実際より高く出て、合計が膨らみます。 この構成で欲しいのは順番だけでなく確率そのものなので、重みは付けず、較正で合わせます。

合計の幅は、確率から出します。 来ないおそれ p の予約が n 件あれば、来ない数の平均は p の合計、ばらつきは p×(1−p) の合計から求まります（予約どうしが独立と置いた場合）。ただし、同じ団体の手配や同じ会社の出張がまとめて取り消されることがあり、独立ではありません。 幅は「少なく見積もった幅」として表示し、支配人の上限で守ります。

指示内容を固定する

モデルの設定は次のとおりです。 学習と較正は月1回、予測は毎日15時と21時に回します。

from sklearn.ensemble import HistGradientBoostingClassifier
from sklearn.calibration import CalibratedClassifierCV
from sklearn.model_selection import TimeSeriesSplit

# X は前日15時の時点の特徴量（到着日の順に並べる）、y は来なかった=1
base = HistGradientBoostingClassifier(
    categorical_features="from_dtype",   # 経路・館・部屋タイプ・プランは Categorical 型
    max_iter=300,
    learning_rate=0.05,
    # class_weight は付けない（確率を合計に使うため）
)
model = CalibratedClassifierCV(
    base,
    method="sigmoid",                     # 件数が十分にたまったら isotonic と比べる
    cv=TimeSeriesSplit(n_splits=5, gap=7) # 学習の末尾7件を空けて評価に漏らさない
)
model.fit(X_train, y_train)
p = model.predict_proba(X_today)[:, 1]   # 予約ごとの来ないおそれ

gap を入れるのは、同じ日の予約どうしが似た動きをするからです。 ドキュメントでは、gap は学習用の末尾から評価用の前までに除くサンプルの数とされています。到着日の順に並べたとき、学習の最後と評価の最初が同じ日の予約になると、同じ日の天候やイベントの影響が両方に入り、成績が良く見えます。 実際には日の単位で空けるよう、件数を調整します。

連絡文の下書きは、Claude API に次の指示で作らせます。

あなたはホテルのフロントで、到着前日に予約者へ到着時刻を確かめる連絡文を書く立場です。
渡された予約の情報だけを使って、メールの本文と、電話で話す要点を作ってください。

【渡す情報】
- 館の名前、到着日、泊数、部屋タイプ、プラン名
- 到着時刻の入力の有無（ある場合はその時刻）
- 事前決済の有無
- 館のチェックインの時刻と、当日の連絡先
- 取消の規定の文面（館が定めたものをそのまま）

【書き方】
- 1行目は、到着日と館の名前を書いた、到着のお礼とご案内の書き出しにしてください。
- 到着時刻の入力が無い場合は、到着の予定時刻を教えてほしいとお願いしてください。
- 到着時刻の入力がある場合は、その時刻で変わりがないかを確かめてください。
- 予定が変わった場合の連絡先を書いてください。
- 取消の規定は、渡された文面をそのまま末尾に添えてください。
- 電話の要点は3行以内にしてください。

【厳守事項】
- 宛名は書かないでください。「{宛名}」とだけ書いてください。
- 来ないおそれ、確率、順位、過去の取消や不泊のことを書かないでください。
- 取消を勧める、取消料を強調する表現を使わないでください。
- 渡された情報に無いサービスや特典を書かないでください。
- 料金、プランの内容を書き換えないでください。
- 取消の規定を要約・言い換えしないでください。
- 渡された情報が足りない場合は、文面を作らず missing に足りない項目を書いてください。

【予約の情報】{reservation}
【館の情報】{property}
【取消の規定】{cancel_policy}

「過去の取消や不泊のことを書かない」を明記するのは、渡していなくても書くことがあるからです。 指示に「来ないおそれの高い予約への連絡」と目的を書くと、生成AIは丁寧に「前回のご予約ではお越しいただけなかったため」と書き添えることがあります。目的を指示に書かず、到着時刻を確かめる連絡とだけ伝えます。

出力形式を固定する

次の形のJSONを、予約ごとと日ごとの2種類で作ります。 予約ごとの p_noshow と順位は Python が埋め、contact_draft を Claude API の構造化出力（output_config.format に type: "json_schema"）で受け取ります。

{
  "reservation_id": "R-2026-1008-03321",
  "property": "B館",
  "arrival_date": "2026-10-08",
  "room_type": "シングル",
  "channel": "OTA-2",
  "prepaid": false,
  "lead_days": 1,
  "p_noshow": 0.31,
  "contact_rank": 4,
  "model_version": "2026-10-01",
  "run_at": "2026-10-07T15:00",
  "contact_draft": { "email_body": "", "phone_points": [], "missing": [] },
  "contact_result": { "status": null, "by": "", "at": "" },
  "outcome": null
}

{
  "property": "B館",
  "arrival_date": "2026-10-08",
  "room_type": "シングル",
  "rooms_total": 180,
  "rooms_booked": 178,
  "expected_noshow": 6.4,
  "range_low": 2.6,
  "range_high": 10.2,
  "manager_cap": 3,
  "suggestion": "上限3室の範囲で販売継続を検討",
  "decision": { "action": null, "by": "", "at": "" }
}

1つ目の理由は、予測と人の判断と結果を1行に並べられることです。 p_noshow を出した時点の値、contact_result に連絡の結果、outcome に実際の結果が入るので、後から「0.3と出た予約が本当に3割来なかったか」を数えられます。

2つ目は、manager_cap を出力に含めることです。 提案の文言は上限の範囲でしか作らず、上限が0の日は「販売継続」の提案を出しません。 上限そのものが記録に残るので、後から判断の前提を読み直せます。

システムへ連携する

予約サイトとの在庫の連携には、つなぎません。 売り止めを自動で入れると、確率の外れがそのまま販売の停止や継続になります。この構成の出力は、人が売り止めを決めるための表までです。

人が確認する

売り止めの判断は、予約担当と支配人が必ず行います。

1. 日別の表を見る … 残室、来ない見込みの室数と幅、支配人の上限を並べて見ます
2. 表に無い事情を足す … 団体の到着の遅れ、近隣のイベントの中止、振替先の手当てなどを加えます
3. 売り止めるか、上限の範囲で販売を続けるかを決める … 決めたことを decision に記録します
4. 連絡の一覧の上から連絡する … フロントの予約係が、下書きを直して送るか電話します
5. 結果を記録する … 到着時刻の確認、取消の申し出、不通のいずれかを残します

5番目で「不通」を記録することを省かないでください。 連絡がつかなかった予約は、来ないおそれがさらに高い可能性があり、21時の見直しの材料になります。 ただし、この値はモデルの特徴量には入れません。連絡したかどうかは順位で決まっているので、入れると順位が自分を強める形になります。

目標は、1,500件をならして1件1分です。 上位の予約は連絡と記録で数分かかり、下位の予約は一覧で流し見るだけで済みます。

例外に対処する

3行目の新しい経路は、確率が当てにならない典型です。 モデルは学習したことのない区分について、ほかの区分から推し量った数字を出します。その数字を合計に入れると、日別の見込みが根拠なく動きます。 別枠にして、件数だけを並べて見せます。

記録を残す

• 15時と21時の予約の書き出しと、そこから作った特徴量
• 予約ごとの p_noshow、順位、model_version、run_at
• 日別の見込み、幅、支配人の上限、人の判断（売り止めたか、何室販売を続けたか）
• 連絡の結果（到着時刻の確認、取消の申し出、不通）と、連絡した人と時刻
• 実際の結果（宿泊／当日取消／不泊）
• 較正の確認の記録 … 月ごとに、確率の帯ごとの実際に来なかった割合

3つ目で「人の判断」を残すのは、見込みの当たり外れと判断の良し悪しを分けて見るためです。 見込みが当たっていても、販売を続けなかった日は空室が出ます。

最後の行がいちばん大事です。 ドキュメントには、予測の確率を横軸、実際に陽性だった割合を縦軸にとる較正の曲線（calibration_curve）があります。0.3の帯で実際に3割前後が来ていなければ、合計の数字を信用してはいけません。 毎月この表を見てから、翌月も数字を使うかを決めます。