可用性とは
可用性とは、システムが利用者の必要なときに、止まらずに使える状態を保てる度合いのことです。
言い換えると「いざ使おうとしたときに、ちゃんと動いているか」という性質です。英語では Availability（アベイラビリティ）と呼ばれます。情報セキュリティの三要素である機密性・完全性・可用性の一つとしても知られており、「情報が漏れない」「情報が正しい」と並んで「情報やサービスが使える」ことが守るべき価値とされています。
可用性を数値で表すときによく使われるのが稼働率です。ただし可用性は数値だけの話ではなく、止まりにくくする設計、止まったときに早く戻す運用、止まっても業務が続けられる代替手段まで含めた考え方です。
可用性を高める仕組み
可用性は「故障しにくくする」と「故障しても早く戻す」の二つの方向から高めます。主な手段を整理すると次のとおりです。
| 方向性 | 主な手段 | ねらい |
|---|---|---|
| 止まらない構成 | 冗長化、ロードバランサー、複数拠点への配置 | 一部が壊れても全体を動かし続ける |
| 負荷への備え | オートスケーリング、キャッシュ、CDN | アクセス集中で応答不能にならない |
| 早く気づく | 監視、アラート、外形監視 | 利用者より先に異常を検知する |
| 早く戻す | バックアップ、復旧手順書、ロールバック | 停止時間を短くする |
| 計画停止を減らす | 無停止デプロイ、メンテナンス設計 | 更新作業による停止をなくす |
どの手段も費用と手間がかかります。可用性は「上げられるだけ上げる」ものではなく、事業として許容できる停止の範囲を決め、それに見合った対策を選ぶものです。
単一障害点をなくす
可用性設計の基本は、そこが止まると全体が止まる箇所、いわゆる単一障害点を洗い出すことです。サーバーが1台しかない、データベースが1つしかない、特定の担当者しか復旧方法を知らない、といった箇所がそれにあたります。技術的な構成だけでなく、人や手順にも単一障害点は潜んでいます。
洗い出しの際は、システム構成図を見ながら「この箱が止まったら何が起きるか」を一つずつ確かめていくと漏れが減ります。外部の決済サービスやメール配信サービス、ドメインの更新手続きや証明書の期限切れなど、自社のサーバー以外の要素も対象に含めます。すべてをなくす必要はなく、影響が大きく、対策の費用が見合うものから順に手を打つのが現実的です。
実務での使い方・具体例
要件の決め方
発注や設計の場面では、次の順番で可用性の要件を決めると話が具体的になります。
- 止まったときに何が起きるかを書き出す（売上が止まる、現場の作業が止まる、問い合わせが増えるなど）
- 業務上、どれくらいの停止なら許容できるかを時間帯ごとに考える
- 計画メンテナンスで止めてよい時間帯があるかを決める
- 許容範囲に収めるための構成と運用の案を、費用とあわせて比較する
- 合意した内容を保守契約やSLAなどの取り決めに反映する
架空の例：予約サイトと社内の集計ツール
ある飲食チェーン（架空）では、顧客向けの予約サイトと、本部が使う売上集計ツールを運用しています。予約サイトは夜間も週末も使われ、止まれば予約の取りこぼしに直結するため、サーバーを複数台構成にし、外形監視で異常を即座に検知する体制をとりました。一方、集計ツールは平日の日中に本部が使うだけなので、1台構成のまま、毎日のバックアップと復旧手順書を整える対応にとどめました。同じ会社の中でも、システムごとに求める可用性を分けることで費用を抑えています。
よくある誤解と注意点
- 「クラウドなら止まらない」わけではない：クラウド事業者側の障害も起こりえます。どの範囲が事業者の責任で、どこからが自社の設計の責任かを確認しておきましょう。
- 可用性とデータ保全は別の話：止まらない構成にしても、誤操作でデータを消せば元に戻りません。バックアップや復旧の目標は別に決める必要があります。
- 過剰な要件は費用を押し上げる：「絶対に止めない」を求めると、構成も運用体制も大がかりになります。止まったときの影響と費用を並べて判断します。
- 計画停止も利用者から見れば停止：メンテナンスの告知方法や時間帯も可用性設計の一部です。
関連用語
- 稼働率：可用性を数値で表す代表的な指標
- 冗長化：機器や経路を複数用意し、一部の故障でも止まらないようにする手法
- RPO・RTO（目標復旧時点・目標復旧時間）：どの時点まで、どれくらいの時間で戻すかの目標
- DR（ディザスタリカバリ）：災害などの大規模障害からの復旧の備え
- SRE（サイトリライアビリティエンジニアリング）：信頼性を工学的に管理する運用の考え方
契約面の取り決めはシステム保守契約に含めるべき内容で詳しく解説しています。
Otsumuに相談できること
可用性の要件は、事業への影響と費用を天秤にかけて決めるものです。Otsumuでは、止まったときの業務影響の整理から、構成の見直し、監視や復旧手順の整備までを、必要な範囲に絞って支援します。運用中のシステムについては保守・運用、クラウドへの移行を伴う場合はクラウド移行のページもご覧ください。
「今の構成でどこが弱いのか知りたい」という段階でも構いません。30分の無料相談で状況をお聞かせください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01