セルフホスト型音楽配信サーバ＆プレイヤーKanadeを作った

5月 16, 2026

はじめに#

「前編の続きがないな, おかしいな…」

それは… 本当に… そう

2022年にRaspberry PiとMediaPlayerを使ってOpenHomeレンダラを作る (前編)という記事を書いて, 最後にしれっと「後編に続く」と書き残したのですが, 続きませんでした.

4年も.

この記事は, 2022年の記事で予告していた「MediaPlayerで続きをやる後編」ではありません.

その代わり, 使っているうちに色々と気になり始めて, 気付いたら自分で音楽サーバを作っていたという話です.

つまり今回は, 「前編の続き」ではあるのですが, 内容としてはかなり斜め上です.

前編では, OpenHomeレンダラとして使えそうなJava製のMediaPlayerを見つけて,

これで行けそうだし, 後編で環境構築を書こう

みたいな顔をして終わっていました.

しかし現実には,

• しばらくMediaPlayerを使った
• 便利ではあった
• でも不満がじわじわ溜まった
• どうせなら自分の欲しい構成に全部合わせたい
• じゃあ作るか

という流れで, セルフホスト型の音楽配信サーバ兼プレイヤーであるKanadeを作ることになりました¹.

この記事では, 前編のその後として

• MediaPlayerを使ってどう感じたか
• なぜ一から作る方向に転んだのか
• Kanadeがどういうものなのか
• どんな設計にして, 何を気に入っているのか
• 実際どうデプロイして, どう使っているのか

を, だいぶ長めに書いていきます. マジで長いです.

今回作ったもの:

GitHub - petitstrawberry/kanade: A self-hosted music player server written in Rust.

A self-hosted music player server written in Rust. - petitstrawberry/kanade

GitHub - petitstrawberry/KanadeApp: Native iOS & macOS client for kanade — a self-hosted, multi-room music system.

Native iOS & macOS client for kanade — a self-hosted, multi-room music system. - petitstrawberry/KanadeApp

しばらく前編の続きと動機の話が続くので, Kanade自体の説明が読みたい方はこちらまで飛ばしてください.

前編のあと, どうなったのか#

まずは2022年の記事の後日談からです.

前編を書いた時点では, MediaPlayerはかなり良さそうに見えていました.

実際, OpenHomeレンダラとしてちゃんと使えるというだけでも当時の自分にはかなり魅力的でした.

moOdeやVolumioのような「全部入りの音楽再生ディストリビューション」は便利なのですが, 前編でも書いたように, 自分が欲しかったのはあくまで

• OpenHomeコントローラから扱えること
• 余計なレイヤーで隠蔽されすぎていないこと
• 必要なら自分でいじれること

でした.

その意味で, MediaPlayerはかなり筋が良かったです.

Java製で, OpenHomeを話せて, バックエンドにMPDを使えて, プラグインもある.

当時の私は「これだ」と思いました.

思ったのですが, しばらく使っていると, 当然ながら色々欲が出てきます.

MediaPlayerがダメだったわけではない#

GitHub - PeteManchester/MediaPlayer

Contribute to PeteManchester/MediaPlayer development by creating an account on GitHub.

ここで大事なのは, MediaPlayerがダメだったという話ではないということです.

むしろしばらく動いていましたし, 前編で苦しんでいた「音楽再生ディストリビューションの都合に振り回される感じ」からはかなり解放されました.

ただ, 使えば使うほど,「自分が本当に欲しいのは何なのか」がより具体的になってきます.

統合されたシステムが欲しい#

特に大きかったのは, 再生の責務がいくつかのソフトにまたがる構成に対する, うっすらしたもやもやです.

前編の頃からずっと, 私は

• ライブラリ管理
• コントロール
• レンダラ
• 配信
• 付加機能

が分かれた構成そのものは嫌いではありませんでした.

むしろUnix哲学っぽくて好きです.

でも, 好きと毎日気持ちよく使えるは別でした.

バラバラだった自宅の音楽再生環境#

具体的に言うと, Kanadeを作る前の私の音楽再生環境はこんな感じでした.

• 自宅サーバでMinimServerをDLNAサーバとして動かす
• リビングのRaspberry PiはDLNAレンダラとして, Lumin Appなどのコントローラから操作
• 一方でスマホでは, foobar2000 mobileでDLNAサーバから無理やり引っ張って再生

要するに, 家の中と外で別の仕組みを使っていました.

リビングで聴く時はLumin Appを開いて, DLNA経由でRaspberry Piに投げる.

外出中はfoobar2000 mobileを開いて, DLNAサーバから直接引っ張ってくる.

ライブラリは同じMinimServerにあるのですが, アクセス方法もUIもプレイリストもキューも全部別.

しかもfoobar2000 mobileのDLNAクライアントとしての使い勝手は, 正直「なんとか聴ける」レベルでした. アーティスト一覧が出るまでが遅いし, キューの管理も微妙だし, そもそもDLNA経由だと外出先から自宅にアクセスするのにVPNを張るなり工夫が必要です.

Roon ARCという商用サービスを知っている方はいるかもしれません. Roonは自宅ライブラリの管理とリモート再生を統合したシステムで, Roon ARCというアプリを使えば外出先からも自宅ライブラリにアクセスして, スマホでそのまま聴けます. 統一されたライブラリ, 統一されたUI, 家でも外でも同じ体験.

これが欲しかった…

ただしRoonはサブスクリプションで年額$150くらいかかるし, 自分のサーバで自分のライブラリを自分の都合で扱いたいという趣旨からは外れます.

結局のところ, 商用のSpotifyやApple Musicのような「統合されたシステム」が, いかに日常的な使い勝手を高めているかを痛感することになりました.

では, DLNAサーバを主軸にした構成を捨てて, メディアサーバを主軸にした構成に移行しようという考えになります.

なぜ既存のセルフホスト型音楽サーバではダメだったのか#

「いや, 世の中にセルフホスト型音楽サーバなんていくらでもあるんだから，それ使えばいいだろ」と思う方がいるかもしれません.

Jellyfin, Navidrome, Subsonic, Airsonic, Gonic, etc…

セルフホスト界隈は, 音楽系サーバの種類が豊富です. 豊富なんですが, 実際に使ってみると, 私の用途とはだいぶズレていました.

どれも「音楽をブラウザやアプリから聴く」という目的には十分なのですが,

• タグの扱いが雑
  • 日本語のタグが怪しい, DSDをサポートしないなど
• そもそも重い
• オーディオ志向の機能（lossless配信, DSD対応）が薄い
• 「音楽ライブラリを自分の好みに合わせて扱う」という思想が弱い

あたりが, 私の用途とは合いませんでした.

要するに,

「日本語のタグをちゃんと読んで, losslessで配信して, 軽くて, 自分の好きにできるやつ」

が欲しかったのです.

そんな都合の良いものがある訳がなく, じゃあ作るか, という流れです.

じゃあ何が欲しかったのか#

MediaPlayerやMPDまわりでしばらく遊び, さらに既存の音楽サーバも一通り試した結果, 欲しいものはだいぶ明確になりました.

大雑把に言うと, 欲しかったのはこんなシステムです.

1. 自分の音楽ライブラリを自分で持てる
2. サーバが権威を持ち, クライアントは薄くしたい
3. スマホで, 商用サービスと同じ体験で聴けること（一番大事）
4. 再生先を複数マシンに分散したい
5. でも操作感は一つのシステムとして揃えたい
6. iPhoneやMacでも再生したい (外出時も)
7. Webからも雑に使いたい
8. 付加機能はあとから足したい

こうして書くと, まあまあ面倒くさいですね.

というか, 既存ソフトを組み合わせて作れなくはないが, 綺麗にはまとまらない類の要求です.

しかし, どうしてもこの構成が欲しかったので, じゃあ自分で作るかということになりました.

Kanadeとは何か#

Kanadeは, 自分の音楽ライブラリをスキャンして管理し, 複数のクライアントから操作でき, 複数の再生ノードへ配信できる, セルフホスト型音楽配信サーバ＆プレイヤーです.

GitHub - petitstrawberry/kanade: A self-hosted music player server written in Rust.

A self-hosted music player server written in Rust. - petitstrawberry/kanade

名前は日本語で「奏」です. (あの, 某吹奏楽アニメのキャラから取りました…)

自分のライブラリを, 自分のサーバで, 自分のプレイヤーに送る.

分かりやすくて良い.

やっていることをざっくり言うと,

• サーバが音楽ライブラリをスキャンする
• クライアントはサーバに繋いで一覧や検索結果を見る
• 再生先となるノードは別プロセスとしてサーバに接続する
• 各ノードは独立したキューを持つ
• 必要に応じてローカル再生もできる

という構成です.

全体のアーキテクチャ#

まずは雑に全体像を出します.

  Web / TUI / iOS / macOS
             │
             │ WebSocket / HTTP
             ▼
      Kanade Server (:8080)
   ┌───────────────────────┐
   │ kanade-core           │
   │ kanade-db (SQLite)    │
   │ kanade-scanner        │
   │ axum WS + media       │
   └───────────────────────┘
        │             │
        │             └── HTTP media / HLS
        │
        ├── WebSocket → Node A (MPDなど)
        ├── WebSocket → Node B (別マシン)
        └── WebSocket → Node C (別マシン)

ポイントは, サーバが単一の権威を持つことと, クライアントやノードはそこにぶら下がることです.

この構成にしたことで, 「複数クライアントから見た状態がズレる」問題をかなり避けやすくなりました.

技術スタック#

サーバ側はRustです.

主に使っているものは以下の通り.

• Rust
• tokio
• axum
• SQLite
• lofty

クライアント側は用途ごとに分かれています.

• Web: Svelte 5 + hls.js
• TUI: ratatui
• iOS / macOS: Swift + AVFoundation

Kanadeの主な機能・特徴#

機能を列挙するとだいたい以下の通りです.

• ライブラリ管理
• ストリーミング再生
• 独立した再生ノード
• ローカル再生

ライブラリ管理#

• ローカルの音楽フォルダをスキャン
• メタデータを保存して全文検索対応
• アルバム, アーティスト, ジャンル, 曲単位でブラウズ
• プレイリスト管理
  • 手動プレイリスト
  • スマートプレイリスト

対応フォーマットはかなり広めで,

• FLAC
• MP3
• M4A
• Ogg Vorbis / Opus
• WAV
• AIFF
• WMA
• APE
• DSD (DSF)

などを扱えます.

DSDまで視野に入っているのは, オーディオ系の自宅ライブラリとしては割と大事です.

「そのへんの一般的なWeb音楽アプリの都合」ではなく, 自分都合で自由に追加したり修正したりできるのが大きいです.

スマートプレイリスト#

スマートプレイリストは個人的にかなり好きな機能です.

単なるプレイリストではなく, ルールベースで曲を集められます.

例えば,

• ジャンルがClassical
• かつ composer に特定文字列を含む
• あるいは album artist に特定文字列を含む

みたいな条件を, AND / ORで組み合わせられます.

いわゆる「賢いプレイリスト」です.

賢いのはプレイリストであって, 作っている側はそこまで賢くありません.

この機能は, Audirvanaに同様のものがあって, 使っていた時に非常に便利だったのです. ライブラリが増えてくると, 「この条件で絞り込んだプレイリスト」が日常の選曲でかなり効く. ジャンルで絞ったり, 最近追加した曲だけ拾ったり, 特定の作曲家だけ集めたり.

ところが, これをDLNA/UPnPの世界でやろうとすると, まずできません.

DLNAサーバは, せいぜいディレクトリ構造を配信しているだけです. 設定を作り込めば可能かもしれませんが，DLNAクライアントアプリから中身を編集したりはできません．普通の商用サービスならアプリで全部完結するので, これは認められないです.

Audirvanaであれだけ便利だったスマートプレイリストを, モバイルでも, 据え置きの再生機でも, 同じように使いたい. これもKanadeを作る動機の一つでした.

ストリーミング再生#

KanadeはHLS経由で音声を配信します.

Webクライアントではhls.jsを使ってそのまま再生できますし, ネイティブクライアントでもHLSプレイリストをフェッチして再生する形です.

ストリーミングとローカル再生が同じ配信経路に乗っているので, クライアント側の実装が統一されています.

独立した再生ノード#

Kanadeの最大の特徴が, ノードごとに再生状態が独立していることです.

各ノードはそれぞれ

• キュー
• 音量
• シャッフル
• リピート
• 現在位置

を個別に持ちます.

つまり,

• リビングではアルバムを通しで流す
• 書斎では別のキューを作る
• 手元のiPhoneではローカル再生する

みたいなことを, 一つのサーバ配下で扱えます.

この「部屋ごと, 端末ごとに独立しているが, ライブラリは一つ」という感じが, 私が欲しかった形そのものでした.

マルチルーム#

ノードは別マシンに置けます.

つまり, Raspberry Piでも, Linuxマシンでも, 何なら別のMacでも, サーバに繋いで再生先として扱えます.

結果として,

• サーバはNASの近くに置く
• 再生ノードは各部屋のマシンに置く
• コントロールはWeb/TUI/iPhone/Macからやる

という構成が素直に組めます.

前編ではRaspberry Pi上のレンダラ構築が主題でしたが, Kanadeではその発想をもう少し一般化して, 「音が出る場所」をノードとして抽象化しました.

ローカル再生#

サーバから別ノードへ投げるだけではなく, 手元の端末自体で再生することもできます.

具体的には,

• iOS / macOSではAVFoundation
• Webではhls.js

を使ってローカル再生できます.

Apple系のネイティブアプリは別リポジトリです².

GitHub - petitstrawberry/KanadeApp: Native iOS & macOS client for kanade — a self-hosted, multi-room music system.

Native iOS & macOS client for kanade — a self-hosted, multi-room music system. - petitstrawberry/KanadeApp

これがあると, 据え置きの再生ノードに投げる使い方だけでなく,

「今日はヘッドホンで聴きたいから, この端末自身で鳴らす」

が自然にできます.

ここは「サーバなのにプレイヤーでもある」というタイトルの, まさに後半部分です.

詳細設計と実装の話#

ここからは, 何ができるかではなく, どう作って, なぜそうしたのかという細かい話です. 長いのでスキップしてもらっても全然大丈夫です.

運用と使い心地#

ここからは運用の話です.

セルフホスト系の話は, どうしても設計の話だけで終わるとふわっとするので, 実際のデプロイ感も書いておきます.

デプロイ#

KanadeはDocker Composeでも, Nix flakeでも扱えます.

私はこの手のものは, 開発中はNixが便利で, 常用運用はComposeが楽という顔をしがちです.

だいたい皆そうかもしれません.

Docker Composeでの基本構成#

サーバ側はだいたいこんな感じです.

services:
  kanade:
    image: ghcr.io/petitstrawberry/kanade:main
    ports:
      - "8080:8080"
    environment:
      MUSIC_DIR: /music
      DB_PATH: /data/kanade.db
      HLS_CACHE_DIR: /data/hls-cache
      BIND_ADDR: "0.0.0.0:8080"
      PUBLIC_HOST: "kanade.example.com"
      SCAN_INTERVAL_SECS: "300"
    volumes:
      - ./music:/music:ro
      - kanade-data:/data

大事な環境変数はこのあたりです.

• MUSIC_DIR
  • 音楽ライブラリのルート
• DB_PATH
  • データベース配置先
• HLS_CACHE_DIR
  • HLS remuxキャッシュ置き場
• BIND_ADDR
  • WebSocket + HTTPメディア面の待受
• PUBLIC_HOST
  • クライアント向けに見せる公開ホスト名
• SCAN_INTERVAL_SECS
  • 定期スキャン間隔

PUBLIC_HOST は, リバースプロキシ越しに使う時に特に大事です.

サーバ内部の見え方と, クライアントが実際にアクセスするURLがズレると, メディアURLや発見まわりが綺麗に繋がりません.

この手の変数は地味ですが, ちゃんとあると運用がすごく楽になります.

NASとの連携#

上の例では ./music:/music:ro とローカルディレクトリをマウントしていますが, 実際には音楽ファイルはNAS上にあることが多いと思います.

Kanadeでは, SMB/CIFS用のCompose overlayを用意しています.

# docker-compose.smb.yml
# Usage: docker compose -f docker-compose.yml -f docker-compose.smb.yml up -d
services:
  kanade:
    volumes:
      - music:/music:ro
  mpd:
    volumes:
      - music:/music:ro

volumes:
  music:
    driver_opts:
      type: cifs
      o: "username=${SMB_USER},password=${SMB_PASS},ro,vers=3.0,iocharset=utf8"
      device: "//${SMB_HOST}/${SMB_SHARE}"

.env にNASの接続情報を書いておけば, あとはoverlayを重ねるだけでSMBボリュームが /music にマウントされます.

docker compose -f docker-compose.yml -f docker-compose.smb.yml up -d

NAS側でファイルを追加・整理したものが, Kanadeの定期スキャンで自動的に反映されます.

別マシンにノードを置く#

Kanadeの面白いところは, ノードを別マシンに出せることです.

例えばRaspberry Piや小型PC側に kanade-node だけ置いて, そこからローカルMPDを叩く構成にできます.

Standalone nodeのComposeはだいたいこんな感じです.

services:
  node:
    image: ghcr.io/petitstrawberry/kanade:main
    command: kanade-node
    environment:
      NODE_NAME: "living-room"
      SERVER_ADDR: "kanade.example.com:8080"
      MPD_HOST: "127.0.0.1"
      MPD_PORT: "6600"

必要な変数は少なめです.

• NODE_NAME
  • 表示用のノード名
• SERVER_ADDR
  • Kanadeサーバの接続先
• MPD_HOST
  • ローカルMPDの接続先
• MPD_PORT
  • ローカルMPDのポート

これだけで, サーバとノードを別マシンに分けられます.

リバースプロキシ#

外からHTTPSで気持ちよく使いたいなら, リバースプロキシを前に置くのが素直です.

nginxやCaddyで,

• TLS終端
• WebSocketのupgrade
• 静的ファイルとAPIの振り分け

をやれば, iPhoneでもMacでもブラウザでもかなり素直に扱えます.

クライアントの使い分け#

Kanadeはクライアントが複数あります.

これも一見やりすぎ感がありますが, 実際には使い分けると結構便利です.

Web#

まず一番気軽なのはWebです.

ブラウザがあればすぐ使えますし, 家の中のどの端末からでもアクセスしやすい.

しかもHLS経由でそのままローカル再生できるので, 「ちょっと今この端末で聴きたい」という時に強いです.

雑に使えることの価値は高い.

TUI#

TUIは完全に趣味枠に見えて, 実際かなり趣味枠です.

でも, ターミナル常駐民にとっては妙にしっくりきます.

SSH越しに雑に触れるのも良いですし, 作業中に別ウィンドウで状態を見るのにも向いています. 楽しいというのは大事です.

iOS / macOSネイティブ#

日常使用という意味では, やはりネイティブクライアントがかなり便利です. ほとんどをこのクライアントの開発に時間を割いています.

単純にコントローラとして使うことができるだけでなく, その端末でローカル再生もできるのが大きいです.

GitHub - petitstrawberry/KanadeApp: Native iOS & macOS client for kanade — a self-hosted, multi-room music system.

Native iOS & macOS client for kanade — a self-hosted, multi-room music system. - petitstrawberry/KanadeApp

「今手元にあるものをそのまま再生先にできる」というのは, 思っている以上に自然です.

特にMacでは, 据え置き再生機に投げるか, このMacで鳴らすかをその場で選べるのが快適です.

実際に使ってみてどうか#

ここは一番大事なところです.

自作システムは, 作っている時点では何でも最高に見えます.

しかし, 本当に重要なのは毎日雑に使っても嫌にならないかです.

Kanadeについて言うと, 今のところかなり良いです.

良いところ#

まず, 自分の欲しかった形にかなり近いです.

特に以下の点は満足度が高いです.

• ライブラリと再生が一つのシステムとして繋がっている
• サーバが権威なので, クライアントを跨いでも状態が分かりやすい
• ノード単位で再生文脈を持てる
• ローカル再生と据え置き再生機への出力を同列に扱える
• 電車の中でもスマホでSpotifyと同じ感覚で聴ける

前編を書いていた頃の自分が見たら, たぶん「なんでそんな大事にしたんだ」と言うと思います.

私もそう思います.

それでも自作は自作#

もちろん, 自作システムなので万能ではありません.

既製品や成熟したOSSのように, あらゆる環境で雑に動くというものではないですし, 細かい詰めはまだ色々あります.

ただ, 少なくとも自分が普段使う文脈では,

不満の出どころを自分で直せる

というのが本当に大きいです.

前編の頃は, あるレイヤーの都合が気になっても, そこから先に進むのが重かった.

今はその大半が自分の管理下にあります.

これは自由であると同時に, 普通に保守責任も自分へ飛んでくるということですが, まあ趣味なので大丈夫です.

たぶん.

そのうち書きたいこと#

Kanadeまわりは, この記事だけでは書ききれない話がまだ色々あります.

例えば,

• node protocolの詳細
• KanadeApp側の実装
• HLS remuxまわりの実装詳細

などは, それぞれ単独記事にできるくらいにはあります.

ただし, ここで「続きは後編で」と言うと嫌な予感しかしません.

学習しました. ので, 今回はあまり大きな予告はしません.

書けたら書きます.

おわりに#

という訳で, 4年間放置された前編の続きとして,

今回はMediaPlayerの後編ではなく, 自作のセルフホスト型音楽配信サーバ＆プレイヤーKanadeを作ったという話を書きました.

前編を書いた時点では, まさかここまで話が大きくなるとは思っていませんでした.

興味があればリポジトリも見てみてください.