Unityで「Editorでは動くのにビルドで動かない」原因7選｜最短で解決するチェックリスト

Q: Development Buildでは動くのにリリースビルドで動かないのはなぜ？

一番多い原因は 条件付きコンパイル です。 例えば次のようなコードがあるとします。 #if DEVELOPMENT_BUILD InitDebugSettings();#endif この場合、リリースビルドではこの処理が丸ごと実行されません。 結果として「初期化がされずに動かない」という状態になります。 対策としては、 本番でも必要な処理が含まれているか を見直すことが重要です。

Q: IL2CPPとMonoはどちらでテストすべき？

結論としては、 最終的に使う環境（ほとんどの場合IL2CPP）で必ず確認する のが重要です。 Monoはデバッグしやすい反面、実機との差が出ることがあります。 おすすめの使い分けは次の通りです。 開発中：Monoで高速にテスト 仕上げ前：IL2CPPで最終確認 この流れにしておくと、「最後に全部崩れる」リスクをかなり減らせます。

はじめに
まず最初に確認すべきポイント
Editorとビルドで何が違うのか
よくある原因7選
すぐ確認できる診断チェックリスト
よくある誤解・注意点
実務で使える判断基準
理解を深めるための参考情報
まとめ
よくある質問（FAQ）
1. 関連記事:

はじめに

Editorでは普通に動いていたのに、ビルドして実機で起動した瞬間に「あれ…動かない？」と固まる。この瞬間、かなり焦りますよね。

例えばこんな症状、心当たりはありませんか？

シーンが切り替わらず真っ暗なまま
ボタンを押しても反応しない
特定の処理だけ実機で動かない
最悪、起動直後にクラッシュする

しかも厄介なのが、Editorでは問題なく動いていること。コードもエラーなし。「どこが悪いのか分からない…」という状態にハマりやすいポイントです。

この現象の正体はシンプルで、「Editorとビルド後の実行環境は別物」であることにあります。

実際の開発でも、私は「とりあえず動いたからOK」と思ってビルドしたら、実機で全崩壊…という経験を何度もしています🙂

ここで重要なのは、やみくもに原因を探すことではなく、「差が出るポイント」を順番に切り分けることです。

原因はある程度パターン化されていて、チェックする順番さえ分かっていれば、意外と短時間で解決できます。

このあと、まず優先的に確認すべきポイントを整理し、その後に原因ごとの具体的な対処方法を順番に見ていきます。

まず最初に確認すべきポイント

時間をかけて原因を探す前に、先にここだけチェックしてみてください。実際の開発でも、この段階で解決するケースがかなり多いです。

優先度と発生頻度が高い順に並べています。

シーンがBuild Settingsに含まれているか
Editor専用APIを使っていないか
IL2CPP環境で問題が出ていないか
コードがストリッピングで削除されていないか
Development Buildに依存した処理がないか

特に最初の「シーン設定」は、本当に見落としがちです。プロジェクト内に存在していても、Build Settingsに入っていなければ実機には含まれません。

また、「Editorでは動くのに実機で動かない」場合は、ほぼ確実に環境差による問題です。

判断の目安としてはこんな感じです。

症状	疑うべきポイント
実機でのみ動かない	IL2CPP / ストリッピング / API制限
起動直後に止まる	シーン設定 / 初期化処理
一部の機能だけ動かない	コード削除 / プラットフォーム依存
表示が崩れる	シェーダー / グラフィックス設定

ここまでチェックしても解決しない場合は、原因を1つずつ切り分けていく必要があります。

次からは、実際にハマりやすい原因を「症状 → 原因 → 解決方法」の流れで具体的に見ていきましょう。

Editorとビルドで何が違うのか

同じプロジェクトなのに挙動が変わる理由は、「実行される環境」が根本的に違うからです。ここを理解しておくと、原因の切り分けがかなり楽になります。

MonoとIL2CPPの違い

Editorで再生しているときは、多くの場合「Mono」という仕組みでコードが動いています。一方、スマホや実機にビルドすると「IL2CPP」という別の仕組みに変わることが多いです。

ざっくり違いをまとめるとこんな感じです。

項目	Mono（Editor）	IL2CPP（ビルド）
実行方式	C#のまま実行	C++に変換して実行
柔軟性	高い（動的処理に強い）	制限あり
実機再現性	低い	高い

例えばこんなケースです。

リフレクション（文字列からメソッド呼び出し）を使っている
動的にクラスや処理を生成している

これらはMonoでは動いても、IL2CPPではうまく動かないことがあります。

「実機だけでエラーが出る」場合は、まずここを疑うのが基本です。

ビルド時に最適化される仕組み

ビルドでは、軽く・速く動かすためにさまざまな最適化が入ります。これが原因で、Editorとの差が生まれます。

使われていないコードの削除（ストリッピング）
シェーダーの削減
アセットの圧縮・変換

ここで重要なのが、「Unityが勝手に不要と判断する」という点です。

例えばこんなパターンがあります。

リフレクション経由でしか呼ばれないメソッド → 削除される
特定条件でしか使わないシェーダー → 除外される

Editorではすべて存在しているため問題なく動きますが、ビルドでは消えてしまうことがあります。

判断のコツ：どこで差が出ているか

迷ったときは、次の視点で整理すると一気に見えてきます。

実機だけで再現する → 環境差（IL2CPP・最適化）
表示だけおかしい → シェーダー・グラフィックス
一部機能だけ動かない → ストリッピング・API制限

この段階で「どのタイプの問題か」が分かるだけでも、調査時間はかなり短縮できます。

次からは、実際に多くの現場で遭遇する原因を具体的に見ていきます。

よくある原因7選

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

症状
起動すると真っ黒な画面のまま進まない、またはシーン遷移が起きない。

考えられる原因
Build Settingsの「Scenes In Build」に対象シーンが登録されていない。

解決方法

Unityメニューから「File > Build Settings」を開く
「Scenes In Build」に対象シーンが含まれているか確認
含まれていない場合は「Add Open Scenes」またはドラッグ＆ドロップで追加
シーンの順番（インデックス）も確認する

注意点
プロジェクト内に存在していても、Build Settingsに入っていなければ実機には含まれません。

再発防止策
ビルド前に必ずScenes In Buildを確認する習慣をつける。

Editor専用APIが混入している

症状
ビルド時にエラーが出る、または実機で特定の処理だけ動かない。

考えられる原因
UnityEditor名前空間のAPIやEditor専用処理が含まれている。

解決方法

スクリプト内で「using UnityEditor」が含まれていないか確認
Editor専用処理は #if UNITY_EDITOR で囲む
Runtime環境で使えるAPIに置き換える

注意点
Editorでは問題なく動くため、気づきにくいポイントです。

再発防止策
Editor専用処理とRuntime処理を明確に分離する設計にする。

Managed Code Strippingでコードが削除される

症状
特定の機能だけ動かない、またはNullReferenceExceptionが発生する。

考えられる原因
ビルド時に「使われていない」と判断されたコードが削除されている。

解決方法

Player Settingsで「Managed Stripping Level」を確認
削除されたくないクラスに [Preserve] 属性を付与
link.xml を作成して保持対象を明示する

注意点
リフレクション経由で呼び出しているコードは削除されやすいです。

再発防止策
依存関係が見えにくい設計は避け、明示的な参照を意識する。

IL2CPPの制限に引っかかる

症状
実機でのみクラッシュする、または特定の処理が動かない。

考えられる原因
IL2CPPの仕様により、一部の動的処理が制限されている。

解決方法

Build SettingsでScripting Backendを確認
Monoに切り替えて再現するかテスト
リフレクションや動的生成処理を見直す

注意点
モバイルビルドではIL2CPPが標準のことが多いです。

再発防止策
早い段階から実機ビルドでテストする習慣をつける。

シェーダー・グラフィックスの差異

症状
オブジェクトがピンクになる、表示が崩れる。

考えられる原因
シェーダーバリアントの削除や、GPU・APIの違い。

解決方法

Shader Variant Collectionを作成する
Graphics API設定を確認する
実機での表示を直接確認する

注意点
PCとスマホではグラフィックス仕様が大きく異なります。

再発防止策
見た目に関する部分は早めに実機確認を行う。

Development Build依存のコード

症状
開発ビルドでは動くが、リリースビルドで動かない。

考えられる原因
#if DEVELOPMENT_BUILD による条件分岐。

解決方法

該当コードを検索して確認
必要な処理がリリースでも実行されるよう修正

注意点
デバッグ用コードに依存していると見落としやすいです。

再発防止策
本番環境を想定したビルドでも必ずテストする。

プラットフォーム固有のアセット問題

症状
動画やテクスチャが表示されない、音声が再生されない。

考えられる原因
プラットフォームごとのフォーマット非対応や圧縮設定。

解決方法

インポート設定を確認する
対応フォーマットに変換する
ターゲット端末で再生確認を行う

注意点
同じアセットでも環境によって動作が変わります。

再発防止策
使用するプラットフォームを前提にアセット設定を行う。

すぐ確認できる診断チェックリスト

原因を1つずつ深掘りする前に、短時間で方向性を絞り込みます。上から順にチェックしていくと、3分ほどで「どのタイプの問題か」が見えてきます。

□ Build Settingsに必要なシーンがすべて入っているか
□ Consoleのエラーログ（ビルド時・実機ログ）を確認したか
□ Development Buildでビルドして再現するか
□ Scripting BackendがIL2CPPかMonoか把握しているか
□ 実機のみで再現するか（Editorでも再現するか）を切り分けたか
□ 表示崩れの場合、シェーダー・Graphics APIを確認したか
□ リフレクションや動的生成コードを使っていないか

チェックの進め方

迷ったときは、次の順番で進めると効率的です。

まずシーン設定とビルド設定を確認する
次にDevelopment Buildでログを取りながら再現確認する
「実機だけか／Editorでもか」で分岐する
実機のみならIL2CPP・ストリッピング・API制限を疑う
表示系ならシェーダー・Graphics設定を疑う

ログ確認のコツ

ログを見るときは、次のポイントを意識します。

最初に出ているエラーから確認する（連鎖エラーを避ける）
Missing / Not found / Null などのキーワードに注目する
Development Build＋Script Debuggingを有効にして再ビルドする

「何も出ていないように見える」場合でも、Development Buildにすると情報が出てくることがあります。

判断の目安

チェック結果	次に疑うポイント
実機だけで再現する	IL2CPP / ストリッピング / API制限
Editorでも再現する	ロジックバグ / 参照ミス
表示だけおかしい	シェーダー / Graphics API
起動直後に止まる	シーン設定 / 初期化処理

ここで「どの方向を調べるべきか」が決まれば、無駄な試行錯誤をかなり減らせます。

よくある誤解・注意点

Editorで動く＝正しいではない

一番多い思い込みがこれです。 Editorで問題なく動いていると「コードは正しい」と感じてしまいますが、実際には実行環境が違うだけで問題が表に出ていないことがよくあります。

特に次のようなケースは要注意です。

IL2CPPでのみエラーになる処理
ストリッピングで削除されるコード
Editor専用APIの混入

「EditorでOK」はあくまで途中段階と考えて、実機確認までが1セットという意識が大切です。

エラーが出ていない＝問題なしではない

実機では、エラーが画面に表示されないことも多いです。そのため「何も出ていない＝正常」と判断してしまいがちです。

実際には裏でこんなことが起きています。

ログにだけエラーが出ている
例外が握りつぶされている
条件分岐で処理がスキップされている

この状態を防ぐために、Development Buildでログを確認する習慣をつけると一気に見えるようになります。

一度動いたから大丈夫は危険

「昨日は動いていたのに今日は動かない」という経験、かなりあると思います。

Unityでは以下のような変化で挙動が変わります。

ビルド設定の変更
シーンの順序変更
スクリプトの最適化状態
ターゲット端末の違い

つまり、一度動いたことは保証にならないということです。

用語	意味
Mono	Editorで主に使われる実行環境（柔軟だが実機と差が出る）
IL2CPP	ビルド時に使われる実行環境（制限ありだが本番に近い）
ストリッピング	未使用コードを削除して軽量化する仕組み
条件付きコンパイル	特定の条件でのみコードを有効にする仕組み

実務で使える判断基準

原因を1つずつ調べていくのも大事ですが、現場では「どこから疑うか」で解決スピードが大きく変わります。ここでは、実際に私がよく使っている判断の優先順位を紹介します。

まず疑うべき優先順位

経験上、次の順番でチェックすると効率よく原因にたどり着きます。

シーン設定（Build Settings）
Editor専用APIの混入
ストリッピングによる削除
IL2CPPの制限
シェーダー・アセットの差異

特に最初の2つは、初心者〜中級者が一番ハマりやすいポイントです。

症状から原因を逆算する

闇雲に調べるより、「症状」から原因を絞るほうが圧倒的に速いです。

症状	優先的に疑うポイント
実機でのみ動かない	IL2CPP / ストリッピング / API制限
起動直後に止まる	シーン設定 / 初期化処理
一部機能だけ動かない	コード削除 / 条件分岐 / 参照ミス
表示だけおかしい	シェーダー / Graphics API

例えば「ボタンだけ効かない」場合、いきなりIL2CPPを疑うよりも、まず参照やUI設定を見るほうが自然です。

実機検証のコツ

実機での問題は、再現条件を固定できるかどうかが重要です。

Development Buildでビルドする
Script Debuggingを有効にする
ログを毎回確認する
同じ手順で再現できるか確認する

再現条件が曖昧なままだと、原因も曖昧なままになります。

迷ったときのシンプルな考え方

最終的に迷ったら、次の3つだけ意識すると整理しやすいです。

環境差か？（Editor vs 実機）
最適化で削られていないか？
条件分岐で実行されていないだけではないか？

この3つに当てはめて考えるだけでも、かなりの確率で原因に近づけます。

「とりあえず全部疑う」ではなく、「パターンで切り分ける」ことが、デバッグを楽にするコツです。

理解を深めるための参考情報

ここまでのチェックで原因の方向性はかなり絞れているはずです。さらに理解を深めておくと、次に同じ問題が起きたときにほぼ迷わなくなります。

特に「ビルド後に動かない問題」は、単発のトラブルではなく、設計や開発フローの考え方と強く関係しています。

原因の網羅パターンをもう一度整理する

別の視点で整理すると、ほとんどの問題は次の3つに分類できます。

環境の違い（Editorと実機）
ビルド時の最適化（削除・変換）
設定や参照ミス

この3分類を頭に入れておくだけで、未知のエラーにも対応しやすくなります。

開発効率を上げるための知識

ビルド差異で詰まる時間を減らしたい場合は、少し体系的に学んでおくと楽になります。

Unityプログラミング・バイブル R6号
✅ Amazonでチェックする｜✅ 楽天でチェックする

設定・ビルド・最適化の考え方がまとまっているので、「なぜそうなるのか」を理解する助けになります。

知識として整理しておくと、「次に同じ症状が出たときの初動」がかなり速くなります。

まとめ

一番大事なのは、Editorと実機は別環境で動いているという前提です。ここを意識するだけで、原因の見当がかなりつきやすくなります。

迷ったときは、まず次の順番で確認してみてください。

シーンがBuild Settingsに入っているか
Editor専用APIを使っていないか
ストリッピングでコードが削除されていないか
IL2CPPの制限に引っかかっていないか
シェーダーやアセットの差異がないか

この5つを押さえておけば、ほとんどのケースは解決できます。

また、原因特定のコツは「再現条件の切り分け」です。

実機だけで起きるのか
特定の機能だけか
表示だけの問題か

このように整理していくと、無駄な調査を減らせます。

開発をしていると、「昨日まで動いていたのに突然動かない」という状況はどうしても発生します。

そんなときこそ焦らず、パターンに当てはめて順番に潰していくことが一番の近道です。

ビルド周りのトラブルは最初こそ大変ですが、一度パターンを掴めばかなり楽になります。

よくある質問（FAQ）

Q Development Buildでは動くのにリリースビルドで動かないのはなぜ？

一番多い原因は条件付きコンパイルです。

例えば次のようなコードがあるとします。

#if DEVELOPMENT_BUILD
    InitDebugSettings();
#endif

この場合、リリースビルドではこの処理が丸ごと実行されません。結果として「初期化がされずに動かない」という状態になります。

対策としては、本番でも必要な処理が含まれているかを見直すことが重要です。

Q 実機でしか再現しないバグはどうやって調べる？

次の3つをセットで使うのが効果的です。

Development Buildを有効にする
Script Debuggingをオンにする
ログ（Console / Logcat / Xcode）を確認する

特にログは重要で、エラーが画面に出なくても内部では記録されています。

また、「どの操作で再現するか」を固定できると、原因の特定が一気に進みます。

Q IL2CPPとMonoはどちらでテストすべき？

結論としては、最終的に使う環境（ほとんどの場合IL2CPP）で必ず確認するのが重要です。

Monoはデバッグしやすい反面、実機との差が出ることがあります。

おすすめの使い分けは次の通りです。

開発中：Monoで高速にテスト
仕上げ前：IL2CPPで最終確認

この流れにしておくと、「最後に全部崩れる」リスクをかなり減らせます。

Unityで「Editorでは動くのにビルドで動かない」原因7選｜最短で解決するチェックリスト

はじめに

まず最初に確認すべきポイント