SLA、損害賠償上限、免責事由、例外、データ消失、通知・復旧・移行支援まで、企業法務実務で確認すべき論点を体系的に整理します。
SLA、損害賠償上限、免責事由、例外、データ消失、通知・復旧・移行支援まで、企業法務 実務で確認すべき論点を体系的に整理します。
免責文ではなく、SLA・救済・上限・例外を組み合わせるリスク配分設計として整理します。
SaaSの障害発生時の責任制限条項の書き方では、「一切責任を負わない」という免責文ではなく、障害リスクを誰が、何を、どこまで、どの順番で負担するかを契約で透明化することが中心になります。SaaSは継続的なクラウドサービスであり、可用性、応答時間、保守、バックアップ、セキュリティ、外部クラウド、API連携、利用者側の設定ミスなど複数の原因が絡むためです。
次の一覧は、SaaSの障害発生時の責任制限条項を設計するときの四層構造を表しています。単なる免責ではなく、SLA、責任発生、救済手段、責任制限を分けて考えることが重要であり、どの層で何を決めるべきかを読み取ってください。
稼働率、メンテナンス、障害通知、復旧目標、サポート窓口を定め、サービス水準を測定できる形にします。
どの障害が提供者の管理領域・帰責領域に属するのかを区別し、すべての停止を同じ扱いにしない設計にします。
サービスクレジット、返金、損害賠償、解除、データ返還、移行支援のどれを使うかを障害の重さごとに整理します。
損害範囲、上限額、請求期間、例外事由、故意・重大過失、秘密保持、個人情報、知財を条文で調整します。
実務上望ましいのは、提供者が管理できるリスクについては合理的な責任を負い、管理できないリスク、過大な派生損害、予測困難な逸失利益については明確に制限する構造です。個別の契約作成やレビューでは、事業内容、顧客属性、障害の影響、準拠法、取引規模、交渉力、個人情報・秘密情報・知的財産・金融規制・医療規制などを踏まえて検討する必要があります。
障害の類型、責任制限条項の機能、B2B・B2C・個人情報を分けて確認します。
SaaSとは、ソフトウェアを利用者の端末やサーバーに個別導入するのではなく、インターネット等のネットワークを通じてアプリケーション機能を継続的に提供するサービスです。契約実務では、利用規約または基本契約、注文書、サービス明細書、SLA、セキュリティ付属書、データ処理契約、保守・サポート条件、価格表、API利用条件、サブプロセッサー一覧などが組み合わされます。
次の比較表は、SaaS契約で「障害」として扱われやすい事象を整理したものです。完全停止だけでなく、性能劣化、データ障害、セキュリティ障害、外部連携障害などを分けることが重要であり、各類型ごとに契約上の論点が異なる点を読み取ってください。
| 障害類型 | 内容 | 契約上の論点 |
|---|---|---|
| 完全停止 | ログイン不可、全機能利用不可 | 稼働率、復旧時間、サービスクレジット、解除権 |
| 部分停止 | 一部機能のみ利用不可 | 重要機能か軽微機能か、影響範囲 |
| 性能劣化 | 応答遅延、処理遅延、検索遅延 | SLA対象指標に含めるか |
| データ障害 | データ消失、破損、同期不整合 | バックアップ、復元義務、損害上限の例外 |
| セキュリティ障害 | 不正アクセス、情報漏えい、マルウェア | 通知義務、調査協力、個人情報保護法対応 |
| 外部連携障害 | API、決済、メール、ID認証、クラウド基盤の障害 | 第三者サービス免責、代替手段 |
| メンテナンス停止 | 計画停止、緊急メンテナンス | 稼働率算定から除外するか |
| 利用者起因障害 | 設定ミス、過大アクセス、不正利用、利用者環境の問題 | 提供者の責任対象から除外するか |
責任制限条項とは、契約違反やサービス不具合が発生した場合に、当事者が負う損害賠償責任の範囲、金額、期間、救済方法、免責事由、例外をあらかじめ定める条項です。SaaS障害では、利用者側で売上機会の喪失、業務停止、人件費増加、顧客対応費用、データ復旧費用、代替サービス費用、取引先への補償、信用毀損、行政対応費用などが発生し得ます。
一方、提供者側から見ると、月額数万円から数十万円の利用料しか受領していないにもかかわらず、利用者の事業全体の逸失利益や第三者請求まで無制限に負担することは、保険・価格・事業継続の観点から困難です。責任制限条項は、この非対称性を調整するための条項です。
日本法を前提にすると、契約違反に基づく損害賠償では、債務不履行、帰責事由、損害、因果関係、損害額が問題になります。民法上は通常損害と特別損害の考え方があり、損害賠償額の予定も認められています。SaaSでは、契約上約束した可用性や保守義務への違反、提供者の管理領域・帰責領域、相当因果関係、上限・請求期間の有無を確認します。
B2BのSaaS契約では責任制限条項が比較的広く使われますが、故意・重大過失、秘密保持違反、個人情報漏えい、知的財産権侵害、支払義務まで一律に低い上限へ押し込むと、交渉上も法的評価上も問題になり得ます。消費者向けSaaSや個人向けサービスでは、消費者契約法上、事業者の責任を全部免除する条項や一定の不当な一部免除条項が無効となるリスクがあります。
個人データの漏えい、滅失、毀損、不正アクセス、誤送信、閲覧権限設定ミス等を伴う場合は、単なるサービス停止とは別に、行政報告、本人通知、取引先通知、フォレンジック調査費用、再発防止費用、信用回復費用を検討します。公的なSLAガイドラインや情報システム・モデル契約書からも、SLA・役割分担・補償・損害賠償・例外・運営ルールを含む総合設計が重要といえます。
サービスの重要度、管理可能性、救済手段を先に決めることで、条文と運用のズレを防ぎます。
条文を書く前に、サービスの重要度、提供者が管理できる領域、利用者に提供する救済手段を社内で決める必要があります。ここを決めずに雛形だけを作ると、営業、法務、開発、CS、セキュリティ、経営の説明が食い違います。
次の一覧は、SaaSの重要度と責任制限の強弱を判断するための観点をまとめたものです。業務停止が売上停止や法令違反に直結するほど条項の許容幅が狭くなるため、どの利用場面が重いリスクを持つかを読み取ってください。
社内チャット、ナレッジ管理などでは、低めの上限とサービスクレジット中心の設計が合理的な場合があります。
経費精算、勤怠、人事労務、CRM、SFAなどでは、停止が社内統制や顧客対応に影響します。
EC、決済、受発注、予約、広告配信などでは、逸失利益や代替手段の議論が生じやすくなります。
金融、医療、インフラ、自治体、教育、セキュリティ監視、ID管理では、通知・復旧・監査の要求水準が高くなります。
提供者のアプリケーション、提供者が選定・管理するクラウド基盤、第三者サービス、通信回線、利用者環境、利用者の設定・操作、不可抗力を区別します。第三者クラウド基盤に起因する障害をすべて免責と広く書くと利用者に受け入れられにくいため、提供者の合理的管理義務と不可抗力・外部要因免責を分けて書くことが現実的です。
次の比較表は、障害時の救済手段と当事者双方の見方を整理したものです。金銭補償だけでなく解除や移行支援も選択肢になるため、どの救済が予見可能性と業務継続に資するかを読み取ってください。
| 救済手段 | 内容 | 提供者側の利点 | 利用者側の懸念 |
|---|---|---|---|
| サービスクレジット | 稼働率未達時に一定額を翌月利用料から控除 | 金額予見可能性が高い | 実損を補填できない |
| 利用料返金 | 障害期間分の利用料を返金 | 理解されやすい | 重大障害には少額すぎる |
| 損害賠償 | 実損について賠償 | 利用者保護が厚い | 提供者のリスクが大きい |
| 解除権 | 一定以上の重大障害で解約可能 | 紛争を早期に終えやすい | 移行コストが残る |
| 移行支援 | データエクスポート、代替手段 | 利用者の業務継続に有効 | 工数・費用負担が問題になる |
| 復旧支援 | データ復元、原因調査、再発防止 | 信頼回復に有効 | 期間・範囲を明確化すべき |
責任制限条項だけでなく、救済手段を組み合わせることで、契約全体の納得感が増します。通常障害はクレジット、重大障害は解除・移行・報告、データや秘密情報は別上限という層別設計が出発点になります。
SLA未達と契約違反・サービスクレジット・損害賠償の関係を分けて設計します。
SLAは、Service Level Agreementの略で、サービス水準合意と訳されます。SaaS契約では、月間稼働率または年間稼働率、計画メンテナンス、緊急メンテナンス、ダウンタイムの定義、障害の重要度分類、初動応答時間、復旧目標時間、サポート受付時間、障害通知方法、サービスクレジット、申請期限、免責・除外事由を定めます。
提供者側の雛形では、SLA未達時の救済をサービスクレジットに限定することがあります。この設計は提供者のリスク予見可能性を高めますが、重大障害、長時間停止、データ消失、セキュリティ事故まで同じ扱いにすると利用者側の反発を招きます。
次の判断の流れは、SLA未達時にサービスクレジットだけで処理できるかを整理するものです。障害の種類により救済を切り分けることが重要であり、分岐ごとに別条項へ送るべき場面を読み取ってください。
稼働率、除外時間、申請期限、対象機能を確認します。
連続時間、月間合計時間、業務影響、主要機能への影響を見ます。
SLAで定めた控除・返金を主たる救済にします。
解除、移行支援、データ返還、原因報告、特別上限を検討します。
SLAでは、事前通知された計画メンテナンス、合理的に必要な緊急メンテナンス、利用者設備・通信回線・端末・ブラウザ・設定に起因する停止、過大アクセスや契約違反に起因する停止、第三者API・外部認証・外部決済等の停止、不可抗力、提供者の合理的支配を超える事由による停止を除外することがあります。
ただし、除外事由を広く書きすぎるとSLAが空文化します。「当社の責めに帰すべき事由によらない一切の停止」とだけ書くのではなく、除外事由を具体的に列挙し、必要に応じて「ただし、当社の故意または重大な過失による場合を除く」といった留保を置きます。
1か月・3か月・6か月・12か月・固定額・特別上限を、利用料と業務影響に応じて整理します。
損害賠償上限を決めるときは、受領する利用料、機能の重要性、想定される障害の影響、顧客の業種、利用規模、サポート・セキュリティ体制、サイバー保険・賠償責任保険の補償範囲、競合他社の契約水準、交渉可能性、上限例外の有無を総合して検討します。
次の比較表は、SaaS契約で使われる損害賠償上限の代表的なパターンを整理したものです。上限額は低いほどよいというものではなく、サービスの重要性と事故類型に応じて調整する必要があるため、各パターンの向き不向きを読み取ってください。
| 上限パターン | 例 | 向いている場面 | 注意点 |
|---|---|---|---|
| 直近1か月分 | 月額利用料1か月分 | 低額・非重要SaaS | 重大障害では低すぎる |
| 直近3か月分 | 月額利用料3か月分 | 標準的B2B SaaS | 中規模案件で使いやすい |
| 直近6か月分 | 月額利用料6か月分 | 業務影響が一定程度あるSaaS | 保険・価格設計と整合が必要 |
| 直近12か月分 | 年間利用料相当 | エンタープライズ、重要業務 | 提供者にとって負担が大きい |
| 固定額上限 | 100万円、500万円等 | 月額が小さいが影響が大きい場合 | 利用規模に応じた不均衡に注意 |
| 高い特別上限 | 個人情報漏えい等は別上限 | 事故類型ごとの調整 | 条項が複雑になる |
| 無制限例外 | 故意・重大過失、支払義務等 | 法的・交渉上必要な場合 | 範囲を明確に限定する |
「当社の損害賠償責任は、利用料の3か月分を上限とします」という表現だけでは、1回の障害ごとの上限なのか、契約期間全体の累積上限なのか、同一原因に基づく複数請求はどう扱うのかが不明確です。望ましい条項では、請求原因のいかん、法律構成、対象期間、現実に支払った利用料、累積上限を明示します。
当社が契約者に対して負う損害賠償責任は、請求原因のいかんを問わず、契約違反、不法行為、不当利得その他法律構成のいかんを問わず、当該損害発生の原因となった事由が発生した日から遡って過去12か月間に契約者が当社に現実に支払った本サービスの利用料相当額を累積上限とする。年額、半年額その他月額以外の単位で利用料が定められている場合は、対象期間の月数で按分して月額相当額を算定する旨を置きます。初月無料、割引、キャンペーン価格、複数サービス一括契約の場合は、どの金額を基準にするかも検討します。
無償プランやトライアルでは、利用料を基準にすると上限がゼロになります。無償プランは法令上許容される範囲で損害賠償責任を負わない、トライアルは現状有姿で提供する、といった設計があり得ます。ただし、故意・重大過失、秘密保持、個人情報、知財侵害等は別途扱い、B2Cでは完全免責の有効性にも注意します。
直接・通常損害、逸失利益、第三者請求、不可抗力、第三者サービス、利用者起因を分けます。
提供者側の契約では、損害賠償の範囲を「直接かつ通常の損害」に限定することが多くあります。この表現は、逸失利益、事業機会の喪失、売上減少、信用毀損、顧客離れ、取引先からの請求、代替サービス導入費用の一部、内部人件費、経営判断の遅延による損失、特別事情に基づく損害を原則として除外する目的で使われます。
次の一覧は、通常のサービス停止と別扱いにすべき損害類型を整理したものです。損害範囲を広げすぎると提供者の予見可能性が失われ、狭めすぎると利用者の業務継続に不足するため、どの損害を上限内・上限外・別条項に置くかを読み取ってください。
EC、予約、決済、営業管理、広告配信などでは争点になりやすい一方、提供者は利用者の売上規模・利益率・季節要因を把握できません。
原則除外例外検討利用者の顧客、取引先、消費者、従業員からの請求は、通常停止では除外または上限内、個人情報・知財では別処理が現実的です。
類型分け重大障害では、逸失利益を全面的に認めるより、合理的に証明しやすい代替サービス費用や復旧費用を上限内で認める折衷案があります。
交渉余地個人情報漏えいやセキュリティ事故では、行政報告、本人通知、調査協力、フォレンジックなどを通常障害から分けて扱います。
別上限不可抗力としては、地震、津波、台風、洪水、落雷、火災、戦争、内乱、暴動、テロ、感染症、政府・行政機関の措置、停電、通信障害、インターネット障害、クラウド基盤、データセンター、DNS、CDN等の大規模障害、合理的なセキュリティ対策を尽くしても防止困難なサイバー攻撃、法令改正、行政指導、輸出規制、制裁などが考えられます。
ただし、クラウド障害と書けば常に免責されるわけではありません。単一リージョン構成で冗長化を怠った、バックアップを取得していなかった、監視体制が不十分だった、既知脆弱性を放置した、といった場合は不可抗力と評価されにくい可能性があります。
当社の合理的支配を超える事由により本サービスの提供が困難となった場合、当社は当該事由により生じた不履行について責任を負わない。ただし、当社が本契約に基づき負うべき合理的な予防措置、バックアップ、監視、通知その他の義務を怠った場合は、この限りでない。AWS、Azure、Google Cloud等のクラウド基盤、メール配信、決済、SMS、ID認証、地図、生成AI API、翻訳API、会計API、CRM APIなど、SaaSは外部サービスに依存します。第三者サービスだから無条件に免責ではなく、合理的支配を超える事由と、提供者による選定・設定・監視・代替措置の管理責任を分けます。
利用者側の端末、ネットワーク、ブラウザ、プロキシ、ファイアウォール、認証設定、API設定、権限設定、データ投入、過大アクセス、禁止行為による障害は、提供者の責任対象から除外します。ただし、原因が直ちに分からないことがあるため、障害原因の切り分けに合理的に協力する義務も置きます。
故意・重大過失、秘密保持、個人情報、知財、支払義務を通常障害から切り分けます。
責任制限条項で最も重要なのは、上限を置くこと自体ではなく、何を上限から外すかです。すべてを低い上限に押し込むと、交渉上も事故時の運用上も破綻しやすくなります。
次の一覧は、責任制限の例外として検討すべき主要項目を整理したものです。通常障害とは性質が違うリスクを同じ上限で処理しないことが重要であり、どの項目を上限外・特別上限・別条項にするかを読み取ってください。
低額上限で制限すると交渉上・法的評価上問題になりやすく、情報システム契約実務でも上限外とする例があります。
漏えいした情報は回収が困難で、競争上の損害や営業秘密に影響します。情報分類や秘密情報の範囲とセットで設計します。
漏えい、滅失、毀損では、調査協力、ログ提供、本人通知、行政報告支援、再発防止を通常停止から切り離します。
ソフトウェア、画面、機能、API、ドキュメントに関する第三者請求は、補償条項で別処理することが多くあります。
未払利用料、遅延損害金、税金負担などを上限に含めると、高額未払でも上限主張が出るため通常は除外します。
個人情報を扱うSaaSでは、個人情報保護法上の委託先管理、漏えい等報告、本人通知、再発防止、安全管理措置が問題になります。フォレンジック調査費用、通知費用、コールセンター費用、信用回復措置費用をどこまで含めるか、行政制裁金、課徴金、制裁金、懲罰的損害賠償等を含めるかを慎重に検討します。
知的財産権侵害補償では、利用者による改変、提供者の仕様に反する利用、利用者データ・利用者コンテンツに起因する侵害、提供者が指定していない第三者サービスとの組み合わせ、無償版・ベータ版・試験版の利用を対象外にするのが一般的です。
B2B標準型、エンタープライズ型、B2Cで避ける表現を条文例で確認します。
B2B向けSaaSでは、SLA未達についてサービスクレジットを中心に処理し、損害賠償は直接・通常損害に限定し、逸失利益・間接損害・第三者請求を原則除外し、賠償上限を過去12か月分の利用料などに置き、故意・重大過失、秘密保持、個人情報、知財を例外として扱う構造がよく使われます。
第○条（障害発生時の対応および責任制限）
1. 当社は、本サービスに障害、停止、遅延、エラーその他の不具合が発生したことを認識した場合、当社所定の方法により、障害の内容、影響範囲、復旧見込みその他当社が合理的に必要と判断する情報を契約者に通知するよう努めるものとする。
2. 当社は、本サービスについて、別紙SLAに定めるサービスレベルを満たすよう商業上合理的な努力を行う。ただし、別紙SLAに明示された保証を除き、本サービスが中断なく、エラーなく、または契約者の特定の目的に適合して提供されることを保証しない。
3. 本サービスが別紙SLAに定める稼働率を満たさなかった場合、契約者は、別紙SLAに定める条件および手続に従い、サービスクレジットの付与を請求することができる。サービスクレジットは、当該SLA未達に関する契約者の唯一かつ排他的な救済とする。ただし、当社の故意または重大な過失により生じた損害、秘密保持義務違反、個人情報の漏えい等、知的財産権侵害に関する責任については、この限りでない。
4. 当社が本契約に関連して契約者に対し損害賠償責任を負う場合、その範囲は、当社の責めに帰すべき事由により契約者に現実に発生した直接かつ通常の損害に限られ、逸失利益、事業機会の喪失、信用毀損、データ利用機会の喪失、第三者からの請求に基づく損害、特別損害、間接損害、付随的損害および結果的損害を含まない。
5. 当社が本契約に関連して契約者に対して負う損害賠償責任は、請求原因のいかんを問わず、契約違反、不法行為、不当利得その他法律構成のいかんを問わず、当該損害発生の原因となった事由が発生した日から遡って過去12か月間に契約者が当社に現実に支払った本サービスの利用料相当額を累積上限とする。
6. 前二項の責任制限は、当社の故意または重大な過失により生じた損害、当社の秘密保持義務違反、当社の責めに帰すべき事由による個人情報の漏えい等、および当社が本契約に基づき明示的に負う知的財産権侵害補償義務には適用しない。ただし、各例外事由に適用される上限または条件が別紙または個別契約に定められている場合は、当該定めに従う。
7. 契約者の設備、端末、ソフトウェア、ネットワーク、設定、データ、API利用、契約違反、誤操作、不正利用、過大アクセス、計画メンテナンス、緊急メンテナンス、第三者サービス、通信回線、インターネット、クラウド基盤、不可抗力その他当社の合理的支配を超える事由により障害が生じた場合、当社は法令上許容される範囲で責任を負わない。
8. 前項にかかわらず、当社が本契約上負うべき合理的な予防措置、監視、バックアップ、通知その他の義務を怠ったことにより障害が拡大した場合、当社は当該拡大部分について本条に従い責任を負う。提供者側がリスクを抑えたい場合は、上限を過去6か月分または3か月分にする、サービスクレジットを唯一の救済とする範囲を広げる、第三者サービス免責を明確化する、無償版・ベータ版を別条項で現状有姿にする、個人情報漏えいの上限を通常上限の2倍または固定額にする、障害通知義務を合理的努力に限定する、といった修正が考えられます。
利用者側が保護を強めたい場合は、サービスクレジットを唯一の救済にしない、重大障害時の解除権を設ける、長時間停止時の代替費用を上限内で認める、データ消失・個人情報漏えい・秘密情報漏えいを高い上限または上限外にする、障害通知時間、原因報告、再発防止報告を明記する、外部クラウド障害でも提供者の設計・監視・冗長化義務を明記する、データ返還と移行支援を定める、といった修正が考えられます。
第○条（重大障害および損害賠償）
1. 「重大障害」とは、当社の責めに帰すべき事由により、本サービスの主要機能が連続○時間以上利用不能となり、または1暦月内に合計○時間以上利用不能となり、契約者の通常業務に重大な支障を生じさせる障害をいう。
2. 重大障害が発生した場合、当社は、契約者に対し、障害の内容、影響範囲、原因、復旧見込み、暫定対応策および再発防止策を、別紙SLAに定める期限内に報告する。
3. 重大障害が発生し、かつ当社が別紙SLAに定める復旧目標を著しく超過した場合、契約者は、本サービスの全部または一部を解除することができる。この場合、当社は、未利用期間に対応する利用料を返還する。
4. 当社が契約者に対して損害賠償責任を負う場合、その範囲は、当社の責めに帰すべき事由により契約者に現実に発生した合理的かつ直接の損害に限られる。ただし、重大障害に関しては、契約者が合理的に支出した代替手段の利用費用、データ復旧費用および顧客対応費用を含むものとする。
5. 当社の損害賠償責任は、請求原因のいかんを問わず、当該損害発生の原因となった事由が発生した日から遡って過去12か月間に契約者が当社に支払った利用料相当額を累積上限とする。ただし、秘密保持義務違反、個人情報の漏えい等、知的財産権侵害補償義務、および当社の故意または重大な過失により生じた損害については、別紙に定める特別上限または法令に従う。消費者向けSaaS、個人向けアプリ、個人課金サービスでは、「本サービスに関連してユーザーに生じたいかなる損害についても、一切責任を負いません」という表現は、消費者契約法との関係で無効となるリスクが高いです。消費者向けでは、法令上許容される範囲、現実に発生した直接かつ通常の損害、故意または重大な過失の例外、過去○か月間の利用料相当額などを用いて限定的・段階的に書く必要があります。
バックアップ、RPO・RTO、通知、原因報告、データ返還、移行支援、セキュリティ対応を連動させます。
SaaS障害のうち、サービス停止より深刻になりやすいのがデータ消失です。データ消失は、利用者の業務継続、監査対応、税務、労務、取引証跡、個人情報保護に直結します。責任制限条項だけでなく、バックアップの有無、頻度、保存期間、復元可能範囲、復元時間の目安、利用者自身のバックアップ義務、エクスポート機能、退会・解除後の保持期間、消去時期、復元失敗時の責任範囲を明記します。
当社は、別紙サービス仕様に定める範囲で、本サービスに保存された契約者データのバックアップを取得する。ただし、当社は、契約者データの完全性、永続的保存または任意時点への復元を保証するものではない。契約者は、自己の責任において、必要に応じて契約者データをエクスポートし、バックアップを取得するものとする。重要データを預ける場合は、RPO（Recovery Point Objective ― どの時点までのデータ復旧を目標とするか）とRTO（Recovery Time Objective ― どの程度の時間で復旧するか）を定めるべきです。
次の時系列は、障害通知・原因報告・再発防止報告の段階を整理したものです。金額だけでなく通知の遅れや説明不足が紛争を悪化させるため、いつ何を伝えるかを読み取ってください。
「認識後速やかに」「○時間以内」など、初動通知の起点と期限を定めます。
不確実な場合も暫定報告を認め、影響範囲を更新できる運用にします。
暫定復旧・本復旧の目安、復旧完了、残存影響の有無を伝えます。
重大障害に限定して、原因、時系列、影響、技術的・運用的対策、実施時期を報告します。
当社は、重大障害を認識した場合、契約者に対し、当社所定の方法により速やかに初動通知を行う。当社は、重大障害の復旧後、合理的な期間内に、障害の概要、影響範囲、原因、対応経過および再発防止策を記載した報告を行う。ただし、セキュリティ上の理由、第三者の秘密情報、他の顧客情報または法令上の制約がある場合、当社は報告内容の一部を省略または抽象化することができる。障害が継続する場合、利用者にとって最も重要なのは損害賠償ではなく、別サービスへ移行して業務を継続できるかです。重大障害が一定期間継続した場合の解除権、未利用期間分の利用料返金、データエクスポート形式、解除後のデータ取得期間、移行支援の有償・無償、データ削除時期、ログ・監査証跡の提供範囲を定めます。
重大障害が連続○営業日以上継続し、契約者の通常業務に重大な支障を生じさせる場合、契約者は、当社に書面で通知することにより、本契約の全部または影響を受けるサービス部分を解除することができる。当社は、解除日以降の未利用期間に対応する利用料を返還する。契約者は、解除日から○日間、当社所定の方法により契約者データをエクスポートすることができる。障害条項は、可用性、復旧、SLA、サービスクレジットが中心です。セキュリティインシデント条項は、機密性、完全性、個人情報、ログ、調査、通知、行政対応、フォレンジック、再発防止が中心です。個人データ、営業秘密、金融・医療・教育・公共・インフラ分野、SSO・ID管理・権限管理、決済情報・認証情報・位置情報・健康情報、大量データ処理を扱う場合は、別条項を設ける方が安定します。
提供者側・利用者側の確認事項と、法務・セキュリティ・会計・経営のレビュー観点を整理します。
責任制限条項は、提供者側と利用者側で見るべきポイントが異なります。双方の確認項目を並べることで、交渉時に何を譲歩し、何を残すべきかが見えやすくなります。
次の比較表は、提供者側と利用者側のチェック項目を整理したものです。条項の有利不利だけでなく、実際の運用や証跡まで確認することが重要であり、自社の立場に応じて不足している項目を読み取ってください。
| 観点 | 提供者側 | 利用者側 |
|---|---|---|
| 障害定義 | 完全停止、部分停止、性能劣化、データ障害、セキュリティ障害を区別します。 | 自社の重要機能がSLA対象になっているか確認します。 |
| SLA | 対象時間、除外時間、計画・緊急メンテナンス、クレジット計算を定めます。 | 稼働率だけでなく復旧時間・通知時間を確認します。 |
| 損害範囲 | 直接・通常損害、逸失利益、間接損害、第三者請求の扱いを明記します。 | サービスクレジットだけで救済が足りるかを確認します。 |
| 上限額 | 月額・年額・固定額、累積上限、請求原因を問わないことを明記します。 | 利用規模・リスクに比べて低すぎないかを確認します。 |
| 例外 | 故意・重大過失、秘密保持、個人情報、知財、支払義務を検討します。 | 故意・重大過失、秘密保持、個人情報、知財侵害の例外を確認します。 |
| データ・移行 | 漏えい等報告、本人通知、調査協力、優先順位を定めます。 | データ消失時の復旧義務、解除後の返還・移行支援を確認します。 |
弁護士・企業内弁護士・外部弁護士は、条項の有効性、民法・消費者契約法・個人情報保護法・独禁法・業法との整合、紛争時の立証、裁判上の解釈可能性を確認します。法務担当は、営業現場で使える雛形、交渉時の譲歩レンジ、個別契約との優先順位、顧客別特約の管理を担当します。
コンプライアンス・リスクマネジメント担当は、条項が顧客に誤解を与えないか、社内説明と実態が一致しているか、障害時の危機対応・広報・顧客通知・再発防止・保険対応を確認します。個人情報保護担当は、漏えい等発生時の報告・本人通知・委託先管理・安全管理措置・越境移転・サブプロセッサー管理を確認します。
内部監査・内部統制担当は、契約書上の約束が実際の運用で守られているかを確認します。SLAで99.9%稼働率を約束しているのに、監視ログやメンテナンス記録が不十分であれば、条項は機能しません。セキュリティ・IT運用担当は、バックアップ、冗長化、監視、脆弱性対応、ログ保存、インシデント通知義務が実態と一致しているか確認します。
公認会計士・税理士・経理財務担当は、返金、サービスクレジット、損害賠償、引当金、偶発債務、保険金、売上認識、顧客補償費用を確認します。経営者・CFO・CIO・CTOは、責任上限を価格、保険、セキュリティ投資、SRE体制、顧客信頼、競争力の問題として判断します。
一切免責、SLA矛盾、上限不明確、例外漏れ、業種別リスクを確認します。
よくある失敗は、サービス停止、データ消失、情報漏えい、セキュリティ事故をすべて含めて「一切責任を負わない」と書くことです。B2Bでも交渉上問題になり、B2Cでは消費者契約法上のリスクが高くなります。
次の一覧は、SaaS障害時の責任制限条項で起きやすい失敗を整理したものです。文言だけでなくSLA、上限計算、例外、データ、外部クラウド、通知運用がつながっていることが重要であり、どの失敗が自社の条項に残っていないかを読み取ってください。
通常停止、データ消失、情報漏えい、セキュリティ事故を同じ免責に入れると、無効リスクや交渉難が生じます。
稼働率99.9%を保証と書きながら、別条項でサービス提供を保証しないと書くと、事故時に解釈が割れます。
月額か年額か、過去何か月か、税込か税抜か、割引後か定価か、複数サービスのどの部分かが不明になります。
大企業、公共、金融、医療、個人情報を扱う案件では、例外を検討しない条項は修正されやすくなります。
業務証跡、法定保存、顧客対応、監査に影響するため、低額上限だけでは受け入れにくい場合があります。
提供者が選定した基盤について、冗長化、バックアップ、監視、復旧手順の設計責任が問題になります。
提供者側は、無制限責任は価格に反映されていないこと、SLA未達にはサービスクレジットを提供すること、重大障害では解除権やデータ返還を認めること、故意・重大過失・秘密保持・個人情報・知財は別扱いにすること、セキュリティ体制・バックアップ・監視・インシデント対応を説明すること、より高い上限が必要な場合はエンタープライズプランや追加料金で対応することを準備します。
利用者側は、抽象的に上限撤廃を求めるより、自社の重要業務に関わる機能、許容停止時間、必要な通知時間、復旧目標、報告内容、データ消失時の復旧範囲、個人情報漏えい時の調査協力、12か月分または特定事故の別上限、代替費用・復旧費用・顧客対応費用など証明可能な費用を具体化する方が実務的です。
金融・決済系SaaSでは、停止が取引機会、決済遅延、顧客損失、規制対応に直結します。医療・ヘルスケアでは、個人情報、要配慮個人情報、医療記録、研究データが問題になります。人事労務では、給与支払、労働時間管理、社会保険手続、マイナンバー、従業員個人情報が関係します。
EC・予約・マーケティングでは、停止が売上機会喪失に直結しやすいため、逸失利益の除外、繁忙期、キャンペーン期間、代替手段、通知時間が重要です。公共・教育では、住民、学生、保護者、教職員の情報を扱い、社会的説明責任が大きいため、通知、ログ、データ保全、セキュリティ、サービス終了時のデータ移行を重視します。
よくある疑問を一般情報として整理し、個別判断が必要な点を明示します。
一般的には、十分ではなく、B2Bでも交渉上受け入れられにくく、B2Cでは消費者契約法上のリスクが高いとされています。ただし、契約類型、顧客属性、サービスの有償・無償、取り扱うデータによって結論が変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、低額・補助的なSaaSでは1か月から3か月分、標準的B2Bでは6か月から12か月分、エンタープライズや重要業務では12か月分以上または特別上限が検討されることがあります。ただし、受領利用料、業務影響、保険、例外事由、交渉力によって結論が変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、B2Bの通常障害についてはサービスクレジットを主たる救済とする設計が検討されます。ただし、故意・重大過失、秘密保持違反、個人情報漏えい、知財侵害、重大障害、データ消失まで一律にサービスクレジットだけにすると、交渉上・法的評価上問題となる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、免責事由として定めることは可能とされています。ただし、提供者がクラウドを選定し、冗長化、バックアップ、監視、復旧設計を行う以上、無条件免責には慎重な検討が必要です。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、軽微なデータや利用者が容易に再作成できるデータであれば通常上限で足りる場合もあります。ただし、業務記録、個人情報、会計・税務・労務・医療・金融データを扱う場合は、バックアップ、復旧、特別上限、移行支援を別途検討すべき場面があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、故意・重大過失を責任制限の例外にすることが多く検討されます。ただし、契約類型、交渉力、サービスのリスク、保険、価格設計によって具体的な設計は変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、上限撤廃だけを求めるより、重大障害の定義、復旧目標、通知義務、データ返還、個人情報漏えい時の協力、解除権、代替費用、特別上限を具体化する方が実務的とされています。ただし、自社業務の重要度、既存の代替手段、データの性質、規制対応によって優先順位は変わります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、標準条項、許容修正、法務承認事項、経営承認事項を分ける運用が有効とされています。例えば、通常上限を12か月分まで上げる修正、個人情報漏えいを上限外にする修正、無制限責任を認める修正では承認レベルを変える設計が考えられます。ただし、事業規模、顧客層、保険、社内権限規程によって運用は変わるため、具体的な対応は専門家と社内関係部門で確認する必要があります。