プログラムと前記プログラム上で実行されるアプリケーションを格納する記憶装置を備えた情報処理装置における不良該非判定手法おいて、前記プログラムの提供するアプリケーションインタフェース以下、APIと略に不良を検出した場合に、暗号化した設定ファイルを含む前記プログラムを配布し、前記設定ファイルを前記プログラムに読み込ませて、前記プログラムがメモリ上の前記APIのバイトコードにログ取得処理を埋め込むことで前記作成された情報処理システムにて使用しているか否かを判定し、前記APIを使用しているか否かの判定は前記プログラム上で前記アプリケーションを実行することで判定し、前記APIを使用している場合は前記APIの呼び出し回数、呼び出しトレースをログ出力することにより前記ユーザが前記情報処理システムへの影響を判断できるように出力することを特徴とする不良該非判定手法。ユーザの有する情報処理システムユーザシステムと省略するが自システムで不良APIを使用しているか否かはシステムを構成するアプリケーションプログラムのソースコードが不良APIを使用して実装されているか否かを調査する。しかし、プログラムの提供するAPIの不良がセキュリティに関わる問題であった場合、セキュリティ攻撃の手法を公開することになるため、不良APIや不良の発生条件といった詳細情報をプログラムのユーザに提供できない。そのため、ユーザシステムが自システムで不良APIを使用しているかが分からず、修正版の適用判断ができない。ユーザシステムを構成するプログラムのソースコードを所持していなくても該非判定を行い、また、情報処理システムは様々なプログラム部品を使用して実装されており、ユーザシステムは必ずしも自システムを構成する全てのプログラムのソースコードを所持していない。そのため、自システムで不良APIを使用しているかが不明な場合がある。本発明の目的は、プログラムの提供するAPIに不良が判明した時に、ユーザシステムで発生条件を知らなくても、ユーザシステムの該非判定を行えるようにすることである。上記目的を達成するために、本発明では不良APIを含むプログラムの提供元が不良の概要情報と不良APIの詳細情報を暗号化した判定用設定ファイルとをネットワークを介してユーザシステムに提供し、ユーザシステムに判定用設定ファイルをAPIの提供元であるプログラムに読み込ませ、プログラムはファイルを復号化して不良情報を読み取り、プログラム実行時に不良APIを含むクラスが主記憶装置上にロードされるタイミングで主記憶装置上の不良APIのバイトコードを書き換え、該非判定のためのログ情報を取得する処理を埋め込み、ユーザシステムが処理を実行して不良APIが実行された時に取得したログ情報をユーザシステムに判定結果ログとしてファイル形式で提供し、ユーザシステムは判定結果ログファイルを参照して自システムへの影響を確認し、プログラムの修正版適用を判断する。APIを提供するプログラムを使用している情報処理システムにて、APIに不良が発生した場合にユーザシステムが発生条件を知らなくても不良の該非判定を実施することが可能となる。以下、本発明を実施するための形態以下実施形態というについて、図面を参照して説明する。図1は本実施形態における情報処理システムの装置構成の概要を示す説明図である。図1に示すように本実施形態ではプログラム提供元の計算機10とユーザが使用する計算機120がネットワーク11を通じて接続される。プログラム提供元の計算機10はユーザが使用する計算機120に対して不良APIの情報を情報発信する。ユーザの計算機120は複数存在してもよい。プログラム提供元の計算機10は、通信アダプタ50、CPU30、入力装置40、出力装置20、補助記憶装置90および主記憶装置60を備え、バス100を介して互いに接続される。通信アダプタ50を利用してユーザが使用する計算機120へ接続し、判定用設定ファイル400と不良情報300とを送信する。ユーザが使用する計算機120は、通信アダプタ51、CPU31、入力装置41、出力装置21、補助記憶装置91および主記憶装置140とを備え、バス101を介して互いに接続される。通信アダプタ51を使用してプログラム提供元の計算機10と通信を行う。出力装置20はプログラム提供元の計算機10から出力される情報を表示する。各処理部は、プログラムやオブジェクト、もしくは同等の機能を有するハードウェアで実現できる。本実施例は、各処理部がプログラムで実現された一例を示している。CPU30は主記憶装置60に記憶された各種処理部を実行することによって各種処理を実行する。入力装置40はプログラム提供元の計算機10に必要な情報および指示の入力に使用する。通信アダプタ50はネットワーク11を介して通信アダプタ51と通信する。主記憶装置60はファイル暗号化処理部70と情報発信処理部80を含む。プログラム提供元の計算機10は主記憶装置60上でユーザの計算機10へ判定用設定ファイル400と不良情報300を送信するための処理を行う。ファイル暗号化処理部70は判定用設定ファイル400を生成し、セキュリティ問題が含まれる場合には判定用設定ファイル400を暗号化する。情報発信処理部80はプログラム提供元の計算機10からユーザの計算機120へ不良情報300と判定用設定ファイル400を送信する。補助記憶装置90はプログラム提供元の計算機10上でプログラム及びプログラムの実行に必要なデータを格納する。判定用設定ファイル400は補助記憶装置90に含まれる。出力装置21はユーザの計算機120から出力される情報を表示する。CPU31は主記憶装置61に記憶された各種プログラムを実行することによって各種処理を実行する。入力装置41はユーザの計算機10に必要な情報および指示の入力に使用する。通信アダプタ51はネットワーク11を介して通信アダプタ50と通信する。主記憶装置61はプログラム実行処理部150を含む。不良の該非判定のための処理は主記憶装置61上で行われる。プログラム実行処理部150はクラスロード処理部151、バイトコード書換部152、該当バージョン判定部153、ファイル復号化処理部154、ログ出力処理部155、ユーザ処理部156、バイトコード格納部170を含む。クラスロード処理部151はAPI処理部161が必要とするクラスをバイトコード格納部170へ読み込む。読み込む際、該当バージョン判定部153を呼び出し、不良の該当バージョン判定を行い、該当し、かつロード対象クラスが不良APIを含む場合はバイトコード書換部を呼び出し、ロード対象クラスのバイトコードを書き換える。バイトコード書換部152はバイトコード格納部170に読み込まれたAPI160に判定フラグ処理部162を埋め込む。さらに、不良がセキュリティ問題でない場合は、呼出回数カウント部163、トレース取得部164、不良箇所実行回数カウント部165を埋め込む。該当バージョン判定部153はユーザの計算機120上で動作するプログラムが不良が存在するバージョンに該当しているか判定する。ファイル復号化処理部154は判定用設定ファイル400が暗号化されている場合、復号化処理を行う。ログ出力処理部155は判定結果ログファイル700を出力する。ユーザ処理部156はAPI処理部161を使用してユーザプログラムの実行処理を行う。API処理部161はユーザプログラムの実行処理を行う。判定フラグ処理部162は不良APIが実行された時に判定ログ保存テーブル500に該当フラグを保存する。呼出回数カウント部163は不良APIが実行された回数を判定ログ保存テーブル500に保存する。トレース取得部164は不良APIが実行された時のスレッドスタックトレースを取得し、トレース保存テーブル600に保存する。不良箇所実行回数カウント部165は不良APIの不良箇所が実行された回数をカウントし、判定ログ保存テーブル500に保存する。バイトコード格納部170はAPI160を含む。クラスロード処理部151によってロードされたAPIを格納する。不良情報300は不良の概要を含み、情報発信処理部80によってプログラム提供元からユーザへ送付される。判定用設定ファイル400は不良APIの詳細情報を格納する。プログラム実行処理部150がプログラムを実行する際に読み取る。判定ログ保存テーブル500は判定フラグ処理部162、呼出回数カウント部163、不良箇所実行回数カウント部165で取得したログ情報を保存する。トレース保存テーブル600はトレース取得部164で取得したログ情報を保存する。判定結果ログファイル700は判定ログ保存テーブル500、トレース保存テーブル600に保存された情報を格納する。図2は本実施形態における不良の該非判定を行う処理の流れの一例を示す説明図である。まず、プログラム提供元200は判定用設定ファイル400と不良情報300をユーザが使用する計算機210へ送付する201。次に、ユーザが使用する計算機210はプログラム実行処理部150を判定モードで起動する211。判定モードで起動されるとプログラム実行処理部150は起動時に判定用設定ファイル400を読み込む221。読み込みが終わると該当バージョン判定部153が、不良に該当するバージョン、オプション設定となっているか判定する222。判定が終わるとプログラム実行処理部150はユーザが使用する計算機210へ起動完了した旨を通知する223。起動完了の通知を受けるとユーザ210はアプリケーション処理を実行する212。アプリケーション処理の実行によりクラスをロードする必要が生じるとプログラム実行処理部150はクラスロード処理を行う224。クラスロード処理ではプログラム実行処理部150は不良APIのバイトコードへログ取得処理を埋め込む225。アプリケーション処理実行212により、ログ取得処理を埋め込んだAPIが実行されるとログが取得される226。アプリケーション処理実行が終わるとユーザが使用する計算機210はプログラム実行処理部に対してログ出力要求を行う213。ユーザが使用する計算機210からログ出力要求を受け取るとプログラム実行処理部150は判定結果ログファイル700を出力する227。ログ出力が終わるとプログラム実行処理部150はユーザが使用する計算機210へログ出力の終了を通知する228。ログ出力終了を通知されるとユーザが使用する計算機210は判定結果ログファイル700を確認する214。ユーザが使用する計算機210はログから修正版を適用するかしないか判断する215。修正版を適用すると判断した場合はユーザが使用する計算機210はプログラム提供元200へ修正版の提供を要求する216。ユーザが使用する計算機210から修正版要求を受けるとプログラム提供元200はユーザが使用する計算機210へ修正版を提供する202。修正版を提供されたらユーザが使用する計算機210は修正版を適用する217。以上で不良の該非判定は完了する218。図3は本実施形態におけるプログラム提供元からユーザに通知される不良情報300の一例を示す説明図である。ユーザは、ユーザが使用する計算機210より、判定結果ログファイル700と不良情報300の情報を元に自システムでの不良の影響度を判定する。不良情報300は修正ID310、現象320、発生条件330、該当バージョン340、修正バージョン350を含む。修正ID310は不良を識別するためのIDを表示する。IDは不良毎に固有の値を有する。現象320は不良が発生した場合の現象を表示する。320Aでは詳細な現象を表示する。発生条件330は不良の発生条件を表示する。330Aは不良に該当するオプション設定を表示した例、330Bは不良を含むAPIを表示した例である。セキュリティ問題の場合は非公開となる。該当バージョン340は不良が存在するプログラムのバージョン情報を表示する。340Aは該当バージョンの表示例である。修正バージョン350は不良が修正されたプログラムのバージョン情報を表示する。350Aは修正バージョンの表示例である。図4は本実施形態における判定用設定ファイル400の一例を示す説明図である。判定用設定ファイル400は不良の該当するバージョンや不良の存在するAPIの情報が記載されており、プログラム実行処理部150が不良の該非判定のためのログ出力処理をどのクラスのどのAPIに埋め込むかを判断するのに用いる。判定用設定ファイル400は修正ID410、該当VRS420、該当オプション430、該当API440、不良箇所のインデックス450、セキュリティ460を含む。判定用設定ファイル440はプログラム実行処理部150が判定モードで起動した時にプログラム実行処理部150によって読み込まれ、不良APIのバイトコードに該非判定のためのログ取得処理を埋め込むために使用される。修正ID410は不良の識別ID情報である。該当VRS420は不良に該当するプログラムのバージョン情報である。該当バージョン判定部153によってプログラムのバージョンが該当バージョンであるか判定するために使用される。該当オプション430は不良に該当するオプション設定の情報である。該当バージョン判定部153によって不良に該当するオプションがプログラムに設定されているか判定するために使用される。該当API440は不良を含むAPIの情報である。クラスロード処理部151がクラスをロードする時にロード対象クラスが不良APIを含むか判定するために使用される。不良箇所のインデックス450は不良APIのバイトコード中の不良箇所のインデックスである。バイトコード書換部152は不良箇所のインデックス450から不良APIの不良箇所を特定し、不良箇所実行回数カウント部を不良APIのバイトコードに埋め込む。セキュリティ460は不良がセキュリティ問題であるか否かを示し、判定ログ保存テーブル500のセキュリティフラグ520に読み込まれる。図5は本実施形態における判定ログ保存テーブル500の一例を示す説明図である。判定ログ保存テーブル500はプログラム実行中にプログラム実行処理部150が不良APIの実行状況を保存しておくテーブルである。判定ログ保存テーブル500は主記憶装置140上に存在し、ログ出力処理部155が判定結果ログファイル700を出力する際に参照される。判定ログ保存テーブル500は修正ID510、セキュリティフラグ520、コード書換フラグ530、判定フラグ540、API呼出回数550、不良箇所実行回数560を含む。修正ID510は不良を識別するIDである。セキュリティフラグ520は修正ID510の不良がセキュリティ問題であるか否かを表す。Yであればセキュリティ問題であることを表し、Nであればセキュリティ問題ではないことを表す。バイトコード書換部152が不良APIに呼出回数カウント部163、トレース取得部164、不良箇所実行回数カウント部165を埋め込むか否かを判定するのに用いる。コード書換フラグ530はクラスロード処理部151が修正ID510の不良APIのバイトコード書換処理をバイトコード書換処理部152に行わせるか否かを表す。Yであればバイトコード書換を行い、Nであればバイトコード書換を行わない。コード変換フラグは該当バージョン判定部153によって更新され、プログラムが修正ID510の該当バージョンであり、かつ該当オプションである場合のみYとなる。判定フラグ540はプログラムが修正ID510の不良に該当しているかどうかを表す。Yであれば不良に該当していることを表し、Nであれば不良に該当していないことを表す。判定フラグ処理部162によって更新され、ユーザ処理部156によって不良APIが実行された場合のみYとなる。API呼出回数550は修正ID510の不良APIがプログラム実行中に何回呼び出されたかを表す。呼出回数カウント部163によって更新される。不良箇所実行回数560は修正ID510の不良APIのバイトコードのうち、不良箇所が何回実行されたかを表す。不良箇所実行回数カウント部によって更新される。図6は本実施形態におけるトレース保存テーブル600の一例を示す説明図である。トレース保存テーブル600はプログラム実行中にトレース取得部164が取得した不良APIの呼び出しトレースを保存するテーブルである。トレース保存テーブル600は主記憶装置140上に存在し、ログ出力処理部155が判定結果ログファイル700を出力する際に参照される。修正ID610と呼び出しトレース620を含む。修正ID610は不良を識別するIDである。呼び出しトレース620は不良APIが呼び出された時のスタックトレースを表す。トレース取得部164によって更新される。図7は本実施形態における判定結果ログファイル700の一例を示す説明図である。判定結果ログファイル700は不良の該非判定結果を出力したログファイルである。半知恵結果ログファイル700をユーザが参照し、修正版の適用判断を行う。判定結果ログファイル700は修正ID710、判定720、API呼び出し回数730、不良箇所実行回数740、呼び出しトレース750を含む。判定結果ログファイル700はログ出力処理部155によって出力される。修正ID710は不良を識別するIDである。判定ログ保存テーブル500の修正ID510の値が出力される。判定720は修正ID710の不良に該当するか否かを表し、判定ログ保存テーブル500の判定フラグ540の値が反映される。具体的には判定フラグ540がYであれば、判定720は該当となり、判定フラグ540がNであれば判定720は非該当となる。API呼び出し回数730は修正ID710の不良APIがプログラム実行中に何回呼び出されたかを表す。判定ログ保存テーブル500のAPI呼び出し回数550の値が出力される。不良箇所実行回数740は修正ID710の不良APIがプログラム実行中に何回呼び出されたかを表す。判定ログ保存テーブル500の不良箇所実行回数560の値が出力される。呼び出しトレース750は不良APIが呼び出された時のスタックトレースを表す。トレース保存テーブル600の呼び出しトレース610の内容が出力される。760、770、780はトレースを表している。780のAPIから770のAPI、770のAPIから760のAPIが呼び出されていることを表す。図8は本実施形態における非セキュリティ問題の不良APIのメモリ上でのコードイメージ800の一例を示す説明図である。判定ログ保存テーブル500のセキュリティフラグ520がNであり、コード書換フラグがYとなる不良に対して、バイトコード書換部152がバイトコード書換を行ったクラスのソースコードのイメージである。非セキュリティ問題のコードイメージ800では不良APIを含むクラスのイメージを表している。一行目ではクラス名が記述されておりステップ810、2行目では不良APIの名称が宣言されているステップ820。不良APIのコードの先頭からは順に判定フラグ処理部162ステップ830、呼び出し回数カウント部163ステップ840、トレース取得部164が埋め込まれる。If文860は条件分岐を表しており、条件文がtrueの場合のみ括弧内の処理が実行される。不良箇所ステップ880の直前に不良箇所実行回数カウント部165が埋め込まれるステップ870。図9は本実施形態におけるセキュリティ問題の不良APIのメモリ上でのコードイメージ900の一例を示す説明図である。判定ログ保存テーブル500のセキュリティフラグ520がYであり、コード書換フラグがYとなる不良に対して、バイトコード書換部152がバイトコード書換を行ったクラスのソースコードのイメージである。セキュリティ問題のコードイメージ900では不良APIを含むクラスのイメージを表している。一行目ではクラス名が記述されておりステップ810、2行目では不良APIの名称が宣言されているステップ820。不良APIのコードの先頭には判定フラグ処理部162が埋め込まれるステップ830。図10は本実施形態における情報発信処理時のフローチャート1000である。プログラム提供元の計算機10がユーザの計算機120へ判定用設定ファイル400と不良情報300を送信する際の流れを示したものである。情報発信処理1000は図2でプログラム提供元200によって実行される処理201の詳細である。情報発信処理1000を行う時はまずファイル暗号化処理部70が判定用設定ファイル400を作成するステップ1010。次に、判定用設定ファイル400がセキュリティ問題を含むか判定するステップ1020。具体的には判定用設定ファイル400のセキュリティ460を確認し、Yの不良が存在するか判定する。セキュリティ問題を含む場合はファイル暗号化処理部70が判定用設定ファイル400を暗号化しステップ1030、セキュリティ問題を含まない場合は暗号化を行わない。最後に判定用設定ファイル400と不良情報300をユーザへ発信する。判定用設定ファイル400を暗号化することでユーザから読み取れないようにし、ユーザにセキュリティ問題の発生条件を知られないという目的を達成する。図11は本実施形態における判定モード処理時のフローチャートである。ユーザが不良の該非判定を行う際にプログラム実行処理部150が実行する処理を説明した図である。判定モード処理1100は図2でユーザ210がプログラム実行処理部150に対して要求する処理である。プログラム実行処理部150を判定モードで起動するとまずファイル復号化処理部154が判定用設定ファイル400を読み込むステップ1110。ファイル復号化処理部154は判定用設定ファイル400が暗号化されているかを判断しステップ1120、暗号化されていれば復号化するステップ1130。次に判定ログ保存テーブル500のセキュリティフラグ520を設定するステップ1140。具体的には判定用設定ファイル400のセキュリティ460の値を各修正ID毎にセキュリティフラグ520に設定する。セキュリティフラグ520を設定すると、該当バージョン判定部153が該当するバージョンかを判定するステップ1150。該当しないバージョンである場合は該当バージョン判定部153は判定ログ保存テーブル500のコード書換フラグ530をNに設定する。次に、該当するオプションが設定されているかを判定するステップ1160。ただし、1150で該当するバージョンでないと判定された場合はオプションの判定ステップ1160は行わない。該当するオプションが設定されていない場合は該当バージョン判定部153は判定ログ保存テーブル500のコード書換フラグ530をNに設定する。次に、ユーザ処理部156がアプリケーション操作を開始するステップ1180。アプリケーション操作によってクラスロードが必要になると、クラスロード処理部151がクラスロード処理を行うステップ1190。クラスロード処理1190では不良APIにログ取得処理が埋め込まれる。詳細は図12で説明する。クラスロード処理1190が終わるとAPI処理部161によってAPIが実行されるステップ1101。API実行時に不良APIに埋め込まれたログ取得処理によってログ取得が実行される。全てのアプリケーション操作が終了するステップ1102と、ログ出力処理部155が判定結果ログファイル700を出力する。具体的には判定ログ保存テーブル500とトレース保存テーブル600に取得された情報を判定結果ログファイル700に出力する。判定結果ログファイル700の出力が終了すると判定モードでの処理が終了する。図12は本実施形態におけるクラスロード処理1190のフローチャートである。プログラム実行処理部150でプログラム実行中に新たなクラスロードが必要になった際に実施される処理を示した図である。クラスロード処理1190はアプリケーション実行時に必要となったクラスをロードし、不良APIのバイトコードを書き換える処理であり、図11に示す判定モード処理1100で呼び出される。クラスロード処理部151はまずロード対象クラスをバイトコード格納部170に読み込むステップ1200。次にロード対象クラスが不良APIを含むかを確認するステップ1210。具体的には判定用設定ファイル400の該当API440に記載されたAPIをロード対象クラスが含むかを確認する。含まない場合はクラスロード処理を終了する。不良APIを含む場合は次に判定ログ保存テーブル500のコード書換フラグ530を確認しステップ1220、フラグがNであれば、クラスロード処理を終了する。Yであれば不良APIに判定処理コードを埋め込む処理ステップ1230を行う。埋め込みが終了するとクラスロード処理を終了する。図13は本実施形態における不良APIに判定処理コードを埋め込む処理1230のフローチャートである。不良APIにログ取得処理を埋め込む処理であり、これにより不良APIがAPI処理部161によって実行されるとログが取得できる。不良APIに判定処理コードを埋め込む処理1230は図12に示すクラスロード処理1190から呼び出される。まず、バイトコード書換部152が不良APIの先頭に判定フラグ処理部162を埋め込むステップ1300。これにより、API処理部161によって不良APIが実行されると判定ログ保存テーブル500の判定フラグ540がYに更新される。次に、判定ログ保存テーブル500のセキュリティフラグ520を確認し、不良APIがセキュリティ不良のAPIであるか判定するステップ1310。セキュリティ問題である場合は不良APIに判定処理コードを埋め込む処理を終了する。セキュリティ問題でない場合は続いて呼出回数カウント処理部を埋め込むステップ1320。これにより、API処理部161によって不良APIが実行されると判定ログ保存テーブル500のAPI呼び出し回数550がインクリメントされる。続いて、バイトコード書換部152は不良APIにトレース取得処理部164を埋め込むステップ1330。API処理部161によって不良APIが実行されるとトレース取得処理部164によって呼び出し時のスタックトレースが取得され、トレース保存テーブル600の呼び出しトレース620に保存される。以上の処理が終わると最後にバイトコード書換部は判定用設定ファイル400の不良箇所のインデックス450の箇所に不良箇所実行回数カウント部163を埋め込むステップ1340。API処理部161によって不良APIが実行され、かつ不良箇所が実行されると、判定ログ保存テーブル400の不良箇所実行回数560の値がインクリメントされる。本実施形態は、単純に不良APIが使用されただけでは問題とならず、タイミングの問題であればAPIの実行回数が多いか少ないかが重要となる。また、メモリリークの不良のように複数回実行されることで問題が顕在化する場合があるため、そのような場合は不良APIの不良箇所を実行した回数が重要となる。また、不良APIの呼び出し箇所が特定できれば不良APIを呼び出さないようにコード修正するなどの回避が可能になる。また、呼び出し箇所の処理の重要性から不良がシステムに与える影響を判断できる。また、ユーザが自システムを構成するプログラムのソースコードを所持していない場合も該非判定が可能になる。また、不良APIの実行回数、呼び出しトレースを取得することにより、不良がシステムに与える影響をユーザが確認することができる。