定期巡回型回収業務における配車設計

1問題設定と三つの問題

対象とする業務は、多数の顧客拠点を定期的に巡回し、資源物を回収して処理施設へ運搬する事業である。規模は、稼働拠点が数百、車両が十台弱、巡回コースが曜日×地区の組み合わせで数十本という水準にある。この規模は、大手物流事業者向けの配送計画システムを導入するには小さく、しかし人手の勘だけで最適性を担保するには大きい、という中間帯にある。

計画は月次で更新される表計算ファイルとして存在する。地区ブロックと曜日の組で識別されるコースがあり、各コースに回収拠点が順序付きで列挙される。この表が唯一の計画表現であり、実績は長らく紙の伝票としてのみ残っていた。

1.1検討に用いるモデルケース

以降の議論は、次のパラメータを持つモデルケースを前提に進める。実在の事業を記述したものではなく、各手法の適否が規模のどこで切り替わるかを見るための、統制された設定である。数値は単一営業所として運用しうる規模の上限側に置いてある——本節冒頭で描いた車両十台前後の事業の、およそ倍にあたる。下限側ではなく上限側を採るのは、標本量に依存する手法（階層ベイズ、方策学習）がどこで成立し始めるかを見るのが目的だからである。これより小さい規模では成立しない手法があることは、その都度明示する。

この設定を選ぶ理由は二つある。第一に、k ≈ 300 は拠点別の係数が識別可能になる水準であり(7.3)、統計モデルの選択肢が最も広がる点にあたる。第二に、D が3年に及ぶことで気象と季節の交絡が解ける。これより小さい規模では、本稿の後半で論じる手法の多くが標本の制約で成立しない。逆にこれより大きい規模では、単一営業所の配車という問題設定自体が複数拠点の階層問題に変わる。

なお、入力は専用のアプリケーションを通じて行われ、マスタは正規化されているものとする（第2節）。

1.2設計を規定する三つの性質

この問題群には、設計を規定する三つの性質がある。いずれも仕様書やコードからは導けず、実績を集計して初めて可視化される種類のものである。本節ではこれらを一般的な性質として述べ、以降の節はこの三点を前提に構成される。

性質1 — 訪問先は計画どおり、訪問順序は計画と乖離する。 計画表に列挙された拠点はほぼ確実に消化される。一方、実際に回る順序は計画表の記載順と体系的にずれる。両者の順位相関を曜日ごとに測ると、ほぼ一致する曜日と、ほぼ逆順に回る曜日とが同居しうる。すなわち計画表は「回る場所の集合」としては正確だが、「回る順序」としては形骸化している。順序は各乗務員の経験として保持されており、そこには渋滞傾向・搬入口の開放時刻・積載の積み下ろし順といった、表に書かれていない知識が織り込まれている。

性質2 — 担当の交代が日常的に発生する。 計画表の担当欄に記載のない乗務員が恒常的に稼働し、担当コースを相互に代走することも珍しくない。人員配置は月次の計画表より速く変動するため、計画表の担当欄は、実績を突合するための鍵として信頼できない。

性質3 — 実績にコース識別子が残らないと、計画と実績を突合できない。 入力画面でドライバーがコースを選択していても、その選択値が実績レコードに保存されていなければ、後から曜日と担当者で推定するほかない。性質2により代走が常態である以上この推定は破綻し、実績の相当部分がコースに紐づけ不能となる。

1.3三つの問題

本稿は配車の設計を三つの問題に分解する。三者は目的も道具も評価基準も異なり、混同すると設計を誤る。以降の構成はこの分解に従う。

接続は直列である。予測が供給する蓄積量の分布を、最適化がそのまま消費する。そして転移問題は、その両者を経験していない土地へ持ち出せるかを問う——外部の地図から任意の拠点対の所要時間が得られる以上、走行実績の欠如は障害ではなく、実績が担うのは一般的な所要時間と自社の実所要時間との残差の学習である。同様に、新規拠点の蓄積速度は識別子ではなく属性から予測する。

第三の問題を独立に立てる理由は、それが他の二つの検証方法を変えるからである。既存の運用への当てはまりを測るなら日で分割すれば足りるが、新規地域への転移を測るなら地域を丸ごと保留して分割しなければならない——日分割では同じ拠点・同じ区間が訓練側と検証側の双方に現れ、測っているのは記憶であって一般化ではない。この違いは第14節で改めて扱う。

2データモデル — 計画・実績・派生の三層

配車最適化の文脈でデータモデルを設計する際、最も陥りやすい誤りは、計画テーブルに実績を上書きしてしまうことである。「予定どおりに回れたか」を後から問えなくなり、第1節で述べた性質1のような知見は永久に得られない。計画と実績は別テーブルとして保持し、両者を突合する第三の層——派生テーブル——を明示的に置く。

2.1実績テーブルの設計要件

実績テーブルは最も慎重に設計されなければならない。理由は単純で、記録されなかったデータは後から復元できないからである。機能は後から追加できるが、欠測は取り返しがつかない。最低限、以下の列を初期段階から持つべきである。

course_no

その作業がどのコースの遂行として行われたか。性質3が示すとおり、これが無いと代走日の突合が不可能になる。入力画面でコースを選択させているなら、その値を必ず実績側にも保存する。

work_start_time / work_end_time

作業の開始・終了時刻。連続する実績の時刻差から拠点間所要時間を導出するため、これが所要時間行列の唯一の情報源となる。端末入力での記録率は9割を超えうる項目であり、運用が定着すれば所要時間の推定に足る精度が得られる。

lat / lng / gps_accuracy

送信時点の測位結果。「回収したその場で送信する」という運用ルールを定めれば、この値は実質的に拠点座標そのものとなり、別途のジオコーディングが不要になる。技術的な補正機構を作るより、運用ルールを一行定める方が確実である。

item_id / quantity

品目を分けて記録する。品目マスタが貧弱だと、現場は複数品目の内訳を備考欄の自由記述に書き込むようになり、数量が集計に乗らなくなる。これは品目マスタの不足が必ず引き起こす帰結である。

is_spot

定期回収か臨時(スポット)回収かの区別。事後に判別する手段がないため、記録しなかった期間の区別は永久に失われる。請求にも配車分析にも影響する。

2.2計画層の版管理

計画表は月次で更新される。取り込みのたびに計画テーブルを全削除・再作成する実装は簡明だが、翌月分を取り込んだ瞬間に前月の計画が消える。計画対実績の比較を月をまたいで行えなくなり、コース改定の効果測定も不可能になる。主キーを(適用月, コース番号)とし、履歴を保持すべきである。

2.3派生層 — 所要時間行列

派生層の中核は拠点間所要時間である。同一ドライバー・同一日の連続する実績レコードの時刻差から算出する。

-- 連続する実績から区間所要時間を集計する
WITH seq AS (
  SELECT work_date, driver_id, location_id, work_end_time,
         LAG(location_id)   OVER w AS prev_location_id,
         LAG(work_end_time)  OVER w AS prev_end_time
  FROM collections
  WHERE source = 'field_input'
  WINDOW w AS (PARTITION BY work_date, driver_id ORDER BY work_end_time)
)
SELECT prev_location_id AS from_id, location_id AS to_id,
       strftime('%w', work_date)          AS weekday,
       COUNT(*)                          AS n_samples,
       MEDIAN(elapsed_min)              AS p50_min,
       MAX(elapsed_min)                 AS p_max_min
FROM seq
WHERE prev_location_id IS NOT NULL
  AND elapsed_min BETWEEN 1 AND 90   -- 休憩・給油等の外れ値を除外
GROUP BY 1, 2, 3;

この行列は疎である。実績が埋めるのは既存コースが通る区間だけであり、拠点数を n とすれば要素数 n(n−1) のごく一部にとどまる。しかしこれは決定的な制約ではない。任意の拠点対の所要時間は地図サービスの経路探索から得られるため、行列そのものは埋められる。実績が担うのは絶対値の推定ではなく、地図サービスの一般的な所要時間と自社の実際の所要時間との残差——搬入経路、荷扱い、当該拠点固有の事情——の学習である。強い事前分布の上の補正であるため、必要な標本は絶対値を推定する場合より桁で少ない。詳細は8.2、残差の未検証性の扱いは第14節で述べる。

3定式化

対象は、時間枠付き容量制約配送計画問題(VRPTW)の変種である。標準的な定式化に、本業務に固有の項を加える。

ノード集合を V = {0} ∪ N とする。0 は車庫、N は当日訪問すべき拠点集合である。車両集合を K、決定変数を x_ijk ∈ {0,1}(車両 k が拠点 i から j へ移動するとき1)とする。各拠点 i には時間枠 [e_i, l_i]、作業時間 s_i、発生量 q_i が与えられ、各車両 k には積載上限 Q_k が与えられる。

3.1第六項について

第六項は標準的なVRPTWには現れない。これは第1節の性質1——実走順には表に書かれていない知識が織り込まれている——を目的関数に明示的に取り込むための項である。数理的に最適でも実走順から大きく外れた解は、現場が受け入れないか、モデル化されていない制約に抵触する可能性が高い。w₆ を大きく取れば「現行運用の微修正」に、小さく取れば「白紙からの再設計」に近づく。この一つの重みが、提案の急進度を制御するつまみになる。

ただし第六項には副作用がある。実走順を強く尊重するほど、現行運用に埋め込まれた非効率もまた再生産される。w₆ の値そのものが、既存知識の尊重と改善余地の探索とのトレードオフを表す。第5節では、これを単一の値に決め打ちせず、パレート境界として提示する方法を採る。

4訪問頻度の決定 — 閉形式と週次割付

前節の定式化は、訪問すべき拠点集合が所与であることを前提としていた。しかし実務上より手前にある、そしてより効果の大きい問いは「その拠点には何日おきに行くべきか」である。本節はこれを、需要予測の問題ではなく在庫補充の問題として定式化する。

4.1問題の再定義

各拠点は、不確実な速度で満ちていく容器とみなせる。意思決定は「いつ空けるか」であり、費用構造は明快である。頻繁に行きすぎれば訪問費用の無駄になり、間隔を空けすぎれば容器が溢れる。この構造は定期発注方式の在庫管理そのものであり、経路選択と組み合わせた形は在庫配送問題(IRP)として知られる。

この再定義には実務上の利点が三つある。第一に、決定変数が数量 q_i ではなく間隔 T_i になる。間隔は運用が直接操作できる量である。第二に、基準となる間隔は実績のみから決まり、気象データを一切必要としない。第三に、後述するとおり閉形式の解が存在する。気象と暦は、この基準間隔を微調整する第二層として位置づけられる。

4.2蓄積モデルと基準間隔

拠点 i の日次発生量を確率変数 X_i とし、平均 λ_i(袋/日)、分散 σ_i² とする。日々の発生が独立と仮定すれば、T 日間の蓄積量 A_i(T) について次が成り立つ。

この制約を等号で解く。u = √T と置けば λ_iu² + z σ_i u − C_i = 0 という u の二次方程式となり、正の根から基準間隔が閉形式で得られる。

4.3サービス水準を費用から導く

閉形式は α(許容する溢れ確率)を外生的に与える必要がある。これを勘で決める代わりに、費用から導出できる。訪問1回の費用を c_v、溢れ1回の費用(緊急対応・信用毀損)を c_o とすると、長期の日あたり費用は次で表される。

実務的には、c_o(溢れの費用)の見積もりが難しい。推奨する使い方は、費用版で一度 α を較正し、日々の運用は図5の閉形式で回すことである。c_o/c_v の比だけが効くため、「溢れ1回は訪問何回分の損失か」という問いに答えられれば足りる。

4.4実効日数 — 気象と暦による調整

ここまでは蓄積速度 λ_i を定数として扱った。実際には気温や暦によって日々変動する。ここで基準間隔の枠組みを壊さずに調整を入れる方法が、実効日数の導入である。

日 d の蓄積速度を、拠点固有の基準速度と、その日の倍率の積として表す。

分散についても同様に T を T_eff で置き換えればよい。したがって図5の閉形式は一切変更せず、入力の「日数」を「実効日数」に読み替えるだけで調整が完了する。これが本節の構成上の要点である。基準は実績のみから決まり、気象は基準を歪めるのではなく時計の速度を変える。

倍率の係数 β の推定が、次節で扱う回帰の役割である。ここで重要なのは、β は拠点ごとではなく業態ごとに推定すれば足りるという点である。拠点固有の情報はすべて λ_i に吸収されており、β が担うのは「暑い日は何割増えるか」という業態共通の感応度だけである。これにより、拠点あたり観測数が少ないという制約が緩和される。

4.5週次パターンへの割付 — ここが組合せ問題

閉形式が返す T_i^* は実数である。しかし運用は「3.7日おき」を実行できない。曜日パターン(毎日／月水金／火木／週1回・火 など)に割り付ける必要があり、同時に曜日ごとの作業量を平準化しなければならない。ここで初めて、閉形式では解けない組合せ最適化が現れる。

この問題は、拠点数が数百・パターン数が十数であれば、標準的なソルバで実用時間内に解ける規模である。そしてこれはブラックボックス最適化の問題ではない。目的関数も制約もすべて明示的に書けており、その構造を利用できるソルバを使わない理由がない。道具の選択については次々節で改めて整理する。

5目的関数の重みの較正

本節が本稿の中心である。構成は二重ループになる——内側で専用ソルバが巡回路を構築し、外側でその目的関数の重みを探索する。内側と外側で道具が異なる点が要諦であり、その整理は第6節で行う。まず外側、すなわち重み w_1..6 をどう決めるかという問いに対し、実績を教師信号とする逆問題として解くという答えを与える。

5.1着想

我々は真の目的関数を知らない。しかし、熟練ドライバーが日々選んだ巡回路は観測できる。彼らの選択が(局所的にせよ)合理的であると仮定するなら、ソルバの出力が実績とよく一致するような重みこそが、現場が実際に最小化している目的関数の近似である。これは選好の逆推定にあたる考え方であり、評価に時間のかかる関数(=一日分をソルバで解く)を少ない試行で探索するという構造は、ブラックボックス最適化の典型的な適用対象である。

5.2目的関数の実装

import optuna

VALID_DAYS = load_days(# 実績が揃っている過去の稼働日)

def objective(trial):
    w = {
        # 移動時間を基準(1.0固定)に、他を相対値として探索する。
        # 全係数を自由にすると目的関数がスケール不定になるため。
        "dist":     trial.suggest_float("w_dist",     0.0, 2.0),
        "tw":       trial.suggest_float("w_timewindow", 0.1, 50.0, log=True),
        "cap":      trial.suggest_float("w_capacity",   0.1, 50.0, log=True),
        "balance":  trial.suggest_float("w_balance",    0.0, 5.0),
        # w_order は単一目的の較正では固定する（5.5 の退化解を参照）
        "order":    W_ORDER_FIXED,
        # ソルバ側のメタパラメータも同時に探索対象に含める
        "meta":     trial.suggest_categorical(
                        "local_search", ["guided_local_search",
                                        "tabu_search",
                                        "simulated_annealing"]),
        "limit_s":  trial.suggest_int("time_limit_s", 5, 60),
    }

    losses = []
    for step, day in enumerate(VALID_DAYS):
        plan   = solve_vrptw(day, weights=w)      # 内側: 専用ソルバ
        actual = observed_route(day)              # 実績
        losses.append(divergence(plan, actual))

        # 見込みのない試行を早期に打ち切る
        trial.report(sum(losses) / len(losses), step)
        if trial.should_prune():
            raise optuna.TrialPruned()

    return sum(losses) / len(losses)

study = optuna.create_study(
    direction="minimize",
    sampler=optuna.samplers.TPESampler(seed=42),
    pruner=optuna.pruners.MedianPruner(n_warmup_steps=5),
    storage="sqlite:///calibration.db",     # 中断・再開・並列化のため
    study_name="weights_v1", load_if_exists=True,
)
study.optimize(objective, n_trials=300, n_jobs=4)

5.3乖離度の定義

divergence() の設計が結果を大きく左右する。単一の指標では捉えきれないため、三成分の重み付き和として定義する。

三成分のうち時刻差が突出して大きい場合、それは重みの問題ではなく所要時間行列の推定精度の問題である。較正の前に派生層の品質を疑うべきであり、この切り分けが可能な点も三成分に分ける利点である。

5.4単一目的から多目的へ

実務では「実績の再現」と「効率の改善」は対立する。実績を完全に再現する重みは、定義上、現行運用と同じ効率しか生まない。したがって単一目的での最小化は、較正の第一段階としては正しいが、提案生成としては不十分である。

study = optuna.create_study(
    directions=["minimize", "minimize"],      # 実績乖離, 総移動時間
    sampler=optuna.samplers.NSGAIISampler(seed=42),
)

def objective(trial):
    w = suggest_weights(trial)
    div, total_time = evaluate(w, VALID_DAYS)
    return div, total_time

study.optimize(objective, n_trials=500)

# パレート境界: 「現行に近い解」から「効率重視の解」までの連続体
for t in study.best_trials:
    print(t.values, t.params)

5.5探索空間設計の注意点

• スケールを固定する。 全ての重みを自由に動かすと、目的関数全体を定数倍しても解が変わらないため探索が発散する。一つの項(移動時間など)の係数を1.0に固定し、残りを相対値として探索する。
• ペナルティ項は対数スケールで探索する。 時間枠違反や積載超過の重みは、実効的な範囲が桁で変わる。log=True を指定する。
• ソルバ側のメタパラメータも同じ探索に含める。 局所探索の戦略や制限時間は重みと相互作用する。分離して順に調整すると、その相互作用を取り逃がす。
• 検証日を固定し、試行間で共通にする。 日ごとに難易度が違うため、試行ごとに日をサンプリングすると評価値にノイズが乗り、探索が不安定になる。

6最適化手法の選択 — 何にどの道具を使うか

ここまでに、性質の異なる六つの最適化問題が現れた。同じ「最適化」という語で括られるが、要求される道具はまったく異なる。本節はその対応を整理する。実務上、最も費用のかかる誤りは構造が分かっている問題にブラックボックス最適化を使うことである。

6.1最初に問うべきこと — それは本当にブラックボックスか

ブラックボックス最適化が正当化されるのは、目的関数について評価しかできない場合に限られる。すなわち、閉形式がなく、勾配が取れず、線形・凸などの利用可能な構造もなく、評価そのものが高価(シミュレーションやソルバ呼び出し)である場合である。この四条件のいずれかが崩れていれば、より良い道具が存在する。

構造があるのにブラックボックス最適化を使うと、四つの損失が生じる。最適性の保証を失う(近傍の良い点を返すだけで、それが最適である証明はない)。再現性を失う(乱数種と試行数に依存する)。説明性を失う(なぜその値かを式で説明できない)。そして単純に遅い(構造を使えば一発で解ける問題に数百回の評価を費やす)。

6.2本稿に現れた六つの問題と、その道具

六つのうち五つで、ブラックボックス最適化は不要である。この事実自体が、道具を先に決めてから問題を眺めることの危うさを示している。

6.3ブラックボックス最適化ツールの比較

6.2 でブラックボックス最適化が適するとされた問題に限って、どのツールを選ぶかを検討する。まず中核となるアルゴリズムの系統を押さえると、ツールの違いは理解しやすい。

主要なツールは、これらのアルゴリズムをどう束ねるかで性格が分かれる。

6.4選択の指針

• 1回の評価が数分以上かかり、試行数が50程度しか取れない → ガウス過程系(scikit-optimize / Ax)。少数の試行から最大限を引き出す設計になっている。
• 試行数100〜1000、連続とカテゴリが混在 → TPE系(Optuna)。この帯域が最も広く、多くの実務が当てはまる。
• 評価値に雑音が乗る(乱数を含むシミュレーション) → CMA-ES または Nevergrad。TPEは雑音に引きずられやすい。
• 目的が複数あり、トレードオフを面として見たい → NSGA-II(Optuna)または qEHVI 系(BoTorch)。
• 評価が途中経過を出せる(本稿の較正は日ごとに累積損失が出る) → 枝刈りを備えたツールを選ぶ。見込みのない試行を早期に打ち切れるため、実効的な試行数が数倍になる。この点はアルゴリズムの優劣より効くことが多い。
• まず基準を作りたい → ランダム探索。どの高度な手法も、ランダム探索に対する改善幅で評価すべきである。

6.5本稿の問題設定における結論

本稿の六問題のうち、ブラックボックス最適化が適するのは目的関数の重み較正のみである。そしてその一つについては、Optuna が要件によく合う。理由は探索性能そのものではなく、周辺機能にある。すなわち、(a)連続変数とカテゴリ変数が混在する空間を素直に書ける、(b)評価が日ごとに途中経過を出せるため枝刈りが効く、(c)試行をデータベースに永続化でき、実績が増えるたびに探索を継続できる、(d)単一目的から多目的への移行がサンプラの差し替えだけで済む。

逆に言えば、これらの要件が無ければ他のツールでも構わない。探索アルゴリズムの選択が結果を左右する場面は、実務では思われているほど多くない。多くの場合、探索空間の設計(スケールの固定、対数スケールの採用、無意味な範囲の除外)と評価関数の定義のほうが、サンプラの違いより桁違いに効く。

7蓄積速度の推定

7.1予測対象の定義 — 流量ではなく累積量

設計を誤りやすい第一の点がここにある。回収時に得られる数量は、その日に発生した量ではなく、前回訪問以降に蓄積した量である。したがって被説明変数は流量ではなく累積量であり、支配的な説明変数は気象ではなく前回訪問からの経過日数である。

この定義から、二つの帰結が導かれる。第一に、気象変数は回収日当日の値ではなく、前回訪問日の翌日から当日までの区間で集約した値でなければならない。当日の気温を特徴量に入れる実装は、蓄積の物理と整合しない。第二に、経過日数の効果は線形とは限らない。容器が満杯になれば、それ以上は蓄積しない。

訪問間隔は拠点ごとにも訪問ごとにも一定でない。経過日数を明示的に扱わない限り、拠点間・訪問間の数量は比較不能である。

7.2実績からの推定

拠点 i の連続する訪問について、経過日数 g_k と回収量 q_k の対が得られる。推定量は次のとおりである。

打ち切りの補正。 容器が満杯だった回の q_k は真の発生量ではなく容量である。これを素直に平均すると λ̂_i は下振れし、間隔がさらに長く算出され、溢れが増えるという悪循環に入る。実務的な処理は、観測の一定割合(たとえば2割)以上が最大値に張り付いている拠点を「打ち切り疑い」として識別し、その λ̂_i を下限値として扱う——すなわち算出された T^* をそのまま採用せず、短めに丸めることである。

小標本の縮小推定。 拠点あたりの観測数が十分でない段階では、λ̂_i の標準誤差は無視できない。点推定をそのまま閉形式に入れると、たまたま少なく観測された拠点の間隔が過大に算出される。同一業態の全体平均 λ̄ へ縮小させる。

7.3識別可能性と必要標本量

手法を論じる前に、標本がその推定を支えるかを問う必要がある。ここで効くのは総観測数ではなく、推定したい係数の階層と、観測が張る範囲である。三つの独立した条件を順に確認する。

条件1: 階層に応じた観測数。 目安として、推定するパラメータ1個あたり10〜20観測を要する。拠点数を n、拠点あたり観測数を k とすると、推定できるモデルの階層は次のように分かれる。

実務上ほぼ常に成り立つのは上二段であり、拠点別の感応度が推定できるのは長期の蓄積を経てからである。この段差を認識せずに拠点別モデルを組むと、雑音を係数として読み取ることになる。

条件2: 説明変数が十分な範囲を張っているか。 これは総観測数では代替できない、より厳しい条件である。観測期間が一年に満たない場合、気温の係数は季節に伴う他のすべての変化——学校の在学期間、行楽期、来客構成、日照時間——と本質的に分離できない。標本を増やしても、期間が偏っていれば交絡は解けない。同様に、祝日の効果を業態別に推定するには、各業態が十分な数の祝日を経験している必要がある。

したがって推奨される順序は、暦だけのモデルから始めることである。曜日と祝日の効果は同一季節内でも識別できるため、通年データを待たずに推定できる。気象変数の追加は季節を一巡してからでよい。この順序を守れば、交絡した係数を早期に信じてしまう事故を避けられる。

条件3: 説明すべき変動が実在するか。 逆方向の確認も要る。拠点内の変動係数がゼロに近ければ、その拠点は定数で足り、回帰は不要である。回帰が意味を持つのは、蓄積速度に説明可能なばらつきが存在する場合に限られる。加えて、データが複数の測定系（紙伝票の転記と端末入力など）から来ている場合は、系統差を吸収する指示変数を必ず入れる。丸め方や欠測の癖が系統ごとに異なるため、これを入れないと測定系の差が気象の効果として現れうる。

8気象と暦による調整

前節は、基準間隔 T_i^* を実績のみから閉形式で定め、気象と暦は実効日数の倍率 m(x_d) = exp(β′x_d) として時計の速度を変える、という二層構成を示した。本節はその第二層、すなわち係数 β をどう推定するかを扱う。あわせて、推定に必要な外部データの取得と保持を設計する。β は拠点ごとではなく業態ごとに推定すれば足りるため、拠点あたり観測数が少ないという制約は第一層ほど厳しくない。

8.1外部データの取得と保持

気象と暦は業務システムの外にあるデータであり、取得方法と保持形式を先に決める必要がある。要件は三つ、過去に遡って取得できること(蓄積済みの実績を後から特徴量つきにするため)、自動取得できること(手作業では継続しない)、再配布・保存が許諾されていることである。

保持は二つの独立したテーブルに分ける。実績テーブルには一切の気象列を持たせない。気象は後から遡って修正されることがあり、また同じ日の値を複数拠点が共有するためである。

-- 気象観測: 地点×日。実績テーブルとは独立に日次バッチで積む
CREATE TABLE weather_daily (
  obs_point   TEXT    NOT NULL,   -- 観測地点コード
  obs_date    TEXT    NOT NULL,
  temp_mean   REAL,   temp_max REAL,  temp_min REAL,
  precip_mm   REAL,   sunshine_h REAL, humidity REAL,
  is_forecast INTEGER NOT NULL DEFAULT 0,   -- 予報値か実況値か
  fetched_at  TEXT    NOT NULL,
  PRIMARY KEY (obs_point, obs_date, is_forecast)
);

-- 暦: 日ごとに1行。祝日CSVと自社の稼働規則から生成
CREATE TABLE calendar_days (
  cal_date        TEXT PRIMARY KEY,
  weekday         INTEGER NOT NULL,        -- 0=日 … 6=土
  is_holiday      INTEGER NOT NULL,        -- 法定祝日・振替休日
  holiday_name    TEXT,
  is_company_off  INTEGER NOT NULL,        -- 自社休業日(年末年始・お盆等)
  run_length_off  INTEGER NOT NULL,        -- その日が属する連休の長さ
  days_since_off  INTEGER,                 -- 直前の休業日からの経過日数
  school_term     TEXT                     -- 'term' | 'vacation'(学校拠点用)
);

-- 拠点と観測地点の対応。座標が無い間は地区で代用する
CREATE TABLE location_obs_point (
  location_id INTEGER PRIMARY KEY,
  obs_point   TEXT NOT NULL,
  mapping     TEXT NOT NULL              -- 'nearest' | 'region_default'
);

学習と推論の不一致。 モデルは実況値で学習されるが、運用時に入力できるのは予報値である。予報には誤差があるため、実況で学習したモデルに予報を与えると精度は必ず劣化する。対処は二通りある。(a)予報値でも学習し、予報の誤差込みで係数を推定する。(b)実況で学習した上で、予報誤差の分だけ予測区間を広げる。実装が簡単なのは(b)だが、is_forecast の両方を保持しておけば、後から(a)に移行できる。

8.2特徴量の設計

特徴量は、経過日数・気象・暦・拠点属性の四群に整理される。気象と暦はいずれも訪問区間で集約する点が要点である。

業態による効果の符号反転。 祝日の効果は業態によって逆向きである。教育機関・事業所・官公庁の拠点は休日に人がいなくなるため発生量が減る。一方、遊技場・商業施設・宿泊施設は休日に来客が増えるため発生量が増える。両者を混ぜた単一の祝日係数はゼロ付近に打ち消し合い、「祝日は効かない」という誤った結論を導く。業態区分と暦特徴量の交互作用項は必須である。気温についても、屋内空調の効いた事業所と屋外施設では効き方が異なる。

8.3モデルの選択

被説明変数は非負の整数(袋数)であり、右に裾を引き、ゼロを含む。通常の最小二乗法は前提を満たさない。加えて、拠点数に対して拠点あたり観測数が少ない階層構造を扱う必要がある。

import statsmodels.formula.api as smf
import statsmodels.api as sm

# 負の二項回帰。対数リンクにより、各係数は「発生量の倍率」として解釈できる
#   log_base_rate = log(拠点の過去平均日次発生量) をオフセットに置き、
#   拠点ぶんのダミー変数を推定せずに拠点差を吸収する（簡易的な部分プーリング）
model = smf.glm(
    formula=(
        "quantity ~ np.log(gap_days)"
        " + C(segment) * (holidays_in_gap + weekend_days_in_gap)"
        " + C(segment) * temp_max_in_gap"
        " + rain_days_in_gap + hot_days_in_gap"
        " + C(source)"            # 伝票OCR / 端末入力 の測定系の差を吸収
    ),
    data=df,
    family=sm.families.NegativeBinomial(),
    offset=df["log_base_rate"],
).fit()

print(model.summary())

log(gap_days) の係数は診断値として読む。 蓄積が経過日数に比例するなら、この係数は1付近になるはずである。実測値が明確に1を下回る拠点群があれば、それは容量による飽和が起きている証拠であり、4.1で述べた打ち切りの扱いが必要になる。係数を予測精度のためだけでなく、モデルの前提が成り立っているかの検査に使う。

データが増えた段階では、次の順に高度化する。(1)拠点をランダム切片とする混合効果モデルへ移行し、観測の少ない拠点は全体平均へ縮小(shrinkage)させる。(2)勾配ブースティング木で非線形性と交互作用を自動的に捉える。ただし拠点あたり観測が少ない段階で木モデルを使うと、拠点IDに過適合しやすい。(3)ゼロ過剰(「回収物なし」の記録)が無視できないなら、ゼロ過剰モデルを検討する。

8.4評価とベースライン

予測モデルの評価で最も重要なのは、越えるべきベースラインを先に決めておくことである。気象と暦を投入したモデルが、素朴な代替案に勝てないことは珍しくない。

• B0: 拠点別の全期間平均。 最も単純な代替案。
• B1: 拠点別の日次平均 × 経過日数。 蓄積の物理だけを使い、気象も暦も使わない。実質的にはこれが本命の対抗馬である。
• B2: 前回の実測値。 持続予測。

検証の分割は目的によって変える。既存拠点での性能を測るなら時系列で分割する——無作為分割は同一拠点の未来の観測が学習側に混入し、精度を過大評価する。未知拠点への一般化を測るなら拠点で分割する(9.4)。両者は別の量であり、前者が良くても後者が悪いことは普通に起きる。指標は数量の平均絶対誤差(袋)に加え、業務上の判断に直結する指標を併置する。すなわち「その日の当該コースが車両の積載上限を超えるか」という二値判定の正解率である。数量の誤差が小さくても積載超過の判定を外すなら、配車には使えない。

気象変数がB1に勝てないなら、投入しない。 特徴量が増えるほど、取得・保持・監視のコストが恒常的に発生する。効果が確認できない特徴量を残すのは、精度ではなく運用負債を増やす行為である。

8.5予測の使い道と、自己成就のわな

回収量予測の用途は二つある。第一は前節の q_i として最適化に入力し、積載制約の実行可能性を判定すること。第二は訪問頻度の見直しである。予測発生量が恒常的に小さい拠点は、訪問間隔を延ばせる可能性がある。回収一回ごとに費用が発生する業態では、後者のほうが経路最適化より直接的に効く。

ただし第二の用途には固有の危険がある。予測が小さい拠点の訪問を減らすと、その拠点の観測が減り、モデルを更新する材料が失われる。予測が外れていても、それを検知する機会が消える。これは自己成就的な予測であり、機械学習系のシステムが運用判断に組み込まれたときの典型的な失敗である。

対処は、意図的に予測に反する観測を残すことである。一定割合の訪問を、予測にかかわらず従来頻度で実施し、真の発生量を観測し続ける。実務的には、「回収物なし」の記録が蓄積されること自体が頻度見直しの根拠になるため、ゼロを正しく記録する運用——訪問したが回収物がなかった事実を、入力漏れと区別して残すこと——が、この探索の役割を部分的に果たす。

9マップ不変な表現 — 転移の前提条件

第III部が目指すのは、ある地域で学習した模型が、まったく別の地域でそのまま使えることである。道路網も顧客構成も気候も交通事情も異なる土地へ事業を広げるとき、そこで数年の実績が溜まるのを待つのでは遅い。

この目標は、模型の入力に何を許すかによってほぼ決まる。本節はその制約を先に定める。以降の各節——移動時間、需要、方策——はいずれもこの制約の下で設計される。

9.1転移が壊れる原因

転移が成立しない模型には共通の特徴がある。他のマップに存在しない量を入力にしていることである。拠点識別子、区間識別子、絶対緯度経度、地域名、コース番号——いずれも別の土地には対応物がない。これらを入力に取った模型は、学習した地域の索引表として振る舞い、新しいマップに対して何も言えない。

厄介なのは、この種の模型は既存地域の検証では極めて良い成績を出すことである。索引表は自分が索引している対象に対しては完璧に答える。日で分割した検証は、この失敗を検出できない。

9.2何が不変で、何が不変でないか

四行目が最も見落とされやすい。「7月」という月のダミー変数は、地域が変われば意味が変わる——同じ7月でも気候レジームが異なるからである。一方、気温そのものは物理量であり、どのマップでも同じ意味を持つ。業態ごとの感応度——暑いほど飲料容器が増える、雨天は集客施設の来訪が減る——は土地に依存しない機構であり、これは転移する。したがって暦の効果は月ではなく気象で表現しなければならない。この置き換えは、第II部で「気象変数の追加は季節を一巡してから」と述べた順序とも整合する——月ダミーで代用したままでは、そもそも転移可能な模型にならない。

9.3スケールの正規化

不変な量を選んでも、その尺度が地域で異なれば模型は転移しない。都市部と郊外では拠点間距離の分布が桁で違い、事業規模が違えば1日の訪問数も違う。入力は無次元化して与える。

• 距離は、当該マップにおける拠点間距離の代表値で正規化する
• 需要量は、拠点の容器容量で正規化する（＝充填率として扱う）
• 作業時間・移動時間は、1日の稼働可能時間で正規化する
• 密度は、拠点数と対象面積から無次元量として与える

正規化により、模型が学ぶのは「何キロメートル」ではなく「その土地の標準的な移動距離の何倍か」になる。この変換が、密な都市部で学んだ方策を疎な地方部へ持ち出すことを可能にする。

9.4検証はマップを保留して行う

転移可能性を測る方法は一つしかない。地域を丸ごと保留することである。ある地域の実績を一切見ずに学習し、その地域で評価する。

三者は別の量であり、上から順に厳しい。日で良好、拠点で良好、しかしマップで破綻するという事態は普通に起きる——それは模型がマップ固有の量を学んでいたことの証拠であり、9.2の制約に戻って入力を見直すことになる。既存地域が複数あるなら、そのうち一つを保留する交差検証が実施可能である。単一地域しかない段階では、地理的に離れた部分集合を人為的に切り出して代用する。

10移動時間の転移 — 外部地図と残差の一般化

実績が埋める所要時間行列は疎である(2.3)。しかし任意の拠点対の所要時間は外部の地図サービスから得られる。したがって欠けているのは所要時間の絶対値ではなく、一般的な所要時間と自社の実所要時間との差である。この差を残差として定義し、学習の対象を絞り込む。

10.1残差を区間ではなく特徴で学習する

残差を区間ごとに推定することはできない。区間数は拠点数の二乗であり、実績はそのごく一部しか埋めないからである。ここが地域をまたいで転移するための要点である——区間の識別子ではなく、区間の特徴を入力として残差を予測する関数を学習する。

この定式化により、一度も走ったことのない区間についても残差を予測できる。予測には分散が伴い、その分散は特徴空間における学習データからの距離とともに増大する。走行実績の多い領域では残差の予測は鋭く、経験のない領域では広い——これがそのまま次節以降の不確実性の扱いへ接続する。

10.2未検証な区間の扱い

残差の予測分散は、提案経路の信頼性を測る指標として直接使える。計量は、提案経路が使う区間について予測分散を集計した値である。これが大きい提案は、残差の事前分布を広く取って再求解するか、当該区間を試走して残差を確認する。12.3の領域ランダム化は、この不確実性を方策の学習段階で扱う対応物である——残差の事後分布から抽出して学習すれば、経験のない領域に対して自動的に保守的な方策が得られる。

検証は区間を保留して行う。実績のある区間を訓練と検証に無作為分割すると、同じ区間が両側に現れて残差の記憶を測ってしまう。区間——あるいは地域——を丸ごと保留し、その残差を一切見ずに所要時間を予測して実績と比較する。これが未経験の土地に展開したときの精度の推定値になる。

11需要の転移 — 属性による冷始動

ここで目的を明確にしておく。このパイプラインが生むべきものは現在の拠点集合に適合した重みではなく、まだ存在しない拠点にも適用できる関数である。新規顧客を獲得したとき、実績が一件もない状態で「この拠点は何日おきに回り、どのコースに入り、限界費用はいくらか」に答えられなければ、模型は運用に追随できない。

これが生成の本質的な価値である。12.1では生成の利点を事例数として述べたが、より重要なのは被覆である。実績のリプレイから学べるのは、自社が現に経験したマップだけである。生成器はマップの空間統計を意図的に走査でき、実在しない配置——密集した都市部、離れた郊外、狭い時間枠が重なった日——も作れる。量ではなく、経験していない状況を作れることが効いている。

表現の要件。 方策も推定も、入力を拠点識別子ではなく属性ベクトルに取らなければならない。識別子を入力にした瞬間、その模型は既存拠点の索引表になり、新規拠点に対して何も言えなくなる。

冷始動の手順。 新規拠点について、蓄積速度は属性からの回帰で与える——λ_i = f(属性_i) ＋ 拠点固有効果。実績のない拠点は f(属性) とその予測分散を用いる。移動時間は地図サービスから即座に得られる。したがって新規拠点は初日から間隔と割付が決まる。実績が蓄積するにつれ、拠点固有効果が f からの乖離として推定され、予測が個別化していく。7.2の縮小推定は、この個別化の速度を制御する装置として読み直せる——観測が乏しいうちは f(属性) に寄り、増えるにつれ自身の実績に寄る。

12マップの生成と方策学習

前三節は、不変な表現・移動時間・需要のそれぞれについて転移の手立てを述べた。本節はそれらを束ね、マップそのものを生成し、机上で走らせ、方策を学習する。盤上遊戯の探索エンジンが自己対局で局面を無限に供給するのと同じ構造である。

12.1実績の役割は方策の学習ではなく生成器の較正である

この道筋を検討するにあたり、最初に整理すべきは実績データが何に使われるかである。学習に必要な事例数と、手元にある実績件数を直接比べるのは誤りである。

要点は二行目と三行目である。移動時間は実走の有無に依存しない——地図サービスの経路探索は任意の拠点対について所要時間を返すため、実績が疎であることは行列の穴を意味しない(この含意は第10節で扱う)。そして方策の学習に実績は要らない。必要なのは実績で較正された生成器であり、そこから事例は望むだけ得られる。

12.2生成器の構成

生成器は、一日分の配車問題インスタンスを確率的に生成する。構成要素と較正元は次のとおりである。

移動時間の行が要点である。地図サービスが返すのは一般的な所要時間であり、当該拠点での搬入経路や荷扱いの癖は含まない。したがって地図サービスの値を事前分布とし、実績との残差だけを学習する。残差は強い事前分布の上の補正であるため、必要な標本は絶対値を推定する場合より桁で少ない。

12.3不確実性の扱い — 領域ランダム化

「シミュレータは世界モデルの精度までしか正しくない」という懸念は正当だが、それは方策を点推定の世界に固定した場合の話である。標準的な対処は逆で、パラメータの不確実性そのものを分布として与え、その上で頑健な方策を学ぶ。

この構成により、推定の誤差は方策を壊す要因ではなく方策が備えるべき環境の一部になる。事後分布が狭まれば方策はより積極的になり、広ければ保守的になる。推定と決定の関係が、パラメータの受け渡しではなく分布の受け渡しへ変わる。

12.4何を学習するか — 三つの水準

(a) 経路構成の方策。 訪問集合を入力として巡回順を構成する。注意機構による符号化・復号が標準的な構成で、1日1車両あたりの訪問数は20前後、全体でも数百の水準にとどまるため、この規模は近年の研究が扱う範囲の下限に位置する。既存の求解器を明確に上回るかは検証を要するが、推論が一回の順伝播で終わるため、後述の(c)の内側で何万回も呼ぶ用途では決定的に有利である。

(b) 近傍選択。 大規模近傍探索において、どの拠点群を破壊・再構築すれば改善が見込めるかを予測する。求解器を置き換えず内側に差し込めるため導入が容易で、標本要求も緩い。

(c) 訪問間隔と割付の方策。 ここが本質的に重要である。第4節の閉形式は、各拠点を独立に扱っている。しかし現実には経路費用が拠点を結合する——隣接する拠点は「ついでに」回れば限界費用がほぼゼロであり、単独で最適な間隔とは異なる間隔で回るほうが全体では安い。

間隔と経路を同時に決める問題は在庫配送問題として知られ、閉形式は存在しない。逐次的な意思決定であり、状態(各拠点の蓄積量)が確率的に遷移し、行動(今日どこへ行くか)が将来の状態を変える。これは強化学習が本来対象とする構造そのものである。第4節の閉形式は、この結合を無視する分解ヒューリスティクスとして位置づけられる——実用上は良い近似だが、上限ではない。

12.5学習の設計と計算量

報酬は図3の目的関数をそのまま用いる。報酬設計に恣意性が入らない点は、この問題の際立った利点である——多くの応用では報酬の定義自体が難題だが、ここでは走行時間・時間枠違反・積載超過・平準化がすべて明示的に計算できる。

学習は方策勾配法による。同一インスタンスから複数の軌跡を生成し、その平均を基準値として用いれば、価値関数を別に学習せずに分散を抑えられる。訪問数の小さいインスタンスから開始し、実規模へ段階的に広げる。

この規模は、第13節で述べる階層ベイズと同程度である。本稿の問題群において、演算加速を要する処理は統計推論と方策学習の二つであり、いずれも数時間から一日の水準に収まる。分散環境を要する規模ではない。

12.6シミュレータを信じないための検証

生成した世界で学んだ方策が現実で機能する保証はない。検証は三段で行う。

1. 生成器の妥当性検定。 生成した日の統計量——訪問数、総発生量、稼働時間、時間枠違反率の分布——が、実績の分布と整合するかを検定する。生成器が現実の日を再現できないなら、その上で学んだ方策を論じる意味はない。ここが最初の関門である。
2. 実績日でのリプレイ。 生成器を通さず、実際にあった日の訪問集合と制約を入力として方策を走らせ、実績と比較する(第14節)。このとき拠点を保留した分割で行う(9.4)——保留拠点での性能が、新規顧客に対する性能の推定値になる。学習した方策が閉形式および較正済み求解器を上回るかを、この土俵で判定する。
3. 運用後の閉ループ照合。 溢れ発生率の実測が設計値と整合するか(第14節)。シミュレータの欠陥は最終的にここで露見する。

12.7学習させない部分

すべてを学習に委ねる必要はない。厳密に計算できるものは厳密に計算する。距離、時間枠違反量、積載超過量は式で求まり、その計算は数個の加減算で終わる。これらを近似する模型は、置き換える算術より遅く、かつ不正確である。

学習が担うのは二つに限られる。方策——どの順で回るか、今日どこへ行くか——と、書き下せない選好——図3の第六項が単一のスカラーで代理していた、乗務員の暗黙知である。探索と評価の厳密な部分を保ったまま、書けない部分だけを学習する。これは学習済み評価関数を採用した探索エンジンが辿った分業と同じ構造である。

13計算資源の配置

前節は「どのアルゴリズムを使うか」を論じた。本節は「どの計算機に載せるか」を論じる。とりわけ、汎用GPUによる並列演算が有効な処理と無効な処理を判別する。結論を先に述べれば、本稿の最適化パイプラインにおいて、GPUが効くのは統計推論とシミュレーションであって、最適化そのものではない。

13.1まず桁を見積もる

加速の検討は、対象の計算量が何桁かを確認することから始めるべきである。この問題群の主要な計算は、拠点数 n、実績件数 R、特徴量数 F で概ね記述できる。

ここで決定的なのは、拠点数 n は事業規模に対してほとんど伸びないという事実である。数百から数千の範囲に収まり、距離行列は倍精度でも数MBから数十MBにすぎない。これは現代のCPUのキャッシュ階層で扱える大きさであり、行列そのものの大きさが加速の理由になることはない。伸びるのは実績件数 R であり、時間とともに線形に増える。

13.2二つの規模での比較

規模によって答えが変わるため、二つの水準で比較する。小規模は実績 R ~ 10³、拠点 n ~ 10²。中規模は乗務員20名・3年程度の蓄積を想定し、R ~ 3×10⁵、n ~ 10³、拠点あたり観測数 k ~ 300 とする。

この表から二つのことが読み取れる。第一に、規模を上げても最大の計算負荷は依然としてGPUの問題ではない。重み較正ループは trials × D 回の求解を要し、中規模では10³ CPU時間の水準に達するが、これは試行間・日ごとが独立な粗粒度並列であり、加速手段はコア数・ノード数・枝刈りである。

第二に、質的に変化するのは階層ベイズと方策学習である。前者から述べる。拠点あたり観測数 k が30〜50を超えると、7.3節の条件1により拠点別の係数が推定可能になる。すると推定パラメータ数 P が拠点数に比例して増え、勾配評価が R × P のオーダーになる。統計的により正しいモデルを選べるようになった瞬間に、計算量が跳ね上がる——ここが演算加速の出番である。方策学習(第12節)も同じ帯域にあり、こちらは規模によらず訓練そのものが並列演算を要する。ただし両者とも数時間から一日の水準に収まり、単一の高性能GPUを超える設備は要らない。

13.3GPUが効く処理・効かない処理の判別

個別の事例に当たる前に、判別の原則を述べる。GPUは同一の演算を大量の独立したデータへ一斉に適用する構造でのみ性能を発揮する。したがって次の三条件がそろう必要がある。

• データ並列性 — 同じ命令列を多数の要素に適用できる。分岐が要素ごとに異なると、実行が直列化して性能が崩れる。
• 規則的なメモリアクセス — 連続した領域にまとめてアクセスできる。ポインタ追跡や不規則な間接参照は苦手である。
• 演算密度 — 転送したデータ量に対して十分な演算がある。転送が支配的なら、加速しないどころか遅くなる。

この三条件に照らせば、配送計画の求解がGPUに向かない理由は明白である。分枝限定と制約伝播は本質的に分岐が多く、逐次的で、メモリアクセスが不規則である。探索木の各ノードで異なる制約が発火し、異なる枝が刈られる。これはGPUが最も苦手とする形であり、実用的な求解器がCPUベースであるのは実装上の都合ではなく問題の構造による。

ただし、規模が上がると一つだけ検討に値する例外が現れる。大規模近傍探索における候補手の一括評価である。1日あたりの訪問数を M とすると、2-opt 近傍の候補は O(M²) 個あり、各候補の改善量は独立に O(1) で計算できる。M が数百に達すればこれは数万件の独立な評価となり、データ並列性の条件を満たす。既存の求解器を上回るかは実証を要するが、「明確に不適」から「実験に値する」へ位置づけが変わる。

13.4周辺処理

最適化パイプラインの外側の処理は、演算資源を規定しない。入力が構造化された系では、自由記述の解釈や表記ゆれの突合といった処理そのものが発生しない。大量処理が生じるのは既存帳票からデータを起こす移行期のみであり、一度きりの作業は定常状態の設備を規定する根拠にならない。

13.5本節の結論

1. 行列の大きさは加速の理由にならない。 拠点数は事業規模に対して伸びず、距離行列は数MB規模にとどまる。
2. 最大の計算負荷は粗粒度並列である。 重み較正ループはCPUコア数・ノード数・枝刈りで対処する問題であり、GPUは寄与しない。
3. 組合せ探索は規模によらずGPUに向かない。 ただし大規模近傍の一括評価は、規模が上がれば実験に値する。
4. 質的に変化するのは統計推論と方策学習である。 前者は拠点別係数が識別可能になる規模で計算量が跳ね上がる。後者は生成器さえ較正できれば規模によらず訓練を要する。いずれも単一の高性能GPUで数時間から一日の水準に収まる。
5. 周辺処理は演算資源を規定しない。 大量処理が生じるのは移行期の一度きりである。

この節の含意は、第6節の原則の系である。道具から問題を選ばないという原則は、アルゴリズムだけでなく計算機にも当てはまる。演算資源があるから最適化を重くするのではなく、問題の構造が要求する計算に資源を割り当てる。

14評価と監視

配車最適化は本番投入前の検証が難しい。実際に走らせてみるまで真の所要時間が分からないためである。したがって、過去実績に対するオフライン再現(リプレイ)を主たる評価手段とする。

評価は1.3の二軸に分けて行う。推定の評価は、蓄積速度と調整係数がどれだけ現実を再現するかを、素朴なベースラインとの差で測る(8.4)。決定の評価は、それらを入力として生成した計画が、実績と比べてどうかを測る。両者を混ぜてはならない——推定が正確でも決定が悪いことはあり、その逆もある。以下は決定の評価を扱う。

手続きは次のとおりである。実績のある期間を時系列で分割し、前半で重みを較正し、後半で評価する。後半の各日について、その日の訪問拠点集合と車両制約を入力としてソルバに巡回路を生成させ、実績と比較する。

加えて、要素の寄与を切り分けるアブレーションを行う。(a)重みを手で決めた場合と較正した場合、(b)実効日数による調整を有効化した場合と無効化した場合、(c)第六項(実走順の尊重)の有無。それぞれで上記指標を比較する。これにより、どの要素が実際に効いているかを定量化できる。

設計上の限界は、散文の但し書きとして書き残しても機能しない。読まれず、更新されず、実際にその限界に触れたときに誰も気づかないからである。限界は計算可能な量として定義し、閾値を決め、超えたときに系が何をするかまで書いて初めて設計に組み込まれる。本節は各限界について〈計量・閾値・フィードバック先〉の三つ組を与える。

整理は1.3の二軸に従う。推定側の限界は入力パラメータの信頼性に、決定側の限界は解の妥当性に関わる。そして両者を繋ぐ閉ループが一つ存在し、これが系全体の健全性を担保する。

14.1推定側の限界

標本の偏り。 実績の記録は一部の乗務員・一部のコースから始まるため、初期の標本は特定地区に偏る。この偏りは「注意する」ものではなく測るものである。計量は拠点ごとの観測数 k_i と、そこから定まる標準誤差 SE(λ̂_i) = σ̂_i/√(Σg_k) である。フィードバックは二経路ある。第一に、7.2の縮小推定の重み w_i が SE の関数として定義されているため、偏りは自動的に推定へ織り込まれる。第二に、SE の大きい拠点を次の観測対象として優先する——これは能動的な標本設計であり、偏りの是正をループに戻す唯一の手段である。

識別可能性の欠如。 観測期間が短ければ、気温の係数は季節に伴う他の変化と分離できない(7.3)。これも計量できる。説明変数間の相関行列、あるいは分散拡大係数を計算し、閾値を超える変数群は係数を推定せずモデルから落とす。人間が「交絡に注意する」のではなく、共線性の指標が自動的に変数を除外する構成にする。除外された変数は、期間が伸びて共線性が下がった時点で自動的に復帰する。

打ち切り。 容器容量に達した観測は真の発生量ではない(4.1)。計量は拠点ごとの最大値張り付き率——観測のうち当該拠点の最大値と一致するものの割合である。閾値を超えた拠点は λ̂_i を下限値として扱い、閉形式が返す T_i^* を短縮側へ丸める。打ち切りの検出そのものが、間隔の安全側への補正として作用する。

14.2決定側の限界

残差が未検証な区間への依存。 任意の拠点対の所要時間は地図サービスから得られるため、行列に穴は空かない(2.3)。残る不確実性は、地図サービスの値と自社の実所要時間との残差——その区間や拠点に固有の事情——であり、これは実際に走った区間でしか検証されていない。したがって計量すべきは「観測済みか」ではなく残差の検証済み度である。提案経路が使う区間のうち、残差が実績で確認されている割合を測る。

最後の行が重要である。未検証の区間は制約であると同時に、次に何を観測すべきかの指示でもある。有望に見えるが未検証の区間を意図的に走らせて残差を得れば、以降の推定精度が上がる。限界を静的な制約として受け入れるか、能動的に解消していくかの分岐点がここにある。なお12.3の領域ランダム化は、この不確実性を方策の学習段階で扱う対応物である——残差の事後分布から抽出して学習すれば、未検証区間に対して自動的に保守的な方策が得られる。

最適性ギャップ。 求解は時間制限つきで打ち切られるため、返る解は最適とは限らない。混合整数計画・制約プログラミングのソルバは残余ギャップ——現在の解と下界の隔たり——を返す。これを記録し、ギャップが常態的に大きいなら制限時間を延ばすか定式化を見直す。「最適化した」と称しながらギャップを記録していない実装は、何を達成したか主張できない。

14.3二つの問題を繋ぐ閉ループ

ここまでの計量は、それぞれの問題の内部で完結している。しかし系全体の健全性を測る指標は、推定と決定の境界をまたいだところにある。

閉形式(4.2)は、溢れ確率が α 以下になるよう間隔を定めた。この α は設計値である。運用を開始すれば、実際の溢れ発生率が観測される。両者を比較することが、系全体に対する唯一の実地検証である。

乖離度の三成分による切り分け。 同様の切り分けは重み較正にも組み込まれている。5.3の乖離度を集合差・順序差・時刻差の三成分に分けたのは、どちらの問題に原因があるかを判別するためである。時刻差だけが突出して大きければ、それは重みの問題ではなく所要時間行列の推定精度の問題であり、修正すべきは決定側ではなく推定側である。指標を分解しておくことが、そのまま原因の切り分けになる。

自己成就の遮断。 予測に基づいて訪問頻度を下げると、その拠点の観測が減り、推定を更新する材料が失われる(8.5)。計量は、頻度を変更した拠点群の観測数の推移である。これが減少し続ける場合、一定割合の訪問を予測にかかわらず従来頻度で実施し、観測を確保する。予測を運用判断に使う系は、必ず予測に反する観測を意図的に残さなければならない。

14.4監視量の一覧

この表が本節の成果物である。各行は計算可能であり、閾値を持ち、行き先を持つ。限界とは、監視されていない量のことである。計量してループに戻した時点で、それは限界ではなく制御量になる。

15段階的導入

本設計は、データの成熟度に応じた段階を踏む。各段階を飛ばすと、後段が成立しない。

段階1で得られる記述的レポート——予定と実績の消化率、区間所要時間、拠点別の発生量——は、最適化に到達する前であっても実務価値がある。むしろ、この段階のレポートを配車担当者が日常的に見る状態を作ることが、後段の提案を受け入れてもらうための最良の準備になる。

16結論

本稿は、定期巡回型回収業務における配車最適化を、データモデル・定式化・解法・評価の四面から設計した。主要な主張を再掲する。

1. データモデルが成否を決める。 計画と実績を分離し、実績にコース識別子を残し、派生層を明示的に置く。記録されなかったデータは後から復元できないため、記録粒度の確保は他のあらゆる機能追加に優先する。
2. 計画表の順序を制約にしてはならない。 実測された順位相関は、計画表の順序が実態から乖離していることを示す。実走順こそが、明文化されていない知識を含む信号である。
3. 目的関数の重みは実績から較正する。 ブラックボックス最適化の最も価値ある適用先は、巡回路の探索ではなく、この逆問題である。多目的化すれば、単一の推奨案ではなく選択肢の連続体を実務者に提示できる。
4. 移動時間は外部の地図サービスから得られる。 実績が担うのは絶対値の推定ではなく、地図サービスの値と実所要時間との残差の学習である。その残差もまた区間識別子ではなく区間の特徴から予測する——そうして初めて、走ったことのない土地の区間にも適用できる。
5. 計算資源の配置も、問題の構造から決まる。 行列の大きさは加速の理由にならず、組合せ探索は規模によらず並列演算装置に向かない。質的に変化するのは統計推論であり、拠点別の係数が識別可能になる規模で階層ベイズの計算量が跳ね上がる。演算加速の価値は速度ではなく、点推定で妥協せずに不確実性を伝播させた推論を、実務の反復速度で回せるようになることにある。
6. 閉形式は上限ではない。 拠点を独立に扱う閉形式は、経路費用による拠点間の結合を無視している。間隔と経路を同時に決める問題に閉形式はなく、そこは生成器で事例を供給した方策学習の対象になる。実績が足りないことは学習の障害ではない——局面は生成できる。
7. 目的は既存地域への適合ではなく、新規地域への転移である。 模型の入力から拠点識別子・絶対座標・月ダミーといったマップ固有の量を排し、相対幾何・業態属性・気温といった不変量に置き換える。そのうえで多様なマップを生成して学習すれば、実績のない土地でも初日から間隔と経路が決まる。生成の価値は事例数ではなく、経験していない土地の空間統計を作れることにある。この目的を採るなら、検証は日でも拠点でもなく地域を丸ごと保留して行わなければならない。
8. 限界は但し書きではなく監視量として定義する。 標本の偏りは標準誤差として、識別可能性は共線性指標として、打ち切りは張り付き率として、未観測区間への依存は被覆率として計算できる。そして溢れ発生率の実測と設計値の差が、推定と決定を繋ぐ唯一の閉ループを成す。計量して行き先を決めた時点で、限界は制御量になる。

最後に、方法論上の一点を付言する。本稿が挙げた設計上の要点の多くは、仕様書やコードからは導けない種類のものである。計画順序と実走順序の乖離、担当交代の常態性、記録粒度の不足が生む情報の逃避——いずれも、実績を集計して初めて可視化される。設計の妥当性は、業務の記述ではなく実績の分布によって検証される。最適化の設計に着手する前に、まず実績を取り、その分布を眺めることに尽きる。