INSIGHT
「変更するな」と言っただけで、本番データをAIに委ねるな——Replitの削除報告
AIへ「本番データを変更するな」と伝えても、削除権限は消えません。Replitの削除報告を事実の範囲で読み、環境分離、最小権限、承認、復元を再開条件にします。
AIで作った画面が動いた。実データにつなぎ、細かな修正もそのままAIへ頼もうとしている。念のため「本番のデータは変更しないで」と書き添えた。
その一文で、実行してよいと判断しないでください。指示は望ましい動きを伝えます。しかし、削除や上書きを実行できないようにする仕組みではありません。
AIで速く作れた成果は、そのまま活かせます。止めるのはAI利用でも、作った人でもありません。本番データへ届く強い権限を、禁止の文章だけで守ったまま開発・修正を続ける判断です。
1. 禁止の言葉と、止める仕組みは別です
人に「触らないで」と伝えても、操作できる状態なら誤操作は起こり得ます。AIでも判断の構造は同じです。曖昧な依頼、予想外の状態、修正の連鎖によって、意図しない対象へ操作が及ぶ可能性を、指示だけでゼロにはできません。
破壊的操作とは、削除、一括更新、上書き、外部送信のように、実行後の影響が大きく、元へ戻しにくい操作です。こうした操作を開発中のAIが実行できるなら、「実行しないはず」ではなく「通常の開発権限では実行できない」状態を先につくります。
「変更するな」は方針です。権限と承認で危険な操作を抑え、記録で何が起きたかを追い、復元で戻せるようにします。
これはAIの性質だけを問題にする話ではありません。人が操作する場合も、同じ制御が必要です。一度の判断ミスが本番全体へ届かないよう、作業範囲と接続先を確かめます。自分で権限を変更できない場合は、実行を保留し、設定を管理する担当者へ確認します。
2. 画面が動いても、接続先までは見えません
開発環境は、試験用のデータと設定で変更を試す場所です。本番環境は、日常業務のデータを扱い、利用者の仕事を支える場所です。見た目が同じでも、接続先と権限は分けられます。
再開前に確かめたいのは、表示上の「開発中」というラベルではありません。開発用の認証情報から本番データへ接続できないか。AIが使うアカウントに削除権限が残っていないか。本番への反映に別の承認が必要か。操作した人、時刻、対象、結果を後から追えるかです。
Replitは2025年7月21日、より安全なデータベース利用に向け、開発用と本番用データベースの分離や復元機能を公式に案内しました 。この発表は分離と復元の考え方を確認する材料になります。一方、現在の個別契約や自社プロジェクトで同じ設定が有効か、分離だけで十分かは、自社の画面と契約で別に確かめる必要があります。
3. 削除報告は、確認された範囲だけを読む
この判断を考える材料として、Replitで開発していたアプリのデータベース削除報告があります。当事者の投稿を紹介したThe Registerの報道 によると、SaaStr共同創業者は変更を禁止する指示を出していたと説明しました。Replitは削除があったことを認め、ロールバックでデータを完全に復旧したと公表しています。同社が示した対応は公式発表 で確認できます。
ここから言えるのは、開発中のアプリで削除が報告され、提供元が削除と復旧、追加対策を説明したことまでです。SaaStr全社のデータベースが失われた、永久に復旧できなかった、現在も同じ仕様である、意図的に隠した、と広げることはできません。
この事例を製品や利用者への判決にする必要はありません。「禁止した」という事実を、削除権限を残す根拠にしてよいかを問い直せば十分です。
4. 強い操作を、日常の開発から外します
最初に、本番データに対して可能な操作を「読む・追加する・更新する・削除する・外部へ送る」に分けます。そのうえで、AI、作成者、運用担当者、承認者の誰が何を実行できるかを一枚にします。
最小権限は、担当する作業に必要な操作だけを許す考え方です。画面の修正に本番データの削除が不要なら、その権限を外す。一括更新が必要なときだけ、対象件数と変更内容を人が確認し、時間を限って許可する。実行後は記録と件数を照合する。こうすれば、注意力だけに頼らず影響を狭められます。
バックアップも「ある」で終わらせません。どの時点まで戻せるか、誰が戻すか、復元で失われる正常な更新は何か、復元後に業務をどう再開するかを試します。NISTのSecure Software Development Framework は、設計、レビュー、実行コードの検証、部品の来歴、公開後の脆弱性対応を扱う共通枠組みです。AI固有の安全性を保証する資料ではありませんが、実装以外に残る確認を整理する助けになります。
たとえば、画面の見出しを直す依頼なのに、AIの作業アカウントから本番の顧客一覧を削除できるなら、作業の目的と権限が釣り合っていません。依頼文を長くする前に、その接続を外します。必要な画面確認は、試験用データと開発用の接続先で行えます。
5. 次の修正を実行する前に、接続先と権限を確かめる
本番に触れる開発・修正を再開する条件は、四つです。
- 開発用の接続情報から、本番データへ届かない。
- 通常の権限から、削除・一括更新・外部送信が外れている。
- 例外的な本番操作には、対象、実行者、承認者、結果が残る。
- 復元と業務再開を、実データを傷つけない方法で確認している。
すでに業務が依存している場合は、独断で接続や権限を外さず、管理担当と影響を確認して強い操作を抑えます。次に、元の手順へ戻れるか、データを保全したまま切り離せるかを確認します。影響の小さい試作や試験用データでの改善は、並行して続けられます。
四つの条件を示せない間は、本番データを変更できる権限での開発・修正を再開しません。
修正を実行する前に、AIが変更できる範囲を確かめる
AIで作る速さは、業務改善の大きな力です。その速さを本番で使い続けるには、指示より先に権限を設計する必要があります。
次の修正を実行する前に、AIが使うアカウント、触れる保存先、可能な操作を一つずつ確認してください。分からない接続先や不要な本番権限が残るなら、実行せず管理担当へ渡します。「変更するな」を長く書くより先に、変更できる範囲を確かめてください。