SLAとは？意味、見るべき項目、違反時の扱いを分かりやすく解説

クラウドサービスやSaaSを選ぶときは、「どこまで面倒を見てもらえるのか」「止まったときに何が起きるのか」を先に確かめる必要があります。そこで見るのがSLAです。SLAは、サービスを出す側と使う側が、どの水準でサービスを出すか、止まったときにどう動くかを文書で決めるものです。

• まず見る点：稼働率の数字だけでなく、何をどう測るか
• 見落としやすい点：除く条件、責任の切り分け、申請のしかた
• 違反時の見方：自動で全てを補う扱いになるとは限らず、利用料の一部を返す扱いなどにとどまることが多い

SLA基本

SLAとは

SLA（Service Level Agreement）とは、サービスを出す側と使う側が、サービスの水準や支援の条件を決めて文書にした取り決めです。クラウドサービスやSaaSでは、使う側がサービスの中身を直接は管理しないことが多いため、何をどこまで求められるかをそろえるために使われます。

SLAで決めるのは、「良いサービスです」という説明ではありません。稼働率、返答までの時間、障害が起きたときの連絡、窓口の受け付けなどを、どう測るかも含めて書きます。読む側にとっては、問題が起きたときに何を基準に見ればよいかを決める文書だと考えると分かりやすいでしょう。

SLAは、契約の本文に入ることもあれば、利用の規約、仕様書、支援の方針などの別文書で示されることもあります。どの形でも、サービスを出す側が何を約束するかを共有する役目は同じです。

ただし、SLAがあるからといって、いつでも安定して動くと受け取るのは危険です。SLAには、何を対象にするかだけでなく、何を対象から外すかも書かれます。現場では、対象から外れる条件まで読んではじめて使える文書になります。

SLAの役割

SLAには、まず使う側を守る役目があります。たとえば稼働率や復旧までの目安が見えていれば、停止が業務にどう響くかを見積もりやすくなります。その情報は、監視の作り方や代わりの手段、BCPを考えるときにも役立ちます。

また、SLAで決めた水準を下回ったときに、サービスクレジットのような救済が用意されることがあります。ただし、違反したら自動で損害が全て埋まる、という扱いが普通というわけではありません。多くは、上限、申請の期限、必要な記録などが決められており、その条件を満たしたときだけ適用されます。

もう一つの役目は、サービスを出す側が日々の運用を整えやすくすることです。SLAを掲げるなら、監視、障害への対応、窓口の体制を続けて見直す必要が出ます。その結果、運用の質を保ちやすくなります。

さらに、SLAは双方の認識をそろえる助けにもなります。障害が起きたときに、「どこまでが出す側の責任か」「いつまでに何をするのか」があいまいだと、復旧そのものより話し合いで消耗しがちです。SLAは、そのずれを減らすための共通の物差しです。

SLAの主な内容

SLAに書かれる中身はサービスごとに違いますが、現場でよく出る項目には共通点があります。代表例は次の通りです。

• 可用性：月や年で見た稼働率、どの機能を計算に入れるか
• 性能：返答までの時間や処理量の目安、測るときの条件
• 障害への対応：障害の定義、知らせ方、最初の返答までの時間、復旧の目安
• サポート：受け付け時間、連絡の手段、どこまで受けるか
• データ保護：バックアップの回数、保管する期間、戻し方
• セキュリティ：責任の切り分け、ログの扱い、弱点が見つかったときの方針

ここで見落としやすいのは、数字そのものより、どう測るかと、どんな条件で当てはめるかです。たとえば稼働率でも、どこで測るのか、計画メンテナンスを入れるのか、利用者側の回線トラブルをどう扱うのかで意味が変わります。

また、違反したときの救済については、内容だけでなく、申請の期限、必要な記録、計算のしかた、上限も見ておく必要があります。現場では、違反していても申請の条件を満たせず適用されないことがあるためです。

SLAの意義

SLAの意義は、サービスの質を「約束」として示し、選ぶときと使うときの判断を支える点にあります。使う側にとっては、選定時の比べる材料になるだけでなく、導入後の監視や障害時の動き方を決める土台にもなります。

出す側にとっても、SLAは品質への向き合い方を示す手段です。似た機能のサービスが並ぶ分野では、何を、どこまで、どんな条件で約束するのかが、選ばれる理由の一つになります。

一方で、SLAがあっても、中身があいまいだったり前提が読みにくかったりすると、障害時にかえって混乱を招きます。SLAは、トラブルを避けるために現場で使う文書として、読む側が判断できる書き方になっていることが大切です。

SLAの中身

SLAを見るときは、稼働率の数字だけを追うだけでは不十分です。どこまでを対象にするのか、何を指標にするのか、未達のときにどう扱うのかをまとめて見る必要があります。ここでは、条件の例、対象の決め方、指標の考え方、見直しで見る点を確認します。

SLAの具体的な条件例

SLAには、サービスの質を見るための条件が書かれます。よくある項目は次の通りです。

1. サービスの稼働率
2. 返答までの時間
3. 障害を知らせる方法と時間
4. 復旧までの目安や最初の返答までの時間
5. バックアップの回数、保管する期間、戻すときの制約

ここで大事なのは、条件が数字だけで終わらないことです。たとえば返答までの時間が書かれていても、混む時間帯をどう扱うか、出す側で測るのか、使う側で測るのかが分からなければ、障害時に合意が崩れます。条件は、数字と測り方がそろってはじめて使えます。

SLAの対象の決め方

主要な点の一つが、どこまでをSLAの対象にするかです。ここがあいまいだと、「止まった原因は出す側にあるのか、使う側の環境にあるのか」で話が止まりやすくなります。

よく見る点は次の通りです。

• 責任の切り分け：出す側が管理する部分と、使う側が管理する部分
• 除く条件：計画メンテナンス、使う側の設定ミス、外の回線の問題など
• 対象の機能：サービス全体なのか、一部の機能なのか
• 対象の時間：24時間365日なのか、業務の時間だけなのか

なお、違反したときの扱いは、項目ごとに保証が付く場合と、目安として示されるだけの場合が混ざることがあります。ここでいう保証も、損害の全てを補う意味ではないことが多く、実際にはサービスクレジットのような限定的な扱いにとどまる例が目立ちます。

SLAにおける指標

指標とは、サービスの状態を数字で見て、約束を守れたかどうかを判定するための基準です。SLAが現場で役立つかどうかは、この指標がどこまで具体的かに大きく左右されます。

たとえば稼働率を見る場合でも、次の点があいまいだと判断できません。

• 計算のしかた
• どの監視の結果を使うか
• どこからを停止とみなすか
• 計画メンテナンスを外すかどうか

指標は、サービスを比べるためだけのものではありません。使う側は、その指標に合わせて監視や運用の手順を組み、必要なら冗長化や代わりの手段も考えます。そこまで見てはじめて、現実的なリスク低減につながります。

SLAの見直しと更新

組織の状況や技術の前提は変わるため、SLAも定期的に見直されることがあります。機能の追加、データ保護の要件の変更、支援の体制の変更などがあれば、SLAの中身も変わり得ます。

使う側としては、SLAの改定が運用や費用にどう響くかを見ておく必要があります。特に、稼働率の計算のしかた、免責、受け付け時間の変更は、現場にそのまま影響します。契約時には、変更の知らせ方、同意までの手順、いつから変わるかを確認しておくと安全です。

サービス品質の合意

SLAの中心にあるのは、サービスの質についての合意です。ここがそろっていないと、平常時は表に出なくても、障害や性能が下がることが起きたとたんに判断の基準が揺れます。すると、話し合いにかかる手間が一気に増えます。

なぜサービス品質の合意が重要か

サービスの質について合意が要るのは、使う側と出す側の期待をそろえるためです。サービスの質は体感で語られやすいものの、体感は使い方や業務への影響で変わります。そこでSLAにより、達成か未達かを判定できる基準を置きます。

出す側は、その基準を前提に日々の責任を切り分け、使う側は、その基準を前提に業務を続ける計画や社内への説明を組み立てます。こうして、誤解や無用な対立を減らせます。

サービス品質の合意に必要な要素

サービスの質について合意するには、数字を並べるだけでは不十分です。少なくとも次の点がそろっている必要があります。

• 指標：稼働率、返答までの時間、障害時の最初の動きなど
• 測り方：どこで、どう測り、どう記録するか
• 前提となる条件：使う側が満たすべき設定や運用
• 責任の切り分け：どこまでが出す側で、どこからが使う側か
• 未達時の扱い：救済、申請、上限、免責

また、SLAが利用の規約などの定型文として示される場合は、あとから改定されることもあります。通知の方法、適用日、異議を出せるかどうかといった手続き面も見ておくと、不意打ちを避けやすくなります。

サービス品質と顧客の満足

サービスの質についての合意は、使う側の満足にもそのままつながります。約束した水準が保たれていれば、使う側は「約束どおりに出ている」と確認でき、出す側への信頼も積み上がります。

逆に、質が下がったときに説明や対応がSLAに沿っていないと、「止まったこと」以上に不信が強まります。SLAは、契約の条項であるだけでなく、問題時の説明する責任を支える枠組みでもあります。

質の見直しへの取り組み

SLAは、質を良くしていくための道具としても使えます。出す側は、SLAで決めた指標を見ながら、障害や劣化の傾向を調べ、運用を改めていけます。

使う側も、SLAに基づく報告や稼働の記録をもとに、追加の対策、プラン変更、冗長化の要否を判断できます。大切なのは、SLAを「守ったか、守らないか」だけで見るのではなく、質を育てる材料として使うことです。

サービス提供者と顧客間の認識合わせ

ITサービスは技術の要素が多く、責任の切り分けも複雑になりやすいため、認識がそろっていないとトラブル時に混乱が広がります。SLAは、その認識合わせを制度として残し、判断の基準を共有するために使われます。

ユーザーとサービス提供者のコミュニケーション

使う側と出す側は、契約の前後で話し合いを重ね、必要な水準や運用の前提をすり合わせます。この過程はSLAを決めるうえで大切です。使う側は、「何分止まると業務に響くのか」「混む時間帯にどれだけの性能が要るのか」といった条件を言葉にする必要があります。

出す側も、自社で約束できる範囲と、使う側に守ってほしい条件を明確にします。SLAは、その合意を文書に固定して、運用に引き渡すための道具です。

SLAを通じた認識のズレの解消

SLAは、使う側が期待する水準と、出す側が実際に出せる水準のずれを埋めるための枠組みです。たとえば「24時間365日止まらない」と受け取られがちなサービスでも、実際には計画メンテナンスや外の要因の影響を受けます。SLAでは、そうした条件を定義し、どの状態を停止や違反とみなすかを決めます。

また、SLAには、質を保つために要る前提が入ることがあります。たとえば、使う側で特定の設定を行うこと、推奨する環境を満たすこと、つなぐ経路の条件を守ることなどです。こうした前提を満たさない場合、SLAの評価の対象に入らないこともあります。

信頼が深まる理由

SLAは品質に関する約束を文書で示すため、出す側と顧客の信頼を作りやすくします。特に価値が出るのは障害時です。連絡、最初の返答、当面の対応、再発を防ぐ説明がSLAに沿っていれば、顧客は状況をつかみやすく、社内の調整も進めやすくなります。

逆に、SLAがあっても情報の共有が遅れたり、基準があいまいだったりすると、不信は強まります。SLAは、書面の文言だけでなく、運用でどう動くかまで含めて信頼を支える仕組みです。

長期的な関係性

SLAは、出す側と顧客が長く付き合うための土台にもなります。顧客はSLAをもとに、そのサービスを使い続ける価値とリスクを見ます。そのうえで、必要ならプラン変更や追加の導入を考えます。

出す側も、SLAを通じて必要な水準と運用の条件を明確にできれば、過度な期待や無理な要求を避けつつ、顧客に合った提案ができます。長い関係は、「止まらないこと」だけでなく、止まったときの説明と、その後の見直しで支えられます。

SLA違反時の責任

SLA違反とは、SLAで決めたサービス水準を満たせなかった状態を指します。典型例としては、稼働率が目標を下回った、性能が大きく落ちた、障害時の連絡や最初の返答が約束した時間内に行われなかった、といった場合です。

ただし、現場では、違反かどうかを決める前に、まず計測の前提と、対象から外す条件を確認する必要があります。たとえば計画メンテナンスを外す契約なら、同じ停止でもSLAの計算に入りません。使う側の回線トラブルや設定ミスが原因なら、出す側の責任ではないとされることもあります。

SLA違反時の責任や救済は、契約の定めに従います。一般には、サービスクレジットのような限定的な救済が決められ、損害の賠償は別の条項で範囲や上限を定める形が多く見られます。つまり、SLA違反は「罰則」というより、合意した条件に沿って処理する契約上の話として見るのが現実的です。

SLA違反の判定の基準

SLA違反の基準は、SLAそのものの中で決められます。よく使われるのは、可用性、返答までの時間、エラー率、障害時の連絡や最初の返答までの時間などです。大切なのは、基準が具体的で、測り方も合意されていることです。

たとえば可用性なら、月の稼働率が基準を下回ったら違反とする、といった決め方が一般的です。ただし、停止の定義、どこで測るか、何を外すかがあいまいだと、違反とみなすことそのものが難しくなります。

また、軽い性能が下がることは対象外にする、優先度で対応までの時間を変える、といった運用もあります。その場合は、どの条件でその扱いになるのかを確認しておく必要があります。

SLA違反時の対応

SLA違反時の扱いは、項目によって、未達時に救済が付くものと、目標として示されるものが併存することがあります。たとえば可用性は救済の対象でも、問い合わせ対応は目安として書かれるだけ、という形です。現場では、SLA全体を一律に「全て保証される」と受け取らず、項目ごとに見る必要があります。

さらに、救済が自動で付くとは限らず、使う側の申請が必要な場合があります。期限、必要な情報、出す側が採用する計測の結果などが定められていると、その手順を踏まない限り適用されません。運用の担当者は、障害時の手順の中に、SLAの適用の確認と申請を入れておくと取りこぼしを減らせます。

SLA違反時のどちらがどこまで負うか

どちらがどこまで負うかは、原因と免責で変わります。出す側の不具合や運用ミスが原因なら、SLAで決めた救済の対象になる可能性があります。反対に、天災、大規模な外で起きた障害、使う側の不備などは、出す側の責任外として外されることがあります。

ここで大切なのは、免責があること自体より、免責の範囲があいまいだと「何が責任外か」を巡って話が止まり、復旧や見直しが遅れる点です。契約時には、どんな事例が外れるのか、第三者による要因をどう扱うのかまで確かめておくと役立ちます。

SLA違反をどう捉えるか

SLA違反は、使う側への影響だけでなく、出す側の評価や信頼にもつながります。そのため、違反が起きたときは、早く、かつ中身が見える形で知らせることが大切です。事象の概要、影響が及ぶ範囲、当面の対応、戻る見込み、再発を防ぐ方針を、段階ごとに更新しながら共有する必要があります。

また、SLA違反を問題の終わりと見るのではなく、見直しの出発点として扱うことも重要です。再発を防ぐ策を詰め、必要ならSLAの指標や対象を見直すことで、契約と運用のずれを減らし、長い関係の安定につなげられます。