本記事は2部構成です。
第1部では、Zilliz Customer Story「How a World-Leading Music Platform Searches 100M+ Songs by Sound and Lyrics with Milvus」を、原文の構成と内容に沿って日本語化します。
第2部では、そこから先を日本市場に置き換え、国内の音楽配信、音源検索、UGC、権利管理、そしてAIネイティブな音楽サービスでどのような応用が考えられるかを整理します。
原文：
https://zilliz.com/customers/music-streaming-platform
※第1部は原文の内容に忠実な翻訳です。日本企業・日本市場に関する記述は第2部からの追加考察です。
※GitHub Star数などの数値は、原文掲載時点の記載をそのまま反映しています。
第1部：Zilliz Customer Story 原文の日本語訳
世界有数の音楽プラットフォームは、Milvusで1億曲超を「音」と「歌詞」からどう検索しているのか
100M+ tracks
1億曲超の楽曲
ロングテールを含むカタログ全体をEmbedding化し、検索可能な状態にしています。
~10 ms P99
P99 約10ミリ秒
数十億のAudio Embeddingを対象に、毎秒数百件の検索を処理しながらマッチングします。
By sound and meaning
音と意味の両方から検索
曲名だけではなく、鼻歌、短い音声クリップ、言い換えた歌詞からも楽曲を探せます。
音楽プラットフォームについて
このプラットフォームは、世界最大級の音楽ストリーミングサービスの1つです。カタログは1億曲を超え、100か国以上で数億人のリスナーが利用しています。
しかし、リスナーがすることは、単に再生ボタンを押すだけではありません。
部屋の向こうで流れている曲の名前を知るためにスマートフォンをかざしたり、うろ覚えの歌詞の一節を入力して曲を探したり、「これに似た曲をもっと」と頼んで夜のプレイリストを作ったり、自分でアップロードした音源が権利上問題ないかカタログと照合したりします。
これらはすべて、カタログ全体を検索します。そして、正しい楽曲へ即座に到達しなければなりません。
この検索レイヤーを支えているのが Milvus です。
The Challenge — 課題
プラットフォームのカタログは1億曲を超えています。そして、リスナーが音楽を検索する方法から、同時に3つの要件が生まれました。
1. 音楽検索はキーワードだけではなく、「音」と「意味」で動かなければならない
リスナーはメロディを鼻歌で歌ったり、スピーカーから流れる音を5秒だけ録音したり、歌詞を実際に書かれた通りではなく、自分の記憶通りに入力したりします。
そこには、照合に使える曲名やタグが存在しないことがあります。
プラットフォームには、曲がどう聞こえるか、そして歌詞が何を意味しているかを基に検索できる仕組みが必要でした。これはキーワードマッチだけでは実現できません。
2. カタログは数十億ベクトルになり、それらすべてを検索可能に保つ必要がある
音でマッチングするには、各楽曲を短いセグメントに分割し、それぞれをEmbedding化します。
そのため、1億曲超のカタログは数十億のAudio Vectorになり、さらに各歌詞セットに対するText Vectorも加わります。
そして、そのすべてを同時にオンラインで検索可能にしておく必要があります。ロングテールも例外ではありません。
なぜなら、1年間誰にも再生されていないような無名の楽曲こそ、検索から落ちてしまえば「探しているのに見つからない」曲になってしまうからです。
3. すべての検索を、大規模環境でリアルタイムに返さなければならない
楽曲認識も歌詞検索も、ユーザーがその場で結果を待つ機能です。
したがって、数十億のベクトルを対象に、毎秒数百件の検索を処理しながら、ミリ秒単位で結果を返す必要があります。
さらに、カタログが増え続けても検索速度が低下してはいけません。
Why Milvus — なぜMilvusなのか
Milvusは、この3つの要件に直接対応します。そのため、このチームは検索基盤としてMilvusを採用しました。
Vector・全文検索・メタデータフィルタを1つのクエリで扱える
MilvusはAudio EmbeddingとLyric Embeddingを格納し、音声クリップがどう聞こえるか、あるいは歌詞が何を意味するかを基にNearest Neighborを検索します。
そのため、鼻歌や言い換えた歌詞からでも正しい楽曲へ到達できます。
歌詞検索では、Full-Text Keyword SearchとVector Searchを1つのHybrid Queryで組み合わせます。つまり、「同じ単語」と「同じ意味」を同時に評価できます。
さらに、同じ呼び出しの中で次のようなMetadata Filterを適用します。
- Artist
- Genre
- Territory
- Rights
これはKeyword-onlyのシステムだけでは実現できないHybrid Searchです。
数十億ベクトルで実証されたスケーラビリティ
Milvusは、Billion-scaleのCollectionを前提に設計されたDistributed Databaseです。
Embedding化されたカタログ全体を1つのシステムに置き、ライブラリの成長に合わせてクラスタをScale-outできます。
新しい規模の節目を迎えるたびに検索アーキテクチャを作り直す必要はありません。
高Throughputでもミリ秒レベルのLatency
Milvusは、数十億ベクトルに対し毎秒数百クエリを処理しながら、約10ミリ秒でMatchを返します。
また、重いIndexing処理をLive Queryから分離するため、新しい音楽が追加されている最中でも検索を高速に維持できます。
Open Sourceで、自社インフラ上に構築できる
これらの要件を満たすだけでなく、MilvusはOpen Sourceです。
この規模で運用するチームはMilvusを自社インフラ上で動かし、Workloadに合わせてTune・拡張し、Vendor Lock-inなしで既存の技術スタックに統合できます。
The Solution — ソリューション
Milvusは、音楽がどう聞こえるか、あるいは何を意味するかを基に楽曲を探す、すべての機能の下にあるSimilarity Search Layerとして動きます。
AudioとTextはいずれもVectorになり、それらを絞り込むMetadataと一緒にMilvusへ格納されます。
アーキテクチャ図は次のようになります。
カタログをIndexingする
各楽曲を、短く、互いに重なるAudio Clipへ分割します。
Audio Modelは各ClipをVectorに変換し、音色（Timbre）、メロディ、リズムなど、その音がどう聞こえるかを表現します。
そのため、1曲は1つの点として表現されるのではなく、数秒ごとに1本という一連のVectorとして表現されます。
歌詞は別のText Modelで処理します。
各歌詞セットをVectorとしてEmbeddingすると同時にFull-Text Search用にもIndexingし、意味でも完全一致した単語でも検索できるようにします。
さらに、同じRecord上にScalar Fieldとして次の情報を書き込みます。
- Artist
- Album
- Genre
- Release date
- Popularity
- Territory / Rights
Audio ClipはBillion-scaleのCollectionを構成し、その横にLyric Vector、Full-Text Index、Metadataが配置されます。
Graph-based ANN Indexである HNSW により高速なRecallを維持し、Scalar IndexによってMetadataをFilter可能にします。
Queryに答える
4つのProduct Featureはいずれも、Milvus上のSimilarity Searchへ解決されます。
1. Song recognition — 楽曲認識
数秒の録音音声をEmbedding化し、MilvusのAudio Collectionに対して検索します。
Milvus側では、各楽曲は順序を持った多数の短いClipとして保存されています。
録音された音は、同じ楽曲から続いている複数のClipに連続してMatchします。
このような連続した一致を作れるのは正しい楽曲だけなので、Milvusは対象を1曲に絞り込み、リアルタイムに返します。
2. Lyric search — 歌詞検索
各歌詞はMilvus内の同じRecordに、
- Semantic Dense Vector
- Full-Text（BM25）Index
の両方を持ちます。
1回のHybrid Searchで「意味」と「表現」を同時にMatchし、1つのRanked Listとして返します。
リスナーが歌詞を一字一句覚えていても、意味だけを曖昧に覚えていても、正しい曲へ到達できます。
3. Recommendation — レコメンド
リスナーが現在再生している楽曲そのものをQueryとし、Milvusが音響的に類似した楽曲を返します。
RadioやDiscovery向けの候補を、リスナーのTerritoryやTasteに応じてFilterします。
4. Copyright matching — 著作権照合
アップロードされたAudio ClipをChunk化してカタログ全体に対して検索します。
高いSimilarityを持つHitが連続して現れれば、保護された素材が再利用されている可能性をFlagできます。
その後、Rights Fieldから権利者情報を解決します。
1つのデータを、4つの機能から検索する
4つのFeatureはすべて、Milvus内にある同じデータを検索します。
- 同じAudio Vector
- 同じLyric Vector
- 同じMetadata
- 各Queryに付与される同じFilter
異なるのはTuningです。
チームはRetrieval Layerを複数のMilvus ClusterからなるFleetとしてSelf-hostし、それぞれを役割に合わせてSizingしています。
例えば、Song RecognitionのPathでは最低Latencyを重視し、Full-catalog Collectionでは数十億規模まで成長した際のThroughputとRecallを重視します。
新曲も同じIndexing Pathを通り、取り込まれた瞬間から検索可能になります。
Results & Benefits — 結果とメリット
戦略的な価値は、「音から検索すること」が個別Projectではなく、プラットフォーム共通のCapabilityになることです。
音楽がどう聞こえるかを利用する新しい機能を作りたいとき、すでに1億曲超をリアルタイム検索できるFoundationから始められます。
約10ミリ秒で楽曲を特定し、毎秒数百検索を処理
数秒の音声、あるいは歌詞1行から正しい楽曲を返します。
高い同時実行負荷があっても、リスナーには「瞬時」と感じられる速度です。
1億曲超、数十億Vectorのすべてを検索可能に維持
すべての楽曲がEmbedding化され、Onlineのまま維持されます。
ロングテールも含まれるため、カタログが巨大になったことを理由に「検索できない曲」が生まれません。
曲名だけでなく、音と意味から楽曲を発見
鼻歌、5秒間のAudio Clip、うろ覚えの歌詞からでも正しい楽曲へ到達します。
これはKeyword Searchだけでは実現できない検索体験です。
Recognition、Lyric Search、Recommendation、Copyright Matchingを1つのEngineで実行
新しいAudio Featureを作るたびに新しい検索システムを立ち上げるのではなく、Full Catalogをすでにリアルタイム検索できるレイヤーからスタートできます。
自社インフラ上で動かし、Clusterを拡張してScale
TrafficやCatalogが成長した場合も、運用中のMilvus ClusterにCapacityを追加して対応できます。
Search Layerそのものを再設計する必要はありません。
Get started with Milvus
Milvusは、原文掲載時点でGitHub Star 46K+を持つ、世界で広く利用されているOpen Source Vector Databaseです。
LaptopからDistributed Clusterまでどこでも動作し、Vector WorkloadのIndexing、Filtering、Scalingをチーム自身でControlできます。
GitHubからMilvusを始めることも、Documentationを読むことも、Discord Communityへ参加することもできます。
Milvusを自分たちで運用したくないチームは、同じEngineをFully Managed Serviceとして提供する Zilliz Cloud を利用できます。Free Tierから開始できます。
第2部：この事例を日本市場に置き換えて考える
ここからは原文の翻訳ではありません。
上の事例が示した「巨大なAudio / Text CatalogをVector化し、音・意味・Metadataを横断してリアルタイム検索する」という考え方を、日本の音楽サービスやAIネイティブ企業に置き換えて考えます。
なぜ日本でも今、このテーマが重要なのか
日本レコード協会が2026年3月に発表した2025年の国内市場推計では、音楽配信売上は約1,700億円。そのうち、Subscriptionと広告収入を合わせたStreamingは約1,580億円で、音楽配信の約**93%**を占めます。
つまり現在の音楽ビジネスでは、「何を配信できるか」だけでなく、巨大なCatalogの中からユーザーが次に聴きたい1曲へどう到達するかがますます重要になっています。
出典：日本レコード協会
https://www.riaj.or.jp/news/press/94d112e4-697a-4990-9f80-a721d1f5a921/
そして日本には、単なる「曲名検索」では捉えにくいコンテンツ文脈があります。
- J-POP / アニソン / ゲーム音楽
- ボカロ / 歌い手 / VTuber
- Original / Live / Acoustic / THE FIRST TAKE的な別演奏
- Cover / Remix / Karaoke / Off Vocal
- TV Size / Anime Edit
- 日本語・英語・ローマ字の表記差
- UGCやShort Videoの中で使われる短い音源
- 生成AIによって急増する新規音源
こうした世界では、Metadataだけでなく音そのもの、歌詞の意味、作品文脈、Rights、User Behaviorを組み合わせて検索する価値が大きくなります。
日本でも「1億曲」「2億曲」の世界はすでに現実
このZilliz事例の「100M+ tracks」は、海外だけの特殊な規模ではありません。
LINE MUSICは公式に1億曲以上を提供していると説明しています。
さらにAWAは2026年5月、配信楽曲数が2億曲を突破したと発表しました。
Catalogがここまで大きくなると、課題は「曲を保存できるか」ではなく、
2億曲の海から、その瞬間にユーザーが求めている数十曲をどう候補として取り出すか
になります。
この部分はまさに、Vector DatabaseがCandidate Retrieval Layerとして価値を出しやすい領域です。
日本ですでに見えている「Vector Search型」の音楽体験
LINE MUSIC / LINEヤフー：自然言語から音楽を検索する
LINEヤフーの研究部門は、対話型音楽推薦について公開しています。
ユーザーが入力する「今の気分」「音楽を聴きたい状況」のような抽象的なQueryをLLMで解釈し、Vectorとして表現した上で、
- Text-to-Music Retrieval：音響的特徴から検索
- Lyric-to-Music Retrieval：歌詞の意味から検索
- Metadata-based Retrieval：Metadataから検索
を統合してPlaylistを生成する研究です。
これは原事例の「Sound + Lyrics + Metadata」という設計と非常に近い方向です。
将来的に1曲が複数のEmbeddingを持つようになるほど、検索基盤には単なるANNだけではなく、Multi-Vector、Hybrid Search、Filter、Rerankingを組み合わせる柔軟性が求められます。
Audiostock：「キーワードが分からない」をAudio Searchで解く
Audiostockは、手元のMP3/WAVをUploadすると、Audiostock内からイメージの似た楽曲を探せる「音楽で検索」機能を提供しています。
公式説明では、音響信号を解析して音源間の類似度を推定する技術が使われています。
これはとても日本らしい実務ユースケースです。
映像制作や広告制作では、ユーザーが必ずしも
「BPM 118、Female Vocal、Synth Pop」
と検索したいわけではありません。
むしろ、
「クライアントからこの参考曲を渡された。これに近い雰囲気で、利用可能なBGMを探したい」
という仕事が多くあります。
ここでは、 Query-by-Example（例をそのままQueryにする検索） がKeyword Searchより自然です。
なお、Audiostockの公開情報では検索結果通知まで数分〜数十分を想定していますが、その時間のどこがEmbedding生成、Queue処理、Retrieval、後処理に使われているかは公開されていません。そのため「Vector DBを入れればそのまま10msになる」という単純比較はできません。
それでも、音をQueryにしてCatalogを探したい需要が日本でも実際にあることを示す分かりやすい例です。
日本の音楽サービスで考えたい6つのユースケース
1. 「この曲に似た曲」を探すContent-based Recommendation
現在再生している曲をQueryとして、Audio Vectorが近い楽曲を取得します。
Currently Playing Song
↓
Audio Embedding
↓
Milvus / Zilliz Cloud
↓
Similar Song Candidates
↓
User Behavior / Popularity / FreshnessでRerank
↓
Next Song / Radio / Discovery
Vector Searchが担当するのは、推薦システム全体ではなく、巨大なCatalogから関連度の高い候補を絞るCandidate Retrievalです。
最終順位には、
- 再生履歴
- Like / Skip
- Playlist追加
- Artist affinity
- 時間帯
- 新曲Boost
- Popularity
- Diversity
などを加えられます。
2. 新曲・インディーズ・新人アーティストのCold Start
Collaborative Filteringは強力ですが、Interactionがまだ存在しない新曲には弱いという問題があります。
日本で考えると、
- 新人アーティストのデビュー曲
- インディーズの新曲
- 新作アニメのOP / ED
- 新しいボカロ曲
- VTuberのOriginal Song
などです。
Audio EmbeddingやLyrics Embeddingがあれば、再生履歴が少ない段階でも既存曲との類似性を使ってCandidateを作れます。
これはLong-tailを発見させる仕組みとしても重要です。
3. 鼻歌・短い録音・「うろ覚え歌詞」から検索
原事例で特に面白いのは、Search Boxへ文字を入力するだけの検索ではないことです。
鼻歌
短い録音
部屋で流れている数秒の音
うろ覚えの歌詞
↓
Audio / Text Embedding
↓
Similarity + Full Text Hybrid Search
↓
Track
ただし、鼻歌検索ではQuery-by-Hummingに対応したModelが必要です。
Vector Databaseは「どんなAudioでも自動的に鼻歌検索できる魔法のModel」ではなく、Modelが作ったEmbeddingを巨大なCatalogに対して検索するServing Layerです。
ModelとRetrieval Infrastructureを分離して考えることが重要です。
4. Live / Cover / Remix / Karaoke / 重複音源の候補検出
日本のCatalogでは、同じCompositionに対して多数のVersionが存在します。
例えば、
Original
Live ver.
Acoustic ver.
Remastered
TV Size
Instrumental / Off Vocal
Cover
Remix
Karaoke
Metadataだけで全関係を管理しようとするとRulesが複雑になります。
Audio Similarityを使えば、まず「音響的に近い候補」を高速に探し、その後にFingerprint、Rights Metadata、Business Ruleで精査できます。
ここでVector Searchを最終的な著作権判断そのものに使うのではなく、Recallを高めるCandidate Generation Layerとして使うのが現実的です。
5. UGC / Short Video / VTuber配信のAudio Matching
YouTube、Short Video、Live Streaming、VTuber、Game実況などでは、長いVideoの一部に音楽が含まれます。
UGC Video / Live Archive
↓
Audio Extraction
↓
3〜5秒単位にChunk
↓
Embedding
↓
Milvus
↓
Top-K Candidate Tracks
↓
Fingerprint / Rights Rule / Human Review
原事例で「1曲を短いClipの列として持つ」設計が重要なのはここです。
1つのTrackに1 Vectorだけを付けるのではなく、時間軸を持った複数VectorとしてIndexすることで、長いContentの中の一部だけが使われたケースにも対応しやすくなります。
6. 生成AI時代のMusic Corpus Search
AI-nativeな音楽会社では、検索対象が「配信済みCatalog」だけではありません。
例えば日本発のSOUNDRAWは、AI Music GenerationをAPIとして外部Productへ組み込めるサービスを提供しています。
生成音楽の世界では、同じVector Infrastructureを次のような用途へ広げられます。
Training Corpus
Generated Songs
Loops / Stems
Reference Music
User Generated Music
↓
Embedding
↓
Vector Search Layer
↓
Dedup / Near-duplicate Search
Dataset Curation
Similar Sample Retrieval
Generated-output Similarity Check
Recommendation
Text-to-Music Retrieval
ここで特に面白いのは、ServingとModel Developmentが同じEmbedding Catalogを共有できることです。
音楽生成AIの会社にとってVector DBは、Recommendation Engineの部品だけではなく、Training Data、Evaluation、Safety / Rights Review、Product Searchを横断するMusic Data Layerになり得ます。
生成AI時代は「権利照合」の負荷も増える
TuneCore Japanは、Release審査で複数の第三者楽曲Databaseと照合しており、類似した波形のSampleやLoop素材が検知された場合に確認を行うことを公開しています。
また、生成AIで制作された可能性が高い音源について、Guidelineへの同意や証明資料を求める審査フローも公開しています。
生成AIで「作れる曲数」が急増すると、同時に、
- Near Duplicate
- Sample / Loop Reuse
- Existing CatalogとのSimilarity
- Training CorpusのDeduplication
- Rights Metadataとの紐付け
を大量に処理する必要も増えていきます。
この部分でも、Exact FingerprintだけでなくVector SearchをCandidate Retrievalとして組み合わせる設計が考えられます。
日本向けなら「Audioだけ」で終わらせない
原事例はすでにAudioとLyricsの両方を扱っていますが、日本向けにさらに発展させるなら、1曲に複数の検索表現を持たせるのが自然です。
song_id
│
├─ audio_clip_vectors[] 音色 / Melody / Rhythm
├─ lyrics_dense_vector 歌詞のSemantic
├─ lyrics_fulltext BM25 / Keyword
├─ metadata_vector 紹介文 / Genre / 作品文脈
├─ behavior_vector User behaviorから学習した表現
│
└─ scalar metadata
├─ artist_id
├─ language
├─ release_year
├─ anime_title
├─ game_title
├─ is_live
├─ is_cover
├─ is_remix
├─ territory
└─ rights_status
例えばQueryが、
「夏の夜に聴きたい、少し切ないシティポップ。女性ボーカルで、2015年以降」
なら、
- Text QueryからIntentをEmbedding化
- Text-to-MusicでAudio Vector Search
- Lyrics Semantic Search
- Full-Text / Metadata Search
-
release_year >= 2015、vocal=femaleなどScalar Filter - 複数結果をRRF / Weighted Ranker等でFusion
- User TasteやBusiness Ruleで最終Rerank
という構成が可能です。
Vector Searchを単なる「似た音探し」ではなく、Programmable Search Spaceとして使う考え方です。
検索基盤として見ると、評価すべきなのは「Vector数」だけではない
原事例には、
- 100M+ tracks
- billions of audio vectors
- ~10ms P99
- hundreds of searches per second
という分かりやすい数字が出ています。
しかし、自社で同じ仕組みを評価するときは、単に「何億Vector入るか」だけでは足りません。
少なくとも次を自分たちのWorkloadで確認する必要があります。
| 観点 | 例 |
|---|---|
| Scale | Tracks数、Clip数、総Vector数 |
| Query | Audio-to-Audio、Text-to-Music、Lyrics、Hybrid |
| Recall | 正しいTrackがTop-Kへ入る率 |
| Latency | p50 / p95 / p99 |
| Throughput | QPS、Peak QPS |
| Filter | Territory、Rights、Genre等のSelectivity |
| Update | 新曲追加頻度、Index反映時間 |
| Hybrid | Dense + BM25 + MetadataのFusion |
| Cost | SearchあたりCost、TB / Billion vectorsあたりCost |
公開Benchmarkだけでなく、自社のDataとQuery Patternで評価することがProductionでは重要です。
まとめ：これは「音楽検索の事例」だけではない
このCustomer Storyの面白さは、単に「Milvusなら1億曲を検索できる」という点ではありません。
本質は、
非構造化データをEmbeddingに変え、巨大なCatalogを丸ごとOnlineに保ち、Vector・Full Text・Metadataを組み合わせてリアルタイムに検索する
という設計にあります。
音楽では、それが
- Song Recognition
- Lyric Search
- Recommendation
- Copyright Matching
として現れています。
日本市場に置き換えると、さらに
- J-POP / アニソン / ボカロのDiscovery
- Live / Cover / Remixの整理
- UGC / VTuber / Short VideoのAudio Matching
- Production MusicのQuery-by-Example
- 生成AI MusicのCorpus Search / Dedup / Evaluation
へ広がります。
RAGの普及によって「Vector Database = 文書検索」というイメージが強くなりましたが、Milvusの適用先はTextだけではありません。
Audio、Image、Video、Product、User Behaviorなど、大規模な非構造化データを“似ているものから探す”問題は、すべて同じ検索パターンとして捉えることができます。
そして音楽は、その価値が非常に分かりやすく現れるユースケースの1つです。
参考リンク
- Zilliz Customer Story — Music Streaming Platform
https://zilliz.com/customers/music-streaming-platform - Milvus
https://milvus.io/ - Zilliz Cloud
https://zilliz.com/cloud - 日本レコード協会 — 2025年国内レコード市場
https://www.riaj.or.jp/news/press/94d112e4-697a-4990-9f80-a721d1f5a921/ - LINE MUSIC 10周年 / 1億曲以上
https://www.lycorp.co.jp/ja/news/release/017920/ - LINEヤフー Research — 対話型音楽推薦システム
https://research.lycorp.co.jp/jp/research_area/details/2 - AWA — 配信楽曲数2億曲突破
https://news.awa.fm/jpn/2026/5/1/over-200-million-songs-available-for-streaming - Audiostock — 「音楽で検索」
https://tips.audiostock.jp/entry/search_by_audio - SOUNDRAW AI Music API
https://soundraw.io/api - TuneCore Japan — 第三者楽曲データベースとの照合
https://support.tunecore.co.jp/hc/ja/articles/4403660267277