キャラクターや武器のプレハブをResourcesフォルダに入れて、Resources.Load()で読み込む——動きます。ちゃんと動くのに、公式ドキュメントやフォーラムでは 「Resourcesは使うな」 と言われ続けています。なぜでしょうか。
この記事では、Unityのアセットがメモリに乗る仕組みから出発して、アセットの持ち方3方式——直接参照・Resources・Addressables——の長所短所と、使い分けの判断基準を解説します。
この記事でわかること
- アセットがメモリに乗るタイミング（シーンロードと参照の関係）
- 直接参照——小規模の正解。その限界はどこか
- Resourcesが非推奨な理由——全部入りビルド・手動解放・追跡不能
- Addressables——参照カウントと動的ロードによる解決
- 使い分けの判断基準（規模・メモリ・配信要件）
前提: アセットはいつメモリに乗るのか
Unityの基本ルールはシンプルです。 「シーンに置かれたもの＋Inspectorから参照されているものは、シーンロード時に全部メモリに乗る」。
たとえば敵のプレハブがボスのモデル・テクスチャ・BGMを参照していれば、そのボスが登場しないステージでも、プレハブを参照した瞬間に芋づる式で全部ロードさ れます。アセットが少ないうちは問題になりませんが、増えてくると次の症状が出始めます。
- メモリ使用量の増大: 使っていないアセットまで乗り続け、モバイルではクラッシュの原因に。
- ロード時間・ビルドサイズの肥大化: すべてがゲーム本体に同梱される。
- コンテンツの動的更新が不可能: 新キャラ1体の追加でもアプリ全体の更新が必要。
アセット管理の3方式は、この症状にどう向き合うかの違いです。
方法1: 直接参照——小規模の正解
[SerializeField]でInspectorからアセットを割り当てる、いつものやり方です。
- 長所: 最もシンプル。参照が切れればエディタが即座に教えてくれ、リネームにも強い。小〜中規模ゲームではこれが正解です。
- 短所: 参照先はシーンロード時に必ずメモリへ。ロードのタイミングを制御できません。
直接参照の安心感はここにあります。参照が切れれば エディタが即座に赤く教えてくれる ため、「知らないうちに壊れていた」が起きません。これは後 述するResourcesの文字列参照とは対照的な、直接参照ならではの大きな利点です。
「まだメモリで困っていない」なら、無理に他の方式へ移る必要はありません。
方法2: Resourcesフォルダ——なぜ非推奨か
Resourcesという名前のフォルダに入れたアセットは、Resources.Load<T>("パス")でいつでもロードできます。一見便利ですが、代償が大きい方式です。
- 使わなくても全部ビルドに入る: Resourcesフォルダの中身は、実際に使うかどうかに関係なく全量がビルドに含まれます。ビルドサイズと起動時間（起動時にResourcesの索引を構築します）が肥大化します。
- メモリ解放が手動:
Resources.UnloadUnusedAssets()を自分で呼ぶ必要があり、呼び忘れればメモリに残り続けます。 - 参照が文字列:
"Prefabs/Boss"のような文字列パスは、リネームやフォルダ移動で静かに壊れます。エディタは何も警告しません。
こうした理由から、Unity公式のベストプラクティスでも新規プロジェクトでのResources使用は非推奨とされています。「昔のチュートリアルではよく出てくるが、今は選ばない」方式と覚えて ください。
方法3: Addressables——現代の解決策
Addressable Asset Systemは、アセットに「アドレス」（キー）を割り当て、非同期で動的にロード・アンロードする公式システムです。
- 参照カウントによるメモリ管理: 同じアセットを複数箇所でロードしても実体は1つ。ロードした側が使い終わりに
Releaseを呼ぶと参照カウントが減り、どこからも使われなくなった時点で解放されます。「全自動」ではなく、 「借りたら返す」ルールを守れば解放タイミングをシステムが正確に管理してくれる 仕組みです。 - ビルドからの分離と動的更新: アセットをゲーム本体から切り離してサーバーに置けるため、アプリ更新なしで新コンテンツを配信できます。
- ロードタイミングの制御: 「ボス戦の直前 にボスのアセットをロードし、倒したら解放」といった制御が素直に書けます。
導入手順・LoadAssetAsync/Releaseの使い方・Event Viewerでのリーク検出などの実践は、Addressables入門 で詳しく解説しています。
実践：使い分けをプロジェクトで診断する
自分のプロジェクトはどの方式にすべきか——2つの質問で診断できます。
実際のジャンルに当てはめると、判断のイメージが掴めます。
| プロジェクト例 | 診断 | 推奨 |
|---|---|---|
| ステージ10個の2Dパズル | アセット総量が小さくメモリに困らない | 直接参照 |
| キャラ100体のガチャありRPG | 全キャラ同梱ではビルドも起動も重い。イベント配信もしたい | Addressables |
| ボス戦だけ超重量級の3Dアクション | 普段は不要なアセットを戦闘直前だけロードしたい | Addressables（ボス関連のみ） |
| 昔のチュートリアル 通りにResources使用中 | 動いてはいるが三重苦を抱えている | 直接参照へ書き換え推奨 |
判断基準は1行です。 「ロードのタイミングを自分で制御したくなったら、Addressables」。困っていないうちは直接参照で十分です。
ポイントは2つです。
- 「困ってから」で遅くない: 直接参照→Addressablesへの移行は、参照の持ち方を
AssetReferenceに置き換える形で段階的にできます。最初から全部Addressables化する必要はありません。 - 診断は計測とセットで: 「メモリで困っている気がする」は Profiler のMemoryビューで事実確認してから。導入の実作業は Addressables入門 が続きです。
おまけ：先に知っておくと良いこと
- AssetBundleとの関係: Addressablesの内部では従来のAssetBundleが使われています。「AssetBundleを人間が直接扱いやすくしたラッパー」がAddressables、と理解しておけば古い記事も読み解けます。
- StreamingAssets: ビルドにそのまま同梱したい生ファイル（動画・設定ファイルなど）は
StreamingAssetsフォルダという別の仕組みがあります。アセット管理ではなく「ファイル同梱」の用途です。 - Resources.UnloadUnusedAssets(): シーン遷移時に呼ぶと未使用アセットを解放できます。既存プロジェクトでResourcesを使い続ける場合の応急処置として覚えておくと役立ちます。
- Resourcesに残る小さな使いどころ: 「IDに応じてアイコンを名前でロードする」のような、 名前で動的に選ぶ小規模な用途 では、今でもResourcesが手軽な場面があります。使うなら三重苦を理解した上で、対象フォルダを最小限に絞りましょう。
- メモリの計測: 「本当にメモリで困っているのか」は Profiler のMemoryビューで確認してから判断しましょう。
まとめ
- アセットは「シーン＋参照」で芋づる式にメモリへ乗る。これが全方式の出発点。
- 直接参照が基本。小〜中規模ならこれが正解で、早すぎる移行は不要。
- Resourcesは新規では選ばない。全部入りビルド・手動解放・文字列参照の三重苦。
- Addressablesは「制御したくなったら」。参照カウント・動的配信・ビルド分離が揃う公式解。
- 実践的な使い方は Addressables入門 へ。
「なぜResourcesではダメか」を仕組みから説明できれば、アセット管理の設計判断は自信を持ってできるようになります。