水道の検針データから使用者ごとの使用量を見込み、漏水の疑いがある使用者を拾って、お知らせと現地確認の優先順を出す

処理の起点を決める

地区ごとの検針が締まったことを起点にします。 検針は地区単位で月をずらして行われるので、1か月に何回か、締まった地区の分だけを動かします。 締めの予定は検針の計画表にあるので、その日付で定時に動かすのが最も単純です。

全地区を月末にまとめて動かすことはしません。 月の前半に締まった地区の漏水を月末まで寝かせると、その分だけお知らせが遅れます。この構成の価値の多くは、気づくのを早めることにあります。

学び直しは別に動かします。月に1回、前の月までの検針の結果と、お知らせの後に量が戻ったかの記録を足して作り直します。 予測と学び直しを同じ処理に入れると、学び直しが失敗した日に一覧も出なくなります。

入力データを集める

質を決めるのは、いちばん下の2つです。 どの使用者が実際に漏水だったかの記録が無いと、見込みは「ふだんと違う」までしか言えません。減免の記録と、お知らせの後に量が戻ったかの記録が、漏水らしさの正解の材料になります。

世帯の人数は使いません。 住民の記録と結び付ければ見込みは良くなりそうに見えますが、水道料金の事務のために集めた情報ではありません。 人数の変化は、過去の使用量の動きそのものに表れます。

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

料金システムから、締まった地区の今回の検針の結果と、同じ使用者の過去の記録を書き出します。書き出しは地区の締めの翌朝に行い、締めの前の暫定の値を拾わないようにします。

修繕の受付簿はスプレッドシートなので、使用者番号の書き方をそろえるところから始めます。 番号の桁数やハイフンの有無が揃っていないと、修繕済みの使用者を「まだ漏れている」と拾い続けます。

メーターの交換の記録も必ず一緒に取ります。 交換の前後で指示数が0から始まり直すため、交換を知らずに差を取ると、とてつもない使用量か負の使用量が出ます。

AIへ渡す前に整形する

1. 1日あたりにそろえる … 今回と過去の使用量を、それぞれの検針の間隔の日数で割ります。検針日が数日ずれるだけで、前回比は1割近く動きます
2. メーターの交換をつなぐ … 交換の前後の指示数を、旧メーターの最終値と新メーターの初期値でつないでから差を取ります
3. 読み違いの疑いを分ける … 指示数が前回より小さい、使用量が過去の最大の10倍を超える、桁が1つずれた値と一致する、のどれかに当たるものを再検針の一覧へ回し、予測の対象から外します
4. 閉栓中の使用を分ける … 閉栓の期間に使用量が出ているものは、見込みを使わずに別の型として一覧に入れます
5. 特徴量を作る … 直近6期の1日あたり使用量、前年同期の値、直近3期の増え方の傾き、用途、口径、地区、検針月、メーターの設置からの年数
6. 欠けた値を残す … 新規の使用者の前年同期などは欠けたまま渡します
7. 修繕済みの印を付ける … 修繕の届出があった後の期は、学び直しで「漏水中」として扱わないようにします

3番目を軽く見ないでください。 読み違いは漏水よりはるかに大きく跳ねるため、見込みの上側との差で並べると、必ず一覧の上位を占めます。 使用者に「漏水のおそれ」と知らせた後で読み違いと分かるのが、この業務で最も信頼を損ねる失敗です。

5番目の「直近3期の傾き」が、（b）の少しずつ増える漏水を拾うための特徴量です。 前回比では見えない増え方を、3期分の並びとして渡します。

AIに処理させる

させるのは、使用者ごとに今回の1日あたり使用量の中央の見込みと上側の見込みを出すことだけです。 拾うかどうか、どの型か、どの順に並べるかは、見込みの値を使った規則で決めます。

疑いの型は4つです。

右端の列は候補で、決めるのは担当者です。 仕組みが「お知らせ」を自動で選んで、はがきの印刷まで進むことはありません。

優先順を「超過量 × 続いている期数」にしているのは、使用者の負担の大きさに近い並びだからです。 1日あたりの超過が大きくても1期だけなら来客や一時的な使用のこともありますが、小さな超過が3期続いているものは、その間ずっと水が流れ続けています。 超過の大きさだけで並べると、少しずつ増える漏水がいつまでも下位に残ります。

1行目が、この構成で最もはっきりさせておくことです。 上側を超えたという事実は、漏水の証拠ではありません。漏水を確かめる方法は、蛇口を全部閉めてメーターのパイロットが動いていないかを見ることで、これは使用者か現地の確認でしかできません。

指示内容を固定する

この構成でAIに与える指示は、文章のプロンプトではなく学習と予測の設定です。中央と上側の2本を同じ設定で作ります。

from sklearn.ensemble import HistGradientBoostingRegressor

FEATURES = [
    "use_per_day_lag1", "use_per_day_lag2", "use_per_day_lag3",
    "use_per_day_lag4", "use_per_day_lag5", "use_per_day_lag6",
    "use_per_day_same_period_last_year",   # 新規の使用者は欠けたまま
    "slope_last3",                          # 直近3期の傾き
    "usage_type", "diameter", "district",   # 区分の値（Categorical 型にしておく）
    "reading_month", "meter_age_years",
]

def make_model(q):
    return HistGradientBoostingRegressor(
        loss="quantile",
        quantile=q,            # 0.5 で中央、0.95 で上側
        max_iter=300,
        learning_rate=0.05,
        random_state=0,
    )

model_mid = make_model(0.5)
model_upper = make_model(0.95)

# 学習から外すもの
#   - 再検針になった期（読み違いの疑い）
#   - 閉栓中の期
#   - 修繕の届出より前で、減免の対象になった期（漏水中の量を「ふつう」と覚えさせない）
train = history[~history["excluded"]]
model_mid.fit(train[FEATURES], train["use_per_day"])
model_upper.fit(train[FEATURES], train["use_per_day"])

学習から外す3つ目が、この設定の要です。 漏水が続いていた期をそのまま学ばせると、モデルはその使用者の「ふつう」を漏水込みの量で覚えます。次に同じ漏れ方をしても、上側の見込みの中に収まって拾えなくなります。 減免の記録がある期を外すのは、そのためです。

上側を0.95にしているのは出発点です。 0.9にすれば拾う数が増え、0.98にすれば減ります。一覧の件数が担当者の手に負える数になるよう、最初の数か月で決め直します。 変えたときは、いつどの値にしたかを記録に残します。

評価には mean_pinball_loss を使います。分位点回帰のモデルを評価するための指標で、alpha に0.95を渡すと上側の見込みの評価になります。前年の同じ月を検証用に取っておき、学習に使わずに評価します。

出力形式を固定する

使用者1件ごとに、次の形で一覧に書き出します。

{
  "district": "北3",
  "reading_date": "2026-09-18",
  "customer_no": "",
  "usage_type": "家事用",
  "days": 61,
  "actual_per_day": 0.0,
  "pred_mid_per_day": 0.0,
  "pred_upper_per_day": 0.0,
  "excess_per_day": 0.0,
  "consecutive_periods": 1,
  "pattern": "spike | creeping | vacant_use | use_mismatch",
  "priority_rank": 1,
  "suggested_action": "notice | site_check | reread",
  "repair_history": "なし | 修繕届あり（日付） | 減免あり（日付）",
  "model_version": "2026-09"
}

1つ目の理由は、見込みと実績を並べて残せることです。 担当者は actual_per_day と pred_upper_per_day の差を見れば、どれだけ外れているかを履歴の画面を開かずに読めます。

2つ目は、pattern と suggested_action を分けていることです。 型は規則で決まる事実、次の手は候補です。担当者が候補と違う手を選んだときに、どの型でどの手に変えたかが残ります。

3つ目は、model_version を残すことです。 上側の分位点や学習の期間を変えると、同じ使用者でも拾われ方が変わります。後から「なぜこの月はこの使用者が拾われたか」を説明するのに必要です。

repair_history を一覧に載せるのは、担当者が料金システムの画面を開かずに済ませるためです。 前回の修繕から半年で同じ型の超過が出ていれば、修繕が不完全だったか、別の箇所で漏れているかのどちらかで、お知らせより現地確認が先になります。

一覧は担当者向けには表で出します。

システムへ連携する

料金システムには書き込みません。 減免の登録も、お知らせの発送の記録も、これまでどおり料金システムの画面で職員が行います。書き込みの経路を作らないことで、見込みの誤りが料金に届く道を最初から無くします。

委託先への依頼も、担当者が一覧から選んで渡します。 仕組みから委託先へ直接流すと、読み違いと漏水の区別が付く前に、現地へ人が向かいます。

人が確認する

担当者が見るのは、一覧の上からです。 600件をすべて同じ深さで見る必要はなく、上位は型と超過量を見て手を決め、下位は件数と地区を流し見ます。

1. 再検針の一覧を先に片付ける … 読み違いの疑いは委託先へ回すだけで、使用者への連絡はしません
2. vacant_use を確かめる … 閉栓中や空き家での使用は、漏水か無断の使用かで扱いが大きく変わるので、現地確認が基本です
3. creeping と spike の上位を決める … 修繕の記録と見比べ、お知らせか現地確認かを決めます
4. 見送ったものに理由を付ける … 「散水の季節」「事業の繁忙」など、短い理由を選択肢から選びます

4番目を省かないでください。 見送りの理由は、次の学び直しで「上側を超えても漏水でなかった」例になります。理由が残らないと、同じ使用者が毎回拾われ続けます。

目標は600件をならして1件2分です。 上位の数十件に時間を使い、残りは短く見る想定です。上位が毎月増えていくなら、上側の分位点か、学習から外す条件を見直します。

例外に対処する

上から2行が大半を占めます。 どちらも見込みの問題ではなく、検針の記録の問題です。 予測の前に分けておくことで、一覧の上位が漏水の候補で埋まります。

7行目は、静かに起きる失敗です。 書き出しが途中で切れても、一覧は「拾う使用者が少ない月」として出てしまいます。件数の比較を、予測の前に必ず通します。

記録を残す

• 地区・検針日ごとの書き出しのファイルと件数
• 使用者ごとの見込みの値（中央・上側）、超過量、型、優先順
• 担当者が選んだ手と、候補と違えた理由
• お知らせを出した日、現地確認の結果、次の検針で量が戻ったか
• モデルの版（学習の期間、分位点、学習から外した条件）と評価の値
• 再検針に回したものと、その結果（読み違いだったか）

4つ目の「量が戻ったか」が、この記録の中で最も価値があります。 お知らせの後に戻った使用者は、修繕の届出が無くても漏水だった可能性が高く、学び直しの正解の材料がここから増えていきます。

最後の行は、検針の委託先との話し合いの材料になります。 特定の地区で読み違いが続くなら、メーターの位置か、検針の手順に理由があります。