遷移属性を使用してビジネス ロジックをモデル化する

このガイドでは、遷移属性の可能な使用方法について説明します。このチュートリアルでは、2 つの例（最適化されたルートに車両の駐車時間を組み込む、各ルートが特定の場所への訪問で終わるようにする）を通して、現実世界のシナリオをモデル化する方法を学びます。

始める前に

トランジション属性を使用して、最適化されたルートの特定のトランジションにモデル固有の費用と遅延を追加します。これらの費用と遅延は、使用する車両のパラメータに基づいて地図データから計算された移行期間と費用に加えて計算されます。

トランジションとは、ある地点から次の地点までを結ぶルートのセグメントです。

位置とは、車両のルート上の次のいずれかの地点を指します。

• ルートの出発地。
• 集荷または配達が行われる停車地。
• ルートの終点。

モデルのすべての遷移属性は、リスト ShipmentModel.transition_attributes に追加することで定義します。リストの各要素は、1 つの遷移属性のセットを定義します。この要素は、遷移の開始位置と終了位置のタグを使用して、ルート内の遷移と照合されます。遷移属性の詳細については、TransitionAttributes のリファレンス ドキュメントをご覧ください。

重要なポイント: 遷移属性を使用すると、位置情報のシーケンスに関する多くのビジネス制約を実装できます。たとえば、特定のルートをオプティマイザーにとって魅力のないものにしたり、地点 A から地点 B への直接の移動を禁止したり、地点 A への訪問の後に必ず地点 B への訪問が続くようにしたりできます。

実際のシナリオをモデル化する

このセクションでは、遷移属性を使用して実際のビジネス制約を実装する 2 つの簡単な例を示します。

駐車時間を予約する

このシナリオでは、ドライバーは場所 A に行く前に車両を駐車する必要があります。場所 B は近くにあり、ドライバーは両方の訪問で同じ駐車スペースを使用できます。A の直後に B に立ち寄る場合、駐車スペースから離れて再び駐車する必要がないため、時間を節約できます。Route Optimization API では、移行属性を使用して、運転手が 1 つの駐車スペースから別の駐車スペースに移動する場合にのみ、車両を駐車するための追加時間を追加できます。

駐車時間を訪問時間とは別にモデル化すると、同じ駐車場を使用する訪問がグループ化されたルートの所要時間が短くなります。モデルの精度を高め、オプティマイザーが訪問がグループ化されたルートを優先するようにします。

Route Optimization API リクエストでこれを行う手順は次のとおりです。

1. VisitRequest.duration は、訪問の実施に必要な時間のみ使用します。たとえば、荷物を手渡してお客様から署名を受け取ります。

2. モデルで使用される個別の駐車スペースごとに、モデル内の他の用途で使用されていない新しいタグ（PARKING_123 など）を使用します。

3. このタグを次の場所に追加します。

   1. この駐車スペースを使用するすべての訪問リクエストで VisitRequest.tags。

   2. Vehicle.start_tags 車両がこの駐車スポットからルートを開始する場合。

   3. 車両がこの駐車スペースでルートを開始または終了する場合の Vehicle.end_tags。

4. 新しい駐車タグごとに、ShipmentModel.transition_attributes にエントリを追加します。これにより、別の駐車位置から来た場合に駐車の遅延が追加されます。手順は次のとおりです。

   1. TransitionAttributes.excluded_src_tag と TransitionAttributes.dst_tag を PARKING_123 に設定します。

   2. TransitionAttributes.delay を、車両の駐車に必要な時間に設定します。

   たとえば、場所のタグが PARKING_123 で、車両の駐車に 150 秒かかる場合は、ShipmentModel.transition_attributes に次のエントリを追加します。

   {
     "excluded_src_tag": "PARKING_123",
     "dst_tag": "PARKING_123",
     "delay": "150s"
   }
   

ルートの最後に必須の清掃

このシナリオでは、ルートの最後に車両を清掃する必要があります。次の追加の制約があります。

• 清掃は、車両基地に戻る前に専門の清掃施設で行われます。最適化されたルートでは、車両の集荷場所と配達場所に基づいて、最適なクリーニング施設が使用されます。
• 清掃後、車両は追加の集荷や配達を行ってはなりません。
• 運転手がそこまで運転して車両を清掃する時間は、運転手の勤務時間に含まれ、ルートの最大所要時間内に収まる必要があります。

この要件は、空のルートか、最後に清掃施設に立ち寄ったルートのみを許可することでモデル化します。Route Optimization API では、清掃施設またはルートの出発地点以外の場所からルートの終点ウェイポイントへの移行を禁止することで、これを実現します。

1. モデルのどこでも使用されていない 2 つの新しいタグ（CLEANED や ROUTE_END など）を選択します。前者は車両がクリーンになる場所、後者はルートの終点です。
2. 車両ごとに、次の属性を持つクリーニング施設への訪問を表す新しい配送専用の配送を追加します。
   1. 各クリーニング施設の場所は、この配送の配送訪問リクエストとして表す必要があります。
   2. 清掃施設の配送の各訪問リクエストの VisitRequest.tags に CLEANED を追加します。この場所から出発する車両がクリーンであることを示します。モデル内の他の訪問リクエストでは、このタグを使用しないでください。これにより、車両が「清掃済みでない」と見なされます。
   3. 車両が未使用の場合に、penalty_cost を小さい数値に設定して、オプティマイザーがこの配送をスキップできるようにします。

3. 車両ごとに、CLEANED を Vehicle.start_tags に追加します。これは、前営業日の終わりに清掃されたと想定して、車両が集荷や配達を行う前に車両を清掃済みとしてマークし、開始ウェイポイントから終了ウェイポイントに直接移動できるようにするために使用されます。このようなルートが実際に発生しない場合でも、このシナリオを許可することで、オプティマイザーが最適化されたルートをより効率的に検索できるようになります。

4. 車両ごとに、ROUTE_END を Vehicle.end_tags に追加します。

5. 次のプロパティを使用して、車両がクリーンでない場合に車両の最終経由地に到着することを禁止する新しいエントリを ShipmentModel.transition_attributes に追加します。

   1. TransitionAttributes.excluded_src_tag を CLEANED に設定します。

   2. TransitionAttributes.dst_tag を ROUTE_END に設定します。

   3. TransitionAttributes.delay に大きい値を設定します。遅延を最大ルート時間よりも長くすると、オプティマイザーがルートでこのトランジションを使用することを事実上禁止できます。

   たとえば、モデルの時間スケールが 1 営業日の場合、24 時間（86,400 秒）の遅延を使用して、清掃施設とルートの開始以外の場所からルートの終了への移行を禁止できます。

   {
     "excluded_src_tag": "CLEANED",
     "dst_tag": "ROUTE_END",
     "delay": "86400s"
   }
   

注意: 遷移を禁止しすぎると、特定の集荷や配送へのアクセスが完全にブロックされ、多くの配送またはすべての配送がスキップされるソリューションのみがオプティマイザーによって検出されることがあります。

遅延と費用のどちらを選択するか

遅延と費用のどちらを選択するかは、実装されたビジネス ロジックと制約の性質によって異なります。TransitionAttributes.delay を設定することは、ハード制約を実装する場合や、費やした時間という観点からトレードオフを表現する場合に最適です。TransitionAttributes.cost は、追加費用として表されるソフトな設定やトレードオフを実装する場合に適しています。時間と費用の両方が関係する場合は、遅延と費用を任意に組み合わせることができます。

車両の清掃の例では、非常に長い遅延を使用しています。これは、ルートの最後に車両を清掃することが必須要件であり、長い遅延によってオプティマイザーがこの要件を無視しないようにするためです。費用のみを設定した場合、オプティマイザーは、他の場所で費用を補う方法が見つかれば、清掃をスキップすることを選択する可能性があります。たとえば、車両の清掃を行わないことで「節約」された時間で、より多くの配送を行うなどです。

駐車の例では、車両の駐車に必要な追加時間に対応する短い遅延を使用します。ドライバーが有料駐車場に停車した場合、遅延と組み合わせて費用を使用することもできます。

すべての訪問リクエストに一致するトランジション属性を追加する方法

上記の例では、特定のタグを持つロケーション、またはタグを持たないロケーションに一致する遷移属性を使用しています。ただし、すべての遷移に適用される遷移属性を追加する必要がある場合はどうでしょうか。

各 TransitionAttributes メッセージには TransitionAttributes.src_tag と TransitionAttributes.excluded_src_tag のいずれか 1 つと、TransitionAttributes.dst_tag と TransitionAttributes.excluded_dst_tag のいずれか 1 つが含まれている必要があるため、タグを省略することはできません。

ただし、TransitionAttributes.excluded_src_tag または TransitionAttributes.excluded_dst_tag をモデル内のどこでも使用されていないタグに設定することで、すべてのタグを照合できます。これにより、このタグのないすべての場所が一致しますが、どの場所でも使用されていないタグを意図的に選択したため、これらの移行属性はすべての場所と一致します。

関連情報

• 費用モデル パラメータ