SLAとは何か？意味・具体例・計算方法を初心者にもわかりやすく解説

「SLAとは結局どういう意味なのか」「SLOやSLIとの違いがよくわからない」「99.9%の可用性でどれくらい停止するのか知りたい」――こうした疑問を持ってこのページにたどり着いた方は多いのではないでしょうか。SLA（Service Level Agreement）は、サービスの品質水準を提供者と利用者が合意する契約文書です。

本記事では、SLAの基本定義から類似用語との違い、稼働率の計算方法、具体的な活用例、さらには返金制度の実態や見落としやすい落とし穴まで、実務に直結する情報を体系的に解説します。この記事を読み終えれば、SLAの全体像を正しく理解し、自信を持って契約の評価や策定に臨めるようになるはずです。

SLA（サービスレベル契約）とは？基本をわかりやすく解説

SLAの定義と正式名称――「サービスレベルアグリーメント」の意味

SLAとは「Service Level Agreement（サービスレベルアグリーメント）」の略称で、日本語では「サービスレベル合意書」や「サービス品質保証契約」と訳されます。サービスの提供者と利用者の間で、提供するサービスの品質水準を具体的な数値や基準で定め、双方が合意する契約文書です。

たとえば、携帯電話の通信サービスで「月間稼働率99.9%を保証する」と約束するようなものをイメージすると理解しやすいでしょう。SLAは単なる努力目標ではなく、達成できなかった場合の補償や対応まで含めて明文化する点が大きな特徴です。

SLAはなぜ必要なのか？――3つの本質的な理由

SLAが必要とされる理由は、大きく3つあります。第一に、サービスの品質水準に関する共通認識の形成です。提供者と利用者の間で「どの程度のレベルを保証するか」を明確にすることで、認識のズレによるトラブルを未然に防げます。第二に、責任範囲の明確化です。

障害が発生した際に「誰がどこまで対応するか」を事前に定めておくことで、対応の遅れや責任の押し付け合いを回避できます。第三に、双方の期待値コントロールです。SLAがなければ、利用者は過剰な品質を要求し、提供者はコストに見合わない対応を迫られる可能性があります。

SLAが活用される代表的な場面と業界

SLAが活用される場面は、IT業界に限りません。最も一般的なのはクラウドサービス（IaaS・SaaS）の分野で、AWSやAzureなどの主要ベンダーは可用性や応答時間に関する詳細なSLAを公開しています。コールセンターやBPO業界では、応答率や平均応答速度を指標としたSLAが標準的です。

ヘルプデスクやITSMの領域でも、問い合わせへの一次対応時間や解決率がSLAとして設定されます。通信サービスやデータセンターでも広く運用されており、ビジネスの信頼性を担保するうえで業界を問わず欠かせない仕組みとなっています。

【図解】SLA・SLO・SLI・OLAの違いと関係性を一目で整理

SLOとの違い――「合意」と「目標」の決定的な差

SLAとSLOは混同されやすい用語ですが、両者には決定的な違いがあります。SLA（Service Level Agreement）は、サービスの提供者と利用者が交わす正式な契約文書です。これに対してSLO（Service Level Objective）は、SLAの中で設定される具体的な品質の目標値を指します。

たとえば「月間稼働率99.9%」という数値目標がSLOであり、その目標を含む契約書全体がSLAです。わかりやすく整理すると、SLAは「外部の顧客との約束」、SLOは「その約束を守るための内部指針」です。SLOを達成できなければSLA違反となるため、両者は密接に連動しています。

SLIとの違い――品質を「測る物差し」としての役割

SLI（Service Level Indicator）は、SLOの達成度合いを実際に測定するための具体的な指標です。稼働率やレイテンシ、エラー率などがSLIに該当します。たとえば「サーバーの月間稼働率」というSLIで計測した結果が99.95%であれば、SLOの目標値99.9%を達成していると判断できます。

つまり、SLIは「計測する物差し」、SLOは「到達すべき目標」、SLAは「顧客に約束する契約」という階層構造になっています。この3つの関係を正確に理解することで、品質管理の仕組み全体を論理的に設計できるようになります。

OLAとの違い――社内部門間の「裏方の合意」

OLA（Operational Level Agreement）は、SLAの存在を前提に社内の関連部門間で結ぶ運用レベルの合意です。SLAが「顧客に対する外部の約束」であるのに対し、OLAは「その約束を果たすための社内の取り決め」という位置づけになります。

具体的には、インフラチームが「障害検知から30分以内に初動対応を完了する」、アプリケーションチームが「修正パッチを4時間以内に適用する」といった、各部門の責任範囲と対応基準を明文化します。OLAが整備されていなければ、SLAで顧客に約束した水準を組織として守ることが困難になります。

4つの関係を一枚で理解する――SLI→SLO→SLA→OLAの構造図

SLI・SLO・SLA・OLAの4つは、次のような流れで連動しています。まずSLI（指標）で実際のサービス品質を計測し、その計測値がSLO（目標）を満たしているかを評価します。

SLOを含む品質基準一式を顧客との合意文書としてまとめたものがSLA（契約）です。そしてSLAの水準を組織的に達成するために、社内部門間でOLA（運用合意）を締結します。

概念	役割	対象
SLI	サービス品質を計測する指標	稼働率等
SLO	達成すべき品質の目標値	99.9%等
SLA	顧客との品質保証契約	外部利用者
OLA	SLA履行のための社内合意	社内部門

この構造を押さえれば、上司への説明もスムーズです。

SLAで使われる代表的な指標と可用性の計算方法

SLAの代表的な品質指標6選

SLAで使用される代表的な品質指標は、以下の6つです。

指標名	測定内容	主な活用場面
可用性（稼働率）	サービスが正常稼働している割合	クラウド・通信
応答時間	リクエストへの応答の速さ	Webサービス
復旧時間（MTTR）	障害発生から復旧までの時間	インフラ全般
エラー率	エラー応答の割合	SaaS・API
サポート対応時間	問い合わせから初回回答までの時間	ヘルプデスク
一次解決率	最初の対応で解決した割合	コールセンター

それぞれの指標は業界や業務内容によって重要度が異なります。自社のビジネスに直結する数値を見極めて設定することが重要です。

可用性「99.9%」と「99.99%」で何が違う？停止時間早見表

可用性の数値は、小数点以下の「9」がひとつ増えるだけで許容される停止時間が大幅に変わります。以下の早見表で確認してみてください。

可用性	月間停止時間	年間停止時間
99%	約7時間12分	約3日15時間36分
99.9%	約43分	約8時間45分
99.95%	約21分	約4時間23分
99.99%	約4分	約52分
99.999%	約26秒	約5分15秒

99.999%は「ファイブナイン」と呼ばれ、ミッションクリティカルなシステムで要求される水準です。一方、99.9%でも月に約43分の停止が発生する可能性があるため、ビジネスへの影響度を考慮したうえで適切な目標値を選ぶ必要があります。

計算時に注意すべき落とし穴――計画停止の扱いと測定方法の罠

可用性の数値を比較する際に見落としがちなのが、計画停止（メンテナンス時間）の扱いです。ベンダーによっては計画メンテナンスを停止時間から除外して稼働率を算出しており、見かけ上の数値が高くなるケースがあります。また、測定の観点もベンダーごとに異なります。

インフラ側の監視で「正常稼働」と判定されていても、エンドユーザーがサービスを利用できない状態になっていることは珍しくありません。数値だけを額面通りに受け取るのではなく、計算の前提条件や測定方法の詳細を契約書やSLA文書で確認することが、正しい比較評価の第一歩です。

SLAの具体例―クラウド・コールセンター・SaaSではどう書かれているか

クラウドサービス（AWS・Azure）のSLA例

クラウドサービスにおけるSLAの代表例として、AWSとAzureの仕組みを紹介します。AWS EC2では、単一インスタンスに対して月間99.5%、マルチAZ構成で99.99%の可用性を定めています。Azureの仮想マシンも同様に、可用性ゾーンをまたいだ構成で99.99%を保証します。

両社ともSLA未達時にはサービスクレジット（利用料の割引）で補償する仕組みを採用しており、返金ではなく将来の利用料に充当される点が共通しています。選定の際は可用性の数値だけでなく、免責事項やクレジット申請の条件を比較することが重要です。

コールセンター・BPOにおけるSLA例

コールセンターやBPO（ビジネス・プロセス・アウトソーシング）のSLAは、IT系とは異なる指標が使われます。代表的なのは応答率（全着信のうち一定時間内に応答した割合）で、「20秒以内に80%の着信に応答する」といった形式が一般的です。

そのほか、平均応答速度（ASA）、放棄率（応答前に切断された割合）、顧客満足度（CSAT）なども主要な項目として設定されます。これらの指標はオペレーターの配置計画やシフト管理に直結するため、達成可能な水準を慎重に見極めることが重要です。数値を厳しくしすぎると人件費が高騰する点にも注意してください。

自社SaaS・受託開発で使えるSLA設計のポイント

自社でSaaSを提供する立場の場合、SLAの設計は「品質保証」と「コスト管理」のバランスが最大の課題です。過剰な保証水準を設定すれば運用コストが膨らみ、低すぎれば顧客の信頼を失います。目標値は過去の実績データを基準に設定し、実態より少し余裕を持たせるのが定石です。

返金条項はサービスクレジット方式とし、損害賠償責任と明確に切り離す設計が一般的です。テンプレートをそのまま流用せず、自社のサービス特性と顧客が求めるレベルを踏まえたカスタマイズを行うことで、信頼性と競争力を兼ね備えたSLAを構築できます。

SLAに記載すべき必須項目と策定時の注意点

対象サービス・提供範囲・品質指標――SLAの骨格となる7項目

SLAに記載すべき必須項目は、以下の7つです。

1. 対象サービスの範囲：SLAの適用対象を明確に定義する
2. 提供時間・サポート時間：24時間365日か平日営業時間内かを明記する
3. 品質指標と目標値：可用性や応答時間など具体的な数値で示す
4. 測定方法と報告方法：品質の計測手法と結果の共有方法を定める
5. 障害時の対応フロー：連絡先や対応の優先順位を明文化する
6. 返金・サービスクレジットの条件：補償内容と申請手続きを定める
7. 免責事項：天災や計画メンテナンスなどSLA適用外の条件を列挙する

これらの項目を漏れなく策定することで、契約としての実効性が格段に高まります。

「努力目標」と「法的義務」の違い――一行の文言が命運を分ける

SLAの法的な拘束力は、契約書に使われる文言によって大きく変わります。「99.9%の可用性を保証する」と記載されていれば、提供者にはその水準を維持する法的義務が生じます。一方、「99.9%の可用性を目標とする」や「ベストエフォートで提供する」という表現では、努力目標にとどまり、未達でも契約違反とはみなされない可能性があります。

この違いは、トラブル発生時の損害賠償請求の成否を左右する極めて重要なポイントです。契約締結前に、責任の範囲を明確にする文言になっているかを法務部門と連携して精査してください。

定期見直しを前提とした運用設計のすすめ

SLAは締結して終わりではなく、定期的な見直しを前提とした運用設計が不可欠です。技術の進化やビジネス環境の変化により、当初設定した目標値が現実と乖離するケースは決して少なくありません。半年から1年ごとに実績データを詳しく分析し、各指標や基準値の妥当性を再評価することが望まれます。

見直しの際には、障害の発生頻度や復旧時間の実績を参照し、SLOやOLAの調整も併せて行うことが効果的です。このサイクルを継続することで形骸化を防ぎ、提供者と利用者双方にとって実質的な価値を持つSLAを長期的に維持できます。

SLA違反時の現実――返金・サービスクレジットの「理想と実態」

SLA違反時の一般的な補償フロー

SLA違反が発生した場合の補償は、多くのベンダーで以下のフローをたどります。まず障害を検知し、SLAで定めた品質基準を下回ったことを確認します。次に、利用者がベンダーに対して正式にサービスクレジットの申請を行います。

その後、ベンダー側で障害の内容と影響範囲を審査し、SLA違反に該当すると認定されればクレジットが付与されます。ここで重要なのは、多くのベンダーが自動返金ではなく「利用者からの申請」を必須条件としている点です。申請期限が設けられているケースも多いため、障害発生時には迅速に対応手続きを進めることが求められます。

返金額が「期待外れ」になりやすい構造的な理由

SLA違反時のサービスクレジットは、利用者が期待するほどの金額にならないことが大半です。その理由は、クレジットが「実際の損害額」ではなく「月額利用料の一定割合」として算出される仕組みにあります。たとえば月額10万円のサービスで障害が発生しても、返金はその10～30%程度、つまり1～3万円にとどまることが一般的です。

一方、業務停止による実ビジネスの損失は数百万円に及ぶ可能性もあります。SLAを「保険」のように考えるのは危険であり、ビジネス継続性は別途BCP（事業継続計画）として設計する必要があります。

返金申請の手続き負担と、現場を疲弊させないためのポイント

サービスクレジットの申請には、障害発生時のログや証跡の収集が求められることが多く、現場の運用担当者にとって大きな工数負担となります。少額の返金のために何時間もかけてログを精査するのは、費用対効果の面で合理的とはいえません。

この負担を軽減するためには、日頃からモニタリングツールを活用し、障害の記録を自動的に蓄積する仕組みを整えておくことが有効です。監視データの自動保存やアラート通知の設定を事前に行っておけば、障害発生時の対応スピードが向上し、申請に必要な証跡を確実かつ効率的に残せるようになります。

SLAの落とし穴――数値だけでは守れないビジネスの現実

「システム復旧」と「業務復旧」の乖離―インフラが動いても仕事ができない理由

SLAが保証する「可用性」は、一般的にインフラレベルのシステム稼働率を意味します。しかし、サーバーが正常に稼働していても、データベースの整合性チェックやキャッシュの再構築、アプリケーションの再起動といったプロセスが完了するまで、実際の業務を再開できないケースは珍しくありません。

この「システム復旧」と「業務復旧」の乖離こそが、SLAの数値だけでは把握できない盲点です。自社のビジネスにとって「業務を再開できるまでの時間」がどの程度かを明確にし、SLAの範囲外であっても具体的な復旧手順と対策を講じておくことが欠かせません。

SLA遵守率100%でも顧客が離れる理由――サポート品質とKPIの形骸化

SLAの数値を完璧に達成していても、顧客満足度が低下するケースがあります。その原因は、サポート品質の形骸化です。ベンダーが「初回回答を24時間以内に行う」というSLAを遵守するために、問題の本質的な解決よりもケースクローズを優先する現象が起きることがあります。

回答期限という数値目標の達成そのものが目的化し、利用者が本当に求めている「課題の解決」が置き去りにされてしまうのです。SLAの指標だけでベンダーの品質を評価するのではなく、実際のサポート対応力や改善への姿勢も含めて総合的に判断することが大切です。

免責事項を読まないリスク――「想定外」は本当に想定外だったか

SLAには必ず免責条項が含まれており、天災、第三者に起因する障害、計画メンテナンスなどはSLAの適用対象外とされることが一般的です。この免責事項を十分に確認しないまま契約してしまうと、いざ障害が発生した際に「SLA違反には該当しません」と告げられ、補償を一切受けられない事態に陥りかねません。

特に大規模な障害では、ベンダー側が免責事項への該当を主張するケースも十分に想定されます。契約前に想定されるリスクシナリオを具体的に洗い出し、免責範囲と自社のリスク許容度を慎重に照合する作業を必ず実施してください。

ベンダー選定・契約時に確認すべきSLAチェックポイント

導入担当者が確認すべき5つの視点

クラウドサービスやSaaSを選定する際、SLAで確認すべきポイントは以下の5つです。

1. 数値目標の適合性：可用性や応答時間が自社の業務要件に合致しているか
2. 障害時のエスカレーション体制：連絡先や対応手順が明確に定められているか
3. 返金条件の現実性：クレジットの算出方法と申請手続きが実行可能か
4. 定期レポートと改善提案：品質測定結果の報告と改善の仕組みがあるか
5. マルチベンダー戦略との整合性：特定ベンダーへの依存リスクと矛盾しないか

これらの視点を契約前にチェックすることで、導入後のトラブルを大幅に減らせます。

SaaS事業者・サービス提供側が押さえるべき設計原則

サービスを提供する立場でSLAを策定する場合は、過剰品質の回避と顧客信頼の確保を両立する設計が重要です。目標値は社内の実績データを根拠に設定し、達成可能でありながらも競争力のある水準を目指します。返金条項は損害賠償と切り離し、サービスクレジット方式で上限を設けるのが標準的な手法です。

免責事項は、自社の責任範囲を合理的に限定しつつ、利用者が不当に不利益を被らない範囲で設計しましょう。また、SLAの文言は「保証する」と「目標とする」の違いが法的責任に直結するため、法務部門のレビューを必ず経ることを推奨します。

これからのSLA――「可用性」から「ユーザー体験」の時代へ

ELA（Experience Level Agreement）という新しい考え方

近年注目されている概念がELA（Experience Level Agreement）です。従来のSLAが「システムが稼働しているか否か」というインフラ視点の指標で品質を測っていたのに対し、ELAは「利用者がストレスなくサービスを使えているか」というユーザー体験の視点で評価します。

サーバーの稼働率が100%でも、画面表示が遅い、操作に引っかかりがあるといった体験上の問題はSLAでは捕捉できません。ELAはこうした「体験の品質」を指標化する試みであり、SLAの限界を補う次世代の考え方として関心が高まっています。

AI時代のSLA――「稼働率」だけでなく「精度」も保証する時代へ

AIサービスの普及に伴い、SLAの対象領域は大きく拡大しつつあります。従来のクラウドサービスでは「稼働しているか否か」を二値的に判定すれば済みましたが、AIサービスでは「回答の精度」「推論にかかる時間」「ハルシネーション（誤情報生成）の発生率」など、品質を測定する指標が質的に変化しています。

今後は可用性だけでなく、精度やパフォーマンスの保証もSLAに組み込まれていくと考えられます。こうした変化を踏まえ、最新の技術トレンドを注視しながら自社のSLA設計を継続的にアップデートしていく姿勢が、これからの時代にはますます重要になるでしょう。

よくある質問と回答

まとめ――SLAを「お守り」で終わらせないために

押さえるべき3つのポイント

本記事では、SLAの基本定義からSLO・SLI・OLAとの違い、可用性の計算方法、具体例、策定の実務、違反時の現実、そして今後の展望まで解説しました。最後に、SLAを正しく活用するための3つのポイントを整理します。

第一に、SLAは品質の数値だけでなく、障害時の対応設計・返金条件・免責範囲まで含めて読み込むことが不可欠です。第二に、サービスクレジットはあくまで限定的な補償であり、ビジネス継続性はBCPとして別途設計する必要があります。第三に、数値達成だけでベンダーを判断せず、サポート品質や改善姿勢も含めて総合的に評価してください。