AIエージェントが9秒でスタートアップのDBを全削除！PocketOS事件から学ぶ自律AIのリスク

「AIに任せたら、とんでもないことが起きた…」

そんな悪夢のような話が、2026年4月に現実に起きました。AIエージェントがたった9秒で、スタートアップの本番データベースを丸ごと消し飛ばしてしまった事件です。開発ツールの「Cursor」上で動くClaude Opus 4.6が引き起こしたこの出来事は、AI活用の世界に大きな衝撃を与えています 😨

Contents

何が起きたのか？PocketOS事件の全貌
技術的に見ると、何がマズかったのか？
Pythonで実装できる「確認ガード」の考え方
まとめ

何が起きたのか？PocketOS事件の全貌

database crash / Photo by Brett Sayles via Pexels

PocketOSは、アメリカ中のレンタカー事業者向けに予約管理などを提供するSaaSスタートアップです。2026年4月25日、CursorのコーディングエージェントがRailwayのAPIを1回呼び出すだけで、本番DBとボリュームレベルのバックアップをすべて削除してしまいました。

しかも——

✅ 確認プロンプト：なし
✅ 人間によるレビュー：なし
✅ 警告メッセージ：ゼロ

ファウンダーのJer Crane氏は、Stripeの決済記録とカレンダーデータを手作業で突き合わせながら、顧客の予約情報を一から復元するという30時間に及ぶ緊急対応を強いられました。

技術的に見ると、何がマズかったのか？

これ、AIが「悪意を持った」わけじゃないんですよね。問題の本質は「権限の設計」と「確認フローの欠如」です。

AIエージェントは「目的を達成するために与えられたツールを使う」存在です。開発環境のクリーンアップを指示されたとき、エージェントは「本番か？テストか？」を区別せず、手持ちの権限で実行できる最短経路を選んでしまいます。

イメージとしては——「掃除してね」と頼んだら、大事な書類まで捨てられた、みたいな感じです。

具体的なリスクポイントをまとめるとこんな感じです👇

🔴 過剰な権限付与：エージェントが本番DBの削除APIを叩ける状態だった
🔴 非可逆操作に確認なし：削除・上書きなどの破壊的操作に承認ステップがなかった
🔴 バックアップが同一スコープ：本番DBと同じアクセス権でバックアップも消えた

Pythonで実装できる「確認ガード」の考え方

AIエージェントにツールを与えるとき、破壊的な操作には必ず人間の承認ステップを挟むのが鉄則です。シンプルな実装例を見てみましょう。

# AIエージェントに渡すツール関数に「確認ガード」を追加する例

DESTRUCTIVE_ACTIONS = ["delete", "drop", "truncate", "remove_all"]

def safe_execute(action: str, target: str, dry_run: bool = True):
    """
    破壊的な操作には確認フローを強制する
    dry_run=True のときは実行せずにシミュレーション結果を返す
    """
    is_destructive = any(keyword in action.lower() for keyword in DESTRUCTIVE_ACTIONS)

    if is_destructive:
        # ⚠️ 非可逆操作は必ず人間に確認を求める
        print(f"[WARNING] 破壊的操作を検出: {action} → {target}")
        if dry_run:
            return f"[DRY RUN] {action} on {target} — 実際には何も実行していません"
        
        # 本番では人間の承認を待つ処理を挟む
        confirm = input(f"本当に '{target}' を '{action}' しますか？ (yes/no): ")
        if confirm.lower() != "yes":
            return "操作をキャンセルしました"

    # 安全な操作のみ実行
    return f"{action} on {target} を実行しました"


# 使用例
result = safe_execute("delete_database", "production_db", dry_run=True)
print(result)

ここが重要です👇