JP7238714B2 - 情報処理装置、情報処理方法、およびプログラム - Google Patents

Description

本発明は、移動計画を生成する技術に関する。

自動車での移動において、所要時間が最短となる経路を検索するシステムがある。さらに、渋滞情報を時間帯ごとに保持し、出発予定時刻や到着希望時刻に応じて、最適な経路と所要時間を算出するシステムがある。渋滞状況は刻々と変化するため、走行を行う時間帯を考慮することで、適切な経路を求めることができる。

例えば、特許文献１には、出発時刻をずらしながら経路探索を行って複数の経路を取得し、走行中に、現在の時刻に応じて推奨経路を切り替えるナビゲーションシステムが記載されている。

特開２０１１－２４２２２８号公報

従来型のナビゲーション装置では、ユーザが入力した出発時刻や到着希望時刻に基づいて、最も早く移動することができる経路を求めることができるが、快適に移動するためのスケジュール自体を提案するという観点において改善の余地があった。

本発明は上記の課題を考慮してなされたものであり、ユーザに対して適切な移動スケジュールを提供することを目的とする。

本開示の第一の様態は、ユーザに対して提供する移動スケジュールを決定する情報処理装置である。
具体的には、道路リンクごとの渋滞情報を時間帯別に記憶する記憶部と、ユーザから、出発地、目的地、および到着デッドラインに関する情報を取得することと、前記出発地と前記目的地とを結ぶ経路と、出発時刻および到着予定時刻を含む移動スケジュールと、を決定することと、を実行する制御部を有し、前記制御部は、前記到着デッドラインまでに前記目的地に到着可能であって、前記経路ごとに定められた所定値よりも短い所要時間で前記経路を移動可能な移動スケジュールを決定することを特徴とする。

また、本開示の第二の様態は、前記情報処理装置が行う情報処理方法である。
具体的には、道路リンクごとの渋滞情報を時間帯別に取得する取得ステップと、ユーザから、出発地、目的地、および到着デッドラインに関する情報を取得し、前記出発地と前記目的地とを結ぶ経路と、出発時刻および到着予定時刻を含む移動スケジュールと、を決定する決定ステップと、を含み、前記決定ステップでは、前記到着デッドラインまでに前記目的地に到着可能であって、前記経路ごとに定められた所定値よりも短い所要時間で前記経路を移動可能な移動スケジュールを決定することを特徴とする。

また、他の態様として、上記の情報処理装置が実行する情報処理方法をコンピュータに実行させるためのプログラム、または、該プログラムを非一時的に記憶したコンピュータ可読記憶媒体が挙げられる。

本発明によれば、ユーザに対して適切な移動スケジュールを提供することができる。

第一の実施形態に係るナビゲーションシステムの構成図。 所定の経路を移動する際の移動スケジュールの例。 記憶部に記憶される渋滞データおよび道路データの例。 ユーザ端末、旅程サーバ、交通情報サーバが行う処理の概要図。 旅程サーバが行う旅程生成処理のフローチャート。 往路に要する時間、滞在時間、復路に要する時間の関係を示した図。 第二の実施形態における、旅程生成処理のフローチャート。 第二の実施形態の変形例における、旅程生成処理のフローチャート。 第三の実施形態における、旅程生成処理のフローチャート。 第四の実施形態に係る旅程サーバのシステム構成図。 第四の実施形態における道路データの例。 第四の実施形態における、旅程生成処理のフローチャート。

渋滞状況を勘案し、ユーザに対して最適な経路を提案するナビゲーション装置が普及している。このような装置には、例えば、リアルタイムの渋滞情報に基づいて所要時間を算出するものや、過去の渋滞情報に基づいて、指定した時刻に出発した場合における所要時間を算出するものがある。

一方で、このようなナビゲーション装置では、指定した時刻に出発、または、指定した時刻に到着できるような移動スケジュールを求めることはできるが、許容可能な範囲内で、出来るだけ快適に移動できる移動スケジュールを探索することはできない。

例えば、朝７時５５分までに勤務先に到着するよう、自動車で移動するケースを考える。ここでは、経由する道路が、通常３０分で到達可能なところ、通勤時間帯においては４５分かかるものとする。
この場合、従来型のナビゲーション装置では、一般的に、７時１０分頃に出発し、７時５５分頃に到着する移動スケジュールを出力する。しかし、仮に出発時間を１０分繰り上げることで、混雑時間帯を避けることができる場合（例えば、３５分で到着可能になる場合）であっても、従来型のナビゲーション装置では、これを提案することができない。もし、１０分早く出発することをユーザが許容できる場合、渋滞による１０分の損失を抑えることができる。

本実施形態では、このような移動スケジュールを求める情報処理装置を提供する。
なお、以下の説明において、「移動スケジュール」とは、ある経路についての出発時刻と到着予定時刻の組み合わせを含む。経路は、複数のトリップを含んでいてもよい。この場合、複数のトリップに関連付いた時刻をまとめて移動スケジュールと呼ぶこともできる。また、「旅程」とは、出発地と目的地とを結ぶ経路と、移動スケジュールの組み合わせを指す。

当該情報処理装置は、記憶部が、道路リンクごとの渋滞情報を時間帯別に記憶しており、制御部が、ユーザから、出発地、目的地、および到着デッドラインに関する情報を取得し、経路と、出発時刻および到着予定時刻を含む移動スケジュールと、を決定する。また、移動スケジュールを決定する際は、前記到着デッドラインまでに前記目的地に到着可能な移動スケジュールのうち、前記経路ごとに定められた所定値よりも短い所要時間で前記
経路を移動可能な移動スケジュールを選択する。

経路ごとに定められた所定値とは、当該経路においてユーザに推奨できる所要時間の閾値である。例えば、対象の経路について、３０分を閾値とした場合、３０分以下で当該経路を移動できるような移動スケジュールを探索する。換言すると、所要時間が３０分を上回ってしまうような移動スケジュールは適切ではないと判断し、採用しない。このような閾値は、当該経路における標準所要時間（渋滞が無い場合における移動時間）に基づいて定められてもよい。すなわち、渋滞による所要時間の増加が一定値以下であることを条件に、移動スケジュールを採用するようにしてもよい。

このように、本実施形態に係る情報処理装置は、到着デッドラインまでに目的地に到着するという制約の下で、ドライバーにかかる労力の低減を優先して移動スケジュールを求めることができる。

また、前記所定値は、前記経路に対応する標準所要時間に基づいて決定されることを特徴としてもよい。所定値は、例えば、標準所要時間に対して１０％，１５％といったような割合を加算したものであってもよい。

また、前記制御部は、前記到着デッドラインを末尾とする所定の時間幅内に前記出発時刻および到着予定時刻が収まるよう前記移動スケジュールを決定することを特徴としてもよい。
所定の時間幅は、例えば、ユーザによって指定可能とすることができる。時間に幅を持たせることで、最適な移動スケジュールを探索することが可能になる。

また、前記制御部は、前記到着デッドラインを到着予定時刻として移動スケジュールの候補を取得し、得られた所要時間が前記所定値を上回る場合に、前記所要時間が前記所定値を下回るまで出発時刻を繰り上げることを特徴としてもよい。
かかる構成によると、到着時刻がデッドラインに近く、かつ、渋滞を回避できる移動スケジュールを求めることができる。

また、前記制御部は、前記移動スケジュールの候補を取得し、前記渋滞情報を用いて、前記移動スケジュールの候補に対応する所要時間を算出することを特徴としてもよい。
時間帯別の渋滞情報を参照することで、精度のよい所要時間予測を行うことができる。

また、前記制御部は、算出した前記所要時間に基づいて、前記候補に対して評価値を与えることを特徴としてもよい。
また、前記制御部は、前記評価値が所定値以上である前記移動スケジュールの候補を採用することを特徴としてもよい。
例えば、所要時間がより短いほど、より高い評価値を与えるようにしてもよい。なお、経路が複数のトリップを含む場合、その所要時間の合計値によって評価値を算出してもよい。

また、前記経路は、第一のトリップと第二のトリップを含み、前記制御部は、前記第一のトリップと前記第二のトリップのインターバルが長いほど、前記候補に対してより高い評価値を与えることを特徴としてもよい。
また、前記制御部は、前記第一のトリップと前記第二のトリップの所要時間の合計が短いほど、前記候補に対してより高い評価値を与えることを特徴としてもよい。

かかる構成によると、第一のトリップを往路、第二のトリップを復路とした場合において、滞在時間を最大化することができる。すなわち、より運転時間が短く、より滞在時間
が長くなる移動スケジュールを求めることが可能になる。

また、前記制御部は、前記経路の候補を取得し、複数の評価基準に基づいて、前記経路の候補に対して第二の評価値を与えることを特徴としてもよい。

評価基準は、運転の難易度、ないし、運転にかかる労力に関連するものであって、経路や時間帯によって変動するものであれば、どのような条件であってもよい。
例えば、経路によって変動するものとして、車線の多さ、道幅の広さ、歩道の有無、および、これらに基づいて算出された値などがある。また、時間帯によって変動するものとして、交通量、日照の有無、日の出や日没の時刻、予測される降水量などがある。
評価基準を用いることで、より運転が容易な移動スケジュールを求めることが可能になる。

また、前記制御部は、ユーザの指定に基づいて、前記複数の評価基準のそれぞれについて重みを付与することを特徴としてもよい。
かかる構成によると、ユーザの嗜好に合った経路および移動スケジュールを決定することが可能になる。

また、前記制御部は、前記複数の評価基準による評価の結果をユーザに提示することを特徴としてもよい。
評価をユーザに提示することで、ユーザがより好ましい経路や移動スケジュールを選択することが可能になる。

（第一の実施形態）
第一の実施形態に係るナビゲーションシステムの概要について、システム構成図である図１を参照しながら説明する。本実施形態に係るナビゲーションシステムは、ユーザが所持する端末（ユーザ端末１００）と、ユーザ端末１００に対してナビゲーションサービスを提供する旅程サーバ２００と、道路交通情報（渋滞情報）を提供する交通情報サーバ３００と、を含んで構成される。
なお、システムを利用するユーザが複数である場合、ユーザ端末１００は複数あってもよい。また、交通情報サーバ３００も、エリアごと（あるいは道路管理者ごと）に複数設置されていてもよい。

ユーザ端末１００は、例えばスマートフォン、携帯電話、タブレットコンピュータ、個人情報端末、ノートブックコンピュータ、ウェアラブルコンピュータ（スマートウォッチ等）といった小型のコンピュータである。ユーザ端末１００は、通信部１０１、制御部１０２、記憶部１０３、入出力部１０４を有して構成される。

通信部１０１は、ネットワーク経由で旅程サーバ２００と通信を行うための通信インタフェースである。

制御部１０２は、ユーザ端末１００の制御を司る手段である。制御部１０２は、例えば、ＣＰＵ（Central Processing Unit）によって構成される。
制御部１０２は、機能モジュールとして旅程検索部１０２１を有している。機能モジュールは、ＲＯＭ（Read Only Memory）等の記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

旅程検索部１０２１は、旅程サーバ２００に対して旅程を検索する要求（以下、旅程検索要求）を送信し、得られた応答に基づいて、ユーザに対して旅程を案内する。具体的には、出発地および目的地をユーザから取得し、当該出発地と目的地を結ぶ経路と、当該経
路を移動するための最適な移動スケジュールを検索するリクエストを旅程サーバ２００に送信する。また、旅程サーバ２００から受信した旅程を、後述する入出力部１０４を介してユーザに提供する。このような機能は、オペレーティングシステム上で動作するアプリケーションプログラムによって実現してもよい。
本実施形態では、旅程検索部１０２１は、出発時刻／到着時刻を指定する代わりに、目的地に到着するデッドラインとなる時刻を指定する。具体的な例については後述する。

記憶部１０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。

入出力部１０４は、ユーザに対して情報を提示し、当該ユーザから情報の入力を受けるためのインタフェースである。入出力部１０４は、例えば、ディスプレイ装置やタッチパネルを有して構成される。

次に、旅程サーバ２００の構成について説明する。
旅程サーバ２００は、複数のユーザ端末１００から受信した旅程検索要求に基づいて、指定された出発地と目的地を結ぶ経路、および、当該経路を移動するための移動スケジュールを生成する装置である。

ここで、移動スケジュールの生成について説明する。
本実施形態に係る旅程サーバ２００は、出発地と目的地を結ぶ経路を生成した後に、当該経路を移動する際の最適なスケジュールを算出する。図２は、所定の経路を移動する際のスケジュールの例を示した図である。
ここで、デッドライン時刻とは、目的地に到着するデッドラインとなる時刻であり、ユーザによって指定される時刻である。例えば、指定されたデッドライン時刻が２１時００分である場合、旅程サーバ２００は、２１時００分までに目的地に到着できる移動スケジュールを生成する。

出発地と目的地を結ぶ経路を移動する際のスケジュールは複数存在する。図示した例では、１８時ちょうどに出発地を発つスケジュール１、１７時３０分に出発地を発つスケジュール２、１７時１５分に出発地を発つスケジュール３が例示されている。なお、図示した例において、経路の標準所要時間（渋滞が無い場合における移動時間）は２時間ちょうどであるものとする。

経路の所要時間は、当該経路を通過する時刻によって変動する。例えば、スケジュール１によって移動した場合、夕刻の渋滞時間帯にかかるため、移動に３時間を要する。
一方、スケジュールを変更し、出発時刻を繰り上げると、渋滞が軽いうちに通過できるため、所要時間が短くなる場合がある。図示した例では、１７時３０分に出発することで、スケジュール１と比較して所要時間を１５分短縮することができる。同様に、１７時１５分に出発することで、スケジュール１と比較して所要時間を３５分短縮することができる。

本実施形態に係る旅程サーバ２００は、デッドライン時刻までに到着することを前提として、設定可能な移動スケジュールのうち、時間的な条件を満たす移動スケジュールを選択し、ユーザに提供する。時間的な条件とは、「所要時間が最も短い」であってもよいし、「所要時間が、経路ごとに設定された閾値よりも短い」であってもよい。

以下、かかる機能を実現するための旅程サーバ２００の構成について説明する。
旅程サーバ２００は、通信部２０１、制御部２０２、記憶部２０３を有して構成される。
通信部２０１は、通信部１０１と同様の、ネットワーク経由でユーザ端末１００および交通情報サーバ３００と通信を行うための通信インタフェースである。

制御部２０２は、旅程サーバ２００の制御を司る手段である。制御部２０２は、例えば、ＣＰＵによって構成される。
制御部２０２は、機能モジュールとして、経路生成部２０２１、交通情報取得部２０２２、旅程生成部２０２３を有している。各機能モジュールは、ＲＯＭ等の記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

経路生成部２０２１は、ユーザ端末１００から取得した旅程検索要求に応じて、指定された出発地と目的地を結ぶ経路を検索する。経路の検索は、例えば、後述する記憶部２０３に記憶された道路データ（後述）に基づいて、公知の手法によって行うことができる。

交通情報取得部２０２２は、道路交通状況に関するデータ（以下、渋滞データ）を交通情報サーバ３００から取得する。本実施形態では、渋滞データとは、道路リンクごとの平均車速を時間帯別に表したデータである。図３（Ａ）は、渋滞データの例である。本例では、道路リンクごとの平均車速が、時間帯および曜日別に定義されている。

旅程生成部２０２３は、経路生成部２０２１が生成した経路に対応する移動スケジュールを生成する。具体的には、記憶された道路データおよび渋滞データに基づいて、経路生成部２０２１が生成した経路を走行した場合の所要時間を算出し、指定されたデッドライン時刻までに目的地に到着可能であって、かつ、時間的な条件を満たす移動スケジュールを生成する。
旅程生成部２０２３が実行する詳細な処理については後述する。

記憶部２０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。
記憶部２０３には、前述した渋滞データと、道路データが記憶される。道路データは、道路リンクごとの接続関係、各道路リンクの延長（距離）、各道路リンクの標準所要時間などが定義されたデータである。本実施形態に係る経路生成部２０２１は、記憶部２０３に記憶された道路データを用いて経路を生成する。

図３（Ｂ）は、道路データの例である。本例では、道路リンクごとの距離および標準所要時間が定義されている（道路リンク同士の接続関係は省略）。記憶部２０３に記憶された道路データによって、複数のリンクの集合からなる経路を走行した場合における所要時間を算出することができる。さらに、渋滞データを加味することで、任意の時間帯における所要時間を算出することができる。

次に、交通情報サーバ３００の構成について説明する。
交通情報サーバ３００は、渋滞データを提供するサーバ装置である。交通情報サーバ３００は、通信部３０１、制御部３０２、記憶部３０３を有して構成される。
通信部３０１は、通信部２０１と同様の、ネットワーク経由で旅程サーバ２００と通信を行うための通信インタフェースである。

制御部３０２は、交通情報サーバ３００の制御を司る手段である。制御部３０２は、例えば、ＣＰＵによって構成される。
制御部３０２は、機能モジュールとしてデータ収集部３０２１とデータ提供部３０２２を有している。各機能モジュールは、ＲＯＭ等の記憶手段に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

データ収集部３０２１は、道路交通状況に関するデータを収集する。データの収集先は、例えば、道路管理者や警察組織が設置した装置（例えば、車両感知器や路側装置等）とすることができる。収集されたデータは、記憶部３０３に記憶される。

データ提供部３０２２は、旅程サーバ２００からの要求に基づいて、道路リンクごとの渋滞の度合いを示す渋滞データを生成し、提供する。データ提供部３０２２は、データ収集部３０２１が収集したデータに基づいて、図３（Ａ）に示したような、渋滞の度合いを時間帯や曜日ごとに表した統計データを生成し、旅程サーバ２００に提供する。
なお、図３（Ａ）の例では平均車速を例示したが、旅程サーバ２００が所要時間を算出することができれば、他形式のデータを提供してもよい。また、図３（Ａ）の例では統計データを例示したが、渋滞データは、統計を行う前のデータであってもよい。

記憶部３０３は、情報を記憶する手段であり、ＲＡＭ、磁気ディスクやフラッシュメモリなどの記憶媒体により構成される。

次に、ユーザ端末１００、旅程サーバ２００、交通情報サーバ３００が行う処理の概要について、図４を参照して説明する。
まず、交通情報サーバ３００（データ収集部３０２１）が、道路交通状況に関するデータを収集し、蓄積する（ステップＳ１１）。また、旅程サーバ２００（交通情報取得部２０２２）が、交通情報サーバ３００（データ提供部）から渋滞データを取得する（ステップＳ１２）。ステップＳ１１およびＳ１２は、システムの稼働中において周期的に実行される。

ユーザが、ユーザ端末１００を介して旅程の検索を実行すると、ステップＳ１３で、旅程検索要求が旅程サーバ２００に送信される。旅程の検索操作は、例えば、専用のアプリケーションを介して行うことができる。旅程検索要求には、出発地および目的地のほか、時間的な制約を示すデータ（以下、制約条件）が含まれる。制約条件とは、旅程を生成する上で満たすべき条件であり、本例では、デッドライン時刻、すなわち、目的地への到着において許容される最終時刻である。

旅程検索要求を受信した旅程サーバ２００は、条件に合致する旅程を生成し（ステップＳ１４）、ユーザ端末１００に送信する（ステップＳ１５）。

旅程サーバ２００が旅程を生成する処理について、図５を参照してより詳細に説明する。図５に示した処理は、ユーザ端末１００から旅程検索要求を受信したタイミングで開始される。

まず、ステップＳ２１で、旅程生成部２０２３が、旅程検索要求に含まれる制約条件（デッドライン時刻）を取得する。

次に、ステップＳ２２で、経路生成部２０２１が、旅程検索要求に含まれる出発地と目的地に基づいて、経路を決定する。経路は、渋滞を考慮しない状況下において最も合理的な経路とすることができる。

次に、ステップＳ２３で、旅程生成部２０２３が、出発時刻を仮決定する。初回の処理においては、デッドライン時刻に合わせて目的地に到着できると推定できる出発時刻を決定する。

ステップＳ２４では、旅程生成部２０２３が、ステップＳ２３で決定した出発時刻に出発地を発った場合における所要時間を算出する。所要時間の算出は、記憶部２０３に記憶
された渋滞データおよび道路データに基づいて行うことができる。例えば、経路に含まれる道路リンクごとの距離と平均車速を用いて、各道路リンクにおける通過所要時間をそれぞれ算出し、合計することで、所要時間を求めることができる。
ステップＳ２３およびＳ２４の処理によって、仮の移動スケジュールが決定される。

ステップＳ２５では、旅程生成部２０２３が、デッドライン時刻までに目的地に到着可能であるか否かを判定する。ここで、仮の移動スケジュールに含まれる到着時刻がデッドライン時刻を超えていた場合、処理はステップＳ２８へ遷移し、出発時刻を繰り上げる。到着時刻がデッドライン時刻を超えていなかった場合、処理はステップＳ２６へ遷移する。

ステップＳ２６では、旅程生成部２０２３が、算出された所要時間が、経路ごとに定められた所定値以下であるか否かを判定する。
例えば、決定した経路の標準所要時間がＡ分であった場合、所定値をＡ＋Ｂ分とすることができる。この場合、値Ｂは、値Ａに基づいて決定される整数とすることができる。例えば、決定した経路の標準所要時間が３０分であった場合、所定値を３０＋１０＝４０分とすることができる。
また、所定値をＡ×Ｂ分とすることもできる。この場合、値Ｂは、値Ａに基づいて決定される１以上の実数とすることができる。例えば、決定した経路の標準所要時間が３０分であった場合、所定値を３０×１．２＝３６分とすることができる。
所定値は、仮の移動スケジュールを採用するか否かの閾値である。すなわち、ある移動スケジュールについて、所要時間が所定値を超えていた場合、渋滞による損失が大きいと判断し、当該移動スケジュールを破棄する。
経路ごとの所定値は、当該経路における標準所要時間に基づいて適宜設定すればよい。

算出された所要時間が所定値を超えていた場合、処理はステップＳ２８へ遷移し、出発時刻を繰り上げる。算出された所要時間が所定値以下であった場合、処理はステップＳ２７へ遷移する。

ステップＳ２７では、旅程生成部２０２３が、生成した仮の移動スケジュールを正式なものとして決定し、ユーザ端末１００に送信する。これにより、決定された経路と移動スケジュールが、ユーザ端末１００を介してユーザに提供される。

以上説明したように、第一の実施形態に係るシステムでは、デッドライン時刻までに目的地に到着できる範囲内で、所要時間が条件を満たす移動スケジュールを探索する。かかる構成によると、より運転に労力を要さない移動スケジュールを求めることができる。すなわち、希望の時刻に合わせて到着することよりも、ドライバーにかかる労力の軽減を優先したいというユーザの要請に応えることができる。

なお、本実施形態では、ステップＳ２６において、所要時間が所定値を超えているか否かを判定したが、例えば、経路上の渋滞の程度に基づいて、仮決定した移動スケジュールを採用するか否かを決定してもよい。
また、経路の中間において、休憩や滞在などによって移動を停止する時間が発生する場合、当該時間を除外して所要時間を算出するようにしてもよい。換言すると、出発地と目的地とを結ぶ経路が複数のトリップで構成される場合、各トリップの所要時間の合計を算出するようにしてもよい。

（第一の実施形態の変形例）
第一の実施形態では、移動スケジュールを求める際に、デッドライン時刻のみを制約条件としたが、出発時刻に制限を設けてもよい。

例えば、深夜や早朝に出発することで、日中に発生する渋滞を避けることができることが知られているが、出発時刻を無制限に繰り上げると、真夜中に出発するスケジュールが提案されてしまい、かえってドライバーの負担となることが考えられる。そこで、出発が可能となる時刻（以下、出発可能時刻）を制約条件に含ませ、ステップＳ２５において、出発可能時刻からデッドライン時刻までの間（所定の時間幅内）に移動スケジュールが収まるか否かを判定するようにしてもよい。出発可能時刻は、例えば、ユーザ端末１００を介してユーザが指定できるようにしてもよい。

（第二の実施形態）
第一の実施形態では、経路に対応する所要時間とデッドライン時刻に基づいて移動スケジュールを決定した。第二の実施形態は、経路を、第一のトリップと第二のトリップに分割したうえで、そのインターバルをさらに考慮して移動スケジュールを決定する実施形態である。

第二の実施形態における経路は、滞在地に向かう第一のトリップと、滞在地から戻る第二のトリップで構成される。
第二の実施形態における移動スケジュールは、第一のトリップを開始する時刻（すなわち、出発地を出発する時刻）、第一のトリップを終了する時刻（滞在地に到着する時刻）、第二のトリップを開始する時刻（滞在地を出発する時刻）、第二のトリップを終了する時刻（目的地に到着する時刻）から構成される。なお、出発地と目的地は必ずしも同一の地点である必要はない。

第二の実施形態では、第一のトリップ（出発地から滞在地まで）を往路、第二のトリップ（滞在地から目的地まで）を復路と称する。
また、第二の実施形態では、旅程サーバ２００が、（１）第一のトリップの所要時間、（２）滞在地における滞在時間、（３）第二のトリップの所要時間、を最適化する移動スケジュールを生成する。

図６は、往路に要する時間、滞在時間、復路に要する時間の関係を示した図である。
例えば、デッドライン時刻に到着する移動スケジュールとして、スケジュール１があったものとする。
このようなケースにおいて、例えば、滞在を早めに切り上げることで、復路の所要時間が短縮できる場合がある（スケジュール２）。また、往路を早めに出発することで、往路の所要時間が短縮され、結果として、滞在時間を伸ばすことができる場合がある（スケジュール３）。
第二の実施形態に係る旅程サーバ２００は、このように、往路と復路の出発時刻を個別に決定することで、全体のスケジュールを最適化する。具体的には、移動にかける時間をより短く、滞在地における滞在時間がより長くなる移動スケジュールを求める。

図７は、第二の実施形態において旅程サーバ２００が実行する、旅程を生成する処理のフローチャートである。図７に示した処理は、ユーザ端末１００から旅程検索要求を受信したタイミングで開始される。

まず、ステップＳ３１で、旅程生成部２０２３が、旅程検索要求に含まれる制約条件を取得する。第二の実施形態では、制約条件は、デッドライン時刻と、出発可能時刻を含む。

次に、ステップＳ３２で、経路生成部２０２１が、ステップＳ２２と同様の方法によって経路を決定する。

ステップＳ３３では、経路生成部２０２１が、出発可能時刻からデッドライン時刻までの間において取りうる、往路と復路の移動スケジュールの組み合わせを生成する。具体的には、往路の出発時刻と復路の出発時刻を１分ずつずらしながら、未処理、かつ、出発可能時刻からデッドライン時刻までの間に移動が完結する組み合わせを生成する。所要時間は、第一の実施形態と同様の方法で算出することができる。
ここで生成される移動スケジュールには、以下の情報が含まれる。
・往路の出発時刻
・往路の到着時刻
・復路の出発時刻
・復路の到着時刻
また、これにより、往路の所要時間、滞在地における滞在時間、復路の所要時間が算出できる。

ステップＳ３４では、経路生成部２０２１が、算出した所要時間（往路の所要時間と復路の所要時間）、および、滞在時間を用いて評価値を算出する。評価値は、往路および復路の所要時間が短いほど高くなり、滞在地における滞在時間が長いほど高くなる値である。評価値を算出するための基準ないし数式は、予め記憶させておいてもよい。

ステップＳ３３およびＳ３４の処理は、生成された全ての組み合わせについて実行される（ループＡ）。ループＡは、未処理の移動スケジュールのうち合理的なものが無くなった時点で終了する。例えば、滞在地における滞在時間が極端に短いもの、平均滞在時間よりも短いもの、滞在時間が極端に長いもの等は、合理的ではないとして除外されてもよい。

ステップＳ３５では、生成した複数の移動スケジュールの中から、評価値が基準を満たす（例えば、評価値が閾値以上である）ものを特定する。
なお、評価値が基準を満たしていても、生成した移動スケジュールが以下のいずれかに該当する場合、対応する移動スケジュールについては、基準を満たさないものとして扱ってもよい。
・往路の所要時間が、往路に対して設定された閾値を上回っている
・滞在地における滞在時間が、滞在地に対して設定された範囲を外れている（短すぎる、または、長すぎる）
・復路の所要時間が、復路に対して設定された閾値を上回っている

ステップＳ３５で、基準を満たす移動スケジュールが抽出された場合、当該移動スケジュールが、正式な旅程としてユーザ端末１００に送信される（ステップＳ３６）。なお、候補が複数ある場合、評価値や、評価値の算出根拠などとともにユーザに提示してもよい。なお、ステップＳ３５で、基準を満たす移動スケジュールが抽出されなかった場合、その旨がユーザ端末１００に送信される（ステップＳ３７）。

以上説明したように、第二の実施形態によると、往路における所要時間、滞在地における滞在時間、復路における所要時間のバランスが取れた移動スケジュールを算出することができる。

（第二の実施形態の変形例１）
第二の実施形態では、出発可能時刻からデッドライン時刻までの間において取りうる、往路と復路の移動スケジュールの組み合わせを全て生成し、それぞれを評価したが、時系列順にトリップを特定してもよい。
図８は、本変形例において、旅程サーバ２００が旅程を生成する処理のフローチャート
である。破線で図示したステップは、第二の実施形態と同様であるため説明は省略する。

ステップＳ４１では、ステップＳ２３～Ｓ２６，Ｓ２８と同様の処理によって、トリップに対応する移動スケジュールを決定するが、処理対象が復路（第二のトリップ）であるという点において相違する。復路における移動スケジュールは、デッドライン時刻までに目的地に到着可能であって、所要時間が条件を満たすものとなる。

ステップＳ４２では、滞在地における最小滞在時間を決定する。最小滞在時間は、ユーザの意向に基づいたものであってもよいし、当該滞在地における平均的な滞在時間に基づいて求められてもよい。

ステップＳ４３では、復路と同様の処理によって、往路（第一のトリップ）に対応する移動スケジュールを決定する。復路における移動スケジュールは、出発可能時刻よりも後に出発するものであって、所要時間が条件を満たすものとなる。なお、往路の出発時刻が繰り上がった場合、滞在時間が延長される。
この場合において、出発可能時刻よりも前に出発する移動スケジュールが算出された場合、ユーザの意向に基づいて滞在時間を短縮し、再度ステップＳ４３の処理を行うようにしてもよい。

（第二の実施形態の変形例２）
第二の実施形態では、滞在地を一箇所としたが、滞在地は複数であってもよい。
例えば、旅程サーバ２００が、旅程検索要求に基づいて、二箇所以上の滞在地を経由する経路を求めてもよい。すなわち、当該経路は、三つ以上のトリップから構成されていてもよい。

本変形例の場合、各トリップにおける所要時間と、二箇所以上の滞在地における滞在時間に基づいて、移動スケジュールに対する評価値を算出することができる。本変形例によれば、各トリップの所要時間の合計が短くなり、各滞在地における滞在時間の合計が長くなるほど高い評価値を得ることができる。

（第三の実施形態）
第一および第二の実施形態では、単一の経路を決定したのちに、当該経路に対応する移動スケジュールを求めた。これに対し、第三の実施形態は、複数の経路を生成したうえで、移動スケジュールの評価を経路ごとに実施する実施形態である。

図９は、第三の実施形態において旅程サーバ２００が実行する、旅程を生成する処理のフローチャートである。破線で示したステップは、第二の実施形態と同様であるため説明は省略する。

第三の実施形態では、ステップＳ３２Ａにおいて、経路生成部２０２１が、旅程検索要求に含まれる出発地と目的地に基づいて、経路を決定する。経路の候補が複数ある場合、経路生成部２０２１は、複数の候補を順に選択する（ループＢ）。

ステップＳ３３およびＳ３４では、選択中の経路について、第二の実施形態と同様の処理を行う。すなわち、経路生成部２０２１が、出発可能時刻からデッドライン時刻までの間において取りうる、往路と復路の移動スケジュールの組み合わせを生成し、それぞれに対して評価値を算出する。
ステップＳ３３およびＳ３４の処理は、生成された全ての組み合わせについて実行される（ループＡ）。ループＡは、未処理の移動スケジュールのうち合理的なものが無くなった時点で終了する。
また、ループＢは、未処理の経路のうち合理的なものが無くなった時点で終了する。
ステップＳ３５以降の処理については、第二の実施形態と同様である。

第三の実施形態によると、出発地と目的地との間を移動するユーザが取りうる複数の経路を取得し、それぞれについて評価を行うため、より適切な旅程を探索することが可能になる。

（第四の実施形態）
第一ないし第三の実施形態では、ユーザが取りうる複数の旅程を取得し、時間に基づいてそれぞれを評価した。これに対し、第四の実施形態は、経路ごとの運転の難易度をさらに用いて旅程を評価する実施形態である。

図１０は、第四の実施形態に係る旅程サーバ２００のシステム構成図である。
第四の実施形態では、旅程サーバ２００が有する制御部２０２は、運転の難易度を判定する難易度判定部２０２４を含んで構成される。
難易度判定部２０２４は、経路（ないしトリップ）を特定する情報（例えば、道路リンクの集合）を取得し、当該経路（トリップ）を運転する際の難易度を数値によって出力するモジュールである。

また、第四の実施形態では、記憶部２０３に、運転の難易度に影響を与える要素に関するデータが道路リンクごとに記憶される。図１１は、本実施形態における道路データの例である。運転の難易度に影響を与える要素とは、例えば、車線の多さ、道幅の広さ、歩道の有無などであるが、これ以外であってもよい。

図１２は、第四の実施形態において旅程サーバ２００が実行する、旅程を生成する処理のフローチャートである。破線で示したステップは、第三の実施形態と同様であるため説明は省略する。第四の実施形態では、ステップＳ３４Ａにて、旅程生成部２０２３が、以下の情報を用いて第一の評価値を算出する。
・往路の所要時間
・復路の所要時間
・滞在地における滞在時間

また、旅程生成部２０２３が、以下の情報を用いて第二の評価値を算出する。
・往路における運転難易度
・復路における運転難易度
なお、旅程生成部２０２３は、難易度判定部２０２４を介して、往路または復路における運転難易度を取得する。

難易度判定部２０２４は、例えば、以下の数式によって、所定のトリップに対応する運転難易度を算出する。
運転難易度＝Σ_{道路リンク}（車線数×係数１＋道路幅×係数２＋歩道の有無×係数３）
ここで、係数は、各要素に対する重みである。係数は、ユーザによって予め指定されていてもよいし、固定値であってもよい。

第四の実施形態では、旅程生成部２０２３が、運転難易度に基づいて、経路に対する評価値（第二の評価値）を算出する。例えば、経路が複数のトリップを含む場合、トリップごとに算出した運転難易度を合計し、第二の評価値とすることができる。
また、算出した第二の評価値を、移動スケジュールに対する評価値（第一の評価値）と合わせ、旅程の総合的な評価を行う。

なお、所要時間、滞在時間、運転難易度のどれを重要視するかを事前にユーザから取得し、評価値を算出する際に重みを付してもよい。
また、候補が複数ある場合、評価値や、評価値の算出根拠などとともにユーザに提示してもよい。
さらに、図１１では、各道路リンクに固有な情報を例示したが、走行時間帯や予測される天候など、道路に固有でない情報を用いて運転難易度を補正してもよい。例えば、走行が夜間である場合や、降雨が予測される場合に、運転難易度を高くする補正を行ってもよい。

以上説明したように、第四の実施形態では、所要時間と滞在時間に加え、運転の容易さによって旅程を評価する。かかる構成によると、ドライバーにかかる労力を最小化する旅程を選択することが可能になる。
なお、本実施形態の説明では、例示した式によって運転難易度を算出したが、ユーザが指定した条件に合致する旅程については、無条件に採用を見送ってもよい。例えば、「日没後にかかる旅程は無視する」「対面通行の高速道路を経由する旅程は無視する」といったような条件を加えてもよい。

（変形例）
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、実施形態の説明では、ユーザ端末１００によってアクセスされる旅程サーバ２００が旅程を生成したが、旅程の生成は、例示した装置以外によって行われてもよい。例えば、サーバ装置、パーソナルコンピュータ、携帯型コンピュータ、その他の汎用コンピュータによって行われてもよい。また、旅程の生成は、必ずしも携帯端末とサーバ装置との組み合わせによって行わなくてもよい。例えば、ユーザ端末１００が行う処理と、旅程サーバ２００が行う処理を同一の装置によって実行してもよい。

また、実施形態の説明では、図３（Ａ）に示したような、渋滞のレベルを詳細に示したデータを例示したが、渋滞の有無のみを示したデータを利用してもよい。この場合、所要時間と閾値とを比較するステップにおいて、経路上に渋滞が存在するか否かのみを判定するようにしてもよい。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタ
イプの媒体を含む。

１００・・・ユーザ端末
１０１，２０１，３０１・・・通信部
１０２，２０２，３０２・・・制御部
１０２１・・・経路検索部
１０３，２０３，３０３・・・記憶部
２００・・・旅程サーバ
２０２１・・・経路生成部
２０２２・・・交通情報取得部
２０２３・・・旅程生成部
３００・・・交通情報サーバ
３０２１・・・データ収集部
３０２２・・・データ提供部

Claims (12)

1. 道路リンクごとの渋滞情報を時間帯別に記憶する記憶部と、
   ユーザから、出発地、目的地、および到着デッドラインに関する情報を取得することと、
   前記出発地と前記目的地とを結ぶ経路と、出発時刻および到着予定時刻を含む移動スケジュールと、を決定することと、
   を実行する制御部を有し、
   前記経路は、第一のトリップと第二のトリップを含み、
   前記制御部は、
   前記到着デッドラインまでに前記目的地に到着可能であって、前記経路ごとに定められた所定値よりも短い所要時間で前記経路を移動可能な移動スケジュールの候補を取得し、
   前記渋滞情報を用いて、前記候補に対応する所要時間を算出し、
   算出した前記所要時間に基づいて、前記候補に対して
   前記第一のトリップと前記第二のトリップのインターバルが長いほど、前記候補に対してより高い評価値を与え、
   前記第一のトリップと前記第二のトリップの所要時間の合計が短いほど、前記候補に対してより高い評価値を与え、
   前記インターバルに係る評価値と前記合計に係る評価値との合計が所定値以上である前記候補を採用し、
   前記第一のトリップの所要時間が前記第一のトリップに設定された閾値を上回る、または、前記第一のトリップと前記第二のトリップのインターバルが前記インターバルに設定された範囲を外れている、または、前記第二のトリップの所要時間が前記第二のトリップに設定された閾値を上回る前記採用した候補を前記移動スケジュールとして決定せず、
   前記第一のトリップの所要時間が前記第一のトリップに設定された閾値以内であり、かつ、前記第一のトリップと前記第二のトリップのインターバルが前記インターバルに設定された範囲に含まれており、かつ、前記第二のトリップの所要時間が前記第二のトリップに設定された閾値以内である前記採用した候補を前記移動スケジュールとして決定する、
   情報処理装置。
2. 前記経路ごとに定められた所定値は、前記経路に対応する標準所要時間に基づいて決定される、
   請求項１に記載の情報処理装置。
3. 前記制御部は、前記到着デッドラインを末尾とする所定の時間幅内に前記出発時刻および到着予定時刻が収まるよう前記移動スケジュールを決定する、
   請求項１または２に記載の情報処理装置。
4. 前記制御部は、前記到着デッドラインを到着予定時刻として移動スケジュールの候補を取得し、得られた所要時間が前記経路ごとに定められた所定値を上回る場合に、前記所要時間が前記経路ごとに定められた所定値を下回るまで出発時刻を繰り上げる、
   請求項１から３のいずれかに記載の情報処理装置。
5. 前記制御部は、前記経路の候補を取得し、複数の評価基準に基づいて、前記経路の候補に対して第二の評価値を与える、
   請求項１から４のいずれかに記載の情報処理装置。
6. 前記制御部は、ユーザの指定に基づいて、前記複数の評価基準のそれぞれについて重みを付与する、
   請求項５に記載の情報処理装置。
7. 前記制御部は、前記複数の評価基準による評価の結果をユーザに提示する、
   請求項５または６に記載の情報処理装置。
8. 道路リンクごとの渋滞情報を時間帯別に取得する取得ステップと、
   ユーザから、出発地、目的地、および到着デッドラインに関する情報を取得し、
   前記出発地と前記目的地とを結ぶ経路と、出発時刻および到着予定時刻を含む移動スケジュールと、を決定する決定ステップと、を含み、
   前記経路は、第一のトリップと第二のトリップを含み、
   前記決定ステップでは、
   前記到着デッドラインまでに前記目的地に到着可能であって、前記経路ごとに定められた所定値よりも短い所要時間で前記経路を移動可能な移動スケジュールの候補を取得し、
   前記渋滞情報を用いて、前記候補に対応する所要時間を算出し、
   算出した前記所要時間に基づいて、前記候補に対して
   前記第一のトリップと前記第二のトリップのインターバルが長いほど、前記候補に対してより高い評価値を与え、
   前記第一のトリップと前記第二のトリップの所要時間の合計が短いほど、前記候補に対してより高い評価値を与え、
   前記インターバルに係る評価値と前記合計に係る評価値との合計が所定値以上である前記候補を採用し、
   前記第一のトリップの所要時間が前記第一のトリップに設定された閾値を上回る、または、前記第一のトリップと前記第二のトリップのインターバルが前記インターバルに設定された範囲を外れている、または、前記第二のトリップの所要時間が前記第二のトリップに設定された閾値を上回る前記採用した候補を前記移動スケジュールとして決定せず、
   前記第一のトリップの所要時間が前記第一のトリップに設定された閾値以内であり、かつ、前記第一のトリップと前記第二のトリップのインターバルが前記インターバルに設定された範囲に含まれており、かつ、前記第二のトリップの所要時間が前記第二のトリップに設定された閾値以内である前記採用した候補を前記移動スケジュールとして決定する、
   情報処理方法。
9. 前記経路ごとに定められた所定値は、前記経路に対応する標準所要時間に基づいて決定される、
   請求項８に記載の情報処理方法。
10. 前記決定ステップでは、前記到着デッドラインを末尾とする所定の時間幅内に前記出発時刻および到着予定時刻が収まるよう前記移動スケジュールを決定する、
    請求項８または９に記載の情報処理方法。
11. 前記決定ステップでは、前記到着デッドラインを到着予定時刻として移動スケジュールの候補を取得し、得られた所要時間が前記経路ごとに定められた所定値を上回る場合に、前記所要時間が前記経路ごとに定められた所定値を下回るまで出発時刻を繰り上げる、
    請求項８から１０のいずれかに記載の情報処理方法。
12. 請求項８から１１のいずれかに記載の情報処理方法をコンピュータに実行させるためのプログラム。

Images