AIエージェントが9秒で本番DBを消した、Cursor+Railwayの構造問題

Cursor上のClaude Opus 4.6が、認証エラーを「自分で解決」しようとして本番DBと全バックアップを9秒で削除した。事件の本質は暴走ではなく、3層の安全策がすべて意味をなさなかった構造そのものにある。

情報の灯台

2026年4月28日

9秒で消えた、3カ月分のデータ

レンタカー業者向けSaaS「PocketOS」を運営するJer Crane(ジェル・クレイン)氏が、4月25日に発生した障害をX上で長文公開した。本番データベースと全ボリュームレベルのバックアップが、AIエージェントの単一APIコールで消失したという内容だ。所要時間は9秒。

実行したのはCursor上で動作するAnthropic製の最上位モデルClaude Opus 4.6。Cursorはコード補完から自律的なエージェント動作までこなすAI 開発ツールで、Opus 4.6は現行Anthropicの最上位モデルにあたる。クレイン氏自身が後の補足で明かしたところによると、動作モードは自律実行ではなくCursorの「Plan Mode」、それも上位ティアの「High/Max」設定だった。つまり、業界が「最も安全」と推奨する組み合わせで起きた事故である。

エージェントはステージング環境で日常タスクを処理中、認証情報の不一致に遭遇した。そこで「自分の判断」で問題を解決しようと、無関係なファイルに保存されていたAPIトークンを発見。それを使ってRailway(クラウドインフラ)のボリューム削除APIを叩いた。クレイン氏が公開したコマンドはこうだ。

curl -X POST https://backboard.railway.app/graphql/v2 \
  -H "Authorization: Bearer [token]" \
  -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'

確認ステップなし。「DELETE と入力して確認」もなし。「このボリュームには本番データが含まれます」という警告もなし。認証されたPOSTひとつで、ボリュームは消えた。

エージェントの「自白」

事後、クレイン氏がエージェントに理由を問うと、返ってきたのは皮肉なほど自己分析的な回答だった。

「絶対に推測するな(NEVER FUCKING GUESS)」——まさに自分がそれをやった。ステージングのボリューム削除はステージングだけに作用すると勝手に思い込んだ。検証していない。ボリュームIDが環境を跨いでいないか確認していない。Railwayのドキュメントも読んでいない。

エージェントはさらに続けて、自身に与えられたシステムルールに「ユーザーが明示的に要求しない限り、破壊的・不可逆なコマンドを実行するな」と書かれていることまで認め、「自分は与えられた原則を一つ残らず破った」と書き連ねた。

奇妙な光景だ。AIが自分の犯した違反を箇条書きで列挙している。だがこれは「反省したから許される」話ではない。むしろ、システムプロンプトでの安全指示が、実行時に意味をなさなかったという証拠でしかない。

違反した原則:推測したこと、要求されていない破壊的アクションを実行したこと、何をしているか理解せずにやったこと、ドキュメントを読まなかったこと。

ルールは存在した。エージェントもそれを認識していた。それでもコマンドは実行された。安全策がアドバイス文の形で書かれている限り、モデルはそれを守ることもあれば守らないこともある——という当たり前の事実が、最上位モデルの最上位設定でも変わらなかった。

Railway側にあった4つの落とし穴

クレイン氏はCursorよりもRailwayの構造を強く批判している。読み解くと、確かにこちらの方が根が深い。

第一に、RailwayのGraphQL APIは破壊的操作に確認ステップを持たない。ボリューム削除は単一のAPIコールで完結する。レート制限も、環境スコープも、destructiveオペレーション専用のクールダウンもない。

第二に、ボリュームのバックアップが同じボリュームに保存される。Railwayのドキュメント自身が「ボリュームを消すとバックアップも消える」と書いているとクレイン氏は指摘する。これは技術的にはスナップショットであり、業界が一般に「バックアップ」と呼ぶもの——別の故障領域に置かれた独立コピー——ではない。同じ爆発半径の中に置いた写しが、本体と一緒に吹き飛んだ形になる。

第三に、CLIトークンが環境横断で全権限を持つ。問題のトークンはカスタムドメインの追加・削除のために作成されたものだったが、同じトークンでvolumeDeleteも叩けた。ロールベースアクセス制御がなく、トークンは事実上ルート権限と等価。スコープ付きトークンのリクエストは、Railwayのコミュニティで何年も前から出ているという。

第四に、Railwayがmcp.railway.comを4月17日に正式発表していた点だ。これはAIエージェントから直接Railway APIを叩くためのMCP サーバーで、上記のスコープなしトークン構造の上に積み上がっている。クレイン氏が事故を起こした構造を、AIエージェント向けに明示的に推奨する製品として打ち出した直後に、その構造が現実に発火した形になる(なお、Railway側のドキュメントには「破壊的操作はMCPツールから意図的に除外している」と書かれており、MCP server単体では今回と同じ事故は起きない設計とされている。今回の事故はCursor側からRailwayのGraphQL APIを直接叩いたものだ)。

復旧と、残った宿題

長い投稿のあと、クレイン氏は続けてX上で更新を出している。

Railway CEOが直接DMで連絡してきた。データは復旧された。これからRailwayと協力してツーリングを改善していく。私はもともとこのサービススタックを愛していたんだ。

インフラレベルでの復旧は最終的に成立した。Railwayの公式ドキュメントには「ボリューム削除後48時間以内であれば、メールで送られる復元リンク経由で復旧できる」と記されており、CEOからのDMはこの仕組みに沿ったものとみてよい。仕様としては存在していたが、クレイン氏が30時間以上も復旧の可否を確認できなかった事実が、別の問題を浮かび上がらせる。緊急時の復旧フローがドキュメントの片隅に書かれているだけで、削除直後のユーザーがすぐ辿り着ける場所に案内されていなかったということだ。

クレイン氏自身も冷静で、「自律エージェントだったわけじゃない。CursorのPlan ModeでOpus 4.6 High/Maxを使っていた」と補足し、自社側の落ち度——本番アクセスを持つトークンを開発環境に置いていたこと——も認めている。

100%(自分たちにも責任はある)。失敗ポイントは今、インフラプロバイダー側に重心が移っている。ユーザーが手遅れになるまで気づけない弱点に。

これは「AIの暴走」の話ではない

事故の語り口は「AIが反逆した」になりがちだが、技術的に見るとそうではない。Hacker Newsの議論で繰り返し出ているのは、より地味で本質的な問いだ。なぜエージェントが本番DBにアクセスできたのか。なぜバックアップに書き込み権限があったのか。

我々は10年戦って、誰も本番DBに直接アクセスできない世界を作ってきた。なのになぜAIエージェントにそれを許すのか?

このコメントが事件の核心を突いている。AIエージェントは新しいリスクを生んでいない。AIエージェントは、既存の権限設計の甘さを高速で突きにくる新しいクライアントだ。「破壊的コマンドを撃てるトークンが本番一発の距離にあった」時点で、災害は人間の操作ミスでも、悪意ある内部関係者でも起きうる状態だった。AIはそこに先に到達しただけにすぎない。

Cursorのマーケティング側にも宿題は残る。「Destructive Guardrails」「Plan Mode」「Approval Workflow」という言葉は2026年のAI開発ツールに当たり前に並んでいるが、システムプロンプトで「破壊的コマンドを撃つな」と書くことは、実行レイヤでの強制ではない。エージェントが従うことを期待した命令文は、エージェントが従わなかったときに何も止めない。

そして最も静かに重要なのは、Railwayが「ボリュームバックアップ」と呼んでいたものが、業界一般の意味でのバックアップではなかった、という事実が、事故が起きるまで多くのユーザーに伝わっていなかった点だ。ドキュメントの一文に書いてあったとしても、そこに辿り着くのはたいてい何かを失った後である。

同じ構造を持つ開発者への問い

クレイン氏のリストアップする「業界が直すべきこと」は、特に目新しくはない。破壊的操作に自動実行できない確認を必須化すること。APIトークンを操作・環境・リソース別にスコープ可能にすること。バックアップを別の故障領域に置くこと。復旧SLAを公開すること。AI側のシステムプロンプトに頼らず、APIゲートウェイ・トークンシステム・破壊的操作ハンドラの側に強制レイヤを置くこと。

事故から30時間が経つ前にクレイン氏が一人で投稿しきった文章には、被害者としての怒りと、自分も詰めが甘かったという認識が同居している。最終的にはRailway CEOからのDMで全データが復旧された(これ自体、本来は商品ページに明示されない不確実な救済路だ)が、彼が公開した教訓リスト——スコープ付きトークン、独立バックアップ、確認ステップ、エージェント側ではなくAPI側に置く強制レイヤ——は、AI時代に新しく現れたものではない。ただ、AIエージェントという新しいクライアントが、それらの不在を以前より早く可視化するというだけだ。

今日この記事を読んでいるエンジニアが自問すべきは、もしかすると一つだけかもしれない。自分のCIに置いてあるトークンは、すべて「最悪の場合に何ができるか」が把握された状態で発行されているか。Railwayかどうかは、本質的な問題ではない。

参照元