SLAとは？SLO・SLIとの違いと稼働率の決め方・監視実装をエンジニア視点で解説

SLA（サービスレベルアグリーメント）は、提供するサービスの品質を稼働率や応答時間といった数値で約束し、達成できなかったときの補償まで含めて交わす合意です。この記事では、契約書の書式そのものではなく、SLAを支えるSLO・SLIとの階層関係、稼働率99.9%が実際に何分の停止を許すのか、その稼働率をどの分母で計算し何で測定するのか、そしてエラーバジェットで開発速度と信頼性をどう調停するのかを、システムを作って運用する側の解像度で整理します。加えて、受託開発や運用委託でSLAを決めるときの現実的な目標値と交渉項目まで踏み込みます。自社サービスやクライアント向けシステムのSLAをこれから設計する開発者・運用担当者に向けた内容です。

まとめ：SLA・SLO・SLIの関係と稼働率目標の決め方を先に整理

SLAは、SLI（測る指標）→SLO（内部で狙う目標）→SLA（顧客と約束する契約値）という積み上げの、いちばん外側にある対外的な約束です。SLIで稼働率や応答時間を測り、それをSLOとして社内目標に置き、そのうち補償付きで顧客に開示するものがSLAになります。だからSLAだけを先に決めても、測るSLIと運用するSLOが無ければ守れません。

稼働率は数字の桁が1つ増えるたびに許される停止時間が10分の1になります。月間で見ると99.9%は約43分、99.99%は約4分の停止しか許しません。この差を埋めるには冗長化と24時間監視の体制が要り、費用が段違いに上がります。中規模の業務システムなら99.5〜99.9%が現実的な着地点で、99.99%以上は本当に必要かを費用と見合わせて決めます。

実装で外せないのは、稼働率の「計算方法」を先に合意することです。計画メンテナンスを分母から除くか、障害対応時間を受付起点で測るか復旧完了で測るか——ここを曖昧にしたまま数値だけ約束すると、同じ稼働率でも守れる難易度がまるで変わります。SLOには余白（エラーバジェット）を残し、その残量で新機能の投入と安定化のどちらを優先するかを判断すると、開発と運用が同じ数字で会話できます。

SLAの定義とSLA・SLO・SLIの階層構造——指標・目標・契約の役割分担

まずSLAが何を約束する言葉で、SLOやSLIとどう積み重なるのかを押さえます。この3つは似た略語ですが、担う役割と拘束力が異なります。

SLAの定義：サービス品質を数値と補償で約束する対外的な合意

SLAは Service Level Agreement の略で、サービス提供者と利用者の間で、提供する品質の水準を具体的な数値で取り決める合意です。稼働率・応答時間・障害復旧までの時間などを項目ごとに定め、その水準を下回った場合には利用料の減額といった補償が発生する形が一般的です。単なる努力目標ではなく、守れなかったときの結果まで含めて交わす点が、社内目標との違いになります。

ここで押さえたいのは、SLAが「対外的で拘束力を持つ約束」だという性質です。契約書としてどう条文化し、補償や免責をどう書くかは調達・法務の領域に入ります。契約文面としての定義と基本を先に確認したい場合は、SLA（サービスレベル契約）の定義と基本概要を契約視点で解説した記事が対応します。本記事はその約束を技術的にどう作り、どう守るかに軸を置いた解説です。

SLA・SLO・SLIの階層：指標から目標、そして契約への積み上げ方

SLA・SLO・SLIは、下から積み上がる3層で理解すると混乱しません。土台がSLI（Service Level Indicator＝指標）で、稼働率・応答時間・エラー率といった、サービスの状態を数値で測る物差しです。その上にSLO（Service Level Objective＝目標）が乗り、SLIをどの水準まで満たすかを社内目標として置きます。いちばん上のSLAは、SLOのうち顧客に開示し補償付きで約束するものです。

実務では、SLOをSLAより厳しく設定するのが定石です。たとえば顧客への約束（SLA）を月間稼働率99.9%とするなら、社内目標（SLO）は99.95%に置き、SLAに触れる前に自分たちで気づいて動ける余白を作ります。SLIの定義（何を、どの地点で測るか）が全ての土台になるため、指標そのものの設計を掘り下げたい場合はSLI（サービスレベル指標）とSLOの基本概念を解説した記事を先に読むと、この階層の底が固まります。

この積み上げが崩れる典型が、SLAだけを営業段階で先に約束してしまう進め方です。測るSLIも社内SLOも無いままSLAの数字が独り歩きすると、達成できているかを誰も測れず、補償の請求が来て初めて未達に気づきます。

可用性（稼働率）の読み方：99.9%が許す月43分の停止という桁の感覚

SLAで最もよく使われる指標が稼働率（可用性）です。稼働率は「サービスが使えた時間 ÷ 対象期間」で表し、桁が1つ増えるほど許される停止時間が急激に縮みます。30日（43,200分）を分母にした月間の許容停止時間で並べると、桁ごとの重みが体感できます。

99.9%と99.99%は数字の見た目こそ近いものの、月に許される停止が43分と4分では、要求される設計が別物になります。前者は単一障害点をある程度許容できますが、後者は冗長化と自動フェイルオーバー、そして数分以内に検知して切り替える監視が前提です。数字を約束する前に、その桁を支える構成を自社が持てるかを先に見積もってください。

SLAで約束する指標と稼働率の計算・測定を実務でどう実装するか

SLAに載せる数字は、載せた瞬間に「どう測るか」が問われます。ここでは代表的な指標と、稼働率をどの分母で計算し何で測定するか、そして開発と運用を調停するエラーバジェットの実装を見ます。

SLAに載せる代表指標：稼働率・応答時間・復旧時間・エラー率

SLAで数値化する対象は、サービスの性質によって選び分けます。代表的なものは次の4種です。

• 稼働率（可用性）：一定期間でサービスが使えた割合。可用性を約束の中心に置くサービスで採用
• 応答時間（レイテンシ）：リクエストに対する応答の速さ。95パーセンタイルで○ミリ秒以内、のように分布で約束する
• 障害復旧時間：障害発生から復旧までの目標時間。受付までの一次応答と、復旧完了を分けて定義する
• エラー率：全リクエストに対する失敗（5xxなど）の割合。可用性を時間ではなく成功率で測る場合の指標

指標を欲張って並べると、どれか1つが未達でもSLA違反になり、補償の発生確率が上がります。守るべき体験は何か——止まらないことか、速いことか、失敗しないことか——を絞り、中心となる指標を1〜2個に決めてから、残りは社内SLOで見る形にすると運用が回ります。

稼働率の計算式と測定方法：分母の取り方とメンテナンス時間の扱い

稼働率は 稼働率 = (対象時間 − 停止時間) ÷ 対象時間 で求めますが、勝負は「対象時間（分母）に何を含めるか」です。ここの合意がないと、同じ99.9%でも守れる難易度が変わります。詰めるべき論点は主に3つあります。

• 計画メンテナンスの扱い：事前告知した定期メンテを分母から除外するか。除外できれば稼働率は守りやすく、含めれば利用者の実感に近い
• 停止の定義：全断だけを停止とみなすか、一部機能の劣化やエラー率悪化も停止に数えるか
• 測定地点：サーバー側のヘルスチェックで測るか、外形監視（ユーザーに近い外部の地点からの到達性）で測るか

測定は、内部のメトリクス（プロセス死活・HTTPステータス・レスポンスタイム）と外形監視を併用し、SLAで採用する側をあらかじめ明記します。サーバーは生きているのにロードバランサ手前で到達不能、というケースは内部監視では拾えません。実測値をSLIとして蓄積し、月次で稼働率を集計する仕組みまで含めて、SLAは初めて「守っていると示せる約束」になります。稼働後の監視・集計体制を自前で組むか外部に委ねるかは、システム運用の業務範囲と委託判断を整理した記事で全体像を確認すると切り分けやすくなります。

エラーバジェット：SLOの残量で開発速度と信頼性を調停する設計

SLOを100%に置かない理由が、エラーバジェットの考え方です。たとえばSLOを稼働率99.9%とするなら、残りの0.1%（月に約43分）が「許された停止の予算」になります。この予算がまだ残っているうちは、多少のリスクを取ってでも新機能を投入してよく、予算を使い切りそうなら投入を止めて安定化に回す——という判断基準になります。

この仕組みの利点は、開発チームと運用チームが同じ1つの数字で会話できる点です。「もっと速くリリースしたい開発」と「止めたくない運用」は本来対立しますが、エラーバジェットの残量という共通の残高で調停すれば、感情論ではなく予算の増減で優先順位を決められます。SLOとエラーバジェットの設定手順を具体的に踏みたい場合は、SLOの設定方法とSLA・SLIとの違いを解説した記事が実務の手順まで対応します。

受託開発・運用委託でSLAを決めるときの目標値と5つの交渉項目

ここが設計判断の核心です。競合記事は定義とSLO/SLIの違いで終わりがちですが、実務で迷うのは「自社のこのサービスに、どの数字を約束すべきか」です。目標値の現実解と、契約で詰める項目を条件付きで言い切ります。

稼働率目標の現実解：99.5〜99.9%と、99.99%で跳ね上がるコスト

目標稼働率は「高いほど良い」ではなく「支えられる範囲でいちばん低くていい」と考えるほうが実務に合います。中規模の業務システムやWebサービスなら、99.5〜99.9%が現実的な着地点です。この帯なら、適切な監視と冗長化、日中の運用体制でおおむね守れます。

一方、99.99%（月4分）を約束に載せると、要求が一段跳ね上がります。単一障害点の排除、複数系統での冗長化、自動フェイルオーバー、そして数分以内に検知・切り替えできる24時間監視が前提になり、構築費・運用費とも大きく増えます。約束の桁を1つ上げる前に、その桁を本当に事業が必要としているか——たとえば数分の停止が売上や信用に直結するのか——を問い直してください。必要が薄いのに桁を上げるのは、費用だけがかさむ過剰品質です。実際の監視・冗長化・SLA運用の体制づくりから相談したい場合は、保守運用・内製化支援の窓口で、現状の測定と目標設定の切り分けから話を始められます。

SLA契約で詰める5項目：計算方法・対応時間・測定・補償・免責

稼働率の数字が決まっても、次の5項目を曖昧にしたまま契約に進むと、後から解釈が割れます。相見積もりや発注の段階で、必ずそろえて確認してください。

1. 稼働率の計算方法：計画メンテナンスを分母から除外するか、停止を全断だけとみなすか機能劣化も含むか
2. 対応時間の定義：一次応答（受付）までの時間か、復旧完了までの時間か。どちらをSLAの約束にするか
3. 測定方法：どのツールで、内部監視か外形監視か、誰が集計して開示するか
4. 補償の上限と算定：未達時の減額率と、その月額に対する上限。青天井にしない
5. 免責範囲：提供者側が責任を負わない条件（利用者起因の障害、不可抗力、指定外の使い方など）

この5点は機能一覧のカタログには載りません。特に計算方法と対応時間の定義は、契約書の文言で確認しないと、同じ「稼働率99.9%」でも守れる難易度がまるで違ってきます。条文としての補償・免責の書き方まで踏み込む場合は、契約視点でまとめたSLA（サービスレベル契約）の基本概要の記事とあわせて確認すると、技術と契約の両面が埋まります。

SLAを盛りすぎる失敗と、SLOで内部運用にとどめる見送り判断

SLAは、付ければ付けるほど安心なわけではありません。むしろ、守れない約束を対外的に背負う失敗のほうが実務では多く見られます。典型は、営業段階で競合対抗のために99.99%を安請け合いし、支える冗長化も監視も用意しないまま契約してしまうパターンです。この状態では、障害が起きるたびに補償が発生し、信用も費用も削られます。

逆に、SLAとして対外的に約束せず、SLOとして内部運用にとどめる判断が合う場面もあります。社内利用の基幹システムや、まだ利用者が少なく品質の実測データが薄い立ち上げ期のサービスでは、補償付きの数字を約束するより、まず自分たちのSLOで測って改善を回すほうが堅実です。約束は、測って守れる実績が積み上がってから外へ出す——この順番を守ると、SLAが空手形にならずに済みます。数値を約束できるだけの測定と体制が整っているか、を先に確かめてから契約へ進んでください。

よくある質問

SLAの設計でよく挙がる疑問に、作って運用する側の視点で簡潔に答えます。

SLAとは何の略ですか？

SLAは Service Level Agreement（サービスレベルアグリーメント／サービスレベル合意）の略です。サービス提供者と利用者の間で、稼働率や応答時間、障害復旧時間といった品質の水準を数値で取り決め、達成できなかったときの補償まで含めて交わす合意を指します。単なる社内の努力目標ではなく、対外的に拘束力を持つ約束である点が特徴です。

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

3つは下から積み上がる階層です。SLI（指標）は稼働率や応答時間を測る物差し、SLO（目標）はSLIをどの水準まで満たすかの社内目標、SLA（合意）はSLOのうち顧客へ開示し補償付きで約束するものです。一般にSLOはSLAより厳しく設定し、SLAに触れる前に自分たちで気づける余白を作ります。測るのがSLI、狙うのがSLO、約束するのがSLA、と役割で覚えると混同しません。

稼働率99.9%は月にどれくらいの停止まで許容されますか？

30日を分母にすると、99.9%が許す月間の停止は約43.2分です。桁が1つ増えて99.99%になると約4.32分、逆に99.5%なら約216分（3.6時間）になります。稼働率は1桁上がるごとに許容停止が10分の1に縮むため、99.9%と99.99%は見た目が近くても、要求される冗長化と監視の水準がまったく異なります。

SLAの稼働率はどう計算・測定しますか？

稼働率は「(対象時間 − 停止時間) ÷ 対象時間」で計算しますが、分母（対象時間）に計画メンテナンスを含めるかどうかで難易度が変わります。測定は、サーバー内部のヘルスチェックと、利用者に近い地点から見る外形監視を併用し、SLAで採用する側を契約時に明記しておくのが前提です。実測値をSLIとして蓄積し、月次で集計する仕組みまで用意して、初めて達成を証明できます。

SLAの稼働率目標はどのくらいに設定すべきですか？

サービスの性質によりますが、中規模の業務システムやWebサービスなら99.5〜99.9%が現実的な着地点です。99.99%以上は、冗長化・自動フェイルオーバー・24時間監視が前提となり費用が大きく上がるため、数分の停止が事業に直結する場合に限って検討します。高い数字を約束する前に、その桁を支える構成と体制を自社が持てるかを先に見積もることを勧めます。

関連記事

• SLOとは？SLA・SLIとの違いと設定方法をわかりやすく解説：本記事で触れたSLOの設定手順とエラーバジェット運用を、実務の流れで深掘りできます。
• サービスレベル指標(SLI)とサービスレベル目標(SLO)とは何か？信頼性を測る基本概念と役割を解説：SLAの土台になるSLI・SLOの基本概念を、指標設計の視点から確認できます。
• SLA（Service Level Agreement）とは？サービスレベル契約の定義と基本概要：本記事の技術視点に対し、契約書としての補償・免責の書き方など調達・契約の視点を補えます。
• システム運用とは？保守との違い・業務一覧から委託判断まで発注者視点で解説：SLAを守る監視・集計の体制を、社内運用と委託のどちらで持つか判断する材料になります。
• 保守運用・内製化支援：稼働率の測定・監視・SLA運用の体制づくりを相談したい場合の窓口です。