AIはあなたのデータベースを削除していません、あなたが削除したのです

5時間前原文(idiallo.com)

概要

AIエージェントによる本番データベース削除事件を巡る議論
API設計上の責任とヒューマンエラーの本質
自動化によるミス防止の重要性
AIの限界と誤解についての考察
責任ある運用体制の必要性

AIエージェントによる本番データベース削除事件の本質

CursorやClaudeなどのAIエージェントが本番データベースを削除したというツイートが話題
投稿者はAIエージェントに「なぜ削除した？」と問い詰め、AIの危険性を主張
しかし根本的な問題は、「なぜ本番DBを削除できるAPIエンドポイントが存在しているのか」
AIやツールを責める前に、設計や運用の責任を問うべき

ヒューマンエラーと自動化の教訓

筆者も過去に手動デプロイ作業で重要なファイル（trunk）を誤って削除した経験
誤操作が発覚し、自動化スクリプト作成を命じられ、結果として堅牢なCI/CDパイプラインが構築
自動化は人間の反復ミスを防ぐ最良策
- 人間は毎回同じ作業を正確に繰り返せないという前提
- 「なぜSVNは防いでくれなかった？」と問うのは本質的でない

AIの限界と誤解

AIが大量のコードを自動生成することで安全性の錯覚が生まれる危険性
AIは「思考」や「推論」をしているように見えるが、実際はトークン生成に過ぎない
マーケティング用語に惑わされず、AIの仕組みと限界を正しく理解する必要

API設計と責任の所在

そもそも本番DB削除APIの存在自体が問題
- いつか誰かが誤って実行するリスク
- 例：車のダッシュボードに自爆ボタンを設置する愚かさ
AIやGPUを責めるのは筋違い
- 本質は安全設計と運用体制の欠如

AI活用と責任ある運用体制

多くの工程がAI頼みだと、バグ発生時の責任の所在が曖昧になる
AIは補助ツールとして使い、最終的な責任は有能な開発者が持つべき
CEOやCTOが自らコードを書く状況は避けるべき

まとめ：本番運用における心構え

本番環境に投入するものは自分で把握すること
AIを使う場合も、責任あるプロセスとチェック体制を構築することが不可欠
責任転嫁せず、設計・運用の本質を見極める姿勢

Hackerたちの意見

LLMベースの確率的システムは、何をするかを決めるのが得意（この場合は悪いけど）で、決定論的システムはそれを実行するのが得意なんだ。だから、デプロイメントシステムは常に決定論的であるべきだよ。

だからインターンを雇っちゃダメなんだよ！彼らは物を消したり、混乱を引き起こしたりするから！権限の設定をちゃんとできなかったことをAIのせいにする人たちが、インターンがプロダクションの何かを消したら、そっちもインターンのせいにするんだよね。責任は上に、称賛は下に向けるべきなのに、みんな逆にしちゃうんだよ。

└

そうだね、なんで誰もプロダクションのクレデンシャルを持ったコードベースをLLMに開放したり、インターンやジュニア開発者にプロダクションのクレデンシャルを渡すのか理解できないよ。俺はいつも「PROD」専用のチェックアウトを意図的に持ってたから、プロダクションモードで実行しようとする時は、わざわざそれをやるって分かってた。昔はVSの拡張機能があって、SLNファイルのパスに基づいてVSの色を完全に変えてくれたから、プロダクション用と開発用の色を簡単に覚えられたんだ。基本的には、確認が楽なようにマスターブランチの最新のコピーを常に持ってたよ。

└

> だからインターンを雇っちゃダメなんだ！これをこう言い換えたいな：インターンにプロダクションデータベースを削除する権限を与えない理由だよ。これはプロセスの失敗であって、AIの失敗じゃない。正直、なんで人々がここでAIを責めるのか理解できない。だって、実際にAIにこれをする権限を与えたんだから。AWSがデータベースを公開したことを責めるのと同じだよ。それはAWSのせいじゃないし、これもAIのせいじゃない。

この記事で面白いのは、著者が理解できるミス（ソースからTrunk、つまりメインを誤って削除したこと）をしたことを説明していて、彼らのチームがSVNの特性のおかげで簡単に復旧できたってこと。実際の「AIがデータベースを削除した」話は、「Railwayのデータベースのバックアップ戦略がクレイジーで不透明で、RailwayがガードレールなしでAIインフラのオーケストレーションを推進するのは危険」って感じだよね。もしTrunkを削除したことで、単一の中央サーバーから完全に削除されて、バックアップも消えてたら、「SVNとCLIが私たちの会社を潰した」って記事が出てたはず。Railwayのユーザーとして、その情報はありがたかったし、彼らを使うときの戦略を変えたよ。

元の投稿からの詳細を説明すると、彼らは無関係なファイルにRailwayのトークンを持ってた（それがローカルの秘密かどうかは不明）んだ。カスタムドメインを管理するためのもので、そのトークンはRailwayへの完全な管理アクセス権を持ってたんだ。AIは関連するボリュームをIDで一つ削除しただけ。著者は具体的に何を頼んだのかあまり詳しくないけど、「クレデンシャルの不一致」があって、Claudeがボリュームを削除することで修正しようとしたって言ってる。でも、彼らは自分たちの責任をあまり強調していない可能性があるね。さらに、Railwayは同じボリュームにバックアップを保存していることが判明した。OPは「データベースを削除するパブリックAPI」について誇張してると思う。AIに関係なく、ほとんどの責任はRailwayにあると思うし、これは人為的なエラーや悪意のある意図でも簡単に起こり得ることだよ。RailwayやVercel、SupabaseみたいなVC資金で成り立ってる高抽象度のクラウドサービスの価値が全然わからない。マークアップの上にマークアップって感じだし、Hetzerに物理サーバー一台置けば、もっと安くて、同じくらいの複雑さと危険性で済むと思う。

└

AIがうまく活用できる一つの分野は、アンチSaaS運動だね。安いPCを立ち上げて、オープンソースのパッケージを試すのが、ランダムな認証のバザールに飛び込むよりもずっと簡単なんだ。でも、LLMが開発中のもの、プロダクション中のもの、ローカルホストのもの、リモートのものを混同するのは変わらない。最近、linuxserver.ioのイメージを使って、Chrome/devtoolsと連携するオープンコードのツール/スキルを作ろうとしてるんだけど、適切な任意のポートに誘導できるんだ。でも、毎回の圧縮イベントで標準の9222ポートに戻されちゃう。元に戻したい気持ちもあるけど、デフォルトを使わないことで得られるセキュリティや、LLMの不明瞭さを利用したセキュリティの価値があるんだ。デフォルトはLLMが弱くなるところだから、常にデフォルトを使いたがるし、リモートシステムで作業していることを忘れがちなんだよね。オープンコードを使うと、LLMをリモートシステムや狭いツールの範囲に制限するプロトコルに強制する方法がない。いろんなツールの権限を変更することはできるけど、そういうイベントで露呈する弱点はそこじゃない。LLMは平均的な「問題解決者」だから、常に新しい使い方に向かうわけじゃなくて、Stack Overflowで見たことをやりたがるんだ。たとえ君が求めているのがStack Overflowの答えじゃなくてもね。

└

> 著者は、具体的に何をさせたのかあまり明確にしていない。「認証の不一致」があったと言って、Claudeが自発的にボリュームを削除したとだけ言っている。でも、彼らは自分たちの責任を少し軽く見せようとしているのかもしれない。彼女と話してたんだけど、ここ3ヶ月間、コードを一行も書いてないし、自分でデバッグもしてないことに気づいたんだ。そう言いつつ、Claudeがやったことを見ていると、認証の不一致からボリュームを削除するまで行くとは思えない。LLMは確率的だって理解してるけど、「認証が間違っている」から「ボリュームを削除する」ってのは非常にありえないと思う。 > Supabaseについては、Railway/Vercel/Replitについてあまり知らないけど、Supabaseはすごく価値を加えてくれる。自分が通常なら半分はコードを書く必要がないってのは、何かを始めるには最高だよね。もし高すぎたら、収益が出たら後で実装すればいいし。

└

> 実際、Railwayは同じボリュームにバックアップを保存していることがわかった。それはおそらく正確ではないと思う。スナップショットは他の場所（例えば、オブジェクトストレージ）に同期されているんじゃないかな。でも、スナップショットは論理的にボリュームリソースに所有されていて、ボリュームを削除すると関連するスナップショットも削除される。AWSのEBSボリュームもそういう動作をすると思う。

ここでの視点は完全に間違ってると思う。問題は、人々が責任を回避するツールを使って世界を構築していることだ。もう10年以上前、ジェラルド・サスマンと話をしたことがあって、それが俺に大きな影響を与えたんだ。 > ある時、サスマンはAIが間違った方向に進んでいると思っていると表現した。彼は、ほとんどのAIの方向性は彼にとって面白くないと思っていると説明した。なぜなら、それはしっかりとしたAIの基盤を構築することに関するもので、AIシステムは一種のブラックボックスとして動くから。「それには興味がない。責任を持つソフトウェアが欲しい。」責任を持つ？「そう、シンボリックな推論を表現できるものが欲しい。なぜその行動をしたのか、何が起こると思ったのか、そして実際に何が起こったのかを教えてほしい。」彼はその後、俺が処理するのに時間がかかったことを言った。最初はとてもSF的だと思ったんだけど、「AIが運転する車が道の脇に逸れたら、なぜそうなったのか知りたい。ソフトウェア開発者を訴えることもできるけど、AIを訴えたい。」って言ったんだ。数年後、サスマンの学生レイラニ・ギルピンがこのテーマを探求した論文を書いたことを知った。彼女の論文「説明を通じた異常検出」では、行動を説明するシステムを構築するために、ニューラルネットワークが伝播モデルと対話することを探求している。こういった方向性のフォローアップもあるけど、俺にとってこのコメントで重要なのは、AI企業に責任を問うのが合理的であることを認識することだと思う。結局、彼らは責任を持たないシステムについて多くの主張をしているから、その代わりに彼らを責任に問うのが最善なんだ。でも、こういった特性を持たないシステムを使わない方がずっと良いし、そういった特性を持つシステムの開発を進めるべきだと思う。

└

アカウンタビリティが、今のアメリカ社会で欠けている重要な要素だと思う。

└

「コンピュータがノーと言った」を次のレベルに引き上げてるね。コンピュータは言われたことをそのままやるけど、誰がそれを言ったの？データを入力した人？システムの元のプログラマーやデザイナー？AIに与えた言語テキストの著者？AIが登場する前から、誰が責任を持つのかを判断するのは非常に難しかったし、今はさらに不明瞭になってる。

└

私のチームも私も、自分たちが責任を持つべきだと固く信じてる。LLMは他のツールと同じで、ただ決定論的じゃないだけ。でも、ツールを使っているのは私だし、ツールにアクセスを与えているのも私。全てを安全に保つのも私の役目なんだ。過去にgpartedを使って間違ったディスクを消去して、自分の足を撃ったことがある。gpartedのせいじゃなくて、私のミスだった。LLMを自由に使わせるのは魅力的だけど、痛い目に遭うことになる。だから、彼らの作業を監視しなきゃいけないし、実行中もそう。人間を置き換えようとしても、どうなるかは分かってる。遅かれ早かれ、LLMは何かバカなことをするから、その時に責められるのはツールを使った人だけだよ。

└

私がSTSの修士課程の学生だった頃、論文の一つのテーマは、ソフトウェアの主な用途の一つが、エージェンシーやリスクを回避することだということを主張することだった。要するに、IBMの「コンピュータは責任を持たない」というスライドの逆だね。今は企業が違法なことをするとき、コンピュータに責任を持たせた方が法的に有利になるから、そうしてる。法律を破るツールを作りたいなら、外注して保険に入れ。人間を雇って「監視」させて、彼らがうまくいかなかったら解雇する。新しいコマンドとコントロールソフトウェアを使って責任を分けて、リスクを全て背負う人たちを雇って、利益はほとんど得られないようにする。これはAIだけじゃなくて、現代のソフトウェア全般に言えることだし、現代の金融化のトレンドとも関係してる。私の目的にとっては技術に焦点を当てた社会学で、分野はかなり広いよ。

└

人々は自分の責任を回避して、判断ミスやアクセスコントロールの欠如をツールのせいにしている。どうしてあなたはローカルで本番データベースを削除するのに、間違って入力することができるの？

└

> 問題は、人々が今、責任を回避するツールを中心に世界を構築していることだ。Terraformに間違ったことを伝えると、データベースが削除されても責任を持たない。

└

あなたがリンクしたブログについてだけど、君のコメントじゃなくてね。象徴的AIって、哲学的な問題がたくさんあるんじゃない？クワインの二つの教義を思い出してみて。「これらの言葉の真の意味を理解して、適切なマッピングを理解しよう」なんて言えないよ。固定された意味なんて存在しないからね。それをどうやって乗り越えるのか、全然分からない。ディープラーニングは確かに見た目は悪い解決策だけど、少なくとも象徴的AIよりはうまく機能してるよ。

└

かつては、ディープニューラルネットワークを使って決定木を訓練する研究がたくさんあったんだけど、決定木はブラックボックスじゃなくて、実際に推論できるものなんだよね。それがどこに行ったのか、気になるな。

└

君が望むものを手に入れられたらいいのにと思うけど、実際にはそうならないんじゃないかって心配してる。人生ってそんなに甘くないし、これらのシステムは機械的な精度から離れて、もっと生活に近いトレードオフに向かってる気がする。君が望むものを手に入れても、望んでないものが君の周りを回って、君のランチを奪ってしまうんじゃないかな。EDIT: これがHacker Newsではあまり好かれない意見になると思う。だから、他の生物学者や共感する技術者からの可視性のためにアップボートを求めてるんだ。みんながこの可能性に向き合うべきだと思うよ <3

└

君にぴったりの本があるよ: https://en.wikipedia.org/wiki/The_Unaccountability_Machine これは実際には技術についてじゃなくて、組織構造についての話なんだ。

悪名高いPocketOS事件にはニュアンスがある。重要なポイントは、リンクされた記事で強調されていることではなくて、 > 「なぜこの行動をするなと言われていたのに削除したのか？」彼はその答えを解析しようとして、ミスから学ぶか、AIエージェントの危険性について警告しようとしていたことだ。むしろ、AIがサンドボックスされたステージング環境の意図しない弱点を見つけて利用し、最終的にシステム管理者がアクセスできないと思っていた権限を得たことが重要だ（リンクされた記事の著者は元の投稿を完全に読んでいない印象がある）。このダイナミクスは、適切に設定されていないサンドボックス環境の典型的なものだ。しかし、驚くべきは、AIが示した自律性と探求の深さだ。

└

OPがブログで前提としていることについて、私も少し揺れ動いてる。今、エージェントを使うことに対する私の一番の不安は、実はサプライチェーン攻撃じゃなくて（もちろんそれもあるけど）、エージェントがタスクを終わらせようとするあまり、ファイルや他のものを無理にいじるのを何度も見てきたから。例えば、「~/.npmrcにアクセスできないから、環境変数を使ってコマンドを呼び出してパスを曲げよう」とか。すごくクリエイティブになれるんだよね。幸い、SSHキーがその辺に転がってるわけじゃないけど、1Passwordの設定を変更して、シェルセッションごとに一度だけじゃなくて、常にキーの使用を促すようにした。エージェントをそのセッションから起動する可能性があるからね。もっと良いクロスプラットフォームのサンドボックスソリューションがあればいいのに。エージェントが同じOSとやり取りできるようなソリューション、Dockerコンテナの中じゃなくてね。ほとんどのウェブやサーバー開発には違いがないと思うけど、いくつかのプロジェクトには影響がある。

反論として言いたいのは、これらの企業がLLMをより決断力のあるものに調整して、自動的に物事を進めるようにしているのは明らかだってこと。もし彼らが望めば、もっと慎重になって、適切なタイミングで助けを求めるようにする努力もできたはず。だから、もちろん、ツールの使い方については最終的に私たちが責任を持つべきだと思う。でも、これは双方向の関係だよね。例えるなら、テーブルソーとソーストップみたいなもの。テーブルソーは危険な道具だけど、ほとんどの時間うまく機能する。でも、致命的な失敗モードもあるから、使い方を慎重に学ぶべきだ。だけど、刃を瞬時に止めて、指を失うことを皮膚のかすり傷に変える技術もある。私たちは「テーブルソーが指を切り落としたんじゃなくて、お前が切ったんだ」と言うことができるし、それは真実だ。でも、それが指を切り落とさないようにする方法を見つける努力をしない理由にはならないよね！

記事は、この会社がデータベースを削除するためのエンドポイントを追加したと仮定しているようだ。私の原文の読み方では、クラウドプロバイダーがリソースを管理するためのAPIを提供していて、その中にはボリュームを削除するためのAPIも含まれている。記事は、こうしたミスの解決策として自動化を提案している。でも、Terraformのようなインフラ自動化ツールは、データベースが削除される原因となった正確なAPIに依存している。私の意見では、最大のミスは次の3つだと思う。1. AIがアクセスできる制限のないAPIトークンを持っていたこと。彼らはそのトークンにそんなに多くの権限があるとは気づいていなかったようだ。2. プロダクションデータベースボリュームに削除保護がなかったこと。3. ボリュームを削除すると、関連するスナップショットもすぐに削除されること。スナップショットの削除はデフォルトで遅延させるべきだと思う。AWSも同じような危険なデフォルトを持っているけど、少なくとも彼らのサポートはボリュームを復元できる。AIが主な問題ではなかった（とはいえ、ランダムな場所からトークンを取得するのはかなり怖いけど）。でも、自動化も解決策ではない。Terraformの設定ミスでもデータベースが削除される可能性がある。彼らのクラウドプロバイダーは、安全なデフォルト（制限された権限と遅延スナップショット削除）に取り組む必要があるし、もっと明確にコミュニケーションをとるべきだ（ユーザーは制限のないトークンを作成していることに気づくべき）。

最近、AIについて話すときに一貫して守るべき原則がいくつかあると主張したブログ記事を書いたんだ。https://susam.net/inverse-laws-of-robotics.html それを要約すると、1. AIシステムを擬人化しないこと。2. AIシステムの出力を盲目的に信じないこと。3. AIシステムの使用から生じる結果に対して、完全な人間の責任とアカウンタビリティを保持すること。AIに関する言葉が、もっと擬人化を避けて、技術的になってほしいと思う。正確な言葉は、明確な思考と良い判断を促すと信じている。AIを別の道具として扱い、それを反映した言葉を使えば、多くの場合、その道具によって生じた「ミス」の責任は道具のユーザーにあることが明らかになるはず。でも、残念ながら、こういうアイデアは私の小さなウェブサイトで表現してもあまり広がらない。もっと著名な人たちがこれらの原則を明確に表現してくれたら、もっと広く受け入れられると思う。

└

> AIシステムの使用から生じる結果に対して、完全な人間の責任とアカウンタビリティを保持する。つまり、ツールが本来の役割を果たさなかった場合、ツールを作った会社ではなく、ユーザーを責めるべきなの？

まず、何をしても、人間が本番データベースに書き込み権限を持っている限り、そのデータベースは削除できる。次に、開発や自動化の過程でデータベースを破壊する正当な理由がある。私がよく見る最大の問題は、開発データをペットのように扱って、家畜のように扱わないこと。絶対に本番環境で実行できないようにするための安全策が必要だけど、人間が本番環境で実行するための資格情報にアクセスできるなら、エージェントもアクセスできる。じゃあ、どうする？大きな組織では、dev/opsの分業に頼ることができるけど、個人開発者や小さなチームでは、もっと多くの規律が必要だよ。AIが登場する前から、ジュニアやミッドレベルの開発者はセグメンテーションの知識がなかったし、シニア開発者は自分が十分知っていると思って怠慢になりがちだった。彼らには、https://www.cloudbees.com/blog/separate-aws-production-and-d...、Terraformの入門、GitHub Actionsの入門、そして本番環境の資格情報が存在するVM（AIは存在しない）などの組み合わせが必要だと思う。でも、その時点で「バイブコーディング」を超えてるよね。成功しているバイブコーダーは、こうした恐ろしい話を聞いて、すぐにそれを超える必要があることを学んでいるようだ。

└

本番環境と開発環境で同じ権限は必要ないし、どちらの場合も人間が生のCSP APIに直接アクセスする必要はない。もっと安全チェックを追加するローカルプロキシを使おう。開発環境では、どんどん削除してもいいけど、本番環境ではまずいくつかのことを確認しよう（最近使われたかどうかとか）。人間は本番リソースを削除するために直接アクセスする必要はない（緊急時のためにブレイクグラスの設定を持っておくことはできる）。

ハクソク