音源は端末で再生できている時点で100%は守れない——AI音楽サービスの音源保護を整理する

個別の対応としてはそれで一段落なのだが、騒動のなかで気になる議論があった。「SUNOは音源ファイルのURLが公開状態で誰でも取り放題、セキュリティを放置している」というものだ。

事実関係としては、おおむねその通りだ。少し前まで、SUNOの公開曲のページには https://cdn1.suno.ai/{曲のID}.mp3 という形でMP3ファイルの置き場所がそのまま書かれていた。本稿執筆時点では配信元が変わっているが、ブラウザの「開発者ツール」（Webページの中身や通信を覗くための、ブラウザに標準で付いている機能）で通信を見れば、配信サーバー上の音声ファイルを保護のないURLで丸ごと1本取得しているのが、今も見える。これを利用してSUNOの曲を一括ダウンロードするツールも、探せばすぐに見つかる。

ただ、ここから「だから対策すべきだ」「対策すれば防げるはずだ」へ話を進める前に、共有しておきたい前提がある。音源の保護というのは、そもそも「完全」がありえない世界だということだ。

僕自身、RezonateというAI音楽のプラットフォームを運営していて、この問題には自分の設計判断として向き合ってきた。今回はSUNO、SoundCloud、Spotify、Apple Music、そしてRezonateの実装を並べて、何ができて何ができないのか、なぜ各社の選択がこうも違うのかを、できるだけ日常の言葉で整理してみたい。

大前提: スピーカーから音が出る時点で、100%は守れない

最初に、いちばん身も蓋もない話をしておく。

音楽が「聴ける」ということは、リスナーの端末の中で、音声データがどこかの時点で必ず生の状態になる、ということだ。配信側がどれだけ強固な鍵をかけても、最後にその鍵を開けてスピーカーへ音を送り出すのはリスナーの端末側になる。鍵を開けたあとの音を端末側で写し取ることは、原理的に止められない。

仮にデジタルの経路を完璧に固めたとしても、スピーカーから出た音をマイクで録れば、それで音源は手に入る。この抜け道は業界で「アナログホール」と呼ばれていて、コンテンツ保護の根本的な限界として昔から知られている（Analog hole - Wikipedia）。マイクを持ち出すまでもなく、パソコンが再生中の音をそのままファイルに録音する「ループバック録音」という手もある。フリーソフトでできてしまう操作で、これを完全に防ぐ実用的な手段は、今のところ存在しない。

実は、こうしたコンテンツ保護の仕組み（業界では「DRM」と呼ぶ。Digital Rights Management＝デジタル著作権管理の略）は、設計思想からして「絶対に破れない箱を作る」ことを目指していない。目指しているのは「気軽にコピーされにくくする」こと、つまりコピーの手間とコストを引き上げることだ。100%守る技術は存在しない、というのが業界側の共通認識になっている。

この前提に立つと、音源保護は「やる／やらない」の二択ではなくなる。「どこまで手間とコストをかけて、その代わりに何を諦めるか」というバランスの問題になる。そして、そのバランスの取り方がサービスごとに違う。

守りの強さは、おおまかに4段階

Webで音源を配信するときに使われている技術を、保護の強さで並べると、だいたい4段階に整理できる。

先に断っておくと、この4段階のどれにも、突破して音源を取り出す方法がすでに存在する。レベルが上がるというのは「取り出すのに必要な手間と専門知識が増える」という意味であって、「取り出せなくなる」という意味ではない。

レベル1: 音源ファイルのURLをそのまま公開する

いちばんシンプルな形。Webページが、配信用サーバー（CDNと呼ばれる、世界中にファイルを届けるためのサーバー網）に置かれたMP3ファイルのURLを直接読み込んで再生する。開発者ツールを開けばURLが丸見えなので、それを知っていれば誰でもファイルとしてダウンロードできる。

実装が簡単で、配信コストが安く、シェアしやすく、再生開始も速い。その代わり、保護はほぼゼロ。SUNOがこれにあたる。Bandcampの試聴や、ニュースサイトの埋め込み音声なども同じ形だ。

レベル2: URLに「有効期限」と「署名」を付ける

URL自体に短い有効期限と、「これは正規のリクエストです」と証明する署名（合言葉のようなもの）を埋め込むやり方。「このURLは数分しか使えない」「正規のページ経由でないリクエストには応答しない」といった制限をかけられる。

URLがどこかに貼られて拡散しても、時間が経てばただの文字列になる。再生中のリアルタイム取得までは止められないが、「いつのまにか出回ったURLを後から叩かれる」事態にはかなり強い。実装の手間はレベル1より少し増える程度で、CDN事業者の多くが標準機能として提供している。

レベル3: 音源を細かく刻む。さらに暗号化することもある

音声を数秒ごとの細かい欠片（チャンクと呼ぶ）に分割して配信する方式。プレーヤー側は「欠片の一覧表（プレイリスト）」を取得し、欠片を順番に集めながら再生する。この分割配信の仕組みが「HLS」や「DASH」と呼ばれるものだ。

分割するだけでも、「URLひとつでMP3が丸ごと手に入る」状態ではなくなる。さらに各欠片をAES-128という方式で暗号化し、復号用の鍵を別の場所から取得させる構成も組める（Dolby OptiView: Content Protection for HLS）。

ただし、この暗号化の鍵はプレーヤー自身が取得できる場所に置かれている。つまり仕組みを知っているツールなら、欠片と鍵を両方集めて、復号して、結合できる。実際そういうダウンローダーは存在する。レベル1のように一発では取れない、というのが正確なところだ。

レベル4: 鍵を、ブラウザの外の「覗けない場所」で扱う

音源を暗号化したうえで、復号の鍵をブラウザやOSに組み込まれた保護領域の中だけで受け渡しする方式。鍵がWebページ上のプログラムや開発者ツールに一切露出しないので、ブラウザ側でいくら頑張っても鍵が手に入らない。

これが世間で「DRM」と呼ばれるときの本格的なやつで、Googleの「Widevine」、Appleの「FairPlay」、Microsoftの「PlayReady」の3つが代表格だ。大手のサブスク型音楽・動画サービスは、ほぼこのどれかを使っている。

ここまでやっても完璧ではない。鍵の処理をソフトウェアだけで行う構成（Widevineでいう「L3」）は過去に解析・突破された実例があるし、最後にはアナログホールとループバック録音が残る。それでも「気軽にダウンロードして配り直す」ハードルは、レベル1〜3とは桁違いに高くなる。

各サービスはどこにいるのか

SUNO: レベル1

公開楽曲は、CDN上の音声ファイルを直URLで丸ごと取得する形で配信されている。少し前までは cdn1.suno.ai/{曲のID}.mp3 というMP3直リンクがページの中にそのまま書かれていた。本稿執筆時点では配信元のホストが変わり、プレーヤーに表示されるURLも blob: で始まる形式（一度取得したデータをブラウザの中で受け渡しするときの表示）になっているが、開発者ツールで通信を覗けば、音声ファイル（.m4a）をひとつのURLで丸ごと取りに行っているのが見える。分割もされていなければ、暗号化もされていない。プレーヤー上のURLが一段隠れただけで、保護の実態はレベル1のままだ。

これは図らずも、本稿の主題のちょうどいい実例になっている。表示上のURLが見えなくなることと、音源が守られることは、まったく別の話なのだ。

なぜ保護をかけないのかは、後で別の角度から考える。

SoundCloud: レベル1から、レベル2と3の間あたりへ移行中

SoundCloudは長らくMP3の直リンク（レベル1相当）を提供してきたが、現在、AAC形式ベースのHLS（先ほどの分割配信）への移行を進めている。旧来のMP3・Opus形式の配信は2025年末を期限として廃止が告知された（SoundCloud Developers Blog、GitHub上の告知）。

ひとつ正確に書いておきたいのは、この新方式は「分割配信＋有効期限つきの署名URL」であって、公開されている情報を見るかぎり、欠片自体の暗号化までは行われていないことだ。つまりレベル2と3の中間くらい。リスナーの体験はほぼ変わらないまま、「URL一発で丸ごと取れる」状態からは確実に脱しつつある、という位置づけになる。

Spotify / Apple Music: レベル4

Spotifyは音源を暗号化し、ブラウザでの再生にはブラウザ組み込みのDRMの仕組みを通してWidevineを使っている（ブラウザの設定でDRMを無効にしているとSpotifyのWeb版が再生できないのは、このため）。デスクトップアプリでは、暗号化された音源の復号をアプリ内部で独自に処理している。

Apple Musicは、HLS（分割配信）に自社DRMのFairPlayを組み合わせた「FairPlay Streaming」を使っている（Apple Developer: FairPlay Streaming）。

Rezonate: レベル2を、何枚か重ねて

Rezonateの現在の実装も書いておく。音源ファイルはCloudflare R2というストレージの非公開領域に置いていて、ファイルそのものを指す公開URLは存在しない。配信はすべて自作の配信プログラム（Cloudflare Worker）を経由する。

再生のたびに、まずサーバーが「この曲を、いま再生してよいか」を確認したうえで、ごく短い有効期限つきのトークン（合言葉）を発行する。配信プログラム側はそのトークンの正しさに加えて、トークンと曲が1対1で結び付いているか、リクエストが正規のページ経由かを確認し、すべて通った場合だけ音声を返す。URLがどこかに流れてもすぐに失効するし、そのトークンを別の曲に使い回すこともできない。「URLをコピペされたら永続的に流出する」という構造そのものを断っている、と言えばいいだろうか。

ただ、ここも正直に書いておくと、完璧ではない。ブラウザの正規の振る舞いを丁寧に模倣したアクセスや、再生中の音を録音する行為までは止められない。ここまで書いてきた通り、ブラウザで再生できる以上、原理的に防げない領域は必ず残る。だからRezonateの設計目標は、最初からそこに置いていない。狙いは「カジュアルな流出と、機械的な大量取得のコストを上げる」ことで、そのために独立した確認を何枚か重ねる構成にしている。

この先については、配信を分割方式（HLS）へ上げる選択肢も、さらにその先にDRMという選択肢も、技術的にはありうる。ただしどれも相応のコストと引き換えなので、サービスの規模とリスクを見ながら判断していくつもりだ。

なぜSpotifyにはできて、SUNOはやらないのか

「SpotifyはちゃんとDRMをやっているのに、SUNOは怠慢だ」という指摘は、それぞれの事情を見ると成り立ちにくい。

まずSpotify側。DRMを自社サービスに組み込むのは、導入して終わりという話ではない。DRM提供元との契約、鍵を発行・検証するサーバーの運用、対応プレーヤーの実装、無数のデバイスでの動作検証。継続的にお金とエンジニアの工数が溶けていく類の仕事で、小さな会社が片手間でやれるものではない。

そしてもうひとつ、こちらのほうが本質的だと思うのだが、SpotifyやApple MusicにとってDRMは「やりたくてやっている」ものですらないかもしれない。レーベル（レコード会社）の音源をインターネットで配信させてもらうこと自体が、レーベルにとっては相当な妥協だった。その妥協を引き出す条件として、DRMによる保護は事実上の必須要件だったのだ。レーベル音源を扱う限り、DRMをやらないという選択肢はそもそも存在しない。

ではSUNOはどうか。SUNOの中心的な価値は、AIで作った曲を「公開して、聴いてもらい、シェアしてもらう」ことにある。SNSへ直接シェアできて、埋め込みプレイヤーで他サイトに貼れて、軽くて再生開始が速い。音源ファイルを公開URLでそのまま返すという実装は、この体験を最大化するための選択だ。DRMをかけた瞬間、ここに挙げたものはほぼすべて大きく後退する。

加えて、SUNOが扱っているのはレーベル音源ではなく、ユーザーが生成した楽曲だ。DRMを契約で強制してくる相手がいない。「ユーザーの曲も守ってほしい」という声が大きくなれば動く可能性はあるにせよ、現状の優先順位はシェアのしやすさにある。

これを「甘い」と評することも、「設計上の意図的な判断」と評することもできる。どちらと取るかは、SUNOというサービスを何だと位置づけるか次第で変わる話だと思う。

AI音楽特有の事情: そもそも著作権が認められにくい

ここまでは、Web上の音源配信ぜんぶに当てはまる技術の話だった。AI生成音楽には、もうひとつ固有の事情がある。法的な保護の弱さだ。

米国で著作権登録を担当するCopyright Officeは、純粋にAIが生成した出力物は人間の創作的関与を欠くため著作権保護の対象にならない、という立場を取り続けている。保護されうるのは、人間が創作的に関わった部分（オリジナルの歌詞を書く、自分でボーカルを録る、生成物を大幅に編集・アレンジするなど）に限られる（米国著作権局: Copyright and Artificial Intelligence, Part 2: Copyrightability）。

日本の文化庁の整理も、方向としてはほぼ同じだ。人間がAIを道具として使い、創作意図と創作的寄与をもって関わっていることが、著作物として認められる条件とされている（文化庁: AIと著作権）。

つまり、生成ボタンを押しただけに近い楽曲は、「これは自分の作品だ」と法的に主張する足場が、現状かなり弱い。そしてこれが、音源保護の文脈で効いてくる。

著作権侵害を理由にした削除要請（米国のDMCAという制度が代表例）は、著作権が認められない曲では根拠そのものが揺らぐ。民事で損害賠償を求めるにしても、「そもそもこれは著作物なのか」の立証から始めることになる。プラットフォーム側もこの事情を知っているから、AI楽曲の削除依頼への対応には温度差が出うる。

今回のMusicMintの件で運営が削除に応じてくれたのは、現実問題としてありがたかった。ただ、あれが法的義務として確実に履行される構造があったかというと、そうとは言えない。はっきり主張できるのは、SUNOの利用規約上、有料プランのユーザーは生成楽曲を商用利用できる権利を契約上持っている、という点くらいだ。そして契約上の権利と著作権は別物で、契約の当事者ではない第三者に対する効力には限界がある。

では、作る側はどう立ち回るか

技術と法律の両方を踏まえると、AI音楽を公開している側が現実的に取れる手は、だいたい次のあたりに落ち着く。

公開＝取得されうる、を前提にする。 これが出発点。ストリーミングで公開すると決めた時点で、外から取られる可能性はゼロにならない。SUNOに限らず、SoundCloudでもBandcampでも原則は同じで、「絶対に守れる公開場所」はどこにもない。

月に一度でいいので、自分の曲をエゴサーチする。 アーティスト名や曲名で、主要なAI音楽サービスとGoogleを検索してみる。網羅は無理でも、ゼロよりはるかにいい。気づくことがすべての起点になる。

転載を見つけたら、まず運営に削除依頼。 多くのサービスには問い合わせ窓口（abuse@、support@、contact@ といったメールアドレス）があり、連絡すれば対応されることは少なくない。今回のMusicMintも、メールを送った翌日には消えていた。法的根拠を完璧に組み立てなくても、運営判断で消してくれるケースは多い。

それでも消えなければ、ホスティング事業者に通報。 サイトがCloudflareやAWS、Google Cloudといったインフラの上で動いている場合、それらの事業者にも権利侵害の通報窓口がある。サイト運営が無視しても、インフラ側から圧力がかかることはある。ただし前述のとおり、AI楽曲は著作権の足場が弱いので、ここも万能ではない。

本当に守りたい音源は、公開しない。 身も蓋もないが、これも立派な選択肢のひとつだ。聴いてもらう機会と引き換えに取得リスクを引き受けるのか、守るために公開を諦めるのか。中間の工夫はいろいろあるにせよ、「公開したうえで完全に守る方法」は、技術的にも法的にも、今のところ存在しない。

おわりに

「SUNOは音源URLが丸見えでセキュリティが甘い」という指摘そのものは、間違っていない。ただ、そこから「対策すれば守れるはずだ」「他社はちゃんとやっている」へ進むと、いくつかの前提を踏み外す。

100%の音源保護は技術的に存在しない。SpotifyやApple MusicのDRMは、レーベル音源を扱うための契約上の必須要件という側面が強く、そのDRMですら完璧ではない。SoundCloudは分割配信と期限つきURLへ静かに移行して、保護のレベルを一段上げつつある。SUNOのレベル1は、シェアを最大化するための設計判断と読むのが実態に近い。そしてAI生成楽曲には、どれだけ技術で固めても埋まらない、著作権上の弱さがある。

サービス側にできるのは、コストと効果を天秤にかけて、自分のサービスに見合った保護レベルを選ぶことだ。Rezonateも例外ではなく、いまの規模とリスクに釣り合うと考える場所に線を引いている。作る側にできるのは、公開のリスクを引き受けたうえで、見つけたら淡々と削除依頼を出していく地道な運用だ。

「完全に守る」という方向に答えはない。これはAI音楽に限らず、Webで音を配信するという行為そのものに織り込まれた現実で、今回の騒動は、それを改めて突きつけてきた出来事だったのだと思う。