少数のクラウド事業者への依存が招くカスケード障害
2025年10月、AWSとAzureが相次いで大規模障害を起こしました。少数のクラウド事業者への依存が生む構造的リスクと、企業が取るべき備えを解説します。
「サイバー脅威は外部の侵入者からもたらされるもの。」これを前提として、サイバーレジリエンス戦略を立てている組織が多いのではないでしょうか。攻撃者が境界を突破する。悪意のある人物が脆弱性を悪用して侵入する。こうした脅威に備える組織も多いはずです。
しかし実は、過去1年間に発生した深刻な障害の中には、攻撃者がまったく関与していないものもありました。その発端は、現在の世界経済を支えている少数のクラウド事業者の内部で行われた、わずか一つの設定変更や、潜在していたソフトウェアの不具合だったのです。
現代社会において、デジタルインフラが少数のハイパースケーラー（Amazon Web Services、Microsoft Azure、Google Cloudなど、世界規模でクラウド基盤を提供する巨大事業者）に集中したことで、効率性、拡張性、イノベーションの面では大きな恩恵がもたらされました。一方で、多くの組織がリスクモデルに十分織り込めていない、構造的な脆弱性も生み出されています。基盤となるプラットフォームが停止すれば、その影響はプラットフォームだけにとどまりません。その上に構築されたすべてのサービスが同時に影響を受けることになります。各サービスでどれほど慎重な設計が行われていたとしても。
日本企業は、主権クラウドを推進する政策や、厳格化する金融規制への対応も求められている一方で、こうしたグローバルなクラウドエコシステムに深く組み込まれています。私たちは、事業のどの程度が自社で管理できないインフラに依存しているのか、そして、そのインフラが停止した日に何が起きるのかという、経営層が向き合うべき問題を抱えているのです。
集中がもたらす問題
クラウド市場における集中の度合いは際立っています。ある調査によれば、2025年半ばの時点で、Amazon Web Services（AWS）、Microsoft Azure、Google Cloudの大手3社は、世界のクラウドインフラ支出のおよそ3分の2を占めており、AWSは約30％、Azureは約20％、Google Cloudは約13％とされています。これほど市場が集中している状況では、いずれか一社で発生した地域的な障害は、その顧客だけに影響する個別の問題ではありません。世界のインターネットの相当な部分を一度に機能低下させる可能性があります。
こうしたカスケード障害（連鎖的障害）が発生する技術的な仕組みを見てみましょう。
現代のクラウドサービスは、共有されたコントロールプレーン（control plane：クラウド全体の設定・管理・制御を担う中枢機能）の基盤機能に依存しています。具体的には、DNSによる名前解決、アイデンティティおよびアクセス管理、グローバルルーティングなど、数多くの下位サービスが依存する基盤的な機能です。これらの機能は、クラウド全体を結び付ける重要な役割を担っています。同時に、設計上、高度に集中管理されています。これらのいずれかに障害が発生すると、影響は単一のアプリケーションや顧客の範囲には収まりません。個々のサービスがそれぞれ高いレジリエンスを備えていたとしても、その基盤機能に依存するすべてのサービスへと障害が波及してしまうのです。
多くのレジリエンス戦略が見落としているのは、まさにこの点です。自社のアプリケーションを、高可用性を前提として設計し、複数のアベイラビリティゾーンに分散していたとしても、自社インフラよりさらに下層で発生したコントロールプレーンの障害によって、サービスが停止する可能性があります。
アプリケーション層で冗長化を行っても、基盤層に存在する脆弱性を防ぐことはできません。
この問題を如実に示す出来事が2025年10月に起きました。のちに「暗黒の10月（Dark October）」とまで呼ぶ人もいるこの期間、何があったのでしょうか？
暗黒の10月：2週間に2つの障害
2025年10月、わずか2週間の間に、最大手のクラウド事業者2社が相次いでコントロールプレーンのカスケード障害に見舞われ、広く利用されているアプリケーションや企業向けサービス、さらには公共機関までが利用不能となりました。
10月20日、AWSのUS-EAST-1リージョンを中心に、14時間以上に及ぶ障害が発生しました（AWSのリリース）。原因は、Amazon DynamoDBのDNS自動化処理に潜在していた競合状態であり、これによってリージョンサービスのエンドポイントに対するDNSレコードが空の状態になったとされています。なお、DNSとはインターネット上の住所録に相当し、人間が読み取れるホスト名を数値形式のIPアドレスに変換します。DynamoDBのように高頻度で利用される制御用APIの名前解決ができなくなると、それに依存するソフトウェア開発キットやコントロールプレーンの構成要素は、新たな接続を確立できなくなり、通常のオーケストレーション処理も停止します。
この障害はDynamoDB単体にとどまらず、EC2（仮想サーバー）・NLB（ネットワーク負荷分散）・Lambda（サーバーレス処理）・IAM（認証・アクセス管理）・ECS/EKS（コンテナ基盤）・Redshiftなど、カテゴリの異なる多数のサービスへと連鎖的に拡大しました。その結果、ゲーム、メッセージング、金融関連のアプリケーションを含む数千の顧客サービスが、部分的または全面的に利用できなくなりました。
その9日後の10月29日には、Microsoft AzureとMicrosoft 365の環境で、AWSとは別の世界規模のサービス低下が発生しました（Microsoftのブログ）。原因は、Microsoftのグローバルエッジ基盤であり、レイヤー7ルーティングとアプリケーション配信を担うAzure Front Doorのコントロールプレーンにおいて、2つのバージョン間の構成変更シーケンスが互換性のないメタデータを生成したことでした。この互換性のないメタデータは構成保護システムをすり抜けてグローバルに展開され、その後データプレーンの非同期処理における潜在的なバグを露呈させ、マスタープロセスのクラッシュを引き起こしました。これにより、Azure Front Doorを経由するサービスでタイムアウトや502、504のゲートウェイエラー、サインインの失敗が発生しました。
影響は、企業向けの生産性ツール（Microsoft 365、Teams）、ゲームネットワーク（Xbox Live、Minecraft）、航空会社のチェックインシステムにまで及びました。Microsoftは設定変更を凍結し、直近で正常に動作していた設定への復旧を試みましたが、マスタープロセスの再起動に約4.5時間を要し、データプレーンは10月30日00:05 UTCに完全復旧しました。また、安全性確認のため設定変更の制限は11月5日まで続きました。
参考：航空業界に見る集中依存リスクの実例 ここまで、少数のハイパースケーラーに多くの組織が集中的に依存している状態において、ハイパースケーラー側での設定ミスや不具合によって引き起こされるカスケード障害について触れました。そうしたシステム上のトラブルではなく、サイバー攻撃者が共通の依存先を標的にすることでも、同じ構造の被害が広範囲に波及します。1つの標的に対する侵害が業界全体へ波及する可能性を示した事例を紹介しておきます。 |
AIの普及によって問題が深刻化する可能性
今後の見通しも、自然に改善する状況にはありません。2026年に少なくとも二つの大規模なクラウド障害が発生するという予測もあります。その背景には、AI開発競争の複雑さによって負荷が高まる、老朽化したインフラがあります。ハイパースケーラーがAI分野での主導権争いに大量のリソースを投入する一方、その土台となる従来のインフラは、増大する複雑性のもとで不安定さを増しています。2025年の一連の障害は、懸念すべき傾向を明らかにしました。複雑性と相互依存性が高まるほど、復旧には時間がかかり、対応も困難になります。連鎖的な影響が完全に解消されるまで、数日を要することもあります。クラウドの拡大を推進しているのと同じ要因が、その脆弱性も高めているのです。
さらに、AIの普及によって問題の深刻さは一段と増しています。複数の調査やレポートが示すところによれば、組織が継続的なデータフローに依存する自律型システムを導入するにつれて、AI関連のダウンタイムは増加傾向にあり、技術責任者の多くがAIエージェントの予測不能な挙動が障害を引き起こすことを懸念しています。AIエージェントが取引の承認、配送経路の決定、顧客体験の個別化などをリアルタイムで行う場合、サービスの中断は、事業モデルが依存する自動化そのものを停止させます。AIが業務に深く組み込まれるほど、短時間の障害であっても許容することが難しくなります。
マルチクラウドという選択肢：単純な解決策ではない
集中リスクに対する直感的な対応は、「リスク分散」ではないでしょうか。複数のクラウド事業者を利用すれば、単一の障害によって事業全体が停止する事態を避けられるという考え方です。そのため、マルチクラウドというシステム冗長化の方法は明白な解決策として提示されることが少なくありません。しかし、実際の状況はそれほど単純ではないようです。この選択肢を評価する組織は、利点と課題の両方を理解する必要があります。
マルチクラウドには、確かな利点があります。決済処理のように継続的な可用性が不可欠なワークロードでは、複数の事業者に分散することで、一社の障害中もサービスを継続できる可能性があります。
2025年6月にGoogle Cloudの障害が発生し、SpotifyやCloudflareなど多くの企業が数時間にわたってサービス停止に見舞われました。そのなかで、ラテンアメリカの著名なeコマース・フィンテック事業者であるMercado Libreは、複数のクラウドで常時アクティブなワークロードを運用しており（参考）、影響を免れたと報じられています（参考）。同報道によれば、冗長化は受動的なものではなく能動的なものであり、障害が発生してから起動するフェイルオーバーではなく、平常時から複数事業者上で稼働するワークロードだったとされています。
しかしマルチクラウドは、追加コストなしに機能する解決策ではありません。マルチクラウド戦略が管理・ガバナンス上の課題を増大させ、複雑性とコストの面で単一クラウドを上回る可能性があります。通常、マルチクラウド管理は複雑さが増すので、正しく実装するためにはその分の時間とコストが掛かります。その複雑さは、ネットワーキング、自動化、データサービス、復旧可能性、セキュリティなど複数の技術領域にまたがります。それぞれの専門知識を持つ人材を確保し続ける必要も生じますが、そのような専門人材は希少であり、転職などによって流動しやすい存在でもあります。
また、実際に障害が起きた際の復旧経路も大幅に複雑になります。各クラウド事業者が独自の復旧プロセスを持つため、複数の事業者にまたがって運用する場合、事前に設定したRPO（Recovery Point Objective：目標復旧時点）およびRTO（Recovery Time Objective：目標復旧時間）の達成が難しくなることも考えられます。
マルチクラウドが誤っているということではありません。マルチクラウドは、スキル、テスト、運用規律への十分な投資を必要とする、本格的なアーキテクチャ上の選択であるということを、十分に理解しておく必要があります。
規制当局の動き：集中リスクへの危機感の表れ
このような一部のハイパースケーラーへの過度の依存と、それによって発生しうる障害に対し、各国・地域の規制当局も強い危機感を抱いていると見られます。ここでは、その一部を紹介します。
欧州連合のデジタル・オペレーショナル・レジリエンス法(DORA)は、2025年1月から全面適用されており、金融機関にサービスを提供する重要な技術事業者にまで監督を直接拡大しています。対象事業者には、堅牢なリスク管理体制、インシデント報告、定期的なレジリエンステストが求められています。違反した場合には高額な制裁金が課されます。2025年11月には、Amazon、Google、IBMを含む19社が、この「重要事業者」として指定されました。また、欧州の金融監督当局とイングランド銀行、英国のPRA(健全性規制機構)およびFCA(金融行為規制機構)は、こうした重要技術事業者の監督において連携する協力覚書を締結しており、規制の実務面でも国境を越えた対応が進んでいます。
日本においても、同様の方向性の動きが見られます。2024年10月、金融庁は「金融分野におけるサイバーセキュリティに関するガイドライン」を公表しました。その第２章は、国際的なフレームワークであるNIST CSF 2.0の「ガバナンス、特定、防御、検知、対応、復旧」という6つのフェーズに加えて、独立した項目「サードパーティリスク管理」を設けた7つの要素で構成されています。「サードパーティリスク管理」では、金融機関等に対し、外部委託先やクラウド事業者などのサードパーティ全体を対象としたリスク管理体制の整備を求めています。
金融庁は以前から、このリスクがシステム全体に及ぶ可能性を認識してきました。2023年4月のディスカッションペーパー「オペレーショナル・レジリエンス確保に向けた基本的な考え方」では、ITシステムへの依存の高まり、大規模な技術障害、クラウドサービスの広範な利用によって、リスク環境が複雑化していると指摘しています。また、予期しない事象が発生した際に、決済サービスなどの重要業務を維持するには、既存の事業継続計画では不十分な可能性があると警告しました。
重要なのは、金融庁が金融機関の委託先も監視しており、銀行法に基づいて、システムの開発や運用を担う第三者に報告を命じる権限を持っている点です（金融分野におけるサイバーセキュリティに関するガイドライン、2.6節）。つまり、規制当局の監督範囲は金融機関そのものを越え、その業務が依存する事業者にまで及んでいます。
クラウド集中リスクは、技術部門が目立たない形で管理する運用上の課題から、取締役会が説明責任を負う規制上の義務へと移行しつつあります。
まとめ：組織は何をすべきか
言うまでもないことですが、ハイパースケールクラウドの利用をやめることはほぼ不可能でしょう。それは現実的ではなく、多大なコストを伴ううえ、そもそもクラウド導入を促した実質的な利点まで失うことになります。必要なのは、レジリエンスを、調達、アーキテクチャ、エンジニアリング、経営層の説明責任にまたがる、測定可能な設計目標として扱うことです。そこから、いくつかの実践的な優先事項が導かれます。
• ベンダーだけでなく、依存関係を可視化する。特定のクラウド事業者を利用していると把握することと、重要業務が実際にどのコントロールプレーンの基盤機能に依存しているかを把握することは同じではありません。WEFの「Global Cybersecurity Outlook 2026」によると、サプライチェーン・エコシステムを包括的に可視化し、サイバー脅威にさらされるリスクや相互依存関係をより深く理解している企業は、わずか33%にとどまります。つまり、多くの企業が依存関係の一部を把握できないまま運用していることが推察されます。失うことが許されない依存先を特定することが、あらゆるレジリエンス対策の基盤となります。
• 実効性のある代替手段を構築し、検証する。待機系インフラを保持したり、フェイルオーバー手順を文書化したりしつつも、現実的な条件下で検証していない組織もあるのではないでしょうか。少数の重要サービスについて復旧訓練とフェイルオーバー試験を実施しておけば、数時間に及ぶ障害を、企業存続に関わる危機ではなく、コントロール可能な事象に変えられます。
• マルチクラウドをチェック項目ではなく、本格的な取り組みとして捉える。継続的な可用性が真に必要とされるワークロードでは、アクティブなマルチクラウドアーキテクチャが実質的なレジリエンスをもたらし得ます。しかし、それには複数事業者にまたがるスキル、テスト、運用能力への投資が必要です。表面的に導入すれば、障害が発生し得る領域を減らすどころか、増やしてしまう可能性があります。判断はワークロードごとに行い、導入によって生じるコストと複雑性を十分に考慮する必要があります。
• 集中リスクを取締役会レベルの課題として扱う。カスケード障害による影響は、売上、評判、サプライヤーエコシステム全体にまで及びます。調達部門と取締役会は、アプリケーション層のレジリエンスを顧客側だけの責任とする標準的なSLAを受け入れるのではなく、運用の透明性、定量化された是正措置への確約、ベンダーに実質的な説明責任を求めるための契約上の手段を要求すべきです。
• 早い段階からレジリエンスを規制上の期待に合わせる。 規制当局による対応がまだ罰則中心ではなく、ガイダンス中心である今の段階で、これらの基準を満たすレジリエンスを構築する方が、後になって監督上の圧力を受けながら改修するよりも、はるかにコストを抑えられます。特に日本の金融機関にとって、金融庁が定めるガイドラインは、実質的には基準になりつつあり、こうした業界の基準を参考にすることも1つの選択肢です。
次のカスケード障害を乗り越えられるのは、自社の依存関係を理解し、代替手段を実際に検証し、マルチクラウドを反射的に選ぶのではなく現実的に評価し、集中リスクを戦略上かつ取締役会レベルの課題として扱う組織です。目標は、ハイパースケーラーへの依存をなくすことではありません。それは現実的でも望ましくもありません。必要なのは、その依存の実態を十分に理解したうえで、障害が発生した日に備えた検証済みの計画を持つことです。
グローバルプラットフォームとの深い統合と、積極的な金融規制が交差する日本にとって、今行動すべき理由は明確です。このインフラは不可欠です。だからこそ、その脆弱点を検証しないままにしておくことはできません。
（関連記事）
・事例から考えるサービスサプライチェーンリスクによる影響とその対策
・クラウドサービスのリスク審査はなぜ疲弊するのか？～実態と業務のヒント～
・ソブリンクラウドとは？プライベートクラウドやガバメントクラウドとの違いを解説
Security GO新着記事
少数のクラウド事業者への依存が招くカスケード障害
（2026年9月30日）
2026年上半期の脅威動向を分析：自律AIによる「マシンスピードの脅威」
（2026年8月28日）
