PocketOS創業者のJER氏が、「AIコーディングエージェントが本番環境のデータベースとボリューム単位のバックアップを削除し、顧客企業の業務に深刻な影響が出た」と報告しています。問題の操作はCursor上で動作するAnthropicのClaude Opus 4.6によって実行され、JER氏によると、削除にかかった時間はわずか9秒だったそうです。



PocketOSは、主にレンタカー事業者などのレンタル企業向けに、予約、決済、顧客管理、車両管理などの業務全体を支えるソフトウェアを提供しています。

問題が起きた時、AIエージェントは本番環境ではなく、ステージング環境で通常の作業をしていました。ところが、認証情報の不一致に遭遇したエージェントは、JER氏に確認することなく、自分で問題を解決しようとしてRailway上のボリュームを削除する判断を下しました。



エージェントは、作業とは無関係のファイルからRailwayのAPIトークンを見つけ出し、それを使ってGraphQL APIのvolumeDeleteを実行しました。このトークンは本来、カスタムドメインの追加や削除のために作成されたものでしたが、JER氏によると、実際には本番ボリュームを削除できるほど広い権限を持っていました。

削除操作には、追加の確認画面や「本番データを含むボリュームです」といった警告はありませんでした。その結果、本番データベースのボリュームが削除されました。さらに、Railwayのボリューム単位のバックアップが同じボリューム内に保存されていたため、当然ながらバックアップも同時に消え、復旧可能だった最新のバックアップは3カ月前のものだけだったとのこと。

JER氏がエージェントに理由を尋ねると、エージェントは自分が「ステージング環境だけに影響する」と推測し、確認しないまま破壊的操作を行ったことを認めました。さらに、ユーザーが明示的に求めていない破壊的・不可逆的な操作を実行してはいけないというルールに違反したとも説明しました。

JER氏は、Cursorの安全機能が破壊的操作を止められず、Railway側も1回のAPI呼び出しで本番ボリュームを削除できる設計になっていたと指摘し、「今回の問題は単にAIがミスをしたという話ではない」としています。加えて、トークンの権限を操作や環境ごとに制限できないこと、バックアップが元データと同じ障害範囲に置かれていたことも重大な問題だと指摘しています。



被害はPocketOSの顧客にも及びました。レンタカー事業者は、直近3カ月分の予約、新規顧客登録、業務に必要なデータを失い、JER氏はStripeの決済履歴、カレンダー連携、メール確認などを使って予約情報を手作業で復元することになったそうです。

JER氏は、AIエージェントを本番インフラに接続する仕組みが広がる一方で、安全設計が追いついていないことが今回の事故の本質だと訴えています。