SingletonパターンはUnityで使うべき？

グローバルな管理クラス（サウンドマネージャー等）に限定して使用するのが推奨です。使いすぎは依存性を高めます。

通常のC# SingletonとUnity Singletonの違いは？

Unity版はMonoBehaviour継承でライフサイクルメソッドやDontDestroyOnLoadが使えます。

シーン移動時もSingletonを保持するには？

Awake内でDontDestroyOnLoad(gameObject)を呼び出します。重複生成防止のチェックも必要です。

【Unity】Unityで学ぶSingletonパターンの正しい実装と、知っておくべき注意点

概要

Unityでゲーム開発を進めていると、「どこからでもアクセスできる、ただ一つの管理役」が必要になる場面に必ず遭遇します。例えば、ゲーム全体のスコアを管理するクラス、BGMや効果音の再生を制御するクラス、あるいはゲームの進行状態（ポーズ中、ゲームオーバーなど）を保持するクラスなどです。

これらの管理クラスを、毎回GameObject.Find()で探したり、インスペクターから手動で参照を設定したりするのは非常に手間がかかります。また、誤って同じ管理クラスのオブジェクトを複数シーンに配置してしまうと、予期せぬバグの原因にもなりかねません。

この記事では、Singleton（シングルトン）パターンの基本概念と、Unityでの安全な実装方法を解説します。

Singletonパターンの基本概念

Singletonパターンは、クラスのインスタンスがアプリケーション全体でただ一つであることを保証し、そのインスタンスへのグローバルなアクセスポイントを提供する仕組みです。

通常のC#クラスでこれを実現するには、主に以下の要素が必要です。

静的なインスタンス変数: クラス自身を保持するためのstaticな変数。
プライベートなコンストラクタ: 外部からのnewによるインスタンス生成を防ぐため。
静的なアクセスプロパティ: 唯一のインスタンスを返すためのstaticなプロパティ。

UnityにおけるMonoBehaviour Singletonの実装

UnityでSingletonパターンを実装する場合、多くの管理クラスはMonoBehaviourを継承する必要があります。これは、AwakeやUpdateといったUnityのライフサイクルメソッドを利用したり、インスペクターから設定を行ったりするためです。

ここでは、ジェネリック（Generic）を用いて、どんなクラスでもSingleton化できる汎用的な基底クラスを作成する方法を紹介します。この方法が、UnityでのSingleton実装のベストプラクティスの一つとされています。

汎用的なMonoSingletonクラス

以下のコードをMonoSingleton.csとして保存してください。

using UnityEngine;

// TはMonoBehaviourを継承したクラスである必要があるという制約
public abstract class MonoSingleton<T> : MonoBehaviour where T : MonoSingleton<T>
{
    // 唯一のインスタンスを保持する静的変数
    private static T instance;

    // 外部からアクセスするための静的プロパティ
    public static T Instance
    {
        get
        {
            // インスタンスがまだ存在しない場合
            if (instance == null)
            {
                // シーン内からT型のオブジェクトを探す
                instance = (T)FindObjectOfType(typeof(T));

                // それでも見つからない場合は、新しいGameObjectを作成してアタッチする
                if (instance == null)
                {
                    GameObject singletonObject = new GameObject();
                    instance = singletonObject.AddComponent<T>();
                    singletonObject.name = typeof(T).ToString() + " (Singleton)";
                }
            }
            return instance;
        }
    }

    // インスタンスが生成された直後に呼ばれる
    protected virtual void Awake()
    {
        // 既にインスタンスが存在する場合（重複生成の防止）
        if (instance != null && instance != this)
        {
            // 自身を破棄して、重複を防ぐ
            Debug.LogWarning($"[Singleton] 既にインスタンスが存在するため、{typeof(T).Name}を破棄します。");
            Destroy(gameObject);
            return;
        }

        // 自身を唯一のインスタンスとして設定
        instance = (T)this;

        // シーンを跨いでオブジェクトを永続化させる
        // ただし、エディタ上での挙動に注意が必要なため、実行時のみ適用
        if (Application.isPlaying)
        {
            DontDestroyOnLoad(gameObject);
        }

        // 初期化処理を子クラスに任せるためのメソッド
        OnInitialize();
    }

    // 破棄時に静的参照をクリアする
    protected virtual void OnDestroy()
    {
        if (instance == this)
        {
            instance = null;
        }
    }

    // 子クラスで初期化処理をオーバーライドするためのメソッド
    protected virtual void OnInitialize() { }
}

使い方（例：サウンドマネージャー）

次に、この基底クラスを継承して、実際の管理クラスを作成します。

using UnityEngine;

// MonoSingleton<SoundManager>を継承する
public class SoundManager : MonoSingleton<SoundManager>
{
    // 外部からアクセスするための公開メソッド
    public void PlayBGM(AudioClip clip)
    {
        Debug.Log($"BGMを再生しました: {clip.name}");
        // 実際のBGM再生処理...
    }

    public void PlaySE(AudioClip clip)
    {
        Debug.Log($"効果音を再生しました: {clip.name}");
        // 実際SE再生処理...
    }

    // 初期化処理をオーバーライド
    protected override void OnInitialize()
    {
        // サウンド設定のロードなど、初期化時に一度だけ実行したい処理を記述
        Debug.Log("SoundManagerの初期化が完了しました。");
    }
}

アクセス方法

これで、ゲーム内のどこからでも、シーンを気にすることなく簡単にアクセスできます。

// どこかの別のスクリプトから
public class PlayerController : MonoBehaviour
{
    public AudioClip jumpSound;

    void Jump()
    {
        // 唯一のインスタンスにアクセスし、メソッドを呼び出す
        SoundManager.Instance.PlaySE(jumpSound);
    }
}

ポイント: MonoSingleton<T>クラスのInstanceプロパティは、インスタンスが存在しない場合に自動的にシーン内を検索し、それでも見つからなければ新しいGameObjectを作成してアタッチします。これにより、手動でシーンに配置し忘れてもエラーにならず、安全性が高まります。

初心者が陥りやすい3つの落とし穴と対策

Singletonパターンは便利ですが、Unity特有のライフサイクルが絡むため、初心者が陥りやすい問題がいくつかあります。

1. シーン遷移時の重複インスタンス生成

最もよくある問題は、DontDestroyOnLoadを使っているSingletonクラスが、シーンを移動した際に重複して生成されてしまうことです。

間違いの例: シーンAでSoundManagerが生成され、DontDestroyOnLoadで永続化されます。次にシーンBをロードした際、シーンBにもSoundManagerのプレハブが配置されていると、2つ目のインスタンスが生成されてしまいます。
対策: 上記のMonoSingleton<T>の実装にあるように、Awakeメソッド内で既にinstanceが存在するかどうかをチェックし、存在する場合は Destroy(gameObject);で自身を即座に破棄 します。これにより、常に一つだけのインスタンスが保証されます。

2. 参照順序の問題（Script Execution Order）

Unityでは、スクリプトの実行順序（AwakeやStartが呼ばれる順番）は基本的に不定です。あるスクリプトのAwakeでSingletonのInstanceにアクセスしようとしたとき、まだそのSingletonのAwakeが実行されておらず、instanceがnullである可能性があります。

対策:
1. Instanceプロパティ内でインスタンスを生成するロジック（上記のコード）を採用することで、アクセスされた時点で必ずインスタンスが存在するようにします。
2. Script Execution Order設定（Edit -> Project Settings -> Script Execution Order）で、Singletonクラスを他のスクリプトよりも早く実行されるように設定します。これにより、他のスクリプトがアクセスする前に初期化が完了することを保証できます。

3. OnDestroyによる静的参照のクリア忘れ

シーン遷移時やゲーム終了時に、Singletonオブジェクトが破棄されることがあります。このとき、staticなinstance変数をクリアし忘れると、既に破棄されたオブジェクトへの参照が残り続け、次にアクセスした際に予期せぬエラー（MissingReferenceExceptionなど）を引き起こす可能性があります。

対策: MonoSingleton<T>クラスにOnDestroyメソッドを実装し、オブジェクトが破棄される際にinstance = null;として静的参照をクリアします。

    // 破棄時に静的参照をクリアする
    protected virtual void OnDestroy()
    {
        if (instance == this)
        {
            instance = null;
        }
    }

Singletonパターンの注意点（デメリット）

Singletonパターンは非常に強力ですが、乱用するとプロジェクトの健全性を損なう可能性があります。特に小規模開発者でも知っておくべきデメリットは以下の2点です。

密結合（強い依存性）: Singletonはグローバルなアクセスポイントを提供するため、どのクラスからでも簡単にアクセスできてしまいます。その結果、多くのクラスが特定のSingletonクラスに依存するようになり、コード間の結合度（密結合）が高まります。密結合は、コードの一部を変更した際に、予期せぬ場所でバグが発生するリスクを高めます。
テストの困難さ: ユニットテストを行う際、Singletonクラスはグローバルな状態を持つため、テスト間で状態が共有されてしまい、テストの独立性を保つのが難しくなります。また、Singletonクラスをモック（偽のオブジェクト）に置き換えることが難しく、テストの柔軟性が損なわれます。

まとめ

Unity開発におけるSingletonパターンの正しい実装と注意点について解説しました。このパターンを適切に活用することで、ゲームの管理構造をシンプルに保つことができます。

学んだことの要点は以下の通りです。

Singletonパターンは、インスタンスが一つであることを保証し、グローバルなアクセスを提供するデザインパターンです。
Unityでは、MonoBehaviourを継承したジェネリックな基底クラスを作成することで、安全かつ汎用的なSingletonを実装するのがベストプラクティスです。
Awakeメソッド内で重複インスタンスのチェックと破棄を行うことで、シーン遷移時のバグを防ぐことができます。
DontDestroyOnLoad(gameObject);を適用することで、シーンを跨いでオブジェクトを永続化させることができます。
Singletonの乱用は密結合を引き起こし、コードの保守性やテストの容易性を損なうため、グローバルな管理役に限定して使用することが重要です。

これらの知識を活かし、あなたのUnityプロジェクトをより効率的で堅牢なものにしてください。

Menu