メリークリスマス！本日はみなさんがユーザーとしてWebサービスにサインアップするとき読まされる利用規約のお話です。みなさん、利用規約ちゃんと読んでいますか？
さて、サービスがあふれる今日、利用しているすべてのサービスの利用規約に目を通せている方は正直少数派ではないでしょうか。利用規約はユーザーが読んでいようが読んでいまいが、強制的に同意を求め、サインアップしたが最後、そのサービスを利用しているすべてのユーザーが読んでいる前提になります。そんな読まれないのに読ませようとしてくる、面倒な存在の利用規約ですが、サービス提供する側となったときとても大事な存在になります。しっかり向き合い、味方にするとで、頼れる存在になってくれます。
本記事ではWebサービスを公開する場合に準備すべき利用規約を作るために考慮すべきことを考えてみます。また、すでにWebサービスを公開して運用していたりするけど、ちゃんと読んだことがないという方にとっても読み直すきっかけになれば幸いです。
※画像はイメージです
筆者と本記事について
本記事は筆者が法人向けのWebサービスを実際公開する際に、利用規約の作成・改定を通じて学んだことをもとに記載しています。実際に利用規約を完成させる場合は、本記事以外にも考慮すべきことが多くありす。その際には、専門家へ相談することをおすすめします。所属組織とは無関係の記事です。もし記事中に誤り、間違いなどあればコメントなどでご意見いただけると幸いです。
前提（想定読者）
事業としてWebサービスを立ち上げるときには、有料・無料を問わず開発するサービスごとに利用規約を作ることになるでしょう。読者の中にもこれから新規事業に携わり、自身のWebサービスを立ち上げようとされている方もいるかも知れません。そのような方が初めて利用規約を作る参考になればと思い、私が利用規約を作成するまであまり見えていなかった事を中心にご紹介します。
例えば、読者のあなたがQiitaのように記事を投稿できるプラットフォームサービスを開発しており、いまにもローンチしたいと考えているとします。どのような利用規約を用意すべきでしょうか。
（Qiitaにももちろん利用規約があります。）
Webサービス公開にあたり必要なドキュメント
そもそもですが、Webサービスを公開するにあたり必要なドキュメントを考えておきます。
書籍良いウェブサービスを支える「利用規約」の作り方によると、そもそもWebサービス公開時に3大ドキュメントとして、「利用規約」、「プライバシーポリシー」、**「特定商取引法に基づく表示」**の3つを準備について検討する必要があると述べられています。
本記事ではその中でも**「利用規約」**について言及します。他の「プライバシーポリシー」、「特定商取引法に基づく表示」もそれぞれ、個人情報を取り扱う場合、有料サービスとする場合は、重要なドキュメントとなるので、興味がある方は上述の書籍が体系的にまとまっています。ぜひ参考にしてみてください。
なぜ利用規約が必要になるのか
利用規約が無いとなぜ困るのか、利用規約の存在意義から考えてみます。
利用規約はWebサービスにおける全顧客共通の契約書
顧客にとってあなたのサービスが十分に機能的に魅力的だとします。
その場合、利用規約は、本格利用してもよいか判断するための情報になります。法人向けのサービスであれば、先方の法務部門も、問題がないことを確認するでしょう。疑問点があれば質問をしてくるでしょうし、場合によっては変更リクエストをする可能性もあるでしょう。
特にWebサービスのような形態のサービスにおいては、1アカウント（=1契約）ごとに個々の契約書を結ぶことは行わず、すべてのアカウントに同じ契約を締結することになります。原則は利用規約に記載されている情報をもとに契約を行うのです。
顧客の期待のギャップを埋めて、未来のトラブルに備える
利用規約はあなたのサービスに将来起こりうるトラブルへの備えとなります。特に有料契約のサービスの場合、顧客の期待とあなたが提供するレベルにギャップがあるかもしれません。
例えば、システム稼働率の問題などもそうでしょう。顧客は24時間365日絶対にダウンしないサービスを期待しているかもしれません。
その場合、予め利用規約でギャップを埋めておきましょう。少しでも、意図しないギャップの差から生じるクレームや訴訟の確率を下げておきましょう。
先に紹介した良いウェブサービスを支える「利用規約」の作り方には以下のように記載されています。
何か障害・トラブルが発生し、クレームになったときに、サポート対応担当者の"唯一の防具"となるのが利用規約なのです。
-- 良いウェブサービスを支える「利用規約」の作り方 P. 17
想定しうる全てのリスク対策をシステム的に解決するのは現実的では無い
また、すべてのトラブルへのリスク対策をシステム的に行うのは現実的でないと考えます。
例えば、よくある話ですが、あなたのサービスに投稿機能があり、投稿者自身が著作権を保持していないにも関わらず、投稿するケースを考えます。この場合、もしかすると著作権者にあなたのサービスが訴えられるかもしれません。あなたはできるなら問題となる記事を投稿を制限したいはずです。
この場合、著作権者の期待としては、そのようなコンテンツを通報したり、自動検出したりする仕組みが用意されている事かもしれません。しかし、このような機能は本質的ではないにも関わらず開発ボリュームは大きいでしょう。また、あなたのWebサービスはあなたが想像する以上に不完全で発展途上です。ビジネスとして成功することが約束されていない限り、すべての想定しうるリスクにシステム的な対策を取ることは現実的ではありません。リスクを想定できるけれど、システム的な対策を用意できていないことは、利用規約で禁止事項としましょう。実際、事象が発生した場合、ユーザーが同意した利用規約でサービスで禁止しているにも関わらずユーザーが行ったということになります。
利用規約で対策できる場合、リスクの大きさにもよりますが、システム的な対策は取らず少しでも多くのビジネスに貢献する機能を盛り込み、顧客に価値を届けられるか検証を優先するのがよいでしょう。
利用規約をどうやって作るのがよいか
実際にサービスを事業化する場合は、企業の中で業務として新規事業に取り組むケースが多いかと思います。少なくともあなたのサービスをあなたの組織の中でこれから立ち上げようとしているような状況を想定しています。
利用規約を誰がつくれるのか
私達はただでさえシステムを開発するので大変なので、利用規約ぐらい法務部門の担当者で作ってもらえないかと思ってしまうのではないでしょうか。残念ながら、普段話をしないその法務担当者であれば、その人はあなたのシステムに詳しくない可能性が高いです。たたき台を準備することは可能かもしれませんが、あなたのシステムに最適化した利用規約は作れません。あなたが考える必要があります。
利用規約と関係者とそれぞれの思い
- 法務担当者は法的リスクを最小限にしたいでしょう。
- 知財担当者は知的財産権をすべて守りたいでしょう。
- セキュリティ監査部門は個人情報の取扱やセキュリティに対して完璧な要求を求めてくるでしょう。
そのサービスがビジネス的に責任を持っているのは彼らではなく、おそらくあなたです。彼らにすべてをゆだねてしまうことはおすすめしません。
類似サービスの利用規約を参考にすべきか？
世の中に、あなたが作ろうとしているサービスと同じようなサービスがすでにあるかもしれません。その場合、その利用規約をベースにすればよいという考えもありますが、参考にする程度とどめましょう。すでに出来上がっている利用規約は完全なのか、不完全なのかわかりません。その項目がピックアップされた背景も確認することができないでしょう。
良いウェブサービスを支える「利用規約」の作り方やWebサイトの利用規約で利用規約のひな形が提供されています。こちらのような必要最低限のテンプレート、もしくはあなたの組織で用意されているものひな形から、自分のWebサービスの特性や、類似サービスを参考に、自身が必要だと判断したものを加えていくのがよいと、筆者は考えます。
利用規約を用意するということ
利用規約を用意するということは、単にドキュメントを配置して公開するだけではありません。同時にシステム的な対応を求められることがあります。例えば、イメージしやすいところだと「請求・支払い」や「重要事項の通知」については、最初から利用規約と同時に仕組みを十分に考えておく必要があるでしょう。
私の場合だと、「請求・支払い」は当初から利用規約と同時に考えて仕組み化していました。そのため利用規約にかかれている仕組みが用意されている状態になっています。
一方、「重要事項の通知」については、メールアドレスを持っているので、なんとかなるだろうという感覚で進めてしまっていました。結果、検討不十分となり、実際に通知を行う場合に誰に行うべきということを踏まえて、ユーザーロールの設計できていなかったり、障害発生時の緊急メンテナンスの断りの連絡などの手段において、問題を先送りしてしまった感があります。
利用規約へ記載する内容について
全ての項目は記載しませんが、特に筆者が実際運用してみて、当初あまり考え切れていなかった項目を中心に取り上げます。
サービスに関する重要事項の通知する（規約の変更 他）
先にも述べましたが、通知手段は非常に重要です。最初に十分に要件を確認して置かなければなりません。特にあとからシステム化と密接に繋がり、バックログとして優先的に開発する必要があることも出てきます。
サービスの登録メールアドレスに通知する、契約上の契約者のメールアドレスに通知する、もしくは、サービスログイン後の画面で通知するあたりが多いかと思います。重要事項に関して通知すべきタイミングは多岐に渡ります。
- サービスの廃止
- サービスの料金や規約など重要事項の変更
- システムメンテナンスの案内
- システム障害発生の案内
など
メールはすぐに見られない可能性もあるでしょう。ログイン後の画面だけだと障害発生時に通知できないこともあります。通知といえば、FacebookやAWSのサービスなどの通知の仕組みをイメージする人もいるかも知れませんが、これらのサービスの通知の仕組みは非常に複雑です。それだけで一つの通知サービスとしてかなりの開発規模になり得ることもあるでしょう。優先度の判断の際に、あなたは本当は何を作りたかったか改めて問いかけ直す必要があるでしょう。
筆者も利用していますが、通知全般はSendGridのような外部サービスとして切り出しておけると、開発工数を抑えつつ耐障害性も確保する事ができます。ただし、その場合メールアドレスという個人情報を外部へ預けるということになります。どちらがよいかの判断が必要でしょう。
サービスを悪意のある攻撃者から守る（禁止事項／サービス停止／ユーザー資格の取消）
あなたのサービスのユーザーはあなたが想定する範囲内での利用をするとは限りません。
あなたのサービスを利用したいと考えるユーザーの中には予期しない振る舞いを行うことがあるかもしれません。例えば、興味本位で負荷テストを実施し、当該サイトに必要以上に負荷をかけてしまったり、あなたのサービスを踏み台にし、第三者のサイトに攻撃を仕掛けたりすることも考えられなくはないでしょう。
これらのあなたのサービスで行うべきでない行為は法律的にNGのもの、法律的に明確にNGで無いもの含めて利用規約で禁止しておきましょう。また、システム的に対策を行えていないことならなおさらです。システムの負荷テスト対策を行うためにはアクセス流量を把握し、単位時間あたりの上限を設定し、適切な範囲でアクセス制御する仕組みを組み込む必要があります。
1人のユーザーが原因でWebサイトをダウンさせてすべてのユーザーに損害を与えたり、他のシステムへ損害を与えてしまうことが考えられます。このようなユーザーアカウントは全体への影響を考えると、ユーザーへの同意を得ずとも即時に停止できるように規約に書くべきでしょう。
利用規約の運用後を見据えて
利用規約は作って終わりにはならない
最初に作成した利用規約は不完全である可能性があります。あとからあれも書くべきだったということも出てくるでしょう。サービスの成長を見据えた内容になっていないかもしれません。あなたのサービスの成長結果に合わせて、利用規約を変更していく必要があります。
例えば、ベータサービス中は料金を請求しなかった場合や、不安定なサービスレベルで考えていた部分もあるでしょう。正式サービス化する場合は必ず見直すべきでしょう。また、個人情報保護法などの法律の改正など外部環境の変化、新しい外部サービスとのAPI接続の発生の場合も変更の可能性があります。
もし顧客が利用規約に同意できない場合は？
基本的にはすべての利用ユーザーへ利用規約を同意してもらい、サービスを運用すべきです。ごく一部のユーザーが利用規約へ同意してもらえない場合、サービスを利用してもらうことを諦めるのもサービスとしてはやむを得ない事となるでしょう。SaaSサービスの場合、1社のアカウントを特別扱いすることは将来のサービス成長の妨げになることはありえます。
特に、企業向けのサービスであれば、個別契約を要望してくる場合もあるかもしれません。顧客の企業によっては、受託開発と同じレベルで要望してくる企業もあるのが実情です。原則は断るべきです。しかしながら、個別契約を考慮せざるを得ないケースもあるでしょう。その場合にどう考えるのがよいか、少し考えてみます。
まずは、変更リクエストの背景を抑えるべきです。背景が理解できない変更リクエストは受け入れるべきではありません。やむを得ず変更を受け入れる場合は、以下を確認しましょう。あくまでも最終手段です。
利用規約からの差分で管理する
- 利用規約自体を今後も改定することを想定し、改定分が有効になるようにする
- 利用規約自体を改定した場合に、影響が局所的になるようにする
利用規約に受け入れた場合の追加で必要となる作業を把握する
- その変更を受け入れた場合、契約を保証するために追加機能の開発が必要にならないか
- 現時点では満たしているが、今後の開発が制限されないか、制約として管理する
利用規約自体を改定すべきか検討する
- 陳腐化してきたなど利用規約自体を見直しても良いものではないかを考える
上記、受け入れる場合で他の要望を出していないユーザーからみて公平でなくなる可能性もあります。その場合、料金プランを他のユーザーと比べて個別に設定するなどすることも選択肢に入りうるでしょう。
まとめ
利用規約は利用者側はほとんどスルーしているかもしれませんが、提供側としてはしっかり向き合い、自分のサービスにフィットさせる必要があります。Webサービスに携わる全てのみなさんが理解すべき内容です。みなさんが提供するサービスの利用規約がどうなっているか、どうあるべきかこの機会に考えていただければ幸いです。
- 利用規約はトラブルや、悪意のある少数のユーザーからあなたのサービスとユーザーを守ってくれる
- 利用規約は作って終わりではない、サービスの成長とともに常に見直す必要がある
- 利用規約は全ての利用ユーザーに適用される、原則個別対応は行わない
また、 良いウェブサービスを支える「利用規約」の作り方 はとても利用規約の作り方に関して優れた書籍です。理解を深めたい方はぜひ一読ください。
さいごに
本記事で紹介したのは利用規約を作るための一部分の知識です。まず、書籍などで体系的に学ぶこと、すでに作成された方へ相談することをおすすめします。すでに皆さんがこれから公開したいサービスの具体的なイメージがある場合、一度ドラフトを作ってみることもおすすめします。
参考
-
良いウェブサービスを支える「利用規約」の作り方 - Amazon
- 上記の改定版が発売されたので、今後は改定版を参照したほうがよいでしょう。→【改訂新版】良いウェブサービスを支える 「利用規約」の作り方