コインランドリーの事業者が機械ごとの利用の記録・曜日・天気から、店舗ごとの時間帯の稼働を Python で予測し、巡回と点検の時間帯の案を出す

処理の起点を決める

毎週木曜の朝に1回動かします。 巡回の担当の翌週の予定の締めが木曜の夕方なので、計画係が昼のうちに候補を見て、担当の予定と突き合わせられる時刻にします。事務所のパソコンの定時実行の仕組み（Windows ならタスク スケジューラ）で Python のスクリプトを起動します。

前日の朝にも、天気予報が変わった日だけ動かします。 計画係が予定のシートの翌日の天気を直して「やり直し」の印を付けたら、その日の分だけ予測と候補を作り直します。 毎日すべての日をやり直すと、担当への連絡が増えて予定が落ち着きません。

月に1回、モデルを作り直します。 毎月の第1木曜に、先月までの記録で学習し直し、作り直す前と後で、先月の当たり方を比べた結果を残します。悪くなっていれば、前のモデルのまま使います。

結果の表には作った日時を必ず印字します。 前日のやり直しの後に、古い表で巡回を組まないためです。

入力データを集める

質を決めるのは、故障の記録と機械の台帳です。 故障の記録が無ければ、止まっていた機械の分だけ需要が少なく学習されます。台帳のコースの長さが無ければ、使い始めの回数から稼働を積み上げられません。 どちらも管理の仕組みからは出てこない、運営の側が持つ情報です。

利用の記録に会員の番号が含まれる仕組みもあります。 ポイントのカードやアプリで払った客の番号です。予測には要らないので、読み込むときに列ごと捨てます。

天気は日ごとの値を使います。 コインランドリーの乾燥機の需要は、その日に雨が降ったかに加え、前日の雨と、晴れの日の湿度でも動きます。気象庁の過去の気象データ・ダウンロードでは、地点と項目を複数選び、検索の結果を CSV で落とせます。 店の近くの観測地点の日ごとの降水量・日照時間・湿度・最高気温を取ります。店が離れていれば、店ごとに近い地点を割り当てます。

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

気象庁の CSV には、値の列のほかに品質情報や均質番号の列が並び、降水量には現象なし情報の列もあります。 値の列だけを名前で選んで読みます。列の位置で読むと、項目を足したときに湿度の列に品質情報が入ります。

祝日の CSV は、翌年の分が前の年の2月に載るとされています。年に1回、2月に入れ替えます。

管理の仕組みの CSV は、店によって機械の世代が違うと書き方も違うことがあります。 古い機械は使い始めの時刻だけ、新しい機械は終わりの時刻まで出る、という具合です。最初に店ごとに1週分を見て、時刻とコースの列の読み方を1か所に書いておきます。

AIへ渡す前に整形する

1. 1時間の枠にそろえる … 営業時間を1時間ずつに区切り、店・機種ごとに使い始めの回数を数えます
2. 使える台数を出す … 機械の台帳の台数から、故障の記録で止まっていた機械を時間ごとに引きます。全台止まっていた枠は、0ではなく行ごと外します
3. 満台の枠に印を付ける … コースの長さで稼働を積み上げ、使える台数の95％を超えた枠を「満台」とします
4. エラーで止まった利用を外す … エラーの番号のある利用は、すぐ別の機械で使い直されることが多いので、二重に数えないよう外します
5. 項目を作る … 店、機種、曜日、時刻、祝日とその前日、月、その日と前日の降水量、日照時間、湿度、最高気温、催しの有無、前年の同じ週の同じ曜日・同じ枠の回数、直近4週の同じ曜日・同じ枠の平均
6. 店・機種・曜日・時刻を Categorical にする … pandas の Categorical の型にしておけば、既定の設定でカテゴリとして扱われます

2番目と3番目が、この構成の肝です。 乾燥機が1台止まっていた雨の日は、使える台数が1つ少なく、満台になりやすい日です。台数を引かずに学習すると、「雨なのに使い始めが少なかった日」として覚えます。

満台の枠の使い始めは、本当の需要より少なく出ます。 コインランドリーには待ちの受付がなく、入れなかった客の記録を取る手段がありません。満台の枠は、中央のモデルの学習から外し、上振れのモデルにだけ使います。 印の付いた枠が多い店は、予測が低めに出ていることを表の上に書きます。

前日の降水量を項目に入れるのは、雨が上がった翌日にも乾燥機が埋まるからです。 雨の日に乾かせなかった洗濯物を、翌日にまとめて持ち込む客がいます。その日の雨だけで学習すると、翌日の混み方を見落とします。

AIに処理させる

させるのは、翌週の店・機種・1時間ごとの使い始めの回数を予測することだけです。 機械学習のモデルを2本作ります。

稼働そのものは、モデルに直接予測させません。 稼働は台数で頭打ちになるので、学習させると天井を覚えます。使い始めを予測し、コースの長さで1時間ごとに積み上げて稼働を出します。

巡回の候補は、「空き」の枠が1時間以上続き、前後の枠に橙や赤が無いところから選びます。 乾燥機のフィルターの掃除には、乾燥機を止められる時間が要るからです。40％の線は、計画係と一緒に決めます。 店の広さや作業の長さで、邪魔にならない稼働は違います。

2行目は、とくに気を付けてください。 満台の印が多い店は乾燥機を足したくなりますが、満台の枠の需要は少なめにしか見えていません。 増設を考えるなら、予測の表ではなく、満台の枠の数と長さの推移を別に見ます。

指示内容を固定する

生成AIを使わないので、プロンプトはありません。 かわりに、予測と積み上げの中身を示します。

from sklearn.ensemble import HistGradientBoostingRegressor
from sklearn.model_selection import TimeSeriesSplit
import numpy as np

FEATURES = ["store", "machine_type", "weekday", "hour", "is_holiday", "is_pre_holiday",
            "month", "rain_mm", "rain_mm_prev", "sunshine_h", "humidity", "tmax",
            "event_flag", "last_year_same", "recent4w_same_mean"]
# store・machine_type・weekday・hour は pandas の Categorical にしておく

# 乾燥機のモデルだけ、降水量が増えて使い始めが減ることはない、という向きを付ける
dryer_cst = {"rain_mm": 1, "rain_mm_prev": 1}

center = HistGradientBoostingRegressor(
    loss="poisson", max_iter=800, learning_rate=0.05, monotonic_cst=dryer_cst,
    early_stopping=True, validation_fraction=0.15, random_state=0)
upper = HistGradientBoostingRegressor(
    loss="quantile", quantile=0.8, max_iter=800, learning_rate=0.05,
    monotonic_cst=dryer_cst, early_stopping=True, validation_fraction=0.15, random_state=0)

train_c = dryer[~dryer["full"]]              # 満台の枠は中央の学習から外す
center.fit(train_c[FEATURES], train_c["starts"])
upper.fit(dryer[FEATURES], dryer["starts"])

# 当たり方は時系列の順を守って確かめる（学習は常に検証より前）
tscv = TimeSeriesSplit(n_splits=5, gap=24 * 7)   # 1時間の枠で1週分の間を空ける

monotonic_cst は名前で指定しています。 公式の説明では、辞書で渡すと項目の名前で制約を対応させ、1は増える向き、-1は減る向き、0は制約なしです。名前で渡すには、学習に項目の名前のある表（pandas の DataFrame）を使います。乾燥機のモデルにだけ付け、洗濯機のモデルには付けません。 洗濯機は雨で増えるとは限らないからです。

当たり方の確かめには TimeSeriesSplit を使います。 公式の説明では、時系列の順に並んだデータで、学習が常に検証より前になるように分け、後の分割ほど学習の範囲が広がります。gap で学習の末尾と検証の間を空けられます。ふつうの交差検証で混ぜると、未来の記録で学習して過去を当てることになり、当たり方が良く見えすぎます。 公式は、各回の比べ方をそろえるには等間隔に並んでいることが要るとしているので、営業時間外の枠も行として持ってから分けます。

early_stopping を明示的に有効にしているのは、既定の 'auto' では学習の行が10,000を超えるときにしか有効にならないからです。 9店・4機種・1時間の枠で1年分あれば超えますが、1店で試す段階では超えないことがあります。

def occupancy(starts_by_hour, run_share):
    """run_share[k] = 使い始めた機械が k 時間後の枠でもまだ動いている割合"""
    occ = np.zeros(len(starts_by_hour))
    for i, s in enumerate(starts_by_hour):
        for k, r in enumerate(run_share):
            if i + k < len(occ):
                occ[i + k] += s * r
    return occ

run_share は、機械の台帳のコースの長さと、利用の記録のコースの分数から作ります。 洗濯乾燥のコースは1時間を超え、乾燥機は10分単位で延長されるので、機種ごと・時間帯ごとに分けて持ちます。

出力形式を固定する

計画係に渡すのは、次の2つの表です。 印刷して木曜の昼に見ることを前提にします。

【店ごとの1時間ごとの稼働（1日分の例・駅前店）】

【翌週の巡回の時間帯の候補】

「印」の列で、計画係が見る先を決めます。 雨の日の翌日には「雨の翌日」、満台の枠が多い店には「予測は低めの恐れ」、故障の記録で機械が止まったままの店には「台数減で計算」、予定のシートが空の日には「予定未入力」を出します。

機械で読む用には、同じ内容を CSV でも残します。 列は、店、日、時、機種、中央・上振れの使い始め、稼働、使える台数、印、モデルを作った日付です。翌週に実績と並べて当たり方を見るのは、この CSV です。

システムへ連携する

管理の仕組みに API があっても、最初は CSV の書き出しで始めます。 週に1回の書き出しで足り、仕組みの会社との取り決めや認証の手間を先に抱えなくて済みます。 書き出しの手間が負担になってから、API に替えるかを考えます。

人が確認する

1. 作った日時を見る … 表の上の日時が当日の朝であることを確かめます
2. 赤と橙の帯を見る … 巡回がその帯にかからないよう、候補から組みます
3. 雨の日と翌日の印を見る … 雨の予報の日は、前日にやり直すかを決めます
4. 予測の外の事情を足し引きする … 近くの店の休業、学校の行事、引っ越しの多い時期、機械の入れ替えの工事

目標は、36件をならして1件5分です。 印の無い店は候補を写すだけで、時間を使うのは雨の週と満台の印が多い店です。

例外に対処する

4行目を間違えると、雨の効き方が乱れます。 台風で店を閉めた時間を「使い始め0」として学習すると、モデルは「大雨の日は誰も来ない」と覚え、乾燥機の単調性の制約とも食い違います。

記録を残す

• 実行の日時、使ったモデルの作成日、読み込んだ記録の期間
• 店・機種・1時間ごとの中央・上振れの使い始め、稼働、使える台数、印
• 計画係が組んだ巡回の時間と、候補から変えた理由
• 翌週の実績（使い始め、満台の枠、巡回の時間に店にいた客の数の目安）
• 前日のやり直しの有無と、やり直す前と後の候補
• 月ごとの当たり方（中央の外れの大きさ、上振れを上回った枠の割合）と、モデルの作り直しの結果

上振れを上回った枠の割合は、0.8の線なら5枠に1枠ほどが目安です。 それより多ければ上振れの線が低すぎます。満台の印を信じてよいかを見る、一番わかりやすい物差しです。