この投稿は、Fediverse Advent Calendar 2022の8日目の記事です。
この記事ではこの先、主にGDPRと日本の個人情報保護法令がFediverseサーバーの運用にどう影響するか、ということを書いていきますが、その前に、個人情報保護法令の世界的な流れをおさえておきます。
個人情報保護法令の世界的な流れをひとことでいえば、「アメリカが経済活動優先でデータ覇権を握ったところを、ヨーロッパが中心となって国・地域がデータ主権を取り返せるよう法令を整備しているところ」です。
コンピュータの普及とともにプライバシーの概念が芽生え、1980年、OECD「プライバシー保護と個人データの国際流通についての勧告」の中で8原則が定められました（収集制限の原則・データ内容の原則・目的明確化の原則・利用制限の原則・安全保護の原則・公開の原則・個人参加の原則・責任の原則）。その後、1990年台〜2000年台は、個人情報保護法令による規制が比較的緩かったアメリカを中心にインターネット技術が発達し、その結果、アメリカ以外の国では、個人情報に対する主権が奪われた格好となりました。
2010年台に入り、「GAFA」「ビッグテック」と呼ばれる企業群がデータ覇権を握ったことによる政治的・経済的な弊害が表面化しました。そして2018年、EU諸国の「切り札」とも言える、GDPR（一般データ保護規則）が成立、施行されます。
GDPRには、たとえば、個人情報が知らないうちに国・地域の規制を掻い潜ってマーケティングに使われるといった、際限のない個人情報の流用を防ぐ狙いがあります。そこでGDPRでは個人データ処理の6原則制定やデータの域外移転原則禁止などを定めていて、これが世界に大きな影響を与えました。結果、日本を含む多くの国・地域が、個人情報保護法令でGDPRに倣う格好となっています。
私は、Fediverseにアカウントを持つ人やFediverseサーバー管理者がGDPRを恐れすぎる必要はないと考えていますが、その理由を以下で述べていきます。
GDPRの適用範囲はEEA（欧州経済領域）内在住の個人データを取り扱う事業者も含まれます。言い換えると、EEAからアカウントを作ることができるFediverseの各サーバー・インスタンスはGDPRの適用範囲になりえます。このことが原因で、EEAからのアクセスを閉じたFediverseのサーバー・インスタンスもあることはあります。また、GDPR遵守が困難という理由でEEAからのアクセスを遮断している商用ウェブサービスもあります。そして、GDPRに違反した場合の制裁金はかなりの金額です。ですから、Fediverseのサーバー管理者がGDPRを恐れる気持ちも理解できます。
しかし、前述の通り、GDPRは、際限のない個人データの流用を防ぐことを狙いとしています。その狙いは、個人データ処理の6原則に表現されています。
ここでMastodonのプライバシーポリシーを読んだことがある方はお気づきだと思いますが、Mastodonがデフォルトで表示するプライバシーポリシーはこれらの原則を満たすように書かれています。言い換えると、「Mastodonをそのまま運用するのであれば実は、GDPR違反を問われるおそれはあまりない」のです（Misskeyについては後述します）。
FediverseサーバーがGDPR違反に問われるとしたら、どのようなケースが想定されるでしょうか。
個人データ処理の6原則のうち1〜5、および6のうち完全性は、Fediverseサーバーにどのような情報を登録するか、ということです。Fediverseの目的は、SNSとしてコミュニケーションの場を提供することであり、Fediverseの情報を使用してマーケティングをすることではありません。そして、Fediverseで流れる情報は、マーケティング情報として属性化しにくい状態になっています。ひとつひとつの投稿に個人の属性情報が含まれることはありますが、そういった属性情報は解析されず、解析したとしてもその結果を共有したり精度を上げたりする仕組みがありません。したがって、Fediverseサーバーに対して機能拡張を施さない限りは、GDPR違反に問われにくいでしょう。気をつけたほうがいい機能拡張としては、たとえば、位置情報を連続して取得するような機能拡張や、タイムラインに広告を挟むような機能拡張が考えられます。このような機能拡張を実装する場合は、プライバシーポリシーにも反映させる必要があります。
そして、個人データ処理の6原則の6のうち機密性は、OSやミドルウェアの脆弱性には素早くアップデートを当てる・外部に不必要なサービスを公開しない・SSHのパスワードログインを無効にするなど、Fediverseサーバーソフトウェア以外の部分でも守りを固める必要があるところです。ですが、これはGDPR特有の原則ではなく、サーバーを運用する以上は誰もが守るべき原則です。
すなわち、Fediverseでやり取りされている情報は、基本的に個人データ（個人情報）として「最小限」のものなのでGDPR違反を犯しにくく、それゆえにFediverseサーバー管理者がGDPRを恐れすぎる必要はない、ということです。
最後に、EEAから域外へのデータ移転についておさえておきます。たとえば、EEAで運用されているMastodonホスティング「Masto.Host」でサーバーを運用していたのをやめて、日本国内に移転したい場合です。
EEA域外への個人データの移転は原則としてGDPR違反です。しかし例外があり、移転先の国・地域において個人情報保護法令に「十分性」があると認められている場合、または、「適切な保護措置」をとった場合は移転が可能です。そして、日本は欧州委員会から「十分性」があると認められています。ですから、EEA域内から日本国内に個人情報を移転することは可能です。すなわち、たとえばMasto.HostにあったサーバーをHostdonに引越したい、ということはGDPRの観点からも可能ということです。
GDPRそのものについては、個人情報保護委員会の『GDPR（General Data Protection Regulation：一般データ保護規則）』をご覧ください。
GDPRの話を先にしたのには理由があります。これは、日本の個人情報保護法令には「十分性」があると認められていることを理解していただくためです。
日本の個人情報保護法はGDPRほど厳しくないとはいえ、それでも、GDPRにおける個人データ処理の6原則と同等の定めがあります。また、個人情報取扱の委託先が海外の場合はより厳しい管理が求められます。そのため、多くの個人情報取扱事業者は、なるべく海外に個人情報を出さないようにと取り組んでいます。
さて、日本の個人情報保護法では、個人情報を自分以外が取り扱うことがあるケースを「委託」「第三者提供」「共同利用」という定義で整理しています。このうち「第三者提供」はそもそも宣言した上で事前に明確な同意を個人ごとにとりつける必要がありますし、「共同利用」は「本人から見て、当該個人データを提供する事業者と一体のものとして取り扱われることに合理性がある範囲」に限られますので、個人情報を提供する側から見ていちばん見えづらいのは「委託」です。個人情報取扱の「委託」先は、同意を取り付ける必要がない代わり、目的外利用が厳しく、委託先を監督することが求められます。特に海外に「委託」する場合は、日本国内法と矛盾する情報法制があることも考えられますので、より一層慎重になります。
そうすると疑問になってくるのが、国外のクラウドにFediverseの個人情報を置く場合です。
Fediverseのサーバーをクラウドに建てる場合のクラウドサービス事業者は「委託」先にはあたりません。これは、『個人情報取扱事業者が、個人データを含む電子データを取り扱う情報システムに関して、クラウドサービス契約のように外部の事業者を活用している場合、個人データを第三者に提供したものとして、「本人の同意」（法第23条第1項柱書）を得る必要がありますか。または、「個人データの取扱いの全部又は一部を委託」（法第23条第5項第1号）しているものとして、法第22条に基づきクラウドサービス事業者を監督する必要がありますか。』を読むと分かります。
クラウドサービスには多種多様な形態がありますが、クラウドサービスの利用が、本人の同意が必要な第三者提供（法第 23 条第１項）又は委託（法第 23 条第５項第１ 号）に該当するかどうかは、保存している電子データに個人データが含まれているかどうかではなく、クラウドサービスを提供する事業者において個人データを取り扱うこととなっているのかどうかが判断の基準となります。
当該クラウドサービス提供事業者が、当該個人データを取り扱わないこととなっている場合には、当該個人情報取扱事業者は個人データを提供したことにはならないため、「本人の同意」を得る必要はありません。
ですので、たとえばUSリージョンに日本人がFediverseのサーバーを建てたからといって、AWSやGCPなどを監督する必要まではありません。
ただし、令和4年完全施行の改正個人情報保護法では、個人の権利利益を害するおそれがある個人情報の漏えいがあった場合には、個人情報保護委員会への報告及び本人への通知が必要と定められました。特に、個人情報の漏えいの事実を知ってから5日以内に個人情報保護委員会に速報を行う義務が発生します。このことは覚えておきましょう。
GDPRの項でMastodonのプライバシーポリシーがGDPRに適合するよう書かれていると書きましたが、Misskeyについてはここでまとめておきます。Misskeyの場合、Github:misskey-dev/misskeyを見る限り、デフォルトで表示するプライバシーポリシーが存在しません。ですが、公式インスタンスMisskey.IOについては Github:MisskeyIO/policyに日本語と英語でプライバシーポリシーがあり、日本の個人情報保護法に適合するよう記載されているようです。
さて、最後に、『フジイユウジ::ドットネット』の2022-12-06『データやアルゴリズム、そしてユーザーにどう向き合うべきか（あるいはTwitterのホーム表示と時系列表示について）』に、このことと表裏の関係にある話が書かれています。
Twitterのデフォルトである「ホーム」表示が機械学習によって反応されそう・刺激的なツイートが優先表示される仕様になっていて、Twitterの場合データ上はどうしてもこちらの方が定着率がいいこと、そしてフジイさんがTwitterに対してではなくてプロダクトに関わる人全員に対して問題提起しているのが「データとして（サービスにとって）良い結果が出ているとき、（ユーザーにとって）不満や不快が膨らむのはやむを得ないことなのか」と書いていることについて。
今後10年で、この問いに対する答えが出てくるのではないか?というふうに、私は思っています。
TwitterのようなコマーシャルSNSに対するFediverseのようなノンコマーシャルSNSを、定着率という視点で見るとやはりコマーシャルSNSの方に定着する人が多い、良し悪しではなく事実としていまだそのような状況なのだと言えるでしょう。端的に、Fediverseが「避難所」とよく呼ばれるところにも、それがあらわれていると考えられます。
最初に、いままでの流れは、「経済活動優先でデータ覇権を握った」ことに対して、「国・地域がデータ主権を取り返せるよう法令を整備しているところ」と書きました。しかし、この流れが本当に正しいのかどうかは誰も断定できませんし、仮にこの流れが倫理的に正しいからといって、そのことと利用者の心を掴むこととは、別の話です。
結局のところ、利用者は何を望んでいるのか、ということは、いんたーねっつ（フジイさんリスペクト）を使う限り、常に問われていると言えるのではないかと思っています。