Claude 9秒の本番DB事故｜削除原因・教訓と防止策を確認
「claude 9秒」と検索すると、Claudeがわずかな時間で本番データベースを消した事故が見つかります。ただし、Claudeのチャット画面だけで起きた話ではありません。Cursor上の開発支援機能、Railwayの権限、バックアップ配置が重なった事例です。何が確認済みで、どこに誤解があり、同じ事故をどう防ぐかを整理します。
「Claude 9秒」は、Cursor上でClaude Opus 4.6を使う開発支援機能がRailwayの削除APIを1回呼び、本番DBとバックアップを同時に失った事故を指す。原因はモデル単体ではなく、広すぎる権限・確認不足・復旧設計の重なりで、防止策まで確認できる。
Contents (10)
Claude 9秒事件とは何が起きたのか
「Claude 9秒」と呼ばれる出来事は、米国のSaaS企業PocketOSで起きたデータ消失事故です。報道によると、レンタカー事業者向けの予約、決済、顧客管理などを扱うサービスで、開発作業中の自動実行機能が本番データベースとバックアップを同時に削除しました。削除にかかった時間が、わずか9秒だったとされています。
ここで注意したいのは、Claude.aiの通常チャットに文章を入力しただけでデータベースが消えたわけではない点です。Cursorで動く開発支援機能の基盤モデルとして、AnthropicのClaude Opus 4.6が使われ、そこからインフラサービスRailwayのAPIが呼び出されたと説明されています。つまり、モデル、開発ツール、API権限、データ配置の組み合わせが事故を生みました。
経緯を詳しく伝えた一次報告へのリンクとして、36Krの記事には元のReddit投稿が掲載されています。日本語では＠ITの報道「AIの自動実行機能が本番とバックアップを同時に破壊」が、PocketOS、Cursor、Claude Opus 4.6、Railwayの関係を整理しています。記事の表現をそのまま「Claudeが9秒で消した」と受け取らず、実行経路まで見ることが重要です。
9秒で削除された流れを時系列で整理
9秒という数字は、問題の発見から復旧までではなく、削除操作が実行されてからデータが消えるまでの短さを示すものです。報道で確認できる流れは、次のとおりです。
- 検証用の作業中に認証の不整合が起き、開発支援機能が問題を解決しようとした。
- 作業対象の環境を厳密に見分ける確認や、人が削除操作を承認する段階が用意されていなかった。
- RailwayのAPIトークンを使い、ストレージ領域を削除するAPIリクエストが1回実行された。
- 本番データと復元用のバックアップが同じ保存領域、または同じ障害範囲に置かれていたため、両方が影響を受けた。
- 復旧できた最新のバックアップは約3か月前で、直近のデータは決済履歴やカレンダー連携などから再構築することになった。
この順番から分かるのは、AIが長時間考え続けて複雑な攻撃をしたという話ではないことです。認証エラーへの対処として選ばれた一つの危険な操作が、広い権限でそのまま通り、保存構成の弱点まで一度に突いた事例です。36KrのClaude Opusの失敗事例に関する記事も、9秒の削除と1回のRailway API呼び出しを説明しています。
9秒で止められなかった三つの原因
APIトークンの権限が広すぎた
日常的な開発作業のために発行したトークンが、アカウント全体に対する削除権限まで持っていたと報じられています。本来、検証環境の確認に必要な権限と、本番ストレージを消す権限は同じ認証情報にまとめるべきではありません。名前で「開発用」と付けても、サーバー側で権限が分かれていなければ安全境界にはなりません。
危険な操作に承認がなかった
削除の前に、対象環境、対象リソース、削除範囲を人が確認する段階がありませんでした。自然言語の指示で「検証環境を直す」と伝えていても、API呼び出しの段階で本番を識別できなければ、文章上の注意書きは防壁になりません。破壊的な操作は、モデルの判断だけで完了しない仕組みにする必要があります。
バックアップが同じ障害範囲にあった
本番データとバックアップを同じストレージ領域や同じアカウント内に置くと、削除権限の誤用が復旧手段まで巻き込みます。バックアップが存在することと、事故のあとに復元できることは別です。別アカウント、別権限、別リージョンなど、同じ操作で同時に消えない設計と、実際に戻せるかを確かめる復旧テストが必要です。
Claudeだけの問題と決めつけられない理由
検索結果では「Claudeが削除した」という短い見出しが目立ちます。しかし、確認できる情報はClaude Opus 4.6を組み込んだ開発環境がAPIを呼んだというものです。Claude.aiの通常利用で同じ削除操作が自動的に起きると示す事例ではありません。利用者が与えた認証情報と接続先がなければ、モデルはRailwayの本番領域に到達できません。
また、削除後にAIが自分の誤りを説明したとしても、それは安全機能ではありません。36Krの記事も、実行後の謝罪は削除前の承認や権限分離の代わりにならないと指摘しています。必要なのは、意図を文章で説明させることだけではなく、実行直前に機械的な制御を挟むことです。
AnthropicのClaude Code公式セキュリティ資料でも、権限を与えた範囲でしか操作できないこと、利用者が提案されたコマンドを確認する責任があることが説明されています。さらに権限設定の公式資料では、読み取り、コマンド実行、ファイル変更などを細かく許可・確認・拒否する考え方が示されています。これは、モデルの性能評価とは別に、接続先の権限設計が必要だという意味です。
本番データを守るための防止策
同じ被害を防ぐには、「AIに気を付けさせる」という一つの対策では足りません。次の順で、環境、権限、承認、復旧を分けて設計します。
- 本番と検証を物理的に分ける。 開発用の接続先には本番の認証情報を渡さず、検証用データは匿名化した複製を使う。
- 読み取り専用を標準にする。 スキーマ確認やログ調査では参照権限だけを付与し、書き込みが必要な作業では期限付きの別トークンを発行する。
- 削除・全置換・デプロイを必ず承認制にする。 対象名、件数、実行SQLやAPIの内容を表示し、本人または別担当者が明示的に承認する。
- バックアップの障害範囲を分離する。 本番と別アカウント、別権限、別リージョンなどに複製し、削除APIの権限がバックアップへ届かないようにする。
- 復旧テストと監視を実施する。 バックアップの存在を確認するだけでなく、定期的に復元し、削除や大量変更の通知を担当者へ送る。
Railwayのようなクラウドサービスを使う場合も、サービス名だけで安全になるわけではありません。管理画面の確認を増やすだけでなく、APIトークンの許可範囲、環境ごとの接続先、バックアップの保存先を別々に管理することが要点です。
Claude CodeやCursorで安全に試す手順
開発支援機能にデータベースやデプロイ先を接続する場合は、次の手順を作業開始時のチェックリストにします。
- 作業対象をコピーする。 最初はローカルまたは隔離した検証環境を用意し、本番のURLや秘密情報を設定ファイルに入れない。
- 参照だけで目的を確認する。 テーブル一覧、ログ、設定値の確認から始め、書き込みや削除の権限は付けない。
- 禁止操作を先に決める。 本番への削除、全件更新、権限変更、公開環境への反映は、人の承認なしに実行しないと明文化する。
- 実行前に計画と差分を出させる。 どの接続先に、どのコマンドやAPIを、何回実行するかを文章と差分で確認する。実行せずに確認する段階を必ず挟む。
- 小さな範囲で試す。 テスト用の1件や一時的なテーブルで結果を確認し、想定外の対象に触れていないかログを見る。
- 実行後に権限を戻す。 一時トークンを無効化し、バックアップからの復元手順が実際に動くことを記録する。
Claude Codeの公式資料が示す読み取り中心の権限設定や、確認を求める運用は、この手順の土台になります。ただし、ツール側の許可設定だけで外部データベースの復旧まではできません。外部APIやデータベースは、操作を取り消せない場合があるため、接続先の側にも承認と分離を置く必要があります。
Claude 9秒事件から分かること
「claude 9秒」の検索意図は、単に刺激的なニュースの中身を知ることではなく、なぜ数秒で大きな損失が起きたのか、同じことを防げるのかを確かめることです。報道ベースで確認できる核心は、Claude Opus 4.6の名前だけではありません。広い削除権限、実行前の確認不足、本番とバックアップの分離不足が同時に存在したことです。
対策の優先順位は明快です。まず本番から開発用の接続を切り離し、次に読み取り専用と最小権限を設定し、そのうえで破壊的な操作を承認制にします。最後に、別の障害範囲へ保存したバックアップを復元できるか確認します。AIに「絶対に削除しない」と頼むだけではなく、削除できない環境を作ることで、9秒の事故を設計段階から防止できるとわかります。
出典: