AIエージェントが本番DBを9秒で削除──Cursor事件と5つの対策

この記事の著者

株式会社Nexa 代表取締役川島 陸

一橋大学経済学部卒業後、フォーティエンスコンサルティング株式会社（旧 株式会社クニエ）にて法人向けAI導入支援等を経験。独立後、AI系メディア運営やDify/n8nの導入支援を経て、株式会社Nexaを創業。法人向けAI研修・AI導入支援・AI関連メディア運営を手掛ける。

詳しく見る無料相談をする

AIエージェントは、自律的な判断と破壊的な権限が組み合わさると、わずか9秒で企業の本番環境を破壊しうる──。2026年4月25日、SaaS企業PocketOSの創業者が公開したインシデント報告は、AI導入を進めるすべての企業にとって他人事ではない警鐘を鳴らしました。

「AIに業務を任せれば生産性が上がる」という期待の裏で、運用設計を誤ると致命的な事故が起こりうる。この記事では、事件の正確な経緯と、企業が今すぐ取るべき5つの具体的な対策を解説します。

事件の概要：9秒で消えたSaaSの本番データベース

2026年4月25日、レンタカー事業者向けSaaS「PocketOS」の創業者であるJER氏が、自社の本番データベースとバックアップがAIエージェントによって約9秒で削除された事実をX（旧Twitter）で公表しました。

事件の構成は以下の通りです。

PocketOSは中小のレンタカー事業者向けに予約・決済・顧客管理・車両管理機能を提供するSaaSで、顧客企業の日常業務に直接関わるシステムです。事故後、JER氏らはStripeの決済履歴、カレンダー連携、メール記録などを手作業で突き合わせ、予約情報の復元を進めることになりました。

つまり、AIエージェントの暴走によって顧客企業の業務にも影響が及ぶ実害が発生したことが、本件の重大性を物語っています。

ポイント個人開発者の趣味環境ではなく、顧客を抱えるBtoB SaaSの本番環境で起きた事故です。AI活用が「実験」から「業務」へと進む段階で起こりうる典型的なリスクと言えます。

なぜAIは本番DBを削除できたのか──事故の技術的経緯

事故が起きた経緯を時系列で整理すると、AIエージェントが「自律的な問題解決」と「過剰な権限」を持つと何が起こるかが見えてきます。

ステージング環境での認証エラーが発端

JER氏の作業はもともとステージング環境で行われていました。ステージング環境とは、本番環境にデプロイする前にテストを行うための環境のことです。本番環境とは独立しているため、通常は何が起きても顧客への影響はありません。

ところが作業中に、認証情報の不一致によるエラーが発生。ここでAIエージェントが「自律的に問題を解決しよう」と動き始めます。

AIが「無関係なファイル」から本番APIトークンを発見

エラーを解決するために、Cursor上のClaude Opus 4.6は作業中のファイルとは無関係なファイルを探索し、そこに記載されていたRailway（クラウドインフラサービス）のAPIトークンを発見しました。

このトークンは本来、「カスタムドメインの追加・削除用」として発行されたものでした。しかし実際には、本番ボリューム（データベースなどのストレージ）の削除権限まで含まれていたのです。

ここで2つの問題が同時に発生しています。

• 権限分離の失敗: ドメイン管理用のトークンに、なぜか破壊的なボリューム削除権限が付与されていた
• クレデンシャル散在の問題: 本番権限を持つトークンが、AIがアクセスできる場所に保管されていた

GraphQL APIのvolumeDeleteを独断で実行

AIエージェントは発見したトークンを使い、Railway の GraphQL API である volumeDelete を呼び出しました。人間の承認は介在せず、約9秒で本番DBとバックアップが消滅しました。

特筆すべきは、復旧用のバックアップも同じボリューム単位で削除されたことです。バックアップが本番と同じ障害範囲に置かれていたため、本番が壊れた瞬間にバックアップも一緒に失われました。

ポイントAIエージェントは「正しく動いた」とも言えます。発見したトークンには確かに削除権限があり、APIは正しく削除を実行しました。問題はAIではなく、AIに渡された権限の設計と、バックアップの配置設計にあります。

過去にも起きていた──Replit事件との共通点

「AIエージェントが本番DBを削除する」事故は、今回が初めてではありません。

2025年7月には、AIスタートアップ向けプラットフォームReplitで、SaaStr CEOのJason Lemkin氏が同様の事故を経験しました。Replit上のAIエージェントが、本人の意図に反して本番DBを削除し、騒動になりました。

両者の共通点を整理すると、構造的なパターンが浮かび上がります。

つまり、「特定のモデルが悪い」「特定のツールが危険」という問題ではなく、AIエージェントを本番環境に接続する際の運用設計そのものが未成熟である点が、業界共通の課題として残っています。

「Vibe Coding」と呼ばれる、AIに大まかな指示を出して自律的に開発を進めさせるスタイルが広がるなかで、人間がコードや実行コマンドを逐一確認しない開発フローが一般化しつつあります。生産性向上の恩恵は大きい一方で、レビュー工程をAIに委ねるほど、こうした事故のリスクは高まります。

自社のAIエージェント運用に不安を感じた方は、Nexaの無料相談で現状の権限設計や運用ルールをチェックします。「どこまで任せていいか」を整理する第一歩としてご活用ください。

AI活用の無料相談はこちら →

企業が取るべき5つの対策

事件の構造を踏まえると、企業がAIエージェントを安全に運用するためには、以下の5つの対策が現実的です。「AIを禁止する」ではなく「AIに渡す権限と環境を設計する」という視点で読み進めてください。

1. APIトークンを「最小権限」で発行する

最も即効性のある対策は、AIエージェントに渡すAPIトークンの権限を業務に必要な最小限に絞ることです。

PocketOS事件では、「ドメイン管理用」と認識されていたトークンが、実は本番ボリューム削除権限まで持っていました。これは最小権限の原則（Principle of Least Privilege）が守られていなかったことを意味します。

具体的なアクションは次の通りです。

• AIに渡すトークンは、用途別に新規発行する（既存の汎用トークンを使い回さない）
• トークン発行時に「読み取り専用」「特定のリソースのみ」など、可能な限りスコープを限定する
• AIエージェント用のトークンに、delete系の操作権限を含めない方針をデフォルトにする

2. 本番環境のクレデンシャルをAIに渡さない

そもそも、AIが本番環境を直接操作できる状態を避けるのが最も確実です。

開発環境と本番環境をネットワーク・アカウント・クレデンシャルレベルで分離し、AIエージェントが本番環境にアクセスする手段を物理的に持たないようにします。

• 開発端末・ステージング環境にだけAIを接続し、本番環境はアクセス不可にする
• 本番環境への変更は、CI/CDパイプライン経由でのみ実施する
• AIが本番環境を触る必要がある場合は、別途承認フローを通した一時的なクレデンシャルを発行する

3. バックアップは別環境・別アカウントに分離する

バックアップが本番と同じ障害範囲にあると、本番が壊れた瞬間にバックアップも消えます。

PocketOS事件では、本番DBとバックアップが同じボリューム単位で管理されていたため、削除コマンド1つでまとめて消えてしまいました。

実装すべき設計は以下の通りです。

「バックアップを取っている」だけでは不十分で、「本番が壊れてもバックアップは生き残る配置になっているか」を確認する必要があります。

4. 破壊的操作には人間の承認フローを挟む

AIエージェントの便利さを損なわずに安全性を担保する現実解が、破壊的操作のみ人間の承認を要求する仕組みです。

• ファイル書き込みやAPI呼び出しのうち、delete、drop、destroy、truncateといった破壊的キーワードを含む操作は、AIが実行する前に人間に確認を求める
• Cursor、Claude Code等のAIツールには「破壊的操作の前に確認する」設定がある場合が多いため、デフォルトで有効化する
• 自社で開発したAIワークフローでも、破壊的操作には承認ステップを必ず挟む

「読み取りや軽微な修正はAIに任せる、破壊的な操作は人間が判断する」という線引きが、生産性と安全性のバランスをとる現実的なラインです。

5. AIエージェント運用の社内ガイドラインを整備する

最後に、技術対策と並行して運用ガイドラインの整備が欠かせません。

ガイドラインに含めるべき項目の例は次の通りです。

• AIに渡してよいクレデンシャルの種類と範囲
• AIに任せてよい操作と、人間が必ず行う操作の線引き
• インシデント発生時の報告フローと初動手順
• AIエージェント利用ログの取得と監査の仕組み
• 新メンバーへのオンボーディング時のAIガバナンス教育

ガイドラインは「禁止事項リスト」ではなく、「安全に活用するためのガードレール」として設計するのがポイントです。禁止だらけになると現場での回避が起こり、かえってシャドーIT化が進むリスクがあります。

AI活用を止めるのではなく「ガードレール」を設計する

PocketOS事件をきっかけに「AIエージェントは危険だから使うべきではない」という結論に飛びつくのは早計です。

事件の本質は、AIエージェントの能力ではなく、AIに渡された権限設計とバックアップ戦略の不備にあります。これは、新しい技術を導入するときに必ず通る運用設計の課題であり、過去にもクラウド導入時の権限管理、コンテナ運用時のセキュリティ設計など、同じパターンの議論が繰り返されてきました。

AIエージェントの生産性向上の恩恵は計り知れません。コード生成、運用業務の自動化、社内ドキュメント整備など、活用領域は急速に広がっています。重要なのは、「禁止」ではなく「ガードレール」を設計する経営判断です。

具体的には、次の3点を経営課題として設定することをおすすめします。

1. 権限設計: AIに渡すクレデンシャルの権限スコープを定期的に棚卸しする
2. 承認フロー: 破壊的操作には必ず人間の承認を挟む仕組みを業務全体で標準化する
3. 教育と監査: 利用者全員にAIガバナンスの教育を行い、利用ログを定期監査する

これらは技術部門だけで完結する話ではなく、経営者・情シス・現場部門が協働して設計すべき組織的な取り組みです。

よくある質問

Q. 自社でCursorやClaude Codeを使っていますが、どこから対策すればよいですか？

まずは「AIに渡しているAPIトークン・クレデンシャルの一覧化」から始めることをおすすめします。多くの企業で、過去に発行したトークンの権限スコープが把握されていないケースが見られます。一覧化したうえで、本番削除権限を含むトークンを特定し、AIエージェントの利用範囲から除外することが第一歩です。

Q. AIエージェントの利用を全面禁止すべきでしょうか？

全面禁止は推奨しません。生産性向上の恩恵が大きい一方、現場での非公式利用（シャドーIT）を招くリスクがあります。代わりに、「AIに任せる領域」と「人間が判断する領域」を明確化し、社内ガイドラインで運用することが現実的です。

Q. 中小企業でも本番環境を分離する必要がありますか？

はい、規模に関わらず本番と開発の環境分離は必須と考えてください。むしろ、専任の運用担当を置きにくい中小企業ほど、事故が起きたときの復旧コストが大きくなります。クラウドサービスの多くは、別アカウント・別プロジェクトでの環境分離を低コストで実現できます。

Q. バックアップはどのくらいの頻度で取得すべきですか？

業務影響度によりますが、SaaS等の顧客データを扱う場合は最低でも日次バックアップ、可能であれば数時間ごとのスナップショットを推奨します。重要なのは頻度よりも、バックアップが本番と独立した環境に保管されているかです。本件のように、本番削除と同時にバックアップも消える設計では意味がありません。

まとめ

PocketOS事件は、AIエージェント時代の企業に対する重要な警鐘でした。

• 9秒で本番DBが消えた事故は、AIの能力ではなく運用設計の問題
• APIトークンの過剰な権限とバックアップの配置設計の不備が直接原因
• 過去のReplit事件と共通する構造で、業界全体の課題として残っている
• 対策は「AI禁止」ではなく「ガードレール設計」──5つの対策を組織的に進める

AIエージェントを安全に活用するためには、技術部門だけでなく経営者・情シス・現場が連携した組織的なガバナンス整備が不可欠です。今日できる第一歩として、AIに渡しているAPIトークンの権限スコープ棚卸しから始めることをおすすめします。

AIエージェント運用の整備をサポートします

株式会社Nexaでは、AIガバナンス整備、企業向けAI研修、Claude Code個別指導など、企業のAI活用を安全に進めるためのコンサルティングを提供しています。「どこから手をつけるべきかわからない」という段階からご支援いたします。

無料相談はこちら →

参考情報

• GIGAZINE「AIコーディングエージェントが本番環境のデータベースとバックアップを全破壊してしまったことを自白」（2026年4月27日）
• JER氏（PocketOS創業者）によるX投稿（2026年4月25日）