ニュースコメンタリー（個人関連情報への同意取得など）

毎週木曜日に配信している「データサイン・ランチタイムトーク」の模様をレポートします。

当記事で取り上げるのは以下の配信です。

• 配信日：2021年4月8日
• タイトル：ニュースコメンタリー（個人関連情報への同意取得など）
• 発表者：データサイン 代表取締役社長 太田祐一

個人関連情報の第三者提供における同意取得を、提供元が代行するとどうなる？

プライバシーテック界隈の気になる話題やニュースについて、データサイン 代表取締役社長 太田祐一がコメントしました。

最初の話題は、2020年公布の改正個人情報保護法（以下、改正法）における「個人関連情報」について、です。

個人関連情報とは、提供元（Ａ社）では個人データに該当しないものの、提供先（Ｂ社）において保有される個人データやIDと結合することにより個人を識別できるようなデータの総称です。ユーザーの氏名と結びついていないインターネットの閲覧履歴や位置情報、オンライン識別子であるCookieなどが該当します。

改正法では、個人関連情報の第三者提供をしてよいかどうかについて、ユーザー本人の同意があることが義務付けられています。

2021年4月７日に開催された第171回個人情報保護委員会の資料「改正法に関連するガイドライン等の整備に向けた論点について（個人関連情報）」では、論点の1つとして「本人からの同意取得の態様・方法」が取り上げられました。

「上述の委員会では、本人同意を提供元・提供先のどちらが取得するか、が検討されています。本人と接点を有する、情報の利用主体である提供先B社だけでなく、提供元のＡ社が同意を取得したほうが流れはスムーズではないか、といった指摘はこれまでにもパブコメなどでありました」（太田）

上記委員会資料によると、提供元A社での同意取得は、提供先B社の「代行」という位置付けです。同意の取得に先立って、提供元A社と提供先B社は商談などの際に、A 社が提供する個人関連情報の項目（購買履歴等）と、B社が有する顧客情報等の個人データとを紐づける予定があるのかどうか、などを確認する業務フローが例示されています。

「あくまでも提供先が同意取得の主体であることに変わりはなく、提供元が代行する際には、本人に対して個人関連情報の提供先を個別に明示する、ことが記されています。ところで、個人情報の第三者提供における同意取得では、本人に提供先を個別に通知する必要はありません。そのため、提供元の立場では、個人関連情報の取り扱いのほうが煩雑な運用になってしまうのではないか、という懸念があります」（太田）

なお、EUのGDPR（一般データ保護規則）やCCPA （カリフォルニア州消費者プライバシー法）では、Cookieなどのオンライン識別子は「個人情報」と見なしており、日本の個人情報保護法の捉え方とは一線を画しています。

アップルのApp Tracking Transparency対応が必須化

2021年4月27 日から配信が開始されたiOS14.5。アプリが他のWebやアプリを横断してユーザーの行動を追跡する前に、ユーザーから明示された許可を得ることが必須になりました。これはApp Tracking Transparency（ATT、アプリのトラッキング透明性）と呼ばれています。

ところが、WebメディアのEngadgetが提供する情報などによると、アップルではiOS14.5配信の前からすでに、ユーザーを追跡する一意の識別子を作成していたいくつかのアプリを発見し、そのアップデートを却下していました。

「2021年4月６日にWeb開催された総務省の第2回『プラットフォームサービスに係る利用者情報の取扱いに関するワーキンググループ』に私も参加したところ、アップルのCPO（Chief Privacy Officer）が、アプリを利用するユーザーの選択を尊重しなければならないと強調していました。CPOの発言は、アプリ開発側はUnified ID 2.0のようなメールアドレスをハッシュ化、またはアプリや開発者を識別するIDFV（Identifier for Vendor）を他社と共有することによるトラッキング、フィンガープリンティングなど、あらゆるトラッキング手段は認められない、もしそれらを行っていた場合はAppStoreからアプリを除外する、という厳しいものでした」（太田）

Unified ID 2.0で扱われるハッシュ化されたメールアドレスは「個人情報」？

前述のUnified ID 2.0を用いたリターゲティング広告のイメージは、GitHubに公開された仕様などによると次のような流れです。

1. 広告主などが提供するサイトを訪れたユーザーＸが会員登録などの際に入力したメールアドレスは、UID2アドミニストレーターのAPIを介してノーマライズ（正規化）され、ソルト付きのハッシュ値に変換されたのちに【UID2】として保存されます。
2. 他方、広告を表示するメディア（SSP）では、上記と同様にユーザーがメディアにメールアドレスでログインした際に当該メールアドレスをAPI経由でハッシュ化し、さらに暗号化して【UID2トークン】に変換、広告主側（DSP）に送付します。
3. DSPは、UID2アドミニストレーターから提供されるキーを用いて、受け取ったUID2トークンを復号し、ハッシュ化されたメールアドレスを取り出します。
4. そしてデータ保有者から送られるUID2と照合することで、ユーザーXであることを認識し、広告表示するメディアの広告枠をいくらで買うかを決めるオークション（Real Time Bidding）に参加します。

「UID2とUID2トークンは、匿名加工情報である、という意見がありますが、本人を一意に識別できる個人データと考えられます。したがって、Unified ID 2.0の利用においては個人情報の第三者提供におけるユーザー本人の同意取得が必要になるでしょう」（太田）

太田が気になったのはもう1点、ユーザーが使い分けているメールアドレスを名寄せするノーマライズ（正規化）の適用について。こちらについては、ユーザーからの事前同意などは必要ないのでしょうか。今後の論点になりそうです。