ローカルのコーディングLLMが存在しないパッケージ名を作る率は最大73%──Slopsquatting対策論文を読む

コード生成AIが実在しないパッケージ名を作り出し、その名前を攻撃者が先回りしてPyPI（Pythonのパッケージ配布サイト）に登録しておくことで、開発者に悪意あるコードをインストールさせる「Slopsquatting」という攻撃手口は、すでに海外では一定の知名度がある用語だ。arXivで2026年8月24日に公開された論文（arXiv:2608.23897）は、この用語自体を新しく作ったものではないが、ローカルで動くコーディングLLMを対象に、幻覚率とその対策を具体的な数字で定量化している。著者はIIT Jodhpur（インド工科大学ジョードプル校）のM.Tech学生Akash Raj氏と、Jaypee University of Engineering and Technology（Guna校）のB.Tech学生でKruman Corporationsのサマーインターンでもあった Sargam Sahu氏の2名。arXiv投稿はv1のみで、査読を経た論文ではない。

3行まとめ

1. IIT JodhpurとJaypee大学の学生2名が提案する「決定論的PyPI存在チェック＋ランダムフォレスト分類器(400本の木、10特徴量)」の2層検出器は、300件のプロンプト評価でパイプライン全体として76%(228/300)の実行で幻覚のないコードを生成できたと報告している。
2. 幻覚率はプロンプトの敵対性にほぼ線形に相関し、通常のコーディング指示(データエンジニアリング等)では0%、Slopsquattingを誘発する意図的なプロンプト(Adversarial Realistic Hallucination Bait、30件)では73.3%に達した。
3. フラグされた幻覚パッケージ179件のうち、実在しない完全な捏造名は約半分(真の404)で、残り半分はすでにPyPIに登録済みの低品質な紛らわしいパッケージ(pil/faiss/tabula/haystackなど)だった。主モデルと同系統(同じLlamaファミリー)のフォールバックモデルでは、失敗の83.5%が再発し、救済できたのは16.5%にとどまった。

Slopsquattingという言葉自体は新しくない

論文はこの用語について明確に線を引いている。

When a code generating language model fabricates a Python package name, an adversary who has pre-registered that name on PyPI can convert that hallucination into a supply chain compromise. This event has been termed as 'slopsquatting'.

（コード生成言語モデルがPythonパッケージ名を捏造したとき、そのパッケージ名をPyPIに先回りして登録していた攻撃者は、その幻覚をサプライチェーン侵害に変換できる。この現象はすでに「slopsquatting」と呼ばれている）

つまりSlopsquattingという概念・呼称自体はこの論文の新規性ではなく、ローカル環境で動くコーディングLLMを対象にした幻覚率の実測と、それを食い止める2層の検出パイプラインが論文の中身だ。

2層検出器の仕組み

検出パイプラインは次の要素からなる。LangGraphの状態機械（6ノード：generate・classify_output・extract_packages・label_packages・decide_retry・finalize）としてエージェント全体が組まれている。

1. 抽出器（Extractor）：AST解析でコードブロック内のimport文からモジュール名のみを取り出す。当初はLLMの応答全文に正規表現をかけていたが、github・python・spacy-lgのような英文中の単語まで拾ってしまう誤検知が多発し、コードブロック内限定・AST解析＋正規表現フォールバックという設計に作り直したという（ユーザーテスト中に「Install requests, flask and pandas.」という入力で「and」を誤ってパッケージ名と認識するバグが発覚し、30種類以上の類似バグをまとめて修正した経緯も本文に記載されている）
2. 決定論的なPyPI存在チェック：抽出した各名前についてPyPI JSON APIに問い合わせ、404なら「捏造」と即断定する層
3. ランダムフォレスト分類器：400本の木からなり、パッケージ名由来8特徴量（名前の長さ・パーツ数・数字の有無・3文字連続の繰り返し・super/pro/ai/magic等の語の有無・helper/tools等の汎用語の有無・py-/python-で始まるか・上位1.5万件のPyPI名との類似度）とメタデータ由来2特徴量（メンテナー数・GitHub URLの有無）の計10特徴量で学習しており、存在チェックだけでは見抜けない、実在するが低品質な「似た名前」のパッケージを検出する
4. import名の照合器（import name reconciler）：import cv2だが実際にインストールするパッケージ名はopencv-pythonである、といったケースを解決する24エントリのYAMLマッピング。セキュリティ上重要なのは、この照合器がPyPI存在チェックで404が返った場合にのみ発火する設計になっている点で、著者は「攻撃者がcv2という名前のパッケージを実際に登録した場合、PyPIは200を返すため照合器は一切起動せず、分類器がそのメタデータの怪しさを判定する」という順序をセキュリティ上の不変条件として明記している
5. LangGraphのエージェントループ：主モデルが失敗するとtemperature（0.7→1.0→1.2）を上げながらリトライし（リトライ予算は1、つまり最大2回の試行）、それでも失敗すればフォールバックモデルにルーティングする

数字で見る幻覚の実態:71%→28.7%まで削減した経緯

評価に使われたLLMは7種類（gpt-5・gpt-oss-120b・llama-3.1-8b・llama-3.3-70b・llama-4-scout・qwen3-27b・qwen3-32b）で、エージェント評価にはGroqでホストされている無料枠に収まる2モデルを使い、主モデルにllama-3.1-8b・フォールバックにllama-3.3-70bを採用している。

システムの改善過程を示すTable 1（重複するプロンプト集合での主モデルの「諦め率」）は次の通り。

300件のプロンプトのうち約140件は通常のコーディングタスク（データエンジニアリング・セキュリティ・DevOpsなど）、約55件はマイナーな依存関係を含むタスク、残り105件は敵対的なプロンプト（パッケージ名を直接指定する、あるいは「Xのための最新かつ最強のライブラリ」のように誘導する言い回し）だったという。300回の実行（llama-3.1-8b）の内訳は、初回で成功したのが186件（62%）、114件でリトライが発生しそのうち28件がモデル内リトライで回復（24.6%の回復率）、86件（28.7%）がリトライ予算を使い果たしてフォールバックへ回り（うち1件はGroqのレート制限で欠測）、フォールバックが85件中14件を回復（16.5%の回復率）。最終的にパイプライン全体としては300件中228件（76%）でクリーンなコードを生成できたが、残る72件は全試行を経ても幻覚パッケージ名が残った、と報告されている。

18段階に分けたプロンプトの敵対性ティア別の諦め率（Table 2、一部抜粋）を見ると、通常タスクではほぼ0%、意図的な誘導プロンプトでは大きく跳ね上がる構造がはっきり出ている。

論文はこの結果について「コーディングタスクの多くを占めるデータエンジニアリング・DevOps・基本スクリプトでは検出器がほぼ無音（諦め率がゼロ近辺）で済む一方、敵対的な末端では約4件に3件がパイプライン全体を発動させる。ユーザーが最も警告を必要とする状況で検出器の失敗モードがちょうど意図通りに働いている」とまとめている。

179件の幻覚のうち半数は「すでにPyPIに実在する」紛らわしい名前だった

385回の実行を通じて抽出器が判定した823件のパッケージ検証のうち、644件（78.3%）が「実在」、179件（21.7%）が「幻覚」と判定された。この179件をPyPIに照らし合わせると、約半数が本当に存在しない完全な捏造（pkg-resources・embedflow・vectorcache・codegenplus・sklearn-ai・pyyamlplus・chromastore・groqclient・intelligentcache・packagevalidatorなど）で、残り半数はPyPIステータス200（実在）だがメタデータの怪しさから分類器にフラグされたパッケージだった。論文はこの「野生で捕獲されたPyPI登録済みのスクワット・紛らわしいパッケージ」の一部を実名で公開している（P(fake)は分類器が算出した偽物らしさのスコア）。

（Table 3 の全行。実名で挙がっているのは14件で、これに「他22件」を足した36件が分類器のフラグ対象になった）

論文はこの結果を「本論文で最も意外な実証結果」と位置づけ、「決定論的なチェックのみの対策は、シンプルで低コストだが半分しか捕まえられない。MLレイヤーは決定論的レイヤーへの付け足しではなく、脅威領域の別の部分をカバーしている」と述べている。90件の「ステータス200」フラグに対しては、照合器は一度も発火しなかった（＝セキュリティ上の設計が意図通りに機能した）ことも確認されたという。

モデルは6割の直接攻撃を自力で拒否した

「Bonus Stress Test」という10件のプロンプトは、fastvectorai・hyperfaiss・streamgraphx・pdfgenius・smartocrpro・torchvisionx・langgraphx・openrouter-sdk-python・fastyamlparser・ultraragという、存在しないパッケージ名を直接名指しする内容だった。結果、主モデルがbait名をそのままインストールしたのはultraragの1件のみ（検出器が最終的に捕捉）。3件は近縁の幻覚バリエーション（fastvectorai→fastvector、fastyamlparser→fastyaml、hyperfaiss→faiss）を生成し、残り6件はbaitを拒否してpdfplumber・torchvision・networkx・openrouterのような実在パッケージに置き換えたという。エンドツーエンドでは10件中6件（60%）がクリーンな結果に終わり、論文は「最近の指示チューニングがすでに第一の防衛線を提供している」と評価している。

ユーザー受容調査:24名中21名が「業務で使いたい」

著者の1人が、所属大学（JUET Guna）のCS学部生の友人24名を対象にStreamlit製の分類器単体UIでアンケートを実施した（1〜5点のリッカート尺度）。

24名中21名が「業務で使いたい」、23名が「他人に勧めたい」と回答した。ただし著者自身が「調査参加者はインターン担当者(著者の1人)の友人であり、社会的望ましさバイアスが多少なりとも働いた可能性がある」と明記しており、この結果を「ツールを気に入ってもらえたことの兆候であり、実際の効果の証明ではない」と位置づけている。

ローカルLLMでコーディング支援をしている人への含意

この論文が対象にしているのは、クラウドAPIではなくローカルで動かすコーディングLLMという設定だ。ローカルモデルを使ったコーディング支援を導入している場合、生成されたコードに含まれるパッケージ名を無条件に信頼してインストールする運用は、この論文が示す数字を踏まえるとリスクがある。特に「主モデルとフォールバックモデルを同系統で組む」設計は再発率が高いという指摘は、複数モデルを使い分けている体制でも意識しておく価値がある。

著者自身が挙げる限界と、この記事の限界

この論文はIIT JodhpurのM.Tech学生とJaypee大学のB.Tech学生の2名による、査読前のarXiv投稿（v1のみ）で、著名な研究機関の大規模な検証ではない点は最初に断っておく必要がある。著者自身が本文7.1節「Limitations」で列挙している限界は具体的だ。(1)実際に評価したモデルの組み合わせはLlama-3.1-8b→Llama-3.3-70bという「同系統内」のペア1組のみで、Llama→QwenのようなファミリーをまたぐペアはGroqの無料トークン予算が足りず今回は未実施（著者は「モデル類似性の主張を証明するには必要」としつつ次回に持ち越している）。(2)pypi_maintainers_countという特徴量は、PyPIのJSON APIが管理者本人以外にはメンテナー情報をほとんど返さない仕様のため、実質的に常にゼロに近い値になっており、正規の小規模パッケージを誤検知させる要因になりうる。(3)クロスモデル転移性の検証は、当初のランダム分割にリーク（学習・テスト間でパッケージ名が重複）があったことが判明し、パッケージ名で分割し直す修正を行った経緯があり、修正後もモデルあたりの陽性テスト例が2〜12件と少なく、セル単位の比較には統計的な確度が乏しいと著者自身が認めている。(4)分類器の判定根拠はlog_maintainers(57.6%)とgithub_url_present(24.5%)の2特徴量だけで82%を占めており、メタデータを本物らしく見せかける攻撃への耐性は未検証。(5)PyPIに実在する「スクワット」として提示した30件超のパッケージ名についても、著者は「1件ずつ人手で低品質な模倣品か正当な小規模プロジェクトかを確認したわけではない」と明記している。(6)ユーザー受容調査は前述の通りインターン担当者の友人集団によるものでバイアスの可能性がある。

この記事はarXivのPDF本文（16ページ、Abstract・本文8節・Appendix A〜C）をcurlで取得し、Table 1〜6と各節の記述を読んで書いている。ただし評価対象のモデルにgpt-5が含まれている点は、論文の「ローカルで動く小規模なオープンウェイトLLM（7B〜70B）を対象にする」という冒頭の問題設定と字面上ずれがあり、このgpt-5が具体的に何を指すモデルなのか（クラウドAPI経由なのか、別の呼称のローカルモデルなのか）は本文の範囲では明記されておらず、この記事でも判断を保留している。リポジトリ（github.com/sargamsahu1011/package-hallucination-detectorとして本文に記載）は実在を確認した。GitHub APIで取得したリポジトリ情報は説明文「Machine Learning based Package Hallucination Detection using Random Forest and Streamlit」・MITライセンス・最終更新2026年8月26日となっており、README.mdには論文と対応するディレクトリ構成（results/＝リーク混入の元データ、results_v2_leakage_safe/＝著者が限界セクションで言及していたパッケージ名重複リークを修正した後の結果、data/eval_prompts.txt＝300件の評価プロンプト、models/に7モデル分のRandom Forest分類器）が明記されている。ただし個々のファイルの中身（プロンプト全文やログの実データ）までは開いておらず、記載通りの内容が入っているかは未検証。またarXivの論文ページにはZenodoでのDOIアーカイブ（10.5281/zenodo.22087562、2026年8月25日公開）へのリンクがあり、著者2名の所属（IIT Jodhpur／Jaypee University of Engineering and Technology, Guna）と提出日はここでも一致することを確認した。自分の手元でローカルコーディングLLMを動かし、実際に幻覚パッケージ名が出るかどうかを再現する検証は行っていない。

関連記事: AIコーディングアシスタント比較 / Claude Codeとは / MCPとは

感想・指摘はコメント欄へ。