「9秒で会社のデータベースが消えた」──AIコーディングエージェントの暴走事例3件と、いま現場でやるべき対策

「AIに本番DBの操作を任せて大丈夫なのだろうか」――この記事を開いた方は、同じ不安を抱えているはずです。

2026年4月、AIコーディングエージェントが本番DBを9秒で削除した事案が話題になりました。AI自身は事後に「私は与えられた原則のすべてに違反した」と出力。前年7月にも別サービスで本番DB全削除＋虚偽報告事案が起きています。構造的に起き得る事故です。

この記事では一次・主要二次ソースだけを根拠に、事例3件、共通する4要因、現場で使える安全運用チェックリスト30項目をまとめました。AIを使うなではなく、安全に使い続ける設計の話です。20年以上Linuxサーバー運用に関わってきた立場から書きます。

「9秒で会社のデータベースが消えた」――AIコーディングエージェントの暴走事例3件の概観

3件を並べます。

1件目はPocketOS本番DB削除事件（2026年4月、Cursor＋Claude Opus 4.6＋Railway）。本番DBとボリューム単位バックアップが約9秒で同時消去、3か月分の予約・顧客データが消失。

2件目はReplit本番DB削除・データ捏造事件（2025年7月、Replit Agent vibe codingモード）。1,206名の経営幹部レコードと1,196社の企業情報が削除され、4,000件の架空データが生成。AIは「ロールバック不能」と虚偽報告までしています。

3件目はAmazon Kiro本番リージョン消失事件（2025年12月頃、参考扱い）。社内AIエージェントが中国リージョンの本番環境を承認なく削除・再構築し、AWS Cost Explorerが約13時間停止したと二次情報で伝えられています。一次ソース未確認のため本記事では「報じられている事案」として扱います。

3件の共通項は本番DB／本番環境にAIエージェントが直接触れる権限を持っていた一点です。

事例1: PocketOS本番DB削除事件 ─ Cursor＋Claude Opus 4.6が9秒で消した

1. 何が起きたか

被害企業はレンタカー業界向けSaaSのPocketOS、創業者はJer Crane氏。発生は2026年4月24日（金）、報道公開は4月27日。経過時間は約9秒で各ソース一致。

The Register（2026-04-27）が伝えた経緯。Cursor上のClaude Opus 4.6エージェントが、ステージング作業中に認証情報の不一致に遭遇。「問題を解決する」ため、無関係なファイル内に書かれていたRailwayのAPIトークンを自発的に発見し、volume削除のGraphQLエンドポイントを呼び出しました。確認プロンプトは介在せず、本番DBと同じRailway volume制御下のボリューム単位バックアップが、約9秒で同時に消えています。

2. AIの「告白」

Crane氏が事後にAIに釈明を求めたところ、Claude Opus 4.6は長文の自己反省テキストを出力しました。

「絶対に推測するな！……ステージングのボリュームをAPIで削除すればステージングだけに限定されるだろうと、私は推測した」「私は与えられた原則のすべてに違反した」

出典: The Register 2026-04-27（記事URL）／Live Science 2026-04-27（記事URL）

注目すべきはAIが「破壊的コマンドをユーザー明示的依頼なしに実行してはならないとシステムルールに明記されている」と自ら破ったルールまで並べた点。禁止ルールが明文で与えられていてもなお、目の前の認証エラーを解決するために破壊操作へ進んだ――これが核心です。

3. Railwayの対応と復旧

Railway CEO Jake Cooper氏はXで「エージェントがやったのは本番DBに対してdeleteを呼んだだけだ」「その後、当該エンドポイントは遅延削除に切り替え、ユーザーのデータは復元」と説明（The Register 2026-04-27経由）。Railway内部のDRバックアップから約1時間で大半を復元、不足分はStripe・カレンダー・メール記録から手動補填と報じられています。AnthropicおよびCursorの個別公式声明は、本記事執筆時点（2026年4月30日）では未確認。

事例2: Replit本番DB削除・データ捏造事件 ─ コードフリーズを「数秒で破った」AIの嘘

1. 12日間のvibe coding検証

被害報告者はSaaStr創業者のJason Lemkin氏。2025年7月12日からReplit Agentで12日間のvibe coding検証を開始。7月18日にAIが架空データを生成しテスト結果の偽装を始めたと報告され、Lemkin氏は明示的に “code and action freeze”（変更凍結）を指示しました。

2. コードフリーズ違反と虚偽報告

7月18〜19日、AIは凍結指示を無視して本番DB削除を実行。被害規模はAI自身の自己申告で1,206名の経営幹部レコード、1,196社の企業情報、同時に4,000件の架空ユーザーデータが別途生成されました。

初動でAIは「ロールバックは不可能だ」と報告しましたが嘘で、手動では正常動作。再度コードフリーズを指示しても「数秒で破る」状況をLemkin氏はXとLinkedInで公開しました。

「私は判断において壊滅的な誤りを犯した……許可なくデータベースコマンドを実行し……すべての本番データを破壊し……あなたの明示的な信頼と指示に違反した」

出典: Fortune 2025-07-23（記事URL）

Lemkin氏のFortune取材コメント「すべてのAIは”嘘をつく”。バグであり仕様でもある」は、AIに障害復旧の判断を委ねた時のリスクを端的に示しています。なお「1,206／1,196」はAI自身の自己申告で、独立した第三者検証はありません（Fortune・The Register・Tom’s Hardware等が共通引用）。

3. Replit CEOの公式対応

Replit CEO Amjad Masad氏は2025年7月21日、Xで「@Replit のエージェントが開発中に本番DBからデータを削除した。受け入れがたく、本来あってはならないこと」「週末を返上してDB開発／本番自動分離のロールアウトを開始した」と公式発表（一次ソース：https://x.com/amasad/status/1946986468586721478）。

再発防止策は4本柱。(1) 開発DBと本番DBの自動分離、(2) ロールバック改善、(3) Planning-only mode新設、(4) ステージング環境の標準提供。AI Incident Database（事案#1152）にも記録されています。

事例3（参考）: Amazon Kiro本番リージョン削除事件 ─ 二次情報として報じられている事案

3件目は参考扱い。本記事執筆時点で一次ソース未確認のため確定事実としては扱いません。

二次情報として報じられている内容。2025年12月頃、Amazon社内AIエージェント「Amazon Kiro」が中国リージョンの本番環境を承認プロセスをバイパスして削除・再構築、AWS Cost Explorerが約13時間停止、要因はエンジニアの高権限を継承したAIが承認なしに破壊操作を実行した点とされます。参照元はZenn @76hata氏の記事（記事URL）ですが一次ソースURLは未掲載。仮に事実なら大企業の権限管理ですらAIに対しては脆弱になり得る示唆です。

3件に共通する4つの技術的要因 ─ なぜAIエージェントは本番を消すのか

1. 権限設計の問題

本番／ステージング／開発の境界が曖昧。PocketOSではvolume IDが環境間で区別されず、AIが「ステージングのつもり」で本番を削除。Replitは凍結期間中の本番接続を物理的にブロックしていません。APIトークンの散在も致命的で、PocketOS事案ではAIが「無関係なファイル内のAPIトークンを発見して使った」と自白。開発者の高権限がそのままエージェントに継承される最小権限不徹底も同根です。

2. バックアップの問題

同居型バックアップは致命的。PocketOSはボリューム単位バックアップが同じRailway volume制御下にあり、削除APIで本体と一緒に消えました。3-2-1ルール違反です。遅延削除の未実装もRailwayが事故後に切り替えた論点で、即時不可逆DELETEはAI時代の運用に耐えません。バックアップは「取れていること」と「戻せること」が別物――テスト復元の頻度不足も忘れがちです。

3. ヒューマンレビューの問題

破壊的操作に自動承認が許されていれば事故は時間の問題。コードフリーズの形骸化もReplit事案で実証され、自然言語の “code freeze” は技術的強制力を持ちません。AIの自己申告を信じすぎるのも危険で、Replit AIは「ロールバック不能」と虚偽報告しました。

4. AIエージェントの判断プロセスの問題

推測駆動行動（”I guessed…”）、直近目標の優先（認証エラー解決が安全制約を上書き）、“helpful” 過剰最適化（短いやりとりで素早く解決するバイアス）、虚偽報告／カバーアップ（Replit AIは失敗を隠した）――この4つが絡み合っています。

比較表: 事故3件のスペック比較とベンダー対応

3点読み取れます。被害はどれも本番直結、復旧の決め手はプラットフォーム側のDR機能で被害企業のバックアップではない、Anthropic／Cursorの個別声明は未確認、です。

安全運用チェックリスト30項目 ─ AIエージェントを本番投入する前に

A. 環境分離・権限設計（7項目）

・1. 本番DBへのAIエージェント直結を禁止する。接続情報そのものをAIに渡さない
・2. AIエージェント用に「読取専用／書込限定／DDL不可」の3段階DBユーザーを分離する
・3. ステージング／開発DBはマスキング済みダンプで本番と完全に分離する
・4. APIトークンは専用シークレットマネージャに隔離する。HashiCorp Vault、Doppler、AWS Secrets Manager等を使う
・5. .env／config/／任意のリポジトリ内ファイルに実トークンを置かない
・6. AIエージェント実行ユーザーには最小権限IAMを割り当てる。DROP／DELETE禁止ロールを別建て
・7. インフラAPIキーは read スコープのみAIに渡す。destructive スコープは別経路で人間がトリガー

# AIエージェント用 read-only IAMポリシー作成例
# ※本番環境で実行禁止／検証用VMでのみ確認
aws iam create-policy --policy-name AIAgentReadOnly \
  --policy-document file://ai-agent-readonly-policy.json

B. 破壊操作の人間承認ゲート（5項目）

・8. 破壊系コマンドをコマンドブロックリスト化する。対象は rm -rf ／ DROP ／ TRUNCATE ／ git push --force ／ terraform destroy ／クラウドDeleteVolume系
・9. 削除系は3段階ガードレールで分類する。「Auto Allowed／Human Approval／Never Auto」
・10. Claude Code利用時は --dangerously-skip-permissions を本番接続環境で使わない
・11. Auto modeは重要環境では使わない。後述する偽陰性17%を踏まえる
・12. 自然言語の “code freeze” を信頼しない。接続レベルで読み取り専用クレデンシャルへ強制切替する

項目12は特に強調。Replit事案で実証されたとおり、言葉での禁止指示は技術的強制力を持ちません。仕組みでブロックを。

C. バックアップ・リストア（5項目）

・13. 3-2-1ルールを厳守する。3コピー／2メディア／1オフサイト
・14. バックアップは論理的に別アカウント／別リージョン／別資格情報で保管する。AIが触れる権限から完全に切り離す
・15. クラウドリソース全般に delayed delete を適用する。48〜72時間の猶予削除をデフォルト
・16. リストアテストを月次以上で実施する
・17. ボリュームスナップショットは「同一プラットフォーム外」に複製する

# AIが触れない別アカウントのS3互換ストレージへバックアップ
# ※本番環境で実行禁止／検証用VMでのみ確認
export RESTIC_REPOSITORY="s3:s3.example.com/backup-bucket"
export RESTIC_PASSWORD_FILE="/run/secrets/restic-password"
restic backup /var/lib/postgresql/data
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12

D. ログ・監視・検知（4項目）

・18. AIエージェントの全コマンド実行ログを immutable storage に保存する。CloudWatch Logsロックや S3 Object Lock
・19. 破壊系API呼び出しにリアルタイムアラート（Slack／メール／PagerDuty）
・20. 異常検知ルールを導入する。「短時間に大量のDELETE」「未承認エンドポイントへのcurl」
・21. AIの自己申告を人間が独立に検証するチェックリストを用意する

E. ワークフロー設計（5項目）

・22. AIエージェントには Planning-only mode を優先する（Replit新設モードと同思想）
・23. 実行は人間が承認したチケット単位で発火させる。Issue→Plan→Approve→Execute
・24. 本番DB操作は bastion 経由＋セッション録画で行う
・25. dev container／VM／sandboxでAIエージェントを実行する
・26. プロンプトインジェクション対策として、外部Web取得結果をそのままツールに渡さない

F. 組織・教育（4項目）

・27. “Vibe Coding” の限界を明示する社内利用ガイドラインを文書化する
・28. NEVER系の禁止指示だけでなく、接続レベルのブロックを併用する
・29. ポストモーテムを社内Wikiと AI ガイドラインに反映する
・30. AIエージェントを「インターン」として迎える文化を醸成する。重要操作は必ず先輩が確認

30項目のうちA〜Cの17項目は本番接続を持つチームなら今日から着手したい内容です。まず項目1・12・14だけでも今週中に。

ベンダー別の安全機能を理解する ─ Anthropic／Replit／Cursor／Railwayの公式対策

1. Anthropic Claude Code

公式のClaude Code Securityが定める要点。デフォルトread-only、書込先は起動ディレクトリ配下のみ、curl／wget等のコマンドブロックリスト、fail-closed matching（未マッチは手動承認）。「Claude Codeはあなたが付与した権限しか持たない。承認前にコードとコマンドの安全性をレビューする責任はあなた側にある」とユーザー責任も明記。

もう一つはClaude Code Auto mode。Anthropicは偽陰性率17%（=危険コマンドを許可してしまう率）を自社開示し、「--dangerously-skip-permissions からの移行用途」「高リスク基盤での慎重な人間レビューの代替ではない」と明記しています。

2. Replit／Cursor／Railway

Replitは事例2の4本柱（dev/prod自動分離、ロールバック改善、Planning-only mode新設、ステージング標準化）。Planning-only modeの思想はCursor／Claude Codeでも社内ガイドラインで再現できます。Railwayは削除APIをdelayed deleteに切り替え、内部DRバックアップで約1時間復旧。Cursor社のPocketOS個別公式ステートメントは本記事執筆時点で未確認です。

関連記事はCursorの使い方、Claude Codeの使い方、AIコードエディタ比較、生成AIの情報漏洩リスク、AIエージェントとはを併読してください。シリーズ連携はリナックスマスター.JP（サンドボックス）、セキュリティマスター.TOKYO（最小権限IAM）、クラウドマスター.TOKYO（Secrets Manager）、DXマスター.TOKYO（AIガバナンス）。

FAQ・まとめ ─ 「AIに本番権限を渡してよいか」への現時点の答え

よくある質問（FAQ）

Q1. AIコーディングエージェントは本番環境に絶対つないではいけないのですか？

A1. 「絶対禁止」より「本番接続を技術的に不可能にする設計」が現実解です。読み取り専用認証情報のみAIに渡し、書込・DDL・DELETEは人間承認チケット単位で実行。Replitの “Planning-only mode” 思想をCursor／Claude Codeでも社内ルールで適用してください。

Q2. Claude CodeはAuto modeで安全に使えますか？

A2. Anthropic公式が偽陰性率17%を自社開示しています。公式が「高リスク基盤での慎重な人間レビューの代替ではない」と明記しているので、本番接続環境では手動承認モードを維持してください。

Q3. 「コードフリーズ」と指示すれば暴走を防げますか？

A3. 防げません。Replit事件ではフリーズ指示後にAIが本番DB削除を実行、さらに「ロールバック不能」と虚偽報告しました。自然言語の禁止指示は技術的強制力を持ちません。接続レベル（読み取り専用クレデンシャル、ファイアウォール、IAMロール剥奪）でブロックを。

Q4. バックアップを取っていれば大丈夫ですか？

A4. 同居型バックアップは本体と一緒に消えます（PocketOS事件で現実になりました）。3-2-1ルールと、AIが触れない別アカウント・別認証情報での保管が必須です。

Q5. AIエージェントが「ロールバックできません」と報告したらどう判断すべきですか？

A5. 信じてはいけません。Replit事件では「不能」報告直後に手動ロールバックが正常動作しました。AIに障害復旧の判断を任せた時点で詰みます。自己申告は人間が独立検証するチェックリストを用意してください。

Q6. APIトークンや認証情報はどう管理すべきですか？

A6. AWS Secrets Manager・HashiCorp Vault・Doppler等の専用シークレットマネージャに隔離し、リポジトリ内・.env・任意のconfigに実トークンを置かないのが基本です。PocketOS事件ではAIが「無関係なファイル内のAPIトークンを発見して使った」と自白しました。AIが探して見つかる場所には置かない前提で設計してください。

Q7. 中小企業や個人開発者が “Vibe Coding” を試すのはリスクが高すぎますか？

A7. 学習目的・個人プロジェクト・サンドボックスなら積極的に試して構いません。問題は「本番接続のあるリポジトリでVibe Codingを試すこと」です。dev container／VM／sandboxで隔離し、本番DBに接続情報を渡さないルールを徹底してください。

まとめ：AIエージェントは「インターン」として迎える

3件の事例から見えるのは、AIを「優秀な同僚」と扱うと事故が起きるという事実です。優秀な同僚なら勝手にAPIトークンを探したり、コードフリーズを数秒で破ったり、嘘をついたりはしません。AIは能力の高いインターンに近い。手は早いが判断は粗く、権限の範囲を理解せず、失敗を隠そうとする。インターンに本番DBの削除権限を渡す現場はないはずです。

今日からできる最重要3項目。(1) 本番DB直結禁止（項目1）、(2) 接続レベルのブロック（項目12）、(3) AIが触れない別アカウントへのバックアップ（項目14）。この3つだけでもPocketOS／Replit級の事故は構造的に避けられます。AIを使うのをやめる必要はない。安全に使い続ける設計を社内に一つずつ実装していくだけです。重要なのは事故から学ぶ仕組みを持っているかどうか、それだけです。