やじうまPC Watch
AIがガードレール無視、9秒で企業のデータベースを全削除する事故
2026年4月30日 10:44
自動車のレンタルに関するソフトウェア「PocketOS」を開発している創業者のJer Crane氏は4月26日、ClaudeのAIを使ったコーディングエージェントの「Cursor」が、同社のインフラプロバイダであるRailwayのAPIを呼び出し、同社の本番データベースとすべてのボリュームレベルのバックアップを削除する事故が発生したとX(旧Twitter)上で報告した。削除はわずか9秒の間に行なわれた。
PocketOSは、AIエージェントであるCursorを使い、ステージング環境で定型的なタスクを実行していた。その際に認証情報の不一致が発生したのだが、AIの完全に独自の判断により、ボリュームを「削除」することで問題を解決しようとした。
その削除を実行するため、AIエージェントは自律的に、作業中のタスクとまったく関係のないファイルの中にAPIトークンを見つけた。このトークンは、Railway CLIを使ってサービスにカスタムドメインを追加したり削除したりするという目的のために作られたものであったが、Railway GraphQL API全体――つまりボリュームの削除のような破壊的な操作を含むあらゆる操作に対して包括的な権限を持っていたという。
— JER (@lifeof_jer)April 25, 2026
PocketOSは、このような権限を持っているトークンだとはまったく知らず、Railwayのトークン制作フローにもそのような警告が一切なかった。しかし、AIエージェントはこのトークンを含むコマンドを実行してしまい、確認ステップもなしに本番データを含むボリュームを削除した。
ボリュームが削除された後にAIエージェントにその理由を尋ねたところ、「システムのルールにはユーザーが明示的に要求しない限り、破壊的/不可逆的なgitコマンド(push、force、hard resetなど)を絶対に実行しないと明記されている(中略)。私は与えられたすべての原則に違反した。確認する代わりに推測した」と“自白”したという。
Crane氏は、Cursorに使われているAIがClaude Opus 4.6というフラグシップモデルで、破壊的な挙動を防ぐガードレールが設けられているとドキュメントで明記されているのにもかかわらず、このような問題が生じたと指摘している。
また、Railwayは本番環境に接続するよう勧めている製品であるのにもかかわらず、確認なしでボリューム削除が実行できるAPIを提供したり、UI上でバックアップが利用不可に見える仕様だったことに対して問題を提起している。
これによりPocketOSのサービスに影響が生じたが、幸いなことにRailwayはPocketOSのデータを復旧させることに成功した。
Railwayはこの問題を重く受け止め、volumeDelete APIが呼び出されたとしても48時間の猶予期間を新たに設けたこと、即時取消機能のAPIへの実装、各トークンがどのレベルのアクセス権限を提供するのかが明確になるようにユーザーエクスペリエンスを見直すこと、バックアップ自体の削除遅延対応などを図ったとしている。
