JP7218451B2 - タグドメイン提示装置およびタグドメイン提示方法、およびそれを用いた情報処理システム - Google Patents

Description

本発明は、タグドメイン提示装置およびタグドメイン提示方法に係り、特に、データに関するタグによる情報検索の機能が提供されるデータレイク管理者が、データレイクで検索を行うユーザに対して、工数を掛けずに検索する部門によらず統一的なタグによる検索式を提供するのに好適な技術に関する。

近年、ハードウェア技術や情報処理技術の進展により、データ分析やＡＩ活用事例が増加しており、より多くのデータを利用したいというニーズが高まっている。従来、企業体において部門毎でデータを管理していたことによるサイロ化（企業のある部門が、他の部門と情報共有や連携などをせずに独自に業務を遂行し、孤立した状態）されたデータに対し、部門横断的に利用可能とするため、データレイクに、各部門のデータを集約するという動きがある。ここで、データレイクとは、構造化データや非構造化データを格納する場所であり、様々なデータソースから集められたデータを管理し、活用のための前処理を行える環境であり、データの一元的な貯蔵庫である。

しかしながら、データレイクをそのような企業体において適切に利用するためには、管理規則を遵守した上で、各データに対し適切なビジネスメタデータ（タグ）を付与することによって、データを発見・利用できるようにする必要がある。一般に、部門毎のデータに対しては、部門毎の固有情報に基づいて付与されたタグが付与されており、異なった定義がなされている。そのため、データレイクを管理するデータ管理者は、そのような部門ごとで定義されたタグの組合せの検索式で表現される範囲の共通範囲を特定し、部門利用を超えて横断的に使用できる統一的なタグを付与する必要がある。データ利用者が、そのような統一的なタグを、ユーザに提供し、それをユーザが利用することにより、ユーザが検索したかったタグの付与されたデータに対して、部門横断的にアクセスが可能となる。

このような情報検索技術としては、例えば、特許文献１がある。特許文献１に記載されたシステムでは、エンティティの標準名を一意に識別しない固有の名前から非標準の特徴を識別し、余分となる文字列を削除し、標準名形式にしたがって名前を使用するように調整された選択された正規表現を使用して各個別の名前を処理することにより、エンティティの標準名に自動的に修正する。

このように、特許文献１記載の技術を用いれば、既存のタグに対し辞書を参照し、共通項目外の文言を削除することにより、企業における部門ごとのタグの統一化を自動的に行い、管理者が部門ごとのタグの統一化を行う場合の労力を軽減することが期待される。

米国特許９５４２４５６号公報

例えば、産業分野においては、データの部門横断的利用に向けてデータレイクの利活用が進むと予想される。その場合には、データレイク上のデータの発見・利用を支援するデータカタログの利用により、データ利活用の効率向上を図ることになる。

このような環境では、従来独自に管理していたデータをデータレイク上に移管する形で格納される。そのとき、部門毎の固有情報に基づいて作成・付与されたタグは標準化されておらず、定義の異なりが生じる。そして、データレイクに格納されたデータと部門ごとに定義されたタグに関して、各部門間のマッピングをとることは、データに関する理解や利用手法（部門ごとのデータを扱うノウハウ）を十分に把握していないデータレイク管理者には困難であることが予想される。そのため、部門毎のデータユーザとのヒアリングを通じて部門毎のタグを横断できるようなタグの検索式で表現できデータ範囲を見出し、それを抽出することにより統一的のタグを付与することを試行するが、そのような場合には、ヒアリングによるデータレイク管理者の管理工数が増加してしまう。

特許文献１によれば、部門ごとに異なるタグの名称から非標準の特徴を識別し、余分となる文字列を削除することにより標準化することができるが、異なる表現を有する名称の標準化については言及していない。したがって、共通となる特徴表現を持っていない名称で定義されることが生じる環境において、部門横断的な統一的なタグを提供しようとするときに、データレイク管理者のそのような処理に関する労力を軽減することについては考慮されていない。

本発明の目的は、データに関するタグによる情報検索の機能が提供されるデータレイク管理者が、データレイクで検索を行うユーザに対して、工数を掛けずに検索する部門によらず統一的なタグによる検索式を提供することのできる方法を提供することにある。

本発明のタグドメイン提示装置の構成は、好ましくは、検索のためのタグが付与されたデータに関して、そのデータを利用する各部門に横断的なタグの検索式を提示するタグドメイン提示装置であって、タグドメイン提示装置は、ユーザとそのユーザの部門を対応付けたユーザ属性テーブルと、部門ごとにタグとデータとの対応情報を格納する固有タグテーブルと、ユーザの属する部門と、ユーザごとにアプリケーションソフトウェアに関する情報と、アプリケーションソフトウェアが利用した検索タグと、検索タグに対応するデータ情報と、固有タグテーブルにより示されるデータごとに対応する付与タグと、付与タグに関するユーザ評価情報を格納するデータ利用ログテーブルとを保持し、タグドメイン提示装置は、データ利用ログテーブルのレコードから、アプリケーションソフトウェアによるデータ利用観点でフィルタリングした利用観点抽出ログテーブルを生成し、利用観点抽出ログテーブルから、データの部門ごとのユーザとアプリケーションソフトウェアに関する利用情報と、ユーザ評価情報に基づいて、利用傾向評価テーブルを生成し、利用傾向評価テーブルの情報に基づいて、データ利用観点として共通する部門ごとのタグの検索式を提示するようにしたものである。

本発明によれば、データに関するタグによる情報検索の機能が提供されるデータレイク管理者が、データレイクで検索を行うユーザに対して、工数を掛けずに検索する部門によらず統一的なタグによる検索式を提供することのできる方法を提供することができる。

一実施形態に係る情報処理システムの全体構成図である。 データレイク管理サーバの機能構成図である。 データカタログ管理部の機能構成図である。 管理者端末の機能構成図である。 タグドメイン提示装置の機能構成図である。 データ利用ログ管理部の機能構成図である。 ユーザ属性管理部の機能構成図である。 タグドメイン管理部の機能構成図である。 アプリケーション管理部の機能構成図である。 タグドメイン提示装置のハードウェア・ソフトウェア構成図である。 データ利用ログテーブルの一例を示す図である。 利用観点抽出ログテーブルの一例を示す図である。 固有タグテーブルの一例を示す図である。 アプリケーションテーブルの一例を示す図である。 アプリケーションパラメータ情報テーブルの一例を示す図である。 ユーザ属性テーブルの一例を示す図である。 ユーザ属性重みテーブルの一例を示す図である。 利用傾向評価テーブルの一例を示す図である。 タグドメイン推薦値テーブルの一例を示す図である。 推薦タグドメインテーブルの一例を示す図である。 タグドメインの領域分割のタイプを説明する図である。 データ利用ログの蓄積から、データレイク管理者にタグドメインを提示するまでの一連の処理を示すフローチャートである。 データ利用ログのレコード間の類似度を算出する処理を示すフローチャートである（その一）。 データ利用ログのレコード間の類似度を算出する処理を示すフローチャートである（その二）。 データレイク管理者にタグドメインを提示する処理を示すフローチャートである。 推薦タグドメインを抽出する処理を示すフローチャートである。 タグドメイン推薦画面の一例を示す図である。

以下、本発明に係る一実施形態を、図１ないし図２４を用いて説明する。

本実施形態は、部門毎でデータが生成され、部門毎で異なる定義のタグが付与されたデータをデータレイクに格納した際の、タグの組合せによる検索式で示されるタグで表されるデータの検索領域に関して、データ管理者が部門間で共通の統一的なタグの検索式を提供することを可能とする例である。本実施形態では、一会社における工場ＩｏＴ（Internet Of Thing）の現場を例に採り説明する。

ここで、最初に本明細書中で使用する定義について説明する。

「タグ」とは、データに付加されるに関するメタデータの情報である。例えば、工場で使用する振動センサに対する仕様説明書、事故事例、動作履歴データ、計測データなどに、「Ｓｈｉｎｄｏ＿Ｓｅｎｓｏｒ」というタグをつけることができる。

「固有タグ」とは、企業体の部門毎の固有情報に基づいて付与されるタグである。本明細書中で「固有タグ」という用語を使用するときには、常に、それを定義した部門が意識されている。

「タグドメイン」とは、固有タグの組合せの検索式で表現される検索の概念的な範囲である。

「統一タグ」とは、データレイクの管理者が、複数の「タグドメイン」に対して、概念的な共通範囲を見出して、横断的な検索ができるように付与するタグである。

先ず、図１ないし図１０を用いて、一実施形態に係る情報処理システムの構成について説明する。

本実施形態の情報処理システムは、図１に示されるように、ユーザ端末１、データレイク４、アプリケーションサーバ３、タグドメイン提示装置１０がネットワーク５により接続された形態である。ネットワーク５は、ＬＡＮ（Local Network）でもよいし、インターネットのようなグローバルネットワークであってもよい。

ユーザ端末１は、アプリケーションソフトウェアを実行の指示をするユーザが、コマンドやデータを入力し、システムからの情報を確認するための端末装置である。データレイク４は、構造化データや非構造化データを格納する場所であり、様々なデータソースから集められたデータを管理し、活用のための前処理を行える環境を提供するシステムである。ユーザは、使用するアプリケーションソフトウェアの中からのＡＰＩやデータ検索ソフトウェアなどにより、データレイク４に蓄積されたデータを利用することができる。アプリケーションサーバ３は、データを処理するアプリケーションソフトウェアを実行するサーバ装置である。アプリケーションサーバ３は、アプリケーションソフトウェアで使用されるアプリケーションデータ７０を保持する。タグドメイン提示装置１０は、データレイク管理者に統一タグを付与する複数のタグドメインを提示する装置である。

データレイク４は、データレイク管理サーバ４０、管理者端末５０が、ネットワーク９で接続された構成である。ネットワーク９も、ＬＡＮでもグローバルネットワークでもよい。

データレイク管理サーバ４０は、データレイクにおけるデータとそのメタデータ（データレイクで取り扱うデータに対して付与されるデータ）を管理して、外部に提供するためのサーバ装置である。データレイク管理サーバ４０は、データレイク蓄積データ６０、タグストア６１、ビジネスグロッサリー６２、認証データストア６３を管理している。データレイク蓄積データ６０は、このデータレイクとして提供するためのデータであり、ＲＤＢ（Relational DataBase）のような構造化データでもよいし、ＩｏＴ（Internet of Things）で利用されるセンサの計測データのような非構造化データでもよい。タグストア６１は、データレイク蓄積データ６０に関して、検索のために付与されたタグとデータの対応を保持するデータストアである。ビジネスグロッサリー６２は、企業体のおける規範として定義された用語辞書である。本実施形態では、ビジネスグロッサリー６２に定義された用語とタグの一致度を調べるために利用される（詳細は後述）。認証データストア６３は、ユーザの認証情報を格納するデータストアである。

次に、図２ないし図１０を用いて情報処理システムの各コンポーネントの機能構成について説明する。

先ず、図２を用いてデータレイク管理サーバの機能構成について説明する。
データレイク管理サーバ４０は、図２に示されるように、認証部４１、データカタログ管理部４２、データ管理部４３の各機能部から構成される。

認証部４１は、データレイクにおけるデータカタログとデータをアクセスする者の権限を認証する機能部である。カタログ管理部４２は、データレイクにおけるデータカタログを管理する機能部である。ここで、データカタログとは、企業が保有するデータに対する辞書であり、本実施形態では、具体的には、タグストア６１、ビジネスグロッサリー６２である。データ管理部４３は、データレイクにおいて蓄積され取り扱うデータであるデータレイク蓄積データ６０を管理する機能部である。

なお、本実施形態においては、データレイク４の外部のアプリケーションサーバ３を利用する構成としているが、データレイク４内部にアプリケーションサーバ３を含めて、データレイク管理サーバ４０と統合する構成としてもよい。

次に、図３を用いてデータカタログ管理部のより詳細な機能構成について説明する。
データレイク管理サーバ４０のデータカタログ管理部４２は、図３に示されるように、検索部４２１、リネージ表示部４２２、データカタログ登録部４２３、ユーザ評価部４２４、タグ管理部４２５の各サブ機能部から構成される。

検索部４２１は、タグによるデータ検索の機能を提供する機能部である。リネージ表示部４２２は、データの利用来歴の表示データを生成する機能部である。データカタログ登録部４２３は、データに対するタグなどをデータカタログに登録する機能部である。ユーザ評価部４２４は、タグによる検索のユーザ評価を行う機能を提供する機能部である。タグ管理部４２５は、データレイクにおけるタグストア６１のタグを管理する機能部である。

次に、図４を用いて管理者端末の機能構成について説明する。
管理者端末５０は、図４に示されるように、データ登録部５１、データカタログ管理部５２、タグドメイン提示部５３、統一タグ定義部５４の各機能部から構成される。

データ登録部５１は、データレイクで取り扱うデータをデータレイク蓄積データ６０に登録する機能部である。データカタログ管理部５２は、データレイクで取り扱うデータカタログを管理する機能部である。タグドメイン提示部５３は、データレイクの管理者に対して、あるデータ利用の観点から概念的な共通点を有するタグドメインの候補を提示する機能部である。統一タグ定義部５４は、データレイクの管理者が、提示されたタグドメインに対する統一タグを定義するのをサポートする機能部である。

次に、図５を用いてタグドメイン提示装置の機能構成について説明する。
タグドメイン提示装置１０は、図５に示されるように、データ利用ログ管理部１１、ユーザ属性管理部１２、タグドメイン管理部１３、アプリケーション管理部１４の機能構成部からなり、各々の機能構成部は、それぞれデータ利用ログストア２１、ユーザ属性ストア２２、タグドメインストア２３、アプリケーション管理ストア２４を保持する。
なお、各々のデータストアに含まれるテーブルについては後に詳説する。

データ利用ログ管理部１１は、ユーザやアプリケーションソフトウェアからタグにより検索を利用した履歴の情報を管理する機能部である。ユーザ属性管理部１１は、ユーザ属性に関する情報を管理する機能部である。タグドメイン管理部１３は、あるデータ利用の観点から概念的な共通点を有するタグドメインを求めて、それを管理する機能部である。アプリケーション管理部１４は、あるデータ利用の観点から概念的な共通点を有するタグドメインを求める際に利用されるアプリケーションの情報を管理する機能部である。

次に、図６を用いてデータ利用ログ管理部のより詳細な機能構成について説明する。
タグドメイン提示装置１０のデータ利用ログ管理部１１は、図６に示されるように、データカタログ連携部１１１、アプリケーション連携部１１２、データ利用ログ生成部１１３の各サブ機能部から構成される。

データカタログ連携部１１１は、データレイク管理サーバ４０のデータカタログ管理部４２と連携し、データカタログの情報をアクセスする機能部である。アプリケーション連携部１１２は、アプリケーション管理部１４と連携し、アプリケーションソフトウェアの情報を取得する機能部である。データ利用ログ生成部１１３は、データ利用ログの情報を生成する機能部である。

タグドメイン提示装置１０のユーザ属性管理部１２は、図７に示されるように、認証連携部１２１、ユーザ属性情報生成部１２１の各サブ機能部からなる。認証連携部１２１は、データレイク管理サーバ４０の認証部４１と連携し、ユーザの認証情報をアクセスし、ユーザのプロファイル情報を取得する機能部である。ユーザ属性情報生成部１２１は、ユーザのプロファイル情報に基づきユーザ属性情報を生成する機能部である。ユーザ属性情報生成部１２１は、例えば、当該ユーザのプロファイル情報を基に、ユーザＩＤとユーザの所属部門、ユーザロールを紐づけ、ユーザ属性データを生成する。例えば、ユーザロールとして、「技術者」、「研究者」、「課長」、「部長」のようにビジネスロールを登録する。また、ユーザロールはデータマネジメントにおけるユーザロール（「Engineer」、「Analyst」、「Data Scientist」、「Data Steward」）に組織のビジネスロールをマッピングするようにしてもよい。

タグドメイン提示装置１０のタグドメイン管理部１３は、図８に示されるように、データ利用ログテーブルアクセス部１３１、利用観点抽出ログテーブル管理部１３２、固有タグ管理部１３３、ユーザ属性アクセス部１３４、利用傾向抽出部１３５、推薦タグドメイン生成部１３６、ビジネスグロッサリーアクセス部１３７、タグドメイン推薦条件管理部１３８の各サブ機能部からなる。

データ利用ログテーブルアクセス部１３１は、データ利用ログテーブル（後述）をアクセスする機能部である。利用観点抽出ログテーブル管理部１３２は、利用観点抽出ログテーブル（後述）を生成し管理する機能部である。固有タグ管理部１３３は、あるデータ利用の観点から概念的な共通点を有するタグドメインの候補を提示するために用いられる固有タグを管理する機能部である。ユーザ属性アクセス部１３４は、ユーザ属性情報をアクセスする機能部である。利用傾向抽出部１３５は、ユーザとアプリケーションソフトウェアからの使用に関する観点から固有タグの利用傾向の情報を抽出する機能部である。推薦タグドメイン生成部１３６は、あるデータ利用の観点から概念的な共通点を有するタグドメインの候補として推薦するタグドメインを生成する機能部である。ビジネスグロッサリーアクセス部１３７は、データレイクにおけるビジネスグロッサリー６２をアクセスする機能部である。タグドメイン推薦条件管理部１３８は、あるデータ利用の観点から概念的な共通点を有するタグドメインの候補として推薦するタグドメインを生成するための条件を管理する機能部である。

タグドメイン提示装置１０のアプリケーション管理部１４は、図９に示されるように、アプリケーション情報管理部１４１、アプリケーションパラメータ情報管理部１４の各サブ機能部からなる。

アプリケーション情報管理部１４１は、アプリケーションソフトウェアに関する情報を管理する機能部である。アプリケーションパラメータ情報管理部１４２は、アプリケーションソフトウェアが実行されるときに渡されるパラメータに関する情報を管理する機能部である。

次に、図１０を用いてタグドメイン提示装置のハードウェア・ソフトウェア構成について説明する。
タグドメイン提示装置１０のハードウェア構成としては、例えば、図１０に示されるパーソナルコンピュータのような一般的な情報処理装置で実現される。

タグドメイン提示装置１０は、ＣＰＵ（Central Processing Unit）８０２、主記憶装置８０４、ネットワークＩ／Ｆ（InterFace）８０６、表示Ｉ／Ｆ８０８、入出力Ｉ／Ｆ８１０、補助記憶Ｉ／Ｆ８１２が、バスにより結合された形態になっている。

ＣＰＵ８０２は、タグドメイン提示装置１０の各部を制御し、主記憶装置８０４に必要なプログラムをロードして実行する。

主記憶装置８０４は、通常、ＲＡＭなどの揮発メモリで構成され、ＣＰＵ８０２が実行するプログラム、参照するデータが記憶される。

ネットワークＩ／Ｆ８０６は、ネットワーク５と接続するためのインタフェースである。

表示Ｉ／Ｆ８０８は、ＬＣＤ（Liquid Crystal Display）などの表示装置８２０を接続するためのインタフェースである。

入出力Ｉ／Ｆ８１０は、入出力装置を接続するためのインタフェースである。図１０の例では、キーボード８３０とポインティングデバイスのマウス８３２が接続されている。

補助記憶Ｉ／Ｆ８１２は、ＨＤＤ（Hard Disk Drive）８５０やＳＳＤ（Solid State Drive）などの補助記憶装置を接続するためのインタフェースである。

ＨＤＤ８５０は、大容量の記憶容量を有しており、本実施形態を実行するためのプログラムが格納されている。タグドメイン提示装置１０には、データ利用ログ管理プログラム８６１、ユーザ属性管理プログラム８６２、タグドメイン管理プログラム８６３、アプリケーション管理プログラム８６４がインストールされている。

データ利用ログ管理プログラム８６１、ユーザ属性管理プログラム８６２、タグドメイン管理プログラム８６３、アプリケーション管理プログラム８６４は、それぞれ、データ利用ログ管理部１１、ユーザ属性管理部１２、タグドメイン管理部１３、アプリケーション管理部１４の機能を実現するプログラムである。

また、タグドメイン提示装置１０のＨＤＤ８５０は、データ利用ログストア２１、ユーザ属性ストア２２、タグドメインストア２３、アプリケーション管理ストア２４を保持する。

次に、図１１ないし図１８を用いて本実施形態のタグドメイン提示装置で扱われるデータ構造について説明する。

データ利用ログテーブル２００は、データを検索したときのログ情報とそのデータがどのようにアプリケーションソフトウェアに利用されたかの情報を格納するテーブルであり、図１１に示されるように、ログＩＤ２００ａ、ユーザＩＤ２００ｂ、検索利用タグ２００ｃ、ユーザ評価２００ｄ、利用データリスト２００ｅ、付与タグ２００ｆ、アプリケーションソフトウェア２００ｇ、アプリケーションパラメータ情報２００ｈの各カラムを有する。データ利用ログテーブル２００は、タグドメイン提示装置１０のデータ利用ログストア２１に格納される。

ログＩＤ２００ａには、このレコードを一意に識別する識別子が格納される。ユーザＩＤ２００ｂには、検索したユーザの識別子が格納される。検索利用タグ２００ｃには、ユーザが起動したアプリケーションソフトウェアによって検索のときに利用されたタグが格納される。ここで、例えば、ログＩＤ２００ａが「０００１」のレコードにおいて、「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ」、「プロセスＡ」のように列記されているのは、「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ」と「プロセスＡ」のＡＮＤ条件で検索したことを意味する。ユーザ評価２００ｄには、ユーザがデータを検索・利用の際に扱ったデータとデータに対して付与されている固有タグの整合性についてのユーザが評価したフラグが、付与タグ１８６の列記されている付与タグに対応して格納される（整合しているときには、「１」、整合していないときには、「０」）。利用データリスト２００ｅには、検索されたデータで、アプリケーションソフトウェアが利用したデータの情報が格納される。本実施形態では、例として、データがテーブル形式であり、テーブル名やカラム名を格納しているが、ファイル名や、ストレージの格納場所を示す情報であってもよい。付与タグ２００ｆには、固有タグテーブル（図１３により後述）に基づいて、利用データリスト２００ｅに格納されたデータに対して付与されている固有タグが格納される。ここで、例えば、ログＩＤ２００ａが「０００１」のレコードにおいて、「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ」、「プロセスＡ」のように列記されているのは、「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ」、「プロセスＡ」の双方が、利用データリスト２００ｅに列記された「Ｃｏｌｕｍｎ＿Ａ２」、「Ｃｏｌｕｍｎ＿Ａ３」の双方に付与タグとして定義されていることを意味する。アプリケーションソフトウェア２００ｇには、タグを用いて検索したアプリケーションソフトウェアに関する名称やＩＤが格納される。アプリケーションパラメータ情報２００ｈには、アプリケーションソフトウェアを起動したときのパラメータ情報が格納される。

このデータ利用ログテーブル２００は、データ利用ログ全件に関する情報を有するテーブルであり、データ利用ログの全件からデータ利用観点でフィルタリングして、利用観点抽出ログテーブル（図１２により後述）を生成するために用いるテーブルである。

利用観点抽出ログテーブル２１０は、データ利用ログテーブル２００をアプリケーションソフトウェアにおけるデータ利用観点でフィルタリングしたテーブルであり、図１２に示されるように、タグドメインＩＤ２１０ａ、ログＩＤ２１０ｂ、ユーザＩＤ２１０ｃ、検索利用タグ２１０ｄ、ユーザ評価２１０ｅ、利用データリスト２１０ｆ、付与タグ２１０ｇ、アプリケーションソフトウェア２１０ｈ、アプリケーションパラメータ情報２１０ｉの各カラムを有する。データ利用ログテーブル２００は、タグドメイン提示装置１０のデータ利用ログストア２１に格納される。

利用観点抽出ログテーブル２１０は、データ利用観点（本実施形態では、「製品故障率分析利用」の観点）ごとにデータ利用ログテーブル２００からフィルタリングされ、生成されたテーブルであり、データ利用ログテーブル２００のフィルタリングされたレコードの各カラムにタグドメインＩＤ２１０ａのカラムを付加したものである。データ利用観点ごとに生成されるタグドメインの一連のグループを一意的に識別する識別子が格納される。それ以降のログＩＤ２１０ｂ、ユーザＩＤ２１０ｃ、検索利用タグ２１０ｄ、ユーザ評価２１０ｅ、利用データリスト２１０ｆ、付与タグ２１０ｇ、アプリケーションソフトウェア２１０ｈ、アプリケーションパラメータ情報２１０ｉは、それぞれデータ利用ログテーブル２００のログＩＤ２００ａ、ユーザＩＤ２００ｂ、検索利用タグ２００ｃ、ユーザ評価２００ｄ、利用データリスト２００ｅ、付与タグ２００ｆ、アプリケーションソフトウェア２００ｇ、アプリケーションパラメータ情報２００ｈに対応するカラムである。

固有タグテーブル２２０は、固有タグに関する情報を格納するテーブルであり、図１３に示されるように、固有タグ２２０ａ、部門２２０ｂ、付与先データリスト２２０ｃの各カラムを有する。固有タグテーブル２２０は、タグドメイン提示装置１０のタグドメインストア２３に格納される。

固有タグ２２０ａには、対象とされる固有タグが格納される。所属２２０ｂには、該当する固有タグがどの部門の固有タグであるかを示す情報が格納される。付与先データリスト２２０ｃには、該当する固有タグがその部門において検索される対象となるデータの情報が格納される。

アプリケーションテーブル２３０は、タグにより検索されたデータを利用するアプリケーションソフトウェアの情報を格納するテーブルであり、図１４Ａに示されるように、プロジェクト名２３０ａ、プロジェクトカテゴリ２３０ｂ、アプリケーション名２３０ｃ、処理ステップ２３０ｐｉ（ｉ＝１，２，３，…）の各カラムを有する。

アプリケーションテーブル２３０は、アプリケーションサーバ３のアプリケーションデータ７０に事前に登録されているアプリケーションの情報に基づいて生成され、タグドメイン提示装置１０のアプリケーション管理ストア２４に格納される。

プロジェクト名２３０ａには、対象となるアプリケーションの企業内におけるプロジェクト名称が格納される。プロジェクトカテゴリ２３０ｂには、対象となるアプリケーションの企業内におけるプロジェクトのカテゴリ名称が格納される。図１４Ａの例では、プロジェクト名が「Ａ製品生産プロジェクト」のプロジェクトに対して、そのプロジェクトのカテゴリ名称は、故障率分析であることを示している。
アプリケーションソフトウェア名称２３０ｃには、対象となるアプリケーションソフトウェアの名称が格納される。本実施形態のアプリケーションソフトウェア名称２３０ｃは、システムで一意に定まるものとする。処理ステップ２３０ｐｉ（ｉ＝１，２，３，…）には、対象となるアプリケーションソフトウェアの処理ステップに関する情報が格納される。

処理ステップ２３０ｐｉは、それぞれのカラムが種別ｄｉｋ、固有情報ｄｉｓからなる。種別ｄｉｋには、そのステップにおける機能が「入力」、「変換」、「出力」などのように格納される。固有情報ｄｉｓには、そのステップで呼び出すアプリケーションソフトウェアの情報や設定するパラメータなどの必要な情報を格納する。

アプリケーションパラメータ情報テーブル２４０は、アプリケーションソフトウェアのパラメータに関する情報を格納するテーブルであり、図１４Ｂに示されるように、パラメータＩＤ２４０ａ、アプリケーションソフトウェア名称２４０ｂ、パラメータ情報２４０ｃの各カラムを有する。本実施形態では、データ分析に利用したアプリケーションパラメータをログ情報から抽出し、履歴として保持しているが、アプリケーションテーブル２３０の作成したときは同様に事前に定義、分類した構成をとってもよい。

パラメータＩＤ２４０ａには、そのパラメータを一意に識別する識別子が格納される。アプリケーションソフトウェア名称には、そのパラメータにより呼び出されるアプリケーションソフトウェアの名称が格納される。パラメータ情報２４０ｃには、具体的なパラメータの値の情報が格納される。

ユーザ属性テーブル２５０は、アプリケーションソフトウェアを利用するユーザの属性を格納するテーブルであり、図１５Ａに示されるように、ユーザＩＤ２５０ａ、部門２５０ｂ、ユーザロール２５０ｃの各カラムを有する。ユーザ属性テーブル２５０は、データレイク管理サーバ４０の保持する認証データストア６３から取得するユーザのプロファイル情報に基づいて、データ利用傾向をユーザの属性の観点で評価するために用いる（詳細は、後述）。ユーザ属性テーブル２５０は、タグドメイン提示装置１０のユーザ属性ストア２２に格納される。

ユーザＩＤ２５０ａには、ユーザを識別する一意的な識別子が格納される。部門２５０ｂには、そのユーザの属する部面の名称が格納される。ユーザロール２５０ｃには、そのユーザの企業体における役割を表す情報が格納される。

ユーザ属性重みテーブル２６０は、タグドメインにおけるユーザ評価を計算するために用いられるために、ユーザロールごとのユーザ属性重みを保持するテーブルであり、図１５Ｂに示されるように、ユーザロール２６０ａ、同部門重み２６０ｂ、異部門重み２６０ｃの各カラムを有する。

ユーザロール２６０ａには、ユーザ属性テーブル２５０のユーザロール２５０ｃと同様のユーザの役割を表す名称が格納される。同部門重み２６０ｂ、異部門重み２６０ｃには、それぞれタグドメインを評価するときの固有タグが同部門であるか異部門であるかに従ったユーザ評価の際の重みづけの値が格納される。

同部門２４２、異部門２４３は固有タグが定義された部門に対して、ユーザの所属が同部門もしくは異部門であるかで重みを変化させる。本実施形態では、ユーザ属性重みは管理者による事前定義に基づくとするが、利用傾向によって重みを変更させてもよい。本実施形態では、異部門のユーザによる評価を大きくしているが、管理者の入力により重みを変更可能としてもよい。本実施形態では各ユーザ属性の重みを一番値の小さいものを１とした際の相対値として算出する。例えば、各ユーザロールの存在比の逆比として算出する（すなわち、企業内で数が少ない「Ｄａｔａ Ｓｔｅｗａｒｄ」（データ管理者）などの重みづけを大きくする）。

ここで、利用傾向評価テーブル、タグドメイン推薦テーブル、推薦タグドメインテーブルを説明する前に、図１９を用いてこれらのテーブルで用いられるタグドメインの領域分割のタイプについて説明する。

図１２に示した利用観点抽出ログテーブル２１０の場合には、部門「Ａ工場」の付与タグ２１０ｇとして「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ」，「プロセスＡ」が存在する。

ここで、本実施形態では、タグドメインの判定タイプとして、図１９（ａ）に示されるようなタイプＡと図１９（ｂ）に示されるようなタイプＢを用いる。

タイプＡでは、タグドメインを構成する領域の分割として（Ａ）：「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＡＮＤ プロセスＡ」、（Ｂ）：「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＯＲ プロセスＡ」、（Ｃ）：「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ」、（Ｄ）：「プロセスＡ」であるとする。

一方、タイプＢでは、（１）：「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＡＮＤ プロセスＡ」、（２）：「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＮＡＮＤ プロセスＡ」、（３）：「プロセスＡ ＮＡＮＤ Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ」であるとする。

そして、タイプＡとタイプＢで分割されたそれぞれの領域は、（Ａ）：（１）、（Ｂ）：（１）＋（２）＋（３）、（Ｃ）：（１）＋（２）、（Ｄ）：（１）＋（３）に対応する。

タイプＢでは、領域の分割がＤｉｓｊｏｉｎｔな分割（直和分割）になっていることが特徴である。これは、各々に属する分析の値を計算しやすくするためであり、以下の利用傾向評価テーブルの分析タグドメインの分割に利用される。

利用傾向評価テーブル２７０は、図１２に示した利用観点抽出ログテーブル２１０において、付与タグにより生成されるタグドメインが、アプリケーションソフトウェアによりどのように利用されていたかの情報を保持するテーブルであり、図１６に示されるように、分析用タグドメイン２７０ａ、部門２７０ｂ、関連利用率２７０ｃ、ユーザ利用率２７０ｄ、ユーザ評価平均２７０ｅの各カラムを有する。

利用傾向評価テーブル２７０は、データの利用観点ごとに一つ作成されるテーブルであり、図１６では、データ利用観点として、「製品故障分析」の例が示されている。利用傾向評価テーブル２７０は、タグドメイン提示装置１０の利用傾向抽出部１３５により抽出されるテーブルであり、後述するタグドメイン抽出処理において、利用観点抽出ログテーブル２１０、ユーザ属性テーブル２５０、固有タグテーブル２２０に格納された情報に基づいて作成される。

分析用タグドメイン２７０ａには、利用傾向を評価するタグドメインが格納される。分析用タグドメイン２７０ａは、タグドメインの領域分割において、図１９（ｂ）のタイプＢにより定義されたタグドメインで記述される。部門２７０ｂには、該当する分析タグドメインの部門が格納される。関連利用率２７０ｃには、あるタグドメインに対応するデータに対して、他のタグドメインのアプリケーションソフトウェアに関する利用率が格納される。ここで、ｉ行の分析タグドメインとｊ列の関連利用率に定義された値は、以下の（式１）で定義される。ここで、ｉ行の分析タグドメインは、図１６のように、分析用タグドメインの（１）「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＡＮＤ プロセスＡ」、（２）「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＮＡＮＤ プロセスＡ」、…と表記している。ｊ列についても同様である。

関連利用率２７０ｃの（ｉ行目、ｊ列目）の値＝（ｉ行のタグドメインに対応するデータに対して、ｉ行のタグドメインとｊ列のタグドメインをアプリケーションソフトウェアが使用した回数）／（ｉ行のタグドメインに対応するデータに対して、ｉ行のタグドメインをアプリケーションソフトウェア使用した回数） …（式１）

ユーザ利用率２７０ｄには、該当するタグドメインに対応するデータを利用したのが、同部門であるか、異部門であるかの割合が格納される。例えば、（１）「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＡＮＤ プロセスＡ」のタグドメインの部門は、「工場Ａ」なので、このデータをアプリケーションソフトウェアにより、利用したユーザの部門が「工場Ａ」のときには、同部門としてカウントされ、それ以外のときには、異部門としてカウントされた割合が格納される。ユーザ評価平均２７０ｅには、利用観点抽出ログテーブル２１０のユーザ評価２１０ｅを反映した値の平均値が格納される。このときには、評価したユーザによって、図１５Ｂのユーザ属性重みテーブル２６０により重みづけをした以下の（式２）により計算する。

ここで、分母、分子のΣは、分析用タグドメインの該当する利用観点抽出ログテーブル２１０の該当するレコードのユーザ評価にわたって総和をとることを意味し、ｃ_ｉは、そのレコードのユーザＩＤ２１０ｃのユーザの同部門、異部門の重みづけであるユーザ属性重みテーブル２６０の同部門重み２６０ｂ、異部門重み２６０ｃの値であり、ｅ_ｉは、そのレコードのユーザ評価２００ｄの値である０または１である。

例えば、ある分析用ドメインに対応するユーザ評価として、ユーザロールが、同部門「Ｄａｔａ Ｓｔｅｗａｒｄ」のユーザ評価「１」、同部門「Ａｎａｌｙｓｔ」のユーザ評価「１」、異部門「Ａｎａｌｙｓｔ」のユーザ評価「０」、異部門「Ｅｎｇｉｎｅｅｒ」のユーザ評価「１」のときには、（６０×１＋２×１＋４×０＋２×１）／（６０＋２＋４＋２）＝６４／６７≒０．９６となる。

タグドメイン推薦値テーブル２８０は、タグドメインに関する推薦値を決定するためのテーブルであり、図１７に示されるように、タグドメインＩＤ２８０ａ、タグドメイン候補２８０ｂ、部門２８０ｃ、利用傾向値２８０ｄ、ユーザ評価値２８０ｅ、ビジネスグロッサリー一致度２８０ｆ、タグドメイン推薦値２８０ｇの各カラムを有する。

タグドメイン推薦値テーブル２８０は、タグドメイン提示装置１０のタグドメイン推薦値管理部１３８により作成されるテーブルであり、後述するタグドメイン推薦値算出処理において、利用傾向評価テーブル２７０、ビジネスグロッサリー定義（図示せず）を用いて生成されるテーブルである。ビジネスグロッサリー定義は、例えば、データレイク管理サーバ４０が管理するビジネスグロッサリー６２に格納されている固有タグ名称、付与先テーブル・カラムの組から作成される。

タグドメインＩＤ２８０ａには、データレイク管理者に提示する候補となるタグドメインを一意的に表す識別子が格納される。タグドメイン候補２８０ｂには、データレイク管理者に提示する候補となるタグドメインが格納される。タグドメイン候補２８０ｂのタグドメインは、図１９（ａ）で示したタイプＡの形式で記述する。部門２８０ｃには、該当する候補となるタグドメインの部門が格納される。利用傾向値２８０ｄには、図１６の利用傾向評価テーブル２７０の情報に基づいた該当する候補となるタグドメインの利用傾向値が格納される。利用傾向値の求め方の詳細は、後述する。ユーザ評価値２８０ｅには、候補となるタグドメインのユーザ評価値が格納される。ユーザ評価値の求め方の詳細は、後述する。ビジネスグロッサリー一致度２８０ｆには、候補となるタグドメインのビジネスグロッサリー一致度の値が格納される。ビジネスグロッサリー一致度の求め方の詳細は、後述する。タグドメイン推薦値２８０ｇには、利用傾向値２８０ｄの値、ユーザ評価値２８０ｅの値、ビジネスグロッサリー一致度２８０ｆの値を合計した値が、総合推薦値として格納される。

次に、利用傾向値２８０ｄに格納される利用傾向値の求め方について説明する。
利用傾向値とは、候補となるタグドメインについて、ユーザとアプリケーションソフトウェアのタグドメインに対応するデータについての利用傾向を評価する値である。

先ず、図１６の利用傾向評価テーブル２７０の関連利用率２７０ｃとユーザ利用率２７０ｄのカラムの値を、それぞれの要素とする行ベクトル（図１６の例では、８次元）を生成する。ここで、それぞれの分析用タグドメイン（１）～（６）に対応するベクトルを、ｖ_１～ｖ_６とする。

次に、部門２７０ｂの値を参照して、それぞれのベクトルの類似度を例えば、コサイン類似度を用いて計算する。コサイン類似度とは、ベクトル間のコサインを内積で表現したときの式を利用した類似度の評価であり、ベクトルｖ、ｕに対するコサイン類似度は、以下の（式３）で表され、１に近いほどそれらのベクトルは類似し、０に近いほどそれらのベクトルは類似しないとされる。

ここで、（式３）の分子は、ベクトルｖ、ｕのノルムの積であり、分母は、ベクトルｖ、ｕの内積である。

例えば、「Ａ工場」の部門においては、ｖ_１，ｖ_２，ｖ_３間のコサイン類似度が、３通り求められる。ここで、（ｖ_１，ｖ_２）間のコサイン類似度が一番大きく、かつ、そのコサイン類似度が所定の閾値（例えば、０．８）を越えているときには、分析用タグドメイン（１）の領域と、分析用タグドメイン（２）の領域に対応するタグドメイン候補（図１９のタイプＡの（Ｃ）「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ」）の利用傾向値を、「１」として、他の「Ａ工場」の部門のタグドメインの利用傾向値を、「０」とする。

また、「Ａ工場」の部門においては、ｖ_１，ｖ_２，ｖ_３間のコサイン類似度が、全て、所定の閾値を越えなかったときには、他の部門「Ｂ工場」との関連利用率で一番大きい値を有する分析用タグドメインに対応するタグドメイン候補の利用傾向値を、「１」として、他の「Ａ工場」の部門のタグドメインの利用傾向値を、「０」とする。図１９の例では、分析用タグドメイン（１）の関連利用率（４）の値が、「０．４２」となっているので、分析用タグドメイン（１）に対応するタグドメイン候補の「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＡＮＤ プロセスＡ」の利用傾向値が「１」とされる。

次に、ユーザ評価値２８０ｅに格納されるタグドメインのユーザ評価値の求め方について説明する。

ユーザ評価値は、図１６の利用傾向評価テーブル２７０の分析用タグドメインごとのユーザ評価平均２７０ｃの値を、タグドメイン候補の値として平均をとることにより求められる。
例えば、（Ｂ）「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＯＲ プロセスＡ」のユーザ評価値は、（分析用タグドメイン（１）のユーザ評価値＋分析用タグドメイン（２）のユーザ評価値＋分析用タグドメイン（３）のユーザ評価値）／３である。

次に、ビジネスグロッサリー一致度２８０ｆには、格納されるビジネスグロッサリー一致度の求め方につい説明する。

ビジネスグロッサリー一致度２８０ｆは、タグドメイン候補に使用されている付与タグの名称（例えば、「Ｓｈｉｎｄｏ＿ｓｅｎｓｏｒ ＡＮＤ プロセスＡ」のときには、「Ｓｈｉｎｄｏ＿sｅｎｓｏｒ」、「プロセスＡ」）とビジネスグロッサリーに定義されているタグドメインの名称の文字列としての一致度を見ることにより求める。例えば、完全一致しているときには、「０．５」とし、一致しないものがあるときには、「０」とする。また、タグドメイン候補に使用されている文字列とビジネスグロッサリーに定義されているタグドメインの名称の文字列がどの程度の一致率を有するかを、０～１の数値で表すことにしてもよい。

タグドメインテーブル２９０は、データ管理者に提示するタグドメインに関する情報を保持するテーブルであり、図１８に示されるように、タグドメインＩＤ２９０ａ、統一タグ名称２９０ｂ、タグドメイン２９０ｃ、部門２９０ｄ、付与先テーブル・カラム２９０ｅの各カラムを有する。

タグドメインＩＤ２９０ａには、このテーブルで保持するタグドメインを一意的に識別する識別子が格納される。統一タグ名称２９０ｂには、データ管理者が提示されたタグドメインに付与した統一タグ名称が格納される。タグドメイン２９０ｃには、部門ごとのタグドメインが格納される。部門２９０ｄには、タグドメインを定義している付与タグに関する部門の情報が格納される。付与先テーブル・カラム２９０ｅには、該当するタグドメインと対応するテーブル名やカラムに関する情報が格納される。

タグドメインテーブル２９０は、タグドメイン提示装置１０のタグドメイン管理部で生成される。

統一タグ名称については、後述するタグドメイン抽出処理の後、候補となるタグドメインを管理者への提示後、データ管理者が、提示されたタグドメインに対して付与する統一タグの名称を入力する（ユーザインタフェースの詳細については、後述）。そして、タグドメイン提示装置１０のタグドメイン管理部は、入力として受けた統一タグ名称の情報と、抽出したタグドメインの情報に基づいてタグドメインテーブル２９０を生成する。

例えば、図１８には、統一タグ名称として、データ管理者から「Ａ工程_振動センサデータ」の入力を受け、抽出したタグドメインとタグドメインＩＤ２６１に紐づけてタグドメインテーブル２９０として生成される例が示されている。

次に、図２０ないし図２４を用いてタグドメイン提示装置の行う処理について説明する。

先ず、図２０を用いてデータ利用ログの蓄積から、データレイク管理者にタグドメインを提示するまでの一連の処理について説明する。
データレイク管理サーバ４０のデータカタログ管理部４２から、データ利用者からデータ検索、選定および利用の要求を受信した場合に、タグドメイン提示装置１０のデータ利用ログ管理部１１に通知される。

タグドメイン提示装置１０のデータ利用ログ管理部１１は、それを新規のデータ利用ログとして、データ利用ログストア２１のデータ利用ログテーブル２００に格納し（Ｓ３０１：Ｙ）、Ｓ３０２に行く。

次に、タグドメイン提示装置１０のタグドメイン管理部１３は、データ利用ログテーブル２００の新規に登録されたレコードとタグドメインテーブル２９０の登録済みのレコードを取得する（Ｓ３０２）。

次に、タグドメイン提示装置１０のタグドメイン管理部１３は、データ利用ログテーブル２００の新規に登録されたレコードについて、データ利用ログテーブル２００の付与タグ２００ｆの内の少なくとも一つ以上の組合せで表現できるタグドメインが、タグドメインテーブル２９０のタグドメイン２９０ｃのカラムに登録されているか否かを検索する。

そして、データ利用ログテーブル２００の新規に登録されたレコードについて、タグドメインテーブル２９０のタグドメイン２９０ｃに、データ利用ログテーブル２００の付与タグ２００ｆの組合せで表現できるタグドメインが含まれているときには（Ｓ３０３：Ｙ）、Ｓ３０４に行き、含まれていないときには（Ｓ３０３：Ｎ）、Ｓ３０６に行く。

タグドメインテーブル２９０のタグドメイン２９０ｃに、データ利用ログテーブル２００の付与タグ２００ｆの組合せで表現できるタグドメインが含まれているときには、該当するタグドメインＩＤ２９０ａのタグドメインの値を、タグドメインＩＤ２１０ａの値として有する利用観点抽出ログテーブル２１０を取得する（Ｓ３０４）。

データ利用ログテーブル２００の新規に登録されたレコードについて、データ利用ログテーブル２００のレコードの値を、取得した当該利用観点抽出ログテーブル２１０のログＩＤ２１０ｂ、ユーザＩＤ２１０ｃ、検索利用タグ２１０ｄ、ユーザ評価２１０ｅ、利用データリスト２１０ｆ、付与タグ２１０ｇ、アプリケーションソフトウェア２１０ｈ、アプリケーションパラメータ情報２１０ｉにコピーしたレコードを作製し、タグドメインＩＤ２１０ａに、タグドメインテーブル２９０のタグドメインＩＤ２９０ａの値を代入する（Ｓ３０５）。

タグドメインテーブル２９０のタグドメイン２９０ｃに、データ利用ログテーブル２００の付与タグ２００ｆの組合せで表現できるタグドメインが含まれていないときには、データ利用ログテーブルのレコード間の類似度を計算する（Ｓ３０６）。

データ利用ログテーブルのレコード間の類似度を計算する処理は、後に、図２１Ａおよび図２１Ｂを用いて説明する。

そして、類似度が一定以上のデータ利用ログテーブル２００のレコードから、利用観点抽出ログテーブル２１０のログＩＤ２１０ｂ、ユーザＩＤ２１０ｃ、検索利用タグ２１０ｄ、ユーザ評価２１０ｅ、利用データリスト２１０ｆ、付与タグ２１０ｇ、アプリケーションソフトウェア２１０ｈ、アプリケーションパラメータ情報２１０ｉに値をコピーしたレコードを作製し、タグドメインＩＤ２１０ａに、新しいＩＤの値を代入し、それらのレコードから新規の利用観点抽出ログテーブル２１０を生成する（Ｓ３０７）。

次に、図２１Ａおよび図２１Ｂを用いてデータ利用ログのレコード間の類似度を算出する処理について説明する。

この処理は、図２０のＳ３０６に該当する処理であり、タグドメイン提示装置１０のタグドメイン管理部１３の利用観点抽出ログテーブル管理部１３２が行う処理である。

先ず、タグドメイン提示装置１０のタグドメイン管理部１３は、未取得の新規のデータ利用ログテーブル２００のレコードがあるか否かを判定し（Ｓ４０１）、未取得の新規のデータ利用ログテーブル２００のレコードがあるときには（Ｓ４０１：Ｙ）、Ｓ４０２に行き、未取得の新規のデータ利用ログテーブル２００のレコードがないときには（Ｓ４０１：Ｎ）、処理を終了する。

未取得の新規のデータ利用ログテーブル２００のレコードがあるときには、ＲＥＣ１←未取得の新規のデータ利用ログテーブル２００のレコードとする（Ｓ４０２）。

次に、タグドメイン提示装置１０のタグドメイン管理部１３は、ＲＥＣ１以外の未取得のデータ利用ログテーブル２００のレコードがあるか否かを判定し（Ｓ４０３）、ＲＥＣ１以外の未取得のデータ利用ログテーブル２００のレコードがあるときには（Ｓ４０３：Ｙ）、Ｓ４０４に行き、未取得の新規のデータ利用ログテーブル２００のレコードがないときには（Ｓ４０３：Ｎ）、Ｓ４０１に戻る。

ＲＥＣ１以外の未取得のデータ利用ログテーブル２００のレコードがあるときには、ＲＥＣ２←ＲＥＣ１以外の未取得のデータ利用ログテーブル２００のレコードとする（Ｓ４０４）。

次に、ＲＥＣ１の検索利用タグ２００ｃに含まれる固有タグが、ＲＥＣ２の検索利用タグ２００ｃに含まれているか否かを判定する（Ｓ４０５）。含まれている場合には（Ｓ４０５：Ｙ）、Ｘ_１＝１．０に設定し（Ｓ４０６）、含まれていない場合には、Ｘ_１＝０に設定する（Ｓ４０７）。

次に、ＲＥＣ１の付与タグ２００ｆに含まれる固有タグが、ＲＥＣ２の付与タグ２００ｆに含まれているか否かを判定する（Ｓ４０８）。含まれている場合には（Ｓ４０８：Ｙ）、Ｘ_２＝１．０に設定し（Ｓ４０９）、含まれていない場合には、Ｘ_２＝０に設定する（Ｓ４１０）。

本実施形態では、ＲＥＣ１の付与タグに含まれる固有タグがＲＥＣ２の付与タグに含まれる場合で場合分けを設定しているが、完全に一致する場合、ＲＥＣ１の付与タグがＲＥＣ２の付与タグの部分集合となっている場合等、細かく場合分けを設定して、Ｘ_２の値を定めることにしてもよい。

次に、ＲＥＣ１とＲＥＣ２のアプリケーションソフトウェア２００ｇ、図１４Ａのアプリケーションテーブル２３０を参照し、アプリケーションソフトウェアの名称が同一名称か、同一のプロジェクトカテゴリであるか否かを判定する（Ｓ４１１）。

アプリケーションソフトウェアの名称が同一名称か、同一のプロジェクトカテゴリであるときには、（Ｓ４１１：Ｙ）、Ｘ_３＝１．０に設定し（Ｓ４１２）、名称が異なるが、同一のプロジェクトカテゴリであるときには（Ｓ４１１：Ｙ）、Ｘ_３＝０．５に設定し（Ｓ４１２）、それらの条件を満たさないときには（Ｓ４１１：Ｎ）、Ｘ_３＝０に設定する（Ｓ４１０）。

本実施形態では、アプリケーションソフトウェアの名称が同一であるか、同プロジェクトカテゴリに含まれるかで場合分けを設定したが、図１４Ａのアプリケーションテーブル２３０で表現される処理ステップ毎の一致度、ステップの順序等細かく場合分けを設定して、Ｘ_３を設定してもよい。

次に、ＲＥＣ１とＲＥＣ２のアプリケーションパラメータ情報２００ｈを参照し、アプリケーションソフトウェアのパラメータ情報が一致するか否かを判定する（Ｓ４１４）。一致する場合には（Ｓ４０８：Ｙ）、Ｘ_４＝１．０に設定し（Ｓ４１５）、一致しない場合には、Ｘ_４＝０に設定する（Ｓ４１６）。

本実施形態では、一致しているか否かの場合分けとしているが、アプリパラメータに関する辞書を設定し、同義のパラメータ群を定義して一致度を算出して、Ｘ_４を設定してもよい。

次に、上記の設定したＸ_１～Ｘ_４に基づいて、ＲＥＣ１とＲＥＣ２の類似度Ｒを算出する（Ｓ４１７）。ＲＥＣ１とＲＥＣ２の類似度Ｒは、例えば、以下の（式４）で表れる各変数を重みづけた線形式で算出する。

Ｒ＝ａ_１×Ｘ_１＋ａ_２×Ｘ_２＋ａ_３×Ｘ_３＋ａ_４×Ｘ_４ …（式４）

ここで、ａ_１～ａ_４は、それぞれ変数Ｘ_１～Ｘ_４に対応する重みづけ係数であり、例えば、アプリケーションソフトウェアの一致度を重要視するなら、ａ_１＝０．１，ａ_２＝０．２，ａ_３＝０．５，ａ_４＝０．２として、類似度を算出する。本実施形態の図２１Ａおよび図２１Ｂに示される処理では、比較項目ごと比較結果に対して重みをつけて計算したが、重みづけの手法、および類似度を算出する手法については、データレイクの構成に応じて変更してもよい。

次に、類似度Ｒが、一定の閾値以上か否かを判定し（Ｓ４１８）、類似度Ｒが、一定の閾値以上のときには（Ｓ４１８：Ｙ）、ＲＥＣ１とＲＥＣ２をワークメモリに記憶する（Ｓ４１９）。
そして、Ｓ４０３に戻る。

次に、図２２を用いてデータレイク管理者にタグドメインを提示する一連の処理について説明する。
この処理は、タグドメイン提示装置１０のタグドメイン管理部１３が行う処理である。

先ず、タグドメイン提示装置１０のタグドメイン管理部１３の利用観点抽出ログテーブル管理部１３２は、利用観点抽出ログテーブル２１０の更新があったか否かを判定する（Ｓ５０１）。更新があった場合には（Ｓ５０１：Ｙ）、更新された該当の利用観点抽出ログテーブル２１０のデータを取得する（Ｓ５０２）。

次に、タグドメイン提示装置１０のタグドメイン管理部１３の固有タグ管理部は、固有タグテーブル２２０のデータを取得する（Ｓ５０３）。

次に、タグドメイン提示装置１０のタグドメイン管理部１３のユーザ属性アクセス部１３４は、タグドメイン提示装置１０のユーザ属性管理部１２のユーザ属性ストア１３から、該当するユーザ属性テーブルのデータを取得する（Ｓ５０４）。

次に、タグドメイン提示装置１０のタグドメイン管理部１３のユーザ属性アクセス部１３４は、タグドメイン提示装置１０のユーザ属性管理部１２のユーザ属性ストア１３から、ユーザ属性重みテーブル２６０のデータを取得する（Ｓ５０５）。

次に、タグドメイン提示装置１０のタグドメイン管理部１３が、タグドメイン抽出処理を実施する（Ｓ５０６）。なお、タグドメイン抽出処理の詳細は、図２３を用いて後述する。

次に、タグドメイン提示装置１０は、タグドメイン管理部１３の推薦タグドメイン生成部１３６で生成されたタグドメインの推薦結果を、管理者端末５０に送信する。管理者端末５０のタグドメイン提示部５３は、タグドメイン推薦画面を表示出力、データレイク管理者に対して推薦するタグドメインを提示する（Ｓ５０７）。なお、タグドメイン推薦画面のユーザインタフェースは、後に、図２４を用いて説明する。

次に、タグドメイン提示装置１０は、タグドメイン推薦画面から統一タグ名称の入力を受け付け、入力があったときには（Ｓ５０８：Ｙ）、入力された統一タグ名称を取得する（Ｓ５０９）。

次に、Ｓ３４０において、提示したタグドメイン、タグドメイン推薦値テーブル２８０からタグドメインＩＤ２６１の値と、タグドメイン推薦画面から入力されたデータからタグドメインテーブル２９０を生成し、タグドメインストア２３に登録する（Ｓ５１０）。

次に、タグドメインテーブル２９０の付与先テーブル・カラム２９０ｅと統一タグ名称２９０ｂに基づき、新たなタグとして、データレイク管理サーバ４０のタグストア６１に登録する（Ｓ５１０）。これにより、一般のユーザが統一タグ名称のタグを、データ検索に用いることが可能になる。

次に、図２３を用いて推薦タグドメインを抽出する処理について説明する。
これは、図２２のＳ５０６に該当する処理である。

先ず、タグドメイン提示装置１０のタグドメイン管理部１３は、利用観点抽出ログテーブル２１０の付与タグ２１０ｇと固有タグテーブル２２０の固有タグ２２０ａをマッチングさせて、付与タグ２１０ｇのタグに該当する部門２２０ｂの値を抽出する（Ｓ６０１）。

次に、タグドメイン提示装置１０のタグドメイン管理部１３は、利用観点抽出ログテーブル２１０の付与タグ２１０ｇから、検索式として組み合わせられるタグドメインを生成する（Ｓ６０２）。タグドメインを生成の仕方は、タイプＡとタイプＢがあることを、既に図１９を用いて説明した。

次に、タグドメイン提示装置１０のタグドメイン管理部１３の利用傾向抽出部１３５は、利用観点抽出ログテーブル２１０の各レコードに対し、Ｓ６０３～Ｓ６０７のループ処理を実行する。

先ず、利用観点抽出ログテーブル２１０のレコードに対して、付与タグ２１０ｇが、部門が異なる固有タグを有するか否かを判定する（Ｓ６０３）。

そのレコードの付与タグの値として、部門が異なる固有タグを有さない場合には（Ｓ６０３：Ｎ）、付与タグ２１０ｇが該当するＳ６０１で生成した分析用タグドメイン（タイプＢ）を検索し、そのレコードの一件をその部門の利用回数としてカウントする（Ｓ６０５）。

そのレコードの付与タグの値として、部門が異なる固有タグを有する場合には（Ｓ６０３：Ｙ）、該当する分析用タグドメイン（タイプＢ）を検索し、その部門における利用回数としてカウントする事に加え、その他の部門における利用回数としてカウントする。

次に、タグドメイン提示装置１０のタグドメイン管理部１３は、利用観点抽出ログテーブル２１０のユーザＩＤ２１０ｃとユーザ属性テーブル２５０のユーザＩＤ２５０ａに基づいて、ユーザと利用したデータの属するタグドメインが同部門か異部門かを判定して、それぞれカウントする（Ｓ６０６）。本実施形態では、ユーザの部門とデータの属するタグドメインの部門が一致するか否かで場合分けしているが、部門に加えユーザロールを含めて細かく場合分けを行ってもよい。

次に、タグドメイン提示装置１０のタグドメイン管理部１３は、利用観点抽出ログテーブル２１０のユーザ評価２１０ｅとユーザＩＤ２１０ｃ、ユーザ属性テーブル２５０のユーザＩＤ２５０ａ、ユーザ属性重みテーブル２６０の値に基づいて、それぞれの分析用タグドメインに対するユーザ評価平均を算出する（Ｓ６０７）。ユーザ評価平均を算出の際には、ユーザ評価２１０ｅの値に対し、ユーザ属性テーブル２５０とユーザ属性重みテーブル２６０に設定された値により、該当ユーザの相対値として算出されたユーザ評価に対する重み（同部門重み２６０ｂ、異部門重み２６０ｃ）を取得し、ユーザ評価に対する重みを各評価値に乗じたユーザ評価平均を算出する（（式２）参照））。

ループを抜けたときに、各分析タグドメイン２７０ａの領域に対して、関連利用率２７０ｃ、ユーザ利用率２７０ｄ、ユーザ評価平均２７０ｅの値を算出し、利用傾向評価テーブル２７０の各カラムに設定する（Ｓ６０８）。各カラムの値の求め方は、既に説明した所である。

次に、タグドメイン提示装置１０のタグドメイン管理部１３のビジネスグロッサリーアクセス部１３７で、データカタログサーバ２４のビジネスグロッサリー６２で定義されているビジネスグロッサリー定義を取得する（Ｓ６０９）。

次に、利用傾向評価テーブル２７０の各分析タグドメインに対する値を参照し、タグドメイン候補２８０ｂの領域に対するそれぞれの利用傾向値２８０ｄの値、ユーザ評価値２８０ｅの値、ビジネスグロッサリー一致度２８０ｆの値をそれぞれ算出し、タグドメイン推薦値テーブル２８０の各カラムに設定する（Ｓ６１０）。利用傾向値２８０ｄの値、ユーザ評価値２８０ｅの値、ビジネスグロッサリー一致度２８０ｆの求め方については、既に説明した。

次に、タグドメイン提示装置１０のタグドメイン管理部１３で、タグドメイン推薦値テーブル２８０の各タグドメイン候補２８０ｂに対するタグドメイン推薦値の算出を行い、タグドメイン推薦値テーブル２８０のタグドメイン推薦値２８０ｇのカラムに設定する（Ｓ６１１）。各タグドメイン候補２８０ｂに対するタグドメイン推薦値は、それぞれのレコードの該当する利用傾向値２８０ｄの値、ユーザ評価値２８０ｅの値、ビジネスグロッサリー一致度２８０ｆの値の合計した値となる。

次に、タグドメイン提示装置１０のタグドメイン管理部１３のタグドメイン推薦条件管理部１３８は、事前に設定されるタグドメイン推薦条件を取得する（Ｓ６１２）。

次に、タグドメイン提示装置１０のタグドメイン管理部１３のタグドメイン推薦条件管理部１３８は、タグドメイン推薦値テーブル２８０の各々のタグドメイン候補に対して算出したタグドメイン推薦値と取得したタグドメイン推薦条件に基づいて、各部門でのタグドメイン推薦値が最も大きくかつ取得タグドメイン推薦条件を満たすタグドメイン候補２５１をリストとし、推薦タグドメインとして決定する（Ｓ６１３）。

次に、図２４を用いてタグドメイン推薦画面のユーザインタフェースについて説明する。

タグドメイン推薦画面３７０は、管理者端末５０に表示される画面であり、統一的なタグ名称を付与する対象となるタグドメインの候補をデータレイク管理者に提示し、それらの統一タグ名称の入力を受け付ける画面である。

ビジネスグロッサリー定義見出し３７１、ビジネスグロッサリー値領域３７２は、ビジネスグロッサリー値領域３７２で示されている文字列の値が、ビジネスグロッサリーで定義済みであることを示している。図２４に示される例としては、「振動センサ」の名称がビジネスグロッサリーで定義済みであることを示している。この情報は、データレイク管理者に対して、例えば、この「振動センサ」の統一タグ名称として採用するなどとして、統一タグ名称をつけるためのヒントとして提示される情報である。

タグドメイン推薦条件見出し３７３、タグドメイン推薦条件値領域３７４は、タグドメインの推薦条件を示している。図２４に示される例では、タグドメイン推薦条件値領域３７４に、タグドメイン評価値：０．８以上とあり、タグドメイン推薦値テーブル２８０のタグドメイン評価値２６５が０．８以上であることが推薦に必要な条件であることを示している。したがって、この例では、特定の部門のタグドメイン２６２のタグドメイン評価値がすべて０．８未満であった場合、その部門に属するタグドメインは推薦されないことになる。

統一タグ名称入力見出し３７５、統一タグ名称入力欄３７６は、データレイク管理者の統一タグ名称入力を待機していることを表現している。統一タグ名称入力欄３７６には、初期の画面では、「－入力してください－」されており、データレイク管理者は、自分が決定した統一タグ名称を入力することができる。

タグドメイン表示欄３７７、部門表示欄３７８、付与先テーブル・カラム表示欄３７９は、それぞれタグドメインテーブル２９０のタグドメイン２９０ａ、部門２９０ｂ、付与先テーブル・カラム２９０ｃに対応する値であり、データレイク管理者に対して、部門ごとに推薦条件を満たすベストなタグドメインを表示している。

データレイク管理者は、推薦されたタグドメインについて確認し、統一タグ名称入力欄３７６に、自分が決定した統一タグ名称を入力した後、実行ボタン３８０をマウスなどのポインティングデバイスにより、クリックすることによって、タグドメイン提示装置１０のタグドメイン管理部１３は、提示したタグドメインと付与先テーブル・カラムに対して、入力された統一タグ名称を該当するタグドメインテーブル２９０の統一タグ名称２９０ｂの値として格納する。

以上述べ立てきたように、本実施形態のタグドメイン提示装置においては、タグを利用したユーザやアプリケーションソフトウェアの利用傾向を分析して、部門ごとの共通するタグドメイン（部門ごとに固有のタグによって定義されるタグの検索式）を、データレイク管理者に提示することにより、データレイク管理者に対して、部門を横断して使えるような統一的なタグ名称を作成する労力を軽減することができる。

１…ユーザ端末、４…データレイク、３…アプリケーションサーバ、７０…アプリケーションデータ、５…ネットワーク、１０…タグドメイン提示装置、
９…ネットワーク、４０…データレイク管理サーバ、５０…管理者端末、６０…データレイク蓄積データ、６１…タグストア、６２…ビジネスグロッサリー、６３…認証データストア、
２００…データ利用ログテーブル、２１０…利用観点抽出ログテーブル、２２０…固有タグテーブル、２３０…アプリケーションテーブル、２４０…アプリケーションパラメータ情報テーブル、２５０…ユーザ属性テーブル、２６０…ユーザ属性重みテーブル、２７０…利用傾向評価テーブル、２８０…タグドメイン推薦値テーブル、２９０…タグドメインテーブル

Claims (8)

1. 検索のためのタグが付与されたデータに関して、そのデータを利用する各部門に横断的なタグの検索式を提示するタグドメイン提示装置であって、
   前記タグドメイン提示装置は、
   ユーザとそのユーザの部門を対応付けたユーザ属性テーブルと、
   部門ごとに前記タグとデータとの対応情報を格納する固有タグテーブルと、
   ユーザの属する部門と、ユーザごとにアプリケーションソフトウェアに関する情報と、前記アプリケーションソフトウェアが利用した検索タグと、前記検索タグに対応するデータ情報と、前記固有タグテーブルにより示されるデータごとに対応する付与タグと、前記付与タグに関するユーザ評価情報を格納するデータ利用ログテーブルとを保持し、
   前記タグドメイン提示装置は、
   前記データ利用ログテーブルのレコードから、アプリケーションソフトウェアによるデータ利用観点でフィルタリングした利用観点抽出ログテーブルを生成し、
   前記利用観点抽出ログテーブルから、データの部門ごとのユーザとアプリケーションソフトウェアに関する利用情報と、前記ユーザ評価情報に基づいて、利用傾向評価テーブルを生成し、前記利用傾向評価テーブルの情報に基づいて、アプリケーションソフトウェアによるデータ利用観点として共通する部門ごとのタグの検索式を提示することを特徴するタグドメイン提示装置。
2. 前記利用傾向評価テーブルのカラムとして、タグの検索式ごとに、前記タグの検索式に対応するデータの相互の利用関係率を表す関連利用率を有することを特徴とする請求項１記載のタグドメイン提示装置。
3. 前記利用傾向評価テーブルのカラムとして、タグの検索式ごとに、タグの検索式に対応するデータのユーザの部門ごとの利用率を表すユーザ利用率を有することを特徴とする請求項１記載のタグドメイン提示装置。
4. 前記ユーザ属性テーブルは、ユーザと企業内における役割とが対応付けられており、
   前記タグドメイン提示装置は、
   さらに、ユーザの企業内における役割ごとの重みを格納するユーザ属性重みテーブルを保持し、
   前記利用傾向評価テーブルのカラムとして、タグの検索式ごとに、前記利用観点抽出ログテーブルのデータに対応するタグを利用したことへのユーザ評価と、前記ユーザ属性重みテーブルのユーザの企業内における役割ごとの重みとに基づいて算出されるユーザ評価の平均値を表すユーザ評価平均を有することを特徴とする請求項１記載のタグドメイン提示装置。
5. 前記利用傾向評価テーブルのカラムとして、タグの検索式ごとに、前記タグの検索式に対応するデータの相互の利用関係率を表す関連利用率と、
   前記利用傾向評価テーブルのカラムとして、タグの検索式ごとに、タグの検索式に対応するデータのユーザの部門ごとの利用率を表すユーザ利用率とを有し、
   タグの検索式ごとの関連利用率の値とユーザ利用率の値の類似度を示す利用傾向値を算出し、
   前記利用傾向値に基づいて、タグの検索式ごとの推薦値を算出し、
   前記タグの検索式ごとの推薦値に基づいて、データ利用観点として共通する部門ごとのタグの検索式を提示することを特徴する請求項１記載のタグドメイン提示装置。
6. 前記タグドメイン提示装置は、
   ビジネスグロッサリーに定義されたタグの情報を所得する手段を有し、
   前記タグの検索式を構成する文字列と、ビジネスグロッサリーに定義されたタグの文字列による一致度を算出するビジネスグロッサリー一致度を算出し、
   前記利用傾向値に基づいて、タグの検索式ごとの推薦値を算出し、
   前記タグの検索式ごとの推薦値に基づいて、アプリケーションソフトウェアによるデータ利用観点として共通する部門ごとのタグの検索式を提示することを特徴する請求項５記載のタグドメイン提示装置。
7. 検索のためのタグが付与されたデータに関して、そのデータを利用する各部門に横断的なタグの検索式を提示するタグドメイン提示装置によるタグドメイン提示方法であって、
   前記タグドメイン提示装置は、
   ユーザとそのユーザの部門を対応付けたユーザ属性テーブルと、
   部門ごとに前記タグとデータとの対応情報を格納する固有タグテーブルと、
   ユーザの属する部門と、ユーザごとにアプリケーションソフトウェアに関する情報と、前記アプリケーションソフトウェアが利用した検索タグと、前記検索タグに対応するデータ情報と、前記固有タグテーブルにより示されるデータごとに対応する付与タグと、前記付与タグに関するユーザ評価情報を格納するデータ利用ログテーブルとを保持し、
   前記タグドメイン提示装置が、前記データ利用ログテーブルのレコードから、アプリケーションソフトウェアによるデータ利用観点でフィルタリングした利用観点抽出ログテーブルを生成するステップと、
   前記タグドメイン提示装置が、前記利用観点抽出ログテーブルから、データの部門ごとのユーザとアプリケーションソフトウェアに関する利用情報と、前記ユーザ評価情報に基づいて、利用傾向評価テーブルを生成し、前記利用傾向評価テーブルの情報に基づいて、アプリケーションソフトウェアによるデータ利用観点として共通する部門ごとのタグの検索式を提示するステップとを有することを特徴するタグドメイン提示方法。
8. データとそれに対するタグが付与されたタグストアとを保持するデータレイクと、
   前記データレイクのデータを利用する各部門に横断的なタグの検索式を提示するタグドメイン提示装置と、
   管理者端末とを有する情報処理システムであって、
   前記タグドメイン提示装置は、
   ユーザとそのユーザの部門を対応付けたユーザ属性テーブルと、
   部門ごとに前記タグとデータとの対応情報を格納する固有タグテーブルと、
   ユーザの属する部門と、ユーザごとにアプリケーションソフトウェアに関する情報と、前記アプリケーションソフトウェアが利用した検索タグと、前記検索タグに対応するデータ情報と、前記固有タグテーブルにより示されるデータごとに対応する付与タグと、前記付与タグに関するユーザ評価情報を格納するデータ利用ログテーブルとを保持し、
   前記タグドメイン提示装置は、
   前記データ利用ログテーブルのレコードから、アプリケーションソフトウェアによるデータ利用観点でフィルタリングした利用観点抽出ログテーブルを生成し、
   前記利用観点抽出ログテーブルから、データの部門ごとのユーザとアプリケーションソフトウェアに関する利用情報と、前記ユーザ評価情報に基づいて、利用傾向評価テーブルを生成し、前記利用傾向評価テーブルの情報に基づいて、アプリケーションソフトウェアによるデータ利用観点として共通する部門ごとのタグの検索式を提示する情報を前記管理者端末にネットワークを介して送信し、
   前記管理者端末は、アプリケーションソフトウェアによるデータ利用観点として共通する部門ごとのタグの検索式を提示する情報と、統一タグ名称を入力するタグドメイン推薦画面を表示し、
   前記データレイクは、前記管理者端末から入力された統一タグ名称を登録することを特徴とする情報処理システム。

Images