【完全ガイド】稼働率計算と許容停止時間一覧｜合成可用性とエラー予算

「稼働率99.99%（フォーナイン）」を目指すと聞いたとき、それが具体的に「1か月あたり何分何秒の停止しか許されないのか」を即座に試算できているでしょうか。

単なる用語としての可用性理解から一歩踏み込み、「システム全体の合成可用性をどう計算し、SRE運用のエラー予算へどう落とし込むか」は、インフラアーキテクトやリードエンジニアにとって不可欠なスキルです。

本記事では、主要な稼働率における「許容停止時間の早見表」から、直列・並列接続の数理計算モデル、現場のシミュレーションで陥りがちな落とし穴、そしてエラー予算の算出手法までを網羅して解説します。

【早見表】稼働率99.9%・99.99%の許容停止時間一覧

まずは、目標とする稼働率（可用性）ごとに、どれだけのダウンタイム（停止時間）が許されるのかを整理します。

※ 1年＝365日（8,760時間）、1か月＝30日（720時間）として試算。

稼働率（可用性）	年間許容停止時間	月間許容停止時間（30日換算）	日間許容停止時間	想定されるインフラ構成レベル
99%（ツーナイン）	3日 15時間36分	7時間12分	14分24秒	冗長化なし単一構成 / 平日日中運用システム
99.9%（スリーナイン）	8時間45分57秒	43分12秒	1分26秒	単一AZ＋自動バックアップ / 一般的Webシステム
99.99%（フォーナイン）	52分35秒	4分19秒	8.64秒	マルチAZ冗長化＋自動昇格（Failover）
99.999%（ファイブナイン）	5分15秒	25.9秒	0.86秒	マルチリージョン / 社会インフラ・基幹基盤

99.9%から99.99%に引き上げるだけで、月間の許容停止時間は「約43分」から「約4分」へと一気に10分の1以下へ凝縮されます。

この数分間で「検知・切り分け・復旧（あるいは自動Failover）」を完了させられるかが、アーキテクチャ設計の境界線となります。

稼働率計算の基本公式（MTBFとMTTRの関係）

稼働率の数学的な基本定義は、MTBF（平均故障間隔）とMTTR（平均修復時間）を用いて以下のように表されます。

• MTBF（Mean Time Between Failures：平均故障間隔）システムが正常に動き始めてから、次に障害が発生するまでの「連続稼働時間の平均」。
• MTTR（Mean Time To Repair：平均修復時間）障害が発生してから検知・切り分け・復旧作業を行い、サービスが再開するまでの「停止時間の平均」。

稼働率を上げる2つのアプローチ

上記の公式から、稼働率を高めるアプローチは以下の2点に集約されます。

1. MTBFを大きくする（壊れにくくする）：コンポーネントの冗長化、高品質なインフラ・ハードウェアの選定。
2. MTTRを小さくする（素早く直す）：監視の自動化、IaCによる再構築、Auto Scalingや自動Failoverの導入。

「計画停止（メンテナンス）」の扱い

システム運用において、計画点検やメンテナンス時間を分母（全運用時間）から除くかどうかは事前に明確化しておく必要があります。

• 分母から除く場合：以下の式で稼働率を計算。

• 分母に含める場合：無停止メンテナンス（ブルー/グリーンデプロイ等）の仕組みが必須。

【直列・並列】システム構成別の合成可用性（稼働率）計算モデル

実際のシステムは単一の機器で動いているわけではありません。複数のコンポーネントが繋ぎ合わさった「全体の合成稼働率」を計算する手法を解説します。

① 直列依存（Serial Dependency）の計算

いずれか1つのコンポーネントが停止すると、システム全体が停止する構成です（単一障害点：SPOFが存在する状態）。

全体の稼働率は、各コンポーネントの稼働率Aの「掛け算」で求めます。

【計算例】

• AWS ALB（99.99% : 0.9999）
• EC2インスタンス群（99.99% : 0.9999）
• 専用線/VPN境界（99.9% : 0.999）
• オンプレミスDB（99.9% : 0.999）

$$全体の稼働率 = 0.9999 \times 0.9999 \times 0.999 \times 0.999 \approx 0.9978 \quad (99.78\%)$$

単体で高可用なクラウドサービスを使っても、直列に繋ぐ要素が増えるほど全体の理論稼働率は下がります。

② 並列冗長（Parallel Redundancy）の計算

複数のコンポーネントが並列に配置され、どれか1つでも稼働していればサービスが継続できる構成です（マルチAZ、ネットワーク回線の冗長化など）。

全体の稼働率は、各要素の「不稼働率（1 – A）の掛け算」を1から引くことで求めます。

【計算例】

稼働率99.9%のネットワーク回線を2系統用意し、アクティブ/スタンバイ（またはアクティブ/アクティブ）で並列化した場合：

$$全体の稼働率 = 1 – (1 – 0.999) \times (1 – 0.999) = 1 – (0.001 \times 0.001) = 0.999999 \quad (99.9999\%)$$

並列化によってボトルネックの不稼働率を劇的に下げることができます。

稼働率シミュレーションで陥りがちな3つの落とし穴

試算上は「99.99%達成」と計算できても、現実の運用で破綻する主な原因は以下の3つです。

落とし穴①：ベンダーの公表SLAをそのまま計算式に入れる

パブリッククラウドのSLA（保証値）は「未達時にクレジット返金が発生するライン」であり、平常時の実効稼働率とは異なります。

試算時には「ベンダーSLAの数値をそのまま積算に使うと過度に厳しい結果が出る」リスクを理解しておく必要があります。

落とし穴②：「完全停止」以外の障害（遅延・スロットリング）の欠落

サーバーが応答していても、「レスポンスに10秒かかる」「APIスロットリングでリクエストの半分が503になる」状態は、ユーザーから見れば「停止」と同義です。

稼働率の計算母数に「レイテンシ悪化」や「部分エラー率」を含める定義（SLIの設定）が必要です。

落とし穴③：MTTRに「リストア・データ整合性検証」を含めていない

オンプレハードウェアの「4時間オンサイト保守」をMTTR＝4時間と計算してしまうケースです。

現場では部品交換後のOS起動・データリストア・バックアップからのリカバリ・業務整合性確認にさらに数時間がかかります。これらを含めた全復旧時間をMTTRとして見積もる必要があります。

SRE運用に活かす「エラー予算（Error Budget）」の計算方法

稼働率（SLO）を定義したら、それを日々の運用ルールである「エラー予算（Error Budget）」へ変換します。

エラー予算の基本式

• 例：月間SLO 99.9%（許容停止時間 約43分12秒）の場合運用チームは、1か月の中で「43分12秒までの障害やメンテナンス停止（＝エラー予算）」を消費することが許容されます。

エラー予算を活用した運用ガバナンス

1. エラー予算が潤沢なとき：新機能のリリースやリスクを伴うアーキテクチャ変更を積極的に推進する。
2. エラー予算を使い果たしたとき：新機能リリースを一時凍結し、インフラの安定化や自動リカバリの強化（MTTR削減）に全リソースを集中させる。

このように、稼働率計算を単なる「提出書類の数字」に終わらせず、「開発速度とシステム安定性のバランスを制御する指標」として機能させることが重要です。

まとめ

• 稼働率計算はトレードオフの可視化：99.9%から99.99%への引き上げには、コスト・複雑性が跳ね上がる。
• 直列と並列の数理モデル：直列接続は掛け算で低下し、並列接続はボトルネックを解消する。
• エラー予算への落とし込み：計算された許容停止時間をSRE運用（リリース判断・安定化投資）に活かす。

算出した理論値をもとに、ビジネス要件に合致した無理のないアーキテクチャと運用体制を作り上げましょう。