Unityのビルドに時間がかかるときは、インポート・シェーダーのコンパイル・IL2CPP・ビルド出力・ライティングのどこで待っているかを、まず既存のログで切り分けます。ゲーム実行中のFPS低下とは別の問題です。

この記事の要点
「ビルドが遅い原因はすべて光の計算」とは限りません。処理段階と、その処理にかかった時間を確認します。 旧画像はUnity 2017の資料です。Unity 6.0（6000.0）の操作説明と区別してください。 最初は既存のログやレポートを確認します。再計測が必要なら、作業を退避した検証用コピーで条件を一つずつそろえます。

1. 旧画像と使用中のUnityの版を確認する

元の記事はUnity 2017でLighting設定を確認する説明でした。次の画像のタイトルバーにはUnity 2017.1.1f1 Personal（64bit）と表示され、旧メニューのWindow → Lighting → Settingsが示されています。現在版の画面ではありません。

図1：Unity 2017.1.1f1のLightingウィンドウへの入口。Unity 6.0の公式資料ではWindow → Rendering → Lightingです。使用中の版とレンダーパイプラインを確認し、旧画面と項目が同じだと決めつけないでください。ここでは設定の閲覧にとどめます。出典：Unity 6.0：ベイク用のシーンとライトの設定。

2. GIのチェックを一律に外さない

次の旧画面は、現在の推奨設定や高速化の実測結果ではありません。元の記事にはRealtime Global IlluminationとBaked Global Illuminationの両方を外す案内がありましたが、原因を確認せず全シーンへ適用する対処にはしません。ライティングの方式を変えると見た目やライトの扱いも変わります。

図2：旧LightingウィンドウのSceneタブ。赤枠はRealtime Global IlluminationとBaked Global Illuminationの欄で、両方が未チェックです。画面内にはBaked/MixedライトがRealtime扱いになる旨の注意もあります。この画像だけでは、ビルドの遅延原因や短縮効果は分かりません。図2自体にはUnityの詳細版表示がなく、元記事のUnity 2017の説明に属する画像として掲載しています。

シーンごとの状態を確かめるという元記事の着眼点は有用です。ただし全シーンを同じ設定へ変えるのではなく、対象シーン、割り当てられたLighting Settings、必要な照明表現をそれぞれ確認します。Unity 6.0ではLightingウィンドウのAuto Generateは削除済みです。「Auto Generateを外す」を現在版共通の手順にはしません。出典：Unity 6.0へのアップグレード：Lightingの変更。

3. 何を待っているのかを分類する

記録済みの進捗表示やログを、次の区間に分けて読みます。以下は診断の分類であり、特定の原因が必ず当てはまるという一覧ではありません。

区間	既存の記録で確認すること	混同しないこと
アセットのインポート	どのファイルやインポーターの処理で待っていたか。直前にアセットや対象プラットフォームが変わっていないか。	ファイルをUnity用に処理する時間と、Playerのビルド時間は別に整理します。
シェーダーのコンパイル	Editor.logのCompiling shader付近。対象シェーダー、バリアント、処理時間の記録。	シェーダーのコンパイル待ちと、実行時にGPUが描画する時間は別です。
IL2CPP・ネイティブコンパイル	既存の設定記録でScripting Backendを確認し、IL2CPP変換やC++コンパイルの区間を調べます。	ビルド時間と実行速度は同じ指標ではありません。診断のためにバックエンドを切り替えません。
Playerのビルド出力	コンテンツ構築、コードコンパイル、圧縮、署名など、どの工程で時間を使っていたか。	初回・増分・クリーンビルド、対象プラットフォームが違う記録を同条件として比較しません。
ライティングのベイク・事前計算	遅かった時刻に照明計算が実行されていた記録があるか。対象シーンと照明データの状態。	照明計算が遅いことを、すべてのビルド遅延の原因とはしません。
実行中のFPS低下	既存のProfiler記録などでフレーム処理を確認します。	完成したゲームの実行時性能は、このページのビルド待ちとは分けて調べます。

シェーダーのログ確認方法はUnity公式：シェーダーバリアント数の確認、IL2CPPの変換工程はUnity公式：IL2CPPの概要を参照してください。ビルド工程と増分ビルドはUnity公式：ビルドの概要に説明があります。

4. 既存のEditor.logとBuildReportを確認する

1. 条件を記録する：Unityの詳細版、OS、対象プラットフォーム、レンダーパイプライン、Scripting Backend、対象シーン、直前の変更、遅かった操作と時刻を整理します。不明な項目は推測せず不明とします。
2. 既存のEditor.logを開く：起動済みのEditorではConsoleウィンドウのメニューからOpen Editor Logで確認できます。Editorを起動し直さず、OSのファイル管理から既存ファイルを読む方法でも構いません。ログの場所は下表を参照してください。
3. 該当時刻と工程を読む：エラー・警告と時間の記録を対応させます。単語が見つかっただけで主原因とは断定しません。シェーダーログのCPU時間と全体の経過時間も区別します。
4. すでにあるBuildReportを確認する：既存のビルドツールやCIが保存したレポートに、全体のsummary.totalTime、結果、各stepsの名前・時間があれば照合します。親子の工程があるため、すべての時間を単純合計して全体時間とみなさないでください。
5. 不足を明記する：該当時刻のログやレポートがなければ、原因未確定です。次の計測では対象の操作と記録項目を決め、共有プロジェクトなら担当者と実行範囲を確認します。通常のビルドと照明ベイクは別々に記録します。

OS	Editor.logの場所
Windows	%LOCALAPPDATA%\Unity\Editor\Editor.log
macOS	~/Library/Logs/Unity/Editor.log
Linux	~/.config/unity3d/Editor.log

ログの場所はUnity 6.0：ログファイルのリファレンス、レポートの項目はBuildReportとBuildSummaryで確認できます。Unity 6.0のBuildReport.GetLatestReportは直近のPlayerまたはAssetBundleのレポートを取得するAPIであり、このページで調べたい実行のものとは限りません。既存のレポートを使う場合も、対象と時刻を確認します。

ログ全文を公開しないでください。パス、ユーザー名、署名や認証に関わる情報、社内URLなどを点検し、共有は必要な工程名・時間・伏字化したエラー付近に限定します。

5. 原因候補に応じて次の確認を決める

ライティングの計算が長い記録があった場合は、シーンのLighting Settings、Lightmap Resolution、Contribute GIの対象などをまず閲覧します。これらは品質にも関わるため、数値の一律引下げやGIの無効化を行わず、必要な見た目と変更範囲を先に整理してください。ベイク対象の条件はUnity公式のライティング設定資料で確認します。

シェーダーやIL2CPPの工程が長い場合は、その工程の記録に絞って調べます。設定の変更には、表示の欠落・互換性・実行時性能など別の影響があり得るので、ビルド時間だけを理由に切り替えません。既定の増分ビルドは以前の処理結果を再利用するため、初手でLibrary、ShaderCache、GI Cacheやビルドキャッシュを削除して比較条件を崩さないでください。

比較するときに残す記録

変更前のソース・Assetsのmetaファイル・Packages・ProjectSettingsと、必要な生成済みデータを退避してから、元とは別の出力先を使う検証用コピーで比べます。実作業中のコピーや共有CIの設定を直接変えず、対象プラットフォーム・シーン・コード・アセットを固定してください。

1. 基準を一回記録：Unity版、ビルド条件、開始/終了時刻、結果、主要工程の時間、エラーを残します。初回と増分ビルドは区別します。
2. 仮説に関係する条件だけ比較：シェーダーなら対象variant、照明なら対象シーンの設定、IL2CPPなら該当工程を調べます。複数条件を同時に変えた結果を、一つの設定の効果と断定しません。
3. 時間以外も確認：ビルドが成功したか、画面の照明/材質が変わらないか、対象端末で必要な機能が動くかを確認します。時間が短くても表示や機能が欠ければ改善ではありません。

一回だけの差や他プロセスの負荷による揺れは結論にせず、変更内容と測定条件を残します。検証用コピーであっても、署名/配布/課金通信など外部へ影響する処理は切り離してください。キャッシュ全削除やセキュリティ機能の無効化は、原因を特定する前の定型対処にしません。

確認範囲

公式資料の確認対象はUnity 6.0（6000.0）、確認日は2026年10月26日です。画像は元記事の旧画面であり、現在版での画面再現、ビルド時間の実測、特定プロジェクトでの改善効果を保証するものではありません。実行時の調査はUnity Profilerの公式資料を参照し、ビルド待ちと分けて扱ってください。