可用性とは？CIA3要素・稼働率・RPO・RTO・冗長化・クラウドでの実践を徹底解説

「システムが止まったら売上が止まる」「サービス停止中に競合他社に顧客が流れた」「復旧に時間がかかり、取引先からの信頼を失った」——こうした経営上の痛手を防ぐために欠かせない概念が「可用性（Availability）」です。

可用性（Availability）とは、システム・サービス・データが必要なときに正常に使用できる状態を維持できるか、という能力・性質のことです。情報セキュリティの3大要素「CIA」のひとつに位置づけられ、機密性（Confidentiality）・完全性（Integrity）と並んで、組織の情報資産を守る根幹です。

可用性とは？

可用性（Availability）とは、「使いたいときに使える」という状態を維持し続けられるシステムの能力です。どれだけ機密性が高く、データが正確であっても、必要なときにアクセスできなければ業務は止まってしまいます。

「コンビニの自動ドア」のたとえ
可用性は「24時間365日、必要なときに開くコンビニの自動ドア」のようなものです。故障して開かない状態が続くと、お客様は別の店舗へ行ってしまいます。一方で、誰でも自由に入れるだけでは防犯上の問題が生じます。可用性とは、確実に・素早く・安定して使える状態を維持しながら、セキュリティとのバランスを取る考え方です。

可用性が重要な理由

業務継続への直結：システム停止は業務停止につながる場合がある
売上・機会損失：ECサイト・金融システムなどでは、停止時間が長引くほど売上損失・機会損失・問い合わせ対応コストが増大する
信頼・ブランド毀損：システム障害が長引くと、顧客・取引先からの信頼低下につながる
法令・ガイドライン対応：重要インフラ・金融・医療などでは、法令、監督指針、業界ガイドライン、委託契約などで業務継続や復旧体制の整備が求められる場合がある
セキュリティ攻撃への対応：DDoS攻撃やランサムウェアは、可用性を直接破壊する攻撃手法である

CIA3要素における可用性の位置づけ

情報セキュリティでは、機密性（Confidentiality）・完全性（Integrity）・可用性（Availability）の3つを「CIA」と呼びます。可用性は、情報やシステムを必要なときに使える状態に保つための重要な要素です。

要素	英語	意味	脅威の例
機密性（C）	Confidentiality	許可された人だけが情報にアクセスできる	情報漏洩・不正アクセス・盗聴
完全性（I）	Integrity	情報が正確で改ざんされていない状態を維持する	データ改ざん・マルウェアによる破壊・誤更新
可用性（A）	Availability	必要なときにシステム・データが使える状態を維持する	DDoS攻撃・ランサムウェア・システム障害・自然災害

情報セキュリティのCIA

2024.9.3

情報セキュリティのCIAとは、情報の「機密性（Confidentiality）」「完全性（Integrity）」「可用性（Availability）」の3つの基本原則を指し、情報資産を安全に管理・保護するための重要な枠組みです。機密

可用性を脅かす主な要因

DDoS攻撃：大量のトラフィックでサーバーやネットワークを停止・遅延させる
ランサムウェア：ファイルやシステムを暗号化し、業務システムを使用不能にする
ハードウェア障害：サーバー・ストレージ・ネットワーク機器などの故障
ソフトウェア障害：バグ・設定ミス・パッチ適用後の不具合
自然災害：地震・洪水・停電などによるデータセンターや拠点の停止
ヒューマンエラー：誤操作・誤削除・設定変更ミスによるサービス停止

稼働率とSLA：「9の数」で読む可用性

稼働率とは

稼働率（Uptime Rate）とは、ある期間においてシステムが正常に動作していた時間の割合です。

稼働率（%）＝稼働時間 ÷ 総時間 × 100

稼働率が高いほど、利用者がシステムやサービスを使えない時間が短いことを意味します。ただし、計算対象にメンテナンス時間を含めるか、どの障害を停止時間として扱うかは、契約やサービス定義によって異なります。

「9の数」で表す稼働率の水準

可用性の水準は「9の数（Nines）」で表されることが多く、9が多いほど高い可用性を意味します。

稼働率	呼び方	年間停止時間（目安）	月間停止時間（目安）
99%	ツーナイン	約87.6時間	約7.2時間
99.9%	スリーナイン	約8.76時間	約43.8分
99.95%	—	約4.38時間	約21.9分
99.99%	フォーナイン	約52.6分	約4.4分
99.999%	ファイブナイン	約5.26分	約26.3秒

SLA（サービス水準合意）での可用性
SLA（Service Level Agreement）は、サービス提供者と利用者の間で合意するサービス水準の契約です。クラウドサービスのSLAには可用性の保証値が記載されることがあります。ただし、SLAはサービス、構成、リージョン、可用性ゾーンの利用有無、インスタンス数、障害の定義、除外条件によって異なります。実際の設計では、各クラウド事業者の最新SLAとアーキテクチャ条件を確認することが重要です。

可用性を高める主な技術

冗長化（Redundancy）

冗長化とは、同じ役割を持つコンポーネントを複数用意し、1つが障害を起こしても別のものが機能し続けるようにする設計です。

サーバー冗長化：複数台のサーバーで同じサービスを提供する
ストレージ冗長化：複数のディスクやストレージにデータを分散・複製する
ネットワーク冗長化：複数の通信回線・ルーター・スイッチを用意する
電源冗長化：UPS（無停電電源装置）、自家発電機、複数系統の電源で停電に備える

負荷分散（ロードバランシング）

負荷分散とは、複数のサーバーにリクエストを分散して処理する仕組みです。特定のサーバーに負荷が集中することを防ぎ、1台に障害が発生した場合でも他のサーバーで処理を継続しやすくなります。

バックアップ・データ保護

バックアップは、障害・誤削除・ランサムウェア感染時にデータを復旧するための基本対策です。バックアップを取得するだけでなく、実際に復元できるかを定期的に確認することが重要です。

3-2-1ルール：3つのコピー、2種類の異なるメディア、1つはオフサイトに保存する
オフラインバックアップ：ランサムウェアに到達されにくいように、ネットワークから切り離したバックアップを保持する
イモータブルバックアップ：一定期間、削除・改ざんできないバックアップを保持する

フェイルオーバー（自動切り替え）

フェイルオーバーとは、主系システムに障害が発生した際に、自動的に副系システムへ切り替える仕組みです。自動化によってダウンタイムを短縮し、復旧作業の属人化を防ぎやすくなります。

CDN（コンテンツデリバリーネットワーク）

CDNは、世界各地のエッジサーバーにコンテンツをキャッシュして配信する仕組みです。特定のサーバーやリージョンに負荷が集中することを避け、アクセス集中や一部障害時でもサービスを継続しやすくします。

DDoS対策

DDoS攻撃は、大量の通信を送りつけてサーバーやネットワークを停止・遅延させる攻撃です。DDoS緩和サービスやWAF、CDN、レート制限、ネットワーク監視などを組み合わせることで、可用性を守りやすくなります。

RPO・RTOとは：可用性の目標値

可用性を考える際は、「どのくらい早く復旧するか」「どの時点のデータまで戻せるか」を事前に決めておくことが重要です。その代表的な指標がRTOとRPOです。

RTO（Recovery Time Objective：目標復旧時間）

RTOとは、障害発生からシステムを復旧させるまでの許容時間の目標値です。「システムが止まってから何時間以内に復旧させなければならないか」を定めます。

たとえば、RTOが4時間であれば、障害発生から4時間以内にシステムを復旧させることが目標です。

RPO（Recovery Point Objective：目標復旧時点）

RPOとは、障害発生時に、どの時点のデータまで損失を許容するかの目標値です。「最大何時間分のデータ損失まで許容できるか」を定めます。

たとえば、RPOが1時間であれば、最大1時間前のバックアップからの復旧を許容する設計になります。

指標	問いかけ	短い場合	長い場合
RTO	「何時間以内に復旧する？」	停止時間が短い。コストや設計難度は高くなりやすい	許容ダウンタイムが長い
RPO	「何時間前のデータまで戻れる？」	データ損失が少ない。バックアップ頻度や複製コストは高くなりやすい	データ損失が多くなる可能性がある

可用性と機密性のトレードオフ

可用性と機密性は、しばしばトレードオフの関係になります。安全性を高めるための制限が、緊急時のアクセスや復旧を難しくすることがあるためです。

トレードオフの具体例

アクセス制御の強化（機密性↑）→ 可用性↓：多要素認証、VPN、IPアドレス制限を強化すると、障害時の緊急アクセスが難しくなる場合がある
暗号化の強化（機密性↑）→ 可用性↓：鍵を紛失すると、暗号化データにアクセスできなくなる
可用性の向上（可用性↑）→ 機密性↓：緊急アクセス用の例外ルールやマスター権限を設けると、不正利用リスクが高まる

組織は、ビジネス要件・リスク評価・監査要件に基づいて、可用性と機密性のバランスを設計する必要があります。

クラウドでの可用性：ゾーン冗長・リージョン冗長

アベイラビリティゾーン（AZ）

AWS・Azure・Google Cloudなどの主要クラウドプロバイダーは、同一リージョン内に物理的に分離されたデータセンター群を複数用意しています。これらは、AWSではアベイラビリティゾーン、Azureでは可用性ゾーン、Google Cloudではゾーンと呼ばれます。

ゾーンをまたいだ冗長化により、1つのデータセンターやゾーンで障害が発生しても、別のゾーンでサービスを継続しやすくなります。

マルチリージョン構成

マルチリージョン構成は、地理的に離れた複数のリージョンにシステムを展開し、自然災害・リージョン全体の障害・大規模ネットワーク障害に備える設計です。

より高い可用性を実現できますが、データレプリケーション、ネットワーク遅延、整合性、運用コスト、障害時の切り替え手順などを慎重に設計する必要があります。

主要クラウドの可用性SLA

クラウドのSLAは、サービスや構成条件によって変わります。以下は代表的な目安です。

クラウドサービス	稼働率SLA（目安）	主な条件
AWS EC2	99.99%	同一リージョン内の複数AZに配置するなど、条件を満たす構成
Azure Virtual Machines	99.99%	2つ以上のインスタンスを2つ以上の可用性ゾーンに配置する構成
Google Cloud Compute Engine	99.99%	複数ゾーン構成
AWS RDS（Multi-AZ）	99.95%など	Multi-AZ構成など、サービス種別・構成により異なる

クラウドSLAの注意点
クラウドのSLAは、クラウド事業者が提供する基盤部分の可用性を示すものであり、アプリケーションのバグ、設定ミス、データ削除、認証障害、バックアップ不備、ユーザー側の設計ミスによる停止まで自動的に保証するものではありません。高可用性を実現するには、利用者側のアーキテクチャ設計と運用も重要です。

企業での可用性向上の実践方法

業務影響分析（BIA）の実施

業務影響分析（BIA：Business Impact Analysis）とは、どのシステム・データ・業務が止まると、どの程度の影響が出るかを評価する作業です。売上、顧客影響、法令対応、取引先影響、復旧優先度を整理し、重要度に応じてRTO・RPOを設定します。

事業継続計画（BCP）・災害復旧計画（DRP）の策定

BCP（Business Continuity Plan）は、災害や障害が発生しても重要業務を継続するための計画です。DRP（Disaster Recovery Plan）は、システムやデータを復旧するための具体的な手順です。

大規模障害・自然災害・ランサムウェア感染時の復旧手順、連絡体制、意思決定者、委託先との役割分担を事前に文書化し、定期的に訓練することが重要です。

定期的な可用性テスト

障害訓練（ゲームデー）：意図的に障害シナリオを設定し、システムと運用体制の回復力を確認する
バックアップからの復旧テスト：実際にバックアップから復旧し、RTO・RPOを満たせるか確認する
フェイルオーバーテスト：主系から副系への切り替えが正常に機能するか確認する
連絡訓練：障害発生時に関係者へ迅速に連絡できるか確認する

監視・アラートの整備

システム・サービスの稼働状態をリアルタイムで監視し、障害の早期検知と自動通知体制を整えます。サーバー監視、アプリケーション監視、ネットワーク監視、ログ監視、外形監視を組み合わせることで、障害の兆候を早期に把握できます。

可用性に関連する被害・注意事例2選

事例1：DynへのDDoS攻撃による大規模サービス影響

可用性を脅かす代表的な攻撃がDDoS攻撃です。2016年、米国のDNSサービス事業者Dynが大規模なDDoS攻撃を受け、同社のDNSサービスを利用していた複数のWebサービスに接続しづらい状態が発生しました。

サイバーセキュリティ.comの記事では、Dynに対する継続的なDDoS攻撃により、Twitter、Spotify、Amazon、Netflixなど、多くのユーザーが利用するサービスに影響が出たと紹介しています。DNSのような基盤サービスが停止すると、個別のWebサイトやアプリケーションが正常でも、利用者がサービスに到達できなくなる可能性があります。

この事例は、可用性を守るうえで、自社サーバーだけでなく、DNS、CDN、クラウド、回線、外部SaaSなど、依存先を含めた可用性設計が必要であることを示しています。

米国最大手ネットインフラ支援Dyn（ダイン）、継続的なDDoS攻撃によりサービスが一時停止

2016.10.22

2016年10月21日、米国内において、Twitter（ツイッター）やAmazon（アマゾン）など多くのネットサービスに、サイト接続が出来ないなどのシステム上のトラブルが発生し、サービスが一時停止に陥る事象が相次いで起こりました。ト

DDos攻撃の具体例と対策について

2015.5.8

前回、サービス妨害攻撃で攻撃する側と攻撃される側が1対10、1対100といった状況になることをDDoS攻撃（ディードス攻撃）と呼ぶ定義をご紹介しました。引き続き、今回は、DDoS攻撃に対して具体的な事例と対策を考えていきたいと思います。

事例2：大阪急性期・総合医療センターのランサムウェア被害

ランサムウェアは、機密性だけでなく可用性を直接破壊する攻撃です。2022年10月31日、大阪急性期・総合医療センターは、ランサムウェアと思われる攻撃により電子カルテシステムに障害が発生し、緊急以外の手術や外来診療の一時停止など、通常診療ができない状況になったと公表しました。

同センターはその後、2022年12月12日に電子カルテ等の基幹システムの運用を再開し、2023年1月11日に診療体制の全面復旧を公表しています。医療機関において電子カルテや部門システムが使えなくなることは、診療継続や患者受け入れに大きな影響を与えます。

この事例は、バックアップの取得だけでなく、バックアップから実際に復旧できるかを確認する復旧訓練、ネットワーク分離、委託先を含めたセキュリティ管理、IT-BCPの整備が重要であることを示しています。

参考：ランサムウェア感染時の対応｜サイバーセキュリティ.com

よくある質問（FAQ）

Q. 可用性・機密性・完全性（CIA）のうち最も重要なのはどれ？

どれが最も重要かは、システムや業務の性質によって異なります。金融決済システムでは可用性と完全性が重視されやすく、医療記録では機密性と完全性が特に重要です。緊急通報システムや医療機関の基幹システムでは、可用性が人命や安全に関わることもあります。

そのため、組織はリスクアセスメントや業務影響分析に基づき、システムごとに重視すべき要素を評価する必要があります。

Q. 稼働率99.9%と99.99%では実際にどれだけ違う？

年間の停止時間で比較すると大きな差があります。99.9%（スリーナイン）は年間約8.76時間の停止が目安ですが、99.99%（フォーナイン）は年間約52.6分です。

ただし、稼働率を高めるほど、冗長化、監視、運用体制、障害訓練、クラウド構成などに必要なコストも増えやすくなります。ビジネス上どこまでの停止時間を許容できるかを明確にしたうえで、可用性目標を設定することが重要です。

Q. RTOとRPOはどのように設定すればいい？

まず業務影響分析（BIA）を実施し、各システムが停止した場合の業務影響、売上損失、顧客影響、法令・契約上の影響を評価します。影響が大きいシステムほど、RTO・RPOを短く設定します。

たとえば、決済システムはRTO1時間・RPO15分、社内ポータルはRTO24時間・RPO24時間など、業務重要度に応じて差をつけます。設定したRTO・RPOを実際に達成できるかは、定期的な復旧テストで確認する必要があります。

Q. 高可用性（HA）と災害復旧（DR）はどう違う？

高可用性（HA：High Availability）は、サーバー1台の故障やネットワーク瞬断など、比較的限定的な障害に対して短いダウンタイムでサービスを継続する設計です。冗長化、自動フェイルオーバー、負荷分散などが中心です。

災害復旧（DR：Disaster Recovery）は、地震・洪水・データセンター全体の停止・広域障害など、大規模な障害からの復旧を扱います。別拠点へのデータ複製、復旧手順書、訓練、代替業務手順などが重要になります。

企業は、HAとDRの両方を組み合わせて、日常的な障害と大規模災害の両方に備える必要があります。

Q. クラウドを使えば可用性は自動的に担保される？

いいえ。クラウドプロバイダーが提供するインフラの可用性はSLAで示されることがありますが、その上で動くアプリケーション、データベース、認証、バックアップ、ネットワーク設定の可用性は、利用者側の設計と運用に大きく依存します。

シングルAZ構成で運用している場合、単一ゾーン障害でサービスが停止する可能性があります。クラウドで高可用性を実現するには、マルチAZ構成、自動スケーリング、バックアップ、監視、フェイルオーバー、権限管理、復旧手順の整備が必要です。

まとめ

可用性（Availability）とは、システム・サービス・データが必要なときに正常に使用できる状態を維持する能力です。情報セキュリティの3大要素CIA（機密性・完全性・可用性）のひとつとして、組織が守るべき重要な要素です。

稼働率は「9の数（Nines）」で表され、99.9%なら年間停止時間は約8.76時間、99.99%なら約52.6分が目安です。ただし、SLAはクラウドサービスや構成条件によって異なるため、実際の設計では最新のSLAと条件を確認する必要があります。

可用性を高めるには、冗長化、負荷分散、バックアップ、フェイルオーバー、CDN、DDoS対策、監視・アラートを組み合わせることが重要です。また、RTO・RPOを定義し、業務影響分析（BIA）やBCP・DRPに基づいて復旧体制を整える必要があります。

DDoS攻撃やランサムウェアは、可用性を直接破壊する代表的な脅威です。自社システムだけでなく、DNS、クラウド、回線、委託先、バックアップ環境など、依存先を含めた可用性設計を行い、定期的な復旧テストによって実効性を確認しましょう。