AIコード生成ツールを安全に使う開発者チェックリスト
スロップスクワッティング対策の現状と今すぐできる5つの対策
GitHub Copilot・Cursor・Claude Codeが提案する架空パッケージ名を攻撃者が先取り登録する「スロップスクワッティング」。2026年最新論文のデータを踏まえ、今日から実践できるlockfile管理・SCA統合・サンドボックステストなど5つの防御策を解説します。
GitHub Copilot・Cursor・Claude CodeといったAIコーディングアシスタントが提案するパッケージ名を、そのままインストールしていませんか？
2026年5月19日、arXivに投稿されたプレプリント論文（arXiv:2605.17062）が改めて確認したのは「フロンティアモデルでもパッケージハルシネーション率は4.62〜6.10%で残存している」という事実です。「最新モデルに変えたからもう安全」ではなく、**脅威は規模を縮めながらも続いている（The Range Shrinks, the Threat Remains）**というのが研究者たちのメッセージです。
この記事は、スロップスクワッティング（slopsquatting）の仕組みと最新データを整理したうえで、今日から開発ワークフローに組み込める5つの対策を具体的に解説します。同じサプライチェーンセキュリティの文脈でも、HuggingFaceのpickle脆弱性（モデルファイル経由の攻撃）やMCPのtool poisoningとは攻撃ベクターが異なります。本記事が扱うのは「LLM自身が架空パッケージ名を”捏造”してしまう」という固有のリスクです。
スロップスクワッティングとは何か
「スロップスクワッティング（slopsquatting）」は、LLMが存在しないパッケージ名を「捏造（ハルシネーション）」することを利用した攻撃手法です。攻撃者はLLMが頻繁に捏造するパッケージ名を事前に調査し、そのパッケージ名でPyPIやnpmに悪意あるパッケージを先行登録します。
開発者がAIの提案コードを確認せずにインストールすると、意図しないマルウェアや情報窃取コードを実行してしまうリスクがあります。一般的な「タイポスクワッティング」が正規パッケージ名に似た名前を使うのに対し、スロップスクワッティングはAIが生成した架空の名前を悪用する点が異なります。
名前の由来は「slop（粗悪な出力）+ squatting（先占）」の造語で、SecurityWeekなど英語圏のセキュリティメディアでも広く報じられています（SecurityWeek, 2024）。
2026年最新データ：フロンティアモデルでもリスクは残る
2026年5月19日にarXivに投稿された論文「The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort」（arXiv:2605.17062）は、最新のフロンティアモデル群におけるパッケージハルシネーション問題を再評価した研究です（査読前プレプリントであり、今後内容が更新される可能性があります）。
この論文では5種類のモデルを対象に、199,845件のプロンプトを用いた大規模評価を実施しました。
| モデル | ハルシネーション率 |
|---|---|
| Claude Sonnet 4.6 | 4.62% |
| GPT-5.4-mini | 4.98% |
| DeepSeek V3.2 | 5.41% |
| Gemini 2.5 Pro | 5.73% |
| Claude Haiku 4.5 | 6.10% |
最新モデルでもハルシネーション率は4〜6%台で推移しており、完全にゼロにはなっていません。また、研究者たちは5つのモデル全てに共通して現れる捏造パッケージ名127件（PyPI 109件、npm 18件）を特定しています。これらはどのモデルを使っても確率的に出現しうるため、攻撃者にとって安定した標的になりえます。
Infosecurity Magazineの報告によれば（Infosecurity Magazine, 2024）、スロップスクワッティング問題は2024年前後から研究者の間で注目を集めており、生成AIを活用する開発者が増えるにつれてリスク面の整備が急務とされています。
5つの対策：今日から始められる開発ワークフローの見直し
Snykが公開している緩和策ガイド（Snyk: Slopsquatting Mitigation Strategies）を参考に、実務で導入しやすい5つの対策を解説します。
対策1：lockfileによるバージョン・ハッシュの固定
最も確実な「事後変更防止策」がlockfileの活用です。
- Python（pip）:
pip freeze > requirements.txtでバージョン固定 - Python（Poetry）:
poetry.lockが自動生成される。poetry install --frozenで再現性を保つ - Python（Pipenv）:
Pipfile.lockが生成される。pipenv install --deployで厳密な一致を強制 - Node.js（npm）:
package-lock.jsonを必ずコミットし、npm ciでインストール - Node.js（Yarn）:
yarn.lockをコミットし、yarn install --frozen-lockfileを使う
lockfileはパッケージ名・バージョン・依存関係ハッシュを記録するため、一度検証済みの状態を保存・再現できます。初回インストール時にパッケージが実在することを確認できれば、以降の再現性はlockfileが保証します。
# CI/CDでのlockfile活用例（GitHub Actions）
- name: Install dependencies
run: npm ci # package-lock.json が存在しない場合はエラーで停止する対策2：AIが提案したパッケージのインストール前確認
AIが提案したパッケージ名は、必ずインストール前に存在確認を行いましょう。確認すべき観点は次の3点です。
- 公式レジストリに存在するか: PyPI または npmjs.com で名前を検索
- ダウンロード数は妥当か: 正規ライブラリであれば週次ダウンロード数が数万〜数百万規模であることが多い。週次数十件のパッケージは要注意
- 公開日と更新履歴: 数日前に初めて公開されたパッケージをAIが「有名ライブラリ」として提案してきた場合は赤信号
# PyPIでの確認（コマンドライン）
pip index versions <パッケージ名>
# または PyPI JSON API で確認
curl -s https://pypi.org/pypi/<パッケージ名>/json | python3 -m json.tool | grep '"version"'対策3：SnykやSocketなどSCAツールによるパッケージ評判スキャン
SCA（Software Composition Analysis）ツールは、依存パッケージのセキュリティリスクを自動評価します。スロップスクワッティング対策として注目されているのが次のツールです。
Snyk
- CI/CDに統合可能（GitHub Actions・GitLab CIなど）
- 新規登録パッケージや依存関係の脅威スコアを提示
snyk testでプロジェクト単位のスキャンが可能
Socket（socket.dev）
- npmパッケージの「評判スコア」を算出
- インストール直後のネットワーク通信・ファイルシステムアクセスなどの動的リスクを検出
- GitHub Appとして自動でPRレビューに組み込める
実務的には、まず無料プランで試験導入し、CI/CDのPRチェックに組み込むと継続的に機能します。
対策4：AI生成コードのサンドボックス環境でのテスト先行実行
AIが提案したコードブロック（新規パッケージのインポートを含む場合）は、本番・開発環境に直接適用する前に、隔離された仮想環境で動作確認することを推奨します。
# Python仮想環境でのサンドボックステスト
python3 -m venv /tmp/ai-test-env
source /tmp/ai-test-env/bin/activate
pip install <AIが提案したパッケージ名>
python3 -c "import <パッケージ名>; print('OK')"
deactivate
rm -rf /tmp/ai-test-envDockerやDevContainerを活用することで、さらに隔離度の高い検証環境を手軽に用意できます。ポイントは「インストール時に予期しないネットワーク通信や書き込みが発生していないか」を確認することです。本番環境で使う前の「最後の防御層」として機能します。
対策5：DepScopeなどMCP統合によるリアルタイムブロック（任意）
より積極的なリアルタイム防御として、MCP（Model Context Protocol）サーバーを介してAIコーディングアシスタントにパッケージ検証機能を統合するアプローチが登場しています。
DepScopeはその一例で、AIがパッケージ名を生成する段階でリポジトリの実在確認をリアルタイムに行い、存在しないパッケージ名を含むコードが出力される前にブロックする仕組みを目指しています（DepScopeデータセット: GitHub）。
ただし、MCP統合はAIツールへの設定変更が必要であり、チームやCI/CD環境への組み込みにある程度の工数が伴います。対策1〜4を先に整備してから、余裕があれば検討する「任意の追加対策」として位置付けるのが現実的です。
実務での優先順位と「プロンプト確認習慣」
5つの対策を導入コストと効果でマッピングすると次のようになります。
| 対策 | 導入コスト | 防御効果 | 優先度 |
|---|---|---|---|
| ①lockfile管理 | 低 | 高 | 最優先 |
| ②手動確認 | 低 | 中（習慣化が必要） | 優先 |
| ③SCAツール | 中 | 高（継続的） | 優先 |
| ④サンドボックス | 中 | 中（工数あり） | 推奨 |
| ⑤MCP統合 | 高 | 高（ツール依存） | 任意 |
あわせて、AIコーディングアシスタントを使う際の「プロンプト習慣」も効果的です。
【AIコーディングアシスタントへのプロンプト例】
以下の機能を実装してください。
なお、提案するパッケージは必ずPyPI（またはnpm）に実在するものを使用し、
架空のパッケージ名を含めないようにしてください。
また、各パッケージの公式ドキュメントURLも添えてください。「実在するパッケージのみ使うよう」明示的に指示することで、ハルシネーションが発生する確率をある程度下げる効果が期待できます。ただし、これだけでは完全ではないため、上記の対策と組み合わせることが重要です。
よくある質問
クリックで展開。
スロップスクワッティングはどのAIコーディングツールで発生しますか？
GitHub Copilot・Cursor・Claude Code・ChatGPTなど、コード補完・生成を行うLLMベースのツール全般で理論的には発生しうります。arXiv:2605.17062の研究では、Claude Sonnet 4.6・Claude Haiku 4.5・GPT-5.4-mini・Gemini 2.5 Pro・DeepSeek V3.2の5モデル全てでハルシネーションが確認されています。
最新モデルに変えれば安全になりますか？
最新フロンティアモデルではハルシネーション率が低下傾向にありますが、2026年の研究時点では4〜6%台が残存しており「ゼロ」にはなっていません。論文タイトルが示す通り「脅威は続く（The Threat Remains）」状態です。モデル更新と並行して、本記事で紹介した対策を導入することを推奨します。
PyPIやnpmの存在確認だけで十分ですか？
存在確認は必要ですが十分ではありません。攻撃者が架空パッケージ名を事前に登録している場合、PyPIに「存在する」ことになります。ダウンロード数・公開日・メンテナー情報のチェックや、SCAツールによる評判スキャンを組み合わせることで防御の厚みが増します。
lockfileをGitリポジトリにコミットすべきですか？
はい、コミットを推奨します。lockfileをコミットすることで、チームメンバー全員が同一のパッケージバージョン・ハッシュを使用でき、CI/CDでの再現性も保証されます。ただし、シークレットが含まれないことを確認してからコミットしてください。
既存のプロジェクトにSCAツールを追加導入するのは難しいですか？
SnykやSocketはいずれも既存プロジェクトへの後付け導入を想定しており、GitHub AppsやCLIツールとして追加できます。無料プランでまず試し、必要に応じて有料プランへ移行するアプローチが現実的です。
まとめ
2026年最新の研究（arXiv:2605.17062）は、フロンティアモデルでもパッケージハルシネーション率が4.62〜6.10%で残存し、全モデルに共通する捏造パッケージ名が127件特定されていると報告しています（査読前プレプリント）。
スロップスクワッティングはモデルを変えるだけでは解決しません。開発ワークフローへの防御の組み込みが重要です。今日から始められる対策を優先度順に整理すると：
- lockfileの徹底管理（package-lock.json・poetry.lock・Pipfile.lock）
- AI提案パッケージのインストール前存在確認（PyPI/npm検索・ダウンロード数確認）
- SCAツール（Snyk・Socket等）のCI/CD統合
- サンドボックス環境でのテスト先行実行
- DepScope等のMCP統合（任意・余裕があれば）
AIコーディングアシスタントの生産性メリットを活かしながら、こうした「確認の習慣」と「ツールによる自動化」を組み合わせることが、実務での現実的なリスク低減につながります。
次に読むおすすめ
AIコーディングやAIサプライチェーンのセキュリティをより深く学びたい方に向けて、筆者がまとめたnote記事を紹介します。
- 【2026年最新】主要AIツール5つに自腹課金して徹底比較！生産性が劇的に変わる「用途別・最強の1つ」の選び方 — AIコーディングツールの選び方・使い分けを実務目線でまとめたnote記事です。本記事の対策をどのツールに適用するか悩んでいる方にも参考になります。
関連記事
- HuggingFaceモデルのpickle脆弱性とsafetensors安全移行ガイド — モデルファイル経由の攻撃（ダウンロード時RCE）に対する対策。スロップスクワッティングとは異なる攻撃ベクターですが、AIサプライチェーンセキュリティとして合わせて確認したい
- MCPのtool poisoning・rug pull・サプライチェーン攻撃から守る — LLMアプリのランタイム攻撃を防ぐ防御設計チェックリスト。対策5のMCP統合の文脈でも参考になる
- AgentDojo論文解説：AIエージェントのプロンプトインジェクション対策を評価する実務チェックリスト — AIエージェントの安全性評価手法を学べる論文解説
参考リンク
- arXiv:2605.17062「The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort」（2026年5月19日公開、査読前プレプリント）: https://arxiv.org/abs/2605.17062
- SecurityWeek「AI Hallucinations Create a New Software Supply Chain Threat」: https://www.securityweek.com/ai-hallucinations-create-a-new-software-supply-chain-threat/
- Infosecurity Magazine「AI Hallucinations: Slopsquatting」: https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/
- Snyk「Slopsquatting Mitigation Strategies」: https://snyk.io/articles/slopsquatting-mitigation-strategies/
- DepScope ハルシネーションデータセット（GitHub）: https://github.com/cuttalo/depscope-hallucinations-dataset