2026年5月25日

稼働率99.9%と99.99%の違いとは？ダウンタイム換算と計算方法

稼働率 SLA 可用性ダウンタイム

稼働率とは

稼働率（アップタイム / availability）とは、ある期間のうちサービスが正常に稼働していた時間の割合です。SLA（サービスレベル合意）でよく使われる指標で、計算式はシンプルです。

稼働率(%) = (稼働時間 ÷ 全体時間) × 100
        = (1 − ダウンタイム ÷ 全体時間) × 100

「99.9%」のような数字だけを見ると差が小さく感じますが、許容されるダウンタイムに換算すると印象は大きく変わります。この記事では稼働率を実時間に直し、99.9%と99.99%の違いが現場で何を意味するのかを整理します。

nines（ナイン）の数え方

可用性の世界では、稼働率を「9がいくつ並ぶか」で表現する習慣があります。

稼働率	呼び方	9の数
99%	two nines（ツーナイン）	2
99.9%	three nines（スリーナイン）	3
99.99%	four nines（フォーナイン）	4
99.999%	five nines（ファイブナイン）	5

9が1つ増えるごとに、許容ダウンタイムはおよそ10分の1になります。つまり99.9%から99.99%へ上げるとは、停止して良い時間を1桁減らすということです。

稼働率別のダウンタイム換算表

稼働率を年間・月間の許容ダウンタイムに換算すると次のようになります（1年＝365日、1か月＝約730時間で計算）。

稼働率	年間ダウンタイム	月間ダウンタイム
99%（two nines）	約3日15時間	約7時間18分
99.5%	約1日20時間	約3時間39分
99.9%（three nines）	約8時間46分	約43分
99.95%	約4時間23分	約22分
99.99%（four nines）	約52分	約4分
99.999%（five nines）	約5分	約26秒

こうして並べると、99.9%は年間で約8時間46分も停止して良いのに対し、99.99%では年間わずか52分しか許されないことが分かります。同じ「ほぼ100%」でも、運用に求められる厳しさは桁違いです。

稼働率を自分で計算する

換算値を手元で素早く出したいときは、次のワンライナーが便利です。稼働率を変えるだけで任意の許容ダウンタイムを求められます。

# 稼働率から年間ダウンタイムを計算する
# 例: 99.9% → 約 8.76 時間/年（= 525.6 分）
uptime=99.9
python3 -c "d=(1-${uptime}/100)*365*24; print(f'{d:.2f} 時間/年 ({d*60:.1f} 分/年)')"

逆に「許容ダウンタイムから必要な稼働率」を求めることもできます。SLAの目標値を決めるときに使えます。

# 月間で許される停止が30分のとき、必要な稼働率を求める
# 1か月 = 730時間 = 43800分
downtime_min=30
python3 -c "print(f'{(1 - ${downtime_min}/43800)*100:.4f} %')"

99.9%と99.99%の差が現場で意味するもの

数字上はわずか0.09%の差ですが、運用体制の要求は大きく変わります。

99.9%（年間8時間46分まで）: 計画メンテナンスや短時間の障害を吸収できる現実的なライン。共用サーバーや一般的なWebサイトでも狙える
99.99%（年間52分まで）: 単一障害点の排除、冗長構成、自動フェイルオーバー、24時間の監視・即応体制がほぼ必須。1回の長めの障害で年間予算を使い切る

つまり9を1つ増やすには、コストと運用負荷が大きく跳ね上がります。重要なのは「とにかく高い稼働率」を掲げることではなく、サービスの性質に見合った目標を選ぶことです。ダウンタイムが実際にいくらの損失になるかはサイトダウンのコストで試算しています。

業種別の影響試算

同じダウンタイムでも、ビジネスへの影響は業種で変わります。

業種	想定する目標	理由
個人ブログ・コーポレートサイト	99.5〜99.9%	短時間の停止は許容範囲。過剰投資は不要
ECサイト	99.9〜99.95%	停止が直接売上減に直結。セール時は特に重要
SaaS・業務システム	99.95〜99.99%	顧客の業務が止まるため、契約上のSLAが必要
決済・金融インフラ	99.99%以上	法令・信頼性要件が極めて厳格

制作会社がクライアントとSLAを結ぶ際は、まず99.9%前後を基準に置き、サイトの重要度に応じて調整するのが現実的です。SLAの設計手順は稼働率レポートの作り方で詳しく解説しています。

MiterlでSLAを監視する

目標稼働率を決めたら、実際に達成できているかを継続的に計測する必要があります。Miterlはサイトを1分間隔で監視し、稼働率を自動で集計します。

# 直近30日の稼働率をAPIで取得する（uptime_30d）
curl -s "https://miterl.com/api/v1/monitors/1" \
  -H "Authorization: Bearer YOUR_API_KEY" | jq '{name, status, uptime_30d}'

月初〜月末などカスタム期間で計算したい場合は、解決済みの障害履歴を取得してダウンタイム合計（秒）を自前で集計します。

# 解決済み障害のダウンタイム合計（秒）を集計
curl -s "https://miterl.com/api/v1/incidents?monitor_id=1&status=resolved&per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq '[.data[].duration_seconds] | add'

事前に通知した計画メンテナンスの時間を稼働率計算から除外すれば、純粋な障害だけを評価できます。月次の稼働率レポートはダッシュボードで自動生成され、共有URLやPDFでクライアントに渡せます。SLAの達成状況を数値で証明できます。

まとめ

稼働率は「9の数」で語られ、9が1つ増えるごとに許容ダウンタイムが約10分の1になります。

99.9%は年間約8時間46分、99.99%は年間約52分の停止しか許されない
9を1つ増やすには冗長化・即応体制などコストが大きく跳ね上がる
目標は「最大化」ではなく、サービスの性質に見合った値を選ぶ
達成状況は監視ツールで継続計測し、レポートで証明する

具体的なSLAレポートの作り方は稼働率レポートの作り方を、計測の設定方法はドキュメントをご覧ください。実際の稼働率集計は無料プランでそのまま試せます。