ルートプランのライフサイクル

このページでは、Route Optimization API を使用したルートプランのライフサイクルについて説明します。ルートのニーズの特定から、システムに統合されたルートプランの作成までを扱います。

ルートプランのステージに沿って進むと、次の目標を達成できます。

  • フリート運用をマッピングする: 実際のフリート、複雑な制約、ビジネス目標を API のコードに変換します。
  • ビジネスに合わせてルートプランを最適化する: 目標を達成し、日々の業務を改善できるようにルートプランを調整する方法を理解します。
  • 本番環境にデプロイする: ルートプランを日常業務に組み込んで実装します。

次の図は、ルートプランのライフサイクルを示しています。

以下のテキストで説明するルートプランのライフサイクルのフロー図

ルートプランの実装フェーズは、API を最初に統合するとき、またはビジネス要件が大幅に変更されたときに発生します。ステージ 1 ～ 5 を対象としています。

日常業務フェーズは軽量で、改善は最小限です。ステージ 2 ～ 4 を対象としています。

ルートのライフステージは次のとおりです。

  1. 問題をスコープする: API の使用を開始する前に、目標、リソース、タスク、制約を特定して整理し、オペレーションの全体像を把握します。
  2. データをマッピングする: ビジネスの現実を API パラメータに変換して、ルートプランにフリートの運用方法を反映させます。
  3. リクエストを作成してルートプランを取得する: API にデータを入力して、最適化されたルートプランを取得します。
  4. ルートプランを調整する: ルートプランをテストし、制約と目標を調整して、すべてのニーズを満たすようにルートプランを繰り返し調整します。
  5. ルートプランを統合する: ルートプランを既存のシステムに接続して、実用的なナビゲーションを提供します。

問題の範囲を確認する

API を使用する前に、日々の業務の詳細を明確なデータカテゴリに整理する必要があります。これにより、現在のリソースとタスク、それらの制約、フリートで達成したい目標を明確にして、実装プロセスを開始できます。

リソースとタスクを特定する

ルートプランを計画する際の重要なステップは、リソースとタスク（車両と配送）を特定することです。

車両 配送
  • Number（台数）: 所有している車両の台数をお知らせください。
  • 場所: 車両の始点と終点はどこですか？
  • 時間: 車両の運転手の業務時間はどのくらいですか？
  • 容量: 車両の制限事項は何ですか？
  • 費用: フリートの運用費用はどのくらいですか？
  • 場所: 集荷場所と配達場所はどこですか？
  • 要件: 荷物の重量またはサイズはどのくらいですか？
  • 制約: 納品に特定の時間帯はありますか？
  • サービス時間: 運転手が駐車して荷物を降ろすのにかかる時間。
  • 要件: 配送に特定の車種やドライバーが必要ですか？

制約を特定する

制約は、車両の使用方法と荷物の取り扱い方法に関する制限です。ほとんどのオペレーションを決定し、最適化されたルートプランを作成するうえで不可欠です。

制約は一般的に次の 2 つのカテゴリに分類されます。

厳格な制約 ソフト制約
これらは破ることができない上限です。たとえば、トラックの最大積載量を超える重量を運ぶことはできません。また、店舗の閉店後にドライバーが荷物を集荷することもできません。 これらは、通常はペナルティ費用が発生しますが、必要に応じて違反できる設定です。たとえば、トラックの積載量を 80% に抑えたい、目標時間より前に配達したいといった希望があるものの、より良いルートが見つかるなら、これらの制限を超えても構わない、といった場合です。

一般的な制約は次のとおりです。

  • 容量の上限: 車両が運搬できるアイテムの最大重量、最大容量、最大数。
  • 時間枠: 訪問可能な特定の時間帯、または運転手の特定の勤務時間。
  • 費用: 車両の運行費用または配送のスキップ費用。この API の主な目的の 1 つは、費用対効果の高いルートプランを生成することです。
  • 運転手の休憩: 労働法で義務付けられている、一定の業務時間後の運転手の休憩時間。

ビジネス目標を設定する

リソースとタスク、およびそれらの制限事項を確立したら、ビジネスにとって最も重要な指標を確立します。これらの目標は制約と密接に関連しており、ルートを計画する際に最も重要なことを判断するのに役立ちます。

ビジネス目標の例を次に示します。

規模 距離 時間 費用
使用する車両の数を最小限に抑えるか、フリート全体を使用して作業日を早く終えるか。 燃料を節約するために最短経路を選択しますか？それとも、高速道路を使用するため距離は長くなるものの、より速いルートを選択しますか？ 総労働時間を最小限に抑えたいですか？それとも、特定の時間に到着することを優先して、ルート上の時間を長くしても構いませんか？ 賃金や燃料などの運用費用を最小限に抑えるか、厳しい納期を満たすために費用を増やすか。

データをマッピングする

データを収集したら、API のプロパティと一致するようにマッピングします。これにより、ビジネスの現実を考慮したルートプランを返すために必要なすべての情報がオプティマイザーに提供されます。

次の表のパラメータを使用して、問題の範囲を特定するでマッピングしたリソース、タスク、制約、目標をマッピングします。

変数のマッピング

現実世界のコンセプト API パラメータ 説明
運転手または車両 model.vehicles[] フリート内の 1 台の車両を表します。
デポの場所 vehicles[].startWaypoint
vehicles[].endWaypoint 		車両が経路の開始地点と終了地点として使用する場所。
営業時間 model.globalStartTime
model.globalEndTime 		フリート全体のオペレーションの最も早い開始時刻と最も遅い終了時刻。
タスクまたはパッケージ model.shipments[] ジョブを表します。pickup、delivery、またはその両方になります。
タスクの場所 pickups[].arrivalWaypoint
deliveries[].arrivalWaypoint 		ジョブが行われる地理的位置。
サービス時間 pickups[].duration
deliveries[].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 車両が稼働している時間（移動時間と待機時間を含む）ごとに料金を適用します。完了までの時間を短縮することを優先します。
移動時間を最小限に抑える vehicles[].costPerTraveledHour 移動に費やした時間に対して費用を適用します。これにより、渋滞に巻き込まれている状態（費用がかかる）と、停車場で待機している状態（費用が安くなる可能性がある）を区別できます。
特定のタスクの優先順位を上げる shipments[].penaltyCost 特定の配送がスキップされた場合に費用を適用します。この値を高く設定すると、重要なタスクがオプションのタスクよりも優先されます。

リクエストを作成してレスポンスを取得する

Route Optimization API を使用してルートプランを生成する手順は次のとおりです。

  1. 環境を構成する: Google Cloud プロジェクトを設定し、API を有効にして、認証を構成します。手順については、スタートガイドをご覧ください。この手順は 1 回だけ行ってください。
  2. リクエストを送信する: 前のセクションで定義したデータ マッピングを使用して、リクエスト本文を作成します。エンドポイント、ヘッダー、リクエストの形式については、API リクエストを行うをご覧ください。
  3. レスポンスを理解する: API からレスポンスを受け取ったら、ルートプランと各パラメータの意味を理解します。レスポンスを解釈するをご覧ください。

ルートプランを調整する

現実世界のロジスティクスを API の費用と制約に変換するのは複雑な作業です。最初のルートプランは、ビジネス目標やドライバーの期待と一致しない可能性があります。ルートプランの調整は、返されたルートをテストし、目標を達成する設定が見つかるまでパラメータを調整する反復プロセスです。

目標と制約を調整する

生成されたルートプランがニーズに合わない場合は、特定のパラメータを変更して別の結果を得ることができます。パラメータを厳しくしたり緩めたりすると、ルートプランで競合する目標が解決される方法が変わります。パラメータを緩めることは、ルートプランでエラーの原因となっているパラメータを効率的に見つける方法です。

次の表に、一般的なルーティングの問題と、その解決のために調整できるパラメータを示します。

シナリオ パラメータ 調整 説明
重要な配送がスキップされる shipments[].penaltyCost 価値を高めるか、他の配送にペナルティ料金を追加する 配送が任意の場合は、ペナルティ費用を増やして優先度を上げます。配送が必須（ペナルティ費用がない）の場合は、ペナルティ費用を重要度の低いその他の配送に追加します。これにより、重要な荷物のために車両の時間と容量を確保できます。
タイミングにより配送がスキップされました softStartTime / softEndTime ソフト タイム ウィンドウを追加する ハード タイム ウィンドウでは、1 分でも遅れたタスクはドロップされます。ソフト ウィンドウを使用すると、割り当てを失敗するのではなく、「コスト」を支払うことで、ドライバーはスケジュールから少し遅れて到着できます。
重量超過のため配送をスキップしました loadLimits[].softMaxLoad、costPerUnitAbove ソフトロードの需要を追加する 荷物を残すのではなく、車両が理想的な容量をわずかに超えることを許可します（ペナルティあり）。
フリートの過負荷のため、配送をスキップしました model.vehicles[] または shipments[].timeWindows 車両または休憩時間枠を追加する 現在の車両数では配送が多すぎる場合は（特にピーク時）、車両を追加するか、配送時間帯を広げてワークロードを分散します。
ルートが長すぎる、または非効率的である vehicles[].costPerKilometer / costPerHour 費用を追加するか、価値を高める 移動のコストが高いことを API に伝え、遠く離れた孤立した停車地を削除して、フリートのルートを短縮するように促します。
ドライバーのシフトが長すぎる vehicles[].routeDurationLimit または model.vehicles[] 利用時間の上限を追加する、または車両と上限を追加する ドライバーが道路で費やす合計時間に上限（8 時間など）を適用します。車両を追加するだけでは、ルートは短縮されません。ソルバーにワークロードをより大きな車両に分散させるように強制する時間制限も適用する必要があります。

ルートプランを更新する

ルートプランは、ベースを同じに保ちながら更新する必要があることがよくあります。たとえば、アクティブなドライバーのスケジュールに集荷を追加する場合などです。これを行うには、以前のソリューションに基づいて API に開始点を提供する挿入パラメータを使用します。これにより、API は新しいプランをゼロから計算するのではなく、既存のプランを変更できます。

次の方法は、挿入パラメータを使用してルートプランを更新するさまざまな方法です。

  • 以前のレスポンスから新しいリクエストの injectedFirstSolutionRoutes フィールドにルートを渡します。これにより、最適化検索が高速化され、直前の配送の統合など、毎日のオペレーション開始前の再計画に役立ちます。
  • injectedSolutionConstraint フィールドを使用して、変化の度合いを制御します。これは、オペレーションがすでに進行中の場合に便利です。これにより、ドライバの現在のシーケンスを維持したり、すでに実行されたプランの一部を修正したりできます。
  • interpretInjectedSolutionsUsingLabels を true に設定して、更新されたルートが正しい車両に割り当てられたままになるようにします。これは、インデックスではなくラベルを使用してルートを照合するため、配送や車両の追加または削除を行う実験で役立ちます。このため、車両と荷物のラベルはすべて一意である必要があります。

ルートプランを統合する

最終的なルートプランは、制約と目標に従いながら、リソースとタスクの最適化された管理を表すデータ オブジェクトです。このルートプランをシステムに統合して、日常業務で使用します。通常、フリート マネージャー向けのルートプランの可視化と、ドライバーへのターンバイターン方式の指示の送信が含まれます。

可視化

フリート管理者がルートプランを確認してモニタリングできるようにするには、次の方法でルートプランを可視化します。

フリート管理者がルートプランを確認してモニタリングできるように、ダッシュボードの地図にルートプランを表示できます。現在の開発段階に応じて、次の方法でルートプランを可視化できます。

  • コードなしで探索する: オープンソースの Route Optimization アプリを使用すると、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 は予定されている訪問順序と車両のリアルタイム追跡をペア設定します。