レンダージョブが「キュー待ち」「停止」「遅い」ときの原因

Super Renders Farmにジョブを送信したものの、ジョブがそのまま動いていなかったり、レンダリングは進んでいるものの明らかに想定より時間がかかっていたりすることがあります。何か問題が起きていると決めつける前に、キューが実際にどう機能しているかを知っておくと役立ちます — 何がジョブの開始タイミングを決めるのか、より高速なティアに料金を払うことで実際に何が得られるのか、そしていくつかの中間ステータスが実際に何を意味するのか、といった点です。

本ガイドでは、開始タイミングを決める要因、優先度ティアによって実際に何が変わるのか、GPUジョブがCPUジョブと異なる動作をする理由、待つのが普通な場合とサポートに連絡する価値がある場合の見分け方、そしてすでに実行中のレンダリングがそれでも想定より遅くなる理由について説明します。

症状

アップロードや送信の直後、ジョブに目に見える進捗がありません。
フレームがまだ1枚も返ってこないまま、シーンの規模から想定される以上に長く「解析中」または「キューに入っています」というステータスが表示され続けています。
ジョブは実際にレンダリング中ですが、ペースが明らかに想定より遅くなっています。
特に異常は見当たらないものの、そのまま待つべきか、問い合わせるべきか判断がつきません。

ジョブの開始タイミングを実際に決めるもの

開始タイミングを決める要素は2つあり、それぞれを区別して理解しておく価値があります。

ジョブがどのノードプールに割り当てられるか。 これは、送信時に選択するマシンテンプレート — DCC、レンダリングエンジン、CPUかGPUか — によって決まり、支払う優先度ティアによって決まるものではありません。ジョブは、該当するプールのワーカーが空くまで開始できません。
キュー内でのご自身の順番。 そのプール内では、選択したティアによって設定される優先度に従ってジョブが並べられます。キューに入っているジョブは、空いているワーカーがその順番に達し次第、開始されます。

より高速なティアを選んでも、プールが単純に満杯である状況を飛び越えることはできませんが、そのプールのワーカーが利用可能になった際には、より早く順番が回ってきます。即座の開始をお約束することはできません — プールの空き状況や、ご自身より前にある他の方のジョブは、変動する実在の要因だからです。

優先度ティアで実際に変わること

CPUレンダリングは、GHz時間あたり$0.004〜$0.016という優先度スケールで運用されており、選択するティアに応じておよそ×1〜×4の幅があります。この幅は単なる価格差ではなく、実際の速度ティアです。

より高いティアを選ぶと、キュー内での順番が上がり、前で待つジョブの数が少なくなります。
より高いティアでは、ジョブを一度により多くのレンダーノードに分散できるため、フレームが1つずつ順番にではなく、より多く並列でレンダリングされます。

この2つの組み合わせ — キュー内でのより良い順番と、同時に稼働するノード数の増加 — こそが、より高いティアが単に高くつくだけでなく、より早く完了する理由です。

GPUジョブの仕組みは異なります。GPUジョブはすべて、1台の専用GPUノード上で実行され、既定で固定の高優先度に設定されています — 上位ティアを購入するという概念はありません。その代わり、GPUジョブのフレームは、より高いティアのCPUジョブのように複数のGPUノードに分散されるのではなく、その1台のマシン上で1つずつ順番にレンダリングされます。GPUアニメーションが一度にではなくフレームごとに進んでいく理由がわからない場合は、これが理由です。

「解析中」「キューに入っています」とは

ジョブがレンダリング時間を消費し始める前に、自動チェックが行われます。必要なジョブ情報が揃っているかを確認し、テクスチャや参照の欠落、カメラや出力パスの問題、バージョンの不一致といった問題がないかシーンをスキャンします。このステップはキュー自体とは別のもので、シーンが重いほど、通過に時間がかかることがあります。

ジョブがその複雑さから想定される以上に長く「解析中」または「キューに入っています」の状態にとどまっている場合、それは通常、キューが長いことのサインではなく、シーン自体を確認する必要があるサインです。

そのまま待つべきときと、サポートに連絡すべきとき

繁忙期に待つこと、そして複雑なシーンに対して解析中のステップが処理を進めている間は、そのまま待つのが正しい判断です — どちらもそれ自体は問題ではありません。ご自身のプールとティアに照らして、キューが妥当な時間で解消されているはずなのにジョブに進捗が見られない場合や、シーンの内容から見て不自然なほど長く「解析中」または「キューに入っています」のまま止まっている場合は、お問い合わせいただく価値があります。どちらのパターンも、多くの場合、そのまま待ち続けるべきものではなく、確認する価値のある具体的な原因を示しています。

レンダリング中のジョブが、それでも想定より遅くなる理由

すでにフレームが返ってきているものの、想定より遅い場合、原因は通常キューではなくシーン側にあります。

シーンの重さ。 グローバルイルミネーションのバウンス回数、サンプリングやアンチエイリアシングの設定、密度の高いジオメトリ、ヘア／ファー／パーティクルシステム、重いボリューメトリクス、大きな非圧縮テクスチャは、ティアやプールに関係なく、フレームごとのレンダリング時間に直接影響します。想定より遅い場合は、まずレンダリング設定を確認する価値があります — バウンス回数を減らす、デノイザーを使う、サンプリング設定を軽くするといった対応で、見た目の品質をほとんど落とさずにレンダリング時間を削減できることがあります。
見過ごされたアセット欠落の警告。 送信時チェックは、テクスチャや参照の欠落を検知した場合、送信をブロックするのではなく警告を出すだけです。そのため、欠落があるシーンでも送信・レンダリングが行われ、見た目がおかしい結果として返ってくることがあります。実際には各レンダリングステップは通常の速度で実行されていても、その欠落を発見し、修正して再アップロードするまでの一連の流れが、「ものすごく時間がかかった」という体感につながることがよくあります。アップロード前にこれを発見する方法については、レンダリング結果でのテクスチャやアセットの欠落をご覧ください。

予防のためのチェックリスト

送信前に、DCC、レンダリングエンジン、プラグインビルドを対応バージョン・プラグイン一覧で確認してください — バージョンの問題があると、サポートへの問い合わせが1往復分、スケジュールに追加されることになります。
優先度ティアは、予算だけでなく締め切りにも合わせて選んでください。締め切りが厳しいときこそ、より高速なティアがコストに見合う場面です。
レンダリング設定は、そのショットに実際に必要な範囲にとどめてください — バウンス回数、サンプル数、解像度は、いずれもレンダリング時間に直接影響します。
毎回のアップロード前に、お使いのDCCのアセット欠落チェックを実行してください（レンダリング結果でのテクスチャやアセットの欠落をご覧ください）。見過ごした警告が原因で再レンダリングになる事態を防げます。
ジョブが止まっているように見える場合は、最悪の事態を想定する前に、実際にどの段階にあるかを確認してください — 特に重いシーンでは、しばらく「解析中」や「キューに入っています」の状態が続くのは正常です。

よくある質問

Q: 優先度ティアを上げれば、ジョブはすぐに開始されますか？ A: 即座には開始されません。より高いティアを選ぶと、キュー内での順番が上がり、一度により多くのレンダーノードを使用できるようになりますが、それでも該当するノードプール内でワーカーが空く必要があります。ティアが影響するのは、空き容量が発生した後にどれだけ早く進むかであり、そもそも空き容量があるかどうかではありません。

Q: ジョブが「解析中」または「キューに入っています」のまましばらく変わりません — 何か問題があるのでしょうか？ A: 通常は問題ありません。この段階は、ジョブの情報を確認し、テクスチャの欠落、カメラや出力パスの問題、バージョンの不一致などがないかシーンをスキャンする自動チェックであり、シーンが重いほど時間がかかることがあります。シーンの内容から見て不自然なほど長くこの状態が続く場合は、何が原因で止まっているかを確認しますので、サポートまでご連絡ください。

Q: GPUレンダリングが、一度にではなくフレームごとに進むのはなぜですか？ A: GPUジョブはジョブごとに1台の専用GPUノード上で実行されるため、複数のGPUノードに同時に分散されるのではなく、そのマシン上でフレームが1つずつ順番にレンダリングされます。その代わり、GPUジョブは既定でキュー内の固定の高優先度が割り当てられます。

レンダージョブがキューに入ったまま止まっている、または遅いのはなぜですか？

症状