Audiobookshelfを音声ライブラリの実態に合わせて運用する
自己ホスト型のオーディオブックおよびポッドキャスト サーバー。 Kindle) ポッドキャストやオーディオブックの RSS フィードを開く 探している機能はありますか?
ひと目でわかる
- これは何？
- セルフホスト型のオーディオブックとポッドキャスト管理を、ファイル配置、同期、公開経路の条件から読む。
- 誰に向いている？
- 向いているのは、音声ファイルの命名とディレクトリを自分で整え、複数ユーザーの再生位置を管理したい人です。既存の配置を変えられない環境や、iOSベータの即時利用を前提にする場合は適しません。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。最後のコミットは 4 日前です。
- 何の言語で書かれている？
- 主に JavaScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
音声と電子書籍を一つの棚で扱う範囲
READMEはAudiobookshelfをセルフホスト型のオーディオブックとポッドキャストのサーバーと定義しています。音声形式をオンザフライで配信し、ポッドキャストの検索とエピソードの自動ダウンロード、オーディオブックやポッドキャストのオープンRSSを挙げています。電子書籍はEPUB、PDF、CBR、CBZの基本対応と、Kindleなどの端末への送信が記載されています。これは機能の対象範囲であり、すべての形式での再生結果を保証する記述ではありません。
本を音声ファイルの集合として置く製品では、画面より先に保管規則が実用性を左右します。READMEもディレクトリ構造とフォルダー名が重要だと明記し、対応する構造、命名、音声メタデータをライブラリ文書へ案内しています。導入時は一冊分の実データで、著者や章が期待通りにまとまるかを確認するのが妥当です。
ユーザー別の進捗と端末連携
ユーザーごとに再生進捗を保持し、端末間で同期できる点が中核です。カスタム権限を伴うマルチユーザーにも対応するとREADMEは説明しています。ChromecastはWebアプリとAndroidアプリでサポートされ、AndroidとiOSのアプリはオープンソースでベータ版とされています。ポッドキャストを追加して自動ダウンロードする場合も、誰の購読状態と進捗を保存するのかを先に分けて設計する必要があります。
モバイル運用は安定版のWeb機能と同列に扱わない方がよいでしょう。iOSベータはAppleのテスター上限に達しているとREADMEにあり、更新はDiscordで告知されます。Chromecastや端末送信を採用条件にするなら、利用するアカウント権限、ネットワーク経路、対象端末を固定して個別に再生を試します。
取り込み、章編集、バックアップ
メディア更新は再スキャンを手動で繰り返す方式ではなく、自動検出を特徴として掲げています。フォルダーの一括ドラッグアンドドロップによるアップロード、複数ソースからのメタデータとカバー取得、章エディターとAudnexus APIを使う章検索もREADMEにあります。複数音声を一つのM4Bへ結合し、音声ファイルへメタデータとカバー画像を埋め込む機能も対象です。
メタデータは再取得や編集で変わり得るため、元ファイルと生成物を分けて扱う運用が必要です。READMEにはメタデータのバックアップと自動化された毎日のバックアップも記載されていますが、復元時間や保存先、世代数までは示されていません。最初の確認ではバックアップが生成される場所と、進捗を含めた復元単位を実際に確認してください。
WebSocketを含む公開経路
リバースプロキシ配下で使う場合、READMEはWebSocket接続が必要だと注意しています。サブフォルダーでの公開は追加変更なしに対応しますが、パスは変更できず `/audiobookshelf` でなければならないとされています。通常のHTTP転送だけを設定したプロキシでは、一覧表示ができても再生や同期の一部が失敗する可能性があります。
検証ではまずローカルのWebクライアントで再生し、次にプロキシ経由で同じ章を再生して再接続後の進捗を比較します。TLS終端、認証、WebSocket転送の設定はREADMEのリバースプロキシ文書を参照し、サブパスを採る場合はURLが固定条件に合うかを確認します。性能上限や同時再生数は素材に記載がないため、そこから推測しません。
開発環境はNode.js 20とFFmpegが軸
ソースから動かす場合、READMEはNode.js 20とFFmpegを必要条件として挙げ、ルートに `dev.js` を作る手順を示しています。例は `.devcontainer/dev.js` にあるとされます。依存関係はルートで `npm ci`、続いて `client` で `npm ci` と `npm run generate` を実行します。その後ルートで `npm run dev` を起動し、クライアント変更時は `(cd client; npm run generate)` を再実行してサーバーを再起動します。
Dev ContainerではDocker DesktopとVS Codeを使う入口が用意されています。開発用クライアントの既定ポートは3333ですが、`dev.js` で変更できるとREADMEにあります。既存のVueフロントエンド向けプルリクエストはレビューやマージの対象外で、Reactへの書き換えと移行中という注意もあります。UI改修を主目的にする場合は、この方針とブランチ状態を先に確認します。
ライセンスと採用前の境界
メタデータ上のライセンスはGPL-3.0です。再配布や改変を含む扱いは、リポジトリのLICENSE本文と自社の配布形態を照合して決める必要があります。READMEの機能一覧は豊富ですが、対応形式ごとの互換表、性能基準、バックアップの復元保証は示していません。星数やIssue数は利用規模の手掛かりにはなっても、運用可否の証明にはなりません。
採用前の具体的な確認対象は、命名規則に沿った一冊、Podcastの自動取得、ユーザー二つの進捗、プロキシ経由のWebSocket、バックアップからの復元です。これらを対象バージョンで記録し、iOSベータを必須にしない前提を置けるなら、個人または家庭内の音声棚として検討しやすくなります。
追加確認として、READMEが案内する公式ドキュメントのライブラリ例とリバースプロキシ例を、同じ版のサーバーで照合します。音声の再生だけでなく、章位置を変えて別端末から再開できるか、Podcastの自動取得を止めたとき既存ファイルが残るかも見ます。自分の保管規則に合わない場合は、スキャン結果を手作業で直す時間まで含めて採用可否を決めます。
編集部の結論
向いているのは、音声ファイルの命名とディレクトリを自分で整え、複数ユーザーの再生位置を管理したい人です。既存の配置を変えられない環境や、iOSベータの即時利用を前提にする場合は適しません。最初に小さなライブラリを作り、WebSocket越しの再生、メタデータ取得、ユーザー別の進捗同期を確認してください。
コミュニティノート