From 57359de030e555af59ea76b9076c473fee4ad7fa Mon Sep 17 00:00:00 2001 From: yo4e <5.9075346e+07+yo4e@users.noreply.github.com> Date: Tue, 18 Aug 2026 08:35:05 +0000 Subject: [PATCH 1/2] docs: refine prelaunch legal and naming review --- docs/JAPAN_TELECOM.md | 175 ++++++++++++------------------- docs/LEGAL_REVIEW.md | 237 ++++++++++++++++-------------------------- docs/NAMING_REVIEW.md | 160 ++++++++++++---------------- 3 files changed, 219 insertions(+), 353 deletions(-) diff --git a/docs/JAPAN_TELECOM.md b/docs/JAPAN_TELECOM.md index 9e5e133..6875370 100644 --- a/docs/JAPAN_TELECOM.md +++ b/docs/JAPAN_TELECOM.md @@ -1,146 +1,105 @@ -# 日本で nanne を公開運用する場合の注意 — 電気通信事業法 +# 日本で `nanne` を公開運用する場合の電気通信事業法ガイド -調査日: 2026-08-16 +**調査日: 2026-08-18** -nanne は MIT License で自由に利用・改変・再配布できます。 +> **重要**：これは、`nanne` を日本で公開運用する場合の公開情報に基づく調査メモです。個別の届出・登録の要否を確定するものではありません。収益化の有無、実際のデータフローおよび運営主体を整理したうえで、公開前に管轄の総合通信局へ確認してください。 -ただし、日本で nanne を利用者同士の通信を媒介するサービスとして公開・運用する場合、利用形態によっては電気通信事業法上の「電気通信事業」に該当し、登録または届出が必要になることがあります。 +`nanne` のMIT Licenseはコードの利用許諾です。公式サービスを運営する者や、自らホスティングして第三者へ提供する者に課され得る法令上の検討・手続を免除しません。 -この文書はOSS利用者向けの一般的な案内であり、法律相談ではありません。法令・手続は変更されることがあるため、実際の公開前には必ず最新の総務省・e-Gov情報を確認し、判断に迷う場合は管轄の総合通信局等へ相談してください。 +## 結論 -## nanne v1 の暫定判断 +`nanne` の想定する「招待URLを知る少人数が、宛先を指定して、内容を加工せずにテキストを交換する」機能は、総務省が例示する利用者間メッセージ媒介と同じ方向の機能です。メッセージ媒介そのものは、**他人の通信の媒介**に当たり得ます。[1] -READMEで想定している、招待URLで入る2〜数名のテキストチャットは、利用者Aのメッセージを利用者Bへ届ける「他人の通信の媒介」に当たり得ます。 +ただし、チャット機能があるだけで届出・登録が必要になるわけではありません。総務省のガイドブックは、他人のために役務を提供し、利益を得ようとし、電気通信設備を用い、反復継続して提供する場合に「電気通信事業を営む者」に該当すると整理します。無償・原価ベースで提供する場合は、この「利益を得ようとする」に当たらないと説明されています。[1] -一方、公開されていること、小規模であること、無料であること、Cloudflare等の外部インフラを使うことだけで、登録・届出の要否は決まりません。電気通信事業法上の「事業」に当たるか、誰の需要に応じて反復継続して提供するか、誰が設備を設置・運用するか、適用除外に該当するかを合わせて確認します。 +| `nanne` の運用事実 | 現時点の整理 | 公開前の対応 | +| --- | --- | --- | +| 自己利用・開発・一回限りの検証 | 反復継続または他人の需要への提供に当たらない可能性がある。 | 公開サービスの扱いに移る前に、運用事実を見直す。 | +| 無償・広告なし・原価回収を超える利益を意図しない継続提供 | 総務省ガイドブックの「営む」要件に当たらない可能性がある。ただし、実態判断は必要である。 | 収益源、運営目的、利用規約、設備構成を記録し、判断に迷う場合は総合通信局に確認する。 | +| 有料、広告収入、紹介料その他の利益を得る意図を伴う継続提供 | `nanne` の通信形態では、登録または届出が必要な電気通信事業に該当する可能性が高い。 | 事業開始前に総合通信局へ相談し、登録対象でなければ法16条の届出を行う。 | +| OSSを配布するだけで、開発者のサーバー・APIがメッセージを通らない | コード配布者と実際の通信サービス運営者は区別して考えるのが合理的である。 | self-hosted運営者が自らの提供形態について確認する旨をREADME等に明記する。 | -したがって、次のような公開運用を始める場合は、開始前に総合通信局へサービス概要を示して確認してください。 +この表は総務省の一般的な考え方を `nanne` の想定に当てはめたものです。**無料であること、小規模であること、Cloudflare等を使うこと、招待制であることのいずれも、単独では結論を決めません。** -- 利用者同士のメッセージをサーバー等で中継する -- 招待URLを通じて第三者へ反復継続して提供する -- 日本の個人事業主・法人が運営者になる -- Cloudflare、クラウド、ホスティング等を利用する +## 1. なぜ `nanne` のチャットは「媒介」の候補になるか -確認の結果、電気通信事業に該当し、登録対象でない場合は、電気通信事業の届出を開始前に行う候補になります。これは一般論であり、nanneの実際の構成だけで届出対象と確定するものではありません。 +電気通信事業法は、電気通信設備を用いて他人の通信を媒介すること等を「電気通信役務」とし、これを他人の需要に応じて提供する事業を「電気通信事業」と定義しています。総務省は、オンラインサービスでは、情報を本質的に加工・編集せず、送信時に受信者を宛先として指定する場合を「他人の通信の媒介」と説明し、メール、ダイレクトメッセージ、参加者を限定したWeb会議、ビジネスチャットを例示しています。[2] [1] -## まず確認すること +`nanne` v1 は、少人数の受信者を招待URLで特定してメッセージを届ける構想です。よって、公開タイムライン型の「場」の提供ではなく、上記のメッセージ媒介に近い前提で扱うべきです。メッセージを要約・変換・審査する機能を将来追加する場合でも、媒介性や他の規律が自動的に消えるわけではないため、仕様変更時に再確認してください。[1] -電気通信事業法上、次の事実を整理してください。 +## 2. 登録・届出・適用除外の分岐 -- 日本の利用者に対し、誰がサービスを提供するか -- 個人的・閉じた利用か、事業として反復継続する提供か -- 有料、広告、寄付、サブスクリプション等の収益性があるか -- 他人同士のメッセージを自分のサービスが媒介するか -- 利用者が不特定多数か、招待された少人数だけか -- 自ら設置する電気通信回線設備があるか -- サーバー、データベース、ログ、バックアップを誰が管理するか -- 適用除外に該当するか +電気通信事業を営もうとする者は原則として登録を受けますが、自ら設置する電気通信回線設備の規模・区域が省令基準を超えない場合等は登録対象から除かれます。その場合であっても、電気通信事業を営む者であれば法16条の届出が必要となり得ます。[2] -電気通信事業法2条は、電気通信役務、電気通信事業などを定義しています。利用者間チャットは、技術的には通信の媒介に当たり得ますが、個別の届出・登録判断は運用実態と設備構成によります。 +総務省のガイドブックは、他人の通信を媒介するサービスを、登録・届出が必要な類型として示しています。他方、他人の通信を媒介せず、かつ電気通信回線設備を設置しない「第3号事業」や、専ら一者への提供、同一構内での提供は登録・届出を要しない類型として整理します。招待制で少人数であることは、専ら一者への提供と同義ではありません。[1] [2] -## 登録と届出 +| 確認順序 | 確認する事実 | `nanne` での確認材料 | +| --- | --- | --- | +| 1 | 誰の需要に応じるか | 運営者、対象利用者、招待URLの発行者、公開範囲。 | +| 2 | 利益を得ようとしているか | 料金、広告、アフィリエイト、紹介料、寄付、スポンサー、原価回収の扱い。 | +| 3 | 反復継続して提供するか | ベータの期間、公開URL、運営・障害対応体制、利用規約。 | +| 4 | 他人の通信を媒介するか | 送信者、受信者、宛先指定、本文の加工の有無、送受信フロー。 | +| 5 | 誰が設備・回線・アプリを設置・管理するか | CDN、ホスティング、アプリ、DB、WebSocket、ログ、バックアップの構成図。 | +| 6 | 登録対象か、届出対象か、適用除外か | 上記を添えて管轄の総合通信局へ確認する。 | -電気通信事業法9条は原則として登録を定めつつ、設備の規模・区域などが省令基準内の場合に登録を要しない仕組みを置いています。登録対象でない場合でも、法16条の届出対象になる可能性があります。 +## 3. 届出が必要と判断された場合 -小規模なWebサービスだから自動的に届出、または自動的に対象外、とはいえません。 +e-Govの「電気通信事業の届出」は、法16条1項に基づく、登録対象者を除く者のための手続です。**事業開始前**に行い、手数料はありません。個人・法人の別および電気通信回線設備を設置するかどうかで届出書の様式が分かれます。回線設備を設置する場合には、別途、事業用電気通信設備の自己確認の届出等が必要となる旨も案内されています。[3] -法164条の適用除外には、相手方が一者だけの場合、小規模な設備の場合、他人の通信を媒介せず電気通信回線設備を設置しない場合などがあります。少人数の招待チャットは、利用者数が少ないことだけを理由に、他人の通信を媒介しない類型になるとは判断しにくく、実装・設備・運営形態の確認が必要です。 +届出書の法定記載事項には、氏名・名称および住所、業務区域、一定の場合の電気通信設備の概要等が含まれます。実際の様式・添付書類・自己確認の要否は、届出時点のe-Gov案内と管轄局の指示に従ってください。[2] [3] -また、適用除外に該当しても、電気通信事業法3条の検閲禁止、4条の通信の秘密の保護まで無くなるわけではありません。 +> 総務省は、登録・届出の照会先と提出先を、法人なら本店所在地、個人なら住所により管轄する総合通信局等として公表しています。[4] -## 届出をする場合の大まかな流れ +### 相談時に渡す1枚の説明資料 -### 1. 登録か届出かを確認する +公開前相談では、機能説明だけでは足りません。次のような事実を1枚の構成図と表にまとめると、登録・届出・自己確認を切り分けやすくなります。 -総務省の参入マニュアルで、自分のサービスが登録対象か届出対象かを確認します。サービスの説明だけでなく、設備構成、業務区域、運営者、外部インフラの役割を整理して相談してください。 +| 区分 | 記載する内容 | +| --- | --- | +| 運営主体 | 氏名・商号、住所、問い合わせ先、公式提供かself-hostedか。 | +| 収益性 | 無料・有料、広告、紹介料、寄付、スポンサーの有無と予定時期。 | +| 通信の流れ | ブラウザ、CDN/WAF、アプリ、リアルタイム接続、DB、受信者の順序。 | +| 設備と委託先 | 各コンポーネントの運営者、リージョン、管理権限、契約主体。 | +| データ | 本文、ルームID、IPアドレス、Cookie、アクセスログ、バックアップの保存先と保持期間。 | +| 運用 | 招待URLの発行・失効、管理者による本文アクセス、通報、障害・捜査照会への対応。 | -### 2. e-Govの「電気通信事業の届出」を確認する +## 4. Cloudflare・クラウドを使う場合 -公式手続は [電気通信事業の届出（e-Gov）](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00001) です。 +クラウドを使うこと自体は、媒介性や届出の検討をなくしません。総務省のガイドブックは、オンラインサービスにおいて、サービス・アプリ提供のためにクラウドを利用する事業者も、サーバーを設置する事業者に含めて説明しています。[1] -e-Govの案内では、法16条1項に基づく手続で、事業開始前に提出し、手数料はありません。個人・法人の別や、電気通信回線設備を設置するかどうかによって入力・添付内容が分かれます。 +そのため、公式版の運営者は、少なくともアプリ、データベース、ログ、バックアップ、CDN/WAF、監視・エラー通知のそれぞれについて、誰が管理し、何のデータにアクセスでき、どの国・地域に保存・処理されるかを棚卸ししてください。これは届出判断と、個人情報・通信の秘密・委託先管理の判断を分けて進めるためにも必要です。 -### 3. 事業内容を整理する +## 5. 通信の秘密と管理者アクセス -届出対象と判断された場合は、氏名または名称、住所、業務区域、設備の概要など、法令・様式で求められる事項を確認します。 +法3条は電気通信事業者の取扱中に係る通信の検閲を禁止し、法4条は通信の秘密の侵害を禁止しています。法164条3項は、同条1項の適用除外の事業を営む者についても、法3条および4条を適用すると定めます。[2] -例として、nanne型のサービスは次のように説明できます。 +したがって、メッセージ本文だけでなく、誰が誰といつ通信したかを推知させるログも、最小限に扱う設計が必要です。運営者が必要な場合に本文を閲覧できることを規約に一律に書くのではなく、目的・条件・権限・記録・保存期間を限定してください。 -> Webブラウザ上で、招待URLを知る利用者同士にテキストメッセージの送受信機能を提供するサービス。 +| 運用場面 | v1で決めること | +| --- | --- | +| 通常運用 | 本文を読まないことを原則とし、本文への恒常的な管理者アクセスを避ける。 | +| 通報・安全対応 | 受付方法、閲覧承認者、対象範囲、判断基準、アクセス記録、削除・停止手順を定める。 | +| 障害調査 | 本文を使わずに解決できるログを優先し、本文が必要なときの承認・記録を定める。 | +| 法的要請 | 受領窓口、真正性確認、保存措置、開示判断、専門家・関係機関への相談経路を定める。 | +| 削除 | 本文、添付が将来追加された場合の派生データ、ログ、バックアップを分けて保存期限を定義する。 | -これは正式な記載例ではありません。実際の申請はe-Govと総務省の最新案内に従ってください。 +## 6. 変更・廃止 -### 4. 変更・廃止時も確認する +法16条の届出後、氏名・住所等の変更は遅滞なく届け出る必要があり、業務区域または一定の電気通信設備の概要を変更しようとするときは事前の届出が必要です。事業の全部または一部を休止・廃止したときも遅滞ない届出が必要です。[2] -届出は、一度出せばその後どんな通信サービスを追加してもよい包括免許ではありません。 +有料化、広告導入、公開ルーム、検索、ファイル送信、音声・映像、外部の共通バックエンド、海外向け提供などは、収益性・通信の宛先・設備・利用者情報の扱いを変え得ます。実装前に、届出事項だけでなく通信の秘密、個人情報、外部送信、利用規約を再評価してください。 -- 提供する電気通信役務の種類等の変更報告は、変更後に提出する手続です。[e-Gov](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00002) -- サービス区域や電気通信設備の概要の変更届出は、変更前に提出する手続です。[e-Gov](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00004) -- 事業を全部やめる場合は、廃止後に提出する手続です。[e-Gov](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00007) +## 7. OSS配布と公式サービスの切り分け -## Cloudflare・外部インフラ +`nanne` のコードを配布するだけで、開発者のサーバー・API・ログ基盤が利用者の通信を一切扱わない完全self-hosted構成では、実際に利用者へ通信サービスを提供する導入者と、コード配布者を同一視しない整理が有力です。反対に、共通のAPI、リレー、認証、DB、モデレーション、ログ基盤を開発者側が提供するなら、実際のデータフローに基づく再評価が必要です。 -Cloudflare、クラウド、ホスティングを利用することだけで、nanneの運営者が電気通信事業上の検討対象から外れるとはいえません。 +READMEには、次を明記してください。 -少なくとも次を図にしてください。 +> `nanne` のMIT Licenseはコードの利用許諾です。自らホスティングして第三者にチャットを提供する運営者は、自己の運営形態、データ処理、行政手続および利用者対応について確認してください。公式サービスの説明や手続は、導入者自身の確認を代替しません。 -- アプリ、データベース、ログ、バックアップを誰が管理するか -- 通信設備・回線設備を誰が設置しているか -- メッセージ本文、IPアドレス、アクセスログを誰が見られるか -- データ保存地域と海外事業者への委託・移転の有無 -- 外部サービスが、サービス提供に必要なデータ以外を取得するか +## 参考資料 -第三者インフラの利用は、電気通信事業の登録・届出の論点と、個人情報の委託・第三者提供・外国移転の論点を分けて確認します。 - -## 通信の秘密とログ・モデレーション - -電気通信事業法3条は検閲を、4条は通信の秘密の侵害を禁止しています。保護対象はメッセージ本文だけでなく、通信の当事者、日時、識別情報など、通信の意味を推知できるメタデータを含み得ます。 - -nanne v1では、次を先に決めてください。 - -- メッセージ本文へアクセスできる管理者を最小限にする -- 通報対応、障害調査、法的要請、緊急対応の目的ごとにアクセス条件を分ける -- 通常運用で本文を読まない場合と、例外的に確認する場合を利用者へ明示する -- 何を、どの期間、どの理由でログ保存するかを決める -- 管理者アクセスを記録し、不要になったデータを削除する -- 削除要請や捜査関係事項照会を受けたときの保存・開示判断を一本化する - -「規約に、運営者が全メッセージを自由に閲覧できると書けばよい」という設計は避けます。必要性、範囲、利用者への説明、アクセス権限、保存期間を限定してください。 - -## 個人情報・Cookie・外部送信 - -電気通信事業法の確認とは別に、個人情報保護法と外部送信の確認が必要です。 - -ニックネーム、メールアドレス、IPアドレス、Cookie・端末識別子、メッセージ本文は、他の情報と容易に照合できるかなどにより、個人情報または個人関連情報になり得ます。v1では、取得データ、利用目的、保存期間・削除基準、クラウドや監視サービスへの委託、海外事業者、問い合わせ先をプライバシー通知に明記してください。 - -広告タグ、第三者アクセス解析、不要なトラッキングSDKは入れず、必要な外部サービスだけを一覧化する方針が安全です。外部送信規律の対象となるサービス構成であれば、通知、容易に知り得る状態、同意・拒否手段などを個別に確認します。 - -詳しい調査結果は [公開前法務・運用レビュー](./LEGAL_REVIEW.md) を参照してください。 - -## 利用者投稿・違法コンテンツ - -v1は公開タイムラインや不特定多数向け投稿を前提にしていないため、大規模なプラットフォーム事業者向け制度がそのまま適用される可能性は高くありません。ただし、違法・権利侵害コンテンツへの対応が不要という意味ではありません。 - -開始時点で、通報窓口、削除・ブロック・停止の基準、招待URLの失効、重大事故時のエスカレーション、未成年者の利用方針を用意します。公開範囲や利用者数を広げる場合は、別途再評価してください。 - -## nanneを使うだけで必ず届出が必要、という意味ではありません - -MIT Licenseはソフトウェアの利用許諾です。行政上の手続や法令遵守を代替するものではありません。 - -ローカルで試すだけ、開発環境で動かすだけ、自分だけが使う、といった利用まで一律に「届出が必要」としているわけではありません。 - -一方、第三者向けに公開し、利用者同士の通信を継続的に媒介するサービスとして運営する場合は、公開前に対象性を確認してください。 - -## 公式情報 - -- [電気通信事業法（e-Gov法令検索）](https://laws.e-gov.go.jp/law/359AC0000000086) -- [電気通信事業の届出（e-Gov電子申請）](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00001) -- [総務省「電気通信事業参入マニュアル」](https://www.soumu.go.jp/main_content/000739290.pdf) -- [総務省「電気通信事業参入マニュアル［追補版］」](https://www.soumu.go.jp/main_content/000477428.pdf) -- [総務省「電気通信事業参入マニュアル（追補版）ガイドブック」](https://www.soumu.go.jp/main_content/000799137.pdf) -- [個人情報保護法ガイドライン（個人情報保護委員会）](https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/) -- [外部送信規律に関する総務省FAQ](https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu_00002.html) - ---- - -軽率に作る。公開するときは、ちゃんと確認する。 +[1]: https://www.soumu.go.jp/main_content/000799137.pdf "総務省『電気通信事業参入マニュアル（追補版）ガイドブック』" +[2]: https://laws.e-gov.go.jp/law/359AC0000000086/ "e-Gov法令検索『電気通信事業法』" +[3]: https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00001 "e-Gov電子申請『電気通信事業の届出』" +[4]: https://www.soumu.go.jp/menu_seisaku/ictseisaku/denkitsushin_suishin/tetsuzuki/index.html "総務省『電気通信事業参入・変更手続の案内』" diff --git a/docs/LEGAL_REVIEW.md b/docs/LEGAL_REVIEW.md index 1460e96..4373fae 100644 --- a/docs/LEGAL_REVIEW.md +++ b/docs/LEGAL_REVIEW.md @@ -1,193 +1,132 @@ -# nanne 公開前法務・運用レビュー +# `nanne` 公開前法務・運用レビュー -調査日: 2026-08-16 +**調査日: 2026-08-18** -## この文書の位置づけ - -Issue #1 に基づき、nanne を日本で小規模に公開運用する前提で、法務・個人情報・通信の秘密・運用上の論点を整理した調査メモです。法律相談や個別案件の確定判断ではありません。公開前に、所轄の総務省総合通信局と、必要に応じて弁護士・弁理士へ事実関係を示して確認してください。 - -前提は、README にある次の v1 想定です。 - -- MIT License のOSS -- ブラウザで利用する、アカウント不要の招待URL方式 -- 2〜数名のテキストリアルタイムチャット -- 公開タイムライン、検索、SNS、画像・動画・ファイル投稿は持たない -- 一定期間後に削除する -- 日本の個人事業主が公開運用する可能性がある -- 利用者が自分でホスティングする可能性がある +> **位置づけ**：本書は、アカウント不要・招待URL・少人数・テキストのみ・一定期間後削除を想定する `nanne` v1 の公開前レビューです。AIによる公開情報の整理であり、個別案件の法的判断ではありません。公開時の運用事実と構成図を添え、管轄の総合通信局および必要に応じて弁護士・弁理士に確認してください。 ## 結論 -日本で公開運用を始める前に、最低限、次を完了させるべきです。 - -1. 実際の運営者、料金・広告の有無、反復継続性、設備構成を整理し、電気通信事業に該当するかを総合通信局へ確認する。該当し、登録対象でない場合は、電気通信事業の届出を開始前に行う候補になる。 -2. 運営者情報、問い合わせ先、プライバシー通知、利用規約、保存期間・削除方針を公開する。 -3. メッセージ本文と通信メタデータへのアクセス権限、モデレーション・通報対応・法的要請への対応手順、ログの保存期間を先に決める。 -4. Cloudflare、ホスティング、ログ、分析、エラー監視など、第三者へ送られるデータを棚卸しする。v1 は広告・アクセス解析タグを入れず、外部送信を最小化する方針が安全。 -5. 招待URLの漏えい対策、レート制限、通報・ブロック、削除・緊急停止の手順を実装する。 -6. OSS として配布する場合、各自のホスティング運営者が自分の利用者・設備・データ処理について責任を負うことをドキュメントに明記する。 - -「小規模」「無料」「Cloudflareを使う」だけで届出や個人情報対応が不要になるとは判断できません。一方、公開されたチャットは必ず届出が必要、とも断定できません。事業性、誰の需要に応じて提供するか、通信設備を誰が設置・運用するか、サービスの範囲を合わせて判断します。 - -## 1. 電気通信事業への該当性 - -### 調査結果 - -電気通信事業法は、他人の通信を媒介する電気通信役務を、他人の需要に応ずるために提供することを電気通信事業と定義しています。nanne のように、利用者Aのテキストを利用者Bへリアルタイムに届ける構成は、技術的には「他人の通信の媒介」に当たり得ます。 +`nanne` を日本で小さく公開するために最も重要なのは、**収益性を含む電気通信事業への該当性を公開前に確定すること**、**通信の秘密を前提にデータアクセスを最小化すること**、そして**利用者にデータ利用と削除方針を分かりやすく示すこと**です。招待制・少人数・無料という設計はリスクを下げ得ますが、それだけで届出、個人情報保護、外部送信、違法利用対応を不要にはしません。[1] [2] -ただし、届出・登録の要否は、チャット機能の有無だけで決まりません。次を事実として整理する必要があります。 +総務省のガイドブックによれば、`nanne` 型の宛先を指定した利用者間メッセージ機能は「他人の通信の媒介」に当たり得ます。利益を得ようとし、他人のために、電気通信設備を用いて、反復継続して提供するなら、登録または届出が必要な電気通信事業に該当する可能性が高い整理です。無償・原価ベースで利益を得る意図がない運用は、この「営む」の要件に当たらない可能性がありますが、公開時の実態を添えて確認してください。[1] -- 日本の利用者に対し、誰がサービスを提供するか -- 反復継続して運営するか、収益事業として行うか -- 自分で電気通信設備・回線を設置するか、第三者の設備上でアプリを運営するか -- 誰の通信を、誰に向けて、どの範囲で媒介するか -- 利用者が不特定多数か、招待された少人数だけか -- 外部サービスがデータを保存、処理、監視するか +| v1公開の優先度 | すべきこと | 目的 | +| --- | --- | --- | +| **必須** | 収益性、運営主体、通信フロー、設備・委託先を確定し、電気通信事業の登録・届出要否を総合通信局に確認する。 | 法令上の手続を公開前に確定する。 | +| **必須** | 利用規約、プライバシー通知、保存・削除方針、問い合わせ先を公開する。 | 利用条件とデータ利用を透明化する。 | +| **必須** | 本文・通信メタデータへの管理者アクセス、ログ、バックアップ、通報、法的要請の手順を文書化する。 | 通信の秘密と安全管理を実装・運用で守る。 | +| **必須** | 実際に送信されるデータを棚卸しし、Cloudflare、ホスティング、監視、分析等の委託先・保存地域を特定する。 | 個人情報、外部送信、委託先管理を判断可能にする。 | +| **強く推奨** | 招待URLの十分なランダム性・失効、レート制限、通報、ブロック、緊急停止を設計する。 | 悪用・漏えい・権利侵害の被害範囲を限定する。 | +| **強く推奨** | v1では広告・第三者解析・不要なSDKを入れず、外部送信を最小化する。 | 利用者への説明負担と情報流出面を減らす。 | +| **将来再評価** | 有料化、広告、公開ルーム、検索、ファイル送信、音声・映像、海外展開、共通バックエンドを追加する。 | 役務、データ、消費者保護、著作権・違法情報対応の前提が変わるため。 | -個人のローカル開発、試験、自己利用が直ちに届出対象になるわけではありません。しかし、日本で継続的に第三者へ公開運用するなら、対象候補として事前確認するのが妥当です。 +## 1. 電気通信事業法 -### 登録と届出 +### 現時点の判断 -法9条は原則として登録を定めつつ、設備の規模・区域などが省令基準内の場合に登録を要しない仕組みを置いています。その場合でも、法16条の届出対象になる可能性があります。小規模なWebチャットだから自動的に届出、または自動的に対象外、とはいえません。 +電気通信事業法は、電気通信設備を用いて他人の通信を媒介すること等を「電気通信役務」、その役務を他人の需要に応じて提供する事業を「電気通信事業」と定義します。[3] 総務省は、情報を本質的に加工せず、送信時に受信者を宛先として指定して他人同士を通信させる形を媒介と整理し、メール、ダイレクトメッセージ、参加者限定Web会議、ビジネスチャットを例示しています。[1] -法164条の適用除外には、相手方が一者だけの場合、小規模な設備の場合、他人の通信を媒介せず電気通信回線設備を設置しない場合などがあります。少人数の招待チャットは、利用者数が少ないことだけを理由に第三の類型へ入るとは判断しにくく、実装と設備の確認が必要です。 +`nanne` v1は、招待URLを通じて少人数の宛先へテキストを送る構想であるため、このメッセージ媒介の整理に近いと考えるのが安全です。総務省の同資料は、他人のための提供、利益を得ようとすること、電気通信設備の利用、反復継続の全要件を満たす場合に「電気通信事業を営む者」に該当すると説明します。料金だけでなく、無料サービスに広告収入を伴わせる場合も利益を得ようとするケースとして案内されています。[1] -また、適用除外に該当しても、電気通信事業法3条の検閲禁止、4条の通信の秘密の保護まで無くなるわけではありません。 +| 判断要素 | v1で確定すべき事実 | 対応 | +| --- | --- | --- | +| 提供主体 | OSS配布者、公式サービス運営者、導入先の誰が利用者に役務を提供するか。 | サービス画面、規約、問い合わせ先、インフラ契約主体を一致させる。 | +| 収益性 | 利用料金、広告、紹介料、スポンサー、寄付、原価回収を超える収益意図の有無。 | 公開前に方針を固定し、追加する前に再判定する。 | +| 通信形態 | 送信者・受信者、宛先指定、本文の加工の有無、公開閲覧の可否。 | データフロー図と仕様書にする。 | +| 反復継続性 | 一時検証か、一般利用者向け継続サービスか。 | ベータ公開を含め運用期間・対応体制を説明する。 | +| 設備 | アプリ、CDN/WAF、リアルタイム基盤、DB、ログ、バックアップを誰が管理するか。 | 構成図、リージョン、権限、委託先を整理する。 | -### nanne v1 の暫定評価 +登録対象でない電気通信事業を営む場合は、法16条の届出が必要となり得ます。e-Govは届出を開始前・手数料なしとし、個人・法人および回線設備設置の有無により様式を分けています。回線設備を設置する場合には、別途の自己確認届出等が必要となる旨も案内されています。[4] -nanne の想定は、次の理由から「日本で公開運用する前に総合通信局へ確認する」べきケースです。 +### 通信の秘密 -- 利用者同士のメッセージをサーバー等で中継する -- 招待URLを通じて第三者に反復継続して提供する可能性がある -- 日本の個人事業主による運用が想定されている -- Cloudflare等の第三者インフラを利用する可能性がある +法3条は検閲を禁止し、法4条は電気通信事業者の取扱中に係る通信の秘密を保護します。さらに法164条3項は、同条1項の適用除外の事業を営む者についても、法3条および4条を適用します。[3] したがって、適用除外と判断した場合でも、本文と通信メタデータを無制限に閲覧・利用できるものではありません。 -確認の結果、電気通信事業に該当し、法9条の登録対象ではない場合は、法16条に基づく届出を開始前に行う候補になります。届出対象かどうか、また登録が必要かどうかは、実際の設備構成と運用形態を添えて確認してください。 +v1では、通常運用で本文を読まない設計を原則とし、通報、安全対応、障害調査、法的要請のそれぞれについて、閲覧条件、承認者、対象範囲、アクセス記録、保存期間を定めてください。招待URLは秘密情報として扱い、ログに全文URLを残す場合にもアクセス権限と保持期間を限定します。 -### 届出の実務 +## 2. 個人情報・ログ・委託先 -e-Gov の「電気通信事業の届出」は、法16条1項に基づく手続で、手数料はありません。案内上は事業開始前の提出で、個人・法人、電気通信回線設備の設置有無などにより入力・添付内容が分かれます。 +個人情報保護委員会の通則ガイドラインは、個人情報データベース等を事業の用に供する者に、規模や営利・非営利を問わず適用され得ると説明します。個人情報が少ない小規模サービスでも、利用目的の特定・通知または公表、安全管理措置、従業者・委託先の監督、保有個人データへの対応等を、実際に取り扱うデータに応じて設計する必要があります。[5] -- [電気通信事業の届出（e-Gov）](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00001) -- [電気通信事業法（e-Gov）](https://laws.e-gov.go.jp/law/359AC0000000086) -- [電気通信事業参入マニュアル（総務省）](https://www.soumu.go.jp/main_content/000739290.pdf) -- [電気通信事業参入マニュアル［追補版］（総務省）](https://www.soumu.go.jp/main_content/000477428.pdf) +メッセージ本文、表示名、問い合わせ内容、IPアドレス、端末・ブラウザ情報、Cookie、ルームID、アクセスログは、単独または容易に照合できる情報と組み合わさることで個人情報または個人関連情報になり得ます。特にチャット本文には、本人が自ら健康、信条、犯罪被害等を記載する可能性があります。サービスが意図して収集しなくても、事故時の影響が大きい情報を含み得る前提で扱ってください。[5] -届出後にサービス内容を変える場合の手続も分かれます。 +| データ類型 | 目的を限定して記載する例 | v1の最小化方針 | +| --- | --- | --- | +| メッセージ本文 | ルーム参加者への表示、通報対応、障害復旧。 | 保持期間を短くし、通常は管理者が読まない。 | +| 招待URL・ルームID | 入室管理、失効・不正利用対応。 | 十分な推測困難性を持たせ、ログでの露出を抑える。 | +| IP・アクセスログ | セキュリティ、レート制限、障害調査、不正利用対応。 | 必要項目だけを短期間保存する。 | +| Cookie・ローカル保存 | セッション維持、入室状態、セキュリティ。 | 広告・行動追跡を入れず、目的を明記する。 | +| 問い合わせ・通報 | 連絡、調査、対応履歴。 | 受付窓口を分離し、閲覧者を限定する。 | -- 役務の種類等の変更報告は、変更後に提出する手続です。[e-Gov](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00002) -- サービス区域や電気通信設備の概要の変更届出は、変更前に提出する手続です。[e-Gov](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00004) -- 事業を全部廃止した場合は、廃止後に届出する手続です。[e-Gov](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00007) +漏えい等が起きた場合、要配慮個人情報を含む事態、財産的被害のおそれ、不正目的による漏えい等、または1,000人超の漏えい等では、個人情報保護委員会への報告と本人への通知が必要です。PPCは速報を概ね3〜5日以内の目安として案内しています。[6] v1公開前に、検知、封じ込め、証跡保全、影響評価、通知、問い合わせ対応の担当と連絡経路を決めてください。 -### Cloudflare・外部インフラ +### Cloudflare等への委託・海外処理 -Cloudflare、クラウド、ホスティングを利用することだけで、nanne の運営者が電気通信事業上の検討対象から外れるとはいえません。少なくとも次を図にして確認してください。 +外部インフラを使う場合、委託か第三者提供か、外国にある第三者への提供に当たるかは、契約と実際のデータ処理によって判断します。サービス提供者、CDN/WAF、クラウド、ログ・エラー監視、メール、サポートの各サービスについて、事業者名、契約主体、保存・処理地域、送信データ、目的、削除方法を一覧にしてください。個人データの委託では、委託先監督も必要です。[5] -- アプリ、データベース、ログ、バックアップを誰が管理するか -- 通信設備・回線設備を誰が設置しているか -- メッセージ本文・IPアドレス・アクセスログを誰が見られるか -- データ保存地域と、海外事業者への委託・移転の有無 -- Cloudflare等の外部サービスが、サービス提供に必要なデータ以外を取得するか +## 3. Cookie・外部送信 -第三者インフラの利用は、届出の要否と個人情報の委託・第三者提供・外国移転の論点を分けて確認します。 +メッセージ媒介サービスは、総務省が「利用者の利益に及ぼす影響が少なくない電気通信役務」として列挙する対象です。このため、利用者端末から情報を外部送信させるプログラム等を送る場合、原則として、送信される情報の内容、取扱者の氏名または名称、利用目的を、通知・容易に知り得る状態への設置・同意取得・オプトアウトのいずれかで確認可能にする必要があります。[2] [7] -## 2. 通信の秘密とログ・モデレーション +サービス提供に真に必要な情報や、事業者が利用者へ送った識別符号（first-party cookieのID）には例外があります。しかし、広告、第三者アクセス解析、行動計測、不要なエラー監視などは、必要性を個別に検討しなければなりません。[8] -電気通信事業法3条は検閲を、4条は通信の秘密の侵害を禁止しています。保護対象は、メッセージ本文だけでなく、通信の当事者、日時、識別情報など、通信の意味を推知できるメタデータを含み得ます。 +| 外部送信の候補 | v1の方針 | 公開時の確認 | +| --- | --- | --- | +| ルーム利用に必要な自社サーバー送信 | 必要最小限に限る。 | 送信項目と目的が役務提供に真に必要かを確認する。 | +| first-party session cookie | 安全なセッション維持に限る。 | 属性・有効期間・目的を整理する。 | +| CDN/WAF | セキュリティ・配信に必要な範囲で使う。 | 送信先、IP等の送信項目、契約・保存地域を通知に反映する。 | +| 第三者解析・広告SDK | **v1では導入しない。** | 導入する場合は外部送信規律とプライバシー通知を事前に再評価する。 | +| エラー監視 | 本文を送らない設定を優先する。 | 送信イベント、マスキング、保持期間、送信先を確認する。 | -v1 では、次の設計を文書化してください。 +## 4. 利用規約・プライバシー通知・削除方針 -- メッセージ本文へアクセスできる管理者を最小限にする -- 通報対応、障害調査、法的要請、緊急対応の目的ごとにアクセス条件を分ける -- 通常運用で本文を読まない場合と、例外的に確認する場合を利用者へ明示する -- 何を、どの期間、どの理由でログ保存するかを決める -- 管理者アクセスを記録し、不要になったデータを削除する -- 捜査関係事項照会や削除要請を受けた時の保存・開示判断を一本化する +個人情報保護法に「プライバシーポリシー」という名称のページを一律に要求する規定があるわけではありません。ただし、利用目的等を通知・公表し、問い合わせ・権利行使の窓口を示すため、公開サービスでは実質的に必要です。[5] -「規約に、運営者が全メッセージを自由に閲覧できると書けばよい」という設計は避けます。必要性、範囲、利用者への説明、アクセス権限、保存期間を限定してください。 +v1では、少なくとも次を公開画面から容易に到達できるようにしてください。 -## 3. 個人情報、Cookie、外部送信 - -### 個人情報保護法 - -個人情報保護法は、事業者の規模が小さいことだけで適用対象から外れるものではありません。ニックネーム、メールアドレス、IPアドレス、Cookie・端末識別子、メッセージ本文は、他の情報と容易に照合できるかなどにより、個人情報または個人関連情報になり得ます。 - -v1 の公開前に、少なくとも次をプライバシー通知に書きます。 - -- 取得するデータの種類 -- 利用目的 -- 保存期間または削除基準 -- クラウド・ログ・監視サービスへの委託 -- 海外事業者・外国サーバーが関係する場合の説明 -- 開示、訂正、削除、問い合わせ窓口 -- 事故時の連絡方針 - -個人情報の安全管理措置、不要となったデータの消去、漏えい時の対応も必要です。プライバシーポリシーという名前のページ自体が常に法律上の書類として要求されるという意味ではありませんが、利用目的等を利用者に通知・公表するため、公開サービスでは実質的に必須の文書です。 +| 文書 | 最低限の内容 | +| --- | --- | +| プライバシー通知 | 運営者、取得データ、利用目的、委託先・外部送信、保存期間、削除、問い合わせ、保有個人データへの対応。 | +| 利用規約 | 禁止行為、招待URLの取扱い、利用停止、通報、免責の範囲、準拠法・連絡先。 | +| 削除方針 | 本文、ルーム、ログ、バックアップごとの保持期間と削除処理の関係。 | +| 安全・通報ポリシー | 通報方法、緊急時の制限・停止、著作権・プライバシー侵害等の受付、対応の限界。 | -- [個人情報保護法ガイドライン（通則編、個人情報保護委員会）](https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/) -- [個人情報保護法 FAQ（個人情報保護委員会）](https://www.ppc.go.jp/personalinfo/faq/APPI_QA/) +「一定期間後に消える」と表現する場合、本文の削除だけでなく、検索索引、キャッシュ、監視ログ、バックアップからの消去時期を区別して説明してください。即時に全ての複製から消える設計でない限り、そのように断定しないことが重要です。 -### Cookie・外部送信 +## 5. 違法情報・権利侵害・未成年者 -外部送信規律は、Cookieという名前の技術だけを対象にするものではありません。Webサイトやアプリが端末に送信指令を出し、利用者に関する情報を外部へ送る場合に、サービスの種類、送信先、情報の内容、例外要件を確認する必要があります。 +`nanne` v1は公開タイムライン・検索・一般公開投稿を持たないため、大規模なプラットフォーム向け制度の指定対象に直ちに当たるとは限りません。しかし、招待URLが流出すれば、嫌がらせ、脅迫、個人情報、著作権侵害、違法な画像・リンク等が送られる可能性はあります。 -nanne v1 では、広告タグ、第三者アクセス解析、不要なトラッキングSDKを入れず、Cloudflare・エラー監視等の必要サービスだけを一覧化するのが安全です。外部送信の対象サービスに当たる場合は、通知、容易に知り得る状態、同意・拒否手段などを個別に確認します。 +v1では、禁止行為、通報窓口、招待URL失効、ルーム停止、再発防止、緊急連絡の方針を定めてください。本文を読まない原則と、安全対応で例外的に確認する条件は、通信の秘密への配慮と一体で設計します。画像・動画・ファイル送信を初期版で持たない判断は、違法コンテンツ・マルウェア・著作権リスクを減らす点で有効ですが、テキストだけでも違法利用への対応は必要です。 -- [外部送信規律に関する総務省FAQ](https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu_00002.html) +未成年の年齢確認は、アカウント不要・テキストのみのv1で直ちに一律必須と結論づけられません。一方、年齢を問わず利用する設計なら、利用規約で不適切・違法な利用を禁止し、通報窓口を示し、児童の安全に関する重大な通報の取扱いを事前に決めてください。年齢制限、課金、出会い機能、画像・動画、位置情報を導入する場合は、別途の専門的な再評価が必要です。 -## 4. 利用者投稿、違法・権利侵害コンテンツ +## 6. OSSと運営サービスの責任分担 -v1 は、公開タイムラインや不特定多数向けの投稿サービスを前提にしていないため、大規模なプラットフォーム事業者向けの義務がそのまま発生する可能性は高くありません。ただし、これは違法・権利侵害コンテンツへの対応が不要という意味ではありません。実際に誰が受信できるか、部屋を公開できるか、サービス規模がどう変わるかで評価は変わります。 +MIT Licenseは著作権上の利用許諾であり、OSS配布者の説明を、導入者が自ら第三者向けサービスを運用する際の届出・データ保護・利用者対応の代わりにはできません。コードだけを提供し、開発者のサーバー、API、ログ基盤がメッセージを一切扱わない構成では、実際にサービスを提供するself-hosted運営者が、自らの構成を確認するのが基本です。 -開始時点で、少なくとも次を用意します。 +反対に、公式の共通API、リアルタイムリレー、DB、認証、ログ、モデレーション、障害監視を提供する場合、どの組織が通信とデータを取り扱うかが変わります。提供形態を変える前に、電気通信事業、通信の秘密、個人情報、外部送信、利用規約上の主体を見直してください。 -- 通報窓口と、削除・ブロック・停止の判断基準 -- なりすまし、嫌がらせ、脅迫、個人情報、著作権侵害、性的画像等の緊急エスカレーション -- 利用者からの削除要請・開示要請の受領方法 -- 重大事故時のログ保存と関係機関への相談手順 -- 招待URLの無断共有、連投、DoS、アカウント・端末の不正利用への制限 -- 未成年者の利用可否、保護者対応、禁止行為の方針 +## 7. 公開判定のための最終チェック -現行の「特定電気通信による情報の流通によって発生する権利侵害等への対処に関する法律」に基づく大規模事業者向け制度は、指定対象となる大規模事業者を中心としたものです。2〜数名の招待チャットが直ちにその指定対象になるとは考えにくいものの、公開範囲を広げる場合は再評価します。 +公開ボタンを押す前に、次の質問に文書で答えられる状態にします。 -- [特定電気通信による情報の流通によって発生する権利侵害等への対処に関する法律（e-Gov）](https://laws.e-gov.go.jp/law/413AC0000000137?occasion_date=20260625) +1. 誰が利用者にサービスを提供し、どの問い合わせ先を表示するか。 +2. 料金、広告、紹介料、スポンサーその他の収益意図があるか。 +3. 送信者・受信者・サーバー・外部インフラ・ログ・バックアップのフローはどうなっているか。 +4. 本文とメタデータを誰が、どの目的で、どの条件なら閲覧できるか。 +5. 何を何日保存し、削除表示はどのデータ範囲を指すか。 +6. 端末から誰のサーバーへ何が送られるか。第三者解析・広告SDKは本当に必要か。 +7. 通報、漏えい、障害、法的要請を誰がどの手順で受けるか。 +8. 届出・登録要否について、実際の構成と収益性を添えて総合通信局へ確認したか。 -## 5. v1 の対応優先度 +## 参考資料 -| 優先度 | 開始前に行うこと | -| --- | --- | -| 必須候補 | 総合通信局への事前確認、該当する場合の電気通信事業の届出 | -| 必須候補 | 運営者情報、問い合わせ先、プライバシー通知、利用規約、保存・削除方針 | -| 必須候補 | 通信の秘密を守る管理者権限、ログ、バックアップ、削除、事故対応 | -| 必須候補 | Cloudflare・ホスティング・監視・ログのデータフローと委託先の棚卸し | -| 強く推奨 | 通報、ブロック、招待URL失効、レート制限、緊急停止 | -| 強く推奨 | 第三者広告・解析タグなしで開始し、外部送信を最小化 | -| 強く推奨 | OSS利用者向けに、ホスティング運営者が法務・運用主体になることを説明 | -| 将来対応 | 有料化、広告、公開ルーム、検索、画像・動画・ファイル、海外展開、利用者数増加に伴う再評価 | -| 将来対応 | 年齢確認、本人確認、専門的なコンテンツモデレーション、商標登録 | - -## 6. 未解決事項 - -総合通信局または専門家へ相談する際は、次の回答を添えてください。 - -- 有料・無料、広告・寄付・サブスクリプションの有無 -- 想定利用者数、公開範囲、招待URLの発行者 -- 自前設備か、Cloudflare等のクラウド上のアプリか -- サーバー、データベース、ログ、バックアップの所在 -- メッセージ本文を誰がどの目的で閲覧できるか -- IPアドレス、Cookie、端末情報、アクセス解析の取得内容 -- 未成年者の利用を許可するか -- 利用者間の通信を誰に向けて媒介するか -- 一定期間後の削除が本文、ログ、バックアップのどこまで及ぶか - -## 7. 参考資料 - -- [電気通信事業法（e-Gov）](https://laws.e-gov.go.jp/law/359AC0000000086) -- [電気通信事業の届出（e-Gov）](https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00001) -- [電気通信事業参入マニュアル（総務省）](https://www.soumu.go.jp/main_content/000739290.pdf) -- [電気通信事業参入マニュアル［追補版］（総務省）](https://www.soumu.go.jp/main_content/000477428.pdf) -- [関係法令Q&Aハンドブック（政府サイバーセキュリティポータル）](https://security-portal.cyber.go.jp/guidance/law-handbook/v2-07.html) -- [個人情報保護法ガイドライン（個人情報保護委員会）](https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/) -- [個人情報保護法 FAQ（個人情報保護委員会）](https://www.ppc.go.jp/personalinfo/faq/APPI_QA/) -- [外部送信規律に関する総務省FAQ](https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu_00002.html) +[1]: https://www.soumu.go.jp/main_content/000799137.pdf "総務省『電気通信事業参入マニュアル（追補版）ガイドブック』" +[2]: https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu.html "総務省『外部送信規律について』" +[3]: https://laws.e-gov.go.jp/law/359AC0000000086/ "e-Gov法令検索『電気通信事業法』" +[4]: https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00001 "e-Gov電子申請『電気通信事業の届出』" +[5]: https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/ "個人情報保護委員会『個人情報の保護に関する法律についてのガイドライン（通則編）』" +[6]: https://www.ppc.go.jp/news/kaiseihou_feature/roueitouhoukoku_gimuka "個人情報保護委員会『漏えい等報告・本人への通知の義務化について』" +[7]: https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu_00002.html "総務省『外部送信規律FAQ』" +[8]: https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu_00002.html#faq "総務省『外部送信規律FAQ』第6節" diff --git a/docs/NAMING_REVIEW.md b/docs/NAMING_REVIEW.md index e01265f..1cfbe31 100644 --- a/docs/NAMING_REVIEW.md +++ b/docs/NAMING_REVIEW.md @@ -1,124 +1,92 @@ -# nanne ネーミングレビュー +# `nanne` ネーミングレビュー -調査日: 2026-08-16 +**調査日: 2026-08-18** -## この文書の位置づけ - -Issue #1 に基づく公開前の簡易ネーミング調査です。検索エンジン、GitHub、アプリストア検索、J-PlatPat、ドメインWHOISを組み合わせています。検索結果に現れなかったことは、商標・商号・サービス名の安全性を保証しません。公開・有料化・商標登録の前には、弁理士による先行商標調査を行ってください。 +> **位置づけ**：本書は公開情報による初期スクリーニングです。商標検索で見つからないことは、使用や登録の安全性を保証しません。名称を有料サービス、広告付きサービス、アプリ、海外提供、商標出願に用いる前には、対象国・対象区分・類似称呼を含む弁理士のクリアランス調査を行ってください。 ## 結論 -現時点では、名称を直ちに変更する必要があるとまでは判断しません。暫定的には、nanne をブランド名として残し、サービス説明を添えて nanne chat または nanne — temporary chat のように使う案を推奨します。 - -ただし、次の理由から「商標上安全」「完全に空いている」とは言えません。 - -- J-PlatPatで、ＮＡＮＮＥ／ナンネの登録商標が1件確認できた。 -- nanne.com は登録済みで、標準ドメインの取得候補にはできない。 -- GitHubには同名・類似のアカウントやリポジトリが複数ある。 -- 検索エンジンやアプリストアに、同名の著名チャットサービスは目立って確認できなかったが、検索結果は網羅的ではない。 -- 「なんね？」という日本語の由来は親しみやすい一方、海外利用者には意味が伝わらないため、説明語を付けた方が識別しやすい。 - -## 1. 商標調査 - -### J-PlatPatで確認できた登録 - -2026-08-16 に、J-PlatPatの商標検索で次の条件を指定しました。 - -- 商標（検索用）: nanne -- 称呼（単純文字列検索）: ナンネ -- 部分一致 - -確認できた結果は次の1件です。 - -| 項目 | 結果 | -| --- | --- | -| 商標 | ＮＡＮＮＥ | -| 登録番号 | 5483611 | -| 出願番号 | 商願2011-082203 | -| 称呼 | ナンネ | -| 区分 | 29、32 | -| 権利者表示 | 株式会社野口総合研究所 | -| 状態 | 存続-登録-継続 | -| 出願日 / 登録日 | 2011-11-01 / 2012-04-06 | - -検索結果上の区分は29、32で、nanneのソフトウェア・通信サービスと直ちに同一とは限りません。しかし、類似判断は文字だけでなく、指定商品・役務、取引実情、称呼・外観・観念を総合して行われます。区分が違うことだけで安全とは判断しません。 +現時点では、`nanne` を直ちに改名すべき強い衝突は確認できていません。ただし、`nanne` と同一の日本商標登録記録が少なくとも1件あり、`.com` はすでに登録済みです。また、短い単語で人名にも用いられるため、検索性・識別性・ドメイン確保の面で単独表記には限界があります。[1] [2] -今回の検索は、入力した文字列と称呼に対する再現可能な一次確認です。異字体、類似称呼、別区分、未登録表示、海外権利、会社名・ドメイン名までは網羅していません。 +**v1では、ブランドの核として `nanne` を残しつつ、画面表示・説明文・リポジトリ説明では `nanne — temporary chat` のような説明語を併記する**ことを勧めます。これは商標上の衝突を自動的に解消する方法ではなく、利用者の混同と検索ノイズを下げるための表示上の方針です。アプリ配信、有料化、広告導入、商標出願の前には、名称そのものを維持できるかを専門調査で決めてください。 -- [J-PlatPat 商標検索](https://www.j-platpat.inpit.go.jp/t0100) +| 評価項目 | 調査時点の結果 | 判断への影響 | +| --- | --- | --- | +| 日本の商標 | J-PlatPatで登録番号5483611／出願番号2011-082203の記録を確認した。 | **要追加調査**。類似商品・役務、現権利状態、類似称呼を含めた判定が必要。 | +| Webサービス・チャットの著名な同名 | 公開Web検索では、`nanne` を主名称とする著名な日本語チャットサービスの強い衝突は確認できなかった。 | 積極的な衝突兆候は低いが、網羅的な調査ではない。 | +| GitHub | `yo4e/nanne` のほか、同名の古いリポジトリが複数ある。`nanne chat` のリポジトリ検索では上位結果に明確な競合はなかった。 | OSS名の一意性はない。説明語・組織名・READMEの明確化が必要。 | +| App Store・Google Play | この調査では、同名の著名なチャットアプリを確証をもって特定できなかった。 | **未確定**。ストア申請・公開直前に各ストアで再検索する。 | +| ドメイン | `nanne.com` はRDAP上で登録済み。 | `.com` の取得を前提にブランドを設計しない。別の公式ドメインとSNSハンドルを先に確保する。 | +| 海外商標 | 本書では国際データベースを含む完全な調査を実施していない。 | 海外提供前にWIPO Global Brand Databaseおよび対象国の公式DBで調査する。 | -### 追加で行うべき確認 +## 1. 調査方法と限界 -公開前、特に有料化・広告・商標登録を行う前に、少なくとも次を専門家または追加検索で確認します。 +特許庁は、J-PlatPatの「称呼（類似検索）」で読み方が類似する可能性のある商標を広く確認し、「商標（検索用）」で同じ文字を含む商標を確認する方法を案内しています。検索項目・キーワードを変えること、情報反映に時差があり得ることも明示されています。[1] -- ソフトウェア、ダウンロードアプリ、通信、SaaSに関係する区分 -- nanne、ＮＡＮＮＥ、ナンネ、および外観・称呼が近い名称 -- 既存の商号、サービス名、アプリ名、ドメイン、SNSアカウント -- 日本以外で提供する場合の各国商標 -- nanne chat のように説明語を加えた場合の識別力と先行権利 +今回、J-PlatPatの簡易検索で登録番号 **5483611** を照会し、商標出願 **2011-082203** と商標公報 **5483611** の対応を確認しました。[2] ただし、簡易検索は詳細検索の代替ではありません。また、ブラウザのセッションに依存する詳細画面から、今回の調査時点で指定区分、権利者、現存続状態を再取得・再確認することはできませんでした。既存の資料にあった区分・権利者・状態は、**この改訂版では再検証済みの事実として扱いません**。 -## 2. サービス名・アプリ・GitHubの確認 +この調査は、`nanne`、`Nanne`、`NANNE`、`ナンネ` を中心にした公開Web・GitHub・公式DBの初期確認です。類似称呼、異表記、図形、指定商品・役務、未登録周知表示、商号、不正競争、各国権利、将来の出願は網羅していません。 -### 著名な同名サービス +## 2. 日本の商標 -検索エンジンで nanne / Nanne と chat、messaging、SaaS、アプリを組み合わせて確認した範囲では、nanneという名称の著名な同名チャットサービスやSaaSは確認できませんでした。アプリストア検索でも、同名の著名チャットアプリは目立って確認できませんでした。 +同一又は類似する文字列が他の区分に登録されているだけで、`nanne` のソフトウェア・通信サービスへの使用が直ちに禁止されるとはいえません。一方、文字・称呼・観念、指定商品・役務、取引実情を踏まえた類似判断が必要であり、区分が異なることだけを根拠に安全と結論づけるべきでもありません。 -一方、Nanneは人名としても使われ、無関係なアプリ開発者名・プロフィール名などが検索結果に出ます。これらは直ちにサービス名の衝突を意味しませんが、検索性とSEOではノイズになります。 - -### GitHub - -GitHubのリポジトリ検索では、nanneという名前のリポジトリやユーザーが複数確認できました。nanne chat の検索では、現時点では yo4e/nanne が主な該当結果でした。 - -- [GitHub: nanne リポジトリ検索](https://github.com/search?q=nanne&type=repositories) -- [GitHub: nanne chat リポジトリ検索](https://github.com/search?q=nanne+chat&type=repositories) - -これはGitHub上で名前が唯一であることを意味しません。README、パッケージ名、SNSの表示名、検索用の説明語に chat / temporary / invite-only などを添えると、混同と検索ノイズを下げられます。 - -## 3. ドメイン・SNS - -### ドメイン - -nanne.com はWHOIS確認時点で登録済みでした。したがって、nanne.comを取得できる前提でブランドを設計しないでください。 +| 公開前に確認する検索軸 | 具体的な対象 | +| --- | --- | +| 表記 | `nanne`、`Nanne`、`NANNE`、全角表記、`ナンネ`、`なんね`。 | +| 称呼 | 「ナンネ」を含む称呼、近接する音、長音・促音・濁音等の揺れ。 | +| 商品・役務 | ソフトウェア、ダウンロード可能なアプリ、通信・メッセージング、SaaS、Web提供、周辺的な情報サービス。 | +| 権利状態 | 登録・出願・拒絶・放棄・更新等の現状態と、権利者の事業内容。 | +| 周知性 | 登録の有無と別に、先行するサービス名・商号・ドメイン・SNSの使用実態。 | -- [WHOIS: nanne.com](https://who.is/whois/nanne.com) +> **実務上の扱い**：J-PlatPat検索は一次情報に基づく重要な入口ですが、特許庁自身も検索条件を変えた確認を案内しています。名称の採用・出願を決める最終判断には、弁理士による類似群コード・指定役務を踏まえた調査を用いてください。[1] -nanne.jp、nanne.io、nanne.appなどの空き状況は、レジストラ、登録要件、プレミアム価格、取得時点により変動するため、この調査では確定判定していません。購入直前に公式レジストラで確認し、利用規約・商標・なりすましリスクも合わせて確認します。 +## 3. Webサービス・アプリ・GitHub -### SNS +公開Web検索では、`nanne` の語が人名・プロフィール名などとしても使われるため、検索結果にノイズがあります。この調査時点で、日本で広く知られた同名のチャット・メッセージングサービスとの明確な衝突は確認できませんでした。しかし、検索結果に現れないサービス、地域限定のサービス、アプリストアの表示名、未公開プロダクトがあり得るため、「見つからない」ことを安全宣言には使えません。 -主要検索エンジンで nanne と chat / app を組み合わせて確認した範囲では、同名の著名チャットブランドは確認できませんでした。ただし、SNSのアカウント取得状況や非公開アカウントは検索結果だけでは判定できません。公開前に、公式アカウント名、プロフィール、短縮URL、なりすまし通報先を確保してください。 +GitHubのリポジトリ検索では、`yo4e/nanne` のほか、`nanneii/nanne`、`NooNanneii/nanne`、`nanneonlinegh/Nanne` という完全同名のリポジトリが確認されました。これらはGitHub上の名前の重複であり、商標権の有無やチャット領域での競合を示すものではありませんが、検索結果での混同を避ける必要があります。[3] -## 4. 推奨判断 +| 使う場所 | 推奨表記 | +| --- | --- | +| ブランド名 | `nanne` | +| サービスの見出し | `nanne — temporary chat` | +| GitHub説明 | `nanne: a tiny temporary chat tool` | +| 日本語説明 | `nanne（なんね？から始まる一時チャット）` | +| パッケージ・アプリ名 | 先行調査と登録可能性を確認してから決定する。 | -### 現時点の案 +App StoreとGoogle Playの検索は、ストアの地域・時点・検索アルゴリズムで結果が変わります。モバイル配信を行わないv1では、名称審査をこの段階で完結させる必要はありません。アプリ化またはストア申請の直前に、提供予定国ごとに `nanne`、`Nanne`、`ナンネ`、`nanne chat` を再検索し、開発者名も含めて確認してください。 -1. v1では nanne を残し、nanne chat のような説明語を付ける。 -2. ロゴ、ドメイン、SNS、アプリ表示では、単独のnanneだけに依存せず、一時チャット・招待制・テキストのみ等の説明を併記する。 -3. 有料化、広告、一般公開、アプリストア申請、商標出願の前に、弁理士へ区分を指定した先行商標調査を依頼する。 -4. nanne.comを前提にせず、取得可能なドメインとSNSハンドルを先に確認する。 -5. 既存のＮＡＮＮＥ登録商標との関係について、指定区分が異なることを根拠に自己判断で安全宣言しない。 +## 4. ドメイン・SNS -### 改名を検討する条件 +VerisignのRDAP記録では、`NANNE.COM` は登録済みで、2026-08-18時点のレコードには有効期限が2026-12-10と記載されています。[4] これはドメインの登録状況に関する参考情報であり、登録者との関係、実際のサービス内容、商標上の関係を示すものではありません。 -次のいずれかが見つかった場合は、nanneを維持するより改名を優先します。 +`.jp`、`.io`、`.app`その他の候補は、登録要件・価格・プレミアム設定・取得可否が変動します。取得可能であること自体は商標上の使用可能性を保証しません。公開時に使う**1つの公式ドメイン**、主要SNSの公式ハンドル、なりすまし報告の窓口を決め、利用規約・プライバシー通知・READMEで一貫して表示してください。 -- ソフトウェア・通信・SaaSに近い区分で同一または強く類似する商標がある -- 同名のチャット・コミュニケーションサービスが日本または提供予定地域で営業している -- 公式ドメインやSNSハンドルを確保できず、なりすまし・誤認のリスクが高い -- 海外利用者向けに、発音・意味・検索性の説明コストがブランド上の利点を上回る +| 時点 | ドメイン・SNSで行うこと | +| --- | --- | +| v1公開前 | 公式ドメインと主要SNSハンドルを確保し、公式URLを固定する。 | +| 有料化・広告開始前 | 検索結果、類似ドメイン、なりすまし、公式表記を再調査する。 | +| 海外公開前 | 対象国の商標DB、WIPO Global Brand Database、現地のドメイン・アプリストアを調査する。 | -## 5. 未解決事項 +## 5. 推奨判断 -- J-PlatPatでの類似称呼・関連区分を含む専門的なクリアランス -- nanne を商標登録する場合の適切な区分 -- nanne.jp / nanne.io / nanne.app等の取得可否と価格 -- GitHub、X、Instagram、Bluesky、Discord等の公式ハンドル -- 海外公開時の同名サービス・商標 -- 「なんね？」を正式なブランド由来として説明するか +現段階の判断は、**「`nanne` をv1のブランドとして維持し、説明語を併記する。ただし、収益化・アプリ化・海外展開・商標出願の前に専門的な先行調査を完了する」**です。 -## 6. 参考資料 +この判断は、`nanne` に一切の衝突がないという意味ではありません。日本の同一登録記録と、`.com` が利用できない事実により、単独語を長期的な独占ブランドとして扱うには不確実性があります。一方で、今回の公開調査では、直ちに改名を要するほど明確な国内チャットサービスの衝突は確認できませんでした。 -- [J-PlatPat 商標検索](https://www.j-platpat.inpit.go.jp/t0100) -- [GitHub: nanne リポジトリ検索](https://github.com/search?q=nanne&type=repositories) -- [GitHub: nanne chat リポジトリ検索](https://github.com/search?q=nanne+chat&type=repositories) -- [WHOIS: nanne.com](https://who.is/whois/nanne.com) +| 状況 | 推奨アクション | +| --- | --- | +| 無料・小規模なWeb版v1 | `nanne` を維持し、説明語を併記する。公式ドメインと問い合わせ先を確保する。 | +| 有料化・広告・スポンサー | 弁理士に、実際の役務と対象区分を指定した先行調査を依頼する。 | +| アプリストア公開 | ストア検索と審査ポリシーを国別に確認し、開発者名・アイコン・説明文の混同も避ける。 | +| 海外提供 | WIPOおよび対象国の公式DBを使い、現地の商標専門家を含めて再評価する。 | +| 近い区分の強い先行商標・同名通信サービスが見つかった場合 | `nanne` 単独利用を停止し、改名または専門家の意見に基づく対応を優先する。 | + +## 参考資料 + +[1]: https://www.jpo.go.jp/support/startup/shohyo_search.html "特許庁『商標を検索してみましょう』" +[2]: https://www.j-platpat.inpit.go.jp/ "J-PlatPat（登録番号5483611／出願番号2011-082203を簡易検索で照会）" +[3]: https://github.com/search?q=nanne&type=repositories "GitHub リポジトリ検索: nanne" +[4]: https://rdap.verisign.com/com/v1/domain/nanne.com "Verisign RDAP: NANNE.COM" +[5]: https://branddb.wipo.int/ "WIPO Global Brand Database" From d8be7113ab2b1cdab7208181c12dbac25df2c0d9 Mon Sep 17 00:00:00 2001 From: yo4e <5.9075346e+07+yo4e@users.noreply.github.com> Date: Tue, 18 Aug 2026 08:40:32 +0000 Subject: [PATCH 2/2] docs: add telecom filing schedule --- README.md | 1 + docs/TELECOM_FILING_SCHEDULE.md | 156 ++++++++++++++++++++++++++++++++ 2 files changed, 157 insertions(+) create mode 100644 docs/TELECOM_FILING_SCHEDULE.md diff --git a/README.md b/README.md index a64d874..ef89716 100644 --- a/README.md +++ b/README.md @@ -129,6 +129,7 @@ URLを相手に渡す - [公開前法務・運用レビュー](./docs/LEGAL_REVIEW.md) - [ネーミングレビュー](./docs/NAMING_REVIEW.md) - [埋め込み提供形態の法務レビュー](./docs/EMBEDDING_LEGAL_REVIEW.md) +- [電気通信事業の届出条件・公開スケジュール](./docs/TELECOM_FILING_SCHEDULE.md) 法令や手続は変更されることがあります。実際の公開時には必ず最新の総務省・e-Gov情報を確認し、迷う場合は管轄の総合通信局等へ相談してください。 diff --git a/docs/TELECOM_FILING_SCHEDULE.md b/docs/TELECOM_FILING_SCHEDULE.md new file mode 100644 index 0000000..bb54062 --- /dev/null +++ b/docs/TELECOM_FILING_SCHEDULE.md @@ -0,0 +1,156 @@ +# `nanne`：電気通信事業法の届出条件と開発スケジュールへの影響 + +**作成日: 2026-08-18** + +> **法務上の注意**：これは公開一次情報に基づく実務用の整理であり、法的助言ではありません。実際の公開前には、収益性、構成図、データフローおよび運営主体を示して、管轄の総合通信局に届出・登録の要否を確認してください。 + +## エグゼクティブサマリー + +`nanne` の「招待URLで参加者を特定し、利用者同士がテキストを送受信する」機能は、総務省が例示するダイレクトメッセージや参加者限定のWeb会議に近く、**他人の通信の媒介**に当たり得ます。[1] + +ただし、メッセージ機能を実装した時点で直ちに届出が確定するわけではありません。総務省ガイドブックの整理では、次の4条件を満たして初めて「電気通信事業を営む者」に該当します。特に、**料金・広告等を通じて利益を得ようとするか**が、`nanne` の公開計画を分ける最初の判断点です。[1] + +| 条件 | 公式ガイドの意味 | `nanne` v1での確認点 | +| --- | --- | --- | +| 他人のための提供 | 自己利用ではなく、他人の需要に応じて役務を提供する。 | 第三者が招待URLで参加できる公式サービスか。 | +| 利益を得ようとすること | 料金を取る場合だけでなく、無料でも広告収入を得る場合を含む。無償・原価ベースは該当しないと説明されている。 | 利用料、広告、紹介料、スポンサー、寄付の扱いを公開前に固定する。 | +| 電気通信設備の利用 | 自己所有に限らず、利用権限を持つサーバー等を含む。 | アプリ、クラウド、DB、WebSocket、CDN/WAF、ログ基盤の構成。 | +| 反復継続 | 緊急・臨時の提供ではなく、主体的・継続的な提供。 | 継続公開、利用規約、サポート、障害対応、運営体制があるか。 | + +## 1. 届出が必要になる具体的な条件 + +### 1.1 `nanne` に当てはめた判断 + +下表は、現在の想定を前提にした実務上の判断表です。ここでいう「届出が必要」は、登録対象ではないことを前提にした法16条の届出を指します。自ら設置する電気通信回線設備の規模・区域が所定基準を超える場合等は、届出ではなく**登録**が必要になり得ます。[2] + +| 運用パターン | 届出・登録の見込み | 理由と次の行動 | +| --- | --- | --- | +| 開発環境、社内検証、自己利用 | 通常は低い。 | 他人の需要への反復継続提供に当たらない可能性が高い。ただし公開用インフラ・広告・一般利用を開始する前に再判定する。 | +| 無料、広告なし、原価回収を超える利益を意図しない招待制ベータ | 必要性は低い可能性があるが、事実確認が必要。 | 総務省ガイドブックは無償・原価ベースを「利益を得ようとする」に当たらないと説明する。収益化の予定、運営目的、構成を記録し、管轄局へ照会する。 | +| 有料の招待制チャット | **届出または登録が必要となる可能性が高い。** | 他人の通信を媒介し、利益を得る意図を伴う継続サービスだからである。開始前に登録・届出を確定する。 | +| 無料だが広告収入があるチャット | **届出または登録が必要となる可能性が高い。** | 総務省は、無料サービスでも広告収入で利益を得ようとする場合を届出が必要となる例として示す。[1] | +| OSSコードだけを配布し、開発者のサーバーやAPIが通信を通さない | コード配布者自身の届出は通常不要と考えられる。 | 実際に利用者間チャットを提供するself-hosted運営者が、自らの運用について確認する。 | +| 共通の公式API、リアルタイムリレー、DB、ログ、モデレーションを提供 | 公式運営者について届出・登録の検討が必要。 | 誰が通信・データを扱うかで、OSS配布者ではなくサービス提供者として評価する。 | + +**小規模・招待制・Cloudflare利用は、単独の免除条件ではありません。** 招待された少人数がいることは「専ら一者への提供」と同義ではなく、クラウド利用も通信媒介の検討をなくしません。[1] [2] + +### 1.2 届出か登録か + +法9条は原則として登録を求めますが、設置する電気通信回線設備の規模・区域が省令基準を超えない場合等は登録対象から除かれます。登録対象ではない電気通信事業を営む者は、法16条により届出を行います。[2] + +`nanne` のようなWebアプリについて、クラウド・CDNを利用しているだけで登録か届出かが自動的に決まるわけではありません。相談時には、事業者自身が何を設置・利用・管理しているか、特に伝送路・交換設備に該当し得る設備の有無を、構成図で説明してください。通常の小規模Webチャットでは、登録より届出の可能性を先に確認する設計が現実的ですが、これは構成確定後に管轄局が判断する事項です。 + +### 1.3 届出のタイミングと内容 + +e-Govの案内では、法16条の届出は**事業開始前**に提出し、手数料はありません。個人・法人の別と電気通信回線設備の設置の有無で様式が分かれ、回線設備を設置する者には別途の自己確認届出等が必要となる旨が案内されています。[3] + +| 届出前に確定する事項 | 開発上の意味 | +| --- | --- | +| 運営者の氏名・名称、住所、問い合わせ先 | 個人事業・法人化、問い合わせ用メール、規約の名義を先に決める。 | +| 業務区域 | 日本向けか、海外利用をどう扱うかを明確にする。 | +| 電気通信設備の概要（該当する場合） | 本番アーキテクチャ、クラウド、リアルタイム接続、ネットワーク構成を固定する。 | +| 収益モデル | 有料、広告、スポンサー、寄付の扱いを、公開後に曖昧なまま変更しない。 | +| データフロー | 本文、IPアドレス、Cookie、ログ、バックアップ、監視の保存先と権限を確定する。 | + +## 2. 開発計画にどう影響するか + +届出の有無は、チャットUIの実装そのものを止める要因ではありません。一方で、**公式サービスを公開する前**に収益モデル・運営主体・本番構成を確定しなければ、行政相談、届出書、プライバシー通知、利用規約、ログ設計を確定できません。したがって、開発計画では「機能開発」と「公開可否判定」を分離し、後者をリリースゲートとして扱うべきです。 + +### 2.1 先に凍結すべき5つの意思決定 + +| 意思決定 | なぜ先に必要か | 推奨期限 | +| --- | --- | --- | +| v1の収益性 | 無料・原価ベースか、広告・課金等を含むかで届出判断が大きく変わる。 | 実装開始時、遅くとも公開6週間前。 | +| 運営主体 | 誰が届出・規約・問い合わせ・データ保護を担うかを決める。 | 公開6週間前。 | +| 本番アーキテクチャ | 設備概要、委託先、データフロー、海外処理を説明する前提になる。 | 公開5週間前。 | +| データ保持・管理者アクセス | 通信の秘密、プライバシー通知、バックアップ、通報対応の設計前提になる。 | 公開4週間前。 | +| 外部サービス | CDN/WAF、分析、エラー監視、メール、課金を導入すると送信データと説明が変わる。 | 公開4週間前。 | + +### 2.2 実装と並行できること + +以下は、届出要否の回答を待たずに着手できます。むしろ先に実装しておくと、届出が必要になった場合にも公開準備の手戻りを抑えられます。 + +| 領域 | v1で実装・決定すること | 法務・運用上の効果 | +| --- | --- | --- | +| 招待URL | 十分に推測困難なトークン、失効、再発行、利用回数または期限の制御。 | URL流出時の被害範囲を限定する。 | +| 本文アクセス | 通常運用では本文を読まない。例外閲覧は目的・承認・記録を必須にする。 | 通信の秘密に配慮した最小権限設計になる。 | +| ログ | 本文をログ・監視イベントへ送らず、IPや識別子も必要最小限・短期間にする。 | 個人情報・漏えい・外部送信のリスクを下げる。 | +| 削除 | 本文、ルーム情報、ログ、バックアップを分けて保持期間と削除処理を定義する。 | 「一定期間後に消える」の説明を正確にできる。 | +| 通報・停止 | 通報受付、ルーム停止、URL失効、証跡保全、緊急連絡を用意する。 | 違法・権利侵害・不正利用への初動を可能にする。 | +| 外部SDK | 広告、第三者解析、不要な監視SDKはv1から除外する。 | 外部送信・委託先の説明と同意設計を最小化する。 | + +### 2.3 リリースを止めるべき変更 + +次の変更は、単なる機能追加としてリリースせず、電気通信事業の該当性・届出事項・プライバシー通知を再確認するゲートを設けてください。[2] + +| 変更 | 再評価する理由 | +| --- | --- | +| 有料化、広告、スポンサー導入 | 「利益を得ようとする」要件と届出判断に直接影響する。 | +| 公開ルーム、検索、タイムライン | 通信の宛先・公開範囲・違法情報対応の前提が変わる。 | +| 共通API、リレー、認証、DBの提供 | OSS配布者とサービス提供者の役割分担が変わる。 | +| 画像、動画、ファイル、音声・映像 | 保存データ、権利侵害、違法コンテンツ、セキュリティの影響が増える。 | +| 海外向け提供、海外インフラ追加 | 業務区域、外国第三者、越境データ、利用規約の前提が変わる。 | +| 分析・広告・外部SDK導入 | 利用者情報の外部送信と通知・公表等の検討が必要になる。[4] | + +## 3. 推奨スケジュール + +ここでは、**本日をWeek 0として、最短で6週間の公開準備枠を確保する**案を示します。これは行政の法定審査期間を保証するものではなく、事実整理、管轄局への相談、必要な届出、文書・運用・技術の整合を確保するためのプロジェクト上のバッファです。 + +### 3.1 収益化を伴う公式サービスの場合 + +| 時期 | 法務・行政 | 開発・運用 | リリース判定 | +| --- | --- | --- | --- | +| Week 0 | 収益モデルと運営主体を決定する。 | v1の機能凍結案、データ項目一覧を作る。 | **課金・広告の有無を確定する。** | +| Week 1 | 構成図、通信フロー、設備・委託先一覧、保存期間表を作る。管轄局への相談資料を準備する。 | 招待URL、本文非記録ログ、削除ジョブ、管理者権限を実装する。 | 相談資料が1枚で説明できるか確認する。 | +| Week 2 | 管轄の総合通信局へ、届出か登録か、回線設備の自己確認の要否を相談する。 | 本番候補環境でデータフローを検証する。 | 公式回答・案内に従い、手続ルートを確定する。 | +| Week 3 | 届出対象なら届出書を完成し、開始前に提出する。追加書類・自己確認の要否を確認する。 | 規約、プライバシー通知、削除方針、通報手順、漏えい対応手順を完成する。 | **届出が必要なら、提出完了が公開の前提。** | +| Week 4 | 変更時・廃止時の責任者と手順を決める。 | レート制限、障害対応、権限監査、バックアップ削除をテストする。 | 本番構成が届出・通知内容と一致するか確認する。 | +| Week 5 | 問い合わせ導線と記録を確認する。 | 少人数のクローズドベータを行い、ログ・削除・通報を運用テストする。 | 収益性・構成・外部SDKの変更がないことを確認する。 | +| Week 6 | 公開前の最終確認を行う。 | 本番公開、初週の監視と問い合わせ当番を開始する。 | 公開する。 | + +この経路では、**Week 2までに行政相談、Week 3までに必要な届出の提出**を完了させる設計です。行政から追加確認が来た場合に備え、公開日はWeek 6以降に固定し、届出提出日より前には一般公開・課金・広告開始をしないでください。 + +### 3.2 無料・広告なし・原価ベースのベータの場合 + +無償・原価ベースで利益を得る意図がないと明確に設計・運用できるなら、総務省ガイドブックの「営む」要件を満たさない可能性があります。[1] ただし、実際に届出不要と決め打ちするのではなく、Week 1〜2の相談・確認は維持してください。ここで短縮できるのは届出書の作成・提出工程であり、通信の秘密、個人情報、外部送信、削除、通報といった開発タスクではありません。 + +| 時期 | 実施内容 | +| --- | --- | +| Week 0 | 無料・広告なしの方針と、将来の収益化は公開前に再判定するルールを決定する。 | +| Week 1 | 構成図、データフロー、保存・削除、運営主体を整理し、管轄局へ確認する。 | +| Week 2〜3 | チャット、招待URL、削除、ログ最小化、通報・停止、規約・通知を実装する。 | +| Week 4 | クローズドベータで、削除、アクセス権限、障害・通報手順を検証する。 | +| Week 5 | 管轄局への確認結果と本番構成の一致を最終確認し、公開する。 | + +無料ベータから広告・課金へ移る日は、単なる機能リリースではなく、**届出要否を再判断する別プロジェクトの開始日**として扱うべきです。 + +## 4. 公開可否のゲート + +公開予定日の2週間前に、次のゲートを設けてください。1つでも未決なら、機能を削ってでも公開を遅らせるか、限定ベータに留めます。 + +| ゲート | 合格条件 | +| --- | --- | +| 収益性 | 料金・広告・その他収入の有無が文書化され、公開後に変わらない。 | +| 行政手続 | 管轄局に相談済みで、必要な登録・届出・自己確認の手続が開始前に完了している。 | +| 本番構成 | 構成図と実環境が一致し、委託先・リージョン・権限が説明できる。 | +| 通信の秘密 | 本文への通常アクセスがなく、例外閲覧に承認・記録・期間制限がある。 | +| データ通知 | プライバシー通知に取得項目、目的、外部送信、保存・削除、問い合わせ先がある。 | +| 運用 | 招待URL失効、通報、ルーム停止、漏えい、障害、法的要請の担当と手順がある。 | +| 変更管理 | 課金・広告・外部SDK・公開機能の追加時に再評価する責任者が決まっている。 | + +## 5. 今すぐ決めるべき結論 + +開発を止めずに進めるため、次の順で決めるのが合理的です。 + +1. **v1は無料・広告なし・外部解析なしで出すか、有料・広告付きで出すかを決める。** 後者なら届出・登録を要する前提でWeek 1の相談に進む。 +2. **公式版の運営主体を決める。** 個人・法人、問い合わせ先、クラウド契約主体、利用規約の名義を統一する。 +3. **本番構成を凍結する。** CDN/WAF、アプリ、リアルタイム接続、DB、バックアップ、監視を一枚の図にする。 +4. **通信本文を読まない運用を標準にする。** 管理者アクセスは、通報・障害・法的要請に限定し、記録を残す。 +5. **公開日を、行政相談・必要な届出・運用テストの後に置く。** 届出要否が未確定のまま、課金や広告を伴う一般公開はしない。 + +## 参考資料 + +[1]: https://www.soumu.go.jp/main_content/000799137.pdf "総務省『電気通信事業参入マニュアル（追補版）ガイドブック』" +[2]: https://laws.e-gov.go.jp/law/359AC0000000086/ "e-Gov法令検索『電気通信事業法』" +[3]: https://shinsei.e-gov.go.jp/recept/procedure/lists/procedureInformation?gtaTetCd=145181GA00001 "e-Gov電子申請『電気通信事業の届出』" +[4]: https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu.html "総務省『外部送信規律について』"