このページでは、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 キロメートルごとに費用を適用します。燃料の節約と摩耗の軽減のために、より短いルートを優先します。 |
| 合計時間を最小化する | vehicles[].costPerHour |
車両が稼働している時間（移動時間と待ち時間を含む）ごとに費用を適用します。完了までの時間を短縮することを優先します。 |
| Minimize drive time | 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 は予定された訪問順序と車両のリアルタイム トラッキングをペア設定します。