ホテルの予約・チェックアウト予定・連泊の数から、翌週の客室清掃に必要な人数を日ごとに予測してシフトの案に渡す

処理の起点を決める

毎週水曜の朝6時に動かします。 シフトの確定が木曜なので、リーダーが水曜の日中に印の付いた日を確かめ、夕方までに人事部へ渡せる時刻にします。前日の夜の予約まで入った状態で書き出すため、夜間の締めの処理が終わった後にします。

見込む先は、翌週の月曜から2週先の日曜までの14日分です。 確定するのは翌週の7日分ですが、2週先の分を出しておくと、催しで人が多く要る週に、早めに勤務の希望を集め始められます。

月曜にも同じ処理をもう一度動かし、その週の見込みを出し直します。 確定したシフトとの差が大きい日だけを人事部に知らせ、追加で呼ぶ人を探す材料にします。

入力データを集める

質を決めるのは、予約の記録の「予約した日」と「取り消した日」です。 この2つが無いと、「8日前の時点で何室入っていて、最終的に何室になったか」が作れず、 これから動く分を学ばせることができません。宿泊管理システムの書き出しに、この2つの列が含まれるかを最初に確かめます。

清掃の時間の表は、リーダーが実際に測って作ります。 部屋の種類ごとに、チェックアウトの清掃と連泊の清掃を数回ずつ測り、平均を置きます。ここが実態とずれていると、室数の見込みが当たっても人数が外れます。

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

宿泊管理システムの帳票の機能で、予約の記録を表の形で書き出します。宿泊管理システムによって、書き出しの方法と列の名前が違います。 API を持つものなら定時に取りに行き、持たないものは帳票を定時に書き出す設定にして、共有フォルダに置かれたファイルを読みます。

過去の分は、取消も含めて取ります。 取消された予約を除いて書き出すと、「8日前には入っていたが、後で取り消された」という動きが消え、 取消の多い日を少なめに見込みます。

AIへ渡す前に整形する

1. 予約を日ごとに展開する … 到着日から出発日の前日までを1泊ずつに分け、出発日を「チェックアウトの日」にします。連泊の2日目以降の泊まりを「連泊の清掃」にします
2. 清掃を断る連泊を分ける … プランの一覧で、連泊の清掃をしない予約を数えから外します。ただし、何泊かに1回は清掃に入る決まりのプランは、その日だけ数えに戻します
3. ある時点での室数を作る … 過去の各日について、「到着の14日前の時点で、取り消されずに入っていた室数」「13日前の時点で…」と、日数前ごとの数を作ります
4. 学ばせる組を作る … 「何日前か」「その時点の室数」「曜日」「ホテル」「祝日・連休」「催しの有無と規模」「前年の同じ曜日の最終の室数」を特徴に、最終の室数からその時点の室数を引いた値（これから動く分）を答えにします
5. 異常な日を外す … 休館した日、大きな団体の貸し切り、宿泊管理システムの入れ替えの前後は、学ばせる組から外します
6. 検証の分け方を決める … 時系列を崩さないよう TimeSeriesSplit で、過去で学んで後の期間で確かめる組を作ります

4番目で、最終の室数そのものを答えにしないでください。 これから動く分を答えにすると、いま入っている室数がそのまま土台になり、 モデルが外れても大きくは崩れません。

1番目で、予定より早い出発と延泊を答えに入れておきます。 予約の記録の出発日は、最後に更新された値です。客が1泊早く発った日は、チェックアウトの清掃が前の日に移ります。 答えには客室係の作業表の実際の清掃室数を使い、予約から数えた最終の室数との差を別の列に残します。この差が大きいホテルは、早い出発の多い客層だということで、その割合も特徴の列に足します。

6番目で gap を使います。 TimeSeriesSplit の gap は、学ばせる期間の終わりと確かめる期間の間に空ける数です。同じ到着日の別の時点の組が両側に入ると、答えが漏れて当たりすぎます。 少なくとも14日分を空けます。

AIに処理させる

させるのは、ホテル・日・清掃の種類ごとに、これから動く室数を真ん中と多めの2本で見込むことだけです。 人数への換算と印付けは、決まった計算で行います。

右端の列が、人が見る日を決めます。 low_history は、開業したばかりのホテルや、過去に例の無い大きな催しの日です。モデルの見込みを信じる根拠が薄い日だけを、リーダーに回します。

3行目がいちばん起きやすい失敗です。 月曜の見込みの出し直しで人数が減ったからといって、確定したシフトを自動で減らすと、働くつもりで予定を空けていた人の勤務が前日に消えます。 出し直しの結果は、人事部への知らせにとどめます。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、モデルの設定と換算の規則を書いておきます。

【モデル】
- HistGradientBoostingRegressor(loss="quantile", quantile=0.5)  真ん中
- HistGradientBoostingRegressor(loss="quantile", quantile=0.8)  多めの側
- categorical_features = ["hotel", "weekday", "room_type"]
- monotonic_cst = {"event_scale": 1}  催しの規模が大きいほど、これから動く分も大きい向き
- 目的変数 = 最終の室数 − その時点の室数（これから動く分）
- 清掃の種類ごと（checkout / stayover_clean）に別のモデル

【換算の規則】
- 見込みの室数 = その時点の室数 + これから動く分（負なら取消が多い）
- 見込みの室数は 0 以上、その日の販売できる室数以下に収める
- 清掃の分数 = Σ 部屋の種類ごとの室数 × 清掃の時間
- 必要な人数 = 清掃の分数 ÷ 1人1日に清掃できる分数（切り上げ）
- 真ん中の人数 = 確定のシフトの目安、多めの人数 − 真ん中の人数 = 呼べたら呼ぶ人

【印を付ける条件】
- low_history：そのホテル・曜日で学ばせた組が 20 未満、または催しの規模が過去の最大を超える
- wide：多めの室数 − 真ん中の室数 が、真ん中の 3 割を超える
- event：催しの予定表に載っている日
- jump：先週の同じ日の見込みから、人数が 2 人以上変わった
- 印の無い日は、リーダーの確認なしで人事部へ渡す

「販売できる室数以下に収める」を書いておかないと、催しの日に満室を超える見込みが出ます。 モデルは室数の上限を知りません。上限は規則の側で決めます。

monotonic_cst の向きは、学ばせる前に記録で確かめます。 大きな催しの日は、早くから予約が埋まって直前に入る分がかえって少ないホテルもあります。向きの制約が実態と逆だと、見込みが一方に偏ります。 制約を付けた場合と付けない場合の両方で、確かめる期間の外れ方を比べてから決めます。

出力形式を固定する

ホテル・日ごとに、次の形のJSONを作り、表にしてシフト作成の仕組みへ渡します。

{
  "hotel": "",
  "date": "",
  "checkout_rooms": { "on_books": 0, "p50": 0, "p80": 0 },
  "stayover_clean_rooms": { "on_books": 0, "p50": 0, "p80": 0 },
  "cleaning_minutes": { "p50": 0, "p80": 0 },
  "staff_needed": { "p50": 0, "p80": 0 },
  "flags": ["low_history | wide | event | jump"],
  "model_version": "",
  "leader_override": { "staff": null, "reason": "" }
}

1つ目の理由は、on_books と p50 を並べて見せられることです。 いま入っている室数と、見込みの室数の差が、そのまま「これから動く分」です。リーダーは、この差が現場の感覚と合うかを見れば足ります。

2つ目は、p50 と p80 を分けて持てることです。 シフト作成の仕組みには staff_needed.p50 を必要人数として渡し、p80 との差を「呼べたら呼ぶ人」の枠として別の列で渡します。 1本の数字にすると、どちらに寄せたかが後から分かりません。

3つ目は、leader_override で直した記録が残ることです。 リーダーが人数を直したら、ここに人数と理由を書きます。シフトに渡るのは直した後の値で、モデルの値も残ります。 どちらが当たったかを、翌週に比べられます。

システムへ連携する

シフト作成の仕組みには、人数の表を渡すだけです。 取り込みは人事部の担当者が行い、取り込んだ後に誰を入れるかは、勤務の希望と労働時間を見て人が決めます。 必要人数の列だけを自動で書き換えるAPIがあっても、確定したシフトに触れる経路は作りません。

モデルの学ばせ直しは、月に一度、別の処理として動かします。 毎週の見込みは、その月に決めた版のモデルで出します。学ばせ直した版は、直近の8週を確かめる期間にして前の版と外れ方を比べ、良くなっていたときだけ切り替えます。 毎週学ばせ直すと、見込みが変わった理由が記録の変化なのかモデルの変化なのか、リーダーにも人事部にも分からなくなります。

人が確認する

人が見るのは、印の付いた日だけです。 印の無い日はそのまま人事部へ渡ります。14日分の全部を開く設計にすると、第10章の10.0時間には収まりません。

1. event と low_history を先に見る … 催しの日と、記録の少ない日です。営業担当に、催しの客がこのホテルに来るかを確かめます
2. wide を確かめる … 見込みの幅が広い日です。真ん中で組み、呼べたら呼ぶ人を多めに確保します
3. jump を確かめる … 先週から人数が大きく変わった日です。団体の予約や大口の取消が入っていないかを、予約の一覧で見ます
4. 直したら理由を書く … leader_override に人数と理由を残します
5. 翌週に、見込みと実際の差を見る … 外れた日の印と理由を読み、次の確認の参考にします

確認の期限は水曜の15時に置きます。 それを過ぎた日は第7章の例外処理のとおり「未確認」として渡し、人事部はシフトを組みながら必要ならリーダーに電話で確かめます。

1番目の催しの日は、モデルより人の知っていることのほうが確かなことがあります。 会場の催しでも、客層によっては近くの別のホテルに流れます。直すことはためらわず、直した理由を必ず残します。

目標は、120件をならして1件5分です。 印が付くのは一部の日という想定で、それより多い週は、催しの予定表が細かすぎるか、学ばせた期間が短すぎます。

例外に対処する

| 新しい部屋の種類やプランを売り始めた | 清掃の時間の表とプランの一覧に足すまで、その室数を low_history で人へ |

| 学ばせ直したモデルの外れ方が前の版より悪い | 新しい版を使わず、前の版で見込みを出す。 版の比較を記録する |

上から2行目が、最初の数か月でいちばん起きます。 宿泊管理システムによっては、取消した予約の「予約した日」が書き出されないことがあります。学ばせる組が作れない期間がどれだけあるかを、最初に数えてください。

記録を残す

• 実行ごとに、書き出した予約の記録のファイル名と書き出し日時
• 学ばせたモデルの版（学ばせた期間、特徴の列、monotonic_cst の有無）
• 確かめる期間での外れ方（mean_pinball_loss を alpha=0.5 と alpha=0.8 で）
• ホテル・日ごとの出力のJSON（on_books、p50、p80、flags）
• リーダーが直した記録（leader_override の人数と理由）
• 日ごとの実際の清掃室数と、見込みとの差

外れ方は mean_pinball_loss で測ります。 分位点の回帰の損失を測る関数で、alpha で見る分位点を決め、alpha=0.5 のときは平均絶対誤差と同じになります。 0.8の側は、多めの見込みを下回った日がどれだけ痛かったかで測ります。真ん中だけを当たり外れで測ると、多めの側が当たっているかが分かりません。

直した記録は、モデルを学ばせ直す材料になります。 同じ催しで毎回同じ方向に直しているなら、催しの規模の列の付け方が実態と合っていません。