クラウド障害8時間、稟議書に何を書くか

先週、Railwayという開発プラットフォームで大規模障害が起きたという記事を読みました。日本時間の2026年5月20日朝7時20分ごろから午後3時過ぎまで、約8時間にわたってサービス全体が落ちたという話です。原因はRailway自身のシステム障害ではありませんでした。Google Cloudが、Railwayの本番用アカウントを誤って一時停止したことが発端でした。

これを読んだとき、正直ぞっとしました。自分たちは製造業で、工場の生産ラインを直接クラウドに乗せているわけではありません。ただ、営業DX推進部として、SFA・CRM・社内ポータルなど、クラウドサービスへの依存度はこの3年でかなり高まっています。今は特定ベンダーのクラウドに相当な業務を集約していますが、「同じことが起きたら」と考えると、部下25名の業務が一斉に止まるシナリオは決してゼロではないと感じました。

「ベンダーのせい」では済まない構造

記事の中でRailwayが述べていた言葉が刺さりました。「利用者から見えるサービスはGoogle CloudではなくRailwayであるため、ベンダー選択を含めた可用性の責任はRailwayにある」という一文です。これはそのまま、私たちにも当てはまります。社内で何かトラブルがあったとき、「ベンダーが悪い」と経営陣に説明しても、「なぜそのベンダーを選んだのか」という話に必ずなる。ベンダー選定の責任は推進部門にあるわけです。

Railwayの障害で技術的に興味深かったのは、Google Cloud以外の基盤であるAWSや自社ベアメタル上のワークロードは動き続けていたという点です。それでもサービス全体が落ちたのは、ネットワーク制御プレーンがGoogle Cloudに一本化されていたからでした。つまり、複数のクラウドを使っているように見えても、制御系が一箇所に集中していれば意味がない。この構造を、自分たちのシステム選定にそのまま当てはめて考える必要があると思いました。

稟議書に「可用性要件」をどう書くか

私が今直面しているのは、来年度予算の稟議です。現行SFAのリプレイスを含む、クラウド関連投資の申請を秋までにまとめなければなりません。経営陣への説明資料を作るとき、これまでは「導入後の工数削減」や「営業データの可視化」を前面に出してきました。しかし今回の記事を読んで、可用性に関するリスク説明を追加しなければと感じています。

具体的に自分が稟議書に盛り込もうと考えているのは、次のような論点です。

• 採用予定のクラウドサービスが依存している下位インフラの構成
• 単一クラウドへの制御系集中がないか
• SLAに記載されている補償範囲と実際のビジネス損失のギャップ
• 障害発生時の代替手段・手動オペレーションの有無

これを整理して資料に落とすのは、ベンダーに追加ヒアリングをかける必要があります。先月、ベンダーから提案を受けた際には可用性の話はSLA数値の説明で終わっていました。99.9%というパーセンテージだけ見ていても、今回のRailwayのケースのように「誤操作で突然アカウントごと停止」という事態は防げません。SLAの数字と実際のリスク構造は別物だと、改めて認識しました。

部下への落とし込みをどうするか

私の部下には、クラウドのインフラ構成に詳しいメンバーが少ないです。営業出身のメンバーが多く、ツールは使えるけれど、その下で何が動いているかを意識している人はほとんどいません。これは責めることではなく、そういう組織構成にしてきた自分の判断の結果でもあります。

今回の障害事例を使って、近いうちにチームミーティングで「依存リスクの話」をしようと思っています。難しい技術の話をするつもりはなく、「朝出社したら使っているツールが8時間使えなくなったら何ができるか」という問いから始める予定です。バックアッププランを持たずにデジタルツールを使うことへの無自覚さを、まず共有したいと考えています。

息子が大学でITを少しかじっていて、先日帰省したときにクラウドの話になりました。「パパたちの会社、全部クラウドに移してるのに障害時の訓練ってやってないの?」と聞かれて、返答に詰まりました。稟議を通すことに集中しすぎて、運用段階のリスク訓練まで考えが及んでいなかった。その一言が、今回の記事と重なって頭に残っています。

あなたの会社では、クラウド障害時の代替手段を言語化できていますか。