JP7118037B2 - テキストデータ解析システム、テキストデータ解析方法、および故障対応リコメンドシステム - Google Patents

Description

本発明は、テキストデータを解析する技術に関する。

社会活動においては、文章によって報告や説明がされた書類が作成されている。現代において、多くの書類はテキストデータとして記憶装置に蓄積されている。蓄積されたテキストデータを分析すれば、多くの知見を得ることが期待される。

テキストの文字列を対象としたデータマイニングは、テキストマイニングとも呼ばれる。テキストマイニングは、通常の文章からなるデータを単語や文節で区切り、それらの出現の頻度や共出現の相関、出現傾向、時系列などを解析することで有用な情報を取り出す、テキストデータの分析方法である。近年は人工知能を用いて分析することも行われている。

例えば、特許文献１には、パターンを定義することなくテキスト情報を分析するシステムについて開示されている。

特開2018－18254号公報

テキストデータ化されている文書の中で代表的なものは報告書である。報告書は、業務の経緯や結果について述べた文書であり、多くの企業や官公庁において日常的に使用されている。

報告書には様々な種類があるが、例えば「保守報告書」や「故障報告書」等と呼ばれるものでは、これらのテキストデータを解析することにより、効率的な問題解決に寄与する情報を、保守や故障を行う作業員に与えることで、作業員の経験の度合いによらず、故障等の問題が生じた場合の作業員の作業の効率性や精度を向上させることが期待されている。

しかしながら、報告書のテキストデータは、あくまで「報告」という目的のために作成されているため、他の目的に転用し難いという課題があった。

例えば、「保守報告書」や「故障報告書」は、作業員の故障現場で臨場の様子を正確に報告する必要があるため、作業内容が時系列に記載されている場合が多い。そのため、この作業が時系列に記載されているテキストデータ上から、「効率的な問題解決に寄与する情報」を判別、抽出することは困難、ひいては、故障等の問題が生じた場合の作業員の作業の効率性や精度を向上させることが困難であるという課題があった。

本発明の好ましい一側面は、複数の文書のテキストデータを処理する、テキストデータ解析システムである。このシステムでは、複数の文書のテキストデータから、文書中の特定の意味を持つテキストデータとして予め定義された「通知」と「確認」の項目を抽出する項目抽出部と、同一の項目として抽出された複数のテキストデータを、複数のカテゴリに分類する項目分類部と、抽出されたテキストデータが分類されたカテゴリを、当該テキストデータが抽出された文書に対応付ける報告書分析情報作成部と、を備える。

本発明の好ましい他の一側面は、複数の文書のテキストデータを処理する、テキストデータ解析方法である。この方法では、複数の文書のテキストデータから、文書中の特定の意味を持つテキストデータとして予め定義された項目を抽出し、同一の項目として抽出された複数のテキストデータを、複数のカテゴリに分類し、抽出されたテキストデータが分類されたカテゴリを、当該テキストデータが抽出された文書に対応付ける。

本発明の好ましい他の一側面は、故障に関する内容を含む複数の文書のテキストデータを処理し、故障への対応を提案する故障対応リコメンドシステムであって、複数の文書のテキストデータから、文書中の特定の意味を持つテキストデータとして予め定義された「受動情報」と「能動情報」の項目を抽出する項目抽出部と、同一の項目として抽出された複数のテキストデータを、複数のカテゴリに分類する項目分類部と、抽出されたテキストデータが分類されたカテゴリを、当該テキストデータが抽出された文書に対応付ける報告書分析情報作成部と、を備え、報告書分析情報作成部の分析結果に基づいた故障対応リコメンドを出力する、故障対応リコメンドシステムである。

効率的な問題解決に寄与する情報をユーザに与え、経験の有無にかかわらず、問題解決の効率を向上させることができる。

実施例のテキストデータ解析システムの構成ブロック図。 実施例のシステムの全体フロー図。 原因の抽出と分類の処理Ｓ２の詳細なフロー図。 原因カテゴリ付報告書ＤＢ１１２のデータ構造例を示す表図。 他の項目の抽出の処理Ｓ３の詳細なフロー図。 項目タグ付報告書ＤＢ１１３のデータ構造例を示す表図。 他の各項目のグルーピング処理Ｓ４の詳細なフロー図。 項目タグ分類付報告書ＤＢ１１５のデータ構造例を示す表図。 原因推定モデル作成処理Ｓ５の詳細なフロー図。 報告書分析情報ＤＢ１１６のデータ構造例を示す表図。 原因推定モデルの運用処理Ｓ６の詳細なフロー図。 決定木で構成された原因推定モデル１３４の例を示す概念図。 図１のシステムを用いた他の全体フローの例を示すフロー図。 報告書分析情報ＤＢ１１６のデータを一覧形式にした例を示す表図。 図１のシステムを用いた他の全体フローの例を示すフロー図。

実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。

同一あるいは同様な機能を有する要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、複数の要素を区別する必要がない場合には、添字を省略して説明する場合がある。

本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数、順序、もしくはその内容を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。

図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。

本明細書で引用した刊行物、特許および特許出願は、そのまま本明細書の説明の一部を構成する。

本明細書において単数形で表される構成要素は、特段文脈で明らかに示されない限り、複数形を含むものとする。

＜１．システム構成＞
図１に、実施例のテキストデータ解析システムの構成ブロックを示す。本実施例のシステムは、基本的に入力部、出力部、制御部、記憶部からなる情報処理装置で構成される。情報処理装置の例はタブレット等の端末やサーバである。

本実施例のテキストデータ解析システム１００は、それぞれが、情報処理装置で構成されるデータ蓄積サーバ１１０、分析サーバ１２０、分析モデル格納サーバ１３０、ユーザ端末１４０からなる。これらは、互いに有線あるいは無線のネットワークで接続されており、互いに情報処理のためのソフトウエア資源を利用することができる。

データ蓄積サーバ１１０は、主にデータを管理するサーバである。この例では、報告書データベース（ＤＢ）１１１、原因カテゴリ付報告書ＤＢ１１２、項目タグ付き報告書ＤＢ１１３、項目分類リストＤＢ１１４、項目タグ分類付報告書ＤＢ１１５、報告書分析情報ＤＢ１１６が格納される。報告書データベース（ＤＢ）１１１には、前述した報告書のテキストデータが格納される。

分析サーバ１２０は、主にデータを解析するサーバであり、また、分析モデルの学習を管理する。この例では、モデル生成部１２１、原因カテゴリ抽出部１２２、項目抽出部１２３、項目テキスト分類部１２４、報告書分析情報作成部１２５、解析部１２６が機能ブロックとして存在する。

本実施例では、計算や制御等の機能は、各情報処理装置の記憶装置に格納されたプログラムが処理装置によって実行されることで、定められた処理を他のハードウエアと協働して実現される。計算機などが実行するプログラム、その機能、あるいはその機能を実現する手段を、「機能」、「手段」、「部」、「ユニット」、「モジュール」等と呼ぶ場合がある。図１では、サーバなどの情報処理装置の機能を機能ブロックとして示しており、周知構成である入力部、出力部、制御部、記憶部は省略している。

分析モデル格納サーバ１３０は、分析サーバ１２０が利用する各種分析モデルを格納する。この例では、原因抽出モデル１３１、項目抽出モデル１３２、項目グループ化部１３３、原因推定モデル１３４である。

ユーザ端末１４０は、ユーザが直接操作するパーソナルコンピュータや携帯端末である。ユーザ端末の機能である制御部１４１は、ネットワークを介して、データ蓄積サーバ１１０、分析サーバ１２０、分析モデル格納サーバ１３０に指示を送り、これらのハードウエア、ソフトウエア、およびデータを利用可能である。
以上で列挙された構成要素の詳細は、この後の実施例で詳細に説明される。

本実施例で処理されるテキストデータは、ユーザがキーボードから入力したものでもよいし、音声認識によりテキスト化されたものでもよいし、チャットボットなどが自動的に収集したものでもよい。すなわち収集方法を問わない
本実施例で説明される各種のＤＢのデータは、基本的に文書番号によりクロスリファレンスが可能である。よって、複数のＤＢであってもこれらを合成することが可能であり、逆に単一のＤＢを複数に分割することも可能である。

以上の構成は、図１で示した構成に限らず、単体のコンピュータで構成してもよいし、あるいは、入力装置、出力装置、処理装置、記憶装置の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。これらのサーバは物理サーバのみならず、クラウドコンピューティングの形態でもよい。

本実施例中、ソフトウエアで構成した機能と同等の機能は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）などのハードウエアでも実現できる。そのような態様も本願発明の範囲に含まれる。

＜２．全体フロー＞
図２は本システムの全体フローを示している。ここでは概略だけを述べ、詳細は後の項目で説明する。

処理Ｓ１では、ユーザはユーザ端末１４０により、報告書データベース（ＤＢ）１１１をアクセスし、対象とする報告書データ（の集合）を選定する（報告書のテキストデータのことを、以下単に「報告書」ということがある）。また、報告書から抽出する抽出項目を定義する。制御部１４１は例えばブラウザ機能を有しており、ユーザはデータ蓄積サーバ１１０のデータを閲覧しデータのダウンロードも可能である。

対象とする報告書は例えば、「設備Ａの保守報告書」のように特定の目的や用途に対応する報告書を選定することが望ましい。抽出項目は、例えば「設備Ａの保守報告書」の中に現れる項目を、ユーザが自由に定義することができる。

本実施例では、故障等が起こった際に作業員に対して通知された情報、言い換えれば、作業員が受領した故障等に関する情報を「通知」、通知された事象の原因や対策を検討するために必要な情報を収集する確認を行い、確認の結果得られた事象の内容に関する情報を「確認（内容）」、当該確認の結果に基づいて作業員により導き出された原因に関する情報を「原因」、当該原因に基づいて立案・実行された対策に関する情報を「対策」と定義する。

保守報告書や故障報告書においては、上述のように作業内容が時系列やフリーテキストの形式で記載されているものがあるため、上記「通知」、「確認」、「対策」、「原因」それぞれの項目は散発的に記載されていたり、同じ項目複数回登場したり、複数の項目にまたがる内容がテキストになっていたりする場合があり、抽出が困難である。

しかしながら、上記４つの項目は、上記保守報告書等においては概ね全てに記載されている内容であり、且つ、これらを解析することにより、作業員の作業の効率性を飛躍的に高めることができることを初めて見出し、本実施例はこれを実現するものである。

なお、「通知」と「確認」はともに事象に関して得られた情報であるが、「通知」は報告書を作成した主体からみて受動的に得られた情報、「確認」は能動的に得られた情報である。例えば、「通知」はお客様からの故障連絡すなわち課題の内容であり、時系列的には最初の事象であることが多い。また、「確認」は課題を解決するために認識した事象の内容であり、受動的な情報である。認識のために現場の作業員などが行う行動を「指示（内容）」ということがあるが、これは能動的な情報である。また、「対策」は通知された課題を解決するために現場の作業員などが行う行動であり、これは能動的な情報である。「原因」は、それがなければ課題が生じなかった事象であり、これは受動的な情報である。

このように、各情報は受動的な情報（受動情報）または能動的な情報（能動情報）の２つに大別することができ、この受動情報と能動情報の２つを含んでいることが、「故障という事象（受動的事象）が起きた場合の、対策（能動的事象）をリコメンドする」という故障対応リコメンデーションの概念と整合する。このため、報告書に含まれる受動情報と能動情報の関係を分類整理することで、故障等が起こった際の的確なリコメンデーションが可能となる。

本実施例では、上記で説明した「通知」、「確認」、「対策」、「原因」を項目とした例で説明するが、これに限る必要はないし、さらに項目を増やしてもよい。たとえば、「報告」「作業内容」「指示」「その他」など、項目は対象とする報告書の用途や性格にあわせて定義してよい。

処理Ｓ２では、対象とする報告書から「原因」の項目を抽出して「原因」を分類する。分類はユーザが定義する。「原因」の項目は報告書の結論として記載されることも多く、また、ユーザが最も知りたい項目でもある。「原因」の項目の抽出と分類は、例えばＤＮＮ（Deep Neural Network）を用いて行うことができる。分類した「原因」のカテゴリは報告書のテキストデータにタグ（原因ラベル）として付加する。

処理Ｓ３では、対象とする報告書から「原因」以外の他の項目を抽出する。本実施例では、「通知」、「確認」、「対策」の項目が該当する。項目の抽出は、例えばＤＮＮを用いて行うことができる。処理Ｓ３の結果、項目毎に、報告書から抽出したテキストデータの集合が形成される。

処理Ｓ４では、処理Ｓ３で抽出した各項目のテキストデータを、類似したもの同士でグルーピングする。そして、各報告書にそれに含まれる項目のグループを特定するＩＤ（グループ名）をタグとして付加する。

処理Ｓ５では、グループ名を説明変数、原因ラベルを目的変数として、原因推定モデルを作成する。

処理Ｓ６では、原因推定モデルを運用する。

なお、上記の処理Ｓ１～Ｓ６は一連の処理であるが、独立の処理として実行することもできる。その場合、処理Ｓ１～Ｓ６は、それぞれ別のシステムで実行することもできる。

＜３．原因の抽出と分類（処理Ｓ２）＞
処理Ｓ１に続く処理を以下説明する。なお、以降の説明では、処理Ｓ１で選定した対象とする報告書データにのみについて説明する。報告書ＤＢ１１１には、選定していないデータも格納される場合もあるが、説明上それらについては言及しない。

図３は、原因の抽出と分類の処理Ｓ２の詳細なフロー図である。説明上、ユーザがユーザ端末１４０と分析サーバ１２０を操作して行う処理、分析モデル格納サーバ１３０の分析モデルが行う処理、およびデータ蓄積サーバ１１０が格納するテキストデータを区分して説明している（以下同様）。

処理Ｓ２０１では、ユーザは処理Ｓ１で選定した対象とする報告書を検討し、推定される原因のカテゴリを決定する。このため、例えば制御部１４１により、該当する報告書を報告書ＤＢ１１１から呼び出して、ユーザ端末１４０に表示して内容を検討する。原因のカテゴリの定義、内容や種類は任意であり、対象とする報告書に応じてユーザが任意に定めることができる。

原因カテゴリの定義は経験のあるユーザが決定することが望ましい。例えば「電気系統の故障」「機械系統の故障」「人為的ミス」等である。もちろんさらに原因を細分化してもよい。決定した原因カテゴリは、分析サーバ１２０の原因カテゴリ抽出部１２２に格納される。

処理Ｓ２０２では、ユーザは教師データとする報告書を抜粋する。これはＳ１で選定した対象とする報告書の集合から、その一部を任意に選定してよい。ランダムに選定してもよい。

処理Ｓ２０３では、ユーザはユーザ端末１４０で、教師データとする報告書を閲覧し、それぞれの報告書に処理Ｓ２０１で定めた定義に従い原因カテゴリを付与する。原因カテゴリが付された報告書は、データ蓄積サーバ１１０の原因カテゴリ付報告書ＤＢ１１２に格納される。

図４は、原因カテゴリ付報告書ＤＢ１１２のデータ構造例である。報告書の文書番号４０１にテキストデータ４０２と原因カテゴリ４０３が対応している。なお、報告書ＤＢ１１１のデータ構造は、図４の構成から原因カテゴリ４０３を除いたものである。

図３に戻り、処理Ｓ２０４では、モデル生成部１２１は、テキストデータ４０２と原因カテゴリ４０３のペアを教師データ４０４として、原因抽出モデル１３１に入力する。

処理Ｓ２０５では、モデル生成部１２１の制御により、分析モデル格納サーバ１３０の学習前の原因抽出モデル１３１が教師データを取り込む。原因推定モデルは、特に限定しないが、例えばベイジアンＤＮＮである。

処理Ｓ２０６では、モデル生成部１２１の制御により、原因抽出モデル１３１が教師有り学習を行う。学習方法は公知の手法を用いてよい。

処理Ｓ２０７では、原因カテゴリ抽出部１２２の制御により、学習済みの原因抽出モデル１３１に対して、教師データ以外の報告書のテキストデータを入力する。教師データ以外の報告書には原因カテゴリ４０３が付されていないが、処理Ｓ２０６で適切に学習された原因抽出モデル１３１は、報告書のテキストデータ４０２の入力に対して、原因カテゴリ４０３を出力する。

処理Ｓ２０８では、原因カテゴリ抽出部１２２は、分類結果の出力をユーザ端末１４０に送信する。処理Ｓ２０９では、ユーザは必要により内容をチェックして、教師データ以外の報告書の原因カテゴリを決定する。

以上の処理により、ユーザが処理Ｓ１で選定した対象データの報告書には、ユーザあるいは原因カテゴリ抽出部１２２によって、全て原因カテゴリが付与されたことになる。このデータ形式は図４に示したものと同様である。ユーザは制御部１４１の制御により、原因カテゴリが付与された報告書を、データ蓄積サーバの原因カテゴリ付報告書ＤＢ１１２に格納する。

＜３．他の項目の抽出（処理Ｓ３）＞
図５は、他の項目の抽出の処理Ｓ３の詳細なフロー図である。

処理Ｓ３０１では、ユーザは報告書データベース１１１から、教師データとする報告書を抜粋する。これはＳ１で選定した対象とするデータの集合から、任意に選定してよい。処理Ｓ２０２で選定した報告書とは異なっていてもよい。

データ蓄積サーバ１１０に格納されている、教師とする報告書３０１０のテキストデータから、時系列的に記載された作業内容３０１１がユーザ端末に送られる。

処理Ｓ３０２では、ユーザはユーザ端末１４０を操作して、時系列的に記載された作業内容３０１１の一行ごとに項目をタグ付けする。タグ付けする項目は、処理Ｓ１で行った定義に従う。この例では、「通知」、「確認」、「対策」である。なお、タグ付けする単位は、所定のルールに従って報告書のテキストを区切るものであれば、一行ごとでなくてもよい。タイムスタンプ毎でもよいし、一段落毎でもよいし、枠で区切られた文章毎でもよい。句読点から句読点まででもよい。タグ付けをした報告書は項目タグ付き報告書ＤＢ１１３として、データ蓄積サーバ１１０に格納してもよい。

処理Ｓ３０３では、モデル生成部１２１の制御により、項目がタグ付けされた報告書を、教師データとして分析モデル格納サーバ１３０の項目抽出モデル１３２に入力する。

図６は、処理Ｓ３０２でタグ付けされた報告書の例であり、項目タグ付報告書ＤＢ１１３のデータ構造例である。この例では行番号６０１の一行ごとに、「通知」「確認」「対策」がタグ付けされている。一行ごとのテキストデータ６０２と項目タグ６０３のペアが教師データ６０４として項目抽出モデル１３２に入力される。

処理Ｓ３０４では、モデル生成部１２１の制御により、項目抽出モデル１３２が教師データを取り込む。このとき、蓄積済みの分類データ３０１２があれば、教師データとして同様に取り込むことができる。

処理Ｓ３０５では、モデル生成部１２１の制御により、項目抽出モデルが教師有り学習あるいは再学習される。項目抽出モデル１３２は、必要に応じて学習を繰り返すことにより性能向上を図ることができる。分析モデルの学習については、処理Ｓ２０６と同様である。

処理Ｓ３０６では、項目抽出部１２３が、学習済みの項目抽出モデル１３２に対して、教師データ以外の報告書のテキストデータ６０２を例えば、１行ずつ入力する。処理Ｓ３０５で適切に学習された項目抽出モデル１３２は、報告書の各行に対して、項目タグ６０３を出力する。

処理Ｓ３０７では、出力された項目タグが付された報告書の各行を、ユーザ端末１４０に送付する。

処理Ｓ３０８では、ユーザ端末１４０の制御部１４１は、項目タグが付された報告書の各行を、項目別にリスト化する。この例では、報告書の各行のテキストが、「通知」「確認」「対策」の３つに分類されてリストアップされる。

以上の処理で、過去の報告書データのテキストデータの各行が、所定の項目と紐づけられた項目分類リスト３０１３が作成された。項目分類リストは、項目分類リストＤＢ１１４としてデータ蓄積サーバ１１０に格納しておいてもよい。

＜４．他の各項目のグルーピング（処理Ｓ４）＞
図７は、他の各項目のグルーピング処理Ｓ４の詳細なフロー図である。処理Ｓ４０１では、分析モデル格納サーバ１３０の項目グループ化部１３３は、処理Ｓ３により作成された項目分類リストＤＢ１１４の同一項目に紐づけられたテキストを分類し、類似する文章同士でグルーピングする。

テキスト分類の手法は公知の技術を適用可能である。例えば、テキストをベクトルに変換し、クラスター分析の手法によりデータを外的基準なし（教師なし）で自動的にグルーピングする。

処理Ｓ４０２では、項目グループ化部１３３は、グルーピングされたデータにグループ名（ＩＤ）を付与する。グループ名は自動的に付与してもよいし、ユーザが、制御部１４１を操作し、ユーザ端末１４０でテキストの内容を見て適切な名前を付与してもよい。そして処理Ｓ４０３では、報告書に各項目のグループ名をタグ付けして、項目紐付済の報告書を項目タグ分類付報告書ＤＢ１１５としてデータ蓄積サーバ１１０に格納する。

以上の処理により、各報告書で自由な表現で記入されていた各項目の内容が、類似なもの同士でカテゴライズされ、記述の揺らぎが吸収される。

例えば、ドアの故障を表現する「通知」の記述が「ドアが開かない」「扉が故障している」「開閉異常」など異なる表記で行われていた場合でも、これらを同じカテゴリの通知であるとして扱うことができる。

図８は、項目タグ分類付報告書ＤＢ１１５のデータ構造の一例を示す表図である。報告書の文書番号４０１に対して、行番号６０１、当該行のテキストデータ６０２、当該行の項目タグ６０３、および項目の項目分類８０１が対応付けられる。

＜５.原因推定モデル作成（処理Ｓ５）＞
図９は、原因推定モデル作成処理Ｓ５の詳細なフロー図である。

処理Ｓ５０１では、報告書分析情報作成部１２５は、項目タグ分類付報告書ＤＢ１１５のデータと原因カテゴリ付き報告書ＤＢ１１２のデータを合体して、報告書分析情報データを生成する。すなわち図８の項目タグ分類付報告書ＤＢ１１５のデータの文書番号毎に、図４の原因カテゴリ付き報告書ＤＢ１１２の原因カテゴリ４０３を付加し、これをデータ蓄積サーバ１１０に格納して、報告書分析情報ＤＢ１１６とする。報告書分析情報ＤＢのデータは、原因推定モデル教師データとして利用できるが、後述のように他にも利用価値がある。

図１０は、処理Ｓ５０１の結果生成されたデータ構造（報告書分析情報ＤＢ１１６のデータ構造）を示す図である。先に述べたように、項目タグ分類付報告書ＤＢ１１５のデータに原因カテゴリ４０３が追加されている。ここで、項目分類８０１と原因カテゴリ４０３のペアを原因推定モデル教師データ１００１として利用することができる。

処理Ｓ５０２では、ユーザ端末の制御部１４１は、モデル生成部１２１に対して、原因推定モデル教師データ１００１を原因推定モデル１３４に入力するように指示を出す。

処理Ｓ５０３では、原因推定モデル１３４は、原因推定モデル教師データ１００１の項目分類８０１を説明変数、原因カテゴリ４０３を目的変数として取り込む。

処理Ｓ５０４では、原因推定モデル１３４は、モデル生成部１２１の制御で学習を行う。

処理Ｓ５０５では、教師データで一応学習が済んだ原因推定モデル１３４に対して、項目タグ分類付報告書ＤＢ１１５の原因カテゴリ４０３が付されていない報告書を学習データ（トレーニングデータ）として用い、原因の推定を行う。すなわち、項目分類８０１を入力として、原因推定モデル１３４が正しい原因カテゴリ４０３を出力するように学習させる。

処理Ｓ５０６では、出力された原因カテゴリ４０３を確認して推定結果を評価し、原因推定モデル１３４の精度を確認する。精度が不十分であれば、原因推定モデル１３４を再学習する。精度が十分であれば、原因推定モデル１３４は完成し、実運用となる。

用いる原因推定モデル１３４は、決定木、ランダムフォレスト、サポートベクトルマシン（ＳＶＭ）など、公知の教師有り学習モデルから選択してよい。学習方法も公知手法を用いてよい。

＜６.原因推定モデルの運用（処理Ｓ６）＞
図１１は、原因推定モデルの運用処理Ｓ６の詳細なフロー図である。

処理Ｓ６０１で何らかの障害が発生したとする。障害の内容は、「通知」内容として処理Ｓ６０２でトリガとして入力される。通知は、原因推定モデル１３４に入力される。

処理Ｓ６０３で、原因推定モデル１３４が決定木で構成されている場合、「通知」を入力された原因推定モデル１３４は、分岐となる「確認」項目に対応する指示を出力する。

出力された確認項目の指示に対して、処理Ｓ６０４で現場の作業員などは、状況を確認し回答を行う。処理Ｓ６０５で、回答は「確認」内容として原因推定モデル１３４に入力される。
処理Ｓ６０６で、原因推定モデル１３４は推定される原因を出力する。

図１２は、決定木で構成された原因推定モデル１３４の例である。この決定木は、「通知」「確認」「原因」「対策」を入力としているが、「確認」を行うために必要な動作は「指示」として定義することができる。いま、「モータが動作しない」という通知カテゴリ１の事象が入力された場合、原因推定モデル１３４の警告灯の点灯有無という分岐に対応する指示「警告灯をチェック」が現場に対して行われる（処理Ｓ６０３）。図１２の例にも見られるように、「通知」と「確認」の項目は、決定木の（特に初期の）分岐に対応する事象であることが多いため、重要である。

指示に対応して「警告灯が点灯している（確認カテゴリ１）」あるいは「警告灯が点灯していない（確認カテゴリ２）」が原因推定モデル１３４に入力され（処理Ｓ６０４）、原因推定モデルの実行で推定が進められる（処理Ｓ６０５）。

最終的に原因が推定されたら、推定原因を出力し（処理Ｓ６０６～Ｓ６０７）、出力結果に基づく事実確認を現場に指示し（処理Ｓ６０８）、対策を行う（処理Ｓ６０９）。例えば、ヒューズ切れという原因が推定されたら（図１２、原因カテゴリ１）、ヒューズを交換という対策を行う（図１２、対策カテゴリ１）。

図１３は、実施例２の説明のため、図１のシステムを用いた他の全体フローの例を示している。

実施例１の図１では、処理Ｓ１～Ｓ４で得られたデータを用いて、システムは原因推定モデルの作成と運用（処理Ｓ５およびＳ６）を行っている。しかし、処理Ｓ１～Ｓ４で得られたデータを、報告書分析情報作成処理Ｓ１００で加工して、直接ユーザに示してもよい。

図１４は、報告書分析情報作成部１２５により報告書分析情報作成処理Ｓ１００を行い、図１０に示した報告書分析情報ＤＢ１１６のデータを一覧１４００の形に変形したものである。報告書に出現する各項目のカテゴリの組み合わせが示されており、ユーザは各通知のカテゴリに対して、どの確認や原因のカテゴリが関係するかを知ることができる。

ユーザは、制御部１４１により、報告書分析情報ＤＢ１１６のデータから作成した一覧１４００を、ユーザ端末１４０に表示することができる。

図１５は、実施例３の説明のため、図１のシステムを用いた他の全体フローの例を示している。

実施例１の図１では、原因項目のカテゴリの抽出のために、他の項目のカテゴリの抽出処理Ｓ３とは別個の処理Ｓ２を行っている。しかし、原因項目のカテゴリ抽出も、他の項目と同様に行ってもよい。

実施例３の項目の抽出処理Ｓ３－２では、「通知」「確認」「対策」と同様に「原因」の項目抽出およびカテゴリ分けを行う。実施例１よりも処理が簡略化されるメリットがあるが、「原因」特有の抽出方式を使用できないというデメリットがある。

以上説明したように、本実施例では、様式や表現の定まっていない報告書であっても、項目を抽出してカテゴライズすることにより、報告書の内容を定式化して整理し、ユーザが内容を理解しやすくすることができる。また、人工知能の機械学習のための教師データとして使いやすくすることができる。

テキストデータ解析システム１００、データ蓄積サーバ１１０、分析サーバ１２０、分析モデル格納サーバ１３０、ユーザ端末１４０、報告書データベースＤＢ１１１、原因カテゴリ付報告書ＤＢ１１２、項目タグ付き報告書ＤＢ１１３、項目分類リストＤＢ１１４、項目タグ分類付報告書ＤＢ１１５、報告書分析情報ＤＢ１１６、モデル生成部１２１、原因カテゴリ抽出部１２２、項目抽出部１２３、項目テキスト分類部１２４、報告書分析情報作成部１２５、解析部１２６

Claims (6)

1. 複数の文書のテキストデータを処理する、テキストデータ解析システムであって、
   前記複数の文書のテキストデータから、文書中の特定の意味を持つテキストデータとして予め定義された「通知」と「確認」の項目を抽出する項目抽出部と、
   同一の項目として抽出された複数のテキストデータを、複数のカテゴリに分類する項目分類部と、
   抽出されたテキストデータが分類されたカテゴリを、当該テキストデータが抽出された文書に対応付ける報告書分析情報作成部と、
   を備え、
   前記項目抽出部は、
   前記項目として、受動的に得られた情報を記述した「通知」と、能動的に得られた情報を記述した「確認」を抽出し、
   前記項目抽出部は、
   前記項目として、「通知」の内容となる事象の「原因」を抽出し、前記「通知」と「確認」を第１のアルゴリズムで抽出し、「原因」を第２のアルゴリズムで抽出し、
   前記報告書分析情報作成部は、
   「通知」、「確認」の項目として抽出されたテキストデータが分類されたカテゴリを説明変数、「原因」の項目として抽出されたテキストデータが分類されたカテゴリを目的変数とし、分析モデルを学習するための教師データを生成する、
   テキストデータ解析システム。
2. 前記項目分類部は、
   同一の項目として抽出された複数のテキストデータを、類似するものをグループ化することにより、複数のカテゴリに分類する、
   請求項１記載のテキストデータ解析システム。
3. 前記項目抽出部は、
   前記項目として、「通知」の内容となる事象を解消するための「対策」を抽出する、
   請求項１記載のテキストデータ解析システム。
4. 前記報告書分析情報作成部は、
   「通知」、「確認」をおよび「原因」の項目として抽出されたテキストデータが分類されたカテゴリが、当該テキストデータが抽出された文書に対応付けられていることを示す情報を生成する、
   請求項１記載のテキストデータ解析システム。
5. 複数の文書のテキストデータを処理する、テキストデータ解析方法であって、
   前記複数の文書のテキストデータから、文書中の特定の意味を持つテキストデータとして予め定義された項目を抽出し、
   同一の項目として抽出された複数のテキストデータを、複数のカテゴリに分類し、
   抽出されたテキストデータが分類されたカテゴリを、当該テキストデータが抽出された文書に対応付け、
   同一の項目として抽出された複数のテキストデータを、類似するものをグループ化することにより、複数のカテゴリに分類し、
   前記項目として、受動的に得られた情報を記述した「通知」と、能動的に得られた情報を記述した「確認」を抽出し、
   「通知」、「確認」の項目として抽出されたテキストデータが分類されたカテゴリを、当該テキストデータが抽出された文書に対応付け、
   前記複数の文書のテキストデータから、文書中の「通知」の内容となる事象の「原因」の意味を持つテキストデータを、予め定義された分類に従って抽出し、
   前記「原因」の項目として抽出されたテキストデータが分類されたカテゴリを、当該テキストデータが抽出された文書に対応付け、
   項目として抽出されたテキストデータが分類されたカテゴリを、当該テキストデータが抽出された文書に対応付けた情報を、教師データとして分析モデルを学習し、
   前記教師データでは、「通知」、「確認」の項目として抽出されたテキストデータが分類されたカテゴリを説明変数、「原因」の項目として抽出されたテキストデータが分類されたカテゴリを目的変数とする、
   学習した分析モデルにより新たなテキストデータの分析を行う、
   テキストデータ解析方法。
6. 項目として抽出されたテキストデータが分類されたカテゴリを、当該テキストデータが抽出された文書に対応付けたことを示す情報を、ユーザに表示する、
   請求項５記載のテキストデータ解析方法。

Images