1 概要
可用性とは、情報技術の領域において、利用者が必要とする時点で、システムやサービス、情報、機能が利用可能な状態にあることを示す概念である。障害や停止の発生を抑え、発生した場合でも停止状態を最小化し、所定の性能水準で継続的に提供することが目標とされる。
実務上は、設計段階での仕組み作りに加え、運用の手順、監視体制、復旧の手順、要員配置、変更管理などが組み合わさって達成される性質として扱われる。結果として可用性は、技術だけでなく組織的な運用能力とも結び付く評価対象となる。
1.1 定義
可用性は、ある対象（システム、サービス、機能、情報）が、要求された時間帯において利用できる割合、または利用可能な状態であることの度合いとして定義されることが多い。定量的な指標としては稼働率、障害時間、復旧時間などが用いられる。
また、可用性は「常に動いていること」に限定されず、利用者が期待する水準でサービスが提供されているかという観点も含む。たとえば、応答が著しく遅い、特定の機能が使えないといった事象は、利用可能性の低下として可用性の評価に反映される。
1.2 重要性
可用性は、業務継続や利用者満足に直結するため、組織にとって重要な品質特性となる。決済、予約、通信、医療情報、行政手続きなど、停止が損失や危険につながりやすい領域では、可用性を高めることが経営課題として扱われる。
さらに、可用性は信頼性や安全性とも関係し、長時間の停止は技術的な影響だけでなく、業務プロセス、契約上の義務、ブランドイメージにも波及する。したがって、費用対効果を踏まえつつ、目標を明確化し、達成手段を設計し続ける姿勢が求められる。
1.3 評価の観点
評価では、まず対象範囲と「利用可能」の定義を定める必要がある。利用可能性の判定が曖昧なままでは、指標の比較や改善の判断が困難になる。
次に、時間軸の扱いが重要となる。通常は、稼働率を時間帯別に見る、障害から復旧までの時間を測る、といった観点で評価する。加えて、障害の性質（ハード故障、ソフト不具合、設定ミス、人的操作、外部要因）ごとに原因分析を行い、再発防止のための改善につなげることが実務的な評価方法となる。
2 可用性を支える要素
可用性は複数の要素の組合せで実現される。代表的には、障害が起きにくい性質を高める信頼性、止まってもサービス継続を可能にする冗長化、問題を早期に見つけて影響を抑える監視、そして状況を維持する保守や復旧手順が挙げられる。
また、単一の対策では不十分な場合が多く、技術・運用・人の連携によって全体としての停止リスクを下げることが求められる。
2.1 信頼性
信頼性は、対象が故障せずに動作を継続する性質であり、可用性を底上げする基盤となる。部品やソフトウェアの品質、設計の妥当性、変更管理の厳格さ、性能劣化に対する方針などが信頼性に影響する。
可用性の観点では、単に故障率が低いことだけでなく、故障の種類に応じて影響範囲が小さくなることも重要である。たとえば、特定コンポーネントの劣化が全体停止につながらないよう分離する設計は、実効的な可用性の改善に寄与する。
2.2 冗長化
冗長化は、故障や障害が発生してもサービスを継続できるよう、構成要素や経路を重ねて持つ考え方である。目的は「単一障害点（SPOF）」を減らし、復旧に頼りすぎない状態を作ることにある。
冗長化はコストと複雑性を増やすため、重要度、影響度、許容停止時間を踏まえ、どこまで冗長にするかを設計する。
2.2.1 冗長構成
冗長構成では、サーバー、ネットワーク機器、電源、ストレージなどの要素を複数用意し、どれかが失われても残りで機能を維持するように設計する。単純な二重化だけでなく、ネットワーク経路の複数化、電力系統の分離、ストレージの多重化など、影響範囲に応じた構成が選択される。
また、冗長化の利点が活きるには、構成要素同士の相互依存を見直し、同一の障害要因が全系に波及しないよう考慮することが必要になる。たとえば同じ障害原因に同時に左右される配置は、冗長化の効果を弱める。
2.2.2 自動切り替え
自動切り替えは、障害が検出された際に、待機系へ切り替える処理を自動化する仕組みである。手動操作よりも迅速に対応でき、復旧にかかる時間を短縮しやすい。
ただし自動化は、切り替え条件の設計、データ整合性の確保、切替え後の安定化手順など、慎重な検討が欠かせない。誤検知による不要な切り替えが頻発すると、可用性の低下や利用者体験の劣化につながるため、判定基準の調整が重要となる。
2.3 監視
監視は、可用性向上のための早期発見と影響抑制を目的とする。障害の兆候は本格的な停止より先に現れることが多く、監視によって兆候を捉えることで、致命的な状態へ進む前に手を打てる可能性が高まる。
また、監視は単なるアラート発報に留まらず、障害解析を助け、復旧のための根拠情報を提供する役割も担う。
2.3.1 状態監視
状態監視では、稼働・応答・リソース使用量などの指標を継続的に確認する。CPUやメモリ、ディスク容量、応答時間、キュー長、接続数、トラフィックの急変などが対象となり得る。
加えて、サービスの健全性を示す観測点を定義し、単にプロセスが起動しているかではなく、利用者視点で機能しているかを判断する設計が求められる。たとえば、ログインや主要API呼び出しが失敗する場合は、稼働していても実質的な利用不能として扱う必要がある。
2.3.2 異常検知
異常検知は、通常状態からの逸脱を捉え、異常の可能性を早めに通知する仕組みである。閾値による検知に加え、統計的手法や時系列解析によって「いつもと違う」挙動を拾う手段も用いられる。
異常検知の実効性は、誤検知と見逃しのバランスに左右される。誤検知が多いと運用がアラート疲れに陥り、重要な信号が埋もれる。見逃しが多いと手遅れになりやすいため、運用の実データを用いたチューニングが重要になる。
2.4 保守
保守は、故障の予兆を扱い、システムを健全に保つための活動である。可用性を高めるためには、変更や更新を含むライフサイクル全体で、状態を安定させ続ける運用が不可欠となる。
また、保守は計画性と手順化が鍵であり、属人的な対応に依存すると停止や手戻りが増える傾向がある。
2.4.1 予防保守
予防保守は、故障や劣化を未然に防ぐ目的で行う活動である。部品の点検、容量の計画的増設、定期的なソフト更新、設定の見直し、性能のベースライン更新などが含まれる。
予防の対象を見極めるには、監視データや履歴に基づく原因傾向の分析が有効である。たとえば特定期間にエラー率が上がる場合、環境要因やパッチ関連の影響を検討し、再現性のある予防策へつなげることができる。
2.4.2 計画停止
計画停止は、利用者影響を最小化するために、停止やメンテナンスを事前に調整して実施する考え方である。作業ウィンドウの設定、関係者への告知、切り替え手順の準備などが必要になる。
計画停止は、緊急対応の頻度を下げ、結果として全体の可用性を押し上げる。重要度の高いサービスでは、メンテナンス方式を工夫し、冗長系の活用や段階的切替えにより影響を局所化することも検討される。
3 可用性の指標
可用性は測定と改善がセットで扱われる。指標は対象の性質を反映させる必要があり、測定単位、対象範囲、停止の定義を揃えることで、比較可能な評価が可能になる。
指標に基づき、目標値と達成状況をモニタし、改善策の効果を確認する運用が一般的である。
3.1 稼働率
稼働率は、対象が利用可能であった時間の割合を示す指標である。一定期間内における稼働時間を基礎として算出され、可用性の直感的な把握に役立つ。
ただし算出には「利用可能」の判定基準が必要である。プロセスの稼働をもって良しとするのか、主要機能が応答していることをもって良しとするのかで値が変わるため、運用設計と整合する形で定義することが重要になる。
3.2 障害時間
障害時間は、利用不能または性能劣化によりサービス提供が基準を満たさなかった時間の累計として扱われる。稼働率と対になる位置付けで、どれだけ時間を失ったかを示す。
障害時間を運用改善に活かすには、発生件数だけでなく、影響範囲やユーザ影響度、復旧の段階（検知、切替え、安定化）を切り分けて記録することが有効である。
3.3 復旧時間
復旧時間は、障害が発生してから利用可能な状態へ戻るまでの時間を指す。可用性改善の焦点が「止まらない」だけでなく「戻るのが早い」にある場合、復旧時間は特に重要な指標となる。
運用では、検知から切り替え、整合性確認、利用者復旧までの各工程を分けて測定すると、改善の優先順位を定めやすい。
3.3.1 平均復旧時間
平均復旧時間は、複数の障害事例に対する復旧時間の平均として求められることが多い。平均化により全体傾向が見えやすくなる一方、極端な事例に引きずられる可能性もあるため、分布や中央値も併せて確認する運用が望ましい。
平均値の改善には、手順の標準化、切替え自動化、必要情報（手順書、ログ、構成情報）の即時性向上などが効く。
3.3.2 平均故障間隔
平均故障間隔は、障害の発生頻度を表す指標であり、対象が故障してから次の故障までの平均時間として扱われる。これは信頼性の側面を反映し、結果として可用性にも影響する。
頻度の指標は、原因の多様性や季節性、変更イベントとの相関などを考慮して解釈する必要がある。特定の変更が引き金になっている場合は、回数の削減よりも再発要因の排除が優先される。
4 可用性の設計と運用
可用性の設計と運用は、相互に補完し合う。設計で冗長化や障害耐性を持たせ、運用で監視・保守・復旧の品質を高めることで、現実の停止リスクを下げる。
また、改善は一度限りではなく、障害履歴や監視データに基づく継続的な見直しが前提となる。
4.1 冗長化設計
冗長化設計では、どのコンポーネントを二重化し、どの経路を分離し、どのレベルで同期や整合性を確保するかを決める。重要度の高い機能から段階的に強化し、全体のコストと運用負荷を調整する考え方が採られる。
設計では「冗長であっても同時に落ちる」状態を避ける視点が必要である。たとえば同一の電源系統、同一故障の波及が起きる配線、同一の管理プレーン依存などは、二重化の効果を損なう可能性がある。
4.2 障害対策
障害対策は、障害が起きたときの影響を抑え、復旧までの時間短縮を実現するための取り組みである。対策は、障害をいち早く隔離することと、復旧手順の確実性を高めることの両面を含む。
また、障害は必ずしもシステム内部だけで発生するわけではないため、外部依存（通信回線、認証基盤、クラウド側サービスなど）も含めた整理が有効になる。
4.2.1 障害分離
障害分離は、問題が一箇所に留まり、全体停止へ波及するのを防ぐ設計である。論理的な分割（ゾーニング、テナント分離、キュー分離）や物理的な分離（ネットワーク経路や電源系統の分離）などが該当する。
分離の目的は復旧のしやすさにもある。影響範囲が限定されれば、復旧対象の特定が速くなり、利用者へ与える影響を抑えながら復旧を進めやすくなる。
4.2.2 障害回復
障害回復は、故障した状態から利用可能へ戻す一連の作業である。復旧手順の標準化、必要な情報の整備、ロールバックや再実行の基準、データ整合性の確認方法などをあらかじめ定めることが重要である。
回復の実効性は、手順書の品質と訓練に左右される。机上演習や復旧訓練を通じて、手戻りや判断遅延を減らし、現場が迷わず動ける状態を整えることが求められる。
4.3 バックアップ
バックアップは、障害や誤操作、データ破損に対する復旧手段を提供する。可用性の観点では「即時に復旧する」だけでなく、「致命的な損失を避ける」ことが復旧可能性を高める。
バックアップは保存先、復元手順、保存期間、復元目標（どれだけ古い時点まで戻せるか）などを設計して運用する必要がある。
4.3.1 定期保存
定期保存は、一定間隔でデータをバックアップし、復元可能な時点を確保する方法である。保存頻度はデータの更新速度と、許容できる損失量（許容データロス）に基づいて決められる。
保存処理の実装では、性能への影響やバックアップ中の整合性確保を考慮する必要がある。バックアップが成功しているかの検証（リストアテストや整合性確認）も運用の一部として扱うのが望ましい。
4.3.2 世代管理
世代管理は、複数のバックアップ世代を保持し、誤消去や段階的な破損に対して復元の選択肢を増やす考え方である。世代数や保持期間、削除ルールを明確にし、保管コストと復元可能性のバランスを取る。
世代管理が不適切だと、必要な時点のデータが失われたり、復旧の選択肢が狭まったりする。したがって、復元要求を想定した運用設計が重要となる。
4.4 災害対策
災害対策は、地震、火災、停電、通信障害、広域停電など、広範囲に影響する事象からサービスを守るための考え方である。単一拠点に依存すると、局所的な障害でも広域停止に発展するため、対策の設計が重要になる。
災害対策では、遠隔地にバックアップや稼働環境を確保し、必要な復旧手順を事前に整えることが中心となる。
4.4.1 遠隔地対策
遠隔地対策は、主要拠点とは異なる地理的場所に、データや稼働基盤の一部を用意する取り組みである。これにより、拠点障害が発生しても別拠点から復旧または継続提供が可能になる。
設計では、通信遅延、同期方式の違い、切替え時の整合性、運用責任分界などが論点になる。単に保管場所を離すだけでなく、実際に切り替えられることを検証する運用が求められる。
4.4.2 事業継続計画
事業継続計画は、災害や大規模障害が発生した際に、重要業務をどの順で、どの水準で継続し、必要な資源をどう確保するかを整理した計画である。可用性対策は技術だけでは完結せず、意思決定、連絡体制、代替要員、優先度設定などが不可欠となる。
計画には演習や見直しが含まれることが多い。状況が変化するほど計画の妥当性が下がるため、定期点検を通じて現実の運用に適合させることが重要である。
5 情報システムにおける可用性
情報システムでは、可用性は階層構造（サーバー、ネットワーク、データベース、外部サービス）ごとに設計される。上位層の対策も下位層の不具合に影響されるため、全体整合の視点が必要になる。
ここでは代表的な構成要素ごとの考え方を整理する。
5.1 サーバー
サーバーの可用性は、計算資源の停止やサービスプロセスの異常に直結するため、冗長化や健全性監視が重要となる。仮想化やコンテナ環境では、稼働インスタンスの複数配置やオートスケーリングによって吸収する設計が採用されることが多い。
また、OSやミドルウェアの更新、パッチ適用、構成変更の管理は停止時間に影響する。計画停止や段階的なロールアウトといった運用方式を整備することで、可用性の揺らぎを抑えられる。
5.2 ネットワーク
ネットワークは経路や名前解決、セキュリティ装置など多くの要素を含み、可用性に対する影響範囲が広い。回線の二重化、経路冗長化、負荷分散の適切な設定、DNSの設計などが対策として検討される。
監視では、疎通だけでなく遅延やパケット損失、帯域逼迫などの品質指標も扱う必要がある。単にリンクが上がっているだけでは利用可能性を保証できないため、利用者体験に近い観測が求められる。
5.3 データベース
データベースの可用性は、データ整合性と復旧時間が重要な焦点になる。レプリケーションによる冗長化、フェイルオーバー、読み取り専用や分離レイアウトなどが用いられる場合がある。
設計では、トランザクションの整合性、復旧後の整合状態、バックアップからの復元手順の確実性が課題となる。性能面の劣化も可用性に影響するため、監視指標やチューニングの継続が欠かせない。
5.4 クラウドサービス
クラウドサービスでは、基盤側の冗長化があらかじめ提供されることが多い一方で、利用者側の設計や運用の工夫が可用性を左右する。複数AZ（可用性ゾーン）やマルチリージョン対応、冗長な構成、障害時の切替え設計などが要点となる。
また、従量課金やオートスケーリングの設定、依存先サービスのSLA、ネットワーク構成（セキュリティグループやルーティング）も評価対象である。監視と復旧手順をクラウド特有の前提に合わせて整えることが実効性につながる。
6 可用性と関連概念
可用性は他の品質特性と相互に関係する。単独の目標として扱うと、コストや設計の整合が崩れることがあるため、関連概念とのバランスを意識した整理が重要になる。
ここでは、信頼性、保守性、性能、機密性・完全性との関係を概観する。
6.1 信頼性との関係
可用性と信頼性は近い概念として扱われるが、焦点が異なる。信頼性は故障の少なさに寄り、可用性は利用可能状態にある時間の割合に焦点がある。
そのため、信頼性が高くても復旧手順が遅いと可用性は十分に高まらない。一方で、信頼性が完全でなくても、復旧が速い、あるいは冗長構成で停止を局所化できれば、可用性は維持され得る。
6.2 保守性との関係
保守性は、システムが理解・修正・運用しやすい性質である。保守性が高いほど、原因調査や復旧に必要な時間を短縮でき、結果として可用性の改善に結び付く。
たとえば、ログが整理されている、構成管理が整備されている、変更が追跡できるといった特性は、障害時の判断遅延を減らす。保守性を軽視すると、手順の不確実さが増し、復旧が長引く要因になりうる。
6.3 性能との関係
性能は、応答時間やスループット、リソース使用量の観点で品質を示す指標である。性能が劣化すると、利用者はサービスを利用できない状態に近い体験を得ることがあり、可用性の低下として扱われる場合がある。
負荷の急増やリソース枯渇は停止に至らなくとも、タイムアウトやエラー増加として現れる。容量設計やスケーリング、ボトルネック監視は可用性を間接的に守る施策として位置付けられる。
6.4 機密性・完全性との関係
機密性（情報の秘匿性）と完全性（改ざんや破損に対する正しさ）はセキュリティに関する特性であり、可用性の設計と衝突することがある。たとえば、強固なアクセス制御や暗号化処理は性能負荷を増やし、過度な負荷は利用可能性に影響する場合がある。
一方で、可用性のために復旧や切替えを急ぐあまり、整合性確認を省略するとデータの正しさが損なわれる恐れがある。したがって、復旧手順にはセキュリティ要件と整合性確認を組み込み、運用の優先順位を明確化する必要がある。