温泉旅館が日帰り入浴の記録・曜日・天気・催しから Python で翌週の日ごとの来場を予測し、受付の時間と食事処の仕込みの案を出す
温泉旅館の日帰り入浴の記録と予約、曜日・天気・催しから、Python で翌週の日ごとの予約なしの来場を幅付きで予測します。宿泊客の入浴と重なる時間帯の混み具合から受付を締める時刻の案を出し、昼食の仕込みと人の配置の案も作ります。
- 連携・自動化
- Python
- 対象業界
- その他/宿泊
- 対象部門
- 経営企画
- 対象業務
- 集計・分析
- 主な課題
- 人手が足りない/判断に時間がかかる/属人化している
- AIで行う処理
- 予測
- 主な効果
- 判断支援/属人化解消/機会損失防止
- 導入難易度
- ★★★★☆
- 実装レベル
- 本格構成
- 費用感
- 個別開発(大)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 金曜に、事務が券売機から前年の同じ週と先週の日ごとの日帰り入浴の数を書き出す
- 宿の予約の管理の仕組みから、翌週の日ごとの宿泊のチェックインの数と、日帰りプランの予約の数を書き出す
- 女将が、週間天気予報と近くの催し(祭り、紅葉の見ごろ、道路の通行止め)を見て、日ごとの予約なしの客の多さを見立てる
- 混みそうな日は、受付を締める時刻を早める
- 食事処の料理長に、日ごとの昼食の仕込みの目安を伝える
- 受付と浴場の見回り、貸しタオルの準備の人数をシフトの表に書く
- 当日の朝、天気が予報と違えば、女将が受付の時間と仕込みを直す
- 人事務が、翌週の催し(祭り、紅葉の見ごろ、道路の通行止め、旅行の情報誌の掲載)と、週間天気予報の日ごとの天気・最高気温を予定のシートに入れる
- 自動金曜の朝、Python が券売機の記録、予約の書き出し、予定のシートを読み込む
- 自動学習済みのモデルで、翌週の日ごとの予約なしの来場を、下振れ・中央・上振れの3つで予測する
- 自動過去の時刻の分布から、予約なしの客のうち13時から15時に浴場にいる人数を見積もり、宿泊の早い到着の数と合わせて混み具合の印を付ける
- 自動受付を締める時刻の案、昼食の仕込みの数の案、貸しタオルの数、受付と見回りの人数の案を出す
- 人女将が印の付いた日を中心に見て、受付の時間を決め、ホームページの案内を直す
- 人料理長が仕込みの数の案を見て、仕入と仕込みを決める
- 【自動/人】 前日の朝、天気予報が大きく変わった日だけ予定のシートを直して予測をやり直し、女将が直すかを決める
各工程の詳しい説明を読む
- 金曜に、事務が券売機から前年の同じ週と先週の日ごとの日帰り入浴の数を書き出す
- 宿の予約の管理の仕組みから、翌週の日ごとの宿泊のチェックインの数と、日帰りプランの予約の数を書き出す
- 女将が、週間天気予報と近くの催し(祭り、紅葉の見ごろ、道路の通行止め)を見て、日ごとの予約なしの客の多さを見立てる
- 混みそうな日は、受付を締める時刻を早める
- 食事処の料理長に、日ごとの昼食の仕込みの目安を伝える
- 受付と浴場の見回り、貸しタオルの準備の人数をシフトの表に書く
- 当日の朝、天気が予報と違えば、女将が受付の時間と仕込みを直す
(a)受付を締める時刻が、当日の朝に変わる。 3番の見立てが外れると、7番で直します。ホームページの案内を当日に変えても、すでに向かっている客には届きません。 着いてから「本日は締め切りました」と断る日があり、遠くから来た客の不満になります。逆に、早めに締めると決めた日が雨で空き、受けられたはずの客を断ったことになります。
(b)昼食の仕込みが余る・足りない。 食事処の昼食は、予約のプランの分に、予約なしの客の分を上乗せして仕込みます。上乗せの量は料理長の勘です。 余った分は捨てるしかなく、足りない日は品切れの札を出します。
(c)決め方が女将の頭の中にある。 3番の見立ては、女将が長年の経験で行っています。女将が出張や休みの週は、前年の写しで決まります。 連休の並びが変わった年や、近くで新しい催しが始まった年には、大きく外れます。
(d)宿泊の予約と日帰りの客を並べて見ていない。 宿泊が満室に近い日の14時の浴場と、宿泊が少ない日の14時の浴場は、同じ日帰りの数でも混み方が違います。2つの記録は別の画面にあり、並べて見るのは女将の頭の中です。
- 【人】 事務が、翌週の催し(祭り、紅葉の見ごろ、道路の通行止め、旅行の情報誌の掲載)と、週間天気予報の日ごとの天気・最高気温を予定のシートに入れる
- 【自動】 金曜の朝、Python が券売機の記録、予約の書き出し、予定のシートを読み込む
- 【自動】 学習済みのモデルで、翌週の日ごとの予約なしの来場を、下振れ・中央・上振れの3つで予測する
- 【自動】 過去の時刻の分布から、予約なしの客のうち13時から15時に浴場にいる人数を見積もり、宿泊の早い到着の数と合わせて混み具合の印を付ける
- 【自動】 受付を締める時刻の案、昼食の仕込みの数の案、貸しタオルの数、受付と見回りの人数の案を出す
- 【人】 女将が印の付いた日を中心に見て、受付の時間を決め、ホームページの案内を直す
- 【人】 料理長が仕込みの数の案を見て、仕入と仕込みを決める
- 【自動/人】 前日の朝、天気予報が大きく変わった日だけ予定のシートを直して予測をやり直し、女将が直すかを決める
6番目で決めるのは女将です。 モデルが出すのは締める時刻の案で、宿泊の客層(年配の団体、家族連れ)や、当日の清掃の段取りを知っている女将が決めます。
受付の時間は、前の週のうちにホームページに載せます。 当日に変えると、向かっている客に届かないからです。前日のやり直しで変えるのは、締める時刻を遅らせる(多く受ける)方向だけにし、早める方向の変更は、よほど混む見込みが出た日に限ります。
02今回想定するシステム構成
券売機の記録(券の種類・時刻)+ 食事処のレジ(日帰りの昼食の数) + 予約の書き出し(宿泊のチェックイン・日帰りプラン) + 過去の天気(気象庁の過去の気象データ)+ 祝日(内閣府の CSV) + 翌週の催しと天気予報(事務が入れる予定のシート) │ ▼【トリガー】毎週金曜の朝(事務所のパソコンの定時実行) Python(pandas) ├──▶ 日ごとの予約なしの来場をそろえ、受付を締めた日に印を付ける ▼ scikit-learn(HistGradientBoostingRegressor) │ 翌週の日ごとの予約なしの来場:中央(ポアソン)・下振れと上振れ(分位点) ▼ Python ── 13〜15時の浴場の人数を見積もり、宿泊の早い到着と合わせて印 ▼ Python ── 受付の時間・昼食の仕込み・貸しタオル・人数の案 ▼ 【人】女将が受付の時間を決め、料理長が仕込みを決める
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 実行環境 | Python(pandas・scikit-learn) | R |
| 処理エンジン | scikit-learn の HistGradientBoostingRegressor(ポアソン損失と分位点損失) | LightGBM、Prophet |
| 集計 | Python(浴場の人数の見積もり、受付の時間・仕込み・人数の換算) | スプレッドシートの計算式 |
| 保管 | Google スプレッドシート(予定、換算の規則、決めた受付の時間の記録) | - |
新しく足すのは、Python の処理と、予定のシート、換算の規則の表です。 券売機と予約の管理の仕組みはこれまでどおりで、この構成はホームページの案内もシフトの表も書き換えません。 出すのは日ごとの案です。
予測のエンジンに HistGradientBoostingRegressor を選んだのは、損失を目的に合わせて替えられるからです。 来場の数は0以上の数なので、中央の見込みには loss="poisson"(目的の値が0以上であることが要る)を使い、下振れと上振れには loss="quantile" で分位を指定します。曜日や催しの種類は、pandas の Categorical の列にしておけば、categorical_features の既定の 'from_dtype' でカテゴリとして扱われます。
生成AIは使いません。 予測は数の問題で、女将と料理長に渡すのは日ごとの表です。
03どうやって実装するのか
処理の起点を決める
毎週金曜の朝に1回動かします。 翌週の受付の時間をホームページに載せるのが金曜の午後なので、女将が昼までに案を見て決められる時刻にします。事務所のパソコンの定時実行の仕組み(Windows ならタスク スケジューラ)で Python のスクリプトを起動します。
前日の朝にも、天気予報が大きく変わった日だけ動かします。 事務が予定のシートの翌日の天気を直し、「やり直し」の印を付けたら、その日の分だけ予測と案を作り直します。 毎日すべての日をやり直すと、料理長への連絡が毎日変わります。
月に1回、モデルを作り直します。 毎月の第1金曜に先月までの記録で学習し直し、作り直す前と後で、先月の当たり方を比べた結果を残します。悪くなっていれば、前のモデルのまま使います。
結果の表には作った日時を必ず印字します。 前日のやり直しのあとに古い表で仕込みを決めないためです。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 日帰り入浴 | 券の種類(大人・小人・タオル付き)、発券の時刻、枚数 | 券売機の記録(CSV) |
| 日帰りの昼食 | 日帰りの客の昼食の注文の数と時刻 | 食事処のレジの記録 |
| 予約 | 日ごとの宿泊のチェックインの数と到着の予定の時刻、日帰りプランの予約の数 | 予約の管理の仕組みの書き出し |
| 過去の天気 | 日ごとの降水量・気温など | 気象庁の過去の気象データ・ダウンロード(CSV) |
| 祝日 | 国民の祝日の日付 | 内閣府の祝日の CSV |
| 予定 | 翌週の催し、天気予報の天気と最高気温、道路の通行止め、受付の時間の変更、浴場の工事 | 予定のシート(事務が入れる) |
| 換算の規則 | 浴場の人数と受付を締める時刻、来場と昼食・タオル・人数の対応 | 換算の規則の表(女将と料理長と決める) |
質を決めるのは、予定のシートと、受付を締めた日の記録です。 催しと通行止めは券売機の記録からは分かりません。受付を早めに締めた日は、来場が締めた時刻で頭打ちになっています。 締めた日と時刻を記録していないと、モデルは「この日はこれだけしか来なかった」と覚えます。
券の種類で、小人の券を分けて数えます。 浴場の混み方には大人も子どもも効きますが、昼食の注文の数は大人の数のほうに強く結びつきます。 予測は大人と小人を合わせた来場で行い、昼食の換算に使う比率は過去の大人の比率から出します。
天気は日ごとの値を使います。 気象庁の過去の気象データ・ダウンロードでは、地点と項目と期間を選んで観測値を CSV で落とせるので、旅館の近くの観測地点の日ごとの降水量と気温を取ります。山あいの旅館は、市街地の地点より近くのアメダスの地点を選びます。
データの取得方法を決める
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 日帰り入浴 | 券売機の管理画面から週に1回 CSV を書き出し、決まったフォルダに置く | 日ごとの来場と、時刻の分布 |
| 日帰りの昼食 | 食事処のレジの記録を週に1回書き出す | 来場と昼食の比率 |
| 予約 | 予約の管理の仕組みから、翌週と過去の日ごとの数を書き出す | プランの数と、宿泊の早い到着の数 |
| 過去の天気 | 月に1回、気象庁のページから CSV を落とす | 降水と気温の項目 |
| 祝日 | 年に1回、内閣府の CSV を入れ替える | 祝日の印 |
気象庁の CSV には、値の列のほかに品質情報や均質番号の列が並びます。 値の列だけを名前で選んで読みます。列の位置で読むと、項目を足したときに気温の列に品質情報が入ります。
祝日の CSV は、翌年の分が前の年の2月に載るとされています。年に1回、2月に入れ替えます。
予約の書き出しには、宿泊客の名前と連絡先が含まれます。 読み込むときに、日付と数と到着の予定の時刻以外の列を捨てます。予測に要るのは日ごとの数だけです。
AIへ渡す前に整形する
- 日ごとにそろえる … 営業日ごとに、券売機の発券の数を合わせます。日帰り入浴を休んだ日(浴場の点検、貸切)は、0ではなく行ごと外します
- プランの客を外す … 日帰りプランの客は券売機を通らない作りが多いですが、通る場合は券の種類で外し、予約なしの客だけを学習の対象にします
- 受付を早めに締めた日に印を付ける … 予定のシートの過去の記録から、締めた日と時刻を拾い、印を付けます
- 時刻の分布を作る … 予約なしの客の発券の時刻から、曜日・季節ごとに「13時から15時に浴場にいる割合」を作ります。入浴の時間は、過去の滞在の見当(たとえば1時間半)を女将と決めて置きます
- 項目を作る … 曜日、祝日とその前日、連休の何日目か、月、降水の有無と量、最高気温、催しの種類、道路の通行止め、前年の同じ週の同じ曜日の来場、直近4週の同じ曜日の平均
- 曜日・月・催しを Categorical にする … pandas の Categorical の型にしておけば、既定の設定でカテゴリとして扱われます
3番目が、この構成の肝です。 13時で締めた日の来場は、14時まで受けていればもっと多かったはずです。印を付けずに学習すると、混む日ほど来場が少なく覚えられ、また締める判断を遅らせることになります。 締めた日は、締めた時刻までの来場を、時刻の分布で14時までの分に引き延ばした値を学習に使うか、中央のモデルからは外して上振れのモデルにだけ使います。
宿泊の早い到着の数は、予約の到着の予定の時刻から数えます。 予定の時刻が空の予約も多いので、空のものは、過去の同じ曜日・同じ人数の組の予約で15時前に着いた割合を掛けて見積もります。 団体の予約は到着の時刻がバスの都合で決まっているので、担当が予定のシートに時刻を入れます。
1番目で休んだ日を0にしないのは、0の日を学習すると、雨の日の来場が実際より少なく出るからです。 浴場の点検の日が雨の日に重なっていると、モデルは「雨の日は誰も来ない」と覚えます。
AIに処理させる
させるのは、翌週の日ごとの予約なしの来場を予測することだけです。 機械学習のモデルを3本作ります。
| 出すもの | 損失 | 使いみち |
|---|---|---|
| 中央の見込み | loss="poisson" | 受付と見回りの人数、貸しタオルの数 |
| 下振れの見込み(0.2) | loss="quantile"、quantile=0.2 | 昼食の仕込みの数(捨てる量を抑える) |
| 上振れの見込み(0.8) | loss="quantile"、quantile=0.8 | 受付を締める時刻の案、貸しタオルの予備 |
昼食の仕込みに下振れを使うのは、作った料理は翌日に回せないからです。 足りない分は品切れの札で済みますが、余った分は捨てるしかありません。どの分位を使うかは、料理長と、品切れと廃棄のどちらを重く見るかで決めます。 貸しタオルは足りないと客を待たせるので、上振れで準備します。
受付を締める時刻は、浴場の人数で決めます。 予約なしの客の上振れに、13時から15時に浴場にいる割合を掛け、プランの客と宿泊の早い到着の数を足したものが、その時間帯の浴場の人数の見積もりです。
| 13〜15時の浴場の人数の見積もり | 受付の時間の案 | 表の印 |
|---|---|---|
| 換算の規則の「ゆとり」以下 | 通常(14時まで受付) | - |
| 「ゆとり」を超え「上限」以下 | 通常。見回りを1人増やす | 黄 |
| 「上限」を超える | 13時で受付を締める案 | 赤 |
「ゆとり」と「上限」の人数は、女将と決めます。 洗い場の数と脱衣所のかごの数から目安を出し、過去に宿泊客から「混んでいた」と言われた日の人数を思い出しながら決めます。
| させないこと | 理由 |
|---|---|
| 受付の時間の決定と、ホームページへの掲載 | 宿泊の客層と清掃の段取りを知る女将が決める |
| 源泉と浴槽の衛生の管理の判断 | 換水や清掃の時刻は衛生の決まりで決める |
| 台風・大雪のときの営業の判断 | 安全の判断。予報と現場の様子で決める |
| 初めての催しの効果 | 記録が無い。女将が上乗せする |
| 天気予報そのもの | 事務が予報を見て入れる |
2行目は、とくに気を付けてください。 来場が多い見込みの日でも、浴槽の換水や清掃の時刻を、来場に合わせてずらす判断に予測を使わないでください。 衛生の管理は、自治体の条例や保健所の指導に沿った旅館の決まりで行います。
指示内容を固定する
生成AIを使わないので、プロンプトはありません。 かわりに、予測と浴場の人数の見積もりの中身を示します。
from sklearn.ensemble import HistGradientBoostingRegressor
FEATURES = ["weekday", "is_holiday", "is_pre_holiday", "holiday_seq", "month",
"rain_mm", "rain_flag", "temp_max", "event_type", "road_closed",
"last_year_same", "recent4w_same_mean"]
# weekday・month・event_type は pandas の Categorical にしておく
def hgb(**kw):
return HistGradientBoostingRegressor(
max_iter=400, learning_rate=0.05, early_stopping=True,
validation_fraction=0.15, random_state=0, **kw)
center = hgb(loss="poisson")
lower = hgb(loss="quantile", quantile=0.2)
upper = hgb(loss="quantile", quantile=0.8)
ok = train["closed_early"] == 0 # 早めに締めた日は中央・下振れから外す
center.fit(train.loc[ok, FEATURES], train.loc[ok, "walkins"])
lower.fit(train.loc[ok, FEATURES], train.loc[ok, "walkins"])
upper.fit(train[FEATURES], train["walkins_extended"]) # 締めた日は引き延ばした値
def bath_load(walkins_upper, share_13_15, plan_guests, early_checkins):
"""13〜15時の浴場の人数の見積もり"""
return walkins_upper * share_13_15 + plan_guests + early_checkins
early_stopping を明示的に有効にしているのは、既定の 'auto' では学習の行が10,000を超えるときにしか有効にならないからです。 日ごとの記録は3年分でも千行ほどで、既定のままでは早期の打ち切りが働きません。
walkins_extended は、締めた日の来場を14時までの分に引き延ばした値です。 13時で締めた日なら、締めるまでの来場を、同じ曜日・季節の締めなかった日に「13時までに発券された割合」で割って出します。引き延ばした値は推計なので、上振れのモデルにだけ使い、中央と下振れには入れません。
share_13_15 は、曜日と季節で分けて持ちます。 冬の週末は昼前から来る客が多く、夏の平日は午後に寄ってくる客が多い、といった違いがあります。同じ来場の数でも、13時から15時に重なる人数は季節で変わります。
中央と上振れが交わる日は、大きいほうを上振れとして使います。 別々に学習した分位点のモデルは、まれに中央を下回る上振れを出すことがあり、その日数を記録しておきます。
出力形式を固定する
女将と料理長に渡すのは、次の表です。 印刷して金曜の昼に見ることを前提にします。
【翌週の日ごとの日帰りの見込み(2026年11月第2週・金曜 9:02 作成)】
| 日 | 天気(入力) | 予約なし(下振れ/中央/上振れ) | プラン | 宿泊の早い到着 | 13〜15時の浴場 | 印 | 受付の案 | 昼食の仕込み | 貸しタオル |
|---|---|---|---|---|---|---|---|---|---|
| 月 | 雨・9℃ | 42/55/68 | 6 | 4 | 26 | - | 14時まで | 18 | 75 |
| 土 | 晴れ・14℃ | 160/195/240 | 22 | 15 | 92 | 赤 | 13時で締める案 | 64 | 260 |
| 日 | 曇り・12℃ | 120/150/185 | 18 | 3 | 61 | 黄 | 14時まで・見回り+1 | 48 | 205 |
「印」と「受付の案」で、女将が見る先を決めます。 赤の日は、締める時刻を早めるかを決め、決めたらホームページの案内を直します。黄の日は、受付は通常どおりで見回りを増やします。
表の一番下には、注意の印を並べます。 予報に雨や雪を含む日には「天気の読み:前日にやり直し」、初めての催しには「催しの上乗せ未定」、予定のシートが空の日には「予定未入力」を出します。印の無い日は、案のとおりで大きくは外れない日です。
機械で読む用には、同じ内容を CSV でも残します。 列は、日、下振れ・中央・上振れの来場、プランと宿泊の早い到着の数、浴場の人数の見積もり、印、各案、モデルを作った日付です。翌週に実績と並べて当たり方を見るのは、この CSV です。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 券売機 | 週に1回、管理画面から CSV を書き出してフォルダに置く | 日帰り入浴の発券の数と時刻 |
| 食事処のレジ | 週に1回、記録を書き出す | 日帰りの昼食の数 |
| 予約の管理の仕組み | 週に1回、日ごとの数を書き出す(名前と連絡先の列は捨てる) | プランの数と宿泊の早い到着 |
| 予定と換算の規則のシート | スプレッドシートを CSV で書き出して読む | 催し、天気予報、換算 |
| ホームページとシフトの表 | 書き込まない(女将が決めてから直す) | - |
ホームページの案内は、女将が決めてから事務が直します。 予測の案をそのまま載せる作りにすると、前日のやり直しのたびに案内が変わり、客が混乱します。
人が確認する
- 作った日時を見る … 表の上の日時が当日の朝であることを確かめます
- 赤と黄の日を見る … 宿泊の客層、団体の到着の時刻、清掃の段取りと突き合わせ、受付の時間を決めます
- 仕込みの数を料理長と確かめる … 下振れで出した数に、その日の献立と仕入の都合を足し引きします
- 予測の外の事情を足し引きする … 近くの旅館の休館、旅行の情報誌の掲載、テレビの紹介などを足し引きします
目標は、30日をならして1件6分です。 印の無い日は案を写すだけで、時間を使うのは赤と黄の日と、天気の読みの日です。
例外に対処する
| 起きること | 対応 |
|---|---|
| 券売機の CSV が届いていない週がある | その週を欠けとして扱い、表に「来場の記録の欠け」と出す |
| 受付を早めに締めた日の時刻が記録に無い | 締めた日の印だけ付け、中央と下振れの学習から外す |
| 予定のシートが空 | 予測は出し、表の一番上に「予定と天気予報が未入力」 |
| 日帰り入浴を休んだ日(点検・貸切) | 行ごと外す。来場0として学習しない |
| 大雪・台風で道路が止まった日 | 予定のシートで通行止めの印を付ける。営業の判断は女将 |
| 中央と上振れが交わる | 大きいほうを上振れとして使い、日数を記録 |
| 作り直したモデルが前より外れる | 前のモデルのまま使い、作り直しの記録を残す |
| パソコンが止まっていて動かなかった | 事務が手で実行。作った日時の古い表は使わない |
4行目と5行目を間違えると、天気の効き方が大きく出すぎます。 休んだ日や道路が止まった日を「来場0」として学習すると、雪の予報の日の来場を、道路が開いていても少なく見込みます。 冬に雪の多い地域の旅館では、通行止めの印を必ず付けます。
記録を残す
- 実行の日時、使ったモデルの作成日、読み込んだ記録の期間
- 日ごとの下振れ・中央・上振れの来場、浴場の人数の見積もり、印、各案
- 女将が決めた受付の時間と、案から変えた理由
- 翌週の実績(予約なしの来場、受付を締めた時刻、昼食の数と売れ残り、宿泊客からの浴場の混み具合の声)
- 前日のやり直しの有無と、やり直す前と後の案
- 月ごとの当たり方(中央の外れの大きさ、上振れを上回った日の割合、下振れを下回った日の割合)と、モデルの作り直しの結果
3つ目と4つ目を並べると、締める判断が合っていたかが分かります。 赤の日に13時で締め、宿泊客から混み具合の声が出なかったなら、判断は働いています。黄の日に声が出たなら、「上限」の人数を見直します。
上振れを上回った日の割合は、0.8の線なら5日に1日ほどが目安です。 それより多ければ上振れの線が低すぎ、受付を締める判断が遅れます。
04実装レベルの3段階
本記事の想定は本格構成です。 半自動化では来場の表までで、宿泊の到着と重ねる見積もりと、仕込みへの換算は女将と料理長の手に残ります。 第3章の(d)の並べて見る手間が残ります。 半自動化で1件20分が12分ほどに、本格構成で6分になります。 差が大きいのは、浴場の人数の見積もりと仕込みへの換算が、規則があれば機械で出せる作業だからです。 段階を飛ばさないでください。 半自動化の表を1か月見ると、どの曜日・季節の予測が当たり、どこが外れるかが分かります。外れる日の記録を直してから、本格構成に進みます。 本格構成の先には、混みやすい日を客に先に知らせる使い方も考えられます。 赤の日をホームページの「日帰り入浴のご案内」に「混雑が見込まれる日」として出せば、空いている平日に来てもらうきっかけになります。 ただし予測が外れると不満につながるので、出すなら「過去の傾向」として出し、受付の時間の案内とは分けて書きます。
05工数削減シミュレーション
導入後 30件 × 6分 ÷ 60 = 3 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 客室数十室ほどで、昼のあいだ大浴場を日帰りの客に開いている温泉旅館。券売機やレジで日帰り入浴の受付の時刻と人数が記録に残っている場合。宿泊客が入り始める午後と日帰りの客が重なって浴場が混む日があり、受付を締める時刻を女将や支配人が当日の朝に決めている場合。食事処の昼食の仕込みが日帰りの客の数で余ったり足りなかったりしている場合。日帰りの温浴施設を併設する宿にも使える。
- 日帰り入浴を受けていない旅館、または予約制だけで受けていて当日の来場の振れが無い旅館。日帰りの受付の記録が日ごとの売上の合計しか残っていない場合。開業や改装から1年未満で、季節と天気の動きが記録に無い場合。なお、受付を締める時刻の決定、源泉と浴槽の衛生の管理、悪天候のときの営業の判断は、この構成では代替できません。
07最小構成で試す方法
- 券売機から、去年の秋から冬の4か月分の日帰り入浴の記録を書き出す
- その期間に受付を早めに締めた日を、女将の手帳や予定表から拾う
- 気象庁の過去の気象データ・ダウンロードで、近くの地点の日ごとの降水量と気温を落とす
- Python で第7章の設定を動かし、その4か月の最後の4週を「翌週」として予測させる
- 当時の女将の見立てと、実際の来場と並べる
4か月・4週で十分です。 確かめたいのは、「雨と暦と紅葉の動きを、女将の見立てと同じくらい拾えるか」です。
| 出てきた内容 | 判断 |
|---|---|
| 天気と週末の動きが当時の来場と合う | 予定のシートと換算の規則を作り、毎週の表を出す段階に進む |
| 週末の混む日が低めに出る | 早めに締めた日が頭打ちになっている。締めた日の印を確かめる |
| 紅葉や祭りの週が大きく外れる | 催しの項目が足りない。予定のシートの過去の記録を埋める |
2行目は、ほとんどの旅館で出ます。 締めた日の記録が手帳にしか無いためで、失敗ではなく、締めた日と時刻を記録する理由が数字で分かったということです。
秋から冬を選ぶのは、来場の振れが大きい時期だからです。 紅葉の週末、雨の平日、初雪の日が入り、天気と催しの効き方を短い期間で確かめられます。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 早めに締めた日の来場が頭打ちのまま学習される | 締めた日に印を付け、中央から外すか引き延ばす |
| プランの客まで予測して二重に数える | 予約なしの客だけを予測し、プランは台帳の数を足す |
| 休んだ日を来場0で学習する | 行ごと外す |
| 道路の通行止めを天気として覚える | 通行止めの印を予定のシートで付ける |
| 昼食の仕込みを中央で出して余る | 下振れで出し、料理長と分位を決める |
| 13〜15時の重なりを季節で分けない | 曜日と季節で時刻の分布を分ける |
| 気象庁の CSV を列の位置で読む | 品質情報などの列が並ぶ。列名で選ぶ |
early_stopping が効かない | 行が10,000以下だと既定では無効。明示して有効にする |
| ホームページの案内が毎日変わる | 前日の変更は遅らせる方向だけにする |
| 予約の書き出しの名前を読み込む | 日付と数と到着の時刻以外の列を捨てる |
上の2行が、この構成の失敗のほとんどです。 どちらも、記録に残っている来場と、本当に来たかった来場がずれることから起きます。ここを押さえれば、残りは他の来場の予測と同じ注意で足ります。
下の方の行は、作ってからの運用で出てくるものです。 毎月の当たり方の確認と、女将が案から変えた理由の記録を習慣にしておけば、どれも早いうちに気づけます。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 日帰り入浴の発券の数と時刻、昼食の注文の数、宿泊と日帰りプランの予約の日ごとの数です。予約の書き出しには、宿泊客の名前と連絡先が含まれることがあります。
- 宿泊客の名前と連絡先を予測に使わない … 予約の書き出しを読み込むときに、日付と数と到着の時刻以外の列を捨てます。予測に要るのは日ごとの数だけです
- データを外に出さない … 予測は事務所のパソコンの中で動き、生成AIや外部のサービスに記録を送りません
- 受付の時間は人が決める … 案はあくまで案で、ホームページに載せる受付の時間は女将が決めます。 予測の数を理由に、当日になって急に受付を締める運用にしないでください
- 衛生の管理に使わない … 換水や清掃の時刻を、来場の見込みに合わせてずらさないでください。浴槽の衛生は、条例と保健所の指導に沿った旅館の決まりで管理します
- 営業の判断に使わない … 台風や大雪のときに日帰りを受けるかは、客と従業員の安全の判断です。来場の見込みが多いことを、受け続ける理由にしないでください
- 気象庁のデータの使い方を確かめる … 気象庁のホームページのコンテンツは、権利表記の無いものは公共データ利用規約(第1.0版)に沿って使え、使うときは出典を記載し、加工したものは加工したことを書くとされています
誤りが起きた場合のリスクは、宿泊客の入浴が混んで宿の評判を損なうことと、受けられた日帰りの客を断ることの2つです。 前者は締めた日の頭打ちの補いが足りないと起き、後者は上振れの線が高すぎると起きます。締めた日の記録と、上振れを上回った日の割合の確認で、両方を抑えます。
10まず何から始めるか
1週目:締めた日と時刻を記録し始める
受付を早めに締めた日と時刻を、予定のシートに書く決まりにします。過去の分も、女将の手帳や予定表から拾えるだけ拾います。
2週目:4か月分で試す
第8章のとおり、去年の秋から冬の4か月分の券売機の記録と気象庁の日ごとの天気で、最後の4週を予測させます。週末の混む日が低めに出ていないかを最優先で見ます。
3週目:換算の規則を決める
女将と料理長と一緒に、13〜15時の浴場の「ゆとり」と「上限」の人数、昼食の仕込みに使う分位、貸しタオルの予備を表にします。
4週目:翌週の表を毎週出す
金曜の朝に日ごとの来場の表を出す半自動化を始め、女将はこれまでどおり自分で決めながら、表と見比べます。 翌週の月曜に、女将の見立てと表の中央のどちらが実績に近かったかを書き残します。
2か月目以降: 浴場の人数の見積もりと換算の案を足し、前日のやり直しを始めます。女将が案から変えた理由、上振れを上回った日の割合、昼食の売れ残りを毎月見ます。 女将が印の付いた日だけを見て受付の時間を決められるようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
HistGradientBoostingRegressor の loss に 'poisson'(目的の値が0以上であることが要る)と 'quantile' があり quantile で分位を指定すること。categorical_features の既定が 'from_dtype' であること。欠けた値を分岐ごとに左右どちらへ送るか学習すること。early_stopping='auto' は行が10,000を超えるときなどに有効になること(版 1.9.1) | scikit-learn: HistGradientBoostingRegressor | 2026-10-28 |
| 過去の気象データ・ダウンロードで複数地点・複数項目の過去の観測値(日別値など)を CSV で落とせること。CSV に品質情報・均質番号の列が並ぶこと | 気象庁: 過去の気象データ・ダウンロード(このページでできること) | 2026-10-28 |
| 気象庁のホームページのコンテンツが、権利表記の無い限り公共データ利用規約(第1.0版)に準拠して使え、出典の記載と、加工した場合はその旨の記載が求められること | 気象庁: 気象庁ホームページについて | 2026-10-28 |
| 国民の祝日の CSV が昭和30年から令和9年までを収録し、翌年の分を前年の2月に掲載するとされていること | 内閣府: 国民の祝日について | 2026-10-28 |
受付の時間、浴槽の衛生の管理、営業の判断は、旅館の判断で行ってください。 本記事は公開されている仕様で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-2223)についてのご相談はこちらから。
