導入：CloudFront障害は「IT部門だけの問題」ではなくなった
Amazon CloudFront（以降CloudFront）の障害により、PayPayやnote、ニコニコ、はてなブログなど複数のサービスで接続しづらい状況が報告されました。時期を同じくしてマイナポータルでもログイン障害が確認され、行政サービスへの波及が注目されました（因果関係は公式発表を要確認）。
決済、行政、情報発信など生活に近いサービスがクラウド基盤に依存する現在、CloudFrontなど「入口」系の障害は単なる技術問題ではなく事業継続リスクです。自社のWeb、EC、予約、決済、ログインは「止まらない」と言い切れますか。CloudFrontやCDNが止まったときに、顧客に何を案内し、誰が判断するかを決めておく必要があります。
この記事でわかること
- CloudFront障害で何が起きたのか（非エンジニア向けの解説）
- クラウド依存がBCP上のリスクになる理由
- 企業が今すぐ見直すべきBCP項目（実務ベース）
- 障害発生時のステップ・バイ・ステップ対応手順
- そのまま使えるクラウド障害BCPチェックリストとFAQ
結論：止まる前提で「止まっても続ける設計」を作る
クラウドを使うこと自体が問題なのではなく、特定のクラウドサービスや入口に依存したまま、止まったときの代替策を準備していない状態がリスクです。BCPでは「止めない設計」だけでなく、「止まっても最低限の業務を続ける設計（代替経路、告知、社内フロー）」を優先的に整備してください。
CloudFront障害で何が起きたのか
CloudFront障害の概要（非エンジニア向け）
CloudFrontはAWSのCDN（コンテンツ配信網）で、ユーザーとWeb/アプリの間に立つ「入口」の役割を担います。高速化・負荷分散・キャッシュ・セキュリティ対策に使われます。入口側が不調になると、アプリ本体が正常でもユーザーが到達できず「つながりにくい」状態が発生します。
影響を受けたサービスの傾向
影響はCloudFront経由でコンテンツを配信している多数のサービスに広がりました。決済、メディア、ブログプラットフォームなど、ユーザー接点をCloudFrontで持つサービスが特に影響を受けます。マイナポータルの事象は時間帯が重なり注目されましたが、因果関係は各社・AWSの公式発表を確認してください。
CloudFrontとは？非エンジニアにもわかる仕組み
入口（玄関口）としての役割
ユーザーがWebにアクセスする際、多くのケースでCDNを経由します。CDNは世界中に分散した拠点から最短経路でコンテンツを配るため、表示速度や耐障害性を高めます。ここが止まると、「店舗のシャッターが閉まっている」のと同じ状態になります。
他の共通依存点
- DNS：ドメイン解決ができないと接続できない
- 認証基盤：ログイン不可で会員サービスが停止
- 決済基盤：購入・支払いができない
- SaaS/API：外部サービス停止で業務フローが止まる
決済・行政サービスへの影響が示したクラウド依存の現実
決済サービス停止の影響
- 実店舗でキャッシュレス決済が使えない→売上損失
- 店員の手続きの混乱、返金や手動処理の発生
- 顧客への案内（現金への誘導や他決済の提示）が必要
行政サービス停止の影響
- ログイン・申請の遅延→住民の不便・説明責任発生
- 代替の窓口案内や郵送手続きの準備が必要
このようにクラウド障害は、個別企業の損失にとどまらず社会インフラとしての機能に波及する可能性があります。
なぜクラウドを使っていてもBCPが必要か
クラウドは万能ではない
大手クラウドでも障害は起こります。高可用性は「設計と運用」の結果であって、自動的に付与されるものではありません。利用者側にも可用性を高める設計・運用の責任があります。
「クラウド事業者側の障害だから仕方ない」では済まない
顧客から見れば「自社サービスが使えない」事実が重要です。問い合わせ対応、返金・補償対応、広報は自社の責任領域であり、事業継続計画（BCP）に含める必要があります。
企業がBCPで見直すべき5つの項目（実務チェック）
1. 外部依存サービスの棚卸し
まず依存関係を可視化します。対象例：
- クラウド（AWS/Azure/GCP）と利用サービス（例：CloudFront、S3、ELB）
- CDN、DNS、WAF、認証基盤
- 決済サービス、メール配信、監視、SaaS業務ツール
- 外部API、パートナー連携
2. 業務影響度分析（BIA）の見直し
どの機能が止まると業績・顧客満足に直結するかを評価し、停止許容時間を定義します。
3. RTO・RPOの現実的な再設定
RTO（復旧目標時間）：どれくらいの時間で復旧すべきか。
RPO（復旧目標時点）：どの時点までのデータを復旧対象にするか。
すべてを同じ目標にするのではなく、重要度に応じて差をつけます。
4. 復旧優先順位を決める
- 顧客告知ページ（情報発信の確保）
- ログイン・認証
- 決済処理
- 注文・予約処理
- 問い合わせ窓口（CS）
- 管理者向け操作（バックオフィス）
- 分析・レポート
5. 社内外の連絡フロー整備
担当者と判断フローを明確にします（情シス→BCP責任者→経営→広報/CS/営業）。発信チャネルとテンプレートを用意しておくと初動がスムーズです。
CDN障害に備える技術的対策（実践的）
別CDNへの切り替え（要事前準備）
CloudFront以外のCDNを代替として準備します。ただし証明書（TLS）、DNS設定、WAFルール、キャッシュパスの整合性を事前に合わせておく必要があります。シンプルな形としては「重要ページだけ別CDNで配信する」方式が現実的です。
DNSフェイルオーバー
DNSレコードを切り替えて別オリジンへ誘導する仕組み。TTLの設定や切替手順、切替にかかる時間を事前に把握し、定期的に切替訓練を行ってください。
緊急用の静的ページを別クラウドに常設
サービス本体が到達不可でも、障害情報を出せるように別クラウドや別CDN上に静的な告知ページを用意します。復旧見込みや代替手段、問い合わせ先を明記しておくと顧客の不安を軽減できます。
認証・決済・メール配信の代替策
- 認証不可時は「一時的な利用制限」やメールによる本人確認フローを用意
- 決済停止時は別決済（他カードブランド、リンク決済、銀行振込）の案内を事前準備
- メール配信停止時はSNSやWeb告知、CSによる電話案内を併用
監視と外形監視の強化
AWSのHealth Dashboardや各ベンダーの障害情報ページだけでなく、自社のユーザー視点（外形監視）を複数ロケーションで実装し、SNSや問い合わせ件数の増加も重要なアラート指標としてください。
障害発生時の社内・顧客対応フロー（ステップ・バイ・ステップ）
初動のチェックリスト（5分以内）
- 監視やCSからの報告で問題を確認
- まずは「自社起因 vs 外部起因」を切り分け（ログ・監視・外形監視の確認）
- 影響範囲（全ユーザーか一部か、機能範囲）を暫定把握
- 暫定対外告知（緊急告知ページ・SNS）を準備
- BCP責任者へエスカレーション
社内連絡の流れ（例）
- 情シス：一次調査（ログ、外形監視、ベンダーステータス）
- BCP責任者：影響範囲・復旧見込みを判定（暫定）
- 経営/法務：必要な判断（補償・取引先対応）
- 広報/CS：告知内容作成・承認
- 告知発信：Web/SNS/メールで周知
顧客告知で必ず入れる項目
- 発生している事象（簡潔に）
- 影響を受ける機能
- 自社起因か外部起因か（判明している範囲で）
- 現時点での対応策（代替手段や回避方法）
- 次回更新予定時刻と更新チャネル（公式ページ・SNSなど）
- 問い合わせ先（CSチャネル）
告知テンプレート（短文）
現在、外部クラウドサービスの障害により、一部機能が利用しづらい状況が発生しています。影響範囲は調査中です。復旧状況は本ページおよび公式SNSで随時お知らせします。ご不便をおかけし申し訳ございません。
マルチクラウドだけでは解決しない理由
マルチクラウドは特定ベンダー依存を下げる効果がありますが、コスト・運用負荷・データ同期・認証連携などの課題も大きいです。全てを二重化するより、重要導線（告知・ログイン・決済・問い合わせ）を優先的に保護する方が現実的で効果的です。
現実的な選択肢の例：
- 重要ページだけを別CDNで配信
- 緊急告知ページを常時別クラウドにホスティング
- 決済手段を複数化（主要代替案を明示）
- 年1回以上の切替訓練を実施
クラウド障害BCPチェックリスト（そのまま使える）
依存関係の確認
- 利用中のクラウド／サービス一覧が最新か
- CDN、DNS、WAF、認証、決済、メール配信の依存先が明確か
- 各ベンダーの障害情報URL・連絡先・SLAを管理しているか
技術対策の確認
- CloudFront障害時の代替経路（別CDN/別オリジン）の設計・手順があるか
- DNS切替にかかる時間（TTL含む）を把握しているか
- 代替環境で証明書やWAF設定が適用できるか
- 緊急用静的告知ページを別クラウドで用意しているか
- 外形監視を導入しているか
業務継続の確認
- 最低限継続すべき業務が定義されているか
- サービス別のRTO/RPOが設定されているか
- 決済停止時の代替案（現金・別決済）の手順があるか
- 手作業で代替可能な業務をリスト化しているか
組織対応の確認
- 障害時の責任者・代行者が定められているか
- 情シス／広報／CS／営業／経営の連絡フローが文書化されているか
- 告知テンプレートを用意しているか
- 年1回以上の障害対応訓練を実施しているか
一次情報の確認（E-E-A-T対応）
障害の詳細や範囲はAWSの公式サイト（AWS Health Dashboard）および各サービスの障害情報ページ、公式SNSで必ず確認してください。事実関係は一次情報を基に社内リリースを組み立てると信頼性が高まります。
よくある質問（FAQ）
Q1. CloudFront障害時にすぐできる簡単な対応は？
A. まず緊急告知ページを別クラウド（例：GitHub Pages、別CDN）で表示し、状況と代替手段を伝えます。CSチームに簡単な案内文を配布して電話対応やSNS対応を統一します。
Q2. 別CDNはどの程度用意すべきですか？
A. すべてを二重化する必要はありません。まずは「重要導線（告知ページ・ログイン・決済）」の一部を別CDNで保護することを優先してください。
Q3. DNS切替は本当に有効ですか？
A. 有効ですが、DNSのTTLやキャッシュ、プロバイダ依存で即時反映されない場合があります。事前に切替手順と所要時間を把握し、訓練しておくことが重要です。
Q4. マルチクラウドに移行すべきですか？
A. マルチクラウドは有効な手段ですがコスト・運用負荷が増えます。まずは重要導線の保護と代替手順の確立から始め、コスト対効果を見て段階的に進めることをおすすめします。
まとめ：クラウド依存時代のBCPは「止まっても続ける設計」へ
CloudFront障害は、共通基盤の一部が不調になると多数のサービスに同時影響が出る現実を示しました。重要なのは「クラウドだから安心」と盲信することではなく、障害を前提にした設計・運用です。技術的な復旧手順に加え、顧客告知、社内連絡、代替業務、経営判断まで含めたBCPを整備してください。
最後に：障害情報は逐次更新されます。AWS Health Dashboardや各サービスの公式発表を一次情報として確認し、社内外の意思決定・告知に反映してください。
