SLA条項レビューのチェックポイント｜サービスレベル・障害対応・返金の実務論点
こんにちは。LegalAgent 代表弁護士の朝戸です。
SaaSや保守運用、BPOの契約書を見ていると、営業資料では「稼働率99.9%」のように強く見えるSLAが、契約書の本文を読むと適用条件が限定されていたり、返金がわずかだったりすることがあります。逆に、提供者側が数字だけを重視して厳しいSLAを受け入れてしまうと、自社ではコントロールできない外部要因まで責任を負うように読める場合があります。SLAは法務だけで完結しにくく、サービスの技術構成や保守体制、利用者側の運用まで理解して初めて、契約文言が現実に合っているかを判断できます。
SLAの数字は何を測っているか
SLAはService Level Agreementの略で、サービス提供者が利用者に約束するサービス水準を定めるものです。契約書ではサービスレベルや稼働率保証などの名称で置かれ、月間稼働率とサービスクレジットを軸に項目が構成されるのが典型です。同じ「稼働率」という言葉でも、重視される数字はサービスの性質で変わります。SaaSでは稼働率やデータバックアップ、保守契約では一次対応の速さというように、何を測る数字なのかを踏まえて読みます。
数字そのものより先に見ておきたいのは、その数字が「努力目標」なのか「契約上の義務」なのかという位置づけです。水準を下回った場合に改善協議で終わるのか、サービスクレジットが発生するのか、解除や損害賠償にまでつながるのかで、条項の重みはまったく違います。営業資料と契約条項の整合性を利用者側で照らし合わせておく方がよいでしょう。
まず見ておきたい論点は次の三つです。
- 稼働率の計算期間・計算方法と、計画停止や外部要因の除外条件
- 重要度区分ごとの初動対応時間・復旧目標時間の定め
- サービスクレジットの水準と、実際の事業影響との釣り合いなど
対象サービスの範囲も見落とせません。本番環境だけを対象にしているのか、管理画面やAPI、モバイルアプリ、サポート窓口まで含むのかによって、実質的な保証範囲は変わります。稼働率の計算方法についても、計画停止や利用者側の設定ミス、外部サービス障害、不可抗力を分母又は分子から除外しているかどうかまで読み込むと、数字の意味が具体的に見えてきます。
障害発生時に何が動くのか
障害対応では、重要度区分ごとに初動対応時間、復旧目標時間、進捗報告の頻度が定められているかを確認します。重要度の判定主体が提供者だけになっている条項は、利用者側の実感とずれることがあります。サポート条件では、24時間受付と24時間対応は別物である点に注意が必要です。問い合わせを受け付けるだけなのか、技術者が実際に対応するのかを分けて読むと、体制の実態が見えてきます。
サービスクレジットや返金では、発生条件と金額の上限、翌月利用料からの控除か返金かを見ます。利用者側では実効性、提供者側では損害賠償と重複して発生するのか唯一の救済なのかが焦点になります。障害報告では、報告期限や原因分析、再発防止策の提出が定められているかを見ます。重大障害では、復旧報告だけでは、利用者側の顧客対応や当局対応を支えきれないことがあります。
利用者側の協力義務も無視できません。利用者の設定やアクセス権限管理、推奨環境の維持がSLAの前提になっている場合、提供者側では利用者の協力がないときにSLAの対象外とする設計が要ります。最後に、SLA未達が続いた場合の効果も見ておきます。単発のサービスクレジットで足りるのか、改善計画や契約解除、優先サポートまで用意しておくのかは、事業上の重要度に応じて判断が変わります。
利用者側・提供者側で見るべきリスク
利用者側では、SLAが実際の業務リスクをカバーしているかをまず見ます。基幹システムであれば、月間稼働率の数字だけでなく、障害発生時の連絡経路や復旧見込み、データ保全までそろっているかが問われます。サービスクレジットの金額が事業損失に比べて小さすぎる場合は、代替運用や保険、社内BCPも含めて考える方が現実的です。
提供者側では、SLAを守れる運用体制になっているかがまず問われます。契約書上は短い初動時間を約束していても、夜間休日の担当者がいない、障害検知が手動になっているといった実態があると、契約と現場がずれます。SLA未達時の効果が重すぎないかも確認します。軽微な遅延でも解除権が発生する、外部サービス障害でも損害賠償責任を負うといった条項は過大になりやすく、責任制限条項や不可抗力条項との整合性を合わせて見る必要があります。
双方に共通するのは、障害時のコミュニケーション設計です。数字だけ決めても、誰にどの手段でどの頻度で報告するのかが決まっていなければ、実際の混乱は抑えられません。SLA条項は相手を責めるための条項ではなく、品質を測り、問題が起きたときに冷静に対応するための共通言語として設計する方が実務的です。