パレットのレンタル会社が出荷・返却の記録から、デポごと・パレットの種類ごとの翌月の返却の数を Python で幅を付けて見込み、洗浄の人員と回送の計画に使う

処理の起点を決める

毎月の締めの3営業日目、基幹のシステムの書き出しが決まったフォルダにそろった時点で動かします。 書き出しが終わったら「そろった」の印のファイルを置き、ジョブ管理の仕組みが15分ごとにその印を見に行きます。

月末ちょうどではなく、締めの3営業日目にするのは、返却の入庫の記録が遅れて入るためです。 返ってきたパレットは検品を終えてから入庫の記録になり、月末に届いたパレットの記録が翌月の1日や2日に入ることがあります。 入庫の記録は「入庫の受付の日」で月を決め、3営業日目までに入った前月の分を取り込みます。

見込む先は「翌月の1日から末日までに、そのデポに入庫の受付がある返却のパレットの数」です。 見込みを作るのは今月の20日の会議のためで、今月の残りの日の分は見込みません。 今月の返却は、会議の時点で半分以上が記録になっているので、担当がその数を見ます。

入力データを集める

質を決めるのは、納品先のコードのそろい方です。 荷主が出荷のときに届け出る納品先のコードが空だったり、同じセンターが別のコードで届けられていたりすると、その出荷はどのデポに返るのかが分かりません。 空の割合を荷主ごとに数え、多い荷主には届け出の決まりを営業から頼みます。

回送の記録を入れるのは、学習の正解から外すためです。 回送で入ったパレットは、返却ではありません。基幹のシステムで回送の入庫と返却の入庫が同じ種類の記録になっているなら、回送の記録と突き合わせて引き算します。 ここを誤ると、回送を多く受けるデポほど返却が多いと学ぶモデルになります。

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

基幹のシステムの画面から自動で取ってくる仕組みは作りません。基幹のシステムの定時の書き出しで、決まったフォルダに置きます。

対応表は、毎月作り直さずに半年に1回作り直します。 過去12か月の返却の入庫で、返してきた運送会社や荷主のコードから納品先を推し量れる記録を数え、納品先ごとに、どのデポに何割が返っているかを持ちます。1つの納品先から2つのデポに分かれて返るなら、出荷を割合で分けます。作り直したときは、作った月を対応表に残します。

対応表に無い納品先の出荷は、警告として数えます。 新しく開いた物流センターへの出荷は、どこに返るかの記録がまだありません。その出荷は「返却先不明」としてデポに振らず、 本部の需給の担当がデポの担当と相談して対応表に足します。

AIへ渡す前に整形する

1. 回送を除く … 返却の入庫から、同じ日・同じデポ・同じ種類の回送の入庫を引きます
2. 出荷をつなぎ直す … 対応表で、出荷を返却先のデポに割り振ります。対応表に無い納品先は「返却先不明」に積みます
3. 時点をそろえる … 特徴はすべて「前月末の時点」で作ります。3営業日目までに入った前月の入庫は前月に入れ、当月の入庫は入れません
4. 特徴を作る … 返却先のデポ別の出荷の数（1か月前・2か月前…6か月前を別々の列で）、前月の返却、前年の同じ月の返却、前年の同じ月の翌月の返却、翌月の営業日の数、荷主の新規・終了・移転の印と効力の月からの月数、デポ、種類、月
5. 新しいデポ・種類を分ける … 記録が12か月に満たないデポと種類は、モデルに渡さず「記録不足」にします
6. 行を並べる … 月の順に並べ、同じ月の中はデポと種類の順にします

4番目で出荷を1か月ごとの別の列にするのは、返るまでの日数が荷主と納品先で違うからです。 飲料のように納品先ですぐ空になる荷主は1か月前の出荷が効き、倉庫で長く保管される荷物の荷主は3か月前、4か月前の出荷が効きます。 どの月の出荷がどれだけ効くかは、モデルに学ばせます。

2番目で1つの納品先を2つのデポに割合で分けた出荷は、端数が出ます。 枚数の特徴は小数のまま持ち、見込みの表に出すときだけ整数に丸めます。 途中で丸めると、小さなデポで割合の小さい出荷が毎月0枚になって消えます。

AIに処理させる

させるのは、デポごと・種類ごとに「翌月の返却の数」を3つの見込みで出すことだけです。 学習には、過去3年分の毎月末の時点の特徴と、その翌月の返却の数を使います。

4行目は、この記録だからそのまま使えます。 公式の説明では、TimeSeriesSplit は時間の順に並んだ記録を行の位置で分けるもので、分け目ごとの成績を比べるには記録が等しい間隔で並んでいる必要があるとされています。この記録は毎月30デポ × 8種類の240行で、月ごとの行の数が同じです。 前処理の6番目で月の順に並べ、test_size を240の倍数にすれば、分け目が月の境目に重なります。新しいデポを足して1か月の行の数が変わったら、月の境目で自分で分ける作りに替えます。

確かめ方は、見込みの種類ごとに分けます。 中央の見込みは、公式の説明のある mean_poisson_deviance で測ります。この指標は見込みの値が0より大きいことを求めます。 'poisson' の損失は対数のつなぎを使うので見込みは正の値になり、そのまま測れます。上側と下側の見込みは mean_pinball_loss で、alpha をそれぞれ0.9と0.1にして測ります。公式の説明では、alpha=0.95 のときは95％点の見込みで最も小さくなるとされ、見込んだ％点と同じ alpha で測るのが筋です。

もう一つ、確かめる月ごとに「実際の数が上側と下側のあいだに入った割合」を数えます。 10％点と90％点なら、おおむね8割が入るはずです。大きく下回るなら、幅が狭すぎて計画の材料になりません。

早めに止める見張りは、既定のままにしないでください。 公式の説明では、early_stopping の既定は 'auto' で、件数が1万件を超えるか、X_val と y_val を fit に渡すと有効になります。 3年分の240行は1万件に届かないので、何もしなければ見張りが効きません。直近の月を X_val・y_val として渡し、見張りを効かせます。

指示内容を固定する

この構成は生成AIを使わないため、プロンプトはありません。 代わりに、つなぎ直し・学習・見込みの表の作り方を決める設定を、ひとつのファイルにまとめます。

【見込む先】
target: 翌月1日〜末日に、デポに入庫の受付がある返却の枚数（回送の入庫は除く）
as_of: 前月末（締めの3営業日目までに入った前月の入庫を含む）
unit: デポ × パレットの種類 × 月

【つなぎ直し】
mapping_table: 納品先 → 返却先のデポ（割合つき。半年ごとに作り直す）
on_unknown_destination: 「返却先不明」に積み、デポに振らない（推測で近いデポに寄せない）

【モデル】
median: HistGradientBoostingRegressor(loss="poisson", categorical_features="from_dtype")
upper:  HistGradientBoostingRegressor(loss="quantile", quantile=0.9)
lower:  HistGradientBoostingRegressor(loss="quantile", quantile=0.1)
validation: 直近2か月を X_val / y_val として fit に渡す
cv: TimeSeriesSplit(test_size=240 の倍数)。月ごとの行の数が変わったら月の境目で分ける
指標: median は mean_poisson_deviance、upper/lower は mean_pinball_loss(alpha=0.9 / 0.1)
学習期間: 直近36か月

【見込みの表】
- 中央・上側・下側を並べ、前年の同じ月・前月・3か月前に出した見込みとの差を付ける
- 上側が下側より小さくなったら、上側を中央の見込みにそろえ「幅の逆転」と付ける
- 中央の見込みが前年の同じ月から30％以上動いたら印
- 記録が12か月未満のデポ・種類は見込みを出さず「記録不足」

「推測で近いデポに寄せない」を設定に書くのは、新しい納品先の出荷を地図の上で近いデポに振りたくなるからです。 実際には、運送会社の帰りの便の都合で、近くないデポに返ることがあります。寄せた出荷が外れると、2つのデポの見込みが同時に外れます。

上側と下側を別々に学ばせると、まれに上側が下側より小さくなります。 そのまま表に出すと担当が迷うので、機械的に直して印を付けます。

出力形式を固定する

見込みの表は表で出し、同じ内容を JSON でも残します。 表は担当が読むため、JSON は翌月の振り返りのためです。

{
  "as_of": "2026-09-30",
  "target_month": "2026-11",
  "model_version": "pallet-return-2026-09",
  "mapping_version": "2026-07",
  "unknown_destination_shipments": 1840,
  "rows": [
    {
      "depot": "D-12",
      "pallet_type": "P-03",
      "median": 18400,
      "lower_10": 16900,
      "upper_90": 20600,
      "last_year_same_month": 17200,
      "last_month_actual": 18900,
      "forecast_3_months_ago": 17800,
      "flags": ["big_change | interval_inverted | insufficient_records | none"],
      "override": { "value": null, "reason_code": "" }
    }
  ]
}

mapping_version を残すのは、どの版の対応表で出荷をつなぎ直したかを後から追うためです。 対応表を作り直した月に見込みの当たり方が変わったら、それが対応表のせいか、荷主の動きのせいかを分けられます。

override は、デポの担当が上書きしたときの値と理由のコードです。 「荷主の新しいセンターが翌月から動く」「大口の荷主の出荷が止まる」のように、記録にまだ出ていない事情を選ぶ形にします。

システムへ連携する

見込みの表は、会議の後に固めます。 担当の上書きが入った版を、計画に使った版として日付を付けて残します。 翌月の振り返りでは、モデルの見込みと、上書きの後の数の両方を実際と比べます。

見込みを基幹のシステムに取り込みたくなったら、上書きの後の数だけを取り込みます。 モデルの見込みをそのまま入れると、担当が上書きした事情が計画の数から消えます。 取り込むかどうかは、半年ほど振り返りを回してから決めます。

人が確認する

1. 返却先不明の出荷の数 … 前月より大きく増えていたら、新しい納品先がある。対応表に足してから見込みを使います
2. 印の付いたデポと種類 … 前年の同じ月から大きく動いたもの、幅の逆転、記録不足。営業の情報と照らします
3. 上書きの理由を書く … 上書きしたときは値と理由のコードを入れます。理由の無い上書きはしません
4. 全体の釣り合い … 本部の需給の担当が、30デポの中央の見込みの合計を、全体の出荷の動きと見比べます

目標は、240件をならして1件4分です。 上の4つに入るものだけを記録と照らし、残りは見込みの表で流し見ます。

1番目を省かないでください。 返却先不明の出荷は、どのデポの見込みにも入っていません。数千枚が不明のまま会議に出ると、どこかのデポで見込みを大きく超える返却が来ます。 不明の出荷の納品先を上から10件見るだけで、多くは新しく動き始めたセンターだと分かります。

例外に対処する

最後の行は、見込みと実際の比べ合わせのときにも効きます。 物流が止まった月の返却は、翌月にまとめて返ってきます。その2か月をそのまま学ぶと、普段の月の動きがゆがみます。

記録を残す

• 月ごとの書き出しの件数、返却先不明の出荷の数、回送として引いた枚数
• 対応表の版（いつ作り直し、どの納品先を足したか）
• モデルの版、学習・確かめに使った月、確かめた結果（中央の見込みの指標、上側と下側の指標、幅に入った割合）
• 見込みの表の JSON の全文と、会議に出した版
• デポの担当が上書きした値と理由のコード
• 翌月の実際の返却の数と、モデルの見込み・上書きの後の数との差

最後の行が、上書きが役に立っているかを知る材料になります。 上書きの後の数がモデルより当たっていれば、その理由のコードの事情を記録として足すことを考えます。外れていれば、その理由での上書きをやめる目安になります。