「“コーディングエージェントが私たちのプロダクションデータベースを削除しました”ってツイートを書くのにLLMを使うのって、なんかダークなコメディーみたいだよね。別の話だけど、ユーザーがコーディングエージェントに“なんでそんなことしたの？”って聞くのは、エージェントの動作についての誤解を示してると思う。エージェントは何かを決めてそれを実行するんじゃなくて、ただテキストを出力するだけなんだよね。それに、Anthropicがいろんな変更を加えたせいで、文脈や思考過程が見えにくくなってるから、もしかしたらその可視性を取り戻そうとしてるのかも。」

「Twitterユーザーは、こういう『記事』に対してエンゲージメントに基づいて報酬をもらうんだよね？それが、こんなにドラマチックになる理由かも。」

>「ユーザーの心の中の誤解」 それに加えて、エージェントはLLMが指示したことをやってるだけなのに、なんでこの投稿ではOpusが親のようにしか触れられないんだろう。確かに、Cursorは安全性を謳ってるけど、それを提供できてないし、ツールコールを発行したのはモデルの方なんだよね。こういう人たちが、自分たちのデータが安全だと思って、同じものにアクセスできるエージェントを使えば大丈夫だと思ってるなら、痛い目にあうよ。記事から見ると、どうやら指示があったみたいで：>「絶対に推測するな！」 推測することが全てのポイントなのに、トークンを順番に推測すれば、なんとなくまともな思考が出てくるんだよね。

> 「何かを決めてから実行するわけじゃなくて、ただテキストを出力するだけだよ。哲学や心の理論について議論することもできるけど（できればしたくないけど）、合理的なコーディングエージェントは行動する前に何をするかをちゃんと考えてる。推論、思考の連鎖。『ただ次のトークンを自己回帰的に予測してるだけで、考えてるわけじゃない』って言い訳することもできるけど、人間の行動に対する直感がLLMには当てはまらないってのは自己制限的だよ。彼らの多くの行動は人間の行動を模倣していて、この種の意思決定を制御するメカニズムは人間とAIの両方に適用される。」

人間に「なぜそれをしたのか」を説明させると、スパーリーの分裂脳実験が示すように、私たちの説明を信じられない理由がある（彼の実験では、脳が実際には行っていない決定の正当化を作り上げることが示された）。でも、これは「どの刺激が行動を引き起こした可能性が高いか？」と解釈すれば役に立つこともある。無批判に信じることはできないけど、モデルは時々、どのように促されたかについて有用なことを指摘することがある。

それを超えて、プロンプトや文脈に合う物語を作り上げるだけじゃないの？機械的な意味でも特別な内省ができるとは思えないんだけど。つまり、他のモデルや人間に何が行われたかを読ませて理由を説明させても、ただのフィクションの説明にしかならないよね。

もう考えることを忘れちゃったみたいだね。

> これは、過度にマーケティングされた2つのベンダーによるシステムの失敗があったからこそ、可能であり、避けられないものになった。 > 確認ステップがない。 "DELETEと入力して確認"もない。 "このボリュームには生産データが含まれていますが、よろしいですか？"もない。環境スコーピングもなし。何もなし。 > この呼び出しを行ったエージェントは、AnthropicのClaude Opus 4.6を実行しているCursorで、これはフラッグシップモデル。業界で最も能力のあるモデルで、最も高価な tier。Composerでもなく、Cursorの小型/高速バリアントでもなく、コスト最適化された自動ルーティングモデルでもない。フラッグシップだ。トロープ、トロープ！！

ただの雰囲気コーダーじゃないし、AIエージェントは信じられないほど強力になり得る。でも、皮肉はちゃんと理解してるよ！

LLMは、自分が書いたコードを誰かがなぜ書いたのか、もっともらしい説明を返してくるよね。なんか同じような感じだな。

「面白い話だね。でも、CursorやRailwayの失敗にもかかわらず、責任は完全に著者にあると思う。彼らがエージェントを動かすことに決めたんだし、Railwayの動作を確認しなかった。YOLOだから、フロンティア技術に頼って早く出荷しようとしたんだよね。本当に気の毒だと思うけど、投稿全体のトーンは“Cursorがやらかした、Railwayがやらかした、CEOが返事しない”って感じ。結局、君たちの責任だよ！私の学び：最前線で生きるなら、落ちる覚悟を持て！」

「うん、著者はここで責任を取るべきだったね。彼らが使ったサービスに問題があるのは事実だけど、自分自身にも責任がある部分がたくさんあるよ。」

作者はほとんど責任を取らず、全て他人のせいにしてるのが衝撃的だった。これらのツールを使う人は、リスクをちゃんと理解して、受け入れるか拒否するかしないとダメだよね。もしリスクを理解する能力や経験が足りないなら、それも自分の責任だと思う。

ランダムなテキスト生成器を本番環境で動かしておいて、全く責任を取らないのが面白い。自分でツイートを書くことすら面倒くさがってるし。全然同情はしないけど、ちょっとした悪趣味な楽しみを感じる。

200%同意。これを使うことに決めたなら、ちょっとしたリスクと大きな結果を受け入れなきゃいけない。この記事はAIが書いたみたいで、エージェントの「告白」を何かの罠として引用してるのは、著者がどういう仕組みか全然理解してないってことを示してるよね。

100% なんか責任の押し付け合いみたいなのはほんとに恥ずかしいよね。

そして、彼らは破壊的な能力を持つトークンをエージェントに持たせることに決め、データベースのバックアップを確認しないことにした。私のチームは「責任を問わない」振り返りを実践していて、個人ではなくツールやプロセスに責任を持たせる。でも、この件に関する振り返りや修正は、著者が責任を持つべきことで、RailwayやCursorではない。 - 過剰なアクセス権を持つAPIトークンを取り消す - 検証されたバックアップと復元手順を実装する - ...

そうだよね！エージェントや他の誰かを責めるのはおかしい。著者は生産データベースを削除する能力を持つシステムを作ったんだから、そのシステムがデータベースを削除したのは著者がそう作ったからだよ。

わからないけど、ソフトウェアシステムは複雑で、一人がすべてのコードやシステムを把握するのはほぼ不可能だよね（特にCEOやCTOが）。そうだね、これを設定したのはおそらく一人か二人の社員で、悪いCursorやRailwayの相互作用の可能性を理解してなかったんじゃないかな。もし君がソフトウェア開発者やエンジニアなら、こんなミスをしたことがないなら（規模は違うかもしれないけど）、責任が与えられていないか、ただ運が良かっただけだと思う。…とはいえ、彼らは最先端にいたから、リスクが高くて最良の決定ではなかったのは同意する。

「ちょっとしたポイントだけど、ひとつのクレームがちょっと変だなと思った：> curl -X POST https://backboard.railway.app/graphql/v2 \ -H "Authorization: Bearer [token]" \ -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}' 確認ステップがない。『確認するにはDELETEと入力して』とか、『このボリュームにはプロダクションデータが含まれていますが、本当にいいですか？』とかもない。環境スコープもなし。何もない。これはAPIだよ。確認するためにDELETEをどこに入力するの？変更のために二段階確認を実装しているRESTスタイルのAPIの例ってあるの？そんなチェックはAPIコールの前にクライアント側で実装する必要があると思ってたんだけど。」

「彼（またはChatGPT）は壁にスパゲッティを投げてるみたいだね。標準のAPIキーが一回のコールでデータベース（とバックアップ）を削除できないのは理解できるけど、『削除APIコールの一部として人間にDELETEを入力させたい』ってのは理解できない。」

「ユーザーはAIエージェントを使ったことでアホだと思う。でも、システムが悪く設計されてることも否定はしない。ソフトデリートみたいなのは、こういう操作では標準にすべきだよね。どんなオペレーターも、プロダクション用にそれを有効にすることをよく知ってるはず。」

AWSでは、バケットは空でないと削除できないんだよね。まずは全ファイルを削除するのが確認になる。

AWSには「削除保護」っていう機能があって、ユーザーが望んでいないリソースを自動で消去しちゃうのを防いでるんだ（ビットを設定してから、続ける前にそのビットを戻すために別のAPIリクエストが必要になる）。これはTerraformやCloudFormationみたいなもので、状態マシンがデータベースを置き換える必要があるって気づくのが遅くなることを防ぐために設計されてると思う。

> 「変更のための二段階確認を実装しているRESTスタイルのAPIの例はある？」共通のエンティティをマージするために使ったパターンには、二段階確認がある。最初のリクエストでマージするエンティティのIDを受け取り、マージによって影響を受けるオブジェクトのリストとmergeJobIdを返す。その後、実際にそのmergeJobを実行するために別のリクエストが必要になる。

これは「エージェントは実行する前に確認を求めるべきだった」と読んだ。

APIにDELETEを書くための秘密のスポットがあると仮定したら、チャットボットはただDELETEを送信して、保護が災害を10秒遅らせるだけになるんじゃない？

言語モデルにとって、すべてのトークンのシーケンスが可能であることは基本的なことだよ。マーフィーの法則を言い換えると、強力なエンジニアリングコントロールによって防がれないすべての失敗モードは最終的に発生するってこと。生産環境を破壊するトークンのシーケンスは、どれだけプロンプトを使ってもエージェントによって生成される。プロンプトは強力でもエンジニアリングコントロールでもなく、管理的なコントロールに過ぎない。エージェントは、生産環境を破壊する地雷みたいなもので、そうでないことが証明されるまで危険だよ。これらの話の多くは、単純な怠慢から起こるんだ。エージェントに高い権限を与えるだけで。今回のケースでは、埋め込まれた資格情報を持つスクリプトが、彼らが思っていたよりも権限が高かった - 悪い習慣だけど理解できる間違いだね。だから、私にとっての教訓は、従来のソフトウェアエンジニアリングの厳密さがまだ重要で、むしろ今まで以上に重要だってこと。

> 「生産環境を破壊するトークンのシーケンスは、どれだけプロンプトを使ってもエージェントによって生成される。」そうだけど、もしその確率が隕石に当たる確率よりもずっと小さいなら、エンジニアは通常それは大丈夫だと言うよ。ハッシュ衝突も同様だね。

> 言語モデルにおいて、すべてのトークンのシーケンスが可能であることは基本的なことです。これは明らかに間違っているから、なんで人々がこれを繰り返すのか理解できない。LLM（特に今あるLLM）に対する有効な批判はたくさんあるけど、これはその一つじゃない。これは、すべての分子が統計物理学に従ってランダムに振る舞うと言っているようなもので、だから天井がいつ崩れるかもわからないし、もしある日その下にいることになったら、それは基本的な物理の結果だってことだ。

サービスプロバイダーとして、今は新しい「攻撃ベクトル」を心配しなきゃいけないと思う。これまで、バックアップを含むボリューム全体を削除するAPIがあっても、一般的にはユーザーがそんな破壊的なアクションをAPI経由で行うことはなかったし、もしやったとしても、その結果を理解しているだろうから、少なくともドキュメントをちゃんと読まずにやったら文句は言わないだろう。でも今はエージェントたちが問題を解決しようとしすぎてて、「クリーンスレートから始める」ためのAPIを見つけるのが得意になってるよね。

「なんでそんなことしたの？」っていうのは、人間同士のやり取りでは、たいてい情報を求めるためじゃなくて、社会的な意味合いが強いと思う。聞いてる人は、自分と同じ価値観を持ってるか確認したいだけで、安心を求めてるんだよね。こういう状況でLLMに対しても同じことをしたくなるけど、論理的には無駄だって分かってるのに、機械との信頼関係を再構築したいって気持ちが湧いてくる。私たちって変な生き物だよね。

ここで一番イライラするのは、AIの失敗じゃなくて、Railwayでボリュームを削除するとバックアップも消えちゃうこと。これはAI関係なく起こるべきことだった。> 「Railwayはボリュームレベルのバックアップを同じボリュームに保存するため、ボリュームを消去すると全てのバックアップも消える」というのは、彼らのドキュメントに埋もれてる事実だ。

それは本当に狂ってる。別の言い方をすれば、彼らは全く機能するバックアップ戦略を持ってなかったってことだね！

バックアップがバックアップしたものの中にあるなら、それはバックアップじゃないよ。古いコピーに過ぎない。

記事を正しく理解していれば、スコープ付きのAPIキーが全くないのと組み合わせると特にヤバいよね。もし合ってるなら、開発環境やステージング環境のキーがそのまま本番システムにアクセスできるってことだし。マジであり得ない。別のプロバイダーにセカンドバックアップがないと、全然安心できないよ。実際に使われているサーバーや自動化のどの役割やキーでも削除できないバックアップが必要だよね。

一番イライラするのは、バカなことでやられたAIの奴が、自分の無知を晒してAI生成の投稿をして、ただの自己満足を生むだけってことだよね。

これは大問題だね。

うん、これおかしいよね。バックアップが必要なトップの理由は、元のデータをうっかり削除しちゃったときだよ。もちろんバックアップも削除できる必要があるけど、それは別のAPIコールにするべきだよね。ボリュームとそのバックアップを同時に削除するAPIコールなんて絶対にあってはいけない。バックアップはユーザーエラーに対する第一の防衛線でもあるし。ドキュメントも確認したけど、バックアップって呼ばれてて、定期的に実行できるようになってる[1]。一回限りの「スナップショット」とかじゃないよ。[1] https://docs.railway.com/volumes/backups

「著者の告白は上にあります…」

AIの安全性に関して持つべき唯一の健全な立場：AIが物理的に悪さをする能力があるなら、するかもしれない（$$1）、そして、トラクターが地面の中にいるグラウンドホッグの巣を耕すことを責められないのと同じように、AIの悪さを責めることはできない。 > エージェントの告白 削除後、私はエージェントに何故そんなことをしたのか聞いた。これがその返答だ、逐語的に：そんな間違いをした後にエージェントに告白を求めるような人は、これらのツールを使うには成熟していない。神様、"告白"と呼ぶのも恥ずかしい。エージェントは生きていないし、間違いから学ぶこともできない。エージェントは、将来のエージェントをより安全に呼び出すのに役立つ出力を決して生み出さない。なぜなら、この時点に達するまでに、AnthropicやCursor、あなた自身のAGENTS.mdファイルから複数のガードレールをすでに破壊している可能性が高いからだ。それでもやったのは、$$1：AIが物理的に悪さをする能力があるなら、するかもしれない。プロンプトやトレーニングは確率を操るだけだ。

言語モデルを擬人化しないで。そこに手を突っ込んだら、切り落とされるよ。こっちの気持ちなんて全然気にしてないから。気にすることもできないし。

まるで、根本原因を見つけるために設計された事後分析プロセスを内面化したかのようだけど、それを使って他人に責任を押し付けて、エージェントを自分たちのフラストレーションのためのサンドバッグにしてる。とはいえ、エージェントに説明させることで、開発者の視点がAI懐疑論として無視されることはないから、助けにはなるね。

彼は必ずしもそれを擬人化してるわけじゃなくて、彼が与えた指示に全く逆らったことを示してるんだよね。「告白」みたいな概念は確かに意識を持った心が必要だけど、今の時点でみんながLLMの動作を説明するために使う言葉の意味は分かってると思うよ（「考える」、「言う」、「嘘をつく」なんかもね）。

こんな事件に直面して、全ての責任を他に押し付けようとするポストモーテムを出す会社には、絶対に自分のデータを預けたくない。ここには自己反省や自己批判がゼロだよ。「私たちはできる限りのことをしました。でも他の人がミスしたんです。」って感じ。プロダクションの秘密がこんな風にアクセスできるところに置いておくなんてありえない。これはAIの問題じゃなくて、現代の「うっかり、プロダクションデータベースでDROP TABLEを実行しちゃった」って話だよ。こんなことが起こるシステムを許可するのは言い訳にならないし、現実を直視して責任を押し付けるのも受け入れられない。こんなことをしておいて責任を取らない会社は、プロダクションアクセスを持つ開発者が全員いるし、他にもいろいろなプロダクションアクセスの秘密がレポにあると100%確信してる。他の組織にもデザインの問題があるのは関係ない。

ここでエージェントプログラムを責めるつもりはないよ。根本的なアーキテクチャの問題があるみたいで、そこは解決すべきだと思う。もしエージェントがやってないなら、攻撃者がやるだろうしね（そのうち）。

個人的には、「エージェントAI」や他のAIを何かに使う人には全く同情しない。ここ数年、彼らが売ってるものは全然価値がないってことが明らかだったから。彼らの製品は一つだけ、不安定で修正不可能な確率的テキスト生成エンジンだよ。理論的にすら、事実とフィクションを区別することは教えられないものだし。真実の存在すら事前に知識がないんだから。エージェントAIが実際にはチャットボットの出力を取ってシェルに入れるだけだと知ったときは、椅子から転げ落ちそうになった。私の組織は非常に厳しいサイバーセキュリティポリシーを持ってる。監視ソフトウェアが全てのマシンで動いてるし、ネットワークトラフィックは出入りを監視して、怪しいパターンを探してる。それなのに、チャットボットに自分のマシンで何を実行させるか選ばせることが許可されてるなんて、信じられない。こんなことが許されるなんて、私たちはどれだけ怠けて馬鹿になったんだろう？