宿泊プランの予約の入り方と過去の実績から、翌月の日別・部屋タイプ別の料金調整の案を出す

処理の起点を決める

起点は3つあります。毎晩の予約データの記録、週1回の見直し、月次の決定です。

1つ目の毎晩の記録が、この構成でいちばん大事です。宿泊の管理システムから予約データを書き出し、その日の時点で、どの宿泊日に何室の予約があったかを残します。 これを続けることで、「残り30日の時点で何室入っていたか」を後から正確に引けるようになります。過去の分は、予約の作成日とキャンセル日から組み立て直します（データの取得方法で後述）。

2つ目の週1回の見直しは、毎週月曜の朝に動かします。翌月と今月の残りの宿泊日について見込みと案を出し、前週から案が変わった日だけを一覧の上に出します。

3つ目の月次の決定は、毎月20日の朝に動かします。翌月の全宿泊日の案を出し、責任者が翌月分の段階を決める資料にします。

スクリプトは、社内のサーバーで決まった時刻に動かします。動いた時刻、読んだデータの日付、使ったモデルの版を、必ず記録に残します。 前夜の書き出しが失敗していたのに気づかず、古いデータで案を出すことを防ぐためです。

入力データを集める

質を決めるのは、予約の作成日とキャンセル日です。 この2つがあれば、過去のどの日の時点でも「その日に何室入っていたか」を組み立て直せます。どちらかが書き出せない場合、過去の分の学習ができず、毎晩の記録を1年以上ためてから始めることになります。

催しの一覧は、人が入力するしかありません。 祝日はCSVで取れますが、近くの花火大会や音楽の催しは施設の側で拾うしかありません。この一覧が抜けると、モデルは「前年のその日だけ急に埋まった理由」を知らないまま学びます。

料金の段階の履歴も入力に入れます。 過去に段階を上げた日は、予約の入り方が遅くなっているはずです。段階の影響を知らずに学ぶと、「上げた日は入りが遅い」を「その日は人気がない」と読み違えます。

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

過去の分は、予約データから「各時点の予約室数」を組み立て直します。

見込む対象は「最終的な販売室数」ではなく「ここから増える室数」です。 今すでに入っている予約は分かっている数なので、分からない部分だけを見込みます。 最終的な販売室数は、今の予約室数に見込みを足して出します。

組み立ては pandas の groupby で行います。 予約1件を「作成日からキャンセル日まで」の期間として展開し、宿泊日・部屋タイプ・記録の日の組で室数を数えます。連泊の予約は、泊数の分だけ宿泊日ごとに分けてから数えます。 分けないと、2泊目の宿泊日の予約が数えられません。

毎晩の記録が1年分たまったら、組み立て直した値と記録の値を突き合わせます。 差が出る場合は、キャンセル日の付け方や、部屋タイプの変更の扱いが書き出しに反映されていないことが多いです。差の原因が分かるまでは、組み立て直した過去の分を学習に使いません。

AIへ渡す前に整形する

1. 団体の予約を分ける … 団体の仮押さえは、まとめて入ってまとめて消えます。個人の予約とは別に数え、見込みの対象は個人の予約だけにします
2. 販売できる室数で上限を付ける … 改装や故障で止めた部屋を除いた室数を、見込みの上限にします
3. 特殊な期間の印 … 災害、感染症の流行、大規模な改装など、予約の入り方が普通でなかった期間に印を付け、学習から外すかを決めます
4. 前年の比べる日を決める … 曜日を合わせ、連休の並びが違う日は、祝日のCSVから連休の何日目かを計算して合わせます
5. 催しの一覧を結合する … 宿泊日ごとに、催しの有無と規模の目安を列として足します
6. 料金の段階を列にする … その時点で売っていた段階を、学習の特徴として足します
7. 欠けの確認 … 前夜の書き出しが無い、件数が前日より極端に少ない場合は、処理を止めて担当者へ知らせます

1番目を軽く見ないでください。 団体の仮押さえが30室入って2週間後に消えると、個人の予約の入り方として学べば、その日の見込みが大きく外れます。 団体の分は営業の担当者が別に把握しているので、見込みの一覧では別の列として並べます。

7番目は、古いデータで案を出さないための止め具です。 書き出しが止まったまま見込みを出すと、予約が入っていないように見え、下げる案が並びます。

AIに処理させる

させることは2つです。scikit-learn のモデルに「宿泊日までに増える室数」を見込ませることと、Claude API に案ごとの理由の文を書かせることです。

1つ目の見込みで使う特徴：

出すのは、0.1、0.5、0.9の3つの分位点です。 真ん中の見込みに加えて、「これより少ないことは1割くらいしかない」下側と、「これより多いことは1割くらいしかない」上側を出します。上側と下側の差が「幅」です。

2つ目の理由の文で書かせること： スクリプトが出した数字（今の予約室数、前年の同じ時点との差、見込みの幅、規則表のどの行に当たったか）から、責任者が一目で読める2〜3文を書かせます。

2行目がいちばん起きやすい失敗です。 「見込みは約90室」と丸めた文が一覧に並ぶと、表の数字と文の数字が食い違い、どちらを信じるかで会議が止まります。 数字は表の側だけに置きます。

規則表の例：

いちばん下の行が、この構成の要です。 幅が広い日は、規則で自動的に案を出さず、「人が判断」として一覧の上に出します。モデルが自信を持てない日を、人が見る日にします。

指示内容を固定する

見込みのモデルの設定（Python のスクリプトの中の指示）：

目的の値：宿泊日までに増える個人の予約の室数（最終的な販売室数 － 今の予約室数）
モデル：HistGradientBoostingRegressor(loss="quantile", quantile=q) を q = 0.1, 0.5, 0.9 で3つ
区分の値として扱う列：曜日、月、連休の何日目か、今の料金の段階
学習に使う期間：直近3年。ただし特殊な期間の印が付いた宿泊日は除く
検証：直近の6か月を学習から外し、その期間で見込みと実績の差を測る
採用の条件：真ん中の見込みの誤差が、「前年の同じ時点からの増え方をそのまま足す」
          単純な方法より小さいこと。小さくなければ単純な方法を使う
後処理：最終的な販売室数 ＝ 今の予約室数 ＋ 見込み。販売できる室数を上限に切る
        下側 ＞ 真ん中、真ん中 ＞ 上側 になったら並べ直す

「単純な方法より小さいこと」を採用の条件に入れているのが要です。 前年の同じ時点からの増え方をそのまま足す方法は、責任者が頭の中でしていることに近い考え方です。モデルがそれより当たらないなら、モデルを使う意味がありません。 比べる相手を決めておかないと、当たっているかどうかを誰も言えません。

理由の文の指示（Claude API）：

あなたはホテルの営業部で、料金の段階の案に理由を添える担当です。
下のデータだけを使って、責任者が読む理由の文を2〜3文で書いてください。

【厳守事項】
- 数字は、データに書かれた数字をそのまま使ってください。
  丸める、足す、割るなどの計算をしないでください。新しい数字を書かないでください。
- 案（raise / hold / lower / human）を覆さないでください。
  案が raise なら、上げる理由を書いてください。
- データに無い理由（人気、口コミ、競合の料金、天気など）を書かないでください。
- 案が human のときは、幅が広い理由（前年のデータが無い、催しがある、など）を
  データの中から1つ選んで書き、「判断をお願いします」で終えてください。
- 料金の金額を書かないでください。

【データ】
宿泊日：{stay_date}（{weekday}、{holiday_note}）
部屋タイプ：{room_type}　販売できる室数：{capacity}
今の予約室数：{otb}　前年の同じ時点：{otb_last_year}（差 {otb_diff}）
見込み（下側／真ん中／上側）：{p10}／{p50}／{p90}　幅：{width_label}
当たった規則表の行：{rule_row}　案：{proposal}
催し：{event_note}

「案を覆さない」を明記しないと、文の側で判断が変わります。 生成AIは慎重な言い方を好むので、上げる案に「ただし様子を見るのが無難です」と書き添えがちです。文が案と違うことを言えば、責任者はどちらを読めばよいか分からなくなります。

出力形式を固定する

Claude API の構造化出力で、スキーマに沿ったJSONを受け取ります。 出力の形式にJSONスキーマを指定すると、制約付きのデコードでスキーマに沿った応答が返ります。オブジェクトには additionalProperties: false を付ける必要があります。

{
  "stay_date": "YYYY-MM-DD",
  "room_type": "",
  "proposal": "raise | hold | lower | human",
  "reason_text": "",
  "reason_tags": ["pace_ahead", "holiday_eve", "event", "no_history", "wide_range"]
}

スクリプトの出力と合わせて、一覧は次の列にします。

1つ目の理由は、数字と文を別の列に分けられることです。 数字はスクリプトの列だけにあり、文は reason_text にだけあります。文の中の数字と表の数字が食い違っていないかは、スクリプトの側で機械的に確かめます。 文に表に無い数字が出ていたら、その行の文を空にして人に回します。

2つ目は、reason_tags で一覧を絞り込めることです。 責任者は「催し」や「前年のデータなし」の日だけを先に見るといった使い方ができます。proposal を human とした日を一覧の最上段に並べます。

システムへ連携する

宿泊の管理システムと予約サイトとの連動の仕組みへは、書き込みません。 この構成が出すのは案の一覧までで、売り値を変えるのは人の操作です。

Claude API に渡すのは、1行分の集計した数字だけです。 予約1件ごとのデータ、客の氏名、販売経路ごとの手数料は渡しません。理由の文を書くのに要るのは、第7章のプロンプトの【データ】の欄にある項目だけです。

人が確認する

人が確かめるのは2か所です。データの確認と、案の決定です。

1. 担当者がデータを確かめる … 前夜の書き出しの日付、件数の急な増減、催しの一覧の入力漏れを見ます。ここで止めれば、誤った見込みが責任者に届きません
2. 責任者が human の日を先に見る … 幅が広い日、前年のデータが無い日、催しのある日。ここに時間を使います
3. 責任者が前週から案が変わった日を見る … 週の見直しでは、変わった日だけを見れば足ります
4. 責任者が規則どおりの日を流し見る … 幅が狭く規則どおりの案は、採るか直すかを一覧の上で決めます
5. 案を直したら理由を記録する … どの日の案を、どう直したか、なぜか

5番目の記録が、規則表を育てます。 責任者が同じ理由で繰り返し案を直しているなら、それは規則表に書かれていない判断です。 3か月分の記録を見て、規則表に行を足します。責任者の頭の中にあった判断が、表の側に移っていきます。 第3章の（a）は、ここで解けます。

例外に対処する

1行目と7行目が、この構成を信用できるものにします。 1行目は入口の止め具、7行目は出口の止め具です。モデルが当たらなくなったことに気づける仕組みが無いと、外れた案が毎週並び続けます。

記録を残す

• 毎晩の予約データの書き出しと、日ごとの予約の状態の記録
• 学習に使った期間、特殊な期間の印、学習済みのモデルの版
• 案を出すたびの、見込み（3つの分位点）、規則表の行、案、理由の文
• 責任者が採った段階と、案と違ったときの理由
• 宿泊日を過ぎた後の、最終的な販売室数の実績
• 見込みと実績の差と、単純な方法の差の月ごとの比較

4つ目と5つ目を並べると、案の良し悪しが後から測れます。 案を採った日と直した日で、最終的な販売室数がどうだったか。「直した日のほうが良かった」が続く規則は、規則表の側を直します。

最後の行を、毎月の会議で見ます。 見込みの誤差が単純な方法より小さい状態が続いているかどうか。続いていなければ、モデルを使う理由がなくなっています。