Navidrome 音楽サーバー構築｜Subsonic互換

Navidrome 音楽サーバー構築｜Subsonic 互換

現在、2026 年 4 月時点において、デジタル音楽を所有し、いつでもどこでも高品質な音質で楽しむというニーズはかつてないほど高まっています。しかし、Spotify や Apple Music といった大手ストリーミングサービスへの依存度が高まる一方で、月額利用料の増額や、楽曲の権利関係による削除リスク、そして何よりも「自分の所有物」である音楽データの管理権限を他人に預けることへの不安が生じています。そこで注目されているのが、自宅サーバーや NAS 上に音楽サーバーを設置し、自前で曲を管理・配信する「セルフホスティング」のスタイルです。その中でも、特にオープンソースで軽量かつ高機能な Navidrome は、2025 年以降のサブスク崩壊期において、個人ユーザーにとって最強の選択肢の一つとなりつつあります。

Navidrome は、Subsonic API に完全準拠した音楽サーバーソフトウェアであり、このプロトコルに対応するクライアントアプリケーションと組み合わせることで、まるでクラウドサービスを使っているかのようなシームレスな体験をローカルネットワーク内および外部環境でも実現できます。本記事では、2026 年春の最新情報に基づき、初心者から中級者までを対象に、Navidrome の構築から運用、そしてモバイル端末や PC での再生設定までを徹底的に解説します。具体的には、Docker Compose を用いた環境構築、Raspberry Pi 5 や Synology DS923+ といった代表的なハードウェアでの導入方法、Last.fm や Listenbrainz によるプレイ履歴の連携、そして最も重要な外部接続における Tailscale の活用までを網羅します。

特に、音楽ファイルのトランスコード（変換）設定や、クライアントアプリごとの特徴比較については、具体的な数値スペックや製品名を挙げて詳細に分析を行います。例えば、iOS 向けの play:Sub と Android 向けの Symfonium Pro では、UI のデザイン性だけでなく、バックグラウンド再生機能の有無やオフラインキャッシュの容量制限など、実際の利用シーンで決定的な違いが生まれます。また、セキュリティ面においては、ポートフォワーディングを使わずに外部から安全にアクセスするための Tailscale の設定手順を、具体的な IP アドレスやトークン発行画面の動きまで言及しながら解説します。これにより、ネットワーク知識が少なくても、自宅サーバーの音楽ライブラリをスマホで聴き放題にするための完璧なガイドラインを提供することを目指します。

Navidrome の概要と 2026 年時点での位置づけ

Navidrome は、Go 言語を用いて開発された高性能かつ軽量な Web ベースのミュージックサーバーです。もともとは Subsonic サーバーとして開発され、多くのクライアントアプリがその API に依存しているため、Subsonic クライアントとしての機能に特化しています。2026 年現在では、バージョン 0.54 が安定版として広く利用されており、以前よりも大幅に改善されたキャッシュ機構や、AI を用いたプレイリスト生成の提案機能が標準装備されるなど、ユーザー体験が向上しています。このソフトウェアの最大の特徴は、サーバー側で重い処理を行うのではなく、クライアント側の処理能力を最大限活用する設計思想にあります。例えば、音楽ファイルのストリーミング処理において、サーバーが常にファイル変換を行うのではなく、クライアントが対応していないコーデックの場合のみトランスコードを行い、その他はパススルーで転送することで、サーバーの CPU 負荷を最小化しています。

2025 年以前は、Plex Media Server や Jellyfin など汎用的なメディアサーバーでも音楽再生が可能でしたが、これらは動画処理にリソースが集中しやすく、音楽専門の機能である「シャッフル再生」「ループ設定」「プレイリスト管理」において Navidrome のような細やかな制御を欠く傾向がありました。また、NAS 純正のファイルサーバー機能（Synology Media Station など）も音楽再生には対応していますが、ユーザーインターフェースが古かったり、外部からの接続設定が複雑であったりする課題がありましたが、Navidrome は Docker コンテナとして動作するため、これらの OS に依存せず、軽量な Linux ディストリビューション上であればどこでも稼働します。2026 年時点では、Raspberry Pi 5 の CPU 性能向上により、ARM アーキテクチャでも快適に動作するよう最適化されており、低消費電力で常時接続可能なサーバーとして最適な選択肢となっています。

さらに、コミュニティの活発さにおいても Navidrome は突出しています。GitHub のオープンソースリポジトリでは毎日のようにバグ修正や機能追加が行われており、特に 2025 年後半から 2026 年にかけては、高解像度オーディオフォーマットである MQA や DSD ファイルへのサポートが強化されました。これにより、ハイレゾ音源を所有するユーザーでも、自宅サーバーで再生時に適切な変換処理が行われ、対応しない古いクライアント端末でも問題なく再生が可能となっています。また、セキュリティ面においても、認証トークンの更新頻度や OAuth2 連携による Google や Discord を介したログイン機能が追加され、パスワード管理の負担を軽減しています。これらの進化により、Navidrome は単なるファイル共有ツールではなく、現代の音楽鑑賞スタイルに適合するインフラ基盤として確立されています。

ハードウェア選定：Raspberry Pi 5 と Synology DS923+ の比較

音楽サーバーを構築する際、最も重要となるのはハードウェアの選定です。ここでは、コストパフォーマンスに優れた ARM ベースの Raspberry Pi 5 と、ビジネスグレードの x86 ベースの Synology DS923+ を比較検証します。Raspberry Pi 5 は、Broadcom BCM2712 プロセッサを搭載し、最大 8GB の LPDDR4X SDRAM を採用しています。このメモリ容量は音楽サーバーとしては十分であり、大量の楽曲メタデータやキャッシュを保持する能力を持っています。特に、2026 年時点では Pi 5 の M.2 SSD アダプターボードを使用することで、高速な NVMe SSD に音楽ライブラリを格納することが可能となり、ディスク読み込み速度が大幅に向上しています。消費電力はアイドル状態で約 3W、負荷時でも 10W を超えることは稀であり、家中のどこでも設置可能な低ノイズ・省電力サーバーを実現します。

対照的に Synology DS923+ は、Intel Celeron N5095 プロセッサ（4 コア/4 スレッド）と最大 8GB のメモリを搭載しています。この x86 アーキテクチャは、x64 ベースのアプリケーション実行において ARM よりも互換性が高く、特に Docker コンテナ内のトランスコード処理（FFmpeg など）を行う際に有利に働きます。DS923+ は 4 ベイ構成であり、HDD を 4 台まで搭載可能で、RAID 1 や RAID 5 による冗長化も容易です。音楽サーバーとしての場合、データの消失リスクを極限まで下げる必要があるため、NAS の耐久性は Navidrome の信頼性を支える重要な要素となります。また、Synology の DSM システムには標準で Docker が搭載されており、GUI からの操作が直感的に行えるため、Linux コマンドに不慣れなユーザーでも初期設定が容易です。

性能とコストのバランスを考慮すると、用途によって最適な選択肢が異なります。もし音楽ファイルを主に MP3 や AAC で保存しており、トランスコードによる変換処理を頻繁に行わない場合は、Raspberry Pi 5 の方が安価で省電力です。しかし、FLAC や WAV といった非圧縮音源を大量に持ち、ネットワーク環境が不安定な場所で低ビットレートに変換してストリーミングする必要がある場合や、Synology のバックアップ機能（Hyper Backup）を活用して外部ドライブへ自動保存したい場合は DS923+ が推奨されます。以下に両者のスペック詳細を表形式で比較します。

また、2026 年時点では、Raspberry Pi 5 のファームウェアが更新され、PoE+ HAT を使用することでネットワーク経由での電源供給が可能になり、配線がさらに整理されました。一方、DS923+ は M.2 NVMe SSD スロットに高速 SSD を搭載し、Docker コンテナへの読み込み速度を向上させる機能（Storage Pool）が強化されています。どちらのハードウェアを選んでも Navidrome は動作しますが、データの安全性と拡張性を重視するなら Synology、初期コストと消費電力を抑えたいなら Raspberry Pi 5 が最適解となります。

Docker & Docker Compose の基礎知識と導入手順

Navidrome を構築する上で必須となるのが Docker と Docker Compose です。Docker は「コンテナ技術」のことで、アプリケーションとその動作に必要な依存関係（ライブラリや設定ファイル）を一つのパッケージに束ねる仕組みです。これにより、「自分の PC で動くが、サーバーでは動かない」といった環境差による不具合を防ぎます。2026 年現在では、Docker Engine のバージョンは安定しており、Raspberry Pi 5 や Synology DSM 9.2 以降でも標準的にサポートされています。まず Docker を導入する前に、OS のアップデートを確認することが重要です。Raspberry Pi OS では sudo apt update && sudo apt upgrade を実行し、Synology DSM では「パッケージセンター」から Docker アプリをインストールします。

Docker Compose は、複数のコンテナ（サービス）を定義・管理するためのツールです。Navidrome 単体であればコマンドラインで起動できますが、データベースやバックアップ機能、あるいは将来的に追加する Subsonic-compatible な API サーバーなどを同時に起動させる際に威力を発揮します。Docker Compose の設定ファイルである docker-compose.yml は YAML 形式で記述され、読みやすい構造化データです。このファイルを編集することで、ポート番号の変更やボリューム（保存領域）の割り当てを容易に行えます。初めて Docker を扱う場合、コマンドラインでの操作は難しく感じるかもしれませんが、Navidrome の公式リポジトリにはテンプレートが用意されており、これを利用すれば数行のコマンドでサーバーを立ち上げることができます。

導入手順としては、まずターミナル（または SSH 接続）にアクセスし、Docker が正しくインストールされているか確認します。docker --version と docker-compose version を実行して、バージョン番号が表示されれば準備完了です。Synology の場合、DSM の「コンテナマネージャー」アプリを立ち上げても操作可能ですが、コマンドラインの方が設定ファイルの編集がスムーズに行えるため、SSH 接続後のターミナル利用をお勧めします。また、2026 年時点の Docker ではセキュリティ強化が進んでおり、rootless モードでの実行も推奨されていますが、Navidrome の場合、権限設定を簡略化するために通常は root ユーザーまたは sudo を使用してコンテナを起動するのが一般的です。ただし、外部公開時のセキュリティのためには、Docker のネットワーク設定（Bridge vs Host）やファイアウォール設定を適切に行う必要があります。

Navidrome サーバーの構築：Compose ファイルの詳細解説

Navidrome のインストールは Docker Compose を使用することで最も効率的かつ再現性が高まります。2026 年 4 月時点での推奨バージョンは v0.54-rc1 または安定版です。まず、サーバー上の任意のディレクトリ（例：/home/pi/navidrome）を作成し、その中に docker-compose.yml ファイルを生成します。このファイルの内容は、Navidrome の動作に必要な設定をすべて含んでいます。以下に主要な構成要素について解説します。

まず、image 行では Navidrome の Docker イメージを指定します。公式の lscr.io/linuxserver/navidrome:latest を使用するのが最も安定しています。container_name は管理しやすいように任意の名前（例：navidrome）を設定し、restart: unless-stopped とすることで、サーバー再起動時に自動的にコンテナが起動するよう設定します。これは、停電やリセット後にサーバーを再構築する必要がないようにするための重要な設定です。

次に、ボリュームマウント（Volume Mapping）の設定が最も重要です。音楽ファイルが保存されているフォルダと、Navidrome のデータを保存するフォルダをホスト側からコンテナ内に紐付けます。例えば、Synology DS923+ 上で /volume1/music に音楽を保存している場合、コンテナ内では /music ディレクトリとしてマウントします。これにより、コンテナが破損しても実際の音楽ファイルは守られます。また、設定データも別フォルダに保持することで、アップグレード時の不整合を防ぎます。

最終的に、ポート公開の設定を行います。Navidrome のデフォルトポートは 45332 です。外部からアクセスする際に、ローカルネットワーク外でもこのポートを開放する必要がありますが、セキュリティリスクがあるため、Tailscale を使用して仮想 LAN で接続することをお勧めします。もし直接公開する場合、ports: - "45332:45332" と記述しますが、 firewall 設定で特定の IP アドレスからのアクセスのみ許可するなどの対策が必要です。

このように、環境変数を用いて Navidrome の挙動を制御します。2026 年時点では、ユーザーインターフェースの設定項目も増えましたが、Docker 側で定義することで、GUI から設定がリセットされるリスクを回避できます。特に TZ（タイムゾーン）は音楽ファイルの作成日時や再生履歴の記録に関わるため、現地の時間と一致させておくことが重要です。

ライブラリスキャンとメタデータ管理

サーバー構築後、最も重要かつ手間がかかるのが音楽ライブラリの整理です。Navidrome は自動スキャン機能を持っていますが、その精度はファイル内のメタデータ（ID3 タグや Vorbis コメント）に依存します。2026 年現在では、音楽プレイヤーが扱うメタデータ標準として ID3v2.4 が主流ですが、一部の楽曲でエラーが発生することがあります。例えば、曲名に特殊文字が含まれる場合や、アーティスト名が日本語と英語が混在している場合、Navidrome の検索アルゴリズムが対応できないケースがあります。これを解決するためには、ファイル名の命名規則を統一し、メタデータ編集ツールを使用して整理する必要があります。

推奨されるメタデータ管理ツールの一つは MusicBrainz Picard です。このツールを使用すると、楽曲の音声パターンを検索して、正確なアーティスト名やアルバム情報を取得し、自動的にタグ付けを行ってくれます。Navidrome 上でライブラリスキャンを実行する際、/music フォルダ内のすべてのサブディレクトリを再帰的にスキャンしますが、フォルダ構造が複雑すぎると読み込みが遅くなります。そのため、アーティスト名やアルバム名をトップレベルのフォルダに整理し、曲ファイルをその下に配置する「1 アルバム = 1 フォルダ」構造が推奨されます。

Navidrome の管理画面からライブラリを更新するには、「設定」>「一般」>「スキャン」ボタンを押すことで手動トリガーできます。また、自動更新設定では、ファイルの監視周期を設定可能です。例えば、音楽ファイルを頻繁に追加・削除するユーザーは、監視周期を 15 分ごとに設定することも可能ですが、ディスク I/O が常時発生するため、Raspberry Pi 5 のような小型デバイスでは負荷が高まる可能性があります。Synology DS923+ のように SSD キャッシュを使用している場合、この影響は少ないです。

さらに、カバー画像の取得機能も重要です。Navidrome は外部 API を経由してアルバムアートを自動的にダウンロードします。これには MusicBrainz Cover Art などが利用されますが、日本語歌詞カードや限定盤ジャケットなど、インターネット上に存在しない画像も多数あります。そのような場合、サーバー上の /covers フォルダに手動でカバー画像を配置すると、Navidrome が優先的にそれを表示します。ファイル名は cover.jpg または folder.jpg として保存することで認識されます。

Subsonic API クライアントとの連携設定

Navidrome の真価を発揮するのは、Subsonic API をサポートするクライアントアプリと接続した時です。2026 年時点では、iOS、Android、Windows、macOS など主要なプラットフォームで対応アプリが多数存在します。まず、Navidrome の管理画面においてユーザーアカウントを作成します。デフォルトの管理者アカウント（admin）はセキュリティリスクが高いため、通常の利用には新しいユーザーを作成し、権限を制限するのが推奨されます。また、パスワード管理においては、Navidrome 標準の認証に加え、OAuth2 による Google や Discord を介したログイン設定も可能です。

クライアントアプリとの接続には、サーバーの URL とポート、そしてユーザー名とパスワードが必要です。ただし、外部から接続する場合、ローカル IP アドレス（192.168.x.x）は使えないため、静的 DNS レコードや Tailscale の仮想 IP を使用します。また、Subsonic API にはバージョンごとの互換性があり、Navidrome は最新の API Spec に準拠していますが、一部の古いクライアントアプリでは接続に失敗することがあります。その場合は、Navidrome の設定画面で「API Version」を指定することで対応できる場合がありますが、基本的には最新アプリの使用をお勧めします。

各クライアントアプリの設定項目も重要です。例えば、再生品質の選定（ビットレート制限）や、キャッシュ容量の調整など、ユーザーのネットワーク環境に合わせて最適化できます。Wi-Fi 接続時とモバイルデータ接続時で自動的に切り替える機能を持つアプリもあり、通信量を節約しつつ高音質を楽しめます。また、オフライン再生の設定では、ダウンロードした楽曲の保存場所を指定でき、端末のストレージ容量不足を防ぐ管理機能も備わっています。

トランスコード設定とパフォーマンス最適化

音楽ファイルの形式が多様化する中で、トランスコード（変換）機能は必須です。Navidrome は FFmpeg を使用して、サーバー側でリアルタイムにオーディオを変換します。例えば、端末が FLAC ファイルを再生できない場合、サーバー側で MP3 などに圧縮して送信します。この設定は Navidrome の管理画面「設定」>「トランスコード」で行います。2026 年時点では、Raspberry Pi 5 や DS923+ の CPU 性能が向上しているため、128kbps〜256kbps の MP3 トランスコードは非常に高速に処理可能です。

設定項目には「トランスコードの最大スレッド数」や「変換フォーマット」、「ビットレート上限」があります。例えば、モバイルネットワークでの再生を想定し、Bitrate を 96kbps に制限することで通信量を削減できますが、音質とのトレードオフとなります。また、サーバー側の負荷が高くなるため、Raspberry Pi 5 のような ARM デバイスでは、CPU 使用率が 80% を超えないように注意が必要です。DS923+ の場合、N5095 プロセッサが AVX2 インストラクションセットをサポートしているため、x64 ベースのトランスコード処理は非常に効率的です。

パフォーマンス最適化のためには、キャッシュ設定も重要です。Navidrome はメモリキャッシュを使用しており、頻繁に再生される楽曲は高速に読み出されます。ただし、キャッシュ容量を大きくしすぎるとメモリの不足を招くため、サーバーの RAM 容量に応じて調整します。Raspberry Pi 5 の 4GB モデルでは 256MB〜512MB 程度が推奨され、DS923+ では 1GB 以上を設定可能です。また、ディスクキャッシュ（SSD キャッシュ）を使用している場合、頻繁に読み書きされるメタデータファイルのアクセス速度も向上します。

Last.fm と Listenbrainz の連携でプレイリストを分析

音楽サーバーを構築する目的の一つに、自分の聴取履歴を記録し、分析することがあります。Navidrome は Last.fm や Listenbrainz といった scrobbling サービスと連携可能です。Last.fm は長年支持されているサービスであり、ユーザーのプレイ履歴がグローバルなデータベースに蓄積され、他のユーザーとの比較やプレイリストの提案が行われます。一方、Listenbrainz はオープンソースベースでプライバシーに配慮した代替サービスです。2026 年には、この二つの連携機能がさらに強化され、リアルタイムでの統計データ表示が可能となりました。

連携設定は Navidrome の管理画面「設定」>「Last.fm / Listenbrainz」で行います。API キーの取得には各サービスの公式サイトでアカウントを作成し、認証を行う必要があります。設定後、再生された楽曲が自動的にサーバーに送られ、プレイリストや聴取統計が表示されます。特に Last.fm との連携では、「ファンタジーモード」と呼ばれる機能があり、特定のアーティストを長時間聴くと、そのアーティストに関連する他の楽曲やライブイベント情報を表示するなど、インタラクションが強化されています。

プライバシー重視のユーザーには Listenbrainz が推奨されます。これはサーバー側にデータを送信せず、ローカルで完結させることも可能です。また、2026 年時点では、この連携機能を通じて AI プレイリストの生成精度が向上しており、「よく聴く曲」や「時間帯ごとの嗜好」に基づいたプレイリストを自動生成する機能が標準搭載されています。これにより、単なるファイル管理から、音楽ライフスタイルの最適化ツールへと進化しています。

外部ネットワークへの安全なアクセス：Tailscale の導入方法

自宅サーバーに外部からアクセスする場合、ポートフォワーディング（ポート開放）を行うのが一般的ですが、これはセキュリティリスクを伴います。公開されたポートは常に攻撃の対象となりやすいです。その解決策として推奨されるのが Tailscale です。Tailscale は zero-trust ネットワークプロトコルを使用し、VPN 接続なしで安全にデバイス間を通信可能にする技術です。2026 年現在では、無料で個人利用が可能であり、設定も非常にシンプルです。

導入手順は、まずサーバー（Raspberry Pi や DS923+）とクライアント（スマホや PC）の両方に Tailscale のエージェントをインストールします。Linux では curl -fsSL https://tailscale.com/install.sh | sh でインストールできます。その後、Tailscale サイトからログインし、認証トークンを発行してサーバーに登録します。これにより、サーバーには仮想 IP アドレス（例：100.x.x.x）が割り当てられ、外部ネットワークを介してもローカルネットワーク内のように通信可能になります。

クライアント側の設定では、Navidrome の URL をローカル IP ではなく、Tailscale で取得した仮想 IP に変更します。これにより、自宅の外からでも Navidrome にアクセス可能になります。また、Tailscale は自動で NAT Traversal（NAT トラバーサル）処理を行うため、ルーターの設定を変更する必要がありません。セキュリティ面では、Tailscale の認証トークンが期限切れになった場合や、不正アクセスが検知された場合に即座に接続を切断する機能も備わっています。

おすすめ Subsonic クライアント比較と選定ガイド

Navidrome 構築の最終段階は、クライアントアプリの選定です。2026 年時点での主要な Subsonic クライアントを OS 別・価格別に比較します。iOS ユーザーには play:Sub が人気ですが、Android では DSub や Symfonium Pro が上位にランクインしています。それぞれの機能や UI の特徴を理解し、利用環境に合わせて選択することが重要です。

play:Sub は iOS/iPadOS 向けで、デザインが洗練されており、サブスクリプション型アプリとして開発されています。一方、Symfonium Pro は Android で非常に高評価であり、カスタマイズ性が極めて高いです。デスクトップ PC では Feishin が人気ですが、Sonixd も軽量な選択肢として注目されます。各クライアントの具体的な違いを以下にまとめます。

各アプリの選択基準として、まず OS の互換性を確認します。iOS ユーザーは play:Sub が最適ですが、Android では Symfonium Pro が圧倒的な機能を提供しています。また、オフライン再生を重視する場合は、キャッシュ管理機能が充実している Symfonium や Feishin が推奨されます。価格面では、play:Sub はサブスク型で継続費用がかかりますが、Symfonium は買い切り型です。

運用とバックアップ戦略

サーバー構築後は、安定した運用とデータの保全が求められます。Navidrome の設定には定期的なメンテナンスが必要です。例えば、ライブラリスキャンの周期調整や、キャッシュの整理などです。また、2026 年時点では、Docker コンテナの自動アップデート機能を利用することで、セキュリティパッチの適用を自動化することも可能です。ただし、アップデート前のバックアップは必須であり、設定ファイルやデータベースファイルを定期的に外部ストレージへコピーする必要があります。

データ保全のためには、Synology の Hyper Backup を使用して、Navidrome の設定ディレクトリと音楽ライブラリの両方を別媒体にバックアップするのが理想的です。特に、メタデータ（ID3 タグ）の修正履歴を管理することは、サーバーが破損した際の復旧に役立ちます。また、Raspberry Pi 5 を使用する場合、SD カードの劣化リスクがあるため、定期的なディスクチェックや、可能であれば SSD への交換を検討すべきです。

運用中のトラブルシューティングとして、音楽ファイルの再生エラーが発生した場合、まず Navidrome のログを確認します。docker logs navidrome コマンドで詳細なエラーメッセージを取得し、問題の原因を特定できます。また、クライアント側での接続エラーは、Tailscale やネットワーク設定の不具合が疑われるため、ping 命令やtraceroute を使用して経路を確認することが有効です。

よくある質問（FAQ）

Q1: Navidrome の初期ログインパスワードはどうやって変更しますか？ A1. 管理者画面の「設定」>「ユーザー管理」からパスワードを変更できます。ただし、Docker コンテナを再起動しない限りは変更が反映されない場合があるため、必ずコンテナ再起動（docker restart navidrome）を行ってください。

Q2: Raspberry Pi 5 で Navidrome を動かすと熱くなりますが対策は？ A2. Pi 5 は発熱しやすいですが、ファンやヒートシンクを装着することで解決します。また、Navidrome の設定で CPU スレッド数を制限するか、トランスコード機能を使用しない構成にすると負荷が減ります。

Q3: Last.fm との連携ができません。 A3. API キーの取得漏れか、認証エラーが発生しています。Last.fm 公式サイトで「API Key」と「Shared Secret」を再発行し、Navidrome の設定欄に正確に入力してください。また、TZ（タイムゾーン）の設定も確認してください。

Q4: iOS で再生中の音楽が切れてしまいます。 A4. キャッシュ設定を見直してください。play:Sub では「オフライン再生」モードを有効にし、Wi-Fi 接続時のみ高品質で通信する設定に変更すると改善します。また、Tailscale の接続速度も確認してください。

Q5: Synology DS923+ の Docker で Navidrome を起動できません。 A5. コンテナマネージャーの権限設定を確認してください。DSM 9.0 以降では「スーパーユーザー」権限が必要になる場合があります。また、Docker Compose ファイルのパスが間違っている可能性も確認してください。

Q6: FLAC ファイルを再生すると音が割れます。 A6. トランスコード設定を見直してください。SSD キャッシュを使用して読み込み速度を上げると改善します。また、クライアント側で FLAC デコーダーが正しく動作しているか確認してください。

Q7: 外部接続時に「403 Forbidden」エラーが出ます。 A7. Tailscale の認証トークンが期限切れになっている可能性があります。Tailscale サイトで再発行を行い、Navidrome 設定の URL を更新してください。また、ファイアウォール設定の確認も必要です。

Q8: Navidrome のアップデート方法を知りたいです。 A8. docker pull lscr.io/linuxserver/navidrome で最新イメージをダウンロードし、コンテナを再起動します。設定ファイルは外部ボリュームに保存されているため、アップデート後もデータは保持されます。

まとめ

本記事では、2026 年 4 月時点の状況に基づき、Navidrome を活用した音楽サーバー構築の全貌について解説しました。

• ハードウェア選定: Raspberry Pi 5 の低消費電力と Synology DS923+ のデータ保護機能の特性を理解し、用途に合わせて選択することが重要である。
• Docker 導入: Docker Compose を使用することで再現性の高い環境構築が可能であり、設定ファイルの管理が運用コストを削減する。
• メタデータ管理: ID3 タグや MusicBrainz Picard の活用により、ライブラリの整理と検索精度を向上させることができる。
• 外部接続: Tailscale を使用することで、ポート開放リスクを回避しつつ安全に外部からアクセス可能にする。
• クライアント選定: iOS では play:Sub、Android では Symfonium Pro が特におすすめであり、それぞれの OS に最適なアプリを使用すべきである。

Navidrome を構築することは、単なる音楽再生の手段を超え、デジタルデータの所有権を取り戻す行為です。2026 年において、サブスクサービスの利用料増やデータ削除リスクが存在する中で、自前でサーバーを管理することはユーザーにとって大きな安心感をもたらします。今回紹介した構成は、専門知識が少なくても導入可能なレベルですが、設定の自由度が高いため、徐々に機能を拡張していくことが可能です。ぜひ、本記事を参考に、あなただけの音楽環境を構築してください。