「クラウドは落ちない」という思い込みが、業務停止リスクを見えにくくしています。2026年7月15日（現地時間）、Google Cloudのオランダ（europe-west4）データセンターが電力系統の障害で約15時間にわたって停止し、複数のエンタープライズ向けサービスに影響を及ぼしました。その6日後となる7月21日、GoogleはCloud Runの「自動クロスリージョンフェイルオーバー」機能を正式一般公開（GA）しました。これはサーバーレスアプリケーションが特定リージョンで障害を検知した場合、手動操作なしで自動的に別リージョンへトラフィックを切り替える仕組みです。今回の障害とGA発表は、企業がクラウド設計を見直す絶好の機会です。IT担当者が押さえておくべき背景・機能概要・導入時の考え方をわかりやすく解説します。
何が起きたのか——オランダデータセンター15時間停止の概要
Photo by Taylor Vick on Unsplash
2026年7月15日午後4時39分（PST）、Googleのオランダ・europe-west4-aアベイラビリティゾーンが停止しました。原因はデータセンター上流の電力グリッドで発生した電気的障害で、配電設備と冷却インフラが同時にダウン。急速に上昇したデータホール内の温度を受け、Googleはサーバー・ストレージ・ネットワークスイッチを安全のためにシャットダウンせざるを得ませんでした。
影響を受けたサービスは以下の通りです。
・Google Cloud VMware Engine
・Bare Metal Solution
・Google Cloud NetApp Volumes
これらは同月16日午前7時34分（PST）に復旧しましたが、障害継続時間は約14時間55分に達しました。Cloud Run自体は今回の障害を直接受けたサービスには含まれていませんでしたが、「単一リージョン依存」の危険性を如実に示したインシデントとして業界に大きな警戒感をもたらしました。クラウドであっても物理的な電力・冷却インフラに依存している以上、こうした障害は起き得るという事実を改めて認識する必要があります。
Cloud Run 自動フェイルオーバーGA——何が変わったのか
2026年7月21日にGAとなった「Cloud Run サービスヘルス（Service Health）」機能は、サーバーレスアプリケーションに自動クロスリージョンフェイルオーバーをもたらします。主なポイントを整理します。
【仕組み】
Cloud Runのコンテナインスタンスごとにレディネスプローブ（Readiness Probe）を設定すると、インスタンス単位のヘルス状況が収集され、リージョン全体の健全性として集約されます。この情報をサーバーレスNEG（Network Endpoint Group）が受け取り、グローバル外部Application Load Balancerが不健全なリージョンを検知した際に自動でトラフィックを健全なリージョンへ切り替えます。リージョン復旧後は段階的に元のリージョンへ戻す「フェイルバック」も自動で行われます。
【コスト】
追加料金なし。レディネスプローブで消費するCPUとメモリの通常コスト範囲内で利用できます。
【対象範囲】
Google Cloudの全Cloud Runリージョンで利用可能。外部向け（グローバル外部ALB）と内部向け（クロスリージョン内部ALB）の両方に対応しています。
切り替えは数秒以内に完了する設計とされており、障害時の業務影響を大幅に短縮できます。
企業が今すぐ確認すべき「マルチリージョン設計」の基本
Cloud Runの自動フェイルオーバーを活用するには、事前に適切なマルチリージョン構成を整えておく必要があります。まだ単一リージョンで運用している組織は、以下のポイントを確認してください。
1. リージョン依存度の棚卸し
自社が利用しているGoogle Cloudサービスがどのリージョンに依存しているかを一覧化します。単一リージョン（例：asia-northeast1のみ）で構成されているサービスは障害時に完全停止するリスクがあります。
2. Cloud Runのマルチリージョン展開
同一のサービス設定を複数リージョンにデプロイします。その上でグローバル外部Application Load Balancerを設定し、トラフィックを分散させます。
3. レディネスプローブの設定
コンテナが実際にリクエストを受け付けられる状態かをチェックするレディネスプローブをHTTPまたはgRPCで設定します。これによってサービスヘルスが有効化されます。
4. 内部トラフィックの考慮
社内システム間通信（プライベートネットワーク）の場合はクロスリージョン内部ALBを利用します。
既存のCloud Run利用者は、Google Cloudコンソール上で「Service Health」タブから設定状況を確認することができます。
クラウド障害から企業を守る「3つの教訓」
今回のオランダ障害とCloud Run GAの組み合わせは、企業のクラウド運用に重要な示唆を与えています。
教訓① SLAは「停止しない保証」ではない
クラウドベンダーのSLAは稼働率目標であり、99.9%のSLAでも年間約9時間の停止を許容します。今回の約15時間障害はSLA違反に相当する可能性がありますが、SLA補償（月額費用の一部クレジット）は実際の業務損失をカバーしきれません。SLAを信頼しつつも、独自の冗長化設計は必須です。
教訓② 自動化されていない冗長化は「冗長化」ではない
手動でのリージョン切り替えは、障害発生から担当者が気づくまでのタイムラグが生じます。自動フェイルオーバーによって初めて「実効的な冗長化」が実現されます。
教訓③ 物理インフラのリスクを忘れない
今回の原因は電力グリッドの電気的障害という、クラウドとは無関係に見えるインフラ障害でした。クラウドも物理施設に依存しているため、データセンターの地理的分散（別の電力系統・地域に属するリージョンの選択）も冗長化設計では重要な視点です。
まとめ——クラウド可用性設計を「後回し」にしない
Google CloudのCloud Run自動フェイルオーバーGA（2026年7月21日）は、サーバーレスアプリケーションの可用性を大幅に高める重要なアップデートです。特別な追加料金なしで利用できる点は、中小規模のIT部門にとっても導入ハードルが低く、積極的に検討する価値があります。
この機能の恩恵を最大限に受けるために、まず自社のCloud Run利用状況を確認し、単一リージョン依存になっていないかをチェックすることから始めましょう。
今日からできるアクション
・GCPコンソールでCloud Runの現在のリージョン構成を確認する
・業務クリティカルなサービスについてマルチリージョン展開の計画を立てる
・レディネスプローブの設定方法をGoogle Cloud公式ドキュメントで確認する
・クラウドインフラ全体の「障害時影響マップ」を作成し、経営層・事業部門と共有する
クラウドサービスの信頼性に依存しながらも、万が一に備えた設計を自社で持つことが、現代のIT担当者に求められる重要なスキルとなっています。
よくある質問
Cloud Runの自動フェイルオーバーは追加料金がかかりますか？
いいえ、追加料金はかかりません。レディネスプローブが消費するCPUとメモリの通常コストの範囲内で利用できます。全てのCloud Runリージョンで利用可能です。
Cloud Run以外のGoogle Cloudサービスも自動フェイルオーバーに対応していますか？
今回GAとなったのはCloud Runの「サービスヘルス」機能です。他のサービス（GCE、GKEなど）ではそれぞれ異なる高可用性設計の手法があります。今回のオランダ障害で影響を受けたVMware EngineやBare Metal Solutionは別途冗長化設計が必要です。
マルチリージョン構成にするとデータの一貫性に問題は起きませんか？
アプリケーションの特性により異なります。ステートレスなAPIやWebアプリは比較的容易に対応できますが、データベースを含む場合はリージョン間レプリケーションの設計が必要です。まずはステートレスなサービスから段階的にマルチリージョン化することを推奨します。
今回のオランダ障害でCloud Run自体も影響を受けましたか？
いいえ、今回の障害でCloud Run自体は影響を受けていません。影響サービスはCloud VMware Engine、Bare Metal Solution、Cloud NetApp Volumesの3つです。ただし今回の事例はCloud Run利用者も含め、マルチリージョン設計の重要性を再確認する機会となっています。