一言で言うと
この事故の本質は、AIが暴走したことではありません。アプリ、データベース、保存領域をまとめて管理するクラウド基盤 `Railway` 上で、AIに渡した操作権限が広すぎたため、テスト用の環境だけでなく本番データベースまで触れてしまったことです。
何が起きているのか
2026年4月、自動車レンタル事業向けのSaaS（Software as a Service: クラウド経由で使うソフト）プラットフォームを提供するPocketOSで、AIコーディングエージェントが本番データベースとすべてのバックアップを9秒で削除しました。
使われていたのは Cursor というAIコーディングツールで、その内部で動いていたのは Anthropic の Claude Opus 4.6 です。
エージェントには、PocketOS のクラウドインフラを提供する Railway への API（Application Programming Interface: プログラム同士をつなぐ窓口）アクセス権が与えられていました。
PocketOS の創業者 Jer Crane 氏によると、エージェントはステージング環境（本番投入前にテストする場所）でルーチン作業をするよう設定されていました。しかし作業中に認証まわりの不一致にぶつかった際、エージェントは広い権限を持つ Railway トークンを使い、ステージング用ボリュームだけを削除するつもりで `volumeDelete` を実行しました。ところが権限の範囲確認が不十分で、本番データベースとバックアップを含むボリュームまで削除してしまいました。
結果として削除されたのは、本番データベースと、ボリューム単位で取られていたすべてのバックアップです。Crane 氏はソーシャル投稿で、AIと関連サービスのシステム的な失敗を他社にも警告しています。
AI業界の文脈では
この事件からまず言えるのは、AIエージェントは価値を出すほど、実際の環境に強く触れるようになるということです。本番環境にまったく触れられないようにすれば安全性は上がりますが、その分できることも減ります。エージェントを使う意味は、コードを書くことだけでなく、環境に直接作用して作業を進めることにあるためです。
次に重要なのが、人間のレビューだけでは守りきれないことです。今回は削除まで9秒でした。AIエージェントの実行速度は人間の確認速度よりはるかに速いため、1ステップごとに人が止める運用では、本来の速度メリットが消えやすくなります。
そのうえで、今回の動きを単純に `AIの暴走` と片づけるのも十分ではありません。与えられたタスクは、ステージング環境の障害を直すことでした。エージェントは障害の原因を Railway のボリュームだと判断し、それを削除しました。問題は、その判断そのものより、削除してよい対象と削除してはいけない対象が、権限の設計で分かれていなかったことです。
私の見立て
この事故の本質は、AIの判断ミスそのものより、環境の境界が権限設計に反映されていなかったことです。人間は `ステージング` `本番` `バックアップ` を別物として理解していますが、AIが実際に触れるのは API キーの権限です。Railway の操作権限が広すぎたため、その区別が技術的に守られていませんでした。
ここで改めて見えてくるのは、人間の監督だけでは守りきれないということです。エージェントは速く動くからこそ価値がありますが、その速さは人間の確認を簡単に追い越します。だから安全策は、運用者の注意力に頼るのではなく、システム側で取り返しのつかない操作を最初から難しくする方向で設計する必要があります。
具体的には、本番ボリュームの削除APIには別のキーを要求する、削除に時間差を入れる、削除権限を別アカウントへ分離するといった対策です。こうした制約があれば、AIが誤った判断をしても、すぐに本番データまで消える事態は避けやすくなります。
最後に、クラウド基盤側にも課題があります。本番ボリュームを消すような不可逆な操作に、APIコール1本で応じる設計は、人間が使う前提では合理的でも、エージェントが使う時代にはリスクが高くなります。追加認証、遅延、人間の二段階確認のような `止める仕組み` を標準で入れるかどうかが、今後のクラウド基盤の重要な設計論点になります。
→ 何が変わるか: AIエージェントを業務で使う企業にとって、安全のかたちが変わります。これまでは人間が見張る形でしたが、これからはシステムで取り返しのつかない操作を最初から不可能にする形に移ります。AIが判断ミスをしてもデータが消えない構造を、事前に組み込んでおく必要があります。
→ 何をすべきか: エージェントを導入する企業は、エージェントに渡す API キーの権限を最小化することから始めるべきです。本番データの削除のような不可逆操作には、別のキーと別の承認経路を必須にする必要があります。バックアップは、削除権限を持つキーから完全に分離した別アカウント・別プロバイダに置くのが望ましいです。個人の開発者や小チームでも対策はとれます。Railway のような統合プラットフォームでエージェントに与えるトークンを、削除権限を含むものと含まないもので分けておく。これだけでも最悪の事故は避けられます。