「AI が import しろと書いたパッケージを、npm install したらマルウェアだった」――2026 年、これは机上の空論ではなく、現実に起こりうる攻撃です。 AI コーディング支援ツールは、ときに実在しないパッケージ名をさも本物のように提案します。この現象を パッケージ幻覚（package hallucination） と呼びます。問題は、その幻覚が毎回バラバラではなく、同じ名前が繰り返し出てくることがある点です。攻撃者はその「よく幻覚される名前」を先に調べ上げ、npm や PyPI に悪意あるパッケージとして先回り登録しておく。開発者が AI の提案を信じてインストールした瞬間、攻撃が成立します。
この攻撃手法は slopsquatting（スロップスクワッティング） と呼ばれます。「AI slop（AI が出す雑な出力）」と「typosquatting（タイポスクワッティング）」を組み合わせた造語で、Python Software Foundation のセキュリティ専門家 Seth Larson 氏が 2025 年に名付けたとされます。タイプミスではなく、AI の幻覚そのものを攻撃の入口にする――これが AI 時代に新しく生まれたサプライチェーン攻撃の形です。
連載「バイブコーディング危機」は、第 11 回（AI 生成コードのセキュリティスキャン（SAST/DAST/SCA））・第 13 回（OSS ライセンス混入リスク）・第 15 回（シークレット/API キー漏洩）と「防衛策の実装編」を進めてきました。本記事・第 17 回は、その中でも**依存パッケージ（サプライチェーン）**に焦点を当て、パッケージ幻覚と slopsquatting への現実的な備えを整理します。
なお本記事は、公開されている研究・公式情報をもとにした一般的な注意喚起です。具体的な攻撃事例の固有名や被害額は、報道・公表ベースで確認できたもののみを記載し、確認できない数値は使いません。
目次
- パッケージ幻覚（package hallucination）とは
- slopsquatting とは：幻覚を攻撃の入口にする
- なぜAIコード生成でパッケージ幻覚が起きるのか
- 攻撃の流れ：幻覚名→悪意登録→自動実行
- typosquatting との違い
- 中堅企業の対策：8つの防御層
- 中堅企業向けチェックリスト（30分）
- いつGXOに相談すべきか
- よくある質問（FAQ）
- 参考一次ソース
- まとめ
- 関連記事
パッケージ幻覚（package hallucination）とは
パッケージ幻覚とは、AI コーディング支援ツール（LLM）が、コードを生成する際に実在しないパッケージ（ライブラリ）名を、あたかも実在するかのように提案してしまう現象です。たとえば「画像をリサイズしたい」と頼むと、もっともらしい名前のパッケージを import するコードを返してくるが、その名前で npm install や pip install を実行すると「そんなパッケージは無い」と返ってくる――というケースです。
どのくらいの頻度で起きるのか
この現象を大規模に測定した研究として、USENIX Security 2025 で発表された **Spracklen らの論文「We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs」**があります。この研究では、複数の LLM（16 モデル）に Python・JavaScript のコードを大量生成させ、提案されたパッケージのうちどれだけが実在しないかを調べています。報告されている主な数値は次のとおりです（出典は参考一次ソース）。
| 観点 | 研究で報告された値 |
|---|---|
| 生成コードサンプル中、幻覚パッケージを含んだ割合 | 約 19.7%（全体平均） |
| 商用（プロプライエタリ）モデルの平均幻覚率 | 約 5.2% |
| オープンソースモデルの平均幻覚率 | 約 21.7% |
| 検出されたユニークな幻覚パッケージ名の数 | 205,474 件 |
つまり、おおよそ 5 回に 1 回のコード生成で、何らかの実在しないパッケージ名が紛れ込む可能性があるという報告です（モデルや条件により大きく差があり、商用モデルでは相対的に低い傾向と報告されています）。重要なのは、これがまれな珍事ではなく、構造的・継続的に起こる現象として報告されている点です。
「同じ名前」が繰り返し出てくることが問題
さらにこの研究では、幻覚されたパッケージ名がランダムにバラけるのではなく、同じ名前が繰り返し出現する傾向があると報告されています。同じプロンプトを繰り返したとき、一定割合の幻覚名が再現的に出てくる――この「再現性」こそが、後述する slopsquatting 攻撃を成立させる土台になります。攻撃者にとっては、「どの名前を登録すれば、被害者が引っかかるか」が予測可能になってしまうからです。
要点：パッケージ幻覚は AI の「うっかり」だが、その名前に再現性があるため、攻撃者が悪用できる「予測可能な穴」になりうる。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
情シス部門の稟議書作成をサポートする無料の30分壁打ち。ROI 試算シート・失敗要因チェックリストをその場で共有します。
slopsquatting とは：幻覚を攻撃の入口にする
slopsquatting とは、AI が幻覚として繰り返し提案する実在しないパッケージ名を、攻撃者が先回りして npm / PyPI などのレジストリに（悪意あるコードとともに）登録しておく攻撃手法です。
この用語は、Python Software Foundation の Developer-in-Residence でありセキュリティ専門家でもある Seth Larson 氏が 2025 年に名付けたとされています（その後、複数のセキュリティベンダーや報道で広く使われるようになりました）。「AI slop（AI が吐き出す雑で当てにならない出力）」と「typosquatting」を掛け合わせた語です。
実際に「幻覚名を登録したら使われた」例
slopsquatting の危険性を示す先行事例として、しばしば引用されるのが huggingface-cli のケースです。セキュリティ研究者 Bar Lanyado 氏が 2023 年に、LLM が huggingface-cli という（実在しない）パッケージ名を繰り返し幻覚することに気づき、検証のため空のパッケージを同名で PyPI に登録しました。報告によれば、この空パッケージは3 ヶ月で 3 万件超のダウンロードを記録したとされます。これは攻撃ではなく研究目的の検証でしたが、「AI が幻覚した名前を登録しておけば、開発者が実際にインストールしてくる」という攻撃シナリオが現実的に成立することを示した、しばしば引用される実証例です。
なお、正しい HuggingFace の CLI は pip install -U "huggingface_hub[cli]" でインストールされるものであり、huggingface-cli という単独パッケージ名は本来の正規パッケージではありません。AI は「コマンド名」と「パッケージ名」を混同して、もっともらしい別名を作ってしまったわけです。
注記：この huggingface-cli の事例は、特定企業への攻撃事例ではなく、研究者による**概念実証（PoC）**として報告されたものです。バイブコーディング（AI に任せきりの開発）が直接の原因と断定するものではなく、専門家のチェックが薄い環境で同種リスクが顕在化しやすいという警鐘として参照します。
なぜAIコード生成でパッケージ幻覚が起きるのか
パッケージ幻覚は、LLM の仕組みに由来する構造的な現象です。バイブコーディングのスピード感が、これを増幅します。
理由1：LLM は「もっともらしさ」で出力する
LLM は、レジストリに問い合わせて「実在するか」を確認してから名前を出すわけではありません。学習した膨大なコードのパターンから、**統計的にもっともらしい次の単語（トークン）**を並べて出力します。そのため、「いかにもありそうだが実在しない」名前を、自信たっぷりに提示してしまうことがあります。
理由2：名前の「合成」と「混同」が起きる
研究では、幻覚パッケージには一定のパターンがあると報告されています。報告されている分類の例として、実在する 2 つの名前を混ぜ合わせた合成（例：express と mongoose を混ぜたような名前）、綴り違い（typo 的なバリエーション）、そして**完全な創作（fabrication）**などが挙げられています。先ほどの huggingface-cli も、コマンド名とパッケージ名を取り違えた「混同」型の一例といえます。
理由3：「動いたら正しい」とは限らない
バイブコーディングでは、「とりあえず動いたら採用」という進め方になりがちです。しかし、幻覚パッケージが攻撃者によって既に登録されていた場合、インストールは成功し、コードも一見動いてしまう――つまり「動いた」が安全の証明にはなりません。第 11 回のセキュリティスキャンで扱ったとおり、「動く」と「安全」は別物です。
理由4：確認の省略が積み重なる
AI の提案する import 文を、一つひとつ「この名前は本当に実在する正規パッケージか」と確認するのは手間です。スピードを優先するほど、この確認が省略され、素性不明のパッケージが依存ツリーに紛れ込むことになります。
要点：パッケージ幻覚は AI の能力不足というより、LLM の出力の仕組み（もっともらしさで生成する）に由来する構造的な現象。だからこそ「人の確認」と「仕組みでの防御」の両方が要る。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
攻撃の流れ：幻覚名→悪意登録→自動実行
slopsquatting がどのように被害につながるのか、典型的な流れを段階で整理します。
ステップ1：攻撃者が「よく幻覚される名前」を収集する
攻撃者は、複数の AI モデルにさまざまなコード生成を依頼し、どんな実在しないパッケージ名が、繰り返し提案されるかを観察・収集します。前述のとおり幻覚名には再現性があるため、「狙い目の名前リスト」を作ることが可能です。
ステップ2：その名前を npm / PyPI に悪意あるパッケージとして登録する
攻撃者は、収集した幻覚名で実際に動く（一見正規に見える）パッケージを作り、公開レジストリに登録します。表向きは「画像処理ライブラリ」などとして振る舞いつつ、内部に悪意あるコードを仕込みます。
ステップ3：開発者が AI の提案どおりにインストールする
開発者が AI の生成コードをそのまま使い、npm install <幻覚名> や pip install <幻覚名> を実行すると――かつては存在しなかった名前が、今度は本当に存在してしまっている。インストールは成功します。
ステップ4：インストール時の自動実行（postinstall 等）でマルウェアが走る
ここが最も危険な点です。npm の postinstall スクリプトのように、パッケージにはインストールしただけで自動実行されるフックが存在します。悪意あるパッケージは、このフックを使って、ビルド環境や開発者の端末で任意のコードを実行しようとします。環境変数（API キー・トークン）の窃取、バックドアの設置、CI/CD 環境への侵入などにつながりうる――第 15 回のシークレット/API キー漏洩とも直結する被害です。
攻撃の流れ（まとめ表）
| 段階 | 攻撃者がやること | 開発者側で起きること |
|---|---|---|
| 1 | 幻覚されやすい名前を収集 | （気づかない） |
| 2 | その名前で悪意あるパッケージを登録 | （気づかない） |
| 3 | ― | AI 提案を信じてインストール成功 |
| 4 | postinstall 等で自動実行 | 端末・CI でコード実行、情報窃取 |
要点：被害の決め手は「インストールしただけで動く自動実行フック」。だからこそ、入れる前に止める設計が効く。
typosquatting との違い
slopsquatting は、従来からある typosquatting（タイポスクワッティング） と混同されがちですが、入口が異なります。
| 観点 | typosquatting（従来型） | slopsquatting（AI時代型） |
|---|---|---|
| 攻撃の入口 | 人間のタイプミス（例：reqeusts を requests と打ち間違える） | AI の幻覚（実在しない名前を提案する） |
| 攻撃者が狙う名前 | 人気パッケージの綴り間違い | AI が繰り返し幻覚する名前 |
| 引っかかる理由 | 打ち間違い・確認不足 | AI を信頼して提案どおりにインストール |
| 対策の力点 | 名前の正確な入力・確認 | AI 提案の存在確認・依存の出所管理 |
typosquatting は「人がミスする」ことを前提にした攻撃ですが、slopsquatting は「AI がもっともらしい嘘の名前を出す」ことを前提にした攻撃です。両者は重なる部分（綴り違いの悪用など）もありますが、AI を介在させることで、攻撃対象の名前が予測しやすくなり、規模が広がりうる点が新しさです。従来のタイポ対策だけでは、AI 由来の幻覚名は防ぎきれません。
中堅企業の対策：8つの防御層
専門のセキュリティチームを持たない中堅・中小企業でも、**多層で防ぐ（一つに頼らない）**ことが現実的です。以下を、できるところから組み合わせます。
防御1：lockfile を固定し、レビュー対象にする
package-lock.json / pnpm-lock.yaml / poetry.lock などの lockfile を必ずコミットし、依存の追加・変更をプルリクエストのレビュー対象にする。新しいパッケージが追加された差分は、人の目で「この名前は本当に正規か」を確認するゲートになります。CI では npm ci（lockfile に厳密に従うインストール）を使い、勝手な解決を避けます。
防御2：SCA / 依存監査ツールを CI に組み込む
SCA（ソフトウェアコンポジション解析）や依存監査ツールを CI に入れ、依存パッケージを自動でチェックします。代表的なものに Dependabot（GitHub）・Trivy・Snyk などがあります（いずれも公式の利用条件・機能の最新仕様は各公式サイトで確認してください）。これらは既知の脆弱性検出が主目的ですが、依存の可視化・新規追加の検知にも役立ちます。第 11 回のSAST/DAST/SCA の手順で扱った「シフトレフト」の考え方を、依存管理にも広げる形です。
防御3：許可リスト（allowlist）と内部ミラー／プライベートレジストリ
より堅い守りは、**「使ってよいパッケージ・レジストリを限定する」**ことです。
- 許可リスト方式：社内で承認した依存だけを使えるようにする
- 内部ミラー／プライベートレジストリ：公開レジストリを直接叩くのではなく、社内でミラー・キュレーションしたレジストリ経由でのみ取得する。Verdaccio・Nexus・Artifactory などのプライベートレジストリ製品があります（具体的な選定は環境に合わせて）
こうしておくと、未承認の（＝幻覚由来かもしれない）新しい名前は、そもそも取得できないため、入口で止められます。
防御4：インストール前の「存在・素性」確認
AI が新しいパッケージを提案したら、入れる前に最低限の素性確認をします。
- そのレジストリでの公開日・ダウンロード数・メンテナ・リポジトリを確認する（作られたばかり・実績がほぼ無い・リポジトリが無いものは要注意）
- 公式ドキュメントやリポジトリで、その名前が本当に正規パッケージかを確認する
- AI に聞き返すのではなく、一次情報（公式サイト・公式リポジトリ）で裏取りする
防御5：postinstall など自動実行スクリプトを無効化／制限する
npm では、インストール時の任意スクリプト実行を抑制する設定（例：--ignore-scripts 相当の運用や、CI でのスクリプト実行制限）を活用できます。少なくとも CI / ビルド環境では、依存パッケージの postinstall を無条件に実行しない方針が、被害の決め手（自動実行）を断つうえで有効です。正規パッケージで本当に必要な場合のみ、明示的に許可します（具体的な設定はパッケージマネージャの公式ドキュメントを確認してください）。
防御6：AI 提案パッケージの「人によるレビュー」
AI が提案した import / 依存追加は、「正規パッケージである」と人が確認するまで採用しないルールにします。とくに初めて見る名前は、レビューで重点的にチェックします。第 13 回のOSS ライセンス混入と同じく、「動いたから取り込む」を「素性を確認してから取り込む」に変えることが核心です。
防御7：ビルド環境を隔離する（最小権限）
万一悪意あるパッケージを入れてしまっても、被害を広げないために、ビルド／インストールを隔離環境（コンテナ・専用 CI ランナー）で、最小権限・ネットワーク制限つきで実行します。本番のシークレットや広い権限を、依存解決の段階で晒さない設計です。
防御8：SBOM で「何が入っているか」を把握し続ける
**SBOM（ソフトウェア部品表）**で、自社プロダクトにどの依存が入っているかを継続的に可視化します。新しい依存が増えたら気づける状態にしておくことで、幻覚由来の不審な追加を検知しやすくなります（SBOM は第 13 回でも扱いました）。
防御層の早見表
| 防御層 | 主に効く段階 | 難易度 |
|---|---|---|
| lockfile 固定＋レビュー | 取り込み | 低 |
| SCA／依存監査（Dependabot 等） | 取り込み・運用 | 低〜中 |
| 許可リスト・内部ミラー | 取得 | 中 |
| インストール前の存在確認 | 取り込み | 低 |
| postinstall 無効化・制限 | インストール | 中 |
| AI 提案の人によるレビュー | 取り込み | 低 |
| ビルド環境の隔離・最小権限 | 実行 | 中 |
| SBOM での継続把握 | 運用 | 中 |
中堅企業向けチェックリスト（30分）
今日、30 分以内に「自社が引っかかりやすいか」を確認できる項目です。
| # | 確認項目 | できている？ |
|---|---|---|
| 1 | lockfile（package-lock.json 等）をコミットし、CI で npm ci 相当を使っている | ☐ |
| 2 | 依存の追加・変更が、プルリクエストでレビューされる運用になっている | ☐ |
| 3 | Dependabot などの依存監査が有効になっている | ☐ |
| 4 | AI が提案した「初めて見るパッケージ名」を、入れる前に公式で存在確認している | ☐ |
| 5 | CI／ビルド環境で、依存の postinstall を無条件実行していない | ☐ |
| 6 | ビルド環境に、本番シークレットや広い権限を晒していない | ☐ |
| 7 | 公開レジストリを直叩きせず、許可リストや内部ミラーを検討している | ☐ |
| 8 | 「動いた＝安全」ではないと、開発メンバーが理解している | ☐ |
☐ が 3 つ以上あれば、slopsquatting に対して無防備な状態といえます。まずは 1〜5（lockfile・レビュー・依存監査・存在確認・postinstall）から着手するのが費用対効果が高い順です。
いつGXOに相談すべきか
次のいずれかに当てはまる場合は、自社だけで抱え込まず、外部の力を借りることを検討してください。
- AI に依存追加を任せきりで、誰も「正規パッケージか」を確認していない
- lockfile を使っていない／CI で依存が毎回バラバラに解決されている
- 依存監査（SCA）も SBOM も無く、何が入っているか把握できていない
- CI／ビルド環境で postinstall が無制限に走っており、そこに本番権限がある
- 過去に不審なパッケージを入れた疑いがあり、影響範囲を確認したい
GXO は中堅企業（年商 30〜300 億・情シス 1〜3 名）向けに、AI 生成コードを含むサプライチェーンの脆弱性診断、DevSecOps の CI 組み込み（依存監査・存在確認ゲートの設計）、そして**システム開発・運用ルール整備**までを段階的に支援します。「AI に任せて速くしたいが、変なパッケージは入れたくない」という中堅企業の現実に合わせて、仕組みで止める設計をお手伝いします。本連載のハブ（バイブコーディング危機 特集）もあわせてご覧ください。
よくある質問（FAQ）
Q1. パッケージ幻覚は、有料の高性能モデルを使えば起きないのでしょうか？
A. ゼロにはなりません。USENIX 2025 の研究では、商用（プロプライエタリ）モデルの平均幻覚率が約 5.2%、オープンソースモデルが約 21.7% と報告されており、商用モデルのほうが相対的に低い傾向ですが、商用モデルでも幻覚は起こりうるという結果です。「良いモデルだから確認不要」とは言えません。
Q2. インストールが成功したら、そのパッケージは本物ですか？
A. いいえ。slopsquatting では、攻撃者が幻覚名で実在のパッケージを既に登録しているため、インストールは成功します。インストール成功は「本物である」証明にはなりません。公開日・実績・公式リポジトリで素性を確認してください。
Q3. typosquatting 対策をしていれば、slopsquatting も防げますか？
A. 部分的にしか防げません。typosquatting は「人のタイプミス」を、slopsquatting は「AI の幻覚」を入口にします。タイポ検知だけでは、AI が提案するもっともらしい新しい名前は防ぎきれません。AI 提案の存在確認・依存の出所管理が別途必要です。
Q4. postinstall を無効化すると、正規パッケージが壊れませんか？
A. 一部の正規パッケージは postinstall を正当に使っています。そのため全面禁止ではなく、CI／ビルド環境では原則実行しない＋必要なものだけ明示的に許可する運用が現実的です。具体的な設定はパッケージマネージャの公式ドキュメントを確認してください。
Q5. 内部ミラー（プライベートレジストリ）は中堅企業に重すぎませんか？
A. 規模によります。まずは lockfile 固定・依存監査・存在確認といった低コストな対策から始め、依存が増え・取り扱う情報が機微になってきた段階で、許可リストや内部ミラーの導入を検討するのが現実的です。
Q6. もう不審なパッケージを入れてしまったかもしれません。どうすれば？
A. まず影響範囲の確認です。導入時期・対象環境（端末／CI）・そこにあったシークレットの有無を洗い出し、該当シークレットのローテーションを急ぎます。CI で広い権限を持っていた場合は、第 15 回のシークレット漏洩の手順も参照してください。判断に迷う場合は専門家に相談を。
Q7. AI に「この名前は実在しますか？」と聞けば確認になりますか？
A. なりません。幻覚を起こす当の AI に確認しても、再び幻覚で「実在します」と答えうるためです。必ず公式サイト・公式リポジトリ・レジストリそのものという一次情報で裏取りしてください。
参考一次ソース
- USENIX Security 2025「We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs」（Spracklen ら）発表ページ
- 同論文の事前公開版（arXiv）
- Slopsquatting（Wikipedia・用語の由来と huggingface-cli 事例の概説）
- npm Docs（scripts / lifecycle スクリプト・lockfile・
npm ciの公式仕様） - GitHub Docs（Dependabot による依存関係の監査）
- OpenSSF（Open Source Security Foundation・OSS サプライチェーンセキュリティ）
※研究の数値（全体平均 約 19.7%、商用 約 5.2%／オープンソース 約 21.7%、ユニーク幻覚名 205,474 件、16 モデル）は上記論文の報告に基づきます。huggingface-cli の「3 ヶ月で 3 万件超のダウンロード」は研究者による概念実証として報告されたものです。攻撃手法・ツールの最新仕様は、各公式ドキュメントを確認してください。
まとめ
- パッケージ幻覚とは、AI が実在しないパッケージ名をもっともらしく提案する構造的な現象で、研究では生成コードのおおよそ 5 回に 1 回の割合で起こりうると報告されている
- 幻覚名には再現性があるため、攻撃者が「狙い目の名前」を予測できる――これが slopsquatting（幻覚名を先回り登録する攻撃）の土台になる
- 攻撃の流れは 幻覚名→攻撃者が悪意登録→開発者がインストール→postinstall 等で自動実行。被害の決め手は「インストールしただけで動く自動実行」
- typosquatting（人のタイプミス）とは入口が違い、AI の幻覚を悪用する点が新しい。タイポ対策だけでは防げない
- 対策は多層で――lockfile 固定・SCA/依存監査（Dependabot 等）・許可リスト/内部ミラー・インストール前の存在確認・postinstall 制限・AI 提案の人レビュー・ビルド環境の隔離・SBOM
- 中堅企業は、まずlockfile・レビュー・依存監査・存在確認・postinstall 制限という低コストな層から着手するのが効果的
- 「動いた＝安全」ではない。AI に任せて速くするほど、素性確認を仕組みで担保することが要になる
「AI に依存を選ばせる」を続けるなら、「その名前が本物か、仕組みで確かめる」をセットにする。これが、AI 時代のサプライチェーン攻撃からプロダクトを守る、実装上の核心です。
AI生成コードのサプライチェーン対策を相談したい方へ
AI が提案したパッケージ、本当に「本物」か確かめられていますか？
GXO は中堅企業（年商 30300 億・情シス 13 名）向けに、外部 CTO / セキュリティ顧問、AI 生成コードの脆弱性診断、依存監査・存在確認ゲートの CI 組み込み、運用ルール整備までを段階的に支援します。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
関連記事
- 第 1 回 バイブコーディング危機 概論 + 7 リスク類型
- 第 11 回 AI生成コードのセキュリティスキャン手順（SAST/DAST/SCA）
- 第 13 回 AI生成コードのライセンス・OSS混入リスク
- 第 15 回 シークレット/API キー漏洩の現実と対策
- 連載ハブ：バイブコーディング危機 特集
著者: GXO株式会社 初回公開: 2026 年 6 月 9 日 最終更新: 2026 年 6 月 9 日 連載: バイブコーディング危機 第 17 回（全 20 回予定 / 防衛策の実装編）