クラウド障害が起きたとき、契約上どこまで責任を問えるのか？

――SLAと免責条項の読み方ガイド

「クラウドが半日落ちて、システムが止まった。これ、クラウド事業者に損害賠償を請求できますよね？」

情シス・法務の現場で、障害が起きたあとに必ず出てくる会話です。

ところが、AWS・Azure・各種SaaSのSLAや利用規約をよく読むと、

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

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

といった条文がズラっと並んでいます。

結局、障害が起きたとき、契約上どこまで責任を問えるのか？

この記事では、静岡県内の中堅企業で一人情シス／総務法務をされている方を想定して、

• SLAと免責条項がどんな役割をしているのか

• クラウド障害時に実際に取り得る「契約上の手段」

• 契約を見るときにチェックすべきポイント

を、法律と実務の両面から整理します。

※以下は一般的な解説です。具体案件では契約内容や事実関係次第で結論が変わります。

1. 「SLAがある＝ユーザーが守られている」わけではない

まず押さえておきたいのは、

SLAは必ずしも「ユーザーを守るための条文」ではない

という現実です。

SLAってそもそも何？

SLA（Service Level Agreement）は、

• 稼働率（例：月間 99.9%）

• 応答時間

• 障害対応の目安

など、サービス品質に関する約束をまとめたものです。

クラウド事業者のSLAを見ると、

• 「月間稼働率が◯％を下回ったら◯％のサービスクレジット」

• 「クレジットが**唯一の救済手段（sole and exclusive remedy）**である」

と書かれていることが多く、AWSやAzureのSLAにも同様の文言が見られます。

つまりSLAは、

• 一定のサービスレベルを約束する代わりに

• その範囲内のトラブルへの対応を「サービスクレジット」に限定する

という、**事業者側の「責任をコントロールするためのツール」**でもあるわけです。

2. 「99.9%の稼働率」と「現実の止まる時間」

よく見かける「月間稼働率 99.9%」は、数字だけ見るととても高く見えます。

でも、30日（約43,200分）の1ヶ月で換算すると、

• 99.9% ＝ 約 43分 の停止まではSLA範囲内

• 99.99% ＝ 約 4.3分 の停止まではSLA範囲内

というイメージになります。

さらにSLAでは、多くの場合、

• 計測対象になるのは「完全に利用不可」の時間のみ

• 計画メンテナンス、利用者側のミス、ネットワーク障害等は除外

• 各リージョン・各サービスごとに別々に計算

といった細かい条件が決められています。

ポイント「99.9%だからほとんど止まらない」は、あくまでクラウド基盤の一部の話であり、ユーザーの業務全体から見た「体感停止時間」とは必ずしも一致しません。

3. 障害が起きたとき、SLA上「できること」は？

① まずは「サービスクレジット」の仕組みを確認

AWSやAzureなどのSLAでは、

• SLAを下回った場合に

• 利用料金の◯％をサービスクレジットとして付与する

という仕組みが一般的です。

特徴としては：

• 自動ではなく、ユーザー側から申請が必要なことが多い

• クレジットは今後の利用料金から控除されるだけで、現金返金ではない

• クレジット額は、あくまでその月の利用料金が上限

SLAの末尾によくある一文がこれです：

「本SLA違反に対する利用者の唯一かつ排他的な救済は、本SLAの条件に従ってサービスクレジットを受け取ることとする。」

この文言があると、

• サービスが止まった

• 仕事ができず、大きな機会損失が出た

としても、基本的にはクレジット以上の請求は難しい、という方向に話が傾きます。

② では、損害賠償請求は完全にムリ？

ここで効いてくるのが、**利用規約の「免責条項」「責任限定条項」**です。

多くのSaaS利用規約では、

• 間接損害・逸失利益については一切賠償しない

• 損害賠償額の上限は、「過去12ヶ月の利用料金の総額」などに限定する

という条文が置かれています。

日本の裁判例（レンタルサーバー障害でデータが消失した事件）でも、

• 「連続して24時間以上サービスが全く利用できない場合のみ責任を負う」

• 「損害賠償額は月額料金を上限とする」

という免責・責任限定条項を有効とし、ユーザーの請求を棄却したケースがあります。

また、クラウド（SaaS）契約の解説でも、

• BtoBサービスにおいては、免責・責任限定条項は原則有効

• 故意・重過失についてまで免責することは信義則上認められにくいが、軽過失レベルの障害については免責・限定が機能し得る

と説明されています。

まとめると ふつうの障害（軽過失レベル）なら → SLAクレジット＋上限付きの損害賠償が基本ライン 故意や重過失レベルの不正・管理不行き届きなら → 免責条項が無効・制限される余地もある

というイメージです。

4. SLAを読むときのチェックポイント

じゃあ、実際に契約書やSLAを手にしたとき、どこをどう見ればいいのか？

① 「サービスレベル」そのもの

• 月間稼働率の数字（99.5％／99.9％／99.99％など）

• 計測単位（1サービス単位・リージョン単位・全体平均）

• ダウンタイムの定義（完全停止のみ／一部機能停止も含む？）

チェック例 「99.9％」と書いてあるが、それはどのサービス単位で？ 計画メンテナンスは完全に除外か？ 一時的な性能低下はダウンタイムにカウントされるか？

② 「除外事由」（何がSLAの対象外か）

SLAの中には、

• 利用者の設定ミス

• 利用者ネットワーク側の障害

• DDoS攻撃など、外部要因

• フォースマジュール（天災等）

といった事業者の責任外とされる事由が細かく定められています。

ここが多いほど、「SLAが適用されるケース」は絞られる＝ クレジット請求できる場面も狭くなります。

③ 「サービスクレジット」の条件

• どの程度SLAを下回ると、何％のクレジットが出るか

• クレジットは「自動付与」か、「ユーザー申請ベース」か

• 申請期限（例：障害発生から◯日以内）

• クレジットの上限（その月の利用料金まで、等）

AWS・Azure等でも、指定の窓口からの申請がなければクレジット対象としないという規定が一般的です。

④ 「sole and exclusive remedy（唯一かつ排他的な救済）」の有無

英語SLAでよく出てくる魔法の一文がこれです。

「Service Credits are Customer’s sole and exclusive remedy for any failure to meet any Service Level.」

これがあると、

• SLA違反についてはクレジット以外の請求は原則できない

• 重大な障害でも、原則としてクレジット以上は請求できない

という解釈につながります。

クラウド契約の実務解説でも、この「sole and exclusive remedy」付きSLAは実はベンダーを守る条項だ、という指摘がされています。

⑤ 別途「責任限定条項」がどうなっているか

SLAとは別に、利用規約本体に、

• 免責条項

• 責任限定条項（上限）

• 間接損害・逸失利益の除外

が置かれていることがほとんどです。

要チェックポイント 賠償額上限： 「直近1〜12ヶ月分の利用料金」が多い 除外される損害： 逸失利益・間接損害・特別損害はほぼ常に除外 例外の有無： 故意・重過失、機密保持違反、個人情報漏えいなどは上限・免責の対象外とする条文になっているか

5. 実務的には「どこまで戦える」のか？パターン別イメージ

パターンA：よくある数時間の障害

• 稼働率が一時的に落ちたが、後日見るとSLAぎりぎりクリア

• あるいは「除外事由」に該当する扱い

→ SLAクレジットも出ない／出てもごくわずか→ 損害賠償請求も、免責条項・上限条項でかなり難しい

パターンB：SLAを明確に下回る大規模障害

• 数時間〜半日以上の全停止

• 公式に「SLA違反」を認めるケース

→ 契約どおりにクレジット請求（+自社の顧客向け対応）→ それ以上の損害賠償は、

• 自社の契約（上限）

• 間接損害除外に阻まれることが多い

パターンC：明らかな管理不行き届き・重過失レベル

• 長期間、既知の重大な脆弱性を放置

• セキュリティ標準から大きく外れた運用

など、故意・重過失レベルの事情があれば、免責条項・責任限定条項の適用が否定される余地があります。

ただし、このレベルはハードルが高く、裁判等を視野に入れた慎重な検討が必要です。

6. 「障害が起きる前」にやっておくべきこと

正直なところ、障害が起きてから契約を読み始めても、できることは限られます。

だからこそ、“平時”にやっておきたいのは次の3つです。

① クラウド頼みになりすぎないアーキテクチャを組む

• 単一リージョン・単一サービスに頼りきりにならない

• 業務上クリティカルなシステムは、

  • 冗長構成（複数AZ／リージョン）

  • 代替手段（オフライン運用・バックアップ環境）を検討する

MicrosoftやAWSも、SLA解説の中で、アーキテクチャ側での冗長化・フェイルオーバー設計を前提としていることが多いです。

② 「自社の顧客への約束」がクラウドSLAを超えていないか確認

自社がクラウド上でサービスを提供している場合、

• 自社のSLA・利用規約でクラウド事業者より高い稼働率や責任を約束していないか

は重要な確認ポイントです。

SaaS事業者向けの利用規約解説でも、

• BtoBサービスでは免責・責任限定条項が重要

• しかし、自社が負うリスクとクラウド基盤のSLAが噛み合っていないと危険

と指摘されています。

③ 法務・情シスで「SLAと免責条項の読み合わせ」をしておく

• 法務：

  • 責任限定・免責の範囲

  • 故意・重過失の扱い

  • 個人情報・機密情報漏えい時の例外有無

• 情シス：

  • アーキテクチャと実運用とのギャップ

  • ログ・監視体制

  • 障害時に取れるオペレーション

YS法律事務所などの解説でも、SLAは契約実務・技術運用・組織体制の3つをセットで考えるべきとされています。

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

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

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

• 自社サービス（SaaS・業務システム）のSLA・利用規約作成時の「現実的な責任ライン」設計

• 取引先からの情報セキュリティチェックシート・クラウド利用説明依頼に対する回答文案作成

• クラウド障害発生時の契約上取り得る対応（クレジット請求・損害賠償・契約見直し）の整理

といったご相談を多くいただいています。

「クラウド障害が起きたとき、うちとして何が言えて、何は言えないのか整理したい」

という段階からでも大丈夫です。

静岡県内の企業さま向けには、オンライン・訪問どちらでも対応可能です。

お問い合わせの際に、

• 利用しているクラウドサービス名

• 自社がお客様に約束しているSLA（あれば）

を教えていただければ、

• クラウド事業者のSLA／免責とのギャップ

• 障害時に想定されるリスクと、契約・運用で埋めるべきポイント

を、法務＋技術の両面から分かりやすく整理したレポートをご提案します。