現行情報システムから新情報システムへアプリケーションを移行する際の移行テストを支援するシステムであって、前記現行情報システム上で動作するアプリケーションと前記新情報システム上で動作するアプリケーションを実行することによって前記アプリケーションの実行結果トレースを取得するアプリケーション実行装置と、前記現行情報システムの入出力データを記録した現行入出力ログと、前記新情報システムの入出力データを記録した新入出力ログとを比較して不一致箇所を特定する移行テスト支援装置と、を有し、前記移行テスト支援装置は、前記現行入出力ログと前記新入出力ログを読み込み、前記現行入出力ログにおける入力と出力の対応関係が、前記新入出力ログにおける入力と出力の対応関係に一致しているか否かを判定し、前記現行入出力ログにおける前記対応関係と前記新入出力ログにおける前記対応関係が一致していない場合は、その不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを、前記実行結果トレースに基づき判定し、前記アプリケーションが前記新情報システム上で改修されていると判定した場合は、前記現行情報システムと前記新情報システムを比較する対象から除外する箇所として前記不一致箇所を指定し、前記指定した前記不一致箇所を除いて、前記アプリケーションの動作が前記現行情報システム上と前記新情報システム上で異なる部分についての差分ログを出力することを特徴とする移行テスト支援システム。前記アプリケーション実行装置は、前記新情報システム上で動作するアプリケーションのソースコードを読み込み、前記現行情報システム上のアプリケーションが前記新情報システム上で改修されている場合は、その箇所を特定する改修タグを記述したトレースログを出力するステップを前記ソースコード内に埋め込み、前記ソースコードをコンパイルして実行することにより、前記実行結果トレースを取得し、前記移行テスト支援装置は、前記実行結果トレースが記述している前記改修タグに基づき、前記不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを判定することを特徴とする請求項1記載の移行テスト支援システム。前記アプリケーション実行装置は、前記移行によって置き換える特定のソフトウェアが提供するAPIを前記アプリケーションが利用している場合は、その旨を示すAPI利用タグを記述したトレースログを出力するステップを前記ソースコード内に埋め込み、前記ソースコードをコンパイルして実行することにより、前記実行結果トレースを取得し、前記移行テスト支援装置は、前記実行結果トレースが記述している前記API利用タグに基づき、前記アプリケーションが前記APIを利用しているか否かを判定することにより、前記現行情報システム上の前記アプリケーションと前記新情報システム上の前記アプリケーションの間の差異が前記移行に起因するものであるか否かを推定し、その結果を前記差分ログに出力することを特徴とする請求項1記載の移行テスト支援システム。前記移行テスト支援装置は、前記現行情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる現行通信セッションIDを記述したセッション管理テーブルを読み込み、前記セッション管理テーブルが記述している前記現行通信セッションIDをキーにして、前記現行入出力ログ内の対応するレコードを特定し、その記述内容にしたがって前記新情報システム上で前記アプリケーションの動作を再現することにより、前記新入出力ログを作成することを特徴とする請求項1記載の移行テスト支援システム。前記移行テスト支援装置は、前記新情報システム上で前記アプリケーションの動作を再現する過程において、前記新情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる新通信セッションIDと、前記現行通信セッションIDとの対応関係を、前記セッション管理テーブルに記述することを特徴とする請求項4記載の移行テスト支援システム。現行情報システムから新情報システムへアプリケーションを移行する際の移行テストを支援する処理をコンピュータに実行させるプログラムであって、前記コンピュータに、前記現行情報システムの入出力データを記録した現行入出力ログと、前記新情報システムの入出力データを記録した新入出力ログとを読み込むステップ、前記現行入出力ログにおける入力と出力の対応関係が、前記新入出力ログにおける入力と出力の対応関係に一致しているか否かを判定するステップ、前記現行入出力ログにおける前記対応関係と前記新入出力ログにおける前記対応関係が一致していない場合は、その不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを、前記アプリケーションの実行結果トレースに基づき判定する改修判定ステップ、前記改修判定ステップにおいて、前記アプリケーションが前記新情報システム上で改修されていると判定した場合は、前記現行情報システムと前記新情報システムを比較する対象から除外する箇所として前記不一致箇所を指定する除外ステップ、前記除外ステップで指定した前記不一致箇所を除いて、前記アプリケーションの動作が前記現行情報システム上と前記新情報システム上で異なる部分についての差分ログを出力するステップ、を実行させることを特徴とする移行テスト支援プログラム。前記移行テスト支援プログラムは、前記コンピュータに、前記現行情報システム上のアプリケーションが前記新情報システム上で改修されている箇所を特定する改修タグを記述したトレースログを前記実行結果トレースから読み込むステップ、前記実行結果トレースが記述している前記改修タグに基づき、前記不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを判定するステップ、を実行させることを特徴とする請求項6記載の移行テスト支援プログラム。前記移行テスト支援プログラムは、前記コンピュータに、前記移行によって置き換える特定のソフトウェアが提供するAPIを前記アプリケーションが利用している旨を示すAPI利用タグを記述したトレースログを前記実行結果トレースから読み込むステップ、前記実行結果トレースが記述している前記API利用タグに基づき、前記アプリケーションが前記APIを利用しているか否かを判定することにより、前記現行情報システム上の前記アプリケーションと前記新情報システム上の前記アプリケーションの間の差異が前記移行に起因するものであるか否かを推定し、その結果を前記差分ログに出力するステップ、を実行させることを特徴とする請求項6記載の移行テスト支援プログラム。前記移行テスト支援プログラムは、前記コンピュータに、前記現行情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる現行通信セッションIDを記述したセッション管理テーブルを読み込むステップ、前記セッション管理テーブルが記述している前記現行通信セッションIDをキーにして、前記現行入出力ログ内の対応するレコードを特定し、その記述内容にしたがって前記新情報システム上で前記アプリケーションの動作を再現することにより、前記新入出力ログを作成するステップ、を実行させることを特徴とする請求項6記載の移行テスト支援プログラム。前記移行テスト支援プログラムは、前記コンピュータに、前記新情報システム上で前記アプリケーションの動作を再現する過程において、前記新情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる新通信セッションIDと、前記現行通信セッションIDとの対応関係を、前記セッション管理テーブルに記述するステップを実行させることを特徴とする請求項9記載の移行テスト支援プログラム。現行情報システムから新情報システムへアプリケーションを移行する際の移行テストを支援する方法であって、前記現行情報システムの入出力データを記録した現行入出力ログと、前記新情報システムの入出力データを記録した新入出力ログとを読み込むステップ、前記現行入出力ログにおける入力と出力の対応関係が、前記新入出力ログにおける入力と出力の対応関係に一致しているか否かを判定するステップ、前記現行入出力ログにおける前記対応関係と前記新入出力ログにおける前記対応関係が一致していない場合は、その不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを、前記アプリケーションの実行結果トレースに基づき判定する改修判定ステップ、前記改修判定ステップにおいて、前記アプリケーションが前記新情報システム上で改修されていると判定した場合は、前記現行情報システムと前記新情報システムを比較する対象から除外する箇所として前記不一致箇所を指定する除外ステップ、前記除外ステップで指定した前記不一致箇所を除いて、前記アプリケーションの動作が前記現行情報システム上と前記新情報システム上で異なる部分についての差分ログを出力するステップ、を有することを特徴とする移行テスト支援方法。前記現行情報システム上のアプリケーションが前記新情報システム上で改修されている箇所を特定する改修タグを記述したトレースログを前記実行結果トレースから読み込むステップ、前記実行結果トレースが記述している前記改修タグに基づき、前記不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを判定するステップ、を有することを特徴とする請求項11記載の移行テスト支援方法。前記移行によって置き換える特定のソフトウェアが提供するAPIを前記アプリケーションが利用している旨を示すAPI利用タグを記述したトレースログを前記実行結果トレースから読み込むステップ、前記実行結果トレースが記述している前記API利用タグに基づき、前記アプリケーションが前記APIを利用しているか否かを判定することにより、前記現行情報システム上の前記アプリケーションと前記新情報システム上の前記アプリケーションの間の差異が前記移行に起因するものであるか否かを推定し、その結果を前記差分ログに出力するステップ、を有することを特徴とする請求項11記載の移行テスト支援方法。前記現行情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる現行通信セッションIDを記述したセッション管理テーブルを読み込むステップ、前記セッション管理テーブルが記述している前記現行通信セッションIDをキーにして、前記現行入出力ログ内の対応するレコードを特定し、その記述内容にしたがって前記新情報システム上で前記アプリケーションの動作を再現することにより、前記新入出力ログを作成するステップ、を有することを特徴とする請求項11記載の移行テスト支援方法。前記新情報システム上で前記アプリケーションの動作を再現する過程において、前記新情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる新通信セッションIDと、前記現行通信セッションIDとの対応関係を、前記セッション管理テーブルに記述するステップを有することを特徴とする請求項14記載の移行テスト支援方法。システム移行を実施する際には、ハードウェア、ソフトウェアともに、その時点で提供されているバージョンにアップデートされる場合が多い。したがって、システム側の動作が変化することは容易に想定できる。基幹系のコンピュータシステムによるサービスは基本的なサービスであるので、コンピュータシステムが更改されてもサービス内容が変わらないことが要求される場合が多い。そのため、移行前のアプリケーションが移行後もそのまま動作するように新システムを構築することが重要である。もっとも、システムに対する入出力データが移行の前後で維持されていれば、システム内部の動作が変更されていたとしても、特段の支障はないと考えられる。したがって、アプリケーションには手を加えず、システム移行後も入出力データが移行前と同じであることを保証する必要がある。しかし実際には、ユーザサイドにおいて、システム運用中にアプリケーションに修正や機能追加等の改修が実施されている場合がある。この場合、システム移行前後において入出力データに予期しない相違が生じる可能性がある。このとき、その相違がシステム移行に起因するものであるのか、それともアプリケーションの改修が原因となっているのかを切り分ける必要がある。特許文献1に記載されている技術では、新旧システムの入出力ログやトレース情報を比較することにより、移行によって生じたシステム構成モジュールの相違点を抽出することはできるが、アプリケーション自体の更改も相違点として抽出するため、相違の原因を容易に切り分けることが難しい。本発明は、上記のような課題を解決するためになされたものであり、システム移行テストにおいて、現行システムと新システムとの間の差分を解析するにあたり、アプリケーションが改修されている部分を解析対象から除外し、新旧システム間の相違原因を分析し易くすることを主な目的の一つとする。本発明に係る移行テスト支援システムの一態様は、アプリケーションが改修されている箇所を記述した改修タグをアプリケーションの実行結果トレースから読み込み、その部分を現行システムと新システムの間の比較対象から除外する。本発明に係る移行テスト支援システムによれば、アプリケーションの改修箇所を実行結果トレースから読み込むことにより、現行システムと新システムの間の相違がアプリケーションの改修によるものであるか否かを識別することができる。これにより、相違の原因を早期に発見することができる。<実施の形態1>図1は、本発明の実施形態1に係る移行テスト支援システム1000の構成図である。移行テスト支援システム1000は、テスト支援サーバ100、現行システム200、新システム300及び端末400を有する。これらはネットワークを介して接続されている。テスト支援サーバ100は、現行システム200を新システム300に移行する際に、アプリケーションの動作が変更されていないかをテストする移行テスト支援を実施するサーバ装置である。テスト支援サーバ100は、現行システムログ111と新システムログ112に記録されているログに基づき、移行テスト支援を実施する。これらログ及びテスト支援サーバ100の詳細は後述する。現行システム200は、Web3階層モデルに準じたWebアプリケーションを実行する情報システムであり、WebAPサーバ210及びDBMS220を有する。WebAPサーバ210は、Webアプリケーションとして実装されたアプリケーションAP211と、開発/実行環境212とを有する。開発/実行環境212は、アプリケーション開発を実施するための開発ソフトウェアなどを含むソフトウェア群である。詳細は後述する。DBMS220は、アプリケーション211が利用するデータベースDBへのアクセス等を管理する機能を有する。新システム300は、現行システム200のうち、WebAPサーバ210を新WebAPサーバ310に置き換えたものである。これにともない、Webアプリケーションを提供するためのミドルウェアが新バージョンに置き換えられている。また、移行前におけるアプリケーション211は、新システム300の下では改修アプリケーション311に置き換えられている場合もある。新システム300は、アプリケーション211の動作が現行システム200との間で相違ないことを保証する必要がある。システム内部の動作は、現行システム200と新システム300の間で異なっていても問わないことにする。システム内部の動作とは、例えばOSやWebサーバなどのミドルウェアの動作がこれに相当する。WebAPサーバ210と新WebAPサーバ310は、本実施形態1におけるアプリケーション実行装置に相当する。図2は、テスト支援サーバ100の詳細構成を示す図である。テスト支援サーバ100は、記憶装置110、メモリ120、ネットワークインタフェース130、プロセッサ140、入力装置150、出力装置160及びバス170を備える。記憶装置110は、ハードディスク装置などの不揮発性記憶装置であり、図1で説明した現行システムログ111と新システムログ112を格納する。これらログはメモリ120上に展開することもできる。図2では、記載の便宜上、メモリ120上にこれらログを展開した例を示した。メモリ120は、プロセッサ140が実行するプログラム、現行システムログ111、新システムログ112及びリプレイテストシナリオ113を格納する記憶装置である。これらプログラム等については後述する。以下では記載の便宜上、各プログラムを動作主体として説明する場合があるが、実際にこれらプログラムを実行するのはプロセッサ140であることを付言しておく。ネットワークインタフェース130は、テスト支援サーバ100とネットワークを接続するインタフェースである。入力装置150は、ユーザがテスト支援サーバ100を操作するためのキーボード、マウスなどの操作装置である。出力装置160は、テスト支援サーバ100が実施した処理などを表示するディスプレイ等の画面出力装置である。バス170は、上記各機能部を接続する。メモリ120は、プロセッサ140が実行する移行テスト支援プログラムとして、通信部141、リプレイテスト実行部142、トレース情報受信部143、新システムログ情報処理部144、現行システムログ情報取得部145及び差分抽出部146を格納する。これら機能部は一体的に構成してもよい。メモリ120はその他、現行システムログ111を構成する各ログとして、現行セッション管理テーブル1111、現行入出力ログ1112及び現行テストログ1113を格納する。また、新システムログ112を構成する各ログとして、新セッション管理テーブル1121、新入出力ログ1122、新トレースログ1123及び新テストログ1124を格納する。通信部141は、ネットワークインタフェース130が受信したデータを取得し、リプレイテスト実行部142が送信するデータをネットワークインタフェース130へ出力する。リプレイテスト実行部142は、現行システムログ情報取得部145が取得した現行セッション管理テーブル1111及び現行入出力ログ1112から、新システム300に投入するリプレイテストシナリオ113を生成する。また、リプレイテストシナリオ113にしたがって、新システム300へ入力データを送信し、新システム300から出力データを受信して、これに基づき新セッション管理テーブル1121及び新入出力ログ1122を生成する。トレース情報受信部143は、図3に後述する新システム300の開発/実行環境212が出力するアプリケーション実行時の新トレースログ1123を取得し、新システムログ情報処理部144へ引き渡す。新トレースログ1123は、新システム300を構成する少なくとも1つ以上のサーバミドルウェアが個別にあるいは連携して出力する。ここでいうサーバミドルウェアは、例えば新WebAPサーバ310が実行するWebサーバ及びアプリケーションサーバ及びDBMS220などがこれに相当する。新システムログ情報処理部144は、リプレイテスト実行部142がリプレイテストを実行して得た新セッション管理テーブル1121及び新入出力ログ1122を受け取り、またトレース情報受信部143から新トレースログ1123を受け取る。現行システムログ情報取得部145は、現行システム200から現行システムログ111を取得し、差分抽出部146へ引き渡す。差分抽出部146は、現行テストログ1113と新テストログ1124を比較し、差分を検出する。この際、新テストログ1124内にアプリケーション211を改修した旨を示す改修タグが付加されている場合は、その部分の処理については差分検出の対象から除外して両者を比較する。詳細は後述の図12で説明する。図3は、WebAPサーバ210の構成を示す図である。新WebAPサーバ310も同様の構成を有する。WebAPサーバ210は、AP211と開発/実効環境212の他、メモリ213、プロセッサ214、記憶装置215、入力装置216、出力装置217、ネットワークインタフェース218及びバス219を備える。記憶装置215、入力装置216、出力装置217、ネットワークインタフェース218及びバス219の役割についてはテスト支援サーバ100と同様であるため、説明を省略する。開発/実行環境212は、プログラム開発ツール及びその実行モジュールなど、アプリケーション211を開発するために用いられるソフトウェアを集約したものである。開発/実行環境212は、スタンドアロンアプリケーションとして構成することもできるし、WebAPサーバ210配下のアプリケーションとして構成することもできる。メモリ213は、開発/実行環境212を構成するプログラムモジュールとして、通信部2121、アプリケーションコンパイル部2122、アプリケーション実行部2123、トレース情報送信部2124及びアプリケーションプログラミングインタフェースAPI2125を格納する。新WebAPサーバ310は、さらに新トレースログ1123を格納する。アプリケーションコンパイル部2122は、さらにアプリケーション改修検出部21221と実行ファイル生成部21222を有する。アプリケーション実行部2123は、さらに実行部21231とトレース情報記録部21232を有する。通信部2121は、ネットワークインタフェース218から、アプリケーション211に対する入力データ及びテスト支援サーバ100からのシステムログ取得要求を受信し、これらをアプリケーション211やトレース情報送信部2124に引き渡す。また、アプリケーション211が送信するデータや、アプリケーション211を実行して得られるトレース情報を、ネットワークインタフェース218へ出力する。実行ファイル生成部21222は、アプリケーションソースコードをコンパイルして実行ファイルを生成する。アプリケーション改修検出部21221は、実行ファイル生成部21222がアプリケーション211のソースコードをコンパイルする時、ソースコードのうち改修されている部分及び改修されている部分を呼び出している部分に改修タグを付ける。改修タグを付ける処理は、ユーザがソースコードを改修した際にアプリケーション改修検出部21221が自動的に実施してもよいし、API2125を介してユーザが改修箇所を指定するようにしてもよい。実行部21231は、実行ファイル生成部21222がソースコードをコンパイルすることによって生成したアプリケーション211の実行ファイルを起動して実行する。トレース情報記録部21232は、実行部21231がアプリケーション211を実行する際、トレースID等の識別子を割り当て、アプリケーション211に対する入力から出力までのシステム内部動作をトレースした情報を記録する。トレース情報送信部2124は、テスト支援サーバ100からの要求に応じて、トレース情報記録部21232が記録したトレース情報を送信する。API2125は、現行システム200と新システム300が有するシステム要素のうち、新バージョンに置き換えられているミドルウェア等が有するAPIである。例えばWebアプリケーションを実行するために用いるミドルウェアやDBMSなどが提供するAPIがこれに相当する。以上、移行テスト支援システム1000の構成について説明した。以下の図4~図7では、移行テスト支援システム1000の動作手順について説明する。図4は、新システム300におけるアプリケーションコンパイル部2122とアプリケーション実行部2123が、アプリケーション211又は改修アプリケーション311、以下図4において同様の実行結果トレースを生成する処理のフローチャートである。実行結果トレースは、アプリケーション211又は改修アプリケーション311の内部的な処理状態を記録するログである。実行結果トレースは特に、アプリケーションが改修されている箇所を示す改修タグを記録する意義がある。以下、図4の各ステップについて説明する。図4:ステップS400アプリケーションコンパイル部2122は、例えばユーザの選択に基づき、アプリケーション211のソースコードをコンパイルするか、それともアプリケーション211を実行して実行結果トレースを生成するかを判断する。コンパイルを実施する場合はステップS401へ進み、実行結果トレースを生成する場合はステップS408へスキップする。図4:ステップS401~S402アプリケーションコンパイル部2122は、アプリケーション211のソースコードを適当な分量例えば1命令文読み込むS401。アプリケーションコンパイル部2122は、ソースコード内に改修タグが付加されているかどうかを検出するS402。改修タグが付加されている場合はステップS403へ進み、付加されていない場合はステップS404へスキップする。図4:ステップS402:補足ソースコード内の改修タグは、ユーザがソースコードを改修するときに手動で付加してもよいし、ソースコードが改修された旨をプログラム開発ツールなどが自動検出して自動的に付加してもよい。図4:ステップS403アプリケーションコンパイル部2122は、アプリケーション211のソースコード内の改修されている箇所に、改修タグが付加されている旨のトレース情報を出力するプログラムコードを埋め込む。例えば、実行結果トレースのファイル名を指定し、ソースコード内の改修されている箇所の行番号、関数名などを実行結果トレースに書き込むようなコードを埋め込む。実行結果トレースの例は後述の図5で説明する。図4:ステップS404~S405アプリケーションコンパイル部2122は、ステップS402で検出した、改修タグが付加されている箇所のプログラム命令のうち、API2125を利用しているものがあるか否かを判定するS404。改修タグが付加されているプログラム命令のうちAPI2125を利用しているものがある場合はステップS406へ進み、ない場合はステップS407へスキップするS405。図4:ステップS404~S405:補足本ステップは、アプリケーション211の改修された部分が、API2125を介してミドルウェアと連結しているか否かを判定するための準備としての意義がある。改修された部分のプログラム命令がAPI2125を利用している場合は、その部分はAPI2125を介してミドルウェアの機能を利用しているため、ミドルウェアを更改するとその影響がアプリケーション211にも及ぶ可能性があると考えられる。アプリケーション211のうち動作がシステム移行前後で異なる場合、その部分がAPI2125を利用していなければ、動作の相違はアプリケーション211自体の改修によって生じたと推測することができる。図4:ステップS406アプリケーションコンパイル部2122は、改修タグが付加されているプログラム命令がAPI2125を使用している旨のトレース情報を出力するプログラムコードを埋め込む。例えばミドルウェア更改によってAPI2125に関連する部分が更改されたか否かなどの基準により、ミドルウェア更改の影響がアプリケーション211に及ぶか否かを推定し、その結果をトレース情報に出力してもよい。図4:ステップS407アプリケーションコンパイル部2122は、アプリケーション211のソースコードをコンパイルして実行コードを生成する。図4:ステップS408~S409アプリケーション実行部2123は、例えばユーザの選択に基づき、アプリケーション211を実行するよう指示されているか否かを判断する。実行する場合はステップS409へ進んでアプリケーション211を起動しS409、実行しない場合は本処理フローを終了する。図4:ステップS410アプリケーション実行部2123は、アプリケーションコンパイル部2122が生成した実行コードを読み込んで実行する。図4:ステップS411~S412アプリケーション実行部2123は、実行コード内に、アプリケーションコンパイル部2122がステップS403でソースコード内に埋め込んだプログラムコードが含まれているか否かを判定するS412。含まれている場合は、改修タグを記述したトレース情報を新トレースログ1123に記録するS412。図4:ステップS413~S414アプリケーション実行部2123は、実行コード内に、アプリケーションコンパイル部2122がステップS406でソースコード内に埋め込んだプログラムコードが含まれているか否かを判定するS413。含まれている場合は、改修タグが付加されているプログラム命令がAPI2125を使用している旨のトレース情報を新トレースログ1123に記録するS414。図4:ステップS415アプリケーション実行部2123は、アプリケーション211が終了するまで、S410~S414を繰り返し実行する。図5は、新トレースログ1123の構成とデータ例を示す図である。新トレースログ1123は、アプリケーション実行部2123が図4で説明した処理フローにしたがって新システム300におけるアプリケーション211又は改修アプリケーション311、以下図5において同じを実行することによって得られる、アプリケーション211の内部的な動作ログである。現行テストログ1113及び新テストログ1124も、同様のフォーマットを有する。新トレースログ1123は、1レコード内に、時刻情報112301、プロセスID112302、トレースID112303、セッションID112304、送信元アドレス112305、宛先アドレス112306、モジュール名112307、処理コード112308、APIフラグ112312、改修タグ112313及びデータ112314を格納する。時刻情報112301は、当該レコードが発生した時刻を保持する。プロセスID112302は、当該レコードを出力するプログラムのプロセス識別子を保持する。トレースID112303は、当該レコードがどの入力データに対するトレース情報であるのかを対応付けるための識別子を保持する。セッションID112304は、当該レコードを記録したアプリケーション211へその時点で割り当てられているセッション識別子を保持する。送信元アドレス112305は、当該レコードが通信処理に関するものである場合、当該通信処理の送信元アドレスを保持する。宛先アドレス112306は、当該レコードが通信処理に関するものである場合、当該通信処理の宛先アドレスを保持する。モジュール名112307は、当該レコードを出力したプログラムコードのモジュール名を保持する。処理コード112308は、当該レコードを出力したプログラムの関数名112309、入力引数112310、出力値112311を保持する。APIフラグ112312は、処理コード112308が指定するプログラムコードがAPI1125を利用しているか否かを示す値を保持する。改修タグ112313は、処理コード112308が指定するプログラムコードが改修されているか否かを示す値を保持する。例えば、改修タグ112313が0である場合は改修なしを、1である場合は当該コードが改修されていることを、2である場合は改修されたコードを利用していること等である。データ112314は、例えば当該レコードが通信処理に関するものである場合は、その通信データ、関係するメモリのデータ等を保持する。図6は、テスト支援サーバ100の処理フローである。以下、図6の各ステップについて説明する。図6:ステップS600現行システムログ情報取得部145は、現行システムログ111を取得する。リプレイテスト実行部142は、現行システムログ111を用いて、リプレイテストシナリオ113を生成する。本ステップの詳細は、後述の図7で改めて説明する。図6:ステップS601リプレイテスト実行部142は、リプレイテストシナリオ113にしたがって、新システム300のリプレイテストを実施する。リプレイテストは、新システム300に対して現行システム200と同様の入力データを与え、出力データを記録することにより、現行システム200の動作を再現するテストである。本ステップの詳細は、後述の図11で改めて説明する。図6:ステップS602~S604リプレイテスト実行部142は、現行入出力ログ1112を読み込みS602、リプレイテストによって出力した新入出力ログ1122と比較するS603。現行入出力ログ1112における入力データと出力データの対応関係が、新入出力ログ1122における入力データと出力データの対応関係とは異なっている場合は、ステップS605へ進む。両者が同じである場合は、本処理フローを終了するS604。図6:ステップS603:補足現行入出力ログ1112と新入出力ログ1122の比較は、セッション識別子セッションIDをキーとし、システムに対する入力データとシステムからの出力データとをそれぞれ比較することによって実施する。図6:ステップS605トレース情報受信部143は、新システム300から新トレースログ1123を取得する。図6:ステップS606新システムログ情報処理部144は、新入出力ログ1122及び新トレースログ1123を、時刻情報112301やシステムがアプリケーション実行時に割り当てる識別子例えば、プロセスID112302、トレースID112303、セッションID112304等を基準として統合することにより、新テストログ1124を生成する。図6:ステップS607差分抽出部146は、現行テストログ1113におけるシステム入出力と、新テストログ1124におけるシステム入出力との間の差分を抽出する。本ステップの詳細は、後述の図12で説明する。図6:ステップS608~S609差分抽出部146は、現行テストログ1113と新テストログ1124の間に差分があるか否かを判断するS608。差分がある場合はその差分を記述した差分情報を記憶装置110に書き込み、差分がない場合は本処理フローを終了するS609。図7は、ステップS600の詳細を示す図である。以下、図7の各ステップについて説明する。図7:ステップS700リプレイテスト実行部142は、後述の図8で説明する現行セッション管理テーブル1111を読み込む。現行セッション管理テーブル1111は、端末400と現行システム200の間の通信処理を、主にネットワークの観点から通信セッション単位で記録したデータテーブルである。すなわち本ステップは、端末400と現行システム200の間のデータ入出力を通信セッション単位で再現しようとするものである。図7:ステップS701~S702リプレイテスト実行部142は、現行セッション管理テーブル1111から1レコード分の情報を読み取るS701。現行セッション管理テーブル1111にレコードが記録されていればその情報を取得しS702、記録されていなければステップS706へスキップする。図7:ステップS703現行システムログ情報取得部145は、後述の図9で説明する現行入出力ログ1112を読み込む。現行入出力ログ1112は、端末400と現行システム200の間の通信処理を、主にアプリケーション211に対する入出力データの観点から通信セッション単位で記録したデータテーブルである。現行セッション管理テーブル1111はネットワーク情報を記録しているのに対して、現行入出力ログ1112は入出力データを記録している点が異なる。すなわち、端末400と現行システム200の間の通信処理は、現行セッション管理テーブル1111と現行入出力ログ1112にまたがって記録されている。図7:ステップS704現行システムログ情報取得部145は、ステップS702で取得したレコード内に記録されているセッションIDをキーとして、現行入出力ログ1112の対応するレコードを特定し、そのレコードに記録されている入出力データを取得する。図7:ステップS705~S706リプレイテスト実行部142は、ステップS702~S704で取得した各情報を、後述の図10で説明するリプレイテストシナリオ113に記録するS705。リプレイテスト実行部142は、現行セッション管理テーブル1111が他のセッション記録を保持していればステップS702に戻って同様の処理を繰り返し、保持していなければ本処理フローを終了するS706。図8は、現行セッション管理テーブル1111の構成とデータ例を示す図である。新セッション管理テーブル1121も同様の構成を有する。現行セッション管理テーブル1111は、端末400と現行システム200の間の通信処理を通信セッション単位で記録したデータテーブルであり、新セッションID11111、送信元アドレス11112、宛先アドレス11113、開始時刻11114、終了時刻11115、旧セッションID11116を格納する。新セッションID11111は、新システム300の新WebAPサーバ310が端末400に対して割り当てるセッション識別子を保持する。送信元アドレス11112と宛先アドレス11113は、新セッションID11111の値で識別される通信セッションにおける通信元と通信先それぞれのアドレス情報を保持する。開始時刻11114と終了時刻11115は、新セッションID11111の値で識別されるセッションが開始した時刻と終了した時刻をそれぞれ保持する。旧セッションID11116は、現行システム200のWebAPサーバ210が端末400に対して割り当てるセッション識別子を保持する。リプレイテストシナリオ113を作成する際には、あらかじめ現行システム200を実行して現行システムログ111を生成し、現行セッション管理テーブル1111と現行入出力1112にレコードを格納しておく必要がある。ただしこの時点では、新セッションID11111については空にしておく。テスト支援サーバ100のリプレイテスト実行部142は、ステップS601のリプレイテストを実施する過程で、旧セッションID11116に対応する新セッションID11111の値をセットする。図8の1行目のレコードは、旧セッションID1111646wetj3に対応する現行入出力ログ1112のレコードを用いてリプレイテストを実施した結果、新システム300においては同じ入出力データに対して新セッションID11111abcdefが割り当てられたことが記録されている。新セッションID11111は、旧セッションID11116に対応する通信セッションを新システム300上で再現する際に新システム300が割り当てるセッションIDである。新セッションID11111の値は、現行セッション管理テーブル1111に記録してもよいし、新セッション管理テーブル1121に記録してもよいし、双方に記録してもよい。図9は、現行入出力ログ1112の構成とデータ例を示す図である。新入出力ログ1122も同様の構成を有する。現行入出力ログ1112は、時刻情報11121、セッションID11122、送信元アドレス11123、宛先アドレス11124、シーケンス番号11125、データ11126を格納する。時刻情報11121は、現行システム200に対する端末400からのデータ入出力が発生した時点の時刻を保持する。セッションID11122は、WebAPサーバ210が端末400に対して発行したセッション識別子を保持する。送信元アドレス11123と宛先アドレス11124は、セッションID11122の値で識別される通信セッションにおける通信元と通信先それぞれのアドレス情報を保持する。セッションID11122の値が同じレコードは、端末400が送信元になる場合とそれに対する応答としてWebAPサーバ210が送信元になる場合のいずれかを記録したものである。シーケンス番号11125は、セッションID11122の値で識別される通信セッションのシーケンス番号を保持する。データ11126は、セッションID11122の値で識別される通信セッションにおける現行システム200に対する入力データ又は現行システム200からの出力データを保持する。図9の1行目のレコードと3行目のレコードは、セッションID11121がともに同じabcdefであるため、いずれか一方が現行システム200に対する入力、もう一方が現行システム200からの出力を記録したレコードであると想定される。この場合は1行目のレコードがWebAPサーバ210に対するHTTPPOSTリクエストを記録したレコードであり、3行目のレコードがWebAPサーバ210からの応答を記録したレコードである。図10は、リプレイテストシナリオ113の構成とデータ例を示す図である。リプレイテストシナリオ113は、時間情報1131、セッションID1132、送信元アドレス1133、宛先アドレス1134、データ1135を格納する。時間情報1131は、端末400と新システム300の間の通信セッションを開始する時刻を起点とした、端末400と新システム300の間のデータ入出力を再現実施する時間間隔を示す。セッションID1132は、セッション識別子を保持する。送信元アドレス1133と宛先アドレス1134は、セッションID1132の値で識別される通信セッションにおける通信元と通信先それぞれのアドレス情報を保持する。データ1135は、セッションID1132の値で識別される通信セッションにおける新システム300に対する入力データ又は新システム300からの出力データを保持する。リプレイテスト実行部142は、現行入出力ログ1112からセッションID11122の値をキーにして全ての通信セッションについての入出力データを抽出し、リプレイテストシナリオ113へ記録する。図11は、ステップS601の詳細を示すフローチャートである。以下、図11の各ステップについて説明する。図11:ステップS1100テスト支援サーバ100のリプレイテスト実行部142は、ステップS600で生成したリプレイテストシナリオ113から、リプレイテストを実施していないレコードを1つ読み込む。図11:ステップS1101リプレイテスト実行部142は、リプレイテストシナリオ113の記述にしたがって、新セッション管理テーブル1121の各項目に値をセットする。具体的には、セッションID1132を旧セッションID11116へ、送信側のアドレス情報を送信元アドレス11112へ、受信側のアドレス情報を宛先アドレス11113へ、現在時刻を開始時刻11114へ、それぞれ登録する。新セッションID11111は、本ステップの時点では空にしておく。図11:ステップS1102リプレイテスト実行部142は、リプレイシナリオ113が記述している入力データを新システム300に新たに投入する場合はステップS1103へ進み、その結果を新システム300から受け取る場合はステップS1110へ進む。図11:ステップS1103リプレイテスト実行部142は、リプレイテストシナリオ113から1件分の入力データを読み取る。すなわち、送信元アドレス1133が端末400のアドレスと一致するレコードのデータ1135を読み取る。図11:ステップS1104リプレイテスト実行部142は、ステップS1103で取得した入力データに現行システム200上で割り当てられたセッションIDが含まれており、かつ新システム300上のセッションIDを既に取得している場合は、現行システム200上で割り当てられたセッションIDを新システム300上のセッションIDに書き換える。図11:ステップS1105リプレイテスト実行部142は、現在時刻を取得する。図11:ステップS1106リプレイテスト実行部142は、ステップS1103で取得したレコードの時間情報1131が指定する時刻になるまで待機した後、新WebAPサーバ310へ入力データを送信することにより、現行システム200に対するデータ入力処理を再現する。図11:ステップS1107リプレイテスト実行部142は、ステップS1106で新WebAPサーバ310へ送信した入力データを、新入出力ログ1122へ記録する。図11:ステップS1108~S1109リプレイテスト実行部142は、リプレイテストシナリオ113の件数カウントnを1インクリメントするS1108。リプレイテストシナリオ113が記述している全ての通信セッションについてリプレイテストを完了した場合はステップS1112へ進み、残っている場合はステップS1102に戻って同様の処理を繰り返す。図11:ステップS1110リプレイテスト実行部142は、現在時刻を取得する。図11:ステップS1111リプレイテスト実行部142は、新WebAPサーバ310がステップS1106に対する応答として出力したデータを受信し、新入出力ログ1122へ記録する。図11:ステップS1112~S1113リプレイテスト実行部142は、現在時刻を取得して新セッション管理テーブル1121へ記録するS1112。リプレイテストシナリオ113に登録されている全ての通信セッションのテストが終了もしくはユーザによりリプレイテストの終了が指示された場合は本処理フローを終了し、リプレイテストを継続する場合はステップS1100に戻って同様の処理を繰り返す。図12は、ステップS607の詳細を示すフローチャートである。以下、図12の各ステップについて説明する。なお、本処理フローを実施するに先立ち、あらかじめ現行システム200と新システム300からそれぞれ実行結果トレースを取得し、これらをまとめて現行テストログ1113と新テストログ1124を生成しておく必要がある。現行テストログ1113と新テストログ1124のフォーマットは図5で説明した新トレースログ1123と同様であるため、以下の説明において現行テストログ1113と新テストログ1124が備える各項目について言及するときは、新トレースログ1123が備える項目と同じ符号を用いる。図12:ステップS1200テスト支援サーバ100の現行システムログ情報取得部145は、現行テストログ1113を取得する。図12:ステップS1201~S1202差分抽出部146は、現行テストログ1113から1レコード1通信セッション分のログデータを読み込むS1201。差分抽出部146は、ステップS1201で読み込んだログデータからセッションID112304を取得するS1202。図12:ステップS1203差分抽出部146は、ステップS1202で取得したセッションIDをキーにして新セッション管理テーブル1121と新テストログ1124を検索し、対応するレコードを特定する。差分抽出部146は、特定したレコードを読み込む。図12:ステップS1204差分抽出部146は、ステップS1203で読み込んだ新テストログ1124のレコードに改修タグ112313が記録されているかどうかをチェックする。改修タグ112313が記録されている場合はステップS1208へ進み、記録されていない場合はステップS1205へ進む。図12:ステップS1205差分抽出部146は、ステップS1203で読み込んだ新テストログ1124のレコードにおけるモジュール名112307及び処理コード112308が、ステップS1201で読み込んだ現行テストログ1113のレコードにおけるモジュール名112307及び処理コード112308と同じであるか否かをチェックする。同じである場合はステップS1206へ進み、異なる場合はステップS1209へ進む。図12:ステップS1206差分抽出部146は、ステップS1203で読み込んだ新テストログ1124のレコードにおける入力引数112310が、ステップS1201で読み込んだ現行テストログ1113のレコードにおける入力引数112310と同じであるか否かをチェックする。同じである場合はステップS1207へ進み、異なる場合はステップS1209へ進む。図12:ステップS1207差分抽出部146は、ステップS1203で読み込んだ新テストログ1124のレコードにおける出力値112311が、ステップS1201で読み込んだ現行テストログ1113のレコードにおける出力値112311と同じであるか否かをチェックする。同じである場合はステップS1208へ進み、異なる場合はステップS1209へ進む。図12:ステップS1208差分抽出部146は、ステップS1203で読み込んだ新テストログ1124のレコードを、現行テストログ1113と新テストログ1124の間の差分を比較する対象から除外する。差分抽出部146は、アプリケーション211のソースコードが修正されているか、又は修正されたソースコードが別の箇所で利用されていることを示すため、当該ログコードの差分情報として、アプリケーション211が改修されている旨の情報を記録する。図12:ステップS1209差分抽出部146は、新テストログ1124と現行テストログ1113を、APIフラグ112312が記録されているログデータまで読み込み、それまでのログデータを差分情報内に記録する。図12:ステップS1209:補足本ステップは、現行入出力ログ1112と新入出力ログ1122が異なる部分のうち、改修タグが付加されていない部分についてのみ実施されるため、結果として現行システム200と新システム300の間の相違点のみを抽出して差分ログに記録することになる。図12:ステップS1210差分抽出部146は、ステップS1201で読み込んだセッションIDに対応する全てのレコードについて比較完了するまで、ステップS1203~S1209までの処理を繰り返し実行する。<実施の形態1:まとめ>以上のように、本実施形態1に係るテスト支援サーバ100は、現行入出力ログ1112と新入出力ログ1122の間に差分がある場合は、実行結果トレース現行テストログ1113と新テストログ1124に基づき、アプリケーション211のソースコードが改修されているか否かを判定する。改修されている場合は、その改修部分については現行システム200と新システム300を比較する対象から除外する。これにより、現行システム200と新システム300の間の相違原因を特定するにあたり、アプリケーション211の改修による影響を切り分けることができる。特に、ユーザがアプリケーション211を改修した場合において、その部分の影響を除外することができる。また、本実施形態1に係るテスト支援サーバ100は、アプリケーション211のうち改修されている部分のコードが、所定のミドルウェア等のAPI2125を利用しているか否かを、実行結果トレースに基づき判定する。これにより、現行システム200と新システム300の間に相違がある場合、その相違が当該ミドルウェア等を更改したことによるものであるか否かを推定することができる。また、本実施形態1に係るテスト支援サーバ100は、現行システム200が発行したセッションIDと新システム300が発行したセッションIDの対応関係を、現行セッション管理テーブル1111又は新セッション管理テーブル1121に記録する。セッションIDは一般にランダムな文字列などを用いて作成されるため、現行システム200と新システム300は、入出力データが同じであってもそれぞれ異なるセッションIDを発行する可能性があるが、これらの対応関係を管理しておくことにより、セッションIDをキーにして両者を関連付け、同じ入出力処理を再現することができる。<実施の形態2>実施形態1では、現行システム200と新システム300がWebアプリケーションを提供する例を説明したが、その他の種類のアプリケーションについても、実施形態1と同様の手法を用いることができる。例えば、クライアント/サーバ型のアプリケーション、スタンドアロン型のアプリケーションなどについて、実施形態1の手法を用いることができる。この場合、新トレースログ1123内のセッションID112304を用いて各入出力処理を特定することに代えて、例えばプロセスID112302などを用いて各入出力処理を特定することができる。また、実施形態1ではミドルウェアのAPI2125を利用するか否かを判定しているが、これに限らずその他のAPIを利用するか否かを判定するようにしてもよい。例えば新システム300において新WebAPサーバ310外のアプリケーションを更改する場合は、アプリケーション211がそのアプリケーションのAPIを利用しているか否かを判定するようにしてもよい。以上説明した各構成、機能、処理部などは、それらの全部又は一部を、例えば集積回路で設計することによりハードウェアとして実現することもできるし、プロセッサがそれぞれの機能を実現するプログラムを実行することによりソフトウェアとして実現することもできる。各機能を実現するプログラム、テーブルなどの情報は、メモリやハードディスクなどの記憶装置、ICカード、DVDなどの記憶媒体に格納することができる。以上、本発明者によってなされた発明を実施形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。