パッケージハルシネーション攻撃（Slopsquatting）とは — AIコーディング時代の新しいサプライチェーンリスクと防御策

AIにコードを書かせたら、存在しないパッケージを npm install するよう提案された——この経験、心当たりはないでしょうか。

実はこの「AIのうっかりミス」が、サプライチェーン攻撃の新しい入口になっています。攻撃者がAIの生成する架空パッケージ名を先回りして登録し、悪意あるコードを仕込む手口。これがSlopsquatting（スロップスクワッティング）、別名パッケージハルシネーション攻撃です。

この記事では、Slopsquattingの仕組み・公開されている実証事例や前兆・開発者と組織が今すぐ取るべき防御策を、実務目線で整理します。あわせて、axios 汚染版のような正規パッケージの公開経路が侵害される事故も踏まえ、AIコーディング時代の依存防衛をもう一段運用寄りに考えます。

Slopsquattingとは何か

Slopsquattingは、Python Software FoundationのSecurity Developer in ResidenceであるSeth Larsonにより広く知られるようになった呼び方です。従来のtyposquatting（タイポスクワッティング）が「人間の打ち間違い」を狙うのに対し、Slopsquattingは**「AIの幻覚（ハルシネーション）」を狙います**。

攻撃の流れはシンプルです。

LLMが架空のパッケージ名を生成する — express-mongoose、react-codeshift のように、実在しそうな名前をもっともらしく提案する
攻撃者がその名前でパッケージを登録する — npm、PyPIなどのレジストリに悪意あるコードを仕込んだパッケージを公開する
開発者がAIの提案をそのままインストールする — npm install や pip install で悪意あるパッケージが本番環境に入り込む

typosquattingとの決定的な違いは、攻撃の再現性が高いことです。USENIX Security 2025で発表予定の研究では、16のLLMを対象に576,000件のコードサンプルを生成したところ、同じプロンプトを10回繰り返したとき43%の幻覚パッケージが10回すべてで再現され、58%は2回以上再現されました。つまり攻撃者は「どのパッケージ名が狙い目か」を事前に予測できます。

どのくらい発生しているのか — 数字で見る実態

研究データは問題の深刻さを示しています。

生成されたパッケージ推薦の19.7% が存在しないものだった（全LLM平均）
オープンソースモデル: 21.7% vs 商用モデル: 5.2% のハルシネーション率
GPT-4 Turboで最低3.59%、CodeLlama 7Bでは35.71%
ハルシネーションされた名前の 58%が複数回の実行で再現 される
20万件以上のユニークな架空パッケージ名が観測済み

ハルシネーションのパターンにも傾向があります。

パターン	割合	例
純粋な捏造	51%	実在しない名前をゼロから生成
既存パッケージの合成	38%	`express` + `mongoose` → `express-mongoose`
タイポ変種	13%	実在パッケージ名の微妙な変形

特に「既存パッケージの合成」パターンは厄介です。react-codeshift（実在するのは jscodeshift と react-codemod）のように、開発者が見ても「ありそう」と感じる名前が生成されるため、疑いを持ちにくくなります。

公開されている実証・前兆事例

`huggingface-cli` 実証事例

セキュリティ研究者のBar Lanyado氏は、複数のLLMが繰り返し huggingface-cli という存在しないPythonパッケージを推奨していることを発見しました。そこで氏は無害なダミーパッケージをPyPIに登録して挙動を検証し、3か月で30,000回超の実ダウンロードを確認しました。

さらに、Alibabaを含む複数の企業リポジトリに、このハルシネーション由来のインストール例が転載されていたことも報告されています。これは「AIが幻覚した名前でも、実際に人間やシステムがインストールする」ことを示した実証です。

`react-codeshift` の拡散事例（2026年1月）

Aikido SecurityのCharlie Eriksen氏が報告したこの事例は、AIエージェント時代の危険性を象徴しています。react-codeshift というnpmパッケージ名は実在しませんでしたが、AI生成とみられるGitHub上のエージェントスキル記述に含まれた結果：

237のリポジトリにフォーク経由で拡散
日本語翻訳版にも伝播
AIエージェントが自動的にダウンロードを試行 し続けたとみられる

現時点で大規模な実害が確認された攻撃そのものではありませんが、人間が介在しないAIからAIへの伝播が起こりうることを示す前兆事例です。

`unused-imports` の悪性パッケージ事例

eslint-plugin-unused-imports と混同しやすい unused-imports という悪意あるnpmパッケージも報告されています。Aikidoは、2026年2月時点でも週233回のダウンロードが続いていたと説明しており、AIの過去の推奨や古い記述が長く残存しうることを示しています。ただし、これが意図的な slopsquatting だったかどうかまでは公開情報だけでは断定できません。

架空パッケージだけ見ていると足りない

ここで一つ、視野を広げる必要があります。AIコーディング時代のサプライチェーン防衛は、架空パッケージを踏まないだけでは不十分です。2026年3月末の axios 汚染版のように、正規パッケージの公開経路そのものが侵害されるケースもあります。

この種の事故が示しているのは次の3点です。

正規名だから安全 ではない
patch バージョンだから安全 でもない
GitHub でソースが普通に見えるから安全 でもない

Slopsquatting と axios 事故は入口が違います。前者は AI が存在しない名前を提案する 問題で、後者は 正規パッケージの配布面が侵害される 問題です。ただ、防御原則はかなり重なります。どちらも、依存追加・依存更新・install script 実行・CI secrets の露出 が実害の起点になるからです。

つまり、AIコーディング時代の防御は「名前を確認する」だけで終わりません。公開直後の版をすぐ踏まない、install script を既定で信用しない、信頼証跡の劣化を見る、踏んだ後はインシデントとして扱う まで含めて考える必要があります。

なぜバイブコーディングで特に危険なのか

バイブコーディングの脆弱性チェックリストでも解説しましたが、AIにコードを「おまかせ」するスタイルでは、生成されたコードのレビューが甘くなりがちです。Slopsquattingのリスクは、特に以下の状況で跳ね上がります。

1. AIエージェントが自律的にパッケージをインストールする場合

Claude CodeのAuto Modeや他のAIコーディングツールが npm install を自動実行する設定になっていると、人間のレビューを経ずに悪意あるパッケージが入り込みます。

2. 初見の技術スタックで作業する場合

馴染みのないエコシステムでは、AIが提案するパッケージ名が正しいかどうか判断できません。「それっぽい名前だから大丈夫だろう」が最大のリスクです。

3. プロトタイピングや個人開発で「とりあえず動けばいい」場合

本番環境ではないからと油断しますが、postinstall スクリプトは npm install の時点で実行されます。APIキー、クラウドトークン、npmの認証トークンが窃取される可能性があります。

開発者が今すぐやるべきこと

まず優先すべきなのは、次の4つです。

AIが提案したパッケージ名をレジストリで確認する
AIエージェントの自動インストール権限を絞る
lockfile と CI で依存関係を固定する
公開直後の版と install script を既定で警戒する

この4つだけでも、Slopsquattingや正規パッケージ汚染を踏み抜くリスクはかなり下げられます。そのうえで、補強策としてSCAやSBOM管理を追加するのが現実的です。

1. AIが提案したパッケージは必ずレジストリで確認する

最もシンプルで効果的な対策です。npm install する前に、npmjs.comやpypi.orgでパッケージの存在・作成日・メンテナ情報を確認しましょう。

# npmパッケージの情報を確認
npm info <package-name>

# 存在しないパッケージならエラーになる
# 存在する場合も、作成日・ダウンロード数・メンテナを確認

ダウンロード数だけで判断するのは危険です。huggingface-cli は30,000回ダウンロードされていましたが、それ自体がハルシネーション起因のインストールでした。作成日とメンテナ情報が信頼性の判断基準になります。

2. AIエージェントのパッケージインストール権限を制限する

OpenClawのセキュリティ設計でも解説しましたが、AIエージェントがパッケージを自律的にインストールできる状態は、Slopsquattingの攻撃対象面を最大化します。

--dangerously-skip-permissions を使わない
Auto Modeでも Bash ツールの実行前確認を有効にする
CI/CDパイプラインでは、パッケージインストールを許可リスト制にする

3. ロックファイルをコードレビューの対象にする

package-lock.json、pnpm-lock.yaml、Pipfile.lock は単なる自動生成ファイルではなく、サプライチェーンの防衛線です。

# CIでは必ず ci コマンドを使う（lockfileの整合性を強制）
npm ci        # npm
pnpm install --frozen-lockfile  # pnpm
pip install -r requirements.txt --require-hashes  # pip（ハッシュ付き requirements 前提）

PRレビューでロックファイルの差分を確認する習慣が、未知のパッケージ混入を防ぎます。

4. 公開直後の版をすぐ入れない

axios の汚染版のような事故は、公開から短時間で発見・削除されることがあります。つまり、公開直後の版を自動で踏まないだけでも被弾率は下げられます。

ただし、npm の min-release-age は npm 11.10.0 以降 の機能です。npm 10 系や古い npm 11 系ではそのまま使えません。

# npm 11.10.0+
npm config set min-release-age 3

# pnpm 10.16.0+
minimumReleaseAge: 1440

pnpm の minimumReleaseAge は pnpm 10.16.0 以降 の設定です。pnpm なら分単位で制御できます。全依存を何日も遅らせる必要はありませんが、少なくともCIや本番寄りの環境では「公開直後の版をそのまま入れない」設定を検討する価値があります。npm 側の設定や pnpm 側の設定が使えないバージョンなら、更新 bot 側の cooldown や、CI での手動承認フローで代替するのが現実的です。

5. install script を既定で信用しない

postinstall は、存在しないパッケージでも正規パッケージの汚染でも、実害の起点になりやすいです。依存にコード実行権限を渡しているという前提で扱うべきです。

# npm
npm ci --ignore-scripts

# pnpm 10.1.0+
pnpm approve-builds

pnpm approve-builds は pnpm 10.1.0 以降 のコマンドです。pnpm approve-builds と onlyBuiltDependencies を使えば、どの依存のビルドスクリプト実行を許可したかを設定として残せます。AIコーディング環境では、この明文化が重要です。古い pnpm を使っているなら、少なくとも CI 側で ignore-scripts 相当の制御や、依存追加時の手動レビューを強める必要があります。

6. CLAUDE.mdやHooksでパッケージインストールにガードレールを設ける

Claude Codeを使っている場合、settings.json のHooksでパッケージインストール前に明示的な確認や拒否を挟めます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.command' | grep -qE '^(npm install|pnpm add|pip install)\\b' && jq -n '{hookSpecificOutput:{hookEventName:\"PreToolUse\",permissionDecision:\"ask\",permissionDecisionReason:\"パッケージ追加前にレジストリで存在・作成日・メンテナを確認してください\"}}' || exit 0"
          }
        ]
      }
    ]
  }
}

また、CLAUDE.mdに以下のようなルールを書いておくことも有効です。

## 依存関係の追加ルール

- 新しいパッケージを追加する前に、npmjs.com で存在・メンテナ・作成日を確認すること
- 作成から30日未満、または週間ダウンロード数100未満のパッケージは使用禁止
- パッケージ追加時は理由をコミットメッセージに明記すること

7. Trusted Publishing や信頼証跡の劣化を見る

正規パッケージ事故では、いつもの公開経路から外れた版 が強い異常信号になることがあります。利用者側が毎回完全に追うのは難しくても、次の観点を知っておく価値はあります。

npm の Trusted Publishing / OIDC
npm の registry signatures
pnpm の trustPolicy

特に pnpm の trustPolicy: no-downgrade は、pnpm 10.21.0 以降 で使える設定で、以前より弱い信頼証跡で公開された版を拒否できます。AI起点の架空パッケージ対策とは別に、正規パッケージの公開経路劣化を見る防御線 として有効です。古い pnpm では効かないので、そこは lockfile レビューや CI 側の追加検査で補うべきです。

8. 踏んだ後は依存問題ではなくインシデントとして扱う

AI提案の偽パッケージでも、汚染された正規パッケージでも、postinstall を実行した時点で依存問題ではなく 端末やCIの侵害事故 として扱うべきです。

パッケージを消して終わりにしない
CI で使った secrets は漏えい前提でローテーションする
開発端末は再構築判断まで含めて考える
lockfile と CI ログを確認して影響範囲を切る

この初動を決めていないチームは、技術力の問題ではなく判断の遅さで被害を広げます。

9. SCAツールで依存関係ツリー全体をスキャンする

直接の依存関係だけでなく、推移的依存関係（依存の依存）にも悪意あるパッケージが潜む可能性があります。

Socket.dev — npm/PyPIパッケージのリスクスコアをリアルタイム評価
Snyk — 既知の脆弱性＋サプライチェーンリスクを検出
npm audit — 基本的な脆弱性チェック（無料）
Socket CLI — socket npm / socket npx でインストール時のスキャンを補助

# 基本的なセキュリティ監査
npm audit

# Socket.dev によるインストール前スキャンの例
socket npm install <package-name>

組織として取るべき対策

個人の注意力だけに頼る防御は限界があります。チームや組織レベルでは、以下の仕組みを整えましょう。

依存関係の許可リスト

検証済みパッケージのみインストール可能なプライベートレジストリを導入します。Verdaccio（npm）やDevPI（Python）で社内プロキシを立てれば、未検証パッケージのインストールを構造的に防げます。

SBOM（ソフトウェア部品表）の管理

npm sbom や syft でSBOMを生成し、プロジェクトの依存関係を可視化します。新しい依存関係が追加された際に自動でアラートを出す仕組みと組み合わせると効果的です。

AIコーディングツールの社内ガイドライン

「AIが提案したパッケージは無条件に信頼しない」をルール化し、レビューチェックリストに組み込みます。これは単なるセキュリティ対策ではなく、AI活用の成熟度を上げるプロセスです。雛形から作りたい場合は、AIコーディングツールの社内ガイドラインでテンプレと判断基準をまとめています。

まとめ — 「AIが言ったから」を信じない習慣

Slopsquattingは、AIコーディングツールの普及とともに現実的な脅威になっています。2026年3月時点で公開されているのは主に実証・前兆事例ですが、AIエージェントが自律的にコードを書く時代には、攻撃対象面はさらに広がります。

防御の基本は技術的に難しいものではありません。

AIが提案したパッケージ名をレジストリで確認する
公開直後の版をすぐ踏まない
install script とロックファイルを防衛線として扱う
AIエージェントのインストール権限を制限する
踏んだ後は secrets ローテーションまで含めて対応する

「AIが言ったから正しい」ではなく、「AIが言ったからこそ確認する」。この習慣が、あなたのプロジェクトをサプライチェーン攻撃から守ります。