可用性とは？ファイブナイン（99.999%）の停止時間と稼働率の計算、SLAの読み方

可用性とは、システムを使いたいときに使える状態にある度合いのことで、ふつうは稼働率（%）で表します。ファイブナインは稼働率99.999%のことで、止まってよい時間は1年でわずか約5分15秒、1か月（30日）なら約26秒です。

この記事では、「ナイン」の数ごとに許される停止時間をPythonで計算し、稼働率の求め方、クラウドのSLA（サービス品質保証）の読み方、可用性を上げる考え方を順に説明します。

可用性（アベイラビリティ）とは

可用性は英語のavailabilityの訳で、「必要なときにシステムを利用できること」を指します。情報セキュリティの3要素（機密性・完全性・可用性）の一つとしても使われる言葉です。

システムを発注・設計するときに決める「非機能要求」でも、可用性は中心的な項目です。情報処理推進機構（IPA）が公開している非機能要求グレードでは、非機能要求を可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分けて整理しています。可用性は「どれだけ止まらずに動き続けるか」「止まったときにどれだけ早く戻るか」を決める項目です。

可用性の高さは、多くの場合、次の式の稼働率で表します。

稼働率（%）＝実際に使えた時間 ÷ 使えるはずだった時間 × 100

たとえば、1か月（30日＝43,200分）のうち合計43分止まったなら、稼働率は (43,200 − 43) ÷ 43,200 × 100 ≒ 99.9% です。

ファイブナインとは：ナインの数と停止時間の早見表

稼働率の「9」の数で可用性の水準を呼ぶ言い方があり、99.999%は9が5つ並ぶので「ファイブナイン」と呼びます。9が1つ増えるごとに、許される停止時間は10分の1になります。次のPythonコードで、1年（365日）と1か月（30日）に許される停止時間を計算しました。

def fmt(minutes):
    if minutes >= 60:
        h, m = divmod(minutes, 60)
        return f"{int(h)}時間{m:.0f}分"
    if minutes >= 1:
        return f"{minutes:.1f}分"
    return f"{minutes*60:.1f}秒"

YEAR = 365 * 24 * 60   # 1年（365日）の分数
MONTH = 30 * 24 * 60   # 1か月（30日）の分数

for name, a in [("ツーナイン", 0.99), ("スリーナイン", 0.999),
                ("フォーナイン", 0.9999), ("ファイブナイン", 0.99999),
                ("シックスナイン", 0.999999)]:
    print(f"{name:　<7} {a*100:.4f}%  年間 {fmt(YEAR*(1-a)):>10}  月間 {fmt(MONTH*(1-a)):>8}")

実行結果（Python 3.12.15）：

ツーナイン　　 99.0000%  年間    87時間36分  月間   7時間12分
スリーナイン　 99.9000%  年間     8時間46分  月間    43.2分
フォーナイン　 99.9900%  年間      52.6分  月間     4.3分
ファイブナイン 99.9990%  年間       5.3分  月間    25.9秒
シックスナイン 99.9999%  年間      31.5秒  月間     2.6秒

呼び方	稼働率	1年に許される停止	1か月（30日）に許される停止
ツーナイン	99%	約87時間36分（約3.65日）	約7時間12分
スリーナイン	99.9%	約8時間46分	約43分
フォーナイン	99.99%	約52分34秒	約4分19秒
ファイブナイン	99.999%	約5分15秒	約26秒
シックスナイン	99.9999%	約32秒	約2.6秒

ファイブナインの「年に約5分」には、計画メンテナンスで止めた時間も含めるのかどうかで意味が大きく変わります。サーバーの再起動やソフトウェアの更新を1回するだけで数分かかることもあるので、ファイブナインを実現するには「止めずに更新できる仕組み」が前提になります。

稼働率をMTBFとMTTRから計算する

稼働率は、故障の起きにくさと直る速さからも計算できます。

MTBF（平均故障間隔）：故障してから次に故障するまでの平均時間。長いほど壊れにくい
MTTR（平均修復時間）：故障してから直るまでの平均時間。短いほど早く戻る

稼働率＝ MTBF ÷（MTBF ＋ MTTR）

MTBFを2,000時間に固定して、MTTR（直るまでの時間）だけを変えてみます。

# 稼働率 = MTBF / (MTBF + MTTR)
mtbf = 2000   # 平均故障間隔（時間）
for mttr in [4, 1, 0.25]:
    a = mtbf / (mtbf + mttr)
    print(f"MTTR {mttr:>5}時間 → 稼働率 {a*100:.4f}%")

MTTR     4時間 → 稼働率 99.8004%
MTTR     1時間 → 稼働率 99.9500%
MTTR  0.25時間 → 稼働率 99.9875%

壊れる頻度が同じでも、復旧を4時間から15分に縮めるだけで、稼働率はスリーナイン未満からフォーナイン近くまで上がります。可用性を上げるには「壊れないようにする」ことに加え、「すぐ気づいて、すぐ戻す」ことが同じくらい効きます。監視や自動切り替えが重視されるのはこのためです。

サーバーを直列・並列につないだときの稼働率（冗長化したときの計算）は、冗長化とは？意味・方式と稼働率の計算で詳しく解説しています。

可用性と信頼性・保守性の違い（RASIS）

システムの「止まりにくさ」を表す言葉には、可用性のほかにも似たものがあります。頭文字をとってRASIS（ラシス）と呼ばれ、基本情報技術者試験などでもよく出てきます。

頭文字	意味	主な指標
R：Reliability（信頼性）	故障しにくいこと	MTBF
A：Availability（可用性）	使いたいときに使えること	稼働率
S：Serviceability（保守性）	故障したときに直しやすいこと	MTTR
I：Integrity（保全性・完全性）	データが壊れたり矛盾したりしないこと	－
S：Security（安全性・機密性）	不正な利用や情報漏えいを防げること	－

可用性は、信頼性（壊れにくさ）と保守性（直しやすさ）の結果として決まります。稼働率＝MTBF÷（MTBF＋MTTR）という式は、まさにこの関係を表しています。

稼働率を測るときの注意

同じ「99.9%」でも、何を停止として数えるかで中身は変わります。数字だけを比べる前に、次の点を確認しましょう。

計画停止を含めるか：事前に告知したメンテナンスの時間を、停止に数えない約束になっていることがあります。
どこから見て「使えない」か：サーバーが動いていても、ネットワークや認証の障害で利用者がつながらなければ、利用者にとっては停止です。
測る期間：月単位か年単位かで、1回の長い停止の重みが変わります。月間99.9%なら、ある月に1時間止まった時点でその月は目標を下回ります。
一部だけの停止：一部の機能や一部の利用者だけが使えない状態を、停止に数えるかどうかを決めておきます。

クラウドのSLAで可用性を読む

クラウドサービスは、SLA（サービスレベル契約）で月間の稼働率の目標を約束し、下回った場合は利用料の一部をクレジット（返金の代わりの割引）で返す、という形をとっています。代表例として仮想サーバーのSLAを確認しました（2026年10月15日確認）。

サービス	構成	月間稼働率の約束
Amazon EC2（Amazon Compute SLA）	リージョン単位（複数のアベイラビリティーゾーンに配置）	99.99%
Amazon EC2（Amazon Compute SLA）	インスタンス1台ごと	99.5%
Google Compute Engine（Compute Engine SLA）	複数ゾーンに配置したインスタンス	99.99%以上
	メモリ最適化の単一インスタンス	99.95%以上
	その他の単一インスタンス	99.9%以上

この表から読み取れることは2つあります。1つ目は、同じサービスでも構成によって約束される稼働率が違うことです。サーバー1台だけなら99.5〜99.9%で、複数のゾーンに分けて配置して初めて99.99%になります。2つ目は、大手クラウドの仮想サーバーでも、SLAはファイブナインではないことです。ファイブナインを目指すなら、クラウドの上でさらに冗長化や切り替えの仕組みを自分で組む必要があります。

また、SLAは「その稼働率を下回ったらクレジットを返す」という約束で、停止しないことの保証ではありません。たとえばAmazon EC2のリージョン単位のSLAは、99.99%未満99.0%以上ならクレジット10%、という段階制です。

停止時間の目安に直すと、次のようになります。

# 月間稼働率から「止まっていた時間」を逆算する
def downtime_minutes(percent, days=30):
    return days * 24 * 60 * (1 - percent / 100)

for p in [99.99, 99.9, 99.5]:
    print(f"月間{p}% → 30日の月で最大 {downtime_minutes(p):.1f}分の停止")

月間99.99% → 30日の月で最大 4.3分の停止
月間99.9% → 30日の月で最大 43.2分の停止
月間99.5% → 30日の月で最大 216.0分の停止

可用性を上げる主な方法

方法	考え方	効く対象
冗長化	同じ役割の機器を複数用意し、1台が壊れても残りで動かす	故障による停止（MTBFを実質的に延ばす）
負荷分散	アクセスを複数のサーバーに振り分け、壊れたサーバーを外す	過負荷による停止・1台の故障
複数拠点への配置	ゾーンやリージョン（データセンター）を分けて置く	停電・災害など拠点ごと止まる障害
監視と自動復旧	異常をすぐ検知し、自動で再起動・切り替えをする	復旧までの時間（MTTR）
止めずに更新する手順	1台ずつ入れ替えるなど、サービスを止めずにメンテナンスする	計画停止
バックアップと復旧訓練	データを別の場所に保存し、戻す手順を実際に試しておく	データ破損・誤操作からの復旧時間

負荷分散の仕組みはロードバランシングとは？で、Pythonを使って振り分け方の違いを確かめています。

ファイブナインは必要か：目標の決め方

9を1つ増やすごとに、許される停止時間は10分の1になり、そのための仕組みと運用の手間は大きく増えます。すべてのシステムにファイブナインが必要なわけではありません。目標を決めるときは、次の順に考えると現実的です。

止まると誰がどれだけ困るかを洗い出す（社内の業務が数時間止まる程度か、決済や予約のように止まると取引が失われるか）
使う時間帯を決める（24時間365日か、平日の営業時間だけか。夜間に止めてよければ計画停止の自由度が上がる）
止まったときに何分で戻すか（MTTRの目標）を決める
それを満たす構成と費用を比べ、稼働率の目標を数字で合意する

IPAの非機能要求グレードは、こうした項目を発注者と開発者が漏れなく話し合うためのチェックリストとして使えます。

よくある質問

Q. ファイブナインとは何ですか？

稼働率99.999%のことです。9が5つ並ぶのでファイブナインと呼びます。止まってよい時間は1年で約5分15秒、30日の月で約26秒です。

Q. 可用性はどうやって計算しますか？

稼働率＝実際に使えた時間÷使えるはずだった時間×100で計算します。故障の統計から求める場合は、稼働率＝MTBF÷（MTBF＋MTTR）を使います。

Q. スリーナインとフォーナインの違いはどれくらいですか？

1年に許される停止時間が、スリーナイン（99.9%）は約8時間46分、フォーナイン（99.99%）は約52分です。9が1つ増えるごとに許される停止時間は10分の1になります。

Q. クラウドを使えばファイブナインになりますか？

なりません。2026年10月15日時点で、Amazon EC2のSLAはリージョン単位で月間99.99%、インスタンス1台では99.5%、Google Compute Engineは複数ゾーン配置で99.99%以上です。ファイブナインを目指すには、その上で冗長化や切り替えの仕組みを組む必要があります。