この記事に広告・アフィリエイトリンクはありません。Google SRE、AWSの公開SLA、Uptime Instituteの公式資料を2026年7月29日に再確認し、停止時間の換算値を再計算しています。個別サービスの契約条件は公式最新版を優先してください。
結論から言うと、稼働率は「99.9%」という数字だけでは比較できません。何を利用可能と数えるか、どの期間・場所から測るか、計画停止や利用者起因の障害を除外するかで、同じ数字の意味が変わります。
99.9%は30日で43分12秒。ただし、測定定義とセットで読む
稼働率はサービスを利用できた割合です。実測指標のSLI、目標のSLO、契約上のSLAを分け、期間・対象・成功条件・除外条件をそろえて評価してください。
| 稼働率の意味 | 定義した期間または有効リクエスト全体に対して、利用者がサービスを正常に使えた割合 |
|---|---|
| 99.9%・30日 | 43分12秒の利用不能時間相当 |
| 99.9%・365日 | 8時間45分36秒の利用不能時間相当 |
| 比較時の条件 | 測定期間、対象範囲、成功条件、除外条件、部分障害の集計、観測地点をそろえる |
| SLI・SLO・SLA | SLIは実測指標、SLOは目標、SLAは不達時の扱いを含む契約上の合意 |
| 最終確認 | 2026年7月29日。契約条件は各サービスの公式最新版を優先 |
サーバー稼働率とは、利用者がサービスを使えた割合
サーバー分野の稼働率（availability / uptime）は、定義した期間または有効なリクエスト全体に対して、サービスが利用可能だった割合です。
日本語の「稼働率」は、製造設備やCPUがどれだけ使われているかという利用率・使用率の意味でも使われます。この記事では、レンタルサーバー、クラウド、Webサイト、Webアプリの可用性を示す稼働率に限定します。
重要なのは、サーバーの電源が入っているかではなく、利用者が必要な機能を正常に使えるかです。サーバーへpingが通っていても、DNS、TLS証明書、データベース、アプリケーション、外部APIのどこかが失敗し、ログインや購入ができなければ、利用者視点では利用可能とは言えません。
時間基準の稼働率
1か月などの期間のうち、サービスを利用できた時間の割合です。分かりやすい一方、利用者が少ない深夜と多い昼間を同じ重みで数えます。
リクエスト基準の稼働率
有効なリクエストのうち、成功したリクエストの割合です。部分障害やアクセス量の変動を反映しやすい測り方です。
利用者視点の可用性
ページ表示だけでなく、ログイン、検索、保存、決済など重要な利用経路が完了できるかを確認します。
システム全体の可用性
サーバー、DNS、CDN、DB、認証、外部APIなど、必要な構成要素を通した結果で評価します。
「uptime」と「availability」は完全な同義語とは限らない
ホスティングの説明では近い意味で使われますが、uptimeが機器やプロセスの稼働時間を指す場合があります。サービス品質を判断するときは、利用者が操作を完了できるかを重視するavailabilityの定義を確認してください。
サーバー稼働率の計算式は2種類
Google SREは、時間を基準にする方法と、成功したリクエストを基準にする方法を示しています。どちらも、分子と分母に何を含めるかを先に決めることが重要です。
30日間は43,200分です。43.2分利用不能なら、43,156.8 ÷ 43,200 × 100 ＝ 99.9%です。
100万件の有効リクエストのうち99万9,000件が成功なら、999,000 ÷ 1,000,000 × 100 ＝ 99.9%です。
30日間で99.9%を計算する手順
測定期間を分へ変換する
30日 × 24時間 × 60分 ＝ 43,200分です。
定義に合う利用不能時間を集計する
監視記録から停止を合計します。ここでは43.2分とします。
利用可能時間を求める
43,200分 − 43.2分 ＝ 43,156.8分です。
割合へ換算する
43,156.8 ÷ 43,200 × 100 ＝ 99.9%です。
逆算式：許容される利用不能時間
測定期間 ×（1 − 目標稼働率）で求めます。30日で99.9%なら43,200分 × 0.001 ＝ 43.2分です。これは目標値から逆算した上限相当であり、実際の停止予定や実績ではありません。
99%〜99.999%の停止時間一覧
月は30日、年は365日として、期間 ×（1 − 稼働率）で計算しています。実際の月次SLAが暦月基準なら、28日・29日・31日で許容時間が変わります。
表は横へスクロールできます。
| 稼働率 | 30日（43,200分） | 365日（525,600分） | 利用不能割合 |
|---|---|---|---|
| 99% | 7時間12分 | 3日15時間36分 | 1% |
| 99.5% | 3時間36分 | 1日19時間48分 | 0.5% |
| 99.9% | 43分12秒 | 8時間45分36秒 | 0.1% |
| 99.95% | 21分36秒 | 4時間22分48秒 | 0.05% |
| 99.99% | 4分19.2秒 | 52分33.6秒 | 0.01% |
| 99.999% | 25.92秒 | 5分15.36秒 | 0.001% |
停止時間かんたん計算
稼働率と期間を入力すると、利用不能時間の上限相当を計算します。
エラーバジェット相当：0.1%
「9」が一つ増えると、許容停止時間は約10分の1
99.9%と99.99%は見た目では0.09ポイント差ですが、30日換算の利用不能時間は43分12秒から4分19.2秒へ減ります。高い目標ほど、監視精度、冗長化、変更管理、復旧の自動化に必要なコストも大きくなります。
稼働率を測る前に固定する6つの条件
稼働率は、測定仕様から作られる数値です。事業者比較でも社内運用でも、条件が違う数字をそのまま横並びにしないでください。
測定期間
暦月、連続30日、四半期、365日などを明示します。月次SLAを年間値へ単純平均すると、月の日数やリクエスト量の差が隠れます。
対象範囲
サーバー1台、リージョン、契約アカウント、Webサイト全体、特定APIなど、何を測るかを決めます。DNSや管理画面が対象外かも確認します。
成功条件
HTTPステータス、応答内容、処理完了、応答時間を定義します。200応答でも内容が壊れている、または極端に遅い場合を成功と数えるか決めます。
除外条件
計画メンテナンス、利用者設定、上流事業者、不可抗力、ベータ機能などの扱いを確認します。除外が広いほど体感停止との差が大きくなります。
部分障害の集計
利用者の10%だけが失敗した時間を全停止とするか、失敗リクエスト率で重み付けするかを決めます。重要操作は別SLIに分ける方法もあります。
観測地点と証拠
事業者内部監視、複数地域の外形監視、利用者ログのどれを正とするか決め、時刻、場所、エラー、継続時間を保存します。
2026年の実務では、重要操作ごとのイベント基準が扱いやすい
一部リージョンや一部APIだけが失敗するサービスでは、停止時間だけより「成功した有効イベント ÷ 有効イベント総数」のほうが影響を連続的に表せます。ただし、閲覧リクエストが大量にあると、件数の少ない決済障害が埋もれるため、利用経路ごとにSLIを分けます。
サーバー1台のSLAと、サイト全体の稼働率は同じではない
利用者がサイトを使うまでにDNS、CDN、ロードバランサー、アプリ、データベース、認証、決済などが必要なら、どれか一つのSLAだけで全体の可用性は決まりません。
すべてが必要で、障害が独立していると単純化した場合：0.999 × 0.999 × 0.999
約99.7003%この単純例では、30日換算の利用不能時間は約2時間9分です。実際には共通ネットワークや設定変更による相関障害、キャッシュや代替経路による影響軽減があるため、単純な掛け算だけで予測はできません。それでも「各部品が99.9%だからサイトも99.9%」とは限らないことが分かります。
遅すぎるサービスを「稼働中」と数えない
タイムアウト直前の応答や、画面表示後に操作できない状態は、HTTP 200でも実用上の障害です。重要操作ごとに「成功」と「十分に速い」を定義し、たとえば95%のリクエストが一定時間以内に完了する、といった遅延SLOも併用します。
監視対象が「サーバー」だけだと、利用者の障害を見逃す
最低限、トップページ、ログイン、検索、保存、購入などの重要経路を外部から定期実行してください。内部メトリクスは原因調査に、外形監視は利用者影響の把握に向いており、両方を組み合わせます。
稼働率とSLI・SLO・SLA・関連指標の違い
似た用語は、測定値、目標、契約、設計特性という役割が異なります。稼働率はSLIの一つになり得ますが、目標や契約そのものではありません。
表は横へスクロールできます。
| 用語 | 役割 | 稼働率との関係 | 例 |
|---|---|---|---|
| SLI 測る | サービス水準を表す定量指標 | 稼働率、成功率、遅延、正しさなどがSLIになります。 | 購入成功率99.93% |
| SLO 目標 | SLIに設定する目標値・範囲 | 実測値ではなく、達成したい水準です。 | 30日で99.9%以上 |
| SLA 契約 | 水準と不達時の扱いを定める合意 | 算定式、除外、救済、申請条件まで含めて読みます。 | 不達時に利用料金の一部をクレジット |
| エラーバジェット | SLOから許容される失敗量 | 基本形は100% − SLO。99.9%なら0.1%です。 | 30日で43分12秒相当 |
| 信頼性 | 期待する機能を故障なく果たす性質 | 故障回数と復旧速度が違っても、合計停止時間が同じなら同じ稼働率になり得ます。 | 故障頻度、復旧性 |
| 冗長性 設計 | 構成要素・経路を重複させる設計 | 可用性を高める手段であり、切替失敗や共通原因障害は残ります。 | 複数AZ、二重化 |
| 利用率・使用率 | CPU、回線、設備の使用割合 | 高いほど良いとは限らず、逼迫の兆候にもなります。 | CPU使用率75% |
| 耐久性 | 保存データが失われない性質 | 一時的に接続不能でもデータは保持され得ます。 | オブジェクト耐久性 |
| MTBF / MTTR | 故障間隔と復旧・修復時間 | 単純な定常モデルではMTBF ÷（MTBF＋MTTR）で可用性を概算できますが、サービスSLIの代替にはなりません。 | 復旧時間を短縮 |
データセンターTierを固定の稼働率へ変換しない
Uptime Instituteは2009年に「年間の予想停止時間」への参照をTier Standardから削除し、現行のTier Standard: TopologyはTierレベルへ可用性予測を割り当てないと説明しています。Tierは施設インフラの保守性・耐障害性などを扱う枠組みであり、アプリケーションのSLAや実績値とは別です。
SLAの99.9%を比較する5つの手順
SLAは数字の大きさだけで選びません。AWSの公開SLAでも、サービスごとに算定単位、利用不能の定義、サービスクレジット、除外、申請条件が異なります。契約するサービス自身の最新版を確認してください。
- 対象サービスと単位を確認するリージョン、インスタンス、アカウント、エンドポイントなど、保証対象を確認します。Webサイト全体を保証するとは限りません。
- 計算式と測定期間を確認する暦月か連続期間か、時間基準かエラー率基準か、事業者ログか外形監視かを読みます。
- 利用不能の定義と除外を確認する計画保守、利用者設定、外部ネットワーク、不可抗力、ベータ機能などが除外されるか確認します。
- 救済内容と申請条件を確認する自動付与か申請制か、申請期限、必要な証拠、対象料金、クレジット上限を確認します。
- 実測履歴と自社の復旧策を別に確認するSLAは過去実績ではありません。公式ステータス、外形監視、障害報告、バックアップ、切替試験を確認します。
サービスクレジットは、事業損失の全額補償とは限らない
多くの公開SLAでは、救済は対象期間の利用料金に対するクレジットです。売上損失、従業員の待機、信用低下が自動で補償されるとは限りません。許容できない影響は、冗長化、バックアップ、代替手段、復旧目標、個別契約を含めて別途設計します。
SLA確認用の短いチェックリスト
- 「99.9%」の分母は、時間・リクエスト・5分区間のどれか
- 利用不能は、接続不可だけか、エラー応答や遅延も含むか
- 複数AZ・複数リージョンなど、利用者側の構成要件があるか
- 計画停止、第三者サービス、利用者設定が除外されるか
- 申請期限と、提出が必要なログ・時刻・リソースIDは何か
サーバー稼働率を高める8つの実務
高可用性は、サーバーを二重化するだけでは実現しません。設計、監視、変更、復旧、組織運用を一つの仕組みとして整えます。
単一障害点を減らす
ロードバランサー、複数ゾーン、冗長DB、冗長DNSなどを検討し、切替が本当に機能するか試験します。
重要操作を外形監視する
複数地点からページ、ログイン、検索、保存、購入を監視し、内容と応答時間まで確認します。
SLOとエラーバジェットを運用する
目標を定め、予算消費が速いときに変更を止める、信頼性改善を優先するなどの判断へつなげます。
安全に変更する
小さなリリース、段階配信、ロールバック、設定レビューにより、変更起因の障害範囲と復旧時間を抑えます。
容量に余裕を持たせる
CPU、メモリ、接続数、キュー、DB負荷を監視し、急増時の自動拡張と上限を設計します。
バックアップと復元を試す
バックアップが存在するだけでなく、復元時間、復元後の整合性、権限、手順を定期的に検証します。
依存先の障害を隔離する
タイムアウト、再試行上限、サーキットブレーカー、キュー、縮退運転で連鎖障害を防ぎます。
障害対応を練習する
責任者、連絡経路、利用者告知、切替手順を決め、事後検証で再発防止策と検知改善を追跡します。
100%を目標にすると、費用と変更速度が急激に悪化する
Google SREは、100%の達成を常に求めることは非現実的で、過度に保守的な設計や開発速度低下につながり得ると説明しています。業務影響と投資額を見ながら、適切なSLOとエラーバジェットを決めます。
サーバー稼働率のよくある質問
稼働率99.9%なら、1年間の停止時間は約52分ですか？
いいえ。365日換算の99.9%は8時間45分36秒です。約52分33.6秒になるのは99.99%です。いずれも期間から逆算した算術上の利用不能時間で、SLAの除外条件は反映していません。
99.9%と99.99%はどのくらい違いますか？
30日換算では99.9%が43分12秒、99.99%が4分19.2秒です。許容される利用不能時間は約10分の1になります。ただし、測定範囲や除外条件が違うSLA同士は数字だけで比較できません。
計画メンテナンスは稼働率の計算から除外しますか？
一律には除外しません。社内SLIや契約SLAが定める算定式に従います。利用者が経験した利用不能時間と、契約判定用の利用不能時間を分けて記録すると、体感品質と補償判定の両方を追えます。
SLA 99.9%は、実際の稼働率を保証しますか？
SLAはサービス水準と不達時の扱いを定める合意で、過去の実測値そのものではありません。算定範囲や除外条件のもとで基準を下回った場合に、サービスクレジットなどが適用される契約があります。
稼働率と可用性は同じ意味ですか？
ホスティング分野では近い意味で使われます。技術的には、uptimeが機器やプロセスの稼働時間を指すことがある一方、availabilityは利用者が必要な機能を利用できる状態を重視します。比較時は定義を確認してください。
監視でサーバーへpingが通れば稼働中ですか？
重要サービスの確認としては不十分です。pingが成功しても、Webが500エラー、ログイン不可、保存失敗という状態は起こります。利用者が行う重要操作を外形監視し、成功条件と応答時間を定義してください。
データセンターがTier IIIなら稼働率も決まりますか？
固定の割合には変換できません。Uptime Instituteの現行Tier Standard: TopologyはTierレベルへ可用性予測を割り当てていません。施設設計、運用、ネットワーク、アプリケーション、SLA、実績を分けて評価します。
確認した一次資料・公式資料
定義、計算、SLO、エラーバジェット、公開SLA、Tierの扱いは次の資料で確認しました。個別サービスの契約条件は変更されるため、契約前と障害申請時に最新版を確認してください。
- Google SRE Book「Availability Table」— 稼働率と許容停止時間、部分障害では集約型指標が有用であること
- Google SRE Book「Embracing Risk」— 時間基準・集約基準の可用性とエラーバジェット
- Google SRE Book「Service Level Objectives」— SLI・SLO・SLAと100%目標の注意点
- Google SRE Workbook「Implementing SLOs」— イベント基準のSLIとエラーバジェット運用
- Amazon S3 Service Level Agreement — 月間稼働率、サービスクレジット、条件の例
- Amazon Compute Service Level Agreement — リージョンレベルとインスタンスレベルの算定単位の例
- Uptime Institute「Explaining the Tier Classification System」— Tierと固定稼働率を結び付けない理由
まとめ：99.9%は、何をどう測ったかまで確認する
サーバー稼働率は、サービスを利用できた割合です。99.9%は30日で43分12秒、365日で8時間45分36秒の利用不能時間に相当します。ただし、実務では期間、対象範囲、成功条件、除外、部分障害、観測地点がそろって初めて比較できます。
実測値であるSLI、目標であるSLO、契約上のSLAを分け、サイト全体の依存関係、遅延、実測履歴、復旧手順まで確認してください。数字だけでなく、利用者が重要操作を完了できる状態を継続的に測ることが、信頼できる運用につながります。