思考実験:PIAとリクナビ事件

1.今日のテーマ

f:id:seko-law:20211128082252p:plain

高木先生が以下のようなツイートをされていて、確かに面白い思考実験だなと思ったので自分でも考えてみることにしました。*1

2.前提

まずは検討の前提を整理します。

(1)事実

「リクナビ事件」については、個人情報保護委員会の「個人情報の保護に関する法律に基づく行政上の対応について」における「勧告の原因となる事実」記載の事実を前提とします。

➀ 2018年度卒業生向けの「リクナビ2019」におけるサービスでは、個人情報である氏名の代わりに Cookie で突合し、特定の個人を識別しないとする方式で内定辞退率を算出し、第三者提供に係る同意を得ずにこれを利用企業に提供していた。
リクルートキャリア社は、内定辞退率の提供を受けた企業側において特定の個人を識別できることを知りながら、提供する側では特定の個人を識別できないとして、個人データの第三者提供の同意取得を回避しており、法の趣旨を潜脱した極めて不適切なサービスを行っていた。

➁ 本サービスにおける突合率を向上させるため、ハッシュ化すれば個人情報に該当しないとの誤った認識の下、サービス利用企業から提供を受けた氏名で突合し内定辞退率を算出していた。ハッシュ化されていても、リクルートキャリア社において特定の個人を識別することができ、本人の同意を得ずに内定辞退率を利用企業に提供していた。

➂ 「リクナビ2020」プレサイト開設時(2018年6月)に、本サービスの利用目的 が同サイト内に記載されたことをもって、サービス利用企業から提供を受けた氏名で突合し内定辞退率を、算出していた。
しかしながら、プレサイト開設時のプライバシーポリシーには第三者提供の同意を求める記載はなく、2019年3月のプライバシーポリシー改定までの間、本人の同意を得ないまま内定辞退率をサービス利用企業に提供していた。

➃ 本人の同意なく第三者提供が行われた本人の数は、上記➁、➂及び前回の勧告の対象となった事実によるもの等を合わせ、26,060人となった。

出典:個人情報の保護に関する法律に基づく行政上の対応について

(2)仮定

「ISOやJIS則ったPIAを実施」していたなら

という仮定の部分ですが、ここは少し解釈を加えます。「ISOやJIS則ったPIAを実施」しているということは、以下の仮定が成り立つことであると解釈して検討します。

  • 【仮定1】PIAの実施要否について社内に基準がある
    (6.2 PIA の必要性の決定(しきい値分析))
  • 【仮定2】PIA実施のための組織・制度がある
    (6.3.1 PIA チームの設置及び指示)
  • 【仮定3】PIA実施のために必要な専門性を持ったリソースがある
    (6.3.2 PIA 計画の作成及び PIA を実施するために必要なリソースの決定)
  • 【仮定4】プライバシーリスクのアセスメントが行われる
    (6.4.4 プライバシーリスクのアセスメント) 
  • 【仮定5】残留するプライバシーリスクの受容,対応計画におけるPIA 推奨事項の非実施、及び PIA 報告書の非公表要素に関して行われた意思決定は、これらの意思決定に至った結論が明示される
    (7.7 結論及び意思決定)
  • 【仮定6】PII 主体に関連する重要な側面については、PIAパブリックサマリが公表される
    (7.8 PIA パブリックサマリ)

3.検討

上記の前提の下で本件が進行した場合、どのようなことが起こるかを検討します。

(1)「本サービス」はPIAの対象になる

【仮定1】【仮定2】から、本サービスがPIAを経ずに世に出ることはなさそうです。

制度として運用されているPIAがあり、また、スコアリングを行うという本サービスの性質を踏まえると、今回の案件がしきい値を下回ってPIA対象外と処理されることはなさそうだからです。

(2)混ぜるな危険の話・同意の有効性の話は、議論の俎上に上がる

【仮定3】【仮定4】から、本件で指摘を受けたような論点についてはPIAの過程で議論の俎上に上がると考えます。

それが「個人情報保護法における”委託”や”同意”の解釈論」として上がるか、「toCユーザーに正面から説明ができないような取組みを進めるべきではない」といったべき論寄りの意見として上がるかはともかく、PIA実施のために必要な専門性を持ったリソースがあるのであれば何らかの問題提起があると想像します。

(3)強引なリスク受容はしにくい

【仮定5】から、上記の問題提起を乗り越えリスク受容をする場合、「これらの意思決定に至った結論」を文字に落とすことになります。また【仮定6】からパブリックサマリの公表があります。これらは、強引なリスク受容への抑止力になります。

案件の状況によってはエスカレーション等々があるかもしれませんが、ここを理由にもならないような理由で乗り切ることを許容する制度にはなっていないとは言えそうです。

4.結論

以上より「起きなかった」と言えるのではないか…というのが、希望も含めた自分の考えです。

5.おまけ(仮定は本当に成り立つか、推論は現実的か)

とはいえ、2で述べた仮定が揺らいでしまったり、3で述べた推論が成り立たない場合もありそうです。「実際にこういうことは起こりそう」という観点から検討してみます。(なお、以下は一般論としてまさに思考実験を行うもので、リクナビ事件の実際の状況について述べるものではありません(そもそも私は詳細を知りません)。)

(1)PoC

世の中にはPoCという都合の良い言葉があります。

本サービスがどのような位置付けだったかは分かりませんが、PoCであることを理由に社内的な手続を省略したいという考えを持つ人はいます。ここに誤解があると「(1)「本サービス」はPIAの対象になる」が揺らぎそうです。

「対象ユーザー数が少ない」というのは確かに考慮すべき一つの事情ではありますが、それを持ってPIAが不要になるものではありません。

(2)子会社

グループ会社の場合には、本社側が管理機能を持つ(=PIAを行う)こともそれなりに多くありそうです。

法人を跨ぐ場合には、認識やリテラシーに差が生じがちであり、案件の捕捉漏れも起こりやすいことから「(1)「本サービス」はPIAの対象になる」が揺らがないように注意したい所です。

(3)toB顧客

本件では内定辞退率を受け取る側の、toB顧客が存在しました。

このようなケースでは、企画を練る段階においてtoB顧客にヒアリングをすることはよくあります。それがPIAの実施に先立つことも、またよくあることです。

これがあくまでヒアリングとして位置付けられていれば良いのですが、熱心な事業担当者がtoB顧客に対してこの段階で何らか合意や確約をしてしまうこともあり得ます。

この合意や確約が「今更反故にはできない」といった認識につながり、「強引なリスク受容」を行うモチベーションになってしまうことはありそうです。まさにPrivacy by Designですが、企画の柔らかい段階から入り込んでおくことは、この辺りのケアという意味でも重要だと考えています。

(4)実績

既に実施している取組みについて「実施しない」と判断することは、新たな取組みについて「実施しない」と判断することの何倍、何十倍も難しいことです。

本記事では「【仮定2】PIA実施のための制度がある」との仮定を置きましたが、PIA実施のための制度が定着する前に意思決定がなされた取組みもたくさん存在するはずです。そして、当然ながらそれらの取組みについてはPIAがなされていない訳です。

PIAがなされず、リスクを丸抱えしたまま継続されている施策についても「今更止められない」といった気持ちが「強引なリスク受容」を行うモチベーションになってしまうことはありそうです。

-----------------

以上です。

個人的には「5.おまけ」で書いたような部分こそが、PIAにおける悩ましい部分で気をつけなければならないと感じている所です。

また、PIAはそのアセスメント行為自体も大切ですが、PIAを通じて事業側と管理側が相互理解を深めることこそ価値があると思うので、継続実施が大事だなとも思います。

*1:リクルートさんには尊敬できる方が多くおられますし、現在プライバシーにも積極的に取り組んでおられると人づてに聞いています。本記事に他意はなく、あくまで事例の検討のためであることを明確にしておきます。