# 音源分離ツールの選び方：Demucs / UVR5(MDX-Net) / Spleeter / Open-Unmix を要件で選ぶ

> 音源分離（Music Source Separation）の主要OSS——Demucs v4・UVR5(MDX-Net)・Spleeter・Open-Unmix——を、品質・速度・ライセンス・導入難度・メモリで横断比較。『どの案件でどれを選ぶか』を要件から逆引きできる意思決定フレームワークと、商用利用で必ず確認すべきライセンスの落とし穴を、実コードとともに解説します。

- 公開日: 2026-06-25
- 著者: 友田 陽大
- タグ: 音源分離, Demucs, UVR5, 技術選定, 音声処理, Python, 生成AI
- URL: https://tomodahinata.com/blog/music-source-separation-tool-selection-demucs-uvr-spleeter

## 要点

- 音源分離OSSは『万能の1つ』が無い。多ステム×最高品質ならDemucs v4、ボーカル/伴奏の2分離ならUVR5(MDX-Net)、高速・大量ならSpleeter、軽量な研究ベースラインならOpen-Unmix——要件で選ぶのが正解
- 品質の目安：Demucs v4はMUSDB HQで9.0〜9.20 dB SDRと公開モデルでSOTA級。Spleeterは高速だが品質は一段下、Open-Unmix(UMX)は参照実装。最高精度はDemucs+MDXのアンサンブル（UVRが実装）
- 商用案件の最大の落とし穴は『コードのライセンス』と『重みのライセンス』が別なこと。Open-UnmixのUMXLは重みが非商用(CC BY-NC-SA 4.0)。Demucs/Spleeter/UVRはMITだが、分離した音源の原盤権は常に別問題
- SDRはデータセット・バージョン・評価方法に依存する相対値。ベンチの数字を鵜呑みにせず『自分の素材で測る』のが鉄則。評価はmuseval(BSSEval v4)で数値化する
- 非エンジニアが手で使うならUVR5 GUI、サーバー自動化ならDemucs API / python-audio-separator。本番化（GPUワーカー×ジョブキュー×冪等性）の設計は別記事に分離した

---

## この記事のゴール

「音源を声と伴奏に分けたい」「ドラムだけ抜きたい」——音源分離（Music Source Separation, MSS）を始めようとすると、最初にぶつかるのが**ツールが多すぎる**問題です。Demucs、UVR5、MDX-Net、Spleeter、Open-Unmix……どれも「最先端」を名乗り、ベンチマークの数字を掲げています。

本稿は、これらを**横断的に比較し、「あなたの案件ではどれを選ぶべきか」を要件から逆引きできる意思決定フレームワーク**を提供します。個別ツールの使い方は各専用記事（[Demucs](/blog/demucs-v4-music-source-separation-production-guide) / [UVR5・MDX-Net](/blog/uvr5-mdx-net-vocal-separation-production-guide)）に譲り、本稿は**選定の軸**に集中します。読み終えたときに、次の3つができる状態を目指します。

1. 4大OSS（Demucs / UVR5・MDX-Net / Spleeter / Open-Unmix）の**得意・不得意を一言で説明**できる。
2. 自分の要件（品質・速度・ステム数・予算・運用体制）から、**迷わず1つに絞れる**。
3. 商用案件で**訴訟リスクになりかねないライセンスの落とし穴**を、事前に潰せる。

> **筆者について（信頼性の開示）**：私は、動画をアップロードするだけで「**音声分離 → 文字起こし → 翻訳 → 多言語吹き替え → 口元同期**」まで全自動化する**AI動画ローカライズ基盤を単独で設計・実装し、本番運用**しています。その**第1段（音声分離）でどのツールを使うか**は、後段すべての品質とコストを左右する実際の意思決定でした。本稿の選定軸は、カタログスペックの寄せ集めではなく、**実運用でツールを乗り換えながら得た判断基準**です。

---

## 30秒のまとめ（要件 → 推奨ツール）

| あなたの要件 | 推奨 | 理由 |
| --- | --- | --- |
| **drums/bass/vocals/other を最高品質で4分割** | **Demucs v4**（`htdemucs` / `htdemucs_ft`） | 公開モデルでSOTA級（9.0〜9.20 dB SDR） |
| **ボーカル/伴奏の2分離が主目的**（カラオケ・アカペラ） | **UVR5（MDX-Net）** | ボーカル/伴奏特化モデルが豊富で消し残りが少ない |
| **とにかく高速・大量処理、品質はそこそこ** | **Spleeter** | GPUで実時間の100倍。前処理の下ごしらえに最適 |
| **研究のベースライン・軽量な参照実装** | **Open-Unmix（UMX）** | 素直なBiLSTM。再現性と可読性が高い |
| **非エンジニアが手作業で使う** | **UVR5 GUI** | ドラッグ&ドロップ。Win/Mac/Linux対応 |
| **サーバーで自動化・APIにする** | **Demucs API** / **python-audio-separator** | コードから3行で呼べる |
| **絶対に最高品質**（納品・マスタリング） | **Demucs + MDX のアンサンブル** | 複数モデルの推定を合成。UVRが実装 |

「個別ツールの導入手順」は各専用記事へ。本稿はこの後、**選定の根拠**を一段深く掘ります。

---

## 4大OSSの全体像（一言ずつ）

まず、各ツールが「何者か」を最短で掴みます。

- **Demucs v4（Meta）**：**波形とスペクトログラムの両方**を見て、Transformerで橋渡しするハイブリッドモデル。**4ステム（+6ステム版でguitar/piano）**を高品質に分離する**総合力No.1**。MITライセンス。[→ 詳細](/blog/demucs-v4-music-source-separation-production-guide)
- **UVR5（Ultimate Vocal Remover）/ MDX-Net**：**ボーカル/伴奏の2分離に特化**したGUI＋モデル群。MDX-Netは周波数領域と時間領域を組み合わせた二段構成で、**消し残りの少なさ**に定評。GUIで誰でも使え、`python-audio-separator`でコード自動化も可能。MITライセンス。[→ 詳細](/blog/uvr5-mdx-net-vocal-separation-production-guide)
- **Spleeter（Deezer）**：**TensorFlow製**。2/4/5ステムの事前学習モデルを同梱し、**GPUで実時間の約100倍**という圧倒的な速さが武器。品質は最新世代に一歩譲るが、**大量の下ごしらえ**には最適。MITライセンス。
- **Open-Unmix（UMX, sigsep）**：**PyTorch製の参照実装**。3層の双方向LSTMでマスクを推定するシンプルな構造で、**研究のベースライン**として広く使われる。軽量で読みやすいが、品質は専用最適化された上記に譲る。

---

## 横断比較表

数字は「執筆時点・公式情報ベースの目安」です。**SDRは評価条件で変わる相対値**なので、最終判断は必ず[自分の素材での実測](#ベンチマークの数字を鵜呑みにしないsdrの罠)で。

| 観点 | **Demucs v4** | **UVR5 / MDX-Net** | **Spleeter** | **Open-Unmix** |
| --- | --- | --- | --- | --- |
| 開発 | Meta | Anjok07 ほか（OSS） | Deezer | sigsep |
| 方式 | 波形+スペクトル+Transformer | 周波数+時間の二段構成 | CNN（スペクトログラム） | BiLSTM（スペクトログラム） |
| ステム | **4 / 6** | 主に2（Vocals/Inst） | 2 / 4 / 5 | 4 |
| 品質（目安） | **最高（9.0〜9.20 dB）** | 高（ボーカル分離が特に強い） | 中（高速優先） | 中（参照実装） |
| 速度 | 中（GPU推奨・CPU可） | 中（GPU推奨） | **最速（GPUで100×実時間）** | 速め |
| 導入 | `pip install demucs` | GUI / `pip install audio-separator` | `pip install spleeter` | `pip install openunmix` |
| GUI | なし（CLI/API） | **あり** | なし | なし |
| コードのライセンス | MIT | MIT | MIT | MIT |
| **重みのライセンス** | MIT | モデル毎に確認 | MIT | **UMXLは非商用（CC BY-NC-SA）** |
| 向く用途 | 多ステム・総合品質 | ボーカル/伴奏分離 | 大量・高速下ごしらえ | 研究・ベースライン |

---

## 要件から選ぶ意思決定フローチャート

「結局どれ」を、**質問に答えていくだけで絞れる**形にしました。

```text
Q1. 何を分けたい？
├─ ボーカル と 伴奏 の2つだけ（カラオケ・アカペラ・吹替前処理）
│    └─ Q2. エンジニアが自動化する？
│         ├─ NO（手作業でOK）         → UVR5 GUI
│         └─ YES（サーバー/CIに組む）  → UVR5系を python-audio-separator で
│                                        ／ または Demucs --two-stems=vocals
│
└─ drums / bass / vocals / other に4分割（リミックス・耳コピ・教育）
     └─ Q3. 品質と速度、どちらを優先？
          ├─ 品質最優先（納品・主役） → Demucs v4（htdemucs_ft）
          ├─ バランス重視           → Demucs v4（htdemucs）
          └─ 速度・大量最優先        → Spleeter（4stems）で下ごしらえ
                                        → 採用分だけ Demucs で本処理（二段構え）

※ 研究のベースライン比較が目的 → Open-Unmix
※ 最後の数%まで品質を詰めたい  → Demucs + MDX のアンサンブル（UVR）
```

**意思決定の勘所**は2つです。

- **「2分離」か「多分離」か**で大きく道が分かれる。カラオケ・吹替前処理のように**声と伴奏だけ**欲しいなら、多ステムモデルはオーバースペック。ボーカル特化のUVR5/MDX-Netか、Demucsの`--two-stems=vocals`で十分。
- **品質と速度はトレードオフ**。全曲を最高品質で回すのは無駄が多い。**「Spleeterで全件下ごしらえ → 採用分だけDemucsで本処理」**の二段構えが、品質とコストを両立させる定石です。

---

## 商用案件で必ず効く：ライセンスの落とし穴

ここが**B2B案件で最も差がつく**ところです。「OSSだから商用OK」と雑に判断すると、後で足をすくわれます。**確認すべきは3層**あります。

### 第1層：コードのライセンス

Demucs・UVR5・Spleeter・Open-Unmix は、いずれも**コードはMITライセンス**で商用利用に対応します。ここは概ね安全。

### 第2層：重み（学習済みモデル）のライセンス ← 見落としがち

**コードがMITでも、配布される学習済みモデルのライセンスは別**です。最も典型的な罠が **Open-Unmix の UMXL**——高品質版の重みは**非商用ライセンス（CC BY-NC-SA 4.0）**で、**商用プロダクトに組み込むと違反**になります（商用なら無印 `UMX` / `UMXHQ` を選ぶ）。

> 🔑 **シニアの鉄則**：音源分離に限らず、AIモデルを商用導入するときは**「コードのライセンス」と「重みのライセンス」を必ず別々に確認**する。READMEのライセンス欄だけでなく、**モデル配布ページ（HuggingFace / 各モデルカード）のライセンス**まで読む。これを習慣にしているかどうかで、案件の安全性が変わります。

### 第3層：分離した「音源そのもの」の権利 ← 最重要

ツールが商用OKでも、**入力した楽曲の著作権・原盤権は別問題**です。市販曲を分離してカラオケ音源やアカペラとして**配布・販売する行為は、権利者の許諾が必要**。ツールの自由 ≠ 素材の自由。ここは技術ではなく**権利処理の問題**として、利用者（と発注元）の責任で押さえます。

| 確認すべき層 | Demucs | UVR5 | Spleeter | Open-Unmix |
| --- | --- | --- | --- | --- |
| コード | MIT ✅ | MIT ✅ | MIT ✅ | MIT ✅ |
| 重み | MIT ✅ | モデル毎に要確認 ⚠️ | MIT ✅ | **UMXLは非商用 ❌** |
| 分離した音源 | **常に別途・権利処理が必要** ⚠️ | 同左 | 同左 | 同左 |

---

## ベンチマークの数字を鵜呑みにしない：SDRの罠

「Demucsは9.2 dB、Spleeterは…」というSDR比較を見たら、**一歩引いて**ください。**SDR（Signal-to-Distortion Ratio）は、評価データセット・モデルのバージョン・評価方法（フレーム集計の取り方）に強く依存する相対値**です。論文Aの9.2 dBと記事Bの数字は、**そもそも同じ土俵で測っていない**ことが珍しくありません。

実務での正しい態度はこうです。

- **公式ベンチは「序列の目安」として使う**（Demucs > Spleeter という大小関係は信頼してよい）。
- **最終判断は必ず「自分の素材」で実測する**。J-POP・ナレーション・ポッドキャスト・ライブ録音——ジャンルやマイク環境で得意不得意は変わる。
- 実測は**耳だけでなく数値で**。`museval`（BSSEval v4）で SDR/SIR/SAR を出し、**候補ツールを同じ素材・同じ指標で並べる**。その具体的な手順は[音源分離の品質を数値で測る記事](/blog/music-source-separation-quality-evaluation-sdr-museval)にまとめました。

> 私が案件でツールを選ぶときは、**「公式ベンチで2〜3個に絞り → 顧客の実素材10本でmuseval比較 → 耳でも確認」**という二段階を踏みます。カタログの数字だけで決めると、本番素材で「思ったより消し残る」事故が起きます。

---

## ビルド vs バイ：OSSセルフホスト or 商用API

「そもそも自前で動かすべきか、SaaS APIを使うべきか」も選定の一部です。

| 観点 | OSSセルフホスト（Demucs等） | 商用API / SaaS |
| --- | --- | --- |
| 初期コスト | 環境構築・GPU調達 | ほぼゼロ（即日） |
| 単価 | **大量なら安い**（GPUを埋める） | 従量課金が積み上がる |
| データ主権 | **自社内で完結**（機密音源も安全） | 外部送信が必要 |
| カスタマイズ | モデル・パラメータを自由に | 提供範囲に依存 |
| 運用負荷 | **自分で見る**（本記事群の出番） | 任せられる |

**判断の目安**：

- **少量・試作・データ機密性が低い** → まず商用API or ローカルCLIで品質を確かめる。
- **定常的に大量・データ機密性が高い・単価を下げたい** → **OSSをセルフホスト**。GPUワーカーで回す。その本番設計は[音源分離を本番APIにする記事](/blog/music-source-separation-production-api-gpu-worker-queue)で詳述しています。

**一人 × 生成AI**で開発を進める私のスタンスは「**まずOSSローカルで品質と需要を確かめ、量が見えたらセルフホストのGPUワーカーに載せる**」。これが、無駄な固定費を払わず、かつロックインも避ける現実解です。

---

## よくある質問（FAQ）

**Q. 結局、最初の1つは何を入れればいい？**
A. **多ステム分離なら Demucs、ボーカル/伴奏だけなら UVR5**。この2つを押さえれば大半の案件はカバーできます。迷ったら Demucs から。

**Q. Demucs と UVR5(MDX-Net) はどちらが上？**
A. **目的次第**。drums/bass/other まで欲しい総合力は Demucs、ボーカル/伴奏の消し残りの少なさは MDX-Net 系が強い場面が多い。最高品質を狙うなら**両者をアンサンブル**（UVRが実装）。

**Q. Spleeter はもう古い？**
A. 品質では最新世代に譲りますが、**速度は依然トップクラス**。「全件を高速に下ごしらえ → 採用分だけ高品質モデルで本処理」の前段として現役です。

**Q. 商用プロダクトに組み込んで大丈夫？**
A. コードはいずれもMITで概ねOK。ただし**重みのライセンス（特にOpen-Unmix UMXLは非商用）**と、**入力楽曲の権利処理**を必ず別個に確認してください（[ライセンスの章](#商用案件で必ず効くライセンスの落とし穴)）。

**Q. CPUしかありません。**
A. 動きます（遅い）。Demucsは約1.5×実時間、Spleeterは比較的軽い。大量ならGPUを推奨しますが、少量検証はCPUで十分です。

**Q. ベンチで一番SDRが高いものを選べばいい？**
A. **危険です**。SDRは評価条件依存の相対値。**自分の素材でmuseval実測**して選ぶのが鉄則です（[SDRの罠](#ベンチマークの数字を鵜呑みにしないsdrの罠)）。

---

## まとめ：ツール選定は「要件 → 制約 → 実測」の順で

音源分離OSSに「万能の1つ」はありません。だからこそ、選定は**感覚ではなくフレームワーク**で行うべきです。

1. **要件**：何を分けたいか（2分離 or 多分離）、品質と速度のどちらを優先するか。
2. **制約**：ライセンス（コード・重み・素材の3層）、予算、運用体制、データ機密性。
3. **実測**：候補を2〜3に絞り、**自分の素材でmuseval比較**してから決める。

この順で詰めれば、「とりあえず有名なものを入れて後で後悔」を避けられます。そして——**この選定そのものが、外注で価値が出るところ**です。ツールを動かすだけなら誰でもできますが、**要件と制約を読み解いて最適な1つ（または組み合わせ）を選び、ライセンスリスクまで潰す**のは、経験がそのまま品質になります。

> 私は、本稿の選定軸を**実際に本番運用しているAI動画ローカライズ基盤**で使ってツールを決めてきました。音源分離を含む音声/動画AIの技術選定・PoC・本番化をお考えなら、[実績](/case-studies/ai-video-localization-lipsync)をご覧のうえ、お気軽にご相談ください。**一人 × 生成AI**で、速く・安く・安全に意思決定から実装まで伴走します。

---

## 出典・公式リソース

- **Demucs**：[adefossez/demucs](https://github.com/adefossez/demucs) — モデル一覧・SDR・ライセンス（[解説記事](/blog/demucs-v4-music-source-separation-production-guide)）
- **UVR5 / MDX-Net**：[Anjok07/ultimatevocalremovergui](https://github.com/Anjok07/ultimatevocalremovergui) ／ [MDX-Net 論文 arXiv:2111.12203](https://arxiv.org/abs/2111.12203)（[解説記事](/blog/uvr5-mdx-net-vocal-separation-production-guide)）
- **Spleeter**：[deezer/spleeter](https://github.com/deezer/spleeter) — TensorFlow・2/4/5stems・MIT
- **Open-Unmix**：[sigsep/open-unmix-pytorch](https://github.com/sigsep/open-unmix-pytorch) — UMX/UMXHQ/UMXL（**UMXLは非商用ライセンス**）
- **評価ツール**：[sigsep/sigsep-mus-eval（museval）](https://github.com/sigsep/sigsep-mus-eval) — BSSEval v4（SDR/ISR/SIR/SAR）

※ ライセンス・品質・料金は更新されます。**商用利用は必ず一次情報（特に重みのライセンス）を確認**してください。本稿の数値は執筆時点の公式情報に基づく目安です。