SLA(Service Level Agreement)
よみ: エスエルエー
サービス提供者(業者や SaaS企業)と利用者(自社)の間で、「これくらいのサービス品質を保証します」と数値で取り決めた契約です。稼働率、障害への対応時間、サポートの応答時間などを明示します。SaaS の導入や、サーバー保守、セキュリティ(WAFなど)の契約時には、必ず確認すべき項目です。
なぜ重要なのか
SLA がない契約は、あくまで業者の「努力義務(ベストエフォート)」にとどまります。いざ障害が起きた際に、復旧が遅れたり口頭での曖昧な対応になったりするのを防ぐため、品質を「約束」として文書に残すことが、トラブル時の大きな差になります。
実務における確認ポイント
- 稼働率(サーバ稼働率)の具体例：99.9% 保証なら「年間約 8 時間半」、99.99% なら「年間約 52 分」の停止までは許容範囲(セーフ)とみなされます。
- 除外事項のチェック：「計画停止」や「天災」は保証の対象外になることがほとんどです。稼働率の数字だけでなく、「何が除外されるか」を必ず読み込みましょう。
- 違反時の補償：目標数値を下回った場合、返金や利用期間の無償延長(サービスクレジット)などのペナルティが設定されているか確認します。
- 計測と報告：「誰が、いつ、どのように計測し、どう報告するのか」が明確か確認します。
よくある落とし穴(注意点)
- 補償内容が「努力義務」にとどまっており、実質的な保証がない。
- 品質違反があった際に、自社から申告するプロセスを決めておらず泣き寝入りになる。
- SLA をよく読まずに契約し、自社の事業継続計画(BCP)の基準を満たしていなかった。
- 稼働率は守られているが、システムが止まったあとの「復旧」が遅すぎて実務に支障が出る。
絶対に止まってはいけない重要業務の場合は、業者の SLA だけに頼らず、自社でもバックアップ手段を用意しておくことが鉄則です。
言葉をよく利用する人
- 法務 / 契約担当
- インフラエンジニア
- Web 担当者(発注側)
- 情シス
- プロデューサー
会話上での使用例
運用保守契約の対応時間を業者と詰める場面
-
Web担当者
保守契約のSLAですが、平日10時から18時の障害対応を4時間以内、夜間と休日は翌営業日対応、という条件で問題ないでしょうか。
-
ディレクター
ECを動かしている以上、いちばん怖いのは休日の障害なんです。夜間と休日も着手2時間以内、復旧目標6時間以内にしたいので、別料金のプランで業者と交渉しましょう。
-
Web担当者
たしかに売上が止まる時間帯ほど手当てしたいですね。その条件で見積もりを取り直します。
利用中のSaaSの稼働率保証を読み直す場面
-
情シス
今使っているSaaSのSLA、稼働率99.9%とありますけど、これって月に43分くらいは止まってもいい計算ですよね。
-
Web担当者
そうなんです。しかも計画停止と第三者起因が除外になっているので、実際の保証はかなり薄いんですよ。止まると困る業務はバックアップ手段を別に用意しておきましょう。
-
情シス
なるほど、数字だけ見て安心するところでした。除外条項のほうをちゃんと読みます。