常時稼働するJellyfinサーバーだからといって、すべてのCPUコアを常にフル稼働させたり、すべてのメディアドライブを一日中シークさせたりする必要はありません。継続的な発熱やディスク活動の大部分は、ソフトウェアトランスコード、ライブラリスキャン、生成画像、プラグイン、データベースやメタデータへのアクセス、ダウンロード、バックアップ、または周辺サービスなど、少数の処理経路から発生します。
最も安全な最適化方法は、どの処理経路がシステムをアクティブに保っているかを特定し、不要な重複を取り除くことです。積極的なディスクのスピンダウンやCPUスロットリングは後回しにしましょう。ドライブを頻繁に起動したり、リアルタイムトランスコード速度を下回ったりするサーバーは、理論上の消費電力が少なくても、日常の使い勝手が悪くなる可能性があるためです。
Jellyfinを最適化する前にアイドル時の消費電力を測定する
Jellyfinを起動したまま、誰もストリーミングしていない状態で、コンセント側の消費電力、CPU温度、ファン速度、ディスク活動を記録します。次に、Direct Playのセッションを1つ、代表的なハードウェアトランスコードを1つ、スケジュールされたスキャンを1つ実行して比較します。
2026年の消費電力測定プロジェクトでは、低消費電力ミニPC、旧型デスクトップ、NASシステム、ソフトウェアトランスコード環境の間に大きな差があることが示されており、短時間のピークよりも常時稼働時のベースラインが重要になる場合があることが分かります。
数値は測定の目安として利用し、普遍的なワット数だとは考えないでください。ドライブ、電源ユニット、ファンカーブ、OS、バックグラウンドサービスによって、結果は大きく変わる可能性があります。
継続的なアプリの処理をメディアHDDから移す
Jellyfinのデータベース、メタデータ、アートワーク、ログ、キャッシュは、小さなランダム読み書きを発生させます。そのため、誰も視聴していないときでもメディアHDDがアクティブな状態になり得ます。可能であれば、この遅延に敏感なデータをSSDに置き、大容量のメディアファイルは容量重視のストレージに残しましょう。
ZimaSpaceによるJellyfinのアプリ状態とメディアストレージのI/Oに関する分析では、この分離によって応答性が向上し、メディアドライブに長いアイドル時間を与えられる理由が説明されています。
トランスコードキャッシュをSSDまたはRAMに置く場合は、想定される一時的なピークに対応できる十分な書き込み耐久性と空き容量がデバイスにある場合に限ってください。
ライブラリを繰り返し起動するタスクのスケジュールを変更する
ライブラリスキャン、チャプター抽出、キーフレームやトリックプレイ用データの生成、字幕検索、プラグインのメンテナンス、データベース処理は、ユーザーが視聴していないときでもライブラリの大部分を走査することがあります。
現在のスケジュールタスクガイドでは、Jellyfinが自動的に実行できる定期的なライブラリ処理やメンテナンスジョブを確認し、メディアストレージを繰り返し起動する高負荷な処理を、計画的なメンテナンス時間帯に移すことが推奨されています。
すべてのスケジュールタスクを無効にする必要はありません。結果を利用していない機能だけを無効にするか、ライブラリの変更頻度よりも同じジョブが頻繁に実行されている場合は、実行頻度を下げてください。
変換が避けられない場合はハードウェアトランスコードでCPUの発熱を抑える
通常、Direct Playのストリームは動画を変換するよりも負荷が低くなります。トランスコードが必要な場合は、対応するメディアエンジンを利用することで、処理の大部分を汎用CPUコアから固定機能ハードウェアへ移し、発熱を大幅に抑えられます。
実際のコーデック、トーンマッピングの経路、字幕処理がアクセラレーションの対象になっているかを確認してください。「ハードウェアアクセラレーション」を全体で有効にしていても、1つのソフトウェアフォールバックによってCPUが高温のままになることがあります。
必要な画質を下回るまでトランスコード品質を下げて、CPU温度を低くしようとしないでください。目標は可能な限り低いセンサー値ではなく、効率的なリアルタイム再生です。
ドライブがアイドル状態を維持できると確認してからディスクスタンバイを使う
ドライブスタンバイは、本当に使用されていないメディアプールの消費電力や動作音を低減できます。ただし、バックグラウンドのメタデータ処理、スキャン、監視、SMARTポーリング、その他のサービスがディスクを繰り返し起動していない場合に限って効果があります。
ドライブスタンバイは、ディスクがアイドル状態を維持できる場合にのみ効果があります。QNAPの現在のトラブルシューティングガイドでは、バックグラウンドサービスやアプリがNASディスクを起動し続ける可能性があり、頻繁なスピンアップとスピンダウンの繰り返しは摩耗を増やすと説明されています。そのため、頻繁にアクセスされるメディアプールは、積極的なスタンバイタイマーには適していません。
スタンバイを有効にした後は、起動頻度を測定してください。数分おきにドライブがスピンアップする場合は、I/Oの原因となっているサービスを特定するか、常時停止と起動を繰り返す状態を避けるためにスタンバイを無効にします。
常時稼働時のベースラインはこの順番で最適化する
- 不要なバックグラウンドサービスと繰り返し実行されるスキャン処理を削除する。
- Jellyfinのアプリデータとキャッシュを大容量メディアHDDから移す。
- Direct Playとハードウェアトランスコードの経路を確認する。
- ワークロードを把握してから、ファンカーブとCPU電力ポリシーを調整する。
- 十分な時間にわたって本当にアイドル状態を維持できるプールにのみ、ドライブスタンバイを有効にする。
常時稼働に最適な構成とは、最も積極的な省電力設定を適用したものではありません。不要な処理がなく、アクティブなデータが適切なストレージ階層を使い、アイドル状態のメディアドライブが自然にアイドル状態を維持できるため、涼しく静かに動作する構成です。
よくある質問
Jellyfinのメディアドライブは常にスピンダウンさせるべきですか?
いいえ。スタンバイは、ドライブが十分な時間アイドル状態を維持できる場合にのみ役立ちます。Jellyfinのスキャン、監視、ダウンロード、その他のサービスが頻繁にドライブを起動する場合、スピンアップの繰り返しによって遅延が増え、期待される省電力効果の大部分が失われる可能性があります。
NAS&サーバー設定
もっと読む

リソースを大量に消費するサービスと共有しているサーバー上で Jellyfin を分離する方法
CPU、メモリ、GPU、ストレージI/O、タスクのタイミングなど、実際に競合しているリソースだけを分離し、すべてのサービスを分離せずに、共有ホスト上のJellyfinを安定して動作させます。

マルチユーザー向けホームストリーミングのJellyfinワークフロー設計図
実際の同時再生経路、ユーザー権限、クライアントの対応機能、帯域幅、そして復旧テスト済みのサーバーワークフローを踏まえて、複数ユーザー向けの Jellyfin を構築しましょう。

SSDにメタデータ、HDDにデータを保存するデュアルストレージ構成のJellyfin環境
レイテンシーが重要な Jellyfin アプリデータには SSD を使用し、大容量メディアには HDD を使用します。その後、SSD の状態を個別に保護し、HDD のスリープ解除と混合 I/O の動作を検証します。

