JP2020154897A - 不具合情報抽出装置及び方法並びにプログラム - Google Patents

Abstract

【課題】過去の不具合の事例が記載されたテキストから必要十分な情報量の不具合情報を抽出する不具合情報抽出装置及び方法並びにプログラムを提供する。【解決手段】方法は、過去の不具合の事例が記載されたテキストから不具合事象及び当該不具合事象が発生した故障機器・部品をそれぞれ抽出しＳ１１、抽出した不具合事象及び故障機器・部品を対応付けることにより不具合情報を生成しＳ１２、抽出した故障機器・部品について、テキスト内で記載が省略されている当該故障機器・部品の親部品を推定しＳ１４、推定した当該親部品の情報を不具合情報に追加するようにして不具合情報を補完する。【選択図】図７

Description

本発明は不具合情報抽出装置及び方法並びにプログラムに関し、例えば、故障診断装置に適用して好適なものである。

近年、製品の故障診断や修理を行う際、症状、診断手順及び対処方法などに関する情報を蓄積したデータベースから類似した症状の事例を検索により抽出し、抽出した事例を参考にして故障診断や修理を行うことが広く行われている。このような方法によれば、故障診断や修理の作業効率の向上させることができる。

このような故障診断に関連する技術として、例えば、非特許文献１には、故障診断の用途において、事故報告書等のテキストに含まれる「ため」や「ので」のような手掛かり語を用いて、発生した不具合とその原因との因果関係を解明するために必要な語句や文章を抽出する技術が開示されている。

一方、故障診断に用いるために、テキストから機器や部品の不具合に関する情報（以下、これを不具合情報と呼ぶ）を抽出する場合、故障した機器・部品の種類だけでなく、その機器・部品が存在する箇所を特定する必要がある。例えば、「ねじ」のような部品は数多くの箇所に使用されており、「ねじが破断している」といった情報だけでは、破断したねじの存在箇所を特定することができず、実際に故障の有無を調査することが困難である。

このため、「ねじ」が使用されている上位機器・部品の名称や場所・位置を特定する情報を抽出することが必要となる。例えば、「プリント板を固定するねじを調べたところ、ねじが破断していた」といったテキストの場合、「プリント板のねじ」のように「ねじ」が「プリント板」に関係しているという情報を抽出し、「プリント板のねじが破断している」という不具合情報を抽出することが望ましい。このような省略されている部品の親子関係を抽出する技術が非特許文献２に開示されている。

このような意味的な処理は、多大な計算コストを必要とするため、計算を効率的に行うことが望ましい。このような要求に対応すべく、特許文献１には、ゼロ代名詞に対して、関係抽出処理を起動するか否かの判断を行う技術が開示されている。

特開２００６−２４３８４４号公報

乾孝司，乾健太郎，松本、「接続標識「ため」に基づく文書集合からの因果関係知識の自動獲得」、情報処理学会論文誌 45(3), 919-933, 2004. Yufang Hou，Katja Markert，Michael Strube、「Global Inference for Bridging Anaphora Resolution」、Proceedings ofNAACL-HLT 2013, pages 907-917.

従来技術では、関係抽出処理を起動するか否かの判断を行う対象がゼロ代名詞に限定されている。特許文献１では、ゼロ代名詞を格要素としてもつ述語に関する格解析結果に基づいて、関係抽出処理の要否が判断される。しかしながら、故障診断で用いる不具合情報の抽出処理では、このような方法によっては関係抽出処理の要否を適切に判断することが難しい。

また故障診断で用いる不具合情報の抽出処理では、故障機器・部品の階層関係（以下、適宜、これを親子関係とも呼ぶ）を考慮する必要がある。例えば、「エンジン」は、「ピストン」及び「バルブ」のような部品から構成されており、さらに「ピストン」は「ピストンリング」のような部品から構成されている。このため「ピストンリング」の上位機器・部品が「ピストン」であり、さらにその上位機器・部品が「エンジン」となる。

しかしながら、事故報告書の作成者が事故報告書を作成する際、このような機器・部品間の親子関係を常に意識して不具合事象を記述するとは限らない。例えば、「エンジンのピストンリング」という記述だけでなく、単に「ピストンリング」といった記述がなされることもあり得る。このため、テキストの記述に従って機器・部品間の親子関係を抽出した場合、同じ不具合事象に関して対して様々な表記・表現が抽出される。

この場合、故障診断では、過去に発生した不具合の不具合情報のうち、今回発生した不具合と類似する不具合情報を集約し、その件数をカウントすることで可能性が高い故障機器・部品を推定するため、抽出される表記・表現の多様性が増すことは、集約処理の妨げとなり、結果的に故障診断性能の低下に繋がるおそれがある。

さらに上述のような上位機器・部品の省略だけでなく、下位機器・部品が省略される場合もあり得る。例えば、「エンジンの圧力」といった表現は普通に用いられるが、「エンジンの圧力」は、「エンジンのシリンダ（内）の圧力」のことを意味していると考えられ、「シリンダ」が省略されていると推定できる。

従って、過去の事故報告書に記載された不具合情報に基づいて今回発生した不具合を診断するに際しては、事故報告書のテキスト中に不足している上位又は下位の機器・部品の名称などの情報を補ったり、事故報告書間における同一の不具合事象に対する表記・表現の揺れを同一の表記・表現に集約するなどして、各事故報告書から必要十分な情報量の不具合情報を抽出できるようにすることが必要となる。

本発明は以上の点を考慮してなされたもので、過去の不具合の事例が記載されたテキストから必要十分な情報量の不具合情報を抽出し得る不具合情報抽出装置及び方法並びにプログラムを提案しようとするものである。

かかる課題を解決するため本発明においては、過去の不具合の事例が記載されたテキストから不具合情報を抽出する不具合情報抽出装置であって、前記テキストから不具合事象を抽出する不具合事象抽出部と、当該不具合事象が発生した故障機器・部品を前記テキストから抽出する故障機器・部品抽出部と、前記故障機器・部品抽出部により抽出された前記故障機器・部品、及び、前記不具合事象抽出部により抽出された前記不具合事象を対応付けることにより前記不具合情報を生成する機器・事象対応付け部と、前記故障機器・部品抽出部により抽出された前記故障機器・部品について、前記テキスト内で記載が省略されている当該故障機器・部品の親部品を推定し、推定した当該親部品の情報を前記不具合情報に追加するようにして前記不具合情報を補完する故障機器・部品変更部とを設けるようにした。

また本発明においては、過去の不具合の事例が記載されたテキストから不具合情報を抽出する不具合情報抽出装置により実行される不具合情報抽出方法であって、前記テキストから不具合事象、及び、当該不具合事象が発生した故障機器・部品をそれぞれ抽出する第１のステップと、抽出した前記不具合事象及び前記故障機器・部品を対応付けることにより前記不具合情報を生成する第２のステップと、抽出した前記故障機器・部品について、前記テキスト内で記載が省略されている当該故障機器・部品の親部品を推定し、推定した当該親部品の情報を前記不具合情報に追加するようにして前記不具合情報を補完する第３のステップとを設けるようにした。

さらに本発明においては、プログラムにおいて、過去の不具合の事例が記載されたテキストから不具合事象、及び、当該不具合事象が発生した故障機器・部品をそれぞれ抽出する第１のステップと、抽出した前記不具合事象及び前記故障機器・部品を対応付けることにより不具合情報を生成する第２のステップと、抽出した前記故障機器・部品について、前記テキスト内で記載が省略されている当該故障機器・部品の親部品を推定し、推定した当該親部品の情報を前記不具合情報に追加するようにして前記不具合情報を補完する第３のステップとを備える処理をコンピュータに実行させるようにした。

本発明によれば、過去の不具合の事例が記載されたテキストから必要十分な不具合情報を抽出し得る不具合情報抽出装置及び方法並びにプログラムを実現できる。

本実施の形態による故障診断装置の構成を示すブロック図である。 事故報告書のテキストの記載例を示す図表である。 不具合情報テーブルの構成例を示す図表である。 機器・部品のツリー構造の一例を示すツリー図である。 機器・部品階層関係辞書の構成例を示す図表である。 不具合情報抽出処理の処理手順を示すフローチャートである。 故障機器・部品情報変更処理の処理手順を示すフローチャートである。 不具合情報テーブルの更新例を示す図表である。 部品系列正規化処理の処理手順を示すフローチャートである。 正規化処理テーブルの構成例を示す図表である。 分岐数決定処理の処理手順を示すフローチャートである。 （Ａ）は「例１」の場合における正規化処理テーブルの更新例を示す図表であり、（Ｂ）は「例２」の場合における正規化処理テーブルの更新例を示す図表である。 不具合情報テーブルの更新例を示す図表である。 検索画面の構成例を示す図である。

以下、添付図面を参照して本発明の一実施の形態を説明する。本実施の形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。各図において共通の構成については同一の参照符号が付されている。

（１）本実施の形態による故障診断装置の構成
図１において、１は全体として本実施の形態による故障診断装置を示す。この故障診断装置１は、過去に作成された複数の事故報告書から不具合情報をそれぞれ抽出し、抽出したこれらの不具合情報に基づいて故障診断を行うコンピュータ装置であり、ＣＰＵ２、主記憶装置３、入出力装置４及び補助記憶装置５を備えて構成される。

ＣＰＵ２は、故障診断装置１全体の動作制御を司るプロセッサである。ＣＰＵ２は、補助記憶装置５に格納されたプログラムを故障診断装置１の起動時や必要時に主記憶装置３にロードし、ロードしたプログラムを実行することにより各種処理を実行する。なおプログラムは、図示しないネットワークを介して外部サーバから主記憶装置３にロードするようにしてもよい。

主記憶装置３は、例えば、揮発性の半導体メモリから構成され、ＣＰＵ２のワークメモリとして利用される。また入出力装置４は、キーボードやマウスなどの入力装置と、液晶ディスプレイなどの表示装置とから構成される。入力装置は、ユーザが各種情報や指示を入力するために利用され、表示装置は、必要な情報やＧＵＩ（Graphical User Interface）画面を表示するために利用される。

補助記憶装置５は、ハードディスク装置、ＳＳＤ（Solid State Drive）又はフラッシュメモリなどの計算機（コンピュータ）で読取り可能な大容量の不揮発性の記憶装置から構成される。補助記憶装置５には、各種プログラムや、各種データが格納される。本実施の形態においては、かかるプログラム及びデータとして、事故報告書データベース１０、ＯＳ（Operating System）１１、不具合情報抽出プログラム１２、故障診断プログラム１３、不具合情報テーブル１４及び機器・部品階層関係辞書１５が補助記憶装置５に格納される。

事故報告書データベース１０は、過去に作成された事故報告書１６が蓄積されたデータベースである。また事故報告書１６は、過去の不具合に関する調査内容、調査結果及びそのとき実行した対策などの事例が記載された文書である。フォーマットは規定されている場合も，任意である場合もある。

不具合情報抽出プログラム１２は、事故報告書データベース１０に登録されている各事故報告書１６から不具合情報を抽出して不具合情報テーブル１４に登録する機能を有するプログラムである。例えば、事故報告書データベース１０に登録された各事故報告書１６の内容がそれぞれ図２のようなものであったとする。図中、斜体太字の部分は機器・部品を表し、下線の部分は不具合事象を表す。この場合、不具合情報抽出プログラム１２は、例えば文書ＩＤが「00001」の事故報告書１６からは、「エンジン」の「オイル交換忘れ」という不具合情報と、「シリンダ」の「圧縮圧力低下」という不具合情報とを抽出し、抽出したこれらの不具合情報を不具合情報テーブル１４に登録する。

なお、文書ＩＤが「00001」の事故報告書１６に関連して、「のため」という接続関係を示す表現がある場合、前者が後者を引き起こす、逆に言えば、後者が発生している場合には、前者が原因となる可能性があると推定することができる、このような原因と現象との関係（因果関係）に基づいて、故障原因を推定することもできる。

故障診断プログラム１３は、ユーザにより入力された不具合事象に類似する過去の事例の不具合情報を抽出し、抽出した不具合情報に基づいて故障原因を推定し、推定結果に基づく対処方法をユーザに提示する機能を有するプログラムである。具体的に、故障診断プログラム１３は、ユーザにより入力された、故障原因を診断する対象となる不具合事象に類似する不具合情報を不具合情報テーブル１４上で検索し、当該検索により検出した不具合情報に基づいてその不具合事象の対処方法をユーザに提示する。

不具合情報テーブル１４は、不具合情報抽出プログラム１２が事故報告書１６から抽出した不具合情報を管理するために利用するテーブルであり、図３に示すように、文書ＩＤ欄１４Ａ、事象ＩＤ欄１４Ｂ、故障機器・部品欄１４Ｃ及び不具合事象欄１４Ｄを備えて構成される。不具合情報テーブル１４では、１つの行が不具合情報抽出プログラム１２により１つの事故報告書から抽出された１つの不具合情報に対応する。１つの事故報告書から、複数の不具合情報が抽出されることもあり、その場合、同一の文書ＩＤを持ち、異なる事象ＩＤを持つ複数の行が存在することとなる。

そして文書ＩＤ欄１４Ａには、対応する不具合情報を抽出した事故報告書１６に付与されたその事故報告書１６に固有の識別子（文書ＩＤ）が格納され、事象ＩＤ欄１４Ｂには、その不具合情報に付与されたその不具合情報に固有の識別子（事象ＩＤ）が格納される。また不具合事象欄１４Ｄには、対応する事故報告書２６から抽出した具体的な不具合事象が格納され、故障機器・部品欄１４Ｃには、当該事故報告書１６から抽出されたその不具合事象が発生した機器・部品（以下、適宜、これを故障機器・部品と呼ぶ）の名称が格納される。

従って、図３の例の場合、「00001」という文書ＩＤが付与された事故報告書１６から「エンジン」の「オイル交換忘れ」という不具合情報と、「シリンダ」の「圧縮圧力が低下」という不具合事象とが抽出され、前者の不具合事象には「0000001」という事象ＩＤが付与されると共に、後者の不具合事象には「0000002」という事象ＩＤが付与されたことが示されている。なお、以下の説明においては、不具合情報の内容を「故障機器・部品の名称／不具合事象」の形式で表記するものとする。例えば、「エンジン」の「オイル交換忘れ」という不具合情報については「エンジン／オイル交換忘れ」と表記し、「シリンダ」の「圧縮圧力が低下」という不具合情報については「シリンダ／圧縮圧力が低下」と表記する。

機器・部品階層関係辞書は、図４に示すような機器・部品間の階層関係（親子関係）を管理するために利用される辞書であり、図５に示すように、部品ＩＤ欄１５Ａ、故障機器・部品欄１５Ｂ及び親部品欄１５Ｃを備えるテーブル状の構成を有する。機器・部品階層関係辞書１５では、１つの行が１つの機器・部品間の親子関係に相当する。

そして故障機器・部品欄１５Ｂには、機器・部品の名称が格納され、機器・部品ＩＤ欄１５Ｂには、その機器・部品に付与されたその機器・部品に固有の識別子（部品ＩＤ）が格納される。また親部品欄１５Ｃには、故障機器・部品欄１５Ｂに名称が格納された機器・部品の親部品の名称が格納される。

なお、この機器・部品階層関係辞書１５は、部品表（ＢＯＭ：Bill of materials）などの構造データに基づいて作成することができるが、処理対象の事故報告書１６などのテキストから自動的に作成することもできる。この場合には、テキスト内の「ＡのＢ」のような表現を手掛かりとして機器・部品間の親子関係（包含関係）を判断しながら機器・部品階層関係辞書１５を作成する。

例えば、「バッテリの端子」のように２個の部品が「の」により接続されている場合には、これらの部品が親子関係にある可能性が高いため、「端子」が「バッテリ」の部品であると推定することができる。同様に、「ＡＢ」のような表現も２個の部品の親子関係を推定するための手掛かりとなる。例えば、「バッテリ端子」のように２個の部品が隣接して存在する場合、これらの部品が親子関係にある可能性が高く、「端子」が「バッテリ」の一部品（「バッテリ」が「端子」の親部品）であると推定することができる。

（２）本実施の形態による不具合抽出機能
（２−１）本実施の形態による不具合抽出機能の概要
ところで、図２の文書ＩＤが「00002」の事故報告書１６の内容に対して不具合情報抽出プログラム１２が単純に不具合情報を抽出する処理を実行した場合、「バッテリ／経年劣化」という不具合情報と、「端子／腐食」という不具合情報とが抽出される。

しかしながら、後者の不具合情報は、故障した部品が「端子」というだけでは情報として不十分である。つまり、この例の場合、「端子」は「バッテリ」の端子を指していると推定されるが、「バッテリ」という情報が省略されているため、「端子」が「バッテリ」の端子を指しているのか、または「スパークプラグ」の端子を差しているのかが明確ではない（図４参照）。このため、このような不具合情報に基づいて実行された故障診断処理において、故障原因候補として「端子の腐食」との診断結果が提示されたとしても、ユーザはどの機器・部品の「端子」の腐食が故障原因であるかを特定することができない。

この場合、人間が事故報告書１６を読む際には、省略された要素を自然と補完するため、上述のように「端子」の直前に「バッテリ」という親部品の名称が存在しない場合でも特に問題とはならない。しかしながら、事故報告書１６から部分的に不具合情報のみを抽出するに際しては、省略された要素を何らかの方法により補完する必要がある。

そこで、本実施の形態の故障診断装置の場合、不具合情報において記載が省略されている情報（ここでは親部品）を推定し、その情報をその不具合情報に追加するようにして不具合情報を補完する親部品推定機能が不具合情報抽出プログラム１２に搭載されている。実際上、不具合情報抽出プログラム１２は、図５について上述した機器・部品階層関係辞書１５を利用してそのとき注目している部品（以下、これを注目部品と呼ぶ）の親部品の候補（以下、これを親部品候補と呼ぶ）を取得し、対応する事故報告書１６のテキスト内でその親部品候補の名称を探索することでその注目部品の親部品を推定して、その名称を不具合情報に追加する。

例えば、図２の文書ＩＤが「00002」の例において、「端子」が注目部品の場合、不具合情報抽出プログラム１２は、機器・部品階層関係辞書１５を参照して、親部品候補として「バッテリ」及び「スパークプラグ」を取得し、その後、文書ＩＤが「00002」の事故報告書１６のテキスト内で親部品候補の「バッテリ」及び「スパークプラグ」という文字列を探索する。この結果、不具合情報抽出プログラム１２は、かかるテキスト内で「バッテリ」という文字列を検出するため、そのときの注目部品である「端子」の親部品を「バッテリ」と推定する。なお、対応する事故報告書１６のテキストを探索する際には、通常、注目部品の単語よりも前の範囲を探索するが、当該単語よりも後の範囲や、対応する事故報告書のテキスト全体を探索するようにしてもよい。

一方で、図２における文書ＩＤが「00001」の事故報告書１６の場合、「シリンダ」は「エンジン」の一部品であるが、例えば、故障診断プログラム１３により実行される故障診断処理において、故障原因候補として「シリンダ」の親部品である「エンジン」を省略して「シリンダ内圧縮圧力が低下」と表示したとしてもユーザは故障原因や故障箇所を確実に特定することができる。逆に、この例で「エンジンのシリンダ」のように「エンジン」が補完されると、却って冗長だと感じられる。

これは、「端子」が様々部品の一部として存在しているため、どの部品の「端子」であるかが故障原因特定の重要な情報となるのに対して、「シリンダ」は「エンジン」にしか存在しない部品であるため、「シリンダ」という表記だけで故障原因や故障箇所を特定できることが理由である。このように不具合情報に上位部品（親部品）の名称が欠落している場合に、その上位部品の名称を不具合情報に補う必要があるか否かは、その部品の性質に依存する。

そこで本実施の形態の場合、不具合情報抽出プログラム１２には、上述した親部品推定機能に基づく処理に先駆けて、まず、注目部品の親部品を推定する必要があるか否かを判断する部品曖昧性判定機能も搭載されている。部品曖昧性判定機能は、注目部品の親部品が複数存在するか否かに基づいて、注目部品に曖昧性があるか否かを判定する機能である。

この場合、不具合情報抽出プログラム１２は、機器・部品階層関係辞書１５を参照して、注目部品の親部品が複数存在する場合には、その注目部品に曖昧性があると判断する。例えば、図５の例の場合、部品ＩＤが「0006」及び「0007」の行を参照すると、両方とも故障機器・部品が「端子」であり、それぞれの親部品は異なっている。このため不具合情報抽出プログラム１２は、注目部品が「端子」である場合、その注目部品に曖昧性があると判断することになる。

そして不具合情報抽出プログラム１２は、注目部品に曖昧性があると判断した場合にのみ、その親部品を上述の親部品推定機能により推定し、推定した親部品の名称を不具合情報テーブル１４におけるその注目部品の不具合情報の故障機器・部品欄１４Ｃに追加する。

他方、例えば図３の不具合情報テーブル１４における文書ＩＤが「00003」の事故報告書１６について抽出された「エンジン／圧縮圧力が低下」という不具合情報（事例ＩＤが「0000005」の不具合情報）は、文書ＩＤが「00001」の事故報告書１６について抽出された「シリンダ／圧縮圧力が低下」という不具合情報（事例ＩＤが「0000002」の不具合情報）と同一の不具合事象を表す不具合情報であり、「エンジンのシリンダ」という表現から「シリンダ」という部品の名称が省略された表現となっている。

このように不具合情報では、１つの機器・部品にしか存在しない下位の機器・部品については記載が省略されていることも多い。このような場合においても、コンピュータ装置が、事象ＩＤが「0000002」の「シリンダ／圧縮圧力が低下」という不具合と、事象ＩＤが「0000001」の「エンジン／圧縮圧力が低下」という不具合と、事象ＩＤが「0000007」の「エンジン，シリンダ／圧縮圧力が低下」という不具合とを同一の不具合事象として集約できるようにすることが必要である。

そこで本実施の形態の場合、不具合情報抽出プログラム１２には、図３における事象ＩＤが「0000002」の不具合と、事象ＩＤが「0000005」の不具合と、事象ＩＤが「0000007」の不具合とを同一の不具合事象を表す不具合情報として取り扱えるように、故障機器・部品の親子関係の系列を要約する部品系列正規化機能が搭載されている。

この部品系列正規化機能は、「シリンダ／圧縮圧力が低下」や、「エンジン／圧縮圧力が低下」及び「エンジン，シリンダ／圧縮圧力が低下」といった異なる表現ではあるものの同一の不具合事象を表す不具合情報を「エンジン／圧縮圧力が低下」のように同じ親子関係の系列内の１つの故障機器・部品の不具合事象に集約する機能である。以下においては、このように同一の不具合事象が発生した同じ親子関係の系列に属する複数の故障機器・部品の不具合情報を、当該系列内の１つの故障機器・部品の不具合事象にそれぞれ集約（修正）することを「部品系列正規化」又は「部品系列を正規化する」と呼び、このような部品系列正規化を行う処理を「部品系列正規化処理」と呼ぶものとする。

なお不具合情報抽出プログラム１２は、図３における事象ＩＤが「0000008」の不具合情報と、事象ＩＤが「0000010」の不具合情報とのように、不具合事象が同じ「汚れ」であっても、その不具合事象が発生した故障機器・部品が異なる親子関係の系列に属する場合には、これらの不具合情報の集約（修正）は不要であると判定し、これらについては部品系列正規化処理を実行しない。

以上のような親部品推定機能、部品曖昧性判定機能及び部品系列正規化機能を含む本実施の形態の不具合情報抽出機能を実現するための手段として、不具合情報抽出プログラム１２は、図１に示すように、故障機器・部品抽出サブプログラム２０、不具合事象抽出サブプログラム２１、機器・事象対応付けサブプログラム２２及び故障機器・部品変更サブプログラム２３を備えて構成されている。これら故障機器・部品抽出サブプログラム２０、不具合事象抽出サブプログラム２１、機器・事象対応付けサブプログラム２２及び故障機器・部品変更サブプログラム２３の具体的な処理内容について後述する。

（２−２）本実施の形態の不具合情報抽出機能に関する各種処理
次に、かかる本実施の形態の不具合情報抽出機能に関連して実行される各種処理の具体的な処理内容について説明する。なお、以下においては、各種処理の処理主体を「サブプログラム」として説明するが、実際には、その「サブプログラム」に基づいてＣＰＵがその処理を実行することは言うまでもない。

（２−２−１）不具合情報抽出処理
図６は、かかる不具合情報抽出機能に関連して不具合情報抽出プログラム１２の故障機器・部品抽出サブプログラム２０、不具合事象抽出サブプログラム２１、機器・事象対応付けサブプログラム２２及び故障機器・部品変更サブプログラム２３により順次実行される一連の処理（以下、これを不具合情報抽出処理と呼ぶ）の流れを示す。

この不具合情報抽出処理は、定期的又はユーザ等の指示に応じて不定期に開始される。そして、この不具合情報抽出処理が開始されると、まず、故障機器・部品抽出サブプログラム２０が、事故報告書データベース１０に登録されたすべての事故報告書１６について、その事故報告書１６のテキストから故障機器・部品の名称をすべて抽出する（Ｓ１）。

テキストからの故障機器・部品の名称の抽出は、例えば、事故報告書１６のテキスト内に名称が存在する可能性のあるすべての機器・部品の名称が登録された辞書を予め準備し、この辞書と、事故報告書１６のテキストとを順次文字列照合することによって行うことができる。また例えば、特開２０１０−０９２３５２号公報に開示されているような系列ラベリング技術を用いることによっても行うことができる。抽出した故障機器・部品の名称は、名寄せ処理により表現を統一した上で主記憶装置３（図１）に一時的に格納しておく。

続いて、不具合事象抽出サブプログラム２１が、事故報告書データベース１０に登録されたすべての事故報告書１６について、その事故報告書１６のテキストから不具合事象をすべて抽出する（Ｓ２）。テキストからの不具合事象の抽出は、ステップＳ１について上述したテキストからの故障機器・部品の名称の抽出と同様に行うことができる。このとき抽出された不具合事象は、名寄せ処理により表現を統一した上で主記憶装置３に一時的に格納しておく。

次いで、機器・事象対応付けサブプログラム２２が、ステップＳ１で名称が抽出された各故障機器・部品と、ステップＳ２で抽出された各不具合事象とをそれぞれ対応付けて、不具合情報として不具合情報テーブル１４に登録する（Ｓ３）。

ただし、事故報告書１６中に出現する機器・部品のすべてが故障機器・部品であるとは限らない。例えば、「部品Ａを調査したが異常がなかったため」といった記載もあり得る。このため機器・事象対応付けサブプログラム２２は、故障機器・部品と不具合事象とを対応付けることによって、故障機器・部品及び不具合事象のペアを生成する。このときの対応付けは、単純に距離が近いペアを対応付けるといった方法を適用することができる。この場合、部品が前に出現することが多いため、出現順序を利用しても良い。また構文解析技術、係り受け解析技術を利用してもよい。

そして機器・事象対応付けサブプログラム２２は、このような処理により生成した故障機器・部品の名称及び不具合事象のペアについて、その故障機器・部品の名称を図３の故障機器・部品欄１４Ｃ、不具合事象を不具合事象欄１４Ｄ、その事象に付与した事象ＩＤを事象ＩＤ欄１４Ｂ、その故障機器・部品の名称及びその不具合事象を抽出した事故報告書１６の文書ＩＤを文書ＩＤ欄１４Ａにそれぞれ格納するようにして、そのペアを不具合情報として不具合情報テーブル１４に登録する。

この後、故障機器・部品変更サブプログラム２３が、不具合情報テーブル１４に登録されている各不具合情報の修正を必要に応じて行う故障機器・部品情報変更処理を実行する（Ｓ４）。具体的に、故障機器・部品変更サブプログラム２３は、事故報告書データベース１０に格納されている対応する事故報告書１６と、機器・部品階層関係辞書１５とを参照して、情報が不足している不具合情報については不足している情報を追加し、複数の不具合情報間で同一の不具合事象に対する表記・表現に揺れがある場合には上述の部品系列正規化処理を実行する。

そしてステップＳ４の処理が完了すると、この不具合情報抽出処理が終了する。

（２−２−２）故障機器・部品情報変更処理
図７は、図６について上述した不具合情報抽出処理のステップＳ４において故障機器・部品変更サブプログラム２３により実行される一連の処理（以下、これを故障機器・部品情報変更処理と呼ぶ）の流れを示す。

故障機器・部品変更サブプログラム２３は、不具合情報抽出処理がステップＳ４に進むとこの図７に示す故障機器・部品情報変更処理を開始し、まず、不具合情報テーブル１４に登録されたすべての不具合情報についてステップＳ１１以降の処理を実行し終えたか否かを判定する（Ｓ１０）。

そして故障機器・部品変更サブプログラム２３は、ステップＳ１０の判定で否定結果を得ると、不具合情報テーブル１４に登録されている不具合情報の中から１つの不具合情報（不具合情報テーブル１４の１行分の情報）を読み出すことにより取得する（Ｓ１１）。

続いて、故障機器・部品変更サブプログラム２３は、ステップＳ１１で取得した不具合情報から故障機器・部品の名称を取得し、その故障機器・部品を注目部品に設定する（Ｓ１２）。

次いで、故障機器・部品変更サブプログラム２３は、そのときの注目部品に曖昧性があるか否かを判断する（Ｓ１３）。上述のように機器・部品の曖昧性の判断は、機器・部品階層関係辞書１５（図５）を参照して、注目部品の親部品が複数存在するか否かを確認することにより行う。例えば、注目部品が「端子」である場合には、「スパークプラグ」及び「バッテリ」という２種類の親部品が存在するため、曖昧性があると判断する。

なお、以上の説明では、データや処理結果が理想的な場合を例に、親部品の種類が２種類以上であれば曖昧性があるとしたが、実際上は、図７のステップＳ１において故障機器・部品の名称を完全に名寄せすることは難しい。また機器・部品階層関係辞書１５が自動作成されたものである場合、作成された機器・部品階層関係辞書１５に誤りが含まれる可能性もある。このような状況を考慮した場合、予め２より大きい数値の閾値を設定しておき、注目部品の親部品の数がその閾値を超えた場合に、故障機器・部品変更サブプログラム２３がその注目部品に曖昧性があると判断するようにしてもよい。

また注目部品の曖昧性を完全に親部品の種類数に依存するのではなく、注目部品の親部品として機器・部品階層関係辞書１５から抽出された機器・部品同士の類似性を考慮して、注目部品の曖昧性を判断するようにしてもよい。例えば、図５の例では、「原動機」が「エンジン」に名寄せされることを想定しているが、名寄せに失敗して「ピストン」の親部品として「エンジン」及び「原動機」の２種類の部品が機器・部品階層関係辞書１５から抽出される場合もあり得る。このような場合、例えば、特開２０１２−１８５７０号公報に開示されているような技術を用いて「エンジン」という単語と、「原動機」という単語の類似度をスコアとして算出し、算出したスコアに基づいてこれら「エンジン」及び「原動機」が同じものを指しているか否かを判定し、その判定結果に基づいて注目部品の曖昧性を判断するようにすればよい。

故障機器・部品変更サブプログラム２３は、ステップＳ１３の判断で否定結果を得た場合にはステップＳ１０に戻る。これに対して故障機器・部品変更サブプログラム２３は、ステップＳ１３の判断で肯定結果を得た場合には、注目部品の親部品を推定する（Ｓ１４）。具体的に、故障機器・部品変更サブプログラム２３は、注目部品の上述した親部品候補を機器・部品階層関係辞書１５から取得し、対応する事故報告書１６のテキスト内でその親部品候補の名称を探索し、この名称を検出できたときにはその親部品候補を注目部品の親部品を推定する。

例えば、図３の事象ＩＤが「0000004」の不具合情報を処理している場合、「端子」の親部品候補として「スパークプラグ」及び「バッテリ」の２種類が親部品候補として抽出され、これらの名称を図２における文書ＩＤが「00002」の事故報告書１６のテキスト内で探索した場合に「バッテリ」が検出されるため、この「バッテリ」が注目部品（ここでは「端子」）の親部品と推定されることになる。

そして故障機器・部品変更サブプログラム２３は、上述のようにして推定した親部品の名称を不具合情報テーブル１４における対応する故障機器・部品欄１４Ｃ（図３）に追記する。例えば、上述の例の場合、故障機器・部品変更サブプログラム２３は、図３における事象ＩＤが「0000004」の故障機器・部品欄１４Ｃを「端子」から図８のように「バッテリ，端子」に書き換える。

この後、故障機器・部品変更サブプログラム２３は、ステップＳ１０に戻る。そして故障機器・部品変更サブプログラム２３は、さらにこの後、ステップＳ１１で選択する不具合情報を未処理の他の不具合情報に順次切り替えながら、ステップＳ１０において肯定結果を得るまでステップＳ１１以降の処理を上述と同様に繰り返す。

そして故障機器・部品変更サブプログラム２３は、やがて不具合情報テーブル１４に登録されたすべての不具合情報についてステップＳ１１〜ステップＳ１４の処理を実行し終えることによりステップＳ１０で肯定結果を得ると、不具合情報テーブル１４に登録されているすべての不具合情報を、不具合事象ごとにグルーピングする（Ｓ１５）。このグルーピングにより、例えば図８の例では、不具合情報テーブル１４に登録されている不具合情報が、不具合事象がそれぞれ「オイル交換忘れ」、「圧縮圧力が低下」、「経年劣化」、「腐食」、「汚れ」又は「振動」である６つのグループ（以下、これらを不具合情報グループと呼ぶ）に分けられることになる。

続いて、故障機器・部品変更サブプログラム２３は、ステップＳ１５で生成したすべての不具合情報グループに対して、ステップＳ１８の部品系列正規化処理を実行し終えたか否かを判断する（Ｓ１６）。

そして故障機器・部品変更サブプログラム２３は、この判断で否定結果を得ると、不具合情報グループのうち、ステップＳ１８の処理を未処理の不具合情報グループを１つ選択し（Ｓ１７）、選択した不具合情報グループに対して上述した部品系列正規化処理を実行する（Ｓ１８）。

さらに故障機器・部品変更サブプログラム２３は、ステップＳ１６に戻り、この後、ステップＳ１７で選択する不具合情報グループをステップＳ１８の部品系列正規化処理が未処理の他の不具合情報グループに順次切り替えながら、ステップＳ１６〜ステップＳ１８の処理を繰り返す。

そして故障機器・部品変更サブプログラム２３は、やがてステップＳ１５で生成したすべての不具合情報グループについてステップＳ１８の処理を実行し終えることによりステップＳ１６で肯定結果を得ると、この故障機器・部品情報変更処理を終了して不具合情報抽出処理（図６）のステップＳ４に戻る。

（２−２−３）部品系列正規化処理
図９は、図７について上述した故障機器・部品情報変更処理のステップＳ１８において故障機器・部品変更サブプログラム２３により実行される部品系列正規化処理の具体的な処理内容を示す。故障機器・部品変更サブプログラム２３は、この図９に示す処理手順に従って、同一の不具合が発生した同じ親子関係の系列に属する複数の故障機器・部品の不具合情報を、当該系列内の１つの故障機器・部品の不具合事象にそれぞれ集約（修正）する部品系列正規化処理を実行する。

実際上、故障機器・部品変更サブプログラム２３は、故障機器・部品情報変更処理（図７）のステップＳ１８に進むと、この図９に示す部品系列正規化処理を開始し、まず、初期状態の図１０に示すような正規化処理テーブル２４を生成する（Ｓ２０）。

この正規化処理テーブル２４は、この部品系列正規化処理を実行する際に利用するテーブルであり、図１０に示すように、部品ＩＤ欄２４Ａ、故障機器・部品欄２４Ｂ、不具合フラグ欄２４Ｃ、葉ノードフラグ欄２４Ｄ及び分岐数欄２４Ｅを備えて構成される。

そして故障機器・部品欄２４Ｂには、機器・部品階層関係辞書１５（図５）に掲載されているすべての機器・部品の名称が格納され、部品ＩＤ欄２４Ａには、その機器・部品の部品ＩＤが格納される。また不具合フラグ欄２４Ｃには、後述する不具合フラグが格納され、葉ノードフラグ欄２４Ｄには、後述する葉ノードフラグが格納される。これら不具合フラグ及び葉ノードフラグは、初期時には「０」に設定される。さらに分岐数欄２４Ｅには、対応する機器・部品について算出された後述の分岐数が格納される。各機器・部品の分岐数も、初期時には「０」に設定される。

続いて、故障機器・部品変更サブプログラム２３は、そのとき対象としている不具合情報グループの各不具合情報について、正規化処理テーブル１４の各行のうちのその不具合情報に対応する行（その不具合情報の故障機器・部品の名称が故障機器・部品欄１４Ｃに格納された行）の不具合フラグ欄２４Ｃに格納されている不具合フラグをオンに設定（不具合フラグの値を「１」に設定）する（Ｓ２１）。

例えば、図８の例において、不具合事象が「圧縮圧力が低下」である不具合情報グループを対象としている場合（以下、この例を「例１」と呼ぶ）、その不具合情報グループに属する事象ＩＤが「0000002」の不具合情報、事象ＩＤが「0000005」の不具合情報及び事象ＩＤが「0000007」の不具合情報にそれぞれ対応する機器・部品の不具合フラグがオンに設定される。

また図８の例において、不具合事象が「汚れ」である不具合情報グループを対象としている場合（以下、この例を「例２」と呼ぶ）、その不具合情報グループに属する事象ＩＤが「0000008」の不具合情報及び事象ＩＤが「0000010」の不具合情報にそれぞれ対応する機器・部品の不具合フラグがオンに設定される。

次いで、故障機器・部品変更サブプログラム２３は、機器・部品階層関係辞書１５（図５）を参照して、図４のツリー構造で葉ノードとなるすべての機器・部品を抽出し、正規化処理テーブル２４におけるこれらの機器・部品にそれぞれ対応する行の葉ノードフラグ欄２４Ｄに格納されている葉ノードフラグをオンに設定（葉ノードフラグを「１」に設定）する（Ｓ２２）。ここで、「葉ノード」とは、ツリー構造において子ノードを持たないノードを指す。図４の例では、「シリンダ」、「ピストン」、「端子」及び「電解液」が葉ノードであるため、正規化処理テーブル２４におけるこれらの機器・部品に対応する葉ノードフラグがそれぞれ「１」に設定される。

この後、故障機器・部品変更サブプログラム２３は、各機器・部品の分岐数をそれぞれ決定し、決定した分岐数を正規化処理テーブル２４における対応する分岐数欄２４Ｅにそれぞれ格納する後述の分岐数決定処理を実行する（Ｓ２３）。

さらに故障機器・部品変更サブプログラム２３は、ステップＳ２３で決定した各機器・部品の分岐数に従って、そのとき対象としている不具合情報グループに属する各不具合情報の故障機器・部品を正規化（部品系列正規化）する（Ｓ２４）。

具体的に、故障機器・部品変更サブプログラム２３は、そのとき対象としている不具合情報グループ内の任意の２個の不具合情報にそれぞれ含まれる故障機器・部品を取得し、図４のツリー構造の中からこれらの故障機器・部品を含む最小の部分木を抽出する。そして故障機器・部品情報変更サブプログラム２３は、このようにして抽出した部分木の最も上位階層の故障機器・部品であるルートノードの分岐数（そのルートノードの分岐数）が１であれば、これらの故障機器・部品を正規化の対象とし、かかる２個の不具合情報における故障機器・部品をその部分木上で最もルールノードに近いノードに修正する。また故障機器・部品変更サブプログラム２３は、かかる部分木のルートノードの分岐数が２以上であれば、これらの故障機器・部品を正規化の対象外とし、かかる２個の不具合情報における故障機器・部品の修正を行わない。

そして故障機器・部品変更サブプログラム２３は、このステップＳ２４の処理を終了すると、この部品系列正規化処理を終了して故障機器・部品情報変更処理（図７）のステップＳ１８に戻る。

なお部品系列正規化処理（図９）のステップＳ２３において故障機器・部品変更サブプログラム２３により実行される分岐数決定処理の具体的な処理内容を図１１に示す。

故障機器・部品変更サブプログラム２３は、部品系列正規化処理のステップＳ２３に進むと、この図１１に示す分岐数決定処理を開始し、まず、機器・部品階層関係辞書１５（図５）を参照して、当該機器・部品階層関係辞書１５に基づくツリー構造（図４）のルートノードを注目ノードに設定し、その注目ノードが葉ノードであるか否かを判断する（Ｓ３０）。例えば、図４及び図５の例では、「自動車」がこのときの注目ノードに設定される。

そして故障機器・部品変更サブプログラム２３は、この判断で否定結果を得ると、その注目ノードのすべての子ノードについて、この分岐数決定処理を再帰呼出しする（その子ノードを注目ノードとしてこの分岐数決定処理をそれぞれ実行する）ことにより、これら子ノードの分岐数をそれぞれ算出する（Ｓ３１）。

続いて、故障機器・部品変更サブプログラム２３は、ステップＳ３１の算出結果に基づいて、そのときの注目ノードの分岐数を算出する（Ｓ３２）。具体的に、故障機器・部品変更サブプログラム２３は、ステップＳ３１で取得した各子ノードの分岐数の合計を算出し、算出した合計値が０よりも大きい場合には、その合計値をその注目ノードの分岐数とする。また故障機器・部品変更サブプログラム２３は、算出した合計値が「０」の場合には、正規化処理テーブル２４（図１０）におけるその注目ノードの不具合フラグの値を取得し、その値が「１」のときにはその注目ノードの分岐数を「１」とし、その値が「０」のときにはその注目ノードの分岐数と「０」とする。そして故障機器・部品変更サブプログラム２３は、この後、そのときの注目ノードに対するこの分岐数決定処理を終了して呼出し元の処理に戻る。

これに対して、故障機器・部品変更サブプログラム２３は、ステップＳ３０の判断で肯定結果を得ると、正規化処理テーブル２４からそのときの注目ノードの不具合フラグを取得し、取得した不具合フラグの値に応じてその注目ノードの分岐数を決定する（Ｓ３３）。具体的に、故障機器・部品変更サブプログラム２３は、そのとき取得した注目ノードの不具合フラグの値が「１」のときには注目ノードの分岐数を「１」とし、その不具合フラグの値が「０」のときは注目ノードの分岐数を「０」とする。そして故障機器・部品変更サブプログラム２３は、この後、そのときの注目ノードに対するこの分岐数決定処理を終了して呼出し元の処理に戻る。

以上のような図９及び図１１の処理によって、上述した「例１」及び「例２」は以下のように処理される。

まず「例１」の場合、図９のステップＳ２１及びステップＳ２２により正規化処理テーブル２４が図１２（Ａ）のように更新され、その後、図１１のステップＳ３０において最初に「自動車」が注目ノードに設定される。そして「自動車」は葉ノードではないため、図１１のステップＳ３１において「自動車」の子ノードである「エンジン」及び「バッテリ」に対して分岐数決定処理の再帰呼出しが行われる（図４参照）。

この場合、「エンジン」も葉ノードではないため、「エンジン」の子ノードである「シリンダ」、「ピストン」及び「スパークプラグ」に対してさらに分岐数決定処理の再帰呼出しが行われる（図４参照）。そして「シリンダ」は葉ノードであるため、図１２（Ａ）の正規化処理テーブル２４における「シリンダ」の不具合フラグの値がオンに設定されているか否かを確認する。「例１」では、「シリンダ」の不具合フラグはオフ（不具合フラグの値が「０」）であるため、「シリンダ」の分岐数は「１」となる。同様にして、「ピストン」及び「スパークプラグ」の分岐数はいずれも「０」として算出される。この結果、「エンジン」の分岐数は「１」として算出される。

そして図４のツリー構造において、「エンジン」、「シリンダ」及び「エンジンのシリンダ」を含む最小の部分木のルートノードは「エンジン」であり、「エンジン」の分岐数が「１」であるため、「エンジン」、「シリンダ」及び「エンジンのシリンダ」は正規化の対象となり、最も上位の「エンジン」に集約される。そして、この集約に応じて、図８の不具合情報テーブル１４が図１３のように更新される。この図１３に示すように、「例１」の場合は、事象ＩＤがそれぞれ「0000002」、「0000005」及び「0000007」の不具合情報については、故障機器・部品が「エンジン」に集約されて、これらを故障診断の際に同じ不具合事象としてカウントできる状態となっている。なお、例では「エンジン」に集約したが、「エンジン」、「シリンダ」及び「エンジンのシリンダ」の出現頻度を比較し、最も頻度が高い、すなわち良く使用される表現に統一しても良い。

また「例２」の場合、図９のステップＳ２１及びステップＳ２２により正規化処理テーブル２４が図１２（Ｂ）のように更新され、その後、図１１のステップＳ２０において最初に「自動車」が注目ノードに設定される。この後、「例１」と同様の処理が行われるが、この「例２」の場合には葉ノードである「シリンダ」の不具合フラグがオンに設定されていないため、「シリンダ」の分岐数が「０」として算出される。同様に「ピストン」の分岐数は「１」に設定される。また「スパークプラグ」は葉ノードではないため、さらに「端子」について分岐数決定処理の再帰呼出しが行われる（図４参照）。このとき「端子」は葉ノードであり、その不具合フラグのオフであるため、「端子」の分岐数は「０」として算出される。また「スパークフラグ」は、子ノードの分岐数の合計が「０」であり、対応する不具合フラグがオフであるため、分岐数が「１」として算出される。また「エンジン」の分岐数は「２」として算出される。

そして図４のツリー構造において、「ピストン」及び「スパークプラグ」を含む最小の部分木のルートノードは「エンジン」であり、「エンジン」の分岐数は「２」であるため、「ピストン」及び「スパークプラグ」は正規化の対象とならず、これら「ピストン」及び「スパークプラグ」は集約されない。このため「例２」の場合には、事象ＩＤが「0000008」及び「0000010」の不具合情報が更新されず、図８のままとなる。

（３）故障診断処理
次に、故障診断プログラム１３（図１）により実行される故障診断処理について説明する。故障診断プログラム１３は、入出力装置４（図１）を介したユーザからの所定の操作入力に応じて図１４に示すような検索画面３０を入出力装置４に表示する。

この検索画面３０は、そのとき発生している不具合事象の原因候補を検索するための画面であり、発生事象入力欄３１、診断ボタン３２及び原因候補提示領域３３を備えて構成される。そして、ユーザは、検索画面３０を用いて不具合事象の原因候補を検索する場合、入出力装置４を用いて「エンジンに振動がある」などのように故障機器・部品及びその不具合事象を自然文形式で発生事象入力欄３１に入力し、その後、診断ボタン３２をクリックする。

故障診断プログラム１３は、かかる診断ボタン３２がクリックされると、発生事象入力欄３１に入力された自然文に対して形態素解析などを含む既存の自然言語解析処理を施すことにより、そのとき発生している不具合事象や、故障機器・部品の名称を抽出する。図１４の例では、不具合事象として「振動」、故障機器・部品の名称として「エンジン」が抽出される。

そして故障診断プログラム１３は、抽出したこれら不具合事象や故障機器・部品の名称をキーワードとして、これらキーワードを含む事故報告書１６を事故報告書データベース１０（図１）上で検索する。図２の例の場合、かかる事故報告書１６として、文書ＩＤが「00005」の事故報告書１６と、文書ＩＤが「00006」の事故報告書１６とが少なくともヒットする。

また故障診断プログラム１３は、このときヒットした事故報告書１６の不具合情報を不具合情報テーブル１４（図３）から取得する。例えば、図３の例の場合、少なくとも事象ＩＤがそれぞれ「0000008」〜「0000011」である４つの不具合情報が取得される。

続いて、故障診断プログラム１３は、取得したこれらの不具合情報の中から発生事象入力欄３１に入力された不具合事象と同じ不具合事象の不具合情報を除去する。従って、図３及び図１４の例では、図３の少なくとも事象ＩＤがそれぞれ「0000009」及び「0000011」である２つの不具合情報が除去され、少なくとも事象ＩＤがそれぞれ「0000008」及び「0000010」である２つの不具合情報が残る。

さらに故障診断プログラム１３は、残った不具合情報について、機器・部品及び不具合事象が同じ不具合情報の件数を機器・部品及び不具合事象の組合せごとにそれぞれ集計し、件数が多い機器・部品及び不具合事象の組合せの順番で、予め定められた数だけ、対応する機器・部品及び不具合事象の組合せに応じたメッセージを原因候補として原因候補提示領域３３に表示する。また故障診断プログラム１３は、原因候補提示領域３３に表示した原因候補ごとに、それぞれ不具合情報テーブル１４に登録されている機器・部品及び不具合事象の組合せが同じ不具合情報の件数（過去に発生した同じ内容の不具合の回数に相当）を、その組合せに対応させて原因候補提示領域３３にそれぞれ表示する。

上述の例では、機器・部品及び不具合事象の組合せとして、少なくとも「ピストン」及び「汚れ」の組合せに対応する「ピストンの汚れを確認して下さい」というメッセージ（原因候補）及び過去に発生した同じ内容の不具合の回数と、「スパークプラグ」及び「汚れ」の組合せに対応する「スパークプラグの汚れを確認して下さい」というメッセージ及び過去に発生した同じ内容の不具合の回数とが原因候補提示領域３３に表示される。

（４）本実施の形態の効果
以上のように本実施の形態の故障診断装置１では、事故報告書データベース１０に蓄積された各事故報告書１６からそれぞれ不具合情報を取得し、取得した不具合情報のうちの故障機器・部品の親部品の情報が不足している不具合情報に対しては、当該親部品を推定してその親部品の名称をその不具合情報に追加する。従って、本故障診断装置１によれば、不具合情報に不足した情報を補完することができ、かくして事故報告書データベース１０に蓄積された各事故報告書１６から必要十分な不具合情報をそれぞれ抽出することができる。

また本実施の形態の故障診断装置１は、このような故障機器・部品の親部品を推定してその名称を追加する処理を実行するか否かを、不具合情報ごとに、その故障機器・部品の曖昧性に基づいて判断するため、冗長な情報（親部品の名称）が不具合情報に追加されるのを未然に防止することができる。

さらに本実施の形態の故障診断装置１は、同一の不具合事象が発生した同じ親子関係の系列に属する複数の故障機器・部品の不具合情報を、同一の表現からなる故障機器・部品の不具合事象にそれぞれ修正するため、故障診断時における不具合情報の集約を精度良く行うことができる。

従って、本実施の形態の故障診断装置１によれば、各事故報告書１６からそれぞれ抽出される不具合情報のうち、同一の故障機器・部品の同一の不具合事象の表記・表現を集約することができ、故障診断時における集約処理において同一の不具合事象の不具合情報が異なる不具合事象の不具合情報として取り扱われることを未然に防止することができる。また本故障診断装置１によれば、かかる故障診断結果として提示される原因候補の内容に情報（故障機器・部品の親部品の情報）の過不足が発生することを防止することができる。よって、本実施の形態によれば、故障診断性能の低下を抑制しながら、適切な診断結果を提示し得る使い勝手の良い高性能の故障診断装置を実現することができる。

（５）他の実施の形態
なお上述の実施の形態においては、不具合情報抽出プログラム１２及び故障診断プログラム１３を同じ１つのコンピュータ装置に実装するようにした場合について述べたが、本発明はこれに限らず、不具合情報抽出プログラム１２と、故障診断プログラム１３とをそれぞれ別個のコンピュータ装置に実装して本実施の形態の故障診断装置１を２つのコンピュータ装置から構築されるシステムとして構成するようにしてもよい。

また上述の実施の形態においては、過去の不具合の事例が記載されたテキストから不具合事象を抽出する不具合事象抽出部と、当該不具合事象が発生した故障機器・部品をテキストから抽出する故障機器・部品抽出部と、故障機器・部品抽出部により抽出された故障機器・部品、及び、不具合事象抽出部により抽出された不具合事象を対応付ける機器・事象対応付け部と、故障機器・部品抽出部により抽出された故障機器・部品について、テキスト内で記載が省略されている当該故障機器・部品の親部品を推定し、推定した当該親部品の情報を不具合情報に追加するようにして不具合情報を補完する故障機器・部品変更部とをすべてソフトウェア構成とするようにした場合について述べたが、本発明はこれに限らず、これら不具合事象抽出部、故障機器・部品抽出部、機器・事象対応付け部及び故障機器・部品変更部の一部又は全部をハードウェア構成とするようにしてもよい。

本発明は、例えば、故障診断装置に適用することができる。

１……故障診断装置、２……ＣＰＵ、３……主記憶装置、４……入出力装置、５……補助記憶装置、１０……事故報告書データベース、１２……不具合情報抽出プログラム、１３……故障診断プログラム、１４……不具合情報テーブル、１５……機器・部品階層関係辞書、１６……事故報告書、２０……故障機器・部品抽出サブプログラム、２１……不具合事象抽出サブプログラム、２２……機器・事象対応付けサブプログラム、２３……故障機器・部品変更サブプログラム、２４……正規化処理テーブル、３０……検索画面。

Claims (13)

1. 過去の不具合の事例が記載されたテキストから不具合情報を抽出する不具合情報抽出装置であって、
   前記テキストから不具合事象を抽出する不具合事象抽出部と、
   当該不具合事象が発生した故障機器・部品を前記テキストから抽出する故障機器・部品抽出部と、
   前記故障機器・部品抽出部により抽出された前記故障機器・部品、及び、前記不具合事象抽出部により抽出された前記不具合事象を対応付けることにより前記不具合情報を生成する機器・事象対応付け部と、
   前記故障機器・部品抽出部により抽出された前記故障機器・部品について、前記テキスト内で記載が省略されている当該故障機器・部品の親部品を推定し、推定した当該親部品の情報を前記不具合情報に追加するようにして前記不具合情報を補完する故障機器・部品変更部と
   を備えることを特徴とする不具合情報抽出装置。
2. 前記故障機器・部品変更部は、
   前記不具合情報を補完する必要があるか否かを、前記故障機器・部品の曖昧性に基づいて判断し、
   必要があると判断したときに、当該不具合情報を補完する
   ことを特徴とする請求項１に記載の不具合情報抽出装置。
3. 前記故障機器・部品変更部は、
   前記故障機器・部品に前記親部品が複数存在する場合に、当該故障機器・部品に前記曖昧性があると判定して、前記不具合情報を補完する必要があると判断する
   ことを特徴とする請求項２に記載の不具合情報抽出装置。
4. 前記故障機器・部品変更部は、
   各前記機器・部品の前記親部品が登録された辞書を参照して、前記故障機器・部品抽出部により抽出された前記故障機器・部品の前記親部品が複数存在するか否かを確認する
   ことを特徴とする請求項３に記載の不具合情報抽出装置。
5. 前記故障機器・部品変更部は、
   同一の前記不具合が発生した同じ親子関係の系列に属する複数の前記故障機器・部品の前記不具合情報を、当該系列に属する１つの前記故障機器・部品の前記不具合事象に集約する
   ことを特徴とする請求項１に記載の不具合情報抽出装置。
6. 前記故障機器・部品変更部は、
   同一の前記不具合が発生した同じ親子関係の系列に属する複数の前記故障機器・部品の前記不具合情報を、当該系列の最も上位階層の前記故障機器・部品の前記不具合事象に集約する
   ことを特徴とする請求項５に記載の不具合情報抽出装置。
7. 過去の不具合の事例が記載されたテキストから不具合情報を抽出する不具合情報抽出装置により実行される不具合情報抽出方法であって、
   前記テキストから不具合事象、及び、当該不具合事象が発生した故障機器・部品をそれぞれ抽出する第１のステップと、
   抽出した前記不具合事象及び前記故障機器・部品を対応付けることにより前記不具合情報を生成する第２のステップと、
   抽出した前記故障機器・部品について、前記テキスト内で記載が省略されている当該故障機器・部品の親部品を推定し、推定した当該親部品の情報を前記不具合情報に追加するようにして前記不具合情報を補完する第３のステップと
   を備えることを特徴とする不具合情報抽出方法。
8. 前記第３のステップでは、
   前記不具合情報を補完する必要があるか否かを、前記故障機器・部品の曖昧性に基づいて判断し、
   必要があると判断したときに、当該不具合情報を補完する
   ことを特徴とする請求項７に記載の不具合情報抽出方法。
9. 前記第３のステップでは、
   前記故障機器・部品に前記親部品が複数存在する場合に、当該故障機器・部品に前記曖昧性があると判定し、前記不具合情報を補完する必要があると判断する
   ことを特徴とする請求項８に記載の不具合情報抽出方法。
10. 前記第３のステップでは、
    各前記故障機器・部品の前記親部品が登録された辞書を参照して、前記故障機器・部品抽出部により抽出された前記故障機器・部品の前記親部品が複数存在するか否かを確認する
    ことを特徴とする請求項９に記載の不具合情報抽出方法。
11. 前記第３のステップでは、
    同一の前記不具合が発生した同じ親子関係の系列に属する複数の前記故障機器・部品の前記不具合情報を、当該系列に属する１つの前記故障機器・部品の前記不具合事象に集約する
    ことを特徴とする請求項７に記載の不具合情報抽出方法。
12. 前記第３のステップでは、
    同一の前記不具合が発生した同じ親子関係の系列に属する複数の前記故障機器・部品の前記不具合情報を、当該系列の最も上位階層の前記故障機器・部品の前記不具合事象に集約する
    ことを特徴とする請求項１１に記載の不具合情報抽出方法。
13. 過去の不具合の事例が記載されたテキストから不具合事象、及び、当該不具合事象が発生した故障機器・部品をそれぞれ抽出する第１のステップと、
    抽出した前記不具合事象及び前記故障機器・部品を対応付けることにより不具合情報を生成する第２のステップと、
    抽出した前記故障機器・部品について、前記テキスト内で記載が省略されている当該故障機器・部品の親部品を推定し、推定した当該親部品の情報を前記不具合情報に追加するようにして前記不具合情報を補完する第３のステップと
    を備える処理をコンピュータに実行させることを特徴とするプログラム。

Images