配送の実績記録から配送先・時間帯・曜日ごとの所要時間を予測し、翌日の配車計画の到着予定に入れる

処理の起点を決める

見込みは2つの時点で動かします。 1つは毎日深夜の実績の取り込みで、前日の車載端末の書き出しを読み、学ぶための表を更新します。もう1つは、配車担当が便の順番を決めて、配車システムから便の表を書き出したときです。

便の表の書き出しは、共有フォルダへの保存で検知します。 保存されたら Python のスクリプトが動き、1〜2分で到着予定の表と確認の一覧を同じフォルダに返します。配車担当は、便を何本か決めるたびに書き出してよく、全便がそろうのを待ちません。 締めの直後に集中する作業を、決まった便から順に流すためです。

モデルの学び直しは週1回、日曜日の深夜です。 前の週までの実績で学び直し、検証の成績が前のモデルより下がっていなければ入れ替えます。

入力データを集める

質を決めるのは、実績の記録の「到着」と「作業開始」が分かれているかどうかです。 到着してから荷受けが始まるまでの待ちが、配送先の癖のいちばん大きな部分です。到着と出発しか無いと、待ちと荷降ろしを分けられません。 車載端末の操作で「到着」「作業開始」を押してもらうよう、ドライバーと決めておきます。

荷主の特売の前日の印は、量販店のセンターの作業時間に効きます。 荷主から届く販促の予定を、日付と荷主の表にしておきます。

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

区間とは、1つ前の配送先（最初は営業所）を出てから次の配送先に着くまでです。 実績の記録を、便の順番で並べて「前の配送先の出発」と「次の配送先の到着」の差を走行時間とし、途中に休憩の記録があればその時間を引きます。

作業時間は、到着から出発までです。 そのうち到着から作業開始までを「待ち」として別の列に持ち、一覧で配送先ごとの待ちの長さを見られるようにします。

実績の配送先と、配車システムの配送先を同じ番号で結びます。 車載端末では配送先を位置か名前で記録していることが多く、配車システムの配送先の番号と一致しないことがあります。 最初に対応の表を作り、対応のつかない記録は学ぶ対象から外して、件数を配車担当に返します。ここが合っていないと、別の配送先の作業時間で見込むことになります。

便の表は、書き出しのたびに全便を読み直します。 配車担当が順番を直して書き出し直したときに、古い順番の見込みが残らないよう、同じ便の前回の結果は上書きし、前回の内容は保存・ログの側に残します。

AIへ渡す前に整形する

1. 区間を作る … 実績を便の順番で並べ、前の配送先の出発から次の到着までを1区間にします。営業所の出発から最初の配送先、最後の配送先から帰庫までも区間にします
2. 休憩を引く … 区間の途中にある運転の中断を、走行時間から引きます。引いた休憩の時間は別の列に残します
3. 外れた記録を外す … 押し忘れで到着と出発が同じ時刻、作業時間が数時間を超える、といった記録は学ぶ対象から外します。外した割合を配送先ごとに数えます
4. 材料をそろえる … 区間には、前後の配送先、出発の時間帯（30分刻み）、曜日、祝日の前後、走行距離、車格を付けます。作業時間には、配送先、到着の時間帯、曜日、個数、重量、特売の前日の印を付けます
5. 件数の少ない配送先をまとめる … 過去1年で実績が20回に満たない配送先は、荷受けの場所の種類ごとの「その他」にまとめます
6. 答えを付ける … 走行時間と作業時間を、分の単位の数にします

3番目を軽く見ないでください。 押し忘れの記録を混ぜると、作業時間が0分の日と数時間の日が混ざり、遅めの見込みが大きく振れます。 外した割合が多い配送先は、ドライバーの操作の決まりを見直す材料にします。

5番目の「その他」は、学び直しのたびに入れ替わります。 実績が20回を超えた配送先は、その回から自分の名前の区分で学びます。新しく取引の始まった配送先は、最初の1か月ほど new_stop の印が付き続けることになります。

4番目で、出発の時間帯は見込む区間ごとに変わります。 積み上げの途中で、前の区間の到着予定から次の区間の出発の時間帯が決まるので、区間を1つずつ順に見込みます。

AIに処理させる

させるのは、区間の走行時間と配送先での作業時間を、普通の場合と遅めの場合で見込むことだけです。 到着予定の積み上げと照合は、決まった計算で行います。

遅めの到着予定は、遅めの見込みを単純に足し上げません。 各区間で「遅めの見込み − 普通の見込み」を出し、その2乗の和の平方根を、普通の見込みの積み上げに足します。 区間ごとの遅れが毎回そろって起きるわけではないとみなした近似で、単純に足すと、後ろの配送先ほど遅めの予定が大きくなりすぎるためです。この近似が合っているかは、実績で確かめます（第7章の人間の確認と保存・ログ）。

拘束時間と連続運転は、目安として照らすだけです。 トラック運転者の改善基準告示では、1日の拘束時間は13時間を超えないものとし、延長する場合でも最大15時間とされています。連続運転時間は4時間を超えないものとされ、運転の中断は1回がおおむね10分以上、合計30分以上です。見込みの帰庫の時刻から拘束時間の見込みを出し、13時間を超える便と、休憩を入れないと連続運転が4時間を超える便に印を付けます。

3行目を最初に決めておいてください。 見込みの拘束時間は、到着予定の見込みから出した目安です。改善基準告示を守れているかの判断は、実際の勤務の記録で運行管理者が行います。 この構成の印は、前日のうちに無理のある便に気づくためのものです。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、モデルと積み上げと照合の設定を書いておきます。

【モデル（4つ）】
- 走行・普通：HistGradientBoostingRegressor(loss="quantile", quantile=0.5)
- 走行・遅め：HistGradientBoostingRegressor(loss="quantile", quantile=0.8)
- 作業・普通：同上 quantile=0.5
- 作業・遅め：同上 quantile=0.8
- categorical_features = ["前の配送先", "次の配送先", "曜日", "車格"]（走行）
                         ["配送先", "曜日", "荷受けの種類"]（作業）
- monotonic_cst = {"個数": 1, "重量": 1}（作業のモデルだけ）
- 欠けた値は埋めずに渡す
- 検証：TimeSeriesSplit(n_splits=5)（日付の順に並べてから分ける）

【積み上げ】
- 到着予定（普通）＝ 出発の時刻 ＋ これまでの区間の走行（普通）と作業（普通）の和
- 遅めの上乗せ ＝ √（各区間の（遅め − 普通）の2乗の和）
- 到着予定（遅め）＝ 到着予定（普通）＋ 遅めの上乗せ
- 次の区間の出発の時間帯は、前の配送先の出発予定（普通）で決める
- 休憩は、配車担当が便の表に入れた位置と長さをそのまま使う

【照合と印】
- late_risk：到着予定（遅め）が指定時間の枠の終わりを過ぎる
- early_risk：到着予定（普通）が枠の始まりより 30 分以上早い
- long_duty：始業から帰庫（遅め）までが 13 時間を超える
- drive_4h：休憩を挟まずに走行（普通）の和が 4 時間を超える区間の並びがある
- new_leg ／ new_stop：実績が 20 回に満たない区間・配送先を含む
- 到着予定の時刻は 5 分単位に丸めて取り込む（照合は丸める前の値で行う）

early_risk を入れているのは、早すぎる到着も配送先で待ちになるためです。 量販店のセンターは枠より前に着いても荷受けが始まらず、早く着いた分は拘束時間が延びるだけです。 出発を遅らせられる便を見つける材料になります。

「照合は丸める前の値で行う」を明記しないと、5分の丸めで枠の境目の便が見落とされます。 9時の枠の終わりに対して8時58分の見込みを9時に丸めて照らすと、間に合う便と間に合わない便の区別がつかなくなります。

出力形式を固定する

便ごとに、次の形のJSONを作り、配車システムへの取り込み用の表と確認の一覧にします。

{
  "route_id": "",
  "date": "",
  "depart_at": "",
  "flags": ["late_risk", "early_risk", "long_duty", "drive_4h", "new_leg", "new_stop"],
  "duty_hours_p80": 0.0,
  "stops": [
    { "seq": 1, "stop_id": "", "window": "08:00-09:00",
      "eta_p50": "", "eta_p80": "", "drive_min_p50": 0, "work_min_p50": 0,
      "wait_min_hist": 0, "flags": [] }
  ],
  "model_version": ""
}

1つ目の理由は、eta_p50 と eta_p80 を並べられることです。 配車システムの到着予定には eta_p50 を5分単位に丸めて入れ、確認の一覧には2つを並べて、遅めの予定がどれだけ枠に食い込むかを見せます。

2つ目は、drive_min_p50 と work_min_p50 と wait_min_hist で遅れの理由を分けられることです。 枠に遅れそうな配送先について、走行が長いのか、その前の配送先の作業が長いのか、待ちが長いのかが分かれば、順番を変えるか、出発を早めるか、荷主と相談するかを選べます。

3つ目は、flags を便と配送先の両方に持てることです。 便の一覧では印の付いた便だけを並べ、開いた便の中で、どの配送先に印が付いたかをすぐに見つけられます。

システムへ連携する

配車システムへの取り込みは、配車担当が操作します。 スクリプトが直接書き込むことはしません。確認の一覧を見て直した便は、直してから取り込みます。 書き込みを自動にすると、確認する前の到着予定が荷主に共有されることがあります。

車載端末の実績は読み取りだけです。 実績の記録は運行の記録として残すものなので、押し忘れの直しは車載端末の側の手順で行い、この構成の中では直しません。

人が確認する

人が開くのは、印の付いた便だけです。 45便のすべてを1か所ずつ見直す設計にすると、第10章の30.0時間には収まりません。

1. late_risk を先に見る … 遅めの予定が枠を過ぎる配送先です。順番を入れ替えるか、出発を早めるか、荷主に枠の相談をするかを決めます
2. long_duty と drive_4h を見る … 運行管理者として、休憩の位置と、便の分け方に無理が無いかを確かめます
3. new_leg と new_stop を見る … 実績の少ない区間と配送先は見込みの幅が大きくなります。ドライバーに荷受けの様子を聞いた担当が、時刻を直します
4. early_risk を見る … 出発を遅らせられる便があれば直します
5. 時刻を直したら記録する … どの配送先の時刻を、どちらへ何分直したか、理由を残します

5番目を省かないでください。 担当が直した時刻と、翌日の実績を並べると、人の直しが当たったのか、モデルの見込みのほうが近かったのかが分かります。人の直しが続けて当たる配送先は、モデルが見ていない事情があるということです。

月に1回、遅めの予定を実績が超えた割合を数えます。 0.8の分位点で見込んでいるので、超えた割合が2割前後なら見込みは合っています。 3割を超える配送先があれば、その配送先の材料が足りていません。

例外に対処する

上から4行目までが大半を占めます。 どれもモデルの問題ではなく、実績の付け方とマスタの整備の問題です。 直すほうが、モデルを作り直すより効きます。

6行目は、この構成の限界です。 過去の実績だけを材料にしているので、翌日だけ起きる道路の事情は見込みに入りません。 分かっている工事や行事は、配車担当が直す前提で運用します。

記録を残す

• 毎日の見込みの結果（便ごとの JSON）と、そのときのモデルの版
• 配車担当が直した時刻と理由
• 翌日の実績の到着・作業開始・出発と、見込みとの差
• 配送先ごとの、遅めの予定を実績が超えた割合（月ごと）
• 学び直しのたびの検証の成績
• 実績から外した記録の数と、配送先ごとの割合

3つ目の「見込みとの差」が、この構成のいちばん大事な記録です。 配送先ごとに差を並べると、見込みがいつも短い配送先、曜日によって外れる配送先が分かります。荷主との時間の相談の材料にもなります。

4つ目の割合は、第7章の人間の確認で月1回見るものです。 割合の推移を残しておくと、学び直しで見込みが良くなったのか悪くなったのかを追えます。