JP2017068862A - 情報処理装置、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

【課題】テキストデータにおいて記述の対象となっている情報を精度良く特定することができるテキスト情報処理装置、テキスト情報処理方法、及びテキスト情報処理プログラムを提供する。
【解決手段】検索部は、テキストデータから抽出される検索キーに対応する１又は複数のアイテム情報である検索結果セットを、アイテム情報を格納しているアイテムデータベースから取得する。類似度計算部は、検索部が一の検索キーについて複数のアイテム情報からなる検索結果セットを取得した後に、その一の検索キーに対応する複数のアイテム情報間の類似度に基づく検索結果セットのスコアを計算する。妥当性判定部は、スコアに基づいて、検索部が取得したアイテム情報の中から、テキストデータに対応するアイテム情報を特定する。
【選択図】図１

Description

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

近年、インターネットの普及を背景にして、インターネット上の掲示板やソーシャルネットワークサービス（SNS: Social Network Service）など、ユーザが手軽に口コミ情報等の文章をアップロードして、その文章を公開することができるサービスが増えている。また、このようなインターネット上の口コミ情報等を把握することは、企業のマーケティング戦略の面などから注目されている。
しかし、個々のユーザによってアップロードされたインターネット上の文章には、省略された語句や表記揺れが多いため、そのような文章から適切なキーワードを迅速に見つけにくいという問題があった。このような問題に対応する技術として、例えば特開２０１１−３１５７号公報（特許文献１）のような技術が存在する。

特開２０１１−３１５７号公報

特許文献１には、テキストデータを解析し、商品またはサービスであるアイテムを特定し、アイテムごとにユーザの口コミ情報を要約する技術が記載されている。しかしながら、解析対象のテキストデータが、どのアイテムに対応するかの判定精度が必ずしも十分ではなかった。例えば、記述の対象が音楽や映画などの場合、その名称は非常に多様であり、名称を示す文字列に明確な規則性が存在しないため、記述の対象となっているアイテムを特定する精度が十分でない場合があった。このため、テキストデータにおいて記述の対象となっているアイテムを特定できなかったり、実際に記述の対象となっているアイテムとは異なるアイテムを特定したりしてしまう場合があった。

本発明はこのような問題点に鑑みなされたものであり、テキストデータにおいて記述の対象となっている情報を精度良く特定することを目的とする。

本発明は上述した従来の技術の課題を解決するため、データベースを検索し、検索条件に対応した複数の情報を取得する検索部と、前記複数の情報間の類似度に基づくスコアを計算する類似度計算部と、前記スコアに基づいて、前記検索条件の妥当性を判定する妥当性判定部とを備えることを特徴とする情報処理装置を提供する。
また、本発明は上述した従来の技術の課題を解決するため、データベースを検索し、複数の情報からなる検索結果セットを取得する検索部と、前記検索結果セットに含まれる複数の情報間の類似度に基づくスコアを計算する類似度計算部と、前記スコアに基づいて、前記検索結果セットの妥当性を判定する妥当性判定部とを備えることを特徴とする情報処理装置を提供する。
また、本発明は上述した従来の技術の課題を解決するため、１または複数のコンピュータが実行する情報処理方法であって、データベースを検索し、検索条件に対応した複数の情報を取得する検索ステップと、前記検索ステップにおいて取得した前記複数の情報間の類似度に基づくスコアを計算する類似度計算ステップと、前記類似度計算ステップで計算された前記スコアに基づいて、前記検索条件の妥当性を判定する妥当性判定ステップとを含むことを特徴とする情報処理方法を提供する。
また、本発明は上述した従来の技術の課題を解決するため、１または複数のコンピュータが実行する情報処理方法であって、データベースを検索し、複数の情報からなる検索結果セットを取得する検索ステップと、前記検索ステップにおいて取得された前記検索結果セットに含まれる複数の情報間の類似度に基づくスコアを計算する類似度計算ステップと、前記類似度計算ステップで計算された前記スコアに基づいて、前記検索結果セットの妥当性を判定する妥当性判定ステップとを含むことを特徴とする情報処理方法を提供する。
また、本発明は上述した従来の技術の課題を解決するため、１または複数のコンピュータを、データベースを検索し、検索条件に対応した複数の情報を取得する検索部、前記検索部において取得した前記複数の情報間の類似度に基づくスコアを計算する類似度計算部、前記類似度計算部で計算された前記スコアに基づいて、前記検索条件の妥当性を判定する妥当性判定部として機能させることを特徴とする情報処理プログラムを提供する。
また、本発明は上述した従来の技術の課題を解決するため、１または複数のコンピュータを、データベースを検索し、複数の情報からなる検索結果セットを取得する検索部、前記検索部において取得された前記検索結果セットに含まれる複数の情報間の類似度に基づくスコアを計算する類似度計算部、前記類似度計算部で計算された前記スコアに基づいて、前記検索結果セットの妥当性を判定する妥当性判定部として機能させることを特徴とする情報処理プログラムを提供する。

本発明によれば、テキストデータにおいて記述の対象となっている情報を精度良く特定することができる。

各実施形態における全体構成を示すためのブロック図である。 記事テキスト（テキストデータ）の例を示す図である。 第１実施形態のテキスト情報処理装置１の動作を示すフローチャートである。 記事テキストからキーワードを抽出する方法の一例について説明するための図である。 テキストデータ記憶部６が格納するデータの一例を示す図である。 アイテムＤＢ３が格納するデータの一例を示す図である。 キーワードグループ記憶部５が格納するデータの一例を示す図である。 スコア記憶部７が格納するデータの一例を示す図である。 アイテム算出結果記憶部８が格納するデータの一例を示す図である。 アイテムランキング情報記憶部９が格納するデータの一例を示す図である。 第２実施形態のテキスト情報処理装置１の動作を示すフローチャートである。 第２実施形態のテキスト情報処理装置１の動作を示すフローチャートである。

以下、本発明のテキスト情報処理装置、テキスト情報処理方法、及びテキスト情報処理プログラムについて、図面を参照して説明する。なお、図面中において、同一のものは同じ符号を付す。
また、以下の説明におけるアイテムは、音声、音楽、映像、ウェブページ等のコンテンツや様々な物品であってもよいし、金融商品、不動産、人物に関する情報等であってもよい。また、以下の説明におけるアイテムは、有形か無形かを問わず、有料か無料かも問わない。

＜第１実施形態＞
図１は、第１実施形態のテキスト情報処理装置１を含むシステム全体の構成例を示すブロック図である。
このシステムには、テキスト情報処理装置１や、テキストデータサーバ（ブログサーバ）２、アイテムデータベース（アイテムデータサーバ）３、利用者の端末装置４などが含まれ、それぞれがネットワーク２０を介して通信可能である。なお、テキスト情報処理装置１は例えばサーバである。
また、テキストデータサーバ２はテキストデータを記憶し、アイテムデータベース３はアイテムに関する情報を記憶する。
以下の説明では、テキスト情報処理装置１が処理するテキストデータの一例としてブログデータを用いて説明する。ブログデータとは、ユーザによって作成されたテキストデータを含むものである。例えば、ユーザが、ソーシャルネットワークサービスを利用して作成したテキストデータ（ブログ記事）を含むものである。ソーシャルネットワークサービスとして、例えば、Twitter（登録商標）、Facebook（登録商標）、mixi（登録商標）などがある。

また、テキストデータサーバ２とアイテムデータベース３はそれぞれ別の主体として記述しているが、それらの一部、または全てがテキスト情報処理装置１と同一の主体となるように構成されていてもよい。

テキスト情報処理装置１は、テキストデータ収集部１０、キーワード集合生成部１１、アイテム特定部１２、及びランキング情報作成部１３という４つの処理部を有して構成されている。これら４つの処理部は一体であってもよいし、それぞれ別体であってもよい。また、単一のＣＰＵやＤＳＰを用いて構成してもよいし、複数のＣＰＵやＤＳＰ等を用いて構成してもよい。
また、テキスト情報処理装置１は、キーワードグループ記憶部５、テキストデータ記憶部６、スコア記憶部７、アイテム算出結果記憶部８、及びアイテムランキング情報記憶部９を有して構成されている。これら５つの記憶部は一体であってもよいし、それぞれ別体であてもよい。また、単一のハードディスクドライブ（ＨＤＤ）やフラッシュメモリ等を用いて構成してもよいし、複数のHDDやフラッシュメモリ等を用いて構成してもよい。

テキストデータ収集部１０は、テキストデータを記憶しているテキストデータサーバ２より、ブログ等の記事テキスト（テキストデータ）と、その作成者を示すユーザ識別子、及び記事作成更新日といった属性情報を取得し、テキストデータ記憶部６に保存する。なお、ユーザ識別子とは、テキストデータの作成に関連するユーザ、又は、テキストデータの作成に関連する端末装置、を識別する識別子である。なお、テキストデータ記憶部６は必ずしも必要ではなく、テキストデータサーバ２が、テキストデータ記憶部６の役割を兼ね備えていてもよい。

キーワード集合生成部１１は、不要文字列処理部１４と、キーワード抽出部１５と、グルーピング処理部１６とを有している。キーワード集合生成部１１は、テキストデータ収集部１０によって取得したテキストデータから、アイテムを特定するためのキーワードを抽出し、キーワードグループ（検索キー）を生成する役割を持つ。なお、詳しくは後述するが、このキーワードグループを用いて検索することとなる。
キーワード集合生成部１１の不要文字列処理部１４は、アイテム情報に関係しない不要な情報を除いたテキストデータを生成する。アイテム情報に関係しない不要な情報とは、例えば、文書リンク情報やメタタグなどの情報である。不要文字列処理部１４における処理については後に詳述する。

キーワード集合生成部１１のキーワード抽出部１５は、不要文字列処理部１４によって加工されたテキストデータからキーワードを抽出する。
キーワード集合生成部１１のグルーピング処理部１６は、キーワード抽出部１５によって切り出された１又は複数のキーワードをグループ化して、そのグループ化した、１又は複数のキーワードの集合であるキーワードグループを、キーワードグループ記憶部５へ保存する。なお、１つのキーワードしか含まない場合であってもキーワードグループと称することとする。

アイテム特定部１２は、検索部１７と類似度計算部１８と妥当性判定部１９とを有しており、キーワード集合生成部１１によって生成されたキーワードグループを用いて、アイテムデータベース３からアイテム情報を検索し、その検索結果で得られた複数のアイテム情報間の類似度からキーワードの妥当性を判定する役割を持つ。

アイテム特定部１２の検索部１７は、キーワード集合生成部１１によって生成されたキーワードグループを使用し、アイテムデータベース３を検索する。そして、複数のアイテム情報からなる検索結果セットが得られた場合、アイテム特定部１２の類似度計算部１８は、複数のアイテム情報間の類似度を計算する。さらに、類似度計算部１８は、複数のアイテム情報間の類似度を用いて、キーワードグループ毎に後述する算出式で検索結果セットに関するスコアを求め、スコア記憶部７へ記録する。

アイテム特定部１２の妥当性判定部１９は、類似度計算部１８が算出したスコアと閾値θとを比較して、アイテムデータベース３の検索に使用したキーワードグループの妥当性を判定する。そして、妥当であると判定されたキーワードグループに対応する検索結果セットを用いて、記事テキスト（テキストデータ）に関連するアイテムを特定する。妥当性判定部１９は、その特定したアイテム（アイテム識別子）と、そのキーワードグループを抽出した元のテキストデータのブログ識別子と、を関連付けて、アイテム算出結果記憶部８へ記録する。なお、妥当であると判定されたキーワードグループが複数存在する場合、その中で最もスコアの高いキーワードグループに対応する検索結果セットを用いてアイテムを特定してもよいし、その複数のキーワードグループに対応する複数の検索結果セット全てを用いてアイテムを特定してもよい。

ランキング情報作成部１３は、アイテム算出結果記憶部８のデータを用いて算出したアイテムの出現回数に基づき、順位付け（ランキング）を行い、アイテムランキング情報記憶部９へ記録する。なお、ランキング情報作成部１３を備えていなくともテキストデータにおける記述の対象となっている情報を精度良く特定することができるが、ランキング情報作成部１３を備えることで、テキスト情報処理装置１による解析結果をより有用な形式で出力することができる。

なお、テキスト情報処理装置１は、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ネットワークインターフェース等を備える一般的なコンピュータを用いて構成してもよい。すなわち、後に説明するような処理を行うプログラムをコンピュータに実行させることにより、テキスト情報処理装置１として機能するようにしてもよい。

また、テキスト情報処理装置１を複数のコンピュータを用いて構成してもよい。例えば、負荷分散をするために、テキスト情報処理装置１のある処理ブロックに相当するコンピュータを複数台用いて、すなわち、同じ処理ブロックを備える複数台のコンピュータを用いて分散処理を行なうようにしてもよい。また、テキスト情報処理装置１の一部の処理ブロックをあるコンピュータで実施し、他の処理ブロックを別のコンピュータで実施する形態で分散処理を行なってもよい。

テキスト情報処理装置１の具体的な処理について、図２に示すテキストデータの一例と、図３に示すフローチャートと、図４〜９に示すデータ構成図とを用いて詳細に説明する。

以下では、楽曲に関する記事テキスト（テキストデータ）に基づいて、その楽曲を示すアイテム情報を特定し、その特定したアイテム情報に基づくランキング情報を作成する例について説明する。なお、前述のように、アイテムは楽曲に限らず、様々なコンテンツ、物品、サービスであってもよい。

図３に、テキスト情報処理装置１の処理フローを示す。
ステップＳ１において、テキストデータ収集部１０が、テキストデータサーバ２からテキストデータを取得し、その取得したテキストデータをテキストデータ記憶部６に格納する。

具体的には、テキストデータ収集部１０は、テキストデータサーバ２に対して、所定のリクエストコマンドを送信することで、ユーザ識別子、記事テキスト（テキストデータ）、及び記事作成更新日などを含むブログデータを受信（取得）する。この受信したデータをテキストデータ記憶部６のテキストデータテーブルに格納する。
この際に、テキストデータ収集部１０は、記事テキスト１件につき１つの識別情報（ブログ識別子）を付与する。テキストデータテーブルの格納形式の一例を図５に示す。ブログ識別子、ユーザ識別子、記事テキスト、及び記事作成更新日（例えばアップロードした日時）が関連付けられて格納される。例えば、ユーザが一度のアップロードでテキストデータサーバ２に送信したテキストデータ毎にブログ識別子が付されることとなる。

本実施形態におけるブログ識別子の表記は、記事作成更新日の順に、「BlogID」という文字列＋アンダースコア記号（_）＋数字の連番とするが、ユーザID＋数字の連番としてもよいし、記事取得日時＋数字の連番としてもよい。それぞれのブログデータを一意に特定できればよい。なお、テキストデータサーバ２が、ブログ識別子（またはブログ識別子に相当するデータ）を備えており、テキストデータ収集部１０が、そのデータを受信（取得）する場合は、テキストデータ収集部１０においてブログ識別子を付与する処理を省略し、受信したブログ識別子を利用してもよい。

ブログデータの読み込みは、必要な記事作成更新日の範囲（期間）をリクエストコマンドで指定して、それに対応するデータを取得してもよい。同様に、リクエストコマンドで必要なユーザ識別子を指定して、そのユーザの記事データのみを取得してもよい。また、リクエストコマンドに文字列に関する検索式を含め、記事テキストに特定の文字列パターンが含まれるブログデータのみを取得してもよい。

（キーワード集合生成部１１の動作）
図３に戻り、ステップＳ２〜ステップＳ５にて、キーワード集合生成部１１によるキーワード集合生成処理が実行される。

まず、ステップＳ２において、キーワード集合生成部１１は、テキストデータ記憶部６のテキストデータテーブルからブログ識別子毎のテキストデータを読み出す（取得する）。これ以降の処理においては、各々のテキストデータを対象にして処理を行う。

ステップＳ３において、不要文字列処理部１４は、テキストデータの先頭から末尾までの文字の内、アイテムの特定に役立たない文字列（不要文字列ＦＷと呼ぶ）を、所定の区切り記号Ｋに置換する。例えば「\\」といった、記事テキストに出現する可能性が少ない記号（複数の記号の組合せも含む）を区切り記号Ｋにするとよい。不要な文字列は置換せずに削除したり、空白文字（例えば、スペース記号、タブ記号など）に置換してもよいが、区切り記号Ｋに置換する方が、アイテムの特定に使用する文字列の切り出しに役立つため、好ましい。なお、所定の区切り記号Ｋは、常に同じ記号を使う必要はなく、テキストデータに応じて、適宜、変更してもよい。例えば、テキストデータの言語種別や文字種別に応じて、区切り記号を変えてもよい。

ここで、図２及び図５を用いて、ステップＳ３の不要文字列処理部１４による処理の詳細について説明する。
なお、図２はアイテム情報の特定に使用する記事テキスト（テキストデータ）の一例を示す図である。図２の例では、テキストデータの先頭Ｓから末尾Ｅまでの間に、1つ以上の通常文字列Ｗと、特定記号ＴＫと、不要文字列ＦＷとを含む。ただし、特定記号ＴＫと不要文字列ＦＷは必ずしもあるとは限らない。また、特定記号ＴＫと不要文字列ＦＷは複数存在する場合がある。キーワード抽出部１５によって、特定記号ＴＫと不要文字列ＦＷ以外の通常文字列Ｗを抽出することになるが、この抽出方法については後述する。なお、１文字の場合も文字列と称することとする。また、通常文字列Wは、アイテムの特定に役立つ可能性のある文字列であり、例えば、テキストデータの中の特定記号ＴＫと不要文字列ＦＷ以外の文字列である。

また、図５はテキストデータ記憶部６に格納されるデータ（テキストデータテーブル）の一例を示す図である。図５に示すように、テキストデータテーブルには、記事テキストと、記事テキストに付与されたブログ識別子と、記事テキストをアップロードしたユーザを示すユーザ識別子と、記事テキストをアップロードした更新日を示す記事作成更新日とが関連付けて格納される。図５の記事テキストに示すように、ブログなどのユーザが作成する様々なテキストでは、使われる単語や表現形式が非常に多様になる。

また、一般的には、アイテムの特定に役立つ文字列と、不要な文字列が混在している。図５に示す例において、「#NowPlaying」は、楽曲や映像コンテンツの再生に係わる記事であることを慣用的に示す文字列である。これは、どのアイテムに関する記事においても、同一の文字列になるため、アイテムの特定に役立たず、不要文字列ＦＷになる。

また、例えばTwitterなどの比較的短い記事テキストがアップロードされることが多いサービス（マイクロブログサービス）におけるテキストでは、他サイトへのリンクを示すＵＲＬ（Uniform Resource Locator）が頻繁に含まれているが、このＵＲＬの文字列にはアイテム名等が含まれていないことが多いので、アイテム特定に役立たないため、「http://」などで始まるＵＲＬ文字列を不要な文字列として扱う。なお、特に短縮ＵＲＬの文字列にはアイテム名等が含まれていないことが多いので、短縮ＵＲＬのときのみ不要文字列ＦＷと扱うようにしてもよい。

また、アイテム名が含まれていないことが多い、メタタグ（「<」と「>」とで囲まれている文字列）や、音符（♪）などのマークについても不要文字列ＦＷとして扱う。これらは、半角、全角いずれであってもよい。
不要文字列処理部１４は、不要文字列ＦＷの一覧表や、不要文字列ＦＷとすべき文字列の条件等を記憶したデータベースを参照して、テキストデータに上記の不要文字列ＦＷが含まれるか否かを判断する。不要文字列処理部１４は、所定の区切り記号Ｋに置き換える。

不要文字列処理部１４によって、不要な文字列を空白文字（例えば、スペース記号、タブ記号など）に置き換えるのではなく、ブログ記事等で使用される可能性の少ない所定の記号に置き換えることにより、アイテムの特定に役立つキーワードを精度よく抽出することができる。
例えば、図４（Ａ）に示すような「Ｍ１：タイトル，Ｍ２：空白，Ｍ３：ＵＲＬ，Ｍ４：空白，Ｍ５：アーティスト（姓），Ｍ６：空白，Ｍ７：アーティスト（名），Ｍ８：#NowPlaying」というパターンの記事テキストがあった場合、図４（Ｂ）に示すように、不要文字列ＦＷであるＭ３：ＵＲＬやＭ８：#NowPlayingを空白文字に置換すると、アイテムの特定に役立つキーワードである文字列Ｍ５と文字列Ｍ７との間に空白が入っていた場合、文字列Ｍ５と文字列Ｍ７とを１つのキーワードとして扱うか否かの判別は難しくなる。

つまり、文字列Ｍ５：アーティスト（姓）と、文字列Ｍ７：アーティスト（名）とを１つのキーワードとして抽出した方がアイテムの特定には有利であるが、不要文字列ＦＷを空白へと置換した場合は、そのような文字列の統合が難しい。
これに対して、図４（Ｃ）のように、不要文字列ＦＷであるＭ３：ＵＲＬやＭ８：#NowPlayingを区切り記号Ｋ（本図の例では「\\」）に置換すれば、空白を無視してこの区切り記号Ｋでテキストデータを区切ればよいため、文字列Ｍ５と文字列Ｍ７とを統合して、１つのキーワードとして扱うことができ、より精度良くアイテムを特定できる。なお、不要文字列ＦＷの文字数に係らず、「\\」に置き換えるようにしているが、不要文字列ＦＷを構成する文字それぞれを「\\」に置き換えてもよい。

なお、前述の特許文献１記載の除外文字や句読点等についても不要文字列ＦＷとして扱うことができる。特許文献１記載の除外文字とは、例えば、「の」、「が」、「い」及び「く」などである。

次に特定記号について説明する。本実施形態で対象としている、楽曲再生中に係わるテキストデータでは、楽曲名とアーティスト名を記述する順序やフォーマットに明確なルールは存在しないが、図２や図５のテキストデータに示すように、ハイフン「-」 又は、スラッシュ「/」をテキストとアーティストを区切る記号として用いていることが多い。本実施形態では、この記号を特定記号ＴＫと称する。テキストデータの中に、特定記号ＴＫが存在する場合もあるし、存在しない場合もある。

不要文字列処理部１４によって不要文字列ＦＷを所定の区切り記号Ｋに置き換える処理を行う場合、この特定記号ＴＫをそのまま残してもよいし、不要文字列ＦＷとして区切り記号Ｋに置き換えてもよい。特定記号の前後は、楽曲名やアーティスト名などアイテムの特定に役立つ文字列が存在する可能性が比較的高いため、特定記号ＴＫを残して利用することにより、精度よくキーワード抽出が行える場合がある。一方、特定記号ＴＫを区切り記号Ｋに置換することにより、キーワード抽出処理を簡略化できる。

また、テキストデータにおける記述の対象であるアイテムのアイテム情報が日本語である場合、そのアイテム情報（例えば、音楽コンテンツであれば、日本語のタイトル、日本語のアーティスト名など）に空白文字が含まれる可能性が比較的低いという特徴を利用して、テキストデータが日本語の場合、空白文字を全て区切り記号に置換してもよい。あるいは、日本語の場合、空白文字を削除し、空白文字の前後の文字列をつなげる処理をしてもよい。
以上が、不要文字列処理部１４による処理の詳細である。

図３の説明に戻り、ステップＳ４では、キーワード抽出部１５が、キーワードを抽出する。区切り記号Ｋを区切りとして、先頭Ｓから最初の区切り記号Ｋの一つ前の文字までのテキスト領域と、区切り記号Ｋに挟まれたテキスト領域と、最後の区切り記号Ｋの次の文字から文末Ｅまでのテキスト領域とに分割し、これらのテキスト領域に含まれる文字列をそれぞれキーワードとする。なお、区切り記号Ｋに挟まれたテキスト領域は複数存在することが多い。 また、特定記号ＴＫを利用する場合は、特定記号ＴＫと区切り記号Ｋの間、または特定記号ＴＫと先頭Ｓの間、または特定記号ＴＫと文末Ｅの間のいずれかのテキスト領域に含まれる文字列を優先的にキーワードとしてもよい。このような処理を行うことにより、キーワード抽出の精度をさらに高めることができる。
また、不要文字列処理部１４によって不要文字列ＦＷを空白文字に置換する処理を行っていた場合は、テキストデータを空白文字の位置で区切ってキーワードを抽出する。

なお、テキスト領域の文字種（漢字、ひらがな、カタカナ、アルファベット、数字等）を判定して、キーワードに空白文字を含めるか否かを決定してもよい。例えば、テキスト領域が主にアルファベットの文字種で構成されている場合は、空白の前後の文字列をつなげる処理を行わずに、空白を含めた前後の文字列を１つのキーワードとして抽出する。例えば、図４（Ｃ）に示す例では「Ｍ５アーティスト（姓），Ｍ６空白，Ｍ７アーティスト（名）」を１つのキーワードとして抽出する。
一方、主に、漢字、ひらがな、カタカナで構成されている場合は、空白の前後の文字列をつなげる処理を行った上で、前後の文字列を１つのキーワードとして抽出する。例えば、図４（Ｃ）に示す例では「Ｍ５アーティスト（姓），Ｍ７アーティスト（名）」を１つのキーワードとして抽出する。

なお、キーワードの先頭Ｓおよび末尾Ｅは、空白文字にならないようにすることが好ましい。また、空白文字をキーワードに含めない場合は、特定記号に最も近い空白以外の文字列をキーワードとして抽出することが好ましい。

また、特定の長さの文字列のみをキーワードにしてもよい。例えば、５文字以上１５文字以下の文字列をキーワードにする等の基準（条件）を設けて、キーワードを抽出してもよい。このようにする場合、文字種に応じて、キーワードにする文字列の長さの条件を変えてもよい。例えば、アルファベットを使った文字列では、１つの単語の文字列が多くなる傾向があるので、非空白文字と空白文字を合わせた長さが７文字以上２０文字以下である場合に、キーワードとするといった条件を設定してもよい。

また、漢字が多く含まれる文字列の場合は、キーワードとする文字列の長さを他の文字種の場合と比較して短めに設定して、２文字以上１０文字以下といった条件を設定してもよい。また、特定記号ＴＫを利用する場合は、特定記号に隣接するテキスト領域と、特定記号から離れた位置にあるテキスト領域とで、キーワード抽出の条件を変えてもよい。例えば、特定記号に隣接するテキスト領域では、キーワードとする文字列の長さの条件を緩くし（例えば、３文字以上２０文字以下）、特定記号から離れた位置にあるテキスト領域では、文字列の長さの条件を厳しく（例えば、６文字以上１２文字以下）する等の処理をしてもよい。

以上のようにして、ステップＳ４にて、１つの記事テキストから例えばＪ個（Ｊ≧１）のキーワードが抽出される

次のステップＳ５では、ステップＳ４で作成した記事テキスト毎のキーワードを使用して、グルーピング処理部１６が、１つの記事テキスト毎に、キーワードグループを作成する。
キーワードの数が１つ（Ｊ＝１）である場合は、１つのキーワードグループが作成される。キーワードが複数（Ｊ≧２）の場合は、基本的に複数のキーワードグループを作成する。１つのキーワードグループに含めるキーワードの数は、１以上の任意の数である。
ここでは、図２に示すテキストデータから抽出された４つのキーワードＫ１，Ｋ２，Ｋ３，Ｋ４を例に、キーワードグループの作成方法を説明する。

まず、１つのキーワードグループにつき１つのキーワードを含むように、キーワードグループを作成した場合について説明する。このような場合もキーワードグループと称することとする。
グルーピング処理部１６は、キーワードＫ１，Ｋ２，Ｋ３，Ｋ４それぞれを、それぞれ別のキーワードグループとする。そして、作成したキーワードグループに、それぞれを識別可能なキーワードグループ識別子を付与し、図７に示すような形式で、キーワードグループ記憶部５に格納する。なお、図７は、図２に示すテキストデータに基づいた検索キーワードグループテーブルの例である。

グルーピング処理部１６は、キーワードＫ１，Ｋ２，Ｋ３，Ｋ４に、キーワードグループ識別子Gr001-001、Gr001-002、Gr001-003、Gr001-004をそれぞれ付与する。この例において、キーワードグループ識別子のハイフン「-」より前の部分は、ブログ識別子によって決まる文字列であり、「Gr001」は、「BlogID_001」と対応する。あるいは、キーワードグループ識別子の前半にブログ識別子を直接用いて、「BlogID_001-001」などとしてもよい。また、キーワードグループ識別子のハイフン「-」より後の部分は、数字の連番であるが、作成順の数字の連番としてもよいし、記事取得日時＋数字の連番としてもよい。そして、グルーピング処理部１６は、キーワードグループ識別子と、ブログ識別子と、キーワードグループに含まれるキーワードとを対応させて格納する。

次に、１つのキーワードグループにつき２つのキーワードを含むように、キーワードグループを作成した場合について説明する。

グルーピング処理部１６は、４つのキーワードから２つのキーワードを選ぶ組合せである、「Ｋ１とＫ２」，「Ｋ１とＫ３」，「Ｋ１とＫ４」，「Ｋ２とＫ３」，「Ｋ２とＫ４」，「Ｋ３とＫ４」の６つのキーワードグループを作成する。
図７に示す例では、グルーピング処理部１６は、「Ｋ１とＫ２」，「Ｋ１とＫ３」，「Ｋ１とＫ４」，「Ｋ２とＫ３」，「Ｋ２とＫ４」，「Ｋ３とＫ４」に、キーワードグループ識別子Gr001-005、Gr001-006、Gr001-007、Gr001-008、Gr001-009、Gr001-010をそれぞれ付与する。
１つのキーワードグループに複数のキーワードが存在する場合、各キーワードを空白文字で連結した１つの文字列として格納してもよいし、各キーワードを分離して読み出せる形式で格納してもよい。

本実施形態のように、アイテムが楽曲である場合、アイテムの特定には、楽曲名とアーティスト名の２つの文字列が役立つ場合が多い。よって、２つのキーワードを含むキーワードグループであると、記述の対象となっている情報を精度良く特定することができることが多い。ただし、１つのキーワードグループにつき１つのキーワードを含むように、キーワードグループを作成した場合よりもキーワードグループの数が多くなり、処理量は多くなる。

なお、グルーピング処理部１６によって、第１の数（図７の例では１つ）のキーワードを含むキーワードグループと、第１の数よりも大きい第２の数（図７の例では２つ）のキーワードを含むキーワードグループとの両方を作成すると、後述のように、処理量を抑えながら、記述の対象となっている情報を精度良く特定することができる。なお、図７には示していないが、検索キーワードグループテーブルに、優先度又は優先順位を保持する列を追加し、キーワードグループそれぞれに優先度（優先順位）を付与してもよい。そして、後述のステップＳ６において、優先度（優先順位）に従って、アイテムデータベース３を検索してもよい。すなわち、まず優先度が最も高いキーワードグループを用いて検索を行った後、次に優先度が２番目に高いキーワードグループを用いて検索を行う等の処理を行ってもよい。

優先度（優先順位）を付与する方法としては、それぞれのキーワードが、文字列の長さや文字種などに関するキーワード基準（条件）をどの程度満たしているかの度合いを用いることができる。また、特定記号ＴＫの近くの文字列から抽出されたキーワードの優先度を高くする処理を行ってもよい。

（アイテム特定部１２の動作）
図３に戻り、ステップＳ６にて、アイテム特定部１２の検索部１７は、キーワードグループ記憶部５に格納されているキーワードグループテーブルから、順次キーワードグループを読み出し、キーワードグループごとに検索式を作成して、アイテムデータベース３に検索リクエストを送信する。

本実施形態におけるアイテムデータベース３は、図６に示すような構成のアイテムテーブルを格納している。アイテムデータベース３は、検索リクエストを受信すると、アイテムテーブルを検索し、タイトル列およびアーティスト列のうちの少なくとも一方が、検索リクエストで指定された条件（検索式）に合致した場合に、そのアイテムの情報（タイトル、アーティスト名など）をテキスト情報処理装置１に送信する。なお、テキスト情報処理装置１に送信する情報にアイテム識別子を含めてもよい。
また、ベクトル空間モデル等の検索モデルを用いれば、アイテム情報に検索キーワードが含まれない場合であっても、そのアイテム情報を検索出力とすることも可能である。アイテム特定部１２の検索部１７は、検索リクエストに含まれる検索式に基づく、アイテム情報のリストを取得する。

１つの検索式（１回の検索）に対応して、アイテムデータベース３から取得できるデータ（アイテム情報のリスト）を、検索結果セット（検索結果リスト）と称する。検索式に合致するアイテムが存在する場合、検索結果セットには、１つ又は複数のアイテム情報が含まれている。なお、検索により取得されたアイテム情報を単に「検索結果」とも称する。
また、本実施形態におけるアイテムデータベース３は、検索式の中でＡＮＤ又はＯＲ条件が明示されずに、複数のキーワードが指定された場合、複数のキーワードがＡＮＤ条件で結合されたものとして解釈する。また、アイテムデータベース３は、検索式に合致するアイテムが複数存在する場合、優先順位を付けて検索結果を送信してもよい。例えば、優先順位の最も高いアイテムを１番目の検索結果とし、優先順位が２番目に高いアイテムを２番目の検索結果とし、以下同様に検索結果の順番を決めてもよい。

ここで、優先順位は、検索式とアイテム情報とが合致する度合いを用いて算出されてもよいし、アイテムの人気度を用いて算出されてもよい。例えば、検索結果として出力する回数をアイテムごとにカウントし、この回数を人気度とし、人気度の高いアイテムの優先順位を高くする処理を行ってもよい。また、外部から取得可能な、アイテムの利用回数、アイテムの売り上げ金額などの情報を用いて人気度を算出してもよい。また更に、テキスト情報処理装置１が、アイテムデータベース３に対して、後述するランキング情報に基づき、アイテムごとの人気度を算出し、この情報を定期的にアイテムデータベース３に提供し、アイテムデータベース３が優先順位の決定に用いてもよい。
このように、検索部１７とアイテムデータベース３とが協働して検索処理を行うようにしているが、どちらかが単独で行ってもよい。

検索部１７は、１回の検索につき、１つのキーワードグループを用いる。また、キーワードグループが複数のキーワードを含む場合は、それらを使ってＡＮＤ条件となるように、検索式を作成する。１つの検索式に使われるキーワードの集合を検索キーと称する。本実施形態においては、キーワードグループが検索キーに相当する。また、検索式にＡＮＤ又はＯＲ条件が含まれず、検索式が１つ以上のキーワードのみで構成されている場合は、検索式と検索キーは等価であるといえる。
例えば、１つのキーワードのみが含まれるキーワードグループで検索を行った場合は、タイトルおよびアーティストの内の少なくとも一方にそのキーワードが含まれるアイテム情報（ここでは、タイトルとアーティスト名）が出力される。

図７に示すように、キーワードグループ識別子Gr001-001のキーワード「歌」のみのキーワードグループで検索した場合、タイトルやアーティスト名に「歌」が含まれる検索結果が出力される。例えば、「愛の歌／Ｚ山 Ｔ朗」，「卒業の歌／Ｙバンド」，「歌ソング／Ｃ＆Ａ」，「春歌／Ａバンド」，「夏歌／Ａバンド」などを含む、タイトルとアーティスト名のリストが、検索結果として出力される。

また、（Ｋ１，Ｋ２）の２つのキーワードがキーワードグループに含まれる場合、（Ｋ１ ＡＮＤ Ｋ２）といった検索式を作成する。つまり、タイトルかアーティストの内の少なくともどちらかにキーワードＫ１が含まれ、かつ、タイトルかアーティストの内の少なくともどちらかにキーワードＫ２が含まれるアイテムを示す情報が出力される。
例えば、図７に示すように、キーワードグループ識別子Gr001-006の「歌」及び「Ａバンド」が含まれるキーワードグループで検索した場合、タイトルやアーティスト名に「歌」が含まれ、かつ、タイトルやアーティスト名に「Ａバンド」が含まれる検索結果が出力される。例えば、「春歌／Ａバンド」及び「夏歌／Ａバンド」という、タイトルとアーティスト名のリストが出力される。

次のステップＳ７において、アイテム特定部１２は、検索結果セットに含まれる各アイテム情報の正規化を行う。この正規化は、アイテムデータベース３が、実質的に同じアイテムを別々の検索結果として返すことがあるため、これに対応する処理として行う。アイテムが楽曲である場合、実質的に同じ楽曲であっても、複数パターンの曲名表記が使われている場合がある。

例えば、アイテムデータベース３が１つの楽曲「タイトルＡ／アーティストＢ」に関して、「タイトルＡ（version Ｃ）／アーティストＢ］、「タイトルＡ／アーティストＢ（featuring Ｘ）」、「タイトルＡ／アーティストＢ with Ｘ」などの複数の検索結果を返す場合がある。特に、多数のユーザが作成、提供した楽曲情報をもとにアイテムデータテーブルが作成されている場合には、このような現象が起こりやすい。アイテム情報の正規化を行うことにより、上記のような楽曲表記のバリエーションを１つにまとめることが可能になる。具体的には、検索結果セットに含まれる各アイテム情報（タイトルおよびアーティスト名）の文字列に対して、所定の文字列を消去したり、文字種の変換を行って正規化文字列を作成したりする。例えば、括弧で囲われた文字列（「（」と「）」とで囲われた文字列）を削除してもよい。

また、「featuring」、「with」などアーティスト名を補足するのに多用される文字列をあらかじめ登録しておき、検索結果のアーティスト名からその文字列以降を消去してもよい。また、半角カタカナを全角カタカナに、全角アルファベットを半角アルファベットに、全角数字を半角数字に等の文字種の変換処理を行ってもよい。正規化処理は必ずしも行わなくてもよいが、このような検索結果の正規化処理を行うことで、テキストデータとアイテムとをさらに精度良く対応付けることができる。

次にステップＳ８では、アイテム特定部１２は、ステップＳ７で作成された正規化されたアイテム情報を用いて、検索結果セットに含まれるアイテム情報間それぞれの類似度計算を行い、算出結果の平均値をスコアとして算出する。そして、算出したスコアをキーワードグループ識別子に対応させて、図８に示す検索結果スコアテーブルのスコア列に格納する。なお、検索した結果、該当するアイテムが見つからなかった場合（検索結果セットが空集合の場合）、そのキーワードグループについてのスコアは格納されない。

次に、スコア算出方法について説明する。例えば、検索結果セットとして、（１）「春歌／Ａバンド」、（２）「Ａソング／Ａバンド」、及び（３）「夏歌／Ａバンド」の３つのアイテム情報が出力された場合は、（１）「春歌／Ａバンド」と（２）「Ａソング／Ａバンド」との類似度、（１）「春歌／Ａバンド」と（３）「夏歌／Ａバンド」との類似度、（２）「Ａソング／Ａバンド」と（３）「夏歌／Ａバンド」との類似度、の３つの類似度を算出する。そしてこの３つの類似度の平均値をスコアとして算出してもよい。このように、検索結果セットに含まれるアイテム情報の全ての組合せについて類似度を算出すると、スコアを精度よく算出することができるが、処理量は多くなる。

また、検索結果セットの中のアイテムから１つの基準アイテム（基準検索結果）を選び、その基準アイテムと、検索結果セットの中の他のアイテムとの類似度を算出し、それらの平均値をスコアとして算出してもよい。例えば、（１）「春歌／Ａバンド」を基準アイテムとし、（１）「春歌／Ａバンド」と（２）「Ａソング／Ａバンド」との類似度、（１）「春歌／Ａバンド」と（３）「夏歌／Ａバンド」との類似度、の２つの類似度を算出し、それらの平均値をスコアとしてもよい。このようにすると、検索結果セットに含まれるアイテム情報の全ての組合せについて類似度を算出する場合と比べ、スコアの精度は低下するが、処理量は少ない。検索結果セットに含まれるアイテム情報が多い場合には、基準アイテムを使う方法が望ましい。

検索結果セットに２つのアイテム情報しか含まれない場合は、その２つのアイテム情報間の類似度をそのままスコアとして用いればよい。また、検索結果セットに１つのアイテム情報しか含まれない場合には、類似度およびスコアの計算処理は行わず、その検索結果セットのアイテム情報をブログ識別子に対応付けるようにしてもよい。

類似度計算には種々の方法を用いることができる。例えば、正規化された検索結果Ｎ件（Ｎ≧２）を対象に、形態素解析処理を行い、単語を抽出する。この際に、名詞や形容詞など特定の品詞を抽出対象としたり、助詞や助動詞を除外する等の処理を行ってもよい。合計でＭ種類の単語（１〜Ｍ語）が抽出できた場合、検索結果（アイテム情報）を行列の行に、単語を列に対応させて、ある検索結果にある単語が出現する頻度（回数）を行列要素とするＮ×Ｍ生起行列を作成する。あるいは、行列要素を、ある検索結果にある単語が出現した場合に「１」、出現しない場合に「０」としてもよい。
以下では、生起行列の要素をｄijと表わす（i＝１〜Ｎ、j＝１〜Ｍ）。iは行列のi番目の行、jは行列のj番目の列を示す。

ここで、Ｎ件全ての組み合わせについて類似度を算出してもよいが、処理を簡便化するために、生起行列のＮ行の中から１つの行を基準検索結果（基準アイテム）として選び、基準検索結果と他の検索結果（他の行）との類似度を算出する。基準検索結果は、乱数を使ってランダムに選択してもよいが、本実施形態では１行目の検索結果（アイテムデータベース３が最初に出力したアイテム情報）を基準検索結果とする。

本実施形態において、類似度の計算には、下記の数１に示す式に示すとおりコサイン類似度を使用する。基準検索結果をk番目の行とすると、基準検索結果とi番目の検索結果（i番目の行）との類似度Ｓikは、数１に示す式で求められる。ただし、i＝１〜Ｎ、i≠k、j＝１〜Ｍである。

本実施形態においては、コサイン類似度を使用するが、類似度算出の式はこれに限らない。例えば、公知のＪａｃｃａｒｄ係数、Ｓｉｍｐｓｏｎ係数、ピアソン積率相関係数などを用いて類似度を算出してもよい。また、形態素解析を用いて単語を抽出するのではなく、検索結果同士を文字単位で比較して類似度を算出してもよい。例えば、２つの正規化された検索結果に対して、それぞれ先頭からｐ番目の文字が一致するか否かを判定し、それを用いて類似度を算出してもよい。また、レーベンシュタイン距離等、一般的に文字列の類似度として用いられている尺度を算出してもよい。

そして、１つの検索結果セットにつき得られる類似度の平均値を算出して、スコアとする。例えば、Ｎ件（Ｎ≧３）の検索結果が得られた場合、基準検索結果と、他の（Ｎ−１）件の検索結果との間の類似度が（Ｎ−１）個算出される。この（Ｎ−１）個の類似度の平均値を算出すればよい。なお、ここでは、類似度の平均値を算出してスコアとするが、類似度の最小値、平均値、中央値、最頻値、四分位値などを算出してスコアとしてもよい。このスコアが大きければ大きい程、複数の検索結果が類似していることを意味する。また、１つの検索結果セットから算出された複数の類似度の内、所定値以上であった類似度の個数をカウントし、その個数を、類似度計算の対象とした検索結果セットに含まれるアイテム数Ｎや、その検索結果セットから算出された類似度の個数で割った値をスコアとして用いてもよい。

ブログ記事で使われる一般的な単語と、楽曲のタイトルで使われる単語は、重なっていることが多く、事前にルールを作っておいて、これらを区別することが難しい。このため、抽出されたキーワードには、アイテムとは関係ない一般的な単語が入る場合もある。

キーワードが一般的な単語である場合、それを使ってアイテムデータベース３を検索すると、１つの楽曲ではなく、複数の楽曲に関する検索結果が返ってくる可能性が高い。例えば、「愛」といった一般的な単語を楽曲名に含む楽曲は多いため、「愛」を検索キーにしてアイテムデータベース３を検索すると、複数の楽曲に関する検索結果が得られる可能性が非常に高い。このような場合、多様な検索結果が得られ、検索結果どうしの類似度は低くなり、スコアも低い値となる。

一方、キーワードが、ある１つの楽曲に特有の語句であったり、一般的な使用頻度が低い語句であったりする場合、検索結果が複数であっても、実質的には１つの楽曲に関することが多い。この場合は、検索結果どうしの類似度が高くなり、スコアも高い値となる。従って、上述した方法でスコアを算出することにより、検索に用いたキーワード（キーワードグループ）によって、１つのアイテムが特定できたか否かを的確に判定することができる。

次のステップＳ９にて、アイテム特定部１２の妥当性判定部１９は、スコアが所定の閾値θより大きいかどうかを判定する。θの値は、あらかじめ試験的に収集した検索結果を用いて設定してもよいし、状況に応じて設定値を変更してもよい。妥当性判定部１９は、スコアがθ以上であれば、アイテム特定に結び付くキーワードグループであると判断してステップＳ１０に移って真を返すと共に、検索結果セットの中からブログ記事と対応させるアイテムの候補である候補アイテムを選択し、図８に示す検索結果スコアテーブルの「候補アイテムのアイテム識別子」列に、候補アイテムのアイテム識別子を登録する。スコアがθより小さければ、アイテム特定に結び付くキーワードグループではないと判断してステップＳ１１に移って偽を返す。

ここで、図８は、キーワードグループ識別子Gr001-001 〜Gr001-010のキーワードグループのスコアを示す検索結果スコアテーブルを示すものである。検索結果スコアテーブルはスコア記憶部７に格納される。
閾値θを「０．４」とすると、図８の例では、３つのキーワードグループGr001-006、 Gr001-008、Gr001-010が閾値θ以上のスコアとなっている。スコアが閾値以上となったキーワードグループについては、検索結果セットの内の一のアイテム識別子が関連付けられる。なお、キーワードグループに含まれるキーワード数に応じて閾値θを変更してもよい。この場合、キーワード数が多いほど大きな閾値（真となりにくい閾値）を用いるとよい。検索結果セットの中から一のアイテム（候補アイテム）を選択する方法としては、以下の方法を用いることができる。

第１の方法は、アイテムデータベース３が検索結果として出力する最初（１番目）のアイテム（検索部１７が最初に取得したアイテム）を選択する方法である。この方法は、アイテムデータベース３が、優先順位付きの検索結果を出力する場合に用いることができる。テキスト情報処理装置１は、取得した検索結果の順番の情報を記憶しておく。

第２の方法は、キーワードグループ（検索キー）と、それに基づく検索結果それぞれとの類似度を算出して、類似度が最も高かった検索結果（アイテム）を選択する方法である。例えば、「Ａソング」と「Ａバンド」が含まれるキーワードグループGr001-010については、キーワード「Ａソング」及び「Ａバンド」と、各検索結果である「Ａソング／Ａバンド」，「Ａソングsingle ver.／Ａバンド」，「Ａソング／ＡバンドwithT」それぞれとの類似度を算出する。ここでの類似度は、２つの文字列を１文字単位で比較するタイプの方法を用いて算出するとよい。この例の場合、検索結果「Ａソング／Ａバンド」が最も類似度が高くなるため、妥当性判定部１９は、この「Ａソング／Ａバンド」を候補アイテムとして決定し、図６に示すアイテムテーブルを参照しながら、「Ａソング／Ａバンド」のアイテム識別子であるＡ００１を特定し、検索結果スコアテーブルのキーワードグループ（Gr001-010）に対応する候補アイテム識別子として登録する。なお、類似度の代わりに、キーワードグループと検索結果それぞれとの差（違いの度合い）や距離を算出してもよい。

第３の方法は、ステップＳ７で正規化されたアイテム情報と、正規化する前のアイテム情報との差が最も小さいアイテムを選択する方法である。例えば、アイテムデータベース３が、（１）「Ａソング／Ａバンド」、（２）「Ａソングsingle ver.／Ａバンド」、（３）「Ａソング／ＡバンドwithT」の３つのアイテムを出力し、これらを正規化した結果が全て、「Ａソング／Ａバンド」となった場合、正規化の前後で文字列が変わらない（１）「Ａソング／Ａバンド」を選択する。

第４の方法は、後述するランキング情報を利用し、過去に作成されたランキング情報の順位が最も高いアイテムを選択する方法である。過去にブログ記事に多く登場したアイテムほど、新たなブログ記事にも登場する可能性が高いためである。

次のステップＳ１２にて、妥当性判定部１９は、全てのキーワードグループについて妥当性の判定を行ったか判断し、まだ妥当性を行っていないキーワードグループがあれば、ステップＳ９に戻り、次のキーワードグループのスコアと閾値とを比較する。ステップＳ１２にて、全てのキーワードグループについて妥当性の判定が終わっていた場合は、次のステップＳ１３に移る。なお、このステップＳ１２において、全てのキーワードグループについて妥当性判定を行ったかを判定するのではなく、妥当性判定の結果が真となったキーワードグループが１つ存在した時点で、次のステップＳ１３に移ってもよい。こうすることで計算負荷が低減される。

次のステップＳ１３において、アイテム特定部１２の妥当性判定部１９は、妥当性判定の結果が真であったアイテム識別子とブログ識別子とを、検索結果スコアテーブルに基づき、図９に示すようなアイテム算出結果記憶部８が備えるアイテム算出結果テーブルに登録する。このように、妥当性判定部１９は、妥当性判定の結果が真であったアイテム識別子をそのブログ識別子に対応するアイテム情報であると特定している。

なお、図８に示す例においては、閾値以上のスコアとなっているキーワードグループが複数（３つ）存在し、それぞれアイテム識別子（候補アイテム識別子）が関連付けられているが、その中で最もスコアの高いキーワードグループのアイテム識別子を採用して、アイテム算出結果テーブルに登録してもよいし、閾値以上のスコアとなっているキーワードグループ全てのアイテム識別子を登録してもよい。これは、１つのテキストデータにおいて、複数のアイテムが記述されることもあるためである。ただし、アイテムを特定する精度を重視する場合は、最もスコアの高いキーワードグループのアイテム識別子のみを採用した方がよい。なお、スコアの高い順に複数のキーワードグループを選択し、それらに対応する複数のアイテム識別子をアイテム算出結果テーブルに登録してもよい。また、ステップＳ８で算出されたスコアが閾値未満である場合でも検索結果スコアテーブルに候補アイテムを登録するようにした上で、最もスコアの高いキーワードグループに対応する候補アイテムのアイテム識別子をアイテム算出結果テーブルに登録してもよい。

最もスコアの高いキーワードグループのアイテム識別子を採用する場合、図７及び図８に示す例では、ブログ識別子BlogID_001とアイテム識別子Ａ００１とがアイテム算出結果テーブルへ出力される。
以上のようにして、ブログ識別子に対して、記述の対象となっているアイテム識別子を精度良く対応させることができる。なお、上述の説明では、１つの検索結果セットの中から１つの候補アイテムを選択して、検索結果スコアテーブルに登録しているが、１つの検索セットから複数の候補アイテムを選択して登録するようにしてもよい。

以上のようにして特定したアイテムを示す情報を、対応するブログ記事そのものやブログ記事を示す情報（例えばブログ識別子やブログの題名）とともに表示部に表示させる表示制御部２１を備えるようにしてもよい。例えば、アイテム名とともにブログ記事を表示することで、そのアイテムに関する口コミ情報であることがすぐに識別できる。なお、表示部はテキスト情報処理装置１が有する表示部（図示せず）でもよいし、端末装置４が有する表示部（図示せず）でもよい。
また、アイテム名と、そのアイテムに関連付けられた複数のブログ記事とを同じ画面で表示するようにすれば、そのアイテムに関する複数の口コミ情報などが一度に見ることができるため有用である。

（ランキング情報作成部１３の動作）
図３に戻り、ランキング情報作成部１３によって行われる処理について説明する。
ステップＳ１４にて、ランキング情報作成部１３は、図９に示すアイテム算出結果テーブルと、図５に示すテキストデータテーブルと、図６に示すアイテムテーブルとを参照して、アイテム算出結果テーブルに登録されている（ブログ識別子、アイテム識別子）の組み合わせに対応する、アイテム情報（タイトル、アーティストなど）、ユーザ識別子、及び記事作成更新日を抽出する。

ステップＳ１５にて、ランキング情報作成部１３は、アイテム算出結果テーブルにおけるアイテム識別子の出現回数をカウントし、出現回数が多い順（降順）にソートした（アイテム識別子、出現回数）の組み合わせリスト（第１のリスト）を作成し、アイテムランキング情報記憶部９に記憶する。なお、ある１人のユーザがあるアイテムについてのブログ記事を所定回数以上書いていた場合、そのアイテムの出現回数を所定の規則に従って、元の出現回数より少なくするといった処理を追加してもよい。

ステップＳ１６において、ランキング情報作成部１３は、ステップＳ１４で作成したデータを使用し、アイテム算出結果テーブルに登録されているアイテム識別子それぞれについて、ユーザ識別子の種類数（異なるユーザ識別子の出現回数）をカウントする。すなわち、あるアイテムが何人のユーザのブログに記述されているかをカウントする。そして、出現回数が多い順（降順）にソートした（アイテム識別子、ユーザ識別子の種類数）の組み合わせリスト（第２のリスト）を作成し、アイテムランキング情報記憶部９に記憶する。

ステップＳ１７において、ランキング情報作成部１３は、ステップＳ１５で作成した第１のリストと、ステップＳ１６で作成した第２のリストとを用いて、図１０に示す形式のランキングテーブルを作成する。ランキングテーブルは、ランキング情報記憶部９に格納される。ランキングテーブルは、順位と、アイテム識別子と、アイテム識別子の出現回数とを対応させたテーブルであり、種々の方法で作成することができる。

具体的には、まず第１のリストに従って、アイテムの出現回数の多い順にアイテムに順位を付ける。次に、アイテムの出現回数が同じアイテムが存在する場合は、それらのアイテムに関して、第２のリストに従って、ユーザ識別子の種類数が多い順に順位を付ける。すなわち、アイテム識別子の出現回数を第１優先項目、ユーザ識別子の種類数を第２優先項目として、それぞれ多い順にアイテムをソートして、順位を付与すればよい。また、ユーザ識別子の種類数を第１優先項目、アイテム識別子の出現回数を第２優先項目としてソートして、順位を付与してもよい。

なお、上述のランキングテーブル作成方法は、あくまでも一例であり、種々の方法でランキングを作成することができる。例えば、リスト１の出現回数とリスト２のユーザ識別子の種類数とに基づいて、総合点数を算出し、総合点数の多い順に順位を付与してもよい。この総合点数をランキングテーブルに登録してもよい。また、特定したアイテムに係る種々の数値に基づいて統計的な処理を行うようにしてもよい。例えば、複数の集計期間を設定し、それぞれの集計期間でのアイテム出現回数を比較して、出現回数の増減率等を算出し、増加率の高いアイテムに対して、「赤丸急上昇」などの情報を付与するようにしてもよい。

また、表示制御部２１は、以上のようにして作成したランキング等を表示部に表示させてもよい。また、ランキングとともに、そのランキングに含まれるアイテムと関連付けられたブログ記事や、ブログ記事を書いたユーザの情報を表示させてもよい。なお、表示部については、テキスト情報処理装置１が有する表示部（図示せず）でもよいし、端末装置４が有する表示部（図示せず）でもよい。

以上説明したように、本実施形態のテキスト情報処理装置により、ブログ等のテキストデータから商品またはサービスであるアイテムを精度良く抽出することができる。

また、本実施形態のテキスト情報処理装置によれば、抽出したアイテム情報について統計的に処理することができる。

例えば、所定期間（例えば、１週間、１日、１時間など）内においてマイクロブログサービス等で記述の対象となっている曲を抽出し、曲ごとの記事数やユーザ数をカウントし、そのカウント数に従って、曲の順位付けを行うことで、市場動向の統計データとしてマーケティングに活かすことができる。また、ユーザへそれらの情報を提示することで、ユーザの購買意欲を高めたりすることが期待できる。

＜第２実施形態＞
次に図１１及び図１２のフローチャートを用いて、テキスト情報処理装置１における処理の他の実施形態について説明する。
第１実施形態においては、第１の数のキーワードを含むキーワードグループによる検索と、第１の数よりも大きい第２の数のキーワードを含むキーワードグループによる検索の両方を行うか、またはどちらか一方のみを行っていたが、本実施形態においては、アイテムを特定できたか否かに応じて、キーワードグループに含まれるキーワード数を多くしていくことで、処理量を抑えながら、記述の対象となっている情報を精度良く特定することができるように構成したものである。

なお、図１１のフローチャートにおけるステップＳ５ａ，ステップＳ１２ａ，ステップＳ１２ｂ、及び、図１２のフローチャートにおけるステップＳ５ｂ，ステップＳ１２ｃ，ステップＳ１２ｄ以外は第１実施形態と基本的に同様な処理である。よって、第１実施形態と同様な処理については説明を省略する。

本実施形態において、図１１のステップＳ５ａにて、グルーピング処理部１６は、１つの記事テキスト毎に、第１の数のキーワードを含むキーワードグループを作成する。例えば、図７のキーワードグループ識別子Gr001-001 〜Gr001-004のキーワードグループのように、グルーピング処理部１６は、１つのキーワードを含むキーワードグループを作成する。

ステップＳ６〜Ｓ１１については、第１実施形態と同様の方法で、検索結果の妥当性を判断する。
次のステップＳ１２ａにおいて、妥当性判定部１９は、第１の数のキーワードを含むキーワードグループ全てについて妥当性の判定を行ったか判断し、まだ妥当性を行っていないキーワードグループがあれば、ステップＳ９に戻り、次のキーワードグループのスコアと閾値とを比較する。ステップＳ１２ａにて、第１の数のキーワードを含む全てのキーワードグループについて妥当性の判定が終わっていた場合は、次のステップＳ１２ｂに移る。

次のステップＳ１２ｂにおいて、真となったキーワードグループがあったか否か判断し、真となったキーワードグループがあれば、ステップＳ１３に移り、妥当であったキーワードグループとアイテムを出力する。一方、ステップＳ１２ｂにおいて、真となったキーワードグループがなければ、図１２のフローチャートに示すステップＳ５ｂに移る。

図１２のステップＳ５ｂにて、グルーピング処理部１６は、１つの記事テキスト毎に、第１の数よりも大きい第２の数のキーワードを含むキーワードグループを作成する。例えば、図７のキーワードグループ識別子Gr001-005 〜Gr001-010のキーワードグループのように、グルーピング処理部１６は、２つのキーワードを含むキーワードグループを作成する。キーワードグループを作成する処理は、検索処理に比べてシステムの負荷が小さいため、第２の数のキーワードを含むキーワードグループについては予め作成しておくようにしてもよい。

その後、ステップＳ６〜Ｓ１１については、第１実施形態と同様の方法で、検索結果の妥当性を判断する。
次のステップＳ１２ｃにおいて、妥当性判定部１９は、第２の数のキーワードを含むキーワードグループ全てについて妥当性の判定を行ったか判断し、まだ妥当性を行っていないキーワードグループがあれば、ステップＳ９に戻り、次のキーワードグループのスコアと閾値とを比較する。ステップＳ１２ｃにて、第２の数のキーワードを含む全てのキーワードグループについて妥当性の判定が終わっていた場合は、次のステップＳ１２ｄに移る。

次のステップＳ１２ｄにおいて、真となったキーワードグループがあったか否か判断し、真となったキーワードグループがあれば、図１１のステップＳ１３に移り、妥当であったキーワードグループとアイテムを出力する。一方、ステップＳ１２ｂにおいて、真となったキーワードグループがなければ、ステップＳ１８に移り、妥当性判定部１９は、当該記事テキストは、アイテムについて記述していないと判断する。
なお、ステップＳ１８において処理を終了せずに、グルーピング処理部１６は、１つの記事テキスト毎に、第２の数よりも大きい第３の数のキーワードを含むキーワードグループを作成し、同様な処理を続けてもよい。どの程度の数のキーワードを含むキーワードグループまで作成するかは、例えば、特定したいアイテムの種類等に応じて適宜決めればよい。

以上のように、アイテムを特定できたか否かに応じて、キーワードグループに含まれるキーワード数を多くして検索していくことで、処理量を抑えながら、記述の対象となっている情報を精度良く特定することができる

上述した本発明の実施形態は、説明のための例示であり、上記実施形態に限定されるものではない。本発明は、ブログ以外のテキスト、例えばアンケートなどのデータに対しても適用可能である。また、音楽に係わるブログ記事を使って処理を行う例を示したが、音楽だけでなくその他の分野の記事についても、同様に処理できることはもちろんである。

なお、本発明は各部の機能をコンピュータに実現させるためのプログラムを含むものである。これらのプログラムは、記録媒体から読み取られてコンピュータに取り込まれてもよいし、通信ネットワークを介して伝送されてコンピュータに取り込まれてもよい。

また、本発明は以上説明した実施形態に限定されることはなく、本発明の要旨を逸脱しない範囲において種々変更が可能である。例えば、各実施形態や変形例等を組み合わせてもよい。また、テキスト情報処理装置１の一部の構成を別体にし、ネットワーク等を介してその別体とした構成と通信するようにして、テキスト情報処理装置１の機能を実現してもよい。

１ テキスト情報処理装置（サーバ）
２ テキストデータサーバ
３ アイテムデータベース
４ 端末装置
５ キーワードグループ記憶部
６ テキストデータ記憶部
７ スコア記憶部
８ アイテム算出結果記憶部
９ アイテムランキング情報記憶部
１０ テキストデータ収集部
１１ キーワード集合生成部
１２ アイテム特定部
１３ ランキング情報作成部
１４ 不要文字列処理部
１５ キーワード抽出部
１６ グルーピング処理部
１７ 検索部
１８ 類似度計算部
１９ 妥当性判定部
２０ ネットワーク

Claims (13)

1. データベースを検索し、検索条件に対応した複数の情報を取得する検索部と、
   前記複数の情報間の類似度に基づくスコアを計算する類似度計算部と、
   前記スコアに基づいて、前記検索条件の妥当性を判定する妥当性判定部と、
   を備えることを特徴とする情報処理装置。
2. 前記妥当性判定部は、前記スコアが所定値以上である場合に、前記検索条件を妥当であると判定する、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記検索条件は１以上のキーワードを含み、前記妥当性判定部は、前記キーワードの数に応じて、妥当性を判定する基準を変更する、
   ことを特徴とする請求項１または請求項２に記載の情報処理装置。
4. 前記妥当性判定部において前記検索条件が妥当ではないと判定された場合に、前記検索部は、前記検索条件に含まれるキーワードと異なる数のキーワードを含む検索条件を用いて、データベースを検索する、
   ことを特徴とする請求項１から請求項３のいずれか１項に記載の情報処理装置。
5. データベースを検索し、複数の情報からなる検索結果セットを取得する検索部と、
   前記検索結果セットに含まれる複数の情報間の類似度に基づくスコアを計算する類似度計算部と、
   前記スコアに基づいて、前記検索結果セットの妥当性を判定する妥当性判定部と、
   を備えることを特徴とする情報処理装置。
6. 前記妥当性判定部は、前記スコアが所定値以上である場合に、前記検索結果セットを妥当であると判定する、
   ことを特徴とする請求項５に記載の情報処理装置。
7. 前記妥当性判定部は、前記検索結果セットを妥当であると判定した場合に、前記検索結果セットに含まれる少なくとも１つの情報を検索結果として出力する、
   ことを特徴とする請求項５または請求項６に記載の情報処理装置。
8. 前記検索部は、複数の検索条件を用いてデータベースを検索し、複数の情報からなり、前記複数の検索条件それぞれに対応する検索結果セットを複数取得し、
   前記類似度計算部は、前記検索部で取得された複数の検索結果セットそれぞれに対して前記スコアを計算し、
   前記妥当性判定部は、前記スコアに基づいて、前記複数の検索結果セットそれぞれの妥当性を判定し、妥当であると判定した検索結果セットのうち前記スコアが高い検索結果セットに含まれる情報を優先的に検索結果として出力する、
   ことを特徴とする請求項５から請求項７のいずれか１項に記載の情報処理装置。
9. 前記類似度計算部は、検索結果セットに含まれる２つの情報の組合せに対応する類似度を複数算出し、その複数の類似度のうちの所定値以上の類似度の数に基づいて、前記スコアを計算する、
   ことを特徴とする請求項１から請求項８のいずれか１項に記載の情報処理装置。
10. １または複数のコンピュータが実行する情報処理方法であって、
    データベースを検索し、検索条件に対応した複数の情報を取得する検索ステップと、
    前記検索ステップにおいて取得した前記複数の情報間の類似度に基づくスコアを計算する類似度計算ステップと、
    前記類似度計算ステップで計算された前記スコアに基づいて、前記検索条件の妥当性を判定する妥当性判定ステップと、
    を含むことを特徴とする情報処理方法。
11. １または複数のコンピュータが実行する情報処理方法であって、
    データベースを検索し、複数の情報からなる検索結果セットを取得する検索ステップと、
    前記検索ステップにおいて取得された前記検索結果セットに含まれる複数の情報間の類似度に基づくスコアを計算する類似度計算ステップと、
    前記類似度計算ステップで計算された前記スコアに基づいて、前記検索結果セットの妥当性を判定する妥当性判定ステップと、
    を含むことを特徴とする情報処理方法。
12. １または複数のコンピュータを、
    データベースを検索し、検索条件に対応した複数の情報を取得する検索部、
    前記検索部において取得した前記複数の情報間の類似度に基づくスコアを計算する類似度計算部、
    前記類似度計算部で計算された前記スコアに基づいて、前記検索条件の妥当性を判定する妥当性判定部、
    として機能させることを特徴とする情報処理プログラム。
13. １または複数のコンピュータを、
    データベースを検索し、複数の情報からなる検索結果セットを取得する検索部、
    前記検索部において取得された前記検索結果セットに含まれる複数の情報間の類似度に基づくスコアを計算する類似度計算部、
    前記類似度計算部で計算された前記スコアに基づいて、前記検索結果セットの妥当性を判定する妥当性判定部、
    として機能させることを特徴とする情報処理プログラム。

Images