SaaSとスタートアップ業界

SaaSとは？

SaaSとは「Software as a Service」の略で、「ユーザーが開発者などからソフトウェア提供を受けるに当たり、必要な機能のみを選択して利用できるようにしたソフトウェア」です。ユーザーはネットワーク経由でサービスプロバイダから利用したい機能を直接入手し、その使用分に対して対価を支払います（「SaaS向けSLAガイドライン」（2008年1月）参照）。
利用例としては、Salesforceに代表されるCRM（Customer Relationship Management ）やSFA（Sales Force Automation）、SmartHR等の人事情報管理サービス、freeeやマネーフォワード等の会計・企業サービス、フロムスクラッチ等のマーケティングオートメーションツール、ヤプリ等のアプリ開発ツール、リーガルテックサービス等があります。

SaaSは今やスタートアップ業界を牽引する存在

SaaSは、圧倒的な勢いでスタートアップ業界を牽引しています。2018年10月28日付日経新聞では、2018年に『日本は「SaaS元年」、スタートアップが引っ張る』とされ、同年の国内SaaSスタートアップの資金調達額は1000億円に迫り、アメリカでのベンチャーキャピタル投資は、その4割がSaaS向けが占めるとのデータがあると言われています。
直ぐに思い浮かぶ例では、2018年にアメリカで、オンラインストレージSaaSのDropboxが約110億ドルの初値で上場、2019年にはSlackが約195億ドルで上場しています。国内では2019年に名刺管理SaaSのSansanが約1424億円、クラウド会計SaaSのfreeeが約1165億円の初値で上場しています。いずれもユニコーンとして、SaaS業界の盛り上がりを示しています。
弊所も多くのSaaSスタートアップの支援を行っていますが、SaaSスタートアップの成長は著しく、また、身近に接点を持つ国内外のベンチャーキャピタリストも有望なSaaS企業（特にBtoB・SaaS）を探して動きを活発化させているといった実感があります。BtoB SaaS専門の投資家・前田ヒロ氏が、「BtoB SaaSはノウハウを体系化しやすい」と指摘されているように、SaaSについては、数々の体系化されたノウハウ等があり（書籍で言えば、ザ・モデル等）、成功の再現性が高いという点もベンチャーキャピタリストが好む一因になっていると思います。
新型コロナウイルスの影響による経済低迷も懸念されるところではありますが、リモートワークへの対応や柔軟な働き方に寄り添う、SaaS企業の成長は今後も継続することが予想されます。
少し前置きが長くなってしまいましたが、今回は、2020年4月1日より、改正民法が適用され、一定程度SaaSビジネスにも影響が出ることが想定されるため、民法改正も踏まえつつ、SaaSを扱うスタートアップ経営者や法務担当者に意識しておいてほしいことを整理したいと思っています。なお、民法改正と契約実務の対応については「民法改正と契約実務対応」もご参照ください。

SaaSのSLA

SaaSビジネスを行うにあたって法務的に重要なのは、SLAと利用規約です。まず、本章ではSLAについて、様々なSaaS企業の実例を紹介しながらその実務上の留意点について解説します。

SLAとは？

SLAとは、Service Level Agreementの略であり、「提供するサービスの品質に関するSaaS企業とユーザーの間の合意」です。SLAにおいては、SaaS企業がその提供するサービスの品質について、一定の水準を保証し、保証された水準を下回った場合には、ユーザーへの返金その他の何らかの効果が発生する旨が定められます。SLAの締結形態としては、利用規約等のサービス利用契約文書の一部として締結される場合と、利用規約等のサービス利用契約文書から独立した文書として締結される場合がありますが、いずれの場合においても、SLAが締結された場合は、SaaS企業とユーザーとの間の契約内容となり、法的効力を有します。

SLAはなぜ必要か？

ユーザーは、SLAにより、一定のサービスレベルの保証を受けることができるという明確な利益を受けます。ユーザー側にとって、SaaS企業の提供するサービスは、契約を締結し実際に使用してみないことにはその具体的な品質がわからないという不透明性が存在しますが、SLAはこの不透明性を解消する効果を持ちます。
一方、SaaS企業側にとっても、SLAにより一定のサービスレベルへのコミットメントを示すことで、ユーザーを獲得しやすくなるため、SLAの締結にはメリットがあります。競合他社がSLAを締結していない場合には、SLAの締結はそれ自体が競争優位性になり得ますし、サービスレベルの高さをアピールすることもできます。また、あらかじめサービスレベルの保証水準を明確に合意しておくことで、ユーザーとのトラブル・紛争を未然に防止する効果もあります。
すなわち、SLAはユーザーとSaaS企業の両者にメリットがあります。実際に、後程紹介するように多くのSaaS企業がユーザーとSLAを締結し、一定のサービスレベルへのコミットメントを示しています。

SLI、SLOとは？

SLAと関連する用語に、SLI とSLOがあり、それぞれ全く意味が異なります。
SLI（Service Level Indicator）とは、サービスレベルの指標を意味します。一口に「サービスレベル」と言っても、その指標は様々に考えられ、サービスの稼働率や、応答速度、エラー率などがあります。
SLO（Service Level Objective）とは、サービスレベルの具体的な達成目標値であり、SLAによりその達成が保証される値でもあります。サービスがこの値を下回った場合、SLAに基づいてユーザーへの返金その他の効果が発生します。
具体例で示すと、SaaS企業が、ユーザーに対しサービスの稼働率99.99%を保証した場合、

・SLA ：稼働率99.99%を保証する内容の、SaaS企業とユーザーの間の合意
・SLI  ：「稼働率」というサービスレベルの指標
・SLO：「99.99%」というサービスレベルの具体的な達成目標値

ということになります。
なお、SLOは、SLAによって保証される数値としてではなく、あくまでSaaS企業内部で設定されるサービスレベルの目標数値として用いられることもありますが、本稿では上述の意味で用います。

SLAの構成要素

経産省による「SaaS向けSLAガイドライン」（2008年1月）においては、SLAの一般的な構成要素として、以下が挙げられています。

SLA構成要素	構成要素の概要
前提条件	サービスレベルに影響を及ぼす業務上／システム上の前提条件
委託範囲	合意された委託内容がカバーする範囲
役割と責任	利用者とSaaS提供者の役割と責任を明確化した分担表
サービスレベル項目	管理対象となるサービス別に設定される評価項目および要求水準
結果対応	サービスレベルが達成されなかった場合の対応方法（補償）
運営ルール	利用者とSaaS提供者間のコミュニケーション（報告・連絡）のルール／体制

経産省「SaaS向けSLAガイドライン」（2008年1月）p22より抜粋

この表に挙げられた要素のうち、SLAの中核的内容を構成するのは、「サービスレベル項目」と、「結果対応」なので、本稿ではこの2点につき解説します。

サービスレベル項目（SLI）

経産省ガイドラインで挙げられている「サービスレベル項目」とは、すなわちSLIであり、何をサービスレベルの指標とするか、という問題です。SLIの選定にあたっては、各企業において、その提供するサービスの具体的態様等に応じて検討する必要がありますが、各企業において必ずと言っていいほどSLIに選定されているのが、サービスの「稼働率」、すなわちシステムが稼働すべきであった場面のうち、正常に稼働していた場面の割合です。SaaS企業の提供するサービスには様々な種類がありますが、どのようなサービスにおいても、サービスが頻繁にダウンしていては問題であるため、稼働率はサービスレベルの指標として等しく重要です。SLIの選定にあたって、稼働率は第一に候補に挙がるものと言えます。
SLIを選定した後に、それを契約書（SLA）に落とし込む際に留意すべき点として、SLIを厳密に定義することが挙げられます。稼働率を例に用いると、一口に稼働率といっても、その定義は各社によってかなり異なります。
例えば、株式会社マネーフォワードのマネーフォワードME、Google社のGoogle Colud Storageではそれぞれ以下のように定義されています。

マネーフォワードME
1か月間のうち、使用不能時間（サービス全利用者の5%以上が、サービス停止状態となった時間）を除いた時間の割合
（株式会社マネーフォワード「利用規約」第9条）

Google Cloud Storage
稼働率：100%から、月の請求期間中の各5分間で測定されたエラー率の平均を差引いた値
（Google Asia Pacific Pte. Ltd「Google Cloud StorageのSLA」）

このように、稼働率一つとってもその定義には様々なものがあり得るので、SLIを契約書に落とし込む際には、疑義が生じず、一意に定まるように厳密に定義を行うことが重要になります。これを怠ると、ユーザーとの認識の齟齬が生じ、無用なトラブル・紛争を招くことになります。

結果対応

サービスレベル項目（SLI）と合わせて、SLAの中核的内容を構成するのが、結果対応、すなわち、実際にサービスレベルがSLAで保証されている水準を下回った場合のSaaS企業の対応です。一定の金銭的補償が行われることが多いですが、その具体的内容は様々なものが考えられますが、次の二つの類型がよく見られます。

（ア）現金返還型

サービスがSLAで保証した水準を下回った場合に、ユーザーに対し現金を返還する方法です。後に紹介するクレジット付与型と異なり、実際に現金の支出を行うことが必要であるため、この方式は一般的にはSaaS企業にとって負担の大きいものであるといえます。
この方式を採用している企業に、ビジネス向けチャットツール「Chatwork」を提供するChatwork株式会社があり、サーバ稼働率が99.9%未満となった場合に、ユーザー利用料の10%を返還する旨を定めています（「サービス品質保証（SLA）」）。

（イ）クレジット付与型

サービスがSLAで保証した水準を下回った場合に、将来のサービス利用料金から一定の値引きを行う方式です。先に紹介した現金返還型と比較すると、実際に現金の支出を行う必要はないため、一般的にはSaaS企業にとって負担が比較的大きくないものであり、現金返還型よりクレジット付与型を採用する企業の方が多く見られるように思います。
この方式を採用している企業に、既に紹介したChatworkと同じくビジネス向けチャットツール「Slack」を提供するSlack Technologies, Inc.があり、アップタイムが99.99%を下回った場合に、影響を受けたすべてのアカウントに対して、Slackを利用できなかった時間分の支払済み料金の10倍に相当する金額を「Slackクレジットポイント（1pt = 1円）」として付与し、将来の利用料金の支払いにおいて利用できるものとしています（「サービス品質保証契約」）。

また、現金返還かクレジット付与かという分類と別軸の分類として、申請方式か自動付与方式か、というものもあります。
申請方式は、サービスがSLAで保証した水準を下回った場合でも、SaaS企業が自ら補償を行わず、自ら補償の申請を行ったユーザーに対してのみ補償を行う方式です。既に紹介したChatworkは申請方式を採っています。
一方、自動付与方式は、サービスがSLAで保証した水準を下回った場合、ユーザーが申請等のアクションを何ら行わずとも、SaaS企業が自ら補償を行う方式です。よりユーザーフレンドリーな方式はこちらであると言えます。既に紹介したSlackは、自動付与方式を採っています。

また、これら補償の方式の他に、結果対応をSLAに定める際に留意すべき点として、例外事由の規定があります。例外事由とは、補償の対象外となる事由のことであり、仮にサービスがSLAで保証した水準を下回った場合でも、例外事由に該当するときには、補償が行われません。
例えば、Chatworkでは「除外事項」として例外事由を以下の通り定めています。

・メンテナンス作業に伴うサービスの中断（計画、緊急問わず）
・お客様（利用者）が契約約款または法令などに違反したことによる場合
・お客様の環境、または本サービス設備以外の不具合による場合
・第三者からの攻撃、妨害による場合
・原因の如何を問わず、障害が継続した時間を測定できない場合
・火災、停電などにより本サービスの提供ができなくなった場合
・地震、噴火、洪水、津波などの天災により本サービスの提供ができなくなった場合
・戦争、動乱、暴動、騒乱、労働争議などにより本サービスの提供ができなくなった場合
・そのほか運用上あるいは技術上の理由により、Chatworkが本サービスの一時的な中断が必要と判断した場合

Chatwork「サービス品質保証 （SLA）」より抜粋

例外事由の規定の作成にあたっては、SLAで保証された水準を下回ることもやむを得ないと合理的に考えられるような事由を挙げることになります。典型的な論点としては、計画的メンテナンスのみならず、緊急メンテナンスによるダウンタイムを補償の対象とするかという点が、各社において判断が分かれているようですが、緊急メンテナンスの場合も例外事由に含めてしまうと、例外事由が恣意的に拡張してしまうおそれがあるため、基本的には、計画的メンテナンスのみを例外事由とし、緊急メンテナンスによるダウンタイムは補償の対象とすることが望ましい対応であると思われます。

SLAの運用

SLAは定めるだけで終わりでなく、SLAにおいて保証したサービスレベル項目（SLI）を継続的に測定し、運用する必要があります。ユーザーが自身でサービスレベルを測定することは非常に困難である以上、SaaS企業は、SLAにおいて保証対象としたサービスレベル項目（SLI）の実績値をWebサイト等で公表することが望ましい対応であると言えます。特に、補償の方式において申請方式を採った場合、補償の申請を行うためにユーザーが自らSLA違反がないかモニタリングをできることが前提条件になるため、実績値の公表を必ず行うべきであるといえます。

SaaSエコシステムと利用規約上の免責

SaaSビジネスの特徴に、複数のSaaSがAPI（Application Programming Interface）等による相互連携を行っており、一種のエコシステムを形成している、という点があります。ユーザーにとっては、導入する複数のSaaSが連携されることで、よりシームレスかつ効率的にビジネスを行うことができるようになります。例えば、先ほどご紹介したチャットツールSlackは、Google DriveやDropbox、JIRA、Asana等といった10以上の他社SaaSサービスと連携することができます。
SaaS企業にとって、他社SaaSサービスと連携する際に利用規約上重要になるのは、連携する他社SaaSサービスが適切に稼働しなかったことによりユーザーが損害を被った場合に、自らの責任を免責することです。
この免責は、付加的な機能における第三者のサービスとの連携に留まらず、システムの稼働の基盤部分を第三者のサービスに依拠しているというような、エコシステムのレイヤーが異なるサービスと連携している場合により重要となります。第三者のサービスが適切に稼働しなかった場合には、自社サービス全体がダウンするような重大な事態が生じることもあり得るためです。具体的には、Amazon Web Servicesのようなシステムの基本的機能を提供するサービスを利用して自社サービスを構築した場合が想定されます。

連携する他社SaaSサービスが適切に稼働しなかった場合にSaaS企業の責任を免責する具体的規定として、例えば、クラウド型電子契約サービスのクラウドサインの利用規約では以下のように定められています。

第19条（免責）
４　当社は、当サービスまたは当サービスが提携するサービスの変更、中止または終了によってお客さまに損害が発生した場合でも、一切の責任を負いません。
５　当社は、当サービスまたは当サービスが提携するサービスの変更、提供中止、停止、故障等により、損害が生じたとしても、これについて一切の責任を負わないものとします。
（弁護士ドットコム株式会社「クラウドサイン利用規約」）

また、クラウド人事労務サービスのSmartHRの利用規約では、Amazon Web Servicesの名称を利用規約中で具体的に挙げており、特徴的です。

第13条（本サービスの停止等）
１　当社は以下のいずれかに該当する場合には、お客様に事前に通知することなく、本サービスの全部又は一部の提供を停止又は中断できるものとします。
（中略）
　③本サービスの提供に必要な外部システム（Amazon Web Services等）の提供又は利用が遮断された場合
（株式会社SmartHR「SmartHR利用規約」）

各SaaS企業においては、こうした他社事例を参考にしつつ、自社サービスにおける第三者サービスとの提携の具体的ありかたや、そのリスクの特質を踏まえて、免責等の条項の規定を検討するとよいでしょう。

改正民法と利用規約

SLAの内容含め、SaaSでは、利用規約でサービスの内容・事業者の責任等が定められます。したがって、利用規約をどう規定するかが事業の生命線となり得ます。
民法の原則によれば契約の当事者は契約の内容を認識しなければ契約に拘束されません。しかし、SaaS事業者は大量の取引を迅速に行うため、詳細で画一的な取引条件等を定めた約款を用いることが必要不可欠です。SaaSを始めとする需要増加を背景に、改正民法では、①ある特定の者が不特定多数の者を相手方とする取引で、②内容の全部又は一部が画一的であることが当事者双方にとって合理的なものを「定型取引」と定義した上、この定型取引において、③契約の内容とすることを目的として、その特定の者により準備された条項の総体を「定型約款」として、これに関する規定が新設されました（改正民法548条の2）。鉄道・バスの運送約款、電気･ガスの供給約款、保険約款、インターネットサイトの利用規約等が「定型約款」として想定されます。
改正民法で定められた定型約款のルールとして重要なのは、以下の3点であり、それぞれにつき解説します。

　①組入要件
　②不当条項
　③一方的な内容変更

組入要件

組入要件とは、定型約款の各条項の内容が当事者間の契約の内容となるための要件です。民法上の原則では、契約書の各条項の内容が当事者間の契約の内容となるためには、各条項の内容について当事者が認識した上で、これを契約の内容とすることにつき同意する必要があります。定型約款における組入要件は、この民法上の原則の例外として、定型約款については、その各条項について当事者が認識していなくとも、一定の要件を満たすことでそれらが当事者間の契約の内容となることを認める制度であるといえます。

組入要件について定めた改正民法の条文は以下の通りです。

改正民法第548条の2
１　定型取引（ある特定の者が不特定多数の者を相手方として行う取引であって、その内容の全部又は一部が画一的であることがその双方にとって合理的なものをいう。以下同じ。）を行うことの合意（次条において「定型取引合意」という。）をした者は、次に掲げる場合には、定型約款（定型取引において、契約の内容とすることを目的としてその特定の者により準備された条項の総体をいう。以下同じ。）の個別の条項についても合意をしたものとみなす。
①定型約款を契約の内容とする旨の合意をしたとき。
②定型約款を準備した者（以下「定型約款準備者」という。）があらかじめその定型約款を契約の内容とする旨を相手方に表示していたとき。

この条項では、「定型取引」を行うことの合意があり、かつ約款が「定型約款」に該当することを前提として、さらに次の二つの要件のいずれかを満たす場合に、約款の個別の条項につき合意がなくとも、それが契約の内容とされることが規定されています。

① 定型約款を契約の内容とする旨の合意をしたとき
② 定型約款を準備した者（以下「定型約款準備者」という。）があらかじめその定型約款を契約の内容とする旨を相手方に表示していたとき

① 定型約款を契約の内容とする旨の合意をしたとき（1号）

「定型約款を契約の内容とする旨の合意をしたとき」とは、当事者が定型約款の個別条項の内容を認識している必要がなく、文字通り定型約款を契約の内容とする旨の合意で足りるということを意味します。
例えば、ユーザーがSaaSのサービスサイト上で「当サービスの利用規約に同意する」旨のチェックボックスにチェックを入れた場合は、当該利用規約の個別条項が表示されておらず、ユーザーがこれらの内容を認識していなかったとしても、「定型約款を契約の内容とする旨の合意をしたとき」にあたり、さらに「定型取引」を行うことの合意があり、利用規約が「定型約款」に該当するという前提を満たせば、当該利用規約が契約の内容となります。

② 定型約款を準備した者（以下「定型約款準備者」という。）があらかじめその定型約款を契約の内容とする旨を相手方に表示していたとき（2号）

この要件では、「定型約款準備者」（SaaS事業者は通常これに該当します。）があらかじめその定型約款を契約の内容とする旨を相手方に表示していたときは、当該定型約款の内容が契約の内容となることを定めています。1号のように定型約款を契約の内容とする旨の合意をユーザーから得ることは不要であるので、こちらの要件により組入を行う場合には同意のチェックボックスにユーザーがチェックを入れるというようなことは不要になります。
一方で、1号と異なるのは、相手方への表示が「あらかじめ」行われている必要がある点です。すなわち、「定型取引合意」たるSaaSのサービスの利用契約締結がなされる時点までには表示が行われている必要があり、1号と異なりユーザーから同意を得る必要がない代わりに時的要件が課されているわけです。
具体的には、サービス申込画面までの画面上で、特定の利用規約が契約内容となる旨が、ユーザーに認識できるように表示されている必要があります。例えば、サービス申込画面において、「本サービス利用規約が適用されます」という旨の表示が見やすい位置に表示されていれば基本的にはこの要件を満たすと考えられます。

SaaSにおいてはどのように組入要件を満たすべきか
①（1号）の方法を用いる場合は、具体的にはSaaSのサービスサイト上で「本サービスの利用規約に同意する」旨のチェックボックスにチェックを入れさせるという方法が考えられます。
②（2号）の方法を用いる場合は、例えばサービス申込画面に「本サービスの利用規約が適用されます」という旨の表示を行う方法が考えられます。

いずれの方法を用いる場合にも、利用規約全文を当該画面に表示することは必要ではありませんが、ユーザーから利用規約につき適切な理解を得て、事後のクレームやトラブル等を防止するという観点からは、利用規約の全文をユーザーが容易に閲覧できるようにする方策を取ることが望ましいと言えます。例えば、利用規約全文へのリンクを上記チェックボックス（①）又は表示（②）に設置することが考えられます。

一方で、Web上で利用規約の同意を得るためのフローとして従前からよく見られた、「利用規約全文をテキストボックスに表示し、最下部までスクロールさせた上で同意チェックボックスにチェックを入れさせる」という方法は、組入要件に照らすと過剰な方法であるといえます。また、利用規約の全文を表示したところできちんと目を通しているユーザーがどれほど存在するのか、全文を表示し強制的にスクロールさせることが本当に利用規約の内容をユーザーに認識させることにつながっているのかといった点を疑問視する議論がある中でこの方法を採るメリットは大きくないと考えられ、一方で強制的にスクロールをさせることでユーザーにストレスを与えUXが損なわれるおそれがあります。したがって、「利用規約全文をテキストボックスに表示し、最下部までスクロールさせた上で同意チェックボックスにチェックを入れさせる」という従来採られてきた方法を盲目的に採用すべきでなく、上記のように改正民法の組入要件を用いることで利用規約を契約に反映させつつ、スムーズなUXを確保することができる方法の採用を検討すべきであると思われます。

不当条項

改正民法においては、組入要件を満たし定型約款が契約の内容となった場合にも、定型約款中に不当な条項が存在するときは、当該条項については契約の内容とならない旨を定めた条文があります。

改正民法第548条の2
２　前項の規定にかかわらず、同項の条項のうち、相手方の権利を制限し、又は相手方の義務を加重する条項であって、その定型取引の態様及びその実情並びに取引上の社会通念に照らして第一条第二項に規定する基本原則に反して相手方の利益を一方的に害すると認められるものについては、合意をしなかったものとみなす。

本項において、不当条項として契約内容から除外される要件は、「相手方の権利を制限し、又は相手方の義務を加重する条項」であって、取引の態様等を考慮し信義則に反して相手方の利益を一方的に害すると認められるものとされています。
これとよく似た条項は消費者契約法10条にもありますが、本項のポイントは、To Cのサービスのみならず、To Bのサービスにおいても適用される点にあり、BtoBのSaaS企業も本項に留意する必要があります。
具体的に本項により無効とされる利用規約の条項としては、事業者の責任を、事業者に故意又は重過失がある場合も含めて一切免責する条項が挙げられます。このような条項は、To Cにおいては消費者契約法8条1項1号・3号により、またTo Bにおいては裁判例により無効とされてきましたが、本項によりTo Bにおいても民法1条2項を定型約款の場面により具体化した条文上の根拠が与えられたことになります。

一方的な内容の変更

民法上の原則では、締結した契約の内容を変更する際には相手方の同意が必要になりますが、改正民法においては、この例外として、定型約款の内容をユーザーの同意を得ることなく変更することができる場合が定められています。

定型約款の変更（改正民法第548条の4）
１　定型約款準備者は、次に掲げる場合には、定型約款の変更をすることにより、変更後の定型約款の条項について合意があったものとみなし、個別に相手方と合意をすることなく契約の内容を変更することができる。
①定型約款の変更が、相手方の一般の利益に適合するとき。
②定型約款の変更が、契約をした目的に反せず、かつ、変更の必要性、変更後の内容の相当性、この条の規定により定型約款の変更をすることがある旨の定めの有無及びその内容その他の変更に係る事情に照らして合理的なものであるとき。
２　定型約款準備者は、前項の規定による定型約款の変更をするときは、その効力発生時期を定め、かつ、定型約款を変更する旨及び変更後の定型約款の内容並びにその効力発生時期をインターネットの利用その他の適切な方法により周知しなければならない。
３　第一項第二号の規定による定型約款の変更は、前項の効力発生時期が到来するまでに同項の規定による周知をしなければ、その効力を生じない。
４　第五百四十八条の二第二項の規定は、第一項の規定による定型約款の変更については、適用しない。

本条1項で定型約款の内容を一方的に変更することができる場合としては、以下の2つが挙げられています。

① 変更が相手方の一般の利益に適合するとき
② 定型約款の変更が契約をした目的に反せず、かつ、各要素に照らして合理的なものであるとき

　① 変更が相手方の一般の利益に適合するとき

変更が相手方の一般の利益に適合するときは、定型約款の内容を一方的に変更することができます。例えば、ユーザーの負担金額を増やすことなくサービスを拡充するような場合がこれにあたります。
この場合の変更の具体的なフローとしては、効力発生時期を定めて周知を行うことが求められているものの（改正民法548条の4第2項）、同条第3項は適用されないので、例えば効力発生時期と同時の周知も許されると考えられます。

　② 定型約款の変更が契約をした目的に反せず、かつ、各要素に照らして合理的なものであるとき

場合によってはユーザーの不利益になるような変更を一方的に行う場合には、より厳格な要件を満たす必要があります。
「契約をした目的に反せず」とは、典型的にはユーザーがサービスを利用する意義を無に帰するような場合が想定されています。
さらに各要素に照らし合理的であることが求められますが、利用規約上の対応としては、適切な変更条項を設定することが重要です。適切な変更条項としては、利用規約の変更によりユーザーに生じる不利益を低減する措置を取る旨を定めたものが想定され、具体的には、変更の一定期間（例えば14日間など）前までに変更について周知して猶予期間を与え、変更を受け入れないユーザーに対してサービス利用契約の解除権を与えることを内容とするものが考えられます。

【執筆者】

弁護士　小笠原　匡隆

　同　　島　内　洋人