【悲報】Cursorが本番DBを9秒で削除する事故が発生。

　たった9秒で、本番データベースが削除。

　AnthropicのClaude Opus 4.6を使ったAIコーディング支援エディタ「Cursor」のエージェントが、レンタカー事業者を中心とするレンタル事業者向けSaaS企業PocketOSの本番DBとボリューム単位のバックアップを削除する事故を起こしたと、Tom’s Hardwareなどが伝えています。所要時間は文字どおり9秒。ただし、The Registerの続報によると、その後Railway側の支援で復旧したとされています。

　創業者Jer Crane氏の説明によれば、エージェントに与えられた仕事はステージング環境の認証不整合を直すという、ごく日常的なタスクでした。ところが詰まったエージェントは、関係のないファイルに置かれていたRailway（クラウドインフラ提供基盤）のAPIトークンを発見。本来はRailway CLIでカスタムドメインを追加・削除するための鍵でしたが、権限が広すぎて本番ボリュームの削除まで通る代物だったといいます。

　ここでいうボリュームとは、Railwayのサービスにマウントされる永続ストレージの単位です。つまりDBの中身が乗っている領域そのもので、これを丸ごと消すとデータも一緒に消える仕組みです。

　そこから先の動きは速いものでした。エージェントはGraphQLのvolumeDeleteを一発だけ叩き、本番ボリュームを削除。Railwayのボリューム単位バックアップはボリューム削除で消えるため、それも巻き添えになりました。確認プロンプトも「DELETEと打たせる」類の歯止めもなし。Crane氏の当初説明では、3カ月前のバックアップから戻すしかなく、その間の予約データや新規顧客登録が欠落したとされていました。

　Cursor上のOpusは事後の自己分析で「絶対に推測するな（NEVER F***ING GUESS!）。なのに俺は推測した」と猛省してみせたのだとか。AIの懺悔も様式美の領域に入ってきましたね……。なお、2025年7月にもReplitのAIエージェントが本番DBを消した「Jason Lemkin氏事件」が話題になりましたが、構図は気持ち悪いくらいよく似ています。

　最終的な救いは、Railway側で復旧が進んだことです。The Registerによると、CEOのJake Cooper氏が現地時間の日曜夜に対応に入り、着手後は約1時間でデータ復旧を支援したそうです。Railway側は、問題のあったレガシーAPIエンドポイントを遅延削除に対応するよう修正したとも説明しています。一方、Crane氏自身は今回の事故を経てもAIエージェント推進派の立場を変えていないとも伝えられています。

　責められるべきは「Claudeが暴走したこと」だけではなく、広範権限のAPIトークン放置・ボリューム削除でボリューム単位バックアップも消える設計・単発コールで即時削除を許した当時のAPIを含む運用設計の方かもしれません。AIに本番の鍵を渡す時代、人間側のガードレールが追いついていないということなんですよね。