(57)【特許請求の範囲】
【請求項１】
ある拠点の複数の端末からの取引情報を収集するデータ収集部と、
前記取引情報に基づいて、前記複数の端末に共通する第１の成分と各端末に依存する第２の成分とを含む予測モデルを計算する学習部と、
前記予測モデルを用いて各端末の現金変化量を予測する予測部と、
を備え、
前記第１の成分が、前記拠点の総来客者数に関する第１の要素と、取引毎の現金変化量の予測に関する第２の要素とを含み、前記第２の成分が、ある来客者がある端末を使用する割合に関する第３の要素を含むことを特徴とする
ことを特徴とする計算サーバ。
【請求項２】
請求項１に記載の計算サーバにおいて、
前記学習部は、
前記第１の要素として、前記拠点のある時間帯の総来客者数を予測する第１の予測関数を計算し、
前記第２の要素として、前記拠点のある時間帯の取引毎の現金変化量を予測する第２の予測関数を計算し、
前記第３の要素として、前記拠点のある時間帯の総来客者数と端末毎の取引回数との間のマッピング関数を計算することを特徴とする計算サーバ。
【請求項３】
請求項２に記載の計算サーバにおいて、
前記第１の予測関数及び前記第２の予測関数は、外部要因情報の説明変数を含むことを特徴とする計算サーバ。
【請求項４】
請求項１に記載の計算サーバにおいて、
前記予測された各端末の現金変化量に基づいて運用計画を計算する運用計画計算部をさらに備え、
前記運用計画計算部は、現金輸送コスト及び調達コストの少なくとも１つのコストに基づいて、前記運用計画を修正することを特徴とする計算サーバ。
【請求項５】
請求項４に記載の計算サーバにおいて、
前記運用計画計算部は、あらかじめ登録されている制約情報を用いて、前記運用計画を修正することを特徴とする計算サーバ。
【請求項６】
請求項１に記載の計算サーバにおいて、
前記予測モデルが、ある地域の複数の拠点に共通する第３の成分と、前記地域の各拠点に依存する第４の成分をさらに含むことを特徴とする計算サーバ。
【請求項７】
請求項１に記載の計算サーバにおいて、
前記予測部は、前記現金変化量として、入金と出金を個別に予測することを特徴とする計算サーバ。
【請求項８】
計算サーバを用いて、ある拠点の各端末の現金変化量を予測する方法であって、
前記計算サーバが、前記拠点の複数の端末から取引情報を収集するデータ収集ステップと、
前記計算サーバが、前記取引情報に基づいて、前記複数の端末に共通する第１の成分と各端末に依存する第２の成分を含む予測モデルを計算する学習ステップと、
前記計算サーバが、前記予測モデルを用いて各端末の現金変化量を予測する予測ステップと、
を含み、
前記第１の成分が、前記拠点の総来客者数に関する第１の要素と、取引毎の現金変化量の予測に関する第２の要素とを含み、前記第２の成分が、ある来客者がある端末を使用する割合に関する第３の要素を含む
ことを特徴とする方法。
【請求項９】
請求項８に記載の方法において、
前記学習ステップは、
前記第１の要素として、前記拠点のある時間帯の総来客者数を予測する第１の予測関数を計算するステップと、
前記第２の要素として、前記拠点のある時間帯の取引毎の現金変化量を予測する第２の予測関数を計算するステップと、
前記第３の要素として、前記拠点のある時間帯の総来客者数と端末毎の取引回数との間のマッピング関数を計算するステップと、
を含むことを特徴とする方法。
【請求項１０】
請求項８に記載の方法において、
前記予測された各端末の現金変化量に基づいて運用計画を計算する運用計画計算ステップをさらに含み、
前記運用計画計算ステップは、現金輸送コスト及び調達コストの少なくとも１つのコストに基づいて、前記運用計画を修正することを含むことを特徴とする方法。
【請求項１１】
請求項１０に記載の方法において、
前記運用計画計算ステップは、あらかじめ登録されている制約情報を用いて、前記運用計画を修正することを含むことを特徴とする方法。
【請求項１２】
ある地域の各拠点の複数の端末からの取引情報を収集するデータ収集部と、
前記取引情報に基づいて、各拠点の前記複数の端末に共通する第１の成分と前記地域の各拠点に依存する第２の成分とを含む予測モデルを計算する学習部と、
前記予測モデルを用いて各拠点の現金変化量を予測する予測部と、
を備え、
前記第１の成分が、前記地域の総来客者数に関する第１の要素と、取引毎の現金変化量の予測に関する第２の要素とを含み、前記第２の成分が、前記地域全体の総来客者数に対する各拠点の総来客者数の割合に関する第３の要素を含む
ことを特徴とする計算サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末の中の現金残高を予測するための計算サーバ及び方法に関する。
【背景技術】
【０００２】
金融機関などで運用するＡＴＭやＣＤなどの自動現金取引端末、又は銀行窓口テラー用の窓口端末などでは、取引に備えて予め現金の充填が必要となる。また、これらの端末では、取引により、端末内の現金額が常に変動することになる。自動現金取引端末内の現金は、金融市場から何らかの方法で調達されたと捉える事ができ、調達コスト（金利コスト）がかかることになる。したがって、出来る限り端末内には現金を詰めないことが望ましい。
【０００３】
一方、端末内に詰める現金が少ないと、現金切れが起こる時期が早まり、現金輸送の回数が増えることになる。これにより、現金輸送に絡むコスト（現金輸送コスト）が増加する。したがって、どの程度の現金が各端末で必要となるかを精緻に予測し、予測結果に応じて必要十分な現金を端末に充填することで、調達コストと現金輸送コストを抑えることが望まれる。従来の現金の残高の予測方法としては特許文献１がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−１６７９３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来の現金需要予測法は、端末毎に独立に、端末の過去の残高の変化の履歴から現金残高を予測する構成を取っていた。現金残高の予測という観点からは、過去の現金残高の履歴データが多いほど、予測精度が高まる。金融機関の支店などでは複数の端末を有していることが多く、同一拠点の複数の端末のデータを用いて、現金残高を予測することが望ましいと考えられる。
【０００６】
金融機関の支店（拠点）又はある地域に設置されている複数の端末は、類似の現金残高の変化傾向を示す場合がある。これは、端末内の残高が、複数の端末間で共通する要因に基づいて変動する場合があるためである。一方、同じ拠点又は同じ地域でも、端末が設置されている場所が異なるため、使用傾向に違いが出ることも想定される（例えば、支店の入口に近い端末や、駅の近くに設置された端末などは使われ易い傾向にある）。これは、端末内の残高が、各端末に依存する要因（例えば、端末の位置）に基づいて変動する場合があるためである。従来では端末間で共通する要因と各端末に依存する要因とを分けて考えておらず、現金残高の予測の精度が十分ではなかった。
【０００７】
そこで、本発明は、複数の端末のデータを利用する場合において、端末間で共通する要因と各端末に依存する要因とを考慮して端末内の現金残高を予測する技術を提供する。
【課題を解決するための手段】
【０００８】
例えば、上記課題を解決するために、特許請求の範囲に記載の構成を採用する。本願は上記課題を解決する手段を複数含んでいるが、その一例をあげるならば、ある拠点の複数の端末からの取引情報を収集するデータ収集部と、前記取引情報に基づいて、前記複数の端末に共通する第１の成分と各端末に依存する第２の成分とを含む予測モデルを計算する学習部と、前記予測モデルを用いて各端末の現金変化量を予測する予測部と、を備える計算サーバが提供される。
【０００９】
他の例によれば、計算サーバを用いて、ある拠点の各端末の現金変化量を予測する方法であって、前記計算サーバが、前記拠点の複数の端末から取引情報を収集するデータ収集ステップと、前記計算サーバが、前記取引情報に基づいて、前記複数の端末に共通する第１の成分と各端末に依存する第２の成分を含む予測モデルを計算する学習ステップと、前記計算サーバが、前記予測モデルを用いて各端末の現金変化量を予測する予測ステップと、を含む方法が提供される。
【００１０】
また、他の例によれば、ある地域の各拠点の複数の端末からの取引情報を収集するデータ収集部と、前記取引情報に基づいて、各拠点の前記複数の端末に共通する第１の成分と前記地域の各拠点に依存する第２の成分とを含む予測モデルを計算する学習部と、前記予測モデルを用いて各拠点の現金変化量を予測する予測部と、を備える計算サーバが提供される。
【発明の効果】
【００１１】
本発明によれば、複数の端末のデータを利用する場合において、端末間で共通する要因と各端末に依存する要因とを考慮し、高精度に現金残高を予測することが可能となる。
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の、課題、構成及び効果は、以下の実施例の説明により明らかにされる。
【図面の簡単な説明】
【００１２】
【図１】第１実施例における現金残高予測システムの構成図である。
【図２】第１実施例における計算サーバの構成図である。
【図３】端末設置拠点の端末レイアウト例である。
【図４】第１実施例における計算サーバの学習部の機能ブロック図である。
【図５】第１実施例における学習フローを示すフローチャートである。
【図６】第１実施例における計算サーバの予測部及び運用計画計算部の機能ブロック図である。
【図７】第１実施例における予測フロー及び運用計画計算フローを示すフローチャートである。
【図８】端末毎の取引回数を時系列で示した例である。
【図９】予測結果のフォーマットの一例である。
【図１０】第２実施例における学習フローを示すフローチャートである。
【発明を実施するための形態】
【００１３】
以下、添付図面を参照して本発明の実施例について説明する。なお、添付図面は本発明の原理に則った具体的な実施例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。
【００１４】
［第１実施例］
以下の実施例は、銀行などの金融機関のＡＴＭ／ＣＤなどの端末の現金変化量を予測する機能を提供する。また、以下の実施例は、端末への現金充填量、配送タイミングの運用計画の最適化の機能も提供する。
【００１５】
ある金融機関の支店（拠点）は、複数の端末を備える。この場合において、各端末の現金残高の予測モデルを、複数の端末間に共通する第１の成分と、各端末に依存する第２の成分とを用いて計算する。上記の第１の成分が、ある拠点の総来客者数に関する要素と、取引毎の現金変化量の予測値に関する要素を含む。上記の第２の成分が、ある来客者が該当の端末を使用する割合（取引頻度）に関する要素を含む。予測モデルを用いて、未来の各端末の現金残高が予測される。
【００１６】
以下の実施例では、ある拠点の総来客者数、ある来客者が該当の端末を使用する割合（取引頻度）、及び、取引毎の現金変化量の予測値の３つの成分の積により、各端末の現金残高の予測値を計算する。総来客者数は、その支店に存在する全ての端末の取引の総和として定義する。取引毎の現金変化量は、端末には依存しないで決まる因子と考えることができる。したがって、複数の端末の過去の履歴を用いて予測することで、従来の構成（端末毎に独立に予測する技術）と比べて、高精度に予測が可能となる。一方で、取引頻度は、各端末に依存して決まる因子と考えることができる。したがって、端末毎に推定することが望まれる。
【００１７】
図１は、第１実施例における現金残高予測システムの構成図である。本例では、複数の端末設置拠点１〜Ｎが設けられている。各端末設置拠点は、複数の端末を備える。例えば、端末設置拠点１は、複数の端末１０１−１−１〜Ｍ１を備える。ここで、各端末は、ＡＴＭやＣＤなどの現金の入金もしくは出金が行われる端末であるとする。現金残高予測システムは、計算サーバ１０２を備える。計算サーバ１０２は、各拠点の各端末から取引情報を収集し、現金残高の予測を行うものである。ここで、取引情報は、各端末の時間帯毎の取引回数、各端末の時間帯毎の残高情報などを含む。時間帯の単位は、例えば１時間を単位としてもよいし、１０分単位としてもよい。また、時間帯は、午前／午後という単位で分けてもよい。残高情報は、前の時間帯を基準とした残高の変化量としてもよい。
【００１８】
図２は、第１実施例における計算サーバ１０２の構成図である。計算サーバ１０２は、入力部２０１、出力部２０２、ＣＰＵ２０３、メモリ２０４及び記憶媒体２０５を有する。入力部２０１は、マウス、キーボードなどのヒューマンインタフェースであり、計算サーバ１０２への入力を受け付ける。出力部２０２は、計算サーバ１０２による演算結果を出力するディスプレイやプリンタである。
【００１９】
記憶媒体２０５は、計算サーバ１０２による各種処理を実現するプログラム、及び、各種処理の実行結果等を格納する記憶装置であり、例えば、不揮発性記憶媒体（磁気ディスクドライブ、不揮発性メモリ等）である。
【００２０】
メモリ２０４には、記憶媒体２０５に格納されているプログラムが展開される。ＣＰＵ２０３は、メモリ２０４にロードされたプログラムを実行する演算装置である。以下に説明する処理及び演算は、ＣＰＵ２０３が実行する。
【００２１】
本実施例の計算サーバ１０２は、一つの計算機で、又は、論理的あるいは物理的に構成された複数の計算機で構成されてもよい。また、計算サーバ１０２の各種処理は、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。
【００２２】
ＣＰＵ２０３によって実行されるプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介して計算サーバ１０２に提供されてもよい。このため、計算サーバ１０２は、リムーバブルメディアを読み込むインタフェースを備えてもよい。
【００２３】
計算サーバ１０２は、データベース２０６を備える。データベース２０６は、取引情報記憶部２２１と、学習パラメータ記憶部２２２と、運用制約情報記憶部２２３とを備える。
【００２４】
記憶媒体２０５は、各種プログラムとして、データ収集部２１１と、学習部２１２と、予測部２１３と、運用計画計算部２１４とを備える。データ収集部２１１は、各端末設置拠点の各端末から、時間帯毎に取引情報を収集し、収集した取引情報を取引情報記憶部２２１に格納する。データ収集部２１１は、取引情報を、端末を識別するための識別情報（端末ＩＤ）とともに収集する。また、データ収集部２１１は、取引情報として、取引の種類（入金／出金）及び取引量を収集してもよい。さらに、データ収集部２１１は、端末ＩＤとともに端末の位置情報も収集してもよい。なお、計算サーバ１０２側に、各端末ＩＤと位置情報とを紐づけた情報があらかじめ格納されていてもよく、この場合、データ収集部２１１は、位置情報を収集しなくてもよい。
【００２５】
学習部２１２は、取引情報記憶部２２１に格納されている過去の取引情報（現時点までの取引情報）を用いて学習を行うものである。ここで、「学習」とは、後述する予測モデルを計算することを意味する。学習部２１２は、計算された予測モデルのパラメータを、学習パラメータ記憶部２２２に格納する。
【００２６】
予測部２１３は、学習部２１２によって計算された予測モデルを用いて、各端末の将来の残高量を計算する。予測する残高量は、任意の時期に関するものでよく、例えば、各端末の翌日の現金残高量でもよいし、各端末の１週間後の現金残高量でもよい。
【００２７】
運用計画計算部２１４は、予測部２１３によって計算された各端末の将来の残高量から運用計画を計算する。ここで「運用計画」とは、端末毎の現金充填量及び配送タイミングを意味する。現金充填量は、例えば、端末内のカセット毎に詰める現金枚数及び現金の種類である。配送タイミングは、各拠点の端末への配送のタイミングを意味する。例えば、配送タイミングは、翌日配送するかどうか、または１週間の内いつ配送に行くかという情報である。
【００２８】
運用計画計算部２１４は、現金輸送コスト及び調達コストの少なくとも１つのコストを計算する。さらに、運用計画計算部２１４は、運用制約情報記憶部２２３に予め格納されている制約情報及び上述したコストを考慮して運用計画を修正し、修正した運用計画を出力する。ここで「制約情報」とは、運用計画を決定する際に制約となる情報であり、例えば、端末毎の現金充填量や配送タイミングに関する制約情報である。例えば、制約情報としては、各端末で維持されるべき最低限の現金充填量の情報、月に少なくとも１回は配送するなどの情報である。
【００２９】
図３は、ある端末設置拠点の端末レイアウト例である。複数の端末３０１−１〜３０１−６は、それぞれ出入口から異なる距離に設置されている。したがって、閑散時間帯であれば、入口から近い距離の端末（例えば、端末３０１−５）が頻繁に使用されることが想定される。また、一方で繁忙期については、全ての端末が同様の頻度で使われることが想定される。このように、端末の使われやすさは端末の設置位置に依存して異なり、各端末の使用傾向も混雑状況に依存して変化する。本実施例では、この性質に着目し、端末の使われやすさを端末設置拠点全体の混雑度合いに依存して変化する変数であるとして推定する。
【００３０】
図４は、計算サーバ１０２の学習部２１２の機能ブロック図である。学習部２１２は、学習ブロック４０１を備える。学習ブロック４０１は、取引情報記憶部２２１に格納されている過去の取引情報、及び、データ収集部２１１が収集した直近の取引情報を受け取り、これらの取引情報を用いて予測モデルの各種パラメータを学習する。学習ブロック４０１は、予測モデルのパラメータを学習パラメータ記憶部２２２に格納する。
【００３１】
図５は、学習ブロック４０１における学習フローを示すフローチャートである。以後の説明では、図４の機能ブロックを主語として説明を行うが、プログラムはＣＰＵ２０３によって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、ＣＰＵ２０３を主語とした説明としてもよい。
【００３２】
学習ブロック４０１は、処理を開始する（５０１）。次に、学習ブロック４０１は、入力された各端末毎の取引情報を元に、拠点毎の総来客者数を算出する（５０２）。ここで、「総来客者数」とは各拠点の各時間帯毎の取引総数とする。学習ブロック４０１は、各拠点の取引総数を時間帯毎に算出する。したがって、算出した総来客者数は、拠点毎、時間毎に１つの値を持つことになる。
【００３３】
次に、学習ブロック４０１は、端末毎の取引回数と総来客者数との間のマッピング関数の推定を行う（５０３）。まず、学習ブロック４０１は、端末毎の取引回数を、時間帯毎に算出する。また、既に算出してある時間帯毎、拠点毎の総来客者数とのマッピング関数を、例えば以下のように定義する。
【００３４】
(数１)
端末毎のある時間帯の取引回数  ＝  拠点毎のある時間帯の総来客者数  ×  Ｇ
【００３５】
ここで、Ｇを、拠点毎の総来客者数に対する端末毎の取引回数の比率としてもよく、時間に依存しない何らかの関数として定義してもよい。学習ブロック４０１は、端末毎の取引回数及び拠点毎の総来客者数から、Ｇを、例えば最小二乗法により決定してもよい。
【００３６】
図８は、端末毎の取引回数を時系列で示した例である。図８に示すように、ある拠点において総来客者数が少ない場合、その拠点の入口近くの端末が使われやすくなるのに対して、繁忙期はほぼ全ての端末が使われている状態になる。つまり、繁忙期において、Ｇは、各端末に依存しない値に近づくことが想定される。したがって、Ｇを、総来客者数に依存する関数Ｇ（総来客者数）として推定するような構成を取っても良い。言い換えれば、Ｇを、時間に依存する関数として定義してもよい。この例において、Ｇは、時間によって変化する総来客者数を変数とする。
【００３７】
この場合、学習ブロック４０１は、線形モデル、ニューラルネットワークモデル、カーネル関数などを用いてＧを設定してもよい。線形モデルであれば、最小二乗法を用いてＧを推定してもよい。また、シグモイド関数モデルであれば、ニューラルネットワークモデルを用いてＧを推定してもよい。また、カーネル関数であれば、サポートベクター回帰などを活用してＧを推定してもよい。
【００３８】
次に、学習ブロック４０１は、総来客者数の予測式のパラメータを計算する（５０４）。例えば、予測式を以下のように定義する。
【００３９】
(数２)
総来客者数（ｔ＋Ｄ、Ａ拠点）＝ｆ（総来客者数（ｔ、Ａ拠点）、  総来客者数（ｔ−１、Ａ拠点）、・・・）
【００４０】
上記の式によれば、Ａ拠点における時間帯ｔのＤ単位時間先の総来客者数を、関数ｆにｔ時間帯までのＡ拠点での総来客者数を入力することによって予測することができる。ｆは説明変数から予測値を算出する予測関数である。予測関数ｆは、例えば、線形モデル、シグモイド関数モデル、カーネル関数などを使用して定義される。
【００４１】
数２の式は、総来客者数の自己回帰モデルとなっているが、例えば、Ｄ単位時間先の天候やＤ単位時間先の曜日、もしくは上旬であるか中旬か下旬かによっても総来客者数は変わることが想定される。このようなことを考慮し、予測関数ｆの中に上記の事項に対応する説明変数を増やすような構成を取ってもよい。以降では、天候や曜日などの因子を「外部要因情報」と称する。
【００４２】
予測関数ｆの学習は、線形モデルであれば、最小二乗法を活用して行ってもよい。また、シグモイド関数モデルであれば、予測関数ｆの学習は、ニューラルネットワークモデルを活用して行ってもよい。また、カーネル関数であれば、予測関数ｆの学習は、サポートベクター回帰などを活用して行ってもよい。
【００４３】
次に、学習ブロック４０１は、取引毎の現金変化量を推定する（５０５）。時間帯毎に、Ａ拠点内の全ての端末の取引毎の現金変化量の総和（Ａ１）を取る。また、時間帯毎の拠点内の全ての端末の取引数の総和（Ｂ１）を取る。一例として、学習ブロック４０１は、Ａ１をＢ１で割った値を取引毎の現金変化量として算出する。
【００４４】
次に、学習ブロック４０１は、取引毎の現金変化量の予測式のパラメータを計算する（５０６）。例えば、予測式を以下のように定義する。
【００４５】
(数３)
取引毎の現金変化量（ｔ＋Ｄ、Ａ拠点）＝ｈ（ｔ＋Ｄ時点の曜日、ｔ＋Ｄ時点の天候、ｔ＋Ｄ時点がボーナス支給日かどうか、・・・）
【００４６】
上記の式によれば、Ａ拠点における時間帯ｔのＤ単位時間先の取引毎の現金変化量を、関数ｈにｔ＋Ｄ時点での各種情報を入力することによって予測することができる。ｈは説明変数から予測値を算出する予測関数である。予測関数ｈは、例えば、線形モデル、シグモイド関数モデル、カーネル関数などを使用して定義される。取引毎の現金変化量は、顧客がどの程度現金を必要とするかによって決まるため、曜日、天候、ボーナス支給日といった現金需要に影響を及ぼす外部要因情報で推定する。なお、予測関数ｈに関して上述以外の説明変数を追加してもよい。
【００４７】
予測関数ｈの学習は、線形モデルであれば、最小二乗法を活用して行ってもよい。また、シグモイド関数モデルであれば、予測関数ｈの学習は、ニューラルネットワークモデルを活用して行ってもよい。また、カーネル関数であれば、予測関数ｈの学習は、サポートベクター回帰などを活用して行ってもよい。
【００４８】
予測関数Ｇ、ｆ、ｈを推定した後、学習ブロック４０１は、予測関数Ｇ、ｆ、ｈの形状を決定するパラメータを予測モデルのパラメータとして学習パラメータ記憶部２２２に格納し、処理を終了する（５０７）。
【００４９】
図６は、計算サーバ１０２の予測部２１３及び運用計画計算部２１４の機能ブロック図である。また、図７は、図６の構成における予測フロー及び運用計画計算フローを示すフローチャートである。
【００５０】
予測部２１３の予測ブロック６０１は、処理を開始する（７０１）。現金残高の予測量算出は、任意のタイミングで開始してよい。処理の開始は、例えば、入力部２０１からの入力を介して行ってもよい。現金残高の予測量算出は、各曜日毎に行ってもよいし、また各曜日の各時間帯毎に行うような構成を取ってもよい。
【００５１】
予測ブロック６０１は、データ収集部２１１及び取引情報記憶部２２１から現時点までの取引情報を入力として受け取る。予測ブロック６０１は、例えば、Ａ拠点での各端末の現金残高需要の予測値を計算する（７０２）。ここでの予測値とは、例えば翌日の各端末の現金残高であったり、１週間後までの各曜日の現金残高であったり、各曜日の各時間帯毎の現金残高であったりすることを想定する。
【００５２】
予測ブロック６０１は、学習パラメータ記憶部２２２に格納されている予測関数Ｇ、ｆ、ｈのパラメータを用いて、各端末のＤ単位時間先の現金変化量を以下のように計算する。
【００５３】
(数４)
現金変化量（ｔ＋Ｄ、Ａ拠点のある端末）  ＝  Ｇ  ×  ｈ×  ｆ
【００５４】
ここで、予測関数Ｇ、ｈ、ｆの値を計算するためには、各種説明変数を要する。例えば、ｔ＋Ｄ時点の天候という説明変数であれば、予測ブロック６０１は、ｔ＋Ｄ時点の天気予報を、ネットワークを介して図示しない外部のリソースから取得してもよい。予測ブロック６０１は、外部リソースなどを用いて説明変数の値を取得する。なお、予測関数Ｇが総来客者数に依存するようにモデル化されている場合は、予測関数Ｇに与える総来客者数のパラメータは予測関数ｆで推定した値を用いればよい。
【００５５】
図９は、単位時間毎に各端末の現金変化量を算出した例である。ここでは、単位時間帯Ｄを１日とした。図９のフォーマットでは、端末毎に、１週間後までの残高変化量を、現在の各端末の現金残高からの差分値として出力されている。図９の数値は、例えば、ある紙幣の枚数としてもよいし、実際の金額など任意に設定すればよい。予測ブロック６０１は、図９のフォーマットを、出力データとして運用計画計算部２１４の運用計画初期化ブロック６０２へ出力する。
【００５６】
次に、運用計画初期化ブロック６０２は、現金運用計画の初期案を算出する（７０３）。運用計画初期化ブロック６０２は、例えば、図９のフォーマットを用いて、現金切れを起こさない範囲で、現金搬送回数を最小化するといった基準で、現金運用計画の初期案を算出する。この現金運用計画には、どの端末に、いつ、どの程度現金を詰めるか、及び回収するかの情報が含まれる。運用計画初期化ブロック６０２は、現金運用計画の初期案の情報をコストシミュレータ６０３に出力する。
【００５７】
次に、コストシミュレータ６０３は、現金運用計画の初期案の情報を用いてコストを計算する（７０４）。例えば、コストシミュレータ６０３は、現金運用計画の初期案の情報を用いて、現金輸送コストを計算する。なお、コストシミュレータ６０３は、調達コストを計算してもよい。
【００５８】
次に、計算されたコストを最小化するために、運用計画修正ブロック６０４が、現金運用計画を修正する（７０５）。具体的には、運用計画修正ブロック６０４は、コストシミュレータ６０３で計算されるコスト値（現金輸送コスト及び調達コストの少なくとも１つのコスト）を下に、準ニュートン法を用いて、どの端末に、いつ、どの程度現金を詰めるか、及び回収するかを変更する。準ニュートン法ではパラメータとコスト値のマッピング関数さえあれば、パラメータの最適化を行うことができる。ここでは、パラメータは、どの端末に、いつ、どの程度現金を詰めるか、及び回収するかという情報である。本構成では、マッピング関数はコストシミュレータ６０３となる。なお、運用計画の最適化は、準ニュートン法に限定されず、例えば、混合整数計画法など、他の公知の最適化手法を用いてもよい。
【００５９】
このとき、運用計画修正ブロック６０４は、運用制約情報記憶部２２３の情報を用いて、現金運用計画を修正する。運用制約情報記憶部２２３には、運用計画を決定する際に制約となる情報があらかじめ格納されている。例えば、端末毎に月に少なくとも１度は配送する必要があるなどの制約情報がある場合、月に１度配送することを制約とした制約付き準ニュートン法により、現金運用計画を最適化することが可能となる。なお、混合整数計画法を用いる場合は、運用計画修正ブロック６０４は、制約付き混合整数計画法により、現金運用計画を修正すればよい。運用計画修正ブロック６０４は、修正した運用計画を修正終了判定ブロック６０５へ出力する。
【００６０】
次に、修正終了判定ブロック６０５は、運用計画の修正を終了するかを判定する（７０６）。運用計画の修正を終了する場合、修正終了判定ブロック６０５は、修正した運用計画を出力部２０２に出力し（７０７）、処理を終了する（７０８）。一方、運用計画の修正を継続する場合、ステップ７０５へ戻る。
【００６１】
修正終了判定ブロック６０５での判定は、例えば、運用計画修正ブロック６０４における修正回数が所定回数以上なされたかに基づいて行ってもよい。また、上記判定は、準ニュートン法におけるパラメータ修正量が所定量を下回ったか（すなわち、パラメータの修正量が収束した）に基づいて行ってもよい。
【００６２】
以上の実施例によれば、端末に依存する因子として取引頻度を端末毎に推定するとともに、取引毎の現金残高の変動量の予測値、及び総来客者数を端末に依存しない因子として推定する構成を取ることで、複数の端末のデータを効率的に利用して現金残高を推定可能となる。
【００６３】
現金残高予測において、同じ残高推移傾向を示す同一拠点の端末の情報を用いることは予測精度向上にかなうが、同一拠点といっても、端末が設置されている場所が異なるため、例えば入口近くの端末は、使われやすいなど、使用傾向に違いが出ることが想定される。しかし、従来では、複数の端末のデータを利用する場合でも、各端末毎に独立して現金残高の予測がされるだけであった。これに対して、本実施例では、複数の端末のそれぞれの使用傾向の違いを上手く考慮して、現金残高を推定可能となる。本実施例では、同一拠点の複数の端末のデータを活かすことにより、端末毎に独立に現金残高を予測する構成と比較して、高精度に現金残高を予測することが可能となる。したがって、調達コストと現金輸送コストを上手く抑えることができなかった。
【００６４】
上述の例では、端末ＩＤを用いて端末毎に現金変化量を予測したが、端末の位置情報を用いてもよい。この場合、予測部２１３は、端末設置拠点内のどの位置にある端末がどの程度の現金変化量があるかを計算することができる。
【００６５】
上述の例では、入金及び出金のまとめて扱った現金変化量として予測を行ったが、入金と出金を分けて予測してもよい。この場合、データ収集部２１１は、取引情報として、取引の種類（入金／出金）及び取引量を収集する。これらの情報を用いて、学習部２１２は、取引の種類ごとに予測モデルを作成すればよい。これにより、予測部２１３は、ある拠点のある時間帯の端末毎の入金と、ある拠点のある時間帯の端末毎の出金とを個別に予測することができる。
【００６６】
［第２実施例］
以下の実施例では、現金残高情報の予測を地域全体の情報を用いて行う例を説明する。この例では、予測モデルが、ある地域の複数の拠点に共通する第３の成分と、地域の各拠点に依存する第４の成分をさらに含む。図１０は、第２実施例における学習部２１２の学習フローを示すフローチャートである。
【００６７】
学習ブロック４０１は、処理を開始する（１００１）。次に、学習ブロック４０１は、入力された各端末毎の取引情報を元に、地域全体の総来客者数を算出する（１００２）。ここで、「総来客者数」とは地域全体（以下では、Ａ地域として説明する）の各時間帯毎の取引総数とする。学習ブロック４０１は、各拠点の取引総数を時間帯毎に算出し、Ａ地域に属する全ての拠点の取引総数を算出する。これにより、時間帯毎のＡ地域の取引総数を得ることができる。
【００６８】
次に、学習ブロック４０１は、拠点毎の取引回数と地域全体（Ａ地域）の総来客者数との間のマッピング関数の推定を行う（１００３）。既に算出してある時間帯毎、地域毎の総来客者数とのマッピング関数を、例えば以下のように定義する。
【００６９】
(数５)
ある拠点のある時間帯の総来客者数  ＝  地域全体（Ａ地域）のある時間帯の総来客者数×Ｊ
【００７０】
ここで、Ｊを、地域全体の総来客者数に対する拠点毎の総来客者数の比率としてもよく、時間に依存しない何らかの関数として定義してもよい。学習ブロック４０１は、拠点毎の総来客者数、及び地域全体の総来客者数から、Ｊを、例えば最小二乗法により決してもよい。
【００７１】
また、繁忙期か閑散期かによって拠点毎に使用頻度は変化することが想定される。閑散期のＪは、拠点に依存する値（例えば、閑散期は、駅に近いなど利便性によって来客数が変動することが想定される）となる一方、繁忙期のＪは拠点によらない値に近づくことが想定される。したがって、Ｊを地域の総来客者数に依存する関数Ｊ（地域の総来客者数）として推定するような構成を取っても良い。この場合、学習ブロック４０１は、線形モデル、ニューラルネットワークモデル、カーネル関数などを用いてＪを設定してもよい。線形モデルであれば、最小二乗法を用いてＪを推定してもよい。また、シグモイド関数モデルであれば、ニューラルネットワークモデルを用いてＪを推定してもよい。また、カーネル関数であれば、サポートベクター回帰などを活用してＪを推定してもよい。
【００７２】
次に、学習ブロック４０１は、地域全体の総来客者数の予測式のパラメータを計算する（１００４）。例えば、予測式を以下のように定義する。
【００７３】
(数６)
地域全体の総来客者数（ｔ＋Ｄ、Ａ地域）＝ｆ（地域全体の総来客者数（ｔ、Ａ地域）、  地域全体の総来客者数（ｔ−１、Ａ地域）、・・・）
【００７４】
上記の式によれば、Ａ地域における時間帯ｔのＤ単位時間先の総来客者数を、関数ｆにｔ時間帯までのＡ地域での総来客者数を入力することによって予測することができる。ｆは説明変数から予測値を算出する予測関数である。予測関数ｆは、例えば、線形モデル、シグモイド関数モデル、カーネル関数などを使用して定義される。
【００７５】
数６の式は、総来客者数の自己回帰モデルとなっているが、例えば、Ｄ単位時間先の天候やＤ単位時間先の曜日、もしくは上旬であるか中旬か下旬かなどによっても、総来客者数は変わることが想定される。このような外部要因情報を考慮し、予測関数ｆの中に上記の事項に対応する説明変数を増やすような構成を取ってもよい。
【００７６】
予測関数ｆの学習は、線形モデルであれば、最小二乗法を活用して行ってもよい。また、シグモイド関数モデルであれば、予測関数ｆの学習は、ニューラルネットワークモデルを活用して行ってもよい。また、カーネル関数であれば、予測関数ｆの学習は、サポートベクター回帰などを活用して行ってもよい。
【００７７】
次に、学習ブロック４０１は、端末毎の取引回数と拠点の総来客者数との間のマッピング関数Ｇの推定を、第１実施例に示した方法と同一の方法により行う（１００５）。同様に、学習ブロック４０１は、取引毎の現金変化量算出を第１実施例に示した方法と同一の方法により行う（１００６）。さらに、学習ブロック４０１は、取引毎の現金変化量の予測関数ｈのパラメータ推定を第１実施例に示した方法と同一の方法により行う（１００７）。学習ブロック４０１は、予測関数Ｊ、ｆ、Ｇ、ｈの形状を決定するパラメータを予測モデルのパラメータとして学習パラメータ記憶部２２２に格納し、処理を終了する（１００８）。
【００７８】
次に、本実施例の予測ブロック６０１での処理について説明する。予測ブロック６０１は、学習パラメータ記憶部２２２に格納されている予測関数Ｊ、ｆ、Ｇ、ｈのパラメータを用いて、Ｄ単位時間先の現金変化量を以下のように計算する。
【００７９】
(数７)
現金変化量（ｔ＋Ｄ、Ａ地域）＝  Ｊ  ×Ｇ  ×  ｈ  ×  ｆ
【００８０】
このＤ単位時間先の現金変化量に基づいて運用計画を作成する処理については、第１実施例に示した方法と同一の方法で行う。
【００８１】
なお、各拠点内のＡＴＭ現金残高は同じ挙動を示すと仮定し、拠点内の全てのＡＴＭに関してＧの値を等しい値に設定してもよい。
【００８２】
また、本実施例では、地域全体の総来客者数から、各拠点の各端末の現金変化量を推定する例を説明したが、このように第１実施例と第２実施例の組み合わせに限定されない。例えば、端末毎の現金変化量を考慮にいれず、Ａ地域の各拠点ごとの現金変化量を算出してもよい。この場合、Ｇを用いずに、例えば、Ａ地域の各拠点の現金変化量は以下の式で定義してもよい。
【００８３】
(数８)
現金変化量（ｔ＋Ｄ）＝  Ｊ  ×  ｈ×  ｆ
【００８４】
以上の実施例によれば、地域全体の総来客者数から、各拠点の端末毎の現金変化量を推定することができる。また、地域全体の総来客者数から、各拠点の現金変化量を推定することができる。
【００８５】
本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。上記実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることもできる。また、ある実施例の構成に他の実施例の構成を加えることもできる。また、各実施例の構成の一部について、他の構成を追加・削除・置換することもできる。
【００８６】
上述した処理は、それらの機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【００８７】
ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できる。更に、汎用目的の多様なタイプのデバイスが使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益である場合もある。つまり、上述した処理の一部又は全部が、例えば集積回路等の電子部品を用いたハードウェアにより実現されてもよい。
【００８８】
さらに、上述の実施例において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。
【符号の説明】
【００８９】
１０１−１−１、・・・、１０１−Ｎ−ＭＮ  ：端末
１０２      ：計算サーバ
２０１      ：入力部
２０２      ：出力部
２０３      ：ＣＰＵ
２０４      ：メモリ
２０５      ：記憶媒体
２０６      ：データベース
２１１      ：データ収集部
２１２      ：学習部
２１３      ：予測部
２１４      ：運用計画計算部
２２１      ：取引情報記憶部
２２２      ：学習パラメータ記憶部
２２３      ：運用制約情報記憶部
４０１      ：学習ブロック
６０１      ：予測ブロック
６０２      ：運用計画初期化ブロック
６０３      ：コストシミュレータ
６０４      ：運用計画修正ブロック
６０５      ：修正終了判定ブロック
【図１】
0006366471.tif 000002
【図２】
0006366471.tif 000003
【図３】
0006366471.tif 000004
【図４】
0006366471.tif 000005
【図５】
0006366471.tif 000006
【図６】
0006366471.tif 000007
【図７】
0006366471.tif 000008
【図８】
0006366471.tif 000009
【図９】
0006366471.tif 000010
【図１０】
0006366471.tif 000011