現代の企業活動において、システム障害やクラウドサービスのトラブル、サイバー攻撃など、システムが止まる、情報にアクセスできないといった状態は、もはや経営リスクそのものです。
情報セキュリティの3要素の一つである可用性（Availability）は、必要なときに、必要な情報資産にアクセスできる状態を維持することを意味します。これは、セキュリティ対策と聞いて多くの人がまず思い浮かべる情報漏えいの防止（機密性）や改ざんの防止（完全性）とは異なり、業務継続や業務効率に直結する、業務を止めないための土台となる考え方です。
本記事では、可用性の基本的な定義から、実際に可用性が損なわれた事例、そしてそれを防ぐための実践的な対策までを分かりやすく解説します。
可用性とは？
可用性（Availability）とは、必要なときに必要な情報やシステムを使える状態に保つことを意味します。 例えば、業務システムが落ちてアクセスできなくなったり、ファイルサーバが故障して資料が取り出せなくなったりすれば、いくら情報が安全に保たれていても意味がありません。可用性は、「情報が存在することではなく、利用できることに価値を置いた概念です。
この可用性は、情報セキュリティの3要素（CIA）のうちのひとつとして定義されています。
| 情報セキュリティの3要素 | 意味 |
| 機密性（Confidentiality） | 許可された人だけが情報にアクセスできること |
| 完全性（Integrity） | 情報が正確で改ざんされていないこと |
| 可用性（Availability） | 必要なときに情報やシステムが利用できること |
これら3つの要素は、どれが欠けても業務に深刻な影響を及ぼします。
信頼性・継続性との違い
可用性に近い概念として、信頼性（Reliability）や継続性（Continuity）という言葉もよく使われます。これらは似ているようで、焦点が異なります。
| 用語 | 主な意味 |
| 可用性 | 必要なときに使える状態であること |
| 信頼性 | エラーや障害が少なく、安定して動作すること |
| 継続性 | 災害などの重大インシデント発生時も、業務を続けられる仕組み |
可用性は、今まさに使えることに重点を置いたセキュリティの考え方であり、信頼性や継続性は可用性を支える別の観点として捉えることができます。
では、もし可用性が損なわれてしまったら、業務にはどのような影響があるのでしょうか。
可用性喪失のリスク
情報やシステムにアクセスできない状態、つまり可用性が損なわれた状態は、単なる一時的な不便さにとどまらず、組織にとって深刻な損失を引き起こすリスクをはらんでいます。
可用性の低下や喪失が引き起こすリスクには、次のようなものがあります。
売上の損失
オンラインショップや予約システムなど、売上に直結するサービスが停止すると、その間の注文や契約機会を丸ごと失うことになります。
特にセール期間中や繁忙期での障害は、通常の何倍もの機会損失となり、事業全体の業績に影響する場合もあります。
さらに、停止中に他社サービスへ顧客が流れてしまえば、一時的な損失にとどまらず、継続的な顧客離れによる売上の低下にもつながりかねません。
顧客の信用喪失
サービスの提供停止やシステム障害が発生すると、顧客の業務や生活に直接的な影響を与え、顧客満足度の低下やクレームの増加を招きます。
とくに、サービス停止に対する原因説明や対応の不備がある場合は、企業の信頼を一気に失うことになります。
また、復旧後も「また止まるのではないか」という不安感が残り、ブランドイメージの毀損や口コミによる風評被害につながることもあります。
SLA違反・契約違反
法人向けのサービスでは、SLA（サービスレベル合意）に基づき、可用性や応答時間、復旧時間などが数値で定められていることが一般的です。
こうした条件を満たせなかった場合、違約金や返金対応、契約の打ち切りなどのリスクが発生します。
特に、インフラや基幹業務を支えるサービスでSLA違反が起これば、顧客の事業に重大な影響を及ぼし、法的責任を問われることもあります。
人命への影響
医療、交通、エネルギーなどの社会インフラでは、可用性の低下が人命に直結する深刻な事態を引き起こす可能性があります。
例えば、電子カルテシステムの停止により患者の処方履歴が確認できなければ、適切な診療が行えず命に関わる判断ミスが起こりえます。
また、交通システムや電力制御のようなリアルタイム性の高い分野では、わずかな停止時間でも事故や大規模障害につながることがあり、社会的影響は計り知れません。
このように、可用性の喪失はただのダウンタイムでは済まされず、事業継続や社会的責任、そして経営そのものにまで影響を与える重大なリスクであることを理解しておく必要があります。
可用性を脅かす主な原因
こうした可用性のリスクは、特別な状況でだけ起こるわけではありません。
多くの場合、日常的なシステム運用や、外部環境の変化、そして人的な不備など、ありふれた要因によって引き起こされます。
システム障害
ハードウェアやソフトウェアの故障によって発生するシステム障害は、最も基本的かつ頻度の高い可用性リスクです。
ストレージ装置の故障でファイルサーバが停止したり、バグを含んだソフトウェア更新によって業務システムが起動しなくなったりするケースは、業界を問わず発生しています。
また、ライセンスの期限切れや証明書の失効など、見落とされがちな要因によって、正常に稼働していたシステムが突然停止する事態も起こります。
技術的な問題に見えますが、その背景にはしばしば運用体制や点検フローの不備が潜んでおり、単なる技術トラブルとして片付けるべきではありません。
サイバー攻撃
外部からのサイバー攻撃によって、可用性が直接的に損なわれるリスクも増加しています。
典型的なのがDDoS（分散型サービス妨害）攻撃です。大量のトラフィックを送りつけ、サーバやネットワーク機器を過負荷状態にすることで、サービスの利用を困難にします。
さらに深刻なのが、ランサムウェア感染によってシステムが暗号化され、データや業務アプリケーションにアクセスできなくなるケースです。
このような攻撃は、単に情報を盗むのではなく業務を止めることを狙った破壊的な手口であり、対応が後手に回ると甚大な被害をもたらします。
人為的ミス（ヒューマンエラー）
システムトラブルの中でも見過ごされがちなのが、人間の操作ミスや判断ミスによる障害です。
ネットワーク設定の誤りによる通信断や、業務データの誤削除、サーバ設定の変更ミスなど、日常的な業務の中で発生する小さなミスが、大きな障害へと発展するケースは珍しくありません。
とくに作業手順が属人化していたり、レビューや承認のプロセスが不十分であったりすると、人的ミスのリスクは高まります。
そのため、業務マニュアルの整備やダブルチェック体制、操作教育の実施など、仕組みによる予防が重要です。
自然災害・インフラ障害
地震・火災・落雷・台風などの自然災害、あるいは停電・通信障害といったインフラトラブルも、可用性を一瞬で奪う脅威となります。
オンプレミス環境では、災害によってサーバルームやネットワーク機器が損傷すれば、物理的に業務継続が不可能になることもあります。
一方で、クラウドを利用していてもインターネットに接続できなければ何もできないという点では、可用性の依存先が変わるだけでリスク自体が消えるわけではありません。
こうしたインフラ系のリスクには、冗長構成・遠隔バックアップ・代替拠点の整備など、BCP（事業継続計画）を含めた備えが不可欠です。
このように、可用性を脅かす原因は多岐にわたりますが、いずれも「まさか」で済まされるものではありません。
組織の規模や業種にかかわらず、あらゆる企業にとって現実的なリスクであることを認識し、平時からの対策が求められます。
可用性を損なった事例
ここでは、実際に可用性が損なわれたことで重大な影響が生じた事例を紹介します。
セキュリティソフト更新による世界規模の業務停止
2024年7月、米CrowdStrike(クラウドストライク)が配布したWindows端末向けアップデートに不具合があり、全世界で約850万台のPCがクラッシュ（BSOD）・起動不能となる障害が発生しました。 サイバー攻撃ではなくソフトウェアのロジックエラーによるもので、影響は企業・自治体・医療機関・航空会社など多岐にわたり、911通報システムや主要航空会社の運航が一時停止、予約キャンセルや手術延期なども発生しました。
この障害は、セキュリティソフトという守るための仕組みが、逆に全体の可用性を脅かす単一障害点（SPOF）となるリスクを浮き彫りにしました。 また、OSカーネルレベルで動作するソフトウェアの更新が全体に波及する構造的リスク、そして依存するエコシステム全体の連鎖的障害の可能性も示しています。
ランサムウェア感染が燃料インフラを停止
米国東海岸の燃料供給の約45%を担うColonial Pipeline社は、2021年5月にランサムウェア「DarkSide」に感染し、ITシステムの一部が暗号化されました。結果として、全パイプラインの稼働が一時停止することになり、身代金440万ドル（約4億8000万円）を支払うまでに至りました。
ガソリン価格の高騰、給油所の閉鎖、米政府の緊急対応など、サイバー攻撃が社会インフラの可用性に与える影響が広範囲に及びました。
この事例は、ITシステムの可用性喪失が、物理インフラの停止にまで波及することを示しています。また、侵入経路がレガシーVPN×多要素認証なしという基本的な対策の欠如だったことも、重要な教訓となりました。
Log4Shell脆弱性による長期的な可用性リスク
2021年12月、Javaのログ出力ライブラリLog4jに深刻な脆弱性「Log4Shell（CVE-2021-44228）」が報告され、世界中のシステムに影響を与えました。
この脆弱性はリモートから任意のコードが実行可能であり、各種ランサムウェアへの感染や、ボットネット化によるシステム停止が報告されました。
問題は、Log4jがサプライチェーンの深層に広く浸透していたことにあり、パッチが出た後も、影響範囲の特定と対処に長期間を要しました。
この事例は、脆弱性そのものよりも見えない場所に存在することが最大の可用性リスクになりうることを示しています。オープンソースコンポーネント管理の不備が、広範で長期的な業務停止につながる可能性があるという教訓です。
これらの事例に共通しているのは、可用性の喪失が一部の障害にとどまらず、社会全体・産業全体へと波及しうる時代になっているということです。
可用性を守るには、技術だけでなく、構造、関係性、備えの観点から対策を講じることが不可欠です。
可用性を維持するための対策
可用性は、技術だけで守るものと思われがちですが、実際には設計・組織体制・外部との関係性・復旧の備えなど、複数の観点から支えられています。
ここでは、技術、構造、関係性、備えという4つの視点で、可用性を維持するための主な対策を紹介します。
技術の観点：止まらない設計と検知の仕組み
可用性を維持するうえで、まず押さえておきたいのが技術的な仕組みによる備えです。技術の観点では、主に冗長化とフェイルオーバー構成の導入、常時監視とアラート体制の整備、脆弱性管理とパッチ適用の仕組みという3つが重要な柱になります。
まず一つ目は、冗長化とフェイルオーバー構成です。これは、サーバやネットワーク、ストレージなどのインフラを複数系統で構成し、一方に障害が発生してももう一方に自動で切り替えることで、システム全体の停止を防ぐ設計です。たとえば、Webサーバをクラスタ構成にしたり、クラウドでマルチAZ（可用性ゾーン）を活用することで、単一障害点のリスクを軽減できます。
二つ目は、常時監視とアラート体制の整備です。障害や過負荷の兆候を早期に検知し、迅速に対応するには、システム全体の状態を常にモニタリングする仕組みが欠かせません。CPUやメモリ使用率、ネットワーク通信、アプリケーションの稼働状況などを監視対象とし、しきい値を超えた際にはアラートが発報されるよう設定することで、トラブルの深刻化を未然に防ぐことができます。
三つ目は、脆弱性管理とパッチ適用の体制整備です。近年ではLog4Shellのように、基盤ソフトウェアやライブラリに含まれる脆弱性が深刻な可用性リスクにつながるケースが増えています。これに対処するには、自社で利用しているソフトウェアやオープンソースコンポーネントを把握し（SBOM：ソフトウェア部品表の作成）、公開された脆弱性情報に基づいて迅速にパッチ適用を進める体制が必要不可欠です。
このように、技術的な対策は単なるシステム強化にとどまらず、障害を未然に防ぎ、起きた際の影響を最小限に抑える設計と検知の仕組みそのものです。これらをしっかりと整備しておくことが、可用性を支える第一歩となります。
構造の観点：属人性をなくし、ミスを許容しない体制づくり
可用性を脅かす原因の多くは、技術的なトラブルよりも、日常の運用や組織構造の中に潜んでいます。ヒューマンエラー、手順の属人化、不透明な作業権限など、組織としての仕組みの弱さが、可用性を損なうリスクを高めるのです。この観点では、主に権限分離とダブルチェック、マニュアルと標準化、作業記録とログ管理の3点がポイントになります。
まず一つ目は、権限分離とダブルチェックの仕組みを取り入れることです。重要な設定変更や本番環境への操作が、1人の判断や作業で完結してしまう体制では、たった1つのミスが全社的なサービス停止に直結する恐れがあります。これを防ぐには、操作を行う担当者と、その内容を確認・承認する担当者を分離し、作業前のレビューや申請プロセスを必須とすることが有効です。加えて、リスクの高い操作については、複数人による立ち会いやWチェック体制を設けることで、安全性を高めることができます。
二つ目は、マニュアル整備と作業手順の標準化です。業務が特定の担当者に依存していたり、慣習ベースで作業が進められている状況では、トラブルが発生したときに他の人が対応できない、という事態になりかねません。こうした属人性を排除するために、日常的な運用や障害対応の手順を文書化し、誰が作業しても同じ品質で対応できるようにしておく必要があります。また、手順の見直しや更新を定期的に行うことで、現場との乖離を防ぎ、実効性のあるマニュアルとして活用できます。
三つ目は、作業記録とログの活用です。可用性に関わる作業を行った際の記録が残っていないと、問題が発生したときの原因特定や再発防止が難しくなります。どのような操作を、誰が、いつ、どのように行ったのかを記録し、万一のトラブル時には速やかに遡れる状態を保つことが重要です。これは、IT監査やインシデント対応の観点からも欠かせない基本対策です。
これらの構造的な取り組みは、人の行動が原因となる可用性リスクを、組織の仕組みで制御するための工夫です。現場任せにせず、組織全体で間違いにくくする、間違ってもすぐに気づける体制を整えることが、長期的な可用性の維持につながります。
関係性の観点：依存先・連携先との調整と可視化
可用性は、自社だけで完結する問題ではありません。クラウド、SaaS、外部委託、OSSといった外部リソースに依存する現代のシステムでは、誰とどうつながっているかを正しく理解し、関係性を管理することが可用性の前提条件になります。ここでは、責任分界の明確化、サプライチェーンの可視化、社内外の連携体制の構築という3つの取り組みが求められます。
第一に必要なのが、外部サービスや委託先との責任分界の明確化です。クラウドサービスやSaaSを利用している場合、インフラの可用性を完全に自社でコントロールすることはできません。そのため、サービス提供事業者との契約やSLA（サービスレベル合意）において、稼働率・復旧時間・障害通知・対応手順などの条件を事前に合意し、文書として把握しておくことが不可欠です。トラブル発生時に自社の責任なのか、委託先の責任なのかが曖昧なままだと、復旧対応が遅れ、被害が拡大しかねません。
次に重要なのが、ソフトウェアサプライチェーンの可視化と管理です。近年のLog4Shellに代表されるように、オープンソースライブラリや委託開発コードなど、自社が直接開発していないコンポーネントに脆弱性が潜むケースが増えています。これを可用性リスクとして把握するには、使用しているソフトウェア部品やその依存関係を洗い出す、いわゆるSBOM（ソフトウェア部品表）を整備し、どこに影響が及ぶ可能性があるかを可視化しておくことが求められます。可用性は見えない依存先によって脅かされることがある、という前提での管理が必要です。
さらに、社内外をまたいだ連携体制の構築と訓練も欠かせません。可用性を損なうインシデントは、自社だけで対応しきれない場合があります。たとえば、クラウド障害時にベンダーに連絡する手順、複数の子会社・グループ会社と一斉に対応を取る体制、通信事業者との復旧連絡フローなど、関係者を巻き込んだ体制構築と定期的な確認・訓練が、迅速な対応につながります。
このように、可用性を守るには、自社の内側だけでなく、つながっている外部との関係性そのものを管理・最適化する視点が不可欠です。依存している先、任せている先、連携している相手との調整ができて初めて、安心して業務が継続できる土台が築かれます。
備えの観点：復旧までの道筋を準備しておく
どれだけ堅牢にシステムを設計しても、どれだけ組織体制や関係性を整えても、障害や攻撃の発生そのものを完全に防ぐことはできません。そのため、可用性を維持するうえで最も現実的かつ実効性の高い対策が、いざ止まったときに、どう復旧するかの事前準備です。ここでは、バックアップとリストア手順の整備、BCP／DR計画の策定と訓練、インシデント対応フローの明確化という3つの要素が重要になります。
まず最初に必要なのが、バックアップと復元の体制整備です。これはあらゆる可用性対策の基本とも言える取り組みで、システム停止やデータ破壊、ランサムウェアによる暗号化などに備えて、重要なデータや設定情報を定期的にバックアップし、確実に復元できる手順を確立しておくことが求められます。ここで重要なのは、単にバックアップを取るのではなく、実際にリストアテストを実施し、復旧にかかる時間や手順を可視化しておくことです。
次に必要なのが、事業継続計画（BCP）や災害復旧計画（DR）の策定と訓練です。これは、システムが完全に使えない状態になったときに、業務を止めずに続ける方法を事前に定めておくものです。たとえば、他拠点への業務移管、紙運用への切り替え、クラウド代替環境の起動など、業務ごとの優先度と復旧手段を整理し、関係者全員で実際に訓練を行うことが重要です。特に、可用性の低下がビジネスに直結する業種においては、こうした計画が形式だけで終わっていないかを定期的に検証する必要があります。
最後に、インシデント発生時の対応フローの明確化も欠かせません。誰が状況を確認し、誰が判断し、どこに連絡し、どのように復旧を進めるのか、この一連の手順を整える必要があります。こうした手順が曖昧なままでは、初動が遅れ、被害が拡大するリスクがあります。とくに、IT部門だけでなく現場部門や経営層、委託先など関係者の役割分担を明文化しておくことで、緊急時の混乱を最小限に抑えることができます。
このように、可用性のための備えは、起こってしまった事態にどう立ち向かうかをあらかじめ考え、仕組みにしておくことです。事前準備があれば、予期せぬ事態が発生しても、組織は冷静に対応し、サービスを迅速に復旧させることができます。これこそが、可用性の本質的な強さにつながる力です。
まとめ
情報セキュリティにおいて、可用性はしばしば機密性や完全性の陰に隠れがちですが、実際には業務や社会インフラの継続に直結する重要な要素です。
一度でもサービスやシステムが停止すれば、売上や顧客対応に直結した混乱が発生し、BtoBのサービスであればSLA違反や損害賠償のリスクにもつながります。さらに、医療・交通・通信などの領域では、人命や社会全体への影響も避けられません。
本稿で取り上げたように、CrowdStrikeのアップデート障害やColonial Pipelineへのランサムウェア攻撃は、可用性喪失が一企業の問題にとどまらず、社会や経済全体に連鎖的な影響を及ぼすことを示しています。また、Log4Shellのような脆弱性は、直接的・間接的にサービス停止を引き起こし、組織の信頼や業務継続性を大きく損ないます。
これらの事例に共通するのは、一見して小さな要因が、大規模な可用性リスクに発展している点です。単純な設定ミス、アップデートの不備、脆弱性対応の遅れといった日常的な管理の緩みが、重大な障害の引き金となっています。
障害は起こるものだと前提を置き、復旧までの手順、代替手段、責任分界、関係者の対応力を含めた、具体的な備えを組織全体で進めていくことが求められます。
可用性を守るということは、企業としての責任を果たすことであり、将来の信頼を守る行為でもあります。
すべてのリスクをゼロにすることはできませんが、まずは自社の業務にとって止まったら困るものは何かを、把握することから始めてみてはいかがでしょうか。
