IncidentHub の 2026 年上半期クラウド／SaaS 信頼性レポートは、1 月から 6 月にかけて 1,082 社の事業者にわたる 30,246 件の障害を記録しました。ピークは 5 月の 6,070 件、クラウド事業者というカテゴリだけで 86 社・4,723 件を占めます。レポートはこの半年をひとことでまとめています。依存リスク（dependency risk）——障害が制御プレーン、エッジと CDN、認証基盤、AI API を伝って下流へ連鎖したのです。

記憶しておきたい 3 つの事例

  • Railway、5 月 19 日、約 8 時間：引き金は Google Cloud による自動的なアカウント停止で、Railway の制御プレーン、API、データベースが停止し、すべての Railway ワークロードが到達不能になりました——同社自身のベアメタルや AWS 上で動いていたものを含めてです。ハードウェアが壊れたわけではなく、プラットフォームによる自動的なポリシー執行であり、レポートはこれを新興のリスク分類として個別に扱っています。
  • Google Cloud、デリー／ムンバイのデータセンター火災：インドリージョン関連のトラフィックに 21 日 12 時間の劣化が生じました。GCP の記録は半年で 2 件のみ——件数の少なさが影響範囲の小ささを意味しないことの証明です。
  • Azure、4 月 24 日、East US の制御プレーンが 12 時間超停止：ロック競合とフェイルオーバーの不完全さが関与しました。制御プレーンが落ちてもデータプレーンは動き続けることが多いのですが、作成・スケール・変更が一切できません——障害対応でまさに必要になる操作です。

もう 2 つの数字も控えておく価値があります。Cloudflare は上半期に 487 件の事象を記録し（4 月が最多で 98 件）、Hetzner のオブジェクトストレージは nbg1 で 27 日 16 時間、hel1 で 31 日 13 時間の劣化を経験しました。傾向としては短時間の障害が増えています——ニュースにはならないものの、監視の警報を背景ノイズへと変えてしまう類のものです。

制御プレーンとデータプレーンを分けて考える

多くの人は「事業者が落ちた」をサイトが表示されないことだと想像します。実際の被害はもっと厄介です。サイトは動き続けているのに、何ひとつ変更できない——スケールも、ファイアウォールの編集も、証明書の発行も、コンソールへのログインもできない。使える障害対応計画は、2 つの問いに別々に答えます。サービスが利用できないときどうするか、そしてサービスは正常なのに制御を失ったときどうするか。

依存関係図を描く（30 分もかからない）

第三者ごとに 1 行、列は 3 つ——それが落ちると何が壊れるか、置き換えにどれだけかかるか、代替はあるか。

  • DNS：CDN の事業者から最も引き離しておくべき項目です。DNS が別の場所にあってこそ、障害中の CDN を迂回できます。
  • CDN／リバースプロキシ：CDN なしでもオリジンが単独で応答できることを確認してください——証明書も含めてです。CDN の送信元レンジからの接続しか受け付けないオリジンは、CDN が問題になった瞬間に完全に到達不能になります。
  • 証明書の発行：ACME の更新失敗時に通知は届きますか。手動発行の予備証明書はどこかにありますか。
  • オブジェクトストレージとバックアップ：少なくとも 1 部は別のベンダーに置き、復元のリハーサルを済ませておくこと。単一事業者内のマルチ AZ はアカウント単位の事象を防げません。
  • アカウントと請求そのもの：期限切れの支払い方法、無効な連絡先、自動的なリスク判定——Railway の事例は、これだけですべてがゼロになりうることを示しています。請求先の連絡先、支払い方法、アカウントの確認状態を定期的に見直しましょう。
  • 帯域外アクセス：SSH の秘密鍵、コンソールの復旧コード、サポート窓口——障害を起こしたプラットフォームにログインしなくても参照できる控えはありますか。

素朴な独立 VPS が有用な最終防衛線になる理由

自前運用のほうが信頼できる、という主張ではありません。1 台にマルチ AZ はなく、壊れたハードウェアは壊れたままです。しかしマネージドサービスを積み上げた構成の中で、完全に自分が制御でき、直接 SSH でき、静的ページと基本的なサービスを単独で提供できるインスタンスは、復旧手順のなかで実に役立つ 1 コマになります。メンテナンスページの置き場、DNS 切り替え後の暫定オリジン、バックアップの 2 つ目の置き場です。SharkCloud は日本、シンガポール、香港、米国にノードを持っており、その予備インスタンスを主力プラットフォームとは別の事業者・別の地域に置くことは、依存関係図のなかで最も埋めやすいマスです。