スロップスクワッティングとは？AI生成コードの新脅威

CISA KEVに3件追加、Arista EOSはパッチ提供なし 研究・論文

生成AIにコードを書かせると、実在しない「幻のパッケージ」名がインポート文に紛れ込むことがあります。攻撃者はその名前を先回りして公開リポジトリ（PyPIやnpm）に登録し、悪意あるコードを仕込みます。AIの提案を信じてpip installした瞬間にマルウェアを取り込む——これが「スロップスクワッティング（slopsquatting）」と呼ばれる新しいサプライチェーン攻撃です。本記事では、2026年6月に公開された査読前の最新研究を起点に、情シスが押さえるべき脅威の輪郭と現実的な備えを整理します。

この記事でわかること：

  • スロップスクワッティング／パッケージハルシネーションとは何か、なぜ危険か
  • 幻のパッケージがどれくらいの頻度で発生するのか（公表されている実測値）
  • 最新の査読前研究が示した「検知の難しさ」と新しいアプローチ
  • AIコーディング普及期に情シスが取るべき現実的な対策の方向性

スロップスクワッティングとは何か

スロップスクワッティングとは、大規模言語モデル（LLM）が生成したコードに含まれる実在しないパッケージ名を、攻撃者が悪用するサプライチェーン攻撃です。LLMが事実と異なる出力をする現象を「ハルシネーション（幻覚）」と呼びますが、それがパッケージ名で起きたものが「パッケージハルシネーション」です。この名称は、打ち間違いを狙う従来の「タイポスクワッティング（typosquatting）」をもじって、Python Software Foundationの開発者Seth Larson氏が名付けたとされています。

なぜ成立してしまうのか

攻撃の流れはシンプルです。第一に、LLMが存在しないパッケージ名を提案する。第二に、攻撃者が同じ名前を観測し、公開リポジトリに先回り登録して悪意あるコードを仕込む。第三に、別の開発者が同じプロンプトでAIに尋ね、同じ幻の名前を提案され、何の疑いもなくインストールしてしまう——という連鎖です。重要なのは、同じモデルは同じ幻を繰り返し提案しやすいという再現性で、これが攻撃者にとって「狙いを定めやすい」性質になっています。

幻のパッケージはどれくらい発生するのか

査読を経た代表的な研究が、2025年のUSENIX Security Symposiumで発表された「We Have a Package for You!」（Spracklenら）です。16のLLMで2言語・約57万6千件のコードを生成し、パッケージハルシネーションを大規模に測定しました。広く報じられている要点は次のとおりです。

観点 報告されている傾向
商用モデルでの幻出現率 おおむね5%前後
オープンソースモデルでの幻出現率 20%超に達するケースも
再現性 同一プロンプトの反復で、幻の多くが繰り返し出現

数値はモデルや条件で変動しますが、「ごく稀な事故」ではなく無視できない頻度で起こる構造的な問題だという点が肝心です。生成AIによるコーディング支援が日常化した現場ほど、リスクの母数は大きくなります。

最新の査読前研究は何を示したのか

今回取り上げる査読前（プレプリント）の研究は、「Bayesian-Calibrated Detection of Hallucinated Package Imports in AI-Assisted Code」（arXiv:2606.13918、2026年6月11日投稿）です。arXivに公開された査読前の論文であり、結果は今後の査読で変わりうる点に留意してください。

「登録済みだが怪しい」を見抜く、が論点

従来の検知器の多くは、提案されたパッケージ名がリポジトリに存在するか（HTTP 200か404か）という二択で判定します。しかしこの研究が問題視するのは、攻撃者がすでに幻の名前を登録してしまった後の状況です。この場合、名前は「存在する（200）」ため、単純なレジストリ照合では素通りしてしまいます。

そこで研究チームは、判定を「フラグする／しない」の二値ではなく確率（Beta事後分布）で出す較正（キャリブレーション）層を提案しました。さらにPyPIのメタデータ——パッケージの作成からの経過日数、リリース回数、作者情報、概要文——といった信号を併用し、「登録はされているが不自然なパッケージ」を浮かび上がらせる狙いです。評価は1,734件のPythonスニペット・6種類のLLMを対象に、統計的検定（McNemar検定）や予測の確からしさを測るBrierスコアで行われたとされています。

情シスにとっての意味

この研究が実務者に投げかけるのは、「存在チェックだけでは不十分」というメッセージです。攻撃者が先回りして名前を“実在化”させてしまえば、白黒の照合はすり抜けられる。だからこそパッケージの素性（新しすぎないか、実績があるか、作者は信頼できるか）を多面的に見る必要がある、という指摘は、ツール選定や社内ルール作りの観点として腑に落ちます。

現場目線の課題

正直なところ、情シスがすべての開発端末で「どのパッケージが入ったか」を細部まで把握するのは容易ではありません。生成AIによる補完は速く、開発者はAIが提案したインポート文をほぼ無意識にコピーします。レビューの目が届く前にinstallが走る——この速さこそが攻撃者の追い風です。

また、オープンソースモデルやローカルLLMを各自が自由に使い始めると、出力のばらつきが大きく、幻の出現率も読みにくくなります。利便性を一律に禁止すれば現場は回りませんし、放置すればリスクが積み上がる。この「止めずに、しかし野放しにしない」さじ加減が、当面いちばん悩ましいところだと感じます。

情シスはどうすべきか（公的指針への誘導）

個別の検知ツールに飛びつく前に、まずはソフトウェアサプライチェーン全体をどう管理するかという土台を固めるのが近道です。日本語で参照できる実務的な指針として、IPA（情報処理推進機構）の資料が役立ちます。

そのうえで現場の勘所を一言添えるなら、(1)依存パッケージの導入をレビュー対象に含める（AIの提案でも“実在＝安全”ではないと周知する）、(2)SBOM（ソフトウェア部品表）で何を使っているかを可視化する、(3)新規・低実績パッケージの追加時はひと呼吸おいて素性を確認する、という運用の習慣化が効きます。加えて、開発者への地道な啓発——「AIが出したインポート文をそのまま信じない」という意識づけ——が、ツール導入と同じくらい重要です。

まとめ

  • スロップスクワッティングは実在する脅威。AIが提案する幻のパッケージ名を攻撃者が先回り登録し、サプライチェーンを汚染する。
  • 「存在チェック」だけでは守りきれない。攻撃者が名前を登録済みにすれば素通りするため、パッケージの素性を多面的に見る発想が要る（査読前研究の問題提起）。
  • 土台は王道のサプライチェーン管理。IPAの指針を起点に、レビュー・SBOM・開発者啓発を組み合わせるのが現実的。

出典

コメント

タイトルとURLをコピーしました