WO2018216502A1

WO2018216502A1 - 配送管理装置、荷物配送システムおよびプログラム

Info

Publication number: WO2018216502A1
Application number: PCT/JP2018/018254
Authority: WO
Inventors: 隆仁右田
Original assignee: ソニー株式会社
Priority date: 2017-05-26
Filing date: 2018-05-11
Publication date: 2018-11-29
Also published as: US20200097890A1; JPWO2018216502A1; CN110651284A; EP3633566A4; EP3633566A1

Abstract

本技術は、最適化された配送を実現することができるようにする配送管理装置、荷物配送システムおよびプログラムに関する。配送管理装置の作成部は、移動体への荷物の積み込みにかかる積み込み時間および移動体からの荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、荷物を積み込む積み込み地点および荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、移動体の配送計画を作成する。移動体はボックスを備え、ボックスに荷物が積み込まれる。移動体は、配送計画に基づいて、各目的地に移動し、受け取る者に荷物を配送する。本技術は、複数の受け取る者に荷物を配送する場合に適用可能である。

Description

配送管理装置、荷物配送システムおよびプログラム

　本技術は、配送管理装置、荷物配送システムおよびプログラムに関し、特に最適化された配送を実現できるようにした配送管理装置、荷物配送システムおよびプログラムに関する。

　店舗で商品を購入する場合、その購入者は、所定の店舗まで出向き、商品を探し、注文する。１つの店舗に希望する商品がない場合には、希望する商品を販売している店舗に移動する必要があり、そして購入者は購入した商品を持ち帰る。

　一方、最近、インターネットの通信販売サイト（EC(Electronic Commerce)サイト）の利用者が増加している。ECサイトでは、所望の商品を検索機能で迅速に検索することができる。そして、ECサイトで商品を購入した場合、その商品が購入者の自宅まで配送されるので、便利である。

　ECサイトでの商品の購入の増加に伴って、搬送する商品の数が増加し、配送業者の負担が大きくなっている。特に、配送先の住人（すなわち荷物の受取人）が留守である場合、再配送を余儀なくされ、配送効率が低下してしまう。そこで、さまざまな提案がなされている（例えば特許文献１）。

　特許文献１には、例えば受取人が旅行中で留守であることを依頼人が知った場合、依頼人の指示に応じて配送日時を変更できるようにすることが提案されている。

特開平10-149386号公報

　特許文献１の提案によれば、再配送を抑制し、効率的な集配が可能になる。

　しかしながら、この提案では、最適化された配送を実現することが困難である。

　本技術はこのような状況に鑑みてなされたものであり、最適化された配送を実現できるようにするものである。

　本技術の一側面は、移動体による荷物の配送を管理する配送管理装置において、前記移動体への前記荷物の積み込みにかかる積み込み時間および前記移動体からの前記荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、前記荷物を積み込む積み込み地点および前記荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、前記移動体の配送計画を作成する作成部を備える配送管理装置である。

　前記積み込み時間は、最初の配送依頼の発注時刻から前記積み込み地点の出発時刻までの時間であり、前記受け取り時間は、前記移動体の前記受け取り地点への到着予定時刻から希望配送時間帯の開始時刻までの時間とすることができる。

　さらに前記受け取り地点の数および前記到着予定時刻に基づいて前記配送計画が作成されることができる。

　さらに前記移動体の数に基づいて前記配送計画が作成されることができる。

　前記積み込み時間と前記受け取り時間の両方に基づいて前記配送計画が作成されることができる。

　本技術の一側面は、積み込まれた荷物を配送する移動体と、前記移動体への前記荷物の積み込みにかかる積み込み時間および前記移動体からの前記荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、前記荷物を積み込む積み込み地点および前記荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、前記移動体の配送計画を作成するサーバーとを備える荷物配送システムである。

　本技術の一側面は、コンピュータに、積み込まれた荷物を配送する移動体の配送計画を作成する処理を実行させるプログラムにおいて、前記移動体への前記荷物の積み込みにかかる積み込み時間および前記移動体からの前記荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、前記荷物を積み込む積み込み地点および前記荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、前記移動体の配送計画を作成するステップを含むプログラムである。

　本技術の一側面においては、移動体による荷物の配送を管理する配送管理装置において、作成部が、移動体への荷物の積み込みにかかる積み込み時間および移動体からの荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、荷物を積み込む積み込み地点および荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、移動体の配送計画を作成する。

　以上のように、本技術の一側面によれば、最適化された配送を実現することができる。なお、本明細書に記載された効果はあくまで例示であって、限定されるものではなく、また付加的な効果があってもよい。

荷物受注配送地域を説明する図である。荷物配送システムの構成を示す図である。通常シナリオの発注処理を説明する図である。商品購入処理を説明するフローチャートである。配送計画作成処理を説明するフローチャートである。配送計画を説明する図である。配送指示処理を説明するフローチャートである。積み込み処理を説明するフローチャートである。荷物の積み込みを説明する図である。通常シナリオの配送処理を説明する図である。出発処理を説明するフローチャートである。移動到着処理を説明するフローチャートである。受け取り処理を説明するフローチャートである。帰還処理を説明するフローチャートである。購入キャンセル処理を説明するフローチャートである。配送キャンセル処理を説明するフローチャートである。再配送処理を説明するフローチャートである。カートが動けない場合の処理を説明するフローチャートである。顧客が来ない場合の処理を説明するフローチャートである。取り忘れの場合の処理を説明するフローチャートである。配送管理システムの構成例を示すブロック図である。配送計画作成処理を説明するフローチャートである。配送状態を説明する図である。配送計画を説明する図である。配送計画を説明する図である。配送計画を説明する図である。配送計画を説明する図である。配送計画を説明する図である。配送計画を説明する図である。配送管理システムの構成例を示すブロック図である。利用時間帯検索処理を説明するフローチャートである。配送状態を説明する図である。配送計画を説明する図である。利用時間帯検索を説明する図である。利用時間帯検索を説明する図である。購入サイトのユーザインターフェースを示す図である。購入サイトのユーザインターフェースを示す図である。配送サイトのユーザインターフェースを示す図である。配送サイトのユーザインターフェースを示す図である。配送サイトのユーザインターフェースを示す図である。配送サイトのユーザインターフェースを示す図である。配送サイトのユーザインターフェースを示す図である。配送サイトのユーザインターフェースを示す図である。作業者サイトのユーザインターフェースを示す図である。作業者サイトのユーザインターフェースを示す図である。管理サイトのユーザインターフェースを示す図である。管理サイトのユーザインターフェースを示す図である。キーアプリケーションのユーザインターフェースを示す図である。キーアプリケーションのユーザインターフェースを示す図である。パーソナルコンピュータの構成例を示すブロック図である。

　以下、本技術を実施するための実施の形態について説明する。なお、説明は以下の順序で行う。
　１．荷物受注配送地域（図１）
　２．荷物配送システムの全体の構成（図２）
　３．通常シナリオの処理（図３乃至図１４）
　　（１）発注処理（図３乃至図９）
　　（２）配送処理（図１０乃至図１４）
　４．イレギュラーシナリオの処理（図１５乃至図２０）
　５．配送計画作成処理（図２１乃至図２９）
　６．利用可能時間帯検索処理（図３０乃至図３５）
　７．ユーザインターフェース（図３６乃至図４９）
　８．変形例
　９．コンピュータ（図５０）
　１０．その他

＜荷物受注配送地域（図１）＞
　図１は、荷物受注配送地域を説明する図である。同図に示されるように、地域１には、多くの建物が建っており、その居住者はそれぞれの建物のエントランスから出入りする。本技術においては、購入者が所定の店舗３の購入サイト１４で購入した商品２５を荷物として、移動体としてのカート２７がそのボックス２８（いずれも図２を参照して後述する）に収容して配送する。

　カート２７は、購入者の居住する建物のエントランスの近傍のポイント４を順次巡り、購入者はカート２７が近傍のポイント４に到着したとき、荷物をボックス２８から取り出す。図１の例では、XYZ搬入口から、Ａ棟エントランス、Ｂ棟エントランス、Ｃ棟エントランス、Ｄ棟エントランス、Ｆ棟エントランス、Ｇ棟エントランス、およびＨ棟エントランスを巡ってXYZ搬入口に帰還するルート２をカート２７が走行する。購入サイト１４の店舗３が荷物の発送元である。カート２７は、商品の購入者の最寄りのポイント４を巡るので、購入者の居住する建物が異なれば、ルートも異なる。すなわち、図１のルート２に代えて、商品の購入者の最寄りのポイント４を巡る別のルートが設定される。

　カート２７は、無人自動走行車であり、サーバーシステム１７（図２を参照して後述する）により走行が管理される。カート２７は、この例の場合、所定の区画内の走行路を走行する。走行路としては、カート２７が走行可能な所定の幅の走行路が利用される。カート２７は走行路上を動くので、目的地は購入者の居住する建物のエントランスに最も近い位置の走行路上とされる。複数のカート２７により複数の届け先に荷物が届けられる。

＜荷物配送システムの全体の構成（図２）＞
　図２は、荷物配送システムの構成を示す図である。荷物配送システム１０においては、各ユーザは、保持するネットワーク機器（商品を購入するための端末）を利用して購入サイト１４にアクセスする。図２の例では、ユーザ１２Ａは保持するスマートフォン１１Ａを利用して、ユーザ１２Ｂは保持するスマートフォン１１Ｂを利用して、ECサイトである購入サイト１４にアクセスし、商品２５を購入する。なお、図示は省略されているが、インターネットに代表される各種のネットワークを介してアクセスが行われる。このことは、他の機器間においても同様である。ユーザ１２Ａ，１２Ｂは、商品を購入し、宅配を依頼した場合、カート２７は商品２５の荷物を積んで、配送元２４からユーザ１２Ａの目的地１３Ａ、ユーザ１２Ｂの目的地１３Ｂを経由して、配送元２４に戻る。ユーザ１２Ａは目的地１３Ａにおいて、ユーザ１２Ｂは目的地１３Ｂにおいて、それぞれ配送されてきた荷物をカート２７から降ろす。

　また、以下においては、スマートフォン１１Ａ，１１Ｂ、ユーザ１２Ａ，１２Ｂを個々に区別する必要がない場合、単にスマートフォン１１、ユーザ１２と記述する。その他の構成要素についても同様とする。

　ユーザ１２は、スマートフォン１１を用いて購入サイト１４にアクセスし、希望商品を購入する。その際、ユーザ１２は、希望する配送時間、配送場所等を指定する。配送場所がカート２７の目的地となり、例えばユーザ１２Ａの場合、その居住する建物のエントランスに近いポイント４が目的地１３Ａとなり、ユーザ１２Ｂの場合、その居住する建物のエントランスに近いポイント４が目的地１３Ｂとなる。購入サイト１４はユーザ情報を記憶するデータベース１５を有している。

　購入サイト１４は、商品、配送時間、配送場所、およびユーザ情報を、サーバーシステム１７に通知する。配送管理装置としてのサーバーシステム１７は、配送管理システム４１とカート管理システム４４を有している。配送管理システム４１は、ユーザ情報を記憶するデータベース４２と、配送計画を記憶するデータベース４３を有している。カート管理システム４４は、カート情報を記憶するデータベース４５と、ボックス情報を記憶するデータベース４６を有している。

　サーバーシステム１７は、各ユーザ１２に、探索した配送ルートと到着予定時刻を通知する。サーバーシステム１７には、配送サイト１６が接続されており、各ユーザ１２は、自分のスマートフォン１１から配送サイト１６にアクセスし、カート位置、カート状態を知ることができる。また、配送サイト１６から各スマートフォン１１に、必要に応じてイベント通知が出される。

　サーバーシステム１７にはまた、管理サイト１８が接続されており、サーバーシステム１７の管理者２０は、自身のパーソナルコンピュータ１９から管理サイト１８を介してサーバーシステム１７にアクセスし、必要な情報を得たり、各種の要求を出したりすることができる。

　発送元２４において、商品２５を配送するために、カート２７に商品２５を積み込む配送作業を行う作業者２３は、タブレット２２を保持している。サーバーシステム１７には、作業者サイト２１が接続されており、タブレット２２を有する作業者２３とサーバーシステム１７との間では、作業者サイト２１を介して、各種の情報、要求等が授受される。

　作業者サイト２１からタブレット２２に、商品２５、カート情報、ボックス情報、配送時間等が通知される。この通知に基づき、作業者２３は、発送元２４に保持されている商品２５の中から所定の商品２５を選択し、所定のパッケージ２６に収容し、パッケージ２６を荷物としてさらに所定のカート２７の所定のボックス２８に積み込む。発送元２４においてカート２７の充電やメンテナンスが行われる。

　カート２７上には、所定の数（例えば６個の）ボックス２８が載置されており（図２にはそのうちの４個のみが示されている）、各ボックス２８の内部には、センサ２９が取り付けられており、ボックス２８内のパッケージ２６の有無が検出される。ボックス２８の上には、全方位カメラ３０が取り付けられており、カート２７の周囲の画像が撮影される。

　カート２７の先頭にはスピーカ３２が取り付けられており、必要に応じて周囲に警告音等を発することができる。カート２７に取り付けられている通信部３１は、無線によりサーバーシステム１７と直接、あるいはインターネットを含む各種のネットワークを介して通信する。

　カート２７は、クライアントシステム５１を有する。クライアントシステム５１は、カート制御システム６１とボックス制御システム６２を有する。

　カート２７には、サーバーシステム１７から目的地と配送時間帯が通知され、カート２７は指定された目的地に走行し、指定された配送時間帯に荷物を配送する。カート２７は、複数台（図２の例では３台）存在する。図２の例では、そのうちの１台であるカート２７Ａが発送元２４で充電中、他の１台であるカート２７Ｂが荷物の積み込み中、さらに他の１台であるカート２７Ｃが配送中とされている。

　図２には、購入サイト１４が１つだけ示されているが、実際には、複数の購入サイト（商品販売業者）があり、サーバーシステム１７は、複数の購入サイト１４からの商品配送の依頼を受け、カート２７によりその商品を配送する。

　サーバーシステム１７の配送管理システム４１は、荷物を配送することを管理するシステムであり、配送にかかわる全般の機能を有し、次のような特徴を有している。
　　・配送計画・個配送（目的地から次の目的地までの配送）を管理する。
　　・カート管理システム４４と連携し、配送指示を行う。
　　・個配送が開始したこと、終了したことしか知らない。
　　・カート２７とボックス２８の状態はカート管理システム４４が管理する。
　　・ユーザ１２（スマートフォン１１）、管理者２０（パーソナルコンピュータ１９）、作業者２３（タブレット２２）に、配送にまつわる状況、依頼を通知する。
　　・外部サイト（購入サイト１４）から配送依頼を受け付ける。
　　・カート２７との直接のやりとりは行わない（カート管理システム４４が行う）。

　配送管理システム４１の機能要件は次の通りである。
　　・購入サイト１４側
　　　　配送依頼を受け、配送計画生成し、更新する。
　　　　配送時間の予測を行う。
　　　　配送計画を所定のタイミングで終了する（時間、リソース等）。
　　・配送サイト１６側（ユーザ側）
　　　　各種の情報を通知する(カート出発、カート到着、異常系、配送時間、受け取り催促、受け取り完了)。
　　　　配送状況をもとに、予定配送時刻を更新する。
　　・カート管理システム４４側
　　　　カートリソース・ボックス状態を確認する。
　　　　配送計画・個配送を通知する。
　　　　個配送の開始・完了を受け取る。
　　　　配送計画の完了(帰還)を受け取る。
　　　　異常を受け取る。
　　　　異常を検知する。
　　・管理サイト１８側
　　　　状況を更新する(個配送状態)。
　　　　各種の情報を通知する(カート出発、カート到着、異常系、受け取り完了)。
　　・作業者サイト２１側
　　　　積み込み指示を作成する。
　　　　積み込み指示を通知する。
　　　　ボックス積み込み完了に返答する。
　　　　カート積み込み完了を確認する。

　カート管理システム４４は、カート状態を管理するシステムであり、カート２７にかかわる全般の機能を有し、次のような処理を行う。
　　・カート２７の状態を管理する。
　　・カート２７に目的地等の指示を行う。
　　・カート２７から状態を受け取る。
　　・カート２７の状態を配送管理システム４１に返す。
　　・カート制御システム６１と連携し、個配送、配送計画を完遂する。
　　・ボックス２８の状態を管理する。
　　・ユーザ１２（スマートフォン１１）、管理者２０（パーソナルコンピュータ１９）に、カート２７とボックス２８の状況、依頼を通知する。
　　・カート２７と直接のやりとりを行う。

　カート管理システム４４の機能要件は次の通りである。
　　・配送サイト１６側（ユーザ側）
　　　　状況を更新する(カート位置)。
　　・配送管理システム４１側
　　　　カートリソース・ボックス２８の状態を返す。
　　　　配送計画・個配送を受け取る。
　　　　個配送の開始・完了を通知する
　　　　配送計画の完了(帰還)を確認する。
　　　　異常を検知する。
　　　　異常を通知する。
　　・カート２７側
　　　　カート２７の停止を通知する。
　　　　個配送指示を通知する。
　　　　カート状態・周辺状況を受け取る。
　　・管理サイト１８側
　　　　状況を更新する(カート位置、カート状態)。
　　　　各種の情報を通知する(異常系)。
　　　　停止コマンドを受け付け、カート２７側に伝える。

　カート２７は、自律的に動き、荷物を目的地まで運ぶ移動体であり、常にオンライン状態とされる。カート２７は相互にインタラクションがあり、ぶつからないように自律移動する。少々の経路ズレはカート２７内で修正される。カート２７は、雨天等、荒天時でも動くことができる。

　クライアントシステム５１のカート制御システム６１は、カート２７を制御するシステムであり、カート２７の上にある。カート制御システム６１は、カート制御にかかわる全般の機能を有し、次のような処理を行う。
　　・カート管理システム４４と連携し、個配送を完遂する。
　　・カート２７を運行する。
　　　　停止・開始、障害物をよける、段差を乗り越える、安全のために止まる等。
　　　　周りの状況(静止画・動画)をアップロードする。
　　・カート管理システム４４と直接のやりとりを行う。

　カート制御システム６１の機能要件は次の通りである。
　　・カート管理システム４４側
　　　　カート停止を受け取る。
　　　　個配送を受け取る。
　　　　カート状態・周辺状況を更新する。
　　・ボックス制御システム６２側
　　　　施錠完了を受け取る。
　　　　受け渡し完了を受け取る。

　ボックス制御システム６２は、ボックス群を制御するシステムであり、カート２７の上にある。ボックス制御システム６２は、ボックス制御にかかわる全般の機能を有し、次のような処理を行う。
　　・カート制御システム６１と連携し、個配送を完遂する。
　　　　ボックス状態を更新する。
　　　　受け渡しの完了をカート制御システム４４側に通知する。
　　・カート管理システム４４からボックス２８のキー情報の更新依頼を受ける。
　　・荷物の受け渡しを管理する（オフライン）。
　　　　錠を開ける・閉じる。
　　　　扉を開ける（閉じない）。
　　　　錠の開閉を確認する。
　　　　扉の開閉を確認する。
　　　　荷物の有無を確認する。
　　・カート管理システム４４と直接のやりとりを行う。

　ボックス制御システム６２の機能要件は次の通りである。
　　・カート管理システム４４側
　　　　ボックス状態を更新する。
　　　　ボックス２８のキーを更新する。
　　・カート制御システム６１側
　　　　施錠完了を通知する。
　　　　受け渡し完了を通知する。

　ボックス２８は、カート２７に幾つかあるスペースであり、パッケージ２６を収納する。ボックス２８には、扉と錠が付いている。取り出されたことがわかるようになっている。ボックス２８のキーとしてはFelica（商標）を用いることができる。この場合、ユーザのFelicaIDが所定のタイミングで配送管理システム４１に伝送され、ボックス２８の扉を開放するキーに変換される。キー情報として、その他のユーザ情報が用いられる場合、配送管理システム４１はそのユーザ情報に基づいて、ユーザ１２がボックス２８から荷物を取り出すのに使用されるキーを生成する。ボックス２８のキーは、ボックス制御システム６２により、内部の荷物（商品２５）の購入者（受け取る者）のキーに書き換えられる。

　なお、所定のタイミングで、カート管理システム４４は、ボックス制御システム６２に対して、ボックス２８のキーのアップデートを要求する。ボックス制御システム６２は、カート管理システム４４からのキーの更新処理の要求を受け取ると、update box keys処理を実行する。すなわち、ボックス２８のキーが指示されたキーに更新される。

　ユーザ１２により購入された商品２５は、配送単位ごとにパッケージ２６に収容されて、荷物として配送される。パッケージ２６は段ボールにより箱状に形成されるが、ビニール袋などで形成してもよい。

　なお、本明細書において、イベントとは、例えば、カート２７が出発する、積み込みが完了するなど、大きくステータスが変更された時に起きる事象である。

＜通常シナリオの処理＞
　　発注処理（図３乃至図９）

　次に、ユーザ１２が商品２５を購入し、その商品２５の荷物がカート２７により配送される通常シナリオの処理（発注処理と配送処理）について説明する。図３は、通常シナリオの発注処理を説明する図である。図３に示されるように、発注処理においては、ステップＳ１において商品購入処理が行われる。ユーザ１２は購入サイト１４にアクセスし、購入する商品を選択し、その配送を依頼する。例えばクレジットカード、電子マネー等による支払いがここで行われる。もちろん振り込み等の支払いが行われる場合もある。

　ステップＳ２においてサーバーシステム１７により、配送計画作成処理が行われる。これにより購入された商品２５の荷物を効率的に各ユーザ１２に配送する最適化されたルートの配送計画が作成される。

　ステップＳ３においてサーバーシステム１７により、配送指示処理が行われる。サーバーシステム１７は、作成された配送計画に基づく商品の配送を作業者２３（タブレット２２）に依頼する。

　ステップＳ４において作業者２３は積み込み処理を行う。すなわち指示された商品２５をパッケージ２６に入れ、そのパッケージ２６を荷物として、指示されたボックス２８に収容し、その扉をロックする処理が行われる。

　以下、ステップＳ１乃至ステップＳ４の各処理の詳細についてさらに説明する。

　図４は、商品購入処理を説明するフローチャートである。この図４を参照して、図３のステップＳ１の商品購入処理の詳細についてさらに説明する。

　ステップＳ１１においてユーザ１２Ａはスマートフォン１１Ａを操作し、商品を購入する。ステップＳ１１においてスマートフォン１１Ａは、Buying処理を実行する。すなわち、ユーザ１２Ａは購入する商品２５を指定し、希望する配送期間を指定する。ここで支払いの手続きも行われる。

　購入サイト１４は、ステップＳ５１においてスマートフォン１１ＡからのBuying手続きを受け取る。

　ステップＳ１２においてスマートフォン１１Ａは、配送管理システム４１に対してrequest delivery処理を実行する。つまり、商品２５の配送が要求される。配信管理システム４１はステップＳ８１においてこの配送要求を受け取る。

　配送希望時間帯は、例えば９時００分から９時３０分、９時３０分から１０時００分、１０時００分から１０時３０分といったように、３０分単位でユーザ１２Ａが選択可能とされる。もちろん、配送希望時間帯は、例えば５分、１０分等の、その他の時間に設定することもできる。

　ユーザ１２Ａが希望する配送時間帯、すなわち利用可能時間帯を検索する処理については図３１を参照して後述する。

　以上においては、ユーザ１２Ａのスマートフォン１１Ａと、購入サイト１４および配送管理システム４１との間の処理について説明した。ユーザ１２Ｂのスマートフォン１１Ｂと、購入サイト１４および配送管理システム４１との間においても同様の処理が行われる。その処理が図４のステップＳ３１、ステップＳ３２、ステップＳ５２、並びにステップＳ８２の処理として記載されている。これらの処理は上述したユーザ１２Ａのスマートフォン１１Ａの場合と同様なので、その説明は省略する。このようにして、配送管理システム４１には複数のユーザ１２から複数の商品２５の荷物の配送が要求される。

　図５は、配送計画作成処理を説明するフローチャートである。この図５を参照して、図３のステップＳ２の配送計画作成処理の詳細についてさらに説明する。

　ステップＳ１０１においてユーザ１２（スマートフォン１１）は、購入サイト１４に対してBuying処理を実行する。購入サイト１４はステップＳ１１１においてこの処理を受け付け、ステップＳ１１２においてrequest delivery処理を実行する。配信管理システム４１はステップＳ１２１において、このrequest delivery処理を受け付ける。以上の処理は、上述した図４の商品購入の処理である。

　ステップＳ１２２において配送管理システム４１は、create delivery plan処理を実行する。すなわち、配送管理システム４１は配送計画(delivery plan)を生成/更新する。ステップＳ１２３において配送管理システム４１は、カート管理システム４４に対して、confirm cart resource処理を実行する。ステップＳ１３１においてカート管理システム４４は、confirm cart resource処理を受け付ける。カート管理システム４４はステップＳ１３２においてレスポンスを配送管理システム４１に返し、ステップＳ１２４において配送管理システム４１はこのレスポンスを受け取る。つまり、配送に必要なカート２７のリソースが確認される。

　ステップＳ１２５において配送管理システム４１は、calculate delivery time処理を実行する。すなわち、個配送(delivery command)の出発地と目的地から配送時間帯が計算される。個配送とは、所定のポイント４（出発地）から次のポイント４（目的地）までの配送である。ステップＳ１２６において配送管理システム４１は、update delivery plan処理を実行する。すなわち配送計画が更新される。その後、配送管理システム４１は、配送計画を作成するタイミングまで待機する。

　配送計画作成に当たって、例えば荷物の積み込み時間は５分、ユーザ１２による荷物の受け取り時間は５分、その荷物の受け取り時間のタイムアウトは１５分等とすることができる。配送管理システム４１は、個配送の到着予定時刻をユーザ１２に通知する。

　図６は、配送計画を説明する図である。図６の例では、配送の開始地ｓから、目的地Ａ、目的地Ｃ、目的地Ｂ、目的地Ｄを経て開始地ｓまで戻るルートの配送計画が作成されている。開始地ｓの出発時刻は16:00、帰還時刻は16:50とされている。この例では荷物の積み込みの時間は、１個口の積み込みに５分かかるとして、４個口の積み込み時間は合計２０分（４×５分）とされている。また、荷物の受け取り時間のタイムアウトは５分とされている。

　最初の個配送１は、開始地ｓから最初の目的地Ａまでの配送であり、出発時刻Ｄは16:00、到着時刻Ａは16:05とされている。そして、荷物の受け取り時間のタイムアウトは５分とされ、カート２７は荷物の受け取りのため、時刻16:10まで待機する。

　次の個配送２は、最初の目的地Ａから次の目的地Ｃまでの配送であり、出発時刻Ｄは16:10、到着時刻Ａは16:15とされている。そして、荷物の受け取り時間のタイムアウトは５分とされ、カート２７は荷物の受け取りのため、時刻16:20まで待機する。

　３番目の個配送３は、２番目の目的地Ｃから３番目の目的地Ｂまでの配送であり、出発時刻Ｄは16:20、到着時刻Ａは16:25とされている。そして、荷物の受け取り時間のタイムアウトは５分とされ、カート２７は荷物の受け取りのため、時刻16:30まで待機する。

　４番目の個配送４は、３番目の目的地Ｂから４番目の目的地Ｄまでの配送であり、出発時刻Ｄは16:30、到着時刻Ａは16:35とされている。そして、荷物の受け取り時間のタイムアウトは５分とされ、カート２７は荷物の受け取りのため、時刻16:40まで待機する。

　最後の個配送５は、４番目の目的地Ｄから開始地ｓまでの配送であり、出発時刻Ｄは16:40、到着時刻Ａは16:50とされている。荷物は全て配送されたので、荷物の受け取りのための時刻は記述されない。

　配送計画の作成処理では、次のようなことが考慮される。
　　・到着時刻予測
　　　　運送データを取り貯め、予測が行われる。その際、気象条件、時間帯、季節、要求元、荷物等が考慮される。
　　・ルーティング(最短ルーティング)
　　　　実時間で解くことが困難なので、近似解が求められる。
　　・リソース(カート)予測、動的リソース増
　　　　カート２７が運行中ならば、常にいつ帰ってくるのかが予測され、そのうえで計画が立てられる。
　　　　カート２７がいつ追加されても常に計算がし直され、計画が立てられる。
　　・ユーザデマンド最大化
　　　　ユーザ１２はある時間幅のある中で、時間帯を指定する。それを、運送依頼しているユーザの指定時間帯を満たすようにする。必ずしもすべてが満たせるわけではないので、なるべく希望時間帯が近くなるように、全体的な最適化が行なわれる。
　　　　空港内の荷物輸送など、時間がクリティカルな場合には、計算の結果、希望時間帯を満たせないと判断されたとき、配送を拒否することもある。逆に、クリティカルなものを優先して計画に組み込むように工夫することもできる。
　　・動的計画
　　　　ユーザ１２からいつ配送が要求されてくるのか判らないので、配送管理システム４１は、作業者２３への配送依頼をなるべく待つ。現状のユーザ１２の希望時間帯が守れない場合には、以後の配送依頼を待たずに、カート２７が出発することもある。またリソースに積み込める以上の依頼がきた場合には、以後の配送依頼を待たずに、カート２７は出発する。
　　　　途中でユーザ１２からの配送キャンセル、時間・場所変更が発生した場合、ルートが再計算される。荷物はすでにそのカート２７に積み込まれているので、そこで再度ルーティングが行われる。
　　・混載とピストン
　　　　依頼が少なく、一度配送し、帰ってきても間に合う場合には、混載せず、ピストン配送することもある。
　　・需要予測（荷主）
　　　　取り貯めた配送データから、いつどこでどのような依頼が発生しそうかが、予測される。
　　　　予測結果を使い、ピークの計算もでき、リソースや在庫管理などに役立てる。
　　・最低リソース計算
　　　　配送範囲、人口や世帯の統計情報、店舗のキャパシティから、最低で配送を回せるリソース（カート数など）を計算することができる。
　　　　ピークの計算ができるので、リソース配分などが分かり、余剰のカート２７などを整備に回すなどの計画ができる。拠点間のカート２７の融通などもできる。

　なお、配送計画作成処理の詳細な例については、図２２を参照して後述する。

　図７は、配送指示処理を説明するフローチャートである。この図７を参照して、図３のステップＳ３の配送指示処理の詳細についてさらに説明する。

　ステップＳ１６１において配送管理システム４１は、close delivery plan処理を実行する。すなわち、配送計画作成のための受け付けが終了され、最終的に確定する。

　ステップＳ１６２において配送管理システム４１は、create loading command処理を実行する。すなわち、作成された配送計画に基づき、作業者２３に対する各個配送の積み込み指示(Loading Command)が生成される。ステップＳ１６３において配送管理システム４１は、send loading command処理を実行する。すなわち、積み込み指示が作業者２３のタブレット２２に通知される。この通知は、ステップＳ１９１において作業者２３（タブレット２２）により受け取られる。

　ステップＳ１６４において配送管理システム４１は、notify estimate arrival time処理を実行する。すなわち、ユーザ１２（スマートフォン１１）に対して、荷物の到着予定時刻が通知される。ステップＳ１５１においてユーザ１２（スマートフォン１１）は、この通知を受け取る。

　ステップＳ１６５において配送管理システム４１は、カート管理システム４４に対して、notify delivery plan処理を実行する。すなわち、配送管理システム４１からカート管理システム４４に対して、配送計画が通知される。ステップＳ１７１においてカート管理システム４４は、この通知を受け取る。

　図８は、積み込み処理を説明するフローチャートである。この図８を参照して、図３のステップＳ４の積み込み処理の詳細についてさらに説明する。

　ステップＳ２１１において配送管理システム４１は、作業者２３（タブレット２２）に対して、send loading command処理を実行する。すなわち、荷物のカート２７への積み込みが要求される。ステップＳ２８１において作業者２３（タブレット２２）によりこの要求が受け取られると、ステップＳ２８２において作業者２３は、packing and loading処理を実行する。すなわち、作業者２３はタブレット２３に通知された各個配送の積み込み指示に基づいて、指定された商品２５をパッケージ２６に収容し、そのパッケージ２６を荷物として指定されたボックス２８に積み込む作業をする。

　積み込み指示は、どのカート２７の、どのボックス２８に、どのユーザ１２のパッケージ２６を、いつまでに入れるのかの情報が記載されている。作業者２３はタブレット２２の積み込み指示に従って、商品２５をパッケージ２６に詰めて荷物とし、指示されたカート２７の指定されたボックス２８の扉を開け、荷物を積み込み、確認して扉を締める。

　図９は、荷物の積み込みを説明する図である。パッケージ２６としては、商品２５の大きさに応じて所定の大きさのパッケージ２６が選択される。商品２５が複数個存在する場合、ユーザ１２のオプションの指定が「まとめて配送」の場合には、全て（図９の例では２個）が１つのパッケージ２６に収容され、「分けて配送」の場合には、１つずつが別のパッケージ２６に収容される。そして商品２５が収容されたパッケージ２６が荷物としてボックス２８内に積み込まれる。１個のボックス２８にはパッケージ２６が1個だけ積み込まれる。１人のユーザ１２が複数のパッケージ２６を有する場合、複数個のボックス２８が割り当てられることになる。

　作業者２３はパッケージ２６を積み込んだボックス２８の扉を閉じたとき、タブレット２２を操作し、扉を閉じたことを入力する。このときステップＳ２８３においてタブレット２２は、close door処理を実行する。すなわち、扉が閉じられたことがボックス制御システム６２に通知される。ボックス制御システム６２は、ステップＳ２６１でこの通知を受け取ると、ステップＳ２６２においてlock automatically処理を実行する。すなわち、ボックス制御システム６２は、扉が閉まると自動的にそれをロックする。

　ステップＳ２６３においてボックス制御システム６２は、カート管理システム４４に対して、notify locked処理を実行する。すなわち扉がロックされたことが、カート管理システム４４に通知される。カート管理システム４４はこの通知をステップＳ２２１で受け取ると、ステップＳ２２２においてレスポンスを返す。このレスポンスはステップＳ２６４においてボックス制御システム６２により受け取られる。

　同様に、ステップＳ２６５においてボックス制御システム６２は、カート制御システム６１に対して、notify locked処理を実行する。すなわち扉がロックされたことが、カート制御システム６１に通知される。カート制御システム６１はこの通知をステップＳ２４１で受け取ると、ステップＳ２４２においてレスポンスを返す。このレスポンスはステップＳ２６６においてボックス制御システム６２により受け取られる。

　ステップＳ２８４において作業者２３は、push complete loading処理を実行する。具体的には、作業者２３は、タブレット２２上で「完了」を操作して、作業が完了したことを入力する。ステップＳ２８５においてタブレット２２は、notify completed処理を実行する。すなわち、作業の完了が配送管理システム４１に通知される。配送管理システム４１はこの通知をステップＳ２１２で受け取る。

　ステップＳ２１３において配送管理システム４１は、confirm box status処理を実行する。すなわち、配送管理システム４１はカート・ボックス状態を、カート管理システム４４に照合を取り、確認する。ステップＳ２２３においてカート管理システム４４はこの確認要求を受け取ると、確認処理を行って、ステップＳ２２４において確認結果のレスポンスを返す。ステップＳ２１４において配送管理システム４１は、このレスポンスを受け取る。そして、ステップＳ２１５において配送管理システム４１は、作業者２３のタブレット２２に対して、ステップＳ２８５においてタブレット２２が出力したnotify completedに対応するレスポンスを返す。

　以上の処理は、数回繰り返される。すなわち、作業者２３は、同様の作業を、指示がなくなるまで繰り返す。

　ステップＳ２１６において配送管理システム４１は、confirm completed loading処理を実行する。すなわち、配送管理システム４１は、カート２７の各ボックス２８の積み込み状況を確認し、積み込み完了を確認する。ステップＳ２１７において配送管理システム４１は、send delivery command処理を実行する。すなわち、配送管理システム４１は、カート管理システム４４に対して。個配送の指示を要求する。カート管理システム４４はステップＳ２２５において、この要求を受け取ると、ステップＳ２２６においてカート制御システム６１に対して、send delivery command処理を実行する。このsend delivery command処理はステップＳ２４３においてカート制御システム６１により受け取られる。つまり、現在位置から次の目的地までの配送が、配送管理システム４１からカート管理システム４４を介してカート制御システム６１に指示される。

　ステップＳ２２７においてカート制御システム４４は配送管理システム４１に対してレスポンスを返し、このレスポンスをステップＳ２１８において配送管理システム４１が受け取る。

　カート制御システム６１は、ステップＳ２４４においてwait for start time処理を実行する。すなわち、カート制御システム６１は、出発時刻まで待機する。出発時刻は、ステップＳ２４３において受け取られたsend delivery command処理に記述されている。

＜通常シナリオの処理＞
　　配送処理（図１０乃至図１４）

　次に、ユーザ１２が商品２５を購入し、その商品２５が荷物としてカート２７により配送される通常シナリオの処理（発注処理と配送処理）のうちの配送処理について、図１０を参照して説明する。図１０は、通常シナリオの配送処理を説明する図である。

　ステップＳ３０１において出発処理が行われる。すなわち、上述した図３の発注処理のステップＳ４の積み込み処理が完了した場合、出発時刻になるとカート２７は目的地に向けて出発する。

　ステップＳ３０２において移動到着処理が行われる。すなわち、出発したカート２７は、目的地に向かって移動し、目的地に到着すると停止する。

　ステップＳ３０３において受け取り処理が行われる。すなわち、カート２７が目的地に到着すると、ユーザ１２に到着が通知され、ユーザ１２はパッケージ２６をボックス２８から取り出す。

　ステップＳ３０４において帰還処理が行われる。すなわち、すべての目的地への配送が完了すると、カート２７は最初の開始地に帰還する。

　以下、ステップＳ３０１乃至ステップＳ３０４の各処理の詳細についてさらに説明する。

　図１１は、出発処理を説明するフローチャートである。この図１１を参照して、図１０のステップＳ３０１の出発処理の詳細についてさらに説明する。

　ステップＳ３８１においてカート制御システム６１は、start処理を実行する。すなわち、カート制御システム６１は、出発時刻になると、発送元を自律的に出発し、目的地に向かって移動する。出発時刻は、図８のステップＳ２４３においてカート管理システム４４から受け取ったdelivery commandに記述されている。

　ステップＳ３８２においてカート制御システム６１は、notify start処理を実行する。すなわち、カート管理システム４４に出発が通知される。この通知は、ステップＳ３５１においてカート管理システム４４により受け取られる。

　以下同様に、ステップＳ３５２においてカート管理システム４４は、notify start処理を実行する。すなわち、配送管理システム４１に出発が通知される。この通知は、ステップＳ３３１において配送管理システム４１により受け取られる。

　また、ステップＳ３３２においてカート管理システム４４は、notify start処理を実行する。すなわち、ユーザ１２（スマートフォン１１）に配送開始が通知される。この通知は、ステップＳ３１１においてユーザ１２（スマートフォン１１）により受け取られる。

　カート２７は人、モノ等に衝突しないように走行する。カート２７はそのための機能を有している。カート２７は、歩道上の安全を確認しながら、障害物は原則よけて6km/hで走行する。カート２７は、管理のために管理者２０（パーソナルコンピュータ１９）に、カメラ３０により撮影された360度の画像をストリーミングするか、または一定の間隔で静止画像を送り続ける。カート２７は、手動移動(押せば動くこと)も可能なように、ロックを手動で切り替えることができる。

　カート２７は状況に応じてスピーカ３２から適宜アラート（外に向けての音）を出す。例えば危険な時、曲がる時、止まる時、動き出す時、異常事態が発生した時(例えばスタックした時)等にアラートが出される。

　ステップＳ４０１において管理者２０(パーソナルコンピュータ１９)は、stop処理を実行する。すなわち、カート管理システム４４に停止コマンドが通知される。カート管理システム４４は、ステップＳ３５３においてこの通知を受け取ると、ステップＳ３５４においてカート制御システム６１に対してstop処理を実行する。すなわち、カート制御システム６１に対して停止コマンドが通知される。

　カート制御システム６１はこのコマンドをステップＳ３８３において受け取ると、ステップＳ３８４においてカート管理システム４４にレスポンスを返す。このレスポンスは、ステップＳ３５５においてカート管理システム４４により受け取られる。カート管理システム４４はステップＳ３５６において管理者２０(パーソナルコンピュータ１９)にレスポンスを返す。このレスポンスは、ステップＳ４０２において管理者２０(パーソナルコンピュータ１９)により受け取られる。

　ステップＳ３８５においてカート制御システム６１は、stop処理を実行する。すなわち、カート２７が停止される。ステップＳ３８６においてカート制御システム６１は、notify stop処理を実行する。すなわち、停止したことがカート管理システム４４に通知される。カート管理システム４４はステップＳ３５７においてこの通知を受け取ると、ステップＳ３５８において、notify stop処理を実行する。すなわち、停止したことが、管理者２０(パーソナルコンピュータ１９)に通知される。この通知は、ステップＳ４０３において管理者２０(パーソナルコンピュータ１９)により受け取られる。

　なお、以上の停止処理は、カート２７が実際に停止するのかをテストするために行われる。

　また、カート制御システム６１は、ステップＳ３８７において、emergency処理を実行する。すなわち、カート２７が障害物等に起因してスタックする等の異常（緊急事態）が検出されると、スピーカ３２から異常アラートが発生される。そして、カート制御システム６１は、ステップＳ３８８においてnotify emergency処理を実行する。すなわち、カート制御システム６１はカート管理システム４４に異常を通知し、ステップＳ３８９においてstop処理を実行する。すなわち、カート２７の走行が停止される。

　カート管理システム４４はステップＳ３５９において、異常の通知を受け取ると、ステップＳ３６０において、notify emergency処理を実行する。すなわち、管理者２０(パーソナルコンピュータ１９)に異常が通知される。この通知は、管理者２０(パーソナルコンピュータ１９)によりステップＳ４０４において受け取られる。

　また、カート管理システム４４はステップＳ３６１において、notify emergency処理を実行する。すなわち、配送管理システム４１に異常が通知される。この通知は、ステップＳ３３３において配送管理システム４１により受け取られる。配送管理システム４１はステップＳ３３４においてnotify emergency(not everything)処理を実行する。すなわち、ユーザ１２（スマートフォン１１）に対して、異常が通知される。この通知はステップＳ３１２において、ユーザ１２（スマートフォン１１）により受け取られる。このユーザ１２（スマートフォン１１）に対する通知は、ユーザ１２に関係する異常事態が発生したときにだけ行われる。

　このような場合、管理者２０（パーソナルコンピュータ１９）は、配送の状況を把握するために、ステップＳ４０５において、get delivery status処理を実行する。すなわち、配送管理システム４１に対して配送の状況の取得が要求される。ステップＳ３３５においてこの要求を受け取った配送管理システム４１は、ステップＳ３３６において、管理者２０（パーソナルコンピュータ１９）に対して最新の配送の状況を表すレスポンスを返す。このレスポンスはステップＳ４０６において管理者２０（パーソナルコンピュータ１９）により受け取られる。

　また、ユーザ１２（スマートフォン１１）も、配送の状況を把握するために、ステップＳ３１３において、get delivery status処理を実行する。すなわち、配送管理システム４１に対して配送の状況の取得が要求される。ステップＳ３３７においてこの要求を受け取った配送管理システム４１は、ステップＳ３３８において、最新の配送の状況を表すレスポンスを返す。このレスポンスはステップＳ３１４において、ユーザ１２（スマートフォン１１）により受け取られる。

　さらに管理者２０（パーソナルコンピュータ１９）は、カート２７の状況を把握する場合、ステップＳ４０７において、get cart status処理を実行する。すなわち、カート管理システム４４に対してカート２７の状況の取得が要求される。ステップＳ３６２においてこの要求を受け取ったカート管理システム４４は、ステップＳ３６３において、管理者２０（パーソナルコンピュータ１９）に対して最新のカート２７の状況を表すレスポンスを返す。このレスポンスはステップＳ４０８において管理者２０（パーソナルコンピュータ１９）により受け取られる。

　また、ユーザ１２（スマートフォン１１）も、カート２７の状況を把握する場合、ステップＳ３１５において、get cart status 処理を実行する。すなわち、カート管理システム４４に対してカート２７の状況の取得が要求される。ステップＳ３６４においてこの要求を受け取ったカート管理システム４４は、ステップＳ３６５において、最新のカート２７の状況を表すレスポンスを返す。このレスポンスはステップＳ３１６において、ユーザ１２（スマートフォン１１）により受け取られる。

　なお図示は省略されているが、停止したカート２７は、カート管理システム４４から復帰コマンドが発行されたとき、再び走行を開始する。

　図１２は、移動到着処理を説明するフローチャートである。この図１２を参照して、図１０のステップＳ３０２の移動到着処理の詳細についてさらに説明する。

　ステップＳ４７１においてカート制御システム６１は、update status処理を実行する。すなわち、カート制御システム６１はカート管理システム４４に対して、ステータスの更新を要求する。カート管理システム４４はステップＳ４５１においてこの要求を受け取ると、ステップＳ４５２においてレスポンスを返す。ステップＳ４７２においてカート制御システム６１は、このレスポンスを受け取る。すなわち、カート２７のステータスがカメラ３０により撮影された静止画とともに、カート管理システム４４に送信される。

　以上のカート制御システム６１のステップＳ４７１，Ｓ４７２の処理、並びにカート管理システム４４のステップＳ４５１，Ｓ４５２の処理は繰り返される。このように、カート制御システム６１は移動中もステータス（静止画）を、カート管理システム４４に適宜（例えば５秒に1回など）アップデートする。

　カート制御システム６１はステータス通知が何度か失敗した場合、異常アラートを発し、カート２７を停止する。

　カート管理システム４４はステップＳ４５３において、detect anormality処理を実行する。そして、異常（通常ではない事態）が検知された場合、カート管理システム４４はステップＳ４５４において、管理者２０（パーソナルコンピュータ１９）に対して、notify anormality処理を実行する。すなわち、異常の発生が管理者２０（パーソナルコンピュータ１９）に通知される。また、カート管理システム４４は配送管理システム４１に対してnotify anormality処理を実行する。すなわち、異常の発生が配送管理システム４１に通知される。

　配送管理システム４１はこの通知をステップＳ４３１において受け取ると、ステップＳ４３２においてユーザ１２（スマートフォン１１）に対して、notify anormality 処理を実行する。すなわち、ユーザ１２（スマートフォン１１）に対して異常の発生が通知される。この通知は、ステップＳ４２１において、ユーザ１２（スマートフォン１１）により受け取られる。

　ステップＳ４７３においてカート制御システム６１は、arrive処理を実行する。すなわち目的地への到着が検知されると、ステップＳ４７４においてカート制御システム６１は、notify arrival処理を実行する。すなわち、カート管理システム４４に対して到着が通知される。カート管理システム４４は、ステップＳ４５５においてこの通知を受け取ると、ステップＳ４５６においてcheck returning処理を実行する。すなわち、開始地である発送元２４に帰還したのかが確認される。いまの場合、カート２７はまだ帰還していない。

　ステップＳ４５７においてカート管理システム４４は、notify arrival処理を実行する。すなわち、管理者２０（パーソナルコンピュータ１９）と配送管理システム４１に対して、到着が通知される。管理者２０（パーソナルコンピュータ１９）はステップＳ４９２においてこの通知を受け取る。配送管理システム４１はステップＳ４３３においてこの通知を受け取ると、ステップＳ４３４において、ユーザ１２（スマートフォン１１）に対してnotify arrival処理を実行する。すなわち、ユーザ１２（スマートフォン１１）に到着が通知される。これにより荷物の受け取りが促される。

　この通知は、ステップＳ４２２においてユーザ１２（スマートフォン１１）により受け取られる。

　カート制御システム６１はステップＳ４７５において、wait for pickup処理を実行する。すなわち、ステップＳ４２２において到着の通知を受けたユーザ１２が荷物を受け取りにくるので、カート２７は指示された時刻まで待機する。待機する時間（出発する時刻）は、図８のステップＳ２４３において受け取ったdelivery commandに記述されている。

　図１３は、受け取り処理を説明するフローチャートである。この図１３を参照して、図１０のステップＳ３０３の受け取り処理の詳細についてさらに説明する。

　ステップＳ５５１においてカート制御システム６１は、wait for pickup処理を実行する。すなわち、図１２のステップＳ４２２において到着の通知を受けたユーザ１２が荷物を受け取りにくるので、カート２７は指示された時刻まで待機する。この処理は図１２のステップＳ４７５の処理としてすでに説明した処理である。

　ステップＳ５１１においてユーザ１２（スマートフォン１１）は、open with user key処理を実行する。すなわち、ユーザ１２はカート２７に近寄り、通知を受けている番号のボックス２８にスマートフォン１１をかざす。スマートフォン１１には配布されたキーが記憶されており、近接無線通信によりそのキーがボックス２８を介してボックス制御システム６２に伝送される。

　ボックス制御システム６２はステップＳ５７１においてこのキーを受け取ると、ステップＳ５７２においてunlock and open door処理を実行する。すなわち、受け取ったキーがそのボックス２８に対応して記憶されているキーと一致している場合、そのボックス２８の扉が開錠され、開かれる。

　ユーザ１２はステップＳ５１２においてpickup処理を実行し、ステップＳ５１３においてclose door処理を実行する。すなわち、ユーザ１２はボックス２８の中からパッケージ２６を取り出し、扉を閉める。これにより受け渡しが完了する。

　ボックス制御システム６２はステップＳ５７３において扉の閉塞を検知すると、ステップＳ５７４においてcheck load & lock door処理を実行する。すなわち、ボックス２８に取り付けられているセンサ２９はボックス２８内のパッケージ２６を検知して、パッケージ２６の取り損ないの有無を検知する。パッケージ２６がボックス２８内に残っている場合には錠は閉まらない。扉が開放されたままのとき、スピーカ３２からアラートが発生され、扉を閉めることが促される。パッケージ２６が取り出され、扉が閉じられたとき、扉は施錠される。

　受け取りが完了したとき、ステップＳ５７５において、ボックス制御システム６２はnotify complete pickup処理を実行する。すなわち、受け取りの完了がカート管理システム４４に通知される。カート管理システム４４は、ステップＳ５４１においてこの通知を受け取ると、ステップＳ５４２において、notify complete delivery処理を実行する。すなわち、配送管理システム４１に配送の完了が通知される。

　配送管理システム４１はこの通知をステップＳ５２１において受け取ると、ステップＳ５２２において、notify complete pickup処理を実行する。すなわち、管理者２０（パーソナルコンピュータ１９）とユーザ１２（スマートフォン１１）に受け取り完了が通知される。この通知は、ステップＳ５８１において管理者２０（パーソナルコンピュータ１９）により、そしてステップＳ５１４においてユーザ１２（スマートフォン１１）により、それぞれ受け取られる。

　ステップＳ５２３において配送管理システム４１は、カート管理システム４４にレスポンスを返す。カート管理システム４４は、ステップＳ５４３においてこのレスポンスを受けとると、ステップＳ５４４においてボックス制御システム６２にレスポンスを返す。

　ボックス制御システム６２はステップＳ５７６においてこのレスポンスを受け取ると、ステップＳ５７７においてnotify complete pickup処理を実行する。すなわち、カート制御システム６１に受け取り完了が通知される。この通知はステップＳ５５２においてカート制御システム６１により受け取られる。

　配送管理システム４１は、ステップＳ５２４においてupdate estimate time処理を実行する。すなわち、実際にパッケージ２６が受け取られた時刻に基づいて、以降の個配送の配送時間帯が更新される。そして、ステップＳ５２５において配送管理システム４１は、update estimate time処理を実行する。すなわち、更新された配送時間帯に基づいて、次の個配送のユーザ１２（スマートフォン１１）に到着予定時刻が通知される。ユーザ１２（スマートフォン１１）は、この通知をステップＳ５１５において受け取る。

　ステップＳ５２６において配送管理システム４１は、send delivery command処理を実行する。すなわち、カート管理システム４４に対して、次の個配送が要求される。カート管理システム４４はステップＳ５４５においてこの要求を受け取ると、ステップＳ５４６においてsend delivery command処理を実行する。すなわち、カート制御システム６１に対して、次の個配送が要求される。カート制御システム６１はステップＳ５５３においてこの個配送の要求を受け取る。

　ステップＳ５４７においてカート管理システム４４は、配送管理システム４１にレスポンスを返す。配送管理システム４１はこのレスポンスを、ステップＳ５２７において受け取る。

　その後、処理は図１１の出発処理に戻る。そして次の個配送が行われる。以上のようにしてルートに沿って個配送が順次行われていく。

　図１４は、帰還処理を説明するフローチャートである。この図１４を参照して、図１０のステップＳ３０４の帰還処理の詳細についてさらに説明する。

　ステップＳ６１１においてカート管理システム４４は、check returning処理を実行する。すなわち、カート管理システム４４は到着地点を確認し、開始地（荷物を積み込んだカート２７が発送元２４）に帰還したかを確認する。カート２７が帰還している場合、ステップＳ６１２においてカート管理システム４４は、notify return処理を実行する。すなわち、カート管理システム４４は配送管理システム４１にカート２７の帰還を通知する。ステップＳ６０２において配送管理システム４１は、complete delivery plan処理を実行する。すなわち、配送管理システム４１は配送計画を完遂する。

　ステップＳ６４１において作業者２３（タブレット２２）は、ボックス制御システム６２に対してopen all boxes処理を実行する。すなわち、作業者２３はマスターキーですべてのボックス２８の扉を開けることができる。ボックス制御システム６２は、ステップＳ６３１においてマスターキーを受け取ると、すべての扉を解錠する。ボックス制御システム６２はステップＳ６３２において、作業者２３（タブレット２２）にレスポンスを返す。作業者２３（タブレット２２）はステップＳ６４２においてこのレスポンスを受け取る。

　ステップＳ６４３において作業者２３（タブレット２２）は、shut down cart処理を実行する。すなわち、作業者２３はシャットダウンボタンを押す。カート制御システム６１はステップＳ６２１において、カート２７をシャットダウンすると、ステップＳ６２２において、notify shutdown処理を実行する。すなわち、カート制御システム６１はシャットダウンをカート管理システム４４に通知する。カート管理システム４４はステップＳ６１３においてこの通知を受け取ると、ステップＳ６１４においてカート制御システム６１にレスポンスを返す。このレスポンスはステップＳ６２３において、カート制御システム６１により受け取られる。

　ステップＳ６４４において作業者２３は、charge cart処理を実行する。すなわち、カート２７が充電される。カート２７はシャットダウンされると、作業者２３が手で押せるようになる。

　ステップＳ６４５において作業者２３（タブレット２２）は、invoke cart処理を実行する。すなわち、作業者２３は充電完了を確認し、起動ボタンを押す。カート制御システム６１は、ステップＳ６２４においてカートを起動すると、ステップＳ６２５において、notify invoke cart処理を実行する。すなわち、カート制御システム６１は、起動をカート管理システム４４に通知する。カート管理システム４４はステップＳ６１５においてこの通知を受け取ると、ステップＳ６１６においてレスポンスをカート制御システム６１に返す。カート制御システム６１はこのレスポンスをステップＳ６２６において受け取る。

　以上の処理が繰り返し行われ、カート２７はその都度作成された配送計画のルートに沿って移動し、荷物を目的地に順次配送する。

＜イレギュラーシナリオの処理（図１５乃至図２０）＞
　図３乃至図１４を参照して説明した以上の処理は、通常シナリオの処理であるが、以下には、通常シナリオではない、イレギュラーシナリオの処理について、図１５乃至図２０を参照して説明する。

　イレギュラーシナリオの処理として、購入がキャンセルされた場合の処理について、図１５を参照して説明する。図１５は、購入キャンセル処理を説明するフローチャートである。ユーザ１２（スマートフォン１１）は購入サイト１４のページから購入自体をキャンセルすることができる。

　最初に、ユーザ１２（スマートフォン１１）のステップＳ６６１，ステップＳ６６２、購入サイト１４のステップＳ６８１、および配送管理システム４１のステップＳ７０１の処理が行われる。すなわち、Buying処理、およびrequest delivery処理が実行される。これらの処理は、上述した図４のユーザ１２（スマートフォン１１）のステップＳ１１，ステップＳ１２、購入サイト１４のステップＳ５１、および配送管理システム４１のステップＳ８１の処理と同じ購入処理である。

　ステップＳ６６３においてユーザ１２（スマートフォン１１）は、cancel処理を実行する。すなわち、ユーザ１２（スマートフォン１１）から購入サイト１４に、購入のキャンセルが要求される。購入サイト１４は、ステップＳ６８２においてこの要求を受け取ると、ステップＳ６８３において、cancel処理を実行する。すなわち、購入のキャンセルが配送管理システム４１に通知される。

　配送管理システム４１は、ステップＳ７０２においてこの通知を受け取ると、ステップＳ７０３においてレスポンスを返す。購入サイト１４は、ステップＳ６８４においてこのレスポンスを受け取ると、ステップＳ６８５において、ユーザ１２（スマートフォン１１）にレスポンスを返す。このレスポンスは、ステップＳ６６４においてユーザ１２（スマートフォン１１）により受け取られる。

　ステップＳ７０４において配送管理システム４１は、update delivery plan処理を実行する。すなわち、配送管理システム４１は、配送計画を更新する。ステップＳ７０５において配送管理システム４１は、update delivery plan処理を実行する。すなわち、配送管理システム４１はカート管理システム４４に更新した配送計画を通知する。

　カート管理システム４４は、ステップＳ７２１においてこの通知を受け取ると、ステップＳ７２２において、update delivery command処理を実行する。すなわち、カート管理システム４４は、カート制御システム６１に、個配送指示を通知する。カート制御システム６１は、ステップＳ７３１においてこの通知を受け取る。ステップＳ７２３においてカート管理システム４４は、レスポンスを返す。配送管理システム４１は、このレスポンスをステップＳ７０６において受け取る。

　ステップＳ７０７において配送管理システム４１は、作業者２３（タブレット２２）に対して、update loading command処理を実行する。すなわち、配送管理システム４１は、作業者２３に、積み込み指示のキャンセルを通知する。作業者２３（タブレット２２）はステップＳ７４１において、この通知を受け取る。

　配送計画確定後、事前にユーザ１２が購入をキャンセルした場合、配送に向かう前であれば、その個配送がキャンセルされ、カート２７はキャンセルされた目的地には停止せずに、その次の目的地に向かう。配送に向かってしまっていた場合、まずは目的地まで向かい、受け取りを待たずに次の目的地に向かうことができる。あるいは、その場で目的地を新たな目的地に変更し、その場から直接新たな目的地に向かうこともできる。

　次に、イレギュラーシナリオの処理として、配送がキャンセルされた場合の処理について、図１６を参照して説明する。図１６は、配送キャンセル処理を説明するフローチャートである。ユーザ１２（スマートフォン１１）は配送サイト１４から配送をキャンセルし、再配送時間帯を入力する。

　ステップＳ７６１においてユーザ１２（スマートフォン１１）は、cancel処理を実行する。すなわち、配送のキャンセルと再配送時間帯が、配送管理システム４１に通知される。配送管理システム４１は、ステップＳ７７１においてこの通知を受け取ると、ステップＳ７７２においてユーザ１２（スマートフォン１１）に、レスポンスを返す。ユーザ１２（スマートフォン１１）はステップＳ７６２においてこのレスポンスを受け取る。

　ステップＳ７７３において配送管理システム４１は、update delivery plan処理を実行する。すなわち再配送時間帯を考慮するように配送計画が更新される。ステップＳ７７４において配送管理システム４１は、update delivery plan処理を実行する。すなわち更新された配送計画がカート管理システム４４に通知される。カート管理システム４４は、ステップＳ７９１においてこの通知を受け取ると、ステップＳ７９２において、update delivery command処理を実行する。すなわちカート制御システム６１に、必要に応じて配送指示の更新が指示される。カート制御システム６１はステップＳ８０１においてこの指示を受け取る。カート管理システム４４はステップＳ７９３においてレスポンスを返す。配送管理システム４１は、このレスポンスをステップＳ７７５において受け取る。

　ステップＳ７７６において配送管理システム４１は、update loading command処理を実行する。すなわち作業者２３（タブレット２２）に対して、積み込みの指示が出される、作業者２３（タブレット２２）はステップＳ８１１において、この指示を受け取り、積み込みを実行する。

　その後、図１５の購入キャンセル処理が行われる。

　次に、イレギュラーシナリオの処理として、再配送する場合の処理について、図１７を参照して説明する。図１７は、再配送処理を説明するフローチャートである。配送時間帯が変更された場合、図１７に示される処理が行われる。

　ステップＳ８４１においてカート管理システム４４は、check returning処理を実行する。すなわち、配送時間帯が変更された荷物を積載しているカート２７が帰還しているかが確認される。配送時間帯が変更された荷物が積み込まれているカート２７がまだ帰還していない場合は、その荷物を乗せたカート２７が帰還するまで待機する処理が行われる。配送時間帯が変更された荷物積み込まれているカート２７がすでに帰還している場合、ステップＳ８４２においてカート管理システム４４は、notify return処理を実行する。すなわち、カート管理システム４４は配送管理システム４１に、カート２７の帰還を通知する。

　配送管理システム４１は、ステップＳ８３１においてこの帰還の通知を受け取ると、ステップＳ８３２においてcheck delivery plan処理を実行する。すなわち配送管理システム４１は、配送計画を確認し、変更された配送時間帯が満足されるように配送計画を作成する。

　ステップＳ８３３において配送管理システム４１は、send loading command処理を実行する。すなわち、配送管理システム４１は、配送計画に基づく積み込みを作業者２３（タブレット２２）に要求する。作業者２３（タブレット２２）はこの要求をステップＳ８６３において受け取る。

　作業者２３（タブレット２２）はこの要求をステップＳ８６３において受け取るが、その前に、ステップＳ８６１においてopen all boxes処理を実行する。すなわち、マスターキーを用いてボックス制御システム６２に対してすべての扉の開放を指示する。ステップＳ８５１においてこの指示を受け取ったボックス制御システム６２は、すべての扉の施錠を解除し、開放する。作業者２３はボックス２８から再配送する荷物を取り出す。

　ステップＳ８５２においてボックス制御システム６２は、作業者２３（タブレット２２）にレスポンスを返す。作業者２３（タブレット２２）はステップＳ８６２においてこのレスポンスを受け取る。

　そこで、作業者２３（タブレット２２）はステップＳ８６３において、配送管理システム４１からの積み込みの要求を受け取ると、ステップＳ８６４においてreloading処理を実行する。すなわち、作業者２３（タブレット２２）はステップＳ８６３において受け取った積み込み要求に従って、ボックス２８から取り出した荷物を、指定されたボックス２８に再度積み込む。

　その後、上述した図８の積み込み処理が行われる。

　次に、イレギュラーシナリオの処理として、カートが動けない場合の処理について、図１８を参照して説明する。図１８は、カートが動けない場合の処理を説明するフローチャートである。

　ステップＳ９０１においてカート制御システム６１は、detect emergency(can not move)処理を実行する。すなわち、何らかの理由により異常（緊急事態）が発生し、カート２７が動けなくなったことが検知される。異常が検知されると、ステップＳ９０２においてカート制御システム６１は、カート管理システム４４に対してnotify emergency処理を実行する。すなわち、カート制御システム６１はカート管理システム４４に異常（カート２７が動けない）を通知する。

　カート管理システム４４は、ステップＳ８９１においてこの通知を受け取ると、ステップＳ８９２において、配送管理システム４１に対して、notify emergency処理を実行する。すなわち、カート管理システム４４は配送管理システム４１に対して異常を通知する。配送管理システム４１はステップＳ８８１において、この通知を受け取る。またカート管理システム４４はステップＳ８９３において、管理者２０（パーソナルコンピュータ１９）に対して、notify emergency処理を実行する。すなわち、カート管理システム４４は管理者２０（パーソナルコンピュータ１９）に対して異常（カート２７が動けない）を通知する。管理者２０（パーソナルコンピュータ１９）はステップＳ９１１において、この通知を受け取る。

　何らかの障害物があり、目的地に行くことができない場合、配送請負側の理由により配送をキャンセルすることができる。あるいは地図情報を更新して、再配達することもできる。電池切れは充電の履歴からわかるはずである。カート２７が破壊されたり、盗まれた場合には、カメラ３０の撮影画像に基づいて、警察に通報するなどの措置を講ずることができる。

　なお、逆に、受け取りが早く終わり、予定時刻より早く出発することができるような場合、そこで予定時刻まで待機したり、次の目的地に移動して、そこで待機したり、移動速度を遅くするなどすることができる。予定より早く着いた原因は確認できるようにしておくのが好ましい。

　次に、イレギュラーシナリオの処理として、顧客が来ない場合の処理について、図１９を参照して説明する。図１９は、顧客が来ない場合の処理を説明するフローチャートである。

　ステップＳ９６１においてカート制御システム６１は、detect emergency(request pickup)処理を実行する。すなわち、カート制御システム６１は、一定時間、受け取りがなされないことを検知する。このとき、カート２７のスピーカ３２から音を鳴らすなどの措置をとることができる。またこのとき、カート制御システム６１はステップＳ９６２において、カート管理システム４４に対して、notify emergency処理を実行する。すなわち、カート制御システム６１はカート管理システム４４に異常を通知する。

　カート管理システム４４は、ステップＳ９５１においてこの通知（受け取り要求）を受け取ると、ステップＳ９５２において配送管理システム４１に対して、notify emergency処理を実行する。すなわち、カート管理システム４４は配送管理システム４１に異常を通知する。

　配送管理システム４１は、ステップＳ９４１においてこの通知を受け取ると、ステップＳ９４２において、ユーザ１２（スマートフォン１１）に対して、request pickup処理を実行する。すなわち、配送管理システム４１はユーザ１２（スマートフォン１１）に受け取りを催促する通知を出す。ステップＳ９３１においてユーザ１２（スマートフォン１１）がこの通知を受け取ると、ユーザ１２はこの催促に基づき荷物を受け取りに行く。

　配送管理システム４１は、ステップＳ９４３において、管理者２０（パーソナルコンピュータ１９）に対して、notify emergency処理を実行する。すなわち、配送管理システム４１は管理者２０（パーソナルコンピュータ１９）に、異常を通知する。管理者２０（パーソナルコンピュータ１９）はステップＳ９７１において、この通知を受け取る。

　ユーザ１２が荷物を受け取りに来ないと、出発予定時刻を超えてしまうので、その後の到着予定時刻等が再度計算し直される。そして、配送管理システム４１が出している状況確認状況を更新することができる。時間のずれがあまりに大きい場合は、ユーザ１２に通知するために、購入サイト１４に通知することができる。

　受け取りを待ったのにユーザ１２が購入をキャンセルしたり、受け取りを待ったのにユーザ１２が希望配送時間帯を変更した場合、受け取り時刻を変更することができる。変更された時点でタイムアウトし、次の目的地に移動を開始することができる。この場合、当初の時刻でタイムアウトした場合と同様の処理が行われる。

　予想よりも遅く着いた場合、着いたことをユーザ１２（スマートフォン１１）に通知し、出発時刻を計算し直すことができる。また予想が遅れた理由を後で確認できるようにするのが好ましい。

　次に、イレギュラーシナリオの処理として、取り忘れの場合の処理について、図２０を参照して説明する。図２０は、取り忘れの場合の処理を説明するフローチャートである。

　ステップＳ１００１においてユーザ１２（スマートフォン１１）は、ボックス制御システム６２に対して、open door処理を実行する。すなわち、ユーザ１２がスマートフォン１１を操作してキーをボックス制御システム６２に読み取らせる。ボックス制御システム６２はステップＳ１０４１においてこのキーを読み取り、それが予め記憶されているキーと一致する場合、ボックス２８の施錠を解除し、扉を開ける。ユーザ１２はボックス２８からパッケージ２６を取り出す。ボックス制御システム６２は、ステップＳ１０４２においてユーザ１２（スマートフォン１１）にレスポンスを返す。ユーザ１２（スマートフォン１１）はステップＳ１００２においてこのレスポンスを受け取る。

　ステップＳ１００３においてユーザ１２は、left some item処理を実行する。すなわち、ユーザ１２がパッケージを取り出すとき、ボックス２８内に何かを残したとする。ステップＳ１００４においてユーザ１２は、close door処理を実行する。すなわちユーザ１２は扉を閉じる。

　ボックス制御システム６２はステップＳ１０４３において、扉が閉じられたことを検知した場合、ステップＳ１０４４において、ユーザ１２（スマートフォン１１）にレスポンスを返す。ユーザ１２（スマートフォン１１）はステップＳ１００５においてこのレスポンスを受け取る。

　ステップＳ１０４５においてボックス制御システム６２は、check load処理を実行する。すなわち、ボックス２８内の荷物の有無が検知される。ステップＳ１０４６においてボックス制御システム６２は、detect left item処理を実行する。すなわち、ボックス２８内に何かが残されていないかがセンサ２９により検知される。ボックス２８内に何かが残されていることが検知された場合、ステップＳ１０４７においてボックス制御システム６２は、beeping処理を実行する。すなわち、スピーカ３２からビープ音が出される。

　ステップＳ１０４８においてボックス制御システム６２は、カート管理システム４４に対してnotify emergency処理を実行する。すなわち、カート管理システム４４に異常が通知される。

　カート管理システム４４は、ステップＳ１０２１において異常の通知を受け取ると、ステップＳ１０２２において、配送管理システム４１に対してnotify emergency処理を実行する。すなわち、配送管理システム４１に異常が通知される。

　配送管理システム４１はステップＳ１０１１において、カート管理システム４４からの異常の通知を受け取ると、ステップＳ１０１２において、ユーザ１２（スマートフォン１１）に対して、request pickup処理を実行する。すなわち、ユーザ１２（スマートフォン１１）に対して受け取りを催促する通知が出される。ステップＳ１００６においてユーザ１２（スマートフォン１１）は、この通知を受け取る。

　またステップＳ１０１３において配送管理システム４１は、管理者２０（パーソナルコンピュータ１９）に対して、notify emergency処理を実行する。すなわち、管理者２０（パーソナルコンピュータ１９）に異常が通知される。この通知は、ステップＳ１０６１において管理者２０（パーソナルコンピュータ１９）により受け取られる。

＜配送計画作成処理（図２１乃至図２９）＞
　次に図３のステップＳ３と図５のフローチャートを参照して説明した配送計画作成処理のうちの、主に配送管理システム４１の処理についてさらに説明するが、この処理を実行するため、配送管理システム４１は、図２１に示される機能的構成を有している。

　図２１は、配送管理システムの構成例を示すブロック図である。配送管理システム４１は判定部１１１、確認部１１２、予測部１１３、および作成部１１４を有している。

　判定部１１１は、依頼の有無、受注終了のタイミング等を判定する。確認部１１２は、希望配送時間帯の利用可能性、ボックスの余裕等を確認する。予測部１１３は、カート２７の帰還時刻等を予測する。作成部１１４は、配送計画等を作成する。

　図２２は、配送計画作成処理を説明するフローチャートである。

　ステップＳ２００１において判定部１１１は、依頼が発生したかを判定する。すなわちユーザ１２（スマートフォン１１）から購入した商品２５の配送の依頼があったかが判定される。

　いま、例えば図２３に示されるように配送の依頼があったとする。図２３は、配送状態を説明する図である。この例においては、次のような３件の配送依頼が発生している。
　　　配送ID：１
　　　　発注時刻　14:04
　　　　希望配送時間帯15:00－15:30
　　　　配送個数：２個口
　　　　配送先：Ｇ
　　　配送ID：２
　　　　発注時刻　14:14
　　　　希望配送時間帯15:00－15:30
　　　　配送個数：１個口
　　　　配送先：Ａ
　　　配送ID：３
　　　　発注時刻　14:23
　　　　希望配送時間帯15:30－16:00
　　　　配送個数：１個口
　　　　配送先：Ｉ

　図２３の例においては、カート２７が配送の開始地ｓ（図２３にはstoreと記載されている）から出発し、荷物を配送する配送先（ポイント４）として、１０個の配送先Ａ乃至配送先Ｊがある。このうちの３つの配送先（目的地）Ｇ，Ａ，Ｉに荷物を配送することが依頼されている。

　ステップＳ２００１において配送の依頼があったと判定された場合、ステップＳ２００２において確認部１１２は、ユーザ１２により指定された希望配送時間帯が利用できるのかを確認する。

　ユーザ１２が指定できる希望配送時間帯は、発注時刻からＡ分後のＷ分の幅の１つの時間帯である。発注直後だと、荷物を積み込む時間がないので、希望配送時間帯は、発注時刻からＡ分後の時間帯となる。ユーザ１２の立場からすると、Ａの値は小さい方が好ましい。Ｗの値を０にするのは、時間的余裕が無くなり、非現実的となる。計算が早くできるならば、指定した段階で「埋まってます」として、その時間帯を選べなくすることができる。

　例えば、Ａ＝３０, Ｗ＝３０であるとする。この場合、例えば時刻16:03に発注があると、３０分後の時刻16:33より後の時間帯が選択可能になるので、17:00-17:30の時間帯から選択可能となる。時刻16:00に発注があると、３０分後の時刻16:30より後の時間帯が選択可能になるので、この場合にも17:00-17:30の時間帯から選択可能となる。任意の自由な点への配送ではなく、予め決められたポイント４のいずれかへの配送とされる。

　例えばID１の配送依頼があった場合、ユーザ１２が指定した希望配送時間帯15:00－15:30が利用できるのかが確認される。発注時刻は14:04であり、配送を開始する開始地ｓから目的地Ｇまでの移動時間は１０分であり、荷物の積み込みの時間は、１個口当たり５分とすると、２個口で１０分となる。従って、出発時刻（配送開始時刻）は、発注時刻14:04より積み込み時間の１０分だけ後の時刻14:14となり、目的地への到着予定時刻は、出発時刻14:14より移動時間の１０分後の14:24となるから、希望配送時間帯15:00－15:30は利用可能であると判断される。もちろん、目的地、そこに移動するルート、目的地まで移動するのにかかる移動時間等を確認するのに必要な地図情報を含む各種の情報は、データベース４３に予め記憶されている。

　なお、ステップＳ２００２の希望配送時間帯が利用できるのかを確認する処理（利用可能時間帯検索処理）の詳細については、図３０乃至図３５を参照して後述する。

　ステップＳ２００３において判定部１１１は、カート２７のリソースがあるかを判定する。カート２７が出払っており、いま利用できるカート２７が存在しない場合、ステップＳ２００４において予測部１１３は、カート２７を発送元２４に要求するか、カート２７の帰還時刻を予測する。すなわち、新たにカート２７が追加されるか、またはいま配送中のカート２７の帰還時刻（配送に向かったカート２７が帰還地に戻ってくる時刻）が予測される。

　ステップＳ２００３において利用できるカート２７が存在すると判定された場合、またはステップＳ２００４において新たなカート２７が追加されるか、利用可能なカート２７の帰還時刻が予測された場合、処理はステップＳ２００５に進む。

　ステップＳ２００５において作成部１１４は、積み込み時間、受け取り時間、目的地までの移動時間に基づいて、配送計画を作成する。積み込み時間は商品２５をパッケージ１６に収容し荷物として、カート２７のボックス２８に積み込むのに掛かる時間である。すなわち、積み込み時間は、実際の積み込みにかかる時間ではなく、配送計画立案中の、積み込みにかかると予想される積み込み予想時間である。受け取り時間は、ユーザ１２がパッケージ２６をボックス２８から受け取ることができるようにする時間である。すなわち、受け取り時間は、実際の受け取りにかかる時間ではなく、配送計画立案中の、受け取りにかかると予想される受け取り予想時間である。目的地までの移動時間は、カート２７が開始地ｓから目的地Ｇまで、移動するのにかかると予想される時間である。移動時間の長さは目的地がどこであるのかに依存する。

　ステップＳ２００５の処理により、いまの場合、例えば図２４に示される配送計画が作成される。図２４は、配送計画を説明する図である。最初の出発地である開始地ｓの出発時刻は14:50とされ、開始地ｓから目的地Ｇまでの移動時間は１０分なので、目的地Ｇの到着予定時刻は15:00とされている。

　目的地Ｇの出発時刻は、目的地Ｇでの受け取り時間は５分とされているので、目的地Ｇへの到着時刻15:00より５分後の15:05とされている。そして目的地Ｇから開始地ｓまでの移動時間は１０分なので、開始地ｓへの到着予定時刻（帰還時刻）は15:15とされている。

　次にステップＳ２００６において確認部１１２は、ボックス２８に余裕があるのかを確認する。ボックスの数が６個であるとすると、いまの場合、個口数は２個なので、余裕があると判断される。すべての荷物を６個のボックス２８に収容することができない場合には（ボックス２８が不足する場合には）、カート２７の数を増加する必要がある。

　ステップＳ２００７において判定部１１１は、対象とするカート２７による配送の受注を終了するか（受け付けを終了するか）を判定する。例えば、すべてのボックス２８が埋まったり、すでに受け付けられている配送をユーザ１２が希望する時間帯に配送することが、発注時刻から判断して困難になる場合、受注は終了される。

　受注がまだ終了されていない場合、処理はステップＳ２００１に戻る。ステップＳ２００１で依頼が発生していないと判定された場合にも、処理はステップＳ２００７に進み、そこで受注がまだ終了されていないと判定された場合、そこから処理はステップＳ２００１に戻る。

　発注時刻14:14に目的地ＡでID２の配送依頼が発生した場合、ステップＳ２００２において希望配送時間帯15:00－15:30が利用できるのかが確認される。単純に、すでに受け付けられている目的地Ｇの次に目的地Ａに移動するものとする。この場合、目的地Ｇから目的地Ａまでの移動時間は７分であり、図２４から明らかなように、目的地Ｇの出発時刻は15:05であるから、目的地Ａへの到着予定時刻は15:12となり、希望配送時間帯15:00－15:30は利用できると判断される。

　ステップＳ２００５の処理により、例えば図２５に示される配送計画が作成される。図２５は、配送計画を説明する図である。図２４の配送計画の目的地Ｇの次に、目的地Ａに移動し、開始地ｓに戻るルートが計画されている。

　目的地Ｇから目的地Ａまで移動時間は７分なので、目的地Ｇの出発時刻15:05から７分後の15:12が目的地Ａの到着予定時刻になる。目的地Ａでの受け取り時間も５分とされるので、目的地Ａの出発時刻は15:17とされる。目的地Ａから開始地ｓまでの移動時間は８分なので、開始地ｓへの到着予定時刻（帰還時刻）は15:25となる。

　発注時刻14:23に目的地ＩでID３の配送依頼が発生した場合、ステップＳ２００２において希望配送時間帯15:30－16:00が利用できるのかが確認される。単純に、すでに受け付けられている目的地Ｇと目的地Ａの次に目的地Ｉに移動するとする。この場合、目的地Ａから目的地Ｉへの移動時間は１２分であり、図２５から明らかなように、目的地Ａの出発時刻は15:17であるから、目的地Ｉへの到着予定時刻は15:29となり、希望配送時間帯15:30－16:00は利用できると判断される。

　ステップＳ２００５の処理により、例えば図２６に示される配送計画が作成される。図２６は、配送計画を説明する図である。図２５の配送計画の目的地Ａの次に、目的地Ｉに移動し、開始地ｓに戻るルートが計画されている。

　目的地Ａから目的地Ｉまで移動時間は１２分なので、目的地Ａの出発時刻15:17から１２分後の15:29が目的地Ｉの到着予定時刻になる。目的地Ｉでの受け取り時間も５分とされるが、希望配送時間帯は15:30－16:00なので、到着してから希望配送時間帯の開始時刻15:30までの１分間は待機する必要がある。そこで、目的地Ｉでの受け取り時間は６分（＝５分＋１分）となり、目的地Ｉの出発時刻は15:35となる。目的地Ｉから開始地ｓまでの移動時間は１１分なので、開始地ｓへの到着予定時刻(帰還時刻)は15:46となる。

　ステップＳ２００７において受け付けが終了されたと判定された場合、ステップＳ２００８において、作成部１１４は、周回時間、積み込み時間、および受け取り時間のうちの少なくとも１つに基づいて、配送計画を作成する。すなわちこれにより、複数の配送計画が比較され、その中から１つの配送計画が選択され、作成される。

　配送計画を作成する場合に各配送計画を評価するパラメータとして使用される周回時間は、荷物を積み込む積み込み地点および荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる時間であり、カート２７の使用時間を表す情報である。具体的には、カート２７が配送の開始地ｓ（積み込み地点）から各目的地（受け取り地点）を経て、最終的に帰還地（開始地ｓと同じ場所または異なる場所であってもよい）に戻るまでにかかる時間であり、開始地ｓの出発時刻と帰還地への到着予定時刻（帰還時刻）との差である。これにより、カート２７の回転率を把握することができる。周回時間が短い方が、カート２７の回転率がよく、配送効率も良いことになる。

　また、ここで配送計画を評価するパラメータとして使用される積み込み時間は、荷物の個数に応じた積み込み時間（例えば５分×４個＝２０分）に、バッファ的時間を加算した時間である。バッファ的時間は、荷物を積み込むのにかかる時間に対する余裕（カート２７への荷物の積み込みの余裕に関する積み込み余裕時間）を表す時間であり、最初の配送依頼の発注時刻から開始地ｓの出発時刻までの時間である。これにより、積み込み作業が作業者２３に与える負荷の程度を把握することができる。積み込み時間のバッファの容量は大きい方が、作業者２３に与える負荷は小さくなる。この積み込み時間のバッファの容量の値により、積み込み作業の負荷をバッファ的に調整することができる。

　さらに、配送計画を評価するパラメータとして使用される受け取り時間は、荷物の個数に応じた受け取り時間（例えば１分×５個＝５分）に、バッファ的時間を加算した時間である。バッファ的時間は、荷物の受け取りに利用することができる付加的な時間（カート２７からの荷物の受け取り待ちの余裕に関する受け取り待ち余裕時間）である。すなわちそれは、到着予定時刻より前の荷物の受け取りに利用することができる時間、具体的には、目的地への到着予定時刻からその目的地における希望配送時間帯の開始時刻までの時間である。これにより、ユーザ１２にサプライズ的に、荷物の受け取りのために余裕時間を与えることができる。これにより受け取りのための時間をバッファ的に調整することができる。

　例えばID３の配送依頼が発生した場合、次のような配送計画が考えられる。
　（１）図２５に示されるように、開始地ｓ－目的地Ｇ－目的地Ａ－開始地ｓのルートで移動したカート２７が、時刻15:25に開始地ｓに戻ってきた後、そのカート２７にID３の配送依頼の荷物を積み込むことができる。１個口なので積み込み時間は５分となり、時刻15:30を出発時刻とすることができる。
　（２）配送ルートとして、開始地ｓ－目的地Ｇ－目的地Ａ－目的地I－開始地ｓのルートとは、目的地の順番が異なる別のルートを考えることができる。
　（３）他のカート２７で開始地ｓ－目的地I－開始地ｓのルートを考えることができる。

　配送全体の最適化の見地から、例えば上記（２）の目的地の順番が異なるルート（開始地ｓ－目的地Ｇ－目的地Ａ－目的地I－開始地ｓとは異なる順番のルート）の配送計画を作成するものとする。

　例えば、図２７に示されるように、開始地ｓ－目的地Ａ－目的地Ｇ－目的地I－開始地ｓの順番のルートを考えることができる。図２７は、配送計画を説明する図である。

　図２７の例においては、最初の目的地Ａに、希望配送時間帯15:00－15:30の開始時刻15:00に到着すればよい。従って、開始地ｓから目的地Ａまでの移動時間は８分なので、開始地ｓの出発時刻は、希望配送時間帯の開始時刻15:00より８分前の時刻14:52となる。そして目的地Ａへの到着予定時刻は15:00となる。受け取り時間は５分とされているので、目的地Ａの出発時刻は15:05となる。

　目的地Ａから目的地Ｇまでの移動時間は７分なので、目的地Ｇへの到着予定時刻は15:12となる。目的地Ｇの出発時刻は、目的地Ｇでの受け取り時間は５分とされているので、目的地Ｇへの到着時刻15:12より５分後の時刻15:17とされている。

　目的地Ｇから目的地Ｉまで移動時間は８分なので、目的地Ｇの出発時刻15:17から８分後の時刻15:25が目的地Ｉの到着予定時刻になる。目的地Ｉでの受け取り時間も５分とされるが、希望配送時間帯は15:30－16:00なので、到着してから希望配送時間帯の開始時刻15:30までの５分間は待機する必要がある。そこで、目的地Ｉでの受け取り時間は１０分（＝５分＋５分）となり、目的地Ｉの出発時刻は15:35となる。目的地Ｉから開始地ｓまでの移動時間は１１分なので、開始地ｓへの到着予定時刻は15:46となる。

　また、図２８に示されるように、開始地ｓ－目的地Ｇ－目的地Ｉ－目的地Ａ－開始地ｓの順番のルートを考えることができる。図２８は、配送計画を説明する図である。

　図２８の例においては、最初の目的地Ｇに、希望配送時間帯15:00－15:30の開始時刻15:00に到着すればよい。従って、開始地ｓから目的地Ｇまでの移動時間は１０分なので、開始地ｓの出発時刻は、希望配送時間帯の開始時刻15:00より１０分前の時刻14:50となる。そして目的地Ｇへの到着予定時刻は15:00となる。受け取り時間は５分とされているので、目的地Ｇの出発時刻は15:05となる。

　目的地Ｇから目的地Ｉまでの移動時間は８分なので、目的地Ｉへの到着予定時刻は15:13となる。目的地Ｉでの受け取り時間は５分とされているが、目的地Ｉでの希望配送時間帯は15:30－16:00なので、到着予定時刻15:13から、望配送時間帯の開始時刻15:30までの１７分間も待機する必要がある。従って待機時間は合計２２分（＝５分＋１７分）となる。その結果、目的地Ｉの出発時刻は、目的地Ｉへの到着時刻15:13より２２分後の時刻15:35とされている。

　目的地Iから目的地Ａまで移動時間は１２分なので、目的地Ｉの出発時刻15:35から１２分後の時刻15:47が目的地Ａの到着予定時刻になる。しかし、目的地Ａでの希望配送時間帯は15:00-15:30であるから、到着予定時刻が希望配送時間帯を過ぎてしまっている。従って、このルートは採用することができない。

　また、図２９に示されるように、開始地ｓ－目的地Ａ－目的地Ｉ－目的地Ｇ－開始地ｓの順番のルートを考えることができる。図２９は、配送計画を説明する図である。

　図２９の例においては、最初の目的地Ａに、希望配送時間帯15:00－15:30の開始時刻15:00に到着すればよい。従って、開始地ｓから目的地Ａまでの移動時間は８分なので、開始地ｓの出発時刻は、希望配送時間帯の開始時刻15:00より８分前の時刻14:52となる。そして目的地Ａへの到着予定時刻は15:00となる。受け取り時間は５分とされているので、目的地Ａの出発時刻は15:05となる。

　目的地Ａから目的地Ｉまでの移動時間は１２分なので、目的地Ｉへの到着予定時刻は15:17となる。目的地Ｉでの受け取り時間は５分とされているが、目的地Ｉでの希望配送時間帯は15:30－16:00なので、到着予定時刻15:17から、望配送時間帯の開始時刻15:30までの１３分間も待機する必要がある。従って待機時間は合計１８分（＝５分＋１３分）となる。その結果、目的地Ｉの出発時刻は、目的地Ｉへの到着予定時刻15:17より１８分後の時刻15:35とされている。

　目的地Iから目的地Ｇまで移動時間は８分なので、目的地Ｉの出発時刻15:35から８分後の時刻15:43が目的地Ｇへの到着予定時刻になる。しかし、目的地Ｇでの希望配送時間帯は15:00-15:30であるから、到着予定時刻が希望配送時間帯を過ぎてしまっている。従って、このルートは採用することができない。

　図２６の開始地ｓ－目的地Ｇ－目的地Ａ－目的地I－開始地ｓのルートの場合、ID３の配送依頼の発注時刻は14:23であり、開始地ｓの出発時刻は14:50となるから、積み込み時間のバッファの容量は２７分（＝14:50-14:23）となる。

　これに対して図２７の開始地ｓ－目的地Ａ－目的地Ｇ－目的地I－開始地ｓのルートの場合、ID３の配送依頼の発注時刻は14:23であり、開始地ｓの出発時刻は14:52となるから、積み込み時間のバッファの容量は２９分（＝14:52-14:23）となる。

　このように、積み込み時間のバッファの容量は図２６の例の場合（２７分）より図２７の例の場合（２９分）の方が大きい。積み込み時間のバッファの容量は、積み込みに対する時間的な余裕を表すので、その値は大きい方が好ましい。

　また図２６の例の場合、目的地Ａにおける受け取り時間のバッファの容量が１分であるのに対して、図２７の例の場合、目的地Ｇにおける受け取り時間のバッファの容量は５分である。受け取り時間のバッファの容量は、荷物の受け取りの時間的余裕を表すので、その値は大きい方が好ましい。ただしあまり大き過ぎると、カート２７が必要以上に長時間停止していることになり、無駄である。

　図２６のルートの場合、開始地ｓの出発時刻は14:50であり、帰還時刻は15:46であり、周回時間は５６分（＝15:46-14:50）となる。一方、図２７のルートの場合、開始地ｓの出発時刻は14:52であり、帰還時刻は15:46であり、周回時間は５４分（＝15:46-14:52）となる。

　周回時間はカート２７を走行させる時間なので、その値が小さい方が好ましい。

　以上のことから、作成部１１４は、図２６乃至図２９に示されるルートのうち、図２７に示されるルートが最適であるとして、採用、決定し、配送計画を作成することができる。

　なお、以上においては、積み込み時間、受け取り時間、および周回時間のすべてを考慮したが、必ずしも全部を考慮する必要はなく、少なくとも１つを考慮するようにすることができる。これらの要素は、必要に応じて重み付けすることができる。これにより、最適化された配送を実現することができる。また、効率よく配送ができるようになる。

　結局、本実施の形態においては、次のようなパラメータに基づいて配送が計画されることになる。すなわち、希望配送時間帯、到着予定時刻、発注時刻、カートの数、積み込み時間、受け取り時間、目的地の数、目的地までの移動時間、ボックスの容量、周回時間、積み込み時間のバッファの容量、受け取り時間のバッファの容量である。

　以上のようにして配送計画が作成される。作業者２３（タブレット２２）に対する積み込み指示は、１つのカート２７に対する配送ルートが確定してから行われる。つまり、配送の依頼が発生する度に積み込み指示が行われるのではない。それにより、カート２７を無駄に移動させたり、荷物を積み戻すような作業の発生が抑制される。

　ユーザ１２に希望配送時間帯の利用の可否を通知するのもルートが確定してから行われる。徐々にアップデートしていく方式にすると、何度もアップデートが必要になり、その都度、利用可能な時間帯が早くなったり遅くなったりするのは好ましくない。ユーザ１２から希望配送時間帯を受け取って、後で、「配送時間が決定しました」のような通知をするのが好ましい。

　なお、この他、荷物の個数や重さを配送計画作成のパラメータとすることもできる。

　以上のような、配送計画を作成した後、インシデントが発生した場合、配送計画を再計画することができる。

　起きるインシデントとしては、上述したように、個配送がなくなる(事前キャンセル)、ユーザ１２の待ち時間を０にする(事後キャンセル)、ユーザ１２が来ない(timeout)等がある。

　再計画のパターンとしては、次のようなものが考えられる。
　　・配送計画ごと再度作成し直す。
　　　　今の状態で再度計算するが、リソース、荷物の状態、および時間は確実に確認する必要がある。
　　・配送計画はそのままで、個配送の待ち時間を0にして次に行く。時間は再計算する。
　　・配送計画はそのままで、個配送をスキップし、次の個配送のスタート地点を書き換える。時間は再計算する。
　　・送計画はそのままで、個配送の時間を再計算する。
　　・配送計画自体、異常状態（emergency）にする。
　　　　どこまで終わっているのかは確認できるようにして、配送計画をemergencyにして、完了していない個配送もemergencyとする。

＜利用可能時間帯検索処理（図３０乃至図３５）＞
　次に、図２２のステップＳ２００２において説明した、希望配送時間帯の利用可能性を確認する処理の詳細について、利用可能時間帯検索処理として、図３０乃至図３５を参照して説明する。

　利用可能時間帯検索処理を行うために、配送管理システム４１は図３０に示される機能的構成を有している。図３０は、配送管理システムの構成例を示すブロック図である。

　配送管理システム４１は、判定部１６１、確認部１６２、および表示部１６３を有している。

　判定部１６１は、再配送であるか等を判定する。確認部１６２は、帰還時刻、利用可能時間帯等を確認する。表示部１６３は、受け付け可能な時間帯等を表示する。

　次に、図３１を参照して利用時間帯検索処理について説明する。図３１は、利用時間帯検索処理を説明するフローチャートである。

　ステップＳ２０２１において判定部１６１は、荷物の配送は再配送であるかを判定する。再配送である場合、ステップＳ２０２２において確認部１６２は、荷物の帰還時刻を確認する。すなわち、再配送である場合、すでに荷物が配送されているので、荷物が開始地ｓに戻ってくる帰還時刻が確認される。この帰還時刻は予定時刻である。

　図３２と図３３は、いずれも配送状態を説明する図である。いま配送状態はこの図３２に示されるようであるとする。この図３２は、基本的に図２３と同じ図であり、１０個の配送先Ａ乃至配送先Ｊのうちの３つの配送先Ｇ，Ａ，Ｉに、荷物を配送することが依頼されている。そしていま１台のカート２７Ａが現に配送中である。再配送が指定された荷物がカート２７Ａに積み込まれている場合、このカート２７Ａの帰還時刻が確認される。

　ステップＳ２０２１の判定処理において再配送ではないと判定された場合、またはステップＳ２０２２において帰還時刻の確認が行われた場合、次に、ステップＳ２０２３において確認部１６２は、利用可能時間帯を確認する。

　例えば時刻15:20にユーザ１２から配送が要求された場合、発注時刻15:20に所定の時間Ａが加算される。時間Ａは荷物をボックス２８に積み込むのに必要な時間である。上述したようにこの時間Ａは３０分とすることができる。この場合、発注時刻に３０分を加算した時刻は15:50となる。従って、ユーザ１２は、16:00-16:30以降の時間帯を指定可能となる。もちろん実際には、さらに目的地までの移動時間が加算された時間帯が利用可能時間帯となる。

　再配送の場合には、帰還時刻に積み込み時間を加算した時刻より後の時間帯が利用可能時間帯となる。

　ステップＳ２０２４において確認部１６２は、各時間帯の配送中の配送計画を確認する。例えば図３３に示されるように、カート２７Ａがその配送計画に基づく配送に利用されており、カート２７Ｂとカート２７Ｃは利用されていないとすると、カート２７Ｂまたはカート２７Ｃを利用対象として選択することができる。

　ステップＳ２０２５において確認部１６２は、各時間帯の計画中の配送計画を確認する。例えばカート２７Ｂにすでにいくつかの荷物の配送が計画中である場合、さらにそこに別の荷物を追加して配送することができるのかが確認される。必ずしもボックス２８を満杯にする必要はないが、半分以上は積み込むようにするのが好ましい。

　ステップＳ２０２６において表示部１６３は、受け付け可能な時間帯を表示する。すなわち、ユーザ１２より指定された時間帯のうち、利用可能な時間帯がユーザ１２（スマートフォン１１）に表示される。

　図３４と図３５は、利用時間帯検索を説明する図である。図３４に示されるように、利用可能時間帯ロジックだけでは利用可能時間帯を決定することができず、配送計画ロジックと共同して利用時間帯が検索される。実質的に、図２２の配送計画作成処理のフローチャートのステップＳ２００２の処理に、図３１の利用可能性時間帯検索処理が対応している理由もそこにある。利用可能時間帯ロジックは、荷物やカート２７のリソースを確認するが、配送計画ロジックが管理する配送計画も確認する必要がある。

　図３５に示されるように、ユーザ１２の選択に基づき配送計画ロジックにより計画された配送計画のフィードバックを受けて利用可能時間帯ロジックが利用可能時間帯を検索し、表示画面を生成する。図３５の例では、15:00-15:30の時間帯は利用不可とされ、15:30-16:00と16:30-17:00の時間帯は利用可能とされている。そして16:00-16:30の時間帯は、まだ余裕があるが、あまり多くは配送できないことが表示されている。ユーザ１２はこの表示から希望する時間帯をさらに選択することができる。

　再配達の場合には、商品があるのかが確認される。すなわち荷物が帰ってくる時刻が確認され、その後の時間帯から計算が行われる。帰ってくる予定時刻が15:46ならば、16:30-17:00の時間帯から指定可能にして、荷受けと同じロジックが適用される。

　配送可能時間帯を動的に計算することができる。すなわち、現在状況（計画状況、リソース状況、依頼状況）から空きの希望配送時間帯の計算を行い、現在状況を鑑みて、利用可能時間帯の幅を動的に変更することができる。例えば、ユーザ１２の希望を満たせるように、時間帯を３０分よりだんだんと広くすることができる。

＜ユーザインターフェース（図３６乃至図４９）＞
　次に、図３６乃至図４９を参照して、ユーザインターフェースの例について説明する。

　図３６と図３７は、購入サイトのユーザインターフェースを示す図である。図３６は、購入サイト１４の商品２５を選択する画面の例を表している。商品２５としてトマトが表示されており、ユーザ１２はそのいずれかを購入対象として選択することができる。

　図３７は、購入サイト１４のカート内容を確認する画面の例を表している。すなわち、購入した商品２５（図３７の例の場合トマト）が表示され、ユーザ１２は購入内容を確認することができる。

　図３８乃至図４３は、配送サイトのユーザインターフェースを示す図である。図３８乃至図４０は、状況確認のための画面の例を表している。図３８は、荷物情報を確認するための画面であり、「お問い合わせID」の他、「配送点数」、「ステータス」、「到着予定時刻」、「希望時間帯」、「希望配送場所」等が表示されている。

　図３９は、位置情報を確認するための画面であり、カート２７の現在位置が地図上に表示されている。図４０は、配送状況を確認するための画面であり、「お問い合わせID」の他、注文を受け付けた時刻、積み込みを完了した時刻、出発時刻、到着までの時間、到着時刻等が表示されている。

　図４１と図４２は、配送変更のための画面の例を表している。図４１は、配送時間を変更するための画面の例を表しており、希望配送時間、希望配送場所、配送オプション、内容の確認等の情報が表示されている。図４２は、配送時間変更が完了したときの画面の例を表しており、配送リクエストID、商品数、希望配送時間帯、希望配送場所、配送オプション等の情報が表示されている。図４３は、確認メールの画面の例を表しており、注文内容が表示されている。

　図４４と図４５は、作業者サイトのユーザインターフェースを示す図である。図４４は、作業者サイト２１の積み込み依頼の一覧を表している。カート２７の番号とボックス２８の番号、そこに商品２５を積み込むべき日時が、一覧として表示されている。この画面から所定のカート２７の番号とボックス２８の番号を選択すると、図４５に示されるように、その詳細な情報が表示される。

　図４６と図４７は、管理サイトのユーザインターフェースを示す図である。図４６には、パッケージ一覧、積み込み一覧、カート一覧が表示されている。パッケージ一覧には、パッケージID、ステータス、目的地、希望時間帯、予定時刻、カートID、ボックスID、商品（アイテム）、ユーザキーが表示されている。積み込み一覧には、積み込みID、ステータス、カートID、ボックスID、積み込み終了時刻、パッケージID、目的地、希望時間帯、予定時刻、アイテム種類数が表示されている。カート一覧には、各カートの、カートID、システムステータス、カートステータス、位置、ボックス０乃至ボックス５の商品、扉、ロックの状態が、それぞれ表示されている。

　図４６のカート一覧から所定のカート２７を選択すると、図４７に示されるように、そのカート２７に関する情報を表す画面が表示される。カート２７の地図上の現在位置、カメラ３０で撮影したカート２７の前後左右の画像の他、カート状況とボックス状況が表示される。カート状況としては、カートID、エリアID、周辺状態監視状況、カート状態、システム状態、カート警告音、現在地、速度、充電状況、カメラステータス、タイムスタンプ等が表示される。

　ボックス状況としては、各ボックスの扉、ロック状態、商品のパッケージ情報が表示されている。パッケージ情報としては、パッケージID、パッケージステータス、キャンセル、目的地、到着予定時刻等が表示される。

　図４８と図４９は、キーアプリケーションのユーザインターフェースを示す図である。これらの画面は、スマートフォン１１の表示画面の例を表している。図４８は扉を開ける前（錠のロックを解除する前）の画面を表しており、「荷物を受け取る時はこの画面をリーダーにかざしてください。」のメッセージとロックされた状態の錠の画像、並びにキーIDが表示されている。図４９は扉を開けた後（錠のロックを解除した後）の画面を表しており、「荷物を取り出して扉を閉めてください。」のメッセージとロックが解除された状態の錠の画像、並びにキーIDが表示されている。

＜変形例＞
　なお、本技術においては次のような変形例が考えられる。

　・需要発生からの逆推定
　　　これまでの需要の内容を学習し、別の場所で発生した依頼から、世帯人数や年齢、性別、家族構成を推定することができる。
　　　購入サイト１４にフィードバックして広告や「おすすめ」に使用することができる。
　・屋内での適用
　　　依頼の指定方法に階数を追加し、エレベータなどの運行状況も連携して予測する。
　・旅客への適用
　　　モノを運ぶことと違いはあまりない。
　　　乗り合わせのユースケースは違う。途中でのピックアップや、途中での下車にも対応をする。
　・帰りの荷物を積む
　　　１か所の積載基地に限らず、別に複数の積載基地がある場合にも対応する。動的に配送を計画する。
　・ユースケースが違う場合
　　　ランドリー返却、レンタル品の返却
　　　　レンタル品や、クリーニング品を届けて、その後回収する。回収だけであれば、始め「空」でも移動するように適用することができる。
　・自動販売機
　　　冷却時間等の検討、在庫補充のタイミング予測に適用することができる。
　・携帯電話機等の充電ステーション
　　　充電用電池残量の予測、充電用電池、携帯電話機、携帯用音楽プレーヤ、タブレット、パーソナルコンピュータの充電のタイミング予測。

　なお本技術は、その本質を逸脱しない範囲において、種々の変形例が存在しうる。

＜コンピュータ（図５０）＞

　上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、例えば、各装置は、図５０に示されるようなパーソナルコンピュータにより構成される。図５０は、パーソナルコンピュータの構成例を示すブロック図である。

　図５０において、CPU（Central　Processing　Unit）９２１は、ROM（Read　Only　Memory）９２２に記憶されているプログラム、または記憶部９２８からRAM（Random　Access　Memory）９２３にロードされたプログラムに従って各種の処理を実行する。RAM９２３にはまた、CPU９２１が各種の処理を実行する上において必要なデータなども適宜記憶される。

　CPU９２１、ROM９２２、およびRAM９２３は、バス９２４を介して相互に接続されている。このバス９２４にはまた、入出力インタフェース９２５も接続されている。

　入出力インタフェース９２５には、キーボード、マウスなどよりなる入力部９２６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部９２７、ハードディスクなどより構成される記憶部９２８、モデム、ターミナルアダプタなどより構成される通信部９２９が接続されている。通信部９２９は、ネットワークを介しての通信処理を行う。

　入出力インタフェース９２５にはまた、必要に応じてドライブ９３０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア９３１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部９２８にインストールされる。

　なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

　また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

　また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

＜その他＞
　本技術は、以下のような構成もとることができる。
　（１）
　移動体による荷物の配送を管理する配送管理装置において、
　前記移動体への前記荷物の積み込みにかかる積み込み時間および前記移動体からの前記荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、前記荷物を積み込む積み込み地点および前記荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、前記移動体の配送計画を作成する作成部
　を備える配送管理装置。
　（２）
　前記積み込み時間は、最初の配送依頼の発注時刻から前記積み込み地点の出発時刻までの時間であり、前記受け取り時間は、前記移動体の前記受け取り地点への到着予定時刻から希望配送時間帯の開始時刻までの時間である
　前記（１）に記載の配送管理装置。
　（３）
　さらに前記受け取り地点の数および前記到着予定時刻に基づいて前記配送計画が作成される
　前記（１）または（２）に記載の配送管理装置。
　（４）
　さらに前記移動体の数に基づいて前記配送計画が作成される
　前記（１）乃至（３）のいずれかに記載の配送管理装置。
　（５）
　前記積み込み時間と前記受け取り時間の両方に基づいて前記配送計画が作成される
　前記（１）乃至（４）のいずれかに記載の配送管理装置。
　（６）
　積み込まれた荷物を配送する移動体と、
　前記移動体への前記荷物の積み込みにかかる積み込み時間および前記移動体からの前記荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、前記荷物を積み込む積み込み地点および前記荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、前記移動体の配送計画を作成するサーバーと
　を備える荷物配送システム。
　（７）
　コンピュータに、積み込まれた荷物を配送する移動体の配送計画を作成する処理を実行させるプログラムにおいて、
　前記移動体への前記荷物の積み込みにかかる積み込み時間および前記移動体からの前記荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、前記荷物を積み込む積み込み地点および前記荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、前記移動体の配送計画を作成するステップ
　を含むプログラム。

　１２　ユーザ，　１７　サーバー管理システム，　２５　商品，　２６　パッケージ，　２７　カート，　２８　ボックス，　４１　配送管理システム，　４４　カート管理システム，　１１１　判定部，　１１２　確認部，　１１３　予測部，　１１４　作成部，　１６１　判定部，　１６２　確認部，　１６３　表示部

Claims

　移動体による荷物の配送を管理する配送管理装置において、
　前記移動体への前記荷物の積み込みにかかる積み込み時間および前記移動体からの前記荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、前記荷物を積み込む積み込み地点および前記荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、前記移動体の配送計画を作成する作成部
　を備える配送管理装置。
　前記積み込み時間は、最初の配送依頼の発注時刻から前記積み込み地点の出発時刻までの時間であり、前記受け取り時間は、前記移動体の前記受け取り地点への到着予定時刻から希望配送時間帯の開始時刻までの時間である
　請求項１に記載の配送管理装置。
　さらに前記受け取り地点の数および前記到着予定時刻に基づいて前記配送計画が作成される
　請求項２に記載の配送管理装置。
　さらに前記移動体の数に基づいて前記配送計画が作成される
　請求項１に記載の配送管理装置。
　前記積み込み時間と前記受け取り時間の両方に基づいて前記配送計画が作成される
　請求項１に記載の配送管理装置。
　積み込まれた荷物を配送する移動体と、
　前記移動体への前記荷物の積み込みにかかる積み込み時間および前記移動体からの前記荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、前記荷物を積み込む積み込み地点および前記荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、前記移動体の配送計画を作成するサーバーと
　を備える荷物配送システム。
　コンピュータに、積み込まれた荷物を配送する移動体の配送計画を作成する処理を実行させるプログラムにおいて、
　前記移動体への前記荷物の積み込みにかかる積み込み時間および前記移動体からの前記荷物の受け取りにかかる受け取り時間のうちの少なくとも一方と、前記荷物を積み込む積み込み地点および前記荷物を受け取る受け取り地点のうちの少なくとも２つの地点の経由にかかる周回時間とに基づいて、前記移動体の配送計画を作成するステップ
　を含むプログラム。