システムの可用性（稼働率）を「99.99%にします」と聞くと、ほとんど止まらない安心感があります。ですが、この“0.01%の停止”が実際にはどのくらいの時間なのか、年・月・週・日単位で即答できる人は多くありません。 本記事では、稼働率99.99%のときに許容されるダウンタイム（停止時間）を具体的な数値で示し、他の一般的なSLA値（99%、99.9%、99.95%、99.999%）とも比較しながら、SLA／SLOをどう読むべきか、そしてその水準を現実的に達成するための設計・運用ポイントまでを解説します。
**可用性（稼働率）**は、対象期間（1年、1か月、1日など）のうち、システムが正常に利用できた時間の割合です。式で書くと次のとおりです。
可用性（%）＝（総稼働時間 − 停止時間）÷ 総稼働時間 × 100
したがって、**99.99%（フォーナイン）の可用性は、対象期間中の0.01%**の時間は停止しても良い（SLAの範囲内）ことを意味します。ここでいう「停止」は多くの場合、ユーザーがサービスを利用できない状態を指しますが、SLA文書では「計画停止（メンテナンス）」や「クラウド／通信事業者側の障害」「天災」などが除外されることがあります。何が“停止”としてカウントされるのかは、必ず契約・約款で確認しましょう。
可用性 99.99% は、停止許容量 0.01%（= 0.0001）に相当します。対象期間ごとの総時間に 0.0001 を掛ければ、許容ダウン時間がすぐに出せます。
たった1時間あたり 0.36秒しか止められない。この厳しさが 99.99% の数字の裏にある現実です。
| 可用性 | 年間停止時間（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分以内”に収めるというより、「本当に止めてはいけないタイミングでは0秒に近づける」ための設計・運用上の工夫が求められます。
フォーナインは、単一構成や手作業中心の運用ではまず実現できません。代表的な設計・運用戦略を整理します。
SLA文書では、停止時間のカウント対象が厳密に定義されているのが一般的です。例えば次のようなケースはSLAの対象外（ダウンタイムにカウントしない）とされることがあります。
「我々が日々感じる“止まった時間”と、SLAで定義される“停止時間”が必ずしも一致しない」点は、現場で混乱の元になりやすいので、運用部門・契約担当者間で共通理解を持っておくことが重要です。
SLA（対お客様の約束）より内側に、SLO（Service Level Objective：内部目標）を置くのがSRE（Site Reliability Engineering）の基本です。
たとえば外向け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分