WO2024143561A1

WO2024143561A1 - データ利活用促進システム、データ利活用促進方法、および、プログラム

Info

Publication number: WO2024143561A1
Application number: PCT/JP2023/047361
Authority: WO
Inventors: 太郎諌山; 章広川田; 翔太藤内; 貴範吉岡; 顕範山本; 和谷宮村
Original assignee: ＰｗＣビジネスアシュアランス合同会社
Priority date: 2022-12-28
Filing date: 2023-12-28
Publication date: 2024-07-04
Also published as: JPWO2024143561A1

Abstract

データ種別と用途とを少なくとも対応付けてユースケースファイルに格納し、ユースケース集ファイルに基づいて、ユーザに、用途とともに当該用途に対応するデータ種別を提示する。

Description

データ利活用促進システム、データ利活用促進方法、および、プログラム

　本発明は、データ利活用促進システム、データ利活用促進方法、および、プログラムに関する。

　デジタルトランスフォーメーション（digital transformation：DX）に対する社会的意識の高まりもあり、ＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）技術を用いて、様々な事象に関して膨大な計測データ等が収集、分析される傾向が強まっている。

　例えば、運輸、交通、電力、製造、その他の分野の業務における様々な問題を解決するために、部署や業務さらには会社や業界を跨いで横断的にデータを収集・分析し、データ利活用して、生産性の向上や新規ビジネス創出につなげようという取り組みが挙げられる。

　しかしながら、大量のデータの理解が必要であり、たとえば異業種間を跨いでデータを利活用しようとする場合、そのデータがどのような用途で利活用できるのかをユーザが想起することが困難であり、データ利活用の妨げの一因になっていた。

　また、同業者間であっても、自社がどの他社とデータ連携や協業すればよいか把握することが難しく、データ利活用やDX化の妨げの一因となっていた。

　ここで、特許文献１では、複数の業務システムからの多種多様データを用いての様々な目的でのデータ利活用を容易に行えるように、データ利活用を行うユーザ向けに、利活用の目的に対して、適切なデータ準備内容の提案を行うデータ利活用システムが記載されている。より具体的には、特許文献１のデータ利活用システムでは、(1)ユーザが指定する利活用目的とシステムにて用意するデータ情報との照合を行い、該利活用目的のために実施すべきデータ準備内容項目及び難易度を算出し提示する。

特開２０１９－１８５５８２号公報

　しかしながら、特許文献１等に記載の先行技術においては、データ利活用を行おうとするユーザは、まず、ＫＰＩ（key performance indicators）などのデータ利活用の目的や用途を指定しなければならず、特に異業種間を跨いでデータを利活用してDX新規事業等を創出しようとするときには、ユーザは、はじめから具体的な目的や用途を想起し難く、また生産性向上等の目的がはっきりしているときであっても、どのような業種のどのようなデータを用いればよいか、同業者であってもどの他社とデータ連携すればよいかを想起し難いという問題がある。

　特に、特許文献１等に記載の先行技術においては、データ利活用の実績ベースで、ＫＰＩ等の目的に対するデータ連携を収集したりデータ有用度を把握しており、データ利活用の実績が少ない場合には、新たなデータ連携の提案をすることが難しいという問題もある。

　そこで、本発明は、上述した課題等に鑑み考案されたものであって、データ利活用の知識や経験が乏しいユーザであっても、データ利活用の新たな用途やユースケース、適切なデータ連携先や協業先を把握することができる、データ利活用促進システム、データ利活用促進方法、および、プログラムを提供することを目的とする。

　上記課題を解決する本発明のデータ利活用促進システムは、記憶部と制御部を少なくとも備えたデータ利活用促進システムにおいて、前記記憶部は、データ種別と用途とを少なくとも対応付けて格納したユースケース集ファイル、および／または、複数の異なるユーザのデータを格納したデータベースを備え、前記制御部は、前記ユースケース集ファイルに基づいて、用途とともに当該用途に対応するデータ種別を抽出する、および／または、前記データベースに登録された前記複数の異なるユーザの中から、データ連携により用途に適した他のユーザを抽出する抽出部と、前記抽出した、用途とともに当該用途に対応するデータ種別、および／または、用途に適した他のユーザを、提示する提示部、を備える。

　また、本発明のデータ利活用促進方法は、データ種別と用途とを少なくとも対応付けて格納したユースケース集ファイル、および／または、複数の異なるユーザのデータを格納したデータベースを備えた記憶部と制御部を少なくとも備えたデータ利活用促進システムにおいて実行されるデータ利活用促進方法であって、前記制御部において実行される、前記ユースケース集ファイルに基づいて、用途とともに当該用途に対応するデータ種別を抽出する、および／または、前記データベースに登録された前記複数の異なるユーザの中から、データ連携により用途に適した他のユーザを抽出する抽出ステップと、前記抽出した、用途とともに当該用途に対応するデータ種別、および／または、用途に適した他のユーザを、提示する提示ステップと、を含む。

　また、本発明のプログラムは、データ種別と用途とを少なくとも対応付けて格納したユースケース集ファイル、および／または、複数の異なるユーザのデータを格納したデータベースを備えた記憶部と制御部を少なくとも備えたデータ利活用促進システムにおいて実行させるためのプログラムであって、前記制御部において、前記ユースケース集ファイルに基づいて、用途とともに当該用途に対応するデータ種別を抽出する、および／または、前記データベースに登録された前記複数の異なるユーザの中から、データ連携により用途に適した他のユーザを抽出する抽出ステップと、前記抽出した、用途とともに当該用途に対応するデータ種別、および／または、用途に適した他のユーザを、提示する提示ステップと、を実行させることを特徴とする。

　本発明によれば、データ利活用の知識や経験が乏しいユーザであっても、データ利活用の新たな用途やユースケース、適切なデータ連携先や協業先などの提案を受けることができ、データ利活用を促進することが可能となる。

図１は、本実施形態のデータ利活用基盤サーバを含むデータ利活用システムの構成例を示す図である。図２Ａは、本実施形態におけるデータ利活用促進方法を実施する場合のユースケース例を示す図である。図２Ｂは、データ利活用基盤サーバ２００により抽出されたユースケース集ファイルの一例を示す図である。図３は、本実施形態におけるデータ利活用基盤サーバのモジュール構成例を示す図である。図４は、本実施形態における分析対象データ、分析部品、分析処理、分析目的、及び業務システムの関係例に対応した分析関係情報を示す図である。図５Ａは、本実施形態における分析対象データ紐付けテーブルの例を示す図である。図５Ｂは、本実施形態における分析部品紐付けテーブルの例を示す図である。図５Ｃは、本実施形態における分析部品－分析処理紐付けテーブルの例を示す図である。図５Ｄは、本実施形態における分析処理－分析目的紐付けテーブルの例を示す図である。図５Ｅは、本実施形態における分析目的－業務紐付けテーブルの例を示す図である。図５Ｆは、本実施形態におけるデータ提供先業種－業務アプリ紐付けテーブルの例を示す図である。図５Ｇは、本実施形態におけるデータ提供先利用目的－分析目的紐付けテーブルの例を示す図である。図５Ｈは、本実施形態におけるデータ種別－データ紐付けテーブルの例を示す図である。図６Ａは、本実施形態におけるデータ分析ロジックのメタ情報例を示す図である。図６Ｂは、本実施形態におけるデータ突合ロジックのメタ情報例を示す図である。図７Ａは、本実施形態における分析対象データＤＢの構成例を示す図である。図７Ｂは、本実施形態における分析結果ＤＢの構成例を示す図である。図７Ｃは、本実施形態における実績情報ＤＢの構成例を示す図である。図８は、本実施形態におけるデータ利活用促進方法の処理シーケンス例を示す図である。図９は、本実施形態におけるデータ利活用促進方法のフロー例１を示す図である。図１０は、本実施形態におけるデータ利活用促進方法のフロー例２を示す図である。図１１は、本実施形態におけるデータ利活用促進方法のフロー例３を示す図である。図１２は、本実施形態におけるデータ利活用促進方法のフロー例４を示す図である。図１３は、データ利活用基盤サーバ２００が、ユースケース４５１に基づいて、分析関係テーブル３０７を参照して、ユーザに提案する、データ４１１と分析部品類４１２～４１５の組み合わせを取得する手法を模式的に示す図である。図１４は、本実施形態における画面イメージ例を示す図である。図１５は、本実施形態の統制システム９００の構成例を示すブロック図である。図１６は、本実施形態の統制システム９００の統制部９２０の機能を模式的に示す図である。図１７は、本実施形態の統制システム９００の処理の一例を説明するフローチャートである。

＜システム構成＞
　以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のデータ利活用促進システムの構成例を示す図である。図１に示すように、本実施形態のデータ利活用促進システムは、分散型コンピューティングシステムとして構成され、一例として、図示のごとく、ユーザ端末１００やアセット端末４００等に接続されるゲートウェイ機器と、ゲートウェイ機器とネットワークにて接続された無線基地局等に設置されるエッジコンピュータと、エッジコンピュータにネットワークにて接続されたクラウドサーバに、機能分散されて構成される。本実施形態では、このように複数台の装置に機能分散されたデータ利活用システムを、データ利活用基盤サーバ２００と称して説明するが、これに限られず、データ利活用システムは、一台のサーバ装置で構成されてもよい。また、データ利活用システムは、データ流通基盤としての性質を備えていてもよい。なお、本実施形態のデータ利活用促進システムは、ユーザ端末１００やアセット端末４００等を含んで構成されてもよい。

　データ利活用基盤サーバ２００は、データ利活用の新たな用途やユースケース、データ連携先や協業先を提案するサーバ装置となる。さらに、データ利活用基盤サーバ２００は、提案したデータ種別と用途との対応関係、ないしは、提案したデータ連携先や協業先としての他のユーザと用途との対応関係に基づいて、分析対象となるデータすなわち分析対象データに対する分析処理を構成する分析部品（ＡＳＰサーバ６００が登録したアプリケーションを含む。）の管理及び分析も行うことができ、すなわち、データ種別と用途の提案やデータ連携先や協業先の提案のみならず、そのデータ種別や他ユーザに対応するデータと、その用途に対応する分析部品やアプリケーションの具体的な組み合わせをもユーザに提案することもできる。

　また、データ利活用基盤サーバ２００は、ユーザ端末１００側のデータ利用者への提案のみならず、データ提供者となり得るアセット端末４００側に、アセットを発掘、分析、評価し、データ連携、データ提供を提案することもできる。具体例としては、データ利活用基盤サーバ２００は、データ提供候補者のリソースに関する情報（顧客情報、取引先情報、物流情報、伝票・台帳・元帳データなどの会計情報、ビジネスモデル情報、人的リソース情報、ノウハウ情報等）から、データの取得可能性や、取得可能なデータ価値を推定して、アセット端末４００に、アセット端末４００にデータ提供を提案することができる。また、データ利活用基盤サーバ２００は、アセット端末４００の学習済みモデルやオントロジー情報から、元データを推測することで、様々な有形・無形のアセットを発掘して、そのアセットから生み出されるデータ提供を提案してもよい。

　なお、本実施形態において、説明の便宜のために、データ利用者（自ユーザ）側の端末をユーザ端末１００、データ提供者（他ユーザ）側の端末をアセット端末４００として説明することがあるが、自ユーザと他ユーザの関係は等価なものであっても交換可能なものであってもよく、すなわち、例えば、他ユーザＡから見れば、ユーザ端末１００のユーザＢは他のユーザであると考えることができる。したがって、この場合、他ユーザＡは、データ利用者であり、ユーザＢは、データ提供者と考えることもできる。そのため、本実施の形態において、ユーザ端末１００の機能として説明したものを、端末４００の機能として読み替えることもでき、同様に、アセット端末４００の機能として説明したものを、端末１００の機能として読み替えることもできる。そのため、同じユーザが、データ利用者であり、かつ、データ提供者であるともいえ、そのユーザの端末が、ユーザ端末１００の機能の一部または全部も、アセット端末４００の機能の一部または全部も同時に持っているとみなすこともでき、その端末の機能構成は任意である。

　図１に示すように、データ利活用基盤サーバ２００は、ネットワークを介して、ユーザ端末１００やアセット端末４００と、また、いわゆるＳａａＳ（Software as a Service）として様々なソフトウェアをサービスとして提供するＡＳＰ（Application Service Provider）システム６００と、それぞれデータ通信可能に接続されている。なお、図１では、ユーザ端末１００やアセット端末４００やＡＳＰシステム６００は、各一台を図示しているが、それぞれ複数台あってもよいものである。また、ユーザ端末１００、アセット端末４００、およびＡＳＰシステム６００のうち少なくとも一つを含めて、データ利活用促進システムとして構成してもよい。また、ＡＳＰシステム６００は、クラウドサーバの一部であってもよく、または、ゲートウェイに接続されてもよい。

　上述のネットワーク構成におけるユーザ端末１００は、本実施形態において、データ利活用（候補）者側の端末であり、データ利活用基盤サーバ２００が提示したデータ種別と用途の組み合わせの提案、ないしは用途と他ユーザの提案を受け、更には、データ種別と用途の組み合わせ、ないしは他ユーザと用途の組み合わせに各対応する、データと分析部品（例：アプリケーション）の組み合わせの提案の確認、選択、及び分析実行と結果確認等の操作を行うための端末となる。

　アセット端末１００は、本実施形態において、データ提供（候補）者側の端末であり、データ利活用基盤サーバ２００からのアセットマイニング等によるデータ提供の提案を受け得ることができ、データ提供の際には、そのデータ（元データに限らず、疑似化等を行った派生データ等の場合もある。）を、直接、または、ＡＳＰシステム６００やデータ利活用基盤サーバ２００を介して間接的に、ユーザ端末１００のユーザに提供する。なお、アセット端末１００は、元データから機微情報を削除するなどクレンジングしたデータを提供したり、元データの共起性など統計情報に基づいてオントロジー化や疑似化等した疑似データ等の派生データとして提供してもよく、学習済みモデルやナレッジグラフやオントロジー情報としてデータ提供してもよいものである。また、アセット端末１００は、学習済みモデルやオントロジー情報を送信（アップロード）することなく、データ利活用基盤サーバ２００等から受信したデータを、アセット端末１００にインストールしたアプリケーション・ソフトウェア等を用いて学習済みモデル等で学習処理した処理結果や統計情報等を、データ利活用基盤サーバ２００等に返すことでデータ提供としてもよい。

　また、ＡＳＰシステム６００は、アセット端末４００からの各種データ（例：運輸・物流の走行データや、運行の伝票データ、機器の温度・振動といった観測データ、メンテナンス履歴等）の提供を受けて処理を行うシステムである。このＡＳＰシステム６００は、本実施形態において、ユーザ端末１００のユーザが、アセット端末４００から提供されたデータの分析によって問題解決を行う対象となり、すなわち既存ビジネスの生産性向上や、新規ビジネス開発や、協業先開拓のためのツール等となる。なお、図１に図示しないが、後述する特許文献情報サーバ８００は、ネットワークに接続された特許文献データベース（これに限られず、Ｗｅｂスクレイピング結果などWebデータを記憶するデータベースであってもよい。）を備えた装置であり、データ利活用基盤サーバ２００に特許文献情報やWebスクレイプ結果等に基づくユースケース集を提供する機能を有する。また、図１に図示しないが、後述する統制システム９００は、ネットワークに接続されるか、ないしはデータ利活用基盤サーバ２００の中の機能モジュールであり、データ利活用基盤サーバ２００に登録ないし流通するデータの評価を行い、データの信頼性（真正性や有用性等）を担保する機能を有する。

＜ハードウェア構成＞
　上述のデータ利活用基盤サーバ２００のハードウェア構成の一例を説明する。すなわち、データ利活用基盤サーバ２００は、一例として、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）やハードディスクドライブ等の適宜な不揮発性記憶素子や、メモリ等の揮発性記憶素子を含む記憶部２０６、記憶部２０６に保持されるプログラム等を実行し装置自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等の制御部２０２、ネットワークと接続し他装置との通信処理を担う通信部２０４、キーボードなどの入力手段やディスプレイなどの出力手段である入出力部２０８を備える。なお、上述のように、データ利活用基盤サーバ２００は、本実施形態において、分散型コンピューティング装置として構成されているので、クラウドサーバ、エッジコンピュータ、および、ゲートウェイは、これら記憶部２０６や制御部２０２や入出力部２０８のうちの少なくとも一つを備えていなくてもよく、後述する記憶部２０６や制御部２０２や入出力部２０８のうちの一機能を備えていなくてもよい。

　こうしたハードウェア構成は、ユーザ端末１００、アセット端末４００、および図示しないＡＳＰサーバ６００の各部においても同様である。例えば、ユーザ端末１００は、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）やハードディスクドライブ等の適宜な不揮発性記憶素子や、メモリ等の揮発性記憶素子を含む記憶部１０６、記憶部１０６に保持されるプログラム等を実行し装置自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等の制御部１０２、ネットワークと接続しデータ利活用基盤サーバ２００等との通信処理を担う通信部１０４、キーボードなどの入力手段やディスプレイなどの出力手段である入出力部１０８を備える。

　同様に、アセット端末４００は、ＳＳＤやハードディスクドライブ等の適宜な不揮発性記憶素子や、メモリ等の揮発性記憶素子を含む記憶部４０６、記憶部４０６に保持されるプログラム等を実行し装置自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等の制御部４０２、ネットワークと接続しデータ利活用基盤サーバ２００等との通信処理を担う通信部４０４、キーボードなどの入力手段やディスプレイなどの出力手段である入出力部４０８を備える。図示しないが同様に、ＡＳＰサーバ６００は、ＳＳＤやハードディスクドライブ等の適宜な不揮発性記憶素子や、メモリ等の揮発性記憶素子を含む記憶部、記憶部に保持されるプログラム等を実行し装置自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等の制御部、ネットワークと接続しデータ利活用基盤サーバ２００等との通信処理を担う通信部、キーボードなどの入力手段やディスプレイなどの出力手段である入出力部等を備えてもよい。

＜処理シーケンス＞
　図２Ａは、本実施形態におけるデータ利活用促進方法の処理の一例を示すシーケンス図である。図２Ａで示す処理シーケンスにおける主な構成要素は、特許文献情報サーバ８００から特許文献情報を収集・蓄積し、そこからデータ種別と用途の組み合わせを抽出・格納したユースケース集に基づいてユーザ端末１００のユーザにデータ種別と用途の組み合わせを提案するデータ利活用基盤サーバ２００と、データ利活用基盤サーバ２００からデータ種別（ないしは他ユーザ）と用途の提案、更には、対応するデータとアプリケーションの提案を受けるユーザ端末１００と、アセットのマイニング等によるデータ提供の提案等に基づいて、提供するデータ（派生データ等であってもよい。）を登録するアセット端末４００と、データ利活用プラットフォーム上のＳａａＳとして、分析処理などのアプリケーションを提供するＡＳＰサーバ６００である。なお、上述したように、自ユーザのユーザ端末１００が、自ユーザのデータと他ユーザのデータを連携等して適切な連携先や協業先を把握するために、ユーザ端末１００は、同時に、データ利活用基盤サーバ２００にデータ登録やデータ提供を行うアセット端末４００の機能を有しており、アセット端末４００として、以下のステップSA４のデータ登録などを行ってもよい。

　図２Ａに示すように、まず、特許文献情報サーバ８００は、データ利活用基盤サーバ２００に、特許文献情報を送信する（ステップSA１）。例えば、特許文献情報サーバ８００は、特許庁が提供する特許情報ＡＰＩ（Application Programming Interface）を提供するサーバ、platpatサーバ、espacenetサーバなどの公的機関のサーバやデータベースのほか、民間の特許情報データベースやサーバであってもよい。これに限られず、特許文献情報サーバ８００は、公開Ｗｅｂ情報から、後述するＢｔｏＢのＤＸ事例等を収集・スクレイピングした、Ｗｅｂデータを記憶して、データ利活用基盤サーバ２００にＢｔｏＢユースケース集などを提供してもよい。なお、特許文献情報には、願書情報（特許分類、出願人、発明者などの記述）や、明細書情報（発明が解決しようとする課題、作用効果、発明の詳細な説明、産業上の利用可能性などの記述）、特許請求の範囲、図面（フローチャート、データフロー図、ブロック構成図など）の記載が含まれ得る。

　つづいて、データ利活用基盤サーバ２００は、受信した特許文献情報またはＷｅｂデータを特許文献ファイルとして記憶部２０６に格納し、少なくともデータ種別（ないしは業種）と用途に関する記述を抽出し、ユースケース集ファイルとして記憶部２０６に格納する。例えば、データ利活用基盤サーバ２００は、以下に示すIoT特許分類を用いて、データ種別（ないしは業種）と用途の組み合わせを抽出してもよい。例えば、データ利活用基盤サーバ２００は、G16Y 10/25が付与された特許文献は、そのIoTデータを製造業の用途で用いることができると判定し、G16Y 10/40が付与された特許文献では、そのIoTデータを運輸，交通の用途に用いることができると判定し、G16Y 10/50が付与された特許文献では、そのＩｏＴデータを金融，保険の用途に用いることができると判定し、G16Y 40/60が付与された特許文献は、位置決め，ナビゲーションの用途に用いることができると判定して、ＩｏＴデータ種別（特許分類のみならず、例えば、特許文献の明細書等に記載のＩｏＴ機器名や単位等の記載から抽出してもよい。）と、その用途（特許分類のみならず、例えば、産業上の利用可能性の欄や課題・作用効果、発明の詳細な説明、図面の記載から抽出してもよい。）の組み合わせを抽出してもよい。さらには、データ利活用基盤サーバ２００は、収集されたユースケース集ファイルを学習してシソーラス辞書を作成し、特許文献情報に対して学習結果（この場合、シソーラス辞書）の同義語や類義語を探索することにより、データ種別（ないしは業種）と用途とを自動抽出してもよい。

　ここで、図２Ｂは、データ利活用基盤サーバ２００により抽出されたユースケース集ファイルの一例を示す図である。図２Ｂに示すように、この例では、データ種別（データ提供者（データ提供元）の業種を示す“B”の項目、データの種類を示す“data”の項目）、および、用途（データ利用者（データ提供先）の業種を示す“to B”の項目、データの利用目的を示す“objective”の項目）のほか、URLリンク先には図面等が参照可能に抽出元の特許文献番号がリストアップされており、参照テーブルとしてデータベース化されている。

　そして、データ利活用基盤サーバ２００は、ユースケース集ファイルに基づいて、ユーザ端末１００のユーザに、用途とともに当該用途に対応するデータ種別（データ提供者の業種“Ｂ”等）を提示する（ステップＳＡ３）。ここで、データ利活用基盤サーバ２００は、図２Ｂに示したような、ユースケース集をユーザ端末１００の入出力部１０８に一覧表示させてもよく、入出力部１０８を介して検索枠に任意の単語を入力させて任意の項目が絞り込み検索可能なように提示してもよい。例えば、ユーザが、 “to B”の欄を指定して、自身の業種に関連する「電力」と入力すると、ユースケース集の一覧から“toB”の欄が「電力」のもののみ絞り込みして表示されるようにデータ利活用基盤サーバ２００が制御してもよい。同様に、ユーザが、用途の“objective”の欄を指定して、データ連携等により改善したい項目として、例えば「労働時間売上」と入力すると、ユースケース集の一覧から“objective”の欄に「労働時間」や「売上」など生産性向上等に関するもののみ絞り込みして表示されるようにデータ利活用基盤サーバ２００が制御してもよい。なお、図２Ｂに図示したユースケースは、“Ｂ”と“to B”の業種が異なる異業種間の連携によるＤＸ事例が多いが、これに限られず、“Ｂ”と“to B”の業種が同じである同業種間の連携による生産性の向上等に資するユースケースであってもよい。

　なお、データ利活用基盤サーバ２００は、ユースケース集ファイルの項目に、更に、データの真正性や有用度等の信頼性など、データ価値に関する項目を含んでもよく（後述する統制システム９００によるデータ評価のアノテーションなど）、データ種別や用途とともに、データ価値を提示することで、ユーザ端末のユーザは、選択の指標とすることができる。一例として、データ利活用基盤サーバ２００は、データ種別と用途の同じ組み合わせが、多くの特許文献やＷｅｂデータにおいて記述されているほど、および／または、同じデータ種別に対して、複数の特許文献やＷｅｂデータにわたって多くの用途があるほど、当該データ種別の価値（特に有用性）が高いとの評価付けを行ってもよい。なお、本実施の形態では、データ価値とは、データの真正性や有用性（有用度）などの、データの信頼性を包含する概念として説明することがあるが、これに限られない。これらの真正性や有用性などの信頼性を含むデータ価値の評価値は、データ種別（業種等を含む。）またはデータそのものに対して、メタデータとして付加されていてもよい。また、データの信頼性とは、以下の概念の一部または全部を含んでもよい。より具体的には、後述する統制システム９００の説明において詳述する。
・データの信憑性：すなわち、そのデータの信憑性があるか
・データの所有性：元の所有者は誰か、加えて誰が支払いを受ける可能性があるか
・データの品質：センサーの読み取り値は正しいか
・データの整合性：最初のキャプチャ以降、センサーの読み取り値が改ざんされていないか

　以上が、本実施形態の基本的なシーケンスである。ここで、データ利活用基盤サーバ２００は、データ種別と用途の組み合わせをユーザに提示するのみならず、実際に用いることができるデータとアプリケーションの組み合わせを提示してもよい。なお、以下のステップＳＡ４～ＳＡ６の処理は、データ・アプリケーションの提案（ステップＳＡ６）よりも以前に、予め実行されて処理結果が予め保存されていてもよい。

　まず、アセット端末４００は、提供可能なデータ（派生データであってもよい。）をデータ利活用基盤サーバ２００に登録する（ステップＳＡ４）。なお、この処理の前に、データ利活用基盤サーバ２００が、アセット端末４００に対してマイニング処理を実行させてもよい。より具体的には、データ利活用基盤サーバ２００は、通信部２０４を介して取得される情報から、データの取得可能性、および／または、取得可能なデータ価値を推定して、アセット端末４００の入出力部４０８に提示し、アセット端末４００の利用者（データ提供候補者）が、そのデータ価値（データ販売価格に連動してもよい。）等に鑑みて、そのデータの提供を承諾することによって、上述のステップＳＡ４の登録処理が実行されてもよい。

　つづいて、ＡＳＰサーバ６００は、データ利活用基盤でＳａａＳなどの形態で提供するソフトウェア／アプリケーション・プログラムである分析部品をデータ利活用基盤サーバ２００に登録する（ステップＳＡ５）。なお、ステップＳＡ１やＳＡ４やＳＡ５等の処理は、いずれが前後してもよい。

　つづいて、データ利活用基盤サーバ２００は、ユースケース集ファイルに記憶された、データ種別と用途との対応関係に基づいて、分析対象となるデータと当該データに対する分析処理を実行する分析部品（アプリケーションの機能の全部または一部）との紐付けを規定する分析関係情報を生成する（ステップＳＡ６）。より具体的には、データ利活用基盤サーバ２００は、データ種別と用途との組み合わせに対応するように、ステップＳＡ４で登録されたデータのうち当該データ種別に適合するデータ（例：当該データ種別の業種“B”に適合するユーザであって、当該データ種別の種類“data”に適合するデータ）と、ステップＳＡ５で登録された分析部品のうち当該用途に適合する分析部品の組み合わせを特定する等により、分析関係情報を生成する（以下の式は、その対応関係を模式的に示したものである）。したがって、データ種別と用途の組み合わせであるユースケースとは、抽象的で外観的なデータシーケンス概念として捉えられ、一方、データと分析部品の組み合わせである分析関係情報とは、具体的で内部的な処理内容として捉えることができる。
［式１］
＜ユースケース＞＝＜データ種別＞×＜用途＞
　　↓↑　　　　　　↓↑　　　　　↓↑
＜分析関係情報＞＝＜データ＞×＜分析部品＞

　そして、ユーザ端末１００のユーザが、入出力部１０８を介してユースケース集からデータ種別と用途との組み合わせを選択すると（ステップＳＡ７）、データ利活用サーバ２００は、対応する分析関係情報からデータと分析部品（アプリ）の組み合わせをユーザに提案する（ステップＳＡ８）。そして、ユーザ端末１００のユーザが、入出力部１０８を介してデータと分析部品（アプリ）との組み合わせを選択すると（ステップＳＡ９）、データ利活用サーバ２００は、当該データと分析部品（アプリ）を用いた分析処理を実行して、分析結果をユーザ端末１００に送信する（ステップＳＡ１０）。なお、ステップＳＡ７～ＳＡ１０は、２往復の処理となっているが１往復の処理であってもよい。すなわち、データ種別と用途の組み合わせのユースケースを提示する際に（ステップＳＡ３）、当該組み合わせに対応するデータと分析部品（アプリ）の組み合わせも併せて提示することによって、ユーザが、一回で、データ種別に対応するデータと用途に対応する分析部品（アプリ）の組み合わせを選択（採用）できるように構成してもよい。

　また、データと分析部品（アプリ）の組み合わせを提案する際に、そのデータを分析部品（アプリ）で実行した場合の分析結果（ＫＰＩ等）を併せて提示してもよい。これにより、例えば、自ユーザが、どの他ユーザと提携すれば、生産性などの指標値がどの程度改善するか業務改善効果を把握することができる。なお、自ユーザと他ユーザは、前述のように、疑似データ等の派生データをまずは登録することにより、秘密保持契約（ＮＤＡ）等の業務提携契約などを結ぶ前に、相手側を知らずして、連携による効果を把握することができ、異業種間や同業種間で適切な連携先や協業先を発見することができ、データ提携や協業、ＤＸが促進されることとなる。

＜モジュール構成＞
　図３は、本実施形態におけるデータ利活用基盤サーバ２００のモジュール構成を示す図である。

　本実施形態のデータ利活用基盤サーバ２００においては、分析対象のデータを蓄積ないしアセット端末４００等からリアルタイムに受信して、この分析対象データに対する分析処理を構成する分析部品の管理及び分析を行い、ユーザへの当該分析部品の提案等の処理を実行するための、データ利活用ミドルウェア３００が導入される。

　このデータ利活用ミドルウェア３００の主な構成要素は、特許文献情報サーバ８００から受信された特許文献情報やＷｅｂデータ等を格納する特許文献情報ファイル３０１、少なくともデータ種別と用途を対応付けて記憶するユースケース集ファイル３０２、特許文献情報の中から少なくともデータ種別と用途を抽出してユースケース集ファイル３０２に格納するユースケース抽出部３１６、有用性などのデータ価値の評価付けを行う有用性判定部３１７、データの取得可能性、および／または、取得可能なデータ価値を推定するアセット推定部３１８、データ利活用基盤のデータパイプラインに埋め込まれ、通信部２０４を介した評価を受け入れる評価モジュール部３１９、分析部品３０３の組合せによる分析処理３０２の実行管理を行う分析実行管理部３０３、複数のアセット端末４００から登録された分析対象のデータを格納する分析対象データＤＢ３０４、分析処理の実行結果を格納する分析結果ＤＢ３０５、分析実行管理部３０３にて実行された分析処理に関する実績情報を格納する実績情報ＤＢ３０６、分析関係情報を格納する分析関係テーブル３０７、分析関係テーブル３０７を管理する分析関係情報管理部３０８、ユースケース集ファイル３０２を参照してユーザにデータ種別と用途の組み合わせを提案、さらには、分析関係テーブル３０７を参照してユーザにデータ組み合わせおよび／または分析部品組み合わせを提案する提示部３０９、データ利活用ミドルウェア３００にアクセスして分析を行うユーザ及び業務を管理するユーザ・業務管理部３１０、ユーザ端末１００に対してデータ利活用ミドルウェア３００が提供する機能のインタフェースを提供するクライアント向けＩ／Ｆ提供部３１１、実績情報ＤＢ３０６を管理する分析処理実績管理部３１２、分析実行管理部３０３にて実行する分析部品３０３を管理する分析部品管理部３１３、分析対象データＤＢ３０４に格納されるデータを管理するデータ管理部３１４、ネットワークを介してユーザ端末１００やアセット端末４００やＡＳＰシステム６００や特許文献情報サーバ８００等との間で通信を行うデータ通信部３１５となる。

　特に、評価モジュール部３１９は、データ利活用基盤のデータパイプラインに埋め込まれ、通信部２０４を介した評価を受け入れる評価モジュールである。より具体的には、アセット端末４００から、データがアップロードされる際に、評価モジュール部３１９は、そのデータパイプライン経路上のゲートウェイやエッジコンピュータに埋め込まれており、そのデータの評価値をスコアリングして、メタデータとして当該データに付加する機能を有する。例えば、評価モジュール部３１９は、データの信頼性に関する評価値として、以下の（Ａ）～（Ｉ）の項目のうち少なくとも一つについて、それぞれスコアリングして、信頼性評価値としてメタデータに埋め込んでもよい。
（Ａ）分散台帳によるデータ検証されるか
（Ｂ）セキュアな格納先か
（Ｃ）ゲートウェイ認証があるか
（Ｄ）どこから発生したかの来歴メタデータがあるか
（Ｅ）デバイス署名による所有者情報が含まれるか
（Ｆ）データ分布を３シグマ・ルールでノイズ除去しているか
（Ｇ）ナイキスト基準による最適なポーリング頻度を上回っているか
（Ｈ）真正性指紋(authenticity fingerprint)が一致しているか、
（Ｉ）ビザンチン・フォールトトレラント性があるか

　そして、評価モジュール部３１９は、通信部２０４を介した評価（審査または監査と言い換えてもよい。）を受け入れる。具体的には、評価モジュール部３１９は、上述のようなデータの価値評価の手法が、データ流通の基準・ガイドライン・個人情報保護法等の法令などの適応しているか否か、通信部２０４を介した評価を受け入れる。例えば、監査法人等が、評価モジュール部３１９の内部処理方法を検証できるよう、評価値スコアリングプログラムを提示できるように評価モジュール部３１９を構成してもよい。また、アセット端末４００がアップロードしたデータ（機微情報が含まれていないデータやオントロジー化データ等）とアップロードする前の元データ（機微情報が含まれているデータやオントロジー化前のデータ等）とを比較可能に提示することができるように評価モジュール部３１９を構成してもよい。このほか、評価モジュール部３１９は、以下のような項目を自動チェックする機能を有しており、通信部２０４を介した評価（証券取引法や国際会計ガイドラインに沿っているかの審査または監査と言い換えてもよい。）を受け入れてもよい。
（１）決済の際に、データ提供元からデータ提供先で（ＢｔｏＢで）パイプラインがつながっているかをデューデリジェンスする
（２）複数の企業間取引で正しく相殺が実行されているか
（３）売り上げの水増し（架空取引）のチェック（グループ会社が別会社を介してデータを流している等）
（４）不正情報取引（インサイダー情報）の監視

　ここで、具体的には、評価モジュール部３１９は、後述する、統制システム９００に接続されることにより、統制システム９００にデータ等の情報を与え、統制システム９００からデータ評価結果等を受信することにより、評価を受け入れてもよい。なお、評価モジュール部３１９自体が、統制システム９００であってもよい。

　また、アセット推定部３１８は、通信部２０８を介してアセット端末４００から取得される情報（入出力部４０８の入力データや、記憶部４０６のデータ、制御部４０２の学習済みモデル等）から、データの取得可能性、および／または、取得可能なデータ価値を推定することによって、アセットマイニングを行う。より具体的には、アセット推定部３１８は、（１）データの源となるリソース、（２）デジタル化やデータ化するハードウェアやソフトウェア、および、（３）元データ（生データ）が何らかの加工を受けたもの（加工データなどのオントロジー化データ等）や、データが変化させたもの（学習済みモデル等）から遡及的に元データ（の種別やデータ価値）の推定のうち、少なくとも一つを用いて、データの取得可能性、および／または、取得可能なデータ価値を推定する。なお、データ価値の推定には、有用性判定部３１７や評価モジュール部３１９や統制システム９００等により推定される真正性や有用性、信頼性などのデータ価値を用いてもよい。

　（１）の例としては、アセット推定部３１８は、通信部２０８を介して取得された顧客情報（例：業種の情報）、取引先情報（例：業種の情報）、物流情報、伝票情報、会計情報、ビジネスモデル情報、人的リソース情報、および、ノウハウ情報のうち少なくとも一つに基づいて、当該顧客、当該取引先、当該物流、当該会計、当該ビジネスモデル、当該人的リソース、および、当該ノウハウのうち少なくとも一つから取得できる、データの取得可能性、および／または、取得可能なデータ価値を推定してもよい。

　（２）の例としては、アセット推定部３１８は、通信部２０８を介して取得された顧客情報、取引先情報、物流情報、会計情報、ビジネスモデル情報、人的リソース情報、および、ノウハウ情報のうち少なくとも一つに基づいて、購入、貸与または利用可能化される機器またはソフトウェアを推定して、当該機器または当該ソフトウェアに基づいて、データの取得可能性、および／または、取得可能なデータ価値を推定してもよい。

　（３）の例としては、アセット推定部３１８は、通信部２０８を介して取得された学習済みモデル情報またはオントロジー情報に基づいて、学習された元データまたはオントロジー化された元データを予測して、データの取得可能性、および／または、取得可能なデータ価値を推定してもよい。なお、アセット端末４００から直接、学習済みモデルを受信することに限られず、アセット推定部３１８は、アセット端末４００の学習済みモデルに何らかの入力値（ダミーデータ等）を与えた結果の出力値（学習済みモデル情報の一例）を受信することによって、元データの種別や価値を推定してもよい。

＜ユースケースと分析関係情報の対応関係＞
　図４は、本実施形態における、用途（例：データ提供先の業種“to B”および利用目的“objective”の項目）およびデータ種別（例：データ提供元ユーザの業種“B”や、何のデータかといったデータの種類）に対応したユースケース４５１と、分析対象となるデータ、分析部品、分析処理、分析目的、および、業務システムの関係例に対応した分析関係情報４０１を示す図である。なお、図４の実施形態では、分析部品を、狭義の意味で、データ分析ロジックと突合せロジックであると説明することがあるが、本発明（特許請求の範囲）の分析部品は、これに限られず、ソフトウェア、アプリケーション、分析処理、KPIなどの分析目的（例：生産性などの指標値や評価値をアウトプットする数式や参照テーブル）等を含む概念である。

　上述したように、本実施形態のユースケース４５１は、データ種別４５１と用途４５０の組み合わせであり、より具体的には、データ種別４５１には、データ提供元の業種を示す“B”の項目、データの種類を示す“data”の項目があり、用途４５０には、データ提供先（データ利用者）の業種を示す“to B”の項目、データ提供先の利用目的を示す“objective”の項目がある。

　一方、本実施形態の分析関係情報４０１とは、分析に用いるデータおよび分析部品、それらの組合せによる分析処理、分析目的、該分析目的に対する業務アプリケーションにおける業務及び業務の実施先となる設備等の対象、との関係を表現するものである。なお、「関係」とは、関係付けられるもの同士を組合せて利用可能である、ユースケースの用途およびデータ種別の組み合わせとの対応関係がある、もしくは利用の実績が有る、ということを意味する。分析関係情報４０１は、データ利活用基盤サーバ２００が、ユーザ指定（用途とデータ種別のユースケース提案に対する採用を含む。）の分析対象のデータに対して適切な分析部品を選出し提案するために参照する。

　主な構成要素は、分析対象データ４１１、分析部品４１２、分析処理４１３、分析目的４１４、業務アプリ４１５の各情報であり、それぞれの情報ごとに階層に区切って管理される。このうち分析部品４１２は、データ突合ロジック４２１とデータ分析ロジック４２２とに分類される。ここで分析対象データに対する分析の実施に必要となる、データ突合ロジック及びデータ分析ロジックは、分析部品を構成するソフトウェア部品として再利用可能であるものとし、これらの部品の組合せにより分析処理を構成するものとする。

　まず、分析対象のデータ４１１の階層では、分析対象となる複数のＡＳＰシステム６００からのデータ及び該データ間の関係が管理される。なお、データ関係は、例えば、特開２０１６－２０９０６３号公報による方法により作成されるものである。

　また、分析部品４１２の階層では、１つ以上の分析対象データの組合せをデータベース等の蓄積媒体から抽出するための処理ロジック（例えばＳＱＬ文、等）であるデータ突合ロジック４２１、及び、上述の１つ以上の分析対象データに対して実施する分析のロジック（例えば系列データのグラフ化、相関分析、等）であるデータ分析ロジック４２２が管理される。

　また、分析処理４１３の階層では、上述の１つ以上の分析対象データ及び１つ以上の分析部品の組合せにより作成するデータ分析処理を管理する。

　また、分析目的４１４の階層では、分析を行う目的であるＫＰＩ情報が管理される。また、業務アプリ４１５の階層では、上述の分析目的であるＫＰＩを必要とする業務システムにおける業務４１５１及び設備等の対象４１５２が管理される。なお、各々の階層間では各階層の要素で関係のあるもの同士の紐付け（リンク付け）を行っている。

　分析関係情報管理部３０８は、ユースケース集ファイル３０２に記憶された、データ種別４５１と用途４５０との対応関係に基づいて、分析対象となるデータ４１１と当該データに対する分析処理を実行するアプリケーション（狭義には、業務アプリ４１５および／または分析目的４１４であり、広義には、分析処理４１３、分析部品４１２を含む。）との紐付けを規定する分析関係情報を生成する。

　より具体的には、分析関係情報管理部３０８は、データ種別４５１のデータ提供元の業種を示す“Ｂ”の項目、および、データの種類を示す“data”の項目に対応する、データ４１１を検索・抽出して、対応関係を分析関係情報に格納する。例えば、データ４１１は、データ提供元の情報（企業識別情報や業種などデータ提供元のユーザを表す情報）を示すメタデータや、IoT機器の製品番号や単位を示すメタデータが含まれ得るので、分析関係情報管理部３０８は、メタデータから業種を示す“Ｂ”やデータの種類を示す“data”の項目を検索・抽出してもよい。なお、分析関係情報管理部３０８は、本実施形態において抽出部としての機能を有する。

　また、分析関係情報管理部３０８は、用途４５０のうち、データ提供先の業種を示す“toＢ”の項目４５５、および、データ提供先のデータ利用目的を示す“objective”の項目４５４に対応する、分析部品４１２～業務アプリ４１５を検索して、対応関係を分析関係情報に格納する。例えば、分析関係情報管理部３０８は、データ提供先の業種を示す“toＢ”の項目４５５に対応する、業務アプリ４１５を、ＡＳＰサーバ６００の登録アプリから検索・抽出して、対応関係を分析関係情報に格納してもよい。また、分析関係情報管理部３０８は、データ提供先の利用目的を示す“objective”の項目４５４に対応する、分析目的４１４や業務アプリ４１５を、ＡＳＰサーバ６００の登録アプリ（登録分析部品）から検索・抽出して、対応関係を分析関係情報に格納してもよい。

　なお、分析関係情報は、業務アプリ４１５や分析目的４１４からデータ４１１までの図４の縦方向の対応関係も規定しているので、図４の横方向の対応関係、すなわち、toB４５５に対応する業務アプリ４１５や、objective４５４に対応する分析目的４１４と、データ種別４５１に対応するデータ４１１が決まれば、その間を埋める分析処理４１３や分析部品４１２は、縦方向の対応関係に関する分析関係情報に基づいて、分析関係情報管理部３０８は、決定してもよい。

＜テーブル＞
　図５Ａ～図６Ｂは、本実施形態のデータ利活用基盤サーバ２００にて管理する、分析関係情報４０１における要素間の紐付け情報（すなわち、縦方向の対応関係と縦方向の対応関係）を格納する分析関係テーブル３０７の構成、及び分析部品のメタ情報のデータ構造を示す図である。

　本実施形態において、分析関係情報４０１における要素間の紐付け情報を管理する分析関係テーブル３０７は、分析対象データ紐付けテーブル５０１、分析部品紐付けテーブル５０２、分析部品－分析処理紐付けテーブル５０３、分析処理－分析目的紐付けテーブル５０４、及び、分析目的－業務紐付けテーブル５０５、ならびに、データ提供先業種－業務アプリ紐付けテーブル５０８、データ提供先利用目的－分析目的紐付けテーブル５０９、および、データ種別－データ紐付けテーブル５００を、含んで構成されている。

　このうち図５Ａに例示する分析対象データ紐付けテーブル５０１は、分析関係情報４０１の分析対象データ４１１と分析部品４１２におけるデータ突合ロジック４２１との間の紐付けに関する情報を格納するテーブルである。主な構成要素は、各紐付けを一意に特定する紐付け識別情報５１１、分析対象データ識別情報５１２、データ突合ロジック識別情報５１３、重み５１４、及び、更新日時５１５である。

　上述の紐付け識別情報５１１には、該当紐付けを識別するための情報が格納される。また、分析対象データ識別情報５１２には、紐付けられる一方である分析対象データを識別するための情報が格納される。また、データ突合ロジック識別情報５１３には、紐付けられる他方であるデータ突合ロジックを識別するための情報が格納される。また、重み５１４には、当該紐付けの重みを示す情報が格納される。例えば該紐付けによる組合せが分析者等のユーザに多く使用される程、当該重みを表す数値は大きくなる。また、更新日時５１５には、上述の各項目５１１～５１４のレコードが最後に更新された日時が格納される。なお１つの分析対象データに対して、複数の紐付けがありえるため、分析対象データ紐付けテーブル５０１にて、当該分析対象データに関して複数のレコードが格納され得る。

　また、図５Ｂに例示する分析部品紐付けテーブル５０２は、分析関係情報４０１の分析部品４１２におけるデータ突合ロジック４２１とデータ分析ロジック４２２との間の紐付けに関する情報を格納するテーブルである。その主な構成要素は、紐付け識別情報５２１、データ突合ロジック識別情報５２２、データ分析ロジック識別情報５２３、重み５２４、及び、更新日時５２５である。

　このうち紐付け識別情報５２１には、当該紐付けを一意に識別するための情報が格納される。また、データ突合ロジック識別情報５２２には、紐付けられる一方であるデータ突合ロジックを識別するための情報が格納される。また、データ分析ロジック識別情報５２３には、紐付けられる他方であるデータ分析ロジックを識別するための情報が格納される。また、重み５２４には、当該紐付けの重みを示す情報が格納される。例えば該紐付けによる組合せが分析者等のユーザに多く使用される程、重みを表す数値は大きくなる。また、更新日時５２５には、上述のデータ項目５２１～５２４のレコードが最後に更新された日時が格納される。なお１つのデータ突合ロジック及びデータ分析ロジックに対して、複数の紐付けがありえるため、分析部品紐付けテーブル５０２にて、当該１つのデータ突合ロジック及びデータ分析ロジックに関して複数のレコードが格納され得る。

　また、図５Ｃに例示する分析部品－分析処理紐付けテーブル５０３は、分析関係情報４０１の分析部品４１２におけるデータ分析ロジック４２２と、分析者等のユーザにより実行された分析処理４１３との間の紐付けに関する情報を格納するテーブルである。その主な構成要素は、紐付け識別情報５３１、データ分析ロジック識別情報５３２、分析処理識別情報５３３、重み５３４、及び、更新日時５３５である。

　このうち紐付け識別情報５３１には、当該紐付けを一意に識別するための情報が格納さ
れる。また、データ分析ロジック識別情報５３２には、紐付けられる一方であるデータ分析ロジック４２２を識別するための情報が格納される。また、分析処理識別情報５３３には、紐付けられる他方である分析処理４１３を識別するための情報が格納される。また、重み５３４には、当該紐付けの重みを示す情報が格納される。例えば該紐付けによる組合せが分析者等のユーザにより多く使用される程、重みを表す数値は大きくなる。また、更新日時５３５には、上述の各データ項目５３１～５３４のレコードが最後に更新された日時が格納される。なお１つデータ分析ロジック４２２に対して、複数の紐付けがありうるため、分析部品－分析処理紐付けテーブル５０３にて、当該１つのデータ分析ロジック４
２２に関して複数のレコードが格納され得る。

　また、図５Ｄに例示する分析処理－分析目的紐付けテーブル５０４は、分析処理３０２における実施された分析処理と分析目的４１４におけるＫＰＩとの間の紐付けに関する情報を格納するテーブルである。その主な構成要素は、紐付け識別情報５４１、分析処理識別情報５４２、分析目的識別情報５４３、重み５４４、及び、更新日時５４５である。

　このうち紐付け識別情報５４１には、当該紐付けを一意に識別するための情報が格納される。また、分析処理識別情報５４２には、紐付けられる一方である分析処理４１３を識別するための情報が格納される。また、分析目的識別情報５４３には、紐付けられる他方である分析目的４１４を識別するための情報が格納される。また、重み５４４には、当該紐付けの重みを示す情報が格納される。例えば該紐付けによる組合せが分析者等のユーザにより多く使用される程、重みを表す数値は大きくなる。また、更新日時５４５には、上述の各データ項目５４１～５４４のレコードが最後に更新された日時が格納される。なお１つの分析処理４１３に対して、複数の紐付けがありえるため、分析処理－分析目的紐付けテーブル５０４において、当該１つの分析処理４１３に関して、複数のレコードが格納され得る。

　また、図５Ｅに例示する分析目的－業務紐付けテーブル５０５は、分析目的４１４におけるＫＰＩと業務アプリ４１５における業務及び設備等の対象との間の紐付けに関する情報を格納するテーブルである。その主な構成要素は、紐付け識別情報５５１、分析目的識別情報５５２、業務識別情報５５３、対象識別情報５５４、重み５５５、及び、更新日時５５６である。

　このうち紐付け識別情報５５１には、当該紐付けを一意に識別するための情報が格納される。また、分析目的識別情報５５２には、紐付けられる一方である分析目的４１４を識別するための情報が格納される。また、業務識別情報５５３には、紐付けられる他方である業務４１５１を識別するための情報が格納される。また、対象識別情報５５４には、業務４１５１と合わせて紐付けられる対象４１５２を識別するための情報が格納される。また、重み５５５には、当該紐付けの重みを示す情報が格納される。例えば該紐付けによる組合せが分析者等のユーザにより多く使用される程、重みを表す数値は大きくなる。また、更新日時５５６には、上述の各データ項目５５１～５５５のレコードが最後に更新された日時が格納される。なお１つの分析目的に対して、複数の紐付けがありうるため、分析目的－業務紐付けテーブル５０５において、上述の１つの分析目的に関して複数のレコードが格納され得る。

　また、図５Ｆに例示するデータ提供先業種－業務アプリ紐付けテーブル５０８は、ユースケース集ファイル３０２に記憶された用途４５０のデータ提供先の業種（“toB”）４５５と、ＡＳＰサーバ６００に登録された業務アプリ４１５との間の紐付けに関する情報を格納するテーブルである。その主な構成要素は、紐付け識別情報５８１、データ提供先業種情報“toB”５８２、業務アプリ情報５８３、重み５８４、及び、更新日時５８５である。

　このうち紐付け識別情報５８１には、当該紐付けを一意に識別するための情報が格納される。また、データ提供先業種情報“toB”５８２には、紐付けられる一方であるデータ提供先の業種（“toB”）４５５を識別するための情報が格納される。また、業務アプリ情報５８３には、紐付けられる他方である業務アプリ４１５を識別するための情報が格納される。また、重み５８４には、当該紐付けの重みを示す情報が格納される。例えば該紐付けによる組合せが分析者等のユーザにより多く採用されるなどの有用性が高い程、重みを表す数値は大きくなる。また、更新日時５８５には、上述の各データ項目５８１～５８４のレコードが最後に更新された日時が格納される。なお１つのデータ提供先の業種（“toB”）４５５に対して、複数の紐付けがありえるため、データ提供先業種－業務アプリ紐付けテーブル５０８において、当該１つのデータ提供先の業種（“toB”）４５５に関して、複数のレコードが格納され得る。

　また、図５Ｇに例示するデータ提供先利用目的－分析目的紐付けテーブル５０９は、ユースケース集ファイル３０２に記憶された用途４５０のデータ提供先の利用用途（“objective”）４５４と、ＡＳＰサーバ６００に登録された分析目的４１４との間の紐付けに関する情報を格納するテーブルである。その主な構成要素は、紐付け識別情報５９１、データ提供先利用用途情報“objective”５９２、利用用途情報５９３、重み５９４、及び、更新日時５９５である。

　このうち紐付け識別情報５９１には、当該紐付けを一意に識別するための情報が格納される。また、データ提供先利用用途情報“objective”５９２には、紐付けられる一方であるデータ提供先の利用用途（“objective”）４５４を識別するための情報が格納される。また、利用用途情報５９３には、紐付けられる他方である分析目的４１４を識別するための情報が格納される。また、重み５９４には、当該紐付けの重みを示す情報が格納される。例えば該紐付けによる組合せが分析者等のユーザにより多く採用されるなどの有用性が高い程、重みを表す数値は大きくなる。また、更新日時５９５には、上述の各データ項目５９１～５９４のレコードが最後に更新された日時が格納される。なお１つのデータ提供先の利用用途（“objective”）に対して、複数の紐付けがありえるため、データ提供先利用目的－分析目的紐付けテーブル５０９において、当該１つのデータ提供先の利用用途（“objective”）に関して、複数のレコードが格納され得る。

　また、図５Ｈに例示するデータ種別－データ紐付けテーブル５００は、ユースケース集ファイル３０２に記憶されたデータ種別４５１と、アセット端末２００に登録されたデータ４１１との間の紐付けに関する情報を格納するテーブルである。その主な構成要素は、紐付け識別情報５０１、データ種別情報５０２、データ情報５０３、重み５０４、及び、更新日時５０５である。なお、一例として、上述のように、データ種別４５１には、ユースケースのデータ提供元の業種“Ｂ”の情報が含まれ、一方、データ４１１には、当該データを登録したアセット端末４００のユーザ等の業種の情報が含まれ得るので、これらの対応関係に基づいて、データ種別－データ紐付けテーブル５００は、紐づけに関する情報を規定してもよい。

　このうち紐付け識別情報５０１には、当該紐付けを一意に識別するための情報が格納される。また、データ種別情報５０２には、紐付けられる一方であるデータ種別４５１を識別するための情報が格納される。また、データ情報５０３には、紐付けられる他方であるデータ４１１を識別するための情報が格納される。また、重み５０４には、当該紐付けの重みを示す情報が格納される。例えば該紐付けによる組合せが分析者等のユーザにより多く採用されるなどの有用性が高い程、重みを表す数値は大きくなる。また、更新日時５０５には、上述の各データ項目５０１～５０４のレコードが最後に更新された日時が格納される。なお１つのデータ種別４５１に対して、複数の紐付けがありえるため、データ種別－データ紐付けテーブル５００において、当該１つのデータ種別４５１に関して、複数のレコードが格納され得る。

　なお、本実施形態の分析関係テーブル３０７は、各データ分析ロジック４２２のメタ情報５０６、及び、各データ突合ロジック４２１のメタ情報５０７も格納している。

　このうち、図６Ａに例示するデータ分析ロジック４２２のメタ情報５０６には、当該データ分析ロジック４２２の入力となるデータに関する情報が格納される。その主な構成要素は、識別情報５６１、データ項目５６２、型５６３、及び、種別５６４である。

　このうち識別情報５６１には、当該メタ情報５０６の各レコードを一意に識別するための情報が格納される。また、データ項目５６２には、当該データ項目に該当するデータの名称が格納される。ただし本項目の指定が無い場合もある。また、型５６３には、上述のデータ項目５６２に該当するデータのデータ型が格納される。また、種別５６４には、上述のデータ項目５６２に該当するデータの種別が格納される。

　ここで種別５６４の値としては、“入力”、“キー”、等が想定され得る。このうち“入力”である場合、該当データ項目はデータ分析ロジックの入力データであることを示す。また、“キー”である場合、該当データ項目は、データ分析ロジックにおいて、複数データの突合せ、範囲指定、整列の軸となる共通インデックスであることを示す。

　また、図６Ｂに例示するデータ突合ロジック４２１のメタ情報５０７には、当該データ突合ロジック４２１により提供されるデータに関する情報が格納される。その主な構成要素は、識別情報５７１、データ項目５７２、型５７３、サイズ５７４、及び、テーブル５７５である。

　このうち識別情報５７１には、メタ情報５０７における各レコードを一意に識別するための情報が格納される。また、データ項目５７２には、当該データ項目５７２に該当するデータの名称が格納される。また、型５７３には、当該データ項目５７２に該当するデータのデータ型が格納される。また、サイズ５７４には、当該データ項目５７２に該当するデータのサイズが格納される。また、テーブル５７５には、当該データ項目５７２に該当するデータの抽出元のテーブルに関する情報が格納される。

　図７Ａは、本実施形態における分析対象データＤＢ３０４の構成例を示す図である。本実施形態の分析対象データＤＢ３０４は、アセット端末２００からデータ利活用基盤サーバ２００にアップロードされた、或いは、適宜なユーザ等により記憶媒体経由で格納されたデータ（派生データであってもよい。）である。より具体的には、アセット端末２００で管理しているデータであって、例えば該当業務に使用されている車両や機器等のセンシングデータ等を想定出来る（勿論、これに限定せず、種々のデータを想定可能である）。なお、分析対象データＤＢ３０４は、データに対応付けて、そのデータを登録したユーザやアセット端末２００の情報（ユーザＩＤ、端末ＩＤなどの識別情報、業種の情報、会社名や個人名等）を記憶することができる。

　図７Ａで例示する分析対象データＤＢ３０４は、一例として、複数のテーブルから構成されている。これらのテーブルは、図６Ｂで示したメタ情報５０７（データ突合ロジックのもの）のテーブル５７５にて指定されるデータ抽出元のテーブルに対応する。また、各テーブルは、図示するように、例えば該当データを観測した日時、箇所、結果、センサーID、送信されたプロトコル、センサーの地理的位置、測定値がキャプチャされたゲートウェイID、ゲートウェイの地理的位置、データ読み込みが行われた時間、予想される値またはスケールの範囲、トラストスコア（データ価値の評価値）といった各値を含むレコードの集合体となっている。

　図７Ｂは、本実施形態における分析結果ＤＢ３０５の構成例を示す図である。本実施形態の分析結果ＤＢ３０５は、データ利活用基盤サーバ２００が過去に提案した分析部品、或いはそれとは無関係に分析者２０１（或いは開発者２０２）が選定した分析部品、に基づき実際に実行した分析処理の内容を格納したＤＢである。具体的には、分析結果を一意に特定するＩＤをキーに、当該分析処理を構成する分析部品の、データ突合ロジック及びデータ分析ロジックの情報と、これらを用いて行った分析処理、その分析目的、業務、対象、結果（この場合、分析処理の実行結果として出力されるデータ値）といった値を含むレコードの集合体となっている。

　図７Ｃは、本実施形態における実績情報ＤＢ３０６の構成例を示す図である。本実施形態の実績情報ＤＢ３０６は、実際に実行された分析処理の実績情報を格納するＤＢである。具体的には、分析処理を一意に特定する分析処理名をキーに、当該分析処理の実行頻度（例：直近一ヶ月での実行回数）、利用者数（採用したユーザの数）、定型登録数、及び、修正回数（例：当該分析処理に関して分析者や開発者が修正を行った回数）、金額（例：ユーザが採用するためにかけた費用（データとアプリの購入金額等）の平均）、評価値（採用したユーザからの評価）、改善要望数（採用したユーザからの改善要望の回数）、期間（例：ユーザが採用した期間の平均）といった値を対応付けたレコードの集合体となっている。なお、上述の定型登録数とは、当該分析処理が高頻度で或いは広範に用いられるものと分析者等に認識され、定型の分析処理として設定された回数を示す。

＜シーケンス例＞
　以下、本実施形態におけるデータ利活用促進方法の実際手順について図に基づき説明する。以下で説明するデータ利活用促進方法に対応する各種動作は、データ利活用基盤サーバ２００が実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

　図８は、本実施形態におけるデータ利活用促進方法を実施する場合の処理シーケンスを示す図である。ここでは、既に図２にて示したシーケンスを、データ利活用ミドルウエア３００の各要素を用いて具体的に実行する場合の処理シーケンスについて示すものとする。

　その主な構成要素はアセット端末４００、データ利活用基盤サーバ２００にて稼働するデータ利活用ミドルウェア３００に含まれるデータ管理部３１４、分析関係情報管理部３０８、分析処理実績管理部３１２、提示部３０９、ユースケース集ファイル３０２、及び、分析関係テーブル３０７と、ユーザ端末１００のユーザである。

　このうちアセット端末４００にて、アセット推定部３１８からアセットマイニング等によってデータ提供の提案を受ける等して、該アセット端末４００が有するデータをデータ利活用基盤サーバ２００に対して登録する（ステップ６１１）。この場合、データ利活用基盤サーバ２００のデータ管理部３１４は、上述のアセット端末４００からのデータの登録を受け付ける（ステップ６２１）。また、データ管理部３１４は、分析関係情報管理部３０８に対して、データ登録受付の通知を行う（ステップ６２２）。

　そして、分析関係情報管理部３０８は、上述のデータ管理部３１４からの通知を受信すると、当該データから分析関係テーブル３０７を作成する（ステップ６３１）。なお、上述のように、分析関係情報管理部３０８は、ユースケース集ファイル３０２との紐付け情報（図４の横方向の対応関係）も、分析関係テーブル３０７に格納する。

　他方、提示部３０９は、ユースケース集ファイル３０２を参照して、ユーザ端末１００に、データ種別（ないしは業種）と用途の組み合わせ（ユースケース）の候補を提示する（ステップ６５０）。ユーザ端末１００のユーザは、ユーザ種別と用途の組み合わせ（ユースケース）の候補うち一つを指定する（ステップ６６１）。

　このとき、データ利活用基盤サーバ２００の提示部３０９は、ユーザ端末１００のユーザからのユースケース（ユーザ種別と用途の組み合わせ）の指定を受け付けると、分析関係テーブル３０７を参照して（ステップ６５１）、当該ユースケースであるユーザ種別（ないしは業種）と用途の組み合わせに対して、利用可能なデータと分析部品（アプリ等）の組み合わせ候補を選出する（ステップ６５２）。また、提示部３０９は、選出したデータ（ないしは当該データを登録した他ユーザの情報）と分析部品（アプリ等）の組み合わせ候補をユーザ端末１００のユーザに対して提案する（ステップ６５３）。

　ユーザ端末１００のユーザは、上述の提示部３０９から提案されたデータ（ないしは連携先候補の他ユーザ）と分析部品（アプリ等）の組み合わせ候補を閲覧し（ステップ６６２）、利用するデータ（ないしは連携先候補の他ユーザ）と分析部品（アプリ等）の組み合わせを決定する（ステップ６６３）。ユーザは、ここで提案されたデータ（ないしは連携先候補の他ユーザ）と分析部品（アプリ等）の組み合わせのいずれかを選択する、もしくは提案された組合せの一部を変更することで、利用するデータ（ないしは連携先の他ユーザ）と分析部品（アプリ等）の組み合わせを決定することとなる。また、ユーザは、上述にて決定したデータ（ないしは連携先）と分析部品（アプリ等）の組み合わせによる分析処理を実行する（ステップ６６４）。

　一方、分析処理実績管理部３１２は、上述のユーザによる分析処理の実行を確認して、該分析処理実行に係る実績（分析部品の組合せ、処理実行の履歴、分析結果、他ユーザ連携結果、ユーザからの評価や改善要望など）を記録し（ステップ６４１）、分析関係情報管理部３０８に対して実績記録の通知を行う（ステップ６４２）。この場合、分析関係情報管理部３０８は、上述の分析処理実績管理部３１２からの通知を受信すると、当該実績から分析関係テーブルを更新する（ステップ６３２）。

＜フロー例＞
　図９は、本実施形態におけるデータ利活用促進方法のフロー例を示す図である。具体的には、データ利活用基盤サーバ２００が、アセット端末４００から登録された所定データに基づき、分析関係テーブル３０７を生成するフローチャートである。

　この場合、データ利活用基盤サーバ２００は、アセット端末４００からのデータ登録を受け付ける（ステップ７０１）。ここで登録を受け付けるデータは、それぞれのアセット端末４００で保持する各種の業務データ、センシングデータ等である。

　また、データ利活用基盤サーバ２００は、上述のステップ７０１で得た登録データに対してデータ関係を生成する（ステップ７０２）。このデータ関係の生成処理は、既存技術を適宜に採用すればよいが、例えば、アセット端末４００を跨がって、値の観測箇所（例：地理空間情報）や時間帯、対象等の或る属性が１または複数共通するデータを対応付ける処理（ブロックチェーン技術、分散台帳技術）等を想定出来る。

　続いて、データ利活用基盤サーバ２００は、上述のステップ７０２で生成したデータ関係に基づき、関係付けられた１つ以上のデータを分析対象データＤＢ３０４より抽出するデータ突合ロジック及びメタ情報５０７を生成する（ステップ７０３）。

　データ突合ロジックの生成は、上述のデータ関係が示す各分析対象データを、分析対象データＤＢ３０４の該当テーブルから呼び出すためのＳＱＬ文を生成する処理が該当する。また、このＳＱＬ文の生成は、データ利活用基盤サーバ２００が予め保持するＳＱＬ文の雛形に、呼び出し対象のテーブルとデータの識別情報等をセットするといった手法を採用すればよい。

　また、メタ情報５０７の生成は、上述のデータ関係が示す各分析対象データの、文字列や数値といった型、サイズ、及び、格納先のテーブル名といった値、センサーID、送信されたプロトコル、センサーの地理的位置、測定値がキャプチャされたゲートウェイID、ゲートウェイの地理的位置、データ読み込みが行われた時間、予想される値またはスケールの範囲、トラストスコア（データの信憑性、データの所有権、データの品質、データの整合性などの各評価値などデータ信頼性やデータ有用性に関する各評価値）を、それぞれの分析対象データから読み取り、これをメタ情報５０７としてテーブル化する処理となる。

　また、データ利活用基盤サーバ２００は、上述のステップ７０３で生成したデータ突合ロジックのメタ情報５０７を参照し（ステップ７０４）、分析対象データとデータ突合ロジックとの紐付けについて、分析対象データ紐付けテーブル５０１にレコードを追加する（ステップ７０５）。

　続いて、データ利活用基盤サーバ２００は、データ紐付けロジックのメタ情報５０７に記載される全てのデータに対して処理が終了しているか判定し、終了していないことが判明した場合（ステップ７０６：ＮＯ）、ステップ７０５、ステップ７０６の処理を繰り返す。

　他方、ステップ７０６の判定において、データ紐付けロジックのメタ情報５０７に記載される全てのデータに対して処理が終了したことが判明した場合（ステップ７０６：ＹＥＳ）、データ利活用基盤サーバ２００は、全てのデータ突合ロジックに対して処理が終了しているか判定する（ステップ７０７）。

　この判定の結果、全てのデータ突合ロジックに対して処理が終了していることが判明した場合（ステップ７０７：ＮＯ）、データ利活用基盤サーバ２００は、ステップ７０４～７０６の処理を繰り返す。

　他方、上述の判定の結果、全てのデータ突合ロジックに対して処理が終了していることが判明した場合（ステップ７０７：ＹＥＳ）、かつ、全てのデータ関係に対して処理が終了していないことが判明した場合（ステップ７０８：ＮＯ）、データ利活用基盤サーバ２００は、ステップ７０３～７０７の処理を繰り返す。

　一方、上述のステップ７０８において、全てのデータ関係に対して処理が終了していることが判明した場合（ステップ７０８：ＹＥＳ）、データ利活用基盤サーバ２００は、データ分析ロジックのメタ情報５０６を参照し（ステップ７０９）、また、データ突合ロジックのメタ情報５０７を参照する（ステップ７１０）。

　次に、データ利活用基盤サーバ２００は、上述のステップ７０９、７１０での参照の結果、データ分析ロジックのメタ情報５０６にデータ項目５６２の指定が無い場合（ステップ７１１
：ＮＯ）、データ分析ロジックのメタ情報５０６とデータ突合ロジックのメタ情報５０７で型（５６３、５７３）の比較を行う（ステップ７１２）。

　続いて、データ利活用基盤サーバ２００は、上述のステップ７１２での比較の結果、データ突合ロジックのメタ情報５０７に、データ分析ロジックのメタ情報５０６におけるデータに合致するものが全て含まれることが判明した場合（ステップ７１３：ＹＥＳ）、データ突合ロジックとデータ分析ロジックの紐付けとして分析部品紐付けテーブル５０２にレコードを追加する（ステップ７１４）。

　他方、上述のステップ７１１において、データ分析ロジックのメタ情報５０６にデータ項目５６２の指定が有ることが判明した場合（ステップ７１１：ＹＥＳ）、データ利活用基盤サーバ２００は、データ分析ロジックのメタ情報５０６とデータ突合ロジックのメタ情報５０７とでデータ項目（５６２、５７２）の比較を行う（ステップ７１５）。

　次に、データ利活用基盤サーバ２００は、上述のステップ７１５での比較の結果、データ突合ロジックのメタ情報５０７にデータ分析ロジックのメタ情報５０６におけるデータに合致するものが全て含まれることが判明した場合（ステップ７１６：ＹＥＳ）、データ突合ロジックとデータ分析ロジックとの紐付けとして分析部品紐付けテーブル５０２にレコードを追加する（ステップ７１７）。

　また、データ利活用基盤サーバ２００は、上述のステップ７１７で紐付けたデータ突合ロジックのメタ情報５０７に、データ分析ロジックのメタ情報５０６にて種別５６４が“キー”であるデータに対応するデータが含まれるか判定する（ステップ７１８）。

　この判定の結果、“キー”であるデータに対応するデータが含まれないことが判明した場合（ステップ７１８：ＮＯ）、データ利活用基盤サーバ２００は、データ分析ロジックのメタ情報５０６にて種別５６４が“入力”であるデータからデータ関係を参照して、“キー”に該当するデータを検索する（ステップ７１９）。

　また、データ利活用基盤サーバ２００は、上述のステップ７１９で検索したデータとの紐付けとして、分析対象データ紐付けテーブル５０１にレコードを追加する（ステップ７２０）。
　次に、データ利活用基盤サーバ２００は、全てのデータ突合ロジックに対して処理が終了しているか判定する（ステップ７２１）。この判定の結果、全てのデータ突合ロジックに対して処理が終了していないことが判明した場合（ステップ７２１：ＮＯ）、データ利活用基盤サーバ２００は、ステップ７１０～７２０の処理を繰り返す。

　他方、上述のステップ７２１において、全てのデータ突合ロジックに対して処理が終了していることが判明した場合（ステップ７２１：ＹＥＳ）、データ利活用基盤サーバ２００は、全てのデータ分析ロジックに対して処理が終了しているか判定する（ステップ７２２）。

　この判定の結果、全てのデータ分析ロジックに対して処理が終了していないことが判明した場合（ステップ７２２：ＮＯ）、データ利活用基盤サーバ２００は、ステップ７０９～７２１の処理を繰り返す。他方、全てのデータ分析ロジックに対して処理が終了していることが判明した場合（ステップ７２２：ＹＥＳ）、データ利活用基盤サーバ２００は、処理を終了する。

＜フロー例２＞
　図１０は、本実施形態におけるデータ利活用促進方法のフロー例２を示す図である。具体的には、分析処理の実行実績に基づき分析関係テーブル３０７を更新する処理の流れを示すフローチャートである。

　まず、データ利活用基盤サーバ２００は、分析者２０１により実行された分析処理（分
析部品の組合せ）に関する情報の、分析関係テーブル３０７への登録有無を確認する（ステップ８０１）。なお、分析者２０１により分析処理が実行されたこと自体は、例えば、分析結果ＤＢ３０５でのレコード登録イベントを通じて検知出来る。

　続いて、データ利活用基盤サーバ２００は、ステップ８０１の結果、分析関係テーブル３０７への分析処理の登録が確認された場合（ステップ８０２：ＹＥＳ）、該当分析処理（とこれを構成する分析部品、分析対象データ等）に関して、分析関係テーブル３０７の各テーブルにおいて互いに紐付いている各レコードの「重み」の情報を更新する（ステップ８０３）。この更新は、例えば、「重み」の値をインクリメントすることとなる。

　他方、ステップ８０１の結果、分析関係テーブル３０７への分析処理の登録が確認出来なかった場合（ステップ８０２：ＮＯ）、データ利活用基盤サーバ２００は、上述の実行した分析処理を構成する各々の分析部品、分析対象データの間の紐付けを、当該分析処理の情報に基づき確認する（ステップ８０４）。

　次に、データ利活用基盤サーバ２００は、上述の実行した分析処理の情報を、分析関係テーブル３０７へ新規登録する（ステップ８０５）。また、データ利活用基盤サーバ２００は、上述の実行した分析処理に関する情報として、分析処理－分析目的紐付けテーブル５０４及び分析目的－業務紐付けテーブル５０５にレコードを追加する（ステップ８０６）。

　また、データ利活用基盤サーバ２００は、分析部品－分析処理紐付けテーブル５０３に該当する既存の紐付けレコードが有るか判定する（ステップ８０７）。この判定の結果、分析部品－分析処理紐付けテーブル５０３に該当する既存の紐付けレコードが有ることが判明した場合（ステップ８０７：ＹＥＳ）、データ利活用基盤サーバ２００は、分析部品－分析処理紐付けテーブル５０３における該当レコードの重みの情報を更新する（ステップ８０８）。

　続いて、データ利活用基盤サーバ２００は、上述の８０７の判定の結果、分析部品－分析処理紐付けテーブル５０３に該当する既存の紐付けレコードが無いことが判明した場合（ステップ８０７：ＮＯ）、分析部品－分析処理紐付けテーブル５０３に、上述の実行した分析処理における紐付けに関するレコードを追加する（ステップ８０９）。

　また、データ利活用基盤サーバ２００は、分析部品紐付けテーブル５０２に、該当する既存の紐付けレコードが有るか判定する（ステップ８１０）。この判定の結果、分析部品紐付けテーブル５０２に、該当する既存の紐付けレコードが有ることが判明した場合（ステップ８１０：ＹＥＳ）、データ利活用基盤サーバ２００は、分析部品紐付けテーブル５０２における該当レコードの重みの情報を更新する（ステップ８１１）。

　他方、上述のステップ８１０での判定の結果、分析部品紐付けテーブル５０２に該当する既存の紐付けレコードが無いことが判明した場合（ステップ８１０：ＮＯ）、データ利活用基盤サーバ２００は、分析部品紐付けテーブル５０２に、上述の実行した分析処理における紐付けに関するレコードを追加する（ステップ８１２）。

　続いて、データ利活用基盤サーバ２００は、分析対象データ紐付けテーブル５０１に、該当する既存の紐付けレコードが有るか判定する（ステップ８１３）。この判定の結果、分析対象データ紐付けテーブル５０１に、該当する既存の紐付けレコードが有ることが判明した場合（ステップ８１３：ＹＥＳ）、データ利活用基盤サーバ２００は、分析対象データ紐付けテーブル５０１における該当レコードの重みの情報を更新する（ステップ８１４）。

　他方、上述のステップ８１３の判定の結果、分析対象データ紐付けテーブル５０１に該当する既存の紐付けレコードが無いことが判明した場合（ステップ８１３：ＮＯ）、データ利活用
基盤サーバ１０１は、分析対象データ紐付けテーブル５０１に、上述の実行した分析処理における紐付けに関するレコードを追加する（ステップ８１５）。

　次に、データ利活用基盤サーバ２００は上述の実行した分析処理の分析結果（分析処理の実行結果として出力されるデータ値。例えばＫＰＩの値）を、上述の実行した分析処理との紐付けて、分析結果ＤＢ３０５に保存する（ステップ８１６、８１７）。

　また、データ利活用基盤サーバ２００は、上述の実行した分析処理に関して、実績情報ＤＢ０６における実績情報を更新する（ステップ８１８）。具体的には、該当分析処理の、実行頻度、利用者数、定型登録数、修正回数といった値を更新することとなる。

＜フロー例３＞
　図１１は、本実施形態におけるデータ利活用促進方法のフロー例３を示す図である。具体的には、データ利活用基盤サーバ２００がユースケース集ファイル３０１との対応関係等を規定した分析関係テーブル３０７を参照して、ユーザ指定のユースケース（用途とデータ種別（ないしはデータ提供元（連携先）の業種）の組み合わせ）に対応する分析対象データに対して、対応する分析を実行するために適切な分析部品の組合せを選出し提示するための処理の流れを示すフローチャートである。

　この場合、データ利活用基盤サーバ２００は、ユーザからの分析対象データの指定をユーザ端末１００を介して受け付ける（ステップ９０１）。このユーザからの分析対象データの指定は、ユーザがユースケースを指定すると自動的に対応付けられたデータを呼び出すものであってもよく、図８で説明したように、ユーザがユースケースを指定することによって提示された分析対象データ候補の中からユーザが指定することによって成立するものであってもよく、上述のように、ユーザがデータ提供元（連携先）の業種“B”や用途“objective”を指定することで成立するものであってもよい。

　また、データ利活用基盤サーバ２００は、分析関係テーブル３０７を参照し（ステップ９０２）、上述のユーザ指定の分析対象データに紐付く分析部品（データ突合せロジック、データ分析ロジック）を抽出し（ステップ９０３）、分析部品組合せ候補を作成する（ステップ９０４）。この候補は、ステップ９０３で抽出できた分析部品のリストである。

　続いて、データ利活用基盤サーバ２００は、上述で作成した分析部品組合せ候補に類似する、分析処理を抽出する（ステップ９０６）。なお、本処理の詳細は図１２にて後述する。

　続いて、データ利活用基盤サーバ２００は、ステップ９０６で抽出した類似処理の分析結果を、分析結果ＤＢ３０５から抽出する（ステップ９０７）。この分析結果は関連する情報としてユーザに提示するためのものである。

　次に、データ利活用基盤サーバ２００は、実績情報ＤＢ３０６を参照して、上述の類似処理の実行頻度を算出する（ステップ９０８）。また、データ利活用基盤サーバ２００は、実績情報ＤＢ３０６を参照して、上述の類似処理の利用者数を算出する（ステップ９０９）。
　また、データ利活用基盤サーバ２００は、実績情報ＤＢ３０６を参照して、上述の類似処理の定型業務としての登録数を算出する（ステップ９１０）。

　また、データ利活用基盤サーバ２００は、実績情報ＤＢ３０６を参照して、上述の類似処理の修正回数を算出する（ステップ９１１）。また、データ利活用基盤サーバ２００は、分析関係テーブル３０７を参照して、上述の類似処理の類似処理数を算出する（ステップ９１２）。

　続いて、データ利活用基盤サーバ２００は、上述のステップ９０７から９１２の結果を用いて、当該分析部品組合せの有用度を判定する（ステップ９１３）。ここでは、上述のステップ９０８～９１２の各結果に重み付け加算による点数算出等を行う。なお、有用度（有用性の評価値）の判定は、これに限られず、データ利活用基盤サーバ２００は、ユースケース集ファイル３０２に、データ種別（ないしは業種）と用途の同じ組み合わせが、多くの特許文献やWebデータにおいて記述されているほど、当該データ種別と用途の同じ組み合わせに対応するデータと分析部品の組み合わせの有用度が高いと判定してもよい。また、データ利活用基盤サーバ２００は、ユースケース集ファイル３０２に、同じデータ種別（ないしは業種）に対して、複数の特許文献やWebデータにわたって多くの用途があるほど、当該データ種別（ないしは業種）に対応するデータの有用度が高いと判定してもよい。

　また、データ利活用基盤サーバ２００は、全ての分析部品組合せ候補に対して処理が終了しているか判定する（ステップ９１４）。この判定の結果、全ての分析部品組合せ候補に対して処理が終了していないことが判明した場合（ステップ９１４：ＮＯ）、データ利活用基盤サーバ２００は、ステップ９０６～９１３の処理を繰り返す。

　他方、上述の判定の結果、全ての分析部品組合せ候補に対して処理が終了していることが判明した場合（ステップ９１４：ＹＥＳ）、データ利活用基盤サーバ２００は、処理の結果として、分析部品組合せ候補、有用度判定結果及び類似処理の分析結果を、ユーザ端末１００に出力し（ステップ９１５）、当該ユーザに対して提示する。

＜フロー例４＞
　図１２は、本実施形態におけるデータ利活用促進方法のフロー例４を示す図である。具体的には、データ利活用基盤サーバ２００が、ユーザ指定の分析対象データに対して分析を実行するための、適切な分析部品の組合せを選出する際に、類似の既存分析処理を選出するフローチャートである。

　この場合、データ利活用基盤サーバ２００は、分析関係テーブル３０７を参照して、図１１のフローにて選出した、指定された分析対象データに対する分析部品の組合せ候補と、分析処理の実績として蓄積されている既存の分析部品組合せとの比較を行う（ステップ１００１）。

　次に、データ利活用基盤サーバ２００は、上述の分析部品組合せ候補と既存分析部品組合せとで入力データ項目が一致するか判定する（ステップ１００２）。

　この判定の結果、上述の分析部品組合せ候補と既存分析部品組合せとで入力データ項目（例：データの種類やデータ提供元の業種など）が一致しないことが判明した場合（ステップ１００２：ＮＯ）、データ利活用基盤サーバ２００は、当該組合せ同士は類似しないと判定し（ステップ１００９）、処理をステップ１０１０に遷移させる。

　他方、上述の判定の結果、上述の分析部品組合せ候補と既存分析部品組合せとで入力データ項目が一致することが判明した場合（ステップ１００２：ＹＥＳ）、データ利活用基盤サーバ２００は、分析部品組合せ候補と既存分析部品組合せとで構成する分析部品の種別が一致する数が、指定された閾値以上か判定する（ステップ１００３）。

　上述の判定の結果、分析部品の種別が一致する数が、指定された閾値以上ではないことが判明した場合（ステップ１００３：ＮＯ）、データ利活用基盤サーバ２００は、当該組合せ同士は類似しないと判定し（ステップ１００９）、処理をステップ１０１０に遷移させる。

　他方、上述の判定の結果、分析部品の種別が一致する数が、指定された閾値以上であることが判明した場合（ステップ１００３：ＹＥＳ）、データ利活用基盤サーバ２００は、当該分析部品組合せ候補と既存分析部品組合せとで構成する分析部品の実行順序が一致するか判定する（ステップ１００４）。

　上述の判定の結果、分析部品の実行順序が一致しないことが判明した場合（ステップ１００４：ＮＯ）、データ利活用基盤サーバ２００は、当該組合せ同士は類似しないと判定し（ステップ１００９）、処理をステップ１０１０に遷移させる。

　他方、上述の判定の結果、分析部品の実行順序が一致することが判明した場合（ステップ１００４：ＹＥＳ）、データ利活用基盤サーバ２００は、分析関係情報としてＫＰＩ、業務、対象の情報が有るか判定する（ステップ１００５）。

　この判定の結果、ＫＰＩ、業務、対象の情報が無いことが判明した場合（ステップ１００５：ＮＯ）、データ利活用基盤サーバ２００は、当該組合せ同士は一部分のみが類似する準類似であると判定し（ステップ１００８）、処理をステップ１０１０に遷移させる。

　他方、上述の判定の結果、ＫＰＩ、業務、対象の情報があることが判明した場合（ステップ１００５：ＹＥＳ）、データ利活用基盤サーバ２００は、当該分析部品組合せ候補と既存分析部品組合せとでＫＰＩ、業務、対象が一致する数が、指定された閾値以上か判定する（ステップ１００６）。

　上述の判定の結果、ＫＰＩ、業務、対象が一致する数が、指定された閾値以上ではないことが判明した場合（ステップ１００６：ＮＯ）、データ利活用基盤サーバ２００は、当該組合せ同士は一部分のみが類似する準類似であると判定し（ステップ１００８）、処理をステップ１０１０１に遷移させる。

　他方、上述の判定の結果、ＫＰＩ、業務、対象が一致する数が、指定された閾値以上であることが判明した場合（ステップ１００６：ＹＥＳ）、データ利活用基盤サーバ２００は、当該組合せ同士は類似であると判定し（ステップ１００７）、処理をステップ１０１０に遷移させる。

　次に、データ利活用基盤サーバ２００は、全ての分析部品組合せ候補及び既存分析部品組合せに対して比較が終了しているか判定する（ステップ１０１０）。この判定の結果、全ての分析部品組合せ候補及び既存分析部品組合せに対して比較が終了していないことが判明した場合（ステップ１０１０：ＮＯ）、データ利活用基盤サーバ２００は、上述のステップ１００１から１００９までの処理を繰り返す。

　他方、上述の判定の結果、全ての分析部品組合せ候補及び既存分析部品組合せに対して比較が終了していることが判明した場合（ステップ１０１０：ＹＥＳ）、データ利活用基盤サーバ２００は処理を終了する。

＜ユースケースからデータとアプリの組み合わせの取得方法＞
　図１３は、データ利活用基盤サーバ２００が、ユースケース４５１に基づいて、分析関係テーブル３０７を参照して、ユーザに提案する、データ４１１と分析部品類４１２～４１５の組み合わせを取得する手法を模式的に示す図である。なお、図１３におけるωは、重みを表している。

　データ利活用基盤サーバ２００が、ユースケース集ファイル３０２に記憶されたユースケース４５１に基づいて、データ４１１と分析部品類４１２～４１５の組み合わせを取得する。図１３に示すように、これは、ちょうど、データ種別４５１から用途４５０に至るまでの経路（ノードとリンクの組み合わせ）を求めることに似ている。

　したがって、データ利活用基盤サーバ２００は、ダイクストラ法などの公知の最短経路探索手法を用いて、ユースケース４４１から、データ４１１と分析部品類４１２～４１５の組み合わせを取得してもよい。

　図１３は、グラフ探索アルゴリズムの双方向探索の手法を矢印で示したものである。すなわち、第１段階として、データ利活用基盤サーバ２００は、データ種別－データ紐付けテーブル５００を参照して、データ種別（例：データ提供元の業種“B”およびデータの種類）に対応する、データ（例：データＢ、Ｃ）および重みω５０４を取得する。

　並行して逆向きから、データ利活用基盤サーバ２００は、データ提供先業種－業務アプリ紐付けテーブル５０８を参照して、データ提供先の業種“toB”４５５に対応する業務アプリ（例：アプリＡ）と重み５８４を取得するとともに、データ提供先の利用目的４５４に対応する、分析目的（例：ＫＰＩα）と重み５９４を取得し、分析目的－業務紐付けテーブル５０５を参照して、取得された業務アプリと分析目的に対応する重みω５５５を加算または乗算する。
積算重み＝ω５８４＊ω５９４＊ω５５５

　第２段階として、データ利活用基盤サーバ２００は、分析対象データ紐付けテーブル５０１を参照して、第１段階で特定したデータ（データＣ，Ｄ）にリンクするデータ突合ロジック４２２（例：突合せロジックａ，ｂ）および、それぞれの重みω５１４を特定して、加算または乗算する。
積算重み＝ω５０４＊ω５１４

　並行して逆向きから、データ利活用基盤サーバ２００は、分析処理－分析目的紐付けテーブル５０４を参照して、第１段階で特定した業務アプリ・分析目的（例：アプリＡ・ＫＰＩα）にリンクする、分析処理（例：分析処理１、２）と、それぞれの重みω５４４を特定して、加算または乗算する。
積算重み＝ω５８４＊ω５９４＊ω５５５＊ω５４４

　第３段階として、データ利活用基盤サーバ２００は、第２段階で特定した突合せロジック（例：突合せロジックａ，ｂ）にリンクするデータ分析ロジック（例：分析ロジック１、２、３）と、それぞれの重みω５２４を特定して、加算または乗算する。
積算重み＝ω５０４＊ω５１４＊ω５２４

　並行して逆向きから、データ利活用基盤サーバ２００は、第２段階で特定した分析処理（例：分析処理１、２）にリンクする分析ロジック（例：分析ロジック１、２、３）と、それぞれの重みω５３４を特定して、加算または乗算する。
積算重み＝ω５８４＊ω５９４＊ω５５５＊ω５４４＊ω５３４

　以上の３つのステップで、双方向からの探索は、同じデータ分析ロジック４２２のノードに辿り着いたので、双方からの探索により同じ分析ロジック（例：分析ロジック１、２、３）に辿り着いた経路同士を繋げて、それぞれの重みを加算または乗算する。
積算重みtotalω＝ω５８４＊ω５９４＊ω５５５＊ω５４４＊ω５３４＊ω５０４＊ω５１４＊ω５２４

　この例では、（アプリ，分析目的，分析処理，分析ロジック，突合せロジック，データ）＝
（A，α，１，１，ａ，Ｂ），
（A，α，１，２，ａ，Ｂ），
（A，α，１，１，ａ，Ｃ），
（A，α，２，１，ａ，Ｃ），
（A，α，１，２，ａ，Ｃ），
（A，α，２，２，ａ，Ｃ），
（A，α，１，２，ｂ，Ｃ），
（A，α，２，３，ｂ，Ｃ）の８つの経路が取得され、このうちで積算重みtotalωが最も大きいもの順に価値が高いと判定される。

　このように、データ利活用基盤サーバ２００は、ユーザが採用したユースケース４５１から、データと分析部品類４１２～４１５の組み合わせを特定して、その重みに基づいて、ユーザに提示する。例えば、データ利活用基盤サーバ２００は、それぞれの組み合わせに重みの値を表示してもよく、重みが大きい順、価値が高い順に優先表示してもよい。

　なお、それぞれの重みω（ω５８４，ω５９４，ω５５５，ω５４４，ω５３４，ω５０４，ω５１４，ω５２４）は、有用性の評価値（有用度）に限らず、評価モジュール部３１９による真正性や信頼性など、データやソフトウェア分析部品の価値等に基づいた値（有用度および／または信頼度）であってもよい。具体例として、重みωは、（１）採用したユーザの数が多いほど、（２）ユーザが採用した期間が長いほど、（３）ユーザが採用するためにかけた費用が大きいほど、（４）採用したユーザからの評価が高いほど、（５）採用したユーザからの改善要望が多いものほど、（６）データの網羅性が高いほど、（７）データの正確性が高いほど、（８）データの整合性が高いほど、（９）データの適時性が高いほど、（１０）データ加工の品質が高いほど、（１１）元データから派生データの再現性が高いほど、および、（１２）データ連携による効果が高いほど、のうち少なくとも一つに基づいて、価値が高いとの評価付けをした値であってもよい。

＜画面例＞
　図１４は、本実施形態における出力画面の例である。具体的には、図８のステップ６６１で、ユーザ端末１００を介してユーザが選択したユースケース（データ種別、用途）に対応してステップ６５３で提案する、データと分析部品の組合せ候補の確認画面の例である（ステップ６６２）。

　図１４で例示する画面１１０１には、例えば、ユーザが指定する分析対象データを表示する、分析対象データ欄１１１１と、候補表示欄１１１２とを含んでいる。分析対象データ欄１１１１には、データの種類やデータＩＤを示す情報のほか、データ提供元の業種やデータ提供者（他ユーザ）に関する情報が記載されてもよい。これにより、ユーザは、連携先候補を把握することができる。

　また、候補表示欄１１１２は、ユーザ指定の分析対象データに対して分析処理の候補となる、データ突合ロジック及びデータ分析ロジックの組合せ、及び該組合せに関連付けられる分析処理、分析目的、業務、対象と、該組合せの有用度、関連分析結果（図７Ｂの分析結果ＤＢ３０５における該当レコードのＩＤ）を一覧表示する。なお該当する情報が無い場合は空白箇所を含めて表示する。

　以上、本発明を実施するための最良の形態等について具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

［評価モジュールとしての統制システム］
　評価モジュール部３１９は、一例として、データの受け渡しを行うＡＰＩ等であってもよく、ネットワーク等を介して統制システム９００に接続されることにより、統制システム９００からの評価を受け入れてもよい。なお、評価モジュール部３１９自体が、統制システム９００であってもよい。

　図１に図示しなかったが、本実施形態にかかるデータ利活用促進システムを含むデータ流通基盤の機能モジュールとして、統制システム９００が含まれ得る。図１５は、本実施形態の統制システムの構成例を示すブロック図である。

＜システム全体構成＞
　以下に本発明の実施形態について図面を用いて詳細に説明する。この統制システム９００は、本実施形態において、ＡＰＩ（Application Programming Interface）等のインターフェイスを介したデータの入出力を仲介する装置となる。さらに、統制システム９００は、アセット端末４００やユーザ端末１００やＡＳＰシステム６００等と接続されるインターフェイス（評価モジュール部３１９等）を介して入出力されるデータおよび／または当該データを取得するセンサや当該データを扱うシステムに対して、評価または価値付けを行い、評価結果または価値付け結果を記憶部９０６に格納し、評価結果を評価モジュール部３１９に返すデータデューデリジェンス（ＤＤ）を行うことができる。

　こうした統制システム９００は、ネットワークを介して、ユーザ端末１００やアセット端末４００と、また、いわゆるＡＳＰ（Application Service Provider）として様々なソフトウェアをサービスとして提供するＳａａＳ（Software as a Service）システム６００と、それぞれデータ通信可能に接続されている。なお、図１では、ユーザ端末１００やアセット端末４００やＡＳＰシステム６００は、各一台を図示しているが、それぞれ複数台あってもよいものである。また、ユーザ端末１００、アセット端末４００、およびＡＳＰシステム６００のうち少なくとも一つを含めて、データ流通基盤システムとして構成してもよい。また、ＡＳＰシステム６００は、クラウドサーバの一部であってもよく、または、ゲートウェイに接続されてもよい。

　上述のネットワーク構成におけるユーザ端末１００は、本実施形態において、データ利活用（候補）者側の端末であり、入出力部２０８を介して、遵守すべき統制ルールを統制システム９００に設定登録することによって、統制システム９００が仲介する、統制ルールに適合したデータを受信してデータ利活用することができる端末となる。

　アセット端末４００は、本実施形態において、データ提供（候補）者側の端末であり、データ提供の際には、そのデータを、直接、または、ＡＳＰシステム６００を介して間接的に、ユーザ端末１００のユーザに提供する。この際、本実施の形態では、統制システム９００が、このアセット端末４００からユーザ端末１００へのデータ送受信を仲介することで、ＩＴ統制などの統制ルールを遵守させることができる。例えば、統制システム９００は、アセット端末４００から送信されたデータに、個人情報が含まれている場合、個人情報保護法の統制ルールを遵守させるために、アセット端末４００からの元データから個人情報や機微情報を削除したり加工することで、仮名加工情報にあたるデータとして出力させたり、元データからの学習済みモデルを用いてオントロジー化したデータやナレッジグラフから生成した派生データを匿名加工情報として出力させたりするなどして、ユーザ端末１００へデータ出力してもよいものである。

　このほか、アセット端末４００は、データを送信（アップロード）することなく、データを学習させた学習済みモデル等のデータ処理結果を、統制システム９００等に提供することでデータ提供としてもよい。この場合、統制システム９００は、受信した学習済みモデル等に基づいて派生データを生成させて、ユーザ端末１００やＡＳＰシステム６００にデータを提供することができる。

　また、ＡＳＰシステム６００は、アセット端末４００から直接、または、統制システム９００を介して間接的に、各種データ（例：運輸・物流の走行データや、機器の温度・振動といった観測データ、メンテナンス履歴等）の提供を受けて処理するシステムである。このＡＳＰシステム６００は、一例として、ユーザ端末１００のユーザが、アセット端末４００から提供されたデータの分析によって問題解決を行う対象となり、すなわち既存ビジネスの生産性向上や、新規ビジネス開発や、DXのためのツール等となる。その際、すなわち、ユーザ端末１００のユーザが、アセット端末４００から提供されるデータを用いる際や、アセット端末４００から提供されるデータを用いてＡＳＰシステム６００のアプリケーション等を実行する際に、本実施形態の統制システム９００にデータ入出力を仲介させることで、各種の統制ルールを遵守することができる。すなわち、本実施形態の統制システム９００は、各種統制を実現するためのデータハブと捉えることができる。

＜ハードウェア構成＞
　上述の統制システム９００のハードウェア構成の一例を説明する。すなわち、統制システム９００は、一例として、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）やハードディスクドライブ等の適宜な不揮発性記憶素子や、メモリ等の揮発性記憶素子を含む記憶部９０６、記憶部９０６に保持されるプログラム等を実行し装置自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等の制御部９０２、ネットワークと接続し他装置との通信処理を担う通信部９０４、キーボードなどの入力手段やディスプレイなどの出力手段である入出力部９０８を備えるコンピュータ等である。なお、上述のように、統制システム９００は、本実施形態において、分散型コンピューティング装置として構成されているので、クラウドサーバ、エッジコンピュータ、および、ゲートウェイは、これら記憶部９０６や制御部９０２や入出力部９０８のうちの少なくとも一つを備えていなくてもよく、後述する記憶部９０６や制御部９０２や入出力部９０８のうちの一機能を備えていなくてもよい。

　こうしたハードウェア構成は、ユーザ端末１００、アセット端末４００、およびＡＳＰシステム６００の各部においても同様である。例えば、ユーザ端末１００は、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）やハードディスクドライブ等の適宜な不揮発性記憶素子や、メモリ等の揮発性記憶素子を含む記憶部２０６、記憶部２０６に保持されるプログラム等を実行し装置自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等の制御部２０２、ネットワークと接続し統制システム９００等との通信処理を担う通信部２０４、キーボードなどの入力手段やディスプレイなどの出力手段である入出力部２０８を備える。

　同様に、アセット端末４００は、ＳＳＤやハードディスクドライブ等の適宜な不揮発性記憶素子や、メモリ等の揮発性記憶素子を含む記憶部４０６、記憶部４０６に保持されるプログラム等を実行し装置自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等の制御部４０２、ネットワークと接続し統制システム９００等との通信処理を担う通信部４０４、キーボードなどの入力手段やディスプレイなどの出力手段である入出力部４０８を備える。図示しないが同様に、ＡＳＰシステム６００は、ＳＳＤやハードディスクドライブ等の適宜な不揮発性記憶素子や、メモリ等の揮発性記憶素子を含む記憶部、記憶部に保持されるプログラム等を実行し装置自体の統括制御を行うとともに各種判定、演算及び制御処理を行うＣＰＵ等の制御部、ネットワークと接続し統制システム９００等との通信処理を担う通信部、キーボードなどの入力手段やディスプレイなどの出力手段である入出力部等を備えてもよい。

＜統制システム９００の内部構成＞
　また、図１５において、本実施形態にかかる統制システム９００を含むデータ流通基盤システムは、統制システム９００、複数のアプリケーション９０１、及び複数のマイクロサービス９０３から構成される。アプリケーション９０１は、アセット端末４００やＡＳＰシステム６００等のコンピュータ上で稼働し、マイクロサービス９０３は、ユーザ端末１００やＡＳＰシステム６００等のコンピュータから構成されるシステム上で稼働する。なお、本発明は、アプリケーション９０１及びマイクロサービス９０３の種類及び数に限定されない。また、アプリケーション９０１やマイクロサービス９０３は、ＡＳＰシステム６００等が提供するシミュレーション・プログラム等の高度なソフトウェアを実行することにより実現されるものに限られず、アプリケーション９０１は、単に、アセット端末４００のデータ送信用アプリケーション等と捉えてもよく、マイクロサービス９０３は、単に、ユーザ端末１００のデータ受信用アプリケーション等と捉えてもよい。

　統制システム９００、アプリケーション９０１を実行するコンピュータ（アセット端末４００やＡＳＰシステム６００等）、及びマイクロサービス９０２を実行するシステム（ユーザ端末１００やＡＳＰシステム６００等）は、ネットワークを介して互いに接続される。ネットワークは、ＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）及びＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）等である。ネットワークの接続形式は、有線又は無線のいずれでもよい。

　統制システム９００は、一つのアプリケーション９０１に対して、統制システム９００と接続するための少なくとも一つのAPI９０５を提供する。また、一つのマイクロサービス９０２は、統制システム９００と接続するための少なくとも一つのAPI９０７を提供する。なお、統制システム９００が、一つのマイクロサービス９０２と接続するための少なくとも一つのAPI９０７を提供してもよい。

　統制システム９００は、図１５に示すように、通信部９０４（データ入出力のためのインターフェイスであるAPI９０５，API９０７等）と、制御部９０２（受信部９１０と、統制部９２０と、データデューデリジェンス（DD）部９４０と、送信部９１１等）と、記憶部１３０（統制ライブラリ９３０、ナレッジグラフデータベース（DB）９３１、評価結果ログデータベース（DB）９３２）を備えている。

　このうち、記憶部９０６は、統制種別ごとの統制に対応するコードおよび／または設定を記憶する統制ライブラリ９３０を備える。例えば、統制ライブラリ９３０は、統制種別（各種のIT統制（例：セキュリティガイドライン等）、各種の物理統制（例：警備員の駐在、入退室カードによる自動扉の設置など）、各種の内部統制（例：取引の監視など））と、その統制を実現し得るコードおよび／または設定とを、対応付けて記憶している。より具体的には、統制ライブラリ９３０は、統制ルールとして、例えば、遵守すべきガイドライン、統制フレームワーク、法律、条約、契約書条項、および、回避すべきリスクのうち少なくとも一つと、コードおよび／または設定とを対応付けて格納することにより、統制種別ごとの統制に対応するコードおよび／または設定を記憶する。

　また、記憶部９０６は、ナレッジグラフを記憶するナレッジグラフデータベース（DB）９３１を備える。一例として、ナレッジグラフは、エッジとノードから構成されており、ノードは、概念や単語や項目を表し、エッジは、そのノード間の関係性や共起性や統計量を表す。ノードは言語に限られないが、より具体的な例として、ナレッジグラフは、大規模言語モデル（large language model、LLM）であってもよい。そのほか、ナレッジグラフDB９３１は、分析学習部９２３による分析結果（共起性などの統計情報等）や学習結果（学習済み学習モデル等）を記憶してもよい。

　また、評価結果ログデータベース（DB）９３２は、後述するデータデューデリジェンス部１４０による評価結果または価値付け結果を記憶する。

　制御部９０２のうち、データデューデリジェンス部９４０（データDD部940）は、インターフェイス９０５，９０７を介して入出力されるデータに対して、評価または価値付け（以下「評価または価値付け」を纏めて「評価」と呼ぶ場合がある。）を行い、その評価結果を記憶部９０６の評価結果ログDB９３２に格納する。また、データDD部940は、評価結果ログＤＢに記憶された統制検証用ログ等に基づいて、評価または価値付けを行ってもよい。

＜リアルタイムな動作評価手法の例＞
　換言すれば、データDD部940は、データ流通基盤のデータパイプラインに埋め込まれ、通信部９０４を介して評価を行う評価モジュールである。より具体的には、アセット端末４００から、データがアップロードされる際に、データDD部940は、そのデータパイプライン経路上のゲートウェイやエッジコンピュータに埋め込まれており、そのデータの評価値をスコアリングして、メタデータとして当該データに付加や、評価結果ログDB９３２に格納する機能を有してもよい。例えば、データDD部940は、データの信頼性に関する評価値として、以下の（Ａ）～（J）の項目のうち少なくとも一つについて、それぞれスコアリングして、信頼性評価値としてメタデータに埋め込み、および／または、評価結果ログDB９３２に格納してもよい。
（A）分散台帳によるデータ検証されるか
（B）セキュアな格納先か
（C）ゲートウェイ認証があるか
（D）どこから発生したかの来歴メタデータがあるか
（E）デバイス署名による所有者情報が含まれるか
（Ｆ）データ分布を３シグマ・ルールでノイズ除去しているか
（Ｇ）ナイキスト基準による最適なポーリング頻度を上回っているか
（Ｈ）真正性指紋(authenticity fingerprint)が一致しているか
（Ｉ）ビザンチン・フォールトトレラント性があるか
（Ｊ）衛星データ等の復号結果（例：パリティチェック結果）は正しいか

＜バッチ処理的な動作評価手法の例＞
　また、データDD部940は、通信部９０４を介して入出力されるデータに対して、上述のようなリアルタイムに近い形で評価を行う手法のほか、バッチ処理的に評価を行うことも可能である。例えば、データDD部940は、後述する統制部９２０のログ格納部１２５等により評価結果ログDBに記憶された統制検証用ログ（データDD部940によるリアルタイムに近い評価結果の履歴を含んでもよい。）に基づいて、バッチ処理的に評価を行ってもよい。評価手法としては、データ流通の基準・ガイドライン・個人情報保護法等の法令などの統制ルールに適応しているか否かをデータDD部940がスコアリングしてもよい。

＜設計としての評価手法の例＞
　上述のように、リアルタイムないしバッチで行われる、データ入出力の動作としての評価に限られず、データDD部940は、設計として評価を行ってもよい。例えば、データ流通基盤のデータパイプライン上の、アセット端末４００やＡＳＰシステム６００やユーザ端末１００等が、どの国にあるか、誰がどのように管理しているか、部外者の立ち入りを禁止できる設計になっているかどうかを、物理統制等の統制ルールの観点で、データDD部940は、評価してもよい。具体的には、データDD部940は、物理統制がなされていることをセンシングしたデータの履歴（例：入退室カードや自動ロック扉等による入退室履歴、監視カメラの動作状況、セキュリティガードマンの出勤履歴）に基づいて、物理統制ルールに適合しているかをスコアリングしてもよい。

＜外部評価受け入れ機能の例＞
　なお、これに限られず、データDD部940は、通信部９０４を介して外部機器等から評価を受け入れる評価モジュールとして機能してもよい。例えば、データDD部940は、通信部９０４を介して監査法人等が所有する外部機器等からアクセスを受けると、評価結果ログDB９３２の評価検証ログを監査法人等のユーザに提示して、外部からの評価（審査または監査と言い換えてもよい。）を受け入れる。具体的には、データDD部940は、上述のようなデータの価値評価の手法が、データ流通の基準・ガイドライン・個人情報保護法等の法令などの統制ルールに適応しているか否か、通信部９０４を介した評価を受け入れる。例えば、監査法人等が、データDD部940の内部処理方法を検証できるよう、評価値スコアリングプログラムを提示できるようにデータDD部940を構成してもよい。また、データ提示装置４００がアップロードしたデータ（機微情報が含まれていないデータやオントロジー化データ等）とアップロードする前の元データ（機微情報が含まれているデータやオントロジー化前のデータ等）とを比較可能に提示することができるようにデータDD部940を構成してもよい。このほか、データDD部940は、以下のような項目を自動チェックする機能を有しており、通信部２０４を介した評価（証券取引法や国際会計ガイドラインに沿っているかの審査または監査と言い換えてもよい。）を受け入れてもよい。
（１）決済の際に、データ提供元からデータ提供先で（ＢｔｏＢで）パイプラインがつながっているかをデューデリジェンスする
（２）複数の企業間取引で正しく相殺が実行されているか
（３）売り上げの水増し（架空取引）のチェック（グループ会社が別会社を介してデータを流している等）
（４）不正情報取引（インサイダー情報）の監視
（５）循環取引の監視

＜国際標準基準による評価例＞
　データDD部940は、ISO25012に基づくデータ評価基準により、評価・格付けを行ってもよい。例えば、データDD部940は、アサーション項目として、正確性、網羅性、正当性、機密性、保全性、相互運用性、有用性、法令適合性のうち、少なくとも一つについて評価を行ってもよい。その際、データDD部940は、各アサーション項目について、表２に示すように、測定量要素A、全体量Bとして、A／Bなどの測定関数によって、品質を数値化することが可能である（ISO25012参照）。そのため、データDD部940は、この品質の数値を評価値としてもよい。あるいは、データDD部９４０は、各アサーション項目ごとに所定の閾値を設定しておき、これら品質の数値が閾値の基準を満たしているか否かで、品質の良否を判定してもよい。

　また、制御部９０２のうち統制部９２０は、設定される統制に対応する、統制ライブラリ９３０に記憶されたコードの実行および／または設定を行うことにより、当該統制を実現する。設定される統制は、データ提供装置６００やＡＳＰシステム６００やユーザ端末１００が設置されている国・地域や、データ提供装置６００やＡＳＰシステム６００やユーザ端末１００のユーザや法人の国籍等により、その国や地域で遵守すべき法令などの統制ルールに基づいて自動的に設定されてもよく、データ提供装置６００やＡＳＰシステム６００やユーザ端末１００や統制システム９００のユーザ等により通信部９０４や入出力部９０８等を介して手動で設定されてもよい。図１５に示すように、統制部９２０は、設定される統制に対応する、統制ライブラリ９３０に記憶されたコードの実行および／または設定の構成やデバッグ・自動検証、実行等を行う構成実行部９２１と、データの編集や加工等を行う編集加工部９２２と、データの分析や学習等を行う分析学習部９２３と、ナレッジグラフ等の分析結果や学習結果に基づいて派生データを生成する派生データ生成部９２４と、各種の履歴を統制検証用ログとして評価結果ログDB９３２に格納するログ格納部１２５を備える。

　統制部９２０は、設定される統制に対応する、コードの実行および／または設定の組み合わせを統制ライブラリ９３０から自動的に構成して実行することにより、当該統制を実現し得る。統制部９２０による自動構成の具体的手法については後述する。また、統制を実現するための具体的な制御例として、統制部１０２は、
１．インターフェイス（API９０５，１０７等）の組み合わせ（すなわち、どのようなアプリケーション９０１からデータ入力を受け入れ、どのようなマイクロサービス９０３へ出力するか等）を選択する、
２．入力および／または出力すべきデータを選択する（すなわち、アプリケーション９０１から、どのようなデータの入力を受け入れ、マイクロサービス９０３へどのようなデータを出力するか）、
３．入力されるデータを編集または加工する（例えば、入力されたデータに個人情報が含まれる場合、そのデータから個人情報を削除または加工するなどして、個人情報保護法の個人情報から仮名加工情報といえるレベルに編集・加工する等）、
４．入力されるデータから派生データを生成して出力されるよう制御する（例えば、入力されたデータに個人情報が含まれる場合、その元データの統計情報を反映したナレッジグラフ等から派生データを生成することにより、個人情報保護法の個人情報から匿名加工情報といえるレベルに変換する等）、
５．評価結果または価値付け結果の高いデータが入力および／または出力されるよう制御する（例えば、データDD部940によるスコアリングに基づいて、所定の閾値以上のスコアをもつデータが入出力されるように制御する等）、
６．評価結果または価値付け結果の低いデータが入力および／または出力されないように制御する（例えば、データDD部940によるスコアリングに基づいて、所定の閾値未満のスコアをもつデータが入出力されないように制御する等）、
７．データが統制ルール（例：ESG（Environment、 Social、 Governance）ルール、データ欠損がないかのIT統制ルール、セキュリティガイドライン、リスク回避ルール）に適合しているかを検証する、
８．物理統制がなされていることをセンシングしたデータを検証する（例えば、入退室カードや自動ロック扉等による入退室履歴、監視カメラの動作状況の履歴、セキュリティガードマンの出勤履歴による検証）、
のうち、少なくとも一つを行うことにより、統制を実現してもよい。

　そして、統制部９２０のログ格納部１２５は、これらの履歴を統制検証ログとして評価結果ログDB９３２に格納してもよい。すなわち、統制部９２０のログ格納部１２５は、
１．インターフェイスの選択履歴、
２．データの選択履歴、
３．入力されるデータが編集または加工されたことの履歴、
４．入力されるデータから派生データを生成して出力された履歴、
５．評価結果または価値付け結果の高いデータが入力および／または出力された履歴、
６．評価結果または価値付け結果の低いデータが入力および／または出力されなかった履歴、
７．データが統制ルールに適合しているかの検証結果の履歴、
８．物理統制がなされていることをセンシングした前記データの検証履歴、
のうち、少なくとも一つを統制検証用ログとして記憶部９０６の評価結果ログDB９３２に格納してもよい。

＜派生データ生成の具体例＞
　ここで、統制部９２０の派生データ生成部９２４は、入力されるデータから派生データに変換する。一例として、派生データ生成部９２４は、入力されるデータを反映するナレッジグラフに基づいて、派生データを生成する。例えば、統制部９２０の分析学習部９２３が、入力されるデータを分析・学習することにより、ノードに各種の項目や概念とし、分散・共分散の共起性などの統計データをエッジとした、ナレッジグラフを生成して、ナレッジグラフＤＢ１３１に格納する。そして、統計部１２０の派生データ生成部９２４が、入力されるデータの統計情報を反映したナレッジグラフをナレッジグラフＤＢ１３１から読み出し、当該ナレッジグラフに乱数群を与えて、分散共分散などの統計を反映するように整形することにより、派生データを生成させ、出力されるよう制御してもよい。このように、派生データ生成部９２４は、公知の派生データ生成手法を用いて、入力されるデータから、出力される派生データを生成することができ、例えば、入力されるデータが個人情報保護法の個人情報に該当する場合に、匿名加工情報といえるレベルに加工した派生データを生成・出力することで、個人情報保護法の統制ルールを遵守させることができる。ここで、公知の派生データ生成手法として以下の手法を用いてもよい。なお、派生データ生成処理は、アセット端末４００等において行われてもよい。
参考文献：
１．「統計値を用いたプライバシ保護擬似データ生成手法」
https://ipsj.ixsq.nii.ac.jp/ej/index.php?active_action=repository_view_main_item_detail&page_id=13&block_id=8&item_id=187369&item_no=1

２．「AI・機械学習分野の難関国際会議 NeurIPS の匿名化技術コンペティションで優勝
～パーソナルデータを安全かつ使いやすく匿名化する新たな手法の実現へ～」
https://group.ntt/jp/newsrelease/2021/03/02/210302b.html

３．「Scalable Structure Learning, Inference, and Analysis with Probabilistic Programs」Saad, Feras Ahmad Khaled
https://dspace.mit.edu/handle/1721.1/147226

＜自動構成の具体例＞
　ここで、本実施形態における統制部９２０の具体的な制御例を、図１６を用いて説明する。図１６は、本実施形態の統制システム９００の統制部９２０の機能を模式的に示す図である。統制システム９００は、上述のように、アセット端末４００やＡＳＰシステム６００およびユーザ端末１００とネットワーク３００を介して接続されている。

　統制システム９００は、ユーザＵ１による統制を実現するプログラムコードの構成（コード開発や設定）を支援する。プログラムは、アセット端末４００やＡＳＰシステム６００等により提供される各種のサービスを用いて実行されてもよく、統制システム９００の内部で実行されるプログラム（OS（operating system）や、データ編集加工プログラム等）であってもよい。

　ユーザＵ１は、ユーザ端末１００を操作して、アセット端末４００やＡＳＰシステム６００や統制システム９００等における、利用したいプログラムについて、遵守したい統制に関する情報（個人情報保護法などの統制ルール）の設定入力を行う。統制システム９００は、プログラムの実行に利用されるサービスの複数の候補からユーザＵ１の利用対象のサービスを選択する。

　図１６に示すように、統制システム９００は、統制ライブラリ９３０および統制部９２０を有する。統制ライブラリ９３０は、統制部９２０により取得された統制ルール７およびプログラム８を記憶する。なお、ＡＳＰシステム６００のプログラムを利用する場合等は、統制ライブラリ９３０は、そのプログラムを記憶する必要はなく、そのプログラムを用いるための機能拡張用等の一部のコードや、そのプログラムに対する設定情報のみであってもよい。

　統制ルール７は、プログラム８の実行に伴うユーザＵ１のポリシー（法令やガイドラインの遵守条件や、サービスの利用方針など）に応じた制約を示す情報である。プログラム８は、アセット端末４００やユーザ端末１００の設定やサーバ間のネットワーク３００経由での処理要求などＩＴ統制ルール等を意識せずに作成されたものである可能性がある。

　統制ルール７が示す制約としては、例えば、評価結果などのスコアや性能の下限や、サービスの利用に伴うコストの上限などが考えられる。コストとしては、例えば、サービスの利用のための費用や、サービスの処理に所要される演算リソース量（プロセッサリソース量やメモリリソース量）や、処理に伴うＣＯ２排出量などが考えられる。また、性能としては、サービスのレスポンス時間（あるいは、レスポンス時間の速さを示す指標値）や稼働率（あるいは、サービスに対する更新パッチのリリース頻度などのサービスの信用度などの評価結果を示す指標）などが考えられる。

　また、統制ライブラリ９３０は、ルールテーブル９を予め記憶する。ルールテーブル９は、プログラム８の中に出現し得るコード（命令の集合）のうち、特定のサービスを利用可能な処理を示すコードのパターン（コードパターン）と、利用可能なサービスの候補（利用候補）との対応関係を示す情報である。ルールテーブル９は、ルール情報と言われてもよい。ルールテーブル９には、各サービスに対応する所定のパラメータｐの値も設定されている。ここで、パラメータｐは、該当のサービスを選択した場合のコストまたは性能などを表す指標である。パラメータｐは、統制ルール７に対する入力である。

　例えば、ルールテーブル９は、コードパターンＰ１と利用候補のサービスＡ１とパラメータｐ＝ａ１というレコードを含む。このレコードは、プログラム内のコードパターンＰ１に対してサービスＡ１を利用可能であり、サービスＡ１を利用した場合のパラメータｐの値がａ１であることを示す。

　また、ルールテーブル９は、コードパターンＰ１と利用候補のサービスＡ２とパラメータｐ＝ａ２というレコードを含む。このレコードは、プログラム内のコードパターンＰ１に対してサービスＡ２を利用可能であり、サービスＡ２を利用した場合のパラメータｐの値がａ２であることを示す。

　ルールテーブル９には、他のコードパターンについても同様に利用候補のサービスおよびパラメータｐの値が登録される。

　ここで、アセット端末４００やＡＳＰシステム６００は、例えば、クラウドサービスを提供するサーバコンピュータであってもよく、その場合、アセット端末４００はデータクラウドに対応し、ＡＳＰシステム６００はＳａａＳクラウドに対応する。

　アセット端末４００やＡＳＰシステム６００は、ネットワーク３００経由で受信したデータ送信要求や処理要求に応じて、予め設定されたプログラムや設定情報などを用いて処理を実行する。アセット端末４００やＡＳＰシステム６００が実行可能な処理としては、養親要求に応じてデータを送信するもの、ネットワーク３００を介して受信したデータを処理するもの、ネットワーク３００を介して受信した要求に応じて関数を実行するもの、ネットワーク３００を介して受信したデータを保存するものなどが挙げられる。

　統制部９２０は、統制ライブラリ９３０から、統制ルール７に対応する、コード８ａや設定８ｂを含むプログラム８を取得する。なお、繰り返しになるが、ＳａａＳプログラムを使用する場合は、統制部９２０は、そのプログラムに対して用いる、統制ルール７に対応するコード８ａや設定８ｂの指定情報を、取得する。

　この際、統制部９２０は、プログラム８を実行する際に、プログラム８に含まれるコードパターンに基づいて、サービスの複数の候補から、統制ルール７を満たすサービスの組を特定する。

　例えば、統制部９２０は、プログラム８の中から、パターンマッチングにより、コードパターンＰ１に該当するコード８ａを検出する。この場合、プログラム８はコードパターンＰ１を含むと言える。すると、統制部９２０は、ルールテーブル９に基づいて、コード８ａに対応する利用候補のサービスとして、サービスＡ１，Ａ２を特定する。

　また、統制部９２０は、プログラム８の中から、パターンマッチングにより、ルールテーブル９に登録されたコードパターンＰ２に該当する設定用コード８ｂを検出する。この場合、プログラム８はコードパターンＰ２を含むと言える。すると、統制部９２０は、ルールテーブル９に基づいて、コード８ｂに対応する利用候補のサービスとして、サービスＢ１，Ｂ２を特定する。

　なお、あるコードパターンに該当する１つのコードに対して選択されるサービスは、１つである。上記の例では、コード８ａに対してサービスＡ１，Ａ２の何れか一方が選択される。また、コード８ｂに対してサービスＢ１，Ｂ２の何れか一方が選択される。

　このように、統制部９２０は、プログラム８に含まれる各コードパターンを検出し、サービスの複数の候補を特定する。そして、統制部９２０は、各候補に対するパラメータｐをルールテーブル９から取得し、統制ルール７を満たすサービスの組を特定する。一例として、選択対象のサービスの候補が、サービスＡ１，Ａ２，Ｂ１，Ｂ２であり、ＥＳＧに関する統制ルール７としてＣＯ２コストの総和の上限Ｚが与えられている場合を考える。また、パラメータｐは、サービスの候補のＣＯ２コストの値を示すものとする。

　この場合、選択可能なサービスの組は、サービスＡ１，Ｂ１の組、サービスＡ１，Ｂ２の組、サービスＡ２，Ｂ１の組、および、サービスＡ２，Ｂ２の組の４通りである。サービスＡ１，Ｂ１の組を選択した場合のコストの総和は、ａ１＋ｂ１である。サービスＡ１，Ｂ２の組を選択した場合のコストの総和は、ａ１＋ｂ２である。サービスＡ２，Ｂ１の組を選択した場合のコストの総和は、ａ２＋ｂ１である。サービスＡ２，Ｂ２の組を選択した場合のコストの総和は、ａ２＋ｂ２である。

　このうち、ＣＯ２コストの上限Ｚを超過しない組は、サービスＡ１，Ｂ１であるとする。この場合、統制部９２０は、ＥＳＧの統制ルール７を満たすサービスの組として、サービスＡ１，Ｂ１の組を特定する。なお、ＣＯ２コスト上限Ｚを超過しない組が複数ある場合、統制部９２０は、ＣＯ２コストの総和が最小のサービスの組を特定することが考えられる。

　統制部９２０は、統制ルール７を満たすサービスの組として、サービスＡ１，Ｂ１の組を特定すると、サービスＡ１，Ｂ１の組によりプログラム８を実行する。例えば、統制部９２０は、プログラム８のコード８ａの箇所を実行する際に、コード８ａをサービスＡ１を用いるコードに変換して実行してもよい。同様に、統制部９２０は、プログラム８のコード８ｂの箇所を実行する際に、コード８ｂをサービスＢ１を用いるコードに変換して実行してもよい。

　あるいは、統制部９２０は、プログラム８を、複数のサービスを組合せた分散処理ソフトウェア用のプログラム群に変換してもよい。例えば、ルールテーブル９には、コードパターンＰ１に対応付けて、プログラム変換用の第１のテンプレートが予め登録されていてもよい。同様に、ルールテーブル９には、コードパターンＰ２に対応付けて、プログラム変換用の第２のテンプレートが予め登録されていてもよい。「テンプレート」は、サービスの処理を規定する所定プログラムの書式（雛形）を示す。

　例えば、第１のテンプレートは、処理要求に応じてＡＳＰシステム６００が特定の処理を実行するよう規定するプログラムの書式（雛形）を示す。第１のテンプレートは、例えば、ＡＳＰシステム６００に実行させるプログラムの書式や、ＡＳＰシステム６００に設定情報を送信するためのプログラムの書式などである。また、例えば、第２のテンプレートは、ＡＳＰシステム６００にネットワーク３００経由で処理要求を送信するプログラムの書式（雛形）を示す。

　より具体的な例では、第１のテンプレートが関数プログラムの書式を示し、第２のテンプレートが関数を呼び出すプログラムの書式を示す。また、例えば、第１のテンプレートがデータ保存場所を設定するプログラムの書式を示し、第２のテンプレートがデータの書き込みや読み出しを要求するプログラムの書式を示す。

　この場合、統制部９２０は、コード８ａから抽出した値を第１のテンプレートの引数に代入することで、サービスＡ１を利用する第１の変換後プログラムを生成してもよい。例えば、第１の変換後プログラムは、コード８ａに対応する処理をＡＳＰシステム６００がサービスＡ１を利用して実行するよう規定する。第１の変換後プログラムは、ＡＳＰシステム６００に適用される。例えば、第１の変換後プログラムがＡＳＰシステム６００に送信され、ＡＳＰシステム６００によって第１の変換後プログラムが実行される。また、例えば、第１の変換後プログラムが規定する手順に従って所定の設定情報がＡＳＰシステム６００に送信されてもよい。

　更に、統制部９２０は、コード８ｂから抽出した値を第２のテンプレートの引数に代入することで、サービスＢ１を利用する第２の変換後プログラムを生成してもよい。例えば、第２の変換後プログラムは、コード８ｂに対応する処理をＡＳＰシステム６００―２がサービスＢ１を利用して実行するよう規定する。第２の変換後プログラムは、例えば、ＡＳＰシステム６００―１とは異なるＡＳＰシステム６００―２に適用される。例えば、第２の変換後プログラムがＡＳＰシステム６００―２に送信され、ＡＳＰシステム６００―２によって第２の変換後プログラムが実行される。

　なお、ＡＳＰシステム６００―２は、他のサービスを提供してもよい。その場合、第２のテンプレートは、ＡＳＰシステム６００―２が特定の処理を実行するよう規定するプログラムの書式を兼ねている。これにより、統制部９２０は、ＡＳＰシステム６００―１，ＡＳＰシステム６００―２上の複数のサービス（例えば、サービスＡ１，Ｂ１）を連携させて、プログラム８に記述された処理を実行することもできる。

　統制システム９００によれば、統制ルール７とプログラム８とが取得され、取得されたプログラム８を実行する際に、プログラム８に含まれるコードパターンに基づいて、サービスの複数の候補から統制ルール７を満たすサービスの組が特定される。そして、特定したサービスの組によりプログラム８が実行される。

　これにより、ユーザＵ１により設定された統制ルールに適合した、利用対象のサービスを適切に特定できる。例えば、ＥＳＧ統制ルール７として、サービス利用に伴うＣＯ２消費量などのコストの和の上限が用いられる。この場合、統制システム９００は、ユーザＵ１が想定するＣＯ２コストを上回らないようにサービスを組合せて、ユーザ端末１００のユーザＵ１に提供できる。

　また、統制ルール７として、セキュリティ評価制度（ISMAP：Information system Security Management and Assessment Program）の評価値を用いてもよい。例えば、複数のＡＳＰシステム６００やデータクラウドとしてのアセット端末４００が提供する複数のクラウドサービスについて、ＩＳＭＡＰに基づき登録されているセキュリティ評価値の下限値を用いることもできる。セキュリティ評価値の下限値より大きなクラウドサービスを提供するＡＳＰシステム６００やデータクラウドとしてのアセット端末４００を利用して、データに対してクラウドサービスを実行してユーザ端末１００に提供することで、ＩＳＭＡＰの統制ルール７を満たすことができる。

　また、統制ルール７として、稼働率の平均の下限値を用いてもよい。稼働率の平均の下限値を上げることで（あるいは、稼働率の平均がより大きいサービスの組を選択することで）、プログラム８により実現される機能の信頼性を向上することもできる。

　更に、統制ルール７は、ＣＯ２コストおよび性能値などの複数の種類のパラメータそれぞれに対する条件を含んでもよい。そして、統制部９２０は、複数の種類のパラメータそれぞれに対する条件を全て満たすサービスの組を選択してもよい。また、統制部９２０は、各種のパラメータに対する優先度の入力を受け付けてもよい。そして、統制部９２０は、統制ルール７を満たすサービスの組が複数ある場合に、優先度が高い種類のパラメータほど条件に対する評価が優位である組を選択してもよい。例えば、統制ルール７が、ＣＯ２コストおよび性能値のそれぞれに対する条件を含み、かつ、コストの優先度が性能値の優先度よりも高い場合を考える。この場合、統制部９２０は、コストおよび性能値のそれぞれに対する条件を全て満たすサービスの組が複数であると、当該複数の組のうち、コストが最小の組を利用対象のサービスの組として特定することが考えられる。

　なお、各種のサービスの処理の実行主体は、統制システム９００でもよい。すなわち、統制システム９００は、アセット端末４００やＡＳＰシステム６００にサービスの処理を依頼せずに、当該サービスの処理を自身で実行してもよい。あるいは、各種のサービスの処理の実行主体は、統制システム９００およびアセット端末４００やＡＳＰシステム６００（他の情報処理装置）を含む情報処理システムであってもよい。この場合、統制システム９００の機能、各種のサービスおよびプログラム８（あるいは変換後プログラム）の実行主体は、当該情報処理システムであるとも言える。

　以上が、本実施形態の統制システム９００の構成の一例である。なお、統制システム９００が有する各機能部については、複数の機能部を一つの機能部にまとめてもよいし、一つの機能部を機能毎に複数の機能部に分けてもよい。

＜統制システム９００の処理例＞
　図１７は、本実施形態の統制システム９００の処理の一例を説明するフローチャートである。

　図１７に示すように、まず、統制システム９００の統制部９２０は、構成実行部９２１の処理により、ユーザ端末１００のユーザの入出力部２０８を介した操作を受け付け、ユーザにより統制ルールや、利用したいデータ種やアプリケーション種別が設定されるよう制御する（ＳＡ１）。ここで、具体例として、ユーザは、ＩＳＭＡＰおよびＥＳＧの統制ルールを指定し、クラウドデータから他社の配送予定データを用いて、共同配送のためのルーティングアプリケーションをＳａａＳソフトウェアから選びたいと指定したとする。

　つづいて、統制部９２０は、構成実行部９２１の処理により、指定された統制ルール、データ種、アプリケーション種別の指定を満たす、データを提供するアセット端末４００と、アプリケーションを提供するＡＳＰシステム６００と、そのコードおよび／または設定を、自動的に構成する（ＳＡ２）。具体例として、構成実行部９２１は、ＩＳＭＡＰの統制ルールに従って、ＩＳＭＡＰで登録されている評価値の高いデータクラウド（複数のアセット端末４００）とＳａａＳクラウド（複数のＡＳＰシステム６００）を優先的に選択しつつ、指定された共同配送ルーティングのアプリケーションを提供するＡＳＰシステム６００と、そのための他社配送予定データを提供するアセット端末４００を選択する。このとき、ＥＳＧの統制ルールに従い、CO２排出量削減プログラムのある共同配送ルーティングアプリを優先的に選択する。なお、候補が複数ある場合は、統制ルールにより適合するもの、この例の場合、ＣＯ２コストが最も低いものや、ＩＳＭＡＰの評価値が最も高いものを優先的に選択してもよい。

　そして、統制部９２０は、他の統制ルールの指定を受け付ける（ＳＡ３）。例えば、上記のステップで、多数のアセット端末４００の候補や、多数のＡＳＰシステム６００のアプリケーション候補が提示された場合（ＳＡ３，ＹＥＳ）、絞り込みのために、ステップSA1に処理を戻し、ユーザ端末１００のユーザから更なる統制ルールの指定を受け付ける。

　他の統制の指定がない場合（ＳＡ３，ＮＯ）、統制部９２０は、構成実行部９２１の処理により、上述のステップで構成した、アセット端末４００から出力されるデータが、上述のステップで構成したコードおよび／または設定を指定して、ＡＳＰシステム６００のアプリケーションに入力されるように、データ入出力を仲介する（ＳＡ４）。具体例としては、統制システム９００は、受信部１００によりAPI９０５を介して、配送トラックの運転者が所有するスマートフォン（アセット端末４００の例）から位置情報や伝票情報等を受信し、データDD部940の処理により、そのデータの真正性（位置情報を取得するために衛星データを復号した際のパリティチェック結果が正しいこと等、改ざんされていないか）等をチェックして、送信部９１１の処理により、API９０７を介して、共同配送アプリケーション（マイクロサービス９０３の例）を提供するＡＳＰシステム６００へデータを送信する。

　なお、このデータ入出力の仲介の際、データDD部940の処理により、例えば、個人情報が含まれると評価した場合は、編集加工部９２２により機微データを削除するなどしてデータ加工してからＡＳＰシステム６００へ出力してもよく、あるいは、派生データ生成部９２４の処理により、位置情報の統計情報を反映したナレッジグラフに基づき、派生データを生成して、この派生データをＡＳＰシステム６００へ出力してもよい。

　そして、統制部９２０は、ログ格納部１２３の処理により、データの評価値や処理内容等のログを、評価結果ログDB９３２に格納する（ＳＡ５）。例えば、入出力されたデータの品質を、メタデータ（所有権情報や、スマートフォン等の機器情報など）を評価結果ログDB９３２に格納してもよく、上述のデータ加工プロセス内容や、派生データ処理内容、また、ＳａａＳアプリケーションの運用結果（共同配送により削減されたＣＯ２排出量など）を、ログとして評価結果ログDB９３２に格納してもよい。

　そして、データDD部940は、評価結果ログ１３２に格納されたログに基づいて、統制検証の評価を行う（ＳＡ６）。この統制検証は、バッチ処理として行われる評価であり、上述のステップＳＡ４で行われるリアルタイムのデータ評価とは異なる。また、この統制検証は、データDD部940が、統制ルールに従って自動的に評価を行ってもよく、他の端末から監査人等による手動による評価が行われるように、評価結果ログ１３２に格納されたログが閲覧可能に提示して、外部端末からの評価を受け付けてもよい。

　そして、統制部９２０は、データDD部940による統制検証結果に基づいて、統制適合しているか否かを判定し（ＳＡ７）、統制に適合していなければ（ＳＡ７，ＮＯ）、処理をステップＳＡ２に戻し、コードや設定等を再構成する（ＳＡ２）。したがって、このステップＳＡ７に到達するまでの１サイクル目の手順は、本実行前に行われるテスト運用やデバッグ処理と捉えることもできる。

　一方、統制部９２０は、データDD部940による統制検証結果が統制に適合している場合（ＳＡ７，YES）、終了するか否かをユーザ等に入力させ、終了しない場合（ＳＡ８，ＮＯ）、処理をＳＡ４に戻し、実行を開始する。したがって、このステップＳＡ８に到達した１サイクル目の手順は、テスト実行を終了して、本実行を行うか否かをユーザに問い合わせると捉えることができる。

　一方、統制部９２０は、処理を終了すると判定した場合（ＳＡ８，ＹＥＳ）、以上の処理を終了する。以上が、本実施形態の統制システム９００の処理の一例である。

［実施例１］
　以上のように説明した本実施形態は、さまざまな実施例として利用してもよいものである。例えば、日本において働き方改革関連法案が２０２４年に物流業界で施行されることにより、労働時間に制限がかかるため、限られた労働時間で、これまでの業務を行う必要がある。すなわち、運送効率の最適化、例えばドライバーの労働時間当たりの生産性（売上－経費）の向上が求められている。

　そこで、物流業者Ａが、自ユーザとして、これまで帰りの運行が空荷であることが多かったところ（すなわち、帰り便の実車率が低かったところ）、同業他社との協業により、帰り便マッチングを行い、帰り便の実車率を上げることができれば、生産性の向上が図られる。

　そのため、例えば、本実施形態において、データ提供元の業種“Ｂ”およびデータ提供先の業種“toＢ”をともに「運送業」に指定し、用途”object”を「実車率」「生産性」「求荷求車マッチング」などを指定すれば、協業先候補の他ユーザを見つけることができる。

［実施例２］
　他の実施例として、ある会社のサービスが複数会社をまたがって、サプライチェーンとして提供されている場合に、サプライチェーンの全体のサービスの品質（例えば、ロバスト向上やレジリエンス向上）につなげることができる。例えば、当該サプライチェーンにかかわる企業群をデータ提供元“Ｂ”で指定し、データの種類”data”として、ロバストやレジリエンスに関する部品数値を指定するか、用途”object”を「ロバスト」や「レジリエンス」で指定すれば、連携先候補とデータ連携を行うことで、サプライチェーン全体の品質向上につなげることができる。

［実施例３］
　別の実施例３として、ESG関連のスコープ３（バリューチェーン全体から排出された温室効果ガス）に適用することができる。例えば、上述の実施例２ように、サプライチェーン全体でデータ連携を図ることで、サプライチェーン源流のCO2排出量を足し合わせていき、サプライチェーン全体でＣＯ２排出量を評価することができる。このように、ボトムアップ型でホワイトボックスで足し合わせていく評価手法を用いることもでき、このほか、コスト・価格・温室効果などKPIについて向上させることもできる。

［実施例４］
　他の実施例として、複数のクラウドサービス等にまたがってサービスを提供する場合等において、ＩＳＭＡＰなどの情報セキュリティサービス基準に適合させる評価を行うことができる。例えば、データ連携先として、委託先（クラウドサービス提供会社）のレポートセットからセキュリティ対策を評価して、利用者（自ユーザ）に提供することで、サービス提供会社（委託先）の実際のセキュリティ情報を、委託先企業内で収集して、評価することができる。このほか、リスクコントロールの情報を自動的に識別して取得することもできる。

　以上が本実施形態の説明である。

　本実施形態では、データ種別と用途とを少なくとも対応付けて格納したユースケース集ファイルを備え、ユースケース集ファイルに基づいて、ユーザに、用途とともに当該用途に対応するデータ種別を提示する。

　本実施形態によれば、用途とともに当該用途に対応するデータ種別をユースケースとして提示するので、データ利活用の知識や経験が乏しいユーザであっても、データ利活用の新たな用途やユースケースの提案を受けることができ、データ利活用を促進することが可能となる。

　また、本実施形態では、特許文献情報を記憶する特許文献ファイルを更に備え、特許文献情報の中から、少なくともデータ種別と用途に関する記述を抽出し、対応付けてユースケース集ファイルに格納してもよい。

　これにより、特許文献からユースケースが自動収集されるので、データ利活用の実績のないユースケースであっても、具体的なユースケースとしてユーザに提案することで、データ利活用を促進することができる。

　また、本実施形態では、ユースケース集ファイルに基づいて、データ種別と用途の同じ組み合わせが、多くの特許文献において記述されているほど、および／または、同じデータ種別に対して、複数の特許文献にわたって多くの用途があるほど、当該データ種別の価値が高いとの評価付けを行ってもよい。

　これにより、ユーザ利活用の実績がなくても、特許文献におけるユースケースや用途の数に応じて、有用度を計ることができ、ユーザに有用性のあるユースケースを提示することができる。

　また、本実施形態では、データ種別と用途の組み合わせ、および／または、データないしは他ユーザと用途の組み合わせを、（１）採用したユーザの数が多いほど、（２）ユーザが採用した期間が長いほど、（３）ユーザが採用するためにかけた費用が大きいほど、（４）採用したユーザからの評価が高いほど、（５）採用したユーザからの改善要望が多いものほど、（６）データの網羅性が高いほど、（７）データの正確性が高いほど、（８）データの整合性が高いほど、（９）データの適時性が高いほど、（１０）データ加工の品質が高いほど、（１１）元データから派生データの再現性が高いほど、および、（１２）データ連携による効果が高いほど、のうち、少なくとも一つに基づいて、価値が高いとの評価付けを行うので、ユーザの利用実績やフィードバック等を受けて有用度を求めることができ、実用的なユースケースをユーザに提示することができる。

　また、本実施形態では、通信部を介して取得される情報から、データの取得可能性、および／または、取得可能なデータ価値を推定してもよい。

　これにより、データ提供候補者をアセットマイニングにより探索することができるので、データ提供の促進を図り、もってデータ利活用を促進することができる。

　また、本実施形態では、（１）前記通信部を介して取得された顧客情報、取引先情報、物流情報、会計情報、ビジネスモデル情報、人的リソース情報、および、ノウハウ情報のうち少なくとも一つに基づいて、当該顧客、当該取引先、当該物流、当該会計、当該ビジネスモデル、当該人的リソース、および、当該ノウハウのうち少なくとも一つから取得できる、データの取得可能性、および／または、取得可能なデータ価値を推定すること、
（２）前記通信部を介して取得された顧客情報、取引先情報、物流情報、会計情報、ビジネスモデル情報、人的リソース情報、および、ノウハウ情報のうち少なくとも一つに基づいて、購入、貸与または利用可能化される機器またはソフトウェアを推定して、当該機器または当該ソフトウェアに基づいて、データの取得可能性、および／または、取得可能なデータ価値を推定すること、および、
（３）前記通信部を介して取得された学習済みモデル情報またはオントロジー情報に基づいて、学習された元データまたはオントロジー化された元データを予測して、データの取得可能性、および／または、取得可能なデータ価値を推定すること、
のうち少なくとも一つを実行してもよい。

　これにより、（１）データの源となるリソース、（２）デジタル化やデータ化するハードウェアやソフトウェア、および、（３）元データ（生データ）が何らかの加工を受けたもの（加工データなどのオントロジー化データ等）や、データが変化させたもの（学習済みモデル等）から遡及的に元データ（の種別やデータ価値）の推定のうち、少なくとも一つを用いて、データの取得可能性、および／または、取得可能なデータ価値を推定することができ、データ提供の促進を図ることで、もってデータ利活用を図ることができる。

　また、本実施形態では、ユースケース集ファイルに記憶された、データ種別と用途との対応関係に基づいて、分析対象となるデータと当該データに対する分析処理を実行する分析部品との紐付けを規定する分析関係情報を生成し、分析関係情報に基づき、ユーザにより分析対象として指定された所定データに対して、利用可能な分析部品の組合せを特定してもよい。

　これにより、ユースケースに基づいて、具体的なデータと分析部品類の組み合わせを特定してユーザに提案することで、データ利活用のソフトウエア構成やデータ構成に詳しくないユーザであっても具体的なデータ利活用手法を把握することができ、一層、データ利活用を促進することができる。

　また、本実施形態では、データパイプラインに埋め込まれ、通信部を介した評価を受け入れる評価モジュール部を更に備えてもよい。

　これにより、データ提供元からデータ提供先までのデータパイプライン上で、信頼性や有用性などのデータの価値評価を行うことができ、データのデューデリジェンス機能を果たし、安全で安心なデータ流通システムを構築することができるので、一層、データ利活用が図られる。

　また、本実施形態では、データ種別は、データ提供元の業種、および、データの種類を含み、用途は、データ提供先の業種、および、データ提供先の利用目的を含んでもよい。

　これにより、ユーザが取り組みたい業種や、ユーザがデータ提供を受けたい業種、ユーザがデータを利活用することで達成できる目的が具体的に把握することができ、一層、データ利活用を促進することができる。

　また、本実施の形態によれば、データ分析等のデータ利活用を行うアプリケーションに対してデータ提供を行うシステムにて、当該システムの導入時点、運用開始時点からも、分析処理の作成向けに再利用可能な部品の提案が可能となる。これにより、例えば複数業務システムからのデータを分析するための分析アプリケーションの作成や準備の作業高速化を図りことが可能となり、データ分析処理をはじめとするデータ利活用の実施に要するコストを低減できる。

　すなわち、データ分析の実施履歴の多寡に係わらず分析部品の提案を可能とし、ひいては、データ分析用ソフトウェア作成の効率化やコスト低減を図ることが可能となる。

　また、本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のデータ利活用促進システムにおいて、制御部は、前記分析関係情報を生成する処理において、各分析対象データの属性に基づく分析対象データの間における関係性に応じて複数の分析対象データを関係付け、当該複数の分析対象データを分析に際して抽出するデータ突合ロジックを、前記分析部品の１つとして所定アルゴリズムで生成するものである、としてもよい。
　これによれば、様々な業務システム等から得られたデータ類について、適宜な属性に基づきグルーピングし、これを効率的に分析に供することが可能となる。

　また、本実施形態のデータ利活用促進システムにおいて、前記制御部は、前記分析関係情報を生成する処理において、前記データ突合ロジックと、前記分析部品の１つであって前記データ突合ロジックが抽出する分析対象データに対して分析処理を実行するデータ分析ロジックとを、前記データ突合ロジック及び前記データ分析ロジックの各々の取扱いデータに関するメタ情報を比較することで紐付けするものである、としてもよい。

　これによれば、分析部品を構成するデータ突合ロジックとデータ分析ロジックとを、それぞれで取り扱うデータ項目等の適合に基づき精度良く紐付け、効率的な分析部品の提案が可能となる。

　また、本実施形態のデータ利活用促進システムにおいて、前記制御部は、前記分析部品による分析処理の実績情報に基づき、前記分析関係情報を更新する処理を更に実行するものである、としてもよい。

　これによれば、ユーザに提示した分析部品のうち、実際にユーザが選択して利用したものに関して、その有用度を認める情報を管理可能となり、ひいては、その後の分析部品の組合せの特定精度をより適宜なものできる。

　また、本実施形態のデータ利活用促進システムにおいて、前記制御部は、前記分析関係情報を更新するに際し、前記分析処理と、当該分析処理の目的、当該目的に対応した業務、及び、当該業務の対象、の少なくともいずれかの情報とを紐付けるものである、としてもよい。

　これによれば、ユーザに提示した分析部品のうち、実際にユーザが選択して利用したものに関して、その目的、業務、業務の対象、といった具体的状況を踏まえた有用度を認める情報を管理可能となり、ひいては、その後の分析部品の組合せの特定精度を更に適宜なものとできる。

　また、本実施形態のデータ利活用促進システムにおいて、前記制御部は、前記分析部品の組合せを特定する処理において、分析部品による分析処理の実績情報を有している場合、当該実績情報にも基づいて分析部品の組合せを特定するものである、としてもよい。
　これによれば、分析部品の組合せの特定精度をより適宜なものできる。

　また、本実施形態のデータ利活用促進システムにおいて、前記制御部は、前記特定した分析部品の組合せに類似する分析処理を、分析部品による分析処理の実績情報に基づいて特定し、当該類似の分析処理に関する所定事象の発生頻度の実績値に基づき、当該特定した分析部品の組み合わせの有用度を判定する処理を更に実行するものである、としてもよい。

　これによれば、ユーザに提示した分析部品のうち、実際にユーザが選択して利用した事象等、当該分析部品の有用度を認めうる事象の発生頻度に基づき、分析部品の組合せの特定精度を更に適宜なものできる。

　また、本実施形態のデータ利活用促進システムにおいて、前記制御部は、前記特定した分析部品の組合せに関する情報を、前記分析対象として指定された所定データの分析に適切な分析部品の組合せ候補の情報として、所定装置に出力する処理を更に実行するものである、としてもよい。
　これによれば、ユーザに対して、分析対象データの分析に好適な分析部品の情報を提示することが可能となる。

　また、本実施形態のデータ利活用促進方法において、前記情報処理システムが、前記分析関係情報を生成する処理において、各分析対象データの属性に基づく分析対象データの間における関係性に応じて複数の分析対象データを関係付け、当該複数の分析対象データを分析に際して抽出するデータ突合ロジックを、前記分析部品の１つとして所定アルゴリズムで生成する、としてもよい。

　また、本実施形態のデータ利活用促進方法において、前記情報処理システムが、前記分析関係情報を生成する処理において、前記データ突合ロジックと、前記分析部品の１つであって前記データ突合ロジックが抽出する分析対象データに対して分析処理を実行するデータ分析ロジックとを、前記データ突合ロジック及び前記データ分析ロジックの各々の取扱いデータに関するメタ情報を比較することで紐付けする、としてもよい。

　また、本実施形態のデータ利活用促進方法において、前記情報処理システムが、前記分析部品による分析処理の実績情報に基づき、前記分析関係情報を更新する処理を更に実行する、としてもよい。

　また、本実施形態のデータ利活用促進方法において、前記情報処理システムが、前記分析関係情報を更新するに際し、前記分析処理と、当該分析処理の目的、当該目的に対応した業務、及び、当該業務の対象、の少なくともいずれかの情報とを紐付ける、としてもよい。

　また、本実施形態のデータ利活用促進方法において、前記情報処理システムが、前記分析部品の組合せを特定する処理において、分析部品による分析処理の実績情報を有している場合、当該実績情報にも基づいて分析部品の組合せを特定する、としてもよい。

　また、本実施形態のデータ利活用促進方法において、前記情報処理システムが、前
記特定した分析部品の組合せに類似する分析処理を、分析部品による分析処理の実績情報に基づいて特定し、当該類似の分析処理に関する所定事象の発生頻度の実績値に基づき、当該特定した分析部品の組み合わせの有用度を判定する処理を更に実行する、としてもよい。

　また、本実施形態のデータ利活用促進方法において、前記情報処理システムが、前記特定した分析部品の組合せに関する情報を、前記分析対象として指定された所定データの分析に適切な分析部品の組合せ候補の情報として、所定装置に出力する処理を更に実行する、としてもよい。

　本実施形態によれば、ＩｏＴ機器から生成されるデータアセットや、ある企業の顧客リスト、取引先や物流などのネットワーク、人的リソース、ノウハウ、台帳・元帳データなど様々な有形・無形のアセットを発掘し、そのアセットを分析・資産評価し、また、企業間（B to B）のコラボレーションやデジタルトランスフォーメーション（ＤＸ：digital transformation）を促進するために新たなユースケースを自動検出し、連携候補先に提案し、さらにはデータのトラスト評価を提携候補先に提示することができるようになり、産業上の利用可能である。

［他の実施の形態］
　さて、これまで本発明の実施の形態について説明したが、本発明は、上述した実施の形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施の形態にて実施されてよいものである。

　例えば、データ利活用促進システムは、分散型コンピューティングシステムとして、機能を実現する別々の筐体にて実現されるように記載したが、これに限られず、同一筐体で行われてもよいものである。このほか、制御部や記憶部等の各機能は、機能負荷に応じて、あるいは任意の単位で、機能的または物理的に分散・統合して構成することができる。

　また、データ利活用促進システムが、ユーザ端末１００やアセット端末４００等のクライアント端末からの要求に応じて処理を行い、その処理結果を当該クライアント端末に返却する場合を一例として説明したが、データ利活用促進システムは、ユーザ端末１００やアセット端末４００等を含んで、スタンドアローンの形態で処理を行うよう一体として構成されてもよい。

　また、実施の形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

　このほか、上記文献中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。

　また、ユーザ端末１００やデータ利活用基盤サーバ２００やアセット端末４００やAＳPサーバ６００等に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

　例えば、データ利活用基盤サーバ２００の各装置が備える処理機能、特に制御部２０２にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）などのプロセッサおよび当該プロセッサにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアプロセッサとして実現してもよい。尚、プログラムは、後述する、コンピュータに本発明に係る方法を実行させるためのプログラム化された命令を含む、一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じてデータ利活用基盤サーバ２００に機械的に読み取られる（AＳPサーバ６００等から必要に応じてデータ利活用基盤サーバ２００に読み取られてもよい）。すなわち、ＲＯＭまたはＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）などの記憶部１０６などには、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）と協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。

　また、このコンピュータプログラムは、ユーザ端末１００やデータ利活用基盤サーバ２００やアセット端末４００やAＳPサーバ６００や特許文献情報サーバ８００等に対して任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。

　また、本発明に係るプログラムを、コンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢメモリ、ＳＤカード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、および、Ｂｌｕ－ｒａｙ（登録商標）Ｄｉｓｃ等の任意の「可搬用の物理媒体」を含むものとする。

　また、「プログラム」とは、任意の言語や記述方法にて記述されたデータ処理方法であり、ソースコードやバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）に代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施の形態に示した各装置において記録媒体を読み取るための具体的な構成、読み取り手順、あるいは、読み取り後のインストール手順等については、周知の構成や手順を用いることができる。プログラムが、一時的でないコンピュータ読み取り可能な記録媒体に記録されたプログラム製品として本発明を構成してもよい。

　記憶部１０６，２０６，４０６等に格納される各種のデータベース等（特許文献DB３０１、ユースケース集ファイル３０２等）は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、および、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、および、ウェブページ用ファイル等を格納する。

　また、ユーザ端末１００やデータ利活用基盤サーバ２００やアセット端末４００やAＳPサーバ６００や特許文献情報サーバ８００等は、既知のパーソナルコンピュータ、ワークステーション等の情報処理装置として構成してもよく、また、該情報処理装置に任意の周辺装置を接続して構成してもよい。またユーザ端末１００やデータ利活用基盤サーバ２００やアセット端末４００やAＳPサーバ６００や特許文献情報サーバ８００等は、該情報処理装置に本発明の方法を実現させるソフトウェア（プログラム、データ等を含む）を実装することにより実現してもよい。

　なお、本願において、「Aおよび／またはB」との記載を、「AおよびBのうち一方または両方」と読み替えてもよい。

　更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じて、または、機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。

　７　統制ルール
　８　プログラム
　８ａ　コード
　８ｂ　設定（設定用コードを含む。）
　９　ルールテーブル
　Ｕ１　ユーザ
１００　ユーザ端末
２００　データ利活用基盤サーバ
４００　アセット端末
６００　ＡＳＰシステム
８００　特許文献情報サーバ
１０６、２０６，４０６　記憶部
１０２、２０２、４０２　制御部
１０４、２０４、４０４　通信部
１０８、２０８、４０８　入出力部
３００　データ利活用ミドルウェア
３０１　特許文献情報ファイル
３０２　ユースケース集ファイル
３０３　分析実行管理部
３０４　分析対象データＤＢ
３０５　分析結果ＤＢ
３０６　実績情報ＤＢ
３０７　分析関係テーブル
３０８　分析関係情報管理部
３０９　分析提案部
３１０　ユーザ・業務管理部
３１１　クライアント向けＩ／Ｆ提供部
３１２　分析処理実績管理部
３１３　分析部品管理部
３１４　データ管理部
３１５　データ通信部
３１６　ユースケース抽出部
３１７　有用性判定部
３１８　アセット推定部
３１９　評価モジュール部
３２３　分析部品
３３３　分析処理
４０１　分析関係情報
４２１　データ突合ロジック
４２２　データ分析ロジック
４５１　ユースケース
４５０　用途
４５１　データ種別
５０１　分析対象データ紐付けテーブル
５０２　分析部品紐付けテーブル
５０３　分析部品－分析処理紐付けテーブル
５０４　分析処理－分析目的紐付けテーブル
５０５　分析目的－業務紐付けテーブル
５０６　データ分析ロジックのメタ情報
５０７　データ突合ロジックのメタ情報
５０８　データ提供先業種－業務アプリ紐付けテーブル
５０９　データ提供先利用目的－分析目的紐付けテーブル
５００　データ種別－データ紐付けテーブル
９００　統制システム（統制モジュール）
９０１　アプリケーション
９０２　制御部
９０３　マイクロサービス
９０４　通信部
９０５　（データ入力側）ＡＰＩ
９０６　記憶部
９０７　（データ出力側）ＡＰＩ
９０８　入出力部
９１０　受信部
９１１　送信部
９１２　互換操作制御部
９２０　統制部
９２１　構成実行部
９２２　編集加工部
９２３　分析学習部
９２４　派生データ生成部
９３０　統制ライブラリ
９３１　ナレッジグラフ
９３２　評価結果ログDB
９４０　データDD部

Claims

　記憶部と制御部を少なくとも備えたデータ利活用促進システムにおいて、
　前記記憶部は、
　データ種別ないしは業種と用途とを少なくとも対応付けて格納したユースケース集ファイル、および／または、複数の異なるユーザのデータを格納したデータベースを備え、
　前記制御部は、
　前記ユースケース集ファイルに基づいて、用途とともに当該用途に対応するデータ種別を抽出する、および／または、前記データベースに登録された前記複数の異なるユーザの中から、データ連携により用途に適した他のユーザを抽出する抽出部と、
　前記抽出した、用途とともに当該用途に対応するデータ種別、および／または、用途に適した他のユーザを、提示する提示部、
　を備えるデータ利活用促進システム。
　請求項１に記載のデータ利活用促進システムにおいて、
　前記記憶部は、
　特許文献情報および／またはWebデータを記憶する特許文献ファイルを更に備え、
　前記制御部は、
　前記特許文献情報および／または前記Webデータの中から、少なくとも、データ種別と用途、または、業種と用途に関する記述を抽出し、対応付けて前記ユースケース集ファイルに格納するユースケース抽出部、
　を更に備えるデータ利活用促進システム。
　請求項２に記載のデータ利活用促進システムにおいて、
　前記制御部は、
　前記ユースケース集ファイルに基づいて、
　データ種別ないしは業種と用途の同じ組み合わせが、多くの特許文献および／またはＷｅｂデータにおいて記述されているほど、および／または、
　同じデータ種別ないしは業種に対して、複数の特許文献および／またはＷｅｂデータにわたって多くの用途があるほど、
　当該データ種別の価値が高いとの評価付けを行う有用性判定部、
　を更に備えるデータ利活用促進システム。
　請求項１または２に記載のデータ利活用促進システムにおいて、
　前記制御部は、
　前記提示部により提示された、前記データ種別ないしは業種と用途の組み合わせ、および／または、前記データないしは他ユーザと用途の組み合わせを、
（１）採用したユーザの数が多いほど、
（２）ユーザが採用した期間が長いほど、
（３）ユーザが採用するためにかけた費用が大きいほど、
（４）採用したユーザからの評価が高いほど、および、
（５）採用したユーザからの改善要望が多いものほど
（６）データの網羅性が高いほど
（７）データの正確性が高いほど
（８）データの整合性が高いほど
（９）データの適時性が高いほど
（１０）データ加工の品質が高いほど
（１１）元データから派生データの再現性が高いほど
（１２）データ連携による効果が高いほど
のうち、少なくとも一つに基づいて、価値が高いとの評価付けを行う有用性判定部、
　を更に備えるデータ利活用促進システム。
　請求項１または２に記載のデータ利活用促進システムにおいて、
　前記制御部は、
　通信部を介して取得される情報から、データの取得可能性、および／または、取得可能なデータ価値を推定するアセット推定部、
　を更に備えるデータ利活用促進システム。
　請求項５に記載のデータ利活用促進システムにおいて、
　前記アセット推定部は、
（１）前記通信部を介して取得された顧客情報、取引先情報、物流情報、会計情報、ビジネスモデル情報、人的リソース情報、および、ノウハウ情報のうち少なくとも一つに基づいて、当該顧客、当該取引先、当該物流、当該会計、当該ビジネスモデル、当該人的リソース、および、当該ノウハウのうち少なくとも一つから取得できる、データの取得可能性、および／または、取得可能なデータ価値を推定すること、
（２）前記通信部を介して取得された顧客情報、取引先情報、物流情報、会計情報、ビジネスモデル情報、人的リソース情報、および、ノウハウ情報のうち少なくとも一つに基づいて、購入、貸与または利用可能化される機器またはソフトウェアを推定して、当該機器または当該ソフトウェアに基づいて、データの取得可能性、および／または、取得可能なデータ価値を推定すること、および、
（３）前記通信部を介して取得された学習済みモデル情報またはオントロジー情報ないしナレッジグラフに基づいて、学習された元データまたはオントロジー化された元データを予測して、データの取得可能性、および／または、取得可能なデータ価値を推定すること、
のうち少なくとも一つを実行すること
　を特徴とするデータ利活用促進システム。
　請求項１または２に記載のデータ利活用促進システムにおいて、
　前記制御部は、
　前記ユースケース集ファイルに記憶された、データ種別と用途との対応関係に基づいて、分析対象となるデータと当該データに対する分析処理を実行する分析部品との紐付けを規定する分析関係情報を生成する分析関係情報管理部と、
　前記分析関係情報に基づき、ユーザにより分析対象として指定された所定データに対して、利用可能な分析部品の組合せを特定する分析実行管理部と、
　を備えるデータ利活用促進システム。
　請求項１または２に記載のデータ利活用促進システムにおいて、
　データパイプラインに埋め込まれ、通信部を介した評価を受け入れる評価モジュール部
　を更に備えるデータ利活用促進システム。
　請求項１または２に記載のデータ利活用促進システムにおいて、
　前記データ種別は、データ提供元の業種、および、データの種類を含み、
　前記用途は、データ提供先の業種、および、データ提供先の利用目的を含む、
　データ利活用促進システム。
　請求項１または２に記載のデータ利活用促進システムにおいて、
　前記データベースに登録された複数の異なるユーザのデータは、
　派生データであること、
　を特徴とするデータ利活用促進システム。
　データ種別と用途とを少なくとも対応付けて格納したユースケース集ファイル、および／または、複数の異なるユーザのデータを格納したデータベースを備えた記憶部と制御部を少なくとも備えたデータ利活用促進システムにおいて実行されるデータ利活用促進方法であって、
　前記制御部において実行される、
　前記ユースケース集ファイルに基づいて、用途とともに当該用途に対応するデータ種別を抽出する、および／または、前記データベースに登録された前記複数の異なるユーザの中から、データ連携により用途に適した他のユーザを抽出する抽出ステップと、
　前記抽出した、用途とともに当該用途に対応するデータ種別、および／または、用途に適した他のユーザを、提示する提示ステップと、
　を含むデータ利活用促進方法。
　データ種別と用途とを少なくとも対応付けて格納したユースケース集ファイル、および／または、複数の異なるユーザのデータを格納したデータベースを備えた記憶部と制御部を少なくとも備えたデータ利活用促進システムにおいて実行させるためのプログラムであって、
　前記制御部において、
　前記ユースケース集ファイルに基づいて、用途とともに当該用途に対応するデータ種別を抽出する、および／または、前記データベースに登録された前記複数の異なるユーザの中から、データ連携により用途に適した他のユーザを抽出する抽出ステップと、
　前記抽出した、用途とともに当該用途に対応するデータ種別、および／または、用途に適した他のユーザを、提示する提示ステップと、
　を実行させるためのプログラム。