Eevee vs Cycles: クラウドファームで勝つのはどちら？

はじめに

EeveeとCyclesは競合するものではなく、同じBlenderファイル内で異なる問題を解決するエンジンです。どちらが「優れているか」ではなく、目の前の作業にどちらが適しているかが問われます。クイックなプレビズパス、600フレームのアニメーション、単一のヒーロースチル、レイトレーシングを必要としないスタイライズドな表現——それぞれに合ったエンジンが存在します。

Super Renders Farmでは毎日Blenderのジョブをレンダリングしており、本番環境でのエンジン比率はCyclesが約70%、Eeveeが約30%です。Cyclesはファイナルクオリティの作業に、Eeveeはプレビューラウンドやスタイライズドアニメーションにそれぞれ多く使われています。ただし、2つのエンジンは1台のワークステーションからクラウドファームへ移行したときの挙動が大きく異なります。Eeveeは1台のマシンで高速であり、台数を増やしても概ね同じ速度を維持します。Cyclesは最初はより時間がかかりますが、GPUを追加するにつれて処理が速くなり続けます。この違いこそが、このガイドの実践的な判断の大半を左右します。

この記事では、各エンジンがBlender 4.xで実際に何をするのか、2026年時点でのEevee NextとCycles Xの位置づけ、各エンジンが適した実際のワークフロー、そしてBlenderのクラウドレンダーファームへオフロードしたときのコストと時間の変化について解説します。どちらが「勝者」かを宣言することが目的ではありません。いつ切り替えるべきかを明確に判断できるルールを提供することが目的です。

2026年のEevee NextとCycles X

両エンジンはBlender 4.2 LTSで大幅なアップグレードを受け、4.3および4.4を通じてさらに改善が続いています。Eevee Nextはラスタライザー（rasteriser）のフルリライトであり、スクリーンスペースグローバルイルミネーション（global illumination）、バーチャルシャドウマップ（virtual shadow maps）、改善されたボリューメトリクス（volumetrics）を導入しました。Cycles X（2021年から維持されている統合Cyclesアーキテクチャ）は、スケジューリングの改善、ライトツリーの最適化、Cyclesドキュメントに記載されたOptiXデノイザーのアップデートを継続的に受けています。

根本的な違いは変わっていません。Cyclesは物理ベースのパストレーサー（path tracer）であり、光がシーン内をどのように散乱するかを計算するためにレイをトレースします。Eeveeはリアルタイムラスタライザー（real-time rasteriser）であり、スクリーンスペースの巧みなトリックを使って同じ照明を近似します。パストレーシング（path tracing）は正確なコースティクス（caustics）、屈折（refraction）、グローバルイルミネーション（global illumination）を生成します。ラスタライゼーション（rasterisation）は、ほとんどの場合は正しく見えるものの、画面外オブジェクトのミラー反射、正確な屈折ガラス、複雑なコースティクスなどのエッジケースでは崩れます。Eevee Nextリライト後も同様です。

2026年の典型的なBlenderユーザーにとっての実用モデルは次のとおりです。Cyclesはファイナルフレーム用エンジン、Eeveeはイテレーション用エンジン。クラウドファームはその境界をシフトさせますが、消し去ることはありません。Super Renders Farmで処理するジョブ全体を通じて、サブミットメタデータのエンジンフラグはプロジェクトタイプとほぼ完全に相関しています——建築ビジュアライゼーション (archviz)やプロダクトはCycles、モーションデザインとプレビズはEeveeという具合です。

Eeveeが有利な場面

Eeveeは、物理的な正確さよりもフレームあたりの速度が重要な場合に適したツールです。最も明確なケースを以下に示します。

• アニマティックとプレビズ。 1台のワークステーションで1フレームあたり12秒でレンダリングできる1080p・300フレームのプレビズは、Eeveeが難なくこなせる作業です。同じハードウェアでCyclesはこの速度に及びません。
• スタイライズドおよびNPRワーク。 アニメ風、絵画風、マットシェーディングのシェーディングであれば、正確なコースティクスは必要ありません。Eeveeはこれらのルックを美しく、かつ高速にレンダリングします。
• 制御された照明によるモーショングラフィックス。 ロゴリビール、抽象的な3Dタイポグラフィ、HDRIライティング下のプロダクトターンテーブルはいずれもEeveeの得意領域です。スクリーンスペースリフレクションとブルームがルックを支えます。
• リアルタイムスタイルのシネマティクス。 ゲームのシネマティックモックアップやUnreal Engine的なルックはEeveeの領域です。このエンジンはゲームレンダラーに近い挙動をするよう設計されているためです。
• 欠けているものを補えるアニメーションパス。 シーンにガラス、コースティクス、画面外の反射面、極端な被写界深度がない場合、Eeveeはプレビズだけでなくファイナルエンジンとして使用できます。

Super Renders Farmでは、クライアント向けに1,200フレームのアニメーションシーケンス全体をEeveeでレンダリングして納品したケースがあります。ライティングはEeveeの強みを活かして設計されており、HDRI駆動、クリアガラスなし、スクリーンスペースアンビエントオクルージョン（ambient occlusion）でコンタクトシャドウを処理しました。フレームあたりのレンダリング時間はCyclesの14分ではなく90秒でした。これがEeveeによって実現できる選択肢です。

Cyclesが有利な場面

Cyclesは、画像が物理的に正確である必要がある場合に適したツールです。最も明確なケースを以下に示します。

• 建築ビジュアライゼーション (archviz)のインテリア。 窓、ガラス、鏡を通じてバウンスする室内光、間接照明——これこそがパストレーシング（path tracing）が存在する理由です。Eevee Nextはスクリーンスペースグローバルイルミネーション（GI）で改善されましたが、正確なインテリアバウンスライトではCyclesに及びません。
• 屈折マテリアルを使用したプロダクトレンダー。 ガラスボトル、ジュエリー、時計、そしてコースティクスと正確な屈折がビジュアルの要となるシーン。
• VFXとフォトリアルなコンポジティング。 レンダーを実写プレートに自然に馴染ませる必要がある場合、Cyclesはコンポジターが期待するリニアで物理的に根拠のあるデータを生成します。
• フレームあたりの時間が許容できるスチル。 1,024サンプルとフルデノイジングによる4KのヒーローフレームはひとつのCyclesジョブです。ローカルでは40分かかるレンダーが、クラウドGPUファームでは4分になるかもしれません——しかしEeveeは時間に関わらずそのクオリティの画像を生成できません。
• フォトリアリズムが必須のアニメーション。 長尺のCyclesアニメーションは1台のワークステーションでは高コストです。ここでクラウドファームが計算を変えます。

フリート全体を通じたパターンは一貫しています。Cyclesでフラグされて届くジョブは建築ビジュアライゼーション、プロダクト、VFXの傾向があります。Eeveeでフラグされるジョブはモーションデザイン、アニマティック、スタイライズドアニメーションの傾向があります。どちらのエンジンも有効であり、作業内容が決定します。

機能比較表

機能	Eevee Next（Blender 4.x）	Cycles X（Blender 4.x）
レンダリング技術	リアルタイムラスタライゼーション	物理ベースパストレーシング
グローバルイルミネーション	スクリーンスペース（近似）	完全な双方向パストレーシング
コースティクス	限定的／近似	正確（コースティクス有効時）
屈折	スクリーンスペース（エッジで崩れる）	物理的に正確
反射	スクリーンスペース（画面外の反射は失敗）	完全なレイトレーシング
ヘア／ファー	ストランドベース、近似シェーディング	完全なパストレーシングストランド
ボリューメトリクス	Eevee Nextで改善	物理的に正確
ハードウェアターゲット	GPU（ラスタライゼーション）	GPU + CPU（パストレーシング）
デノイジング	組み込みテンポラルデノイザー	OpenImageDenoise + OptiX
フレーム時間（典型的な1080p）	5〜60秒	2〜30分
クラウドGPUスケーリング	フラット——フレームあたりはすでに高速	リニア——GPU追加でウォールタイムが比例して短縮
ユースケース	プレビズ、モーションデザイン、スタイライズドワーク	建築ビジュアライゼーション、プロダクト、VFX、フォトリアル

クラウドレンダーファーム: Cyclesがより良くスケールする理由

ここでワークフローの議論が変わります。1台のワークステーションでは、EeveeとCyclesの選択はフレームあたりの時間によって決まります。クラウドファームでは、より多くのハードウェアを投入したときに各エンジンがどう振る舞うかが問題になります。

Cyclesはフレームレベルで「当惑するほど並列」（embarrassingly parallel）です。各フレームは独立したパストレーシングジョブであり、現代のGPU（RTX 4090、RTX 5090）上でのOptiXアクセラレーションデノイジングは、ボトルネックがサンプル数であり、通常はデノイズではないほど高速です。600フレームを20台のGPUを持つGPUクラウドレンダーファームに分散させると、ウォールタイムはおおよそGPU台数分だけ短縮されます。ローカルで12時間かかるCyclesジョブがファームでは30分になります。このリニアな関係こそが、Cyclesをファームにかけることのビジネスケースそのものです。

Eeveeのスケーリングは異なります。フレームあたりの時間はすでに低く——多くの場合1分未満——エンジンは1台のデバイスでGPUバウンドです。Eeveeフレームをファームに分散させることは、数千フレームがある場合には効果がありますが、最初からフレームあたり数時間待っていたわけではないため、相対的なスピードアップは劇的ではありません。長いEeveeシーケンス（スタイライズドアニメーションで10,000フレーム以上）ではファームの経済性はなお有利ですが、Cyclesの作業ほど緊急性はありません。

タイルベースのデノイジングも重要な要素です。Blender 4.xのCyclesは、より多くのGPUメモリとコアから恩恵を受ける方法でフレームをまたいだデノイジングとタイルをまたいだデノイジングが可能です。OptiXデノイジングを搭載したRTX 5090（32GB）でCycles Xを動かすと、24GBのGPUが1,024サンプルで解消するのとほぼ同じ時間で256サンプルでノイジーなインテリアを解消できます。現行世代のGPUを持つクラウドファームでは、画質を犠牲にすることなく、サンプル数と時間をトレードオフできます。

Blenderクラウドレンダリングガイドでも同じパターンが見られます。ローカルのCyclesレンダリングからBlenderクラウドレンダーファームへ移行したクライアントは、アニメーションで10〜30倍の時間節約を報告するのが一般的であり、フレームあたりのコストは解像度、サンプル数、エンジン設定に応じて$0.10〜$0.60の間に落ち着きます——公開料金とカルキュレーターは料金ページでご確認いただけます。

エンジンの選び方

ほとんどのBlenderプロジェクトに対して機能するシンプルな意思決定フレームワークを紹介します。

1. スチルか長尺アニメーションか？ スチルはフレームあたりの時間が長くても許容できます。アニメーションはそれを拡大します。長尺のCyclesアニメーションにはファームが必要です。
2. 画像に正確なコースティクス、屈折、インテリアグローバルイルミネーションが必要か？ 必要ならCycles。必要なければEeveeが選択肢に入ります。
3. 締め切りの形は？ 2週間の建築ビジュアライゼーション納品であれば、ローカルでCyclesを使用できます。2日の締め切りにはファームかEeveeが必要です。
4. 実写とのコンポジティング？ ほぼ常にCycles。
5. スタイライズド、NPR、またはゲームシネマティクスのルック？ ほぼ常にEevee。

Super Renders Farmでクライアントにお伝えするルール：レンダー予算に合わせてルックをデザインすることが重要で、その逆ではありません。ローカルのみの予算であれば、Cyclesが技術的に理想的であっても、Eeveeが正しいアーティスティックな選択となる場合があります。パイプラインにクラウドファームがあれば、Cyclesは物理的な正確さから恩恵を受けるあらゆるプロジェクトにとって実行可能なデフォルトとなります。

FAQ

Q: Eevee Nextは通常のEeveeとは別のエンジンですか？ A: Eevee NextはBlender 4.2 LTSで導入されたEeveeラスタライザーのフルリライトです。新しいコンポジターベースのパイプライン、バーチャルシャドウマップ、スクリーンスペースグローバルイルミネーションを使用します。Blender 4.2以降のデフォルトEeveeであり、現在のBlenderリリースに「通常の」Eeveeという別のエンジンは存在しません。 Q: レンダーファームがなくてもCyclesでアニメーションを使用できますか？ A: 可能ですが、長いレンダリング時間を計画に入れる必要があります。1台のハイエンドワークステーションでの600フレームの1080p Cyclesアニメーションには40〜80時間かかる場合があります。同じジョブはクラウドGPUファームでは通常1〜4時間で完了します。ローカルのCyclesアニメーションは短いシーケンスまたは低解像度では現実的ですが、長尺の作業は通常ファームへ移行します。 Q: どちらのエンジンが高品質な画像を生成しますか？ A: 物理的に正確な出力——バウンスライトのあるインテリア、屈折マテリアル、正確なコースティクス——に対しては、Cyclesが光をパストレースするためより高品質なエンジンです。スタイライズド、モーションデザイン、ゲームシネマティクスのルックでは、画像の品質は好みの問題であり、Eeveeも同様に完成した結果をより速く生み出せます。Blenderでより高品質なレンダリングを得る方法は、間違ったエンジンを無理に使い続けることではなく、ルックに合った正しいエンジンを選ぶことに帰着します。 Q: Eeveeはレンダーファームの恩恵を受けますか？ A: 可能です。特に長いアニメーションシーケンス（数千フレーム）では、フレームを複数のマシンに並列化することで時間を節約できます。ただし、Eeveeのフレームはすでに高速であるため、フレームあたりのスピードアップはCyclesほど大きくありません。Eeveeにとってのクラウドの価値は、個々のフレームの純粋な速度ではなく、長いアニメーションのスループットにあります。 Q: クリーンなレンダーのためにCyclesで必要なサンプル数は？ A: 現在のBlenderバージョンのOptiXデノイジングでは、ほとんどの本番シーンはスチルで256〜512サンプル、アニメーションで128〜256サンプルでクリーンに仕上がります。強い間接照明を持つインテリアシーンでは1,024以上が必要な場合があります。デノイザーが重労働の大半をこなします——1,024を超えてサンプルを増やしても、時間に見合うほど品質が向上することはほとんどありません。 Q: CyclesとEeveeは同じ色と照明を生成しますか？ A: Blender 4.xでは視覚的に一貫性を持たせることを目指していますが、わずかな違いが残ります。Cyclesが物理ベースの出力のリファレンスです。Eevee Nextはスクリーンスペースグローバルイルミネーションと改善されたボリューメトリクスによってそのギャップを大幅に縮めましたが、CyclesのルックをEeveeで正確に再現するにはシェーダーとライティングの調整が必要です。 Q: 同じBlenderシーンを両方のエンジンでレンダリングできますか？ A: はい——最近のシェーダーとライトのほとんどはどちらのエンジンでも動作します。一部のノード設定（特定のプロシージャルテクスチャ、複雑なボリュームシェーダー、ディスプレースメント）はエンジン間で挙動が異なります。Blender Studioのベンチマークシーンはどちらのエンジンでも動作するよう設計されているため、クロスエンジンのテストファイルとして役立ちます。 Q: 建築ビジュアライゼーション（archviz）にはどちらのエンジンが適していますか？ A: ほぼすべてのケースでCyclesです。建築インテリアは、窓、ガラス、反射面を通じた正確な光のバウンスに依存します——これはすべてパストレーシングがEeveeでは実現できない結果を生む領域です。Eeveeはデザインフェーズ中の迅速なクライアントレビュープレビューに役立つことがありますが、最終納品物はほぼ常にCyclesです。