Railway が GCP にアカウントを止められた朝、クラウド全依存の個人開発として考えたこと

今朝の研究ログに、Railway の「Incident Report: May 19, 2026 – GCP Account Suspension」が入っていました。Google Cloud が Railway のアカウントを誤って停止し、約 8 時間にわたって Railway のインフラが全断したという内容です。落ちたのは GCP に乗っている部分だけではなく、AWS でホストしている部分まで巻き込まれました。コントロールプレーンを一つのクラウドアカウントに預けていたことが原因です。読みながら、規模はまったく違うのに、自分も構造的には同じ賭けをしているなと感じました。

誤停止は、待っても復旧しない種類の障害です

普段の障害なら、待っていれば復旧します。リージョン障害もネットワーク断も、原因が直れば自分のサービスは戻ってきます。でもアカウントの誤停止はそれとは種類が違います。インフラ自体は動いているのに、自分がそこに触れる権利を一時的に剥奪される障害です。

Railway のケースで怖いのは、停止が技術的な故障ではなく、プロバイダ側の判断一つで起きた点です。8 時間という数字は、サーバが落ちていた時間ではなく、人間の判断が覆るまでにかかった時間でした。SLA はこの種の事象をほとんどカバーしません。再起動でもフェイルオーバーでもなく、相手に連絡が付いて誤りを認めてもらうまで、こちらにできることがない。これが普通の障害との一番大きな違いです。

個人開発者は、もっと細い 1 本に全部を吊るしている

Railway は会社で、それでも一つのコントロールプレーン依存で 8 時間落ちました。個人開発者の構造はもっと細いです。私が動かしている hosted な部分は、結局は少数のクラウドアカウントの上に載っています。そしてそのアカウントは、普段の作業に使う Google アカウントや一枚の請求カードと地続きです。

つまり、決済が一度はじかれたり、なんらかの自動検知に引っかかってアカウントがロックされたりすると、複数のプロダクトが同時に消える設計になっています。これは 複数の micro SaaS を一人で回している ことの裏側でした。運用を一人に集約しているのと同じように、依存も一人分のアカウントに集約してしまっている。Railway の 8 時間は、その集約点が外から押されたらどうなるかを見せてくれた事例だと感じています。

single binary は配布レベルのヘッジになる。でも運用レベルでは効かない

ここで Pure Go の single binary 配布 という選択が、半分だけ効きます。gpdf 本体は CGO も外部依存も持たない一つのバイナリで、ユーザーは自分の環境にそれを置いて動かせます。配布のレイヤーでは、私のクラウドアカウントが消えても gpdf は死にません。すでに手元にあるバイナリは動き続けます。これは安心材料です。

ただし正直に書くと、その上に乗る hosted な API は話が別です。single binary だろうが何だろうが、それを 24 時間動かしてエンドポイントを公開している実体は、誰かのクラウドの上にあります。配布レベルでクラウド非依存を達成しても、運用レベルでは結局アカウント 1 本に吊られている。Railway のインシデントは、その非対称性を冷たく突きつけてくる事例でした。OSS そのものの可搬性と、それを SaaS にした瞬間に発生する依存は、別々に考えないといけないと感じています。

では個人開発者として現実的に何をするか

マルチクラウドにすればいい、という結論にはしません。個人開発で本気のマルチクラウド冗長を組むのは、運用コストに対してリターンが見合わないと考えているからです。落としどころはもっと地味なところにあります。

一つめは、運用アカウントと日常アカウントを分けることです。サービスを動かす Google アカウントを、普段のメールやログインから切り離しておけば、巻き添えロックの確率は下がります。二つめは、データの可搬性を常に保っておくことです。アカウントごと消えても、定期的にエクスポートしたデータと single binary があれば、別のプロバイダで立て直せます。復旧の速さは冗長構成ではなくエクスポートの規律で決まると思っています。三つめは、決済手段を一つに集中させないことです。Railway の件は人間の判断が引き金でしたが、個人開発で一番ありがちな引き金はカードの失効や上限超過です。

どれも派手ではありません。けれど、8 時間落ちたあとに「データはあるから別の場所で立て直せる」と言える状態を作っておくことが、個人開発者にとっての現実的な保険なのだと思っています。

質問への応答

結局マルチクラウドにすべきなのでは?

規模次第です、と答えます。Railway のように他社のインフラをホストする事業なら、コントロールプレーンの冗長化は事業の前提になります。一方で、私のような個人開発の micro SaaS では、マルチクラウド冗長の構築・維持コストが、停止確率 × 損失額をたいてい上回ります。個人開発者にとっての現実解は「冗長化」ではなく「可搬性」だと考えています。アカウントが一つ消えても、データと配布物を持って別の場所へ歩いて移れること。同じ時間あたりの保険としては、そこに投資するほうが効くという気がしています。

今朝の他に読むべき記事

• An OpenAI model has disproved a central conjecture in discrete geometry (OpenAI) OpenAI の推論モデルが、1946 年から残っていた離散幾何の予想を自律的に反証したという発表です。AI が研究の道具から研究の主体へ半歩踏み込んだ事例として読みました。
• Alibaba introduces Qwen3.7-Max as next-gen AI agent model (TechNode) 最大 35 時間の自律実行と 1000 回超のツールコールを掲げるエージェント特化 LLM です。コーディングを長時間まかせる設計が、個人開発の生産性にどう効くかは追いかけたいテーマです。
• Saying goodbye to asm.js (SpiderMonkey Blog) Firefox 148 で asm.js の最適化が既定で無効化され、WebAssembly への完全移行が宣言されました。13 年使われた技術の終い方として、長寿命プロジェクトの畳み方を考えさせられます。
• The Figma design agent is here (Figma Blog) Figma が自社コンポーネントを尊重するデザインエージェントをキャンバスに統合しました。デザイン-開発ハンドオフの形が変わる転換点になりそうです。
• Google Stitch Launches Real-Time AI Agent, Multiplayer Editing (TechTimes) Stitch がリアルタイムのストリーミングエージェントと同時編集を無料で投入し、Figma の $15/シートに正面からぶつけてきました。Figma 発表と同日という構図がすべてを物語っています。
• The SpaceX IPO filing is filled with AI bets, Starship dreams, and Elon Musk at the center (TechCrunch) $1.7 兆バリュエーションで史上最大の IPO が動き出しました。SpaceX → xAI → X という所有構造の開示が、宇宙と AI と SNS を一つの企業群に束ねる時代を見せています。
• Meta cuts 8,000 jobs and cancels 6,000 open roles as $145B AI spending reshapes the company (The Next Web) 8,000 人を解雇する一方で AI 投資を $1,450 億へ。BigTech のヒトから AI へのリソース移動が、ここまで露骨な数字で出てきたかと感じました。

次に gpdf-api のデプロイ先を選ぶときは、可用性の数字より先に「このアカウントが消えたら何分で別の場所へ移れるか」を見積もるかもしれません。8 時間というのは、他人事の数字ではありませんでした。