JP2019139746A - 情報検索システムおよび方法 - Google Patents

Abstract

【課題】情報検索の効率と使い勝手を向上できるようにした情報検索システムおよび方法を提供すること。【解決手段】情報検索システム１は、問合せに対する対応履歴を格納する対応履歴格納部Ｔ１１と、入力情報に基づく検索クエリに対応する所定の対応履歴を対応履歴格納部Ｔ１１から取得する対応履歴取得部Ｐ１３２と、所定の対応履歴に基づいて検索クエリを補正する検索クエリ補正部Ｐ１１４と、補正された検索クエリに基づいて対応履歴格納部Ｔ１１に格納された対応履歴を検索し、検索結果を出力する検索部Ｐ１１５を備える。【選択図】図１

Description

本発明は、情報検索システムおよび方法に関する。

顧客からの問合せに回答するコールセンタ等では、顧客への対応結果を記録しており、新たな問合せがあった場合に、回答者は、過去の類似事例を検索し、その検索結果を参考にして回答する。過去の事例の検索には、指定されたキーワードが含まれる事例を検索する全文検索の他に、問合せ文に類似する文書が含まれる事例を検索する概念検索が用いられる。

一つの従来技術（特許文献１）として、「Ｑ＆ＡシステムのＱ＆Ａサイトに質問者が質問文書を入力し、回答者が当該質問に応じた回答文書を入力する。その後、質問文書だけでなく、比較的質問事象に対して詳しい知識を有する回答者が作成した回答文書をも対象として複合的に文書解析を行い、検索インデックスを作成する。そして、該検索インデックスを用いて検索アルゴリズムを実行させ、データベース内に含まれる文書群に対して検索処理を行う。これにより、回答文書から直接ベストの回答を得られなくとも、データベースに潜在している有益な文書を抽出することができる。」ことが知られている。

また、他の従来技術（特許文献２）として、「テキストデータベース中のテキストに存在する特徴文字列のそのテキストにおける出現頻度を出現頻度ファイルとして格納するステップと、ユーザが指定したテキストから特徴文字列を抽出するステップと、ユーザが指定したテキストにおける特徴文字列の出現頻度を計数するステップとを有し、出現頻度ファイルとユーザが指定したテキストにおける出現頻度を用いてユーザが指定したテキストに対する類似度を算出し、算出された類似度を用いて文書を検索する。」ことが知られている。

さらに、別の従来技術（特許文献３）として、「質問文と回答文との対を含む事例が記憶された事例データベースと、事例の質問文に含まれるキーワードの重要度を質問文の対の回答文同士の類似度を用いて計算し、重要度に基づいて、問い合わせ文に対する回答を絞り込む為の絞込みキーワードを前記キーワードから選択する絞込みキーワード選択手段とを有する質問回答検索システム」が知られている。

特開２０１０−２１１５６３号公報 特開平１１−１４３９０２号公報 特開２０１０−９４７１号公報

従来技術では、質問文に類似する回答文書を抽出するだけであり、その質問文の前に存在する質問文に対する対応履歴まで考慮して検索するものではない。比較的簡単な内容の場合は、一回の質問とそれに対する一回の回答とで終了することもあるが、複雑な内容の場合または状況の切り分けが難しい場合等では、回答者と質問者との間で何度もやり取りをする必要がある。

質問者と回答者の間で質問文および回答文といった情報が複数回交換される場合、最新の質問文には過去の質問文に含まれていた情報が欠落することがある。例えば、問題の生じたシステム名称、問題の発生した状況などのように、質問対象の案件の背景、前提または経過を示す情報が欠落する。この場合、担当者は、その案件についての今までの履歴を探し出し、その履歴を考慮して検索クエリを作成しなければ、適切な回答を検索することができない。

本発明は上記の課題に鑑みてなされたもので、その目的は、情報検索の効率と使い勝手を向上できるようにした情報検索システムおよび方法を提供することにある。

上記課題を解決すべく、本発明の一つの観点に従う情報検索システムは、情報を検索する情報検索システムであって、問合せに対する対応履歴を格納する対応履歴格納部と、入力情報に基づく検索クエリに対応する所定の対応履歴を対応履歴格納部から取得する対応履歴取得部と、所定の対応履歴に基づいて検索クエリを補正する検索クエリ補正部と、補正された検索クエリに基づいて対応履歴格納部に格納された対応履歴を検索し、検索結果を出力する検索部と、を備える。

本発明によれば、検索クエリに対応する所定の対応履歴により当該検索クエリを補正することができるため、対応履歴を用いて検索クエリを自動的に補うことができ、この結果、情報検索の効率と使い勝手が向上する。

事例問合せシステムの全体構成図。 事例問合せシステムの検索実行部の機能構成図。 検索実行部の処理を示すフローチャート。 検索文受付部の処理を示すフローチャート。 文書検索部の処理を示すフローチャート。 対応履歴取得部の処理を示すフローチャート。 クエリ補正部の処理を示すフローチャート。 対応履歴文書検索部の処理を示すフローチャート。 検索結果表示部の処理を示すフローチャート。 結果リランキング部の処理を示すフローチャート。 有用情報登録部の処理を示すフローチャート。 対応履歴格納部の構成を示す説明図。 図１２に続く説明図。 対応履歴文書格納部の構成を示す説明図。 図１４に続く説明図。 補正前の検索クエリの説明図。 補正後の検索クエリの説明図。 対応コード格納部の構成を示す説明図。 有用情報格納部の構成を示す説明図。 利用者属性格納部の構成を示す説明図。 検索前の画面を示す説明図。 検索結果を表示する画面を示す説明図。 検索結果の詳細を表示する画面を示す説明図。 検索結果の詳細を表示する他の画面を示す説明図。 第２実施例に係り、対応コード格納部の構成を示す説明図。 クエリ補正部の処理を示すフローチャート。 補正後の検索クエリの構成を示す説明図。 第３実施例に係る事例検索システムの全体構成図。 第４実施例に係る事例検索システムの全体構成図。 対応履歴格納部の構成を示す説明図。 対応コード格納部の構成を示す説明図。

以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態では、後述のように、担当者（回答者）が検索したときの対応履歴（行動履歴）を取得して保存しておき、保存した対応履歴を次回以降の検索に利用する。

すなわち、本実施形態では、担当者と顧客（質問者）との情報交換を対応履歴として記憶しておき、対応履歴を検索する際には、記憶された対応履歴を用いて検索クエリを補正し、補正された検索クエリにより対応履歴を検索する。

これにより本実施形態によれば、問題解決の参考となる過去の対応履歴を、現在の案件の対応履歴で補正した検索クエリによって効率的かつ的確に検索できる。したがって、本実施形態によれば、担当者と顧客との情報交換の回数を削減したり、１回の情報交換に要する時間を短縮したりすることができ、担当者の単位時間当たりの対応可能案件の数を増加させることができる。

以後の説明では「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ（Ｄａｔａｂａｓｅ）」、（ａａａは任意の文字列）等の表現にて本実施例の情報を説明するが、これら情報は必ずしもその形式で情報が保存されている必要は無く、テーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」等について「ａａａ情報」と呼ぶことがある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）」という表現を用いるが、これらについてはお互いに置換が可能である。

また、本実施例に例示する情報には、不図示のフィールドが含まれていてもよいし、幾つかのデータフィールドが別のＤＢに分割して登録されていてもよいし、幾つかのデータフィールドが存在しなくてもよい。

また、本実施例に例示する処理フローには、不図示の処理ステップが含まれていてもよいし、いくつかの処理ステップが存在しなくてもよい場合もあり、いくつかの処理ステップの実行順序が入れ替わっていてもよい。

また、以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリおよび通信ポート（通信制御デバイス）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。

また、各種プログラムは、プログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。この場合、プログラム配布サーバは、プロセッサと記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムを記憶する。そして、配布プログラムをプロセッサが実行することで、プログラム配布サーバのプロセッサは、配布対象のプログラムを他の計算機に配布する。

なお、本発明は後述する実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例および同等の構成が含まれる。例えば、実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。

ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。ある実施例の構成に他の実施例の構成を加えてもよい。各実施例の構成の一部について、他の構成を追加したり、削除したり、置換したりしてもよい。

後述する各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ、Ｂｌｕｅ Ｒａｙ Ｄｉｓｋ、その他の光ディスク等の記録媒体に格納されていればよい。また、全てが同一の記憶媒体に格納されている必要はなく、幾つかのプログラム、テーブル、ファイルが別の記憶媒体に格納されていてもよいし、通信ネットワークを介して接続される不図示の装置の記憶媒体に格納されていてもよい。

制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

計算機は入出力装置を有する。入出力装置の例としてはディスプレイと、キーボードと、ポインタデバイスと、タブレット端末と、スマートフォンとが考えられるが、これ以外のデバイスであってもよい。また、入出力デバイスの代替としてシリアルインタフェースやイーサーネットインタフェースを入出力デバイスとし、当該インタフェースにディスプレイまたはキーボードまたはポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力装置での入力および表示を代替してもよい。なお、以後インタフェースのことをＩ／Ｆと記述することがある。

計算機は通信Ｉ／Ｆを有する。通信Ｉ／Ｆの例としては、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）接続端子と、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）の接続端子と、無線通信の接続装置と、が考えられるが、これら以外のデバイスであってもよい。また、通信ネットワークには有線ネットワークと無線ネットワークとが考えられるが、どちらの通信ネットワークであってもよい。

図１〜図２４を用いて第１実施例を説明する。まず最初に、本実施例で使用する用語の定義を説明する。

「問合せ」とは、質問者からコールセンタ等に寄せられた質問文や障害情報等の情報である。「問合せ」には、最初に寄せられる質問だけでなく、追加の質問、および一連の対応の中で寄せられる質問に関連する情報も含まれる。

「問合せ文」とは、問合せの内容が書かれた文書情報である。

「対応」とは、事例検索システムを使用する担当者が顧客である質問者からの質問に対して最終的な回答を出すために、情報を交換することである。例えば、顧客に対する状況の確認、補足情報の要求、関連部署への質問の転送等を含む。

「案件」とは、顧客からの問合せ単位を示し、最初の情報交換から問題解決に至った情報交換までをひとまとまりに扱うものである。

「案件番号」とは、案件ごとに一意に振られる番号である。

「クエリ」とは、担当者が事例検索システムに入力した質問文に基づいて生成される検索式の情報である。検索クエリとも呼ぶ。

「事例」とは、完了した案件である。

「対応履歴」とは、過去の問合せについての顧客（質問者）と担当者および関連部署との情報交換の内容をすべて記録した履歴情報である。

「対応履歴文書」とは、対応履歴を一つのテキストファイルとしてまとめた情報であり、案件ごとに作成される。

「資料」とは、障害発生時にシステムまたはアプリケーションが出力する、ログまたはエラーメッセージ等の情報の総称である。

図１は、第１実施例にかかる「情報検索システム」の一例としての事例検索システム１の全体構成を示す。

事例検索システム１は、例えば、「計算機」の例である事例検索サーバ１０と、情報出力装置１７と、情報入力装置１８とを備えており、通信ネットワークＣＮを介して、顧客である質問者の端末２０に接続されている。以下、質問者を顧客とも呼ぶ。事例検索システム１は、例えば、コールセンタ等から利用される。事例検索システム１は、コールセンタ等の施設内に設けることができる（いわゆるオンプレミス）。あるいは、事例検索システム１を通信ネットワーク上に配置し、一つまたは複数のコールセンタから利用されるように構成することもできる（いわゆるクラウド）。

情報出力装置１７は、例えば、ディスプレイ装置である。情報出力装置１７は、ディスプレイ装置に限らず、例えば、プリンタまたは音声合成装置またはロボットなどの他の情報出力装置を備えてもよい。情報入力装置１８は、例えば、キーボード、マウス等のポインティングデバイスである。情報入力装置１８は、キーボードに限らず、例えば、音声認識装置、視線検出装置、動作検出装置などの他の情報入力装置を備えてもよい。情報出力装置１７および情報入力装置１８は、タッチパネルのように一体化させてもよい。

事例検索サーバ１０に接続された操作端末（不図示）を、情報出力装置１７および情報入力装置１８として用いることもできる。事例検索システム１は、複数の顧客からの問合せ（質問とも呼ぶ）に対応することができる。複数の担当者は、事例検索システム１を用いて、それぞれの顧客に対応することができる。

顧客は、端末２０を用いて事例検索システム１にアクセスし、電子メールまたはチャットを介して質問することができる。文字による情報交換に限らず、音声認識システムを用いることにより、顧客または担当者の音声を文字に自動変換して電子ファイルとして記憶してもよい。図示は省略するが、複数の端末２０が通信ネットワークＣＮを介して事例検索サーバ１０に同時にアクセスすることができる。

事例検索サーバ１０の構成を説明する。事例検索サーバ１０は、例えば、マイクロプロセッサ（ＣＰＵ）１１と、メモリ１２と、補助記憶装置（図中、ディスク）１３と、ネットワークインターフェース（Ｉ／Ｆ）１４と、記憶媒体ドライブ１５とを備えており、それら各回路１１〜１５はバス１６によって相互に接続されている。

マイクロプロセッサ１１は、メモリ１２に格納された後述のコンピュータプログラムを実行することにより、事例検索サーバ１０としての各機能を実現する。マイクロプロセッサ１１は、コンピュータプログラムの実行に際して、補助記憶装置１３に格納された後述の各情報Ｔ１１〜Ｔ１５を使用する。

メモリ１２は、例えばＲＯＭ（Read Only Memory）およびＲＡＭ（Random access memory）から構成される。メモリ１２には、例えば、検索実行部Ｐ１１と有用情報管理部Ｐ１２と対応履歴管理部Ｐ１３と対応履歴文書登録部Ｐ１４といったコンピュータプログラムと、オペレーティングシステム（ＯＳ）Ｐ１５とを格納している。メモリ１２には、マイクロプロセッサ１１により使用されるワークエリアＷＡも設けられている。

検索実行部Ｐ１１は、検索を行うコンピュータプログラム群である。検索実行部Ｐ１１は、例えば、問合せ文を受け付ける問合せ文受付部Ｐ１１１と、検索結果を顧客端末２０および／または情報出力装置１７へ表示させる検索結果表示部Ｐ１１２と、対応履歴を検索する文書検索部Ｐ１１３とを含む。

文書検索部Ｐ１１３は、検索クエリを補正する「検索クエリ補正部」としてのクエリ補正部Ｐ１１４と、対応履歴文書を検索する対応履歴文書検索部Ｐ１１５と、結果リランキング部Ｐ１１６とを含む。対応履歴文書検索部Ｐ１１５は、図２８で後述する対応履歴検索部Ｐ１１５Ｂと共に「検索部」の一例である。

有用情報管理部Ｐ１２は、対応履歴が有用であるか評価した有用情報を管理するコンピュータプログラム群である。有用情報管理部Ｐ１２は、例えば、対応履歴に対応づけて有用情報を事例検索システム１に登録する有用情報登録部Ｐ１２１と、対応履歴に対応づけられて登録された有用情報を取得する有用情報取得部Ｐ１２２とを含む。

対応履歴管理部Ｐ１３は、対応履歴を管理するコンピュータプログラム群である。対応履歴管理部Ｐ１３は、対応履歴を事例検索システム１へ登録する対応履歴登録部Ｐ１３１と、登録された対応履歴を取得する対応履歴取得部Ｐ１３２とを含む。

補助記憶装置１３は、例えば、ハードディスクまたはフラッシュメモリデバイス等の不揮発性の大容量記憶装置として構成される。補助記憶装置１３は、例えば、対応履歴格納部Ｔ１１と、対応コード格納部Ｔ１２と、対応履歴文書格納部Ｔ１３と、有用情報格納部Ｔ１４と、利用者属性格納部Ｔ１５とを格納する。

対応履歴格納部Ｔ１１は、対応履歴登録部Ｐ１３１からの対応履歴を記憶する。対応コード格納部Ｔ１２は、対応履歴に対応づけるコード情報を記憶する。対応履歴文書格納部Ｔ１３は、対応履歴文書登録部Ｐ１４により生成される対応履歴文書を記憶する。有用情報格納部Ｔ１４は、有用情報登録部Ｐ１２１からの有用情報を記憶する。利用者属性格納部Ｔ１５は、対応履歴を参照して回答する担当者の属性を記憶する。

ネットワークインターフェース１４は、通信ネットワークＣＮに接続して通信するインターフェースである。事例検索サーバ１０は、ネットワークインターフェース１４から通信ネットワークＣＮを介して顧客端末２０に接続される。

記憶媒体ドライブ１５は、例えばハードディスクまたはフラッシュメモリ等の外部記憶媒体ＭＭを読み書きする装置である。外部記憶媒体ＭＭに固定されたコンピュータプログラムＰ１１〜Ｐ１５または情報Ｔ１１〜Ｔ１５を記憶媒体ドライブ１５から読み込んで、メモリ１２または補助記憶装置１３に記憶させることができる。あるいは、メモリ１２または補助記憶装置１３に記憶されたコンピュータプログラムＰ１１〜Ｐ１５または情報Ｔ１１〜Ｔ１５の少なくとも一部を、記憶媒体ドライブ１５を用いて外部記憶媒体ＭＭへ書き込み、固定することもできる。

図２は、検索実行部Ｐ１１の機能構成を示す。担当者は、電子メールまたはチャット等の情報伝達手段を通じて顧客からの問合せを受けると、情報入力装置１８から事例検索サーバ１０へ問合せ文を入力する。

検索実行部Ｐ１１の問合せ文受付部Ｐ１１１は、担当者から「入力情報」としての問合せ文（最初の検索文と呼ぶこともできる）を受け付けると、文書検索部Ｐ１１３のクエリ補正部Ｐ１１４へ問合せ文を引き渡す。

対応履歴取得部Ｐ１３２は、クエリ補正部Ｐ１１４からの要請により、問合せ文に対応する所定の対応履歴を対応履歴格納部Ｔ１１から取得すると共に、所定の対応履歴に対応づけられているコード情報を対応コード格納部Ｔ１２から取得する。対応履歴取得部Ｐ１３２は、取得した所定の対応履歴およびコード情報をクエリ補正部Ｐ１１４へ送る。所定の対応履歴とは、例えば、問合せ文と同一の案件番号を持つ対応履歴である。

クエリ補正部Ｐ１１４は、対応履歴取得部Ｐ１３２から受領した所定の対応履歴およびコード情報に基づいて、入力された問合せ文から得られる検索クエリ（当初の検索クエリ）を補正する。詳細は後述するが、クエリ補正部Ｐ１１４は、所定の対応履歴を当初の検索クエリに加えることにより当初の検索クエリを補正し、対応履歴文書検索部Ｐ１１５に引き渡す。

対応履歴文書検索部Ｐ１１５は、補正後の検索クエリを用いて、対応履歴文書格納部Ｔ１３に格納された対応履歴文書を検索し、その検索結果を出力する。対応履歴文書とは、関連する複数の対応履歴の本文を一つのファイルとして連結させたものである。

「検索結果並び替え部」としての結果リランキング部Ｐ１１６は、有用情報取得部Ｐ１２２が有用情報格納部Ｔ１４から取得した有用情報に基づいて、対応履歴文書検索部Ｐ１１５の検索結果を評価し、有用情報の値が高い順番に対応履歴を並べ替える。

有用情報の値は、対応履歴を評価した利用者（担当者）の属性により変化させることができる。例えば、経験の豊富な担当者が「参考になった」と評価する場合、その対応履歴の有用情報の値を高くすることができる。そこで、有用情報取得部Ｐ１２２は、有用情報格納部Ｔ１４から所定の対応履歴ごとの有用情報を取得すると共に、それら有用情報を設定した利用者（対応履歴を参照した担当者）の属性（立場、階級、スキルレベル等）を利用者属性格納部Ｔ１５から取得する。

有用情報取得部Ｐ１２２は、例えば、所定の対応履歴に設定された有用情報のうち、所定のスキルレベルや所定の階級を持つ利用者が設定した有用情報の数を算出し、その値を有用情報の値として用いることができる。あるいは、有用情報取得部Ｐ１２２は、所定の対応履歴に設定された各有用情報に利用者属性から定まる値をそれぞれ乗じ、乗算した値の合計値を有用情報の値として用いることもできる。

検索結果表示部Ｐ１１２は、結果リランキング部Ｐ１１６から並べ替えた後の検索結果を受領すると、顧客端末２０に送信して表示させる。検索結果は、情報出力装置３に出力してもよい。

図３は、検索実行部Ｐ１１の処理を示すフローチャートである。上述の通り、検索実行部Ｐ１１は、問合せ文受付部Ｐ１１１で受付けた問合せ文を用いて（Ｓ１１）、文書検索部Ｐ１１３により対応履歴文書を検索させ（Ｓ１２）、その検索結果を検索結果表示部Ｐ１１２に表示させる（Ｓ１３）。

図４は、問合せ文受付部Ｐ１１１の処理を示すフローチャートである。問合せ文受付部Ｐ１１１は、情報入力装置１８から入力された問合せ文を取得する（Ｓ２１）。問合せ文受付部Ｐ１１１は、取得した問合せ文の案件番号を取得する（Ｓ２２）。

案件番号は、担当者が手動で問合せ文と一緒に入力してもよいし、あるいは、問合せ文をキーとして対応履歴を検索し、一致する対応履歴の持つ案件番号を取得してもよい。さらには、問合せ文に一致する対応履歴の持つ案件番号の一覧を表示し、その中から担当者に選択させてもよい。

問合せ文受付部Ｐ１１１は、入力された問合せ文と案件番号とから、最初の検索に使用するクエリ（当初の検索クエリ）を作成する（Ｓ２３）。問合せ文受付部Ｐ１１１は、作成したクエリを文書検索部Ｐ１１３へ送信する（Ｓ２４）。

図５は、文書検索部Ｐ１１３の処理を示すフローチャートである。文書検索部Ｐ１１３は、問合せ文受付部Ｐ１１１から受領した当初の検索クエリをクエリ補正部Ｐ１１４により補正させる（Ｓ３１）。

文書検索部Ｐ１１３は、対応履歴文書検索部Ｐ１１５により補正後のクエリを用いて対応履歴文書を検索させる（Ｓ３２）。文書検索部Ｐ１１３は、結果リランキング部Ｐ１１６により検索結果を有用情報の値に基づいて並べ替えさせる（Ｓ３３）。

図６は、対応履歴取得部Ｐ１３２の処理を示すフローチャートである。対応履歴取得部Ｐ１３２は、当初の検索クエリと同一の案件番号を持つ対応履歴（所定の対応履歴）が対応履歴格納部Ｔ１１に存在するか判定する（Ｓ４１）。すなわち、対応履歴取得部Ｐ１３２は、当初の検索クエリの案件番号と同一の案件番号を持つ案件の履歴が対応履歴格納部Ｔ１１に記憶されているか確認する。

対応履歴取得部Ｐ１３２は、当初の検索クエリと同一の案件番号を持つ対応履歴を発見すると（Ｓ４１：ＹＥＳ）、その対応履歴の本文（書誌的事項を除いた部分）を対応履歴格納部Ｔ１１から取得する（Ｓ４２）。当初の検索クエリと同一の案件番号を持つ対応履歴を発見できなかった場合（Ｓ４１：ＮＯ）、本処理は終了する。

図７は、クエリ補正部Ｐ１１４の処理を示すフローチャートである。クエリ補正部Ｐ１１４は、当初の検索クエリの案件番号を対応履歴取得部Ｐ１３２に引き渡して呼び出す（Ｓ５１）。

クエリ補正部Ｐ１１４は、当初の検索クエリの案件番号と同一の案件番号（図７中において該当案件番号）を持つ対応履歴を対応履歴取得部Ｐ１３２が取得できたか判断する（Ｓ５２）。対応履歴取得部Ｐ１３２により該当案件番号を持つ対応履歴を取得できた場合（Ｓ５２：ＹＥＳ）、クエリ補正部Ｐ１１４は、該当案件番号を持つ対応履歴の本文を取得する（Ｓ５３）。

クエリ補正部Ｐ１１４は、ステップＳ５３で取得した本文を当初の検索クエリに追加することにより、当初の検索クエリを補正する（Ｓ５４）。クエリ補正部Ｐ１１４は、該当案件番号を持つ他の本文が未だ存在するか判定する（Ｓ５５）。クエリ補正部Ｐ１１４は、他の本文が存在する場合（Ｓ５５：ＹＥＳ）、ステップＳ５３に戻り、他の本文を検索クエリにさらに追加する（Ｓ５４）。

該当案件番号を持つ対応履歴を取得できない場合（Ｓ５２：ＮＯ）、および該当案件番号を持つ他の対応履歴の本文（他の本文）が存在しない場合（Ｓ５５：ＮＯ）、本処理は終了する。

図８は、対応履歴文書検索部Ｐ１１５の処理を示すフローチャートである。対応履歴文書検索部Ｐ１１５は、例えば、クエリ補正部Ｐ１１４で補正されたクエリを用いて対応履歴文書格納部Ｔ１３を概念検索し、ヒットした対応履歴文書の案件番号をスコアが高い順にソートして返す（Ｓ６１）。

図９は、検索結果表示部Ｐ１１２の処理を示すフローチャートである。検索結果表示部Ｐ１１２は、検索文を画面に表示し（Ｓ７１）、リランキングした検索結果を取得する（Ｓ７２）。

検索結果表示部Ｐ１１２は、ステップＳ７２で取得した検索結果の中に、次の案件番号が存在するか判定する（Ｓ７３）。次の案件番号が存在しない場合（Ｓ７３：ＮＯ）、本処理を終了する。

検索結果表示部Ｐ１１２は、次の案件番号が存在すると判定すると（Ｓ７３：ＹＥＳ）、ステップＳ７２で取得した検索結果の中から案件番号を一つ取得する（Ｓ７４）。検索結果表示部Ｐ１１２は、対応履歴格納部Ｔ１１を参照し、ステップＳ７４で取得した案件番号と一致する案件の中からコード”Ｑ１”の本文を取得する（Ｓ７５）。コード”Ｑ１”は、図１２で示すように、「顧客からの問合せ」を意味する。

さらに検索結果表示部Ｐ１１２は、対応履歴格納部Ｔ１１を参照し、ステップＳ７４で取得した案件番号と一致する案件の中からコード”ＡＺ”の本文およびその日時を取得する（Ｓ７６）。コード”ＡＺ”とは、「顧客への最終回答」を意味する。

検索結果表示部Ｐ１１２は、案件番号と、コード”ＡＺ”に対応する日時と、コード”Ｑ１”の本文と、コード”ＡＺ”の本文とを画面に表示させる（Ｓ７７）。

対応履歴格納部Ｔ１１の作成手順を説明する。

（手順１）対応履歴は、コールセンタ等の業務の中で作成される。

（手順２）コールセンタ等の担当者（回答者）は、顧客から問合せの第一報を受けると、事例検索システム１にユーザＩＤを用いてログオンし、問合せ内容を事例検索システム１に登録する。担当者は、例えば、顧客からの問合せの内容を本文とし、対応コード（図１２参照）と発信元とを一緒に登録する。

（手順３）事例検索システム１は、対応履歴登録部Ｐ１３１を呼び出して、案件番号と経過Ｎｏ．と日時とを合わせて、対応履歴格納部Ｔ１１に記憶させる。「案件番号」には、直前の番号に「１」を加えた値が採用される。すなわち、対応履歴登録部Ｐ１３１が、直前に登録されている案件番号に「１」を加えたものを採番する。「経過Ｎｏ．」には１が設定される。「日時」には、登録日時を設定する。登録日時は、コンピュータ内のタイマから取得することができる。なお、顧客からの問合せが電子メール等で届く場合には、電子メールを受信したタイミングで、上述のように問合せ内容を自動的に対応履歴格納部Ｔ１１に登録してもよい。

（手順４）担当者は、顧客への回答、顧客に対する詳細の確認、顧客に対する資料の要求や、問合せ対象の製品の開発元部署等の関連部署へ問合せをする場合、その都度、事例検索システム１を用いて問合せ本文とコードとを対応履歴格納部Ｔ１１に記憶する。その際、経過Ｎｏは自動的に一つずつ増加する。

対応履歴文書格納部Ｔ１３の作成手順を説明する。

（手順１）対応履歴文書格納部Ｔ１３の本文は、対応履歴格納部Ｔ１１に記憶された案件のうち同一案件番号の本文をつなげた文書である。一連の対応履歴の本文をつなげた文書（対応履歴文書）は、検索実行部Ｐ１１による概念検索の対象となる。

（手順２）対応履歴文書登録部Ｐ１４は、例えば一日に一回、対応履歴格納部Ｔ１１を確認する。対応履歴文書登録部Ｐ１４は、対応履歴文書格納部Ｔ１３に記憶されていない案件番号が存在し、かつ、その案件番号の案件中にコード”ＡＺ”が存在する場合（すなわち最終回答まで到達している案件である場合）に、該当の案件番号の本文を結合し、該当の案件番号と結合した本文とを対応履歴文書格納部Ｔ１３に記憶する。

（手順３）なお、対応履歴文書登録部Ｐ１４は、一日に一回に限らず、任意のタイミングで処理を実行してもよい。例えば、コードＡＺが対応履歴格納部Ｔ１１に記憶されたタイミング等である。また、現在進行中の案件も検索対象に追加するのであれば、コードの値は無視して作成してもよい。

（手順４）対応履歴文書登録部Ｐ１４をあらかじめ作成しなくてもよい。すなわち、検索実行部Ｐ１１が概念検索を実行するタイミングで、ワークエリアＷＡに対応履歴文書格納部Ｔ１３相当の情報を作成してもよい。

（手順５）対応履歴文書には、担当者と顧客とのやり取りだけではなく、例えばマニュアル等の技術文書またはノウハウ集等のドキュメントも合わせて登録して、検索対象としてもよい。そのようにすることで、担当者はより正確な情報にアクセスでき、結果として対応時間がより短くなる。

図１０は、結果リランキング部Ｐ１１６の処理を示すフローチャートである。まず最初に、結果リランキング部Ｐ１１６は、結果集合に検索結果が１件以上存在するかを判断する（Ｓ８１）。検索結果が存在する場合（Ｓ８１：ＹＥＳ）、ステップＳ８２へ進み、存在しなければ（Ｓ８１：ＮＯ）、ステップＳ８６へ進んで本処理を終了する。

結果リランキング部Ｐ１１６は、結果集合から検索結果を１件取り出し（Ｓ８２）、取得した検索結果の案件番号が、有用情報格納部Ｔ１４に記憶されている案件番号と一致する判断する（Ｓ８３）。案件番号同士が一致すれば（Ｓ８３：ＹＥＳ）、ステップＳ８４へ進み、そうでなければ（Ｓ８３：ＮＯ）、ステップＳ８１へ戻る。

結果リランキング部Ｐ１１６は、有用情報格納部Ｔ１４の案件番号に対応する登録者ＩＤを取得し、取得した登録者ＩＤについて利用者属性格納部Ｔ１５を探索し、登録者のロールがリーダであるか判定する（Ｓ８４）。結果リランキング部Ｐ１１６は、登録者が「リーダー」である場合（Ｓ８４：ＹＥＳ）、ステップＳ８５へ進み、そうでなければステップＳ８２へ戻る。

なお、ロール条件だけに限らず、複数の条件をＡＮＤまたはＯＲでつなげて判断してもよい。また、「ロール」の代わりに、「レベル」のような数値を利用者属性格納部Ｔ１５に登録し、例えば「レベルが３以上か」といった判断をしてもよい。

結果リランキング部Ｐ１１６は、検索結果のスコアを１つインクリメントし（Ｓ８５）、ステップＳ８２へ戻る。

このように処理を進めた結果、最終的にステップＳ８１で「ＮＯ」と判定されると、結果リランキング部Ｐ１１６は、修正されたスコアの高い順に検索結果集合をソートする（Ｓ８６）。

図１１は、有用情報登録部Ｐ１２１の処理を示すフローチャートである。有用情報登録部Ｐ１２１は、図２３に示す事例検索システム画面例（詳細表示）Ｇ１（３）の「参考になった」ボタンＢ３１を押されたタイミングで起動する。

有用情報登録部Ｐ１２１は、検索結果画面（詳細表示）Ｇ１（３）に表示された案件番号を取得し（Ｓ９１）、さらにボタンＢ３１を押したユーザのユーザＩＤを取得する（Ｓ９１）。そして、有用情報登録部Ｐ１２１は、取得した案件番号およびユーザＩＤを有用情報格納部Ｔ１４へ記憶させる（Ｓ９３）。

図１２および図１３は、対応履歴格納部Ｔ１１の記憶内容の例を示す。対応履歴格納部Ｔ１１は、例えば、「案件番号」、「経過Ｎｏ．」、「日時」、「発信元」、「コード」、「本文」を対応づけて管理する。図１２において、「発信元」は、担当者（図中、「コールセンタ」）または顧客のいずれかである。

図１４および図１５は、対応履歴文書格納部Ｔ１３の記憶内容の例である。対応履歴文書は、同一案件番号を持つ各対応履歴の本文をつなげることで生成される。

図１６は、補正前の検索クエリの例を示す。

図１７は、補正後の検索クエリの例を示す。補正前の検索クエリでは、図１７の下側に示すように、顧客からの情報提供（コードＱＬ）のみであった。これに対し、補正後の検索クエリでは、図１７の上側に示すように、顧客からの問合せ（コードＱ１）と、担当者から顧客への情報提供依頼（コードＡＬ）とをさらに含む。このように本実施例では、顧客からの最新の問合せだけで過去の事例を検索するのではなく、その案件の過去の一連の情報から抽出される情報を追加することで検索クエリを補正する。

図１８は、対応コード格納部Ｔ１２の記憶内容の例を示す。コードは、対応履歴の内容を分類するためにあらかじめ用意されている。

コードＱ１は、顧客からの問合せであることを示す。コードＡＬは、顧客への情報提供依頼であることを示す。コードＱＬは、顧客からの情報提供であることを示す。コードＡＸは、顧客への連絡であることを示す。コードＱＸは、顧客からの補足情報であることを示す。コードＱ２は、顧客からの追加質問であることを示す。コードＥＱは、関連部署へのエスカレーションであることを示す。ここでのエスカレーションとは、関連部署への問合せを意味する。コードＥＡは、関連部署からの回答であることを示す。コードＡＺは、顧客への最終回答であることを示す。これらのコードは一例であり、他の意味を持つコードを追加してもよいし、図１８に示したコードの一部を削除してもよい。

図１９は、有用情報格納部Ｔ１４の記憶内容の例を示す。有用情報格納部Ｔ１４は、例えば、案件番号と登録者ＩＤを対応づけて記憶する。

図２０は、利用者属性格納部Ｔ１５の記憶内容の例である。利用者属性格納部Ｔ１５は、例えば、利用者ＩＤとロールとを対応づけて記憶する。ロールとは、過去の事例に関する情報を利用する利用者（質問に回答する担当者）の役割を示す情報であり、例えば「リーダ」「担当者」に区別される。これ以外に例えば、「サブリーダ」「スーパーバイザ」「オブザーバ」といった属性を加えてもよい。

図２１は、事例を検索する事例検索画面Ｇ１（１）の検索前の例である。画面Ｇ１（１）は、例えば、問合せ文を表示する部ＧＰ１１（１）と、検索ボタンＢ１１を含む。

図２２は、事例検索画面Ｇ１（２）の検索後の例を示す。検索結果後の画面Ｇ１（２）は、例えば、問合せ文表示部ＧＰ１１（１）、検索ボタンＢ１１、検索結果部ＧＰ１２を含む。担当者が、所望の案件番号を選択すると、図２３または図２４に示すように、詳細な情報が提供される。

図２３は、事例検索画面の詳細表示画面Ｇ１（３）の例を示す。本実施例では、図２２に示す画面Ｇ１（２）で検索結果の一覧を表示した後に、担当者（利用者）が所望の案件番号に設定されたリンクをクリックすると、その案件の詳細な経過を表示する。

これに代えて、担当者に対して詳細画面を直接提供してもよい。すなわち、担当者はリンクをクリックする等の操作は不要となる。この場合は例えば、検索結果の最上位の案件のみを表示すればよい。

図２３の画面Ｇ１（３）は、例えば、最終回答を表示する最終回答部ＧＰ１１（２）、「参考になった」ボタンＢ３１、経過表示部ＧＰ１２（２）を含む。最終回答部ＧＰ１１（２）では、担当者からの最終回答（コードＡＺの本文）を表示しているが、これに代えて、顧客からの問合せ文を表示してもよいし、あるいは、最終回答部ＧＰ１１（２）そのものを画面から省略してもよい。

また、経過表示部ＧＰ１２（２）には、図２３のように全部の経過を表示してもよいし、あるいは、図２４に示すように、経過の一部分のみを表示してもよい。

図２４の画面Ｇ１（４）では例えば、検索に用いた問合せ文と最も一致する本文が含まれる日時以降のものを表示する。図２３，図２４の例では、「２０１７／９／１ １０：５０：００」のコードＡＬが該当する。経過の一部を表示することで、顧客からの問合せに対して、担当者が顧客に対して行うべき次のアクションが容易にわかる。図２３，図２４の場合、顧客からログファイル（ｓｅｒｖｅｒ．ｌｏｇ）を送ってもらうように依頼することが、次に行うべきアクションだとわかる。次に行うべきアクションを自動的に抽出することにより、事例検索システム１を自動応答システムへ適用することもできる。

このように構成される本実施例によれば、検索クエリに対応する所定の対応履歴により検索クエリを補正できる。したがって、本実施例によれば、対応履歴を用いて検索クエリを自動的に補うことができ、情報検索の効率と使い勝手が向上する。

本実施例によれば、対応履歴の内容（対応内容）を種類ごとに区別するコード情報を用いるため、内容に応じて対応履歴を管理することができ、検索クエリの補正に用いる対応履歴を容易に抽出することができる。

図２５〜図２７を用いて第２実施例を説明する。本実施例を含む以下の各実施例は第１実施例の変形例に相当するため、第１実施例との差異を中心に述べる。本実施例では、対応履歴に設定するコードごとにあらかじめ重みを持たせておき、その重みを検索クエリに付与して検索する。

図２５は、対応コード格納部Ｔ１２Ａの記憶例である。対応コード格納部Ｔ１２Ａは、コード、その意味、重みを対応づけて記憶する。

顧客からの情報には比較的高い重みが設定され、担当者から顧客に与えられる情報には比較的低い重みが与えられる。担当者から発せられる情報（本文）は、顧客の問題解決にあまり役立たないと考えられるためである。

図２６は、クエリ補正部Ｐ１１４Ａの処理を示すフローチャートである。図２６に示す処理は、図７で述べた処理に比べて、重みを取得して本文とともに検索クエリに追加する点で異なる。

クエリ補正部Ｐ１１４Ａは、当初の検索クエリの案件番号を対応履歴取得部Ｐ１３２に引き渡して呼び出す（Ｓ５１）。クエリ補正部Ｐ１１４Ａは、当初の検索クエリの案件番号と同一の案件番号を持つ対応履歴および重みを対応履歴取得部Ｐ１３２が取得できたか判断する（Ｓ５２Ａ）。

対応履歴取得部Ｐ１３２により該当案件番号を持つ対応履歴を取得できた場合（Ｓ５２Ａ：ＹＥＳ）、クエリ補正部Ｐ１１４Ａは、該当案件番号を持つ対応履歴の本文と重みを取得する（Ｓ５３Ａ）。

クエリ補正部Ｐ１１４Ａは、ステップＳ５３Ａで取得した本文および重みを当初の検索クエリに追加することにより、当初の検索クエリを補正する（Ｓ５４Ａ）。クエリ補正部Ｐ１１４Ａは、該当案件番号を持つ他の本文（および重み）が未だ存在するか判定する（Ｓ５５Ａ）。クエリ補正部Ｐ１１４Ａは、他の本文（および重み）が存在する場合（Ｓ５５Ａ：ＹＥＳ）、ステップＳ５３Ａへ戻り、他の本文を検索クエリにさらに追加する（Ｓ５４Ａ）。

該当案件番号を持つ対応履歴を取得できない場合（Ｓ５２Ａ：ＮＯ）、および該当案件番号を持つ他の対応履歴の本文（他の本文）が存在しない場合（Ｓ５５Ａ：ＮＯ）、本処理は終了する。

図２７は、補正後の検索クエリの例を示す。本実施例では、検索クエリ内においてコードごとに重みが付与されている点で第１実施例と異なる。重みは、次のようにして検索に反映させることができる。

コードＱ１の付与されている本文”ＤＥＦ証券の社内システムのサーバＨＢ−２３３０において昨日のバックアップが夜間の業務停止時間内に終わらなかった。”から抽出された単語とその単語のスコア（（）内）が、ＨＢ−２３３０（１００），バックアップ（４０），終わらなかった（１０）であるとする。この場合、各抽出されたスコアにコードＱ１に設定された重み「１．０」を乗じることにより、本クエリにおける上記各単語のスコアは、ＨＢ−２３３０（１００）， バックアップ（４０），終わらなかった（１０）、となる。

同様に、コードＡＬの付与されている本文”エラーメッセージは何か出ていますでしょうか？メッセージファイルａｂｃ．ｅｒｒをご確認頂き、お知らせいただけますでしょうか＊＊＊ｂｂｂ社 サポートサービス担当 斉藤＊＊＊”から抽出された単語とその単語のスコアが、エラーメッセージ（１００）， メッセージファイル（３０），確認（２０）， 担当（３０）であるとする。この場合、各抽出されたスコアにコードＡＬに設定された重み「０．２」を乗じることにより、本クエリにおける上記単語のスコアは、ＨＢ−２３３０（２０），メッセージファイル（６），確認（４）， 担当（６）、となる。コードＱＬの付与された本文についても同様である。

本実施例では、このようにして補正後クエリの文書から抽出された単語にスコアを付与し、そのスコア付単語で対応履歴文書を概念検索する。なお、上記の「ＨＢ−２３３０」のように複数回出現した場合は、最高スコアの単語のみ残せばよい。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施形態によれば、コードごとに重みをつけることができるため、重要な対応に含まれるキーワード（単語）を優先して対応履歴文書を概念検索することができ、より一層適切な検索結果を得ることができ、使い勝手が向上する。

図２８を用いて第３実施例を説明する。本実施例の事例検索システム１Ｂでは、対応履歴文書に対して概念検索するのではなく、各対応履歴の本文に対して概念検索を行う点で第１実施例と相違する。

つまり、第１実施例では補正後の検索クエリ（補正済検索クエリ）を用いて対応履歴文書を概念検索していたが、本実施例の検索対象は対応履歴の各本文である。本実施例の事例検索サーバ１０Ｂの対応履歴検索部Ｐ１１５Ｂは、補正後の検索クエリで各対応履歴の本文を概念検索する。対応履歴検索部Ｐ１１５Ｂは、その検索結果を案件番号単位で出力する。結果リランキング部Ｐ１１６と検索結果表示部Ｐ１１２の処理は、第１実施例と同じである。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。本実施例では、各対応履歴の本文をつなげた対応履歴文書を用いずに、各対応履歴の本文を直接概念検索するため、事例検索サーバ１０Ｂの構成を簡素化することができる。本実施例は、第２実施例と結合させて用いることもできる。

図２９〜図３１を用いて第４実施例を説明する。本実施例では、事例検索システム１Ｃをチャットボットシステム（問合せに自動応答するシステム）に適用する。

図２９は、事例検索システム１Ｃの構成例である。事例検索サーバ１０Ｃは。問合せ文受付部Ｐ１１１に代えて問い合わせ受付部Ｐ１１１を備える。さらに、事例検索サーバ１０Ｃは、検索結果表示部Ｐ１１２に代えて回答部Ｐ１１２Ｃを有する。本実施例では、顧客からの問合せに対してコールセンタの担当者が回答するのではなく、事例検索システム１Ｃがチャットボットとして自動的に回答する。

本実施例の問合せ受付部Ｐ１１１Ｃは、顧客からの問合せを受け付ける。本実施例の回答部Ｐ１１２Ｃは、結果リランキング部Ｐ１１６でリランキングされた結果の最上位の案件番号が持つコードＺＺの本文をチャットとして出力する。

図３０は、対応履歴格納部Ｔ１１Ｃの例を示す。図３０の下側に太字で示すように、コードＺＺは、該当案件番号の対応を元に自動での回答向けに作成された本文である。コードＺＺの本文は、コールセンタの担当者や別に割り当てられた回答作成者が、事例検索システム１Ｃから対応履歴登録部Ｐ１３１を呼び出して登録する。

コードＺＺの本文は、コードＡＺの本文から顧客名や担当者名、挨拶文等を除いて作成する他に、自動応答用に新たに作成したり、該当するマニュアル等から引用したりしてもよい。

図３１は、対応コード格納部Ｔ１２Ｃの例である。コードＺＺは、上述の通り、自動応答用の回答であることを示す。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施形態によれば、事例検索システム１Ｃをチャットシステムに組み込んで、顧客からの問合せに自動回答できるため、効率的に運用することができる。

１，１Ｂ，１Ｃ：事例検索システム、１０，１０Ｂ，１０Ｃ：事例検索サーバ、Ｐ１１：検索実行部、Ｐ１２：有用情報管理部、Ｐ１３：対応履歴管理部、Ｐ１４：対応履歴文書登録部、Ｔ１１，Ｔ１１Ｃ：対応履歴格納部、Ｔ１２，Ｔ１２Ｃ：対応コード格納部、Ｔ１３：対応履歴文書格納部、Ｔ１４：有用情報格納部、Ｔ１５：利用者属性格納部

Claims (9)

1. 情報を検索する情報検索システムであって、
   問合せに対する対応履歴を格納する対応履歴格納部と、
   入力情報に基づく検索クエリに対応する所定の対応履歴を前記対応履歴格納部から取得する対応履歴取得部と、
   前記所定の対応履歴に基づいて前記検索クエリを補正する検索クエリ補正部と、
   前記補正された検索クエリに基づいて前記対応履歴格納部に格納された対応履歴を検索し、検索結果を出力する検索部と、
   を備える情報検索システム。
2. 前記検索クエリには、問合せ案件ごとに付与される案件番号を有しており、
   前記対応履歴格納部は、前記案件番号と過去の対応内容とを対応づけることにより前記対応履歴として格納しており、
   前記対応履歴取得部は、前記検索クエリの持つ案件番号と同一の案件番号を持つ対応履歴を前記所定の対応履歴として前記対応履歴格納部から取得し、
   前記検索クエリ補正部は、前記所定の対応履歴に含まれる対応内容の少なくとも一部を前記検索クエリに加えることにより、前記検索クエリを補正する、
   請求項１に記載の情報検索システム。
3. 前記対応履歴は、対応内容を種類ごとに区別するコード情報を含んでいる、
   請求項２に記載の情報検索システム。
4. 前記コード情報には重み情報が設定されており、
   前記検索クエリ補正部は、前記所定の対応履歴に含まれる対応内容を当該対応内容に設定された前記重み情報に基づいて前記検索クエリに加えることにより、前記検索クエリを補正する、
   請求項３に記載の情報検索システム。
5. 前記検索結果に含まれる対応履歴が有用であるかを示す有用情報を取得する有用情報取得部と、
   前記検索結果に含まれる対応履歴の順番を前記有用情報に基づいて並び替える検索結果並び替え部と、
   をさらに備える、請求項１に記載の情報検索システム。
6. 前記対応履歴に有用情報を設定するユーザの属性に応じて、前記有用情報の値が算出される、
   請求項５に記載の情報検索システム。
7. 前記検索部は、前記対応履歴格納部に格納された対応履歴のうち同一案件番号を持つ対応履歴を一つのファイルにまとめた対応履歴文書ファイルを検索対象とする、
   請求項２に記載の情報検索システム。
8. 前記検索部は、前記対応履歴格納部に格納された対応履歴のうち同一案件番号を持つ対応履歴の中から選択される一部の対応履歴を前記検索結果として出力する、
   請求項２に記載の情報検索システム。
9. 計算機を用いて情報を検索する方法であって、
   入力情報に基づく検索クエリに対応する所定の対応履歴を、問合せに対する対応履歴を格納する対応履歴格納部から取得し、
   前記取得された所定の対応履歴に基づいて前記検索クエリを補正し、
   前記補正された検索クエリに基づいて前記対応履歴格納部に格納された対応履歴を検索し、
   検索結果を出力する、
   情報検索方法。

Images