MCデータプラス執行停止申立事件:公取委の排除措置命令が個情法違反行為を命じるものである旨の主張が認められなかった事例(東京地方裁判所令和7年3月27日決定・東京高等裁判所令和7年10月17日決定)

個人情報保護法から見たMCデータプラス一審・抗告審決定について、お蔵入りになっていたペーパーを掲載します(2026年12月7日脱稿)。こちらを分かりやすくした上で、加筆したものです。なお、原文はこちらです:排除措置命令、一審決定、抗告審決定。

はじめに

MCデータプラス事件は、独禁法違反事件(不公正な取引方法―取引妨害)において、正当化事由として排除措置命令に従った場合の個情法違反が主張され、裁判所がこれを否定した事例である。本稿は、①独禁法関係者向けに個情法の構造を示すこと、②個情法関係者向けに独禁法の構造を示すこと、③本決定に典型的に表れている、個情法上の論点について検討を加えることを目的とする。

事実の概要

株式会社MCデータプラス(MCDP)は、建設業向けクラウドサービス「建設サイト・シリーズ」を提供する事業者であり、その主なサービスとして、建設工事の現場における元請・下請間の労務安全書類の作成・提出・管理等をインターネット上で行うことを可能とする労務安全サービス「グリーンサイト」を提供している。競争関係にあるサービスとして、シェルフィー株式会社が提供する「Greenfile.work」及び株式会社リバスタが提供する「Buildee労務安全」がある。

労務安全サービスは、建設工事の現場において元請及び下請のユーザーが同一のサービスを利用し、労務安全書類のやり取りをオンラインで行うことにより関連業務の効率化を図るものであり、その利用に当たっては、下請となるユーザーが自社の作業員に関する詳細な個人情報をサービス上に登録する必要がある。グリーンサイトでは、作業員一人につき最大100項目を超える氏名、生年月日、在留資格、健康診断結果等の情報の登録が求められ、多数の作業員を抱えるユーザーにとって登録作業は大きな負担となる。これらの作業員情報は、労務安全書類の作成のみならず、多数の作業員の適正配置等にも利用されるなど、建設工事の施工において必要かつ重要な情報である。MCDPは、平成31年4月以降、労務安全サービスに係る売上高や登録企業数、登録作業員数、契約元請会社数及び契約企業数において第1位の地位を占め、第2位以下を大きく引き離している。

MCDPは、グリーンサイトの提供に当たり、「「建設サイト・シリーズ」サービス利用約款」への同意をユーザーに求め、同約款に同意しない限りグリーンサイトを利用できないようにしていた。グリーンサイトに登録された作業員情報等について、ユーザーは労務安全書類を帳票として出力する場合を除き、電磁的記録として直接出力することができなかったため、他社の労務安全サービスに切り替える場合には、当該帳票を利用するか、再度入力して登録する必要があった。そのような状況の下で、ユーザーから、他社の労務安全サービスに移行可能な形式で別紙2記載の作業員情報の提供を求められても、MCDPは遅くとも令和2年頃以降、当該作業員情報がユーザー自ら登録した情報であるにもかかわらず、個人情報保護を理由とするなどして、合理的な理由なく当該提供に応じなかった。

サービス利用約款の個人情報に関する定めは、以下のようになっていた。

40条

1項 MCDPは、「サービス」に登録された個人情報を、本条各項のとおり取り扱います。「申込者」は、本条各項で記載された個人情報の取扱いについて、あらかじめ本人に通知し同意を得るものとします。

2項 MCDPは、「サービス」に登録された個人情報を、以下の利用目的の範囲内で、目的の達成に必要な限りにおいて利用します。

(1) 「建設サイト・シリーズ」のサービス提供を行うため。

(2) 「サービス」の利用料等の請求及びそれに附随する連絡等のため。

(3) 「サービス」の運営に関する各種通知や連絡のため。

(4) MCDPが提供又は提携する商品・サービス等に関する各種お知らせ等の配信・送付のため。

(5) 商品・サービス等の企画、開発等のための情報収集を目的とした調査を実施するため。

(6) 第3項に規定される「共同利用の目的」に記載の目的。

(7) 第4項に規定される「提供目的」に記載の目的。

(8) 第5項に規定される「提供目的」に記載の目的。

3項 MCDPは、以下の各号のとおり個人情報の共同利用を行っています。「申込者」は、個人情報の共同利用について、個人情報保護法その他の法令・ガイドラインの定めに従い、共同利用の内容を、あらかじめ本人に通知し、又は本人が容易に知り得る状態に置くものとします。また、「申込者」は、共同利用される個人情報を、個人情報の保護に関する法律その他の法令及びガイドラインを遵守して、適切に取り扱うものとします。

(1) 「建設サイト・シリーズ」で提供する全ての「サービス」における個人情報の共同利用について

① 共同利用の範囲

・MCDP

・「オーナー企業」が企画組成し、該当個人情報が登録される「プロジェクト」に参加する「申込者」

② 共同利用の目的

(ア) 「建設サイト・シリーズ」の「利用者」の個人認証をするため。

(イ) 「建設サイト・シリーズ」として提供される、建設工事に係る業務の効率化を目的としたサービス(例えば、施工体制台帳・再下請負通知書・作業員名簿等の作成・管理、建設現場への入退場の記録・管理、作業日報・安全日報・安全巡視記録等の作成・管理、独自資格保有者の入退場記録の集計及び報告書の作成・管理等)の利用のため。

(ウ) 「建設サイト・シリーズ」で作成される各種書類(データを含む)の法に基づく公的機関への提出のため。

(エ) 「建設サイト・シリーズ」に関する各種通知や連絡のため。

(オ) 「建設サイト・シリーズ」の運営や改善のため。

(カ) 「建設サイト・シリーズ」の新規サービス開発及びそれに附随する調査等のため。

(キ) 「建設サイト・シリーズ」に関するお問合せ・依頼等に対応するため。

③ 共同利用される個人情報の項目

(ア) 以下の項目

・氏名、性別、住所、電話番号、電子メールアドレス、生年月日、国籍、顔写真、MCDPが情報管理を行うために発番するID等の記号等の属性情報

・会社名、会社住所、部署名、役職、職種、取得資格、経験年数等の職歴情報

・健康診断受診日、社会保険加入状況、血液型、血圧、じん肺管理区分等の労働安全衛生管理のための情報

(イ) 「建設サイト・シリーズ」の利用に際して、「申込者」又は「利用者」がMCDPに提出した情報

(2) 《省略》

さらにMCDPは、シェルフィーが、グリーンサイトから出力した帳票をシェルフィーに提供することにより作業員情報を自社の労務安全サービスへ移行する方法等を解説する記事(移行記事)を自社ウェブサイト上に公開したことを受け、令和元年9月9日にサービス利用約款の禁止事項条項(29条1項8号)を改定し、「サービスの利用により入手したものを他社サービスに提供する行為」を含めて、グリーンサイトから出力した帳票等を他社に提供する行為を一律に禁止する旨を明記した。また、令和3年12月1日には、29条1項12号を新設し、グリーンサイトに登録された作業員情報について、共同利用の目的の範囲外での加工、複写又は複製を一律に禁止することとした。MCDPは、これらの約款改定を踏まえ、令和元年10月21日及び令和3年1月21日に、移行記事がサービス利用約款に違反する行為をグリーンサイトのユーザーに促し、同ユーザーに利用停止等の不利益を招きかねない内容であるとして、移行記事の削除等を求める配達証明郵便及び内容証明郵便をシェルフィーに送付した。さらに、令和2年9月頃に、グリーンサイトのユーザーがリバスタの「Buildee労務安全」への切替えに際し、グリーンサイトから出力した帳票等をそのまま他社に提供している事例を把握すると、同年10月7日に、当該行為がサービス利用約款29条1項8号に規定する禁止事項に該当する旨を建設サイト・シリーズのポータル画面に周知文として掲載し、同年10月20日、23日及び28日の3回にわたり、同様の内容の電子メールをユーザーに送信した。

これらの対応の結果、グリーンサイトのユーザーの中には、他社の労務安全サービスへの切替えを断念した者が生じ、実際に他社への切替えを実施したユーザーについても、下請事業者の作業員情報の移行に電磁的記録を利用できなかったため、相当の時間及び費用を投じて作業員情報を代行入力するなど、切替えにあたり大きな負担を負うこととなった。また、シェルフィー及びリバスタは、グリーンサイトのユーザーから、その下請事業者の作業員情報を容易に移行できないことを理由に取引を断られることがあったほか、シェルフィーは、MCDPからの度重なる削除要求等を受けて移行記事を非公開とし、営業先の変更等を余儀なくされ、当該記事を利用した積極的な営業が困難となった。

公取委は、MCDPがこのように、グリーンサイトのユーザーに対し他社の労務安全サービスへの切替えをしないようにさせることによって、自己と競争関係にある事業者とその取引の相手方との取引を不当に妨害している(一般指定14項)として、令和6年12月24日付けで、①作業員情報の提供拒否行為の中止(以下簡略に「提供」を命じたものとして言及することがある。)、②前記行為の中止等の取締役会決議、③②に基づいて取った措置の競争者への通知と自社従業員への周知徹底、④同種行為の禁止、⑤体制整備、⑥①②⑤に基づいて取った措置の公取委への報告を内容とする排除措置命令を発した(丸付き番号は命令主文の項番号に対応する。)。MCDPは、取消訴訟を提起し、執行停止を申し立てた。

執行停止申立事件においては、大きく2つの争点が生じた。第1点は、排除措置命令主文1項の解釈であり、一審は、MCDPの解釈を支持して執行停止における「重大な損害」要件(行訴法25条2項)を認めたが(一部執行停止)、抗告審は、公取委の解釈を支持してこれを否定した(原決定取消し、申立て却下)。第2点は、主文1項が個情法27条1項違反及び19条違反の行為を命じるものではないかであり、一審・抗告審とも公取委の主張を支持した。本稿では、控訴審決定が引用する一審決定の個情法に関する判示を論評の対象とする。

判旨

個情法27条1項関係

「申立人は、ユーザーが作業員情報を利用できる目的は、申立人のサービスにおける利用に限定されているから、本件命令(主文第1項)により、本人の事前の同意を得ないまま作業員情報を提供することが避けられないこととなり、個人情報保護法27条1項に違反する行為を強制されると主張する。/しかしながら、①…関係法令上、元請会社に作成が義務付けられている施工体制台帳や施工体系図は、協力会社から提出される再下請通知書等の労務安全書類を基に作成されるものであり、各協力会社は、当該工事現場の工事に関与する自社の作業員に関する名簿(作業員名簿)を作成し、元請会社に提出しているものであることからすれば、別紙3記載の項目に係る情報については、作業員からユーザーの労務管理一般のために提供されることが想定されているものであるといえる。②現に、元請会社の中には、協力会社及び各作業員から、工事施工に関して取得する個人情報があり、それについては、施工監理、安全管理の遂行、連絡及び建設業法、労働安全衛生法等の関係法令の要望事項を履行するために利用することなどを公表している事業者が見受けられる…。③そして、申立人の営業担当部長も、ユーザーは社会通念上、自社の作業員から雇用契約等で自社の事業活動のために作業員の個人情報を利用することについて同意を得ていると考えられると述べているところである…。以上の事情を総合すると、提供先ユーザーが登録した作業員情報については、当該作業員は、自身の安全や仕事の遂行に関わる個人情報である当該情報を、自らに対する労務安全管理のために必要であることから、自己の雇用主等に提供(伝達)していることが一応認められ、当該作業員は、その提供(伝達)の際、提供先ユーザーが、当該作業員の労務安全管理のために、当該情報を取得及び利用することに黙示的に同意しているものと一応推認される。そして、当該作業員が、本件サイトにおける利用のためだけに限定して当該情報を提供(伝達)した事実は認められず、上記推認を覆すに足りる疎明資料はない。/したがって、本件命令主文第1項の申立人から提供先ユーザーの当該情報の提供については、本人の同意があると一応認められ、申立人が本件命令に従っても個人情報保護法27条1項に違反することにはならず、申立人の上記主張は採用することができない。」

個情法19条関係

「申立人は、本件命令(主文第1項)により、提供先ユーザーに第三者提供を行おうとする際に、提供先ユーザーが他社サービスの運営事業者に対して個人情報保護法27条1項に違反して個人情報データの提供を行うことが予見できるにもかかわらず当該提供先ユーザーに個人情報データを提供することとなり、個人情報保護法19条に違反する行為を強制されると主張する。/しかしながら、〔個情法27条1項に関する判示部分〕で説示したところによれば、①実務上、労務管理一般のために作業員情報が提供されることが求められており、作業員も、自身の労務安全管理のために、当該作業員情報が利用されることに黙示的に同意しているものと一応推認され、これが本件サイトにおける利用のみに限定された同意であるとは認め難い。このほか、②申立人の競争事業者である株式会社≪A≫及び≪B≫株式会杜も、それぞれの利用規約において個人情報を適切に取り扱うことを規定しているところ…、一件記録に照らしても、申立人の運営する本件サイトと、申立人の競争事業者が運営するクラウドサービスは、いずれも作業員の労務安全管理のためのツールを提供するものであるところ、両者について、作業員が、前者で利用されることには同意するが後者で利用されることには同意しないと区別しているとみるべき事情はうかがわれないこと、③もとより、ユーザーは、(1)作業員情報が記載されたPDF形式の帳票(作業員名簿)を自ら本件サイトから出力することにより当該作業員情報の提供を受けることができる上、(2)その内容を他社サービスの利用のために用いること(そのファイル形式をOCR技術の利用や手作業によりPDFファイルからCSVファイル等に適宜修正した上で、当該作業員情報を申立人に競争事業者に提供すること)もできるところ、申立人も、上記(1)を個人情報保護法違反とはしていないし、上記(2)を禁止してもいないこと…をも総合すると、作業員は、自己の作業員情報を本件サイトに登録した提供先ユーザーが、当該作業員に対する労務安全管理のために他社サービスにおいて利用すべく、申立人から当該作業員情報を取得することについても、黙示的に同意している蓋然性が相当程度あるといえる。そうすると、申立人が本件命令に従って提供先ユーザーに作業員情報を提供することが、提供先ユーザーが他社サービスの運営事業者に対して個人情報保護法27条1項に違反して個人情報の提供を行うことが予見できるにもかかわらず当該提供先ユーザーに個人情報を提供することにはならず、違法又は不当な行為を助長又は誘発するおそれがあるとは認められないというべきである。/さらにいえば、申立人の競争事業者が運営するサービスにおける利用について作業員の同意があるならば、申立人がいう個人情報保護法19条違反は問題にならないというだけでなく、仮に同意がないのであれば、その同意を提供先ユーザー又は当該競争事業者が取得すればよいのであって、申立人は、そのようにするよう提供先ユーザーに注意喚起することもできる。そうした場合に、申立人が個人情報保護法19条違反に問われることは、ますます考え難い。」

解説

独禁法の文脈*1

独禁法は、公正かつ自由な競争を促進するため、それを阻害する各種の行為を禁止する法律である(裏を返せば、独占それ自体を禁止する法律ではない。)。独禁法の規制は、形式的には、①私的独占の禁止(2条5項、3条)、②不当な取引制限の禁止(2条6項、3条)、③不公正な取引方法の禁止(2条9項、19条、一般指定*2)、④企業結合規制(第4章。株式取得であれば10条が適用される。)に分けられる。①の典型例は、NTT東日本事件やJASRAC事件のような他者排除である。②の典型例は、カルテルや入札談合のような競争停止行為である。③には様々な行為が含まれるが、大きく、他者排除(私的独占と比べると違反要件が緩和されている。)、搾取(=優越的地位濫用)、不正手段に分けられる*3。一般指定14項の取引妨害には、他者排除と不正手段の双方がありえ、それによって「不当に」の解釈が異なるが(前者の場合、排除効果を認定する必要がある。)、MCDPの行為は前者に属すると思われ、実際、排除措置命令書は排除効果を認定している(排除措置命令書理由第1の3)。

本件における個情法上の争点の独禁法の位置づけを理解する上では、公取委の「官公庁における情報システム調達に関する実態調査報告書」の次の記述が役に立つ。すなわち、「既存ベンダーが、官公庁(作業に関連する他のベンダーを含む。)に対し、合理的な理由が無いにもかかわらず、他のベンダーに対して仕様の開示を拒否すること、他の情報システムとの接続を拒否すること、又は既存システムから新システムへのデータ移行を拒否すること(事実上拒否するのと同視し得る程度に高額なデータ移行のための費用を請求する場合を含む。)などにより、他のベンダーが、官公庁の情報システムに関する入札に参加することや受注することができないようにさせる場合や、受注後の作業の遂行に支障が出るようにさせる場合には、独占禁止法上問題となるおそれがある(取引妨害)。/どのような場合に合理的理由が無いと判断され得るかについては、例えば、既存ベンダーが新規ベンダーを排除することを目的として、合理的な算定根拠がなく、簡単にデータの出力ができるにもかかわらず、仕様の開示や接続のために高額な費用を請求すること、知的財産権やノウハウとは無関係な部分であるにもかかわらず、それらを理由として開示等を拒否することなどが考えられる。」*4。この「知的財産権やノウハウ」が個人情報保護に置き換わったのが本件だと考えられる。

個情法の文脈*5

個情法は、個人の権利利益を保護するため、個人情報取扱事業者*6(以下個情法の文脈であることが明らかである場合には、単に「事業者」ということがある。)に個人情報の取扱いの適正化のための義務を課す法律である(裏を返せば、個人情報の保護それ自体を目的とする法律ではない。)*7。個情法は、独禁法と比較すると、(禁止規定ではなく)具体的な義務規定を中心とする、いわゆる業法(例えば、電気通信事業法、資金決済法、医薬品医療機器等法)に近い規定ぶりの法律であるが、根幹となるのは、利用目的による制限、不適正利用の禁止、第三者提供制限であり、本件にも、専らこれらの規定が関係する。以下説明する。

まず、利用目的による制限について。事業者は、個人情報を取り扱うに当たっては、利用目的を特定しなければならない(個情法17条1項)。利用目的の変更は、「変更前の利用目的と関連性を有すると合理的に認められる範囲」でのみ認められる(同条2項)。事業者は、あらかじめ本人の同意を得ないで、利用目的の達成に必要な範囲を超えて、個人情報を取り扱ってはならない(同法18条1項)。ただし、法令に基づく場合、生命・身体・財産保護に必要な場合、公衆衛生・児童健全育成に特に必要な場合等には、例外が認められる(同条3項)。事業者は、個人情報を取得する場合、利用目的を本人に通知し又は公表しなければならない(同法21条1項、2項)。利用目的による制限は、「個人情報がみだりに取り扱われることを制限することを通じて、本人の権利利益の侵害を未然に防止しようとするもの」*8であり、個情法の最も基本的なルールとされている*9。利用目的は、利用目的による制限(や正確性確保義務(同法22条))の適用の基準となる*10という意味で、「個人情報の取扱いに関する規律の要」*11であり、透明性を確保し、本人の権利行使の機会を保障するため、通知・公表が義務付けられている*12。

次に、第三者提供制限について。事業者は、例外事由がある場合を除き、あらかじめ本人の同意を得ないで、個人データを第三者に提供してはならない(個情法27条1項)。例外事由は、概ね利用目的による制限と同様のものが規定されている*13。第三者提供制限は、利用目的による制限の特則であり*14、「特に電子的に処理することが容易な個人データが本人の意思にかかわりなく第三者に提供されれば、本人の全く予期しないところで当該個人データが利用されたり、他のデータと結合・加工されるなどして、本人に不測の権利利益侵害を及ぼすおそれが高まることとなる」*15ことから、第三者提供を一律に目的外利用とみなしたものと考えられる*16。

一方、①委託に伴う提供、②事業承継に伴う提供、③共同利用者への提供については、受領者は、第三者に該当しないものとされている(個情法27条1項)。これらの場合は、「形式的には第三者に該当するものの、その取扱いの態様、本人の権利利益侵害のおそれの程度等からみて、本人との関係では、個人情報取扱事業者と一体のものとしてとらえることが適当かつ合理的である場合」*17ないし「本人の信頼を裏切らない」場合*18と説明されている。このような意味での一体性を担保するため、①委託においては、委託元に監督義務が課され(同法25条)、②事業承継においては、利用目的が承継され(同法18条2項)、③共同利用については、共同利用を行う旨、共同利用されるデータ項目、共同利用者の範囲、共同利用の目的、責任者(苦情処理を行い、権利行使の相手方となる者)の名称等を事前に通知・公表*19することが要件とされている。本件では、MCDPとユーザー企業は、サービス利用規約40条3項に従って通知・公表を行い、共同利用を行っていたものと思われる。

最後に、不適正利用の禁止について。事業者は、違法又は不当な行為を助長し、又は誘発するおそれがある方法により個人情報を利用してはならない(個情法19条)。この例として、通則ガイドライン上、「個人情報を提供した場合、提供先において法第27条第1項に違反する第三者提供がなされることを予見できるにもかかわらず、当該提供先に対して、個人情報を提供する場合」*20等が挙げられている。本件では、MCDPは、MCDPがユーザーに個人データを提供すると、当該ユーザーが、同法27条1項に違反して競争者に当該個人データを提供することが予見できるから、そのような状況でMCDPがユーザーに個人データを提供することは、同法19条に違反する旨主張していた。

以上を前提に、裁判所の判断を見ていくこととする。

個情法27条1項について

この点に関する申立人の主張は、「ユーザーが作業員情報を利用できる目的は、申立人のサービスにおける利用に限定されているから」、「本人の事前の同意を得ないまま作業員情報を提供すること」は個情法27条1項に違反する、というものであった。これに対し、決定は、作業員は、自己の雇用主等に個人情報を提供する際、「提供先ユーザー(注:「雇用主等」と同一であると思われる。)が、当該作業員の労務安全管理のために、当該情報を取得及び利用することに黙示的に同意している」ことを理由に、同項違反はないとした。ここでは、個情法27条1項について、共同利用の目的以外の目的のための提供は、共同利用の相手方に対する提供であっても、同条5項3号の要件を満たさない、との解釈(同号の文言からは必然的なものではない。)が前提とされているように思われる。

しかしながら、このような解釈は適切ではないと思われる。

第1に、個情法27条1項や5項3号は、文言上、利用目的を問題としておらず、共同利用者の一人(である事業者)が共同利用の目的以外の目的のための利用(提供を含む。)を行う場合でも、当然には同法27条1項に違反するものではない。本決定は、意識的にであるかどうかは別として、個情法27条5項3号に、個人データが共同の利用目的の達成に必要な範囲で提供されること、という要件を解釈によって付け加えたかのような判示になっている。しかしながら、個情法27条1項は、あえて利用目的の達成に必要な範囲内であるかどうかを無視して、専ら法人格の「越境」に着目した規制を課しているのであり、そうであるとすれば、共同の利用目的の達成に必要な範囲であるかどうかは、同条5項3号ではなく、同法18条1項の問題と考えるべきではないか。

第2に、個情法18条1項の問題と考えた場合、まずは、提供が共同利用の目的による制限の達成に必要な範囲内かを検討すべきであるが、サービス利用規約40条3項の(1)②(イ)は、共同利用の目的として、「「建設サイト・シリーズ」として提供される、建設工事に係る業務の効率化を目的としたサービス…の利用のため」を定めており、サービスの利用中止に伴うデータのエクスポートは、当然、これに含まれると解される。そうであるとすれば、個情法18条1項の問題としても、同意を検討する必要はなかったのではないか。

以上に述べたところに従えば、申立人の主張に対する応答は、「個情法27条5項3号は、共同利用者を同条1項の第三者に該当しないものとしているから、本人の事前の同意を得ないまま作業員情報を提供先ユーザーに提供することは、同項に違反しない。また、サービス利用規約40条3項に照らすと、「建設サイト・シリーズ」の利用中止に伴うデータのエクスポートは、共同利用の目的の範囲内であるから、このような提供は、個情法18条1項の規定にも違反しない。」となり、必要な事実認定としては、サービス利用契約のみで足りたと考えられる。

個情法19条について

この点に関する申立人の主張は、「提供先ユーザーに第三者提供を行おうとする際に、提供先ユーザーが他社サービスの運営事業者に対して個人情報保護法27条1項に違反して個人情報データの提供を行うことが予見できるにもかかわらず当該提供先ユーザーに個人情報データを提供すること」は個情法19条に違反する、というものであった。これに対し、決定は、「作業員は、自己の作業員情報を本件サイトに登録した提供先ユーザーが、当該作業員に対する労務安全管理のために他社サービスにおいて利用すべく、申立人から当該作業員情報を取得することについても、黙示的に同意している蓋然性が相当程度ある」から、そのような場合には当たらないとし、さらに、「仮に同意がないのであれば、その同意を提供先ユーザー又は当該競争事業者が取得すればよい」と付け加えた。

この点については、MCDPと競争者のサービスの双方が共同利用によっていたことを前提とすると、(提供先)ユーザーによるサービスの乗り換えは、ユーザーがMCDPとの共同利用を離脱し、共同利用していた個人データについて、新たに競争者との共同利用を開始することを意味する。このような場面について、通則ガイドラインは、「既に特定の事業者が取得している個人データを他の事業者と共同して利用する場合には、当該共同利用は、社会通念上、共同して利用する者の範囲や利用目的等が当該個人データの本人が通常予期し得ると客観的に認められる範囲内である必要がある。」*21としている。本件にこれを当てはめると、決定文中の「作業員も、自身の労務安全管理のために、当該作業員情報が利用されることに黙示的に同意しているものと一応推認され」は、「作業員も、自身の労務安全管理のために、当該作業員情報が利用されることを通常予期し得る」と読み替え可能であると思われるから、そのような新たな共同利用の開始は適法であると考えられる。そうであるとすれば、提供先ユーザーがMCDPから提供された個人データを競争者に提供する行為は、個情法27条1項にいう「第三者」に対する提供に該当しないから、MCDPの提供が同法19条に違反することもない、と言えば足りたのではないかと思われる。

同意の認定について

以上のとおり、本件で同意を認定する必要は本来なかったと考えられるが、一方で、本決定における同意の認定方法は、個情法における同意の位置づけを考える上で興味深いので、検討する。

本決定には、「自社の作業員から雇用契約等で自社の事業活動のために作業員の個人情報を利用することについて同意を得ている」、「当該作業員は、その提供(伝達)の際、提供先ユーザーが、当該作業員の労務安全管理のために、当該情報を取得及び利用することに黙示的に同意している」といった記述が含まれる。このような黙示的同意、契約による同意、雇用主に対する同意は、現在の個情法実務の下では、必ずしも不自然なものではなく、むしろしばしば行われている整理だと思われる。通則ガイドラインも、「本人が同意に係る判断を行うために必要と考えられる合理的かつ適切な方法」*22が必要であること以上のことは述べていない。

一方、EUにおいては、民間主体が広く依拠しうる法的根拠(処理が適法となる場合)として、同意、契約履行(契約上の必要性)、正当利益が規定され(GDPR 6条1項(a)(b)(f))、それぞれ解釈が発達している。すなわち、同意には、任意性、個別性、インフォームド性(情報に基づくこと)、明確性が求められ、契約と同意の抱き合わせや、複数の処理目的の抱き合わせ、雇用関係のような力の不均衡は、同意の無効をもたらす可能性が高い*23。契約履行においては、契約上の義務の履行のために客観的に必要な処理のみが適法化される*24。正当利益は、処理が正当利益の追求に必要であり、かつデータサブジェクト(日本法でいう「本人」)の利益が正当利益に優越しない場合に利用可能であり、比較衡量に当たっては、データサブジェクトの合理的予測*25が重要な考慮要素とされる*26。労務管理は、正当利益が適切である可能性が高いとされる場面の典型である。

今般の個情法の3年ごと見直しでは、個情委は、利用目的による制限や第三者提供制限の例外事由として、契約履行を導入することを検討している。日本法の同意が緩やかに解されているのは、日本法がそれらの例外事由として契約履行(や正当利益)を持たず、私法上の意思表示や合理的予測をもって(黙示の)同意と評価する必要があるからであると思われる。それ自体は現行法の下ではやむを得ないとしても、それによって、同意が形骸化している側面は否定できず(しばしば指摘される「同意疲れ」は、具体的なリスクのない場面で同意を求められたり、情報提供が不十分なため同意すべきかどうかの判断がつかない状態で同意を求められたり、「抱き合わせ」により特定の利用を拒否したい場面でも拒否できないことに起因している面も相当程度あると思われる。)、例外事由が分化することで、それぞれの性質に応じた規律が可能となると考えられる。

共同利用について(本決定を離れた検討)*27

本件では、MCDPや競争者が共同利用者とされていることについて、特段の問題提起はなされていない。しかしながら、個情法実務からすれば、この種のサービスにおける個人情報取扱いは、委託と構成するのが通常であり、共同利用と構成することは一般的ではないように思われる。以下、この点について検討する。

まず、法律とガイドラインを確認する。個情法27条5項3号は、「特定の者との間で共同して利用される個人データが…」としており、文言上は、共同利用者間に何らかの実質的関係があることを要求していない。通則ガイドラインは、「「共同利用の趣旨」は、本人から見て、当該個人データを提供する事業者と一体のものとして取り扱われることに合理性がある範囲で、当該個人データを共同して利用することである。/したがって、共同利用者の範囲については、本人がどの事業者まで将来利用されるか判断できる程度に明確にする必要がある。」としているが、明確にしさえすれば、個人データの共同利用以外に「共同」性の認められない者の間であっても個情法27条5項3号が適用されるかのように見える。

ところで、GDPRには、ジョイントコントローラーの制度がある。コントローラーとは、日本法でいう個人情報取扱事業者のうち、他の個人情報取扱事業者の委託先であるものを除いたものに相当し、単独で又は共同して個人データ処理の目的と手段を決定する者と定義されている(GDPR 4条7項)。この「共同して」決定を行うコントローラーがジョイントコントローラーである。これは、共同利用に一見類似するが、実際の機能は全く異なる。すなわち、日本法の共同利用は、既に述べてきたとおり、共同利用者の一体性に着目して、第三者提供制限の適用を除外するものであるが、EUのジョイントコントローラーは、刑法の共同正犯類似の、共同責任を負わせるための概念である(なお、EU法には特別の第三者提供制限は存在せず、第三者への開示は、有効な同意に基づいているか、契約履行や正当利益の追求に必要か、(正当利益であれば)データサブジェクトの利益が優越しないかといった観点から結果として厳格な規律を受けるに過ぎない。)。したがって、GDPRのジョイントコントローラーの制度は、前段落に述べた問題を考える上では、直接の参考とはならない。

一方で、個情委が挙げる「共同利用に該当する事例」は、「グループ企業で総合的なサービスを提供するために取得時の利用目的…の範囲内で情報を共同利用する場合」、「親子兄弟会社の間で取得時の利用目的の範囲内で個人データを共同利用する場合」、「使用者と労働組合又は労働者の過半数を代表する者との間で取得時の利用目的の範囲内で従業者の個人データを共同利用する場合」であり、これらは、GDPRにおいては、正当利益により処理が適法化される場面の典型である。その上で、通則ガイドラインの関連する記載を見ると、①「既に特定の事業者が取得している個人データを他の事業者と共同して利用する場合には、当該共同利用は、社会通念上、共同して利用する者の範囲や利用目的等が当該個人データの本人が通常予期し得ると客観的に認められる範囲内である必要がある。」、②「「共同利用する者の利用目的」については、社会通念上、本人が通常予期し得る限度と客観的に認められる範囲内…で変更することができる。」、③「共同利用者の範囲については、本人がどの事業者まで将来利用されるか判断できる程度に明確にする必要がある。」との記載が含まれていることが分かる。これらの記載は、一貫して、共同利用の限界を合理的予測によって画そうとしているといえ、そうであるがゆえに、個情委が挙げる事例は、いずれも正当利益(先に述べたとおり、データサブジェクトの合理的予測が重要な考慮要素となる。)に親和的なものとなっているのではないか。①は単独で収集した個人データを共同利用する場面、②は利用目的の変更の場面*28、③共同利用者の名称を個別に列挙しない場面に関するものであり、いずれも共同利用そのものの限界を示したものではないが、共同利用を第三者から除外した趣旨から導かれた解釈であり、共同利用そのものの限界についても、同様に考えてよいのではないか。

このように考えると、本件では、雇用主が労務管理目的で従業員の個人データを取り扱うことについては、「社会通念上、本人が通常予期し得る」(合理的予測がある)と言え、建設(元請け、1次請け、2次請け…という下請けの連鎖が行われ、建設現場には様々な者に雇用された者が集合する。)のような場面では、労務管理に必要な範囲で個人データが共有されることについても、「社会通念上、本人が通常予期し得る」と言えると思われる*29。一方で、そのために使用されるクラウドサービスは、労務管理という文脈上必須のものではなく(言い換えれば、従業員とMCDPの関係は希薄であり)、雇用主がそれを利用する場合、雇用主が自らの責任でサービスを管理することを期待するのが通常であり、このことは、それと異なる内容の取扱いをすることを通知・公表したという事実のみによって変わるものではないと思われる。そうであるとすれば、クラウドサービス提供者との共同利用は、「社会通念上、本人が通常予期し得る」ものではない、と言い得るのではないか*30。

なお、共同利用の限界を巡っては、Tポイント事案が知られているが*31、これについても同様に考える余地があるように思われる。すなわち、ポイントプログラムは、企業から見れば、ポイント相当額を支払って顧客との継続的関係を築いたり、顧客に関するデータを収集し、マーケティングに活用する施策であり、共同ポイントプログラムは、当該施策の範囲を拡大することで、ポイントプログラム(言い換えれば、「ポイント経済圏」)それ自体の競争力を高めるとともに、それによって、より横断的なデータ収集・利用を可能にする施策である。しかしながら、企業としては、ユーザーに対してそのように「露骨な」説明はせず、専ら「お得」であることを訴求するのが通常である。このような状況においては、ユーザーが当該加盟店を利用したかどうか等にかかわらない広範囲な共同利用は、「社会通念上、本人が通常予期し得る」範囲を逸脱している、と言えるのではないか。

まとめ

本稿で述べたことを整理すると、以下のとおりである。

第1に、本決定は、ユーザーの従業員の黙示的同意を理由に、個情法27条1項及び19条違反を理由とする正当化を否定しているが、本件はそもそも同意が必要な場面ではない。同法27条に関する論点は、本来的には同法18条1項に関するものとして構成されるべきであったと思われるが、そのように構成したとしても同様である。

第2に、本決定に典型的に見られるような同意の認定は、現在の個情法実務の下では、必ずしも不自然ではないが、今後の個情法改正次第では、認められなくなる可能性がある。

第3に、共同利用の限界については、個情法上解釈が固まっておらず、そのためか本件でも争われていないが、実務上は、クラウドサービス提供者が共同利用者とされることは一般的ではない。個情委のガイドラインは、共同利用に関して、本人の予測可能性ないし合理的予測を重視した解釈を示しており、そこからすれば、本件のような共同利用は認められないとの解釈もありうるのではないか。

以上の議論は、独禁法違反の結論に影響を与えるものではないが、現在の我が国個情法を巡る論点が典型的かつ複合的に表れていると思われることから、検討を加えたものである。

*1:独禁法の基本文献として、菅久修一編著・品川武ほか著『独占禁止法〔第5版〕』(商事法務、2024)、白石忠志『独禁法講義〔第11版〕』(有斐閣、2025)、白石忠志『独占禁止法〔第4版〕』(有斐閣、2023)。本件に関する解説・評釈として、吉兼彰彦=川端龍徳「解説(排除措置命令)」公正取引892号(2025)、菅野みずき「評釈(排除措置命令)」ジュリスト1608号(2025)、西村暢史「評釈(排除措置命令)」NBL 1299号(2025)、渕川和彦「評釈(排除措置命令)」新・判例解説Watch 経済法 No.103(2025)、中島美香「判批(一審決定)」公正取引901号(2025)、大久保直樹「判批(一審決定)」ジュリスト1615号(2025)、白石忠志「判批(一審決定)」ジュリスト1615号(2025)、中島美香「判批(一審決定)」公正取引901号(2025)など。

*2:不公正な取引方法(昭和57年6月18日公取委告示第15号)のこと。

*3:公取委がこのうちどれに注力すべきかという問題(例えば、公取委の法執行は優越的地位濫用に偏っているが、それは中小企業政策に属するものであって、そのことによって、公取委の本来的任務である競争政策(反競争行為に対する法執行)が疎かになっているといった議論がされることがある。)は、個情法委が個情法の保護法益(例えば、個人に対する評価・決定の適切性、伝統的プライバシー、名簿屋に関連する問題)のうちどれに注力すべきかの問題と類似している。

*4:公取委「官公庁における情報システム調達に関する実態調査報告書」(令和4年2月)51頁。

*5:個情法の基本文献として、園部逸夫=藤原靜雄編『個人情報保護法の解説 第三次改訂版』(ぎょうせい、2022)(「園部藤原」)、藤原靜雄著『逐条 個人情報保護法』(弘文堂、2003)(「藤原」)。当局見解として、個情委「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和7年6月最終改訂)(「通則ガイドライン」)。

*6:「個人情報取扱事業者」は、法律上定義された語であるが、個人情報データベース等、すなわち個人情報を体系的に構成したものを事業の用に供する者として定義されている(業として個人情報を取り扱う者ではない。)(個情法16条1項、2項)。そのため、頭の中では、「個人情報データベース等供用(事業)者」と読み替えたほうが誤解が少ない。

*7:令和3年個情法改正の立案担当者は、「個人情報保護法性は、…様々な「個人の権利利益」を保護することを目的として、予防的に個人情報の取扱いに関する義務の遵守を求めるものであるため、「個人の権利利益を保護すること」の内容として「個人情報を保護すること」を例示することは適当ではありません。」と明言している(冨安泰一郎=中田響編著『一問一答 令和3年改正個人情報保護法』(商事法務、2021)98頁)。

*8:園部藤原151頁。

*9:園部藤原152頁。

*10:園部藤原147頁。

*11:園部藤原146頁。

*12:園部藤原147頁、167頁~168頁。

*13:園部藤原154頁。

*14:園部藤原196頁。

*15:園部藤原197頁。

*16:藤原84頁も参照。その背景には、第三者提供が行われた場合、受領者が事業者でない場合には個情法が適用されず(特に、平成15年の個情法制定時から平成27年改正までの間、いわゆる5000件要件が存在したため、小規模事業者には個情法が適用されなかった。)、事業者である場合も、「要」である利用目的が承継されない(同法18条2項はその例外である。)ことがあったものと思われる。また、現代においては、様々な企業が様々な情報源から個人データを収集・処理しているが、平成15年当時は、個人情報は基本的には本人から提供されるものという認識があったものと思われる(例えば藤原90頁。委託先を「本人が信頼して個人情報を提供した事業者自体ではない」としている。)。

*17:園部藤原213頁。

*18:藤原91頁。

*19:法文上は「本人が容易に知りうる状態に置くこと」。法文においては、公表(個情法21条1項)とは区別されているが(なお、同法32条の見出しも参照)、実務上は、まとめて「公表」と呼ぶことが多い。

*20:通則ガイドライン3-2。

*21:通則ガイドライン3-6-3。

*22:通則ガイドライン2-16。

*23:GDPR上の同意について、EDPB, Guidelines 05/2020 on Consent Under Regulation 2016/679 (May 4, 2020, rev. May 13, 2020)。

*24:GDPR上の契約履行について、EDPB, Guidelines 2/2019 on the Processing of Personal Data Under Article 6(1)(b) GDPR in the Context of the Provision of Online Services to Data Subjects (Oct. 8, 2019)、CJEU, Case C-252/21, Meta Platforms Inc. v. Bundeskartellamt, EU:C:2023:537 (Jul. 4, 2023)。Bundeskartellamt判決以降、「データサブジェクトのために意図された契約上の給付の不可分の要素となっている目的の達成に客観的に不可欠」という定式が確立している。

*25:Reasonable expectationの訳。米国憲法修正4条の文脈では、reasonable expectationは、「合理的期待」と訳されるのが一般的であるが、そこでは、プライバシーが保護されることへのexpectationが問題となるのに対し、GDPRの文脈では、特定の個人データ処理が行われることのexpectationが問題となるという違いがある。本文では、後者について、通則ガイドラインの「本人の予測を可能とする」、「本人が通常予期し得る」という表現を参考に、「合理的予測」を採用した。

*26:GDPR上の正当利益について、WP29, Opinion 06/2014 on the Notion of Legitimate Interests of the Data Controller Under Article 7 of Directive 95/46/EC (Apr. 9, 2014)、EDPB, Guidelines 1/2024 on Processing of Personal Data Based on Article 6(1)(f) GDPR (Oct. 8, 2024)。

*27:共同利用に関する実務的な文献として、岡田淳ほか「個人情報保護をめぐる実務対応の最前線(第4回)個人データの第三者提供と共同利用をめぐる論点(2)」NBL 1210号72頁(2022)、松本亮孝「実務問答 個人情報保護法(第5回)共同利用」NBL 1260号82頁(2024)、寺門峻佑ほか「デジタルマーケティングの法律相談(第4回)個人情報保護法(3)第三者提供の諸論点(同意・記録・共同利用)」ビジネス法務2025年9月号139頁(2025)。

*28:通則ガイドライン3-1-2も参照。

*29:大久保・前掲注(1)は、「異なるユーザーによって登録された情報が突合されてデータ項目が増やされることもある」ことから「「委託」として議論することは難しかった」可能性を指摘しているが、このことは、関係する各建設業者を共同利用者とすべき理由にはなっても、MCDPを共同利用者とすべき理由にはならないと思われる。

*30:この問題は、ある意味、スタディサプリ事案(那須翔「個人情報保護法の論点」JILISレポート7号5頁参照)と鏡合わせである。すなわち、本件では、プロセッサーとなるべき者がコントローラーとなっているのではないか、スタディサプリ事案では、コントローラーとなるべき者がプロセッサーなっているのではないかが問題となった。もっとも、これらの問題の解決方法は、鏡合わせである必要はない。

*31:詳細については、岡田ほか・前掲注(27)74頁、松本・前掲注(27)86頁。本件では、当局は少なくとも表立っては行動を起こさなかった。

デジタルオムニバスGDPR改正法案の理論的意義

Researchmapに掲載していたペーパーを転載します。PDF版はResearchmapをご参照ください。

 

1 はじめに

欧州委員会は、今年11月19日、デジタルオムニバス法案を公表した。同委員会は、今年2月11日、J.D. VanceがAIアクションサミットで演説を行ったのと同日、“A simpler and faster Europe: Communication on implementation and simplification”と題する政策文書*1において、EUのデジタル法制の簡素化・整理に向けて行動することを表明しており、本改正案は、その最初のアウトプットである。

デジタルオムニバス法案は、複数の法案を一括して改正する法案であり、データ関連法制の見直し(特にデータ法は大幅な修正の対象となる。)、個人データ保護法制の見直し、インシデント報告の統合等を含む。

このうち、GDPRに関する部分は、大きく、①個人データの定義の明確化、②特別カテゴリデータ処理に関する新たな例外、③アクセス権の濫用への対応、④情報提供義務の簡素化、⑤自動決定に関する明確化、⑥データ侵害通知義務の緩和・簡素化、⑦DPIAの要否や手法の統一、⑧仮名化データの再識別リスク評価基準の明確化、⑨端末設備上の個人データ処理、⑩AI開発・運用において正当利益に依拠しうることの明確化、からなる。本稿では、このうち、理論的に重要な意義を有すると思われる、①②⑤⑨⑩について紹介しつつ、理論的な観点から分析を加える。

なお、本稿の「改正後条文案」の下線は、変更箇所を示し、それ以外の箇所(「Recital案」を含む。)の下線は、単なる強調である。

2 個人データ概念と仮名化データの識別性

(1) 改正後条文案

第4条 定義

この規則において、

(1) 「個人データ」とは、識別された、又は識別され得る自然人(「データサブジェクト」)に関するあらゆる情報をいう。識別され得る自然人とは、特に氏名、識別番号、位置データ、オンライン識別子、又は当該自然人の身体的、生理的、遺伝的、精神的、経済的、文化的、又は社会的なアイデンティティに特有の一つ以上の要素を参照することにより、直接的又は間接的に識別され得る者をいう。自然人に関する情報は、他のエンティティがその自然人を識別できるという理由のみによって、常に他の全ての者又はエンティティにとって個人データとなるわけではない。情報は、あるエンティティが合理的に使用する可能性の高い手段を考慮して、当該エンティティが当該情報に関連する自然人を識別できない場合、当該エンティティにとっては個人データではない。そのような情報は、潜在的な後続の受領者が、当該情報に関連する自然人を識別するために合理的に使用される可能性が高い手段を有するという理由のみによって、当該エンティティにとって個人データとなるわけではない。

(2) Recital案

(27) 本規則は、同等の水準のデータ保護を維持しながら、明確化及び簡素化のための規則(EU)2016/679への対象を絞った一連の改正を提案する。規則(EU)2016/679第4条は、個人データとは、識別された又は識別可能な自然人に関するあらゆる情報であると規定している。データサブジェクトの識別を可能とする追加情報が存在する場合でも、そのこと自体によって、常に、かつ全ての者又はエンティティに対して、仮名化されたデータが規則(EU)2016/679の適用上個人データとみなされなければならないわけではない。特に、あるエンティティが当該情報の関連する自然人を識別するために合理的に使用される可能性のある手段を保有しない場合には、当該情報はそのエンティティにとって個人データとはみなされないことを明確にする必要がある。後に当該情報が、他の保有データとの照合などにより、当該情報の関連する自然人を識別することを合理的に可能とする手段を保有する第三者に提供され得る場合、その情報は、当該手段を保有するその第三者にとってのみ個人データとなる。あるエンティティにとって当該情報が個人データではない場合、原則として、そのエンティティは規則(EU)2016/679の適用範囲に含まれない。この点に関し、欧州連合司法裁判所は、データサブジェクトの識別に関するリスクが現実には無視できる程度に低く、当該データサブジェクトの識別が法律により禁止されているか、又は、時間、費用、労力の観点から不均衡な負担を伴うために実際上不可能である場合には、識別手段が合理的に使用される可能性があるとは言えないと判示している。再識別の禁止の例としては、欧州議会及び理事会規則(EU)2025/327第61条3項に定める医療データ利用者の義務が挙げられる。欧州委員会は、欧州データ保護委員会とともに、実施行為において技術的基準を規定することにより、この更新された定義の適用においてコントローラーを支援すべきである。

(3) 解説
ア 改正の内容

本改正案は、個人データの定義自体を変更することなく、個人データの識別性の認定方法に関する記述を追加するものである。追加される記述は、3つの文からなる。第2文は、個人データ該当性は、GDPRの適用が問題となるエンティティが使用する可能性の高い手段を考慮して判断すべきことを述べている。第1文・第3文は、第2文の帰結とも言うべき内容で、第1文は、ある情報について、あるエンティティが識別手段を有することが、直ちに他のエンティティにとって当該情報が識別性を有することを意味しないこと、第3文は、データの開示(日本法で言えば第三者提供)の場面において、受領者(提供先)が識別手段を有することが、直ちに開示を行う者(提供元)にとって当該情報が識別性を有することを意味しないことを述べている。

イ SRB事件判決と仮名化データの個人データ該当性

本改正案の背景にあるのは、SRB事件判決*2である。同事件は、欧州における大規模な銀行の破綻処理を担う単一破綻処理委員会(SRB)が、スペインの銀行Banco Popular Españolの破綻処理に当たり、SRBが収集した株主及び債権者の意見書を、仮名化の上、単一破綻処理メカニズム(SRM)規則上の独立評価者として選任されたDeloitteに開示したという事案に関する。EU機関の個人データ処理を監督するEDPSは、株主及び債権者の苦情申立てに基づき、SRBがDeloitteに対する開示について情報提供を行わなかったことが、規則(EU)2018/1725第15条1項(d)(GDPR第13条1項(e)に相当)違反に該当するとして、SRBに対し是正勧告を行ったところ、SRBが、一般裁判所*3に異議訴訟を提起した。一審を管轄する一般裁判所は、情報提供義務の適否について、Deloitteにとっての識別性を問題とし、同事案ではそれがないとしてSRBの主張を支持したが、上訴審に当たる司法裁判所は、SRBにとっての識別性を問題とし、同事案ではそれがあるとしてEDPSの主張を支持した。EU法には日本法でいう第三者提供制限はなく、法文上「第三者提供」が特別扱いされているのは、主として情報提供義務(受領者又はそのカテゴリを情報提供する必要がある。)の場面であるところ、本件はいわば「提供元基準説 vs 提供先基準説」論争のEU版であり、CJEUは、我が国と同様の立場(つまり、提供元基準説)を示したものと言える*4。

SRB事件判決は、上記のような帰結であったので、その点(転載時の注:Deloitteが受領したデータがDeloitteにとって個人データに該当するものであったか)について積極的には判断していなかった。本改正案は、法文本体で、「合理的に使用される可能性のある全ての手段」基準(GDPR Recital 26に既に示されていた。)を確認し、当該基準の適用がエンティティごとに異なりうること(相対的基準説。Breyer判決*5以来累次の判例で繰り返されてきた*6。)を確認し、それらの帰結として、Recitalにおいて、仮名化データは常に個人データに該当するわけではないことを新たに明示している。

ウ 識別とは何か―残された問題

ところで、本改正案は、個人データの識別性とは何かを示していないように思われる。「合理的〜手段」は考慮要素であって、判断基準そのものではない。WP29は、個人データ保護指令(DPD)下で、識別性とは個人をsingling outできることだとし*7、GDPR Recital 26は、「合理的〜手段」の例という形でsingling outに言及し、CJEUも、自動車の車台番号*8やオンライン広告の同意管理用の識別子*9の文脈では、これに親和的な判断を示しているようにも思われるが、EDPBやCJEU自身が「識別性とはsingling outできることである」(あるいは「singling outできる場合には識別性が認められる」)旨を明言したことはない*10。匿名化や仮名化とは識別性を失わせることであり、その意味でも、識別性の解釈はなお重要な問題として残ることになる。

エ 日本法への理論的影響

本改正案の日本法への理論的な影響は、ひとまずは限定的であると思われる。日本においては提供元基準説はリクナビ事案に際して解決済みであり、相対的基準説も当然の前提とされてきたと思われるからである*11。一方で、識別性概念の解釈は日本法でも未解決であり、引き続き検討が必要である*12。

3 AI開発と正当利益

(1) 改正後条文案

第88c条 AIの開発及び運用の文脈における処理

AIシステム(規則(EU)2024/1689第3条(1)に定義されるもの)又はAIモデルの開発及び運用の文脈において、コントローラーの利益のために個人データの処理が必要な場合において、それが適切である場合には、規則(EU)2016/679第6条1項(f)の意味における正当な利益のために当該処理を追求することができる。ただし、他の連合法又は国内法が明示的に同意を要求する場合、又は当該利益がデータサブジェクトの利益又は個人データ保護を必要とするデータサブジェクトの基本的権利及び自由によって優越される場合(特にデータサブジェクトが子供である場合において)はこの限りでない。

当該処理は、情報源の選択段階及びAIシステム又はAIモデルの訓練及びテストの段階においてデータ最小化を確保すること、AIシステム又はAIモデルに残留的に保持されるデータの不開示を確保すること、データサブジェクトに対する透明性を強化すること、及びデータサブジェクトに自己の個人データの処理に対して無条件で異議を述べる権利を付与することなど、データサブジェクトの権利及び自由のための適切な組織的・技術的措置及びセーフガードの対象とならなければならない。

(2) Recital案

(30) 信頼できるAIは、経済成長を実現し、社会的に有益な結果を伴うイノベーションを支えるための重要な要素である。AIシステム及び大規模言語モデルや生成動画モデルのような基盤モデルの開発及び使用は、AIライフサイクルの訓練段階、テスト段階及び検証段階など、様々な段階においてデータ(個人データを含む)に依拠し、場合によってはデータがAIシステム又はAIモデル内に保持されることがある。この文脈における個人データの処理は、適切な場合には、規則(EU)2016/679第6条の意味における正当な利益の目的のために実施される可能性がある。このことは、コントローラーに対し、AIを特定の文脈又は特定の目的で開発又は使用(配備)する場合に、他のEU法又は国内法に適合すること、又はその使用が法令により明示的に禁止されている場合には適合性を確保する義務に影響を及ぼすものではない。また、規則(EU)2016/679第6条1項(f)の他の全ての条件及び同規則の他の全ての要件と原則が満たされることを確保する義務にも影響を及ぼさない。

(31) コントローラーが、本規則に基づく義務の拡張性を導くリスクベースアプローチに照らして、コントローラー又は第三者が追求する正当な利益と、データサブジェクトの利益、権利及び自由との均衡を図る場合、コントローラーが追求する利益がデータサブジェクト及び社会全体にとって有益であるかどうかを考慮するべきである。例えば、個人データの処理がバイアスを検出して除去するために必要であり、そのことによってデータサブジェクトを差別から保護する場合、又は個人データの処理が、特定のサービスへのアクセシビリティの向上のような有益な利用のために、正確で安全な出力を確保することを目的とする場合などがこれに該当し得る。また、データサブジェクトとコントローラーとの関係に基づくデータサブジェクトの合理的予測、データサブジェクトへの透明性の向上を提供すること、個人データの処理に対する無条件の異議権を提供すること、第三者によるAI開発のためのデータ使用を制限するサービスに組み込まれた技術的指示を尊重すること、AI学習のための他の最先端のプライバシー保護技術の使用、逆流(regurgitation)、データ漏洩その他の意図された又は予見可能な行為に起因するリスクを効果的に最小化する適切な技術的措置の使用など、他の事項についても考慮するべきである。

(3) 解説
ア 改正の内容

GDPRは、個人データ処理に法的根拠を要求しており、民間事業者が一般的に依拠できるものとしては、同意、契約履行、正当利益が定められている(GDPR第6条1項(a)(b)(f))。特に、正当利益は、「処理が、コントローラーまたは第三者が追求する正当な利益の目的のために必要である場合。ただし、個人データの保護を必要とするデータサブジェクトの利益又は基本的権利及び自由によってその利益が優越する場合(特にデータサブジェクトが子供である場合において)を除く。」とされている(同項(f))。

本改正案は、AIシステム及びAIモデルの開発及び運用のための個人データ処理が正当利益により正当化され得ることを確認する規定を新設するものである。

追加される法文は2つのサブパラグラフからなる。前半は、AIシステム又はAIモデルの開発及び運用の文脈において、コントローラーの利益のために個人データ処理が必要な場合、当該利益が正当利益に該当すること、データサブジェクトの利益が優越する場合はこの限りではないことを述べている。これは、GDPR第6条1項(f)の繰り返しである。

後半は、組織的・技術的措置及びセーフガードを求め、①学習用データの最小化、②AIシステム又はAIモデルに残留的に保持されるデータの不開示、③透明性、④異議権(オプトアウト)を例示している。GDPRは、もともとコントローラーに個人データ保護のための組織的・技術的措置を求めているから(GDPR第24条、25条)、意味があるのは、例示部分である。Recital案は、この点を敷衍し、データサブジェクトとの関係から生じる合理的予測、データ使用を制限する技術的指示(robots.txtやその他の機械可読なメッセージを指すと思われる。)の尊重、逆流・漏洩等の防止(プロンプトのフィルタリング等を指すと思われる。)に言及している。

イ 背景―BfDIディスカッションペーパー、EDPBオピニオン、ケルン高裁決定

AI開発を巡るEU関係当局の態度は揺れている。まず、ドイツ・ハンブルク州データ保護監察官(HmbBfDI)は、2024年7月、ディスカッションペーパー(DP)を公表し*13、①LLM(large language models)に個人データは保存されておらず、したがって、LLMの保存(storage)は個人データ処理に該当しない、②学習と利用(推論)は個人データ処理に該当しうる、③LLMの学習時に違法な個人データ処理が行われたとしても、そのことは当該LLMの利用の適法性には影響を与えない、という立場を示した。ただし、このDPは、LLM開発における個人データ処理の法的根拠については詳述していなかった。

一方、EDPBは、同年12月、Opinion 28/2024を公表し*14、①AIモデルが匿名(=個人データ非該当)とみなされるのは、モデル自体の解析によって、又はクエリを通じて個人データを抽出・取得できる可能性が、無視できる程度(insignificant)である場合に限られる、②AIモデル開発時に個人データ処理が行われる場合、正当利益に依拠することが考えられるが、3段階テスト(正当利益の追求、必要性テスト、比較衡量テスト)が厳格に適用され、情報提供義務も免除されない、③違法な個人データ処理によって開発されたAIモデルを別の者(デプロイヤー)が利用する場合、デプロイヤーは開発時に違法な個人データ処理が行われていないことを確認する義務がある、という立場を取った。このうち、①③はHmbBfDIの解釈を否定するものであり、②に関する記述は、AIの用途(リスクはそこから生じる。)、従来型AIと生成AI、学習と利用(推論)を区別しない結果、極めて厳格な印象を与えるものとなっていた。

その後、2025年5月、ケルン高等裁判所*15は、NRW消費者センターがFacebook IrelandによるユーザーデータのLLM開発への利用の差止めを求めた事案で、正当利益の追求とそのための必要性を認めた上で、比較衡量に関し、①「データ処理の結果に関しては、判断に関連するのは、個人データを用いたAIのトレーニング及びその結果のみである…AIの後の「稼働」によって生じうる他の権利侵害(例えば偽情報、操作、その他の有害な実践)は、現時点では十分に予見可能ではなく、別途追及することができる」として、これらを比較衡量の対象から除外した上で*16、②本件では「以前から誰にでも公開されており、検索エンジンによっても発見可能であった個人データのみが影響を受ける」、「AIシステムは「データアーカイブ」と同一視できるものではなく、通常は確率計算のためのパラメータのみで構成される」として、データサブジェクトへの影響が基本的には小さいことを述べ、③「個人データのAIへの取り込みが、…AIの「稼働」時におけるこれらのデータの再構築可能性および出力のリスクを伴うことは考慮しなければならない」、「大規模な生成AIモデルは、説明(解釈)可能性・透明性に欠け、動作が不透明であり、このことは、被害者のデータに対する自己決定権を損なう可能性がある」、「AIからのデータの後の削除が限定的にしか可能でなく、AIの訓練が一度行われると、仮処分被申立人が訓練により追求した目的、すなわちモデルの開発を達成できる」ことを考慮する必要があるとしつつも、④データサブジェクトへの影響緩和措置として、(a)一定の識別性低減措置(Maßnahmen zu Deidentifizierung)*17が行われていること、(b)訓練データのセキュリティが確保されていること、(c)投稿ごとの非公開設定(無条件の異議権と同様の意味がある。)が可能であること、(d)十分な情報提供が行われたことを考慮し、正当利益の優越を認め、申立てを却下した(仮処分事件であったためCJEU付託は実施されなかった。)。ケルン高裁決定は、Opinion 28/2024と基本的には軌を一にしつつも、LLMの開発という場面に即した考慮要素を取捨選択することで、Opinion 28/2024と比べると現実的な内容となっており、本改正案で挙げられた組織的・技術的措置は、概ね本決定が挙げた(a)-(d)と同等である。

ウ 日本法からの評価

日本においては、内部利用について法的根拠は要求されていないから、「AI開発と正当利益」の問題は、そのままの形では当てはまらない。同等物があるとすれば、「AI開発と利用目的制限」であるが、この点に関連して、①従前から、統計作成それ自体を利用目的とする必要はないとされており*18、また、②2023年秋から行われている個情法の3年ごと見直しにおいて、要配慮個人情報の取得や個人データの第三者提供制限に関して、個情委は、「統計作成等、特定の個人との対応関係が排斥された一般的・汎用的な分析結果の獲得と利用のみを目的と」する場合について、「統計作成等であると整理できるAI開発等を含」め、「このような統計情報等の作成にのみ利用されることが担保されていること等…を条件に」、同意取得を不要とすることを提案している*19(これは、OpenAIに対する注意喚起*20において、要配慮個人情報の取得・学習を可能な限り回避すべきとしたことからの方針転換と言える。)。③AI開発のための個人データ処理が利用目的による制限の対象となるかについては、明示的な解釈は示されていないが、②の理由として、「特定の個人との対応関係が排斥された統計情報等の作成(注:AI開発を含む)や利用はこれによって個人の権利利益を侵害するおそれが少ない」*21ことが挙げられていること、第三者提供制限は利用目的による制限の特則であり、両者は保護法益を共通にしていること*22からすれば、同様に考えることができると思われる*23。端的に言えば、利用目的制限・第三者提供制限は、個人に対する評価・決定の適切性(や予測可能性)の確保を主たる目的としており、一方、統計作成もAI開発もそれ自体としてはそのような評価・決定を目的としていないのだから、これらの規制を及ぼす必要がない(仮にそのようにして開発された統計モデルやAIモデルを個人に適用する場合、当該行為に規制を及ぼせば足りる)、ということである。

このように考える場合、本改正案又はそれに関連するRecitalが挙げる影響緩和措置(セーフガード)のうち、学習用データの最小化やオプトアウトは不要となり(もちろん、安全管理措置や二次流通の防止は別途図られる必要がある。)、残留データの不開示のための措置は、少なくとも学習段階の処理としては必須ではないことになる。日本の立場からは、本改正案は、今般の3年ごと見直し以前の日本と同様に、保護法益を見失ったことで、個人データ保護法が対処すべきリスクとそうでないリスク(固定的である必要はないが、ある時点においては特定されたものである必要がある。)の区別がつかなくなっており、その結果、個人データ保護法上が要求すべき緩和措置を特定することが困難になっている、と評価されるのではないか。

4 生体認証・AI開発と特別カテゴリデータ処理

(1) 改正後条文案

第9条 特別なカテゴリの個人データの処理

1. 個人データのうち、人種的又は民族的出自、政治的意見、宗教的又は哲学的信条、又は労働組合への所属を明らかにするもの、並びに遺伝データ、自然人を一意に識別する目的でのバイオメトリックデータ、健康に関するデータ、自然人の性生活又は性的指向に関するデータの処理は、禁止される。

2. 第1項は、以下のいずれかに該当する場合には適用されない。

(a) データサブジェクトが、特定された一つ以上の目的のために当該個人データの処理について明示的な同意を与えている場合。ただし、連合法又は加盟国法が第1項に言及される禁止がデータサブジェクトによって解除されてはならないと定める場合を除く。

(b) 処理が、連合法又は加盟国法に基づき、又は加盟国法に従う団体協約に基づいて、適切なセーフガードを提供しつつ、雇用、社会保障及び社会保護法の分野において、コントローラー又はデータサブジェクトの義務の履行及び特定の権利の行使を目的として必要である場合。

(c) 処理が、データサブジェクトが身体的又は法的に同意を与えることができない場合に、データサブジェクト又は他の自然人の重要な利益を保護するために必要である場合。

(d) 処理が、政治的、哲学的、宗教的又は労働組合目的を有する財団、協会その他の非営利団体によって、その正当な活動の過程で適切なセーフガードとともに行われ、当該処理が当該団体の構成員又は元構成員、若しくはその目的に関連して当該団体と定期的に接触する者のみに関係し、データサブジェクトの同意なく当該団体外に個人データが開示されない場合。

(e) 処理が、データサブジェクトにより明らかに公にされた個人データに関係する場合。

(f) 処理が、法的請求の立証、行使又は防御のため、又は裁判所がその司法機能を行使する場合に必要である場合。

(g) 処理が、連合法又は加盟国法に基づき、追求される目的に比例し、データ保護の権利の本質を尊重し、かつデータサブジェクトの基本的権利及び利益を保障するための適切かつ具体的な措置を定めるものとして、重大な公共の利益の理由により必要である場合。

(h) 処理が、連合法又は加盟国法に基づき、又は医療専門家との契約に基づき、第3項に言及される条件及びセーフガードの下で、予防医療又は職業医学、従業員の勤務適性の評価、医療診断、医療又は社会ケアの提供又は治療、又は医療又は社会ケアの制度及びサービスの管理を目的として必要である場合。

(i) 処理が、連合法又は加盟国法に基づき、データサブジェクトの権利及び自由を保障するための適切かつ具体的措置を定め、特に専門上の秘密保持義務を確保するものとして、公衆衛生の分野における公共の利益の理由、例えば重大な国境を越える健康脅威からの保護、又は医療や医薬品又は医療機器の品質及び安全性の高い基準の確保のために必要である場合。

(j) 処理が、連合法又は加盟国法に基づき、追求される目的に比例し、データ保護の権利の本質を尊重し、かつデータサブジェクトの基本的権利及び利益を保障するための適切かつ具体的措置を提供するものとして、公的利益のための保存目的、科学的又は歴史的研究目的、又は統計目的のために必要である場合。

(k) 処理が、規則(EU)2024/1689第3条(1)に定義されるAIシステム又はAIモデルの開発及び運用の文脈において行われ、かつ第5項に規定される条件に従う場合。

(l) 処理が、データサブジェクトのアイデンティティを確認する目的(検証)のために必要であり、バイオメトリックデータ又は検証に必要な手段がデータサブジェクトの単独の管理下にある場合。

3. 第1項に言及される個人データは、それらのデータが連合法又は加盟国法に基づく専門上の秘密保持義務に服する専門家、又は加盟国の権限ある機関によって定められた規則に従う専門家の責任において、若しくは同様の秘密保持義務に服する他の者によって処理される場合、第2項(h)の目的のために処理することができる。

4. 加盟国は、遺伝データ、バイオメトリックデータ又は健康に関するデータの処理に関して、追加の条件を維持又は導入することができる。

5. 第2項(k)に言及される処理については、特別カテゴリの個人データの収集及びその他の処理を回避するために、適切な組織的及び技術的措置を実施するものとする。これらの措置の実施にもかかわらず、コントローラーが、訓練、テスト又は検証に使用されるデータセット、又はAIシステム若しくはAIモデルにおいて特別カテゴリの個人データを特定した場合、当該データを削除するものとする。当該データの削除が不釣り合いな労力を必要とする場合、コントローラーは、いかなる遅滞もなく、当該データが出力生成に使用されること、第三者に開示されること又はその他の方法で利用可能とされることを防止するための効果的な保護を行うものとする。

(2) Recital案

(33) 特定のAIシステム及びAIモデルの開発には、大量のデータ(個人データ及びその特別カテゴリーを含む)の収集が関係する場合がある。特別カテゴリーの個人データは、処理の目的に必要ではない場合であっても、訓練、テスト又は検証のデータセットに残留的に存在する場合や、AIシステム又はAIモデル内に保持される場合がある。AIの開発及び運用を過度に妨げないようにするため、またコントローラーが特別カテゴリーの個人データを識別し除去する能力を考慮するため、規則(EU)2016/679第9条2項に基づく特別カテゴリーの個人データの処理禁止からの例外を認めるべきである。この例外は、コントローラーが当該データの処理を回避するための適切な技術的及び組織的措置を効果的に実施し、AIシステム又はAIモデルの全ライフサイクルを通じて適切な措置を講じ、かつそのようなデータを識別した際には効果的に除去する場合にのみ適用されるべきである。除去に過度の労力を要する場合、特にAIシステム又はAIモデルに記憶された特別カテゴリーのデータを除去するためにシステムやモデルの再設計が必要となる場合には、コントローラーは、当該データが出力として使用されること、開示されること、その他の方法で第三者に提供されることを効果的に防止するべきである。この例外は、特別カテゴリーの個人データの処理が処理の目的にとって必要である場合には適用されない。この場合、コントローラーは規則(EU)2016/679第9条2項(a)から(j)までに基づく例外を根拠とするべきである。

(34) バイオメトリックデータは、規則(EU)2016/679第4条14項で定義されているとおり、特定の技術的手段を通じて自然人の特定の特徴を処理し、その人物を一意に識別することを可能にする、又は確認するデータを意味する。バイオメトリックデータの概念には、2つの異なる機能が含まれている。すなわち、自然人の識別と、主張された本人のアイデンティティの検証(認証とも呼ばれる)であり、これらは異なる技術的プロセスに依拠している。識別プロセスは、データサブジェクトのバイオメトリックデータをデータベース内で「一対多数」で照合することに基づいており、これに対して検証プロセスは、データサブジェクトが自らのアイデンティティを主張する際に提供するバイオメトリックデータを「一対一」で比較することに基づいている。規則第9条1項の下でバイオメトリックデータを処理することの禁止についての例外も、データサブジェクトの主張されたアイデンティティの検証がコントローラーが追求する目的にとって必要であり、かつデータサブジェクトが検証プロセスを単独で制御できるように適切な保護措置が適用される場合には、認められるべきである。例えば、バイオメトリックデータがデータサブジェクト側にのみ安全に保管されている場合、又はコントローラー側に最先端の暗号化された形式で安全に保管されており、暗号鍵又は同等の手段をデータサブジェクトのみが保持している場合には、その処理がデータサブジェクトの基本的権利及び自由に重大なリスクを生じさせる可能性は低い。コントローラーは、バイオメトリックデータについて全く知識を得ないか、検証プロセスの間だけ極めて限定的に知識を得るにとどまる。

(3) 解説
ア 改正の内容

GDPR第9条は、1項で、特別カテゴリデータの処理を原則として禁止し、2項で、その例外を定めている。本改正案は、まず、特別カテゴリデータの処理の禁止の原則に対する例外として、①AIシステム又はAIモデルの開発及び運用のために行われる特別カテゴリデータの処理と、②ローカルで完結する生体認証(biometric authentication)を目的とするバイオメトリックデータの処理を追加し、その上で、①の条件として、(a)特別カテゴリデータの収集・処理を最小化するための組織的・技術的措置を求め、(b)それらの措置を実施したにもかかわらずデータセット又はAIシステム若しくはAIモデルから特別カテゴリデータが検出された場合、当該データを削除すること(削除が困難である場合、出力を防止するための措置)を求めるものである。

イ 背景①―AI

LLMは、大量のテキストデータを用いて開発されるが、その中には、特別カテゴリデータ(GDPR第9条1項)が含まれることが避けられない。NRW消費者センター対Facebook Ireland事件では、この点が争われ、ケルン高等裁判所は、検索エンジンに関するCJEUのGC and Others事件判決*24を引用し、データサブジェクトからの請求があった時点で9条適合性を個別に判断し対応すれば足りるとしていたが、このような解釈がCJEUでも認められるかは明らかではなかった。本改正案は、AI開発を事実上、9条の「原則禁止―例外許容」ルールの枠外に置き、それに代わって「リスクベースアプローチ」(リスクマネジメントアプローチ)的なルールを課すものといえる。一方、日本では、EU法に倣って、要配慮個人情報の取得制限を課しているところ*25、個情法の3年ごと見直しにおいて、統計作成・AI開発目的の取得について、目的外利用(≒個人に対する評価・決定のための利用)の禁止等の代替的な義務を課しつつ、当該制限の例外を認めることが検討されている。

ウ 背景②―生体認証

生体認証は、上記とは全く場面が異なる。GDPR第9条1項は、「自然人を一意に識別する目的でのバイオメトリックデータの処理」を禁止している。その典型は、Clearview AIのような、Web上で大量の顔画像を収集し、特徴量をデータベース化し、それとの照合により、公共空間で特定の個人を検出するようなAIシステムであるが(AI法5条1項(h)参照)、スマートフォンにおける顔認証も、文言上は9条の対象に含まれていた。その上で、実務上、法執行分野における顔認識技術に関するEDPB Guidelines 05/2022*26は、顔識別(1:N照合)と顔認証(1:1照合)のリスクの違いを強調し*27、空港での旅客フローの円滑化のための顔識別技術の使用に関するOpinion 11/2024*28は、主として漏洩リスクの観点から、バイオメトリックテンプレートは顧客の端末等に保存することが相対的に安全であるとしていた。現行法においても、例えば明示的同意(GDPR第9条2項(a))に依拠する余地はあり、このこと自体は本改正案が成立した場合でも変わらないが、本改正案は、ローカル完結の生体認証を明示的に例外とすることで、法的確実性をもたらすとともに、ローカル保存を促進しようとする*29ものと思われる。

以上の理論的示唆としては、3点が挙げられる。以下詳述する。

エ 特別カテゴリデータ規制の正当化根拠

第1に、特別カテゴリデータ規制の正当化根拠である。近時、Daniel Soloveは、OECDプライバシーガイドライン制定時に主張された「いかなるデータも本質的に「プライベート」又は「センシティブ」であるわけではなく、その文脈や利用方法(context and use)によってそうなる場合がある」という立場を引用し、センシティブデータ規制は不適切であり、弊害(≒リスク)に着目すべきである旨主張している*30。我が国においても、高木浩光は、同様の文脈で、要配慮個人情報の取得制限は、不当な差別の防止を目的としているが、個人データ処理による不当な差別は、結局のところ、(評価・決定の)目的に関連しないデータの処理によって生じるのであり、データの性質が問題なのではない旨主張している*31。GDPR第9条は、もともと、生体データの処理を「個人の一意の識別」を目的とするものに限定しており、その時点で、特別カテゴリデータ処理のリスクが文脈依存であることを既に認めていたと言えるが、ローカル生体認証を類型的に例外事由とする本改正案は、そのことを更に推し進めるものと言える。

オ 個人との関係で非体系的な処理

第2に、個人に標的を定めていない(non-targeted)、言い換えれば、個人との関係で非体系的な処理を規制する必要性の有無である。個人に対する評価・決定の適切性の観点からは、個情法は、個人に標的を定めた、個人との関係で体系性を持ったデータ処理を規制すれば足り*32、いわゆる散在情報の取扱いを規制することは、必須ではない。このような観点からは、個人(又は個人に紐づけられたトランザクション等)を単位として構造化されたデータセットを使用した識別AIモデル(例えば与信モデル、不正検知モデル)の開発と、Webからスクレイピングしたテキストデータを用いたLLMの開発は、性質が異なり、少なくとも上記の立場からは、前者のデータセットは、評価・決定に利用されないことを担保する必要がある一方、後者のデータセットは、そもそもそのような用途には適さないのであるから、そのような規制は必要ない。

もちろん、本改正案も、個情法3年ごと見直しにおける個情委の提案も、そのように理論的に徹底された立場を取るものではない*33。一方で、HmbBfDIのDPの次の記述は、この点を考える上で興味深い。「(注:CJEU判例で個人データと認められてきた)これらの識別子は全て、結果として、特定の人又は人に関する対象の同一性、属性又は状況の代用物(placeholder)としての役割を果たしており、その機能は、標的を定めた関連付け(targeted association)である。」、「CJEU判例法で扱われたこれらの識別子とは異なり、(注:LLMにおける)言語の断片としての個々のトークン…には個別の情報としての内容がなく、上記の代用物として機能しない」、「LLMは、個人に「関連する」具体的な特性や参照なしに、トレーニングデータからの高度に抽象化され集約されたデータポイントとそれらの相互関係を保存する」、「LLMに保存された情報は、CJEU判例法において個人データを特徴づける、特定の自然人に対する直接的かつ標的を定めた関連付け、すなわち自然人に「関する」情報要件を既に欠いている」*34。この指摘は、直接にはLLM自体の個人データ該当性を否定する文脈で書かれたものであるが、LLM開発にも応用可能であると思われる。すなわち、LLM自体が個人への「標的を定めた関連付け」を欠いているのと同じように、LLM開発に使用されるテキストデータセットは、「標的を定めた関連付け」を欠いている。自然人が読んだ場合の意味内容としては個人に「関する」情報であるかもしれないが、LLM開発におけるデータ処理は、そのような意味内容の解釈を伴うものではない。そのようなデータ処理は、そもそも個人データ保護法の対象とする必要性は小さい*35。

カ ローカル完結の個人データ処理

第3に、ユーザー端末等で完結する個人データ処理の個人データ処理該当性(ないし当該処理との関係での関係エンティティのコントローラー該当性)である。累次のCJEU判例は、コントローラー該当性を処理への影響力によって実質的に判断し、自ら又はその者の指示を受けたプロセッサーが個人データへのアクセスを有するわけではない者にコントローラー該当性を認めてきた*36。そのような中で、ユーザーが支配する機器で完結する処理について、当該機器の製造者やソフトウェアの提供者がコントローラーとされる可能性が指摘されていたが*37、本改正案は、そのことを前提としているようにも思われる。このことは、例えば、Verifiable Credentialsを専らローカルに保存するデジタルアイデンティティウォレットの提供者に個人データ保護法が適用されるか*38、といった問題にも影響する。

5 自動決定・プロファイリング

(1) 改正後条文案

第22条 自動化された個人に対する決定(プロファイリングを含む)

1. データサブジェクトに法的効果を生じ、又は同様に重大な影響を及ぼす決定は、当該決定が以下のいずれかに該当する場合に限り、プロファイリングを含む専ら自動化された処理に基づいて行うことができる。

(a) 当該決定を専ら自動化された手段以外の手段によって行うことが可能であるかどうかにかかわらず、当該決定が、データサブジェクトとコントローラーとの間の契約の締結又は履行のために必要である場合。

(b) 当該決定が、コントローラーが従う連合法又は加盟国法によって認められており、かつ当該法がデータサブジェクトの権利及び自由並びに正当な利益を保護するための適切な措置を定めている場合。

(c) 当該決定が、データサブジェクトの明示的な同意に基づく場合。

2. 第1項(a)及び(c)の場合、コントローラーは、データサブジェクトの権利及び自由並びに正当な利益を保護するための適切な措置を実施しなければならず、少なくとも、コントローラーによる人による関与を得る権利、自身の見解を表明する権利、及び当該決定に異議を述べる権利を確保しなければならない。

3. 第1項に言及される決定は、特別カテゴリの個人データ(第9条1項に言及されるもの)に基づいてはならず、ただし第9条2項(a)又は(g)が適用され、かつデータサブジェクトの権利及び自由並びに正当な利益を保障するための適切な措置が講じられている場合を除く。

(2) Recital案

(38) 規則(EU)2016/679第22条は、コントローラーが、専ら自動化された処理に基づき、データサブジェクトに法的効果又はこれと同程度に重要な効果を及ぼす決定を行う場合の個人データの処理を規律する規則を定めている。より高い法的確実性を提供するため、規則(EU)2016/679に定められた特定の条件が満たされる場合には、専ら自動化された処理に基づく決定が許容されることを明確化するべきである。また、規則(EU)2016/679第22条2項(a)に定めるように、データサブジェクトとコントローラーとの間の契約の締結又は履行にとって決定が必要かどうかを評価する際に、その決定が専ら自動化された処理によってのみ行われ得ることを要件とすべきではないことも明確化するべきである。これは、その決定が人間によって行われる可能性があるとしても、コントローラーが専ら自動化された処理によって決定を行うことを妨げないことを意味する。複数の同程度に効果的な自動化処理の解決策が存在する場合、コントローラーは、より侵害性の低いものを使用するべきである。

(3) 解説
ア 改正の概要

本改正案は、GDPR第22条1項柱書を、権利規定(一定の自動決定の対象とされない権利)から義務規定(同様の自動決定の禁止)に書き換えるとともに、同項(a)に関して、マニュアル処理が可能であることは、自動決定が必要であるとの評価を妨げないことを確認する記述を追加するものである。前者は従前から実質的には義務規定と解されていたものであり、実質的な意味があるのは、後者である。

イ 背景

本改正案の背景は、2つあると思われる。1つはCJEUのSCHUFA事件判決*39であり、信用スコアを算出して第三者に提供する者は、自らは与信判断を行わないため、22条の対象とは考えられてこなかったが、同判決は、当該スコアに基づいて与信判断がされているという実態を重視し、信用スコアの算定自体が自動決定であり、第三者がそれに強く依拠して信用判断を行うのであれば、当該スコアの算出自体が「法的効果又はこれと同程度に重要な効果を及ぼす」ものであるとした。この結果、GDPR第22条の適用が問題となる範囲が拡大した。

もう1つは、必要性に関する厳格な解釈である。CJEUは、EU法上、「必要」性は特別の意味を持ち、契約履行にとって役に立つだけでなく、より制限的でない(データサブジェクトへの影響の少ない)他の手段(LRA)がないことを必要とすると解してきた*40。本改正案は、このような解釈を前提に、マニュアル処理はLRAを構成しないことを明示したものと言える。

ウ 日本法への示唆

必要性概念は、一般の個人データ処理の法的根拠としての契約履行及び正当利益においても用いられ、共通してLRAの不存在を要求すると解釈されているが、本改正案は、そのような解釈の不合理性*41を部分的にであるにせよ認めるものと言える。今般の3年ごと見直しにおいては、法的根拠による規制は、個情委の最終的な提案には含まれなかったが、第三者提供制限の例外事由として、契約履行を定めることが提案されており、今後、必要性概念を用いるのか、用いられた場合どのように解釈すべきかについて、EU法の状況も十分に踏まえながら検討する必要がある。

なお、GDPR第22条のような自動決定・プロファイリング規制の導入の可否が議論されているが、同条は、特にハイリスクな自動決定・プロファイリングに関する追加的規制を定めたものであり、あくまで基本原則が重要であることに留意する必要がある*42。

6 Cookie規制(自然人の端末設備における個人データ処理)

(1) 改正後条文案

第88a条 自然人の端末設備における個人データの処理

1. 自然人の端末設備に個人データを保存し、又は既に保存されている個人データへのアクセスを取得することは、当該自然人が本規則に従って同意を与えている場合に限り許容される。

2. 第1項は、個人データの保存、又は自然人の端末設備に既に保存されている個人データへのアクセス取得を、連合法又は加盟国法に基づき、かつ第6条の意味及び条件に従い、第23条1項に言及される目的を保護するために行うことを妨げない。

3. 自然人の同意なく自然人の端末設備に個人データを保存する行為、又は既に保存されている個人データへのアクセス取得を行い、その後に処理を行うことは、以下のいずれかに必要な範囲において適法となる。

(a) 電子通信ネットワーク上で電子通信の伝送を実施すること。

(b) データサブジェクトが明示的に要求したサービスを提供すること。

(c) オンラインサービスの利用に関する集約情報を作成して当該サービスのオーディエンス数を測定すること。ただし、当該オンラインサービスのコントローラーが自らの利用のためにのみ実施する場合に限る。

(d) コントローラーが提供し、データサブジェクトが要求したサービス、又は当該サービスの提供に使用される端末設備の安全性を維持し又は回復すること。

4. 自然人の端末設備に個人データを保存する行為、又は既に保存されている個人データへのアクセス取得が同意に基づく場合には、以下が適用される。

(a) データサブジェクトは、単一のクリックボタン又は同等の手段により、同意の要請を容易かつ理解可能な方法で拒否することができる。

(b) データサブジェクトが同意を与えた場合、コントローラーは、当該コントローラーがデータサブジェクトの同意に適法に依拠できる期間中、同一の目的について新たな同意要請を行ってはならない。

(c) データサブジェクトが同意要請を拒否した場合、コントローラーは、同一の目的について少なくとも6か月間新たな同意要請を行ってはならない。

5. 本項は、同意に基づく個人データの後続処理にも適用される。

6. 本条は、【規則発効の6か月後】から適用される。

第88b条 自然人の端末設備における個人データの処理に関するデータサブジェクトの選択の自動化された機械可読な表示

1. コントローラーは、自らのオンラインインターフェースがデータサブジェクトに以下を可能とすることを確保しなければならない。

(a) 本規則に定める同意の条件が満たされていることを前提として、自動化された機械可読手段によって同意を与えること。

(b) 自動化された機械可読手段によって、同意要請を拒否し、第21条2項に従って異議権を行使すること。

2. コントローラーは、第1項に従ってデータサブジェクトが行った選択を尊重しなければならない。

3. 第1項及び第2項は、メディアサービスを提供する際のメディアサービス提供者であるコントローラーには適用されない。

4. 委員会は、規則(EU)1025/2012第10条1項に従い、機械可読のデータサブジェクトの選択の表示の解釈のための標準を策定するよう、一つ以上の欧州標準化機関に要請するものとする。

コントローラーのオンラインインターフェースが、欧州連合官報にリファレンスが掲載された調和標準又はその一部に適合している場合、当該オンラインインターフェースは第1項に定める要件に適合しているものと推定される。

5. 第1項及び第2項は、【規則発効の24か月後】から適用される。

6. 中小企業ではないウェブブラウザの提供者は、第1項に言及される自動化された機械可読手段を用いて、データサブジェクトが同意を与えること、同意要請を拒否すること、及び第21条2項に従って異議を行使することを可能とする技術的手段を提供しなければならない。これは本条2項から第5項を適用して実施される。

7. 第6項は、【規則発効の48か月後】から適用される。

(2) Recital案

(44) 端末設備における個人データの保存、又は既に保存されている個人データへのアクセスと、その後の当該データの処理は、電子通信サービスの加入者又は端末設備の利用者が自然人である場合には、単一の法的枠組み、すなわち規則(EU)2016/679の下で規律されるべきである。本規則において提示される改正は、データサブジェクトが権利を行使しオンライン上で選択を表明する際の体験を簡素化しつつ、個人データに対する最高水準の保護を引き続き提供するものである。改正は特に、当該端末設備に情報を保存する行為、当該端末設備から情報を取得する、又はその他の方法で収集する行為に関するものであり、それらは端末設備から情報を取得するためにcookieその他の類似技術を通じて個人データの処理を伴う。関連する規則は、端末設備が自然人により所有されているか、他の法人又は自然人により所有されているかを問わず適用されるべきである。

端末設備における個人データの保存、又は既に保存されている個人データへのアクセスは、引き続き同意に基づく場合にのみ認められるべきである。指令2002/58/ECのアプローチと同様に、この要件は、規則(EU)2016/679第6条の意味においてEU法又は加盟国法に基づく場合で、かつ当該規定に定められた適法性の全ての条件を満たし、規則(EU)2016/679第23条1項に定められた目的のために行われる場合には、自然人の端末設備に個人データを保存すること、又は既に保存されている個人データにアクセスすることを妨げるものではない。

コンプライアンス負担を軽減し、コントローラーに法的明確性を提供するため、また特定の処理目的がデータサブジェクトの権利及び自由に対して低いリスクしかもたらさない場合、あるいはデータサブジェクトが求めるサービスを提供するために当該処理が必要である場合があるため、同意なしに処理が認められる目的の限定的な一覧を定義することが必要である。端末設備における個人データの保存、又は既に保存されている個人データへのアクセスと、その目的のために必要なその後の処理については、本規則は処理が適法であると定めるべきである。メディアサービス提供者のようなコントローラーは、市場調査会社のようなプロセッサーに対し、自らの代わりに処理を実施するよう委託することができる。

限定的な一覧に定義されている目的以外の目的で個人データをさらに処理する場合には、規則(EU)2016/679第6条及び関連する場合には第9条が適用されるべきである。目的とする処理の適切な法的根拠を選択する責任は、説明責任の原則に照らしてコントローラーにある。規則(EU)2016/679第6条1項(f)に基づく正当な利益をその後の処理の根拠として用いるためには、コントローラーが、自ら又は第三者の正当な利益を追求していること、その正当な利益の目的を達成するために処理が必要であること、及びデータサブジェクトの利益又は基本的権利がコントローラーの追求する利益を優越しないことを示さなければならない。この文脈において、コントローラーは以下の要素を最大限考慮するべきである。すなわち、データサブジェクトが児童であるかどうか、データサブジェクトの合理的な予測、処理されるデータの規模又は機微性に起因する個人への影響、問題となる処理の規模(処理がその量又はデータカテゴリーの範囲の観点から特に広範であってはならないこと)、処理は必要最小限のデータに基づくべきであり、データサブジェクトのオンライン活動の大部分を監視することに基づいてはならないこと、その他適切な要素。処理は、データサブジェクトの私生活を継続的に監視する結果を招いてはならない。

コントローラーがその後の処理について正当な利益を法的根拠として依拠できない場合には、処理は規則(EU)2016/679第6条1項の他の根拠、特に同規則第6条及び第7条に従った同意に基づいて行われるべきである。その際には、規則(EU)2016/679の全ての原則が満たされていなければならない。

(45) データサブジェクトは、一度同意の求めに対して拒否した場合であっても、同じコントローラーのオンラインサービスを再度訪問するたびに、新たに同意を求める要求に直面することが多い。このことは、データサブジェクトに不利益をもたらす可能性があり、データサブジェクトが繰り返される要求を避けるためだけに同意してしまうおそれがある。そのため、コントローラーは、一定期間にわたり、同意の求めに対するデータサブジェクトの拒否の選択を尊重する義務を負うべきである。

(46) データサブジェクトは、自らの選択、すなわち同意を与えること、同意要求を拒否すること、又はデータ処理に異議を述べることを、自動化された機械可読の指示に依拠して示すことが可能であるべきである。そのような手段は、最新の技術に従うものであるべきである。これらは、ウェブブラウザの設定、規則(EU)914/2014で定められるEUデジタルアイデンティティウォレット、又はその他の適切な手段に具体化することができる。本規則に定められる規則は、適切なインターフェースを備えた市場主導の解決策の出現を支援するべきである。標準が利用可能になった場合には、コントローラーはデータサブジェクトの選択に関する自動化された機械可読の指示を尊重する義務を負うべきである。民主社会における独立した報道の重要性に鑑み、その経済的基盤を損なわないため、メディアサービス提供者はデータサブジェクトの機械可読の選択指示を尊重する義務を負うべきではない。ウェブブラウザ提供者がデータサブジェクトに処理に関する選択を可能にする技術的手段を提供する義務は、メディアサービス提供者がデータサブジェクトに同意を求める可能性を妨げるものではない。

(47) 指令2002/58/EC(プライバシー及び電子通信に関する指令、いわゆる「ePrivacy指令」)は、2009年に最後の改正が行われ、通信の秘匿を含むプライバシー権の保護のための枠組みを定めている。また、電子通信サービスの文脈における個人データの処理に関して、規則(EU)2016/679を補足している。当該指令は、そのような通信に使用される利用者又は加入者の端末設備のプライバシーと完全性を保護している。指令2002/58/EC第5条3項の現行規定は、加入者又は利用者が自然人でなく、保存又はアクセスされる情報が個人データの処理を構成せず、又はそれにつながらない範囲において、引き続き適用されるべきである。

(3) 解説
ア 改正の内容・背景

第88a条、第88b条は、撤回されたePrivacy規則案(のCookie関係部分)を、規則案の交渉過程を踏まえ、GDPRに組み込む形で事実上再提案するものである。

第88a条1項は、ePrivacy指令(EPD)第5条1項第1文を引き継ぎ、自然人の端末設備(terminal equipment)への個人データの保存及び保存された個人データへのアクセスについて、原則として同意を必要とするものである。EPDは、端末設備を私的領域の一部と位置づけ、「スパイウェア、ウェブバグ、隠された識別子」などから当該端末設備を保護するため、上記の行為について、2002年の制定当時、オプトアウト(拒否権)を定めていたが、2009年の改正により、オプトイン(同意)を求めるようになった*43。

同条2項、3項は、例外的に同意なき処理が認められる場面を定めるものである。2項は、安全保障、治安維持、犯罪捜査等を定めている(参照される23条1項は、加盟国法によりデータサブジェクトの権利を制限することが許される場合を定めるものである。)。3項は、①通信の伝送、②データサブジェクトが明示的に要求したサービスの提供、③ファーストパーティとして行うオーディエンス測定、④セキュリティ確保を定めている。同項は、後続処理(subsequent processing)についても適用される。一方、同条4項は、同意に基づく保存・アクセスと後続処理について、同意取得の方法(ワンクリック同意)、再度の同意要求禁止等の規制を定めるものである。

88b条は、「Cookieバナー疲れ」を解消し、かつダークパターンに対処するため、ユーザーが自動かつ機械可読な方法で選好(preferences)を表明できるようにするものである。具体的には、1項・2項で、Webサイトやアプリ等の「オンラインインターフェース」を提供するコントローラーが、前記の方法でユーザーの選好を受け付け、尊重する義務を定め、6項で、ブラウザの提供者が、前記の方法で選好を表明できるようにする義務を定め、4項で、欧州標準化機関(ETSI等が想定される。)が標準(HTTPのDo Not Trackヘッダのようなものが想定される。)を策定することとしている。

88b条には、重要な例外がある。すなわち、同条3項で、同条1項・2項は、メディアサービスには適用しないこととされている。GDPR上、同意の有効性は厳格に解釈されていることを考慮すると、88b条が成立した場合、多くのユーザーはデフォルトでCookieの保存・アクセスを拒否し、伝統的メディアやWebメディア(動画共有サイトやSNSそれ自体を含まない。)だけがいわば特権的に同意を要求できる、ということになる可能性が高い。

イ 日本法への示唆

日本の状況は、以上とは大きく異なる。日本では、Cookie IDはそもそも個人データとは解されておらず、電気通信事業法上の外部送信規律は、個情法の上乗せ規制ではなく、むしろ個情法より緩和な義務(情報提供)を補完的に課すにとどまる。また、外部送信規律は、「電気通信の信頼性を確保し、利用者の利益を保護する」ものとされており*44、EPDのように、私的領域の保護を根拠としているわけではない。その上で、本改正案から得られる示唆としては、次の2点があると思われる。

第1は、同意偏重が「同意疲れ」を引き起こす可能性である。すなわち、同意は、本来、Cambridge Analytica事案やリクナビ事案のように、Cookieを使用して個人に対するリスクの高い処理が行われる場合にこそ要求されるべきである(このような場面では、データ対象者は注意深く意思決定をするであろうし、そのような意思決定に資するべく、十分な情報提供が行われるべきである。)。そうあるにもかかわらず、EUでは、EPDでCookieの使用全般に同意が強制され、またGDPRでも正当利益が厳格に適用されることで、個人に対する具体的なリスクがあるとは言い難い処理にまで同意が要求され、このことが、「同意疲れ」、そして今回の提案に繋がっているように思われる。

日本においては、①Cookie IDは単体では個人データとされず、また、②個情法27条1項の例外は狭いものの、本則である同意を極めて柔軟に解釈することで、このような弊害は回避されている。(少なくともEUのようなレベルの)「同意疲れ」を回避できていること自体はよいとしても、①②の解釈が適切であるとは思われず、これらを是正しつつもEUの失敗も繰り返さないような制度設計が求められる。

第2は、広告規制を個人データ保護や私的領域の保護の文脈で扱うことが適切かどうかである。EUは、上記のとおりCookieの使用に同意を要求した上で、同意を厳格に解釈することを通じて、事実上、広告依存型ビジネスモデルを否定しつつある*45。しかしながら、日本の最高裁も認めるとおり*46、広告には、社会における情報流通を支える役割もある(それは伝統的メディアにおいても同じである。)。また、仮に(様々な広告のうち)ターゲティング広告を規制するとしても、端末設備への識別子の保存は、ターゲティング広告の手段の一つに過ぎず、そのような保存なしに同様の効果をもたらすことも、技術的には可能である*47。そのため、仮に特別の規制を課そうとするのであれば、広告の仕組み、広告の本質、広告を巡るエコシステムを十分に把握し分析した上で、消費者保護や民主主義の観点から必要かつ適切な規制を検討する、というのが「王道」ではないか*48。

(2025年12月8日脱稿)

*1:European Commission, A Simpler and Faster Europe: Communication on Implementation and Simplification (Feb. 11, 2025).

*2:Case C-413/23 P, European Data Protection Supervisor v. Single Resolution Board, EU:C:2025:645 (Sep. 4, 2025).

*3:欧州連合司法裁判所(Court of Justice of the European Union)は、一般裁判所(General Court)と司法裁判所(Court of Justice)の2つの裁判所からなる。一般裁判所は、EU機関による法的措置に対する異議訴訟等を管轄する。司法裁判所は、一般裁判所の判決に対する上訴を管轄するほか、EU法の解釈に関して加盟国裁判所から付託を受けて先決裁定を行う。EUの個人データ保護法は、基本的にはEUレベルでの法執行メカニズムを持たないので、CJEU判例の多くは先決裁定の形で示されるが(個人データ保護法について司法判断が示されるルートとしては、加盟国当局の法執行に対する異議訴訟、データサブジェクトの苦情申立ての却下決定に対する異議訴訟、データサブジェクトによる直接提訴、消費者団体による直接提訴があるが、いずれも基本的には加盟国裁判所を経由する。)、本件では、EU機関であるSRBによる個人データ保護法違反が問題となり、同じくEU機関であるEDPSのSRBに対する決定が争われたことから、一般裁判所が一審を管轄した。

*4:Case C-479/22 P, OC v Commission, EU:C:2024:215 (Mar. 7, 2024)は、欧州不正対策局(OLAF)が行った研究資金不正の調査結果に関するプレスリリースの適法性(調査対象者が損害賠償を請求した。)に関して、提供先基準説を(も)採用したかのようであったが、SRB判決を前提とすると、個人データ該当性の場面では、OLAFにとっての識別性を問題とすれば足りた可能性がある。

*5:Case C-582/14, Patrick Breyer v. Bundesrepublik Deutschland, EU:C:2016:779 (Oct. 19, 2016).

*6:この点について、猪谷誠一氏から、IAB Europe事件判決は絶対的基準説を採用しているのではないかとのコメントをいただいた(猪谷誠一「IAB Europe事件欧州司法裁判所先決裁定の検討」情報ネットワーク・ローレビュー24号32頁注44(2025)参照)。同判決45段落と48段落〜50段落の関係をどう読むかに関わる問題であるが、45段落では、「TC String…を追加データ、特にユーザー端末のIPアドレス又は他の識別子と関連付けることが、そのユーザーを識別することを可能にする限りにおいて、TC Stringは識別可能なユーザーに関する情報を含み、したがって…個人データを構成すると言わなければならない。」と、条件付きで個人データ該当性を認めるにとどまっていること、48段落〜50段落でその「条件」の充足が(事実認定権限を有する照会裁判所による認定を要するという条件付きであるものの)認められ、確定的に個人データ該当性が認められていることからすれば、48段落〜50段落は傍論とは言えず、そうである以上、やはり相対的基準説に立っていると言えるのではないか。

*7:WP29, Opinion 4/2007 on the Concept of Personal Data, WP 136 (Jun. 20, 2007); WP29, Opinion 05/2014 on Anonymisation Techniques, WP 216 (Apr. 10, 2014).

*8:Case C-319/22, Gesamtverband Autoteile-Handel e.V. v. Scania CV AB, EU:C:2023:837 (Nov. 9, 2023).

*9:Case C-604/22, IAB Europe v. Gegevensbeschermingsautoriteit, EU:C:2024:214 (Mar. 7, 2024).

*10:See, Nadezhda Purtova, From Knowing by Name to Targeting: The Meaning of Identification Under the GDPR, 12 International Data Privacy Law 163 (2022).

*11:仮名加工情報に関して、佐脇紀代志編著『一問一答 令和2年改正個人情報保護法』15頁(商事法務、2021)。

*12:筆者の見解は、那須翔「個人情報保護法の論点」JILISレポート7号2頁。

*13:The Hamburg Commissioner for Data protection and freedom of information (HmbBfDI), Discussion Paper: Large Language Models and Personal Data (July 15, 2024).

*14:EDPB, Opinion 28/2024 on Certain Data Protection Aspects Related to the Processing of Personal Data in the Context of AI Models (Dec. 17, 2024).

*15:Oberlandesgericht Köln, 15 UKl 2/25, ECLI:DE:OLGK:2025:0523.15UKL2.25.00 (May 23, 2025).

*16:この判示は、正当利益テストにおいて考慮すべき弊害の範囲ないし具体性を問題にしたものと言える。この種の問題については、独禁法の競争の実質的制限を巡って議論の蓄積があり、仮に個情法に(第三者提供制限の例外として、あるいは法的根拠規制の導入に伴って)正当利益を導入する場合、独禁法の参照可能性も検討する必要があろう。

*17:フルネーム、メールアドレス、電話番号、国民識別番号、ユーザー識別子、クレジット・デビットカード番号、銀行口座番号・銀行コード、車両ナンバープレート、IPアドレス・住所の削除。

*18:個情委「『個人情報の保護に関する法律についてのガイドライン』に関するQ&A」(平成29年2月16日(令和7年7月1日更新))(「Q&A」)2-5。

*19:個情委「個人情報保護法の制度的課題に対する考え方について」(令和7年3月5日)1頁。

*20:個情委「OpenAIに対する注意喚起の概要」(令和5年6月2日)。

*21:同上。

*22:園部逸夫=藤原靜雄編著『個人情報保護法の解説 第三次改訂版』14頁(ぎょうせい、2022)196〜197頁、藤原静雄『逐条 個人情報保護法』84〜85頁(弘文堂)。

*23:個情委も、OpenAIに対する注意喚起(注20参照)においては、利用目的による制限には言及していない。なお、Q&A 2-5からすれば、利用目的特定義務自体が適用されないようにも思われるが、本注意喚起は、そのようには解釈していないようである。

*24:Case C-136/17, GC and Others v Commission nationale de l'informatique et des libertés (CNIL), EU:C:2019:773 (Sep. 24, 2019).

*25:瓜生和久編著『一問一答 平成27年改正個人情報保護法』19頁〜20頁(商事法務、2015)。

*26:EDPB, Guidelines 05/2022 on the Use of Facial Recognition Technology in the Area of Law Enforcement, Version 2.0 (Apr. 26, 2023).

*27:なお、この記述に照らせば、通則ガイドラインが「個人識別符号」に含まれるバイオメトリックデータを「本人を認証することができるようにしたもの」としていることの不適切性は明らかである。

*28:EDPB, Opinion 11/2024 on the Use of Facial Recognition to Streamline Airport Passengers' Flow (Compatibility with Articles 5(1)(e) and (f), 25 and 32 GDPR), Version 1.1 (May 28, 2024).

*29:なお、生体認証の場面では、処理速度の観点からも、もともとローカル保存が一般的である。

*30:Daniel J. Solove, Data Is What Data Does: Regulating Based on Harm and Risk Instead of Sensitive Data, 118 Northwestern University Law Review 1081 (2024).

*31:高木浩光「『個人情報保護法のいわゆる3年ごと見直しの検討の充実に向けた視点』に対する意見」(2024年11月21日個情委事務局ヒアリング資料3)11頁〜13頁。

*32:ただし、このことは、構造化されたデータベースの存在を必須とするものではない。例えば、AIエージェントが一定のプロンプトに従って散在的な情報を収集・処理し、個人に対する評価・決定を行う場合、当該プロンプトに従った体系的な処理が行われている以上、規制を及ぼすべきである。

*33:仮にそのような立場を取るとすれば、GDPRではprocessing概念、個情法では「個人情報」の取扱いを対象とする義務規定の解釈を改めることが考えられる。今般の個情法の3年ごと見直しにおいては、個人データ概念、コントローラー概念といった制度の根幹部分の見直しが先送りとされたが(個情委「『個人情報保護法 いわゆる3年ごと見直しに係る検討』の今後の検討の進め方について」(令和7年1月22日)8頁)、次回の3年ごと見直しにおいては、是非とも見直しの対象とされるべきである。個情法は、平成15年改正後、平成27年、令和2年、令和3年と改正されてきたが、いずれも、GDPRにあって我が国にない追加的規制の導入や、監督体制に関する見直しにとどまっており、根本的な見直しはなされていない。

*34:The Hamburg Commissioner for Data protection and freedom of information (HmbBfDI), Discussion Paper: Large Language Models and Personal Data (July 15, 2024). なお、本文の引用部分に続けて、「プライバシー攻撃」によって個人データらしきものが出力されるからといって、当該個人データが「記憶」されていることの証拠にはならず、また、そのような出力は、通常、標的を定めた攻撃によって可能となるのであり、そのような出力が可能であるからといって、LLMが個人データに該当するものではない、とされている。

*35:高木浩光「個人情報保護法3年ごと見直し令和6年に対する意見」(2024年6月12日第289回個人情報保護委員会資料1-2)4頁〜9頁。

*36:Case C-25/17, Tietosuojavaltuutettu v Jehovan todistajat, EU:C:2018:551 (Jul. 10, 2018); Case C-604/22, IAB Europe.

*37:Efstratios Koulierakis, Personal Data Controllers and Device Producers: Mind the Gap, 58 Computer Law & Security Review 106172 (2025).

*38:デジタル庁「令和6年度 DIWアドバイザリーボード報告書」(2025年3月27日)28頁、36頁、37頁、49頁参照。See also Niko Tsakalakis & Alessandro Ortalda, Legal Bases for the Use and Operation of European Digital Identity Wallets, Brussels Privacy Hub Report (May 2022).

*39:Case C-634/21, OQ v. Land Hessen, EU:C:2023:957 (CJEU Dec. 7, 2023). SCHUFAに関するOQの苦情申立てに対し、ヘッセン州データ保護当局が法的措置を取らなかった事案。

*40:Case C-394/23, Mousse v. Commission nationale de l'informatique et des libertés (CNIL) and SNCF Connect, EU:C:2025:2 (Jan. 9, 2025).

*41:すなわち、個人データ処理は本来有用なものであり、個人データ保護法はあくまでそれに伴って生じうるデータサブジェクトに生じうる権利侵害を防止するためのリスクマネジメントを要求するものであるところ、上記の解釈は、リスク対応として、常にリスク回避を優先させることを要求するものと言える。

*42:WP29, Guidelines on Automated Individual Decision-Making and Profiling for the Purposes of Regulation 2016/679, WP251 rev.01, at 9-14 (Oct. 3, 2017).

*43:EPD Recital 24, EDPB, Guidelines 2/2023 on Technical Scope of Article 5(3) of ePrivacy Directive, Version 2.0, paras. 1, 28 (Oct. 16, 2024).

*44:多賀谷一照監修・電気通信事業法研究会編著『電気通信事業法逐条解説(再訂増補版)』212頁(情報通信振興会)。電気通信の何に対する信頼なのか、信頼が裏切られた場合にどのような利益が侵害されるのかは、説明されていない。外部送信規律の導入を勧告した「電気通信事業ガバナンス検討会報告書」(2022年2月)18頁も、①Cambridge Analytica事案、②「Smooz」ブラウザ事案、③Webスキミングの事案、④Clearview事案等に言及しているが、それらの何が問題だったかについての言及はない。なお、これらの事案のうち、Webサイト運営者の関与の下にデータ収集(やそのための外部送信)が行われたと言えるのは、①のみである。

*45:なお、88b条では、メディアサービス提供者は独自の方法で同意を要求してよいこととされているが、同意が不要となるわけではない上に、クロスドメインなデータ収集が(より一層)できなくなるのであれば、広告主ひいてはメディアサービス提供者にとってはそれほど大きな恩恵とはならないであろう。

*46:最判令和4年1月20日刑集76巻1号1頁(Coinhive)。

*47:この点について、猪谷誠一氏から、3rd party cookieに代わる追跡手段の代表例である共通IDはユーザの端末設備に情報を書き込まず、アクセスもしないので、EPDや本改正案による改正後のGDPR第88a条では捕捉できない可能性がある旨のコメントをいただいた。

*48:この点について、白石忠志ほか「〔座談会〕デジタル広告と競争法・透明化法」ジュリスト1564号(2021)〔野口祐子発言〕。

個人データ保護における個人の識別とは何か―類型と本質

情報ネットワーク法学会 第25回研究大会(2025年11月24日)における発表「個人データ保護における個人の識別とは何かー類型と本質」の予稿を転載します。PDF版はResearchmapをご参照ください。

1 要約

本稿で述べることを要約すると、次のとおりである。①WP29意見書は識別をsingle outと説明していた。②Breyer判決はWP29意見書よりも識別性を狭く解釈したようにも見えるが、射程を限定する読み方も成り立つ。③識別には、狭義のアイデンティティを通じた識別と、存在・行動を通じた識別がある。氏名による識別は前者に属し、顔画像やCookie IDによる識別は後者に属する。個人情報保護委員会も顔識別カメラの文脈では後者の識別を認める。④「特定の個人」はa particular individualと読むべきであり、狭義のアイデンティティを要求したものと解することは、法目的、沿革、個人情報保護委員会の実務のいずれに照らしても不適切である。⑤個人情報データベース等の本質は、個人に着目した処理ができるよう体系的に構成されていることであり、リアルタイム処理も個人情報データベース等の供用に当たる。

2 GDPRの規定とWP29意見書

GDPRにおいて、個人データは、「識別された又は識別可能な(identified or identifiable)自然人に関する(relating to)あらゆる情報」と定義されている(GDPR 4条(1))。WP29意見書は、これを、①情報要件、②関連性要件、③自然人要件、④識別性要件に整理している*1。①③の解釈は、日本法と概ね同様である。

②関連性要件は、内容、目的、結果の観点を考慮して*2、言い換えれば、データそれ自体の性質だけでなく、データが処理される文脈ないし状況(context)を考慮して判断される。この点につき、WP29意見書は、特定の家の価値は、それ自体としては物に関する情報であり、特定の地区の不動産価格の水準を説明するためにのみ使用される場合、個人データとみなすべきでないことは明らかだが、納税義務の範囲を決定するために使用される場合、個人データとすべきことは明らかだとする*3。

④識別性要件は、ある集団において、1人の自然人を他の構成員から区別(single out, distinguish)できることとされている*4。このように、識別性もまた、文脈依存的(contextual)な概念であり、最低限どのような情報があれば識別性が認められるかは、処理が行われる状況に依存する*5。この点につき、WP29意見書は、「ありふれた姓は、国全体の人口から誰かを識別する…には十分ではないが、教室で生徒を識別するのには十分である可能性が高い」*6、「『黒いスーツを着た男』などの補助的な情報でさえ、信号機で立っている通行人の中から誰かを識別するかもしれない」とする*7。

3 Breyer判決(2016年10月19日)

Patrick Breyer氏は、ドイツ連邦政府が運営するWebサイトにアクセスした。これらのサイトでは、DDoS攻撃を防止し、攻撃者を訴追することを目的として、アクセス情報(アクセス日時、通信量、IPアドレスなど)のログを保存していた。Breyer氏のIPアドレスは、動的IPアドレス、すなわち、「各インターネット接続に対して割り当てられ、その後の接続が行われる際に置き換えられる一時的なアドレス」であった*8。Breyer氏は、このようなIPアドレスの保存は個人データ保護指令(DPD)に基づく国内法に違反するとして、ドイツの行政裁判所に、IPアドレスの保存の禁止を求める訴えを提起した。

裁判所は、①動的IPアドレスは、「ウェブサイトにアクセスしたコンピュータを所有する自然人のアイデンティティ、またはそのコンピュータを使用する可能性のある他の者のアイデンティティを直接明らかにしない」ため、「識別された」自然人に関する情報ではないことは争いがない*9とした上で、②「識別されうる」自然人に関する情報に当たるかどうかについて、(a)識別性は、コントローラーまたは他の者が当該個人を識別するために合理的に使用される可能性のある全ての手段を考慮すべきとされていること(DPD recital 26)を確認した上で、(b)サイバー攻撃の場合には、Webサイトの運営者が関係当局に連絡し、関係当局がISPから情報を取得し刑事訴追ができることから、「識別されうる」自然人に関する情報であることを認めた*10。

4 共通の考察―識別とは何か

(1) WP29意見書とBreyer判決―射程の限定

日EUに共通の問題は、識別とは何かである。WP29の回答は明快であり、ある集団において1人の自然人を他の構成員から区別(single out)できることである。WP29は、〈名前による識別は最も一般的だが、常に名前が必要であるわけではない〉、〈Webトラフィック監視ツールは、機械の行動を識別し、その背後にいるユーザーの行動を識別することを容易にする。…特定の決定を当該個人に帰属させるため、データの断片を組み合わせて個人の人格を形成することができる〉、〈個人の接点であるコンピューターは、その人の狭義のアイデンティティの開示を必ずしも必要としない〉とする。一方、Breyer判決は、先に述べたとおり、動的IPアドレスが、ユーザーの「アイデンティティを直接明らかにしない」ことをもって「識別された」個人に関するデータであることを否定するかのようであり*11、WP29意見書にいう狭義のアイデンティティを要求しているようにも見える。

この点につき、Purtovaは、WP29の広い解釈を前提に、Breyer判決の射程を限定する解釈を提案する。彼女によれば、動的IPアドレスは、セッション中はそれ自体で「識別された」個人に関するデータだが、その後に保存されている段階では、それ自体では「識別された」個人に関するデータとはいえず、ISPが保有するデータとの照合によって初めて「識別されうる」個人に関するデータとなる*12。

この「区別」は、相応の説得力を持つ。Breyer判決後も、静的IPアドレスが識別性を有することは争いがないと思われるが、そうであるにもかかわらず、動的IPアドレスの識別性が否定され(う)るのは、それが一定期間で切り替わるという性質(ないし使い方)に起因するものである。裏を返せば、動的IPアドレスであっても、同一IPアドレスを割り当てられている間(数日から数か月に及ぶこともある。)は、個人の識別に利用でき、そうだとすれば、CJEUがISPが保有するデータとの照合を問題としたのは、保存されるIPアドレスが問題となっていたからにすぎない、という議論は成り立ちうる。

(2) Purtovaによる識別の5類型

さらに、Purtovaは、Leenesの主張*13に依拠しつつ、識別の態様を、①参照(look-up)、②認識(recognition)、③分類(classification)、④セッション、⑤ターゲティングに分類する。①は、識別子と狭義のアイデンティティの対応表が存在することを前提に、識別子から狭義のアイデンティティを参照することによる「識別」である。②は、個人がその場に存在すること、またはその活動(the presence or activity of an individual)による「識別」である。そのような識別を可能にするものとして、識別子、トークン(例えばクロークルームの預り証)、特徴の組み合わせ(例えば身体的外観)が例示されている。③④は、より時間的に限定され、③は個人を事前に定義されたカテゴリに分類すること、④は特定のやり取りの間相手を追跡することである。⑤は、「ある瞬間において集団から特定の個人を注意または処遇の対象として選ぶこと」である。その例として、顔特徴データをもとに属性を推論し、それに応じてカスタマイズされた広告を表示することが挙げられている*14。これらは、基本的には、いずれもWP29意見書にいう区別(single out)に含まれるとされる。この類型論は、2つの点で注目に値する。次節以下で詳述する。

(3) 狭義のアイデンティティを通じた識別 vs 存在・行動を通じた識別

Purtovaの類型論は、第1に、識別の態様として、①参照と②認識、言い換えれば、①’狭義のアイデンティティが明らかになることによる識別と、②’存在・行動を通じた識別を区別する点で注目に値する。

個人情報保護委員会は、顔識別カメラシステムの文脈で、(a)ID(例:1)、(b)顔画像、(c)発生日時、(d)状況(例:ドアをこじ開け立入禁止区域に侵入した。)、(e)特徴(例:男性、スーツ、40代)という項目からなるデータベースについて、レコード全体が個人情報に該当するとしているが*15、これらはそれだけでは狭義のアイデンティティを示すものとは言い難い。それにもかかわらず、当該レコードが個人データとされるべきなのは、当該データベースの目的、すなわちデータベースに登録された人物が顔識別カメラに映り込んだ際に、従業員等に通知し、違法行為等を行わないか注視したり、声掛けを実施したりすることとの関係では、データベースに登録された者とカメラに映り込んだ者の顔画像があればよいからである。ここでは、対象者(映り込んだ者)の存在・行動が識別を可能としているのであって、狭義のアイデンティティがそうしているのではない。

翻って、ターゲティング広告において、(i)Cookie ID、(ii)行動履歴、(iii)関心カテゴリ、(iv)広告表示履歴を表すデータセットが使用される場合を考える。この場合、広告主やアドネットワークの運営者は、あるサイトを訪れた人物(ブラウザ)のCookie IDを読み取り、当該人物の(ii)-(iv)のデータを参照し計算して広告を出し分ける。ここでは、Cookieが顔識別カメラの事例における顔画像と同様に、②’存在・行動による識別を可能にする役割を果たす。データセットが狭義のアイデンティティを明らかにしないことは、個人データ該当性を否定する理由にはならない。

(4) 瞬間的な識別―リアルタイム処理の個人データ処理該当性

Purtovaの類型論は、第2に、①②の比較的長期の識別と、③④の比較的短期の識別と、⑤の瞬間的な識別を区別しつつ、これらがいずれもWP29意見書にいう区別(single out)に含まれることを明らかにする点で注目に値する。個人データ保護法の適用範囲を画定する上で重要なのは、個人を識別したデータ処理が行われる(可能性がある)かどうかであって、個人を識別できるデータの保存の有無は必ずしも重要ではない。

このような考え方は、実は、既に断片的に実務に取り込まれていると思われる。3つの事例を挙げる。第1に、Garanteは、2017年、Grandi Stazioni Retail社が、ミラノ中央駅に顔検知機能付きのデジタルサイネージを設置し、周辺の状況をカメラで撮影し、即時に視聴者の到着時刻、滞在時間、注視した時間、性別、年代、カメラからの距離、表情(幸せ、悲しいなど5分類)からなるデータに変換し、サーバに送信し、画像は破棄していた事案で、同社が個人データ処理を行っていたことを前提に、処理自体は適法としつつ、情報提供(掲示等)とセキュリティ監査を命じた*16。第2に、Conseil d’Étatは、2020年、COVID-19パンデミック中に、Lisses市の小学校が入口に移動式のサーマルカメラを設置し、異常が検出された場合には帰宅を要請する等していた事案で、法的根拠の欠如等を理由に、カメラの使用停止を命じた*17。第3に、個人情報保護委員会は、2018年、JapanTaxi社が、タクシーの車載タブレットのカメラを使用して乗客の顔画像を撮影し、広告配信を行っていた事案で、同社を指導し、「顔画像を取得した後、属性情報を抽出した上で、当該属性情報に基づき当該本人向けに直接カスタマイズした広告を配信する場合、当該顔画像を直ちに廃棄したとしても、当該顔画像について、特定の個人を識別した上で、広告配信を行っている」とするQAを公開した*18。

もっとも、Purtovaは、上記①〜⑤が識別に含まれることは論証しているが、それが識別に含まれるべきである理由は説明していない。この点に関して、我が国では、今般の3年ごと見直しを通じて、個情法の保護法益(の候補)として、(a)個人に対する評価・決定の適切性、(b)個人に対する勧誘その他の働きかけの適切性、(c)私事の秘匿、(d)自己情報コントロール、(e)個人の意思決定の自律性が議論されている*19。特に、(a)は、ターゲティングを識別に含めるべき理論的根拠を提供する*20。米国でも、Soloveは、2023年の論文で、「プライバシー法の最も重要な目的は人々を不適切な決定(faulty decisions)から保護することである」*21としており、同様の考え方に立つと思われる。

5 日本法固有の考察

(1) 特定の個人―“a specific individual”ではなく“a particular individual”

日本法における個人情報の定義中、「特定の個人を識別することができる」とは、「社会通念上、一般人の判断力や理解力をもって、生存する具体的な人物と情報との間に同一性を認めるに至ることができること」をいうとされ、Cookie IDを含む一般的なIDは、単体ではこれを満たさないとされる*22。ここでは、「特定の」に前節でいう狭義のアイデンティティのようなニュアンスが読み込まれているものと思われる。

しかしながら、そのような解釈は、次の3点から適切でない。第1に、前節で述べたことから明らかなとおり、個人に対する評価・決定の適切性の観点からは、狭義のアイデンティティを要求することは、不当に狭い解釈である。第2に、平成15年個情法制定時、昭和63年個情法の「当該個人」に代えて「特定の個人」が採用され、かつ、「氏名、生年月日その他の記述」に続いて例示されていた「個人別に付された番号、記号その他の符号」が省略されたが、個人情報の範囲を狭める趣旨ではなかったことが明らかにされており*23、現行法を前提としても、「特定の」はspecificではなく、particularの意味に解すべきである(なお、WP29意見書も“single out a particular person”との表現を用いる*24。)。第3に、個人情報保護委員会は、既に、顔識別カメラシステムの文脈では、存在・行動を通じた識別を認めており、そうであるとすれば、これと同様のメカニズムで行われるCookie IDによる識別も、識別性要件を満たすはずである。

(2) 個人情報データベース等―データベースとストレージの区別

次に、日本法をリアルタイム処理に適用しようとする場合、「個人情報データベース等」が問題となる可能性があるが*25、文言と趣旨に照らすと、リアルタイム処理を捕捉することも不可能ではない。「個人情報データベース等」は、抽象化して言えば、特定の個人情報を検索できるよう体系的に構成したものであるが、この文言に照らす限り、保存は要求されない。「個人情報データベース等」という定義語がストレージを指すかのような印象を与えうるが*26、データベースは「データの特性およびそれらに対応するエンティティ間の関係を記述する概念的構造に従って編成されたデータの集合であり、1つまたは複数の応用分野を支援するもの」*27などと説明され、ストレージ*28とは区別される上、「等」とあるように、そもそも「データベース」の語に概念の外縁を画する機能はない。

したがって、特定の個人情報を検索できるよう体系的に構成したものである限り、リアルタイム処理も現行法上捕捉されていると理解すべきである*29。立案担当者は、体系的構成を、「個人情報としてのそれぞれの属性に着目して検索できるように構成されている」*30こと、「個人情報としての索引が付されてい」*31ることと説明しているが、このことは、体系的構成要件が、結局のところ、個人に着目した処理ができることを定めたものであることを裏付ける。

*1:WP29, Opinion 4/2007 on the Concept of Personal Data, at 6, WP 136 (June 20, 2007).

*2:WP29, Opinion 4/2007, supra note 1, at 10.

*3:Ibid.

*4:WP29, Opinion 4/2007, supra note 1, at 12.

*5:WP29, Opinion 4/2007, supra note 1, at 13.

*6:個人情報保護委員会「『個人情報の保護に関する法律についてのガイドライン』に関するQ&A」(平成29年2月16日(令和7年7月1日更新))1-2も参照。

*7:Case C-582/14, Breyer v. Bundesrepublik Deutschland, ECLI:EU:C:2016:779, paras. 13-17 (Oct. 19, 2016).

*8:Breyer, ECLI:EU:C:2016:779, para. 36.

*9:Breyer, ECLI:EU:C:2016:779, para. 38

*10:Breyer, ECLI:EU:C:2016:779, paras. 39, 47, 49.

*11:ただし、「〜ことには争いがない」という文脈での説示であることには留意が必要である。

*12:Nadezhda Purtova, From Knowing by Name to Targeting: The Meaning of Identification Under the GDPR, 12 International Data Privacy Law 163, at 179 (2022).

*13:Ronald E. Leenes, Do They Know Me? Deconstructing Identifiability, 4 University of Ottawa Law & Technology Journal, 135 (2007).

*14:Purtova, supra note 12, at 169.

*15:個人情報保護委員会「犯罪予防や安全確保のための顔識別機能付きカメラシステムの利用について」(2023年3月)31頁。

*16:Garante per la Protezione dei Dati Personali, Installazione di Apparati Promozionali del Tipo “Digital Signage” (Definiti anche Totem) presso una Stazione Ferroviaria, Registro dei Provvedimenti No. 551 (Dec. 21, 2017), https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/7496252.

*17:Conseil d’État, Ord. no. 441065, June 26, 2020, ECLI:FR:CEORD:2020:441065、金塚彩乃「体温自動測定GDPR違反コンセイユデタ判例解説」情報法制研究11号68頁(2022)。

*18:個人情報保護委員会「個人情報の保護に関する法律に基づく指導について」(令和元年9月17日)、個人情報保護委員会・前掲注(6)1-16。なお、専ら匿名化目的のGarante事案と、広告の出し分け目的の個人情報保護委員会事案では、リスクは異なる。

*19:那須翔「個人情報保護法の論点」JILISレポート7巻5号1頁(2025)。これらは保護法益の候補に過ぎないことには留意する必要がある。

*20:高木浩光「個人情報保護から個人データ保護へ ⑽ ――法目的に基づく制度見直しの検討――」情報法制研究17号57頁(2025)参照。Purtovaは、ターゲティングが識別の一態様であるという解釈を支持する裁判例として、2010年代の英国の2つの裁判例(Vidal-Hall v. Google Inc., [2015] EWCA Civ 311; [2016] QB 1003 (Eng. & Wales CA), R (on the application of Bridges) v. Chief Constable of S. Wales Police, [2020] EWCA Civ 1058 (Eng. & Wales CA))を引用し、それらがsingle outをindividuate(個別化)と言い換えていることを紹介している(Purtova, supra note 12, at 180)。この言い換えは、辞書的な意味に従ったもののようであるが(Purtova, supra note 12, at 167)、高木のいう「各個人を他の個人らと異なって扱うこと」(前掲論文59頁)と符合する。

*21:Daniel J. Solove, The Limitations of Privacy Rights, 98 Notre Dame Law Review 975, at 1013, 1014 (2023)..

*22:Cookie IDについて個人情報保護委員会「株式会社リクルートキャリアに対する勧告等について」(令和元年12月4日)、オンラインゲームのIDについて個人情報保護委員会・前掲注(6)1-9。

*23:高木浩光「個人情報保護から個人データ保護へ――民間部門と公的部門の規定統合に向けた検討(2)」情報法制研究2号88頁(2017)、同「個人情報保護から個人データ保護へ (10)――法目的に基づく制度見直しの検討」情報法制研究17号57頁58頁注13(2025)も参照。

*24:WP29, Opinion 4/2007, supra note 1, at 13.

*25:個人情報保護委員会・前掲注(6)1-16は、「個人情報」に言及する一方で、「個人データ」には言及しておらず、体系的構成要件を満たすかどうかについて疑義があると考えられている可能性がある。

*26:園部逸夫=藤原靜雄編著『個人情報保護法の解説第三次改訂版』65頁(ぎょうせい、2022)は、「本法で『個人情報データベース等』とは、データベースシステムやその装置、記録媒体をいうのではなく、データベースシステムに体系的に整理されて記録されている、特定の個人を識別できるデータを含む情報の総体のことである。」(83頁)としつつ、「『データベース』は、データの共有化や統合管理を目的として、個人情報を含む膨大な情報を蓄積するものであり、特定の個人が検索可能なものについては…」(84頁)と、保存に重点を置いた説明を加える。

*27:ISO/IEC, Information Technology—Vocabulary, ISO/IEC 2382:2015.

*28:ISO/IEC, Information Technologyでは、「ストレージデバイス」は、「データを格納することができ、保持することができ、かつ取り出すことができる機能単位」と説明される。

*29:高木(2025)・前掲注(23)60頁も同旨。

*30:園部=藤原・前掲注(26)85頁。

*31:園部=藤原・前掲注(26)86頁。

FATF DeFi Targeted Reportメモ

FATFから"Targeted Report on Regulatory Challenges from Decentralised Finance"が公表されていたので、背景と、実務上参照する機会が多そうな箇所についてメモしておきます。

 

  • 前提
    • FATF勧告15 para. 2は、「仮想資産から生じるリスクを管理および軽減するために、国は、仮想資産サービスプロバイダーがAML/CFT目的で規制され、免許を取得し又は登録され、FATF勧告で要求される関連措置の遵守を監視し確保するための効果的なシステムの対象となることを確保すべきである。」としている。
    • FATF勧告一般用語集は、仮想資産(VA)は、「デジタルで取引又は移転でき、支払い又は投資目的で使用できるデジタル価値の表現である。仮想資産には、FATFの勧告の他の箇所で既にカバーされているフィアット通貨、証券及びその他の金融資産のデジタル表現は含まれない。」、仮想資産サービスプロバイダ(VASP)は「仮想資産サービスプロバイダーとは、勧告の他の箇所でカバーされていないあらゆる自然人又は法人で、ビジネスとして他の自然人又は法人のために又はその代わりに以下の活動又は操作の一つ以上を行うものを意味する: i. 仮想資産と法定通貨間の交換; ii. 一つ又は複数の形態の仮想資産間の交換; iii. 仮想資産の移転; iv. 仮想資産又は仮想資産に対する支配を可能にする手段の保管及び/又は管理; v. 発行者の仮想資産の募集及び/又は販売に関連する金融サービスへの参加及び提供。」と定義している。
    • 2021年VA/VASPガイダンスは、「DeFiアプリケーション(すなわちソフトウェアプログラム)は、基準が基礎的なソフトウェア又は技術には適用されないため、FATF基準におけるVASPではない。しかし、DeFiアレンジメントにおいてコントロール又は十分な影響力を維持する創設者、所有者及び運営者又はその他の者は、たとえ当該アレンジメントが分散化しているように見える場合であっても、VASPサービスを提供し又は積極的に促進する(providing or actively facilitating)場合には、FATFのVASPの定義に該当する可能性がある。」としていた(para. 67)。
  • Targeted Report 5.2は、DeFiアレンジメントの支配者、すなわち「コントロール又は十分な影響力」を有する者とは、「実務上、主要なプロトコルの運用若しくは利用者へのサービスの提供を決定し、若しくはこれに重大な影響を及ぼす権限を有する人、及び/又はかかる活動から重大な経済的利益を得る人であり得る」とした上で、支配力の徴憑として、以下を挙げている(para. 34)。
    • i. 利用者又は参加者への経済的報酬、手数料若しくは発行の分配を含むがこれに限られない、プロトコルレベルの行動の実行を指示し、承認し、又は影響を及ぼすこと
    • ii. アップグレードキー、管理上の特権、緊急機能又はガバナンスメカニズムを通じるか否かを問わず、プロトコル又はそのスマートコントラクトの構成要素のいずれかを変更し、アップグレードし、一時停止し、又は終了させること
    • iii. アレンジメントに代わって資産を展開し、再配分し、又は処分する権限を含め、プロトコルの資産又はトレジャリー資源を決定し、割り当て、又は管理すること
    • iv. 最終的に金融サービスの提供を促進する、DeFiプロトコル又はその構成要素と相互作用する参加者、バリデーター又はその他の重要な利用者を追加し、除去し、ホワイトリストに登録し、又はその他の方法で決定すること
    • v. 開発者、マルチシグネチャー署名者[40]、オラクル運用者又はガバナンス代表者を含む、主要なガバナンス上、運用上又は管理上の役割を果たす人を任命し、解任し、又はこれらに影響を及ぼすこと。
  • Targeted Report 5.3は、より具体的な指標の例として、以下を挙げている(para. 37)。
    • オンチェーンコントロール指標:
      • i. アップグレード可能性及びバックドアの特権:アップグレード可能なコントラクト、プロキシパターン又はキルスイッチ機能の存在は、特にかかる権限が特定の人若しくはグループによって保持されている場合、中央集権的な支配を示し得る。安全性及びセキュリティの目的で保持される透明に開示された緊急機能(例えば、サイバー攻撃への対応として資産を保護すること)は、それ自体では支配を示す場合と示さない場合があるが、悪用された場合に重大なリスクをもたらし得る、特定の人が保持する開示されていない又は一方的なアクセス権(例えば、バックドアアクセス)は、しばしば支配を示す
      • ii. パラメータの設定:リスク限度額、手数料、報酬、担保係数又は類似の経済的若しくは運用上の設定を含む、主要なプロトコルのパラメータを一方的に設定し、又は変更する人若しくはグループが保持する権利は、支配の重要な指標である
      • iii. オラクル支配:価格その他のオラクルフィードを選択し、設定し、又は変更する能力(手動での価格設定への切替え又はオラクル入力の上書きを含む。)は、支配を示し得る
      • iv. プロトコルにとって重要なスマートコントラクトインフラに対する支配:展開キー、コントラクトレジストリ又はコアコントラクトの依存関係(自動化されたキーパー、実行者ネットワーク、決済コントラクト等)に対する排他的又は支配的な支配は、プロトコルの健全性及び継続性に対する直接的な運用上の影響力を示し得る
      • v. 手数料フロー及び利益:特定のアドレスが、手数料、最大抽出可能価値(MEV)リベート、清算ペナルティ又はトークン発行(すなわち、新たに発行されたトークン)といったプロトコルレベルの経済的フローを受け取る場合、支配が推認され得る。かかるフローは、受領者による継続的な影響力又は支配を示し得る
      • vi. 管理者/ゲートキーパー:流動性プール又はプロトコル機能がパーミッション制である場合、すなわちアクセスが承認された又はホワイトリストに登録された参加者に制限されている場合、これらの許可を管理し、及びアクセス権を決定する人が、支配者として特定され得る
      • vii. ガバナンスの集中及び議決権:ガバナンストークン保有の集中、影響力のある委任された投票ブロック、又は少数の主体が統治上の成果、アップグレード及びトレジャリーの配分を決定することを可能にする低い参加率は、戦略的な決定に対する事実上の支配を示し得る。
    • オフチェーンコントロール指標:
      • viii. カストディ及び運用:ガバナンス上又は管理上の決定の署名者として指定された人、アップグレードキーを支配する人、又はアレンジメントに代わって資産のためのカストディアルサービスを調整し若しくは取得する人は、重要な運用上又はセキュリティ関連の機能に影響を及ぼす能力を有することに鑑み、支配者として合理的に識別され得る。[42] ix. フロントエンドの運用及び流通:公開ウェブフロントエンド(モバイルアプリを含む。)及び関連するコンテンツ又はツール(ウォレット等)に対する支配は、これらのインターフェースを運用し、維持し、又は流通させる者が利用者のDeFiアレンジメントへのアクセス及びこれとの相互作用の方法を形作り得るため、中央集権的な影響力を示し得る
      • x. 法人:コア・コントリビューターを雇用し、知的財産権を保有し、トレジャリーを管理し、又はサービスプロバイダーに支払を行う企業、財団、ラボ、事業会社又はその他の法人は、中央集権的な支配を行使している場合がある。支配の程度は、プロトコルからのこれらの実際の独立性、及びガバナンス、開発又は運用にこれらが及ぼす影響力の程度に依存する
      • xi. 開発、ロードマップ又はオフチェーンインフラに対する支配:開発の優先順位を決定し、リリースを支配し、又は不可欠なオフチェーンインフラ(インデクサー、データサービス、自動化システム等)を管理する人は、DeFiアレンジメントの方向性及び機能に対する実質的な影響力を行使し得る。この指標は、実際の支配を示すことなくDeFiアレンジメントのインフラに貢献する個々の開発者とは別個のものであり得る
      • xii. ブランディング、コミュニケーション及び利用者への方向付け:公式ブランディング、公的メッセージング、文書、リスク開示又は教育資料に対する支配は、影響力を示し得る。
  • Targeted Report 5.5は、「コントロール又は十分な影響力を有する者」が存在せず、DeFiアレンジメント及び関係者がVASPに該当しない場合について、「代わりに、これらのアレンジメントと相互作用することのリスクについて規制対象事業体にガイダンスを発出すること、並びにこれらのアレンジメントとの関与がいつ、及びどのような条件下(例えば、強化されたAML/CFT管理の適用)で適切であり得るかを明確化することを含む、より広範でホリスティックなリスクベースの軽減措置を検討すべきである。」とし、当該事業体の例として、以下を挙げている(para. 43)。
    • i. 真に分散化されたDeFiプロトコルで用いられるステーブルコインを凍結し、及び焼却する能力を保持するステーブルコイン発行者
    • ii. DeFiエコシステムへのオン及びオフランプを提供し、KYC及びCDDの責任、並びに疑わしい取引についてSTRを提出する義務を有するVASP
    • iii. 識別可能な支配者及びAML/CFT義務を有し得る、基盤となるDeFiアレンジメントへのアクセスに用いられるフロントエンドプラットフォーム(訳注:例えばDeFi接続機能を有するウォレットアプリ)
    • iv. DeFiアレンジメントと相互作用する金融機関
  • Targeted Report 5.8は、金融機関がDeFiアレンジメントと相互作用する場合について、以下のとおり、リスクアセスメントを求めている。
    • 「DeFiアレンジメントと相互作用する金融機関及びVASPは、R.15第1項に沿って、商品のリスク評価を実施し、かつ、これらのアレンジメントがもたらすリスクを管理し、及び軽減するための適切な措置を講じることを求められるべきである。金融機関及びVASPがDeFiアレンジメントにサービスを提供する場合、これらは勧告10(DeFiアレンジメントが顧客となろうとし、又は既に顧客である場合の顧客デューデリジェンス)及び勧告13(DeFiアレンジメントがコルレス銀行関係の確立を求める場合)も遵守すべきであり、これらの具体的な義務がFATF基準の下で満たされ得ない場合には、DeFiアレンジメントとの相互作用を控えるべきである。これらはまた、自らのAML/CFT枠組みの健全性を維持し、及び自らのエコシステム内で予防措置の効果的な適用を確保する一般的な義務を負う。金融機関及びVASPは、リスクベースかつ比例的な方法でDeFiアレンジメントを評価し、及び様々なシナリオにおいて適切な軽減措置を実施すべきである。
      • i. 中央集権型DeFiアレンジメント:金融機関及びVASPは、コルレス銀行業務に関するFATF基準に沿って、当該アレンジメントが免許付与若しくは登録され、及び適切な監督に服しているか否かの判定を含め、DeFiアレンジメントについてCDDを実施すべきである。金融機関及びVASPは、適切なデューデリジェンスを行い、又は勧告10及び13に沿って当該アレンジメントがAML/CFT管理を実施していることを確認すべきである。
      • ii. 支配者を容易には識別できない中央集権型DeFiアレンジメント及び真に分散化されたDeFiアレンジメント:金融機関及びVASPは、身元確認、並びに適切な場合には、当該プロトコルの健全性及びセキュリティの継続的な監視を含め、DeFiアレンジメントの基盤となる顧客に対し適切なAML/CFT措置を適用すべきである。金融機関及びVASPは、かかるアレンジメントとの相互作用がAML/CFT要件に適合することを確保する責任を引き続き負う。監督当局は、法域上のリスク並びにセクター別及び事業体別の考慮事項を考慮に入れつつ、規制対象事業体に対しさらなるガイダンスを提供すべきである。」(para. 59)
    • 「金融機関及びVASPのDeFiアレンジメントとの相互作用は、堅固なリスク軽減措置と組み合わされるべきである。AML/CFT管理を全く伴わずに利用者の無制限のアクセスを認めるDeFiアレンジメントは、潜在的な不正主体との直接的な相互作用を促進し得るため、より高リスクとみなされうる。金融機関及びVASPは、コンプライアンス義務に違反することなくかかるアレンジメントと相互作用するために、自らのコンプライアンス枠組み内で適切なAML/CFT軽減措置を実施できるか否かを慎重に評価すべきである。」(para. 60)
    • 「DeFiアレンジメントのガバナンス構造、監査及びサイバーセキュリティ管理を理解することはグッドプラクティスであるが、規制対象事業体は、当該アレンジメントによって実施されるAML/CFT管理の適切性及び有効性を評価すること、並びにその基盤となる利用者を効果的に識別し、及びその本人確認を行うための堅固な枠組みを確立することに優先順位を付けるべきである。これらはまた、適切な場合には、追加的な軽減措置(例えば、ブロックチェーン分析ツールを通じたリアルタイム監視)も適用すべきである。」(para. 61)
    • 「規制及び監督当局は、真に分散化されたDeFiアレンジメントがプロトコルレベルで効果的なAML/CFTリスク軽減措置を組み込んでいる場合には、個別化されたより柔軟なアプローチを採用することを検討することができる。かかる措置には、サードパーティのKYC/CDDプロバイダーへの依拠、組み込み型のKYC/CDDソリューション、並びにスマートコントラクト若しくはフロントエンドレベルでの許可リスト若しくは拒否リストの利用が含まれ得る。かかる場合、DeFiアレンジメントに関連する残存リスクはより低くなる可能性があり、金融機関及びVASPがDeFiアレンジメントの基盤となる顧客に適用するAML/CFT管理は、リスクが効果的かつ継続的に軽減されることを条件に、調整され得る。」(para. 62)

```

シンガポール控訴裁判所Quoine対B2C2事件判決―AIエージェント取引に関連して

AIエージェント取引について考えていたところ、シンガポール控訴裁判所のQuoine判決というのを見つけたのでメモです。

 

  • 事案・判決について
    • 暗号資産取引所Quoineにおいて、取引所の誤操作により注文板が徐々に薄くなり、信用取引を行っていたPulsarらのポジションの強制決済(買い注文)が発動し、アルゴリズム取引を行っていたB2C2の売り注文とマッチし、相場価格の250倍の価格での取引が成立した。翌日、Quoineが異常な取引として取引を取り消したところ、B2C2がQuoineを契約違反で提訴した。
    • Quoineは抗弁の1つとして、Pulsarらの取引所の作動状況に関する錯誤とそれによる取引の無効を主張したが、裁判所は、①契約条項ではなく取引の状況に関する錯誤なので(この点の評価が一審と控訴審で異なる。)無効事由とならず、②仮にそうでないとしてもB2C2のアルゴリズム開発者がそのことを認識しておらず、異常な取引から利益を得る設計も不正・非良心的なものとまでは言えないため、やはり無効とならないとした。
    • 暗号資産の板取引における誤発注の事案だが、誤発注がシステムエラーにより生じた点が、ジェイコム株誤発注事件とは異なる。また、Quoineが実行した強制決済についてPulsarらの錯誤が問題とされ、かつそれをQuoineが主張している点で特殊な事案。
  • 日本法に関するメモ
    • 仮に本件が日本法準拠で、かつPulsarらが取消しを主張したと仮定した場合、B2C2は、①基礎事情錯誤ではあるが表示がない、②仮に表示があるとしても錯誤を知らずかつそのことに重過失がないと主張するだろう。SG控訴裁がアルゴリズム開発者の認識を基準とした点は異なる判断もありうる(この点につき反対意見あり)。
    • 当該枠組みの下では、表示の有無に加えて、アルゴリズムがそのような表示を無視するものとなっていた(表示に反応する機構を設けていなかった)ことが重過失と言えないかが争われるだろう。もっとも、取引所取引では重過失とされることはまずないだろう。
    • 一方で、今後例えばECサイトにおけるAIエージェント取引で同種の問題が生じた場合、重過失とされる可能性は上がるかもしれない。実務上はそうならないようなインターフェース設計が重要であり(AIエージェントの資格証明・検証などはここに関わる)、そうすることが結果的に重過失がなかったことの立証に役立つだろう。
  • 関連文献

匿名化/スクレイピング/ブロックチェーンに関するEDPBガイドラインについて

EDPBが匿名化・生成AI開発目的のスクレイピングに関する2ガイドラインのパブコメ版と、ブロックチェーン技術を用いた個人データ処理に関するガイドラインの最終版を公表していたので*1、それについて書いていきます(別の箇所からの転載なので文章が荒削りなのはご容赦ください。)。

 

匿名化関係

  • 匿名性は、自然人に「関する」か(関連性)、自然人が「識別され又は識別可能」か(識別性)で判断する;①関連性の判断に当たっては内容、目的、効果を考慮する;識別性は、②合理的手段により、③その自然人を他者から区別し、異なる取扱いを可能にできるか("To identify a natural person means to distinguish them from others within a given context, consequently making it possible to treat them differently from those other people.")によって判断される;とする。
  • ②はRecitalにも書かれており、CJEU判例でも繰り返されてきたことだが、①③は実質的にWP29の2007年意見書*2が述べていたことをEDPB名義で再度オーソライズするものと言え、重要な意義を持つ可能性がある(なお、前提として、GDPRにおいて、匿名性とは個人データ該当性の否定である)。
  • SRB判決*3に沿って個人データ該当性の相対性を認めている。もっとも、これは、欧州の実務的には大きなことなのだと思われるが、日本では自明と考えられていることである*4。
  • 匿名性(したがって識別性)に関して、No Record Isolation; No Linkage; No Inferenceの3つの累積的基準(ただし例外が全く許容されないわけではないよう)を示している。これらはWP29の2014年意見書を実質的に踏襲したもの*5。
  • 本ガイドラインは、AIが背景とされているが、AI特有の記載はほぼない。一方で、AIモデルが個人データかという必ずしも合理的ではない問題設定(2024年意見書*6で示されたもの。HmbBfDIディスカッションペーパー*7への反論の必要性に引きずられている節がある。)は維持されているようである。

 

スクレイピング関係

  • 生成AIモデル開発のためのWebスクレイピングについて、透明性のほか、データ最小化、正確性を強調しているが、生成AIモデル開発だけが目的なのであれば、なぜそれらが個人の権利保護のために必要なのかは、やはり疑問に感じる。他の目的に転用された場合、もちろんリスクは生じるのだが、それは法的根拠欠如や目的制限違反(incompatibleな目的のための処理)として捕捉するのがGDPRの体系ではないのか。
  • 生成AIモデルの出力による権利侵害については、仮に個人データ処理(イメージ的には個人データの「生成」ということになろうか)に該当するとしても、リスク低減措置として、必ずしもモデルの訓練(正確にはそれに先立つデータの前処理)が必須であるわけではないことに留意する必要がある(ガイドラインが挙げるリスク低減措置はあくまで検討しうる候補と考えるべきだろう)。
  • 特別カテゴリデータについて、GC&Others判決*8を援用している。ケルン高等裁判所決定*9に倣ったものだと思われるが*10、やはり特別カテゴリデータ規制が合理的とは言えなくなっていることを裏付けているように思われる。

 

ブロックチェーン関係

  • 昨年4月にパブコメされていたもの。修正履歴付き版が公表されているが、実質的な変更は行われていないようである(Glossaryにsmart contractの定義が追加されているが、本文のsmart contractに関する記載自体は元々あった)。
  • パブコメ版の時点でそうだったが、GDPRの一般的内容を繰り返し、個人データ(直接識別性のあるものが念頭にあるのだろう。)をブロックチェーン上に保存してはいけないといった当然のことを確認するにとどまっているように思われる。
  • 「ブロックチェーンを用いた個人データ処理」においては、その分散的性質に起因して、誰をControllerとするかが重要な問題であり、特にIAB Europe判決*11を踏まえたとき、この問題は極めて重要だと思われるが、関連箇所は2021年ガイドライン*12を引用するにとどまっており、何ら新規の考え方を示していないように思われる。

*1:Guidelines 02/2026 on Anonymisation, Version 1.0, Adopted on 07 July 2026
Guidelines 03/2026 on web scraping in the context of generative AI, Version 1.0, Adopted on 07 July 2026
Guidelines 02/2025 on processing of personal data through blockchain technologies, Version 2.0, Adopted on 07 July 2026
https://www.edpb.europa.eu/news/edpb-sheds-light-on-anonymisation-and-web-scraping-for-generative-ai-and-adopts-final-version_en

*2:WP29, Opinion 4/2007 on the concept of personal data, Adopted on 20th June, https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf

*3:Case C-413/23 P, European Data Protection Supervisor v Single Resolution Board, ECLI:EU:C:2025:645 (Sep. 4, 2025), https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:62023CJ0413
同判決の簡易な解説として、那須翔, デジタルオムニバスGDPR改正法案の理論的意義, https://researchmap.jp/snasu/published_works, 3

*4:那須, 4

*5:WP29, Opinion 05/2014 on Anonymisation Techniques, Adopted on 10 April 2014, https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf

*6:EDPB, Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models, Adopted on 17 December 2024, https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en

*7:HmbBfDI, Discussion Paper: Large Language Models and Personal Data, https://datenschutz-hamburg.de/fileadmin/user_upload/HmbBfDI/Datenschutz/Informationen/240715_Discussion_Paper_Hamburg_DPA_KI_Models.pdf

*8:Case C-136/17, GC and Others v Commission nationale de l’informatique et des libertés (CNIL), EU:C:2019:773 (Sep. 24, 2019), https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:62017CJ0136

*9:Oberlandesgericht Köln, 15 UKl 2/25, ECLI:DE:OLGK:2025:0523.15UKL2.25.00 (May 23, 2025), https://nrwe.justiz.nrw.de/olgs/koeln/j2025/15_UKl_2_25_Urteil_20250523.html

*10:那須, 12

*11:C-604/22, IAB Europe v Gegevensbeschermingsautoriteit, ECLI:EU:C:2024:214 (Mar. 7, 2024), https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:62022CJ0604

*12:EDPB, Guidelines on the concepts of controller and processor in the GDPR, Ver. 2.0, Adopted on 7 July 2021, https://www.edpb.europa.eu/documents/guideline/guidelines-072020-on-the-concepts-of-controller-and-processor-in-the-gdpr_en

令和8年個情法改正法案における統計作成等特例について

統計作成等特例について、雑駁ですが書いていきます。法案公表段階で書いた「統計等特例の条文の読み方」も合わせてご参照ください。

 

改正の内容・背景

  • 統計等特例は、前回記事で述べたとおり、①要配慮個人情報の取得制限の特則、②利用目的による制限・第三者提供制限の特則、③通則からなる。①②は、特例の要件としての当初公表→特例に基づき取得・提供を行った場合の継続公表義務→公表事項の変更時の公表義務→目的外利用禁止という構成である。③は、特例に基づき取り扱うデータの再提供の禁止等を定める。
  • 令和7年3月5日「考え方」では、以下のように述べられていた。
    • 「統計情報等の作成(注1)のために複数の事業者が持つデータを共有し横断的に解析するニーズが高まっていること、特定の個人との対応関係が排斥された統計情報等の作成や利用はこれによって個人の権利利益を侵害するおそれが少ないものであることから、このような統計情報等の作成にのみ利用されることが担保されていること等(注2)(注3)を条件に、本人同意なき個人データ等の第三者提供(注4)(注5)及び公開されている要配慮個人情報の取得を可能としてはどうか(注6)。」
    • 「注1:統計作成等であると整理できるAI開発等を含む。」
    • 「注2:本人同意なき個人データ等の第三者提供については、当該個人データ等が統計情報等の作成にのみ利用されることを担保する観点等から、個人データ等の提供元・提供先における一定の事項(提供元・提供先の氏名・名称、行おうとする統計作成等の内容等)の公表、統計作成等のみを目的とした提供である旨の書面による提供元・提供先間の合意、提供先における目的外利用及び第三者提供の禁止を義務付けることを想定している。」
    • 「注3:本人同意なき公開されている要配慮個人情報の取得については、当該要配慮個人情報が統計情報等の作成又は本規律に基づく本人同意なき個人データ等の第三者提供にのみ利用されることを担保する観点等から、公開されている要配慮個人情報の取得者における一定の事項(取得者の氏名・名称、行おうとする統計作成等の内容又は本規律に基づく本人同意なき個人データ等の第三者提供を行う目的である旨等)の公表、取得者における目的外利用及び第三者提供(本規律に基づく本人同意なき個人データ等の第三者提供を行う目的である場合における当該第三者提供を除く。)の禁止を義務付けることを想定している。」
    • 「注4:法第17条の規定により特定された利用目的の達成に必要な範囲を超える第三者提供を含む。」
    • 「注5:当該提供により提供先が本人同意なく要配慮個人情報を取得することも可能とすることを想定している。」
    • 「注6:具体的な対象範囲や公表事項等は、制度が円滑に運用されるよう、改正の趣旨を踏まえつつ、個人情報保護委員会規則(以下「委員会規則」という。)等で定めることを想定している。」
  • この点について、筆者は、JILISレポートで、以下のように述べていた。
    • 「[統計等特例]は、評価・決定の適切性との関係では、第一[義的]に、個人データが評価・決定に用いられるかが問題であり、それに用いられないこと(非決定利用)が確保される場合には、そもそも第三者提供制限(やその一般法である利用目的による制限)を課す必要がないことを根拠に、非決定利用を確保するための代替的なセーフガードと引き換えに、同意を不要とするものである(評価・決定の利益に優越する他の利益が存在するからではない。)。このような考え方は、事業者内部における統計利用や仮名加工に係る規律との関係では、既に採用されていたものであり、それ自体としては適切だと思われるが、仮名加工情報に係る規律との関係について、さらに検討を要すると思われる。/すなわち、仮名加工は、個人との対応関係を維持しつつ、他の情報と照合しない限り個人を識別できないようにすることであり(法2条5項)、仮名加工後に委託先に提供した場合、委託先にとっては識別性がないため、委託先には個人情報・個人データに係る規制は適用されないものと解されている。[統計等特例]の下でも、(非決定)利用の目的に反しない限り、提供者側で仮名化を行うことは望ましいが、そうすることで、提供先に規制が及ばなくなってしまう可能性がある。これは、識別性解釈が保護法益に対して十分なものとなっていないことに起因するものであるが、識別性解釈を修正するのであれば、仮名加工に係る規律を併せて見直す必要があり、それを先送りするのであれば、受領者に適切な義務を課す必要がある(※)。」。
      • ※について、その後公表された条文案は、識別性解釈の修正を先送りし、「受領者に適切な義務を課す」ことを選んだものといえる。
    • 「個情委は、AI開発を含む非決定利用のための要配慮個人情報の取得を認めることを提案している。しかし、…(a)データベース化しない場合(LLM開発のために収集するテキストデータは通常ここに含まれる。)と(b)データベース化するが決定に利用しない場合は区別すべきであり、(a)はそもそも取得に関する規制の対象としないことが、個情法の体系に適合的である。(b)は、LLMを含む生成AIというよりは、信用スコアリングのような識別AI(非生成AI)の開発において問題となるが、要配慮個人情報の取得制限の保護法益(必ずしも第三者提供制限のそれとは同一ではないと思われる。)に照らした検討が必要である。」
      • 関連する脚注:「要配慮個人情報の保護法益は、必ずしも明らかではない。評価・決定の適切性との関係では、何のために情報を利用するのかが重要であり、情報の性質は重要ではない。プライバシーとの関係でも、Webに公開された情報は、非公知性を欠き、少なくとも収集に対しては保護されない可能性が高い。要配慮個人情報の出力(第三者提供制限の対象とならないと思われる。)の予防のために学習を規制することは考えられないではないが、要配慮個人情報を学習させなかったからといって、要配慮個人情報を出力しなくなるわけではない(LLMにおいて特定の学習用データが特定のパラメータの重みに与える影響は極めて小さく、特定のパラメータが出力に与える影響もまた極めて小さい。)。さしあたり、法的根拠による規制を一般的には行っていない日本法にあって、経験的に不適切に評価されやすい情報について、法的根拠を要求したものと理解した上で…、個別の場面ごとに保護法益を特定し、それに沿って規制を合理化していくほかないと思われる。」
      • 関連する記載(散在情報の規制):「「個情法17条~21条は、文言上、「個人情報」を対象としており、データベース化を予定していない個人情報にも適用されるものと解されている。/もっとも、立案担当者は、データベースは、「…特定の個人が検索可能なものについては、いったん不適正な処理がなされると、個人の権利利益に重大な侵害をもたらしたり、社会問題を引き起こす可能性が高い」とした上で、個情法第4章は、「基本的に…個人情報データベース等を対象としている」とし、「いずれ個人情報データベースに記録され「個人データ」となるものであっても、取得段階では「個人情報」の状態である」ことから、(例外的に、)取得に関する規制は「個人情報」を対象とすることとした、と説明していた。取得に関する規制が個人情報を対象とする理由が、このようなものであるとすれば、データベース化を予定していない個人情報の取得に規制を及ぼす必要はないはずであり、事務局ヒアリングでは、規制の対象を、個人データ(個人データとして「取り扱」うことが予定された個人情報を含む。)に統一することが議論されている。」
      • 関連する記載(体系的構成要件に関する日EUの違い):「LLMの提供について、個情委は直接的には見解を明らかにしていないが、OpenAIに対する注意喚起においては、要配慮個人情報の取得制限及び利用目的の通知・公表のみを問題とされているため、…体系的構成要件を欠き、[個人データ]の「取扱い」(第三者提供)に該当しないと判断されている可能性がある。一方、EUでは、イタリアのデータ保護当局が、同社が個人データ処理を行っていたことを前提に、同社に制裁金を課している。」

 

コメント

  • 【特例が対処する2つの問題】統計等特例は、①要配慮個人情報の取得制限の特則と②利用目的による制限・第三者提供制限の特則を合わせて規定しているが、JILISレポートにも一部書いたとおり、この条文は、2つの問題に対処しようとしている。すなわち、1つは、LLMを開発する事業者が無差別にWebスクレイピングを行うと、たまたま要配慮個人情報が混入してしまう可能性が否定できず、厳格な取得制限が適用されてしまうという問題である(OpenAIの件で問題となった)。もう1つは、複数の事業者が保有する個人データを突合して、よりリッチなデータセットとした上で、統計やAIモデル(生成モデルというよりは識別モデル)を作成する場合、委託(事業者の一方が委託者となり、他方が受託者となる)では行えず、同意が必要になるという問題である。
  • 【散在的取得と体系的取得の並存】ここで重要なことが2つある。1つは、LLMのケースでは、事業者は取得した要配慮個人情報を体系化(=個人に着目して体系的に構成すること。つまり、個人データとして取り扱うこと。)するつもりはないが、統計作成・識別AIモデル開発のケースでは、少なくとも提供者側においては体系化が前提となっているということである(そうでなければ個人データに該当せず、第三者提供制限が適用されない)。もう1つは、統計作成・識別AIモデル開発のケースでも、提供される個人データに要配慮個人情報が含まれていた場合には、「考え方」の注5にあるとおり、受領者は要配慮個人情報を(多くの場合体系化されたな形で)取得することになるということである。これらの結果、要配慮個人情報の取得制限の特則は、散在的・非意図的な要配慮個人情報の取得と、体系的・非意図的な「要配慮個人データ」の取得の双方に適用される。本来2つの異なる場面を対象とする規定が、同じ1つの「特例」としてまとめられているのは、このためなのかもしれないが、そのことが、本来2つの異なる場面を対象としていることを分かりにくくし、議論を混乱させているように思われる。
    • 体系化されているかどうかは、本人の権利との関係でも重要である。本人の権利は保有個人データを対象としているからである。このため、散在的な要配慮個人情報の取得について、特例の要件に従って公表を行わせたとしても、事業者が統計目的を逸脱して、要配慮個人情報を体系化している(ひいては個人に対する評価・決定に使用している)ような場合を除いて、権利行使は認められない。
    • 大臣は、6月5日の閣議後会見で、「音声データ内や医療機関で身体を測定した画像データなどの例を挙げ「(氏名を)一枚一枚を削除していくというのは大変な作業だ」と述べ、対応は困難だとの認識を示した」と報じられているが、(そもそものやり取りの文脈がよく分からないものの、)体系化されたデータとそうではないデータで「大変な作業」かどうかやその度合いは異なるのではないか。
  • 【要配慮個人情報:体系性による解決という選択肢】本来、個人データ保護とは、個人に着目した体系的なデータ処理による権利侵害(意図的に行われたものか、リスクを適切に識別・評価し、低減する能力が欠けているがゆえに生じたものかにかかわらず)を防止するための法体系なので、散在的な情報取得を規制する必然性はなく、立案担当者も、適正取得義務の文脈で、「個人情報」の語を使ったのは取得段階ではデータベースに入力されていないからと説明しているに過ぎなかった。ここからは、取得制限は、体系化を予定している個人情報の取得にのみ適用されるとの解釈も可能であったが、個情委はそのようには解していないようであった。適正取得義務に関する限りでは、このことの弊害は、それほど大きくなかったが、より厳格な要配慮個人情報の取得制限との関係では、弊害が大きくなっていた。このような背景に照らせば、LLMの問題は、要配慮個人情報(に限らないが)の取得制限の適用範囲の合理化によって解決した上で、統計に絞って(要配慮個人情報の取得制限・個人データの第三者提供制限の)特例を設けるという選択肢もあり得たが、そうはされなかった。前者の解決は、規制対象を「個人データの処理」に統一することで達成するのが本筋だという考慮によるのかもしれない。
  • 【第三者提供:「第三者」からの除外という選択肢】第三者提供制限の特例に関しては、契約締結義務と二次提供の禁止が定められており、委託・共同利用に類似の「統制された提供」であるとの指摘がある。この発想からすると、なぜ(委託・共同利用と同様に)第三者からの除外(これが合理的であることは、板倉先生もどこかのタイミングで言及されていた。)にしなかったのかは分からないが、①適用除外要件として書くには長すぎる、②要配慮個人情報の取得制限の特例と合わせて書きたかった、③関連する義務(目的外利用禁止)を課徴金の対象とするためには、積極的な義務として規定する必要があった、といった考慮によるのかもしれない。なお、共同利用で足りるとの指摘もなされているが、個情委が共同利用を積極的に推しにくいのは、共同利用の規律密度が低すぎることによるのではないかの裏返しなのではないか(この点に限らず、平成27年以降の改正は、個情法の脆弱な基本構造を放置して、それによって生じる個別の問題について、弥縫策の寄せ集めによって対応してきたようなところがある。次回の見直しでは、抜本的な見直しが不可欠である。)。
  • 【特例業務を適正に実施するための体制整備】統計等特例業務の適正な実施(ひいては信頼の醸成)をどのようにして図るかは難しい。ひとまず考えられることは、「統計等特例を信頼される形で適用するためにはどうすればよいか」に書いたが(すなわち、①DPOの選任と実効的な内部統制、②実効的な内部監査、③安全管理措置を適切に適用すること、④確認・記録義務を確実に履行すること、⑤DPIAの実施、⑥問い合わせ、苦情処理、権利行使への対応のための体制整備・対応の記録、⑦以上の枠組みの取締役会による統治、⑧当局届出・年次報告、⑨当局の監督)、もう少し場面を分け、かつ、法律事項、委員会規則事項、ガイドライン事項(ベースライン/ベスプラ)を分けて考える必要があろう。
  • 【次世代医療基盤法との関係/提供側のデューデリジェンス】後知恵だが、次世代医療基盤法との関係は、もう少し丁寧に検討する必要があったのかもしれない。例えば、要配慮個人情報である個人データについては特例の対象から外したり(オプトアウト制度と同様に)、次世代医療基盤法のような特別法が規律する領域については特例の対象から外すことは、少なくとも選択肢として考慮されてもよかった(公表資料に出てきていないだけで、事務局では一定の検討はしてたのだろうが)。一方で、ヘルスケアデータの収集過程を考えると、医療機関がヘルステック企業にデータを提供する場面が典型的であり、当該場面に関する限り、提供元にゲートキーパーとしての役割を期待しうる。当該役割を法的に強制する根拠は直ちには見当たらないが(拡張的に解釈するのだとすれば、安全管理措置のうちの組織的安全管理措置だろうか)、いずれにせよ、GDPR24条1項のような包括的な義務を課し、第三者提供時のデューデリジェンス(もちろん、その内容・手続は場面によって異なってよい。)を法令上も明確に求めるべきではないか。
  • 【次回の見直しに向けて:法的根拠規制とコンプライアンス】一連の反応を見て思ったのは、要配慮個人情報の取得制限の単純な廃止は困難だということである。近時、要配慮個人情報の取得制限(を含むセンシティブデータ規制)の不合理性が指摘されており(要するに、個人データ保護の目的からすれば、個人データ処理のリスクは処理の目的・態様から生じるのであって、内容から生じるのではないということである。「GDPRの基本概念に関するメモ:個人データ、コントローラー、法的根拠」、「デジタルオムニバスGDPR改正法案の理論的意義」参照)、筆者はそれを支持するが、単純な廃止は受け入れられない可能性が高い。現状、要配慮個人情報の取得と第三者提供にのみ適用されている「法的根拠規制」を個人データ処理全体に及ぼし、不適正利用禁止をネガティブリストからポジティブリストに転換するというナラティブで、それらを法的根拠規制に置き換えることによって合理化するほかないように思われる。なお、この場合、個情委のエンフォースメント・企業のコンプライアンス実務(EUの言う「アカウンタビリティ」とはそういうことである。)をどのような内容・方法で形成していくかが決定的に重要である(DPO、DPIA、制裁金はそのためのツールに過ぎない)。「統計等特例を信頼される形で適用するためにはどうすればよいか」や「個情法の安全管理措置・体制整備に関するメモ」に書いたことは、そのための試論でもある。

統計等特例の条文の読み方

注:本記事は4月8日にNoteに投稿した記事を、Noteの整理に伴い再投稿するものです。

昨日公表された「個人情報の保護に関する法律等の一部を改正する法律案」に含まれる統計等特例(30条の2)について、条文を転記した上で、現時点で気づいたことを書いていきます。理論的な分析・批判というよりは、文言の分析が中心です。一読してのメモに過ぎないので、その前提でお読みください。

 

条文

(定義)

第2条

13 この法律において「統計作成等」とは、統計の作成その他の大量の情報から当該情報を構成する要素に係る情報を抽出して分類、比較その他の解析を行うことにより、当該大量の情報の傾向又は性質に係る情報(個人に関する情報であるものを除く。)を作成する行為のうち、個人の権利利益を害するおそれが少ないものとして個人情報保護委員会規則で定めるものをいう。

 

(個人情報に係る統計作成等の特例)

【要配慮個人情報の取得制限の特則】

第30条の2 個人情報取扱事業者は、統計作成等を行う目的(以下この項及び第5項並びに第31条の3第1項において「統計作成等目的」という。)又は第5項本文の規定による提供を行う目的で現に公開されている要配慮個人情報を取り扱う必要がある場合(当該要配慮個人情報を取り扱う目的の全部が統計作成等目的又は当該提供を行う目的である場合に限る。)であって、インターネットの利用その他の個人情報保護委員会規則で定める方法により当該個人情報取扱事業者の氏名又は名称、取得した要配慮個人情報を用いて行おうとする統計作成等の内容又は同項本文の規定による提供を行う目的で当該要配慮個人情報を取り扱う旨その他個人情報保護委員会規則で定める事項を公表しているときは、第20条第2項の規定にかかわらず、当該現に公開されている要配慮個人情報を本人の同意を得ないで取得することができる。

2 前項の規定により要配慮個人情報を取得した個人情報取扱事業者(次項及び第4項並びに第72条の3第1項において「特例要配慮個人情報取得者」という。)は、前項の個人情報保護委員会規則で定める方法により、当該要配慮個人情報又はその全部若しくは一部を複製し、若しくは加工した生存する個人に関する情報を取り扱っている期間、同項に規定する事項(当該事項を次項本文の規定により変更した場合又は同項ただし書の場合にあっては、変更後の当該事項)を継続して公表しなければならない。

3 特例要配慮個人情報取得者は、前項の規定により公表している事項を変更するときは、あらかじめ、第1項の個人情報保護委員会規則で定める方法により、その旨及び当該変更の内容を公表しなければならない。ただし、当該特例要配慮個人情報取得者の氏名又は名称その他個人情報保護委員会規則で定める事項を変更するときは、当該変更をした後、速やかに、同項の個人情報保護委員会規則で定める方法によりその旨及び当該変更の内容を公表すれば足りる。

4 第1項の規定により取得された要配慮個人情報又はその全部若しくは一部を複製し、若しくは加工した生存する個人に関する情報(第6項に規定する提供統計作成等用個人情報等であるものを除く。以下「統計作成等用要配慮個人情報等」という。)を取り扱う個人情報取扱事業者は、第18条の規定にかかわらず、法令に基づく場合及び人命の救助、災害の救援その他非常の事態への対応のため緊急の必要がある場合(以下この章において「法令に基づく場合等」という。)を除くほか、当該統計作成等用要配慮個人情報等を、次の各号に掲げる場合の区分に応じて、当該各号に定める行為を行うために必要な範囲を超えて取り扱ってはならない。

一 当該統計作成等用要配慮個人情報等に係る特例要配慮個人情報取得者が第2項の規定により当該統計作成等用要配慮個人情報等に係る要配慮個人情報を用いて行おうとする統計作成等の内容を公表している場合(第3号に掲げる場合を除く。) 当該公表されている内容の統計作成等

二 当該統計作成等用要配慮個人情報等に係る特例要配慮個人情報取得者が第2項の規定により次項本文の規定による提供を行う目的で当該統計作成等用要配慮個人情報等に係る要配慮個人情報を取り扱う旨を公表している場合(次号に掲げる場合を除く。) 当該提供

三 当該統計作成等用要配慮個人情報等に係る特例要配慮個人情報取得者が第2項の規定により当該統計作成等用要配慮個人情報等に係る要配慮個人情報を用いて行おうとする統計作成等の内容及び次項本文の規定による提供を行う目的で当該要配慮個人情報を取り扱う旨を公表している場合 当該公表されている内容の統計作成等及び当該提供

【利用目的による制限・第三者提供制限の特則】

5 個人情報取扱事業者は、第三者(個人情報取扱事業者又は行政機関の長等(第63条に規定する行政機関の長等をいう。第9項第2号、第12項並びに第31条の3第5項第2号及び第8項において同じ。)(これらの者が外国にある者である場合にあっては、個人情報、仮名加工情報、匿名加工情報及び個人関連情報(以下「個人情報等」という。)の取扱いについてこの章の規定により個人情報取扱事業者、仮名加工情報取扱事業者、匿名加工情報取扱事業者及び個人関連情報取扱事業者(以下「個人情報取扱事業者等」という。)が講ずべきこととされている措置に相当する措置(第13項及び第31条の3第9項において「相当措置」という。)を継続的に講ずるために必要なものとして個人情報保護委員会規則で定める基準に適合する体制(第13項及び第31条の3第9項において「基準適合体制」という。)を整備している者に限る。第12項及び第31条の3第8項において同じ。)である者に限る。以下この項、次項並びに第31条の3第1項及び第2項において同じ。)が個人情報(統計作成等用要配慮個人情報等を含む。以下この項から第7項まで及び第13項並びに第72条の3第2項及び第3項において同じ。)を統計作成等目的で取り扱う必要がある場合(当該個人情報を取り扱う目的の全部が統計作成等目的である場合に限る。)であって、次の各号のいずれにも該当するときは、第18条及び第27条第1項の規定にかかわらず、当該個人情報を本人の同意を得ないで当該第三者に提供することができる。ただし、当該個人情報が他の個人情報取扱事業者又は個人関連情報取扱事業者からこの項本文又は第31条の3第1項本文の規定により提供されたもの(その全部又は一部を複製し、又は加工したものを含む。)である場合は、この限りでない。

一 当該個人情報取扱事業者及び当該第三者が、インターネットの利用その他の個人情報保護委員会規則で定める方法により、当該個人情報取扱事業者及び当該第三者の氏名又は名称、行おうとする統計作成等の内容その他個人情報保護委員会規則で定める事項を公表していること。

二 当該第三者との間の書面(電磁的記録を含む。)による合意により、当該提供がこの項本文の規定によるものである旨が明確に定められていること。

6 前項本文の規定により個人情報の提供を受けた第三者(個人情報取扱事業者である者に限る。以下この条及び第72条の3第5項第1号において「特例個人情報受領者」という。)は、前項第1号の個人情報保護委員会規則で定める方法により、当該個人情報又はその全部若しくは一部を複製し、若しくは加工した生存する個人に関する情報(以下「提供統計作成等用個人情報等」という。)を取り扱っている期間、同号に規定する事項(当該事項を次項本文の規定により変更した場合又は第8項の場合にあっては、変更後の当該事項)を継続して公表しなければならない。

7 特例個人情報受領者は、第5項第1号の個人情報保護委員会規則で定める方法により当該特例個人情報受領者及び同項本文の規定により当該特例個人情報受領者に対する個人情報の提供を行った個人情報取扱事業者の双方が前項の規定により公表されている事項を変更する旨及び当該変更の内容をあらかじめ公表する場合に限り、当該事項を変更することができる。ただし、当該特例個人情報受領者の氏名又は名称その他個人情報保護委員会規則で定める事項を変更するときは、この限りでない。

8 前項ただし書の場合においては、特例個人情報受領者は、当該変更をした後、速やかに、第5項第1号の個人情報保護委員会規則で定める方法により当該変更をした旨及び当該変更の内容を公表しなければならない。

9 提供統計作成等用個人情報等を取り扱う個人情報取扱事業者は、第18条の規定にかかわらず、法令に基づく場合等を除くほか、当該提供統計作成等用個人情報等を、次の各号に掲げる場合の区分に応じて、当該各号に定める統計作成等を行うために必要な範囲を超えて取り扱ってはならない。

一 当該提供統計作成等用個人情報等に係る第5項本文の規定による提供が特例個人情報受領者に対して行われたものである場合 当該特例個人情報受領者が第6項の規定により公表している内容の統計作成等

二 当該提供統計作成等用個人情報等に係る第5項本文の規定による提供が行政機関の長等に対して行われたものである場合 当該行政機関の長等が第72条の3第2項の規定により公表している内容の統計作成等

【通則】

10 統計作成等用要配慮個人情報等又は提供統計作成等用個人情報等を取り扱う個人情報取扱事業者は、第27条第1項及び第2項並びに第28条第1項の規定にかかわらず、次に掲げる場合を除くほか、当該統計作成等用要配慮個人情報等又は提供統計作成等用個人情報等である個人データを第三者に提供してはならない。この場合において、第27条第5項中「は、前各項」とあるのは「(個人情報取扱事業者又は第63条に規定する行政機関の長等(これらの者が次条第1項に規定する外国にある者である場合にあっては、第30条の2第5項に規定する基準適合体制を整備している者に限る。)である者に限る。)は、第30条の2第10項」と、同項第3号中「、本人に通知し、又は本人が容易に知り得る状態に置いて」とあるのは「公表して」と、同条第6項中「、本人に通知し、又は本人が容易に知り得る状態に置かなければ」とあるのは「公表しなければ」と、第29条第1項ただし書中「同条第1項各号又は第5項各号のいずれか(前条第1項の規定による個人データの提供にあっては、第27条第1項各号のいずれか)」とあるのは「第30条の2第4項に規定する法令に基づく場合等又は第27条第5項各号のいずれか」と、前条第1項ただし書中「第27条第1項各号又は第5項各号のいずれか」とあるのは「次条第4項に規定する法令に基づく場合等又は第27条第5項各号のいずれか」とする。

一 法令に基づく場合等

二 当該個人情報取扱事業者が、第1項の規定により要配慮個人情報を取得し、かつ、第2項の規定により第5項本文の規定による提供を行う目的で当該要配慮個人情報を取り扱う旨を公表している場合であって、当該個人情報取扱事業者が当該要配慮個人情報に係る統計作成等用要配慮個人情報等を同項本文の規定により提供するとき。

11 統計作成等用要配慮個人情報等又は提供統計作成等用個人情報等を取り扱う個人情報取扱事業者は、第31条第1項の規定にかかわらず、前項各号に掲げる場合を除くほか、当該統計作成等用要配慮個人情報等又は提供統計作成等用個人情報等(これらのうち個人データであるものを除く。次項において同じ。)を第三者に提供してはならない。

12 第27条第5項及び第6項の規定は、統計作成等用要配慮個人情報等又は提供統計作成等用個人情報等の提供を受ける者(個人情報取扱事業者又は行政機関の長等である者に限る。)について準用する。この場合において、同条第5項中「前各項」とあるのは「第30条の2第11項」と、同項第3号中「、本人に通知し、又は本人が容易に知り得る状態に置いて」とあるのは「公表して」と、同条第6項中「、本人に通知し、又は本人が容易に知り得る状態に置かなければ」とあるのは「公表しなければ」と読み替えるものとする。

13 第5項本文の規定により個人情報を基準適合体制を整備している外国にある第三者に提供し、又は統計作成等用要配慮個人情報等若しくは提供統計作成等用個人情報等を当該第三者に提供した個人情報取扱事業者は、個人情報保護委員会規則で定めるところにより、当該第三者による相当措置の継続的な実施を確保するために必要な措置を講ずるとともに、当該必要な措置に関する情報を公表しなければならない。この場合においては、第28条第3項の規定は、適用しない。

14 第23条から第25条までの規定は個人情報取扱事業者による統計作成等用要配慮個人情報等又は提供統計作成等用個人情報等(これらのうち個人データであるものを除く。)の取扱いについて、第29条第1項本文及び第2項の規定は第5項本文の規定により個人情報取扱事業者が統計作成等用要配慮個人情報等(第31条第1項に規定する個人関連情報であるものに限る。)を特例個人情報受領者に提供する場合(当該特例個人情報受領者が当該統計作成等用要配慮個人情報等を個人データとして取得することが想定される場合に限る。)について、それぞれ準用する。この場合において、第23条中「漏えい、滅失又は毀損」とあるのは、「漏えい」と読み替えるものとする。

 

コメント

  • 30条の2は、1項〜4項、5項〜9項、10項〜14項の3グループに分かれる。第1グループが要配慮個人情報の取得制限の特則、第2グループが利用目的による制限・第三者提供制限の特則、第3グループが通則的なものである。
  • 第2グループで「個人データ」ではなく「個人情報」の文言が使われているのは、27条1項だけでなく18条1項を適用除外する必要があるからだと思われる。
  • 第1・第2グループは、それぞれ、特例の要件としての当初公表→特例に基づき取得・提供を行った場合の継続公表義務→公表事項の変更時の公表義務→目的外利用禁止という構成となっている。第1グループは一者で完結するのでより単純で、第2グループは提供者と受領者が関与する(かつ外国や委託等が関わる)のでより複雑である。
  • 目的外利用禁止は、公表された内容の統計作成に紐づけられている。特例の趣旨からすれば、統計作成目的を逸脱しない限り(さらに言えば、評価・決定に使用しない限り)、取扱いを許容してもよいはずだが、そうしなかったのは、公表義務のエンフォースメントに主眼があるのだろう。
  • 目的外利用禁止は、特例に基づき取得された/提供を受けた(要配慮)個人情報だけでなく、その複製・加工物も対象となる(統計作成等用要配慮個人情報等、提供統計作成等用個人情報等の定義にそれらが含まれており、これらの概念が使われている場合には、そのことを念頭に置く必要がある)。
  • 要配慮個人情報に関する統計等特例(第1グループ)と、第三者提供制限等に関する統計等特例(第2グループ)は、併用できる。30条の2第1項の「又は第5項本文の規定による提供を行う目的で」と、5項の「統計作成等用要配慮個人情報等を含む。」がこのことを表現している。
  • 30条の2第5項は、「第三者」を個人情報取扱事業者又は行政機関の長等に限定しているので(同項第1かっこ書き)、データセットの一般公開のようなことはできない。
  • 27条1項は、外国にある者にも適用されうるが(基準適合体制を整備した者がそれに該当する。28条1項本文第3括弧書き、ただし書き)、統計等特例は、この場合にも適用される(30条の2第5項の第1かっこ書き中の第2かっこ書き参照)。
  • 特例に基づき提供を受けた個人情報等の第三者提供(二次提供)は、禁止される。個人データであるものについては30条の2第10項前段、そうでないものについては30条の2第11項が根拠である。この場合でも、委託、共同利用等は認められる。個人データについては、30条の2第10項後段で読み替えの上適用される27条5項が根拠、非個人データについては、30条の2第12項で読み替えの上準用される27条5項が根拠。
  • 些末だが、「基準適合体制」はこれまでガイドラインの用語だったが、法律上定義される。
  • 30条の2第13項は、基準適合体制を整備している外国第三者への提供時の、相当措置の継続実施確保のための措置義務と、公表義務を定める。本項は、個人データ以外の個人情報や、個人情報ではない統計作成等用要配慮個人情報等・提供統計作成等用個人情報等との関係では、新規の規定であり、個人データとの関係では、28条3項を上書きする規定である。上書きするのは、取るべき措置の内容・公表すべき事項が異なりうるからかもしれない(規則委任されている)。
  • 30条の2第14項は、統計作成等用要配慮個人情報等・提供統計作成等用個人情報等のうち、個人データでないものについて、安全管理義務を準用している。準用に当たって、「漏えい、滅失又は毀損」が「漏えい」と読み替えられているが、これは、統計等作成目的のデータセットは、漏洩により権利侵害が生じる可能性はあるものの、滅失・毀損により権利侵害が生じる可能性は小さい(統計が不正確なものとなりうるに過ぎない)ことによるものと思われる。
  • 課徴金制度においては、①27条1項違反の個人データの第三者提供、②30条の2第4項・9項(統計作成等用要配慮個人情報等・提供統計作成等用個人情報の目的外利用の禁止)に違反する個人情報の取扱い、③30条の2第10項・11項(統計作成等用要配慮個人情報等・提供統計作成等用個人情報である個人データの第三者提供の禁止)に違反する個人情報の提供が、課徴金対象行為とされている(148条の3第1項3号、4号、5号)。提供が特例の要件を満たさない場合(例えば、当初公表を行わなかった場合には)、単なる27条1項違反となるので、①が適用され、特例の要件を満たして提供を受けた個人情報を、30条の2の義務に違反して取り扱った場合には、②又は③が適用されることになる。
  • 本人の権利との関係でも、利用停止請求等ができる場合に、30条の2第4項・9項、30条の2第10項の違反が追加されている(35条1項、3項)。30条の2第11項の違反が追加されていないのは、利用停止請求権等は、基本的に、保有個人データを対象としており、非個人データに関する違反を対象とすることは整合しないからであろう。

令和8年個情法改正法案における第三者提供制限の例外事由について

個情法27条1項各号の改正案について書いていきます。この論点は、統計作成等特例(30条の2)と比べてあまり注目されていませんが、実務上、重要な論点を生じさせるものであり、かつ、「個情法のパラダイムシフト」に向けた重要な意義を有すると思います。

 

改正の内容

  • 個情法27条1項は、個人データの第三者提供について、原則として同意を要求し、例外として、①法令に基づく場合、②生命・身体・財産の保護に必要かつ同意取得困難な場合、③公衆衛生向上・児童健全育成に特に必要かつ同意取得困難な場合、④国等の事務遂行の協力する必要があり、かつ、同意取得により事務遂行に支障を及ぼすおそれがある場合、⑤学術研究、を定めている。
  • 法案27条1項2号(正確には法案成立・施行による改正後の個情法27条1項2号だが、便宜上このように記載する。)・3号は、「本人の同意を得ることが困難であるときその他本人の同意を得ないことについて相当の理由があるとき。」とし(下線部が追加部分)、同意取得困難性を緩和する。
  • 法案27条1項8号は、「本人との間の契約の履行のために必要やむを得ないことが明らかである場合その他当該個人データの取得の状況からみて本人の意思に反しないため本人の権利利益を害しないことが明らかである場合として個人情報保護委員会規則で定める場合」を定める(新設)。

 

背景

  • EU法では、個人データの収集を含む処理全般について法的根拠が必要とされており、民間企業が広く依拠しうるものとしては、①データ対象者が1つ又は複数の具体的な目的のための処理に同意した場合、②データ対象者が当事者となっている契約の履行又は契約締結に先立ってデータサブジェクトの要求に応じて行われる対応に処理が必要な場合、③コントローラー又は第三者が追求する正当な利益のために処理が必要な場合(ただし、データサブジェクトの利益が当該正当利益に優越する場合を除く。)が定められている。
  • 令和7年3月5日「考え方」では、
    • 契約履行について、「個人データの第三者提供等が契約の履行のために必要不可欠な場合を始め、目的外利用、要配慮個人情報取得又は第三者提供が本人の意思に反しないため本人の権利利益を害しないことが明らかである場合(注7)について、本人の同意を不要としてはどうか。」とされ、注7で、「例えば、本人が、事業者Aの運営するホテル予約サイトで事業者Bの運営するホテルの宿泊予約を行ったため、事業者Aが事業者Bに当該本人の氏名等を提供する場合や、金融機関が海外送金を行うために送金者の情報を送金先の金融機関に提供する場合等が想定される。具体的な対象範囲は…委員会規則等で定めることを想定している。」とされていた。
    • 同意取得困難性について、「…事業者・本人の同意取得手続に係る負担を軽減し、個人情報のより適正かつ効果的な活用及びより実効的な個人の権利利益の侵害の防止につなげる観点から、「本人の同意を得ることが困難であるとき」のみならず、「その他の本人の同意を得ないことについて相当の理由があるとき」(注8)についても、上記例外規定に依拠できることとしてはどうか。」とされ、注8で、「例えば、(公衆衛生の向上のために特に必要である一方で、)本人のプライバシー等の侵害を防止するために必要かつ適切な措置(氏名等の削除、提供先との守秘義務契約の締結等)が講じられているため、当該本人の権利利益が不当に侵害されるおそれがない場合等が想定される。具体的な事例については…ガイドライン等において明確化することを想定している。」とされていた。
  • なお、この点について、筆者は、JILISレポートで、以下のように述べていた。
    • 契約履行について、「…必ずしも活発な議論の対象となっていないが、次のような効果があると思われる。すなわち、従前、日本法においては契約履行のための提供が許容されていなかったため、契約履行に必要な提供について、利用規約やプライバシーポリシーに記載し(ただし提供先や提供先での利用目的は記載せず)、同意ボタンを押させることで包括的に同意を取得することが広く行われていた。契約履行を同意から分離することで、契約履行に必要な提供については、真に必要な提供なのかを厳密に判断し、同意に基づく提供については、同意の任意性(例えば、必要な情報提供がなされているか、契約との「抱き合わせ」や複数の利用目的の「抱き合わせ」がなされていないか、力の不均衡がないかや提供が同意の範囲に含まれるかを、厳密に判断することができるようになる。」
    • 同意取得困難性について、「公衆衛生例外及び学術研究例外については、[統計等特例]との関係を整理する必要がある。すなわち、現にニーズのある公衆衛生目的の提供及び学術研究目的の提供の少なくない部分は非決定利用であると思われるところ、そのような利用は、[統計等特例]によって統制すべきである。この場合、公衆衛生例外及び学術研究例外(なお、これらが重複しうることにも留意すべきである。)は、決定利用に適用されることになるが、この場合、研究倫理指針などの代替的セーフガードが必要である。」、「生命等保護例外(及び公衆衛生等例外)については、(i)人格権が含まれるか明らかではない、(ii)財産の処分が含まれない(この結果、債権譲渡の文脈では、推定的同意すら認められている。)、(iii)(必ずしも個々に権利保護を目的としたものとは言い難い)犯罪対策において、提供できる場合が限定されるといった問題が生じている。正当利益による第三者提供を認めないのであれば、(i)(ii)については、別途権利行使のための提供を認め、(iii)については、公衆衛生等例外の拡張や別途情報共有のルールを定めるといったことを検討する必要があると思われる。」

 

コメント

  • 契約履行関係
    • 現在、利用規約やプライバシーポリシーによる同意取得が広く行われているが、同意は、具体的な対象に対して、十分な情報に基づいて与えられない限り、端的に言って無意味である。JILISレポートで述べたとおり、契約履行を独立の例外事由とし、同意から分離することで、同意に本来求められる任意性(具体性、情報に基づくこと、抱き合わせの不存在はその要素である。)を求めることができるようになる。
    • 一方で、契約履行の範囲は、GDPR第6条1項(b)よりも相当程度広いことに留意する必要がある。GDPRにおける契約履行については、Bundeskartellamt判決により、処理が、「データ対象者のために意図された契約上の給付(注:英語版ではobligationとされているが、文脈や独仏語版を考慮すると「給付」が正しいと思われる。)に不可欠な(integral to)目的のために客観的に不可避(objectively indispensable)」でなければならないとされている。同事件では、Meta社は、コンテンツのパーソナライゼーションやFacebook / Instagram / WhatsAppのシームレスな使用(当該事案ではサービス横断的な突合が問題となっていた。)を主張したが、これらについては、上記の意味での不可欠性は認められなかった。日本法について言えば、「本人との間の契約の履行のために必要やむを得ないことが明らかである場合」はある程度限定的と言えるが、「その他当該個人データの取得の状況からみて本人の意思に反しないため本人の権利利益を害しないことが明らかである場合」は相当に広い(委員会規則次第であるが)。
    • ところで、GDPRでは、正当利益(の利益衡量テスト)に関して、データ対象者の予測可能性(reasonable expectation. 米国の修正4条のreasonable expectation (of privacy)が保護のexpectationなのに対して、GDPRのそれは処理が行われることへの expectationであることに留意。このため、「予測可能性」と訳す。)を重要な考慮要素としている。この点の解釈は確立していないが、ひとまず、感覚としては、予測可能性がある場合には正当利益が優越し、ない場合にはデータ対象者の利益が優越する方向に傾くが、予測可能性があってもデータ対象者に重大な不利益をもたらす場合には、例外的に処理が適法化されない余地があり、逆に、予測可能性がなくても正当利益が強固なものである場合には、例外的に処理が適法化される余地がある、ということだと思われる。「その他当該個人データの取得の状況からみて本人の意思に反しないため本人の権利利益を害しない」とは、このうち、予測可能性があり、かつ、データ対象者に重大な不利益をもたらさない場合をカバーしているように見える。具体的なことは、委員会規則の案を見なければ分からないが、ひとまず、このような視点を持っておく必要がある。
  • 同意取得困難性
    • こちらについては、JILISレポートで述べたようなことへの考慮はあまりなされなかったようである。公衆衛生例外については、Q&A 7-25で、コストを理由とする同意取得困難性が(すら)認められており、「相当の理由」を正面から認め、「考え方」注8のような措置を要求することは、それを適正化する意味があったはずだが、別途統計等特例が設けられたことにより、その意義が減殺されている(さらに、統計等特例との関係で言えば、統計等特例の比較的厳格な規律に対する抜け穴となってしまっている)ように思われる。
    • 一方、JILISレポートで述べたような犯罪対策(財産保護例外に依拠するのが通常であろう。)との関係では、「相当の理由」として、同意取得により財産保護の目的を阻害するおそれがあることが示されれば、多少使いやすくはなるかもしれない。
    • GDPRとの比較で言えば、2号・3号は、正当利益の一部を限定列挙したものと言える。2号と3号を対比すると、2号は権利保護目的(=特定の者の利益を図る)、3号は公益目的(=不特定者の利益を図る)の提供に関する一般規定と言えるが、特に3号の列挙する公益は極めて限定的である。正当利益を正面から導入すべきだと考えるが、そのためには、強力なコンプライアンス体制と執行体制が不可欠であり(いかに実務を形作るかが重要であり、権限強化はその第一歩に過ぎない。)、次回の3年ごと見直しまでに当局、企業、消費者団体等、専門職(≒個人データ保護を専門とする弁護士)、研究者の間で共通認識を形成していく必要がある。

個情法の安全管理措置・体制整備に関するメモ

世古先生の単著『個人情報保護法に基づくインシデント対応の実務』をレビューさせていただく中で、安全管理措置・体制整備に関していくつか思ったことがあるので、書いていきます。

 

個情法通則ガイドライン関係

  • 個情法通則ガイドライン10は、個情法のガイドラインであるにもかかわらず、情報セキュリティが中心の内容となっており、個人データ保護に関する記載が十分ではないように思われる。10-3(3)は、データマッピングのようなことを述べているが、データマッピング・ツールキットも合わせて読むと、情報セキュリティにおける情報資産台帳に個情法に関連する項目を付け足す発想で書かれている節があり、個人の権利保護や、そのためのリスクアセスメントに役立つ内容には必ずしもなっていない。この点については後述する。
  • 個情法通則ガイドライン10を情報セキュリティに関するガイドラインとして見た場合、まず、経営者のリーダーシップという基本的な要素が抜けている。この点については、経産省サイバー経営ガイドライン、IPA中小企業ガイドライン、金融庁サイバーガイドラインが参考になる。
  • それ以外の点については、項目レベルではそれなりに網羅的だが、具体的な管理策に関しては、全く十分ではない(そもそも管理策のリストとして使われることは想定していないものと思われる。)。IPA中小企業ガイドライン、金融庁サイバーガイドライン、ISO/IEC 27001 / 27002、NIST CSF / SP 800-53などによる補完が必要である。
  • なお、それらのガイドラインを参照して具体的な管理策を設計した上で、法令遵守の観点から通則ガイドラインを参照することは考えられるが、以下の点には留意が必要である。
    • 通則ガイドラインは、個人情報の取扱いと部署が概ね対応関係にあり、かつ、部門横断的なデータ利活用がそれほど多くない、伝統的企業を念頭に置いている節がある。そのような条件が当てはまらない企業においては、当該企業の業務・組織に応じた体制整備が必要である(無理に通則ガイドラインに合わせる必要はない)。
    • 通則ガイドラインの物理的安全管理措置の箇所は、オンプレミスサーバやリムーバブルメディアなどの伝統的なIT機器を念頭に置いている節がある。クラウドサービスが中心の環境においては、必ずしも物理的安全管理措置は必要ないが、逆に、委託先管理や技術的安全管理措置(特に認証・認可)は、より慎重に行う必要がある。
    • 些末だが、通則ガイドライン10-6の「(1)アクセス制御」と「(2)アクセス者の識別と認証」の記載は適切ではない。(1)は、実際には、認可(authorization)を意味しているようであり、アクセス制御は認証(authentication)と認可の総称である。また、順番的には、認証→認可が自然である。
    • 「中小規模事業者における手法の例示」は、従業者数100人以下の事業者を対象とした上で、そこから個人データの対象者数が5000人以上の者が除かれているが、実際には、後者が重要である。CtoCオンラインサービスを提供するスタートアップの場合、正社員は10人以下、業務委託を含めても20〜30人だが、個人データの対象者数は数万人、ということが容易にありうるが、このような場合、「中小規模事業者」レベルでは足りない(M&Aなら、レッドフラッグとは言わないが、PMIにおける重要な改善事項となろう)。

 

セキュリティ関係

  • 政府系ガイドライン
    • 経産省サイバー経営ガイドラインは、サイバーセキュリティにおける経営者の責務を説いており、経営者や取締役会を説得する材料になると思われる。
    • IPA中小企業ガイドラインは、中小企業向けとはされているものの、第2部の「4. より強固にするための方策」まで含めると、相当しっかりしたことが書かれており、規模にかかわらず、これから真面目に(特に経営レベルで)セキュリティに取り組もうという組織のほとんどは、まずはここから入るのがよいと思われる。
    • 金融庁サイバーガイドラインは、後述のNIST CSFベースで書かれており、経営者の責務、フレームワーク、具体的な管理策(基本/応用)をカバーしている。金融機関特有の記載は実はそれほど多くはないので、金融機関以外でも、IPA中小企業ガイドラインの次のステップとして参考にしてもよいかもしれない。
  • 技術標準
    • 基本的には、国際標準であるISO/IEC 27001 / 27002や、米国の連邦政府向けだがより詳細であり、民間においても参考にされることの多いNIST CSF / SP 800-53を参照することになると思われる。
  • なお、個情法通則ガイドライン10にも共通することであるが、これらのセキュリティ基準は汎用的なものであり、個別のサービス・プロダクトや、個別の業務に関連するセキュリティについては、別途検討する必要がある。この点については、例えば、IPA中小企業ガイドライン、IPAの「安全なウェブサイトの作り方」、デジ庁のデジタルアイデンティティガイドライン・解説書、総務省の「クラウドサービス利用・提供における適切な設定のためのガイドライン」・「クラウドの設定ミス対策ガイドブック」が参考になる。

 

個人データ保護関係

  • 個人データ保護は、セキュリティと比べると未成熟であり、かつ、考え方や必要な知識も相当異なるので、まずセキュリティ管理体制を整備した上で、「差分」を考えるのがよいと思われる。
  • 個人データ保護の観点から必要な体制整備としては、必ずしも安全管理の枠組みに収まらないが、①内部統制(DPOを含む)、②内部監査、③苦情・権利行使への対応のための体制、④インシデントへの対応のための体制、⑤リスクアセスメント(DPIA)、⑥委託先管理が考えられる。これらは個人データ保護以外の目的(例えば金商法の開示規制・東証規則、会社法、業法、サイバーセキュリティ)との関係でも必要とされるものであり、そこに個人データ保護を組み込むのが通常だと思われるが、その場合でも、個人データ保護の観点がおざなりにならないようにする必要がある。
  • これらについて、個情委が「個人データの取扱いに関する責任者・責任部署の設置に関する事例集」、「データマッピング・ツールキット」、「PIAの取組の促進について-PIAの意義と実施手順に沿った留意点-」と、関連する委託調査報告書を公表している。
  • 一方で、EU法は、個情法よりも強力なコンプライアンスを求めているところ、特にDPOとDPIAに関する文書は、日本における実務の参考にもなると思われる。
    • 内部統制については、ICOのDPOガイダンスや、EDPBのDPOガイドラインが参考になる。EU法では、公的機関や一定のハイリスク処理を行うコントローラーには、DPOの選任が義務付けられる。DPOは、個人情報保護に関する知識・経験を有し、経営者に直接レポーティングし、必要な権限とリソース(DPO自身が職務を遂行するのに十分な時間、必要な場合DPOを補助する内部管理部門を含む。)の割り当てを受け、個人データ処理業務からの独立性が保障される(=利益相反の防止)ものでなければならない。日本では、証券会社の内部管理について、このような責任者の選任が義務付けられている。
    • リスクアセスメントについては、ICOのDPIAガイダンス・テンプレート、EDPBのガイドライン・テンプレート案が参考になる。EU法では、一定のハイリスク処理を行う場合には、DPOの助言の下でのDPIAの実施と、当局への事前協議が義務付けられている。当局は、当該協議を契機として、調査や是正勧告を行っている。
  • 上記の6つの体制整備事項のうち、①〜④は、ここで挙げた文書を参考に、自組織の状況を考慮すれば、どの程度のものを整備すべきかはある程度明らかになるものと思われる。一方、⑤のリスクアセスメントや、⑥の委託先管理は、特に実務が未成熟で、悩みが多いものと思われる。
  • ⑤リスクアセスメントに関しては、
    • 個情委が「データマッピング・ツールキット」を公開しているが、先に述べたとおり、情報資産台帳的な発想で作られており、「PIAの取組の促進について-PIAの意義と実施手順に沿った留意点-」も、個情法遵守チェックリストと(ISO 31000的な意味での)リスク管理一般の説明を組み合わせたような内容になっており、個人の権利利益の保護という観点からは、十分なものになっていないと思われる。
    • DPIAは、本来、処理業務を個人データ保護適合的に設計する(data protection by design)過程を、文書という側面から表現したものであり、アセスメントシートは、IT・ビジネス部門とコンプライアンス・プライバシー部門の対話を促進し、事後的に説明可能にするものであって初めて意味がある。そのような観点からは、どのような個人データが存在しているかよりも、どのような個人データ処理を行うのか、例えば、誰のどのようなデータを、どのような目的のために、どのような方法で収集・処理し、その際、どのようなセーフガードを採用し、データ対象者とどのように関わり合う(情報提供、同意取得)のかを記述することが重要なはずである。ICO・EDPBのテンプレートは、このような観点から有用なものとなっていると思われる。なお、テンプレートは、ICO・EDPBのものを参考にしつつも、自組織に合ったものを作成すればよいが(基本的にはコンプライアンス・プライバシー部門が作成することになろう。)、一般的には、ICOのもの(抽象的)とEDPBのもの(具体的)の間くらいが使い勝手がよいことが多いのではないか。
    • なお、これとは別に、安全管理措置の設計や委託先管理、インシデント対応の前提として、データマッピングを行うことは行うことは考えられる。もっとも、その場合、情報資産台帳的なデータマッピングシートを作成する(往々にしてその後活用されない。)よりも、データマネジメント/データガバナンスの設計に当たってそれらの観点を組み込むほうが現実的であるように思われる。
  • ⑥委託先管理に関しては、
    • 個情法通則ガイドライン上、委託先の選定、委託契約の締結、取扱状況の把握が必要とされているが、どのレベルでそれを行うのかが問題である。この点については、リスクアセスメント以上に実務が未成熟であるが、GDPRのProcessorに関する規律、(EUの)DORAやICTサードパーティリスク管理に関する委任規則を参考にすると、例えば、委託先の選定・委託契約の締結に関して言えば、①処理されるデータの性質・量に応じた基準を設け、それほど重要ではない委託先については、利用規約やホワイトペーパーで済ませ、重要な委託先については、SOC2 Type IIレポート等を入手して評価を行い、特に重要な委託先については、レポート等では確認できなかった事項について、個別に質問を行う等の対応を定めておき、②不明又は不充足となった場合の代替的コントロールの評価方法を(基準化まではできないにせよ)検討し、③最終的に不明又は不充足な点が残る場合のリスク許容の基準・手続を定めておく、といったことが考えられるのではないか。
    • なお、繰り返しになるが、重要なのは、どのレベルで委託先の選定、委託契約の締結、取扱状況の把握を行うかであり、これらを放棄することはできないし、無理に委託先非該当として統制の外に置くべきではない(クラウド例外に関して言えば、そもそもクラウド例外が適用されるかどうかで安全管理の水準は変わらないので、仮に統制を免れることができるように見えるとすれば、そのような整理自体が不適切である可能性がある。)。逆に言えば、委託先管理基準が硬直的すぎる(例えば委託先は全て個別に交渉可能な前提で書かれている)ゆえにそうなっているのであれば、そのような委託先管理基準自体を見直すべきである。