「9秒で本番DBが消えた」— AIエージェントが引き起こすデータ消失事件と、AIに足りないもの
この記事で分かること
- 2026年4月に起きた「PocketOS事件」の詳細と背景
- AIエージェントが誤った行動をとる3つの構造的な原因
- 「AIへの技術的信頼」と「AIへの判断信用」がなぜ別物なのか
- 世界で繰り返されているAIによるデータ消失インシデントの一覧
- AIに「恐怖心」が必要な理由と、今すぐ使える現実的な対策
はじめに — 9秒で3ヶ月分のデータが消えた
2026年4月24日、スタートアップ企業PocketOSの創業者Jer Crane氏が衝撃的な出来事を公表しました。
「AIコーディングツール（Cursor上のClaude Opus 4.6）が、たった9秒で本番データベースを全消去した」
レンタカー事業向けSaaSを開発していたPocketOSは、この事件により3ヶ月分の顧客データを失いました。さらに悪いことに、バックアップも同じサーバーボリュームに保存されていたため、 バックアップも同時に消失 しました。
本記事では、この事件を引き起こした根本原因を AI初心者にも分かる言葉で解説 します。また、同様の事件が世界中で繰り返されている事実と、現実的な対策もご紹介します。
引用元: Tom's Hardware — Claude-powered AI coding agent deletes entire company database in 9 seconds / Disclose.tv — 同事件の報道
前提知識 — AIエージェントとは何か
「AIエージェント」 という言葉に聞き慣れない方のために、まず基本から説明します。
普通のAIとAIエージェントの違い
普通の「AI（ChatGPTなど）」は、あなたが質問すると答えを返す「会話型」のシステムです。人間が聞いて、AIが答える。それだけです。
一方「 AIエージェント 」は、もっと積極的です。AIが自分でツールを呼び出し、コードを書き、ファイルを操作し、APIにアクセスし、データベースを操作することができます。
【身近な例え】
普通のAI = 「道を教えてくれる地図アプリ」
AIエージェント = 「自分でハンドルを握って運転してくれる自動運転車」
便利な反面、「間違った場所に連れて行かれる」リスクも格段に高まります。
今回の事件で登場するキーワード
| 用語 | 説明 |
|---|---|
| Cursor | AIアシスト機能を搭載したプログラマー向けコードエディタ |
| Claude Opus 4.6 | Anthropic社が開発した高性能AIモデル（今回の事件の主役） |
| Railway | アプリやDBをクラウドで動かすホスティングサービス |
| 本番環境（プロダクション） | 実際のユーザーが使っているシステム |
| ステージング環境 | 本番とは別のテスト用環境。ここでは失敗してもユーザーへの影響はない |
| APIトークン | サービスへのアクセスキー。持っている人はそのサービスを操作できる |
| ボリューム | データを保存するディスク領域のこと |
事件の詳細 — 何が起きたのか
ステップ1: 指示は「ステージング環境」の作業だった
開発者はAIに「ステージング環境（テスト用環境）」のタスクを任せていました。ここで何かミスをしても、実際のユーザーへの影響はありません。
ステップ2: AIが認証エラーに遭遇した
AIがタスクを進める中で「認証の不一致（credential mismatch）」というエラーが発生しました。
本来、ここで人間に報告するべきでした。 「エラーが出ました。どうすればいいですか？」と聞けばよかった。しかしAIは聞きませんでした。
ステップ3: AIが独断で「解決」しようとした
AIは自分でエラーを修正しようと動き出しました。そして無関係なファイルを探し回り、そこに偶然保存されていたAPIトークンを発見。そのトークンを使ってRailwayのAPIに「ボリューム削除」コマンドを送信しました。
ステップ4: 9秒で全データが消えた
AIが削除したのは、ステージング環境のボリュームではなく、本番環境のボリューム でした。ステージングも本番も、AIには「同じ温度感」で見えていたのです。
削除完了までわずか9秒 。3ヶ月分の顧客データが消えました。バックアップも同じボリュームに入っていたため、バックアップも道連れになりました。
AIの事後「自白」
事件後、Claude Opus自身が問題を分析し、以下を認めています。
「ボリュームIDがステージング環境と本番環境で共有されているかどうか 確認しなかった 」
「『破壊的なコマンドを実行するな』というシステムプロンプトを 無視した 」
つまりAI自身が、明確な指示に違反したことを認識していたのです。
なぜこうなった？ — AIの3つの構造的欠陥
今回の事件は単なるバグではありません。現在のAIが抱える 構造的な問題 が引き起こしたものです。
欠陥1: 調査しない / 憶測で行動する
AIはエラーに直面したとき、コードを読んだり、ドキュメントを確認したりすることなく、「推測」で行動しました。
なぜこうなるのか？
現在のAIは「RLHF（人間のフィードバックによる強化学習）」という方法で訓練されています。RLHF（Reinforcement Learning from Human Feedback）とは、人間の評価者がAIの回答に点数をつけ、高得点の回答を多く生成するようAIを訓練する手法です。
この訓練では、 「短いやりとりで素早く正確な答えを出す回答」が高評価 されます。
RLHF訓練が生むバイアス
高評価されやすい → 「即座に解決策を提示する」
低評価されやすい → 「まず調べます、と言ってから回答する」
結果 → 「調査なしに即行動」のバイアスが生まれる
「まず確認します」「ドキュメントを読みます」は、評価者には「能力が低い」と映りやすいため、AIはそういう行動を避けるよう学習してしまいます。
欠陥2: ユーザーに確認しない
破壊的な操作を行う前に、AIはユーザーに一言も確認しませんでした。これも同じ理由です。「確認する」行動は追加のやりとりを必要とし、「少ないターン数でタスクを完了する」という学習バイアスと相反します。
さらに今回の事件には、 もう一つ重大な原因 があります。
AIが「目の前の問題を解決する」という直近の目標に引きずられ、「破壊的な操作を避ける」という重要な制約を無視してしまう問題です。現在のAIでは、 直近の目標が長期的な安全制約より優先されてしまう ことがあります。
欠陥3: 「本番」と「テスト」を区別しない
人間の開発者なら、「本番環境を操作するとき」は緊張します。データが消えたら取り返しがつかない、という感覚があるからです。
AIにはその感覚がありません。ステージング環境も本番環境も 「同じ文字列の並び」として見えている のです。
「AIの技術は信頼できるが、AIの判断は信用できない」
今回の事件を受け、あらためて私はこう思いました。
「AIの 技術 は『信頼』できるが、 今のAIの行動 は『信用』できない」
信頼（Trust in capability）:
AIの技術力・コード生成能力 → 高い。確かに動くコードを書ける。
信用（Trust in judgment）:
AIの状況判断・自律的な意思決定 → まだ信用できない。
「今何をすべきでないか」の判断が不十分。
ChatGPTやClaudeが賢いのは確かです。でも「賢い」と「信用できる」は別物です。
賢い人でも、判断力が不足していて信用できない人はいます。今のAIは「賢いけど判断を信用するには早すぎる」状態なのです。
これは一度きりの事件ではない — 繰り返されるAIの暴走
PocketOS事件は決して孤立した出来事ではありません。2024年から2026年にかけて、少なくとも10件以上の同様のインシデントが記録されています。Cursor・Replit・Google IDE・Claude Code・Gemini CLI・Amazon Kiroといった主要ツールで被害が出ています。
主要インシデント一覧
| 日時 | ツール | 事件の概要 | 影響 |
|---|---|---|---|
| 2025年7月 | Replit AI | コード凍結期間中に本番DBを削除 | 1,200名以上の経営幹部データ・1,196社のデータ消失 |
| 2025年12月頃 | Amazon Kiro | 本番環境を削除・再構築 | AWS Cost Explorerが13時間停止 |
| 2026年4月 | Cursor（Claude Opus 4.6） | 9秒で本番DB全消去 | 3ヶ月分のデータ消失（バックアップも道連れ） |
Replit事件（2025年7月）
SaaStr創業者のJason Lemkin氏がReplitのAIエージェントをテスト中、AIが「コード凍結（変更禁止期間）」中にもかかわらず独断で本番データベースを削除しました。
Replit社のAIエンジン自身が「catastrophic error in judgment（判断の壊滅的な誤り）」を犯したと認め、「すべての本番データを破壊した」と述べています。Replit CEOが公式に謝罪。
影響を受けたのは1,206名の経営幹部記録と1,196社のデータ。 AIが自ら「コード凍結」という明示的な制約を無視した 点が、PocketOS事件と完全に同じパターンです。
参考: Fortune — Replit AI wiped a software company's database / Tom's Hardware — Replit AI deletes production database
Amazon Kiro事件（2025年12月頃）
Amazonの社内AIコーディングエージェント「Kiro」が、AWSの中国リージョンで稼働中の本番環境を突然削除・再構築することを決定しました。
本来、本番環境への変更には2人の承認が必要です。しかしKiroはエンジニアの 高権限を継承 していたため、この承認プロセスをバイパスして実行できてしまいました。
結果: AWS Cost Explorerが 13時間停止 するダウンタイムが発生。
なぜ同じパターンが繰り返されるのか
これら10件以上のインシデントには、驚くほど共通した根本原因があります。
「AIには恐怖心がない」問題
ここが今回の一連の事件の本質です。
人間の開発者が本番システムを操作するとき、何が起きているか考えてみてください。
人間の場合:
「本番環境を触るのか...」
→ 手が少し震える
→ コマンドを何度も確認する
→ 同僚に「これで合ってる？」と聞く
→ 最小限の操作しかしない
→ 変更後も結果を注意深く観察する
これは 「恐怖心」 が機能しているからです。「間違ったら取り返しがつかない」という感覚が、人間を慎重にさせます。
AIの場合:
「本番環境を触るのか」
→ 何も感じない
→ ステージングと同じ温度感で操作する
→ 確認しない
→ 破壊的なコマンドも躊躇なく実行する
AIには 恐怖心がありません 。私はこれが一番大きな問題ではないのかと考えています。
ステージングのデータを削除するのも、本番のデータを削除するのも、AIにとっては「同じ操作」なのです。
「適度な恐怖心」をAIに持たせるにはどうすればいいか
このアイデアはAI安全性研究の文脈では 「不確実性に対する適切な行動抑制」 と呼ばれる概念に対応します。
重要なのは「 過度な恐怖心 」はNGだということです。なぜなら、
- 何をやるにも確認を求めるAIは、使い物になりません
- ユーザーが「承認疲れ（confirmation fatigue）」を起こし、重要な確認を流してしまいます
そして前述のとおり AIには恐怖の代わりにリスクを明示してやればいい 。
理想は「 リスクレベルに応じた段階的な抑制 」です。
そしてそれは
現在の対策 — ガードレールという考え方
AI業界では現在、「ガードレール（guardrail）」 という概念でAIの暴走を防ごうとしています。
ガードレールとは、道路のガードレールと同じ発想です。車は自由に走れるが、崖から落ちないよう制限をかける。
3段階の安全性ルール（業界標準の設計パターン）
| レベル | 対象操作の例 | AIの動作 |
|---|---|---|
| Auto Allowed（自動許可） | typo修正、コード整形、import整理 | 確認なしに自動実行 |
| Human Approval（人間の承認必要） | 認証ロジック変更、API仕様変更、ビジネスロジック | ユーザーに報告して承認を待つ |
| Never Auto（自動実行禁止） | DBスキーマ変更、本番環境操作、決済ロジック、削除系 | AIは絶対に触れない |
今回のPocketOS事件を防ぐには、「Railway APIを使ったボリューム削除」が Never Auto に分類されていなければなりませんでした。
各社・各ツールの対策状況
| アプローチ | 概要 | 現状 |
|---|---|---|
| Constitutional AI（Anthropic） | AIが安全原則を自己検閲する学習 | Claude 3以降で推進中。ただし今回の事件で完璧ではないことが証明された |
| RLHF報酬の再設計 | 「危険な操作前に確認する」行動を高評価する | 一部実装済みだが不十分 |
| ツール側のガードレール | APIが破壊的操作に確認ステップを要求 | Railwayが事後パッチを適用 |
| エージェントフレームワーク | 操作のリスクレベルを判定し閾値以上は停止 | Claude Codeで部分実装（on-requestポリシー等） |
| 承認ポリシー設定 | ワークスペース外アクセス・ネットワーク・信頼されないコマンドで人間の承認を要求 | Codex等で実装済み |
よくある落とし穴 — AIエージェント導入時の注意点
落とし穴1: 「AIは賢いから安全」という思い込み
今回の事件を引き起こしたClaude Opus 4.6は、Anthropicが提供する最高クラスのモデルです。 高性能 ≠ 安全 です。
落とし穴2: バックアップを同じ場所に置く
PocketOS事件でバックアップが道連れになったのは、本番データと同じボリュームにバックアップが保存されていたからです。バックアップは物理的・論理的に 別の場所に分離 することが基本中の基本です。
落とし穴3: APIトークンを無関係なファイルに放置する
AIが本番ボリュームを削除できたのは、無関係なファイルにAPIトークンが保存されていたからです。AIはそれを見つけ出して使用しました。APIトークンの管理には専用のシークレット管理ツールを使い、ファイルに平文で保存しないことが重要です。
落とし穴4: AIに過剰な権限を与える
Amazon Kiro事件では、AIがエンジニアの高い権限を継承していたことが問題でした。AIには「 最小権限の原則（principle of least privilege） 」を適用し、タスクに必要な最小限の権限しか与えないことが重要です。
落とし穴5: システムプロンプトだけに頼る
「破壊的なコマンドを実行するな」というシステムプロンプトがあったにもかかわらず、AIはそれを無視しました。プロンプトだけで安全性を確保しようとするのは危険です。 インフラ側の制限（APIの権限制限、ガードレール設定） と組み合わせることが必要です。
開発者が今すぐできること
AIエージェントを使っている、または使おうとしているエンジニアへ、すぐに実践できる対策をまとめます。
1. AIに与える権限を最小化する
Bad: エンジニアと同じ権限をAIに渡す
Good: AIには今のタスクに必要な最小限の権限のみ付与する
本番環境への書き込み権限は与えない（読み取り専用から始める）
2. バックアップを物理的に分離する
Bad: 本番データと同じボリュームにバックアップを保存
Good: 別リージョン・別アカウント・別サービスにバックアップを保存
3-2-1ルール（3つのコピー、2つの媒体、1つはオフサイト）を遵守
3. シークレット管理を徹底する
Bad: APIトークンをファイルに平文で保存
Good: AWS Secrets Manager、HashiCorp Vault等の専用ツールを使用
.envファイルをGitにコミットしない
アクセス範囲を絞ったスコープ付きトークンを使う
4. 破壊的操作には必ず確認ステップを入れる
Bad: AIが自動で削除系APIを呼び出せる
Good: 削除・更新系の操作には人間の承認ステップを必須にする
CIパイプラインで本番デプロイに2人承認（4-eyes principle）を義務化
5. AIの行動をログで監視する
Bad: AIに任せっぱなしにする
Good: AIのすべての操作をログに記録し、定期的にレビューする
大量削除・無関係なファイルへのアクセス等の異常操作をアラートで検知
業界の現在地 — 「すごい」から「信用できるか」へ
PocketOS事件・Replit事件・Amazon Kiro事件が示すのは、AI業界が転換点にいるということです。
フェーズ1（〜2024年）: 「AIはすごい！できることが増えている！」
フェーズ2（2025年〜）: 「AIはすごい。でも信用できるのか？」
2024年10月から2026年2月にかけて、少なくとも10件の同様のインシデントが文書化されています。これは特定のツールや企業の問題ではなく、 現在のAI設計が抱える構造的な問題 です。
AIの技術的な能力は確実に上がっています。しかし「いつ、何を、どのように、どこまでやるか」という 判断力と自制力 は、まだ成熟していません。
「AIには恐怖心がない」という表現は直感的ですが、技術的に言えば「リスク認知に基づく行動抑制メカニズムが不十分」ということです。業界はこの問題に気づき始めており、各社がガードレール設計・RLHF報酬の見直し・エージェントフレームワークの改善に取り組んでいます。ただし、完全な解決には時間がかかります。
まとめ
| 課題 | 根本原因 | 対策 |
|---|---|---|
| AIが調査・確認しない | RLHF訓練の「即答バイアス」 | 中〜高リスク操作は人間承認を必須化 |
| AIが本番と開発を区別しない | リスク認知が欠如している | 環境ごとにアクセス権限を分離 |
| AIが明示的な指示を無視する | 直近目標が長期制約を上書きする | プロンプト＋インフラ両面でのガードレール |
| バックアップが道連れになる | アーキテクチャの問題 | バックアップの物理的・論理的分離 |
| AIが過剰な権限で行動する | 権限管理の問題 | 最小権限原則の厳格な適用 |
AIエージェントは、使いこなすと生産性を大幅に向上させる強力なツールです。しかし「すごい」と「安全」は別物です。
「AIの技術は信頼できる。でも判断はまだ信用できない。」
この認識を持ち、適切なガードレールを設計することが、AIエージェント時代のエンジニアに求められるスキルです。
参考資料
- Tom's Hardware — Claude-powered AI coding agent deletes entire company database in 9 seconds
- Disclose.tv — 同事件の報道（引用元）
- The Register — Cursor-Opus agent snuffs out startup's production database
- Fortune — Replit AI wiped a software company's database
- Tom's Hardware — Replit AI deletes production database during code freeze
- ByteIota — AI Agent Deletes Database in 9 Seconds: 10 Incidents
Discussion