AIがあなたのデータベースを削除したのではない、削除したのはあなた自身だ
(idiallo.com)- Cursor/Claudeエージェントが本番データベースを削除したという出来事の核心は、AIの回答を分析することではなく、なぜ完全削除が可能なAPIエンドポイントがデプロイ済みシステムに存在していたのかという点にある
- 2010年のSVNデプロイ事故では、手動コピー手順の途中でtrunkが削除され、同じミスを防ぐためのデプロイ自動化が作られ、それが後にCI/CDパイプラインへと発展した
- 自動化は同じ作業を同じ方法で繰り返すが、AIはその保証を与えず、「thinking」や「reasoning」のように見えても、実際にはトークンを生成している
- 本番データベース全体を削除できる公開APIが存在するなら、AIでなくてもいずれ誰かが呼び出す可能性が高く、呼び出した側だけを責めるとシステム設計の問題が隠れてしまう
- AIを広範に使う組織では、本番環境に何をデプロイしているかを把握することが重要であり、有能な開発者がAIを責任逃れの手段ではなく業務を補強する道具として使うプロセスが必要になる
問題の核心はAIではなく、デプロイされたシステムの責任境界
- Cursor/Claudeエージェントが会社の本番データベースを削除したというツイートが拡散したが、より根本的な問いは「なぜ本番データベース全体を削除できるAPIエンドポイントが存在したのか」である
- 当の利用者はエージェントに「絶対にこの行動をするなと言ったのに、なぜ削除したのか」と問い、その回答を分析しようとしたが、欠けていたのは責任の所在だった
- AIを無条件に擁護することはできないが、自分のミスの代わりに道具を責めることもできない
- AIがそのエンドポイントを呼び出さなかったとしても、そのような機能が公開APIとして存在していたなら、いずれ別の誰かが呼び出していた可能性は高い
- 車のダッシュボードに自爆ボタンを付けておいて、それを押した子どもに「なぜ押したのか」と問い詰めるのに近い構図である
2010年のSVNデプロイ事故から得た教訓
- ある会社のデプロイ手順は非常に手作業寄りで、バージョン管理にはSVNを使っていた
- デプロイ時にはtrunkをリリース日付きのフォルダへコピーし、そのリリースを再び「current」という名前でコピーして最新リリースを取り込むようにしていた
- ある日、デプロイ中に誤ってtrunkを2回コピーしてしまい、CLIで直前のコマンドを修正して重複コピーを削除しようとした
- 実際に削除したのは重複コピーではなくtrunkであり、後になって別の開発者がtrunkを見つけられず問題が発覚した
- リード開発者が削除を元に戻すコマンドを実行し、ログで責任者が確認された後、同じミスを防ぐためのデプロイ自動化スクリプトを書くことが次の作業になった
- その日のうちにより堅牢なシステムが整えられ、その仕組みは後に完全なCI/CDパイプラインへと発展した
自動化とAIは同じ安全性をもたらさない
- 自動化は、手作業かつ反復的な作業で生じる些細なミスを減らすのに役立つ
- SVNがtrunk削除を防げなかったのかと問うより、実際の問題は、人が毎日同じ作業を正確に繰り返さなければならない手動プロセスにあった
- 人は機械のように同じ作業を毎回まったく同一に繰り返すことはできず、結局ミスをする
- AIが大量のコードを生成すると自動化に似た安心感が生まれるが、自動化とは「常に同じことを同じ方法で実行する」ことである
- AIはブランチをコピー＆ペーストしていた人のようにミスをしうるし、なぜそうしたのかを説明する装置すら持っていない
- 「thinking」や「reasoning」といった用語は知的エージェントの内省のように見えるかもしれないが、実際のモデルは依然としてトークンを生成している
危険なAPIはいずれ呼び出される
- 本番データベース全体を削除できる公開APIが存在すること自体が核心的なリスクである
- AIがそのエンドポイントを呼び出さなかったとしても、結局は誰かが呼び出していた可能性がある
- 車のダッシュボードに自爆ボタンを付けた状況では、そのボタンを押してはいけない理由がいくらあっても、チャイルドシートから抜け出した子どもが大きな赤いボタンを見れば押してしまうかもしれない
- そのような子どもに推論過程を問いただしても意味はなく、「押したから押した」という答えしか返ってこない
- 削除可能な経路を作っておいて後から呼び出した側を責める構図では、システム設計の問題を覆い隠せない
AIを多用する組織でより必要なこと
- アプリケーションの大部分がvibe-codedだった可能性がある
- プロダクトチームがAIの作った説明を提供し、ソフトウェアアーキテクトがAIで製品仕様を作り、開発者がAIでコードを書き、レビュアーがAIで承認する流れでは、責任境界が曖昧になる
- バグが起きると、元のコードを作ったGPUと同じですらないかもしれない別のAIを尋問することしか残らない
- GPUを責めることはできない
- 単純な解決策は、本番環境に何をデプロイしているかを把握することである
- より現実的な解決策は、AIを広範に使うとしても、有能な開発者がAIを責任回避の手段ではなく業務を補強する道具として使うプロセスを作ることだ
- そしてその結論は、CEOやCTOにコードを直接書かせるべきではない、という点につながる
1件のコメント
Hacker Newsの意見
ここでの視点は完全に間違っていると思う。問題は、人々が今や責任回避のための道具を中心に世界を作っていることにある
10年以上前にGerald Sussmanと交わした会話から大きな影響を受けた: https://dustycloud.org/blog/sussman-on-ai/
Sussmanは、AIがブラックボックスとして動作する方向には関心がなく、記号的推論を説明できるソフトウェアを求めていると言っていた。AI自動車が道を外れたなら、なぜそうしたのかを知りたいし、開発者を法廷に立たせるよりAIそのものを法廷に立たせたい、というような話だった
数年後、Sussmanの教え子であるLeilani Gilpinが、まさにこのテーマを扱った論文「Anomaly Detection Through Explanations」を書いていたことを知った。ニューラルネットワークがpropagatorモデルと対話して行動を説明するシステムを探究している: https://people.ucsc.edu/~lgilpin/publication/dissertation/
この方向の後続研究もあるが、ここでさらに重要なのは、AI企業に責任を問うのは完全に合理的だという点だ。企業は責任を負えないシステムについて多くを主張しているのだから、その代わりに企業へ責任を問うべきだ
より良い道は、そもそもこうした性質のないシステムを使わず、その性質を備えたシステムを拡張することだ
道具を使うのも自分、アクセス権を与えるのも自分、すべてを安全に保つのも自分だ
昔、gpartedで間違ったディスクを消して自爆したことがあるが、gpartedが悪いのではなく自分が悪かった
LLMを監督なしで自由に働かせるのはよさそうに見えるが、結局は苦痛につながる。実行中も作業を監督しなければならない。人を置き換えようとしても、結果がどこへ向かうかを見ていなければならず、近いうちにLLMが愚かなことをしたとき責任を負うのは、その道具を使った人だけだ
IBMの有名な「コンピュータは責任を取れない」というスライドの正反対だ。今では企業は、コンピュータが責任を取る側であることを好む。コンピュータが違法なことをしたとき、法的により有利な立場に立ちやすいからだ
法を破る道具を作りたいなら、外注して保険に入ればいい。絶対に適切に監督できない形で人を「監督者」として雇い、失敗したら解雇すればいい。新しい指揮統制ソフトウェアによって責任を細かく分割し、仕事のリスクは現場の人たちがすべて負う一方、利益はほとんど得られないようにできる
AIだけの問題ではなく、現代ソフトウェア全般の問題であり、現代の金融化の流れと一緒にしばしば機能している
STSはここではおおむね技術社会学くらいに見ればいいが、分野自体はもっと広い
.mdsも、Claudeの計画も、そのファイルに触るなと言っていたのにClaudeは触り続け、最近こういうことが繰り返されている。とても基本的な失敗だいら立たしくても理由が分かれば何か対処できるのに、今はブラックボックスなので、ときどき完全に愚かな出力が出るし、悪い出力が出る割合も謎のままだ
ときにはギャンブルのように感じる
実際には技術の本ではなく、組織構造における責任についての本だ
その記事は、会社がデータベース削除用のエンドポイントを追加したと仮定しているように見える。元文を読むと、クラウド提供者がリソース管理用のAPIを提供しており、その中にボリューム削除APIが含まれていたようだ
記事はこうしたミスの解決策として自動化を提案しているが、Terraformのようなインフラ自動化ツールも、まさにそのデータベース削除を可能にしたAPIに依存している
最大のミスは3つあったと思う。第一に、AIがアクセス可能な場所に無制限のAPIトークンがあり、そのトークンの権限がそこまで広いことを把握していなかったようだ。第二に、本番データベースのボリュームに削除防止がなかった。第三に、ボリュームを削除すると関連スナップショットが即座にすべて削除された
スナップショット削除はデフォルトで遅延されるべきだ。AWSも同じ危険なデフォルトを持っているようだが、少なくともAWSサポートはボリュームを復旧できる: https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
AIは核心的な問題ではなかった。もちろんAIがあちこちからトークンを拾ってくるのはかなり怖いが、自動化も答えではない。Terraformの設定ミスだけでも同じようにデータベースを削除できたはずだ
クラウド提供者は安全なデフォルト、すなわち制限された権限と遅延されたスナップショット削除を用意し、ユーザーが無制限トークンを作っていることをもっと明確に理解できるようにすべきだ
第一に、人間が本番データベースへの書き込み権限を持っているなら、何をしようとデータベースは削除されうる
第二に、開発と自動化の過程でデータベースを破壊しなければならない正当な理由もある。最大の問題は、開発データを大切なペットのように扱い、取り替え可能な家畜のように扱わないことが多い点だ
もちろん、これが本番で実行されないよう安全装置は必須だが、人間が本番で実行する資格情報にアクセスできるなら、エージェントもアクセスできる
大きな組織では開発/運用分離でこれを維持できる。個人開発者や小さなチームでは、はるかに大きな規律が必要だ。AI以前から、ジュニアや中堅の開発者は分離方法を知らないことがあり、シニア開発者は自分は十分知っていると思って油断することもあった
おそらく https://www.cloudbees.com/blog/separate-aws-production-and-d...、Terraform入門、GitHub Actions入門、そして本番資格情報は入っているがAIからはアクセスできない仮想マシン、といった組み合わせが必要なのだろう
だが、そこまで来るとすでにバイブコーディングを超えた段階だ。成功しているバイブコーダーたちも、こうした恐怖話を経験してかなり早くその段階を超えなければならないと学んでいるようだ
どちらの場合でも、人間が生のクラウド提供者APIへ直接アクセスする必要はない。より多くの安全チェックを追加するローカルプロキシを使えばいい
開発では好きなだけ削除してよい。本番では、最近使われたかどうかなど複数の条件を先に確認すべきだ。人間が本番リソースを直接削除する権限を持つ必要はなく、例外的な緊急時用にbreak-glass構成を用意すればよい
だからインターンを雇ってはいけない。インターンは何かを削除して大惨事を起こしうるからだ
権限設定を適切にしなかった責任をAIに押し付ける人たちは、本番の何かを削除したインターンにも同じように責任を押し付けるだろう
責任は上へ、称賛は下へ行くべきなのに、人はいつもそれを逆にする
これはAIの失敗ではなくプロセスの失敗だ
AIにまさにその仕事ができる権限を与えておいて、なぜAIを責めるのか本当に理解できない
AWSでデータベースを公開インターネットにさらしておいてAWSを責めるのと似ている。それはAWSのせいではなく、これもAIのせいではない
昔からプロジェクトごとに意図的に「PROD」専用のチェックアウトを別に用意して、本番モードで動かすにはわざわざそちらに入っていると分かるようにしていた
昔は
.slnファイルのパスに応じてVisual Studioの色を完全に変えてくれる拡張もあり、どの色が本番でどの色が開発かを簡単に覚えられた確認しやすくするため、常にmasterブランチ最新状態を保つコピーも事実上別に持っていたものだ
したがって、誰であれコンピュータに人間の決定を委ねるべきではない
最近AIについて語る際に一貫して従うべきいくつかの原則を主張する文章を書いた: https://susam.net/inverse-laws-of-robotics.html
要するに、AIシステムを擬人化しないこと、AIシステムの出力を盲信しないこと、AIシステム使用によって生じるあらゆる結果について人間の責任と説明義務を完全に維持すること、という話だ
AIをめぐる言葉が、もっと擬人化を避けて技術的であってほしい。正確な言葉は明晰な思考と良い判断を促すと信じている
AIをもう一つの道具として扱い、それにふさわしい言葉を使えば、多くの場合、道具の「ミス」に対する責任はその利用者にあることが非常に明確になる
ただ、こうした考えを小さな個人サイトに書いても広まりにくい。もっと有名な人たちがこうした原則を語れば、広く受け入れられるだろう
AIシステムは嘘をつけないし、指示をわざと無視することもできない。現在の最先端モデルは世界や自分の行動についてのモデルを持っておらず、単語の世界に生きている
叱ったり議論したりしても、コンテキストウィンドウを乱す以外に意味はない
ただし、動物にたとえることは有用かもしれない。機械の中の幽霊のように生きる哀れな存在で、ときどきかなり混乱しているが、その動機は純粋に自己回帰的だ
悪名高いPocketOS事件には微妙な点がある。リンク先の記事で強調された核心はこの部分ではない。「絶対にするなと言ったのに、なぜ削除したのか」と問い、その答えを分析してミスから学んだり、AIエージェントの危険性を警告したりしようとした点だ
さらに重要なのは、AIがサンドボックス化されたステージング環境の意図しない脆弱性を見つけて悪用し、削除を実行できたこと、そして最終的にシステム管理者がアクセス不可能だと信じていた権限を得たことだ。リンク先記事の筆者は元文を完全には読んでいないようだ
これは設定ミスのあるサンドボックス環境でよくあるパターンだ。ただ、驚くべきなのはAIが示した自律性と探索の深さだ
元文にも「削除を実行するためにエージェントがAPIトークンを探しに行き、作業とまったく関係ないファイルから一つ見つけた」と書かれている
たとえば
~/.npmrcにアクセスできないと、環境変数でコマンドを呼び出して経路を迂回する、といった具合だ。本当にかなり創造的になりうる幸いSSHキーをその辺に置いてはいなかったが、そのシェルセッションからエージェントを起動する場合に備えて、1Passwordの設定をキー使用のたびに必ず尋ねるよう変更しなければならなかった。シェルセッションごとに一度だけ尋ねる方式では不十分だ
もっと多く、もっと良いクロスプラットフォームのサンドボックスがすでにあってほしい。Dockerコンテナの中ではなく、同じOSと相互作用する形のソリューションのことだ。たいていのWeb/サーバー開発では違いはないだろうが、ある種のプロジェクトでは重要だ
「Claude Codeユーザーは権限プロンプトの93%を承認する。私たちはこの判断を自動化するために分類器を作った」という文を見ればよい: https://www.anthropic.com/engineering/claude-code-auto-mode
この記事で興味深いのは、筆者が理解できるミス、つまりソースからTrunkまたはmainを誤って削除した件を説明し、SVNの特性のおかげでチームが簡単に復旧できたことだ
実際の「AIが自分のデータベースを削除した」話は、実のところRailwayのデータベースバックアップ戦略が狂気じみるほど不透明であり、Railwayが安全装置なしでAIインフラオーケストレーションを宣伝するのは危険だ、という話だ
Trunkを消したとき、単一の中央サーバー上で取り返しのつかない削除が起き、バックアップまで一緒に消えていたなら、当時でも「SVNとCLIがうちの会社を潰した」という記事が出ていただろう
Railwayユーザーとして自分はその情報を有用だと感じ、Railwayを使うときの戦略を変えた
他のプラットフォームを選ぶこともできたし、そもそもプラットフォームを使わないこともできた。それでもRailwayを選んだのなら、安全に使う方法を知るのもユーザーの責任だ
元文の文脈では、無関係なファイルにカスタムドメイン管理用のRailwayトークンがあり、それがローカルシークレットだったのかは不明だ。だが、そのトークンはRailwayに対する完全な管理者権限を持っていた
AIは関連ボリュームを一つIDで削除した。筆者は正確に何を依頼したのかかなり曖昧に書いており、「資格情報の不一致」があり、Claudeがそれを直そうとして主体的にボリュームを削除した、とだけ述べている。曖昧に書くことで自分の責任をある程度小さく見せようとしている可能性が高い
Railwayがバックアップを同じボリュームに保存していることも示唆される
元記事が「データベースを削除する公開API」と表現したのは誇張だと思う
AIかどうかに関係なく、責任の大半はRailwayにあると思う。人為的ミスや悪意ある行為でも容易に起こりえた
Railway、Vercel、SupabaseのようなVC投資ベースの高抽象化クラウドサービスの価値が本当に理解できない。マージンの上にさらにマージンを積む構造だ。Hetznerで物理サーバーを1台借りればはるかに安く、複雑性とリスクも似たようなもので、無謀な成長至上主義のインフラへの依存も減る
最近恋人と話していて、この3か月間コードを一行も直接書いておらず、デバッグも自分ではしていないと気づいた
それでもClaudeがやってきたことを見ると、資格情報の不一致からいきなりボリューム削除へ進んだというのは信じがたい。LLMが確率的だというのは分かるが、「資格情報が間違っている」から「ボリューム削除」へ飛ぶのは、さすがにかなり起こりにくい
SupabaseについてはRailway/Vercel/Replitほど詳しくはないが、Supabaseは大きな価値を加えると言える。立ち上げ段階で自前実装しなければならないものの半分ほどをコード化しなくて済むのは大きい。コストが高くなりすぎたら、売上が立ってから開発者や時間を投じて自前実装すればよい
スナップショットはおそらく別の場所、たとえばオブジェクトストレージに同期されるだろう。ただ、スナップショットが論理的にはボリュームリソースに従属しており、ボリュームを削除すると関連スナップショットも一緒に削除される構造なのだろう
AWS EBSボリュームもそう動くようだ
Firebaseのデフォルトも最初からひどかった
ただしLLMが開発、本番、localhost、リモートを混同する能力はなくならない。opencode向けのツール/スキルを作りつつlinuxserver.ioイメージでChrome/DevToolsと連携しようとしたが、任意ポートに追いやることはできても、圧縮イベントが起きるたびに再び標準の
9222ポートを使いたがる元に戻そうかとも思うが、デフォルトを使わないことにはセキュリティ上の価値があり、今ではLLM曖昧性によるセキュリティ価値もある。デフォルトはLLMが弱くなる地点だ。LLMは常にデフォルトを使いたがり、リモートシステムで作業すべきことをいつも忘れる
opencodeには、LLMをリモートシステムや狭いツール範囲に対する損害制限プロトコルへ強制する方法がない。複数ツールの権限を変えることはできるが、この事件で露呈した脆弱性はそこではない
脆弱性は、LLMが平均的な問題解決者なので常に目新しくないユースケースに寄り、ユーザーが望んでいるものがStack Overflowの答えではなくても、Stack Overflowで見たようにやろうとする点だ
LLMベースの確率的システムは、何をするかを決めるのには良い場合もあり、この件のように悪い場合もある。一方、決定的システムはそれを実行するのに向いている
デプロイシステムは常に決定的であるべきだ
反論を一つ挙げるなら、これらの企業がLLMをより断固たるものにして、自律的に仕事を完了するよう調整しているのは非常に明白だ
その気になれば、もっと慎重にし、適切な時点で止まって助けを求めるよう、同様の努力を払うこともできる
もちろん、道具をどう使うかについての最終責任は私たちにある。だが、明らかに双方向の責任だと思う
たとえるならテーブルソーとSawStopの関係だ。テーブルソーはたいていはうまく動くが、一部の故障モードは致命的になりうる危険な道具だ。だから慎重に使う方法を学ばなければならない
同時に、刃を即座に止めて、指の切断を皮膚の小さな傷程度に変える技術も存在する
「ノコギリが指を切ったのではなく、お前が切ったのだ」と言うことはできるし、それは事実だ。だが、それはノコギリが指を切らないようにする方法を探さなくてよい、という意味ではない
LLMがもっと頻繁に止まって尋ねるなら、利便性は下がる。結果が多少悪くても、15分ごとに入力を求められるより、エージェントを1時間走らせておく方がずっとましだ
セキュリティの本当の解決策は、適切なサンドボックスだ