(57)【要約】【課題】一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータにおいて、現在の残高がいくらあるのか、いつ頃割り当てられた予算を消費が上回りそうか、といった判断や管理を総合的に行うことを可能とする。【解決手段】クラウドサービス管理コンピュータ１００に、一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信する受信モジュール１２１と、独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換する変換モジュール１１１と、変換された一以上の前記標準データに基づき、一以上のクラウドサービスを統合したデータを出力する統合モジュール１１２と、を備える。【選択図】図１
2020201739.tif 000002
【特許請求の範囲】
【請求項１】
一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータであって、
前記一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信する受信手段と、
前記独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換する変換手段と、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを統合したデータを出力する統合手段と、
を備えるクラウドサービス管理コンピュータ。
【請求項２】
前記変換手段は、
前記標準データに変換する際に、当該標準データに対応するクラウドサービスに予め設けていた予算に関する予算項目を当該標準データに付与し、
さらに、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを考慮した請求内容を算出する算出手段と、
当該請求内容に対応したクラウドサービスの使用量に基づく予算からの残高を出力する出力手段と、
を備える請求項１に記載のクラウドサービス管理コンピュータ。
【請求項３】
前記変換手段は、
前記標準データに変換する際に、当該標準データに対応するクラウドサービスに予め設けていた予算に関する予算項目を当該標準データに付与し、
さらに、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスのなかから指定された単数または複数のクラウドサービスについて、任意の項目の集計データを算出する算出手段と、
当該任意の項目の内容に対応したクラウドサービスの集計データを出力する出力手段と、
を備える請求項１に記載のクラウドサービス管理コンピュータ。
【請求項４】
前記請求データに基づいて、所定期間の当該クラウドサービスの使用量から予測モデルを生成する予測モデル生成手段と、
前記予測モデルを用いて、当該クラウドサービスの将来の使用量を予測する使用量予測手段と、
を備える請求項１から請求項３のいずれか一項に記載のクラウドサービス管理コンピュータ。
【請求項５】
前記請求データに基づいて、所定期間の当該クラウドサービスの使用料を学習する使用料学習手段と、
学習した使用料から、当該クラウドサービスの将来の残高を予測する残高予測手段と、
を備える請求項１から請求項４のいずれか一項に記載のクラウドサービス管理コンピュータ。
【請求項６】
一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理システムであって、
前記一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信する受信手段と、
前記独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換する変換手段と、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを統合したデータを出力する統合手段と、
を備えるクラウドサービス管理システム。
【請求項７】
一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理方法において、
前記一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信するステップと、
前記独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換するステップと、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを統合したデータを出力するステップと、
を備えるクラウドサービス管理方法。
【請求項８】
一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、
前記一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信するステップ、
前記独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換するステップ、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを統合したデータを出力するステップ、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、統合したデータを出力させる手法に関する。
【背景技術】
【０００２】
近年、クラウドシステムの発展により、Ａｚｕｒｅ（Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ）、ＡＷＳ（アマゾン  テクノロジーズ  インコーポレイテッド）、Ｓａｌｅｓｆｏｒｃｅ（株式会社セールスフォース・ドットコム）等、様々なクラウドサービスが提供され、その利用が活発となっている。このような環境の変化に伴い、企業ユーザがクラウドサービスを利用する機会も増加しており、そのような場合にクラウドサービスの消費を、部門毎あるいは個人毎に管理することが難しいという、特有の問題が発生する。
【０００３】
企業ユーザがクラウドサービスを利用している場合、ユーザがクラウドサービスの消費を確認・管理するためには、各クラウドサービス提供業社の消費管理ポータルに、それぞれログインしなければならない。しかし、クラウドサービス提供業社は、例えば、サービス名称・消費量・コスト等の同様な管理項目に不統一な名称をつけており、かつ、複数のユーザの利用毎に発生する消費を確認・管理するためのデータ量が膨大であるため、ユーザはそれぞれのサービスの料金の比較や集計が困難である。また、クラウドサービス提供業社によっては、契約部門に対してＩＤとパスワードを一つしか付与しないため、部門毎のユーザの多いエンタープライズ企業では、各部門にクラウドサービスの消費を管理させることが困難となっている。さらに、ユーザ毎に特定レコードを見せるか見せないかといったアクセス権限のコントロールを行うことが難しい、又は、アクセス権限の設定のための手間がかかる、という問題もある。このように、各クラウドサービス提供業社は、ユーザに消費量を知らせることを中心として情報提供しているだけであるため、ユーザは自部門に割り当てられた予算と比較して、現在の残高がいくらあるのか、いつ頃割り当てられた予算を消費が上回りそうか、といった判断を行うことが非常に困難である。
【０００４】
複数のクラウドを利用する場合において、監視データの分析にかかるコストの低減を図りうる方法が提案されている（特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１８−１７０７１５号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１の技術では、クラウドが複数ある場合に、クラウド管理装置が各クラウドの監視データの分析にかかる料金を特定し、その料金に基づいて分析処理をするクラウドを自動で選択することでコストの低減を行うことが可能であるが、ユーザ自身が、予算と比較して現在の残高がいくらあるのかを把握したり、いつ頃割り当てられた予算を消費が上回りそうか、といった判断を行ったりすることは難しい。また、特許文献１の技術では、クラウドが単数であろうと複数であろうと、クラウド毎に異なる消費を確認・管理するためのデータを変換処理して、ユーザが予算と支出の管理を容易に行うことはできない。
【０００７】
この課題に対し、本発明の発明者は、一以上のクラウドサービスから、独自のフォーマットを備えた請求データを受信して互いに処理可能な標準データに変換し、一以上のクラウドサービスを統合したデータとして出力可能であることに着目した。具体的には、各クラウドサービス提供業者の請求データを、「部門」「システム名」「利用した日付」等のキーワードで絞り込んで特定することにより、予算管理のための項目群を追加して、標準データを作成することで、ユーザが予算と支出の管理を行うことを可能とする。
【０００８】
本発明は、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、一以上のクラウドサービスを統合したデータを出力させることで、ユーザが自部門の予算と比較して、現在の残高がいくらあるのか、いつ頃割り当てられた予算を消費が上回りそうか、といった判断や管理を総合的に行うことが可能なクラウドサービス管理コンピュータ、クラウドサービス管理方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明では、以下のような解決手段を提供する。
【００１０】
第１の特徴に係る発明は、
一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータであって、
前記一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信する受信手段と、
前記独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換する変換手段と、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを統合したデータを出力する統合手段と、
を備えるクラウドサービス管理コンピュータを提供する。
【００１１】
第１の特徴に係る発明によれば、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータにおいて、前記一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信する受信手段と、前記独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換する変換手段と、変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを統合したデータを出力する統合手段と、を備える。
【００１２】
第１の特徴に係る発明は、クラウドサービス管理コンピュータのカテゴリであるが、クラウドサービス管理システム、クラウドサービス管理方法、及びプログラムであっても同様の作用、効果を奏する。
【００１３】
第２の特徴に係る発明は、第１の特徴に係る発明であるクラウドサービス管理コンピュータであって、
前記変換手段は、
前記標準データに変換する際に、当該標準データに対応するクラウドサービスに予め設けていた予算に関する予算項目を当該標準データに付与し、
さらに、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを考慮した請求内容を算出する算出手段と、
当該請求内容に対応したクラウドサービスの使用量に基づく予算からの残高を出力する出力手段と、
を備えるクラウドサービス管理コンピュータを提供する。
【００１４】
第２の特徴に係る発明によれば、第１の特徴に係る発明であるクラウドサービス管理コンピュータにおいて、前記変換手段は、前記標準データに変換する際に、当該標準データに対応するクラウドサービスに予め設けていた予算に関する予算項目を当該標準データに付与し、さらに、変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを考慮した請求内容を算出する算出手段と、当該請求内容に対応したクラウドサービスの使用量に基づく予算からの残高を出力する出力手段と、を備える。
【００１５】
第３の特徴に係る発明は、第１又は第２の特徴に係る発明であるクラウドサービス管理コンピュータであって、
前記変換手段は、
前記標準データに変換する際に、当該標準データに対応するクラウドサービスに予め設けていた予算に関する予算項目を当該標準データに付与し、
さらに、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスのなかから指定された単数または複数のクラウドサービスについて、任意の項目の集計データを算出する算出手段と、
当該任意の項目の内容に対応したクラウドサービスの集計データを出力する出力手段と、
を備えるクラウドサービス管理コンピュータを提供する。
【００１６】
第３の特徴に係る発明によれば、第１又は第２の特徴に係る発明であるクラウドサービス管理コンピュータにおいて、前記変換手段は、前記標準データに変換する際に、当該標準データに対応するクラウドサービスに予め設けていた予算に関する予算項目を当該標準データに付与し、さらに、変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスのなかから指定された単数または複数のクラウドサービスについて、任意の項目の集計データを算出する算出手段と、当該任意の項目の内容に対応したクラウドサービスの集計データを出力する出力手段と、を備える。
【００１７】
第４の特徴に係る発明は、第１から第３のいずれかの特徴に係る発明であるクラウドサービス管理コンピュータであって、
前記請求データに基づいて、所定期間の当該クラウドサービスの使用量から予測モデルを生成する予測モデル生成手段と、
前記予測モデルを用いて、当該クラウドサービスの将来の使用量を予測する使用量予測手段と、
を備えるクラウドサービス管理コンピュータを提供する。
【００１８】
第４の特徴に係る発明によれば、第１から第３のいずれかの特徴に係る発明であるクラウドサービス管理コンピュータにおいて、前記請求データに基づいて、所定期間の当該クラウドサービスの使用量から予測モデルを生成する予測モデル生成手段と、前記予測モデルを用いて、当該クラウドサービスの将来の使用量を予測する使用量予測手段と、を備える。
【００１９】
第５の特徴に係る発明は、第１から第４のいずれかの特徴に係る発明であるクラウドサービス管理コンピュータであって、
前記請求データに基づいて、所定期間の当該クラウドサービスの使用料を学習する使用料学習手段と、
学習した使用料から、当該クラウドサービスの将来の残高を予測する残高予測手段と、
を備えるクラウドサービス管理コンピュータを提供する。
【００２０】
第５の特徴に係る発明によれば、第１から第４のいずれかの特徴に係る発明であるクラウドサービス管理コンピュータにおいて、前記請求データに基づいて、所定期間の当該クラウドサービスの使用料を学習する使用料学習手段と、学習した使用料から、当該クラウドサービスの将来の残高を予測する残高予測手段と、を備える。
【００２１】
第６の特徴に係る発明は、
一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理システムであって、
前記一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信する受信手段と、
前記独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換する変換手段と、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを統合したデータを出力する統合手段と、
を備えるクラウドサービス管理システムを提供する。
【００２２】
第７の特徴に係る発明は、
一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理方法において、
前記一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信するステップと、
前記独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換するステップと、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを統合したデータを出力するステップと、
を備えるクラウドサービス管理方法を提供する。
【００２３】
第８の特徴に係る発明は、
一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、
前記一以上のクラウドサービスから、当該クラウドサービス独自のフォーマットを備える請求データを各々のクラウドサービスから受信するステップ、
前記独自のフォーマットを備えた請求データを、互いに処理可能な標準データに変換するステップ、
変換された一以上の前記標準データに基づき、前記一以上のクラウドサービスを統合したデータを出力するステップ、
を実行させるためのプログラムを提供する。
【発明の効果】
【００２４】
本発明は、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、一以上のクラウドサービスを統合したデータを出力させることで、ユーザが自部門の予算と比較して、現在の残高がいくらあるのか、いつ頃割り当てられた予算を消費が上回りそうか、といった判断や管理を総合的に行うことが可能なクラウドサービス管理コンピュータ、クラウドサービス管理方法、及びプログラムを提供することが可能となる。
【図面の簡単な説明】
【００２５】
【図１】本発明の好適な実施の形態の概要図である。
【図２】クラウドサービス管理コンピュータ１００によるシステムの概要と機能ブロック図である。
【図３】クラウドサービス管理処理のフローチャート図である。
【図４】残高出力処理又は集計データ出力処理を行う場合のシステムの概要と機能ブロック図である。
【図５】残高出力処理のフローチャート図である。
【図６】集計データ出力処理のフローチャート図である。
【図７】標準データへの変換処理のフローチャート図である。
【図８】使用量予測処理と残高予測処理を行う場合のシステムの概要と機能ブロック図である。
【図９】使用量予測処理のフローチャート図である。
【図１０】残高予測処理のフローチャート図である。
【図１１】クラウドサービス管理処理の請求データと統合した標準データの出力の一例である。
【図１２】クラウドサービス管理処理の請求データと統合した標準データの出力の一例である。
【図１３】残高出力処理の請求データと統合した標準データの出力の一例である。
【図１４】任意項目追加処理のフローチャート図である。
【図１５】標準データに任意項目追加処理を行う場合のデータ概要である。
【図１６】ＮｏＳＱＬによる予算支出管理を行う場合の利点を示す一例である。
【発明を実施するための形態】
【００２６】
以下、本発明を実施するための最良の形態について図を参照しながら説明する。なお、これはあくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。
【００２７】
［クラウドサービス管理コンピュータ１００によるシステムの概要］
図１は、本発明の好適な実施形態の概要図である。この図１に基づいて、本発明の概要を説明する。クラウドサービス管理コンピュータ１００によるシステムは、図２に示すように、クラウドサービス管理コンピュータ１００、クラウドサービス２００、ユーザ端末３００、通信網４００から構成される。クラウドサービス管理コンピュータ１００はクラウドサービス管理システムを運用可能な装置であるとする。ここでは、デスクトップ型のコンピュータを図示しているが、ネットワーク上のコンピュータや、ノートパソコン、スマートフォン、タブレット端末等であってよい。クラウドサービス管理コンピュータ１００は、各処理を実現するために、一つに限らず複数のコンピュータで構成されていてもよく、また、実在する装置に限らず仮想的な装置やクラウドであってもよい。クラウドサービス管理コンピュータ１００は、制御部１１０、通信部１２０、記憶部１３０、入力部１４０、出力部１５０、から構成される。制御部１１０には、変換モジュール１１１、統合モジュール１１２を備える。制御部１１０は、各モジュールの実現のために、必要に応じて通信部１２０、記憶部１３０、入力部１４０、出力部１５０と協働する。通信部１２０には、受信モジュール１２１を備える。通信部１２０は、必要に応じて制御部１１０と協働する。クラウドサービス２００は、ユーザの利用する一以上のクラウドサービスである。Ａｚｕｒｅ、ＡＷＳ、Ｓａｌｅｓｆｏｒｃｅ等、クラウドサービス提供業者の種類は問わない。図１、図２では、便宜上クラウドＸとクラウドＹとして２つ図示しているが、単数であっても、３つ以上のクラウドサービスであっても問題ない。ユーザ端末３００は、クラウドサービス管理コンピュータ１００を利用するユーザが使用する端末である。ここでは、ディスプレイと一体型のコンピュータを図示しているが、デスクトップ型のコンピュータ、ノートパソコン、スマートフォン、タブレット端末、ウェアラブル端末等であってよい。数は一つに限らず複数であってよい。通信網４００は、クラウドサービス管理コンピュータ１００とクラウドサービス２００とユーザ端末３００間の通信を可能とする通信網である。
【００２８】
図１のクラウドサービス管理システムにおいて、まず、クラウドサービス管理コンピュータ１００の受信モジュール１２１は、クラウドサービス２００から、請求データを受信する（ステップＳ０１）。ここでは、利用しているすべてのクラウドサービス２００から、それぞれ請求データを受信するものとする。本発明における請求データとは、当該クラウドサービス独自のフォーマットによるもので、それぞれ、使用量、請求額、請求期間、部門、等を特定するための情報を含むものとする。ステップＳ０１の、請求データを受信するタイミングは、２４時間毎、毎日＊＊時、等の設定と変更が可能であるものとする。クラウドサービス管理コンピュータ１００に対する負荷の低いタイミングや、利用料金の安いタイミングで、ステップＳ０１のみを実施してもよい。受信した請求データは、記憶部１３０に記憶してもよいし、外部のコンピュータやデータベースやクラウドサービス等に記憶してもよい。図１では、ステップＳ０１で、クラウドＸから、「クラウドＸ、サービス名：仮想マシン、使用期間：２０１９／１／１〜、使用済み：５６時間、合計使用料：６６，０００円、用途：ＳＥＯシステム、部門：マーケティング」という請求データを、クラウドＹから「クラウドＹ、サービス名：仮想マシン、利用期間：２０１９−０１−０１〜、使用量：６０分、消費金額：３４，０００円、用途：ＳＥＯシステム、部門：マーケティング」という請求データを、受信した例を図示している。ここでは、説明の都合上、各クラウドサービスから１つずつのみ請求データを受信した例として記載しているが、実際には、複数のユーザの各クラウドサービスの利用毎に請求データが発生するため、データ量は膨大であり、ユーザが手動で処理することは困難である。
【００２９】
次に、クラウドサービス管理コンピュータ１００の変換モジュール１１１は、受信した請求データを、互いに処理可能な標準データへと変換する（ステップＳ０２）。変換モジュール１１１は、請求データを標準データへ変換するための処理として、名称寄せ、書式統一、単位変換、数値計算、メタデータ作成、任意項目追加、の各処理を行う。標準データへの変換処理の詳細については、後述する。図１では、ステップＳ０１で受信した請求データを、「クラウドＸ、サービス名：仮想マシン、請求期間：２０１９年０１月０１日−、消費量：５６時間、請求額：６６，０００円、部門：マーケティング、予算：１，０００，０００円、メタデータ：（用途：ＳＥＯシステム）」という標準データと、「クラウドＹ、サービス名：仮想マシン、請求期間：２０１９年０１月０１日−、使用量：１時間、請求額：３４，０００円、部門：マーケティング、予算：１，０００，０００円、メタデータ：（用途：ＳＥＯシステム）」という標準データとに、変換した例を図示している。ここで、それぞれの請求データに、標準データとして「予算：１，０００，０００円」という予算に関する予算項目を、任意項目として追加している。任意項目の追加方法の詳細については、後述する。
【００３０】
最後に、クラウドサービス管理コンピュータ１００の統合モジュール１１２は、ステップＳ０２で変換した標準データに基づき、クラウドサービスを統合したデータを、ユーザ端末３００に出力させる（ステップＳ０３）。クラウドサービスを統合したデータとは、具体的には、サービスの消費（利用実績）を統一したデータ、及び任意に追加した項目、及び計算処理されて追加される任意の項目で構成されるデータである。図１の場合は、「クラウドＸ、サービス名：仮想マシン、請求期間：２０１９年０１月０１日−、消費量：５６時間、請求額：６６，０００円、部門：マーケティング、予算：１，０００，０００円、メタデータ：（用途：ＳＥＯシステム）」という標準データと、「クラウドＹ、サービス名：仮想マシン、請求期間：２０１９年０１月０１日−、使用量：１時間、請求額：３４，０００円、部門：マーケティング、予算：１，０００，０００円、メタデータ：（用途：ＳＥＯシステム）」という標準データに基づき、「クラウドＸ＆クラウドＹ、請求期間：２０１９年０１月０１日―、使用量：５７時間、請求額：１００，０００円、部門：マーケティング、予算：１，０００，０００円、メタデータ：（用途：ＳＥＯシステム）」というデータを作成できる。このデータを基にして、「予算：１，０００，０００円」に対して、「請求額：１００，０００円」であるため、「残高：９００，０００円」であることが算出できる。この、予算に対する残高を含めたものを、標準データを統合したデータとして、ユーザ端末３００に出力させる。図１では、「統合ＶＩＥＷ（クラウドＸ  ＆  クラウドＹ）、サービス名：仮想マシン、請求期間：２０１９年０１月０１日−、使用量：５７時間、請求額：１００、０００円、部門：マーケティング、予算：１,０００,０００円、残高：９００,０００円」という内容を表示した例を図示している。
【００３１】
以上のように、本発明によれば、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、一以上のクラウドサービスを統合したデータを出力させることで、ユーザが自部門の予算と比較して、現在の残高がいくらあるのか、いつ頃割り当てられた予算を消費が上回りそうか、といった判断や管理を総合的に行うことが可能なクラウドサービス管理コンピュータ、クラウドサービス管理方法、及びプログラムを提供することが可能となる。
【００３２】
［各機能の説明］
図２は、クラウドサービス管理コンピュータ１００によるシステムの概要と、クラウドサービス管理コンピュータ１００の機能ブロック図である。クラウドサービス管理コンピュータ１００によるシステムは、クラウドサービス管理コンピュータ１００、クラウドサービス２００、ユーザ端末３００、通信網４００から構成される。
【００３３】
クラウドサービス管理コンピュータ１００はクラウドサービス管理システムを運用可能な装置であるとする。ここでは、デスクトップ型のコンピュータを図示しているが、ネットワーク上のコンピュータや、ノートパソコン、スマートフォン、タブレット端末等であってよい。クラウドサービス管理コンピュータ１００は、各処理を実現するために、一つに限らず複数のコンピュータで構成されていてもよく、また、実在する装置に限らず仮想的な装置やクラウドであってもよい。クラウドサービス管理コンピュータ１００は、制御部１１０、通信部１２０、記憶部１３０、入力部１４０、出力部１５０、から構成される。
【００３４】
クラウドサービス管理コンピュータ１００は、制御部１１０として、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）等を備える。制御部１１０には、変換モジュール１１１、統合モジュール１１２を備える。制御部１１０は、各モジュールの実現のために、必要に応じて通信部１２０、記憶部１３０、入力部１４０、出力部１５０と協働する。
【００３５】
クラウドサービス管理コンピュータ１００は、通信部１２０として、他の機器と通信可能にするためのデバイス等を備える。通信方式は、無線であっても有線であってもよい。通信部１２０には、受信モジュール１２１を備える。通信部１２０は、必要に応じて制御部１１０と協働する。
【００３６】
クラウドサービス管理コンピュータ１００は、記憶部１３０を備え、請求データ、標準データ、等の必要なデータを記憶する。データのストレージ部は、外部のコンピュータやクラウドにあってもよい。記憶部１３０は、必要に応じて制御部１１０と協働する。
【００３７】
クラウドサービス管理コンピュータ１００は、入力部１４０として、入力を実現するためのデバイスを備える。例として、キーボード、マウス、タッチパネル、ペンタブレット、マイク等である。通信部１２０を介して、他の端末等からの入力を実現してもよい。
【００３８】
クラウドサービス管理コンピュータ１００は、出力部１５０として、出力を実現するためのデバイスを備える。例としては、ディスプレイ、プロジェクタ、スピーカー等である。通信部１２０を介して、ユーザ端末３００等の他の機器への出力を実現してもよい。
【００３９】
クラウドサービス２００は、ユーザの利用する一以上のクラウドサービスである。Ａｚｕｒｅ、ＡＷＳ、Ｓａｌｅｓｆｏｒｃｅ等、クラウドサービス提供業者の種類は問わない。図１、図２では、便宜上クラウドＸとクラウドＹとして２つ図示しているが、単数であっても、３つ以上のクラウドサービスであっても問題ない。
【００４０】
ユーザ端末３００は、クラウドサービス管理コンピュータ１００を利用するユーザが使用する端末である。ここでは、ディスプレイと一体型のコンピュータを図示しているが、デスクトップ型のコンピュータ、ノートパソコン、スマートフォン、タブレット端末、ウェアラブル端末等であってよい。数は一つに限らず複数であってよい。クラウドサービス管理コンピュータ１００からの出力をユーザが確認するための機能を備える端末であるものとする。また、ユーザは、ユーザ端末３００の入力部（非図示）を介して、データを絞り込むための検索条件の指定や、検索結果のダウンロードが可能であるものとする。また、出力部（非図示）を介して、検索結果の出力を確認可能であるものとする。
【００４１】
通信網４００は、クラウドサービス管理コンピュータ１００とクラウドサービス２００とユーザ端末３００間の通信を可能とする通信網である。
【００４２】
［クラウドサービス管理処理］
図３は、クラウドサービス管理処理のフローチャート図である。上述した各モジュールが実行する処理について、本フローチャートで説明する。
【００４３】
図３のクラウドサービス管理システムにおいて、まず、クラウドサービス管理コンピュータ１００の受信モジュール１２１は、クラウドサービス２００から、一定時間毎に請求データを受信する（ステップＳ３０１）。ここでは、利用しているすべてのクラウドサービス２００から、それぞれ請求データを受信するものとする。本発明における請求データとは、当該クラウドサービス独自のフォーマットによるもので、それぞれ、使用量、請求額、請求期間、部門、等を特定するための情報を含むものとする。請求データを受信する一定時間毎とは、２４時間毎、毎日＊＊時、等の設定と変更が可能であるものとする。ユーザからのデータ参照要求にかかわらず、クラウドサービス管理コンピュータ１００に対する負荷の低いタイミングや、利用料金の安いタイミングで、ステップＳ３０１のみを実施してもよい。受信した請求データは、記憶部１３０に記憶してもよいし、外部のコンピュータやデータベースやクラウドサービス等に記憶してもよい。
【００４４】
図１１は、クラウドサービス管理処理の請求データと統合した標準データの出力の一例である。図１１左上の図１１０１に示したのは、クラウドＸから受信した「サービス：＊＊＊＊、使用期間：２０１９／１／１−、使用済み：５６時間、合計使用料：６６，０００円、用途：ＳＥＯシステム、部門：マーケティング」という請求データである。図１１右上の図１１０２に示したのは、クラウドＹから受信した「インスタンス：＃＃＃＃、利用期間：２０１９−０１−０１〜、使用量：６０分、消費金額：３４，０００円、用途：ＳＥＯシステム、部門：マーケティング」という請求データである。これらは、ユーザから見ると一つの例えば「ＳＥＯシステム」というクラウドサービスを利用したことにより、発生する請求であるものとする。この「ＳＥＯシステム」のサービスを提供する企業が、システムを様々なクラウドサービスを利用して構築するため、結果として一つの「ＳＥＯシステム」で、異なる企業が提供する複数のクラウドサービスを利用していることとなる。請求は、クラウドサービス毎に発生するため、それぞれがどのシステムの利用による請求か、また、予算と比較して残高がどうなっているのか、ということがユーザには非常に分かりにくい。そのため、複数の請求データを、「ＳＥＯシステム」という一つのくくりで、当てられた当初の予算と比較して残高の管理を行うために、標準データへの変換が必要となる。図１１では、説明の都合上、各クラウドサービスから１つずつのみ請求データを受信した例として記載しているが、実際には、複数のユーザの各クラウドサービスの利用毎に請求データが発生するため、データ量は膨大であり、ユーザが手動で処理することは困難である。
【００４５】
図３に戻り、クラウドサービス管理コンピュータ１００の変換モジュール１１１は、ユーザ端末３００から、データ参照要求かあるかの確認を行う（ステップＳ３０２）。データ参照要求がある場合には、次のステップＳ３０３に進み、データ参照要求がない場合には、ステップＳ３０１に戻る。
【００４６】
データ参照要求がある場合、クラウドサービス管理コンピュータ１００の変換モジュール１１１は、受信した請求データを、互いに処理可能な標準データへと変換する（ステップＳ３０３）。変換モジュール１１１は、請求データを標準データへ変換するための処理として、名称寄せ、書式統一、単位変換、数値計算、メタデータ作成、任意項目追加、の各処理を行う。標準データへの変換処理の詳細については、後述する。ここで、「互いに処理可能な標準データ」という意味は、複数のクラウドサービスを利用している場合にも、統一した標準データへと変換するため、お互いのデータを統合して処理することが可能となる、という意味である。単数のクラウドサービスを利用している場合に複数の標準データがあっても、もちろん統合して処理することが可能である。図１１の例を変換する場合、クラウドＸの請求データは、「請求期間：２０１９年０１月０１日−、使用量：５６時間、請求額：６６，０００円、部門：マーケティング、予算：１，０００，０００円、メタデータ：（サービス：＊＊＊＊）、（用途：ＳＥＯシステム）」という標準データに変換する。また、クラウドＹの請求データは、「請求期間：２０１９年０１月０１日−、使用量：１時間、請求額：３４，０００円、部門：マーケティング、予算：１，０００，０００円、メタデータ：（インスタンス：＃＃＃＃）、（用途：ＳＥＯシステム）」という標準データに変換する。ここで、それぞれの標準データに、「予算：１，０００，０００円」という予算に関する予算項目を、任意項目として追加する。変換モジュール１１１が標準データに予算項目を任意項目として追加するための、任意項目追加処理の詳細については、後述する。
【００４７】
次に、クラウドサービス管理コンピュータ１００の統合モジュール１１２は、ステップＳ３０３で変換した標準データに基づき、クラウドサービスを統合したデータを算出する（ステップＳ３０４）。クラウドサービスを統合したデータとは、具体的には、サービスの消費（利用実績）を統一したデータ、及び任意に追加した項目、及び計算処理されて追加される任意の項目で構成されるデータである。図１１の場合は、クラウドＸの「請求期間：２０１９年０１月０１日−、使用量：５６時間、請求額：６６，０００円、部門：マーケティング、メタデータ：（サービス：＊＊＊＊）、（用途：ＳＥＯシステム）」という標準データと、クラウドＹの「請求期間：２０１９年０１月０１日−、使用量：１時間、請求額：３４，０００円、部門：マーケティング、メタデータ：（インスタンス：＃＃＃＃）、（用途：ＳＥＯシステム）」という標準データに基づき、「クラウドＸ＆クラウドＹ、請求期間：２０１９年０１月０１日―、使用量：５７時間、請求額：１００，０００円、部門：マーケティング、予算：１，０００，０００円、メタデータ：（サービス：＊＊＊＊）、（インスタンス：＃＃＃＃）、（用途：ＳＥＯシステム）」というデータを作成できる。
【００４８】
最後に、クラウドサービス管理コンピュータ１００の統合モジュール１１２は、ステップＳ３０４で算出した全体の請求額を含めたものを、標準データを統合したデータとして、ユーザ端末３００に出力させる（ステップＳ３０５）。図１１下部の図１１０３に、クラウドＸ＆クラウドＹの統合Ｖｉｅｗとして、「サービス名：ＳＥＯシステム、請求期間：２０１９年０１月０１日−、使用量：５７時間、請求額：１００、０００円、部門：マーケティング、メタデータ：（用途：ＳＥＯシステム）、追加項目：（予算：１,０００,０００円）」という内容を表示した例を図示している。ユーザは、この統合Ｖｉｅｗを確認することで、「マーケティング部門内で、ＳＥＯシステムを使用するために割り当てられた予算は１,０００,０００円であり、現在の請求額が１００,０００円である」ことがわかる。また、ユーザが図１１０３の「クラウドＸ」タブや「クラウドＹ」タブを選択することで、それぞれのクラウドサービスでの使用量や請求額を確認可能としてもよい。この統合Ｖｉｅｗで、すべてのメタデータを表示する必要はない。また、ここではメタデータである（用途：ＳＥＯシステム）をもとに、「サービス名」の項目に「ＳＥＯシステム」という値を表示した例を示しているが、本発明は、表示の方法によって限定されるものではない。
【００４９】
ここでは、クラウドＸとクラウドＹという複数のクラウドサービスの請求データを標準データとして統合したデータとして出力させる例を示したが、本発明の効果は、複数のクラウドサービスを利用する場合に限定されるものではない。例えば、単体のクラウドＸのみの利用である場合にも、複数のユーザの各クラウドサービスの利用毎に請求データが発生するため、データ量は膨大であり、ユーザが手動で請求データを処理することは困難である。そのような場合に、単体のクラウドサービスの見辛く膨大な量の請求データを、標準データへと変換して、統合して出力することで、ユーザが予算と支出（請求額）の管理が可能となるという効果が得られる。
【００５０】
また、図３では、データ参照要求があるかどうかの確認（ステップＳ３０２）を、標準データへの変換前に行う例を示したが、要求のあった端末への出力（ステップＳ３０５）の直前に行ってもよい。その場合は、標準データへの変換（ステップＳ３０３）と標準データの統合（ステップＳ３０４）は、参照要求のあったデータに対してのみ行うのではなく、受信した全請求データに対して、事前に行う。データ参照のための検索を行う際に、標準データへの変換と標準データの統合が完了しているため、レスポンスタイムを高速化できるという効果が得られる。
【００５１】
以上のように、本発明によれば、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、一以上のクラウドサービスを統合したデータを出力させることで、ユーザが自部門の予算と比較して、現在の請求額がいくらであるのか、といった判断や管理を総合的に行うことが可能なクラウドサービス管理コンピュータ、クラウドサービス管理方法、及びプログラムを提供することが可能となる。
【００５２】
［残高出力処理］
図４は、残高出力処理を行う場合のシステムの概要と機能ブロック図である。図２の構成に加えて、制御部１１０に算出モジュール１１３を備える。制御部１１０は、各モジュールの実現のために、必要に応じて通信部１２０、記憶部１３０、入力部１４０、出力部１５０と協働する。また、出力部１５０に、出力モジュール１５１を備える。出力部１５０は、必要に応じて制御部１１０と協働する。
【００５３】
図５は、残高出力処理のフローチャート図である。上述した各モジュールが実行する処理について、本フローチャートで説明する。図５のステップＳ５０１からステップＳ５０４は、図３のステップＳ３０１からステップＳ３０４に相当するため、ここでは、ステップＳ５０５以降について説明する。なお、説明には、図１３を使用する。図１３は、クラウドサービス管理処理の請求データと統合した標準データの出力の一例である。図１３左上の図１３０１に示したのは、図１１左上の図１１０１と同じクラウドＸの請求データ、図１３右上の図１３０２に示したのは、図１１右上の図１１０２と同じクラウドＹの請求データである。
【００５４】
クラウドサービス管理コンピュータ１００の算出モジュール１１３は、ステップＳ５０４で統合したデータに基づき、請求内容を算出する（ステップＳ５０５）。具体的には、一以上のクラウドサービスからなるシステムを使用する場合の予算と、全体の請求額とから、予算から請求額を差し引いた残高を求める。図１３の例を用いた図５のフローでは、統合したデータを基にして、「予算：１，０００，０００円」に対して、「請求額：１００，０００円」であるため、「残高：９００，０００円」であることが算出できる。
【００５５】
最後に、クラウドサービス管理コンピュータ１００の出力モジュール１５１は、ステップＳ５０５で算出した予算に対する残高を含めたものを、標準データを統合したデータとして、ユーザ端末３００に出力させる（ステップＳ５０６）。図１３下部の図１３０３に、クラウドＸ＆クラウドＹの統合Ｖｉｅｗとして、「サービス名：ＳＥＯシステム、請求期間：２０１９年０１月０１日−、使用量：５７時間、請求額：１００、０００円、部門：マーケティング、メタデータ：（用途：ＳＥＯシステム）、追加項目：（予算：１,０００,０００円）、（残高：９００,０００円）」という内容を表示した例を図示している。ユーザは、この統合Ｖｉｅｗを確認することで、「マーケティング部門内で、ＳＥＯシステムを使用するために割り当てられた予算は１,０００,０００円であり、現在の残高が９００,０００円である」ことがわかる。また、ユーザが図１３０３の「クラウドＸ」タブや「クラウドＹ」タブを選択することで、それぞれのクラウドサービスでの使用量や請求額を確認可能としてもよい。
【００５６】
図５では、データ参照要求があるかどうかの確認（ステップＳ５０２）を、標準データへの変換前に行う例を示したが、請求内容の算出（ステップＳ５０５）の直前に行ってもよい。その場合は、標準データへの変換（ステップＳ５０３）と標準データの統合（ステップＳ５０４）は、参照要求のあったデータに対してのみ行うのではなく、受信した全請求データに対して、事前に行う。請求内容の算出のための検索を行う際に、標準データへの変換と標準データの統合が完了しているため、レスポンスタイムを高速化できるという効果が得られる。
【００５７】
以上のように、本発明によれば、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、一以上のクラウドサービスを統合したデータを出力させることで、ユーザが自部門の予算と比較して、現在の残高がいくらあるのか、といった判断や管理を総合的に行うことが可能なクラウドサービス管理コンピュータ、クラウドサービス管理方法、及びプログラムを提供することが可能となる。
【００５８】
［集計データ出力処理］
図４は、又、集計データ出力処理を行う場合のシステムの概要と機能ブロック図である。図２の構成に加えて、制御部１１０に算出モジュール１１３を備える。制御部１１０は、各モジュールの実現のために、必要に応じて通信部１２０、記憶部１３０、入力部１４０、出力部１５０と協働する。また、出力部１５０に、出力モジュール１５１を備える。出力部１５０は、必要に応じて制御部１１０と協働する。
【００５９】
図６は、集計データ出力処理のフローチャート図である。上述した各モジュールが実行する処理について、本フローチャートで説明する。ここでは、図１２を用いて、ユーザがマーケティング部門のＳＥＯシステムの使用について、確認したい場合の例について述べる。ＳＥＯシステムは、クラウドＸが単体で提供しているサービスであるものとする。
【００６０】
図６のフローチャートにおいて、まず、クラウドサービス管理コンピュータ１００の受信モジュール１２１は、クラウドサービス２００から、一定時間毎に請求データを受信する（ステップＳ６０１）。ここでは、利用しているすべてのクラウドサービス２００から、それぞれ請求データを受信するものとする。本発明における請求データとは、当該クラウドサービス独自のフォーマットによるもので、それぞれ、使用量、請求額、請求期間、部門、等を特定するための情報を含むものとする。請求データを受信する一定時間毎とは、２４時間毎、毎日＊＊時、等の設定と変更が可能であるものとする。ユーザからのデータ参照要求にかかわらず、クラウドサービス管理コンピュータ１００に対する負荷の低いタイミングや、利用料金の安いタイミングで、ステップＳ６０１のみを実施してもよい。受信した請求データは、記憶部１３０に記憶してもよいし、外部のコンピュータやデータベースやクラウドサービス等に記憶してもよい。
【００６１】
図１２は、クラウドサービス管理処理の請求データと統合した標準データの出力の一例である。図１２上の図１２０１に示したのは、クラウドＸから受信した「サービス、使用期間、使用済み、合計使用料、用途、部門」という項目を含む、複数の請求データである。これらは、ユーザから見ると一つの例えば「ＳＥＯシステム」というクラウドサービスを利用したことにより、発生する請求であるものとする。図１２では、図の記載の都合上、クラウドＸから４つの請求データを受信した例として記載しているが、実際には、複数のユーザの利用毎に請求データが発生するため、データ量は膨大であり、ユーザが手動で処理することは困難である。
【００６２】
図６に戻り、クラウドサービス管理コンピュータ１００の変換モジュール１１１は、ユーザ端末３００から、集計データ参照要求かあるかの確認を行う（ステップＳ６０２）。データ参照要求がある場合には、次のステップＳ６０３に進み、データ参照要求がない場合には、ステップＳ６０１に戻る。
【００６３】
データ参照要求がある場合、クラウドサービス管理コンピュータ１００の変換モジュール１１１は、受信した請求データを、標準データへと変換する（ステップＳ６０３）。変換モジュール１１１は、請求データを標準データへ変換するための処理として、名称寄せ、書式統一、単位変換、数値計算、メタデータ作成、任意項目追加、の各処理を行う。標準データへの変換処理の詳細については、後述する。図１２０１の一番右の例を変換する場合、請求データは、「請求期間：２０１９年０１月０１日−、使用量：１時間、請求額：１，７００円、部門：マーケティング、予算：５００，０００円、メタデータ：（用途：ＳＥＯシステム）」という標準データに変換する。ここで、それぞれの標準データに、「予算：５００，０００円」というマーケティング部門の予算に関する予算項目を、任意項目として追加する。
【００６４】
次に、クラウドサービス管理コンピュータ１００の統合モジュール１１２は、ステップＳ６０３で変換した標準データを統合する。（ステップＳ６０４）。受信した請求データを変換した標準データをすべて統合して、請求期間、使用量、請求額、部門、予算、メタデータ等の項目での、検索や集計を可能なデータ形式とする。
【００６５】
次に、クラウドサービス管理コンピュータ１００の算出モジュール１１３は、ステップＳ６０４で統合したデータに基づき、集計データを算出する（ステップＳ５０５）。ここでは、ユーザがマーケティング部門のＳＥＯシステムの使用についての集計データを求めているため、部門がマーケティングであるデータを検索してまとめたデータを算出する。図１２の場合は、４つのデータをまとめて、「請求期間：２０１９年０１月０１日―、使用量：２５時間、請求額：４２，５００円、部門：マーケティング、予算：５００，０００円、メタデータ：（用途：ＳＥＯシステム）」が、マーケティング部門の集計データであるとする。
【００６６】
最後に、クラウドサービス管理コンピュータ１００の出力モジュール１５１は、ステップＳ６０５で算出した集計データを、ユーザ端末３００に出力させる（ステップＳ６０６）。図１２下部の図１２０２には、ＳＥＯシステムを利用したマーケティング部門の統合Ｖｉｅｗとして、「請求期間：２０１９年０１月０１日―、使用量：２５時間、請求額：４２，５００円、部門：マーケティング、予算：５００，０００円、メタデータ：（用途：ＳＥＯシステム）」という内容を表示した例を図示している。ユーザは、この統合Ｖｉｅｗを確認することで、「マーケティング部門内で、ＳＥＯシステムを使用するために割り当てられた予算は５００,０００円であり、現在は４２，５００円使用している」ことがわかる。詳細は後述するが、統合Ｖｉｅｗには、あわせて残高を表示してもよい。
【００６７】
図６では、データ参照要求があるかどうかの確認（ステップＳ６０２）を、標準データへの変換前に行う例を示したが、集計データの算出（ステップＳ６０５）の直前に行ってもよい。その場合は、標準データへの変換（ステップＳ６０３）と標準データの統合（ステップＳ６０４）は、参照要求のあったデータに対してのみ行うのではなく、受信した全請求データに対して、事前に行う。集計データの算出のための検索を行う際に、標準データへの変換と標準データの統合が完了しているため、レスポンスタイムを高速化できるという効果が得られる。
【００６８】
以上のように、本発明によれば、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、ユーザが指定した任意の項目を集計データとして出力することで、ユーザが自部門の予算について判断や管理を総合的に行うことが可能なクラウドサービス管理コンピュータ、クラウドサービス管理方法、及びプログラムを提供することが可能となる。
【００６９】
［標準データへの変換処理］
図７は、標準データへの変換処理のフローチャート図である。図３のフローチャートのステップＳ３０３、図５のフローチャートのステップＳ５０３、図６のフローチャートのステップＳ６０３に該当する。ここでは、図３のフローのステップＳ３０３に当てはまる場合を例として、図１１のクラウドサービス管理処理の請求データと統合した標準データの出力の一例を用いて説明する。
【００７０】
まず、クラウドサービス管理コンピュータ１００の変換モジュール１１１は、ステップＳ３０１で受信した請求データから、標準データに未変換のものを、一つ選択する（ステップＳ７０１）。
【００７１】
次に、変換モジュール１１１は、選択した請求データの名称寄せを行う（ステップＳ７０２）。具体的には、請求データの項目名を、標準データの項目名へと寄せる作業を行う。例えば、標準データとして、システムを使用するのに割り当てられた期間がいつからかを表すために「請求期間」という項目名を使用したいのに対し、図１１の図１１０１に示すようにクラウドＸの請求データでは「使用期間」という項目名を、図１１０２に示すようにクラウドＹの請求データでは「利用期間」という項目名を使用している。このように、クラウドサービスによって、使用している名称が違う場合に、請求データ内で該当する項目名称を検索して、標準データとして使用する項目名への置き換えを行う。同じように、標準データとして、システムをすでに使用した時間を表すために「使用量」という項目名を使用したいのに対し、クラウドＸでは「使用済み」という項目名を、クラウドＹでは「消費量」という項目名を使用しているので、これらも置き換えを行う。さらに、標準データとして、システムをすでに使用したことに対する料金を表すために「請求額」という項目名を使用したいのに対し、クラウドＸでは「合計使用料」という項目名を、クラウドＹでは「消費金額」という項目名を使用しているので、これらも置き換えを行う。置き換えを行う文言は、上記のものに限定されるわけではなく、クラウドサービスに応じて、検索を行うための追加が可能であるものとする。また、標準データの名称についても、ユーザにあわせて項目名のカスタマイズを可能としてもよい。
【００７２】
次に、変換モジュール１１１は、選択した請求データの書式統一を行う（ステップＳ７０３）。具体的には、請求データの項目内の書式を、標準データの書式へと統一する作業を行う。例えば、標準データの書式として、「請求期間」では「２０１９年０１月０１日―」を使用したいのに対し、クラウドＸでは「２０１９／０１／０１−」という書式を、クラウドＹでは「２０１９−０１−０１〜」と書式を使用している。このように、クラウドサービスによって、項目内の書式が違う場合に、標準データとして使用する書式への統一を行う。書式の統一は、「請求期間」の項目のみに限定されるわけではなく、書式の統一が必要なすべての項目に対して行うものとする。また、標準データの書式については、ユーザにあわせてカスタマイズを可能としてもよい。
【００７３】
次に、変換モジュール１１１は、選択した請求データの単位変換を行う（ステップＳ７０４）。具体的には、請求データの項目内の単位を、標準データの単位へと統一する作業を行う。例えば、標準データの単位として、「使用量」では「時間」を使用したいのに対し、クラウドＸでは「時間」という単位を使用しているが、クラウドＹでは「分」という単位を使用している。このように、クラウドサービスによって、項目内の単位が違う場合に、標準データとして使用する単位への統一を行う。単位の統一は、「使用量」の項目のみに限定されるわけではなく、単位の統一が必要なすべての項目に対して行うものとする。また、標準データの単位については、ユーザにあわせてカスタマイズを可能としてもよい。
【００７４】
次に、変換モジュール１１１は、選択した請求データの数値計算を行う（ステップＳ７０５）。例えば、クラウドＸの請求データが複数ある場合には、それらの消費量や請求額を合算するといった処理をおこなう。合算処理に限らず、請求データ内で例えば通貨の変換が必要であるなどの、数値計算が必要となる場合には、ここで処理を行うものとする。
【００７５】
次に、変換モジュール１１１は、メタデータの作成を行う（ステップＳ７０６）。具体的には、請求データの項目として存在するのに、標準データの項目として存在しないものを、メタデータとする。例えば、図１１０１の「用途：ＳＥＯシステム」というデータ、図１１０２の「用途：ＳＥＯシステム」というデータは、標準データの項目として存在しないので、項目名と内容をあわせて標準データに、メタデータという項目名で保存する。メタデータの作成は、標準データの項目として存在しないものすべてについて行ってもよいが、以降のフローで必ずしもすべてのメタデータを出力する必要はない、図１１０３の例でも、「用途：ＳＥＯシステム」というデータのみをメタデータとして表示している。
【００７６】
次に、変換モジュール１１１は、任意項目の追加を行う（ステップＳ７０７）。具体的には、クラウドサービスに予め設けていた予算に関する予算項目を、任意項目として標準データに追加する。図１１の例では、「予算：１，０００，０００円」という項目を追加している。また、予算管理の必要に応じて、「予算」以外の項目群も、任意項目として追加可能である。「予算」を含む任意項目は、ユーザから取得する。具体的には、項目名と値の組み合わせを、プログラム、ＡＰＩ、メール、ファイル共有等の任意の手段を用いてユーザから取得する。その際のデータ形式は、ＥＸＣＥＬ／ＣＳＶ／ＸＭＬ／ＪＳＯＮ／ＴＥＸＴ等の任意の形式であってよい。任意項目の取得方法やデータ形式は、既存の技術を使用してよく、本発明を限定するものではない。任意項目追加処理のフローの詳細については後述する。
【００７７】
最後に、変換モジュール１１１は、全請求データについての変換処理が完了したかどうかを確認し、完了していなければステップＳ７０１に戻って処理を継続し、完了していれば終了する（ステップＳ７０８）。
【００７８】
このように、標準データへの変換処理は、各請求データの項目名や書式、単位等を統一して、一以上のクラウドサービスのデータを一括して扱えるようにするとともに、必要な項目を任意項目として追加するものである。
【００７９】
［使用量予測処理］
図８は、使用量予測処理と残高予測処理を行う場合のシステムの概要と機能ブロック図である。使用量予測処理を行う場合、図２または図４の構成に加えて、制御部１１０に予測モデル生成モジュール１１４、使用量予測モジュール１１５を備える。制御部１１０は、各モジュールの実現のために、必要に応じて通信部１２０、記憶部１３０、入力部１４０、出力部１５０と協働する。図９は、使用量予測処理のフローチャート図である。使用量予測処理は、ユーザからの要望に応じて適時行ってもよいし、定期的に行ってもよい。
【００８０】
使用量予測処理を行う場合、まず、クラウドサービス管理コンピュータ１００の使用量予測モジュール１１５は、予測を行うために利用する過去の期間を、所定の期間として取得する（ステップＳ９０１）。ここでの所定の期間は、システム構成情報に指定されたデフォルトの期間としてもよいし、ユーザに指定させてもよい。ユーザに所定の期間を指定させるには、ユーザ端末３００を介して、構成情報として構成情報ファイルに値を指定させ、それをクラウドサービス管理コンピュータ１００に入力として取り込む方法等がある。
【００８１】
次に、使用量予測モジュール１１５は、ステップＳ９０１で取得した所定の期間の標準データを取得する（ステップＳ９０２）。ここでは、一以上のクラウドサービスの標準データをすべて取得するものとする。
【００８２】
次に、予測モデル生成モジュール１１４は、所定の期間の標準データを基に、予測モデルを生成する（ステップＳ９０３）。予測モデルとしては、統計的な最小二乗法や機械学習等が考えられる。
【００８３】
次に、使用量予測モジュール１１５は、ステップＳ９０３で生成した予測モデルを利用して、将来の使用量を予測する（ステップＳ９０４）。ここでの将来の使用量とは、例えば時間毎、日毎、週毎、月毎、年毎等の使用量（時間）のことである。
【００８４】
最後に、使用量予測モジュール１１５は、将来の使用量を出力する（ステップＳ９０５）。ユーザ端末３００への出力を行う場合には、ユーザからの指定に応じて、時間毎、日毎、週毎、月毎、年毎等に表示を切り替えて予測した使用量を表やグラフで確認できるようにしてよい。また、使用量は、部門毎やプロジェクト等、予算の割り当て先に応じて、切り替えて確認できるようにしてよい。
【００８５】
以上のように、本発明によれば、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、一以上のクラウドサービスを統合したデータを出力させることで、今後の使用量の予測を確認することが可能となり、自部門の予算と比較して、いつ頃割り当てられた予算を消費が上回りそうか、といった判断や管理を総合的に行うことが可能なクラウドサービス管理コンピュータ、クラウドサービス管理方法、及びプログラムを提供することが可能となる。
【００８６】
［残高予測処理］
図８は、使用量予測処理と残高予測処理を行う場合のシステムの概要と機能ブロック図である。残高予測処理を行う場合、図２または図４の構成に加えて、制御部１１０に使用料学習モジュール１１６、残高予測モジュール１１７を備える。制御部１１０は、各モジュールの実現のために、必要に応じて通信部１２０、記憶部１３０、入力部１４０、出力部１５０と協働する。図１０は、残高予測処理のフローチャート図である。残高予測処理は、ユーザからの要望に応じて適時行ってもよいし、定期的に行ってもよい。
【００８７】
残高予測処理を行う場合、まず、クラウドサービス管理コンピュータ１００の残高予測モジュール１１７は、予測を行うために利用する過去の期間を、所定の期間として取得する（ステップＳ１００１）。ここでの所定の期間は、システム構成情報に指定されたデフォルトの期間としてもよいし、ユーザに指定させてもよい。ユーザに所定の期間を指定させるには、ユーザ端末３００を介して、構成情報として構成情報ファイルに値を指定させ、それをクラウドサービス管理コンピュータ１００に入力として取り込む方法等がある。
【００８８】
次に、残高予測モジュール１１７は、ステップＳ１００１で取得した所定の期間の標準データを取得する（ステップＳ１００２）。ここでは、一以上のクラウドサービスの標準データをすべて取得するものとする。
【００８９】
次に、使用料学習モジュール１１６は、所定の期間の標準データを基に、使用料の学習を行う（ステップＳ１００３）。具体的には、どの時期に、各クラウドサービスの使用料（標準データにおける請求額）が、標準データの使用量に対して、いくらであったかを教師データとする機械学習が考えられる。
【００９０】
次に、残高予測モジュール１１７は、ステップＳ１００３での学習により、将来の残高を予測する（ステップＳ１００４）。将来の残高は、予算からこれまでの使用料（標準データにおける請求額）を差し引いて、将来の使用料がどのように推移するかを予測することで算出可能である。
【００９１】
最後に、残高予測モジュール１１７は、将来の残高を出力する（ステップＳ１００５）。ユーザ端末３００への出力を行う場合には、ユーザからの指定に応じて、残高がどのように推移するか、いつ頃割り当てられた予算を消費が上回りそうかを、表やグラフで確認できるようにしてよい。また、どのくらいの追加予算がいつ頃必要となるかを予測して、メール等での通知や予測レポートの出力を行ってもよい。
【００９２】
以上のように、本発明によれば、一以上のクラウドサービスが提供する請求データを管理するクラウドサービス管理コンピュータに、一以上のクラウドサービスを統合したデータを出力させることで、ユーザが自部門の予算と比較して、現在の残高がいくらあるのか、いつ頃割り当てられた予算を消費が上回りそうか、といった判断や管理を総合的に行うことが可能なクラウドサービス管理コンピュータ、クラウドサービス管理方法、及びプログラムを提供することが可能となる。
【００９３】
［任意項目追加処理］
図１４は、任意項目追加処理のフローチャート図である。図１５は、標準データに任意項目追加処理を行う場合のデータ概要である。図１５の表１５０１は、任意項目処理を説明するために最低限必要な項目のみ示しており、実際の標準データには、他の項目も含まれるものとする。図１４のフローは、図７のステップＳ７０７にも相当する。
【００９４】
任意項目追加処理を行う場合、図１４のフローにおいて、まず、ユーザがユーザ端末３００で検索し、予算を割り当てるためのデータを絞り込む（ステップＳ１４０１）。例えば、ここでは、ユーザはマーケティング部門のＳＥＯシステムの利用に対する予算を割り当てるために、「部門：マーケティング」かつ「用途：ＳＥＯシステム」として絞り込みを行うものとする。
【００９５】
次に、クラウドサービス管理コンピュータ１００の変換モジュール１１１は、ユーザが絞り込みに使用した検索文を、ユーザ端末３００から取得する（ステップＳ１４０２）。検索文は、項目名と値の組み合わせを、プログラム、ＡＰＩ、メール、ファイル共有等の任意の手段を用いてユーザから取得する。その際のデータ形式は、ＥＸＣＥＬ／ＣＳＶ／ＸＭＬ／ＪＳＯＮ／ＴＥＸＴ等の任意の形式であってよい。ここでは、項目名「部門」と値「マーケティング」という組み合わせと、項目名「用途」と値「ＳＥＯシステム」という組み合わせとを取得する。ステップＳ１４０１で、「部門：マーケティング」かつ「用途：ＳＥＯシステム」という絞り込み検索を行うため、「かつ（ＡＮＤ）」という検索条件もあわせて取得するものとする。
【００９６】
次に、変換モジュール１１１は、取得した検索文で検索し、標準データを絞り込む（ステップＳ１４０３）。ここでは、『「部門：マーケティング」かつ「用途：ＳＥＯシステム」』という条件で、標準データの絞り込みを行う。図１５の表１５０１のデータ１５０２は、絞り込みを行った標準データのサービス、用途、部門、を表すものである。
【００９７】
次に、変換モジュール１１１は、追加を行う任意項目を、ユーザ端末３００から取得する（ステップＳ１４０４）。ここでは、『「部門：マーケティング」かつ「用途：ＳＥＯシステム」』のデータに、任意項目として、「予算：５，０００，０００円」、「予算開始日：２０１９／０１／０１」、「予算終了日：２０１９／１３／３１」を追加するものとし、これらの任意項目を取得する。任意項目は、項目名と値の組み合わせを、プログラム、ＡＰＩ、メール、ファイル共有等の任意の手段を用いてユーザから取得するものとする。また、任意項目の取得は、ステップＳ１４０２であわせて行ってもよいものとする。
【００９８】
最後に、変換モジュール１１１は、絞り込んだ標準データに、ステップＳ１４０４で取得した任意項目を追加する（ステップＳ１４０５）。図１５の表１５０１のデータ１５０３は、標準データに追加を行った任意項目の予算、予算開始日、予算終了日、を表すものである。図１５には図示していないが、ステップＳ１４０３で絞り込んだ標準データには、必ずクラウドサービスの「使用日」の項目が含まれる。この「使用日」の値である日付が、「予算開始日」の項目と「予算終了日」の項目との間の日付である場合に、「予算」の項目を追加するものとする。
【００９９】
このように、標準データへの任意項目追加処理は、ユーザ端末３００から絞り込みに使用した検索文と、任意項目とを取得して、行うものである。
【０１００】
図１４では、ステップＳ１４０１で、ユーザが予算を割り当てるデータの絞り込みを行うフローを記載した。図７の標準データへの変換処理のフローの中の任意項目追加処理（ステップＳ７０７）としての処理の場合には、ステップＳ１４０１の明示的な絞り込みは行われないが、ステップＳ１４０２で、プログラム、ＡＰＩ、メール、ファイル共有等の任意の手段を用いて、非同期に検索文を取得しておくことで対応が可能である。
【０１０１】
［ＮｏＳＱＬによるデータ管理］
本発明の発明者は、ＮｏＳＱＬによるデータベースを構築してデータ管理を行うことによる利点を確認済である。ＮｏＳＱＬの利点は、リレーショナルデータベースのように、予めスキーマ（データ構造）を決めなくとも、後から柔軟にスキーマを変更できることである。後からスキーマを変更できることにより、クラウドサービス提供業社の仕組みとは関係なく、ユーザによる項目の追加が可能となり、利便性を向上させることが可能である。
【０１０２】
図１６は、ＮｏＳＱＬによる予算支出管理を行う場合の利点を示す一例である。サービス使用量テーブル１６０１は、クラウドサービスプロバイダーが管理する項目、予算支出テーブル１６０２は、ユーザが管理のために追加したい項目とし、これらをあわせてサービス予算支出ビュー１６０３を作成するものとする。また、項目１６０４の「予算管理者：山田太郎」という項目を、後から追加した例を示すものとする。ここで、もしＲＤＢ（Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａｂａｓｅ）を使用した場合には、サービス使用量テーブル１６０１と予算支出テーブル１５０２のそれぞれに、後から項目１６０４の「予算管理者：山田太郎」という項目を追加することは可能であるが、この項目で統合することはできない。これは、ＲＤＢを使用するアプリケーションの場合には、あらかじめテーブル間にリレーションを定義しなければならないためである。後からリレーションを再定義することは、アプリケーション自体を作り直すことになる。これに対して、ＮｏＳＱＬでは、サービス使用量テーブル１６０１と予算支出テーブル１６０２のそれぞれに、後から項目１６０４の「予算管理者：山田太郎」という項目を追加することで、この「予算管理者：山田太郎」の項目を利用して、サービス使用量テーブル１６０１と予算支出テーブル１６０２とを統合して、サービス予算支出ビュー１６０３を作成することが可能である。
【０１０３】
以上のように、本発明によれば、クラウドサービス提供業社の仕組みにとらわれることなく、ユーザによる予算支出管理のための項目の追加が可能となり、ユーザの利便性を向上させることが可能なクラウドサービス管理コンピュータ、クラウドサービス管理方法、及びプログラムを提供することが可能となる。
【０１０４】
以上、本発明の実施形態について説明したが、本発明は上述したこれらの実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載されたものに限定されるものではない。
【符号の説明】
【０１０５】
１００  クラウドサービス管理コンピュータ、２００  クラウドサービス、３００  ユーザ端末、４００  通信網
【図１】
2020201739.tif 000003
【図２】
2020201739.tif 000004
【図３】
2020201739.tif 000005
【図４】
2020201739.tif 000006
【図５】
2020201739.tif 000007
【図６】
2020201739.tif 000008
【図７】
2020201739.tif 000009
【図８】
2020201739.tif 000010
【図９】
2020201739.tif 000011
【図１０】
2020201739.tif 000012
【図１１】
2020201739.tif 000013
【図１２】
2020201739.tif 000014
【図１３】
2020201739.tif 000015
【図１４】
2020201739.tif 000016
【図１５】
2020201739.tif 000017
【図１６】
2020201739.tif 000018