予め定めた期間ごとに計器の値を受信して保持する検針値収集処理部と、前記検針値収集処理部が記録した計器の値に基づいて、月次処理で、使用量を算出するとともに、予め定めた時間帯ごとの重複した使用量を算出して保持する使用量算出処理部と、シミュレーション要求を受信したとき、対象契約を構成する時間帯に応じて、前記時間帯ごとの重複した使用量を参照して、料金計算を行なう料金計算部と、からなる料金シミュレーション装置。請求項1に記載の料金シミュレーション装置であって、新規契約種別で、料金シミュレーションを行なうとき、前記使用量算出部は、新たな時間帯の使用量を算出して保持することを特徴とする料金シミュレーション装置。コンピュータを、予め定めた期間ごとに計器の値を受信して保持する検針値収集処理部、前記検針値収集処理部が記録した計器の値に基づいて、月次処理で、使用量を算出するとともに、予め定めた時間帯ごとの重複した使用量を算出して保持する使用量算出処理部、シミュレーション要求を受信したとき、対象契約を構成する時間帯に応じて、前記時間帯ごとの重複した使用量を参照して、料金計算を行なう料金計算部、として機能させるための料金シミュレーションプログラム。近年、電力網の安全確保や電力の有効利用のためにスマートグリッドが注目されている。今後、各需要家において電力メーターの電子化が進み、計量器の目盛りの値を一定間隔30分などで自動的に読み取る自動検針が普及すると考えられる。これにより、電力会社は、様々な時間帯で料金が異なるプランを設定することができる。すなわち、将来的に電力会社が提供する契約種別は、より多種多様なものになると予想される。時間帯によって契約単価が異なる料金シミュレーションを行なう場合、計算対象の契約種別を構成する各時間帯ごとの使用量の算出が必要となる。しかし、特許文献1では、膨大に蓄積される自動検針値を基にした時間帯別使用量の再計算処理の負荷が考慮されておらず、将来的に契約種別が増えた場合に処理速度が増大すると考えられる。これにより、電力需要家がホームページから料金シミュレーションを行なったときに、レスポンス時間が増大する。本願発明では、月に一度、夜間バッチ処理にて需要家の月間使用量を算出すると同時に、需要家自身が締結中の契約とは関係のない時間帯を含めた各種時間帯別使用量をあらかじめ算出する。算出対象とする時間帯は、契約情報には依存しない形で時間帯ごとにまとめ、パラメータを定義する。シミュレーション要求があった場合は、シミュレーション対象の契約情報から契約を構成する時間帯と単価等を判定し、算出済みの各種時間帯別使用量を参照して料金計算を実行する。上述した課題は、予め定めた期間ごとに計器の値を受信して保持する検針値収集処理部と、検針値収集処理部が記録した計器の値に基づいて、月次処理で、使用量を算出するとともに、予め定めた時間帯ごとの重複した使用量を算出して保持する使用量算出処理部と、シミュレーション要求を受信したとき、対象契約を構成する時間帯に応じて、時間帯ごとの重複した使用量を参照して、料金計算を行なう料金計算部と、からなる料金シミュレーション装置により、達成できる。また、コンピュータを、予め定めた期間ごとに計器の値を受信して保持する検針値収集処理部、検針値収集処理部が記録した計器の値に基づいて、月次処理で、使用量を算出するとともに、予め定めた時間帯ごとの重複した使用量を算出して保持する使用量算出処理部、シミュレーション要求を受信したとき、対象契約を構成する時間帯に応じて、時間帯ごとの重複した使用量を参照して、料金計算を行なう料金計算部、として機能させるための料金シミュレーションプログラムにより、達成できる。本発明によれば、時間帯別にあらかじめ使用量を算出しておくことにより、料金シミュレーション時に、膨大に蓄積された自動検針値を基にした使用量再計算が不要となるため、主にWeb画面から要求される料金シミュレーションにも素早く応答することができる。以下、本発明の実施の形態について、実施例を用い図面を参照しながら詳細に説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。図1を参照して、自動検針料金シミュレーションシステムを説明する。図1において、自動検針料金シミュレーションシステム100は、計器10と、ネットワーク20と、バッチサーバ30と、DBサーバ40と、端末50と、Webアプリケーションサーバ60とから構成される。バッチサーバ30は、I/F31は、処理部35とから構成される。処理部35は、自動検針値収集処理部32と、使用量計算処理部33と、料金計算処理部34とを含む。Webアプリケーションサーバ60は、リクエスト処理部61と、シミュレーション処理実行部62とからなる。計器10は、一定間隔ここでは30分とするで自動的に目盛りの値を検針する。計器10は、ネットワーク20を介して、自動検針値をバッチサーバ30に送信する。I/F部31は、ネットワーク20から自動検針値を受信する。DBサーバ40は、後述する30分自動検針値70と、契約情報71と、月間使用量72と、算出対象時間帯パラメータ73と、時間帯別使用量74を格納する。端末50は、需要家がシミュレーション実行の指示と結果を確認するのに使用する。自動検針値収集処理部31は、日次処理にて自動検針値を収集し、計器ごとの1日分の自動検針値レコードを作成する。これを毎日繰り返すことにより、図3を参照して後述する30分自動検針値が計器ごとに蓄積する。さらに月に一度、バッチサーバ30は、1ヶ月分の30分自動検針値を集計し、月間使用量を算出する。図2を参照して、バッチサーバ30、DBサーバ40およびWebアプリケーションサーバ60のハードウェア構成を説明する。図2において、バッチサーバ30、DBサーバ40およびWebアプリケーションサーバ60は、中央処理装置CPU41と、メモリ42と、I/O43と、I/F44と、バス45とから構成される。CPUは、メモリ42上のプログラムを実行する。メモリ42は、I/O43で不揮発に記録されたプログラムをロードする。I/O43は、入力装置、出力装置、外部記憶装置である。I/F44は、通信インタフェースである。バス45は、CPU41、メモリ42、I/O43、I/F44を相互接続する。図2と図1の比較から明らかなように、バッチサーバ30、DBサーバ40およびWebアプリケーションサーバ60の内部処理部は、CPU41が実行するプログラムによって、実現されている。図3を参照して、DBサーバ40が保持する30分自動検針値70を説明する。図3において、30分自動検針値70は、計器ID701と、収集年月日702と、検針値703とからなる。検針値703は、24時間を30分ごとに区切った49の検針値を保持する。なお、検針値が49あるのは、前日24:00の検針値を当日00:00の検針値にコピーしているからである。図4を参照して、DBサーバ40が保持する契約情報71を説明する。図4において、契約情報71は、契約種別711と、契約名称712と、時間帯713と、単価714とから構成されている。なお、時間帯713と単価714は、3種類あり得る。契約種別711は、契約のIDである。契約名称712は、文字通り契約名称である。時間帯713は、電力消費の時間帯である。単価714は、当該時間帯のkWhr当たりの単価である。図5を参照して、DBサーバ40が保持する月間使用量72を説明する。図5において、月間使用量72は、契約番号721と、計器ID722と、今回検針日723と、時間帯724と、使用量725とから構成されている。なお、時間帯724と使用量725は、3種類あり得る。ここでは、1契約分しか図示していないが、図4との比較により、当該契約は、A契約であることが分かる。図6を参照して、DBサーバ40が保持する算出対象時間帯パラメータ73を説明する。図6において、算出対象時間帯パラメータ73は、時間帯番号731と、使用開始時刻732と、使用終了時刻733と、適用契約734とから構成されている。使用開始時刻732と使用終了時刻733の組み合わせは、契約A~契約Dをもっとも少ない数で分割した時間帯である。適用契約734は、その時間帯を利用する契約IDを保持する。図7を参照して、DBサーバ40が保持する時間帯別使用量74を説明する。図7において、時間帯別使用量74は、契約番号741と、計器ID742と、前回検針日743と、今回検針日744と、時間帯使用量745とから構成されている。なお、時間帯使用量745は、契約に無関係に時間帯番号001~時間帯番号008分まで保持する。図8を参照して、バッチサーバ30における月次処理を説明する。図8において、バッチサーバ30は、月次処理を開始すると、DBサーバ40から契約者の契約情報71と、30分自動検針値70を読み込んで、月間使用量計算を実施し、結果をDBサーバ40が保持する月間使用量72に記録するS31。バッチサーバ30は、DBサーバ40から算出対象時間帯パラメータ73を読み込んで、時間帯別使用量計算を実施し、結果をDBサーバ40の時間帯別使用量74に記録してS32、終了する。具体的に説明すると、図4に示すような契約があり、時間帯別契約Aを締結しているとする。この場合、1ヶ月で23:00~07:00の時間帯に使用した使用量、07:00~23:00の時間帯に使用した使用量をそれぞれ算出する必要がある。月間使用量計算S31は、該当する時間帯の30分自動検針値70を参照し、月間使用量を算出する。図5が算出された月間使用量である。図5に示すように算出された月間使用量は、需要家が締結している時間帯別契約Aに対する使用量である。そのため、別の契約情報での料金をシミュレーション計算する場合、再度各時間帯ごとの月間使用量を算出しなければならない。そこでバッチサーバ30は、料金シミュレーション実行時に月間使用量の再計算を避けるために、月間使用量計算実行後に時間帯別使用量計算を実行する。時間帯別使用量計算は、算出対象時間帯パラメータ73を参照し、月間使用量を算出する時間帯を取得し、時間帯ごとに月間使用量を算出して時間帯別使用量74を登録する。算出対象時間帯パラメータ73は、図6に示すように、月間使用量を算出する時間帯を定義する。このパラメータに定義された時間帯ごとの月間使用量をあらかじめ算出し、料金シミュレーション実行時には算出済みの時間帯別使用量を参照して各契約種別に対する料金計算を行なうことにより、月間使用量の再計算を避けることができる。一般的に電気は夏場の暑い時期に消費量が大きく、1日の中でも午後2時ごろをピークとして消費量は変化する。このように電力消費量は、季節や時間帯によって変化することから、電力会社は夏季やその他季、時間帯によって料金が異なる契約プランを提供している。そのため、年間を通した使用量でシミュレーションを行ないたいという需要家の要望が考えられるため、算出した時間帯別使用量は過去1年間分のデータを保持する。図9を参照して、料金シミュレーション時の処理を説明する。図9において、需要家は、電力会社のホームページから料金シミュレーションを行なう。このとき需要家は、シミュレーション計算を行ないたい実績月と契約種別の指定を行なう。実績月の指定は単独月や連続した複数月の指定などを可能とする。需要家は様々な料金プランでの比較を行ないたいと考えられるため、契約種別についても複数の指定を可能とする。具体的には、時間帯別契約Aを締結している需要家が過去のある月の実績使用量を基に時間帯別契約Bの料金シミュレーションを実施する。需要家の操作により、端末50は、電力会社のホームページから料金シミュレーションを行ないたい実績月と契約種別の指定を行ない、Webアプリケーションサーバ60に対してシミュレーション要求を送信するS81。シミュレーション要求を受け取ったWebアプリケーションサーバ60は、DBサーバ40から契約情報71を受け取って、契約種別判定を実行するS82。Webアプリケーションサーバ60は、DBサーバ40から時間帯別使用量74を受け取るS83。Webアプリケーションサーバ60は、料金計算に必要な時間帯別使用量がそろっているか判定するS84。NOのとき、バッチサーバ30は、DBサーバ40か30分自動検針値70を受け取って、不足時間帯使用量計算を実施して、不足時間帯別使用量75をDBサーバ40に追加するS86。ステップ86のあと、またはステップ84でYESのとき、バッチサーバ30は、DBサーバ40から、時間帯別使用量74、不足時間帯使用量75、契約情報71を受け取って、料金計算を実施するS87。Webアプリケーションサーバ60はバッチサーバ30から料金計算結果を受け取って、シミュレーション結果を提示するS88。端末50は、シミュレーション結果を表示するS89。このように、あらかじめ時間帯別の使用量を算出しておくことにより、料金シミュレーション実行時に月間使用量の再計算を避けることができる。将来的に自動検針が普及し、例えば30分間隔で指針値を管理することになると、1つのメーターだけで指針値は1日48個、月間で約1440個、年間17280個となる。このように膨大なデータから時間帯別の使用量を算出する処理を料金シミュレーション実行時に行なうと、主にWebページから要求されるシミュレーション要求へのレスポンスが増大する。そのため、月に一度の定例で月間使用量を算出する夜間バッチ処理と同時に時間帯別使用量をあらかじめ算出しておくことにより、シミュレーション時の再計算を避けることの効果は大きい。さらに本実施例では、あらかじめ使用量を算出する際、契約種別ごとに使用量を算出するのではなく、算出対象として定義した時間帯別に使用量を算出することとした。契約種別を構成する時間帯は複数の契約種別で重複している場合があるが、時間帯別に使用量を算出することにより重複時間帯における使用量計算を1度で済ませることができるため、計算処理時間が短縮され、作成するデータ容量も節約することができる。また、連続した複数月の実績使用量を使用したシミュレーション計算を行なう場合も、該当期間の時間帯別使用量を加算するだけで済むため、シミュレーション計算時の処理時間の短縮にもつながる。将来的に電力会社が算出時間帯パラメータに定義されていない時間帯で構成される新しい契約種別を追加した場合、シミュレーション計算実行時に該当時間帯の使用量算出を行なわなければならない。例えば、図4に示す契約種別に加えて、23:00~07:00、07:00~10:00、10:00~16:00、16:00~23:00の4つの時間帯で構成される契約が追加されたとする。この場合、図6の算出対象時間帯パラメータでは07:00~10:00、10:00~16:00の時間帯別使用量が計算されていないため、図9の料金シミュレーション実行時の判定S84にて必要な時間帯別使用量が不足していると判断し、シミュレーション処理実行部は不足時間帯使用量計算S86を実行する。このとき該当期間の30分自動検針値70から、料金計算のために不足している時間帯別使用量を計算し、不足時間帯別使用量75としてデータを作成する。23:00~07:00、16:00~23:00の時間帯別使用量は作成済みであるため再計算不要である。このため、料金シミュレーション実行時に全時間帯の使用量を再計算する場合と比較して、処理時間を短縮することが可能である。特に、需要家が過去1年間分など長期間の実績使用量を使用したシミュレーションを行ないたい場合、不足時間帯分の計算のみを行なうことによる処理時間の短縮は、効果が大きい。このように不足時間帯使用量を算出した結果、時間帯別使用量74、不足時間帯別使用量75、契約情報71を参照して料金計算S87を行なうことができる。なお、上述した実施例では、自動検針料金シミュレーションの処理を、バッチサーバ30、DBサーバ40、Webアプリケーションサーバ60に分けて分担したが、1台の通信装置で実施してもよい。本実施例によれば、時間帯別にあらかじめ使用量を算出しておくことにより、料金シミュレーション時に、膨大に蓄積された自動検針値を基にした使用量再計算が不要となるため、主にWeb画面から要求される料金シミュレーションにも素早く応答することができる。また、時間帯別にあらかじめ使用量を算出済みにしておくことは、契約種別ごとに使用量を算出済みにする場合よりもデータ量を少なくすることができるため、使用量算出の処理時間やデータ資源を節約できる。