世界を動かす技術を、日本語で。

インシデントレポート:2026年5月19日 – GCPアカウントの停止

概要

  • 2026年5月19日から約8時間、RailwayはGoogle Cloudの誤ったアカウント停止により全サービス停止
  • 主要なAPI、ダッシュボード、ネットワークインフラが影響を受け、全ワークロードが停止
  • キャッシュ切れにより他クラウドにも障害が波及
  • 復旧には複数段階を要し、GitHub連携にも一時的な制限が発生
  • 今後の再発防止策とアーキテクチャ改善を実施予定

Railway 全面障害発生レポート(2026年5月)

  • 2026年5月19日22:20 UTCから約8時間、 Google Cloud による誤ったアカウント停止により Railway のプラットフォーム全体に障害発生
  • API、ダッシュボード、コントロールプレーン、データベース、Google Cloud上のコンピュート基盤が全て停止
  • ユーザーはダッシュボードやAPIで 503エラー ("no healthy upstream"や"unconditional drop overload")を即時体験、ログイン不可状態
  • Google Cloud上のワークロード全停止、Railway MetalやAWSの一部ワークロードは一時的に稼働継続
    • ただし、エッジプロキシがGoogle Cloud上のコントロールプレーンAPI依存のため、ネットワークルートキャッシュ切れ後はこれらも404エラーで到達不能
  • 復旧作業中、ビルド・デプロイは全体で一時停止、復旧後はバックログを段階的に処理
  • キャッシュクリアの影響でGitHubはRailwayのOAuth・Webhook連携をレート制限、一時的にログインやビルド不可
  • 利用規約受諾記録もリセットされ、ユーザーは再受諾が必要に

インシデントタイムライン

  • 5/19 22:10 UTC:自動監視がAPIヘルスチェック失敗を検知、担当者へ通知
  • 5/19 22:11 UTC:ダッシュボードが503エラー、ユーザーがログイン不可
  • 5/19 22:19 UTC:原因特定、Google Cloud PlatformがRailway本番アカウントを停止
  • 5/19 22:22 UTC:Google CloudにP0チケット提出、アカウントマネージャーと直接連絡
  • 5/19 22:29 UTC:インシデント宣言、GCPアカウントアクセス回復(計算インスタンス・ディスクは停止状態)
  • 5/19 22:35 UTC:キャッシュルート切れ始め、Metal/AWSも404エラー返却
  • 5/19 23:09 UTC:最初のディスクが復旧
  • 5/19 23:54 UTC:全ディスクが復旧、ネットワークは未復旧
  • 5/20 00:39 UTC:ディスク準備完了、ネットワーク復旧待ち
  • 5/20 01:30 UTC:計算インスタンス復旧開始
  • 5/20 01:38 UTC:エッジトラフィック復旧、ネットワーク復旧
  • 5/20 01:57 UTC:オーケストレーション・ビルド基盤復旧、デプロイ一時停止
  • 5/20 02:04 UTC:計算ホスト段階的に復旧
  • 5/20 02:47 UTC:GitHubがOAuth/Webhook連携をレート制限、一部ユーザーがログイン・ビルド不可
  • 5/20 02:55 UTC:ダッシュボード再利用可能
  • 5/20 03:59 UTC:全階層でデプロイ処理再開
  • 5/20 04:00 UTC:API、ダッシュボード、OAuthエンドポイント正常化
  • 5/20 06:14 UTC:インシデント監視フェーズ移行
  • 5/20 07:58 UTC:インシデント解決

障害原因の詳細

  • 5/19 22:20 UTC、Google CloudがRailway本番アカウントを 自動処理で誤って停止
    • 複数アカウントに影響、事前連絡なし
  • この停止により、 ダッシュボード、API、ネットワーク制御、バースト計算基盤 などGCP依存インフラが全停止
  • コントロールプレーンAPI停止により、エッジプロキシのルートテーブルが更新不可となり、キャッシュ切れ後に他クラウド(Metal/AWS)も到達不能
  • 高可用性設計(マルチAZ、冗長ネットワーク)でも、 アカウント復旧だけでは個別サービス復旧不可
    • ディスク、計算、ネットワーク各レイヤーで個別復旧が必要で、復旧に数時間を要した
  • 復旧中、GitHub連携がリトライ急増により レートリミット、ログイン・ビルドに影響
  • 5/20 04:00 UTC時点で主要サービス復旧、残りワークロードも順次回復

再発防止策と今後の改善

  • コントロールプレーンは マルチAZ・マルチゾーン で設計済み、ユーザー影響最小化を目指す
  • しかし、 ネットワーク制御APIがGCP上に依存 しており、キャッシュ切れ時に全体障害へ波及
  • 今後、この依存を排除し、 真のメッシュ構成 へ移行予定
    • どのクラウドが停止しても他クラウド経由で必ずルートが確保できる設計へ
  • 高可用性データベースシャードを AWS・Metalへも拡張、どのクラウド全停止でも即時フェイルオーバー可能に
  • Google Cloudサービスをデータプレーンのホットパスから除外、セカンダリ/フェイルオーバー用途のみに
  • 新アーキテクチャ(データプレーン・コントロールプレーン)を導入し、 単一ベンダ依存の排除 とユーザー向けサービスの堅牢化を図る
  • ベンダ選定・運用責任はRailwayにあり、 ユーザー体験・稼働率の責任を全うする方針

参考リンク

  • 前スレッド: Incident Report: Railway Blocked by Google Cloud [resolved] https://news.ycombinator.com/item?id=48201484

Hackerたちの意見

鉄道業界は、最近のテックプレスであまりいい月じゃなかったよね?どちらの場合も、他の誰かの自動化されたプロセスが原因で、評判を傷つけられたみたい。Gemini CLIの件についてGoogleの担当者と話そうと思ってたけど、こっちの方が心配だわ。

他の誰かのプラットフォームの上に構築するのは常にリスクがあるし、他の誰かのプラットフォームの上にプラットフォームを構築するのはさらにリスキーだよね。うちの会社は、基本的にはAWSにいくつかの追加保証をつけたホスティングプロバイダーを使ってたけど、今は必要なものを直接提供してくれる通常のAWSに移行したばかり。

AIに管理者権限を与えて、彼らの本番データベースを削除させた場合、それは彼らの責任だよ。彼らだけが管理者アカウントの認証情報をAIに入力したんだから。その後、個人的な責任を全く取らなかった。それは確実に彼らの評判を傷つけたね。ここでは、少なくとも彼らは責任を取ってる。改善してるのは評価できるよ。それに、GCPには本当に深刻な信頼性の問題があるし、Googleには顧客サポートの問題もある。

Google Cloudが顧客のアカウントを本気でめちゃくちゃにしたのは、これが初めてじゃないよね。https://cloud.google.com/blog/products/infrastructure/detail...

質問:小規模なSaaSツールや内部製品について。もしチームがAWSや他のIaaSプロバイダーを管理したくない場合、以下の選択肢の中でベストな代替は何?1.) Vercel - 今月は調子悪い 2.) Supabase - 今月は調子悪い 3.) Railway - 今月は調子悪い

Railwayは使ったことないけど、Herokuに似たものだって聞いたよ。Fly.ioはそのニッチな分野の小さなプロジェクトにはかなり良かった。Vercelについては、Next.jsのサイトが静的にコンパイルできるなら、ほぼどんなものでも上げられると思う。以前は自分たちでホスティングしてたけど、設定が簡単だけど、画像の最適化とかは結構手間がかかるよね。

DigitalOceanだよ。マジで。彼らは長い間存在していて、毎日頼りにしているコアインフラの多くを構築してきた(例えば、Cephとか)。

FlyやRender、Herokuの方がRailwayよりもずっといい選択肢だと思う。

何を作ってるかによるけど、これらは全部VPSみたいなもんだね。慣れてないとマシンの管理やセキュリティの負担がちょっとあるけど、他の人も言ってるようにNext.jsはセルフホスティングできるよ。サーバーレスやエッジの機能が必要なければ、Cloudflare Workersに行くのがいいと思う。

もしIaaSを直接使えないなら、自分のサービスがダウンする可能性を受け入れなきゃいけないよ。AWSみたいなものを使っても、複数のAZに冗長性を持たせてないなら、時々ダウンタイムがあるからね。それに、複数のAZで冗長性を持たせても、AWSは完全に孤立してるわけじゃないから、サービスが失敗することもある。だから、ダウンタイムは受け入れて、自分に合った最適なツールを使うべきだよ(本当にひどい場合、例えばGitHubレベルのひどさじゃない限り)。ダウンタイムを全く受け入れられないなら、何百万ドルもかけて、ダウンタイムがないことを期待できる自信を持つために数ヶ月の作業が必要になるよ。Netflixのカオスモンキーやインフラがあれば十分だね。

Hetzner(またはどのVMプロバイダーでも)+ Dokkuが一番いいよね。

ここでのメッセージは、どのクラウドプロバイダーも一つだけじゃ信頼できないってことだと思う。少なくとも、完全な運用能力を持つ二つは必要だよ。

VPSとかどう?管理が簡単で、ずっと安いし。でも、実際にはどんなサービスでも(オンサイトホスティングでも)ダウンタイムがあるから、それが許容できないなら、複数の地理的に分散したホスト間で分散できるツールを作るか使うのがベストな選択かもね。

仲介者は価値を提供できるけど、リスクもあるから、AWSやGCPなどを直接使いたくない理由を考えた方がいいよ。主要なクラウドプロバイダーは、Railwayがやってることより少し難しいだけのサービスを提供していて、ニーズが拡大するにつれてより高度なものに成長できるんだ。機能やセキュリティ、可用性をコントロールする第三者を加えずにね。例えば、GCPはタイムラインによると7分以内に対応したみたい。Cloud Runを使ってたら、ダウンタイムを7時間以上減らせたかもしれないし、もし未知のトリガーイベントが他の顧客のアクティビティやRailwayの奇妙な行動に関連してたら、そもそもダウンしなかった可能性も高いよ。複雑さの要素もあるし、彼らが修正しなきゃいけなかった複雑なインフラの量を考えてみて。自分のアカウントには必要ないものだよね。そのコードは役に立つことをしてると思うけど、ホスティングプロバイダーが必要とする多くの動く部分があって、あなたには必要ないものなんだ。このダウンタイムはみんなを巻き込んだけど、個々のAWSやベアメタルユーザーは影響を受けなかっただろうね。誰にとっても同じグローバルな最適解はないけど、開発者は他人の環境で作業する際の直接的なコストやあまり明らかでないコストに比べて、デプロイのステップをいくつか省くことでどれだけ時間を節約できるかを過大評価しがちだと思う。

「最後に、私たちはデータプレーンのホットパスからGoogle Cloudサービスを削除する計画を立てており、二次的なものやフェイルオーバー用にのみ保持します。」って、かなり明確だよね。GoogleはもはやB2Bサービスプロバイダーとして信頼できない。

それは無理だね。Googleは、あなたの従業員の一人が個人アカウントで何か悪いことをしただけで、会社全体をブロックするかもしれないし、その禁止措置は強力で、関連するアカウントを徹底的にブロックするから。

もっと多くの企業がこのメッセージを聞くべきだよ。Googleは何度も信頼できないサービスプロバイダーだって証明してるから、まさにこの問題が原因なんだ。

彼らはまだお金を渡すくらい信頼してるんだね。これが大手テック企業がどれだけ根深いか、そしてなぜ分割される必要があるのかを示してる。

彼らはアカウントが停止された理由を説明していない。それが一番重要な部分だと思う。クラウドプロバイダーは理由もなくアカウントを停止することはないからね。

Metaも同じだよ。ある会社は、MetaにあるOAuthアプリが完全に使えなくなったんだけど、それはその社員(開発者)の個人Facebookアカウントが理由もなくMetaに禁止されたからなんだ。何度もエスカレーションしようとしたけど、全然進展しなかった、笑。Metaはさらにひどくて、アカウントは「個人」でなければならない。ビジネスマネージャーを持ってると、そこに追加されたユーザーはみんなその人の個人Meta/Facebookアカウントに結びついてる。これっておかしいよね。

RailwayはGoogleに責任を押し付ける圧倒的なインセンティブがあるよね。このレポートは、なぜGoogleがRailwayのアカウントを停止したのかを答えてない。判断する前にもっと詳細を待った方がいいと思う。

Railwayはスケーラブルなシステムを構築するのが得意じゃないみたい(雰囲気コーディングの影響?)。結論を急ぐ前にGoogleの返答を待つ価値はあるよ。AzureやAWS、自前のデータセンターに移行することもできるけど、数ヶ月後にまた同じことが起こる可能性が高いと思う。

どのクラウドプロバイダーも問題を抱えてない? サービスの劣化は本当にGoogleだけの問題なのか、それともみんな運命を共にしてるのか。

Googleが説明もなくアカウントを停止したり、終了させたりするのは何年も前からの話だよね。ユーザーが不満を表明して、その件がバイラルになると、結局は撤回することが多いし。Googleは、払ってる顧客に対して何の義務もないかのように振る舞ってる。

面白いけどまだ説明されてないのは、なぜGoogleがアカウントをフラグしたのかってことだね。観察したことに関するタイムスタンプをポストモーテムに入れても、根本的な原因には触れてない。ストーリーの「これおかしいよね」って部分には、誰もまだ明かしたくない本当の説明があると思う。

Googleはこのインシデントレポートに不満があるなら、ちゃんと答えるべきじゃない?Railwayがそれを知ってるかどうかも確かじゃないし。

ここでGoogleが言うのは、セキュリティの理由で正確な理由は教えられないってことだよね。

こういうことについては、通常理由を教えてもらえないと思うし、ほとんどが自動化されてるみたい。自動システムはミスをするけど、もっと重要なのは全く不透明だってこと。誰も、Googleですら、正確にどう動いているのかは知らないんだよね。

2017年頃にhttps://www.fatherly.com/を運営してたとき、全く同じことが起きたよ。Googleが何の前触れもなくアカウントをシャットダウンしたんだ。月に1万ドルも使ってたのに。プレミアムサポートアカウントにもアクセスできなくなって、誰にも気づいてもらえなかった。約8時間後、ランダムなGoogleのサポート担当者が「ビットコインをマイニングしてたから」と言ったけど、それは全くの嘘だった。CPU使用率のグラフやログがあって、全然スパイクもなかったのに。12時間後に復旧して、「不正検出の設定ミスだった」と言われて、100ドル分のクレジットをもらった。馬鹿げてるよ。AWSについて何を言おうと、顧客に対してそんなことは絶対にしないし、まず担当者が連絡してくるよ。GCPはそれ以来信用してない。

残念ながら、昨日この件でAzureに緊急移行しなきゃいけなかったんだ。幸い、DBはRailwayにホスティングされてなかったから、数時間で復旧できたよ。彼らが提供してくれたシンプルさは大好きだったけど、あまりにも多くのトラブルや欠点があって、B2Bのエンタープライズアプリを彼らのインフラで続けるのは無理だね。悲しい日だ :(

Azureもアカウントを停止されたの?

これはGCPを使ってる人への警告だね。彼らは何も考えずにアカウントを次々と停止するから。どうやら、Gemini 3.1 Proを使って運営の決定をしてるみたい。TKはOCIでの文化を完全に壊した過去があって、GCPでも似たようなことをやってるって聞いたことがある。GCPとGoogleは全然違う組織だから、名前だけでGoogleクオリティを期待しちゃダメだよ。昔のブランドが今は安いライセンス商品を出してるのと同じだね、例えばNokiaみたいに(ちょっと大げさだけど、真実から遠くはない)。それに、サービスを突然停止することが多くて、移行するのに6ヶ月しか猶予をくれないこともある。無駄にしてるエンジニアがたくさんいるから、彼らを内部ユーザーの移行に回してるけど、ほとんどのクライアントはそれをやってない。これについては元GCPの社員が書いた素晴らしい記事があったけど、今は見つからない。ビジネスに本気ならGCPは避けた方がいいよ。

Googleの製品はみんなこんな感じだよ。重要なことには絶対に使うべきじゃない。

これがRailwayだよ。HNのメインページに載るくらいの大きな名前だし、どこかのタイミングでGoogleから誰かが介入する可能性もある。もし自分が作った小さな製品だったら、何も手立てがなかっただろうな。

Googleがどこでも同じスパム対策の考え方を適用してる感じだね。リスクを検出して、まずは禁止、その後に質問。

GoogleはGeminiの前からアカウントをすぐに停止するような行動をしてたんじゃない? LLMを批判するのは好きだけど、これはまるで金魚の記憶みたいだね。それとも、LLM以前のことを覚えてないくらい若いの?

「彼らは生産の決定を下すのにGemini 3.1 Proを使っているようだ。すでに内部でGemini 3.5 Proを使っていると言ってたよ。」

Googleがこういう行動を完全かつ即座に取る理由は何なんだろう?もっと慎重に通知や遅延を設けて、支払い顧客には手動レビューをするようなアプローチじゃないの?一度や二度ならエラーや実装ミスかもしれないけど、こういうパターンは説明できないよね。どうやらGoogleの法務部は、_____が検出されたら、すぐにビジネス関係を完全に断つべきだと判断しているみたい。何がそんなに心配なんだろう?制裁の執行?CSAM?それとも他の何か?

問題はスケールだね。Googleは自動化を使ってるけど、その自動化の行動をチェックする人がいないんだ。Googleで働いたことはないけど、何年もこれを見てきた中での一番明白な説明だと思う。Googleで働いてた人、コメントしてくれないかな。

これは、悪用報告に基づく自動的なアクションかもしれないね。Railway関連のネットワークからは大量のスパムが来てるし。

「お客さんは失敗がGoogleのせいかRailwayのせいかなんて気にしない。彼らが見るのはあなたの製品だ。稼働率は私たちの責任で、私たちはそれを守り続ける。」- クロード、ありがとう!

副作用として、利用規約の同意記録もリセットされ、ユーザーはダッシュボードに次回訪問した際に再度同意を求められました。誤解しないでほしいけど、この混乱の残りは明らかにGoogle Cloudの責任だけど、これはRailwayが自分たちでやったことのように感じる。