稼働率とは？意味・計算方法とSLAでの扱い方

稼働率とは

稼働率とは、システムが動いているべき時間のうち、実際に正常に動いていた時間がどれだけあったかを表す割合のことです。

簡単に言えば「止まらずに使えていた時間の比率」です。システムが止まらずに使える性質を可用性と呼び、それを数値で示す代表的な指標が稼働率です。英語圏では Uptime（アップタイム）とも呼ばれ、クラウドサービスや保守契約のSLA（サービス品質の取り決め）で目標値として使われます。

計算方法と読み方

基本の計算式はシンプルです。

稼働率＝実際に正常稼働した時間 ÷ 稼働すべき時間

たとえば1か月を30日として、稼働すべき時間が720時間、そのうち停止が1時間あった場合、稼働率は 719 ÷ 720 で、およそ 0.9986 となります。

稼働率は小数で見るとどれも「ほぼ1」に見えるため、停止してよい時間に置き換えて考えるのが実務的です。

稼働率の目標	1か月（30日）あたりの停止許容時間の目安
0.99	約7時間12分
0.999	約43分
0.9999	約4分

「9」が一つ増えるごとに、許される停止時間は10分の1になります。それを守るための構成や監視、待機体制にかかる費用は大きく上がっていくのが一般的です。

何を「停止」と数えるか

稼働率の数字は、定義によって大きく変わります。次の点を決めておかないと、同じ障害でも「稼働率は目標どおり」「いや止まっていた」と認識が割れます。

計画メンテナンスを停止に含めるか：契約上は除外されることが多い項目です。
一部機能だけの停止をどう扱うか：ログインはできるが決済だけ止まった場合など。
極端に遅い状態を停止とみなすか：画面が開くまで長く待たされる状態は、利用者にとっては使えないのと同じです。
どこから測るか：サーバー内部の監視か、外部から利用者と同じ経路でアクセスする外形監視か。
測定の単位時間：1分単位で見るか、5分単位で見るか。

複数の仕組みを組み合わせたときの稼働率

システムが複数の部品に依存していると、全体の稼働率は個々の稼働率より下がります。直列につながった部品は「どれか一つ止まれば全体が止まる」ため、各部品の稼働率を掛け合わせたものが全体の目安になります。逆に同じ役割の部品を並列に置く冗長構成にすると、「両方同時に止まらない限り動く」ため全体の稼働率は上がります。外部APIや決済サービスなど、自社で制御できない依存先も、この掛け算に入ってくる点に注意が必要です。

実務での使い方・具体例

保守契約・SLAで使う

保守会社やクラウドサービスとの契約では、稼働率の目標値と、それを下回った場合の扱い（報告、改善策の提出、利用料の減額など）が定められることがあります。発注側としては、数字の高さよりも「停止の定義」と「測定方法」「下回ったときに何が起きるか」を確認することが重要です。

架空の例：会員サイトの運用報告

ある会員制サービスの運営会社（架空）では、毎月の運用報告で稼働率を確認しています。以前はサーバー内部の死活監視だけで計測していたため、データベースの不調で画面がエラーになっていた時間も「稼働中」と記録されていました。そこで外部から実際のログイン画面にアクセスする外形監視を追加し、「利用者が正常に使えたか」を基準に数えるように定義を改めました。数字は以前より下がりましたが、改善すべき箇所が見えるようになりました。

よくある誤解と注意点

高い稼働率＝良いシステム、とは限らない：業務時間外しか止まらないなら、実害はほとんどない場合もあります。止まった時間帯と影響を合わせて見ます。
稼働率だけでは障害の重さが分からない：短い停止が何度も起きるのと、長い停止が一度起きるのとでは、対策の方向が違います。障害の回数や復旧までの時間も記録しましょう。
過去の実績値と将来の保証値は別物：「これまで止まっていない」ことは、今後の稼働率を約束するものではありません。構成や運用体制の裏付けがあるかを確認します。
目標値をむやみに上げない：達成のための費用と、止まったときの損失を比べて決めるのが現実的です。

Otsumuに相談できること

稼働率の目標は、事業への影響と運用費用のバランスで決めるべきものです。Otsumuでは、停止の定義づくりや外形監視の導入、保守契約の見直しなど、運用中のシステムの信頼性を上げる取り組みを支援しています。詳しくは保守・運用のページをご覧ください。

今の運用報告の数字が実態を表しているか不安な場合も、30分の無料相談でお話を伺います。

執筆：Otsumu株式会社／編集日 2026.10.01

稼働率とは？意味・計算方法とSLAでの扱い方