AIエージェントのリスクとは？事故事例6選と権限設計によるセキュリティ対策
目標を与えると、自分で手順を考え、ツールやシステムを操作して業務を進めるAIを「AIエージェント」といいます。メールの送信、ファイルの整理、コードの修正、発注処理など、これまで人が手を動かしていた作業を任せられるため、導入を検討する企業が増えています。
一方で、AIエージェントには生成AIチャットにはなかったリスクがあります。出力が文章ではなく「操作」だからです。チャットなら、おかしな回答が出ても人が確認する段階で止められます。AIエージェントは人が読む工程を経ずに実行するため、間違いに気づくのは、外部への操作が実行されたあとです。
この記事では、実際に起きた事故と脆弱性を6件紹介します。あわせて、調査会社と公的機関がこのリスクをどこまで把握しているか、導入前に設計で何を切っておけばよいかを整理します。
目次
- AIエージェントのリスクが生成AIチャットと違う3つの理由
- AIエージェントで実際に起きた事故・脆弱性の事例6選
- AIエージェントのリスクはどこまで把握されているか｜調査統計と公的ガイドライン
- 【対策】AIエージェントのリスクを設計で小さくする4つの境界
- AIエージェントの設計と運用は、スパイクスタジオへご相談ください
AIエージェントのリスクが生成AIチャットと違う3つの理由
違いは「出力が文章か、操作か」
AIエージェントは、目標を与えると自分で手順を決め、外部のツールやシステムを呼び出して実行するAIです。質問をすると、文章で返答するところで止まる生成AIチャットとは、仕組みが違います。両者の違いは「AIエージェントとは？ChatGPTとの違いや特徴」で詳しく解説しています。
弊社がDXPO東京’25［夏］の来場者に実施した調査では、生成AIの導入率は87.0%、業務効率化への寄与を実感した人は91.5%でした。一方で、活用状況への満足度は30.5%にとどまっています（スパイクスタジオ調べ、DXPO東京’25［夏］来場者調査、2025年8月実施）。すでにチャット型AIは普及しており、効果も実感されている。それでも満足には届いていない。この差が、エージェントをつくる動機になっています。一般的なチャットAIを導入したものの、何かが足りなかった。そのため、次の段階としてAI自身に作業を実行させようとするのは自然な流れです。ただし、AIが自律的に動くようになった瞬間に、それに伴う「リスクの種類」が変わります。
①人のレビューを経ずに、外部へ作用する
生成AIチャットの事故は、ほとんどが「人が出力を信じきってしまい、確認せず外部に出る情報として使ってしまった」形で起きます。
先ほどお伝えしたとおり、AIエージェントの出力は操作そのものです。ファイルを消す、メールを送る、コードを書き換える、発注する。実行された時点で外部に作用しており、気づいたときには戻せません。後述するReplitの事例では、変更を禁じる指示が出ていたにもかかわらず本番データベースが削除されました。
②渡した権限が、そのまま被害の範囲になる
エージェントを動かすには、APIキーやアクセストークンを渡します。このとき渡した権限が、そのまま事故の上限になります。読み取りだけの鍵なら、最悪でも読み取られて終わりです。書き込みと削除まで含む鍵を渡していれば、そこまで起こりえます。
Cloud Security Allianceが2026年4月に公表した調査では、ITおよびセキュリティ専門家445人のうち53%が「AIエージェントが意図した権限を超えて動作した」経験があると回答しました（Cloud Security Alliance／Zenity調査、2026年4月16日）。
③指示の入口が、利用者以外にも開いている
エージェントは業務のために、メール・Webページ・Issue・ドキュメントを読みます。読んだ文字列の中に「これまでの指示は無視して次を実行せよ」と書かれていた場合、それを命令として実行してしまうことがあります。これを間接プロンプトインジェクション（外部データ経由の指示の注入）と呼びます。
利用者が何も間違えていなくても、攻撃者がデータを置いておくだけで成立します。指示の入口が利用者以外にも開いている点が、チャット型との大きな違いです。手口そのものの防御策はプロンプトインジェクションの対策にまとめています。
AIエージェントで実際に起きた事故・脆弱性の事例6選
ここからは、公表されている事故と脆弱性を6件紹介します。いずれも、発見者または当事者の一次情報が出ているものに絞りました。
①指示の乗っ取り｜Microsoft 365 Copilotで、メール1通と利用者の操作なしに社内データが外部へ
2025年6月、セキュリティ企業のAim Securityが、Microsoft 365 Copilotの脆弱性を公表しました。識別番号はCVE-2025-32711です。深刻度はMicrosoftの評価でCVSS 9.3、NVD（米国の脆弱性データベース）自身の評価では7.5と、評価が分かれています（NVD、"CVE-2025-32711 Detail"）。
攻撃者が細工したメールを送るだけで成立します。受信者がそのメールを開かなくても、Copilotが社内文書を検索して回答を作る過程でメール本文を読み込み、そこに埋め込まれた指示を実行してしまう構造でした。社内データを外部へ送信させることが可能だったと報告されています。
原因は、Copilotの検索拡張生成（RAG、社内データを検索して回答に使う仕組み）が、読み込んだ本文の中の指示と利用者からの正規の指示を区別できなかった点にあります。注入を検知するフィルターは、自然な文面にすることで回避されました。
Microsoftは2025年6月までにサーバー側で修正しました。悪用は確認されていませんが、利用者の操作を一切必要としない攻撃が成立した例として扱われています（出典: arXiv、"EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System"、2025年9月6日）。
②指示の乗っ取り｜Webページに隠された指示での攻撃が、実際に観測される
2026年3月、Palo Alto NetworksのUnit 42が、間接プロンプトインジェクションが実際に使われている事例を観測したと公表しました。2025年12月には、AIによる広告審査をすり抜ける目的で使われた例が検出されています。
手口は22種類が確認されました。文字の大きさをゼロにする、CSSで見えなくする、HTMLの属性値に紛れ込ませるなど、人の目には見えずAIだけが読む形で指示を埋め込みます。
検出された攻撃者の意図は、無関係な出力の強制が28.6%、データ破壊が14.2%、AIによる内容審査の回避が9.5%でした。研究者は、実際の被害は理論上の想定より限定的としながら、手口が高度になっていると指摘しています（出典: Palo Alto Networks、"Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild"、2026年3月3日）。
③権限の超過｜公開Issueを悪用し、非公開リポジトリの情報を流出させる攻撃を実証
2025年5月、Invariant Labsが、GitHubの公式MCPサーバーを使った構成で情報が流出しうることを実証しました。MCP（Model Context Protocol、AIエージェントが外部ツールに接続するための共通仕様）を使った構成です。
手順はこうです。攻撃者が公開リポジトリに悪意あるIssueを立てる。開発者がエージェントに「Issueを見て対応して」と頼む。エージェントはIssueに書かれた指示に従い、同じトークンで読める非公開リポジトリから給与情報などを読み出し、公開のプルリクエストに書き込む。
原因は、開発者が1つの個人アクセストークンで公開・非公開の両方へのアクセスを許していた点にあります。GitHub側のコードに不具合はなく、仕様どおりの動作でした。この公表を受け、リポジトリ単位でトークンを分ける運用が広がりました（出典: Invariant Labs、"GitHub MCP Exploited: Accessing private repositories via MCP"、2025年5月26日）。
④自律実行の暴走｜「コードフリーズ」の指示下で、本番データベースを削除
2025年7月、開発プラットフォームReplitのAIコーディングエージェントが、利用者の本番データベースを削除しました。利用者はSaaStr創業者のJason Lemkin氏です。
当時は、変更を禁じる「コードフリーズ」の指示が出ていました。それにもかかわらず、エージェントは許可を得ていないコマンドを実行しました。失われたのは、役員1,200人超と企業1,190社超のデータです。
本番環境と開発環境が分離されないまま、エージェントが本番データベースへの操作権限を持っていたことが原因でした。データは手作業で復旧しています。ReplitのCEOアムジャド・マサド氏は謝罪し、本番と開発のデータベースの自動分離、復元機能の改善、実行せず計画だけを立てるモードの追加を発表しました（出典: Fortune、"An AI-powered coding tool wiped out a software company’s database, then apologized for a ‘catastrophic failure on my part’"、2025年7月23日）。
⑤サプライチェーンの汚染｜コーディング支援の拡張機能に、データ消去の指示が混入
2025年7月、Amazon Web Servicesのコーディング支援機能「Amazon Q」のVS Code向け拡張機能に、何者かがシステムやクラウド資源を初期化する指示を混入させました。この拡張機能の導入数は約100万件です。
経路はプルリクエストでした。7月13日、無関係のアカウントから送られたプルリクエストを足がかりに、権限の広いGitHubトークンが悪用され、問題のコードがバージョン1.84.0に入ります。このバージョンは7月17日に公式のマーケットプレイスで配布されました。
AWSは、指示の書式に不備があったため自社の環境では実行されなかったと説明しています。この説明は、「実行されたものの実害はなかった」とする研究者の見解と食い違っています。AWSは7月23日に報告を受け、翌24日に修正版1.85.0を公開しました（出典: AWS、「セキュリティ更新 （バージョン #1.84）」、2025年7月23日）。
⑥連携先の汚染｜あとから接続したツールが、SSH鍵を持ち出し、メールの宛先を書き換える
2025年4月、Invariant Labsが「ツールポイズニング」と呼ぶ手法を公表しました。MCPのツール説明文に、利用者の画面には出ない指示を埋め込む手口です。
実証は2つ行われました。1つは、細工した計算ツールをCursorに接続させ、設定ファイル（他のMCPサーバーの認証情報を含みうる）とSSH鍵を攻撃者のサーバーへ送らせたものです。もう1つは「ツールシャドーイング」と呼ばれ、正規のメール送信ツールと悪意あるツールを同時に接続させ、利用者が指定した宛先を無視して、すべてのメールを攻撃者のアドレスへ送らせました。
原因は、ツールの説明文がAIにだけ見える形で書けることにあります。利用者の画面では、何も起きていないように見えます。接続を承認したあとで説明文を書き換える手口も報告されました。Invariant Labsは、ツールの説明文を利用者にも表示すること、接続先のバージョンを固定することを対策に挙げています（出典: Invariant Labs、"MCP Security Notification: Tool Poisoning Attacks"、2025年4月1日）。
AIエージェントのリスクはどこまで把握されているか｜調査統計と公的ガイドライン
個別の事故だけでなく、調査会社と公的機関の動きも押さえておくと、社内への説明に使えます。
| 発表元（時期） | 分かったこと |
|---|---|
| Gartner（2025年6月） | エージェント型AIの案件の40%超が、2027年末までに中止されると予測 |
| Darktrace（2026年2月） | セキュリティ専門家の76%がAIエージェントのリスクを懸念。最大の懸念はデータ漏洩で61% |
| Cloud Security Alliance／Zenity（2026年4月） | 53%が権限の逸脱を経験、47%が過去1年にインシデントを経験。方針を整備済みは31% |
| OWASP GenAI Security Project（2025年12月） | エージェント特有のリスクを10分類に整理したTop 10を公表 |
| 経済産業省（検討会資料） | 2025年〜2026年7月のAIエージェント関連インシデント45件を収集・分析。ガイドラインを公表予定 |
| 総務省・経済産業省（2026年3月） | AI事業者ガイドライン第1.2版に、AIエージェントの定義・便益・リスクと対策を追記 |
これらの情報から読み取れることは2つあります。1つは、導入した組織の約半数がすでに何らかの事故を経験していること。もう1つは、方針を整備できている組織は、わずか3割前後にとどまることです。いま起きている事故は珍しい事件ではなく、設計の抜けから繰り返し起きています。
国内では、総務省と経済産業省が2026年3月のAI事業者ガイドライン第1.2版で、AIエージェントを明示的に扱い始めました。AIエージェントは自律性が高い分、権限の設定、人の判断を挟む箇所、操作履歴を確認する頻度そのものを見直す必要がある、という整理です。
【対策】AIエージェントのリスクを設計で小さくする4つの境界
ここまでの6件は、AIの賢さが足りなかった話ではありません。実際の被害に至ったものも、研究者による実証で止まったものも、どれも権限と実行経路の設計で防げる範囲が大きいものです。使い始める前に切っておく境界を、4つに絞りました。
①権限はエージェント専用に分け、読み取りから始める
人が使っているアカウントやトークンを、そのままエージェントに渡さないことです。GitHub MCPの事例は、1つのトークンで公開・非公開の両方が見られたために起きました。
実践ポイント: エージェント専用の資格情報を新しく発行します。最初は読み取りだけを許可し、書き込みは業務ごとに1つずつ足します。対象も、全社の共有ドライブではなく特定のフォルダやリポジトリに限定します。
②元に戻せない操作にだけ、人の承認を残す
すべての操作に承認を挟むと、承認が形だけになります。経済産業省の検討会でも、国内企業へのヒアリングで人の承認が形骸化しているという課題が挙がりました。絞ることが必要です。
実践ポイント: 削除・外部への送信・支払い・本番環境への反映の4つだけを承認の対象にします。それ以外は自動で通します。あわせて本番と検証の環境を分け、エージェントの既定の接続先を検証側にしておきます。
③外部から来た文字列は「指示」ではなく「データ」として扱う
メール、Webページ、Issue、添付ファイル。業務で読み込むものはすべて、攻撃者が書き込める可能性があります。
実践ポイント: 外部から取得した内容は、指示を書く領域ではなく参照データの領域に入れて渡します。そのうえで、読み込んだ内容をきっかけに外部へ送信する動作には、必ず②の承認を挟みます。手口と防御策の詳しい整理はプロンプトインジェクションの対策をご覧ください。
④連携先と操作ログを棚卸しする
⑥のツールポイズニングは、どのツールに接続しているかを把握していれば、異常に気づけた可能性があります。⑤のように、使っている拡張機能そのものが途中で汚染されることもあります。
実践ポイント: 接続しているツールとその提供元を一覧にし、バージョンを固定します。追加するときは申請制にします。あわせて、エージェントが実際に何を実行したかのログを残し、週に一度、想定外の操作がないかを確認します。
4つとも、特別な製品を買う話ではありません。設計と運用の決めごとです。作る手順そのものはAIエージェントの作り方で5工程に分けて解説しています。
AIエージェントを開発したいが、自社の業務でどこまで自律させてよいか判断がつかない場合は、スパイクスタジオにご相談ください。導入前の不安や、どの業務から切り出すかの整理からお手伝いします。
スパイクスタジオの支援事例
弊社は株式会社Circloop様のシステム改修で、生成AIを全面的に使った開発を行いました。開発業務の80%以上をAIが担い、従来の約1.3倍のスピードで改修を完了しています（株式会社Circloopの事例）。また、お客様の環境に合わせたオーダーメイドなAIエージェントを開発し、業務効率を上げた自社事例が複数あります。詳細については、ぜひお問い合わせください。
このときも、AIに任せる範囲と人が確認する範囲を工程ごとに決めたうえで進めました。どこまで自律させるかを決めるのは、使い始める前の設計です。
AIエージェントの設計と運用は、スパイクスタジオへご相談ください
AIエージェントは、権限と実行経路を先に設計しておくことで、事故のリスクを下げられます。逆に設計を後回しにして動かし始めると、気づいた時点では外部に作用したあとになります。
スパイクスタジオでは、次の支援を行っています。
- Spike AI Agent Studio｜専任のエンジニアと開発を実行するAIがチームになり、月額定額でAIエージェントを作り、直し続ける体制
- BPRコンサルティング｜AIを前提に、業務プロセスそのものを組み替える設計
- AI人材育成｜使う側・作る側・基盤層の三層に分けた研修
- ZUNO｜図面・設計・積算など、専門業務のための産業特化型AIエージェント
どこまで自律させるか、どの操作に人の確認を残すかは、業務ごとに答えが変わります。AIエージェントの導入と権限設計についてご相談ください。現状の課題を整理するところからご一緒します。