自社便の配送で、当日の積込・走行・配達の記録から配送先ごとの到着時刻を見込み、遅れそうな配送先へ事前の連絡文を作る

処理の起点を決める

積込完了の時点と、8時から18時までの30分ごとに回します。 積込完了の時点の見込みは、その日の最初の連絡に使います。出庫前に「今日は遅れる」と分かる配送先は、朝のうちに連絡します。

30分ごとの回は、便ごとに最新の記録だけで見込みを作り直します。 配達完了の記録が入るたびに回す形も考えられますが、25台が1日に数百件の完了を記録するので、30分ごとにまとめたほうが、見込みの揺れが落ち着きます。 回すたびに結果を上書きせず、時刻付きで残します。

入力データを集める

質を決めるのは、2行目の「配送先ごとの到着と配達完了の時刻」です。 到着から完了までが荷受けにかかった時間で、これが配送先ごとに大きく違います。 工事現場は職人を呼んでくるまで待ち、ホームセンターは検品の列に並びます。到着と完了の両方を押す運用になっていなければ、最初にそこを直します。

3行目の過去の荷受けの時間は、配送先ごとの中央値と、ばらつきの大きさで持ちます。 「平均20分」の配送先でも、10分の日と50分の日が混ざっていれば、遅めの見込みが大きく変わります。

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

配車システムから当日の便を、車載端末の管理画面から位置と配達の記録を、それぞれCSVかAPIで取り、Python の pandas で読み込みます。どの形で取れるかは製品ごとに違うため、最初に、配達完了の記録が何分遅れで取れるかを確かめます。 1時間遅れでしか取れないなら、30分ごとに回す意味がありません。

Routes API は、残りの配送先を順番に結んだ区間ごとに呼びます。 今の位置から次の配送先、次から次へと区間を並べ、duration を足していきます。1台あたり残り十数区間で、30分ごとに25台分なので、呼ぶ回数と料金を最初に見積もります。 混み具合を考える設定は料金が高い区分なので、夕方以降に残りが数件になった便から、呼ぶ間隔を広げます。

AIへ渡す前に整形する

1. その時点の状態を作る … 便ごとに、最後に配達を終えた配送先、今の位置、残りの配送先の並びを作ります
2. 遅れの積み上がり … ここまでの配送先で、予定よりどれだけ遅れているか（分）を出します
3. 走行の時間 … 残りの配送先ごとに、今の位置からその配送先までの duration の合計と staticDuration の合計を出します
4. 荷受けの時間 … その配送先より前にある配送先の、過去の荷受けの時間の中央値の合計を出します
5. 時刻の特徴 … 曜日、その時点の時刻、月末か、雨か（気象の記録を取り込む場合）を加えます
6. 欠けた値の扱い … 初めての配送先の荷受けの時間、位置が途切れた時間帯は、0で埋めずに NaN のまま渡します
7. 目的の値 … 「その時点から、その配送先に実際に着くまでの分数」を目的の値にします

学習用のデータは、過去の便を30分ごとの時点で切って作ります。 同じ便の同じ配送先について、9時の時点、9時30分の時点、……の行ができ、それぞれに「その時点で分かっていたこと」だけを入れます。その時点より後の配達完了の記録を混ぜると、学習では当たるのに本番では外れるモデルになります。 時刻で切る処理を必ず入れます。

7番目を「到着の時刻」ではなく「その時点からの分数」にするのは、時刻のままだと朝の便と午後の便で値の大きさがまったく違うからです。 分数にしてから、その時点の時刻に足して到着の見込みに戻します。

AIに処理させる

この構成の「AI」は2つの部品に分かれます。 到着の見込みを出すのが機械学習のモデル、連絡文を整えるのが生成AIです。生成AIは時刻を作りません。

遅めの見込みに90％点を使うのは、「10回に1回はこれより遅くなる」ラインだからです。 公式ドキュメントでは、loss='quantile' はピンボール損失を使い、quantile で推定する分位点を0から1の間で指定するとされています。中央値（0.5）と90％点（0.9）で、モデルを2つ学ばせます。

2つのモデルの見込みが逆転することがあります。 別々に学ばせるので、まれに90％点の見込みが中央値より早く出ます。その場合は90％点を中央値にそろえ、記録に印を付けます。 印が増える配送先は、学ぶ材料が足りていません。

単調の制約も入れます。 公式ドキュメントでは、monotonic_cst で特徴ごとに単調増加（1）・単調減少（−1）を指定できるとされています。残りの走行時間と、前にある配送先の数は、増えれば到着が遅くなる向きに縛ります。 縛らないと、データの少ない範囲で「配送先が増えたのに早く着く」見込みが出ることがあります。

学び直しの成績は、時間の順に分けて測ります。 公式ドキュメントでは、TimeSeriesSplit は時間順のデータを分けるもので、ほかの分け方は未来のデータで学習して過去を評価することになり不適切とされています。

指示内容を固定する

モデルの設定は次のとおりです。 学習は月1回、見込みは30分ごとに回します。

import numpy as np
from sklearn.ensemble import HistGradientBoostingRegressor

common = dict(
    categorical_features="from_dtype",       # 配送先の種類・曜日は Categorical 型
    monotonic_cst={"remaining_drive_min": 1, # 残りの走行時間が増えれば遅くなる
                   "stops_before": 1},       # 前にある配送先が増えれば遅くなる
    max_iter=400, learning_rate=0.05,
)
p50 = HistGradientBoostingRegressor(loss="quantile", quantile=0.5, **common)
p90 = HistGradientBoostingRegressor(loss="quantile", quantile=0.9, **common)
p50.fit(X_train, y_train)                    # y はその時点から到着までの分数
p90.fit(X_train, y_train)

eta50 = now + p50.predict(X_now)             # 普通の見込み
eta90 = now + np.maximum(p90.predict(X_now), p50.predict(X_now))  # 逆転をそろえる

判定は、時間指定の終わりと2つの見込みを比べるだけにします。 普通の見込みが過ぎれば late_likely、遅めの見込みだけが過ぎれば late_risk、どちらも過ぎなければ on_time です。判定を生成AIに任せないのは、同じ見込みから毎回同じ答えが出る必要があるからです。

連絡文の下書きは、Claude API に次の指示で作らせます。

あなたは建築資材の卸の配車係で、時間指定のある配送先へ、到着の見込みを事前に知らせる
連絡文を書く立場です。渡された情報だけを使って、電話で伝える要点とSMS・メールの本文を
作ってください。

【渡す情報】
- 配送先の名前（会社名と現場名）、時間指定（例：10:00まで）
- 到着の見込み（普通の見込みと遅めの見込み。Python が出した時刻）
- 判定（late_likely または late_risk）
- 自社の名前と、配車係の連絡先

【書き方】
- 到着の見込みは「◯時◯分ごろから◯時◯分ごろ」と、渡された2つの時刻の幅で書いてください。
- late_likely の場合は、時間指定に間に合わない見込みであることをお詫びとともに伝えてください。
- late_risk の場合は、時間指定ぎりぎりになるおそれがあることを伝えてください。
- 受け取りの段取りに差し支えがあれば連絡がほしいと書き、連絡先を添えてください。
- 電話の要点は3行以内、SMSの本文は120字以内にしてください。

【厳守事項】
- 時刻を書き換えないでください。丸める場合は5分単位で、遅い側へ丸めてください。
- 遅れの理由（渋滞、前の配送先、天候 など）を書かないでください。
- 「必ず」「確実に」など、到着を約束する表現を使わないでください。
- 渡された配送先以外の会社名や、荷の中身を書かないでください。
- 渡された情報が足りない場合は、文面を作らず missing に足りない項目を書いてください。

【配送先と見込み】{stop}
【自社の情報】{company}

「遅れの理由を書かない」を明記しないと、生成AIは丁寧に理由を足します。 「道路の混雑により」と書かれた連絡を受けた配送先は、本当の理由が前の配送先での待ちだったと後で知ると、連絡そのものを信じなくなります。

出力形式を固定する

次の形のJSONを、残りの配送先ごとに作ります。 時刻と判定は Python が埋め、draft を Claude API の構造化出力（output_config.format に type: "json_schema"）で受け取ります。

{
  "run_at": "2026-10-07T09:30:00+09:00",
  "route_id": "R-07-12",
  "stop_seq": 6,
  "stop_id": "C-20418",
  "window_end": "2026-10-07T11:00:00+09:00",
  "eta_p50": "2026-10-07T10:52:00+09:00",
  "eta_p90": "2026-10-07T11:18:00+09:00",
  "delay_so_far_min": 14,
  "status": "late_risk",
  "flags": ["first_visit"],
  "draft": { "phone_points": "", "sms": "", "missing": [] },
  "contacted": null
}

1つ目の理由は、時刻と文面を別の欄に置けることです。 配車係が見るのは eta_p50 と eta_p90 で、draft はそれをもとに作った文です。下書きの時刻が eta_p90 と食い違っていないかを、送る前に Python で照合します。

2つ目は、run_at で見込みの動きを追えることです。 同じ配送先の見込みが、9時、9時30分、10時と、どう動いたかを並べて見られます。遅れの見込みが急に跳ねたら、前の配送先で何か起きています。

3つ目は、flags で見込みの確からしさを伝えられることです。 first_visit（初めての配送先）、gps_gap（位置が途切れている）、order_changed（配送順が予定と違う）のような印があれば、配車係はその見込みを割り引いて読みます。

システムへ連携する

配送先への連絡は、この構成から自動で送りません。 配車係が下書きを確かめ、電話するか、SMSやメールで送ります。遅れの連絡は取引先との関係に直接ひびくので、送る判断は人に置きます。

ドライバーへは、この構成から何も送りません。 運転中のドライバーに通知を送ると、画面を見る理由を作ってしまいます。ドライバーへの指示が要るときは、いままでどおり配車係が判断して連絡します。

人が確認する

人が開くのは、late_likely と late_risk の配送先だけです。 on_time のものは、一覧の色で流し見るだけにします。

1. late_likely を先に見る … 下書きを確かめ、配送先へ連絡します。連絡した時刻と、相手の返事を記録します
2. late_risk は時間指定の近い順に見る … 立会いの要る配送先は連絡し、置き場所の決まった配送先は様子を見ます
3. flags の付いた見込みは割り引く … 位置が途切れているなら、ドライバーに1回だけ確かめます
4. 配送順の入れ替えや応援の車は、配車係が決める … この構成は、入れ替えた後の見込みを出しません

目標は、1,800件をならして1件1分です。 遅れのおそれのある配送先は1割前後という想定で、それより多い日は、積込の遅れか、時間指定の付け方に無理があります。

例外に対処する

6行目は、見込みを出し続けることのほうが危ないものです。 止まっている車の見込みは、走行の時間を足すほど現実から離れます。故障の連絡が入った便は、人が判断するまで一覧から外します。

記録を残す

• 30分ごとの見込み（eta_p50・eta_p90）と判定、そのときの位置と残りの配送先
• 呼んだ Routes API の区間と、返ってきた duration・staticDuration
• 下書きと、配車係が直した後の文面、連絡した時刻と手段
• 見込みと実際の到着の差 … 配送先ごと、時刻ごと
• 学び直しの日付と、そのときの成績（中央値の誤差、90％点を超えた割合）

4つ目の差は、90％点が本当に「10回に1回」になっているかを見るために要ります。 実際の到着が90％点を超えた割合が1割を大きく超えるなら、遅めの見込みが甘く、遅れを見落としています。