Content directories: Beyond the AssetBundle

Sep 22, 2026|6 Min

George Ing - Unity Technologies

Senior Engineering Manager

Content directories

このウェブページは、お客様の便宜のために機械翻訳されたものです。翻訳されたコンテンツの正確性や信頼性は保証いたしかねます。翻訳されたコンテンツの正確性について疑問をお持ちの場合は、ウェブページの公式な英語版をご覧ください。

ここをクリックしてください。

Unityにおけるコンテンツについて

Unity 2.1以降、控えめなAssetBundleは、プレイヤーバイナリ外で配布されるUnityコンテンツを支えてきました。この過去20年間で、ワールド最大級のタイトルを含む非常に多くのゲームが、データ表現としてアセットバンドルを使用しています。

基本的なレベルでは、各AssetBundleは分布、ストレージ、ロードのための不可分な単位です。AssetBundleはバンドルレベルで依存関係を追跡し、効率性のために一緒にダウンロード、ロード、アンロードされる必要がある、より大きなモノリシックな単位を形成します。

この仕様により、タイトルがアセットバンドルのレイアウトを定義する方法は、ランタイムパフォーマンスからダウンロードサイズに至るまですべての主要因となっています。これは、AssetBundleを直接使用する場合でも、Addressablesパッケージ経由で使用する場合でもtrueです。

今日は、Unityランタイムについて別のことを話します。

コンテンツディレクトリの紹介

コンテンツディレクトリは、AssetBundleの基盤的で、より高性能で、より粒度の細かい代替手段です。これらは、プレイヤーに同梱されるAssetBundleの代替として、Unity 6.6で利用可能です。Unity 7の生成中に、完全で粒度の細かいオーバー・ザ・エア配信を処理するために技術スタックが拡張されます（これについては後ほど詳しく説明しますが、非常にクールです）。

アセットを大きなロード可能なユニットにベイクするのではなく、コンテンツディレクトリは、ハードウェアリソースの完全な飽和と暗示的なコンテンツ重複排除により、個々のアーティファクト（メッシュ、テクスチャなど）を独立して識別、ロード、アンロードする能力をUnityランタイムに提供します。

Unityアセットがローカルストレージからワーキングメモリにロードされる方法を示す図。左側には、「ローカルストレージ」パネルがあり、9つのUnityアセットアイコン（3Dメッシュ、スプライトアトラス、オーディオクリップ、プリファブ）が含まれています。「個別にロード」とラベル付けされた矢印が右向きに、「作業メモリ」パネルを指しており、そのパネルにはそれらのアセットのうち3つしか含まれておらず、下部には「その他の作業用空き」とラベル付けされた空のスペースがあります。矢印の下に、「ロード → 使用 → リリース」という字幕がある。

Unityプロジェクトでのコンテンツ管理は、ビルドの高速化やアセットの配置、AssetBundleのレイアウトに関する懸念が減り、これまで以上に簡単になりました。

あなたがビルドするゲームは、より小さく、高速で、暗示的に重複排除され、新しいロード可能なリファレンスタイプを介して完全な動的メモリ管理にアクセスできます。プレイヤーにバンドルされているコンテンツにAddressablesを使用している方のために、コンテンツディレクトリに切り替えることができます。これはゼロコード変更で可能です。

どうしてこれが起こったのですか？パイプラインの各ステージの内部を外観てみましょう。

馴染みのある基盤：Build

2019年頃、私たちはUnityにおける真剣なビルド基盤に何を求めるかについて議論していました。それは、全コアで並列化され、決定論的で、完全にキャッシュされ、マシン間でビルドデータを共有できるものでした。実は、私たちの同僚の何人かが、そのアセットインポートフレームワークというプロパティを持つAPIを何年も出荷していたことがわかりました。

コンテンツディレクトリのビルドプロセスは、標準のアセットインポーターフレームワーク内で実行されます。各アセットは、アセットインポーターによって個別に構築され、サンドボックス化され、アウトプロセスで実行されます。ビルドは決定論的であり、アセットデータベースのキャッシング、全ハードウェアコアの完全な彩度、および高速な共有ビルドのためのネイティブアクセラレータサポートを備えています。

このビルドシステムについて聞いたのは初めてではないかもしれません。Unity 2023.1で予告したマルチビルドパイプラインを覚えている方もいるかもしれません。これは同じ基盤です。

ソースファイルがビルドインポーターを介してUnityアセットに変換される図2つのFBXファイルはそれぞれ2つのAssetBundleオブジェクト（青とグレーのパッケージアイコンで表示）を生成し、2つのPNGファイルはそれぞれ1つのスプライト/テクスチャアセット（チェッカーボード模様の正方形アイコンで表示）を生成します。FBXファイルからの分岐する矢印は、単一の3Dソースファイルから複数のランタイムアセットを生成できることを示しています。

出力は、非常に粒度の細かいアーティファクトの緩いグループ、それらの間の依存関係を追跡する小さなマニフェスト、そしてビルドをこれまで以上に理解しやすくするための新しい診断ファイルです。

それは信じられないほど簡単です。

馴染みのある基盤：宛先

コンテンツディレクトリをビルドしてアーティファクトを見ると、各アーティファクトがかなり奇妙なハッシュ名を持っていることに気づくでしょう。

c0152db4dd710be51b2decb997325f34.cf
f0a44ad4a4babd121543fd44032928e7.resS
4226b5c16a50dab6eff0f08dd1253d4b.resource

クールなのは、それはランダムなハッシュではないということです。代わりに、コンテンツディレクトリリシステムはGitのような技術が使用するのと同じコンテンツアドレス指定ストレージパターンを使用します。各コンテンツファイルは、そのコンテンツのハッシュによって名前が付けられ、参照されます。このパターンは、ネイティブな特徴としてコンテンツを暗示的に重複排除できるため、Unityランタイムにとって非常に有用です。

とはいえ、trueの依存関係関係グラフを持つコンテンツアドレス指定ストレージは高いチャーンのリスクを伴います。2つのアーティファクト間の最も単純な関係を考慮してください。

A → B

Bを更新し、Bのハッシュが変更されます。残念ながら、AがBを参照しているため、Aのハッシュも変更されます。さらに悪いことに、それが連鎖的に上層部にカスケードます。

代わりに、アーティファクトはコンテンツハッシュで互いをリファレンスするのではなく、安定IDでリファレンスします。ビルドマニフェストは、安定IDをコンテンツハッシュにマッピングする小さなルックアップテーブルを保持しています。

これで、ランタイムはロードするために必要なものがすべて揃いました！

馴染みのある基盤：をロード

コンテンツディレクトリでは、非常に高性能な動的ローディングシステムを導入しています。

コンテンツディレクトリがマウントされると、ローディングシステムはマニフェストを読み込み、アーティファクト間の安定ID依存関係を解決します。各アーティファクトが完全に独立してロードおよびアンロードされ、共存するアーティファクトからの汚染がゼロになります （アセットバンドルの問題、つまり単一の巨大で分割不可能な単位を思い出してください）。Gone.)

DOTSユーザーにとって、アーティファクトの基盤となるファイル形式もかなり見覚えがあるかもしれません。コンテンツディレクトリは、2022年にDOTSで導入したコンテンツファイル形式の次世代を生成しロードし、4年間マルチスレッドのEntitiesロードを支えてきた技術をすべてのアセットにも適用します。

これは読み取り操作とデシリアライズ操作の両方で完全に非同期であるローディングシステムです。これは、より高いロード帯域幅とプラットフォーム固有の非同期読み取りAPIの利用を意味します。

2つのUnityアセットロードパイプラインを比較する図「AssetBundles」とラベル付けされた上部セクションは、シリアル化されたファイルを順次処理していることを示しています。各アセットは、最終的なAwakeステップの前に、Readしてからデシリアライズされ、GPUへのアップロードは終了にのみ行われます。これは「逐次」とラベル付けされています。「コンテンツディレクトリ」とラベル付けされた下部のセクションでは、ジョビファイドパイプラインを使用するコンテンツファイルが表示されています。すべてのアセットが最初に並列で読み込まれ、その後、各アセットのデシリアライズとAwakeステップが段階的かつオーバーラップされ、GPUアップロードが全体にわたって分散されます。これは「Jobified」とラベル付けされており、並列化されたロードがシーケンシャルなAssetBundleアプローチよりもパフォーマンス上の利点があることを示しています。

さらにエキサイティングなことに、コンテンツディレクトリの基盤により、Loadableと呼ばれるモダンなロード可能なリファレンスタイプを初めてUnityにもたらすことができます。

Loadable bodyMesh;
bodyMesh.Load();

これは、コンテンツディレクトリリベースのプロジェクトのためにエンジンに直接組み込まれた、真のロード可能リファレンスです。Loadableによって参照されるオブジェクトはビルドに引き込まれますが、Loadableを呼び出すまでロードされません。非常に馴染みのあるScriptableObjectインターフェースとロードアブルを結合することで、動的にロードされるコンテンツを素早く整理できます。

それは私たちが非常に興奮している原則です。コンテンツディレクトリとロードアブルを基盤として、Unity内のあらゆるアセットは、キャラクター作成者の断片からストリーミングされるTerrain (地形) のチャンクに至るまで、アセットバンドルレイアウトやグループ定義を設計する必要なく、独立してロードおよびアンロードできる単位になることができます。

Unityで大スケールにゲームを構築することが、これほど簡単になったことはありません！

コンテンツディレクトリを試す：Slime Rancher 2

ここ数ヶ月間、いくつかのパートナーが親切にも、彼らのゲームでコンテンツディレクトリをテストさせてくれました。

例えば、モノミパークの優れたゲーム『スライムランチャー2』を取り上げ、コンテンツディレクトリに切り替えることによって得られるいくつかの利点を外観てみましょう。(Slime RancherはSteamで入手可能！)スライムレンジャー, スライムレンジャー 2)

インクリメンタルビルド時間