SLA（サービスレベル合意）とは？定義・SLOとの違い・要件と稼働率保証を解説

SLA（Service Level Agreement／サービスレベル合意）は、サービス提供者と利用者が「どの水準のサービスを、達成できなかったときはどうするか」まで含めて取り決める合意である。単なる努力目標ではなく、稼働率や応答時間といった測定可能な指標と、未達時のサービスクレジット（返金）をセットで定める点が要点になる。この記事では、SLAの定義とSLO・SLIとの違い、契約に盛り込む要件とサービスレベル指標、「稼働率99.9%」が実際に何分の停止を許すのか、そしてAWS・Azure・Google Cloudが公表している稼働率保証とサービスクレジット率までを、発注・運用の実務目線で整理する。

まとめ：SLAの要点（先に結論）

• SLAは「品質水準＋未達時の対応」を明文化した合意。稼働率・応答時間などの指標と、割ったときのサービスクレジット（返金率）を必ず対で定める。
• SLA・SLO・SLIは役割が違う。SLI＝測る指標、SLO＝社内で狙う目標、SLA＝顧客に対する契約上の約束。契約で拘束力を持つのはSLAだけ。
• 稼働率は%の桁で停止許容が大きく変わる。99.9%は月約43分、99.99%は月約4分。1桁の違いが運用コストを大きく左右する。
• クラウドのSLAは「%」だけで判断しない。AWS EC2の99.99%は複数AZ構成が前提で、単一インスタンスは99.5%。クレジットは自動付与ではなく申請制のことが多い。
• SLO・SLIの深掘りや監視実装はSLAとSLO・SLIの違いと稼働率の決め方・監視実装の解説、SLI/SLOの定義はサービスレベル指標(SLI)とサービスレベル目標(SLO)の解説を参照。

SLA（サービスレベル合意）の定義と役割

SLAは、提供するサービスの品質を数値で約束し、達成できなかった場合の措置までを含めた契約上の取り決めである。「サービスレベル契約」「サービス品質保証」とも訳される。口約束の品質目標と決定的に違うのは、測定できる指標と未達時のペナルティ（サービスクレジット）を明記し、双方が合意のうえで契約に組み込む点だ。これによって、障害時に「どこまでが提供者の責任か」を後から争わずに済む。

SLAが対象にするサービスと当事者

SLAはクラウド・SaaS・データセンター・保守運用・BPOなど、継続的にサービスを提供する契約で用いられる。当事者は、外部ベンダーと顧客の間で結ぶ「外部SLA」が典型だが、社内のIT部門と事業部門の間で結ぶ「内部SLA」もある。いずれも、提供者は過剰な約束を避けて実現可能な水準に留め、利用者は自社の業務要件に照らして水準の妥当性を確認する、という緊張関係のなかで水準が決まる。

SLA・SLO・SLIの違い

SLAを理解するうえで避けて通れないのが、SLO・SLIとの区別である。三者は階層が違い、混同すると「達成しているのに契約違反」といった認識のずれを生む。

実務では、まずSLIで測り、余裕を見てSLOを社内に置き、それより低い水準を顧客向けのSLAとして約束する。SLAをSLOと同値にすると、少しの逸脱がそのまま契約違反になり運用が破綻するため、SLAはSLOより緩く設定するのが定石だ。三者の詳しい違いと監視での測り方はSLI・SLOの基本概念と役割の解説で扱っている。

SLAに定める主要項目とサービスレベル指標

SLAに盛り込むべき必須項目

SLAの本体は「何を、どの水準で、割ったらどうするか」の3点に集約される。過不足なく合意するために、少なくとも次の項目を明記する。

• 対象範囲：どのサービス・機能・時間帯が対象か（計画停止や特定リージョンを除外するかも含む）。
• サービスレベル指標と目標値：稼働率・応答時間・復旧時間などの数値。
• 測定方法と測定期間：誰が・どの計測点で・月次か年次かを定義（測定方法が曖昧だと違反判定で揉める）。
• サービスクレジット：未達時の返金率と算定基準、請求手続き。
• 除外・免責事項：不可抗力、利用者側起因の障害、事前告知した計画停止など。
• 見直し条件：水準を再交渉する契機（利用規模の変化、重大障害の発生など）。

代表的なサービスレベル指標

指標は業務への影響が直結するものを選ぶ。数値化できない「安定した」「速い」といった表現は避け、必ず測れる形にする。

• 可用性（稼働率）：月間または年間で、サービスが利用可能だった時間の割合。SLAの中心指標。
• 応答時間：リクエストへの応答にかかる時間（例：95パーセンタイルで500ミリ秒以内）。
• 障害復旧時間：障害発生から復旧までの目標時間（RTO）や、一次回答までの時間。
• エラー率：全リクエストに占める失敗の割合（例：0.1%以下）。

可用性は平均値ではなくパーセンタイル、応答時間は最大値ではなく分位点で約束するのが実務的だ。平均で約束すると、少数の極端な遅延が平均に埋もれて利用者の体感と乖離する。

稼働率「99.9%」が意味する停止時間

SLAで最も誤解されやすいのが稼働率の桁だ。「99%も99.9%も大差ない」と感じやすいが、許される停止時間は桁ごとに一桁変わる。次の早見表で体感をそろえておきたい。

99.9%から99.99%へ一桁上げると、許容停止は月43分から月4分へと縮む。その差を埋めるには冗長構成や多重AZが必要になりコストが跳ね上がるため、業務が本当に要求する桁を見極めることで、過剰投資を避けられる。稼働率目標の決め方の詳細は稼働率の決め方と監視実装の解説を参照。

非機能要件・内部SLAとの関係

非機能要件とSLAの対応

SLAで約束する可用性や性能は、システム開発の「非機能要件」がそのまま契約水準に反映されたものと捉えると整理しやすい。要件定義で可用性・性能・運用の水準を決め、そのうち顧客に約束する部分をSLAとして切り出す、という流れになる。IPAが公開する非機能要求グレードは、可用性や性能などを6大項目で段階化しており、SLAの水準を決める共通言語として使える。非機能要件の枠組みはIPAの非機能要求グレードの解説で確認できる。

内部SLA・OLA・UCの違い

顧客向けSLAを守るには、それを支える社内・委託先との取り決めが要る。混同されがちな3つを区別しておく。

• 内部SLA：社内のIT部門と事業部門の間で結ぶサービス水準の合意。
• OLA（運用レベル合意）：同一組織内のチーム間（例：運用チームとインフラチーム）の取り決め。
• UC（外部委託契約）：外部の下請けベンダーとの契約。

顧客SLAで「復旧2時間」を約束するなら、それを支えるOLAやUCは2時間より短い水準でなければ整合しない。外向きのSLAだけ先に決めて内部の裏付けを取らないと、約束はしたが守れない状態に陥る。

SLAの契約上の効力とサービスクレジット

SLAの法的性質と未達時の救済

SLAは契約書またはその付属文書として合意されると、契約上の義務となる。水準を割った場合の救済として一般的なのがサービスクレジットで、未達の程度に応じて月額料金の一定割合を返金・値引きする仕組みだ。多くのクラウドSLAでは、クレジットは損害賠償ではなく「唯一かつ排他的な救済」と定義され、実損害の全額補填ではない点に注意が要る。業務停止による逸失利益まで求めるなら、SLAとは別に個別条項での交渉が必要になる。

見落としやすい除外・免責条項

SLAの数値だけを見て安心すると、除外条項で実質的に保証が薄いことがある。契約前に必ず確認したいのが次の点だ。

• 計画停止の扱い：事前告知したメンテナンスは稼働率の分母から除外されることが多い。
• 対象範囲の限定：特定リージョン・特定構成・接続性のみが対象で、データ整合性やAPIエラーは対象外というケース。
• クレジットの上限と申請制：返金は月額料金が上限で、しかも利用者からの申請がなければ支払われないことが多い。障害の検知と申請を運用に組み込まないと、権利があっても受け取れない。

クラウド各社のSLAと稼働率保証

主要クラウドのSLAは公開されているが、同じ「99.99%」でも前提となる構成が違う。ここでは代表的なコンピューティング／ストレージのSLAを、公式文書（2026年7月時点）から整理する。契約時は必ず最新の公式SLAを確認してほしい。

主要クラウドの稼働率保証とサービスクレジット

サービスクレジットは稼働率が下がるほど返金率が上がる段階制になっている。AWS EC2を例にすると次のとおりで、95%を割ると全額（100%）返金となる。

AWS S3 Standardは同じ区分で10%／25%／100%、Azure VMは99.99%未満で25%、95%未満で100%と、各社で返金率の刻みが異なる。

クラウドSLAの落とし穴

クラウドSLAは「稼働率の数字が高い＝安心」と読みたくなるが、実務では次の点で期待と食い違う。

• 高い数字ほど構成条件が付く：EC2やAzure VMの99.99%は複数AZ構成が前提で、単一構成では99.5〜99.9%に下がる。冗長化を怠ると保証水準そのものが下がる。
• 返金は月額の一部で、損害は埋まらない：全額返金でも「その月のそのサービスの料金」まで。業務停止の損失はカバーされない。
• 申請しないと支払われない：多くのクラウドはクレジットが申請制。障害の記録と申請フローを運用に組み込む必要がある。

したがってクラウド選定では、%の高さより「対象範囲・前提構成・クレジットの実効性」を突き合わせるほうが判断を誤らない。

SLAの策定・運用プロセス

策定から合意・見直しまでの進め方

SLAは一度決めて終わりではなく、業務要件の変化に合わせて更新し続ける前提で運用する。標準的な流れは次のとおりだ。

• 要件の洗い出し：業務が止まると困る度合いから、必要な稼働率・応答時間の桁を決める。
• 指標と目標値の設定：測定可能な指標に落とし込み、SLOより緩いSLA値を置く。
• 交渉と合意：提供者の実現可能性とクレジット条件を突き合わせ、双方が署名できる水準にする。
• 測定と報告：合意した計測点で継続測定し、定期的にレポートする。
• 見直し：利用規模の変化や重大障害を契機に、水準とクレジットを再交渉する。

SLAレポートと継続的な見直し

運用フェーズでは、稼働率・応答時間・違反の有無を定期レポートで可視化する。レポートには実測値（SLI）と目標（SLO／SLA）を並べ、逸脱があれば原因と改善策まで記す。ここでSLAレポートを「達成/未達の報告」で終わらせず、指標が悪化する予兆を早期に拾う道具として使うと、違反による返金の前に手を打てる。監視の具体的な実装方法はSLA監視の実装解説で扱っている。

よくある質問（FAQ）

SLAとは何の略ですか？

Service Level Agreement（サービスレベル合意／サービスレベル契約）の略です。サービスの品質水準と、達成できなかったときの対応（サービスクレジットなど）を取り決めた合意を指します。

SLAとSLOの違いは何ですか？

SLOは社内で狙うサービスレベル目標、SLAは顧客に対する契約上の約束です。契約違反として拘束力を持つのはSLAで、通常SLAはSLOより緩い水準に設定します。測定に使う実測値がSLIです。

稼働率99.9%はどのくらいの停止時間ですか？

月あたり約43.8分、年あたり約8.8時間の停止までが許容範囲です。99.99%なら月約4.4分まで縮みます。

サービスクレジットとは何ですか？

SLAで約束した稼働率などを割った場合に、月額料金の一定割合を返金・値引きする仕組みです。多くは申請制で、返金額は当該サービスの月額料金が上限になります。

SLA要件には何を書けばよいですか？

対象範囲、稼働率や応答時間などの指標と目標値、測定方法と期間、サービスクレジット、除外・免責事項、見直し条件を明記します。数値化できない表現は避け、測定できる形に落とし込みます。

関連記事

• SLAとは？SLO・SLIとの違いと稼働率の決め方・監視実装をエンジニア視点で解説
• サービスレベル指標(SLI)とサービスレベル目標(SLO)とは何か？信頼性を測る基本概念と役割を解説
• 【非機能要求グレードとは何か？】IPAが提唱するフレームワークの概要と非機能要求定義の目的を詳しく解説する