スロップスクワッティングは、最新のAIコーディングツールにとって増大する脅威となっている。

　最新のアプリケーション開発はコードパッケージに依存している。パッケージは、アプリケーション構築に必要なフレームワークや機能を提供する。AIコーディングツールは、公開されていないパッケージ名を提案し、ハルシネーション（幻覚）を起こすことがある。モデルはコードレジストリを確認するのではなく、学習データのパターンに基づいてもっともらしい名前を予測して出力する。

　開発者やAIコーディングエージェントは、パッケージが正当なものか確認せずにインストールしてしまう可能性がある。

攻撃の手順

　攻撃者はAIのこうした挙動を悪用し、パッケージハルシネーション攻撃を実行できる。

　Keeper SecurityのCISO（最高情報セキュリティ責任者）を務めるシェーン・バーニー氏は次のように説明する。「攻撃者は大規模言語モデル（LLM）の出力パターンを分析し、繰り返し出現する架空のパッケージ名を特定している。そして悪意あるペイロードを仕込んだ上で、パッケージマネジャーやオンラインレジストリにその名前を事前に登録しておく。開発者がインストールコマンドを実行した時点ですでにわなは仕掛けられている」

　AIによるパッケージ名のハルシネーションが繰り返される性質は数値でも証明されている。テキサス大学サンアントニオ校、オクラホマ大学、バージニア工科大学の研究者が2025年の「USENIX Security」で発表した論文によると、16種類のコード生成モデルをテストした結果、推奨されたパッケージの19.7％が存在しなかった。さらに深刻なことに、同一のプロンプトを10回繰り返したところ、捏造されたパッケージ名の43％が全ての試行で繰り返し出現した。

タイポスクワッティングとスロップスクワッティングの違い

　タイポスクワッティングは、人間が実在する名前を入力ミスしたり、誤字にだまされたりすることを利用する。一方、スロップスクワッティングはAIモデルが実在しない名前を捏造することを利用する。USENIXの研究者によると、捏造された名前のうち実在するパッケージと1～2文字の違いにとどまっていたものはわずか13.4％だった。

なぜ今、これが情シスにとって重要なのか

　スロップスクワッティングは、情シスが直面している極めて緊急性の高いセキュリティリスクの1つだ。理由は複数ある。

AI導入の急速な進展

　ほぼ全ての企業がコーディングにAIを利用しており広大な攻撃対象領域が生じている。Gartnerは、企業のエンジニアの90％が2028年までにAIコードアシスタントを使用すると予測している。この普及規模により、AIツールのリスク対策はほぼ全企業のロードマップに組み込まれることになる。

サプライチェーンによるリスクの増幅

　パッケージは単一のアプリケーション内のコードにとどまらず、複数のアプリケーションで広く使われるため、ソフトウェアサプライチェーンの脅威を増幅させる。つまり、1つの改ざんされたパッケージが、それを依存関係として利用する数百から数千のアプリケーションに波及する恐れがある。バーニー氏は「開発者がAIアシスタントの提案を信じて検証せずにインストールすることは、実在しない名前を捏造するシステムにソフトウェアサプライチェーンの重要な特権を丸投げしているのと同じだ」と語る。

風評被害と金銭的リスク

　本番環境に悪意ある依存関係が混入すると、攻撃やデータ侵害につながる恐れがある。結果、コンプライアンス違反や顧客への通知義務が生じる可能性がある。

規制の強化

　欧州連合（EU）の「サイバーレジリエンス法」は、2026年9月11日までのインシデント報告を義務付けている。米行政管理予算局（OMB）が2026年1月に発行した覚書「M-26-05」は、連邦政府のSBOM（ソフトウェア部品表）証明をリスクベースのアプローチへと移行させた。

検知の難しさ

　従来のセキュリティスキャナは、AIのハルシネーションによるセキュリティリスクを見逃してしまう。悪意あるパッケージは、既知のパッケージの改ざんではなく新規登録されたものである場合が多いためだ。Bugcrowdの最高戦略および信頼責任者であるトレイ・フォード氏は「このリスクは大半の企業で取締役会の報告資料や監査チェックリスト、サイバー保険のアンケートにも載っていない。既存の分類に当てはまらず、フィッシングテストでもパッチ適用の周期でもないからだ」と指摘する。

　この脅威は現実に起きている。2026年1月、Aikido Securityのセキュリティ研究者チャーリー・エリクセン氏は、「react-code shift」という架空のnpmパッケージが、AIが生成したエージェントスキルを通じて237個のリポジトリに拡散していたことを発見した。エリクセン氏自身がその名前を登録して保護するまで、自律型エージェントは毎日同パッケージをインストールしようとしていた。

組織への影響とリスク評価

　スロップスクワッティングのインシデントは、企業内の複数の層に影響を及ぼす。

開発ワークフローの脆弱性

　多くの開発チームはコード作成の一環としてAIツールを利用しているが、依存関係のセキュリティ管理プロセスを明確に定めているチームは少ない。

　Black Duckのプリンシパルストラテジックサービスコンサルタントを務めるリー・ジャオ氏は「最大の弱点は、依存関係のガバナンスと検証にある」と話す。「大半の企業は既知のコンポーネントや脆弱性をスキャンできる。しかしAIが提案した依存関係が、ソースリポジトリやビルドシステム、CI/CDパイプラインに入る前に、正当性や出どころ、信頼性を検証するガバナンスが欠けている」（ジャオ氏）

技術スタックについての考察

　開発者のワークフローはインフラによって支えられており、AI生成コードの脆弱性を阻止すべきもう1つの重要領域となる。

　AIコーディングアシスタントは「npm」や「PyPI」といったパッケージレジストリを多用するため、パッケージリポジトリのセキュリティが新たな攻撃対象領域となっている。

　SBOMはアプリケーション内の全コンポーネントの正確なインベントリを提供するものだが、規制対象の業界以外での運用にはばらつきがある。

　アプリケーションの構成要素を特定するSCA（ソフトウェア構成分析）ツールも、ハルシネーションによるパッケージ名については盲点を抱えがちだ。

セキュリティアーキテクチャのギャップ

　大半の企業は、依存関係の検証をシステムに組み込まれた統制ポイントではなく、個々の開発者の判断に委ねている。フォード氏は「スケーラブルな解決策は、開発者のその場のあやふやな判断ではなく、レジストリやパイプラインの層に設けるべきだ」と指摘する。

ガバナンスとポリシーの必要性

　AIコーディングは比較的新しい取り組みのため、ポリシーやガバナンスが不足している。バーニー氏は「安全な開発ライフサイクルの文書で、AI支援開発について明確に言及している企業は極めて少ない」と語る。

部門横断的な影響

　スロップスクワッティングは技術チームにとどまらず、組織全体の運用リスクをもたらす。

　悪意あるパッケージが本番環境で使用された場合、法的なリスクやコンプライアンス上のリスクに直面する可能性がある。大半の企業はスロップスクワッティングを正式なリスク事象としてまだ扱っていない。

　Info-Tech Research Groupのテクニカルカウンセラーであるエリック・アバキアン氏は次のように語る。「私が把握している他社事例では、必ずしも監査での指摘や保険金請求につながったわけではなかった。多くの場合、ソフトウェアサプライチェーンのセキュリティについての議論が深まるきっかけとなった。これは良いことだ。AIが生成した依存関係がなぜコードベースに混入したのか、なぜ検証されなかったのか、承認責任者は誰だったのかといった本質的で重要な問いを企業に投げかける契機になった」

情シスが取るべき戦略的行動

　スロップスクワッティングのリスクが高まる中、情シスは能動的に対処する必要がある。リスクを低減するために短期および長期で取れる対策がある。

即座に実施すべき戦術的措置

　コードの安全性を確保するため、まずは以下のような基本的な統制から着手する。

・利用中のAIコーディングツールを監査し、承認済みか非承認かを把握する

・AIが提案したパッケージはインストール前に対象レジストリと照合して検証する

・依存関係の固定とロックファイルの適用を有効にし、検証済みの正確なバージョンにインストールを制限する

・新規パッケージやスロップスクワッティングの兆候となる異常値を正確に識別できるSCAツールやSBOMツールに投資する

・パッケージリポジトリの動向をカバーする脅威インテリジェンスのフィードを統合する

　ジャオ氏は「企業はAIが提案した依存関係を、他の信頼できないサードパーティー製コンポーネントと同様に扱うべきだ」とアドバイスする。「CI/CDパイプラインにSCAと依存関係の監視を組み込み早期かつ継続的にスキャンを実行する必要がある。ただし、従来のSCAでは新たに公開されたスロップスクワッティングパッケージを検出できない場合がある点も認識しておくべきだ」（ジャオ氏）

ポリシーとガバナンスの枠組み

　AI支援によるコード開発に特化したポリシーを策定することが重要だ。これは今日、DevSecOpsのベストプラクティスの不備の1つとなっている。

　バーニー氏は「真の脅威は、開発ライフサイクルのほぼ全ての部分で利用規定を定めているにもかかわらず、この部分だけが抜け落ちていることだ」と指摘する。

メトリクスと監視

　統制とポリシーの整備はリスク軽減の基盤となる。

・未検証パッケージのインストール傾向を監視する

・悪意あるパッケージの検知時間を測定し、本番環境に到達する前に対処する

・開発者のセキュリティトレーニング完了率を追跡し、サプライチェーン攻撃対策を測定可能なプログラムと連動させる

確認すべき重要事項

　自社がスロップスクワッティングのインシデントに対応し、リスクを低減できる態勢にあるかを評価するには以下の点を確認するとよい。

・SBOMの対象範囲にAI生成コードが含まれているか

・AIツールの調達時にベンダーのセキュリティ対策を評価したか

・利用している全てのリポジトリでレジストリレベルのセキュリティ統制が評価されているか

・未検証のパッケージがインストールされた際に検知できるか

・侵害が確認された場合、インシデント対応計画が整備されているか

　最も答えを出すのが難しいのは、責任の所在とオーナーシップについての問いだ。

　フォード氏は「ほぼ全ての企業で抜け落ちているのがオーナーシップの所在だ。人間ではなく機械が行った提案に、誰が責任を負うのかが明確に定められていない」と話す。

　結局のところ、スロップスクワッティングを防ぐために組織がまず講じるべき対策は、コードのコミット時に検証を実施することだ。

　アバキアン氏は「明日すぐに統制を1つ導入できるとすれば、AI生成コードをリポジトリへコミットする前の検証を義務付けることだ」と語る。「コードがコンパイルできたからといって、AIモデルが提案したパッケージが正当だと開発者が思い込むことは絶対に避けるべきだ」（アバキアン氏）