[Tokyo DevDays 26'] 開発効率化のための Zen 利用ベストプラクティス

開発効率化のための Zen 利⽤ベストプラクティス Epic Games Japan Lead Software Engineer, Developer Relations 鍬農 健⼆郎 Last update: Aug 26, 2026

UE5 から追加されたZenシリーズ 禅 /Zen/zen/[noun] : fundamentals; essentials; harmony; 完全に再設計されたアーキテクチャにより、アセットのクック、保 存、ロードを⾼速かつ効率的に⾏うことができる エレガントで調和の取れた流れが、待ち時間や中断を最⼩限に抑 えて仕事をするスペースを提供し、落ち着いた時間を過ごすこと ができる（ようなイメージ）

よくわからない ● ● ● そもそも現在動いているのか...？ なんとなく使っているけど有効活⽤できているか...？ 意図して使っているけど他のアプローチはあるか...？

Zen が解決するのは開発イテレーション 開発の待ち時間は次の3つ DDC Cook Deploy シェーダ‧メッシュ等 のキャッシュ再⽣成待ち アセットのコンバート 成果物の受け渡し待ち パッケージ作成 コンテンツのコピー待ち Zen これらの作業を効率化するサービス

Zen DDC Agenda Zen Cook Zen Streaming まとめ

Chapter 1 Zen DDC

DDC (従来の運用) の基本 ● ● DDC (Derived Data Cache) = 派⽣データをキャッシュし、次回以降で⾼速に起動 派⽣データの例: プラットフォーム別テクスチャ圧縮、コンパイル済みシェーダ、 変換済みメッシュ/オーディオ、Nanite/Lumenビルド結果 ローカルPC データ要求 ヒット：返却 ミス：⽣成‧保存 エディタ Local DDC

DDC (従来の運⽤) の派⽣ ● 様々な種類のDDC ○ Local DDC : ⾃機のキャッシュ ○ Shared DDC : 同⼀オフィス内などのチームで共有 ○ Cloud DDC : Shared DDC よりも広い範囲 (広域‧組織横断のDDC) オフィスPC ローカルPC Shared DDC チームの作業者 クラウドVM Local DDC エディタ Cloud DDC リモート作業者

Zen DDC (現在の運⽤) の基本 ● ● Zen DDC = 派⽣データを Zen Server がキャッシュし、次回以降で⾼速に起動 「⼤量の⼩さなファイル」から「常駐アプリが管理するデータベース」に置き換え ローカルPC DDC エディタ ローカルPC ZenDDC エディタ

Zen DDC (現在の運⽤) の派⽣ ● 様々な種類のZen DDC ○ Zen Local : Zen Server による⾃機のキャッシュ ○ Zen Shared : Zen Server による同⼀オフィス内などのチームで共有 オフィスPC ローカルPC Zen Shared チームの作業者 クラウドVM Zen Local エディタ Cloud DDC リモート作業者

Zen DDC の有効化 ● Zen Local：UE5.8ではデフォルト有効 BaseEngine.ini [Zen] AutoLaunch=true ● Zen Shared：追加でホストの設定が必要 BaseEngine.ini [StorageServers] Shared=(Host=None, Namespace="prj.ddc", EnvHostOverride=UE-ZenSharedDataCacheHost, CommandLineHostOverride=ZenSharedDataCacheHost, DeactivateAt=60)

例1: オフィスにあるビルドマシンに Zen Shared を配置 DefaultEngine.ini Shared=(Host="http://office-zen.example.local:8558", 例２：クラウド上に複数（2拠点, レイテンシが良い1台を利⽤） Zen Shared を配置 DefaultEngine.ini Shared=(Host="http://tokyo.example.com:8558;http://virginia.example.com:8558", 実際に使われる優先度は、 ● ● ● .iniファイル 環境変数 コマンドライン : Host="http://office-zen.example.local:8558" : UE-ZenSharedDataCacheHost="10.7.101.1:8558" : -ZenSharedDataCacheHost=None リモート作業者や接続不安定時はZenSharedを”None”で切り離すことも

Zen DDC と DDC はどう違う？ ボトルネックだった「ファイルシステム‧メタデータ操作」を排除し、通信をバッチ化 DDC (ファイル群) ZenDDC (バッチ+DB) OSメタデータ操作(1リクエスト=1ファイル)が集中 バッチRPC、DB化でメタデータ定義を回避 リクエスト .udd #1 open/stat/close リクエスト×8 既定バッチ .udd #2 open/stat/close .udd #3 open/stat/close .udd #4 open/stat/close ※ CID: Content ID, キャッシュの実データ Zen Server Record+CID Store

Zen DDC が保有するキャッシュデータ 共通の論理モデル→Zenの物理配置 FCacheKey Zen Server 内部 Bucket+Hash Record Store FCacheRecord 保存 Key→Record参照 CID Store 複数Value+Meta 内容アドレス Tiny/Small/Large 圧縮バッファ Hits/Miss/Writes 変わらない 変わった: 保存形式 Legacy: .uddファイル Zen: Record Store + CID Store

Zen DDC キャッシュ共有の仕組み エディタ Zen Local 派⽣データ要求 Engine Pak Local DDC Project Pak Zen Shared Shared DDC Cloud DDC Engine\Config\BaseEngine.ini [DerivedDataCacheGraphs] Default=(ProjectPak, EnginePak, ZenLocal, Local, ZenShared, Shared, Cloud)

Zen DDC キャッシュ共有の仕組み - Get (読み取り) Miss エディタ 派⽣データ要求 Zen Local Get Get Miss Miss Get Engine Pak Get Miss Get Project Pak Local DDC Hit Get Zen Shared Shared DDC Cloud DDC 順番に Get し、Miss したら Hit するまで次の層へ

Zen DDC キャッシュ共有の仕組み - Put (書き込み) エディタ 派⽣データ要求 Put Zen Local Engine Pak Put Local DDC Project Pak Put Zen Shared Put Shared DDC Put Cloud DDC Put 書き込み可能な層へ同時 Put

Zen DDC の効果 試⾏ エディタ起動 Map オープン PIE DDC 初回起動 1m21s 2m14s 20m46s DDC 2回⽬起動 17s 26s 1m18s 試⾏ エディタ起動 Map オープン PIE ZenDDC 初回起動 1m43s 2m26s 22m6s ZenDDC 2回⽬起動 15s 26s 54s 計測条件 効果 Unreal Engine: UE5.8.1 Project: CitySample CPU: AMD Ryzen Threadripper PRO 3995WX 64-Cores GPU: NVIDIA GeForce RTX 3080 DRAM: 256GB DDR4 Disk: AMD-RAID Array2 SCSI Disk Device DDC vs ZenDDC 単体では差が殆どない

DDC と⽐較して Zen DDC の効果は？ 効果が薄いケース ● 既定では DDC/Zen の両⽅に書く 効果があるケース ● 既定設定時は ZenDDC(Zen)+DDC(File System)へ の書き込みの⼆重作業 ● 初回起動の時間は DDC ではなくシェーダ コンパイルの割合が⼤きい 殆どはシェーダコンパイル、テクスチャ圧縮、 Nanite/VSM/ Distance Field ビルド ● DDC 取得が全体の⼀部しか占めていない 2回⽬の DDC 読み取りは OS ページキャッシュに 乗っており実質メモリアクセス チームの 共有場所がネットワークフォルダ DDCは各 Editor が共有フォルダを直接開くが、 Zen Shared はHTTP でまとめて要求 ● ⼩さなキャッシュの照会が多数ある リクエスト数がまとめて要求されるため、照会数 が多いほど効果的 ● 複数箇所からのリクエストが同時発⽣時 Zen Shared がキャッシュを⼀元管理しているた め、効率的に処理

CI で Zen DDC の充填 Zen DDC を効率的に利⽤するための⽅針 ● ● ● ● ● CIで夜間に Zen Shared を充填するのが最も費⽤対効果が⾼い DDCコマンドレットを全プラットフォーム分回してZenShared に書き込み 夜間定期 + エンジンアップグレードやシェーダバージョン更新の直後 開発者は読み取り専⽤、CI のみ書き込み、という構成も環境変数で可能 健全かどうかは、DDC.Summary の ZenRemoteGetHitPct を収集して確認

Zen Shared の キャッシュを充填 Engine\Binaries\Win64\UnrealEditor-Cmd.exe ^ D:\Proj\MyGame\MyGame.uproject ^ -run=DerivedDataCache ^ -fill ^ -TargetPlatform=Windows ^ -unattended ^ -nop4 ZenRemoteGetHitPct を CI で収集 Engine\Build\BatchFiles\RunUAT.bat BuildCookRun ^ -project=D:\Proj\MyGame\MyGame.uproject ^ -platform=Windows -clientconfig=Development ^ -cook -zenstore -skipstage -nop4 -unattended -buildmachine ^ -AdditionalCookerOptions="-CookStatsFile=D:\Temp\cookstats.json"

Zen DDC のベストプラクティス - Zen Local ● Zen Local のデータパスを⾼速SSDに設定 ○ クラウド同期フォルダ‧ネットワークドライブは厳禁 ○ 空き容量を常時確保しておく、最低でも100GB程度は望ましい ○ Engine.ini の DataPath でパス指定可能 ■ LocalDDCPath / ProjectLocalDDCPath で指定時はそちら優先 DefaultEngine.ini [Zen.AutoLaunch] DataPath=C:\DDC\Zen

Zen DDC のベストプラクティス - Zen Shared ● Zen Shared ホスト設定を.iniで配布するだけ、必要があれば以下を調整 ○ Zen Server は「データを定期削除」「接続が遅い場合は⾃動で無効化」 ■ ■ ■ ■ --gc-cache-duration-seconds 1209600 --gc-interval-seconds 21600 --gc-low-diskspace-threshold 2147483648 DeactivateAt=60 : 14⽇経過で削除 : 6時間毎に削除 : 空き2GBで強制削除 : 遅延閾値(ms)超過で接続無効化 DefaultEngine.ini [Zen.AutoLaunch] ExtraArgs=--http asio --gc-cache-duration-seconds 1209600 --gc-interval-seconds 21600 --gc-low-diskspace-threshold 2147483648 --cache-bucket-limit-overwrites --quiet --restrict-content-types --allow-external-oidctoken-exe=false [StorageServers] Shared=(Host=”10.7.101.1:8558”, Namespace="ue.ddc", EnvHostOverride=UE-ZenSharedDataCacheHost, CommandLineHostOverride=ZenSharedDataCacheHost, DeactivateAt=60)

Zen DDC のベストプラクティス - 健全化 指標の⽬安 良好 要調査 ZenLocal の Hit% 95%以上 80%未満 ZenLocal/Zen Sharedの Latency 1ms未満 / 20ms以下 10ms超 / 60ms超 File System の Write (FS未使⽤時) 0 0以上

Chapter 2 Zen Cook

Cook (従来の運⽤) の基本 ● ● Cookの基本処理は、依存アセットの検索‧オープン‧保存の繰り返し 出⼒先はディスク上で、出⼒は Loose Files (.uasset/.uexp/.ubulk) Cooker ディスク パッケージ毎に1-3を繰り返し Loose Files を保存 1.検索 2.ロード 3. 保存 依存関係を辿る UPackageロード ファイル書き出し Commit 以降⼯程は、このディスク上のファイルを前提にする Package→Deploy→Launch では⼤量のLoose Files をコピー‧再配置 .uasset .uasset .uasset .uasset

Zen Cook (現在の運⽤) の基本 ● ● ● 基本的な Cook 処理は同じ 出⼒先は Zen Server で、出⼒は Oplog (Cook済みアセット情報) ディスク上に ue.projectstore (接続情報を持つ.jsonファイル) Cooker Zen Server パッケージ毎に1-3を繰り返し Oplog を保存 1.検索 2.ロード 3. 保存 依存関係を辿る UPackageロード ファイル書き出し Commit ディスク Project Store を保存 .json 以降⼯程は、このディスク上のファイルを前提にする Package は Oplog から コンテナファイルを作成、Zen Streaming は実機が HTTP でチャンクを取得

Oplog (operation log) とは Zen Server Oplog を保存 ● ● ● ● ● Zen Server が持つ ”Cook済みアセットの格納庫” で実質ここに「Cook済みデータ」がある 「1 uasset = 1ファイル」ではなく「IoStore 向け に分解されたチャンク」として保存 パッケージ単位で載るもの ○ PackageData：本体チャンク ○ BulkData：.ubulk 等 ○ 追加ファイル情報 ○ PackageHashes：増分判定‧整合性 ○ その他... Incremental Cook‧Snapshot の⼟台 Editor の View Store から閲覧可

Project Store とは Zen Server Oplog を保存 ● ● ● ● Oplog の参照先情報を格納した JSON ファイル Oplog が本体、ue.projectstore は案内図 実機や Package は Project Store を読んで、どの zenserver のどの Oplog を開くかを決める Cook 開始時に作成、Cooked/StagedBuilds に保存 Disk ue.projectstore を保存 ue.pr ojects tore

Zen Cook の有効化 ● プロジェクト設定 (UE5.8からデフォルト有効) BaseGame.ini [/Script/UnrealEd.ProjectPackagingSettings] bUseIoStore=True bUseZenStore=True ● コマンドライン/UAT -ZenStore (無効化時は -SkipZenStore)

Zen Cook の効果 Cook出⼒ 試⾏ Cook Mode 時間 Loose Files Cook 初回 FullCook 785.7s Cook出⼒ 試⾏ Cook Mode 時間 Zen Server Oplog Zen Cook 初回 Full Cook 788.7s 計測条件 効果 Unreal Engine: UE5.8.1 Project: CitySample CPU: AMD Ryzen Threadripper PRO 3995WX 64-Cores GPU: NVIDIA GeForce RTX 3080 DRAM: 256GB DDR4 Disk: AMD-RAID Array2 SCSI Disk Device Cook vs ZenCook 単体では差が殆どない

Cook と Zen Cook ではどう違う？ Zen Cook ⾃体の速度は Cook と変わらない、後⼯程も含むトータルで⾼速化 観点 Cook Zen Cook 出⼒単位 ファイル チャンク 未変更データ 毎回書き出す 送らない ⼤きいデータ ソケット経由 ソケットを介さない 圧縮 書き込み時 並列タスクで先に実施 成果の形 後⼯程で変換 Cook時点でIoStoreのフォーマット Zen Cook における最⼤の強み（次ページ以降で説明） Incremental Cook Snapshot 未変更パッケージのCook処理を省略 過去のCook成果を起点に増分でCookを開始

Incremental Cook とは？ ● 変更されたアセットのみを再Cookし、 Cook 時間を短縮する仕組み ● 従来の -iterativecooking（変更アセットの み）より堅牢な -cookincremental（変更+ 依存関係）がUE5.8でデフォルトに ● エディタ設定で有効化、.iniファイルで以 前の Legacy Cook に戻すことも可能 ● Epic は CI でも Incremental Cook を活⽤ Editor.ini の [CookSettings] ; This mode was not as robust as the new Incremental Cook, because it did not handle changes to ; c++ serialization, changes to non-package files, or hidden dependencies undeclared to the AssetRegistry LegacyIterative=false

Incremental Cook の有効化 ● .ini 設定 DefaultEditor.ini [CookSettings] LegacyIterative=False (UE5.8ではdefault=False) CookIncrementalDefaultIncremental=True ● コマンドライン/UAT ‧強制的にIncremental Cook実⾏ -CookIncremental (または -forcerecook=false) ‧UATで実⾏時 -iterative (設定次第で -iterativecooking(LooseFiles)/-cookincremental(ZenStore)が実行) ● Project Launcher

Incremental Cook の処理フロー Zen Server / Oplog Cooker / UCookOnTheFlyServer 1.検索 必要なパッケージを列挙 Read 2.前回の鍵を読む attachment meta.cook.artifacts =前回のStoreKeyと依存 StoredKeyをRead 3.今回の鍵を計算 CurrentKeyを計算 4.判定 HashKeyMatch Key+依存の変更なし？ なし Cook済み本体 あり ⼀致 → skip 不⼀致/なし → recook Open/Save/Commitなし Open/Save/Commit実⾏ 次のパッケージへ Commit PackageData / BulkData (IoStoreチャンク)

Zen Cook (Incremental Cook) の効果 Cook出⼒ 試⾏ Cook Mode 時間 (s) Cook 初回 FullCook 785.7 Cook 2回⽬ Iterative Cook 53 試⾏ Cook Mode 時間 Zen Cook 初回 Full Cook 788.7 Zen Cook 2回⽬ Incremental Cook 62 Loose Files Cook出⼒ Zen Server Oplog 計測条件 効果 Unreal Engine: UE5.8.1 Project: CitySample CPU: AMD Ryzen Threadripper PRO 3995WX 64-Cores GPU: NVIDIA GeForce RTX 3080 DRAM: 256GB DDR4 Disk: AMD-RAID Array2 SCSI Disk Device ‧Cook vs ZenCook 単体では差が殆どない ‧反復 Cook はいずれも10倍以上早くなる ‧反復 Cook 実施時もレガシーに負けることがある → 依存関係正しく検証する処理が追加されるため → 速度はやや劣るものの、反復の正確性は⾼い

Snapshot とは？ ● Cookの「基点」を CI から配布、Cook済みアセットを共有する仕組み ○ Snapshot なし：Cook の基点は⾃分が前回Cookした結果 ○ Snapshot あり：CI が公開した Cook 結果を基点に Incremental Cook で短縮 ● Snapshot は Import / Export することで共有可能 ○ Export：ZenServer上のデータを FileServer/他ZenServer/Cloud 等へ出⼒ ○ Import：descriptor を⾒て Zen Local へ取り込む ● 実機確認における効果が有⽤なケース ○ 効果⼤：新規ワークスペース、久しぶりのCook、CIの新規エージェント ○ 効果⼩：毎⽇Cookしている⼈には差が⼩さく、効果も薄い

Snapshot を利⽤した検証構成 クラウド ① CL同期とCook Cook済みデータ充填 ② Snapshot Export 正本‧履歴‧開発者⽤ Cloud DDC ファイルサーバ Horde ④ Snapshot Import ③ Snapshot Export ローカル検証⽤ オフィス共通検証⽤ ローカルPC エディタ Zen Local オフィスPC Zen Shared

Snapshot を利⽤した検証フロー ● 基本：CI が Cook して Snapshot を Export → 開発者が Snapshot を Import ○ CI 成果の Oplog を保存、Oplogを配布して利⽤ ○ BuildGraph : ZenExportSnapshot / ZenImportSnapshot ● ケース1：特定CLの成果を保存‧共有し、検証を⾼速化 ○ [CI] CL を同期 → CL でCookして Snapshot Export ○ [開発者] CL を同期 → CL の Snapshot をImport → ZenStreaming で起動 ● ケース2：Cook のたびに公開し、全員の Incremental Cook の基点にする ○ SnapshotBaseDescriptorFile を指定すれば差分 Export も可能

例：CIから Zen Shared へ Export する BuildGraph
<?xml version='1.0' ?>
<BuildGraph xmlns="http://www.epicgames.com/BuildGraph" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.epicgames.com/BuildGraph ../Schema.xsd">
<Option Name="ProjectFile" DefaultValue="_Unknown_" Restrict=".+" Description="Path to the .uproject"/>
<Option Name="TargetPlatform" DefaultValue="Windows" Restrict=".+" Description="Cook platform to export"/>
<Option Name="DestinationZenHost" DefaultValue="http://10.7.101.29:8558" Restrict=".+" Description="Shared Zen
host URL"/>
<Option Name="DestinationIdentifier" DefaultValue="cl-$(Change)" Restrict=".+" Description="Oplog identifier.
Defaults to cl-&lt;P4 changelist&gt;."/>
<Error Message="No project file specified. Pass -project=&lt;path.uproject&gt;." If="'$(ProjectFile)' ==
'_Unknown_'"/>
<Agent Name="Export Agent" Type="Win64">
<Node Name="Publish Snapshot $(ProjectName) $(TargetPlatform)">
<ZenExportSnapshot
Project="$(ProjectFile)"
Platform="$(TargetPlatform)"
DestinationStorageType="Zen"
DestinationZenHost="$(DestinationZenHost)"
DestinationIdentifier="$(DestinationIdentifier)"
SnapshotDescriptorFile="$(ProjectDir)/Saved/Snapshots/$(TargetPlatform).json"/>
</Node>
</Agent>
<Aggregate Name="PublishSnapshot" Requires="Publish Snapshot $(ProjectName) $(TargetPlatform)"/>
</BuildGraph>

例：UAT からの Export
Engine\Build\BatchFiles\RunUAT.bat BuildGraph ^
-Script=Engine\Build\Graph\PublishSnapshot.xml ^
-Target=PublishSnapshot ^
-project=D:\Proj\MyGame\MyGame.uproject ^
-set:TargetPlatform=Windows ^
-NoP4

例：CIが出した Snapshot を Zen Local へ Import する BuildGraph
<?xml version='1.0' ?>
<BuildGraph xmlns="http://www.epicgames.com/BuildGraph" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.epicgames.com/BuildGraph ../Schema.xsd" >
<Option Name="ProjectFile" DefaultValue="_Unknown_" Restrict=".+" Description="Path to the .uproject"/>
<Option Name="DescriptorFile" DefaultValue="_Unknown_" Restrict=".+" Description="snapshot.json produced by CI"/>
<Agent Name="Import Agent" Type="Win64">
<Node Name="Import Snapshot">
<ZenImportSnapshot Project="$(ProjectFile)" SnapshotDescriptorFile="$(DescriptorFile)"/>
</Node>
</Agent>
<Aggregate Name="ImportSnapshot" Requires="Import Snapshot"/>
</BuildGraph>

例：UAT からの Snapshot を Import
Engine\Build\BatchFiles\RunUAT.bat BuildGraph ^
-Script=Engine\Build\Graph\ImportSnapshot.xml ^
-Target=ImportSnapshot ^
-project=D:\Proj\MyGame\MyGame.uproject ^
-set:DescriptorFile=\\fileserver\CookedSnapshots\main\latest\Windows\snapshot.json ^
-NoP4

Zen Cook のベストプラクティス ● Zen Store を有効化した環境を準備 ● 開発者とCI で Incremental Cook を活⽤ ○ Cook 時間を短縮することで待ちを減らし試⾏を増やす ● 定常的に Snapshot を配布 ○ 問題発⽣時に特定のCLに同期して迅速に検証して対処 ○ QAは特定の環境で検証しやすい ● Zen Shared を利⽤ ○ 全CLの oplog を貯め続けることで検証を⾼速化 ○ ストレージ容量には注意

Chapter 3 Zen Streaming

実機確認（従来の運⽤）の基本 ● ● アセットCookして実機で確認するためのワークフロー 「実機での反復チェック」⽤途では転送コストが⽬⽴ち、待ち時間が⻑い Cook On The Fly 要求毎に都度Cookして供給 待ち：Cook+転送 起動 要求 都度Cook 都度転送 表⽰ 全件Cook 成果を配置 Copy Launch 表⽰ 全件Cook Package Deploy Launch 表⽰ Cook By The Book 事前にCookし配置して起動 待ち：Cook+コピー Package パッケージ作成 待ち：Cook+Pak+Deploy

Zen Streaming の基本（現在の運⽤） ● ● ● ● 基本的には Cook → Package → Deploy → Launch という流れは同じ 軽量なパッケージ Package/Deploy ○ 実⾏ファイル + Project Store のみの軽量版パッケージを作成/配置 起動時に アセットを Zen Server から Streaming ○ アプリケーションが HTTP で Zen Server からチャンクを取得 2回⽬の起動はクライアントキャッシュ（4GB）が効くため⾼速な起動が可能 ○ STORAGE_SERVER_PLATFORM_CACHE_SIZE_KB 、プラットフォーム依存 ○ 同⼀セッションはメモリ上に残るため同様に⾼速 Zen Streaming Zen Server からの転送 Incremental Cook 軽量な Package 軽量な Deploy Launch 表⽰

Zen Streaming（現在の運⽤）のフロー ⾼速 ローカルPC ② アプリケーション Deploy 実機デバイス 実⾏バイナリ+ProjectStore エディタ ① Incremental Cook oplogを充填 アプリ ケーション ③ アセット参照 Zen Server Serverからストリーミング ⾼速

Zen Streaming の有効化 ● プロジェクト設定 (UE5.8ではデフォルト有効 / Zen Cook 利⽤前提) ● BaseGame.ini ● ) [/Script/UnrealEd.ProjectPackagingSettings] bUseZenStore=True bUseIoStore=True ● コマンドライン/UAT -zenstore -cook -stage -deploy(-pak なし) ● Project Launcher

Zen Streaming の効果 時間 (s) 起動⽅法 Build Cook Stage Deploy Launch Total Development Package (Project Launcher) 4.0 175.3 115.5 188.7 43.0 526.5 Zen Streaming Incremental (Project Launcher) 3.5 68.2 2.1 0.2 42.0 116.0 計測条件 効果 Unreal Engine: UE5.8.1 Project: CitySample CPU: AMD Ryzen Threadripper PRO 3995WX 64-Cores GPU: NVIDIA GeForce RTX 3080 DRAM: 256GB DDR4 Disk: AMD-RAID Array2 SCSI Disk Device ‧Stage, Deployの重い⼯程がほぼスキップされるので 早くなる、この結果だけ⾒ると5倍近く早い

Zen Streaming の効果 時間 (s) 起動⽅法 Build Cook Stage Deploy Launch Total Zen Streaming Incremental (Project Launcher) 3.5 68.2 2.1 0.2 42.0 116.0 Quick Launch (Editor) 2.7 788.7 2.0 0.2 42.2 835.8 Quick Launch Incremental (Editor) 2.6 68.1 1.9 0.2 42.3 115.1 計測条件 効果 Unreal Engine: UE5.8.1 Project: CitySample CPU: AMD Ryzen Threadripper PRO 3995WX 64-Cores GPU: NVIDIA GeForce RTX 3080 DRAM: 256GB DDR4 Disk: AMD-RAID Array2 SCSI Disk Device ‧ZenStore=True の場合、Quick Launch は Zen Streaming で起動する ‧Quick Launch時は設定 で Incremental Cook を有 効にすると⾼速（無効時はFull Cook、これで同等)

Project Launcher の Content Scheme

Project Launcher の Content Scheme Scheme データの置き場 起動時の読み⽅ UAT Pak Files 提出に近い実機確認 Stage上の .pak /.ucas /.utoc 本体（または Stage）のコンテナ -cook -pak -iostore -stage -deploy Zen Streaming 反復確認 zenserver oplog HTTP でチャンク取得 -zenstore -cook -stage -deploy Zen Pak Streaming 既にPakがある反復確認 既存 Pak + PC の Stage を share ローカル Pak + /ws オーバーレイ -skipcook -skippak -ZenWorkspaceSharePath= Development Package 提出に近い実機確認 開発⽤パッケージ パッケージをDeploy+Launch -package Submission Package 提出⽤ ストア提出⽤パッケージ / パッチ 提出物として出⼒ Shipping + release/patch/DLC Loose Files (legacy) ZenStore=OFF時のみ Saved/Cooked の個別ファイル ディスク or FileServer Zen Store なし の CBTB Cook On The Fly その場で Cook 必要時にネットワーク転送 -cookonthefly + FileServer Use Current Staged Build 既存の StagedBuilds 再 Cook / 再 Stage しない -prestaged

Zen Pak Streaming の利⽤ ● コンテナファイル（.pak、.ucas、.utoc）をベースとして、差分のみを Zen Streaming による上書きをする機能 ○ ベースビルドが既にあり、差分だけ何度も確認したいケースで有⽤ ○ 全体をZenから読むか、Pakベース + 差分オーバーライドか Zen Streaming Zen Pak Streaming 参照 参照 参照 .toc Zen Server アプリケーション コンテナファイル Zen Server アプリケーション

Zen Pak Streaming のイメージ ローカルPC ② アプリケーション Deploy 実機デバイス 実⾏バイナリ+projectstore ① Pakファイル作成 コンテナファイル エディタ ⑤ フォールバック WSになく実機にあれば参照 アプリ ケーション .toc ④ 取得 WSもあればチャンク取得 Zen Server ③ アセット参照 Serverからストリーミング .toc

● Zen Pak Streaming をUATから実⾏時に有効化 Engine\Build\BatchFiles\RunUAT.bat BuildCookRun ^ -project=D:\Proj\MyGame\MyGame.uproject ^ -TargetPlatform=Win64 -skipbuild -skipcook -skippak -stage -deploy -run ^ -ZenWorkspaceSharePath="D:\Proj\MyGame\Saved\StagedBuilds\Windows" ● Zen Pak Streaming をProject Launcherから実⾏時に有効化

Zen Streaming のベストプラクティス ● デバイスとの接続は有線で、⾼速アダプタの利⽤を推奨 ● 初回ロードはネットワーク RTT/帯域に依存 ● コード‧コンテンツ変更時のイテレーションに最適 ○ プロファイリング、Shipping ビルド、デバイスがリモートの場合は向かない ● Zen Streaming は参照する Zen Server を指定可能 ○ ローカルに Zen Server が無い場合や、CIが作成した Oplog ベースで確認した いケース（QAテスト等）では、Zen Shared を参照して確認も可能

まとめ

Zen DDC Zenをフル活⽤した構成 Zen Cook Zen Streaming クラウド Horde 夜間ビルド 定常ジョブ ローカルPC Import Export DDCFill Cloud DDC File Server Cloud DDC Zen Shared Snapshot Sharedの上流 DDCハブ 当⽇Oplogの配信先 Import Import Oplog DDC Zen Shared Editor DDCハブ‧当⽇Oplogの配信先 ローカルPC リモート 開発者 オフィス DDC/Cook ローカルPC DDC ローカルPC DDC Zen Local DDC+Oplog Streaming 実機 Zen Streaming で起動 開発者 Editor Editor ローカルPC ローカルPC DDC/Cook QA DDC/Cook Zen Local Zen Local DDC+Oplog DDC+Oplog Streaming Streaming 実機 実機 Zen Streaming ローカル起動 当⽇のOplogで Zen Streaming Streaming

Thank