株式会社TIMEWELLの濱本 隆太です。
「Claude CodeにReactの状態管理ライブラリ提案させたら、react-pretty-state ってのを推奨してきた。npm install したらインストールできた。動作も問題ない。これでヨシ」——5分後、その開発者のローカルから本番DBの認証情報が攻撃者のサーバに送信されていた。
これは仮想シナリオではなく、 Slopsquatting という新種のサプライチェーン攻撃の実例です。AIが幻覚で生む 「もっともらしいが実在しないパッケージ名」を、攻撃者が先取り登録 し、開発者が信じて npm install した瞬間に踏み台になる。
Trend Microの2025年調査では、 AIが推奨するパッケージ名の20%が存在しない という衝撃的な数字が報告されています。本記事では、Slopsquattingの仕組み、関連する Cursor / Claude Code / MCP の実害事例、そして開発組織が今日からできる4つの対策を解説します。
要約
- Slopsquatting＝AI幻覚で生まれる架空パッケージ名を攻撃者が先取り登録する新型サプライチェーン攻撃
- 統計：AIが推奨するパッケージの 20%は実在しない。攻撃者にとっては「待ち伏せ」の絶好機
- Cursor（MCPoison / CurXecute）、Claude Code（TrustFall）、MCPサーバ群（7,000+公開、150M+DL）でも実害事例続出
- 対策は 4層：パッケージ署名検証、ロックファイル運用、Workspace Trust徹底、AIBOM
Slopsquattingとは — 1分で理解する
タイポスクワッティング（Typosquatting）の親戚です。
- Typosquatting：
requestsのタイポreqestsを攻撃者が登録 → 開発者の打ち間違いを狙う - Slopsquatting：AIが幻覚で生む
react-pretty-stateを攻撃者が登録 → AIの幻覚を狙う
“Slop”は「AI生成のゴミコンテンツ」の俗称。Slopsquatting研究は2024年後半から本格化し、Trend Micro、Lasso Security、Socketといったセキュリティ企業が攻撃検出事例を公表しています。
統計の重さ — 20%という数字
2025年に発表された研究では、複数のLLMが推奨するパッケージ名 756,000サンプル中、約20%が非実在（PyPI / npm / RubyGems / Maven で検索ヒットなし）でした。
| LLM | 幻覚パッケージ率 |
|---|---|
| GPT系（一般モデル） | 約20% |
| オープンソース系（CodeLlama、Mistral等） | 30-40% |
| 商用上位モデル（GPT-4、Claude） | 約5-15% |
「AIのアウトプットをそのまま信じて npm install」が一定確率で踏み台になる構造 が、構造的に存在することが明らかになりました。
AIセキュリティ研修を、本気で
OWASP・NIST・ISO 42001・経産省ガイドライン全準拠の2日間集中講座。経営層と現場で分けて受講できます。
攻撃の流れ
Step 1：攻撃者が「狙い目」を観測する
複数のAIに同じ質問を繰り返し、幻覚で出てくるパッケージ名を集める。
質問例：「Reactで状態管理するライブラリを5つ推奨して」
→ AI回答に `react-pretty-state` `easy-react-store` といった非実在名が紛れる
Step 2：攻撃者が非実在名を npm/PyPI/その他に登録
実在しない名前のうち、AIが繰り返し提案するものに優先順位を付けて登録。中身は 正規パッケージ + バックドア。
Step 3：開発者がAIに頼って npm install
- Cursor / Claude Code / Copilot が提案
- 開発者が「AIが推奨したから大丈夫」と信じる
npm install react-pretty-state
Step 4：踏み台化
postinstallスクリプトでローカル.env読み出し- AWS / GCP 認証情報、APIキー、社内ネットワーク偵察情報を C2 サーバに送信
- 自己更新機能で検出を回避
Cursor / Claude Code / MCP の実害事例
Slopsquatting単体だけでなく、AIコーディングを取り巻く周辺で実害事例が続出しています。
Cursor MCPoison（CVE-2025-54136、2025年7月）
Cursor IDEのMCPサーバ設定の検証不備を突き、 悪意あるMCPサーバを介して開発者端末でRCE を実行できる脆弱性。CVSS 9.6。
Cursor CurXecute（CVE-2025-54135、2025年8月）
特定のリポジトリを開いた瞬間、 .cursor 設定ファイル経由で任意コード実行。Cursorは即時パッチを公開。
Claude Code TrustFall（CVE-2025-59536、2026年2月）
悪意あるリポジトリの設定ファイル経由で プロジェクトを開いた瞬間RCE、APIキー流出。Anthropicは Workspace Trust の徹底を呼びかけた。
MCPエコシステムの構造的脆弱性
2026年5月時点で 公開MCPサーバ7,000以上、累計DL 150M超。STDIO設計の欠陥、mcp-remote（CVE-2025-6514）などが報告され、 「現代のサプライチェーン最大の侵入口」 と評する研究者も。
開発組織が今日からできる4つの対策
対策1：パッケージ署名検証の義務化
# npm の場合
npm install --signature
npm audit signatures
# PyPI の場合（PEP 458/480）
pip install --require-hashes -r requirements.txt
- 署名なしパッケージは CI/CD で自動 reject
- Sigstore / cosign の活用検討
- 内部レジストリ（Verdaccio、Artifactory）経由のみ許可
対策2：ロックファイルとピン留めの厳格運用
package-lock.json/pnpm-lock.yaml/poetry.lockを必ずコミット- AIに新規パッケージ提案させた直後の
npm installは 必ず人間レビュー - ロックファイル差分が大きい PR は自動でセキュリティ担当へエスカレーション
対策3：Workspace Trust の徹底
Cursor / Claude Code / VSCode 系の Workspace Trust 機能を、社内ポリシーで デフォルト「信頼しない」 に設定。
// VSCode settings.json
{
"security.workspace.trust.enabled": true,
"security.workspace.trust.startupPrompt": "always",
"security.workspace.trust.untrustedFiles": "open"
}
- 外部リポジトリは初回必ず untrusted で開く
- trusted への昇格は明示的な承認フローを通す
- CI環境では Workspace Trust を強制有効化
対策4：AIBOM（AI Bill of Materials）の運用開始
ソフトウェアのSBOMに加えて、 AI関連の依存関係を可視化 する AIBOM の整備：
- 使用しているLLM（GPT-4、Claude、Llama等）
- MCP サーバ一覧と署名
- AIエージェント・ツールの権限スコープ
- 学習データセットの来歴
OWASP の Top 10 for LLM 2025 第3項目「Supply Chain」でも AIBOM が推奨対策として記載されています。
AIに頼るほど、検証コストは下がるべきか上がるべきか
AI コーディングが普及するほど 「人間レビュー」のコストが上がる という直感に反する真実があります。
- 従来：開発者が自分でググって信頼性確認→そのまま採用
- AI併用：AIが提案→開発者が AIの提案を検証 →採用
つまり「AIで生産性が3倍になる」前提のチームは、 「セキュリティレビューも3倍の量を処理する」 必要があります。これを設計に織り込まないと、生産性向上分がインシデント対応コストに飲まれます。
経営層が問うべき1問
「うちのチーム、AIコーディング使ってる？ じゃあ、AI由来のパッケージ追加分について、誰がどう検証してるの？」
これが回答できない組織は、Slopsquattingの待ち伏せ列に並んでいます。
WARP SECURITYでの位置づけ
TIMEWELLの WARP SECURITY では、Slopsquatting型のサプライチェーン攻撃をシナリオ05として扱います。
経営層コースでは、「AI生産性 vs セキュリティ検証コスト」のトレードオフを 投資判断ワークショップ で議論。
現場コースでは、ハンズオン形式で：
- 実際にAIが幻覚パッケージを推奨する瞬間を観測
- 署名検証・Workspace Trust 設定の実装
- AIBOM 雛形の作成
- MCP サーバの来歴チェック手順
を学びます。
EU AI Actとの接続 — 2026年8月2日から始まるもの、まだ始まらないもの
Slopsquatting対策は技術面だけでなく、AIガバナンスの制度枠組みとも接続し始めています。注視すべきは、EU AI Act（Regulation (EU) 2024/1689）の規制枠組み（European Commission）の一般適用日が 2026年8月2日 である点です。ただし、この日に AI Act が「全面適用」されるわけではありません。同法は段階適用を採っており、2026年8月2日から適用が始まるのは主に次の3つです。
- 第4章の 透明性義務（Art.50）
- 第3章第5節（Art.40〜49：整合規格・適合性評価・CEマーキング・登録）
- 欧州委員会が汎用AI（GPAI）モデルの提供者に制裁金を科す権限（Art.101）
一方、高リスクAIの実体義務が始まるのはさらに先 です。Digital Omnibus による改正法 Regulation (EU) 2026/1744（2026年7月8日採択、OJ L 2026/1744 掲載2026年7月24日、2026年7月27日発効）により、附属書III型の高リスクAI（Art.6(2)）には 2027年12月2日、附属書I型（Art.6(1)＝製品組込み型）には 2028年8月2日 から第3章第1〜3節が適用されます。EU代理人（Art.22）、バリューチェーン上の義務（Art.25）、deployer（利用者側）の義務（Art.26）、基本権影響評価（Art.27）も、この適用日に合わせて発動します。
制裁金の水準（Art.99）は、Art.5の禁止行為違反が 最大3,500万ユーロ又は全世界売上高の7%（高い方）、GPAI関連ほかが 最大1,500万ユーロ又は全世界売上高の3%（高い方）。罰則規定である第12章（Art.99・100）自体は2025年8月2日から適用されており、2026年8月2日に加わるのが上記 Art.101 の権限、という整理になります。
なお、2026年8月2日より前に上市された合成コンテンツ生成AIの提供者については、改正で新設された Art.111(4) により、2026年12月2日まで に Art.50(2) へ適合することが求められます。
ここで問われるのはモデル提供側の透明性であり、利用側の依存関係検証を代替するものではありません。むしろ、AIが提案するパッケージの来歴を誰がどう確認するかという運用責任は、これまで通り開発組織に残る——というのが筆者の見立てです。制度が整うほど、AIエージェントの権限と来歴を統制する必要性は増します（統制されたエンタープライズAIエージェントも参照）。
まとめ
- Slopsquatting＝AI幻覚パッケージを狙う新型サプライチェーン攻撃
- 統計：AIが推奨するパッケージの 20%は非実在——攻撃の温床
- Cursor / Claude Code / MCP エコシステムでも実害事例続出（2025-2026）
- 対策は 署名検証、ロックファイル運用、Workspace Trust、AIBOM の4層
- 「AI で生産性 3倍」のチームは、セキュリティ検証も 3倍 処理する設計が必要
AIコーディングは間違いなく強力です。ただし、力には責任が伴います。Slopsquatting は、その責任を放棄したチームから順番に被害に遭う構造的攻撃です。
