生成AIが語るクラウドSLAの9の数：月間停止時間の真実と誤解

クラウドのSLAに並ぶ「99.9%」「99.99%」といった“9の数”。安心材料に見えますが、実は月間の停止時間や、実際に体感する止まり方を正しくイメージできないまま選定してしまうケースが多くあります。本稿では、9の数が意味するもの・しないものを整理し、誤解を避けるためのポイントと、現実的な対処法を提案します。

“9の数”が示すもの／示さないもの

可用性のパーセンテージは「サービスがどれだけの時間、使える状態だったか」の目安です。一方で次の点は直接は示しません。

どの時間帯に止まるか（深夜か、昼のピークか）
何度に分かれて止まるか（短い停止が多数か、長い停止が一回か）
遅延や劣化（重くなる、時々エラー）の扱い
計画メンテナンスや外部要因の除外条件

つまり、同じ「99.9%」でもビジネス影響は大きく変わり得ます。

月間停止時間の目安：数字で直感をつかむ

「1か月=約30日=43,200分」でざっくり換算すると、次のような停止時間になります。

99%（2つの9）: 約432分（7時間12分）
99.9%（3つの9）: 約43.2分
99.95%: 約21.6分
99.99%（4つの9）: 約4.32分
99.999%（5つの9）: 約0.432分（約26秒）

数字は目安で、ベンダーによって「月」の定義や除外条件が異なります。正確には各SLA本文を確認しましょう。

よくある誤解と落とし穴

「9が1つ増えるだけでしょ？」: 99.9%→99.99%は、43分→約4分へと10倍以上の差。コストも設計の手間も跳ね上がりやすい点に注意。
「SLA=実力保証」: 多くは返金クレジットでの補償。実被害や逸失利益はカバー外が一般的。
「1サービスが高可用なら全体も高可用」: 依存を重ねると可用性は掛け算で下がる（例: 0.999×0.999×0.999≒99.7%）。
「予定メンテは停止に含まれる」: 除外されることが多い。通知条件や時間帯ルールを要確認。
「地域障害も含む」: 単一リージョンSLAでは地域全体の障害が除外または想定外の場合も。

設計視点：可用性は“足し算”ではなく“掛け算”

複数コンポーネントが直列につながるほど、全体の可用性は下がります。逆に、冗長化（並列化）すれば上がります。例えば、同一リージョン内で2つの独立ゾーンにまたがって構成するだけでも、障害の局所化と自動フェイルオーバーが期待できます。ただしデータ整合性やコスト、複雑さが増すため、要件に応じたバランスが重要です。

実務でできる対処とコツ

要件の言語化: 「平日日中は止めない」「5分以内に復旧でOK」など、ビジネスと技術の共通言語を作る。
依存の見える化: DNS、ID基盤、キュー、外部APIなどの可用性も含めて全体図を作る。
リトライ・タイムアウト: 一時的な失敗に強いクライアント実装で体感停止を減らす。
段階的冗長化: まずマルチAZ、次に仕組みが成熟したらマルチリージョンへ。
測定と内製SLO: エンドツーエンドの実測（合格率やレイテンシ）で“使える体験”を管理。
練習と手順化: 障害想定訓練、Runbook、アラートのノイズ削減で復旧時間を短縮。

「月間停止時間の真実」と向き合うために

“9の数”は便利な指標ですが、現実の止まり方、除外条件、依存の連鎖、利用者体験までは語ってくれません。数字をうのみにせず、ビジネスが許容できる停止の姿をまず定義し、それに沿って設計・運用・測定を回すことが肝心です。SLAは出発点、最終ゴールは「ユーザーが困らないこと」。この視点を持てば、真に意味のある可用性向上に投資できます。