いま見直すべき「BCP戦略」と「マルチクラウド戦略」
2025年初頭、中東・バーレーンのAWSリージョンが物理的な攻撃を受け、一時的なサービス断が発生しました。クラウドへの脅威はサイバー空間だけにとどまらない——そのことを改めて世界のIT部門に突きつけた出来事です。
加えて、AIを悪用した高度なサイバー攻撃の増加も深刻な課題となっています。さらに、東日本大震災後に策定したBCP計画も、10年以上が経過するなかで見直しが必要な時期を迎えています。当時と比べ、リモートワークの定着によるワークスタイルの変化や、ゼロトラストセキュリティという考え方の普及など、ビジネス環境は大きく様変わりしました。当時の前提のままでは、現実に即したBCPとして機能しない可能性があります。これらの潮流が今、同時に押し寄せています。
AWS・Azure・Google Cloudによるマルチクラウドが当たり前となりつつある一方、その設計がBCPとして本当に機能しているかを検証できている企業はまだ少数派です。「導入済み」という安心感の裏で、リスクは静かに積み重なっています。
AWSバーレーン物理攻撃が示した「クラウド神話」の終焉
「パブリッククラウドは止まらない」という期待のもと、多くの企業がITインフラを移行してきました。しかし今回の事案は、クラウドプロバイダのデータセンター自体が地政学リスクや物理的脅威にさらされることを証明しました。
注目すべきは影響の広がり方です。中東に拠点を持たない日本企業でも、利用するSaaSや業務システムが当該リージョンに依存しているケースがあります。「自社には関係ない」では済まない時代です。
自社が直接使うクラウドだけでなく、業務で使うSaaSやAPIがどのリージョンに依存しているかまで把握できている企業は多くありません。この「見えないSPOF（単一障害点）」こそ、現代のクラウドBCPにおける最大の盲点です。
AI脅威の高度化——従来の防御モデルが機能しない時代へ
生成AIの普及はビジネスに恩恵をもたらした一方、サイバー攻撃にも根本的な変化をもたらしています。攻撃の「技術コスト」が劇的に下がり、高度な攻撃が誰でも実行できる環境が整いつつあります。
– フィッシング攻撃の精度向上
AIが自然な日本語を生成し、経営者・人事・財務を狙ったスピアフィッシングが急増。「日本語がおかしい」という従来の識別基準が機能しなくなっています。
– ゼロデイ脆弱性の自動探索
AIによる脆弱性スキャンの自動化で、発見から悪用までのサイクルが大幅に短縮。パッチ適用のタイムラグが命取りになるリスクがかつてないほど高まっています。
– ディープフェイクを活用したソーシャルエンジニアリング
経営幹部の音声・映像を精巧に偽造し、資金移動や認証情報の提供を迫る手口が実際の被害として報告されています。意思決定プロセス全体の見直しが必要です。
– クラウド設定ミスの自動攻略
IAM設定ミスやストレージの公開設定をAIが自動スキャンし、侵入経路を効率的に発見する攻撃も急増。クラウド設定のドリフト（意図せぬ変更の蓄積）を継続的に検知する仕組みが不可欠です。
サイバー攻撃による業務停止は「IT部門の問題」ではなく「事業継続の問題」です。BCP設計の中にサイバーインシデントシナリオを明示的に組み込むことが、現代の必須要件となっています。
震災から10年以上——ワークスタイルの変化を踏まえたBCPの刷新
2011年の東日本大震災は、日本企業にBCPの重要性を痛感させた転換点でした。しかし10年以上が経過した現在、策定当時の前提とビジネス環境が大きく乖離しています。「良いBCP」だったものが「機能しないBCP」に変わってしまう——これが今まさに多くの企業で起きている現実です。
– オンプレミス前提の設計がそのまま残っている
基幹システムの多くがクラウドに移行した今、BCPの想定シナリオが現実と合っていません。
– テレワーク・分散勤務が考慮されていない
リモートワークが定着した一方、BCPは「全員が同じオフィスで働く」前提のまま。分散環境での指揮系統や情報共有の手順が未整備なケースが大半です。
– デジタルサプライチェーンリスクが未定義
クラウド基盤・SaaS・外部APIへの依存リスクがBCPに明記されていないケースが多く見られます。ここが現代のBCPの最大の空白地帯です。
– 訓練・検証サイクルが止まっている
「BCPはあるが誰も内容を知らない」という状態はよく見られます。文書としてのBCPは有事に機能しません。
– サイバーインシデントシナリオがない
現代の事業継続リスクの筆頭はサイバー攻撃ですが、ランサムウェアやクラウド障害を想定したシナリオが欠けているBCPが大半です。
BCPは作ることが目的ではありません。「10年前に作ったBCPがある」という状態は、最新リスクを想定しない計画に安心しているという点で、むしろ危険です。今こそ全社的な棚卸しと再設計が必要なタイミングです。
マルチクラウドが「当たり前」になる時代の正しい設計思想
マルチクラウドは「先進的な取り組み」から「業界スタンダード」へと移行しつつあります。「どのクラウドを選ぶか」から「複数のクラウドをどう使いこなすか」という問いへのシフトが加速しています。
一方で「複数クラウドを使っているから大丈夫」という誤解も広がっています。BCPとして機能させるには、意図を持った設計思想が不可欠です。
– ワークロードの適切な分散設計
重要度・可用性要件・コスト特性に応じて、どのワークロードをどのクラウドに置くかを明確に定義することが大前提。「とりあえず分散」は管理コストを増やすだけです。
– フェイルオーバー経路の事前実装と検証
メインクラウド停止時のセカンダリへの切り替え経路を事前に実装し、定期的に動作を検証しておくことが必須です。有事に初めて試すのでは遅すぎます。
– データ主権・データレジデンシーの管理
どのリージョンに何のデータを置くかを体系的に管理することが、個人情報保護法・GDPR等の規制対応でも求められます。
– 統合モニタリング・コスト可視化の仕組み
複数クラウドの統合的な可視化は難易度が高く、見えないコストが積み重なるリスクがあります。CSPM・CNAPPなどのサードパーティツールの活用も検討してください。
– ベンダーロックイン回避の技術選定
Kubernetes・Terraform・コンテナ技術などクラウドニュートラルな技術スタックを基本に据えることが、長期的な柔軟性とリスク低減につながります。
マルチクラウドは手段であり、目的ではありません。「なぜマルチクラウドにするのか」「どのリスクを低減したいのか」——この問いへの答えが設計の起点です。
いま着手すべき5つの優先アクション
- BCPの棚卸しと現状適合性の確認（目安：〜1ヶ月）
「クラウド障害」「地政学リスク」「AIサイバーインシデント」「リモートワーク環境」をBCPが網羅しているか確認。担当者だけでなく経営層も内容を把握できているかも確認してください。 - クラウド依存関係のマッピング（目安：〜2ヶ月）
利用中のクラウド・SaaS・外部APIを全社的にリスト化し、単一障害点（SPOF）を洗い出します。シングルリージョン・シングルプロバイダ依存の基幹業務を優先的に対処してください。 - フェイルオーバーのライブ訓練実施（目安：〜3ヶ月）
机上訓練ではなく、実際にセカンダリ環境への切り替えを行う訓練を実施。訓練から設計の穴を発見し、改善につなげることが本質的な価値です。 - AI脅威を想定したセキュリティアセスメント（随時）
IAM設定の最小権限原則の徹底・MFAの全面適用・ログ分析の強化を中心に、専門家によるアセスメントを実施してください。 - 経営層への定期報告ガバナンスの構築（継続的に）
BCPとクラウドリスクを「IT部門だけの問題」にしないことが重要です。月次のリスク報告と四半期ごとのBCPレビューを経営層を含めた体制で実施してください。
「クラウドは止まらない」「マルチクラウドだから大丈夫」「BCPは昔作った」——これらの思い込みが、次の重大インシデントの温床となっています。
まずは小さな一歩から、確実に動き始めてください。
by 亀田 治伸
記事をシェア：