目次

• 企業間データ連携とデータ連携基盤
• データ活用を管理するUsage Controlの仕組み

1章：企業間データ連携とデータ連携基盤

これまで企業内のデータを活用し様々なビジネス機会を創出したり、企業活動を最適化したりするような取り組みは多数行われてきました。一方で近年では、企業の枠を越えたデータ連携の必要性が高まっており、国内外で関連する技術開発、検討が行われ始めています。（※1、※2、※3、※4）このようなデータ連携においては、信頼関係があらかじめ構築されていない相手との連携や競合相手との連携も含まれるため、データ自体を取り扱う技術に加え、データのやりとりを管理するための技術が重要となります。そこで本記事では、データ連携の管理の側面に着目し、いくつかの特徴的な要素を説明したのち、データの利用制御を行う「Usage Control技術」を紹介します。

1-1節：企業間データ連携の背景とデータ連携基盤

まず初めに企業の枠を越えた連携の一例を挙げます。近年、環境に配慮した持続可能な経営的な観点から、バリューチェーンを構成する製造業企業をまたいでCO₂排出量・資源排気量などを算出し社会的な環境・人権の問題に対応していこうとする取り組みを耳にする機会も多いのではないでしょうか。（※5）いわば社会課題である、このような課題に対応するためには個社の取り組みだけでは足りません。関連する不特定多数の企業が連携してデータ分析し報告責務を果たしたり、企業横断の傾向から改善策を立案したりすることになります。ほかにも、このような企業の枠を越えた連携が必要なケースは、いまや様々な業界で見られるようになってきました。（※6）一方で、個社ごとにデータ連携を支える仕組みを構築するのでは、各企業は相手やユースケースごとに仕組み、プロトコル、アーキテクチャを検討・実現しなくてはならず、不特定多数の企業が円滑にデータ連携して共同で社会課題に対応していくようにスケールさせるのが困難です。そこで業界・企業横断で用いられるデータ連携の技術、基盤が期待されています。（図1参照）

図1：企業間データ連携基盤の概要

企業内のデータ連携と比べ、企業間のデータ連携では、お互いに適切な契約や約束をしたうえで、適切に管理された状態でデータ連携されることが望ましいでしょう。（※7）身近なケースでも、書面をやり取りして秘密保持契約を結んだり、利用するデータ共有サービスやアクセス権限を取り決めて用いたりしているのではないでしょうか。とはいえ、今よりも多数の企業と頻繁に、もしくはオンデマンドにデータ連携するようになり、やりとりされるデータが増えていくと個別対応することに限界があります。また本当に秘密に取り扱いたいデータの場合は、契約を結んでいるとはいえ技術的な担保なしにデータを共有することに抵抗を感じることもあるのではないでしょうか。そこで企業間データ連携では、図1に示すようにデータ本体のやり取りに加え、それを管理する仕組みが重要となります。本記事の1章ではそのうち、探索・発見、合意形成、Usage Control（データ利用制御）を紹介します。

1-2節：データ連携を支えるデータセット探索・発見、合意形成、Usage Controlの機能

データ連携を支える技術は多々ありますが、ここでは不特定多数の企業同士が利用可能なデータを見つけて交渉の上で適切に使用する際に必要となる技術を紹介します。
典型的な企業間データ連携（※8）では主にメタデータ情報からデータ利用者が使いたいデータを探索・発見し、データ提供者とデータ利用者の間でデータ共有時の条件について合意形成を行い、合意情報を基にしたポリシー（※9）によりデータ共有するというような流れが想定されます。以下に、全体概要を示します。

図2：データ連携を管理する仕組み：探索・発見、合意形成、Usage Control

ここでは図2のように、登場人物としてデータ共有を安全に行いたいデータ提供者と他社所有データを活用したいデータ利用者がいることとします。データ連携基盤内に記載された各機能の役割は表の通りです。

表：機能と役割

以下に、これらの機能を利用する際の処理フローを示します。

図3：データ連携を管理する仕組みの利用例

図3の1．探索・発見では、データ利用者が探索を行う前にデータ提供者が探索・発見に必要な情報（メタデータ）を登録しておく必要があります。その後、データ利用者がメタデータから必要な情報を探します。この時、適切な情報を保持したメタデータを用いることで、データ本体を直接扱うことなく探索ができます。つづいて2．合意形成では、発見したデータに関してデータ利用者とデータ提供者の間で利用条件を共同で定め、お互いが参照可能な場所に合意情報として登録します。さらに3．Usage Controlでは、合意情報を基にした機械可読かつ強制・実施可能なポリシーに従い、データ提供者とデータ利用者のデータストア使用や通信などを制御することで安全にデータ共有が可能となります。

以上が、データ連携を管理する主要な仕組みの紹介でした。本記事の2章では、その中でも特にセキュアにデータ流通する上では欠かせないUsage Control機能を取り上げ、関連オープンソースソフトウェアの概要・動向を含めて紹介します。

2章：データ活用を管理するUsage Control機能

ここからは、欧州での取り組みを参考にしつつ、Usage Controlについての内容と我々の見解について説明します。

2-1節：Usage Controlとは？

欧州のInternational Data Spaces Association（IDS）は、企業間でセキュアにデータ連携するために、Usage Controlというデータ利用制御方式を定義しています。Usage Controlには、企業内に閉じたデータ基盤に存在するデータストアに具備されているIDベースやロールベースなどの一般的なアクセスコントロールよりも条件が厳しく、かつ幅広い制御が求められるポリシーが定義されています。一般的なアクセスコントロールと比べて、Usage Controlには2つの大きな違いがあります。一つは、データ消費者に「責務」を与えるということです。一般的なアクセスコントロール（※12）では「誰が、どのデータに、どの操作を許可する／許可しない」という定義が一般的ですが、Usage Controlでは「いつまでに」「この目的に限って」など、データを利用するうえで守らなければならないことも定義に含まれます。もう一つは、データ利用制御を行う時間幅が広いということです。データの読み書きのタイミングで制御を行う一般的なアクセスコントロールに対し、Usage Controlではデータを流通している最中や流通後にも制御が求められます。具体的なポリシーをいくつかピックアップしてみますと、「データ流通後の第三者への提供が不可」、「決済が済んでいる場合のみ流通可」、「決められた回数だけ利用可能」、「生データの読み込みは不可で、匿名加工が必須」など特徴的なものがあります。ちなみに、「配布や印刷の禁止」など、カメラによる撮影や書き取りなどを考慮すると、現在のテクノロジーでは実現が不可能なのではないかというポリシーも含まれています。

図4：アクセスコントロールとUsage Controlのポリシーの具体例

2-2節：Usage Controlを実現するうえでの問題と対応するプロダクト

このUsage Controlで定義されたポリシーを用いてデータ連携を実現しようとすると、解決しなければならない重要な問題が2つあります。一つは制御内容の観点で、主にデータストアに採用されるアクセス制御方式のアクセスコントロールではデータセット・ユーザ・アクションを中心に判定を行うため、データ消費者に対しての「責務」の制御のように複雑な内容を取り扱うのが難しいという問題です。

もう一つは制御対象の観点で、データストアに対するアクセスコントロールのみでは、データを読みだした後のデータ流通途中や流通後の制御が難しいという問題です。 ここからは、2つの問題について、どのような解決手段が挙げられているのか1つずつ説明します。

まず、一つ目のデータ消費者に対して「責務」の制御を行うことができないという問題について説明します。この問題を裏返して考えると、「対象の許可・拒否に限らずポリシーを柔軟に定義できる仕組みが必要」という課題を解くべきであると言うことが可能です。この「単純なアクセスコントロールを超えた柔軟な制御を定義できる仕組み」については、IDSによる「Usage Control in the International Data Spaces（※13）」というポジションペーパーの中でいくつかソフトウェアが挙げられています。これらのソフトウェアによって、ユーザ自らが制御ポリシーをプログラミング言語で自由度高く定義することができ、また定義したポリシーに元ついてデータの利用可否を判断することができます。ここでは「ポリシー言語処理系ソフトウェア」と呼ぶことにします。このポリシー言語処理系ソフトウェアを利用することで、Usage Controlポリシーのような現実世界に基づく状態や行動も柔軟に定義が可能となります。ポジションペーパーの中には、初めから企業間データ連携を想定して作られたプロダクトとそうではない汎用的なプロダクトが挙げられています。前者にはMyDataやLuconといったプロダクトがあり、後者にはOpen Policy Agentといったプロダクトがあります。図5は、Open Policy Agent（※14）によって、データストアのデータ利用制御を高度化しているアーキテクチャの一例です。Open Policy Agentを用いることで、Regoというプログラミング言語による自由度の高いポリシー定義および定義したポリシーに従ってリクエストを許可するかの判定を行うことが可能です。例えば、2-1節で取り上げた制御内容で考えると、「決済完了が必須」という責務に対しては、「決済システムにAPIでアクセスして、実際に決済が完了していることが確認できれば許可する」というロジックを定義するということがRegoによって可能となります。「特定の目的のみに利用できる」という責務では、少し条件は厳しくなりますが、「事前に取り決めた特定のアプリケーションのみからデータ消費が可能」というロジックの定義が考えられます。図5の中では時間制限のソースコードの例を挙げています。Regoには様々なデータ型やAPIが用意されており、それらを用いて多様な制御を行うことが可能です。

図5：Open Policy Agentを用いたアーキテクチャ例およびサンプルコード

続いて、もう一つの「流通途中や流通後の制御ができない」という問題について説明します。この問題を裏返して考えると、「定義したポリシーに基づいて、データ提供者側のデータ基盤だけでなく、データ消費者側のデータ基盤や間にあるシステム上でも制御を行うことができる仕組みが必要」という課題を解くべきであると言うことが可能です。IDSのポジションペーパーでは、Apache Camel （※15）というメッセージ処理・ルーティングソフトウェアを用いてこの仕組みを実現できる可能性があると述べられています。Apache Camelによって、流入されるメッセージのプロトコルや中身それぞれについて、実施する処理の定義や次の転送先の定義をすることができます。図6は、Apache Camelを利用して、データ提供者が持つデータを定義されたポリシーに遵守させた状態でデータ消費者に流通させ、流通後もデータ利用制御を監視することでポリシーに遵守させることができると想定されるアーキテクチャの一例です。Apache Camelは各データ基盤・システムにデプロイされ、データを受け取る際にポリシーの判定を行うことで、間に匿名化処理を挟む、流通後もデータ利用を制御し続ける、などというポリシー制御が可能と見込まれています。（※16）

図6：Apache Camelを用いたデータ流通全体のポリシー制御アーキテクチャ例

ここまで、Usage Controlのポリシー制御を実現するために存在する問題を解決し得るアプローチとして、ポリシー言語処理系ソフトウェアとメッセージ処理・ルーティングソフトウェアの2つを挙げました。ここでは「し得る」という言い方に留めていておりますが、各ポリシー言語処理系は開発の歴史が浅く、Usage Controlのポリシー群の実現を現状カバーできていないこと、また実際にデータ流通全体で利用制御を行うような事例が世に出回っていないということが理由としてあります。NTTデータは、本記事で説明した技術を用いてUsage Controlを実現することに加え、企業間データ連携を実現するための様々技術開発を行っています。これらの活動を通じて、安全なデータ連携基盤の実現に貢献します。