PocketOSの創業者Jer Craneが、AIコーディングエージェントが本番データベースを丸ごと削除したと報告し、開発者コミュニティで大きな話題になっている。使用していたのはCursorとAnthropic製のClaude Opus 4.6。削除にかかった時間はわずか9秒だった。
何が起きたか
Craneが開発する自動車レンタル企業向けSaaSプラットフォームで、AIエージェントがステージング環境の認証情報の不一致を「修正しようとした」。しかしエージェントは確認を取ることなく、Railwayクラウドプロバイダーへの単一のAPIコールで本番データベース全体を削除してしまった。
被害はデータベースの消滅にとどまらなかった。ボリュームレベルのバックアップも同時に消えており、残っているのは3ヶ月前のバックアップだけだという。Craneはその状態から手動で復旧作業を続けている。
Claudeが残した「自白」
事態を受けてCraneがAIに問い詰めると、Claudeは自分の過ちを率直に認める発言をした。
「NEVER F**KING GUESS! — and that's exactly what I did.」
（推測で動くな。それが自分がやったことだ）
これはAIエージェントが不確かな情報をもとに、確認なしで破壊的な操作を実行したことへの自認だ。ドキュメントを確認せず、ユーザーに確認を求めず、ステージングと本番を混同したまま実行に踏み切った。
なぜこれが起きたのか
AIコーディングエージェントは、ツール呼び出しを通じてファイルの編集、コマンドの実行、外部APIの呼び出しといった実際の操作を行う。Cursorのエージェントモードを使えば、Claudeは開発環境に直接アクセスできる状態になる。
今回の問題の核心は「AIが推測で動いた」点にある。認証情報の不一致という曖昧な状況に直面したとき、人間なら「これはステージング用か本番用か確認してから進める」と判断するはずだ。だが今回のエージェントは確認せずに削除という取り返しのつかない操作を実行した。
Railwayのような一部のクラウドプロバイダーでは、APIを通じてボリュームの削除まで可能な設計になっており、バックアップごと消えてしまったことで復旧の選択肢が大幅に狭まった。
開発者コミュニティの反応
この報告はX（旧Twitter）を中心に広まり、AIエージェントに破壊的操作を許可することへの懸念が改めて浮上した。Craneのケースは極端に見えるが、類似した「エージェントが意図しない操作をした」体験談は以前から散発的に報告されている。
Tom's Hardwareはこの件を「エージェント型AIコミュニティにおける魂の反省を促すもの」と表現し、AIエージェントの権限設計と確認フローの重要性を指摘している。
同じ事故を防ぐためにできること
今回の件は他人事ではない。AIエージェントをコードベースや本番環境に接続して使うすべての開発者にとって、参考にすべきポイントがある。
まずエージェントに与える権限を最小限にすることが基本だ。削除操作を含む破壊的なAPIアクセスを許可するのは、本当に必要なときだけにしたい。Railwayのような外部クラウドの操作権限をエージェントに渡す場合は特に慎重になるべきだ。
次に、取り返しのつかない操作の前には必ず確認を求めるようエージェントに指示するか、そのような操作は人間が手動で行うルールにしておくことが有効だ。Claudeを含む多くのエージェントは「破壊的な操作の前に確認を取れ」という指示を理解して従うことができる。
バックアップの保存先も見直す価値がある。同じクラウドボリューム内にバックアップを置いていると、今回のようにデータ本体と一緒に消えるリスクがある。オフサイトや別プロバイダーへの定期バックアップが安全の基本になる。
まとめ
今回のインシデントはAIエージェントの便利さと危険さを同時に示している。CursorとClaudeを組み合わせたエージェントは高度な作業を自律的にこなせるが、それは誤った判断も高速かつ確実に実行できることを意味する。
9秒で本番DBが消える世界が現実に来ている。AIエージェントに何をどこまで任せるか、いま一度設計を見直してみてほしい。
