本日の対談のテーマは、個人データの漏えい等となります。外部ゲストとして、一般社団法人JPCERTコーディネーションセンター(JPCERT/CC)の早期警戒グループマネージャーの佐々木勇人さんをお呼びしています。佐々木さん、どうぞよろしくお願い致します。

よろしくお願いします。

佐々木さんは、私が内閣官房内閣サイバーセキュリティセンター（NISC）で任期付職員として働いていたときに大変お世話になった方であり、弁護士に戻ってからも大変お世話になっております。さて、セキュリティ業界の人にとっては、JPCERT/CC（ジェイピーサート・シーシー）を知らないなんてモグリだろうと思いますが(笑)、この対談を読まれる方の中にはJPCERT/CCを知らない人もいるかもしれないので、JPCERT/CCという組織が何をしているのか、簡単にご紹介いただけないでしょうか。

JPCERT/CCは、不正アクセスやサービス妨害といったセキュリティインシデントについて、予防のための注意喚起などの情報発信、インシデント発生時の初動対応の支援、発生状況の把握、手口の分析、再発防止のための検討や助言等を技術的な立場から行っています。一般社団法人ではありますが、営利を目的とする団体ではなく、特定の政府機関や企業から独立した中立の組織として、攻撃被害低減のための国内外の官民間の調整も日本の窓口として担っています。公的機関との繋がりも多く、法令等で特定業務を行う組織として指定されたり、経済産業省や、蔦さんがいらっしゃったNISCから委託を受けて業務を行うこともあります。本日のテーマとなっている個人データの漏えい等との関係でも、個人情報保護委員会と連携しています。例えば、新しい攻撃手法による個人データの漏えい、滅失、毀損（以下「漏えい等」といいます）被害が多数発生し始めた場合、技術的なサポートや注意喚起等の情報発信による連携をしています。

ありがとうございます。佐々木さん自身のプロフィールについては、これがアップロードされたときに多分対談者のプロフィールが出ると思うので、そこを見てもらうということで。さて、これは豆知識ですが、NISCとの関係で申し上げると、サイバーセキュリティ基本法31条は、サイバーセキュリティ戦略本部の事務を政令で指定する法人に委託できる旨を定めております。これを受けて、サイバーセキュリティ基本法施行令5条（※1）に、指定法人としてJPCERT/CCが出てきます。一般社団法人であり、かつ、アルファベットが出てくるという結構レアな法令の条文だと思うので、ご関心があれば是非見てください。

余談ですが、電気通信事業法164条にIPアドレスが出てきますが、これも条文上はカタカナで「アイ・ピー・アドレス」ですよね。

仰るとおりです。法令の条文ってそうそうアルファベット使いませんよね。

ではそろそろ本題に入ります。ご承知のとおり、2020年の個人情報保護法改正により、一定の条件を満たす個人データの漏えい等及びその「おそれ」が発生した場合には、原則として個人情報保護委員会へ報告する義務と、本人への通知義務が導入され（個人情報保護法26条）、2022年4月1日から施行されました。報告は、個人情報保護委員会ウェブサイトのフォームを用いて行う必要がありますが、弊所でも早速様々なご相談を受けています。報告の対象となる事態の中で一例を挙げると、サイバー攻撃など、「不正の目的をもって」行われたおそれがある個人データの漏えい等については、即座に報告義務の対象となってしまいます（個人情報保護法施行規則7条3号）。その関係で佐々木さんにお伺いしたいのですが、インシデント対応を行う中で、この法改正が実務に影響していると思うところはありますでしょうか。

施行されたばかりということもあると思いますが、まだ周知が足りておらず、改正前と同じ対応をしている事業者が多い印象を持っています。個人情報保護委員会への報告義務は、速報と確報の2段階になっており、速報は、ガイドライン（通則編）によれば、インシデント発生から3～5日以内が目安となっているはずですが、実際の現場でそれが意識されているかというと、必ずしもそうではないように思います。マルウェアEmotet（エモテット）やランサムウェアなど、今までの初動対応のスピード感ではこうした制度上の報告に間に合わないような類型の攻撃も増えています。

おっと待ってください、今、それだけで各々数時間は対談できる単語が2つほど飛び出しましたが、それはちょっと後でお話をさせてください（笑）。さて、私の方でも、個人データ漏えい等に関する相談を受けた際に、速報は3～5日以内が目安ですよ、と申し上げるのですが、企業によって受け止めの温度感が違う印象を持っています。速報を適切に実施しておかないと、確報が間に合わなくなるのでは…ということが懸念されますね。 そういえば、こうした施行直後の過渡期ならではの論点だと思っていますが、例えば、サイバー攻撃が起こったのが2022年3月の改正法施行前であった一方で、サイバー攻撃を実際に認識したのが2022年4月以降の改正法施行後、というケースがあり得ます。この場合、改正法が適用されて報告義務があるのかどうかは明確ではないように思いますが、田中弁護士、どう思われますか。

私もそれはよく聞かれます。条文を見ると、26条は一定の要件を満たす個人データの漏えい等の事態が「生じたときは」、となっているので、客観的な事象の発生を基準にしているように思います。つまり、改正法施行前に発生した事象については改正法の適用対象外ということですね。ただ気になるのは、個人情報保護法施行規則8条1項やガイドライン（通則編）の26条の箇所では、報告対象事態を「知った」後に報告せよとなっていて、事象の発生を認識した時点という主観的な認識を基準にしているようにも見えるんですよね…。

私もそこが気になっています。しかし、私も田中弁護士に同意で、まずは条文から出発すべきだと思うので、客観的な事象の発生時点がベースなんだろうと思います。施行規則やガイドラインの「知った」という記述は、発生した事象に関する報告義務発生の起算点を示すものと考えれば、法令の文言との整合性も取れるのかな、と思います。 ただ気になるのは、サイバー攻撃の場合って、半年前とか1年前に実は攻撃が発生していたというケースもあります。例えば、改正法施行後の2022年6月にサイバー攻撃による個人データ漏えいが発生していて、それを2022年12月に知った場合は、知った時点から3～5日以内に速報、60日以内に確報ということになります。これは違和感ないのですが、改正法施行前の2022年3月にサイバー攻撃が発生していたことを2022年12月に知ったという場合、事象の発生が2022年3月なので改正法が適用されません、というのは何となく違和感が残ります。この点に関連して、2020年改正法の立案も担当していた小川弁護士、いかがでしょうか。

まず26条の「生じたときは」という文言は、電気通信事業法28条の重大な事故の報告などの用例にならったものですが、当初から報告義務が生じるのは、漏えい等の事態を認識した時点と考えられており、この点を明確にするために、個人情報保護法施行規則8条1項では、「前条各号に定める事態を知った後、速やかに、」と規定されました。 改正法施行前に発生し、改正法施行後に漏えい等事案については、確かに条文上明確でなく解釈問題となりますが、客観的な発生時点をベースに、認識の時点で義務が生じる時点を限定していると考えれば、改正法施行前に発生したものは対象外ということになるかと思います。ただ、実際の漏えい等事案では、客観的な発生時点も必ずしも明らかではなく、事実認定の問題も生じるかなと思います。

サイバー攻撃の場合は、不正アクセスが1回あってそれで終わり、というわけじゃなくて、いつでも侵入できる状態が継続しているようにも思うので、そうすると、2022年4月以降も不正の目的を持った個人データの漏えいのおそれが継続していた、つまり、改正法は適用されると考えることもできそうですね。

仰るとおりだと思います。そのあたりは、個人データ漏えいの蓋然性をまさに個別具体のケースに応じて判断するということになるんでしょうね。実務上の対処としては、改正法が適用されるかどうかは断定できないが報告した方が良い、と申し上げることになりそうです。

先ほども少し触れましたが、個人情報保護法26条の報告対象事態は、一定の条件を満たす個人データの漏えい等の「おそれ」がある場合も対象になっています。おそれとは、漏えい等が疑われるものの確証がない場合といわれていますが、サイバー攻撃事案における「おそれ」については、ガイドライン（通則編）にいくつか具体的な事例が挙げられています。この事例の一つがJPCERT/CCさんとの関係でも興味深いと思っておりまして、「不正検知を行う公的機関、セキュリティ・サービス・プロバイダ、専門家等の第三者から、漏えいのおそれについて、一定の根拠に基づく連絡を受けた場合」というものがあります。第三者による連絡をトリガーにするということで特殊な事例だと思います。 佐々木さんにお伺いしますが、ここにいう「第三者」には、ストレートにJPCERT/CCさんが入ると思います。実際にJPCERT/CCから企業に対してこのような連絡をするケースは多いのでしょうか。

はい、相当数あります。国内外の専門機関等との連携や調査により、明らかに非公知であるはずの情報が外部に漏えいしてしまっていることをJPCERT/CCにおいて認知する場合があり、そうした場合は漏えい元と思われる企業に対して個別に連絡しています。漏えいしている情報は、具体的には、顧客情報のほか、企業のユーザーのアカウント情報や、社員が利用していると思われるSSL-VPN等のアカウント情報などが多いです。こうしたアカウント情報が漏えいしていると、なりすましによる不正ログインの危険が高まります。実際に、アカウント情報を使った不正アクセスが国内外で発生している旨も注意喚起としてお伝えすることもあります。

JPCERT/CCから連絡をする際には、企業側も適切に情報提供を受けられるようにしておくことが必要だと思うのですが、JPCERT/CCとしては通常どういったルートで連絡をされるのでしょうか。

JPCERT/CCから連絡する場合、個別に担当者等の連絡先を知っているなら直接伝えるのですが、そうではない場合は、企業のドメイン情報を見ます。WHOISサービスで個別のドメインに登録されている「技術連絡担当者」や「登録担当者」欄に記載された連絡先宛てに連絡することが通例です。念のため補足ですが、WHOISとは、ドメイン名の登録情報を検索できるようにするためのインターネット上の取り決め、またはその検索サービスで、「.jp」ドメインであれば、JPRSが登録情報の検索サービスを提供しています。JPCERT/CCは、WHOISの情報を見て連絡を試みるのですが、この登録情報がしばらくの間更新されておらず、連絡したくてもできないというケースが残念ながらそれなりに発生していますので、皆様には是非、WHOIS登録情報を適切にメンテナンスしていただければと思います。

WHOIS情報はユーザーが普段見るところではないので、メンテナンスが後回しになりがちなのかもしれませんが、適切な情報提供を受けるためには普段から適切にメンテナンスしておく必要がありますね。これに関連してですが、ガイドラインの事例は、「漏えいのおそれについて、一定の根拠に基づく連絡を受けた場合」とされており、パブリックコメントに関する個人情報保護委員会の見解を見るに、脆弱性があることの連絡をするだけでは「漏えいのおそれ」についての連絡ではないと解されています（※2）。ここは誤解がないようにしたいと思っておりまして、脆弱性があるということは、確かにそれだけで直ちに個人データ漏えい等の蓋然性が高いまでは言えないかもしれませんが、脆弱性を放置すれば結局のところ不正アクセスやデータの漏えいに繋がりますので、脆弱性に関する連絡を受けた段階では、個人情報保護委員会への報告が法的な義務とはならずとも、対応することは必要だと思っております。佐々木さんにこのあたりについてコメントいただきたいのですがいかがでしょうか。

仰るとおり、JPCERT/CCからは、漏えい等のおそれだけではなく、脆弱性がある旨の連絡をすることもあります。例えば、外から古いバージョンのソフトウェアを使っていることが見えた場合などですね。確かに、この場合であれば、直ちに不正アクセスなどの攻撃が起きていない場合もあります。しかし、脆弱性に関しては、JPCERT/CCを含む様々なセキュリティ機関等から注意喚起が発出されることが通例ですが、その注意喚起に、既にこの脆弱性を用いた攻撃が観測されている、という情報がセットで出ている場合は要注意です。JPCERT/CCなどから脆弱性がある旨の個別連絡を行ったときに、その脆弱性を突いた攻撃が既に観測されているという情報も入っている場合は、もはやその脆弱性を使って不正アクセス等されている可能性が十分にあることを前提に対応いただきたいと思います。 もちろん、特定の脆弱性を用いた攻撃が観測されており、御社が攻撃されている可能性が高い又は御社の情報と思われるものの漏えいを確認しているとJPCERT/CCから連絡を受けた場合は、漏えい等の「おそれ」があることはもちろん、漏えいがほぼ確定していることを前提に直ちに調査を始めていただきたいと思います。

①単に脆弱性がある、②その脆弱性を使った攻撃が既に観測されている、③その脆弱性を使って御社が攻撃を受けている、というように、脆弱性がある旨の連絡にも色々あるということですね。今は個人情報保護法との関係だけを見ておりますが、例えば、脆弱性があることの連絡を受けたのにそれを放置して、それが原因で自分が攻撃者の踏み台にされてしまい、第三者への不正アクセスが発生し損害が生じたというケースを想定すると、「脆弱性があることの連絡を受けたのに放置した」という事実が過失となって、第三者から損害賠償請求を受けるリスクもあると思います。個人情報保護法だけではなく、様々な法的関係を検討する必要もあると思っています。

そうですね、個人データの漏えい等のインシデントにおいて、個人情報保護法は、問題になる法律の一つでしかないということですね。個人データの漏えい等が発生した場合には、当局の他にも、取引先、委託先、委託元、ユーザーといった色んな関係者がいますから、その関係者との関係で論点となり得る賠償リスク等を常に意識する必要があります。

私が配信させていただいたセミナー動画でも触れましたが、改正による実質的規制強化の点、これは是非議論させてください。この記事がアップロードされた際に画像が貼り付けられているはず。

改正前は、告示に基づく努力義務として、個人情報保護委員会への報告等が定められていました。その告示では、漏えいしたデータだけを見ても特定の個人を識別できない場合には、「実質的に個人データが外部に漏えいしていない」ということで、個人情報保護委員会への報告は不要とされていました。今回の改正で、パラダイムシフトと言ってもいいぐらい大幅な方向転換をしておりまして、「個人データに該当するかどうかは、当該個人データを漏えい等した個人情報取扱事業者を基準に判断する」となっています。要は、漏えいしたデータだけを見て特定個人を識別できなくても、漏えいした企業が他の情報と紐付けて特定個人を識別できるなら個人データの漏えいとして扱わないといけないということがQ&Aで明記されています。スライドにもあるとおり、強調するために敢えて「漏えい元基準」とラベリングして呼んでいます。小川弁護士、なぜこのような転換が行われたのでしょうか。

個人データの第三者提供を行う際に、提供元と提供先のどちらを基準に個人データ該当性を考えるか、という論点があって、こちらは提供元を基準に考えるというのが、個人情報保護委員会の立場です。いわゆる提供元基準ですね。つまり、提供先にとって個人データでなくても、提供元にとって個人データであれば、それは個人データの提供として扱わないといけないことになります。この考え方自体にも議論がありますが、提供と漏えいの区別が微妙な事例もありますし、提供元基準を一貫させる立場から、今回の改正にあたって提供元基準の考え方を個人データの漏えいについても当てはめた、ということかと思います。

漏えい先がどんな情報をもっているかは正直分からないということが考慮されたのかな、と思います。漏えい先基準で考えると、おそらく漏えい先では特定の個人は識別できないだろうということの予測に基づいた基準になってしまうため、そうならないように、自分を基準に考える漏えい元基準説を採用しているということなのかなと思います。

一貫させたいというところはわからなくはないのですが、実際のところ、これは本当に厳しい改正をいきなりぶち込んだな、という印象を持っております。極端な例を挙げますが、例えば、氏名、メールアドレス、社員ID（社内で整理用としてのみ利用）をデータベースで管理しているときに、社員IDだけが漏えいした場合、社外の人が社員IDだけを見ても誰のことなのかさっぱりわかりませんが、漏えいした企業としては、データベースを見れば社員IDから特定個人を識別できますので、社員IDは個人データの一部ということになります。そして、漏えいした社員IDが1000件を超えてたらその時点で報告義務の対象となります。

漏えいしたデータのみでは特定個人を識別できるかどうか微妙なケースもあるので、そういう場合に幅広に報告して欲しい、ということなのかもしれませんね。さすがに、社員IDだけ漏れましたという場合は、プライバシー性も低いので、報告を受けた個人情報保護委員会も特段リアクションはしないように思います。

幅広に報告するのは構わないのですが、社員IDだけ漏えいしたケースみたいに、報告する方もされる方も手間が増えるだけ、というのは何とかならないかな、と思います。

立法論になるかもしれませんが、誰を基準にするかで画一的に決めるのではなく、本人の権利利益侵害のおそれの度合いという観点からケースバイケースで実質的に判断できる余地を残してもよいと思います。旧告示は、漏えい元基準説を採用していなかったものの、当該事業者以外では特定の個人を識別できない場合であっても、例外として、当該情報のみで「本人に被害が生じるおそれのある情報が漏えい等した場合」には、やはり漏えい等に該当するとしていました。このことも、結局は事案ごとの実質的な判断が必要であることを示唆しているように見受けられます。 確かに、今回の改正法で漏えい等報告を義務化したことに伴い、画一的な判断基準を設けるべきという意識が背景にあることは理解できますが、例えばGDPRにおいても、自然人の権利及び自由に対するリスクを発生させるおそれがない場合は（“unlikely to result in a risk to the rights and freedoms of natural persons”）監督機関への報告は不要とされていますよね。高度な暗号化（個人情報保護法施行規則7条1号括弧書に相当）といったケースも、GDPRでは、この抽象的な要件該当性の中で判断されることになります。 今回の改正法では、個人データに該当しても仮名加工情報であれば漏えい等報告が免除されることが明記されています（個人情報保護法41条9項）。これと平仄を合わせる意味でも、本人の権利利益侵害のおそれの度合いという観点から合理的な結論を導き出せるような解釈ないし立法上の手当てはあっても良いのではないかと思います。

強く同意します。今の点に関して、仮名加工情報は確かに報告義務が除外されていますが、この制度って、「私はこれを仮名加工情報にします！」という意思をもって加工しないと使えないのがネックですよね。仮名加工情報の加工基準は比較的緩いので、安全管理のために一部の情報を削っていれば、結果的に仮名加工情報の加工基準を満たしているケースが多いです。それと同じように、漏えいしたデータだけを見ると、オリジナルのデータと比較したときに仮名加工情報の加工基準を結果的に満たしているケースが結構あると思うんですよね。データの内容、つまり、本人の権利利益の侵害の程度としては仮名加工情報と同じなのに、仮名加工情報にする意思をもって加工したかどうかだけで義務の有無が変わるというのは違和感があります。ここからちょっと悪いことも考えることができそうで、北山弁護士に確認しておきたいのですが、漏えいしたデータがたまたま仮名加工情報の基準を満たしていたというケースで、「実はこれ仮名加工情報だったんです！」と後から仮名加工情報だったことにするのはどうでしょうか。「事後的仮名加工情報」といいますか。まぁダメだと思いますけど。

変なスキームを作らないでください（笑）、そりゃダメでしょう。今仰っていただいたのは、仮名加工情報を「作成するとき」に、仮名加工情報として取り扱おうとしていなければならないという解釈の箇所だと思いますが、これはあくまで作成するその時点で意思が必要ということですので、後から実は意思があったというのは通用しないと思います。

すいません、言ってみただけです。頭の体操と思っていただければ。さて、先ほど岡田弁護士から立法論かもしれないが、という示唆がありましたが、私としても、本人の権利利益の侵害がほとんどないと言えるような軽微な事故については、そもそも報告することを不要とするか、そうでなくとも、例えば、電気通信事業法で定められている事故発生時の四半期報告制度（電気通信事業報告規則7条の3参照）のように、軽微な事故に関する特則があれば良いな、と思っております。データ漏えいが起こった現場で、皆がこの漏えい元基準を完全に把握して対応しているとは思えないのですが、佐々木さんの所感としてはいかがですか。

インシデント対応支援をしている被害組織においても、漏えいした情報の個人情報保護法やGDPR上の「解釈」で混乱しているケースが確かにあります。改正法自体の周知はもちろん、実務上影響が大きい法解釈についても周知も必要ですね。 それに関連しますが、多いのはアカウント情報の窃取です。昔から、オンラインサービスのユーザーのアカウント情報が窃取される被害は多く発生していましたが、こうした顧客情報の漏えいだけでなく、社員に関する情報の漏えいも多くなっています。例えば、社員がリモートアクセス時に使うSSL-VPNアカウントや、ブラウザからログインするウェブメールやクラウドストレージサービスのアカウントに関するID・パスワード等ですね。従来は社内サーバーとして稼働していたものが、クラウドサービスにログインするという方向に移行しつつあるのですが、それによって、アカウント情報さえあれば、攻撃者もアクセスできる「攻撃対象」になってしまいました。攻撃者はフィッシング等によって、IDとパスワードのセット情報をより多く入手し、または別の攻撃者に転売するようになりました。

田中弁護士、ID・パスワード等の個人データ該当性についてはいかがでしょうか。基本的に当たるということになりそうですが。

そうですね。まず、ID自体が単体でも個人データにあたる電子メールアドレスだったりすると、IDだけが漏れた場合でも、それ自体で当然に単体で個人データの漏えいですね。そして、仮に、ID自体が英数字の羅列のようなものであって、IDだけが漏れた場合だとしても、漏えい元ではそのIDを個人データとして管理しているはずなので、結局、個人データの漏えいになりますね。さらに、IDとパスワードのセットが漏れてしまえば、なりすましによる不正ログインの危険が高まりますので、不正ログインした場合に閲覧できる情報についても、漏えいの「おそれ」があるケースも多くなりそうです。

関連して触れておきたいのは、いわゆるリスト型攻撃ですね。簡単に解説すると、リスト型攻撃とは、さっき佐々木さんからお話のあったフィッシングなどによって窃取したID・パスワードのリストを使って、他のサービスへの不正ログインを試みるものです。IDやパスワードについては、色んなサービスで同じものを使い回している人が多いので、使い回しが多ければ多いほど、リスト型攻撃による被害を受ける可能性が高くなってしまうという関係にあります。大きなサービスだと、1日あたり数アカウントの情報が、このリスト型攻撃によって漏えいしているとも聞いたことがあります。リスト型攻撃は、第三者による明確な悪意をもった不正ログインですので、「不正の目的」であることは明白です。つまり、1件でも個人データが漏えいすれば、報告対象事態となります。ID・パスワードについては、先ほどの田中弁護士の話にもありましたが、事業者が他の特定個人を識別できる情報とともに管理しているでしょうから、ID・パスワードが漏えいした時点で、漏えい元基準に基づけば個人データの漏えいになります。

リスト型攻撃による不正ログインが成功しただけだと、そのサービスを提供している事業者からIDとパスワードが攻撃者に流出したわけではないと解釈する余地もあるように思います。

私としては、不正ログインが成功した時点で、そのサービスを提供している事業者のユーザーの認証情報を攻撃者が取得してしまっているので、漏えいに該当するのではないかな、と思っています。もちろん異なる見解もあろうかと思いますが。ただし、この時点では漏えいに該当しないと考えたとしても、ID・パスでログインできるサービスは、ログインした後にユーザー情報を閲覧できることも多いので、結局のところ、不正ログインが成功した時点で、閲覧できる可能性がある情報の漏えいの「おそれ」は発生してしまっているように思います。今の議論が問題となりうるのは、不正ログインをシステムで検知する等して即座にブロックしたようなケースですね。この場合は、攻撃者による不正ログイン自体は成功してしまっていますが、ログイン後に閲覧できる情報等の漏えい又は漏えいのおそれはないと評価することも可能と思われます。

そうすると、ログインした後に閲覧できる情報が非常に限られている場合は、個人データの漏えいのおそれがないという場合もありえそうですね。

ただ、結局ここでまた漏えい元基準が絶妙な効果を発揮しちゃうんですよね。大抵のウェブサービスって、ログインした後に、ユーザーネームとかユーザーIDが表示されることがほとんどだと思うんですが、これも漏えい元基準に基づけば個人データになりますので、ログイン後にユーザーネームやユーザーIDを閲覧できてしまうと、結局その時点で法的には個人データの漏えいになりますよね。

形式的にはそうなりますよね。多要素認証を入れるなどして、IDとパスワードだけでログインさせない、という対策をとるしかないのかもしれません。

一応解説すると、多要素認証とは、ID・パスワードという、知識による認証以外に、保有しているものや身体的特徴といった他の要素による認証を付加するものですね。2つの要素を用いる場合には二要素認証ということもあります。具体的には、保有しているスマートフォンを用いた端末認証や、指紋や顔の特徴による認証が挙げられます。ID・パスワードの後に、「秘密の質問」といった知識による認証を追加する場合もありますが、これはどちらも知識という同じ要素を用いて二段階の認証を行うものですので、二段階認証ということになります。 話を戻すと、多要素認証を入れるというのはリスト型攻撃を防止するために有効な手段と言えますが、これを導入することで、ユーザーの利便性が落ちる（ログインが面倒になる）というマイナス効果もあるように思うので、現時点では、まだ全ての事業者が導入できているものではないという印象を持っています。佐々木さん、リスト型攻撃への対策は現状どのような感じでしょうか。

直接的な原因は、やはりユーザーがID・パスワードを使い回してしまうということですので、JPCERT/CCとしても、ユーザー側に対してパスワードの使い回しをやめましょうという注意喚起を行ってきました。「STOP! パスワード使い回し！」という特設ページも作っています。ただ、どうしても呼びかけるだけでは限界があるように思っています。抜本的な対策の一つが多要素認証の導入ですね。仰っていただいたとおり、少し前は、導入を嫌がる傾向にありましたが、最近では、大手サービスが導入し始めていることもあり、ユーザー側も徐々に抵抗感が薄れてきているイメージがあります。リスト型攻撃は防ぐことが難しい類型の一つですので、導入を積極的に検討して欲しいと思っています。後これはJPCERT/CCとしてではなく個人的な見解ですが、パスワードの使い回しって、たくさんのパスワードを覚えていられないから使い回す、という背景があると思うので、パスワードの再発行手続が安全かつ速やかに行われるのであれば、「無理して短いパスワードを覚えたり、使いまわす」よりも「忘れてもいいから長いパスワードを使う」という考えに切り替えてもいいんじゃないかと思っています。例えば、1回くらいしか使わないサービスと普段から頻繁に使っていて金銭にも紐づくようなサービスとで同じID・パスワードを使っていて、1回くらいしか使わないサービスから漏えいした認証情報で後者のサービスに不正ログインされることが想定されます。それなら、1回くらいしか使わないサービスの方は、50文字ぐらいのめっちゃ長いパスワードにしてしまって、2回目以降のログインはパスワードの再発行手続をしてしまうという、ということもなくはないと思います。

なんと！その発想は全くなかったです。まさに、「逆に考えるんだ、『忘れちゃってもいいさ』と考えるんだ」ってやつですね。某奇妙な冒険のファンが喜びそうです（笑）。確かにパスワードの再発行手続は、結果的に多要素認証又は多段階認証になってるものが多いですもんね。ただ、再発行手続が適切であるという前提には注意しないといけないですね。まぁ、再発行手続が適切でないということは、それ自体がシステムの脆弱性であるようにも思いますが。

さて、後で触れましょう、と先ほど申し上げたテーマにそろそろ言及しましょう。この対談の時間も限られていますので、詳細は別の機会があれば、ということにもなりそうですが、まずはランサムウェアから。皆様ご承知のとおり、近年のランサムウェアの脅威は極めて大きく、様々な企業が被害に遭っており、弊所も多数の相談を受けております。情報処理推進機構（IPA）が公開している「情報セキュリティ10大脅威2022」でも組織向けの脅威第1位ですね。近年のランサムウェア攻撃の特徴としては、単にデータを暗号化するだけではなく、情報を窃取してリークサイトに公開してしまうという点が挙げられるかと思います。ランサムウェアに関する論点は、身代金の支払いの関係を含め沢山あり、これだけで対談のテーマにできてしまいますが、時間の制約もあるので今回はあくまで個人情報保護法との関係に絞りたいと思います。嶋村弁護士、おさらいですが、こうした暴露型のランサムウェアに感染した場合、個人データの漏えい等の関係でどうなるか教えていただけますか。

暗号化した時点で個人データの「毀損」になり、情報が窃取されていれば「漏えい」に該当することになりますね。バックアップがあり復元できるような場合は「毀損」には該当しないとされています。ただ、個人情報保護法施行規則7条は、漏えい・滅失・毀損について特段扱いを分けていないので、課せられる義務は変わりません。

ありがとうございます。そのとおりですね。これは佐々木さんにお伺いしたいのですが、ランサムウェア対応と個人データ漏えい対応について、何か特徴的なことはありますでしょうか。

ランサムウェアは、初動対応が今までと大幅に異なる類型の一つだと思っています。早いものだと、侵入して数時間から数日の間に、情報の窃取・データの暗号化・リークサイトでの暴露までされてしまいます。企業がランサムウェア攻撃を認知したタイミングとほぼ同タイミングでリークサイト掲載を通じて漏えいが発覚したというケースも多く、個人データの漏えいがあったという前提で報告対応をする必要があると思います。

ここは私も悩ましいと思っておりまして、ランサムウェアに感染したということだけがわかっている場合、それが情報窃取を伴うものなのかどうか、情報窃取を伴うものであるとして、実際に窃取されたのかどうか、というところを判断することが難しい点が悩ましいですね。これは、ランサムウェア攻撃を受けた場合に、報告義務が発生する「知ったとき」がいつなのか、という論点とも絡んできますね。

ランサムウェアの種別によっては、仮に暗号化被害を認知した時点ではまだリークサイトに漏えい情報の掲載がなされていなかったとしても、今までの犯行履歴からして、確実に情報を窃取していて、数日以内にリークサイトで暴露されてしまう可能性が高いというものもありますので、その類型のランサムウェア被害の場合は漏えい前提で対応した方が良いように思います。

通常は、ランサムウェアの種別までは企業自身は把握できないと思うので、セキュリティベンダに尋ねることになりますでしょうか。

仰るとおり、そこは専門知見を持つ組織に聞いていただく必要があります。ただ、ランサムウェア感染の対応をベンダに依頼する場合、即応対応をしてもらえるかどうかはベンダによって異なると思っています。インシデント対応を専業でやっているセキュリティベンダなら動きが速いのですが、そうでないベンダだと、スピード感が間に合わないケースもあるように思っています。ランサムウェア感染が発覚してから数日後にベンダに相談というのは遅いですし、ベンダに調査依頼をかけて契約して、それから結果を見てから考える、という悠長なこともできません。ランサムウェア対応においては、復旧対応に軸足が置かれ、当局への対応は後回しにされがちですが、改正個人情報保護法の下だと、そうした復旧対応の中でも、3～5日以内に速報を出すかどうかを判断しなければならないので、それを踏まえた対応が必要となるはずなのですが、冒頭に申し上げたとおり、現時点では、事業者自身がそこまで意識できていないように思っています。

ランサムウェアがどのような挙動をするかは、確かに企業自身では判断できないと思いますので、ベンダに聞いていただくか、まさにJPCERT/CCにインシデント対応依頼をして尋ねるのも選択肢ですね。佐々木さんが触れなかったので私の方で触れておきますが、JPCERT/CCは、近年のランサムウェアの脅威の増加も踏まえて、「侵入型ランサムウェア攻撃を受けたら読むFAQ」という特設ページを公開しています。ランサムウェアを受けた場合の対応について簡潔かつ網羅的にまとまっているので、感染したらまずここを読みましょう。私もクライアントによくこのページを案内しています。

最近また猛威を振るっているEmotetにも触れましょう。Emotetは、企業が保有する連絡先情報やメール情報などを窃取することがありますから、その時点で個人データの漏えいがあったといえるケースが多いですし、例えば、自社がEmotetに感染したことを原因として、第三者をEmotetに感染させてしまった、という二次被害が発生するケースもあります。その際には賠償問題となるリスクもあると思います。佐々木さん、JPCERT/CCでも、Emotetに関する相談は多いでしょうか。すいません、結論はわかった上で敢えて聞いてますが。

感染の流行期といいますか、攻撃全体の波ごとに感染被害の「ピーク」があるんですが、そういった時期になると、普段対応しているチームだけでは対応がまわらなくなるので、別のチームを投入するぐらいに相談が多いですね。Emotet対応も、従来とは異なるスピード感でのインシデント対応が必要となる類型の一つと思っています。Emotetは、感染から1日以内に不審メールが取引先等にバンバン飛んでいきますので、短時間での対応が必要です。メールサーバーが乗っ取られて不審なメールが送られる可能性もあります。ベンダに依頼して対応して、というような従来の対応では間に合わないので、被害組織自身が、一定程度の初動対応を実施する必要があります。そうした特徴を踏まえ、JPCERT/CCでは、「マルウェアEmotetの感染再拡大に関する注意喚起」という特設ページを作り、担当者が対応に関するノウハウを紹介する動画をYoutubeで公開しています。Emotetに関する動画の再生回数は段違いで、それだけ被害者が非常にたくさんいるということだと思っています。

ありがとうございます。弊所でも多く相談を受けているところですが、やはり感染してしまっている事業者の数はかなり多いという実感があります。さて、こちらも、感染拡大に伴う民事責任等を検討すると、それだけで数時間は対談できそうですので、感染した企業の個人情報保護法上の対応に絞ってお話をさせていただきます。Emotetに感染すると、感染した端末に保存されていたメールデータやアドレス帳に登録されていた情報等が窃取されると言われています。これらは前提として、報告義務が生じる「個人データ」の漏えいにあたるでしょうか。北山弁護士、いかがでしょう。

今の質問の趣旨は、「個人情報」か「個人データ」か、という質問であると理解しました。報告義務の対象は「個人データ」なので、個人データではない「個人情報」の漏えいがあったとしても法的には報告義務はないということですね。今挙げてもらったものは、「個人情報」であることは前提としてよいと思います。特定の個人情報を容易に検索できるように体系的に構成されているかどうかで、個人データに該当するかどうかが変わりますが、その点で申し上げると、まず、アドレス帳は体系的に構成されたデータですので、それを事業に使っているなら個人データに当たることは疑いないと思います。メールデータについてはちょっと微妙ですね。ただ、メールソフトの機能として、特定の送信元や送信先を基準に並べ替えたり、メールデータの検索ができたりしますので、個人データであることを前提に対応した方が良いのではないでしょうか。

ありがとうございます。確かにギリギリ詰めるとメールデータは「個人データ」ではないと解する余地はあると思いますが、基本的には、様々なデータが漏えいしており、その一部には少なくとも個人データが含まれているという前提で対応した方がよいかと思います。他にもEmotetは、感染した被害組織によるメール送信先（Emotet未感染）になりすますこともあるというのが怖いところだな、と思っています。つまり、第三者から、「あなたになりすましたメールがこちらに届いた」という連絡を受けたとしても、実はその連絡を受けた組織はEmotetに感染してないという場合があり得るので、感染しているかしていないかがわかりづらい、ひいては、個人データの漏えい等があるかどうかがわからないのではと思います。

蔦先生のおっしゃる通り、Emotetの感染流行に対して社会全体での対応を難しくさせている背景として、「関係者のうちだれが感染したのかわかりにくい」戦術を攻撃者が取っていることが挙げられます。JPCERT/CCは、Emotet感染の有無を確認するための「Emocheck」というツールを公開していますので、こちらで確認いただくのがよいかと思います。ただし、Emotetは、逐次バージョンアップ版が投入されており、様々なセキュリティ対策を突破するためのバージョンアップ等が行われています。JPCERT/CCが公開したEmocheckも回避するためのバージョンアップ版がこれまでも登場しています。Emocheck側も、回避されないようにするため等のバージョンアップを何度か行っていますが、こちらがバージョンアップすると向こうもそれを回避するためのバージョンアップを行うなど、いたちごっこになっています。JPCERT/CCは、最新のEmotetを検知するためのバージョンをどんどん追加で投入していますので、Emocheckをご使用いただく際には、是非最新版を確認いただければと思います。

では、そろそろお時間となりますので、今回の対談はこのあたりで終了とさせていただきたいと思います。サイバーセキュリティ対策の重要性が高まる中、個人データ漏えい等対応と密接に関わってくることは明白であると思いますし、私も本日議論させていただいて非常に勉強になりました。佐々木さん、本日は誠にありがとうございました。どうぞ引き続きよろしくお願い致します。

ありがとうございました。

今回は越境移転規制に係る実務上の対応について議論させていただきます。令和２年改正により外国にある第三者に対して個人データを提供する場合（以下「越境移転」という）には、本人への情報提供が義務付けられました。これにどう対応するかが難しいわけですが、前提として、越境移転のための法的根拠（個人情報保護法（以下「法」という）28条）と一般的な第三者提供のための法的根拠（法27条）の組み合わせを整理しておきたいと思います。ご参考までに、弊事務所弁護士によるNBLの連載記事（※1）から表を抜粋します 。この表に記載のとおり、法令に基づく場合等の例外を除いて、実務上、主に、５通りの組み合わせが検討されるかと思います。各組み合わせの留意点や越境移転規制の詳細は、NBLの連載記事（※2）をご覧いただけたらと思いますが、令和２年改正で導入された情報提供義務の観点で指摘しておくべきことはありますでしょうか。

令和２年改正法の情報提供義務は、個人データの越境移転が増加する中で、それに伴うリスクについての本人の予測可能性を向上させるということを意図したものですが、情報提供のあり方は移転の根拠によって異なります。すなわち、本人の同意を越境移転の根拠とする場合は、「事前に」本人への情報提供が必要となる一方で、いわゆる相当措置を継続的に講ずるために必要な体制として規則で定める基準に適合する体制の整備（以下「基準適合体制の整備」という）を根拠とする場合には、「本人の求めがある場合」に情報提供が必要となります。このように選択した越境移転の法的根拠によって本人に情報提供するタイミングと本人に提供すべき情報の内容等が異なるため、事前に越境移転の法的根拠を確定しておくことが特に重要となります。

ありがとうございます。法改正前はいずれを根拠として越境移転をしているのか不明な不適切な事業者が散見されました。EEA諸国や英国への移転であれば、この表のⅣまたはⅤを選択することで、情報提供義務の問題は回避できますが、それ以外の場合だと、どう情報提供義務に対応すべきか検討が重要ですね。

各組合せにメリット・デメリットがあるとは理解していますが、Ⅲをオプションとして勧めることはあまりないように思います。28条を基準適合体制でクリアするなら、27条も委託・共同利用でクリアする、つまりⅡが多いのでは。Ⅲは実際上どういったケースが想定されますでしょうか。

実務上必ずしも頻繁に採用されるわけではないですが、たとえば、海外に本拠を置く会社が、グローバルなプライバシーポリシーや利用規約をそのまま日本でも用いて、グループ会社間で個人データを共有する場合がありますね。法27条との関係では委託や共同利用も選択肢となり得るものの、委託の実態がない場合や、比較法的には共同利用という制度自体が珍しいので、海外の親会社が日本の子会社との関係でのみそれに依拠することを望まないことがあります。その場合、従業員やサービスの利用者であれば法27条の同意を得ることは容易である一方、グローバルなプライバシーポリシー雛形をそのまま利用すると法28条の同意に必要な事前情報提供としては足りない（ものの法28条については既に基準適合体制でクリアできている）ため、結果として、法27条に基づく本人の同意を得ることを選択することを希望する場合があります。

では、越境移転の根拠として本人の同意を選択した場合、各社が実際にどう対応しているか議論していきましょう。まず、ガイドラインでは、本人から同意を得る際の本人に対する情報提供の方法としては、電子メール、書面の直接交付、口頭説明、ホームページに掲載し本人に閲覧させる方法が挙げられているのですが、実際にはどのような方法を採用することが多いでしょうか。

プライバシーポリシーに情報提供項目を記載する例も増えるかと思ったのですが、実際には記載していない例も多く見られます。

全ての事業者が越境移転についてプライバシーポリシーに詳細な記載をしているわけではなく、たとえば、「当社は法令で定める場合を除き、本人の同意を得ることなく個人データを第三者に提供しません」とだけ記載している例もありますね。

そもそも越境移転をしていない事業者がそのような簡潔な記載とすることはあるのですが、越境移転している事業者であっても、公表している当該事業者全体の個人情報の取扱いについて定めたプライバシーポリシー上では特段の追記をしない例もあります。特定のサービスやアプリにおいてのみ越境移転が生じる場合は、その利用規約や個別のプライバシーポリシーを作成している場合もあります。

ありがとうございます。ガイドライン上は口頭説明も１つの情報提供の方法として挙げられていますが、実務上は、本人に確実に認識いただく観点から、文書の形で示す例を採用することが多いですね。その文書がプライバシーポリシーであることがありますが、それにこだわる必要はなく、プライバシーポリシーとは別の説明文書を用意する例もあります。ここは各社の対応方針によるところですが、何らかの文書にするとした場合、どのような点に留意してアドバイスされてますでしょうか。

少なくとも越境移転に関する条項が他の個人情報の取扱いに関する条項等と明確に区別され、本人に理解されるように示す必要があると考えていますが、その観点では、越境移転について独立の項目を設けて必要な事項を分かりやすく説明するようにしています。説明する量がプライバシーポリシー等の文書全体と比較してアンバランスになる場合には、別紙の形を提案することもあります。

なるほど。越境移転に関する条項を他の事項と明確に区別するという点は「金融分野における個人情報保護に関するガイドライン」（以下「金融GL」という）でも指摘されている重要なポイントですね。

次に、本人同意を得る際の具体的な各項目の記載方法について議論させてください。提供すべき項目は、①外国の名称、②適切かつ合理的な方法により得られた当該外国における個人情報保護制度に関する情報、③当該第三者が講ずる個人情報の保護のための措置に関する情報ですが、これを文書に記載するとして、どのような工夫が見られますでしょうか。

実際の例をみると、提供先となる外国が１または２か国であればプライバシーポリシーに記載しても読みにくさはないと思うのですが、より多くの国に提供する場合には、越境移転の情報提供項目の記載が大半を占めることになり、見栄えが悪くなります。そこで、別紙を作成して、本体のポリシー上では、別紙へのリンクを貼る等の対応がみられます。この点、リンク先をいくつもたどらないと情報提供のページにたどり着かないような場合は別ですが、越境移転の情報提供を行うページへのリンクが分かりやすい形で示されているのであれば、リンクによる対応を行うことで、プライバシーポリシー上の記載はスッキリしますね。

たしかに、別紙や別ページへのリンクを設ける例は良くみますね。上記②の外国の個人情報保護制度の記載に関して伺いますが、個人情報保護委員会が40か国分の個人情報保護に関する制度を調査し、その結果を「情報提供文書」として公表したことを受け、どう対応されてますか。

一番多いのは情報提供文書が掲載されているウェブページのURLを貼るパターンでしょう。これは、「個人情報の保護に関する法律についてのガイドライン」に関するQ＆A（以下「QA」という）の12-10でも認められているところです。情報提供文書は表形式でわかりやすくなっており、これを示せば説明したことにはなると思われるので、これを示す導線を用意することが実務的対応になるかと思います。

ウェブベースのビジネスであれば、情報提供文書のURLを掲載する対応をする場合が多いと思うのですが、紙媒体の同意書面を用いる場合には当該 URL の近くにQR コードを掲載すること等により、本人が当該URLの指定する Web ページに掲載された情報を閲覧すると合理的に考えられる形で、情報提供を行う必要があると考えられます。このことは、「金融機関における個人情報保護に関するQ&A」（金融QA）に言及があります。

QRコードですか。確かに紙にURL書いてるものを掲示されたりFAXで送られても、URLを一文字ずつポチポチ打ってアクセスしようという奇特な人はなかなかいませんよね。ただ、実際にそこまで意識して対応している事業者は多くないという認識です。

その点は今後の改善を検討すべき点として認識しておきましょう。ところで、外国の個人情報法制度は、事業者の責任で、「適切かつ合理的な方法」により確認することが必要であり、個人情報保護委員会も情報提供文書において、同資料はあくまで「補助的なもの」として参照するものと説明されています。また、金融QAでは、「適切かつ合理的な方法」による確認は、個人情報取扱事業者の責任において行うべきものであり、個人情報保護委員会が提供する情報は、あくまで補助的なものとして参照する必要があるとしたうえで、当該事業者が当該外国における個人情報保護制度に関する情報について一般的な注意力をもって適切かつ合理的な方法により確認を尽くした結果、当該事業者として本人に提供すべき情報が、個人情報保護委員会が補助的なものとして提供する情報と同じである場合は、個人情報保護委員会が提供している情報を「適切かつ合理的な方法」として本人に提供することが考えられるとしています。これは、40か国についても独自に調査する義務があるということでしょうか。

そこの解釈が悩ましいところですが、ガイドラインでも「適切かつ合理的な方法」の例としては、「我が国又は外国の行政機関等が公表している情報を確認する方法」が挙げられています。性質上、個人情報保護委員会の調査結果は、全ての事業者が関係する細かな業法等を網羅的に完全に説明することは難しいとは思いますので、この文書で挙げられていない制度が実際には存在する可能性があります。記載されていない制度が本人の保護を厚くする方向の制度であれば、ある意味それが漏れていても、より保護が手厚いのだから実害はないのかもしれません。しかし、実は、日本の個人情報保護法と抵触するようなガバメントアクセスの定め等が細かな業法にあったりした場合は、問題になるでしょう。各企業が、実は、そういうものがある（らしい）ことを認識しつつ、個人情報保護委員会の文書には明記されていないので敢えてスルーしてしまうような場合は問題だと思いますが、そうではなく、結果的に、なかなか調べにくいようなものがあったことが後から判明してしまったような場合に、個人情報保護委員会が外部法律事務所も起用して調べても調べ尽くせなかったものについて、個別の企業に責任を問うのは酷ではないかとは思われ、そのような状況で、果たして現実に執行をしていくのかというところはあるかとは思います。

概ね情報提供文書に依拠することで問題はないといったところでしょうか。情報提供文書が公表の直後に、一部誤りもあって、個人情報保護委員会に指摘してみたところ、すぐに微修正が入りましたね。闇雲に内容を信用してはいけないということなのかもしれません。

各国の個人情報保護制度の動きは激しく、たとえば、個人情報保護委員会が調査を実施した時点以降、外国において個人情報の保護に関する制度が改正されること等により、外国にある第三者に対して個人データを提供する事業者が本人に対して提供すべき情報の内容にも変更が生じている可能性はあります。その意味で、厳密には調査時点日以降の改正の有無の調査も必要ではないかという論点はありますが、現実に40か国について事業者が一から独自の調査を実施している例はないように思います。条文解釈としては、「適切かつ合理的な方法」による外国の個人情報保護制度の調査として、どこまで求められているのか、ということになるかと思います。

いずれにしても、各国で個人情報に関する法制度の制定・改正が相次いでいることから、情報提供文書があるから安心とはならなそうです。では、40か国以外についてはどのような調査をしていますでしょうか。だいたい費用の目安も気になるところです。

情報提供文書やその元となった法律事務所による報告書を英訳して、現地の法律事務所に趣旨を伝えて英語で表を作成してもらい、こちらで和訳するという作業があり得るかと思います。費用の目安は依頼する現地の法律事務所にもよりますが、新規に調査する国であれば1ヶ国あたり数十万円程度といったところでしょうか。

最近では40か国以外の国の調査結果を公表している法律事務所もあります。また、既に独自に調査をした事業者はその結果を自社ホームページで公表しています。そのような、個人情報保護委員会が作成した情報提供文書ではない資料を流用しようとするとする事業者も現れそうですが、こうした事例についてはどう考えますか。

我々としては、どのような調査経過を経ているのか不明なものについてはリスクがとれないとして独自の調査を勧めることもありますが、最近は、そのようなリスクをとって流用する例もあるようです。調査費用も安くないですし、スタートアップ企業等ではやむを得ない経営判断なのかもしれません。

私が見た限りでは、公表している調査結果の内容が、各社で異なってしまっている例も散見されます。個人情報保護委員会が40か国といわず、EEAを除く全世界を対象に追加調査をすることが望まれますね。

全事業者の要望かもしれませんね。次に、「当該第三者が講ずる個人情報の保護のための措置に関する情報」について議論させてください。提供先が、OECDプライバシーガイドライン8原則に対応する措置を全て講じている場合には、その旨を本人に情報提供すれば足りるとされます。他方で、当該措置を講じていない場合には、当該講じていない措置の内容についての情報提供が必要とされています。

今の点ですが、そもそも、OECD8原則に対応する措置を講じていない第三者に提供していいのだろうかという問題提起はあって良かったように思います。提供先は契約等でその遵守を義務付けることができるはずですし、講じていない措置があれば、その分、本人の権利利益が害される危険性があるわけで、その手間を惜しんで、本人にリスクを寄せることが妥当かは議論があるはずです。とはいえ、実務的な提供の必要性も考慮して、ガイドラインは、本人が自らリスクを判断して同意すればいいという判断なのかもしれません。

仰るとおりかと思います。また、OECD８原則との対応関係を示すとして、その判断が難しい事例があります。その場合には、「現地法を遵守しています」という説明だけをする例もあるようです。現地法を遵守しているというだけを説明しても、消費者である個人が越境移転のリスクを適切に判断できるのかという疑問はやはりあります。

現地法は遵守していますと説明した上で、現地法と日本法の差分はどこにあるのかは個人情報保護委員会の情報提供文書を見てくれということはあり得るかと思います。しかし、いざ個人情報保護委員会による情報提供文書の個別項目を一つ一つみても、具体的な日本法との差分を理解しづらいというのは事実だとは思います。何らかの点数付けをした上で、国別にこの国はリスク大（赤）・リスク中（黄色）・リスク小（青）みたいにリスク度合いを3段階で色分けした方が余程わかりやすいような気はしているのですが、なかなか勝手にそういう色分けをすると色々各国からもクレームのつきそうですので難しいのかもしれません･･･。

越境移転について本人から同意を得る際に提供先が特定できない場合は、個人情報保護法上、情報提供項目に代えて、特定できない旨とその理由、さらに参考情報を伝えることになります。ガイドラインでは、保険会社における再保険の事例などが挙げられておりますが、実務上は、他にどのような事例がありましたか。

実務上は、特に、将来的に発生するかもしれない、外国企業への委託の場合がよく問題になると思います。基準適合体制の整備で整理すればそれで良いのですが、同意でやりたいという場合にどこまで広く認めるのかは問題になりますね。

この例外を根拠とする場合、当該事業者は外国の個人情報保護制度に関する情報提供が不要となるので、その前提としての調査も不要となりますが、何ら情報を提供しなくてよいわけではない点には注意が必要ですね。

はい、それは、参考情報として、どこまで伝えるべきかという問題でしょう。外国の候補が具体的に定まっている場合は当該候補を伝える必要があります。現在は候補地ですらないような国を除いて、候補国の名称と当該候補国の個人情報保護制度を伝える必要はあるでしょう。ところで、本人から同意を得る際に、提供先の第三者は特定できているが、すぐにその国の法制度の調査を行うことが難しい事例もあるように思います。たとえば、本人からの指示に基づいて外国にある第三者に対して、個人データを含む情報を提供する場合、本人からの指示に基づく性質上、提供先となる外国は全世界が対象となります。

その点は興味深いところでして、そのような場合も明文上の例外はありません。そうすると、形式的には、提供元の事業者が当該外国の個人情報の保護に関する制度及び当該第三者が講ずる個人情報の保護のための措置に関する情報を調査して、情報提供する責任があるということになりそうです。

海外送金の例や国内の旅行代理店を通じて海外旅行を手配した場合の当該代理店から航空会社や宿泊先への提供の例が想定できますね。この点については個人情報保護委員会の見解は明らかではありませんが、実務上は、各事例において可能な範囲での対応はしているようです。他方で、これらの事例では、本人が自ら、当該外国に対して情報提供することを望んでいるわけですので、明文上の例外として定まっているわけではないものの、今後の議論として、情報提供義務を一定程度緩和する余地もあり得るとは思います。そもそも外国に関する情報提供義務の趣旨は、個人データの取扱いにつき本人の予測可能性を高めることにあるのですから、本人が自ら提供先を具体的に特定し、当該事業者に提供の指示をした場合には、情報提供義務を緩和しても本人の権利利益の保護にもとるところはない、という考え方もあり得るでしょう。

似たような事例として、航空会社による利用者の個人データの提供もあり得るかと思いました。ただ、私がある航空会社のホームページを見たところ、案内されているのは個人情報保護委員会の情報提供文書だけで、40か国以外の整理は不明でした。

その点も興味深いですが、たとえば、航空会社が就航する国が40か国やEEA・英国に含まれている限りは、情報提供文書への案内で十分だとも判断できそうですね。

個人的には、この論点については、そもそも、情報提供義務に、今議論している「特定できない場合」以外の例外がないのが厳しいな、と思っています。例えば、本人が海外のホテルを公式ウェブサイトから直接予約する場合は、ホテルが直接本人から個人情報を取得していますので、情報提供義務を含む越境移転規制は適用されませんよね。一方で旅行会社経由で海外のホテルを予約すると、旅行会社から海外のホテルに個人データが提供されるということで旅行会社に情報提供義務が課せられてしまいます。これに関連して、個人データの第三者提供に関する確認・記録義務については、ガイドラインで「本人による提供」や「本人に代わっての提供」であれば、解釈上適用が除外されてますよね。海外送金は「本人に代わっての提供」の典型例だと思います。なぜ越境移転の情報提供義務は確認・記録義務と同じような例外がないんでしょうか。

蔦弁護士のご指摘は、先ほどの岡田弁護士の発言と同趣旨と理解しました。第三者提供の確認記録義務も明文上の例外ではなく、前回の改正法が成立した後で、ガイドラインにより解釈上の例外として設けられたもので、実務上の要請に柔軟に対応したものと認識しています。情報提供義務に関しても、このような解釈上の例外を設けることが完全に否定されているわけではなく、今後、同じような例外が示される余地はあるように思いますし、期待しています。

次に、基準適合体制に基づく提供の場合ですが、こちらは事前の情報提供ではなく、本人の求めがあった場合のみとなります。そうすると、あらかじめプライバシーポリシー等の文書の形式にして予め示す形にしておく必要はありません。もちろん、問い合わせがあった場合に回答すべき内容は準備しておく必要があります。情報提供事項のうち、例えば、「当該第三者による相当措置の実施に影響を及ぼすおそれのある当該外国の制度の有無及びその概要」「当該第三者による相当措置の実施に関する支障の有無及びその概要」の２つは事前調査が必要ですが、個人情報保護委員会による情報提供文書の内容と重複する部分がありますので、これを参照するといった対応が可能です。本人から情報提供の求めがあった場合の留意点はありますか。

本人の同意を得る際は提供は同意後に行われるので提供先が不明ということがあり得ますが、基準適合体制の場合は、既に提供したものについて情報提供が求められます。そのため、提供先が不明という事態が起こり得ないはずですから、情報提供を省略することは予定されていません。

提供先が不明であれば相当措置をどう講じているのか担保できませんので、当然といえば当然ですね。

あとは、金融分野GLで、金融分野における個人情報取扱事業者は、本人の求めに応じて事後的に情報を提供する旨を「個人情報保護宣言」に記載の上、インターネットのホームページへの常時掲載又は事務所の窓口等での掲示・備付け等により、公表することとする、とされていることから、これに倣ってプライバシーポリシー上にその旨を記載する事業者もいます。

基準適合体制の場合は、本人に対して事前に情報提供されないため、本人は自らの個人データが越境移転された事実を知る契機がないおそれがあります。いくら情報提供の求めができる制度があるとしても、実際に活用されないないことになりかねません。その意味で、プライバシーポリシー上に、そのような求めができることを記載しておくことは、本人に契機を与える点でも望ましい対応といえます。

あとは、金融分野GLでは、基準適合体制に基づいて外国にある第三者に個人データを提供した場合、提供先の第三者が所在する外国の名称ををインターネットのホームページへの掲載等により、公表するとともに、定期的に更新することが望ましいとされている点も参考になります。

ありがとうございます。一般の事業者がそこまで対応する例は多くないようですが、今後の対応動向にも注目していく必要がありますね。

ところで、基準適合体制を根拠として提供した場合において、「相当措置の継続的な実施の確保が困難となった場合」には当該第三者への提供を停止する必要があるわけですが（規則18条1項2号）、仮に提供先の国にガバメントアクセス等の制度があったとしても、当該制度の存在自体によって、これに該当するものではなく、当該第三者による個人データの取扱状況や、当該制度の運用の状況等を踏まえて、外国にある第三者による相当措置の継続的な実施の確保が困難となったか否かを個別の事案ごとに判断する必要があるとされております（QA12-17）。この点は、比較法的にはどう評価されるでしょうか。

たとえばGDPRでも越境移転に際してはデータ越境移転評価（TIA）が求められるわけですが、ガバメントアクセスの制度があるというだけで越境移転が絶対にできないというわけではなく、実際のガバメントアクセスのリスクに応じたリスクベースによる評価は許容されて然るべきかと思います。日本の個人情報保護法もこの点は同様かと思います。

では、実際にガバメントアクセスの要求に応じて個人データを提供してしまった場合は実務上どう対応すべきでしょうか。この点について、パブリックコメントにおいて、直ちに提供を停止しなければならないわけではないと回答されていますが、安易にそのまま提供し続けるわけにもいかないと思われます。

そのパブリックコメントにおいて、当該提供先において、当該外国の政府による要請に対応した個人データの提供が認められるか否かは、個人データの性質や提供の必要性等を踏まえた個別の事案ごとの判断が必要であり、例えば、提供の必要性が認められないにもかかわらず、当該提供先が漫然と個人データの提供を行っている場合には、当該提供先による相当措置の実施に支障が生じていると評価される可能性があるとされている点は重要でしょう。当然、提供元の事業者も提供先において提供の必要性がないのに漫然と個人データを提供していないかを定期的に確認する義務はあります。

基準適合体制に基づく越境移転をしたことで負担する定期的な確認義務として重要な点ですね。一方で、本人の同意を根拠として越境移転した場合にはこのような定期的な監督義務は明文上ありません。

ただ、本人から同意に基づき越境移転した場合であっても、当該提供行為が委託の趣旨である場合には、委託元として監督義務を負うべきという議論はあると思います。

委託先への監督義務としてガバメントアクセスへの対応についても責任を負う可能性があるということですね。そこは重要なご指摘かと思います。

外国がらみで、「外的環境の把握」についても簡単に議論しておきたいと思います。令和２年改正で保有個人データに関する公表等事項に安全管理措置が追加され、さらにガイドライン（通則編）の改正により、安全管理措置の内容に「外的環境の把握」という項目が追加されました。これにより、外国にある第三者に個人データの取扱いを委託する場合や、外国にある第三者の提供するクラウドサービスを利用する場合、外国に設置されたサーバに個人データを保存する場合等に対応が必要となります。

保有個人データの公表等事項に加わったことで各社のプライバシーポリシー対応をみると、外的環境の把握に関しては、「個人データを保管している外国における個人情報の保護に関する制度を把握した上で安全管理措置を実施」するという記載例や、単に「外国」にとどまらず、具体的な国名を記載する例があります。具体的な外国名を記載しない場合は、本人から問い合わせがあれば遅滞なく回答するという運用と理解しています。

そうですね。外的環境の把握とは、①外国において個人データを取り扱う場合に、②当該外国の個人情報保護制度等を把握した上で、③個人データの安全管理のために必要かつ適切な措置を講じることですので、②の前提として、調査は必要なわけですが、ガイドライン上、本人の知り得る状態におく必要があるのは、外国の名称であるとされているので、そのような対応が見られるところです。他方で、外国の個人情報保護制度は本人の知り得る状態におく対応が「望ましい」とされるにとどまりますね。そうすると、越境移転の場合と異なり、外国の個人情報保護制度について本人に伝える必要はないということになります。

セキュリティの文脈でも、海外でデータを取り扱うことは、特にクラウド利用の関係で、リスクとして捉えなければならないとされています。例えば、NISCが策定している「政府機関等の対策基準策定のためのガイドライン」でも、海外にデータセンターが設置されている場合、その国の執行機関の命令でデータが強制的に開示されたり、サーバーごと没収されたりするリスクがあるとされています。これはあくまで政府機関に関するものですが、重要インフラ関係のドキュメントにも同じような記述があります。個人情報保護法における外的環境の把握は、令和２年改正に関する政令・規則の整備に当たって、海外でのデータの取り扱いに関するリスクにフォーカスして、例のメッセージアプリ事業者に関する事案もあって正式にガイドラインで盛り込まれたという理解ですが、海外で個人データを取り扱うことのリスクを事業者自身が法制度を含めて把握することが重要であって、国はともかく法制度まで本人に示すことまでは不要という考慮もあったのかな、と思っています。後はそこまでの情報提供を求めるならさすがにガイドライン改正じゃなくて法改正でやれよ、とも思いますが。

なるほど、たしかに、条文上、安全管理措置が「必要かつ適切な措置を講じる」のみ規定されてますが、法律上、何を考慮し何をすべきかをより具体的に規定していくことも今後は検討されて良いですよね。さて、事業者は外国にあるクラウドサービスを利用することがありますが、その場合、クラウドサービス提供事業者が所在する外国の名称及び個人データが保存されるサーバが所在する外国の名称を明らかにする必要があります。しかし、実務上、サーバの所在国が特定できない場合があります。その場合も、①サーバが所在する国を特定できない旨及びその理由、及び②本人に参考となるべき情報を本人に知り得る状態におく必要があるのですが、実際にどのような対応例がありますか。

実際にプライバシーポリシーに書くわけではなく、問い合わせがあった場合に回答する準備をするということが多いとは思います。そのうえで、サーバ提供事業者に問い合わせたが回答がなく、他に手がかりもない場合なのか、それとも、サーバ提供事業者への問い合わせに対して回答はないが、ウェブページからサーバ所在国の候補場所は確認できる場合かで、対応は分かれ得ると思います。特に、前者の場合は、そもそも判断の手がかりがないことになってしまい、果たしてそのようなサービスを利用を続けて良いのか（代替サービスに乗り換えられないのか）が特に問題になってしまうかと思います。ここはSaaS等のサービス提供会社側も問題意識を持つ必要があります。この点の情報提供に誠実に対応してくれる事業者が選ばれやすくなり、ここに誠実に対応しない事業者は、他に代替可能なサービスがあれば敬遠されてしまう可能性があるでしょう。

本日は時間の関係もあって議論できませんが、2022年の電気通信事業法改正法に関して、「特定利用者情報の適正な取扱いに関するワーキンググループ」における議論が始まっています。一部の大規模な電気通信事業者が特定利用者情報の取扱いに関して公表しなければならない情報取扱方針（新電気通信事業法27条の8）において、外的環境の把握と似たような事項を公表事項とするかどうか等を含めて検討が進んでいるようですので、こちらも要注目ですね。

さて、そろそろお時間となります。越境移転と情報提供義務との関係では、外国の個人情報に関する法制度の把握が特に重要ですが、これらは各国の法改正により大きく影響されるところですので、令和２年改正法施行時に対応したから万全というわけではなく、定期的な調査等により更新していく必要がある点に留意いただきたいと思います。理論的な面も含めて、詳細はNBLの連載でも論じておりますので参考になればと思います。本日はありがとうございました。

今回は個人関連情報の第三者提供規制について議論していきたいと思います。個人関連情報の第三者提供規制は、従前の個人情報の定義や、いわゆる提供元基準説（個人データの第三者提供における「個人データ」該当性について、提供元を基準に判断する考え方）を前提にしつつ、個人データの第三者提供規制では対応できない、新たな問題状況に対応するものとして創設されました。個人データの第三者提供規制と個人関連情報の第三者提供規制の関係を整理するため、弊事務所弁護士によるNBLの連載記事（※1）から表を抜粋します。下記表の３は、従前個人データの第三者提供規制でカバーできていなかった領域ですが、これを個人関連情報の第三者提供規制で対応したと説明できます。

【表】個人データの第三者提供規制と個人関連情報の第三者提供規制の整理

この表をみると分かるように、あるデータを提供するときに、それが提供元において個人データであるか個人関連情報であるかによって規制のあり方が変わり、提供元においてどちらかに該当するのかを確定することが重要になります。実際の事案を検討する際にも、このような頭の整理が役立つのではないかと思いますが、改正法対応での経験を踏まえて説明をお願いできますでしょうか。

令和２年改正法対応では、新たに創設された個人関連情報の規制の注目度は高く、多くのご相談をいただきましたが、検討してみると、個人関連情報の提供の問題ではなく、個人データの提供や委託の問題として整理されることもありました。事案の検討の順序であれば、個人関連情報の定義が「生存する個人に関する情報であって、個人情報、仮名加工情報及び匿名加工情報のいずれにも該当しないもの」ですので、まず個人情報かどうかを確定するのが先になります。例えば、ユーザーのデータを突合する際には、CookieID、広告ID、メールアドレス、電話番号などがキーとして用いられますが、それぞれの事業者で個人情報となっているのか、個人情報ではなく個人関連情報なのかという点は注意して検討する必要があります。

ある情報が個人情報ですか、個人関連情報ですかというご質問をいただくこともありますが、事案ごとに個別に確認していく必要がありますよね。

個人関連情報の第三者提供規制は、本人の権利利益の保護の観点から、今まで規制をかけていなかった箇所に規制を加えたと認識していますが、逆は考慮してくれないのだろうか、と思うことがあります。要は、提供元基準では法的には個人データ提供に該当してしまうけれども、明らかに本人の権利利益侵害リスクが低いケースです。例えば、不審なメールの添付ファイルを開いてしまってマルウェアに感染したので被害拡大防止のためにメールを第三者に共有するケースを想定すると、メールの中に従業員の氏名やメールアドレス等が含まれていると、その部分だけ黒塗りにしても、提供元基準からすると個人データの提供になってしまいますよね。こうした形式的な個人データについては、こんなものに何で規制をかける必要があるんだと心の中で呪詛を唱えながら、個人情報・個人データに該当するかどうかとか、27条1項の例外に当たるかどうかとか色んな理屈を考えることになるのですが、何とかならないのでしょうか。

そのあたりは悩ましいですよね。提供先の状況が分からない以上、提供元で個人データであれば提供してはならないという考え方も成り立つ反面、確かに保護の必要性が低いものについても過度に規制されてしまうという側面があります。蔦弁護士の挙げた事例については、現状では27条１項各号の例外事由の検討において、情報の内容を加味して柔軟な解釈を導くほかないかなと思います。

さて、話を戻しておさらいにはなりますが、嶋村弁護士、個人情報該当性の検討のポイントの説明をお願いできますでしょうか。

それ単体で特定の個人を識別できるか（単体識別性）、他の情報と容易に照合することができ、それにより特定の個人を識別することができるか（容易照合性）の双方を区別してきちんと検討することが必要です。もちろん、個人識別符号に該当しないかということも別途検討する必要があります。

メールアドレスを例に説明しますと、例えば、メールアドレスに「naoto shimamura」という氏名を表す文字列が入っていれば、個人情報に該当します。また、メールアドレスに氏名を表す文字列が入っていなくとも、容易照合性の観点から個人情報になることがあります。例えば、ある事業者が氏名や住所等を含む顧客情報の一部としてメールアドレスを保有していれば、メールアドレスも個人情報となります。

そうすると、メールアドレスが個人情報とならず個人関連情報となるのは、メールアドレスを構成する文字列に氏名等が含まれていないなど単体識別性がなく、かつ氏名等の顧客情報も保有していないなど容易照合性の観点からも特定の個人を識別できない場合となりますね。

そうですね。例えば、メールアドレスと任意に設定したパスワードだけで登録できるウェブサービスもありますが、この場合には基本的に単体識別性が問題になるので、登録したメールアドレスに氏名が含まれていれば個人情報、氏名が含まれていなければ個人関連情報ということになりますね。ただ、こうしたサービスでも、ユーザー数が増えれば増えるほど、実際に登録されたユーザーのメールアドレスをふるいにかけて個人情報かどうか区別するのが難しくなります。担当者がメールアドレスを１つ１つみて個人情報か個人関連情報かを判断するというのも現実的ではないでしょう。

データベースの中に存在する個人情報を検出するようなサービスもあり、例えば判決文のマスキングや仮名加工情報作成への活用が期待されているようですが、メールアドレスから個人情報を検出して区別しているという話は聞かないですよね。実際に区別するとしても、データベースや判決文なら、ある情報が氏名なのかどうかは、文脈も頼りに判別することもできそうですが、メールアドレスには文脈がないですし、珍しい名前や外国人の名前まで判別できない場合もあるかもしれません。

職場のメールアドレスは比較的フルネームが入っていることが多いのではないかと思います。他方で、プライベートで利用しているフリーのメールアドレスにはフルネームを含めていないことも多いかと思います。

実務上の論点としては、この事例のメールアドレスのような、個人関連情報になり得るものも含めて、メールアドレスを一律に個人情報として整理することが許容されるのかという論点がありますが、このあたりの見解はいかがでしょうか。

パブリックコメントの回答（※2）では、「事業者は、個人情報に該当するか否かを判断し、個人情報に該当する情報については、個人情報の取扱いに適用される規律に従って取り扱う必要がありますが、改正後の法第26条の2（注：改正後の個人情報保護法31条）に従って取り扱う必要はありません。」とされており、必ずしも明確なスタンスは示されていないですね。ただ、もともと個人情報の規制の対象にならない領域を個人関連情報の規制でカバーしようとしたという経緯からすれば、個人情報に寄せて整理することは規制の潜脱にはならないのではないでしょうか。また、グローバルに展開している企業では、共通のポリシーなどを策定して個人情報の定義をグローバルに統一する場合もありますが、そうするとメールアドレスなども個人情報として扱うという運用になり、これ自体は合理的であるように思います。

個人情報保護委員会のQAの1-4では、「メールアドレスだけでも個人情報に該当しますか。」という質問に対して、「メールアドレスのユーザー名及びドメイン名から特定の個人を識別することができる場合（例：kojin_ichiro@example.com）、当該メールアドレスは、それ自体が単独で、個人情報に該当します。これ以外の場合、個別の事例ごとに判断することになりますが、他の情報と容易に照合することにより特定の個人を識別することができる場合、当該情報とあわせて全体として個人情報に該当することがあります」と回答されています。後段の容易照合性の話はよくわかるのですが、前段の単独での特定個人識別性の話は、そもそも妥当なのかという問題が本来あると思います。特にGDPRに慣れ親しんだ外国のクライアントや弁護士にこのQAを説明しようとしてもなかなか理解してもらえないところがあります。

このあたりは、個人情報保護法が何を保護しようとしているのか、ということにも関係する深淵な議論になってしまい、理論的な興味は尽きないのですが、実務上は、先程北山弁護士が言っていたとおり、一つ一つのアドレスで区別するのが実務上現実的ではないので、メールアドレスは個人情報として一律扱う方が良いと思っています。

いろいろな見方がありますが、メールアドレスを通じて名寄せができてしまうということはポイントになるかと思います。私たちは、日頃数多くのウェブサービスを利用していますが、登録の際には、メールアドレスとパスワードの組み合わせが求められます。サービスによっては、氏名や住所の入力を求めないものの、メールアドレスの入力は求められる場合もあります。ユーザーIDとしてメールアドレスを登録する事例を想起すれば、メールアドレスはまさに私たちを識別する記号として使われているような側面があり、それは社会生活において個人を他人から識別して特定する機能を有する氏名と同じ役割を果たしているのではないかと思います。

確かにメールアドレスにはそういう側面がありますね。私も生活する中でいろいろなウェブサービスにメールアドレスを登録していますが、漏えいした場合のセキュリティリスクの観点から、サービスによっては、あまり使っていないメールアドレス（転送用アドレスを含む）で登録したり、エイリアスを使ったりします。一応解説すると、エイリアスというのは要はメールアドレスのあだ名みたいなものです。例えば、メールアドレスの「@」の前の文字列は自分で決めることが大半だと思いますが、サービスによっては、ドット（.）をつけても、「+」を付けてその後何を入力しても、同じアドレスとして扱われたりします。今の例だと、具体的には「tsuta@....」というアドレスなら、「tsu.ta@...」としても、「tsuta+MHM@...」としても同じアドレスとしてメールが届くということです。ただ、それでもやはり重複は生じますし、実際のところ、私のようなケースはむしろ特殊で、ほとんど同じメールアドレスで複数のサイトに登録している方もいると思います。そうすると、このメールアドレスをキーにすることで、サイト横断でデータを統合することができてしまいます。現にCookie規制が厳しくなる中で、ハッシュ化したメールアドレスでユーザーのデータを統合するという話もでてきていますよね。

現行法の個人情報の解釈は、平成15年の当初法の解釈を踏襲していますが、メールアドレスの位置づけは、変わってきているかもしれないですね。

そうですね。もう１つ例を挙げると、携帯電話番号の例がありますね。現行法の解釈としては、携帯電話番号は単体で個人情報に該当することはないのですが、メールアドレスと同様の視点で捉えると、かなり特定個人の識別性が高いですよね。携帯電話番号ポータビリティの制度がかなり普及していることもあって、多くの人は何年もずっと同じ携帯電話番号を持ち続けると思います。しかも、携帯電話番号はいろいろなサービスで登録すると思われますし、ワンタイムパスワードをSMSで受け取るために携帯電話番号を登録するケースも増えていると思いますので、これをキーとする名寄せはできますよね。

こういう話をしていて思い出すのが、個人識別符号の議論ですね。個人識別符号が創設された平成27年改正当時の議論では、携帯電話番号が個人識別符号に該当しないかという議論がありました。結局、「様々な契約形態や運用実態があり、およそいかなる場合においても特定の個人を識別することができるとは限らない」（「個人情報の保護に関する法律についてのガイドライン」に関するQ＆A（以下「QA」という）1-25）という理由で個人識別符号該当性は否定されています。他には携帯電話番号を利活用するということも考慮されたようには思いますが、個人識別符号と整理してもおかしくはないと思います。

現行法では、個人識別符号に民間事業者が付番した番号・符号は含まないという整理がされていますが、将来的には議論がありそうですね。個人関連情報の第三者提供規制の本丸であったCookieも個人識別符号にするという解決策もあり得たところです。こうした個人情報の定義は、やはり外国の法制度にも目配せしていく必要があるかもしれません。田中弁護士、外国での議論の状況はいかがでしょうか。

たとえば、GDPRでは、「個人データ」は、識別された、または識別可能な自然人（データ主体）に関するあらゆる情報をいう（GDPR4条1号）とされ、幅広い情報が個人データに該当することになっており、メールアドレスや電話番号やCookieに紐付いて収集される情報も単体で個人データに該当するものとして扱われているかと思います。なお、Cookie等の利用については、GDPRの特則として位置づけられる、eプライバシー指令に基づく各国法により厳格に必須なものを除いて、同意が必要ということになっています。カリフォルニア州のCCPAでも、「直接的に又は間接的に、特定の消費者又は世帯を、識別し、関連し、叙述し、合理的に関連付けることができ、又は直接的に若しくは間接的に合理的にリンクさせることのできる情報」との広い定義が採用されています。そして、個人情報の類型として、「識別子」が挙げられており、「識別子」には、例えば、実名、別名、住所、一意個人識別子、オンライン識別子であるインターネット･プロトコル･アドレス、電子メール･アドレス、アカウント･ネーム、社会保険番号、運転免許証番号、旅券番号、又はその他の類似の識別子が含まれるとされています。グローバルにみても、比較的新しい規制の場合には、個人データ／個人情報の定義は広めにする傾向にあると思います。

こうしてみると、やはり日本では個人情報該当性という入り口の問題に焦点があたってきた経緯がよくわかりますね。そのような経緯を踏まえて、令和２年改正法では、個人情報の規制でカバーできないところを個人関連情報という別の形でカバーしたということですね。もっとも、別の形にしたが故に、規制がかえって複雑になっているきらいもありますね。いずれにしても、まず保護の範囲を広く取った上で、その性質に応じた対応を行っていくという対応は合理的であり、現行法の解釈・運用としても意識していくべきではないかと思います。個人情報保護法の議論をしていると、個人情報該当性、要配慮個人情報該当性という入り口の議論にどうしても注力しがちですが、個人情報でない、あるいは要配慮個人情報でないとしても、プライバシーの観点から一定の保護を及ぼすべきということあります。立法論としても、今後個人情報保護法がどこまでの範囲に保護を及ぼしていくかということは検討課題だと思います。

個人情報保護法も過去の立法の経緯を踏襲しつつ、新たに生じた問題に法改正で対応してきてきましたが、どこかでよりドラスティックな転換が必要になるのかもしれません。現実の問題の対処に当たっても、そうした大局的な視点をもっておくことは有益ですね。

続いて、「提供」の概念について議論していきたいと思います。個人関連情報の第三者提供規制は、「提供」という行為に適用されるため、この概念が重要になってきます。すなわち、事業者間での提供行為があれば、それは個人関連情報の第三者提供規制が問題となり得ますが、他方で本人から直接取得しているということであれば、第三者提供規制は問題となりません。

直接取得か第三者提供かという論点は、令和２年改正法以前でも、個人データの第三者提供時の確認記録義務の観点から問題になることがありました。この確認記録義務というのは、実務的に諸々の障害になることが多いのですが、例えばA社からB社に提供されるということではなくて、A社からいったん本人が取得し、本人がB社に提供しているということだとすると、第三者提供にはならず確認記録義務がかからないということになります。しかし、このような構成を採用する際には、やはり実態が伴っている必要があり、規制の潜脱とならないかきちんと検討することが必要です。今回、個人関連情報の第三者提供規制が創設されたことで、同様の論点がより顕在化したのではないかと思います。

確かにもともと提供元では個人情報にならない情報は規制の対象外ということで、個人情報保護法の観点からはあまり気にしていなかったということはあるかもしれません。

個人関連情報の第三者提供規制との関係でよく問題となるのは、A社のウェブサイトにソーシャルプラグイン等のタグを設置してB社に情報を送信させる場合です。この場合に、ウェブサイトを管理するA社からB社への提供行為とみるのか、あるいはB社によるユーザーからの直接取得とみるのか、という問題があります。QA8-10では、A社がB社のタグにより収集される情報を取り扱っているかどうかを基準としています。この見解は、平成30年のソーシャルプラグインに関する行政指導の事案以来採用されていた解釈を明文化したものですが、当時個情委に出向していた北山弁護士から背景の説明をお願いできますでしょうか。

当時も直接取得なのか、第三者提供なのかということは相当議論がありました。その中で、解釈の決め手となったのは、ソーシャルプラグインを設置する側の事業者は、実際にはデータの中身に触れていないということでした。小川弁護士の例でいえば、A社は、いわば、自社のウェブサイト上に、B社がデータを取得するための窓を設けてあげるだけで、B社は、その窓を通してデータを取得する一方で、A社は、その窓を通るデータに触れることはなく、その中身に関知しないという前提がありました。当時、「提供」とは、やはり自らが一旦手元で物理的に保有した後に、第三者に渡すという行為を念頭においていたので、A社がその中身が分かっておらず、触れもしないデータを提供しているというのはなかなか観念しにくいだろうと。データを取得するための手段であるソーシャルプラグインを設置しているのは他ならぬA社だという点を重視して、「提供」とすべきだという整理もあり得るとは思いましたが、他にも様々な考慮があって、結局、Q8-10 のような結論となりました。もっとも、当時の解釈は、個人関連情報の第三者提供規制まで念頭に置いたものではなく、今後も議論されるべき論点と思っています。

個人情報保護法は、個人情報の取扱いを規律の対象としていますので、個人情報に触れていない、中身が分からないという事業者に規律をかけられるかという発想にはなりますね。他方で、個人情報に直接触れないとしても、ソーシャルプラグインを設置するという行為は行っている訳ですから、こうした関与をどう考えるのかという問題はありそうです。

GDPRでは、共同管理者（joint controllers）という概念があり、「複数の管理者が共同して処理の目的および手段を決定する場合、これらの者は共同管理者とする」と規定されています（GDPR26条）。Fashion ID事件（※1）では、個人データの収集と提供の局面において、ウェブサイト運営者が、ソーシャルプラグインを提供するSNS運営事業者とともに、共同管理者に該当すると判示されており、「ソーシャルメディアユーザーのターゲティングに関するガイドライン」（Guidelines 08/2020 on the targeting of social media users）にも同様の趣旨の記載があります。日本法にはそもそも管理者と処理者という区別はなく、また共同管理者という概念もありませんが、これらの考え方からすれば、ソーシャルプラグインを設置したウェブサイト運営者について、個人情報または個人関連情報を取り扱っているものとして、一定の規律を及ぼすことはあり得るように思います。

GDPRの共同管理者の考え方は議論の参考になりそうですね。日本法でも似た問題意識は既にあり、例えばQA7-36は、A社がB社にアンケート調査の実施と統計情報の作成を依頼し、A社はアンケート調査の結果のみ受領するという事例が挙げられています。この場合、「調査を依頼した事業者が一切個人データの取扱いに関与しない場合」には、A社は個人情報を取扱っておらず、委託もしていないとされています。他方で、「調査を依頼した事業者が当該個人データの内容を確認できる場合」、「契約上、調査を依頼した事業者に個人データの取扱いに関する権限が付与されている場合」、「外部事業者における個人データの取扱いについて制限が設けられている場合」には個人データの取扱いの委託をしているとされます。

QA7-36は事例ベースでの記載になっていることもあり、他の事案でどこまで援用できるか判断が難しいですが、日本法でも個人情報に直接触れていなくとも、規律の対象となる場面はありそうですね。確かに、A社がB社にアンケート調査を指示しており、これを契機に個人情報の収集が始まっているので、B社だけではなく、A社も規律するというのは実態に即しているかもしれないですね。

A社も規律していくべきという方向性は理解できますし、あとはどのような場合に規律するかということですね。話をQA8-10に戻しますと、結局何が個人関連情報の「取扱い」なのかということがポイントとなります。「取扱い」の有無は、実際のデータに触れているかということのみならず、契約等によって定められる権限も加味して判断されますが、QA8-10の事例は現状どのように理解していますでしょうか。

一般的な理解としては、QA8-10を根拠にユーザーからB社が直接取得すると構成する場合が結構多いような気がします。「A社がB社のタグにより収集される情報を取り扱っている」というのをどれだけ広く読むのかが問題となりますが、これは例外的なケースだと狭く読んで、原則論に従うと直接取得だと考えていることが多いと思われます。QAも原則は直接取得であるとしているように読めますので、これが素直な考え方でしょう。しかし、仮に、たとえば、先程話題に出たGDPRのFashion ID事件の共同管理者の考え方のように規範的な評価を取込んで、この「A社がB社のタグにより収集される情報を取り扱っている」というのを広く読んでいくとすれば、むしろ、「提供」にあたる場合が原則になっていくことになります。

ここは、今後もまだ議論がありそうなところなので、要注意ですね。

現状はQA8-10で個人情報保護法の守備範囲が狭まっているという見方もできますよね。今月（2022年6月）成立した改正電気通信事業法では、利用者情報の外部送信に関する規律が設けられました（改正電気通信事業法27条の12）。こちらの規律の内容は、条文そのままだとかなりややこしいのでデフォルメしますが、要は、一部の電気通信サービス提供者が、利用者に対し、「端末に保存している利用者情報を外部送信するように」という指令を行う場合には、その利用者情報の内容等について、通知・公表等する必要があるというものです。今日の議論との関連では、外部への「送信」の「指令」とあるとおり、「提供」という概念が使われていない点がポイントとなり得ます。つまり、外部送信の指令を行った事業者がその情報を保有しているかどうかや「取扱い」の有無は無関係と解することもできそうですね。もともと利用者の意思によらずに外部の第三者に利用者情報が送信されることは問題視されていたのであって、このような問題意識は個人情報保護法と電気通信事業法とで共通するところもあるように思います。改正電気通信事業法の利用者情報の外部送信に関する規律については、現在、「プラットフォームサービスに係る利用者情報の取扱いに関するワーキンググループ」において、下位規則等の検討も進んでいるようですので、具体的な規律の内容や、この規律が適用される事業者の範囲等に留意する必要があります。適用範囲によっては、実務上かなり影響が大きい規律となる可能性があります。

さて、最後に個情法改正の対応でも質問の多かった、アクセス解析ツールの利用と個人関連情報の第三者提供規制について議論したいと思います。ここでは、NBLの連載記事でも取り上げた以下の事例を抜粋します。

この事例では、まずどのような点がポイントになりますでしょうか。

まず、大きな論点としては、①一次的な情報の取得主体がA社とB社のどちらとなるかということがあります。後ほど議論したいと思いますが、取得主体をB社とすると、その次の過程でA社がB社の情報にアクセスして確認できるようにすれば、B社からA社への提供に該当します。そして、②B社からA社への提供に該当することを前提に、A社において個人データとなるか、③個人データとなる場合に、ユーザーの同意が必要かというあたりが論点になります。また、④対象となる個人関連情報がデータベース化されているかという点も論点になります。

それぞれの論点について順次議論していきたいと思います。まず、①一次的な情報の取得主体がA社とB社のどちらであるかという点についてはどうでしょうか。

この論点も、先ほどの論点と同じように「取扱い」の考え方によるところがありますが、QA8-10の整理を前提にすると、ユーザーがA社のウェブサイトにアクセスした際にB社のサーバーに情報が送信されるという仕組みですので、基本的にはユーザーからB社が一次取得することになります。他方、A社での取扱いがあり、A社からB社に送信（提供）しているという整理をしようとするのであれば、A社がB社のサービスを導入した上で、自社のウェブサイトにトラッキングコードを設置するという関与をしている点に着目するのだと思いますが、現行のQ&A8-10からやや離れた考え方になりそうです。

B社が一次取得するという前提で、その後のフローを検討してみたいと思います。収集した個々の情報から、B社がA社のウェブサイトにおけるユーザーの全体的な動向をまとめて、A社に提供するということであれば、統計情報の提供として、規制はかかりません。他方で、B社において取得したA社のウェブサイト内での行動履歴等の個人関連情報をA社が保有する個人データと紐付ける場合であれば、個人関連情報の第三者提供規制の適用が問題になりそうです。

確かにその場合、データフローとしては、B社がA社に個人関連情報を第三者提供し、A社において個人関連情報を個人データに結びつけることになり、「個人データとして取得する」になってしまうようにも思われます。

ただ、A社としては、アクセス解析ツールを利用して、ユーザーの個人情報を取得しようとしており、その過程でいったんB社に個人関連情報の形で一次取得してもらっているともいえます。もともとA社が自社で取得できる情報をたまたまB社の方でいったん取得してもらうだけであると。そうすると、A社がB社に個人データの取得の委託を行い、B社がA社に代わって情報取得をしているものと整理できます。このように考えると、B社からA社への提供行為は個人データの委託の一環として行われるもので、個人関連情報の第三者提供規制は適用されないといえます。

確かにこの事例では、自社では取得できないデータを提供してもらって、データをいわばリッチにする事例でもなく、個人データの取得の委託と整理するのが妥当ですね。ただ委託と構成する以上、いわゆる「混ぜるな危険」も含め、個人データの委託に関する規律を遵守する必要がありますね。

そもそも個人関連情報の第三者提供規制は、個人関連情報が個人関連情報データベース等を構成する場合に限って適用されますが、④対象となる個人関連情報がデータベース化されているかという点はどうでしょうか。

もちろんケースバイケースの判断になりますが、個人関連情報の提供は、データベースとしてまとまったものを第三者提供することが大半でしょうから、この要件だけで規制の適用がないと判断できるケースはそう多くないように思います。この事例でA社からB社への委託ではないという前提に立った場合、普通に考えれば、B社において一定のIDでユーザーのデータを識別しているでしょうから、データベース化していないとは言いにくいだろうと思います。

個人関連情報データベース等の概念は、個人情報データベース等に平仄を合わせる形で規定されていますが、個人情報データベース等以上にイメージしにくく判断が難しいですね。ただ、相場感として、この要件でいろいろなものを提供規制の対象外にできるという感じではなさそうですね。

今議論した内容は、アクセス解析ツールに関する１つの整理であり、もちろん事案によって異なる整理もあるでしょう。議論した内容をまとめますと、上記の事例では、B社からA社への提供が問題となりますが、ユーザーの全体的な動向の把握であれば、統計情報の提供になり、規制の対象外となります。また、ユーザーID等をキーとして解析ツールで取得された情報と自社のもつ顧客データとの紐付けを行う場合には、個人データの取得の委託と整理でき、本人の同意は不要となります。もっとも、解析ツールで取得された情報をもともとB社が保有する個人データや個人関連情報と突合して広告配信に利用する、といった場合は、本人の同意取得が必要になるので、留意が必要ですね。

そろそろお時間となりました。本日の対談では、改正法の解釈・運用のみならず、これまでの立法の経緯や今後の方向性も議論することができました。個人関連情報の規制を検討する際には、複雑なデータフローの分析が必要になることもありますが、規制の位置づけや趣旨に立ち戻った検討も重要なのではないかと思います。本日はありがとうございました。

本日の対談のテーマは、プライバシーポリシーの最新動向です。個人情報保護法の令和２年改正が本年４月１日に施行されたことに合わせ、多くの会社がプライバシーポリシーのアップデートを行っていますし、弊所でも数多くの案件を担当しました。私も、多くの案件を受ける中でノウハウを蓄積し、事務所内の若手弁護士向けに、プライバシーポリシーに関するセミナーを行いました。今日はよろしくお願いします。

プライバシーポリシーの法改正対応や具体的な記載例は、さきほど、私からセミナーでお話ししたとおりです。法改正対応以外だと、プライバシーポリシーについては、どのような相談を受けることが多いでしょうか。まずは、北山弁護士いかがでしょうか。

新しくサービスを始める場合に、そのサービス用のプライバシーポリシーの作成をご依頼いただくことが多いですが、それに関連して、一つの会社が複数の事業やサービスを行っている場合に、プライバシーポリシーをどう構成していくべきか、という相談をよく受けます。

どのようなアドバイスをしていますか。私がすぐに思いつくのは、個別のサービスや事業ごとにプライバシーポリシーを個別に作っていく方法ですね。

はい。その派生形として、事業やサービスごとに個別にプライバシーポリシーを作成しつつも、それぞれのプライバシーポリシー上で共通する項目は、別途、まとめることもよくあります。

確かにそうですね。令和２年改正に関していうと、同一の会社であれば、事業やサービスごとに個別にプライバシーポリシーを作成していた場合でも、保有個人データに関して情報提供が求められている事項、すなわち、本人の権利行使に関する事項（法32条1項3号）や、安全管理措置に関する事項（法32条1項4号、施行令10条1号）については、同じ記載内容になるケースが多いかもしれません。

はい。プライバシーポリシーの数があまりに多くなると、更新した際に漏れが生じるなど、適切な管理ができていないことがあります。小川弁護士のご指摘のとおり、同じ記載内容になるケースが多い事項についても、微妙に異なった内容になっていることがあり、その違いの理由を把握できていない事例もありました。そのような事態を改善するには、数学で因数分解するのと同じように、同じ記載内容とすべき事項については一つにまとめてくくりだした方が、すっきりする場合もあると思います。

そこで、事業やサービスごとに、個別にプライバシーポリシーは定めつつも、共通する内容については、共通プライバシーポリシーを作成し、そこにリンクを貼って参照させるということが考えられます。

そうですね。ただ、例えば個人データの第三者提供の場面等でプライバシーポリシーへの同意を取得することが法律上必要となる場合などには、同意を求める内容は、わかりやすく示す必要があるので、わかりにくいリンク先に同意事項が記載されているだけだと、同意の有効性に疑義が生じる場合もあるかもしれません。

ありがとうございます。共通版にリンクを貼る方法で、個別のプライバシーポリシーを作成するときは、同意の点は留意しておいた方がいいですね。

逆に、複数の事業やサービスでプライバシーポリシーを作る場合、個別に作るのではなく、一つのプライバシーポリシーに全ての事業やサービスについてまとめて記載するのは、どうでしょうか。

あり得る方法の一つだとは思います。事業やサービスごとのプライバシーポリシーを敢えて定めず、一つのプライバシーポリシー内において、「X事業についての個人情報の利用目的は、次のとおりです。」「次に、Y事業についての個人情報の利用目的は、次のとおりです。」と書くような事例も実際にはあります。多様なサービスやアプリケーションを提供している事業者が、同意してもらうことを想定したポリシーを定めようとする場合、どのユーザーがどのポリシーに同意しているのか、という同意管理が非常に複雑になりかねないことから、単一のポリシーで管理したいという目的があるのかもしれません。

ただ、多くの事業やサービスがある事例で、一つにまとめると、プライバシーポリシーが長くなりすぎてしまうようなケースでは、まとめることは、必ずしもおすすめできない場合もあります。

というのも、利用者からすると、自分とは無関係の事業やサービスについて延々と記載がなされているプライバシーポリシーを読むことになるので、利用者目線ではわかりにくくなってしまう可能性もあります。また、あまりに広汎で多岐にわたる内容について全てを一括して同意するか否かというオプションしか与えないと、ユーザーが真に必要とするサービスとは全く無関係なデータ取扱いの同意が事実上強制されてしまうという弊害が生じることもありますので、同意の粒度を細かくしてユーザーの選択の事由を確保すべきというグローバルな趨勢にも反してしまいます。サービス設計に際しては、同意の取り方だけでなく、同意の撤回を認めるべきか、認めるとしてその範囲や方法なども問題となることが増えています。

確かにそのとおりですね。複数の事業やサービスがある場合に、どのようにプライバシーポリシーを構成していくかは、いろいろなアプローチがありますね。

プライバシーポリシーに関して、田中弁護士はどういう相談を受けることが多いでしょうか。

私は特にグローバル・プライバシーポリシーに関する相談を多く受けますね。

ユーザーが日本だけでなく外国にもいるオンラインサービスやアプリなどの場合に、日本法準拠で作られたプライバシーポリシーをグローバル化させたい、という相談や、その逆、すなわち、グローバル企業から、GDPR等に対応させて作成したプライバシーポリシーを日本法向けにローカライズさせたいという相談も多いですね。

日本向けのプライバシーポリシーをグローバル化させる場合、まず、どの外国の個人情報保護制度をスコープに含めるかどうかを検討する必要がありますね。

世界には、約200の国や地域があると思いますが、グローバル・プライバシーポリシーの検討対象に含める外国は、どのように選べばよいでしょうか。

一般論として、世界中にユーザーがいるのであれば、世界中のすべての国・地域を検討対象に含めるのが正論にはなります。もっとも、そのような方法は、現実的ではないですし、実践している事業者がいるとも思えません。ドラスティックな対策の一つとしては、たとえば、ユーザーのIPアドレスから国を判別して、特定の国のユーザーのみがサービスを利用できるように選別したうえで、その国の法規制のみを検討対象とする方法はありますよね。

確かに、ユーザーをIPアドレスでブロックする方法はありますね。ほかに、モバイル・アプリであれば配信地域を指定したり、ユーザー登録時に、ユーザーの所在国を選択してもらって特定の国の所在者しか登録できないようにしたりする、という方法もありますよね。

ただ、実際には、そうしたユーザー選別をできない場合も多いと思います。この場合、どうやってグローバル・プライバシーポリシーの検討対象に含める国を絞り込んでいくべきでしょうか。

多くの法域で要求される項目を共通項目として入れておくことで、一定のレベルまでの対応は可能です。しかし、各国法の個別対応（別紙作成等）も必要になり、この場合、一般的には、リスクベースド・アプローチに基づいて、対象となる国を選別することになると思います。

これは、つまり、対象となる外国を、クライアントの事業との関係で特に関係が深い国かどうか、その国は制裁が厳しい国となのかどうか、取り扱う個人データの量やセンシティブさなどの考慮要素を総合的に判断して選別し、クライアントの事業との関係で高いリスクを有する外国を優先的に個別対応することになります。

グローバル対応といえども、リスクが低い外国については、個別対応のスコープからは外しているケースは多いです。

サイバーセキュリティの文脈でも、リスクベースドアプローチは、有用なアプローチの一つですね。サイバー攻撃の複雑化・多様化に伴って、セキュリティ対策も多様化・複雑化していますが、全ての対策を取ることはできませんし、中には各々の対策が競合する等して両立しない場合もあります。費用対効果の観点から過剰な対策にならないようにする必要もありますね。ですので、リスク評価を行った上で必要な対策を選択することとなります。グローバルデータ保護法対応でいうと、リスクが高めとして対応を要する国・地域というと、やはりGDPRの対象となるEEA諸国や、GDPRと同等の法規制を有する英国が思い当たりますが、その他にはどうでしょうか。

最近は、アメリカのカリフォルニア州や中国についても対応する会社が増えてきています。他は、各社の事業の実態次第といえますが、たとえば、タイについてもGDPR類似の厳格な規制があるため、個別対応を検討することも多いです。弊所のタイオフィス(CMHM)には、個人情報保護規制を主要取扱分野とするタイ人弁護士もおり、多くのタイPDPA案件に対応しています。また、この他、中国・台湾・ベトナムも現地有資格者が複数おり、これらの法域についても弊所内部リソースのみでも助言可能となっています。

具体的には、プライバシーポリシーをグローバル化させる場合には、どのような構成とするのがよいでしょうか。

いろいろな方法が考えられます。

グローバルに共通に適用される共通部分（日本企業の場合は日本法対応を含む）を作り、そこでカバーしきれない部分については別紙を作ることが一例です。たとえば、GDPR対応の別紙やCCPA対応の別紙を作ることになります。それぞれの法域毎に別々のポリシーを用意することも可能です。

日本の個人情報保護法とGDPRとでは、共通する点も多いと思いますが、異なる点も多くありますね。嶋村弁護士、いくつか具体例を挙げていただけますでしょうか。

はい。たとえば、日本法には、GDPRにはない「共同利用」の概念があります。

また、日本法は、個人データの第三者提供について、原則として本人の同意を要するという規制がありますが、GDPRは、個人データの第三者提供を含めて、あらゆる処理に同意や正当な利益などの「法的根拠」を必要とする（GDPR6条）など、基本的な考え方が日本法と大きく異なりますね。またGDPRでは、本人に通知すべき点も日本法と異なっています。

どのようにグローバル・プライバシーポリシーを構成していくかについては、私は、いつも頭を悩ませながら案件に取り組んでいます。

ところで、グローバル・プライバシーポリシーの一類型だと思うのですが、世界中にグループ会社を有する日本企業から、グループ・プライバシーポリシーの作成を頼まれることはありますか。

はい。よくあります。全てのグループ会社に共通で適用されるポリシーを作りたいというニーズは高いです。この場合、全グループ会社共通の本体のポリシーと各国法別紙を作る方法が考えられます。しかし、このように統一的なポリシーを作る前提として、グループ全体の個人情報の管理体制がある程度統一化されている必要があるかと思います。たとえば、地域毎に事業形態も管理体制もバラバラであるという場合に無理矢理ポリシーを一つにしようとしても、実態にあわないものができあがってしまうことになるかと思います。一つにするにしても、ポリシーのなかで、たとえば、一定事業毎に記載項目を分けたり、事業分野毎にポリシーを用意したりすることも一案です。グループ共通ポリシーがあるとしても、たとえば特定のアプリだけはまた個別のポリシーを用意したりすることも可能であるため、各社が無理のない方法で進めていくべきかと思います。外部向けと内部の役職員向けのものは分けて作成して、後者についてはウェブサイトで一般公開はせずに、役職員だけに見せていることが多いかと思います。外部向けでも、顧客向けと採用候補者向けや株主向けを分けたりする例もあります。

世界中にグループ会社を有する場合、グループ会社だからといって一括りに扱うことはできず、資本関係の程度はもとより、グループ会社となった背景や日本本社との関係性などをきちんと把握したうえでプライバシーポリシーの設計をアドバイスすることが求められます。日本本社がゼロから立ち上げた現地拠点と、M&Aによって傘下となった拠点とでは企業カルチャーもポリシーも違うことが多いです。また、日本本社と現地拠点の関係性についても、現地の自主的な判断がどの程度尊重されてきたのか、現地のデータ保護責任者がどのようなキャラクターの人物であるのか等、単純に資本関係だけからでは判断できない様々な背景事情などもあります。そのような点も総合的に加味したうえで、プライバシーポリシーの設計方針も依頼者に応じてカスタマイズしていくことはよくあります。

先ほどのセミナーでは、保有個人データに関する権利行使の範囲が広がったこと、安全管理措置についての開示請求も認められるようになったこと、そして、これらの改正についてはプライバシーポリシーに影響を与え得ることについて話をしました。

実際に、企業から、そのような権利行使や開示請求などの相談を受けることは、よくあるのでしょうか。

金融分野や世界的にもユーザーを多く抱えているプラットフォーマーを除くと、数としてはかなり少ないと認識しています。私が個人情報保護委員会事務局に出向していた際に、保有個人データの開示請求に関する論点についてのガイドライン及びQ＆Aの改訂も担当しましたが、数として、そのような事例が多いという印象はありませんでした。

私も実際に請求を受けた、というご相談はそこまで多くはないですね。ただ、2020年の改正によって、利用停止や消去等を請求できる要件が拡大し（法35条3項）、個人データ漏えい等の報告対象事態が生じた場合（法26条、施行規則7条）も、法律上の権利として利用停止や消去を請求できるようになったことは留意が必要だと思っています。このとき、本人通知も義務ですので、通知を受けた、または漏えい等に関するプレスリリースを見た本人が、事業者に対して自らの保有個人データの消去を求めるケースが増えてくるのではないかと予想されますので、どうせ請求なんて来ない、と油断しない方がよいかと思います。

私としては、今回の改正法によって、個人データの授受の記録が開示請求できるようになったというのは、大きいと思います。

実際、変な営業の電話があったときに、「私の個人情報をどうやって入手したのか教えてほしい」と尋ねたことがあるのですが、「教えられない」などと一蹴されて、気持ち悪い思いをすることもよくありました。今は、個人データの第三者提供を受けた記録の開示請求をすれば、個人情報の出所がわかることになりますよね。

本人目線でいえば、今回の法改正で、行使できる請求権の範囲が拡大され、必要なときに権利行使しやすくなったということがいえます。

他方で、事業者目線では、従前よりも本人から請求権の行使を受ける可能性が高くなったということでもあり、いざ請求を受けた場合に適切に対応できるように準備しておくことが必要です。業種にもよりますが、典型的な事例をいくつか想定し、対応の指針を作成しておくことは有益だと思います。

先ほどのセミナーでも触れましたが、法律上の要求を超えて、個人情報の取り扱いについて、わかりやすい工夫を凝らしている企業が増えていることがレポートでも触れられていますね。

私は友人に、プライバシーポリシーを作る案件を多数担当している、という話をすると、「プライバシーポリシーはよく目にするけど、結局、よく読まないで同意しちゃいますよね」などと言われてしまうこともあり、せっかくの力作プライバシーポリシーが、やや軽視されているのが実情ではないか、と思うこともあります。

さて、法律で求められていないのに、企業が個人情報の取り扱いについて、わかりやすい工夫を凝らすようになった背景には、どのような事情があるのでしょうか。

ユーザーからのプライバシー上の懸念を払しょくし、安心してサービスを利用してもらうことが、ユーザーの維持・拡大につながると考えているからだと思います。

特に最近は、プライバシーや個人情報を気にするユーザーも増えてきています。そうしたユーザーの懸念に対して、単に法律を遵守するということを超えて、より高い透明性を確保してユーザーの個人情報を適切に扱う方針を積極的に打ち出していくことは、企業にとってもユーザーの信頼を得るために重要なことなのだろうと思いますね。プライバシーポリシーよりも更に高次の原理・原則を明らかにしていく「データ憲章」の策定のような試みも、その一環として位置づけられます。データ憲章を策定するために、企業としての在るべき姿について様々な部署の責任者の皆様と議論を重ねる機会も多いですが、そのようなインタラクティブな議論のプロセス自体が、より実効的なプライバシーガバナンス実現のための重要な要素であると感じています。

以前は、プライバシーポリシーの作成や改訂のご相談をいただく際、とりあえず法律との関係で最低限の準備ができればよいという前提でご相談いただくことが、少なからずあったのが実情です。しかし、ここ最近は、このような前提も徐々に変化しているように感じますね。特にグローバルプライバシーを作成する際は、より透明性をもった内容にする必要がありますから、比較法的な観点からもこのような変化は望ましいと思っています。

第1部で嶋村弁護士が触れたいわゆるダッシュボードの事例のように、第三者提供の許否を、ユーザー自身がいつでも自由に設定できるようにするという取り組みは、特にわかりやすいと思います。

そうですね。そろそろ時間がきましたので、第４回の対談はこれにて終わりにしたいと思います。

今回で4回に分けてお送りしてきた、改正個人情報保護法施行後セミナーに連動した対談企画は最終回となります。

日本の個人情報保護法の解釈は、今後も進展していくと思いますし、国外に目を向けると定期的に重要なアップデートがあるというような状況ですので、今後も皆様に適時に情報提供していきたいですね。

そうですね。また、最近では、電気通信やヘルスケア、金融、HRといった個々の業界に特有の問題意識に基づいて深堀りしたデータ関係のアドバイスを必要とされることも非常に増えていますし、AIなどのテクノロジーの特性をふまえてどのように柔軟な法解釈をしていくかという視点も重要です。弊所データ・セキュリティプラクティスグループでは、今後も、最新の動向を注視しつつ、依頼者の皆様の状況に応じて適切なアドバイスができるよう心掛けてまいります。

皆様には、お忙しいところ、弊所の連続セミナーをご覧いただき、また、対談記事を読んでいただいたことに感謝申し上げるとともに、今後も、弊所の弁護士がセミナーなどをする際には、ぜひご参加いただけると幸いです。ありがとうございました。