SLA（Service Level Agreement）は、サービス提供者と利用者が「どの品質を、どの条件で、どこまで保証するか」を数値とルールで合意する取り決めです。クラウドや SaaS の利用が当たり前になった今、契約前に SLA を読み解けることはサービス選定と安定運用の要になります。

本記事では、SLA の基本定義から必要性、SLO／OLA との違い、代表的な指標、未達時の補償、そして設計・作成手順までを一気通貫で整理します。クラウドサービスの SLA を確認する際のポイントもあわせて解説します。

この記事で得られること：契約前に SLA を読み解く視点／代表的な指標（SLI）の定義と測定の勘所／SLA・SLO・OLA の役割分担／クラウド特有の除外条件・補償の請求要件を確認するポイント

結論（要点）

SLA（サービスレベル合意）とは

SLA は「サービス品質をどう測り、どの水準を満たすか」を提供者と利用者で合意する取り決めで、稼働率やレスポンスタイムなどを定量的に定めるのが特徴です。

SLA は、サービスの品質を「高い・低い」といった感覚ではなく、数値と条件で判断できる形に落とし込むための合意です。たとえば月間稼働率、問い合わせの一次応答時間、復旧目標などを定め、どこまでが保証でどこからが努力目標かをはっきりさせます。

重要なのは、SLA が単なる品質表ではなく、測定方法や判定基準、例外（免責）まで含めて運用可能なルールになっている点です。数値だけが書かれていても、計測期間や対象範囲が曖昧だと「達成した・していない」の判断で揉めやすくなります。

また SLA は、障害をゼロにする約束ではなく、障害が起きたときの影響を最小化するための設計図でもあります。何が起きたら未達なのか、未達なら何が起こるのか（報告、改善、補償）を事前に決めることで、緊急時の意思決定が速くなります。

SLA が必要な理由

SLA は、品質の期待値のズレを防ぎ、障害時の対応を迅速化し、責任範囲と補償条件を明確にすることでトラブルを未然に減らします。

SLA がないと、利用者は「この料金なら常に快適に動くはず」と期待し、提供者は「ベストエフォートで提供している」と考えるなど、前提がズレやすくなります。SLA はこのズレを数値と条件で埋め、契約後の不満や追加要求を減らします。

次に、障害対応のスピードが上がります。優先度の定義、連絡手段、復旧の目標時間、報告のタイミングが決まっていれば、個別交渉に時間を使わずに復旧作業へ集中できます。

さらに、責任分界を明確にできます。特にクラウドでは、提供者の障害なのか利用者設定の問題なのかで対応が変わります。SLA は補償の話だけでなく、どこまでが提供者の責任で、利用者が何を準備すべきかを明文化する役割も担います。

SLA がなくてもよいケース

SLA は万能ではなく、事業影響が限定的なサービスでは、補償を伴う SLA を設けず SLO（内部目標）の運用で品質を担保するほうが現実的なこともあります。

すべてのサービスに SLA が必要なわけではありません。補償（サービスクレジット）を伴う SLA は、契約・測定・申請対応といった運用コストを生みます。事業影響が小さい領域や、提供条件がまだ固まりきっていない段階では、このコストが品質向上に見合わないこともあります。

たとえば、無料プランやフリーミアム、社内向けの補助ツール、立ち上げ期のスモールスタート、ベストエフォートで提供する周辺機能などは、SLA を結ばずに SLO（内部目標）で品質水準を定め、継続的に改善していく形が一般的です。利用者にとっても、まず使って効果を確かめたい段階では、厳密な保証よりも導入のしやすさが優先されることがあります。

重要なのは「SLA の有無」そのものではなく、品質目標を明確にし、測定・改善するための運用があるかどうかです。まず SLO で運用品質を可視化し、事業上重要になった領域から段階的に SLA へ広げていく進め方も、過剰な約束を避けながら品質を高める現実的な選択肢になります。

SLA の種類

SLA は適用範囲や契約形態によって複数のタイプに分かれ、サービス特性に合わせて選ぶ・組み合わせることが重要です。

SLA は大きく、サービス全体に一律で適用するものと、個別の顧客・プランごとに条件が変わるものに分けて考えると整理しやすいです。たとえば SaaS の標準プランでは共通 SLA、エンタープライズ契約では個別 SLA を設けるケースがあります。

また、対象を機能単位に切り分けるタイプもあります。アプリ全体の稼働率ではなく、API、認証、ストレージ、ネットワークなどコンポーネント別に SLA を定めると、利用者は自社の重要箇所を重点的に評価できます。

SLA と SLO／OLA の違い

SLA は対顧客の合意（契約）である一方、SLO は内部目標、OLA は組織内（部門間）の運用合意という位置づけで整理すると理解しやすくなります。

SLO は、サービス提供側が運用品質を維持するために置く「内部目標」です。SLA のように補償とセットにならないことも多く、まずは現実的に達成可能な運用水準を定めて継続的に改善する目的で使われます。

SLA は、SLO のうち利用者にとって重要で、かつ双方が合意できるものを契約として外部に出したもの、と捉えると分かりやすいです。つまり、SLO が先にあり、重要な一部が SLA になる関係が一般的です。

OLA は社内や委託先との間の運用合意です。たとえば「監視チームは検知後 10 分以内に一次切り分け」「ネットワーク担当は重大障害に 30 分以内に参画」など、SLA を守るために必要な内側の約束を整備するイメージです。SLA だけ作っても、OLA が弱いと結局守れません。

関係の整理　SLO が土台にあり、その重要な一部が SLA として外部化される。SLA を内側で支えるのが OLA（SLO ⊃ SLA、それを下から支える OLA）。

SLA に定める主な項目

SLA には、対象範囲、品質項目と目標値、測定・報告方法、免責、未達時の救済措置、見直しルールなど、運用まで見据えた要素を盛り込みます。

まず必須なのは対象範囲です。どの機能・どの環境・どの時間帯を SLA の対象にするのかを明記します。範囲が曖昧だと、期待値が膨らみ、未達判定の争点になりやすくなります。

次に、品質項目と目標値です。稼働率、レスポンスタイム、復旧時間、サポート応答など、事業影響と直結する指標に絞り、計算式や測定地点、集計期間をセットで定義します。数値だけを掲げるのではなく、どう測るかまでが合意事項です。

さらに、免責と未達時の救済措置をセットで書きます。計画メンテナンス、天災、利用者環境起因などを除外条件として整理し、未達時にはサービスクレジットなどの補償、報告、改善計画、再発防止策の提出などを規定します。最後に、見直しの頻度と変更手続きも入れておくと、運用実態に合わせて更新しやすくなります。

SLA で使われる指標の例

SLA の指標（SLI）は、サービスの状態を客観的に判断できるよう、定義と計算方法を含めて合意するのが基本です。

SLA の指標は、単に「99.9%」のような数字を置くのではなく、どの状態を成功とみなすか、どこで測るか、どの期間で集計するかまで決めて初めて機能します。ここが曖昧だと、実測値が近いほど解釈の違いが露呈し、トラブルの火種になります。 また、指標は多ければ良いわけではありません。計測・報告のコストが増え、形骸化しやすくなるため、重要なユーザージャーニーやクリティカルな機能に絞って「改善につながる指標」を採用することが実務的です。

以下では代表例を挙げ、何を定義すべきかの観点を整理します。

稼働率（可用性）

稼働率は SLA で最もよく見かける指標ですが、月間なのか年間なのか、どの単位で集計するのかで意味が変わります。一般には「稼働率（%）＝（総時間－停止時間）÷総時間×100」の形で定義し、総時間に計画メンテナンスを含めるか、停止時間に部分障害を含めるかを明確にします。

　計算式　稼働率（%）＝（総時間 － 停止時間）÷ 総時間 × 100

比較のコツは、パーセンテージを停止時間に換算することです。月 30 日を前提にすると、99.9%は停止許容が約 43 分、99.99%は約 4 分、99.999%は約 26 秒程度まで縮みます。数字が小さく見えても、許容停止時間は桁で変わるため、事業影響の大きい機能ほどこの差が効きます。

クラウドでは未達時の補償としてサービスクレジットが用意されることが多いです。ただし「自動付与」ではなく、期限内の申請が必要だったり、影響の証跡提出が求められたりします。補償額も月額の一部に限定されることが一般的なので、損失補填というより改善インセンティブと捉えるのが現実的です。

復旧時間（MTTR）・障害件数

MTTR（平均復旧時間）は、障害の検知から復旧まで、あるいは影響開始から正常化までなど、どの区間を測るかで数値が変わります。SLA に入れるなら、開始点と終了点をログで追跡できる形で定義し、集計対象期間も合わせて決めます。

障害件数も同様に、何を 1 件と数えるかが重要です。たとえば重大度（Severity）ごとに件数を分ける、同一原因の連続事象を 1 件とみなす、計画停止は除外するなど、運用実態に合わせたルールが必要です。

ポイントは「利用者の事業に影響する障害」を対象にすることです。内部で吸収できた軽微な警告まで数えると件数が増えすぎて判断材料になりません。逆に重大障害の定義が曖昧だと、報告義務や補償の範囲で揉めるため、重大度の基準（影響範囲、継続時間、代替手段の有無）を明文化します。

レスポンスタイム

レスポンスタイムは平均値だけだと実態を隠しやすいため、パーセンタイルで合意するのが実務的です。たとえば「1 分間のリクエストのうち 95%が 2 秒以内」のように定義すると、少数の極端な遅延に引きずられず、体感に近い評価になります。

また、測定地点が重要です。提供者側のサーバー内計測はネットワーク影響を含まず短く出やすい一方、利用者側計測は回線や端末の影響を受けます。どちらを正とするか、もしくは両方を補助指標として扱うかを決めておかないと、未達判定が難しくなります。 ピーク時の扱いも詰めどころです。通常時だけ良くても、月末やセール時に遅くなるなら業務影響が出ます。ピーク定義（時間帯・負荷条件）や、対象 API や画面を絞って測るなど、測定可能で事業に効く形に設計します。

ヘルプデスクの対応時間・応答時間

サポート SLA は「一次応答」と「解決（復旧）」を分けて定めるのが基本です。一次応答は受付確認や状況ヒアリングまで、解決時間は原因特定と恒久対応まで、というように区切ると、提供者側も利用者側も期待値を持ちやすくなります。

受付時間の前提も重要です。営業時間のみなのか 24 時間 365 日なのかで実質のスピードは大きく変わります。さらに、優先度別に目標を変える（例：重大は 30 分以内に一次応答、軽微は翌営業日）ことで、限られた体制でも重要案件に集中できます。

問い合わせチャネルも SLA の一部です。電話・メール・チケットのどれが対象か、証跡として何を正とするか（チケット登録時刻など）を決めておくと、後から「連絡したのに反応がない」といった認識齟齬を減らせます。

SLA 未達時の対応と補償

未達時の対応は、原因切り分け・エスカレーション・報告・再発防止に加え、返金・減額などの補償（サービスクレジット）条件を具体化しておく必要があります。

SLA 未達が起きたときに重要なのは、補償の金額よりも、対応プロセスが止まらないことです。誰がいつまでに何を報告し、暫定対応と恒久対応をどう進め、再発防止をどう確認するかまでを決めておくと、障害後の混乱を抑えられます。

補償はサービスクレジット（利用料の一部返還や翌月減額）で定められることが多いです。ただし多くの場合、上限は月額利用料の範囲で、逸失利益などは対象外です。利用者側は、補償がリスクを完全に相殺するものではない前提で、冗長化や代替手段も含めた事業継続計画を検討する必要があります。

実務上の落とし穴：請求要件　未達でも自動で返金されない／申請期限が短い／利用者側のログ提出が必要／対象サービスやプランが限定される——など。未達時に「何を提出すればよいか」を事前に運用へ組み込み、補償を受けられる状態にしておくことが現実的な備えです。

実務上の落とし穴は、請求要件です。未達でも自動で返金されない、申請期限が短い、利用者側のログ提出が必要、対象サービスやプランが限定されるなどがあります。未達時に「何を提出すればよいか」を事前に運用に組み込み、補償を受けられる状態にしておくことが現実的な備えです。

SLA の設計・作成手順

SLA はテンプレの流用ではなく、サービス特性と運用実態に合わせて「範囲 → 責任 → 測定 → 改善」の順に設計すると実務で機能しやすくなります。

SLA 作成でありがちな失敗は、先に数値目標だけを決めてしまい、後から対象範囲や測定方法が追いつかなくなることです。順番としては、何を保証するかの境界を引き、その境界内で責任を整理し、測定可能な形に落とし込み、最後に改善サイクルへ組み込むのがスムーズです。

また、SLA は契約書としての側面があるため、運用担当だけでなく法務・営業・サポート・開発を巻き込んで整合を取る必要があります。現場が守れない SLA は信頼を毀損し、過度に守りに入った SLA は競争力を落とします。

以下のステップで、実態に合う SLA を作りやすくなります。

サービス範囲と前提条件を決める

まず、SLA の適用範囲を明確にします。対象となる機能、環境（本番のみか検証環境も含むか）、提供時間（24 時間か営業時間か）を定義し、利用者が期待してよい範囲を固定します。

計画停止やメンテナンスの扱いも前提条件として必須です。事前告知の期限、メンテ時間の上限、緊急メンテの定義などを決めておくと、稼働率の計算と利用者の業務調整がしやすくなります。

さらに、利用者側要因の明記が重要です。回線・端末・ブラウザ・利用者設定・権限管理など、提供者が制御できない領域は免責になり得ます。ここを曖昧にすると、提供者が対応不能な問題まで SLA 未達として扱われるリスクが生まれます。

役割と責任（責任分界）を明確にする

責任分界は、SLA の実効性を左右します。提供者、利用者、委託先（MSP など）がそれぞれ何を担当し、誰が最終責任を持つかを整理します。RACI のように、実行・承認・相談・報告の関係を描くと合意しやすくなります。

障害対応では連絡体制が特に重要です。一次窓口、エスカレーション先、緊急連絡手段、連絡可能時間を決め、連絡が取れないこと自体が復旧を遅らせないようにします。

ログ提供や設定変更権限も境界の一部です。利用者が必要なログを提供しないと原因究明が進まない場合、提供者が対応期限を守れなくなることがあります。何をどの形式で、どの期限で共有するかまで取り決めると、責任分界が実務に落ちます。

測定方法・報告方法を決める

測定は、監視ツール、測定地点、集計周期をセットで決めます。提供者側監視だけでなく外形監視を入れるのか、複数地点の平均を取るのかなど、測定設計によって数値は変動します。

計算式とデータの正（公式記録）も合意事項です。どのログを基準にするか、欠測時はどう扱うか、部分障害の取り扱いはどうするかを決めておくと、未達判定の争いを減らせます。

報告については、頻度（月次など）、形式（ダッシュボード、レポート）、含める項目（稼働率、障害一覧、原因分類、改善状況）を定義します。未達判定と異議申立て手順まで用意しておくと、双方が納得感を持って運用できます。

運用・見直し（改善）に活かす

SLA は守ることが目的ではなく、品質を継続的に改善し、事業リスクを下げるための仕組みです。四半期や年次での定期レビューを設け、実績と課題をもとに指標や目標値を更新できるようにします。

SLO との整合も見直しで重要になります。内部目標（SLO）が変わったのに SLA が古いままだと、現場は二重管理になり、指標が形骸化しやすくなります。SLA は最低限の約束、SLO は改善を牽引する目標として役割分担を明確にします。

変更手続きも SLA に組み込みます。変更の周知方法、効力発生日、合意方法を定めておくと、サービス拡張や提供条件の変更に合わせて適切に更新できます。

クラウドサービスの SLA の見方

クラウドの SLA は一見同じ数値でも、対象範囲・除外条件・クレジット請求要件で実質が変わるため、条文の読み解きが欠かせません。

クラウドの SLA は「稼働率 99.9%」のように一言で比較されがちですが、実際は対象サービス単位（リージョン、AZ、特定機能）や除外条件で実質の厳しさが変わります。数値だけで選ぶと、想定していた保証を受けられないことがあります。

特に注意したいのは、何が停止としてカウントされるかです。管理画面は落ちたが API は動いていた、特定機能だけ不安定だった、ネットワーク経路の問題だったなど、現象ごとに SLA 対象外になる場合があります。利用者の重要機能がどの条項に紐づくかを確認します。

もう一つはクレジットの請求要件です。申請期限、申請窓口、必要情報、証跡、対象プランを確認し、運用側で申請できる体制を整えておくと、いざという時に取りこぼしません。

責任共有モデルと SLA の関係

クラウドでは責任共有モデルが前提です。提供者はデータセンター、物理サーバー、基盤サービスなどを担い、利用者は OS 設定、アプリ、ID 権限、ネットワーク設定、データ保護などを担うという分担になります。SLA が主に保証するのは、提供者が管理する領域であることが多いです。

たとえば、クラウド基盤の稼働率 SLA が高くても、利用者が誤ってセキュリティ設定を変えて通信不能にした場合は SLA 対象外になり得ます。逆に、提供者の障害でも、利用者側で冗長化設計をしていれば影響を小さくできることがあります。

つまり、SLA は安心材料である一方、利用者側の設計と運用が品質を決める部分も大きいということです。SLA 確認と同時に、どこまで自社が責任を持つべきかを洗い出し、監視・バックアップ・権限管理・冗長化の方針とセットで考えるのが安全です。

まとめ

SLA はサービス品質を数値と運用ルールで合意し、期待値のズレや障害時の混乱を減らすための重要な契約要素です。自社の要件に合う指標・測定方法・責任分界・補償条件を押さえ、定期的に見直すことで実効性のある SLA にできます。

SLA とは、提供者と利用者がサービス品質を数値と条件で合意し、測定から未達時対応までを運用可能な形にする取り決めです。契約前に読み解けると、サービス選定の精度と運用の安定性が上がります。

実務で効く SLA にするには、数値の高さだけでなく、対象範囲、除外条件、測定地点、報告と異議申立て、補償の請求要件まで確認することが重要です。特にクラウドでは責任共有モデルにより、SLA が保証する範囲が限定される点を押さえます。

SLA は一度作って終わりではありません。運用実績と SLO を踏まえて定期的に見直し、責任分界と指標を現実に合わせ続けることで、トラブル予防と継続的な品質改善の両方に活かせます。

WebSAM Cloud で支えるサービスレベル運用の実践

SLA で定める応答・通報時間（サポート SLA）、復旧・エスカレーション時間（MTTR／SLO）、責任分界、そして継続的な見直しは、実際の運用現場でこそ問われます。インシデント管理高度化ソリューション「WebSAM Cloud」は、アラート対応の自動化でサービスレベルの目標を支えます。

監視システムからの大量のアラート対応に追われると、社内で定めた応答・エスカレーションの目標時間を守り切れなくなりがちです。アラートの自動判別・自動エスカレーションは、こうした運用の負荷を下げ、目標時間を維持しやすくする打ち手になります。リトライオーバーや通報件数といった指標を可視化しながら、継続的に運用品質を高めていけます。

サービスレベルを支える運用へ ― WebSAM Cloud で次の一歩を

サービスレベルは数値とルールの合意であると同時に、それを日々支える運用があって初めて意味を持ちます。WebSAM Cloud は、アラートの自動判別と自動エスカレーションで、応答・エスカレーションや MTTR に関わる運用の安定を支えます。

まずは小さく始めて自社の運用で効果を確かめるのが近道です。次の 2 つの入口から、コストをかけずに第一歩を踏み出せます。

まずは Free プランで試す（無料）

費用ゼロで始められる、期間無制限の無料プランです。電話通報とメールフィルターの中核機能を、お使いの監視ツールの通知メールに WebSAM Cloud のアドレスを追加するだけで試せます。

サービス紹介資料のダウンロード

個別相談・お問い合わせ

「自社の運用に合うか相談したい」「料金プランや構成管理機能の詳細を聞きたい」といったご要望には、専門担当者が個別にお応えします。