JP6923864B1 - 状態判定システム、状態判定方法および状態判定プログラム - Google Patents

Abstract

［課題］ソーシャルメディアに発信されたコメントを利用して、対象となるイベントの進行状態を、即時性と正確性を両立して判定する状態判定システム等を提供する。［解決手段］状態判定システムは、ソーシャルメディアに対して発信されたコメントを、イベントの進行状態に応じて定められた複数のクラスのいずれかに分類する分類部と、複数のクラスのうち着目する特定クラスに分類された特定コメントの割合に基づいて、現在または将来におけるイベントの進行状態を判定する判定部とを備える。

Description

本発明は、状態判定システム、状態判定方法および状態判定プログラムに関する。

例えば事故の発生により鉄道が一定期間運休を余儀なくされるような場合に、運行の再開予測を一刻も早く知らなければならない利用者がいる。しかし、鉄道会社は正確を期するために不確かな情報を公表せず、往々にして運行を再開してからその旨を公表する。そこで、利用者は、ソーシャルメディアに対して発信された第三者のコメントを参照して、いち早く運行状況を予想し、行動する場合がある。しかし、ソーシャルメディアの個々のコメントは、即時性がある反面、正確性に劣る場合がある。このような背景のもと、ソーシャルメディアに発信されたコメントを、実際の状況を予測する材料とする技術が開発されるようになってきた（例えば、特許文献１参照）。

特開２０１４−２０６８２９号公報

例えば特許文献１では、ソーシャルメディア情報を用いて、駅の混雑を正確に予測することを意図した技術が開示されている。しかしながら、特許文献１に記載の技術は、ソーシャルメディアに発信された多数のコメントから、対象イベントの進行状態を大局的に予測するのには不向きな場合がある。

本発明は、このような問題を解決するためになされたものであり、ソーシャルメディアに発信されたコメントを利用して、対象となるイベントの進行状態を、即時性と正確性を両立して判定する状態判定システム等を提供するものである。

本発明の第１の態様における状態判定システムは、ソーシャルメディアに対して発信されたコメントを、イベントの進行状態に応じて定められた複数のクラスのいずれかに分類する分類部と、複数のクラスのうち着目する特定クラスに分類された特定コメントの割合に基づいて、現在または将来におけるイベントの進行状態の判定結果を算出する判定部とを備える。

本発明の第２の態様における状態判定方法は、ソーシャルメディアに対して発信されたコメントを、イベントの進行状態に応じて定められた複数のクラスのいずれかに分類する分類ステップと、複数のクラスのうち着目する特定クラスに分類された特定コメントの割合に基づいて、現在または将来におけるイベントの進行状態の判定結果を算出する判定ステップとを有する。

本発明の第３の態様における状態判定プログラムは、ソーシャルメディアに対して発信されたコメントを、イベントの進行状態に応じて定められた複数のクラスのいずれかに分類する分類ステップと、複数のクラスのうち着目する特定クラスに分類された特定コメントの割合に基づいて、現在または将来におけるイベントの進行状態の判定結果を算出する判定ステップとをコンピュータに実行させる。

このように、多数寄せ集められたコメントをその内容に応じて分類し、分類によって現れる大局的な傾向を利用して対象であるイベントの進行状態を判定する。このような手法によれば、個々のコメントの正確性の全体の予測に及ぼす影響を低減しつつ、いち早く判定結果を提示することができる。

本発明により、ソーシャルメディアに発信されたコメントを利用して、対象となるイベントの進行状態を、即時性と正確性を両立して判定する状態判定システム等を提供することができる。

本実施形態に係る状態判定システムが利用される全体環境と、状態判定に関する情報の流れを説明する図である。 状態判定サーバのハードウェア構成を示す図である。 コメントのクラスへの分類を説明する図である。 コメントの整数列への変換を説明する図である。 ニューラルネットワークの処理を説明する図である。 クラス分類の検証結果を示す図である。 クラス割合と状態判定結果の時間推移を示すグラフである。 状態判定するための判定期間を説明するための図である。 現在における状態判定結果の表示例である。 クラスＡの割合の時間推移と再開判定時刻を示すグラフである。 再開判定時刻の表示例である。 状態判定プログラムの処理手順を示すフロー図である。 他の例における全体環境と、状態判定に関する情報の流れを説明する図である。

以下に発明の実施形態を通じて本発明を説明するが、特許請求の範囲に係る発明を以下の実施形態に限定するものではない。また、実施形態で説明する構成の全てが課題を解決するための手段として必須であるとは限らない。

（１）全体構成
図１は、本実施形態に係る状態判定システムが利用される全体環境と、状態判定に関する情報の流れを説明する図である。本実施形態における状態判定システムは、状態判定サーバ１００によって実現される。状態判定サーバ１００は、インターネット９００に接続されており、インターネット９００を介して、直接的または間接的に利用者のスマートフォン２１０、コメント発信者のスマートフォン９１０、およびメディアサーバ９２０と情報の授受を行う。

より具体的には、コメント発信者が各自のスマートフォン９１０を操作して発信したツイート等のコメントは、インターネット９００を介してメディアサーバ９２０へ送られ、メディアサーバ９２０に接続されたコメント蓄積部９２１に蓄積される。コメント蓄積部９２１は、例えば大容量のＨＤＤによって構成されている。コメント発信者のスマートフォン９１０には、メディアサーバ９２０を運営する運営者によってリリースされたアプリケーションがインストールされており、コメント発信者は、当該アプリケーションを介してコメントをテキスト入力することができる。なお、コメントは、コメント発信者の発声を認識してテキスト変換したものであっても良い。

コメント蓄積部９２１に蓄積されたコメント発信者のコメントは、アクセス権限に応じて閲覧することができる。このように特定のアプリケーションを介して利用者間でコメントを授受するサービスは、代表的にはソーシャルネットワークサービス（ＳＮＳ）が知られている。ただし、本実施形態におけるソーシャルメディアは、ＳＮＳに限らず、発信者が一方的に情報を発信するサービスも含み得る。

本実施形態における状態判定システムは、このように任意に運営されている１つまたは複数のソーシャルメディアを利用する。具体的には、状態判定サーバ１００は、分析対象のイベントを定めると、当該イベントに関するコメントを特定コメントと定め、インターネット９００を介してメディアサーバ９２０へアクセスし、コメント蓄積部９２１から特定コメントを収集する。複数のソーシャルメディアを利用する場合には、それぞれのソーシャルメディアのメディアサーバ９２０へアクセスする。状態判定サーバ１００は、収集したコメントに基づいて当該イベントの現在または将来における進行状態を判定する演算処理を実行する。そして、利用者のスマートフォン２１０から状態判定のリクエストを受けると、スマートフォン２１０へ判定した判定結果を送信する。利用者は、気になるイベントの進行状態を、スマートフォン２１０に表示される判定結果により想像することができる。

なお、ここでは、ツイート等のコメントとして、３００文字以内の文字数で構成されるものを分析対象とする。以下においては、公共交通機関の非常停止後の運行再開事象を分析対象のイベントとして説明する。具体的には、発生した車両事故により運休が余儀なくされているある鉄道路線（「東急電鉄」の「東横線」を具体例とする）において、列車の運行再開に関する進行状態を判定する例を説明する。東横線の利用者は、例えば自宅やオフィスに居ながら、「現時点で運行が再開しているのか」や、「いつ運行が再開しそうか」といった情報を知りたい場合がある。そのような場合において、利用者は、スマートフォン２１０の専用アプリケーションを利用して、状態判定サーバ１００へ状態判定をリクエストする。

図２は、状態判定サーバ１００のハードウェア構成を示す図である。状態判定サーバ１００は、主に、処理部１１０、記憶部１２０、通信部１３０、および入力部１４０によって構成される。処理部１１０は、状態判定サーバ１００の制御とプログラムの実行処理を行うプロセッサ（ＣＰＵ及び／又はＧＰＵ等で構成される）である。処理部１１０は、記憶部１２０に記憶された状態判定プログラムを読み出して、状態判定に関する様々な処理を実行する。処理部１１０が収集部１１１としての処理を実行する場合には、コメント蓄積部９２１に蓄積されたコメントのうち、分析対象として指定されたイベントである「東横線の運行再開」に関する特定コメントを収集する。

具体的には、収集部１１１は、通信部１３０を介してコメント蓄積部９２１へアクセスし、コメント蓄積部９２１で一定時間の間に蓄積されたコメントから、キーワード検索により特定コメントを抽出する。そして、キーワード検索により抽出されたコメントを特定コメントとして状態判定サーバ１００へ取り込む。キーワード検索は、例えば、路線名に関する複数のキーワード（「東横線」「東急東横線」等）が予め設定されており、設定されているキーワードを含むコメントを抽出する。特定のキーワードについては、他のキーワードと共に含まれている場合に抽出候補とする等の抽出条件を定めても良い。また、キーワード検索を実行する対象コメントを、例えばタグ情報として東横線沿線の位置情報を有するコメントに限っても良い。

処理部１１０が分類部１１２としての処理を実行する場合には、記憶部１２０から読み出したニューラルネットワーク１２１（以下「ＮＮ１２１」とする）を用いて特定コメントを、東横線の運行再開の進行状態に応じて定められた複数のクラスのいずれかに分類する。処理部１１０が判定部１１３としての処理を実行する場合には、設定した複数のクラスのうち着目する特定クラスに分類された特定コメントの割合に基づいて、現在または将来における東横線の運行再開の進行状態を判定する。分類部１１２と判定部１１３の具体的な処理については、後に詳述する。

記憶部１２０は、不揮発性の記憶媒体であり、例えば大容量のＨＤＤによって構成されている。記憶部１２０は、状態判定サーバ１００の制御や処理を実行するプログラムを格納するほか、収集部１１１が収集した特定コメントを一時的に保管する役割も担う。また、学習モデルであるＮＮ１２１を記憶している。本実施形態におけるＮＮ１２１は、対象イベントである「東横線の列車運行再開」について、入力された特定コメントを、イベントの進行状態として設定された「再開した」「再開しそう」「止まっている」「無関係、判別不能」の４つのクラスのいずれかに分類する。

通信部１３０は、インターネット９００への接続および外部機器とのデータ授受を担い、例えばＬＡＮによって構成されている。通信部１３０は、判定部１１３が判定した判定結果を利用者のスマートフォン２１０へ出力する出力部としての機能も担う。入力部１４０は、システム管理者がプログラムの実行および停止を指示したり、メニューの設定やパラメータの調整を行ったりするための入力デバイスを含む。なお、本実施形態においては、状態判定サーバ１００が状態判定システムの主要構成を備える構成を説明するが、例えば記憶部１２０がインターネット９００に直接的に接続されたネットワークＨＤＤで構成されていても良い。そのような場合には、分散して構成された装置の全体によって状態判定システムが構築される。

（２）分類部の処理
次に、特定コメントのクラスへの分類について説明する。図３は、特定コメントのクラスへの分類を説明する図である。ここでは、イベント「東横線の列車運行再開」の進行状態として、４つのクラス「再開した（クラスＡ）」「再開しそう（クラスＢ）」「止まっている（クラスＣ）」「無関係、判別不能（クラスＤ）」が予め設定されている。収集部１１１によって収集された特定コメントは、これら４つのクラスのいずれかに分類される。

これらのうち「再開した（クラスＡ）」「再開しそう（クラスＢ）」「止まっている（クラスＣ）」の３つのクラスは、時間の推移と共に想定されるイベントの進行状態に対応している。例えば、収集された特定コメントが「東横線再開したって！」であれば、列車の運行が再開したことを意味するので、クラスＡに分類される。また、「東横線試運転をしているみたい」であれば、列車の運行再開に向けて準備が進んでいる様子を表すので、クラスＢに分類される。同様に、「地震で東横線が止まった」であれば、列車が動いていないことが推測されるので、クラスＣに分類される。

一方、「東横線」について言及しているので特定コメントとして収集されたものの、その内容が列車運行再開の進行状態とは関係ないコメントや、そもそも進行状態に関係するものか否かを判別できないコメントも存在し得る。そのような特定コメントは、進行状態に対して「無関係、判別不能（クラスＤ）」のコメントと分類される。例えば、収集された特定コメントが「東横線は東急だよね」であれば、列車の運行再開とは関係のないコメントなので、クラスＤに分類される。

なお、本実施形態においては、時間の推移と共に想定される状態を３つのクラスに区分したが、これに限らず、例えば多くの特定コメントが収集できそうな場合にはより多くの情報を抽出し得るので、区分を細分化しても良い。例えば、「再開した」を「臨時ダイヤで再開した」と「通常ダイヤに戻った」などに分けても良い。逆に、コメント数が期待できないような場合には、区分を減らしても良い。

本実施形態においては、このようなクラスの分類を分類部１１２が行う。分類部１１２は、ＮＮ１２１へ特定コメントを入力し、出力としてすべてのクラス毎への分類確率を受け取る。分類確率の値が最も大きいクラスを当該特定コメントのクラスと判定する。ＮＮ１２１に、事前に正解クラスが紐づけられた大量のコメント例を教師データとして学習させたものを用いる。本実施形態におけるＮＮ１２１を具体的に説明する。

分類部１１２は、コメントを整数列に変換してＮＮ１２１へ入力する。図４は、コメントの整数列への変換を説明する図である。ここでは、コメントの例として「東急東横線が動き出したようです。」を説明する。

分類部１１２は、まず、入力コメントに対して形態素解析を行い、単語単位の分かち書きにする。そして、単語ごとに分解した後に、活用語を終止形に変換する。これにより、入力コメントは、「'東急','東横線','が','動く','出す','た','ようだ','。'」と分解される。なお、対象言語を英語とする場合には、スペース文字による単語の区切りをそのまま利用する。

ここで、ＮＮ１２１は、特定コメントを単語ごとに整数に変換して得られた整数列を入力して前記複数のクラスへの分類確率を出力する。具体的に、ＮＮ１２１は複数の層から構成される。ＮＮ１２１の第一層では、整数列から数値行列を求める。さらに詳しくは、ＮＮ１２１の第一層では、このように分解した入力コメントのそれぞれの単語を分散表現に変換する。各単語の分散表現は、d次元の行ベクトルとして表される。したがって、n単語に分解される一つの入力コメントは、n行d列の数値行列で表現される。

コメント発信者が発信するコメントは、１文であるとは限らない。また、１文がいくつの単語で構成されるかも不定である。また、ソーシャルメディアによっては、コメント可能な字数が制限されている場合もある。発信されたそれぞれのコメントについて、すべての単語を数値ベクトル化すれば、そのコメントが含む内容を最大限に利用できるが、数値行列化した場合に、コメントごとに行列のサイズが異なることになる。

本発明者らは、コメントの主要な内容は、当該コメント内で比較的早い段階において言及されるという知見を得た。また、本発明者らは、コメントが１４０文字以内に制限されるソーシャルメディアの場合、３０語の固定長化により８割以上の内容が収まるという知見を得た。そこで、本発明者らは、このような知見に基づいて任意のコメントに固定長化処理を施すことを想到した。

本実施形態においては、分類部１１２は、収集部１１１が収集した特定コメントを予め定められた単語数になるように固定長化処理を施す。具体的には、収集した特定コメントに対して分かち書き処理を施した結果、３０語を上回った場合には、上回った単語を棄却する。また、収集した特定コメントに対して分かち書き処理を施した結果、３０語を下回った場合には、不足分を０ベクトルで補う。このように処理することにより、いずれの特定コメントも、３０行d列の数値行列に変換することができる。特に、固定長化処理により、複数のコメントのバッチ並列処理が可能となり、一つずつ処理した場合に比べ１００倍以上の高速化が実現する。

なお、３０語を超えるコメントにおいても先頭から３０語以内で概ね趣旨を言及していることが多い。本発明者らは、コメントが１４０文字以内に制限されるソーシャルメディアの場合、３０語を超える部分を棄却することによる分類精度の低下は１％程度であることを確認した。

本実施形態においては、このように変換された特定コメントの数値行列を画像データに類似するデータに見立て、ＮＮ１２１の第二層に、画像処理において多用される畳み込み層を採用する。図５は、ＮＮ１２１の処理を説明する概念図である。

上述のように数値行列化された特定コメントに対し、畳み込み演算を実行することにより、コメント中の数単語のまとまり（ｎ−ｇｒａｍ）の特徴が抽出される。そして、プーリング処理が施され、コメントごとの特徴量が生成される。例えば、グローバル最大プーリングが実行される。その後、活性化関数にソフトマックス演算を持つ全結合層により、４つのクラスへの分類確率を計算する。４つのクラスは、それぞれクラスＡ、クラスＢ、クラスＣ、クラスＤに対応する。

なお、上記ＮＮ１２１では、畳み込み処理を行なう際に、単語分散表現の次元数dに応じた重みフィルターを用いる。具体的には、フィルターの幅をfとしてf行d列の数値行列により表現される重みフィルターが用いられる（図５参照）。このような重みフィルターを用いることで、ＮＮ１２１は、コメントに含まれる概念が反映された情報を学習することが可能となる。

例えば、コメントの中に「再開」という単語が含まれている場合、単なる形態素解析による分類では、「再開した（クラスＡ）」に分類するのか、「再開しそう（クラスＢ）」に分類するのかを決定することができない。これに対し、上記ＮＮ１２１では、特定の表現に反応する重みフィルターを学習しているので、「再開した（クラスＡ）」に分類するのか、「再開しそう（クラスＢ）」に分類するのかを適切に決定することができる。換言すると、上記ＮＮ１２１は、同一単語を含むコメントを異なるクラスに分類可能な学習モデルであり、概念に応じたクラス分類を可能としている。

また、上記ＮＮ１２１では、単語を数値ベクトル化するための処理で用いるパラメータの学習と、畳み込み処理から分類確率計算までに用いられるパラメータの学習とを一連のバックプロパゲーションで実行することができる。これにより、特定ジャンルのコメントの分類に特化した単語分散表現やｎ−ｇｒａｍの特徴を獲得するため、クラス分類の精度を高めることができる。なお、上記の畳み込み層及びプーリング層に替えて、多層ＬＳＴＭやＴｒａｎｓｆｏｒｍｅｒを用いても同様の効果を得ることが可能である。その他、ＮＮ１２１は、上述のものに限定されず、クラス分類できるものであれば任意のものを採用することができる。

本発明者らは、災害時に運休となった路線に対してソーシャルメディアへ発信された実際のコメントを収集し、手作業でその内容に応じた正解クラスをそれぞれのコメントに与えて教師データを作成し、これらを学習させることによってＮＮ１２１を作成した。そして、学習に利用していないコメントを使って、作成したＮＮ１２１の分類精度を検証した。図６は、クラス分類の検証結果を示す図である。

学習に利用していない検証用のコメント数は６４９個である。そのうち、作業者がクラスＡと判断する（すなわちクラスＡが正解である）コメント数は１４３個であり、ＮＮ１２１は、そのうち１２５個をクラスＡに分類されると判断した。同様に、作業者がクラスＢと判断するコメント数は２９２個であり、ＮＮ１２１は、そのうち２５８個をクラスＢに分類されると判断した。さらに、作業者がクラスＣと判断するコメント数は９２個であり、ＮＮ１２１は、そのうち７０個をクラスＣに分類されると判断した。そして、作業者がクラスＤと判断するコメント数は１２２個であり、ＮＮ１２１は、そのうち１０２個をクラスＤに分類されると判断した。すなわち、正しく分類できたコメント数は５５５個であり、ＮＮ１２１による分類の正解率は約８５％であった。この程度の正解率が達成できれば、ＮＮ１２１による分類は十分に実用に耐えるものと考えられる。

（３）判定部の処理
収集部１１１が一定時間の間に収集した特定コメントのそれぞれを、分類部１１２がクラスＡからクラスＤのいずれかに分類すると、全体のコメント数に対してそれぞれのクラスに属するコメント数の割合を計算することができる。判定部１１３は、各クラスの当該割合に着目することにより、現在または将来における対象イベントの進行状態の判定結果を算出する。なお、ここでは、分類部１１２は、一定期間毎に特定コメントを複数のクラスＡからクラスＤのいずれかに分類するものであり、例えば１分間毎に各コメントをいずれかのクラスに分類する。

現在または将来における対象イベントの進行状態を判定する場合には、時間の推移と共に想定される状態を定めたクラスＡ，クラスＢおよびクラスＣのそれぞれのコメント数の割合を演算の対象とすることが望ましい。すなわち、クラスＡ，クラスＢおよびクラスＣのそれぞれの割合を算出する場合に、進行状態とは無関係なコメントおよび判別不能なコメントが分類されるクラスＤのコメント数を除外して算出する。具体的には、収集されたクラスＡのコメント数がｎ_Ａ個、クラスＢのコメント数がｎ_Ｂ個、クラスＣのコメント数がｎ_Ｃ個、クラスＤのコメント数がｎ_Ｄ個である場合には、クラスＡの割合Ｔ_ＡをＴ_Ａ＝ｎ_Ａ／（ｎ_Ａ＋ｎ_Ｂ＋ｎ_Ｃ）、クラスＢの割合Ｔ_ＢをＴ_Ｂ＝ｎ_Ｂ／（ｎ_Ａ＋ｎ_Ｂ＋ｎ_Ｃ）、クラスＣの割合Ｔ_ＣをＴ_Ｃ＝ｎ_Ｃ／（ｎ_Ａ＋ｎ_Ｂ＋ｎ_Ｃ）のように計算し、クラスＤのコメント数を考慮しない。このように計算すれば、コメント数が急増した場合でも計算量を抑えることができる。また、各クラスの割合の変化がイベントの進行状態の推移をより反映すると期待できる。

第１実施例として、現在におけるイベントの進行状態を判定する手法について説明する。イベントの例は、引き続き「東横線の運行再開」であり、本実施例も実際に発生したイベントについて特定コメントを収集し、検証したものである。

図７Ａは、「東横線の運行再開」のイベントにおけるクラス割合と状態判定結果の時間推移を示すグラフである。横軸は時刻を表す。左縦軸は各クラスの割合（％）を表し、右縦軸は判定結果を０、１、２で表す。判定結果「０」は「止まっている」の予測を表し、「１」は「再開しそう」の予測を表し、「２」は「再開した」の予測を表す。点線で示すグラフは、クラスＡの割合の推移を表す。破線で表すグラフは、クラスＢの割合の推移を表す。なお、クラスＣの割合は、１００−（クラスＡの割合＋クラスＢの割合）であるので省略している。また、それぞれの割合の推移には、突発的な変化を軽減するノイズ除去フィルターを適用している。実線で示すグラフは、判定部１１３が判定した判定結果の推移を表す。

全体の傾向としては、クラスＣが大きな割合を占めている期間の「現在における進行状態」の判定結果は「止まっている」であり、クラスＢが大きな割合を占めている期間の「現在における進行状態」の判定結果は「再開しそう」であり、クラスＡが大きな割合を占めている期間の「現在における進行状態」の判定結果は「再開した」である。ただし、本実施例は、その時点において最大の割合を占めるクラスに対応する進行状態を「現在における進行状態」とするものに限定されるものではない。判定部１１３は、その時点における各割合に、直前に判定した進行状態を加味して、現在における前記イベントの前記進行状態を判定してもよい。このような処理により、時間の経過に対して、判定される進行状態が頻繁に遷移してしまうことを防ぐことができる。

具体的な演算について説明する。現在における進行状態を判定するために、判定部１１３は、状態推定演算を行う。状態推定演算は、進行状態を状態番号ｉ（ｉ＝０：止まっている、ｉ＝１：再開しそう、ｉ＝２：再開した）で表した場合に、総コストＣをｉ＝０、１、２に対して計算し、Ｃが最小となるｉを決定する演算である。総コストＣ_iは、

で表される。ここで、σ_iはフィッティングコストであり、τ_iは遷移コストである。フィッティングコストσ_iは、観測値（収集されたコメントの分類）と状態（イベントの進行状態）の当てはまりにくさの指標である。フィッティングコストは、観測値と状態が一致しているほど小さく、離れているほど大きい値になる。

具体的には、以下のように計算する。コメント分類番号ｊ（ｊ＝０：止まっている、ｊ＝１：再開しそう、ｊ＝２：再開した）、時刻ｔ、時刻ｔに収集された分類ｊのコメント数ｎ_t,j、時刻ｔに収集された全コメント数Ｓ_ｔ、励起状態における確率変動の割合を示す行列Ｑ（Ｑは励起状態数×励起状態数の行列で、Ｑ［０］[０]，Ｑ［０］[１]，Ｑ［１］[０]，Ｑ［１］[１]の要素を有する。各要素の値はハイパーパラメータである。）と定義すると、状態ｉに対するフィッティングコストσiは、

により計算される。ｌｏｇの括弧内は、多項分布の確率質量関数になっている。上述したようにコメントの割合によって計算する場合、フィッティングコストσ_iは分類jの割合（％）Ｔ_t,jを用いて、

となる。ここで、Γ（ｓ）はガンマ関数であり、

で表される。ｐ_i,jは、状態ｉにおけるコメント分類ｊの発生確率であり、行列で表すと、

となる。

まず、基底状態としてｉ＝０（止まっている）における確率を決定する。

次に、行列Ｑを用いて励起状態としてｉ＝１（再開しそう）、ｉ＝２（再開した）における確率を決定する。

各成分は確率なので、各ｉ（各行ごと）に対して、Σ_jｐ_i,j＝１、各ｉ，ｊ（各成分ごと）に対してｐ_i,j≧０が課せられる。そこで、これらの条件を満たすように修正を加える。具体的には、ｐ_i,j＜０であるｉ，ｊについてｐ_i,j＝０とし、Σ_jｐ_i,j＝ｐ_tmp＞１であるｉについてｐ_i,j＝ｐ_i,j／ｐ_tmpとする。

このような手法はバースト検知として知られているが、よく知られたバースト検知は励起状態が一つであり、行列Ｑの対角成分を２、非対角成分を１とするのが一般的である。しかし、本実施例における運行再開の進行状態においては、ｉ＝１（再開しそう）とｉ＝２（再開した）の観測値が共起しやすいと考えられるので、非対角成分を１より大きくしている。本実施形態においては、Ｑ［０］[０]＝２．０、Ｑ［０］[１]＝１．２、Ｑ［１］[０]＝１．２、Ｑ［１］[１]＝２．０と設定した。

遷移コストτ_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.に詳しい。

上記の演算による総コストＣ_iのうち最も小さい値を示す状態番号ｉの進行状態を、現在における進行状態の判定結果とする。図７Ａに示す例では、判定部１１３は、２０時５０分ころまでは「止まっている」と判定し、それから２２時１０分ころまでは「再開しそう」と判定し、それ以降は「再開した」と判定している。なお、この事象において鉄道会社が正式に運行再開をアナウンスした時刻は２２時３０分であった。実際にはそれ以前に運転が再開されたと考えられるので、本実施形態における判定プログラムの判定結果が実際の推移におよそ対応していると推測できる。このような検証結果から、本実施形態に係る状態判定システムの利用者は、運行再開に関する進行状態をある程度の正確性をもっていち早く知ることができると言える。

なお、現在における進行状態を判定するための演算手法は、上記のバースト検知手法に限らない。時間の経過に対して判定結果が頻繁に変化しないように、直前に判定した進行状態を加味する手法は、他にも種々採用し得る。演算を簡素化してプロセッサの負荷を軽減する場合には、例えば、各クラスの割合に予め用意した重み付け係数を乗じ、その中から大きな値を示すものを判定結果とすることもできる。この場合、ある状態から別の状態へ遷移する場合の重み付け係数は、遷移しやすいほど大きな値を設定しておく。

上述した判定部１１３の処理について補足する。判定部１１３は、所定の判定期間毎にイベントの進行状態を判定する。例えば、図７Ｂに示すように、判定期間は１分間とする。現在が時刻ｔであるとすると、現在のイベントの進行状態は、現在の時刻ｔに時間的に最も近い判定期間Ｄ１のコメントの分類結果に基づいて判定される。また、直前の判定期間Ｄ２は、現在の判定期間Ｄ１に時間的に逆方向に連続する判定期間である。

このような前提で、判定部１１３は、一定期間毎（１分間毎）に収集した各クラスのコメントの割合（数６のｐ_0,1 ,ｐ_0,2を参照）に基づいて、現在のイベントの進行状態を判定する判定期間Ｄ１において各クラスが取り得る発生確率（ｐ_i,j）を算出する。そして、判定部１１３は、算出した各クラスが取り得る発生確率（ｐ_i,j）と、判定期間Ｄ１に収集されたクラス毎のコメント数 （ｎ_t,j）とに基づいて、現在のフィッティングコストσiを算出する。

また、判定部１１３は、現在のイベントの進行状態を判定する判定期間Ｄ１より前の判定期間Ｄ２の間に判定したイベントの進行状態と、判定期間Ｄ１に取り得るイベントの進行状態との間の遷移行列γに基づいて、遷移コストτ_iを算出する。

そして、判定部１１３は、これらのフィッティングコストσi及び遷移コストτ_iから総コストＣ_iを算出し、現在におけるイベントの進行状態を判定する。なお、総コストＣ_iは、必ずしもフィッティングコストσi及び遷移コストτ_iの両方から算出される必要はなく、いずれか一方から算出されるものであってもよい。

図８は、図７Ａのイベントに対して利用者のスマートフォン２１０に表示される状態判定結果の表示例である。スマートフォン２１０のディスプレイ２１１には、主に、イベント表示２２１と状態判定表示２２２が表示される。イベント表示２２１は、対象イベントの情報が表示される。対象イベントは、利用者により選択されたイベントであり、例えば、その時点で状態判定が提供されるイベント一覧のメニューから選択される。対象イベントの情報としては、例えば、「東横線は事故のため１４：３０から運休しています」のように表示される。

状態判定表示２２２は、状態判定サーバ１００から送られてきた判定結果が表示される。ここで状態判定サーバ１００から送られてくるのは、現在における進行状態の判定結果であるので、例えば、「現在、東横線の状態は『再開しそう』です」のように表示される。このように、利用者は、自身のスマートフォン２１０で、対象イベントの現在における進行状態の判定結果を容易かつ簡潔に知ることができる。

次に、第２実施例として、将来におけるイベントの進行状態を判定する手法について説明する。イベントの例は、引き続き「東横線の運行再開」であり、一つ目の実施例と同じものである。

図９は、クラスＡの割合の時間推移と再開判定時刻を示すグラフである。横軸は時刻を表す。縦軸はクラスＡの割合（％）を表わす。点線で示すグラフは、クラスＡの割合の推移を表すが、本実施例では状態判定サーバ１００が２２時ちょうどに利用者からのリクエストを受け取った場合を想定するので、２２時００分までの推移を示す。なお、クラスＡの割合の推移には、突発的な変化を軽減するノイズ除去フィルターを適用している。実線で示すグラフは、２２時００分までのクラスＡの割合の推移に対して当てはめたフィッティング関数を表す。

フィッティング関数は、ここでは０から１００の間で変化するように規格化したシグモイド型関数を利用する。図示するようにシグモイド型関数を当てはめることにより、クラスＡの割合が２２時００分以降にどうのように変化するかを推定する。

クラスＡの割合は「再開した」の割合なので、この割合が一定値を超えると列車の運行が実際に再開されていると考えることができる。そこで、本実施例では、その閾値Ｓａを８０％と定め、当てはめたフィッティング関数が８０％を超える時刻を、運行の再開予測時刻とする。図の例ではフィッティング関数が８０％を超える時刻は２２時２８分である。したがって、判定部１１３は、将来におけるイベントの進行状態である「再開予測時刻」を、２２時２８分であると判定する。上述のように、この事象において鉄道会社が正式に運行再開をアナウンスした時刻は２２時３０分であったので、良好な判定結果であると評価できる。なお、本実施例ではフィッティング関数としてシグモイド型関数を採用したが、事象に合わせて他の関数をフィッティング関数として採用しても良い。

図１０は、図９のイベントに対して利用者のスマートフォン２１０に表示される再開予測時刻の表示例である。スマートフォン２１０のディスプレイ２１１には、主に、イベント表示２２１と状態判定表示２２２が表示される。イベント表示２２１は、図８の例と同様である。

状態判定表示２２２は、状態判定サーバ１００から送られてきた判定結果が表示される。ここで状態判定サーバ１００から送られてくるのは、将来における進行状態の判定結果であるので、例えば、「東横線の再開予測時刻は『２２：２８』です」のように表示される。このように、利用者は、自身のスマートフォン２１０で、対象イベントの将来における進行状態の判定結果を容易かつ簡潔に知ることができる。

（４）状態判定処理
次に、本実施形態における状態判定サーバ１００の処理手順について説明する。状態判定サーバ１００による状態判定処理は、状態判定プログラムがコンピュータであるプロセッサに各ステップを実行させることにより実現される。図１１は、状態判定プログラムの処理手順を示すフロー図である。

図示するフローは、システム管理者が対象イベントを定めてサービスの提供を開始した時点から始まる。収集部１１１は、ステップＳ１０１で、ソーシャルメディアに対して発信されたコメントのうち、対象イベントに関する特定コメントを、メディアサーバ９２０のコメント蓄積部９２１から収集する。ステップＳ１０２へ進むと、分類部１１２は、記憶部１２０から読み出したＮＮ１２１を用いて、ステップＳ１０１で収集された特定コメントを、イベントの進行状態に応じて定められた複数のクラスのいずれかに分類する。

イベントごとに設定される単位時間が経過したら、判定部１１３は、ステップＳ１０３で、その間に収集され分類された特定コメントにおけるクラスごとの割合に基づいて、現在または将来における対象イベントの進行状態を判定する。このとき、判定に用いるクラスを特に着目する特定クラスと定め、特定クラスに分類された特定コメントの割合に基づいて進行状態を判定すると良い。上述の第１実施例では、除外クラスとしたクラスＤ以外のクラスＡ、クラスＢおよびクラスＣが特定クラスであり、第２実施例では、フィッティング関数を当てはめたクラスＡが特定クラスである。クラスの設定の仕方によっては、全てのクラスを特定クラスとしても良い。

ステップＳ１０４へ進み、処理部１１０は、利用者のスマートフォン２１０（ここでは「リクエスト端末」とする）から、状態判定のリクエストを受け取ったか否かを確認する。受け取っていたらステップＳ１０５へ、受け取っていなければステップＳ１０５をスキップしてステップＳ１０６へ進む。ステップＳ１０５へ進んだ場合には、ステップＳ１０３で判定した判定結果をリクエスト端末へ出力し、ステップＳ１０６へ進む。

ステップＳ１０６へ進むと、処理部１１０は、イベント処理が終期に達したか否かを判断する。例えば、対象イベントが列車の運行再開であれば、実際に列車の運行が再開された情報を取得してから所定時間の経過後を終期とする。終期は、対象イベントごとに、状態判定のリクエストが途絶えると判定される時期に設定すると良い。処理部１１０は、イベント処理が終期に達していないと判断した場合には、ステップＳ１０１へ戻り、終期に達したと判断した場合には、一連の処理を終了させる。

なお、上述の説明では、状態判定サーバ１００が単一の装置で動作される例を用いて説明したが、状態判定サーバ１００の構成は、発明の要旨を逸脱しない範囲で、適宜構成の追加又は変更が可能なものである。例えば、図１２に示すように、状態判定サーバ１００がリクエスト端末から直接リクエストを受け付けるのではなく、別途設置したリクエスト処理装置８００がリクエスト端末２１０からリクエストを受け付ける構成であってもよい。この場合、状態判定サーバ１００は、ステップＳ１０３で進行状態の判定をする度に、所定の記憶装置８５０に進行状態の判定結果を書き込む。リクエスト処理装置８００は、リクエスト端末２１０からのリクエストを受け取った場合に、上記記憶装置８５０から最新の判定結果を取り出して、リクエスト端末２１０に出力する。

以上、公共交通機関の非常停止後の運行再開事象を対象イベントとして本実施形態を説明したが、分析対象とするイベントはこれに限らない。例えば、特定名所の桜の開花事象を対象イベントとすることもできる。この場合、進行状態として、例えば「つぼみ」「三分咲き」「五分咲き」「満開近い」「満開」「散り始め」「葉桜」の７クラスを設定し得る。また、「千鳥ヶ淵の桜、もうすぐ満開だね」のようなコメントが特定コメントとして収集される。

１００ 状態判定サーバ、１１０ 処理部、１１１ 収集部、１１２ 分類部、１１３ 判定部、１２０ 記憶部、１２１ ＮＮ、１３０ 通信部、１４０ 入力部、２１０ スマートフォン、２１１ ディスプレイ、２２１ イベント表示、２２２ 状態判定表示、９００ インターネット、９１０ スマートフォン、９２０ メディアサーバ、９２１ コメント蓄積部

Claims (17)

1. ソーシャルメディアに対して発信されたコメントを、イベントの進行状態に応じて定められた複数のクラスのいずれかに分類する分類部と、
   前記複数のクラスのうち着目する特定クラスに分類された特定コメントの割合に基づいて、現在または将来における前記イベントの前記進行状態を判定する判定部と
   を備える状態判定システム。
2. 前記分類部は、前記特定コメントを単語ごとに整数に変換して得られた整数列を入力して前記複数のクラスへの分類確率を出力する学習モデルを用いて前記特定コメントを分類する、
   請求項１に記載の状態判定システム。
3. 前記学習モデルは、
   前記整数列から数値行列を求める第１演算部と、
   前記数値行列の入力に応じて前記複数のクラス分類確率を出力する第２演算部と、
   を備える、請求項２に記載の状態判定システム。
4. 前記第１演算部は、前記整数列から分散表現を求め、
   前記第２演算部は、前記分散表現の入力に応じて前記複数のクラス分類確率を出力する、
   請求項３に記載の状態判定システム。
5. 前記分類部は、前記特定コメントを予め定められた単語数となるように固定長化処理を施して前記学習モデルへ入力する請求項２から４のいずれか１項に記載の状態判定システム。
6. 前記学習モデルは、畳み込み演算を実行する、
   請求項２から５のいずれか１項に記載の状態判定システム。
7. 前記コメントは、３００文字以内の文字数で構成されるものである、
   請求項１から６のいずれか１項に記載の状態判定システム。
8. 前記分類部は、同一単語を含むコメントを異なるクラスに分類可能な学習モデルを用いて前記コメントを分類する、
   請求項１から７のいずれか１項に記載の状態判定システム。
9. 前記判定部は、前記割合を算出する場合に、前記複数のクラスのうち前記進行状態とは無関係な前記特定コメントおよび判別不能な前記特定コメントが分類される除外クラスのコメント数を除外して算出する請求項１から８のいずれか１項に記載の状態判定システム。
10. 前記判定部は、直前に判定した進行状態を加味して現在における前記イベントの前記進行状態を判定する請求項１から９のいずれか１項に記載の状態判定システム。
11. 前記分類部は、一定期間毎に前記コメントを複数のクラスのいずれかに分類するものであり、
    前記判定部は、
    前記一定期間毎に収集した各クラスのコメントの割合に基づいて、現在のイベントの進行状態を判定する判定期間において各クラスが取り得る発生確率を算出し、
    算出した各クラスが取り得る発生確率と、前記判定期間に収集されたクラス毎のコメント数とに基づいて、現在におけるイベントの進行状態を判定する、
    請求項１から１０のいずれか１項に記載の状態判定システム。
12. 前記分類部は、一定期間毎に前記コメントを複数のクラスのいずれかに分類するものであり、
    前記判定部は、現在のイベントの進行状態を判定する判定期間より前の一定期間の間に判定したイベントの進行状態と、前記判定期間に取り得るイベントの進行状態との間の遷移行列に基づいて、現在におけるイベントの進行状態を判定する、
    請求項１から１１のいずれか１項に記載の状態判定システム。
13. 前記判定部は、前記割合の推移にフィッティング関数を当てはめ、前記フィッティング関数が予め設定された閾値を超える時刻に基づいて将来における前記イベントの前記進行状態を判定する請求項１から９のいずれか１項に記載の状態判定システム。
14. 前記ソーシャルメディアに対して発信されたコメントのうち、分析対象のイベントに関する特定コメントを収集する収集部、
    をさらに備える、請求項１から１３のいずれか１項に記載の状態判定システム。
15. 前記イベントは、公共交通機関の異常停止後の運行再開事象であり、
    前記判定部は、前記進行状態として前記公共交通機関の運行が再開間近である状態、および再開した状態の少なくともいずれかの判定結果を出力する請求項１から１４のいずれか１項に記載の状態判定システム。
16. ソーシャルメディアに対して発信されたコメントを、イベントの進行状態に応じて定められた複数のクラスのいずれかに分類する分類ステップと、
    前記複数のクラスのうち着目する特定クラスに分類された特定コメントの割合に基づいて、現在または将来における前記イベントの前記進行状態を判定する判定ステップと
    をコンピュータが実行する状態判定方法。
17. ソーシャルメディアに対して発信されたコメントを、イベントの進行状態に応じて定められた複数のクラスのいずれかに分類する分類ステップと、
    前記複数のクラスのうち着目する特定クラスに分類された特定コメントの割合に基づいて、現在または将来における前記イベントの前記進行状態を判定する判定ステップと
    をコンピュータに実行させる状態判定プログラム。

Images