[Game Developers Meeting Vol.66] UEモバイルゲーム開発の最前線

Game Developers Meeting Vol.66 UEモバイルゲーム開発の最前線 グラフィックス‧アセット配信‧新しいバージョン管理システム「Lore」 Epic Games Japan Lead Software Engineer, Developer Relations 鍬農 健⼆郎 Last update: Sep 25, 2026

⾃⼰紹介 鍬農 健二郎 Epic Games Japan Lead Software Engineer, Developer Relations 2017年7月にEpic Games Japanへ入社 Unreal Engine のテクニカルサポートに従事 コンソール、ネットワーク、バックエンドの技術を主に担当 X: @donbutsu17

Unreal Engine 5 を ご存じですか？ 使っていますか？

Unreal Engine を採⽤された最近のリリースタイトル 公式X (@UnrealEngineJP) で随時採⽤タイトルを紹介中

UE = ハイエンドPC /コンソール向け というイメージ

UEでモバイルゲームは作れる？

国内UEモバイルタイトル eFootball 実況パワフルサッカー スペースペンギンズ 修羅道 / SHURADO VARIOUS DAYLIFE THE LAST REMNANT Remastered エンゲージソウルズ エヴァンゲリオン バトルフィールズ Life is Strange Bloodstained: Ritual of the Night Mobile OCTOPATH TRAVELER ⼤陸の覇者 聖剣伝説3 TRIALS of MANA FINAL FANTASY VII THE FIRST SOLDIER HYKE:Northern Light(s) 8番出⼝ Mobile etc… トルネコの⼤冒険 不思議なダンジョン ちょっとステキなリマスター ファンタジーライフi グルグルの⻯と時をぬすむ少⼥

国外UEモバイルタイトル Fortnite HIT Lineage 2: Revolution PUBG MOBILE ODIN: Valhalla Rising MARVEL Future Revolution Ni no Kuni: Cross Worlds Tower of Fantasy Wuthering Waves / 鳴潮 Infinity Nikki Carmen Sandiego The Seven Deadly Sins: Origin Game of Thrones: Kingsroad etc… NTE:Neverness to Everness MONGIL:STAR DIVE

最近の傾向として、 マルチプラットフォーム展開が増加

UEマルチプラットフォームモバイルタイトル

モバイルも⾼い描画品質や⼤規模コンテンツが求められる 単にPC/Console向けゲームを縮⼩すれば良いわけではない

本⽇のテーマ グラフィックス‧アセット配信‧バージョン管理

1. グラフィックス アジェンダ 2. アセット配信 3. バージョン管理 4. まとめ

Chapter 1 グラフィックス UE5のグラフィックスはモバイルでどこまで使える？

モバイルでも「⾼品質」 が前提になってきた PC + Mobile / UE5 Open World

PC/Console のコンテンツをそのまま動かせる？ PC / Console Mobile ⾼性能な描画 バッテリーと発熱 ⼤きなアセット 安定した電源と冷却 ≠ 帯域 端末差 PC/Console と Mobile には動く⼟台が異なるため、そのままは動かせない

モバイル端末での制約 演算 CPU / GPU ピーク性能だけではない CPU側の描画関連処理も制約 メモリ 容量 / 帯域 容量だけではない 転送量とテクスチャ読み出し 電⼒ バッテリー / 発熱 ⻑時間プレイでの 発熱とクロック低下を考える 端末差 SoC / GPU / OS / 解像度 Mobile という単⼀クラスはない 重要なのは「最⾼画質を決める」より先に「最低保証ラインを決める」こと

モバイル開発で考慮すべき端末・SoCの多様性 iPhone Android 限定されたSoC / GPU構成 多数のSoCベンダー / GPU構成 Apple / iPhone : A20 Pro, A19 Pro, A19, A18 Pro... Qualcomm : Snapdragon (8 Elite Gen 5, Gen3, ~) iPadやMacbook : M5, M4, M3, M2, M1 ~ Mediatek : Dimensity (9500, 9400, ~) Google : Tensor (G6, G5, G4, G3, ~) Samsung : Exynos (2600, 2500, ~) UNISOC : Tiger (T9300, ~) … Target Deviceを定義しなければ、性能‧品質の基準を決められない → 先に最低保証と⽬標端末を決める

UEでの基本的な設定⽅針 ‧High、Mid、Lowといったプリセット設定を⽤意 ‧Device Profile(.iniファイル)で各機種GPU向けにプリセットを含む設定が可能 ※細かい型番は正規表現で対応 .\Engine\Config\BaseDeviceProfiles.ini

モバイル開発で決めておくと良い項目 ● 最低保証端末 どの端末まで対応するか、端末の性能、メモリ容量、OS / API ● ⽬標 fps 30fps / 60fps、安定して出したいfps、重い場⾯での最低ライン、発熱時の維持 ● 解像度 画⾯解像度、内部解像度、解像度の⾃動調整、アップスケール⽅式 ● 品質段階 画質の段階分け、影、テクスチャ、エフェクト、表⽰距離 ● 機能セット ライティング、影、反射、エフェクト、ポストプロセス ● 描画パス Forward / Deferred、Mobile向け設定、⾼機能設定、HDR / LDR

「レンダラー選択」は重要な選択 ⽬標端末 フレーム予算 機能セット レンダラー 選択

UE5モバイルで利⽤可能なレンダラー モバイル フォワード モバイル ディファード デスクトップ レンダラー フォワード形式のレンダラー ディファード形式のレンダラー 実験的 (Android) / ベータ機能 (iOS) 軽量化のため⼀部の機能が制限 モバイル向け(タイルベースのGPU) に軽量化されているディファードレ ンダラーで、フォワードでは利⽤で きない描画機能を利⽤できる PC版で表現されているような描画を 実現するためのレンダラー ハイスペックな端末を必要とする GLES3.2(Android) Vulkan(Android) Metal(iOS)

UE5モバイルで利⽤可能なレンダラー モバイル フォワード モバイル ディファード デスクトップ レンダラー フォワード形式のレンダラー ディファード形式のレンダラー 実験的 (Android) / ベータ機能 (iOS) 軽量化のため⼀部の機能が制限 モバイル向け(タイルベースのGPU) に軽量化されているディファードレ ンダラーで、フォワードでは利⽤で きない描画機能を利⽤できる PC版で表現されているような描画を 実現するためのレンダラー ハイスペックな端末を必要とする モバイルに特化した設計のレンダラー GLES3.2(Android) Vulkan(Android) Metal(iOS)

モバイルフォワード vs ディファード デフォルトでカリング r.Forward.MaxCulledLightsPerCell = 8 モバイルフォワード ● ● ● ● ベースが軽量 機能拡充が⾏われており制限は減ってきている ローカルライトも使⽤可能に（多い場合はDeferred） ベイクしたライティングはフォワードの⽅が有利 モバイルディファード ● ● ● タイルベースGPUに最適化されたディファード ライトが多数使える GBuffer活⽤ どちらも開発‧最適化を継続、必要とする要件やパフォーマンスに応じて選択

モバイル向けレンダラーの機能強化 Shadow機能の強化 Inset Shadow TemporalAAの最適化と既定化 Screen Space Shadow 0 : No AA Single Layer Waterの対応 Mobile Deferred New Mobile Deferred 2 : TemporalAA モバイル向け簡易GI (Diffuse Ambient Capture)

レンダラーの選択 ● コンテンツ次第 ● 使いたい機能による ● 各機能が負荷調整できるようにパラメータを多数⽤意 いずれにしても調整次第 サポート対象のレンダリング機能 https://dev.epicgames.com/documentation/unreal-engine/mobile-rendering-features-in-unreal-engine

• https://dev.epicgames.com/documentation/unreal-engine/mobile-rendering-features-in-unreal-engine

ではハイエンド描画機能は モバイルで利⽤できるか？

ハイエンド描画機能は Console/PC と違い機能に制限 機能 PC/Console Mobile Renderer Desktop Renderer Mobile での代替 Nanite 〇 ✕ ▲ LOD / HLOD / Culling オブジェクトの数 ⼀部端末のみ実験的 ※1 Lumen 〇 ✕ ▲ ⼀部端末のみ実験的 ※2 Baked Lightmap + 必要な動的ライト Diffuse Ambient Capture VSM 〇 ✕ ✕ CSM / Contact Shadows Precomputed Shadow MegaLights 〇 ✕ ✕ ライトの数 ローカルライトのカリング Hardware RT △ ✕ ▲ 使わない SSR または Reflection Capture 対応GPUのみ ※1： iOS SM6のみ ※2：Android SM5 / iOS SM6のみ 出荷前提ではない

NTE: Neverness to Everness Hotta Studio / UE5 / PC‧PS5‧Mobile 注⽬ポイント ハイエンド描画 モバイル向け実装の要点 最適化 ‧⾼密度な都市型オープンワールド を、PC‧PS5‧モバイルで同時展開 ‧モバイル版も“劣化版”ではなく、 次世代感のある都市表現を維持 ‧Lumen / Nanite / Virtual Shadow Maps を採⽤ ‧World Partition+PCGで都市構築 ‧モバイルでは Mobile Deferred Shading を活⽤ ‧Octree Frustum Culling ‧Cluster-based Light Culling ‧GPU-driven Instancing Culling ‧Niagara GPU Particles ‧GPU Scene ‧World Partition ‧都市型Open Worldでは計算量だ けでなく、帯域‧外部メモリアクセ ス‧発熱が⽀配的 ‧Custom UE5 Mobile Deferred Rendering でパイプラインを調整 ‧Adreno Tile Memory / Render Pass最適化で帯域負荷を軽減 ‧SGSR2 + AFME2、Occlusion、 Adaptive Performanceを活⽤ 技術的な流れ ⾼密度な都市型Open World 帯域‧発熱‧GPU負荷 Custom Mobile Rendering Upscaling / Sustained Perf 多数の建物‧⼈‧⾞‧ライト‧FX Memory traffic / Thermal / Compute Deferred最適化 + Tile Memory + Culling SGSR2 / AFME2 / Adaptive control ハイエンドモバイルグラフィックスは“機能を全部有効化”することではない カスタムなレンダラーを使⽤して独⾃の描画パイプラインを設計 Crafting the urban open world of NTE: Neverness to Everness with UE5 across PC, PlayStation 5, and mobile UE5 on Mobile at Scale: Turbocharging Neverness to Everness on Snapdragon

• https://www.unrealengine.com/developer-interviews/crafting-the-urban-open-world-of-nte-neverness-to-everness-with-ue5-across-pc-playstation-5-and-mobile
• https://www.youtube.com/watch?v=jogymfpx7uk

MONGIL: STAR DIVE Netmarble Monster / UE5 / PC‧Mobile 注⽬ポイント グラフィックスの焦点 ライティング∕演出 最適化 ‧サブカルチャー調のビジュアル を、リアルタイム性能と両⽴させる UE5タイトル ‧ゲームプレイだけでなく、イン ゲームのリアルタイム演出‧シネマ ティックも重視 ‧Shader Optimization ‧GPU-based Performance Enhancement ‧Visual System Architecture ‧数理的アプローチで表現品質とリ アルタイム性能を両⽴ ‧Stylized 描画に対する最適化 ‧Dynamic Lighting Setup による リアルタイムSequence Lighting ‧Sequencer を軸に Lighting / Animation / FX を連携 ‧インゲーム演出をリアルタイムで 成⽴させる制作フロー ‧モジュラー環境でのライティング 調整と再利⽤性 ‧Stylized作品では“シェーダー設 計”と“⾒た⽬の⼀貫性”が中⼼ ‧単純な軽量化ではなく、アート⽅ 向性を守るGPU最適化が重要 ‧描画品質‧ライティング‧演出を 同⼀リアルタイム基盤で扱う 技術的な流れ Stylized Art Target Shader / Lighting Design GPU Optimization Real-time Cinematic キャラクター‧世界観‧マテリアル 表現の⼀貫性を先に設計 描画負荷を制御しリアルタイム化 ゲーム内演出まで同じ基盤で実現 Stylizedの負荷‧最適化を考慮した初期設計 シェーダー、ライティング、演出ワークフローを最初から⼀体で設計 Subculture Rendering and Calculations in Mongil: Star Dive | Unreal Fest Orlando 2025 Talks And Demos: Subculture Rendering and Calculations in Mongil: Star Dive | Unreal Fest Orlando 2025 언리얼 페스트 서울 2025 DAY1 몬길: STAR DIVE 다이내믹 라이팅 세팅을 활용한 리얼타임 시퀀스 라이팅

• https://dev.epicgames.com/community/learning/talks-and-demos/abMX/unreal-engine-subculture-rendering-and-calculations-in-mongil-star-dive-unreal-fest-orlando-2025
• https://forums.unrealengine.com/t/talks-and-demos-subculture-rendering-and-calculations-in-mongil-star-dive-unreal-fest-orlando-2025/2674021
• https://epiclounge.co.kr/contents/replay_view.php?idx=1396

Infinity Nikki Infold Games / UE5 / PC‧PS5‧Mobile 注⽬ポイント ハイエンド描画 GI‧ライティングの⼯夫 最適化 ‧着せ替え表現とオープンワールド 探索を両⽴するUE5タイトル ‧スタイライズドなキャラクター と、⾼密度な⾃然環境‧⾐装表現の 両⽴が特徴 ‧Open World環境向けの独⾃ GPU-driven Rendering ‧植⽣描画で Compute Culling / GPU LOD / DrawIndirect / MultiDrawIndirect ‧ShellFur System での⽑並み表現 ‧⾐装‧布‧素材感の表現がタイト ル価値そのもの ‧Enlighten を UE5 に統合し、リア ルタイムGIを活⽤ ‧Interior と Dynamic Object を含 むライティング品質を強化 ‧Lumen⼀辺倒ではなく、タイト ル要件に合わせてGI⼿法を選択 ‧⼤量植⽣ではCPUより描画パイプ ライン設計が重要 ‧GPU-driven化でCPU負荷を抑え つつ⼤規模環境を描画 ‧Fur Layer数を Screen Size に応じ て調整 ‧モバイル60 FPSを⻑期的な最適化 課題として扱う ‧UE4/UE5を CPU‧GPU‧Memory‧Package‧ Workflowで⽐較しUE5へ移⾏ 技術的な流れ ⾼いWorld Content密度 ⾼い⾐装表現の忠実度 GPU-driven + GI Choice Dynamic Quality Scaling 植⽣‧地形‧多様なロケーション 布‧⽑並み‧素材感 描画とライティングをタイトル別設計 Platformに応じ品質を柔軟制御 標準機能をそのまま活かしつつ、独⾃の最適化を導⼊ タイトルの強みに直結する表現は独⾃の描画技術で置き換え‧補強 Behind the Scenes of Infinity Nikki: Tracing a Glamorous Turn to an Unreal Open World Enlighten Used for the Open-World Game “Infinity Nikki” Built in Unreal Engine 5 Infinity Nikki official development update

• https://www.unrealengine.com/developer-interviews/behind-the-scenes-of-infinity-nikki-tracing-a-glamorous-turn-to-an-unreal-open-world
• https://www.siliconstudio.co.jp/en/news/pressreleases/2025/250206InfinityNikki/250206InfinityNikki.html
• https://infinitynikki.infoldgames.com/en/news/72

モバイル用に Scalability を調整する際の参考 (UE5.6) https://www.docswell.com/s/EpicGamesJapan/58WDEE-ue-5-6-mobile-graphics

• https://www.docswell.com/s/EpicGamesJapan/58WDEE-ue-5-6-mobile-graphics

「PC品質をMobile向けにダウングレード」 ↓ 「プラットフォームの能⼒に合わせて同じ体験を、 端末に合う機能の組み合わせで成⽴させる」

⾼品質なコンテンツが増えると ゲームサイズも増える

Chapter 2 アセット配信 UEならどこまで簡単にモバイル配信できる？

⾼品質化＋⻑期運営に伴いゲームサイズが⼤きくなる サイズ デバイスの 上限を越える 運営でさらに増える イベントや追加コンテンツで増加 初期DLとして許容できる量 ストレージ・通信・離脱率 量が増える Texture / Mesh / Audio / Map 時間 全コンテンツ ≠ 初期インストール

「端末内には今必要なものだけがある」状態が理想的 初回インストール アプリケーション本体 Bootアセット テクスチャやUIなど 必要に応じて導⼊ 起動直後 初回ダウンロード直後はチュートリアルまで遊べる 本編開始 ある程度まで進んだら、Map A を追加取得する イベント イベントデータだけを取得、終わったら消して容量を空ける

先に決めるのはこの3つ 何を 配信するか いつ 配信するか どこから 配信するか ‧初回ダウンロード ‧起動時 ‧ストア CDN ‧後から配信 ‧インストール直後 ‧独⾃ CDN ‧遊び始めてから必要に応じて

配信はハイブリッド⽅式が主流 Store管理 ハイブリッド Game管理 ストアがルールを持つ PAD / App Store 起動は Store 更新は⾃前CDN 取得も版も⾃前 独⾃CDN + Manifest

Android : Google Play の Asset Packs 配信モード Play Asset Delivery インストール時 install-time アプリ導⼊と⼀緒に配信 端末には起動必須のものだけ追加 Boot / UI / 最初のプレイ インストール直後 fast-follow ⼊れたあと、⾃動で取りに⾏く 直後に使う本体が追加 Tutorial / 直後に使う本体 必要なとき on-demand ゲームが要求した瞬間に取得 エリア、イベントはここで追加 個別 pack 1.5GB / install-time 累計 4GB / FF+OD 30GB / 全体 34GB targetSdk 36、64bit は 16KB（独⾃ .so はゲーム） Area / Event / 追加キャラ

iOS : App Store の Asset Packs 配信モード Managed Background Assets インストール時 essential 初回起動の前に取得 端末には起動必須のものだけ追加 Boot / UI / 最初のプレイ インストール直後 prefetch ⼊れたあと、先読みする 直後に使う本体が裏で追加 Tutorial / 直後に使う本体 必要なとき on-demand ゲームが要求した瞬間に取得 エリア、イベントはここで追加 Apple-hosted は pack をアプリと別に提出可。本体は約 4GB が上限になりやすい Area / Event / 追加キャラ

UE：アセットが配信可能なデータになるまで 1. アセット 2. Label 指定 3.Chunk割り当て 4. Cook 5. 配布物⽣成 Texture や Mesh 等の .uasset 配信単位ごとに アセットの依存関 係を辿りChunk ID を確定 Chunkごとにコン テナを書き出す pakchunkN.pak pakchunkN.utoc pakchunkN.ucas Primary Asset Label でラベル付け Asset Manager Primary Asset を登録、ロードの⼊⼝ Asset Registry 依存を解析、アセットのReference を辿り Chunk に⼊れる (未指定は Chunk 0)

UE：Primary Asset Label で指定してChunk分割 Chunk 指定あり Map_Tutorial + dependencies Chunk 10 Label でまとめる Cook が割り当てる pakchunk10.pak pakchunk10.utoc pakchunk10.ucas Chunk 指定なし 未指定の Asset Chunk 0 初期インストールの対象 ここが増えすぎると 初期インストールサイズが⼤きくなる “Chunk” は先に分割‧配信を意識して設計

UE：Chunk毎にコンテナファイルを⽣成 Asset → Label → Chunk 10 → Cook を経て、この3つのファイルが作られる（これを梱包して配信） pakchunk10.pak pakchunk10.utoc pakchunk10.ucas 起点とコンフィグファイル アセットの⽬次データ アセットの実データ マウントの⼊⼝ ランタイムでまずマウント どこに何があるかの索引 Texture / Mesh などの本体

アセットが梱包されて配信されるまでの流れ 開発機・ CI 端末 Store / CDN アセット Label Cook コンテナ Discover Download 配信⽤の箱を作成 箱を配置してゲームが利⽤ 場所：開発マシン / CI 成果物：コンテナ 場所：プレイヤーの端末 ⼊⼒：Store / CDN 上の箱 Mount

UEの成果物はコンテナ、ストア/CDNはその先 Android / PAD UE Cook iOS / Apple pakchunkN.pak pakchunkN.utoc pakchunkN .ucas 独⾃ CDN Engine GooglePAD: パック名で取得 Project Chunk→Pack 分割 / Mount Asset Pack に載せる Background Asset に載せる Engine 未実装（開発中） Project 梱包 / 取得 / Mount ファイルとして置く Engine ChunkDownloader: pakをDL+Mount Project Manifest / utoc / ucas 同梱 Asset Pack に載せる

Android : GooglePAD plugin で取得や展開を操作 Chunk Asset Pack Google Play GooglePAD エンジンができること ゲームが実装すること できないこと パック名で状態を聞く RequestDownload 取得完了後のパスを得る モバイル通信での取得確認 Chunk とパック名の対応 追加パックの梱包配置 パスを受け取ったあと Mount 失敗時の UI Label から Pack を⾃動⽣成 Play 以外への配信 アプリ審査なしの中⾝差し替え pack は AAB の⼀部、中⾝の変更 は新しい AAB

iOS : 配信後は独⾃実装 or Chunk Downloaderを使⽤ UEプラグイン提供なし 独自実装 Or ChunkDownloader Container Apple Asset Pack Game Background Assets エンジンができること ゲームが実装すること できないこと コンテナを Cook する Pak + IoStore Apple の Asset Pack か ⾃前ホストへ載せる 取得、Mount、失敗 UI 最低OS BA / ODR の公式梱包 パック名で取る API 取得 API は公式には無い Managed: iOS 26+ Unmanaged BA: 16.1〜 ODR は legacy

独⾃CDN : ChunkDownloader で直接配信 Manifest CDN ChunkDownloader Verify エンジンができること ゲームが実装すること できないこと Manifest を取りに⾏く pak を HTTP で取る サイズ / Hash 検証 MountPak CDN と Manifest の運⽤ Cook の ChunkId との対応 .utoc / .ucas の配置 失敗 UX ホストは⾃分 バージョンは⾃前で管理

Chunkを作れた ≠ 運⽤可能な配信システム エンジンが提供する ゲームが設計する Label、依存解析、Cook Pak / IoStore Mount / Load PAD（Android の窓⼝） 何を、いつ、どこから Chunk と載せ先の対応表 版とキャッシュ 失敗したときの遊び⽅ エンジン側は、配信可能なデータを作りロードする ゲーム側は、どう届けるかを設計する

配信はハイブリッド⽅式を前提に分ける 何を いつ どこから Boot 初回ダウンロード Store STORE Tutorial インストール後 Store Main 必要なとき Store / CDN CDN Event 必要なとき CDN 何を・いつ・どこから配信するかを決める

アセット参照を整理し配信⽤にChunkを正確に分離 Chunk 10 Chunk 20 Map_A Character_A Hard Reference Hard Reference Material_Common Label 未指定 Chunk 0 初期インストールが膨らむ 対策 ・共通アセットの置き場を決める ・Soft / Primary で後から取得 ・境界を明示する Texture_Common 参照がChunkをまたげば配信データは想定外のコンテナに追加される

バージョン管理も重要 ストア管理 ゲーム管理 APP 端末上の実行ファイル APP VERSION アプリを出さずに中身だけ変える ＝ 目録と実ファイルが独立する イベント修正にもアプリ更新が必要 MANIFEST 今どれを取るかの目録 ずれると … 古い目録で 存在しないファイルを取りに行く CONTENT 実ファイル（ Chunk） 自由度の代わりに、バージョンの整合性を自分で持つ

配信するデータは 開発中は巨⼤なファイル

Chapter 3 バージョン管理 新しいバージョン管理システム「Lore」

大規模ゲーム開発のVCSに求められる5つの要件 巨⼤リポジトリ対応 Binary の差分‧重複排除 複数 Branch 運⽤ 数TB規模のプロジェクトデータを 効率的に管理できること 同じアセットの繰り返しを検出しス トレージを最適化する仕組み リリース版と開発版を同時に進める 柔軟な並⾏開発が可能 同時編集の File Lock 部分チェックアウト 同じファイルの上書き競合を防ぎな がら100⼈規模での作業を⽀える 必要なファイルだけをローカルに取 得し、初期セットアップ時間を短縮 VCS : Version Control System、バージョン管理システム

VCSで管理する2つの要素 コード コンテンツ 割合 約5%程度 約95%と殆どを占める マージしやすさ マージできる 部分的なマージができない ファイルサイズ 数KB〜数100KB 1ファイルが数MB〜数百MB ファイル数 ファイル数は数100〜1000 プロジェクト次第で数万〜 履歴 全履歴を必要 履歴も必要だが最新版が重要

Lore とは？ ● Epicが開発中の新しいバージョン管理システム ● MITライセンスで利⽤はフリー（無料） ● Rust 製でランタイム不要 ● UEFNでは製品版として稼働、OSSは早期公開版 v0.9.0 (2026/9/15時点) ● データは中⾝のハッシュで管理 ● Stage、commit、ブランチはローカルで完結、ネットワーク不要

Loreは5つの要件を解決する設計 巨⼤リポジトリ対応 Binary の差分‧重複排除 複数 Branch 運⽤ 数百 GB を超えるプロジェクトデー タを⼀元管理し、必要なファイルだ けを選択的に取得する Fragment 分割（FastCDC / 固定 ⻑）と Deduplication により、巨⼤ バイナリの重複を排除し、差分転送 を最適化 リリース版と開発版を同時に進める 柔軟な並⾏開発が可能 同時編集の File Lock 部分チェックアウト ⼤⼈数が同時に編集する際のファイ ル Lock をスケーラブルに実現（予 定） 必要なファイルだけをローカルに取 得し、初期セットアップ時間を短縮

VCS スペック比較表 Git + LFS SVN Perforce Lore 分散型 集中型 集中型 集中型＋ローカル操作 ⼤容量バイナリ対応 △ ○ ◎ ◎ ファイルロック △ ◎ ◎ △→◎ ブランチ∕マージ ◎ ○ ○ ◎ 部分取得 ○ ○ ◎ ◎ バイナリ重複排除 × × × ◎ Unreal Engine 連携 ○ ○ ◎ △→◎ 費⽤ 無料/OSS 無料/Apache 無料/5Userまで 無料/MIT 成熟度 ◎ ◎ ◎ △ アーキテクチャ Loreは、Perforceの⼤規模バイナリ対応と、Gitに近い軽量なローカル操作の両⽴を⽬標

Loreが大容量Binaryに強い理由 1. Fragment 分割 2. Content Hash (BLAKE3) A B C 3．Content-addressed Storage CAS D A B 4. Deduplication/ Incremental Transfer 変更後のファイル C D A B´ C D B´ 新しく保存‧転送 A 既存Fragmentを再利⽤ ⼤きなBinaryファイル Texture/Mesh/Map/Audio A B C D ⼩さなFragmentに分割 Hash (A) Hash (B) Hash (C) Hash (D) 各Fragmentを内容で識別 Hash (A) Hash (B) Hash (C) Hash (D) 同じ内容は同じHashになる ファイルの変更部分を扱う Loreは、ファイル全体ではなく変更されたFragment単位で管理する

VCS 概念/操作比較 Git + LFS SVN Perforce Lore 最新状態へ同期 git pull svn update p4 sync lore sync 編集開始 不要 不要 p4 edit lore dirty/status --scan 変更を登録対象へ追加 git add svn add p4 add, reconcile lore stage 変更を確定 git commit + git push svn commit p4 submit lore commit → lore push 履歴単位 コミット リビジョン チェンジリスト リビジョン 履歴を⾒る git log svn log p4 changes lore history ブランチ ブランチ branches/ へのコピー ストリーム ブランチ 作業範囲を限定 sparse-checkout sparse checkout ワークスペース ビュー‧フィルタ付きツリー ファイルロック git lfs lock svn lock p4 lock lore lock acquire Loreは、既存のVCSと同じような使い⽅が可能

Lore Desktop (Client) 現在はバイナリ版のみ公開（OSS版は2027年に公開の予定） ホーム画⾯ ブランチ画⾯

Commit → Push の流れ

Lore の現在の状況 できること 制約 基本VCS操作 公式CI/CD連携が未整備 Clone / Sync / Stage / Commit / Push / History / Diff CLI⾃動化は可能だが、JenkinsやHorde連携はこれから ブランチ / マージ ⽇本語UI / CLI未対応 Branch作成‧切替‧Merge‧Conflict Resolve 現状は英語中⼼ ローカルCommit 成熟したGUIがない サーバー接続なしでCommit‧Branch操作が可能 Desktop Clientはまだ初期段階 部分取得 Git/P4の⼀部ワークフローがない Sparse / Selective Clone‧Sync ⼤容量バイナリ管理 Fragment単位のContent Addressing‧重複排除 履歴操作 Revert / Cherry-pick / Amend / Bisect Rebase / Shelve / Blame等 実運⽤ノウハウ‧Ecosystemが少ない ⻑期Production実績がまだない

Lore ロードマップ 2026 2027 2028〜 スケールとコラボレーション 模索段階 Lore OSS / UEFN compatibility Desktop client IN PROGRESS IN PROGRESS Forks & isolated partitions VS Code plugin Unreal Editor plugin IN PROGRESS IN PROGRESS Scalable file locking Web client + code review tools IN PROGRESS COMMITTED Virtual file system (VFS) Edge instances + advanced server topologies IN PROGRESS EXPLORING 基盤整備 2026.09 EXPLORING Links & layers IN PROGRESS ※タイムライン‧ロードマップは⽅向性を⽰すものであり、今後内容が変更になることもあります

Lore は開発中 保存形式は長く使える設計ですが、 APIやプロトコル、ツールはまだ Fixしていない 検証での利用は可能 実運用への導入はこれから 正式版のリリース時期、プロダクトへの導入可能時期はまだ未定

Chapter 4 まとめ

● グラフィックス — 同じ体験を端末に合う機能の組み合わせで成⽴させる ● アセット配信 — 配信設計はエンジンだけでは完結しない ● バージョン管理 — ⼤規模向けの設計、検証はできるが実運⽤はこれから

告知：Unreal Fest Tokyo 2026 開催

Thank