JP5974663B2 - 分析装置、分析方法及び分析プログラム - Google Patents

Description

本発明は、ソーシャルメディアに記録された文書としてのつぶやきを分析するための技術に関し、特に、ソーシャルメディア内で話題となっているトピックの注目度を測るための分析装置、分析方法及び分析プログラムに関する。

近年、マイクロブログ、ＳＮＳ（Social Networking Service：ソーシャルネットワーキングサービス）、ブログ、掲示板等のソーシャルメディアを用いたサービスが急速に普及している。例えば、マイクロブログの一つであるＴｗｉｔｔｅｒ（登録商標）は、ユーザがつぶやきとして入力した文字列等を、インターネット等の通信ネットワークを介して送受信し、公衆に閲覧可能に記憶するものである。また、所定のユーザのつぶやきを閲覧したり（フォロー）、あるユーザのつぶやきに対して他のユーザがそれを引用して自らのつぶやきとしたり（リツイート）、所定のユーザのつぶやきに自らのコメントを追加して投稿したり（クオートツイート）することができる。

ソーシャルメディアが持つ自由な意見発信と即時性という特徴により、ソーシャルメディアを一種の人間センサーとして用い、「今、社会で起きていることを知る」ための様々なソーシャルメディア分析サービスが提供されている。例えば、世の中で注目されている話題を知るために、つぶやき中に記載されたＵＲＬ（Uniform Resource Locator：統一資源位置指定子）に着目し、その数を集計しランキングする分析方法がある。

しかし、同一のＵＲＬが必ずしもいつも同一の内容（トピック）を指しているとは限らない。例えば、記載されているＵＲＬがニュースのトップ記事のＵＲＬであれば、時刻によって指している内容が書き換わることがある。そのため、抽出をしたＵＲＬを集計してもソーシャルメディア内で話題となっていることを抽出できることにはならない。

図１は、同一ＵＲＬが指し示すトピックの内容が変遷する例を示す図である。
図１に示すように、時刻９：００と時刻１１：００につぶやかれた２つの「つぶやき」は、同じＵＲＬ（ｈｔｔｐ：／／ａ．ｃｏｍ／）を含んでいる。しかしながら、時刻９：００のつぶやき「超嬉しい ｈｔｔｐ：／／ａ．ｃｏｍ／」時のトピックは、「アイドルグループＡをＣＭに起用」である。これに対して、時刻１１：００のつぶやき「許せない ｈｔｔｐ：／／ａ．ｃｏｍ／」時のトピックは、「社長スキャンダル」である。すなわち、これらのつぶやきには同一のＵＲＬが含まれているが、そのトピックは、全く異なっている。これは、時間の経過に伴い、ＵＲＬが指し示すコンテンツが書き換えられたからである。

そのため、つぶやきから抽出したＵＲＬの分析を行うのではなく、つぶやき分析時にＵＲＬに一度アクセスし、ＵＲＬが参照しているトピックそのものを取得して、トピックを集計するという方法が考えられる。マイクロブログでは、ユーザは見たり聞いたりしたことをすぐにつぶやく傾向にあるため、つぶやかれてすぐにつぶやき内のＵＲＬが指し示しているトピックを取得すれば、ユーザが参照したトピックを取得できると考えられる。

しかし、つぶやき時刻と分析処理時刻のずれにより、つぶやかれてすぐにトピックを取得できなかった場合は、トピック側はすでに更新されて違うものになってしまい、ユーザが参照したトピックを正しく取得できない可能性がある。

図２は、つぶやきと、つぶやきが参照するトピックの組み合わせを正しく取得できない例を示す図である。

図２に示すように、例えば、時刻９：００に分析処理を行い、つぶやきが参照するトピックを取得した後、次は時刻１１：００に分析処理（トピック取得）をしたとする。もし、その間の１０：００にもつぶやきが存在していた場合、１０：００の時点では分析処理が行われなかったため、つぶやきが参照するトピックは取得されない。しかし、過去に戻ってトピックを取得することはできないので、このような場合、１０：００のつぶやき「ＣＤプレゼントだって ｈｔｔｐ：／／ａ．ｃｏｍ／」はトピック取得失敗、つぶやきとトピックの組み合わせなし、となってしまう。

このような状況は、例えば、過去のつぶやきデータを後から入手した場合などにも発生する。

しかし、ソーシャルメディア上での話題の流行は寿命が短いと言う特徴があり、つぶやき側の分析とは別に、あらゆるＵＲＬについて、トピックの変化を常に監視し続け、どの時刻にどのトピックであったかを管理し続ける方法は現実的ではない。

そこで、つぶやきとそれに対応するトピックを組み合わせで取得することに失敗した場合に、できるだけ、足りないトピックを推定して補う方法が考えられる。これまでの分析処理で取得した手持ちのトピックデータの中に、対象となるつぶやきが参照していたトピックがないか、推定する。例えば、図２の場合は、つぶやき「ＣＤプレゼントだって ｈｔｔｐ：／／ａ．ｃｏｍ／」に含まれるＵＲＬ（ｈｔｔｐ：／／ａ．ｃｏｍ／）が指していた他のトピックとして、「アイドルグループＡをＣＭに起用」もしくは「社長スキャンダル」がある。つぶやき「ＣＤプレゼントだって」がこのどちらかのトピックと関係があるか推定を行い、関係が高いと推定されたトピックを、つぶやきが参照していたトピックだと推定する。

つぶやきとトピックの間の関係性を推定する方法として、例えば、文書間の文字列、すなわちこの場合はつぶやき文字列とトピックの文字列の類似度を計算する技術が開示されている（例えば、非特許文献１、２参照。）。

また、機械学習法（例えば、非特許文献３、４参照。）を用いて、文書間の関係性を推定する方法も開示されている。この方法は、つぶやきとトピックの間に関係がある事例（正例）、関係がない事例（負例）を事前に学習して、関係ありかなしかの推定規則を自動で生成し、その規則を用いて、新しいつぶやきとトピックの間の関係ありかなしかを推定する方法である。

例えば、事前に「ＣＤプレゼントだって ｈｔｔｐ：／／ｂ．ｃｏｍ／」というつぶやきと「アイドルグループＢをＣＭに起用」というトピックが対応付けられているという事例を学習していたとする。このような場合、「ＣＤプレゼントだって ｈｔｔｐ：／／ａ．ｃｏｍ／」というつぶやきと「アイドルグループＡをＣＭに起用」というトピックとの組合せは、学習していた組合せと類似しているので、例えば、確信度９０で関係があると判定される。

Salton、 G.、 "The Vector Space Model、 Automatic Text Processing." Addison Wesley Publishing、 1985、 pp.312-325 北研二、津田和彦、獅子掘正幹 著、「情報検索アルゴリズム」、共立出版、2002、4.2 ベクトル空間モデル pp.60-63 Quinlan、 J. R. C4.5: "Programs for Machine Learning." Morgan Kaufmann Publishers、 1993 pp.15-33 奥村学監修、高村大也著、「言語処理のための機械学習入門」、コロナ社、2010 pp.101-117

しかしながら、文字列同士の類似度を計算する方法をつぶやきとトピックの対応関係の推定に適用しても、実はつぶやき文字列とトピックの文字列には類似性があるとは限らないため、対応付けが難しいという問題がある。マイクロブログでは特に、つぶやきの文字数は１４０文字まで、といった制限があるため、つぶやき中にトピックの内容は記載されないことが多い。例えば、図２のつぶやき「超嬉しい ｈｔｔｐ：／／ａ．ｃｏｍ／」の例では、トピック「アイドルグループＡをＣＭに起用」という内容を記述するのを省略するためにトピックのＵＲＬを引用しているのであり、つぶやき文字列とトピック文字列の間には類似性が見られない。

他方、機械学習法による関係有無の推定では、つぶやきとトピックの間で文字列に必ずしも類似性がなくても推定が行えるが、推定の結果、確信度が高い場合に限られる。確信度が低い場合は対応付けができなかった。

本発明は、上述のような実状に鑑みたものであり、ソーシャルメディア内のＵＲＬに着目して、世の中で注目されている話題を発見するにあたり、つぶやき内に記載されたＵＲＬが指しているトピックが常時固定ではなく時刻に応じて変化することにより、つぶやきとそれが参照しているトピックの対応関係が明確でない場合でも、つぶやきとトピックの対応関係を推定することが可能な分析装置、分析方法及び分析プログラムを提供することを目的とする。

本発明は、上記課題を解決するため、下記のような構成を採用した。
１つの案では、分析装置が、リンク先を示す情報を含むコンテンツが登録をされた日時と、該リンク先を示す情報と、該リンク先の内容を示す情報と、該リンク先の内容を示す情報の確からしさを示す情報と、を関連付けて記録をしたデータベースを格納する記憶部と、前記データベースを参照して、前記リンク先を示す情報が同一のデータについてコンテンツが登録をされた日時の時系列で並べた場合に、リンク先の内容を示す情報が同一で、且つ、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えるデータに挟まれた、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えないデータについて、リンク先の内容を示す情報を、該データを挟む、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えるデータのリンク先の内容を示す情報に変更をする変更部とを有することを特徴とする。

本発明によれば、１つのつぶやきと、そこに記載されたＵＲＬが示す１つのトピックを対応づけるにあたり、対応関係の有無を推定する必要がある際に、従来手法のように、つぶやきとトピックの１対１で個別に推定を行って、推定結果の確信度が低く対応付けが行えない場合であっても、他のつぶやきとトピックの対応関係も含めて、時刻情報の前後関係および推定の確信度を用いることにより、対応関係の有無を推定することができる、という効果を奏する。

これにより、ソーシャルメディア分析において、つぶやきに記載されたＵＲＬが同一でも異なるトピックを指すことがある場合においても、世間で多くの人に注目されているトピックを精度よく抽出できる、という効果を奏する。

同一ＵＲＬが指し示すトピックの内容が変遷する例を示す図である。 つぶやきと、つぶやきが参照するトピックの組み合わせを正しく取得できない例を示す図である。 本実施の形態の概略を説明するための図（その１）である。 本実施の形態の概略を説明するための図（その２）である。 トピックの推定結果の変更のパターンを説明するための図である。 変更履歴を用いた再変更を説明するための図である。 分析装置が実行するソーシャルメディア分析処理の流れを示すフローチャートである。 図７のステップＳ７０１で実行される「つぶやき取得処理」の流れを示すフローチャートである。 つぶやきＤＢの例を示す図である。 推定・変更に用いるデータの蓄積を説明するための図である。 図７のステップＳ７０２で実行される「つぶやき分析処理」の流れを示すフローチャートである。 トピックＤＢの例を示す図である。 つぶやき−トピックＩＤ対応ＤＢの例を示す図である。 分析装置が実行する「対応推定処理」の流れを示すフローチャート（その１）である。 分析装置が実行する「対応推定処理」の流れを示すフローチャート（その２）である。 単体の推定では十分な確信度がなかったものが、変更によって解決する例を説明するための図（その１）である。 単体の推定では十分な確信度がなかったものが、変更によって解決する例を説明するための図（その２）である。 単体の推定では十分な確信度がなかったものが、変更によって解決する例を説明するための図（その３）である。 単体の推定では十分な確信度がなかったものが、変更によって解決する例を説明するための図（その４）である。 単体の推定では十分な確信度がなかったものが、変更によって解決する例を説明するための図（その５）である。 変更の変更が起こる例を説明するための図（その１）である。 変更の変更が起こる例を説明するための図（その２）である。 変更の変更が起こる例を説明するための図（その３）である。 変更の変更が起こる例を説明するための図（その４）である。 変更の変更が起こる例を説明するための図（その５）である。 変更の変更が起こる例を説明するための図（その６）である。 変更の変更が起こる例を説明するための図（その７）である。 変更の変更が起こる例を説明するための図（その８）である。 変更の変更が起こる例を説明するための図（その９）である。 本実施の形態を実行する分析装置の構成図（その１）である。 蓄積した事例を学習データに利用する例を説明するための図である。 本実施の形態を実行する分析装置の構成図（その２）である。 変形例を説明するための図である。

以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
本実施の形態を実現する分析装置では、ソーシャルメディアにおける下記の３つのポイントとなる性質を利用する。

第１のポイントは、つぶやき及びトピックが両方とも時刻情報を有していることである。つぶやきは、投稿された時刻情報を有し、トピックは、ある時刻にあるＵＲＬにアクセスしたらこのトピックであったというトピック取得時刻情報を有する。

第２のポイントは、時刻の経過に対して、トピックの変化は一般的に不可逆であることである。次々に新しいトピックに更新されて変わっていき、元のトピックには戻らない。そして、更新と更新の間はいつアクセスしても同じトピックである。例えば、ＷＷＷ上のあるＵＲＬの内容が、時刻９：００の時点で「アイドルグループＡをＣＭに起用」であったとすると、時刻１１：００の時点で「社長スキャンダル」に更新されるまでの間、そのＵＲＬの内容は、「アイドルグループＡをＣＭに起用」の状態である。すなわち、あるＵＲＬに記載されている内容は、ある時点にある状態であり、その後のある時点で同じ状態であれば、その期間は同じ内容であったと推定できる。

第３のポイントは、上述した通り、特にマイクロブログに顕著なように、ユーザは見たり聞いたりしたものをすぐにつぶやきとして投稿する傾向にあるという点である。ＵＲＬが記載されたつぶやきは、ユーザがあるトピックを閲覧後、さほど時間をおかずに該当トピックのＵＲＬを記載して投稿している可能性が高い。

これら３つのポイントを利用することで、時刻の前後関係を使って、対応トピックを推定することができる。単体のつぶやきとトピックの対応付けでは十分な確信が持てない場合でも、前後のつぶやきとトピックの並びから、トピックを推定する。

次に、本実施の形態の概略を説明する。 まず、トピックとは、本実施の形態を実現する分析装置が、つぶやき分析時に、つぶやきに記載されたＵＲＬにアクセスして取得する、ある時刻のコンテンツのスナップショット、例えば、最も簡単には、ＨＴＭＬファイルをダウンロードしてきたものであるとする。

トピックは、別の時刻に収集しても、内容に変更がなければ、同じトピックであることを特定するために同じトピックＩＤを付与して、同じトピックとして扱う。変更の有無を調べる方法としては、例えば、最も簡単には、取得したファイルに差異がないかどうかを見る。

また、つぶやき時刻の後、一定時間（例えば５分と設定）内にトピックを取得できた場合は、つぶやきが参照しているトピックを正しく取得できたものとし、つぶやきとトピックの対応付け「確定」とする。確定できなかったつぶやきがあった場合に、対応するトピックの推定を行うとする。

図３は、本実施の形態の概略を説明するための図（その１）である。
図３では、分析装置が、対応づけられたつぶやきとトピックの組み合わせをつぶやき時刻の時系列順に並べ、その前後関係を用いてトピックを推定する。

図３の（Ａ）に示すように、トピックが取得できなかったつぶやき「早く見たい！ ｈｔｔｐ：／／ａ．ｃｏｍ／」というつぶやきがあり、手持ちのトピックから対応するトピックを推定する。今、推定対象のトピックとして、「アイドルグループＡをＣＭに起用」のトピックがある。機械学習等の従来手法によって、このつぶやきとトピックの間に関係あり、と単体で推定しようとしたが、推定の結果、確信度が低い場合は、推定が正しい可能性が低く、推定結果を採用できない。

そこで、本実施の形態では、このつぶやきに記載されたＵＲＬ「ｈｔｔｐ：／／ａ．ｃｏｍ／」を含む他のつぶやきとトピックの組み合わせを、つぶやき時刻の時系列順に並べる。そうすると、図３の（Ｂ）に示すように、つぶやき「早く見たい！ ｈｔｔｐ：／／ａ．ｃｏｍ／」が、つぶやき「超嬉しい ｈｔｔｐ：／／ａ．ｃｏｍ／」と「ＣＤプレゼントだって ｈｔｔｐ：／／ａ．ｃｏｍ／」に挟まれる形となる。そして、「超嬉しい ｈｔｔｐ：／／ａ．ｃｏｍ／」と「ＣＤプレゼントだって ｈｔｔｐ：／／ａ．ｃｏｍ／」のトピックは、両方とも「アイドルグループＡをＣＭに起用」で確定である。このような場合には、同一のトピックにはさまれている間のトピックは同一、すなわちつぶやき「早く見たい！ ｈｔｔｐ：／／ａ．ｃｏｍ／」が示しているトピックは、「アイドルグループＡをＣＭに起用」であると判断する。

図４は、本実施の形態の概略を説明するための図（その２）である。
図４では、分析装置が、時刻の前後関係を用いるのに加えて、確信度スコアの大小を用いてトピックを推定する。

図４の（Ａ）に示すように、つぶやき時刻９：００のつぶやき「超嬉しい ｈｔｔｐ：／／ａ．ｃｏｍ／」は、つぶやかれてすぐに分析及びトピック取得が実行され、つぶやきに対応するトピックとして「アイドルグループＡをＣＭに起用」が確定している。確定の場合、確信度１００として扱う。同様に、つぶやき時刻１１：００のつぶやき「許せない ｈｔｔｐ：／／ａ．ｃｏｍ／」も、つぶやきに対応するトピック「社長スキャンダル」が確定（確信度１００）している。

そして、上記両つぶやき時刻に挟まれたつぶやき時刻９：３０には、つぶやき「また？ ｈｔｔｐ：／／ａ．ｃｏｍ／」があったとする。このつぶやき「また？ ｈｔｔｐ：／／ａ．ｃｏｍ／」は、対応するトピックが取得できなかったので、対応トピックの推定を行う。時刻の前後関係から、前のトピックである「アイドルグループＡをＣＭに起用」か、又は後のトピックである「社長スキャンダル」のどちらかの可能性がある。そこで、機械学習等を用いてトピックの推定を行う。ここでは、機械学習の推定で確信度５０で「社長スキャンダル」と推定された。

更に、図４の（Ｂ）に示すように、つぶやき「また？ ｈｔｔｐ：／／ａ．ｃｏｍ／」と「許せない ｈｔｔｐ：／／ａ．ｃｏｍ／」の間の時刻１０：３０に、もう１つのつぶやき「アイドルグループＡ大好き ｈｔｔｐ：／／ａ．ｃｏｍ／」があったとする。このつぶやき「アイドルグループＡ大好き ｈｔｔｐ：／／ａ．ｃｏｍ／」にも、対応するトピックがないので、対応トピックの推定を行う。トピック「アイドルグループＡをＣＭに起用」か、又は「社長スキャンダル」のどちらかの可能性がある。そこで、機械学習等を用いてトピックの推定を行う。ここでは、確信度９５で「アイドルグループＡをＣＭに起用」が推定されている。

ここで、上記４つのつぶやきとトピック全体の時系列の流れを見直してみると、上記第２のポイントとして説明したように、トピックは不可逆であるため、一度「アイドルグループＡをＣＭに起用」から「社長スキャンダル」になったトピックが、その後に再度「アイドルグループＡをＣＭに起用」には戻らないはずである。したがって、上記２つの推定の何れかが間違っていることになる。

それぞれの推定の確信度を見て、確信度の高い方を信用すると、つぶやき「アイドルグループＡ大好き ｈｔｔｐ：／／ａ．ｃｏｍ／」とトピック「アイドルグループＡをＣＭに起用」の対応付けは確信度９５、つぶやき「また？ ｈｔｔｐ：／／ａ．ｃｏｍ／」とトピック「社長スキャンダル」の対応付けは確信度５０であるので、後者が間違っていると推定できる。したがって、トピック「アイドルグループＡをＣＭに起用」とトピック「アイドルグループＡをＣＭに起用」の間の時間帯にある、つぶやき「また？ ｈｔｔｐ：／／ａ．ｃｏｍ／」の対応先のトピックは、「アイドルグループＡをＣＭに起用」であった、すなわち、つぶやき「超嬉しい ｈｔｔｐ：／／ａ．ｃｏｍ／」からつぶやき「アイドルグループＡ大好き ｈｔｔｐ：／／ａ．ｃｏｍ／」までの間の時間帯では、トピックに更新がなかったと推定される。

このように、本実施の形態では、つぶやきとトピックの対応付けを単体で推定するのに加えて、つぶやきとトピックの対応付けを時系列で並べた後、確信度の高い対応付けを信用して、確信度の低い対応付けを変更する。

次に、上記変更のパターンについて説明する。
図５は、トピックの推定結果の変更のパターンを説明するための図である。

図５の（Ａ）に示したパターン１は、最新の推定結果により、それまでの推定結果が変更される例である。

まず、時系列順に並べて、最初と最後に確定の組み合わせがあり、最初のトピックはトピックＩＤが「１」のトピック、最後のトピックはトピックＩＤが「２」のトピックである。上から２番目のトピックは、つぶやきに対しトピックが取得できなかったものであり、分析装置により推定が行われ、トピックＩＤ「２」のトピックであるとされた。その確信度は５０である。この時点では、３つのトピックを時系列順に見ると、「１→２→２」であるので、矛盾はないため変更は行われていない。

続いて、図５（Ａ）中の左端に矢印で示している、上から３番目のつぶやきが新たに入ってきて、これもつぶやきに対しトピックが取得できなかったものであるため、分析装置が、対応するトピックを推定する。その結果、確信度９５でトピックＩＤ「１」のトピックと推定された。

この時点で、４つのトピックを時系列順にみると、「１→２→１→２」となっており、トピックの変化に矛盾が生じているため、２つの推定のどちらかが間違っていると考えられる。２つの推定の確信度を比較すると、確信度５０と確信度９５であるから、確信度９５の方が正しい可能性が高い。そこで、確信度５０の以前の推定は、最初の確定のトピックＩＤ「１」と確信度９５の最新の推定のトピックＩＤ「１」に挟まれる形で、トピックＩＤ「１」へと変更される。

図５の（Ｂ）に示したパターン２は、最新の推定結果が、それまでの推定結果をもとに変更される例である。

まず、最初と最後に確定の組み合わせがあり、最初のトピックはトピックＩＤ「１」のトピック、最後のトピックはトピックＩＤ「２」のトピックである。上から３番目のトピックは、つぶやきに対しトピックが取得できなかったものであり、分析装置により推定が行われ、トピックＩＤ「１」であるとされた。その確信度は９５である。この時点では、３つのトピックを時系列順に見ると、「１→１→２」であるので、矛盾はないため変更は行われていない。

続いて、図５（Ｂ）中の左端に矢印で示している、上から２番目のつぶやきが新たに入ってきて、これもつぶやきに対しトピックが取得できなかったものであるため、分析装置が、対応するトピックを推定する。その結果、確信度５０でトピックＩＤ「２」と推定された。

この時点で、４つのトピックを時系列順にみると、「１→２→１→２」となっており、トピックの変化に矛盾が生じているため、２つの推定のどちらかが間違っていると考えられる。２つの推定の確信度を比較すると、確信度５０と確信度９５であるから、確信度９５の方が正しい可能性が高い。そこで、最新の推定である確信度５０の方の推定は、最初の確定のトピックＩＤ「１」と確信度９５の以前の推定のトピックＩＤ「１」に挟まれる形で、トピックＩＤ「１」へと変更される。

このように、確信度の高いつぶやきが確信度の低いつぶやきのトピックを変更するのであり、つねに新しい推定が過去の推定を変更するとは限らない。

さらに、本実施の形態は、分析装置による推定結果の変更が発生した際、どのつぶやきとトピックの組み合わせによって対応するトピックが変更されたのかを記録しておき、それをもとに、分析装置が、さらなる変更を行うか確認する。

上述のようにしてトピックの変更を行った後、その変更の根拠となっていたつぶやきとトピックの組み合わせ自体が、後に別のつぶやきとトピックの組み合わせにより変更されてしまった場合、当初の変更は根拠が失われて、信頼できなくなる。そのため、変更が発生した場合、分析装置は、自身がどのつぶやきを根拠に変更されたのか、履歴をとっておく。同時に、他の履歴をたどり、過去に自身が根拠となって変更が発生したものを抽出して、分析装置が過去の変更の取り消しを行う。

図６は、変更履歴を用いた再変更を説明するための図である。
図６において、まず、図６中の（Ａ）の左端に矢印で示すように、つぶやき４が新たに入ってきたことにより、以前に分析装置により推定された確信度の低い（確信度５０）つぶやき２のトピックが、つぶやき３とつぶやき４に挟まれて、トピックＩＤ「１」からトピックＩＤ「２」へ変更される。この際、分析装置は、つぶやき２が変更された根拠（つぶやき４）を記録しておく。

次に、図６中の（Ｂ）の左端に矢印で示すように、つぶやき５が新たに入ってきたことにより、つぶやき２の変更の根拠となったつぶやき４のトピックが、つぶやき１とつぶやき５に挟まれて、トピックＩＤ「２」からトピックＩＤ「１」へ変更される。このとき、以前につぶやき２の変更の根拠となったつぶやき４が変更されたので、過去のつぶやき２の変更は信頼できなくなる。そこで、図６中の（Ｃ）に示すように、つぶやき２のトピックは、トピックＩＤ「２」への変更を取り消して元のトピックＩＤ「１」に戻す。

以上により、本実施の形態では、分析タイミングのずれで、つぶやきが参照するトピック取得を逃した場合であっても、分析装置が、推定によりつぶやきと手持ちのトピックとを対応づけて、データを補完することができる。単体の「つぶやきとトピック」の対応推定（例えば、機械学習等）に比べて、後で時系列の前後関係と推定の確信度から判断し直す変更を加えることで、推定精度・カバー範囲が向上する。これにより、トピックごとの注目度集計をする場合も、精度が上がる。

さらに、本発明を適用した実施の形態を詳細に説明する。
図７は、分析装置が実行するソーシャルメディア分析処理の流れを示すフローチャートである。

まず、ステップＳ７０１において、分析装置が、「つぶやき取得処理」を実行することによりつぶやきを取得する。「つぶやき取得処理」の詳細は、図８乃および図９を用いて説明する。

そして、ステップＳ７０２において、分析装置が、「つぶやき分析処理」を実行することにより、ステップＳ７０１で取得したつぶやきを分析する。「つぶやき分析処理」の詳細は、図１０乃至図１５を用いて説明する。

このソーシャルメディア分析処理は、定期的に実行される。
図８は、図７のステップＳ７０１で実行される「つぶやき取得処理」の流れを示すフローチャートであり、図９は、つぶやきＤＢの例を示す図である。

まず、図８のステップＳ８０１において、分析装置が、例えば各ソーシャルメディアが提供するデータ取得用のＡＰＩ（Application Programming Interface：アプリケーション・プログラミング・インターフェース）にアクセスしてつぶやき群を取得する。もしくは、別途ファイル等で取得しても構わない。

次に、ステップＳ８０２において、分析装置が、ステップＳ８０１で取得したつぶやき群について、それぞれのつぶやきを特定するためのつぶやきＩＤ、つぶやきそのもののテキスト情報、つぶやきが投稿された時刻の情報を、図９に示すつぶやきＤＢに格納する。

そして、ステップＳ８０３において、分析装置が、新規につぶやきＤＢに追加したつぶやき群を、後述するつぶやき分析部に渡す。

次に、分析装置が実行するつぶやき分析処理について説明する。
まず、図１０は、推定・変更に用いるデータの蓄積を説明するための図であり、分析処理において、つぶやきとトピックの対応付け確定のデータを蓄積する方法のうち、これまでに述べてきた方法とは別の方法を説明するための図である。

上述の通り、つぶやき時刻後、一定時間（例えば５分と設定）内にトピックを取得できた場合は、つぶやきが参照しているトピックを正しく取得できたものとし、つぶやきとトピックの対応付け「確定」とする。「確定」は、後の推定のための大事な情報源になるため、ここで、他にも「確定」を増やす方法について説明する。図１０に示す通り、９：００のつぶやき「超嬉しい ｈｔｔｐ：／／ａ．ｃｏｍ／」に対応するトピックは、９：０１に「ｈｔｔｐ：／／ａ．ｃｏｍ／」にアクセスして取得できたため、対応「確定」である。今、１５：００の時点で再度分析処理が行われ、９：３０のつぶやき「また？ ｈｔｔｐ：／／ａ．ｃｏｍ／」が処理対象となっている。しかし、こちらはつぶやかれてからすでに５分以上過ぎているため、対応するトピックが取得できなかったケースにあたる（この後、推定処理が行われる）。９：３０の時点でＵＲＬ「ｈｔｔｐ：／／ａ．ｃｏｍ／」が示していたトピックは、今からではもう取得できないが、同じＵＲＬの現在１５：００のトピックであれば、今、ＵＲＬにアクセスすれば取得可能である。つまり、図１０に示すように、１５：００のつぶやきは存在していないが、１５：００の時点で「ｈｔｔｐ：／／ａ．ｃｏｍ／」のトピックが今得られるトピックであることは確かな事実であるので、この情報は、本来存在しない１５：００のダミーのつぶやきと、１５：００に取得したトピックとを組み合わせた、ダミーの「確定」組み合わせの情報として蓄積し、後の推定の材料として活かす。

図１１は、図７のステップＳ７０２で実行される「つぶやき分析処理」の流れを示すフローチャートであり、図１２は、トピックＤＢの例を示す図であり、図１３は、つぶやき−トピックＩＤ対応ＤＢの例を示す図である。

まず、図１１のステップＳ１１０１において、分析装置が新規のつぶやき群からつぶやきを１つ取り出した場合（ステップＳ１１０１：ある）は、ステップＳ１１０２において、分析装置が、そのつぶやきのテキストからＵＲＬを抽出できるかできないかを判断する。

抽出できない場合（ステップＳ１１０２：Ｎ）は、ステップＳ１１０１に戻り、抽出できる場合（ステップＳ１１０２：Ｙ）は、ステップＳ１１０３において、分析装置が、そのＵＲＬにアクセスし、そのＵＲＬの現在のトピックを取得する。

次に、ステップＳ１１０４において、分析装置が、図１２に示したようなトピックＤＢを検索し、同じＵＲＬを持つ過去のトピック情報があるかないかを判断する。トピックＤＢには、「ＵＲＬ」「トピック取得時刻」「トピック」、及び「トピック」を特定するための「トピックＩＤ」が格納されている。なお、図１２において、カラム「トピック」は、例えば実体であるＨＴＭＬファイルのファイル名を示す。「ＵＲＬ」は同じ「ｈｔｔｐ／／ａ.ｃｏｍ／」であるが、トピック取得時刻が違うため、「ｘｘｘ．ｈｔｍｌ」と「ｚｚｚ．ｈｔｍｌ」の２つのＨＴＭＬファイルがある。この異なる２つのＨＴＭＬファイルは、内容が同一と過去に判定されているため、同一の「トピックＩＤ」として「１」が付与されている。

続いて、同じＵＲＬを持つ過去のトピック情報がない場合（ステップＳ１１０４：Ｎ）は、ステップＳ１１０５において、分析装置が、新規にトピックＩＤを付与する。他方、同じＵＲＬを持つ過去のトピック情報がある場合（ステップＳ１１０４：Ｙ）は、ステップＳ１１０６において、分析装置が、現在のトピックと同じＵＲＬの過去のトピックのうち、トピック取得時刻が最も直前のものを取り出し、現在のトピックとの同一判定を行う。同一であれば同一のトピックＩＤを付与し、同一でなければ新規のトピックＩＤを付与する。

そして、ステップＳ１１０７において、分析装置が、ステップＳ１１０３で取得したトピックを、ＵＲＬ、トピック取得時刻（すなわち現在の時刻）、トピックＩＤとともに、図１２に例示したようなトピックＤＢに格納する。

次に、ステップＳ１１０８において、分析装置が、現在処理中のつぶやきを、図１３に示すようなつぶやき−トピックＩＤ対応ＤＢのレコード形式に変換する。

そして、ステップＳ１１０９において、分析装置が、トピックとつぶやきの対応付けが確定か、すなわち、トピック取得時刻とつぶやき時刻との差分が所定の閾値、例えば５分以内か５分を越えたかを判断する。

トピック取得時刻とつぶやきが蓄積された時刻との差分が所定の閾値内である場合（ステップＳ１１０９：Ｙ）は、つぶやきとトピックＩＤの対応が対応確定であるので、ステップＳ１１１０において、分析装置が、処理中のつぶやきとトピックＩＤを対応づけて、確定フラグ付きでつぶやき−トピックＩＤ対応ＤＢに格納した後、ステップＳ１１０１に戻る。つぶやき−トピックＩＤ対応ＤＢには、「対応ＩＤ」「つぶやき」「つぶやき時刻」「トピック取得時刻」「ＵＲＬ」「トピックＩＤ」「対応関係」「変更根拠履歴」が格納されている。なお、カラム「対応関係」には、対応「確定」又は対応「推定」が入る。「推定」の場合は、「確信度スコア」もあわせて記載される。なお、ここで、「対応ＩＤ」とは、「つぶやき」と「トピックＩＤ」との対応付けを特定するための識別子であり、例えば図１３に示すように「１」から順に１ずつ増やしながら付与することができる。

他方、トピック取得時刻とつぶやきが蓄積された時刻との差分が所定の閾値内でない場合（ステップＳ１１０９：Ｎ）は、つぶやきと対応するトピックが取得できなかった状態であるので、分析装置が、図１４及び図１５を用いて説明するトピックの「対応推定処理」を実行する。

図１４及び図１５は、分析装置が実行する「対応推定処理」の流れを示すフローチャートである。

ここで、図１６乃至図２９の具体例を用いながら、図１４及び図１５内のそれぞれのステップについて説明する。まず、図１６乃至図２０は、あるつぶやきとトピックの組み合わせ単体の推定を行い、その結果、十分な確信度がなく、対応トピック不明、といったん判定されたものが、他のつぶやきとトピックの組み合わせとあわせて推定し直したことにより、変更されて解決する例である。なお、図１６乃至図２０は、図１３に示したつぶやき−トピックＩＤ対応ＤＢと同様のレコード形式であるが、説明に不要なカラム「対応ＩＤ」「変更根拠履歴」は省略してある。

まず、図１４のステップＳ１４０１において、分析装置が、「ダミー確定」にあたるレコードの作成を行う。推定対象となっているつぶやきに記載されたＵＲＬと現在のトピックＩＤとを、つぶやき−トピックＩＤ対応ＤＢのレコード形式に変換する。対応するつぶやきは存在しないが、カラム「つぶやき」にはダミーの旨を記載、「つぶやき時刻」にはダミー時刻としてトピック取得時刻を入れ、カラム「対応関係」に「確定」を入れる。

図１６に示すように、具体的には、推定処理の対象となっているつぶやきが「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」という８：００のつぶやき、つぶやきから抽出したＵＲＬが「ｈｔｔｐ：／／ａ．ｃｏｍ／」、「ｈｔｔｐ：／／ａ．ｃｏｍ／」が指している現在のトピックが取得された時刻が１２：００、現在のトピックＩＤが「２」である。そのため、ダミー確定のレコードでは、カラム「つぶやき時刻」に１２：００が入れられている。

次に、ステップＳ１４０２において、分析装置が、つぶやき−トピックＩＤ対応ＤＢから、つぶやきに記載されたＵＲＬと同一のＵＲＬを持つレコードを抽出する。

具体的には、図１６に示すように、つぶやき「ほにゃ ｈｔｔｐ：／／ａ．ｃｏｍ／」、つぶやき時刻７：００、トピック取得時刻７：０５、トピックＩＤ「１」、対応関係「確定」、という１レコードが抽出されている。

そして、ステップＳ１４０３において、分析装置が、ステップＳ１４０２で抽出したレコードが１個以上あるかないかを判断する。

ここで、もし、つぶやき−トピックＩＤ対応ＤＢから抽出したレコードが１個もなかった場合は（ステップＳ１４０３のＮ）、過去に蓄積された情報を活用した推定は行えないということであるので、ステップＳ１４０４にて、推定処理中のつぶやき「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」と、現在のトピックＩＤ（つまりダミーレコードのトピックＩＤ）「２」との対応関係を単体で推定することになる。推定方法には、例えば機械学習を用いる。

推定の結果、算出された確信度に応じて、ステップＳ１４０５において、分析装置が、推定処理中のつぶやき「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」と、トピックＩＤ「２」を対応づける、もしくは、つぶやき「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」の対応トピックは「不明」である、とする。

なお、トピック「不明」を対応付けるのは、確信度が所定値、例えば４０点以下の場合である。そして、推定処理中のつぶやきレコードのカラム「トピックＩＤ」に現在のトピックＩＤ「２」または「不明」、カラム「対応関係」に「推定」を入れて、ダミー確定レコードと共に、つぶやき−トピックＩＤ対応ＤＢに格納する。ここで分析装置による対応推定処理は終了となり、図１１のステップＳ１１０１に戻る。

しかし、図１６に示す例では、ＤＢから抽出したレコード数が１であるので（ステップＳ１４０３のＹ）、ステップＳ１４０６において、分析装置が、ＤＢから抽出したレコード、推定処理中のつぶやきのレコード、ダミーレコードの３レコードをつぶやき時刻でソートし、これらは図１６の順番で並べられる。

続いて、ステップＳ１４０７において、分析装置が、ソート済みのレコードの中から、推定処理中のつぶやきのレコードの前後で、カラム「対応関係」が「確定」と「確定」にはさまれた区間のレコードを抽出する。ここでは、図１６に示す３レコードである。

次に、ステップＳ１４０８において、分析装置が、推定処理中のつぶやきのレコードが、同じトピックＩＤの「確定」レコードに挟まれているかを判定する。

もし、ここで同じトピックＩＤの確定にはさまれているのであれば（ステップＳ１４０８のＹ）、推定処理中のつぶやきレコードに対応するトピックＩＤも、同じトピックＩＤで「確定」になり、あとはステップＳ１４０９において、分析装置が、推定処理中のつぶやきレコードに、トピックＩＤと確定情報を格納して、ダミーレコードとあわせてつぶやき−トピックＩＤ対応ＤＢに格納し、「対応推定処理」のフローは終了となる。そして、図１１のステップＳ１１０１に戻る。

しかし、図１６に示す例では、トピックＩＤ「１」の確定レコードと、トピックＩＤ「２」の確定レコードに挟まれているので、ステップＳ１４０８はＮとなり、ステップＳ１４１０に進む。

ステップＳ１４１０では、分析装置が、推定処理中のつぶやきを挟んでいる前後の確定レコードの「トピックＩＤ」から、トピックＩＤの候補を抽出する。

図１６に示す例では、トピックＩＤ「１」または「２」が候補である。
続いて、ステップＳ１４１１において、分析装置が、推定処理中のつぶやきレコードのつぶやき「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」と、それぞれのトピックＩＤ候補との対応関係を単体で、例えば機械学習を利用して推定し、確信度を算出する。

ここで、トピックＩＤ「１」である確信度スコアが２０点、トピック「２」である確信度スコアが１０点だったとする。

ステップＳ１４１２において、分析装置が、各確信度スコアから、つぶやきと対応するトピックＩＤを選出する。

前述の通り、「スコアがこれ以上ないとどちらとも対応付けせず不明とする」閾値を４０点としていた場合、トピックＩＤ「１」、トピックＩＤ「２」どちらのスコアも低すぎる（閾値以下である）ので、ここでの推定結果は、１でも２でもなく「不明」である。よって、分析装置は、推定対象のつぶやきレコードのカラム「トピックＩＤ」に「不明」を格納、カラム「対応関係」に「推定」および推定結果のスコアもあわせて格納する。つまり、図１４内のステップの推定処理の結果は、図１７の通りとなる。

次に、図１５のステップＳ１５０１において、分析装置が、対応確定と対応確定に挟まれた区間のレコードの並びの中に、トピックＩＤの変更候補があるかないかを判断する。例えば、トピックＩＤが１から２に変更になった後に再度１に戻る等、トピックＩＤの時間的な前後関係で矛盾がないかを見る。矛盾があるつぶやきとトピックの対応付けレコードのうち、確信度の低い方の対応付けレコードが変更候補となる。また、トピックＩＤが不明だったトピックが、同じＩＤにはさまれて決まることがないかを見る。その場合は不明トピックのレコードが変更候補となる。

図１７に示す通り、ここでのトピックＩＤの並びは「１→不明→２」で、矛盾があるわけではなく、また、同じトピックＩＤに挟まれた「不明」があるわけでもないので、ステップＳ１５０１はＮとなり、ステップＳ１５０２に進む。そして、対応推定中のレコードおよびダミー確定のレコード、つまり図１７内の下２つのレコードを、つぶやき−トピックＩＤ対応ＤＢに格納して、分析装置による「対応推定処理」のフローを終了する。そして、図１１のステップＳ１１０１に戻る。

次に、図１５内のステップＳ１５０１がＹとなる場合について、今度は新しく図１８の具体例を用いて説明する。

図１８の例は、図１６、１７を使って説明してきた１２：００のつぶやき分析処理が一通り終了し、次に１５：００の時点で、新たなつぶやき分析処理が行われている際の例である。

図１８に示した通り、新たに現在推定処理中となっているつぶやきは、９：００のつぶやき「ほにゃらら ｈｔｔｐ：／／ａ．ｃｏｍ／」である。また、図１８の他のレコードは、図１４のステップＳ１４０３でつぶやき-対応トピックＤＢから抽出されたレコード（つまり、前回１２：００の際のつぶやき分析処理の結果）と、１５：００現在のダミー確定のレコードの状態を示している。

図１４のステップＳ１４０６で、分析装置が、これらのレコードをつぶやき時刻でソートすると、推定処理中のつぶやきレコード（つぶやき「ほにゃらら ｈｔｔｐ：／／ａ．ｃｏｍ／」のレコード）は、図１８中の矢印の位置、つまり８：００のつぶやき「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」と、１２：００のダミー確定のつぶやきの間に入り、ソート結果は図１９に示す通りとなる。

この場合、図１４中のステップＳ１４１０で抽出された、トピックＩＤの候補は、前後の確定レコードのトピックであるから、７：００のつぶやき「ほにゃ ｈｔｔｐ：／／ａ．ｃｏｍ／」のトピックであるトピックＩＤ「１」か、１２：００のダミー確定のトピックであるトピックＩＤ「２」のどちらかとなる。

続いて図１４のステップＳ１４１１で、分析装置が、推定処理中のつぶやき「ほにゃらら ｈｔｔｐ：／／ａ．ｃｏｍ／」と、それぞれのトピックＩＤ候補との対応関係を単体で、例えば機械学習を利用して推定し、確信度を算出する。

その結果、トピックＩＤ「１」である確信度スコアが８０点、トピックＩＤ「２」である確信度スコアが１０点となり、図１４中のステップＳ１４１２で、分析装置が、トピックＩＤ「１」と判定する。

ここで、図１５内のステップＳ１５０１で、分析装置が、レコードの並びからトピックＩＤの変更候補があるかを見ると、図１９の上から３つのレコードの並びにおいて、トピックＩＤが「１→不明→１」となる（ステップＳ１５０１がＹ）。

そこで、ステップＳ１５０３において、上から２つ目のトピックＩＤ「不明」だったレコードが、図２０の通り、分析装置によってトピックＩＤ「１」に変更される。

ステップＳ１５０４、Ｓ１５０５は、後に別の例で説明するため、ここでは説明を省略し、ステップＳ１５０６において、分析装置により変更候補がまだあると判断されれば（Ｓ１５０６がＹ）、分析装置は、ステップＳ１５０３に戻り処理を続ける。他方、分析装置により他にトピックの並びの矛盾も不明もないと判断されれば（Ｓ１５０６がＮ）、図２０に示す通り、ステップＳ１５０７において、分析装置が、図２０のレコードの並びのうち、更新分、すなわち、上から２番目のつぶやき「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」のレコード、３番目のつぶやき「ほにゃらら ｈｔｔｐ：／／ａ．ｃｏｍ／」のレコード、５番目のダミーレコードをつぶやき−トピックＩＤ対応ＤＢに格納して、対応推定処理を終了する。

以上のようにして、分析装置は、あるつぶやきとトピックの組み合わせ単体の推定を行い、その結果、十分な確信度がなく、対応トピック不明、といったん判定されたものであっても、他のつぶやきとトピックの組み合わせとあわせて推定し直したことにより、推定結果の変更が起こって、解決することができる。

次に、図２１乃至図２９を用いて、変更の変更が起こる例を説明する。なお、図２１乃至図２９は、図１３に示したつぶやき−トピックＩＤ対応ＤＢと同様のレコード形式であるが、図２１乃至図２５については説明に不要なカラム「対応ＩＤ」「変更根拠履歴」を省略してある。

図１４および図１５のすでに説明済みのステップについては詳細に追うことを省略するが、新しく図２１に示す例では、分析装置によるつぶやき分析処理を実行する時刻１２：００の時点において、推定処理中のつぶやきは、つぶやき時刻８：００のつぶやき「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」である。また、つぶやき−トピックＩＤ対応ＤＢから抽出したレコード、１２：００現在のダミー確定レコードをつぶやき時刻でソートすると、図２１の順序になり、推定処理対象のつぶやきレコードは、確定のトピックＩＤ「１」とトピックＩＤ「２」のレコードに挟まれているため、この２つのトピックＩＤが推定候補となる。

推定処理中のつぶやき「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」と、それぞれのトピックＩＤ候補との対応関係を単体で、例えば機械学習を利用して推定し、確信度を算出する。その結果、トピックＩＤ「１」の確信度スコアが２０点、トピックＩＤ「２」の確信度スコアが５０点となり、トピックＩＤ「２」と判定された。その結果が図２２である。

また、次に時刻１５：００の時点で分析装置によりつぶやき分析処理が再度実行され、図２３に示す通り、推定処理中のつぶやきは、９：００のつぶやき「ほにゃらら ｈｔｔｐ：／／ａ．ｃｏｍ／」である。また、つぶやき−トピックＩＤ対応ＤＢから抽出したレコード（前回１２：００の処理結果）、１５：００現在のダミー確定レコードをつぶやき時刻でソートすると、図２４に示す通りの順序になり、推定処理対象のつぶやきレコードは、「確定」のトピックＩＤ「１」と「確定」のトピックＩＤ「２」のレコードに挟まれているため、この２つのトピックＩＤが推定候補となる。

推定処理中のつぶやき「ほにゃらら ｈｔｔｐ：／／ａ．ｃｏｍ／」と、それぞれのトピックＩＤ候補との対応関係を単体で、例えば機械学習を利用して推定し、確信度を算出する。その結果、トピックＩＤ「１」である確信度スコアが６０点、トピックＩＤ「２」である確信度スコアが１０点となり、トピックＩＤ「１」と判定された（ここまでで、図１４のステップＳ１４１２）。

ここで、図１５のステップＳ１５０１において、分析装置が、レコードの並びの中にトピックＩＤの変更候補があるかを判定すると、図２５に示す通り、上から３つのレコードのトピックＩＤの並びが「１→２→１」となっており、矛盾がある。

カラム「対応関係」の確信度スコアを見ると、２番目のつぶやき「ほにゃら ｈｔｔｐ：／／ａ．ｃｏｍ／」のレコードがトピックＩＤ「２」である確信度は５０、３番目のつぶやき「ほにゃらら ｈｔｔｐ：／／ａ．ｃｏｍ／」のレコードがトピックＩＤ「１」である確信度は６０であるため、スコアの小さい２番目のレコードが変更候補である。

よって、ステップＳ１５０３で、図２５に示す通り、分析装置により２番目のレコードのトピックＩＤが「２→１」に変更され、上から３つのレコードの間はすべてトピックＩＤ「１」だった、との推定結果となる。

ここで、図２６に示す通り、変更された２番目のレコード（対応ＩＤ２、説明を省略してきたが、各レコードには対応ＩＤが付与されている）のカラム「変更根拠履歴」には、今起こった変更が、対応ＩＤ４のレコードを根拠として、トピックＩＤ「２→１」へと変更された旨が記録される。

さらに、次の推定処理対象のつぶやきとして、図２７に示すように、８：３０のつぶやき「ほにゃららら ｈｔｔｐ：／／ａ．ｃｏｍ／」（対応ＩＤ６）が入ってきて、トピックＩＤの候補が「１」か「２」であり、対応関係を単体で、例えば機械学習を利用して推定すると、トピックＩＤ「２」であると推定された。

続いて、図１５のステップＳ１５０１で、分析装置が、変更候補を判定すると、図２７に示す通り、トピックの推移は上から「１→１→２→１→２…」となっており、矛盾が発生している。つまり、対応ＩＤ６のレコード、もしくは対応ＩＤ４のレコードの推定が誤っていることになる。対応ＩＤ６のレコードは、確信度９０でトピックＩＤ「２」、対応ＩＤ４のレコードは、確信度６０でトピックＩＤ「１」であるため、確信度スコアの小さい対応ＩＤ４のレコードが変更候補となる。

そこで、図１５のステップＳ１５０３において、分析装置により対応ＩＤ４のレコードのカラム「トピックＩＤ」が「１→２」に変更され、該当レコードのカラム「変更根拠履歴」には、今起こった変更が、対応ＩＤ６を根拠として、トピックＩＤ「１→２」への変更であった旨が記録される。その結果を図２８に示す。

すでに述べた通り、ある変更の根拠となっていた情報が後に変更されてしまった場合、それは根拠として信頼できなくなったので、当初の変更の取り消しを行う必要がある。

そこで、次に図１５のステップＳ１５０４において、分析装置により、今変更のあった対応ＩＤ４のレコードを根拠として実施された、過去の変更がなかったかの判定が行われる。上述の通り、対応ＩＤ２のレコードは、対応ＩＤ４のレコードを根拠として変更が行われた経緯があるので、図２８の各レコードの変更履歴の最終変更において、対応ＩＤ４を根拠にしているレコードがあるかを調べると、対応ＩＤ２のレコードが該当する。

そこで、ステップＳ１５０５において、分析装置が、該当するＩＤ２のレコードの過去の変更を取り消す。図２９に示す通り、対応ＩＤ２のレコードのトピックＩＤは、過去に「２→１」に変更されていたものが、「２」に戻され、変更履歴も削除される。

以上のようにして、推定結果の変更の変更が起こる。このように変更が繰り返されることで、全体の推定精度を高めていくことができる。

図３０は、本実施の形態を実行する分析装置の構成図（その１）である。
本発明が適用される分析装置は、つぶやき取得部３００１及びつぶやき分析部３００３を備える。

つぶやき分析部３００３は、つぶやき情報抽出部３００４、トピック取得部３００５、トピック同一判定部３００７、及びつぶやき−トピックＩＤ対応判定部３００８を備える。そして、つぶやき−トピックＩＤ対応判定部３００８は、確定対応付部３０１０、トピックＩＤ候補選出部３０１１、対応推定部３０１２、推定規則ＤＢ３０１３、及び変更部３０１４を備える。

また、つぶやきＤＢ３００２、トピックＤＢ３００６、つぶやき−トピックＩＤ対応ＤＢ３００９を備える。

つぶやき取得部３００１は、ソーシャルメディアのＡＰＩにアクセスしてつぶやき群を取得し、つぶやきＤＢ３００２に格納する。

つぶやき情報抽出部３００４は、つぶやきＤＢ３００２からつぶやきを取り出し、ＵＲＬ等のつぶやき情報を抽出する。

トピック取得部３００５は、つぶやきに記載されたＵＲＬにアクセスし、そのＵＲＬの現在のトピックを取得する。

トピック同一判定部３００７は、現在のトピックと同じＵＲＬの過去のトピックとの同一判定を行い、同一であれば同一のトピックＩＤを付与し、同一でなければ新規のトピックＩＤを付与して、トピックＤＢ３００６に格納する。

確定対応付部３０１０は、処理中のつぶやきとトピックＩＤの「確定」の対応づけを付与する。

トピックＩＤ候補選出部３０１１は、処理中のつぶやきをはさんでいる前後の「確定」レコードから、トピックＩＤの候補を抽出する。

対応推定部３０１２は、推定規則ＤＢ３０１３を参照し、機械学習等によりつぶやきとトピックとの対応関係を推定する。

変更部３０１４は、時系列順に並べたつぶやきとトピックの対応関係について、トピックの推移に矛盾や不明がないか調べ、矛盾や不明がある場合に、トピックＩＤを変更する。

また、本実施の形態の分析装置を利用しながら、対応付けの事例を蓄積していき、それを機械学習の学習データとして利用する（再学習する）こともできる。

次に、蓄積した事例を学習データに利用する例を説明する。
図３１は、蓄積した事例を学習データに利用する例を説明するための図である。

機械学習には、すでに述べた通り、学習フェーズと推定フェーズがある。推定を行うためには、事前に正例・負例による学習データで、学習、すなわち推定のための規則の自動生成を行っておく必要がある。学習データを人手で作成するのは大きな労力が必要となるので、できるだけ自動的に学習データを生成することが望ましい。

本発明では、上述の実施の形態で蓄積するつぶやき−トピックＩＤ対応ＤＢのデータのうち、対応づけ「確定」のつぶやきとトピックの組み合わせの事例を学習データとして利用することができる。

図３１に示す通り、学習フェーズでは、「確定」のつぶやきとトピックの組み合わせの事例を正例として、対応推定規則を学習する。例えば、正例であるつぶやき「超嬉しい ｈｔｔｐ：／／ａ．ｃｏｍ／」とトピック「アイドルグループＡをＣＭに起用」の組み合わせの対応推定規則を学習する。また、本来組み合わせられていたつぶやきとトピック以外の組み合わせ事例を負例として、対応推定規則を学習する。例えば、負例であるつぶやき「超嬉しい ｈｔｔｐ：／／ａ．ｃｏｍ／」とトピック「社長スキャンダル」の組み合わせの対応推定規則を学習する。この対応推定規則を用いて、推定フェーズにて対応推定を行う。

また、対応付け「確定」の事例のみならず、「推定」の事例も、確信度が閾値以上であるならば、学習データとして利用しても構わない。

以上のようにすれば、本実施の形態の分析装置の利用に応じて蓄積データが変更され、学習データとして利用可能なデータが増えていくため、定期的に再学習することで、推定精度が向上する。

図３２は、本実施の形態を実行する分析装置の構成図（その２）である。
図３２に示した分析装置を用いて、蓄積した事例を学習データに利用することができる。

学習データ生成部３２１５は、つぶやきＤＢ３００２、トピックＤＢ３００６、及びつぶやき−トピックＩＤ対応ＤＢ３００９に格納されたデータに基づいて、学習データを生成し、学習データＤＢ３２１６に格納する。学習部３２１７は、学習データＤＢ３２１６に格納された学習データに基づいて、学習又は再学習を行い、推定規則ＤＢ３０１３を更新する。

図３３は、変形例を説明するための図である。
上述してきた実施の形態では、利用する時刻情報として、つぶやき時刻とトピック取得時刻を用いた。これらの時刻情報に加えて、トピックの最終更新時刻を用いることもできる。

図３３に示す通り、現在推定対象となっているのは、左端に矢印の付いた９：００のつぶやき「ほにゃらら ｈｔｔｐ：／／ａ．ｃｏｍ／」のレコードである。

トピックの最終更新時刻を用いない実施の形態の場合、つぶやき時刻の前後関係から、トピックＩＤ「１」又は「２」を候補として推定を行うが、ここで図３３中の一番下のダミー確定のレコードの最終更新時刻により、８：３０以降はトピックＩＤ「２」であることがわかる。よって、推定しなくても「トピックＩＤ２で確定」にすることができる。これにより、確定レコードを増やすことができる。

以上、本発明の実施の形態を、図面を参照しながら説明してきたが、上述してきた本発明の実施の形態は、分析装置の一機能としてハードウェアまたはＤＳＰ（Digital Signal Processor）ボードやＣＰＵボードでのファームウェアもしくはソフトウェアにより実現することができる。

また、本発明が適用される分析装置は、その機能が実行されるのであれば、上述の実施の形態に限定されることなく、単体の装置であっても、複数の装置からなるシステムあるいは統合装置であっても、ＬＡＮ、ＷＡＮ等のネットワークを介して処理が行なわれるシステムであってもよいことは言うまでもない。

また、バスに接続されたＣＰＵ、ＲＯＭやＲＡＭのメモリ、入力装置、出力装置、外部記録装置、媒体駆動装置、ネットワーク接続装置で構成されるシステムでも実現できる。すなわち、前述してきた実施の形態のシステムを実現するソフトェアのプログラムを記録したＲＯＭやＲＡＭのメモリ、外部記録装置、可搬記録媒体を、分析装置に供給し、その分析装置のコンピュータがプログラムを読み出し実行することによっても、達成されることは言うまでもない。

この場合、可搬記録媒体等から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した可搬記録媒体等は本発明を構成することになる。

プログラムを供給するための可搬記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、磁気テープ、不揮発性のメモリーカード、ＲＯＭカード、電子メールやパソコン通信等のネットワーク接続装置（言い換えれば、通信回線）を介して記録した種々の記録媒体などを用いることができる。

また、コンピュータ（情報処理装置）がメモリ上に読み出したプログラムを実行することによって、前述した実施の形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施の形態の機能が実現される。

さらに、可搬型記録媒体から読み出されたプログラムやプログラム（データ）提供者から提供されたプログラム（データ）が、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施の形態の機能が実現され得る。

すなわち、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または形状を取ることができる。

３００１ つぶやき取得部
３００２ つぶやきＤＢ
３００３ つぶやき分析部
３００４ つぶやき情報抽出部
３００５ トピック取得部
３００６ トピックＤＢ
３００７ トピック同一判定部
３００８ つぶやき−トピックＩＤ対応判定部
３００９ つぶやき−トピックＩＤ対応ＤＢ
３０１０ 確定対応付部
３０１１ トピックＩＤ候補選出部
３０１２ 対応推定部
３０１３ 推定規則ＤＢ
３０１４ 変更部
３２１５ 学習データ生成部
３２１６ 学習データＤＢ
３２１７ 学習部

Claims (4)

1. リンク先を示す情報を含むコンテンツが登録をされた日時と、該リンク先を示す情報と、該リンク先の内容を示す情報と、該リンク先の内容を示す情報の確からしさを示す情報と、を関連付けて記録をしたデータベースを格納する記憶部と、
   前記データベースを参照して、前記リンク先を示す情報が同一のデータについてコンテンツが登録をされた日時の時系列で並べた場合に、リンク先の内容を示す情報が同一で、且つ、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えるデータに挟まれた、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えないデータについて、リンク先の内容を示す情報を、該データを挟む、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えるデータのリンク先の内容を示す情報に変更をする変更部と、
   を有することを特徴とする分析装置。
2. 前記変更部が、データのリンク先の内容を示す情報を変更する際に、変更をするデータと、変更前のデータのリンク先の内容を示す情報と、変更の根拠とした、データを挟むリンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えるデータとを記録しておき、データのリンク先の内容を示す情報を変更する際に、変更をするデータを、変更の根拠としてデータのリンク先の内容を示す情報を変更したデータがあれば、該データの変更をしたリンク先の内容を示す情報を変更前のリンク先の内容を示す情報に戻すこと、
   を特徴とする請求項１記載の分析装置
3. コンピュータが、
   リンク先を示す情報を含むコンテンツが登録をされた日時と、該リンク先を示す情報と、該リンク先の内容を示す情報と、該リンク先の内容を示す情報の確からしさを示す情報と、を関連付けて記録をしたデータベースを格納し、
   前記データベースを参照して、前記リンク先を示す情報が同一のデータについてコンテンツが登録をされた日時の時系列で並べた場合に、リンク先の内容を示す情報が同一で、且つ、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えるデータに挟まれた、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えないデータについて、リンク先の内容を示す情報を、該データを挟む、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えるデータのリンク先の内容を示す情報に変更をする、
   ことを特徴とする分析方法。
4. コンピュータに、
   リンク先を示す情報を含むコンテンツが登録をされた日時と、該リンク先を示す情報と、該リンク先の内容を示す情報と、該リンク先の内容を示す情報の確からしさを示す情報と、を関連付けて記録をしたデータベースを格納させ、
   前記データベースを参照して、前記リンク先を示す情報が同一のデータについてコンテンツが登録をされた日時の時系列で並べた場合に、リンク先の内容を示す情報が同一で、且つ、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えるデータに挟まれた、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えないデータについて、リンク先の内容を示す情報を、該データを挟む、リンク先の内容を示す情報の確からしさを示す情報が所定の閾値を超えるデータのリンク先の内容を示す情報に変更をさせる、
   ことを特徴とする分析プログラム。