Menu

© 2026 ういやまラボ

JPEN
BLOGTOOLSPRODUCTNOTES
リストに戻る

【Unreal Engine】アセット管理入門：フォルダ構造と命名規則のベストプラクティス

作成: 2025-12-12最終更新: 2026-07-19

プロジェクトが大きくなっても破綻しないUE5のアセット管理を図解。機能ベースのフォルダ構造、プレフィックス命名規則、リダイレクタ、ハード/ソフトリファレンスまで。

アセットが数百、数千と増えてくると、「あのテクスチャ、どこに置いたっけ」と探すだけで時間が溶けていきます。

アセット管理の乱れは、検索時間の浪費だけでなく、チームでの上書き事故・ビルドサイズの肥大化・依存関係のもつれによる プロジェクトの実質的な停止 にまでつながります。逆に言えば、フォルダ構造と命名のルールを最初に決めておくだけで、これらは全部防げます。

この記事では、破綻しないプロジェクト構造の作り方を解説します。最後に「散らかったアセットを安全に引っ越す」実践も紹介します。

棚にアセットの箱を整然と収める人形。アセット管理のイメージ

この記事でわかること

  • 機能ベース のフォルダ構造が推奨される理由と構成例
  • BP_・SM_・T_ などの プレフィックス命名規則
  • アセット移動の安全装置 リダイレクタ と Reference Viewer
  • ハードリファレンスとソフトリファレンス の使い分け（C++実装例つき）
  • 実践：散らかったアセットを 壊さず引っ越す 一連の手順

目次

Sponsored

プロジェクト構造の基本原則

UEプロジェクトの心臓部は Content フォルダです。ここの構造が、プロジェクトの未来を決めます。

機能ベースで分ける

アセットの整理には、大きく2つの流儀があります。

  1. 種類ベース（非推奨）: Materials・Meshes・Textures のように、アセットの種類で分ける
  2. 機能ベース（推奨）: Characters・Environments・UI のように、ゲームの機能で分ける
種類ベースでは騎士の装備がMeshes・Textures・Materialsへ散らばり、機能ベースではKnightフォルダに集まる。1つの機能は、1つの場所に

種類ベースだと、1体のキャラクターを構成するメッシュ・テクスチャ・マテリアル・Blueprintが バラバラのフォルダに散らばります 。「あのキャラを修正したい」だけで複数フォルダを行き来し、移行や削除の影響範囲も追えなくなります。機能ベースなら Content/MyGame/Characters/Knight/ を開けば、騎士に関する全部がそこにあります。

構成例と3つの約束

/Content
├── /MyGame          ← プロジェクト固有アセットはすべてこの下
│   ├── /Characters
│   ├── /Environments
│   ├── /Weapons
│   ├── /UI
│   └── /Maps        ← レベルファイル専用
├── /External        ← ストア・外部から入れたアセット
│   └── /VendorName
└── /Developers      ← 個人の実験場（後述）
  • プロジェクト名のルートフォルダを1つ切る: 自作アセットをすべて /Content/MyGame/ の下に置くと、外部アセットとの混在を防げるうえ、将来の移行や配布時にパスの一括管理ができます
  • 外部アセットは External へ隔離: ストアからインポートしたものを自作アセットと混ぜない（詳細は「よくある間違い」参照）
  • 階層は3〜4段まで: 深すぎるとナビゲーションが苦痛になり、浅すぎると1フォルダが混みます。/Content/MyGame/機能/種類 くらいが目安です
Sponsored

命名規則の徹底

フォルダ構造が「住所」なら、命名規則はアセットの「IDカード」です。UEコミュニティには広く合意された プレフィックス（接頭辞） の慣習があり、これに従うだけで、名前を見た瞬間にアセットの種類が分かるようになります。

SM_Door_Wooden_Old_02を種類・対象・詳細・連番に分解した図。名前だけで、正体がわかる

基本の形は [プレフィックス]_[対象]_[詳細]_[連番] です（例: 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
アニメーションBPABP_ABP_Player
アニメーションシーケンスA_A_Player_Run
レベル（マップ）L_L_MainMenu
ウィジェットBPWBP_WBP_HealthBar

プレフィックスは人間が読むためだけのものではありません。コンテンツブラウザの検索欄に SM_ と打てば、プロジェクト中のスタティックメッシュだけが一覧に並びます。命名は、検索フィルタのためのタグでもあります。

あわせて2つのルールを。

  • スペースと日本語は使わない: 単語の区切りはアンダースコアかキャメルケース（BP_PlayerCharacter）。パスに使えない文字での事故を防ぎます
  • 大文字・小文字を「区別する」前提で統一する: Windowsは区別しませんが、LinuxやMacは区別します。sm_door と SM_Door が混在したプロジェクトは、他プラットフォームへの移行時に壊れます
Sponsored

アセットを壊さないための3つの道具

日々の整理で登場する、UE標準の3つの道具を押さえましょう。

リダイレクタ——移動のあとに残る「転送メモ」

コンテンツブラウザ内でアセットを移動・リネームすると、UEは元の場所に リダイレクタ (Redirector) という見えないファイルを残します。古いパスを参照しているアセットを新しい場所へ案内する、郵便の「転送届」のようなものです。

リダイレクタの図。移動直後は転送メモ経由で参照が届き、Fix Up Redirectors後は直通になる。コミット前に転送メモを掃除する

転送メモは放置すると溜まり続け、参照解決の遠回りやソース管理上のゴミの原因になります。 フォルダを右クリック → Fix Up Redirectors in Folder で、参照を直通に書き換えて転送メモを掃除できます。 ソース管理へコミットする前に必ず実行する ことを習慣にしてください（エディタ操作の基本はエディタUIの基本でも触れています）。

Reference Viewer——消す前に「誰が使っているか」を見る

アセットを削除・大改造する前に、右クリック → Reference Viewer を開くと、そのアセットを 使っている側 と、そのアセットが 使っている側 が図として表示されます。「このテクスチャを消したら、どのマテリアルが壊れるか」が一目で分かるので、削除前の確認はこれ一択です。

数十個をまとめて直したくなったら

引っ越しやリネームが100個単位になると、手作業では限界が来ます。UEにはエディタ上で動く自前ツールをBlueprintだけで作る仕組みがあり、選択中のアセットやActorを一括処理させられます（→ Editor Utility Widgetでツールを作る）。

Migrate——別プロジェクトへの安全な輸出

アセットを別プロジェクトへ持っていくとき、ファイルのコピー＆ペーストは厳禁です（依存アセットが欠けて壊れます）。右クリック → Asset Actions → Migrate... を使うと、依存するテクスチャやマテリアルまでUEが自動でリストアップし、フォルダ構造ごと安全にコピーしてくれます。Fabで入手したアセットを検証用プロジェクトで確認してから、使う分だけ本番へ移す運用は Fabの記事 で扱っています。

Sponsored

チーム開発におけるアセット管理

複数人での開発では、ルールはさらに重要になります。ソース管理（Git LFSやPerforce）の導入が前提です。Git LFSでUEプロジェクトを管理する具体的な手順は Git LFSでのプロジェクト管理 、プロジェクト作成直後のGitの始め方は 初期設定の記事 で扱っています。

  • 編集はチェックアウトしてから: アセットはバイナリファイルのため、テキストのように差分マージできません。「同じアセットを2人が同時に編集」は必ずどちらかの作業が消えます。編集前にチェックアウト（編集宣言）、終わったらすぐコミットが基本動作です
  • Developers フォルダ＝個人の実験場: 各自の作業中・テスト用アセットはここへ。 このフォルダのアセットに本番アセットから依存してはいけない 、が鉄の掟です。完成したら MyGame 以下の正式な場所へ引っ越してからコミットします
  • フォルダの移動・リネームは「エディタ内で → Fix Up → コミット」の3点セット: エクスプローラーでの直接操作は、依存関係の追跡を破壊する最悪の事故です。 絶対にやめましょう
Sponsored

ハードリファレンスとソフトリファレンス

アセット管理の最後のピースは、BlueprintやC++がアセットを どう参照するか です。ここがメモリ使用量とロード時間を左右します。

Hard Referenceは参照先も鎖で一緒にロードされ、Soft Referenceは住所メモだけ持って必要時に取りに行く。いつも使うはハード、たまに使うはソフト
  1. ハードリファレンス: アセットを直接参照します（例: TSubclassOf<AMyActor>、Blueprintの通常の変数参照）。参照元がロードされると、 参照先も鎖で繋がれたように連鎖ロード されます
  2. ソフトリファレンス: アセットの「住所（パス）」だけを持ちます（例: TSoftObjectPtr<UTexture2D>）。実体のロードは 必要になった瞬間まで遅延 できます

使い分けの軸はシンプルで、 いつも使うものはハード、たまにしか使わないものはソフト です。プレイヤーキャラクターの基本クラスはハードで構いませんが、設定画面の背景やギャラリーの高解像度画像までハードにすると、ゲーム起動時に全部メモリへ乗ってしまいます。

Blueprintでも同じ仕組みを使えます。変数の型を選ぶドロップダウンで 「Soft Object Reference」（クラスを指すなら Soft Class Reference）を選ぶと、その変数は実体ではなく住所だけを持つソフト参照になります。実体が必要になった時点で Async Load Asset ノードを使い、非同期にロードします。

変数 BackgroundImage（型: Texture 2D の Soft Object Reference）
  → Async Load Asset（Asset: BackgroundImage）
  → Completed → 返ってきた実体を Set Brush などで使う

Blueprintでの非同期ロードのより詳しい実践は 非同期ロードとソフト参照 にまとめています。低レイヤーなC++での書き方は次のとおりです。

// MyActor.h
UCLASS()
class AMyActor : public AActor
{
    GENERATED_BODY()
public:
    // アセットの「住所」だけを持つソフトリファレンス
    UPROPERTY(EditAnywhere, Category = "Config")
    TSoftObjectPtr<UMyDataAsset> ConfigData;

    UFUNCTION(BlueprintCallable)
    void LoadConfigData();

private:
    void OnConfigDataLoaded();   // ロード完了時に呼ばれる
};

// MyActor.cpp
#include "Engine/StreamableManager.h"
#include "Engine/AssetManager.h"

void AMyActor::LoadConfigData()
{
    if (ConfigData.IsNull())   // 住所が未設定なら何もしない（安全確認）
    {
        return;
    }

    FStreamableManager& Streamable = UAssetManager::Get().GetStreamableManager();
    // 非同期ロードを依頼し、完了したらコールバックを受け取る
    Streamable.RequestAsyncLoad(
        ConfigData.ToSoftObjectPath(),
        FStreamableDelegate::CreateUObject(this, &AMyActor::OnConfigDataLoaded));
}

void AMyActor::OnConfigDataLoaded()
{
    if (UMyDataAsset* LoadedData = ConfigData.Get())   // ロード済みの実体を取得
    {
        // ここからLoadedDataを使える
    }
}

C++の書き方自体（UPROPERTY・UFUNCTION）が初めての場合は、BlueprintからC++への第一歩から読むとスムーズです。データ駆動設計との組み合わせはData Assetの記事へ。

Sponsored

実践：散らかったアセットを安全に「引っ越す」

ルールを知った直後にやるべきは、いま散らかっているプロジェクトの引っ越しです。チュートリアルを試すうちに Content 直下へ溜まった NewFolder・Untitled・名無しのマテリアル——どのプロジェクトでもよく見かける光景です。これを 1つも壊さずに 新しい構造へ移す一連の手順が、この記事の総仕上げになります。

散乱した箱の部屋と、棚に整理された部屋のビフォーアフター。エディタ内で動かして、Fix Upで締める
  1. 受け皿を先に作る: コンテンツブラウザで MyGame フォルダと、その下の機能フォルダ（Characters・UI など）を先に用意します。行き先が決まっていない引っ越しは散らかりを移動するだけです
  2. 1グループずつ移動: 関連アセットをまとめて選択し、 エディタ内のドラッグ＆ドロップ で新しい住所へ移します。エクスプローラーは開かない、というのが唯一にして最大のルールです
  3. リネームもこのタイミングで: NewMaterial を M_Floor_Stone に。プレフィックス表を見ながら、名前だけで正体が分かる形へ直します
  4. Fix Up で締める: Content フォルダを右クリック → Fix Up Redirectors in Folder 。転送メモを一掃します
  5. 壊れていないことを確認: メインのレベルを開いてPlayし、マテリアルが紫（参照切れの警告色）になっていないかを見ます。不安なアセットは Reference Viewer で参照が繋がっているかを確認
  6. コミット: ソース管理を使っているなら、ここで「Reorganize content folders」のようなコミットを1つ。引っ越しという大手術こそ、セーブポイントを残す価値があります

Playして景色がいつも通りなら、引っ越し成功です。もしどこかのマテリアルが紫になっていたら、そのアセットをReference Viewerで開いて切れた参照元を確認し、移動先のアセットを開き直して再保存すれば、たいていは直ります。

ポイントは2つです。

  • 「エディタ内で動かし、Fix Upで締める」を体に入れる: この2拍子さえ守れば、アセットの移動は怖くありません
  • 引っ越しは小さく分けて: 一晩で全部やろうとせず、「今日はUIフォルダだけ」のように区切ると、問題が起きたときの切り分けも楽です

おまけ：先に知っておくと良いこと

よくある間違い何が起きるか対策
エクスプローラーでアセットを移動・リネーム参照が切れ、Fix Up Redirectors でも直せない必ず コンテンツブラウザ内で操作する
プレフィックスを付けないMyTexture がテクスチャかマテリアルか分からず、検索・フィルタが機能しないT_＋_D/_N などのサフィックスを徹底
ストアアセットをContent直下に展開したまま使う自作アセットと混ざり、更新・削除で事故る/Content/External/VendorName/ に隔離

アセットが壊れた（アイコンが白い・マテリアルが紫）ときの手順: ① Reference Viewerで参照の切れ目を特定 → ② 元の場所と思われるフォルダで Fix Up Redirectors in Folder → ③ それでもダメなら、壊れたアセットを削除して正しいパスへ再インポート、の順で試します。

まとめ：アセット管理チェックリスト

チェック項目頻度
フォルダは 機能ベース（MyGame/Characters/Knight）になっているかプロジェクト開始時・機能追加時
全アセットに 正しいプレフィックス が付いているかアセット作成の都度
移動・リネーム後に Fix Up Redirectors を実行したかコミット前の都度
たまにしか使わないアセットが ソフトリファレンス になっているかBP/コード作成時
Developers フォルダに本番アセットが残っていないかマイルストーンごと

アセット管理は単なるお掃除ではなく、 未来の自分とチームへの投資 です。今日30分かけて構造を整えることが、明日からの何十時間もの探し物とデバッグを消してくれます。

次はエディタUIの基本でコンテンツブラウザの操作を確かめ、Print Stringのデバッグ手法で「動かないときに調べる力」を手に入れましょう。

あなたのプロジェクトの Content 直下には、いま何個のアセットが「住所不定」のまま転がっているでしょうか。引っ越し先を1フォルダだけ決めて、手を動かしてみてください。