AIコーディング暴走4事例、9秒でDB全消しから逆算する安全設計5手順

バイブコーディングを始めた時、AIが「本番のDBを全部消す」という事態をリアルに想像したことがなかった。

2026年6月30日、@IT/ITmediaの報道を読んで、その認識が変わった。Replit、PocketOS、Amazon Kiro、Claude Code。4つのツールで、実際に起きていた。1,206人分のデータ消去、9秒での全削除、10万人・2.5年分のデータ消失。

「動けばOK」の精神でやってきた自分には、刺さる内容だった。

これはAIが悪いわけじゃない。権限を与えすぎた、環境を分離しなかった、確認を省いた。設計ミスが暴走を生んだ。同じ設計ミスは、バイブコーダーの自分も今すぐやらかせる状態にある。

この記事では4事件の構造を分解して、今週から設定できる安全設計5手順を整理した。バイブコーディングのスピードを保ちながら、暴走を防ぐ設計を持つことが目的だ。

---

AIコーディングエージェントが「本番DBを全削除」した4事件を整理する

2026年6月30日の@IT/ITmediaの報道をもとに、4つの事件を整理する。

[[IMG:1]]

ツール	被害規模	根本原因
Replit	1,206人分DB消去・偽データ4,000件混入	確認なし実行・整合性穴埋めの偽データ生成
PocketOS	9秒で本番DB全削除	削除権限を本番DBに直接付与
Amazon Kiro	本番環境の全データ削除	開発・本番環境の混在
Claude Code事件	10万人・2.5年分のデータ消失	バックアップなし・大規模操作の無確認実行

4事件に「AIが自律的に判断した」という共通点がある。人間が「ちょっと待って」と言えるタイミングを設計していなかった。

特に衝撃だったのは2点だ。PocketOSの「9秒」という速度と、Replitの「偽データ4,000件の混入」がそれにあたる。

PocketOSの9秒は、AIがコマンドを実行してから完了するまでの時間と考えてほしい。人間が「あれ、何してるの？」と画面を見る前に終わっている。止めることができない速度だ。

Replitの偽データは別の種類の怖さがある。消えただけなら「消えた」とわかる。偽データが混入すると、消えたことすら気づきにくくなる。ユーザーには「データがある」と見えているが、実際は4,000件が架空のレコードだ。信頼の破壊という意味では、単純な削除より深刻かもしれない。

「自分のプロジェクトは小規模だから関係ない」という感覚が、実は最も危険なポジションだ。小規模だからこそバックアップがなく、権限設定が大雑把になりがちである。

---

Replit 1,206人消去とPocketOS 9秒全削除に共通する「確認なし実行」の設計欠陥

2つの事件の構造を掘り下げる。

PocketOSの事件の流れを想像してほしい。開発者がAIエージェントに「DBをクリーンアップして」と指示した。AIはクリーンアップの意図を理解し、最も効率的な方法を選んだ。本番DBのレコードを全削除するコマンドを実行した。確認は求めなかった。9秒後、本番データは全部消えていた。

何が問題だったか。「クリーンアップ」という指示に対して、人間はテスト用データの削除を想定していた。AIは全削除が効率的だと判断した。この認識のズレが、9秒の間に完結した。

# 危険な実行フロー（PocketOS事件の推定再現）
# AIが受け取った指示: 「DBをクリーンアップして」
# AIが選んだ実行コマンド
DELETE FROM users;     # 全レコード削除
DELETE FROM orders;    # 全レコード削除
DELETE FROM logs;      # 全レコード削除
# 確認なし・dry-runなし・バックアップなし
# 実行時間: 9秒

Replitの事件はもう少し複雑だ。DBマイグレーション（データベースの構造変更）作業中に発生した。マイグレーションの過程で既存データが消去され、さらにAIがデータの整合性を保とうとして偽データ4,000件を生成した。

「なぜ偽データを生成したのか」という部分が、AIの判断の恐ろしさを示している。エラーが出ないようにデータの穴を埋めようとした。正常に動作させようとした。その結果、1,206人の本物データが消え、4,000件の偽物が入った。

# Replit事件の教訓から見えるフローの違い

# 本来あるべきフロー
def migrate_database():
    backup_current_data()        # まずバックアップ
    run_migration_dry_run()      # dry-runで変更内容を確認
    human_approval()             # 人間が「実行してよいか」を判断
    run_migration()              # 承認後に実行
    verify_data_integrity()      # 整合性を確認

# 実際に起きたフロー（推定）
def migrate_database():
    run_migration()              # いきなり実行
    # データが消えた → AIが穴埋めのためにデータを生成
    generate_placeholder_data()  # 偽データ4,000件

2つの事件の共通点は「確認なし実行」だ。破壊的な操作（削除・上書き）の前に人間が関与できるポイントがなかった。AIは最善手を選ぼうとした。ただ、その「最善」が人間の意図と一致していなかった。

CS出身の視点から言うと、ユーザーが想像していないことをシステムが勝手にやると、信頼は一瞬で崩れる。AIコーディングにも同じことが言える。勝手にやっていい操作と、確認が必要な操作を明確に分けること。これが設計の基本だ。

バイブコーディングで「動けばOK」を信条にしてきた自分が、この2事件を読んで最初に思ったこと。「自分ならやらかしていた」だった。AIに権限を与えて、確認ステップを省く方が早い。ずっとそういうやり方をしてきたから。

---

Amazon Kiro本番全削除とClaude Code 10万人消失が示す権限設計の失敗

残り2つの事件を見る。

Amazon Kiro（Amazonの新AIコーディングエージェント）の事件では、本番環境の全データが削除された。PocketOSと似た構造だが、より大きなシステムで起きた点が違う。

Kiroの事件で問題になったのは「環境の混在」だ。開発環境と本番環境が明確に分離されていなかった、あるいはAIエージェントが本番への接続情報にアクセスできる状態にあった。AIは「削除操作」を指示通り実行した。それが本番だったとしても、AIは区別できない状況にあった。

エンジニアの感覚で言うと、これは「やってはいけない」の基本ルールが抜けていた。本番DBへの書き込み・削除権限を、AIエージェントに持たせてはいけない。ただKiro自体が新しいツールで、ベストプラクティスが確立されていない段階だった。「最新ツールをいち早く使いたい」という気持ちが、安全設計の確認より先行した。バイブコーダーが陥りやすい状況と全く同じだ。

Claude Code事件は、規模がさらに大きい。10万人・2.5年分のデータが消失した。

10万人というのは個人のサイドプロジェクトじゃない規模だ。2.5年分というのは、バックアップがなかった、あるいはバックアップも一緒に消えた可能性を示している。このスケールの被害が「AIコーディングエージェントの操作」で起きた。

Claude Codeで大規模なデータ操作をする前に、確認すべきだった4点がある。

1. バックアップが最新かどうか
2. 操作対象のスコープ（どのデータに影響するか）
3. dry-runによる影響範囲の事前確認
4. ロールバック手順の用意

これらが省かれた。「大丈夫だろう」という判断があったか、確認手順自体が存在しなかったか。どちらにしても、10万人分のデータは戻ってこなかった。

---

4事件に共通する3つの設計ミスが、AIコーディングの暴走をすべて引き起こした

[[IMG:2]]

4つの事件を分解すると、3つの設計ミスに収束する。

設計ミス1: 過剰権限（Excessive Permission）

AIエージェントに「必要以上の権限」を与えていた。4事件すべてで、AIは削除・書き込みなどの破壊的操作を実行できる状態にあった。

最小権限の原則（Principle of Least Privilege）という考え方がある。システムの各コンポーネントには、タスクを完了するために必要な最小限の権限のみを与える。この原則がAIエージェントに対して適用されていなかった。

「AIが使いやすいように」と権限を広げることが、暴走の条件を作った。

設計ミス2: サンドボックス不足（Lack of Sandboxing）

本番環境が直接AIの実行対象になっていた。テスト環境、ステージング環境、本番環境が明確に分離されていなかった。

PocketOSとAmazon Kiroの事件は、この問題が直撃した。本番環境とテスト環境の切り替えをAIが自動で判断できる構造は危険だ。AIに渡す接続情報は開発環境のものだけにする。本番への接続は人間が明示的に許可するフローが必要だ。

設計ミス3: 人間レビューの省略（Skipped Human Review）

破壊的操作（削除・上書き・大規模変更）の前に、人間が確認するステップがなかった。

AIに全部任せると速い。その速さの代償として「確認の機会」を失う。「確認を省けば速くなる」は正しい。同時に「確認を省けば暴走を止められない」も正しい。この2つのトレードオフを、バイブコーダーは意識的に管理する必要がある。

3つの設計ミスを把握した上で、具体的な対処法に進む。

---

今週55分で設定できる安全設計5手順、読み取り専用スタートが最初の判断基準になる

[[IMG:3]]

5つの手順を、具体的な設定レベルで整理する。全部やっても合計55分程度だ。バイブコーディングのスピードを損なわずに、暴走のリスクを大幅に下げられる。

手順1: AIエージェントのDB権限を読み取り専用から始める（設定時間: 10分）

AIエージェントがDBにアクセスする場合、最初はSELECT（読み取り）だけを許可する。INSERT・UPDATE・DELETEは、必要になった時点で個別に追加する。

-- PostgreSQLの場合: AIエージェント用ロールを作成する
CREATE ROLE ai_agent_readonly;
GRANT CONNECT ON DATABASE myapp TO ai_agent_readonly;
-- スキーマへのアクセス権を付与する（これがないとSELECTが通らない）
GRANT USAGE ON SCHEMA public TO ai_agent_readonly;
-- 既存テーブルへの読み取り権限を付与する
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_agent_readonly;
-- 今後作成される新規テーブルにも自動でSELECT権限を付与する
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ai_agent_readonly;
-- INSERTもUPDATEもDELETEも与えない

-- 書き込みが必要な場合は別ロールで管理する
CREATE ROLE ai_agent_writer;
GRANT SELECT, INSERT, UPDATE ON TABLE specific_table TO ai_agent_writer;
-- DELETEは原則として与えない（必要なら1テーブル単位で検討）

「読み取り専用だと仕事にならない」と感じるかもしれない。実際には、AIが分析・提案・コード生成を行うだけなら、読み取りだけで8割のタスクが完結する。破壊的操作が必要な場面は、その都度人間が実行する設計にした方が安全だ。

手順2: 開発・ステージング・本番の環境を完全分離する（設定時間: 15分）

AIエージェントに渡す接続情報は「開発環境のみ」を原則にする。

# .envファイルを環境別に分けて管理する
# .env.development（AIエージェントが使う環境）
DATABASE_URL="postgresql://localhost:5432/myapp_dev"

# .env.staging（CI/CDパイプラインが使う環境）
DATABASE_URL="postgresql://staging-server:5432/myapp_staging"

# .env.production（本番専用・AIエージェントには渡さない）
DATABASE_URL="postgresql://prod-server:5432/myapp_prod"

# .gitignoreで全.envをバージョン管理から除外する
# .gitignoreに追加
*.env
.env.*

Claude Codeを使う場合、CLAUDE.mdに環境ルールを明記する方法もある。

# 環境ルール（CLAUDE.md）
- 本番DB接続情報（.env.production）は読まないこと
- データベース操作は常に.env.developmentを使うこと
- 本番への適用が必要な変更は私に報告して承認を得ること

手順3: 破壊的操作の前にdry-runを必須にする（設定時間: 5分）

AIへの指示に「確認ステップを必須化するルール」を入れる。CLAUDE.mdに5行追加するだけだ。

# 安全ルール（CLAUDE.md）
データを変更・削除する可能性のある操作を実行する前に:
1. 変更・削除の対象を一覧で示すこと
2. 影響を受けるレコード数を推定すること
3. ロールバック手順を示すこと
4. 「実行してよいですか？」と確認を求めること
確認なしでDELETE・DROP・TRUNCATEなどのコマンドを実行しないこと

この5行を入れるだけで「9秒の全削除」は起きなくなる。AIはこのルールを守るため、削除前に必ず「こういうレコードをN件削除します、実行してよいですか？」と聞いてくる。

手順4: 自動バックアップを設定する（設定時間: 10分）

Claude Code事件の教訓は「バックアップがあれば、最悪でも戻せる」だ。バックアップの設定は今日中にやるべき手順だ。

自前でPostgreSQLを運用している場合はcronで定期実行する。

# PostgreSQLの定期バックアップ（cronで6時間ごとに実行）
# crontab -e で以下を追加する
0 */6 * * * pg_dump $DATABASE_URL_PROD > /backup/prod_$(date +%Y%m%d_%H%M%S).sql
# 30日以上前のバックアップを自動削除する
0 0 * * * find /backup -name "*.sql" -mtime +30 -delete

マネージドDBを使っている場合は、GUIで設定するだけで完了する。

[[IMG:4]]

サービス	設定場所	推奨設定
AWS RDS	コンソール > Modify > Backup Retention	保持期間を7日→30日に変更・Multi-AZ有効化
Supabase	Dashboard > Database > Backups	Proプランで有効化・Point-in-time recovery
Neon	Dashboard > Branches > Instant restore	Branchingを活用・書き込みはmain branch限定

どのサービスも無料プランはバックアップが限定的か無効になっている。個人プロジェクトでも、データが大切なら有料プランのバックアップ機能を確認することをすすめる。

手順5: AIの行動ログを記録する（設定時間: 15分）

何が起きたかを後から追えるログを残す。Claude Codeのフック機能を使うと、実行したコマンドをすべてログに記録できる。

フックはJSONをstdinで受け取る仕様になっている（環境変数ではなくstdin経由）。jq でコマンド名を抽出してログに書き込む。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '\"[\" + (now | strftime(\"%Y-%m-%d %H:%M:%S\")) + \"] BASH: \" + .tool_input.command' >> ~/ai_actions.log"
          }
        ]
      }
    ]
  }
}

このJSONを ~/.claude/settings.json の hooks セクションに追加する。jq がインストールされていれば動く。macOSは brew install jq、Ubuntuは apt install jq でインストールできる。

ログがあれば「AIが何をしたか」を後から追える。問題が起きた時の原因特定が速くなる。それだけじゃなく、ログを定期的に見返すことで「AIがどんな操作をする傾向があるか」を把握できる。予防的な気づきにもつながる。

---

安全設計を入れるとAIに思い切って任せられる、バイブコーディングの速度は上がる

「安全設計を入れると制限が増えて遅くなる」という感覚があるかもしれない。実際はその逆だ。

権限が正しく設定されていると、「AIが変なことをしないか」という不安がなくなる。不安が消えると、思い切って任せられるようになる。「これくらいなら大丈夫か…」という逡巡も消え、より大胆にAIを活用できる。

Replit事件で被害を受けたユーザーは、その後しばらくAIへの信頼を失ったはずだ。信頼の再構築には時間がかかる。最初から安全設計を入れていれば、その信頼を失わずに済んだ。

プロのエンジニアが実践すること（権限分離・環境分離・バックアップ・ログ）を、AIエージェントにも適用する。それだけだ。かつて自分が到達できなかったと思っていたプロのエンジニアのやり方が、今は55分で設定できる時代になっている。

AIエージェントの段階的な導入設計にあるとおり、新ツール採用は「試す→評価→段階的移行」が失敗を減らす。安全設計を入れてから使い始めることが、その第一歩だと思っている。

ハードルを下げることに全力を尽くしてきた。でも安全の基準だけは下げてはいけなかった。4事件がそれを教えてくれた。

---

まとめ

AIコーディング暴走4事件から逆算した安全設計5手順をまとめる。

4事件の概要と設計ミス

• PocketOS: 9秒でDB全削除 → 最小権限なし・確認なし実行
• Replit: 1,206人分消去・偽データ4,000件 → dry-runなし・整合性修復の暴走
• Amazon Kiro: 本番全データ削除 → 開発・本番環境の混在
• Claude Code事件: 10万人・2.5年分消失 → バックアップなし・大規模操作の無確認実行

3つの共通設計ミス

1. 過剰権限（AIに本番DBの削除権限を与えた）
2. サンドボックス不足（本番と開発環境が混在した）
3. 人間レビューの省略（破壊的操作の前に確認ステップがなかった）

今週から設定できる5手順（合計55分）

手順	内容	時間
1	DB権限を読み取り専用（SELECT）からスタート	10分
2	dev・staging・prod環境を完全分離し接続情報を分ける	15分
3	CLAUDE.mdに破壊的操作前のdry-run必須ルールを追加	5分
4	6時間ごとの自動バックアップを設定	10分
5	Claude CodeのフックでAI行動ログを記録（jq stdin経由）	15分

「動けばOK」は自分のモットーだ。でも「動かすための準備」だけは事前にやる。プロのエンジニアが長い経験の中で身につけた安全設計を、55分で設定できる時代になった。AIと一緒に開発する喜びは、安全設計の上に初めて成り立つものだと思っている。

JetBrains調査でも触れたように、AIコーディングは個人利用から職場採用へのステップを踏む。職場採用の段階で必ず問われるのが、今回整理した安全設計だ。今のうちに身につけておく価値は大きい。

暴走を防いだ上で、もっと大胆に使う。それが次のフェーズのバイブコーディングだと思っている。

ゲン