atprotoと日本法

日本でPDSやサービス運用をするにあたって、法律を気にする声が時々見られるため、個人的な見解をまとめてみました。

あくまで素人の個人的な見解であるため、話半分くらいで読んでいただければと思います。

実用上は公式情報や専門家の解説を確認のうえ、各自で判断してください。

要旨

自分が運用するPDSに他人を招くなら、電気通信事業者として届出が必要な可能性が高いです。
また、利用規約とプライバシーポリシーはしっかり定めて、PDSに設定しましょう。

その他(appviewやクライアント)はケースバイケースですが、該当しないかは一通り確認すべきです。

お金が絡むと考慮すべき範囲は一気に広がりますが、ここでは扱いません。

電気通信事業法

電話回線やインターネット回線を提供する事業者は、電気通信事業法という法律の対象になり、総務省への届出など、様々な義務が課せられます。
回線業者だけでなく、例えばメールサーバーのようなサーバーも通信経路の一部として「他人の通信を媒介する」と解釈されるので、電気通信事業法の対象となります。¹

通信を媒介すると見做されるには、大まかに「特定の相手に対して」「内容がそのまま」伝わることが条件になるようです。
SNSはDM(メッセージ)の有無が基準になると公式にも言われていますが、これは指定した宛先にだけ伝わるようになることで条件を満たす、という理解をしています。

なお、通信に相当しない事業(いわゆる第三号事業)でも特例的に対象に含まれる場合があり、XをはじめとするSNSはこちらに指定されるものが多いです。ただし、これは国から個別に指定されるもので、1000万以上のMAUが目安とされているため、ここでは割愛します。

atprotoとの関係

一番数が多いPDSの話からすると、これは電気通信事業法の管轄に含まれると言えるでしょう。

PDSには大きく以下の機能があります。

• 認証やハンドル変更等のアカウント管理機能
• ユーザーデータを管理するストレージ機能
• 認証付きでサービスAPIを利用するプロキシ機能

この中で、プロキシ機能が特に重要で、特定のサーバー(appview)に対してリクエストを転送しているため、「通信を媒介」していることになるわけです。
一般的なプロキシサーバーが該当することから、これはまず確実でしょう。

一方、ストレージ機能はレンタルサーバーやクラウドストレージと似たようなものなので、これだけでは該当しない可能性が高いです。ただし、非公開データが実装されれば、仕組みによっては該当するかもしれません。

relayは言うまでもないですね。firehoseを束ねるだけなので明らかに「通信を媒介」しています。

appviewやクライアントはケースバイケースですが、まあrecordを加工せず素通しするサーバーがあったら該当するくらいの感覚でいいのではないでしょうか。

条件

さて、atprotoサーバーは機能面では概ね該当することが分かりましたが、実際には使われ方も含めて判断する必要があります。ここでのポイントは、「他人のために提供しているか」「得しているか」です。

前者は簡単ですね。自分以外のアカウントを抱えていないPDSは、他人に提供しているとは言えないでしょう。一般的にはもう少し判断が面倒ですが、少なくともPDSに関しては「他人のアカウントを持っているか」で判断していいと思います。

後者は、直接金銭を受け取っていなくても該当する場合があることに注意してください。総務省のマニュアルでは、「例えば広告収入を得るなど、実質的に電気通信役務の提供により利益を上げているとみなされるときには、電気通信事業を「営む」ことに該当する」(p.15)とあります。
利用料でなく寄付などの形であっても、利益を得ているとみなされる可能性があるわけです。一方、同ページには「無償・原価ベースでこれを提供する場合は電気通信事業を「営む」ことに該当しない」ともあります。ということで、大雑把には「得しているか」で判断する感じです。

細かいところだと、継続的に提供しているかも判断材料になるようです。実験するだけならお目溢しがある、という感覚ですね。まあ他人を招くようなPDSを運用するなら、その時点で常用の可能性は高いでしょうが。

ともあれ、これに該当する場合、電気通信事業を営む者として届出などが必要になるわけです。

やるべきこと

電気通信事業者には、いくつかの義務が課せられます。

• 総務省への届出
• 漏洩や重大な事故の報告
• 検閲の禁止
• 通信の秘密の保護
• 利用の公平

まあ届出と報告以外は当たり前のことかもしれません。報告も、事故に関しては3万人以上の利用者がいる場合に限られるので、該当することはそうないでしょう。
届出に関してはこちらから。解説も巷にあるので、自分で調べてください。

情報流通プラットフォーム対処法

情報流通プラットフォーム対処法は義務ではなく免責の話ですが、PDSを運営するにあたっては知っておいた方がいいでしょう。
この辺りはatproto特有のものはあまりないと思うので、注意すべき法律として概要の言及に留めておきます。

簡単に言うと、ユーザーが違法なことをしても、プロバイダが適切に対応すれば責任を問われない、という法律です。逆に言えば、「適切に対応」しなければ、ユーザーの違法行為に対して責任を問われる可能性があるわけです。
「適切な対応」というのは具体的には、コンテンツの削除依頼や発信者開示請求への対応になります。

有料サービスの場合は押さえておくべき法律は更に増えますが、atproto特有のものはあまりないと思うので、ここでは割愛します。

著作権法

atprotoがユーザーコンテンツを共有する技術である以上、著作権法も避けては通れません。
複製権や公衆送信権はほぼ必須でしょう。これらについて利用者から許諾を得るためには、利用規約に明記する必要があります。

利用規約の内容は巷のサービスやテンプレートを見てください。
自分のものでないコンテンツの投稿を禁止事項に入れたり、他の利用者にも利用を許可する旨を記載するかも忘れずに検討しましょう。

atproto上の利用規約の扱い

atproto的な観点としては、どのように利用者の同意を得るかという話があります。

少なくとも日本法においては、利用規約が効力を持つためには、ただ置いてあるだけでは足りません。利用者が規約の内容を理解し、同意する必要があります。
利用開始前に規約への明確な同意を求めるために、アカウント作成時にチェックボックスを設けているサービスは誰しも見たことがあるでしょう。

PDSであれば、登録時の同意に関しては主に2つの方法で実現できます。
一つは、describeServerのレスポンスに利用規約のURLを含めること。createAccountから登録する場合のルートです。例えばBlueskyからアカウント登録する場合、このURLへのリンクを提示してくれます。招待コード制であれば、招待コードを渡す時に同意を求めるのも一つの方法でしょう。
別の視点で考えると、createAccountを使うクライアントは、利用規約のURLをdescribeServerから取得して、ユーザーに提示するべきです。

もう一つは、OAuthのアカウント登録画面に表示すること。提示の仕方はPDS(というかAuthorization Server)の実装次第ですが、まあ大体はBlueskyと同じような形式になるでしょう。

Bluesky PDSの場合、どちらのルートも利用規約URLはPDS_TERMS_OF_SERVICE_URLという環境変数に設定することになります。PDS自体に利用規約を置く機能はおそらく無いはずです。

appviewの場合、利用規約の提示はなかなかの難題です。APIがオープンなら、確実なタイミングは作れません。
以前Blueskyに聞いた際には、そのappviewを使うクライアントが責任を持ってappviewの利用規約を示すべき、みたいな回答がありました。

著作権に関して言えば、appviewは第47条の4,5あたりで間に合うこともあるでしょうから、そこまで深刻な問題ではないかもしれませんが。

個人情報保護法

個人情報保護法も気をつける必要があるかもしれません。PDSであればメールアドレスを登録することが多いと思いますが、それだけでも場合によっては個人情報として扱われます。
atprotoは大部分の情報がオープンとはいえ、それでも保護すべき情報はそこかしこにあります。

Bluesky PDSの場合、利用規約と同様にPDS_PRIVACY_POLICY_URLでプライバシーポリシーを示すことができます。

Footnotes

1. 厳密には、他人の通信を媒介するかどうかに関わらず、電気通信設備を提供する時点で電気通信事業法の範疇ではあります。多くの場合重要なのは届出が必要かどうかだと思うので、ここではそれを基準にしています。 ↩