"ホスト端末と、該ホスト端末からコマンドを受け取る制御サーバとを備えるコマンドスケジュール対応型クラウド統一操作システムであって、前記ホスト端末は、前記制御サーバへ共通フォーマットのコマンドを送信する手段を備え、前記制御サーバは、仮想サーバとプラットフォームとの対応関係を記憶した仮想サーバ情報記憶手段と、前記共通フォーマットのコマンドに対応する各プラットフォームごとの実コマンドのフォーマットを記憶したコマンド変換情報記憶手段と、前記ホスト端末からの共通フォーマットのコマンドを受信する手段と、受信した共通フォーマットのコマンドに含まれる仮想サーバ名をキーとして前記仮想サーバ情報記憶手段からプラットフォームを検索する手段と、検索されたプラットフォーム名をキーとして前記コマンド変換情報記憶手段からそのプラットフォームのコマンド処理部に投入すべき実コマンドのフォーマットを取得し、取得した実コマンドのフォーマットに基づいて、前記受信した共通フォーマットのコマンドを実コマンドに変換する手段と、得られた実コマンドを含むジョブをコマンドキューに格納する手段と、前記コマンドキューからジョブを取り出して、該ジョブの実コマンドを、対応するプラットフォームのコマンド処理部に投入する手段と、該プラットフォームのコマンド処理部が実行したコマンド結果を受け取る手段と、受け取ったコマンド結果を結果キュー処理部に格納する手段とを備えることを特徴とするコマンドスケジュール対応型クラウド統一操作システム。請求項1に記載のコマンドスケジュール対応型クラウド統一操作システムにおいて、前記コマンドキューからジョブを取り出して該ジョブの実コマンドをコマンド処理部に送信する際には、当該ジョブの送信先である物理サーバがジョブ実行中でないことを確認した後に送信することを特徴とするコマンドスケジュール対応型クラウド統一操作システム。請求項1または2に記載のコマンドスケジュール対応型クラウド統一操作システムにおいて、前記ジョブをコマンドキューに格納する際、当該ジョブが管理者権限のもとで入力されたコマンドのジョブである場合には、前記コマンドキューの先頭に格納し、そうでない場合には、前記コマンドキューの末尾に格納することを特徴とするコマンドスケジュール対応型クラウド統一操作システム。ホスト端末と、該ホスト端末からコマンドを受け取る制御サーバとを用いたコマンドスケジュール対応型クラウド統一操作方法であって、前記制御サーバに、仮想サーバとプラットフォームとの対応関係を記憶した仮想サーバ情報記憶手段と、共通フォーマットのコマンドに対応する各プラットフォームごとの実コマンドのフォーマットを記憶したコマンド変換情報記憶手段とを設けるとともに、前記ホスト端末が、前記制御サーバへ共通フォーマットのコマンドを送信するステップと、前記制御サーバが、前記ホスト端末からの共通フォーマットのコマンドを受信するステップと、前記制御サーバが、受信した共通フォーマットのコマンドに含まれる仮想サーバ名をキーとして前記仮想サーバ情報記憶手段からプラットフォームを検索するステップと、前記制御サーバが、検索されたプラットフォーム名をキーとして前記コマンド変換情報記憶手段からそのプラットフォームのコマンド処理部に投入すべき実コマンドのフォーマットを取得し、取得した実コマンドのフォーマットに基づいて、前記受信した共通フォーマットのコマンドを実コマンドに変換するステップと、前記制御サーバが、得られた実コマンドを含むジョブをコマンドキューに格納するステップと、前記制御サーバが、前記コマンドキューからジョブを取り出して、該ジョブの実コマンドを、対応するプラットフォームのコマンド処理部に投入するステップと、前記制御サーバが、該プラットフォームのコマンド処理部が実行したコマンド結果を受け取るステップと、前記制御サーバが、受け取ったコマンド結果を結果キュー処理部に格納するステップとを備えることを特徴とするコマンドスケジュール対応型クラウド統一操作方法。請求項4に記載のコマンドスケジュール対応型クラウド統一操作方法において、前記コマンドキューからジョブを取り出して該ジョブの実コマンドをコマンド処理部に送信する際には、当該ジョブの送信先である物理サーバがジョブ実行中でないことを確認した後に送信することを特徴とするコマンドスケジュール対応型クラウド統一操作方法。請求項4または5に記載のコマンドスケジュール対応型クラウド統一操作方法において、前記ジョブをコマンドキューに格納する際、当該ジョブが管理者権限のもとで入力されたコマンドのジョブである場合には、前記コマンドキューの先頭に格納し、そうでない場合には、前記コマンドキューの末尾に格納することを特徴とするコマンドスケジュール対応型クラウド統一操作方法。上述したように1つのクラウドシステム内に複数のプラットフォームが混在するケースでは、異なるプラットフォームの仮想サーバに投入する操作コマンドを、すべて共通の形式で操作できるようにして、クラウドシステムに混在するプラットフォームにおける仮想サーバの操作コマンドを一元的に管理することが求められている。また、仮想サーバのプラットフォームが複数混在しているようなクラウドシステムでは、仮想サーバの総数が数千から数万に及ぶことも珍しくなく、それらの仮想サーバに対する起動や停止といったコマンドが同時に大量に投入されることがあるが、仮想サーバを制御するコマンド処理部は投入されたコマンドを処理しきれずにハングアップしたり異常に遅延するなどの問題が発生することがある。コマンド処理部がこのような状態になった場合、該当のコマンド処理部が管理する仮想サーバの操作が行えなくなり、顧客満足度が低下する可能性がある。そのような同時に大量のコマンドが投入された場合の不具合を解消するためには、投入されたコマンドをキューに格納し、1コマンドずつ実行することが考えられる。しかし、単にコマンドをキューに格納し、順次コマンドを実行するようにしただけでは、大量にコマンドがキューに格納されているときには新たなコマンドを投入しても、実際にコマンドが実行されるまでに時間がかかることがある。クラウドシステムでは、ある時点におけるシステム負荷に応じて自由にスケールアウトするといった運用が一般的であるが、意図したタイミングにコマンドを実行できないとクラウドシステムのメリットを生かした運用ができなくなるという問題がある。このため、効率的にコマンドを実行できるようなスケジューリングを行うとともに、緊急時には管理者が最優先でコマンドを実行できるような仕組みが求められている。本発明の目的は、マルチプラットフォームからなるクラウドシステムにおいて、単純なコマンドのキューイングではなく、ユーザから同時に大量のコマンドが投入された場合でも、物理サーバへのコマンドの投入が効率的になるように制御して、物理サーバへの動作の影響を最小限に抑えることができるコマンドスケジュール対応型クラウド操作システムおよび方法を提供することにある。上記目的を達成するため、請求項1に係る発明は、ホスト端末と、該ホスト端末からコマンドを受け取る制御サーバとを備えるコマンドスケジュール対応型クラウド統一操作システムであって、前記ホスト端末は、前記制御サーバへ共通フォーマットのコマンドを送信する手段を備え、前記制御サーバは、仮想サーバとプラットフォームとの対応関係を記憶した仮想サーバ情報記憶手段と、前記共通フォーマットのコマンドに対応する各プラットフォームごとの実コマンドのフォーマットを記憶したコマンド変換情報記憶手段と、前記ホスト端末からの共通フォーマットのコマンドを受信する手段と、受信した共通フォーマットのコマンドに含まれる仮想サーバ名をキーとして前記仮想サーバ情報記憶手段からプラットフォームを検索する手段と、検索されたプラットフォーム名をキーとして前記コマンド変換情報記憶手段からそのプラットフォームのコマンド処理部に投入すべき実コマンドのフォーマットを取得し、取得した実コマンドのフォーマットに基づいて、前記受信した共通フォーマットのコマンドを実コマンドに変換する手段と、得られた実コマンドを含むジョブをコマンドキューに格納する手段と、前記コマンドキューからジョブを取り出して、該ジョブの実コマンドを、対応するプラットフォームのコマンド処理部に投入する手段と、該プラットフォームのコマンド処理部が実行したコマンド結果を受け取る手段と、受け取ったコマンド結果を結果キュー処理部に格納する手段とを備えることを特徴とする。請求項2に係る発明は、請求項1に記載のコマンドスケジュール対応型クラウド統一操作システムにおいて、前記コマンドキューからジョブを取り出して該ジョブの実コマンドをコマンド処理部に送信する際には、当該ジョブの送信先である物理サーバがジョブ実行中でないことを確認した後に送信することを特徴とする。請求項3に係る発明は、請求項1または2に記載のコマンドスケジュール対応型クラウド統一操作システムにおいて、前記ジョブをコマンドキューに格納する際、当該ジョブが管理者権限のもとで入力されたコマンドのジョブである場合には、前記コマンドキューの先頭に格納し、そうでない場合には、前記コマンドキューの末尾に格納することを特徴とする。請求項4に係る発明は、ホスト端末と、該ホスト端末からコマンドを受け取る制御サーバとを用いたコマンドスケジュール対応型クラウド統一操作方法であって、前記制御サーバに、仮想サーバとプラットフォームとの対応関係を記憶した仮想サーバ情報記憶手段と、共通フォーマットのコマンドに対応する各プラットフォームごとの実コマンドのフォーマットを記憶したコマンド変換情報記憶手段とを設けるとともに、前記ホスト端末が、前記制御サーバへ共通フォーマットのコマンドを送信するステップと、前記制御サーバが、前記ホスト端末からの共通フォーマットのコマンドを受信するステップと、前記制御サーバが、受信した共通フォーマットのコマンドに含まれる仮想サーバ名をキーとして前記仮想サーバ情報記憶手段からプラットフォームを検索するステップと、前記制御サーバが、検索されたプラットフォーム名をキーとして前記コマンド変換情報記憶手段からそのプラットフォームのコマンド処理部に投入すべき実コマンドのフォーマットを取得し、取得した実コマンドのフォーマットに基づいて、前記受信した共通フォーマットのコマンドを実コマンドに変換するステップと、前記制御サーバが、得られた実コマンドを含むジョブをコマンドキューに格納するステップと、前記制御サーバが、前記コマンドキューからジョブを取り出して、該ジョブの実コマンドを、対応するプラットフォームのコマンド処理部に投入するステップと、前記制御サーバが、該プラットフォームのコマンド処理部が実行したコマンド結果を受け取るステップと、前記制御サーバが、受け取ったコマンド結果を結果キュー処理部に格納するステップとを備えることを特徴とする。請求項5に係る発明は、請求項4に記載のコマンドスケジュール対応型クラウド統一操作方法において、前記コマンドキューからジョブを取り出して該ジョブの実コマンドをコマンド処理部に送信する際には、当該ジョブの送信先である物理サーバがジョブ実行中でないことを確認した後に送信することを特徴とする。請求項6に係る発明は、請求項4または5に記載のコマンドスケジュール対応型クラウド統一操作方法において、前記ジョブをコマンドキューに格納する際、当該ジョブが管理者権限のもとで入力されたコマンドのジョブである場合には、前記コマンドキューの先頭に格納し、そうでない場合には、前記コマンドキューの末尾に格納することを特徴とする。本発明によれば、マルチプラットフォームから構成されるクラウドシステムにおいて、コマンドを大量に投入しても、効率的にコマンドを実行できるように自動でコマンドの処理順序をスケジューリングすることが出来るインターフェースを提供することができる。以下、図面を用いて、本発明の実施の形態について説明する。図1は、本発明の一実施形態を示すシステム構成図である。この実施形態のクラウド統一操作システムは、コマンド送信部102を備えたホスト端末101と、このホスト端末101から受信したコマンドに応じて種々のプラットフォームのコマンド処理部にコマンドを投入する制御サーバ103とを備える。制御サーバ103は、ホスト端末101のコマンド送信部102から送信されたコマンドを受信するコマンド受信部104、コマンドの引数として渡された仮想サーバのプラットフォームを検索するプラットフォーム検索部105、プラットフォームごとに実行するコマンドを変換するコマンド変換部106、コマンドに優先順位を与えるスケジューリング処理部107、コマンドをコマンドキューに格納するコマンドキュー処理部108、コマンドを所定のプラットフォームのコマンド処理部に投入する実コマンド送信部109、実行したコマンドの結果を受信するコマンド実行結果受信部110、実行したコマンドの結果を格納する結果キュー処理部111、仮想サーバのプラットフォーム情報を格納する仮想サーバ情報DB112、プラットフォームごとの仮想サーバを操作するすべてのコマンドを格納するコマンド変換DB113、および、物理サーバがジョブを実行しているかどうかをのステータスを格納する物理サーバステータスDB114を備える。また、制御サーバ103から投入されたコマンドを実際に操作するプラットフォーム毎のコマンド処理部115a,115bと、仮想サーバの実イメージを保持する各プラットフォームの物理サーバ116a,116b,116cを備える。ホスト端末101と制御サーバ103、制御サーバ103と各プラットフォームのコマンド処理部115a,115b、各プラットフォームのコマンド処理部115a,115bとそのプラットフォームの物理サーバ116a,116b,116cは、それぞれネットワーク接続されている。図2は、仮想サーバ情報DB112に格納される仮想サーバ関連情報の一例を示す図である。図に示すように、仮想サーバ情報DB112には、仮想サーバ名201、仮想サーバが属するプラットフォームを示すプラットフォーム名202、および、仮想サーバのイメージが格納されている物理サーバを示す物理サーバ名203が格納されている。仮想サーバ名201は、クラウドシステム全体において一意なサーバ名である。ホスト端末101のコマンド送信部102が送信するコマンドにおいては、引数として、この仮想サーバ名を指定する。これにより、送信したコマンドにおいて、どの物理サーバに仮想サーバのイメージファイルが格納されているかということには依存せずに、意図した仮想サーバを操作することが可能となる。図3は、コマンド変換DB113に格納されるコマンド変換関連情報の一例を示す図である。図に示すように、コマンド変換DB113には、プラットフォーム名301、変換前のコマンドであり制御サーバ103から投入されるコマンドそのものを示すコマンド名302、および、当該プラットフォームのコマンド処理部115に投入するコマンド形式を格納するコマンド303が格納されている。コマンド名302は、異なるプラットフォームに対しても共通に用いることができる共通コマンド名である。プラットフォーム名301は、プラットフォーム名202と対応しており、仮想サーバ情報DB112と組み合わせることによって当該プラットフォームのコマンド処理部に投入する実コマンドを構成することが可能となる。ここで、例えばホスト端末101からpoweronvmpA1というコマンドが投入されたとする。引数の仮想サーバ名としてvmpA1が指定されているので、仮想サーバ情報DB112の仮想サーバ名201がvmpA1であるレコードを参照し、vmpA1のプラットフォーム名202がplatformAであり、物理サーバ名203がPhysicsServerAであることが検索できる。さらに、そのプラットフォーム名platformAとコマンド名poweronを、コマンド変換DB113から検索することにより、該当するplatformAのコマンド形式がvmpoweronp<物理サーバ名>v<仮想サーバ名>であることが分かる。これらの情報を元に、platformAの物理サーバに投入する実際のコマンドはvmpoweronpPhysicsServerAvvmpA1として投入することが可能となる。図4は、物理サーバステータスDB114に格納されるステータス情報の一例を示す図である。図で示すように、物理サーバステータスDB114には、物理サーバ名401と、ステータス402が格納される。初期状態では、すべての物理サーバのステータス402はNotRunningに設定される。物理サーバにコマンドが投入されると、該当する物理サーバ名401に対するステータス402がRunningに更新され、ジョブが完了するとNotRunningに戻される。図5は、本実施形態のクラウド統一操作システムにおける処理の概要を示すフローチャートである。まず、ホスト端末101は、利用者から入力されたコマンドをコマンド送信部102に渡す。コマンド送信部102は、制御サーバ103に対してネットワーク経由でそのコマンドを送信するステップ501。そのコマンドは、プラットフォームにかかわらず共通に利用できるコマンドであり、引数として仮想サーバ名が指定されているものである。次に、制御サーバ103のコマンド受信部104がそのコマンドを受け取るステップ502。プラットフォーム検索部105は、仮想サーバ情報DB112に対して、コマンド受信部104が受け取った仮想サーバ名をキーに、仮想サーバのプラットフォーム名202と物理サーバ名203を検索するステップ503。コマンド変換部106は、ステップ502で受け取ったコマンドとプラットフォーム名202の情報より、コマンド変換DB113のコマンド303を参照し、コマンド処理部に投入する実コマンドに変換するステップ504。さらに、その実コマンドに対し、実行するコマンド全体で一意となるジョブIDを付与するステップ505。スケジューリング処理部107は、スケジューリング処理により、コマンドキューの該当箇所にそのジョブを格納するステップ506。このスケジューリング処理については、図6で詳しく説明する。次に、コマンドキュー処理部108がコマンド送信判定処理を行うステップ507。コマンド送信判定処理については、図7で詳しく説明するが、要するに、コマンドキューに格納されたジョブのうち各コマンド処理部に送信可能なジョブをコマンド送信待ち状態に設定する処理を行うものである。コマンド送信判定処理によりコマンド送信待ち状態とされたコマンドキュー内のジョブジョブIDと、実コマンドと、その実コマンドの送信先の物理サーバ名を含むは、実コマンド送信部109に渡されるステップ508。実コマンド送信部109は、渡されたコマンドの投入先の物理サーバのステータス402をRunningに変更するように物理サーバステータスDBを更新するステップ509。また、実コマンド送信部109は、ステップ508で渡されたジョブの実コマンドを、該当物理サーバのプラットフォームのコマンド処理部に送信するステップ510。次に、コマンド実行結果受信部110は、各プラットフォームのコマンド処理部115a,115bから送信されるコマンドの結果を受信しステップ511、そのコマンドの結果を結果キューに格納するステップ512。結果キュー処理部111は、コマンドキューと結果キューとで同一のジョブIDを持つものをファイルに出力し、両キューから削除するステップ513。コマンドキューと結果キューとで同一のジョブIDを持つものとは、要するにサーバによる処理が終了したジョブである。次に、結果キュー処理部111は、そのコマンドを実行した物理サーバのステータスをNotRunningに変更するように物理サーバステータスDBを更新する。図6は、図5のステップ506のスケジューリング処理の詳細を示すフローチャートである。まず、受信したコマンドに管理者権限が付与されているかどうかを確認するステップ601。付与されていない場合は、コマンドキューの最後にジョブをキューインするステップ602。付与されている場合は、コマンドキューで待ち状態となっているジョブの先頭にジョブをキューインするステップ603。なお、図6の処理でコマンドキューにキューインしたジョブは、キューイン直後の初期状態では全て待ち状態とされる。コマンドキュー内の待ち状態のジョブは、後述する図7の処理図5のステップ507で待ち状態からコマンド送信待ち状態に変更される。コマンドキュー内のコマンド送信待ち状態のジョブは、図5のステップ508で実コマンド送信部に渡される。図7は、図5のステップ507のコマンド送信判定処理の詳細を示すフローチャートである。まず、物理サーバステータスDB114図4から全物理サーバのステータスを取得するステップ701。次に、ステータスがNotRunning状態となっている物理サーバに対するコマンドがコマンドキュー内に存在するかどうかを判定するステップ702。存在していたら、コマンドキュー内の当該ジョブの状態をコマンド送信待ち状態に変更するステップ703。存在していなかったら、ステップ701に戻り、コマンドキューに次のジョブが投入されるまで待つステップ702。なお、図5では説明の便宜のため全体の処理の流れをつなげて表記したが、実際にはステップ502~506の処理と、ステップ507の処理と、ステップ508~510の処理と、ステップ511~514の処理とは、別タスクで実行している。すなわち、ステップ502~506の処理では、ユーザから入力されたコマンドに応じて、コマンドキューにジョブをキューインする処理を繰り返している。ステップ507の処理では、コマンドキューに格納されているジョブに対して、当該ジョブの送信先である物理サーバがNotRunningであるジョブをコマンド送信待ち状態に変更する処理を繰り返している。ステップ508~510の処理では、コマンドキュー内のコマンド送信待ち状態のジョブを取り出して、該当物理サーバのコマンド処理部に送信する処理を繰り返している。ステップ511~514の処理では、コマンド処理結果が得られた後の処理を繰り返している。上記実施形態のシステムによれば、異なるプラットフォームが混在する場合でも共通のコマンドフォーマットを利用して各プラットフォームに対してコマンドを投入できる。また、同時に大量の仮想サーバを操作するコマンドが投入された場合でも、投入されたコマンドを一旦コマンドキューに格納し、NotRunning状態となっている物理サーバに対するコマンドを該コマンドキューから取り出しながら処理していくので、コマンドを処理しきれずにハングアップしたり異常に遅延することはない。さらに、同時に大量の仮想サーバを操作するコマンドが投入された後に入力されたコマンドでも、ステップ506~510のようにスケジューリングされて物理サーバに投入されるので、全体として効率的な処理が可能となる。"