複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持する保持部と、検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信する受信部と、前記受信部によって受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する応答部とを有することを特徴とする検証装置。前記保持部に保持されるキャプチャデータに、前記検証対象の第1の情報処理装置を宛先とする送信待ちのデータが存在する場合に、当該データを前記検証対象の第1の情報処理装置に送信する送信部をさらに有することを特徴とする請求項1に記載の検証装置。前記保持部に記憶されるキャプチャデータから、前記情報処理装置に処理を要求する際に送信された要求データと、当該要求データの応答として送信された応答データとの対応関係を生成する生成部をさらに有し、前記応答部は、前記生成部によって生成された対応関係に基づいて、前記受信部によって受信されたデータの応答として前記システムで送信されたデータを特定することを特徴とする請求項1または2に記載の検証装置。前記生成部は、前記保持部に記憶されるキャプチャデータのうち、前記情報処理装置が関連する処理が1多重で実行された際に取得されたキャプチャデータから、前記要求データと応答データとの対応関係を生成することを特徴とする請求項3に記載の検証装置。前記生成部は、第1の情報処理装置と第2の情報処理装置との間における前記対応関係を生成する場合に、第3の情報処理装置が前記第1の情報処理装置または第2の情報処理の少なくとも1つの装置に送信した要求データまたは前記第3の情報処理装置が前記第1の情報処理装置または第2の情報処理装置の少なくとも1つの装置から受信した応答データとを用いて、前記第1の情報処理装置と第2の情報処理装置との間における要求データと応答データとを特定することを特徴とする請求項3に記載の検証装置。コンピュータが、複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持部に保持し、検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信し、受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する処理を実行することを特徴とする検証方法。コンピュータに、複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持部に保持し、検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信し、受信したデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する処理を実行させることを特徴とする検証プログラム。しかしながら、従来の技術では、事前検証を容易に実施することができないという問題があった。例えば、複数装置が多階層に連携して動作するシステムなどでは、事前検証するための検証用システムとして、実動機と同じ装置構成の別システムを用意するなど、検証のために準備に時間やコストがかかる。一例を挙げると、Webサーバ、DBサーバ、クライアント装置のうちWebサーバに対して事前作業を行う場合であっても、DBサーバとクライアント装置を用意し、実動環境のシステムを同じシステムを構築した上で、事前検証を実行する。このように、事前検証のために用意する装置費用もかかり、また、検証用のシステムを構築する場所や時間もかかることから、事前検証を簡単に実行できない。1つの側面では、事前検証を容易に実行できる検証装置、検証方法および検証プログラムを提供することを目的とする。第1の案では、検証装置は、複数の情報処理装置を有するシステム内で送受信されたデータをキャプチャして得られたキャプチャデータを保持する保持部を有する。検証装置は、検証対象の第1の情報処理装置から他の第2の情報処理装置へ送信されたデータを受信する受信部を有する。検証装置は、前記受信部によって受信されたデータの応答として前記システムで送信されたデータを前記保持部が保持するキャプチャデータから特定し、特定したデータを前記検証対象の第1の情報処理装置に応答する応答部を有する。事前検証を容易に実行できる。以下に、本願の開示する検証装置、検証方法および検証プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。図1は、実施例1に係るシステムの全体構成の例を示す図である。図1に示すように、このシステムは、事前検証装置10が実動環境と検証環境との各々に接続されている。実動環境は、クライアントに対してWebサービス等の各種サービスを提供するシステムである。検証環境は、実動環境で動作するサーバ等に対して、パッチやバージョンアップなどの更新作業を行う前に、更新作業後に機能面または性能面で退化がないかを検証するためのシステムである。実動環境は、実動APApplicationサーバ1aと実動DBDataBaseサーバ1bとクライアント端末1cとスイッチ1dとを有し、検証環境とは別のネットワークで形成される。実動APサーバ1aは、クライアント端末1cから要求を受信して、実動DBサーバ1bへのトランザクションを実行するサーバであり、HTML文書などを蓄積してWebサービスを提供するWebアプリケーションサーバとしての機能を有していてもよい。例えば、実動APサーバ1aは、クライアント端末1cから受信した要求に対応したアプリケーションを実行して、実動DBサーバ1bへリクエストを送信する。そして、実動APサーバ1aは、当該リクエストに対するレスポンスを実動DBサーバ1bから受信して、クライアント端末1cに送信する。実動DBサーバ1bは、データベースを有し、実動APサーバ1aから受信したリクエストに応じてデータベース等の更新を実行し、その結果をレスポンスとして実動APサーバ1aに送信する。なお、実動DBサーバ1bが有するデータベースは、関係データベース、オブジェクトデータベース、KVSキーバリューストアなど様々なデータベースを利用できる。クライアント端末1cは、Webブラウザ等を用いて実動APサーバ1aにアクセスして各サービスを利用するコンピュータであり、例えば実動APサーバ1aを介して実動DBサーバ1bが保持するデータベースを更新したりする。スイッチ1dは、実動APサーバ1a、実動DBサーバ1b、クライアント端末1cの各々とポートを介して接続し、各装置間の通信をスイッチングするデータ中継装置である。例えば、スイッチ1dとしては、スイッチングハブ、ルータ、タップなどを用いることができる。このスイッチ1dは、ポートミラーリングを実行しており、実動APサーバ1a、実動DBサーバ1b、クライアント端末1cの各々から受信したデータを事前検証装置10に送信する。検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして事前検証装置10に接続する環境である。検証するタイミングとしては、上述した更新後の性能等を確認する他にも、サーバの移設等様々な状況が想定される。例えば、上記実動環境を自社内で運用していたが、APサーバだけをシステムインテグレータ等が提供するクラウド環境に移行する場合も該当する。この場合、事前検証装置10は、APサーバと同様の機能を有する検証APサーバに対して検証を実行する。ここでは、一例として、実動APサーバ1aを検証することとするので、検証環境は検証APサーバ2aを有するものとする。検証APサーバ2aは、実動APサーバ1aと同様の機能を実装した検証対象のサーバであり、事前検証装置10と接続される。この検証APサーバ2aには、検証APサーバ2aが直接通信する検証対象外の装置である、実動DBサーバ1bとクライアント端末1c各々のアドレスとして、事前検証装置10のIPInternetProtocolアドレスを設定しておく。検証APサーバ2aは、実動環境の実動APサーバ1aが処理する実トランザクションと同様のトランザクションを実行して、データを事前検証装置10に送信する。また、検証APサーバ2aは、事前検証装置10からパケットを受信した場合に、当該データに対応する応答データを事前検証装置10に送信する。事前検証装置10は、保持部10aと受信部10bと応答部10cとを有し、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証APサーバ2aの動作や性能を検証するサーバである。保持部10aは、複数の装置を有する実動環境内のデータをキャプチャして得られたキャプチャデータを保持する。例えば、保持部10aは、スイッチ1dのポートミラーリングによって受信したデータを保持する。受信部10bは、検証対象である検証APサーバ2aから他の装置である実動環境の他装置へ送信されたデータを受信する。応答部10cは、受信部10bによって受信されたデータの応答として実動システムで送信されたデータを保持部10aが保持するキャプチャデータから特定し、特定したデータを検証対象の検証APサーバ2aに応答する。このように、事前検証装置10は、実動環境で使用されたトランザクションによって発生したデータや、データの送受信シーケンスを記憶することで、検証対象サーバ以外のサーバ動作を擬似的に動作することができる。したがって、事前検証を実施するのに際して、実動環境と同じ環境を用意することなく、検証対象装置だけを準備すれば事前検証を実行することができる。したがって、事前検証を容易に実行できる。次に、図1に事前検証装置の具体的な構成等を実施例2として説明する。なお、実動APサーバ1aや検証APサーバ2aは、一般的なAPサーバと同様の機能を有し、実動DBサーバ1bは、一般的なDBサーバと同様の機能を有し、クライアント端末は、一般的なコンピュータと同様の機能を有するので、詳細な説明は省略する。ここでは、事前検証装置の構成、処理の流れ、効果等について説明する。[事前検証装置の構成]図2は、実施例2に係る事前検証装置の構成を示すブロック図である。図2に示すように、事前検証装置10は、通信インタフェース11、実動キャプチャデータDB12、検証データDB13、検証結果DB14、制御部15を有する。通信インタフェース11は、少なくとも1つのポートを有し、事前検証装置10と検証APサーバ2aとの間の通信を制御する。また、通信インタフェース11は、事前検証装置10とスイッチ1dとの間の通信も制御する。この通信インタフェースの各ポートには、実動環境で使用するIPInternetProtocolアドレスと、検証対象外装置のIPアドレスが設定される。図1の場合、通信インタフェースの第1ポートには、実動環境用のIPアドレスが設定される。そして、通信インタフェースの第2ポートには、実動DBサーバ1b宛として使用されるIPアドレスが設定される。さらに、通信インタフェースの第3ポートには、クライアント端末1c宛として使用されるIPアドレスが設定される。実動キャプチャデータDB12は、複数の装置を有する実動環境内のパケットをキャプチャして得られた実キャプチャデータを保持する。すなわち、実動キャプチャデータDB12は、実動環境で実行されたトランザクションで発生したパケット情報を記憶する。実動キャプチャデータDB12には、後述するパケットキャプチャ部16によって、1日や1週間など所定間隔でキャプチャされたキャプチャデータが格納される。図3は、実施例2に係る実動キャプチャデータDBに記憶される情報の例を示す図である。図3に示すように、実動キャプチャデータDB12は、シーケンシャル番号、送信元、送信先、パケットを対応付けて記憶する。ここで記憶されるシーケンシャル番号は、パケットキャプチャリングされた順番を示し、送信元は、キャプチャされたパケットの送信元を示す。送信先は、キャプチャされたパケットの送信先を示し、パケットは、キャプチャされたパケットの情報を示す。なお、実動キャプチャデータ12は、上述した情報に対応付けて、キャプチャしたパケットそのものを保持していてもよい。図3の例の場合、1番目に、クライアント端末1cから実動APサーバ1aに送信されたHTTPReqがキャプチャされ、2番目に、実動APサーバ1aから実動DBサーバ1bに送信されたSQLReqがキャプチャされたことを示す。さらに、3番目に、実動DBサーバ1bから実動APサーバ1aに送信されたSQLResがキャプチャされたことを示し、4番目に、実動APサーバ1aからクライアント端末1cに送信されたHTTPResがキャプチャされたことを示す。なお、Reqは、Requestの略であり、Resは、Responseの略である。検証データDB13は、後述する検証実施部17が検証を実施して得られた検証データであり、検証実施部17が検証環境で送受信されるパケットをキャプチャしたデータを記憶する。ここで記憶される情報は検証実施部17によって格納される。図4は、検証データDBに記憶される情報の例を示す図である。図4に示すように、検証データDB13は、検証対象装置、シーケンシャル番号、送信パケット、受信パケットを対応付けて記憶する。ここで記憶される検証対象装置は、検証が実施された装置の名称やIPアドレスなどであり、シーケンシャル番号は、検証によってパケットが送受信された順番である。送信パケットは、検証の際に送信されたパケットの情報であり、受信パケットは、検証で受信されたパケットの情報である。図4の例の場合、APサーバに対して実行した検証では、1番目にHTTPReqが送信され、2番目にSQLReqが受信され、3番目にSQLResが送信され、4番目にHTTPResが受信されたことを示す。検証結果DB14は、後述する検証実施部17によって得られた検証結果を記憶する。例えば、検証結果DB14は、検証された日時を示す検証日時、検証された装置を示す検証対象装置、正常または異常など検証結果を示す検証結果を対応付けて記憶する。制御部15は、パケットキャプチャ部16と検証実施部17とを有し、パケットキャプチャや検証試験を実施する。なお、制御部15は、CPUCentralProcessingUnitなどの電子回路やFPGAFieldProgrammableGateArrayなどの集積回路等である。パケットキャプチャ部16は、スイッチ1dを介して、実動環境で実際に送受信されたパケットをキャプチャして、実動キャプチャデータDB12に格納する。例えば、クライアント端末1cが、実動APサーバ1aにアクセスしてアプリケーションを実行し、実動APサーバ1aが、アプリケーションの実行によって実動DBサーバ1bに対してDBアクセスを実行したとする。この場合、はじめに、パケットキャプチャ部16は、クライアント端末1cから実動APサーバ1aへのDB処理要求を示すパケットをキャプチャする。次に、パケットキャプチャ部16は、実動APサーバ1aから実動DBサーバ1bへ送信されたDBリクエストを示すパケットをキャプチャする。続いて、パケットキャプチャ部16は、実動DBサーバ1bから実動APサーバ1aへ送信されたDBレスポンスを示すパケットをキャプチャする。最後に、パケットキャプチャ部16は、実動APサーバ1aからクライアント端末1cへ送信されたDB処理要求に対する応答を示すパケットをキャプチャする。つまり、パケットキャプチャ部16は、実動環境で実行されたトランザクションによって、実際に発生したパケットを発生した順番でキャプチャして、実動キャプチャデータ12に格納する。なお、パケットキャプチャ部16は、キャプチャしたパケットそのものを実動キャプチャデータDB12に格納してもよい。検証実施部17は、クライアント擬似動作部17aとサーバ擬似動作部17bと結果解析部17cとを有し、これらによって検証対象装置に検証を実行する。クライアント擬似動作部17aは、実動キャプチャデータDB12に保持されるキャプチャデータに、検証対象の装置を宛先とする送信待ちのパケットが存在する場合に、当該パケットを検証対象の装置に送信する。例えば、クライアント擬似動作部17aは、システム管理者等によって検証開始が指示されると、実動キャプチャデータDB12を参照する。そして、クライアント擬似動作部17aは、検証処理がクライアント端末からのパケット送信である場合には、実動キャプチャデータDB12にしたがって、該当するパケットを生成して検証対象装置に送信する。一例を挙げると、クライアント擬似動作部17aは、図3に示した実動キャプチャデータDB12を参照し、シーケンシャル番号=1の処理がクライアント端末1cから実動APサーバ1aへのパケット送信であることを特定する。この結果、クライアント擬似動作部17aは、特定したパケットであるHTTPReqを検証APサーバ2aに送信する。つまり、クライアント擬似動作部17aは、検証APサーバ2aに実トランザクションと同様の処理を実行させるために、クライアント端末1cの動作を擬似的に実行する。また、クライアント擬似動作部17aは、送信したパケットHTTPReqにシーケンシャル番号=1を割り与えて、これらを対応付けて検証データDB13に格納する。サーバ擬似動作部17bは、検証対象の装置から検証対象外の装置へ送信されたパケットを受信する。そして、サーバ擬似動作部17bは、受信されたパケットの応答として実動システムで送信されたパケットを実動キャプチャデータDB12が保持するキャプチャデータから特定し、特定したパケットを検証対象の装置に応答する。例えば、サーバ擬似動作部17bは、クライアント擬似動作部17aからHTTPReqを受信した検証APサーバ2aが実トランザクションと同様のトランザクションを実行して、実動DBサーバ1bに送信したSQLReqを受信する。続いて、サーバ擬似動作部17bは、実動キャプチャデータDB12を参照し、SQLReqの次に、実動DBサーバ1bから実動APサーバ1aにSQLResが送信されていることを特定する。そして、サーバ擬似動作部17bは、SQLResを検証APサーバ2aに送信する。このように、事前検証装置10と検証APサーバ2aとの2台で、実動環境と同様のトランザクションで同様の処理を実行する。つまり、事前検証装置10は、検証環境に存在しない実動DBサーバ1bの動作を擬似的に実行する。また、サーバ擬似動作部17bは、受信したパケットSQLReqにシーケンシャル番号=2を割り与えて検証データDB13に格納する。同様に、サーバ擬似動作部17bは、送信したパケットSQLResにシーケンシャル番号=3を割り与えて検証データDB13に格納する。結果解析部17cは、クライアント擬似動作部17aやサーバ擬似動作部17bによって実行された検証結果を解析する。そして、結果解析部17cは、検証結果をディスプレイ等に表示させたり、メールで管理者等に送信したりする。例えば、結果解析部17cは、実動キャプチャデータDB12に記憶されている情報と検証結果DB14に記憶されている情報とを比較して、一致している場合には、検証処理に異常がないと判定する。一方、結果解析部17cは、実動キャプチャデータDB12に記憶されている情報と検証結果DB14に記憶されている情報とが一致していない場合には、検証処理に異常があると判定する。この場合、結果解析部17cは、一致していない箇所を特定し、特定した箇所を管理者に通知したりする。[事前検証の具体例]次に、事前検証装置10の検証実施部17が実行する事前検証について説明する。図5は、実施例2に係る事前検証を説明する図である。ここで実行される各処理は、例えばシステム管理者から検証開始を指示された場合に、処理を開始する。図5に示すように、事前検証装置10の通信インタフェースには、実動DBサーバ1b宛として使用されるIPアドレスと、クライアント端末1c宛として使用されるIPアドレスが設定されている。検証APサーバ2aには、検証APサーバ2aが直接通信する検証対象外の装置である、実動DBサーバ1bとクライアント端末1cの各々のアドレスとして、事前検証装置10のIPアドレスが設定されている。つまり、検証APサーバ2aは、実動DBサーバ1b宛のパケットおよびクライアント端末1c宛のパケットを事前検証装置10に送信する。また、検証APサーバ2aは、実動DBサーバ1bを送信元とするパケットおよびクライアント端末1cを送信元とするパケットを事前検証装置10から受信する。このような状態において、クライアント擬似動作部17cは、実動キャプチャデータDB12に記憶される情報にしたがってクライアント端末1cの動作を擬似し、HTTPReqを検証APサーバ2aに送信する。続いて、サーバ擬似動作部17bは、検証APサーバ2aからSQLReqを受信した場合、実動キャプチャデータDB12に記憶される情報にしたがって実動DBサーバ1bを擬似し、SQLResを検証APサーバ2aに応答する。その後、サーバ擬似動作部17bは、検証APサーバ2aからHTTPResが送信されると、実動キャプチャデータDB12に記憶される情報にしたがってクライアント動作1cを擬似し、HTTPResを受信する。このようにして、事前検証装置10は、実動環境が取得したパケットキャプチャデータにしたがって検証対象外装置の動作を擬似的に動作させることで、検証処理を実行する。[処理の流れ]次に、図6と図7を用いて、図1に示したシステムで実行される処理の流れについて説明する。ここでは、事前検証装置10が実行するクライアント擬似動作とサーバ擬似動作のそれぞれについて説明する。クライアント擬似動作図6は、事前検証装置が実行するクライアント擬似動作を示すフローチャートである。図6に示すように、クライアント擬似動作部17aは、実動キャプチャデータDB12を参照し、全データの処理が終了したか否かを判定するS101。そして、クライアント擬似動作部17aは、全データの処理が終了していないと判定した場合S101否定、実動キャプチャデータDB12に送信待ちのデータが存在するか否かを判定するS102。その後、クライアント擬似動作部17aは、送信待ちのデータが存在すると判定した場合にはS102肯定、クライアント端末の動作を擬似的に実行して、検証対象装置に対してパケットを送信するS103。つまり、クライアント擬似動作部17aは、検証環境に、実動環境と同様のトランザクションを発生させる。そして、クライアント擬似動作部17aは、検証対象装置に対してパケットを送信したことで、実動キャプチャデータDB12の全データに対して処理を実行した場合にはS101肯定、処理を終了する。なお、S102において、クライアント擬似動作部17aは、実動キャプチャデータDB12に送信待ちのデータが存在しないと判定した場合にはS102否定、S101以降の処理を繰り返す。サーバ擬似動作図7は、事前検証装置が実行するサーバ擬似動作を示すフローチャートである。図7に示すように、サーバ擬似動作部17bは、実動キャプチャデータDB12を参照し、全データの処理が終了したか否かを判定するS201。そして、サーバ擬似動作部17bは、全データの処理が終了していないと判定した場合S201否定、S202以降の処理を実行する。すなわち、サーバ擬似動作部17bは、検証対象装置からパケットを受信した場合S202肯定、実動キャプチャデータDB12を参照し、受信したパケットの応答パケットを抽出するS203。続いて、サーバ擬似動作部17bは、抽出した応答パケットを検証対象装置に送信するS204。その後、サーバ擬似動作部17bは、S201以降の処理を繰り返す。なお、S202において、サーバ擬似動作部17bは、検証対象装置からパケットを受信するまでは、S201とS202を繰り返す。また、サーバ擬似動作部17bは、全データの処理が終了したと判定した場合S201肯定、処理を終了する。[実施例2による効果]実施例2に係る事前検証装置10を用いることで、検証環境として、検証対象外の装置等を準備しなくても、検証対象装置を準備することで事前検証を実施できる。したがって、事前検証の環境構築の費用や人為的労力を従来に比べて大幅に軽減できる。例えば、DBサーバが検証対象外の場合、従来では、実動環境と検証環境においてのDB同期を行っていたが、事前検証装置10を用いることで、同期を行わずとも検証を実施できる。また、図1に示した実動環境以外の他システムで動作する外部サーバが存在する場合、従来は、検証対象の外部サーバとして、検証に用いるスタブ動作をするサーバおよびロジックを準備していた。これに対して、事前検証装置10は、実動環境の実キャプチャデータを用いるので、外部サーバとして筐体やアプリケーションを実装しなくても、実動環境の各装置の検証を容易に実施できる。ところで、実施例2では、APサーバとDBサーバの2階層を有する実動環境のサーバを検証する例について説明したが、これに限定されるものではない。例えば、事前検証装置は、2階層以外の階層であっても同様に検証を実施することができる。そこで、実施例3では、一例として、Webサーバ、APサーバ、DBサーバの3階層を有する実動環境におけるWebサーバに対して検証を実行する例について説明する。[全体構成]図8は、実施例3に係るシステムの全体構成の例を示す図である。図8は、実施例1と同様、事前検証装置10と検証環境とが接続されるとともに、事前検証装置10と実動環境とが接続されている。この検証Webサーバ2bには、検証Webサーバ2bが直接通信する検証対象外の装置である、実動APサーバ1aと実動DBサーバ1bとクライアント端末1cの各々のアドレスとして、事前検証装置10のIPアドレスを設定しておく。実動環境は、実施例2等で説明した装置に加えて実動Webサーバ1eを有し、検証環境とは別のネットワークで形成される。実動Webサーバ1eは、HTML文書や画像などの情報を蓄積しておき、クライアント端末1cや実動APサーバ1aからの要求に応じて、画像等を表示させたWebページを応答する。検証環境は、実動環境とは別のネットワークで形成され、実動環境で動作するサーバや実動環境に新たに接続するサーバを検証サーバとして事前検証装置10に接続する環境である。実施例3では、検証対象装置として検証Webサーバ2bが事前検証装置10と接続されている。事前検証装置10は、実施例2等と同様、実動環境で実際に実行されるトランザクションと同様のトランザクションを用いて、検証APサーバ2aの動作や性能を検証するサーバである。この事前検証装置10は、実動環境における各装置がトランザクションを実行したことで発生したパケットをキャプチャリングする。そして、事前検証装置10は、キャプチャリングしたデータを使用して、検証Webサーバ2bを検証する。[検証処理]図8に示した事前検証装置10は、図2と同様の構成を有するが、実施例2とは実動環境内の装置が異なることから、実動キャプチャデータDB12が記憶する内容が異なる。図9は、実施例3に係る実動キャプチャデータDBに記憶される情報の例を示す図である。図9に示すように、実施例3に係る実動キャプチャデータDB12は、シーケンシャル番号、送信元、送信先、パケットを対応付けて記憶する。なお、ここで記憶される各情報は、実施例2と同様なので、詳細な説明は省略する。実施例3に係る実動キャプチャデータと実施例2で説明した実動キャプチャデータとが異なる点は、実施例3に係る実動キャプチャデータは、実動Webサーバのパケットをキャプチャしている点である。具体的に、図9を用いて説明する。図9の例では、1番目に、クライアント端末1cから実動Webサーバ1eに送信されたHTTPReqがキャプチャされたことを示す。2番目に、実動Webサーバ1eから実動APサーバ1aに送信されたIIOPInternetInter-ORBProtocolReqがキャプチャされたことを示す。さらに、3番目に、実動APサーバ1aから実動DBサーバ1bに送信されたSQLReqがキャプチャされたことを示し、4番目に、実動DBサーバ1bから実動APサーバ1aに送信されたSQLResがキャプチャされたことを示す。5番目に、実動APサーバ1aから実動Webサーバ1eに送信されたIIOPResがキャプチャされ、6番目に、実動Webサーバ1eからクライアント端末1cに送信されたHTTPResがキャプチャされたことを示す。次に、上述したDBを有する事前検証装置10が検証Webサーバ2bに検証を実行する例について説明する。図10は、実施例3に係る事前検証を説明する図である。図10に示すように、事前検証装置10のクライアント擬似動作部17aは、クライアント端末1cから実動Webサーバ1eへのHTTPReqが送信待ちになると、実動キャプチャデータDB12を参照する。すると、クライアント擬似動作部17aは、実動キャプチャデータDB12に記憶されるシーケンシャル番号=1にしたがって、検証Webサーバ2bにHTTPReqを送信する。続いて、サーバ擬似動作部17bは、実動キャプチャデータDB12に記憶されるシーケンシャル番号=2と同様の処理として、検証Webサーバ2bからIIOPReqを受信する。すると、サーバ擬似動作部17bは実動キャプチャデータDB12に記憶されるシーケンシャル番号=5にしたがって、実動Webサーバ2bにIIOPResを送信する。ここで、サーバ擬似動作部17bは、実動キャプチャデータDB12に記憶されるシーケンシャル番号=3と4についてはパケット送信を実行しない。つまり、サーバ擬似動作部17bは、実動APサーバ1aから実動DBサーバ1bへのSQLReq送信と、実動DBサーバ1bから実動APサーバ1aへのSQLRes受信を実行しない。このサーバ擬似動作部17bは、検証対象の検証Webサーバ2bに直接関わりがない処理については、暗に実動システムと同様の処理が内部でなされたとして、パケット送受信しない。その後、結果解析部17cは、サーバ擬似動作部17bが検証Webサーバ2bからクライアント端末1cへのHTTPResを受信すると、検証環境での機能および性能解析検証を行い、検証試験結果を表示する。なお、結果解析部17cが実行する処理は、実施例2と同様なので、詳細な説明は省略する。[実施例3による効果]このように、実施例3によれば、事前検証装置10は、実キャプチャデータにおいて、検証対象である装置が直接通信しない検証対象外の装置と関係する通信については、キャプチャデータで採取されていても、利用しないで検証を進めることができる。なお、事前検証装置10は、検証対象装置が関係する通信だけを実動環境でキャプチャし、検証対象装置が関係しない通信については、キャプチャしないようにすることもできる。このようにすることで、メモリやDBの容量増加も防止できる。ところで、実施例1から実施例3では、事前検証装置10は、実動環境で取得したキャプチャデータを用いて検証を実行する例について説明したが、これに限定されるものではない。例えば、事前検証装置10は、実動環境で取得したキャプチャデータから、送受信されるパケットの対応表を生成し、この対応表を用いて検証を実行することもできる。そこで、実施例3では、事前検証装置10が生成する対応表の生成について説明する。具体例1図11は、対応表生成例を示す図である。図11の左図に示すように、事前検証装置10のパケットキャプチャ部16は、実動APサーバと実動DBサーバとの通信をキャプチャすることで、要求a、要求b、応答c、応答dが送受信されたことを特定する。ところが、パケットキャプチャ部16は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。そこで、パケットキャプチャ部16は、実動APサーバとクライアント端末との間の通信をキャプチャした結果と、上述した実動APサーバと実動DBサーバとのキャプチャ結果と組み合わせる。例えば、パケットキャプチャ部16は、両方のキャプチャデータを時間順に並べる。つまり、図11の中央図に示すように、パケットキャプチャ部16は、クライアント1から要求を受信した実動APサーバが要求aを実動DBサーバに送信し、クライアント2から要求を受信した実動APサーバが要求bを実動DBサーバに送信したと特定できる。さらに、図11の中央図に示すように、パケットキャプチャ部16は、実動DBサーバから応答cを受信した実動APサーバが応答をクライアント2に送信し、実動DBサーバから応答dを受信した実動APサーバが応答をクライアント1に送信したと特定できる。この結果、パケットキャプチャ部16は、図11の右図に示すように、要求、応答として要求a、応答dと要求b、応答cと対応付けて記憶することができる。その後、クライアント擬似動作部17bやサーバ擬似動作部17cは、この対応表を用いて検証を実行する。例えば、実動APサーバを検証する場合、クライアント擬似動作部17bは、クライアント端末の動作を擬似して、要求を検証APサーバに送信する。そして、サーバ擬似動作部17cは、検証APサーバから要求aを受信すると、要求aに対応する応答dを対応表から特定し、実動DBサーバの動作を擬似して応答dを実動APサーバに応答する。その後、サーバ擬似動作部17cは、応答dに対応する応答を実動APサーバから受信する。そして、結果解析部17は、検証対象装置と事前検証装置10との間で対応表通りにパケットを送受信できた場合に、検証対象装置が正常動作していると判定する。一方、結果解析部17は、検証対象装置と事前検証装置10との間で対応表通りにパケットを送受信できなかった場合に、検証対象装置が異常動作していると判定する。具体例2図12は、対応表生成例を示す図である。図12の左図に示すように、事前検証装置10のパケットキャプチャ部16は、実動APサーバと実動DBサーバとの通信をキャプチャすることで、要求a、要求b、応答c、応答dが送受信されたことを特定する。ところが、パケットキャプチャ部16は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。そこで、パケットキャプチャ部16は、実動APサーバとクライアント端末との間の通信をキャプチャした結果と、上述した実動APサーバと実動DBサーバとのキャプチャ結果と組み合わせる。例えば、パケットキャプチャ部16は、両方のキャプチャデータを時間順に並べる。つまり、図12の中央図に示すように、パケットキャプチャ部16は、クライアント1から要求を受信した実動APサーバが要求aを実動DBサーバに送信し、クライアント2から要求を受信した実動APサーバが要求bを実動DBサーバに送信したと特定できる。さらに、図12の中央図に示すように、パケットキャプチャ部16は、実動DBサーバから応答cを受信した実動APサーバが応答をクライアント1に送信し、実動DBサーバから応答dを受信した実動APサーバが応答をクライアント2に送信したと特定できる。この結果、パケットキャプチャ部16は、図12の右図に示すように、要求、応答として要求a、応答cと要求b、応答dと対応付けて記憶することができる。その後、クライアント擬似動作部17bやサーバ擬似動作部17cは、この対応表を用いて検証を実行する。具体例3図13は、対応表生成例を示す図である。図13の左上図に示すように、事前検証装置10のパケットキャプチャ部16は、実動APサーバと実動DBサーバとの通信をキャプチャすることで、要求a、要求b、応答c、応答dが送受信されたことを特定する。ところが、パケットキャプチャ部16は、この情報だけでは、どの要求シーケンスに対してどの応答シーケンスを受信したかを特定できない。そこで、パケットキャプチャ部16は、クライアント端末と実動APサーバと実動DBサーバとの間で、1多重で処理が実行されたときのシーケンスを利用する。つまり、パケットキャプチャ部16は、図13の左上図とは別にパケットキャプチャした情報として、図13の左下図に示すようなクライアント端末から実動APサーバに要求が送信されて、実動APサーバから実動DBサーバに要求aが送信された情報を取得する。さらに、パケットキャプチャ部16は、実動DBサーバから応答dが実動APサーバに送信されて、実動APサーバがクライアント端末に応答を返信した情報を取得する。そして、パケットキャプチャ部16は、図13の左下図に示したパケットキャプチャ情報から要求aと応答dとが対応していることを特定する。パケットキャプチャ部16は、この結果を図13の左上図と組み合わせて要求aと応答dとを除外することで、要求bと応答cとが対応することを特定する。この結果、パケットキャプチャ部16は、図13の右図に示すように、要求、応答として要求a、応答dと要求b、応答cと対応付けて記憶することができる。その後、クライアント擬似動作部17bやサーバ擬似動作部17cは、この対応表を用いて検証を実行する。さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。検証対象例えば、上述した実施例では、APサーバやWebサーバを検証する例について説明したが、これに限定されるものではなく、実動環境で動作する様々な装置を検証対象とすることができる。また、事前検証装置は、実動環境に流れる全てのパケットをキャプチャリングようにしてもよく、検証対象装置に関連するパケットだけをキャプチャリングするようにしてもよい。また、実施例1等では、事前検証装置10は、検証対象の装置から検証対象外の装置へのパケットを受信して、検証対象外の装置の動作を擬似する例について説明したが、これに限定されるものではない。例えば、事前検証装置10は、実動環境のパケットをキャプチャリングしておくことで、検証対象の装置から検証対象の他の装置へのパケットを受信して、検証対象の他の装置の動作を擬似することもできる。この場合、例えば、検証対象の装置には、検証対象の装置が直接通信する検証対象の他の装置のアドレスとして、事前検証装置10のIPアドレスを設定しておくことで、事前検証装置10は、検証対象の装置から検証対象の他の装置へのパケットを受信できる。検証環境例えば、上述した実施例では、実動環境と検証環境とを別のネットワークで構築する例について説明したが、これに限定されるものではない。例えば、実動環境を用いて検証することもできる。その場合、図1のスイッチ1dに対して、事前検証装置と検証対象装置とが接続されるようにスイッチング情報の設定変更をしてもよく、事前検証装置と検証対象装置を実動環境上で直接接続するように、一時的にネットワークを変更してもよい。インタフェース例えば、実施例2に係る事前検証装置10では、通信インタフェース11の第2ポートに実動DBサーバ1bと同じIPアドレスを設定し、第3ポートには、クライアント端末1cと同じIPアドレスを設定することで、通信を区別する例について説明した。ところが、通信の区別はこれに限定されるものではない。例えば、通信インタフェースそのものを複数用意してもよく、通信メッセージの特性から通信を区別することもできる。通信メッセージの特性から通信を区別する一例を挙げると、例えば、HTTP通信の場合にはクライアント端末の通信と判定し、SQL通信の場合にはDBサーバの通信と区別することができる。なお、上述した実施例で説明した各要求や応答はあくまで例示であり、これに限定されるものではない。システムまた、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、例えば図3、図9等に示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。プログラム図14は、検証試験プログラムを実行するコンピュータのハードウェア構成例を示す図である。図14に示すように、コンピュータ100は、CPU101、メモリ102、IFInterface103、Disk104を備えている。また、各構成部はバス100aによってそれぞれ接続されている。ここで、CPU101は、コンピュータ100の全体の制御を司る。メモリ102は、CPU101のワークエリアとして使用され、本メモリ内で検証試験プログラム102aが動作する。この検証試験プログラム102aが実行されることで、図2に示した各制御部と同様の処理を動作する検証試験プロセスが実行される。また、Disk104には、実動キャプチャデータ104aが記憶される。コンピュータ100の外部には、モニタ105として、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示し、マウス106により操作する。このモニタ105は、例えば、CRTCathodeRayTube、TFTThinFilmTransistor液晶ディスプレイ、プラズマディスプレイなどを採用することができる。IF103は、通信回線を通じてLANLocalAreaNetwork、WANWideAreaNetwork、インターネットなどのネットワークに接続される。そして、IF103は、これらのネットワークを介して実動系システム、検証系システムを含む他の装置に接続される。また、IF103は、ネットワークと内部のインタフェースを司り、外部装置からのデータの入出力を制御する。IF103には、たとえばLANアダプタやモデムなどを採用することができる。