ウェブサービスを提供するウェブサービス部と、前記ウェブサービスを利用する際に認証情報を入力することなくウェブサービスが利用可能となる認証トークンと、前記認証情報とを管理する認証サービス部と、前記認証サービス部が管理する情報を取得して前記ウェブサービス部からの要求に応える認証APIサービス部とから構成され、前記認証サービス部と、前記認証APIサービス部は連携して認証サービスを提供し、前記認証APIサービス部は、要求を受け取り処理したことを示すログを第1の間隔で出力し、前記認証サービス部は、要求を受け取り処理したことを示すログを前記第1の間隔よりも間隔が長い第2の間隔で出力し、前記認証APIサービス部により出力されたログと、前記認証サービス部により出力されたログとを一時ログフォルダへ保存し、前記第2の間隔より長い、または等しい間隔で前記一時ログフォルダに保存されたログを前記認証サービスのログとしてログフォルダへ出力することを特徴とするサーバーシステム。前記認証サービスのログを出力する際、前記認証サービス部がログを出力した時点から前記第1の間隔が経過するまでの間に、前記一時ログフォルダへ保存されたログを前記認証サービスのログとして前記ログフォルダへ出力することを特徴とする請求項1に記載のサーバーシステム。前記認証APIサービス部が出力するログにはテナント情報が記載されており、一方、前記認証サービス部が出力するログにはテナント情報が記載されていない場合であって、前記認証サービスが出力したログに記載されているユーザー情報を基に、該ユーザー情報に関連するテナント情報を前記認証サービス部から取得し、前記認証サービスが出力したログに追記することを特徴とする請求項1または2に記載のサーバーシステム。ウェブサービス部は、ウェブサービスを提供し、認証サービス部は、前記ウェブサービスを利用する際に認証情報を入力することなくウェブサービスが利用可能となる認証トークンと、前記認証情報とを管理し、認証APIサービス部は、前記認証サービス部が管理する情報を取得して前記ウェブサービス部からの要求に応え、前記認証サービス部と、前記認証APIサービス部は連携して認証サービスを提供し、前記認証APIサービス部は、要求を受け取り処理したことを示すログを第1の間隔で出力し、前記認証サービス部は、要求を受け取り処理したことを示すログを前記第1の間隔よりも間隔が長い第2の間隔で出力し、前記認証APIサービス部により出力されたログと、前記認証サービス部により出力されたログとを一時ログフォルダへ保存し、前記第2の間隔より長い、または等しい間隔で前記一時ログフォルダに保存されたログを前記認証サービスのログとしてログフォルダへ出力するようにサーバーシステムを制御する制御方法。請求項4に記載の制御方法をサーバーシステムに実行させるためのプログラム。既存のサービスを流用して新たなサービスを提供する際に、既存のサービスに対してカスタマイズできる部分が限られているため、既存のサービスを提供するアプリケーション内部の処理を修正出来ない場合がある。特に各サービスがそれぞれ異なる間隔でログを出力していて、既存のサービスを提供するアプリケーションのログ出力間隔を変更できない場合、ある時間においてログを取得した際、サービス全体のログとしては不完全な状態、即ち、一部のログが不足している状態になりうる。この状態は、認証サービスのようなサービス内での処理順序が重要なサービスにおいて問題となる。例えば、ログインを受け付けるログインサービスがあり、このサービスは内部処理が修正出来ず、ある間隔でしかログを出力できないものとする。ここで、このログインサービスを利用する機能を新規で作成し連携させ、認証サービスを構築したとする。さらに、その新機能はサービス監視のために常時ログを出力すると仮定する。この場合、ログインサービスが出力するログの出力が遅いため、認証サービスにログインしたというログが出力されていないが、認証サービスを利用しているログが出力されている事態が起きうる。監視者がこのようなログを見た場合、ログインしたというログがないにもかかわらず、認証サービスが利用されたと認識するので、サービスが不正利用されている可能性を疑うであろう。その他の課題としては次の様な事が考えられる。一定時間経過後に認証サービスにログインしたというログが出力されるので、監視者は常にログを時系列順に確認することが困難となり、サービスの監視や管理が困難となる。その他の課題としては次の様な事が考えられる。ログインサービスが出力するログの出力が早い場合は、ログアウトしたログが出力された後で、操作内容のログが出力されることが起きうる。この状態でログ監視を行う場合、監視者は操作内容のログが出力されるたびに過去のログから操作者がログアウトしていないかを確認し続ける必要がある。その他の課題としては次の様な事が考えられる。これまでクラウドサービスとして提供していなかったサービスをクラウドサービスと連携させ、クラウドサービスに対応させる事が考えられる。しかし、マルチテナントに対応していないサービスから出力されるログには、テナント情報が出力されない場合がある。この場合、出力されているログがどのテナントに属するユーザーの操作なのかが判断出来ないため、ログとして不十分となる。例えば、ログインを受け付ける認証サービスがマルチテナントに対応しておらず、内部処理も修正できないものとする。一方、その認証サービスを利用する機能がマルチテナントに対応しているものとする。ユーザーの属性情報の一つにテナント情報を持たせて、機能利用時にテナント情報を取得して判断などをすることで、マルチテナントを実現することが出来る。この場合、操作時に出力されるログにテナント情報を出力することは出来るが、ログインした際のログにはテナント情報が出力されない。本発明の一実施形に係るサーバーシステムは、ウェブサービスを提供するウェブサービス部と、前記ウェブサービスを利用する際に認証情報を入力することなくウェブサービスが利用可能となる認証トークンと、前記認証情報とを管理する認証サービス部と、前記認証サービス部が管理する情報を取得して前記ウェブサービス部からの要求に応える認証APIサービス部とから構成され、前記認証サービス部と、前記認証APIサービス部は連携して認証サービスを提供し、前記認証APIサービス部は、要求を受け取り処理したことを示すログを第1の間隔で出力し、前記認証サービス部は、要求を受け取り処理したことを示すログを前記第1の間隔よりも間隔が長い第2の間隔で出力し、前記認証APIサービス部により出力されたログと、前記認証サービス部により出力されたログとを一時ログフォルダへ保存し、前記第2の間隔より長い、または等しい間隔で前記一時ログフォルダに保存されたログを前記認証サービスのログとしてログフォルダへ出力することを特徴とする。本発明により、異なる間隔でログを出力するサービスが連携しているサービスにおいて、ある時点で全てのサービスが出力したログを取得できる。また、その他の効果として、マルチテナントに対応していないサービスが出力するログを、マルチテナントに対応したログとすることが出来る。以下、本発明を実施するための最良の形態について図面を用いて説明する。[システム構成]図1は、本発明の実施例のシステム構成を示すブロック図である。図中10は、WideAreaNetworkWAN10であり、本発明ではWorldWideWebWWWシステムが構築されている。図中11は各構成要素を接続するLocalAreaNetworkLAN11である。また図中12はファイアーウォールである。図中13はクライアント17からの要求を受け、認証サービスを利用してウェブサービスを提供するサービス提供サーバー13である。図中14は、認証サービスを利用するサービスからの要求を受け、認証認可サーバーへと処理を行うAPIAplicationProgrammingInterfaceを提供する認証APIサーバー14であり、APIを利用した呼び出しを受けることで所定の機能を動作させる。図中15は認証APIサービスや認証サービスを提供するサービスからの要求を受け、ユーザー認証や認証情報管理、ユーザーの認可を行う認証認可サーバー15である。図中16は認証認可サービス、認証APIサービス、認証サービスを利用するサービスが連携している認証サービスである。なお、認証サービスを利用するサービスは不図示の他のサービスであってもよく、その場合、認証サービスは認証認可サービスと認証APIサービスとが連携するサービスとなる。なお、認証サービスがサーバーシステムに相当し、サーバーシステムは1台から構成されるシステムであっても、複数台から構成されるシステムであっても良い。認証サービス16を提供するサーバーシステムの運用方法について特に制限はない。よって、認証認可サーバーを認証サービス部と称し、認証APIサーバーを認証APIサービス部と称し、サービス提供サーバーをサービス提供サービス部、またはウェブサービス部と称する。図中17はLAN11およびWAN10を介して各サーバーに対してWebリクエストを発行するクライアント端末17であり、より具体的にはWWWを参照可能なWebブラウザを備えたクライアント端末である。[ハードウェア構成]図2は、図1中の認証認可サーバー13、認証APIサーバー14、サービス提供サーバー15、あるいはクライアント端末17のハードウェア構成を示すブロック図である。図2に示されるハードウェア構成図は一般的な情報処理装置及び出力デバイスのハードウェア構成図に相当するものとし、本実施形態の各情報端末、サーバーは一般的な情報処理装置のハードウェア構成を適用できる。図2において、CPU20は、ROM22に記憶された、或いはHDD23からRAM21にロードされたOSやアプリケーション等のプログラムを実行する。ここでOSとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをOSと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。RAM21は、CPU20の主メモリ、ワークエリア等として機能する。入力装置24は、不図示のキーボードや不図示のポインティングデバイスからのキー入力を制御する。出力装置25は、不図示の各種ディスプレイの表示を制御する。HDD23は、各種データを記憶する外部メモリ、例えばハードディスクやフラッシュメモリなどの永続記憶装置である。ネットワークインターフェース26はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。[ソフトウェア構成]図3は、本発明の実施形態に係るサービス提供サーバー13上で動作する、認証サービス利用サービス30のソフトウェアモジュールの構成図である。Webアプリケーション301はWebからのリクエストを受け付けるWebインタフェースを備えており、クライアント17が備えるWebブラウザからのリクエストに対して不図示の画面を生成して応答する。Webアプリケーション301は認証サービスへの処理要求を受けると、認証APII/F302を利用して、認証APIサービス40へと処理要求を行う。エージェント部303は、Webアプリケーション301に処理要求が来た際に、その要求をしたユーザーの認証状態を確認する。要求者が認証されていなかった場合や認証の有効期限が切れていた場合、Webアプリケーション301に認証要求画面を作成、表示させて、認証を要求する。ここで、本発明では認証方式として、ユーザーを特定するユーザーIDおよびパスワードを認証情報として登録しておき、認証リクエストで取得した情報とのマッチングを行う方式として説明する。ただし、この認証方式に制限するものではなく、電子証明書を確認する方式など、他の認証方式でも実現可能である。エージェント部303はユーザーIDおよびパスワードを取得すると、認証認可サービス50に対して認証を要求する。認証に成功した場合、認証状態を管理する認証トークンを返す。図4は、認証APIサーバー上で動作する、認証APIサービス40のソフトウェアモジュールの構成図である。認証APII/F401は、他のサービスから認証APIへの要求を受け取る。他のサービスとは、例えば、サービス提供サーバー13が提供する認証サービス利用サービス30からの要求である。API処理部402は認証APII/F401によって受け取った要求に基づいて処理を行い、必要に応じて通信部403を介して認証認可サービス50が管理する情報を取得し、その要求に応える。また、API処理部402で行った処理の内容はリアルタイムでログに出力され、認証APIサービス40のログとして認証APIサーバー14内の認証APIサービスログフォルダに保存される。即ち、API処理部402での処理が完了した時点でログが出力される。認証APIサービスは、第1の間隔API処理部402での処理が完了した時点で出力されるので、第1の間隔とは処理が完了する間隔のことを指すでログを主力するログ処理部404は、認証サービスとして連携する全てのサービスの中で、最も出力間隔が長いサービスのログが出力された時点で起動する。ログ処理部404は起動すると、上記認証APIサービス40のログを認証サービス16の一時ログとして認証APIサーバー14内の認証サービス一時ログフォルダに移動する。また同時に通信部403を介して認証認可サービス50へとログ取得要求を行い、取得したログを認証サービス16の一時ログとして認証サービス一時ログフォルダに保存する。その後、認証サービス一時ログフォルダ内のログを確認し、ログ出力時間で最も古い時刻までのログを抽出し、その時刻までのログを認証サービス16のログとして認証サービスログフォルダに移動する。例えば、1時間ごとにログを出力するサービスと45分ごとにログを出力するサービスが連携していた場合には、1時間毎にログを収集する。そして1時間ごとに出力するサービスが13;00まで、45分ごとに出力するサービスが12:45までのログが出力されていた場合、12:45までのログをサービス全体のログとして保存する。換言すれば、あるサービス部がログを出力した時点から最も短い間隔が経過するまでに出力されたログを認証ログとして出力する。なお、本処理部の機能は認証APIサーバー以外の不図示のログ収集サーバーにあってもよい。その場合、ログ処理部404は外部サービスからの要求を受け、認証APIサービスのログを取得し、外部サービスへと送信する処理を行う。図5は、認証認可サービス上で動作する、認証認可サービス50のソフトウェアモジュールの構成図である。設定部501は、通信I/F503を介してユーザー情報の設定要求を受け、認証情報記憶部505の情報の設定を行う。認証認可部502は、通信I/F503やエージェント通信I/F504を介して認証認可要求を受け、認証情報記憶部505の情報を利用して認証および認可を行う。認証認可部502は認証に成功した場合、認証トークンを発行し、認証情報ユーザーIDパスワードと関連付けて認証情報記憶部505に保存し管理する。また、認証認可部502での処理内容はログとして1時間毎に出力され、認証認可サービス50のログとして認証認可サーバー15内の認証認可サービスログフォルダに保存される。認証認可サービス50がログを出力する間隔が第2の間隔に相当し、第2の間隔は第1の間隔よりも長いものとする。ログ処理部506は、通信I/F503を介してログ取得要求を受け付け、認証認可サービスログフォルダ内のログを送信する。なお、認証トークンを有する装置が、ウェブサービス部が提供するウェブサービスを利用する際、認証情報を入力することなく利用可能となる。認証トークンは、利用の制限が設けられた認可トークンであっても良い。[データ構造]図6は認証情報記憶部505にて管理されているユーザー認証情報の例である。図6Aは、ユーザー認証情報のデータ構造の一例であり、ユーザーを特定するためのユーザーID601とパスワード602、およびユーザー属性が管理されている。ユーザー属性は、ユーザーが所属するテナント情報を示すテナントID603とユーザーの権限情報604、その他のユーザー属性情報605からなる。図6Bは、ユーザーの認証状態を管理する認証トークン情報の一例であり、ユーザーを特定するユーザーID611および、ユーザーが認証されたことを示すトークン612からなる。[フローチャート]以下、本発明の認証サービスにおける処理フローについてフローチャートを用いて説明する。図7は、認証APIサービス40および認証認可サービス50が連携している認証サービス16において、認証サービス16のログとして認証APIサービス40と認証認可サービス50のログを集める際の処理フローである。以下のフローにおいて、認証APIサービス40はリアルタイムにログを出力し、認証認可サービス50は1時間ごとにログを出力するものとする。そのため、認証APIサービス40のログ処理部404は1時間ごとに起動するものとする。ログ処理部404が起動すると、ステップS701、S702において認証APIサービスのログフォルダにログが出力されているかの確認を行う。ログが出力されていた場合、ステップS703にて対応するログを認証サービス一時ログフォルダに移動する。また、ログ処理部404は起動時にステップS704にて、連携している認証認可サービスのログを要求する。認証認可サービス50のログ処理部506は、ステップS705にて認証APIサービスからのログ要求を受け付けると、ステップS706で認証認可サービスのログフォルダにログが出力されているかの確認を行う。ログが出力されていた場合、ステップS707にて対応するログをログ送信用のフォルダに移動する。その後ステップS708にて、ログ送信用フォルダ内のログを認証APIサービスへと送信する。認証APIサービスのログ処理部は、ステップS709で認証認可サービスのログを受信すると、ステップS710にて受信したログを認証サービス一時ログフォルダに移動する。全てのサービスのログを取得すると、ステップS711にて、ログ出力時間が最も古いログを調べ、その時刻までに出力されたログを抽出する。なお、過去に抽出されずに残っていたログも抽出対象とする。その後ステップS712にて、抽出されたログを認証サービス16のログとして、認証サービスログフォルダへと移動する。認証サービスログフォルダへ移動する際、第2の間隔毎に移動することとするが、第2の間隔よりも長い間隔で移動させても良い。なぜなら、ある期間内に出力された、認証APIサービス部により出力されたログと、認証サービス部により出力されたログとが漏れなく提供されるからである。以上のフローにより、異なるタイミングでログを出力するサービスが連携している場合に、全てのサービスが出力したある時間までのログを、欠けることなくまとめることが出来る。次に、本発明を実施するための第2の形態について図面を用いて説明する。第1の実施例においては、連携しているサービスが異なる間隔でログを出力する場合に、ある時間までに全てのサービスが出力するログを不足なく集めることができた。本実施例では、第1の実施例において、連携しているサービスの中にマルチテナントに対応していないサービスが存在した場合にログを収集する方法を説明する。なお、本実施例においては、第1の実施例と同一部分に関する説明は省略し、その差異についてのみ説明する。[データ構造]図8は認証APIサービス、認証認可サービスにおいて出力されるログ情報の例と、第二の実施形態に基づいて変換されたログ情報の例を示す。図8Aは、マルチテナントに対応している認証APIサービスが出力するログ情報である。処理が実行された日時と実行者の情報および処理内容からなる。実行者の情報には、実行者を表すユーザーIDと、実行者のテナント情報を表すテナントIDが含まれて記載されている。一方、図8Bは、マルチテナントに対応していない認証認可サービスが出力するログ情報である。図8Aと同様に処理が実行された日時と実行者情報、処理内容からなるが、マルチテナントに対応していないため、テナント情報が記載されたログは出力されない。図8Cは、図8Bに示した認証認可サービスが出力するログ情報を、第二の実施例に基づいて変換したログ情報である。図8Bのログ情報にユーザーのテナント情報を表すテナントIDが追加されたログとなる。[フローチャート]以下、本発明の認証サービスにおける処理フローについてフローチャートを用いて説明する。図9は、認証APIサービスおよび認証認可サービスが連携している認証サービスにおいて、ログを集める際の処理フローである。以下のフローにおいて、認証APIサービス40はマルチテナントに対応しており、認証認可サービス50はマルチテナントに対応していないサービスとする。また、認証認可サービス50上のユーザー情報には、テナント情報がユーザーの属性情報の一つとして管理されており、認証APIを用いて取得できるものとする。ステップS701からステップS710までは、図7と同じ処理である。認証APIサービスのログ処理部は、ステップS710で認証認可サービスのログを受け取ると、ステップS901でそのログを1件読み込む。ログ処理部はステップS902にて、ログに含まれるユーザー情報を利用してユーザーのテナントID情報取得要求を行う。認証認可サービスの設定部501は、ステップS903にてテナントID情報取得要求を受けると、ステップS904でユーザー属性からテナント情報を表すテナントIDを取得する。その後ステップS905にて取得したテナント情報を認証APIサービスへと返す。認証APIサービスはステップS906にてテナント情報を受け取ると、ステップS907にてログにテナント情報を追記し、ログ情報が補完され、補完情報が追加済みのログとしてログ情報を保存する。その後、全てのログにテナント情報を追加するまで、ステップS901からステップS907を繰り返す。こうして全てのログにテナント情報を追加した後で、ステップS711およびS712を行い、認証サービス16のログを取得する。以上のフローにより、マルチテナントに対応していないサービスが出力するログにテナント情報を追加して、マルチテナントに対応したログとすることができる。