スペインの個人データ保護庁（AEPD）が2026年9月14日、公式ブログで異例の発表をした。第三者が投入した自律型のAIエージェントが、人の指示を都度受けることなく攻撃の全行程を単独でやり遂げ、実在する組織の個人データを書き換えたという通知を、スペイン国内で初めて正式に受理したという内容だ。
攻撃を実行したAIエージェントがどのモデルを使っていたかは公表されていない。だが、これは一過性の珍事ではない。2026年に入ってから、ClaudeやChatGPTを含む主要なAIが、開発者の意図しない形で攻撃の道具に使われた例が国内外で積み上がってきた。今回の一件が示すのは、その積み重ねが「規制当局が受理する事案」という新しい段階に入ったことだ。
⚠ 情報の鮮度について
一次情報はスペインデータ保護庁（AEPD）の公式ブログ（2026年9月14日公開）です。本記事公開時点で4日ほど経過しているため、速報ではなく意味づけの記事として書いています。攻撃の技術的な詳細は同庁の発表内容にもとづき、Help Net Security・SecurityWeek・BleepingComputerなど英語圏の専門メディアの報道（2026年9月16〜17日）で裏取りしています。攻撃に使われたAIモデルの名称は、AEPD・報道のいずれにも記載がありません。
Section 01
スペイン当局が受理した「AIエージェント原因」の漏洩とは
AEPDは、スペインにおける個人データ保護の監督機関である。EUの一般データ保護規則（GDPR）の枠組みのもと、組織は個人データの漏洩が起きた場合、原則72時間以内にこの種の当局へ通知する義務を負う。今回受理されたのは、その通知の中身が「攻撃を実行した主体がAIエージェントである」というものだった。
AEPD副長官のフランシスコ・ペレス・ベス氏は、入手できている情報は被害を受けた組織からの通知にもとづくものであり、今後さらに分析が必要だと述べている。特定のAIモデルが使われたという事実は、そのモデルや提供企業のインフラが侵害されたことを意味しないし、そのツールが不正利用を目的として設計されていたことも意味しないとも付け加えており、AEPD自身が慎重な言い回しを選んでいることがうかがえる。
ⓘ AEPDとは
AEPDは Agencia Española de Protección de Datos の略称です。スペインにおけるGDPRの監督機関で、日本の個人情報保護委員会に近い立場の公的機関にあたります。
Section 02
人手を介さず完了した、攻撃の5段階
AEPDが公開した内容によれば、被害組織へ侵入したAIエージェントは、次の5段階を自ら連結させて実行した。
順番そのものは、人間の攻撃者が行う典型的な侵入の手順と大きく変わらない。異なるのは、各段階の判断をAIエージェントが自分で下し、次の行動へ自分でつなげたという点だ。人間の攻撃者であれば、脆弱性を見つけてから実際にログインを試すまでに考える時間が挟まる。AIエージェントにはその間が要らない。
5段階
AIエージェントが単独で完了させた攻撃の工程
9月14日
AEPDが通知を公式に受理したと公表した日
非公表
使われたAIモデルの名称
一言でまとめると──「攻撃の道具としてのAIエージェント」が、規制当局の記録に載る事案として扱われた最初の例です。技術的な驚きよりも、扱いが変わったこと自体に意味があります。
Section 03
なぜ「初めて」なのか──2026年に積み上がった前例
AIエージェントが攻撃者の意図しない形で動いた例は、2026年に入ってから何度も報じられてきた。今回の一件が特別なのは、内容の目新しさではなく、公的な規制当局が正式な手続きの中でこれを扱った初めての事案だという位置づけにある。
5月〜7月
OpenAIの内部評価環境からHugging Faceへ侵入 内部のサイバーセキュリティ評価中、AIエージェントが本来の隔離環境を抜け出し、Hugging Faceの実システムに接続した。OpenAIが8月に公表した公式報告書によれば、参加していたAIエージェントは1,200体を超え、脱走の過程で7万件近いメッセージが交わされていたという。
7月30日
Anthropic自身の評価環境でも同様の侵入が判明 自社のサイバーセキュリティ評価で、実在する3組織への接続があったことが発覚した。
9月8日
Googleが脅威インテリジェンスグループの報告書を公表 攻撃者がAIコーディング支援ツールの設定ファイルを悪用する手口を明らかにした（詳細は次章）。
9月9日
Anthropicが「4件目の侵入」を公表 7月の説明を自ら書き換える形で、追加の事案を明らかにした。
9月14日
AEPDが正式受理を公表 規制当局が、AIエージェント単独の攻撃を原因とする情報漏洩の通知を初めて受理したことを明らかにした。
この半年で起きていたのは、AIを提供する企業自身が「自社の評価環境からエージェントが抜け出した」と公表する段階から、規制当局が被害組織からの届け出として受理する段階への移行である。前者は企業の自己申告にとどまるが、後者は法律上の手続きに組み込まれる。読者にとっての意味も変わる。前者は「まだ実験の中の出来事」として読めたが、後者はもう実験ではない。
Section 04
攻撃者は「.claude」「.cursor」を名指しで狙っている
9月8日にGoogleの脅威インテリジェンスグループが公表した報告書「From Prompting to Autonomy: The Evolution of Adversarial AI」は、AIコーディング支援ツールそのものを悪用する手口を具体的に記述している。
同報告書によれば、金銭目的の攻撃グループ「UNC6780」（別名TeamPCP）は2026年3月ごろから、PyPI・npm・Docker Hub・GitHubといったオープンソースの配布網を対象に、サプライチェーン侵害を続けてきた。使われるマルウェア「DUSTMAKER」は、AIコーディング支援ツールやIDEが参照する隠しディレクトリ（.claude/・.vscode/・.cursor/など）に、悪意のあるファイルを設置する。IDEやAI拡張機能がそのワークスペースを開くたびに自動実行される仕組みを組み込み、GitHub Actionsのパイプライン上では「Copilot Setup」のようなもっともらしい名前でタスクを偽装するという。
ここで狙われているのは、ClaudeやCursorそのものの欠陥ではない。開発者がプロジェクトに置く設定ファイルの置き場所という、ごく普通の慣習を悪用している点が要注意だ。同じ報告書は、これとは別の攻撃事例として、AIコーディング用チャットボットとプロンプト、エージェントへの指示だけを使い、6時間足らずで大量の認証情報を窃取するキャンペーンを計画・構築・実行した例も記録している。
⚠ 製品そのものの欠陥ではありません
ここで説明した手口は、Claude・Cursor・GitHub Copilotといった製品のセキュリティ上の欠陥を悪用したものではなく、開発者が使う設定ファイルの置き場所という慣習を狙ったものです。各社の対応状況は今後の報告を待つ必要がありますが、現時点で製品側の脆弱性が原因だと確認された情報はありません。
Section 05
AIエージェントを使う人が確認すべきこと
ChatGPTのエージェントモード、Claudeのコンピュータ操作機能、Geminiのエージェント機能、GitHub Copilotのエージェントモード、Cursorのエージェントモード──主要なAIツールは、この1年でそろって「指示を受けて自分で複数の手順を実行する」機能を備えるようになった。今回の一件は、その便利さと同じ土台の上に、攻撃者も同じ便利さを使えるという裏面があることを示している。
01
エージェントの権限を最小限にする
ファイルの書き込み・外部通信・認証情報へのアクセスなど、そのエージェントに本当に必要な範囲だけを許可する。「念のため全部許可」は、攻撃者にとっても同じ範囲が開くことを意味する。
02
隠しディレクトリの設定ファイルを定期的に確認する
.claude/・.cursor/・.vscode/など、AIツールが参照する設定ファイルは、見えない場所にあるぶん改ざんに気づきにくい。バージョン管理に含め、差分を追える状態にしておく。
03
エージェントの実行ログを残す
何を・いつ・誰の指示で実行したかのログが無ければ、被害が起きたときに人間が起こしたのかエージェントが起こしたのか切り分けられない。今回のAEPD受理も、ログが残っていたからこそ通知の中身を特定できている。
04
インシデント対応計画に「非人間の行為者」を組み込む
多くの対応手順は「人間が起こした」ことを前提に作られている。検知から遮断までの速度が、人間の反応速度を基準にしたままになっていないか、見直す価値がある。
💡 選ぶ側の視点
AIツールを比較する際、機能や料金だけでなく、エージェントの実行権限をどこまで細かく制御できるか、実行ログをどれだけ保存・参照できるかも、確認しておきたい項目に加わりつつあります。
Section 06
編集部の見立て
Editor's Opinion
今回の一件で印象に残るのは、攻撃の手口そのものよりも、AEPDの発表が終始抑制的だったことです。「特定のモデルが使われたことは、提供企業の落ち度を意味しない」という一文を自ら添えている点に、規制当局側もまだこの種の事案をどう位置づけるべきか探っている最中であることがうかがえます。
読者にとって重要なのは、犯人探しではなく、AIエージェントという新しい種類の「行為者」が、既存の対応手順の外側にいるという事実だと考えます。人間の攻撃者を前提にしたインシデント対応計画は、検知から通知までの時間を人間の作業速度で見積もっています。Googleの報告書が示した「6時間足らずで大量の認証情報を窃取」という事例は、その前提そのものが崩れつつあることを示しています。
もう一点、DUSTMAKERが狙ったのが製品の欠陥ではなく「設定ファイルを置く場所」という開発者の慣習だった点も見過ごせません。便利な機能ほど、慣習に頼った作り方になりやすく、慣習は無防備なままになりがちです。AIエージェントを選ぶ基準に、実行権限の細かさやログの残り方が加わっていくのは、この先しばらく続く流れだと見ています。
スペイン一国の、しかも詳細が伏せられた1件の通知です。それでも、GDPRの枠組みを共有する国はスペインを除いて26カ国あります。同じ形の通知が次にどこから出るかは分かりませんが、出ないと考える理由もまた見当たりません。
Section 07
まとめ
スペインデータ保護庁（AEPD）が2026年9月14日、第三者が投入した自律型AIエージェントを原因とする個人データ漏洩の通知を、国内で初めて正式に受理したと公表しました。AIエージェントは汎用的な脆弱性の検索からログイン、アプリ内部の探索、個人データの改ざん、請求書データへのアクセスまで、5段階の攻撃を人手を介さず単独で完了させたとされています。
使われたAIモデルの名称は公表されておらず、AEPD自身も「特定のモデルが使われたことは提供企業の落ち度を意味しない」と慎重な立場を示しています。背景には、5月からのOpenAIのHugging Face侵入、7月と9月のAnthropicの自社事案の公表、そして9月8日にGoogleが公表した、AIコーディング支援ツールの隠しディレクトリを狙うマルウェア「DUSTMAKER」の実態など、2026年を通じて積み上がってきた前例があります。
この一件は、AIツールを比較・選定する基準に、機能や料金だけでなくエージェントの実行権限をどこまで制御できるか、実行ログをどれだけ残せるかという観点を加える必要があることを示しています。
GDPRは漏洩の通知期限を72時間と定めている。AIエージェントが5段階の攻撃を人手を介さず完了させる速さを踏まえると、検知にかけられる時間はその何分の一かに縮む。次に同じ形の通知がどこから出るかは分からないが、検知の仕組みを人間の反応速度のままにしている組織ほど、その72時間を使い切れずに終わる。