AIコーディングアシスタントが幻覚するパッケージ名が攻撃面になる
スロップスクワッティングの実態と開発者が今すぐ取れる対策（arXiv 2605.17062）
5モデル・199,845プロンプトの大規模検証で明らかになったLLMパッケージ幻覚の実態。幻覚率4.62〜6.10%、127の共通幻覚パッケージ名という「スロップスクワッティング」攻撃面の現状と、開発者が今日から実践できる3ステップ対策を解説します。（査読前arXivプレプリント）
GitHub CopilotやCursor、Claude Codeでコードを書いていると、「このライブラリ、聞いたことないな」と思いながらも pip install や npm install を実行してしまったことはないだろうか。
その違和感は、正しかったかもしれない。
2026年5月16日、独立研究者のAleksandr Churilovがarxivに公開したプレプリント「The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort」は、最新フロンティアモデルでも4〜6%のプロンプトでパッケージ名の幻覚が発生することを、5モデル・約20万件の実験で実証した。
本記事が扱うのは**「消費側攻撃面」だ。攻撃者がpipやnpmのパッケージを改ざんする「製造側攻撃」（PyPI供給チェーン汚染）とは根本的に異なる。AIコーディングアシスタントが存在しないパッケージ名を生成し、攻撃者がその名前を先回りして登録する**という手法が「スロップスクワッティング（slopsquatting）」だ。コードを書く側、つまり私たち開発者が「受け取り側」として直面するリスクである。
論文情報: Aleksandr Churilov,「The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort」, arXiv:2605.17062, 2026年5月16日公開。本論文は査読前のarXivプレプリントであり、内容は今後変更される可能性がある点に留意されたい。
なぜ2026年に「再評価」が必要だったのか
パッケージ幻覚の問題が最初に注目されたのは2023年頃だ。当時の研究では、商用モデルで5.2%、オープンソースモデルで21.7%という幻覚率が報告されている（Churilov論文が参照する先行研究より）。
しかし2年以上が経過し、Claude Sonnet 4.6、Claude Haiku 4.5、GPT-5.4-mini、Gemini 2.5 Pro、DeepSeek V3.2といった「2026年フロンティアモデル」が登場した。各社が安全性・正確性の向上を謳う中、パッケージ幻覚の問題は本当に解消されたのか——それが今回の研究が問う出発点だ。
また、先行研究では限定的なデータセットや少数のモデルで検証されていたものが多く、現在の主要コーディングアシスタントを対象にした横断的な大規模評価は存在しなかった。スロップスクワッティング攻撃の可能性を指摘した「Importing Phantoms」論文（arXiv:2501.19012）の発表後も、実際の攻撃面の規模を数値で示した研究は少なかった。
実験設定：199,845プロンプトで5モデルを横断検証
Churilovの研究設計は次のとおりだ。
対象モデル（5つ）:
- Claude Sonnet 4.6
- Claude Haiku 4.5
- GPT-5.4-mini
- Gemini 2.5 Pro
- DeepSeek V3.2
検証方法:
- プロンプト総数: 199,845件
- 対象エコシステム: Python（PyPI）と JavaScript（npm）
- 検証基準: PyPI・npmのマスターリストを使い、LLMが生成したパッケージ名が実際に存在するかを確認
- パッケージ名の「幻覚」とは: モデルがコード例に含めたパッケージ名がPyPIまたはnpmに登録されていないこと
この規模の実験は、先行研究と比べて統計的な信頼性が格段に高い。
主な結果：改善されたが、脅威は継続する
幻覚率の比較
| モデル | 幻覚率 |
|---|---|
| Claude Haiku 4.5 | 4.62%（最低） |
| Claude Sonnet 4.6 | — |
| Gemini 2.5 Pro | — |
| DeepSeek V3.2 | — |
| GPT-5.4-mini | 6.10%（最高） |
| 先行研究（商用モデル） | 5.2% |
| 先行研究（オープンソース） | 21.7% |
全体の幻覚率は**4.62〜6.10%**の範囲に収まった。先行研究と比較すると、オープンソースモデルの大幅な改善が目立つ。フロンティアモデルは商用モデルの先行値（5.2%）とほぼ同水準か、わずかに改善している。
ただし、これは「問題が解消された」を意味しない。
毎日何百万件もの開発者がコーディングアシスタントにコードを生成させている状況で、4〜6%という幻覚率は無視できない規模だ。
127の「共通幻覚パッケージ名」：最も危険な発見
今回の研究で特に重要な発見は、127のパッケージ名（PyPI 109件・npm 18件）を5つのモデルすべてが同一に幻覚したことだ。
これが意味することは深刻だ。特定のモデルだけが幻覚するパッケージ名であれば、「このモデルでコードを生成した場合にだけ注意」という対策が成り立つ。しかし、**全モデルが共通して幻覚するパッケージ名は「モデル非依存の攻撃面」**となる。
攻撃者がこれらのパッケージ名をPyPIやnpmに先回り登録すれば、どのコーディングアシスタントを使う開発者でも同じワナにはまる可能性がある。Claude Codeを使っていようと、Copilotを使っていようと、Cursorを使っていようと——だ。
スロップスクワッティングとは何か
「スロップスクワッティング（slopsquatting）」という用語は、LLMが生成する「スロップ（slop：粗悪なAI生成物）」と、ドメインスクワッティング（他者のブランドを先取りする手法）を組み合わせた造語だ。
攻撃のシナリオは以下のステップで進む。
- 攻撃者が幻覚パッケージ名を特定する: コーディングアシスタントに「〇〇の処理をするPythonコードを書いて」と入力し、LLMが存在しないパッケージ名を出力するパターンを収集する
- 攻撃者がPyPI/npmにパッケージを登録する: LLMが幻覚したパッケージ名と同名の悪意あるパッケージをリポジトリに登録する
- 開発者がインストールする: コーディングアシスタントのサジェストに従って
pip install <幻覚パッケージ名>を実行する - 悪意あるコードが実行される: インストール時や
import時に、悪意あるコードが開発者のマシンまたはCI/CD環境で実行される
タイポスクワッティング（例: reqests vs requests）は「入力ミス」を狙うが、スロップスクワッティングはAIアシスタントへの信頼を狙う点が本質的に異なる。
Trend Microの解説（参考リンク参照）によれば、この攻撃手法はAIエージェントを使った自動コード生成・自動デプロイパイプラインでも機能し、人間の確認ステップが少ない環境ほど被害が広がりやすい。
先行研究との比較：「改善したが、終わっていない」
論文のタイトルは「The Range Shrinks, the Threat Remains（範囲は縮まったが、脅威は続く）」だ。この一文が結論を的確に表している。
| 指標 | 先行研究（商用） | 先行研究（OSS） | 今回（フロンティア） |
|---|---|---|---|
| 幻覚率 | 5.2% | 21.7% | 4.62〜6.10% |
| モデル数 | 少数 | 少数 | 5モデル |
| プロンプト数 | 限定的 | 限定的 | 199,845件 |
商用モデルの数値（5.2%）と比べると、フロンティアモデルは横ばいか微改善にとどまっている。オープンソースモデルの大幅改善（21.7% → フロンティアレベル）は確認されたが、それはモデルの進化を示す一方、問題が依然として現役であることも示している。
論文の限界と注意点
著者が認識している主な限界：
- エコシステムの範囲: PyPIとnpmのみを対象としており、RubyGems・Maven・NuGetなどは未検証
- 言語の偏り: PythonとJavaScriptに限定。GoやRustなどのエコシステムの実態は不明
- プロンプトの多様性: 実験で使用したプロンプトの多様性や実際の開発シナリオとの乖離がある可能性
- 動的な状況: 実験後にPyPI/npmへの登録状況が変化した可能性があり、スナップショットとしての性格がある
また、研究で特定された「幻覚パッケージ名一覧」の公開については倫理的配慮が必要なため、本記事でもパッケージ名の列挙は行わない。
実務への示唆：今日から取れる3ステップ対策
コーディングアシスタントを使い続けることを前提に、現実的な対策を整理する。
ステップ1：pip show / npm view でインストール前に確認する
AIが提案したパッケージをインストールする前に、まずそのパッケージが実在するかを確認する習慣をつける。
# PyPI での確認（インストール前にパッケージ情報を表示）
pip index versions <パッケージ名>
# またはブラウザで PyPI を直接確認
# https://pypi.org/project/<パッケージ名>/
# npm での確認
npm view <パッケージ名>パッケージが存在しない場合は ERROR: No matching distribution found などのエラーが返る。また、PyPI-Simpleエンドポイント（https://pypi.org/simple/<パッケージ名>/）にアクセスして404が返るかどうかでも確認できる。
確認すべき追加ポイント：
- ダウンロード数: 正規パッケージは通常数十万〜数百万件のダウンロード実績がある。ダウンロード数がゼロや数十件の場合は慎重に
- 公開日時: 直近数日以内に公開されたパッケージはリスクが高い
- GitHub/ソースリポジトリ: パッケージのホームページや説明文の品質を確認する
ステップ2：lockファイルを使い、バージョンをピン留めする
# Python: requirements.txt にバージョンを明示してハッシュも固定
pip install <パッケージ名>==<バージョン> --require-hashes
# またはuv/pipenvを使ったlockfile管理
uv lock
# uv.lock ファイルがコード生成時のパッケージと同一かを確認できる
# Node.js: package-lock.json または yarn.lock を使う
npm ci # package-lock.json 通りにインストールlockファイルを使うことで、後から悪意ある更新版がリリースされた場合でも、指定したバージョンが使われ続ける。スロップスクワッティングの初期段階（攻撃者がパッケージを登録した直後）での被害を防ぐ直接的な効果はないが、後続の改ざんには有効だ。
ステップ3：AIが提案するパッケージ名を逐一検索するルールをチームで共有する
個人の習慣だけでなく、チームのコードレビュープロセスに「新規パッケージのPyPI/npm確認」を含める。
特にCI/CDパイプラインでAIが自動生成したコードをそのままインストールする構成は避ける。人間の確認ステップを一つ挟む設計にする。
よくある質問（FAQ）
スロップスクワッティングに関するよくある質問
クリックで展開。
スロップスクワッティングとタイポスクワッティングはどう違いますか？
タイポスクワッティングは人間のタイプミスを狙います（例: reqests → requests）。スロップスクワッティングはAIが「正しい」と思って生成した幻覚パッケージ名を狙います。前者は「注意深く入力すれば防げる」ですが、後者はAIへの信頼を悪用するため、開発者が疑いを持ちにくいのが特徴です。
幻覚率4〜6%は高いですか？低いですか？
コンテキスト次第です。1件のプロジェクトで数十のパッケージをインストールする場合、1〜3件程度は幻覚名が含まれる計算になります。また、特定の技術領域（例: 新興のPythonライブラリが多い分野）では幻覚率がさらに高くなる可能性があります。「低くなった」という評価と「まだ問題がある」という評価は両立します。
Claude CodeやGitHub Copilotなど特定のツールを避ければ安全ですか？
今回の研究では127のパッケージ名を5つの全モデルが同一に幻覚しています。「特定のモデルを避ける」ことはこの問題の解決策にはなりません。モデル選択より、インストール前の確認習慣とlockfileの使用が実効性の高い対策です。
この論文は査読済みですか？
いいえ、2026年5月時点では査読前のarXivプレプリントです。実験方法や結論は今後の査読で変更される可能性があります。ただし、パッケージ幻覚という問題自体は先行研究（2501.19012等）でも確認されており、今回の研究はその規模と対象モデルを更新した検証として位置付けられます。
攻撃者はどうやって幻覚パッケージ名を知るのですか？
研究者が行ったような「大量プロンプトテスト」を攻撃者も実施できます。また、オープンなコミュニティや学術論文で幻覚パターンが公開されることもあります。攻撃面を把握するために防御側も継続的なモニタリングが必要です。
まとめ
Aleksandr Churilovの研究（arXiv:2605.17062）は、2026年フロンティアモデルがパッケージ幻覚を4.62〜6.10%の確率で起こすことを示した。先行研究と比べて商用モデルはほぼ横ばい、オープンソースモデルは改善されたが、問題は解消していない。
特に危険なのは、127のパッケージ名が5モデルすべてに共通して幻覚された点だ。これはモデルを乗り換えても消えない「構造的な攻撃面」であり、スロップスクワッティング攻撃者にとって安定した標的になりうる。
AIコーディングアシスタントを日常的に使う開発者として取れる対策は実はシンプルだ。「AIが提案したパッケージをすぐにインストールしない」「PyPI/npmで実在を確認する」「lockfileでバージョンを固定する」——この3点を習慣化することが、今この瞬間にできる最も実効性の高い防御だ。
モデルの改善を待つよりも、自分の確認習慣を改善する方が確実で早い。
次に読むおすすめ
この記事でLLMパッケージ幻覚の概要をつかんだら、 AIツール選定の実務判断に役立つこちらの記事もあわせてどうぞ。
※ リンク先は note の独自コンテンツです。
関連記事
- HuggingFaceモデルのpickle脆弱性とsafetensors安全移行ガイド — モデルファイル自体に仕込まれる「ダウンロード時点の攻撃面」を解説。スロップスクワッティングとは異なる製造側のリスク
- MCPのtool poisoning・rug pull・サプライチェーン攻撃から守る — AIエージェントのツール層を狙う攻撃と防御設計チェックリスト
- LLMエージェントの「過剰権限」を排除する：OWASP LLM06:2025 準拠の最小権限設計 — エージェントの権限設計から被害範囲を最小化する考え方
参考リンク
- 原論文: arXiv:2605.17062 — The Range Shrinks, the Threat Remains（Aleksandr Churilov, 2026年5月16日）
- 関連先行研究: arXiv:2501.19012 — Importing Phantoms（スロップスクワッティングの初期定義）
- Trend Micro: Slopsquatting — When AI Agents Hallucinate Malicious Packages
- Aikido: Slopsquatting — AI Package Hallucination Attacks
- Cloudsmith: Slopsquatting and Typosquatting — How to Detect AI-Hallucinated Malicious Packages