複数の時間枠 (Multiple Time Windows)
標準的な VRP 問題では、ノード（ピックアップまたはドロップオフ）には通常、open_time_ts と close_time_ts で定義される単一の時間枠があります。ただし、多くの現実世界のシナリオでは、場所は複数の互いに素な時間間隔の間にアクセスできる場合があります。たとえば、倉庫は08:00から12:00まで、さらに14:00から18:00まで配達のために開いており、その間に昼休みで閉まる場合があります。
複数の時間枠機能を使用すると、ノードに対してこれらの追加の有効なタイムスロットを定義できます。
構成 (Configuration)
ノードに複数の時間枠を指定するには、ノードオブジェクトの time_windows プロパティを使用します。このフィールドでは、ピックアップまたはドロップオフ場所での予約に対して複数の時間枠を設定できます。
- プライマリ時間枠: 標準の
open_time_tsおよびclose_time_tsフィールドによって定義されます。 - 追加の時間枠:
time_windows配列内のオブジェクトのリストとして定義されます。
マージロジック (Merging Logic)
time_windows が設定されている場合、結果として得られる有効な時間枠のセットは、プライマリ時間枠（open_time_ts/close_time_ts から）と time_windows で定義された追加のウィンドウの組み 合わせになります。
たとえば、このフィールドに1つの追加の時間枠が設定されている場合、結果として得られる有効な時間枠セットには2つの要素があります。1つは予約自体から、もう1つはこのフィールドからです。このフィールドは、「追加の」時間枠と考えることができます。
このフィールドに時間枠が設定されている場合、および min_pickup_time/max_pickup_time（または open_time_ts/close_time_ts）も設定されている場合、アルゴリズムはすべての時間枠を考慮し（重複する時間枠のマージロジックが適用されたすべてのフィールドの組み合わせとして）、それらをマージします。設定された時間枠は重複する可能性がありますが、これによりルートの効率が低下する可能性があります。
Stateless API のパラメータ詳細
| パラメータ | タイプ | 説明 |
|---|---|---|
time_windows | オブジェクトの配列 | 追加の時間枠オブジェクトのリスト。 |
時間枠オブジェクト構造:
| フィールド | タイプ | 説明 |
|---|---|---|
open_time_ts | string (date-time) | 時間枠の開始。 |
close_time_ts | string (date-time) | 時間枠の終了。 |
close_time_ts_dynamic | string (date-time) | 時間枠の動的終了（通常は close_time_ts と同じ）。 |
JSON ペイロードの例 (Example JSON Payload)
この例では、dropoff_A には午前中 (09:00 - 10:00) のプライマリ時間枠と、午後 (14:00 - 15:00) の追加の時間枠があります。
{
"nodes": [
{
"uid": "dropoff_A",
"node_type": "dropoff",
"open_time_ts": "2025-11-21T09:00:00Z",
"close_time_ts": "2025-11-21T10:00:00Z",
"time_windows": [
{
"open_time_ts": "2025-11-21T14:00:00Z",
"close_time_ts": "2025-11-21T15:00:00Z",
"close_time_ts_dynamic": "2025-11-21T15:00:00Z"
}
],
// ... その他のノードプロパティ
}
]
}
Integration API での使用
Integration API を介して予約をアップロードする場合、pickup_time_windows および dropoff_time_windows プロパティを使用して複数の時間枠を指定できます。これらのフィールドを使用すると、ピックアップおよびドロップオフ場所の追加の有効なタイムスロットをそれぞれ定義できます。
これらの配列内の時間枠オブジェクトの構造は、上記の ノード構成 と同じです。
予約ペイロードの例 (Example Booking Payload)
この例では、予約には午前のプライマリピックアップウィンドウと午後の追加のピックアップウィンドウがあります。
{
"bookings": [
{
"uid": "booking_1",
"pickup_location_name": "Warehouse A",
"min_pickup_time": "2025-11-21T09:00:00Z",
"max_pickup_time": "2025-11-21T10:00:00Z",
"pickup_time_windows": [
{
"open_time_ts": "2025-11-21T14:00:00Z",
"close_time_ts": "2025-11-21T15:00:00Z",
"close_time_ts_dynamic": "2025-11-21T15:00:00Z"
}
],
// ... その他の予約プロパティ
}
]
}
ドロップオフ時間枠付きの予約ペイロードの例 (Example Booking Payload with Dropoff Time Windows)
この例では、予約にはプライマリドロップオフウィンドウと複数の追加のドロップオフウィンドウがあります。
{
"bookings": [
{
"uid": "booking_2",
"dropoff_location_name": "Store B",
"min_dropoff_time": "2025-11-21T10:00:00Z",
"max_dropoff_time": "2025-11-21T11:00:00Z",
"dropoff_time_windows": [
{
"open_time_ts": "2025-11-21T16:00:00Z",
"close_time_ts": "2025-11-21T17:00:00Z",
"close_time_ts_dynamic": "2025-11-21T17:00:00Z"
},
{
"open_time_ts": "2025-11-21T20:00:00Z",
"close_time_ts": "2025-11-21T21:00:00Z",
"close_time_ts_dynamic": "2025-11-21T21:00:00Z"
}
],
// ... その他の予約プロパティ
}
]
}
ユースケース (Use Cases)
- 昼休み: 配達場所は昼食のために閉まります（例：12:00-13:00）が、その前後は開いています。午前のスロットをプライマリウィンドウとして定義し、午後のスロットを
time_windowsで定義できます。 - シフトベースのアクセス: サイトは特定のシフト中（例：朝のシフトと夜のシフト）にのみアクセス可能であり、その間はアクセスできません。
- 制限された都市アクセス: 一部の都市ゾーンでは、特定のオフピーク時間（例：早朝と深夜）にのみ配送車両が許可される場合があります。
プレイグラウンド (Playground)
以下のプレイグラウンドを使用して、複数の時間枠 の概念を試すことができます。
このシナリオでは：
- Dropoff A には 08:00 - 08:10 のプライマリウィンドウと 14:00 - 15:00 のセカンダリウィンドウがあります。
- Dropoff B には 09:00 - 10:00 の単一のウィンドウがあります。
車両は08:00に開始し、最初にピックアップを実行する必要があるため、プライマリウィンドウ（08:00 - 08:10）内に Dropoff A に到達することは不可能です。したがって、ソルバーは自動的に Dropoff A をセカンダリウィンドウ（14:00 - 15:00）にスケジュールします。
自分で試す: 以下の JSON エディターで dropoff_A の time_windows 配列を削除し、計算を再度実行します。プライマリ時間枠を満たすことができないため、dropoff_A が割り 当てられない（またはソリューションが失敗する）ことがわかります。