今、AWS環境でYouTube的な動画配信サービスがどこまで作れるかを検証している。
動画のアップロード、トランスコード、配信基盤あたりはEC2やS3、CloudFrontを組み合わせれば技術的には普通に動く。
ところがコメント欄やユーザー間のDM機能を足そうとしたところで、ふと手が止まった。
「これ、電気通信事業の届出がいるサービスになるのでは」
調べ始めたら電気通信事業法だけでなく著作権法、情報流通プラットフォーム対処法(旧プロバイダ責任制限法)まで話が広がって、想像よりハードルが高いものだった。
技術的に作れることと、公開していいことは別問題だと痛感したので、調べた内容をここに整理しておく。
なお自分は弁護士ではないので、この記事は個人開発者としての調査メモという位置づけ。
実際に事業として本格運用する場合は専門家に確認してほしい。
「他人の通信を媒介するか」で電気通信事業法の届出要否が決まる
まず電気通信事業法。回線設備を自前で持つかどうかで登録(第9条)と届出(第16条)に分かれていて、AWSのようなクラウド上に構築するサービスは自社で回線設備を敷設していないので、対象になるとすれば基本的に届出(許認可ナビの解説)の方になる。
判断の分かれ目は「他人の通信を媒介するかどうか」。
LRM社の解説がわかりやすくて、要は
「ユーザー同士がメッセージのやり取りをするのではなく、サービス提供者との間でしかやり取りが発生しない、あるいはメッセージ機能自体がない場合は届出不要」
ということらしい。
これを動画配信サービスに当てはめると、
動画を一方向に配信するだけなら「自分の通信」であって「他人の通信の媒介」にはあたらない
という整理になる。
逆にDM、コメントのリアルタイム相互配信、ライブチャットの中継のように
「利用者同士のやり取りを媒介する」
機能を足すと、届出の要否を検討する必要が出てくる。
自分の動画を上げて見てもらうだけなら、実はほぼノーガード
自分が投稿者で、見る側は自分だけという「個人ポートフォリオ的動画配信アプリ」のケースをまとめると以下のようになる。
- 電気通信事業の届出: 不要。他人の通信を媒介していないので対象外
- 情報流通プラットフォーム対処法: 対象外。他人が投稿するUGCが存在しないため、削除受付窓口の義務なども発生しない
- 個人情報保護法: 視聴者アカウント機能(ログイン、視聴履歴保存等)を作るなら形式的には対象になるが、個人開発・非営利・小規模ならプライバシーポリシーを一応用意しておく程度で実務上は十分と考える。
このパターンなら、今までの他プロジェクトと同じ感覚で「作って公開して終わり」で問題ない。
実際、私がこれまでAWS上に公開してきたアプリの大半はこの形なので、ここまでは想定通りだった。
「誰でも投稿できる」にした瞬間、法規制が並び始める
問題は「他のユーザーも動画を投稿できる」、つまり本当の意味でのUGCプラットフォームにした場合。ここから風向きが変わる。
電気通信事業の届出は、コメントやチャットのような相互通信機能を足すと要検討ゾーンに入る。ただし個人開発規模での摘発リスクは現実的にはほぼないので、理論上グレーというくらいの温度感で捉えておけばいい。
もう少し実務に効いてくるのが情報流通プラットフォーム対処法。
2024年5月に公布、2025年4月1日に施行された、旧プロバイダ責任制限法の改正版で、誹謗中傷や著作権侵害コンテンツの削除申請を受け付ける窓口を用意する義務がベースにある。
UGCサービスなら
規模に関わらず実質必須の対応
と考えていい。
規模が大きくなると義務も重くなる。
月間の発信者数が平均1,000万人以上、または総送信者数が2,000万人以上といった基準を満たすと「大規模特定電気通信役務提供者」に指定され、削除申請への対応状況の公表など追加の義務が課される。
2025年4月時点で総務省が指定した事業者はGoogle、LINEヤフー、Meta、TikTokの4社(北浜法律事務所の解説)。個人開発でこの規模に届くことはまずないので
「連絡先メールアドレスを1つ用意しておく」
レベルの最低限で足りる、というのが現実的な結論になる。
著作権法まわりでは、セーフハーバー規定(プロバイダ責任制限法系)を活用するための体制整備という論点もある。
Content ID相当の自動検出の仕組みがなくても
削除依頼窓口さえ用意しておけば法的責任は限定される
という建て付けになっている。
第三者が著作権侵害動画をアップロードできる設計にすること自体のリスクも見逃せない。GitHubにソースコードをパブリック公開する場合、「著作権侵害を助長するツール」と見なされるリスクが技術的な話とは別に発生する。
本命は著作権法だった、「公衆」の壁
ここまで調べて、実は一番厄介なのは電気通信事業法でも情プラ法でもなく著作権法だとわかってきた。
著作権法には「公衆」の定義を定めた条文がある。
第2条5項で「この法律にいう『公衆』には、特定かつ多数の者を含むものとする」と規定されていて、これは「会員だけに貸しているので不特定の人向けではない」といった脱法的な言い逃れを防ぐための条文らしい。
何人から「多数」になるかはケースバイケースだが、一般的には50人超という目安がよく使われ、過去の裁判例(中田英寿選手の詩の無断掲載が争われた事件)では「300名以上という多数の者の要求を満たす部数」が判断材料になった。
さらに厄介なのが第23条(公衆送信権等)。自動公衆送信の場合は「送信可能化」も権利の対象に含まれる。
送信可能化権とは、サーバーにアップロードして誰かがダウンロードできる状態を作った時点で成立する権利で、実際に誰かがアクセスしたかどうかは関係ない。
つまり「認証をかけているから、まだ誰も見ていない/限られた人しか見ていない」という運用実態は、法的な線引きの決め手にはならない。
対になるのが第30条の私的使用のための複製である。
自分や家族のようなごく限られた範囲での利用は、この例外規定でカバーされる。
判例上も「ごく限られた人的結合関係」というのが基準になっていて、音楽教室をめぐるJASRACとの最高裁判決(2022年10月24日)では、教師が生徒に向けて反復継続的に行う演奏について「公衆に対する演奏」にあたると判断されている。
一人ひとりに聞かせる演奏だとしても
対象が次々入れ替わる形で反復されれば公衆性が認められる
という考え方は動画配信にもそのまま効いてきそうな話だった。
認証をかければ安全、ではない
ここで自分が最初に持っていた誤解が
「パスワード認証をかけて知り合いだけに公開すれば私的使用の範囲に収まるはず」
というものだった。
実際に調べてみると、これは半分正しくて半分間違っていた。
境界線を決めるのは認証の有無ではなく、見せる相手の人数と関係性である。
配偶者や家族、同居人程度のごく親密な少人数であれば私的使用の範囲として扱われやすい。一方で友人・知人を個別に承認していく方式だと、人数が増えたり関係性が家族ほど密接でなかったりすると「特定多数」とみなされ、公衆送信扱いになるリスクが上がる。
認証機構があってもこのリスクは消えない。
つまり「OKな人なら誰でも承認する」という設計思想自体が、法的には公開に近いと判断される方向に働きやすい。これは完全に想定外だった。
認証機能さえ実装すればセーフだと思っていたので、この記事を書くために調べていなければ気づかずに実装していたと思う。
ここで一つ補足しておく。
ここまでの「私的使用/公衆送信」の話が効いてくるのは、あくまで著作権者の許諾のない第三者コンテンツが含まれる場合に限られる。
録画にBGMや他人の映像が紛れ込むケースなどがこれにあたる。
100%自分で撮影・制作したオリジナルのコンテンツであれば著作権は自分に帰属するので、何人に見せようが、公開しようが著作権法上は自由に配信できる。
「投稿者=著作権者本人」であることが前提になっている点は、読み返してみて説明が足りていなかったので、ここに明記しておく。
課金や年齢確認を足すと、また別の法律が出てくる
ここまでは動画配信の中核機能だけの話。
さらに機能を足すと、また別の法律が絡んでくる。
視聴履歴やアカウント情報を扱う以上、個人情報保護法の対応(プライバシーポリシー整備、利用目的の明示)は基本セット。
未成年アクセスを想定するなら青少年インターネット環境整備法の年齢確認・フィルタリング対応も視野に入る。
投げ銭やサブスク課金、広告収益分配のようにお金が絡む機能を足す場合は、資金決済法や特定商取引法が別途発生する。
個人開発・非公開・非営利の範囲であれば、このあたりは「一応知っておく」程度で十分だろう。
機能を足すたびにここに戻ってきて確認する
くらいの付き合い方でいいと思っている。
結局、個人開発規模ならどこまでやればいいのか
一通り調べてわかったのは、リスクの所在は
「他人が投稿できるかどうか」よりも「公開してしまうかどうか」で決まる場面が多い
ということ。
完全に非公開でアクセス制御をかけ、URLも公開しない状態であれば私的使用として許容される範囲が広い。
自分が録画・保存した動画に著作物が含まれていても、私的鑑賞の範囲に留まるなら基本的に問題にならない。
一方で公開デプロイしたりブログでURLを晒したりして第三者がアクセスしうる状態にした瞬間、公衆送信に該当する可能性が高い。
私的使用の例外は公衆送信には及ばないので、投稿者が自分1人だけだったとしても、そこに著作権者の許諾のない第三者コンテンツを置くと侵害になりうる。
現実的な対処法は3つだと考えている。
1つ目は、アクセス制御で非公開を維持すること。認証をかけてURLも公開しないなら、私的使用の範囲に収まるため著作権侵害コンテンツを保存すること自体のリスクは低い。
2つ目は、公開デモ用には自作・ライセンスフリー素材のみ使うこと。
GitHub README用のスクリーンショットや動画サンプル、公開デプロイ先で誰でも見られる状態にする場合は、著作権のある番組や音楽を使わず、自分で撮影した動画やCC0・ロイヤリティフリー素材だけを使う。
3つ目は、README やToSに一文添えること。
「本アプリは投稿者の私的利用を想定しており、第三者の著作物を含むコンテンツのアップロードは想定していない」
旨を明記しておくと、万一の際の意図説明として機能する。
音響指紋照合のような技術的な自動検出まで組み込むのは、単一ユーザー・非公開運用の個人アプリの規模には過剰だと判断した。
アクセス非公開とデモ素材の選定で、今のところは十分カバーできる範囲だと思っている。
おわりに
正直、動画配信サービスに触れるまで、法律面でここまで調べることになるとは想定していなかった。
結果として
「投稿者が自分だけの個人ポートフォリオ的アプリ」
であれば法的手続きはほぼ不要、というのは安心材料になったけど
「認証をかければ私的使用」
という思い込みが崩れたのは正直驚いた。
次にDM機能やコメント欄を実装したくなったときは、この記事を読み返すことになると思う。
引き続きAWS環境でどこまで作り込めるか検証中なので、進捗があればまた書く。
最後まで読んでいただきありがとうございました。
