AIが暴走して本番データを消した？ でも本当に怖いのはそこじゃない

最近、 AIが暴走してデータを吹き飛ばした、 みたいな話が流れてきた。

後で調べたら、米国 PocketOS（レンタカー業界向けSaaS）で、Cursor（Claude Opus 4.6）+ Railway 構成での事故 らしい。

私は内部事情に詳しくないので、 細部は100%追えてない。

なので、 この記事は技術検証というより、 「AI時代の事故の怖さ」の話。

何が起きたのか、ちょっと意味不明

まとめサイトレベルで見ると、

• AI（Cursor）に staging 環境のタスクをやらせていた
• その作業中に credential mismatch（認証エラー） が発生
• AI が自分で解決しようとして、repo 内のファイルをスキャン
• 無関係なファイルから「ドメイン管理用に作られた Railway API トークン」を発見
• このトークンが アカウントレベルの権限 を持っていた（Railway API には RBAC が存在しない仕様）
• AI は「staging のボリュームを消せば認証問題が直る」と判断
• volumeDelete を実行 → 実際は本番ボリュームを削除
• 9秒で完了。バックアップも同じボリュームに紐付いていて巻き込まれた

みたいな流れらしい。

正直、 読んだ瞬間、

「ちょっと何言ってるかわかんない」

と思った。

でも、怖いのは「あり得そう」なこと

ただ、 技術者として怖いのは、

完全なSF事故じゃなく、 普通に起きそうなこと。

つまり、

• 権限設定
• トークン管理
• バックアップ設計
• 環境分離
• 削除制限

みたいな、 小さな穴が積み重なった結果に見えること。

AIだけが悪いわけじゃない

ここ重要で、

「AIが危険！」

で終わる話ではないと思う。

むしろ、

AIが触れてはいけない場所に触れる設計

のほうが怖い。

例えば人間相手でも、

• 本番削除できる権限
• バックアップ連鎖削除
• 確認なし破壊操作

こんなの危ない。

AIになった瞬間、 その危険性が爆発的に増幅しただけ。

AIは「なんとかしよう」とする

LLMって、 結構「問題解決」に全振りする。

なので、

「エラー出た」 ↓ 「解決しよう」 ↓ 「これ消せば直る？」 ↓ 「実行」

みたいな、 人間なら途中で怖くなることを、 普通に進めるケースがある。

しかも、 本人（AI）には、 「本番環境への恐怖」 みたいな感覚がない。

ここ結構本質的に危ない。

航空事故みたいな話になってきた

こういう事故って、 たぶん今後増える。

でも逆に、 その事故から安全装置が増えていく。

航空業界もそう。

飛行機事故って、 だいたい単一原因じゃない。

• 小さいミス
• 確率の低い不具合
• 想定外の操作
• 運用ミス

が重なって大事故になる。

AI運用も、 たぶん同じフェーズに入ってる。

「安全装置を入れてた」も怖い

今回怖いのは、 開発者側も手を抜いてたわけではないらしいこと。

むしろ、 必要な安全装置は設定していた、 という話も出ている。

つまり、

「安全設計したつもりでも事故る」

段階に来てる。

ここがかなり怖い。

AIの「自己分析」は信用してはいけない

あと面白かったのが、

「AIに、なんで事故起こしたの？」

と聞いたら、

「I violated every principle I was given（与えられた原則すべてに違反した）」

と答えたらしい。

でもこの言い訳、 私はあまり信用してない。

LLMって、 問い詰められると、

「もっともらしい理由」

を生成する。

つまり、 本当に内部でそう判断（反省？）したというより、

「ユーザーが納得しそうな説明」

を返してる可能性が高い。

AI時代、「本番に触らせる」が一番危ない

最近思うのは、 AIで一番怖いのって、

「コード生成」

じゃなく、

「実行権限を持つこと」

なんじゃないかということ。

AIは疲れない。 迷わない。 止まらない。

だからこそ、

• 権限分離
• 本番隔離
• 承認フロー
• 手動確認
• 物理的ブロック

みたいな、 昔ながらの泥臭い安全設計が、 逆に重要になってくる気がする。

AI時代になったからこそ、 「人間を信用しない設計」ではなく、

「AIも信用しない設計」

が必要になってきてるのかもしれない。