AIが勧めたライブラリはマルウェアだった ─ 「言い間違い」を待ち伏せするスロップスクワッティング

プログラムを書くとき、AIに「この作業に使えるライブラリを教えて」と尋ねる。返ってきた名前をインストールする。いまや世界中の開発現場で毎日行われている、ごくありふれたやり取りです。ところが2026年8月、そのやり取りの中でAIが推薦してきたものが、マルウェアだった——そんな事例が報告されました。

報告したのは、ソフトウェア開発会社Softjournの経営責任者Sergiy Fitsak氏。英テックメディアThe Registerが8月20日、同氏の証言をもとに経緯を伝えています。同社のエンジニアがありふれた作業のためにAIエージェントへパッケージ（プログラムの部品）の推薦を求めたところ、AIはもっともらしい名前を返してきました。有名なライブラリと似た、いかにもありそうな命名です。多くの職場なら、そのままインストールして終わりだったでしょう。

しかしこの会社には決まりがありました。AIが勧めたソフトウェアは、入れる前に必ず中身を確認する。エンジニアがGitHubでそのパッケージのソースコードを開いたところ、2つの違和感に気づきます。ダウンロード数が異常に少ない。そして、作られたのがほんの数日前。手が止まりました。それはマルウェアだったのです。

パッケージ選定にAIを使う開発の現在地

背景を少し補います。現代のソフトウェア開発は、すべてを自分で書くのではなく、公開されている部品（パッケージ、ライブラリ）を組み合わせて作るのが基本です。「日付を扱う部品」「画像を処理する部品」といった既製品が何百万種類も公開されていて、名前を指定すれば自動でダウンロードして組み込める仕組みが整っています。

問題は、部品が多すぎることです。似た機能のパッケージが何十個もあり、どれが定番でどれが古いのか、調べるだけでひと仕事になります。そこで「この用途ならどれがいい？」とAIに聞く。AIは膨大なコードを学習しているので、たいていは妥当な答えを返してくれます。この便利さが定着した結果、AIの推薦をそのままインストールする流れが、開発現場の日常になりました。

一方で、AIには以前から知られた弱点があります。ハルシネーション——実在しない情報を、もっともらしく作り出してしまう現象です。パッケージの推薦でも同じことが起き、AIは時どき、この世に存在しないパッケージの名前を自信たっぷりに答えます。存在しない名前ならインストールしようとしてもエラーになるだけで、実害はない。少なくとも、これまではそう考えられていました。

AIの言い間違いを待ち構える攻撃

今回の一件が示しているのは、その「実害はない」が崩れた、ということです。

Fitsak氏はThe Registerの取材にこう説明しています。AIモデルは、もっともらしいけれど実在しないパッケージ名を作り出すことがある。セキュリティ研究者はこのパターンを「スロップスクワッティング（slopsquatting）」と呼び始めている。攻撃者はこれに目をつけ、AIが作り出しそうな名前で本物のパッケージを先回りして登録しておく。締め切りに追われた開発者が「まずインストール、確認は後で」と動くことに賭けているのだ、と。

似た手口に「タイポスクワッティング」という古典的な攻撃があります。こちらは人間の打ち間違いを狙うもので、有名パッケージのスペルを1文字変えた偽物を登録しておき、うっかり打ち間違えた人に踏ませる手法です。スロップスクワッティングはその発想をAI時代に持ち込んだもので、狙うのは人間のタイプミスではなく、AIの言い間違い。「slop（スロップ）」はAIが量産する粗悪な出力を指す俗語で、この造語はPythonの公式組織Python Software FoundationのSeth Larson氏によるものとされています。

ここで疑問が湧きます。AIの言い間違いなんて予測できるのか？　でたらめな名前を待ち伏せしても、当たるとは思えません。ところが、当たるのです。AIが作り出す架空の名前には、はっきりした偏りがあります。

テキサス大学サンアントニオ校などの研究チームが2025年に発表した論文（セキュリティ分野の主要会議USENIX Securityに採択された査読済みの研究）は、この偏りを大規模に調べています。16種類のAIモデルに57万6千件のコード生成をさせて集計したところ、生成されたパッケージ名のうち実在しないものの割合は、商用モデルで平均5.2%、オープンソースモデルでは平均21.7%にのぼりました。架空の名前は延べ20万種類以上。しかも同じ質問を繰り返すと、同じ架空の名前が何度も出てくる傾向が確認されました。つまり攻撃者は、AIに質問を投げて「よく出てくる架空の名前」を観察し、その名前で悪意あるパッケージを登録しておけばいい。AIのくせが、そのまま攻撃の設計図になるわけです。

この傾向は最新のAIでも消えていません。2026年に公開された追試（こちらは査読前の論文です）では、2025年末から2026年にかけて登場した主要5モデルを同じ方法で調べ直したところ、架空の名前の出現率は4.6〜6.1%。以前のオープンソースモデルよりはずっと低いものの、ゼロには程遠い数字です。さらに興味深いことに、5つのモデルすべてが共通して同じ127個の架空名を出したと報告されています。開発元の違うAIが、そろって同じ言い間違いをする——待ち伏せする側にとって、これほど都合のいい話はありません。

会社を救った数分の確認

Softjournのケースで実際に何が仕込まれていたのか、詳しい内容は公表されていません。The Registerの記事も、使われたAIエージェントの名前や問題のパッケージ名には触れていません。ただ、インストールしていれば、外部からの侵入口を作られたり、データを盗まれたりする恐れがあったと記事は指摘しています。開発に使う部品への混入は「サプライチェーン攻撃」と呼ばれ、汚染された部品を組み込んだソフトを通じて、その先の利用者にまで被害が広がりかねない攻撃です。

それを防いだのは、高度なセキュリティ製品ではありませんでした。ダウンロード数を見る。公開日を見る。ソースコードを眺める。誰にでもできる確認を、AIの推薦であっても省かない——その習慣だけです。Fitsak氏は「余計にかかるのは数分。その一手間を一度省いただけで、チームは機能を予定通り出す代わりに、サプライチェーン侵害の顛末（てんまつ）を説明するはめになる」と語っています。

この話の教訓は「AIは危ないから使うな」ではありません。AIの推薦は今後も開発の役に立ち続けるでしょうし、前述の研究でも、対策次第で架空名の生成をかなり減らせることが示されています。変わったのは、AIの間違いを人間の間違いと同じように「攻撃の入口」として狙う人たちが現れた、という前提のほうです。だとすれば守り方も同じで、出どころのわからないものを確かめてから使う、という昔ながらの用心をAIの答えにも適用する。それだけのことが、今回ひとつの会社を救いました。なお、この攻撃が実際にどれくらいの規模で行われているのかは、まだ全体像がつかめていません。今回の事例も一社の証言にもとづく報告であり、氷山の一角なのか、まれな遭遇なのかは、今後の調査を待つ必要があります。