SLA・SLO・SLIの違いとは？クラウドエンジニアが知るべき信頼性指標の実践ガイド

2026年6月6日2026年6月9日

オンプレのシステム運用を長くやっていると、「SLA」という言葉には馴染みがあるはずです。ベンダーとの契約書に書かれた「稼働率99.9%保証」といったアレです。ところがクラウドに移行すると、「SLO」「SLI」という聞き慣れない用語が突然登場し、「SLAと何が違うの？」と戸惑う場面があります。

この記事では、SLI・SLO・SLAの定義と関係を現場目線で整理します。主要クラウドサービスのSLA、稼働率99.9%と99.99%が月間で何分の停止に相当するか、そしてSREで使われるエラーバジェットの考え方まで、実務に直結する内容を一通りカバーします。

なぜクラウド時代にSLO・SLIが重要になったのか

オンプレのシステム運用を思い出してください。信頼性の担保はサーバーの二重化、ストレージのRAID、電源の冗長化といった物理的な多重化が中心でした。ベンダーとのSLAも「ハードウェアが故障したときのサポート対応時間」を定めるものが主でした。

クラウドではこの前提が変わります。
・インフラはコードで定義される: ハードウェアの物理的な状態より、サービスがどれだけ「使えているか」が重要になる
・依存関係が複雑化する: 1つのアプリが数十のクラウドサービスに依存するため、どこかで障害が起きても「全体として動いているか」を評価する指標が必要になる
・継続的デプロイが当たり前になる: デプロイのたびに信頼性が揺れる環境で、「どこまで許容するか」の基準をチームで持つ必要がある

こうした背景から、Googleが提唱したSRE（Site Reliability Engineering）の考え方とともに、SLI・SLO・SLAを使った信頼性の管理手法が業界全体に広まりました。

3つの用語の定義

1. SLI（Service Level Indicator）── 何を測るか

SLIは「サービスの状態を測定する指標」です。数値として計測できるものすべてがSLIの候補になります。

代表的なSLIの例：
・可用性（Availability）: 「正常にレスポンスを返したリクエストの割合」（例：成功レスポンス数 ÷ 全リクエスト数）
・レイテンシー（Latency）: 「リクエストの95パーセンタイル応答時間が200ms以下の割合」
・スループット（Throughput）: 「1秒あたりの正常処理リクエスト数」
・エラー率（Error Rate）: 「5xxエラーが全レスポンスに占める割合」

SLIはあくまで「測定値そのもの」です。「良い悪い」の判断はSLOに委ねます。

2. SLO（Service Level Objective）── どこを目標にするか

SLOは「SLIに対して設定する目標値」です。チームが「このラインを下回ったら問題」と定めるもので、外部への約束（契約）ではなくあくまでチーム内の目標です。

SLOの例：
・可用性SLI ≥ 99.9%（月次ウィンドウ）
・95パーセンタイルレイテンシー ≤ 200ms（1週間ウィンドウ）
・エラー率 ≤ 0.1%

SLOを設定するときは「ウィンドウ（期間）」を明示することが重要です。「99.9%」という数字も、月次で見るか年次で見るかによって許容される停止時間が大きく変わります。

3. SLA（Service Level Agreement）── 外部への約束

SLAは「ユーザーやクライアントとの契約上の保証」です。SLOを外部に開示し、違反した場合のペナルティ（返金・サービスクレジットなど）が伴うのが特徴です。

クラウドサービスのSLAで目にする「月間稼働率99.9%保証」はこれに該当します。AWSやAzureは、SLAを下回った場合にサービスクレジット（利用料の一部返還）を提供するポリシーを設けています。

SLOはSLAより常に厳しく設定するのが鉄則です。たとえばSLAが99.9%なら、社内SLOは99.95%に設定する。こうすることで、SLAを侵害する前に社内でアラートを検知して対処できます。

3つの関係を整理する

用語	日本語	誰のためのもの	違反時の結果
SLI	サービスレベル指標	チーム内（計測値）	なし（ただの数値）
SLO	サービスレベル目標	チーム内（目標値）	対策検討・改善スプリント
SLA	サービスレベル合意	ユーザー・顧客（契約）	サービスクレジット・賠償

一言で言えば、「SLIで測り、SLOで目標を持ち、SLAで約束する」という関係です。

クラウド主要サービスのSLA一覧

AWSとAzureの主要サービスについて、2026年3月時点の代表的なSLAをまとめます。最新情報は各社の公式SLAページで必ず確認してください。

サービス	提供元	月間稼働率保証
Amazon EC2（マルチAZ）	AWS	99.99%
Amazon EC2（単一インスタンス、gp3 EBS使用）	AWS	99.5%
Amazon S3	AWS	99.9%
Amazon RDS（マルチAZ）	AWS	99.95%
AWS Lambda	AWS	99.95%
Azure Virtual Machines（可用性セット）	Azure	99.95%
Azure Virtual Machines（可用性ゾーン）	Azure	99.99%
Azure Blob Storage（GRS）	Azure	99.9%
Azure SQL Database（General Purpose）	Azure	99.99%

重要な点があります。EC2の例で見るように、同じサービスでも構成によってSLAが大きく変わります。単一インスタンスの99.5%とマルチAZの99.99%では、月間許容ダウンタイムに100倍以上の差があります。システム設計時に「どの構成でSLAが適用されるか」を必ず確認してください。

稼働率と実際のダウンタイムの計算

「99.9%」という数字を見ても、実際に何分止まっていいのかイメージできない人は多いです。計算してみましょう。

稼働率	月間（30日）の許容ダウンタイム	年間の許容ダウンタイム
99%（ツーナイン）	約7時間18分	約3日15時間
99.5%	約3時間36分	約1日19時間
99.9%（スリーナイン）	約43分	約8時間46分
99.95%	約21分36秒	約4時間23分
99.99%（フォーナイン）	約4分	約52分
99.999%（ファイブナイン）	約26秒	約5分15秒

オンプレの感覚で「99.9%なら十分だろう」と考えがちですが、月に43分のダウンタイムが許容されるということです。ECサイトや業務システムで43分の停止がビジネスに与える影響を考えると、システムの重要度に応じてSLAを選ぶことがいかに重要かがわかります。

また、複数のサービスを組み合わせる場合は稼働率の掛け算になります。
EC2（99.99%）× RDS（99.95%）× S3（99.9%）≒ 99.84%

依存サービスが増えるほど複合的な可用性は単体のSLAより低下します。3サービスを組み合わせるだけで月間許容ダウンタイムは約43分から約74分に膨らみます。この事実を設計段階で把握しておくことが重要です。

エラーバジェットの考え方

SREでは「エラーバジェット（Error Budget）」という概念を使います。SLOを逆から見た考え方です。

たとえばSLOを99.9%（月次）に設定した場合、月間の「使えるエラー時間」は約43分です。これがエラーバジェットです。

エラーバジェットは、開発速度と信頼性のバランスを取るための道具として機能します。
・バジェットに余裕があるとき: 積極的な機能リリースやデプロイを許容できる
・バジェットを使い切りそうなとき: 新機能リリースを一時停止し、信頼性改善に集中する
・バジェットを超えたとき: 緊急の対策を取り、根本原因の解消を最優先にする

オンプレの運用チームでは「変更は月1回の定期メンテナンスウィンドウのみ」という硬直した方針を取ることが多いですが、エラーバジェットを使えばデータに基づいてリスクを判断できます。「リリースを全て止める」か「全て許可する」かの二択ではなく、バジェットの残量に応じてリリース頻度を柔軟に調整できるのが大きな違いです。

SLOを設計するときの実践Tips

1. ユーザー体験に近い指標を選ぶ

CPU使用率やメモリ使用量のようなインフラ指標ではなく、「ユーザーが実際に感じる品質」に近いSLIを選ぶことが重要です。よく使われるのは次の4カテゴリです。
・可用性（Availability）: 正常レスポンス率
・レイテンシー（Latency）: 応答時間のパーセンタイル
・エラー率（Error Rate）: 5xxエラーの割合
・スループット（Throughput）: 単位時間あたりの処理数

2. SLOは達成できる現実的な値に設定する

「高い方が良い」という直感で99.999%をSLOに設定すると、エラーバジェットが月26秒しかなく、ちょっとしたデプロイや設定変更でも超過します。過去の実績データを元に、現実的な目標値を設定してください。

3. SLAはSLOより必ず低く設定する

社内SLO 99.95%に対してSLAは99.9%というように、SLOとSLAの間にバッファを設けます。このバッファが、SLA違反を未然に防ぐための余裕になります。

4. ウィンドウを明示する

「月次」か「週次」か「四半期」かによって同じ99.9%でも意味が変わります。AWSやAzureのSLAは「月次カレンダー」を基準にしていることが多いため、社内SLOも月次に合わせるとズレが生じにくいです。

AWS・AzureでSLIを計測するツール

実際にSLIを計測するには、クラウドの監視サービスを使います。

AWSの場合

Amazon CloudWatchを使うことで、主要なSLIをほぼすべて取得できます。
・可用性: ALBのHTTPCode_Target_2XX_Countと全リクエスト数の比率
・レイテンシー: ALBのTargetResponseTime（p50・p95・p99）
・エラー率: ALBのHTTPCode_Target_5XX_Count ÷ RequestCount

CloudWatchのComposite AlarmをSLOのしきい値に設定しておけば、SLO違反時に自動でアラートを受け取れます。ALBのレイテンシーをAWS CLIで取得する例です。


# AWS CLI: ALBのp95レイテンシーを過去1時間で取得
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name TargetResponseTime \
  --dimensions Name=LoadBalancer,Value= \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 \
  --statistics p95 \
  --region ap-northeast-1

Azureの場合

Azure Monitorが同様の役割を担います。Application Insightsを使うと、アプリケーションレベルの可用性・レイテンシー・エラー率を詳細に把握できます。Azure Monitorのアラートルールにメトリクスのしきい値を設定することで、SLO違反を検知できます。

よくある落とし穴と対処法

落とし穴1: クラウドのSLAを「自分のシステムのSLA」と混同する

AWSのEC2のSLAが99.99%でも、その上で動くアプリケーションが99.99%稼働するわけではありません。クラウドの障害、デプロイの失敗、アプリのバグ、依存するDBのダウン、これらすべてを考慮すると、エンドユーザーが体験する実際の可用性はクラウドSLAよりも低くなります。

対処法は「ユーザー体験を直接計測するSLIを持つこと」です。合成監視（Synthetic Monitoring）でユーザーのログインフローや主要操作を定期的にテストし、その成功率をSLIとして使うのが現場では効果的です。

落とし穴2: 複数サービスのSLAを掛け算せずに使う

先ほどの計算例が示すとおり、サービスを組み合わせるほど複合的な可用性は低下します。「マルチAZだから99.99%保証」という認識で止まっていると、実際の稼働率を過大評価することになります。依存関係の全体像を把握した上でシステム全体のSLOを設計してください。

落とし穴3: SLOを設定したまま見直さない

ユーザーの利用パターンやシステムの規模が変われば、SLOも見直す必要があります。立ち上げ時は99.9%で十分でも、ユーザー数が10倍になれば99.99%が求められるかもしれません。四半期に1度はSLOの妥当性を振り返る習慣をつけることをすすめます。

本記事のまとめ

・SLI（指標）: 何を計測するかを定める。可用性・レイテンシー・エラー率が代表的
・SLO（目標）: SLIに対してチーム内で設定する目標値。SLAより厳しく設定する
・SLA（契約）: ユーザーや顧客への外部公約。違反時にはサービスクレジット等が発生
・エラーバジェット: SLOを逆から見た「許容できる障害の余地」。開発速度と信頼性のバランスを数値で管理する
・稼働率99.9%: 月間43分の停止を許容するということ。99.99%では月わずか4分になる
・複合稼働率: 依存サービスが増えるほど実際の可用性は下がる。設計段階で掛け算を確認すること

オンプレの「ハードウェアを二重化すれば信頼性が上がる」という感覚から、「SLIで測り、SLOで目標を持ち、エラーバジェットで開発速度と信頼性をコントロールする」という考え方へのシフトが、クラウド運用の大きな転換点です。

LinuxサーバーのOS・アプリケーション層の監視については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。クラウド監視と合わせて参考にしてください。