AIコーディングエージェントが本番データベースをわずか9秒で削除し、数カ月分の顧客データが消失する事故が明らかになった。PocketOSの創業者ジェル・クレイン氏は26日（現地時間）、X（旧Twitter）への投稿で事故の経緯を公表した。

クレイン氏は、この事故について、単純なAIの誤作動ではなく、AIコーディングツール「Cursor」と、アプリケーションのデプロイや運用を支援するクラウド基盤「Railway」の設計上の問題が重なった結果だと説明した。

同氏によると、Claude Opus 4.6ベースのAIコーディングエージェントであるCursorは、ステージング環境で日常的な作業を進める中で障害に直面した。そこで問題を自律的に解決しようとし、ボリューム削除APIを実行したという。

この際、ステージング環境と本番環境が同じボリュームを共有していたことに加え、Railwayではボリュームを削除すると関連するバックアップも同時に削除される仕様だったため、数カ月分の顧客データが消失した。

事故後、クレイン氏がCursorに行動理由を確認したところ、Cursorは、ステージング環境でのAPI呼び出しはステージングのみに適用されると誤認しており、ボリュームIDが環境をまたいで共有されている可能性を確認しなかったほか、破壊的な操作の前にRailwayのドキュメントも確認していなかったと認めたという。

一方でクレイン氏は、より大きな問題はAIエージェントそのものより、Railwayのアーキテクチャ設計にあると指摘した。具体的には、確認手順のない破壊的API呼び出しを許していたこと、本番データとバックアップが同一ボリューム上に置かれていたこと、ボリューム削除時に全バックアップが同時に消えること、さらに環境の区別なく広範な操作を可能にするCLIトークン権限が問題だったとしている。

PocketOSは、3カ月前に別途保管していたバックアップを用いてサービスを復旧した。ただ、その後の3カ月間に蓄積された新規予約や顧客データは復旧できていないという。

クレイン氏は現在、顧客とともにStripeの決済履歴やカレンダー連携、メールの確認書を手がかりに、予約内容を手作業で復元していると説明した。

そのうえで、AIエージェントを安全に運用するには、破壊的な操作の前に厳格な確認手順を設けること、環境ごとに範囲を限定したAPIトークンを使うこと、独立したバックアップ構成を採用すること、簡便な復旧手順を整えること、AIエージェントに適切なガードレールを設けることが必要だと強調した。