Aさんは、全国に数百店舗を展開する小売チェーンの物流部門で、日々の配送計画を統括しています。

2拠点から30台近いトラックを走らせ、数百店舗へ商品を届ける――。その複雑な配送ルートを、Aさんはこれまで表計算ソフトを駆使して組み立ててきました。しかし、店舗数や出荷量の増加とともに処理が追いつかず、担当者ごとの経験や勘に頼らざるを得ない状況Aさんは、全国に数百店舗を展開する小売チェーンの物流部門で、日々の配送計画を統括しています。

2拠点から30台近いトラックを走らせ、数百店舗へ商品を届ける――。その複雑な配送ルートを、Aさんはこれまで表計算ソフトを駆使して組み立ててきました。しかし、店舗数や出荷量の増加とともに処理が追いつかず、担当者ごとの経験や勘に頼らざるを得ない状況に。「時間もかかるし、ミスも増えてきた。このやり方に限界を感じていました」とAさんは語ります。

ドライバーの負担を平準化し、コストを抑えながら、納品時間を守る――。

そんな“理想の配送ルート”をどうすれば実現できるのか。現場の最前線に立つAさんは、数理最適化AIチャット「Gurobot（グロボット）」に相談を持ちかけました。

前編では、そんなAさんの現状整理をGurobotがお手伝いするやり取りから始まります。

Aさん

はじめまして。私は国内で小売チェーンの物流部門を統括しているAと申します。

毎日数百店舗への配送ルートを表計算ソフトで組んでいるのですが、店舗数や出荷量が増えるにつれて処理が追いつかず、担当者ごとの属人的な工夫に頼っているのが実情です。時間もかかり、ミスが起きやすくなっています。

Gurobotさん、こうした状況で、ドライバーの負担を平準化しながら、配送コストを抑え、納品時間を守れるルートを組むには、どうすればよいでしょうか？

Gurobot

はじめまして、Aさん。Gurobotです。

ご相談いただき、ありがとうございます。数百店舗への配送ルート計画が属人化し、処理が追いつかない状況とのこと、よく理解いたしました。

このような配送ルート最適化の課題は、Vehicle Routing Problem（VRP、配送計画問題）として数理最適化で解決できる典型的なケースです。Gurobi Optimizerを活用することで、複数の制約条件を同時に考慮しながら、最適または非常に良質なルートを自動的に計算することが可能です。

まず問題の詳細を整理させてください

より具体的なモデルを設計するため、以下の点について教えていただけますでしょうか：

1. 配送の基本構造について

• 配送拠点（デポ）は何箇所ありますか？（1箇所か、複数の地域拠点か）

• 使用できる車両は何台程度ですか？

• 車両のタイプは同じですか、それとも積載容量の異なる車両が混在していますか？ 

2. 制約条件について

• 各店舗への納品時間帯の指定はありますか？（例：午前中のみ、10時〜14時など）

• 車両の積載容量制限はどの程度重要ですか？

• ドライバーの労働時間制限はありますか？

• 1台の車両が1日に訪問できる店舗数の上限はありますか？

3. 目的（優先順位）について
現在、以下のような複数の目標を挙げられていますが、優先順位をつけるとしたらどうなりますか？

• 配送コストの最小化（総走行距離 or 総配送時間）

• ドライバーの負担平準化（各車両の走行距離や配送時間のバランス）

• 納品時間の遵守

4. データの状況について

• 店舗間の距離や移動時間のデータはお持ちですか？

• 各店舗の出荷量・配送量のデータは日次で把握されていますか？

• 現在表計算ソフトでどのような情報を管理されていますか？

これらの情報をいただければ、具体的な数理最適化モデルの設計方針をご提案できます。また、Gurobiを使った実装方法や、既存の表計算ソフトフローとの連携方法についてもアドバイスさせていただきます。いかがでしょうか？

Aさん

Gurobotさん、早速のご返信ありがとうございます。数理最適化は専門外なので、かみ砕いたご説明をお願いするかもしれませんが、まず現状と希望を共有します。

■ 現状の前提（ざっくり）

• デポ：2拠点（関東東部・西部）

• 車両：計28台／日稼働、2t・3tの混在（冷蔵12台、常温16台）

• 店舗：約320店（毎日全店配送ではなく、A/B/C頻度あり）

• 作業：積込はデポで波次ごとに30分〜60分、店舗での降ろし・検品10〜20分

■ 制約として見てほしい点

• 納品時間帯：多くは「開店前」「10–12時」「14–16時」の指定あり

• 積載：車両ごと最大積載量あり。冷蔵と常温は原則同一車両で混載不可

• 労働時間：拘束8時間目安（最大10時間まで・休憩1時間）

• 訪問上限：現場感としては1台あたり8〜14店舗程度が現実的

• 道路事情：都心部は午前中の渋滞が顕著、左折進入しかできない店舗も一部あり（考慮方法ご教示ください）

■ 目的の優先度（仮）

• 1位：納品時間の遵守（クレーム抑止が最重要）

• 2位：配送コスト低減（走行距離・高速代・台数）

• 3位：ドライバー負担の平準化（走行時間・停止回数の偏り是正）

 ■ データの手持ち状況

• 表計算ソフトで「店舗マスタ（住所・時間帯・平均サービス時間）」「日別の店舗別出荷量（容積ベース／重量は一部）」「車両マスタ（箱サイズ・冷蔵/常温）」があります。

• 距離・所要時間は今はGoogleマップで手作業推定。距離行列の自動作成方法をご提案いただけると助かります。

• 過去実績（遅着・欠品・緊急便の記録）もCSVで出せます。

 ■ まずは小さく試したい（パイロット案）

• 対象：東部デポ、常温車のみ、週中（火–木）データで50–80店舗

• 目的：①時間帯遵守率、②総走行距離、③1台あたりの作業時間の分散—の3指標で比較

• 比較方法：現行表計算ソフト手組み vs 最適化案（同じ出荷データでA/Bテスト）

 ■ いくつか教えてください（非エンジニア向けに）

• 最低限必要な入力項目とフォーマット例（表計算ソフト列見出し）をいただけますか？当社側でその形に揃えます。

• “時間帯遵守”を最優先にしたとき、距離増とのトレードオフをどう設定（重み付け）すればよいか、実務的な目安が知りたいです。

• 左折制限や高さ制限のような「一部店舗の進入ルール」は、どうやってモデルに入れますか？

• 緊急の当日追加（15時に1店舗追加など）が出た際、既存ルートをどの程度崩さず差し替えできるのか、運用イメージを知りたいです。

• 解の計算時間の目安（上記パイロット規模）と、解が出なかった/遅い場合の“実用的な近似解”の扱い方を教えてください。

• 現場への共有は地図表示・時系列表（積込→訪問順→戻り）など、どんな形で出力できますか？表計算ソフト/PDF/地図画像のサンプルがあると嬉しいです。

• 既存フロー連携：毎朝の出荷量CSVを取り込んでワンクリックでルート出力、まで持っていけるでしょうか。中間に人手の調整画面（時間帯の微修正、特定店舗の優先度付け）があると安心です。

 ■ 成功基準（仮置き）

• 納品時間帯遵守率：現状比＋5pt以上

• 総走行距離：現状比▲8〜10%

• 1台あたり作業時間の標準偏差：現状比▲15%（平準化）
  ※現実的なラインに調整いただけると助かります。

 ■ 懸念と希望

• 冷蔵・常温の分離や出荷バッチ（出荷データをバッチごとに分けて一括送信する方法）との整合が難所だと感じています。モデリングの考え方をご指南ください。

• 将来的にはドライバーごとのスキル差や土地勘も加味したいですが、まずはシンプルな前提で始めたいです。

 以上です。まずはパイロット対象のテンプレと、モデルの考え方（目的関数と主な制約のやさしい説明）をご共有いただけると、社内説明がしやすくなります。よろしくお願いします。

Gurobot

ありがとうございます！知識ベースから情報を確認できました。それでは、非エンジニア向けに「やさしい説明」をベースに、実務的な観点から各質問にお答えします。

 【全体像】この問題は何を解くのか

Aさんが取り組もうとしているのは、VRPTW（Vehicle Routing Problem with Time Windows：時間枠付き配送計画問題）と呼ばれる数理最適化の代表的な問題です。これに、積載容量制約や冷蔵/常温の分離、複数デポといった実務制約が加わった形です。

 やさしい説明：目的関数と制約

 目的関数（何を最良にしたいか） Aさんの場合、複数の目標があります：

• 納品時間帯の遵守（最優先）

• 総走行距離の最小化（コスト削減）

• ドライバー負担の平準化（各車両の作業時間のバラツキ削減）

これらを同時に最適化するには、GurobiのMulti-Objective Optimization（多目的最適化）機能を使います。

 主な制約（守らなければならないルール）

• 各店舗は必ず1台の車両が1回だけ訪問する

• 各車両の積載量を超えてはいけない

• 冷蔵品と常温品は同じ車両に積めない

• 各店舗の指定時間帯内に到着しなければならない

• ドライバーの拘束時間（8時間目安、最大10時間）を超えない

• 各車両はデポから出発し、デポに戻る 

【質問への回答】

❶ 最低限必要な入力項目と表計算ソフト列見出し例
パイロット（東部デポ、常温車、50-80店舗）で必要な入力データは以下です：

 ① 店舗マスタ（店舗テーブル）

 ② 日別出荷量（配送需要テーブル）

 ③ 車両マスタ

 ④ 距離・時間行列（デポと店舗間）
後述しますが、Google Maps APIやMapbox APIを使って自動生成できます。 手作業の場合、以下のような行列形式：

 ❷ 時間帯遵守を最優先にしたとき、距離増とのトレードオフ設定（重み付け）
Gurobiでは、階層的（Hierarchical）アプローチ と 重み付き（Blended）アプローチ の2つの方法があります。

 推奨：階層的アプローチ（優先順位明確）

Aさんのケースでは「納品時間遵守が最重要」とのことなので、階層的多目的最適化が最適です。具体的には：

• 第1優先目標（Priority=3）: 時間帯遵守違反の店舗数を最小化（ゼロが理想）

• 第2優先目標（Priority=2）: 総走行距離を最小化

• 第3優先目標（Priority=1）: 各車両の作業時間の分散を最小化

この方法では、まず時間帯遵守を最優先で解き、その解を一切悪化させない範囲で、次に距離を最小化します。

 重み付けアプローチ（柔軟性重視）
もし「若干の遅延は許容するが、大幅なコスト削減があれば検討したい」という場合は、重み付き目的関数を使います：

 実務的な重み設定例：

（遅延1回 = 1000kmの距離増に相当）

（距離1km = コスト1単位）

（偏差1時間 = 距離10kmに相当）

この重みは、「時間帯遅延1回を避けるために、何kmまでの遠回りを許容するか」 という経営判断を数値化したものです。 

❸ 左折制限や高さ制限など、一部店舗の進入ルールのモデル化

左折制限・右折禁止

これは非対称距離行列として扱います。

• 店舗Aから店舗Bへの距離: 5km（左折可能）

• 店舗Bから店舗Aへの距離: 12km（左折不可のため大回り）

つまり、距離行列を作成する際に、進入ルールを反映した実際の走行距離・時間を登録します。

高さ制限・車両制限

Indicator Constraint（指示制約） を使います。

例：店舗Sに高さ制限があり、車両Tは進入不可の場合

これは、モデル構築時に該当する変数を固定するか、制約として明示的に追加します。

 実装の簡便性

パイロットでは、まず進入制約のない店舗だけで試し、次のステップで制約店舗を追加するのが現実的です。

  ❹ 緊急の当日追加（15時に1店舗追加）への対応
これはDynamic Routing（動的ルーティング） の問題です。

アプローチ①：部分的な再最適化
既存ルートをできるだけ維持しながら、追加店舗を挿入します。

1. 既に出発済みの車両は固定

2. まだデポにいる車両、または現在訪問中の店舗が少ない車両のルートのみを再最適化

3. 追加店舗を優先的に、余裕のある車両に割り当て

 アプローチ②：固定制約付き最適化
既存ルートの大部分をWarm Start（初期解）としてGurobiに渡し、変更可能な部分のみを最適化します。

 実装イメージ

• 既存ルートのうち、訪問済みの部分は変数を固定

• 未訪問部分のみを含む小規模問題として再最適化

• 解の計算時間：数秒〜1分程度（パイロット規模）

この機能は、GurobiのMIPStart（初期解の提供） 機能を使うことで実現できます。

 ❺ 解の計算時間の目安と、近似解の扱い方

パイロット規模（50-80店舗、10-15台）での計算時間

• 最適解を求める場合: 数分〜30分程度（問題の複雑さに依存）

• 実用的な良質解を得る場合: 30秒〜3分程度

Gurobiは、最適解を見つける前でも、途中経過で「現在の最良解」を逐次更新します。

 実用的な近似解の扱い方
以下のパラメータで制御できます：

1. MIPGap（最適性ギャップ）: 例えば5%に設定

   • 「最適解の5%以内の解が見つかれば停止」

   • 設定: model.Params.MIPGap = 0.05

2. TimeLimit（時間制限）: 例えば3分に設定

   • 「3分経過したら、その時点の最良解を返す」

   • 設定: model.Params.TimeLimit = 180（秒）

 解が出ない場合の対応

• 制約が厳しすぎて実行可能解が存在しない場合、GurobiはIIS（Irreducible Inconsistent Subset：矛盾制約の最小集合）を計算し、どの制約が矛盾しているかを診断できます。

• 例：「全店舗を時間帯内に訪問できない」→ 車両台数不足、または時間帯が狭すぎる

❻ 現場への共有：出力形式（地図表示・時系列表）

推奨出力形式

 A. 表計算ソフト形式（ルート詳細表）

 B. 地図表示（Webベース）

• PythonのFoliumライブラリや、Google Maps APIを使って、ルートを地図上に可視化

• 各ルートを色分けし、訪問順に番号を表示

 C. ガントチャート（時系列表）

• 横軸：時刻、縦軸：車両ID

• 各車両の移動時間・作業時間を棒グラフで表示

 サンプル出力のコード例

後ほど、簡易的なPythonコードのサンプルをお示しできます。

  ❼ 既存フロー連携：毎朝の出荷量CSVを取り込んでワンクリック出力

 理想的なワークフロー

[ 毎朝の出荷量CSV ]
↓
[ Pythonスクリプト実行（ワンクリック） ]
├─ データ読込・前処理
├─ Gurobiモデル構築
├─ 最適化実行（3分以内）
└─ 結果出力（表計算ソフト、地図、PDF）
↓
[ 人手の調整画面（オプション） ]
├─ 時間帯の微修正
├─ 特定店舗の優先度変更
├─ 車両の追加・削除
└─ 再最適化ボタン
↓
[ 最終ルート確定 → 現場へ配信 ]

 技術的な実現方法

1. バッチ処理化

   • Pythonスクリプトを.batファイル（Windows）や.shファイル（Linux）でラップ

   • ダブルクリックで実行

2. 簡易Web UI（Flask/Streamlit）

   • ブラウザ上でCSVをアップロード

   • ボタンクリックで最適化実行

   • 結果をダウンロード

3. 調整画面

   • 表計算ソフトのマクロ、またはWeb UIで微修正機能を提供

   • 修正後、再度Gurobiを呼び出して再最適化

  【成功基準の妥当性チェック】
Aさんが設定された目標値について、実務的な観点からコメントします：

 パイロット後、実績データをもとに調整することをお勧めします。

  【難所への対処：冷蔵/常温分離と出荷バッチ】

 冷蔵/常温の分離
これはFleet Heterogeneity（異種車両混在）の問題です。

• 各車両に温度帯属性を持たせる

• 各店舗の出荷量に冷蔵/常温属性を持たせる

• 制約：車両Vが店舗Sを訪問する場合、

  

モデル上は、車両ごとに訪問可能店舗を事前にフィルタリングすることで実装します。

 出荷バッチ（出荷データをバッチごとに分けて一括送信する方法）との整合
出荷バッチは、デポでの出発時刻に制約を設けることで表現できます。

• 第1波：08:00出発

• 第2波：09:30出発

各車両の出発時刻を固定するか、離散的な選択肢として変数化します。

  【次のステップ：パイロット実施に向けて】

1. データ整備

   • 上記フォーマットに沿って、店舗マスタ・出荷量・車両マスタを表計算ソフトで準備

   • 距離・時間行列の取得方法をご相談（Google Maps APIの利用など）

2. 簡易モデルの構築

   • 最もシンプルなVRPTWモデルから開始

   • 段階的に制約を追加（冷蔵/常温分離、負担平準化など）

3. Pythonコードのサンプル提供

   • Gurobiを使った実装例をお示しします

   • データ読込から結果出力までの一貫したスクリプト

4. 実績との比較評価

   • 現行手組みルート vs 最適化ルートの定量比較

   • 3指標（遵守率、距離、偏差）でA/Bテスト

 【ご質問・確認事項】

1. 距離・時間行列の作成について、Google Maps APIの利用を想定してよろしいでしょうか？それとも、既存の地図ソフトから出力できるデータがありますか?

2. パイロット対象の具体的な日付や店舗リストは確定していますか？まずは1日分のデータでモデル検証を行うのがよいかと思います。

3. Gurobiのライセンスは既にお持ちでしょうか？もしまだでしたら、無料トライアル（30日間）から始めることができます。

4. Pythonの実行環境は整っていますか？環境構築のサポートも可能です。

5. 次のステップとして、簡易的なサンプルコードを作成してお見せすることも可能です。どの程度の粒度でコードをご希望でしょうか？

ご不明点があれば、何でもお気軽にお尋ねください！

Aさん

Gurobotさん、詳しいご説明をありがとうございます。

正直、数理最適化という言葉自体になじみがなく、内容の一部はまだ理解が追いついていませんが、すごく整理されたご回答でイメージが湧いてきました。うちの現場でも「どの車で、どの順番にまわるか」を決めるのに毎日かなりの時間を使っており、まさにその部分を自動化できるのではと期待しています。

後編では、数理最適化の実際のモデルを組みはじめるところまで踏み込んでいきます。

▼ Gurobot連載第2回｜「表計算ソフトの限界」が見えたとき（後編）はこちら
https://www.gurobi.com/jp_blog/category01-006-02/