Unreal Engine 5 Nanite アーキテクチャ：包括的技術分析、最適化戦略、およびPlayStation 5開発ガイド
仮想化マイクロポリゴンジオメトリの基礎とパラダイムシフト
リアルタイムレンダリング技術およびコンピュータグラフィックス業界において、長年にわたり直面してきた最大の制約の一つは、ハードウェアリソースを効率的に活用するためのポリゴン予算や「ドローコール（draw call）」数が、CPUとGPU間の通信において必然的にボトルネックを生み出すという点でした。1 従来のゲーム開発ワークフローでは、3Dアーティストやテクニカルディレクターが、映画品質のZBrush製彫刻、レーザースキャン、フォトグラメトリーデータなどの高詳細モデルをゲームエンジンにインポートする際、手動によるトポロジーの最適化、「Level of Detail（LOD）」チェーンの構築、および高解像度ディテールの「ノーマルマップ（Normal Map）」へのベイク（baking）を行うことが必須でした。1 このプロセスは、制作スケジュールを長期化させる厄介な負荷を生み出すだけでなく、メモリの制約により画面上のディテールレベルを人工的な限界に縛り付けていました。1 Unreal Engine 5（UE5）の登場と共に業界標準となったNaniteテクノロジーは、こうした従来の障害を根本から排除する仮想化マイクロポリゴンジオメトリ（virtualized micropolygon geometry）システムです。1 Naniteは、ポリゴン予算を技術的な制約から解放し、映画品質の数十億ものポリゴンで構成されるソースファイルを、手動のLOD処理を一切必要とせずにリアルタイムでシーンにインポートすることを可能にします。1 このシステムは、プレイヤーのカメラによってその瞬間に実際に画面上に映るディテールのみを処理するように設計されており、ピクセルサイズより小さな三角形やジオメトリの断片が無駄にレンダリングされることはありません。3 このテクノロジーは、継続的で滑らかな自動LODシステムを提供し、従来のレンダリングパイプラインをGPU主導のデータストリーミングアーキテクチャへと完全に置き換えます。1 Naniteの主要な革新は、4つの主要な見出しに集約されます 1:
仮想化ジオメトリ：シーン全体が1つの巨大なスタティックメッシュとして扱われ、画面上に表示されている部分のみが処理の対象となります。
自動詳細レベル（LOD）：段階的かつ不連続なLOD切り替え（LODポッピング）の代わりに、距離と画面解像度に応じたシームレスで滑らかなディテールの変化が実現されます。
GPU駆動型パイプライン：ドローコールとカリングの処理がCPUから解放され、GPUの並行処理能力へと移譲されます。
効率的なストリーミング：SSDを介した直接的なメモリのストリーミングにより、必要とされるジオメトリデータのみが瞬時にメモリに読み込まれます。
この調査レポートでは、Naniteシステムの詳細な動作原理、プロジェクト統合のための必須手順、最適化の要件、ボトルネックの克服方法、そして特にハードウェアレベルでの独自の圧縮と高速なデータストリーム（I/O）を備えたPlayStation 5（PS5）プラットフォーム向けのゲーム開発ダイナミクスについて、包括的な分析的枠組みの中で検証します。
Naniteのテクニカルアーキテクチャとデータ構造
Naniteシステムの核となる哲学は、ジオメトリデータをメモリの制限内に収めようとする巨大なスタティックメッシュ（static meshes）として扱うのではなく、仮想テクスチャ（virtual texturing）と同様に、動的にストリーミングされ、オンデマンドで管理される断片化されたデータセットとして扱うことです。3 従来のエンジンは、オブジェクトのほんの一部のみがカメラの視野（フラスタム）内にある場合でも、オブジェクト全体をメモリに読み込んで処理しようとしますが、Naniteはこの可視性をミリメトリックなピクセル精度で評価します。3
階層型クラスター構造（Hierarchical Cluster Structure）
インポート段階において、Naniteアルゴリズムは3Dモデルを解析し、階層型クラスターツリーへと分割します。1 処理される各スタティックメッシュは、ハードウェアレベルで最高のパフォーマンスを発揮するように、正確に128個の三角形からなる小さなデータパケット（クラスター）に分割されます。1 128個の三角形というこの固定サイズは、最新GPUの波面（ウェーブフロント）やワープサイズに完全に適合し、並列処理ユニットとキャッシュ制限（cache limits）から最大の処理効率を引き出すために特別に選択された最適な単位です。1 これらのクラスターは、境界ボックス（bounding box）情報、スクリーン空間でのLOD選択のための幾何学的エラー指標、および親子関係を含む有向非循環グラフ（Directed Acyclic Graph - DAG）に類似したツリーデータ構造を相互に形成します。1 カメラが該当するオブジェクトに近づいたり遠ざかったりするにつれて、システムはこのツリー構造上をリアルタイムで走査し、各画面領域に対してどのクラスターが画面上のピクセル密度に最も適しているかを決定します。1 従来の接近手法とは異なり、オブジェクト全体が突如として変化することはありません。不連続なLODの切り替えの代わりに、オブジェクト表面の異なる領域を同時に異なるクラスター詳細レベルで処理することができ、ハードウェアラスタライゼーションにおいて視覚的な継ぎ目や亀裂（クラック）を発生させることなく、エッジから滑らかに結合します。3
可視性バッファ（Visibility Buffer）と分離されたシェーディング
NaniteがCPUのボトルネックを克服し、現代のレンダリングアーキテクチャに革命をもたらした最も重要な構造は、レンダリングパイプラインの大半を直接GPUに移行させ、従来のフォワード（Forward）またはディファード（Deferred）シェーディングのロジックを「可視性バッファ（Visibility Buffer）」に置き換えることです。1 Naniteのレンダリングループにおける可視性バッファの概念は次のように機能します：従来のG-Buffer構造では、ピクセルの計算時にカラー、法線、ラフネス（粗さ）などの膨大なサイズのデータがすべてのピクセルについてメモリに書き込まれます。一方、Naniteは画面上の各ピクセルに、32ビットまたは64ビットサイズの識別番号（プリミティブIDとクラスターID）のみを記録します。1 このバッファメモリにはカラーやシェーディングデータは含まれず、画面上のその特定のピクセルにどの三角形とどのクラスターが表示されているかを示す参照マップにすぎません。1 可視性バッファが完全に満たされた後、画面領域の各ピクセルに対してマテリアルデータが1度だけ呼び出され、シェーディング処理が実行されます。この「分離された（decoupled）」アーキテクチャのおかげで、カメラの背後に残るもの、別のオブジェクトの背後に隠れているもの、または最終的な画像に何ら貢献しない数百万の三角形に対して、不要なマテリアルの計算が行われることはありません。この状況は、GPUの最大の敵の一つである「オーバードロー（Overdraw）」の問題を、マテリアルの計算ベースで完全に排除します。9
GPU駆動型カリング（Culling）メカニズム
Naniteアーキテクチャにおいて、カリング処理は従来のエンジンのようにCPU上でオブジェクト（アクター）単位で行われるわけではありません。CPU側の従来のドローコールの準備は完全にバイパスされ、カリングのプロセスはGPU内のコンピュートシェーダーに直接委譲されます。10 オクルージョンカリング（Occlusion Culling）の段階において、NaniteはHZB（Hierarchical Z-Buffer）と呼ばれる、スクリーン空間でさまざまな深度レベル（ミップマップ）が対数的に保存される構造を使用します。9 HZBは、128個の三角形を持つ各クラスターの境界ボックスを、スクリーン空間の深度データと比較します。9 あるクラスターがシーン内の別のオブジェクトの背後に隠れている場合、即座にレンダリング処理から破棄されます。このカリングは非常に精密であり、オブジェクト単位ではなくクラスター単位で行われるため、巨大な山の背後に隠れた広大な森の中の木々について、山の背後に隠れている部分のクラスターのみがカリングされる一方で、山の山頂から突き出ている葉のクラスターは処理され続けます。8
ラスタライゼーションのパス：ソフトウェアおよびハードウェア処理のダイナミクス
Naniteは、三角形を画面のピクセルへと変換する（ラスタライゼーション）ために単一の処理ユニットを使用する代わりに、三角形の画面上のサイズとマテリアルの特性に応じて動的に決定される2つの異なるラスタライゼーションパス（raster path）を使用します。9 パフォーマンスの最適化は、これら2つのパス間のバランスを完璧に構築することにかかっています。
ソフトウェアラスタライゼーション（Software Raster Path）
ソフトウェアラスタライゼーションは、Naniteの中で最も効率的、最速、かつ革新的なコア処理パスです。9 このパスは、三角形が画面上で1ピクセル未満（サブピクセル）または正確に1ピクセルのサイズである場合に有効になります。9 このシナリオにおいて、NaniteはGPUのハードウェア三角形描画ユニットを完全にバイパスし、プロセスを「コンピュートシェーダー（Compute Shaders）」を通じて実行します。64ビットアトミック演算（atomic interlocks）を使用することにより、ピクセルが可視性バッファに驚異的な速度で書き込まれることが保証されます。開発者コンソールから r.Nanite.Visualize.Advanced 1 または r.nanite.showmeshdrawevents 1 コマンドによってRaster Binsの視覚化モードを有効にすると、ソフトウェアラスタライゼーションを通過するクラスターが青色で表示されます。9 適切に最適化されたシーンでは、ジオメトリの圧倒的多数が青色であることが目標とされるべきです。9
ハードウェアラスタライゼーション（Hardware Raster Path）
ハードウェアラスタライゼーションは、三角形が画面上で1ピクセルのサイズより大きい場合、またはNaniteのコンピュートベースのソフトウェアラスタライゼーションでは処理できない特殊なマテリアル属性が使用されている場合に有効になる、従来のGPU描画手法です。9 このパスは、視覚化モードでは赤色で表示されます。9 特にカメラが巨大な壁に接近すると、三角形がピクセルよりも大きくなるため、システムがハードウェアラスタライゼーションに移行することは正常です。9 しかし、カメラから離れたオブジェクトやマイクロポリゴンが依然として赤色で表示されている場合、これは「ハードウェアフォールバック（Hardware Fallback）」が発生していることを示しており、深刻な最適化の問題です。9 ハードウェアラスタライゼーションへの望ましくないフォールバックの最大の原因は、マスク付き（masked）、透明、または複雑な変形オフセットを持つマテリアルの使用です。9
Raster Bins（ラスタビン）とマテリアル管理
Naniteのパフォーマンスの核心は、ジオメトリそのものよりも、ジオメトリに適用されるマテリアルが「Raster Bins」と呼ばれる仮想の箱にどのように分散されているかに関係しています。9 Naniteは、標準の、不透明な（opaque）、そして任意のピクセル深度オフセット（PDO）やワールド位置オフセット（WPO）を含まないすべてのマテリアルを1つの巨大なRaster Bin（ラスタビン）にまとめ、システムはこのビンを単一のパスで電光石火の速さで処理します。9 しかし、オブジェクトに変位（displacement）、マスク（masked/alpha test）、または風のエフェクトに使用される集中的なWPOが含まれている場合、これらのオブジェクトはNaniteの高速なパスから外され、各マテリアルタイプに対して個別かつ独立したRaster Binが作成される原因となります。9
パフォーマンスクラスマテリアルの種類と特性Naniteの影響と処理ステータス戦略的な開発者の推奨事項最良（Best）Opaque（不透明）、WPO、PDO、変位オフセットを含まない純粋なマテリアル。単一のRaster Bin内でブレンドされます。ソフトウェアラスタライゼーションがアクティブに動作し、ドローコールのコストはゼロに近いです。9プロジェクトの環境デザイン、建物、およびハードサーフェスの90%以上は、確実にこのタイプで構成されるべきです。9良好（Good）Opaque（不透明）だが、最小限のWPO（World Position Offset）が存在する。WPOが使用されるため、静的なクラスターがGPU内で個別に計算され始めます。境界ボックス（bounding boxes）が動きによって変化するため、カリング（culling）処理が困難になります。境界ボックスの崩壊や誤ったカリングを防ぐために、WPOの移動距離は必ずクランプ（clamp）されなければなりません。3 変形が静的な場合はベイク（baked）処理を行う必要があります。9普通（Okay）Masked（マスク付き/透明なエッジ、Alpha Cutout）。強制的にハードウェアラスタライゼーション（Hardware Raster Path）に移行します。空のピクセルが継続的に評価される結果、激しい「オーバードロー（Overdraw）」を引き起こします。従来の植生やフェンスのモデリングで使用されますが、パフォーマンスを損なうため非常に控えめに使用する必要があります。8最悪（Worst）複雑に変形されたマテリアル（集中的なWPO + PDO）。それぞれのバリエーションが個別のRaster Binを生成します。ステートの変更を増加させ、フレーム時間を瞬時にバ予算の制限を超過させます。遠方のオブジェクトでは直ちに無効化されるべきであり（LODフォールバック）、UE 5.7で導入されたNanite Skinningのようなより近代的な代替手段に移行する必要があります。9
過剰なRaster Binの生成は、GPU上でのステート（状態）変更の増加およびドローコールバリエーションの増加を意味し、GPUを著しく低速化させます。9 60 FPSを目標とするプロジェクト（1フレームあたり16.66 ms）では、VisBufferの処理を4 ms未満に、BasePassの処理を3 ms未満に抑えることが必須です。そうでない場合、ポストプロセス、Lumen、人工知能などの他のシステムに割く時間がなくなってしまいます。7
Nanite統合：プロジェクトでの活用方法
Naniteの統合は、既存のUnreal Engineゲーム開発ワークフローに極力負担をかけない形で組み込めるように設計されています。旧世代の手動によるLOD作成やノーマルマップのベイク処理を排除するこのシステムは、適切に設定されていればパフォーマンスを自動的に最適化します。1
ジオメトリの種類とサポートされているコンポーネント
ジオメトリがNaniteの機能を活用できるようにするには、インポート時またはその後、スタティックメッシュエディター（Static Mesh Editor）を介してこの機能を有効にする必要があります。3 Unreal Engine 5の現在のバージョンでは、Naniteがサポートするコンポーネントの種類が大幅に拡張されています。
● スタティックメッシュ（Static Meshes）：プロジェクトに含まれる任意のStatic Meshは、エディター内で「Enable Nanite Support」オプションにチェックを入れることで変換できます。何千ものオブジェクトが登場する巨大なシーンでは、コンテンツブラウザーを介した一括有効化（batch-enable）により、ライブラリ全体を同時にNaniteフォーマットに移行できます。3 Naniteシステムの主なターゲット層はこれらのメッシュです。
● スケルタルメッシュ（Skeletal Meshes）：初期のUE5バージョンでは静的オブジェクトのみがサポートされていましたが、UE 5.3以降のバージョンで導入されたSkeletal Mesh APIのサポートにより、動的に変形する（アニメーションする）キャラクター、クリーチャー、車両でもNaniteを使用できるようになりました。3 スケルタルメッシュにおける最大の革新は、メッシュ全体に対して単一のドローコール（one draw call）しか生成されない点です。Nanite Skeletal Meshは、従来のジオメトリLODの代わりにアニメーションLODを使用して動作します。3
● スプラインメッシュ（Spline Meshes）およびランドスケープ（Landscape）：Naniteは、道路、パイプライン、壁などの曲線に沿って形状が変化するSpline Meshや、広大なオープンワールドのLandscapeトポロジ（Nanite Tessellationを介して）をネイティブでサポートしています。3 地面のわずかなディスプレースメント（displacement）の細部は、ポリゴン密度を上げたりパフォーマンスを低下させたりすることなく、マテリアルを介して直接取得できます。3
● インスタンス化されたメッシュ（Instanced Static Meshes - ISM / HISM）：何百万ものコピーを持つオブジェクト（例：巨大な森の岩や建物のレンガなど）は、Naniteのビジビリティバッファのおかげで、単一のメモリフットプリントでレンダリングされます。ただし、シーン内に存在できるNaniteインスタンスの最大数はハードウェア的に1600万に制限されていることに留意する必要があります。3
フォールバックメッシュ（Fallback Mesh）の生成とその役割
Naniteデータを作成する際に「Build Nanite」ボックスにチェックを入れると、エンジンは高詳細なメッシュに加えて、従来のポリゴン数を持つ「Fallback Mesh」（フォールバックメッシュ）と呼ばれる簡略化されたジオメトリを自動的に派生させます。13
このフォールバックメッシュが存在する理由は極めて重要です。NaniteのGPU駆動型ラスタライゼーションシステムは、複雑な物理コリジョン（collision）計算、Lightmassによる事前計算済みライトマップ（baked lighting）、そして最も重要なハードウェアレイトレーシング（hardware ray tracing / Lumen HWRT）の反射には直接使用できません。13 ゲームエンジンのCPU側のロジックシステムはこの従来の三角形データを必要とします。「Fallback Relative Error」（フォールバック相対誤差）パラメータを変更することで、フォールバックメッシュの詳細度を制御できます。3 誤差率が低くなるほどフォールバックメッシュのポリゴン数が増加し、ハードウェアレイトレーシングの反射（Lumen Hit Lighting）の計算精度が向上しますが、それに応じてメモリ（VRAM）の消費量も増加します。14
Nanite Foliage：UE 5.6/5.7で導入されたボクセルおよびアセンブリ（Assembly）システム
ゲームエンジンにおいて、森林地帯や密集した植生は、重なり合う多数の透過（マスクされた）葉のサーフェスがあるため、長年にわたりNaniteの最も脆弱な点とみなされていました。15 従来の草や葉のモデリング（alpha cards）は、ピクセルが何度も重ねて評価され、HW Rasterに落ちる「オーバードロー（Overdraw）」の問題を引き起こしていました。8
Unreal Engine 5.6、特に5.7のバージョンでは、「Nanite Foliage」システムによってこの問題が根本的かつアーキテクチャ的な変更によって解決されました 12:
Nanite Voxels（ボクセル）：カメラから離れた木々や植生の、複雑でオーバードローを引き起こす葉の三角形は、「Shape Preservation」メニューから「Voxelize」設定を行うことで、遠方でボクセルに変換されます。17 Minecraftのブロックに似たこれらのボクセルは、三角形とは異なり、ボリュームピクセルとして処理され、透明度（alpha）の必要性を完全に排除するため、ハードウェアレベルでオーバードローの問題を防ぎます。15 遠くにある何十万もの木々が、画面ピクセルサイズのボリュームボクセルとして極めて低コストで処理される一方、近づくにつれてスムーズにフルディテールなマイクロポリゴンへと移行します。15
Nanite Assemblies（アセンブリ）：巨大な木を高解像度でモデリングすると、ディスク上およびメモリ上で驚異的なサイズに達します。Nanite Assemblies機能のおかげで、木の各枝、葉、幹は、個別の巨大なスタティックメッシュとしてではなく、USD（Universal Scene Description）インポーターを介して階層的な全体（アセンブリ）として読み込まれます。12 Houdini Solarisなどのプログラムで準備されたNaniteAssemblyRootAPIスキーマにより、何千もの葉が実際には同じ小さな葉のメッシュのインスタンス化（instancing）手法によって呼び出されたものになります。19 この構造により、メモリフットプリントが信じられないほど小さくなります。
Nanite Skinning：従来のWPO（World Position Offset）ベースの風のアニメーションは、各クラスターの境界ボックスをフレームごとに変更するため、CPU/GPU上で常時再計算（カリングの無効化：culling invalidation）を行う必要がありました。15 UE 5.7で導入されたNanite Skinningにより、木々はスケルタルメッシュ（skeletal mesh）としてインポートされ、物理的およびプロシージャルな風の影響が、「Dynamic Wind」プラグインを使用して骨（bones）を介して計算されます。12 これにより、NaniteはRaster Binsのパフォーマンスを犠牲にすることなく、より有機的で一貫性のある風の相互作用を提供します。新しいQuixel MegaplantsライブラリとProcedural Vegetation Editor（PVE）は、これらのテクノロジーを完全に統合して使用することで、60 FPSの目標を容易に達成できるようにしています。15
最適化プロセス：何に注意すべきか？
Naniteはパフォーマンスを向上させるように設計されていますが、「無限のポリゴン」という約束は魔法の杖ではありません。誤った使用法やハードウェア制限を遵守しない場合、フレーム時間を深刻に危険にさらす複雑なシステムです。11
透明度（Translucency）、マスキング、およびオーバードローの問題
従来のゲーム最適化（UE4以前）では、詳細なオブジェクトを低ポリゴンサーフェスに透明なマスク（アルファテクスチャ／マスクマテリアル）をまとわせてシミュレートするのが標準的なアプローチでした。8 しかし、Naniteアーキテクチャでは、このアプローチは完全に誤りであり、破滅的な結果を招きます。8
Naniteは、ビジビリティバッファを計算する際に透明（空の）ピクセルをスキップするために、追加のハードウェアパスを必要とします。マスクされたマテリアルが連続して配置されている場合（例えば金網や木の葉など）、システムは同じピクセルの深度と透明度を何十回も読み取って処理する必要があり、これが「オーバードロー（Overdraw）」と呼ばれます。10
重要ルール：Naniteシステムでは「ジオメトリは非常に安価ですが、透明度は非常に高価です」。葉、柵、網などの穴あきオブジェクトを作成する際、マスクされたテクスチャ（masked material）を使用する代わりに、必要に応じて形状の周囲を何十万もの追加ポリゴンで完全に（fully modeled）モデリングし、マテリアルを厳密に「Opaque」に設定する必要があります。8 完全にモデリングされた木の葉は、マスクされた平らな表面（plane）よりもはるかに高速にレンダリングされます。8
仮想シャドウマップ（Virtual Shadow Maps - VSM）の統合
従来のシャドウマップ（Cascaded Shadow Maps - CSM）は、Naniteオブジェクトが提供するマイクロポリゴンレベルの圧倒的な詳細度レベルに適応できません。Naniteで使用するために特別に設計されたVirtual Shadow Maps（VSM）は、影の解像度を画面のピクセルと動的に一致させることで、カミソリのようにシャープな影を提供します。23
VSMはその性質上、高いVRAMメモリ要件を持っています。影を落とすオブジェクトが常に動いている場合（例：WPOで揺れる葉）、VSMの影キャッシュ（shadow cache）はフレームごとに無効化（invalidated）され、シャドウマップがゼロから再計算されるため、深刻なFPS低下を引き起こします。22 このため、静的なシーンや建物はNaniteとVSMの組み合わせで完璧に動作しますが、動きの激しい森林地帯ではWPOの制限を設けるか、パフォーマンスのテストに基づいて従来のシャドウマップ（Shadow Maps）への切り替えを検討する必要があります。25
プロファイリング（Profiling）とパフォーマンス読み取りコマンド
最適化問題の根本原因を突き止め、ボトルネックがCPUとGPUのどちらにあるかを特定するために、UE5で提供される内部プロファイル（stat）コマンドを定期的に、かつプロジェクトの最初から実行する（早期最適化の原則）ことが不可欠です。26
開発者が定期的に使用すべきプロファイルコマンドおよびビジュアライゼーションツールは次のとおりです 28:
プロファイルコマンド / モード説明と使用目的開発者のアクションstat unit基本的なボトルネックの検出。画面上の総時間を「Frame」（全体の時間）、「Game」（CPUゲームループ）、「Draw」（CPUレンダー準備）、または「GPU」としてミリ秒（ms）単位の内訳で表示します。28GPU時間が16.66msを超える場合はグラフィックスの制限に、Game時間が超える場合はAIやBlueprintのTick最適化に移行する必要があります。
コマンド / ツール機能と説明最適化アクションstat gpu または stat scenerenderingGPU内の特定のレンダー負荷をリストアップします。Nanite BasePass、Lumen、影（Shadow Depths）、ポストプロセスの負荷にかかる時間を詳細に示します。Nanite VisBufferが4msを超える場合、またはBasePassが3msを超える場合は、Raster BinsまたはOverdrawのチェックを行う必要があります。r.nanite.showmeshdrawevents 1GPU Profiler（Ctrl+Shift+,）内で、どの特定のNaniteマテリアルとオブジェクトがどれだけの時間を費やしているかを階層的に調査します。コストのかかるWPOマテリアルや透明なオブジェクトを特定して切り離すために使用されます。NaniteStats画面の隅に「ShaderPrint」テクノロジーで直接インターフェースを描画します。仮想影と一次視点（Primary View）のどちらがNanite上で描画負荷を引き起こしているかをライブでフィルタリングします。コンソールにパラメータ（primary, VirtualShadowMaps）を入力してアクティブなパスの負荷を特定します。View Mode > Nanite Visualization > Overdraw画面上のピクセルが重なり合っている高密度なエリアを青（良）、オレンジ、赤（悪）のスペクトラムで色分けします。透明なマテリアルが密集しているエリアを特定し、完全なモデリング（opaque）の改訂を行います。
PlayStation 5 (PS5) の I/O アーキテクチャと Nanite ストリーミングの関係
PlayStation 5 向けにゲームを開発する際、Nanite のポテンシャルを理論上の限界から現実世界のパフォーマンスの極限へと引き上げる唯一無二の要因は、コンソールの革新的な SSD ストレージおよびハードウェア圧縮・解凍（デコンプレッション）アーキテクチャです。Nanite の 128 三角形クラスターはオンデマンド読み込み（オンデマンドストリーミングページ）のロジックで設計されており、PS5 の I/O（入出力）階層はこの設計と完全に調和しています。
Kraken ハードウェア圧縮と Oodle Texture の統合
従来の PC システムや旧世代機（PS4、Xbox One）では、ディスクから読み込まれた圧縮データ（ZLIB などの汎用アルゴリズムによるもの）は一度 RAM に取り込まれ、その後メインプロセッサ（CPU）によって処理・解凍される必要がありました。数十億のポリゴンからなる Nanite クラスターの膨大なサイズは、カメラの移動ごとに毎秒ギガバイト（GB/s）単位の新しいデータストリーミングを要求するため、このソフトウェア解凍方式では PC や旧世代機において CPU がボトルネックとなり、ゲームメカニクス（AI、物理演算など）の処理ができなくなる事態を引き起こします。
ソニーは PS5 のハードウェアを設計する際、標準規格に固執せず、RAD Game Tools が開発した Oodle Kraken 圧縮アルゴリズムを処理できるように、シリコンレベルで専用のハードウェアデコンプレッサーブロック（hardware decompressor block）を I/O 複合体に統合しました。Kraken は、旧世代の ZLIB 形式と比較してデータをロスレス（無損失）の形で 29% より小さく圧縮できると同時に、解凍速度において 3〜4 倍効率的です。
PS5 の Kraken チップは、「Oodle Texture」ロスレス形式（BC7Prep などのテクスチャ圧縮最適化と併用）を使用することで、SSD の実効 5.5 GB/s の読み込み速度を乗数効果で増幅させ、毎秒平均 8〜9 GB、ピーク時には毎秒 17 から 22 GB に達する信じられないほどの帯域幅速度でのデータ転送を実現します。
CPU ボトネックの克服と帯域幅乗数
この I/O アーキテクチャが Nanite にとって持つ意味は非常に深遠です。次の表は、PS5 の圧縮技術が競合他社や旧世代機と比較して、どれほど大きな CPU 節約を実現しているかを要約しています。
圧縮ハードウェアおよびアルゴリズムの指標PS4 / 前世代機Xbox Series XPlayStation 5基本圧縮アルゴリズムZLIB（ソフトウェア指向）BCPack (ZLIB HW バリエーション)Oodle Kraken + Oodle Texture (カスタム HW)最大スループット速度（ピーク帯域幅）~100-200 MB/s~6 GB/s (SFS による実効)~22 GB/s平均スループット速度（平均帯域幅）< 100 MB/s~4.8 GB/s8-9 GB/s (Oodle 使用時 17 GB/s)プロセッサ（CPU）相当のパフォーマンス節約CPU に完全に負荷をかける~約 5 基の Zen 2 コア相当~約 9 基の Zen 2 コア相当
この表は明確に示しています。PS5 の I/O 複合体は、従来のコンピュータで SSD からデータを解凍するために正確に 9 基の独立した Zen 2 プロセッサコアが消費する労力を、単体で引き受けています。
Nanite がフレームごと（16 ms 以内）にカメラの新しい視点に合わせてディスクから何万もの新しいクラスター（ストリーミングページ）を要求する際、SSD から読み込まれたこのデータはハードウェアの Kraken チップを経由し、CPU を完全にバイパスして直接 RAM および GPU プールに供給されます。ゲーム開発者は、データが「間に合わない」（ポップイン）という恐怖なしに、Nanite の「Virtual Texturing for Geometry」（ジオメトリ向け仮想テクスチャ）の哲学を最大限に活用できます。Epic Games のエンジニアたちは、この巨大なポテンシャルを見据え、PS5 のこの独自の I/O 構造のために Unreal Engine 5 のコアローディングサブシステム（core I/O subsystems）を PS5 専用にゼロから再記述しました。
VRAM 管理とストリーミングプール（Streaming Pool）の最適化
PlayStation 5 は、16 GB 容量の超高速な統合（unified）GDDR6 メモリを搭載しています。しかし、PC アーキテクチャとは異なり、コンソールではメモリ制限が厳格かつ柔軟性のない（固定メモリ）構造になっており、仮想メモリのオーバーフローは許容されず、システムの直接的なクラッシュ（OOM - Out of Memory）を引き起こします。
Nanite が使用するメモリプール（ストリーミングプール）は、画面解像度に応じて幾何学的に増加します。Nanite は、三角形の識別子を格納するために画面サイズに正比例する可視性バッファ（Visibility Buffer）を使用します。解像度が 1080p から 4K に向上すると（ピクセル数が 4 倍になるため）、Visibility Buffer の VRAM ニーズも直接 4 倍になります。
PS5 プロジェクトで最適化を維持し VRAM を管理するために、「Nanite Streaming Pool」のサイズは開発者によって制限される必要があります。デフォルトのプールサイズは空のプロジェクトで 512 MB 前後で推移しますが、Nanite が多用される AAA プロジェクトでは、コマンドラインまたは .ini ファイル内（例: DefaultEngine.ini 内の ）で次のパラメータを設定する必要があります。
r.Nanite.Streaming.StreamingPoolSize = 2048
（シーンの負荷や他のシステムに応じて 2000〜3000 MB 前後）。このプールの予算が狭すぎると、遠方のオブジェクトの高詳細クラスターが間に合わず、Nanite はフォールバックモデルに落ち込みます。逆に広すぎると、Lumen サーフェイスキャッシュ（Surface Cache）、高解像度テクスチャ、およびオペレーティングシステム用の RAM が不足します。開発者は UE 5.7 とともに、コンソールの制限（通常 2〜4 GB のオーバー）を超える StreamingPoolSize の状況下で警告システムが稼働するようになることに気付くでしょう。
PlayStation 5 の開発要件とコンソール設定
Unreal Engine 5 を使用した PS5 プラットフォームへの開発プロセスは、Epic Games とソニーの緊密な協業により非常に洗練されたものになっていますが、プロジェクトのコンパイルと最適スピードでの動作を実現するためには、特定のソフトウェア開発キット（SDK）およびシステム構成に準拠することが必須です。
SDK バージョンとコンパイラフラグ
Unreal Engine の最新の 5.6 および 5.7 バージョンで PS5 ハードウェアのビルドを行う際に注意すべきハードウェアおよびソフトウェアライブラリの要件は以下の通りです。
サポートされる SDK およびシステムバージョン: PS5 開発環境の基本要件として、「Prospero SDK 11.00.00.40」（または高度なストレージシステム向けの SDK 12）および「システムソフトウェア 11.00.00.43」が指定されています。プロジェクト構成において（IntlNetwork SDK や Interhaptics などのサードパーティ製プラグインと作業する際）、バージョンの不一致はクラッシュの原因となります。
コンパイラ設定: コンパイル処理中には、ソニー独自のツールチェーンに加えて clang-cl が使用されます。Clang 19 における未定義動作（undefined behavior）や NaN（Not a Number）エラーを防ぐため、ソースコードは現在必須で -fhonor-nans フラグ付きでコンパイルされています。さらに、過去にクロスプラットフォームの問題を引き起こした -ffp-contract=off パラメータは、-ffast-math と競合するため PS5 コンパイラから削除されました。
標準ライブラリ（Stdlib）の移行: UE 5.7 とともに、PS5 向け C++20 標準ライブラリ（stdlib v2）のサポートが追加されました。開発者は、将来の互換性とパフォーマンス向上のために UEBuildPS5.cs または BuildConfiguration.xml 設定ファイルを介して StandardLibVersion = 'v2' の割り当てを行うことが強く推奨されます。
システム最適化設定: GPU 上のサンプラー（sampler）ステータスの蓄積を防ぐため、AgcRHI アーキテクチャに新しい LRU（Least Recently Used）キャッシュシステムが導入されました。この制限はデフォルトで r.Agc.MaxSamplerStates 4096 として設定されています。
60 FPS の目標に向けたスケーラビリティプロファイル
UE5 は、PS5 および Xbox Series X コンソールにおいてデフォルトの「Epic」品質レベルで 30 FPS の目標（1 フレームあたり 33.3ms）に合わせて構成されています。レイトレーシングや膨大なポリゴン負荷がかかる最新ゲームにおいて 60 FPS（1 フレームあたり 16.6ms）を目標とすることは、Nanite および Lumen のレンダリング解像度と品質に対して意図的な妥協を行うことを要求します。
PS5 でゲームを滑らかな 60 FPS 体験でリリースしたいスタジオは、エンジンのハードウェアレベルの DeviceProfiles.ini 設定において Lumen グローバルイルミネーション（GI）およびリフレクションシステムの品質を 60 FPS に適応させる「High」スケールに引き下げる必要があります。このプロファイルでは、ゲームは Temporal Super Resolution（TSR）でアップスケールされる前に、内部的に（internal resolution）1080p または 1440p 前後でレンダリングされます。
ゲームディレクトリ内の [ProjectName]\Platforms\PS5\Config\PS5DeviceProfiles.ini ファイルに直接、次の設定ブロックを追加する必要があります。
; Set Lumen GI and reflection quality to High, targeting 60 fps console budget
+CVars=sg.GlobalIlluminationQuality=2
+CVars=sg.ReflectionQuality=2
この設定は、Lumen の計算負荷をコンソールの限界に引き下げ、Nanite で処理される何百万ものポリゴンに 16.66ms 以内のフレームあたりの息継ぎの余地を残します。さらに、Nanite のパフォーマンスを向上させるために、TSR の細微ジオメトリ検出（Thin Geometry detection）機能を有効に保つことが重要です。
Lumen と Nanite の同期に向けた PS5 固有の最適化
Nanite システム単体は静的なジオメトリ描画のみを担当します。しかし、ゲームの視覚品質を決定するのは、Nanite 表面でバウンスしフォトリアルな影を生成するグローバルイルミネーション（GI）システムである Lumen です。両方のシステムが結合すると、PS5 ハードウェアはその限界まで酷使されます。
Lumen には、ディスタンスフィールド（Distance Fields）を使用するソフトウェアレイトレーシング（SWRT）と、直接三角形を計算するハードウェアレイトレーシング（HWRT）の 2 つの動作モードがあります。Nanite は、保持している複雑なジオメトリを、前述のフォールバックメッシュ（Fallback Meshes）を介して HWRT メカニズムに供給します。旧世代のエンジンバージョンでは 60 FPS のためにやむを得ず SWRT が推奨されていましたが、Unreal Engine 5.6 および 5.7 バージョンでは、コンソールハードウェア（特に PS5 の AMD RDNA2 ベースの RT コア）の負荷を軽減するための根本的な HWRT の改善が行われました。
1. ShortRangeAO の最適化: 近距離環境オクルージョン（Ambient Occlusion）の計算は、新しいノイズ除去装置（denoiser）の助けを借りて、現在半分の解像度（half resolution）で実行されています。この処理により、コンソールにおけるこのパスの速度が正確に 2 倍になります。 49
2. Far Field（遠方）Occlusion Only モード: 広大なオープンワールドにおいて、World Partition システムでロードされる非常に遠方の Nanite オブジェクトからのバウンス計算がシステムを圧迫する可能性があります。新しい r.LumenScene.FarField.OcclusionOnly 1 コマンドを使用することで、PS5 上での Lumen の遠方パフォーマンスが 50% 高速化されます。 49
3. Downsampled Screen Probe Gather: 環境光を画面に投影する Probe Gather パスにおいて、ピクセル間の統合サンプリング率を低下させること（r.Lumen.ScreenProbeGather.IntegrateDownsampleFactor）により、PS5 上の 1080p レンダリングシナリオで 0.3〜0.5 ms の時間を節約できます。 20 ディテールに若干のソフト化が見られますが、60Hz の予算に対してこのトレードオフは非常に理想的です。
4. Shader Execution Reordering (SER): HitLighting やレイトレース透過（ray-traced translucency）を使用し、多数の異なるマテリアルを持つ複雑なシーンにおいて、ハードウェアレベルでコマンドの再並べ替え処理を有効にする r.Lumen.HardwareRayTracing.ShaderExecutionReordering コマンドは、サポートされている RHI ユニットで高速化を提供します。 49
開発者は、シーン内の高い Nanite 最にもかかわらず PS5 のレンダリング制限に突き当たる場合、「stat gpu」プロファイルで HWRT のコストを測定し、必要に応じて影の計算を安価にするために指向性ライトで Virtual Shadow Maps（VSM）の代わりに従来の Shadow Maps に戻るシナリオをプロジェクトの初期段階（optimize early）でテストする必要があります。 25
戦略的結論と開発者の推奨事項
行われた詳細な分析に基づき、Unreal Engine 5 の Nanite アーキテクチャは、最新の GPU コンピュートシェーダー機能、ハードウェアレイトレーシング統合、および次世代データ圧縮アルゴリズムを融合させ、コンピュータグラフィックス業界に真の革命をもたらしています。ポリゴン数やドローコールのボトルネックをもはや障害ではなくするこのテクノロジーは、それに伴い異なるワークフロー（Assemblies、Voxelization）と厳格なメモリ予算の規律（Streaming Pools）をもたらしています。
PlayStation 5 プラットフォームでゲームを開発するテクニカルアーティストやエンジンプログラマーが考慮すべき最も基本的な戦略的発見事項は次のとおりです。
1. I/O の利点を正確かつ限界まで活用する: PS5 の独自の Kraken ハードウェアデコンプレッサーは、SSD を介して信じられないほどの I/O 帯域幅を提供します。開発者は、Nanite ストリーミングを制限する旧世代の手動 LOD 戦略から離れ、フィルム品質のオリジナルのソースメッシュ（source mesh）の使用に直接移行することが、システムの自然なフローにより適しています。
2. 透明性とオーアドローのコストを回避する: Nanite のアキレス腱である WPO（World Position Offset）ベースのアニメーションや Alpha Mask/Cutout の使用は、特に植生においてパフォーマンスのキラーとなります。UE 5.6 および 5.7 で導入された Nanite Voxels、Nanite Assemblies、および Nanite Skinning 機能は、PS5 における 60 FPS のオープンワールドの目標において、従来の草のモデリングに代わる主要な手法として採用されるべきです。モデルの最適化ではなく、ハイポリゴンであってもスムーズな「Opaque」ジオメトリへの移行が必須です。
3. 精密な VRAM バジェット作成を行う: PS5 の固定メモリ構造は、Nanite の可視性識別子（Visibility Buffer）および Lumen サーフェイスキャッシュによって急速に消費される可能性があります。StreamingPoolSize の制限は慎重に構築されるべきであり、4K のネイティブレンダリングスケーリングの代わりに Temporal Super Resolution（TSR）を伴う 1080p から 1440p の内部解像度の目標が、高い視覚品質と安定したフレームレートを統合するために使用されるべきです。
4. 定期かつ早期のプロファイル分析（Optimize Early）: 開発プロセスの終盤を待たずに、stat gpu、stat unit、および NaniteStats プロファイリングツールを積極的に追跡する必要があります。問題のある Raster Bins を作成するマテリアル構成を特定して結合し、CPU と GPU の間のステート変更を最小限に抑える必要があります。
Nanite は、魔法のパフォーマンス向上ツールではありません。逆に、その機能を正しく使用すればビジョンを制限せず、ルールを守らない場合（例えば過度にマスクされたマテリアルを使用する場合など）にはハードウェアの壁に激しくぶつかる非常に強力なエコシステムです。PS5 ハードウェアの専用 I/O アーキテクチャと Unreal Engine 5 のレンダリングイノベーションが同期して動作するとき、インタラクティブメディアの視覚的および容量的境界はかつてないほど拡大します。
*情報 : 画像は Google Gemini によって生成されました。