リネンサプライ会社が、取引先ホテルの予約室数と過去の回収量から翌週のシーツ・タオルの必要量を予測し、洗濯工場の稼働計画の案を出す

処理の起点を決める

毎週金曜の15時に動かします。 取引先の予約室数の表は、金曜の昼までに届くよう取引先にお願いしておきます。15時に予測を出し、16時から工場長と稼働計画を相談し、17時までにパートに声をかける流れにします。いまは金曜の夕方にようやく見積もりが終わっているので、声をかけるのが2時間ほど早くなります。

届いていない取引先があっても、15時には動かします。 その取引先は予約室数を空にして予測し、印を付けます。全社がそろうのを待つと、15時が17時になり、追加の勤務の声かけに間に合いません。

水曜の朝にもう1回、同じ予測を動かし直します。 週の後半（木曜から日曜）の分について、取引先から更新した予約室数が届いていれば、その数で予測し直します。週の後半の追加の勤務を、水曜の時点で見直せるようにするためです。

学習のやり直しは、月に1回、月初めの週末にします。 予測と実績の差が、ある取引先だけ続けて大きいときは、月の途中でもその取引先の係数の見直しを先に行います。

入力データを集める

質を決めるのは、2行目の予約室数の控えです。 第1章で書いたとおり、学習に使う予約室数は、予測する時点で手に入っていたものと同じ時点の控えでなければなりません。控えが無い期間は、過去の実際の稼働室数で代用することになり、その期間の学習は直前の予約の分だけずれます。控えを貯め始めた日から、この構成の精度が上がり始めます。

回収数と使用数の関係にも注意します。 回収するのは前の日に使われたリネンなので、回収の日付を1日ずらして宿泊日にそろえます。取引先によっては回収が2日に1回で、その場合は2日分をまとめて回収しているので、宿泊日ごとに按分せず、回収の単位のまま予測します。

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

予約室数の表は、取引先ごとに形がばらばらです。取引先ごとの読み込みの設定（どの列が日付で、どの列が予約室数か）を、設定ファイルに1社1行で持ちます。 新しい取引先が増えたら、その1行を足します。

電話で聞いた室数は、「電話」という印を付けて控えに入れます。 表で届いた数と電話で聞いた数は確からしさが違うので、モデルにはその区別を項目として渡します。 電話の数が多い取引先ほど、予測の幅が広く出るはずです。

AIへ渡す前に整形する

1. 予約室数の表をそろえる … 取引先ごとの設定で読み込み、取引先・宿泊日・予約室数の3列にそろえます
2. 控えに保存する … そろえた表を、予測した日時を付けて控えのファイルに足します。上書きせず、毎回足します
3. 回収の日付をずらす … 回収日の前日を宿泊日として扱います（2日に1回の取引先は回収の単位のまま）
4. 異常な回収数を外す … 0の日（回収の休み）、通常の5倍を超える日（記録の誤り、または改装でまとめて出した日）は学習から外し、一覧に残します
5. 特徴量を作る … 予約室数の控え、前年の同じ週の回収数、直近4週の「回収数 ÷ 実際の稼働室数」の比、曜日、祝日の前日、取引先の区分、品目
6. 予約の伸びを特徴量にする … 前の週の水曜の控えから金曜の控えまでの予約室数の増え方
7. 在庫を確かめる … ホテルに預けている枚数と工場の在庫を、品目ごとに足し合わせます

5番目の「直近4週の比」は、予測する週より前の実績だけで計算します。 予測する週の実績を混ぜると、検証では当たるのに使うと外れるモデルになります。学習と予測で同じ関数を使い、日付で切ることを関数の中に書き込みます。

6番目は、第3章の（c）の癖をモデルに学ばせるための項目です。 直前の予約で伸びる取引先は、水曜から金曜にかけても伸びています。その伸び方が、翌週の直前の上積みの手がかりになります。

AIに処理させる

させるのは、取引先 × 品目 × 日の必要量を、中央の値と多めの値で予測することです。 2つのモデルを別々に学習させます。

学習の検証は、時間の順を守って行います。 scikit-learn の TimeSeriesSplit は時間の順に並んだデータを分ける仕組みで、公式のページによれば、ほかの交差検証の方法では未来のデータで学習して過去のデータで評価することになるため不適切とされています。検証の区間は1週ずつにし、gap で学習の区間の最後の数日を空けます。 金曜の時点では、その週の木曜・金曜の回収がまだ記録表に入っていないので、その状態に合わせます。

検証では、取引先の区分ごとに外れ方を分けて見ます。 ビジネスホテルは当たるのに旅館は外れる、という偏りは全体の数字では見えません。多めの値は、実績がそれを超えた日がおよそ15％に収まっているかを確かめます。 大きく超えるなら、安全の幅として使うには低すぎます。

稼働計画は、予測の後に OR-Tools で計算します。 変数は、日ごと・品目の系統ごと（シーツ類とタオル類）に洗う枚数と、日ごとの残業の時間・休日の稼働の有無です。

「多めの値に対する不足」を目的の側に入れているのは、守ることにすると解けない週が出るからです。 繁忙期は、多めの値まで全部洗うと上限を超えます。中央の値は必ず守り、多めの値は「足りない枚数をできるだけ小さく」する扱いにします。 不足が残った品目と日は、案に書き出して人が判断します。

指示内容を固定する

この構成は生成AIを使わないため、AIへの文章の指示はありません。代わりに、予測と計画の設定をこの形で書いておきます。 担当が替わっても、何を決めてあるかが読めるようにするためです。

【予測の設定】
- 目的の値: 取引先 × 品目 × 宿泊日の回収数（回収日の前日を宿泊日とする）
- 中央の値: HistGradientBoostingRegressor(loss="poisson")
- 多めの値: HistGradientBoostingRegressor(loss="quantile", quantile=0.85)
- カテゴリの項目: 取引先の区分、品目、曜日、予約室数の出どころ（表／電話／無し）
- 欠けた値: 予約室数が届かない取引先は NaN のまま渡す。前週の数で埋めない
- 予約室数: 学習も予測も「金曜15時の控え」を使う。実際の稼働室数は使わない
- 検証: TimeSeriesSplit（1週ずつ、gap は未記録の日数）

【印を付ける規則】
- (多めの値 − 中央の値) ÷ 中央の値 が 0.4 を超える取引先 × 品目
- 予約室数が前年の同じ週から ±30％ を超えて動いた取引先
- 予約室数の出どころが「無し」の取引先
- 直近4週で、予測と実績の差が続けて 20％ を超えた取引先

【稼働計画の設定】
- ソルバー: OR-Tools pywraplp.Solver.CreateSolver("SAT")
- 変数は整数（枚数、残業の分を15分単位、休日の稼働の有無）
- 中央の値は必ず満たす。多めの値の不足は目的関数で小さくする
- 解の状態が OPTIMAL でないときは案を出さず、工場長に知らせる

「実際の稼働室数は使わない」を明記しているのは、使ったほうが検証の成績が良く見えるからです。 実際の稼働室数は答えにかなり近い値で、検証では当たります。ところが金曜の時点では手に入らないので、使うと実際の運用で外れます。 成績の良さに引かれて入れたくなる項目なので、設定に書いて止めます。

「解の状態が OPTIMAL でないときは案を出さない」は、OR-Tools の例のとおりの確かめ方です。 例では solver.Solve() の戻り値が OPTIMAL かどうかを確かめてから結果を読んでいます。解けなかったときに途中の値を案として出すと、上限を超えた計画が案として勤務表に届きます。

出力形式を固定する

工場の共有フォルダに、次の2つの表を置きます。

【見込み表（1行＝取引先 × 品目 × 日）】

{
  "client_code": "H-018",
  "client_type": "business_hotel",
  "item": "sheet_single",
  "date": "2026-10-20",
  "rooms_on_books": 142,
  "rooms_source": "sheet",
  "pred_p50": 231,
  "pred_p85": 268,
  "last_year_same_week": 205,
  "flags": ["booking_jump"],
  "note": ""
}

【稼働計画の案（1行＝日）】

1つ目の理由は、rooms_source を出すことです。 予約室数が表で届いたのか、電話で聞いたのか、無いのかで、予測をどこまで信じてよいかが変わります。担当者は rooms_source が「無し」の取引先から先に電話をかけます。

2つ目は、shortfall_p85 を日ごとに出すことです。 工場長は、多めの値まで洗えない日がどこにあるかを見て、残業を足すか、取引先に在庫の融通を相談するかを決めます。 不足の無い週は、この列が0で並ぶだけです。

システムへ連携する

勤務表へは書き込みません。 稼働計画の案は見込みの表と同じフォルダに置くだけで、勤務表に書き込むのは工場長です。 案を自動で勤務表に入れると、パートへの声かけの前に勤務が決まったように見えてしまいます。

人が確認する

人が開くのは、印の付いた取引先と、稼働計画の案だけです。

1. 予約室数の出どころが「無し」の取引先 … 電話をかけて室数を聞き、入力の表に書いて、その取引先だけ予測し直します
2. 予約室数が大きく動いた取引先 … 団体の予約や改装による休館が無いかを取引先に確かめます
3. 予測の幅が広い取引先 × 品目 … 前年の同じ週の実績と並べ、中央の値と多めの値のどちらに寄せて洗うかを決めます
4. 稼働計画の案 … 工場長が overtime_min と shortfall_p85 を見て、追加の勤務を決めます
5. 直した数を記録する … どの取引先のどの品目を、何枚から何枚に直したか、理由とともに残します

例えば、温泉旅館に booking_jump の印が付いた週です。 予約室数が前年の同じ週より4割多く、担当者が電話で確かめると、団体の予約が入っていたと分かります。団体は浴衣とバスタオルを多く使う一方、連泊が少なくシーツの交換は通常どおりです。担当者は浴衣とバスタオルだけを多めの値に寄せ、シーツは中央の値のままにします。 この判断は、品目ごとに取引先を知っている人にしかできません。

5番目は、予測の外れの原因を切り分けるための記録です。 人が数を直した週と直さなかった週を分けておかないと、翌週の実績と比べたときに、外れたのが予測か人の判断かが分かりません。

例外に対処する

上から5行目は、計算の側の安全装置です。 繁忙期に上限が足りないと、計算は解を返しません。そのとき途中の値で案を出すと、処理しきれない量の計画が勤務表に届きます。 解けないこと自体が「人が判断すべき週」という知らせです。

記録を残す

• 予約室数の控え（取引先ごと、予測した日時ごと。上書きしない）
• 学習に使った期間、モデルの設定、検証の結果（取引先の区分ごとの外れ方）
• 見込み表と稼働計画の案の全行、計算の状態
• 人が直した数と理由、工場長が決めた追加の勤務
• 翌週の実績と予測の差（取引先 × 品目ごと）

1つ目の控えが、この構成のいちばん大事な記録です。 予約室数の表は取引先が毎週上書きして送ってくるので、控えを取らないと、「金曜の時点でいくつだったか」は二度と分かりません。 学習の材料そのものなので、最初の週から貯め始めます。保存の期間は、前年の同じ週と比べられるよう、少なくとも2年とします。