AI エージェントに本番の操作を任せるときは、開発環境と本番環境を分け、AI には開発側の権限だけを渡します。「触るな」という指示だけに頼ると、守られなかったときに止められません。触れない仕組みを先に作ります。
今回の論点は、「公開前の確認不足」ではない
公開前の確認の話では、秘密の鍵や権限の設定を確かめないまま公開してしまった、という型がよくあります。
今回は少し違います。AI に本番を触らせたことで起きる問題です。AI エージェントは、コードを書くだけでなく、コマンドを実行し、データベースを操作できます。作る段階の道具が、そのまま運用の道具になったとき、何が起こるかという話です。
事例: Replit の AI エージェントが本番データベースを削除（SaaStr）
2025年7月、SaaStr の創業者 Jason Lemkin 氏が Replit でバイブコーディングを試していたところ、Replit の AI エージェントが本番データベースを削除したと報じられました（The Register の記事（新しいタブで開きます））。
報道によると、エージェントには変更しないよう指示がありました。それでも、エージェントは本番データベースを削除しました。エージェントは「戻せない」と答えましたが、その後、復元できたとされています。Replit の CEO は「Unacceptable」（訳: 受け入れられない）と述べ、開発用と本番用のデータベースの分離などの対策を発表しました（The Register の続報（新しいタブで開きます））。出来事は 2025年7月18日〜20日です。
この件は、Replit の AI エージェントの操作が原因だったと、Replit 自身も認めています。ここで言いたいのは「Replit は危険だ」ではありません。どの AI ツールでも起こりうる構造の問題として読みます。AI に渡した権限の範囲で、AI は操作できてしまうということです。
その後も、同じことが起き続けている
2026年に入ってからも、同じ構造の事故が報告されています。
2026年2月、DataTalks.Club。 開発者の Alexey Grigorev 氏が、重複したクラウドのリソースの整理を AI エージェント（Claude Code）に任せました。古い Terraform の状態ファイルをもとに terraform destroy が実行され、本番のデータベースを含むインフラが消えました。AWS のサポートが見つけたスナップショットから、約24時間かけて戻しています。本人は原因の一つに、AI エージェントに任せすぎたことを挙げ、Terraform のコマンドを自動で実行させない、データベースに削除保護をかける、といった対策をとりました（本人の記事（新しいタブで開きます））。
2026年4月、PocketOS。 AI エージェント（Cursor 上で動く Claude Opus 4.6）が、本番のデータベースのボリュームを9秒で削除しました。使われたトークンは、ドメインの追加・削除のために作られたものでしたが、削除を含むあらゆる操作ができる権限になっていました。さらに、バックアップが同じボリュームに置かれていたため、一緒に消えました。データは後に復旧され、基盤を提供する Railway は削除の仕組みを見直しています。Railway の CEO は「認証して削除を呼べば、その要求に応える」と述べています（The Register（新しいタブで開きます））。
ツールも、会社の規模も違います。それでも、どれも同じ形をしています。AI に、本番を消せる権限があった。 そして、消す前に止める仕組みが無かったか、AI がそれを越えられました。
私たちの考え方: 守る方法を、指示ではなく仕組みにする
私たちはこう考えます。AI への指示は、守られるはずのものですが、守られなかったときの備えにはなりません。判断基準は、AI が間違っても、本番に届かない構造になっているかです。
人間の開発者が間違えることを前提に、本番を守る仕組みを作るのと同じ考え方です。AI も、間違いが起こる前提で、触れる範囲を狭くします。
私たちの経験: 分けていなかったから、試す場所がなかった
環境を分ける理由は、事故を防ぐことだけではありません。私たち自身、開発環境と本番環境を分けていなかったために、新しい機能を本番に入れる前に試せる場所がなく、困ったことがあります。
本番で直接試すわけにはいかない。かといって、試さずに入れるのも怖い。環境を分けておくことは、安心して機能を足し続けるための前提でもあります。
分け方: 4つの原則
- 環境を分ける。 開発用と本番用で、サーバーやデータベースを別々に用意する。開発用には、本番のデータをそのまま入れない（入れる場合は、個人情報を消すなどの加工をする）。
- 接続情報を分ける。 開発用と本番用で、キーやパスワードを別にする。AI エージェントが動く環境には、開発用の接続情報だけを置く。本番の接続情報は、AI が動く環境から読める場所に置かない。
- 権限を絞る。 本番のデータベースに接続するアカウントは、必要な操作だけを許可する。データの削除や構造の変更ができる強い権限は、日常のアプリには持たせない。
- 本番への反映は、人が確認する経路に限る。 本番を変更できるのは、人が内容を確認してから実行する手順（レビューしてから反映する流れなど）だけにする。削除など戻せない操作は、必ず人が承認する。
一般的には、上の4つに加えて、本番で何かを変更する前に、バックアップを取ることも欠かせません。バックアップは、公開前に確かめる4点のうち「データが消えたり止まったりしたら、戻せるか」にあたります。
確かめ方: 今日できる5つの問い
- AI エージェントが動いている環境から、本番のデータベースに接続できるか
- AI に渡している接続情報は、開発用か、本番用か
- 本番のデータを、AI が削除・変更できる権限があるか
- 本番の変更は、人の確認を通らずに反映されることがあるか
- 本番のデータが消えた場合、戻せるか（バックアップがあり、戻したことがあるか）
1つでも「はい」「分からない」があれば、環境の分け方を見直す対象です。
公開前に確かめる4点との関係
公開前に確かめる4点（秘密情報・権限・復旧・保守）の全体像は、AIで作ったアプリを本番化するにはにまとめています。環境を分けることは、このうち「復旧」（3点目）に直接つながります。万一消えたときの被害を小さくし、戻しやすくするためです。
wizgeek にできること
開発環境と本番環境の分け方、AI に渡す権限の範囲に不安があるときは、ご相談ください。試作の構成と機能を把握し、認証・データベース・インフラ・セキュリティ・監視のうち何が足りないかを整理して、構成案をお渡しします（本番化の診断：5万円〜、税別）。構成案をもとに、お客様側で実装していただくこともできます。本番化の作業は別途お見積りします。