メインコンテンツまでスキップ

車両スラック (Vehicle slack)

車両ルーティング問題 (VRP) のコンテキストでは、スラック（一般に 待機時間 (waiting time) とも呼ばれます）は、車両とドライバーが停留所で費やさなければならない非生産的なアイドル時間です。

この待機時間は、車両が場所のサービス時間枠が開く 前 に到着したときに発生します。

スラックが発生する場所: 具体的な例​

車両に、時間枠が午前9時〜午前11時である「顧客 B」への配達があるとします。

  • 車両到着: 午前8:40
  • 最速サービス時間: 午前9:00（時間枠の開始）
  • サービス開始: 午前9:00
  • 結果としてのスラック: 午前8:40（到着）から午前9:00（サービス開始）までの 20分間 が スラック です。ドライバーは待たなければなりません。

目的: スラックが重要な指標である理由 (Purpose: Why Slack is a Key Metric)​

スラックは、総ソリューションコストの重要な要素です。アイドル状態の車両とドライバーは、ビジネスにとって現実世界のコスト（ドライバーの賃金、車両の非稼働）を表します。

オプティマイザーの目標は、移動時間を最小限に抑えることだけでなく、総コスト を最小限に抑えることです。スラックにコストを割り当てることで、オプティマイザーにドライバーの時間を評価し、ルート効率が良いだけでなく、運用効率も良いソリューションを見つけるように指示します。

オプティマイザーがスラックをどのように扱うか: コストのトレードオフ (How the Optimizer Treats Slack: The Cost Trade-Off)​

オプティマイザーは、スラックを「自由な」時間とは見なしません。待機に対する人工的なコスト（例：スラック1分あたり10ユニットのコスト）でシステムを構成します。このコストは、総ソリューションコストに因数分解されます。

Total Solution Cost = Travel Cost + Vehicle Cost + Penalty Costs + Slack Cost

オプティマイザーは、インテリジェントなトレードオフを行います。そのオプションが他の代替案よりも安い場合にのみ、スラックを 許可 します。

トレードオフの例:

オプティマイザーは、停留所 A と停留所 B にサービスを提供するための2つの可能なルートを評価しています。

  • オプション 1: スラックが発生する

    • ルート: 停留所 A -> 停留所 B
    • 移動時間: 30分
    • 待機時間: 停留所 B で25分のスラック。
    • 総コスト: Cost(30m Travel) + Cost(25m Slack)

  • オプション 2: スラックを回避する

    • ルート: 停留所 A -> (長く、間接的なルート) -> 停留所 B
    • 移動時間: 60分（ドライバーは停留所 B に時間通りに到着するために道路で「時間をつぶす」）。
    • 待機時間: 0分のスラック。
    • 総コスト: Cost(60m Travel)

結果: オプティマイザーは、Cost(25m Slack) がオプション 2 の追加の 30m Travel のコストよりも 少ない 場合、オプション 1 を選択します。より長いルートで燃料と時間を無駄にするよりも、停留所で待つ方が安いことを正しく識別します。

主要原則: 待機コストの構成 (Key Principle: Configuring Wait Cost)​

待機コスト（スラックの分/時間あたりのコスト）は、強力な調整パラメータです。

  • 高い待機コストを設定: オプティマイザーに次のように伝えます。「ドライバー/車両の時間は非常に貴重です。どんな犠牲を払っても待機を避けてください。スラックを防ぐために、車両により長いルートをとらせたり、別の車両を使用したりすることを望みます。」
  • 低い（またはゼロの）待機コストを設定: オプティマイザーに次のように伝えます。「待機は無料です。移動距離と使用される車両の数を最小限に抑える限り、ドライバーがどれだけ長くアイドル状態であっても気にしません。」

このコストのバランスをとることは、紙の上で効率的であり、現実世界で実用的なルートを作成するための鍵です。

警告

厳密な最大スラック制限を課すと、受け入れられるソリューションの数が減り、ソルバーが制約を満たす初期ソリューションを見つけられなくなり、拒否される予約が増加する可能性があります。

他のコストとのトレードオフとしてのスラックの最適化 (Optimizing slack as a tradeoff with other costs)​

Stateless API では、スラック時間をコストとして扱うようにオプティマイザーを構成できます。これは、ドライバーの休憩もサポートしながらスラックの最小化を可能にする新しいローカル検索実装によって実現されます。これにより、距離が短いだけでなく、ドライバーのアイドル時間を最小限に抑えることで運用効率の良いルートの作成が促進され、より良い労働時間とより実現可能な計画につながります。

スラック最適化を有効にするには、リクエストペイロードで次のパラメータを構成する必要があります。

  1. Logistics Mode を有効にする: model_parameters.path_constraints_mode を "logistics" に設定します。このモードは、スラックコスト機能を有効にします。
  2. 車両ごとのスラック最適化をアクティブにする: スラックを最小限に抑えたい各車両について、logistics_optimize_slack を true に設定します。
  3. スラックコストを設定する（オプション）: model_parameters.slack_cost_factor を使用して、スラックの「コスト」を調整できます。これは、目的関数におけるスラック時間の係数です。値が高いほど、オプティマイザーはスラックを減らすために懸命に働き、移動距離が長くなる可能性があります。デフォルト値は 10 で、一般的な範囲は 0.1 から 1000 です。
注意

trip_cost パラメータは logistics パス制約モードと互換性がなく、有効になっている場合は機能しません。

構成例 (Example Configuration)​

注記

この構成は、選択された SWAT ソルバーでのみ機能し、デフォルトでは利用できません。

node_scheduler リクエストでこれらのパラメータを設定する方法を示す JSON スニペットを以下に示します。この例では、エージェント ID dc1e... の車両のスラック時間が最小限に抑えられます。

{
  "engine_settings": {
    "model_parameters": {
      "path_constraints_mode": "logistics",
      "slack_cost_factor": 10
    },
    "calculation_parameters": {
      "scheduling_mode": "prebook_cvrptw"
    }
    // ... その他の設定
  },
  "vehicles": [
    {
      "agent_id": "dc1e0000-2024-0731-aaaa-5206f1c21d09",
      "logistics_optimize_slack": true
      // ... その他の車両プロパティ
    }
  ]
  // ... その他のリクエストプロパティ
}

プレイグラウンド (Playground)​

以下のプレイグラウンドを使用して、車両スラック の概念を試すことができます。 この例では、車両は一連のピックアップとドロップオフを実行します。ドロップオフの時間枠は、車両が一部の停留所間で待機（スラック発生）を強制されるように間隔が空けられており、時間枠制約がどのように避けられないアイドル時間につながるかを示しています。

Loading...
ヒント

スラックコストと確定タイプの処理は難しい場合があります。このユースケースについては、例 を参照してください。