本記事は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