(57)【要約】【課題】パッチ適用による不具合の発生を抑制することを課題とする。【解決手段】管理サーバは、パッチの適用対象のサーバで実行される機能が使用する第１のリソース情報を取得する処理を実行する。そして、管理サーバは、パッチが実行された場合に、パッチがアクセスする第２のリソース情報を取得する処理を実行する。その後、管理サーバは、第１のリソース情報と第２のリソース情報とに基づいて、パッチの適用可否を判定する処理を実行する。【選択図】図２
2014013457.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
パッチの適用対象の情報処理装置で実行される機能が使用する第１のリソース情報を取得し、
前記パッチが実行された場合に、前記パッチがアクセスする第２のリソース情報を取得し、
取得した第１のリソース情報と第２のリソース情報とに基づいて、前記パッチの適用可否を判定する、
処理を実行させることを特徴とするパッチ判定プログラム。
【請求項２】
前記パッチの適用対象の情報処理装置で実行可能な各機能を他の情報処理装置で実行して、各機能がアクセスしたリソースの情報を特定し、
前記パッチの適用対象の情報処理装置上の機能が出力したログを収集する、処理をさらにコンピュータに実行させ、
前記第１のリソース情報を取得する処理は、収集したログから前記パッチの適用対象の情報処理装置で動作している機能を抽出し、抽出した機能が使用するリソースの情報を、各機能がアクセスしたリソースの情報から取得することを特徴とする請求項１に記載のパッチ判定プログラム。
【請求項３】
前記判定する処理は、前記第１のリソース情報と、前記第２のリソース情報とに基づいて、前記パッチがアクセスするリソースを前記情報処理装置で実行される機能が使用する場合に、前記パッチの適用可否を管理者に問い合わせることを特徴とする請求項１または２に記載のパッチ判定プログラム。
【請求項４】
コンピュータが、
パッチの適用対象の情報処理装置で実行される機能が使用する第１のリソース情報を取得し、
前記パッチが実行された場合に、前記パッチがアクセスする第２のリソース情報を取得し、
取得した第１のリソース情報と第２のリソース情報とに基づいて、前記パッチの適用可否を判定する、
処理を実行することを特徴とするパッチ判定方法。
【請求項５】
パッチの適用対象の情報処理装置で実行される機能が使用する第１のリソース情報を取得する第１取得部と、
前記パッチが実行された場合に、前記パッチがアクセスする第２のリソース情報を取得する第２取得部と、
前記第１取得部によって取得された第１のリソース情報と、前記第２取得部によって取得された第２のリソース情報とに基づいて、前記パッチの適用可否を判定する判定部と
を有することを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パッチ判定プログラム、パッチ判定方法および情報処理装置に関する。
【背景技術】
【０００２】
サーバの高性能化やサーバの仮想化が進み、サーバ管理の重要性が増している。１つのクローンマスターから配備された複数の仮想サーバは、同一のソフトウェア構成であるが、仮想サーバごとに業務が異なる場合があり、業務に合わせて適切なパッチを適用することになる。
【０００３】
セキュリティ確保のためにも、すべてのサーバに対して、すべての公開パッチを適用することが好ましいが、適用すると業務に影響を与えるパッチもある。このため、公開パッチの中から適用するパッチを抽出する技術が知られている。
【０００４】
例えば、サーバのエラー発生時に採取したログから不具合の箇所を特定し、不具合の箇所を修正する公開パッチを適用対象として抽出する技術が知られている。また、サーバで使用しているモジュールの使用回数を監視し、公開されたパッチで提供される修正モジュールと照らし合わせて、適用候補を抽出する技術が知られている。また、パッケージ内のファイルへのアクセス回数を監視し、アクセス数が一定以上のファイルを有するパッケージを修正対象とするパッチを適用候補として抽出する技術が知られている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−１９１５２７号公報
【特許文献２】特開２０００−０１０７６６号公報
【特許文献３】国際公開第２００７／１０５２７４号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記技術で抽出されたパッチを適用した場合、サーバが実行する業務へ悪影響を及ぼす可能性があり、パッチを適用することで、却って不具合が発生する場合があるという問題がある。
【０００７】
具体的には、あるソフトウェアが使用するリソースがパッチの適用よって修正された場合、修正されたリソースを使用する他のソフトウェアに悪影響を及ぼす場合がある。
【０００８】
例えば、ソフトウェアＡとソフトウェアＢとが連動して動作する状況で、障害が発生したソフトウェアＡにパッチを適用した場合、パッチ適用が原因で、ソフトウェアＡと連動するソフトウェアＢに障害が発生する場合もある。このため、不具合の箇所を修正する公開パッチを適用対象とするだけでは、別の不具合を誘発する可能性があり、不十分である。
【０００９】
また、適用候補となったパッケージにパッチを適用した場合、このパッケージを一構成要素とする業務の実行において、協働する他のソフトウェアに悪影響を及ぼす可能性がある。このため、アクセス数が一定以上のファイルを有するパッケージを修正対象とするパッチを適用候補とするだけでは、不具合を誘発する可能性があり、不十分である。同様に、使用回数の多いモジュールを修正するパッチを適用候補とするだけでは不十分である。
【００１０】
１つの側面では、パッチ適用による不具合の発生を抑制することができるパッチ判定プログラム、パッチ判定方法および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
１態様のパッチ判定プログラムの案では、コンピュータに、パッチの適用対象の情報処理装置で実行される機能が使用する第１のリソース情報を取得する処理を実行させる。コンピュータに、前記パッチが実行された場合に、前記パッチがアクセスする第２のリソース情報を取得する処理を実行させる。コンピュータに、取得した第１のリソース情報と第２のリソース情報とに基づいて、前記パッチの適用可否を判定する処理を実行させる。
【発明の効果】
【００１２】
１態様によれば、パッチ適用による不具合の発生を抑制することができる。
【図面の簡単な説明】
【００１３】
【図１】図１は、実施例１に係るシステムの全体構成例を示す図である。
【図２】図２は、実施例１に係るシステムを構成する各装置の機能構成を示す機能ブロック図である。
【図３】図３は、機能定義ＤＢに記憶される情報の例を示す図である。
【図４】図４は、機能使用リソースＤＢに記憶される情報の例を示す図である。
【図５】図５は、機能ログＤＢに記憶される情報の例を示す図である。
【図６】図６は、機能利用状況ＤＢに記憶される情報の例を示す図である。
【図７】図７は、パッチアクセスリソースＤＢに記憶される情報の例を示す図である。
【図８】図８は、パッチ照合結果ＤＢに記憶されるパッチＯ２の仮想サーバＡに対する判定結果の例を示す図である。
【図９】図９は、パッチ照合結果ＤＢに記憶されるパッチＣ１の仮想サーバＡに対する判定結果の例を示す図である。
【図１０】図１０は、パッチ適用判定のポリシーの例を示す図である。
【図１１】図１１は、表示部に表示される表示例を示す図である。
【図１２】図１２は、機能定義処理の流れを示すフローチャートである。
【図１３】図１３は、機能使用リソースを特定する処理の流れを示すフローチャートである。
【図１４】図１４は、ログを収集する処理の流れを示すフローチャートである。
【図１５】図１５は、利用機能を解析する処理の流れを示すフローチャートである。
【図１６】図１６は、パッチがアクセスするリソースを特定する処理の流れを示すフローチャートである。
【図１７】図１７は、パッチ適用の可否を判定する処理の流れを示すフローチャートである。
【図１８】図１８は、コンピュータのハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１４】
以下に、本願の開示するパッチ判定プログラム、パッチ判定方法および情報処理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例１】
【００１５】
［全体構成］
図１は、実施例１に係るシステムの全体構成例を示す図である。図１に示すように、このシステムは、パッチ公開サーバ１、管理サーバ１０、クローンマスター３０、ＶＭ（Virtual  Machine）ホスト４０、仮想サーバＡ、仮想サーバＢ、仮想サーバＣ、仮想サーバＤを有する。なお、各仮想サーバが同様の構成を有するので、仮想サーバ５０と表記する。
【００１６】
パッチ公開サーバ１は、公衆回線網２などで管理サーバ１０と接続され、定期的にパッチを公開するサーバ装置である。管理サーバ１０は、公衆回線網２などでパッチ公開サーバ１と接続され、ＶＭホスト４０とネットワークで接続されるサーバ装置である。この管理サーバ１０は、定期的に公開されるパッチをパッチ公開サーバ１から取得し、各仮想サーバ５０に公開されたパッチを適用するか否かを判定する。
【００１７】
クローンマスター３０は、仮想サーバ５０を配備するときの複製元である。つまり、クローンマスター３０と各仮想サーバ５０とでは、ＯＳ（Operating  System）やソフトウェア構成が同じとなる。ＶＭホスト４０は、クローンマスター３０のソフトウェア構成等をコピーしてＶＭゲストを配備するサーバである。
【００１８】
仮想サーバ５０は、クローンマスター３０を複製元として配備された仮想サーバであり、ＶＭゲストとして機能する。また、各仮想サーバ５０は、同一のソフトウェア構成である。各仮想サーバ５０は、それぞれ異なる業務を実行しているものとする。すなわち、各仮想サーバ５０で実行される機能は、必ずしも一致していない。また、クローンマスター３０と各仮想サーバ５０とは同一の物理サーバで実現されてもよく、別々の物理サーバで実現されてもよい。
【００１９】
このような状態において、管理サーバ１０は、パッチの適用対象の各仮想サーバ５０で実行される機能が使用するリソースの情報を示す第１のリソース情報を取得する。そして、管理サーバ１０は、パッチが実行された場合に、パッチがアクセスするリソースの情報を示す第２のリソース情報を取得する。その後、管理サーバ１０は、第１のリソース情報と第２のリソース情報とに基づいて、パッチの適用可否を判定する。
【００２０】
この結果、管理サーバ１０は、パッチ適用対象の仮想サーバの機能が使用するリソースに、パッチがアクセスするか否かによってパッチの適用可否を判定することができる。したがって、管理サーバ１０は、業務への影響を考慮した適用可否を判定し、パッチ適用による不具合の発生を抑制することができる。
【００２１】
［各装置の構成］
次に、図２を用いて、図１に示したシステムが有する各装置の構成について説明する。図２は、実施例１に係るシステムを構成する各装置の機能構成を示す機能ブロック図である。なお、パッチ公開サーバ１は、一般的なパッチ公開サーバと同様の機能を有するので、ここでは、管理サーバ１０、クローンマスター３０、仮想サーバ５０について説明する。
【００２２】
（管理サーバの構成）
図２に示すように、管理サーバ１０は、通信制御インタフェース部１１、表示部１２、機能定義ＤＢ１３、機能使用リソースＤＢ１４、機能ログＤＢ１５、機能利用状況ＤＢ１６、パッチアクセスリソースＤＢ１７、パッチ照合結果ＤＢ１８を有する。また、管理サーバ１０は、取得部１９、特定部２０、収集部２１、判定部２２、表示制御部２３を有する。なお、各ＤＢは、メモリやハードディスクなどの記憶装置に記憶される。各処理部は、ＣＰＵ（Central  Processing  Unit）などによって実行される。
【００２３】
通信制御インタフェース部１１は、他のサーバとの間の通信を制御する処理部である。例えば、通信制御インタフェース部１１は、パッチ公開サーバ１から公開パッチを受信する。また、通信制御インタフェース部１１は、クローンマスター３０から機能定義等を受信し、仮想サーバ５０からログを受信する。また、通信制御インタフェース部１１は、仮想サーバ５０に公開パッチを送信する。
【００２４】
表示部１２は、各種情報を表示するディスプレイやタッチパネルなどの表示媒体である。例えば、表示部１２は、表示制御部２３の指示操作によって、パッチの照合結果を表示する。
【００２５】
機能定義ＤＢ１３は、クローンマスターにインストールされている利用可能な機能についての定義を記憶する記憶部である。ここでいう機能とは、ソフトウェア、ミドルウェア、アプリケーション、コマンド、サービスなどである。また、ここで記憶される情報は、取得部１９等によって格納される。図３は、機能定義ＤＢに記憶される情報の例を示す図である。図３に示すように、機能定義ＤＢ１３は、「ソフトウェア名、機能、機能トリガー実行プログラム、サービス、ログタイプ、出力ログファイル、開始特定文字列、終了特定文字列、開始イベントＩＤ、終了イベントＩＤ」を対応付けて記憶する。
【００２６】
ここで記憶される「ソフトウェア名」には、機能を提供するソフトウェアの名称が設定される。「機能」には、業務を提供する機能の名称が設定される。「機能トリガー実行プログラム」には、機能を提供する実行プログラム名が設定される。「サービス」には、機能よって提供されるサービスの名称が設定される。「ログタイプ」には、機能が出力するログのタイプが設定される。「出力ログファイル」には、機能が出力するログのファイル名が設定される。「開始特定文字列」には、機能が出力したログの開始を特定する文字列が設定される。「終了特定文字列」には、機能が出力したログの終了を特定する文字列が設定される。「開始イベントＩＤ」には、機能が出力したイベントログの開始を特定するＩＤが設定される。「終了イベントＩＤ」には、機能が出力したイベントログの終了を特定するＩＤが設定される。
【００２７】
図３の１行目を例に具体的に説明する。１行目の場合、アプリＡが提供する機能Ａ１が、「C:\aplA\bin\a11.exe」と「C:\aplA\bin\a12.exe」とによって実行される機能であること示す。また、機能Ａ１が、イベントログにログを出力し、そのイベントログの開始がＩＤ＝1003であり、そのイベントログの終了がＩＤ＝1004であることを示す。
【００２８】
次に、図３の５行目を例に具体的に説明する。５行目の場合、ミドルウェアＣが提供する機能Ｃ１は、「C:\mwC\bin\c1.exe」によって実行される機能であり、ServiceCを提供することを示す。また、機能Ｃ１は、テキストタイプのログを「C:\mwC\log\*」に出力する。そして、「C:\mwC\log\*」に出力されたログのうち、「MWC＿FUNC1＿START」が機能Ｃ１の開始を示し、「MWC＿FUNC1＿END」が機能Ｃ１の終了を示す。
【００２９】
図２に戻り、機能使用リソースＤＢ１４は、各機能が使用するリソースの情報を記憶する記憶部である。ここでいうリソースとは、ファイル、レジストリ、サービスなどである。また、サービスとは、サーバ上に常駐するプロセスのことであり、例えばＵＮＩＸ（登録商標）のデーモンプロセスなどが該当する。また、「使用する」とは、リソースがファイルやレジストリの場合には、参照、追加、更新、削除のことを指し、リソースがサービスの場合には、サービスとの通信のことを指す。また、ここで記憶される情報は、特定部２０等によって格納される。図４は、機能使用リソースＤＢに記憶される情報の例を示す図である。図４に示すように、機能使用リソースＤＢ１４は、「ソフトウェア名、機能、ファイル、レジストリ、サービス」を対応付けて記憶する。
【００３０】
ここで記憶される「ソフトウェア名」には、機能を提供するソフトウェアの名称が設定される。「機能」には、業務を提供する機能の名称が設定される。「ファイル」には、機能が使用するファイル名が設定される。「レジストリ」には、機能が使用するレジストリ名が設定される。「サービス」には、機能が使用するサービス名が設定される。なお、「ファイル、レジストリ、サービス」は、アプリケーションが使用するリソース、ミドルウェアが使用するリソース、ＯＳが使用するリソースを区別して管理してもよい。
【００３１】
図４の１行目を例に具体的に説明する。１行目の場合、アプリＡが提供する機能Ａ１が、「C:\aplA\bin\a11.exe」と「C:\aplA\bin\a12.exe」と「C:\aplA\bin\a1.dll」と「C:\mwC\etc\c1.ini」と「C:\WINDOWS\system32\w1.dll」との５ファイルを使用する。また、アプリＡが提供する機能Ａ１が、「HKLM\SOFTWARE\Fujitsu\aplA\a1」と「HKLM\SOFTWARE\Fujitsu\FJCC\c1」との２つのレジストリを使用する。
【００３２】
次に、図４の５行目を例に具体的に説明する。５行目の場合、ミドルウェアＣが提供する機能Ｃ１が、「C:\mwC\bin\c1.exe」と「C:\mwC\bin\c1.dll」と「C:\mwC\etc\c1.ini」と「C:\WINDOWS\system32\w5.dll」との４ファイルを使用する。また、ミドルウェアＣが提供する機能Ｃ１が、「HKLM\SOFTWARE\Fujitsu\FJCC\c1」と「HKLM\SYSTEM\XXX\o2」との２つのレジストリを使用する。また、ミドルウェアＣが提供する機能Ｃ１は、「ServiceC」を使用する。
【００３３】
図２に戻り、機能ログＤＢ１５は、各仮想サーバ５０から取得したログを記憶する記憶部である。この機能ログＤＢ１５は、各仮想サーバ５０ごとにログを記憶する。ここで記憶される情報は、収集部２１によって格納される。図５は、機能ログＤＢに記憶される情報の例を示す図である。
【００３４】
図５に示した情報は、仮想サーバ５０のアプリケーションＢが出力したログファイルに記憶される情報である。図５に示したログファイルには、「2012/02/01  3：00：00  APLB＿FUNC2＿START」と「2012/02/01  3：15：21  APLB＿FUNC2＿END」とが出力されている。これは、図３を参照すると、アプリＢの機能Ｂ２が出力したログであることがわかる。したがって、アプリＢの機能Ｂ２が、「2012/02/01  3：00：00」に起動し、「2012/02/01  3：15：21」に終了したことがわかる。
【００３５】
機能利用状況ＤＢ１６は、各仮想サーバで実行されている機能の利用状況を記憶する記憶部である。ここで記憶される情報は、特定部２０等によって格納される。図６は、機能利用状況ＤＢに記憶される情報の例を示す図である。図６は、一例として、仮想サーバＡで実行されている機能の利用情報を示している。図６に示すように、機能利用状況ＤＢ１６は、「ソフトウェア名、機能、サービス、前回測定から今回までの実行回数、過去１ヶ月間の累積実行回数、機能利用中」を対応付けて記憶する。
【００３６】
ここで記憶される「ソフトウェア名」には、機能を提供するソフトウェアの名称が設定される。「機能」には、業務を提供する機能の名称が設定される。「サービス」には、機能よって提供されるサービスが起動中か停止中かが設定される。「前回測定から今回までの実行回数」には、前回測定から今回までの間に機能が実行された回数が設定される。「過去１ヶ月間の累積実行回数」には、過去１ヶ月間で機能が実行された回数が設定される。「機能利用中」には、機能が利用中であるか否かが設定され、利用中である場合には○、利用中ではない場合には×が設定される。
【００３７】
図６の１行目を例に具体的に説明する。１行目の場合、アプリＡが提供する機能Ａ１が、前回測定から今回の測定までの間に１回実行され、過去１ヶ月間の累積実行回数が２２回であり、現在利用中であることを示す。図６の５行目を例に具体的に説明する。５行目の場合、ミドルウェアＣが提供する機能Ｃ１のサービスが起動中であることを示す。さらに、この機能Ｃ１は、前回測定から今回の測定までの間に１回実行され、過去１ヶ月間の累積実行回数が１回であり、現在利用中であることを示す。
【００３８】
パッチアクセスリソースＤＢ１７は、公開された各パッチごとに、パッチがアクセスするリソースの情報を記憶する。また、「アクセスする」とは、リソースがファイルやレジストリの場合には、参照、追加、更新、削除のことを指し、リソースがサービスの場合には、起動や停止のことを指す。ここで記憶される情報は、特定部２０等によって記憶される。図７は、パッチアクセスリソースＤＢに記憶される情報の例を示す図である。図７に示すように、パッチアクセスリソースＤＢ１７は、「パッチ、パッチ種別、パッチ重要度、ファイル、レジストリ、サービス」を対応付けて記憶する。
【００３９】
ここで記憶される「パッチ」には、パッチ公開サーバ１によって公開されたパッチの名称が設定される。「パッチ種別」には、公開されたパッチの種別が設定される。「パッチ重要度」には、公開されたパッチの重要度が設定される。「ファイル」には、公開されたパッチを実行した際に、パッチがアクセスするファイル名が設定される。「レジストリ」には、公開されたパッチを実行した際に、パッチがアクセスするレジストリ名が設定される。「サービス」には、公開されたパッチを実行した際に、パッチがアクセスするサービス名が設定される。なお、「パッチ、パッチ種別、パッチ重要度」は、公開パッチから取得することができ、その他の情報はパッチをテスト環境等で実行することで取得することができる。
【００４０】
図７の１行目を例に具体的に説明する。１行目の場合、パッチＡ１が、アプリケーションを修正するパッチであり、重要度が重要であることを示す。このパッチＡ１が、ファイル「C:\aplA\bin\a1.dll」とレジストリ「HKLM\SOFTWARE\Fujitsu\aplA\a1」とにアクセスすることを示す。
【００４１】
次に、図７の８行目を例に具体的に説明する。８行目の場合、パッチＯ１が、ＯＳを修正するパッチであり、重要度がセキュリティであることを示す。このパッチＯ１が、ファイル「C:\WINDOWS\system32\w1.dll」と「C:\WINDOWS\system32\other1.dll」とにアクセスすることを示す。また、パッチＯ１が、レジストリ「HKLM\SYSTEM\XXX\o1」とサービス「ServiceO」とにアクセスすることを示す。
【００４２】
図２に戻り、パッチ照合結果ＤＢ１８は、公開されたパッチごとに、各仮想サーバ５０に対するパッチの適用可否の判定結果を記憶する記憶部である。ここで記憶される情報は、判定部２２等によって格納される。図８は、パッチ照合結果ＤＢに記憶されるパッチＯ２の仮想サーバＡに対する判定結果の例を示す図である。図８に示すように、パッチ照合結果ＤＢ１８は、「リソース使用フラグ」と「判定結果」と「詳細テーブル」とを対応付けて記憶する。
【００４３】
ここで記憶される「リソース使用フラグ」には、パッチがアクセスするリソースを使用する機能が存在するか否かが設定され、存在する場合にはＯＮ、存在しない場合にはＯＦＦが設定される。この「リソース使用フラグ」は、後述する「詳細テーブル」に基づいて設定される。「判定結果」には、パッチの適用可否が設定され、例えば管理者判断、適用不要、適用必要などが設定される。
【００４４】
「詳細テーブル」は、「ソフトウェア名、機能、機能利用中、パッチの更新リソースと利用中機能のリソースとに共通のものがある、使用しているファイル、使用しているレジストリ、使用しているサービス」とが対応付けられる。
【００４５】
「ソフトウェア名」には、機能を提供するソフトウェアの名称が設定される。「機能」には、業務を提供する機能の名称が設定される。「機能利用中」には、機能が利用中であるか否かが設定され、利用中である場合には○、利用中ではない場合には×が設定される。「パッチの更新リソースと利用中機能のリソースとに共通のものがある」には、パッチがアクセスするリソースと機能がアクセスするリソースとが一致するか否かが設定され、一致する場合には○、一致しない場合には×が設定される。「使用しているファイル」には、パッチと機能とが共通に使用するファイル名が設定される。「使用しているレジストリ」には、パッチと機能とが共通に使用するレジストリ名が設定される。「使用しているサービス」には、パッチと機能とが共通に使用するサービス名が設定される。
【００４６】
図８の「詳細テーブル」には、機能利用中であるアプリＢの機能Ｂ１が使用するファイル「C:\WINDOWS\system32\w3.dll」と、図７に示すパッチＯ２がアクセスする「C:\WINDOWS\system32\w3.dll」とが一致している。この結果、リソース使用フラグに「ＯＮ」が設定され、判定結果に「管理者判断」が設定される。
【００４７】
図９は、パッチ照合結果ＤＢに記憶されるパッチＣ１の仮想サーバＡに対する判定結果の例を示す図である。図９に示す情報の構成は、図８と同様なので、詳細な説明は省略する。図９に示すように、機能利用中であるアプリＡの機能Ａ１が使用するファイル「C:\mwC\etc\c1.ini」と、図７に示すパッチＣ１がアクセスする「C:\mwC\etc\c1.ini」とが一致している。また、機能利用中であるアプリＡの機能Ａ１が使用するレジストリ「HKLM\SOFTWARE\Fujitsu\FJCC\c1」と、パッチＣ１がアクセスするレジストリ「HKLM\SOFTWARE\Fujitsu\FJCC\c1」とが一致している。
【００４８】
さらに、機能利用中であるミドルウェアＣの機能Ｃ１が使用するファイル「C:\mwC\bin\c1.dll」および「C:\mwC\etc\c1.ini」と、パッチＣ１がアクセスするファイル「C:\mwC\bin\c1.dll」および「C:\mwC\etc\c1.ini」とが一致している。また、機能利用中であるミドルウェアＣの機能Ｃ１が使用するレジストリ「HKLM\SOFTWARE\Fujitsu\FJCC\c1」と、パッチＣ１がアクセスするレジストリ「HKLM\SOFTWARE\Fujitsu\FJCC\c1」とが一致している。また、機能利用中であるミドルウェアＣの機能Ｃ１が使用するサービス「ServiceC」と、パッチＣ１がアクセスするサービス「ServiceC」とが一致している。これらの結果、リソース使用フラグに「ＯＮ」が設定され、判定結果に「管理者判断」が設定される。
【００４９】
取得部１９は、各仮想サーバから機能の定義情報を取得して機能定義ＤＢ１３に格納する処理部である。例えば、取得部１９は、クローンマスター３０で定義された情報を取得してもよく、ユーザに手動で設定させてもよい。
【００５０】
特定部２０は、機能を実行した場合に使用されるリソースの情報を特定して、機能使用リソースＤＢ１４に格納する処理部である。例えば、特定部２０は、パッチの適用対象の仮想サーバ５０で実行可能な各機能をクローンマスター３０に実行させて、各機能がアクセスしたリソースの情報を取得する。
【００５１】
また、特定部２０は、各仮想サーバにインストールされた機能の利用状況を特定して、機能利用状況ＤＢ１６に格納する処理部である。例えば、特定部２０は、各仮想サーバ５０ごとに、機能定義ＤＢ１３に記憶される各機能のログが機能ログＤＢ１５に記憶されるログに出力されているか否かによって、当該仮想サーバで利用されている機能を特定して機能利用状況ＤＢ１６に格納する。一例を挙げると、特定部２０は、仮想サーバＡについて収集されたイベントログに、「イベントＩＤ＝１００３」が存在する場合には、仮想サーバＡではアプリＡの機能Ａ１が利用されていると特定する。この場合、特定部２０は、機能利用状況ＤＢ１６における各実行回数をインクリメントし、機能利用中を○に設定する。
【００５２】
また、特定部２０は、パッチの適用プログラムが実行された場合に、パッチがアクセスするリソースの情報を特定して、パッチアクセスリソースＤＢ１７に格納する処理部である。例えば、特定部２０は、パッチ公開サーバ１から公開されたパッチを取得する。そして、特定部２０は、取得した公開パッチをクローンマスター３０に実行し、当該公開パッチがアクセスしたリソースを取得して、パッチアクセスリソースＤＢ１７に格納する。一例を挙げると、特定部２０は、クローンマスター３０上で実行された公開パッチであるパッチＡ１がファイル「C:\aplA\bin\a1.dll」を修正した場合、パッチアクセスリソースＤＢ１７におけるパッチＡ１のファイルに「C:\aplA\bin\a1.dll」を格納する。
【００５３】
収集部２１は、各仮想サーバ５０からイベントログやログファイルを収集する処理部である。例えば、収集部２１は、各仮想サーバ５０から、定期的にイベントログを収集して機能ログＤＢ１５に格納する。また、収集部２１は、各仮想サーバ５０から、機能定義ＤＢ１３に記憶される各出力ログファイルを取得して機能ログＤＢ１５に格納する。
【００５４】
一例を挙げると、収集部２１は、アプリＢの機能Ｂが出力する出力ログファイル「C:\aplB\log\*」が仮想サーバＡに存在するか否かを仮想サーバＡにアクセスして判定する。そして、収集部２１は、仮想サーバＡに出力ログファイル「C:\aplB\log\*」が存在する場合、出力ログファイル「C:\aplB\log\*」を取得する。その後、収集部２１は、収集先が仮想サーバＡであることを特定できる識別子と、取得した出力ログファイル「C:\aplB\log\*」とを対応付けて、機能ログＤＢ１５に格納する。
【００５５】
判定部２２は、パッチの適用対象のサーバで実行される機能が使用するリソースの情報と、パッチがアクセスするリソースの情報とに基づいて、パッチの適用可否を判定する処理部である。具体的には、判定部２２は、機能使用リソースＤＢ１４と、機能利用状況ＤＢ１６と、パッチアクセスリソースＤＢ１７とに基づいて、パッチ照合結果ＤＢ１８の詳細テーブルを生成する。そして、判定部２２は、詳細テーブルとパッチ適用判定のポリシーに基づいて、パッチ照合結果ＤＢ１８の判定結果を生成する。図１０は、パッチ適用判定ポリシーの例を示す図である。図１０に示すポリシーはあくまで一例であり、任意に設定変更することができる。
【００５６】
図１０に示すように、ミドルウェアやアプリケーションについては、パッチがアクセスする修正対象リソースにアクセスしている機能が存在する場合には、管理者判断と判定される。また、ミドルウェアやアプリケーションについては、パッチがアクセスする修正対象リソースにアクセスしている機能が存在しない場合には、適用不要と判定される。同様に、ＯＳについては、パッチがアクセスする修正対象リソースにアクセスしているミドルウェアやアプリケーションの機能が存在する場合には、管理者判断と判定される。また、ＯＳについて、ＯＳについては、パッチがアクセスする修正対象リソースにアクセスしているミドルウェアやアプリケーションの機能が存在しない、かつ、パッチ種別が予めしている指定する種別である場合には、適用必要と判定する。なお、パッチの種別は、「重要」などであり、ＯＳごとのパッチ種別にあわせてポリシーを用意する。
【００５７】
ここで、パッチ種別が「ＯＳ」であるパッチＯ２を仮想サーバＡに適用するか否かを判定する例を説明する。判定部２２は、図７に示すパッチアクセスリソースＤＢ１７を参照し、パッチＯ２がアクセスするファイル「C:\WINDOWS\system32\w3.dll」及び「C:\WINDOWS\system32\other2.dll」と、レジストリ「HKLM\SYSTEM\XXX\o2」とを特定する。続いて、判定部２２は、図４に示した機能使用リソースＤＢ１４を参照し、パッチＯ２がアクセスするファイルまたはリソースと一致するファイルまたはリソースが設定される機能を特定する。ここでは、判定部２２は、ファイル「C:\WINDOWS\system32\w3.dll」にアクセスするアプリＢの機能Ｂ１を特定する。さらに、判定部２２は、図６に示した機能利用状況ＤＢ１６を参照し、特定したアプリＢの機能Ｂ１の機能利用中が○であることを特定する。
【００５８】
その後、判定部２２は、図６に示した機能利用状況ＤＢ１６からソフトウェア名、機能、機能利用中を抽出してパッチ照合結果ＤＢ１８に格納する。さらに、判定部２２は、アプリＢの機能Ｂ１については、「パッチの更新リソースと利用中機能のリソースに共通のものがある」に「○」を設定し、「使用しているファイル名」に「C:\WINDOWS\system32\w3.dll」を設定する。
【００５９】
そして、判定部２２は、「パッチの更新リソースと利用中機能のリソースに共通のものがある」に「○」が設定されたアプリＢの機能Ｂ１の「機能利用中」に「○」が設定されていることから、「リソース使用フラグ」を「ＯＮ」に設定する。さらに、判定部２２は、図１０に示すポリシーを参照し、パッチ種別が「ＯＳ」で条件が「パッチがアクセスする修正対象リソースにアクセスしているミドルウェアやアプリケーションの機能が存在する」に一致する判定「管理者判断」を特定する。そして、判定部２２は、パッチ照合結果ＤＢ１８の判定結果に「管理者判断」を設定する。このようにすることで、判定部２２は、仮想サーバＡへのパッチＯ２の適用を管理者の判断に委ねると決定する。
【００６０】
図２に戻り、表示制御部２３は、判定部２２によるパッチ照合結果を表示部１２に表示させる処理部である。具体的には、表示制御部２３は、パッチ照合結果１８に記憶される、仮想サーバ５０ごとのパッチ判定結果を表示部１２に表示させる。図１１は、表示部に表示される表示例を示す図である。図１１に示すように、表示制御部２３は、仮想サーバ５０ごとに、「パッチ、パッチ種別、判定」を対応付けて表示する。
【００６１】
ここで表示される「パッチ」は、パッチ照合結果ＤＢ１８に記憶されるパッチの名称が設定され、「パッチ種別」は、パッチ照合結果ＤＢ１８に記憶されるパッチの種別が設定される。「判定」は、パッチ照合結果ＤＢ１８にパッチごと記憶される「判定結果」の内容が設定される。図１１の場合、ミドルウェアのパッチであるパッチＣ１、ミドルウェアのパッチであるパッチＤ１、ＯＳのセキュリティパッチであるパッチＯ１、ＯＳの重要パッチであるパッチＯ２が管理者判断と判定されていることを示している。
【００６２】
また、表示制御部２３は、表示部１２に表示される情報がユーザにより選択された場合に、詳細情報を表示することもできる。例えば、表示制御部２３は、図１１に示した表示例のうち「パッチＣ１」が選択された場合、選択された「パッチＣ１」に対応する詳細テーブルをパッチ照合結果ＤＢ１８から取得して表示部１２に表示する。
【００６３】
（クローンマスターの構成）
図２に示すように、クローンマスター３０は、通信制御インタフェース部３１、機能定義ＤＢ３２、機能定義部３３、ログ収集部３４、機能リソース特定部３５、パッチリソース特定部３６を有する。なお、機能定義ＤＢ３２は、メモリやハードディスクなどの記憶装置に記憶される。各処理部は、ＣＰＵなどによって実行される。
【００６４】
通信制御インタフェース部３１は、他のサーバとの間の通信を制御する処理部である。例えば、通信制御インタフェース部３１は、管理サーバ１０に機能定義結果やパッチの実行結果等を送信し、管理サーバ１０からパッチの実行指示を受信する。
【００６５】
機能定義ＤＢ３２は、クローンマスター３０にインストールされている利用可能な機能についての定義を記憶する記憶部である。つまり、機能定義ＤＢ３２に記憶される情報が管理サーバ１０に送信されて、機能定義ＤＢ１３に格納される。したがって、機能定義ＤＢ３２に記憶される情報は、機能定義ＤＢ１３に記憶される情報と同一なので、詳細な説明は省略する。
【００６６】
機能定義部３３は、管理サーバ１０からの指示等によって、クローンマスター３０で実行可能な機能についての定義を実行する処理部である。具体的には、機能定義部３３は、管理者等の指示操作を受け付けて、クローンマスター３０上のソフトウェアで実行可能な機能を洗い出し、各機能について図３に示した各項目を定義する。そして、機能定義部３３は、定義した結果を機能定義ＤＢ３２に格納する。また、機能定義部３３は、管理サーバ１０からの指示等によって、機能定義ＤＢ３２に記憶される情報を管理サーバ１０に送信する。
【００６７】
ログ収集部３４は、クローンマスター３０で出力されるイベントログやログファイルを収集する処理部である。このログ収集部３４は、クローンマスター３０から配備される各仮想サーバ５０に設定する機能なので、クローンマスター３０上では実行されていなくてもよい。
【００６８】
機能リソース特定部３５は、クローンマスター３０上で実行される各機能が使用するリソースの情報を特定する処理部である。具体的には、機能リソース特定部３５は、管理サーバ１０からの指示操作によって、クローンマスター３０上の各ソフトウェアの各機能を実行して、各機能が使用するリソースを特定し、その結果を管理サーバ１０に送信する。例えば、機能リソース特定部３５は、各ソフトウェアの各機能を実行し、各機能を監視する。そして、機能リソース特定部３５は、各機能が使用するファイル名、レジストリ名、サービス名を特定する。
【００６９】
パッチリソース特定部３６は、公開されたパッチをクローンマスター３０上で実行して、各パッチがアクセスするリソースを特定する処理部である。具体的には、パッチリソース特定部３６は、管理サーバ１０から公開されたパッチを取得し、管理サーバ１０からの指示操作によって、各パッチの適用プログラムをクローンマスター３０上で実行する。そして、パッチリソース特定部３６は、各パッチがアクセスするリソースを特定して管理サーバ１０に送信する。例えば、パッチリソース特定部３６は、各パッチの適用プログラムを実行し、各パッチの挙動を監視する。そして、パッチリソース特定部３６は、各パッチがアクセスするファイル名、レジストリ名、サービス名を特定する。
【００７０】
（仮想サーバの構成）
次に、仮想サーバＡから仮想サーバＤの構成を説明するが、各仮想サーバは同様の構成を有するので、ここでは、仮想サーバ５０として説明する。なお、各仮想サーバは同様の構成を有するが、実行されている機能は必ずしも一致しない。
【００７１】
図２に示すように、仮想サーバ５０は、クローンマスター３０を複製元として配備された仮想的なサーバであることから、クローンマスター３０と同様の構成を有する。すなわち、仮想サーバ５０は、通信制御インタフェース部５１、機能定義ＤＢ５２、機能定義部５３、ログ収集部５４、機能リソース特定部５５、パッチリソース特定部５６を有する。なお、機能定義ＤＢ５２は、メモリやハードディスクなどの記憶装置に記憶される。各処理部は、ＣＰＵなどによって実行される。
【００７２】
このうち、機能定義ＤＢ５２、機能定義部５３、機能リソース特定部５５、パッチリソース特定部５６については、クローンマスター３０が有することから、仮想サーバ５０に配備されるものである。したがって、仮想サーバ５０は、これらを有していなくてもよいので、これらについては詳細な説明は省略する。
【００７３】
通信制御インタフェース部５１は、他のサーバとの間の通信を制御する処理部である。例えば、通信制御インタフェース部５１は、管理サーバ１０からログ取得要求を受信し、管理サーバ１０にログを送信する。
【００７４】
ログ収集部５４は、仮想サーバ５０で出力されるイベントログやログファイルを収集する処理部である。具体的には、ログ収集部５４は、定期的にイベントログやログファイルを収集して管理サーバ１０に送信してもよく、管理サーバ１０から要求があった場合に収集して送信してもよい。
【００７５】
例えば、ログ収集部５４は、仮想サーバ５０のイベントログを定期的にエクスポートして管理サーバ１０に送信する。また、ログ収集部５４は、機能定義ＤＢ５２に記憶される各出力ログファイル、または、管理サーバ１０から指定された出力ログファイルを仮想サーバ５０取得して、管理サーバ１０に送信する。
【００７６】
［処理の流れ］
次に、図１２から図１７を用いて、図１に示したシステムで実行される各処理について説明する。なお、各仮想サーバは同様の処理を実行するので、仮想サーバが実行する処理については仮想サーバ５０として説明する。
【００７７】
（機能定義処理）
図１２は、機能定義処理の流れを示すフローチャートである。この処理は、ソフトウェアごとにクローンマスター３０が実行する。なお、処理開始のタイミングとしては、定期的に実行してもよく、管理サーバ１０からの指示操作によって実行してもよい。また、この処理は、管理者の指定を受け付けて実行される。この図１２の処理を実行することで、機能定義ＤＢ１３や機能定義ＤＢ３２に格納される情報が生成される。
【００７８】
図１２に示すように、クローンマスター３０の機能定義部３３は、クローンマスター３０上のソフトウェアで実行可能な機能をすべて洗い出す（Ｓ１０１）。続いて、機能定義部３３は、洗い出した機能から１つの機能を選択する（Ｓ１０２）。ここで選択されたソフトウェアの機能は、図３に示した「ソフトウェア名」と「機能」に該当する。
【００７９】
続いて、機能定義部３３は、選択した機能のトリガー実行プログラムの指定を受け付ける（Ｓ１０３）。ここで受け付けたトリガー実行プログラムは、図３に示した「機能トリガー実行プログラム」に該当する。また、ここでは、複数のプログラム名を受け付けてもよい。
【００８０】
そして、機能定義部３３は、選択した機能が提供するサービスの指定を受け付ける（Ｓ１０４）。ここで受け付けたサービスは、図３に示した「サービス」に該当する。また、機能がサービスを提供しない場合には、本ステップでは何も格納されない。
【００８１】
続いて、機能定義部３３は、選択した機能が出力ログの種類の指定を受け付ける（Ｓ１０５）。ここで受け付けた出力ログの種類は、図３に示した「ログタイプ」に該当する。
【００８２】
そして、機能定義部３３は、指定されたログの種類がイベントログである場合（Ｓ１０６：イベントログ）、機能またはサービスの開始を示すイベントＩＤと、機能またはサービスの終了を示すイベントＩＤとの指定を受け付ける（Ｓ１０７とＳ１０８）。ここで受け付けたイベントＩＤは、それぞれ図３に示した「開始イベントＩＤ」と「終了イベントＩＤ」に該当する。
【００８３】
一方、機能定義部３３は、指定されたログの種類がテキストファイルである場合（Ｓ１０６：テキストファイル）、機能の実行を判定できるログファイル名の指定を受け付ける（Ｓ１０９）。また、機能定義部３３は、ログ上で機能の実行開始を認識するための文字列と、ログ上の機能の実行終了を認識するための文字列との指定を受け付ける（Ｓ１１０とＳ１１１）。ここで受け付けたイベントログファイル名は、図３に示した「出力ログファイル」に該当する。また、実行開始を認識するための文字列は、図３に示した「開始特定文字列」に該当し、実行終了を認識するための文字列は、図３に示した「終了特定文字列」に該当する。
【００８４】
その後、機能定義部３３は、Ｓ１０２からＳ１１１で指定された定義データを機能定義ＤＢ３２に格納する（Ｓ１１２）。そして、機能定義部３３は、該当ソフトウェアの全機能について処理が終了したか否かを判定し（Ｓ１１３）、未処理の機能が存在する場合には（Ｓ１１３：Ｎｏ）、Ｓ１０２に戻って、未処理の機能についてＳ１０２以降を実行する。
【００８５】
一方、機能定義部３３は、未処理の機能が存在しない場合には（Ｓ１１３：Ｙｅｓ）、機能定義ＤＢ１３に記憶される定義データを、管理サーバ１０に送信して（Ｓ１１４）、処理を終了する。
【００８６】
（機能使用リソース特定処理）
図１３は、機能使用リソースを特定する処理の流れを示すフローチャートである。この処理は、ソフトウェアごとにクローンマスター３０が実行する処理である。処理開始のタイミングとしては、定期的に実行してもよく、管理サーバ１０からの指示操作によって実行してもよい。この図１３の処理を実行することで、機能使用リソースＤＢ１４に情報が格納される。
【００８７】
クローンマスター３０の機能リソース特定部３５は、図３に示した機能定義ＤＢ３２から処理対象のソフトウェアに対応する機能を１つ選択する（Ｓ２０１）。ここで選択されたソフトウェアと機能とは、図４に示す「ソフトウェア名」と「機能」とに該当する。
【００８８】
続いて、機能リソース特定部３５は、図３に示した機能定義ＤＢ３２から、Ｓ２０１で選択した機能の機能トリガー実行プログラムを１つ選択して起動し（Ｓ２０２とＳ２０３）、ＡＰＩ（Application  Programming  Interface）の監視を開始する（Ｓ２０４）。ここで選択した機能トリガー実行プログラムは、図３に示す「機能トリガー実行プログラム」に該当する。
【００８９】
その後、機能リソース特定部３５は、実行プログラムが終了するまでＡＰＩを監視し、ＡＰＩ種別によって各種記録処理を繰り返して実行する（Ｓ２０５からＳ２１０）。
【００９０】
具体的には、機能リソース特定部３５は、ライブラリのロード等が発生した場合には、ロードライブラリ記録処理を実行する（Ｓ２０６）。例えば、機能リソース特定部３５は、ロードされたライブラリ等のファイル名を取得する。ここで取得されるファイル名は、図４に示した「ファイル」に該当する。なお、実行された機能トリガー実行プログラムのファイル名は、図４に示した「ファイル」に該当する。
【００９１】
また、機能リソース特定部３５は、ファイルへのアクセスが発生した場合には、ファイルアクセス記録処理を実行する（Ｓ２０７）。例えば、機能リソース特定部３５は、参照や修正等がされたファイルのファイル名を取得する。ここで取得されるファイル名は、図４に示した「ファイル」に該当する。
【００９２】
また、機能リソース特定部３５は、レジストリへのアクセスが発生した場合には、レジストリアクセス記録処理を実行する（Ｓ２０８）。例えば、機能リソース特定部３５は、参照や修正等がされたレジストリの名称を取得する。ここで取得されるレジストリ名は、図４に示した「レジストリ」に該当する。
【００９３】
また、機能リソース特定部３５は、サービスとの通信が発生した場合には、プロセスアクセス記録処理を実行する（Ｓ２０９）。例えば、機能リソース特定部３５は、通信を行ったサービスの名称を取得する。ここで取得されるサービス名は、図４に示した「サービス」に該当する。
【００９４】
その後、ＡＰＩが終了すると、機能リソース特定部３５は、図３に示した機能定義ＤＢ３２を参照し、Ｓ２０１で選択した処理対象の機能に対応付けられる他の機能トリガー実行プログラムがあるか否かを判定する（Ｓ２１１）。
【００９５】
そして、機能リソース特定部３５は、他の機能トリガー実行プログラムがあると判定した場合（Ｓ２１１：Ｙｅｓ）、Ｓ２０２以降の処理を繰り返す。一方、機能リソース特定部３５は、他の機能トリガー実行プログラムがないと判定した場合（Ｓ２１１：Ｎｏ）、図３に示した機能定義ＤＢ３２を参照し、処理対象となっているソフトウェアに他の機能があるか否かを判定する（Ｓ２１２）。すなわち、機能リソース特定部３５は、図１２に示した処理が未処理の機能があるか否かを判定する。
【００９６】
そして、機能リソース特定部３５は、他の機能すなわち未処理の機能があると判定した場合（Ｓ２１２：Ｙｅｓ）、Ｓ２０１以降を繰り返す。一方、機能リソース特定部３５は、他の機能すなわち未処理の機能がないと判定した場合（Ｓ２１２：Ｎｏ）、Ｓ２０１からＳ２１２で取得し、各機能の使用リソース情報を管理サーバ１０に送信して（Ｓ２１３）、処理を終了する。
【００９７】
（ログ収集処理）
図１４は、ログを収集する処理の流れを示すフローチャートである。この処理は、各仮想サーバ５０が実行する処理である。処理開始のタイミングとしては、定期的に実行してもよく、管理サーバ１０からの指示操作によって実行してもよい。この図１４の処理を実行することで、機能ログＤＢ１５に情報が格納される。
【００９８】
図１４に示すように、仮想サーバ５０のログ収集部５４は、収集タイミングに到達すると（Ｓ３０１：Ｙｅｓ）、図３に示した機能定義ＤＢ５２から機能を１つ選択する（Ｓ３０２）。なお、機能定義ＤＢ５２は、予め指定されたタイミングで、クローンマスター３０の機能定義ＤＢ３２と同期されているものとする。また、仮想サーバ５０のログ収集部５４は、クローンマスター３０から機能の選択を取得してもよい。
【００９９】
そして、ログ収集部５４は、図３に示した機能定義ＤＢ５２を参照し、Ｓ３０２で選択した機能に対応するログファイルを採取する（Ｓ３０３）。このとき、ログ収集部５４は、Ｓ３０２で選択した機能に対応するログファイルがイベントログである場合には、テキストとしてエクスポートする。
【０１００】
続いて、ログ収集部５４は、採取したログファイルを管理サーバ１０に送信する（Ｓ３０４）。このとき、ログ収集部５４は、ログファイル名、採取先の仮想サーバ名、当該ログファイルにログを出力するソフトウェアと機能などをあわせて送信してもよい。
【０１０１】
その後、ログ収集部５４は、未収集の機能が他に存在すると判定した場合（Ｓ３０５：Ｙｅｓ）、Ｓ３０２以降の処理を繰り返す。一方、ログ収集部５４は、未収集の機能が他に存在しないと判定した場合（Ｓ３０５：Ｎｏ）、処理を終了する。
【０１０２】
（利用機能解析処理）
図１５は、利用機能を解析する処理の流れを示すフローチャートである。この処理は、管理サーバ１０が実行する処理である。処理開始のタイミングとしては、定期的に実行してもよく、パッチが公開された場合に実行してもよい。この図１５の処理を実行することで、機能利用状況ＤＢ１６に情報が格納される。
【０１０３】
図１５に示すように、管理サーバ１０の特定部２０は、パッチ適用対象の仮想サーバ５０を１つ選択し（Ｓ４０１）、機能定義ＤＢ１３を参照して、ソフトウェアの機能を１つ選択する（Ｓ４０２）。ここで選択されたソフトウェアの機能は、図６に示した機能利用状況ＤＢ１６の「ソフトウェア名」と「機能」とに該当する。このとき、特定部２０は、機能定義ＤＢ１３を参照して、サービス名についても特定する。
【０１０４】
続いて、特定部２０は、図３に示した機能定義ＤＢ１３を参照し、Ｓ４０２で選択した機能に対応する出力ログファイルまたはイベントログのテキストデータが、機能ログＤＢ１５に記憶されているか否かを判定する（Ｓ４０３）。
【０１０５】
そして、特定部２０は、ログファイル等が機能ログＤＢ１５に記憶されていると判定した場合（Ｓ４０３：Ｙｅｓ）、機能利用状況ＤＢ１６の「前回測定から今回までの実行回数」に、ログファイル等に開始メッセージが登場した回数を設定する（Ｓ４０４）。例えば、特定部２０は、図３に示した機能定義ＤＢ１３の「開始特定文字列」がログファイルに登場する回数を計数して、機能利用状況ＤＢ１６に設定する。また、特定部２０は、図３に示した機能定義ＤＢ１３の「開始イベントＩＤ」がイベントログのテキストファイルに登場する回数を計数して、機能利用状況ＤＢ１６に設定する。
【０１０６】
続いて、特定部２０は、機能利用状況ＤＢ１６の「過去１ヶ月間の累積実行回数」を更新する（Ｓ４０５）。例えば、特定部２０は、現時点の「過去１ヶ月間の累積実行回数」に、Ｓ４０４で計数された回数を加える。なお、特定部２０は、ログファイル等が機能ログＤＢ１５に記憶されていないと判定した場合（Ｓ４０３：Ｎｏ）、Ｓ４０４を実行することなく、Ｓ４０５を実行する。すなわち、この場合、「過去１ヶ月間の累積実行回数」は更新されない。
【０１０７】
その後、特定部２０は、更新した機能利用状況ＤＢ１６の「前回測定から今回までの実行回数」が１以上であるか否かを判定する（Ｓ４０６）。そして、特定部２０は「前回測定から今回までの実行回数」が１以上であると判定した場合（Ｓ４０６：Ｙｅｓ）、機能は仮想サーバ５０で利用されていると判定する（Ｓ４０７）。すなわち、特定部２０は、図６に示した機能利用状況ＤＢ１６において、Ｓ４０２で選択した機能に対応する「機能利用中」に「○」を設定する。
【０１０８】
一方、特定部２０は、「前回測定から今回までの実行回数」が１以上ではないと判定した場合（Ｓ４０６：Ｎｏ）、機能利用状況ＤＢ１６または機能定義ＤＢ１３を参照し、機能の種類がサービスであるか否かを判定する（Ｓ４０８）。つまり、特定部２０は、機能利用状況ＤＢ１６または機能定義ＤＢ１３を参照し、選択中の機能にサービスが対応付けられているか否かを判定する。
【０１０９】
そして、特定部２０は、機能の種類がサービスであると判定した場合（Ｓ４０８：Ｙｅｓ）、Ｓ４０９の判定を実行する。すなわち、特定部２０は、「過去１ヶ月間の累積実行回数」が事前に設定した回数以上、または、以前の最終出力が開始特定文字列（開始イベントＩＤ）で終了しているか否かを判定する。
【０１１０】
その後、特定部２０は、Ｓ４０９の条件に該当すると判定した場合（Ｓ４０９：Ｙｅｓ）、機能は仮想サーバ５０で利用されていると判定する（Ｓ４０７）。一方、特定部２０は、Ｓ４０９の条件に該当しないと判定した場合（Ｓ４０９：Ｎｏ）、機能は仮想サーバ５０で利用されていないと判定する（Ｓ４１０）。この場合、特定部２０は、図６に示した機能利用状況ＤＢ１６において、Ｓ４０２で選択した機能に対応する「機能利用中」に「×」を設定する。
【０１１１】
また、Ｓ４０８において、特定部２０は、機能の種類がサービスでないと判定した場合（Ｓ４０８：Ｎｏ）、機能は仮想サーバ５０で利用されていないと判定する（Ｓ４１０）。すなわち、特定部２０は、図６に示した機能利用状況ＤＢ１６において、Ｓ４０２で選択した機能に対応する「機能利用中」に「×」を設定する。
【０１１２】
その後、特定部２０は、選択されている仮想サーバ５０において他の機能がある場合、すなわち、未処理の機能が残っている場合（Ｓ４１１：Ｙｅｓ）、Ｓ４０２以降を繰り返す。一方、特定部２０は、選択されている仮想サーバ５０において他の機能がない場合、すなわち、未処理の機能が残っていない場合（Ｓ４１１：Ｎｏ）、他の仮想サーバ５０があるか否かを判定する（Ｓ４１２）。
【０１１３】
そして、特定部２０は、他の仮想サーバ５０がある場合、すなわち、未処理の仮想サーバ５０が残っている場合（Ｓ４１２：Ｙｅｓ）、Ｓ４０１以降を繰り返す。一方、特定部２０は、他の仮想サーバ５０がない場合、すなわち、未処理の仮想サーバ５０が残っていない場合（Ｓ４１２：Ｎｏ）、処理を終了する。
【０１１４】
（パッチアクセス特定処理）
図１６は、パッチがアクセスするリソースを特定する処理の流れを示すフローチャートである。この処理は、管理サーバ１０がクローンマスター３０上で実行する処理である。処理開始のタイミングとしては、管理者の指示操作を受け付けた場合でもよく、パッチが公開された場合でもよい。この図１６の処理を実行することで、パッチアクセスリソースＤＢ１７に情報が格納される。
【０１１５】
図１６に示すように、管理サーバ１０の特定部２０は、パッチ公開サーバ１から公開されたパッチを取得し、公開された順番で１つの公開パッチを選択する（Ｓ５０１）。ここで選択される公開パッチの名称が、図７に示したパッチアクセスリソースＤＢ１７の「パッチ」に該当する。同様に、選択された公開パッチの種別が、図７に示したパッチアクセスリソースＤＢ１７の「パッチ種別」に該当する。同様に、選択された公開パッチの重要度が、図７に示したパッチアクセスリソースＤＢ１７の「パッチ重要度」に該当する。
【０１１６】
そして、管理サーバ１０の特定部２０は、選択した公開パッチの適用プログラムをクローンマスター３０に起動させる（Ｓ５０２）。すなわち、管理サーバ１０の特定部２０が公開パッチをクローンマスター３０に格納し、クローンマスター３０のパッチリソース特定部３６は、当該公開パッチの適用プログラムを実行する。
【０１１７】
その後、クローンマスター３０のパッチリソース特定部３６は、公開パッチを実行した後、公開パッチが終了するまでＡＰＩを監視し、ＡＰＩ種別によって各種記録処理を繰り返して実行する（Ｓ５０３からＳ５０８）。
【０１１８】
具体的には、パッチリソース特定部３６は、ファイルへのアクセスが発生した場合には、ファイルアクセス記録処理を実行する（Ｓ５０５）。例えば、パッチリソース特定部３６は、参照や修正等がされたファイルのファイル名を取得する。ここで取得されるファイル名は、図７に示した「ファイル」に該当する。
【０１１９】
また、パッチリソース特定部３６は、レジストリへのアクセスが発生した場合には、レジストリアクセス記録処理を実行する（Ｓ５０６）。例えば、パッチリソース特定部３６は、参照や修正等がされたレジストリの名称を取得する。ここで取得されるレジストリ名は、図７に示した「レジストリ」に該当する。
【０１２０】
また、パッチリソース特定部３６は、サービスの起動や停止が発生した場合には、プロセスアクセス記録処理を実行する（Ｓ５０７）。例えば、パッチリソース特定部３６は、起動や停止がされたサービスの名称を取得する。ここで取得されるレジストリ名は、図７に示した「サービス」に該当する。
【０１２１】
その後、ＡＰＩが終了すると、パッチリソース特定部３６は、公開されたパッチ全てについて処理が終了したか否かを判定する（Ｓ５０９）。具体的には、パッチリソース特定部３６は、管理サーバ１０の特定部２０に、公開されたパッチ全てについて処理が終了したか否かを問い合わせる。
【０１２２】
そして、未処理の公開パッチが存在する場合（Ｓ５０９：Ｎｏ）、Ｓ５０１以降の処理を実行される。一方、未処理の公開パッチが存在しない場合（Ｓ５０９：Ｙｅｓ）、パッチリソース特定部３６は、Ｓ５０１からＳ５０９で特定された各公開パッチがアクセスするリソースの情報を管理サーバ１０に送信する（Ｓ５１０）。
【０１２３】
（パッチ適用判定処理）
図１７は、パッチ適用の可否を判定する処理の流れを示すフローチャートである。この処理は、管理サーバ１０が実行する処理である。処理開始のタイミングとしては、定期的に実行してもよく、パッチアクセスリソースＤＢ１７が更新された場合に実行してもよい。この図１７の処理を実行することで、パッチ照合結果ＤＢ１８に情報が格納される。
【０１２４】
図１７に示すように、管理サーバ１０の判定部２２は、仮想サーバ５０を１つ選択し（Ｓ６０１）、公開パッチを１つ選択する（Ｓ６０２）。ここで選択される公開パッチの名称ごとに図８に示した照合結果が生成される。
【０１２５】
続いて、判定部２２は、初期値として、リソース使用フラグをＯＦＦに設定する（Ｓ６０３）。そして、判定部２２は、図６に示した仮想サーバ５０ごとの機能利用状況ＤＢ１６から機能を１つ選択する（Ｓ６０４）。ここで選択されるソフトウェアの機能が、図８に示したパッチ照合結果ＤＢ１８の「ソフトウェア名」と「機能」に該当する。
【０１２６】
そして、判定部２２は、選択した機能が利用されているか否かを判定する（Ｓ６０５）。具体的には、判定部２２は、図６に示した仮想サーバ５０ごとの機能利用状況ＤＢ１６を参照し、選択した機能に対応する「機能利用中」が「○」であれば、利用されていると判定する。
【０１２７】
続いて、判定部２２は、選択した機能が利用されていると判定した場合（Ｓ６０５：Ｙｅｓ）、選択した機能が使用するリソースと公開パッチがアクセスするリソースとで同じものがあるか否かを判定する（Ｓ６０６）。具体的には、判定部２２は、図４に示した機能使用リソースＤＢ１４を参照して、選択した機能が使用するファイル名、レジストリ名、サービス名を特定する。また、判定部２２は、図７に示したパッチアクセスリソースＤＢ１７を参照して、対象のパッチがアクセスするファイル名、レジストリ名、サービス名を特定する。そして、判定部２２は、特定した両方のファイル名、レジストリ名、サービス名各々を比較し、一致するものがあるか否かを判定する。
【０１２８】
続いて、判定部２２は、選択した機能が使用するリソースと公開パッチがアクセスするリソースとで同じものがあると判定した場合（Ｓ６０６：Ｙｅｓ）、当該パッチの照合結果における「リソース使用フラグ」を「ＯＮ」に設定する（Ｓ６０７）。なお、ここで一致すると判定されたファイル名、レジストリ名、サービス名が、図８に示したパッチ照合結果のファイル名、レジストリ名、サービス名に該当する。
【０１２９】
一方、判定部２２は、選択した機能が利用されていないと判定した場合（Ｓ６０５：Ｎｏ）、「リソース使用フラグ」を「ＯＦＦ」のままにして、Ｓ６０８が実行される。また、判定部２２は、選択した機能が使用するリソースと公開パッチがアクセスするリソースとで同じものがないと判定した場合（Ｓ６０６：ＮＯ）、「リソース使用フラグ」を「ＯＦＦ」のままにする。
【０１３０】
その後、判定部２２は、図６に示した仮想サーバ５０ごとの機能利用状況ＤＢ１６に、未処理の機能がある場合（Ｓ６０８：Ｙｅｓ）、Ｓ６０４以降の処理を繰り返す。
【０１３１】
そして、判定部２２は、未処理の機能がない場合（Ｓ６０８：Ｎｏ）、図７に示したパッチアクセスリソースＤＢ１７を参照し、現在選択中の公開パッチの種別を判定する（Ｓ６０９）。
【０１３２】
判定部２２は、現在選択中の公開パッチの種別が「ＯＳ」である場合（Ｓ６０９：ＯＳパッチ）、現時点でのリソース使用フラグがＯＮであるかＯＦＦであるかを判定する（Ｓ６１０）。そして、判定部２２は、現時点でのリソース使用フラグがＯＦＦであると判定した場合（Ｓ６１０：ＯＦＦ）、図７に示したパッチアクセスリソースＤＢ１７を参照し、選択中のパッチの重要度を特定する（Ｓ６１１）。
【０１３３】
図１７に示した例では、パッチの重要度が「推奨」、「重要」、「セキュリティ」のいずれであっても、判定部２２は、「適用必要」と判定する（Ｓ６１２から６１４）。ここで判定された結果が、図８に示したパッチ照合結果ＤＢ１８の「判定結果」に該当する。
【０１３４】
一方、判定部２２は、現時点でのリソース使用フラグがＯＮであると判定した場合（Ｓ６１０：ＯＮ）、「管理者による適用判断」と判定する（Ｓ６１５）。ここで判定された結果が、図８に示したパッチ照合結果ＤＢ１８の「判定結果」に該当する。
【０１３５】
また、Ｓ６０９において、判定部２２は、現在選択中の公開パッチの種別が「アプリケーション」または「ミドルウェア」である場合（Ｓ６０９）、現時点でのリソース使用フラグがＯＮであるかＯＦＦであるかを判定する（Ｓ６１６）。
【０１３６】
そして、判定部２２は、現時点でのリソース使用フラグがＯＦＦであると判定した場合（Ｓ６１６：ＯＦＦ）、「適用不要」と判定する（Ｓ６１７）。ここで判定された結果が、図８に示したパッチ照合結果ＤＢ１８の「判定結果」に該当する。
【０１３７】
一方、判定部２２は、現時点でのリソース使用フラグがＯＮであると判定した場合（Ｓ６１６：ＯＮ）、「管理者による適用判断」と判定する（Ｓ６１８）。ここで判定された結果が、図８に示したパッチ照合結果ＤＢ１８の「判定結果」に該当する。
【０１３８】
その後、判定部２２は、Ｓ６０１からＳ６１８で判定した、仮想サーバ５０におけるパッチの適用可否の判定結果を、パッチ照合結果ＤＢ１８に格納する（Ｓ６１９）。そして、判定部２２は、未処理の公開パッチがある場合には（Ｓ６２０：Ｙｅｓ）、Ｓ６０２以降の処理を繰り返す。また、判定部２２は、未処理の公開パッチがなく（Ｓ６２０：Ｎｏ）、未処理の仮想サーバ５０がある場合には（Ｓ６２１：Ｙｅｓ）、Ｓ６０１以降の処理を繰り返す。
【０１３９】
一方、判定部２２は、未処理の仮想サーバ５０がない場合には（Ｓ６２１：Ｎｏ）、サーバ管理者に判定結果を表示する（Ｓ６２２）。すなわち、判定部２２による判定が終了すると、表示制御部２３は、パッチ照合結果ＤＢ１８に記憶される情報を表示部１２に表示させる。
【０１４０】
上述した各処理によって、業務で利用されている機能を修正対象とするパッチを抽出するだけでなく、パッチが修正対象とする機能を利用する他のソフトウェア、ミドルウェア、アプリケーションに与える影響の有無まで特定することができる。また、実際の運用では、本番の運用環境に適用する前に、テスト環境にすべてのパッチを１度に適用して、検証する。この時に不具合が発生しても、各パッチが影響を与える機能が分かるため、調査の範囲を特定することができる。
【０１４１】
また、パッチ適用対象のサーバにインストールされているＯＳやソフトウェアのソースコードや構成するモジュールがわからなくても、公開パッチを適用することによる業務への影響を特定できる。また、運用中の仮想サーバ５０上で、使用リソースを監視するためのプログラムを常駐させておくなど、仮想サーバ５０に負荷がかかるような方法をとることなく、パッチの適用性が判定できる。
【実施例２】
【０１４２】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【０１４３】
（物理サーバへの適用）
実施例１では、仮想サーバ５０にパッチを適用する場合を例にして説明したが、これに限定されるものではなく、物理サーバに対しても同様に処理することができる。また、パッチのアクセスするリソースを特定する処理や機能が使用するリソースを特定する処理などのように、クローンマスター３０で実行される処理は、テスト環境に構築されたテスト機等で実行してもよい。
【０１４４】
（リソースの特定）
実施例１では、機能が使用するリソース情報やパッチがアクセスするリソース情報を、クローンマスター３０を用いて特定する例を説明したが、これに限定されるものではない。例えば、プログラム設計等によって予めわかっている場合には、その情報を用いることもできる。また、一度、機能が使用するリソース情報を特定した後は、機能変更があるまで、機能が使用するリソース情報を特定する処理を省略することもできる。
【０１４５】
（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１４６】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１４７】
（ハードウェア）
図１８は、コンピュータのハードウェア構成例を示す図である。ここで示したハードウェア構成は、図１に示した各装置に該当する。図１８に示すように、コンピュータ１００は、ＣＰＵ１０１、メモリ１０２、媒体読取装置１０３、ＨＤＤ（Hard  Disk  Drive）１０４、通信制御部１０５、キーボード１０６、ディスプレイ１０７を有する。また、図１８に示した各部は、バスで相互に接続される。
【０１４８】
キーボード１０６は、入力装置であり、ディスプレイ１０７は、出力装置などであり、通信制御部１０５は、ＮＩＣ（Network  Interface  Card）などのインタフェースである。ＨＤＤ１０４は、図２等に示した機能を実行するプログラムや図２に示した各ＤＢを記憶する。記録媒体の例としてＨＤＤ１０４を例に挙げたが、ＲＯＭ（Read  Only  Memory）、ＲＡＭ、ＣＤ−ＲＯＭ等の他のコンピュータが読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記録媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。
【０１４９】
ＣＰＵ１０１は、図２に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１０４等から読み出してメモリ１０２に展開することで、図２等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、コンピュータ１００が管理サーバ１０である場合には、管理サーバ１０が有する各処理と同様の機能を実行する。また、このプロセスは、コンピュータ１００がクローンマスター３０である場合には、クローンマスター３０が有する各処理と同様の機能を実行する。また、このプロセスは、コンピュータ１００が仮想サーバ５０ある場合には、仮想サーバ５０が有する各処理と同様の機能を実行する。このようにコンピュータ１００は、プログラムを読み出して実行することでパッチ判定方法を実行する情報処理装置として動作する。
【０１５０】
また、コンピュータ１００は、媒体読取装置１０３によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【０１５１】
以上の各実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１５２】
（付記１）コンピュータに、
パッチの適用対象の情報処理装置で実行される機能が使用する第１のリソース情報を取得し、
前記パッチが実行された場合に、前記パッチがアクセスする第２のリソース情報を取得し、
取得した第１のリソース情報と第２のリソース情報とに基づいて、前記パッチの適用可否を判定する、
処理を実行させることを特徴とするパッチ判定プログラム。
【０１５３】
（付記２）前記パッチの適用対象の情報処理装置で実行可能な各機能を他の情報処理装置で実行して、各機能がアクセスしたリソースの情報を特定し、
前記パッチの適用対象の情報処理装置上の機能が出力したログを収集する、各処理をさらにコンピュータに実行させ、
前記第１のリソース情報を取得する処理は、収集したログから前記パッチの適用対象の情報処理装置で動作している機能を抽出し、抽出した機能が使用するリソースの情報を、各機能がアクセスしたリソースの情報から取得することを特徴とする付記１に記載のパッチ判定プログラム。
【０１５４】
（付記３）前記判定する処理は、前記第１のリソース情報と、前記第２のリソース情報とに基づいて、前記パッチがアクセスするリソースを前記情報処理装置で実行される機能が使用する場合に、前記パッチの適用可否を管理者に問い合わせることを特徴とする付記１または２に記載のパッチ判定プログラム。
【０１５５】
（付記４）前記判定したパッチの適用可否の判定結果を、所定の表示部に表示させる処理をさらにコンピュータに実行させることを特徴とする付記１から３のいずれか一つに記載のパッチ判定プログラム。
【０１５６】
（付記５）前記表示させる処理は、前記所定の表示部に表示される前記パッチの適用可否の判定結果が選択された場合、前記第１のリソース情報と前記第２のリソース情報とに基づいて、前記パッチがアクセスするリソースを前記所定の表示部に表示させることを特徴とする付記４に記載のパッチ判定プログラム。
【０１５７】
（付記６）コンピュータが、
パッチの適用対象の情報処理装置で実行される機能が使用する第１のリソース情報を取得し、
前記パッチが実行された場合に、前記パッチがアクセスする第２のリソース情報を取得し、
取得した第１のリソース情報と第２のリソース情報とに基づいて、前記パッチの適用可否を判定する、
処理を実行することを特徴とするパッチ判定方法。
【０１５８】
（付記７）パッチの適用対象の情報処理装置で実行される機能が使用する第１のリソース情報を取得する第１取得部と、
前記パッチが実行された場合に、前記パッチがアクセスする第２のリソース情報を取得する第２取得部と、
前記第１取得部によって取得された第１のリソース情報と、前記第２取得部によって取得された第２のリソース情報とに基づいて、前記パッチの適用可否を判定する判定部と
を有することを特徴とする情報処理装置。
【０１５９】
（付記８）メモリと
前記メモリに接続されるプロセッサと、を有し、
前記プロセッサが、
パッチの適用対象の情報処理装置で実行される機能が使用する第１のリソース情報を取得し、
前記パッチが実行された場合に、前記パッチがアクセスする第２のリソース情報を取得し、
取得した第１のリソース情報と第２のリソース情報とに基づいて、前記パッチの適用可否を判定する
処理を実行することを特徴とする情報処理装置。
【０１６０】
（付記９）パッチの適用対象の情報処理装置で実行される機能が使用する第１のリソース情報を取得し、
前記パッチが実行された場合に、前記パッチがアクセスする第２のリソース情報を取得し、
取得した第１のリソース情報と第２のリソース情報とに基づいて、前記パッチの適用可否を判定する、
処理をコンピュータに実行させるパッチ判定プログラムを記憶する、コンピュータ読み取り可能な記憶媒体。
【符号の説明】
【０１６１】
１  パッチ公開サーバ
２  公衆回線網
１０  管理サーバ
１１  通信制御インタフェース部
１２  表示部
１３  機能定義ＤＢ
１４  機能使用リソースＤＢ
１５  機能ログＤＢ
１６  機能利用状況ＤＢ
１７  パッチアクセスリソースＤＢ
１８  パッチ照合結果ＤＢ
１９  取得部
２０  特定部
２１  収集部
２２  判定部
２３  表示制御部
３０  クローンマスター
３１、５１  通信制御インタフェース部
３２、５２  機能定義ＤＢ
３３、５３  機能定義部
３４、５４  ログ収集部
３５、５５  機能リソース特定部
３６、５６  パッチリソース特定部
４０  ＶＭホスト
５０  仮想サーバ
【図１】
2014013457.tif 000003
【図２】
2014013457.tif 000004
【図３】
2014013457.tif 000005
【図４】
2014013457.tif 000006
【図５】
2014013457.tif 000007
【図６】
2014013457.tif 000008
【図７】
2014013457.tif 000009
【図８】
2014013457.tif 000010
【図９】
2014013457.tif 000011
【図１０】
2014013457.tif 000012
【図１１】
2014013457.tif 000013
【図１２】
2014013457.tif 000014
【図１３】
2014013457.tif 000015
【図１４】
2014013457.tif 000016
【図１５】
2014013457.tif 000017
【図１６】
2014013457.tif 000018
【図１７】
2014013457.tif 000019
【図１８】
2014013457.tif 000020