(57)【特許請求の範囲】
【請求項１】
商品に対する申込内容についての適否を前記商品の属性に基づいて判定するための判定規則が既存の商品ごとに記述されたソースコードを入力して抽象構文木を生成する構文解析部と、
生成された抽象構文木を利用してネスト構造を解析することで、前記既存の商品ごとにおける前記属性間の順序関係を設定するネスト構造解析部と、
設定された前記属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する優先順設定部と、
前記属性ごとに設定された優先順と、前記既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、前記既存の商品のうちから新商品に最も類似する類似商品を判定する類似商品判定部と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記ソースコードにおいて前記類似商品の判定規則が記述されている箇所に基づいて、前記新商品の判定規則の追加のために前記ソースコードにおいて変更すべき内容を判定する変更判定部をさらに備える、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記ネスト構造解析部は、
前記ソースコードにおいて属性を含む条件式の内容に基づいて前記既存の商品ごとにおける属性に重み付け値を設定することにより前記属性間の順序関係を設定し、
前記優先順設定部は、
前記既存の商品ごとにおける属性に設定された重み付け値に基づいて前記ソースコードに記述される属性ごとの優先順を設定し、
前記類似商品判定部は、
前記新商品と前記既存の商品の各々とで内容が一致する属性に設定された前記重み付け値に基づいて求めた類似度が最も高い既存の商品を前記類似商品として判定する、
ことを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記ネスト構造解析部は、
同じ階層において複数の条件文に同じ属性が含まれている場合、前記同じ属性についての重み付け値を大きく変更するように設定する、
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記ネスト構造解析部は、
条件式に含まれる属性についての真偽を示す値が複数である場合、前記属性についての重み付け値を小さく変更するように設定する、
ことを特徴とする請求項３または４に記載の情報処理装置。
【請求項６】
前記優先順設定部は、
前記ネスト構造として解析された前記属性間の順序関係についての推移律に基づいて前記優先順を設定し、
前記類似商品判定部は、
前記優先順が高い方から順に、前記新商品と前記既存の商品の各々とで属性の内容が不一致となるまで属性の内容を比較した結果、内容が一致する属性の数が最も多い既存の商品を前記類似商品として判定する、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項７】
前記ネスト構造解析部は、
前記ソースコードにおいて属性を含む条件式の内容に基づいて前記既存の商品ごとにおける属性に重み付け値を設定することにより前記属性間の順序関係を設定し、
前記優先順設定部は、
前記推移律に基づいて前記優先順を設定した結果、優先順が同じとなった複数の属性については、これら複数の属性に設定された前記重み付け値を利用して異なる優先順を設定する、
ことを特徴とする請求項６に記載の情報処理装置。
【請求項８】
商品に対する申込内容についての適否を前記商品の属性に基づいて判定するための判定規則が既存の商品ごとに記述されたソースコードを入力して抽象構文木を生成する構文解析ステップと、
生成された抽象構文木を利用してネスト構造を解析することで、前記既存の商品ごとにおける前記属性間の順序関係を設定するネスト構造解析ステップと、
設定された前記属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する優先順設定ステップと、
前記属性ごとに設定された優先順と、前記既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、前記既存の商品のうちから新商品に最も類似する類似商品を判定する類似商品判定ステップと、
を備えることを特徴とする情報処理方法。
【請求項９】
コンピュータに、
商品に対する申込内容についての適否を前記商品の属性に基づいて判定するための判定規則が既存の商品ごとに記述されたソースコードを入力して抽象構文木を生成する構文解析ステップと、
生成された抽象構文木を利用してネスト構造を解析することで、前記既存の商品ごとにおける前記属性間の順序関係を設定するネスト構造解析ステップと、
設定された前記属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する優先順設定ステップと、
前記属性ごとに設定された優先順と、前記既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、前記既存の商品のうちから新商品に最も類似する類似商品を判定する類似商品判定ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法およびプログラムに関する。
【背景技術】
【０００２】
金融商品や保険商品（以下、単に「商品」ともいう）などを顧客が契約しようとする際には、例えば、顧客が申込書に記入した各種の契約内容や個人情報などの申込内容が、顧客が契約しようとしている商品の契約条件に適合するか否かを審査することが行われる。このような審査のチェック項目は多数であるうえに、取り扱う商品の種類や数も多いため、人的作業では非常に時間がかかってしまう。
そこで、基本的な審査をシステム上で機械的に実施するようにされた生命保険会社向けの新契約システムが知られている（例えば、非特許文献１参照）
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】本多 正憲、“金融業界の業務とシステムを知る Part10 生保編（2） 契約業務の効率化に不可欠な基幹系システムの仕組みを知る”、［online］、nikkei BPnet、［平成２４年４月１９日検索］、インターネット（URL:http://itpro.nikkeibp.co.jp/article/lecture/20070301/263653/?ST=lecture）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
例えば、金融商品や保険商品などにおいて新商品が発売された場合には、この新商品にも対応して申込内容の適否をチェックできるように審査用のプログラムを変更することになる。
これらの商品は類似のものが多く存在している。このために、例えば保守性などを考慮してソースコードを効率よく変更しようとすれば、類似した商品を的確に特定することが必要になる。このため、新商品に応じてソースコードの変更を行うエンジニアは商品について十分な知識を有している必要がある。しかし、現実においてこのようなエンジニアを確実に確保することは難しいということもあり、ソースコード変更作業の効率を妨げている。
【０００５】
本発明は、このような事情に鑑みてなされたもので、商品知識を必要とすることなく、商品契約のための申込内容の適否を判定するプログラムを新商品に応じて効率的に変更できるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決するために、本発明の一態様としての情報処理装置は、商品に対する申込内容についての適否を前記商品の属性に基づいて判定するための判定規則が既存の商品ごとに記述されたソースコードを入力して抽象構文木を生成する構文解析部と、生成された抽象構文木を利用してネスト構造を解析することで、前記既存の商品ごとにおける前記属性間の順序関係を設定するネスト構造解析部と、設定された前記属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する優先順設定部と、前記属性ごとに設定された優先順と、前記既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、前記既存の商品のうちから新商品に最も類似する類似商品を判定する類似商品判定部とを備える。
【０００７】
また、本発明の情報処理装置において、前記ソースコードにおいて前記類似商品の判定規則が記述されている箇所に基づいて、前記新商品の判定規則の追加のために前記ソースコードにおいて変更すべき内容を判定する変更判定部をさらに備える。
【０００８】
また、本発明の情報処理装置において、前記ネスト構造解析部は、前記ソースコードにおいて属性を含む条件式の内容に基づいて前記既存の商品ごとにおける属性に重み付け値を設定することにより前記属性間の順序関係を設定し、前記優先順設定部は、前記既存の商品ごとにおける属性に設定された重み付け値に基づいて前記ソースコードに記述される属性ごとの優先順を設定し、前記類似商品判定部は、前記新商品と前記既存の商品の各々とで内容が一致する属性に設定された前記重み付け値に基づいて求めた類似度が最も高い既存の商品を前記類似商品として判定する。
【０００９】
また、本発明の情報処理装置において、前記ネスト構造解析部は、同じ階層において複数の条件文に同じ属性が含まれている場合、前記同じ属性についての重み付け値を大きく変更するように設定する。
【００１０】
また、本発明の情報処理装置において、前記ネスト構造解析部は、条件式に含まれる属性についての真偽を示す値が複数である場合、前記属性についての重み付け値を小さく変更するように設定する。
【００１１】
また、本発明の情報処理装置において、前記優先順設定部は、前記ネスト構造として解析された前記属性間の順序関係についての推移律に基づいて前記優先順を設定し、前記類似商品判定部は、前記優先順が高い方から順に、前記新商品と前記既存の商品の各々とで属性の内容が不一致となるまで属性の内容を比較した結果、内容が一致する属性の数が最も多い既存の商品を前記類似商品として判定する。
【００１２】
また、本発明の情報処理装置において、前記ネスト構造解析部は、前記ソースコードにおいて属性を含む条件式の内容に基づいて前記既存の商品ごとにおける属性に重み付け値を設定することにより前記属性間の順序関係を設定し、前記優先順設定部は、前記推移律に基づいて前記優先順を設定した結果、優先順が同じとなった複数の属性については、これら複数の属性に設定された前記重み付け値を利用して異なる優先順を設定する。
【００１３】
また、本発明の一態様としての情報処理方法は、商品に対する申込内容についての適否を前記商品の属性に基づいて判定するための判定規則が既存の商品ごとに記述されたソースコードを入力して抽象構文木を生成する構文解析ステップと、生成された抽象構文木を利用してネスト構造を解析することで、前記既存の商品ごとにおける前記属性間の順序関係を設定するネスト構造解析ステップと、設定された前記属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する優先順設定ステップと、前記属性ごとに設定された優先順と、前記既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、前記既存の商品のうちから新商品に最も類似する類似商品を判定する類似商品判定ステップとを備える。
【００１４】
また、本発明の一態様としてのプログラムは、コンピュータに、商品に対する申込内容についての適否を前記商品の属性に基づいて判定するための判定規則が既存の商品ごとに記述されたソースコードを入力して抽象構文木を生成する構文解析ステップと、生成された抽象構文木を利用してネスト構造を解析することで、前記既存の商品ごとにおける前記属性間の順序関係を設定するネスト構造解析ステップと、設定された前記属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する優先順設定ステップと、前記属性ごとに設定された優先順と、前記既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、前記既存の商品のうちから新商品に最も類似する類似商品を判定する類似商品判定ステップとを実行させるためのものである。
【発明の効果】
【００１５】
以上説明したように、本発明によれば、商品知識を必要とすることなく、商品契約のための申込内容の適否を判定するプログラムを新商品に応じて効率的に変更できるという効果が得られる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施形態におけるソースコード処理装置の構成例を示す図である。
【図２】新商品と類似商品の契約条件およびチェックルールの関係例を示す図である。
【図３】新商品と複数の類似商品候補との契約条件の例を示す図である。
【図４】第１の本実施形態におけるソースコードと商品のチェックルールの内容例を示す図である。
【図５】第１の実施形態におけるソースコードと商品のチェックルールの内容の例を示す図である。
【図６】第１の実施形態におけるソースコードと商品のチェックルールの内容の例を示す図である。
【図７】第１の実施形態における抽象構文木の例を示す図である。
【図８】第１の実施形態における情報テーブルと優先順情報の例を示す図である。
【図９】第１の実施形態における類似商品判定部が実行する類似商品判定の処理を説明するための図である。
【図１０】第１の実施形態において変更判定部が判定したソースコードにおける変更箇所と記述変更内容についての表示態様例を示す図である。
【図１１】第１の実施形態におけるソースコード処理装置が実行する処理手順例を示す図である。
【図１２】第１の実施形態における類似商品判定部が実行する類似商品判定のための処理手順例を示す図である。
【図１３】第２の実施形態におけるネスト構造解析部の動作例を示す図である。
【図１４】第２の実施形態における優先順設定部の動作例を示す図である。
【図１５】第２の実施形態における類似商品判定部の動作例を示す図である。
【図１６】第２の実施形態におけるネスト構造解析部が実行するネスト情報生成のための処理手順例を示す図である。
【図１７】第２の実施形態における類似商品判定部が実行する類似商品判定のための処理手順例を示す図である。
【発明を実施するための形態】
【００１７】
＜第１の実施形態＞
［ソースコード処理装置の構成］
図１は、本発明の実施形態における情報処理装置であるソースコード処理装置１００の構成例を示している。なお、本実施形態におけるソースコード処理装置１００は、顧客が金融商品を契約するにあたって、顧客の申込内容がその金融商品の契約条件に適合するか否かを判定(審査)するプログラムのソースコードを対象として処理する。
【００１８】
本実施形態のソースコード処理装置１００は、ソースコード記憶部１０１、構文解析部１０２、ネスト構造解析部１０３、優先順設定部１０４、類似商品判定部１０５、新商品データ記憶部１０６、変更判定部１０７、表示部１０８、ソースコード変更部１０９および操作部１１０を備える。
【００１９】
ソースコード記憶部１０１は、ソースコードを記憶する。このソースコードは、上記のように顧客が金融商品（以下、単に「商品」という）を契約するにあたって、顧客の申込内容についての適否を商品の契約条件を形成する属性に基づいて判定するためプログラムに対応するものである。つまり、このソースコードは、商品に対する申込内容についての適否を商品の契約条件を形成する属性に基づいて判定するためのチェックルール（判定規則）が既存の商品ごとに記述されたものである。なお、本実施形態において、このソースコードを記述するためのプログラム言語については特に限定されるものではない。
【００２０】
構文解析部１０２は、ソースコード記憶部１０１に記憶されているソースコードを入力して抽象構文木を生成する。
【００２１】
ネスト構造解析部１０３は、構文解析部１０２により生成された生成された抽象構文木を利用してネスト構造を解析することで、既存の商品ごとにおける属性間の順序関係を設定する。
【００２２】
優先順設定部１０４は、ネスト構造解析部１０３により設定された属性間の順序関係に基づいて、前記ソースコードに記述される属性ごとの優先順を設定する。そのうえで、第１の実施形態における優先順設定部１０４は、ネスト構造として解析された属性間の順序関係についての推移律に基づいて優先順を設定する。
【００２３】
類似商品判定部１０５は、属性ごとに設定された優先順と、既存の商品の属性の内容と新商品の属性の内容との一致状態に基づいて、既存の商品のうちから新商品に最も類似する類似商品を判定する。具体的に、第１の実施形態における類似商品判定部１０５は、優先順が高い方から順に、新商品と既存の商品の各々とで属性の内容が不一致となるまで属性の内容を比較した結果、内容が一致する属性の数が最も多い既存の商品を類似商品として判定する。
【００２４】
新商品データ記憶部１０６は、新商品に関する契約条件を示す新商品データを記憶する。なお、ソースコード記憶部１０１と新商品データ記憶部１０６に対応するハードウェアは、例えばＨＤＤ（Hard Disc Drive）やフラッシュメモリなどとすることができる。また、ソースコード記憶部１０１と新商品データ記憶部１０６としてのハードウェアは共通とすることができる。
【００２５】
変更判定部１０７は、ソースコードにおいて類似商品のチェックルールが記述されている箇所に基づいて、新商品のチェックルールの追加のためにソースコードにおいて変更すべき内容を判定する。
本実施形態の変更判定部１０７は、ソースコードにおいて変更すべき内容として、ソースコードにおいて変更すべき箇所（変更箇所）と、この変更箇所における記述の変更内容（記述変更内容）を判定する。ここで変更箇所とはソースコードにおける行（ステップ）、または行内の位置などである。また、記述変更内容とは、単語やステップの追加または削除などである。
【００２６】
表示部１０８は、変更判定部１０７により判定されたソースコードにおいて変更すべき内容を変更判定部１０７の制御に応じて表示する。
なお、変更判定部１０７が例えば変更箇所のみを判定し、表示部１０８にその変更箇所が示されるように表示させることも考えられる。
【００２７】
エンジニア(ユーザ)は、表示部１０８に表示された内容を確認して、新商品に対応するチェックルールが反映されるようにソースコードを変更するための操作を操作部１１０に対して行う。
ソースコード変更部１０９は、操作部１１０に対して行われたソースコード変更のための操作に応じてソースコード記憶部１０１に記憶されているソースコードの内容を変更する。
【００２８】
操作部１１０は、ソースコード処理装置１００をエンジニアが操作するための操作デバイスを一括して示したもので、例えばキーボードやマウスなどを含む。
【００２９】
［ソースコード変更の基本概念］
続いて、本実施形態における新商品に応じたソースコード変更の基本概念について説明する。なお、本実施形態においては、金融商品を対象とした商品申込みに関する審査業務に対応する場合を例として説明するが、対象とする商品は金融商品には限定されるものではない。
図２（ａ）には、新商品の契約条件（仕様）の一例が示されている。この新商品の契約条件の内容は、「商品タイプ」が「国債」、「商品ＩＤ」が「９０」、「発売年」が「２０１２年」、「償還期間」が「１０年」となっている。
なお、上記の契約条件における「商品タイプ」、「商品ＩＤ」、「発売年」、「償還期間」などの項目は、本実施形態においては、商品の属性として扱われる。なお、図２においては便宜上、上記の４つの属性を例示しているが、さらに多くの属性が商品ごとに設定されてよい。
【００３０】
本実施形態において、新商品に応じたソースコードの変更を行うにあたっては、既存の商品のうちから、新商品に類似した類似商品を探し出す。そして、ソースコードにおいてこの類似商品に対応するチェックルールが記述された部分の内容をコピーし、このコピーした内容を新商品の契約内容に対応させて変更する。
【００３１】
図２（ｂ）は、新商品に類似するものとして抽出された類似商品の契約条件を示している。この類似商品の契約条件は、「商品タイプ」の属性が「国債」、「商品ＩＤ」の属性が「７５」、「発売年」の属性が「２０１２年」、「償還期間」の属性が「５年」となっている。
【００３２】
図２（ｃ）は、図３（ｂ）の類似商品に対応してソースコードから抽出したチェックルールの内容例を示している。図２（ｃ）によれば、類似商品のチェックルールは、「取引機関が「窓口販売」である場合はエラー」、「領域払込が「３回払い」である場合はエラー」、「取引機関が「Ａ銀行」かつ料金払込が「２回払い」である場合はエラー」・・・・というように、エラー（不適合）となる条件が示される。なお、図２（ｃ）においては、理解のためにチェックルールの内容を記載しているが、ソースコードにおいては、この内容が所定のプログラミング言語により記述されている。
【００３３】
そして、新商品に対応しては、図２（ｃ）のチェックルールの内容をコピーし、この内容を新商品の契約条件に合わせて変更する。図２（ｄ）には、新商品に対応して図２（ｃ）の内容を変更した結果として、２番目と３番目の項目の「領域払込が「３回払い」はエラー」、「取引機関が「Ａ銀行」かつ料金払込が「２回払い」はエラー」の内容を削除している。
そして、本実施形態では、例えば図２（ｄ）に示した変更をソースコードに反映させる。これにより、変更後のソースコードによって、新商品の契約申込に対する適否の判定（審査）を行うことができる。
【００３４】
ここで、新商品に対応する類似商品を特定するにあたっては、単に内容が一致する属性の数に依存するのではなく、重要度の高い属性ができるだけ数多く一致していることが必要である。
この点について、図３を参照して説明する。図３（ａ）は、新商品の契約条件の例を示し、図３（ｂ）、（ｃ）、（ｄ）は、それぞれ、図３（ａ）の新商品に対する類似商品候補α、β、γの契約条件の例を示している。
この場合において、図３（ｂ）に示す類似商品候補αは、「商品タイプ」の属性と「償還期間」の属性の内容がそれぞれ「国債」と「１０年」であり、図３（ａ）の新商品と一致している。
また、類似商品候補βは、図３（ｃ）に示すように、「商品タイプ」の属性と「購入可能者」の属性の内容がそれぞれ「国債」と「個人」であり、図３（ａ）の新商品と一致している。
また、類似商品候補γは、図３（ｄ）に示すように、「発売年」の属性と「償還期間」の各属性の内容が「２０１２年」と「１０年」で、図３（ａ）の新商品と一致している。
【００３５】
ここで、図３（ｂ）、（ｃ）、（ｄ）に示される類似商品候補α、β、γは、いずれも、２つの属性の内容が新商品と一致している。ただし、その２つの属性の組み合わせが類似商品候補α、β、γとで互いに異なる。
前述のように、類似商品は、重要度の高い属性ができるだけ数多く新商品と一致していることが必要である。したがって、これらの類似商品候補α、β、γの新商品に対する類似性の高さは、新商品と内容が一致する属性の組み合わせにより異なる。
この場合において、例えば、最も重要度が高い属性は「商品タイプ」であり、次いで重要度が高い属性は「償還期間」である。したがって、類似商品候補α、β、γのうち、新商品と最も類似しているものは、図３（ｂ）のように、「商品タイプ」と「償還期間」の属性の組み合わせの内容が新商品と一致している類似商品候補αということになる。つまり、この場合は、類似商品候補αが類似商品として選択される。
【００３６】
例えば、エンジニアが上記のように商品の属性の重要性を考慮して新商品の類似商品を特定しようとするには、十分な商品の知識が必要であるが、このような人材を確保するのは難しい。また、このような人材が確保できたとしても、既存の商品の数は膨大であるために、類似商品を最終的に特定するまでには相当の時間がかかってしまう。
そこで、本実施形態のソースコード処理装置１００は、以降説明するように新商品に応じた類似商品を自動で判定する。
【００３７】
［ソースコードの例］
図４は、ソースコード処理装置１００のソースコード記憶部１０１に記憶されるソースコード１２０の例を示している。この図に示すソースコード１２０は、３つの既存の商品のチェックルールが記述されている例である。なお、ソースコード１２０にそのチェックルールが記述される既存の商品の数は特に限定されるものではなく、さらに多数であってよい。
図４のソースコード１２０にチェックルールが記述されている３つの商品とは、それぞれ、「ＩＤ（商品ＩＤ）」の属性について「ＩＤ＝１３」、「ＩＤ＝１０」、「ＩＤ＝２０」のものである。図４におけるブロックＢＫ１は、「ＩＤ＝１３」の商品に対応する複数のチェックルールが記述されたブロックを示す。
また、図５と図６には、それぞれ、図３と同じソースコード１２０が示されている。
図５におけるブロックＢＫ２は、「ＩＤ＝１０」の商品に対応する複数のチェックルールが記述されたブロックを示す。
図６におけるブロックＢＫ３は、「ＩＤ＝２０」の商品に対応する複数のチェックルールが記述されたブロックを示す。
【００３８】
［ソースコード処理装置の処理例］
以降、ソースコード処理装置１００が類似商品判定と、ソースコードにおいて変更すべき内容の判定のために実行する処理の一例について説明する。
まず、構文解析部１０２は、図４〜図６に示した内容のソースコード１２０をソースコード記憶部１０１から読み込む。そして、この読み込んだソースコード１２０を構文解析することにより、抽象構文木を生成する。
【００３９】
図７は、図４〜図６に示した内容のソースコード１２０を構文解析して生成された抽象構文木２００の例を示している。
図７において、ノードｎｄ１がルートである。そのうえで、ノードｎｄ２〜ｎｄ１１を含む木構造部分は、図４に示したブロックＢＫ１に対応する。
また、ノードｎｄ２、ｎｄ４およびｎｄ１２〜ｎｄ２０を含む木構造部分は、図５のブロックＢＫ２に対応する。
また、ノードｎｄ２１〜ｎｄ２７を含む木構造部分は、図６のブロックＢＫ３に対応する。
【００４０】
次に、ネスト構造解析部１０３は、図７に示すように生成された抽象構文木２００を入力して、そのネスト構造を解析する。ネストとは、ソースコードにおけるブロックの入れ子の構造をいう。
【００４１】
図７の抽象構文木２００の場合のネスト構造は、ブロックＢＫ１、ＢＫ２、ＢＫ３に対応する３つの木構造部分に分けられる。これに応じて、ネスト構造解析部１０３は、ブロックＢＫ１、ＢＫ２、ＢＫ３ごとのネスト構造に対応するネスト情報を生成し、これらのネスト情報をネスト情報テーブルとして出力する。
【００４２】
図８（ａ）は、図７の抽象構文木２００に対応して出力されるネスト情報テーブル３００の例を示している。
この図に示すネスト情報テーブル３００は、ネスト情報ＩＤに対してネスト情報が対応付けられた構造である。ネスト情報ＩＤ＝１はブロックＢＫ１に対応する。ネスト情報ＩＤ＝２はブロックＢＫ２に対応する。ネスト情報ＩＤ＝３はブロックＢＫ１に対応する。
ネスト情報を生成するにあたり、ネスト構造解析部１０３は、深さ優先探索を行うことで、ネストが浅いほうのＩＦ文（条件文）において判定に用いられる属性が先で、ネストが深いほうのＩＦ文において判定に用いられる属性が後となるように属性間の順序関係を設定する。
【００４３】
例えば図７のブロックＢＫ１の木構造部分について深さ優先探索によりノードを探索していくことによっては、ネスト構造解析部１０３は、ネストの最も浅いＩＦ文において判定に用いられる属性はノードｎｄ３において示される「商品タイプ」であることを認識する。また、ネスト構造解析部１０３は、次に深いネストのＩＦ文において判定に用いられる属性は、ノードｎｄ６において示される「償還期間」であることを認識し、さらに次に深いネストのＩＦ文において判定に用いられる属性は、ノードｎｄ８において示される「ＩＤ」と「購入者」であることを認識する。
【００４４】
これにより、ネスト構造解析部１０３は、図８（ａ）においてネスト情報ＩＤ＝１のネスト情報として示すように、「商品タイプ＞償還期間＞ＩＤ｜購入者」という内容のネスト情報を生成する。なお、上記の順序関係を示す式において「｜」の記号は、一つの条件式において複数の属性が存在していることを示す。つまり、「｜」の記号に対して前後に記述される２つの項については、論理積と論理和のいずれも問わないということを意味する。
したがって、ブロックＢＫ１における属性の順序関係は、「商品タイプ」に次いで「償還期間」となり、その次は「ＩＤ」と「購入者」が並列になるというものである。
【００４５】
また、ネスト構造解析部１０３は、ブロックＢＫ２に対応する木構造部分を深さ優先で探索することにより、ネスト構造解析部１０３は、図８（ａ）においてネスト情報ＩＤ＝２のネスト情報として示すように、「商品タイプ＞償還期間＞購入金額」という内容のネスト情報を生成する。つまり、ブロックＢＫ２における属性の順序関係は、「商品タイプ」に次いで「償還期間」となり、その次は、「購入金額」になるというものである。
【００４６】
また、ネスト構造解析部１０３は、ブロックＢＫ３に対応する木構造部分を深さ優先で探索することにより、図８（ａ）においてネスト情報ＩＤ＝３のネスト情報として示すように、「商品タイプ＞ＩＤ｜販売所」という内容のネスト情報を生成する。つまり、ブロックＢＫ３における属性の順序関係は、「商品タイプ」に次いで、「ＩＤ」と「販売所」が並列になるというものである。
【００４７】
次に、優先順設定部１０４は、図８（ａ）に示すネスト情報テーブル３００に基づいて、ソースコードのＩＦ文に出現する属性ごとに優先順を設定する。ここで、ネスト情報テーブル３００において、ソースコードのＩＦ文に出現するすべての属性が抽出され、ブロックごとに対応してその順序関係が設定されている。
【００４８】
そこで、優先順設定部１０４は、ネスト情報テーブル３００におけるネスト情報ごとにおいて示される属性の順序関係に推移律を適用して、ネスト情報テーブル３００において示されているすべての属性ごとの優先順を設定する。これにより、ソースコードのＩＦ文に出現するすべての属性ごとに優先順が設定されたことになる。
なお、図８（ａ）に示すネスト情報の各々は、ブロックごとに対応するものであるが、１つのブロックは、１つの商品に対応するチェックルールに対応する。したがって、ネスト情報の各々は、対応の商品における属性の順序関係を示している。
【００４９】
優先順設定部１０４は、設定した優先順を示す優先順情報を出力する。図８（ｂ）は、図８（ａ）のネスト情報テーブル３００に基づいて設定した優先順を示す優先順情報４００の例である。
この図８（ｂ）に示す優先順情報４００においては、「商品タイプ」の属性が最も優先順が高く、次いで、「償還期間」の属性の優先順が高い。また、「償還期間」に次いでは、「購入者」、「ＩＤ」、「購入金額」、「販売所」の４つの属性が並列に同じ優先順である。
【００５０】
図８（ｂ）の優先順情報４００に示される優先順は、ネストが浅いＩＦ文に出現している属性のほうが高くなっている。ソースコード１２０においては、複数の商品で共通して使用することが多い属性を含むＩＦ文ほどネストが浅くなる。つまり、ＩＦ文に含まれる属性は、そのＩＦ文のネストが浅いほど重要度が高いということになる。この点に着目し、優先順設定部１０４は、ネストが浅いＩＦ文に含まれる属性の優先順が高くなるように優先順の設定を行うものである。
【００５１】
次に、類似商品判定部１０５は、ソースコード１２０においてチェックルールが記述される「ＩＤ＝１３」、「ＩＤ＝１０」、「ＩＤ＝２０」の既存の商品の属性の内容を、図８（ｂ）に示される優先順情報４００が示す優先順にしたがってソートする。類似商品判定部１０５は、このソート結果を、既存商品属性テーブルとして生成する。
【００５２】
図９（ａ）の既存商品属性テーブル５００は、「ＩＤ＝１３」、「ＩＤ＝１０」、「ＩＤ＝２０」の商品ごとの属性の内容を、図８（ｂ）に示される優先順情報が示す優先順にしたがってソートした結果を示している。
【００５３】
この既存商品属性テーブル５００においては、最も左の列の属性が優先順が最も高く、右となるのに応じて低くなっていく。なお、優先順が同じで並列となった属性については、所定規則にしたがって配列順を決定してソートすればよい。
【００５４】
また、類似商品判定部１０５は、図９（ｂ）に示す新商品属性テーブル６００も生成する。このために、類似商品判定部１０５は、新商品データ記憶部１０６から新商品データを読み出す。そして、類似商品判定部１０５は、読み出した新商品データが示す新商品の属性の内容を、図８（ｂ）の優先順情報４００が示す優先順にしたがってソートすることで、新商品属性テーブル６００を生成する。
【００５５】
次に、類似商品判定部１０５は、既存の商品ごとに、優先順が高いほうの属性から順に、新商品属性テーブル６００が示す属性の内容との比較を行っていく。この際、類似商品判定部１０５は、既存の商品ごとの比較の処理について、不一致の結果が得られた段階で終了させる。
【００５６】
具体的に、図９（ａ）と図９（ｂ）において優先順が最も高い属性は「商品タイプ」である。
そこで、類似商品判定部１０５は、まず、図９（ａ）の１行目の「ＩＤ＝１０」の商品について、「商品タイプ」の内容を図９（ｂ）と比較する。この場合、「商品タイプ」の内容は、互いに「国債」で一致する。
【００５７】
そこで、類似商品判定部１０５は、優先順が２番目の「償還期間」の属性の内容を図９（ａ）の１行目と図９（ｂ）とで比較する。この場合にも、「償還期間」の属性の内容は「１０年」で一致している。
【００５８】
そこで、類似商品判定部１０５は、さらに。その右側に配列されている次の優先順の「購入者」の属性の内容を図９（ａ）の１行目と図９（ｂ）とで比較する。この段階で、「購入者」の属性の内容は、図９（ａ）の１行目が「法人、個人」であるのに対して、図９（ｂ）は「法人」のみであることから、その内容が不一致となる。そこで、類似商品判定部１０５は、図９（ａ）の１行目の商品についての属性内容の比較を終了させる。
【００５９】
次に、類似商品判定部１０５は、図９（ａ）の２行目の「ＩＤ＝１３」の商品について、「商品タイプ」の内容を図９（ｂ）と比較する。この場合、「商品タイプ」の属性の内容は、互いに「国債」で一致する。
【００６０】
そこで、類似商品判定部１０５は、優先順が２番目の「償還期間」の属性の内容を図９（ａ）の２行目と図９（ｂ）とで比較する。この場合、「償還期間」の属性の内容は、図９（ａ）の２行目が「５年」であるのに対して、図９（ｂ）は「１０年」であることから、その内容が不一致となる。そこで、類似商品判定部１０５は、図９（ａ）の２行目の商品についての属性内容の比較を終了させる。
【００６１】
次に、類似商品判定部１０５は、図９（ａ）の３行目の「ＩＤ＝２０」の商品について、「商品タイプ」の内容を図９（ｂ）と比較する。この場合、「商品タイプ」の内容は、互いに「国債」で一致する。この場合、「商品タイプ」の属性の内容は、図９（ａ）の３行目が「地方債」であるのに対して、図９（ｂ）は「国債」であることから、その内容が不一致となる。そこで、類似商品判定部１０５は、図９（ａ）の３行目の商品についての属性内容の比較を終了させる。
【００６２】
図９（ｃ）は、上記のように比較を行った結果を既存商品属性テーブル５００に反映させたものである。これまでの比較結果から、類似商品判定部１０５は、図９（ａ）の１行目の「ＩＤ＝１０」の商品は、新商品と内容が一致した属性の数が「２」であることを認識する。また、図９（ａ）の２行目の「ＩＤ＝１３」の商品は、新商品と内容が一致した属性の数が「１」であることを認識する。また、図９（ａ）の３行目の「ＩＤ＝２０」の商品は、新商品と内容が一致した属性の数が「０」であることを認識する。
【００６３】
上記のように認識された属性の数が多い既存の商品ほど、新商品との間で優先順が高い（つまり、重要度が高い）属性を多く共有していることになるので、新商品との類似度が高いと見てよい。そこで、類似商品判定部１０５は、例えば上記のように既存の商品ごとに認識した属性の数を、図９（ｃ）の最も右の列に示すように、類似度として求める。つまり、図９（ａ）の１行目の「ＩＤ＝１０」の商品の類似度は「２」であり、２行目の「ＩＤ＝１３」の商品の類似度は「１」であり、３行目の「ＩＤ＝２０」の商品の類似度は「０」である。
【００６４】
そして、類似商品判定部１０５は、このように求められた類似度が最大値の商品を類似商品として判定する。図９（ｃ）の場合であれば、類似商品判定部１０５は、１行目における「ＩＤ＝１０」の商品を類似商品として判定する。
【００６５】
変更判定部１０７は、類似商品判定部１０５による類似商品の判定結果に基づき、新商品のチェックルールの追加のためにソースコード１２０において変更すべき内容を判定する。
このために、変更判定部１０７は、類似商品判定部１０５により類似商品として判定された商品のＩＤ（商品ＩＤ）を入力する。また、ソースコード記憶部１０１に記憶されているソースコード１２０を読み出す。そして、変更判定部１０７は、類似商品として判定された商品のＩＤを利用して、ソースコード１２０において類似商品のチェックルールが記述されたブロックを探索する。
【００６６】
具体的に、図９（ｃ）にて類似商品であると判定された商品は、「ＩＤ＝１０」の商品である。この「ＩＤ＝１０」の商品のチェックルールが記述されたブロックをソースコード１２０から探索するために、変更判定部１０７は、例えばＩＦ文に「ＩＤ＝１０」を含むブロックを探索する。この結果、変更判定部１０７は、「ＩＤ＝１０」の商品のチェックルールが記述されたブロックとして、図５のブロックＢＫ２を探索する。
【００６７】
次に、変更判定部１０７は、新商品データ記憶部１０６から新商品データを読み出す、そして、変更判定部１０７は、ブロックＢＫ２において記述されるチェックルールと新商品データにおいて示される新商品のチェックルールとの差分を認識する。この場合において、変更判定部１０７は、差分として、ブロックＢＫ２のチェックルールにおいて、新商品の商品ＩＤのみが記述されていないことを認識する。
【００６８】
そこで、この場合の変更判定部１０７は、上記のように認識した差分にしたがって、ブロックＢＫ２においてＩＦ文にＩＤの属性を含む、「IF ID = 10」の行が変更箇所であると判定する。
【００６９】
さらに、本実施形態の変更判定部１０７は、変更箇所における記述変更内容も判定する。この場合には、「IF ID = 10」のＩＦ文に対して新商品の「ＩＤ＝３０」を追加すべきであるため、変更判定部１０７は、変更箇所「IF ID = 10」の行について、「IF ID = 10 OR 30」と、「OR 30」を末尾に追加するように記述を変更すべきであると判定する。
【００７０】
そして、変更判定部１０７は、上記の判定結果（変更箇所と記述変更内容）を表示部１０８に表示させる。
図１０は、表示部１０８に表示される判定結果の内容が示されている。この図に示すように、表示部１０８には、例えば、ソースコード１２０が示される。そのうえで、このソースコード１２０における変更箇所である「IF ID = 10」のＩＦ文において、その後ろに「OR 30」を追加して表示し、この「OR 30」が記述変更内容であることを示すハイライト表示ｉｎｄにより強調する。
【００７１】
この図１０に示す表示を見たエンジニアは、例えば、このように表示された内容を確認したうえで、新商品のチェックルールが反映されるようにソースコード１２０を書き換えるための操作を操作部１１０に対して行う。この操作に応じてソースコード変更部１０９は、ソースコード記憶部１０１に記憶されているソースコード１２０を変更する。
このように、本実施形態においては、例えばエンジニアが十分な商品知識を有していなくとも、ソースコード処理装置が新商品に対応する類似商品を自動で判定する。そして、類似商品の判定結果に基づいて、ソースコード１２０において変更すべき内容を判定してエンジニアに通知することができる。なお、変更判定部１０７の判定結果の表示態様については特に図１０に示したものに限定されない。
【００７２】
［処理手順例］
図１１のフローチャートは、ソースコード処理装置１００が実行する処理手順例を示している。
まず、構文解析部１０２は、ソースコード記憶部１０１からソースコード１２０を読み込む（ステップＳ１０１）。次に、構文解析部１０２は、読み込んだソースコード１２０の構文解析を行って、抽象構文木２００を生成する（ステップＳ１０２）。
【００７３】
ネスト構造解析部１０３は、ステップＳ１０２により生成された抽象構文木２００を利用して、ブロックごと（つまり、既存の商品ごと）の属性の順序関係を示すネスト情報を生成する（ステップＳ１０３）。
【００７４】
優先順設定部１０４は、ステップＳ１０３により生成されたブロックごとのネスト情報から、ソースコード１２０において記述されているすべての属性についての優先順を設定する（ステップＳ１０４）。
【００７５】
類似商品判定部１０５は、ステップＳ１０４により設定された属性ごとの優先順と、既存の商品ごとの属性の内容と、新商品データ記憶部１０６から読み出した新商品データが示す新商品の属性の内容とに基づいて、既存の商品のうちから、新商品に類似する類似商品を１つ判定する（ステップＳ１０５）。
【００７６】
変更判定部１０７は、ステップＳ１０５により判定された類似商品の商品ＩＤと、新商品データとに基づいて、ソースコード１２０における変更箇所と、その変更箇所における記述変更内容を判定する（ステップＳ１０６）。
そして、変更判定部１０７は、判定結果である変更箇所と記述変更内容をソースコードとともに表示部１０８に表示させる（ステップＳ１０７）。
【００７７】
そして、ソースコード変更部１０９は、操作部１１０に対してエンジニアが行ったソースコード１２０を変更するための操作に応じて、ソースコード記憶部１０１に記憶されているソースコード１２０を変更する（ステップＳ１０８）。
【００７８】
図１２のフローチャートは、類似商品判定部１０５が図１１のステップＳ１０５として実行する類似商品判定のための処理手順例を示している。
【００７９】
まず、類似商品判定部１０５は、図９（ｂ）に示した新商品属性テーブル６００を予め生成する（ステップＳ２０１）。つまり、類似商品判定部１０５は、新商品の属性を、図１１のステップＳ１０４により設定された優先順に対応させてソートする。
【００８０】
次に、類似商品判定部１０５は、図９（ａ）、（ｃ）に示した既存商品属性テーブル５００における行番号を示す変数ｎに「１」を代入する（ステップＳ２０２）。
【００８１】
次に、類似商品判定部１０５は、既存商品属性テーブル５００におけるｎ行目を選択し（ステップＳ２０３）、さらに、優先順を示す変数ｍに「１」を代入する（ステップＳ２０４））。
そのうえで、類似商品判定部１０５は、既存商品属性テーブル５００のｎ行目と新商品属性テーブル６００において優先順がｍ番目の属性の内容を比較する（ステップＳ２０５）。
【００８２】
類似商品判定部１０５は、ステップＳ２０５による比較結果として、両者の属性の内容が一致したか否かについて判定する（ステップＳ２０６）。ここで、一致したのであれば（ステップＳ２０６−ＹＥＳ）、類似商品判定部１０５は、変数ｍをインクリメントして（ステップＳ２０７）、ステップＳ２０５に戻る。これにより、次の優先順の属性の内容についての比較が引き続き行われる。
【００８３】
これに対して、内容が一致していない場合（ステップＳ２０６−ＮＯ）、類似商品判定部１０５は、既存商品属性テーブル５００のｎ行目の商品についての類似度Ｄに対して、変数ｍの値を代入する（ステップＳ２０８）。つまり、類似商品判定部１０５は、図９の説明にしたがって、内容が一致していたと判定された属性の数に応じた値を類似度Ｄとして求めるものである。
【００８４】
次に、類似商品判定部１０５は、変数ｎが最大値であるか否かについて判定する（ステップＳ２０９）。図９との例の対応では、変数ｎの最大値は「３」である。
変数ｎが最大値ではない場合には（ステップＳ２０９−ＮＯ）、まだ、属性内容の比較を行っていない既存商品属性テーブル５００の行が残っている。そこで、この場合、類似商品判定部１０５は、変数ｎをインクリメントしたうえで（ステップＳ２１０）、ステップＳ２０３に戻ることで、既存商品属性テーブル５００における次の行を対象として属性内容の比較を行う。
一方、変数ｎが最大値である場合には（ステップＳ２０９−ＹＥＳ）、既存商品属性テーブル５００のすべての行について属性内容の比較を行ったことになる。そこで、この場合の類似商品判定部１０５は、類似度Ｄが最大値の行に対応する既存の商品を類似商品として判定する（ステップＳ２１１）
【００８５】
＜第２の実施形態＞
［ネスト構造解析部、優先順設定部、類似商品判定部の動作例］
次に、第２の実施形態について説明する。なお、第２の実施形態におけるソースコード処理装置１００の全体構成としては、図１と同様でよい。また、第２の実施形態におけるソースコード処理装置１００が実行する処理手順の全体としては、図１１と同様でよい。
【００８６】
第１の実施形態と第２の実施形態においては、属性に対する優先順の設定手法が異なる。第１の実施形態においては、ネスト構造解析部１０３により解析されたブロックごとの属性の順序関係に対して推移律を適用して属性ごとの優先順を設定した。
これに対して、第２の実施形態では、ネスト構造解析部１０３は、ネストの深さによるのではなく、各ネスト情報における属性に重み付け値を設定し、この重み付け値に応じてブロックごとの属性の順序関係を設定する。そして、優先順設定部１０４は、このネスト情報ごとの属性の重み付け値に基づき、属性ごとの優先順を設定する。さらに、類似商品判定部１０５は、新商品と既存の商品の各々とで内容が一致する属性に設定された前記重み付け値に基づいて求めた類似度が最も高い既存の商品を類似商品として判定する。
【００８７】
［属性に対する重み付け値の設定例］
図１３（ａ）、（ｂ）は、それぞれ、第２の実施形態におけるネスト構造解析部１０３がネスト情報を生成する際の属性に対する重み付け値の設定例を示している。
まず、図１３（ａ）においては、ソースコード１２０における同じ階層において、条件文Ｌ１、Ｌ２、Ｌ３の３つの条件文（ＩＦ文）が記述されている。このうち、条件文Ｌ１は「ＩＤ（商品ＩＤ）」の属性を含んでいるが、条件文Ｌ２、Ｌ３は、いずれも「商品タイプ」の属性を含んでいる。つまり、「商品タイプ」の属性については、同じ階層において複数の条件文に含まれている。
【００８８】
このように、同じ階層において複数の条件文に同じ属性が含まれている場合、この属性は重要度が高いということがいえる。そこで、同じ階層において複数の条件文に同じ属性が含まれている場合、ネスト構造解析部１０３は、この属性の重み付け値を大きく変更するように設定する。
【００８９】
一例として、図１３（ａ）の場合において、重み付け値のデフォルトの値は「０．４」であるとする。図１３（ａ）のソースコード１２０において、同じ階層で「ＩＤ」の属性を含むのは条件文Ｌ１のみであるから、ネスト構造解析部１０３は、「ＩＤ」の属性に対してデフォルトとしての「０．４」の重み付け値を設定する。
【００９０】
これに対して、条件文Ｌ２、Ｌ３の２つは、ともに同じ階層であって、かつ、同じ「商品タイプ」の属性を含んでいる。そこで、ネスト構造解析部１０３は、「商品タイプ」の属性については、デフォルトの「０．４」より大きい重み付け値として、例えば、「０．４」の２倍の「０．８」を設定する。
なお、このように重み付け値を大きく変更するように設定するにあたっては、同じ階層において存在する同じ属性の数が多くなるのに応じて大きくしていくように変更してよい。
【００９１】
また、図１３（ｂ）においては、ソースコード１２０における同じ階層において、条件文Ｌ４、Ｌ５の２つの条件文（ＩＦ文）が記述されている。このうち、条件文Ｌ４に含まれる「商品タイプ」の属性についての真の値は「国債」の１つのみである。
これに対して、条件文Ｌ５は、「IF ID = 10 OR 20 OR 30」と記述されているように、その条件式における「ＩＤ」の属性についての真の値は、「１０」、「２０」「３０」の３である。つまり、条件文Ｌ５における真の値は複数である。このように、条件式に含まれる属性についての真の値が複数である場合、ネスト構造解析部１０３は、前記属性についての重み付け値を小さく変更するように設定する。
【００９２】
一例として、ネスト構造解析部１０３は、条件文Ｌ４に含まれる「商品タイプ」の属性に対してはデフォルトとしての「０．４」の重み付け値を設定する。
これに対して、条件文Ｌ５に含まれる「ＩＤ」の属性については、デフォルトの「０．４」より低い重み付け値として、例えば、「０．４」の１／２倍の「０．２」を設定する。なお、このように重み付け値を小さくするように設定するにあたっては、真の値の数が多くなるのに応じて小さくするように変更してよい。
【００９３】
また、ネスト構造解析部１０３は、条件式の内容によっては、条件式に含まれる属性についての偽の値が複数である場合、前記属性についての重み付け値を小さく変更するように設定してもよい。つまり、ネスト構造解析部１０３は、ソースコードの条件式に含まれる属性についての真偽を示す値が複数である場合、属性についての重み付け値を小さく変更するように設定するものである。
【００９４】
なお、第２の実施形態におけるネスト構造解析部１０３が既存の商品ごとの属性間の順序関係を設定するにあたっては、図１３（ａ）のみの手法を採用してもよいし、図１３（ｂ）のみの手法を採用してもよいし、図１３（ａ）と図１３（ｂ）の手法を併用してもよい。
【００９５】
そして、第２の実施形態における優先順設定部１０４は、既存の商品ごとの属性間の順序関係の設定根拠である重み付け値を利用して、ソースコード１２０において記述される属性ごとの優先順を設定する。具体的には、重み付け値の高い属性の順にしたがって優先順を設定すればよい。
【００９６】
ただし、第２の実施形態においては、特に図１３（ｂ）の手法が採用された場合に、ネスト情報テーブル３００におけるネスト情報間で、同じ属性に設定された重み付け値が異なる可能性がある。
具体例として、図１４（ａ）においては、ネスト情報ＩＤ＝「１」と「２」のネスト情報における「商品タイプ」の属性に対する重み付け値Ｋは「１．０」であるのに対して、ネスト情報ＩＤ＝「３」の「商品タイプ」の属性に対する重み付け値Ｋは「１．２」である。
【００９７】
また、ネスト情報ＩＤ＝「１」と「２」のネスト情報における「償還期間」の属性に対する重み付け値Ｋは「０．８」であるのに対して、ネスト情報ＩＤ＝「３」の「償還期間」の属性に対する重み付け値Ｋは「０．５」である。
【００９８】
また、ネスト情報ＩＤ＝「１」のネスト情報における「ＩＤ」の属性に対する重み付け値Ｋは「０．３」であるのに対して、ネスト情報ＩＤ＝「３」の「ＩＤ」の属性に対する重み付け値Ｋは「０．４」である。
【００９９】
このような場合には、例えば所定の規則にしたがって属性に対して１つの正規の重み付け値を決定する。例えば、優先順設定部１０４は、例えば複数の重み付け値のうちの最頻値、最大値、最小値のいずれかを正規の重み付け値として決定することができる。あるいは、優先順設定部１０４は、複数の重み付け値の平均値を算出し、この平均値を正規の重み付け値として決定することができる。
【０１００】
図１４（ｂ）は、優先順設定部１０４が、図１４（ａ）のネスト情報テーブル３００に対応して、平均値の算出により求めた正規の重み付け値にしたがって優先順を設定した場合の優先順情報４００を示している。
この優先順情報４００においては、「商品タイプ」、「償還期限」、「購入金額」、「販売所」、「ＩＤ」、「購入者」の順で優先順が設定されている。「商品タイプ」の重み付け値Ｋは「１．１」、「償還期間」の重み付け値Ｋは「０．７」、「購入金額」の重み付け値Ｋは「０．６」、「販売所」の重み付け値Ｋは「０．４」、「ＩＤ」の重み付け値Ｋは「０．３５」、「購入者」の重み付け値Ｋは「０．３」である。
【０１０１】
そして、第２の実施形態における類似商品判定部１０５は、既存の商品についての新商品との類似度を以下のように求める。
図１５（ａ）には、図９（ｂ）と同様の新商品属性テーブル６００が示されている。また、図１５（ｂ）には、優先順設定部１０４が設定した優先順にしたがって類似商品判定部１０５が生成した既存商品属性テーブル５００の例が示されている。なお、この図に示す属性ごとの重み付け値Ｋは、説明の便宜上、図１４（ｂ）とは異なる結果のものを用いている。この図１５（ｂ）の例では、「商品タイプ」（重み付け値Ｋ＝０．８）、「償還期間」（重み付け値Ｋ＝０．６）、「購入者」（重み付け値Ｋ＝０．４）、「ＩＤ」（重み付け値Ｋ＝０．３）・・・の優先順となっている。
【０１０２】
そのうえで、第２の実施形態における類似商品判定部１０５は、既存商品属性テーブル５００における行（既存の商品）ごとに、新商品属性テーブル６００と内容が一致している属性を特定する。そして、内容が一致していた属性の重み付け値を加算することにより、既存商品属性テーブル５００における行（既存の商品）ごとの類似度を求める。
図１５の場合であれば、図１５（ｂ）においてハッチングで示すように、既存商品属性テーブル５００の１行目においては、「商品タイプ」の属性と「償還期間」の２つの属性の内容が、それぞれ、「国債」と「１０年」で新商品属性テーブル６００と一致している。この場合、「商品タイプ」の属性の重み付け値が０．８で、「償還期間」の属性の重み付け値が０．６なので、類似度は１．４である。
また、既存商品属性テーブル５００の２行目においては、「商品タイプ」の属性と「購入者」の２つの属性の内容が、それぞれ、「国債」と「個人」で新商品属性テーブル６００と一致している。したがって、この既存商品属性テーブル５００の２行目に対応する類似度は１．２である。
また、既存商品属性テーブル５００の３行目においては、「償還期間」の属性の内容のみが「１０年」で新商品属性テーブル６００と一致している。したがって、この既存商品属性テーブル５００の３行目に対応する類似度は０．６である。
【０１０３】
このように類似度を求めたうえで、類似商品判定部１０５は、類似度が最大値のものを類似商品として判定する。つまり、図１５の場合には、既存商品属性テーブル５００の１行目における「ＩＤ＝１０」の商品が類似商品であるとして判定される。
【０１０４】
［処理手順例］
図１６のフローチャートは、第２の実施形態におけるネスト構造解析部１０３が、図１１のステップＳ１０３として実行するネスト情報生成のための処理手順例を示している。
【０１０５】
ネスト構造解析部１０３は、まず、抽象構文木２００におけるルートのノードを選択する（ステップＳ３０１）。
【０１０６】
そのうえで、ネスト構造解析部１０３は、選択しているノードがＩＦ文（条件文）であるか否かについて判定する（ステップＳ３０２）。
ＩＦ文である場合（ステップＳ３０２−ＹＥＳ）、ネスト構造解析部１０３は、そのＩＦ文の条件式の内容にしたがって、図１３にて説明したように、そのＩＦ文に含まれる属性についての重み付け値を設定する（ステップＳ３０３）。そして、ネスト構造解析部１０３は、その条件式に含まれていた属性に、ステップＳ３０３により設定した重み付け値を対応付けて保持し（ステップＳ３０４）、この後にステップＳ３０５に進む。
【０１０７】
ＩＦ文でない場合（ステップＳ３０２−ＮＯ）、また、ステップＳ３０４を実行した後、ネスト構造解析部１０３は、現在選択しているノードの子ノードのうちで、未探索の子ノードが存在するか否かについて判定する（ステップＳ３０５）。
【０１０８】
未探索の子ノードが存在しない場合（ステップＳ３０５−ＮＯ）、つまり、最も深い階層のノードに到達した場合、ネスト構造解析部１０３は、現在において保持しているすべての属性とこれらに対応付けられている重み付け値を１つのネスト情報として出力する（ステップＳ３０６）。このように、最も深い階層のノードにまで探索されるごとにネスト情報が１つずつ順次出力され、これらのネスト情報によりネスト情報テーブル３００が生成される。
【０１０９】
次に、ネスト構造解析部１０３は、ステップＳ３０６により出力した属性とこれらに対応付けられた重み付け値のデータを消去する（ステップＳ３０７）。
【０１１０】
次に、ネスト構造解析部１０３は、これまでに選択しているノードの親ノードに選択を変更したうえで（ステップＳ３０８）、この選択した親ノードを子とする子ノードのうちで未探索のものが存在するか否かについて判定する（ステップＳ３０９）。
【０１１１】
未探索の子ノードが存在する場合（ステップＳ３０９−ＹＥＳ）、ネスト構造解析部１０３は、未探索の子ノードを１つ選択し（ステップＳ３１０）、ステップＳ３０２の処理に戻る。これにより、他のブロック（つまり、他の既存の商品）に対応するネスト情報を生成するための処理に移行する。
【０１１２】
一方、未探索の子ノードが存在しない場合（ステップＳ３０９−ＮＯ）、ネスト構造解析部１０３は、さらに、ステップＳ３０７により選択した親ノードが抽象構文木２００のルートか否かについて判定する（ステップＳ３１１）。
【０１１３】
抽象構文木２００のルートでない場合（ステップＳ３１１−ＮＯ）、ネスト構造解析部１０３は、ステップＳ３０８に戻ることで、前回のステップＳ３０８により選択した親ノードの親ノードをさらに選択する。
そして、抽象構文木２００のルートである場合には（ステップＳ３１１−ＹＥＳ）、抽象構文木２００におけるすべてのノードが探索され、すべてのブロック（既存の商品）に対応するネスト情報が得られている。この場合、ネスト構造解析部１０３は、これまでの抽象構文木２００の探索を終了する。
【０１１４】
なお、これまでの説明では、ＩＦ文に含まれる属性を対象として重み付けを行っているが、例えば、ＩＦ−ＥＬＳＥ文などの他の条件文に含まれる属性を対象とすることも考えられる。
また、第１の実施形態におけるネスト構造解析部１０３も、図１６に準じた探索処理を行うことにより、図８（ａ）に示したネスト情報テーブル３００を生成することができる。ただし、第１の実施形態においては、ステップＳ３０３による重み付け値の設定は行う必要はなく、ステップＳ３０４においては、条件式に含まれていた属性のみを保持すればよい。また、ステップＳ３０６においては、保持している属性のみによるネスト情報を出力すればよく、ステップＳ３０７においては、出力済みの属性のみを消去すればよい。
【０１１５】
図１７のフローチャートは、第２の実施形態における類似商品判定部１０５が図１１のステップＳ１０５として実行する類似商品判定のための処理手順例を示している。
【０１１６】
まず、類似商品判定部１０５は、例えば図９（ｂ）に示した新商品属性テーブル６００を予め生成する（ステップＳ４０１）。
【０１１７】
次に、類似商品判定部１０５は、図９（ａ）、（ｃ）に示した既存商品属性テーブル５００における行番号を示す変数ｎに「１」を代入する（ステップＳ４０２）。
【０１１８】
次に、類似商品判定部１０５は、既存商品属性テーブル５００におけるｎ行目を選択する（ステップＳ４０３）。
そして、類似商品判定部１０５は、ｎ行目の既存の商品と新商品とで属性ごとに内容を比較する（ステップＳ４０４）。そして、類似商品判定部１０５は、ステップＳ４０４による比較結果に基づいて、ｎ行目の既存の商品についての新商品との類似度Ｄを算出する（ステップＳ４０５）。この類似度Ｄは、図１５にて説明したように、内容が一致した属性の重み付け値を加算することにより求めることができる。
【０１１９】
次に、類似商品判定部１０５は、変数ｎが最大値であるか否かについて判定する（ステップＳ４０６）。
変数ｎが最大値ではない場合（ステップＳ４０６−ＮＯ）、類似商品判定部１０５は、変数ｎをインクリメントしたうえで（ステップＳ４０７）、ステップＳ４０３に戻ることで、既存商品属性テーブル５００における次の行を対象として属性内容の比較を行う。
一方、変数ｎが最大値である場合（ステップＳ４０６−ＹＥＳ）、類似商品判定部１０５は、類似度Ｄが最大値の行に対応する既存の商品を類似商品として判定する（ステップＳ４０８）。
【０１２０】
［変形例］
なお、本実施形態の変形例として、優先順設定については、第１の実施形態と、第２の実施形態とが以下のように組み合わされてもよい。
つまり、変形例におけるネスト構造解析部１０３は、第２の実施形態にしたがって重み付け値を対応付けて属性の順序関係を設定する。
そのうえで、優先順設定部１０４は、まず、推移律により属性ごとの優先順を設定する。そして、推移律に基づいて優先順を設定した結果、優先順が同じとなった複数の属性については、さらに、これら複数の属性に設定された重み付け値を利用して異なる優先順を設定するというものである。つまり、推移律に基づいて設定した優先順が同じとなった複数の属性については、改めて、これら複数の属性に設定された重み付け値により異なる優先順を決定するものである。
この際において、図１４にて説明したように、ネスト情報間において同じ属性に対して設定された重み付け値が複数存在する状態となった場合には、平均値を求めるなどの所定の演算によって１つの正規の重み付け値を決定すればよい。
【０１２１】
また、これまでの実施形態の説明にあっては金融商品を例に挙げているが、例えば保険商品や証券などであってもよい。また、これら以外にも、例えばクレジットカードの審査などをあはじめ、申込みの際に審査が必要となる多様なサービスなどにも対応できる。
【０１２２】
また、図１に示す各機能部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりソースコードの処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【０１２３】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【０１２４】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【０１２５】
１００  ソースコード処理装置
１０１  ソースコード記憶部
１０２  構文解析部
１０３  ネスト構造解析部
１０４  優先順設定部
１０５  類似商品判定部
１０６  新商品データ記憶部
１０７  変更判定部
１０８  表示部
１０９  ソースコード変更部
１１０  操作部
１２０  ソースコード
２００  抽象構文木
３００  ネスト情報テーブル
４００  優先順情報
５００  既存商品属性テーブル
６００  新商品属性テーブル
【図１】
0005768009.tif 000002
【図２】
0005768009.tif 000003
【図３】
0005768009.tif 000004
【図４】
0005768009.tif 000005
【図５】
0005768009.tif 000006
【図６】
0005768009.tif 000007
【図７】
0005768009.tif 000008
【図８】
0005768009.tif 000009
【図９】
0005768009.tif 000010
【図１０】
0005768009.tif 000011
【図１１】
0005768009.tif 000012
【図１２】
0005768009.tif 000013
【図１３】
0005768009.tif 000014
【図１４】
0005768009.tif 000015
【図１５】
0005768009.tif 000016
【図１６】
0005768009.tif 000017
【図１７】
0005768009.tif 000018