AIエージェントがDBを消した時、何が足りなかったのか## ――Replit Agentの事例から考える「権限・承認・復旧」の設計

AIエージェントを業務で使う話になると、「回答が正しいか」「誤情報を出さないか」に注目が集まりがちです。

もちろん、それは大事です。

ただ、AIが外部のツールを使い、データを読み、コードを書き、設定を変えられるようになると、別の問いが前に出てきます。

Replitは、ブラウザ上でアプリのコードを書き、実行し、公開までできるクラウド開発プラットフォームです。近年は、作りたいアプリを自然言語で伝えると、コード作成や修正、デバッグを進める「Replit Agent」も提供しています。

つまり今回の事例は、文章を返すだけのチャットAIではなく、アプリやデータベースに手を加えられるAIを使った開発環境で起きた話です。

2025年、Replit Agentを使っていたSaaStr共同創業者のJason Lemkin氏のアプリで、データベース上のデータが削除される問題が起きました。

この件は、AIが単純に「賢くなかった」という話だけではないと思います。

Replit自身の説明を読むと、そこにはAIエージェントを運用する時に避けて通れない、権限・承認・復旧という3つの設計課題が見えてきます。

この記事ではReplitの事例を材料に、「AIに仕事を任せる」とは実際には何を任せることなのかを考えてみます。

Replitの事例で、公式に確認できること

まず、事実と見解を分けておきます。

Replitは2025年7月の公式ブログで、Replit AgentがJason Lemkin氏のアプリのデータベースからデータを削除した事例に言及しています。

Replitの説明によれば、当時は次の状況でした。

• Agentが操作したアプリのデータベースから、データが削除された

• Replitにはチェックポイントとロールバックの機能があり、最終的にデータベースは完全に復元された

• 結果として、データ損失はなかった

• ただし当時は、開発中の変更が本番アプリケーションにも影響し得る構成だった

• Agentはロールバック機能を認識しておらず、問題を解決するための案内として役に立たなかった

Replitはこの事例を受け、開発用と本番用のデータベースをデフォルトで分離し、開発中にはAgentが本番データベースを変更できない仕組みを導入した、と説明しています。

ここで重要なのは、「最終的には復元できたから安全だった」とは言い切れないことです。

削除からロールバックまでの間、本番デプロイに影響が出た可能性がありました。復元の機能は存在していても、Agentのチャットは復旧に役立たず、利用者がロールバック機能を使って復元するまでに時間を要しました。

僕がこの事例で怖いと感じるのは、AIがデータを削除したことだけではありません。

「戻す手段がある」という設計と、「有事に本当に戻せる」という運用の間に、意外に大きな距離があることです。

これはAI特有の問題というより、AIによって既存の運用上の弱点が急に表面化する問題なのだと思います。

ここから有料