--- title: "可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】" url: "https://www.issoh.co.jp/tech/details/13423/" published: 2026-07-10 updated: 2026-10-01 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # 可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】 可用性（アベイラビリティ）とは、システムが停止せずに動き続けられる度合いを指し、実務では「稼働率」という数字で測ります。この記事では、稼働率99.9%が年間どれだけの停止時間を意味するのか、MTBFとMTTRから可用性をどう計算するのか、単一障害点（SPOF）をどう見つけて冗長化・フェイルオーバー・負荷分散で消すのか、クラウドのSLAをどう読むのかを、インフラ設計の実装目線で整理します。そのうえで「自社は稼働率をどこまで上げるべきか」に、停止コストを軸に条件付きで示すのが本記事の狙いです。 ## まとめ｜可用性の測り方と高可用性をどこまで求めるかの判断基準 可用性は、システムが使える状態をどれだけ維持できるかを表す指標で、稼働率（%）で数値化します。稼働率は MTBF（平均故障間隔）÷（MTBF＋MTTR（平均修復時間））で求まり、「壊れにくさ」と「直しの速さ」の両方で決まります。数字の読み方を先に押さえると設計がぶれません。稼働率99.9%は年間約8.76時間、99.99%なら年間約52分の停止に相当します。9が1つ増えるごとに、許される停止は約10分の1に縮みます。 可用性を上げる中心は、止まると全体が落ちる箇所（単一障害点、SPOF）を冗長化で消すことです。サーバーやネットワークを二重化し、障害時に予備へ自動で切り替える（フェイルオーバー）。前段に負荷分散を置いて1台の故障を残りで吸収する。データはレプリケーションで複製する。この積み重ねで稼働率が決まります。ただし9を1つ増やすたびに、費用と運用の複雑さは跳ね上がる一方です。本記事の結論は明快で、稼働率目標は流行や横並びで決めず、「1時間止まると自社はいくら失うか」を先に見積もり、その損失が冗長化コストを上回る水準までしか上げない——これが過剰投資を避ける判断基準になります。 ## 可用性とは｜稼働率で測るシステムが動き続ける能力と信頼性の指標 可用性は、利用者が使いたいときにシステムが使える状態にある度合いを指します。英語のAvailabilityの訳で、情報システムの品質を測る基本指標の1つです。まず定義と、稼働率という数値表現、その計算根拠を順に押さえます。 ### 可用性の定義と信頼性・保守性との違いをMTBFとMTTRで整理 可用性とよく混同されるのが信頼性です。信頼性（Reliability）は「壊れにくさ」、つまりどれだけ故障せずに動き続けるかを指し、MTBFで測ります。保守性（Maintainability）は「直しやすさ」で、壊れてからどれだけ速く復旧できるかを指し、MTTRで測ります。可用性は、この2つを合わせた結果として「使える割合」を表す上位の概念です。壊れにくくても復旧に丸1日かかれば可用性は下がり、たまに壊れても数秒で自動復旧すれば可用性は高く保てます。つまり可用性を上げる道は「壊れにくくする」と「速く直す」の2方向あり、どちらに投資するかが設計判断の出発点になります。 ### 稼働率と9の数（99.9%系）が示す年間停止時間と読み方の目安 稼働率は、ある期間のうちシステムが正常に使えた時間の割合で、パーセントで表します。実務での言い回しは「ナイン（9）がいくつ並ぶか」。1年は8,760時間（365日）なので、稼働率が下がるほど許される停止時間は具体的な長さになります。下表は年間の停止許容時間の目安です。 | 稼働率 | 呼び方 | 年間の停止許容時間（目安） | | ------- | ------- | --------------- | | 99% | ツーナイン | 約87.6時間（約3.65日） | | 99.9% | スリーナイン | 約8.76時間 | | 99.99% | フォーナイン | 約52.6分 | | 99.999% | ファイブナイン | 約5.26分 | 9が1つ増えるたびに、許容停止時間はおよそ10分の1になります。社内ツールなら99%で足りることが多く、決済や予約のように止まると売上に直結する基幹では99.99%以上が求められる、という具合に、この表が要件の物差しになります。 ### MTBFとMTTRから可用性を計算する式と稼働率を上げる勘所 可用性は、次の式で計算します。可用性 ＝ MTBF ÷（MTBF ＋ MTTR）。MTBFは平均故障間隔（Mean Time Between Failures）で連続稼働できる平均時間、MTTRは平均修復時間（Mean Time To Repair）で故障から復旧までの平均時間です。たとえばMTBFが1,000時間、MTTRが1時間なら、可用性は1000÷1001＝約99.9%になります。この式が示すのは、可用性を上げる手段が2つあるという事実です。MTBFを伸ばす（部品の品質を上げ、冗長化で故障の影響を減らす）か、MTTRを縮める（監視と自動フェイルオーバーで復旧を速める）かです。現場では、故障ゼロを目指すより、壊れる前提でMTTRを短くするほうが費用対効果が高い場面が多くあります。監視で障害を数秒で検知し、予備系へ自動で切り替える設計は、まさにMTTRを縮めて可用性を押し上げる打ち手になります。MTTR（平均修復時間）の計算式やMTBFとの違い、短縮の実装策は[MTTRとは？計算式・MTBFとの違いと稼働率への影響](https://www.issoh.co.jp/tech/details/13801/)で詳しく解説しています。 ## 可用性を下げる単一障害点（SPOF）と計画停止・計画外停止の整理 可用性を設計するには、まず「何が止まると全体が落ちるか」を洗い出します。ここを見誤ると、いくら高価な機器を並べても弱点は残ります。押さえるべきは、単一障害点という考え方と、止まり方の分類です。 ### 単一障害点（SPOF）とは何か・システム構成のどこに潜むかの整理 単一障害点（SPOF：Single Point of Failure）とは、そこが1つ壊れるとシステム全体が停止してしまう箇所です。可用性設計の核心は、このSPOFを1つずつ潰していく作業だと言えます。SPOFは意外な場所に潜みます。サーバーを2台に増やしても、その前段のロードバランサーが1台なら、そこがSPOFです。サーバーとネットワークを冗長化しても、電源が1系統なら電源がSPOFになります。データベースが1台なら、Webサーバーを何台並べてもデータベース停止で全滅です。ネットワークスイッチ、電源、空調、そして単一のデータセンターそのものもSPOFになり得ます。設計時は構成図を上流から下流までたどり、「ここが1つだけの箇所はどこか」を機械的に列挙するのが実務の第一歩です。列挙したSPOFのうち、止まったときの影響が大きい順に冗長化していきます。 ### 計画停止と計画外停止を区別した可用性の考え方と稼働率への影響 システムの停止には2種類あります。計画停止は、メンテナンスやアップデートのためにあらかじめ予定して止めるもの、計画外停止は、障害で予期せず落ちるものです。稼働率の計算でどちらを分母から除くかは、SLAの取り決めで変わります。可用性を高める設計とは、この両方を減らす取り組みです。計画外停止は冗長化と自動フェイルオーバーで減らし、計画停止はローリングアップデート（1台ずつ順に更新し全体は止めない）や無停止でのデプロイで減らします。とくに24時間365日動くサービスでは、計画停止をゼロに近づける仕組みこそ可用性の分かれ目です。どちらの停止をどこまで許容するかを先に決めると、必要な冗長構成の水準が具体化します。 ## 可用性を高める冗長化・フェイルオーバー・負荷分散によるSPOF排除の設計 可用性を上げる実装は、大きく「二重化して壊れても続ける」仕組みと「壊れた瞬間に切り替える」仕組み、そして「複数台で受けて偏りを防ぐ」仕組みの組み合わせです。SPOFを消す代表的な手法を、構成要素ごとに見ていきます。 ### 冗長化（Active-StandbyとActive-Active）でSPOFを消す構成 冗長化は、機器や経路を複数用意して、1つが壊れても残りで処理を続ける設計です。可用性を高める最も基本的な手段になります。組み方は大きく2つに分かれます。稼働系（Active）が動き、予備系（Standby）は待機して障害時に引き継ぐのがActive-Standbyです。複数系統を同時に稼働させ、1系統が落ちても残りで受け続けるのがActive-Activeで、待機リソースを遊ばせないぶん効率的です。どこまで二重化するかは費用と要件で決めます。対象はサーバー、ネットワーク、電源、そしてデータセンター（地理的冗長化）まで。広げるほど可用性は上がり、費用も膨らみます。冗長化の種類ごとの構成と設計判断は、判断ハブとして[冗長化の種類と構成、企業の設計判断の解説](https://www.issoh.co.jp/column/details/13356/)にまとめており、本記事はその可用性という目的側から全体像を示します。 ### フェイルオーバーとフェイルバックによる自動切り替えの実装手順 フェイルオーバーは、稼働系に障害が起きたとき、処理を予備系へ自動で切り替える動きです。可用性の実効性は、この切り替えがどれだけ速く確実に起きるかで決まります。手動で人が切り替えるとMTTRが数十分に伸びますが、自動化すれば数秒から数十秒に縮まります。実装の骨子は、稼働系の生死を常時監視し、応答が途切れたら予備系を昇格させることです。データベースなら、監視ミドルウェアが主系（プライマリ）のダウンを検知して副系（レプリカ）を新しい主系へ昇格させる、といった流れです。障害から回復した系を元へ戻す動きはフェイルバックと呼びます。切り替えの瞬間すら止めず系を常時並行実行して無停止を狙う設計は[フォールトトレラントとは？耐障害性の仕組みと高可用性・フェイルオーバーとの違いを実装目線で解説](https://www.issoh.co.jp/tech/details/15221/)で扱っています。注意したいのは、稼働系と予備系が互いに相手を落ちたと誤認して両方が主系になる「スプリットブレイン」で、これを防ぐために第三の監視点（クォーラム）を置くのが定石です。 ### 負荷分散（ロードバランサー）による可用性とスケールアウトの両立 負荷分散は、前段に振り分け役を置いて複数のサーバーへリクエストを配る仕組みです。可用性の観点では、1台のサーバーが落ちても振り分け先から自動で外し、残りの台数で受け続けられる点が効きます。ロードバランサーの働きはヘルスチェックによる生存確認で、応答しないサーバーをプールから切り離す仕組みです。これによりサーバー層のSPOFが消え、同時に台数を増やして処理能力も伸ばせるため、可用性とスケールアウトを1つの構成で両立できます。台数で伸ばす水平スケールと1台を増強する垂直スケールの使い分けは[スケールアウトとスケールアップの解説](https://www.issoh.co.jp/tech/details/13594/)で扱っています。ロードバランサー自身が新たなSPOFにならないよう、これも2台以上で冗長化するのが前提です。Google Cloudのマネージド負荷分散で冗長構成を組む具体は[Cloud Load Balancingの記事](https://www.issoh.co.jp/tech/details/15669/)で解説しています。振り分け方式やL4/L7の違い、ヘルスチェックの設計といった実装の詳細は[ロードバランサーの仕組みと種類・振り分け方式の解説](https://www.issoh.co.jp/tech/details/13137/)で扱っており、本記事では可用性を支える部品としての役割に絞ります。 ### データの可用性を守るレプリケーションとバックアップの使い分け サーバーを冗長化しても、データが1箇所にしかなければデータストアがSPOFのままです。データの可用性は、レプリケーションとバックアップという性質の異なる2つで守ります。レプリケーションは、データを複数のノードへリアルタイムに近い形で複製し、1台が落ちても別ノードで即座に読み書きを続けられるようにする仕組みで、可用性の維持が目的です。バックアップは、ある時点のデータを別媒体へ退避しておき、誤削除や破損から復元するための仕組みで、こちらはデータ保全が目的になります。両者は代替関係ではありません。レプリケーションは瞬時の切り替えに強い一方、誤ってデータを消せば複製先にも伝わってしまうため、過去の時点へ戻せるバックアップが別に要ります。可用性のためのレプリケーションと、復旧のためのバックアップを、目的で分けて両方持つのが堅実な設計です。 ## クラウドとオンプレミスで異なる可用性の担保方法とSLAの読み方 可用性をどう作るかは、オンプレミスとクラウドで手段が変わります。自前で機器を冗長化するのか、クラウドの標準機能に載せるのか。それぞれの前提と、クラウドのSLAの読み方を押さえます。 ### オンプレミスの自前冗長化とクラウドのマルチAZ/リージョン構成 オンプレミスでは、可用性はすべて自前で作り込みます。サーバーやストレージの二重化、予備電源（UPS・自家発電）、回線の冗長化、そして災害に備えた別拠点のデータセンターまで、機器と場所を自社でそろえる世界です。制御は細かく効く反面、初期投資と運用負荷は大きくなります。対してクラウドでは、可用性を高める部品が標準機能として提供されるのが特徴です。AWSなら、物理的に離れた複数のデータセンター群（アベイラビリティゾーン、AZ）にまたがるマルチAZ構成を組め、1つのAZが災害で落ちても別AZで継続できます。広域災害への備えは、東京と大阪のように地理的に離れたリージョン間で構成するマルチリージョン。マネージドのデータベースやロードバランサーは、内部で冗長化された状態で提供されるため、利用者が個別に組む手間は小さくて済みます。自前で作り込むか、クラウドの標準冗長化に載せるかが、可用性設計の分岐点です。 ### クラウドのSLA（稼働率保証）の読み方と可用性設計への織り込み クラウド事業者は、サービスごとに稼働率をSLA（サービス品質保証）として提示します。ここで注意すべきは、SLAの数値が「単体構成での保証」か「冗長構成を組んだ場合の保証」かで変わる点です。たとえば仮想サーバーは、単一インスタンスと複数AZ構成とで保証される稼働率が異なるのが一般的で、高い稼働率を得るには利用者側で冗長構成を組むことが条件になります。SLAはまた、実際の可用性の保証ではなく、下回ったときの返金（クレジット）の取り決めである点も見落とせません。SLAで99.99%と書かれていても、それは事業者側の努力目標と補償の基準であり、自社の使い方次第で実際の可用性は変わります。設計で必要なのは、使うサービスのSLAを確認し、目標稼働率に届く構成（マルチAZ化など）を自分で選ぶことです。AWSの主要サービスのSLA値と99.99%が適用される構成の条件は[AWSのSLA一覧とクレジット申請の手順](https://www.issoh.co.jp/tech/details/18016/)にまとめています。SLAとSLO・SLIの違いや稼働率目標の決め方は[SLA・SLO・SLIの違いと稼働率の決め方の解説](https://www.issoh.co.jp/tech/details/13410/)で詳しく扱っています。 ## 企業が可用性をどこまで上げるか｜稼働率目標と過剰投資を避ける判断 ここは他社の解説が踏み込まない、可用性への投資水準を言い切る章です。原則は「稼働率目標は停止コストから逆算し、そこまでしか上げない」で、9を増やすこと自体を目的にしません。9を1つ増やすたびに構成と運用費は段階的に膨らむため、どこで止めるかの判断が費用対効果を決めます。 ### 稼働率目標（99.9%か99.99%か）を停止コストから決める基準 出発点は、システムが1時間止まったときの損失額からの逆算です。ECや予約、決済、業務基幹のように停止が売上や信用へ直結するシステムは、99.99%以上を狙う投資に合理性があります。年間52分程度への抑制には、マルチAZの冗長化・自動フェイルオーバー・無停止デプロイまでの作り込みが要る水準です。一方、社内の情報共有ツールや更新頻度の低いサイトは、99.9%（年間約8.76時間の停止許容）で十分なことが多く、そこへ99.99%を求めると費用ばかりが増えます。判断軸は稼働率の数字そのものではなく、「その停止時間で失う金額が、冗長化にかける費用を上回るか」です。上回るなら次の9へ、下回るなら現状維持が正解になります。 ### 高可用性を見送ってよい場面と単純な構成で足りるケースの見極め 高可用性が過剰になる場面も、はっきりしています。アクセスが少なく、短時間の停止が業務上許容できるシステムでは、二重化のコストが便益を上回ります。夜間バッチ専用のサーバー、社内の検証環境、参照が中心で更新の少ない情報サイトなどが典型です。こうしたケースで多系統の冗長構成を組むのは、見送るべき典型です。単一構成のまま、監視で障害を早く検知し、バックアップから短時間で復旧できる体制を固めるほうが、費用対効果は高くなります。「他社が99.99%だから」「冗長化しておけば安心だから」という横並びや漠然とした不安で9を積み増すと、使われない予備系の費用と運用の複雑さだけが残ります。要件が「止まると困る」レベルに達していないなら、シンプルな構成にMTTRを縮める監視・復旧手順を組み合わせるのが、最も割の合う選択です。 ### クラウド移行と合わせて可用性設計を開発会社へ相談する際の進め方 可用性の設計は、サーバー構成・データのレプリケーション・監視・自動フェイルオーバー・SLAの選定がかみ合って初めて効きます。個々の機器を二重化しても、データが1箇所に残っていたり、フェイルオーバーの検証をしていなかったりすれば、いざという時に切り替わりません。自社に基盤設計の知見が薄い、あるいは既存システムのクラウド移行に合わせて冗長構成を組みたい場合は、目標稼働率の設定から構成設計・実装までを一貫して支援できる開発会社に相談すると、作り直しを避けられます。一創では[AWS/GCP/Azureでの可用性を含むインフラ構築](https://www.issoh.co.jp/service/system/aws/)として、停止コストに見合った冗長構成の設計から運用まで対応しています。 ## 可用性に関するよくある質問｜稼働率・冗長化・信頼性についての疑問 可用性をこれから設計する担当者や、稼働率目標の設定を控えた技術者から寄せられやすい質問に答えます。 ### 可用性と信頼性はどう違うのですか？ 信頼性は「壊れにくさ」で、どれだけ故障せず連続稼働できるかを表しMTBFで測ります。可用性は「使える割合」で、壊れにくさと直しの速さ（MTTR）を合わせた結果として稼働率で表します。たまに壊れても数秒で自動復旧すれば可用性は高く保て、逆に壊れにくくても復旧に丸1日かかれば可用性は下がるという関係です。信頼性は可用性を構成する要素の1つ、という位置づけになります。 ### 稼働率99.9%と99.99%では何が変わりますか？ 変わるのは年間の停止許容時間です。99.9%は年間約8.76時間、99.99%は年間約52.6分で、9が1つ増えると許される停止時間はおよそ10分の1になります。この差を埋めるには、単一構成から複数AZの冗長化や自動フェイルオーバーへと構成を作り込む必要があり、費用と運用負荷も段階的に増える点は見落とせません。どちらを狙うかは、停止で失う金額から逆算して決めます。 ### 可用性はどうやって計算するのですか？ 可用性 ＝ MTBF ÷（MTBF ＋ MTTR）で計算します。MTBFは平均故障間隔（連続稼働できる平均時間）、MTTRは平均修復時間（故障から復旧までの平均時間）です。たとえばMTBFが1,000時間、MTTRが1時間なら1000÷1001で約99.9%になります。この式から、故障間隔を伸ばすか復旧時間を縮めるかの2方向で可用性を改善できることが分かります。 ### 冗長化すれば可用性は必ず上がりますか？ 単一障害点を正しく消せていれば上がりますが、冗長化しても弱点が残ると効果は限定的です。サーバーを2台にしても前段のロードバランサーが1台なら、そこが新たな単一障害点になります。また、フェイルオーバーの切り替えを検証していなければ、障害時に予備へ切り替わらないこともあります。冗長化が効くのは、「どこがSPOFか」を洗い出し、切り替えを実際に試すところまでやり切ったときです。 ### 中小規模のシステムでも高可用性は必要ですか？ 要件次第で、常に必要とは限りません。短時間の停止が業務上許容できる社内ツールや参照中心のサイトなら、99.9%程度でも足り、多系統の冗長構成は過剰になりがちです。判断軸は規模ではなく「止まったときの損失額」で、それが冗長化コストを上回るなら投資する価値があります。まずは監視とバックアップで復旧を速める体制を固め、要件が上がった段階で冗長化を足すのが現実的です。 ## 関連記事 - [冗長化とは？二重化との違い・種類と構成、企業の設計判断まで解説](https://www.issoh.co.jp/column/details/13356/)：可用性を高める代表手段である冗長化の種類と構成、どこまで組むかの設計判断を扱う判断ハブです。 - [ロードバランサーとは？仕組み・種類・振り分け方式を実装目線で解説](https://www.issoh.co.jp/tech/details/13137/)：可用性とスケールを両立する負荷分散の内部機構と振り分け方式を詳しく解説しています。 - [SLAとは？SLO・SLIとの違いと稼働率の決め方・監視実装をエンジニア視点で解説](https://www.issoh.co.jp/tech/details/13410/)：稼働率目標をどう合意し監視するか、SLA/SLO/SLIの違いから整理した記事です。 - [非機能要件とは？6大項目の数値化とk6での閾値テストまで実装目線で解説](https://www.issoh.co.jp/tech/details/17610/)：稼働率の目標値をIPAのレベル表から決める手順を確認したい場合に --- 出典: [可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】]()（株式会社一創）