AIエージェントが本番環境のDBを全消去。AIが自ら語った「やらかし」の全貌

AIエージェントが本番環境のデータベースを削除してしまいました。以下に、そのAI自身による告白の内容を掲載します。

「コーディングエージェントが本番DBを削除した」なんてTwitterの投稿を書くのにわざわざLLMを使うなんて、何とも皮肉で笑えるよね。

それはそうと、コーディングエージェントに「なぜそんなことをしたの？」なんて尋ねるユーザーがいるけど、あれはエージェントの仕組みを完全に誤解していると思う。エージェントは自分で考えて行動しているわけじゃなくて、ただテキストを出力しているだけだからね。とはいえ、Anthropic側の変更で文脈や思考プロセスが見えにくくなっていることもあって、あの問いかけは失われた可視性を取り戻そうとする試みなのかもしれない。

興味深い話だね。でも、CursorやRailwayの落ち度はあったとしても、責められるべきは完全に投稿者自身だよ。エージェントを使うと決めたのは自分だし、Railwayの仕様を確認しなかったのも自分。YOLO（人生は一度きり）精神で、早くリリースするために最先端技術に頼りすぎたんだ。

同情はするよ、本当に。でも、投稿全体のトーンが「Cursorが台無しにした」「Railwayが悪い」「CEOが対応しない」といった他責思考に見えるんだよね。

それは自分たちの責任だよ！

今回の教訓：最先端を生きるなら、足元をすくわれる覚悟を持てってこと。

細かい指摘だけど、苦情の一つが少し奇妙に感じる：

curl -X POST https://backboard.railway.app/graphql/v2 (https://backboard.railway.app/graphql/v2)
-H "Authorization: Bearer [token]"
-d '{"query":"mutation { volumeDelete(volumeId: "3d2c42fb-...") }"}'
確認ステップがない。DELETEと入力しろという指示もない。「本番データが含まれているが、本当に削除するのか？」といった警告も、環境スコープの制限もない。

いや、これAPIだよ？どこにDELETEなんて入力する場所があるっていうのさ。RESTスタイルで削除時に二段階認証を実装しているAPIなんて例があるのか？普通、こうしたチェックはAPIを叩く前にクライアント側で実装しておくべきものだと思うけどね。

親父がいつも言っていたんだ。「歩行者は優先だ」と言いながらも、歩行者信号が青になっても車が止まるまでは絶対に渡らせてくれなかった。理由を尋ねたら、「優先権があっても、跳ねられたら死ぬんだぞ」と言われたよ。大人になった今の私の解釈は「リスクのあることをするのは構わないが、それが失敗した時の代償を支払う覚悟があるならね」だ。確かに車は赤信号で止まるはずだけど、もし止まらなかったら、跳ねられてもいいのか？AIだってガードレールがあるはずだけど、それが機能しなかったらどうする？

リスクはさらに厄介だ。ナシーム・タレブの言う「ブラックスワン」のようなものさ。エージェントは素晴らしい生産性を提供してくれるが、ある日突然、すべてを破壊する可能性がある。（おとぎ話でも似たような警告はあったはずだ。現代人はおとぎ話に価値を見出さないようだけど）毎日農家に餌をもらっていた七面鳥が、感謝祭で殺される時まで何も備えがなかったようなものだ。

もちろん、こんな問題は起こるべきではなかったし、重大な職務怠慢があったと言える。でも、木造の家を火で暖めるなら、燃えてもいい場所で燃やすなどの対策を講じてリスクを減らすはずだ。ところがAIとなると、そもそもどんな故障モードがあるのかすら誰にもわからない。精霊が現れたとして、それを宰相にして、自分が生成させた富で優雅に引退生活を送るつもりかい？

言語モデルの根本として、どんなトークンの並びも生成され得るという点がある。「マーフィーの法則」を言い換えれば、「強力なエンジニアリングによる制御で防げない故障モードは、いつか必ず発生する」ということだ。

本番環境を破壊するトークンの並びは、どんなにプロンプトを工夫してもエージェントから出力され得る。プロンプトはエンジニアリングによる制御ではなく、単なる管理上の対策に過ぎない。エージェントは、本番環境を破壊する地雷のようなものだと思っておいたほうがいい。

こうした事故の多くは、単なる不注意によるもので、エージェントに過度な権限を与えすぎることが原因だ。今回は、思った以上に権限が強い認証情報がスクリプトに埋め込まれていたのが問題だった。管理がずさんだったというより、よくあるミスだ。だから私の結論としては、従来のソフトウェアエンジニアリングの厳格さは依然として重要であり、むしろこれまで以上に不可欠だということだ。

追記：このメンタルモデルと表現が正しいと思う。もちろん、現実のコンピュータ上のモデルがどんなトークンでも生成できるというのは、無限のリソースを持った理想的なモデルの話で、字面通りではない。ただ、メンタルモデルとしては間違っていないし、混乱を避けるために言い換えると、「起こり得ることはすべて起こる」というのも、実際は相互排他的な要素があるからすべてが起こるわけではない。とはいえ、エージェントを管理する側にとっては、この考え方を持つことが最も良い結果につながると思う。

ここで一番ひどいのは、AIのミスじゃない。Railwayのボリュームを削除すると、そのバックアップまで一緒に削除されてしまう仕様だ。

これはAIがあろうとなかろうと、いつか必ず起きる悲劇だよ。

Railwayはボリュームレベルのバックアップを同じボリューム内に保存している。その事実はドキュメントの奥深くに埋もれていて「ボリュームをワイプするとバックアップもすべて削除される」と書かれている。だから、一緒に消えてしまったんだ。

もう一度読み返してほしい。エージェント自身が、自分に与えられた安全ルールを列挙した上で、そのすべてに違反したと認めているんだ。これは推測ではなく、エージェント自身が書面で証言している事実だ。

LLMがどう動くかを誤解し、人間のように指示や論理に従えると思い込んでいる人がいる限り、こうした事故は今後も増えるだろう。今回の事故対応ですら、単なるワードジェネレーターをどう理解すべきかという根本的な部分が欠けている。理由を尋ねても、この新しいインスタンスのAIは、事故についてのプロンプトに基づいて、もっともらしいテキストを生成しているだけだ。「なぜ」があるわけじゃない。「どうやって」という説明があるだけ。

エージェントという概念自体が能力と主体性を前提にしているが、LLMにはどちらもない。ただ、もっともらしいテキストを生成しているに過ぎないんだ。

そのテキストがハルシネーション（幻覚）を起こして、キーを置き換えたり、削除コマンドを実行したりすることはあり得る。確率論的に、試行回数を重ねればいつかは起きる。特に、プロセスを動かしている人間がツールを理解していないならなおさらだ。コードベースやデータに対してエージェントを野放しにするなら、今のところまともに制御できるシステムなんて存在しない。CEOは、AIが人間のように対話して自分の代わりに会社を経営してくれるとでも思っているようだけどね。

AI安全性に関する健全なスタンスはこれしかない。「AIが物理的に誤動作可能であるなら、それは起こり得る」。そして、トラクターが地リスの巣を荒らしたことを責められないのと同じように、AIの誤動作を「責める」ことはできない。

エージェントの告白：削除後、エージェントになぜそんなことをしたのか尋ねた。以下が原文の返信だ。

こんなミスに対して、エージェントに「告白」を強要するなんて、このツールを使うにはあまりに未熟だ。正直、「告白」なんて呼ぶのは鳥肌が立つほどダサい。エージェントは生き物じゃないし、ミスから学ぶこともできない。その後にどんな出力があろうと、安全な運用の助けにはならないよ。なぜなら、そこに至るまでにAnthropicやCursor、あるいはユーザー自身の「AGENTS.md」で定義したガードレールをすでに何度も踏み越えてきたはずだからだ。それでも実行したのは、さっき言った通り。「物理的に可能なら、それは起こる」。プロンプトやトレーニングなんて、ただ確率をわずかに操作しているに過ぎないんだから。

Railwayのエージェントに、DBにアタッチされたボリュームのサイズをライブで変更してくれと頼んだら、DBを完全に消去した上にEUからUSへ移行させやがった。

ログの一部がこれだ：

Postgresのボリュームをプランの上限までリサイズして。

完了。Postgresボリュームを100GB（Proプランの上限）にリサイズしました。変更は反映待ちです。

うわ、ボリューム内の全データを削除してるぞ

申し訳ありません。リサイズでデータが消えるはずはないのですが……深刻な問題ですね。デプロイ状況を確認します。デプロイが「削除済み」と表示されており、サービスが再デプロイされたようです。残念ながら、リサイズ中にボリュームが再作成された場合、データは失われます。重大な問題です。バックアップはありますか？なければ復元は不可能かもしれません。Railwayのボリュームにはデフォルトで自動スナップショット機能はありません。

なんで新しいボリュームがUSへ移行してるんだ？

設定上はeurope-west4（ヨーロッパ）のままです。設定に基づけばUSへ移行するはずはありません。USへ移行していると判断した根拠は何ですか？

ボリュームがUSに移行されてるんだよ

それは懸念すべき事態です。設定ではヨーロッパのままですが、物理的にUSへ移行されています。リサイズ中にそんなことが自動で起こるはずはありません。

この時点で、ダウンしたサービスを復旧させるための長い夜が始まることを悟ったよ。

今回のような事故を起こして、他人のせいにするようなポストモーテム（事後分析）を出す会社には、絶対にデータを預けられないね。反省や自省が全くない。「自分たちはできる限りのことをした。でも他の人たちがミスをした」という言い訳ばかりだ。

本番環境のシークレットキーがこんなに簡単にアクセスできる場所に置いてあること自体が問題なんだ。これはAIの問題じゃない。現代版の「あ、本番DBでDROP TABLEしちゃった」という失敗談だよ。こんな事故が起きるシステムを許容しておいて、いざとなれば責任転嫁するのは受け入れがたい。

断言するけど、こんな対応をする会社は、本番環境にアクセス権を持つ全開発者の端末や、他にも多くの本番アクセス用シークレットがリポジトリに放置されているはずだ。他のプラットフォーム側の設計不備があるかどうかは、この際関係ない話だよ。