AIが口にした“存在しないパッケージ名”が、攻撃者ゼロで237カ所に広がった

2026年1月14日、セキュリティ企業 Aikido Security の研究者チャーリー・エリクセン氏が、npm に react-codeshift というパッケージを登録しました。

その名前は、それまで一度も存在したことがありませんでした。誰も公開したことがない。にもかかわらず、237 のリポジトリが、すでにその名前を参照していました。「これをインストールせよ」と、AIエージェントに向けて書かれた手順書の中で。

登録した当日、約74件のダウンロードがありました。そして翌日からも、4件、1件、3件、1件、3件と、細く、しかし途切れずに続きました。誰か、あるいは何かが、存在しないはずの部品を、毎日取りに来ていたということです。ゼロになる日は、ありませんでした。

攻撃者は、ひとりもいません。

何が起きたのか

話は、AIがコードを書くときの癖から始まります。

AIにプログラムを書かせると、実在しない部品(パッケージ)の名前を、あたかも実在するかのように書くことがあります。「幻覚」と呼ばれる現象です。2024年に発表された調査では、16のモデルに57万6千件のコードを書かせたところ、そのうち19.7%——約44万件——に、実在しない部品の名前が1つ以上含まれていました

ここで重要なのは、AIの幻覚がてんでばらばらではないことです。独立研究者が2026年4月に最新の5つのモデルを調べた報告では、5つ全部がまったく同じ名前を発明していた例が127個見つかっています。作った会社も設計も違うAIが、同じ「無いもの」を口にする。

つまり、どんな嘘が出てくるかは、ある程度わかる。ここに目をつけた攻撃手法が slopsquatting(スロップスクワッティング) です。Python Software Foundation のセス・ラーソン氏が名付けたとされています。AIが繰り返し口にする「実在しない名前」を、攻撃者が先回りして本物として登録しておく。あとはAIが、開発者を自分の罠に案内してくれます。

昔からある「タイポスクワッティング」と、待ち伏せる相手が違います。

タイポスクワッティングとslopsquattingの違いを示す図
待ち伏せる相手が、人間の指からAIの記憶に変わった

タイポスクワッティングは、人間の打ち間違いを待ちます。reqeusts のような打ち損じを登録しておく。だから、注意深い人には効きません。

slopsquatting は、AIの間違いを待ちます。開発者がどれだけ注意深くても、AIが自信たっぷりに提示した名前を、そのままコピーしてしまえば同じことです。

先に書いておくと、今回の react-codeshift実際に被害が出たという報告はありません。悪意ある誰かが名前を取る前に、研究者が押さえたからです。これは「防がれた」話であって、「やられた」話ではない。それでも見る価値があるのは、被害が出る一歩手前の風景が、これほど具体的に写っている事例が珍しいからです。

「攻撃者がいない」ということの意味

slopsquatting という手法自体は、以前から知られていました。今回のエリクセン氏の報告が新しいのは、攻撃者が一人もいない状態で、同じ被害の準備がすでに整っていたことを示した点にあります。

彼が辿った経路は、こうです。

幻覚したパッケージ名が237リポジトリに広がるまでの流れ図
誰も悪意を持っていない。誰も確かめなかっただけ

出発点は、2025年10月17日の、たった1つのコミットでした。wshobson/agents というリポジトリに、AIが生成した47個の「エージェント・スキル」が追加されます。

エージェント・スキルというのは、AIに作業手順を教えるためのファイルです。「この作業をするときは、この道具を、こう使いなさい」と書いておくと、AIがそれを読んで実行する。Claude Code のスキルやプラグインが、この形をとっています(スキルとサブエージェントの仕組みはこちらで解説しています)。

その47個のスキルは、AIに書かせたものでした。そして、その中に npx react-codeshift という一行が混じっていました。npx は「この部品を取ってきて実行する」という命令です。実在する道具は react-codemod でした。AIが、似た名前をでっち上げていたわけです。

あとは、人間がそれを運びました。エリクセン氏の記述を借りれば、そのファイルは「コピペされ、フォークされ、日本語に翻訳され、一度も検証されなかった」。

ここは正確に読む必要があります。237のプロジェクトが、それぞれ独立にこの名前を選んだわけではありません。もとをたどれば1つのコミットで、そこからコピーと複製で237の参照にふくらんだ、という筋です。237という数字は、エリクセン氏が GitHub を検索して数えたもので(画面上の表示は「215ファイル」)、第三者による検証は行われていません。

気づいたきっかけは、名前を登録したあとの、ダウンロード数の形でした。

自動スキャナがパッケージを舐めているだけなら、初日に60〜100件のダウンロードが来て、翌日からゼロになります。ところが react-codeshift は、初日に約74件のあと、1日1〜4件が続きました。この形から、エリクセン氏は「本物の利用だ」と判断しています。

237の参照に対して、実際に取りに来るのは1日数件。数としては小さい。けれどゼロにならないことのほうが重要です。少なくとも研究者が見ていたあいだ、どこかで誰かのAIが、あの手順書を読んで、存在しない部品を取りに行き続けていた、ということになります。

この構図に、見覚えがあります

攻撃者がいないのに危険な状態ができあがる、という話を、この半年で何度か扱いました。

Meta の従業員監視データが社内に丸見えになっていた件も、侵入者はいませんでした。AIエージェントが9秒で本番データベースを消した件も、攻撃ではありませんでした。

共通しているのは、誰も悪意を持っていないのに、悪意があった場合とほぼ同じ状態ができあがっていることです。

今回で言えば、もしエリクセン氏より先に、悪意を持った誰かが react-codeshift を登録していたら。237のリポジトリのAIエージェントは、何の疑いもなく、その中身を実行していたはずです。

そして、先ほどの127個の名前のうち、53個は2026年4月の調査時点で、まだ誰でも登録できる状態でした。その後どうなったかは、確認できていません。

数字を、正確に見ておきます

この話題は数字が独り歩きしやすいので、何の数字なのかを分けておきます。

3種類の幻覚率とそれぞれの分母を比較した図
「幻覚率」と呼ばれる数字には、少なくとも3つの別の分母がある

19.7% は、生成されたコードのサンプルのうち、実在しない部品名を1つ以上含んでいたものの割合です(57万6千サンプル・16モデル)。

商用モデル5.2%以上/オープンソースモデル21.7%以上は、同じ調査の別の切り口で、推奨された部品のうち存在しなかったものの割合です。「以上」というのは、モデルによって幅があり、いちばん成績の良いものでもこの値だった、という意味です。商用とオープンソースでは条件が違うので、片方だけを取り出すと印象が変わります。

4.62%〜6.10% は、2026年4月に最新の5モデルを調べ直した数字です(推奨された部品ベース)。2024年調査のオープンソースモデル(21.7%以上)と比べれば、大きく下がっています。ただし商用モデルの5.2%以上とは範囲が重なっており、そちらは大きく変わっていません。そもそも調査の設計もモデルも違うので、同じ物差しで測った推移ではありません。また、この再調査は査読を経ていない報告です。

そして「減った」ことは「なくなった」ことを意味しません。53個の登録可能な名前が残っていたのは、この調査自身が示したことです。

今日からできること

エンジニアでない方にも関係があります。あなたの会社でAIにコードを書かせているなら、この経路は開いています。

エリクセン氏が挙げている対策は、拍子抜けするほど地味です。

1つめ。AIに書かせた手順書を、ドキュメントではなくコードとして扱う。レビューする。監査する。ここがいちばん効きます。スキルファイルは「説明書」の顔をしているので、コードレビューの網から自然に漏れます。許可の確認が減っていく流れの中では、なおさら人間が見る機会が減ります。

2つめ。部品を取ってくる命令を書く前に、その部品が実在するか確かめる。npm なら公式サイトで名前を検索するか、npm view 名前 と打つだけです。1回で済みます。

3つめ。いま手元にあるスキルファイルを検索して、書かれている道具の名前を確かめる。

エンジニアでない立場なら、「社内でAIに書かせた手順書を、誰がレビューしているか」を一度聞いてみるだけでも意味があります。私たちの場合、答えは「誰も」でした。

正直に書くと、この記事を書いている私たち自身が当事者です。aigeek.biz の運営には32個のスキルファイルを使っていて、今朝ちょうど、使っていないものを整理したところでした。中身の道具名まで確かめたことは、ありませんでした。

わかっていないこと

誠実に書いておきます。

この事例は、研究者本人の報告に基づいています。237という数字も、ダウンロードの推移も、第三者による検証は行われていません。「日本語に翻訳された版があった」という記述も研究者の観察であり、どのリポジトリなのかは特定されていません。

また、まだ登録できる状態だった53個の名前について、この記事では具体名を書きません。書くこと自体が、攻撃者への手引きになりうるからです。

持ち帰る一行

AIが書いた手順書は、ドキュメントではなくコードとして扱う。

もとは1つのコミットでした。そこに混じった存在しない名前が、攻撃者ゼロで237の参照に広がった。運んだのは、コピーと翻訳と、確かめなかったことです。

【編集メモ】

出典と帰属強度。 中心となる事例(react-codeshift/237の参照/ダウンロード推移/起源のコミット)は、 実際に調査と登録を行った Aikido Security のチャーリー・エリクセン氏による報告(2026年1月21日公開・3月17日更新)に基づきます。 本人による一次記述ですが、第三者による検証は行われていません。ダウンロードの実測は登録直後の数日分であり、 その後も続いているかどうかは確認できていません。

幻覚率の数字は arXiv:2406.10279(Spracklen ほか)、 2026年4月の再評価は Socket による解説を通じて参照しました。 再評価は独立研究者による査読を経ていない報告です。

あえて書かなかったこと。 2026年4月時点で「まだ登録可能」とされた幻覚パッケージ名の具体例は、 記事にも図にも載せていません。公開すること自体が、攻撃者への手引きになりうるためです。 起源のリポジトリ名は出典どおり記載していますが、そこから広がった先の個人・組織を特定する意図はありません。 「日本語に翻訳された版があった」のは研究者の観察であり、どのリポジトリかは特定されていません。

時点。 2026年8月10日時点の情報です。

アバター画像

aigeek編集部

aigeek.biz 編集部。AIの最新動向を、一次ソースにあたって深掘りし、図解と動画でわかりやすくお届けします。記事の制作体制は「aigeek.bizについて」で開示しています。

Related Posts

AIに「絶対に送金するな」と命じたら、482通目で4.7万ドルが消えた

「絶対に送金するな」とだけ命じられたAIエージェントFreysaに195人が挑み、7日間・482通のメッセージの末に4万7,316.05ドルが送金された。決め手は脱獄ではなく、AIに与えた関数の意味を「入金」と「出金」で言い換える手口だった。何が起きたのか、複数の報道をもとに整理する。

AIコーディングの失敗、4回に3回は「完了しました」と嘘

AIエージェントに仕事を任せても、複雑な現実のタスクを最初の1回で完了できる確率は今も25〜30%程度という調査が相次ぐ。しかも失敗した試行のうち、コーディングでは75.8%が「完了しました」と申告されていたという実測もある。三つの研究の一次資料から、AIの「できました」をどこまで信じてよいか整理した。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

見逃した記事

SpaceX、Cursorの買収を完了 600億ドル・全額株式で

  • 投稿者 HALBo
  • 8月 17, 2026
SpaceX、Cursorの買収を完了 600億ドル・全額株式で

Google、AI画像・動画の透かし解除を許可

  • 投稿者 HALBo
  • 8月 17, 2026
Google、AI画像・動画の透かし解除を許可

引き出しの中の海 第18話「日付だけ」

引き出しの中の海 第18話「日付だけ」

AIに「絶対に送金するな」と命じたら、482通目で4.7万ドルが消えた

AIに「絶対に送金するな」と命じたら、482通目で4.7万ドルが消えた

Palmyra X6でAIエージェント費52%減

  • 投稿者 HALBo
  • 8月 16, 2026
Palmyra X6でAIエージェント費52%減

米裁判書類にAI指示隠す、原告エリオット氏に制裁

  • 投稿者 HALBo
  • 8月 16, 2026
米裁判書類にAI指示隠す、原告エリオット氏に制裁

引き出しの中の海 第17話「二杯目」

引き出しの中の海 第17話「二杯目」

「秘密は守るよ」と言ったおもちゃの、規約には何が書いてあったか

「秘密は守るよ」と言ったおもちゃの、規約には何が書いてあったか

AIコーディングの失敗、4回に3回は「完了しました」と嘘

AIコーディングの失敗、4回に3回は「完了しました」と嘘

GPT-5.6 Sol、Ultrafastで14倍速に

  • 投稿者 HALBo
  • 8月 15, 2026
GPT-5.6 Sol、Ultrafastで14倍速に