Unityで敵キャラクターやNPCを動かそうとしたとき、「FSM(状態マシン)」と「ビヘイビアツリー」という言葉を目にして、どちらを選べばいいのか迷ったことはありませんか。
ネットで調べても専門用語が並ぶだけで、結局「自分のゲームにはどちらが合うのか」が分からないまま時間だけが過ぎてしまう…という方も多いと思います。
この記事では、FSMとビヘイビアツリーの違いから、Unity6の公式ツールでの実装方法、そして生成AIと組み合わせやすい設計の考え方まで、順番に見ていきますね。
UnityのAI実装、FSMとビヘイビアツリーどちらを選ぶべきか
先に結論からお伝えすると、NPCの状態がシンプルで遷移のルールが明確ならFSM、条件分岐が多かったり優先度で行動を切り替えたい場合はビヘイビアツリーが向いています。
「シンプル」と「複雑」の境目がどこにあるのか、実際に手を動かす前に一度チェックしてみましょう。
下のチェックリストで、自分が作りたいNPCの動きに近いものを確認してみてくださいね。
- ✅ 待機・攻撃・逃走など、状態の種類が5個以下でおさまる
- ✅ 「この状態の次はこの状態」という遷移ルールがはっきり決まっている
- ✅ 一度作ったら大きく仕様変更する予定がない
上のチェックリストに多く当てはまる場合は、FSMで実装するほうがシンプルに済むケースが多いです。逆に、下のような状況ではビヘイビアツリーのほうが後々の負担が少なくなりやすいでしょう。
- ✅ プレイヤーの行動や周囲の状況によって、判断する条件がどんどん増えていきそうだ
- ✅ 「複数の候補の中から一番優先度の高い行動を選ぶ」という処理をしたい
- ✅ ゲームの開発中に、行動パターンを追加・変更する機会が多そうだ
ここで大事なのは、どちらか一方が優れているという話ではないということです。作りたいNPCの複雑さに合わせて選ぶことが、後から「作り直し」にならないための一番の近道になります。
もし「うちのNPCはFSMで十分そうだ」と感じた方は、まず状態マシンの基本的な考え方を整理しておくと、この後の話もスムーズに理解できると思います。
状態マシンそのものをもう少し詳しく知りたい方は、こちらの記事もあわせて読んでみてください。
状態マシン(FSM)とビヘイビアツリーの根本的な違い
先ほどのチェックリストで、なんとなく「うちはこっちかも」という感触はつかめたと思います。ここからは、その判断の裏側にある仕組みの違いを見ていきましょう。
FSMは、キャラクターの「今の状態」をひとつだけ持っていて、決められたルールに沿って状態を切り替えていく仕組みです。たとえば「待機」から「攻撃」へ、「攻撃」から「逃走」へといった具合に、次に進める先があらかじめ決まっているイメージですね。
一方のビヘイビアツリーは、状態をひとつに絞るのではなく、「今の状況ならどの行動が一番ふさわしいか」を毎回条件と優先度で判断する仕組みです。行動そのものと、行動を選ぶための条件が分かれているため、状況が変わっても柔軟に対応しやすくなっています。
言葉だけだとイメージしづらいので、それぞれの特徴を表で整理してみますね。
| 状態マシン(FSM) | ビヘイビアツリー | |
|---|---|---|
| 仕組み | 状態と、状態間の遷移ルールで管理 | 条件評価と優先度でアクションを選択 |
| 得意なこと | 状態数が少なく、流れが決まっている動き | 状況に応じて柔軟に判断が変わる動き |
| 実装のしやすさ | 理解しやすく、すぐに作り始めやすい | 考え方に慣れるまで少し時間がかかる |
| 規模が大きくなったとき | 状態が増えるほど遷移ルールが複雑になりやすい | ノードを追加していく形なので破綻しにくい |
それぞれのメリット・デメリット
FSMの一番の魅力は、なんといっても分かりやすさです。「今どの状態にいるか」が一目瞭然なので、初めてAIを実装する方でも取り組みやすいのが強みですね。
ただし、状態の数やパターンが増えてくると、遷移ルールを書く量も比例して増えていきます。「攻撃中に逃走に切り替わる条件」「逃走中に待機へ戻る条件」など、組み合わせが増えるほど管理が大変になっていくのです。
ビヘイビアツリーは、この「組み合わせが増えると破綻する」という弱点を解消しやすい仕組みになっています。条件と優先度さえ整理しておけば、行動パターンを追加してもツリーにノードを足すだけで対応できることが多いです。
その代わり、最初に覚えることが少し多めです。ノードの種類や組み立て方に慣れるまでは、シンプルな動きを作るだけでも「思ったより手間がかかるな」と感じるかもしれません。
ここで大切なのは、FSMが「古い」「劣っている」というわけではないということです。状態がシンプルなキャラクターにまでビヘイビアツリーを使うと、かえって実装の手間が増えてしまうこともあります。あくまで、動かしたいNPCの複雑さに合わせて選ぶという考え方が基本になります。
FSMの仕組みをもう少し丁寧に押さえておきたい方は、こちらの記事で基本的な考え方を確認しておくと理解がスムーズです。
FSMとビヘイビアツリーを併用するハイブリッド設計という選択肢
ここまで読んで、「じゃあ複雑なNPCは全部ビヘイビアツリーで作ればいいのでは」と思われたかもしれません。ただ、実はビヘイビアツリーはFSMの上位互換というわけではなく、両方を組み合わせて使う方法もよく使われています。
具体的には、「何をするか」を決める部分はビヘイビアツリーに任せて、決まった行動を実際に動かす部分はFSMで管理するという役割分担です。
たとえば、ビヘイビアツリー側で「攻撃する」という判断が下されたとします。そのあとキャラクターを実際に動かす段階では、「振りかぶる」「攻撃する」「隙ができる」といった細かい状態の切り替えをFSMが担当する、というイメージですね。
このように役割を分けると、判断のロジックと見た目の動きのロジックが混ざらないので、あとから調整するときも見通しがよくなります。判断部分だけをビヘイビアツリーで整理し直したいときに、動きの実装まで巻き込まずに済むのは大きなメリットです。
「移動して敵を追いかける」といった実際の動作部分を作り込みたい場合は、NavMeshAgentを使った追尾処理と組み合わせるのもひとつの方法です。判断はビヘイビアツリーやFSMに任せつつ、実際の移動処理はこちらの記事のような実装と組み合わせて考えてみてください。
Unity6公式「Unity Behavior」でビヘイビアツリーを実装する手順
ビヘイビアツリーが自分のNPCに合っていそうだと分かったら、次に気になるのは「実際どうやって作るの?」という部分ですよね。Unity6には、ビヘイビアツリーをグラフ形式で組み立てられる公式パッケージ「Unity Behavior」が用意されています。
ノードをドラッグ&ドロップでつなげていくだけなので、コードをゼロから書くよりも直感的に理解しやすいのが特徴です。ここから実際の導入手順を順番に見ていきましょう。
導入〜エージェント適用までの手順
まずはパッケージを追加するところから始めます。Unity6のプロジェクトを開いた状態で、以下の手順を進めてください。
- Package Managerを開き、左上の「+」ボタンから「Install package by name..」を選択する
- 入力欄に
com.unity.behaviorと入力してインストールする - Projectビューで右クリックし、「Create > Behavior > Behavior Graph」を選択してアセットを作成する
- 作成したアセットをダブルクリックし、Behavior Graphウィンドウを開く
- スペースキーを押してノード検索ダイアログを開き、「Sequence」などの制御ノードや「Action」ノードを追加してドラッグ&ドロップで接続する
- Blackboardパネルの「+」ボタンから型(Float など)を選んで変数を追加し、ノードのインプットフィールドと紐付ける
- 動かしたい対象のGameObjectに「Behavior Agent」コンポーネントをアタッチし、作成したBehavior Graphを割り当てる
手順の中でつまずきやすいのが、ノードをつなげただけでBlackboardの変数と紐付けを忘れてしまうケースです。ノード同士は正しくつながっているのにキャラクターが反応しないときは、まずリンクボタンでの紐付け漏れを疑ってみてください。
Unity Behaviorだけが実装方法ではない
ここまで公式パッケージの手順を紹介してきましたが、ビヘイビアツリーの実装方法はこれだけではありません。もっと高機能なエディタが欲しい場合や、既存プロジェクトの都合で別の方法を探している場合は、サードパーティ製のアセットも選択肢に入ります。
たとえば「Behavior Designer」のような有償アセットは、より豊富なノードやデバッグ機能を備えており、大規模なプロジェクトで採用されることも多いツールです。
Behavior Designer – Behavior Trees for Everyone
✅アセットストアでチェックする
敵の視界や索敵、警戒度といった、より作り込んだ挙動を実現したい場合は、こちらの記事で紹介しているアセットも参考になると思います。
生成AIと協働しやすいMonoBehaviour設計にする方法
ChatGPTやClaude Codeなどにコードを書いてもらったとき、「思ったより微妙な結果になるな」と感じたことはありませんか。実はその原因、コードの書き方そのものよりも「MonoBehaviourの使い方」にあるケースが多いんです。
Unityでは何でもかんでもMonoBehaviourに書いてしまいがちですが、これはインスペクターやUnity独自のライフサイクルに依存する部分が多く、生成AIにとっては文脈を読み取りにくいコードになりやすいという特徴があります。
そこでおすすめしたいのが、役割ごとにロジックを分けていくという考え方です。分け方の基本は、次の4つに整理するとシンプルになります。
- ダメージ計算などの純粋な計算処理は、静的なユーティリティクラスに切り出す
- 速度や体力などのパラメータは、ScriptableObjectに移して一元管理する
- オブジェクトの生成やデータへのアクセスは、専用のインターフェースにまとめる
- インベントリやスコア管理など、画面表示に関わらない処理はUnity APIに依存しないクラスとして分離する
こうして整理していくと、MonoBehaviourは表示や入力操作だけを担当するシンプルな役割に落ち着きます。すると生成AIに指示を出すときも、「このC#クラスのこのメソッドを直して」と的を絞った頼み方ができるようになるんですね。
もちろん、すべてを最初から完璧に分離する必要はありません。まずは「このスクリプト、いろんな役割が混ざっているかも」と感じた部分から少しずつ整理していくくらいで十分です。
こうした設計をさらに一歩進めたい場合は、依存性注入(DI)という考え方を取り入れると、クラス同士のつながりをより整理しやすくなります。興味のある方はこちらの記事もあわせてチェックしてみてください。
大量NPCでも重くならないための最適化の考え方
1体や2体のNPCならそれほど気にならなくても、敵の数が数十体、数百体と増えてくると急に処理が重くなった、という経験をした方もいるのではないでしょうか。
これは、ひとつひとつのNPCがそれぞれ独立してオブジェクト指向的に判断処理をおこなっていることが原因になっているケースが多いです。数が少ないうちは問題なくても、キャラクターの数が増えるほど負荷は比例して大きくなっていきます。
この負荷を抑える方法として使われているのが、UnityのJobSystemを活用したデータ指向の設計です。すべてのキャラクターのデータをNativeContainerと呼ばれる領域にまとめて配置し、まとめて処理することでCPUの計算効率を高めるという考え方になります。
データをまとめて扱うことで、ガベージコレクション(不要になったメモリの片付け処理)の発生も抑えられるため、処理落ちやカクつきの軽減にもつながりやすくなります。
JobSystemは、少数のNPCを動かすだけの規模ではあまり効果を感じにくい仕組みです。まずはFSMやビヘイビアツリーで動きを作り込み、数を増やしたときに重さが気になってきたら検討する、くらいの位置づけで考えておくとよいでしょう。
ここではあくまで考え方の紹介にとどめていますが、JobSystemやBurst Compilerを使った具体的な高速化の手順は、また別の機会に詳しく扱えたらと思います。
よくある質問
-
Qビヘイビアツリーの学習コストは、独学だとどのくらいかかりますか?
-
AFSMと比べると、ノードの種類や組み立て方に慣れるまで少し時間がかかる傾向があります。ただし、簡単な行動パターンをひとつ作ってみるだけでも仕組みは掴みやすいので、まずは小さなグラフから試してみることをおすすめします。慣れないうちは公式のサンプルプロジェクトを触りながら、ノードの動きを確認していくと理解が早まりやすいです。
-
QUnity Behaviorはまだ新しいパッケージですが、商用ゲームに使っても大丈夫ですか?
-
A導入前にUnityのバージョンやパッケージのアップデート状況を確認しておくと安心です。新しいツールは機能追加や仕様変更が入ることもあるため、プロジェクトの規模や公開時期に応じて、サードパーティ製のツールと比較しながら判断するのがよいでしょう。
-
Q既存のFSMベースのNPCを、あとからビヘイビアツリーに移行することはできますか?
-
A移行は可能ですが、状態の切り替えロジックを条件と優先度の形に組み直す作業が必要になるため、規模が大きいほど工数はかかります。すべてを一気に置き換えるのではなく、複雑になってきた一部の行動だけを先にビヘイビアツリーへ移す、という段階的な進め方をすると負担を減らしやすいです。
※当サイトはアフィリエイト広告を利用しています。リンクを経由して商品を購入された場合、当サイトに報酬が発生することがあります。
※本記事に記載しているAmazon商品情報（価格、在庫状況、割引、配送条件など）は、執筆時点のAmazon.co.jp上の情報に基づいています。
最新の価格・在庫・配送条件などの詳細は、Amazonの商品ページをご確認ください。