JP2012215992A - 情報共有・活用システム - Google Patents

Abstract

【課題】 組織又はウェブの知的財産を活用し、イノベーション能力を強化する「情報共有・活用技術」の提供を目的とするものである。
【解決手段】 データを収集するデータ収集機能と、収集したデータをインデックス化するインデックス化機能と、インデックス化したデータからデータ検索又はフィルタリングするデータ検索・フィルタリング機能と、データを活用するデータ活用機能と、を備えたことを特徴とする情報共有・活用システム。
【選択図】 図１

Description

本願発明は、組織内あるいはウェブ上に分散している、ありとあらゆる情報を素速く、簡単に取り出して活用できる新規な情報共有・活用技術に関するものである。

これまでに情報共有・活用技術としては「ＥＣＭ」(Enterprise Contents Management）がある。ＥＣＭとは「組織のプロセスに関連するコンテンツや文書を収集・管理・蓄積・保護・配布するための技術、ツール、手法」と定義されている。このＥＣＭは、ドキュメントを対象として管理するものである。

このＥＣＭを図面に基づいて説明する。ＥＣＭは、図１８に示すように概要（１）〜（３）のような方式である。
（１）情報ソース（文章やレコード）を形式変換し、情報データベース（文章ベース）に移動する。
（２）インデックス部を検索する。
（３）情報データベース（文章ベース）に格納された文章やレコードが活用時に参照される。

そして、情報データベースは、図１９に示すような構造を備えている。すなわち、情報データベースは「索引」と「データ部」があり、データ（コンテンツ）は形式を保って保存されていた。そして、索引の存在意義は検索を行うためのものであった。そのため、入れ物を準備する必要があり、大がかりな装置が必要であった。

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

しかしながら、上記する従来のＥＣＭでは次のような課題を有し、理想環境の実現にはハードルが高い。
（１）莫大な初期投資が必要になる。
（２）継続的にデータの分類・メンテナンス・更新を行う管理者が必要になる。
（３）現場業務との乖離によってシステムが形骸化する。
（４）システムの管理者と情報管理者の立場の違いによって、…
（５）

そこで、組織又はウェブの知的財産を活用し、イノベーション能力を強化すべく次の目的を達成できる「情報共有・活用技術」を提供するものである。
（１）既存環境（事業環境・システム環境）を変更することなく運用できる情報共有、すなわち、拠点毎・部署毎の運用・管理ルールはそのままにすること
（２）情報収集作業にかかる人的コストの削減、すなわち、１コンソールからあらゆる情報を串刺し検索すること
（３）ユーザー用途に柔軟に対応できる拡張性のあるサービス、すなわち、ユーザー業務にあった専用コンソールを簡単作成すること
（４）データ入力管理にかかる人的コストの削減、すなわち、社内システムへダイレクトに情報を入力・反映すること

上記目的を達成するために、第１の発明は、データを収集するデータ収集機能と、収集したデータをインデックス化するインデックス化機能と、インデックス化したデータからデータ検索又はフィルタリングするデータ検索・フィルタリング機能と、データを活用するデータ活用機能と、を備えたことを特徴とする情報共有・活用システムである。
第２の発明は、インデックス化機能は、データの中身を形態素解析などを通じて抽象化された要素に分解・正規化・名寄せして、要素の集合体としてインデックスベースに格納することを特徴とする同情報共有・活用システムである。
第３の発明は、インデックス化機能は、サーバーを使用することなく各クライアント内にインデックスを保持することを特徴とする同情報共有・活用システムである。
第４の発明は、各機能部をフレームワーク化するとともに、形態の異なるデータや方式の異なる処理を扱うためのプラグインを各プラットフォームに組み込むことを特徴とする同情報共有・活用システムである。

本願発明によれば、以下のような効果を有する。
（１）従来のＥＣＭがドキュメントを意識しながら管理するのに対して、本願発明は情報を抽象化された情報としてフラットに扱うことができる。そして、仮想のフラットな情報空間を縦横に検索することで、重要な情報にたどり着くことができる。
（２）従来の情報検索システムでは、情報やインデックスをサーバーに備え、デスクトップからサーバーのインデックスにアクセスすることにより情報を検索していたために情報検索システムにサーバーが不可欠であるとともに、クライアント別のカスタマイズに制約が生じ、柔軟さに欠けていたが、本願発明では、サーバーを使用せずに全てのインデックスを各クライアントに置くことによってサーバー無しの運用を可能にするとともに、クライアント別検索の柔軟性を増大させた。
（３）従来の情報活用システムは、データ収集、インデックス化、検索などの処理において、形態（場所、形式、利用方法の違い）を意識した処理が必須であり、形態ごとに個別に形成されてきた。そのために、様々な形態の情報を横串に検索したり、形態の異なる情報を包括的に扱うことが困難であり、また、新たな形態の情報に対処することが困難であったが、本願発明は、情報活用のプロセスを極度に抽象化、非常にシンプルなフレームワークとし、そのフレームワークに基づいて、様々なモジュールをプラグインとして組み込むことができるプラットフォームを提供できる。
（４）その他

本願発明に係る第１実施形態を示す説明図（その１）。 本願発明に係る第１実施形態を示す説明図（その２）。 本願発明に係る第１実施形態を示す説明図（その３）。 本願発明に係る第２実施形態を示す説明図（その１）。 本願発明に係る第２実施形態を示す説明図（その２）。 本願発明に係る第２実施形態を示す説明図（その３）。 本願発明に係る第３実施形態を示す説明図（その１）。 本願発明に係る第３実施形態を示す説明図（その２）。 本願発明に係る第３実施形態を示す説明図（その３）。 本願発明に係る第３実施形態を示す説明図（その４）。 本願発明に係る第３実施形態を示す説明図（その５）。 本願発明に係る第３実施形態を示す説明図（その６）。 本願発明に係るインデックス化の具体例（その１）。 本願発明に係るインデックス化の具体例（その２）。 本願発明に係るインデックス化の具体例（その３）。 本願発明に係るインデックス化の具体例（その４）。 本願発明に係るインデックス化の具体例（その５）。 従来技術を示す説明図。 従来のコンテンツデータベースを示す説明図。

＜本願発明の第１実施形態＞
図１〜３に基づいて本願発明の第１実施形態を説明する。
まず、図１に示すように、第１実施形態は（１）〜（３）の機能よりなる。
（１）テキスト文書などの情報ソースの中身が形式別プラグインによって形態素解析等を通じて抽象化された要素に分解・正規化・名寄せされて、要素の集合体としてインデックスに格納される。
（２）インデックスベースは上記（１）によって抽象化されたフラットな情報ベースとなっており、このインデックスベースそのものを検索する。
（３）インデックスベースに格納された情報を活用し、また、活用時に形式別プラグインやアプリケーションを用いて情報の再構築或いはオリジナル情報の参照を行う。

そして、図１に示す第１実施形態の構成を図示すると、図２のようになる。
ここで「形式別抽出プラグイン」とは、様々な形式のオリジナル情報から、情報を抽出するプラグインである。情報の形式別に追加することにより、多様な形式に対応できる。エージェントとして組織内に分散した情報を収集抽出する。
「要素化装置」とは、抽出した情報を抽象化し原子化する装置である。形態素解析・正規化・名寄せなどを行い情報を検索可能な最小要素単位に分解する。
「索引化装置」とは、要素化された情報をインデックスベースに検索可能な形式で格納する装置である。
「合成装置」とは、インデックスベースから参照可能な元データを合成する装置である。
「形式別プラグイン」とは、オリジナル情報から、インデックスベースで合成できない情報を獲得し情報を合成する装置である。
「用途別アプリケーションアダプター」とは、合成された情報を与えて用途別のアプリケーションを呼び出す装置である。
「ユーザーインターフェース装置」とは、ユーザーが検索条件を与え、検索結果と合成情報を受け取り、アプリケーションを実行する装置である。

また、図１に示す第１実施形態の「インデックスベース」は概要図３のように図示されるが、詳しくは（１）〜（７）のような特徴を有する。
（１）インデックスベースは索引そのものである。
（２）索引からオリジナル情報を合成するためのメタ情報をあらかじめ索引の一部として保存する。
（３）索引から再生できる情報を合成し表示する。
（４）そのため、文書としての実体のないケース（外部Ｗｅｂ、電子メールやチャットログなど）にも対応できる。
（５）再生できない場合にオリジナル情報にアクセスする。
（６）そのため、オリジナル情報をそのまま参照でき、大がかりな装置は必要ない。
（７）また、オリジナル情報の場所と形式に非常に柔軟に対応できる。

＜本願発明の第２実施形態＞
図４〜６に基づいて本願発明の第２実施形態を説明する。
まず、図４に第２実施形態の概要を図示する。第２実施形態は、様々な形態・形式の情報にインデックスを付け、柔軟に検索・活用できるシステムであることは第１実施形態の場合と同様であるが、その他にサーバー無しの運用を可能とし、低コストや柔軟性を増すことに特徴がある。すなわち、従来の情報検索システムは、情報やインデックスをサーバーに持ち、デスクトップからサーバーのインデックスにアクセスすることにより情報を検索していた。しかし、この方式では情報検索システムにサーバーが不可欠であり、サーバーのためのコストや運用が必要であった。また、クライアント別のカスタマイズに制約が生じ、柔軟さに欠けていた。これに対して、本願発明（第２実施形態）ではサーバーを使わずに、全てのインデックスを各クライアントに置くことにより、サーバー無しの運用を可能とし、クライアント別検索の柔軟さを増大させるものである。

図５は、第２実施形態の全体構成のイメージである。オリジナル情報とクライアントに本質的な違いはなく、必要な情報を相互に参照するものである。
図６は、第２実施形態の実現方法を図示したものである。ここでの第２実施形態の特徴は、クライアント内にインデックス（インデックスベース）を保持して情報を活用している点にある。これにより、サーバー無しで情報検索システムの運用を可能とした。なお、その他の点については図１に示す第１実施形態と共通するので、その説明を省略する。

＜本願発明の第３実施形態＞
図７〜９に基づいて本願発明の第３実施形態を説明する。
第３実施形態は、情報の包括的活用のフレームワークを実現するソフトウェアプラットフォームを提供することにある。具体的には、データ収集、インデックス化、検索・フィルタリング、データ活用（アプリケーション）の情報活用プロセスをそれぞれ抽象化し、プラグイン化することにより、構成と実装方法の柔軟さを実現するものである。
すなわち、従来の情報活用システムは、データ収集、インデックス化、検索などの処理において、形態（場所・形式・利用方法の違い）を意識した処理が必須であり、形態ごとに個別に作成されてきた。そのため、様々な形態の情報を横串に検索したり、形態の異なる情報を包括的に扱うことが困難であるとともに、また、新たな形態の情報に対処することが難しかった。そこで、第３実施形態では、情報活用のプロセスを極度に抽象化、非常にシンプルなフレームワークとし、そのフレームワークに基づいて様々なモジュールをプラグインとして組み込むことができるプラットフォームにしたものである。
ここで、プラグイン化とは、予め機能の入出力形式を取り決め、取り決められた入出力を持つ外部モジュールを取り込み、プログラムを拡張する方式のことである。

そもそも、情報検索は、必要な情報を得るために、情報を絞り込み、絞り込んだ情報の内容やありかを返し、その情報を利用できるように加工する。これを行うために、予めオリジナル情報を加工して検索できる形式に変換しておく。
すなわち、情報検索は次の（１）〜（４）の要素からなっている。
（１）オリジナル情報のありかを確かめ、情報を収集する（データ収集）
（２）オリジナル情報を加工し、検索できる形式に変換する（インデックス化）
（３）情報を絞り込み、必要な情報に到達する（データ検索・フィルタリング）
（４）検索の結果を加工し利用する（データ活用）

そして、これらの要素は本来非常に多様である。例えば、オリジナル情報は様々な形式で、様々な場所にある。また、情報の絞り込みは、目的の情報に到達するまでに試行錯誤を行ったり、揺れを吸収してマッチングしたり、オリジナル情報のメタ情報（形式や場所など）を利用したり、様々な処理が必要である。また、当然のことながら、その利用に当たっては、その目的に応じた加工が必要となる。これらの処理はオリジナル情報の形態に依存することが多い。そこで、従来はオリジナル情報の形態ごとに、その形態に固有の処理を実装して情報検索のシステムが構築されてきた。一方、汎用の検索ツールにおいては、このような多様な処理を一つのツールで賄うことは難しいため、対象を絞り、処理を絞って実装せざるを得なかった。

まず、図７に第３実施形態の概要を図示する。すなわち、第３実施形態では、上記問題を解決するために、まず、形態ごとに処理を考えるのではなく、情報検索の要素ごとに構成単位を分割し、それぞれの構成単位ごとに多様な機能をプラグインとして取り付けできるようにした（データ収集、インデックス処理、データ検索・フィルタリング、データ活用部分）。そして、それぞれが共通に用いる処理とデータを高度に抽象化して、相互に取り付け・交換ができるようにした（プラットフォーム）。更に、各プラグインが用いる抽象化のための機能郡をライブラリーとして装備したものである。

図７に示すような方式でプラグインを作成する場合、多様な情報の形態を対象とするために、きめ細かい対応が必要となる。
情報の形式として、例えば、テキスト、データベース、ＸＭＬ、ＨＴＭＬ、アプリケーションファイルなどの違いがあるため、それぞれごとにプラグインが必要なことはすぐに分かるが、単にそのような異なる形式への対応だけでは検索情報の抽出としては不十分である。例えば、ある条件を満たす「顧客」を検索したい場合、オリジナル情報のどこに「顧客」があるのかを識別できなければならない。通常のテキストやＨＴＭＬなどでは「顧客」の場所を明示する情報は添付されていない。従って、これらのような形態のデータからは、意味を与えることによって初めて検索可能な情報を得ることができる。
そこで、対象のアプリケーションに合わせて、どういう場所にどういうパターンで特定の意味を持つ情報（例えば顧客情報など）が入っているのかを、個別に与えなければならない。また、日付や住所など、異なる複数の形式を持つ情報に検索のマッチングをかけるためには、形式の揺れを吸収して規格化を行わなければならない。ここでも、どのような揺れがあるのかを予め知識として与える必要がある。

そこで、本願発明では、以下のような抽象化のための機能をライブラリーとして装備し、各プラグインから機能を呼び出して使えるようにした。
（１）規格化（データの揺れの排除）
（２）構文解析（ＨＴＭＬ、ＸＭＬ、アプリケーションファイル、ＣＳＶからのキー付き データの抽出）
（３）パターンマッチング分析（正規表現による意味をもった情報の抽出）
（４）推論（ルールエンジンによる意味をもった情報の抽出）
これらの呼び出しは、ＸＭＬファイル形式で保持されている構成データによって行われる。構成データには、規格化・構文解析・パターンマッチング・推論にかかわるデータ抽象化のための知識が格納されており、対象データや対象アプリケーションごとに定義することができる。
各プラグインは、オリジナルデータにあった構成データを指定し、抽象化ライブラリーを呼び出す。抽象化ライブラリーは、構成データの中身を解釈して必要な処理を行い、データを抽象化する。
これにより、非常に多様なデータに対して、きめ細やかに検索データ抽出を行う仕組みが可能となる。

次に、各プラグイン及びプラットフォームについて説明する。
まず「データ収集プラグイン」の例として、オリジナルデータの形式ごとに次のような種類がある。
（１）テキストプラグイン
（２）ＣＳＶプラグイン
（３）ＸＭＬプラグイン
（４）オフィス製品プラグイン
（５）ＨＴＭＬプラグイン
（６）リレーショナルＤＢプラグイン
（７）ＯＣＲプラグイン
（８）ＰＤＦプラグイン
（９）メールプラグイン
上記プラグインは、それぞれの形式を変換するのみならず、上記抽象化ライブラリー機能（［００２１］（１）〜（４））を用いて、情報の抽出と抽象化を行う。
これらの処理により、オリジナルデータの形態固有のデータ特性が排除され、高度に抽象化された情報に変換される。また、それぞれの機能を用いるためには、情報抽出にかかわる知識を与える必要があり、プラグインごとにそれらの知識を保持する。

データ収集プラグインの特殊なものとして、「インデックスプラグイン」がある。
これは、本願発明の検索システムを備えた他システムのインデックスをオリジナルデータとして処理し、そこからインデックスを抽出するプラグインである。インデックスのマージ処理や重複排除を行う。これにより、他の端末のインデックスを共有でき、より広範な情報ソースの検索を手軽に実装できる。
インデックス（処理）プラグインの例として、次のような種類がある。
（１）ローカルインデックスプラグイン
（２）ピアネットワークプラグイン
（３）ｗｅｂサービスプラグイン
上記（１）ローカルインデックスプラグインは、ローカルにインデックスを保持し、検索する。
上記（２）ピアネットワークプラグインは、ネットワークでアクセス可能な他の端末に検索要求を出し、結果を受け付ける。
上記（３）ｗｅｂサービスプラグインは、Ｇｏｏｇｌｅなどの検索サイトに検索要求を出し、結果を受け取る。また、同じプラグインを用いて、本願発明の検索エンジンをｗｅｂサービスとして提供することも可能である。
なお、後者（２）及び（３）のプラグインは、組織的に情報を管理し提供したい場合や、情報検索サービスでの使用を想定している。

「データ検索プラグイン」の例として、次のような種類がある。
（１）マニュアル検索（キー指定）
（２）アプリケーションからの要求に基づく検索
（３）モニタリング（エージェントが定期的に検索）
（４）セキュリティフィルタリング（アクセス制御
（５）テーブル化
（６）集計
前者（１）〜（３）は、検索キーの与え方に関するプラグインである。
後者（４）〜（６）は、検索結果の処理に関するプラグインである。当該プラグインでは、データ収集プラグインでも用いられている抽象化ライブラリーの「パターンマッチング（正規表現による情報のさらなる絞り込みや変換）」「推論（ルールエンジンによる情報のさらなる絞り込みや変換）」及び「規格化（データの揺れの排除）」機能を用いる。
これらの機能は、インデックスから得られた検索結果データから、さらに意味のある情報を絞り込んだり、意味のある情報に変換するために用いられる。

「データ活用プラグイン」の例として、次のような種類がある。
（１）一覧表示プラグイン
（２）ＨＴＭＬ合成プラグイン（結果をＨＴＭＬに変換しブラウザーで表示）
（３）ＨＴＭＬ差し込みプラグイン（テンプレートを用いてＨＴＭＬの変数に結果を差し 込んで表示）
（４）帳票プラグイン（ＸＰＳ合成により帳票表示）
（５）グラフ表示プラグイン
（６）メール送信プラグイン
（７）ファイル出力プラグイン（ＣＳＶ、Ｅｘｃｅｌへのエクスポート）
（８）自動入力プラグイン（独立したｗｅｂアプリケーションなどのフィールドに、結果 を入力して実行）
これらのプラグインは、検索結果を様々な表現に変換する。また、検索結果を与えて独立したアプリケーションの自動実行を行い、アプリケーションにつなぐ。

「プラットフォーム」は、各プラグインを動的に呼び出すフレームワークである。
プラットフォームとして、次の２種類がある。
（１）ＧＵＩプラットフォーム
（２）エージェントプラットフォーム
上記（１）ＧＵＩプラットフォームは、ユーザーインターフェースを持ち、ユーザーと対話しながら全てのカテゴリーのプラグインを呼び出して情報検索の全局面を行う。
上記（２）エージェントプラットフォームは、ユーザーインターフェースを持たず、主にデータ収集とインデックス処理のプラグインを呼び出すプラットフォームである。バックグラウンドでのインデックス作成などに対応する。
以上、説明した各プラグイン及びプラットフォームは、追加交換が可能であり、様々な情報検索の形態、要件、ニーズに沿って拡張できる。

図８〜図１０は、第３実施形態の方式を図示したものである。図示するように、情報活用の４つのステップをフレームワーク化し、形態の異なる情報や方式の異なる処理を扱うためのプラグインを、それぞれプラットフォームに組み込んで使用する。形態によらない部分は、同じ処理として扱えるように高度に抽象化する。このため、個別のプログラムを作ることなく、活用アプリケーションを作成・増設できるとともに、情報活用の基盤としてデータベースを不要にできる。
図１１及び図１２は、第３実施形態の実現方法及び構成を図示したものである。ここでの第３実施形態の特徴は、情報処理の基盤（フレームワーク＋プラットフォーム）にその処理別にプラグインを組み込むことにある。なお、その他の点については図１に示す第１実施形態や図６に示す第２実施形態と共通するので、その説明を省略する。

＜インデックス化の具体例＞
図１３は、バラバラな形式のファイルをインデックス化する一例を示すものである。
図示するように、メルマガ配信リストＡ〜Ｃのバラバラな項目名や並びのＣＳＶファイルに対して、その記載項目を推測し、メルマガ配信リストを統一された形式にインデックス化する。このように、本願発明のインデックス化は、異なる形式のファイルのデータを統合し、検索やアプリケーションに活用できる。

図１４は、平テキストからキーワードを抽出し、インデックス化する一例を示すものである。
図示するように、電子メールデータの記載内容を判断し、そこからキーワードを抽出し、インデックス化する。このように、本願発明は、自動でキーワードを識別し、インデックス化し、検索やアプリケーションに活用できる。

図１５は、異なるインデックス同士をつないで新しいインデックスを作成する一例を示すものである。
図示するように、インデックス化された保守データ、インデックス化された会社マスタ、インデックス化された保守指示書テーブルから対応するインデックスを検出し、連結することで、「お問い合わせ対応」という新しいインデックスを作成する。このように、本願発明のインデックス化は、検索や編集を繰り返すことなく、必要な情報を一度に取り出して活用できるので、情報を組み合わせてより価値のある情報を作成できる。

図１６は、インデックスの中のテキストパターンを抽出し、複数のインデックスに分割する一例を示すものである。
図示するように、インデックス化された日報から、パターンを認識し、その対応（作業）ごとのインデックス（作業Ａ、作業Ｂ、作業Ｃ）に分割する。このように、本願発明のインデックス化は、再入力や編集を行うことなく、分割した単位の集計や活用もできる。

図１７は、正規化（名寄せ）したデータでインデックスを作成・検索する一例を示すものである。
図示するように、保守リスト、会社マスタ、日報等の各データにおいてバラバラな社名表記を統一し、正規化したデータでインデックスを作成する。これにより、本願発明のインデックス化は、整合性の取れなかった表記を統一し、データ活用ができるようになる。

本願発明は、上記の実施形態のように企業等の組織内に分散している、ありとあらゆる情報を素速く、簡単に取り出して活用できる新規な情報共有・活用ツールとして広く利用できるものである。

また、本願発明は、組織内における情報活用と同様にウェブ上の情報に関しても、次のように活用できる（その一例を紹介する）。
（１）価格情報の推移やしきい値の把握
すなわち、ウェブサイトに掲載されている価格情報を蓄積や活用をし、マーケティ ングに活かす。
（２）自社や製品の評判の把握
すなわち、ウェブサイトなどから口コミ情報を収集し、自社製品の評判を分析し、 マーケティングに活かす。
（３）入札情報の把握
すなわち、ウェブサイトなどから入札情報を収集し、インデックス化した情報を検 索、活用することで営業活動に活かす。
（４）他社キャンペーン情報の把握
すなわち、ウェブサイトなどから競合他社サイトやニュース情報からキャンペーン 情報を終始し検索、活用することで営業活動に活かす。
（５）その他

Claims (4)

1. データを収集するデータ収集機能と、
   収集したデータをインデックス化するインデックス化機能と、
   インデックス化したデータからデータ検索又はフィルタリングするデータ検索・フィルタリング機能と、
   データを活用するデータ活用機能と、
   を備えたことを特徴とする情報共有・活用システム。
2. インデックス化機能は、データの中身を形態素解析などを通じて抽象化された要素に分解・正規化・名寄せして、要素の集合体としてインデックスベースに格納することを特徴とする請求項１記載の情報共有・活用システム。
3. インデックス化機能は、サーバーを使用することなく各クライアント内にインデックスを保持することを特徴とする請求項１又は２記載の情報共有・活用システム。
4. 各機能部をフレームワーク化するとともに、形態の異なるデータや方式の異なる処理を扱うためのプラグインを各プラットフォームに組み込むことを特徴とする請求項１、２又は３記載の情報共有・活用システム。

Images