ホーム > 特許ランキング > Ａｒｉｔｈｍｅｒ株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022178727
(43)【公開日】2022-12-02
(54)【発明の名称】分類システム、分類方法および分類プログラム
(51)【国際特許分類】
G06F 16/35 20190101AFI20221125BHJP
G06Q 10/04 20120101ALI20221125BHJP
【ＦＩ】
G06F16/35
G06Q10/04
【審査請求】未請求
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2021085727
(22)【出願日】2021-05-20
(71)【出願人】
【識別番号】517332845
【氏名又は名称】Ａｒｉｔｈｍｅｒ株式会社
(72)【発明者】
【氏名】鈴木 良尚
(72)【発明者】
【氏名】武内 数馬
(72)【発明者】
【氏名】藤間 光徳
(72)【発明者】
【氏名】有田 親史
【テーマコード（参考）】
5B175
5L049
【Ｆターム（参考）】
5B175DA01
5B175FA03
5L049DD01
(57)【要約】 （修正有）
【課題】分析者が、テキストデータの分類結果から業務に必要な情報のみを抽出する分類システム、分類方法及び分類プログラムを提供する。
【解決手段】利用者端末、分析者端末、管理サーバ及び分類サーバによって実現される分類システムにおいて、分類サーバ３００は、所定の単位で分割されたテキストデータを記憶する記憶部と、分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類部を有する処理部と、を備える。分類部は、テキストデータを単語毎に整数に変換して得られた整数列を入力して、複数のクラスへの分類確率を出力する学習モデル３２１を用いてテキストデータを分類する。
【選択図】図１５
【解決手段】利用者端末、分析者端末、管理サーバ及び分類サーバによって実現される分類システムにおいて、分類サーバ３００は、所定の単位で分割されたテキストデータを記憶する記憶部と、分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類部を有する処理部と、を備える。分類部は、テキストデータを単語毎に整数に変換して得られた整数列を入力して、複数のクラスへの分類確率を出力する学習モデル３２１を用いてテキストデータを分類する。
【選択図】図１５
【特許請求の範囲】
【請求項1】
所定の単位で分割されたテキストデータを記憶する記憶部と、
前記分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類部と、
を備える分類システム。
前記分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類部と、
を備える分類システム。
【請求項2】
前記分類部は、前記テキストデータを単語ごとに整数に変換して得られた整数列を入力して前記複数のクラスへの分類確率を出力する学習モデルを用いて前記テキストデータを分類する、
請求項１に記載の分類システム。
請求項１に記載の分類システム。
【請求項3】
前記学習モデルは、
前記整数列から数値行列を求める第１演算部と、
前記数値行列の入力に応じて前記複数のクラス分類確率を出力する第２演算部と、
を備える、請求項２に記載の分類システム。
前記整数列から数値行列を求める第１演算部と、
前記数値行列の入力に応じて前記複数のクラス分類確率を出力する第２演算部と、
を備える、請求項２に記載の分類システム。
【請求項4】
前記第１演算部は、前記整数列から分散表現を求め、
前記第２演算部は、前記分散表現の入力に応じて前記複数のクラス分類確率を出力する、
請求項３に記載の分類システム。
前記第２演算部は、前記分散表現の入力に応じて前記複数のクラス分類確率を出力する、
請求項３に記載の分類システム。
【請求項5】
前記分類部は、前記テキストデータを予め定められた単語数となるように固定長化処理を施して前記学習モデルへ入力する請求項２から４のいずれか１項に記載の分類システム。
【請求項6】
前記学習モデルは、畳み込み演算を実行する、
請求項２から５のいずれか１項に記載の分類システム。
請求項２から５のいずれか１項に記載の分類システム。
【請求項7】
前記テキストデータは、３００文字以内の文字数で構成されるものである、
請求項１から６のいずれか１項に記載の分類システム。
請求項１から６のいずれか１項に記載の分類システム。
【請求項8】
前記分類部は、同一単語を含む前記テキストデータを異なるクラスに分類可能な学習モデルを用いて前記テキストデータを分類する、
請求項１から７のいずれか１項に記載の分類システム。
請求項１から７のいずれか１項に記載の分類システム。
【請求項9】
前記記憶部に記憶されたテキストデータから、イベントに関する前記テキストデータを収集する収集部をさらに備える、請求項１から８のいずれか１項に記載の分類システム。
【請求項10】
前記テキストデータは、音声データを音声認識により変換した文字列である、請求項１から９のいずれか１項に記載の分類システム。
【請求項11】
所定の単位で分割されたテキストデータを記憶する記憶ステップと、
前記分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類ステップと、
をコンピュータが実行する分類方法。
前記分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類ステップと、
をコンピュータが実行する分類方法。
【請求項12】
所定の単位で分割されたテキストデータを記憶する記憶ステップと、
前記分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類ステップと、
をコンピュータに実行させる分類プログラム。
前記分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類ステップと、
をコンピュータに実行させる分類プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、分類システム、分類方法および分類プログラムに関する。
【背景技術】
【0002】
例えば事故の発生により鉄道が一定期間運休を余儀なくされるような場合に、運行の再開予測を一刻も早く知らなければならない利用者がいる。しかし、鉄道会社は正確を期するために不確かな情報を公表せず、往々にして運行を再開してからその旨を公表する。そこで、利用者は、ソーシャルメディアに対して発信された第三者のコメントを参照して、いち早く運行状況を予想し、行動する場合がある。しかし、ソーシャルメディアの個々のコメントは、即時性がある反面、正確性に劣る場合がある。このような背景のもと、ソーシャルメディアに発信されたコメントを、実際の状況を予測する材料とする技術が開発されるようになってきた（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１４－２０６８２９号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
例えば特許文献１では、ソーシャルメディア情報を用いて、駅の混雑を正確に予測することを意図した技術が開示されている。しかしながら、特許文献１に記載の技術は、ソーシャルメディアに発信された多数のコメントから、対象イベントの進行状態を大局的に予測するのには不向きな場合がある。
【課題を解決するための手段】
【0005】
本発明の第１の態様における分類システムは、所定の単位で分割されたテキストデータを記憶する記憶部と、前記分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類部とを備える。
【0006】
本発明の第２の態様における分類方法は、所定の単位で分割されたテキストデータを記憶する記憶ステップと、前記分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類ステップとを有する。
【0007】
本発明の第３の態様における分類プログラムは、所定の単位で分割されたテキストデータを記憶する記憶ステップと、前記分割された各テキストデータを予め定められた複数のクラスのいずれかに分類する分類ステップとをコンピュータに実行させる。
【0008】
このように、多数寄せ集められたコメントをその内容に応じて分類し、分類によって現れる大局的な傾向を利用して対象であるイベントの進行状態を判定する。このような手法によれば、個々のコメントの正確性の全体の予測に及ぼす影響を低減しつつ、いち早く判定結果を提示することができる。
【図面の簡単な説明】
【0009】
【図1】本実施形態に係る状態判定システムが利用される全体環境と、状態判定に関する情報の流れを説明する図である。
【図2】状態判定サーバのハードウェア構成を示す図である。
【図3】コメントのクラスへの分類を説明する図である。
【図4】コメントの整数列への変換を説明する図である。
【図5】ニューラルネットワークの処理を説明する図である。
【図6】クラス分類の検証結果を示す図である。
【図7A】クラス割合と状態判定結果の時間推移を示すグラフである。
【図7B】状態判定するための判定期間を説明するための図である。
【図8】現在における状態判定結果の表示例である。
【図9】クラスＡの割合の時間推移と再開判定時刻を示すグラフである。
【図10】再開判定時刻の表示例である。
【図11】状態判定プログラムの処理手順を示すフロー図である。
【図12】他の例における全体環境と、状態判定に関する情報の流れを説明する図である。
【図13】分類システムが利用される全体環境と、分類に関する情報の流れを説明する図である。
【図14】分類システムのニューラルネットワークの教師データの一例を示す図である。
【図15】分類サーバのハードウェア構成を示す図である。
【図16】分類プログラムの処理手順を示すフロー図である
【発明を実施するための形態】
【0010】
以下に発明の実施形態を通じて本発明を説明するが、特許請求の範囲に係る発明を以下の実施形態に限定するものではない。また、実施形態で説明する構成の全てが課題を解決するための手段として必須であるとは限らない。
【0011】
（１）全体構成
図１は、本実施形態に係る状態判定システムが利用される全体環境と、状態判定に関する情報の流れを説明する図である。本実施形態における状態判定システムは、状態判定サーバ１００によって実現される。状態判定サーバ１００は、インターネット９００に接続されており、インターネット９００を介して、直接的または間接的に利用者のスマートフォン２１０、コメント発信者のスマートフォン９１０、およびメディアサーバ９２０と情報の授受を行う。
図１は、本実施形態に係る状態判定システムが利用される全体環境と、状態判定に関する情報の流れを説明する図である。本実施形態における状態判定システムは、状態判定サーバ１００によって実現される。状態判定サーバ１００は、インターネット９００に接続されており、インターネット９００を介して、直接的または間接的に利用者のスマートフォン２１０、コメント発信者のスマートフォン９１０、およびメディアサーバ９２０と情報の授受を行う。
【0012】
より具体的には、コメント発信者が各自のスマートフォン９１０を操作して発信したツイート等のコメントは、インターネット９００を介してメディアサーバ９２０へ送られ、メディアサーバ９２０に接続されたコメント蓄積部９２１に蓄積される。コメント蓄積部９２１は、例えば大容量のＨＤＤによって構成されている。コメント発信者のスマートフォン９１０には、メディアサーバ９２０を運営する運営者によってリリースされたアプリケーションがインストールされており、コメント発信者は、当該アプリケーションを介してコメントをテキスト入力することができる。なお、コメントは、コメント発信者の発声を認識してテキスト変換したものであっても良い。
【0013】
コメント蓄積部９２１に蓄積されたコメント発信者のコメントは、アクセス権限に応じて閲覧することができる。このように特定のアプリケーションを介して利用者間でコメントを授受するサービスは、代表的にはソーシャルネットワークサービス（ＳＮＳ）が知られている。ただし、本実施形態におけるソーシャルメディアは、ＳＮＳに限らず、発信者が一方的に情報を発信するサービスも含み得る。
【0014】
本実施形態における状態判定システムは、このように任意に運営されている１つまたは複数のソーシャルメディアを利用する。具体的には、状態判定サーバ１００は、分析対象のイベントを定めると、当該イベントに関するコメントを特定コメントと定め、インターネット９００を介してメディアサーバ９２０へアクセスし、コメント蓄積部９２１から特定コメントを収集する。複数のソーシャルメディアを利用する場合には、それぞれのソーシャルメディアのメディアサーバ９２０へアクセスする。状態判定サーバ１００は、収集したコメントに基づいて当該イベントの現在または将来における進行状態を判定する演算処理を実行する。そして、利用者のスマートフォン２１０から状態判定のリクエストを受けると、スマートフォン２１０へ判定した判定結果を送信する。利用者は、気になるイベントの進行状態を、スマートフォン２１０に表示される判定結果により想像することができる。
【0015】
なお、ここでは、ツイート等のコメントとして、３００文字以内の文字数で構成されるものを分析対象とする。以下においては、公共交通機関の非常停止後の運行再開事象を分析対象のイベントとして説明する。具体的には、発生した車両事故により運休が余儀なくされているある鉄道路線（「東急電鉄」の「東横線」を具体例とする）において、列車の運行再開に関する進行状態を判定する例を説明する。東横線の利用者は、例えば自宅やオフィスに居ながら、「現時点で運行が再開しているのか」や、「いつ運行が再開しそうか」といった情報を知りたい場合がある。そのような場合において、利用者は、スマートフォン２１０の専用アプリケーションを利用して、状態判定サーバ１００へ状態判定をリクエストする。
【0016】
図２は、状態判定サーバ１００のハードウェア構成を示す図である。状態判定サーバ１００は、主に、処理部１１０、記憶部１２０、通信部１３０、および入力部１４０によって構成される。処理部１１０は、状態判定サーバ１００の制御とプログラムの実行処理を行うプロセッサ（ＣＰＵ及び／又はＧＰＵ等で構成される）である。処理部１１０は、記憶部１２０に記憶された状態判定プログラムを読み出して、状態判定に関する様々な処理を実行する。処理部１１０が収集部１１１としての処理を実行する場合には、コメント蓄積部９２１に蓄積されたコメントのうち、分析対象として指定されたイベントである「東横線の運行再開」に関する特定コメントを収集する。
【0017】
具体的には、収集部１１１は、通信部１３０を介してコメント蓄積部９２１へアクセスし、コメント蓄積部９２１で一定時間の間に蓄積されたコメントから、キーワード検索により特定コメントを抽出する。そして、キーワード検索により抽出されたコメントを特定コメントとして状態判定サーバ１００へ取り込む。キーワード検索は、例えば、路線名に関する複数のキーワード（「東横線」「東急東横線」等）が予め設定されており、設定されているキーワードを含むコメントを抽出する。特定のキーワードについては、他のキーワードと共に含まれている場合に抽出候補とする等の抽出条件を定めても良い。また、キーワード検索を実行する対象コメントを、例えばタグ情報として東横線沿線の位置情報を有するコメントに限っても良い。
【0018】
処理部１１０が分類部１１２としての処理を実行する場合には、記憶部１２０から読み出したニューラルネットワーク１２１（以下「ＮＮ１２１」とする）を用いて特定コメントを、東横線の運行再開の進行状態に応じて定められた複数のクラスのいずれかに分類する。処理部１１０が判定部１１３としての処理を実行する場合には、設定した複数のクラスのうち着目する特定クラスに分類された特定コメントの割合に基づいて、現在または将来における東横線の運行再開の進行状態を判定する。分類部１１２と判定部１１３の具体的な処理については、後に詳述する。
【0019】
記憶部１２０は、不揮発性の記憶媒体であり、例えば大容量のＨＤＤによって構成されている。記憶部１２０は、状態判定サーバ１００の制御や処理を実行するプログラムを格納するほか、収集部１１１が収集した特定コメントを一時的に保管する役割も担う。また、学習モデルであるＮＮ１２１を記憶している。本実施形態におけるＮＮ１２１は、対象イベントである「東横線の列車運行再開」について、入力された特定コメントを、イベントの進行状態として設定された「再開した」「再開しそう」「止まっている」「無関係、判別不能」の４つのクラスのいずれかに分類する。
【0020】
通信部１３０は、インターネット９００への接続および外部機器とのデータ授受を担い、例えばＬＡＮによって構成されている。通信部１３０は、判定部１１３が判定した判定結果を利用者のスマートフォン２１０へ出力する出力部としての機能も担う。入力部１４０は、システム管理者がプログラムの実行および停止を指示したり、メニューの設定やパラメータの調整を行ったりするための入力デバイスを含む。なお、本実施形態においては、状態判定サーバ１００が状態判定システムの主要構成を備える構成を説明するが、例えば記憶部１２０がインターネット９００に直接的に接続されたネットワークＨＤＤで構成されていても良い。そのような場合には、分散して構成された装置の全体によって状態判定システムが構築される。
【0021】
（２）分類部の処理
次に、特定コメントのクラスへの分類について説明する。図３は、特定コメントのクラスへの分類を説明する図である。ここでは、イベント「東横線の列車運行再開」の進行状態として、４つのクラス「再開した（クラスＡ）」「再開しそう（クラスＢ）」「止まっている（クラスＣ）」「無関係、判別不能（クラスＤ）」が予め設定されている。収集部１１１によって収集された特定コメントは、これら４つのクラスのいずれかに分類される。
次に、特定コメントのクラスへの分類について説明する。図３は、特定コメントのクラスへの分類を説明する図である。ここでは、イベント「東横線の列車運行再開」の進行状態として、４つのクラス「再開した（クラスＡ）」「再開しそう（クラスＢ）」「止まっている（クラスＣ）」「無関係、判別不能（クラスＤ）」が予め設定されている。収集部１１１によって収集された特定コメントは、これら４つのクラスのいずれかに分類される。
【0022】
これらのうち「再開した（クラスＡ）」「再開しそう（クラスＢ）」「止まっている（クラスＣ）」の３つのクラスは、時間の推移と共に想定されるイベントの進行状態に対応している。例えば、収集された特定コメントが「東横線再開したって！」であれば、列車の運行が再開したことを意味するので、クラスＡに分類される。また、「東横線試運転をしているみたい」であれば、列車の運行再開に向けて準備が進んでいる様子を表すので、クラスＢに分類される。同様に、「地震で東横線が止まった」であれば、列車が動いていないことが推測されるので、クラスＣに分類される。
【0023】
一方、「東横線」について言及しているので特定コメントとして収集されたものの、その内容が列車運行再開の進行状態とは関係ないコメントや、そもそも進行状態に関係するものか否かを判別できないコメントも存在し得る。そのような特定コメントは、進行状態に対して「無関係、判別不能（クラスＤ）」のコメントと分類される。例えば、収集された特定コメントが「東横線は東急だよね」であれば、列車の運行再開とは関係のないコメントなので、クラスＤに分類される。
【0024】
なお、本実施形態においては、時間の推移と共に想定される状態を３つのクラスに区分したが、これに限らず、例えば多くの特定コメントが収集できそうな場合にはより多くの情報を抽出し得るので、区分を細分化しても良い。例えば、「再開した」を「臨時ダイヤで再開した」と「通常ダイヤに戻った」などに分けても良い。逆に、コメント数が期待できないような場合には、区分を減らしても良い。
【0025】
本実施形態においては、このようなクラスの分類を分類部１１２が行う。分類部１１２は、ＮＮ１２１へ特定コメントを入力し、出力としてすべてのクラス毎への分類確率を受け取る。分類確率の値が最も大きいクラスを当該特定コメントのクラスと判定する。ＮＮ１２１に、事前に正解クラスが紐づけられた大量のコメント例を教師データとして学習させたものを用いる。本実施形態におけるＮＮ１２１を具体的に説明する。
【0026】
分類部１１２は、コメントを整数列に変換してＮＮ１２１へ入力する。図４は、コメントの整数列への変換を説明する図である。ここでは、コメントの例として「東急東横線が動き出したようです。」を説明する。
【0027】
分類部１１２は、まず、入力コメントに対して形態素解析を行い、単語単位の分かち書きにする。そして、単語ごとに分解した後に、活用語を終止形に変換する。これにより、入力コメントは、「'東急','東横線','が','動く','出す','た','ようだ','。'」と分解される。なお、対象言語を英語とする場合には、スペース文字による単語の区切りをそのまま利用する。
【0028】
ここで、ＮＮ１２１は、特定コメントを単語ごとに整数に変換して得られた整数列を入力して前記複数のクラスへの分類確率を出力する。具体的に、ＮＮ１２１は複数の層から構成される。ＮＮ１２１の第一層では、整数列から数値行列を求める。さらに詳しくは、ＮＮ１２１の第一層では、このように分解した入力コメントのそれぞれの単語を分散表現に変換する。各単語の分散表現は、d次元の行ベクトルとして表される。したがって、n単語に分解される一つの入力コメントは、n行d列の数値行列で表現される。
【0029】
コメント発信者が発信するコメントは、１文であるとは限らない。また、１文がいくつの単語で構成されるかも不定である。また、ソーシャルメディアによっては、コメント可能な字数が制限されている場合もある。発信されたそれぞれのコメントについて、すべての単語を数値ベクトル化すれば、そのコメントが含む内容を最大限に利用できるが、数値行列化した場合に、コメントごとに行列のサイズが異なることになる。
【0030】
本発明者らは、コメントの主要な内容は、当該コメント内で比較的早い段階において言及されるという知見を得た。また、本発明者らは、コメントが１４０文字以内に制限されるソーシャルメディアの場合、３０語の固定長化により８割以上の内容が収まるという知見を得た。そこで、本発明者らは、このような知見に基づいて任意のコメントに固定長化処理を施すことを想到した。
【0031】
本実施形態においては、分類部１１２は、収集部１１１が収集した特定コメントを予め定められた単語数になるように固定長化処理を施す。具体的には、収集した特定コメントに対して分かち書き処理を施した結果、３０語を上回った場合には、上回った単語を棄却する。また、収集した特定コメントに対して分かち書き処理を施した結果、３０語を下回った場合には、不足分を０ベクトルで補う。このように処理することにより、いずれの特定コメントも、３０行d列の数値行列に変換することができる。特に、固定長化処理により、複数のコメントのバッチ並列処理が可能となり、一つずつ処理した場合に比べ１００倍以上の高速化が実現する。
【0032】
なお、３０語を超えるコメントにおいても先頭から３０語以内で概ね趣旨を言及していることが多い。本発明者らは、コメントが１４０文字以内に制限されるソーシャルメディアの場合、３０語を超える部分を棄却することによる分類精度の低下は１％程度であることを確認した。
【0033】
本実施形態においては、このように変換された特定コメントの数値行列を画像データに類似するデータに見立て、ＮＮ１２１の第二層に、画像処理において多用される畳み込み層を採用する。図５は、ＮＮ１２１の処理を説明する概念図である。
【0034】
上述のように数値行列化された特定コメントに対し、畳み込み演算を実行することにより、コメント中の数単語のまとまり（ｎ－ｇｒａｍ）の特徴が抽出される。そして、プーリング処理が施され、コメントごとの特徴量が生成される。例えば、グローバル最大プーリングが実行される。その後、活性化関数にソフトマックス演算を持つ全結合層により、４つのクラスへの分類確率を計算する。４つのクラスは、それぞれクラスＡ、クラスＢ、クラスＣ、クラスＤに対応する。
【0035】
なお、上記ＮＮ１２１では、畳み込み処理を行なう際に、単語分散表現の次元数dに応じた重みフィルターを用いる。具体的には、フィルターの幅をfとしてf行d列の数値行列により表現される重みフィルターが用いられる（図５参照）。このような重みフィルターを用いることで、ＮＮ１２１は、コメントに含まれる概念が反映された情報を学習することが可能となる。
【0036】
例えば、コメントの中に「再開」という単語が含まれている場合、単なる形態素解析による分類では、「再開した（クラスＡ）」に分類するのか、「再開しそう（クラスＢ）」に分類するのかを決定することができない。これに対し、上記ＮＮ１２１では、特定の表現に反応する重みフィルターを学習しているので、「再開した（クラスＡ）」に分類するのか、「再開しそう（クラスＢ）」に分類するのかを適切に決定することができる。換言すると、上記ＮＮ１２１は、同一単語を含むコメントを異なるクラスに分類可能な学習モデルであり、概念に応じたクラス分類を可能としている。
【0037】
また、上記ＮＮ１２１では、単語を数値ベクトル化するための処理で用いるパラメータの学習と、畳み込み処理から分類確率計算までに用いられるパラメータの学習とを一連のバックプロパゲーションで実行することができる。これにより、特定ジャンルのコメントの分類に特化した単語分散表現やｎ－ｇｒａｍの特徴を獲得するため、クラス分類の精度を高めることができる。なお、上記の畳み込み層及びプーリング層に替えて、多層ＬＳＴＭやＴｒａｎｓｆｏｒｍｅｒを用いても同様の効果を得ることが可能である。その他、ＮＮ１２１は、上述のものに限定されず、クラス分類できるものであれば任意のものを採用することができる。
【0038】
本発明者らは、災害時に運休となった路線に対してソーシャルメディアへ発信された実際のコメントを収集し、手作業でその内容に応じた正解クラスをそれぞれのコメントに与えて教師データを作成し、これらを学習させることによってＮＮ１２１を作成した。そして、学習に利用していないコメントを使って、作成したＮＮ１２１の分類精度を検証した。図６は、クラス分類の検証結果を示す図である。
【0039】
学習に利用していない検証用のコメント数は６４９個である。そのうち、作業者がクラスＡと判断する（すなわちクラスＡが正解である）コメント数は１４３個であり、ＮＮ１２１は、そのうち１２５個をクラスＡに分類されると判断した。同様に、作業者がクラスＢと判断するコメント数は２９２個であり、ＮＮ１２１は、そのうち２５８個をクラスＢに分類されると判断した。さらに、作業者がクラスＣと判断するコメント数は９２個であり、ＮＮ１２１は、そのうち７０個をクラスＣに分類されると判断した。そして、作業者がクラスＤと判断するコメント数は１２２個であり、ＮＮ１２１は、そのうち１０２個をクラスＤに分類されると判断した。すなわち、正しく分類できたコメント数は５５５個であり、ＮＮ１２１による分類の正解率は約８５％であった。この程度の正解率が達成できれば、ＮＮ１２１による分類は十分に実用に耐えるものと考えられる。
【0040】
（３）判定部の処理
収集部１１１が一定時間の間に収集した特定コメントのそれぞれを、分類部１１２がクラスＡからクラスＤのいずれかに分類すると、全体のコメント数に対してそれぞれのクラスに属するコメント数の割合を計算することができる。判定部１１３は、各クラスの当該割合に着目することにより、現在または将来における対象イベントの進行状態の判定結果を算出する。なお、ここでは、分類部１１２は、一定期間毎に特定コメントを複数のクラスＡからクラスＤのいずれかに分類するものであり、例えば１分間毎に各コメントをいずれかのクラスに分類する。
収集部１１１が一定時間の間に収集した特定コメントのそれぞれを、分類部１１２がクラスＡからクラスＤのいずれかに分類すると、全体のコメント数に対してそれぞれのクラスに属するコメント数の割合を計算することができる。判定部１１３は、各クラスの当該割合に着目することにより、現在または将来における対象イベントの進行状態の判定結果を算出する。なお、ここでは、分類部１１２は、一定期間毎に特定コメントを複数のクラスＡからクラスＤのいずれかに分類するものであり、例えば１分間毎に各コメントをいずれかのクラスに分類する。
【0041】
現在または将来における対象イベントの進行状態を判定する場合には、時間の推移と共に想定される状態を定めたクラスＡ，クラスＢおよびクラスＣのそれぞれのコメント数の割合を演算の対象とすることが望ましい。すなわち、クラスＡ，クラスＢおよびクラスＣのそれぞれの割合を算出する場合に、進行状態とは無関係なコメントおよび判別不能なコメントが分類されるクラスＤのコメント数を除外して算出する。具体的には、収集されたクラスＡのコメント数がｎＡ個、クラスＢのコメント数がｎＢ個、クラスＣのコメント数がｎＣ個、クラスＤのコメント数がｎＤ個である場合には、クラスＡの割合ＴＡをＴＡ＝ｎＡ／（ｎＡ＋ｎＢ＋ｎＣ）、クラスＢの割合ＴＢをＴＢ＝ｎＢ／（ｎＡ＋ｎＢ＋ｎＣ）、クラスＣの割合ＴＣをＴＣ＝ｎＣ／（ｎＡ＋ｎＢ＋ｎＣ）のように計算し、クラスＤのコメント数を考慮しない。このように計算すれば、コメント数が急増した場合でも計算量を抑えることができる。また、各クラスの割合の変化がイベントの進行状態の推移をより反映すると期待できる。
【0042】
第１実施例として、現在におけるイベントの進行状態を判定する手法について説明する。イベントの例は、引き続き「東横線の運行再開」であり、本実施例も実際に発生したイベントについて特定コメントを収集し、検証したものである。
【0043】
図７Ａは、「東横線の運行再開」のイベントにおけるクラス割合と状態判定結果の時間推移を示すグラフである。横軸は時刻を表す。左縦軸は各クラスの割合（％）を表し、右縦軸は判定結果を０、１、２で表す。判定結果「０」は「止まっている」の予測を表し、「１」は「再開しそう」の予測を表し、「２」は「再開した」の予測を表す。点線で示すグラフは、クラスＡの割合の推移を表す。破線で表すグラフは、クラスＢの割合の推移を表す。なお、クラスＣの割合は、１００－（クラスＡの割合＋クラスＢの割合）であるので省略している。また、それぞれの割合の推移には、突発的な変化を軽減するノイズ除去フィルターを適用している。実線で示すグラフは、判定部１１３が判定した判定結果の推移を表す。
【0044】
全体の傾向としては、クラスＣが大きな割合を占めている期間の「現在における進行状態」の判定結果は「止まっている」であり、クラスＢが大きな割合を占めている期間の「現在における進行状態」の判定結果は「再開しそう」であり、クラスＡが大きな割合を占めている期間の「現在における進行状態」の判定結果は「再開した」である。ただし、本実施例は、その時点において最大の割合を占めるクラスに対応する進行状態を「現在における進行状態」とするものに限定されるものではない。判定部１１３は、その時点における各割合に、直前に判定した進行状態を加味して、現在における前記イベントの前記進行状態を判定してもよい。このような処理により、時間の経過に対して、判定される進行状態が頻繁に遷移してしまうことを防ぐことができる。
【0045】
具体的な演算について説明する。現在における進行状態を判定するために、判定部１１３は、状態推定演算を行う。状態推定演算は、進行状態を状態番号ｉ（ｉ＝０：止まっている、ｉ＝１：再開しそう、ｉ＝２：再開した）で表した場合に、総コストＣをｉ＝０、１、２に対して計算し、Ｃが最小となるｉを決定する演算である。総コストＣiは、
で表される。ここで、σiはフィッティングコストであり、τiは遷移コストである。フィッティングコストσiは、観測値（収集されたコメントの分類）と状態（イベントの進行状態）の当てはまりにくさの指標である。フィッティングコストは、観測値と状態が一致しているほど小さく、離れているほど大きい値になる。
【数1】
【0046】
具体的には、以下のように計算する。コメント分類番号ｊ（ｊ＝０：止まっている、ｊ＝１：再開しそう、ｊ＝２：再開した）、時刻ｔ、時刻ｔに収集された分類ｊのコメント数ｎt,j、時刻ｔに収集された全コメント数Ｓｔ、励起状態における確率変動の割合を示す行列Ｑ（Ｑは励起状態数×励起状態数の行列で、Ｑ［０］[０]，Ｑ［０］[１]，Ｑ［１］[０]，Ｑ［１］[１]の要素を有する。各要素の値はハイパーパラメータである。）と定義すると、状態ｉに対するフィッティングコストσiは、
により計算される。ｌｏｇの括弧内は、多項分布の確率質量関数になっている。上述したようにコメントの割合によって計算する場合、フィッティングコストσiは分類jの割合（％）Ｔt,jを用いて、
となる。ここで、Γ（ｓ）はガンマ関数であり、
で表される。ｐi,jは、状態ｉにおけるコメント分類ｊの発生確率であり、行列で表すと、
となる。
【数2】
【数3】
【数4】
【数5】
【0047】
まず、基底状態としてｉ＝０（止まっている）における確率を決定する。
【数6】
【0048】
次に、行列Ｑを用いて励起状態としてｉ＝１（再開しそう）、ｉ＝２（再開した）における確率を決定する。
【数7】
【0049】
各成分は確率なので、各ｉ（各行ごと）に対して、Σjｐi,j＝１、各ｉ，ｊ（各成分ごと）に対してｐi,j≧０が課せられる。そこで、これらの条件を満たすように修正を加える。具体的には、ｐi,j＜０であるｉ，ｊについてｐi,j＝０とし、Σjｐi,j＝ｐtmp＞１であるｉについてｐi,j＝ｐi,j／ｐtmpとする。
【0050】
このような手法はバースト検知として知られているが、よく知られたバースト検知は励起状態が一つであり、行列Ｑの対角成分を２、非対角成分を１とするのが一般的である。しかし、本実施例における運行再開の進行状態においては、ｉ＝１（再開しそう）とｉ＝２（再開した）の観測値が共起しやすいと考えられるので、非対角成分を１より大きくしている。本実施形態においては、Ｑ［０］[０]＝２．０、Ｑ［０］[１]＝１．２、Ｑ［１］[０]＝１．２、Ｑ［１］[１]＝２．０と設定した。
【0051】
遷移コストτiは、概念的には状態遷移に支払うコストであり、ある状態から別の状態へは、計算される遷移コストτiが大きいほど移りにくいことになる。具体的には、以下のように計算する。現在の進行状態を上記と同様に状態番号ｉで表すと、直前の状態ｉ直前からの遷移コストτiは、
で計算される。γは、直前と現在の状態間の遷移のしにくさを定義する行列であり、ハイパーパラメータである。ここではγを遷移行列と名付ける。また、ｌｏｇの項は、フィッティングコストとスケールを合わせるために導入している。本実施形態においては、遷移行列γを、
と設定した。例えば、「止まっている（ｉ＝０）」から「再開しそう（ｉ＝１）」への遷移コストを計算する場合は、γ［０］［１］＝１０が用いられる。本実施形態においては設定していないが、ｉ＝１からｉ＝２への遷移を事実上禁止したい場合には、γ［１］［２］＝１０００００００などとすれば良い。逆に、ｉ＝１からｉ＝２への遷移が他の遷移よりも非常に発生しやすい場合には、γ［１］［２］の値を負の値に設定しても良い。このように、プログラムの設計者等は、実際の現象を分析して実情に即すように遷移行列γの各成分をカスタマイズすることが肝要である。なお、一般的なバースト検知手法は、例えば、J. Kleinberg, "Bursty and Hierarchical Structure in Streams,"Proceeding of the 8th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 2002.に詳しい。
【数8】
【数9】
【0052】
上記の演算による総コストＣiのうち最も小さい値を示す状態番号ｉの進行状態を、現在における進行状態の判定結果とする。図７Ａに示す例では、判定部１１３は、２０時５０分ころまでは「止まっている」と判定し、それから２２時１０分ころまでは「再開しそう」と判定し、それ以降は「再開した」と判定している。なお、この事象において鉄道会社が正式に運行再開をアナウンスした時刻は２２時３０分であった。実際にはそれ以前に運転が再開されたと考えられるので、本実施形態における判定プログラムの判定結果が実際の推移におよそ対応していると推測できる。このような検証結果から、本実施形態に係る状態判定システムの利用者は、運行再開に関する進行状態をある程度の正確性をもっていち早く知ることができると言える。
【0053】
なお、現在における進行状態を判定するための演算手法は、上記のバースト検知手法に限らない。時間の経過に対して判定結果が頻繁に変化しないように、直前に判定した進行状態を加味する手法は、他にも種々採用し得る。演算を簡素化してプロセッサの負荷を軽減する場合には、例えば、各クラスの割合に予め用意した重み付け係数を乗じ、その中から大きな値を示すものを判定結果とすることもできる。この場合、ある状態から別の状態へ遷移する場合の重み付け係数は、遷移しやすいほど大きな値を設定しておく。
【0054】
上述した判定部１１３の処理について補足する。判定部１１３は、所定の判定期間毎にイベントの進行状態を判定する。例えば、図７Ｂに示すように、判定期間は１分間とする。現在が時刻ｔであるとすると、現在のイベントの進行状態は、現在の時刻ｔに時間的に最も近い判定期間Ｄ１のコメントの分類結果に基づいて判定される。また、直前の判定期間Ｄ２は、現在の判定期間Ｄ１に時間的に逆方向に連続する判定期間である。
【0055】
このような前提で、判定部１１３は、一定期間毎（１分間毎）に収集した各クラスのコメントの割合（数６のｐ0,1 ,ｐ0,2を参照）に基づいて、現在のイベントの進行状態を判定する判定期間Ｄ１において各クラスが取り得る発生確率（ｐi,j）を算出する。そして、判定部１１３は、算出した各クラスが取り得る発生確率（ｐi,j）と、判定期間Ｄ１に収集されたクラス毎のコメント数 （ｎt,j）とに基づいて、現在のフィッティングコストσiを算出する。
【0056】
また、判定部１１３は、現在のイベントの進行状態を判定する判定期間Ｄ１より前の判定期間Ｄ２の間に判定したイベントの進行状態と、判定期間Ｄ１に取り得るイベントの進行状態との間の遷移行列γに基づいて、遷移コストτiを算出する。
【0057】
そして、判定部１１３は、これらのフィッティングコストσi及び遷移コストτiから総コストＣiを算出し、現在におけるイベントの進行状態を判定する。なお、総コストＣiは、必ずしもフィッティングコストσi及び遷移コストτiの両方から算出される必要はなく、いずれか一方から算出されるものであってもよい。
【0058】
図８は、図７Ａのイベントに対して利用者のスマートフォン２１０に表示される状態判定結果の表示例である。スマートフォン２１０のディスプレイ２１１には、主に、イベント表示２２１と状態判定表示２２２が表示される。イベント表示２２１は、対象イベントの情報が表示される。対象イベントは、利用者により選択されたイベントであり、例えば、その時点で状態判定が提供されるイベント一覧のメニューから選択される。対象イベントの情報としては、例えば、「東横線は事故のため１４：３０から運休しています」のように表示される。
【0059】
状態判定表示２２２は、状態判定サーバ１００から送られてきた判定結果が表示される。ここで状態判定サーバ１００から送られてくるのは、現在における進行状態の判定結果であるので、例えば、「現在、東横線の状態は『再開しそう』です」のように表示される。このように、利用者は、自身のスマートフォン２１０で、対象イベントの現在における進行状態の判定結果を容易かつ簡潔に知ることができる。
【0060】
次に、第２実施例として、将来におけるイベントの進行状態を判定する手法について説明する。イベントの例は、引き続き「東横線の運行再開」であり、一つ目の実施例と同じものである。
【0061】
図９は、クラスＡの割合の時間推移と再開判定時刻を示すグラフである。横軸は時刻を表す。縦軸はクラスＡの割合（％）を表わす。点線で示すグラフは、クラスＡの割合の推移を表すが、本実施例では状態判定サーバ１００が２２時ちょうどに利用者からのリクエストを受け取った場合を想定するので、２２時００分までの推移を示す。なお、クラスＡの割合の推移には、突発的な変化を軽減するノイズ除去フィルターを適用している。実線で示すグラフは、２２時００分までのクラスＡの割合の推移に対して当てはめたフィッティング関数を表す。
【0062】
フィッティング関数は、ここでは０から１００の間で変化するように規格化したシグモイド型関数を利用する。図示するようにシグモイド型関数を当てはめることにより、クラスＡの割合が２２時００分以降にどうのように変化するかを推定する。
【0063】
クラスＡの割合は「再開した」の割合なので、この割合が一定値を超えると列車の運行が実際に再開されていると考えることができる。そこで、本実施例では、その閾値Ｓａを８０％と定め、当てはめたフィッティング関数が８０％を超える時刻を、運行の再開予測時刻とする。図の例ではフィッティング関数が８０％を超える時刻は２２時２８分である。したがって、判定部１１３は、将来におけるイベントの進行状態である「再開予測時刻」を、２２時２８分であると判定する。上述のように、この事象において鉄道会社が正式に運行再開をアナウンスした時刻は２２時３０分であったので、良好な判定結果であると評価できる。なお、本実施例ではフィッティング関数としてシグモイド型関数を採用したが、事象に合わせて他の関数をフィッティング関数として採用しても良い。
【0064】
図１０は、図９のイベントに対して利用者のスマートフォン２１０に表示される再開予測時刻の表示例である。スマートフォン２１０のディスプレイ２１１には、主に、イベント表示２２１と状態判定表示２２２が表示される。イベント表示２２１は、図８の例と同様である。
【0065】
状態判定表示２２２は、状態判定サーバ１００から送られてきた判定結果が表示される。ここで状態判定サーバ１００から送られてくるのは、将来における進行状態の判定結果であるので、例えば、「東横線の再開予測時刻は『２２：２８』です」のように表示される。このように、利用者は、自身のスマートフォン２１０で、対象イベントの将来における進行状態の判定結果を容易かつ簡潔に知ることができる。
【0066】
（４）状態判定処理
次に、本実施形態における状態判定サーバ１００の処理手順について説明する。状態判定サーバ１００による状態判定処理は、状態判定プログラムがコンピュータであるプロセッサに各ステップを実行させることにより実現される。図１１は、状態判定プログラムの処理手順を示すフロー図である。
次に、本実施形態における状態判定サーバ１００の処理手順について説明する。状態判定サーバ１００による状態判定処理は、状態判定プログラムがコンピュータであるプロセッサに各ステップを実行させることにより実現される。図１１は、状態判定プログラムの処理手順を示すフロー図である。
【0067】
図示するフローは、システム管理者が対象イベントを定めてサービスの提供を開始した時点から始まる。収集部１１１は、ステップＳ１０１で、ソーシャルメディアに対して発信されたコメントのうち、対象イベントに関する特定コメントを、メディアサーバ９２０のコメント蓄積部９２１から収集する。ステップＳ１０２へ進むと、分類部１１２は、記憶部１２０から読み出したＮＮ１２１を用いて、ステップＳ１０１で収集された特定コメントを、イベントの進行状態に応じて定められた複数のクラスのいずれかに分類する。
【0068】
イベントごとに設定される単位時間が経過したら、判定部１１３は、ステップＳ１０３で、その間に収集され分類された特定コメントにおけるクラスごとの割合に基づいて、現在または将来における対象イベントの進行状態を判定する。このとき、判定に用いるクラスを特に着目する特定クラスと定め、特定クラスに分類された特定コメントの割合に基づいて進行状態を判定すると良い。上述の第１実施例では、除外クラスとしたクラスＤ以外のクラスＡ、クラスＢおよびクラスＣが特定クラスであり、第２実施例では、フィッティング関数を当てはめたクラスＡが特定クラスである。クラスの設定の仕方によっては、全てのクラスを特定クラスとしても良い。
【0069】
ステップＳ１０４へ進み、処理部１１０は、利用者のスマートフォン２１０（ここでは「リクエスト端末」とする）から、状態判定のリクエストを受け取ったか否かを確認する。受け取っていたらステップＳ１０５へ、受け取っていなければステップＳ１０５をスキップしてステップＳ１０６へ進む。ステップＳ１０５へ進んだ場合には、ステップＳ１０３で判定した判定結果をリクエスト端末へ出力し、ステップＳ１０６へ進む。
【0070】
ステップＳ１０６へ進むと、処理部１１０は、イベント処理が終期に達したか否かを判断する。例えば、対象イベントが列車の運行再開であれば、実際に列車の運行が再開された情報を取得してから所定時間の経過後を終期とする。終期は、対象イベントごとに、状態判定のリクエストが途絶えると判定される時期に設定すると良い。処理部１１０は、イベント処理が終期に達していないと判断した場合には、ステップＳ１０１へ戻り、終期に達したと判断した場合には、一連の処理を終了させる。
【0071】
なお、上述の説明では、状態判定サーバ１００が単一の装置で動作される例を用いて説明したが、状態判定サーバ１００の構成は、発明の要旨を逸脱しない範囲で、適宜構成の追加又は変更が可能なものである。例えば、図１２に示すように、状態判定サーバ１００がリクエスト端末から直接リクエストを受け付けるのではなく、別途設置したリクエスト処理装置８００がリクエスト端末２１０からリクエストを受け付ける構成であってもよい。この場合、状態判定サーバ１００は、ステップＳ１０３で進行状態の判定をする度に、所定の記憶装置８５０に進行状態の判定結果を書き込む。リクエスト処理装置８００は、リクエスト端末２１０からのリクエストを受け取った場合に、上記記憶装置８５０から最新の判定結果を取り出して、リクエスト端末２１０に出力する。
【0072】
以上、公共交通機関の非常停止後の運行再開事象を対象イベントとして本実施形態を説明したが、分析対象とするイベントはこれに限らない。例えば、特定名所の桜の開花事象を対象イベントとすることもできる。この場合、進行状態として、例えば「つぼみ」「三分咲き」「五分咲き」「満開近い」「満開」「散り始め」「葉桜」の７クラスを設定し得る。また、「千鳥ヶ淵の桜、もうすぐ満開だね」のようなコメントが特定コメントとして収集される。
【0073】
（５）テキスト分類
図１３は、テキストデータから各種業務に必要な情報を抽出する分類システムが利用される全体環境と、分類に関する情報の流れを説明する図である。以下、利用者と分析者が、マーケティング業務に携わるマーケターであること前提として説明する。
分類システムは、利用者端末３５０、分析者端末３６０、管理サーバ９３０、分類サーバ３００によって実現される。
図１３は、テキストデータから各種業務に必要な情報を抽出する分類システムが利用される全体環境と、分類に関する情報の流れを説明する図である。以下、利用者と分析者が、マーケティング業務に携わるマーケターであること前提として説明する。
分類システムは、利用者端末３５０、分析者端末３６０、管理サーバ９３０、分類サーバ３００によって実現される。
【0074】
利用者端末３５０は、利用者が使用する端末装置であり、一般的なコンピュータにより実現可能なものである。ここでは、利用者端末３５０はイベント会場や展示場などに携行して設置することが可能なものである。利用者端末３５０は、イベント会場や展示場での会話を集音し、音声データを生成すると、インターネット９００を介して管理サーバ９３０へ音声データを送信する。
【0075】
分析者端末３６０は、一般的なコンピュータにより実現可能なものであり、イベント会場や展示場での会話の音声データなどを分析するために分析者が使用する端末装置である。分析者端末３６０は分類サーバ３００と通信して、分類サーバ３００による音声データの分析結果などを出力する。
【0076】
管理サーバ９３０は、利用者端末３５０から送信された音声データの音声認識を行い文字列に変換する。管理サーバ９３０は、変換した文字列を所定の単位（話者単位、文単位）に分割し、分割したテキストデータをテキストデータ記憶部９３１に記憶する。テキストデータ記憶部９３１は、例えば大容量のＨＤＤによって構成されている。テキストデータ記憶部９３１に記憶されるテキストデータの一部は、後述のニューラルネットワーク３２１の教師データであり、事前に正解クラスが紐づけられている。教師データを記憶する場所は、分類サーバ３００の記憶部３２０でもよいし、管理サーバ９３０や分類サーバ３００とは別のサーバ（例えば、ニューラルネットワーク３２１等の学習用に準備したサーバ）の記憶部でもよい。ここでは、正解クラスは「Ｅ」「Ｆ」「Ｇ」「Ｈ」の４つのクラスであり、例えば、「商品に関してポジティブな発言（クラスＥ）」「商品に関してネガティブな発言（クラスＦ）」「商品に関してポジティブでもネガティブでもない発言（クラスＧ）」「商品と関係のない発言（クラスＨ）」である。なお、正解クラスの分類の種類や数は、本実施形態の例示に限定されるものではなく、利用者の業務に適した分類の種類や数を選択することができる。
【0077】
図１４は、本実施形態における教師データの一例を示す図である。図１４において、教師データは、所定の単位（話者単位、文単位）で管理された各テキストデータに対して、４つのクラスのいずれかが紐づけられている。例えば、話者１の「Ａ社のヒーターは寒さがしのげてよかった。」のテキストデータに対してクラスＥが紐づけられており、話者１の「ただ、持ち運びの時に重くて運びづらい。」のテキストデータに対してクラスＦが紐づけられている。
【0078】
分類サーバ３００は、インターネット９００に接続されており、インターネット９００を介して、直接的または間接的に利用者の利用者端末３５０、分析者の分析者端末３６０、管理サーバ９３０と情報の授受を行う。分類サーバ３００は、図１５に示すように、主に、処理部３１０、記憶部３２０、通信部１３０、および入力部１４０によって構成される。処理部３１０は、分類サーバ３００の制御とプログラムの実行処理を行うプロセッサ（ＣＰＵ及び／又はＧＰＵ等で構成される）である。処理部３１０は、記憶部３２０に記憶された分類プログラムを読み出して、分類に関する様々な処理を実行する。例えば、処理部３１０は、収集部３１１としての処理やクラスタリング部３１３としての処理を実行する。
処理部３１０が収集部３１１としての処理を実行する場合には、管理サーバ９３０のテキストデータ記憶部９３１からテキストデータを収集する。処理部３１０が分類部３１２としての処理を実行する場合には、記憶部３２０から読み出したニューラルネットワーク３２１（以下「ＮＮ３２１」とする）を用いて、収集部３１１が収集したテキストデータを、予め定められた複数のクラス（「Ｅ」，「Ｆ」，「Ｇ」，「Ｈ」）のいずれかに分類する。分類部３１２は上述した分類部１１２と同様の機能を有する。したがって、分類部３１２の処理は、図２の分類部１１２がコメント（所定の単位、すなわち、ソーシャルメディアへの発信者の発信の単位、のテキストデータ）を４つのクラス（複数のクラス）のいずれかに分類する処理と同じである。
処理部３１０がクラスタリング部３１３としての処理を実行する場合には、記憶部３２０から読み出したクラスタリングモデル３２２を用いて、分類部３１２により分類されたテキストデータに対してクラスタリングを行う。具体的には、分類部３１２で同じクラスに分類されたテキストデータが、どのような内容かによってグループ分けされる。
処理部３１０が収集部３１１としての処理を実行する場合には、管理サーバ９３０のテキストデータ記憶部９３１からテキストデータを収集する。処理部３１０が分類部３１２としての処理を実行する場合には、記憶部３２０から読み出したニューラルネットワーク３２１（以下「ＮＮ３２１」とする）を用いて、収集部３１１が収集したテキストデータを、予め定められた複数のクラス（「Ｅ」，「Ｆ」，「Ｇ」，「Ｈ」）のいずれかに分類する。分類部３１２は上述した分類部１１２と同様の機能を有する。したがって、分類部３１２の処理は、図２の分類部１１２がコメント（所定の単位、すなわち、ソーシャルメディアへの発信者の発信の単位、のテキストデータ）を４つのクラス（複数のクラス）のいずれかに分類する処理と同じである。
処理部３１０がクラスタリング部３１３としての処理を実行する場合には、記憶部３２０から読み出したクラスタリングモデル３２２を用いて、分類部３１２により分類されたテキストデータに対してクラスタリングを行う。具体的には、分類部３１２で同じクラスに分類されたテキストデータが、どのような内容かによってグループ分けされる。
【0079】
記憶部３２０は、不揮発性の記憶媒体であり、例えば大容量のＨＤＤによって構成されている。記憶部３２０は、分類サーバ３００の制御や処理を実行するプログラムを格納するほか、収集部３１１が収集したテキストデータを一時的に記憶する役割も担う。また、学習モデルであるＮＮ３２１とクラスタリングモデル３２２を記憶している。本実施形態におけるＮＮ３２１は、所定の単位のテキストデータを予め定められた「Ｅ」「Ｆ」「Ｇ」「Ｈ」の４つのクラスのいずれかに分類するモデルであり、テキストデータ記憶部９３１に記憶された教師データで学習されている。クラスタリングモデル３２２は、分類部３１２から出力された同じクラスのテキストデータに基づいて、教師なし学習で学習されている。クラスタリングモデル３２２は、事前にグループ分けされた教師データに基づいて、教師あり学習により学習されるものでもよい。
【0080】
通信部１３０は、インターネット９００への接続および外部機器とのデータ授受を担い、例えばＬＡＮによって構成されている。通信部１３０は、分類部３１２による分類結果及びクラスタリング部３１３によるクラスタリング結果を分析者の分析者端末３６０へ出力する出力部としての機能も担う。入力部１４０は、システム管理者がプログラムの実行および停止を指示したり、メニューの設定やパラメータの調整を行ったりするための入力デバイスを含む。
【0081】
図１６は、分類プログラムの処理手順を示すフロー図である。
ステップＳ３０１で、処理部３１０は、通信部１３０を介して、分析者端末３６０からの分類指示を受けとる。処理部３１０は、収集部３１１の機能により、分類指示に基づいて、テキストデータ記憶部９３１からテキストデータを収集し、記憶部３２０に記憶する。
ステップＳ３０１で、処理部３１０は、通信部１３０を介して、分析者端末３６０からの分類指示を受けとる。処理部３１０は、収集部３１１の機能により、分類指示に基づいて、テキストデータ記憶部９３１からテキストデータを収集し、記憶部３２０に記憶する。
【0082】
ステップＳ３０２で、処理部３１０は、分類部３１２の機能により、記憶部３２０から読み出したＮＮ３２１を用いて、収集された各テキストデータを「Ｅ」「Ｆ」「Ｇ」「Ｈ」のいずれかに分類する。
ステップＳ３０３で、処理部３１０は、クラスタリング部３１３の機能により、記憶部３２０から読み出したクラスタリングモデル３２２を用いて、ステップＳ３０２で分類された各クラスのテキストデータの属するグループを決定する。
ステップＳ３０４で、処理部３１０は、通信部１３０を介して、分類部３１２による分類結果とクラスタリング部３１３によるクラスタリング結果を分析者端末３６０へ出力する。
ステップＳ３０３で、処理部３１０は、クラスタリング部３１３の機能により、記憶部３２０から読み出したクラスタリングモデル３２２を用いて、ステップＳ３０２で分類された各クラスのテキストデータの属するグループを決定する。
ステップＳ３０４で、処理部３１０は、通信部１３０を介して、分類部３１２による分類結果とクラスタリング部３１３によるクラスタリング結果を分析者端末３６０へ出力する。
【0083】
このように、上述した分類システムは、テキストデータ記憶部９３１が所定の単位で分割されたテキストデータを記憶し、分類部３１２が分割された各テキストデータを予め定められた複数のクラスのいずれかに分類し、同じクラスに分類されたテキストデータに対してクラスタリング部３１３がクラスタリングを行うものである。このような構成により、分析者は、テキストデータの分類結果から業務に必要な情報のみを抽出し、利用することができる。例えば、分析者は、「商品に関してポジティブな発言（クラスＥ）」に紐づけられたテキストデータのみを抽出したり、「商品に関してネガティブな発言（クラスＦ）」に紐づけられたテキストデータのみを抽出したりすることで、抽出したテキストデータをマーケティングや商品開発へのフィードバックに利用できる。また、分析者は、同じクラスに分類されたテキストデータのクラスタリング結果を参照することで、クラス毎にどのような内容の意見が多かったかを確認することができる。
【0084】
なお、上記説明では、利用者端末３５０に、イベント会場や展示場での会話の音声データが入力されるとしたが、管理サーバ９３０のテキストデータ記憶部９３１に記憶されるテキストデータはこれに限られるものではない。例えば、テキストデータ記憶部９３１に記憶されるテキストデータの他の例としては、ＳＮＳや口コミサイトから抽出したテキストデータ、マーケティング調査におけるアンケートのテキストデータ、Ｗｅｂサイトへの問い合わせ，コールセンター，お客様相談窓口における対話ログのテキストデータ、社内日報，議事録，報告書等の文書のテキストデータ、トレンド予測に関するテキストデータ、が挙げられる。また、管理サーバ９３０がテキストデータを管理する所定の単位は、話者単位や文単位に限定されるものではない。
なお、上記説明において、分類サーバ３００、利用者端末３５０、分析者端末３６０、管理サーバ９３０を別の構成としたが、これらの構成の一部又は全部は一体化した装置として実現されてもよいものである。
なお、上記説明において、分類サーバ３００、利用者端末３５０、分析者端末３６０、管理サーバ９３０を別の構成としたが、これらの構成の一部又は全部は一体化した装置として実現されてもよいものである。
【0085】
また、利用者端末３５０が、音声データと当該音声データで言及されている商品名とを関連付けて送信し、管理サーバ９３０が、分割したテキストデータと商品名とを関連付けて記憶してもよい。さらに、分類サーバ３００に記憶されるＮＮ３２１は、テキストデータに関連付けられた商品毎に異なる個別モデルであってもよいし、複数の商品に対して汎用的に利用できる汎用モデルであってもよい。同様に、分類サーバ３００に記憶されるクラスタリングモデル３２２も、個別モデルでも汎用モデルでもよい。さらに、分類サーバ３００の処理部３１０は、分析者端末３６０から分類対象の商品名に関する指示を受けとり、指示された商品名に関連付けられたテキストデータをテキストデータ記憶部９２２から抽出して収集するものでもよい。さらに、分類サーバ３００の処理部３１０は、商品名に対応するＮＮ３２１のモデルを用いて分類部３１２としての処理を実行するものでもよいし、商品名に対応するクラスタリングモデル３２２のモデルを用いてクラスタリング部３１３としての処理を実行するものでもよい。なお、テキストデータと関連付けられる情報は、音声データを記録した日付やイベントの名称等であってもよい。
【0086】
＜他の実施形態＞
本開示は、上記各実施形態そのままに限定されるものではない。本開示は、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できるものである。また、本開示は、上記各実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の開示を形成できるものである。例えば、実施形態に示される全構成要素から幾つかの構成要素は削除してもよいものである。さらに、異なる実施形態に構成要素を適宜組み合わせてもよいものである。
本開示は、上記各実施形態そのままに限定されるものではない。本開示は、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できるものである。また、本開示は、上記各実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の開示を形成できるものである。例えば、実施形態に示される全構成要素から幾つかの構成要素は削除してもよいものである。さらに、異なる実施形態に構成要素を適宜組み合わせてもよいものである。
【符号の説明】
【0087】
１００ 状態判定サーバ、１１０，３１０ 処理部、１１１，３１１ 収集部、１１２，３１２ 分類部、１１３ 判定部、１２０，３２０ 記憶部、１２１，３２１ ＮＮ、１３０ 通信部、１４０ 入力部、２１０ スマートフォン、２１１ ディスプレイ、２２１ イベント表示、２２２ 状態判定表示、３００ 分類サーバ、３１３ クラスタリング部、３２２ クラスタリングモデル、３６０ 分析者端末、９００ インターネット、９１０ スマートフォン、９２０ メディアサーバ、９２１ コメント蓄積部、９３０ 管理サーバ、９３１ テキストデータ記憶部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】