システムの可用性（稼働率）を「99.99%にします」と聞くと、ほとんど止まらない安心感があります。ですが、この“0.01%の停止”が実際にはどのくらいの時間なのか、年・月・週・日単位で即答できる人は多くありません。 本記事では、稼働率99.99%のときに許容されるダウンタイム（停止時間）を具体的な数値で示し、他の一般的なSLA値（99%、99.9%、99.95%、99.999%）とも比較しながら、SLA／SLOをどう読むべきか、そしてその水準を現実的に達成するための設計・運用ポイントまでを解説します。
99.99%とは何か？まずは「可用性（Availability）」の定義を押さえる
**可用性（稼働率）**は、対象期間（1年、1か月、1日など）のうち、システムが正常に利用できた時間の割合です。式で書くと次のとおりです。
可用性（%）＝（総稼働時間 − 停止時間）÷ 総稼働時間 × 100
したがって、**99.99%（フォーナイン）の可用性は、対象期間中の0.01%**の時間は停止しても良い（SLAの範囲内）ことを意味します。ここでいう「停止」は多くの場合、ユーザーがサービスを利用できない状態を指しますが、SLA文書では「計画停止（メンテナンス）」や「クラウド／通信事業者側の障害」「天災」などが除外されることがあります。何が“停止”としてカウントされるのかは、必ず契約・約款で確認しましょう。
99.99%のダウン時間は“年間52.56分”──期間別に具体的に計算してみる
可用性 99.99% は、停止許容量 0.01%（= 0.0001）に相当します。対象期間ごとの総時間に 0.0001 を掛ければ、許容ダウン時間がすぐに出せます。
- 年（365日）: 365日 × 24時間 × 60分 × 0.0001 = 52.56分
- 月（30日換算）: 30日 × 24時間 × 60分 × 0.0001 = 4.32分
- 週: 7日 × 24時間 × 60分 × 0.0001 = 1.008分（約1分0.5秒）
- 1日: 24時間 × 60分 × 0.0001 = 0.144分（8.64秒）
- 1時間: 60分 × 60秒 × 0.0001 = 0.36秒
たった1時間あたり 0.36秒しか止められない。この厳しさが 99.99% の数字の裏にある現実です。
主要なSLA水準を横並び比較（99%／99.9%／99.95%／99.99%／99.999%）
| 可用性 | 年間停止時間（365日） | 月間停止時間（30日） | 週間停止時間 | 1日停止時間 | 1時間停止時間 |
|---|---|---|---|---|---|
| 99% | 3.65日（87.6時間） | 7.2時間 | 1.68時間 | 14.4分 | 36秒 |
| 99.9%（スリーナイン） | 8.76時間 | 43.2分 | 10.08分 | 1.44分（86.4秒） | 3.6秒 |
| 99.95% | 4.38時間 | 21.6分 | 5.04分 | 43.2秒 | 1.8秒 |
| 99.99%（フォーナイン） | 52.56分 | 4.32分 | 1.008分（約1分0.5秒） | 8.64秒 | 0.36秒 |
| 99.999%（ファイブナイン） | 5.256分（約5分15秒） | 25.92秒 | 6.048秒 | 0.864秒 | 0.036秒 |
表を見ると、「ナインを一つ増やす」ごとに許容ダウンタイムが桁違いに厳しくなることが分かります。99.9%（スリーナイン）と 99.99%（フォーナイン）の差は、年間で 8.76時間 → 52.56分 と、10倍以上も縮まります。
「わずか52分」でも致命的になり得る理由
52分という数字だけを見ると大したことがないように感じるかもしれません。しかし、次のような状況では数分のダウンでも直接的な損失や社会的信用の失墜につながります。
- 決済・トレーディングシステム：秒単位の停止が即損失に直結
- ECの大型セール：年に一度のピーク時に落ちると売上の大半を逃す
- 医療・社会インフラ：システム停止が人命や生活に影響
- SaaSプロバイダ：SLA違反によるペナルティ（サービスクレジット）や解約増加
つまり、“年間52分以内”に収めるというより、「本当に止めてはいけないタイミングでは0秒に近づける」ための設計・運用上の工夫が求められます。
99.99%を“現実的に”達成するための設計・運用のポイント
フォーナインは、単一構成や手作業中心の運用ではまず実現できません。代表的な設計・運用戦略を整理します。
1. 冗長化とフェイルオーバーの自動化
- 多AZ/多リージョン構成（クラウドの場合）
- アクティブ-アクティブ or アクティブ-スタンバイ構成
- 無停止切り替え（ゼロダウンタイム・デプロイ）の採用（Blue/Green、Canary、Rolling Update など）
2. MTTR（平均復旧時間）を徹底的に短縮
- Self-healing（自己修復）の仕組み：オートスケーリング、ヘルスチェックによる自動再起動
- IaC（Infrastructure as Code）で、環境を即時に再構築できる状態に
- Runbook / Playbook / SREハンドブックの整備と訓練
3. バックアップとデータ整合性の確保
- RPO/RTOの明確化と、それを満たすバックアップ/レプリケーション戦略
- 整合性の検証（DRテスト、バックアップリストアの定期演習）
4. 変更管理（Change Management）の強化
- リリース前のカナリアリリース・A/Bテスト
- Feature Flagで即時無効化できる仕組み
- Infrastructure/Config Drift の検知と是正
5. 可観測性（Observability）の確立
- メトリクス／ログ／トレースの統合監視
- SLO とエラーバジェットの運用（後述）
- アラート疲れ（Alert Fatigue）の防止と正しい優先度付け
「計画停止はSLAに含まれない」？ダウンタイムの数え方を必ず確認する
SLA文書では、停止時間のカウント対象が厳密に定義されているのが一般的です。例えば次のようなケースはSLAの対象外（ダウンタイムにカウントしない）とされることがあります。
- 事前告知された計画メンテナンス
- ユーザー側設定ミス・ネットワーク起因の障害
- 不可抗力（天災、戦争、テロ等）
- 第三者サービスの障害（ただしマルチベンダー時は調整が難しい）
「我々が日々感じる“止まった時間”と、SLAで定義される“停止時間”が必ずしも一致しない」点は、現場で混乱の元になりやすいので、運用部門・契約担当者間で共通理解を持っておくことが重要です。
SLOとエラーバジェットで“攻めと守り”のバランスを取る
SLA（対お客様の約束）より内側に、SLO（Service Level Objective：内部目標）を置くのがSRE（Site Reliability Engineering）の基本です。
- SLA：法的拘束・ペナルティが発生し得る外部向け約束
- SLO：内部運用チームが守るべき目標値
- エラーバジェット：SLOから逆算した「失敗して良い余白」
たとえば外向けSLAが 99.99% なら、内部SLOを 99.995% に設定し、エラーバジェットを戦略的に使いながら、信頼性と開発スピードのバランスを取ることが推奨されます。
すぐに使える！停止時間の簡易計算式とチェックリスト
簡易計算式
停止時間 ＝ 対象期間の総秒数 × (1 - 可用性)例：1年（365日）の総秒数 = 365 × 24 × 60 × 60 = 31,536,000秒
99.99%（= 0.9999）の場合：
31,536,000 × (1 - 0.9999) = 3,153.6秒 ≒ 52.56分チェックリスト
まとめ：数字を“運用可能な現実”へ落とし込む
- 99.99%（フォーナイン）＝ 年間 52.56分、月間 4.32分、1日 8.64秒の停止が限度。
- ナインを一つ増やすと、必要な投資と運用コストは桁違いに上がる。事業価値・リスクと見合っているかを常に検討すべき。
- SLAは「外向けの約束」。内部では SLO とエラーバジェットを使い、信頼性と機能開発のバランスを取る。
- 真に止められない局面では「0秒に近づける」設計・運用（冗長化・自動化・迅速な復旧）を前提に、ダウンタイムの“定義”と“計測方法”を明文化しておくことが、99.99%の現実的な達成には不可欠です。