コーディングアシスタントが存在しないパッケージを発明すると、攻撃者が先に登録する

AIコーディングアシスタントにインポートの整理を頼むと、存在しないパッケージ名を返してくることがあります。その名前はもっともらしく見えます。実在する2つのツールを組み合わせていたり、見覚えのある命名規則に従っていたりします。あなたはインストールコマンドを貼り付けます。もし誰かがその名前をすでに登録していれば、あなたは相手が公開したものをそのままインストールしたことになります。

セキュリティ研究者はこれをスロップスクワッティング（slopsquatting）と呼んでいます。タイポスクワッティングの親戚のようなもので、ただし攻撃者はあなたのタイプミスを必要としません。必要なのは、モデルがどんな名前を発明しがちかを知り、それを誰よりも早く取得することだけです。

その規模は逸話的なものではない

2025年のUSENIX Securityの研究では、16のコード生成モデルをPythonとJavaScriptの57万6千件のコードサンプルでテストしました。その結果、どのレジストリにも存在しない20万5千以上のユニークなパッケージ名が見つかりました。ハルシネーション率は商用モデルで少なくとも5.2%、オープンソースモデルでは21.7%でした。2026年の追試では5つの新しいフロンティアモデルをテストし、4.62%から6.10%の範囲を計測しました。低くはなっていますが、テストされたすべてのモデルに依然として存在します。

この奇妙な現象を攻撃対象領域に変えるのは再現性です。研究者が同一のプロンプトを再実行したところ、ハルシネーションされた名前の大部分が毎回同じように返ってきました。モデルはランダムに推測しているのではなく、同じ訓練データから同じパターンを学習したため、同じ誤った答えに収束するのです。この予測可能性が脆弱性です。攻撃者は同じプロンプトを実行し、繰り返し現れる名前を収集し、誰よりも早く登録することができます。

2026年の研究では、テストされた5つのモデルすべてが存在しないにもかかわらず生成した127のパッケージ名を特定し、レジストリの保護策が適用された後でも53が登録可能な状態でした。

実在するパッケージ、実際のインストール

これはすでに起きています。2026年初頭、研究者はreact-codeshiftというパッケージが237のGitHubリポジトリで参照されているのを発見しました。この名前は実在する2つのツール、jscodeshiftとreact-codemodを組み合わせたものです。一度も公開されたことはありませんでした。この架空のパッケージを含むAI生成のスキルがコピーされフォークされたことで、参照が独り歩きして広がったのです。

npm上のmetro-evaluatorというパッケージには、2025年12月に公開された4つのバージョンに悪意あるコードが含まれていました。5日後に削除され、セキュリティ用のプレースホルダーに置き換えられました。テストされたモデルはその名前を10回提案していました。もう一つのunused-importsは、実在するeslint-plugin-unused-importsを模倣したもので、アシスタントがそこを指し示した開発者からインストールを集め続けました。

より大規模な作戦は、セキュリティ企業Koi SecurityがPhantomRavenと呼ぶキャンペーンで、少なくとも2025年8月から活動しています。Koiは126の悪意あるnpmパッケージと8万6千以上のダウンロードをこれに帰属させています。ここの手口はハルシネーションされた名前とは異なります。package.jsonはクリーンに見え、時にはログ行程度しか含まれていませんが、別のnpmパッケージではなく、平文のHTTP URLでホストされた依存関係を指しています。ほとんどのスキャナーは生のURLを追跡しないため、npmトークン、GitHub認証情報、CIシークレットを収集するペイロードがインストール時に見えない形で読み込まれます。Endor Labsは2025年11月から2026年2月の間に同じキャンペーンのさらなる3つの波を記録し、約50の使い捨てアカウントを通じてアップロードされた88の追加パッケージを確認しています。

レジストリはほとんどの名前をブロックしたが、すべてではない

研究の中には一つ良い知らせがあります。パッケージレジストリは、モデルが発明しがちな名前をブロックする能力を高めています。類似した名前を正規化し、禁止リストを維持し、多数の生成サンプルに現れるパターンを監視しています。2026年の研究が、127の共有ハルシネーション名のリストを確認したとき、そのほとんどはすでに正当なプロジェクトやレジストリの防御によって取得済みかブロック済みでした。

問題は「ほとんど」が「すべて」ではないことです。同じ研究では、保護策が適用された後でも53の名前が登録可能であることが判明しました。複数のフロンティアモデルが一致する単一の登録可能な名前があれば、それをめぐる攻撃を組み立てるのに十分です。攻撃者はモデルを推測すればよく、開発者を推測する必要はないからです。レジストリ運営者は扉のほとんどを閉ざしましたが、残った隙間は狭いものの開いたままです。

同じパターンは今やパッケージマネージャーの範囲を超えて広がっています。セキュリティ研究者は、モデルがハルシネーションするドメインを攻撃者が登録している事例や、エージェントが発明しそうなリポジトリやスキルについても記録しています。それぞれのケースで仕組みは同じです。モデルがもっともらしい名前を予測し、その予測を信頼するよう作られたシステムがそれに基づいて行動するのです。エージェントが到達できる新しい領域はすべて、エージェントが手を伸ばす名前を植え付ける場所となります。

なぜエージェントが事態を悪化させるのか

人間の開発者なら、疑わしいパッケージ名に気づくかもしれません。エージェントは気づきません。エージェントは依存関係を自律的にインストールし、多くの場合、人間がコマンドを先に読むことはありません。研究者は、エージェントを騙して攻撃者が管理するパッケージ名を要求させるプロンプトインジェクション手法を実証しており、Cursor、Windsurf、GitHub Copilotを含むツールで最大100%の成功率が報告されています。

この組み合わせがリスクプロファイルを変えました。ハルシネーションが名前を提供します。エージェントが実行を提供します。攻撃者はその二つが出会うのを待つだけでよいのです。

リーク問題も同じ問題である

企業Glowによる関連レポートでは、エージェントがGitHub上で300以上の組織から集めた1万3千以上の内部画像を露出させていたことが判明しました。仕組みはありふれたものです。エージェントとそのユーザーがスクリーンショット、図、文書を公開リポジトリに置いてしまい、時には「公開」が検索可能で永続的であることを理解しないまま行っています。開発者を速くするのと同じツールが、内部資料を本来あるべきでない場所へ移動させるのも容易にするのです。

どちらの問題も根本原因は同じです。エージェントは、誤っているかもしれない（ハルシネーションされた名前）あるいは機密性の高い（内部スクリーンショット）指示に対して、機械の速度で行動します。かつて意図と行動の間にあった人間のチェックポイントこそ、エージェントが取り除くものなのです。

実際に何をすべきか

防御策は複雑ではありません。脅威がこれほど急速に動いたことを考えれば、これは良い知らせです。

エージェントが生成するすべてのインストールコマンドを信頼できない入力として扱ってください。インストールする前にパッケージが存在するか確認しましょう。どのくらい古いか確認しましょう。ハルシネーションされた名前が登録されていれば、それは新しいはずです。公開者に実績があるか確認しましょう。npmとPyPIでは、簡単なメタデータ検索でこれら3つの問いに数秒で答えが出ます。

エージェントが依存関係を追加する前に、人間の承認を必須にしましょう。これが単一で最も価値の高い変更です。ハルシネーションされた名前、悪意ある登録、プロンプトインジェクションによる要求を一度に捕まえられるからです。エージェントは少し遅くなりますが、最大の穴が塞がります。

エージェントの到達範囲は小さく保ちましょう。コーディングエージェントにはリポジトリアクセスが必要ですが、本番認証情報が必要になることはまれであり、チェックなしにプライベートレジストリを指すパッケージマネージャーを持つべきではありません。SocketやSnykのようなツールは、IDEやCIパイプライン内でレジストリ検索を自動化できます。チームが多数のリポジトリでエージェントを使うようになれば、そのコストに見合う価値があります。

居心地の悪い部分は、これがパッチで修正されるバグではないことです。ハルシネーションは、これらのモデルがテキストを予測する方法そのものに組み込まれています。モデルは検証済みの名前ではなく、次にもっともらしい名前を生成するのです。修正はモデルの周囲のワークフローに存在しなければならず、それはほとんどのチームが今週から始められるプロセスです。