JP2020030604A - プラン提示プログラム、プラン提示方法、及び情報処理装置 - Google Patents

Abstract

【課題】本発明の課題は、ユーザの予算内において複数種類のリソースの使用量を変更したプランを提示することを目的とする。【解決手段】 上記課題は、ユーザごとに該ユーザが利用する複数種類のリソースの使用量を記憶部に記録し、前記複数種類のリソースそれぞれについて、前記記憶部に記録された使用量に基づき予測してリソース利用予測量を算出し、前記複数種類のリソースそれぞれについての前記リソース利用予測量と、前記ユーザの予算とに基づき、前記複数種類のリソースの使用量に応じた複数の料金プランから、１又は複数の料金プランを選択し、選択した前記１又は複数の料金プランを表示装置に表示させる処理をコンピュータに実行させるプラン提示プログラムにより達成される。【選択図】図３６

Description

本発明は、プラン提示プログラム、プラン提示方法、及び情報処理装置に関する。

近年、複数のサーバ装置を連携させたクラウドサービスが提供されている。クラウドサービスでは、ユーザは、所有している既存の端末を用いて、比較的大規模な業務システムを手軽に利用できる点で利便性があり、利用が拡大している。

クラウドサービスの利用に際しては、ユーザは、リソースの使用予定量と予算とに基づいて、リソースの使用量等のクラウドサービスの利用範囲が予め設定される。一例として、ユーザ指示のリソース使用予定について、予算額範囲内で収まる性能プランを決定する技術等が知られている。

国際公開第２０１３／１０３００６号パンフレット

しかしながら、クラウドサービスを用いて業務等を行う場合には、予期せぬ繁忙期が発生し、予算を超えてしまう状況が急に起こる場合がある。このような場合には、契約したリソースの急速な消費により、急に業務が行えなくなる事態が発生しかねないといった問題がある。

したがって、１つの側面では、ユーザの予算内において複数種類のリソースの使用量を変更したプランを提示することを目的とする。

一態様によれば、ユーザごとに該ユーザが利用する複数種類のリソースの使用量を記憶部に記録し、前記複数種類のリソースそれぞれについて、前記記憶部に記録された使用量に基づき予測してリソース利用予測量を算出し、前記複数種類のリソースそれぞれについての前記リソース利用予測量と、前記ユーザの予算とに基づき、前記複数種類のリソースの使用量に応じた複数の料金プランから、１又は複数の料金プランを選択し、選択した前記１又は複数の料金プランを表示装置に表示させる処理をコンピュータに実行させるプラン提示プログラムが提供される。

ユーザの予算内において複数種類のリソースの使用量を変更したプランを提示することができる。

本実施例が適用されるシステム構成例を説明するための図である。 リソース最適化サービスの概要を説明するための図である。 クラウドサービスにおけるデータの流れの一例を説明するための図である。 データベース間の関連付けの例を説明するための図である。 ポータルにて行われるポータル表示制御処理を説明するためのフローチャート図である。 性能情報収集システムにて行われる性能情報収集処理について説明するためのフローチャート図である。 最適なリソース判断処理を説明するためのフローチャート図である。 図７のステップＳ７３０における変更対象リソースの解析処理を説明するためのフローチャート図である。 図７のステップＳ７５０における変更実施可否の判定処理を説明するためのフローチャート図（続く）である。 図７のステップＳ７５０における変更実施可否の判定処理を説明するためのフローチャート図（続き）である。 図７のステップＳ７７０における変更実施処理を説明するためのフローチャート図である。 第１のリソース構成例を示す図である。 第１のリソース構成における最適化リソース管理ＤＢのデータ例を示す図である。 第１のリソース構成における商品管理ＤＢのデータ例を示す図である。 第１のリソース構成における契約管理ＤＢのデータ例を示す図である。 第１のリソース構成における課金管理ＤＢのデータ例を示す図である。 第１のリソース構成における商品性能管理ＤＢのデータ例を示す図である。 第１のリソース構成における動作性能管理ＤＢのデータ例を示す図である。 第１のリソース構成におけるリソース管理ＤＢのデータ例を示す図である。 第１のリソース構成における変更実施処理後の変更不可リソースＤＢの状態例を示す図である。 第２のリソース構成例を示す図である。 第２のリソース構成における商品管理ＤＢのデータ例を示す図である。 第２のリソース構成における契約管理ＤＢのデータ例を示す図である。 第２のリソース構成における課金管理ＤＢのデータ例を示す図である。 第２のリソース構成における動作性能管理ＤＢのデータ例を示す図である。 第２のリソース構成におけるリソース管理ＤＢのデータ例を示す図である。 第２のリソース構成における変更実施処理後の変更不可リソースＤＢの状態例を示す図である。 顧客による予算の変更に伴う、契約管理ＤＢのデータ遷移例を示す図である。 第２のリソース構成におけるリソース管理ＤＢのデータ例を示す図である。 時間単位の価格例を示す図である。 複数の顧客又は契約を管理した契約管理ＤＢのデータ例を示す図である。 複数の顧客の課金を管理する課金管理ＤＢのデータ例を示す図である。 契約情報を表示する画面例を示す図である。 過去の請求情報を表示する画面例を示す図である。 使用量の推移を示す画面例を示す図である。 予算を変更するための画面例を示す図である。 リソース見直しの結果を示す画面例を示す図である。 本実施例における情報処理装置の機能構成例を示す図である。

以下、本発明の実施の形態を図面に基づいて説明する。本実施例は、様々なシステム及びデータベースサーバ等との連携によるクラウドサービスに関する。本実施例では、ハードディスクの利用量のみならず、ＣＰＵ（Central Processing Unit）、メモリ、及びそれらの様々な性能を含むリソースの利用状態に応じて、迅速かつ柔軟に最適なリソース配分を可能とする。

図１は、本実施例が適用されるシステム構成例を説明するための図である。図１に示すシステム１０００は、クラウドサーバ９０と、複数のユーザ端末３とを有する。クラウドサーバ９０は、複数のサーバ装置１００により形成される仮想サーバに相当する。各ユーザ端末３は、ネットワークを介してクラウドサーバ９０に接続し、クラウドサーバ９０が提供する後述されるクラウドサービス９２を利用する、ユーザが利用する情報処理端末である。

クラウドサーバ９０を形成する複数のサーバ装置１００のそれぞれは、コンピュータによって制御される情報処理装置であって、ＣＰＵ（Central Processing Unit）１１１と、主記憶装置１１２と、補助記憶装置１１３と、入力装置１１４と、表示装置１１５と、通信Ｉ／Ｆ（インターフェース）１１７と、ドライブ装置１１８とを有し、バスＢ１に接続される。

ＣＰＵ１１１は、主記憶装置１１２に格納されたプログラムに従ってサーバ装置１００を制御するプロセッサに相当する。主記憶装置１１２には、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等が用いられ、ＣＰＵ１１１にて実行されるプログラム、ＣＰＵ１１１での処理に必要なデータ、ＣＰＵ１１１での処理にて得られたデータ等を記憶又は一時保存する。

補助記憶装置１１３には、ＨＤＤ（Hard Disk Drive）等が用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置１１３に格納されているプログラムの一部が主記憶装置１１２にロードされ、ＣＰＵ１１１に実行されることによって、各種処理が実現される。主記憶装置１１２、補助記憶装置１１３、及びサーバ装置１００がアクセス可能な外部記憶装置を総称して、記憶部１３０というものとする。

入力装置１１４は、マウス、キーボード等を有し、ユーザがサーバ装置１００による処理に必要な各種情報を入力するために用いられる。表示装置１１５は、ＣＰＵ１１１の制御のもとに必要な各種情報を表示する。入力装置１１４と表示装置１１５とは、一体化したタッチパネル等によるユーザインタフェースであってもよい。通信Ｉ／Ｆ１１７は、有線又は無線などのネットワークを通じて通信を行う。通信Ｉ／Ｆ１１７による通信は無線又は有線に限定されるものではない。

サーバ装置１００によって行われる処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）等の記憶媒体１９によってサーバ装置１００に提供される。

ドライブ装置１１８は、ドライブ装置１８にセットされた記憶媒体１１９（例えば、ＣＤ−ＲＯＭ等）とサーバ装置１００とのインターフェースを行う。

また、記憶媒体１１９に、後述される本実施の形態に係る種々の処理を実現するプログラムを格納し、この記憶媒体１１９に格納されたプログラムは、ドライブ装置１１８を介してサーバ装置１００にインストールされる。インストールされたプログラムは、サーバ装置１００により実行可能となる。

尚、プログラムを格納する記憶媒体１１９はＣＤ−ＲＯＭに限定されず、コンピュータが読み取り可能な、構造（structure）を有する１つ以上の非一時的（non-transitory）な、有形（tangible）な媒体であればよい。コンピュータ読取可能な記憶媒体として、ＣＤ−ＲＯＭの他に、ＤＶＤディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。

ユーザ端末３は、コンピュータによって制御される情報処理装置であって、ＣＰＵ３１１と、主記憶装置３１２と、補助記憶装置３１３と、入力装置３１４と、表示装置３１５と、通信Ｉ／Ｆ（インターフェース）３１７と、ドライブ装置３１８とを有し、バスＢ１に接続される。

ＣＰＵ３１１は、主記憶装置３１２に格納されたプログラムに従ってサーバ装置１００を制御するプロセッサに相当する。主記憶装置３１２には、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等が用いられ、ＣＰＵ３１１にて実行されるプログラム、ＣＰＵ３１１での処理に必要なデータ、ＣＰＵ３１１での処理にて得られたデータ等を記憶又は一時保存する。

補助記憶装置３１３には、ＨＤＤ（Hard Disk Drive）等が用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置３１３に格納されているプログラムの一部が主記憶装置３１２にロードされ、ＣＰＵ３１１に実行されることによって、各種処理が実現される。主記憶装置３１２、補助記憶装置３１３、及びサーバ装置１００がアクセス可能な外部記憶装置を総称して、記憶部３３０というものとする。

入力装置３１４は、マウス、キーボード等を有し、ユーザがサーバ装置１００による処理に必要な各種情報を入力するために用いられる。表示装置３１５は、ＣＰＵ３１１の制御のもとに必要な各種情報を表示する。入力装置３１４と表示装置３１５とは、一体化したタッチパネル等によるユーザインタフェースであってもよい。通信Ｉ／Ｆ３１７は、有線又は無線などのネットワークを通じて通信を行う。通信Ｉ／Ｆ３１７による通信は無線又は有線に限定されるものではない。

サーバ装置１００によって行われる処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）等の記憶媒体１９によってサーバ装置１００に提供される。

ドライブ装置３１８は、ドライブ装置１８にセットされた記憶媒体３１９（例えば、ＣＤ−ＲＯＭ等）とサーバ装置１００とのインターフェースを行う。

また、記憶媒体３１９に、後述される本実施の形態に係る種々の処理を実現するプログラムを格納し、この記憶媒体３１９に格納されたプログラムは、ドライブ装置３１８を介してサーバ装置１００にインストールされる。インストールされたプログラムは、サーバ装置１００により実行可能となる。

尚、プログラムを格納する記憶媒体３１９はＣＤ−ＲＯＭに限定されず、コンピュータが読み取り可能な、構造（structure）を有する１つ以上の非一時的（non-transitory）な、有形（tangible）な媒体であればよい。コンピュータ読取可能な記憶媒体として、ＣＤ−ＲＯＭの他に、ＤＶＤディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。

クライアント端末３は、ラップトップ、タブレット端末等であってもよい。その場合、記憶媒体３１９は、ＳＤ（Secure Digital）メモリカード等であり、ドライブ装置３１８は、ドライブ装置３１８にセットされた記憶媒体３１９と端末３とのインターフェースを行う。

次に、本実施例において、クラウドサーバ９０が提供するリソース最適化サービスの概要について説明する。図２は、リソース最適化サービスの概要を説明するための図である。図２において、クラウドサーバ９０が提供するクラウドサービス９２は、ポータル５と、リソース最適化サービス９４と、様々なデータベース（ＤＢ）３１〜３８と、顧客業務システム４００とを有する。ＤＢ３１〜３８のうち、ＤＢ３７及び３８は、リソース最適化サービス９４に含めて示すものとする。

クラウドサーバ９０は、図１で説明したように、複数のサーバ装置１００で構成されるが、ユーザには、あたかも１台のサーバを利用するように見せた仮想マシン（ＶＭ：Virtual Machine）である。このような観点において、また、説明を簡潔にするため、１台のサーバ装置１００で行われるものとして説明する。従って、ポータル５と、リソース最適化サービス９４とは、サーバ装置１００によって、ユーザ端末３に提供される。

ポータル５は、ユーザ端末３に提供する画面の表示制御を行う処理部であり、後述されるポータル表示制御処理により実現される。

リソース最適化サービス９４は、顧客業務システム４００におけるリソースを最適化して運用効率を改善させる処理をユーザに提供するサービスに相当する。リソース最適化サービス９４には、性能情報収集システム２００と、最適リソース配分システム３００とに相当するそれぞれの処理が含まれる。

性能情報収集システム２００は、性能情報収集部に相当する。最適リソース配分システム３００は、最適リソース配分部に相当する。性能情報収集部と、最適リソース配分部とは、サーバ装置１００にインストールされたプログラムが、サーバ装置１００のＣＰＵ１１１に実行させるそれぞれの処理により実現される。

商品管理ＤＢ３１、契約管理ＤＢ３２、課金管理ＤＢ３３、リソース管理ＤＢ３４、商品性能管理ＤＢ３５、動作性能管理ＤＢ３６、最適化リソース管理ＤＢ３７、変更不可リソースＤＢ３８等は、記憶部１３０に記憶される。

クラウドサービス９２には、顧客業務システム４００も含まれる。顧客業務システム４００は、ユーザの業務処理を担う処理部であり、一例として、様々な承認を必要とする業務に係るワークフロー、又は、財務や人事等の特定業務等のアプリケーションに相当し、サーバ装置１００によって実行される。

本実施例におけるクラウドサービス９２では、ポータル５からの第１見直し要求６ａと、性能情報収集システム２００からの第２見直し要求６ｂのそれぞれに応じて、顧客業務システム４００のリソースを最適化する。

第１見直し要求６ａは、顧客であるユーザによるリソースの使用量等のプランの見直しの依頼に相当する。第１見直し要求６ａによって、逐次的にユーザの所望するプランに最適なリソース判断処理が行われるため、最適なリソース判断処理の「逐次実行」というものとする。第１見直し要求６ａは、契約ＩＤを含む。

第２見直し要求６ｂは、性能情報収集システム２００がリソースの使用量を監視し、使用量が予測以上に増加している、又は、増加する傾向にあると判断した場合に発行されるリソースの最適化の要求に相当する。第２見直し要求６ｂによって、随時、最適なリソース判断処理が行われるため、最適なリソース判断処理の「随時実行」というものとする。第２見直し要求６ｂは、契約ＩＤを含む。

本実施例において、リソースとは、顧客業務システム４００を実施する際に、顧客のユーザとの間で取り交わした契約に基づき利用可能とした、ＣＰＵ、メモリ、ストレージ（ハードディスク）の台数や記憶容量等を表す物理量に加え、それらの種々の性能等をも含む。また、リソースの最適化とは、顧客（ユーザ）の予算範囲において、物理量の増減、性能の変更等を含み、顧客業務システム４００全体として契約期間内の運用効率を最適化することである。

最適リソース配分システム３００によって、ソースの物理量及び／又は性能の変更が判断されると、最適リソース配分システム３００からリソース変更指示６ｃが顧客業務システム４００へ行われる。リソース変更指示６ｃは、変更対象のリソースを特定する識別情報、物理量及び／又は性能を指定する変更内容等を含む。顧客業務システム４００は、リソース変更指示６ｃに応じて、リソースの構成を変更して、顧客に対して継続して業務処理を実施する。

図３は、クラウドサービスにおけるデータの流れの一例を説明するための図である。図３において、クラウドサービス９２では、顧客の予算の上限値７ｂが、ユーザ端末３から送信されポータル５で受信されると、予算の上限値７ｂは、ポータル５によって契約管理ＤＢ３２に記憶される。

一方、リソースの使用量７ｈが、顧客業務システム４００から所定間隔で性能情報収集システム２００へと収集され、契約ＩＤごとに履歴情報として動作性能管理ＤＢ３６に蓄積される。

第１見直し要求６ａ又は第２見直し要求６ｂに応じて、最適リソース配分システム３００において、最適なリソース判断処理が行われる。最適なリソース判断処理により、予兆監視情報として上限値７ｉ及び下限値７ｊが最適化リソース管理ＤＢ３７から取得され、リソース一覧７ｄがリソース管理ＤＢ３４から取得される。

最適リソース配分システム３００において、更に、過去使用量７ｇを含む履歴情報が動作性能管理ＤＢ３６から取得され、商品性能情報７ｆが商品性能管理ＤＢ３５から取得される。また、予算の上限値７ｂが契約管理ＤＢ３２から取得され、商品単価７ａが商品管理ＤＢ３１から取得され、請求額７ｃが課金管理ＤＢ３３から取得される。

また、最適リソース配分システム３００において、リソースの物理量又は性能の変更が行われる場合には、リソース変更情報７ｅによってリソース管理ＤＢ３４が更新される。最適リソース配分システム３００は、リソース管理ＤＢ３４を変更した後、リソース変更指示６ｃを顧客業務システム４００へ送信する。

最適なリソース判断処理によって、変更不可能なリソースが存在すると判断された場合には、変更不可リソース情報７ｋが変更不可リソースＤＢ３８に記憶される。一方、顧客が変更不可能なリソースを判断してもよく、この場合には、変更不可リソース情報７ｋ’がポータル５から変更リソースＤＢ３８へと記憶される。

次に、種々のＤＢ３１〜３８間の関連付けについて図４で説明する。図４は、データベース間の関連付けの例を説明するための図である。図４において、商品管理ＤＢ３１は、リソースのデバイス種別と性能の組み合せごとに１商品とし、商品ごとの商品情報を管理するデータベースであり、商品ＩＤ、商品名、商品説明、単位、商品単価等の項目を有する。

商品ＩＤは、リソースを特定する識別情報を示す。リソースは、ＣＰＵ、メモリ、ストレージ（ハードディスク）等のデバイスである。商品名は、リソースの名称を示す。商品説明は、商品の種類等を簡潔に示す情報である。商品名が商品（リソース）の種類を特定する名称であれば、商品説明に代用してもよい。

単位は、１時間用いられた場合の使用量を示す。使用量は、リソースの特定に応じて台数、記憶容量等で示される。一例として、サーバであれば台数が示され、ストレージであればギガバイト（ＧＢ）等の記憶容量／メモリサイズ等が示される。商品単価は、３０日分に相当する７２０時間の料金を示す。

契約管理ＤＢ３２は、顧客と交わした契約ごとの契約情報を管理するデータベースであり、契約ＩＤ、契約名、契約者ＩＤ、予算（上限値）等の項目を有する。契約ＩＤは、契約ごとを特定する識別情報を示す。

契約名は、契約対象を簡潔に示す名称を示す。一例として、契約者名等を示せばよい。契約者ＩＤは、契約者を一意に特定する識別情報を示す。予算（上限値）は、契約者の予算を示す。契約管理ＤＢ３２への登録時には、契約時の顧客の予算を示すが、状況に応じて更新されてもよい。

課金管理ＤＢ３３は、請求ごとに請求情報を管理するデータベースであり、請求ＩＤ、請求額、請求年月、契約ＩＤ、明細書ＩＤ、商品ＩＤ、小計等の項目を有する。

請求ＩＤは、請求書を特定する識別情報を示す。請求額は、顧客へ請求した総請求額を示す。請求年月は、顧客へ請求した年月を示す。契約ＩＤは、契約管理ＤＢ３２に存在する契約ＩＤのうち、請求の対象となった顧客との契約を特定する契約ＩＤを示す。請求ＩＤに対応付けられる、請求額、請求年月、契約ＩＤ等を「請求情報」というものとする。

明細書ＩＤは、請求の対象となった明細を特定する識別情報を示し、請求ＩＤに対して１又は複数の明細が関連付けられる。商品ＩＤは、商品管理ＤＢ３１に存在する商品ＩＤのうち、請求対象となった商品のＩＤを示す。小計は、明細毎の請求金額を示す。

課金管理ＤＢ３３では、１の請求書に対して、複数の明細が請求の対象となるため、請求項ＩＤで管理される請求情報と、１以上の明細の情報（以下、「明細情報」という）とは、請求項ＩＤを用いて、関連付けて管理されることが望ましい。明細情報は、商品ＩＤ、小計等が相当する。

リソース管理ＤＢ３４は、契約ごとのリソースそれぞれの情報を管理し、使用量に応じて、顧客の予算内でリソースの変更を許容するデータベースであり、リソースＩＤ、リソース名、フレーバＩＤ、使用数、契約ＩＤ等の項目を有する。

リソースＩＤは、リソースを識別する識別情報を示し、顧客が利用中のリソースのそれぞれを特定する。リソース名は、リソースの名称を示す。フレーバＩＤは、商品性能管理ＤＢ３５に存在するリソースの性能を表すフレーバＩＤを示す。使用数は、顧客の予算の上限値７ｂで運用中のリソースの台数や記憶容量等を示す。契約ＩＤは、契約管理ＤＢ３２に存在する契約ＩＤのうち、リソースの利用に係る顧客との契約を特定する契約ＩＤを示す。

商品性能管理ＤＢ３５は、商品ごとの性能を管理するデータベースであり、フレーバＩＤ、フレーバ名、性能等の項目を有する。フレーバＩＤは、リソースの性能を表すフレーバに関する情報を特定するための識別情報を示す。フレーバ名は、性能ごとに与えられた名称を示す。性能は、商品の種類と商品の性能とを特定する情報を示す。

動作性能管理ＤＢ３６は、性能情報収集システム２００が定期的に顧客業務システム４００から収集したリソースごとの使用量を履歴情報として蓄積する、契約ごとのデータベースであり、リソースＩＤ、デバイス種別、使用量、タイムスタンプ等の項目を有する。

リソースＩＤは、リソース管理ＤＢ３４に存在するリソースＩＤのうち、収集されたリソースを特定するリソースＩＤを示す。デバイス種別は、リソースの種別を示し、最適化リソース管理ＤＢ３７で管理されるデバイス種別を含む情報である。使用量は、収集時におけるリソースの使用量を示す。タイムスタンプは、収集した年月日及び時刻を示す。

最適化リソース管理ＤＢ３７は、リソースの増減判定に使用する閾値を管理するデータベースであり、デバイス種別、上限、下限等の項目を有する。デバイス種別は、リソースのデバイス種別を示す。上限は、リソースの増加を必要とする状態判定に用いる使用率の上限値ｉを示す。下限は、リソースの削減を可能とする状態判定に用いる使用率の下限値ｊを示す。リソースの使用用が、下限から上限の範囲である場合、増減の変更は不要であると判断する。

変更不可リソースＤＢ３８は、最適リソース配分システム３００又はユーザによって、変更不可と判断されたリソースの情報を記憶するデータベースであり、リソースＩＤ、推奨フレーバＩＤ、推奨使用数、変更額等の項目を有する。

リソースＩＤは、リソース管理ＤＢ３４に存在するリソースＩＤのうち、最適リソース配分システム３００によってリソースの変更はできないと判断されたリソースのＩＤ、又は、ユーザ端末３の操作によってポータル５から通知されたリソースＩＤを示す。

推奨フレーバＩＤは、商品性能管理ＤＢ３５に存在するフレーバＩＤのうち、推奨されるフレーバのＩＤが示される。推奨使用数は、推奨される使用量（台数／記憶容量）が示される。変更額は、推奨されたフレーバに変更した場合の金額を示す。

先ず、本実施例における様々な処理について説明し、その後、上述したＤＢ３１〜３８のデータ例について説明する。

図５は、ポータルにて行われるポータル表示制御処理を説明するためのフローチャート図である。図５において、ポータル５は、ユーザ端末３からの操作を受け付けると、操作に応じた画面の表示を行う画面表示制御を行う（ステップＳ５０１）。

ユーザ端末３に表示した画面に対してなされたユーザの操作を受け付けると、ポータル５は、操作が予算の上限値７ｂの登録か否かを判断する（ステップＳ５０２）。操作が予算の上限値７ｂの登録の場合には、ポータル５が受信する操作の情報には、契約ＩＤと、予算の上限値７ｂとが少なくとも含まれる。

操作が予算の上限値７ｂの登録である場合（ステップＳ５０２のＹＥＳ）、ポータル５は、予算の上限値７ｂを契約管理ＤＢ３２に登録して（ステップＳ５０３）、ステップＳ５０１へと戻り、予算の上限値７ｂの登録後の画面表示制御を行う。

一方、操作が予算の上限値７ｂの登録でない場合（ステップＳ５０２のＮＯ）、ポータル５は、更に、操作がリソース見直し（逐次実施）か否かを判断する（ステップＳ５０４）。操作がリソース見直し（逐次実施）の場合（ステップＳ５０４のＹＥＳ）、ポータル５は、第１見直し要求６ａを最適リソース配分システム３００へ送信することで、最適リソース配分システム３００に最適なリソース判断処理を行わせ（ステップＳ７００）、ステップＳ５０１へと戻り、最適なリソース判断処理後の画面表示制御を行う。

一方、操作がリソース見直し（逐次実施）でない場合（ステップＳ５０４のＮＯ）、ポータル５は、見直し内容の表示要求か否かを判断する（ステップＳ５０５）。見直し内容の表示要求である場合（ステップＳ５０５のＹＥＳ）、ポータル５は、契約ＩＤを用いて、変更不可リソースＤＢ３８から変更不可リソース情報７ｋを取得して（ステップＳ５０６）、ステップＳ５０１へと戻り、見直し内容の表示要求に応じた画面表示制御を行う。

一方、見直し内容の表示要求でない場合（ステップＳ５０５のＮＯ）、ポータル５は、操作が終了であるか否かを判断する（ステップＳ５０７）。操作が終了でない場合（ステップＳ５０７のＮＯ）、ポータル５は、ステップＳ５０１へと戻り、操作に応じた画面表示制御を行う。操作が終了である場合（ステップＳ５０７のＹＥＳ）、ポータル５は、このポータル表示制御処理を終了する。

図６は、性能情報収集システムにて行われる性能情報収集処理について説明するためのフローチャート図である。図６において、性能情報収集システム２００は、所定時間ごとに性能情報収集処理を実行する。所定時間は、一例として、６０分等である。性能情報収集システム２００は、６０分ごとに、ステップＳ６０１〜Ｓ６０３及びＳ７００を行う。

性能情報収集システム２００は、顧客業務システム４００からリソースごとの使用量７ｈを収集し、動作性能管理ＤＢ３６に履歴情報として蓄積する（ステップＳ６０１）。リソースごとの使用量７ｈは、顧客業務システム４００の現在の性能情報を表す過去使用量７ｇとして、最適リソース配分システム３００によって参照される。

そして、性能情報収集システム２００は、締め処理後の初めての処理であるか否かを判断する（ステップＳ６０２）。締め処理を行うタイミングは、顧客が指定したタイミングであればよい。一例として、毎日、毎週、毎月、３ヶ月、６ヶ月、１２ヶ月、月末等のいずれであってもよい。締め処理後の初めての処理である場合（ステップＳ６０２のＹＥＳ）、性能情報収集システム２００は、最適リソース配分システム３００へ第２見直し要求６ｂを行うことで、最適リソース配分システム３００に最適なリソース判断処理を行わせ（ステップＳ７００）、この性能情報収集処理を終了する。

一方、締め処理後の初めての処理ではない場合（ステップＳ６０２のＮＯ）、性能情報収集システム２００は、リソースごとに使用量の推移をアノマリー分析して、１又は複数のリソースで特異な使用量の増減を検知したか否かを判断する（ステップＳ６０３）。この判断処理では、月末等の特定の時期に使用量が増加している場合に、顧客業務システム４００のリソースを一時的に増強するか否かを判断する。また、業務量が少ない時期等に対して、料金の見直しをする機会であるか否かを判断する。

１又は複数のリソースで特異な使用量の増減を検知した場合（ステップＳ６０３のＹＥＳ）、性能情報収集システム２００は、最適リソース配分システム３００へ第２見直し要求６ｂを行うことで、最適リソース配分システム３００に最適なリソース判断処理を行わせ（ステップＳ７００）、この性能情報収集処理を終了する。

一方、全てのリソースで特異な使用量の増減を検知しなかった場合（ステップＳ６０３のＮＯ）、性能情報収集システム２００は、この性能情報収集処理を終了する。

図７は、最適なリソース判断処理を説明するためのフローチャート図である。図７に示す最適なリソース判断処理において、最適リソース配分システム３００は、最適化リソース管理ＤＢ３７から予兆監視情報として上限値７ｉ及び下限値７ｊを取得する（ステップＳ７１０）。最適リソース配分システム３００は、リソース管理ＤＢ３４から、対象リソースと同一の契約ＩＤのリソース一覧７ｄを取得する（ステップＳ７２０）。リソース一覧７ｄは、リソースＩＤ、フレーバＩＤ等を含んでいる。

最適リソース配分システム３００は、拡張又は縮小による変更対象となるリソースを特定するために、変更対象リソースの解析処理を行い（ステップＳ７３０）、得られた変更対象のリソースに対して、変更の実施可否を判定する変更実施可否の判定処理を行う（ステップＳ７５０）。

本実施例において、拡張による変更（拡張変更）とは、現状の性能では十分ではなく、現状以上の性能で顧客業務システム４００を運用することが望ましい場合に相当する。また、縮小による変更（縮小変更）とは、現状の性能は必要以上に割り当てられ、現状以下の性能で顧客業務システム４００の運用が可能な場合に相当する。

そして、最適リソース配分システム３００は、変更実施可能なリソースの拡張又は縮小を実施する変更実施処理を行って（ステップＳ７７０）、この最適なリソース判断処理を終了する。

図８は、図７のステップＳ７３０における変更対象リソースの解析処理を説明するためのフローチャート図である。図８において、最適リソース配分システム３００は、リソース一覧７ｄからリソースを特定するリソースＩＤを順に１つずつ選択し（ステップＳ７３１）、全てのリソースＩＤに対して以下に説明するステップＳ７３２〜Ｓ７３８を行う。

最適リソース配分システム３００は、リソース一覧７ｄから選択したリソースＩＤを用いて、動作性能管理ＤＢ３６から予め定めた期間内の使用量として過去使用量７ｇを取得する（ステップＳ７３２）。取得した過去使用量７ｇは、当該期間内の顧客業務システム４００のリソースの性能を表す情報（リソース性能情報）に相当する。

最適リソース配分システム３００は、過去使用量７ｇを用いて線形分析を行って、未来使用量を予測する（ステップＳ７３３）。また、最適リソース配分システム３００は、リソースの商品性能情報７ｆと、予測した未来使用量とから未来使用率を算出する（ステップＳ７３４）。最適リソース配分システム３００は、リソース一覧７ｄにおいて、選択したリソースＩＤのレコードで示されるフレーバＩＤを用いて、商品性能情報ＤＢ３５から賞品性能情報７ｆを取得すればよい。

そして、最適リソース配分システム３００は、取得した未来使用率が上限値ｉを超えるか否かを判断する（ステップＳ７３５）。未来使用率が上限値ｉを超える場合（ステップＳ７３５のＹＥＳ）、最適リソース配分システム３００は、選択したリソースＩＤで特定されるリソースは拡張対象リソースであると判断し、リソースＩＤと未来使用率とを記憶部１３０内の拡張用作業テーブル８ａに記憶する（ステップＳ７３６）。

一方、未来使用率が上限値ｉを超えない場合（ステップＳ７３５のＮＯ）、最適リソース配分システム３００は、更に、未来使用率が下限値ｊ以下か否かを判断する（ステップＳ７３７）。未来使用率が下限値ｊ以下の場合（ステップＳ７３７のＹＥＳ）、最適リソース配分システム３００は、選択したリソースＩＤで特定されるリソースは縮小対象リソースであると判断し、リソースＩＤと未来使用率とを記憶部１３０内の縮小用作業テーブルｂに記憶する（ステップＳ７３８）。

ステップＳ３７６又はＳ３７８のいずれかの処理の後、最適リソース配分システム３００は、リソース一覧７ｄの全てのリソースＩＤについてステップＳ７３２〜Ｓ７３８の処理を完了していない場合は、ステップＳ７３１へと戻り、次のリソースＩＤを取得して、上記同様の処理を繰り返す。全てのリソースＩＤについて処理を完了している場合には、ステップＳ７３９へと進む。

リソース一覧７ｄの全てのリソースＩＤについてステップＳ７３２〜Ｓ７３８の処理を完了すると、最適リソース配分システム３００は、拡張用作業テーブル８ａを未来使用率の高い順にソートし（ステップＳ７３９）、また、縮小用作業テーブルｂを未来使用率の低い順にソートした後（ステップＳ７４０）、この変更対象リソースの解析処理を終了する。

図９及び図１０は、図７のステップＳ７５０における変更実施可否の判定処理を説明するためのフローチャート図である。図９にて、最適リソース配分システム３００は、契約ＩＤを用いて、契約管理ＤＢ３２から予算の上限値７ｂを取得する（ステップＳ７５１）。

そして、最適リソース配分システム３００は、拡張用作業テーブル８ａから順にリソースＩＤを１つ選択し（ステップＳ７５２）、全てのリソースＩＤに対して以下に説明するステップＳ７５３〜Ｓ７６５の処理（拡張対象リソースごとのループ）を行う。

最適リソース配分システム３００は、拡張用作業テーブル８ａから、選択したリソースＩＤのレコードを参照し、当該レコードに示される未来使用率に基づいて、リソース使用率の上限値ｉと下限値ｊとで定まるしきい値内に収まる性能を算出する（ステップＳ７５３）。

そして、最適リソース配分システム３００は、算出された性能に基づいて、商品管理ＤＢ３１から、しきい値内に収まる性能の商品単価７ａを取得して（ステップＳ７５４）、拡張した場合の増加額を算出する（ステップＳ７５５）。

また、最適リソース配分システム３００は、契約ＩＤを用いて、前月の請求額を取得する（ステップＳ７５６）。最適リソース配分システム３００は、課金管理ＤＢ３３において、契約ＩＤが一致するレコードのうち、請求年月が前月を示すレコードを特定し、特定したレコードで示される請求額を取得すればよい。

最適リソース配分システム３００は、取得した前月の請求額に増加額を加算して得た値が、予算の上限値７ｂより大きいか否かを判断する（ステップＳ７５７）。加算して得た値が予算の上限値７ｂ以下である場合（ステップＳ７５７のＮＯ）、最適リソース配分システム３００は、ステップＳ７６５（図１０）へと進む。

一方、加算して得た値が予算の上限値７ｂより大きい場合（ステップＳ７５７のＹＥＳ）、最適リソース配分システム３００は、予算の上限値７ｂを超えた金額の分を、他のリソースの性能を縮小し、請求額の削減を試みる。

図１０より、縮小対象ごとのループでは、縮小用作業テーブル８ｂからリソースを特定するリソースＩＤが順に、予算の上限値７ｂを超えるまで選択され（ステップＳ６５８）、ステップＳ７５９〜Ｓ７６１の処理が繰り返される。予算の上限値７ｂを超えときに、最適リソース配分システム３００は、ステップＳ７６３及びＳ７６４の処理を行って、この縮小対象ごとのループを抜ける。

リソースＩＤの選択後、最適リソース配分システム３００は、現在のリソース性能以下の性能の商品単価７ａを取得する（ステップＳ７５９）。一例として、最適リソース配分システム３００は、選択したリソースＩＤで特定されるリソースの性能を、契約ＩＤを用いて、リソース管理ＤＢ３４からフレーバＩＤを特定し、商品性能管理ＤＢ３６から特定したフレーバＩＤのレコードを取得する。取得したレコードで示される性能から、現在のリソース性能を特定できる。最適リソース配分システム３００は、また、商品性能管理ＤＢ３６から特定した現在のリソース性能以上の性能を示すレコードを抽出し、商品管理ＤＢ３１から商品名又は商品説明の一部に抽出したレコードのフレーバ名を含むレコードから商品単価７ａを取得する。

次に、最適リソース配分システム３００は、縮小対象リソースをしきい値内に縮小した場合の予算の削減額を算出し（ステップＳ７６０）、選択したリソースＩＤを縮小対象リソースリスト９ｂに記憶する（ステップＳ７６１）。縮小対象リソースリスト９ｂに、選択したリソースＩＤに加えて、削減額を記憶しておいてもよい。

そして、最適リソース配分システム３００は、前月の請求額に増加額を加算し、削減額を減算した値が予算の上限額７ｂより大きいか否かが判断される（ステップＳ７６２）。予算の上限額７ｂより大きい場合（ステップＳ７６２のＹＥＳ）、最適リソース配分システム３００は、次の縮小対象リソースに対して上述した同様の処理を行うため、ステップＳ７５８へと戻る。

一方、予算の上限額７ｂ以下の場合（ステップＳ７６２のＮＯ）、最適リソース配分システム３００は、縮小対象リスト１０ｂに縮小対象候補リソースリスト９ｂのリソースＩＤを追加する（ステップＳ７５３）。

そして、最適リソース配分システム３００は、縮小対象候補リソースリスト９ｂをリセットした後（ステップＳ７６４）、この縮小対象ごとのループを抜ける。縮小対象ごとのループを抜けた場合、拡張対象リソースは、顧客の予算の上限値７ｂ内で性能拡張が可能であると判断できる。従って、最適リソース配分システム３００は、拡張対象リスト１０ａに当該拡張対象リソースのリソースＩＤを追加する（ステップＳ７６５）。

その後、拡張用作業テーブル８ａに未処理のリソースＩＤが存在する場合、最適リソース配分システム３００は、ステップＳ７５１（図９）へと戻り、上述した同様の処理を繰り返す。拡張用作業テーブル８ａのリソースＩＤ全てに対して処理を完了すると、最適リソース配分システム３００は、この変更実施可否の判定処理を終了する。

図１１は、図７のステップＳ７７０における変更実施処理を説明するためのフローチャート図である。図１１において、最適リソース配分システム３００は、縮小対象リスト１０ｂから順にリソースＩＤを選択し、縮小対象リソースの性能を縮小することを（ステップＳ７７１及びＳ７７２）、全リソースＩＤに対して繰り返し行う縮小対象リソースごとのループを行う。

縮小対象リスト１０ｂの全リソースＩＤに対して性能を縮小するためのリソース管理ＤＢ３４の変更を行うと、最適リソース配分システム３００は、拡張対象リスト１０ａに基づく拡張対象リソースごとのループを行う（ステップＳ７７３及びＳ７７４）。拡張対象リソースごとのループでは、拡張対象リスト１０ａから順にリソースＩＤを選択し（ステップＳ７７３）、選択したリソースＩＤで特定される拡張対象リソースの性能を拡大する（ステップＳ７７４）。

リソース管理ＤＢ３４を変更するリソース変更情報７ｅには、契約ＩＤと、リソースＩＤと、フレーバＩＤ又は使用数とを含む。

リソース管理ＤＢ３４を変更した後、最適リソース配分システム３００は、縮小用作業テーブル８ｂから縮小対象リスト１０ｂのリソースＩＤのレコードを除いた差分レコードに基づく変更不可リソース情報７ｋを、変更不可リソースＤＢ３８に追加する（ステップＳ７７５）。

また、最適リソース配分システム３００は、拡張用作業テーブル８ａから拡張対象リスト１０ａのリソースＩＤのレコードを除いた差分レコードに基づく変更不可リソース情報７ｋを、変更不可リソースＤＢに追加する（ステップＳ７７６）。

そして、最適リソース配分システム３００は、リソース変更指示を送信し（ステップＳ７７７）、この変更実施処理Ｓ７７０を終了する。変更実施処理Ｓ７７０の終了に応じて、最適なリソース判断処理（図７）も終了する。

次に、様々なＤＢ３１〜３８のデータ例について、ある顧客の契約ＩＤ「contractA」で特定される契約に基づいて顧客に提案される資源の構成例に基づいて説明する。先ず、契約時に顧客の予算に合わせた最適化リソース配分に基づく、第１の予算の変更例について図１２〜図２０で説明する。

図１２は、第１のリソース構成例を示す図である。図１２に示す第１のリソース構成１００１は、仮想サーバ１と、仮想サーバ２とを有する契約時のリソース構成を示している。仮想サーバ１はシステムストレージ１を含み、仮想サーバ２はシステムストレージ２と増設ストレージ１とを含む。図１２では、それぞれのリソースに対して、リソースＩＤと、商品ＩＤと対応付けて示す。

仮想サーバ１は、リソースＩＤ「com1」で特定され、商品「product01」が割り当てられ、仮想サーバ１に含まれるシステムストレージ１は、リソースＩＤ「sys1」で特定され、商品「product03」が割り当てられる。

また、仮想サーバ２は、リソースＩＤ「com2」で特定され、商品「product02」が割り当てられる。更に、仮想サーバ２に配分されたシステムストレージ２は、リソースＩＤ「sys2」で特定され、商品「product04」が割り当てられ、仮想サーバ２に配分された増設ストレージ１は、リソースＩＤ「data1」で特定され、商品「product05」が割り当てられる。

図１３は、第１のリソース構成における、最適化リソース管理ＤＢのデータ例を示す図である。図１３に示す最適化リソース管理ＤＢ３７は、最適リソース配分システム３００において、リソースを最適化するタイミングを判定するためのリソースごとの閾値を示している。

この例では、デバイス種別「ＣＰＵ」の場合、ＣＰＵの性能を上げることを判定するしきい値は上限値７ｉは「８０％」であり、ＣＰＵの性能を下げても運用可能であると判定するしきい値は下限値７ｊは「２０％」である。他のデバイス種別に対しても、それぞれ上限値７ｉと下限値７ｊとが示される。

図１４は、第１のリソース構成における商品管理ＤＢのデータ例を示す図である。図１４に示す商品管理ＤＢ３１は、図１２に示すリソースのデバイス種別と性能の組み合せごとに１商品として、リソースの料金を含めた商品情報を示している。図１４では、図１２の第１のリソース構成１００１に含まれる５つのリソース（種類及び性能）は、商品ＩＤ「product01」、「product02」、「product03」、「product04」、及び「product05」で管理されることを示し、1ヶ月の価格を示している。

仮想サーバ１は、商品ＩＤ「product01」に相当し、商品名「仮想サーバ(S-1)」、商品説明「仮想サーバ(S-1)」、及び単位「台数・月」、価格（円）「7466.4」が示される。仮想サーバ２は商品ＩＤ「product02」に相当し、商品名「仮想サーバ(S-4)」、商品説明「仮想サーバ(S-4)」、単位「台数・月」、価格（円）「28937.6」が示される。

システムストレージ１は、商品ＩＤ「product03」に相当し、商品名「システムストレージ１」、商品説明「システムストレージ」、単位「ＧＢ・月」、価格（円）「158.4」が示される。

システムストレージ２は、商品ＩＤ「product04」に相当し、商品名「システムストレージ２」、商品説明「システムストレージ」、単位「ＧＢ・月」、価格（円）「158.4」が示される。また、増設ストレージ１は、商品ＩＤ「product05」に相当し、商品名「増設ストレージ２」、商品説明「増設ストレージ」、単位「ＧＢ・月」、価格（円）「158.4」が示される。

図１５は、第１のリソース構成における契約管理ＤＢのデータ例を示す図である。図１５では、契約締結後の顧客の予算の上限値７ｂの登録前と登録後の契約管理ＤＢ３２のデータ例を示している。

登録前では、契約ＩＤ「contractA」、契約名「Ａ社」、契約者ＩＤ「userA」、及び予算（上限）「ｎｕｌｌ（値無し）」であることを示す。登録後では、予算（上限）「ｎｕｌｌ（値無し）」が「100,000」円に変更される。また、予算（上限）の金額は、契約後の最初の登録から、リソースの最適化ごとに変更され得る値である。

図１６は、第１のリソース構成における課金管理ＤＢのデータ例を示す図である。図１６に示す課金管理ＤＢ３３では、図１２に示す第１のリソース構成１００１での２０１８年４月に顧客に請求した請求履歴を示している。

この例では、請求ＩＤ「billing01」について、請求額「100,764」円、請求年月「2018/04」、及び契約ＩＤ「contractA」が記憶されている。また、請求ＩＤに関連付けて、請求の明細の情報が記憶されている。

明細ＩＤ「statement01」では、商品ＩＤ「product01」の請求額を小計「7,466」円で示し、明細ＩＤ「statement02」では、商品ＩＤ「product02」の請求額を小計「28,938」円で示し、明細ＩＤ「statement03」では、商品ＩＤ「product03」の請求額を小計「7,920」円で示している。

更に、明細ＩＤ「statement04」では、商品ＩＤ「product04」の請求額を小計「7,920」円で示し、明細ＩＤ「statement05」では、商品ＩＤ「product05」の請求額を小計「47,520」円で示している。

図１７は、第１のリソース構成における商品性能管理ＤＢのデータ例を示す図である。図１７に示す商品性能管理ＤＢ３３では、図１２に示す第１のリソース構成１００１に含まれる各リソースの性能が示されている。

この例では、各リソースの性能について、フレーバＩＤ「flaver01」に対して、フレーバ名「S-1」と、性能「1CPU 4GB」とが対応付けられ、フレーバＩＤ「flaver02」に対して、フレーバ名「S-4」と、性能「4CPU 16GB」とが対応付けられている。

フレーバＩＤ「volumetype01」に対して、フレーバ名「M1」と、性能「7200rpm HDD」とが対応付けられ、フレーバＩＤ「volumetype02」に対して、フレーバ名「L1」と、性能「SSD」とが対応付けられている。他性能についても、同様に管理される。

図１８は、第１のリソース構成における動作性能管理ＤＢのデータ例を示す図である。図１８に示す動作性能管理ＤＢ３６では、図１２に示す第１のリソース構成１００１の使用量７ｈを含む履歴情報が時系列に蓄積され記憶されている。

この例では、図１２に示す第１のリソース構成１００１の各リソースから、１時間ごとに使用量７ｈが収集された場合を示しているが、収集する間隔は、顧客、管理者等により、数時間、日ごと、週ごと等、適宜設定されてもよい。

時系列に、リソースＩＤ「com1」のデバイス種別は「ＣＰＵ（使用率）」であり、タイムスタンプによる収集時刻「2018/4/10 19:00」において、使用量は「２０」％であったことが示されている。リソースＩＤ「com2」のデバイス種別は「メモリ（使用量ＧＢ）」であり、タイムスタンプによる収集時刻「2018/4/10 19:00」において、使用量は「１０」ＧＢであったことが示されている。

更に、リソースＩＤ「sys1」のデバイス種別は「ディスク（使用量ＧＢ）」であり、タイムスタンプによる収集時刻「2018/4/10 19:00」において、使用量は「１０」ＧＢであったことが示されている。リソースＩＤ「sys2」のデバイス種別は「ディスク（使用量ＧＢ）」であり、タイムスタンプによる収集時刻「2018/4/10 19:00」において、使用量は「１０」ＧＢであったことが示されている。

更に、リソースＩＤ「data1」のデバイス種別は「ディスク（使用量ＧＢ）」であり、タイムスタンプによる収集時刻「2018/4/10 18:00」において、使用量は「３０」ＧＢであったことが示されている。

次の収集時刻「2018/4/10 19:00」においても同様に各リソースの使用量が記憶される。

最適リソース配分システム３００では、図１３に例示した最適化リソースＤＢ３７のしきい値（上限値７ｉ及び下限値７ｊ）を参照し、上限値７ｉを超える使用量のリソースと、下限値７ｊ以下の使用量を示すリソースとが特定される。

この例において、収集時刻「2018/4/10 19:00」において、リソース「com1」の使用量が「９０」％に達し、未来使用率においても上限値７ｉの「８０」％を超える。従って、使用量の増加が検知される。また、リソース「data1」の使用量が「３０」ＧＢであり、未来使用率において下限値７ｊの「３０」％以下を示す。リソース「data1」は、少なくとも使用量の増加はないと予測され、削減しても顧客業務システム４００に影響はないと判断される。従って、リソース「data1」に対して、使用量の削減可能な状態が検知される。

図１９は、第１のリソース構成におけるリソース管理ＤＢのデータ例を示す図である。図１９では、図１２に示す第１のリソース構成１００１を構成するそれぞれのリソースの情報の変化例を示している。

図１９（Ａ）は、最適リソース配分システム３００によるリソースの縮小実施及び拡大実施によって性能（フレーバ）又は使用数が変更される前のデータ例を示している。顧客の予算（上限）（図１５）の「100,000」円内で、リソースＩＤ「com1」で特定されるリソースのＣＰＵ性能を上げようとしても、顧客の予算に余裕がない。

つまり、図１４の商品管理ＤＢ３１のデータ例に基づくと、
・リソースＩＤ「com1」は商品ＩＤ「product01」に対応し、１台／月で
７、４６６．４円
・リソースＩＤ「com2」は商品ＩＤ「product02」に対応し、１台／月で
２８、９３８．６円
・リソースＩＤ「sys1」は商品ＩＤ「product03」に対応し、５０ＧＢ／月で
７、９２０．０円（＝ ５０ＧＢ×１５８．４円（１ＧＢ／月））
・リソースＩＤ「sys2」は商品ＩＤ「product04」に対応し、５０ＧＢ／月で
７、９２０．０円（＝ ５０ＧＢ×１５８．４円（１ＧＢ／月））
・リソースＩＤ「data1」は商品ＩＤ「product05」に対応し、３００ＧＢ／月で
４７、５２０．０円（＝３００ＧＢ×１５８．４円（１ＧＢ／月））
・合計し、四捨五入して小数点以下をまるめると、
９９、７６４円
となる。

そこで、使用量の少ないリソースdata1については、性能を低く（容量を少なく）することで、リソースcom1の性能を高く（処理能力を高く）した場合の増加分を補う。

具体的には、先ず、商品性能管理ＤＢ３５及び商品管理ＤＢ３１を参照して、リソース「com1」のフレーバを、性能が「1CPU 4GB」のフレーバ「flavor01」から性能が「4CPU 16GB」のフレーバ「flavor02」へと変更した場合の差額を算出する。商品管理ＤＢ３１より、フレーバ「flavor01」に対応する商品「product01」の１台は、７、４６６．４円／月であるのに対して、フレーバ「flavor02」に対応する商品「product02」の１台は、２８、９３７．６円／月である。従って、その差額は、２２、４７１．２円／月である。

得られた差額の２２、４７１．２円／月を、リソースdata1に対応する商品product05の価格「１５８．７」円で割ることにより、減らす使用量として概ね１４０ＧＢを得る。現在のリソースdata1の使用数「３００」ＧＢを「１６０」ＧＢ（＝３００ＧＢ−１４０ＢＧ）に変更する。

図１９（Ｂ）は、縮小実施後のリソース管理ＤＢ３４のデータ例を示している。図１９（Ｂ）に示すように、リソースdata1の使用数が「１６０」ＧＢに変更される。そして、不足していたリソースcom1の性能を変更する。

図１９（Ｃ）は、拡大実施後のリソース管理ＤＢ３４のデータ例を示している。図１９（Ｃ）に示すように、リソースcom1のフレーバＩＤが、「flaver01」から「flaver02」へと変更される。

その結果、１ヶ月間の請求額は、
・リソースＩＤ「com1」は商品ＩＤ「product02」に対応し、１台／月で
２８、９３８円
・リソースＩＤ「com2」は商品ＩＤ「product02」に対応し、１台／月で
２８、９３８円
・リソースＩＤ「sys1」は商品ＩＤ「product03」に対応し、５０ＧＢ／月で
７、９２０円（＝ ５０ＧＢ×１５８．４円（１ＧＢ／月））
・リソースＩＤ「sys2」は商品ＩＤ「product04」に対応し、５０ＧＢ／月で
７、９２０円（＝ ５０ＧＢ×１５８．４円（１ＧＢ／月））
・リソースＩＤ「data1」は商品ＩＤ「product05」に対応し、３００ＧＢ／月で
４７、５２０円（＝３００ＧＢ×１５８．４円（１ＧＢ／月））
・合計すると、
９９、０５９円
となる。顧客の予算の上限値７ｂの範囲内で収めることができる。このような、フレーバ（性能）と使用数（又は使用量）の変更に基づくリソースそれぞれの料金は、仮想利用料金の一例である。

図２０は、第１のリソース構成における変更実施処理後の変更不可リソースＤＢの状態例を示す図である。図２０に示す変更不可リソースＤＢ３６では、顧客の予算の上限値７ｂの範囲内で変更実施処理を完了したため、変更できなかったリソースは存在しない。従って、変更不可リソースＤＢ３６は空の状態である。

図２１は、第２のリソース構成例を示す図である。図２１に示す第２のリソース構成１００２は、仮想サーバ１と、仮想サーバ２とを有する契約時のリソース構成を示している。仮想サーバ１はシステムストレージ１を含み、仮想サーバ２はシステムストレージ２と増設ストレージ１とを含む。図２１では、それぞれのリソースに対して、リソースＩＤと、商品ＩＤと対応付けて示す。

仮想サーバ１は、リソースＩＤ「com1」で特定され、商品「product01」が割り当てられる。仮想サーバ１に含まれるシステムストレージ１は、リソースＩＤ「sys1」で特定され、商品「product03」が割り当てられ、仮想サーバ１に配分された増設ストレージ１は、リソースＩＤ「data1」で特定され、商品「product04」が割り当てられる。

また、仮想サーバ２は、リソースＩＤ「com2」で特定され、商品「product01」が割り当てられる。更に、仮想サーバ２に配分されたシステムストレージ２は、リソースＩＤ「sys2」で特定され、商品「product03」が割り当てられ、仮想サーバ２に配分された増設ストレージ１は、リソースＩＤ「data1」で特定され、商品「product04」が割り当てられる。

仮想サーバ１及び２として使用される商品は「product01」で同一である。システムストレージ１及び２として使用される商品は「product03」で同一である。増設ストレージ１及び２として使用される商品は「product04」で同一である。

第２のリソース構成１００２に対して使用されるしきい値は、図１３の最適化リソース管理ＤＢ３７のデータ例を適用する。従って、その詳細な説明を省略する。

図２２は、第２のリソース構成における商品管理ＤＢのデータ例を示す図である。図２２に示す商品管理ＤＢ３１のデータ例は、商品ＩＤ「product02」の価格が「29937.6」円である以外は、図１４に示すデータ例と同様であるため、その詳細な説明を省略する。

図２３は、第２のリソース構成における契約管理ＤＢのデータ例を示す図である。図２３では、契約締結後の顧客の予算の上限値７ｂの登録前と登録後の契約管理ＤＢ３２のデータ例を示している。

登録前は、第１のリソース構成１００１の場合のデータ例（図１５）と同様であるため、その詳細な説明を省略する。登録後では、予算（上限）「ｎｕｌｌ（値無し）」が「135,000」円に変更される。また、予算（上限）の金額は、契約後の最初の登録から、リソースの最適化ごとに変更され得る値であることは、第１のリソース構成１００１と同様である。

図２４は、第２のリソース構成における課金管理ＤＢのデータ例を示す図である。図２４に示す課金管理ＤＢ３３では、図２１に示す第２のリソース構成１００２での２０１８年４月に顧客に請求した請求履歴を示している。

この例では、請求ＩＤ「billing01」について、請求額「125,813」円、請求年月「2018/04」、及び契約ＩＤ「contractA」が記憶されている。また、請求ＩＤに関連付けて、請求の明細の情報が記憶されている。

明細ＩＤ「statement01」では、商品ＩＤ「product01」が仮想サーバ１及び２で使用されるため、小計「14,933」円が示される。また、明細ＩＤ「statement02」では、商品ＩＤ「product03」が５０ＧＢの商品を特定し、システムストレージ１及び２で使用されるため、２台分として小計「15,840」円が示される。

更に、明細ＩＤ「statement03」では、商品ＩＤ「product04」が３０ＧＢの商品を特定し、増設ストレージ１及び２で使用されるため、２台分として小計「95,040」円が示される。

第２のリソース構成１００２における商品性能管理ＤＢ３５のデータ例は、第１のリソース構成における商品性能管理ＤＢ３５のデータ例と同様であるため、その詳細な説明を省略する。

図２５は、第２のリソース構成における動作性能管理ＤＢのデータ例を示す図である。図２５に示す動作性能管理ＤＢ３６では、図２１に示す第２のリソース構成１００２の使用量７ｈを含む履歴情報が時系列に蓄積され記憶されている。

この例では、時系列に、リソースＩＤ「com1」のデバイス種別は「ＣＰＵ（使用率）」であり、タイムスタンプによる収集時刻「2018/4/10 18:00」において、使用量は「９５」％であったことが示されている。また、リソースＩＤ「com2」のデバイス種別は「ＣＰＵ（使用率）」であり、タイムスタンプによる収集時刻「2018/4/10 18:00」において、使用量は「９０」％であったことが示されている。

更に、リソースＩＤ「data1」のデバイス種別は「ディスク（使用量ＧＢ）」であり、タイムスタンプによる収集時刻「2018/4/10 19:00」において、使用量は「９０」ＧＢであったことが示されている。同様に、リソースＩＤ「data2」のデバイス種別は「ディスク（使用量ＧＢ）」であり、タイムスタンプによる収集時刻「2018/4/10 19:00」において、使用量は「９０」ＧＢであったことが示されている。

この例において、収集時刻「2018/4/10 18:00」において、リソース「com1」及び「com2」の未来使用率が上限値７ｉの「８０」％を超える。従って、使用量の増加が検知される。また、リソース「data1」及び「data2」の未来使用率が下限値７ｊの「３０」％以下を示す。リソース「data1」及び「data2」は、少なくとも使用量の増加はないと予測され、削減しても顧客業務システム４００に影響はないと判断される。従って、リソース「data1」及び「data2」に対して、使用量の削減可能な状態が検知される。

図２６は、第２のリソース構成におけるリソース管理ＤＢのデータ例を示す図である。図２６では、図２１に示す第２のリソース構成１００２を構成するそれぞれのリソースの情報の変化例を示している。

図２６（Ａ）は、最適リソース配分システム３００によるリソースの縮小実施及び拡大実施によって性能（フレーバ）又は使用数が変更される前のデータ例を示している。顧客の予算（上限）（図２３）の「135,000」円内で、リソースＩＤ「com1」及び「com2」で特定されるリソースのＣＰＵ性能を上げようとしても、顧客の予算に余裕がない。

つまり、図２２の商品管理ＤＢ３１のデータ例に基づくと、
・リソースＩＤ「com1」は商品ＩＤ「product01」に対応し、１台／月で
７、４６６．４円
・リソースＩＤ「com2」は商品ＩＤ「product01」に対応し、１台／月で
７、４６６．４円
・リソースＩＤ「sys1」は商品ＩＤ「product03」に対応し、５０ＧＢ／月で
７、９２０．０円（＝ ５０ＧＢ×１５８．４円（１ＧＢ／月））
・リソースＩＤ「sys2」は商品ＩＤ「product03」に対応し、５０ＧＢ／月で
７、９２０．０円（＝ ５０ＧＢ×１５８．４円（１ＧＢ／月））
・リソースＩＤ「data1」は商品ＩＤ「product04」に対応し、３００ＧＢ／月で
４７、５２０．０円（＝３００ＧＢ×１５８．４円（１ＧＢ／月））
・リソースＩＤ「data2」は商品ＩＤ「product04」に対応し、３００ＧＢ／月で
４７、５２０．０円（＝３００ＧＢ×１５８．４円（１ＧＢ／月））
・合計し、四捨五入して小数点以下をまるめると、
１２５、８１３円
となる。この場合、予算に対して、９、１８７円の余裕しかない。

先ず、リソース「com1」の性能を、「1CPU 4GB」のフレーバ「flavor01」から「4CPU 16GB」のフレーバ「flavor02」へと変更した場合の差額は、２２、４７１．２円／月であり、予算に対する余裕では補えない。

一方、リソース「data1」を１００ＧＢに縮小することで、１５、８４０円（＝１５８．４ＧＢ／月×１００ＧＢ）の余裕を得ることができる。予算の余裕と合わせて、２５、０２７円となり、リソース「com1」のフレーバ「flavor02」へと性能を上げることが可能となる。

しかしながら、リソース「data2」を２００ＧＢに縮小しても予算が足りないため、リソース「com2」のフレーバを拡張できない。リソース「data1」の縮小によって余っている予算２、５５５円と、リソース「data2」を縮小して捻出できる額１５、８４０円を使ったとしてもリソース「com2」を拡張するための２２、４７２円に予算が４、０７７円足りていない。

図２６（Ｂ）は、リソース「data1」のみしか縮小できなかったデータ例を示している。また、図２６（Ｃ）は、リソース「com1」のみ、フレーバ「flavor02」へと性能を上げたデータ例を示している。

図２７は、第２のリソース構成における変更実施処理後の変更不可リソースＤＢの状態例を示す図である。図２７に示す変更不可リソースＤＢ３６では、顧客の予算の上限値７ｂの範囲内で変更実施処理を完了できなかったため、変更できなかったリソース「data2」とリソース「com2」とが変更不可リソースＤＢ３６に存在する。

つまり、リソース「data2」を２００ＧＢに縮小しても予算が足りないため、リソース「com2」のフレーバ（性能）を拡張できない。具体的には、リソース「data1」の縮小によって余る予算２、５５５円とリソース「data2」を縮小して捻出できる額１５、８４０円を使ってもリソース「com2」を拡張するための２２、４７２円に予算が４、０７７円不足していたからである。

このデータ例では、リソース「data2」について、推奨フレーバＩＤは「volumetype01」であり、推奨使用数は「２００」ＧＢであり、その変更額は「−１５、８４０」円であることが示されている。

一方、拡張しようと試みたリソース「com2」については、推奨フレーバＩＤは「flaver02」であり、推奨使用数は「１」台であり、その変更額は「＋２２、４７２」円であることが示されている。予算を超える金額は、６、６３２円である。

このような状況をポータル５を介して、ユーザ端末３に提示することで、顧客であるユーザは、予算を変更することができる。

図２８は、顧客による予算の変更に伴う、契約管理ＤＢのデータ遷移例を示す図である。図２８において、契約管理ＤＢ３２は、ユーザからの予算の上限値７ｂの登録に応じて、契約ＩＤ「contractA」のレコードの予算（上限）が、「１３５、０００」円から「１４５、０００」円へと変更される。１０、０００円の予算の増額により、リソース「com2」の拡張が可能となる。

図２９は、第２のリソース構成におけるリソース管理ＤＢのデータ例を示す図である。図２９では、図２１に示す第２のリソース構成１００２におけるリソース「com1」の拡張後の（図２６）、予算の増額により可能となったリソース「com2」の拡張に伴う、リソース管理ＤＢ３４のデータ遷移を示している。

図２９（Ａ）は、図２６（Ｃ）のリソース管理ＤＢ３４のデータ例に相当するため、その説明を省略する。図２９（Ｂ）は、リソース「com2」を拡張するために、先ず、リソース「data2」の使用数を、「３００」ＧＢから「２００」ＧＢへと縮小したデータ例を示している。図２９（Ｃ）は、リソース「com2」を、「flaver01」から「flaver02」へと変更することで、性能を上げたデータ例を示している。

図２８に示す予算の上限値７ｂの変更により、予算内で、リソース「com1」及びリソース「com2」の性能が改善されたため、第１のリソース構成１００１の場合と同様に、図２０に例示したように、変更不可リソースＤＢ３８にはデータが存在しない状態となる。

上述した例では、商品管理ＤＢ３１において、月単位の価格を例としたが、時間単位の価格を管理してもよい。図３０は、時間単位の価格例を示す図である。図３０では、商品ごとの価格を時間単位で示す変更不可リソースＤＢ３８のデータ例を示している。

この例では、商品「product01」について、価格は単位「台数・時間」で表され、価格は「１０．３７」円である。商品「product02」について、価格は単位「台数・時間」で表され、価格は「４１．５８」円である。商品「product03」及び商品「product04」について、価格は単位「台数・時間」で表され、価格は「０．２２」円である。他の商品についても、時間ごとに価格が管理される。

一方、時間ごとに価格を管理した変更不可リソースＤＢ３８に基づいて、契約に応じて、１ヶ月の時間数「７２０」時間を乗算することで、日単位、週単位、又は月単位等の価格を算出するようにしてもよい。

また、本実施例に係る最適リソース配分システム３００は、複数の顧客と個別の契約を締結し、クラウドサービス９２を提供することも可能である。

図３１は、複数の顧客又は契約を管理した契約管理ＤＢのデータ例を示す図である。この例では、Ａ社と予算「１００、０００」円で契約「contractA」を締結し、Ｂ社と予算「２００、０００」円で契約「contractB」を締結したことを示している。

このような複数の顧客の契約ごとの課金は、課金管理ＤＢ３３で記憶される。図３２は、複数の顧客の課金を管理する課金管理ＤＢのデータ例を示す図である。この例では、契約ＩＤ「contractA」で特定される契約に関して、請求ＩＤ「billing01」で特定される請求が、請求年月の「2018/04」に請求額「５０、０００」円で行われたことが記憶されている。更に、請求ＩＤ「billing01」で関連付けられる明細情報により、商品ごとに、明細ＩＤで使用した分の請求額が小計で示されている。

契約ＩＤ「contractA」とは異なる契約ＩＤ「contractB」で特定される契約に関して、請求ＩＤ「billing02」で特定される請求情報が記憶されている。契約ＩＤ「contractA」の請求情報と同様に、請求ＩＤ「billing02」により明細情報が関連付けられている。

このように、本実施例では、複数の契約に係る請求を課金管理ＤＢ３３を用いて管理することが可能である。

次に、ポータル５による画面表示制御によりユーザ端末３の表示装置３１５に表示される画面例について、図３３から図３７で説明する。

図３３は、契約情報を表示する画面例を示す図である。図３３に示す画面Ｇ８１は、合計額表示域８１ａ、内容表示域８１ｂ、履歴表示ボタン８１ｃ等の表示部品を有し、当月の請求金額を示す。

合計額表示域８１ａは、現在の契約に基づく期間毎の契約金額を示す。月単位であれば、１ヶ月の料金が示される。内容表示域８１ｂは、現在の契約情報を表示する。履歴表示ボタン８１ｃは、更に、過去の契約情報を参照するためのボタンである。契約情報は、各リソースの上限使用量等の組合せによって決まる料金プランに基づく。

この例では、合計額表示域８１ａに「２９、６５９」円が表示されている。内容表示域８１ｂでは、項目「リージョン」によりサービスを特定し、項目「商品・サービス」により、顧客に提供されている商品名が表示され、項目「内訳」により、性能が示される。

利用量では、請求単位当たりの使用量（物理量又は性能）が示され、項目「単価」により、請求単位当たりの商品又はサービスの金額が示される。項目「金額（円）」により、商品又はサービスごとの小計が示され、項目「合計」により、全リソースに係る合計額が示される。ユーザが履歴表示ボタン８１ｃを選択すると、図３４に示すような画面Ｇ８２が表示される。

図３４は、過去の請求情報を表示する画面例を示す図である。図３４に示す画面Ｇ８２では、主に、過去の請求情報８２ａと、現在の使用量情報８２ｂ及び将来の使用量情報８２ｃと、メッセージ８２ｄと、詳細ボタン８２ｅと、現状の予算額８２ｆと、予算変更ボタン８２ｇとが表示される。

過去の請求情報８２ａでは、過去半年間の１ヶ月ごとの請求金額が表示される。現在の使用量情報８２ｂでは、リソースごとに、現在の契約情報と使用量とが示される。将来の使用量情報８２ｃでは、それぞれのリソースに対して、今後１０年間の使用量の予測値が１年ごとに示される。メッセージ８２ｄは、使用量の予測値に基づくメッセージが表示される。詳細ボタン８２ｅは、将来の状況を確認するためのボタンである。現状の予算額８２ｆは、契約管理ＤＢ３２に顧客が登録した予算が示される。

ユーザ端末３を利用しているユーザが、詳細ボタン８２ｅを選択すると、図３５に示されるような使用量の推移を示すグラフがユーザ端末３に表示される。

図３５は、使用量の推移を示す画面例を示す図である。図３５に示す画面Ｇ８３は、月ごとの使用量の推移をグラフで示した画面である。この例では使用量の推移を示しているが、ユーザにより請求額等の推移を選択可能としてもよい。また、過去に遡る期間の長さを指定可能としてもよい。また、期間内で値を表示する間隔も、週単位、月単位、半年、１年等、適宜選択可能としてもよい。

画面Ｇ８３では、過去の９月から３月までと、現在の４月の使用量を棒グラフで示している。ユーザは、画面Ｇ８３で推移を視覚的に容易に認識できる。画面Ｇ８２（図３４）へ戻り、ユーザが、予算変更ボタン８２ｇを選択すると、図３６に示されるような画面Ｇ８４がユーザ端末３に表示される。

図３６は、予算を変更するための画面例を示す図である。図３６に示す画面Ｇ８４は、現予算表示域８４ａ、新たな予算入力域８４ｂ、登録ボタン８４ｃ、キャンセル８４ｄ、見直しボタン８４ｅ、内容表示ボタン８４ｆ等を有する。

現予算表示域８４ａには、契約管理ＤＢ３２に設定されている予算が表示される。新たな予算入力域８４ｂには、ユーザによって新たに設定する予算の値が入力される。

登録ボタン８４ｃは、ユーザが新たな予算入力域８４ｂに入力した値を有効とする場合に選択される。登録ボタン８４ｃが選択されると、入力された値が予算の上限値７ｂとして、ポータル５を介して契約管理ＤＢ３２において該当する予算が変更される。

キャンセル８４ｄは、ユーザが新たな予算入力域８４ｂに入力した値を無効とする場合に選択される。キャンセル８４ｄが選択されると、入力された値は画面Ｇ８４において消去される。

見直しボタン８４ｅは、ユーザが新たな予算入力域８４ｂに入力した値でリソース配分の見直しを行うために選択される。見直しボタン８４ｅの選択に応じて、ポータル５は、最適リソース配分システム３００に第１見直し要求６ａを送信し、最適なリソース判断処理が実行される。この場合が、最適なリソース判断処理の逐次実行に相当する。内容表示ボタン８４ｆは、リソース見直しによる結果を幼児するために選択される。

ユーザが内容表示ボタン８４ｆを選択すると、見直し内容要求がポータル５を介して最適リソース配分システム３００に送信され、図３７に示すようなリソース見直しの結果を示す画面が表示される。

図３７は、リソース見直しの結果を示す画面例を示す図である。図３７に示す画面Ｇ８５では、変更不可リソースＤＢ３８のデータに基づいて、リソース見直しの結果を表示する画面である。変更不可リソースＤＢ３８にデータが存在しない場合、「リソース見直しは成功しました」等のメッセージを表示してもよい。

画面Ｇ８５は、縮小又は拡張されたリソースごとに金額を示している。縮小されたリソースには負の金額が示され、拡張されたリソースには正の金額が示される。

この例では、リソース見直しにより、リソースの「システムストレージ M1(100GB)」を縮小することで３、０００円を削減できることを示している。一方、リソースの「増設ディスク(500GB)」を拡張する必要があり、１０、０００円の増加となること、また、リソースの「仮想サーバ S-5タイプ(仮想CPU4、メモリ32GB)」を拡張する必要があり、５、０００円の増加となることが示されている。この状況により、予算に対して２、０００円分超過してしまうことが示されている。

このように、現状のリソース構成において、予算が超過するリソースと、予算が余るリソースとが示されることにより、ユーザは現状のリソース構成の状況を理解し易くなる。また、ユーザは、画面Ｇ８４（図３６）に戻り、予算を新たな予算入力域８４ｂに再入力し、必要に応じて結果を画面Ｇ８５で確認し、見直しボタン８４ｅを選択するのみで、リソース見直しを行える。

本実施例は、図３及び図４で示すような、商品性能管理ＤＢ３５、動作性能管理ＤＢ３６、最適化リソース管理ＤＢ３７、及び変更不可リソースＤＢ３８を備えることで、上述したような様々な効果を得る。

一方、このようなＤＢ３５〜３８を備えないクラウドサーバ９０では、顧客業務システム４００の稼働中において、種類も様々な複数のリソースを対象として、枯渇状態、余剰状態等のリソースを特定できない。また、ユーザは、過去の請求額から予算を自身で予測しなければならず、予算内で稼働中の費用が収まらない場合には、予想外の出費となってしまう。また、どのリソースをどの程度拡大すればよいのか、そのためにどのリソースをどの程度削減可能なのかを知る手段がない。

上述した、性能情報収集システム２００、最適リソース配分システム３００、及びポータル５によって行われる上述した様々な処理は、プラン提示プログラムに従って１又は複数のサーバ装置１００によって行われる処理の一例である。一例として、１台の情報処理装置が図３８に示すように機能構成を有するようにしてもよい。

図３８は、本実施例における情報処理装置の機能構成例を示す図である。図３８に示す情報処理装置１００ａは、図１に示すサーバ装置１００と同様のハードウェア構成を有し、ネットワークを介して、ユーザ端末３、顧客業務システム４００、及びＤＢサーバ８００ａのそれぞれと通信Ｉ／Ｆ１１７により通信可能である。

情報処理装置１００ａは、収集部２００ａと、配分部３００ａと、表示制御部５ａとを有する。収集部２００ａと、配分部３００ａと、表示制御部５ａとは、ＣＰＵ１１１が対応するそれぞれのプログラムを実行することにより実現される。また、情報処理装置１００ａの記憶部１３０には、最適化リソース管理ＤＢ３７、変更不可リソースＤＢ３８等が記憶される。

収集部２００ａは、図６で説明した性能情報収集処理を行う処理部である。配分部３００ａは、図７〜図１１で説明した最適リソース配分処理を行う処理部であり、算出部３１０ａと、選択部３３０ａとを有する。算出部３１０ａは、図８で説明した変更対象リソースの解析処理を行う処理部である。選択部３３０ａは、図９〜図１０で説明した変更実施可否の判定処理と、図１１で説明した変更実施処理とを行う処理部である。表示制御部５ａは、図５で説明したポータル表示制御処理を行う処理部である。

図３８では、一例として、商品管理ＤＢ３１、契約ＤＢ３２、課金管理ＤＢ３３、リソース管理ＤＢ３４、商品性能管理ＤＢ３５、動作性能管理ＤＢ３６等は、ＤＢサーバ８００ａで管理される構成を示しているが、この例に限定されない。ＤＢ３１〜３６の１以上を情報処理装置１００ａの記憶部１３０に保持してもよい。また、ＤＢ３１〜３６を２以上のＤＢサーバ８００ａで管理されていてもよい。また、様々な情報の送受信は、図３等で説明した通りであるため、詳細な説明は省略する。

上述より、本実施例によれば、ユーザは、予算を入力するのみで、予算内でリソース構成に含まれる複数のリソースそれぞれの使用量に係る物理量又は性能を選択することができる。

本実施例において、未来使用量はリソース予測量の一例であり、予算及び複数種類の各リソースの上限使用量等の組み合せに基づく契約情報が料金プランの一例である。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、主々の変形や変更が可能である。

以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
ユーザごとに該ユーザが利用する複数種類のリソースの使用量を記憶部に記録し、
前記複数種類のリソースそれぞれについて、前記記憶部に記録された使用量に基づき予測してリソース利用予測量を算出し、
前記複数種類のリソースそれぞれについての前記リソース利用予測量と、前記ユーザの予算とに基づき、前記複数種類のリソースの使用量に応じた複数の料金プランから、１又は複数の料金プランを選択し、
選択した前記１又は複数の料金プランを表示装置に表示させる
処理をコンピュータに実行させるプラン提示プログラム。
（付記２）
前記コンピュータに、
前記ユーザが契約している料金プランの見直しを要求する第１要求に応じて、前記複数種類のリソースそれぞれの前記リソース利用予測量を算出させ、前記１又は複数の料金プランを選択する
処理を実行させることを特徴とする付記１記載のプラン提示プログラム。
（付記３）
前記コンピュータに、
前記見直しの結果を要求する第２要求に応じて、前記第１要求に応じて選択した前記１又は複数の料金プランを前記表示装置に表示させる
処理を実行させることを特徴とする付記２記載のプラン提示プログラム。
（付記４）
前記コンピュータに、
前記複数種類のリソースの種類ごとのしきい値に基づいて、前記複数種類のリソースそれぞれに対して使用量の変更の有無を判定し、
前記複数種類のリソースのうち、前記変更が使用量の拡張となる第１リソースに対して、該第１リソースを拡張することで前記予算を超える場合には、該第１リソースの仮想利用金額と該拡張の内容とを示す第１変更情報とを前記記憶部に記憶し、
前記第２要求に応じて、前記記憶部に記憶した前記第１変更情報に基づいて、前記１又は複数の料金プランを選択する
処理を実行させることを特徴とする付記３記載のプラン提示プログラム。
（付記５）
前記コンピュータに、
前記複数種類のリソースのうち、前記変更が使用量の縮小となる第２リソースに対して、該第２リソースを縮小することで、前記予算内で前記第１リソースの拡張を可能とするか否かを判断し、
前記第２リソースを縮小することによっても、前記予算内で前記第１リソースの拡張により前記予算を超える場合には、前記第１変更情報と、該第２リソースの仮想利用金額と該縮小の内容とを示す第２変更情報とを前記記憶部に記憶し、
前記第２要求に応じて、前記記憶部に記憶した前記第１変更情報と前記第２変更情報とに基づいて、前記１又は複数の料金プランを選択する
処理を実行させることを特徴とする付記４記載のプラン提示プログラム。
（付記６）
前記コンピュータに、
前記第２リソースを縮小することで、前記予算内で前記第１リソースの拡張が可能となる場合、前記複数種類のリソースの利用において、前記使用量を縮小した前記第２リソースの利用と、該使用量を拡張した前記第１リソースの利用とを有効にさせる
ことを特徴とする付記５記載のプラン提示プログラム。
（付記７）
前記しきい値は、リソースの枯渇を判定する使用量の上限値と、リソースの余剰を判定する使用量の下限値とを含むことを特徴とする付記４乃至６のいずれか一項記載のプラン提示プログラム。
（付記８）
ユーザごとに該ユーザが利用する複数種類のリソースの使用量を記憶部に記録し、
前記複数種類のリソースそれぞれについて、前記記憶部に記録された使用量に基づき予測してリソース利用予測量を算出し、
前記複数種類のリソースそれぞれについての前記リソース利用予測量と、前記ユーザの予算とに基づき、前記複数種類のリソースの使用量に応じた複数の料金プランから、１又は複数の料金プランを選択し、
選択した前記１又は複数の料金プランを表示装置に表示させる
処理をコンピュータが実行するプラン提示方法。
（付記９）
ユーザごとに該ユーザが利用する複数種類のリソースの使用量を記憶部に記録する収集部と、
前記複数種類のリソースそれぞれについて、前記記憶部に記録された使用量に基づき予測してリソース利用予測量を算出する算出部と、
前記複数種類のリソースそれぞれについての前記リソース利用予測量と、前記ユーザの予算とに基づき、前記複数種類のリソースの使用量に応じた複数の料金プランをから、１又は複数の料金プランを選択する選択部と、
選択した前記１又は複数の料金プランを表示装置に表示させる表示制御部と
を有する情報処理装置。

３ ユーザ端末
５ ポータル
６ａ 第１見直し要求、 ６ｂ 第２見直し要求
７ａ 商品単価、 ７ｂ 予算の上限値
７ｃ 請求額、 ７ｄ リソース一覧
７ｅ リソース変更情報、 ７ｆ 商品性能情報
７ｇ 過去使用量、 ７ｈ 使用量
７ｈ 使用量
７ｉ 上限値、 ７ｊ 下限値
７ｋ、７ｋ’ 変更不可リソース情報
３１ 商品管理ＤＢ、 ３２ 契約管理ＤＢ
３３ 課金管理ＤＢ、 ３４ リソース管理ＤＢ
３５ 商品性能管理ＤＢ、 ３６ 動作性能管理ＤＢ
３７ 最適化リソース管理ＤＢ
３８ 変更不可リソースＤＢ
９０ クラウドサーバ、 ９２ クラウドサービス
１００ サーバ装置、 １００ａ 情報処理装置
２００ 性能情報収集システム、 ２００ａ 収集部
３００ 最適リソース配分システム、 ３００ａ 分配部
３１０ａ 算出部、 ３３０ａ 選択部
４００ 顧客業務システム
８００ａ ＤＢサーバ
１０００ システム
１００１、１００２ リソース構成

Claims (7)

1. ユーザごとに該ユーザが利用する複数種類のリソースの使用量を記憶部に記録し、
   前記複数種類のリソースそれぞれについて、前記記憶部に記録された使用量に基づき予測してリソース利用予測量を算出し、
   前記複数種類のリソースそれぞれについての前記リソース利用予測量と、前記ユーザの予算とに基づき、前記複数種類のリソースの使用量に応じた複数の料金プランから、１又は複数の料金プランを選択し、
   選択した前記１又は複数の料金プランを表示装置に表示させる
   処理をコンピュータに実行させるプラン提示プログラム。
2. 前記コンピュータに、
   前記ユーザが契約している料金プランの見直しを要求する第１要求に応じて、前記複数種類のリソースそれぞれの前記リソース利用予測量を算出させ、前記１又は複数の料金プランを選択する
   処理を実行させることを特徴とする請求項１記載のプラン提示プログラム。
3. 前記コンピュータに、
   前記見直しの結果を要求する第２要求に応じて、前記第１要求に応じて選択した前記１又は複数の料金プランを前記表示装置に表示させる
   処理を実行させることを特徴とする請求項２記載のプラン提示プログラム。
4. 前記コンピュータに、
   前記複数種類のリソースの種類ごとのしきい値に基づいて、前記複数種類のリソースそれぞれに対して使用量の変更の有無を判定し、
   前記複数種類のリソースのうち、前記変更が使用量の拡張となる第１リソースに対して、該第１リソースを拡張することで前記予算を超える場合には、該第１リソースの仮想利用金額と該拡張の内容とを示す第１変更情報とを前記記憶部に記憶し、
   前記第２要求に応じて、前記記憶部に記憶した前記第１変更情報に基づいて、前記１又は複数の料金プランを選択する
   処理を実行させることを特徴とする請求項３記載のプラン提示プログラム。
5. 前記コンピュータに、
   前記複数種類のリソースのうち、前記変更が使用量の縮小となる第２リソースに対して、該第２リソースを縮小することで、前記予算内で前記第１リソースの拡張を可能とするか否かを判断し、
   前記第２リソースを縮小することによっても、前記予算内で前記第１リソースの拡張により前記予算を超える場合には、前記第１変更情報と、該第２リソースの仮想利用金額と該縮小の内容とを示す第２変更情報とを前記記憶部に記憶し、
   前記第２要求に応じて、前記記憶部に記憶した前記第１変更情報と前記第２変更情報とに基づいて、前記１又は複数の料金プランを選択する
   処理を実行させることを特徴とする請求項４記載のプラン提示プログラム。
6. ユーザごとに該ユーザが利用する複数種類のリソースの使用量を記憶部に記録し、
   前記複数種類のリソースそれぞれについて、前記記憶部に記録された使用量に基づき予測してリソース利用予測量を算出し、
   前記複数種類のリソースそれぞれについての前記リソース利用予測量と、前記ユーザの予算とに基づき、前記複数種類のリソースの使用量に応じた複数の料金プランから、１又は複数の料金プランを選択し、
   選択した前記１又は複数の料金プランを表示装置に表示させる
   処理をコンピュータが実行するプラン提示方法。
7. ユーザごとに該ユーザが利用する複数種類のリソースの使用量を記憶部に記録する収集部と、
   前記複数種類のリソースそれぞれについて、前記記憶部に記録された使用量に基づき予測してリソース利用予測量を算出する算出部と、
   前記複数種類のリソースそれぞれについての前記リソース利用予測量と、前記ユーザの予算とに基づき、前記複数種類のリソースの使用量に応じた複数の料金プランから、１又は複数の料金プランを選択する選択部と、
   選択した前記１又は複数の料金プランを表示装置に表示させる表示制御部と
   を有する情報処理装置。

Images