Vibe Coding で気を付けておきたいセキュリティ脅威「パッケージハルシネーション」について理解する
はじめに
AI支援コード生成の急速な普及に伴い、開発者の多数がAIツールを活用し、AI由来のコード割合が増加傾向にある現在、新たなセキュリティ脅威が浮上している。パッケージハルシネーションと呼ばれるこの現象は、LLMが存在しないパッケージ名を含むコードを生成することで、ソフトウェアサプライチェーン全体に影響を与える可能性がある。
この問題を扱った研究がUSENIX Security 2025で発表されることを知り、セキュリティ業界でも注目度の高いトピックだと感じた。実際に論文を読んでみると、AI時代の新しい脅威として具体的な分析データと実用的な対策が示されており、現場のエンジニアにとって価値の高い知見が含まれていた。
本記事では、16の主要LLMを対象とした576,000件のコードサンプル分析に基づき、この問題の実態と対策を整理する。商用モデルからオープンソースモデルまで幅広く検証し、実践的な緩和策の効果を定量的に評価した研究成果を、ありがたく拝見する。
TL;DR(要点まとめ)
パッケージハルシネーションの問題と実用的な対策指針を表にまとめた。
| 項目 | 主要な発見 | 実践的な対策 |
|---|---|---|
| 問題の規模 | ・商用モデル5.2% の発生率 ・OSS21.7% の発生率 ・205,474個のユニーク偽パッケージ ・43%が同一プロンプトで再現 |
・temperature param 0.7以下に設定 ・複数モデルでの交差検証 ・AI生成コードの必須検証プロセス |
| セキュリティリスク | ・新型パッケージ混乱攻撃の経路 ・攻撃者の先回り戦術 ・サプライチェーン全体への汚染 |
・キュレーション済パッケージリスト ・企業内プライベートリポジトリ ・パッケージ署名検証の導入 |
| 効果的な緩和策 | ・RAG手法で最大49%削減 ・ファインチューニングで83%削減 ・アンサンブル手法で85%削減 |
・開発段階別の段階的適用 ・コード品質とのバランス調整 ・継続的なモデル更新体制 |
パッケージハルシネーションとは何か?
コード生成LLMが引き起こす新しいタイプの脅威として、パッケージハルシネーションという現象が浮上している。これは、LLMが存在しないパッケージ名を含むコードを生成してしまう現象で、従来のハルシネーション(事実と異なる情報生成)がコード領域に特化して現れたものだ。
この現象は技術的な不具合を超えて、ソフトウェアサプライチェーン全体を脅かすセキュリティリスクに発展する。
パッケージハルシネーションの特徴と現実のソフトウェア開発への影響を整理した。特にやっかいなのは、検出が困難である点だ。従来のパッケージ混乱攻撃(タイポスクワッティング)とは異なり、LLMが生成する架空のパッケージ名は、開発者にとっては実在するものとして認識される可能性が高い。
| 現象の側面 | 詳細内容 | 実際の影響 |
|---|---|---|
| 発生メカニズム | ・LLMの確率的生成による誤予測 ・訓練データの不完全性や偏り ・文脈理解の限界による推論エラー |
・開発者の混乱とデバッグ時間の増加 ・プロジェクトの進行遅延 ・技術負債の蓄積 |
| セキュリティリスク | ・パッケージ混乱攻撃の新しい経路 ・悪意あるパッケージの投入機会 ・大規模な供給チェーン汚染の可能性 |
・企業システムへの不正アクセス ・機密データの漏洩 ・金銭的損失とブランド毀損 |
| 検出困難性 | ・単純な照合では不十分 ・先回りした悪意パッケージ公開 ・動的な脅威の性質 |
・従来のセキュリティツールでは対応困難 ・人的判断に依存する検証プロセス ・自動化されたCI/CDパイプラインでの見落とし |
攻撃の流れと成功要因
パッケージハルシネーションを悪用した攻撃は、従来のパッケージ混乱攻撃を進化させた形態として理解できる。攻撃者は能動的にパッケージ名を捏造する必要がなく、LLMが生成する架空のパッケージ名を「待ち受ける」ことで攻撃を実行できる。
攻撃の成功要因と、それに対応する防御策の関係性を技術的観点から分析すると、明確な構造が見えてくる。特筆すべきは、LLMの普及率とハルシネーションの持続性、リポジトリの開放性が攻撃成功に寄与している点である。
| 攻撃成功要因 | 技術的背景 | 現実的な対策アプローチ |
|---|---|---|
| LLMの普及率 | ・開発者の97%がAI活用 ・生成コードの30%がAI由来 ・信頼性への過度な依存 |
・AI生成コードの必須検証プロセス ・多段階レビューシステム ・人的確認の制度化 |
| ハルシネーションの持続性 | ・同一プロンプトで43%が完全再現 ・58%が複数回発生 ・モデル固有パターンの存在 |
・プロンプトエンジニアリング ・temperature param最適化 ・複数モデルでの交差検証 |
| リポジトリの開放性 | ・誰でもパッケージ公開可能 ・自動化された公開プロセス ・事前審査の限界 |
・キュレーション済みパッケージリスト ・企業内プライベートリポジトリ ・パッケージ署名検証 |
どうやって検証したのか?
この研究では576,000個のコードサンプルを生成し、16の主要LLMを対象とした大規模な検証実験を実施した。
データセット構築では、現実的な開発シナリオを反映させるため、Stack Overflowの質問とLLM生成プロンプトの2つのアプローチを採用した。これは単一の手法では捉えきれない多様性を確保するための選択である。
パッケージハルシネーションの検出手法として、3つのヒューリスティックを開発した。これらの手法は、コード解析の複雑さと実用性のバランスを取った現実的なアプローチでと言える。
| 検出手法 | 技術的アプローチ | 検出対象と限界 |
|---|---|---|
| インストールコマンド解析 | ・pip install、npm installの直接パース ・コマンドライン引数の抽出 ・7%のサンプルで発生確認 |
・最も確実な検出方法 ・発生頻度が相対的に低い ・暗黙的依存関係は捕捉困難 |
| 生成コードからの逆引き | ・同一モデルへの依存関係質問 ・実際のユーザー行動を模倣 ・エラー時の対処プロセス再現 |
・現実的なワークフロー反映 ・モデルの一貫性に依存 ・循環的な検証プロセス |
| プロンプトベース推論 | ・元プロンプトからの必要パッケージ推定 ・タスク理解能力の評価 ・抽象化レベルでの分析 |
・高レベル設計判断の検証 ・実装詳細との乖離可能性 ・プロンプト品質への依存 |
なにがわかったのか?
ハルシネーション率の分布特性
実験結果は、LLMの種類と設定によってハルシネーション率が大きく変動することを明確に示している。商用モデルとオープンソースモデルの間には4倍の性能差が存在し、この差は単純な性能指標を超えた構造的な違いを反映している。

205,474個のユニークなハルシネーションパッケージが発見されたことは、この問題の規模と多様性を物語っている。これは単発的なエラーではなく、体系的な現象として理解すべき規模である。
モデルパラメータの影響分析
temperature paramとハルシネーション率の関係は、創造性と正確性のトレードオフを具体的に示している。temperatureが1を超えると急激にハルシネーション率が上昇する現象は、確率分布の裾における低頻度トークンの選択確率増加として説明できる。

モデル設定がハルシネーション発生に与える影響を定量的に把握することで、実運用での最適化指針が得られる。具体的には、temperatureを0.7以下に設定することで、ハルシネーション率を大幅に低下させることに繋がる可能性が指摘されている。その他、デコーディング戦略(top-p、top-kなど)やデータの新しさもハルシネーションに影響を与える要因として挙げられている。
| 設定パラメータ | 影響の性質 | 実用的な調整指針 |
|---|---|---|
| temperature設定 | ・0に近づくほど安全 ・1超過で急激悪化 ・創造性との明確なトレードオフ |
・コード生成では0.7以下推奨 ・プロトタイピングでは柔軟性重視 ・本番環境では保守的設定 |
| デコーディング戦略 | ・top-p、top-k調整は限定的効果 ・グリーディ手法でも発生 ・確率的性質の根深さ |
・従来手法では根本解決困難 ・新しいアプローチが必要 ・複合的対策の検討 |
| データの新しさ | ・最近データで10%悪化 ・訓練カットオフ日の影響 ・継続学習の課題 |
・定期的なモデル更新 ・外部知識ベース活用 ・RAGアプローチの導入 |
ハルシネーションの持続性とモデル固有性
同一プロンプトに対する反復実験で、43%のハルシネーションが10回全てで再現された事実は、これらが単純なランダムエラーではないことを証明している。

一方で、81%のハルシネーションが単一モデルでのみ発生することは、各モデルが固有のバイアスパターンを持つことを示唆している。

この発見は、複数モデルを用いた交差検証の有効性を理論的に裏付けており、実用的な対策への重要な示唆を提供している。
どういう特徴があるのか?
意味的類似性
ハルシネーションパッケージと既存パッケージのLevenshtein距離分析により、分布特性が明らかになった。距離1-2の単純な誤字は全体の13.4%に過ぎず、48.6%が距離6以上の大幅な差異を示している。

この結果は、ハルシネーションが単純なタイポスクワッティング的な現象ではなく、より根本的な生成プロセスの問題であることを示している。攻撃者にとっては予測が困難な一方で、防御側にとっても従来の文字列類似性ベースの検出手法では対応が困難であることを意味している。
プログラミング言語間の混乱
プログラミング言語間でのパッケージ混乱についても発見がある。Pythonコード生成において、8.7%がJavaScriptパッケージとして有効な名前であることが判明した。これは、多言語学習を行ったLLMの内部表現における言語境界の曖昧さを反映している。
どのように緩和できそうか?
先に結果をペタリ。ファインチューニングとアンサンブル手法の効果が高いことが分かる。

RAG
RAGアプローチでは、上位20,000の人気PyPIパッケージから65,000の質問-パッケージペアを生成し、ベクターデータベースとして活用した。RAGの効果は、外部知識ソースとLLMの内部表現を橋渡しすることで、生成プロセスに現実的な制約を課すメカニズムとして理解できる。これは実在する本のカタログを参照しながら推薦を行う仕組みに近い。
自己修正(Self-Refinement)
LLM自身による自己検出能力を活用した修正手法では、生成と検証を同一モデル内で完結させる可能性を示唆している。しかし、CodeLlamaのように有効パッケージとして分類する傾向が強いモデルでは、この手法の効果が限定的であることも判明した。モデルの特性を理解した上での適用が重要である。
ファインチューニング
最も効果的だったファインチューニング手法では、DeepSeekで83%のハルシネーション削減を達成した。ただし、HumanEvalベンチマークでコード品質の低下が見られ、性能とのトレードオフが存在することも明確になった
緩和策まとめ
ここまでの緩和策を改めてまとめると、次のようになる。
| 緩和手法 | DeepSeek効果 | CodeLlama効果 | 実装上の考慮点 |
|---|---|---|---|
| RAG | ・12.24% (-24.1%) ・外部知識活用 ・リアルタイム参照 |
・13.40% (-49.0%) ・大幅改善 ・一貫した効果 |
・ベクターDB構築コスト ・レスポンス時間への影響 ・知識ベース更新の要件 |
| 自己修正 | ・13.04% (-19.3%) ・内部能力活用 ・追加リソース不要 |
・25.51% (-2.9%) ・限定的効果 ・モデル特性依存 |
・反復処理による遅延 ・検出能力の個体差 ・偽陽性リスクの管理 |
| ファインチューニング | ・2.66% (-83.5%) ・根本的解決 ・最高効果 |
・10.27% (-60.9%) ・大幅改善 ・安定した性能 |
・学習データ品質への依存 ・コード性能とのトレードオフ ・継続的な更新コスト |
実装する際に考慮すべきこと
本番環境への適用
緩和策を実際の開発環境に適用する際には、パフォーマンス、コスト、保守性の観点から総合的な判断が必要である。単一手法での完全解決は困難であり、複数手法を組み合わせたアンサンブルアプローチが現実的である。
開発フェーズに応じた適用戦略を考えると、プロトタイピング段階では創造性を重視し、本番リリース前には厳格な検証を行う段階的なアプローチが有効である。
モデル選択
商用モデルとオープンソースモデルの選択では、ハルシネーション率だけでなく、緩和策の適用可能性、運用コスト、カスタマイズ性を総合的に評価する必要がある。
GPT-4 Turboのような高性能商用モデルは、そのままでも実用的なレベルの安全性を提供するが、DeepSeekのようなオープンソースモデルは適切なファインチューニングにより同等以上の性能を達成できる。
今後の技術展望と研究課題
根本原因の解明
パッケージハルシネーションの根本的なメカニズム解明は、今後の重要な研究課題である。トークナイザーの設計、学習データの構成、アーキテクチャの特性など、多層的な要因分析が必要である。
特に、同一ファミリーモデル間でも異なるハルシネーションパターンを示す現象は、モデルの内部表現における微細な差異の影響を示唆しており、解釈可能AI技術との連携による解明が期待される。
次世代対策技術の展望
リアルタイムフィードバック機能、高度な知識グラフ活用、損失関数の改良など、より洗練された対策技術の開発が進展している。これらの技術は、ハルシネーション問題を根本的に解決する可能性を秘めている。
また、コード生成専用に設計されたアーキテクチャや、セキュリティを第一に考慮した学習手法の開発も重要な方向性である。
パッケージハルシネーション問題は、AI支援開発の普及に伴って重要性を増す技術課題である。現在の緩和策により一定の改善は可能だが、根本的解決には継続的な研究開発が不可欠である。開発者、研究者、セキュリティ専門家の連携により、より安全で信頼性の高いAI支援開発環境の実現を目指していく必要がある。
引用・参考文献
原論文
- J. Spracklen et al., "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs," arXiv preprint arXiv:2406.10279v3, 2025.
論文情報
- arXiv ID: 2406.10279v3 [cs.SE]
- 公開日: 2025年3月2日
- URL: https://arxiv.org/pdf/2406.10279
- ライセンス: CC BY-NC-SA 4.0
著者所属
- Joseph Spracklen, Raveen Wijewickrama, A H M Nazmus Sakib, Murtuza Jadliwala: University of Texas at San Antonio
- Anindya Maiti: University of Oklahoma
- Bimal Viswanath: Virginia Tech
Discussion