利用規約とプライバシーポリシー、作って終わりで大丈夫？運用の勘所

「利用規約とプライバシーポリシー、リリースの時に作ったまま3年間触っていない」。エンジニア出身の創業者が、テンプレートを参考に自作した規約をそのまま使い続けている――Webサービスではよくある構図です。3年の間に機能は拡張され、扱うデータの種類は増え、Slack・Notion・Stripeといった海外ベンダーのSaaSも業務に入り込む。それでもCookieバナーは入れていない、漏えい時の社内対応フローも未整備。

この状態で必要なのは、一度きりの作り直しではありません。運用フェーズに合わせて作り直し続ける体制をどう作るか――考えるべきはそちらです。

利用規約とプライバシーポリシーは、契約書と違って一度交わして終わりではないです。Webサービスは生き物で、機能追加・法改正・トラブル対応のたびに、規約を更新し続ける必要がある。「テンプレートをダウンロードして社名を埋める作り方」だけで止まっている会社が多いのですが、それだとリリースした瞬間から実態と書面の乖離が始まります。

私はもともとシステムエンジニアを9年やってから自分で2社を経営してきました。プロダクトの運用フェーズに入った時、法務面が後追いで追いつかなくなる感覚は、自分でも何度か味わいました。この記事では、利用規約の作り方とプライバシーポリシー作成について、「運用しながら更新する」発想を主軸に書いていきます。テンプレ配布や条項解説は他サイトに豊富にあるので、そこは深追いしません。代わりに、Webサービス運営者が陥りやすい3つのズレと、その対応を中心に整理します。

「作って終わり」が一番危ない――運用と乖離する3つの場面

3年放置した規約に典型的な3つのズレを、最初に書きます。多くのWebサービス運営者が同じところで詰まっている、という実感があります。

ズレ①　機能追加にプライバシーポリシーが追いつかない

リリース時のプライバシーポリシー（以下PP）は「お客様の氏名・メールアドレス・会社名を取得します」程度の記載だったのに、3年分の機能追加で、実際に取得しているデータは決済情報、ログイン履歴、操作ログ、外部サービス連携先のID（Google Workspace連携など）にまで広がっている。PPの記載と実態が乖離していく、典型のパターンです。

これは、利用目的の通知・公表（個人情報保護法第21条）や保有個人データに関する公表事項（同第32条）の問題になります。利用目的を本人に示さないまま個人情報を取得すると、個情法違反として個人情報保護委員会から指導を受けるリスクがあります。Webサービスの場合、機能追加のたびに「これで取得するデータは何か」を確認して、PPに反映する運用が必要です。

ズレ②　個情法改正にPPが対応していない

2022年4月に全面施行された個情法改正で、漏えい等報告義務、越境移転規制の強化、仮名加工情報・個人関連情報の整備など、いくつかの大きな変更がありました。それより前に作ったPPは改正前の建付けのままのことが多く、特に越境移転規制への対応が抜けがちです。

Slack（米国）、Notion（米国）、Stripe（米国）、AWS（東京リージョンでも運営主体は米国）――こうした海外ベンダーを業務で使っていれば、お客様の個人情報が外国事業者に渡り得る構造です。この場合、本人の同意を取るときに「移転先の外国の名称」「その国の個人情報保護制度」「移転先が講ずる保護措置」の概要を情報提供する必要があるんですが、ここが丸ごと抜けているPPをよく見かけます。

ズレ③　電気通信事業法の外部送信規律対応漏れ

2023年6月16日に施行された外部送信規律。Webサービスでは、Cookie等を通じて利用者の情報を外部の事業者（GoogleアナリティクスやMetaピクセル（旧Facebookピクセル）、広告事業者のタグなど）に送信することが多いんですが、この外部送信について通知・公表が義務付けられました。Cookieバナーも、外部送信に関する通知ページもない、というサービスがまだまだ残っています。

この規律は中小Webサービスでもまだ対応していない事業者が多いところです。私の事務所でご相談を受けると、「外部送信規律って何ですか？」と返されることがしばしばあって、知られていない法令だと感じます。

3つのズレに共通するのは、規約とPPを「作って終わり」だと思っていたこと。Webサービスを運営する以上、規約は生き物で、運用フェーズで何度も更新するのが前提です。進め方は二段構えが現実的です。まず今あるズレを埋める作業を集中してやり切る。その後は、四半期ごとに規約レビューを回す体制を作る。

利用規約は「変更するときの作り」が肝――改定条項を最初に決める

利用規約をゼロから作る時、一番考えるべきは「変更する時にどう動かすか」だと私は思っています。条項の中身を網羅することより、改定の仕組みを最初から組み込んでおくほうが、運用が始まってから圧倒的に効きます。

法的な根拠は、民法第548条の4（定型約款の変更）になります。要件を満たせばユーザー全員から個別同意を取り直さなくても規約を一方的に変更できる、というのがこの規定の効きどころで、Webサービス運営にとってはありがたい仕組みです。詳しくは別途調べていただきたいんですが、変更が利用者の一般の利益に適合するか、合理的なものなら、おおむねこの仕組みの中で動かせます。

ただ、こうやって書くと簡単に見えるんですが、実務では「どこまでが軽微な変更で、どこからが個別同意が要る変更か」の線引きで毎回頭を悩ませます。料金の値上げ、解約条件の不利な変更、個人情報の利用目的を新たに追加するような話は、合理性で押し切るには無理があって、個別同意を取り直すほうが現場では安全です。誤字修正や運用ルールの追加といった軽い話なら周知だけで足りる。このグラデーションの判断が、あとになって効いてきます。

それから規約に最初から入れておきたいのが、変更があり得ること、変更内容を周知する手段、効力発生までの予告期間、この3つに触れる文章。私の事務所では、軽微な変更で1〜2週間、重要な変更で1か月くらいの予告期間を取って動かす運用をご提案することが多いです。

機能追加と規約改定の同期は、エンジニア組織の中で運用ルール化しておくと回しやすくなります。私の定番は「機能追加のリリース2週間前に規約レビューミーティングを入れる」というシンプルなフロー。プロダクトマネージャーがリリース予定の機能を整理して、行政書士（または社内法務担当）と一緒に「この機能で取得するデータは規約とPPに反映が必要か」を確認する。リリース日を規約改定の効力発生日にそろえて運用する流れです。

これは、エンジニア時代に経験した「リリース後の運用は設計の3倍の手間がかかる」という肌感覚と、構造としては同じ話です。リリース時にきちんと法務側のチェックポイントを組み込んでおくと、後の運用がうんと楽になります。

プライバシーポリシーは「漏えい時に動けるか」で評価する

プライバシーポリシーの作成は、多くの記事で「個人情報保護法の通知・公表事項を記載しましょう」と説明されます。これは正しいんですが、書いて終わりにならない評価軸として、「漏えいが起きた時に、自社が動ける体制になっているか」をおすすめしています。

2022年の個情法改正で、漏えい等が起きた時の対応がかなり厳しくなりました。一定の事案では、個人情報保護委員会への速報をおおむね3〜5日以内、確報を30日以内（不正アクセスなど不正の目的が疑われる事案は60日以内）に出さないといけない（個情法第26条）。本人への通知も基本必要になります。「一定の事案」というのは、要配慮個人情報や不正アクセス絡み、被害が大きそうなケースが中心、というイメージで持っておけば概ね困らないかと。

漏えいに気づいた時から3〜5日のタイマーが回り始めるんですよ、これが本当にしんどい。事実確認、影響範囲の特定、本人への通知文の作成、委員会への報告書の作成、再発防止策まで一気に走らせる必要がある。PPに「漏えい時の対応窓口」が書かれていても、社内で動ける体制がなければ意味がない、というのが現場感覚です。

だからPPの整備とセットで、漏えい想定の社内フローを作っておきたい。漏えい第一報を受け付ける窓口（CTOと管理部長の2名体制など）、緊急対応チームの招集ルート、本人通知のテンプレート、委員会への報告書の雛形――これらを1つのドキュメントにまとめて社内に共有しておく。その上でPPに「漏えい等が発生した場合は、速やかに本人に通知し、個人情報保護委員会に報告します」と明記すれば、書面と体制がそろいます。

PPの作成でもうひとつ厄介なのが、海外SaaSとの絡みです。Slack、Notion、Stripe、AWS、こうした海外ベンダーを業務で使っていると、お客様の個人情報が外国の事業者に渡り得る構造になります。個情法第28条の越境移転規制がかかる場合、本人の同意を取るか、基準適合体制の整備（契約で相当措置を担保するなど）で対応するかの整理が要ります。同意ルートで行くなら、ズレ②で書いた3点（国名・制度・保護措置）を利用中のベンダーごとに整理して本人に情報提供した上で、サービス登録時の同意チェック画面まで含めて設計することになります。なお、契約上ベンダー側が中のデータを取り扱わない建付けのクラウドサービスは、そもそも「提供」に当たらないと整理される場合もあります。

業務委託先への個人情報提供は第三者提供ではなく「委託」扱いになる代わりに、委託先の監督義務（個情法第25条）が発生します。PPに「業務委託先には適切な監督を行います」と書くだけでなく、選定基準と監督の運用が社内にあるかが問われる。このあたりは、書いて終わりではなく実際に動かせる仕組みを持っているかが、いざという時の差になってきます。

Cookieとトラッキング――電気通信事業法の外部送信規律

2023年6月に施行された電気通信事業法の外部送信規律。Cookieやそれに類する仕組みでユーザー情報を外部の事業者（GAやMetaピクセル、広告タグなど）に送っている場合、その内容と送信先、利用目的を通知または公表してください、という話です。多くのWebサービス運営者がこの対象に入ります。対応がまだの中小Webサービスが本当に多いのは、ズレ③で書いた通りです。

通知の形式は法定されていなくて、CookieバナーでもOK、別ページに「外部送信について」と整理しておくのでもOK。BtoBの限定的なユーザーしかいないSaaSなら、わざわざ大げさなバナーを入れずに、PPからリンクで飛ばす独立ページを作るくらいで足りる場面が多いです。BtoCで広告タグをガンガン入れているサービスはCMP（同意管理プラットフォーム）を入れたほうが運用が楽になる。

違反したらいきなり罰金、というよりは、行政指導から段階的に動く流れだと思いますが、知らずに放置している状態は心地よくないです。最低限、自社のサービスでどんなタグやSDKを入れているかを棚卸ししておくところから始めるのをおすすめしています。

アプリ・SaaSで起きる固有問題

アプリを展開している場合は、Webサイト用の規約テンプレートだけでは足りない部分が出てきます。これも既存の解説記事ではあまり触れられていない領域なので、軽く書いておきます。

一番効いてくるのが、App Store／Google Play 自体の規約との整合性です。アプリストアの開発者ダッシュボードでは、アプリが取得するデータの種類や利用目的を申告する画面があって、ここで申告した内容と自社PPの内容がずれているとリジェクト対象になります。ストアの申告内容と自社PPを並べて突き合わせてみると、齟齬はわりと見つかるものです。どちらが実態に合っているかを確認して、PPと申告の両方をそろえる。

iOSのアプリでトラッキング系のSDK（広告SDK、Metaピクセルなど）を入れているなら、ATT（App Tracking Transparency）ダイアログの実装は必須。これも実装漏れでリジェクトされる定番の落とし穴です。広告SDKを使っているのに、ご自身でも気づかずATTを入れていないアプリ、結構多いです。

それから、サブスク決済を入れているアプリやSaaSなら、契約申込みの最終確認画面で、料金・自動更新の有無・解約方法を表示することは押さえておきたい。特定商取引法絡みの話で、ここを抜くと表示義務違反になります。13歳未満を想定するサービスを除外するなら、規約で「13歳未満は利用不可」と書いて登録時に年齢確認する運用が無難です。

退会後のデータ保持期間も、PPで触れておきたい論点。「退会から○年で削除」のように書いておかないと、後で「いつまで持っているのか」を聞かれて困ります。書き方の一例は「退会から3年経過後に個人情報を削除、ただし法令上の保管義務がある情報は法定期間保持」。法令上の保管義務（帳簿関連、消費者契約関連など）はサービスごとに違うので、自社の業種・取扱データに合わせて整理が要ります。

アプリ・SaaSの固有問題は、扱いだすとキリがないんですが、最低限「ストア規約と整合させる」「ATTを実装する」「サブスクの最終確認画面を整える」の3点を押さえれば、当座は致命傷を回避できます。

行政書士に頼む？自分で作る？――運用視点での判断

ここまで読んでいただいた方は、PP・規約は「作る」より「運用する」ほうが大変だ、と感じていただけたかと思います。専門家に頼むかどうかも、運用視点で判断するのが現場で合理的です。

自分で作るのが合理的なケース。取扱データが氏名・メールアドレス程度でシンプル、海外SaaSをほとんど使わない、個人開発でユーザー数が少ない、Webサービスの機能変更がほぼない静的なサイト、こういう場合は自力でテンプレートを参考に作って、年1回見直す運用で十分です。個人開発の家計簿アプリのような小さなサービスも、最初は自力＋シンプルなテンプレで動き始めて、ユーザー数が増えてきたタイミングで専門家にレビューをお願いする、という段階的なアプローチが現実的だと思います。

行政書士・弁護士に頼むほうが合理的なケース。個人情報を多く取り扱う（氏名・住所・電話番号・決済情報・ヘルスケア情報など）、海外SaaSを業務利用している、アプリストアに展開している、エンジニア組織が大きく機能改修が頻繁、サブスク決済を使っている、これらに当てはまる方は、PP・規約の整備を専門家に任せた方が結果的に時間とリスクを節約できます。

費用感を書いておきます。スポット作成で5〜15万円のレンジが標準。PP単独で5〜8万円、利用規約単独で5〜10万円、両方セットで10〜15万円くらい。これは私の事務所での感覚で、依頼者の事業内容と既存資料の有無で前後します。

継続サポートは月額1〜3万円で、四半期に1回の規約レビュー、機能追加時の規約改定支援、漏えい時の初動対応サポートを含むパッケージ。この記事の主軸である「運用しながら更新する」発想を実装するには、継続サポートのほうが向いています。

「作る時だけ依頼してあとは自社で運用」という選択も、もちろんアリです。ただ、社内に法務担当がいない中小Webサービスでは、四半期に1度くらいは外部の目を入れて規約レビューする方が、規約と実態が乖離していくリスクを下げられる、というのが私の意見になります。

おわりに――生き物として規約を扱う発想

ここまでの要点は「規約を生き物として扱う」に尽きます。最初に今あるズレを埋める作業をやり切り、あとは機能リリース2週間前の規約レビューと四半期レビューを回していく。作る作業より、この回し続ける仕組みのほうが本体です。

利用規約の作り方とプライバシーポリシーの作成は、テンプレートを使うかどうかより、「作って終わりにしない運用設計」を最初に組み込めるかどうかで結果が変わります。Webサービスが生き物である以上、機能追加や法改正のたびに規約も動く。その前提で組み立てておけば、ここまで書いてきた3つのズレには陥らずに済みます。

この記事が、規約の運用で悩んでおられるWebサービス事業者の方の、判断のヒントになれば嬉しく思います。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
利用規約・プライバシーポリシーの作成と運用、お話を聞かせてください。

「3年放置していた規約を見直したい」「機能追加のたびに法務面が追いつかない」「Cookieバナーや外部送信規律にどう対応すれば」「個人情報の漏えい時に動ける体制を作りたい」――こうしたご相談に、運用の継続サポートまで含めてお応えします。テンプレを使うかどうかではなく、サービスの成長に合わせて規約を動かし続ける仕組みを、ご一緒に設計させていただきます。スポット作成のご相談も、月額継続サポートも、両方の選択肢をご用意しています。

[利用規約・プライバシーポリシーの無料相談を予約する]
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝