AIは口を開けば本物そっくりの偽名を作り出す、旧来の防御線では見抜けない

AIコーディング支援ツールはこの脅威モデルを一変させた。統計的に最もそれらしい答えを出そうとするあまり、実在しないパッケージ名を、いかにも本当らしくもっともらしくでっち上げてしまう。攻撃者はある特定のモデルがどんな偽名を作りがちかを把握しさえすれば、リポジトリに先回りして同名の悪意あるパッケージを登録すればいい。これがslopsquattingだ。

肝心なのは、AIが作り出す偽名は単純な誤字ではないため、リポジトリの既存の防御用ブロックリストではまったく見抜けないという点だ。同じブロックリストでも、旧来の手口と新しい手口では結果がまるで違う。

さらに厄介なのは、生成されたパッケージ名を既知のパッケージ名一覧と照合するという単純な手法も効かない点だ。攻撃者はすでに幻覚で生まれた偽パッケージをリポジトリに登録済みかもしれず、照合に使う一覧そのものが汚染されている可能性がある。

すでに実際に起きたこと：空のパッケージが1.5万回もダウンロードされた

これは机上の空論ではない。2023年末から2024年初めにかけて、セキュリティ企業Lasso Securityの研究者Bar Lanyadoが検証を行った。複数の大規模言語モデルが繰り返し同じ実在しないPythonパッケージhuggingface-cliを幻覚で生成することを発見し、実際にPyPIでこの名前を登録した。パッケージの中身は空で、悪意あるコードは一切入れず、純粋に実験のためだった。

中身が空のパッケージでさえ3ヶ月で1万回以上のダウンロードを騙し取り、大企業の公式ドキュメントにまで入り込んだ。もしパッケージの中身が悪意あるコードだったら、感染はとっくに依存関係チェーンに沿って広がっていただろう。（出典：The Register 2024-03-28）

なぜこの偽パッケージ名は攻撃者が待ち伏せする価値があるのか：AIは同じ名前を繰り返し作り出す

一度の幻覚は怖くない。怖いのは、同じモデルが同じ問いに対して繰り返し同じ偽名を作り出すことだ。研究チームは幻覚を誘発したことのある500個のプロンプトをランダムに抽出し、それぞれを同じモデルに10回ずつ尋ね、その偽パッケージ名が何回再生成されるかを記録した。

この偽パッケージ名はどんな見た目か

研究ではこれらの偽名が実在のパッケージ名にどれだけ似ているかも測定した。使ったのはレーベンシュタイン距離（編集距離）で、ある名前を別の名前に変えるのに最低何文字動かす必要があるかを測る。距離が小さいほど名前が似ていて手違いの可能性が高く、距離が大きいほどまったく無関係な二つの単語ということになる。

さらに、独自の偽名の81%が16モデルのうち特定の1モデルにしか出現しない。つまり各モデルにはそれぞれ独自の幻覚パターンがある。攻撃者は特定のモデルを狙い撃ちすれば、そのモデルを使う開発者を刈り取れる。

モデルは自分が作った偽パッケージを見分けられるか

研究ではモデルが幻覚パッケージを識別できるかもテストした。実在するパッケージ名と偽名を混ぜてモデルに「これは有効なPythonパッケージか」と尋ねたところ、GPT-4 Turbo、GPT-3.5、DeepSeekの3モデルはいずれも自分の幻覚を75%以上の精度で識別できた。モデルは自分自身の生成パターンについて、ある種の暗黙の自己認識を持っている。この点は後述する「モデル自身に再検証させる」という緩和策の余地を残している。

オープンソースモデルの幻覚率は商用モデルの4倍、しかし誰も無縁ではいられない

同じくコードを書くにしても、どのモデルを選ぶかで踏む地雷の確率は大きく変わる。この研究では合計576,000個のコードサンプル、220万件以上のパッケージ参照を生成し、全体の幻覚率は19.7%だった。分けて見ると、商用モデルとオープンソースモデルには約4倍の差がある。

個別モデルで見ると、GPT-4 Turboの幻覚率が最も低くわずか3.59%。オープンソースの中で最も成績が良いDeepSeekでも13.63%だった。

二つの設定も幻覚を増幅させる。温度（temperature、ランダム性を制御するパラメータ）を上げるほど幻覚は増え、最高温度ではオープンソースモデルが生成する偽パッケージが実在のパッケージより多くなることさえある。それでも最高温度のGPT-4（8.9%）はGPT-3.5（31.8%）より依然として4倍近く低い。さらに、訓練データのカットオフ後に登場した新しい話題を尋ねると、幻覚率は古い話題より平均10%高くなる。パッケージ名の正確性に敏感な本番環境では、商用モデルを選ぶだけでこの層のリスクをかなり削れる。

対策はあるが、「安全性」と「コード品質」の間でトレードオフが必要

研究チームはいくつかの緩和策をテストし、「生成後にふるいにかける」から「生成前に防ぐ」へと段階的に踏み込み、効果は一段ずつ良くなっていった。

最も基本的なのは生成後に実在するパッケージ名一覧と照合してフィルタリングする方法だが、前述の通りこの手法は攻撃者に一覧を汚染されると効かなくなる、受動的な対症療法にすぎない。一歩進んだのが生成前に介入する二つの手法だ。RAG（検索拡張生成）はモデルが答える前に実在のパッケージ一覧を検索し、結果をプロンプトに組み込んでから回答させる。試験前に信頼できる参考資料を渡すオープンブック試験のようなものだ。自己検証（self-refinement）はモデルが生成した後に自分でパッケージ名の真偽を判断させ、おかしいと思えば書き直させる、最大5回まで繰り返す。さらに上を行くのがファインチューニング（fine-tuning）と複数手法の組み合わせ（ensemble、上記の複数手法を重ねて使う）だ。

下の図は二つのオープンソースモデルを切り替えて、5種類の手法がそれぞれ幻覚率をどこまで抑えるかを見られる。

AIが書くコードが増え続ける中、この脆弱性は開く一方だ

この攻撃経路の脅威面は急速に拡大している。なぜなら、AIが手伝って書くコードがますます増えているからだ。

オープンソースエコシステム自体のセキュリティ状況も悪化している。10言語、31,267件の脆弱性サンプルを分析したある研究によると、報告される脆弱性の数は年98%のペースで増加しており、パッケージ総数の年25%成長を大きく上回る。

さらに注目すべきは悪意ある由来の割合だ。これらの脆弱性報告のうち、NPMエコシステムでは49%が意図的にアップロードされた悪意あるパッケージ由来で、PyPIでも14%に上る。リポジトリの落とし穴は、かなりの部分が誰かがわざと仕込んだものだ。AI幻覚パッケージは、まさにこの種の意図的な攻撃にもう一つの扉を開いている。

一般開発者が今すぐできる二つのこと

この攻撃は信頼の隙間を突いている。開発者はAIが推薦するパッケージをデフォルトで本物だと信じ込み、インストール前に確認しない。この隙間を塞ぐには、ほぼコストゼロで済む二つのことがある。

さらに前述の一点を重ねる：パッケージ名の正確性が求められる場面では、商用モデル、あるいはRAGやファインチューニング処理済みのモデルを選ぶことで、この層のリスクをさらに一段階抑えられる。

AIコーディング支援ツールは「最もそれらしい」答えを出すために、実在しないパッケージ名をいかにも本当らしくでっち上げてしまう。これを「幻覚」と呼ぶ。ハッカーはある特定のモデルがどんな偽名を作りがちかを把握しさえすれば、先回りしてリポジトリに同名のパッケージを登録し、ウイルスを仕込めばいい。業界はこの手口に名前をつけた：slopsquatting。

さらに厄介なのは、この偽名は一度きりの偶然ではなく、同じモデルが繰り返し同じものを作り出すという点だ。だからハッカーは先回りして待ち伏せできる。

研究チームは同じモデルに同じ質問を10回繰り返し尋ねた結果、43%の偽名が毎回吐き出され、58%は少なくとも1回以上再現した。これはランダムなノイズではなく、事前に待ち伏せできる安定した標的だ。攻撃チェーン全体は「偽名が繰り返し出てくる」ことによって一つの閉ループに変わる。

幻覚が多いかどうかは、どのモデルを選ぶかと強く関係する。そしてAIが書くコードはどんどん増えており、この脆弱性は開く一方だ。まず「あるモデルで100個のソフトウェアパッケージ参照を書かせたら、何個が偽物か」を並べて見てみよう。

幻覚率の数字はすべてある学術論文の実測データ（arXiv:2406.10279、USENIX Security 2025）に基づき、1.5万回のダウンロードはセキュリティ企業Lasso Securityによる実際の実験結果だ。いずれもベンダーの自己宣伝ではない。もう一つ「50%〜82%」という数字があるが、これは医療分野の研究であり、同じ口径ではないので混同してはいけない。