Unityでビルド後に動かない原因まとめ｜Editorでは動くのに実機で崩れる理由と対策

はじめに

「Editorではちゃんと動いてたのに、ビルドした瞬間に動かない…」

Unityを触っていると、一度はこの壁にぶつかります。
しかも厄介なのが、エラーが出ないことも多く「何が悪いのか分からない状態」になりがちなところです。

よくある症状としては、こんな感じです。

• アプリが起動しない・すぐ落ちる
• シーンが切り替わらない
• UIが表示されない・崩れる
• 一部の処理だけ動かない
• 特定の端末だけ挙動がおかしい

このとき、多くの人がまず疑うのが「自分のコードが間違っているのでは？」という点です。
でも実際には、コードではなくEditorと実機の環境差が原因になっているケースがかなり多いです。

UnityのEditorは「開発しやすい環境」、ビルド後は「実際に動く環境」です。
この2つは見た目は同じでも、中身は別物と考えたほうが理解しやすいです。

そのため、Editorでは問題なくても、ビルド後にだけ不具合が出るのは珍しくありません。

ここからは、

• まず何を確認すればいいのか
• どこが原因になりやすいのか
• どうやって切り分けるのか

を順番に整理していきます。

---

結論：まず最初に確認すべき5つ

原因を探し始める前に、まずはここをチェックしてください。
実際の現場でも「まずここを見る」で解決するケースがかなり多いです。

• シーンが「Build Settings」に入っているか
• EditorOnlyタグが付いていないか
• #if UNITY_EDITOR のコードを使っていないか
• Development Buildでログを確認したか
• 実機依存（解像度・テクスチャ・API）の問題ではないか

この5つは「発生頻度が高く、修正コストも低い」ものから並べています。
上から順に確認していくのが効率的です。

どの症状なら何を疑うべきか

原因を絞るときは、症状から逆算するのがポイントです。

症状	疑うべき原因
起動しない・すぐ落ちる	ビルド設定・アーキテクチャ・致命的エラー
画面が真っ暗	シーン未登録・カメラ設定
一部だけ動かない	スクリプト・Editor依存コード
UIが崩れる	解像度・Canvas設定・テクスチャ
端末によって違う	プラットフォーム依存・性能差

ここで大事なのは、「全部を疑う」のではなく「優先順位をつける」ことです。

特に初心者のうちは、

• 設定ミス（シーン・タグ）
• ログ未確認

この2つが原因で詰まるケースがとても多いです。

---

なぜEditorでは動くのに実機で動かないのか？

先に結論を言うと、Editorとビルド後のアプリは、同じように見えても動いている環境が違うからです。

この差を知らないまま調べ始めると、コードだけを延々と見直してしまいがちです。
でも実際には、コードそのものよりも「どの環境で、どう実行されるか」が原因になっていることが少なくありません。

Editorとビルド後は別の環境

UnityのEditorは、作業や確認がしやすいように作られた開発環境です。
一方で、ビルド後のアプリは、Windows・Android・iPhoneなどの実機で動く本番環境です。

この2つでは、次のような違いが出ます。

• 使えるAPIや機能が違う
• スクリプトの実行条件が違う
• メモリや処理性能の制約が違う
• 画面サイズや描画方式が違う

たとえば、Editor上では便利に使える処理でも、実機では使えないことがあります。
その典型が #if UNITY_EDITOR で囲まれたコードや、UnityEditor名前空間を使う処理です。

ここでの判断基準はシンプルです。
「Unityエディタ専用の機能に頼っていないか」をまず疑うと、切り分けが早くなります。

アセットとシーンの扱いが変わる

Editorでは、ProjectビューにあるアセットやHierarchy上のオブジェクトを、そのまま確認しながら作業できます。
でもビルド後は、必要なものだけがまとめられてアプリに入ります。

つまり、Editorで見えていたからといって、ビルド後にも必ず存在するとは限りません。

ここでよく起こるのが、次のような問題です。

• Build Settingsに入れていないシーンが読み込めない
• EditorOnlyタグが付いたオブジェクトが消える
• 参照されていないアセットが意図どおり含まれない

私も最初の頃、Hierarchyに置いていた管理用オブジェクトが実機で見つからず、「昨日まで動いてたのに？」となったことがあります。
原因はコードではなく、そのオブジェクトに付いていた設定のほうでした。こういうとき、Unityはなかなか無言で厳しいです。

この場面で大事なのは、「Editorで見えていること」と「ビルドに含まれていること」は別と考えることです。

プラットフォームごとの制約がある

ビルド後のアプリは、最終的に端末の性能や仕様に合わせて動きます。
そのため、同じプロジェクトでも、PCでは問題なくてもスマホでは不具合が出ることがあります。

影響しやすい比較軸は、主に次の4つです。

• CPUの種類やアーキテクチャ
• GPUや描画性能
• グラフィックスAPIの違い
• メモリ容量や端末性能

たとえば、Editorでは問題なく表示されていたUIや画像が、実機では崩れたり消えたりすることがあります。
この場合、コードのミスではなく、解像度設定や圧縮設定、描画方式の違いが原因になっていることがあります。

判断の目安としては、

• すべての端末で同じように壊れる → 設定やコードを優先して疑う
• 特定の端末だけ壊れる → 実機依存の差を優先して疑う

という見方が役立ちます。

---

よくある原因5選と解決方法

シーンがビルドに含まれていない

症状
・画面が真っ暗になる
・シーン遷移が動かない

原因
Build Settingsの「Scenes In Build」にシーンが登録されていない

解決方法

• Unity上部メニュー → File → Build Settings を開く
• 「Add Open Scenes」で現在のシーンを追加
• 必要なシーンすべてにチェックを入れる

注意点
シーンは「インデックス番号」で管理されるため、順番が変わるとバグの原因になります

再発防止
シーン名の直指定ではなく、定数やEnumで管理するのがおすすめです

---

EditorOnlyタグでオブジェクトが消えている

症状
・オブジェクトが存在しない扱いになる
・スクリプトがNullReferenceになる

原因
「EditorOnly」タグが付いているオブジェクトはビルド時に削除される

解決方法

• 該当オブジェクトのTagを確認
• EditorOnlyが付いていれば外す

注意点
デバッグ用で付けたまま忘れるケースが多いです

再発防止
重要なオブジェクトには専用タグを付けるなど、用途を明確にしておきましょう

「Hierarchyにある＝存在する」と思いがちですが、ビルド後は別です。この認識のズレがよくバグを生みます。

---

Editor専用コードを使っている

症状
・一部の処理だけ動かない
・機能が完全に無効になる

原因
#if UNITY_EDITOR 内のコードはビルド時に除外される

解決方法

• プロジェクト全体で「UNITY_EDITOR」を検索
• 実機でも必要な処理が含まれていないか確認
• 必要なら通常コードへ移動

注意点
UnityEditor名前空間もビルドでは使えません

再発防止
「Editor専用」と「実行時コード」を明確に分ける設計にする

---

実機依存の設定ミス（解像度・テクスチャなど）

症状
・UIが崩れる
・画像が表示されない
・一部だけ描画がおかしい

原因
・テクスチャ圧縮形式が端末に合っていない
・Canvasや解像度設定が実機とズレている

解決方法

• Player Settingsの解像度設定を確認
• テクスチャのCompression設定を見直す
• Canvas Scalerを適切に設定する

判断基準
特定の端末だけで問題が出る場合は、この原因の可能性が高いです

再発防止
複数解像度・複数端末でのテストを習慣化する

---

ログを確認していない

症状
・原因が全く分からない
・何も手がかりがない状態になる

原因
実機側のエラーログを確認していない

解決方法

• Build Settingsで「Development Build」にチェック
• 「Script Debugging」を有効化
• 実機ログ（Console / Logcat）を確認

ログを見ることで「なぜ動かないのか」がほぼ確実に分かります。

注意点
EditorのConsoleと実機ログは別物です

再発防止
「動かない＝まずログを見る」を習慣にする

---

3分でできる診断チェックリスト

原因を1つずつ深掘りする前に、短時間で確認できるポイントを順番にチェックしていきましょう。
上から順に見るだけで、かなりの確率で原因にたどり着けます。

• □ シーンはBuild Settingsに入っているか
• □ エラーログ（実機）を確認したか
• □ Development Buildで実行しているか
• □ EditorOnlyタグが付いていないか
• □ UNITY_EDITORを使っていないか
• □ 実機でも同じ症状が再現するか確認したか

チェックの進め方

大事なのは「順番」です。
闇雲に調べるより、次の流れで確認すると効率よく原因を絞れます。

1. まずシーン設定（Build Settings）を確認
2. 次にログを確認（Development Build）
3. コードの条件分岐（UNITY_EDITOR）を確認
4. タグ・オブジェクトの状態を確認
5. 最後に実機依存を疑う

特に「ログ確認」は後回しにされがちですが、最初に見るだけで解決するケースも多いです。

ここで引っかかった場合の考え方

チェック中に1つでも「怪しい」と感じたポイントがあれば、そこを優先的に修正してください。
すべてを同時に直そうとすると、逆に原因が分からなくなります。

• 1つ修正する
• ビルドして確認する
• 変化を見る

このサイクルを回すことで、「どこが原因だったのか」がはっきりします。

---

よくある誤解・落とし穴

エラーが出ていない＝問題ない

EditorのConsoleに何も出ていないと安心しがちですが、実機側ではエラーが出ていることがよくあります。
特にAndroidやiOSでは、端末側のログ（LogcatやXcodeコンソール）にしか出ない情報も多いです。

判断基準：原因不明のときは、必ずDevelopment Buildで実機ログを確認する。

---

Editorで動く＝正しい実装

Editorはあくまで開発用の環境です。便利機能や補助が多く、本番環境とは条件が異なります。
そのため、Editorで動いたこと自体は「通過点」であって「完成」ではありません。

補足概念：スクリプトバックエンド（Mono / IL2CPP）やプラットフォーム依存の差。

---

一度動いたから設定は正しい

ビルド設定やアセットの状態は、変更や最適化の影響で簡単に変わります。
昨日動いていたものが、今日のビルドで動かないのは珍しくありません。

判断基準：再現したタイミング（いつから壊れたか）を基準に差分を疑う。

---

原因は1つだけ

実際には「複数の原因が重なっている」ケースもあります。
たとえば、シーン未登録＋初期化順序の問題が同時に起きていることもあります。

対処のコツ：一度に複数を直さず、1つずつ変更→確認を繰り返す。

---

アセットやデータは自動で含まれる

Editorで参照しているだけでは、ビルドに含まれない場合があります。
特にResourcesやAddressablesの扱いを誤ると、実機で読み込めないことがあります。

補足概念：Resources.Load、Addressables、アセットバンドルの仕組み。

---

中級者向け：原因切り分けの考え方

ここまでのチェックで原因が見つからない場合は、少し視点を変えて「どう切り分けるか」を意識する段階です。
やみくもにコードを見るのではなく、条件を分解していくことで原因が浮き上がります。

再現条件を分解する

まず最初にやるべきは、「いつ・どこで・どの条件で起きるのか」を整理することです。

• Editorでは起きる？起きない？
• すべての端末で起きる？特定の端末だけ？
• 毎回発生する？ランダム？

この3つを分けるだけでも、原因の方向性がかなり絞れます。

• 全環境で再現 → 設定やコードの問題
• 特定端末のみ → 実機依存
• ランダム発生 → 初期化順序や非同期処理

---

初期化順序を疑う

Unityでは、オブジェクトの初期化順序が原因でバグが発生することがあります。

よくあるパターン：

• Awakeで参照するが、相手がまだ生成されていない
• Startの順番が想定と違う
• DontDestroyOnLoadオブジェクトとの競合

Editorでは偶然うまくいくこともありますが、ビルド後は順序が変わることがあります。

判断基準：NullReferenceや「たまに動く」場合は初期化順序を疑う

---

非同期処理を疑う

ロード処理や通信処理を使っている場合、タイミングのズレが原因になることがあります。

• シーンロード完了前に処理している
• データ読み込み前に参照している
• Coroutineの待機が不十分

特に実機では処理速度が変わるため、問題が表面化しやすいです。

対策：完了確認（フラグ・コールバック）を必ず入れる

---

データ管理の問題を疑う

セーブデータや設定ファイルの扱いも、実機でのみ問題になることがあります。

• 保存先のパスが違う
• 書き込み権限の問題
• データの破損や読み込み失敗

こういった問題は、Editorでは見えにくく、実機で初めて発覚します。

判断基準：データを扱っている処理だけおかしい場合はここを疑う

---

まとめ

ビルド後に動かない問題は、「難しいバグ」というよりも原因の当たりをつける順番が重要です。

まず最初に確認するべきポイントを、もう一度整理しておきます。

• シーンがBuild Settingsに入っているか
• EditorOnlyタグが付いていないか
• UNITY_EDITORのコードが含まれていないか
• 実機ログを確認しているか
• 実機依存の設定ミスではないか

この順番でチェックするだけで、多くの問題はかなり早く解決できます。

症状から原因を判断する

• 起動しない → 設定・ビルド関連を優先して疑う
• 一部だけ動かない → スクリプトや条件分岐を疑う
• 端末によって違う → 実機依存を疑う

この「症状→原因」の考え方ができるようになると、無駄な調査が減ります。

再発防止のポイント

• ビルド後の確認を習慣にする
• ログを見るクセをつける
• 環境差がある前提で設計する

私自身も最初の頃は、「Editorで動いたからOK」と思ってビルドして詰む、を何度も繰り返しました。
でも原因のパターンを知ってからは、ほとんどの場合は数分で見当がつくようになります。

---

よくある質問（FAQ）