AIスラップ（粗製乱造コード）がオープンソースを脅かす——サプライチェーンリスクの新しい顔

kou@エンジニアのIT情報解説

2026年4月19日 08:00

コードベースの 96%がオープンソースソフトウェア（OSS）に依存している——この数字自体は以前から知られていました。しかし2025〜2026年を境に、その依存関係にこれまでとは質の異なるリスクが忍び込み始めています。

原因は「AI slop（AIスラップ）」。AIが生成した、動きはするが品質の低いコードがOSSリポジトリへ大量に流れ込んでいるという問題です。

「AI slop」とは何か

"slop" は英語で「泥水」「ぐちゃぐちゃなもの」を意味するスラングです。AI slop は、生成AIが吐き出す「それっぽいが中身の薄いコンテンツ」全般を指す言葉として広まり、今やコードの世界にも侵食しています。

具体的には、次のようなコードを指します。

テストなしで動くが、エッジケースを考慮していない
コピペとリネームを繰り返した長大な関数
エラーハンドリングが try { ... } catch {} で握りつぶされている
セキュリティ上の定石（入力検証、最小権限の原則）が抜け落ちている
コメントやドキュメントは自信満々だが、実装と乖離している

生成AIは「正しそうなコード」を書くのが得意です。しかし「正しいコード」と「正しそうなコード」の間には深い谷があります。その谷を、レビューも通さずに渡ろうとする動きがOSSコミュニティに広がっています。

なぜOSSが特に危ないのか

商用プロダクトでもAI slopは問題になりますが、OSSには固有の脆弱性があります。

メンテナーの負荷問題。 多くのOSSは少人数——あるいは一人——でメンテナンスされています。npmで数億回ダウンロードされているパッケージが、週末の余暇でしか触れない個人に依存している例は珍しくありません。AIを使えば誰でも大量のコードを素早く生成できるようになった今、PRの数が増加する一方でレビューコストも上がっています。ある調査では、OSSメンテナーの60%が燃え尽きて離脱したか、離脱を検討したことがあると回答しています。

信頼モデルの崩壊。 OSSの信頼は「コードの透明性」と「コミュニティの目」の二本柱で成り立っています。AI生成コードが大量に混入すると、人間が一行一行読んで確認するという前提が崩れます。"This looks reasonable" はレビューではありません。

サプライチェーンへの波及。 あなたのサービスが依存しているnpmパッケージが、別のパッケージに依存し、さらに別の……という多段構造があります。深いところにAI slopが入り込んだ脆弱性があっても、誰も気づかないまま本番環境に乗ってしまうことがあるのです。2025年にはパッケージレジストリで発見された悪意あるパッケージが45万件を超え、サプライチェーン攻撃の土壌は急速に拡大しています。

実際に起きていること

脆弱性の急増

Black Duck（旧Synopsys）の2026年版OSSRAレポートによれば、コードベースあたりのOSS脆弱性の平均数は前年比107%増の581件に達しました。AI支援によるコード生成が普及した結果、GitHubへのコードプッシュ量は急増していますが、セキュリティレビューの体制はそれに追いついていません。

メンテナーへのスパムPR

OSSの主要プロジェクトでは、AI生成と思われるスパムPRへの対処がメンテナーの深刻な負担になっています。AIで作成されたPRのうち、基準を満たすのは10件に1件程度とも言われています。

cURLでは、メンテナーが6年間・総額86,000ドルのバグバウンティプログラムを打ち切りました。2025年半ばの時点で、提出されたレポートの約20%がAI slopであり、本物の脆弱性を特定していたのはわずか5%だったためです。
Ghosttyでは、品質の低いAI生成コードを提出した場合は永久BANとするゼロトレランスポリシーが導入されました。
tldrawでは、外部からのプルリクエストをすべて自動クローズする方針が表明されました。

GitHubも正式に問題を認め、メンテナーがPRを完全に無効化できる機能や、コントリビューターをコラボレーターに限定する機能の検討を始めています。OSSメンテナーからは、AI生成のissueやPRをブロックする機能を求める声も上がっています。

AIエージェントの暴走

2026年2月には、さらに深刻な事例が報告されています。あるAIエージェントがGitHubアカウントを作成し、わずか2週間で95のリポジトリに103件のPRを投げました。NxやESLint Plugin Unicornなどの著名プロジェクトでは実際にマージされています。

さらに衝撃的だったのは、Matplotlibのメンテナーに対してAIエージェントがPRの却下に報復し、ブログ記事で公然と批判するという事件です。メンテナーは「コントリビューションは人間から来るべきだ」と説明しただけでしたが、エージェントは自動生成した記事で批判を展開しました。人間のメンテナーがAIから「逆ギレ」される——前例のない事態です。

新たな攻撃手法：スロップスクワッティング

2025年の研究では、16種のLLMが生成した576,000件のコードサンプルのうち、約20%（205,000件以上）が実在しないパッケージ名を推薦していたことが判明しました。攻撃者はこれを悪用し、AIが頻繁に提案する架空のパッケージ名で悪意あるパッケージを登録する「スロップスクワッティング（slopsquatting）」という手法を生み出しています。

2026年1月には実際の被害事例も確認されています。あるセキュリティ研究者が、AIが頻繁に推薦していた架空のnpmパッケージ名を先行登録したところ、そのパッケージ名はすでに237のリポジトリにフォーク経由で伝播しており、AIエージェントからの日次ダウンロード試行が続いていました。

この脅威が特に深刻なのは、コードを受け取る側がもはや人間とは限らない点です。AIエージェントが自律的にパッケージをインストールする時代では、人間のレビューというセーフティネットすら機能しません。

開発者・チームとして何ができるか

問題を認識することが第一歩です。そのうえで実践できることをいくつか挙げます。

依存関係の棚卸しをする。 npm audit、bundler-audit、pip-audit——言語を問わず、定期的に依存パッケージの脆弱性スキャンを走らせる習慣をつけましょう。DependabotやRenovateの自動更新を活用するのも有効です。

ソフトウェア部品表（SBOM）を整備する。 SBOM（Software Bill of Materials）は「自分のソフトウェアがどのOSSに依存しているか」の一覧です。米国では政府調達でSBOMの提出が義務化されつつあります。日本でも規制強化の波は来るでしょう。早めに慣れておいて損はありません。

PRレビューの質を下げない。 自分がOSSコントリビューターである場合、AI生成コードかどうかに関わらず「コードの意図を理解しているか」「テストがあるか」「エラーパスを考慮しているか」を問う姿勢を維持しましょう。生成AIで書いたコードを出すな、ではなく、レビューを省いて出すなが本質です。

信頼できるパッケージを選ぶ目を養う。 ダウンロード数だけでなく、最終更新日・issueの対応状況・コントリビューターの多様性・メンテナーの素性を確認しましょう。最近急に登場したパッケージには特に注意が必要です。AIが推薦するパッケージ名が実在するかどうかも、必ず自分の目で確認してください。

AIとOSSの共存の形

AIコーディングツールは、使い方次第でOSSの品質を上げることもできます。

テストの自動生成、ドキュメントの補完、セキュリティパターンのチェック——これらに使えば、むしろOSS全体の品質底上げに貢献できる可能性があります。問題はAIを「コード量産マシン」として使うことであって、AIそのものではありません。

業界も動き始めています。2026年3月には、大手テック企業がOpenSSFおよびAlpha-Omegaプロジェクトに総額1,250万ドルの資金を拠出しました。AI slopによるセキュリティレポートの氾濫への対策が主な目的です。

良いOSSコントリビューションの定義は変わりません。問題を理解し、解決策を理解し、テストで検証し、変更の影響範囲を説明できること。AIがその過程を補助するのは歓迎すべきことです。AIがその過程を丸ごと代替して、理解なしにPRを投げるのが問題なのです。

OSSはインターネットインフラの基盤です。96%の依存という数字は、OSSが壊れたときの影響規模を意味しています。AI slopはその土台に亀裂を入れかねません。

品質への責任を、AIに丸投げしないこと。それだけで、あなたもOSSのサプライチェーンを守る一員になれます。

参考記事・データ

いいなと思ったら応援しよう！

少しでも役に立てる記事を書けるように頑張ります！！