存在しないパッケージ：スロップスクワッティングと、エージェントに闇雲にインストールさせない方法

AIでコードを書く人、AIエージェントに作業を任せる人なら誰でも、初心者の方でも読めます。セキュリティの知識は不要です。用語にはどれも身近なたとえを添えています。計算の部分は印をつけてあるので、不要なら読み飛ばせます。

数字は公開情報から取っており、末尾に一覧があります。「例」と書いたものは作った例で、実在の人物や会社には触れていません。AIがパッケージ名を作り出す理由は、まだ誰にも完全には分かっていません。以下のたとえは覚えやすくするための補助であり、仕組みそのものの説明ではありません。

---

まず要点#

• AIはコードを書くとき、もっともらしく聞こえるのに実在しないライブラリを提案することがあります。USENIX Security 2025の大規模な研究は、2024年の実験で、その割合を商用モデルで平均少なくとも5.2%、オープンソースモデルで21.7%と測りました。
• 同じ偽の名前が繰り返し提案されるなら、攻撃者はnpmやPyPIのような公開レジストリでその名前を先に登録し、マルウェアを入れておけます。この攻撃をスロップスクワッティング（slopsquatting）と呼びます。
• その研究で、偽の名前が出たことのある500件の質問を10回ずつ再実行したところ、約43%の偽の名前が10回すべてで再び出ました。作り出された名前は完全なランダムではなく、攻撃者が先読みできる程度には偏っています。
• 実際の実験もあります。空のパッケージhuggingface-cliは3万件を超えるダウンロードを集め、react-codeshiftという名前は200を超えるリポジトリに広がりました。どちらも研究者が登録したもので、マルウェアは入っていません。
• リスクは本物ですが、どのくらい大きいかははっきりしません。大きな被害が確認されたスロップスクワッティング攻撃は、私は見つけられませんでした。それより心配なのは、誰も見ていない状態でエージェントがインストールコマンドを実行することです。
• 防ぐのに高価なツールは要りません。ロックファイルでバージョンを固定し、新しいパッケージはインストール前に確認し、インストールスクリプトを止め、エージェントには承認を求めさせ、隔離環境で動かします。

---

むずかしい言葉をやさしく#

---

1. まずたとえで：店員とそっくりの店#

とても熱心な店員さんに「この機種に合うスマホケースはありますか？」と聞いたとします。店員さんはすぐ「はい、ゾルボ・プロがあります」と答えます。しかしその名前の商品はありません。嘘をついているわけではなく、それらしく聞こえる名前を作るのが上手なだけです。

そこへ、店員さんが多くのお客さんに同じ名前を勧めていることに気づいた詐欺師が現れます。隣に「ゾルボ・プロ」という看板の店を開き、有害な商品を売ります。次に店員さんが案内したお客さんは、その店にまっすぐ入っていきます。

これがスロップスクワッティングです。店員がAI、商品がライブラリ名、店がnpmのようなレジストリ、npm installが店に足を踏み入れることにあたります。打ち間違いと違い、利用者は何も間違えていません。提案に従っただけです。

この用語は、WikipediaとAndrew Nesbitt氏（広めた人）の説明によると、Python Software Foundationのセキュリティ開発者Seth Larson氏が2025年4月に考えたとされています。Larson氏本人の元の投稿は見つけられなかったので、伝聞であり引用ではないものとして扱ってください。

学び： 危険なのはAIが間違えることではなく、その間違いが予測でき、待ち構えている人がいることです。

---

2. 実在する2つの実験と、混同しやすい1つの事件#

2.1 空のhuggingface-cliパッケージ（Lasso Security、2023年から2024年）#

Lasso Securityの研究者Bar Lanyado氏は、AIモデルがPyPIのhuggingface-cliというパッケージのインストールコマンドを繰り返し提案することに気づきました。このパッケージは存在せず、正しくはhuggingface_hub[cli]です。氏はその名前で空のパッケージを登録し、誰かがインストールするかを調べました。

報道によると、約3か月で3万件を超えるダウンロードがありました。媒体によって数字が異なり、約1万5,000から3万5,000と幅があるため、数万件程度と読んでください。The Registerは、この偽の名前がAlibabaの研究用リポジトリのインストール手順にも載っていたこと、氏の報告後に修正されたことも伝えています。

注意点があります。ダウンロード数は被害者がいたことの証明ではありません。AIが生成したコード、人が手順をコピーしたもの、自動スキャナーが、それぞれ何件かは分かっていません。

学び： 繰り返し作り出された名前には本物の人がインストールし、他人の文書にまで紛れ込むことがあります。

2.2 react-codeshiftが200以上のリポジトリへ（Aikido Security、2025年から2026年）#

Aikido Securityによると、2025年10月17日に公開リポジトリへ入ったコミットが、LLMが生成した47個の「スキル」（エージェント向けの指示ファイル）を追加しました。そのうち少なくとも2つにnpx react-codeshiftというコマンドが含まれていました。この名前は、実在するjscodeshiftとreact-codemodを混ぜたように見えます。react-codeshiftというパッケージは存在したことがありませんでした。

これらのファイルはコピーやフォークで広がりました。Aikidoによると、2025年12月には200を超えるリポジトリがこのコマンドを参照しており、研究者Charlie Eriksen氏が名前を登録した2026年1月14日には237以上でした。そのときのGitHubのコード検索では、約215件のファイルが一致しました。数え方で結果が変わるため「200以上」と読むのが安全です。登録直後のダウンロードは初日に約74件、その後は1日に1から4件でした。筆者は、このわずかな流れは実際のエージェントがコマンドを試している兆候かもしれないと述べていますが、これは筆者の推測で、検証された結果ではありません。パッケージは安全な場所取りとして保持され、マルウェアは入っていません。

学び： AIが作った間違いはその場にとどまりません。コピーされ、フォークされ、翻訳され、他のエージェントが読んで従う「標準」になっていきます。

2.3 2026年5月のnpmワーム：危険だが、スロップスクワッティングではない#

Cloud Security Alliance（CSA）の2026年5月17日付の調査ノートは、TeamPCPという集団に関連するnpmワームを説明しています。npmの169パッケージとPyPIの2パッケージにまたがる373の悪意あるバージョンです。ノートによると、このワームはAIコーディングツールのファイルにも設定を書き込み、有効に見えるプロベナンスを持つバージョンもありました。これは他者の報告を伝える二次的なノートなので、引用する前に必ず元の資料を開いてください。CSA自身も、「初」とされる主張の一部は引用元の研究者のものだと述べています。

押さえておきたいのは、これが本物のパッケージの乗っ取りであり、AIが作り出した名前の話ではないことです。それでもここに載せる理由は2つです。1つ目は、レジストリが現実の標的であり、インストールコマンドを実行するエージェントが狙いやすい接点になりうることを示すからです。2つ目は、プロベナンスが絶対の保証ではないことを示すからです。第6章の習慣は、どちらの事件にも効きます。

学び： スロップスクワッティングという言葉にこだわらないでください。大事なのは、AIが作った名前でも、本物のパッケージが汚染された場合でも、自分のマシンに何が入るかを管理することです。

---

3. 仕組みをステップで見る#

4つの輪がつながった鎖とイメージしてみましょう。先にお断りします。モデルがなぜパッケージ名を作り出すのかは、まだ完全には分かっていません。よく言われる見方は、モデルが本物のライブラリらしく見える名前を書こうとし、本物の名前もreact、codemod、cliのような見慣れた語の組み合わせが多い、というものです。これはイメージであり、証明された結論ではありません。

1. あなたが頼む。 あなた（またはエージェント）がCSVを読む機能などを必要とし、AIにインストールコマンド付きのコードを頼みます。
2. AIが名前を提案する。 その名前がレジストリにないことがあります。研究によると、偽の名前のうち実在の名前から1、2文字しか違わないものは約13.4%だけで、主に打ち間違いの問題ではありません。
3. 攻撃者が登録する。 公開レジストリでは、空いている名前をすぐに取れます。偽の名前が繰り返されるなら、攻撃者は人気のモデルに何度も質問してよく出る名前を調べ、それを取れます。
4. インストールが成功する。 最初は「見つからない」エラーで無害です。名前が取られると同じコマンドが成功し、インストールスクリプトがインストールした人のマシンやCIサーバーで動くことがあります。

3.1 自分で計算できる例（例、読み飛ばし可）#

これは作った利用状況を使う例ですが、研究の本物の数字2つを基準にしています。5.2%（商用モデル）と43%（10回すべてで繰り返された偽の名前）です。開発者10人のチームが、1人1営業日あたり5回、AIにインストールコマンドを頼み、20営業日続けたとします。

devs, per_day, days = 10, 5, 20
suggestions = devs * per_day * days          # 1000
fake_rate = 0.052                            # 商用モデルの下限の目安
repeat_rate = 0.43                           # 10回すべてで繰り返された偽の名前
fake = suggestions * fake_rate               # 52
predictable = fake * repeat_rate             # 22.36
check_minutes = fake * 2                     # 1パッケージの確認に2分
print(suggestions, round(fake), round(predictable), check_minutes, check_minutes / devs)
# 1000 52 22 104.0 10.4

読み方：1,000件の提案のうち偽の名前は約52件で、そのうち約22件が攻撃者に予測されうる、繰り返すタイプです。もしそのひとつが取られていて誰も確認しなければ、npm installを1回実行するだけで十分です。一方、新しいパッケージを1つ2分で確認するコストは、チーム全体で月に約104分、1人あたり約10分です。確認は、誤ったインストール1回よりはるかに安くつきます。

注意：43%は、以前に偽の名前が出た500件の質問での測定で、全質問ではありません。5.2%は提案されたパッケージ名ごとの平均で、利用者ごとではありません。あなたのチームの数字は大きく違うかもしれないので、予測ではなく計算の方法として見てください。

---

4. 日常業務で穴になる場所#

工事現場とイメージしてみましょう。腕のいい職人でも、誰も倉庫を点検しなければ、間違った資材を持ち出すことがあります。

4.1 例：エージェントと過ごす朝#

これは作った例で、実在の人物や製品には触れていません。パッケージ名も作り物です。

• 10:00。 開発者がエージェントに頼みます。「このフォルダのCSVを結合して、日付の列をきれいにして。」
• 10:03。 エージェントはcsv-tidy-helper-xというパッケージを使うコードを書き、インストールを実行します。自動承認モードなので、コマンドはそのまま動きます。
• 10:04。 この名前はこれまで存在しませんでしたが、先週、誰かが登録していました。インストールは成功し、インストールスクリプトが動きます。
• 11:30。 コードは問題なく動き、開発者はPRを出します。ロックファイルは14行増えましたが、誰も読みません。

やるべきこと：エージェントをインストールコマンドで止め、確認させることです。開発者が名前を調べると、作成は先週、ダウンロードは3件、ソースリポジトリなし。断るには十分な兆候です。インストールがサンドボックスの中で動いていれば、被害も限定されます。第6章にこれらの防御の層をまとめています。

例は証拠の代わりにはなりません。証拠は次章の研究です。なお、Stanfordの研究（Perryら、2022）は、AIアシスタントを使った人のほうが安全性の低いコードを書き、しかも自分のコードは安全だと強く信じていたと報告しています。だから、確認されていないインストールコマンドを心配するのには根拠があります。あわせてAIが書いたコードのレビューとAIを鵜呑みにしてはいけない理由もご覧ください。

---

5. 研究と事件の数字#

読み方： この表は2つの別のことを示しています。AIがパッケージ名を作り出すこと、作られた名前が登録されて人にインストールされうることには、良い証拠があります。それが実際にどれだけの被害を生んでいるかについては、良い証拠がまだありません。

---

6. 明日から使える習慣#

食材の受け入れ手順のある厨房とイメージしてみましょう。新しい食材にはレシートと受け取りのサインが必要で、誰でも勝手に倉庫へ入れてよいわけではありません。

6.1 8つのステップ#

1. ロックファイルでバージョンを固定し、CIやクリーンなマシンではnpm installの代わりにnpm ciを使います。npmの文書によると、npm ciはロックファイルのとおりにインストールし、package.jsonとずれていればエラーになります。
2. 新しいパッケージはインストール前に確認します。 作成日、ダウンロード数、実在して一致するソースリポジトリ、メンテナー、バージョン履歴。先週作られたのに、ちょうど必要な名前をしているパッケージは、立ち止まるサインです。
3. インストールスクリプトは既定で止めます。 --ignore-scriptsか、.npmrcのignore-scripts=trueを使います。信頼すると決めたパッケージだけ有効にします。
4. 許可リストか社内ミラー（private registry mirror）を使います。承認済みのパッケージだけが入り、知らない名前は見つかりません。
5. プロベナンスを確認します。 パッケージにある場合はnpm audit signaturesを使います。分かるのは出どころであり、きれいだという保証ではないことを忘れないでください。
6. エージェントのインストールコマンドは、必ず人が承認します。 インストールや見知らぬコードの実行に自動承認を有効にしないでください。
7. エージェントはサンドボックスかdevcontainerで動かし、本物のキー、デプロイ用トークン、本番への書き込み権限は中に入れません。
8. すべてのPRでロックファイルの差分を読みます。 新しいパッケージはあるか、名前は何か、どのレジストリか。これはAIが書いたコードのレビューのチェックリストにも入っています。

6.2 覚えておきたい4つのコマンド#

# 1. ロックファイルのとおりに、インストールスクリプトを動かさずにインストール
npm ci --ignore-scripts

# 2. インストール前に確認: 作成日、メンテナー、リポジトリ
npm view some-package time.created time.modified maintainers repository.url
curl -s https://api.npmjs.org/downloads/point/last-week/some-package

# 3. インストール済みのものの署名とプロベナンスを確認
npm audit signatures

# 4. エージェントの変更後: ロックファイルに新しいresolved行はないか
git diff package-lock.json | grep '^+.*"resolved"'

Pythonでは、似たコマンドとしてpip install --require-hashes -r requirements.txtがありますが、各パッケージのハッシュ付きの要件ファイルが必要です。ツールごとに書き方が違うため、お使いのツールの文書を確認してください。

6.3 インストール前の10の質問#

1. このパッケージ名はレジストリに実在しますか。確認はレジストリのページで行いましたか、それとも記憶ですか。
2. いつ作られましたか。数週間未満なら疑います。
3. 週あたりのダウンロード数は、この種のパッケージとして妥当ですか。
4. パッケージ名と一致する公開のソースリポジトリはありますか。
5. メンテナーは誰で、実績はありますか。
6. インストール時にスクリプトを動かしますか。
7. 同じ仕事をする、より有名なパッケージはありませんか。
8. このインストールコマンドは自分のものですか、それとも誰も承認していないエージェントのものですか。
9. このパッケージが悪意あるものなら、このマシンで何に触れられますか。
10. インストール後、ロックファイルは何行増え、それを読みましたか。

---

7. バランスよく：分かっていることと不明なこと#

かなり確か： モデルはパッケージ名を作り出します。実験での測定値は数パーセントから20%超まで幅があります。偽の名前は繰り返されうるし、作られた名前は登録でき、本物の人がインストールします。

不明なこと：

• 新しいモデルやツールでの作り出しの割合。多くのツールはいまWebを検索したりパッケージ名を確認したりするので、割合が下がっているかもしれません。ツールごとの独立した測定は、私は見ていません。
• 実際の被害。大きな被害が確認されたスロップスクワッティング攻撃は見つけられませんでしたが、見つからないことは起きていないことを意味しません。
• 実験は、研究者が無害なパッケージを登録して行ったものです。本物の攻撃者は公表しません。

大げさに考えないでください。 2026年5月のnpmワームのような大きなサプライチェーン事件は、本物のパッケージの乗っ取りから起きています。スロップスクワッティングだけを防ぐと、リスクの大半を見逃します。第6章の習慣はどちらにも効きます。

軽く見ないでください。 予防は安く（上の例で1人あたり月約10分）、確認なしにパッケージを入れるエージェントは、アクセスキーやソースコードに触れられます。AIアプリのOWASP Top 10は、サプライチェーンのリスクをより広い地図の中に置いています。エージェントがMCP経由でツールを呼ぶなら、MCPとは何かも読んでください。ツールのひとつひとつも、自分のところへ入れているものだからです。

---

8. 結論#

AIが作った名前は、誰かが登録し、どこかのマシンが自動でインストールするまでは無害です。リスクの大半は「誰も見ていない」ところにあります。インストールコマンドに関所を作りましょう。バージョンを固定し、新しいパッケージを調べ、スクリプトを止め、エージェントに承認を求めさせ、ロックファイルを読みます。

---

参考資料#

数字は2026年10月時点の公開情報によります。同じ数字でも媒体によって伝え方が違うことがあり、二次的なノートは参考用です。引用する前に、必ず元の資料を開いて確認してください。

• Spracklenら、We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs（USENIX Security 2025）
• Lasso Security、AI Package HallucinationsとThe Register（huggingface-cliの実験）
• Aikido Security、react-codeshiftとスキルファイル内の架空のnpxコマンドに関する記事（2026年）
• 用語の由来（伝聞、元の投稿は未確認）：Wikipedia, SlopsquattingとAndrew Nesbitt, Slopsquatting meets dependency confusion
• Cloud Security Alliance、Mini Shai-Hulud: npm Worm Targets AI Developer Supply Chain（二次的な調査ノート、2026年5月17日）
• npm Docs、Generating provenance statementsとnpm ciコマンド
• Pearceら、Asleep at the Keyboard?（2021年）とPerryら、Do Users Write More Insecure Code with AI Assistants?（Stanford、2022年）