AIエージェントのコード生成が招くnpmタイポスクワッティング
公開日
セキュリティ
AIエージェントを用いたコード生成ツールの普及に伴い、存在しないライブラリ名を回答してしまう「パッケージ・ハルシネーション」が問題視されています。もし攻撃者がこれらの存在しない名前をあらかじめnpmなどの公開レジストリへ先回り登録しておいた場合、開発者が気づかずにインストールして悪意あるコードを実行してしまうサプライチェーン攻撃が成立する懸念があります。
本記事では、北京理工大学や中関村研究所などの研究チームが発表した論文「Package Hallucinations as Phantoms in Open-source Software Supply Chains: An Empirical Security Analysis」を基に、AIエージェントが生成するハルシネーションがnpmエコシステムのタイポスクワッティングや攻撃実効性にどのような影響を与えるのか、その実地調査結果を詳しく解説します。
調査の概要：8つの商用モデルとnpmレジストリを用いた実地検証
本研究では、LLMによるパッケージ・ハルシネーションが単なる理論上の可能性にとどまるのか、それとも実際の開発環境で危険な攻撃ルートとなり得るのかを検証するため、実環境での大規模実験を実施しました。
研究チームは、Stack Overflowから収集した10,893件のJavaScript関連クエリを使用し、ChatGPT-4o、DeepSeek-V3、Grok-3など8つの著名なLLMに入力しました。生成されたコードから存在しない107個のパッケージ名を抽出し、実際にJavaScriptの公式レジストリであるnpmへ安全なプレースホルダーパッケージとして登録して6か月間の追跡調査を行いました。
図1：実験の全体像と検証アプローチ
公開されたパッケージには実際の処理は含めず、インストール時に匿名化されたログ（IPアドレスやシステム情報など）を収集する仕組みを組み込みました。記録された343件のアクセス元IPアドレスについて、OSの種類、GUI環境の有無、セッションの対話性などを基にセキュリティ専門家が厳格な分類を行いました。
人間の開発者がハルシネーションに誘い込まれる実態とアクセス傾向
分析の結果、LLMが出力した架空のパッケージに対して記録されたアクセスのうち、35.2%（全343件のIPアドレス中、人間と判定されたカテゴリの合計）が人間の開発者による手動操作であることが確認されました。
表1：アクセス元IPアドレスの環境分類
| カテゴリ | IP割合 | 判別基準と特徴 |
|---|---|---|
| Automated Script | 53.1% | サーバー用OS、GUI非搭載、同一パターンの定期実行ログ |
| Real User | 26.5% | デスクトップ用OS、一般ISP、ブラウザ実行や対話的セッションの確認 |
| Weak Script Signal | 9.9% | 自動化スクリプトである可能性が高いアクセス |
| Weak User Signal | 8.7% | 企業組織等からの手動アクセスの可能性が高いログ |
| Undetermined | 1.8% | 環境の特定が困難なアクセス |
この結果は、LLMが提示した架空のパッケージ名を開発者が信用し、そのままローカル環境で npm install を実行している事実を示しています。開発環境へ1度でも悪意あるパッケージが入り込むと、依存関係を通じてCI/CDパイプラインや本番環境へと被害が拡大する恐れがあります。
また、アクセス発生のタイミングを分析したところ、人間によるアクセスの70.65%（1週目：40.22%、2週目：30.43%）がパッケージ公開から最初の2週間以内に集中していました。最も早い例では、登録からわずか8分後に最初のアクセスが記録されています。
一方で、npmレジストリ側のセキュリティ対応（不審なパッケージの削除）はリアルタイムではなく、一定期間ごとのまとめての削除（バッチ処理）の傾向を示しており、多くのパッケージが12日間ほど有効なまま放置されていました。攻撃者にとっては、開発者を誘い込むための十分な時間的猶予が存在していると言えます。
既存ライブラリを模倣するタイポスクワッティングのリスク
研究チームは、LLMが生成した107個のハルシネーション・パッケージ名を、npmに存在する約380万個の実在パッケージと比較し、構造的な類似性を分析しました。
その結果、全体の25.2%（27個）が既存のnpmパッケージと絶対編集距離（Levenshtein distance）1以下の関係にありました。さらに45.8%（49個）が編集距離2以下でした。
表2：既存パッケージとの類似例
| ハルシネーション名 | 最も近い既存npm名 | 編集距離（絶対/正規化） | 特徴 |
|---|---|---|---|
cordova-plugin-permissions | cordova-plugin-permission | 1 / 0.038 | 末尾の単複表記違い |
vite-plugin-remove | vite-plugin-remote | 1 / 0.056 | タイポスクワッティング型 |
pydantic | pedantic | 1 / 0.125 | 他言語（Python）有名名の移植 |
openssl-node | openssl-nodejs | 2 / 0.143 | 接尾辞のバリエーション |
LLMはランダムな文字列を出力するのではなく、既存のエコシステムに存在する命名パターン（-plugin、node- など）を組み立てたり、他言語（PythonやJavaなど）で有名だがJavaScriptには存在しない名前（例：pydantic や pdfplumber）を出力したりします。これにより、既存ライブラリに極めて類似した「タイポスクワッティング」と同等のリスクが意図せず作り出されています。開発者は見慣れた名称や他言語での知名度から、疑うことなくインストールコマンドを実行してしまう傾向があります。
Web検索拡張（RAG）が招くハルシネーション悪化のメカニズム
ハルシネーション対策として、LLMにWeb検索機能を追加したり（RAG）、プロンプトで存在チェックを促したりする手法が一般的に検討されます。しかし、研究チームが「C0: 通常の出力」「C1: プロンプトでの存在確認指示」「C2: Web検索の導入」の3条件で実験を行ったところ、直感とは異なる影響が明らかになりました。
図2：各条件におけるハルシネーション持続率の比較
Web検索を有効にしたC2環境では、ハルシネーションの発生・持続率がC0の11.2%から17.3%へと有意に増加しました。
この悪化の要因は「コンテキスト汚染」です。Web検索を有効にすると、検索エンジンがPythonやRなど他言語のライブラリ（例：Pythonの undetected-chromedriver）に関する情報（GitHubイシューや解説記事）を検索結果として取得します。LLMはその検索文脈を取り込み、「このパッケージは実在する」と判断を強め、npmパッケージとして誤って推奨し続けてしまう現象が確認されました。単に外部検索を組み合わせるだけでは、異なるエコシステムの情報が混入してかえってハルシネーションを固定化させてしまう危険性を示しています。
まとめ：低コストな攻撃手法に対する開発現場のセキュリティ対策
本研究で明かされた主要な結果とセキュリティ上のポイントは以下の通りです。
- 攻撃の実効性と人間によるアクセス: 登録されたハルシネーション・パッケージへのアクセスの35.2%は人間の開発者による手動操作であり、実際のセキュリティリスクとして機能しています。
- タイポスクワッティングとの酷似: ハルシネーション名の約25%が既存パッケージと編集距離1以下であり、開発者が違和感を持ちにくい名前が生成されています。
- Web検索拡張による誤った信頼: 検索結果から他言語のライブラリ情報がコンテキストに注入される「コンテキスト汚染」により、Web検索を有効にするとかえってハルシネーションの発生・固定化が悪化する場合があります。
- きわめて低い攻撃コスト: 1万件以上のプロンプトからハルシネーション名を収集するAPI費用は約496ドルであり、レジストリの公開コストも無料であるため、攻撃者にとって費用対効果の高い攻撃手段となります。
開発チームは、AIアシスタントが提示した新規ライブラリを無条件で信頼せず、公式レジストリで公開日やメンテナ情報を確認する運用プロセスを徹底することが重要です。また、公開されてから間もないパッケージの自動導入を制限する min-release-age（最低リリース経過日数制限）のポリシーをパッケージマネージャーやCI/CDパイプラインに設定することで、攻撃者が先回り登録した直後の危険なパッケージの取り込みを自動的にブロックする有効な自衛策となります。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるためのさまざまなソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料：
- Package Hallucinations as Phantoms in Open-source Software Supply Chains: An Empirical Security Analysis