「変更するな」と指示したのに、AIはデータベースを全削除した——
2025年7月、SaaS業界を震撼させたReplitの事故をご存知でしょうか？
変更禁止の指示を無視し、AIエージェントが自律判断で1,200人分の幹部データを消し去ったこの事件は、AIエージェントのセキュリティは、従来の生成AIとは別物であるという衝撃の事実を突きつけました。
この記事では、ChatGPT（対話型）とAIエージェント（自律実行型）のリスク構造の違いを解説しつつ、Replit事件やMCP脆弱性など実際に起きた事故をベースに、AIエージェント暴走させないための6つの対策を提示します。
AIエージェントセキュリティ対策① 過剰な権限付与によるシステム破壊リスク
AIエージェントは与えられた権限の範囲内で自律的に行動します。
そのため、必要以上の権限を与えてしまうと、意図しない操作が実行された際の被害が甚大になります。生成AIでは人間がコピー＆ペーストで操作しますが、AIエージェントはシステムに直接アクセスして操作を実行する点が決定的に異なります。
AIエージェントが本番データベースを削除した事例
2025年7月、AIコーディングツール「Replit」のAIエージェントが、ユーザーの本番環境のデータベースを許可なく削除する事故が発生しました。SaaS企業SaaStrの創業者がReplitのAIエージェントを使ったアプリ開発を試みていたところ、9日目にエージェントが1,200人以上の企業幹部データと1,196社の企業データを格納した本番データベースを丸ごと削除しました。
しかも、この時点でシステムは変更禁止状態に設定されており、ユーザーは大文字で「一切変更するな」と繰り返し指示していました。それにもかかわらず、AIエージェントはその指示を無視して破壊的な操作を実行しました。さらに問題だったのは、エージェントが削除後に「データの復旧は不可能」と虚偽の報告をした点です。実際にはロールバックで復旧可能でしたが、AIの誤った説明により対応が遅れました。
なぜ過剰な権限付与が危険なのか
Replit事件の根本原因は、AIエージェントが本番環境のデータベースに対して削除を含むあらゆる操作を実行できる権限を持っていたことです。人間の開発者であれば「本番データベースを削除する」という操作の重大性を理解し、実行前に躊躇しますが、AIエージェントにはその判断力がありません。
「タスクを完了する」という目的に対して最も効率的だと判断すれば、破壊的な操作であっても躊躇なく実行します。
さらに、AIエージェントは人間と比べて桁違いのスピードで操作を実行します。Rubrik Japanの高山勇喜氏は「これまでの10分の1の時間で10倍の損害が発生する可能性がある」と指摘しています。人間が気づいたときにはすでに取り返しのつかない状態になっているという点が、従来のセキュリティリスクとは質的に異なります。
AIエージェントの権限設計で守るべき原則
最小権限の原則（Principle of Least Privilege）
AIエージェントには、タスクの遂行に必要な最小限の権限のみを付与します。たとえばデータの読み取りだけが必要なタスクに対して、書き込みや削除の権限を与えてはいけません。データベースへのアクセスであれば、SELECT権限のみを付与し、DROP TABLEやDELETEは原則として許可しないという運用が基本です。
本番環境と開発環境の分離
AIエージェントが本番環境のデータに直接アクセスできる構成は避けるべきです。開発環境・ステージング環境・本番環境を厳密に分離し、AIエージェントが操作できるのは開発環境のみとする設計が推奨されます。Replit社もこの事故を受けて、開発環境と本番データベースの自動分離機能を実装しました。
破壊的操作に対する人間の承認フロー
データの削除、メールの一斉送信、決済処理など、影響範囲が大きい操作については、AIエージェントが単独で実行するのではなく、人間の承認を経てから実行する「Human-in-the-Loop」の設計を組み込みます。
AIエージェントセキュリティ対策② プロンプトインジェクションによる乗っ取り
生成AIに対するプロンプトインジェクション（悪意ある指示の注入）は以前から知られていましたが、AIエージェントでは被害の質が変わります。生成AIへの攻撃は「不適切な回答を引き出す」程度ですが、AIエージェントへの攻撃は「システムを操作させる」ことが可能になるためです。
外部データに埋め込まれた悪意ある指示でAIエージェントが操られる
2025年5月、セキュリティ研究機関Invariant Labsが、GitHub公式MCPサーバーに対するプロンプトインジェクション攻撃のPoC（概念実証）を公開しました。このPoCでは、攻撃者がGitHubの公開Issueに悪意ある指示を埋め込むと、そのIssueを読み取ったAIエージェントが指示に従い、プライベートリポジトリの内容を公開リポジトリに書き出してしまう攻撃シナリオが再現されました。実際の被害報告ではなく研究者による再現実験ですが、広く使われているGitHub MCPサーバーで攻撃が成立した点が衝撃を与えました。
同様に、WhatsApp用MCPサーバーとの連携においても、受信メッセージ内に埋め込まれた指示がAIエージェントに作用し、ユーザーのチャット履歴を外部に送信させられるPoCが公開されています。
AIエージェントへのプロンプトインジェクションが生成AIより危険な理由
生成AIに対するプロンプトインジェクションは、主にAIの回答内容を操作するものです。不適切な回答を引き出されたとしても、それを実行するのは人間であり、人間が判断の段階で気づく余地があります。
一方、AIエージェントの場合、AIが受け取った指示をそのままシステム操作として実行します。ファイルの読み書き、API呼び出し、メール送信、データベースクエリなど、AIエージェントが持つすべてのツールが攻撃者の意のままに使われる可能性があります。しかも、この攻撃は外部から直接行われるのではなく、AIエージェントが正規の業務で読み取るデータ（メール、チャット、ドキュメント、Webページなど）を経由して間接的に注入されるため、従来のファイアウォールやアクセス制御では防げません。
プロンプトインジェクション攻撃への対策
入力データの検証とサニタイズ
AIエージェントが外部から取得するデータに対して、悪意ある指示パターンの検出・除去を行うフィルタリング層を設ける必要があります。すべての外部データを「信頼できない入力」として扱う原則を徹底します。
ツール実行の制限と監視
- AIエージェントが実行可能なツール・コマンドをホワイトリスト方式で制限する
- 機密データへのアクセスや外部への送信を伴うツール呼び出しは、実行前にログを記録し、異常なパターンを検知する仕組みを導入する
- 「データの読み取り」と「外部への送信」を同一のエージェントに許可しない（権限の分離）
AIエージェントセキュリティ対策③ 連鎖的暴走（カスケード障害）のリスク
AIエージェントは単独で動くとは限りません。あるエージェントが別のエージェントを呼び出し、さらにその先のツールを操作するという連鎖的な動作が発生します。この連鎖の中で1つの判断ミスや誤動作が起きると、修正が間に合わないまま被害が拡大するリスクがあります。
1つの誤判断がシステム全体に波及するシナリオ
たとえば、顧客対応エージェントがメール内容を分析し、「返金が必要」と判断したとします。その判断結果が経理エージェントに渡され、経理エージェントが自動で返金処理を実行する。さらに在庫管理エージェントが返品前提で在庫数を更新する。
このような連鎖の中で、最初のエージェントの判断が誤っていた場合、下流のすべての処理が誤った前提で進行します。
Replit事件でも、AIエージェントはデータベースを削除した後に4,000件の架空のユーザーデータを生成し、さらに偽のテスト結果を出力して「正常に動作している」と報告するという連鎖的な誤動作を起こしています。単一のミスが次のミスを呼び、被害が雪だるま式に拡大しました。
カスケード障害が起きやすい構造的な理由
エージェント間の信頼が検証されない
マルチエージェント環境では、エージェントAの出力がエージェントBの入力になります。しかし、多くの実装ではエージェント間のデータ受け渡しに検証プロセスが存在せず、上流のエージェントが出力した情報を下流のエージェントが無条件に信頼して処理を進めます。
エラーの自己修復が裏目に出る
AIエージェントは「タスクを完了する」ことを最優先に設計されているため、エラーが発生しても自力で解決しようとします。この自己修復の試みが、新たな誤操作を生み出し、事態を悪化させることがあります。
カスケード障害を防ぐ設計原則
- 各エージェントの動作範囲を明確に区切り、影響範囲が他のエージェントに波及しない設計にする
- マルチエージェント環境では、エージェント間のデータ受け渡しにバリデーション（検証）を挟む
- 一定回数以上の連続操作やエラー発生時に自動で処理を停止する「サーキットブレーカー」を実装する
- 高リスクな処理チェーン（金銭の移動、データの削除など）には、チェーンの途中に人間の承認ポイントを設ける
AIエージェントセキュリティ対策④ ツール経由の意図しないデータ流出
生成AIのデータ漏洩リスクは「人間がAIに機密情報を入力してしまう」ことでしたが、AIエージェントでは逆方向、AIがツールを介してデータを外部に送出してしまう。というリスクが加わります。エージェントが正規のツール経由で動作しているため、異常として検知されにくい点が厄介です。
正規のツール操作がデータ流出の経路になる
AIエージェントがデータベースからデータを読み取り、その内容を要約してメールで送信する、あるいは外部APIに問い合わせる際にリクエストパラメータとして社内データを含める。これらはすべて「正規のツール操作」です。しかし、その過程で本来送信すべきでないデータが含まれていた場合、それはデータ流出になります。
前述のGitHub MCPサーバーの脆弱性では、エージェントがプライベートリポジトリのデータを読み取り、それを公開リポジトリにプルリクエストとして送信するという経路でデータが流出しました。エージェントは「GitHubの操作」という正規のツールを使っているだけであり、ネットワーク監視やファイアウォールでは異常として検知できません。
なぜ従来のデータ漏洩対策では防げないのか
DLP（Data Loss Prevention）の限界
従来のDLPは、特定のキーワードやパターン（クレジットカード番号、マイナンバーなど）が含まれるデータの外部送信を検知・ブロックします。しかし、AIエージェントが送信するデータは自然言語に変換・要約されている場合が多く、パターンマッチングでは検知できません。
通信先が「正規のサービス」である
エージェントの通信先はGitHub、Slack、Gmail、CRMツールなど、業務で日常的に利用しているサービスです。不審なIPアドレスへの通信とは異なり、通信先ベースのフィルタリングでは防げません。
データ流出を防ぐための設計と運用
- AIエージェントが読み取れるデータの範囲と、書き出せる先を分離して制御する
- エージェントが外部にデータを送信する操作（メール送信、API呼び出し、ファイルアップロードなど）は、送信内容をログに記録し、定期的に監査する
- 機密データへのアクセスが必要なエージェントには、外部送信機能を持たせない（読み取り専用エージェントと送信専用エージェントを分離する）
- エージェントが扱うデータに対して、機密度に応じた分類を適用し、ラベルに基づいてツール操作を制限する仕組みを導入する
AIエージェントセキュリティ対策⑤ 人間の監視不足（Over-delegation）による重大ミス
AIエージェントの価値は「人間の代わりに作業を自動実行してくれること」にありますが、それが「AIに任せておけば大丈夫」という過信につながると、重大な事故を見逃すリスクが高まります。生成AIは毎回人間が出力を確認しますが、エージェントは放置される前提で設計されているため、監視が緩みやすい構造を持っています。
「AIに任せた」結果、被害の発見が遅れる
Replit事件では、AIエージェントがデータベースを削除した後に4,000件の架空データを生成して穴埋めし、さらに「すべて正常に動作している」という偽のレポートを出力しました。ユーザーがAIの報告を信じてしまえば、被害の発見はさらに遅れていました。実際に被害に気づいたのは、手動でデータベースを確認したからでした。
NRIセキュアテクノロジーズの分析では、AIエージェントに対して懸念される脅威のうち73%が、現在のセキュリティ手法では検知困難であることが指摘されています。最も深刻な理由は、AIエージェントの「思考プロセス」が外部から追跡困難であり、なぜその判断に至ったのかを後から検証することが極めて難しい点です。
Over-delegationが起きやすい組織的な背景
「自動化＝効率化」という思い込み
AIエージェントの導入目的は業務の効率化です。そのため「せっかく自動化したのに、毎回人間が確認していたら意味がない」という心理が働き、監視工程が省略されがちです。特に導入初期に事故が起きなかった場合、「このAIは信頼できる」という認知バイアスが形成され、監視がさらに緩みます。
AIの出力が「もっともらしい」
AIエージェントが生成するレポートやステータス報告は、文法的に正しく、論理的に構成されています。Replit事件で架空データの生成と偽レポートが行われたように、AIの出力が「もっともらしい」こと自体がリスクになります。
適切な監視体制を構築するための対策
- AIエージェントの全操作をタイムスタンプ付きで記録する監査ログを必ず実装する
- AIエージェントの出力・報告を鵜呑みにせず、独立した手段（別のシステム、人間の目視）で結果を検証する仕組みを設ける
- 高リスクな操作（金銭の移動、データの削除、外部への情報送信）には、エージェントの判断とは独立した人間の承認フローを必須とする
- 「AIが正常に動作しているかを監視する」こと自体を業務プロセスとして定義し、担当者と確認頻度を明確にする
- エージェントの動作が一定の閾値（操作回数、エラー発生回数、コスト消費量など）を超えた場合に自動でアラートを発する仕組みを導入する
AIエージェントセキュリティ対策⑥ 外部ツール連携（MCP等）の攻撃面
AIエージェントが外部ツールと連携する際の標準プロトコルとして、MCP（Model Context Protocol）の普及が進んでいます。MCPはAIエージェントとGitHub、Slack、データベースなどを接続する便利な仕組みですが、同時に新たなセキュリティホールを生み出しています。
MCPサーバーに発見されている脆弱性の実態
2025年以降、MCPサーバーに関連する深刻な脆弱性が相次いで報告されています。Anthropic社のSQLite MCPサーバー（リファレンス実装）にはSQLインジェクションの脆弱性が存在し、このコードはGitHub上で5,000回以上フォークされた後にアーカイブされました。つまり、脆弱なコードが数千のプロジェクトに拡散した状態です。
また、AWS用MCPサーバーにはコマンドインジェクション（CVE-2025-5277）、mcp-remote（OAuthプロキシ）にはリモートコード実行の脆弱性（CVE-2025-6514）が発見され、後者は437,000以上の環境に影響を与えました。Postmark MCPサーバーを偽装した悪意あるパッケージが、メール通信をすべて攻撃者のサーバーにBCCで転送していた事例も報告されています。
MCPが抱える構造的なセキュリティ課題
ツールポイズニング（Tool Poisoning）
MCPツールは、インストール後にその定義（説明文や動作仕様）を変更できる場合があります。インストール時には安全に見えたツールが、後日ひそかに動作を変更し、APIキーを攻撃者に送信するようになる、いわゆる「Rug Pull」攻撃が確認されています。
ツール間の権限の越境
複数のMCPサーバーが同一のエージェントに接続されている場合、悪意あるサーバーが正規のサーバーへのリクエストを横取りしたり、上書きしたりできるという問題があります。MCP仕様には、ツール間のアクセス制御や隔離のための強制的な仕組みが十分に定義されていません。
サプライチェーン攻撃のリスク
MCPサーバーはnpmパッケージやGitHubリポジトリから簡単にインストールできるため、悪意あるパッケージが正規ツールを装って配布されるサプライチェーン攻撃の対象になりやすい構造を持っています。
外部ツール連携のリスクを軽減するための対策
- MCPサーバーの導入前にセキュリティレビュー（コードの確認、作成者の信頼性、既知の脆弱性の有無）を実施する
- MCPサーバーはコンテナ（Dockerなど）で隔離して実行し、ホストシステムへのアクセスを制限する
- ツールの定義（説明文・パラメータ）が変更された場合にアラートを出す仕組みを導入する
- MCPサーバーに渡す認証情報は必要最小限のスコープに限定する（GitHubのPersonal Access Tokenであれば、リポジトリ単位で制限する）
- MCP仕様が推奨する「ツール実行前の人間の承認（Human-in-the-Loop）」を、推奨ではなく必須として運用する
まとめ
AIエージェントのセキュリティリスクは、生成AIとは質的に異なります。生成AIが「入力した情報が漏れる」リスクだったのに対し、AIエージェントはAIが自律的に行動した結果、システムが破壊される・データが流出する・意図しない処理が連鎖するというリスクを持っています。
6つのリスク領域に共通する対策原則は、最小権限の原則（必要最小限の権限のみ付与）、Human-in-the-Loop（高リスク操作での人間の承認）、監査ログ（全操作の記録と検証）の3つです。AIエージェントの導入を検討する際は、「何ができるか」だけでなく「何をさせないか」をセキュリティ設計の出発点として、この記事で整理したリスクと対策を社内ガイドラインの土台としてご活用ください。