【Unity】Unity設計パターン：Stateパターンで複雑なAIやキャラクターの状態を管理する

敵AIに「巡回」「追跡」「攻撃」と状態を足していったら、Updateメソッドがif-elseの迷路になった——状態を持つキャラクターを作ると、誰もが一度はこの「ネスト地獄」に迷い込みます。状態が5つを超えたあたりで、もう自分でも読めません。

この混沌を整理する古典にして最強の道具が Stateパターン（ステートマシン） です。核心はただ一つ、「状態そのものをクラスにする」こと。この記事では、敵AIを題材に、IStateインターフェースを使ったクリーンなステートマシンの実装を解説します。

この記事でわかること

• if-elseの肥大化がなぜ起きるのか、Stateパターンが何を解決するのか
• Context / IState / 具象状態クラスという3つの構成要素
• OnEnter / OnUpdate / OnExit を持つ敵AIステートマシンの実装
• 状態を足しても、既存の状態の動きを書き換えずに済む拡張性の正体

動作確認環境: Unity 6 (6000.x)

ネスト地獄とStateパターンの解決策

プレイヤーキャラクターや敵AIは、ゲームの状況に応じて様々な「状態（ステート）」を持ちます。例えば、敵AIは「巡回状態」「プレイヤー追跡状態」「攻撃状態」「待機状態」「逃走状態」などを切り替えながら行動します。まず、これをif-elseで書いた場合と、Stateパターンで書いた場合の構造を見比べてください。

左の書き方が、悪名高い「巨大Update」です。

// 悪い例：巨大なUpdateメソッド
void Update()
{
    if (state == "Patrol")
    {
        // 巡回処理
        if (CanSeePlayer())
        {
            state = "Chase";
        }
    }
    else if (state == "Chase")
    {
        // 追跡処理
        if (IsInAttackRange())
        {
            state = "Attack";
        }
        else if (!CanSeePlayer())
        {
            state = "Patrol";
        }
    }
    else if (state == "Attack")
    {
        // 攻撃処理
        if (!IsInAttackRange())
        {
            state = "Chase";
        }
    }
    // ... さらに状態が増えていく
}

状態が増えるたびにelse ifが伸び、遷移条件が絡み合い、1箇所の修正が別の状態を壊すようになります。

このような「状態に応じた振る舞いの違い」をエレガントに管理するのが Stateパターン です。核心は、「状態」そのものをクラスとして表現し、状態ごとの振る舞いをそのクラスのメソッドとして実装することです。そして、状態を持つ本体（コンテキスト）は、現在の状態オブジェクトへの参照を保持し、処理をその状態オブジェクトに「委譲」します。

Stateパターンの構成要素

Stateパターンは、主に3つの要素で構成されます。

1. Context (コンテキスト): 状態を持つ本体。この例では敵AIキャラクター。現在の状態オブジェクト (IState) への参照を保持し、状態遷移の責任を持ちます。
2. IState (インターフェース): すべての状態クラスが実装すべき共通のインターフェースを定義します。例えば、OnEnter()（その状態に入った時の処理）、OnUpdate()（その状態での毎フレームの処理）、OnExit()（その状態から出る時の処理）といったメソッドを定義します。
3. Concrete State (具象状態): IStateインターフェースを実装した具体的な状態クラス。PatrolState, ChaseState, AttackStateなどがこれにあたります。各クラスは、その状態における具体的な振る舞いを実装します。

補足: OnEnter→OnUpdate→OnExitという3点セットは、「部屋に入るとき・部屋にいる間・部屋を出るとき」と考えると覚えやすいです。アニメーション開始は入室時、移動処理は在室中、エフェクトの後始末は退室時——と、処理の置き場所が自然に決まります。

Unityでの実装例：敵AIのステートマシン

ここからは、実際に動く敵AIを組み立てます。完成形の全体像はこうなります。

Step 1: IStateインターフェースの定義

まず、すべての状態クラスの設計図となるインターフェースを定義します。

// IState.cs
public interface IState
{
    // この状態に入った時に一度だけ呼ばれる
    void OnEnter(EnemyAI context);

    // この状態である間、毎フレーム呼ばれる
    void OnUpdate();

    // この状態から出る時に一度だけ呼ばれる
    void OnExit();
}

Step 2: 具象状態クラスの実装

次に、具体的な状態クラスをそれぞれ作成します。各状態クラスは、自分自身のロジックと、他の状態へ遷移する条件のチェックを行います。

// PatrolState.cs
using UnityEngine;

public class PatrolState : IState
{
    private EnemyAI enemy;

    public void OnEnter(EnemyAI context)
    {
        this.enemy = context;
        Debug.Log("巡回状態に移行");
        // 巡回アニメーションを開始するなどの処理
    }

    public void OnUpdate()
    {
        // 巡回ロジックをここに実装

        // プレイヤーを発見したら、追跡状態に遷移する
        if (enemy.CanSeePlayer())
        {
            enemy.ChangeState(new ChaseState());
        }
    }

    public void OnExit()
    {
        // 巡回アニメーションを停止するなどの処理
    }
}

// ChaseState.cs
using UnityEngine;

public class ChaseState : IState
{
    private EnemyAI enemy;

    public void OnEnter(EnemyAI context)
    {
        this.enemy = context;
        Debug.Log("追跡状態に移行");
    }

    public void OnUpdate()
    {
        // 追跡ロジック（プレイヤーを追いかける）をここに実装

        // 攻撃範囲内に入ったら、攻撃状態に遷移
        if (enemy.IsInAttackRange())
        {
            enemy.ChangeState(new AttackState());
        }
        // プレイヤーを見失ったら、巡回状態に戻る
        else if (!enemy.CanSeePlayer())
        {
            enemy.ChangeState(new PatrolState());
        }
    }

    public void OnExit() { }
}

// AttackState, etc... も同様に実装

Step 3: Contextクラスの実装

最後に、状態を管理する本体であるEnemyAIクラスを実装します。このクラスは、現在の状態を保持し、Update処理を現在の状態オブジェクトに委譲します。

// EnemyAI.cs
using UnityEngine;

public class EnemyAI : MonoBehaviour
{
    private IState currentState;

    void Start()
    {
        // 初期状態を設定
        ChangeState(new PatrolState());
    }

    void Update()
    {
        // 現在の状態のUpdate処理を呼び出す
        if (currentState != null)
        {
            currentState.OnUpdate();
        }
    }

    // 状態を切り替えるメソッド
    public void ChangeState(IState nextState)
    {
        // 現在の状態があれば、終了処理を呼び出す
        if (currentState != null)
        {
            currentState.OnExit();
        }

        // 新しい状態に切り替え、初期化処理を呼び出す
        currentState = nextState;
        currentState.OnEnter(this);
    }

    // 状態クラスから使われるヘルパーメソッド群
    // ここでは骨組みを示すための仮実装。次の実践セクションで「本物」に置き換えます
    public bool CanSeePlayer() { /* プレイヤーが見えるかどうかの判定ロジック */ return false; }
    public bool IsInAttackRange() { /* 攻撃範囲内かどうかの判定ロジック */ return false; }
}

EnemyAIのUpdateが「現在の状態に丸投げするだけ」の数行になった点に注目してください。状態ごとの複雑さは、それぞれの状態クラスに閉じ込められました。

Stateパターンのメリット

このパターンの最大のご利益は、状態を足しても、既存の状態の動きを書き換えずに済むことです。

• 関心の分離: 各状態のロジックが、それぞれのクラスに完全に分離されます。EnemyAIクラスは、状態ごとの詳細な振る舞いを知る必要がなくなります。
• 拡張性: 新しい状態（例: FleeState - 逃走状態）を追加したい場合、IStateを実装した新しいクラスを作り、どの状態から移るか（入口の条件）を書き足すだけで済みます。既存の状態の動きは書き換えずに済むので、影響を最小限に抑えられます。
• 可読性と保守性: if-elseのネスト地獄がなくなり、コードが非常にクリーンで読みやすくなります。各状態の振る舞いを修正したい場合も、対応するクラスを修正するだけです。

実践：巡回→発見→追跡→見失うまで動く警備員AI

骨組みができたので、CanSeePlayer()を本物にして「動く警備員」を完成させます。ステルスゲームの見張り、ホラーゲームの徘徊者、アクションゲームの哨戒兵——どれも中身はこの1体の応用です。目標の挙動は「 巡回中にプレイヤーを発見→追跡→見失っても2秒は粘る→最後に見た場所を調べる→いなければ巡回へ戻る 」です。

まずEnemyAIを完成させます。ポイントは2つ——「距離＋遮蔽Raycast」の最小の視界判定と、 状態インスタンスの使い回し（遷移のたびにnewせず、敵1体ごとにAwakeで1セット作る）です。

// EnemyAI.cs（完成版）
using UnityEngine;

public class EnemyAI : MonoBehaviour
{
    [Header("感知設定")]
    public Transform player;
    public float sightRange = 8f;      // 気づける距離
    public LayerMask obstacleMask;     // 壁など遮蔽物のレイヤー

    [Header("移動設定")]
    public float moveSpeed = 2f;       // 巡回・捜索の速さ
    public float chaseSpeed = 4f;      // 追跡の速さ

    // 追跡・捜索が使う「最後に見た場所」
    public Vector3 LastKnownPosition { get; set; }

    // 状態は最初に1セット作って使い回す（毎回newしない）
    public PatrolState Patrol { get; private set; }
    public ChaseState Chase { get; private set; }
    public SearchState Search { get; private set; }

    private IState currentState;

    void Awake()
    {
        Patrol = new PatrolState();
        Chase = new ChaseState();
        Search = new SearchState();
    }

    void Start() { ChangeState(Patrol); }

    void Update() { currentState?.OnUpdate(); }

    public void ChangeState(IState nextState)
    {
        currentState?.OnExit();
        currentState = nextState;
        currentState.OnEnter(this);
    }

    // 本物の視界判定: 「距離内」かつ「間に壁がない」なら見えている
    public bool CanSeePlayer()
    {
        Vector3 toPlayer = player.position - transform.position;
        if (toPlayer.magnitude > sightRange) return false;

        // 壁に遮られていたら見えない
        if (Physics.Raycast(transform.position, toPlayer.normalized,
                toPlayer.magnitude, obstacleMask)) return false;

        LastKnownPosition = player.position; // 見えている間は更新し続ける
        return true;
    }

    // 現在の状態を色で見えるようにするヘルパー（各状態のOnEnterから呼ぶ）
    public void SetStateColor(Color color)
    {
        GetComponentInChildren<Renderer>().material.color = color;
    }
}

次に、この記事の主役である「見失っても粘る」ChaseStateと、「調べに行く」SearchStateです。

// ChaseState.cs（見失い猶予つき）
using UnityEngine;

public class ChaseState : IState
{
    private EnemyAI enemy;
    private float lostTimer; // 見失ってからの経過時間

    public void OnEnter(EnemyAI context)
    {
        enemy = context;
        lostTimer = 0f; // 使い回すので、入室のたびに必ずリセット
        enemy.SetStateColor(Color.red);
    }

    public void OnUpdate()
    {
        if (enemy.CanSeePlayer())
        {
            lostTimer = 0f; // 見えている間は猶予をリセット
        }
        else
        {
            // 見失った瞬間には諦めない。2秒だけ粘る
            lostTimer += Time.deltaTime;
            if (lostTimer >= 2f)
            {
                enemy.ChangeState(enemy.Search);
                return;
            }
        }

        // 最後に見た場所へ向かう（猶予中も走り続ける）
        enemy.transform.position = Vector3.MoveTowards(
            enemy.transform.position, enemy.LastKnownPosition,
            enemy.chaseSpeed * Time.deltaTime);
    }

    public void OnExit() { }
}

// SearchState.cs — 最後に見た場所を調べて、いなければ巡回へ
using UnityEngine;

public class SearchState : IState
{
    private EnemyAI enemy;
    private float searchTimer;

    public void OnEnter(EnemyAI context)
    {
        enemy = context;
        searchTimer = 0f;
        enemy.SetStateColor(Color.yellow);
    }

    public void OnUpdate()
    {
        // 調べに行く途中で再発見したら追跡へ
        if (enemy.CanSeePlayer())
        {
            enemy.ChangeState(enemy.Chase);
            return;
        }

        // 最後に見た場所へ移動し、着いたら3秒だけ調べる
        enemy.transform.position = Vector3.MoveTowards(
            enemy.transform.position, enemy.LastKnownPosition,
            enemy.moveSpeed * Time.deltaTime);

        if (Vector3.Distance(enemy.transform.position, enemy.LastKnownPosition) < 0.1f)
        {
            searchTimer += Time.deltaTime;
            if (searchTimer >= 3f) enemy.ChangeState(enemy.Patrol);
        }
    }

    public void OnExit() { }
}

PatrolStateは、Step 2のものにenemy.SetStateColor(Color.white)（OnEnter）を足し、遷移先をenemy.ChangeState(enemy.Chase)に変えるだけです（巡回ポイント間の移動はMoveTowardsで同様に書けます）。playerにプレイヤーをドラッグし、壁になるCubeを1つ置きます。CubeのLayerを新しく作ったObstacleにして、obstacleMaskでObstacleを選びます（Nothingのままだと、壁越しでも見えている扱いになります）。再生中にSceneビューでプレイヤーをドラッグして、動かしてみてください。

敵が白→赤→黄→白と色を変えながら、発見・追跡・捜索・帰還のドラマを演じ始めます。なお、MoveTowardsは壁を避けずに通り抜けます。壁を回り込ませたいときは NavMeshの記事 のNavMeshAgentに置き換えます。視界判定を円錐（FOV）にしたくなったら、視界判定（FOV）の記事 の部品がそのまま差し込めます。

仕上げにPlayして、追いかけられている途中で壁の裏に隠れてみてください。警備員はすぐには諦めず、2秒粘ってから最後に見た場所を調べに来て、やがて何事もなかったように巡回へ戻っていく——この一連の「人間くささ」が見えれば完成です。敵が賢く見える正体は、追いかける速さではなく、見失ってからの2秒と、最後に見た場所を調べに来るSearchStateのほうです。敵を3体に増やしても、それぞれが自分のタイミングで動いていれば、状態の使い回しもうまくいっています。

おまけ：先に知っておくと良いこと

ステートマシンを組めるようになったら、次はこのあたりが視野に入ってきます。

• Animatorも実はステートマシン: UnityのAnimator Controllerは、アニメーション版のステートマシンです。本記事の考え方がそのままGUIになっており、Animator Controllerの記事 で学べます。「ロジックのステートマシン」と「アニメのステートマシン」を対応させると設計が締まります。
• ゲーム全体の状態管理: キャラクター単位ではなく「タイトル→プレイ中→ゲームオーバー」というゲーム全体の状態は、GameManagerパターンの記事 で扱います。小さな状態はenum＋switch、複雑になったらStateパターン、という段階的な使い分けが現実的です。
• 状態遷移の通知: 「攻撃状態に入った瞬間にUIを点滅させたい」といった連携は、状態クラスから直接UIを触るのではなく イベント で通知すると、状態クラスを疎結合に保てます。
• 割り込みが増えたら Behavior Tree: 「何をしていても低HPなら逃げる」のような割り込みが増えると、切り替えを書く場所が全部の状態に散ります。優先順位で行動を選ばせる形は Behavior Treeの記事 にあります。

まとめ

Stateパターンは、複雑な状態遷移を持つオブジェクトの振る舞いを、整理され、拡張可能で、保守しやすい形で実装するための非常に強力な設計パターンです。

• 状態をクラスとして表現し、状態ごとの振る舞いをそのクラス内にカプセル化する。
• Context（本体）は、現在の状態オブジェクトへの参照を持ち、処理をそのオブジェクトに委譲する。
• 状態遷移のロジックは、各状態クラスが自身で管理する。
• OnEnter（入室）／OnUpdate（在室）／OnExit（退室）の3点セットで、処理の置き場所が自然に決まる。
• 状態の追加は、クラスを1個足して入口の条件を書き足すだけ。既存の状態の動きを壊さない拡張性が最大の武器。

キャラクターAI、プレイヤーの複雑なアクション（通常時、泳ぎ中、はしご昇り中など）、UIのモーダルウィンドウの管理など、ゲーム開発の様々な場面で応用できます。Updateメソッドがifやswitchで肥大化し始めたら、Stateパターンの導入を検討する良いサインです。