Navidromeで音楽ライブラリを自分のサーバーから配信する
あなたのパーソナルストリーミングサービス。 Navidrome Music Server Navidrome は、オープンソースの Web ベースの音楽コレクション サーバーおよびストリーマーです。
ひと目でわかる
- これは何？
- navidrome/navidrome は、ブラウザやモバイル端末から手元の音楽を聴くためのオープンソースWebサーバーです。大規模ライブラリ、メタデータ、複数ユーザー、歌詞、Transcoding、Subsonic系クライアント、Dockerと配布バイナリをREADMEから確認します。
- 誰に向いている？
- Navidromeは、既存の音楽ファイルとメタデータを自分で管理し、複数の端末から聴きたい人に向きます。商用ストリーミングのカタログ提供や、masterを安定版として運用する用途には向きません。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
手元のライブラリをWeb化する
READMEはNavidromeをopen source web-based music collection server and streamerと説明し、ブラウザやモバイル端末から自分の音楽コレクションを聴けるとしています。商用サービスからカタログを借りる仕組みではなく、利用者が保管するファイルとメタデータを読むサーバーです。
大きなコレクション、ほぼすべての音声形式、整理したメタデータ、Various Artistsのコンピレーション、multi-discのbox setへの対応が機能として挙げられています。対応表や実際のスキャン時間はREADMEにないため、自分のタグ規則とファイル形式で確認します。
配布形態とreleaseの使い分け
READMEのInstallationはプロジェクトサイトの手順へ案内し、Docker imagesと主要プラットフォーム向けのready-to-use binaries、Raspberry Pi向けバイナリをFeaturesに挙げています。macOS、Linux、Windowsで動くという説明もあります。
一方、master branchは開発中にunstableまたはbrokenになり得るため、安定したバイナリにはreleasesを使うよう明記されています。初回導入では、Dockerか対象OSのrelease binaryを選び、masterを取得して運用開始しません。データディレクトリ、音楽ディレクトリ、公開ポート、ユーザー設定は公式installationの対象版で確認します。
メタデータ、歌詞、ライブラリ監視
Navidromeは音楽ファイルのメタデータを読み、ライブラリの変更を自動監視して新しいファイルを取り込み、新しいmetadataを再読み込みするとREADMEにあります。歌詞はsidecarの.ttml、Lyricsfileの.yamlと.yml、.elrc、.lrc、.srt、.txt、埋め込みタグをlyricspriorityで扱うと説明されています。
検証では、同じアルバムにVarious Artistsを含め、複数ディスクを置いて表示単位を確認します。sidecar歌詞と埋め込み歌詞の優先順をlyricspriorityで変え、ファイル追加後に再スキャンを待つ時間とログを記録します。READMEは破損タグや文字コードの処理を詳説していないため、手元のライブラリを小さなサンプルに分けます。（対象リポジトリ: navidrome/navidrome）
複数ユーザーとクライアントの接続
Featuresにはmulti-userがあり、各ユーザーにplay counts、playlists、favouritesなどがあるとしています。Web interfaceはMaterial UIベースでmodern and responsiveと説明され、Subsonic、Madsonic、Airsonicのclientsとの互換性も案内されています。互換クライアントの一覧は公式docsのappsページが入口です。
ユーザーごとの再生履歴が分離されるか、プレイリストの権限、モバイルブラウザの表示、Subsonic系クライアントのログインと再生を別に確認します。READMEには認証方式、外部公開時のTLS、ユーザー数の基準はありません。インターネット公開を前提にせず、まず家庭内または検証用ネットワークで接続範囲を固定します。（対象リポジトリ: navidrome/navidrome）
Transcodingとクラウド運用の境界
READMEはon-the-fly transcodingをユーザーまたはplayerごとに設定でき、Opus encodingをサポートすると説明しています。再生端末や帯域に応じて音声形式を変えられる入口ですが、対応する入力codec、CPU使用量、同時再生数はこの資料からは分かりません。小さな音源で変換前後の形式とログを確認します。
クラウド運用についてはPikaPodsをofficially supported cloud-hosted solutionとして案内し、収益の一部が開発資金になるとしています。自前のDockerやバイナリ運用とPikaPodsは、データ管理と費用の責任範囲が違います。ライセンスはGPL-3.0です。v0.63.2を基準に、ライブラリ、設定、変換、クライアントを同じreleaseで再確認してから公開範囲を決めます。
Navidromeの最初の評価は、音楽ファイルの読み込みから端末の再生までを小さく通すことです。releaseのバイナリまたはDockerを使い、masterは避けます。Various Artists、multi-disc、埋め込みタグ、sidecarの.ttmlと.lrcを用意し、lyricspriorityの順序とライブラリ監視の反映を記録します。別ユーザーのplay counts、playlists、favouritesが分かれるか、Subsonicクライアントからログインできるかを別に確認します。Opusのon-the-fly transcodingは入力形式、CPU、同時再生をREADMEが数値化していないため、小さな条件から測ります。PikaPodsと自前Dockerは責任範囲が異なり、GPL-3.0とv0.63.2を記録して公開前の設定を確定します。（対象リポジトリ: navidrome/navidrome）
Navidromeで音楽ライブラリを自分のサーバーから配信するについても、この確認単位を崩さないことが必要です。Navidromeで音楽ライブラリを自分のサーバーから配信する
この判断で見るべきなのは、READMEの宣伝文句ではなく、対象版で再現できる境界です。導入前にプロジェクト名、参照タグ、設定ファイル、入力、出力、失敗時のログを一組にして保存します。公式READMEに書かれていない既定値は、記事の事実として補いません。小さな入力で正常系を通した後、権限不足、空の入力、再起動、版の不一致を順に試します。結果が仕様と一致しない場合は、採用を急がず、その差をissueや公式ドキュメントの該当箇所と照合します。ライセンスは利用形態を確認する入口であり、認証や個人情報の扱いを判断する資料ではありません。更新時はリリースタグと変更点を記録し、前の組み合わせへ戻せる状態を残します。（対象リポジトリ: navidrome/navidrome）
記事で扱った範囲には、READMEが直接説明した事実と、まだ資料に現れていない条件があります。前者はコマンド、ファイル名、タグ、API、ライセンスとして再確認できます。後者は性能、可用性、認証、保存、復旧などの運用条件です。両者を同じ確度で書かず、対象リポジトリの版を変えたときは、同じ入力と同じ設定で結果が変わらないかを記録します。採用を決める単位は製品名ではなく、実際に使う機能と責任範囲です。
編集部の結論
Navidromeは、既存の音楽ファイルとメタデータを自分で管理し、複数の端末から聴きたい人に向きます。商用ストリーミングのカタログ提供や、masterを安定版として運用する用途には向きません。まずreleaseのバイナリまたはDockerで小さなライブラリを読み込み、タグ、Various Artists、歌詞、Subsonicクライアント、再生時のOpus変換を順に確認してください。
コミュニティノート