【Unity】”error building player because scripts had compiler errors” の直し方

By /

Unityで「error building player because scripts had compiler errors」エラーが発生！徹底解説と解決方法

はじめに：ビルドエラー「error building player because scripts had compiler errors」とは何か

Unityで開発を進め、いよいよアプリケーションを完成させて配布可能な形式（Windowsなら.exe、Androidなら.apk/.aab、iOSなら.ipaなど）にするための「ビルド」という作業を行う際、時に開発者を悩ませるエラーに遭遇します。その中でも非常に一般的で、かつ多くの原因が考えられるのが、ビルドが開始される前に表示される以下のエラーメッセージです。

error building player because scripts had compiler errors

このエラーは、Unityがプロジェクト内のC#スクリプトをコンパイル（コンピュータが理解できる形式に変換）しようとした際に、何らかの理由でコンパイルに失敗したことを示しています。つまり、あなたのプロジェクトに含まれるスクリプトコードに、UnityやC#のルールに則っていない記述があり、それが原因でビルドプロセスが進められない状態であることを意味します。

ビルドプロセスにおいて、スクリプトのコンパイルは最初の重要なステップです。ソースコードが正しくコンパイルできなければ、アプリケーションの実行に必要な中間コードやバイナリが生成されず、結果としてビルドは失敗します。このエラーメッセージが表示された場合、ビルド設定やUnityエディタ自体の問題も可能性としてはゼロではありませんが、大多数の原因はプロジェクト内のスクリプトファイル自体にあると考えて間違いありません。

この記事では、この「error building player because scripts had compiler errors」エラーが発生した場合に、開発者がどのように原因を特定し、問題を解決していくかについて、考えられるあらゆるシナリオと具体的な対処法を詳細に解説します。約5000語のボリュームで、初心者から経験者まで役立つ包括的なガイドを目指します。

1. エラーメッセージの確認：どこで、何を見るべきか

ビルドエラーが発生した際に、まず最初に行うべきことは、Unityエディタが提供するエラーメッセージの詳細を確認することです。

1.1. Console ウィンドウの確認

最も重要な情報は、Unityエディタ内の「Console」ウィンドウに表示されます。通常、このウィンドウはエディタの下部またはレイアウトに合わせて配置されています。

  1. Console ウィンドウを開く: Window -> General -> Console を選択するか、ショートカットキーを使用します。
  2. エラーメッセージを探す: Console ウィンドウには、ログ、警告、エラーの3種類のメッセージが表示されます。エラーは赤いアイコン（通常は！）で表示され、最も目立ちます。ビルドエラーが発生した場合、通常は複数の赤いエラーメッセージが表示されています。
  3. エラーメッセージの詳細を読む: 各エラーメッセージをクリックすると、より詳細な情報が表示されます。重要なのは以下の点です。
    • エラーコード: C#のコンパイルエラーには「CSxxxx」（例: CS0101, CS1061）のようなコードが付与されています。このコードはエラーの種類を示しており、後でオンラインで検索する際に役立ちます。
    • エラーの説明: エラーが具体的に何であるかを示すテキストメッセージです（例: 「名前空間 ‘〇〇’ には ‘△△’ の定義がありません」）。
    • ファイル名: エラーが発生しているスクリプトファイルの名前（例: PlayerController.cs）。
    • 行番号と列番号: エラーが発生しているスクリプトファイル内の正確な位置（例: (50, 25) は50行目の25文字目）。

1.2. ビルドログの確認（より詳細な情報）

Console ウィンドウの情報に加えて、ビルドプロセス全体のログファイルを確認することも非常に有効です。ビルドログには、Console ウィンドウに表示されない、コンパイル過程やビルド環境に関する詳細な情報が含まれている場合があります。

ビルドログの場所はオペレーティングシステムやUnityのバージョンによって異なりますが、一般的な場所は以下の通りです。

  • Windows: %LOCALAPPDATA%\Unity\Editor\<Unityバージョン>\Editor.log
  • macOS: ~/Library/Logs/Unity/Editor.log
  • Linux: ~/.config/unity3d/Editor.log

最新のログは、Unityエディタメニューの Help -> Open Editor Log から簡単に開くことができます。

ビルドログを開いたら、ファイルの最後の方にスクロールして、エラーが発生した箇所を探します。「Build finished with errors」や「Compilation failed」といったキーワードを検索すると見つけやすいでしょう。ビルドログには、特定のコンパイラ引数や、Consoleには表示されない中間的なエラー・警告が含まれていることがあります。

1.3. Console ウィンドウの表示設定

Console ウィンドウの表示設定も確認しておきましょう。

  • Collapse: 同じエラーメッセージを一つにまとめて表示するかどうか。オンにするとすっきりしますが、エラーが発生している複数のファイルや箇所を見落とす可能性があります。オフにして全て表示することをおすすめします。
  • Clear on Play / Clear on Build: 再生ボタンを押したときやビルド時にConsoleをクリアするかどうか。エラーの原因を特定する際は、過去のメッセージも残しておきたい場合があるため、これらのオプションは一時的にオフにしておくと便利かもしれません。
  • Error Pause: エラーが発生した際にゲーム実行を一時停止するかどうか。ビルドエラーには直接関係ありませんが、再生時のデバッグで役立ちます。

基本中の基本:
ビルドエラーが発生した場合、Console ウィンドウに表示されている赤いエラーメッセージを全て解消することが最初の目標です。Consoleに赤いエラーが一つでも残っている状態では、原則としてビルドは成功しません。表示されている最初のエラーから順番に修正していくのが効率的です。なぜなら、最初のエラーが原因で、後続の無数のエラー（いわゆる「連鎖エラー」）が発生していることがよくあるからです。

2. 最も一般的な原因：スクリプト内の構文エラー・論理エラー

「error building player because scripts had compiler errors」エラーの最も一般的かつ直接的な原因は、プロジェクト内のC#スクリプトファイルそのものに、C#言語のルールやUnity APIの利用法に関する間違い（コンパイルエラー）が含まれていることです。

2.1. C#の基本的な構文エラー

これは、C#言語の文法に違反している場合に発生するエラーです。人間で言うところの「文法ミス」のようなものです。

  • セミコロン（;）の忘れ: 各ステートメントの終わりにはセミコロンが必要です。
    “`csharp
    // エラー例: セミコロンがない
    int health = 100
    transform.position = new Vector3(0, 0, 0); // この行でコンパイルエラーになることが多い

    // 修正例
    int health = 100;
    transform.position = new Vector3(0, 0, 0);
    * **閉じ括弧（{}, [], ()）の忘れ/不一致:** ブロック、配列、メソッド呼び出しなどで使用される各種括弧が正しく閉じられていないか、対応が取れていない場合。csharp
    // エラー例: if文の閉じ括弧がない
    void Update()
    {
    if (Input.GetKeyDown(KeyCode.Space)
    {
    Jump();
    } // ここに } が必要
    } // エラー例: クラスやメソッドの閉じ括弧がない
    * **キーワードのタイプミス:** `class` を `clas` と書いたり、`public` を `pubilc` と書いたりするなど。C#はキーワードが厳密に定義されています。
    * **大文字・小文字の間違い:** C#は（ほとんどの場合）大文字・小文字を区別します。`gameObject` と `GameObject`、`update()` と `Update()` は全く異なるものを指します。Unity APIの名前は特に正確に入力する必要があります。    csharp
    // エラー例: 小文字でメソッド名を開始
    void start() // 正しくは Start()
    {
    // …
    }
    * **アクセス修飾子（public, privateなど）の誤用:** メソッドや変数へのアクセス権限に関する間違い。
    * **変数の型不一致:** 異なる型の値を代入しようとしたり、異なる型の変数同士で演算を行おうとしたりする場合。明示的な型キャストが必要なこともあります。    csharp
    // エラー例: string型変数に数値型を代入
    string message = 123; // エラー

    // 修正例
    string message = “123”; // 文字列として代入
    int number = 123; // 数値として代入
    string anotherMessage = number.ToString(); // 数値を文字列に変換
    * **無効な名前空間（Namespace）の使用:** 存在しないか、参照が追加されていない名前空間に含まれるクラスや構造体を使用しようとする。`using` ディレクティブが不足している場合もこれに該当します。csharp
    // エラー例: UnityEngine.UI を using していないのに Text を使う
    // using UnityEngine.UI; // これがないとエラー
    public class MyScript : MonoBehaviour
    {
    public Text scoreText; // ここでエラー
    }
    “`

2.2. Unity APIの誤った使用法

Unity独自のAPI（ MonoBehaviour, GameObject, Transform, Input, Physicsなど）の使用方法に関する間違いも一般的なエラー原因です。

  • 存在しないメソッドやプロパティへのアクセス: 例えば、transform は存在しますが、transfom は存在しません。また、GameObjectには renderer というプロパティはありますが、子オブジェクトのレンダラーにアクセスしたい場合は GetComponentInChildren<Renderer>() のようにする必要があります。

  • Null参照エラー（Null Reference Exception）: これは厳密にはコンパイルエラーではなく実行時エラーですが、ビルドプロセス中にもスクリプトの初期化や検証の段階で発生し、ビルド失敗の原因となることがあります。 特に、Awake や Start メソッド内でNullの可能性のあるオブジェクトのメソッドを呼び出している場合などです。例えば、InspectorからRigidbodyコンポーネントをアサインするのを忘れたまま、そのRigidbody変数を使って物理演算のメソッドを呼び出そうとするとNull参照になります。
    “`csharp
    // エラー例: rigid == null なのに rigid.AddForce を呼ぶ
    Rigidbody rigid; // Inspectorからアサインされていない場合

    void Start()
    {
    rigid.AddForce(Vector3.up * 5f); // rigid が null ならここで実行時エラーになる
    }
    ``
    * **間違ったコンポーネントタイプの指定:**    GetComponent()とすべきところをGetComponent()とタイプミスしたり、存在しないコンポーネントタイプを指定したりする場合。
    * **静的メンバーとインスタンスメンバーの混同:**    GameObject.Find()は静的メソッドなのでクラス名（GameObject）から直接呼び出せますが、gameObject.tag` は特定のインスタンス（今スクリプトが付いているゲームオブジェクト）に対するプロパティなので、インスタンス名（gameObject）から呼び出す必要があります。

2.3. デバッグ手法と修正方法

スクリプト内のコンパイルエラーを修正するための基本的なデバッグ手法は以下の通りです。

  1. Console ウィンドウのエラーを特定する: 前述の通り、Console ウィンドウを開き、赤いエラーメッセージをクリックして詳細を表示します。ファイル名と行番号を正確に確認します。
  2. IDEで該当箇所を開く: エラーメッセージをクリックすると、通常はUnityに設定されたコードエディタ（Visual Studio, Riderなど）が開き、エラーが発生しているファイルと行番号にカーソルがジャンプします。
  3. エラーの原因を分析する: IDE上でエラー行とその周辺のコードを確認します。Consoleメッセージの説明と照らし合わせながら、何が間違っているのかを考えます。
    • セミコロンや括弧の不足ではないか？
    • 変数名、メソッド名、クラス名にタイプミスはないか？ 大文字・小文字は合っているか？
    • 変数やオブジェクトが期待通りの型や値を持っているか？ Nullになっていないか？
    • Unity APIの正しい使い方をしているか？ ドキュメントと見比べる。
    • 参照している名前空間は正しく using されているか？
  4. コードを修正する: 原因が特定できたら、コードを修正します。
  5. Unityに戻る: コードエディタでファイルを保存し、Unityエディタに戻ります。Unityはファイルが変更されたことを検知し、自動的にスクリプトの再コンパイルを行います。
  6. Consoleを確認する: 再コンパイルの結果、Console ウィンドウのエラーが消えたか確認します。もし消えなければ、まだエラーが残っているか、修正が不適切だったということです。
  7. 最初のエラーから順番に: 複数のエラーが表示されている場合は、Consoleにリストされている最初のエラーから順番に修正していくのが鉄則です。最初のエラーが解決すると、それに起因する後続の多くのエラーが同時に消えることがよくあります。

IDEの活用: Visual StudioやRiderなどの統合開発環境（IDE）は、リアルタイムで構文エラーや潜在的な問題をハイライト表示してくれるため、エラーを早期に発見し修正するのに非常に役立ちます。また、コード補完機能（IntelliSense）を利用することで、タイプミスを防ぎ、正確なAPI名を入力できます。

  • デバッガー: IDEのデバッガー機能（ブレークポイント、ステップ実行、変数ウォッチなど）は、Null参照エラーのような実行時エラーの原因特定に非常に強力です。コンパイルエラーそのものの修正には直接使いませんが、ビルド失敗の原因が Null 参照などの実行時エラーに関連している場合に役立ちます。
  • エラーリスト/問題ウィンドウ: IDEには通常、プロジェクト全体のエラー、警告、メッセージを一覧表示するウィンドウがあります。これを活用すると、Consoleウィンドウよりも効率的にエラー箇所を特定できる場合があります。

3. APIの変更と互換性の問題

Unityは定期的に新しいバージョンがリリースされ、多くの新機能が追加されたり、既存の機能が改善・変更されたりします。Unityのバージョンをアップグレードした際に、以前のバージョンでは問題なく動作していたスクリプトがコンパイルエラーになることがあります。これは、Unity APIの変更による互換性の問題が原因です。

3.1. APIの非推奨化と削除

特定のAPI（クラス、メソッド、プロパティなど）が非推奨（Obsolete）とマークされることがあります。これは、将来のバージョンで削除される予定であること、またはより新しい代替手段が存在することを示しています。非推奨のAPIを使用していると、Unityは通常「警告」（Warning）を表示します。しかし、さらにバージョンアップが進むと、そのAPIが完全に削除され、使用している箇所で「エラー」（Error）が発生するようになります。

例：旧UIシステムから新しいUIシステムへの移行、旧ネットワークシステム（UNet）から新しいネットワークシステム（Netcode for GameObjectsなど）への移行、一部のVR/AR APIの変更など。

3.2. Automatic API Updater の活用

Unityはバージョンアップ時に、古いAPIを使用しているスクリプトを新しいAPIに自動的に書き換える「Automatic API Updater」というツールを提供しています。

  1. 古いバージョンのプロジェクトを新しいバージョンのUnityで初めて開くと、API Updaterの実行を確認するダイアログが表示されることがあります。
  2. ここで「Update」を選択すると、Unityは互換性のないAPIを自動的に修正しようと試みます。
  3. API Updaterが完了した後、Console ウィンドウを確認し、エラーが解消されたか確認します。

ただし、API Updaterは全てのケースに対応できるわけではありません。特に大規模なAPI変更や、複雑なロジックに関わる部分は自動修正が難しく、手動での修正が必要になります。

3.3. 手動でのAPI変更への対応

API Updaterで解決しない、またはAPI Updaterが実行されない場合は、手動でコードを修正する必要があります。

  1. Console ウィンドウのエラーメッセージを確認する: エラーメッセージには、どのAPIが問題になっているか（例: 「’〇〇Class’ に ‘△△Method’ の定義がありません」）、またはそのAPIが非推奨である旨の警告が表示されていることがあります。
  2. Unityドキュメントを参照する: 問題となっているAPI名が分かったら、Unityの公式ドキュメントサイト（docs.unity3d.com）でそのAPI名を検索します。
    • 古いバージョンのドキュメントと新しいバージョンのドキュメントを見比べる。
    • APIのページに「Obsolete」マークや、代わりにどのAPIを使うべきかに関する情報が記載されていないか確認する。
    • 関連するアップグレードガイドや移行ガイドを探す。

  3. コードを修正する: ドキュメントやエラーメッセージの指示に従い、新しいAPIにコードを書き換えます。
    “`csharp
    // 例: 旧バージョンのNetwork.InitializeServerが非推奨になった場合
    // エラーになる可能性があるコード (旧API)
    // Network.InitializeServer(connections, port);

    // 新しいAPIに書き換え（Netcode for GameObjectsなど、全く異なるシステムになることも多い）
    // Using Unity.Netcode;
    // NetworkManager.Singleton.StartServer();
    “`
    APIの変更によっては、単にメソッド名を置き換えるだけでなく、パラメータの順番や型が変わったり、全く新しいクラスやシステムを使わなければならなくなったりすることがあります。大規模なAPI変更に対応するには、その新しいシステムに関するドキュメントをしっかりと読む必要があります。

3.4. アセットやライブラリの互換性

サードパーティ製のアセットや外部ライブラリ（DLLなど）も、Unityのバージョンアップによって互換性の問題を引き起こすことがあります。

  • アセットストアで購入したアセットが、使用しているUnityバージョンに対応していない場合。
  • 外部からダウンロードしたDLLが、古いバージョンの.NET Framework/.NET Standard でコンパイルされており、現在のUnityバージョンで使用されている .NET 環境と互換性がない場合。

このような場合は、アセットの配布元（アセットストアのページ、開発者のウェブサイト）で、使用しているUnityバージョンに対応しているか確認する必要があります。対応していない場合は、アセットのアップデートを待つか、一時的にそのアセットをプロジェクトから削除することを検討します。

4. 外部ライブラリ（DLL, Package）の問題

プロジェクトに外部のDLLファイルやPackageManager経由で導入したパッケージが含まれている場合、それらが原因でコンパイルエラーが発生することがあります。

4.1. DLLファイルの問題

プロジェクトの Assets フォルダ内や、それ以外の場所（プラグインフォルダなど）に直接配置されたDLLファイルが、以下の問題を引き起こすことがあります。

  • 互換性のないDLL:
    • 使用しているUnityのスクリプティングバックエンド（Mono or IL2CPP）やAPI互換性レベル（.NET Standard 2.1 or .NET 4.x）と互換性のないDLL。
    • ターゲットプラットフォーム（Standalone, Android, iOSなど）と互換性のないDLL。
  • DLLの破損または不完全なコピー: ファイル転送中の問題などでDLLファイルが壊れている。
  • 同じライブラリの複数バージョン: プロジェクト内の異なる場所に、同じライブラリの異なるバージョンのDLLが存在し、競合が発生している。
  • 依存関係の不足: DLLが依存している別のDLLファイルがプロジェクトに含まれていない。

対処法:

  1. エラーメッセージを確認する: コンソールエラーに特定のDLLファイル名が含まれているか確認します。
  2. DLLのインポート設定を確認する: UnityエディタのProjectウィンドウで該当のDLLファイルを選択し、Inspectorウィンドウでインポート設定を確認します。
    • Platforms: 「Any Platform」以外に、ターゲットプラットフォームが正しくチェックされているか確認します。特定のプラットフォームでのみ使用するDLLの場合は、それ以外のプラットフォームのチェックを外します。
    • Compatible with: 「Any Platform」のチェックが外れている場合、Editor、Standalone、iOS、Androidなどのチェックボックスで、このDLLがどの環境で有効になるかを設定します。例えば、エディタ専用のDLLならEditorだけをチェックします。
    • Scripting Backend: 特定のスクリプティングバックエンド（Mono or IL2CPP）でのみ使用できるDLLの場合、その設定を確認します。
    • API Compatibility Level: プロジェクト設定 (Edit -> Project Settings -> Player -> Other Settings -> Configuration) のAPI Compatibility Levelと、DLLがビルドされた際のAPI互換性レベルが一致しているか確認します。
  3. DLLを再インポートする: プロジェクトウィンドウでDLLを選択し、右クリックメニューから「Reimport」を選択します。
  4. DLLを削除し、再度追加する: DLLファイルをプロジェクトフォルダから完全に削除し、再度コピー＆ペーストします。
  5. DLLのソース元を確認する: DLLがアセットストアやGitHubなどから取得したものである場合、配布元で最新バージョンや互換性情報を確認し、必要に応じて最新のDLLに差し替えます。
  6. 競合するDLLを特定し排除する: 同じライブラリの異なるバージョンのDLLが複数存在しないか、プロジェクトフォルダ全体を検索して確認します。不要な方、古い方を削除します。

4.2. Unity Package Manager (UPM) の問題

Unity Package Manager (UPM) 経由でプロジェクトに追加されたパッケージも、コンパイルエラーの原因となることがあります。

  • パッケージの破損または不完全なダウンロード: UPMがパッケージファイルを正しくダウンロードまたはキャッシュできていない。
  • パッケージ間の依存関係の問題または競合: あるパッケージが依存している別のパッケージが不足している、または複数のパッケージが同じライブラリの異なるバージョンに依存していて競合している。
  • パッケージのバージョンとUnityバージョンの非互換性: インストールしたパッケージが、現在使用しているUnityバージョンに対応していない。
  • ローカルパッケージやカスタムレジストリの問題: 独自に作成したローカルパッケージや、設定したカスタムレジストリに問題がある。

対処法:

  1. Package Manager ウィンドウを開く: Window -> Package Manager を選択します。
  2. 問題のあるパッケージを特定する: Consoleエラーに特定のパッケージ名が含まれている場合、そのパッケージを探します。含まれていない場合でも、最近追加・更新したパッケージが怪しいです。
  3. パッケージのバージョンを確認する: 選択したパッケージのバージョンが、使用しているUnityバージョンと互換性があるか確認します。Package Managerウィンドウに表示される互換性情報や、パッケージのドキュメントを参照します。
  4. パッケージを更新または再インストールする:
    • パッケージに新しいバージョンがある場合、それをインストールします。
    • 現在のバージョンに問題がある可能性がある場合、一度パッケージを「Remove」し、再度インストールし直します。
  5. 依存関係を解決する: エラーメッセージが特定の依存関係の不足を示唆している場合、その不足しているパッケージをインストールします。
  6. 競合するパッケージを特定する: 複数のパッケージが同じライブラリに依存している場合、どのパッケージが競合の原因となっているか特定し、一方を削除するか、競合しないバージョンの組み合わせを探します。.asmdef ファイルを使用している場合、アセンブリ間の参照設定が正しく行われているか確認します。
  7. ローカルキャッシュをクリアする: UPMのローカルキャッシュが破損している可能性がある場合、Unityエディタを閉じ、キャッシュフォルダを削除してから再度Unityを起動します。キャッシュフォルダの場所はOSによって異なります（例: Windows %LOCALAPPDATA%\Unity\cache）。Window -> Package Manager で「Advanced Settings」->「Show dependencies」や「Show Unity Registry packages」が正しく設定されているか確認することも有効です。

4.3. アセンブリ定義ファイル (.asmdef) の問題

.asmdef ファイルを使用している場合、アセンブリ間の参照設定が正しく行われていないとコンパイルエラーが発生します。例えば、あるアセンブリ（A.asmdef）のスクリプトから、別の分割されたアセンブリ（B.asmdef）に含まれるクラスを参照したい場合、A.asmdefのインスペクターで「Assembly Definition References」にB.asmdefを追加する必要があります。この設定が不足していると、「名前空間 ‘〇〇’ には ‘△△’ の定義がありません」といったエラーが発生します。

対処法:

  1. エラーメッセージを確認する: エラーが発生しているスクリプトがどの.asmdefに含まれているか、そして参照できていないクラスや名前空間がどの.asmdefに含まれているか特定します。
  2. 参照元の.asmdef設定を確認する: エラーが発生しているスクリプトが含まれる.asmdefファイルを選択し、Inspectorウィンドウを開きます。
  3. 「Assembly Definition References」に参照先.asmdefを追加する: 参照したいクラスや名前空間が含まれる.asmdefファイルを、「Assembly Definition References」リストにドラッグ＆ドロップするか、「+」ボタンをクリックして追加します。
  4. 依存関係が循環していないか確認する: AがBを参照し、同時にBがAを参照しているような循環参照はエラーの原因となることがあります。アセンブリ間の依存関係を見直します。
  5. Platform Compatibilityを確認する: 各.asmdefファイルのインスペクターで、対応するプラットフォームが正しく設定されているか確認します。

5. ビルド設定とプレイヤー設定の問題

プロジェクトのビルド設定やプレイヤー設定が原因で、特定のターゲットプラットフォームでのみコンパイルエラーが発生することがあります。

5.1. ターゲットプラットフォーム固有のコード

PC（Standalone）ビルドでは問題ないのに、AndroidやiOSなどのモバイルプラットフォームに切り替えてビルドしようとするとエラーになる場合があります。これは、特定のプラットフォームでのみ利用可能なAPIを使用しているコードが、他のプラットフォーム用にコンパイルされる際に問題を引き起こしている可能性が高いです。

例：
* モバイルデバイスのセンサー（加速度計など）やカメラにアクセスするAPIがPCビルドでエラーになる。
* 特定のOSバージョンやデバイスモデルに依存するネイティブプラグインやライブラリを使用している。

対処法:

  • Define Symbols (#if … #endif): Unityはプラットフォーム固有のコンパイルシンボルを提供しています（例: UNITY_EDITOR, UNITY_STANDALONE, UNITY_IOS, UNITY_ANDROID など）。これらのシンボルを #if ... #endif ディレクティブと組み合わせて使用することで、特定のプラットフォームでのみコードをコンパイルするように制御できます。
    csharp
    #if UNITY_IOS
    // iOS固有のコード
    MyIOSNativePlugin.CallSomething();
    #elif UNITY_ANDROID
    // Android固有のコード
    MyAndroidNativePlugin.CallAnotherThing();
    #else
    // その他のプラットフォーム（エディタやPCなど）で実行されるコード
    Debug.Log("This code runs on platforms other than iOS/Android.");
    #endif
    この #if ブロックで囲むことで、エラーの原因となっているプラットフォーム固有のコードが、ビルドターゲットではないプラットフォーム向けにコンパイルされることを防ぎます。
  • プラットフォーム固有のスクリプト: 特定のプラットフォーム専用の機能を持つスクリプト全体を、そのプラットフォームに対応するフォルダ（例: Assets/Plugins/Android, Assets/Plugins/iOS, Assets/Standard Assets (Mobile) など）に配置することで、自動的にそのプラットフォームでのみコンパイルされるように制御することも可能です。

5.2. Scripting Backend の選択

Unityは、C#コードをターゲットプラットフォーム上で実行可能な形式に変換するために、主にMonoとIL2CPPという2つのScripting Backendを提供しています。

  • Mono: 比較的高速にビルドできますが、パフォーマンスや互換性に制約がある場合があります。
  • IL2CPP (Intermediate Language To C++): 中間言語をC++に変換してからコンパイルするため、ビルド時間はかかりますが、パフォーマンスが高く、多くのプラットフォームをサポートし、より幅広いライブラリと互換性があります。iOSビルドでは必須です。

Scripting Backend を変更すると、コンパイルのされ方が変わるため、それまで問題なかったコードやライブラリがエラーになることがあります。特に、特定のサードパーティ製ライブラリやネイティブプラグインは、MonoまたはIL2CPPのいずれか一方のみをサポートしている場合があります。

対処法:

  1. エラーメッセージを確認する: IL2CPP固有のエラーメッセージが出ていないか確認します。
  2. Scripting Backend を変更してみる: 問題が発生しているプラットフォームのPlayer Settings (Edit -> Project Settings -> Player -> 対象プラットフォームのアイコン -> Other Settings -> Configuration) で、Scripting Backend を変更してみてエラーが解消するか確認します。
  3. ライブラリ/プラグインのドキュメントを確認する: 使用している外部ライブラリやネイティブプラグインが、選択しているScripting Backend をサポートしているか、ドキュメントで確認します。サポートされていない場合は、代替となるライブラリを探すか、Scripting Backend の変更を検討します。

5.3. API Compatibility Level

Player Settings (Edit -> Project Settings -> Player -> 対象プラットフォームのアイコン -> Other Settings -> Configuration) には、「API Compatibility Level」という設定があります。これは、プロジェクトで利用できる.NET APIの範囲を制御します。

  • .NET Standard 2.1: よりモダンで軽量ですが、古いライブラリと互換性がない場合があります。
  • .NET Framework (4.x Equivalent): より広いAPIセットを提供し、多くの既存の.NETライブラリと互換性がありますが、ファイルサイズが大きくなる傾向があります。

プロジェクトで使用しているDLLなどの外部ライブラリが、設定されているAPI Compatibility Levelに対応していない場合、コンパイルエラーや実行時エラーの原因となります。

対処法:

  1. エラーメッセージを確認する: 特定のクラスやメソッドが見つからないといったエラーメッセージが、API互換性の問題を示唆していることがあります。
  2. API Compatibility Level を変更してみる: 設定をもう一方のレベルに変更して、エラーが解消するか確認します。
  3. ライブラリの要求仕様を確認する: 使用している外部ライブラリが、どのAPI Compatibility Level を要求しているか、ドキュメントで確認します。プロジェクト設定をライブラリの要求に合わせて変更します。

5.4. Managed Stripping Level

IL2CPP スクリプティングバックエンドを使用する場合、Player Settings に「Managed Stripping Level」という設定があります。これは、ビルドサイズを削減するために、使用されていないマネージドコード（C#スクリプトや参照されている.NET/Unityライブラリコード）をどれだけ積極的に削除（ストリップ）するかを制御します。

ストリッピングレベルを高く設定しすぎると、Unityが誤って使用されているコードまで削除してしまい、実行時エラーを引き起こすことがあります。まれに、コンパイルエラーの原因となる可能性もゼロではありません（例えば、リフレクションなどで動的に呼び出されるコードが静的には参照されていないと判断されストリップされてしまうなど）。

対処法:

  1. Managed Stripping Level を下げる: 設定を「Disabled」または「Low」に変更して、エラーが解消するか確認します。
  2. link.xml ファイルを使用する: ストリッピングによって削除されてほしくないクラスやメソッドがある場合、link.xml ファイルを作成し、そこに保持したい型を指定することで、ストリッピングの対象から除外できます。

6. Unityエディタやプロジェクト自体の問題

スクリプトに明らかなエラーが見当たらない、または上記の方法を試してもエラーが解消しない場合、Unityエディタやプロジェクトファイル自体に一時的な問題が発生している可能性があります。

6.1. 一時的な不具合

Unityエディタや連携しているコードエディタ（Visual Studioなど）が、一時的な内部状態の不整合によって誤ったエラーを表示したり、コンパイルに失敗したりすることがあります。

対処法:

  1. Unityエディタの再起動: 最も手軽で効果的な方法です。一度Unityエディタを完全に終了し、再度プロジェクトを開き直します。
  2. コードエディタ（IDE）の再起動: Visual StudioやRiderを使用している場合、それらのエディタも一度終了し、再起動します。

6.2. Library フォルダの破損

プロジェクトフォルダ直下にある Library フォルダには、インポートされたアセットのキャッシュ、コンパイルされたスクリプトの中間ファイル、設定情報など、プロジェクトの様々な一時ファイルやキャッシュが保存されています。このフォルダの内容が破損したり、不整合を起こしたりすると、様々な問題が発生する可能性があり、その中にコンパイルエラーやビルドエラーも含まれます。

対処法:

  1. Library フォルダを削除する: Unityエディタを完全に終了した状態で、プロジェクトフォルダ直下にある Library フォルダをエクスプローラー/Finderで削除します。
  2. Unityを再度起動する: プロジェクトを開き直します。Unityは Library フォルダが存在しないことを検知し、プロジェクトのアセットを再インポートして Library フォルダを再生成します。

注意: Library フォルダの再生成には、プロジェクトの規模によっては非常に長い時間がかかる場合があります。また、シーンファイルのロック情報など、一部のローカルな情報がリセットされる可能性があります。この方法は比較的強力ですが、時間と影響を考慮して実行してください。Gitなどでバージョン管理している場合、.gitignore ファイルで Library/ は通常無視されているため、リポジトリに影響はありません。

6.3. プロジェクトファイルの破損

プロジェクトの根幹に関わる設定ファイルやメタファイルなどが破損している可能性もゼロではありません。

対処法:

  • プロジェクトの再インポート: Unityエディタメニューの Assets -> Reimport All を選択します。これにより、プロジェクト内の全てのアセットが強制的に再インポートされ、メタファイルなどが再生成されます。これもプロジェクト規模によっては時間がかかります。
  • クリーンアップと再生成: Temp, obj, Library フォルダを全て削除し、Unityを起動し直すことで、プロジェクトのほぼ全ての一時ファイルやキャッシュをクリアし、再生成させることができます。これも強力な方法ですが、時間と影響を考慮してください。
  • バックアップからの復旧: 定期的にプロジェクトのバックアップを取っている場合、エラーが発生する前の状態に戻すことで問題を解決できることがあります。
  • 新しいプロジェクトへのアセット移行: 最終手段として、新しいUnityプロジェクトを作成し、エラーが発生していないアセット（特にScriptsフォルダの内容）を慎重に新しいプロジェクトにコピー＆ペーストして移行する方法があります。ただし、これは設定やシーンの再構築など、手間がかかる作業になる可能性があります。

6.4. Unityエディタのインストール問題

ごくまれに、インストールされているUnityエディタ自体に問題がある場合があります。

対処法:

  • Unity Hubからの確認/修復: Unity Hubを開き、インストールされているエディタバージョンのオプション（歯車アイコンなど）から、「Modules」を確認したり、「Locate」でインストール場所を再指定したり、場合によってはアンインストールして再インストールしたりします。
  • 別のバージョンのUnityで試す: LTS（長期サポート）バージョンなど、別の安定版Unityエディタでプロジェクトを開いてみて、エラーが解消するか確認します。これにより、特定のUnityバージョンに起因する問題であるか切り分けできます。

7. 開発環境（OS, IDE, .NET）の問題

Unityやプロジェクトファイルだけでなく、開発に使用しているOS環境や外部ツールに問題があることも考えられます。

7.1. コードエディタ（IDE）の問題

Visual StudioやRiderなどのコードエディタは、Unityと連携してスクリプトのコンパイルをサポートしています。IDEの設定やインストールに問題がある場合、Unityでのコンパイルプロセスに影響を与える可能性があります。

対処法:

  • UnityのExternal Tools設定: Unityエディタの Edit -> Preferences (macOSでは Unity -> Settings) -> External Tools で、使用するコードエディタが正しく設定されているか確認します。「External Script Editor」が正しく選択され、「Generate .csproj files for」が適切に設定されているか確認します。
  • コードエディタの修復/再インストール: 使用しているIDEに問題があると思われる場合、IDEのインストーラーを使用して修復を試みたり、一度アンインストールして再インストールしたりします。
  • コードエディタのキャッシュクリア: IDEにも一時ファイルやキャッシュがあります。それらをクリアすることで問題が解決する場合があります（IDEによって手順は異なります）。

7.2. .NET SDK / Developer Pack の問題

Unityのスクリプティングバックエンド（MonoやIL2CPP）は、内部的に.NETのコンパイラやライブラリを使用します。使用しているUnityバージョンやプロジェクト設定（API Compatibility Level）によっては、特定の.NET SDKやDeveloper Packがシステムにインストールされている必要があります。これらが正しくインストールされていない、またはバージョンが古い/競合している場合、コンパイルエラーの原因となることがあります。

対処法:

  1. Unityの要求仕様を確認する: 使用しているUnityバージョンの公式ドキュメントで、必要な.NET SDKやDeveloper Packのバージョンを確認します。
  2. .NET SDK/Developer Pack をインストール/修復する: Microsoftの公式ウェブサイトなどから、要求されているバージョンの.NET SDKやDeveloper Packをダウンロードし、インストールまたは修復します。
  3. 環境変数の確認: まれに、環境変数（特にPATH）の設定が影響している場合があります。

7.3. OS環境やセキュリティソフト

オペレーティングシステム自体の問題や、インストールされているセキュリティソフト（ウイルス対策ソフト、ファイアウォール）が、Unityやコードエディタ、またはコンパイラが必要なファイルへのアクセスを妨害している可能性もゼロではありません。

対処法:

  • セキュリティソフトの一時停止: 自己責任において、一時的にセキュリティソフトを無効化し、ビルドを試してみてエラーが解消するか確認します。もし解消する場合、セキュリティソフトの設定でUnityやプロジェクトフォルダを例外として追加することを検討してください。
  • OSのアップデート: OSが最新の状態であるか確認します。
  • 管理者権限: UnityエディタやIDEを管理者権限で実行してみることで、ファイルアクセス権の問題が解決する場合があります。

8. 体系的なデバッグプロセス

ビルドエラーが発生した際に、闇雲に設定を変更したりファイルを削除したりするのではなく、体系的なアプローチで問題に取り組むことが重要です。

8.1. 落ち着いて、エラーメッセージを徹底的に読む

慌てず、Consoleウィンドウに表示されている最初のエラーメッセージからじっくりと読みます。ファイル名、行番号、エラーコード、エラー説明の全てが原因特定の手がかりになります。ビルドログも合わせて確認し、Consoleにはない情報がないか探します。

8.2. 原因の切り分け

  • いつからエラーが発生したか？: 直前に何を変更したか（コード、アセット、パッケージ、Unityバージョン、ビルド設定など）を振り返ります。変更点が原因である可能性が非常に高いです。
  • どのスクリプト/ファイルが原因か？: エラーメッセージに記載されているファイル名や行番号から、問題が発生している箇所を特定します。
  • 特定のプラットフォームでのみ発生するか？: ビルドターゲットを別のプラットフォームに切り替えてみて、エラーが発生するか確認します。特定のプラットフォームでのみ発生する場合、そのプラットフォーム固有の設定やコードが原因である可能性が高いです。
  • 新規プロジェクトでは発生するか？: 非常にシンプルな新規Unityプロジェクトを作成し、問題のスクリプトだけをコピーしてくる、あるいは問題の原因と思われるアセットだけをインポートするなどして、エラーが再現するか確認します。新規プロジェクトで再現しない場合は、元のプロジェクト環境に問題がある可能性が高いです。

8.3. 問題箇所の特定と無効化

原因と思われるスクリプトファイルが特定できたら、問題箇所を特定するために以下の手法を試します。

  • コードのコメントアウト: 怪しいコードブロックやメソッド呼び出しを一時的にコメントアウトし、Unityに戻ってエラーが消えるか確認します。コメントアウトした範囲を少しずつ広げたり狭めたりしながら、正確なエラー箇所を特定します。
  • スクリプトの一時的な削除/無効化: 問題のスクリプトファイル自体をプロジェクトから一時的に削除（または他の場所に移動）するか、ファイル名の拡張子を.csから.cs.disabledなどに変更してコンパイル対象から外し、エラーが解消するか確認します。これにより、そのスクリプト自体がエラーの原因であるか、あるいはそのスクリプトを参照している別のスクリプトに問題があるかを切り分けできます。
  • 問題のアセット/パッケージを一時的に削除: 最近インポートしたアセットやパッケージが原因と思われる場合、それらを一時的にプロジェクトから削除（またはPackage ManagerでRemove）し、エラーが解消するか確認します。

8.4. バージョン管理システム (Git) の活用

Gitなどのバージョン管理システムを使用している場合、エラー解決において非常に強力なツールとなります。

  • 変更内容の確認: git status, git diff コマンドやGUIツールを使用して、最後にビルドが成功した状態から現在までにどのようなコードやファイルが変更されたかを確認します。これがエラー原因特定の手がかりとなります。
  • 過去のコミットに戻る: git checkout <コミットハッシュ> コマンドを使用して、エラーが発生しないことが分かっていた過去のコミットに戻ります。これにより、エラーが発生し始めた正確な変更点を特定できます。その後、エラーが発生したコミットに進みながら、どの変更が原因かを絞り込んでいきます。
  • クリーンなクローン: ローカルのプロジェクトリポジトリに何らかの異常がある可能性もゼロではありません。一度リポジトリを削除し、リモートリポジトリから新たにクローンし直して、エラーが再現するか確認します。

8.5. 情報収集とコミュニティの活用

自身で解決できない場合は、他の開発者の知恵を借りましょう。

  • エラーメッセージでオンライン検索: Consoleに表示されたエラーコード（CSxxxx）やエラーメッセージのキーワード（英語で検索する方が情報が多い傾向があります）を正確に入力して検索します。同じエラーに遭遇した他の開発者の解決策が見つかることが多いです（Stack Overflow, Unity Forum, Qiita, Zennなど）。
  • Unity公式ドキュメント: APIエラーの場合は、公式ドキュメントを参照します。
  • Unityフォーラム: Unityの公式フォーラムで質問を投稿したり、他の人の投稿を検索したりします。
  • Stack Overflow: プログラミング全般に関する質問サイトですが、UnityやC#に関する質問も活発に行われています。

9. よくあるエラーメッセージ例とその読み解き方

Console ウィンドウに表示される C# コンパイルエラー（CSxxxx）は多岐にわたりますが、ビルドエラーでよく遭遇する代表的なものをいくつか紹介します。

  • CS0101: 名前空間 ‘〇〇’ には既に定義が含まれています
    • 意味: 同じ名前のクラスや列挙型などが、同じ名前空間内で複数回定義されている。
    • 原因: 同じクラス名のスクリプトファイルがプロジェクト内の異なる場所にある、コピペミスでクラス定義を重複させてしまったなど。
    • 対処法: Consoleメッセージに表示されるファイルパスを確認し、重複している定義元を特定して削除するか、クラス名を変更します。
  • CS0246: 型または名前空間名 ‘〇〇’ が見つかりませんでした (using ディレクティブまたはアセンブリ参照が不足していますか？)
    • 意味: 指定したクラス名、構造体名、インターフェース名、または名前空間が見つからない。
    • 原因:
      • タイプミス（大文字小文字含む）。
      • 必要な using ディレクティブがスクリプトファイルの先頭に記述されていない（例: UIを使用するのに using UnityEngine.UI; がない）。
      • 参照しようとしているクラスや名前空間が含まれるアセンブリ（DLLや.asmdefで定義されたアセンブリ）が、現在のスクリプトから参照可能な状態になっていない（.asmdefの参照設定ミスなど）。
      • 参照しようとしているクラスが含まれるアセットやパッケージがプロジェクトに正しくインポートされていないか、互換性がない。
      • API Compatibility Levelの設定が原因で、参照したい型が含まれる.NETライブラリが使用できない。
    • 対処法: タイプミスを確認する。必要な using ディレクティブを追加する。.asmdef の参照設定を確認する。参照元のアセットやパッケージが正しく導入され、互換性があるか確認する。API Compatibility Levelを見直す。
  • CS1061: ‘〇〇Type’ には ‘△△MethodOrProperty’ の定義がありません。型 ‘〇〇Type’ の拡張メソッド ‘△△MethodOrProperty’ を最初の引数を検証せずに呼び出すことはできません。
    • 意味: あるオブジェクト（〇〇Type型）に対して、存在しないメソッドやプロパティ（△△MethodOrProperty）を呼び出そうとしている。
    • 原因:
      • メソッド名やプロパティ名のタイプミス。
      • アクセスしようとしているメンバーが private や protected であり、現在の場所からアクセスできない。
      • オブジェクトが期待している型ではない（例: GetComponent<Collider>() の戻り値を Rigidbody として使おうとしている）。
      • APIの変更により、そのメソッドやプロパティが削除されたか名前が変わった（特にUnityバージョンアップ後）。
      • Null参照が発生するオブジェクトに対して、メソッドやプロパティを呼び出そうとしている（これは厳密には実行時エラーだが、コンパイル段階で警告や関連エラーが出ることも）。
    • 対処法: メソッド名/プロパティ名のタイプミスを確認する。アクセス修飾子を確認する。オブジェクトの型を確認し、必要なら型キャストを行う。Unityドキュメントで該当APIの使用方法を確認する。Nullチェックを追加する。
  • CS1503: 引数 〇〇: ‘〇〇Type’ から ‘△△Type’ に変換できません
    • 意味: メソッドやコンストラクタを呼び出す際に渡した引数の型が、メソッドが要求するパラメータの型と一致しない。
    • 原因: メソッド呼び出し時の引数間違い。期待する型の値を渡せていない。
    • 対処法: メソッド定義やドキュメントを確認し、正しい型の引数を渡すように修正する。必要なら明示的な型キャストを行う。
  • CS0117: ‘〇〇Class’ に ‘△△MethodOrProperty’ の定義がありません
    • 意味: 特定のクラス（〇〇Class）の中に、指定したメソッドやプロパティ（△△MethodOrProperty）が存在しない。CS1061 に似ていますが、これはより直接的に「クラス定義の中にない」ことを示唆します。
    • 原因:
      • クラス名またはメンバー名のタイプミス。
      • アクセス修飾子が原因でアクセスできない。
      • 継承関係がないのに基底クラスのメンバーを呼び出そうとしている。
      • APIの変更。
      • 定義が存在するはずなのに見つからない場合、Libraryフォルダやプロジェクトの破損が考えられる。
    • 対処法: CS1061 と同様の対処に加え、クラス定義自体が正しいか確認する。

これらのエラーメッセージは、Console ウィンドウに表示される情報のほんの一部ですが、これらの典型的なパターンを理解することで、エラー解決の糸口を掴みやすくなります。重要なのは、メッセージを鵜呑みにせず、ファイル名、行番号、エラーコード、説明を総合的に判断し、コードと照らし合わせて原因を推測することです。

10. 予防策：エラーを未然に防ぐために

エラーが発生した後の対処も重要ですが、エラーを未然に防ぐための習慣を身につけることも、開発効率を高める上で非常に重要です。

  1. こまめなテストビルドの実施: 開発中の早い段階から、定期的にターゲットプラットフォームでのビルドを試みます。特に大きな変更（Unityバージョンアップ、アセット/パッケージの追加/更新、大規模なコードリファクタリングなど）を行った後は、すぐにビルドを試すことを強く推奨します。早期にエラーを発見することで、原因特定が容易になります。
  2. バージョン管理システム (Git) の積極的な利用: Gitを使用してコードの変更履歴を管理します。少し開発が進んだらコミットする、大きな機能追加の前にはブランチを切るなどの習慣をつけることで、問題が発生した場合に「いつからおかしくなったか」を簡単に追跡し、問題のない状態に戻すことができます。
  3. Unityやパッケージのアップデートは慎重に: UnityエディタやUPMパッケージをアップデートする際は、プロジェクトの互換性情報を確認し、重要なプロジェクトの場合はアップデート前にバックアップを取るか、コピーしたプロジェクトでテストしてから適用します。特にLTS（長期サポート）バージョン以外へのアップデートは、非互換性が発生しやすい傾向があります。
  4. アセットストアのアセットはレビューをよく確認する: アセットストアからアセットを導入する際は、対象のUnityバージョンに対応しているか、他のユーザーのレビューで問題報告が多くないかなどを確認します。評価の高いアセットでも、特定の環境や組み合わせで問題を起こす可能性はあります。
  5. 定期的なプロジェクトのバックアップ: Gitでの管理に加えて、プロジェクトフォルダ全体のコピーや、Unity Package機能（Assets -> Export Package...）を使用して、定期的にプロジェクトのバックアップを作成します。万が一プロジェクトが深刻な破損を起こした場合でも、復旧できるようになります。
  6. 可読性の高い、整然としたコードを書く: 一貫性のある命名規則、適切なインデント、分かりやすいコメントを心がけます。自分自身や他の人が後からコードを読んだりデバッグしたりする際に、問題箇所を素早く特定しやすくなります。
  7. IDEの警告も無視しない: Console ウィンドウにはエラーだけでなく「警告」（Warning）も表示されます。警告はビルドをブロックしませんが、潜在的な問題（非推奨APIの使用、到達不能なコードなど）を示唆していることが多く、将来的にエラーにつながる可能性があるため、可能な限り修正しておくことが望ましいです。
  8. Automatic API Updaterを適切に利用する: Unityバージョンアップ時にAPI Updaterの実行を求められたら、基本的に実行します。ただし、自動修正には限界があることを理解しておき、修正後に手動で確認・調整が必要な場合があることを覚えておきます。

11. まとめ：エラーは開発スキル向上の機会

「error building player because scripts had compiler errors」エラーは、Unity開発において誰もが一度は遭遇するであろう一般的な問題です。このエラーは、あなたのスクリプトコードにコンパイルできない理由があることを明確に教えてくれます。

この記事で解説したように、エラー解決のための鍵は以下の通りです。

  1. エラーメッセージを正確に読み取る: Console ウィンドウとビルドログから、エラーの種類、発生箇所（ファイル名、行番号）、原因に関する手がかりを特定します。
  2. 原因を体系的に切り分ける: エラーがいつから、どこで、どのような状況で発生するかを分析し、コードの問題か、設定の問題か、環境の問題かなどを切り分けます。
  3. 具体的な解決策を試す: 最も可能性の高い原因から順に、コードの修正、設定の変更、プロジェクトやエディタのクリーンアップなどを試みます。
  4. 諦めずに情報収集する: 自分自身で解決が難しい場合は、オンラインリソースやコミュニティを活用して解決策を探します。

多くのコンパイルエラーは、C#言語の基本的な文法ミスや、Unity APIの使い方の間違いが原因です。これらを一つずつ修正していく過程で、C#プログラミングやUnityの理解は深まります。また、環境設定や外部ライブラリに関するエラー対処を経験することで、より複雑な開発環境への対応能力が向上します。

エラーは一見すると開発を妨げるもののように感じられますが、その解決プロセスは、開発者としてのスキルを確実に向上させてくれます。エラーメッセージを恐れず、これを機会にデバッグ能力を高めていきましょう。

この詳細なガイドが、「error building player because scripts had compiler errors」エラーに遭遇した際に、迅速かつ効果的に問題を解決するための一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール