はじめに

AIコーディングアシスタントの普及により、開発効率は飛躍的に向上しました。しかし、その便利さの裏側で新たな脅威が台頭しています。「Slopsquatting（スロップスクワッティング）」と呼ばれる攻撃手法は、AIモデルの「幻覚（Hallucination）」を悪用し、開発者の意図しないマルウェアインストールを引き起こすサプライチェーン攻撃です。

この攻撃は、人間がタイプミスをするのを待つ従来の「Typosquatting（タイポスクワッティング）」とは異なり、AIが自信を持って架空のパッケージ名やコードを提案する瞬間を狙います。本記事では、Slopsquattingの仕組みと、中小企業・スタートアップの開発現場で今すぐ取るべき対策について解説します。

Slopsquattingとは何か：AIの「嘘」を武器にする攻撃

Slopsquattingは、AIが実在しないパッケージ名や関数名を生成し、開発者がそれを信用してインストールまたはコードに組み込むことで成立します。例えば、OAuth2トークンを付与するライブラリとして「requests-oauth2-helper」という名前のパッケージが必要だとAIが提案したとします。

この名前は既存の有名ライブラリ（例: requests）のパターンに似ており、技術的に正当性のように見えます。開発者はAIの出力を信頼し、その名前でインストールコマンドを実行してしまいます。しかし、そのパッケージは攻撃者が事前に登録した悪意のあるものであり、インストール時に機密情報の窃取やバックドアの仕込みが行われる可能性があります。

この攻撃の特徴は、開発者のミスを必要としない点です。AIが生成した出力をそのまま信頼して実行する行為自体が、攻撃のトリガーとなります。つまり、防御の鍵は「人間の慎重さ」ではなく、「AIの出力に対する検証プロセス」にあります。

従来のTyposquattingとの決定的な違い

従来型のタイポスクワッティング（例: express の代わりに expres を登録）は、開発者の手元のタイプミスに依存していました。しかし、AIアシスタントがコードを補完する際、人間はそのパッケージ名を「自分で入力」せず、「コピー＆ペースト」または「自動挿入」で取り込むことが一般的です。

Slopsquattingはこのギャップを狙います。開発者はパッケージ名のスペルを確認することなく、AIが提供した文脈に従ってインストールを行います。攻撃者は大規模にAIの出力を監視し、頻出する架空の名前を即座に登録します。この速度と自動化された性質により、従来の「ユーザーの注意」への依存はもはや通用しません。

実務で陥りやすいリスクケース

開発現場では、以下のような状況でSlopsquattingの影響を受けやすくなります。

  • CI/CDパイプライン内での自動インストール: スクリプト内でAIが生成した依存関係リストをそのままpipやnpmに渡す場合、人間の手を通さずにパッケージが導入されます。
  • 新しいフレームワークやライブラリの採用時: 知名度の低い、あるいは非常に新しい技術スタックでは、実在するパッケージが少ないため、AIの幻覚と現実の見分けがつきにくくなります。
  • 社内Wikiやナレッジベースでのコード共有: AIが生成したコード例をドキュメント化し、他のメンバーがそれを参照して実行する場合、誤ったパッケージ名が広まるリスクがあります。

特にスタートアップ企業では、開発リソースの逼迫から「とりあえず動けばいい」という判断になりがちですが、ここでの油断は重大なインシデントにつながります。

対策1：依存関係の検証プロセスの強化

最も基本的かつ効果的な対策は、AIが提案したパッケージ名を必ず検証することです。具体的には以下の手順を実装・運用します。

  1. 公式ドキュメントでの確認: AIが「requests-oauth2-helper」のような名前を提案した場合、その公式リポジトリ（PyPI, npm, Maven Centralなど）で検索し、メタデータや作者を確認します。特に、パッケージの作成日とスター数（あれば）が不自然に低い場合は要注意です。
  2. 類似パッケージとの比較: 実在する有名ライブラリと名前が似ている場合、それは意図的な紛らわしさである可能性が高いです。必ず公式ドキュメントに記載されている正確なパッケージ名と比較します。

対策2：技術的防御の導入

人的ミスを補うために、技術的なガードレールを設けます。

  • 依存関係スキャンツールの活用: Snyk, Dependabot, Trivyなどのツールを導入し、インストールされる前に既知の脆弱性や不審なパッケージを検出します。ただし、Slopsquattingは「新しい」攻撃であるため、既存のシグネチャベースの検出では漏れる可能性があります。そのため、パッケージの信頼性スコアやレビュー数を参照する機能があるツールを選ぶことが重要です。
  • サンドボックス環境での実行: 初回インストール時や、未知の依存関係を追加する際は、隔離された環境（Dockerコンテナなど）で動作を確認します。本番環境や開発マシンのファイルシステムに直接書き込まれないようにします。

対策3：AI利用ガイドラインの策定と教育

技術的な対策だけでなく、組織としての意識改革が必要です。

  • 「盲信禁止」の原則: チーム内で「AIが提案したパッケージ名は必ず確認する」というルールを明文化します。コードレビューにおいて、依存関係の変更は特に厳格にチェックする項目とします。
  • プロンプトエンジニアリングの改善: AIに対して「実在するパッケージのみを参照し、架空の名前を生成しないこと」や、具体的なドキュメントへのリンクを促すプロンプトを使用します。また、AIの出力結果に「This package may not exist. Verify before installing.」のような警告文を付与させるなどの工夫も有効です。

まとめ：AI時代のサプライチェーンセキュリティ

Slopsquattingは、AIがもたらす恩恵とリスクの両面を象徴する攻撃手法です。開発効率を犠牲にせず、かつセキュリティを確保するためには、単なるツールの導入だけでなく、開発プロセスの見直しが求められます。

中小企業・スタートアップにおいても、リソースが限られていても、依存関係の検証という基本的な習慣を身につけることで、大きな被害を防ぐことができます。AIは強力なアシスタントですが、最終的な判断と責任は常に人間にあります。その自覚を持って、安全な開発環境を構築していきましょう。

参考

本記事は海外の技術トレンド「Slopsquatting: The Supply Chain Attack That Weaponizes AI Hallucinations」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。

記事一覧に戻る