SLAって何?わかりやすく解説

ネットのサービスが突然使えなくなって「早く直してよ!」って思ったこと、ない?でも、そのサービスの会社がどのくらいちゃんと動かしてくれるか、実は最初から「約束」が決まってることがあるんだ。その約束のことをSLAって呼ぶんだけど、ビジネスの世界ではめちゃくちゃよく出てくる言葉なんだよ。この記事を読めば、SLAが何なのか・どう読めばいいのか・なぜ大事なのかが全部わかるよ。

SLAって略語だよね。何の略なの?

Service Level Agreementの略で、日本語にすると「サービスレベル合意」って感じかな。つまり「このサービスはこの品質・この条件で提供しますよ」っていう、サービスを提供する会社とお客さんの間で交わす約束の文書のことだよ。
「サービスの品質の約束」って、具体的にどんなことが書いてあるの?

一番よく出てくるのが稼働率(かどうりつ)——つまり「1年間のうち、サービスが止まらずにちゃんと動いている時間の割合」だよ。「99.9%の稼働率を保証します」みたいに書かれてるんだ。他にも、問い合わせに何時間以内に答えるかとか、もし約束を守れなかったときにどう補償するかとかも書いてあるよ。
99.9%って、ほぼ100%じゃん。それって超すごくない?

実はここが落とし穴で、99.9%って聞くとすごく高そうだよね。でも計算してみると、1年間で約8時間45分は止まっていてもOK、ってことになるんだ。逆に99.99%(ナインが4つ)だと約52分しか止まれない。数字がちょっと変わるだけで、許される停止時間が全然違うんだよ。
じゃあ会社がSLAを守れなかったらどうなるの?

SLAにはペナルティ(罰則)が決められてることが多くて、代表的なのがサービスクレジット——つまり「ごめんなさい、その分の利用料を返しますね」って形の補償だよ。全額返金されることはほぼなくて、停止時間に応じて数パーセント分が戻ってくる感じ。だからSLAは「サービスの品質保証書」でもあり「補償のルールブック」でもあるんだ。
📝 3行でまとめると
  1. SLAとは、サービス提供会社とお客さんが交わす 「品質の約束」の文書 のこと。
  2. 約束の核心は 稼働率 で、99.9%でも年間約8時間45分の停止が許容される。
  3. 約束を破ったら サービスクレジット(利用料の一部返金) などのペナルティが発生する。
目次

もうちょっと詳しく

SLAは主にクラウドサービスやITインフラ、通信サービスで使われる文書だよ。たとえばAmazonのクラウドサービス(AWS)やGoogleのクラウドサービス(Google Cloud)は、サービスごとに細かいSLAを公開していて、誰でも見ることができる。ビジネスでシステムを作るときは「このクラウドのSLAは何%か」を確認してから選ぶことが多いんだ。SLAをちゃんと読まずにサービスを契約すると、いざ障害が起きたときに「こんな条件だったの!?」って驚くことになるから、契約前に必ず確認すべき大事な書類なんだよ。また、SLAはベンダー(サービスを売る会社)とユーザーだけじゃなく、社内の部門同士でも使われることがあって、その場合は特に内部SLAと呼ばれることもある。

💡 ポイント
稼働率の「9の数」が増えるほど信頼性が高い。業界では「ナイン(9)の数」で比較するのが定番!

⚠️ よくある勘違い

❌ 「SLAを守れなかったら全額返金してもらえる」
→ SLAのペナルティは「全額返金」ではなく、停止時間に応じた一部クレジット(数〜数十%)が基本。「全額返ってくる」と思ってると実際の補償額に驚く。
⭕ 「SLAのペナルティはあくまで一部補償、損失の穴埋めには限界がある」
→ 大規模な障害で事業損失が出ても、SLAクレジットはその損失全体をカバーしない。重要なシステムでは複数のサービスを組み合わせるなどリスク分散が必要。
なるほど〜、あーそういうことか!

[toc]

SLAとは?まず「約束の文書」だと覚えよう

SLAの正式名称と意味

SLAは「Service Level Agreement」の頭文字をとった略語だよ。日本語にすると「サービスレベル合意」、もう少し砕いて言うと「どのくらいの品質でサービスを提供するか、あらかじめ文書で約束したもの」ってこと。

たとえば、友だちに「毎朝8時に教室に来て、宿題わからないとこを教えてあげる。もし来られなかったら次の日2倍教える」って約束するとするよね。これが個人版SLAのイメージ。サービスの世界では「何時間以内に返答する」「1年のうち何%の時間は使えるようにする」「障害が起きたら何時間以内に直す」みたいな約束を文書にまとめるんだ。

なぜSLAが生まれたのか

昔はサービスの品質が「なんとなく良さそう」「信頼できる会社だから大丈夫」みたいな感覚で決められていたんだ。でもビジネスが複雑になってきて、特にインターネット上のサービスが普及してくると、「止まったらどうするの?」「品質が悪かったら誰が責任とるの?」という問題がどんどん出てきた。そこで「最初にルールを明確にしておこう」という考え方が広まって、SLAという文書が定着したんだよ。

今では通信会社・クラウドサービス・SaaS(サース)——つまりインターネット越しに使うソフトウェアサービスのこと——を契約するときには必ずと言っていいほどSLAがついてくる時代になった。

SLAを結ぶのはどんな場面?

主に次のような場面でSLAが登場するよ。

  • クラウドサービス(AWS・Azure・Google Cloudなど)を企業が契約するとき
  • インターネット回線やデータセンターを借りるとき
  • システム開発・運用を外部の会社に委託するとき
  • 企業内で、情報システム部門が他の部門にサービスを提供するとき(内部SLA)

個人がスマホのアプリを使うときはあまり意識しないけど、企業がビジネスで使う有料サービスにはほぼ必ずSLAが存在する。逆に言えば「SLAがないサービス」は品質に関する約束がない、ということになるから要注意なんだ。

SLAに書かれている内容を読み解こう

稼働率(アップタイム)が一番重要

SLAで一番よく見かける指標が稼働率(かどうりつ)、英語では「Uptime(アップタイム)」と言うよ。つまり「1年間または1ヶ月間のうち、サービスが正常に動いている時間の割合」のこと。

「99.9%の稼働率を保証します(SLA 99.9%)」って書いてあったとすると、逆に言うと「0.1%は止まってもいい」ってことになる。これを時間に直すと:

  • 99%:年間約87時間36分の停止を許容
  • 99.9%:年間約8時間45分の停止を許容
  • 99.99%:年間約52分の停止を許容
  • 99.999%:年間約5分の停止を許容

業界では「9がいくつ並んでいるか」で信頼性を表すことが多くて、99.9%なら「スリーナイン」、99.99%なら「フォーナイン」と呼ぶよ。フォーナインになるとかなり高信頼で、それだけ維持コストも高い。

応答時間とサポート対応時間

稼働率のほかに、SLAによく書かれているのが次の2つだよ。

応答時間(レスポンスタイム)——つまり「サービスがリクエストに答えるまでの速さ」のこと。たとえば「ページを開いたら3秒以内に表示される」みたいな約束。ゲームでいうと「操作してから1秒以内にキャラが動く」みたいなイメージだね。

サポート対応時間——「問題が起きたとき、何時間以内に担当者が返答するか」の約束。「重大な障害は1時間以内に初回回答」「一般的な問い合わせは24時間以内」みたいに、問題の深刻さによって区分けされていることが多い。

障害復旧時間(RTO・RPO)

もう少し細かいSLAにはRTORPOという指標も登場する。

RTOは「Recovery Time Objective(目標復旧時間)」、つまり「障害が起きてから何時間以内にサービスを再開します」という約束。RPOは「Recovery Point Objective(目標復旧時点)」、つまり「データをどの時点まで戻せるか」の約束。たとえば「最大でも4時間前のデータ状態には戻せます」みたいな感じ。バックアップがどれくらいの頻度で取られているかに関係する話だよ。

稼働率99.9%の本当の意味を深く理解しよう

「ほぼ100%」の落とし穴

99.9%と聞くと「ほぼ完璧じゃん!」って感じるよね。でも年間8時間45分という数字を改めて見てほしい。たとえばあなたが毎日使うオンライン授業のプラットフォームが、突然8時間以上使えなくなったらどうなる?テスト期間にかぶったら最悪だよね。

これは企業にとってもっと深刻で、たとえばECサイト(ネットショップ)が1時間止まると、その間の売上がまるごとゼロになる。大手のショッピングサイトだと1分間の停止で数百万円の損失が出ることもある。だから「99.9%で十分か、99.99%が必要か」はビジネスにとってすごく重要な判断なんだ。

測定の基準期間に注意

稼働率は「何を基準期間として計算するか」も大事なポイントだよ。「月次で99.9%保証」と「年次で99.9%保証」では意味が違う。

月次(1ヶ月を基準)だと、1ヶ月あたり約43分の停止を許容することになる。一方、年次(1年を基準)だと年間で8時間45分の停止を許容する。でも「今月はずっと快調だったけど来月に8時間止まる」可能性もゼロではない。だからSLAを読むときは「どの期間を基準にした稼働率か」を必ず確認するクセをつけよう。

計画メンテナンスはカウントされない場合も

多くのSLAでは、あらかじめ予告された定期メンテナンス中の停止は「稼働率の計算に含めない」と書かれていることがある。これも見落としがちなポイント。「99.99%保証!」と書いてあっても、毎月深夜に2時間のメンテナンスがあったりすると、実質の可用性はそれより低くなる。SLAの「除外条件」もちゃんと読まないと損するよ。

SLAが守られなかったときの補償のしくみ

サービスクレジットとは

SLAを守れなかったとき、サービス提供会社はお客さんにサービスクレジットを払う義務を負うことが多い。サービスクレジットとは、つまり「次回の請求から一定額を割り引きます」「その分の利用料を返金します」という形の補償のこと。現金で振り込まれることはほぼなくて、次のサービス利用料から差し引かれるのが一般的だよ。

補償の計算は複雑で、たとえば「稼働率が99%を下回ったら月額利用料の10%をクレジット」「95%を下回ったら25%をクレジット」みたいに段階的に決まっていることが多い。つまり、少し守れなかった場合の補償はかなり少ないんだ。

なぜ全額返金にならないの?

「サービスが止まって損したんだから全額返せよ!」って思うかもしれないよね。でも考えてみて。たとえば月額1000円のクラウドサービスが1時間止まって、その間に100万円のビジネスチャンスを逃したとする。この場合でも、SLAの補償はあくまで「1000円の一部(たとえば100円)」に過ぎない。

これは意図的にそうなっているんだ。サービス提供会社は「使用料に見合った補償はする」という立場で、ビジネス上の損失まで責任を持つわけじゃない、という考え方だよ。だから重要なビジネスでは、SLAだけに頼らず自分たちでバックアップ体制を組むことが必要になるんだ。

補償を受けるための手続き

SLAの補償を受けるには、お客さん側から申請が必要なことも多い。「自動的に返金される」わけじゃなくて、「○月○日の◯時〜◯時に障害がありましたよね、SLAに基づいてクレジットをください」と申請する必要があるんだ。申請期限も決まっていることが多いから、障害があったときは記録を残しておくことが大事だよ。

SLAを実際のビジネスでどう活用するか

サービスを選ぶときの比較ポイントに

クラウドサービスやITツールを会社で導入するとき、複数の候補があったとする。そのとき「価格」と「機能」だけで選ぶのではなく、「SLAで何%の稼働率を保証しているか」も重要な比較軸になるよ。

たとえば月額5000円でSLA99.9%のサービスと、月額7000円でSLA99.99%のサービスがあったとき、2000円の差額がシステム停止リスクの削減にどれだけ価値があるかを考えて選ぶんだ。コストと信頼性のバランスをSLAを使って判断できるのは、ビジネスで非常に重要なスキルだよ。

社内でシステムを作るときの設計指針にも

たとえば「うちの会社のオンライン受注システムは年間99.9%以上動かし続けないといけない」という要件があったとする。このとき、使うクラウドサービスのSLAが99.9%だと、そのサービスだけに頼った場合ギリギリか足りないかもしれない。なぜなら自分たちのシステムのバグや人為的ミスによる停止もあるから。

だからシステム設計者は、インフラのSLAを確認した上で「複数リージョン(地域)に分散して冗長化する」「バックアップシステムを持つ」といった設計判断をする。SLAは設計の出発点になる数字でもあるんだ。

契約前にチェックすべきSLAのポイント

実際にサービスを契約するときは、以下の点をSLAで確認しよう。

  • 稼働率の数字と基準期間:何%で月次・年次どちらの計算か
  • 除外条件:計画メンテナンスや自然災害は稼働率に含まれないか
  • 補償の上限と申請方法:最大何%が返金されるか、どう申請するか
  • サポートの応答時間:問題が起きたとき何時間以内に対応してもらえるか
  • SLAの変更権:会社側がSLAを一方的に変更できる条件があるか

これらをしっかり確認してから契約することで、「こんな条件だとは思わなかった」という後悔を防げるよ。SLAは難しそうに見えるけど、結局のところ「どんな品質で・何を約束して・守れなければどうするか」という、人間関係でも当たり前の「約束」を文書にしたものだから、読む姿勢さえ持てばきちんと理解できるはずだよ。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

大人になってから「これ知らなかった…」と恥ずかしい思いをした経験から、このサイトを作りました。お金・仕事・社会のしくみって、学校で教えてくれないのに知らないと損することだらけ。むずかしい言葉を「あーそういうことか!」って思えるまでかみ砕いて説明するのが得意です。主に経済・法律・税金・ライフイベント周りの用語を毎日更新中。

目次