稼働率99.9%は「止まらない約束」ではない｜SLAが本当に定義しているのは返金の条件

稼働率99.9%は「止まらない約束」ではない｜SLAが本当に定義しているのは返金の条件

クラウドやSaaSの選定会議で、「このサービスはSLAで稼働率99.9%が保証されているので、止まる心配はほぼありません」という説明を聞いたことはないでしょうか。99.9%という数字は、ほとんど止まらないことの約束に聞こえます。

ところが、実際にSLAの文書を読んでみると、そこに書かれているのは「止まらないこと」ではありませんでした。書かれているのは、目標を下回ったときに、何をどう数え、いくら返すかという精算のルールです。

この記事では、Google Cloud Compute Engine（Googleのクラウドで仮想マシンを提供するサービス）のSLAを1つ取り上げて、その中身を読みます。扱うのはこの1社1サービスだけで、クラウド一般の話に広げることはしません。そのかわり、どのサービスのSLAにも当てはめられる読み方を残すことを目指します。

30秒で要点

• Compute EngineのSLAは、稼働率の数字を自ら「SLO（目標）」と呼んでいる
• 目標未達時の唯一かつ排他的な救済は、将来の請求に充当されるクレジット。上限はその月の該当サービスの支払額
• 停止として数えるのは1分以上連続した停止だけで、1分未満の断続的な停止は数えない
• クレジットを受けるには、60日以内にログを添えて申告する必要がある
• SLAは「何を停止と数えるか × どの粒度で数えるか × 未達時に何が返るか」の3点で読む

読んだのは、Google Cloud Compute EngineのSLA

読んだ文書は、Compute Engine Service Level Agreement です。ページ下部の記載によると最終更新は2025年3月4日で、この記事の内容は2026年9月時点で公開されている版に基づきます。

最初に目に留まったのは、数字の呼び方です。この文書は、Googleが提供する月間稼働率（Monthly Uptime Percentage）の水準を、自ら 「Service Level Objective（SLO）」 と呼んでいます。SLA（取り決め）という名前の文書の中で、中心にある数字は「目標」と呼ばれているのです。

では、目標値はいくつなのか。Premium Tier（メキシコとストックホルム以外のリージョン）では、次のように定められています。

Standard Tierでは、複数ゾーンとロードバランシングがともに99.9%以上、メキシコとストックホルムでは複数ゾーンとロードバランシングが99.95%以上です。

つまり「99.9%」は、この文書では単一インスタンスの目標値です。同じ文書の中で、複数ゾーンの構成には99.99%という、より高い目標値が置かれています。「99.9%のサービス」と一言でまとめると、どの構成の話なのかが抜け落ちます。

1つ目の要素：何を「停止」と数えるか

稼働率を計算するには、まず何を停止（Downtime）と数えるかを決める必要があります。この文書の定義は次のとおりです。

• 仮想マシン: 外部との接続性、または persistent disk へのアクセスが失われた状態
• ロードバランシング: Googleのシステム障害によって、正常な状態のバックエンドのインスタンスすべてへの外部接続性が失われた状態

さらに、適用除外も定められています。たとえば、一般提供（GA）前の機能、Googleの合理的な管理の外にある要因、利用者側や第三者のソフトウェア・ハードウェアに起因するエラー、契約に違反する行為に起因するものなどです（除外項目はこれで全部ではありません）。

ここで考えたいのは、利用者が「止まった」と感じる状態と、SLAが「停止」と数える状態が、同じとは限らないことです。たとえば、自社のアプリケーションの不具合でサイトが表示されない状態は、利用者から見れば「止まっている」状態ですが、利用者側のソフトウェアに起因するエラーは適用除外に含まれます。

2つ目の要素：どの粒度で数えるか

次に、停止をどの細かさで数えるかです。この文書では、次のように定められています。

• 停止期間（Downtime Period） は、1分以上連続した停止の期間
• 1分未満の部分的・断続的な停止は、停止期間に数えない
• 月間稼働率は、(その月の総分数 − 停止の分数) ÷ その月の総分数

ここから、筆者の推論として1つの例を考えます。30秒の停止が1か月に20回あったとします。それぞれが1分未満なので、定義上はどれも停止期間に数えられず、稼働率は100%のままです。利用者側から見れば、合計10分、20回にわたって接続できない時間があったにもかかわらず、です。

「99.9%」を時間に直すと、どれくらいになるでしょうか。これも筆者の計算ですが、30日の月（43,200分）で計算すると、99.9%を下回らない停止の上限は約43.2分、99.99%なら約4.3分です。この「分」は、1分以上連続した停止だけを数えた分であることに注意が必要です。

3つ目の要素：未達のとき、何が返ってくるか

では、目標を下回ったら何が起こるのか。この文書は次のように定めています。

• 目標を下回り、利用者が自分の義務を果たしていれば、Financial Credit（利用料金に充当されるクレジット）を受け取れる
• クレジットは、将来の月の請求に充当される
• このSLAは、目標未達に対する利用者の唯一かつ排他的な救済（sole and exclusive remedy）を定めたものとされている

クレジットの率は、構成ごとに別の表で決まっています。2つの表を混ぜないように、並べて見ます。

さらに、受け取るための条件があります。

• 対象となってから60日以内に、Googleのテクニカルサポートへ通知する
• 停止期間とその日時を示すログを提出する
• これを行わなければ、クレジットを受け取る権利を失う
• 1か月のクレジットの総額は、目標を下回ったリージョンの該当サービスについて、その月に支払う額が上限

具体的な大きさを、仮想の数字で確かめてみます。月額10万円の単一インスタンス（その他のファミリー）で、ある月の稼働率が99.5%だったとします。30日の月なら、1分以上連続した停止が合計216分、つまり3時間36分あったことになります。表に当てはめると10%のクレジットなので、ログを添えて期限内に申告すれば、1万円分が翌月以降の請求に充当されます。

3時間半の停止のあいだに失われた売上や問い合わせの機会は、このクレジットとは別の話です。そしてこの文書では、クレジットが目標未達に対する唯一の救済とされています。

SLAの「%」と、社内のSLOの「%」は数え方が違う

Googleが公開しているSRE Workbook（サイト信頼性エンジニアリングの実践をまとめた資料）の「Implementing SLOs」の章には、似た数字が出てきます。エラーバジェット（目標を下回らない範囲で許容できる失敗の量）を「100% − SLO」と定義し、次のような例を示しています。

• 成功率99.9%のSLOで、4週間に300万リクエストを受けるサービスなら、バジェットは3,000件のエラー（0.1%）
• 1回の障害で1,500件のエラーが出れば、バジェットの50%を消費する

同じ「99.9%」でも、ここで数えているのはリクエストのうち成功したものの割合です。Compute EngineのSLAが数えているのは、1分以上連続した停止を除いた時間の割合です。

分母が違えば、同じ出来事でも数字が変わります。定義から考えると、たとえば30秒の障害でリクエストの大半が失敗したとき、リクエスト単位の成功率には反映されますが、Compute EngineのSLAの稼働率には反映されません（1分未満の停止は数えないため）。自社で「ユーザーから見た可用性」を追うなら、それはベンダーのSLAの数字とは別に、自分で定義して測る必要があります。

なぜ「SLAがあるから大丈夫」と感じてしまうのか

この誤解が生まれやすい理由を、3つ考えます。

1つ目に、Agreement（取り決め）という言葉が、約束に聞こえる。取り決めがあると聞くと、相手がその水準を守る義務を負っているように感じます。しかし中身を読むと、取り決められているのは水準を守ることそのものより、守れなかったときの精算方法でした。

2つ目に、99.9%という数字が、分母を隠す。パーセントは「何のうちの何か」を省略した表記です。時間のうちか、リクエストのうちか。何を停止と数え、どの細かさで数えたのか。それが見えないまま、数字の大きさだけが印象に残ります。

3つ目に、救済の中身を読む場面が、選定のときには来ない。SLAを詳しく読むのは、たいてい障害が起きてクレジットを請求しようとするときです。選定の時点では「99.9%」という見出しの数字だけが比較され、停止の定義や申告期限は読まれないまま契約が進みます。

確かなことと、この記事では確かめていないこと

確かなこと（Compute EngineのSLAとSRE Workbookの記載による）:

• Compute EngineのSLAは、稼働率の水準を自らSLO（目標）と呼んでいる
• 目標未達の唯一かつ排他的な救済はクレジットで、1か月の総額はその月の該当サービスの支払額が上限
• 1分未満の部分的・断続的な停止は停止期間に数えない
• クレジットを受けるには、60日以内にログを添えて通知する必要がある
• SRE Workbookのエラーバジェットの例は、リクエストの成功率で数えている

この記事では確かめていないこと:

• 他のクラウドやSaaSのSLAが、どう定義されているか。停止の定義も、粒度も、救済も、申告期限も、サービスごとに確認が必要です
• Compute EngineのSLAが今後改定されるかどうか。この記事は2025年3月4日更新の版を読んでいます
• クレジット以外の救済が、契約全体の他の条項で定められているかどうか。この記事はSLAの文書だけを読んでいます

SLAを読むときに立ち返る3つの問い

どのサービスのSLAを読むときも、次の3つの問いに、文書の該当箇所を引用して答えられるかを確かめてください。

1. 何を「停止」と数えるか。自社のユーザーが「止まった」と感じる状態は、その定義に含まれているか。適用除外に、自社で起こりうる原因が入っていないか
2. どの粒度で数えるか。何分以上の停止から数えるのか。時間の割合か、リクエストの割合か
3. 未達のとき、何が返ってくるか。クレジットの率と上限はいくらか。申告の期限と、提出が必要なものは何か

この3つに答えると、「99.9%」は「止まらない約束」ではなく、「この条件で数えて、この条件を満たしたら、この額を返す」という精算ルールとして読めるようになります。止まってほしくない時間を守るのは、SLAの数字ではなく、システムの構成と自社の運用です。Compute EngineのSLAが、単一インスタンスと複数ゾーンの構成に別々の目標値を置いていることも、構成の選び方が判断の対象であることを示しています。

自分でも試せる、最小の検証

いま使っている、または検討しているクラウドやSaaSを1つ選び、次の手順を試してください。

1. そのサービスのSLAの文書を開き、上の3つの問いに対応する箇所を探して、1行ずつ引用する
2. 「平日の日中に3時間止まった」という仮定を置き、SLAの定義でその月の稼働率とクレジットの額を計算する
3. 同じ3時間の停止で失われる売上・問い合わせ・社内の作業時間を、ざっくり見積もる

2と3の差が、SLAではカバーされない部分です。その差を許容できないなら、判断の対象はSLAの数字ではなく、構成や代替手段の側にあります。

乗り換えにかかる費用をあらかじめ見積もる考え方はスイッチングコストとベンダーロックインとは？契約前に見積もる「出るとき」の判断基準で、クラウドそのものの基本はクラウドコンピューティング入門で扱っています。SLAの数字とユーザー体感を分けて監視する視点は、AIシステムのパフォーマンス監視でも触れています。

この記事で扱ったような判断を、自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。