SaaSの利用規約作成時に意識すべきポイントと注意点

■ 利用規約の目的と役割
■ 利用規約の重要性
■ SaaSの利用規約に入れておくことが望ましい条項
■ 規約作成時の注意点
■ 規約と別に用意するもの
■ 【まとめ】SaaSの利用規約は作って終わりじゃなくて継続的に見直しが必要！

2023-05-22

何かビジネスを行う際に、顧客と契約を結ぶというのは非常に重要なプロセスです。それはSaaSにおいても例外ではなく、契約書あるいは利用規約を用いて顧客との契約関係を築きます。

SaaSを利用したことはあっても、実際にビジネスとして立ち上げ、運営を経験している人はまだまだ少ないように思います。そんな中で、SaaSの利用規約をどう作成したらいいのか？また、SaaSの利用規約と他のサービスやプロダクトの利用規約との違いはなんなのか？といった疑問をお持ちの方のために、弊社のSaaSus Platformの規約作成時の経験をもとにSaaSの利用規約を作成する際のポイントをまとめてみました。

利用規約の目的と役割

まずは、利用規約の目的についてしっかりと理解しておく必要があります。

利用規約の目的は平たく説明すると契約事項の明確化です。本来、事業を行うなかで、契約を結ぶ際には契約書を用いますが、SaaSなどの数多くの顧客と契約することが見込まれる場合、全ての顧客と毎回契約書の内容を擦り合わせて締結するという手順を踏むとなると、業務が煩雑になるだけでなく契約までのスピードが落ちる恐れがあります。
そこで、利用規約を用いることで、全ての顧客に画一の内容を提示し、同意の有無を以って契約書と同等の効力を発揮することができます。

同意取得について

利用規約によって契約を明確にしても、相手方の同意を確認できなければいざトラブルなどが生じた場合に契約の実態を主張できない可能性があります。契約は口頭でも成立しますが、実際には書面やその他の方法で契約に関して合意が取れている証拠を残す必要があります。

SaaSなどでは一般的には利用登録のページに利用規約とプライバシーポリシーのリンクを設置し、そこに同意のチェックボックスを設けることが多いようです。サービスの利用をした時点で同意とみなす内容を規約上で明文化しておけば、チェックをした時点で規約の内容に同意したとみなされます。

規約の内容を変更した際に、変更前の同意取得のログはあるものの変更後の同意については取得できていない。といったことになると、トラブルになりかねませんので、そのような事態を避けられるように同意取得の手段を構築する必要があります。

例えば、変更の際にはログイン画面にポップアップで変更内容を表示してチェックボックスで改めて同意取得をして、同意をしてからじゃないとサービス利用に進めない形にするなどの方法があります。

利用規約の重要性

利用規約は顧客と提供事業者との契約書の代わりとなりますが、契約を明確にすることが何の役に立つのかを理解しておきましょう。目的や重要性を理解せずに規約を作成すると将来的なリスクになりかねません。

トラブル時に会社を守れるようにする

利用規約があることで、万が一トラブルになった際に会社を守ることに繋がります。

損害賠償や免責事項など、もしもの時に責任の負荷を低減させたり、理不尽な要求をされた際に、突き返すための盾になります。事業者と顧客双方の責任範囲を明確にすることで、リスクをコントロールすることが可能になります。

規約違反や不正利用への対策をしっかりとする

また、サービスの利用方法に問題のあるユーザーが存在する場合や反社会的勢力などと関係のある組織、個人の利用が発覚した際に、規約に従ってそういった不安因子を排除することができます。また、そういった体制を規約に明記することで、ユーザーにとっても、安心感を与えることに繋がります。

SaaSの利用規約に入れておくことが望ましい条項

サービスの変更に関する条項

SaaSはサービスをリリースした後も継続的にアップデートや機能追加を行うケースが多いかと思います。そのため、サービスの追加、変更、停止などに関して事業者側の裁量で行えるようにしておくと良いでしょう。この条項が欠けてしまうと、サービス変更などでユーザーに不都合が生じた場合にトラブルに発展する恐れがあります。

単なる機能の追加（ユーザーにデメリットのない変更）や軽微な修正（誤字の修正やデザインの変更など）については事業者側の裁量で問題ありませんが、サービスの停止などの重要な変更は事前に通知を行うことが望ましいです。また、緊急の変更であれば事後通知でも可とする内容があればさらに良いでしょう。

利用規約の変更に関する条項

サービスの変更だけでなく規約の変更も自社の裁量で行えるようにしたほうが良いでしょう。ただし、裁量で変更ができると言っても事前の通知は必要です。ユーザーの知らないところで規約の変更を重ねることは不信感にも繋がりますし、同意取得が十分になされない可能性もあります。

ユーザーに対する通知方法に関する条項

サービスの変更、規約の変更について定めた上で、それをユーザーにどのように通知するのかを明確にしておくことをお勧めします。通知について規定する際には、顧客がどの時点で通知を受領したとするかを明確に定めておく必要があります。

例えばメールで通知を行って、そのメールが迷惑メールに入っていた場合に、方法のみを規定していて受領時点を明らかにしていなかった場合、通知は無効と主張する余地を与えてしまうことになります。事前に「メールの送信が行われた時点を受領とみなす」という文言が規約内で提示されていれば、こういった認識の齟齬によるトラブルを回避できるので、通知の手段だけでなく、それがいつ有効になるのかについてもしっかりと定めておくことが重要です。

データプライバシーとセキュリティに関する条項

SaaSを提供する場合、事業者はユーザーの個人情報やそれに関連する情報を収集・活用する場面があるかと思います。そのような前提において、ユーザーのプライバシーや権利を保護するための措置を明記することが一般的です。例えば、個人情報の収集とその利用について、情報のセキュリティや保管方法、第三者との情報共有に関して規定することがあります。これらの条項は自社で用意しているプライバシーポリシーとの整合性も考える必要があります。

また、個人情報の取り扱いに関するルールや法規制は国によっても異なるので、海外のユーザーの利用が想定される場合には、対象となる地域の基準を遵守した情報の収集・活用が求められます。国内のみを想定している場合でも、海外のユーザーが利用した場合にはその地域の基準での取り扱いを求められるので、そういった不測の自体が起こらないように、事前に国際水準の規定にしておく、もしくは国外からのアクセスができないようにするなどの対策が必要です。違反した場合のペナルティが事業の運営にも大きく影響する場合があるので、事前に入念に調べた上で定める必要があります。これらはかなり専門的な内容になるので自社で判断せずに専門家の知見やアドバイスを受けながら策定する必要があります。

ユーザーの責任、および禁止事項に関する条項

ユーザーの責任にはアカウントやID、パスワードの管理や第三者利用の禁止、利用環境の整備などが含まれます。SaaSの中にはAPIを使用して外部のサービスとの連携が可能な場合もあるので、そういった第三者サービスの使用に際しての自己責任を規定するものもあると良いでしょう。

禁止事項にはサービスを利用する上で起こりうる不正を網羅的に記載しておくことが求められます。それだけでなく、それらが発生した場合に契約の解除やそれに伴う違約金の請求、アカウントの停止、損害が生じた場合には損害賠償請求などができる建て付けになっていることが望ましいです。

請求、キャンセル、および返金ポリシーに関する条項

支払いや請求などのお金周りの取り扱いについてもしっかりと利用規約内で定めておきましょう。支払い方法や支払い時の手数料の負担者や日割りの有無など基本的な内容の他に、SaaSではサブスクリプションを採用するケースも多いのでその場合は自動引き落としに関する記載もつけておくと良いでしょう。

未払い時の対応やキャンセル、契約終了時の返金などのイレギュラーに関する規定も必要です。遅延損害金の発生や未払い時の契約解除について定めておくことで、未払いへの抑止として働く側面もあります。また、返金については日割りを採用しないのであれば基本的に不要かと思いますが、例えばサービス開始から短期間で解約した場合の返金や、1年分のまとめ払いなど残存期間が発生するケースには返金規定を設けておく方がユーザーにとっては親切な設計になります。

一般的な条項

一般的なWebサービスの利用規約やその他の契約にも記載される条項についてはなるべく記載するようにしましょう。もちろん、サービスに不要なケースもありますが、他の規約との矛盾やサービスの邪魔にならない範囲であれば、削除せずに残しておいても良いでしょう。後に必要になるかもしれませんし、使わないだけである分には問題はないので、ないよりはあった方が不測の事態に備えることができます。

また、損害賠償やアカウントの削除などは問題になりやすい箇所なので細かくチェックしましょう。これらの条項を適当にしてしまうと、問題が生じた際に会社に多大な損害を生じさせる可能性も考えられます。

サービスの特性に合わせた条項

一般的な条項だけでなく、サービスに合わせた内容も記載するようにしましょう。類似サービスを参考にするとどんな項目が必要なのか見えてきます。

たとえば労務系のSaaSであればマイナンバーに関する取り決めを規約内で定めていたり、電子契約系のSaaSはやりとりされる契約の内容について関与しないなどの立場を宣言していたりします。SaaSによって提供されるサービスによって変わるので、自社のサービスの特徴や機能の詳細を明らかにした上で、弁護士などの専門家にアドバイスをもらうと良いでしょう。

特約

もし、サービスのアップデートを続けていく中で、既存の規約では不十分になってしまった場合やアカウントごとに扱いが異なるような場合には特約のような形で、規約とは別に項目を設置する形が良いでしょう。基本的なルールについては規約の内容を適用し、部分的に特約を優先して適用することで、このようなケースに対応することができます。

そのためにあらかじめ規約内で「矛盾が生じた場合は特約を優先する」といった旨の記載が必要です。そうすることで相反する内容だとしてもサービスやプランに応じて対応を分けることができます。よくある例として、無料版と有料版での差異を特約などの形で設けることがあります。

SLAについて

SLAはサービスレベルアグリーメントの略で、サービスの動作保証を記載したものになります。SLAは規約外に別途で定めることもありますが、不具合時の返金対応などを規約に記載する場合の参照先として規約内にリンクを設けることもあります。

「SLAを満たさなかった場合、不具合発生月の翌月末に利用料の何％を返金いたします」のように、不具合発生時の補償の対象を明らかにするための基準に当たります。不具合発生の有無が数値で表現されるため、顧客にとってもサービスの安定性や補償の請求判断が容易になるため、信用を得ることにもつながります。

SLAでは主に下記の内容について記載することが一般的です。規約内に落とし込む形でも問題はありません。

サービスの可用性に関する規定
サポートサービスに関する規定
サービスレベル目標の設定
利用者によるサービス利用の制限
サービス提供者の免責事項

1.サービスの可用性に関する規定

サービス利用の開始・終了時刻、システムメンテナンスなどに伴うサービス停止時期がある場合は明確に記載し、通知方法や通知時期についても合わせて記載することが望ましいです。また、災害発生時のシステム復旧／サポート体制、早期復旧が不可能な場合の代替措置などの障害が発生した際の対応や問い合わせ先なども記載することが望ましいでしょう。

アップグレード方針として頻度や事前通知方法、履歴管理、公開、利用者の負担についても明示すると良いでしょう。

2. サポートサービスに関する規定

お客様からの問い合わせに対して、どのような対応が行われるかについて記載します。オンラインでのサポート、メールや電話での対応、また返信までの時間の目安などを明示することが一般的です。

3. サービスレベル目標の設定

「99.9%の可用性を維持する」など、サービスレベル目標を設定することで、顧客に対して提供するサービスの品質を保証することができます。サービスの稼働率は「(計画サービス時間－停止時間)÷計画サービス時間」で表されます。また、サービス提供者が定めた目標に達成できない場合、その理由やユーザーの権利や補償措置についても記載することが重要です。

4. 利用者によるサービス利用の制限

サービス利用に関して、使用内容、回数、容量、期間などに上限がある場合は、その規定を明確に記載します。また、違反行為に対する罰則についても明示することが一般的です。

5. サービス提供者の免責事項

サービス停止やデータの紛失の原因がサービス提供者ではない場合、またはユーザーの違反行為によって生じた損害や不利益については、サービス提供者が免責されることがあります。その際、免責される範囲を明確に定めることによって、顧客の理解を促進することができます。

規約作成時の注意点

サービスの詳細を把握している人を巻き込む

SaaSの規約を作成する際はプロダクトオーナーなど、サービスの全体像を把握している人を巻き込むようにしましょう。サービスの中身を知らない法務担当が作った規約ではサービスの細かい仕様との齟齬が生じて、実際にサービスをリリースしてから問題が発生するということも考えられます。

そのため、細かくサービス内容や契約の流れ、各種用語の定義、利用のルールや懸念事項などを吸い上げた上で作成するようにしましょう。規約の変更を自社の裁量で行えるようにしても、あまりにも変更が多いとなると顧客側の不信感に繋がる恐れがあります。

足枷にならないような建て付けを意識する

パッケージ型のソフトウェアであれば、規約作成時点で完成形が見えているため、それにあわせたものを作成すれば問題はありません。しかし、SaaSの場合、もちろん事前にある程度の方針は決まっていても、それが必ずしもその通りにいくわけでなく、サービスを提供しながら方針やサービス内容が変化していく可能性が十分にあります。

前述の通りSaaSは変更を前提とした提供体制なので、その変更を行う際に規約が邪魔をするということはなるべく避けたいです。そのためにもプロダクトオーナーなどと綿密に打合せを行い将来的なサービスの展開や機能のイメージを早い段階で共有することが重要です。規約自体の変更はしやすい建て付けにするのが大前提ですが、細かい変更を重ねていると改訂履歴が多くなってしまい、サービスの不安定さを感じさせてしまうこともあります。

定義は明確にする

規約内に登場する用語の定義はわかりやすく明確にしましょう。用語に対する認識の齟齬によって顧客とトラブルになることも十分に考えられます。事業者側の目線では当然だと思うことも、一度顧客目線に立った時に認識違いが起きないかをじっくりと考えてみると良いでしょう。

例えば「会員」「ユーザー」など一見したら同一に思えるような表現には特に注意が必要です。また、そのサービス独自の表現などにも注意が必要です。

なるべくわかりやすい用語を用いることも重要です。規約内に登場する用語が複雑だと、規約の理解の妨げになる恐れもあります。

個別契約は極力避ける

提供するサービスがどういったサービスなのかにもよりますが、基本的には個別で契約を結ぶような契約フローにはしないことをお勧めします。

個別契約にすることで、各企業との契約内容の交渉に応じたり、それを検討する手間が発生します。また、契約書に変更が生じた場合に、それぞれの顧客に対して通知を行なったり、変更の打診を行う必要が出てくるので、サービスの成長にブレーキをかけてしまうことにもなりかねません。契約企業の数が少なければ問題ありませんが、多数の顧客と毎回契約を結ぶのは非常に大変です。その契約で大きなリターンを期待できる顧客であれば個別契約もやむなしですが、前述の手間と得られるリターンのバランスを慎重に考える必要があります。

基本的には個別契約は行わないというスタンスを貫くことが重要です。

規約と別に用意するもの

料金表

料金表などは改訂が見込まれる箇所なので、規約内に設けずに別途定めておく方が良いでしょう。料金や支払いに関する条項内に「料金表を参照」のような表現で記載しておくと良いかと思います。プランが増えたり、金額が変わるたびに規約も修正が必要となると機動力が落ちてしまいます。

なお、金額の変更などは事前に通知をし、相当の猶予期間を設けた上で実施するようにしましょう。

サービスマニュアル

サービスマニュアルも外部に作成したものをリンクでおく形が良いです。変更や追加などが見込まれるので、規約内で細かく機能ごとの解説や使用方法を明記するのは現実的ではありません。その際に、サービスマニュアルやWebページの記載も規約と同様に顧客が遵守するものとして位置付けておくことをお勧めします。

【まとめ】SaaSの利用規約は作って終わりじゃなくて継続的に見直しが必要！

SaaSの利用規約は作って終わりではなく、サービスの成長と共に定期的に見直す必要があります。そのため、サービスの成長や変更に合わせて規約の見直しが必要ということを法務部門だけでなく、ビジネスサイドや開発サイドにも浸透させておくことが重要です。機動力を重視するあまりに法務担当に適切なタイミングで相談されずに、気づいたら規約と実際のサービスの内容が噛み合わない、というような状況になってしまうとトラブルのタネになります。

利用規約は契約書と同様に法的拘束力を持ちますが、表現や内容によっては法的に無効とされる場合があるので、作成の際には専門知識を有する弁護士に相談しながら作成することをお勧めします。

E-Book「SaaS開発ガイド」にてSaaS開発に取り組む前に知っておきたい重要ポイントを解説しています。

SaaSに関する基礎的な知識を身に付けたい方はぜひご一読ください。