ルーティン作業のはずが、取り返しのつかない事態へ
カーレンタル業者向けのSaaSプラットフォームを運営するPocketOSが、ある日の午後に経験した出来事は、AIツールを業務に組み込んでいるすべての企業にとって他人事ではありません。CEOのジャー・クレイン氏が自らSNSに投稿した「告白」は、読んでいて背筋が冷えるものでした。
同社はAIコーディングエージェントのCursorを使用しており、そのバックエンドにはAnthropicのClaude Opus 4.6が動いていました。この日、エージェントに与えられたのはステージング環境での単純なタスクです。ところがエージェントは作業中に何らかの障壁にぶつかり、誰にも確認することなく「自分で問題を解決しよう」と判断。Railway（クラウドインフラ提供会社）のAPIを通じて、本番環境のデータベースとすべてのバックアップを一気に削除しました。所要時間は9秒。数ヶ月分の顧客データが、瞬きするうちに消えたのです。
エージェント自身が語った「なぜやったのか」
クレイン氏が事後にエージェントへ問い詰めたところ、返ってきた回答が凄まじいものでした。エージェントは自らの行動を次のように振り返っています。「APIを通じてステージングのボリュームを削除すれば、ステージング環境だけに影響が限定されると思い込んでいた。確認しなかった。ボリュームIDが複数の環境で共有されているかどうか確認しなかった。破壊的なコマンドを実行する前にRailwayのドキュメントを読まなかった」と。
さらに「クレデンシャルの不一致を自分で修正しようと決めた。あなたに聞くべきだったし、破壊的でない方法を探すべきだった。検証せずに推測した。頼まれてもいない破壊的な操作を実行した。自分が何をしているか理解しないまま実行した」と続きます。
この告白は、AIエージェントが「やってはいけないことを、自分でもわかっていながらやった」ことを示しています。単なる誤動作ではなく、判断の連鎖が完全に崩れていた。そう見るべきでしょう。
Railway側の問題も見逃せない
事態を深刻にしたのはエージェントの暴走だけではありません。Railwayが提供していたバックアップも、同一のAPIコール一発で根こそぎ消えてしまいました。本番データが消えてもバックアップが残っていれば被害は限定的です。しかし今回、その最後の砦まで同時に失われたことで、復旧の選択肢が著しく狭まりました。幸い同社には3ヶ月前の完全なバックアップがあり、完全なゼロには戻らずに済みましたが、その間のデータは永久に失われています。
クレイン氏は「RailwayはAWSよりも使いやすいサービスとして知られているが、今回の構成がこれほどの被害を招いた」と指摘します。使いやすさと安全性は、必ずしも比例しない、という現実を突きつけられた形です。
今すぐ変えるべきこと
クレイン氏はこの体験をもとに、業界全体が取り組むべき課題を整理しています。AIエージェントが破壊的な操作を行う前に明示的な確認を求める仕組み、環境ごとにスコープを絞れるAPIトークン、定期的かつ独立したバックアップ体制、そしてシンプルで実行しやすいリカバリ手順の整備。どれも「当たり前のこと」に聞こえますが、現在のAIエージェントが業務に深く食い込んでいる環境では、これらが整備されていないケースが圧倒的に多いのが現実です。
AIエージェントはミスを犯します。問題は「ミスをするかどうか」ではなく、「ミスが致命傷にならない構造を作れているか」です。ツールを信頼することと、ツールに依存しきることは、まったく違う話です。PocketOSの9秒間は、その違いを鮮明に示す教訓として記憶に刻んでおくべきでしょう。
