アセットが数百、数千と増えてくると、「あのテクスチャ、どこに置いたっけ」と探すだけで時間が溶けていきます。
アセット は、モデル・画像・音・Blueprintなど、プロジェクトで使う素材やデータです。例えば宝箱1つにも、形を表すモデルと、表面を描くための素材が使われます。一緒に編集するものを近くへ置き、名前から種類を読めるようにすると、探す時間を減らせます。
この記事では、探しやすいフォルダと名前の決め方、移動するときに確認する参照関係を整理します。最後に、自作のマテリアル1つを別の場所へ移し、同じ見た目で使えることを確かめます。
この記事でわかること
- 機能ベース のフォルダ構造が推奨される理由と構成例
BP_・SM_・T_などの プレフィックス命名規則- アセット移動の安全装置 リダイレクタ と Reference Viewer
- ハード参照とソフト参照 で、読み込まれるタイミングが違うこと
- 実践：散らかったアセットを 壊さず引っ越す 一連の手順
プロジェクト構造の基本原則
自作のアセットは、主に Content フォルダで管理します。まずは「何を直すときに、一緒に開くか」を基準に置き場所を決めましょう。
機能ベースで分ける
アセットの整理には、大きく2つの流儀があります。
- 種類で分ける：
Materials（表面の見え方）・Meshes（立体モデル）・Textures（画像）のようにまとめます。 - 対象や機能で分ける：
Characters/Knight（騎士）・UI/Inventory（持ち物画面）のように、一緒に使うアセットをまとめます。
騎士を直すたびに複数の種類フォルダを行き来しているなら、Content/MyGame/Characters/Knight/ に専用アセットをまとめると探しやすくなります。数が増えたら、その中を Meshes や Textures に分けても構いません。複数のキャラクターで共用するものは共通フォルダへ置き、人数分コピーしないようにします。
構成例と3つの約束
/Content
├── /MyGame ← プロジェクト固有アセットはすべてこの下
│ ├── /Characters
│ ├── /Environments
│ ├── /Weapons
│ ├── /UI
│ └── /Maps ← レベルファイル専用
├── /VendorPack ← 外部アセットは配布時のフォルダを維持する例
└── /Developers ← 個人の実験場（後述）
- プロジェクト名のルートフォルダを1つ切る: 自作アセットをすべて
/Content/MyGame/の下に置くと、外部アセットとの混在を防げるうえ、将来の移行や配布時にパスの一括管理ができます - 外部アセットと自作を分ける：入手したパックのフォルダへ自作アセットを混ぜないようにします。更新手順や決まったパスを持つパックもあるので、見た目を揃えるためだけに全体を移動する必要はありません。
- 必要な階層だけ作る：最初は
MyGame/Mapsと、今作る機能のフォルダから始められます。空の分類を大量に用意するより、増えたところを分けます。
命名規則の徹底
フォルダ構造が「住所」なら、名前は中身を知らせるラベルです。先頭に種類を表す プレフィックス（接頭辞） を付けると、開く前に用途を判断しやすくなります。以下はよく使われる命名例です。参加先のプロジェクトに規則があれば、そちらへ揃えます。
基本の形は [プレフィックス]_[対象]_[詳細]_[連番] です（例: SM_Door_Wooden_Old_02）。
| アセットの種類 | プレフィックス | 例 |
|---|---|---|
| Blueprintクラス | BP_ | BP_PlayerCharacter |
| マテリアル | M_ | M_Ground_Moss |
| マテ リアルインスタンス | MI_ | MI_Ground_Moss_Dry |
| テクスチャ | T_ | T_Ground_Moss_D（末尾 _D=カラー、_N=ノーマル） |
| スタティックメッシュ | SM_ | SM_Tree_Oak_01 |
| スケルタルメッシュ | SK_ | SK_Player_Base |
| アニメーションBP | ABP_ | ABP_Player |
| アニメーションシーケンス | A_ | A_Player_Run |
| レベル（マップ） | L_ | L_MainMenu |
| ウィジェットBP | WBP_ | WBP_HealthBar |
プレフィックス は名前の先頭へ付ける印です。SM_ ならStatic Mesh、BP_ ならBlueprint Classだと、開く前に見当を付けられます。詳細や連番は、区別が必要なときだけ追加します。
コンテンツブラウザで SM_ と検索すると、その文字を含む名前を絞り込めます。ただし、名前を変えてもアセットの種類は変わりません。種類を確実に絞るときは「Static Mesh」などの型フィルタを使います。
あわせて2つのルールを。
- スペースと日本語は使わない: 単語の区切りはアンダースコアかキャメルケース（
BP_PlayerCharacter）。パスに使えない文字での事故を防 ぎます - 大文字・小文字も揃える：
SM_Doorと決めたら、資料やコードでも同じ表記を使います。ファイル名の大文字・小文字の扱いは環境で異なるため、表記揺れを減らしておくと確認が楽です。
アセットを壊さないための3つの道具
日々の整理で登場する、UE標準の3つの道具を押さえましょう。
リダイレクタ——移動のあとに残る「転送メモ」
コンテンツブラウザ内でアセットを移動・リネームすると、UEは元の場所に リダイレクタ (Redirector) という見えないファイルを残します。古いパスを参照しているアセットを新しい場所へ案内する、郵便の「転送届」のようなものです。
ここでいう 参照 は、別のアセットを指定して使うつながりです。移動の整理が終わったら、元のフォルダで「Fix Up Redirectors in Folder」を実行すると、参照先の更新と保存が行われます。すべてを更新できたリダイレクタは不要になるため取り除かれます。残った場合は、保存できなかったアセットがないかメッセージを確認してください。リダイレクタ自体を手動で消すと、まだ使われている転送先を失うことがあります。
Reference Viewer——消す前に「誰が使っているか」を見る
アセットを右クリックして「Reference Viewer」を開くと、選んだものを中心に参照関係を調べられます。例えば宝箱のマテリアルを選ぶと、左には そのマテリアルを使うモデル、右には そのマテリアルが使う画像 が並びます。マテリアルは表面の色や質感を決めるもので、その材料として画像を使うことがあります。
図は関係を整理したイメージです。矢印は「左のアセットが右を使う」を表し、ゲーム中の処理の順番ではありません。
「この画像を消したら何に影響するか」を考えるときは、使っている側へたどります。表示する参照の種類や深さはフィルタで変わるため、何も表示されないことだけで「使われていない」とは判断しません。
数十個をまとめて直したくなったら
引っ越しやリネームが100個単位になると、手作業では限界が来ます。UEにはエディタ上で動く自前ツールをBlueprintだけで作る仕組みがあり、選択中のアセットやActorを一括処理させられます（→ Editor Utility Widgetでツールを作る）。
Migrate——別プロジェクトへの安全な輸出
アセットを別プロジェクトへ持っていくときは、「Asset Actions → Migrate」を使います。選んだアセットと、その動作や見た目に必要な 依存アセット が一覧に出ます。内容を確認し、移行先プロジェクトの Contentフォルダ を指定します。必要な画像などを一覧から外すと、移行先で見た目が再現できないことがあります。
同じ名前のアセットが移行先にある場合は、上書きの確認が出ます。上書き前にどちらを残すか確認してください。プラグインやC++コードまでこの操作だけで揃うとは限らないため、移行先でも開いて確かめます。検証用プロジェクトから使う分だけ移す手順はFabの記事でも扱います。
チーム開発におけるアセット管理
複数人での開発では、ルールはさらに重要になります。ソース管理（Git LFSやPerforce）の導入が前提です。Git LFSでUEプロジェクトを管理する具体的な手順は Git LFSでのプロジェクト管理 、プロジェクト作成直後のGitの始め方は 初期設定の記事 で扱っています。
- 同じアセットを同時に編集しない：UEのアセットは、文章のように変更を自動で合体させにくいバイナリファイルです。担当を分け、PerforceのチェックアウトやGit LFSのロックなど、使っている管理方法で編集対象を共有します。Gitでコミットするだけでは、他の人の編集は止まりません。
Developersフォルダは実験用：本番で使うアセットから、このフォルダの試作品を参照しないようにします。採用するものは正式な場所へ移して確認します。実験中の内容も失いたくない場合は、チームの方針に沿って履歴へ残します。- 移動はまとめて共有する：移動したファイルに加え、参照を更新して保存したファイルも同じ変更として記録します。他の人が編集中のフォルダは、作業の区切りを合わせてから移動します。
ハードリファレンスとソフトリファレンス
アセット管理の最後のピースは、BlueprintやC++がアセットを どう参照するか です。ここがメモリ使用量とロード時間を左右します。
ロード は、保存されたデータを、実行中に使えるようメモリへ読み込むことです。参照の持ち方によって、読み込みが必要になるタイミングが変わります。
- ハード参照：参照元を読み込むと、その参照先も一緒に必要になります。宝箱のモデルと、その表面のマテリアルなど、同時に使うものを結びつける基本の方法です。
- ソフト参照：アセットの保存場所を持ち、読み込みは別の処理で行います。例えばギャラリーの大きな画像を、ページを開いたときに読み込む用途です。
図の「いつも使う／たまに使う」は使い分けの目安です。大切なのは、どの参照元を読み込むと何が必要になるかです。ハード参照だから必ずゲーム起動時に全部読み込む、という意味ではありません。
ソフト参照に変えても、必要な画像が自動で表示されるわけではありません。読み込みを依頼し、完了してから表示に使います。ほかの処理を進めながら読み込みを待つ方法を 非同期ロード と呼びます。BlueprintのSoft Object ReferenceとAsync Load Assetを使う実践は、非同期ロードとソフト参照の記事で扱います。今は、整理のためにすべての参照を置き換える必要はありません。
実践：散らかったアセットを安全に「引っ越す」
ここでは、レベルで使っている自作のマテリアル1つを移動します。例えば床に割り当てた NewMaterial を、MyGame/Environments/Floor へ整理する練習です。まだ素材が少なければ、同じ手順を試せるテスト用プロジェクトで構いません。移動前の状態をコミットまたはバックアップしてから始めます。
自作マテリアルがまだなければ、マテリアル入門で色を付けるものを1つ作ってから試せます。配布パック全体を最初の練習に使う必要はありません。
- 使っている場所を確認する：対象のマテリアルをReference Viewerで開き、どのモデルやレベルから使われているかを見ます。そのレベルを開き、現在の見た目も確認します。
- 行き先を作って移動する：コンテンツブラウザで
MyGame/Environments/Floorを作ります。対象をそのフォルダへドラッグし、「Move Here」を選びます。「Copy Here」は複製なので、今回は使いません。 - リネームもこのタイミングで:
NewMaterialをM_Floor_Stoneに。プレフィックス表を見ながら、名前だけで正体が分かる形へ直します - 参照先を更新して保存する：移動元のフォルダで「Fix Up Redirectors in Folder」を実行し、変更を保存します。保存に失敗したメッセージがあれば、その対象を先に確認します。
- 同じ見た目か確かめる：使用しているレベルを開き直し、床の色や模様が移動前と同じか確認します。マテリアルの指定欄に移動先のアセットが入っているかも見ます。
- 変更を記録する：ソース管理を使っているなら、移動・名前変更と、参照先を更新したファイルをまとめてコミットします。
レベルを開き直しても見た目が同じで、指定先も新しい場所を指していれば、この移動は完了です。見た目が変わった場合は、どのマテリアルや画像の指定が外れたかを確認します。参照切れの症状は、必ず特定の色になるわけではありません。 Output Logに不足ファイルの名前が出ていれば、保存場所と照合します（→ Output Logの見方）。
ポイントは2つです。
- 移動と確認を一組にする：エディタ内で移動し、参照を更新して保存したら、使っているレベルを開き直します。
- 引っ越しは小さく分けて: 一晩 で全部やろうとせず、「今日はUIフォルダだけ」のように区切ると、問題が起きたときの切り分けも楽です
おまけ：先に知っておくと良いこと
| よくある間違い | 何が起きるか | 対策 |
|---|---|---|
| エクスプローラーでアセットを移動・リネーム | 参照が切れ、Fix Up Redirectors でも直せない | 必ず コンテンツブラウザ内で操作する |
| 名前から種類や用途が分からない | 開くまで中身を判断しにくい | T_などの接頭辞と、用途の分かる名前を付ける |
| 外部パックのフォルダへ自作アセットを混ぜる | 更新や削除の対象を判断しにくい | 自作はMyGame以下へまとめ、配布元の構成は確認して扱う |
見た目が戻らない場合は、追加の移動や削除を止め、移動前との差分を確認します。元のファイルが失われているなら、履歴やバックアップから戻すことも必要です。Fix Upは残っている転送情報を整理する処理なので、失われたアセットそのものを復元する機能ではありません。
まとめ：アセット管理チェックリスト
| チェック項目 | 頻度 |
|---|---|
| 一緒に編集するアセットを探しやすい場所へまとめたか | 機能追加時 |
| 全アセットに 正しいプレフィックス が付いているか | アセット作成の都度 |
| 移動・リネーム後に Fix Up Redirectors を実行したか | コミット前の都度 |
| 大きなアセットの読み込み時期を見直す必要があるか | ロード時間やメモリ使用量が問題になったとき |
Developers フォルダに本番アセットが残っていないか | マイルストーンごと |
最初から完全な分類を作るより、今使っている素材を1つ選び、名前・置き場所・使っている相手を説明できるようにしてみましょう。アセットが増えても、その単位で整理を続けられます。
次はエディタUIの基本でコンテンツブラウザの操作を確かめ、Print Stringのデバッグ手法で「動かないときに調べる力」を手に入れましょう。
あなたのプロジェクトの Content 直下には、いま何個のアセットが「住所不定」のまま転がっているでしょうか。引っ越し先を1フォルダだけ決めて、手を動かしてみてください。
参考資料
Epic公式のReference Viewer、Redirectors、Migrating Assets、Referencing Assetsで、それぞれの仕組みを確認できます。