2026年7月15日（太平洋夏時間、日本時間では16日早朝）、Google Cloud（グーグルが提供するクラウド基盤サービス）のオランダ拠点で電源網の異常が発生し、冷却設備の停止を経て、europe-west4-a（オランダに置かれたアベイラビリティーゾーン、クラウド基盤を区切る運用上の最小単位）が最長14時間55分にわたり利用できなくなった[1][2]。影響を受けたのはNetApp Volumes（NetApp社のストレージ技術をマネージドサービスとして提供する仕組み）、VMware Engine（VMware基盤をマネージドで提供するサービス）、Bare Metal Solution（オンプレミス相当の物理サーバーをクラウド経由で使えるサービス）の3つで、いずれも8時間から13時間規模の停止に至った[1]。これらはオンプレミス資産をクラウドに寄せる企業が採用しやすいサービスであり、可用性の前提が一般的なクラウドサービスの感覚とは異なる点が今回浮き彫りになった。単一データセンターへの依存という構造的な論点は、マルチクラウドやマルチリージョンの冗長設計を検討するIT責任者にとって、契約前に確認すべき判断材料になる。
予備知識
- アベイラビリティーゾーン: クラウド基盤を区切る運用上の最小単位。同一リージョン内でも独立した障害ドメインとして扱われることが期待される
- VMware Engine（GCVE）: Google Cloud上でVMware vSphere基盤をマネージドサービスとして提供する仕組み
- Bare Metal Solution: オンプレミス相当の物理サーバーをクラウド経由のサービスとして利用できる仕組み
- NetApp Volumes: NetApp社のストレージ技術をGoogle Cloud上でマネージドサービスとして提供する仕組み
障害を前提に信頼性を設計するGoogle発の考え方を体系的に学べ、単一施設依存のような可用性の見落としを事前に洗い出す視点が身につく
何が起きたのか 電源網の障害が冷却停止を招いた経緯
今回の障害は、電源網の異常が冷却設備を巻き込み、データセンター内の温度上昇からサーバー保護シャットダウンに至った一連の連鎖である。データセンターの上流にある電力網で電気的な異常が発生し、施設内の配電設備と冷却設備の両方に影響が及んだ[3]。冷却機能が失われたことで、対象のデータホール内の気温は急速に上昇した[3]。温度上昇によって機器が損傷する前に、ホストサーバー、ストレージクラスタ、ネットワークスイッチが保護のため順次シャットダウンされた[3]。
障害の開始は太平洋夏時間7月15日16時39分（日本時間16日8時39分）、復旧完了は太平洋夏時間7月16日7時34分（日本時間同日23時34分）で、合計14時間55分を要した[2]。復旧作業では、Googleの技術者が第三者の施設運営会社と連携して主電源を復旧し、室温を安全な水準に戻したうえで、現地の支援要員と遠隔チームがサーバーホスト、ストレージノード、ネットワーク経路を管理された手順で順番に起動・検証した[3]。電源と冷却が同時に失われる障害は、単純な停電よりも復旧手順が長くなりやすい。
建物・電気設備・空調設備・ICT設備というデータセンターを支える4要素を平易に理解でき、電源と冷却が同時に失われる今回の障害の構造を捉えやすくなる
サービスごとの停止時間はなぜ異なったのか
停止時間はサービスの性質によって差があり、物理サーバーを扱うBare Metal Solutionが最も長く影響を受けた。NetApp Volumesの停止は8時間31分、VMware Engineの停止は9時間24分、Bare Metal Solutionの停止は約13時間に及んだ[1]。ゾーン全体としての影響時間は14時間55分であり、個別サービスの停止時間はこれより短い範囲に収まっている[1][2]。
| サービス | 停止時間 | 特徴 |
|---|---|---|
| NetApp Volumes | 8時間31分 | ストレージのマネージドサービス |
| VMware Engine | 9時間24分 | 仮想化基盤のマネージドサービス |
| Bare Metal Solution | 約13時間 | 物理サーバーを直接扱うサービス |
| ゾーン全体（影響期間） | 14時間55分 | 障害開始から完全復旧まで |
物理サーバーを個別に起動・検証する必要があるBare Metal Solutionは、仮想化レイヤーやソフトウェア制御で復旧できる範囲が狭く、手順が積み上がりやすい。順番に安全確認しながら起動する運用上、停止時間が長くなる構造は、物理ハードウェアに近いサービスほど共通して抱える課題といえる。
このインシデントの舞台はGoogle Cloud VMware Engine（GCVE、Google Cloud上でVMware vSphere基盤をマネージドサービスとして提供する仕組み）。影響を受けたのは、DR（Disaster Re[…]
なぜ単一データセンターへの依存が起きたのか 冗長設計の見落とし
NetApp Volumes、VMware Engine、Bare Metal Solutionの3サービスは、ゾーン内で単一のデータセンターに物理的に依存する構成だったことが、今回の障害範囲を広げた要因である[1]。一般的にクラウド利用者は、アベイラビリティーゾーンという単位そのものが複数施設に分散していると期待しがちだが、この3サービスはその想定に当てはまらなかった[1]。
Forrester Researchのアナリスト、Biswajeet Mahapatra氏は、この問題の本質を透明性の不足にあると指摘している[1]。クラウド事業者は一般に、可用性を高めるため複数ゾーンや複数リージョンの利用を推奨するが、個々のマネージドサービスがゾーン内で単一施設に依存しているかどうかは、利用者側から見えにくい[1]。専用ハードウェアやストレージ基盤に紐づくサービスは、AWSやAzureを含む主要クラウド事業者に共通して存在し、必ずしも複数施設に分散しているとは限らない[1]。
Azure OpenAI Service（マイクロソフトのクラウド上でOpenAI系モデルを推論APIとして提供するPaaS層のAIサービス）で、2026年5月29日、欧州のスウェーデン中部と豪州東部を中心に約7時間45分にわたる障[…]
読者は何を判断すべきか マルチクラウド冗長設計への示唆
特殊なマネージドサービスを採用する際は、ゾーン内の施設冗長性を契約前に確認し、代替手段をあらかじめ用意しておく判断が実務上の防御線になる。今回のようなBare Metal SolutionやVMware Engineのような専用ハードウェア型のサービスは、通常のクラウドサービスと同列の可用性を前提にできない可能性がある。
オンプレミス資産をVMware EngineやBare Metal Solutionに移行した企業ほど、単一障害点が生まれやすい構成になっていないか、既存契約を見直す価値がある。マルチクラウドや複数リージョンへの分散は、コストとの兼ね合いになるが、少なくとも障害発生時に何時間止まりうるかを事前に見積もっておくことが、事業影響の予測精度を高める。
MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]
よくある質問（FAQ）
今回の障害の直接的な原因は何か
データセンターの上流にある電力網で電気的な異常が発生し、配電設備と冷却設備の両方が同時に機能を失ったことが直接的な原因である[3]。冷却が止まったことで室温が急上昇し、機器保護のためのシャットダウンにつながった[3]。
影響を受けたのはどのサービスか
Google Cloud NetApp Volumes、VMware Engine、Bare Metal Solutionの3サービスで、いずれもオランダのeurope-west4-aゾーンにある単一のデータセンターに依存していた[1]。停止時間はそれぞれ8時間31分、9時間24分、約13時間だった[1]。
自社の構成が同様のリスクを抱えているか、どう確認すればよいか
契約しているマネージドサービスが、利用リージョンやゾーン内で単一施設に依存していないか、ベンダーに直接確認することが出発点になる。加えて、障害発生を想定した代替経路や切り替え手順を平常時に整備しておくことが実務的な備えになる。
まとめ
今回の障害の核心は、電源網の異常が冷却設備を道連れにし、温度上昇という物理的な限界がサービス停止の引き金になった点と、NetApp Volumes・VMware Engine・Bare Metal Solutionの3サービスがゾーン内で単一データセンターに依存していた点の2つにある。停止時間はサービスの性質によって8時間台から13時間規模まで幅があり、物理ハードウェアに近いサービスほど復旧に時間を要した。読者に求められる行動は、専用ハードウェア型のマネージドサービスを採用する前に施設レベルの冗長性をベンダーへ確認し、複数ゾーンや複数クラウドへの分散、障害時の代替手順を平常時から準備しておくことである。可用性は契約書の文言だけでなく、施設構成という物理的な実態まで踏み込んで判断する必要がある。
出典
[1] Google Cloud outage shows it’s still hard to understand hyperscalers’ real resilience regimes – The Register https://www.theregister.com/off-prem/2026/07/21/google-cloud-outage-shows-its-still-hard-to-understand-hyperscalers-real-resilience-regimes/5275405[2] Incident details – Google Cloud Service Health https://status.cloud.google.com/incidents/3BvH3LVGcupoYqV6F4Nw
[3] Google Cloud experiences outage after power and cooling failure in Netherlands data center – DataCenterDynamics https://www.datacenterdynamics.com/en/news/google-cloud-experiences-outage-after-power-and-cooling-failure-in-netherlands-data-center/
