「当社のSaaSは稼働率99.9％です」。魅力的に聞こえる数字ですが、誰が、何を、どの期間に、どの方法で測定した割合でしょうか。稼働率の説明だけで、障害時の対応や契約上の保証まで分かるとは限りません。
クラウド製品やBtoB SaaSの信頼性を説明するときに登場するのが、SLI・SLO・SLAです。似た略語でも、測定する事実、社内で目指す水準、顧客との約束は異なります。GoogleのSite Reliability Engineering（SRE）原典とGoogle Cloudの資料をもとに、実務での使い分けを整理します。
SLI・SLO・SLAの違いを、最初に整理する
- SLI（Service Level Indicator）：サービスが実際にどう動いているかを表す指標。例：正常に完了したリクエストの割合、一定時間内に完了した処理の割合。
- SLO（Service Level Objective）：SLIに対して設定する目標。例：特定の計測期間で、要求の99.9％が正常に処理されることを目指す。
- SLA（Service Level Agreement）：提供者と顧客の間で合意するサービス水準や条件。測定方法、対象、救済措置などを定めることがある。
Google Cloudの公式「Concepts in service monitoring」は、SLIをパフォーマンスの測定、SLOを望ましい水準の表明として説明しています。一方、SLAはサービスや契約によって具体的な内容が異なります。
測定値があること、社内目標を設定したこと、契約で約束したことを同じ言葉にしないのが重要です。
SLI――何を「正常」と数えるかで意味が変わる
例えばBtoBの請求書処理APIを考えます。サーバーがHTTPで応答しただけで業務処理は成功でしょうか。形式の誤りで処理できなかったとき、顧客の入力が不正だったとき、タイムアウトしたときはどうでしょう。
SLIを決めるには、単に「成功率」を測るのではなく、対象となる処理と成功の条件を明確にする必要があります。
- 対象となる操作：ログイン、データ照会、帳票出力、外部連携など、どの利用者操作か。
- 分母：全リクエストなのか、契約上の対象となる有効なリクエストなのか。
- 正常の定義：応答が返ったことか、一定時間内に業務上必要な結果が得られたことか。
- 除外条件：利用者の操作、第三者サービス、計画停止などをどう扱うか。
- 観測場所：アプリケーション内部からか、利用者側から見た結果か。
Google Cloudの監視資料では、リクエスト単位と時間窓単位のSLIを区別しています。同じ「99.9％」でも、成功したリクエストの割合と、条件を満たした時間窓の割合は直接同じ意味になりません。
SLO――品質目標には期間と対象が必要
SLIの定義が揃ったら、どの水準を目指すかを決めます。これがSLOです。Google SRE Workbookは、組織の関係者が合意したSLOを設け、その結果を改善や開発優先順位に利用することを重視しています。
例えば「請求データの登録APIについて、対象期間中の有効な要求の99.9％が定めた時間内に正常完了する」という目標を仮に設定できます。ここでの99.9％は本記事の説明用の架空目標であり、実在製品の保証水準ではありません。
また、SLOを機械的に100％へ近づけることがいつも適切とは限りません。より高い信頼性を実現するには、冗長化、監視、変更手順、復旧体制など追加の費用や運用が必要になる場合があります。顧客にとって重要な操作と、合理的に運用できる水準を合わせて検討します。
SLA――契約上の条件と補償を確かめる
SLAは、サービス提供者と顧客の間で何を約束するかを扱います。契約や公表条件の名称が同じでも、その内容は製品ごとに異なります。
実際にGoogle CloudのSLA一覧はサービスごとに公開されており、Cloud ObservabilityのSLAでは「Monthly Uptime Percentage」や「Financial Credits」などの条件が定められています。一定の水準を下回ったら無条件で全額返金するといった単純な約束ではありません。適用範囲、請求手続き、例外、救済措置の定義を読む必要があります。
また、公式のSLA文書でも、契約で約束する水準を「SLO」と呼ぶ場合があります。したがって「SLOは必ず社内のみで、SLAに書かれた目標はSLOと呼ばない」という絶対的な区別も不適切です。数字の名前より、それがどの文書にあり、何の権利・義務に関係するかを確認しましょう。
エラーバジェット――100％との差をどう運用するか
Google SREの重要な考え方に、エラーバジェット（error budget）があります。ある期間のサービス目標から、どの程度の失敗や不安定さを許容できるかを定量的に考え、信頼性の改善と新しい機能の提供を調整します。
例えばリクエスト単位のSLOが99.9％なら、対象となるリクエストの0.1％が正常条件を満たさなくても、数値上は目標内です。ただし、これは「必ず0.1％の障害を起こしてよい」と顧客へ説明するための免罪符ではありません。
エラーバジェットを超えるような状況であれば、変更作業を見直し、信頼性の回復に資源を割くといった判断が考えられます。Google SRE Workbookは、目標だけを掲げても、運用の優先順位に結びつけなければ単なる報告用KPIにとどまると指摘しています。
エラーバジェットの計算も、リクエスト単位なのか時間単位なのか、対象期間が月なのか四半期なのかで異なります。実際の契約上の補償条件とも自動的に一致するものではありません。
「99.9％」と「99.99％」をそのまま比較しない
営業資料に二つのクラウド製品の稼働率が書かれていたとします。片方が99.9％、もう片方が99.99％であっても、定義の異なる数字なら単純に比較できません。
- 同じ操作やサービス範囲を対象としているか。
- 同じ計測期間、タイムゾーン、計算方法か。
- 成功リクエスト率か、稼働時間の割合か。
- 計画停止、外部回線、利用者環境などの扱いは同じか。
- 数値が目標なのか、過去の実測なのか、契約上の約束なのか。
- 障害時に何を通知し、誰が復旧作業と顧客対応を行うのか。
たとえ測定対象が同じでも、止まった業務の重要度や復旧方法によって、顧客が受ける影響は変わります。高い数字だけでなく、顧客の業務がどのような条件で継続できるかを説明する必要があります。
架空例――営業資料とエンジニアの報告が食い違う
以下は実在企業の業績や障害実績ではなく、説明用の架空例です。営業は「99.9％の稼働率」とWebサイトへ記載しようとしています。しかしエンジニアが毎月確認しているのは、特定APIの成功リクエスト率でした。さらにサポート担当は、一部の顧客にとって重要な夜間のバッチ処理が失敗したとき、どこに連絡するかを重視しています。
この場合、成功リクエスト率をそのまま「システム全体の稼働率」と言い換えることはできません。また内部で目指しているSLOを、顧客に対する契約上のSLAと同一視してはいけません。
営業・技術・法務・サポートは、測定の定義、SLO、顧客向けの説明、契約上の保証、障害通知の実務を確認します。数字を魅力的に見せるためではなく、顧客がどの条件で製品を利用できるかを正しく判断できることが目的です。
Webサイトや提案書では、どこまで公開すべきか
技術資料で詳細な指標や監視方式を説明する必要がある一方、最初の製品紹介ページへ全ての監視項目を列挙する必要はないかもしれません。ただし、買い手が重要な条件を調べられるように、概要と詳細資料への導線は用意したいところです。
実績値を公開する場合は、どの期間の結果か、未確認のデータがないか、障害をどうカウントしたかを示します。SLAが存在する場合、適用するプラン、条件、例外と正式文書へのリンクを明記します。
SLAに記載のない復旧時間やデータ復元を勝手に保証しないことも重要です。可用性と、データを失わずに復旧できるかどうかは別の問題です。障害時の通知の設計はBtoBサービス障害時の案内方法も参照できます。
開発・営業・法務で確認するための7項目
- 1. 対象：どの機能・API・環境・顧客プランの信頼性を説明するのか。
- 2. 指標：成功や失敗、遅延、可用性を何で測るのか。
- 3. 期間：集計単位と、メンテナンスなどの除外条件をどう扱うか。
- 4. 目標：内部のSLOはいくつで、誰が決め、どの頻度で見直すか。
- 5. 約束：契約上のSLAの条件と、顧客が取れる対応は何か。
- 6. 障害対応：発見、通知、回復、報告、再発防止を誰が担うか。
- 7. 公開表現：営業資料の数値や保証が、技術上の事実と契約に一致しているか。
これらは本サイトによる実務上の整理です。特定の契約について、必須条項や法的効果を定める助言ではありません。
まず小さなSLOを作る場合の手順
まだサービス品質の目標を正式に管理していないチームなら、利用者にとって重要な操作を一つ選び、何を正常とするかを定義します。次に、過去の実測値と計測漏れ、顧客の業務上の重要性、追加の費用を確認します。
そこから関係部署で暫定的な目標を合意し、監視の結果を見ます。実際に運用すると、初めに選んだ指標が顧客の体験を十分に表していないことに気づく場合もあります。SLOを「一度決めたら変更しない宣言」ではなく、利用状況を踏まえて見直すものとして扱います。
何らかの数値が取れるからといって、それがすぐ顧客へ公開できる実績になるわけではありません。まず指標定義と計測の安定性を確認しましょう。
生成AIを使う場合も、保証条件の確認を省かない
生成AIに障害報告書や技術仕様の要約を書かせることはできます。しかし「稼働率は業界最高」「必ず復旧する」「法定基準に準拠」といった、確認していない表現を追加してはいけません。
AIが作成した概要は原資料と照合し、測定期間、対象プラン、除外条件、契約上の責任を人が確認する必要があります。数値の見せ方が印象に与える影響はBtoBレポートで数字を誤解させない方法も参考になります。
まとめ――信頼性は数字の高さだけでは語れない
SLIは実際のパフォーマンスを測る指標、SLOはその目標、SLAは契約や公表文書で定める合意です。目標と実測と契約を混同せず、利用者にとって重要な操作・期間・除外条件を揃えることで、数字の意味を明確にできます。
大きな数字を広告に使う前に、その数字が何を測り、何を約束しないか説明できるか。 それがBtoB SaaSやクラウドサービスの信頼を支える基本です。
参考資料・確認範囲
- Google SRE Workbook「Implementing SLOs」：SLOとエラーバジェットを用いた信頼性管理の原典。公式公開本文を参照。
- Google Cloud「Concepts in service monitoring」：SLI、SLO、エラーバジェット、リクエスト単位と時間窓単位の定義。
- Google SRE Book「Embracing Risk」：目標とエラーバジェットを用いた開発・運用の判断。
- Google Cloud「Service Level Agreements」：サービスごとにSLAが存在し、条件が異なることの確認。
- Google Cloud Observability「Service Level Agreement」：対象サービス、月間稼働率、補償などの定義例。閲覧時の条件を確認する必要があり、将来の契約内容を保証するものではない。
本文の架空SaaS事例、7項目、公開表現の点検方法は当サイトの編集提案です。Googleが同じBtoBマーケティング手順の成約効果を直接実証したことを意味しません。契約・保証条件は利用する製品の最新の正式文書を確認してください。