タイトル: ビルド
SEOタイトル: UE5のビルドとは｜ライティング等の事前計算とパッケージ化の違い
Unreal Engine 5（UE5）における「ビルド」という言葉は、文脈によって主に2つの異なる意味で使われます。1つはエディタ内のメニュー操作としてのビルドで、ライティング（事前計算された照明）やナビメッシュ、HLODなどをあらかじめ計算してレベルに焼き付ける処理を指します。もう1つはパッケージ化（Package Project）としてのビルドで、プロジェクトをコンパイル・クック（Cook）して、配布や実行が可能な実行ファイルにまとめる処理を指します。この記事では両者を区別したうえで、それぞれの操作と注意点を整理します。
| この記事の要点 |
|---|
|
「ビルド」の2つの意味
UE5を学び始めた段階では、この2種類の「ビルド」が混同されやすいため、まず違いを整理します。下表は両者の役割を対比したものです。
| 観点 | ①エディタのビルド（事前計算） | ②パッケージ化（実行ファイル生成） |
|---|---|---|
| 目的 | ライティングやナビメッシュなどをあらかじめ計算し、レベルに反映する | 配布・単体実行が可能な成果物を生成する |
| 主な入口 | メインメニューの Build（ビルド）メニュー | ツールバーの Platforms（プラットフォーム）→ Package Project |
| 対象 | 開いているレベル／ワールドのデータ | プロジェクト全体（コード＋アセット） |
| 結果の保存先 | マップ（レベル）ファイルなどに焼き付けられる | 指定した出力フォルダに実行ファイル一式が出力される |
| 主な利用場面 | 制作中の見た目・挙動の確定、最終調整 | テスト配布、リリース、他環境での動作確認 |
なお、C++を含むプロジェクトでは、ソースコードを実行可能な状態に変換する「コンパイル」も一般に「ビルド」と呼ばれます。これは上記①②とは別の作業で、後半で改めて触れます。
①エディタのBuildメニュー（事前計算）
エディタ上部のメインメニューにある Build メニューは、レベルに関わる各種データを事前に計算する操作をまとめたものです。これらは実行時の負荷を下げたり、見た目を確定させたりするために行います。代表的な項目を挙げます。
- Build Lighting（ライティングのビルド）: スタティック（静的）なライトやライトマップなど、事前計算ベースの照明情報を計算してレベルに焼き込みます。品質はワールドセッティングのライティング品質（Preview / Medium / High / Production など）で切り替えられ、Production は最終品質向けの設定とされています。Lumen のような動的グローバルイルミネーションを用いる場合は事前計算ライティングの比重が下がりますが、スタティックライトを使う構成ではこのビルドが見た目に直結します。
- Build Paths（ナビメッシュのビルド）: AIキャラクターが移動経路を計算するために用いるナビゲーションメッシュ（NavMesh）を生成します。レベルのジオメトリに基づいて歩行可能な領域を計算する処理で、これが未生成だとAIの経路探索が機能しないことがあります。
- Build HLODs（HLODのビルド）: HLOD（Hierarchical Level of Detail）は、遠距離にあるアクターをまとめて簡略化したメッシュ・マテリアルに置き換える仕組みです。ドローコールやメモリ使用量、ジオメトリ／マテリアルの複雑さを抑えてパフォーマンスを改善する目的で使われます。
- Build All / Build All Levels: 上記のような事前計算をまとめて実行する項目です。レベルの規模によっては時間がかかります。
これらの結果は基本的にレベル（マップ）側に保存されます。そのため、ジオメトリやライト、ナビ関連の設定を変更したら、必要に応じて再ビルドして反映させる、という流れになります。利用しているUE5のバージョンによって項目名や挙動が異なる場合があるため、不確実な点は公式ドキュメントで確認することを推奨します。
②パッケージ化（Package Project）
制作したプロジェクトを、エディタなしで動作する実行ファイルとしてまとめる処理がパッケージ化です。エディタのツールバーにある Platforms（プラットフォーム）メニューから、対象プラットフォームと Package Project を選んで実行します。内部的には、アセットを対象プラットフォーム向けに変換するクック（Cooking）、コードのビルド、ファイルのまとめ（パッケージング）などが順に行われます。
ターゲットプラットフォームの選択
Platforms メニューからは、Windows、各種コンソール、モバイル、VR/AR など、対象とするプラットフォームを選択できます。プラットフォームごとに必要な前提条件（SDKや追加設定）が異なり、選んだプラットフォーム向けにコンテンツがクックされます。プラットフォーム固有の細かな設定は Project Settings の Packaging などから調整できます。
ビルド構成（Build Configuration）
パッケージ化ではビルド構成（Configuration）を選びます。構成は「どのようにコンパイルし、どのコードやコンテンツを含めるか」を決めるプリセットで、Platforms メニューのサブメニューから切り替えられます。代表的なものは次のとおりです。
- Debug: デバッグ情報を多く含み、最適化を抑えた構成。コードの問題を詳しく追う用途に向きます。
- Development: 開発中の標準的な構成。デバッグに役立つ機能やログ、コンソールなどを利用しやすく、開発・テストに広く使われます。
- Shipping: 配布・リリース向けの構成。一般にコンソールコマンドや一部のデバッグ向け機能が無効化され、最適化された成果物になります。プレイヤーに不要な操作をさせたくない配布版に適しているとされています。
このほか Test など、エンジンが提供する構成があります。Development と Shipping では含まれる機能や挙動が異なるため、「開発中は問題なかったが Shipping で挙動が変わった」という事象が起こり得ます。最終的な配布物は、配布に用いる構成（多くは Shipping）で生成・検証することが重要です。
C++プロジェクトのコンパイル
Blueprint のみのプロジェクトと異なり、C++のソースコードを含むプロジェクトでは、コードをコンパイルする作業が発生します。これも広い意味で「ビルド」と呼ばれます。主な方法は次のとおりです。
- エディタの Compile ボタン: エディタ上のコンパイルボタンから、変更したコードを反映できます。
- Live Coding: エディタを起動したまま、主に
.cpp内の関数実装などの変更を素早く反映する仕組みです。Compile ボタン横のドロップダウンから有効化でき、ショートカット（既定では Ctrl + Alt + F11）でビルドを実行できます。ただし、ヘッダ（.h）の変更やクラス構造の変更など、反映できない種類の変更もあり、その場合はエディタを閉じての通常のビルドが必要になります。対応範囲や安定性はバージョンや設定で変わるため、公式情報の確認を推奨します。 - 外部IDE（Visual Studio など）: IDE側からソリューションをビルドする方法です。エディタ自体を起動するためのビルドや、構成を細かく指定したビルドに用いられます。エディタ上で動かすための「Editor」向けターゲットと、スタンドアロン向けのターゲットが分かれている点も押さえておくとよいでしょう。
つまずきやすい落とし穴
「ビルド」に関連して初学者が混乱しやすいポイントを、原因と対処の観点でまとめます。
| 症状・誤解 | 背景・対処の方向性 |
|---|---|
| シーンが暗い／影が不自然 | スタティックライト構成でライティングを未ビルドの場合に起こりやすい。Build Lighting を実行して反映する。設定によっては「ライティングのビルドが必要」を示す警告が表示されることもある。Lumen など動的GIを使う構成では事情が異なる。 |
| AIキャラクターが移動しない | ナビメッシュ（NavMesh）が未生成・未更新の可能性。Build Paths を実行し、ナビ対象の領域がカバーされているか確認する。 |
| Development では出るログが配布版で出ない | ビルド構成の違いによる挙動。Shipping ではコンソールや一部デバッグ機能が無効化される。配布版の検証は実際の配布構成で行う。 |
| パッケージ化に非常に時間がかかる | クックやコンパイルを含むため、初回や大規模プロジェクトでは時間を要する。差分を活かしたビルドや、対象プラットフォームを絞ることで短縮できる場合がある。 |
| コードを直したのに反映されない | コンパイルし忘れているか、Live Coding が対応しない種類の変更（ヘッダ・クラス構造など）の可能性。エディタを閉じて通常のビルドを試す。 |
よくある質問（FAQ）
Q1. エディタの「Build」を押せば、配布できる実行ファイルができますか？
いいえ。メインメニューの Build は主にライティングやナビメッシュなどの事前計算を行うもので、配布用の実行ファイルは生成されません。実行ファイルを作るには Platforms メニューの Package Project を使います。両者は別の操作です。
Q2. Development と Shipping はどう使い分けますか？
開発・テスト中はデバッグ機能やログを使いやすい Development が扱いやすく、配布物は最適化され不要な機能が省かれる Shipping が一般的です。両者で挙動が変わることがあるため、最終確認は配布に用いる構成で行うのが安全です。
Q3. C++を使わずBlueprintだけなら「コンパイル」のビルドは不要ですか？
C++ソースのコンパイルという意味でのビルドは基本的に不要ですが、ライティングやナビメッシュなどの事前計算ビルドや、配布のためのパッケージ化は引き続き必要になり得ます。「ビルド」が指す対象を取り違えないようにしましょう。なお、機能名や手順はUE5のバージョンによって変わることがあるため、最終的には公式ドキュメントでの確認をおすすめします。