SaaS・クラウド・保守運用契約で、99.9%という数字をどう定義し、停止時間、除外事由、サービスクレジット、損害賠償、責任制限へつなげるかを整理します。
99.9%という数字だけでなく、測定対象、分母、停止時間、補償、証拠を一体で設計します。
99.9%という数字だけでなく、測定対象、分母、停止時間、補償、証拠を一体で設計します。
SLAは、単に「稼働率99.9%」を置く書類ではありません。クラウドサービス、SaaS、システム運用、保守運用契約、データ処理委託などで、サービス水準とリスク配分を明確にする契約条項です。
SLA設計で最初に整理すべき5つの問いを一覧にします。この一覧は、どこを測り、どの時間を分母にし、何を停止と見て、補償をどの性質にし、どの証拠で請求するかを確認するために重要です。左から順に読むと、稼働率の数字より前に決めるべき論点が分かります。
サービス全体ではなく、API、認証、決済、管理画面など、利用者に重要な機能を特定します。
24時間365日、営業時間内、特定リージョン、テナント単位などで、同じ99.9%の意味が変わります。
完全停止だけでなく、著しい遅延、エラー率上昇、重要機能の利用不能を含めるかを定めます。
サービスクレジット、損害賠償、賠償額の予定、解除権、再発防止義務を区別します。
監視ログ、障害報告、請求期限、除外事由、顧客側ログの扱いを運用できる形にします。
実際の契約交渉、約款作成、損害賠償請求、行政規制対応、紛争対応では、契約内容、業種、サービス仕様、当事者の属性、適用法、裁判管轄、損害内容、証拠状況で結論が変わります。このページは一般的な情報提供として整理しています。
契約上の保証、社内目標、測定指標を混同しないことが、実効性あるSLAの出発点です。
SLA、SLO、SLIは似ていますが役割が異なります。ここでは、契約上の約束、社内運用目標、測定する指標を分けて示します。この違いを読むことで、顧客向けに約束する水準と、社内で守るべき余裕値を切り分けられます。
| 用語 | 意味 | 実務での位置づけ |
|---|---|---|
| SLA | サービス提供者と顧客が合意するサービス水準、測定方法、責任、報告、是正、補償の文書または条項です。 | 顧客向けの契約上の保証です。条件付きのコミットメントとして設計されることが多く、全損害の補償を意味するとは限りません。 |
| SLI | 可用性、レイテンシ、エラー率、スループット、耐久性、RTO、RPO、サポート応答時間など、サービス水準を測る指標です。 | 「良いイベント数を総イベント数で割る」など、測定可能な形に落とし込みます。 |
| SLO | SLIに対する目標値です。月間API成功率99.9%以上、P95レイテンシ300ms以下、重大障害の初回応答30分以内などです。 | 多くの場合は社内目標です。顧客向けSLAより厳しく置き、違反前に運用改善へつなげます。 |
たとえば顧客向けSLAが99.9%であれば、社内SLOを99.95%または99.99%に置く設計が考えられます。SLAは「絶対に停止しない保証」ではなく、契約全体の責任制限、解除、監査、情報セキュリティ、個人情報保護、事業継続計画と整合させる必要があります。
可用性は技術の希望値ではなく、停止時の損害、代替手段、価格とのバランスから決めます。
稼働率水準は、技術的な見栄えではなく、何の業務を支えるサービスかで変わります。次の一覧は、高い可用性が求められる業務と、同じ水準を求めない設計もあり得る業務を対比するものです。重要なのは、右側の業務を軽視することではなく、費用とリスクに応じて層別化することです。
| 高い可用性を検討する領域 | 同一水準を求めない場合がある領域 |
|---|---|
| 決済、注文、予約、認証、本人確認、金融取引、送金、与信 | 社内ナレッジ、分析用ダッシュボード、非本番環境 |
| 医療、介護、救急、薬局、検査管理、行政・公共サービス | 検証環境、β機能、無料機能、遅延許容のレポート |
| 工場制御、物流、在庫、サプライチェーン、BtoB基幹システム | 一部管理画面設定、低頻度の補助機能、手作業代替が可能な機能 |
停止時の損害は、売上機会の喪失、顧客への返金・補償、契約違反による自社の違約金、業務停止による人件費・外注費、データ消失・復旧費用、行政対応、個人情報漏えい時の通知・公表費用、ブランド毀損、株主・取締役会への説明、利用者からの請求などに広がります。
停止時の影響を段階別に整理すると、どの水準に投資すべきかが見えます。この時系列は、停止直後の業務影響から、顧客対応、経営説明、監査・規制対応へ広がる順番を示します。前半ほど初動、後半ほど説明責任と再発防止の重さを読み取ってください。
注文、決済、認証、問い合わせ、工場や物流の処理が止まり、手作業代替の有無が問われます。
返金、違約金、外注費、顧客説明、サポート増員、障害報告の準備が発生します。
行政報告、取締役会、監査、株主、親会社への説明が必要になり、SLAの証拠設計が効いてきます。
高い稼働率は無料ではありません。冗長構成、複数リージョン、監視、オンコール、障害訓練、バックアップ、セキュリティ対策、容量管理、DDoS対策、サポート体制が必要です。追加の「9」を増やすほどコストが増えるため、SLA水準は費用対効果として決めるべきです。
式そのものより、対象期間、対象機能、短時間障害、部分障害、メンテナンス除外の書き方が重要です。
月間稼働率は、対象期間の総分数からSLA上の停止時間を引き、対象期間の総分数で割って100を乗じる形で表します。リクエストベースでは、正常に処理されたリクエスト数を総リクエスト数で割って100を乗じます。
分母の置き方によって、同じ99.9%でも保証水準は変わります。次の表は、何を分母にするか、どの用途で使うかを整理するものです。左列は測定単位、中央列は契約上の意味、右列は使いやすいサービス類型として読んでください。
| 分母の設計 | 内容 | 主な用途 |
|---|---|---|
| 24時間365日 | 月間または年間の全時間 | SaaS、クラウド、EC、金融、公共サービス |
| 営業時間内 | 平日9時から18時など | 社内業務システム、BtoBサポート |
| 特定時間帯 | ピーク時間、取引時間、入試期間など | 金融、試験、キャンペーン、予約受付 |
| リクエスト数 | API成功率、トランザクション成功率 | API、決済、認証、検索 |
| テナント・リージョン・重要機能単位 | 顧客環境、地域、注文・決済・ログインなど | マルチテナントSaaS、クラウド、業務影響の大きい機能 |
停止時間の定義は、紛争を避けるうえで最も重要です。次の比較は、完全停止だけを見る設計と、遅延・部分障害・重要機能の利用不能まで見る設計の違いです。列ごとに対象範囲が広がるため、補償リスクと利用者保護のバランスを読み取ってください。
| 論点 | 狭い定義 | 広い定義 | 実務上の注意 |
|---|---|---|---|
| アクセス不能 | 完全に接続できない状態のみ | 一定割合以上の失敗や重要機能の利用不能も含める | 認証、決済、保存、検索など重要機能を別紙で特定します。 |
| 遅延 | 遅延は原則として停止に含めない | 著しい遅延で実質利用不能なら含める | 閾値、継続時間、測定点を定めます。 |
| 部分障害 | 全利用者への影響のみ | 一部地域、一部テナント、一部デバイスも対象にする | 影響を受けた環境の料金を基礎額にする設計もあります。 |
| 短時間障害 | 1分未満や断続障害を除く | 短時間でも反復すれば評価する | 商用クラウドでは1分以上連続などの線引きがよく使われます。 |
計画メンテナンスは多くの場合停止時間から除外されますが、無制限に除外すると実質的な可用性が下がります。7日前、14日前、30日前などの事前通知、深夜・休日などの実施時間帯、月4時間以内や四半期8時間以内などの上限、緊急メンテナンスの通知、繁忙期の制限を定めます。
除外事由には、利用者の設定ミス、端末・ネットワーク障害、利用条件違反、第三者サービス障害、通信事業者障害、計画・緊急メンテナンス、DDoS攻撃、不可抗力、β版・無償版・検証環境、サポート対象外バージョンなどがあります。ただし広すぎる除外はSLAを空文化させます。
稼働率の差は小さく見えても、停止できる時間に換算すると運用体制の差になります。
稼働率の「9」の数は、停止できる時間の短さを意味します。次の表は24時間365日稼働を前提に、30日、31日、1年で許容される停止時間を並べたものです。行を下へ進むほど水準が厳しくなり、99.9%から99.99%への差が運用体制を大きく変えることを読み取ってください。
| 稼働率 | 30日あたりの許容停止時間 | 31日あたりの許容停止時間 | 1年あたりの許容停止時間 |
|---|---|---|---|
| 99.0% | 7時間12分 | 7時間26分24秒 | 3日15時間36分 |
| 99.5% | 3時間36分 | 3時間43分12秒 | 1日19時間48分 |
| 99.9% | 43分12秒 | 44分38秒 | 8時間45分36秒 |
| 99.95% | 21分36秒 | 22分19秒 | 4時間22分48秒 |
| 99.99% | 4分19秒 | 4分28秒 | 52分34秒 |
| 99.999% | 26秒 | 27秒 | 5分15秒 |
停止時間の差を割合の比較として見ると、99.9%から99.99%への変更は月間約43分から約4分へ許容時間を縮める判断です。次の横棒グラフは30日あたりの許容停止時間を、99.0%を基準にした相対的な長さで示します。棒が短いほど停止できる余地が少なく、必要な監視・冗長化・復旧訓練が重くなります。
同じサービス内でも機能ごとの重要度は異なります。次の表は、一律SLAではなく機能別SLAを置く場合の見方です。重要度が高い機能ほど高い稼働率や即時報告が必要になり、低い機能では営業時間内サポートや対象外も選択肢になることを読み取ってください。
| 機能 | 重要度 | SLA設計例 |
|---|---|---|
| 認証・ログイン | 高 | 月間99.9%または99.99% |
| 決済・注文確定 | 高 | 月間99.95%または99.99%、障害時の即時報告 |
| データ閲覧 | 中から高 | 月間99.9% |
| レポート出力 | 中 | 99.5%、遅延許容あり |
| 管理画面の一部設定 | 中から低 | 営業時間内サポート中心 |
| β機能 | 低 | SLA対象外 |
将来料金の控除、賠償額の予定、損害賠償併存型は、法的性質と実務効果が異なります。
サービスクレジットは、SLA未達時に将来の利用料金から一定額を控除する制度です。クラウド事業者の標準SLAでは一般的ですが、利用者の実損を十分に補填しないことがあります。月額10万円のSaaSで10%クレジットなら補償額は1万円にすぎず、ECサイトの売上機会数百万円の喪失とは釣り合わない場合があります。
補償の法的性質を比較すると、交渉で何を得て何を制限するのかが明確になります。次の表は、サービスクレジット型、賠償額予定型、損害賠償併存型の違いを示します。利用者側の利点と提供者側の利点、注意点を横に読み、責任制限条項との整合を確認してください。
| 類型 | 法的性質 | 利用者側の利点 | 提供者側の利点 | 注意点 |
|---|---|---|---|---|
| サービスクレジット型 | 将来料金の控除 | 請求しやすい | 上限管理しやすい | 実損補填になりにくい |
| 賠償額予定型 | 民法420条上の賠償額予定 | 損害立証を簡略化できる | 金額を予見可能にできる | 過大・不合理な内容は争点化し得る |
| 損害賠償併存型 | クレジットとは別に損害賠償 | 重大損害に対応しやすい | 重要顧客向けに柔軟 | 責任上限・損害範囲の交渉が必要 |
民法415条は債務不履行による損害賠償、民法416条は通常損害・予見可能な特別損害、民法420条は賠償額の予定と違約金の推定を扱います。SLA未達をどの義務違反として評価するか、帰責性があるか、損害との因果関係があるか、損害範囲がどこまで認められるかを条項間で整合させます。
サービスクレジットの水準は、未達の程度に応じて段階化されることが多いです。次の表は検討例であり、左列の月間稼働率が下がるほど右列の意味が重くなります。深刻な未達ではクレジットだけでなく、解除、改善義務、責任制限の例外も検討することが重要です。
| 月間稼働率 | サービスクレジット例 | 実務上の意味 |
|---|---|---|
| 99.9%以上 | 0% | SLA達成 |
| 99.0%以上99.9%未満 | 10% | 軽微から中程度の未達 |
| 95.0%以上99.0%未満 | 25%または30% | 重大な未達 |
| 95.0%未満 | 50%または100% | 深刻な未達、解除・改善義務を検討 |
クレジットの基礎額は、当月の基本利用料、影響を受けた機能の料金、影響を受けた顧客環境の料金、年額料金の月割額、従量課金額、固定違約金などが考えられます。利用者にとっては障害影響に応じて補償が増えるか、提供者にとっては補償額が料金・保険・利益率と整合するかが重要です。
定義、稼働率、クレジット、請求手続、除外事由、損害賠償の関係を別紙まで落とし込みます。
SLA条項は、対象サービス、対象機能、対象期間、稼働率または成功率の定義、停止時間、除外事由、測定方法、障害通知、補償、請求手続、是正措置、解除権、責任制限、証拠保全、変更手続を含めて作ります。
条項の作成順序を図で見ると、数字を決める前に定義と測定を固め、最後に請求・責任制限・変更手続へつなげる必要が分かります。次の判断の流れは上から下へ進む順番を示し、途中で分岐する箇所は補償だけで足りるか、例外を置くかを検討する場面です。
対象サービス、対象機能、対象期間、測定単位を特定します。
完全停止、遅延、部分障害、計画メンテナンス、不可抗力、顧客起因を整理します。
サービスクレジットを唯一の救済にするか、重大事由の例外を置くかを検討します。
期限、ログ、提出先、付与時期、上限を定めます。
故意・重過失、情報漏えい、データ消失、秘密保持義務違反などを別扱いにします。
定義条項では、月間稼働率を「対象期間の総分数から停止時間を控除した時間を対象期間の総分数で除し、100を乗じた割合」とし、停止時間は「通常の利用環境から対象機能へアクセスまたは利用できない状態が、連続して1分以上継続した時間」などと書きます。ただし1分未満の断続障害、著しい遅延、部分障害は別紙でさらに定義します。
稼働率とクレジットの別紙では、対象機能をログイン機能、データ閲覧機能、API送受信機能などに分け、目標月間稼働率を99.9%以上、99.0%以上99.9%未満で10%、95.0%以上99.0%未満で30%、95.0%未満で100%などと段階化し、翌月以降の利用料金から控除する方法を定めます。
請求手続では、停止発生月の翌月末日までなどの期限、発生日時、影響機能、影響ユーザーまたは拠点、エラー内容、利用者が保有するログ、スクリーンショット、エラーコードなどを提出することを定めます。提供者の障害報告が遅れた場合に期限がいつから進むかも検討します。
除外事由では、利用者の設備・端末・ネットワーク・認証基盤・設定、契約違反、計画メンテナンス、緊急メンテナンス、不可抗力、通信事業者障害、β版・試験版・無償版・検証環境を扱います。計画メンテナンスは月間4時間を上限とするなど、除外の上限を置くとバランスを取りやすくなります。
同じ条項でも、利用者は内部統制と説明責任、提供者は運用能力と責任上限を見ています。
交渉で対立しやすい論点を並べると、利用者側と提供者側が見ているリスクの違いが分かります。次の表は、左から論点、利用者側の主張、提供者側の主張、実務的な落としどころを示します。最後の列を読むと、数字の押し合いではなく、機能・定義・証拠・例外で調整する方向が見えます。
| 論点 | 利用者側の主張 | 提供者側の主張 | 実務的な落としどころ |
|---|---|---|---|
| 稼働率 | 99.99%以上を求める | 標準は99.9% | 重要機能のみ高水準にする |
| 停止定義 | 遅延・部分障害も含める | 完全停止のみ | 重要機能・閾値を定義する |
| 除外事由 | 狭くしたい | 広くしたい | 計画停止・顧客起因・不可抗力を具体化する |
| 補償 | 実損賠償も求める | クレジットに限定したい | 重大事由のみ例外を設ける |
| 請求期限 | 長くしたい | 短くしたい | 障害報告日から30から60日など |
| 証拠 | 提供者ログを求める | 顧客ログを求める | 双方ログと障害報告で判断する |
| 長期停止 | 解除・移行支援を求める | 標準約款では限定 | 一定時間超で解除・移行支援を規定する |
利用者側は、SLAを障害時の補償だけでなく、ベンダー管理、内部統制、取締役会への説明、規制対応の資料として使います。停止できない機能、代替手段、顧客への責任、監査・規制当局への説明、障害ログ、データ消失・情報漏えいの別扱い、長期停止時の解除・移行・データ返還を確認します。
提供者側は、SLAを品質保証であると同時に、責任上限、価格設計、運用能力の約束として管理します。運用実績、社内SLO、監視・ログ、クレジット原資、基盤クラウドや外部APIとの整合、複数顧客同時障害の総額リスク、障害報告と再発防止の実行可能性を確認します。
マルチクラウド、下請、再委託がある場合の責任分担は、複数の関係者でどこまでSLA責任をつなげるかを整理する必要があります。次の一覧は、再委託を許すか、監督するか、障害を除外するか、顧客にクレジットを渡すかなど、契約上の確認点を並べています。各項目は、個人情報、金融、医療、公共領域では規制・監査・説明責任にもつながります。
クラウド、監視、セキュリティ、回線、外部API、決済代行、認証基盤を使う場合、再委託の可否と事前承諾を定めます。
提供者が再委託先の選定、監督、情報セキュリティ、個人情報管理にどこまで責任を負うかを整理します。
再委託先障害をSLA除外とするか、提供者のSLA違反に含めるか、クレジットを顧客へ渡すかを決めます。
ログ、障害報告書、監査証跡を再委託先から取得できるかを確認します。
可用性、情報セキュリティ、データ復旧、会計処理、監査証跡を別条項と連動させます。
SLAで扱う可用性は、情報セキュリティの機密性、完全性、可用性のうち可用性に関係します。しかし情報漏えい、改ざん、データ消失、権限侵害、ランサムウェア被害は、単なる稼働率未達とは異なります。
データ復旧に関する指標は、SLAの稼働率とは別に読まないと、短時間停止でも重大損害を見落とします。次の表は、RTO、RPO、バックアップ頻度、リストアテストの意味と契約上の例を示します。列を横に読むと、いつまでに復旧するか、どの時点のデータへ戻せるか、実際に復元できるかを区別できます。
| 指標 | 意味 | 契約上の例 |
|---|---|---|
| RTO | どれくらいの時間で復旧するか | 重大障害発生から4時間以内に復旧努力 |
| RPO | どの時点のデータまで復旧するか | 最大24時間前までのデータを復旧可能 |
| バックアップ頻度 | どれくらいの頻度で保存するか | 日次、時間ごと、リアルタイム複製 |
| リストアテスト | 実際に復元できるか | 四半期ごとに復旧訓練 |
個人情報漏えい時は、本人通知、行政報告、調査費用、フォレンジック費用、コールセンター費用、再発防止、損害賠償、信用毀損が発生し得ます。漏えい等発見時の通知期限、調査協力、ログ提供、費用負担、当局対応、本人対応、再委託先管理、責任制限の例外をSLAとは別に定めます。
会計・税務・内部統制の観点では、サービスクレジットを売上値引き、返金、将来サービスへの充当、損害賠償、違約金に近い処理として整理する必要があります。提供者側では売上控除、請求書表示、年払い・前受収益、複数月障害、引当金、監査法人説明を確認します。利用者側では費用減額、損害賠償収入、部門配賦、取引先への再請求、税務上の課税関係を確認します。
内部統制として必要な証跡を並べると、SLAが契約書に書いただけでは機能しないことが分かります。この一覧は、契約保管から障害通知、監視ログ、クレジット処理、経営報告まで、監査で追える記録を示します。抜けている項目がある場合は、請求漏れや説明不足につながります。
契約書、SLA別紙、ベンダー評価、重要委託先管理台帳を保管します。
障害通知メール、チケット、監視ログ、障害報告書、顧客側ログを残します。
サービスクレジット請求記録、付与記録、請求書反映記録を管理します。
再発防止策、取締役会、経営会議、監査役会への報告記録を残します。
金融、医療、製造、EC、公共・教育では、停止時の説明責任と代替手順が異なります。
業種によってSLAの重点は変わります。次の一覧は、業種ごとの主な影響と、契約上見ておくべき点をまとめたものです。左側の業種ごとに、右側で可用性、データ完全性、行政対応、代替手順のどこが重いかを読み取ってください。
システム障害が顧客損害、行政対応、適時開示、評判リスクに直結します。取引時間帯、障害通知、データ完全性、監査ログ、外部委託先管理、BCP・DR、訓練を確認します。
高可用性行政対応電子カルテ、予約、検査結果、薬剤管理、オンライン診療では患者安全に関係する場合があります。手作業運用、データ同期、復旧後確認、責任分界点を定めます。
患者安全代替手順停止が出荷遅延、在庫不整合、ライン停止につながります。生産計画、代替処理、現場復旧、データ整合性を確認します。
現場影響セール、キャンペーン、予約開始、チケット販売、入試申込など、特定時間帯の停止が大きな売上損失や公平性の問題を生みます。
ピーク時間公平性、説明責任、アクセシビリティ、広報対応が問題になります。期限延長、再受付、証跡公表も検討します。
説明責任SLA設計には複数の専門職が関わります。法務担当は契約条項、責任制限、解除、請求手続を設計し、IT・SRE・情報システム部門はSLI、SLO、監視、復旧、冗長化、障害報告を担います。セキュリティ、個人情報保護、リスクマネジメント、内部監査、経理、経営者、知財、労務、フォレンジック、紛争対応の関係者も、役割に応じて関与します。
利用者側のチェックでは、停止できない機能、機能別水準、分母、停止定義、部分障害、計画メンテナンス、除外事由、クレジット基礎額、唯一の救済か、重大事由の例外、障害通知、請求期限、長期停止時の解除・移行、自社顧客へのSLAとの整合、監査説明を確認します。
提供者側のチェックでは、顧客向けSLAが実績値・運用能力と整合するか、社内SLOが高めに設定されているか、監視・ログ・障害判定が可能か、SLA未達時の総額リスク、基盤クラウド・外部APIとの整合、除外事由の説明可能性、会計・請求処理、障害報告テンプレート、経営報告、消費者向けの制約、セキュリティ事故の別設計を確認します。
業務影響分析から運用への落とし込みまで、数字を契約と運用に接続します。
SLA設計は、業務影響分析、SLI、社内SLO、顧客向けSLA、補償と責任制限、運用の順に進めると整理しやすくなります。次の時系列は、上から下へ進む設計手順を表しています。各段階で決める内容を読み、契約書と運用手順のどこへ反映するかを確認してください。
停止すると売上や顧客損害が出るか、法令・業法上の報告が必要か、代替手段があるか、何時間で重大障害になるかを整理します。
時間ベースかリクエストベースか、完全停止だけか、エラー率・遅延も含めるか、測定点、ログ、タイムゾーンを決めます。
顧客向けSLAより厳しい社内目標を置き、下回った時点で改善し、契約違反を防ぎやすくします。
標準プランは99.5%または99.9%、重要顧客は99.9%または99.95%、ミッションクリティカルは99.99%相当など、価格・構成・責任制限と一体で決めます。
クレジットのみか、損害賠償と併存するか、故意・重過失、データ消失、情報漏えいを別扱いにするかを決めます。
監視、障害判定、通知、顧客報告、クレジット計算、請求・控除処理、再発防止、経営報告を整えます。
よくある失敗は、クラウド事業者のSLAをそのままコピーすること、SLAと責任制限条項が矛盾すること、障害報告が弱いこと、顧客の顧客への責任を考慮しないこと、短い請求期限を逃すことです。AWS、Google Cloud、Microsoft Azureなどの標準SLAは参考になりますが、自社の顧客属性、業務重要度、価格、技術構成、サポート体制、保険、再委託先に合わせて調整します。
障害報告には、発生日時、検知日時、復旧日時、影響範囲、原因、暫定対応、恒久対応、再発防止策、影響を受けたSLA指標、顧客側で必要な対応を含めるべきです。BtoB SaaSでは、利用者がさらに顧客へサービスを提供していることが多く、自社が受け取るクレジットと自社が負う責任の差分リスクを把握する必要があります。
SLAで稼働率と補償を決める実務で最も重要なのは、数字そのものではなく、事業リスク、契約責任、技術運用、証拠、補償、会計、内部統制を一体で設計することです。明確な定義、合理的な補償、誠実な障害報告、再発防止、現実的なリスク分担があって初めて実務上機能します。