Unityで覚えるデザインパターン：ゲームに効く5つの設計手法

ゲーム制作って、アイデア勝負なところがあるけど、実際に作るとなると「コードぐちゃぐちゃになった…」なんてこと、よくありますよね？そんなときこそ頼れるのがデザインパターンです。これは、いわばソフトウェア開発の「型」や「レシピ」のようなもの。特にUnityでゲーム開発していると、「イベントの管理がややこしい」「キャラの行動を切り替えたい」「状態遷移がめんどくさい」といった悩みが出てきます。

そんなときに使えるのが、シングルトン、オブザーバー、ステート、ストラテジー、コマンドといった定番パターンたち。この記事では、それぞれの使いどころとUnityでの実践方法を具体的に紹介していきます！

デザインパターンとは？ゲーム開発でなぜ重要か？

ソフトウェア開発におけるデザインパターンの役割

デザインパターンとは、プログラムの設計におけるベストプラクティスを集めたものです。1994年、GoF（Gang of Four）によって整理された23種類のパターンが有名ですが、実際の開発ではその中から用途に合ったものを選んで使います。

では、なぜそんなパターンが必要なのか？それは、同じような問題に対して繰り返し効果的な解決法を提供してくれるからです。パターンを知っていれば、「あの時みたいにこの構造でやればOKだな」と判断できるようになり、再利用性や可読性も格段に向上します。

Unityでの利用シーンとは？

Unityでゲームを作るとき、デザインパターンは特に以下のような場面で力を発揮します：

グローバルにアクセスしたいゲームマネージャー（シングルトン）
敵がプレイヤーの動きを監視（オブザーバー）
キャラクターの状態変化（ステート）
敵の戦略切り替え（ストラテジー）
プレイヤー操作の記録・再生（コマンド）

このように、Unityではオブジェクト指向設計を活かして、ゲームを構造的に組み立てるのにぴったりなフィールドなんです。

シングルトンパターン：ゲーム管理の中枢を担う

シングルトンとは何か？

**シングルトンパターン（Singleton Pattern）**は、「あるクラスのインスタンスが1つしか存在しないようにする」ためのパターンです。

例えば、スコアやゲームの状態、BGM管理など、どのシーンからでもアクセスしたい要素ってありますよね？そんなとき、シングルトンは非常に便利です。

Unityでのシングルトンの実装例

Unityでは、以下のように簡単なシングルトンを実装できます：

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }

    void Awake()
    {
        if (Instance == null)
        {
            Instance = this;
            DontDestroyOnLoad(gameObject);
        }
        else
        {
            Destroy(gameObject);
        }
    }
}

このコードでは、GameManagerクラスが一度だけ生成され、それ以降のシーンでも破棄されません。DontDestroyOnLoadを使うことで、ゲーム全体にまたがるグローバルな機能を持たせられます。

利点と注意点（アンチパターン化しないために）

シングルトンは非常に便利ですが、使いすぎると危険です。理由は以下の通り：

テストがしにくくなる（他のクラスに依存する）
結合度が高くなり、再利用性が低下する
マルチスレッド対応が難しい

だからこそ、使うときは「本当に1つでいいのか？」をよく考えること。そして、なるべく外部からのアクセスはインターフェース経由にするなど、工夫することが重要です。

オブザーバーパターン：イベント駆動の設計に必須

イベント通知の仕組みを簡潔に管理

オブザーバーパターン（Observer Pattern）は、あるオブジェクトの状態が変わったときに、関連する他のオブジェクトに通知を送るという仕組みです。

Unityでは、プレイヤーが何かをしたときに敵が反応したり、アイテムを取得したときにUIが更新されたりと、イベントの発火と反応が頻繁に起こります。

Unityでの実装例とイベント管理方法

C#では、デリゲートとイベントを使って簡単に実装できます：

public class Player : MonoBehaviour
{
    public delegate void OnHealthChanged(int currentHealth);
    public static event OnHealthChanged onHealthChanged;

    private int health = 100;

    public void TakeDamage(int damage)
    {
        health -= damage;
        onHealthChanged?.Invoke(health);
    }
}

別のスクリプトでは以下のように登録できます：

void OnEnable()
{
    Player.onHealthChanged += UpdateUI;
}

void OnDisable()
{
    Player.onHealthChanged -= UpdateUI;
}

void UpdateUI(int newHealth)
{
    healthText.text = "HP: " + newHealth;
}

これにより、PlayerクラスとUIが疎結合な関係になり、テストしやすく拡張しやすい設計になります。

柔軟性の高いゲームシステム設計に最適

オブザーバーの強みは、「誰が誰に通知しているのか」を意識しなくても設計できる点です。

これにより、ゲームのロジックとUI、サウンド、エフェクトなどを綺麗に分離することができます。設計がスッキリすると、バグも減り、保守性も向上。

まさに、イベントドリブンなUnityの設計にピッタリなパターンなんです。

ステートパターン：状態管理でゲームロジックを整理

ステートパターンの基本構造と考え方

ステートパターン（State Pattern）は、「オブジェクトの内部状態によって、その振る舞いを変更する」というものです。たとえば、キャラクターが「待機中」「攻撃中」「回避中」と状態ごとに違う挙動をするようなときに活躍します。

ストラテジーパターン：行動の切り替えを柔軟に

アルゴリズムの動的変更が可能に

ストラテジーパターン（Strategy Pattern）は、同じ目的を達成する複数の方法（アルゴリズム）を切り替えられるようにするパターンです。たとえば、敵の攻撃方法を「近接攻撃」「遠距離攻撃」「特殊スキル」など、状況に応じて差し替えたいときに活用できます。

設計の基本は、「戦略」をインターフェースとして定義し、それぞれの戦略ごとにクラスを分けて実装することです。そうすることで、コードがシンプルになり、後から追加・変更が容易になります。

public interface IAttackStrategy
{
    void Attack();
}

public class MeleeAttack : IAttackStrategy
{
    public void Attack()
    {
        Debug.Log("近接攻撃！");
    }
}

public class RangedAttack : IAttackStrategy
{
    public void Attack()
    {
        Debug.Log("遠距離攻撃！");
    }
}

public class Enemy : MonoBehaviour
{
    private IAttackStrategy attackStrategy;

    public void SetStrategy(IAttackStrategy strategy)
    {
        attackStrategy = strategy;
    }

    public void PerformAttack()
    {
        attackStrategy.Attack();
    }
}

敵キャラの行動パターンを切り替える

上記のような設計にすることで、例えば敵がプレイヤーとの距離によって攻撃方法を自動で切り替えることができます。プレイヤーが近づいてくれば近接攻撃、離れれば遠距離攻撃へと自然に移行できるわけです。

この切り替えは、Updateメソッドの中などで状況を判定して SetStrategy を呼ぶだけ。これにより、コードの見通しが良くなり、バグも出にくくなります。

設計の拡張性を高める秘訣

ストラテジーパターンのメリットは以下の通り：

オープン/クローズ原則（OCP）に適応：既存コードを変更せず、新しい戦略だけ追加可能
アルゴリズムの再利用が容易
ユニットテストがしやすい

注意点としては、戦略の切り替えのトリガーが複雑になると本末転倒になりかねません。設計時には、「何を基準に戦略を変更するのか」をシンプルに保つことがコツです。

コマンドパターン：プレイヤーの操作をコントロール

入力処理やアンドゥ機能に使える

コマンドパターン（Command Pattern）は、「操作や命令をオブジェクトとして扱う」パターンです。たとえば、プレイヤーの操作を記録して「アンドゥ（取り消し）」を実現したいときや、入力処理を整理したいときに便利です。

操作をクラスとして定義することで、「この命令を後で実行する」「やり直す」といったことが可能になります。

public interface ICommand
{
    void Execute();
    void Undo();
}

public class MoveCommand : ICommand
{
    private Transform player;
    private Vector3 prevPosition;
    private Vector3 newPosition;

    public MoveCommand(Transform player, Vector3 newPosition)
    {
        this.player = player;
        this.prevPosition = player.position;
        this.newPosition = newPosition;
    }

    public void Execute()
    {
        player.position = newPosition;
    }

    public void Undo()
    {
        player.position = prevPosition;
    }
}

Unityでの簡単なコマンドパターン実装

このコマンドをコントローラー側で呼び出せば、実行履歴をスタックに保存しておいて、アンドゥ処理も簡単に実現できます：

Stack<ICommand> commandHistory = new Stack<ICommand>();

public void MovePlayer(Vector3 destination)
{
    ICommand move = new MoveCommand(player.transform, destination);
    move.Execute();
    commandHistory.Push(move);
}

public void UndoLastAction()
{
    if (commandHistory.Count > 0)
    {
        ICommand last = commandHistory.Pop();
        last.Undo();
    }
}

コマンド管理で操作履歴を活用

コマンドパターンの素晴らしいところは、「ユーザーの行動を履歴として持てる」という点です。これにより、たとえば下記のようなシステムが作れます：

アンドゥ/リドゥ機能
リプレイ再生機能
マクロ（操作の自動再生）

また、操作を「命令」として管理することで、複数の入力タイプ（マウス、キーボード、ゲームパッド）にも柔軟に対応可能。設計の柔軟性と拡張性を一気に高めることができるのがこのパターンの最大の魅力です。

Unityにおけるデザインパターンのベストプラクティス

パターンの選び方と適用タイミング

Unityの開発現場でデザインパターンを使う際、「どのパターンをどの場面で使うべきか？」が悩みどころです。

すべての問題に対してパターンを当てはめる必要はありません。むしろ、目的がはっきりしていて、コードが複雑化しそうな場合にのみ適用するのが理想です。

選定の基準としては：

グローバルに管理する必要があるか？ → シングルトン
イベントや通知が頻繁に発生するか？ → オブザーバー
オブジェクトの状態で挙動が変わるか？ → ステート
行動アルゴリズムを切り替えたいか？ → ストラテジー
入力履歴を管理・再実行したいか？ → コマンド

パターンは「便利な道具」ですが、「使わないほうがいい場面」もあるという意識が重要です。

複数パターンの併用例（例：ステート+ストラテジー）

実際のUnityプロジェクトでは、複数のデザインパターンを組み合わせることで、よりパワフルな設計が可能になります。

たとえば敵AIを考えてみましょう：

ステートパターンで「警戒状態」「攻撃状態」「逃走状態」などを切り替え
各状態の中でストラテジーパターンを使って行動パターン（近接・遠距離など）を選択
状態が変わるタイミングでオブザーバーを使って通知

このように、パターンを組み合わせて構造を分離することで、保守性・再利用性の高いコードが完成します。

よくあるミスとその回避方法

「とりあえず使ってみる」が危険な理由

多くの初心者がやってしまうミスの一つに、「有名なパターンだからとりあえず使ってみる」という設計があります。

これは、目的や問題が明確でないまま適用することで、かえってコードを複雑にしてしまいます。

たとえば、シングルトンを乱用してすべてのクラスをグローバルアクセス可能にしてしまうと、プロジェクト全体の依存関係が強くなり、修正が難しくなります。

コードの過剰抽象化に注意

もう一つありがちな失敗は、「設計を美しくしよう」としすぎて、不必要に抽象化しすぎることです。

これは特にストラテジーやステートパターンでよく見られ、結局コードが読みにくく、扱いづらくなってしまう原因になります。

回避するには以下のルールを守ると良いでしょう：

パターンの目的が明確であること
実際のユースケースに即していること
「将来のための設計」よりも「今のための設計」にフォーカスする

設計はあくまで「わかりやすく、保守しやすくするための手段」。目的を見失わないことが大切です。

実践チュートリアル：シンプルなゲームでパターン適用を体験

ミニプロジェクトで設計を体得する

いくら理論を理解しても、実際に使ってみないと身につきません。そこで、初心者にもわかりやすいミニゲームを題材にして、各パターンを実装してみるのがおすすめです。

例として、「プレイヤーがゾンビを倒していくアクションゲーム」を考えてみましょう。

シングルトン：GameManagerでスコアやゲーム状態を一括管理
オブザーバー：敵が倒されたときにスコア更新UIに通知
ステート：ゾンビの状態（徘徊・追跡・攻撃）を切り替える
ストラテジー：ゾンビの攻撃方法をタイプごとに変更
コマンド：プレイヤーの操作履歴を記録して、アンドゥ実装

これらをすべて盛り込むことで、設計の違いによる柔軟性・効率性を体感できます。

ステップバイステップで学べる構成例

学習ステップの例：

Unityで新規2Dプロジェクトを作成
プレイヤー、ゾンビ、スコアUIなど基本的なオブジェクトを配置
各クラスにパターンを一つずつ適用し、動作を確認
複数のパターンを組み合わせて、より高度な挙動を実装
最後にコードを整理し、保守しやすい形にまとめる

この流れで進めれば、デザインパターンを理論だけでなく、実際に使えるスキルとして習得できます。

まとめ：ゲーム制作を変える設計の力

学んだパターンをどう活用するか

Unityでゲーム開発を進める中で、「なんか設計がゴチャゴチャしてきたな…」という壁にぶつかったときこそ、デザインパターンが力を発揮するタイミングです。

この記事で紹介した5つのパターン（シングルトン、オブザーバー、ステート、ストラテジー、コマンド）は、それぞれが明確な目的を持っていて、状況に応じて適切に使い分けることで、設計の明快さと拡張性をグンと高めてくれます。

ゲームの中核管理に→シングルトン
UIや演出との連携に→オブザーバー
キャラクターの状態管理に→ステート
行動ロジックの切り替えに→ストラテジー
操作記録やコマンド管理に→コマンド

このように、現場での困りごとを解決する実用的な武器として活用できるのがデザインパターンなんです。

今後の学習へのアドバイス

これからデザインパターンを学ぶ方へ、以下のアドバイスを贈ります：

まずは1つずつ実装してみよう！：小さなプロジェクトで試すのが◎
コードを真似るだけでなく、なぜそう設計されているのかを考える
無理に使わず、必要になったら使う発想を持つ
GitHubなどで他の人の設計を見ると勉強になる
ゲームを作りながら自然と覚えていくのが一番効率的！

Unityは「動かしてナンボ」の世界。少しずつでも自分の手を動かして、パターンを「道具」として自然に使えるようになっていきましょう！

よくある質問（FAQs）

Q1: Unity初心者ですが、最初に覚えるべきパターンはどれ？

A: シングルトンです。ゲーム管理やスコア管理など、最初に直面しやすい課題に対処できるので習得しやすく即戦力になります。

Q2: オブザーバーとイベントの違いは？

A: C#のイベントはオブザーバーパターンの一種です。仕組みとしては同じで、複数のリスナーに通知を送ることが目的です。イベントは簡潔に実装できます。

Q3: デザインパターンを使うとコードが複雑になりませんか？

A: 適切に使えばむしろ逆です。構造が明確になり、保守・拡張が楽になります。ただし、必要ないところまで使うと逆効果になるので注意が必要です。

Q4: Unityのアセットでもデザインパターンを使っている？

A: はい、多くのプロ用アセットでは、裏側でデザインパターンが使われています。ゲームイベント管理、AI、UI制御など幅広く応用されています。

Q5: 自分でパターンを作っても良い？

A: もちろんOKです。実際の開発では、既存のパターンをベースに自分流にカスタマイズすることもよくあります。「どう設計すれば保守しやすいか？」が最優先です。