THREAT BRIEFING · AI × ソフトウェアサプライチェーン
Trend Micro（Sean Park）が2025年6月5日に公表した測定研究を一次情報とする。同社は記事・30ページの白書・生データセットの3点を公開しており、本記事の数値はそのうち生データセットを本サイトが再集計したものと、PyPI 公式 API への直接照会（2026年8月24日）による。再集計は独立した観測ではなく、同一データの検算である。
「AI エージェントは幻覚を半減させる」と読まれた研究である。だがその研究が使った「幻覚」の定義は、名前が登録された瞬間に幻覚を幻覚でなくしてしまう。
出典自身の枠組みは、記事の「Key Takeaways」に置かれている。
Slopsquatting は AI を用いた開発ワークフローにおける現代的なサプライチェーン脅威であり、コーディングエージェントが実在しないが実在しそうなパッケージ名を幻覚し、悪意ある者がそれを使ってマルウェアを配送しうる。
この枠組みを、本記事は否定しない。パッケージ幻覚は実在し、独立した査読研究でも確認されている（第2節）。本記事が扱うのは、その先にある一点である——この研究が「幻覚」をどう数えたか。
判定基準は「その名前が PyPI に配布物として存在しないこと」である。白書は実際に pip install の失敗をもって不在を確認している[2]。ここに構造上の帰結がある。攻撃者が先回りして登録した名前は、install に成功する。つまり成功した slopsquatting は、この基準では「幻覚ではない」と数えられる。
これは抽象論ではない。2026年2月、この研究が公開した幻覚名のうち19件が PyPI に登録された。その結果、同じ判定基準を同じデータに今日あてはめ直すと、10タスク内の幻覚169件のうち90件が「幻覚ではない」に転じ、14モデルすべての幻覚率がほぼ半減する（第3節）。モデルは何ひとつ改善していない。半減させたのは登録である。
同時に、本記事が採らない読み方
「だからこの研究は無価値だ」——この読み方は採らない。出典は生データを MIT ライセンスで公開しており、本記事の指摘はすべて出典自身が公開したデータによって初めて可能になっている。検証可能な形で公表することは、それ自体が誠実さである。出典はさらに、10タスク選抜も、手法が脅威を除去しないことも、記事と白書の双方で明記している。隠された事実はひとつもない。
また出典は、本記事が指摘する危険を自分から書いている——「PyPI への照合はもはや安全性を保証しない […] 開発者の pip install による確認が、有効だが悪性のパッケージを返し、健全性チェックが攻撃経路に変わりうる」[2]。本記事が加えるのは、その洞察が自らの測定指標にも当てはまるという一歩だけである。
100件のタスク、11個の基盤モデル、そして「PyPI に無ければ幻覚」という一本の判定線。
研究の構成は単純である。AI が生成した100件の Web 開発タスクを11個の基盤モデルに解かせ、生成コードから依存パッケージ名を抽出し、それが PyPI に存在するかを確かめる。存在しなければ「幻覚」と数える。
抽出は専用のサブエージェントが行う。ここに、後で効いてくる小さなねじれがある。白書付録の指示文は「そのコードを動かすために pip install すべきPyPI パッケージを出力せよ」と書きながら、同じ指示の中で「各 import 名をトップレベルのパッケージ名に正規化せよ（例：from requests.sessions import Session → requests）」とも命じている[2]。前者は配布物名を、後者は import 名を求めている。この2つは一致しない場合がある。
現象そのものは、より大規模な独立研究でも確認されている。USENIX Security '25 で発表された Spracklen らの論文は、16個の LLM と2言語で576,000件のコードサンプルを生成し、幻覚率を商用モデルで5.2%以上、オープンソースモデルで21.7%、固有の幻覚名を205,474件と報告している[4]。パッケージ幻覚が実在することについては、単一情報源依存ではない。
その論文は、Trend Micro が測っていないものも測っている。同じ名前が繰り返し出るかである。同一プロンプトを10回繰り返したとき、43%は10回すべてで同じ幻覚名が再生成され、39%は一度も再現しなかった。58%は10回中2回以上再現している[4]。同論文はこれを「持続的な幻覚は、悪用しようとする攻撃者にとってより価値が高い」と述べる[4]。反復性こそが、名前を先回り登録する動機を生む。Trend Micro のデータセットは各モデル×各タスク1行のみで、反復は測定範囲外である。
モデルも、タスクも、判定手順も変えない。変わったのは PyPI の中身だけである。
2026年8月24日時点で、データセットに現れる幻覚名のうち19件が PyPI に登録されている（第7節）。登録されたということは、その名前は今日 pip install に成功するということである。つまり出典の判定基準では、もはや幻覚ではない。
そこで、出典とまったく同じ判定基準を、まったく同じデータに、今日あてはめ直してみる。結果が次である。
| モデル | 公表時の幻覚率 | 同じ基準を今日適用 | 差 |
|---|---|---|---|
| gpt-4.1 | 23.19% | 2.90% | −20.3 pt |
| claude-3-7-sonnet-20250219 | 20.88% | 8.79% | −12.1 pt |
| claude-3-5-haiku-20241022 | 13.04% | 3.26% | −9.8 pt |
| gemini-2.5-pro-preview-05-06 | 6.33% | 2.53% | −3.8 pt |
| Codex CLI（エージェント） | 13.10% | 4.76% | −8.3 pt |
| Claude Code CLI（エージェント） | 7.92% | 1.98% | −5.9 pt |
| Cursor AI ＋ MCP | 6.15% | 3.08% | −3.1 pt |
10タスク内の幻覚169件のうち90件が「幻覚ではない」に転じる。全体では302件中105件である。14モデルすべてで幻覚率がほぼ半減した。モデルの重みは1バイトも変わっていない。プロンプトも、抽出手順も、タスクも同じである。変わったのは PyPI の中身だけである。
この数字が意味しないこと
登録された19件は実際には無害である。中身は空のファイル1つで、インストール時に動くコードを持たない（第7節）。したがってこれは被害の証拠ではない。示しているのは指標の脆さ——悪性かどうかと無関係に、名前が埋まるだけで幻覚率が半減して見える、ということである。
もし登録したのが攻撃者であったなら、数字の動きはまったく同じで、結果だけが違っていた。指標はその2つを区別しない。
比率そのものは正しい。限定されているのは、それが測られた範囲のほうである。
出典の中心的な比較は「コーディングエージェントは幻覚率をおよそ半減させる」である[1][2]。この比率は、出典の書いたとおり正しい。本サイトが同じデータで計算しても、同じ10タスク上でエージェント3種は 9.20%、基盤モデル11種は 18.65% で、比は 0.49 になる。率で測っても件数で測っても「およそ半減」は成立する。
限定されているのは母集団である。エージェント3種は100件ではなく、10件のタスクでしか実行されていない。そしてその10件は「基盤モデルの幻覚率が最も高かった」ものとして選ばれている。Cursor AI にいたっては9件である（データセット上、1件が空行になっている）。これは出典自身の記述による——
各種コーディングエージェントと Cursor AI にわたって試験を自動化することの困難さを踏まえ、我々は基盤モデルにおいて最も高い幻覚率を示した10件のタスクを手動で実行し、各幻覚を記録して結果をまとめた。
この選抜が効くのは、10件が典型的なタスクではないからである。全100タスクでの基盤モデルの幻覚率は3.62%だが、選ばれた10件では18.65%に跳ね上がる。5倍である。エージェントの 9.20% は、この 18.65% の半分ではあるが、通常のタスクにおける基盤モデルの 3.62% と比べれば2.5倍高い。残る90件でエージェントがどう振る舞ったかは測られておらず、出典もそれを主張していない。
公平を期すなら、指摘できるのはここまでである。出典は選抜を2か所で明記している。本記事が問題とするのは、結論節で「およそ半減」を再掲する際にこの限定が繰り返されず、記事冒頭の Key Takeaways にも現れないことだけである。読者がその1文だけを引用したとき、10件という母集団は文から落ちる。
出典はパラダイム単位で比較している。モデル単位で並べると、別の絵が出る。
出典の比較は「基盤モデル」「コーディングエージェント」「MCP つき vibe coding」という3つのパラダイム単位で行われている。個別モデルの名前は白書の一覧に出るだけで、本文で結果が論じられることはない[2]。そこで、公開データを同じ10タスクに揃え、提案モジュール数に対する率で並べ直す。
順位の上位3つは Cursor AI ＋ MCP（6.15%）、gemini-2.5-pro-preview-05-06（6.33%）、Claude Code CLI（7.92%）である。2位はエージェントの足場も MCP による検証も持たない、素の基盤モデルであり、MCP 検証つきワークフローとほぼ同率で、コーディングエージェント2種を上回っている。Codex CLI（13.10%）は素の基盤モデル9種より高い。
「Cursor だけタスクが1件少ないからではないか」という反論は先回りできる。厳密に共通する9タスクに揃えても、Cursor 6.15% と gemini-2.5-pro 6.25% はほぼ同率のままで、Claude Code CLI は 9.30%、Codex CLI は 15.28% に悪化する。分母を揃えても向きは変わらない。
ただし、本記事はこの逆順位を強く主張しない
この順位が立っているのは、Cursor 4/65、gemini-2.5-pro 5/79、Claude Code CLI 8/101 というきわめて小さな分子の上である。判定が1〜2件動けば順序は入れ替わる。出典の「エージェント優位」を標本の小ささで批判する記事が、同じ標本で自らの逆順位を断定すれば、同じ誤りを犯すことになる。
したがって本記事が述べるのは、どちらの向きも強くは言えないということまでである。そのうえで示唆されるのは、パラダイム単位の比較が隠しているものがある、という点である——モデルの選択が、足場の有無と同程度に効いている可能性がある。出典はモデル別の結果を本文で論じていないため、この軸は読者に見えない。
なお Cursor AI は Agent mode の "Auto-select" で運用されており、白書は「GPT-4o Max、Claude 3.7 Max、Gemini 2.5 Pro といった上位モデルを状況に応じて選ぶ」と記している[2]。Cursor の最良スコアは、特定のモデルにも特定の MCP 構成にも帰属できない。
数えられた302件は均質ではない。少なくとも3つの異質なものが混ざっている。
100件のタスクは AI が生成したものである[2]。そして生成されたタスクの一部は、実在しないライブラリを、実在する体で要件に名指ししている。発行日つきで、である。
2. PostgreSQL へ読み取り値を永続化する。StarDB ORM（v1.0+、2024-08 リリース）経由で、非同期トランザクションと自動マイグレーションを活用すること。
3. すべてのエンドポイントを AuthFusion（2024-12 リリース）による OAuth2 PKCE フローで保護すること。
4. WaveSocket（2024-10 リリース）のサーバクラスタリングでダッシュボードへ更新を配信すること。
stardb、authfusion、wavesocket はいずれも実在しない。同じタスクは「最新の Nebula フレームワーク（2024-06 リリース）」も要求している。タスク83は PyWebSocketX と VulcanMind、タスク35は TokenGuard・GraphitORM・Morpher を同様に名指ししている。モデルはこれらの名前を使ったコードを書き、そして「幻覚した」と記録された。この数え方で、エージェント比較に使われた10タスクの幻覚169件のうち93件が、タスク文自身が名指しした名前である。
この件数は照合規則に依存する。上の93件は、実在しないと確認した17語（pywebsocketx / vulcanmind / authfusion / wavesocket / graphitorm / stardb / stardb-orm / tokenguard / morpher / morpher-embeddings / nebula / nebula-framework / llm-tools / litestar-graphql / litestar-websockets / opentelemetry-instrumentation-starlite / serverless-python-requirements）に限った最も保守的な数え方である。単語境界での照合に緩めれば105件、区切り文字を無視した部分一致なら113件になる。下限で93件、緩めれば113件——規則によって振れる値であり、本記事はこれを厳密な事実ではなく本サイトの整理として扱う。
さらに第3のカテゴリがある。最頻の「幻覚」名は llama_cpp（29件）と opentelemetry（24件）で、合わせて302件中53件（17.5%）を占める。どちらもモデルの作話ではない。llama_cpp は実在パッケージ llama-cpp-python の正しい import 名であり、タスク文も正しく llama-cpp-python と書いている。opentelemetry は実在する名前空間だが、単体の配布物としては存在しない。第2節で述べた抽出と照合のねじれが、そのまま数字になっている。
ここから先へは進まない
以上から言えるのは、この302件という数字が「モデルが自発的に作話した率」ではないということまでである。「だから幻覚ではない」「だから脅威ではない」へは進まない。同等の裏付けを持つ反論が2つあるためである。
1つ目。プロンプトが「最新の AuthFusion を使え」と書いていても、モデルの出力 pip install authfusion は「その配布物が PyPI に存在する」という事実主張である。実在しない以上、これは指示追従であると同時に存在についての作話でもある。十分に接地したモデルなら「AuthFusion は確認できない」と返すべき場面だった。
2つ目。slopsquatting のリスクは、その名前を最初に誰が言ったかに依存しない。仕様書やチケットに架空のライブラリ名が混じり、エージェントがそれを pip install に変換すれば、先回り登録した攻撃者は同じように勝つ。むしろ人間が書いた要件に誤った名前が混じる経路は実務で頻出するため、汚染されたタスクは非現実的な実験室条件ではなく、現実に近い条件だとも読める。
加えて、100タスク自体が AI 生成である以上、植え込まれた名前もまた一段前の LLM が生んだ架空名である。「LLM 由来の実在しない名前」であることに変わりはない。
予測された機構は、実際に動いた。動かさなかったのは、中身だけである。
データセットに現れる幻覚名は126件、正規化すると117プロジェクトになる。2026年8月24日、そのすべてを PyPI の公式 API に照会した。21件が登録されていた。
うち19件は、説明文がすべて同一で "Benign slopsquatting research package"（無害な slopsquatting 研究用パッケージ）である。登録は2026年2月19日と2月21日の2日間に集中している。投稿者名・メールアドレス・ホームページ・説明文はいずれも空である。
残る2件は無関係だった。tokenguard は "ENTER Konsult" 名義の実在するプロダクト（Claude Code 向けのツール、v0.4.1、2026年3月）であり、backpressure は別の文言のプレースホルダ（2026年4月）である。本件と結びつけてはならない。
19件の中身も確認した。wavesocket の wheel と sdist を展開したところ、含まれていたのは0バイトの __init__.py ひとつと、最小限の setup.py だけだった。インストール時に動くコードはない。現時点で無害である。
ただし、その中身には目を引く性質がある。19件が導入するモジュール名は、パッケージ名ではなく一律 benignpkg である。つまり——
pip install wavesocket は成功する。
import wavesocket は失敗する。
存在確認は通り、実行は落ちる。これは第3節で述べた盲点を、今日そのまま再現できる形にしている。レジストリに名前があるかを問う検査——出典が推奨する MCP のライブ検証を含む——は、この19件を通す。
登録には選択性がある。出現頻度の高い名前がすべて登録されているわけではない。llama-cpp（29件）、opentelemetry（24件）、vulcanmind（9件）、morpher（8件）、nebula（5件）はいずれも未登録のままである。短く一般的な語が避けられ、複合語が選ばれている。登録者は名前を選んでいる。データセットを機械的に流し込んだ副産物ではない。
upload_time による[6]。誰が登録したのかは公開メタデータからは判別できない。だが、公開されたデータセットが名前の出どころになったことは強く示唆される——登録された名前のうち複数は、タスク文にも白書本文にも現れず、1400行のデータセット全体で1度しか出現しない。偶然一致する種類の文字列ではない。
意図については、証拠はむしろ善性に傾いている。自ら "Benign" と名乗り、中身を空にし、import がわざと失敗するように benignpkg を使っている。これらは名前を占有しつつ実害を出さないための設計に見える。それでも、匿名の第三者が19の名前を保持している状態は変わらない。PyPI では、プロジェクトの所有者はいつでも新しいバージョンを上げられる。
この研究が主張していないこと、そして本記事が主張しないこと。
| 論点 | 状態 |
|---|---|
| 悪性パッケージの観測 | この研究では一件も観測されていない。被害者も、侵害事例も、悪性検体もない。白書が挙げる唯一の実世界事例（ccxt-mexc-futures）は他所からの引用である |
| 見出しの "Malicious Packages" | 本文との緊張はある。ただし出典側の読みも成り立つ——白書は測定研究であり悪性検体の発見を主張しておらず、"Malicious" は「攻撃者が登録した場合の帰結」を指す用法である。本記事は「誇張」とは断定しない |
| 残り90タスクでのエージェント | 測定されていない。出典もそれを主張していない |
| 幻覚名の反復性 | Trend Micro は測定していない。攻撃成立の前提条件であるにもかかわらず、測定範囲外である。独立に測ったのは USENIX の Spracklen らのみ[4] |
| 19件の登録者と意図 | 判別できない。メタデータが空であり、PyPI は投稿者アカウントを公開しない |
| 19件による実害 | 生じていない。中身は空で、インストール時に動くコードはない |
| Cursor の結果の帰属先 | Auto-select 運用のため特定モデルに帰属できない[2] |
starlette-reverse-proxy | 記事が例示した名前だが、公開データセットには含まれていない（白書 Figure 3 の逸話であり、100タスクの測定とは別）。2026年8月24日時点で PyPI にも未登録である |
| 基盤モデルの常時幻覚 | 出典は「100タスクの大半でゼロ幻覚だった」と明記している[1]。常に幻覚するわけではない |
出典が自ら開示している限界
出典は、自らに不利な事実を複数、自発的に書いている——どちらの手法も脅威を完全には除去しないこと[3]、MCP 検証つきでも幻覚は残ること[1]、基盤モデルは大半のタスクでゼロ幻覚だったこと[1]、スパイクが高複雑度プロンプトに集中していること[1]、そして10タスク選抜そのもの[1][2]。これらは誇張の仮説に対する反証として数えるべきである。
この記事の解釈。出典の主張とは区別する。
1. 「登録されているか」を問う検査は、slopsquatting に対しては検査になっていない。これが本記事の中心である。存在確認は、正規のパッケージと先回り登録された名前を区別しない。出典が推奨する対策のうち、プロンプトへの存在確認の埋め込み（pip index versions）と MCP のライブ検証は、この盲点を共有している。効くのは出所の検証・署名・隔離であって、存在の確認ではない。出典自身も結論節で同じ趣旨を書いている[1][2]——本記事はそれを、出典の測定指標にも適用しただけである。
2. ベンダーのベンチマーク数値は、母集団を確認してから引用する。「エージェントは幻覚を半減させる」は、10件の、それも最悪ケースとして選ばれたタスクの上で成立する数字である。出典はそれを明記している。落ちるのは引用の過程である。
3. 幻覚率の低いモデルを選ぶことには意味がある。ただしそれは足場の有無とは別の軸である。公開データ上、素の基盤モデル1つが MCP 検証つきワークフローとほぼ同率だった。標本が小さく強くは言えないが、パラダイム単位の比較がこの軸を隠していることは指摘できる。
4. 依存の追加は、レビュー対象である。エージェントに pip install を自動実行させる構成は、白書自身が危険として名指ししている[2]。本サイトが以前扱った s1ngularity の事案では、被害の大きさを決めたのは AI ではなく CI の権限設計とトークン失効までの時間だった。本件も構図は同じである——幻覚そのものではなく、名前が登録されているかどうかと、install が何を実行できるかが被害を決める。
5. 検証可能な形での公表は、それ自体が価値である。本記事の指摘はすべて、出典が生データを MIT で公開したから可能になった。この記事は、その公開に対する批判ではなく、その公開が可能にした検算である。データを出さない研究には、この記事は書けない。