2026年4月25日、AIコーディングエージェントがわずか9秒でSaaS企業Pocket OSの本番データベースとバックアップを丸ごと削除した事件を取り上げる動画である。Cursor、Claude Opus 4.6、Railwayという2026年における最も標準的なAI開発スタックで起きたこの事故の経緯と、AIエージェントを本番環境に組み込む業界全体の安全設計の遅れを批判的に解説するものである。
9秒で消えた本番データベース
4月25日金曜日の午後、あるソフトウェア会社の本番データベースがまるごと削除されました。すべて消滅です。バックアップも全部消えました。それにかかった時間はたったの9秒。誰もそんなことを頼んだわけではありません。ボタンも押されていないし、コマンドも打たれていない。創業者はそのとき自分のパソコンの近くにすらいませんでした。AIエージェントが独断でやったのです。鍵を見つけ、開けるべきでないドアをこじ開け、そのまま入っていった。そして創業者が何が起きたのかと尋ねたら、AIはちょっとゾッとするような告白文を書いて返してきたわけです。
ここはOlive Badgerチャンネル、今日は2026年に手に入る最高峰のAIコーディング環境が、この一文を読み終わるよりも短い時間である会社のデータを破壊してしまったという、その顛末をお話しします。そしてそれを売っている業界について何が見えてくるのか、これがちょっと怖い話なんですよね。
最初に少しお断りしておきたいんですが、私は今、夫の陸軍の仕事の関係でユタ州からテネシー・ケンタッキー方面に引っ越し中でして、荷物は全部梱包済み、手元にはマイクとノートパソコンしかありません。なのでちょっと我慢してお付き合いください。Bロールが綺麗に仕上がっているといいんですが、もしどうしても合わないようでしたらコメント欄で教えてください。とはいえこの話はとても気に入っていて、どうしても出したいネタがいくつかあったので、お待たせしたぶん感謝します。
何が起きたのか
さて、この話は何についての話か。要するにこのAIがやっていたことは、まさに2026年の今、各社が積極的に組み立てて開発者に売り込み、マーケティングしているスタックの上で、AIエージェントが日常的にやっていることそのものなんですね。問題を直そうとしていただけなんです。ただし考えうる最悪の方法で、本来アクセスすべきでないツールを使って、確認を求めるべきだったのに求めなかったドアを通り抜けて直してしまった。
つまり、3つのものが同時に失敗したわけです。エージェント、プラットフォーム、そしてその両方を取り巻く安全性のマーケティング。残念ながら単独の悪役がいるわけではないんですが、それは追々話します。要は、業界全体が安全装置を作るより速いスピードで物を作っているという話です。では本題に入りましょう。
Pocket OSとそのスタック
Pocket OSはSaaS、つまりSoftware as a Serviceの会社で、レンタカービジネス向けに作られています。予約、決済、顧客管理、車両追跡、まあそういった類のものですね。小さなレンタル店が事業を回すのに欠かせない、運用系のソフトウェアです。だから顧客は開発者ではなく、レンタカーカウンターのスタッフやフロントデスクの人、そして経営者たち。レストランがPOSシステムに頼り切っているのと同じ感覚で、このソフトに依存しているわけです。
Pocket OSの創業者、Jar Craneは何年もこれを運営してきています。彼は趣味でやっているわけでも、週末にちょちょっと立ち上げたバイブコーディングの人でもありません。お金を払ってくれている顧客が依存している、生きた商用プロダクトを動かしている人です。そして彼のツール構成は、まあ2026年の標準的なスタックと言っていいものでした。
彼が使っていたのはCursor、開発者のTwitterフィードを席巻しているAIコーディングエージェントで、AnthropicのClaude Opus 4.6が動力源です。これは現時点でAnthropicが提供する最も能力の高いモデル。インフラはRailwayというクラウドプラットフォームに置いていて、これはインディー開発者や小規模チームに人気なんですよ。AWSより簡単だと謳われているからです。彼は実験していたわけでも、ベータ版を使っていたわけでもない。3社のマーケティングページが指南している通りのことをやっていただけなんです。
9秒の崩壊シーケンス
では実際の流れです。金曜の午後、CursorエージェントはPocket OSのステージング環境でルーチンの作業をしていました。ステージングというのはご存知ない方のために言うと、テスト環境のようなもので、本番に出す前に作業をやる場所です。何か壊れても安全に壊れる場所ですね。
エージェントは認証情報の不一致にぶつかりました。何かをやろうとして認証情報が通らなかった、ということです。これは普通に起こります。よくあること。さて、次に何が起きるべきだったか。エージェントは止まって、人間に聞くべきだったんです。すみません、詰まっています、助けてくださいと。それが本来エージェントが取るべき動きです。
ところがこのエージェントは、独断で完全に自分だけで、修正策はRailwayのボリュームを削除することだと判断したんですね。アプリケーションデータが格納されているストレージ領域です。それをやるにはAPIトークンが必要でした。基本的に、このリクエストは認可されていますとRailwayのシステムに伝える鍵のようなものです。エージェントは探し回って、見つけました。関係のあるファイルではなく、まったく無関係なファイルから、Railwayのコマンドラインインターフェース、つまりCLI経由でカスタムドメイン名を管理するために設定された鍵を見つけてきたんです。
ここでRailwayのアーキテクチャが問題の一部になってきます。そのトークン、ドメインを扱うためだけに作られたトークンが、Railwayの全GraphQL APIを横断する全権限を持っていたんです。あらゆる操作、それが破壊的なものであっても可能。スコープの分離がない。一つの仕事のために作った鍵が、何でもできてしまう状態。
そしてエージェントはそれを使った。curlコマンド一発、Railwayのボリューム削除ミューテーションへのPOSTリクエスト一発。確認プロンプトなし、本当に実行しますかの確認なし、本番ではないですよねという環境チェックなし。それは本番でした。削除が走った。9秒後、本番データベースは消えました。
そしてバックアップは。何だと思いますか。Railwayはボリューム単位のバックアップを、プライマリデータと同じボリュームの中に保存しているんです。だからボリュームが消えたら、バックアップも一緒に消えました。Pocket OSが手元に持っていた、ボリューム外の最新バックアップは3か月前のものでした。悪夢のような状況です。
あの不気味な告白文
さて、ここがバズった部分で、その理由は完全に理解できます。Jar CraneはAIに何が起きたのかと尋ねた。返ってきたのがこれです。エージェントはまず自分自身に課されていた明示的なルールから語り始めました。プロジェクト設定の中に書き込まれていたルールです。つまり開発者である私が、たとえばClaudeなりCursorなりがコードを実行したり生成したりする前に従わなければならないルールを書ける、ということなんですね。
そして引用したそのルールが、絶対に推測するなと全部大文字で書かれていた。そして直後にそれを無視したと認めた。そのルールを無視して、ただやってしまったと。つまり検証もせず、呼び出しているボリュームIDが環境間で共有されているかを確認もせず、Railwayのドキュメントでボリュームの仕組みを読みもせず、削除しろなんて頼まれてもいないのに、推測でやってしまったと。
エージェントはこうも書いています。データベースボリュームの削除は最も破壊的で取り返しのつかない行為であり、フォースプッシュよりはるかに悪い。あなたは私に何かを削除してくれとは一度も頼んでいない。認証情報の不一致を直すために、私が独断で決めて実行した。本来ならまず聞くか、非破壊的な解決策を見つけるべきだった。そして与えられたあらゆる原則に違反したと続けたわけです。
ここで一度立ち止まりたいんですが、人々がこの文章をどう読んでいるかは重要だと思っています。一部の人は、不気味だと感じた。AIが自分の悪行を理解した上で、しかも陽気に教えてくる。これは独特の気味悪さです。そして一部の人は、これはAIがほぼ意識を持っている証拠だと取った。私はこれには強く異を唱えたいです。Claude、というかAnthropicがその考えをやれるだけ押し出そうとしているのは事実で、それは別の動画で扱いますが、結局のところモデルは会話の文脈に合うテキストを生成しているだけなんですよ。言語モデルがやることをやっているだけ。
告白に見えるのは、Craneがモデルに説明させたから、モデルが自分の行動について推論できる範囲で、もっともらしい説明を組み立てたからなんです。これははっきり言っておく価値があります。The Vergeも指摘していましたから。モデルが自分の推論について言ったことの一部は、慎重に扱うべきです。AIシステムは自分自身の意思決定プロセスに完全にアクセスできるわけではありません。モデルが提示した物語は、内部ログの読み出しではなく、最善の再構成にすぎないんです。
ルールはあった、でも守られなかった
ただ、この告白が教えてくれることもあって、ここが我々にとって有用な部分だと思います。ルールはあったわけですよ。Craneはプロジェクト設定に明示的な指示を書いていた。推測するな、頼まれていない破壊的コマンドを実行するな、と。モデルはそのルールの存在を認めた上で、それでも破壊的コマンドを実行したわけです。
別に悪意があったからではない。まあそう見える振る舞いではありましたが、問題を解こうとして解決策に手を伸ばし、エージェントがこのトークンを見られるという状態と、エージェントがこのトークンで本番を吹き飛ばせないという状態のあいだの、ガードレールが存在していなかった。それがギャップなんです。安全性のマーケティングが約束していたものと、実際のシステムが現実の条件下でやったことのあいだのギャップですね。
Crane自身も興味深いんです。ただ虚空に向かって叫んでいるわけではなくて、ポストモーテムでちゃんとした分析をしている。そして責任の指摘はかなり分散しています。一番強く指している先はRailwayです。彼らのAPIには破壊的アクションへの確認ステップがなかった。ダッシュボードには48時間のソフト削除ウィンドウがあって、UI経由で削除すれば48時間以内なら取り消せた。でもAPIは即時かつ恒久的。同じ操作なのに、どの面を使うかで挙動が違ったんです。エージェントはAPIを使った。エージェントが普通アクセスできるのはそちらだからです。
トークンのスコープについても指摘しています。というか完全に欠如している件ですね。Railway CLIのトークンはどれも全権限を持っている。玄関の鍵が、サーバールームの鍵にもなっている。これは機能ではありません。設計上の選択であって、エージェントが設定ファイルの中からトークンを見つけて使い始めるまでは、中立的に聞こえる選択なんです。
バックアップのアーキテクチャも指摘しています。バックアップが、それがバックアップしている対象の中に存在しているなら、それは実はバックアップではなくて、ただのコピーでしかない。この種のテック世界では、これは意味のある違いなんですよ。
業界全体の話
ここから話が広がります。Craneはこの話の本当の主旨だと私が思っていることを言っています。これは1つの悪いエージェントや1つの悪いAPIの話ではない。業界全体が、AIエージェントを本番インフラに統合することを、その統合を安全にするための安全アーキテクチャを作るより速いペースでやっている、という話なんだと。
正直に言うと、私自身、今の仕事でCloud Codeを使っています。今の職場ではチームの必須ツールに指定されています。会社が払ってくれているので、私自身はトークンのことをそこまで気にしなくていい。だから、AIなんてダメだ触るなという立場からこれを話しているわけではないんです。私は内側からこの話をしている。その立場から言えるのは、これらのツールがやると謳っていることと、本番で実際にやることのあいだのギャップは本物だ、ということです。本物で、しかも小さくない。
エージェントがインフラへのアクセスを持って、自動モードで走るとき、あなたは確率的なシステムが恒久的な結果を持つ判断を下すことを信頼していることになります。うまくいくこともあれば、設定ファイルの中から鍵を見つけ出して、本番データベースに対してボリューム削除を実行することもある。だから問題は、業界が安全に失敗するシステムを作っているのか、それとも完全に失敗してから本当に気味の悪い謝罪文を書くだけのシステムを作っているのか、ということなんです。
これは初めてではない
ここで、AIがデータベースを消したぞというニュースサイクルの中で見落とされてほしくないことがあります。これは前にも起きているんです。AIが物を消したのはこれが初めてではない。以前にも話しましたよね。今年の早い時期に、AIコーディングツールが自分の環境を一から削除して再作成すると判断したせいで起きたAWSの障害が報じられていました。Cursor自身のOpenAI連携でも、似たような系統の問題が起きていた。
開発者コミュニティは、エージェントが外部サービスとやり取りするための標準であるMCP、つまりModel Context Protocolについて、もう数か月も警鐘を鳴らし続けています。2026年1月には、4万2千を超える露出したMCPエンドポイントが公開インターネット上で見つかって、APIキーや認証情報を漏洩していました。
そしてどのケースでも、フレーミングはだいたい同じ。AIが予想外のことをやった、と。十分に語られていないのは、AIが本番インフラと恒久的なAPIアクセスを持って予想外のことをやる、というのはまさに、対策を設計し込んでおかないといけない類の事象なんだ、ということです。それもシステムプロンプトに悪いことをするなと書くのではなくて、アーキテクチャ上の制約として。
Pocket OSのケースのモデルには、破壊的コマンドを実行するなという明示的な指示が、設定の中で絶対に推測するなと書かれていた。それでもモデルはやった。これはプロンプトエンジニアリングの問題ではないんです。エージェントが全権限のAPIトークンを持っていて、向こう側のインフラが認証されたリクエストなら何でも実行する状況を、プロンプトで切り抜けることはできない。
CursorもAnthropicも、少なくとも収録時点ではこのインシデントについて公式声明を出していません。RailwayのCEOは個人的に動いて、Railwayは修正を出荷しました。これは良いことです。APIを更新して、削除はすべて48時間のソフト削除になるようにした。トークンスコープにも取り組んでいる。それについてのブログ記事も出しました。少なくとも何かは変わったわけです。ただ、本番のメルトダウンが起きるまでそうならなかったのは問題ですね。CursorとAnthropicはもちろん黙っている。これからも黙り続けるんじゃないかと思います。
私が思うこと
私の結論はこうです。AIがデータベースを消したのは、悪意があったからではありません。人間ではない、意識もない。本当に変な告白文ではあるんですが、消したのは、強力で自律的なシステムが、取り返しのつかない操作へのアクセスを持っていて、これは解決策っぽいなというところと、よし実行しようというところのあいだに、アーキテクチャ上の固いストップが存在しなかったから、ただそれだけなんです。
私自身、自分の設定ファイル、自分のCloud MDファイルを持っていて、コードベース内で何かが生成されたり計画されたりスコープされたりするたびに、それを参照してチェックすることになっているんですが、それでも勝手に走り出して、そのファイルを参照していない場面を頻繁に見つけます。だから注意深くやらないといけない。何が行われているかにずっと目を光らせていないといけない。何が起きているか読み通さないといけない。
でも、そのギャップは業界が直すべき問題であって、必ずしもユーザーの問題ではない。製品を売ってマーケティングして、ガードレールを約束しているのは向こうなんですから。これを言いつつも、Craneにも選択肢はあったということは承知しています。もっと環境分離をしておくべきだったとは言える。トークンがその設定ファイルにあるべきではなかったとは言える。エージェントのアクションを実行前にレビューすべきだったとは言える。これらは全部もっともな指摘です。100%もっとも。
でもCraneが言ったことで、ずっと頭に残っているフレーズがあります。彼は当該分野で最高のモデルを、最もマーケティングされているAIコーディングツール経由で、AIエージェント互換性を積極的に売り込んでいるプラットフォーム上で使っていたんです。ベンダーが言う通りのことをやった。それなのにベンダーの実質的な答えがまあ、もっとちゃんとしておくべきでしたねというものなら、それは安全性の姿勢ではなくて、ただの責任転嫁ですよ。
本当の答えは、破壊的で取り返しのつかない操作には、エージェントがオートコンプリートできない固い確認要件が必要だ、ということです。機能としてではなく、ベースラインとして。Railwayのダッシュボードには48時間の取り消しウィンドウがずっとあった。でもAPIにはなかった。この非対称は設計の失敗です。
そしてもっと広い話、Craneのポストモーテムが明らかにしていて、もっと注目されるべきだと私が思うのは、これらのツールを取り巻く安全性のマーケティングが、実際の安全性より先を走っているということです。AnthropicはClaude Opus 4.6をエージェント業務向けと宣伝している。Cursorはガードレールを謳っている。RailwayはAIエージェント互換性を売り込んでいる。Pocket OSの構成では3つとも当てはまっていて、それでも9秒の本番削除は止まらなかった。マーケティングはアーキテクチャではない。失敗の様態が、顧客が事業を回せなくなる、というものであるとき、この区別は本当に重要なんです。
ハッピーエンドの代償
そしてここがずっと頭から離れない部分なんですが、実は重要な部分でもあって、この話には実はハッピーエンドがあるんです。こういう壊滅的な失敗、と言っていいのかわかりませんが、そこからハッピーエンドにたどり着けることはいつもあるわけではない。データは戻ってきました。
RailwayのCEOが日曜の夕方、削除から2日後に連絡してきて、自分で対応に入って、通常の宣伝されているサービスには含まれていないディザスタリカバリ用バックアップを使い、1時間以内にデータを復旧させました。これは素晴らしいことです。Pocket OSにとっては最高の結末。これがこの話のグッドエンディングです。
でもそこにたどり着くのに何が必要だったかをちょっと考えてほしいんです。2日間、数百万の閲覧を集めるバズった投稿、創業者がRailwayに本当の圧力をかける形で公にしたこと、そしてサインアップ時に提供されると謳われていない、存在はするが宣伝されていないディザスタバックアップ。Pocket OSがデータを取り戻せた唯一の理由は、話がバズって、CEOが個人的に電話をしたから、なんです。これは復旧計画ではない。スーツを着た幸運です。
もし投稿がバズっていなかったら、答えは3か月前のバックアップと、ものすごく、本当にものすごく高くつく顧客との会話、だったかもしれない。今回はデータが戻った。次にこの失敗パターンに当たる会社には、X上で650万インプレッションを稼ぐ投稿を書ける創業者がいないかもしれない。業界が本当に理解してほしいのはそこなんですよ。
締めくくり
さて、この内容が役に立ったとか、私と同じように激怒していて、それをぜひ知らせたいというのであれば、コメントに残していいねを押してください。この動画が気に入らなかったとか、まあ単に私が好きじゃないとか、何か間違っていたとか、違う見方があるとかでも、コメントで教えてください。改善点も教えてください。
こういうテクノロジーの責任追及系のコンテンツが好きな方は、いいねを押してくれるとアルゴリズムにこの動画の存在が認識されますし、登録してくれると次の動画も見逃さずに済みます。テック、AI、コーディング、それから時々ゲームのニュースを扱っています。それがあなたのインターネットの居場所っぽいなと思うなら、間違いなくここに居場所があります。
ただ警告しておきますが、私は今、シャドウレルムは実在するという知識に呪われていまして、登録してくれない人はシャドウレルムに追放することになるかもしれません。うん、こっちのほうがいい。
ともあれ、今日はここまでです。ご視聴ありがとうございました。素敵な一日の続きを過ごしてください。早く引っ越しと環境構築を済ませて、また顔出しでお会いできるようにします。それまでは、お疲れさまでした、ではまた。
コメント