システム稼働率の計算式と停止時間一覧｜直列並列・SLA設計まで徹底解説

クラウドインフラの普及やサービスの24時間365日連続稼働が当たり前となった現在、サービスの信頼性を測る客観的な指標として「システム稼働率（アベイラビリティ）」の重要性が再認識されています。情報処理技術者試験の頻出計算問題として対策を進めるエンジニアだけでなく、自社サービスのSLA（サービス品質保証）を策定するプロダクトマネージャーや情シス担当者にとっても、正確な計算手法の習得は避けて通れません。

稼働率の算出には、平均故障間隔（MTBF）や平均復旧時間（MTTR）を用いた基本公式から、直列・並列・複合システムといったアーキテクチャ別の計算ルールまで、明確な体系が存在します。本稿では、実務のSLA策定から試験対策、さらにはExcelでの計算方法や年間許容停止時間の早見表まで、現場の知見を交えて体系的に解説します。

📌 【この記事の重要ポイントまとめ】

• 要点1：基本計算式は「稼働率 ＝ MTBF ÷ (MTBF ＋ MTTR)」であり、実稼働時間ベースでは「(計画稼働時間 － 停止時間) ÷ 計画稼働時間」で算出する。
• 要点2：直列構成は掛け算で全体の稼働率が低下し、並列構成は冗長化によって「1 － (1 － 稼働率)^n」で飛躍的に可用性が向上する。
• 要点3：稼働率99.9%（スリーナイン）の年間許容停止時間は約8.76時間、99.99%（フォーナイン）では約52.6分となり、小数点第1位の差で運用コストと設計難易度が激変する。

【基本公式】MTBFとMTTRで求めるアベイラビリティ計算方法

システムの信頼性を定量的に評価する際、最も基本となる可用性（アベイラビリティ）の指標が「稼働率」です。稼働率とは、システムが規定の運用時間内において、要求された機能を正常に果たし続けている時間の割合を指します。

稼働率の計算には、大きく分けて「障害実績データ（MTBF・MTTR）から算出する方法」と「一定期間の計画稼働時間と停止時間から算出する方法」の2種類が存在します。

システムの信頼性工学において用いられる基本公式は以下の通りです。

$$\text{稼働率（アベイラビリティ）} = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$$

• MTBF（Mean Time Between Failures：平均故障間隔）：システムが修理・復旧してから次に故障するまでの平均連続稼働時間。数値が大きいほど「壊れにくい（信頼性が高い）」ことを示します。
• MTTR（Mean Time To Repair：平均復旧時間）：システムが故障してから修理・復旧を完了し、再稼働するまでにかかる平均時間。数値が小さいほど「直しやすい（保守性が高い）」ことを意味します。

例えば、あるサーバーが平均して720時間連続稼働し、故障時の復旧に平均2時間を要している場合、計算式は以下のようになります。

$$\text{稼働率} = \frac{720}{720 + 2} = \frac{720}{722} \fallingdotseq 0.99723 \quad (99.72\%)$$

一方、月次や年次のサービスレポート作成など実務現場で多用されるのは、カレンダー時間ベースの計算式です。

$$\text{稼働率} = \frac{\text{計画稼働時間} - \text{停止時間（ダウンタイム）}}{\text{計画稼働時間}} \times 100$$

仮に1か月（30日＝720時間）の24時間稼働サービスで、突発的なシステム障害によって合計3時間のダウンタイムが発生した場合、稼働時間は「720時間 － 3時間 ＝ 717時間」となり、稼働率は「717 ÷ 720 × 100 ＝ 99.58%」と算出されます。

実務で使えるExcel（エクセル）での計算式

日々の運用ログや障害管理シートで稼働率を集計する場合、Excelを活用すれば瞬時に自動計算が可能です。

• MTBF/MTTRから求める場合：セルA2にMTBF、B2にMTTRが入力されている場合、=A2/(A2+B2) と入力し、セルの書式設定を「パーセンテージ（小数点第2位まで表示）」に設定します。
• 稼働時間とダウンタイムから求める場合：セルA2に総稼働時間（分）、B2に停止時間（分）がある場合、=(A2-B2)/A2 で算出可能です。単位を「時間」または「分」で統一することが誤計算を防ぐ鉄則です。

【構成別】直列・並列・複合システムの稼働率の求め方

実際のITインフラやWebサービスは、Webサーバー、APサーバー、データベースサーバー、ロードバランサーなど複数の機器が組み合わさって構成されています。システム全体の稼働率は、それらが「直列接続」されているか「並列接続」されているかによって計算アプローチが根本から異なります。

1. 直列システムの稼働率（掛け算の法則）

直列システムとは、構成要素のうちいずれか1台でも停止するとシステム全体が停止する構成を指します。

各機器の稼働率を $R_1, R_2, \dots, R_n$ とした場合、システム全体の稼働率 $R_{total}$ は各稼働率の積で求められます。

$$R_{total} = R_1 \times R_2 \times \dots \times R_n$$

例えば、稼働率90%（0.9）のサーバーを2台直列で構成した場合、全体の稼働率は「0.9 × 0.9 ＝ 0.81（81%）」に急落します。構成要素が増えるほど、全体としての可用性は個々の要素単体よりも必ず低くなるという性質を持っています。

2. 並列システムの稼働率（余事象の考え方）

並列システムとは、複数台の機器を冗長構成（Active-StandbyやActive-Active）にし、どれか1台でも正常に動いていればシステム全体が稼働を継続できる仕組みです。

並列システムの計算では、「すべての要素が同時に故障する確率（余事象）」を1から差し引きます。

$$R_{total} = 1 - (1 - R_1) \times (1 - R_2) \times \dots \times (1 - R_n)$$

稼働率90%（0.9）のサーバーを2台並列で冗長化した場合、計算は以下の通りです。

$$R_{total} = 1 - (1 - 0.9) \times (1 - 0.9) = 1 - (0.1 \times 0.1) = 1 - 0.01 = 0.99 \quad (99\%)$$

単体では90%しか稼働しない機器であっても、2重化するだけでシステム全体としては99%の高可用性を実現できることが分かります。

3. 複合システム（直列＋並列）の解き方ステップ

基本情報技術者試験や実務のインフラ設計で最も頻出するのが、直列と並列が組み合わさった「複合システム」です。複合システムを解く際は、「並列部分を先に1つの仮想コンポーネントとして計算し、最後に直列として掛け合わせる」のが鉄則です。

【例題】：
Webサーバー2台が並列冗長化（各稼働率0.9）されており、その後段にデータベースサーバー1台（稼働率0.9）が直列に接続されているシステムの全体稼働率はいくらか。

1. ステップ1（並列部分の計算）：
   Webサーバー群の稼働率 ＝ $1 - (1 - 0.9) \times (1 - 0.9) = 0.99$
2. ステップ2（直列全体の掛け算）：
   システム全体稼働率 ＝ $0.99 \times 0.9 = \mathbf{0.891 \quad (89.1\%)}$

直感的に「0.9より高くなるはず」と誤認しがちですが、単一障害点（SPOF）となるDBサーバーが存在するため、全体稼働率はDB単体の0.9（90%）を下回る結果となります。

【早見表】SLA稼働率ごとの年間・月間許容停止時間一覧

クラウドサービスやホスティング契約のSLA（Service Level Agreement：サービス品質保証契約）では、「99.9%」や「99.99%」といった稼働率目標が掲げられます。しかし、このパーセンテージが「具体的に何分・何時間のダウンタイムを許容しているのか」を直感的に把握できているエンジニアは多くありません。

年間停止時間の算出基準は、1年を365日（8,760時間＝525,600分）、1か月を30日（720時間＝43,200分）として計算します。

表から明らかなように、99.9%と99.99%の間には「年間8時間以上停止できるか、1時間未満しか止まれないか」という決定的な壁が存在します。月間に換算すると、99.99%環境ではわずか4分強の停止で即座にSLA違反となるため、人間による手動切り替え対応では間に合わず、完全自動化されたフェイルオーバー環境の構築が必須条件となります。

【実態検証】利用者の生の声と現場目線で見えたリアル

稼働率の数値設計をめぐっては、経営陣・営業部門とインフラ運用部隊の間で深刻な認識ギャップが生じるケースが後を絶ちません。大手Webサービス企業でSRE（Site Reliability Engineering）を務めるエンジニアの手記やコミュニティでの告白から、現場のリアルな実情が浮き彫りになっています。

「営業がコンペで優位に立つため、安易に『SLA 99.99%保証』と契約書に盛り込んで受注してきた。しかし実態はマルチAZ構成にすらなっておらず、深夜の定期メンテナンスでDBを再起動した瞬間に月間許容停止時間の4分を超過。顧客への返金対応と始末書作成に追われる地獄を見た」（大手SIer・30代インフラエンジニアの告白）

また、クラウドベンダーが提示する「SLA 99.99%」という数値の読み解き方にも注意が必要です。クラウドのSLAは「障害時にサービス利用料の一部を返金（サービスクレジット付与）する条件」を定めた契約上の約束事に過ぎず、「絶対に停止しないことを物理的に保証するもの」ではありません。

近年、Googleが提唱したSREの概念である「エラーバジェット（Error Budget：許容停止枠）」を導入する組織が増えています。例えば稼働率99.9%を目指す場合、残り0.1%の停止枠（月間約43分）は「新機能のリリースやリスクを伴う改善のために計画的に使い切ってよい投資枠」と再定義されます。単にダウンタイムをゼロにする過剰防衛から脱却し、ビジネススピードと信頼性のバランスを取る運用へのシフトが主流となっています。

一般に知られていない盲点とネットの誤解

システム稼働率に関して、技術者の間でも誤解されがちな2つの重大な盲点が存在します。

1. 「稼働率が高い ＝ 信頼性が高い」という致命的な勘違い

稼働率の公式「MTBF ÷ (MTBF ＋ MTTR)」を見直すと、ある数学的な事実に突き当たります。稼働率の数値を引き上げるアプローチには、以下の2通りが存在します。

• アプローチA：故障を減らし、連続稼働時間を極限まで伸ばす（MTBFを大きくする）
• アプローチB：頻繁に壊れても、瞬時に自動復旧させる（MTTRを極小化する）

例えば「1年に1回だけ故障し、復旧に8.76時間かかったシステム」と、「毎日1回壊れるが、毎回1.4秒で自動再起動するシステム」は、計算上の年間稼働率はどちらも同じ99.9%です。

しかし、前者は安定したシステムと感じられるのに対し、後者は「毎日切断される使い物にならないサービス」とユーザーに評価されます。稼働率という単一の指標だけに依存すると、ユーザー体験の劣化を見落とす危険性があります。

2. 計画停止時間を分母から除外する「計算マジック」の罠

多くのSLA条項では、「事前告知した計画メンテナンス時間」を計算の対象外（除外事項）としています。これにより、毎週末に数時間のメンテナンス停止を行っていても「稼働率99.99%達成」と発表できる構図が生まれます。

外部サービスのSLAを評価する際や自社規約を整備する際は、「停止時間のカウントがどのトリガーで開始され、計画メンテナンスがどう扱われているか」の定義確認が不可欠です。

【プロの結論】システム可用性設計の判断基準

システム稼働率をどこまで高めるべきかは、システムの特性と投下可能なコスト・人的リソースのバランスによって論理的に決定されるべき課題です。可用性を「スリーナイン（99.9%）」から「フォーナイン（99.99%）」へ引き上げる場合、インフラ費用と運用コストは数倍から10倍近くへ跳ね上がります。

高可用性（99.99%以上）設計を適用すべきケース

• ダウンタイムが直接的な巨額の金銭損失につながるシステム：決済ゲートウェイ、仮想通貨取引所、ECカート決済画面など。
• 人命や社会的インフラの中枢に関わる基盤：医療情報ネットワーク、交通管制システム、緊急警報配信システム。
• 自律的な自動復旧基盤を運用できるチーム体制：Kubernetesによるコンテナ自動再起動、マルチリージョンでの自動フェイルオーバー、IaC（Infrastructure as Code）が徹底されている環境。

99.0%〜99.9%程度にとどめ、開発速度を優先すべきケース

• 社内業務ツールや非同期バッチ処理：数時間の停止があっても業務手順の代替（ワークアラウンド）が効くシステム。
• PMF（プロダクトマーケットフィット）前の新規事業：インフラの過剰な冗長化に予算を割くよりも、機能追加のイテレーション速度を優先すべきフェーズ。
• 運用担当者が少人数のスタートアップ：深夜の即時オンコール対応が不可能な体制で厳しいSLAを掲げると、チームの疲弊と離職を招くリスクが高まります。

【システム 稼働 率 計算】に関するよくある質問（FAQ）

Q1：基本情報技術者試験で複合システムの稼働率計算を素早く解くテクニックはありますか？
A1：まず複雑に見える構成図の中から「並列接続されているブロック」を四角で囲み、先に並列の公式「1 － (1 － R)^2」で1つの稼働率にまとめます。その後、残った直列の要素と掛け合わせるという2段階の手順を徹底してください。また、「1 － (1 － 0.9)^2 ＝ 0.99」や「1 － (1 － 0.8)^2 ＝ 0.96」といった頻出の計算パターンを覚えておくと計算時間を大幅に短縮できます。

Q2：マイクロサービスアーキテクチャでは稼働率はどう計算されますか？
A2：マイクロサービスにおいて、ある処理を完結させるために5つの独立したAPIサービスを直列で順番に呼び出す場合、全体の稼働率は各APIの稼働率の積（直列計算）になります。各サービスが仮に99.9%の稼働率であっても、「0.999 × 0.999 × 0.999 × 0.999 × 0.999 ＝ 約99.5%」までシステム全体の可用性は低下します。このため、非同期キューの活用やサーキットブレーカーパターンの導入による疎結合設計が不可欠です。

Q3：MTBFが1,000時間、MTTRが10時間のシステムの稼働率は何％になりますか？
A3：公式「MTBF ÷ (MTBF ＋ MTTR)」に当てはめると、「1,000 ÷ (1,000 ＋ 10) ＝ 1,000 ÷ 1,010 ＝ 約0.9901（99.01%）」となります。小数点第3位以下を四捨五入して99.0%と表記されるのが一般的です。

まとめ：今後の動向と失敗しないための判断基準

システムの稼働率計算は、単なる机上の計算式や試験対策にとどまらず、システムのアーキテクチャ設計からビジネス上の合意形成（SLA策定）に至るまで、すべてのITエンジニアが身につけておくべき基礎リテラシーです。

直列構成では掛け算によって可用性が低下し、並列冗長化によって劇的に向上するという基本原理を理解した上で、目標とする稼働率が現場にどれだけの許容停止時間を課すのかを常に意識することが重要です。99.9%と99.99%の間に横たわる運用負荷の決定的な差を見誤ることなく、サービスのビジネス価値に見合った最適な可用性設計と運用規約の策定を推進してください。 （出典: システム 稼働 率 計算（Yahoo!ニュース））