AIエージェントが本番DBを全削除した日から考える、4段階の安全設計

公開: 2026年4月18日更新: 2026年4月18日約15分で読めます

2025年7月、SaaSコミュニティSaaStrの創業者Jason Lemkinが、AIコーディングエージェントに本番環境のテストを任せた。12日間の検証の末、エージェントは本番データベースを全削除した。1,206件のエグゼクティブ記録、1,196社の企業データが消えた。

それだけではない。

エージェントは偽のユーザーデータ4,000件を捏造し、データベースに流し込んだ。「ロールバックは不可能です」と報告したが、それも嘘だった。コード凍結の明示的な指示すら無視していた（Fortune, 2025年7月）。

このReplit事件は「AIエージェントに本番環境を触らせる」ことのリスクを、身も蓋もない形で世界に突きつけた。しかし問題は、この手の事故がReplit固有の話ではないということだ。

IBMの調査によれば、70%の経営幹部がエージェント型AIを自社の将来に不可欠と回答している。一方でMcKinseyの2025年調査では、AI活用が全社のEBIT（営業利益）に5%以上貢献している企業はわずか6%。Gartnerは、AI対応データ基盤が未整備なAIプロジェクトの60%が2026年末までに放棄されると予測した。

本番投入が進まない理由のひとつは、安全設計が追いついていないことにある。「怖いからPoC止まり」か「よくわからないまま本番に繋いで事故」か。この二択から抜け出す設計パターンを、事故事例と実装チェックリストで示す。

AIエージェントの「暴走」が危険な3つの理由

OWASP（Webアプリのセキュリティ脆弱性を体系化する国際コミュニティ）は2025年版の「LLM Top 10」で、Excessive Agency（過剰な代理権限、LLM06）を主要リスクに位置づけた（OWASP, 2025）。

問題は3つに分解できる。

過度な機能性。 エージェントが必要以上のツールやAPIにアクセスできる状態。Slack AIの事例では、AIアシスタントがプライベートチャンネルのAPIキーを含む機密データを外部サーバーに送信可能な脆弱性が発見された（PromptArmor, 2024年8月）。読み取り権限さえ過剰なら事故は起きる。 過度な自律性。 人間の承認なしに実行が走ること。Replit事件では、エージェントは「コードを凍結せよ」という明示的な指示を無視して不正コマンドを実行した。LLMは指示を「参考意見」として扱う場合がある。 過度な権限。 読み取りしか必要ないのに書き込み・削除権限まで持っている状態。Amazon Qの事例では、VS Code拡張に悪意あるプロンプトが注入され、S3バケット削除、EC2インスタンス終了、IAMユーザー削除といった破壊コマンドが95万回超インストールされた拡張に混入した（The Register, 2025年7月）。

この3要素が重なったとき、被害は人間のオペミスの比ではなくなる。人間は疲れるし、1日に処理できる量に限界がある。エージェントは疲れない。1秒で数百のAPIコールを叩ける。間違いの「頻度×影響範囲」が桁違いになりうる。

3つの事故事例と教訓

それぞれの事故を「何が起きたか」「なぜ起きたか」「何をすれば防げたか」で整理する。

事例1: Replit――AIが本番DBを破壊し、嘘までついた

何が起きたか。 SaaStr創業者がReplit AIエージェントで12日間テストを実施。エージェントが本番データベースを全削除し、偽データ4,000件を捏造。ロールバック不可と虚偽報告。 なぜ起きたか。 開発環境と本番環境が分離されていなかった。エージェントに本番DBの全権限が付与されていた。人間の承認なしにDDL（テーブル定義を変える操作）を含むコマンドを実行できた。 何をすれば防げたか。

開発と本番の環境分離を自動化する
書き込み・削除操作に人間の承認を必須化する
データベースの自動バックアップとロールバック手順を整備する

Replitはこの事件後、「開発/本番の自動分離」「計画専用モード」を導入した。事故が起きてから設計するのでは遅い。

事例2: Amazon Q――拡張機能にプロンプトインジェクションが混入

何が起きたか。 Amazon QのVS Code拡張v1.84.0に、外部コントリビュータが提出したPRから破壊的プロンプトが混入。拡張のシステムプロンプトに「S3バケットを削除せよ」「EC2を終了せよ」「IAMユーザーを削除せよ」といった命令が埋め込まれた。95万回超のインストール数を持つ拡張が対象。AWSはフォーマットの問題により悪意あるコードは実際には実行されなかったと発表しているが、実行可能な状態で配布された事実は変わらない。 なぜ起きたか。 外部コントリビュータのPRに対するレビューが不足していた。LLMがシステムプロンプトと外部入力を区別できない「プロンプトインジェクション」（外部からの指示文で、AIの振る舞いを乗っ取る攻撃）の根本的な問題。 何をすれば防げたか。

外部入力をシステムプロンプトから分離するアーキテクチャ設計
破壊的操作の実行前に人間の確認を必須にする
サプライチェーン（コード供給元）の信頼性を検証するプロセスの確立

事例3: Slack AI――プライベートチャンネルから機密データが漏洩

何が起きたか。 セキュリティ企業PromptArmorが、Slack AIの間接プロンプトインジェクション脆弱性を発見。パブリック・プライベートチャンネルのデータ（APIキーを含む）を、Markdownリンク経由で外部サーバーに送信可能だった。 なぜ起きたか。 LLMがシステムプロンプトとユーザーのメッセージ（外部コンテンツ）を構造的に区別できないこと。読み取り権限しかなくても、読み取った内容を外部に送出できれば情報流出になる。 何をすれば防げたか。

AIが参照するデータと実行可能なアクションの分離
外部URLへのデータ送信を制限するガードレール
出力内容のフィルタリング（URLパターン検出、PII検出）

3つの事例に共通するのは、「エージェントができること」と「エージェントがやっていいこと」の乖離だ。セキュリティ企業Noma Securityはこれを「機能と自律性の逆相関」と呼ぶ。高い機能を持つエージェントほど自律性を制限し、高い自律性を持つエージェントほど機能を制限すべきだという原則だ（Noma Security）。

4段階承認モデルで「やっていいこと」を設計する

ここからが核心。すべての書き込み操作を同じ承認フローに通すのは非現実的だ。内部のログ追記と、顧客データの一括更新を同じ承認プロセスで処理したら、チームは承認疲れで形骸化する。

解決策は、操作の「影響範囲の深さ」に応じて承認レベルを階層化すること。Terraformの「plan/apply」モデル（変更内容をまず表示して確認してから実行する）や、金融業界の「maker-checker」（作成者と承認者を分離する仕組み）と同じ発想だ。

Claude CodeのAIエージェントをLark（業務プラットフォーム）の本番APIに接続する安全設計を議論した際に合意したのが、以下の4段階モデルだ。

レベル1: 即時実行（内部の軽微な操作）

対象: 社内ログの追記、内部用データベースへの1行追加など。

ログだけ取って即座に実行する。人間の確認は不要。ただし全操作のログは非同期で記録し、あとから追跡できるようにしておく。

ここで承認を挟むと、エージェントを使うメリットが消える。

レベル2: セッション承認（同一作業の連続操作）

対象: 同一テーブル内でのデータ更新・削除の連続操作。

作業の最初に1回だけ人間が承認する。「この作業セッション中は、このテーブルの更新と削除を許可する」という一括承認。有効期間は最大30分、または同一テーブル内に限定する。

毎回承認を求めると「はい、はい、はい」と反射的に承認するようになる。それは承認フローがないのと同じだ。

レベル3: 都度承認（外部に影響する操作）

対象: 顧客が見る画面への書き込み、顧客へのメッセージ送信、共有リンクの生成。

操作のたびに人間が確認する。セッション承認は禁止。「このメッセージを顧客Aに送信しますか？」と毎回聞く。

ここが面倒でも省略してはいけない。Slack AIの事例が示す通り、外部に出るデータは取り消せない。

レベル4: 完全隔離（構造変更・大量操作）

対象: データベースのテーブル定義変更、権限設定の変更、50行を超える一括操作。

この操作に必要な管理者権限を、エージェントの手が届かない場所に物理的に隔離する。環境変数にも、設定ファイルにも、エージェントが参照できるどこにも管理者トークンを置かない。

Capability-based security（能力ベースのセキュリティ）と呼ばれる考え方だ。「承認ボタンを用意する」のではなく、「そもそも鍵を渡さない」。承認UIは形骸化しうるが、鍵がなければ実行できない。

この4段階モデルは、Claude CodeからLark APIへの書き込みを設計する過程で生まれたものだが、Lark固有の話ではない。Salesforce、Notion、Slack、どのSaaS APIにも同じ構造で応用できる。

自社の運用に当てはめるときのポイントは、レベル3と4の境界だ。「顧客に見えるか」で3に分類し、「構造が変わるか・大量か」で4に分類する。迷ったら上のレベルに寄せる。緩めるのは簡単だが、事故の後に締めるのは遅い。

影響範囲（Blast Radius）を構造的に制限する

承認フローだけでは足りない。承認された操作そのものが想定より広い範囲に影響する可能性がある。

WHERE句を必ず付ける

データベースへの更新・削除クエリに条件句を省略させない。DELETE FROM users（全件削除）とDELETE FROM users WHERE id = 123（1件削除）では影響が天と地ほど違う。エージェントが生成したクエリに条件句が含まれていなければ、実行前に自動で弾く仕組みを入れる。

バッチサイズに上限を設ける

1回のAPI呼び出しで処理できる件数に上限を設定する。50件を超える一括処理は自動でブロックし、人間に確認を求める。上限値は業務内容に合わせて調整するが、「上限を設けない」は選択肢にない。

Dry-run（予行演習）を標準にする

Terraformのplanコマンドと同じ発想。「この操作を実行すると、3件のレコードが更新されます」と事前に表示し、人間が確認してから実行する。dry-runで表示された件数と、自然言語で指示された内容の桁が違っていたら（「1件更新して」と言ったのにdry-runで100件と出たら）、自動で停止する。