はじめに——AIが”存在しないライブラリ”を勧め、それが攻撃の入口になる
これまでのAIセキュリティ記事では、AI生成コードに潜むバグや脆弱性、あるいは汚染パッケージを使ったサプライチェーン攻撃を扱ってきました。しかし2026年、もう一つの新しい攻撃面が現実味を帯びています。それは、LLMが生成した「存在しないパッケージ名」そのものが攻撃の入口になるという手口——スロップスクワッティング（slopsquatting）です。
バイブコーディングが当たり前になり、Claude CodeやCursorが書いたimport文・pip install・npm installをそのまま実行する開発スタイルが広がりました。ところがLLMは、実在しないライブラリ名を、いかにも本物らしく堂々と提案することがあります。攻撃者はこの「AIがよく幻覚する名前」を先回りして公開レジストリに悪意あるパッケージとして登録しておく。そうして、AIを信じた開発者が自らマルウェアをinstallしてしまう——これがスロップスクワッティングの本質です。
筆者はネットワークのNOC/TACで長年、名前解決やルーティングの「正当性検証」に携わってきました。本記事の核心は、この攻撃がDNSのタイポスクワッティングや、権威性のないレコードを鵜呑みにしてしまう構図とまったく同型であり、「名前を解決する前に、その名前が正当かを検証する」というネットワーク防御の発想がそのまま効くという点にあります。
想定読者は、Claude Code／Cursorで開発する個人開発者・スタートアップ・情シスの方々、とくにAI生成コードをそのまま本番に投入している層です。攻撃の仕組みを理解したうえで、ロックファイル・許可リスト・インストール前検証という3層で守る具体策を、実装の視点で整理します。
スロップスクワッティングとは何か——幻覚→先回り登録→拡散の3段階
用語の整理——タイポスクワッティングとの決定的な違い
スロップスクワッティングを理解する最短ルートは、既知の攻撃であるタイポスクワッティングと並べることです。両者は「偽パッケージを公開レジストリに置いて踏ませる」という結果は同じですが、引き金を引くのが誰かが決定的に違います。
| 観点 | タイポスクワッティング | スロップスクワッティング |
|---|---|---|
| 誤りの主体 | 人間のタイプミス（reqeusts等） | LLMの幻覚（存在しない名前の創作） |
| 攻撃者の予測対象 | よくある打ち間違い | AIがよく創作する”それらしい”名前 |
| 被害者の心理 | うっかり | AIの提案への信頼 |
| 標準フレームワーク | 依存混同（Dependency Confusion）の一種 | パッケージ・ハルシネーションを起点とする新種 |
「slop（雑なAI生成物）」＋「squatting（不法占拠）」という造語が示す通り、これはAIの幻覚そのものに寄生する攻撃です。汚染パッケージ全般を扱った従来のサプライチェーン攻撃と異なり、攻撃の起点が「LLMの予測可能な誤り」にある点が新しいのです。
攻撃のライフサイクル——3つのステップ
スロップスクワッティングは、次の3段階で成立します。
- ①幻覚（Hallucination）： 開発者がLLMにコードを書かせると、出力に実在しないパッケージ名が混じる。LLMは確率的にもっともらしいトークンを並べるだけで、「そのパッケージが本当に存在するか」を検証する仕組みを持たないため、自然に起こる。
- ②先回り登録（Pre-registration）： 攻撃者は多数のLLMに同じような質問を投げ、繰り返し幻覚される名前を収集する。それらの名前を、自分が作った悪意あるパッケージとしてnpm／PyPIに事前登録しておく。
- ③拡散（Propagation）： 別の開発者が同じ幻覚を引き当て、提案された名前を疑わずに
installする。インストール時のスクリプトやランタイムでマルウェアが実行され、コードベース全体・認証情報・CI環境が侵害される。
重要なのは、②が「当て推量」ではなく再現性に裏打ちされている点です（詳細は次章のデータで示します）。攻撃者は膨大なプロンプトログを盗む必要はなく、自分でLLMを叩いてよく幻覚する名前を観測し、登録するだけで済みます。
NOC/TAC的に見る——「権威のない名前解決を信じる」構図
この攻撃の骨格は、ネットワークエンジニアには既視感があります。DNSの世界では、正当な権威サーバーから返ってきたのか、それとも汚染されたキャッシュや偽の応答なのかを検証しないと、ユーザーは平然と偽のIPへ誘導されます。タイポスクワットされたドメインを信じてフィッシングサイトに繋いでしまうのも同じ構図です。
スロップスクワッティングでは、LLMという”権威のない名前解決器”が返した名前を、開発者が検証せずに信じてしまう。NOC/TACの鉄則「名前は解決される前に、その出所と正当性が検証されねばならない」を、パッケージのインストールにそのまま適用するのが本記事の防御方針です。
データで見る深刻度——19.7%が幻覚、しかも”再現性が高い”
2025年4月、Python Software FoundationのSeth Larson氏がこの現象を「スロップスクワッティング」と命名しました。同時期に、テキサス大学サンアントニオ校・バージニア工科大学・オクラホマ大学の研究チームが大規模な実証論文（”We Have a Package for You!”）を公開しています。主要な数字を押さえておきましょう。
| 指標 | 数値 | 意味 |
|---|---|---|
| 幻覚率（全体） | 約19.7% | LLMが推奨したパッケージの約5分の1が実在しない |
| 商用モデル | 約5.2% | GPT系など。相対的に低いが無視できない |
| オープンソースモデル | 約21.7% | CodeLlama等。一部は出力の3分の1超が幻覚 |
| ユニークな幻覚名 | 20万5千以上 | 攻撃者が登録しうる”空き枠”の規模 |
| 再現率（同一プロンプト10回） | 43%が毎回・58%が複数回 | 幻覚名は予測可能＝先回り登録が現実的 |
最も警戒すべきは再現性です。同じプロンプトを10回繰り返したとき、幻覚名の43%は毎回同じ名前が出現し、58%は複数回出現したと報告されています。つまり攻撃者にとって、どの名前を登録すれば踏ませやすいかは安定して予測可能なのです。さらに幻覚名の多くは実在パッケージと似た命名構造を持ち、単純な打ち間違い（off-by-oneのタイポ）はごく一部に過ぎません。”それらしさ”こそが危険を高めています。
実例として、2023年にはセキュリティ研究者が、LLMがよく幻覚するhuggingface-cliという名前で空のパッケージを登録したところ、3か月で3万回以上ダウンロードされた事例が報告されています（正しくはhuggingface_hub[cli]）。攻撃者が悪意を込めていれば、それだけの環境が侵害され得たということです。
なお、LLMはtemperature（出力のランダム性）が高いほど幻覚が増える傾向も確認されています。これは後述するプロンプト側の予防に直結する重要な性質です。
なぜ既存のSCA（ソフトウェア構成分析）では漏れるか
「うちはSCAツールや脆弱性スキャナを入れているから大丈夫」と考える方も多いはずです。しかしスロップスクワッティングは、従来型のSCAの設計思想の隙間を突いてきます。理由を整理します。
- 既知脆弱性のDBに載っていない： 多くのSCAは「既知のCVEや既知の悪性パッケージ」と照合します。攻撃者が今日登録したばかりの新規パッケージは、まだDBに存在しません。
- “存在する”こと自体は正常： 攻撃者が先回り登録した時点で、そのパッケージはレジストリに実在します。「存在しないものを弾く」発想のチェックでは引っかかりません。
- 導入の経緯を見ない： SCAは依存ツリーの構成は見ても、「その依存がAIの提案で・人間の検証なしに入った」という来歴までは追いません。スロップスクワッティングはまさにこの来歴に弱点があります。
- インストール時実行を取りこぼす： npmの
postinstall等、インストール段階で走る悪性コードは、ビルド後のスキャンより前に被害を出します。
ネットワークに例えるなら、SCAは「既知のブラックリストIPを弾くファイアウォール」です。有効ですが、まだブラックリスト入りしていない新規の攻撃元や、正規に見える経路を通る通信は素通りします。だからこそ、後述する「正規ルートそのものを許可リストで縛る」「導入前に正当性を検証する」ゼロトラスト的な多層防御が必要になります。
第1の防御層：ロックファイル＆バージョンピン留め
最も基本かつ即効性が高いのが、依存関係の固定（ピン留め）とロックファイルの厳格運用です。これは「一度検証して安全と確認したものだけを、寸分違わず再現する」という発想で、ネットワークでいえば承認済み構成のスナップショットを取り、それ以外への変動を許さない運用に相当します。
- ロックファイルを必ずコミットする：
package-lock.json／poetry.lock／requirements.txt（ハッシュ付き）をリポジトリに含め、チーム全員・CIが同一の依存を再現できるようにする。 - ハッシュ検証を有効化する： pipの
--require-hashesやnpmのnpm ci（lockファイル厳守・改変時はエラー）を使い、名前ではなく中身のハッシュで正当性を確認する。たとえ名前が一致しても中身が差し替わっていれば弾ける。 - CIではクリーンインストールを徹底：
npm installではなくnpm ciを使い、ロックファイルと完全一致しない限り失敗させる。 - 新規依存の追加を”イベント化”する： ロックファイルの差分はPRレビューで必ず目視確認する。新しいパッケージ名が増えたら、それが本当に実在・正当かを人間がレビューする関門を設ける。
ピン留めとハッシュ検証は、スロップスクワッティングに対して特に効きます。なぜなら、AIが新たに幻覚した名前はロックファイルに載っていないため、無検証では本番に入り込めなくなるからです。
第2の防御層：社内許可リスト／プライベートレジストリ
ピン留めが「過去に承認したものを再現する」防御なら、許可リストは「そもそも何を入れてよいかを事前に定義する」ゼロトラスト的な防御です。ネットワークの明示的許可（デフォルト拒否）と同じ思想です。
- プライベートレジストリ／プロキシを置く： Verdaccio、JFrog Artifactory、GitHub Packages、AWS CodeArtifactなどを社内に立て、開発者は公開レジストリへ直接アクセスせず、このプロキシ経由でのみ取得する構成にする。
- 許可リスト方式で運用する： 監査・承認済みのパッケージだけをミラー／キャッシュし、未登録の新規パッケージは申請・審査を経て初めて取得可能にする。AIが幻覚した名前は、この関門で自動的に止まる。
- 依存混同（Dependency Confusion）も同時に防ぐ： 社内パッケージ名のスコープを予約し、外部レジストリの同名パッケージより内部を優先する設定にする。スロップスクワッティングと依存混同は地続きの脅威なので、まとめて対策できる。
- 段階導入の現実解： いきなり全社プロキシが難しい場合は、まず本番ビルドのCIだけを許可リスト化されたレジストリに向け、開発時の自由な探索と本番の厳格さを分離する。
許可リストの本質は、「LLMが何を言おうと、許可リストにない名前はネットワークの外に出られない」という構造的な遮断です。検知に頼る前に、そもそも到達させない——これがゼロトラストの強みです。
第3の防御層：インストール前の存在確認・署名検証をCIに組む
第1・第2層をすり抜ける変則ケースに備え、インストールの直前に正当性を能動的に検証する関門をCI/CDに組み込みます。これはNOCでいう「名前解決の前に、レコードの権威性・整合性をチェックする」工程の実装です。
- パッケージの”素性”を確認する： インストール対象の各パッケージについて、レジストリ上の公開日・メンテナ・ダウンロード実績・ソースリポジトリの有無を自動チェックする。「数日前に登録・作者不明・実績ゼロ・リポジトリなし」は赤信号として人手レビューへ回す。
- 署名・来歴（provenance）の検証： Sigstore／npm provenance、PyPIのTrusted Publishing（OIDC）など、「正規のCIから・正規のソースで公開された」ことを暗号的に検証する仕組みを使う。署名のないパッケージは原則ブロック。
- SBOMを生成・保全する： ビルドごとにSBOM（部品表）を出力し、「いつ・どの依存が・どの経路で入ったか」を改ざん不能なログとして残す。事後の追跡と影響範囲特定の根拠になる。
- インストール時スクリプトを抑制する： 可能な範囲で
--ignore-scriptsを使い、postinstall等の自動実行を止める。実行が必要なものだけを明示的に許可する。 - サンドボックスで先に実行する： 新規依存は隔離環境でまず動かし、想定外の外部通信やファイルアクセスがないかを観測してから本番に昇格させる。
これらは「観測→警告→遮断」というNOCのインシデント対応の階段と同じです。怪しい素性のパッケージをいきなり全部止めるのではなく、赤信号を検知したら人手レビューへ、明確な悪性はブロックという段階設計にすると、開発速度を殺さずに守れます。
プロンプト側の予防——AIにコードを提案させるときの設計
これまでは「AIが幻覚した後」をどう食い止めるかでした。最後に、そもそも幻覚を引き当てにくくする入口側の工夫を挙げます。AI駆動のアプリ開発を日常的に行う層にこそ効く実務的な対策です。
- 「実在するパッケージのみ」を明示的に指示する： プロンプトで「実在が確認できるパッケージのみを使い、不確かなものは明記せよ」と制約する。AIに”わからない”と言わせる余地を作るだけで、堂々とした捏造が減る。
- temperatureを下げる： コード生成では出力のランダム性を低めに設定する。高temperatureほど幻覚が増えることが実証されているため、確実性を優先する場面では決定論寄りにする。
- 依存を”確定させない”運用にする： AIには実装ロジックを書かせ、パッケージの選定は人間または許可リストが行うと役割を分ける。import文はレビューの必須対象とする。
- 提案された名前を即座に検証する： AIが挙げた各パッケージを、
install前にレジストリ上で存在・実績・公式リポジトリの有無まで確認する習慣をチームの規範にする。 - AI出力を”未検証入力”として扱う： AI生成コードのセキュリティ全般と同じく、LLMの出力は信頼境界の外から来た入力とみなし、検証を通してから初めて取り込む。
多層防御チェックリスト
| 層 | 対策 | 主に効くポイント |
|---|---|---|
| 入口 | プロンプトで実在パッケージのみ指示・temperature低減 | 幻覚の発生そのものを抑制 |
| 入口 | AI出力を未検証入力として扱う・import文を必ずレビュー | 無検証導入の防止 |
| 固定 | ロックファイルのコミット・バージョンピン留め | 未承認の新規依存の混入防止 |
| 固定 | ハッシュ検証（--require-hashes／npm ci） | 名前一致でも中身差し替えを検知 |
| 遮断 | プライベートレジストリ＋許可リスト | 未登録パッケージへの到達を構造的に遮断 |
| 遮断 | 社内スコープ予約（依存混同対策） | 同名すり替えの防止 |
| 検証 | インストール前の素性チェック（公開日・作者・実績） | 先回り登録された新規悪性パッケージの検出 |
| 検証 | 署名・provenance検証（Sigstore／Trusted Publishing） | 正規ソース由来であることの確認 |
| 検証 | --ignore-scripts・サンドボックス実行 | インストール時実行による被害の抑制 |
| 記録 | SBOM生成・改ざん不能ログ | 事後追跡・影響範囲特定の根拠 |
よくある質問（Q&A）
Q1. SCAツールや脆弱性スキャナを入れていれば防げますか？
不十分です。多くのSCAは「既知の悪性パッケージや既知のCVE」と照合しますが、攻撃者が先回り登録したばかりのパッケージはまだDBに載っておらず、しかもレジストリ上に”実在”しています。「存在しないものを弾く」発想のチェックでは引っかかりません。ロックファイル・許可リスト・インストール前検証という、来歴と正当性に踏み込んだ多層防御が必要です。
Q2. 商用モデル（GPT系など）を使っていればハルシネーションは起きませんか？
頻度は下がりますが、ゼロにはなりません。研究では商用モデルでも約5.2%のパッケージが幻覚でした。20回に1回でも、AI生成コードを大量に扱えば確実に踏む機会は訪れます。モデルの選択は緩和策であって、防御策の代替にはなりません。
Q3. 攻撃者はどうやって”登録すべき名前”を知るのですか？
盗み見る必要はありません。攻撃者は自分でLLMに同じような質問を繰り返し、よく出てくる幻覚名を観測するだけで足ります。研究では同一プロンプトの再実行で43%の幻覚名が毎回再現したと報告されており、どの名前を登録すれば踏ませやすいかは安定して予測できてしまいます。再現性の高さこそ、この攻撃を現実的にしている要因です。
Q4. ロックファイルさえあれば十分ですか？
強力ですが単独では不十分です。ロックファイルは「一度承認したものを再現する」防御なので、最初に幻覚パッケージを承認してしまうと、その後は忠実に再現してしまいます。だからこそ、新規依存の追加時にPRレビューで目視確認し、許可リストやインストール前の素性チェックと組み合わせることが重要です。
Q5. 個人開発でも対策は必要ですか？
必要です。むしろClaude Code／Cursorで高速に開発する個人開発者ほど、AIの提案をそのままinstallしやすく、リスクに直結します。全社プロキシのような重い仕組みは要りませんが、（1）ロックファイルのコミットとハッシュ検証、（2）AIが挙げたパッケージ名をinstall前にレジストリで実在確認する習慣、（3）temperatureを下げる——この3つだけでも被害確率は大きく下げられます。
まとめ——「AIの提案は未検証の名前解決」と捉える
スロップスクワッティングは、AIコーディング時代に固有の新しいサプライチェーン攻撃です。要点は3つに集約されます。
1. 攻撃の起点はAIの幻覚そのもの。 LLMが堂々と提案する”存在しないパッケージ名”を、攻撃者が先回り登録して踏ませる。しかもその名前は再現性が高く、予測可能です。
2. 既存のSCAでは漏れる。 先回り登録されたパッケージは”実在”し、既知DBにも載っていないため、ブラックリスト型の防御をすり抜けます。だからこそ、許可リスト・ピン留め・インストール前検証というゼロトラスト的な多層防御が要ります。
3. NOC/TACの発想がそのまま効く。 「名前は解決される前に、その出所と正当性を検証する」——DNSやルーティングで培われた原則を、パッケージのインストールに適用するだけです。AIの提案は、権威のない名前解決器が返した未検証の入力として扱う。これが、バイブコーディングを安全に続けるための基本姿勢です。
参考リンク
- Slopsquatting（Wikipedia）
- Socket「Slopsquatting: How AI Hallucinations Are Fueling a New Class of Supply Chain Attacks」
- OWASP Top 10 for LLM Applications（2025年版）
- Python Software Foundation セキュリティ情報
免責事項： 本記事は2026年6月時点の公開情報および研究報告に基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の防御実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家にご相談ください。ツールやレジストリの仕様・統計は更新されるため、最新情報は各公式ソースでご確認ください。
コメント