本連載第一回「完璧な匿名化は存在しない」では、非特定識別情報に幅があるということが明確になった。それはつまりタイトル通り、完璧な匿名化はないということである。

個人は最終的に不安を取り除ききることはできない。そうなると、データそのものが不安な状態でも、安心して処理を託すことができることが重要になる。「リスクがある」ということを個人が理解した上で、この枠組み・この事業者なら安心して任せられるという信頼構築ができることが、現実解ではないかという考えである。

こうした現実解を実現させるために有望視されているのが、トラストフレームワークである。今回はその基礎的なところと、それがパーソナルデータ利活用の基盤に成りうるのかということを、この分野のキーパーソンである野村総合研究所上席研究員でOpenID Foundation理事長、Kantara Initiative理事を兼任する崎村夏彦氏に伺う。

クレジットカードやJASマークも信頼感醸成の枠組み＝トラストフレームワークである

──まず、トラストフレームワークとは何かというところから教えていただけますか。

崎村氏（以下敬称略）：はい。トラストフレームワークは端的に言うと信頼感を醸成するための枠組みです。かなり広く使われる言葉で、ITやプライバシーに限った話ではありません。クレジットカードやJASマークもトラストフレームワークの代表例です。

それを踏まえた上で、今回はパーソナルデータの利活用の基盤となる、いわゆるプライバシートラストフレームワークについてお話していきたいと考えています。

──いまプライバシー分野ではどのようなものがトラストフレームワークとして機能していますか。

崎村：先の定義を踏まえると、プライバシートラストフレームワークは、パーソナルデータやプライバシーの領域でのトラストフレームワークに入っている人たちなら安心してデータを渡せる、という信頼の枠組みということになります。

プライバシートラストフレームワークの代表例はセーフハーバー

その代表例には米国の「セーフハーバー」（※）が挙げられます。
※セーフハーバー:米国商務省のガイドライン「セーフハーバー原則」。個人情報保護の水準がEUのデータ保護指令に準じることを自己宣言し登録するもの。遵守出来なければ連邦取引委員会（FTC）が不公正取引として制裁を加える仕組み。

──いわゆる欧州と米国間の「セーフハーバー」ですね。

崎村：そうです。米国の各企業が「セーフハーバー」に加入すると、これは実行宣言なので、守らなければならないルールがたくさん生じます。具体的には、かなり強制力のあるFTC法5条（※）や集団訴訟などが追いかけてくるようになります。
※FTC法5条:「不公正又は欺瞞的行為又は慣行」を米国のFTCが監督、制裁を行う根拠となる条文。

自主的な宣言であっても、宣言をすることによって法的な強制力が働くようになるため、一つの信頼性を醸成するトラストフレームワークと言えると思います。

===

マルチステイクホルダープロセスによって信頼感の持てる基準が作られる

──仮にトラストフレームワークがなかったら、円滑に進まない、阻害されるものはありますか。

崎村：いくつかの観点がありえると思いますが、一例をお話します。
例えば、ある業務の中で適切なデータの非識別化が出来ているか、を規格や標準で判断出来るかというと、一般的には「できない」という答えになります。

取り扱うデータが多様である以上、一般的な判断基準というのはあり得ないですね。というわけで、ある業務・業界の知識のもとで基準を作って行くことになります。

判断基準となるものを、一企業が単独で主張したところで顧客の信頼は得られません。そこはやはりマルチステイクホルダープロセス（※）で「妥当な線」を引いて行く必要がでてきます。
※マルチステイクホルダープロセス:業務に携わる様々な関係者（ステイクホルダー）が、対等な立場で参加・議論できる会議を通し、合意形成などの意思疎通を図ること。

──業界毎に定めるというお話がでましたが、フレームワークを定める単位は国毎より業界単位と捉えた方がいいのでしょうか。

崎村：国で決められることは、大枠しかありません。たとえば、英国のICO（※）が「処理の要件（Conditions for processing）」として六つ示しているようなものですね。良く「明示的な同意」といいますが、これはその「処理の要件」の一つ、他がダメだったらちゃんと明示的な同意を取ってねという例外規定に過ぎません。問題はその他の要件で、たとえば「処理が必要である。」というのがありますが、何をもって必要とするかということは、その業務内容に鑑みて判断していく必要があります。これは国単位では無理だし、かと言って企業毎だとお手盛りになりますから、やはり業界単位くらいが良い線ではないかと思います。
※英国ICO（Information Commissioner's Office）:英国の個人情報保護、公的機関の情報開示の独立第三者機関。

商取引上必要なデータを取得する際には同意は不要

実は商取引上明らかに必要なデータについては本来同意を取る必要がないのです。たとえば通信販売において、荷物の着荷先の住所氏名は、貰わないと取引が成立しないデータです。これは明示的な同意を求める必要は全くないですね。

こういった状況に合わせて自分たちの取るデータが同意を取る必要があるのかを判断していくことになるのですが、これは業務知識がないと判定できないことです。なので、私は業界毎に基準を決める方がいいと考えています。

──業務の束や業界毎のスタイルに合わせて見て行く必要があるということですね。

崎村：そのデータをもらうことが本当に業務に必要かどうかは傍から見てもわからない、ということがポイントです。

「必要なデータのみ集める」、「必要な人しかデータにアクセスしない」が基本方針

──パーソナルデータかどうかは、商取引のコンテキストにも左右されるということですね。業務のコンテキストに合わせて一つ一つ厳格に定義していくのが妥当なのでしょうか。

崎村：基本方針は、必要なデータしか集めず必要な期間しか保持しない（データミニマイゼーション）、必要な処理しかしない（ユースリミテーション）になると思います。そして何をもってそのデータを必要とするのか、処理が必要なのかは業務知識がないと判断出来ないので個別の検討が必要になるでしょうね。

──業界毎のトラストフレームワークが段階や種類でさらに細分化されるという可能性はあるでしょうか。

崎村：段階毎に分かれるというのはありますね。私たちの業界ではよくレベルオブコントロールやレベルオブプロテクション、と言います。どこまでユーザーに制御権を与えるのかはある程度レベル設定があり、それは情報毎に異なります。

取り扱う情報とリスクをマッピングしていくことで必要な制御や保護レベルが判定できます。これを行わずにすべてに最高のレベルを要求するのは非現実的だと思っています。

──なるほど、ISOのように成熟したルールの枠組みになるといいのでしょうね。

崎村：はい、ただまだそこまでには至ってはいません。そういうものが必要だろうという議論は既に何年も前からあるので、これからなのだと思います。
こういった標準化の話で言うと、PIA（※1）と特定個人情報保護評価（※2）は分けて考えてほしい、ということもお伝えしたいですね。この2つは全く違うものです。
※1 PIA:プライバシー影響評価。金融分野では2008年4月にISO22307（Financial services Privacy impact assessment）として標準ドキュメントが発行された。現在、ISO/IEC 29134（Privacy Impact Assessment Methodology）として標準化が進んでいる。
※2 特定個人情報保護評価:マイナンバー法の施行により個人情報を預かることになる国の行政機関や地方公共団体等が、特定個人情報の漏洩の危険性や影響に関して評価などを行うもの。

いわゆるPIAは、あるデータを扱う業務が個人にどれくらいリスクを与えるかということを査定するものです。ですからリスクの測り方をまず決めないと先の部分が決まりません。現在のところ、PIAはまだかなり初歩的なレベルにあると思います。

===

PIAはパーソナルデータをある業務で扱う時のデータの扱い方をリスクの観点から評価すること

──まず、PIAを一言でご説明いただけますか。

崎村：パーソナルデータをある業務で扱う時のデータの扱い方をリスクの観点から評価することです。パーソナルデータをデータコントローラー（データを収集、保有、処理するないしさせる者）が受け取り処理しながら利用する際、一連のデータ利用のライフサイクルの中で、そのデータサブジェクト（データが指し示す個人）にとってのリスクを評価すること、と言うことができます。

──PIAはそうしたデータコントローラーの業務すべてを対象として評価するのでしょうか。

崎村：いえ、この場合は、パーソナルデータを取り扱う業務プロセスを対象とします。とはいえ、それでも相当領域が広いはず。多くの場合はパーソナルデータを扱う業務の中でも閾値分析をして、リスクの高い領域を重点的に行います。

──PIAは自己評価か第三者評価かどちらでしょうか？

崎村：基本的には自己評価と考えてよいと思います。となると、評価のフレームワークや閾値の設定、またリスクの評価基準が重要です。テンプレート的には共通のものもあると思いますが、インパクトや同意の取り方が適切かどうか、そういったことは業界毎に異なりますね。

PIAのフレームワークそのものは、業界を跨いで共通のものがあっていいのですが、その適用は業界毎に異なるというのが効果的な設計だと思います。

システム構築時に評価を行うことで効果的な設計変更が可能になる

──PIAはいつ行うものですか。

崎村：システム構築の早い段階で行うのが最も効果的です。リスクを減らすためにシステムの設計変更を行うのが目的ですから、それが出来ないタイミングでやっても仕方がないと言えます。

大幅に変更可能なタイミングで行って設計に活かし、業界的なコンセンサスの枠組みの中で望ましいところにリスクが抑えられたシステムを構築し、それをトラストフレームワーク上で公表して行けると理想的ですね。

──トラストフレームワークとかなり近いのですね。

崎村：PIAは、トラストフレームワーク内で望まれるレベルにプライバシー侵害リスクを抑えるための手段です。