クラウド障害で業務停止したとき

「損害賠償できるはず」と思っていたら…契約条項の落とし穴

「クラウドが半日止まって、受注システムもメールも全部ダウン。営業もコールセンターもストップして、相当な機会損失が出たはずです。これはさすがにクラウド会社に損害賠償してもらえますよね？」

—— 障害のあと、経営陣や現場から、情シス・法務にこう言われたことはないでしょうか。

ところが、実際に契約書やSLAを開いてみると、

• 「サービスクレジットが唯一かつ排他的な救済です」

• 「損害賠償額の上限は、過去◯ヶ月分の利用料金までです」

• 「間接損害・逸失利益については、一切責任を負いません」

といった条文が並んでいて、「え、これじゃほとんど何も請求できないのでは…？」という現実に直面することになります。

この記事では、

• 典型的な「損害賠償できるはず」が通らないパターン

• その背後にあるSLA・免責・責任限定条項の落とし穴

• 契約前後に最低限ここだけは見ておきたいポイント

を、クラウド利用側（ユーザー企業）の立場から整理します。

※個別の契約・事案によって結論は変わります。ここでは考え方の整理を目的としています。

1. 「損害賠償できるはず」が通らない典型パターン

まず、よくある期待と現実のギャップから。

想定している世界

• クラウド障害で丸一日システムが止まった

• そのせいで、数百万円〜数千万円の売上機会を逃した

• だから、その損害を丸ごとクラウド事業者に請求できるはずだ

—— こんなイメージを持っているケースが多いです。

実際の契約で書いてあること

ところが、クラウド・SaaSの利用規約やSLAでは、だいたい次のようなことが書かれています。UNITIS+1

• 障害時の補償はサービスクレジット（翌月以降の利用料値引き）だけ

• 「サービスクレジットは、障害に関する唯一かつ排他的な救済とする」

• それ以外の損害賠償を認めるとしても、

  • 賠償額の上限は「過去◯ヶ月分の利用料金」まで

  • 間接損害・逸失利益（失った売上など）は一切対象外

また、レンタルサーバの裁判例でも、

• 「24時間以上完全に利用できない場合に限って賠償する」

• 「賠償額の上限は、契約の月額料金まで」

という条項が有効と判断されたケースがあります。

つまり、

「業務が止まったから、その分全部もらえる」は、契約の世界では基本的に成立しない前提

で条文が組まれていることが多い、ということです。

2. 代表的な「契約条項の落とし穴」5つ

では、どんな条文が「落とし穴」になっているのか。よく出てくるものを5つに絞って説明します。

落とし穴① 「サービスクレジットが唯一の救済」

SLAの最後のほうによくある文言です。

• 「本SLA違反に対する利用者の唯一かつ排他的な救済は、　サービスクレジットの付与とする」

この一言で、

• SLAで定められた稼働率を割り込んだとしても

• 利用側が取れるのは「◯％分のクレジット」だけ

• それ以上の損害（失った売上など）は、原則としてSLAの枠外

という前提が作られています。

「SLA違反＝多額の損害賠償」ではなく、「SLA違反＝せいぜい来月の利用料が一部タダ」

というのが、クラウド世界の標準的な発想です。

落とし穴② 損害賠償額の上限（利用料◯ヶ月分など）

多くのSaaS・クラウド契約では、

• 損害賠償の上限を「過去◯ヶ月の支払額」まで

  • 例：直近12ヶ月分の利用料の総額

とする条項が置かれています。

レンタルサーバの判決でも、「賠償額の上限は月額料金まで」という規定が有効とされ、ユーザー側が主張する数百万円規模の損害のうち、ごく一部しか認められなかった事例があります。

BtoB取引では、

• 故意・重過失でない限り、この種の責任限定条項は有効とされることが多い

と解説されており、「払った利用料以上は基本返ってこない」と覚えておいたほうが現実的です。UNITIS+1

落とし穴③ 間接損害・逸失利益は「全部切られている」

クラウド障害で一番大きくなりがちなのは、

• 受注機会の損失

• 顧客離れによる将来の売上減

• 信用低下によるビジネスへの影響

といった間接的な損害・逸失利益です。

しかし契約書には、たいていこう書いてあります。

• 「特別損害・間接損害・逸失利益については、一切責任を負わない」

この一文で、

「本当に痛い部分」は最初から切り落とされている

と考えたほうがいい場面がほとんどです。

落とし穴④ 「◯時間以上の完全停止でないと対象外」

SLAの中には、

• 「完全に利用できない状態が◯時間以上続いた場合のみSLA違反とみなす」

• 「部分的な性能低下や、一部機能のみの停止は対象外」

という条件が含まれていることもあります。

レンタルサーバの裁判例では、

• 「24時間以上まったく利用できない状態」の場合に限って実費相当の賠償をする、という条項が問題となりました。

つまり、

• 5時間止まっても

• 日中数時間だけ繰り返し落ちても

契約上は**「SLA違反ではない」扱い**になることがある、ということです。

落とし穴⑤ 故意・重過失以外は、ほぼ免責

クラウド事業者側の契約では、

• 「当社の故意または重過失の場合に限り責任を負う」

• 「軽過失の場合は、責任を負わない」

という形の免責が置かれていることも少なくありません。

• 故意（わざと）

• 重過失（通常要求される注意義務を極端に欠くレベル）

といった状態は、そう簡単には立証できません。

多くの障害は、

• 設計ミスやテスト漏れ

• 運用上のヒューマンエラー

といった「軽過失」と整理されることが多いため、免責条項と責任限定条項がそのまま効いてしまう可能性が高いのが実情です。

3. 「じゃあ泣き寝入り？」——現実的に取り得る手段

ここまで読むと、

「結局、クラウドが止まっても、ほとんど何もしてもらえないのか」

という気持ちになるかもしれません。

とはいえ、まったく手段がないわけではありません。

3-1. 契約上きちんと取れるものは「取り切る」

• SLAに基づくサービスクレジット

• 範囲内での損害賠償（上限まで）

は、きちんと請求しきるべきです。

• 対象となる障害がSLA条件を満たすか

• クレジット申請に期限がないか

を確認し、ルールに従って淡々と請求することが、ユーザー企業としての最低限の対応になります。

3-2. それ以上を求めるなら、「交渉」か「設計」で取り返す

契約上は難しくても、

• 大規模障害・長時間停止など、社会的に大きな問題になっているケース

• 複数社からまとまったクレームが出ているケース

では、個別の交渉で追加の補償や条件見直しを引き出せることもあります。

ただし、それを期待してビジネスを組むのは危険なので、

• アーキテクチャ設計（多重化・代替手段の用意）

• 自社SLA・契約条件（自分たちの顧客に対してどこまで約束するか）

のほうで、リスクをコントロールしておくことの方が現実的です。

4. 障害が起きる「前」に最低限やっておきたい契約チェック

実は、障害が起きたあとに契約を読み始めても、できることはかなり限られます。

そうなる前に、少なくとも次の4点だけは押さえておきたいところです。

4-1. 「うちとして許容できる損害額」と「責任上限」のギャップ

• 1日止まったら、どれくらいの損害が出るのか

• 自社として受け入れ可能な「1回あたりの損失ライン」はどこか

をざっくりでも試算したうえで、

• クラウド側の**責任上限（◯ヶ月分の利用料）**と

• 自社の想定損害の規模

を比較します。

もし、

• 利用料：月30万円

• 12ヶ月分の責任上限：360万円

• 実際の1日分の売上：1,000万円

という世界なら、

「クラウド側からは最大360万円まで」「残り640万円は自社のリスク」

という前提で設計・経営判断をする必要があります。

4-2. 自社のSLA・契約が「クラウド側より手厚くなりすぎていないか」

SaaSやクラウド上にサービスを構築している場合、

• 自社が顧客に約束しているSLA

• 自社の免責・責任限定条項

が、クラウド事業者のそれよりもはるかに厳しくなっていることがあります。

• 顧客には「24時間以内に復旧」「機会損失も補償」と約束

• でもクラウド側は「クレジット＋利用料◯ヶ月分まで」

という状態だと、障害時に逆ざやリスクを抱えることになります。

4-3. 「どのレベルの障害までが“自己責任”か」を社内で共有する

契約を読み込んだうえで、

• このサービスが止まったら、どこまでクラウド側、どこから自社のリスクか

• どんな障害ならクレジット／賠償請求対象になり得るか

• それでも穴がある部分は、設計・保険・BCPでどうカバーするか

を経営層・情シス・法務で共有しておくだけでも、「いざ障害」が起きたときの混乱をかなり抑えられます。

4-4. 営業資料・提案書に書きすぎていないか

見落とされがちなのが、

• 営業資料

• 提案書

• Webサイト

に書いているサービス説明の文言です。

• 「止まらないシステムです」

• 「万が一でも安心の補償」

など、法務チェックを経ていない売り文句が、実際の契約よりもかなり手厚いことがあります。

障害時にここを持ち出されると、

「説明と実態が違う」として信頼問題や交渉上の不利に繋がる

ことも多いので、契約条項と大きく矛盾しない表現に揃えておくことが大切です。

5. 「クラウド障害で業務停止」に備える、現実的なスタンス

最後に、情シス・法務としてどんなスタンスでクラウドと向き合うか、整理しておきます。

1. 「止まらないクラウド」は存在しない前提に立つ

   • 契約やSLAは、「止まることを前提にどう扱うか」のルール

2. 賠償で取り返す発想から、設計と契約で“被害を限定する”発想へ

   • 多重化・バックアップ・代替手段

   • 自社SLA・免責条項の設計

3. いざというときに取り得る手段（クレジット請求など）は、感情ではなく冷静に“やるべきこととして”回す

4. 契約を読んでからサービスを選ぶ文化を、社内に根付かせる

   • 「とりあえず便利だから」「大手だから安心」だけで選ばない

山崎行政書士事務所がお手伝いできること

山崎行政書士事務所では、クラウド法務・情報セキュリティを専門として、

• AWS・Azure・各種SaaSのSLA・免責・責任限定条項の読み解きとリスク整理

• 自社サービス（SaaS・業務システムなど）の利用規約・SLA作成／見直し（クラウド側とのギャップ分析付き）

• 「クラウド障害が起きた場合に、うちとして何が言えるか」を整理した経営層向けの簡易メモ・社内説明資料の作成

• 実際に障害が発生した際のクレジット請求・契約交渉の方針整理（法務メモの作成）

などを行っています。

「クラウドが止まったとき、どこまでがクラウド会社の責任で、どこからがうちのリスクなのか、モヤモヤしたままになっている」

という状態であれば、一度

• ご利用中のクラウドサービス名

• おおよその利用規模・月額費用

• 自社サービスの有無（SaaS提供など）

を教えていただければ、現実的な前提のもとでのリスク整理と、契約・設計での手当て案を一緒に組み立てていくことができます。

静岡県内の中堅企業さまには、オンラインでも訪問でも対応可能です。