JP7732111B2 - 配送料金算出装置 - Google Patents

Description

本発明は、配送料金を算出する配送料金算出装置に関する。

下記特許文献１、２に記載されているように、配送経路を考慮して配送料金を決定するシステムが知られている。

特許第４４９１２６５号公報 特開２０１１－１０８０９０号公報

しかしながら、従来は、配送先の住所に到達してから荷渡しが完了するまでの間に生じる配送側の作業量を示す配送先敷地内作業量が考慮されておらず、配送側の負担が大きいといった問題があった。つまり、配送先敷地内作業としては、配送先の敷地内に入場するためのゲートの通過、ゲートから配送先まで徒歩や階段、エレベータなどでの移動、配送先の部署に入場するための受付の通過、受付を通過してから配送先の部署や担当者に実際に荷渡しをするための移動や待機、などが挙げられるが、従来はこのような作業については料金が請求できずに配送側の負担となっていた。

上述した問題に対して、配送側が、配送先敷地内作業量を考慮した配送料金を設定するといった方法も考えられる。しかしこの場合、配送料金が適正であるか否かを確認する機会が配送料金の請求先に無いため、配送料金が不当に高額に設定され、配送料金の請求先が不利益を被ってしまうといった問題がある。

本発明は、上記背景を鑑みてなされたものであり、配送側の負担を軽減しながら配送料金の請求先の不利益も防止できる、配送料金算出装置を提供することを目的としている。

上記課題を解決するために、本発明の配送料金算出装置は、プロセッサを備え、プロセッサは、配送先の住所に到達してから荷渡しが完了するまでの間に生じる配送側の作業量を示す配送先敷地内作業量の入力を受け付け、配送先敷地内作業量を用いて配送料金を算出し、過去の配送実績として、配送先と配送先敷地内作業量との対応関係を記憶し、新規の配送依頼を受け付けた場合に、対応関係を用いて配送料金を予測し、予測した配送料金と、配送依頼の達成後に算出した配送料金とを比較し、比較結果を配送料金の請求先に通知する。

プロセッサは、比較結果が所定の許容範囲外であった場合に、通知を行う、ことが好ましい。

プロセッサは、比較結果が許容範囲外であった場合に、配送依頼の達成後に算出した配送料金の承認を、請求先に要求する、ことが好ましい。

プロセッサは、比較結果が許容範囲外であった場合に、この原因が配送先と配送側とのいずれに起因するかを判定する、ことが好ましい。

プロセッサは、配送先敷地内作業量の決定根拠となる敷地内作業情報の入力を受け付け、敷地内作業情報を提示して承認を要求し、承認の要求が認められた場合に原因が配送先に起因すると判定し、承認の要求が認められなかった場合に原因が配送側に起因すると判定する、ことが好ましい。

プロセッサは、判定の結果、比較結果が許容範囲外であった場合の回数、頻度、の少なくともいずれかを用いて、配送側の信頼度を評価する、ことが好ましい。

プロセッサは、配送側の信頼度に基づいて許容範囲の大きさを画定する、ことが好ましい。

プロセッサは、配送に関する処理の履歴をブロックチェーン上に格納する、ことが好ましい。

本発明によれば、配送側の負担を軽減しながら配送料金の請求先の不利益も防止できる。

配送支援システムの構成を示す概略図である。 プロセッサの構成を示す説明図である。 換算表の説明図である。 第1実施形態の処理の流れを示すフローチャートである。 第２実施形態の処理の流れを示すフローチャートである。 プロセッサの構成を示す説明図である。 第３実施形態の処理の流れを示すフローチャートである。 プロセッサの構成を示す説明図である。 第４実施形態の処理の流れを示すフローチャートである。 配送実績をブロックチェーン上に格納する構成の説明図である。 第５実施形態の処理の流れを示すフローチャートである。

［第１実施形態］
図１に、本発明のプロセッサ１０（配送料金算出装置）を備えた配送支援システム１２を示す。配送支援システム１２は、荷物の配送を支援するものである。荷物は、配送業者１４（配送側）により配送される。配送業者１４は、荷主１６または配送先１８から依頼されて、荷主１６から配送先１８へと荷物を配送する。なお、本実施形態において、配送先１８は、配送先企業２０の敷地２２内に存在するビル（６階）である。

プロセッサ１０は、配送支援プログラムを実行するものであり、配送支援プログラムの実行に伴って、各種機能を実現させる。配送支援プログラムは、配送の依頼を行う際に、依頼元の端末（荷主１６の端末２４、または、配送先１８の端末２６）において、例えば、配送依頼用のアプリケーションソフトウェアを立ち上げることによって実行される。

なお、プロセッサ１０は、端末２４、端末２６、並びに、配送業者の端末２８とは別体に設けられた専用の端末など、１つの端末そのもの（または、このような１つの端末の一部）であってもよいが、本発明は、このように１つの端末（端末そのもの、または、その一部）からプロセッサ１０を構成する例に限定されるものではない。このような端末（端末そのもの、または、その一部）が複数集まり、これらが協働してプロセッサ１０として機能する構成としてもよい。

配送支援プログラムが実行されると、配送条件の指定、配送業者の選択などを経て、新規の配送依頼を立ち上げることができる。配送条件は、配送料金請求先、荷物の態様（重さ、種類、数など）、納品の態様（納品場所、納品時間など）、詳細条件（駐車場の有無や指定、荷さばきの有無や指定、搬入ルートの詳細など）、である。配送条件を指定することで、指定された配送条件での配送が可能な配送業者１４の候補が抽出され、抽出された候補の中から配送依頼を行う配送業者を選択できる。配送業者が選択（例えば、配送業者１４が選択）されると、選択された配送業者１４の端末２８に依頼が送信され、配送業者１４の端末２８において依頼が受任されると、配送依頼の立ち上げが完了する。そして、この配送依頼に従って、荷物の配送が行われる。

また、配送支援プログラムが実行されると、図２に示すように、プロセッサ１０は、受付部３０、算出部３２、記憶部３４、予測部３６、比較部３８、通知部４０、として機能する。

受付部３０は、配送先敷地内作業量の入力を受け付ける。配送先敷地内作業量は、配送先１８の住所（配送先企業２０の敷地２２の住所）に到達してから配送先１８への配送（荷渡し）が完了するまでの間に配送側（配送業者１４）に生じる作業の量（作業量）を示すものである。受付部３０は、この配送先敷地内作業量を決定する根拠となる敷地内作業情報の入力を受け付ける。敷地内作業情報は、例えば、敷地内に入場するためのゲートの有無、ゲートの通過に必要な処理の種類や所要時間、ゲートを通過してから配送先１８までの距離や所要時間、ゲートと配送先の階層差やエレベータの有無、配送先１８での荷渡しに必要な処理の種類や所要時間、などである。

敷地内作業情報の入力は、例えば、質問形式で行われる。具体的には、配送が完了すると、配送業者１４は、端末２８を介して依頼完了の報告をプロセッサ１０に対して行う。この報告を受け、受付部３０が、例えば、「敷地内へのゲートの有無は？」、「ゲートから配送先への距離は？」などといった質問を端末２８に対して送信する。そして、この質問への回答が、敷地内作業情報として入力される。もちろん、これ以外の形式で敷地内作業情報を入力する構成としてもよい。この場合、例えば、依頼の完了後に、配送業者１４の端末２８から、所定のフォーマットに従って敷地内作業情報を入力し、依頼の完了報告とともに、敷地内作業情報が受付部３０に入力される構成とする、などが考えられる。

算出部３２は、配送条件及び配送先敷地内作業量を用いて配送料金の算出を行う。具体的には、算出部３２は、配送業者１４の端末２８から配送依頼の完了の報告を受けると、この依頼の配送条件を参照し、荷主１６の住所や配送先１８の住所などに基づいて、荷主１６から配送先１８の住所までの配送料金（基本配送料金）を算出する。また、算出部３２は、敷地内作業情報に基づいて配送先敷地内作業量を決定し、決定した配送先敷地内作業量に基づいて加算額を算出する。そして、基本配送料金に加算額を加算することによって、依頼元（配送料金の請求先）に請求する最終的な配送料金を算出する。

記憶部３４には、基本配送料金に加算する加算額を算出する際に用いられる換算表４２が格納されている。図３に示すように、換算表４２は、敷地内作業情報の各々と配送先敷地内作業量への加算値との対応関係を示すものであり、算出部３２は、各敷地内作業情報を換算表４２に照合することにより、敷地内作業情報の各々について対応する配送先敷地内作業量を求め、これらを合計したものを最終的な配送先敷地内作業量とする。配送先敷地内作業量は、本実施形態では、加算額と等価な値が設定されており、前述のようにして得られた最終的な配送先敷地内作業量の値が加算額として算出される。

例えば、ゲート対応有り（ゲートでの身分証の提示や通過目的の記入（入力）など）、ゲートから配送先までの距離１００ｍ以上、ゲートから配送先までの階層差３層以上（エレベータ有り）の場合、配送先敷地内作業量（加算額（円））は、ゲート対応有りにより「５０（円）」、配送先までの距離により「５０（円）」、階層差（エレベータ有り）により「５０（円）」、合計「１５０（円）」となる。そして、この例の場合、基本配送料金に加算額１５０円を加えた金額が、最終的な配送料金として請求先に対して請求される。

図２に戻り、上述のように配送先１８へ配送を行った配送実績は、実績データ４４として記憶部３４に記憶される。実績データ４４には、荷主１６の識別情報、配送先１８の識別情報、配送業者１４の識別情報、荷物の種類、配送条件、基本配送料金や加算額、加算額の根拠となる配送先敷地内作業量や敷地内作業情報、が含まれる。なお、配送に用いられる車両に搭載したドライブレコーダの映像や移動軌跡、荷物に装着されたＩＣタグから得られた移動軌跡などの情報が実績データ４４に含まれる構成としてもよい。

予測部３６は、今回の配送料金を、過去の実績データ４４に基づいて算出する。すなわち、今回の配送実績が実績データ４４として記憶される前の実績データ４４を用いて、今回の配送料金を予測する。予測部３６は、算出部３２が配送料金を算出する手法と同様の手法を用いて配送料金を予測する。すなわち、配送条件を参照して荷主１６から配送先１８の住所までの配送料金（基本配送料金）を算出する。また、実績データ４４を参照し、過去の配送における敷地内作業情報に基づいて配送先敷地内作業量（加算額）を決定する。そして、基本配送料金に加算額を加えた配送料金を、今回の配送料金として予測する。

比較部３８は、算出部３２が算出した配送料金と、予測部３６が予測した配送料金とを比較する。通知部４０は、比較部３８による比較結果（算出部３２が算出した配送料金、及び、予測部３６が予測した配送料金の２種類の配送料金）、配送料金の請求先（請求先の端末）に通知する。

以下、図４を用いて、プロセッサ１０による処理の流れを説明する。図４に示すように、配送が完了すると配送先敷地内作業量の入力が行われ、配送先敷地内作業量が入力されると、算出部３２が、今回の配送実績に基づいて配送料金を算出する。また、予測部３６が、過去の配送実績に基づいて配送料金を予測する。次に、２つの配送料金（算出部３２が算出した配送料金と予測部３６が予測した配送料金）が比較され、比較結果が配送料金の請求先に通知される。

このように、本発明の第１実施形態によれば、配送先敷地内作業量を考慮して配送料金を決定するので、配送側の負担を軽減できる。また。今回の配送料金（算出部３２が算出した配送料金）と、過去の実績から予測した配送料金（予測部３６が予測した配送料金）との比較結果を、配送料金の請求先に通知するため、配送料金の請求先において配送料金の比較結果を確認することができ、不当に高額な配送料金が設定されるなどの不利益も防止できる。

［第２実施形態］
第１実施形態では、比較部３８による比較結果（算出部３２が算出した配送料金と予測部３６が予測した配送料金との比較結果）によらず比較結果を通知する構成を例に説明をしたが、第２実施形態では、図５に示すように、比較部３８による比較結果が許容範囲外であった場合に通知を行う。具体的には、２つの配送料金（算出部３２が算出した配送料金と、予測部３６が予測した配送料金）の違いが、許容範囲外（例えば、差額が１０００円以上、または、一方の配送料金が他方の１．５倍以上など）であった場合に、通知部４０がこの旨を通知する。

これにより、第２実施形態によれば、２つの配送料金の違いが許容範囲内であり、不当に高額な配送料金が設定されているなどの不利益が無いとみなせるにも関わらず、２つの配送料金を確認する手間がかかってしまうといった問題や、同様の金額の２つの配送料金が通知されることにより混乱してしまうなどの問題を防止できる。なお、第２実施形態以降の説明では、前述した部材と同様の部材については同様の符号を付して説明を省略している。

［第３実施形態］
図６に示すように、第３実施形態では、プロセッサ１０が、前述した受付部３０、算出部３２、記憶部３４、予測部３６、比較部３８、通知部４０、に加えて、承認要求部５０、として機能する。図７に示すように、承認要求部５０は、通知部４０の通知と同期して、今回の配送料金（算出部３２が算出した配送料金）についての承認を、配送料金の請求先（請求先の端末）に対して要求する。この後、請求先において配送料金が承認されると、配送料金が確定となり、請求先への請求が行われる。

このように、第３実施形態では、今回の配送料金について承認を求めるようにしたので、配送料金の請求先の不利益をより確実に防止できる。なお、第３実施形態においても、前述した第２実施形態と同様に、算出部３２が算出した配送料金と、予測部３６が予測した配送料金の違いが許容範囲外であった場合にのみ、比較結果の通知を行う構成としてもよい。また、算出部３２が算出した配送料金と、予測部３６が予測した配送料金の違いが許容範囲外であった場合にのみ、配送料金の承認を要求する構成としてもよい。

［第４実施形態］
図８に示すように、第３実施形態では、プロセッサ１０が、前述した受付部３０、算出部３２、記憶部３４、予測部３６、比較部３８、通知部４０、承認要求部５０、に加えて、判定部６０、配送側評価部７０、許容範囲画定部８０、として機能する。

判定部６０は、比較部３８による比較結果が許容範囲外であった場合に、この原因が配送側（配送業者１４）と配送先１８とのいずれにあるかを判定する。この判定では、例えば、２つの配送料金（算出部３２が算出した配送料金と予測部３６が予測した配送料金）の決定根拠（配送条件及び配送先敷地内作業量（敷地内作業情報））を、配送先１８（配送先１８の端末２６）に通知し、配送先１８に配送料金の決定根拠についての承認を求める。そして、配送料金の決定根拠が承認された場合は、原因が配送先１８にあると判定する。他方、配送料金の決定根拠が承認されなかった場合は、原因が配送側（配送業者１４）にあると判定する。なお、配送先１８に配送料金の決定根拠についての承認を求める例で説明をしたが、配送料金の請求先が配送先１８と同一である場合、前述した承認要求部５０による要求が承認された（今回の配送料金が承認された）場合に、配送料金の決定根拠についても承認されたとみなしてもよい。

配送側評価部７０は、判定部６０の判定結果を用いて、配送を請け負った配送業者を評価する。具体的には、比較部３８による比較結果が許容範囲外となった原因が配送側（配送業者）にあると判定された回数（及び／または頻度）が多い（高い）ほど、この配送を請け負った配送業者の評価を下げる。もちろん、判定部６０の判定結果だけでなく、配達時間などの配送条件を満たしたか否かも考慮して、配送を請け負った配送業者の評価を行う構成としてもよい。

許容範囲画定部８０は、配送業者の評価に応じて、配送業者毎に許容範囲（比較部３８による比較結果を許容する範囲）を設定（画定）する。具体的には、評価が高い配送業者ほど、許容範囲が広く（大きく）なるように、配送業者毎の許容範囲（各配送業者の各々に対して個別に適用する許容範囲）を設定する。

図９に、第４実施形態における処理の流れを示す。図９に示すように、第４実施形態では、比較部３８による比較結果が許容範囲外である場合、この原因が配送側（配送業者１４）と配送先１８とのいずれにあるかを判定し、この判定結果を用いて配送業者１４を評価する。そして、この評価を用いて配送業者１４に適用する許容範囲が設定される。

［第５実施形態］
上記実施形態では、配送実績を実績データ４４として記憶部３４に格納しているが、図１０に示すように、第５実施形態では、プロセッサ１０が、配送履歴保全部９０、として機能し、配送実績をブロックチェーン１００上に格納している。配送実績は、配送に関する処理の履歴であり、前述のように、荷主１６の識別情報、配送先１８の識別情報、配送業者１４の識別情報、荷物の種類、配送条件、基本配送料金や加算額、加算額の根拠となる配送先敷地内作業量や敷地内作業情報、が含まれる。

ブロックチェーン１００は、荷主１６の端末２４、配送先１８の端末２６、配送業者の端末２８などから構成されるブロックチェーンネットワークにより構築されるものであり、個々の配送の配送実績を示すデータ、及び、直前の配送における配送実績を示すデータをハッシュ化して得られるハッシュ値を含むブロック１１０を、時系列に連結したものである。

図１１に示すように、配送履歴保全部９０は、今回の配送が完了すると、この配送に関する配送実績と、直前の配送に関する配送実績をハッシュ化したハッシュ値とを含む新たなブロック１１０を生成し、ブロックチェーン１００に連結する。こうすることで、配送履歴の公明性・耐改竄性を高めることができる。なお、第５実施形態では、データの処理や登録、保管などブロックチェーンネットワークへの協力に応じて報酬（トークンなど）を付与する構成としてもよい。また、スマートコントラクトを用いて、配送料金の請求や支払いを行う構成としてもよい。

上記実施形態において、受付部３０、算出部３２、記憶部３４、予測部３６、比較部３８、通知部４０、承認要求部５０、判定部６０、配送側評価部７０、許容範囲画定部８０、配送履歴保全部９０、などの各種の処理を実行する処理部（processing unit)のハードウェア的な構造は、次に示すような各種のプロセッサ（processor）である。各種のプロセッサには、ソフトウエア（プログラム）を実行して各種の処理部として機能する汎用的なプロセッサであるＣＰＵ（Central Processing Unit)、ＦＰＧＡ (Field Programmable Gate Array) などの製造後に回路構成を変更可能なプロセッサであるプログラマブルロジックデバイス（Programmable Logic Device:ＰＬＤ）、各種の処理を実行するために専用に設計された回路構成を有するプロセッサである専用電気回路などが含まれる。

１つの処理部は、これら各種のプロセッサのうちの１つで構成されてもよいし、同種または異種の２つ以上のプロセッサの組み合せ（例えば、複数のＦＰＧＡや、ＣＰＵとＦＰＧＡの組み合わせ）で構成されてもよい。また、複数の処理部を１つのプロセッサで構成してもよい。複数の処理部を１つのプロセッサで構成する例としては、第１に、クライアントやサーバなどのコンピュータに代表されるように、１つ以上のＣＰＵとソフトウエアの組み合わせで１つのプロセッサを構成し、このプロセッサが複数の処理部として機能する形態がある。第２に、システムオンチップ（System On Chip:ＳｏＣ）などに代表されるように、複数の処理部を含むシステム全体の機能を１つのＩＣ（Integrated Circuit）チップで実現するプロセッサを使用する形態がある。このように、各種の処理部は、ハードウェア的な構造として、上記各種のプロセッサを１つ以上用いて構成される。

さらに、これらの各種のプロセッサのハードウェア的な構造は、より具体的には、半導体素子などの回路素子を組み合わせた形態の電気回路（circuitry）である。

１０ プロセッサ（配送料金算出装置）
１２ 配送支援システム
１４ 配送業者
１６ 荷主
１８ 配送先
２０ 配送先企業
２２ 敷地
２４ 端末（荷主の端末）
２６ 端末（配送先の端末）
２８ 端末（配送業者の端末）
３０ 受付部
３２ 算出部
３４ 記憶部
３６ 予測部
３８ 比較部
４０ 通知部
４２ 換算表
４４ 実績データ
５０ 承認要求部
６０ 判定部
７０ 配送側評価部
８０ 許容範囲画定部
９０ 配送履歴保全部
１００ ブロックチェーン
１１０ ブロック

Claims (7)

1. プロセッサを備え、前記プロセッサは、
   配送が完了した場合に、配送側から、配送先の住所に到達してから荷渡しが完了するまでの間に生じた前記配送側の作業量を示す配送先敷地内作業量を決定する根拠となる敷地内作業情報の入力を受け付け、
   各敷地内作業情報を換算表に照合することにより、前記各敷地内作業情報に対応する作業量を求め、これらを合計したものを前記配送先敷地内作業量とし、
   前記配送先敷地内作業量を用いて配送料金を算出し、
   過去の配送実績として、配送先と配送先敷地内作業量との対応関係を記憶し、
   新規の配送依頼を受け付けた場合に、前記新規の配送依頼の配送先が前記過去の配送実績として記憶されている前記対応関係を用いて配送料金を予測し、
   予測した配送料金と、前記配送依頼の達成後に算出した配送料金とを比較し、
   比較結果を前記配送料金の請求先に通知する、
   配送料金算出装置。
2. 前記プロセッサは、
   前記比較結果が所定の許容範囲外であった場合に、前記通知を行う、
   請求項１に記載の配送料金算出装置。
3. 前記プロセッサは、
   前記比較結果が前記許容範囲外であった場合に、前記配送依頼の達成後に算出した配送料金の承認を、前記請求先に要求する、
   請求項２に記載の配送料金算出装置。
4. 前記プロセッサは、
   前記比較結果が前記許容範囲外であった場合に、この原因が前記配送先と前記配送側とのいずれに起因するかを判定する場合において、
   前記敷地内作業情報を提示して前記承認を要求し、
   前記承認の要求が認められた場合に前記原因が前記配送先に起因すると判定し、前記承認の要求が認められなかった場合に前記原因が前記配送側に起因すると判定する請求項３に記載の配送料金算出装置。
5. 前記プロセッサは、
   前記判定の結果、前記比較結果が前記許容範囲外であった場合の回数、頻度、の少なくともいずれかを用いて、前記配送側の信頼度を評価する、
   請求項４に記載の配送料金算出装置。
6. 前記プロセッサは、
   前記配送側の信頼度に基づいて許容範囲の大きさを画定する、
   請求項５に記載の配送料金算出装置。
7. 前記プロセッサは、
   前記配送に関する処理の履歴をブロックチェーン上に格納する、
   請求項１～６のいずれか１項に記載の配送料金算出装置。