AI生成音楽が教えてくれるコンテンツ汚染の構造

The Vergeの記事を読んで、正直ちょっと背筋が冷えた。

Deezerのデータによると、2025年9月時点でアップロードされる音楽の28%がAI生成だった。それが年末には1日5万曲超、全アップロードの34%まで膨らんだという。SunoとUdioがテキストプロンプトだけで楽曲を生成できるようにしてから、こんなペースで増えている。

「音楽の話でしょ」で終わらせられないのは、これがコンテンツ配信基盤に何が起きるかの予告編に見えるからだ。

同じことがコードにも起きていると思う

Sunoがやったことを整理すると、生成コストをゼロに近づけて、プラットフォームのアップロード検証をすり抜けたということだ。音楽プラットフォームには「楽曲の質を機械で測る」仕組みがなかった。だから量で押し切られた。

これ、npm・PyPI・GitHubに置き換えると怖くないか。実際にはまだ大規模な「AI生成ライブラリ汚染」は表面化していないけど、構造的にはほぼ同じ穴がある。パッケージ名のタイポスクワットは昔からある話だし、そこにAI生成の「一見まともなコード」が混ざり始めたら検知がずっと難しくなる。

自分がライブラリ選定するとき、いまどこを見ているか振り返ってみた。

• GitHubのスター数とissueの活発さ
• コミットの頻度と差分の中身
• READMEとコードの文体が一致しているか
• 依存関係のサプライチェーン（`npm audit`や`pip-audit`）

最後の2つ、正直ちゃんとやれてないことが多い。

プラットフォーム側が「禁止も推奨もしない」を選んだ理由

Deezerをはじめ各ストリーミングサービスは、AI生成コンテンツを明示的に禁止していない。記事のタイトルが「They won't ban it. They won't embrace it either.」なのが象徴的だ。禁止すれば検証コストが跳ね上がる。黙認すればユーザーと正規アーティストが離れる。どちらも選べない。

この「どっちも選ばない」姿勢はパッケージレジストリも同じで、npm・PyPIともAI生成コードを明示的に排除するルールはない。悪意あるコードの混入チェックはあっても、「機能するが出所不明なAIコード」には対応できていない。

プラットフォームに頼れないなら、自分のチェックを厚くするしかない。自分がいまやろうとしているのは、新しいライブラリを採用するときにコミット履歴を1ページだけ必ず目で確認する習慣をつけることだ。面倒に見えて、実際は5分かからない。それで「急に大量コミットが入った不自然なタイミング」くらいは拾える。

音楽の話がここまで自分ごとになるとは思っていなかったけど、汚染が起きる構造はどのプラットフォームも同じだというのが今回の学びだと思う。生成コストが下がれば、悪意がなくてもノイズが増える。それに対抗するのは、結局自分の目とプロセスしかない。

あなたのチームでは、外部ライブラリの採用フローに何か変化はありそうか？