クラウドの稼働率99.9%とは？1年でどれだけ止まるのかを数字で解説

クラウドは「ほぼ止まらない」って本当？
「99.9%稼働」の真実：実は年間8時間以上止まっていい
数字で見る「稼働率」「MTBF」「MTTR」
1. 稼働率の計算式
2. MTBFとMTTRとは
現実のクラウドはどれくらいの稼働率なのか
1. 障害はどこでも起きる
稼働率を上げるための設計思想
「99.999%を目指す」と言われたらどうする？
まとめ：数字の裏側を理解して、現実的な設計を

クラウドは「ほぼ止まらない」って本当？

「クラウドの稼働率は99.9%です」と聞くと、ほとんど止まらないように感じる。
しかし、実際に数字にしてみると「99.9%」は意外と止まっている。

AWSやAzureのSLA（サービス品質保証）にも書かれているが、
「99.9%稼働」というのは「1年のうち、一定時間は止まっても許容される」という意味だ。

つまり、「99.9%稼働」＝「100%稼働ではない」。

この記事では、
クラウドの稼働率の意味、具体的な停止時間、そしてそれを支える指標（MTBF・MTTRなど）について、
数字を交えて分かりやすく解説していく。
きっとこの記事を読み終える頃には、あなたの頭の中に「99.9%＝魔法ではない」という現実が残るだろう。

—

「99.9%稼働」の真実：実は年間8時間以上止まっていい

まず結論から言おう。

1年＝365日＝8,760時間。
「稼働率99.9%」とは、そのうち約8.76時間の停止が許されるという意味だ。

以下の表を見てほしい。

稼働率	年間停止時間	月間停止時間
99%	約87.6時間（約3.6日）	約43分
99.9%	約8.76時間	約4.4分
99.99%	約52.6分	約26秒
99.999%	約5.26分	約2.6秒

つまり、99.9%は「ほぼ止まらない」ではなく、「年に半日くらいは止まっても文句は言えない」ということだ。
ファイブナイン（99.999%）まで行ってやっと「年に5分しか止まらない」世界に到達する。

—

数字で見る「稼働率」「MTBF」「MTTR」

稼働率の計算式

クラウドの可用性を表す「稼働率」は、以下の式で表される。

稼働率 = 稼働時間 ÷ （稼働時間 + 停止時間） × 100

例として、もし1年のうち丸2日止まった場合：

稼働率 = (8760 - 48) ÷ 8760 × 100
        = 8712 ÷ 8760 × 100
        ≒ 99.45%

つまり、「たった2日止まっただけ」で稼働率は99.45%まで下がる。
クラウドサービスがいかに高い稼働率を維持しているかが分かるだろう。

—

MTBFとMTTRとは

「可用性」は稼働率だけでは語れない。
そこで登場するのが、次の2つの指標だ。

MTBF（Mean Time Between Failures）：平均故障間隔。どのくらいの間隔で故障が起きるか。
MTTR（Mean Time To Repair）：平均修復時間。故障してから復旧するまでの平均時間。

これらを使うと、稼働率は次のようにも表現できる。

稼働率 = MTBF ÷ (MTBF + MTTR)

たとえば、

* 故障が平均1000時間ごとに発生（MTBF=1000）
* 修復に1時間かかる（MTTR=1）

なら、稼働率は

1000 ÷ (1000 + 1) = 99.9%

…そう、これがまさに「スリーナイン」の世界だ。
ちょっとした設定ミスやネットワーク障害があっても、1時間以内に直せば99.9%を維持できる計算になる。

—

現実のクラウドはどれくらいの稼働率なのか

主要クラウドベンダーのSLA（サービス品質保証）を見ると、実際の稼働率がわかる。

クラウドサービス	SLA（稼働率）
AWS EC2	99.99%
Microsoft Azure VM	99.95%
Google Cloud Compute Engine	99.99%

いずれも「フォーナイン」クラス。
しかし、注意したいのはSLAは「保証値」であって、実績値ではないという点だ。
実際に障害が起きた場合、ユーザーは返金などの補償を受けられるが、止まってしまった事実は変わらない。

—

障害はどこでも起きる

2023年には、AWS東京リージョンで大規模なネットワーク障害が発生した。
また、Azureでも一部の認証系サービスが数時間停止したことがある。
どちらも「フォーナイン」をうたうクラウドだ。

どんなに設計が優れていても、
人間が設定し、人間が運用している以上、障害ゼロはありえない。
クラウドは「止まらない魔法の箱」ではなく、 “止まっても早く直るように設計されたシステム”なのだ。

—

稼働率を上げるための設計思想

可用性を高めるためには、単に「信頼できるクラウドを選ぶ」だけでは不十分だ。
アプリケーション側にも工夫が必要になる。

1. 冗長化（Redundancy）

サーバーを複数台構成にする、AZ（アベイラビリティゾーン）をまたぐ配置をすることで、
1台（あるいは1拠点）が落ちてもサービスが継続できる。

2. フェイルオーバー

障害発生時に別系統に自動的に切り替える仕組み。
DNS切り替えやロードバランサで実装する。

3. モニタリングと自動修復

異常を早期検知し、自動で再起動や切り替えを行う。
この「MTTRの短縮」が結果的に可用性を押し上げる。

4. キャパシティプランニング

負荷ピーク時にサーバーが落ちないよう、リソースの余裕を見積もる。
スケーリング戦略の設計もここに含まれる。

—

「99.999%を目指す」と言われたらどうする？

上司が「ファイブナインを目指したい」と言い出したら、
まず深呼吸してから電卓を取り出そう。

99.999%は「年に5分しか止まれない」水準だ。
冗長構成、二重回線、データレプリケーション、24時間体制の監視――
つまり、金がかかる。

本当にそこまでの可用性が必要なのか？
「5分止まっても困らない」なら、99.9%でも十分だ。
「5秒も止まれない」金融取引系なら、専用線＋オンプレ構成の方が現実的な場合もある。

可用性は「どれだけ止まらないか」ではなく、「止まってもビジネス的に許容できるか」で決めるのが正解だ。

—

まとめ：数字の裏側を理解して、現実的な設計を

最後にこの記事のポイントを整理しよう。

「99.9%稼働」は年間約8.76時間の停止を意味する
2日止まると稼働率は約99.45%
可用性は「MTBF」「MTTR」のバランスで決まる
SLAは「保証値」であり「実績」ではない
可用性向上には冗長化・フェイルオーバー・監視が不可欠
ファイブナインはコストとトレードオフ。目的に応じた水準設定が重要

「クラウドだから止まらない」は幻想だ。
しかし、適切な設計と監視で「止まってもすぐ復旧できる」状態にすることはできる。

もしあなたがインフラエンジニアとして
「もっと可用性を上げろ」と言われたら、ぜひこう答えてほしい。

「それ、何分まで止まっていいサービスですか？」

数字の裏側を理解することが、
信頼されるエンジニアへの第一歩である。