どどんぐりラボ

「追いかけてくる敵」のAIを、NavMeshAgentだけで作る話

2026年9月 / Unity・ゲームAI

ホラーゲームの敵AIって、実は「プレイヤーを見たら追いかける」だけだと全然怖くないんです。見た瞬間に一直線で突っ込んでくる敵は、数回遭遇すればパターンが読めてしまう。本当に怖いのは「物音がしたから来てみたけど、姿が見えない」「追いかけてたのに急に見失った、まだそのへんにいるかもしれない」という、確信が持てない時間の方です。

これを、Unity標準のNavMeshAgentだけで作りました。追加のペイドアセットは一切使っていません。設計と、実装で踏んだ罠をまとめます。

1. 状態は4つで足りる

敵の内部状態を Patrol → Investigate → Chase → Search の4つのステートマシンにしました。それぞれの役割はシンプルです。

• Patrol（巡回）：決められたルートを歩く。ループ／往復／ランダムの3パターンに対応
• Investigate（調査）：物音がした地点まで歩いていって、その場を見回す。姿は見えていない
• Chase（追跡）：プレイヤーの姿を視認していて、直接追いかけている
• Search（捜索）：追跡中に見失った直後。最後に見た地点の周辺を一定時間うろつく

大事なのはSearchがChaseと別状態であることです。見失った瞬間にPatrolへ戻すと、プレイヤーは「壁の陰に隠れた1秒後にはもう安全」と学習してしまい、緊張感が消えます。Searchを挟むことで「本当にもう大丈夫か分からない」時間が生まれます。

2. 気配は「視界」と「聴覚」の2系統

Chase/Investigateへの遷移は、2つの独立したセンサーから起こります。

• 視界コーン：一定角度・距離の扇形の中にプレイヤーが入り、かつ障害物で遮られていなければ視認成立 → Chase
• 聴覚（ノイズ）：足音などの「音イベント」が一定範囲内で発生したら、その座標を記憶してInvestigateへ

聴覚のほうは、発音側（プレイヤーの足音など）と受信側（敵の耳）を疎結合にしたくて、静的なイベントバス（NoiseEmitter）を挟みました。発音側は「ここで音が鳴った」と投げるだけ、受信側は範囲内かどうかを自分で判定する。これで敵の数が増えても発音側のコードは変えなくて済みます。

// 発音側：座標と強さを投げるだけ
NoiseEmitter.Emit(transform.position, radius: 6f);

// 受信側（各Enemy）：範囲内なら Investigate へ
void OnNoise(Vector3 pos, float radius) {
    if (Vector3.Distance(pos, transform.position) <= radius)
        stateMachine.ChangeState(EnemyState.Investigate, pos);
}

3. NavMesh焼き込みでハマった罠

デモシーンをエディタスクリプトで自動生成し、その場でNavMeshBuilder.BuildNavMesh()を呼んで検証しようとしたら、「No asset directory」という素っ気ないエラーで静かに失敗しました。原因は単純で、シーンが一度もファイルとして保存されておらずパスを持っていなかったためです。NavMeshのベイクデータはシーンと同じ場所に保存されるので、保存先が決まっていないと焼き込みようがない、というだけの話でした。

4. 捕獲直後に一瞬Searchへ落ちる仕様上の癖

Chase中にプレイヤーを捕獲した直後、ごく短い間だけSearch状態に落ちてから捕獲演出に入る、という癖があることも自動テストで見つかりました。これはバグというより、「捕獲判定」と「視認ロスト判定」がほぼ同じフレームで両方成立しうる設計上の副作用です。捕獲演出自体には影響しませんが、状態遷移をログで追っている人向けにREADMEに明記しています。見た目に影響しない挙動でも、隠さずドキュメントに書くのは、前作（Horror Interaction System）でも徹底したポリシーです。

コード依存ゼロ、でも同じ客層向け

このEnemy AI Systemは、ドア・引き出し・インタラクトを扱うHorror Interaction Systemとはコード上の依存関係が一切ありません。どちらか片方だけでも使えます。ただ、「ホラーゲームを個人で作っている人」という客層は完全に同じなので、片方を持っていればもう片方も欲しくなるはずだと思って作りました。