SLA は Service Level Agreement の略で、サービス提供者と利用者の間で、どの程度のサービスレベルを目指すのかを合意するためのものです。
ITサービス、クラウド、保守契約、運用監視、問い合わせ対応などで使われます。
まず押さえたいポイント
- 対応時間、初動返信、復旧目標、稼働率、報告方法などを決める
- 「頑張って対応します」ではなく、期待値を具体化するために使う
- 厳しいSLAほど、監視、冗長化、待機体制、費用が必要になる
- 小規模案件では、最初から過度な保証を書かない方が安全
- SLAと損害賠償、免責、外部サービス障害の扱いは分けて確認する
どんな場面で使うか
クラウドサービスでは、月間稼働率やサービスクレジットの条件として出てくることがあります。
受託開発や保守契約では、障害連絡を受けてから何営業日以内に一次返信するか、平日営業時間だけ対応するのか、休日夜間も対応するのか、重大障害をどう優先するのかを決める場面で使われます。
たとえば、「平日10時から18時まで受付」「重大障害は1営業日以内に一次返信」「復旧作業は原因調査後に保守内対応か別見積かを判断する」といった内容も、広い意味ではサービスレベルの取り決めです。
よくある誤解
SLAは「必ず直す保証」と同じではありません。
復旧できるかどうかは、原因、権限、バックアップ、外部サービス、インフラ構成、契約範囲によって変わります。
特に小規模な受託開発で「24時間365日対応」「1時間以内復旧」と書くと、実際にはその体制がないのに重い責任だけを負うことになります。
厳しいSLAを置くなら、監視、アラート、冗長構成、担当者の待機、権限、手順書、費用まで合わせて設計する必要があります。
実務で見るポイント
SLAを見るときは、対応時間、初動返信、復旧目標、対象外条件、障害優先度、報告方法、クライアント側の協力事項を確認します。
外部クラウド、決済代行、メール配信、DNS、ドメイン契約の障害は、自社だけでは制御できないため、免責や協議事項として分けておくと安全です。
初心者はまず、「SLAは安心の言葉ではなく、期待値と責任範囲を数字や条件でそろえるためのもの」と覚えるとよいです。
保守費用を説明するときも、SLAが重くなるほど、月額費用や体制も重くなると考えると整理しやすくなります。