(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-05
(45)【発行日】2023-07-13
(54)【発明の名称】物流管理システム
(51)【国際特許分類】
G06Q 10/04 20230101AFI20230706BHJP
G06Q 10/087 20230101ALI20230706BHJP
【ＦＩ】
G06Q10/04
G06Q10/087
【請求項の数】
4
(21)【出願番号】P 2019089900
(22)【出願日】2019-05-10
(65)【公開番号】P2020187416
(43)【公開日】2020-11-19
【審査請求日】2022-03-08
(73)【特許権者】
【識別番号】599163458
【氏名又は名称】アスクル株式会社
(74)【代理人】
【識別番号】110002860
【氏名又は名称】弁理士法人秀和特許事務所
(72)【発明者】
【氏名】小池 和弘
【審査官】毛利 太郎
(56)【参考文献】
【文献】特開２０１２－２５６３６９（ＪＰ，Ａ）
【文献】特開２０１５－１５８８１２（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
電子商取引の商品の商品情報を取得する取得部と、前記商品の物流に関連する環境において許容される行動変数の複数の値に対して、前記取得した商品情報と前記環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、前記第３の行動モデルを用いて前記環境における最適な行動変数の値を予測する制御部と
を有し、
前記行動変数は、前記商品の販売業者による前記商品の発注数であり、
前記取得部によって取得される前記商品情報は、一定期間にわたる前記商品の発注数と出荷数と入荷数の変動を示す情報であり、
前記環境の状態変数は、前記商品の売上と、前記商品の仕入れ値と、前記商品の欠品に関連する欠品コストと、前記商品の販売促進に関連する販売促進コストと、前記商品の過剰在庫に関連する在庫コストと、前記商品の配送に関連する配送コストであり、
前記制御部は、前記行動変数の複数の値に対応する発注数それぞれに対して、前記取得した商品情報と前記環境の状態変数とを用いて互いに異なる報酬を算出する前記第１の行動モデルと前記第２の行動モデルの強化学習を基に前記第３の行動モデルを生成し、前記第３の行動モデルを用いて最適な発注数を予測する
ことを特徴とする予測装置。
【請求項2】
電子商取引の商品の商品情報を取得する取得部と、
前記商品の物流に関連する環境において許容される行動変数の複数の値に対して、前記取得した商品情報と前記環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、前記第３の行動モデルを用いて前記環境における最適な行動変数の値を予測する制御部と
を有し、
前記行動変数は、倉庫における前記商品の保管に関連する人時であり、
前記取得部によって取得される前記商品情報は、前記商品の販売促進の実施日を示す情報であり、
前記環境の状態変数は、前記商品の販売促進の実施日の曜日に応じて決定される販売促進コストであり、
前記制御部は、前記行動変数の複数の値に対応する人時それぞれに対して、前記取得し
た商品情報と前記環境の状態変数とを用いて互いに異なる報酬を算出する前記第１の行動モデルと前記第２の行動モデルの強化学習を基に前記第３の行動モデルを生成し、前記第３の行動モデルを用いて最適な人時を予測する
ことを特徴とする予測装置。
【請求項3】
電子商取引の商品の商品情報を取得する取得部と、
前記商品の物流に関連する環境において許容される行動変数の複数の値に対して、前記取得した商品情報と前記環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、前記第３の行動モデルを用いて前記環境における最適な行動変数の値を予測する制御部と
を有し、
前記行動変数は、ＥＣサイトにおいて前記商品のレコメンドのされやすさを示す値であり、
前記取得部によって取得される前記商品情報は、前記ＥＣサイトにおける一定期間にわたる前記商品のクリック数と表示回数とを示す情報であり、
前記環境の状態変数は、前記商品のサイズと、前記商品の売上と、前記商品の仕入れ値と、前記商品の前記サイズに応じて決定される在庫コストであり、
前記制御部は、前記行動変数の複数の値に対応する前記商品のレコメンドのされやすさを示す値それぞれに対して、前記取得した商品情報と前記環境の状態変数とを用いて互いに異なる報酬を算出する前記第１の行動モデルと前記第２の行動モデルの強化学習を基に前記第３の行動モデルを生成し、前記第３の行動モデルを用いて前記商品のレコメンドのされやすさを示す最適な値を予測する
ことを特徴とする予測装置。
【請求項4】
電子商取引の商品の商品情報を取得する取得部と、
前記商品の物流に関連する環境において許容される行動変数の複数の値に対して、前記取得した商品情報と前記環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、前記第３の行動モデルを用いて前記環境における最適な行動変数の値を予測する制御部と
を有し、
前記行動変数は、ＥＣサイトにおいて前記商品の配送指定日を変更することでユーザに付与されるインセンティブであり、
前記取得部によって取得される前記商品情報は、前記商品の配送先および配送日時と、前記商品の配送業者の配送エリアおよび配送可能な配送先数と、前記商品の配送の所要時間と、前記商品の配送における配送距離とを示す情報であり、
前記制御部は、前記行動変数の複数の値に対応するインセンティブそれぞれに対して、前記取得した商品情報と前記環境の状態変数とを用いて互いに異なる報酬を算出する前記第１の行動モデルと前記第２の行動モデルの強化学習を基に前記第３の行動モデルを生成し、前記第３の行動モデルを用いて最適なインセンティブを予測する
ことを特徴とする予測装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、物流管理システムに関する。
【背景技術】
【0002】
サプライチェーンにおける物流管理において、いわゆるBullwhip Effect（以下「ＢＥ
」と称する）が知られている。ＢＥとは、サプライチェーンの下流における需要予測と意思決定の結果、需要が拡大しながら、サプライチェーンの下流から上流に向かって伝搬していく現象である。この現象は過剰在庫や欠品に繋がるため、発生のメカニズムとＢＥの抑制手法は、長年に渡り研究対象となっている。ＢＥの発生要因としては、価格表、発注頻度、返品方針、価格販売施策の頻度と深さ、情報共有の程度、需要予測方法、欠品時の配分ルールなどが挙げられる。
」と称する）が知られている。ＢＥとは、サプライチェーンの下流における需要予測と意思決定の結果、需要が拡大しながら、サプライチェーンの下流から上流に向かって伝搬していく現象である。この現象は過剰在庫や欠品に繋がるため、発生のメカニズムとＢＥの抑制手法は、長年に渡り研究対象となっている。ＢＥの発生要因としては、価格表、発注頻度、返品方針、価格販売施策の頻度と深さ、情報共有の程度、需要予測方法、欠品時の配分ルールなどが挙げられる。
【0003】
また、ＢＥを検証する１手法として、Beer Game（以下「ＢＧ」と称する）が知られて
いる。ＢＧでは、直列に繋がったビールのサプライチェーンにおけるシミュレーションゲームであり、４プレーヤー（小売業者、卸売業者、流通業者、製造業者）の各プレーヤーが、決められた期間内でのコスト最小化を競う。
いる。ＢＧでは、直列に繋がったビールのサプライチェーンにおけるシミュレーションゲームであり、４プレーヤー（小売業者、卸売業者、流通業者、製造業者）の各プレーヤーが、決められた期間内でのコスト最小化を競う。
【0004】
ＢＧの過程はMarkov Decision Process（ＭＤＰ）として知られており、ＢＧにおいて
、各プレーヤーが観測できる情報は、隣り合うプレーヤーとの注文と商品のやり取りと自身の在庫レベルのみであるため、いわゆるPartially Observable Markov Decision Process（ＰＯＭＤＰ）である。ＢＧでは、各プレーヤーは、観測可能な情報からコストを最小化する行動を選択する。しかしながら、ＢＧは観測空間と行動空間が大きく、非定常な時系列を扱うため複雑な問題となる。そこで、ＢＧに深層強化学習を適用することで、サプライチェーンにおける物流プロセスの全体最適化を実現できる可能性は示されている（非特許文献１－３）。
、各プレーヤーが観測できる情報は、隣り合うプレーヤーとの注文と商品のやり取りと自身の在庫レベルのみであるため、いわゆるPartially Observable Markov Decision Process（ＰＯＭＤＰ）である。ＢＧでは、各プレーヤーは、観測可能な情報からコストを最小化する行動を選択する。しかしながら、ＢＧは観測空間と行動空間が大きく、非定常な時系列を扱うため複雑な問題となる。そこで、ＢＧに深層強化学習を適用することで、サプライチェーンにおける物流プロセスの全体最適化を実現できる可能性は示されている（非特許文献１－３）。
【先行技術文献】
【非特許文献】
【0005】
【文献】V. Mnih et al. Human-level control through deep reinforcement learning, doi 10.1038/nature14236 (2015).
【文献】Afshin Oroojlooyjadid et al. A Deep Q-Network for the Beer Game: A Reinforcement Learning Algorithm to Solve Inventory Optimization Problems, arXiv:1708.05924v2 (2018).
【文献】Taiki Fuji et al. Deep Multi-Agent Reinforcement Learning using DNN-Weight Evolution to Optimize Supply Chain Performance. doi 10.24251/HICSS.2018.157 (2018).
【発明の概要】
【発明が解決しようとする課題】
【0006】
インターネットを利用した通信販売（ネット通販）においては、サイバー空間における情報の流れの効率とフィジカル空間における物の流れの効率の差が顕著になってきており、この差がＢＥの新たな発生要因となる可能性がある。例えば、Electronic Commerce（
ＥＣ）サイトでの高度に効率化された販売施策によって需要の変動が増幅された結果、配送遅延や欠品、過剰在庫などが発生する場合が考えられる。このため、上記の従来技術を用いても、ネット通販を対象としたサプライチェーンにおける物流プロセスの全体最適化を実現することはできない可能性があり、そのような全体最適化を実現する確立された手法が提案されていなかった。
ＥＣ）サイトでの高度に効率化された販売施策によって需要の変動が増幅された結果、配送遅延や欠品、過剰在庫などが発生する場合が考えられる。このため、上記の従来技術を用いても、ネット通販を対象としたサプライチェーンにおける物流プロセスの全体最適化を実現することはできない可能性があり、そのような全体最適化を実現する確立された手法が提案されていなかった。
【0007】
そこで、本件開示の技術は、上記の事情に鑑みてなされたものであり、その目的とするところは、物流管理の全体最適化を支援する技術を提供することである。
【課題を解決するための手段】
【0008】
本件開示の予測装置は、電子商取引の商品の商品情報を取得する取得部と、商品の物流に関連する環境において許容される行動変数の複数の値に対して、取得した商品情報と環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、第３の行動モデルを用いて環境における最適な行動変数の値を予測する制御部とを有する。これにより、本予測装置によって、商品の物流管理において相反する目標が設定された２つの行動モデルから全体最適化に叶うバランスの取れた行動モデルを生成して、最適な行動変数を予測することができる。
【0009】
また、上記の予測装置において、行動変数は、商品の販売業者による商品の発注数であり、取得部によって取得される商品情報は、一定期間にわたる商品の発注数と出荷数と入荷数の変動を示す情報であり、環境の状態変数は、商品の売上と、商品の仕入れ値と、商品の欠品に関連する欠品コストと、商品の販売促進に関連する販売促進コストと、商品の過剰在庫に関連する在庫コストと、商品の配送に関連する配送コストであり、制御部は、行動変数の複数の値に対応する発注数それぞれに対して、取得した商品情報と環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、第３の行動モデルを用いて最適な発注数を予測してもよい。これにより、ＢＥＩが閾値を超えないように制御され、かつ需要数をできるだけ満たすように出荷が行われることで、在庫コストの最小化と売上の最大化という、相反する目標のバランスを取り、当該商品の在庫の最適化を図ることができる。
【0010】
また、上記の予測装置において、行動変数は、倉庫における商品の保管に関連する人時であり、取得部によって取得される商品情報は、商品の販売促進の実施日を示す情報であり、環境の状態変数は、商品の販売促進の実施日の曜日に応じて決定される販売促進コストであり、制御部は、行動変数の複数の値に対応する人時それぞれに対して、取得した商品情報と環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、第３の行動モデルを用いて最適な人時を予測してもよい。これにより、販売促進によって変動する需要数を満たすように出荷を行い、かつ商品が保管される倉庫における人時を低く維持することで、売上最大化と出荷コスト最小化という、相反する目標のバランスを取り、本シミュレーションで設定される販売促進の実施日における当該商品の出荷に割り当てられる人時の最適化を図ることができる。
【0011】
また、上記の予測装置において、行動変数は、ＥＣサイトにおいて商品のレコメンドのされやすさを示す値であり、取得部によって取得される商品情報は、ＥＣサイトにおける一定期間にわたる商品のクリック数と表示回数とを示す情報であり、環境の状態変数は、商品のサイズと、商品の売上と、商品の仕入れ値と、商品のサイズに応じて決定される在庫コストであり、制御部は、行動変数の複数の値に対応する商品のレコメンドのされやすさを示す値それぞれに対して、取得した商品情報と環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、第３の行動モデルを用いて商品のレコメンドのされやすさを示す最適な値を予測してもよい。これにより、レコメンドされないために売れない商品とレコメンドされても売れない商品とを判定して、売れる可能性がより高い商品がレコメンドされるようにすることで、ＥＣサイトにおける商品のレコメンドの最適化を図ることができる。
【0012】
また、上記の予測装置において、行動変数は、ＥＣサイトにおいて商品の配送指定日を
変更することでユーザに付与されるインセンティブであり、取得部によって取得される商品情報は、商品の配送先および配送日時と、商品の配送業者の配送エリアおよび配送可能な配送先数と、商品の配送の所要時間と、商品の配送における配送距離とを示す情報であり、制御部は、行動変数の複数の値に対応するインセンティブそれぞれに対して、取得した商品情報と環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、第３の行動モデルを用いて最適なインセンティブを予測してもよい。これにより、配送コスト最小化とインセンティブコスト最小化の２つの目標のバランスを取りつつ、ＥＣサイトにおいて当該商品の配送日の変更をユーザに促す場合に付与されるインセンティブの大きさの最適化を図ることができる。
変更することでユーザに付与されるインセンティブであり、取得部によって取得される商品情報は、商品の配送先および配送日時と、商品の配送業者の配送エリアおよび配送可能な配送先数と、商品の配送の所要時間と、商品の配送における配送距離とを示す情報であり、制御部は、行動変数の複数の値に対応するインセンティブそれぞれに対して、取得した商品情報と環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの強化学習を基に第３の行動モデルを生成し、第３の行動モデルを用いて最適なインセンティブを予測してもよい。これにより、配送コスト最小化とインセンティブコスト最小化の２つの目標のバランスを取りつつ、ＥＣサイトにおいて当該商品の配送日の変更をユーザに促す場合に付与されるインセンティブの大きさの最適化を図ることができる。
【発明の効果】
【0013】
本件開示の技術によれば、物流管理の全体最適化を支援する技術を提供することができる。
【図面の簡単な説明】
【0014】
【図13】図１３Ａは、変形例１におけるシミュレーションの報酬の一例を示し、図１３Ｂは、変形例１におけるシミュレーションの状態変数の更新の一例を示し、図１３Ｃは、変形例１におけるシミュレーションのゴール条件の一例を示す。
【発明を実施するための形態】
【0015】
以下に、図面を参照しながら、本件開示の技術の好適な実施の形態について説明する。ただし、以下に記載されている構成部品の構成は、本件開示の技術が適用される装置の構成や各種条件により適宜変更されるべきものである。よって、本件開示の技術の技術的範囲を以下の記載に限定する趣旨のものではない。
【0016】
【0017】
ネット通販では、ＥＣサイトやネットによる取引などサイバー空間で完結するプロセスと、物流倉庫や配送センターなどフィジカル空間で行われるプロセスでは特性の違いがある。例えばサイバー空間では商品１００個はあくまでも数値データである。このため、強気な販売施策によって、販売個数を１０倍の１０００個に増やすことについては、物理的な制約を受けにくいといえる。一方で、フィジカル空間では商品１００個は体積と重量を持つ実体である。このため、販売個数を１０００個に増やすことについて、倉庫のキャパシティや出荷能力など物理制約の影響を大きく受けるといえる。また、上記のＢＧでは、サプライチェーンの上流プレーヤーに対する注文においてリードタイムが存在するが、ネット通販における取引では注文のリードタイムは無視することができる。このため、ネット通販の物流プロセスの問題を扱う場合、上記のＢＧのモデルを用いても、問題の解決策を見いだすことができない可能性がある。
【0018】
ここで、図２に、ＢＧ（図２Ａ）と第１実施形態において実行されるNetshop Game（図２Ｂ）のそれぞれにおけるプレーヤーおよびサプライチェーンの関係を示す。第１実施形態では、予測装置１によって図２Ａに例示する環境が設定されたNetshop Gameと称するシミュレーションが実行される。図２Ｂに示すように、上記のＢＧでは、小売業者、卸売業者、流通業者、製造業者の４プレーヤーが直列に連結されているが、Netshop Gameでは、プレーヤーは小売業者のみとし、小売業者に対してサプライチェーンの上流側に位置付けられる卸売業者、流通業者、製造業者の３プレーヤーは供給業者として１プレーヤーにまとめる。第１実施形態ではNetshop Gameで取り扱われる電子商取引の商品は１種類であると想定する。さらに、Netshop Gameでは、小売業者を、サイバー空間で発生するプロセスを管理するサイバープレーヤーと、フィジカル空間で発生するプロセスを管理するフィジカルプレーヤーとに分ける。
【0019】
サイバープレーヤーは、顧客からの需要に対してどれだけ欠品なく商品を供給できたかを示すフィルレート（Fill Rate；ＦＲとも称する）があらかじめ設定された閾値よりも
大きくなるように行動する。サイバープレーヤーは、サイバー空間で報酬最大化を狙いとする。サイバープレーヤーは、例えばＥＣサイト上でセールなどのセールスプロモーションを積極的に行う。また、サイバープレーヤーは、在庫が増加することによって生じるコストを無視し、欠品による機会損失を最小化するように行動する。
大きくなるように行動する。サイバープレーヤーは、サイバー空間で報酬最大化を狙いとする。サイバープレーヤーは、例えばＥＣサイト上でセールなどのセールスプロモーションを積極的に行う。また、サイバープレーヤーは、在庫が増加することによって生じるコストを無視し、欠品による機会損失を最小化するように行動する。
【0020】
また、フィジカルプレーヤーは、ブルウィップ効果インデックス（Bullwhip Effect Index；ＢＥＩとも称する）があらかじめ設定された閾値よりも小さくなるように行動する
。フィジカルプレーヤーは、物流コストの最小化を狙いとする。フィジカルプレーヤーは、欠品による機会損失を無視し、倉庫および配送に関連するコストを最小化すべく、在庫をできるだけ抑え、ＢＥが大きくならないように行動する。
。フィジカルプレーヤーは、物流コストの最小化を狙いとする。フィジカルプレーヤーは、欠品による機会損失を無視し、倉庫および配送に関連するコストを最小化すべく、在庫をできるだけ抑え、ＢＥが大きくならないように行動する。
【0021】
第１実施形態では、予測装置１において図２Ｂに示す環境をOpenAI Gymによって実装し、サイバープレーヤーとフィジカルプレーヤーそれぞれの上記目的を達成するための最適な行動について、Deep Q-Network（ＤＱＮ）によって学習および評価を行う。さらに、第
1実施形態では、サイバープレーヤーとフィジカルプレーヤーそれぞれの報酬とNetshop Gameのゴール条件を踏まえて両者のバランスを取るように行動するメタプレーヤーを導入
する。なお、サイバープレーヤーとフィジカルプレーヤーが、商品情報と環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの一例である。また、メタプレーヤーが、第１の行動モデルと第２の行動モデルの強化学習を基に生成される第３の行動モデルの一例である。
1実施形態では、サイバープレーヤーとフィジカルプレーヤーそれぞれの報酬とNetshop Gameのゴール条件を踏まえて両者のバランスを取るように行動するメタプレーヤーを導入
する。なお、サイバープレーヤーとフィジカルプレーヤーが、商品情報と環境の状態変数とを用いて互いに異なる報酬を算出する第１の行動モデルと第２の行動モデルの一例である。また、メタプレーヤーが、第１の行動モデルと第２の行動モデルの強化学習を基に生成される第３の行動モデルの一例である。
【0022】
次に、Netshop Gameにおける各プレーヤーに対する設定の詳細について説明する。まず、Netshop Gameにおいて、タイムステップｔにおける観測可能な状態変数ｏｔを以下の式（１）で定義する。
ここで、ＩＬｔは、タイムステップｔにおける在庫数、ＯＯｔは供給業者に対して発注済みであるが未入荷の状態である商品数、ｄｔは顧客からの商品の需要数、ＲＳｔは、供給業者から入荷した商品数、ＳＳｔは、顧客に出荷済みの商品数、ａｔは、タイムステップｔにおいて発生するアクション、すなわち供給業者への商品の発注数である。このように、第１実施形態では、これら６変数の回帰分析を用いる。
【数1】
【0023】
また、Netshop Gameでは、ゲーム開始からゴール条件達成までを１エピソードとし、１エピソードにおける全タイムステップの状態変数ｈｏｔを以下の式（２）に示すとして記憶する。
【数2】
【0024】
次に、Netshop Gameにおけるアクション空間について説明する。アクションは、商品の物流に関連する環境において許容される行動変数であるともいえる。また、アクションの各値が行動変数の各値となる。上記のアクションに示すように、本実施形態でのアクションは、供給業者への商品の発注数である。アクション空間、すなわちプレーヤーに許容される商品の発注数の自由度、すなわち発注数の下限から上限までの範囲が広すぎると、予測装置１における処理効率が低下する可能性がある。そこで、本実施形態では、一例としてアクション空間を０から２０の離散値集合［０，１，２，・・・，２０］としてNetshop Gameを実施する。
【0025】
次に、Netshop Gameにおける報酬について説明する。上記のＢＧでは、以下の式（３）に示すように、タイムステップｔにおける在庫数によって報酬が決定される。
【0026】
【数3】
が各プレーヤーに対応する。したがって、式（３）によって全プレーヤーの報酬の総計が算出される。
【0027】
Netshop Gameでは、報酬の算出に、売値、仕入れ値、販売促進費、配送費が追加される。具体的には、サイバープレーヤーの報酬を式（４）、フィジカルプレーヤーの報酬を式（５）、メタプレーヤーの報酬を式（６）によって算出する。
ここで、ｓｐは売値、ｃｒは仕入れ値、ｃｓは販売促進費、ｃｄは配送費である。Netshop Gameでは各プレーヤーはこれらの値を観測できないものとする。
【数4】
【数5】
【数6】
【0028】
式（４）が示すように、サイバープレーヤーは、欠品の機会損失コストに加え、供給業者への発注数が需要より大きい場合にそれらの差を販売促進費として報酬に加算する。また、式（５）が示すように、フィジカルプレーヤーは、在庫数分の在庫コストと顧客への出荷数分の配送コストとを報酬に加算する。サイバープレーヤーは過剰在庫を気にせず、フィジカルプレーヤーは欠品を気にしない、という偏った指向となるように報酬が設定されているのは、局所最適解を求める状況を意図的に発生させるためである。一方、式（６）が示すように、メタプレーヤーは、上記の指向のバランスを取った全体最適解を求めるよう、上記の各コストを報酬に加算する。
【0029】
次に、Netshop Gameにおける各プレーヤーのゴール条件について説明する。上記のＢＧでは、あらかじめ決められたタイムステップ期間内における報酬の合計値によって各プレーヤーが競争するが、Netshop Gameでは、以下の２つの指標がゴール条件として設定される。各プレーヤーは、いずれかの指標を達成した時点で１エピソードを終了する。
【0030】
Netshop Gameにおけるゴール条件の１つの指標が以下の式（７）で示されるＢＥＩであり、もう１つの指標が以下の式（８）で示されるＦＲである。
ここで、ｄｅｍａｎｄは、タイムステップｔにおける顧客からの需要数の直近ｐ期間分の配列である（ｐは正の整数）。また、ｓｈｉｐｐｅｄは、タイムステップｔにおける商品の出荷数の直近ｐ期間分の配列である。また、Ｖａｒ（ｘ）は、変数ｘの分散、Ｍｅａｎ（ｘ）は、変数ｘの平均である。さらに、Netshop Gameでは、以下の式（９）および式（１０）によって各プレーヤーのゴール条件の達成を判断する。
ここで、式（９）がフィジカルプレーヤーのゴール条件に用いられ、式（１０）がサイバープレーヤーのゴール条件に用いられる。また、式（９）および式（１０）がメタプレーヤーのゴール条件に用いられる。
【数7】
【数8】
【数9】
【数10】
【0031】
次に、Netshop Gameにおいて生成される顧客からの需要数について説明する。Netshop Gameでは、タイムステップｔにおける顧客からの需要数Ｄｔが、以下の式（１１）に示されるように、タイムステップｔの直近ｐ期間分の需要数の平均値に正規分布に従う確率変数ｘを加えて生成される。
なお、初期値は、１から１０までの自然数からランダムに選択された値が採用される。
【数11】
【0032】
図３に、本実施形態においてOpenAI Gymによって実行されるシミュレーションのアルゴリズムの一例を示す。図３に示されるように、Netshop Gameでは、アクションの結果から得られる経験の蓄積および活用のバランスを取る方法として、いわゆるイプシロングリーディアルゴリズムを用い、ＤＮＮ（Deep Neural Network）を用いた状態評価を行う。図
３のアルゴリズムは、上記の非特許文献にも記載されている周知のものであるため、ここでは詳細な説明は省略する。
３のアルゴリズムは、上記の非特許文献にも記載されている周知のものであるため、ここでは詳細な説明は省略する。
【0033】
次に、本実施形態における各プレーヤーのパラメータと報酬計算の定義について説明する。図４に、OpenAI Gymによって設定される環境パラメータの一例を示す。図４に示すように、本実施形態で実行されるシミュレーションでは、ゴール条件に用いられるＢＥＩの閾値（「bei_threshold」）は０．９５、ＦＲの閾値（「fillrate_threshold」）は０．
９５、在庫コスト（「stock_cost」）は０．５、欠品コスト（「shortage_cost」）は１
．０、販売促進費（「promotion_cost」）は０．０１、配送コスト（「delivery_cost」
）は０．０１とする。また、顧客からの需要数の生成には、図中「demand_volatility」
（需要変動）、「demand_min」（最小値）、「demand_max」（最大値）の各値が使用される。また、商品の販売価格（「sales_price」）は２．０、商品の仕入れ値（「purchase_price」）は１．２とする。
９５、在庫コスト（「stock_cost」）は０．５、欠品コスト（「shortage_cost」）は１
．０、販売促進費（「promotion_cost」）は０．０１、配送コスト（「delivery_cost」
）は０．０１とする。また、顧客からの需要数の生成には、図中「demand_volatility」
（需要変動）、「demand_min」（最小値）、「demand_max」（最大値）の各値が使用される。また、商品の販売価格（「sales_price」）は２．０、商品の仕入れ値（「purchase_price」）は１．２とする。
【0034】
【0035】
メタプレーヤーの報酬についてより具体的に説明すると、メタプレーヤーに対しては、商品が欠品の場合は在庫数分の欠品コストを加算する（図中「cost += abs(IL) * self.shortage_cost if IL < 0 else 0」）。また、顧客からの需要数よりも発注数が多くなる
場合は販売促進費を加算する（図中「cost += (action - d) * self.promotion_cost if action > d else 0」）。また、現在の在庫数に対しては在庫数分の在庫コストを加算す
る（図中「cost += IL * self.stock_cost if IL > 0 else 0」）。また、出荷数に対し
ては配送コストを加算する（図中「cost += SS * self.delivery_cost if SS > 0 else 0」）。また、販売価格（売上）は、出荷数に売単価を乗算した値とする（図中「sales_price = SS * self.sales_price」）。また、仕入れ値は、入荷数に仕入れ単価を乗算した
値とする（図中「purchase_price = RS * self.purchase_price」）。そして、報酬は、
売上から仕入れ値および上記の各コストを除算した値とする（図中「reward = abs(sales_price)-abs(purchase_price)-abs(cost)」）。メタプレーヤーは、このように設定され
る報酬をもとに後述するゴール条件の達成を目指す。
場合は販売促進費を加算する（図中「cost += (action - d) * self.promotion_cost if action > d else 0」）。また、現在の在庫数に対しては在庫数分の在庫コストを加算す
る（図中「cost += IL * self.stock_cost if IL > 0 else 0」）。また、出荷数に対し
ては配送コストを加算する（図中「cost += SS * self.delivery_cost if SS > 0 else 0」）。また、販売価格（売上）は、出荷数に売単価を乗算した値とする（図中「sales_price = SS * self.sales_price」）。また、仕入れ値は、入荷数に仕入れ単価を乗算した
値とする（図中「purchase_price = RS * self.purchase_price」）。そして、報酬は、
売上から仕入れ値および上記の各コストを除算した値とする（図中「reward = abs(sales_price)-abs(purchase_price)-abs(cost)」）。メタプレーヤーは、このように設定され
る報酬をもとに後述するゴール条件の達成を目指す。
【0036】
次に、図６は、OpenAI Gymにおいて実行される上記の各状態変数の更新の一例を示す。図６に示すように、１つのタイムステップにおいて、現在の在庫数（図中「IL = self.state[0]」）、未入荷の発注数（図中「OO = self.state[1]」）、１つ前のタイムステップにおける発注数（図中「a = self.state[5]」）が用いられる。また、需要の移動平均に正規分布に従う変動数を加算することで、顧客からの需要数が乱数を用いて生成される（図中「d = max(self.demand_min,int(dave + np.random.randn() * self.demand_volatility))」）。また、入荷数リードタイムを１として発注数に応じた商品が入荷するものとする（図中「RS = a # received shipment = last order ( shipping lead time = 1
)」）。
)」）。
【0037】
そして、まず供給業者から入荷した商品数を在庫数に加算する（図中「IL += RS」）。その後、顧客からの需要数が在庫数よりも小さい場合は（図中「if d < IL:」）、需要数分の商品数を顧客に出荷し（図中「SS = d」）、顧客からの需要数が在庫数以上となる場合は（図中「else: # d >= IL」）、在庫数を顧客への出荷数とし（図中「SS = IL」）、在庫数を変更する（図中「IL -= SS」）。そして、今回の発注数から入荷数を除算した値を未入荷の発注数に加算する（図中「OO += action - RS」）。このように各状態変数が
変更され、変更後の状態変数を用いて次のタイムステップにおける商品の発注、入荷、出荷がそれぞれ行われる。
変更され、変更後の状態変数を用いて次のタイムステップにおける商品の発注、入荷、出荷がそれぞれ行われる。
【0038】
図７は、メタプレーヤーに対するゴール条件の一例を示す。図７に示すように、現在のタイムステップから直近の一定期間（例えば１００日）における出荷数の分散（図中「vars4 = np.var(shipped)」）と需要数の分散（図中「vars2 = np.var(demand)」）とを算
出し、算出した分散からＢＥＩを算出する（図中「bei = vars4 / vars2 if vars2 != 0 else bei_threshold」）。そして、算出したＢＥＩが上記のＢＥＩの閾値より小さい場合は（図中「if bei < bei_threshold:」）、算出したＢＥＩはＢＥＩの条件を満たしたとする（図中「bei_flag = True」）。また、現在のタイムステップから直近の一定期間（
例えば１００日）における需要数に対する出荷数の平均を算出する（図中「fillrate = np.mean(shipped / demand)」）。そして、算出した平均が上記のＦＲの閾値よりも大きい場合は（図中「if fillrate > self.fillrate_threshold:」）、算出した平均はＦｉｌｌｒａｔｅの条件を満たしたとする（図中「fill_flag = True」）。そして、上記の２つの条件がいずれも満たされた場合にゴール条件が達成されたとみなす（図中「done = fill_flag & sum_flag」）。
出し、算出した分散からＢＥＩを算出する（図中「bei = vars4 / vars2 if vars2 != 0 else bei_threshold」）。そして、算出したＢＥＩが上記のＢＥＩの閾値より小さい場合は（図中「if bei < bei_threshold:」）、算出したＢＥＩはＢＥＩの条件を満たしたとする（図中「bei_flag = True」）。また、現在のタイムステップから直近の一定期間（
例えば１００日）における需要数に対する出荷数の平均を算出する（図中「fillrate = np.mean(shipped / demand)」）。そして、算出した平均が上記のＦＲの閾値よりも大きい場合は（図中「if fillrate > self.fillrate_threshold:」）、算出した平均はＦｉｌｌｒａｔｅの条件を満たしたとする（図中「fill_flag = True」）。そして、上記の２つの条件がいずれも満たされた場合にゴール条件が達成されたとみなす（図中「done = fill_flag & sum_flag」）。
【0039】
各プレーヤーは、図５に示すように設定される報酬を基に上記のゴール条件の達成を目指して、タイムステップごとに図６に示す状態変数の更新を繰り返していく。図８に、Netshop Gameにおいてタイムステップの上限を５００００ステップとして強化学習を行った場合の、メタプレーヤーを対象としたタイムステップと報酬の変化の一例を示すグラフである。グラフの横軸はタイムステップを表し、グラフの縦軸は上記の通りメタプレーヤーが得る報酬を表す。図８のグラフが示すように、メタプレーヤーの報酬は、タイムステッ
プが進むほど報酬が一定値に向かって上昇していくことがわかる。したがって、タイムステップが進むたびにメタプレーヤーの学習が蓄積されていくものといえる。
プが進むほど報酬が一定値に向かって上昇していくことがわかる。したがって、タイムステップが進むたびにメタプレーヤーの学習が蓄積されていくものといえる。
【0040】
図９～図１１は、上記のNetshop Gameによって学習済みの各プレーヤーの行動モデルを用いて、再度Netshop Gameを１００エピソード分実行したテストにおける、需要数と発注数と在庫数との変化の一例を示すグラフである。グラフの横軸はタイムステップを表し（図中「ｓｔｅｐ」）、グラフの縦軸は商品数を表す（図中「ｉｔｅｍｓ」）。なお、図９は、サイバープレーヤーの獲得報酬の推移を示し、図１０は、フィジカルプレーヤーの獲得報酬の推移を示し、図１１は、メタプレーヤーの獲得報酬の推移を示す。ここで、プレーヤーが学習済みであるとは、図９に示すように、プレーヤーが獲得する報酬がほぼ一定に推移するような状態までプレーヤーの学習が蓄積された状態であるとする。また、１エピソードのタイムステップ数の上限を１０００ステップとし、プレーヤーが上記のゴール条件を達成することなく１０００ステップ目のタイムステップの行動を完了した時点でエピソードを終了する。なお、各図のグラフは、各エピソードの最後の１００ステップ分、すなわちエピソード終了時点から１００ステップ分遡った獲得報酬の推移を示す。また、各図において、「ｓｔｏｃｋ」は在庫数、「ｄｅｍａｎｄ」は需要数、「ｓｈｉｐｐｅｄ」は出荷数をそれぞれ表す。
【0041】
図９の在庫数の推移が示すように、Netshop Gameにおいてサイバープレーヤーの行動によって過剰在庫が増大して高止まりする傾向があると考えられる。また、図１０では在庫数が０である状態が複数ステップに亘って継続していることから、フィジカルプレーヤーの行動によって欠品が頻繁に発生する傾向があると考えられる。一方、図１１では在庫数の推移を示すグラフが概ねのこぎり形となっている。これは、在庫数が０となっても直後のステップあるいは数ステップ以内で在庫数が増加し、在庫数が増えすぎた場合でも需要数および出荷数が在庫数を押し下げるように働いていると考えることができる。したがって、メタプレーヤーの行動によってバランスのとれた在庫数が実現できる可能性があると考えられる。
【0042】
図１２に、上記のテストにおける各プレーヤーのゲーム条件達成までの所要ステップ数、ＢＥＩの値、ＦＲの値、獲得報酬の値について１００エピソードの平均値を求めた結果を示す。図９～１１のグラフにおいて、ゴール条件を達成するまでに要するステップ数（図中「ｓｔｅｐｓ」）は、小さいほどよい。また、ＢＥＩの値が１．０より小さくなる場合に、ＢＥの影響が抑制されていると考えられる。また、ＦＲの値は顧客からの需要に対して出荷できる割合を示しており、１．０に近いほどよい。図１２からわかるように、報酬の最大化だけが目的であればサイバープレーヤーが最適であるが、図９に示す在庫数の推移からわかるように、サイバープレーヤーの場合はエピソード内で在庫数が大きい状態が継続するという現象が生じている。この現象が発生する一因としては、サイバープレーヤーに対する報酬の設定においては過剰在庫を抑制する要素を与えていないことが挙げられる。
【0043】
図１２に示すように、フィジカルプレーヤーの場合は、在庫数が小さい値で維持され、このためＢＥＩもサイバープレーヤーに比べて低い値となるが、図１０に示す在庫数の推移からわかるように、在庫数が０の状態が複数ステップにわたって継続する、すなわち欠品の状態が継続することがあり、結果としてＦＲの値も低い値となっている。
【0044】
また、図１２に示すように、メタプレーヤーの場合は、サイバープレーヤーとフィジカルプレーヤーに比べると獲得報酬は低いが、ＢＥＩの値はサイバープレーヤーとフィジカルプレーヤーの場合よりも小さくなり、ＦＲの値は、過剰在庫がより多く発生するサイバープレーヤーの場合と欠品がより多く発生するフィジカルプレーヤーの場合の間の値となっている。また、図１１の在庫数の推移を示すグラフにおいて、複数ステップにわたって
在庫数の変化の周期および変動幅がほぼ一定となる部分があることから在庫数、入荷数、出荷数のバランスが取れている、すなわち在庫を安定させるための適正な在庫数管理の学習効果が得られていると考えられる。
在庫数の変化の周期および変動幅がほぼ一定となる部分があることから在庫数、入荷数、出荷数のバランスが取れている、すなわち在庫を安定させるための適正な在庫数管理の学習効果が得られていると考えられる。
【0045】
第１実施形態では、予測装置１の制御部１１が取得部としての通信部１５を制御して商品情報ＤＢ（データベース）２と通信する。通信部１５は、商品情報ＤＢ２に記憶されている、一定期間における商品の発注数、出荷数、入荷数の情報を取得する。なお、ここで商品情報ＤＢ２から取得される情報が、一定期間にわたる商品の発注数と出荷数と入荷数の変動を示す商品情報の一例である。制御部１１は通信部１５によって取得された情報を基に各状態変数に基づいて決定される報酬を、発注数を変更しながら算出する強化学習によって上記の行動モデルを生成する。そして、制御部１１は、この行動モデルを用いて、Netshop Gameにおけるメタプレーヤーの行動のシミュレーションを行う。
【0046】
具体的には、制御部１１は、メタプレーヤーによる商品の発注数を上限から下限まで変更しながら、例えば上記の例では発注数を０から２０まで１ずつ増加させながら、シミュレーションを繰り返す。制御部１１は、一例として上記のように１エピソードのタイムステップ数の上限を１０００ステップとし、メタプレーヤーが上記のゴール条件を達成することなく１０００ステップ目のタイムステップの行動を完了した時点でエピソードを終了することとして、各発注数に対して１００エピソード実行した結果を基に、各発注数に対するゴール条件達成までのステップ数、ＢＥＩの値、ＦＲの値、獲得報酬について１００エピソードの平均値を算出し、算出結果を記憶部１２に記憶したり、表示部１４に表示したり、通信部１５から外部装置（図示せず）に送信したりすることで、算出結果を出力する。なお、予測装置１による算出結果が、予測装置によって予測される最適な発注数の一例である。
【0047】
ユーザは、予測装置１による算出結果を確認して、シミュレーションの対象となった商品の実際の発注数を決定することができる。したがって、第１実施形態によれば、販売業者による商品の発注数が、予測装置１によるシミュレーションによる算出結果を基に調整される。これにより、ＢＥＩが閾値を超えないように制御され、かつ需要数をできるだけ満たすように出荷が行われることで、在庫コストの最小化と売上の最大化という、相反する目標のバランスを取り、当該商品の在庫の最適化を図ることができる。
【0048】
以上が本実施形態に関する説明であるが、本実施形態の予測装置１の構成や処理は、上記説明の内容に限定されるものではなく、本発明の技術的思想と同一性を失わない範囲内において種々の変更が可能である。以下に、上記の実施形態の変形例について説明する。なお、以下の説明において、上記と同様の構成や処理などについては同一の符号を付し、詳細な説明については省略する。
【0049】
（変形例１）
変形例１では、ＥＣサイトで販売される１商品の販売促進の戦略に沿った商品の在庫を保管する倉庫の作業者について、１日の出荷に必要な作業人時の決定を行う。なお、本変形例で実行されるシミュレーションでは、１つのタイムステップを１日とし、各日に曜日が設定され、商品の販売促進が実施される日があらかじめ設定されているものと想定する。販売促進の実施日の一例として、５を含む日（５日、１５日、２５日）や五十日などが挙げられる。なお、販売促進の実施日を示す情報は、例えば商品情報ＤＢ２に記憶されていて予測装置１が商品情報ＤＢ２から取得してもよいし、ユーザが操作部１３を操作して入力してもよい。図１３に、予測装置１において、OpenAI Gymによって設定される本シミュレーションの報酬の一例（図１３Ａ）とOpenAI Gymにおいて実行される各状態変数の更新の一例（図１３Ｂ）を示す。なお、本シミュレーションにおけるアクション（行動変数）は、１日における商品の出荷に必要な作業人時であり、０から所定の上限値までの値が
選択される。
変形例１では、ＥＣサイトで販売される１商品の販売促進の戦略に沿った商品の在庫を保管する倉庫の作業者について、１日の出荷に必要な作業人時の決定を行う。なお、本変形例で実行されるシミュレーションでは、１つのタイムステップを１日とし、各日に曜日が設定され、商品の販売促進が実施される日があらかじめ設定されているものと想定する。販売促進の実施日の一例として、５を含む日（５日、１５日、２５日）や五十日などが挙げられる。なお、販売促進の実施日を示す情報は、例えば商品情報ＤＢ２に記憶されていて予測装置１が商品情報ＤＢ２から取得してもよいし、ユーザが操作部１３を操作して入力してもよい。図１３に、予測装置１において、OpenAI Gymによって設定される本シミュレーションの報酬の一例（図１３Ａ）とOpenAI Gymにおいて実行される各状態変数の更新の一例（図１３Ｂ）を示す。なお、本シミュレーションにおけるアクション（行動変数）は、１日における商品の出荷に必要な作業人時であり、０から所定の上限値までの値が
選択される。
【0050】
図１３Ａに示すように、本変形例で実行されるシミュレーションでは、メタプレーヤーに対して、需要数と商品を出荷可能な在庫数との差の累積の絶対値を算出する（図中「cost += abs(b)」）。また、現在のステップにおける曜日が土曜日または日曜日であるか否かを判定する（図中「if self.sat_sun_day_flag(y):」）。そして、土曜日または日曜日である場合は、必要人時と出荷に対応可能な人時との差に、土曜日・日曜日用の係数（土日稼働係数）を乗算してコストとする（図中「cost += abs(f) * self.manpower_cost_holiday」）。一方、曜日が平日である場合は、必要人時と出荷に対応可能な人時との差に
、平日用の係数（平日稼働係数）を乗算してコストとする（図中「cost += abs(f) * self.manpower_cost_weekday」）。なお、これらのコストが、商品の販売促進の実施日の曜
日に応じて決定される販売促進コストの一例である。そして、算出したコストのマイナスの値を報酬とする。メタプレーヤーは、このように設定される報酬をもとに後述するゴール条件の達成を目指す。
、平日用の係数（平日稼働係数）を乗算してコストとする（図中「cost += abs(f) * self.manpower_cost_weekday」）。なお、これらのコストが、商品の販売促進の実施日の曜
日に応じて決定される販売促進コストの一例である。そして、算出したコストのマイナスの値を報酬とする。メタプレーヤーは、このように設定される報酬をもとに後述するゴール条件の達成を目指す。
【0051】
また、図１３Ｂに示すように、１つのタイムステップにおいて、まず、日付が１日進められる（図中「self.step_date += datetime.timedelta(days=1)」）。次に、現在日が販売促進の実施日であるか否かを判定する（図中「t = self.five_six_day_flag(self.step_date.day)」）。次に、現在日の曜日を特定する（図中「y = self.step_date.weekday()」）。そして、販売促進の実施日（ｔ）と曜日（ｙ）と移動平均（ｄａｖｅ）とを用いて商品の需要数を決定する（図中「d = self.demand_by_date(t,y,dave)」）。次に、１時
間あたりの出荷数を決定する（図中「r = self.avg_productivity」）。そして、需要数
分の商品を出荷するために必要となる人時を算出する（図中「n = int( d / r )」）。次に、アクションで選択された人時を特定する（図中「m = action」）。そして、アクションで選択された人時によって出荷可能な在庫数を算出する（図中「p = m * r」）。また
、需要数分の商品を出荷するために必要な人時（ｎ）と出荷に対応可能な人時（ｍ）との差（ｆ）を算出する（図中「f = n - m」）。なお、図１３Ａ、図１３Ｂからわかるよう
に、この差（ｆ）を用いて報酬が計算される。そして、需要数と出荷可能な在庫数の差の累積を算出する（図中「b = self.state[B] + (d - p)」）。このように各状態変数が変
更され、変更後の状態変数を用いて次のタイムステップにおいて、生成される需要を基に商品の出荷が行われる。
間あたりの出荷数を決定する（図中「r = self.avg_productivity」）。そして、需要数
分の商品を出荷するために必要となる人時を算出する（図中「n = int( d / r )」）。次に、アクションで選択された人時を特定する（図中「m = action」）。そして、アクションで選択された人時によって出荷可能な在庫数を算出する（図中「p = m * r」）。また
、需要数分の商品を出荷するために必要な人時（ｎ）と出荷に対応可能な人時（ｍ）との差（ｆ）を算出する（図中「f = n - m」）。なお、図１３Ａ、図１３Ｂからわかるよう
に、この差（ｆ）を用いて報酬が計算される。そして、需要数と出荷可能な在庫数の差の累積を算出する（図中「b = self.state[B] + (d - p)」）。このように各状態変数が変
更され、変更後の状態変数を用いて次のタイムステップにおいて、生成される需要を基に商品の出荷が行われる。
【0052】
図１３Ｃは、本変形例におけるシミュレーションにおけるゴール条件の一例を示す。図１３Ｃに示すように、現在のタイムステップから直近の一定期間（例えば１００日）における需要数に対する出荷数の平均を算出する（図中「fillrate = np.mean(shipped / demand)」）。そして、算出した平均が上記のＦＲの閾値よりも大きい場合は（図中「if fillrate > self.fillrate_threshold:」）、算出した平均はＦｉｌｌｒａｔｅの条件を満たしたとする（図中「fill_flag = True」）。また、現在のタイムステップから直近の一定期間（例えば１００日）における各日の人時ｎ、ｍそれぞれの合計を算出する（図中「ssum = np.sum(history,axis=0)」）。また、現在のタイムステップにおける需要数分の商
品の出荷を行うために必要な人時ｎの月当たりの合計を算出する（図中「nsum = int(ssum[N]/self.months)」）。また、アクションでｎ選択される人時ｍの月当たりの合計を算
出する（図中「msum = int(ssum[M]/self.months)」）。そして、算出した人時ｍの月当
たりの合計が算出した人時ｎの月当たりの合計以下である場合は（図中「if nsum >= msum:」）、コスト最小化が達成されたとして人時の条件が満たされたとする（図中「sum_flag = True」）。そして、上記の２つの条件がいずれも満たされた場合にゴール条件が達
成されたとみなす（図中「done = fill_flag & sum_flag」）。
品の出荷を行うために必要な人時ｎの月当たりの合計を算出する（図中「nsum = int(ssum[N]/self.months)」）。また、アクションでｎ選択される人時ｍの月当たりの合計を算
出する（図中「msum = int(ssum[M]/self.months)」）。そして、算出した人時ｍの月当
たりの合計が算出した人時ｎの月当たりの合計以下である場合は（図中「if nsum >= msum:」）、コスト最小化が達成されたとして人時の条件が満たされたとする（図中「sum_flag = True」）。そして、上記の２つの条件がいずれも満たされた場合にゴール条件が達
成されたとみなす（図中「done = fill_flag & sum_flag」）。
【0053】
本変形例では、制御部１１は、上記の報酬を、複数の人時それぞれに対して算出する強化学習によって行動モデルを生成し、生成した行動モデルを用いてシミュレーションを行
う。具体的に、制御部１１は、一例として１日（１ステップ）において出荷に必要な人時を下限から上限まで変更しながら、例えば０からアクションで選択可能な上限値まで所定人時ずつ増加させながらシミュレーションを繰り返す。そして、制御部１１は、一例として上記のように１エピソードのタイムステップ数の上限を１０００ステップとし、メタプレーヤーが上記のゴール条件を達成することなく１０００ステップ目のタイムステップの行動を完了した時点でエピソードを終了することとして、各人時に対して１００エピソード実行した結果を基に、各人時に対するゴール条件達成までのタイムステップ数、ＦＲの値について１００エピソードの平均値を算出する。そして、制御部１１は、算出結果を記憶部１２に記憶したり、表示部１４に表示したり、通信部１５から外部装置に送信したりすることで、算出結果を出力する。
う。具体的に、制御部１１は、一例として１日（１ステップ）において出荷に必要な人時を下限から上限まで変更しながら、例えば０からアクションで選択可能な上限値まで所定人時ずつ増加させながらシミュレーションを繰り返す。そして、制御部１１は、一例として上記のように１エピソードのタイムステップ数の上限を１０００ステップとし、メタプレーヤーが上記のゴール条件を達成することなく１０００ステップ目のタイムステップの行動を完了した時点でエピソードを終了することとして、各人時に対して１００エピソード実行した結果を基に、各人時に対するゴール条件達成までのタイムステップ数、ＦＲの値について１００エピソードの平均値を算出する。そして、制御部１１は、算出結果を記憶部１２に記憶したり、表示部１４に表示したり、通信部１５から外部装置に送信したりすることで、算出結果を出力する。
【0054】
ユーザは、予測装置１による算出結果を確認して、シミュレーションの対象となった商品について、販売促進の実施日における出荷に対する人時を決定することができる。したがって、第１実施形態によれば、商品の出荷に割り当てられる人時が、予測装置１によるシミュレーションによる算出結果を基に調整される。これにより、販売促進によって変動する需要数を満たすように出荷を行い、かつ商品が保管される倉庫における人時を低く維持することで、売上最大化と出荷コスト最小化という、相反する目標のバランスを取り、本シミュレーションで設定される販売促進の実施日における当該商品の出荷に割り当てられる人時の最適化を図ることができる。
【0055】
（変形例２）
変形例２では、ＥＣサイトで販売される商品を対象に、在庫数が変動しない不動在庫を特定して当該商品のレコメンドの要否の判定を行う。なお、本変形例で実行されるシミュレーションでは、１つのタイムステップを１日とし、ユーザが情報処理端末を使用してインターネット上でＥＣサイトの商品ページを示す情報を検索し、検索結果のページからＥＣサイトの商品ページに移動するものと想定する。また、商品情報の検索結果に当該商品ページの情報が表示される回数を商品の表示回数とし、当該商品ページへの移動回数をクリック数とする。また、１商品が倉庫内で占有する空間の指標となるサイズがあらかじめ定められているとする。
変形例２では、ＥＣサイトで販売される商品を対象に、在庫数が変動しない不動在庫を特定して当該商品のレコメンドの要否の判定を行う。なお、本変形例で実行されるシミュレーションでは、１つのタイムステップを１日とし、ユーザが情報処理端末を使用してインターネット上でＥＣサイトの商品ページを示す情報を検索し、検索結果のページからＥＣサイトの商品ページに移動するものと想定する。また、商品情報の検索結果に当該商品ページの情報が表示される回数を商品の表示回数とし、当該商品ページへの移動回数をクリック数とする。また、１商品が倉庫内で占有する空間の指標となるサイズがあらかじめ定められているとする。
【0056】
図１４Ａは、予測装置１において、OpenAI Gymによって設定されるシミュレーションの報酬の一例を示し、図１４Ｂは、OpenAI Gymにおいて実行される各状態変数の更新の一例を示す。なお、本シミュレーションにおけるアクション（行動変数）は、商品のレコメンドの要否を決定するための閾値であり、例えば０．０から１．０まで０．１刻みの値のうちいずれかの値が選択される。なお、当該閾値が、ＥＣサイトにおいて商品のレコメンドのされやすさを示す値の一例である。
【0057】
図１４Ａに示すように、本変形例で実行されるシミュレーションでは、メタプレーヤーに対して、一定期間、すなわち所定数連続する複数ステップにおいて、商品ページのクリック数（図中「click_num」）と商品ページの表示回数（図中「view_num」）を基に、当
該期間の商品ページのクリックスルー率を算出する（図中「click_through_rate = click_num / view_num」）。そして、クリックスルー率に利益とサイズを乗算した値を報酬と
する（図中「reward = click_through_rate * profit * size」）。すなわち、利益またはサイズが大きくなるほど報酬も大きくなる。メタプレーヤーは、このように設定される報酬をもとに後述するゴール条件の達成を目指す。
該期間の商品ページのクリックスルー率を算出する（図中「click_through_rate = click_num / view_num」）。そして、クリックスルー率に利益とサイズを乗算した値を報酬と
する（図中「reward = click_through_rate * profit * size」）。すなわち、利益またはサイズが大きくなるほど報酬も大きくなる。メタプレーヤーは、このように設定される報酬をもとに後述するゴール条件の達成を目指す。
【0058】
また、図１４Ｂに示すように、１つのタイムステップにおいて、商品１個あたりの利益（一例として販売価格から仕入れ値と在庫コストとを差し引いた額）（図中「profit」）と、１日における商品ページのクリック数（図中「click_num_one_day」）と、１日にお
ける商品ページの表示回数（図中「view_num_one_day」）と、商品が倉庫に保管されてい
る日数である在庫日数（図中「stock_days」）と、在庫数（図中「stock_num」）と、上
記のアクションで選択される閾値（図中「boost_value」）が状態変数である。また、本
変形例では、図中「boost_value」以外の値を示す情報が商品情報ＤＢ２に記憶されてい
る。また、商品情報ＤＢ２には、上記の各値が、例えば過去３０日など、過去の一定期間にわたって日別に記憶されているものとする。予測装置１は、商品情報ＤＢ２に記憶されている一定期間にわたる各値の情報を取得し、タイムステップが１つ進むごとに、取得した情報を基に翌日の各値を特定し、特定した値で各状態変数を更新する。このように各状態変数が変更され、変更後の状態変数を用いて次のタイムステップにおける商品のレコメンドの要否判定が行われる。
ける商品ページの表示回数（図中「view_num_one_day」）と、商品が倉庫に保管されてい
る日数である在庫日数（図中「stock_days」）と、在庫数（図中「stock_num」）と、上
記のアクションで選択される閾値（図中「boost_value」）が状態変数である。また、本
変形例では、図中「boost_value」以外の値を示す情報が商品情報ＤＢ２に記憶されてい
る。また、商品情報ＤＢ２には、上記の各値が、例えば過去３０日など、過去の一定期間にわたって日別に記憶されているものとする。予測装置１は、商品情報ＤＢ２に記憶されている一定期間にわたる各値の情報を取得し、タイムステップが１つ進むごとに、取得した情報を基に翌日の各値を特定し、特定した値で各状態変数を更新する。このように各状態変数が変更され、変更後の状態変数を用いて次のタイムステップにおける商品のレコメンドの要否判定が行われる。
【0059】
図１４Ｃは、本変形例におけるシミュレーションにおけるゴール条件の一例を示す。図１４Ｃに示すように、上記の一定期間におけるクリックスルー率があらかじめ設定された閾値より大きい場合は（図中「if click_through_rate >= click_through_rate _threshold:」）、クリックスルー率の条件が満たされたとする（図中「click_through_rate_flag
= True」）。また、現在のタイムステップから直近の一定期間（例えば１００日）の商
品の在庫日数平均「stock_days」があらかじめ設定された閾値より大きい場合は（図中「if stock_days >= stock_days_threshold:」）、商品の在庫日数平均の条件が満たされたとする（図中「stock_days_flag = True」）。そして、上記の２つの条件がいずれも満たされた場合にゴール条件が達成されたとみなす（図中「done = click_through_rate_flag
& stock_days_flag」）。
= True」）。また、現在のタイムステップから直近の一定期間（例えば１００日）の商
品の在庫日数平均「stock_days」があらかじめ設定された閾値より大きい場合は（図中「if stock_days >= stock_days_threshold:」）、商品の在庫日数平均の条件が満たされたとする（図中「stock_days_flag = True」）。そして、上記の２つの条件がいずれも満たされた場合にゴール条件が達成されたとみなす（図中「done = click_through_rate_flag
& stock_days_flag」）。
【0060】
本変形例では、制御部１１は、取得した商品情報と、商品のサイズと、商品の売上と、商品の仕入れ値と、商品のサイズに応じて決定される在庫コストとに基づいて決定される報酬を、商品のレコメンドのされやすさを示す複数の値それぞれに対して算出する強化学習によって行動モデルを生成し、生成した行動モデルを用いてシミュレーションを行う。具体的に、制御部１１は、商品のレコメンドの要否を決定するための閾値を下限から上限まで変更しながら、例えば０．０から１．０まで０．１ずつ増加させながらシミュレーションを繰り返す。ここで、制御部１１は、１エピソードのタイムステップ数を、商品情報ＤＢ２から取得した上記の各値の情報の対象期間の日数とし、各閾値に対して１００エピソード実行した結果を基に、各閾値に対するゴール条件達成までのタイムステップ数、クリックスルー率、在庫日数平均について１００エピソードの平均値を算出する。例えば、商品情報ＤＢ２から過去３０日にわたる上記の各値の情報が取得される場合は、１エピソードのタイムステップ数は３０となる。制御部１１は、算出結果を記憶部１２に記憶したり、表示部１４に表示したり、通信部１５から外部装置に送信したりすることで、算出結果を出力する。
【0061】
ユーザは、予測装置１による算出結果を確認して、シミュレーションの対象となった商品のレコメンドの要否を決定することができる。したがって、変形例１によれば、ＥＣサイトにおける商品のレコメンドの要否が、予測装置１によるシミュレーションによる算出結果を基に判定される。これにより、ＥＣサイトにおいて、在庫日数の閾値を超えた商品がレコメンドされる、すなわちユーザの情報処理端末に表示される。そして、ユーザが表示された商品をクリックしないなど、レコメンドされた商品に対するユーザの操作が発生しない状況が継続する場合は、当該商品がレコメンドされないようになる。この結果、レコメンドされないために売れない商品とレコメンドされても売れない商品とを判定して、売れる可能性がより高い商品がレコメンドされるようにすることで、ＥＣサイトにおける商品のレコメンドの最適化を図ることができる。
【0062】
（変形例３）
変形例３では、ＥＣサイトで販売される商品を対象に、ユーザによる商品の注文時に配送指定日を変更することでユーザに付与されるインセンティブの決定を行う。ここで、イ
ンセンティブとは、商品の注文に対してユーザに還元されるＥＣサイトで利用可能なポイントなどである。インセンティブについては周知であるため詳細な説明は省略する。なお、本変形例におけるアクション（行動変数）は、インセンティブであり、例えば０．０から１．０まで０．１刻みの値のうちいずれかの値が選択される。また、本変形例で実行されるシミュレーションでは、１つのタイムステップを１日とし、ユーザがＥＣサイトにおいて商品の注文時に配送指定日を変更することが可能であるものと想定する。
変形例３では、ＥＣサイトで販売される商品を対象に、ユーザによる商品の注文時に配送指定日を変更することでユーザに付与されるインセンティブの決定を行う。ここで、イ
ンセンティブとは、商品の注文に対してユーザに還元されるＥＣサイトで利用可能なポイントなどである。インセンティブについては周知であるため詳細な説明は省略する。なお、本変形例におけるアクション（行動変数）は、インセンティブであり、例えば０．０から１．０まで０．１刻みの値のうちいずれかの値が選択される。また、本変形例で実行されるシミュレーションでは、１つのタイムステップを１日とし、ユーザがＥＣサイトにおいて商品の注文時に配送指定日を変更することが可能であるものと想定する。
【0063】
【0064】
図１５Ａに示すように、本変形例で実行されるシミュレーションでは、シミュレーションの対象となる商品の配送に必要な人時の値を報酬とする（図中「reward = click_through_rate * profit * size」）。すなわち、利益またはサイズが大きくなるほど報酬も大きくなる。メタプレーヤーは、このように設定される報酬をもとにゴール条件の達成を目指す。
【0065】
また、図１５Ｂに示すように、１つのタイムステップにおいて、商品の注文情報（注文ＩＤ、配送先の緯度および経度、現在の指定された配送日時である配送指定日および配送時間帯、配送の個口数を含む）（図中「order_info : (order_id, latitude, longitude,
date, time, parcel_num)」）、商品の配送における時空間クラスタ情報（現在の配送指定日および配送時間帯、商品の配送を行うクラスタの中心位置の緯度および経度、当該クラスタの半径、当該クラスタの配送可能な配送先数、現在の当該クラスタ内で予定されている配送の配送先数）（図中「time_space_cluster_info : [ (date,time,latitude,longitude,radius,max,num) , ….]」）、配送に必要な総人時（図中「man_hour」）、配送に必要な総配送員人数（図中「deivers_num」）、クラスタの総数（図中「cluster_num」）、配送に伴う所要時間である総待ち時間（図中「idle_time」）、総配送距離（図中「distance」）、配送指定日時と最適化された日時との差（図中「difference」）、配送指定
日を変更した場合にユーザに付与されるインセンティブ（一例としてポイント数。図中「incentive : basic_point * action (0.0～1.0)」）が状態変数である。また、本変形例
では、図中「incentive : basic_point * action (0.0～1.0)」以外の値を示す情報が商
品情報ＤＢ２に記憶されている。なお、クラスタが配送業者の配送エリアの一例である。予測装置１は、商品情報ＤＢ２に記憶されている一定期間にわたる各値の情報を取得し、タイムステップが１つ進むごとに、取得した情報を基に翌日の各値を特定し、特定した値で各状態変数を更新する。このように各状態変数が変更され、変更後の状態変数を用いて次のタイムステップにおける配送に必要な総人時の算出が行われる。
date, time, parcel_num)」）、商品の配送における時空間クラスタ情報（現在の配送指定日および配送時間帯、商品の配送を行うクラスタの中心位置の緯度および経度、当該クラスタの半径、当該クラスタの配送可能な配送先数、現在の当該クラスタ内で予定されている配送の配送先数）（図中「time_space_cluster_info : [ (date,time,latitude,longitude,radius,max,num) , ….]」）、配送に必要な総人時（図中「man_hour」）、配送に必要な総配送員人数（図中「deivers_num」）、クラスタの総数（図中「cluster_num」）、配送に伴う所要時間である総待ち時間（図中「idle_time」）、総配送距離（図中「distance」）、配送指定日時と最適化された日時との差（図中「difference」）、配送指定
日を変更した場合にユーザに付与されるインセンティブ（一例としてポイント数。図中「incentive : basic_point * action (0.0～1.0)」）が状態変数である。また、本変形例
では、図中「incentive : basic_point * action (0.0～1.0)」以外の値を示す情報が商
品情報ＤＢ２に記憶されている。なお、クラスタが配送業者の配送エリアの一例である。予測装置１は、商品情報ＤＢ２に記憶されている一定期間にわたる各値の情報を取得し、タイムステップが１つ進むごとに、取得した情報を基に翌日の各値を特定し、特定した値で各状態変数を更新する。このように各状態変数が変更され、変更後の状態変数を用いて次のタイムステップにおける配送に必要な総人時の算出が行われる。
【0066】
図１５Ｃは、本変形例におけるシミュレーションにおけるゴール条件の一例を示す。図１５Ｃに示すように、現在のタイムステップから直近の一定期間（例えば１００日）において配送に必要な総人時（図中「man_hour_sum」）と当該配送に割当可能な最大人時（図中「max_ man_hour_sum」）とを算出する。そして、算出したそれぞれの人時を基に、当
該期間における配送員の稼働率を算出する（図中「man_hour_rate = man_hour / max_ man_hour_sum」）。そして、算出した配送員の稼働率があらかじめ設定された閾値以下の場合は（図中「if man_hour_rate <= man_hour_rate_threshold:」）、配送員の稼働率の条件が満たされたとする（図中「man_hour_rate_flag = True」）。また、当該期間のイン
センティブ（「incentive」）の値があらかじめ設定された閾値以下の場合は（図中「if incentive <= incentive_threshold:」）、インセンティブの条件が満たされたとする（
図中「incentive_flag = True」）。そして、上記の２つの条件がいずれも満たされた場
合にゴール条件が達成されたとみなす（図中「done = man_hour_rate_flag & incentive_flag」）。
該期間における配送員の稼働率を算出する（図中「man_hour_rate = man_hour / max_ man_hour_sum」）。そして、算出した配送員の稼働率があらかじめ設定された閾値以下の場合は（図中「if man_hour_rate <= man_hour_rate_threshold:」）、配送員の稼働率の条件が満たされたとする（図中「man_hour_rate_flag = True」）。また、当該期間のイン
センティブ（「incentive」）の値があらかじめ設定された閾値以下の場合は（図中「if incentive <= incentive_threshold:」）、インセンティブの条件が満たされたとする（
図中「incentive_flag = True」）。そして、上記の２つの条件がいずれも満たされた場
合にゴール条件が達成されたとみなす（図中「done = man_hour_rate_flag & incentive_flag」）。
【0067】
本変形例では、制御部１１は、取得した商品情報から算出される配送に必要な総人時に基づいて決定される報酬を、複数のインセンティブそれぞれに対して算出する強化学習によって行動モデルを生成し、生成した行動モデルを用いてシミュレーションを行う。具体的には、制御部１１は、上記のインセンティブの割合を示す値を下限から上限まで変更しながら、例えば０．０から１．０まで０．１ずつ増加させながらシミュレーションを繰り返す。ここで、制御部１１は、１エピソードのタイムステップ数を、商品情報ＤＢ２から取得した上記の各値の情報の対象期間の日数とし、各インセンティブの割合に対して１００エピソード実行した結果を基に、各インセンティブの割合に対するゴール条件達成までのタイムステップ数、配送員の稼働率について１００エピソードの平均値を算出する。例えば、商品情報ＤＢ２から過去３０日にわたる上記の各値の情報が取得される場合は、１エピソードのタイムステップ数は３０となる。制御部１１は、算出結果を記憶部１２に記憶したり、表示部１４に表示したり、通信部１５から外部装置に送信したりすることで、算出結果を出力する。
【0068】
ユーザは、予測装置１による算出結果を確認して、ＥＣサイトにおいてユーザがシミュレーションの対象となった商品を注文する際に、当該商品の配送指定日を変更することでユーザに付与されるインセンティブの大きさを決定することができる。したがって、変形例１によれば、ＥＣサイトにおいて上記インセンティブの大きさが、予測装置１によるシミュレーションによる算出結果を基に調整される。これにより、配送コスト最小化とインセンティブコスト最小化の２つの目標のバランスを取りつつ、ＥＣサイトにおいて当該商品の配送日の変更をユーザに促す場合に付与されるインセンティブの大きさの最適化を図ることができる。
【符号の説明】
【0069】
１ 予測装置
１１ 制御部
２ 商品情報ＤＢ
１１ 制御部
２ 商品情報ＤＢ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】