問題作成のベストプラクティスに従う

このセクションでは、旅程計画の問題作成のベストプラクティスについて説明します。ここでは、問題を最も効果的に作成するための重要なポイントとヒントを紹介します。

集配センターでの集荷ジョブや配達ジョブを追加しない

最も一般的な配達サービスのシナリオでは、1つのツアーには1つの集配センターが定義されます。集配センターとは、すべてのジョブが集荷で、車両のシフトが開始および終了する場所のことです。この場合、集配センターでの集荷ジョブを追加する必要はありません。ソルバーは、集配センターでは集荷が実行されるものとデフォルトで見なし、ラストマイル配達の問題を解決します。

同様に、配達のない集荷ジョブがツアー内に設定されている場合、ソルバーはツアー終了時に集配センターに配達されるとデフォルトで見なします。そのため、集配センターへの配達ジョブを追加する必要もありません。

ただし、集配センターに集荷や配達を追加しても問題の解決はできますが、最適化の観点からは次の問題が発生します。

問題の複雑さが増大し、解決に時間がかかる。
ジョブの数が増加するため、場所/トランザクションの数も増加し、問題解決の総コストが増加する。

ただし、次の場合は、集配センターでの集荷ジョブの追加が必要になります。

問題内に複数の集配センターがあり、集配センター間で車両を共有する。
集配センターでの集荷ジョブに特定の時間枠がある。

不要な時間枠の使用を避ける

最も一般的なラストマイル配達のシナリオでは、特定の時間内にジョブを完了する必要がない限り、配達時間枠を設定する必要ありません。このような場合は、個々のジョブに時間枠を追加しないでください。車両のシフト時間枠を使用して車両の時間を定義することで、すべての配達ジョブがその車両のシフト内で完了します。可能な限り時間枠を設定しないことで、問題の複雑さを軽減して、より効果的なソリューションを迅速に生成できます。また、全体的なパフォーマンスを向上させるために、1つの時間枠で十分な場合に複数の時間枠を追加することは避ける必要があります。

詳細については、「時間帯を使用してアクティビティの開始時間を制限する」を参照してください。

スキルを使用するタイミング

スキルは、特定の車両タイプを特定のジョブに割り当てる際に使用できる最も有効な機能の1つです。ジョブのスキルに一致するスキルを持つ車両のみが、そのジョブを実行できます。そのため、スキルは、ジョブに必要な場合にのみ車両に設定する必要があります。スキルを使用するときは、車両の容量、ジョブの需要、シフト時間を考慮する必要があります。適合するスキルを持つ車両に十分な容量または時間が残っていない場合、そのスキルを必要とするジョブは未割り当てのままとなります。

詳細については、「スキルに基づいてジョブを割り当てる」を参照してください。

コストパラメーターを効果的に使用する方法

コストパラメーターは、最適化の観点からソルバーを導く上で重要な役割を果たします。デフォルトでは、ソルバーは、ツアー全体の所要時間や移動距離のみではなく、すべてのツアーの全体コストを最小化するように設計されています。車両には、次の3つのコストパラメーターがあります。

時間コスト - 車両のツアー所要時間 (秒単位) あたりのコスト
距離コスト - 車両のツアー距離 (メートル単位) あたりのコスト
固定コスト - 車両のツアー1回あたりの固定コスト

ソリューションの総コストは、ソリューションで指定されたすべてのツアーにおける上記3つのコスト係数を線形結合したもので、3つのコスト係数がすべて考慮され、最適化の指針となります。

コスト係数は、さまざまなコスト要素の重要な重み付け係数であり、最適化の指針となります。実世界のコストと同一である必要はありません。ソリューションのツアーオブジェクトには、必要に応じて、実世界のコスト係数に基づいて実際のツアーコストの見積もりを計算するためのすべての統計情報が含まれています。

time costとdistance costの比率は、対応する車両タイプが実行する個々のツアーの停止地点の順序に影響を与えます。たとえば、time costを高く、distance costを低く設定すると、総走行距離が長くなるものの、高速走行が可能な道路 (高速道路など) が優先される可能性があり、それが停車地の順序に影響を与える可能性があります。

対照的に、time costを低く、distance costを高く設定すると、ツアーの所要時間が長くなる可能性はありますが、走行距離が短いツアーが優先されます。

fixed costが高く、time costとdistance costが低いと、ツアーの数は減りますが、ツアー全体の距離や所要時間は長くなる可能性があります。

テリトリーを効果的に使用する

テリトリーの最適化機能は、特定の地区やエリアに車両を分散させるという観点から、柔軟性に優れており、車両を有効に活用して、より実用的なツアーを作成するのに役立ちます。

車両の主要なテリトリーは優先度1で追加し、近隣のテリトリーは低い優先度で追加します。これにより、車両は容量と時間に余裕がある場合にのみ、近隣のテリトリーからジョブを引き受けます。

車両が定義されたテリトリー外でジョブを引き受けないようにする場合は、該当する車両タイプに対してstrictフラグをtrueに設定します。この場合、車両は、まだ容量が残っている場合でも、定義されているテリトリー内でのみジョブを引き受けます。

詳細については、「テリトリー別に旅程を最適化する」を参照してください。

不要な運行管理プロファイルの追加を避ける

運行管理プロファイルは、運行管理のルート検索データの定義に使用します。複数のプロファイルは、互いに大きく異なる場合にのみ追加してください。たとえば、次のような場合は異なるプロファイルを追加する必要があります。

異なる車両タイプ (car、truck、scooter、bicycle、pedestrian、bus、privateBus)
一部の車両の特定のパラメーター (回避ルート、オプション、国の除外)
交通状況に応じて、車両ごとに異なる出発時刻を定義する

プロファイルが同じであることが予想される場合は、複製しないでください。

たとえば、次の代わりに：

"profiles": [
     {
      "name": "c1",
      "type": "car"
     },
     {
      "name": "c2",
      "type": "car"
     }
 ]

次のように簡単に使用します：

"profiles": [
    {
      "name": "c1",
      "type": "car"
    }
 ]

ツアーの結果は同じになりますが、問題はより完結になり、ソルバーのパフォーマンスが向上します。

また、制約条件に追加する運行管理プロファイルごとに全体的な処理時間が増加するため、プロファイルの数は最小限に抑える必要があります。

不要な車両タイプの追加を避ける

異なる車両タイプは、それらの間に明確な違いがある場合にのみ指定します (たとえば、集配センターからの開始時刻や終了時刻が異なる場合)。2つの車両タイプが同じ場合には2つの異なる車両タイプを使用することは避け、1つに統合して車両数を2台に増やしてください。このようにすることで、問題の複雑さが減少し、パフォーマンスが向上する可能性があります。

リレーション

sequenceとflexibleのリレーションは制約に対して検証を行わないため、これらのリレーションには可能な限り制約に従ったジョブを追加するようにしてください。

詳細については、「ツアーの再計画のためのリレーション」を参照してください。

需要と容量を活用する

問題を効果的に構築するための基本の1つとして、ジョブの需要と車両の容量を活用することが挙げられます。この2つのパラメーターは必ず考慮する必要があります。問題内のすべてのジョブを割り当てることができるのは、全ジョブの総需要がすべての車両の総容量を超えない場合のみであるためです。

詳細については、「容量制約付き配送計画問題 (CVRP) を解決する」を参照してください。

トラフィック

Tour Planningでは、利用可能な場合にはライブ交通情報がデフォルトで有効になります。場合によっては、ライブ交通情報の状況 (道路閉鎖など) によりジョブの場所に到達できないことがあります。これを回避したい場合は、問題の定義で"traffic": "historicalOnly"を設定することでライブ交通情報を無効にするオプションがあります。その結果、ライブ交通情報が有効な場合には割り当てられなかったジョブが、正常に割り当てられる可能性があります。

未割り当てジョブの理由

ジョブが未割り当てになる理由が複数存在する場合があります (原因がスキル制約と容量制約の両方である場合など)。しかし、現在、ソリューションに表示される未割り当てジョブの考えられる理由は1つのみです。また、場合によっては、実際とは異なる理由でジョブが未割り当てになっている可能性もあります。したがって、未割り当てジョブを割り当てるには、表示されている理由を修正するだけでなく、さまざまな修正を問題の定義に適用することを試みる必要があります。

次のステップ

詳細については、以下を参照してください。

Submit a Vehicle Routing Problem to solve it synchronously (車両ルート検索問題を送信して同期的に解決する)
Submit a Vehicle Routing Problem to solve it asynchronously (車両ルート検索問題を送信して非同期的に解決する)