事業継続計画(BCP)とは何か ― 意義・策定プロセス・国際標準の全体像

近年、地震や台風などの自然災害、感染症の世界的流行、さらにはサイバー攻撃や大規模な通信障害など、企業活動を脅かすリスクが多様化・複雑化しています。こうした中で、事業を中断させずに継続するための体制を整備することは、もはや一部の大企業だけでなく、あらゆる組織にとって経営上の必須要件となっています。

このような背景のもと注目されているのが、BCP(Business Continuity Plan:事業継続計画)です。BCPは、災害やシステム障害などの非常事態が発生した際に、重要な業務をいかに維持または迅速に復旧させるかを定めた計画のことを指します。単なる危機対応マニュアルではなく、企業の存続と社会的責任を果たすための包括的な仕組みとして位置づけられています。

日本では、2000年代初頭から政府が企業のBCP策定を推進しており、内閣府が2005年に公表した「事業継続ガイドライン」によってその重要性が広く認識されるようになりました。また、国際的にはISO 22301に代表される事業継続マネジメントシステム(BCMS)の規格が整備され、グローバルなサプライチェーンの中で、取引条件としてBCPの有無を問われるケースも増えています。

本記事では、BCPの基本概念から策定プロセス、関連する主要用語、そして国際的な標準や実践のポイントまでを体系的に解説します。BCPを理解し、実効性ある計画を構築することは、企業のレジリエンス(耐性)を高め、予期せぬ危機にも揺るがない経営基盤を築く第一歩となります。

BCPとは何か

BCP(事業継続計画)の定義

BCP(Business Continuity Plan:事業継続計画)とは、地震・台風・火災などの自然災害や、感染症の流行、テロ攻撃、システム障害、サイバー攻撃など、企業活動を中断させる可能性のある緊急事態に備え、重要な業務を継続または早期に復旧させるための計画を指します。
BCPの目的は、被害を最小限に抑えつつ、顧客・取引先・従業員・社会に対して責任ある対応を行うことにあります。単に災害発生後の「復旧マニュアル」ではなく、危機が発生しても中核業務を維持できる経営の仕組みとして位置づけられています。

BCPが注目される背景

BCPの重要性が広く認識されるようになったのは、2000年代以降の大規模災害や社会的混乱が契機となっています。
特に、2004年の新潟県中越地震、2011年の東日本大震災、2020年以降の新型コロナウイルス感染症の世界的拡大などが、企業活動に深刻な影響を与えました。これらの出来事を通じて、多くの企業が「通常業務を前提とした経営体制の脆弱さ」を痛感しました。

また、グローバル化とサプライチェーンの複雑化に伴い、一社の事業停止が取引先や顧客、さらには国際市場全体に影響を及ぼすケースも増えています。そのため、取引先選定や調達契約においてBCPが条件とされることも一般的になりつつあります。政府や自治体もこれを重要な経済安全保障の一環として捉え、内閣府や中小企業庁が策定支援を行っています。

BCPの目的と基本原則

BCPの最終目的は「企業活動の継続と早期復旧」にあります。そのために、計画策定では次の3つの原則が重視されます。

  1. 人命の安全確保
    従業員や顧客など、関係者の生命を守ることを最優先とします。避難誘導・安否確認・医療連携などの体制を整備することが基本です。
  2. 重要業務の維持または早期再開
    売上や信用の維持に直結する業務を特定し、それを停止させない、または停止しても短期間で復旧できる仕組みを構築します。
  3. 社会的責任と信頼の維持
    顧客や取引先への供給責任を果たし、企業としての社会的信用を守ることが求められます。

これらを実現するためには、業務継続に必要な資源(人・情報・設備・システム・サプライヤーなど)をあらかじめ洗い出し、リスク分析と影響評価を通じて、優先順位を明確にしておくことが重要です。

BCPの位置づけ

BCPは、危機管理計画(Crisis Management Plan)と混同されることがありますが、両者の目的は異なります。危機管理計画が「事故や災害発生直後の対応(被害抑制・救助・情報発信)」に重点を置くのに対し、BCPは「業務の維持と復旧」という事後の経営継続プロセスに焦点を当てています。

また、BCPは単独の文書ではなく、組織全体の運用体制として継続的に改善されるべき仕組みです。その運用を包括的に管理する枠組みがBCM(Business Continuity Management:事業継続マネジメント)であり、次章以降ではその具体的な構成や手順について解説します。

BCP策定のプロセス

BCP(事業継続計画)は、単なる文書の作成ではなく、組織全体が一体となって「いかに事業を止めないか」「止まってもどう早く立ち上げるか」を設計するプロセスです。計画策定には体系的な手順が求められ、通常は「分析」「設計」「体制整備」「訓練・改善」の流れで進められます。本章では、代表的な策定プロセスを段階的に解説します。

1. リスク分析と影響評価(BIA:Business Impact Analysis)

最初の工程は、リスク分析影響評価(BIA)です。
ここでは、組織が直面し得る脅威を特定し、それが各業務にどの程度の影響を及ぼすかを定量的に把握します。想定するリスクには、地震・洪水・感染症・火災・停電・サイバー攻撃など、物理的・人的・技術的な要因が含まれます。

BIAの目的は、業務停止による財務的損失、顧客への影響、社会的信用の低下などを評価し、「どの業務をどの順序で復旧すべきか」を明確にすることにあります。この分析により、復旧時間目標(RTO:Recovery Time Objective)や許容できるデータ損失時間(RPO:Recovery Point Objective)を設定する基礎が整います。

2. 重要業務の特定と優先順位付け

BIAの結果をもとに、事業の継続に不可欠な「重要業務(Critical Business Functions)」を特定します。
すべての業務を同時に復旧することは現実的ではないため、経営上の影響度・依存関係・顧客要求などの観点から優先順位を明確にします。

重要業務を決定する際には、以下のような判断基準が用いられます。

  • 売上や社会的信頼に直結する業務か
  • 他部門や取引先に影響を与える業務か
  • 短期間の停止でも致命的な損失を生む業務か

この優先順位づけにより、限られた資源を効率的に配分できる復旧計画を策定することが可能になります。

3. 代替手段・復旧手段の設計

次に、重要業務を支える資源(人員・設備・情報・システム・サプライヤーなど)が利用できなくなった場合に備え、代替手段(Alternative Measures)を設計します。

たとえば、以下のような手法が一般的です。

  • 代替拠点の確保:災害時に使用可能なサテライトオフィスや他地域のデータセンターを事前に契約。
  • システム冗長化:クラウドバックアップ、デュアルサイト構成、遠隔地レプリケーションなど。
  • 業務委託や協定:他社・関連団体との相互支援協定、外部委託による代替実施体制。
  • 人員代替:複数担当制や手順書整備による属人化防止。

これらの設計段階では、コスト・実現可能性・復旧速度のバランスを検討することが重要です。

4. 指揮命令系統・連絡体制の整備

緊急時には、通常の組織体制では機能しない場合があります。そのため、緊急時指揮命令系統(Emergency Chain of Command)を定めておく必要があります。
経営層・BCP責任者・現場リーダーの役割を明確にし、代行順位や意思決定手順をあらかじめ文書化します。

加えて、連絡体制の整備も不可欠です。連絡手段が一つに依存していると機能不全を起こすため、電話・メール・チャット・安否確認システムなど複数チャネルを組み合わせた多層構造にしておくことが推奨されます。
また、初動対応の時間的猶予が短いため、通報・連絡・指示の標準手順(SOP)を平時から訓練しておくことが望ましいです。

5. 教育・訓練・定期的見直し

策定したBCPは、一度作って終わりではなく、継続的に改善されるべき「生きた計画」です。
組織の人員構成、業務プロセス、IT環境、外部環境(災害リスク・法制度など)は常に変化するため、定期的な教育・訓練と見直しが必要です。

教育の目的は、従業員が自らの役割と対応手順を正しく理解することにあります。訓練には次のような形式があります。

  • テーブルトップ演習:シナリオを用いて机上で対応を検討する。
  • 実動訓練:避難・連絡・復旧作業を実際に行う。
  • システム復旧テスト:バックアップからの復旧検証を定期的に実施する。

さらに、訓練結果や実際の災害対応で得られた教訓を反映し、PDCAサイクル(Plan–Do–Check–Act)に基づいて継続的改善を行うことが、BCPの実効性を維持する上で極めて重要です。


このように、BCPの策定プロセスは単なる文書化作業ではなく、組織の全階層を巻き込んだ経営プロセスです。次章では、この計画を支える関連概念や指標について体系的に整理します。

BCPに関連する主要用語

BCP(事業継続計画)は、単独で機能する仕組みではなく、複数の関連概念や管理手法と密接に結びついています。本章では、BCPを理解・運用するうえで重要となる主要用語を整理し、その相互関係を明確にします。

BCM(Business Continuity Management:事業継続マネジメント)

BCMとは、BCPを策定・実行・改善するための包括的な管理プロセスを指します。BCPが「計画書」であるのに対し、BCMは「その計画を運用し、継続的に改善する仕組み」です。
ISO 22301では、BCMを「組織のレジリエンスを高め、混乱事象が発生しても重要業務を維持する能力を確保するためのマネジメントシステム」と定義しています。

BCMの特徴は、BCPを一時的な文書ではなく組織文化の一部として定着させる点にあります。定期的な教育・訓練、監査、経営層のレビューなどを通じて、継続的改善(PDCAサイクル)を実現します。

DR(Disaster Recovery:災害復旧)

DRとは、ITシステムやデータなど、情報資産の復旧に焦点を当てた計画を意味します。特にサーバ、ネットワーク、クラウド環境などの障害に対して、業務システムを迅速に再稼働させることを目的としています。

DRはBCPの一部として位置づけられますが、範囲はIT領域に限定されます。たとえば、データセンターのバックアップ拠点、遠隔地レプリケーション、クラウドフェイルオーバー、バックアップ検証テストなどが代表的な対策です。
BCPが「業務の継続」を目的とするのに対し、DRは「システムの復旧」を技術的に支える存在です。

RTO(Recovery Time Objective:目標復旧時間)

RTOとは、業務やシステムを停止した際に、許容される最大停止時間を示す指標です。たとえば、RTOを「4時間」と設定した場合、その業務は障害発生から4時間以内に復旧できなければ、重大な損害が発生すると判断されます。

RTOは、業務の重要度と顧客要求に基づいて設定され、システム設計や代替手段の投資規模を決定する重要な指針となります。一般的に、RTOが短いほど高い冗長性やコストが必要になります。

RPO(Recovery Point Objective:目標復旧時点)

RPOは、データ損失をどこまで許容できるかを表す指標で、「どの時点までのデータを復旧すべきか」を示します。たとえばRPOを「1時間」と設定した場合、障害発生前1時間以内のデータが保持されていれば許容範囲とみなされます。

バックアップ頻度、レプリケーション間隔、クラウド同期方式などを決定する際の重要な基準となり、特に金融・製造・ECなど、リアルタイム性が要求される業種では厳密に管理されます。
RTOとRPOはセットで定義されることが多く、BCP/DR計画の核心を構成します。

BIA(Business Impact Analysis:業務影響分析)

BIAは、前章でも触れたとおり、各業務が停止した場合に生じる影響を定量的に分析する手法です。財務的損失、顧客離脱、法令違反、ブランド毀損などの観点から影響度を評価し、復旧優先順位を設定します。

BIAはBCP策定の出発点であり、RTO・RPOの設定や資源配分の根拠となります。多くの組織では、年1回程度のBIA見直しを実施し、経営環境やリスクの変化に対応しています。

SLA(Service Level Agreement:サービスレベル合意書)との関係

SLAは、サービス提供者と利用者の間で取り決める提供品質の水準(可用性、応答時間、復旧時間など)を明文化した契約です。
BCPやDRの観点では、SLAにRTOやRPOを明確に定義することが、事業継続性の保証に直結します。

特にクラウドサービスや外部委託先を利用する場合、SLAの内容によって復旧可能性が大きく左右されます。そのため、SLAはBCPの実効性を裏付ける契約上の担保として不可欠です。

レジリエンス(Resilience:復元力・耐性)

レジリエンスとは、組織が外部のショックを受けても柔軟に適応し、元の状態またはより強固な形で回復できる能力を指します。
BCPやBCMの究極の目的は、このレジリエンスを高めることにあります。単なる「危機対応」ではなく、変化に強い経営体質を作ることが、持続可能な事業運営の鍵となります。


以上のように、BCPは単体で完結するものではなく、BCMを中心に、BIA・RTO・RPO・DR・SLAなどの概念が密接に連動して成立しています。これらを理解することで、計画の策定から実行、改善に至る一連のプロセスを体系的に把握することが可能になります。次章では、こうした概念を実際に運用するための評価と維持の方法について解説します。

BCPの運用と評価

BCP(事業継続計画)は、策定しただけでは実効性を持ちません。計画を組織全体で運用し、定期的に評価・改善を行うことで、初めて現実的に機能する仕組みとなります。本章では、BCPの運用段階における実施方法と、評価・改善の考え方を解説します。

訓練・模擬演習の実施

BCPを有効に機能させるためには、平時から訓練を繰り返すことが不可欠です。訓練は、緊急時に想定される行動を事前に確認し、組織としての初動対応力を高めることを目的とします。

訓練の形式は主に以下の3種類に分類されます。

  • 机上訓練(テーブルトップ演習)
    災害や障害のシナリオを用い、関係者が会議形式で対応手順を確認する方法です。手軽に実施でき、意思決定フローや連絡体制の確認に適しています。
  • 実動訓練(フィールド演習)
    実際に避難・通信・復旧作業を行う訓練であり、現場対応能力の検証に有効です。特にデータ復旧や代替拠点への切替など、物理的な動作確認を伴う場合に実施されます。
  • 包括的演習(総合訓練)
    全社的に複数部門が連携して実施する訓練で、指揮命令系統や複数のシナリオを同時に検証します。防災訓練やサイバーセキュリティ演習などと統合して行うケースもあります。

訓練後は、問題点や改善事項を文書化し、次回の計画改訂に反映させることが重要です。訓練は最低でも年1回、重要部門では半年に1回の実施が望ましいとされています(内閣府「事業継続ガイドライン」より)。また、金融業など高リスク業種では四半期ごとの訓練が事実上義務化されています(金融庁監督指針)。

評価指標と改善プロセス

BCPの有効性を維持するには、定量的・定性的な評価を継続的に行う必要があります。評価では、次のような観点が用いられます。

  • 対応時間の妥当性:RTO(目標復旧時間)内に業務を再開できたか。
  • 手順の適切性:緊急連絡、意思決定、代替手段の運用が実際に機能したか。
  • 資源の有効性:必要な人員・物資・システムが確保されていたか。
  • 連携体制の信頼性:社内外の関係者との情報共有が円滑に行われたか。

これらの評価を踏まえ、改善活動はPDCAサイクル(Plan–Do–Check–Act)に基づいて行われます。

  • Plan(計画):BCPの改訂や改善方針を策定。
  • Do(実行):訓練や実際の対応で計画を実施。
  • Check(評価):成果や課題を分析し、指標で効果を測定。
  • Act(改善):分析結果を反映し、計画を更新。

このサイクルを定常的に回すことで、BCPは環境変化に適応し続ける「動的な管理体制」となります。

サプライチェーンBCPの重要性

現代の企業活動は、単独では完結せず、調達・製造・物流・販売といったサプライチェーン全体で成り立っています。そのため、一社の事業停止が他社の業務にも波及する「連鎖リスク」が顕在化しています。

このリスクに対応するため、企業単位ではなくサプライチェーン全体での事業継続性(連携型BCP)が注目されています。具体的には、以下のような取り組みが行われています。

  • 取引先との間で災害時の供給継続計画や代替ルートを事前に協議する。
  • 調達先のBCP実施状況をアンケートや監査で確認する。
  • 重要な部品や原材料を複数のサプライヤーから調達する「多重調達化」。
  • デジタルツインやサプライチェーン・マッピングによるリスク可視化。

政府もこの動きを支援しており、経済産業省は「サプライチェーン強靱化ガイドライン(2021年)」で、企業連携型のBCP策定を推奨しています。こうした取り組みは、単なる防災対策にとどまらず、企業間の信頼性を高める要素にもなっています。しかし、2023年度中小企業庁調査では、BCP策定率は大企業92%に対し中小企業は35%となっており、中小企業については浸透途上という現状も浮き彫りになっています。

第三者評価と認証制度

BCPやBCMの成熟度を客観的に評価するため、第三者認証制度を導入する企業も増えています。代表的なものに、ISO 22301(事業継続マネジメントシステム)があります。この国際規格は、BCPの構築から運用、レビュー、改善に至るプロセスを体系的に規定しており、認証取得は取引上の信頼向上や入札要件にも直結します。

また、日本国内では中小企業庁による「事業継続力強化計画」認定制度もあり、防災・減災対策や継続計画を策定した中小企業を公的に支援する仕組みが整っています。

継続的な見直しと経営層の関与

BCPの実効性を左右する最大の要因は、経営層のコミットメントです。BCPは現場任せではなく、経営戦略の一部として位置づけられるべきものです。経営層が明確な方針を示し、リスクに対する投資判断を主導することで、組織全体の意識と行動が統一されます。

さらに、BCPは一度策定したら終わりではなく、組織構造・事業内容・外部環境の変化に応じて継続的に更新する必要があります。最低でも年1回のレビューを行い、最新のリスクやシナリオに対応できる状態を保つことが推奨されます。


このように、BCPの運用と評価は、計画の維持管理だけでなく、組織文化や経営方針にまで踏み込む継続的な活動です。次章では、これらの実践を支える国際規格および国内ガイドラインについて詳しく解説します。

BCPの国際規格とガイドライン

BCP(事業継続計画)の有効性を高めるためには、体系的な枠組みに基づいた運用が不可欠です。各国では、企業や行政機関が共通の基準で事業継続を管理できるよう、複数の国際規格や政府ガイドラインが整備されています。本章では、代表的な国際標準および日本国内の指針を中心に解説します。

ISO 22301:事業継続マネジメントシステム(BCMS)の国際標準

ISO 22301(Security and resilience — Business continuity management systems — Requirements)は、国際標準化機構(ISO)が2012年に制定した、事業継続マネジメントシステム(BCMS)の国際規格です。最新版は2019年改訂版(ISO 22301:2019)であり、世界中の企業や公共機関が採用しています。

ISO 22301は、単なるBCPの作成方法ではなく組織全体で事業継続を管理する仕組み(マネジメントシステム)を定義しています。主な要求事項は以下のとおりです。

  • 組織の状況把握:事業環境、利害関係者、法的要件の明確化。
  • リーダーシップ:経営層による方針策定と責任の明確化。
  • 計画策定:リスク評価・影響分析・復旧目標設定。
  • 運用:訓練、文書管理、緊急対応手順の整備。
  • 評価と改善:内部監査、経営レビュー、継続的改善。

ISO 22301の特徴は、「PDCAサイクル(Plan–Do–Check–Act)」に基づく継続的改善を求めている点にあります。
この規格に基づく認証を取得することで、組織は国際的に認められた事業継続能力を対外的に証明でき、サプライチェーンの信頼性向上や入札要件への適合にもつながります。

内閣府「事業継続ガイドライン」

日本では、内閣府が2005年に公表した「事業継続ガイドライン(Business Continuity Guidelines)」が、企業のBCP策定の基礎指針として広く活用されています。最新版は2022年版(第5版)であり、国内企業の災害対応能力の強化を目的としています。

このガイドラインは、ISO 22301の原則を踏まえつつ、日本の災害特性や企業規模を考慮した実務的内容が特徴です。主な構成要素は次のとおりです。

  • 事業継続の基本理念と目的
  • BCP策定のステップ(リスク分析、BIA、対策、教育・訓練)
  • 中小企業・自治体への実践的アプローチ
  • 災害時の官民連携体制の重要性

特に、中小企業のBCP支援を目的とした「簡易BCP策定テンプレート」や「地域連携型BCP」も提示されており、各業種の実情に応じた柔軟な活用が可能です。

NIST SP 800-34 Rev.1:米国連邦政府のIT復旧指針

NIST SP 800-34 Revision 1(Contingency Planning Guide for Federal Information Systems)は、アメリカ国立標準技術研究所(NIST)が2010年に改訂した、情報システムにおける事業継続と災害復旧のための指針です。主に政府機関向けの文書ですが、民間企業のDR(Disaster Recovery)やIT-BCPにも広く参考にされています。

このガイドラインでは、情報資産の保全を中心に、以下の要素が体系的に示されています。

  • システムの重要度に応じた復旧戦略の策定。
  • バックアップ、代替システム、冗長化の実装方法。
  • インシデント対応、連絡、復旧後のレビュー手順。

NIST文書の特徴は、リスク評価と技術的対策の明確な対応関係を定義している点にあります。クラウド利用やゼロトラストアーキテクチャを前提とした設計にも適用しやすく、IT部門におけるBCP策定の標準的な参照資料となっています。

その他の主要基準と国内制度

BCPに関連する国際・国内の標準化動向として、以下の基準や制度も整備されています。

  • ISO 22313:ISO 22301の運用ガイドライン。具体的な実施手順を補足。
  • ISO/TS 22317:BIA(業務影響分析)に特化した技術仕様書。
  • ISO/TS 22318:サプライチェーン継続性マネジメントに関するガイドライン。
  • 中小企業庁「事業継続力強化計画」認定制度(2019年開始)
    中小企業が策定した防災・減災・BCP計画を国が認定し、金融支援や補助金優遇を受けられる制度。

これらの基準は相互に補完関係にあり、ISO規格で基礎的な枠組みを学び、国内ガイドラインで実務に落とし込む構成が効果的です。

国際標準化の潮流と今後の展望

事業継続の概念は、単なる防災対策から「社会的レジリエンス(resilience)」へと拡大しています。ISOはBCP関連の規格群を「Security and Resilienceシリーズ(ISO 22300ファミリー)」として体系化しており、今後はサイバーセキュリティ、サプライチェーン、パンデミック対応などを含む統合的リスクマネジメントへと進化が見込まれます。

また、ESG(環境・社会・ガバナンス)経営やSDGsの観点からも、BCPの整備は企業の社会的信頼性や持続可能性評価の一要素として注目されています。今後、BCPの整備・運用は「危機対応」だけでなく、「経営品質の指標」としての重要性をさらに増すと考えられます。


以上のように、BCPは国際的に共通の枠組みのもとで標準化が進んでおり、日本国内でもその整備が着実に進展しています。これらの規格やガイドラインを活用することで、企業は自社の特性に合った効果的な事業継続体制を構築し、社会全体の安定性向上に寄与することが可能となります。

おわりに

BCP(事業継続計画)は、もはや一部の大企業だけの取り組みではなく、あらゆる組織に求められる経営基盤の一部となっています。自然災害や感染症、サイバー攻撃、インフラ障害など、企業活動を脅かすリスクは年々多様化しており、想定外の事象が発生する確率は確実に高まっています。そのような状況下で、「止まらない組織」ではなく「すぐに立ち上がれる組織」をつくることこそが、現代の事業継続における核心です。

BCPの策定・運用は単なる危機管理ではなく、経営戦略の一部として位置づけるべきものです。平時からリスクを分析し、復旧体制を整え、訓練や見直しを繰り返すことにより、企業は不確実な環境下でも柔軟に対応できる体制を確立できます。こうした取り組みは、単に災害対応力を高めるだけでなく、取引先や顧客からの信頼、従業員の安心感、そして企業の社会的信用を支える基盤となります。

また、国際的にはISO 22301などの標準化が進み、国内でも内閣府や中小企業庁による支援制度が整備されています。これらの枠組みを活用し、自社の規模や業種に応じたBCPを段階的に整備していくことが、実効性のある事業継続体制の構築につながります。

今後の社会では、BCPの整備は単なる「リスク回避」ではなく、「組織の持続可能性(サステナビリティ)」を担保する取り組みとして位置づけられるでしょう。危機はいつか必ず訪れます。そのときに備え、BCPを経営の一部として不断に更新し続ける姿勢こそが、真に強い組織をつくる最も確実な道と言えます。

参考文献

Microsoft Azureで大規模障害発生 ― Microsoft 365やXboxにも影響、原因は構成変更ミス

日本時間2025年10月30日午前1時頃からMicrosoft Azureで大規模な障害が発生しました。これにより、Microsoft Azure、Microsoft 365、Minecraft、XboxなどのMicrosoftが提供する製品やサービスだけでなく、Starbucks、costco、Krogerといった大手企業のシステムにも波及しました。

Microsoftの発表によると、「Azure Front Door(AFD)における誤った構成変更(inadvertent configuration change)」が原因とのことで、この設定変更が DNS ルーティングに影響を与え、Azure Portal や関連サービスにアクセス不能状態を引き起こしたものと見られています。

発生から対応までを時系列に並べると以下のようになります。

  1. 2025年10月30日 午前1時頃(日本時間)
    障害発生を確認
  2. 2025年10月30日 04:19(日本時間)
    「last known good configuration(直前の正常構成)」のデプロイが完了し、ノード復旧を開始し、「今後4時間以内に完全復旧を見込む」と告知
  3. 2025年10月30日 08:20(日本時間)
    Azure側が「recovery to happen by 23:20 UTC(=8:20 JSTまでに復旧見込み)」と明記
  4. 2025年10月30日 09:40(日本時間)
    最終更新で「AFDサービスが98%以上の可用性を回復し、完全復旧を9:40 JSTに見込む」と発表

日本では、発生した時間自体は深夜ですが、回復に午前9時過ぎまでかかったため、朝一でメールを受信しようとしたらメールが受信できないなどの影響を受けた方もいたかと思います。

クラウド障害のインパクトの大きさ

先日のAWSの障害もDNSに起因するものでした。

DNSで障害が起きるとネットワークを前提としたシステムは非常に脆いことがわかります。加えて、クラウドベンダーが提供して責任を持つ部分であるため、DNSで障害が起きると複数のサービスに影響がおよび、それらのサービスを使用している複数の企業が影響を受けます。

この点については、各企業ごとに対策することが難しい場合が多いです。クラウド上でシステムを運用しているならマルチクラウドという選択肢はあるにはあります。ただし、コストとトレードオフになるため、事業規模によっては選択肢できない場合もあります。

また、IaaSではなくPaaSサービスを利用している場合はそういった選択肢も難しい場合があります。例えば、Microsoft 365で障害が起きた場合、他のベンダーでメールサービスを継続するということは不可能です。インフラを管理しないことに対するトレードオフでもあるので、どうしても障害を起こしたくないのであればインフラを管理する必要がありますが、クラウドベンダー並の可用性を実現できる企業は数えるほどしかないでしょう。

もう一つはこれが誤設定によるものであるという点です。過去に発生した大規模障害においても、誤った設定を適用した場合や操作ミスといった単純ミスによるものであったことがありました。これはMicrosoft Azureに限ったものではなく、他のクラウドベンダーでも起きています。

具体的な内容については公表されていないので想像になりますが、本当にただの凡ミスだったかもしれません。もしかすると、想定していなかった挙動だったのかもしれません。いずれにせよ、本当のところはわからないので一方的に「テストをしていないのではないか」と断ずるのは総計です。実際、DNS周りは想定しない挙動をする場合があるので、本番同等の環境を用意するのは現実的ではないため、テスト環境では問題ないことを確認した上で適用したが、予想しない挙動を示していたのかもしれません。

おわりに

以前のAWSの障害、今回のAzureの障害から言えるのは、

  • 代替の選択肢を持つこと
  • バックアップを3-2-1ルール取得し、復元できることを定期的に確認しておくこと

が重要であるということです。

代替の選択肢を持つというのは、メールの例で言えばメールが唯一の連絡手段になってしまうとメールが使用できなくなったときに業務が完全にとまってしまうので、それ以外の手段を持っておくというです。メールの例でいえば、電話やチャットなど複数の手段があるのが普通だと思いますのでそれほど問題ありません。しかし、空港での搭乗手続きが完全に電子化され、手動での搭乗手続きの手段が失われていたらどうでしょうか?ゲート搭乗機に障害が発生すると運休せざるを得なくなってしまいます。そういった意味では電子化は優れた選択肢である一方でそこに障害が発生したときに、人間の手による代替ができるようになっていることが重要です。

前述の話は機能に障害が発生した場合ですが、データにアクセスできなくなる場合やロストする場合について対策が必要です。古典的な手段ではありますが、現代でも有効な3-2-1ルールに則って、3つのデータコピーを保持し、2種類の異なるメディアに保存し、そのうち1つをオフサイト(地理的に離れた場所)に保管することは非常に有効です。

ただし、いくらバックアップが無事だといってもそこから復元できなければ意味がありません。バックアップを用意していても、いざ復元しようとしたら戻せなかったということは今に始まった話ではなく昔からずっと起きている話です。古くはテープにバックアップしたけどそこから復元できなかったなどということはよくある話ですし、2020年にはバックアップに不備があり障害が起きたときにバックアップから復元できずに売買停止が起きたこともありました。

避難訓練と同じで、災害発生時のマニュアル確認のための訓練やバックアップから復元できるかのリハーサルは義務付けられているものを除くと行っていないケースが多いように思います。日常的にテスト環境を構築するのにバックアップを使っているという場合であればバックアップ自体は使用可能だt思いますが、高度に自動化されている場合は手動でもできるのかといった点や3-2-1ルールに則ってバックアップが完全に失われないかなどを見直すことも重要です。

「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、こういった他社の事例からもしっかりと教訓を得ることは重要です。

参考文献

AWSで大規模障害 ― マルチAZ構成でも防げなかった理由と今後の対策

2025年10月20日(日本時間)、Amazon Web Services(AWS)において大規模なサービス障害が発生しました。障害は主に米国東部リージョン(US-EAST-1)で発生し、世界中の多くのオンラインサービスやアプリケーションが一時的に停止しました。

本稿では、今回の障害の概要と影響範囲、マルチAZ構成を採用していても防げなかった理由、そして今後の設計指針について整理します。

障害の概要

AWS公式ステータスによれば、障害はUS-EAST-1リージョンにおける複数サービス(DynamoDB、Lambda、API Gateway、STSなど)で発生し、エラー率の急上昇およびレイテンシの増大が確認されました。

この影響により、Snapchat、Fortnite、Signal、Perplexity、Alexaなど、多数の世界的サービスが同時にダウンしました。AWSはその後「主要な根本原因を特定し、主要機能は緩和された(fully mitigated)」と発表していますが、一部では依然として遅延やキュー残りが発生していると報じられています。

マルチAZ構成でも防げなかった理由

AWSが推奨するマルチAZ構成は、高可用性を実現するための基本的な冗長化手法です。しかし今回の障害では、マルチAZ構成を採用していても影響を受けたケースが確認されました。その理由は、障害のレイヤーが「AZ内」ではなく「リージョン全体」に及んでいたためです。

制御プレーン障害が発生

今回の障害は、個別のデータセンターやハードウェア障害ではなく、AWSの制御プレーン(サービス間のAPI、認証、ルーティングなど)に影響したとみられています。

その結果、各AZの物理的な可用性は保たれていても、API呼び出しやリソース管理を行う中核部分が機能しなくなり、アプリケーションレベルでの可用性が確保できなくなりました。

マルチAZ構成の限界

マルチAZ構成は、AZ単位の停電・ネットワーク断などに対しては効果的ですが、制御プレーンや内部ネットワーク層に障害が発生した場合には対応できません。

このため、同一リージョン内の冗長化では「論理的単一障害点(Single Point of Failure)」が残るという設計上の限界が明確に浮き彫りになりました。

今後の対策と設計指針

今回の障害を踏まえると、ランニングコストと求める耐障害性のバランスをどう考えるかが構成設計の分岐点となります。冗長化を強化するほど可用性は向上しますが、運用コストや構成の複雑さも増大します。以下では、代表的な構成パターンと考慮点を整理します。

マルチAZ構成+別リージョンでのコールドスタンバイ構成

平常時は単一リージョンで稼働させ、障害時にのみ別リージョンの環境を立ち上げる方式です。コストを抑えつつ大規模障害に備えられますが、復旧までに数時間単位のダウンタイムが発生します。

  • メリット:低コストで広域障害への備えが可能
  • デメリット:RTO(復旧時間目標)が長く、人的操作が必要

マルチAZ構成+別リージョンでのウォーム/ホットスタンバイ構成

別リージョンにも一定のリソースを常時稼働させておき、障害時に迅速に切り替える構成です。ウォームは部分稼働、ホットは完全稼働を指します。コストと可用性のバランスを柔軟に調整できます。

  • メリット:自動フェイルオーバーが可能でRTOを短縮できる
  • デメリット:維持コスト・設計複雑度が上昇

マルチリージョン構成

複数リージョンで同時稼働させるアクティブ/アクティブ構成です。トラフィック分散や地理的冗長化に優れ、リージョン全体の障害にも耐えられますが、最も高コストかつ複雑です。

  • メリット:最高水準の可用性と応答性能を確保
  • デメリット:整合性維持とコストが大きな課題

マルチクラウド構成

AWS単独ではなく、GCPやAzureなど複数のクラウドを併用する構成です。ベンダー依存リスクを分散できますが、各クラウドのAPI差異・運用統合コストが課題になります。

  • メリット:クラウド全体の障害に対する強靭性を確保
  • デメリット:開発・運用の複雑化、スキル要求の増大

災害対策設計(DR: Disaster Recovery)の最低要件

いずれの構成を採る場合でも、最低限、別リージョンでサービスを再開できるDR設計を持つことが不可欠です。データバックアップ、DNSフェイルオーバー、クロスリージョンレプリケーションなど、迅速に代替リージョンへ切り替える仕組みを整備しておくべきです。

おわりに

今回のAWS障害は、クラウド基盤における高可用性設計の限界を改めて浮き彫りにしました。マルチAZ構成は依然として有効な手法であるものの、それだけで「クラウドは止まらない」と断言することはできません。過去にはAzureやGoogle Cloud Platform(GCP)でも大規模な障害が発生しており、大手クラウドベンダーであっても絶対的な安心・安全が保証されるわけではありません。

また、ランサムウェア被害の事例では、バックアップ自体が無事であったにもかかわらず、復旧がうまくいかなかったケースも報告されています。したがって、単にバックアップを取得するだけでなく、少なくとも年に一度はバックアップからの復旧訓練を実施し、実際に復元できることを検証することが重要です。

今回の事象は、制御プレーンやサービス間依存を含むリージョン単位の障害リスクを前提とした設計、およびバックアップ運用の実効性確保の重要性を改めて認識させるものとなりました。

参考文献

モバイルバージョンを終了