このページでは、Route Optimization API を使用したルートプランのライフサイクルについて説明します。このライフサイクルは、ルートのニーズの特定から始まり、システムに統合されたルートプランで終了します。
ルートプランのステージに沿って進めると、次の目標を達成できます。
- フリート オペレーションをマッピングする: 物理的なフリート、複雑な制約、ビジネス目標を API のコードに変換します。
- ビジネスに合わせてルート計画を最適化する: ルート計画を調整して、目標を達成し、日常業務を改善する方法を理解します。
- 本番環境にデプロイする: ルートプランを日常業務に組み込んで実装します。
次の図は、ルートプランのライフサイクルを示しています。
ルートプランの実装フェーズは、API を初めて統合するとき、またはビジネス要件が大幅に変更されたときに発生します。ステージ 1 ～ 5 が対象です。
日常業務フェーズはより軽量で、改良は最小限に抑えられます。ステージ 2 から 4 までを対象としています。
ルートのライフサイクルのステージは次のとおりです。
- 問題の範囲を特定する: API の使用を開始する前に、目標、リソース、タスク、制約を特定して整理し、オペレーションの全体像を把握します。
- データをマッピングする: ビジネスの実態を API パラメータに変換して、ルートプランにフリートの運用方法が反映されるようにします。
- リクエストを作成してルートプランを取得する: API にデータを入力して、最適化されたルートプランを取得します。
- ルートプランを改良する: ルートプランをテストし、制約と目標を調整して、すべてのニーズに対応できるようにします。
- ルートプランを統合する: ルートプランを既存のシステムに接続して、実用的なナビゲーションを提供します。
問題の範囲を特定する
API を使用する前に、日々のオペレーションの詳細を明確なデータカテゴリに整理する必要があります。これにより、現在のリソースとタスク、それらを制約するもの、フリートで達成したい目標を明確にして、実装プロセスを開始できます。
リソースとタスクを特定する
ルートプランを計画する際の重要なステップは、リソースとタスク（車両と配送）を特定することです。
| 車両 | 配送 |
|---|---|
|
|
制約を特定する
制約とは、車両の使用方法と配送の処理方法に関する制限です。これらはオペレーションの大部分を左右し、最適化されたルート計画を作成するうえで不可欠です。
制約は一般に次の 2 つのカテゴリに分類されます。
| ハード制約 | ソフト制約 |
|---|---|
| これらは破ることができない上限です。たとえば、トラックは最大積載量を超える荷物を運ぶことはできません。また、ドライバーは店舗の閉店後に集荷することはできません。 | これらは、必要に応じて違反できる設定であり、通常はペナルティ費用が発生します。たとえば、トラックの積載量を 80% に制限したり、目標時間までに配送したりすることを優先したい場合でも、より良いルートを確保するためにこれらの制限を超えても構わないことがあります。 |
一般的な制約には、次のようなものがあります。
- 容量制限: 車両が運搬できるアイテムの最大重量、最大容量、最大数。
- 時間枠: 場所が訪問のために開いている特定の時間枠、またはドライバーの特定のシフト時間。
- 費用: 車両の運行費用または配送をスキップする費用。この API の主な目的の一つは、費用対効果の高いルートプランを生成することです。
- ドライバーの休憩: 通常、労働法で定められている、一定の労働時間後のドライバーの休憩時間。
ビジネスの目標を確立する
リソース、タスク、制限を確立したら、ビジネスにとって最も重要な指標を確立します。これらの目標は制約と密接に関連しており、ルートを計画する際に最も重要なことを決定するのに役立ちます。
ビジネス目標の例としては、次のようなものがあります。
| 規模 | 距離 | 時間 | 費用 |
|---|---|---|---|
| 使用する車両の数を最小限に抑えたいですか？それとも、すべての車両を使用して作業を早く終わらせたいですか？ | 燃料を節約するために最短のルートを希望しますか？それとも、高速道路を利用して、距離は長くなってもより速いルートを希望しますか？ | 合計作業時間を最小限に抑えたいですか？それとも、特定の時間に到着することを優先して、ルートに費やす時間を長くしたいですか？ | 賃金や燃料などの運用費用を最小限に抑えたいですか？それとも、厳しい納期に間に合わせるために、より高い費用を受け入れますか？ |
データをマッピングする
データを収集したら、API のプロパティに一致するようにマッピングします。これにより、オプティマイザーは、ビジネスの現実を考慮したルートプランを返すために必要なすべての情報を得ることができます。
次の表のパラメータを使用して、問題の範囲を特定するセクションでマッピングしたリソース、タスク、制約、目標をマッピングします。
変数のマッピング
| 現実世界のコンセプト | API パラメータ | 説明 |
|---|---|---|
| ドライバーまたは車両 | model.vehicles[] |
フリート内の 1 台の車両を表します。 |
| デポの場所 |
vehicles[].startWaypointvehicles[].endWaypoint
|
車両がルートを開始および終了する場所。 |
| 営業時間 |
model.globalStartTimemodel.globalEndTime
|
フリート全体のオペレーションの最も早い開始時刻と最も遅い終了時刻。 |
| タスクまたはパッケージ | model.shipments[] |
ジョブを表します。pickup、delivery、またはその両方を指定できます。 |
| タスクの場所 |
pickups[].arrivalWaypointdeliveries[].arrivalWaypoint
|
ジョブが実行される地理的位置。 |
| サービス時間 |
pickups[].durationdeliveries[].duration
|
タスクを完了するためにその場所で費やした時間（荷降ろしなど）。移動時間は含まれません。 |
制約マッピング
| 実世界の制約 | API パラメータ | 説明 |
|---|---|---|
| 車両の定員 | vehicles[].loadLimits |
車両容量のハードリミットまたはソフトリミットを設定します。配送の loadDemand が残りの上限を超えると、割り当てられません。 |
| パッケージ サイズ | shipments[].loadDemands |
配送が消費する車両容量。 |
| 車両の制限 | shipments[].allowedVehicleIndices |
特定の車両またはドライバーのみが集荷または配達できるように、配送を制限します。 |
| 営業時間 | shipments[].pickups[].timeWindows または shipments[].deliveries[].timeWindows |
場所を訪問できる時間を設定します。車両がこの時間枠内に到着できない場合、配送はスキップされます。 |
| シフトの長さの上限 | vehicles[].routeDurationLimit |
グローバルな終了時間に関係なく、特定のドライバーが作業できる時間（例: 最大 8 時間）にハードまたはソフトの上限を設定します。 |
| ドライバーの休憩 | vehicles[].breakRule |
一定時間の勤務後の必須休憩など、特定の休憩ルールを適用します。 |
| 道路の規制 | vehicles[].travelMode |
移動手段（DRIVE、BICYCLE など）を指定します。これにより、ルートが合法的な道路に制限され、移動時間の計算に使用される速度が決定されます。 |
目標のマッピング
| 実世界の目標 | API パラメータ | 説明 |
|---|---|---|
| フリートサイズを最小化する | vehicles[].fixedCost |
車両の使用に 1 回限りの費用を適用します。固定費が高いと、合計距離や作業時間を増やすよりも、使用する車両を減らすことが優先されます。 |
| 距離を最小限に抑える | vehicles[].costPerKilometer |
移動距離 1 km あたりの費用を適用します。燃料の節約と摩耗の軽減のために、より短いルートを優先します。 |
| 合計時間を最小化する | vehicles[].costPerHour |
車両が稼働している時間（移動時間と待機時間を含む）ごとに費用を適用します。より迅速な完了を優先します。 |
| 運転時間を最小限に抑える | vehicles[].costPerTraveledHour |
移動に費やした時間に対して費用を適用します。これにより、渋滞に巻き込まれている（費用が高い）場合と、停留所で待機している（費用が安い可能性がある）場合を区別できます。 |
| 特定のタスクを優先する | shipments[].penaltyCost |
特定の配送がスキップされた場合に費用を適用します。この値を高く設定すると、重要なタスクがオプションのタスクよりも優先されます。 |
リクエストを作成してレスポンスを取得する
Route Optimization API を使用してルートプランを生成する手順は次のとおりです。
- 環境を構成する: Google Cloud プロジェクトを設定し、API を有効にして、認証を構成します。手順については、スタートガイドをご覧ください。この手順を行うのは 1 回のみとなります。
- リクエストを送信する: 前のセクションで定義したデータ マッピングを使用してリクエスト本文を作成します。エンドポイント、ヘッダー、リクエストの形式については、API リクエストを行うをご覧ください。
- レスポンスを理解する: API からレスポンスを受け取ったら、ルートプランと各パラメータの意味を理解します。レスポンスを解釈するをご覧ください。
ルートプランを調整する
現実世界のロジスティクスを API のコストと制約に変換することは、複雑なタスクです。最初のルート計画が、ビジネス目標やドライバーの期待に沿っていない可能性があります。ルートプランの調整は、返されたルートをテストし、目標を達成する設定が見つかるまでパラメータを調整する反復プロセスです。
目標と制約を調整する
生成されたルートプランがニーズに合わない場合は、特定のパラメータを変更して異なる結果を得ることができます。パラメータを厳しくしたり緩めたりすると、ルートプランで競合する目標の解決方法が変わります。パラメータを緩めると、ルートプランでエラーの原因となっているパラメータを効率的に見つけることができます。
次の表に、一般的なルーティングの問題と、それらを解決するために調整できるパラメータを示します。
| シナリオ | パラメータ | 調整 | 説明 |
|---|---|---|---|
| 重要な配送がスキップされる | shipments[].penaltyCost |
値を増やすか、他の配送にペナルティ費用を追加します。 | 配送がオプションの場合は、ペナルティ費用を増やして優先度を上げます。配送が必須の場合（ペナルティ費用がない場合）、重要度の低い他の配送にペナルティ費用を追加します。これにより、これらの配送はオプションとなり、重要な配送のために車両の時間と容量を確保できます。 |
| タイミングにより配送がスキップされた | softStartTime / softEndTime |
ソフト タイム ウィンドウを追加する | 厳格な時間枠では、1 分でも遅れたタスクはドロップされます。ソフト ウィンドウを使用すると、ドライバーは割り当てに失敗するのではなく、「コスト」を支払うことで、スケジュールから少し遅れて到着できます。 |
| 重量が原因で配送がスキップされた | loadLimits[].softMaxLoad、costPerUnitAbove |
ソフトロード需要を追加する | 荷物を残すのではなく、車両が理想的な容量をわずかに超えることを許可します（ペナルティあり）。 |
| フリートの過負荷により配送がスキップされた | model.vehicles[] または shipments[].timeWindows |
車両を追加するか、時間枠を緩和する | 現在のフリートに対して配送が多すぎる場合（特にピーク時間帯）、車両を追加するか、配送時間枠を広げてワークロードを分散します。 |
| ルートが長すぎる、または非効率的である | vehicles[].costPerKilometer / costPerHour |
費用を追加するか、価値を高める | 移動コストが高いことを API に伝え、遠く離れた孤立した停車地を削除して、フリートのより密なルートを作成するように促します。 |
| ドライバーのシフトが長すぎる | vehicles[].routeDurationLimit または model.vehicles[] |
期間制限を追加するか、車両と制限を追加します | ドライバーが道路上で費やす合計時間に上限（8 時間など）を適用します。車両を追加するだけでは、ルートは短縮されません。期間制限を適用して、ソルバーがより大きなフリートにワークロードを分散するように強制する必要があります。 |
ルートプランを更新する
多くの場合、アクティブなドライバーのスケジュールに集荷を追加するなど、ベースを同じに保ちながらルートプランを更新する必要があります。これを行うには、挿入パラメータを使用します。挿入パラメータは、以前のソリューションに基づいて API に開始を提供し、新しいプランをゼロから計算するのではなく、既存のプランを変更できるようにします。
挿入パラメータを使用してルートプランを更新する方法は次のとおりです。
- 以前のレスポンスのルートを、新しいリクエストの
injectedFirstSolutionRoutesフィールドに渡します。これにより、最適化検索が高速化され、直前の配送の統合など、日々の業務を開始する前の再計画に役立ちます。 injectedSolutionConstraintフィールドを使用して、変化の度合いを制御します。これは、オペレーションがすでに進行中の場合に便利です。ドライバーの現在のシーケンスを保持したり、すでに実行されたプランの一部を修正したりできます。interpretInjectedSolutionsUsingLabelsをtrueに設定して、更新されたルートが正しい車両に割り当てられたままになるようにします。これは、インデックスではなくラベルを使用してルートを照合するため、配送や車両を追加または削除する際のテストに役立ちます。この場合、すべての車両ラベルと送料ラベルが一意である必要があります。
ルートプランを統合する
最終的なルートプランは、制約と目標に従いながら、リソースとタスクの最適化された管理を表すデータ オブジェクトです。このルートプランをシステムに統合して、日々の業務で使用します。通常、これにはフリート管理者のルートプランを可視化し、ドライバーにターンバイターンの指示を送信することが含まれます。
可視化
フリート管理者がルートプランを確認してモニタリングできるように、次の方法でルートプランを可視化できます。
フリート管理者がルートプランを確認してモニタリングできるように、ダッシュボードの地図にルートプランを表示できます。現在の開発ステージに応じて、次の方法でルートプランを可視化できます。
- コードなしで探索する: オープンソースのルート最適化アプリを使用すると、API がデータを地図上の物理的なパスに変換する方法を確認できます。このウェブ アプリケーションは、コードを記述する前に、シナリオの構築、制約パラメータの調整、結果のルートプランの視覚的なレンダリングを行うことができる探索ツールとして機能します。
- 訪問順序を表示する: 訪問順序を地図上に番号付きのポイントとして表示し、独自のシステムで最適化計画とディスパッチ計画を評価できます。これを行うには、API レスポンスの各ルート内にある
visits配列を見つけます。この配列内のアイテムは、ドライバが実行する必要がある順序で並べられます。このリストを反復処理し、shipmentIndexを使用して各停留所の位置座標を取得し、マッピング ライブラリを使用して、リスト内の順序に基づいて地図上に番号付きマーカーをレンダリングできます。 - 物理ルートを描画する: 計画された正確なルートを地図上に可視化して、オプティマイザーが特定のシーケンスを選択した理由を把握できます。このポリラインは、計画と評価を目的とした想定ルートを表すものであり、ドライバーが実際に走行したリアルタイムのルートではありません。リクエストで
populatePolylines: trueを設定して、各ルートのencodedPolylineフィールドを取得し、Maps JavaScript API のgoogle.maps.geometry.encoding.decodePath()メソッドを使用してデコードします。
ドライバーに配車する
Navigation SDK を使用してターンバイターン方式の経路案内をドライバー アプリに統合するか、Google マップのユーザーアプリへのディープリンクを提供できます。
- Navigation SDK: カスタムのドライバー アプリケーションがある場合は、Navigation SDK for Android または iOS を統合して、アプリ内でターンバイターン方式のルート案内を提供できます。API レスポンスから取得したタスク情報をシステムに統合し、SDK を使用してナビゲーションを行うことができます。API レスポンスから SDK にルートを渡すには、リクエストで
populateTransitionPolylines: trueを設定します。これにより、レスポンスの各遷移に対してrouteTokenが生成されます。 - Fleet Engine: 高度なフリート管理を行うには、API によって生成されたルート計画を Fleet Engine にインポートして、ルートの実行をリアルタイムでモニタリングします。API は評価対象の予定ルートのポリラインを提供しますが、Fleet Engine は予定された訪問シーケンスと車両のライブ トラッキングを組み合わせます。