水道事業の担当が過去の配水量と気温の予報・曜日から Python で翌日の配水区域ごとの配水量を見込み、浄水場の運転計画の案に使う

処理の起点を決める

毎日13時に動かします。 前日の配水量が日報として締まり、民間の気象会社から翌日の予報が届いた後で、運転管理の担当が昼過ぎに計画を立て始める時間に間に合います。 予報の配信の時刻は契約している会社に確かめ、それに合わせて時刻を決めます。

予報が夕方に大きく変わったら、もう一度動かします。 気象会社の配信で翌日の最高気温が前回から2度以上変わったときに、見込みと計画の案を出し直し、運転管理の担当と当直の責任者に知らせます。 了承済みの計画を書き換えるのではなく、差を並べて出します。

監視制御の側からの書き出しが13時までに届かなければ、動かしません。 前々日までの記録で見込むと、前日の急な変化が入らないからです。その日は、担当がこれまでどおりの方法で計画を立てます。

入力データを集める

質を決めるのは、異常の記録です。 大きな漏水の事故があった日は、配水量が跳ねます。その日を普通の日として学ばせると、同じ季節・曜日の見込みが多めにずれます。 運転管理の記録に残っている事故・断水・流量計の故障の日を、学ばせる記録から外す印として使います。

気温は、区域ごとに代表の地点を決めます。 山側の観光の区域は、市街地より気温が低いことが多いので、近いアメダスの地点を区域ごとに選びます。 予報も、同じ地点か近い地点の値を気象会社から受け取ります。

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

監視制御の仕組みからは、決まった時刻に、区域ごとの日ごとの配水量と時間ごとの配水量を、決まった列の並びで書き出す設定を作ります。書き出したファイルは、監視制御の側から事務の環境の決まったフォルダへ、一方向で渡します。一方向の渡し方（専用の受け渡しの装置や、媒体による受け渡し）は、局の情報の管理の規程と監視制御の仕組みの保守の会社と決めます。

過去の気温は、最初に3年分をまとめて取り、その後は毎日前日の分を足します。 気象庁のCSVを使うときは、気象庁ホームページの利用の条件に沿い、出典を記載し、加工したものは加工したことを示します。 局の内部の資料でも、資料に出典を書いておきます。

AIへ渡す前に整形する

1. 欠けた日を調べる … 流量計の故障などで欠けた日は、学ばせる記録から外します。前後の日の平均で埋めません
2. 異常の日を外す … 漏水の事故・断水・大口使用者の休止の日に印を付け、学ばせる記録から外します
3. 区域の境界の変更を調べる … 配水区域の切り替えで、ある日から区域の受け持ちが変わっていれば、変わった日の前と後を同じ系列として扱わないよう、項目を立てます
4. 暦の項目を作る … 祝日、連休の何日目か、年末年始、学校の長期休み、地域の行事
5. 気温の項目を作る … 最高気温そのものと、「25度を超えた分」の2つを作ります。暑い側で増え方が急になる形を入れるためです
6. 時間ごとの配水の形を作る … 曜日の種類（平日・土曜・日祝）と季節ごとに、1日の配水量に対する時間ごとの割合の平均を作ります
7. 夏と冬で確かめ方を分ける … 夏の暑い日と、冬の寒波の日は、見込みの外れ方を別に数えます

1番目と2番目を軽く見ないでください。 流量計の故障で0が並んだ日や、大きな漏水で倍になった日は、1日でもモデルを大きく引っ張ります。埋めて使うより外すほうが、季節の動きを素直に学びます。

1年の季節の動きを、季節の長さ365の形で持たせないのも、意図してのことです。 日ごとのデータで1年の周期をモデルの形に入れると、計算が重くなり、3年分の記録では1年の形を3回しか見られません。夏に増え冬に減る動きの大半は気温で説明できるので、気温の項目に任せます。 気温で説明しきれない季節の差（年度末の転居、夏休みの帰省など）は、暦の項目で足します。

AIに処理させる

させるのは、区域ごとに「翌日の配水量の真ん中と幅」を見込むことだけです。 時間ごとの形への割り振り、浄水量と配水池の水位の計画の案、印付けは、決まった計算で行います。

幅は、80％の区間にします。 conf_int の alpha を0.2にし、10日のうち8日はこの間に入るという幅です。配水池の水位の計画は上側で組み、浄水量は真ん中で組みます。浄水は真ん中で作り、配水池の水位の余裕で上側までの差を受け止める、という役割分担です。

SARIMAX を選ぶのは、配水量の並びそのものが強い手がかりだからです。 昨日多ければ今日も多い、という日ごとのつながりと、7日の曜日の動きを、そのままモデルの形として持てます。 気温は外の項目として足し、何度でどれだけ増えるかを係数として読めます。係数が読めることは、第3章の（d）の引き継ぎの材料になります。

5行目がいちばん起きやすい失敗です。 「この気象会社の予報はいつも1度低い」と感じると、プログラムの中で予報を補正したくなります。補正を入れると、予報が外れた日に外れが二重になります。 予報の外れ方は保存して数え、気象会社と話す材料にします。

指示内容を固定する

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

【モデル（区域ごとに1つ）】
- statsmodels の SARIMAX
  ・endog = 区域の日ごとの配水量（異常の日は欠けた値として渡す）
  ・order = (1, 1, 1)、seasonal_order = (1, 0, 1, 7)
    （区域ごとに過去2年で当てはめ、外れ方の小さい組を選んで固定する）
  ・exog = [最高気温, 最高気温の25度超過分, 降水の有無,
            祝日, 連休の日数目, 年末年始, 長期休み]
- 学ばせ直しは月に1回。翌日を見込むのは毎日
- 翌日を見込むとき = get_forecast(steps=1) に翌日の exog を渡す
- 区間 = conf_int(alpha=0.2) で80％の区間

【時間ごとの形】
- 時間ごとの割合 = 直近8週の同じ曜日の種類（平日・土曜・日祝）の平均
- 夏（7〜9月）と冬（12〜2月）は、季節の割合を別に持つ

【浄水量と配水池の水位の案】
- 翌日の浄水量 = 真ん中の配水量の合計（区域の受け持ちの浄水場ごと）
- 配水池の水位 = 前日の夜の水位から、時間ごとに（浄水量 − 上側の配水量）を積み上げる
- 水位が運用の下限を下回る時間があれば、夜間の送水を増やす案を出す
- 運用の下限・上限は、運転管理の責任者が決めた値を設定の表から読む

【印を付ける条件】
- out_of_range  … 翌日の最高気温の予報が過去3年の範囲の外
- wide          … 80％の区間の幅が真ん中の8％超
- holiday_start … 連休の初日、年末年始の始まり
- jump          … 真ん中が前週の同じ曜日の実績から10％以上違う
- low_level     … 計画の案で配水池の水位が下限まで1割を切る時間がある
- 印の無い日は、計画の案をそのまま日報の表に載せ、了承に回す

order と seasonal_order を固定するのは、意図してのことです。 毎日いちばん合う組を探し直すと、日によってモデルの形が変わり、同じ天気の日の見込みが日によって違う、という説明のつかない動きが出ます。 組は月に1回の学ばせ直しのときだけ見直します。

浄水量を真ん中、水位を上側で組むのは、配水池を「幅を受け止める場所」として使うためです。 浄水量を上側で組むと、毎日作りすぎます。作る量は真ん中にし、多かった日の分は配水池の水位の余裕から出す、という形にすれば、外れても夕方の山で水位が下がりすぎません。

出力形式を固定する

区域・日ごとに、次の形のJSONを作り、表にして日報の表に載せます。

{
  "zone": "",
  "date": "",
  "weather_input": { "tmax": 0, "tmin": 0, "rain": false, "issued_at": "" },
  "demand_m3": { "p50": 0, "lower80": 0, "upper80": 0 },
  "last_week_same_day_m3": 0,
  "hourly_m3": [ { "hour": 0, "p50": 0, "upper80": 0 } ],
  "plant_output_m3": 0,
  "reservoir_plan": [ { "reservoir": "", "hour": 0, "level_pct": 0 } ],
  "flags": ["out_of_range | wide | holiday_start | jump | low_level"],
  "model_version": "",
  "operator_override": { "plant_output_m3": null, "reason": "" }
}

1つ目の理由は、weather_input を見込みと並べて残せることです。 どの時刻の予報で見込んだかが分かれば、外れたときに、予報の外れかモデルの外れかを分けられます。

2つ目は、last_week_same_day_m3 を並べて見せられることです。 担当がこれまで使ってきた数と、見込みの数の差が一目で分かります。差が大きい日は、その理由（気温か、祝日か）を印で確かめます。

3つ目は、operator_override で直した記録が残ることです。 担当が浄水量を直したら、その値と理由を書きます。ベテランが直した理由が残れば、それがそのまま引き継ぎの材料になります。

システムへ連携する

監視制御の仕組みへは、何もつなぎ返しません。 計画の案は日報の表までで、運転の担当が日報の表を見て、監視制御の画面で自分で設定します。 これまでの業務の流れの最後の段は変えません。

通知の連絡の場にも、配水量の数字は流しません。 流すのは「印の付いた区域と日」と「日報の表の場所」だけにし、運転の情報が連絡の場の外へ写される経路を作りません。

人が確認する

運転管理の担当が見るのは、毎日の計画の案と、印の付いた日の理由です。 印の無い日は、真ん中と前週の実績の差を見て、了承に回します。全件を前の方法で計算し直す運用にすると、第10章の9.0時間には収まりません。

1. low_level を先に見る … 配水池の水位が下限に近づく時間がある日です。夜間の送水を増やすか、区域間の融通を使うかを決めます
2. out_of_range と holiday_start を見る … 過去に例の少ない日です。ベテランの見立てと並べ、どちらで組むかを決めます
3. jump と wide を見る … 前週と大きく違う理由が、気温の予報か暦かを確かめます
4. 直したら理由を書く … operator_override に値と理由を残します

2番目で、見込みより人の見立てを採る日があって構いません。 見込みは過去3年の記録の範囲で出した数で、初めての暑さや、初めての大きな行事は知りません。 直した理由を残せば、次の年にはその日が学ばせる記録に入ります。

ベテランが在職しているうちは、印の無い日も週に1回は並べて見てもらいます。 見込みとベテランの読みが同じ向きにずれる日が続くなら、モデルに入っていない手がかり（地域の行事、工事による区域の切り替えなど）があるということです。 その手がかりを項目か異常の記録に足すことが、引き継ぎの中身になります。

例外に対処する

上から5行目は、毎年の冬に起きます。 寒波の翌朝に、宅内や道路の下の管が凍って割れ、配水量が一時的に増えます。気温が下がると配水量が増えるという逆向きの動きで、夏の暑さの係数とは別に扱います。 最低気温の項目を冬だけ足すかは、過去の寒波の日の記録で確かめてから決めます。

記録を残す

• 読み込んだ配水量の書き出しと、気象会社の予報（配信の時刻を含めて）
• 区域・日ごとの見込み、80％の区間、時間ごとの配水量
• 浄水量と配水池の水位の計画の案
• 運転管理の担当が直した値と理由
• 翌日の実際の配水量と、見込み・予報の外れ方
• モデルの版、order と seasonal_order、外の項目の係数

最後の行は、引き継ぎの材料になります。 「最高気温が25度を1度超えると、住宅地の区域の配水量が何％増える」という係数が、区域ごとに毎月残ります。ベテランの頭の中にあった読み方の一部が、数字として残ります。