UnityでAIを実装！ビヘイビアツリーと状態マシンで賢いNPCを作る方法

はじめに

Unityで敵やNPCのAIを作っていると、最初は「if文で分岐させれば動くしOK」と思いがちですよね。
実際、追跡・攻撃・待機くらいなら、それでも問題なく動きます。

でも、開発が進んで行動が増えてくると、こんな状態になっていませんか？

• 条件分岐が増えすぎて、どこで何を判断しているのか分からない
• ちょっと修正しただけで、別の行動が壊れる
• 「このAI、もう触りたくない…」という気持ちになる

これは決してあなたの実装力が低いからではありません。
AIの「設計レイヤー」を考えずに実装していることが原因で、ほとんどの人が同じ壁にぶつかります。

そこで登場するのが、状態マシン（FSM）やビヘイビアツリー（BT）といったAI設計手法です。

ただし、ここでよくあるのが次の悩みです。

• FSMは聞いたことがあるけど、どこまで使えばいいの？
• BTって難しそうだし、本当に必要？
• 結局どっちを使えば正解なの？

この記事では、単なる用語解説ではなく、

• なぜ if文だらけのAIは破綻するのか
• FSMが得意なこと・苦手なこと
• BTが力を発揮する場面
• 実務や個人開発で一番壊れにくい組み合わせ方

を、Unity開発者目線で整理していきます。

「とりあえず動くAI」から一歩進んで、
行動が増えても破綻しにくいNPC設計を身につけたい方は、ぜひこのまま読み進めてください 🙂

---

結論：UnityのNPC AI設計は「FSM or BT」ではなく役割分担が正解

先に結論からお伝えします。
UnityでNPC AIを設計するときに重要なのは、「状態マシン（FSM）か、ビヘイビアツリー（BT）か」を選ぶことではありません。

本当に大切なのは、それぞれの得意分野を理解して、役割を分けて使うことです。

• FSM：今NPCが「どんな状態にいるか」を管理する
• BT：その状態の中で「どう行動するか」を判断する

つまり実務や個人開発で一番破綻しにくいのは、

「大枠はFSMで管理し、行動選択はBTに任せる」構成

という考え方です。

よくある失敗として、

• FSMだけですべての行動を表現しようとして、状態が爆発する
• 最初からBTだけで作ろうとして、構造が見えなくなる

というケースがあります。

どちらも「設計として間違い」ではありませんが、
スケールしていくゲームAIには向きません。

この記事ではこのあと、

• なぜ if文ベースのAIが必ず限界を迎えるのか
• FSMが得意な範囲と、逆に苦手なポイント
• BTが「考えるAI」に向いている理由
• 実際にどう組み合わせると壊れにくいのか

を順番に解説していきます。

---

なぜ「if文だらけ」のNPC AIは必ず破綻するのか

UnityでNPCや敵AIを作り始めたとき、多くの人がまず書くのがこんなコードです。

• プレイヤーを見つけたら追跡
• 距離が近ければ攻撃
• HPが減ったら逃げる

最初はシンプルなので、if文で条件分岐しても問題ありません。
むしろ「ちゃんと自分で考えてAIを作っている感じ」がして、楽しい時期です。

ただし、行動が増えた瞬間から状況は一変します。

if文が増えるほど、AIの「全体像」が見えなくなる

例えば、こんな条件が増えていくケースを想像してみてください。

• プレイヤーを見失ったら巡回に戻る
• 攻撃中は移動しない
• ダメージを受けた直後は回避行動を取る
• 一定時間経ったら警戒状態に移行する

これらをすべてif文で管理し始めると、

• どの条件が優先されるのか分からない
• 同時に成立してはいけない条件が重なる
• 修正の影響範囲が読めない

といった問題が一気に表面化します。

「あり得ない状態」を防げなくなる

if文ベースのAIで特に厄介なのが、論理的におかしい状態が簡単に発生してしまう点です。

例えば、

• 追跡中なのに待機アニメーションが再生される
• 逃走判定と攻撃判定が同時に走る
• すでに死亡しているのに行動処理が続く

こうしたバグは「条件が足りない」のではなく、
状態という概念がコード上で明確に管理されていないことが原因です。

行動を1つ追加するだけで、修正箇所が爆発する

さらに厄介なのが拡張性です。

例えば「警戒状態」を追加したいだけなのに、

• 既存のif文すべてに条件を足す必要がある
• どこに書けば正解なのか分からない
• 結果としてバグを生む

という負のループに入ってしまいます。

これは設計が悪いというより、
if文はAI全体を管理する仕組みとして向いていないだけです。

ここで重要なのは、

「行動」ではなく「状態」を軸に考える必要がある

という発想です。

---

有限状態マシン（FSM）とは何か？Unityでの基本設計

「if文だらけのAI」が破綻する一番の理由は、
「今このNPCがどんな状態なのか」がコード上で曖昧なことです。

この問題をきれいに整理できるのが、有限状態マシン（FSM：Finite State Machine）という考え方です。

FSMは「状態」を中心にロジックを整理する設計

FSMでは、AIを次の3つの要素で考えます。

• 状態（State）：NPCが今置かれている状況
• イベント（Trigger）：状態を切り替えるきっかけ
• 遷移（Transition）：ある状態から別の状態へ移る流れ

重要なのは、
NPCは「同時に複数の状態を持たない」という前提です。

たとえば、

• 待機中
• 巡回中
• 追跡中
• 死亡

といった状態のうち、
必ずどれか1つだけが有効になります。

これだけで、「追跡中なのに待機処理が走る」といった矛盾は原理的に起こらなくなります。

Unityでよく使われるFSMの実装パターン

UnityでFSMを実装する方法はいくつかありますが、考え方は共通しています。

• 現在の状態を1つだけ保持する
• 状態ごとに処理を分離する
• 状態遷移の条件を明示する

代表的な実装方法としては、次のようなものがあります。

• enum + switch文
  シンプルで学習コストが低く、小規模AIに向いている
• IStateインターフェースを使う方法
  Stateごとにクラスを分けられ、責務が明確になる
• 抽象クラスによる継承
  共通処理をまとめやすく、中規模以上で扱いやすい

どの方法を選んでも、「状態ごとに考える」という軸さえブレなければOKです。

FSMが得意なAIのパターン

FSMは、次のようなケースで特に力を発揮します。

• 状態の数が明確に決まっている
• 今どのフェーズかが重要
• 行動よりも「モード切り替え」を管理したい

たとえば、

• 通常 / 警戒 / 戦闘 / 死亡
• 昼 / 夜 / イベント中
• 操作可能 / 操作不能

といった大枠の制御は、FSMと非常に相性が良いです。

FSMをさらに発展させた設計（スタック型・ScriptableObject管理など）については、 以下の記事で詳しく解説しています。

ただし、FSMにも明確な弱点があります。

---

FSMが破綻しやすい3つのパターンと現実的な対策

FSMはとても強力な設計手法ですが、
万能ではありません。

使いどころを間違えると、「if文地獄」から「状態地獄」に形を変えてしまいます。

ここでは、UnityでFSMを使ったときに特に起きやすい3つの破綻パターンと、
現場でよく使われる現実的な対策を紹介します。

パターン①：状態が爆発する

FSMで一番よくある問題が状態爆発です。

例えば、

• 通常 / 走行 / 攻撃
• 武器あり / 武器なし
• 警戒中 / 非警戒

といった要素をすべて「状態」として持たせると、

状態数は掛け算で増えていきます

結果として、

• Attack_WithWeapon
• Attack_WithoutWeapon
• Run_WithWeapon
• Run_WithoutWeapon

といった管理不能な状態一覧が生まれます。

対策：FSMの責務を分ける

この問題への定番の対策は、
1つのFSMにすべてを詰め込まないことです。

• 行動用FSM
• 装備用FSM
• ライフサイクル用FSM

のように、独立した軸ごとにFSMを分離します。

こうすることで、状態爆発をかなり抑えられます。

---

パターン②：元の状態に戻れない

FSMでは通常、「現在の状態」しか保持しません。

そのため、

• 攻撃が終わったら、元の状態に戻したい
• 一時的な回避行動を挟みたい

といったケースで設計が苦しくなります。

対策：スタック型FSMを使う

この場合は、状態をスタック構造で管理します。

• 新しい状態をPush
• 処理が終わったらPop

という形にすると、
「元の状態に戻る」という挙動を自然に表現できます。

---

パターン③：共通処理があちこちに散らばる

複数の状態で同じ処理が必要になると、

• 移動処理が各Stateにコピーされる
• 入力処理が重複する

といった問題が起こります。

対策：階層型FSMを導入する

この場合は、

• 「地上状態」という親State
• その下に「待機」「走行」などの子State

という階層構造を作ります。

共通処理を親に集約できるため、保守性が大きく向上します。

ここまで対策を入れても、まだ辛くなる場面があります。

それが「行動の優先順位」や「失敗時の代替行動」が必要になった瞬間です。

---

ビヘイビアツリー（BT）とは何か？考えるAIの仕組み

FSMは「今どんな状態か」を管理するのが得意でしたが、
次のような要求が出てきた瞬間、急に扱いづらくなります。

• 状況に応じて行動の優先順位を切り替えたい
• 失敗したら別の行動にフォールバックしたい
• 「とりあえず試してダメなら次」を自然に表現したい

この「考えて行動を選ぶ」部分を得意とするのが、
ビヘイビアツリー（Behavior Tree / BT）です。

BTは「状態」ではなく「判断の流れ」を表現する

BTは、FSMのように「今はこの状態」と決め打ちする設計ではありません。

代わりに、

「この条件は満たせるか？ → できなければ次を試す」

という意思決定の流れをツリー構造で表現します。

そのためBTでは、各ノードが次の3つの結果のいずれかを返します。

• Success：行動が成功した
• Failure：行動できなかった
• Running：処理が継続中（移動中など）

この3状態があることで、
「今は移動中だから次に進まない」といった挙動を自然に表現できます。

主要なノードの種類と役割

BTは大きく分けて、3種類のノードで構成されます。

① コンポジットノード

複数の子ノードを持ち、実行順序を制御します。

• Sequence
  子ノードを順番に実行し、1つでもFailureが返れば失敗。
  「AしてからBする」といった処理に向いています。
• Selector
  子ノードを順に試し、1つでもSuccessが返れば成功。
  優先順位付きの行動選択に使われます。

② デコレーターノード

1つの子ノードをラップして、挙動を調整します。

• 成功・失敗を反転させる
• 一定回数繰り返す
• 条件付きで実行する

といった細かい制御を担当します。

③ リーフノード

ツリーの末端で、実際の処理を行うノードです。

• 移動する
• 攻撃する
• 視界チェックをする

Unityでは、これらをC#スクリプトとして実装することになります。

BTが得意なAIの特徴

BTは、次のようなAIに特に向いています。

• 行動の優先順位が重要
• 失敗を前提にした設計が必要
• 行動を後から差し替え・追加したい

例えば、

• 攻撃できるなら攻撃 → 無理なら遮蔽に移動 → それも無理なら逃走
• 鍵を使う → ダメなら別ルートを探す

といった「柔軟な思考」は、FSMよりもBTの方が自然に表現できます。

ただし、BTにも弱点があります。

---

FSMとBTの使い分け・組み合わせパターン【実務向け】

ここまでで、

• FSMは「状態管理」が得意
• BTは「行動選択・優先順位」が得意

という役割の違いが見えてきたと思います。

では実際のUnity開発では、
どう組み合わせるのが一番壊れにくいのでしょうか？

基本形：FSMで「状態」、BTで「行動」を分担する

実務・個人開発で最もよく使われるのが、次の構成です。

• FSM：NPCの大枠の状態を管理する
• BT：その状態内での具体的な行動を決める

例えば、FSMでは次のような状態だけを持たせます。

• 巡回
• 警戒
• 戦闘
• 死亡

そして「戦闘状態」に入ったら、その中身はBTに任せます。

BT側では、

• 攻撃できるなら攻撃する
• 無理なら遮蔽に移動する
• それも無理なら距離を取る

といった優先順位付きの行動選択を行います。

この構成が破綻しにくい理由

FSMとBTを分ける最大のメリットは、

• 状態数が増えにくい
• 行動追加が局所的で済む
• 修正の影響範囲が読みやすい

という点です。

例えば「戦闘中の行動を1つ増やしたい」場合でも、
FSMには一切手を入れず、BTの一部を差し替えるだけで済みます。

逆に「戦闘→逃走に切り替える条件」を変えたい場合は、
FSM側だけを調整すればOKです。

この責務分離が、AI設計を長生きさせます。

将来的な拡張にも強い

この構成は、将来の拡張にもそのまま使えます。

• ステルスAI（警戒度に応じた行動）
• 生活AI（仕事・睡眠・移動）
• 感情・好感度による行動変化

いずれも、

• 「今どんな生活フェーズか」はFSM
• 「その中で何をするか」はBT

という形で自然に拡張できます。

生活リズムやスケジュールを持つNPCまで発展させたい場合は、 以下の記事も参考になります。

---

ビジュアルツールを使うと設計理解が一気に進む

FSMやBTは、概念として理解するのが少し難しく感じやすい部分です。

特に最初のうちは、

• 頭の中では分かっているつもりでも、構造が整理できない
• 自分の設計が正しいのか不安になる

という状態に陥りがちです。

そんなときに役立つのが、
AIの構造を「見える形」で確認できるビジュアルツールです。

FSMの理解を深めたいなら「PlayMaker」

FSMの考え方を掴むうえで、とても相性が良いのがPlayMakerです。

状態・遷移・イベントが視覚的に並ぶため、

• 今どの状態にいるのか
• どの条件で切り替わるのか

を直感的に把握できます。

「FSMってこういう構造なんだ」という理解が一気に進むので、
コードでFSMを書く前の設計確認にも向いています。

✅アセットストアでチェックする

BTを本格的に扱うなら「Behavior Designer」

ビヘイビアツリーを実践的に使いたい場合は、
Behavior Designerが非常に分かりやすいです。

SelectorやSequenceの構造がそのままツリーとして表示されるため、

• 行動の優先順位
• 失敗時のフォールバック

が一目で確認できます。

「この条件が失敗したら、次に何が実行されるのか？」を、
コードを読まずに追えるのが大きなメリットです。

✅アセットストアでチェックする

ツールは「最終解」ではなく「理解を助ける手段」

ここで一つ大切なことがあります。

ツールを入れただけで、AIが賢くなるわけではありません

重要なのは、

• FSMは何を管理するのか
• BTはどこまで任せるのか

という設計上の役割分担です。

ビジュアルツールは、その設計を
確認・検証・共有するための強力な補助輪として使うのが理想です。

---

よくある誤解・初心者がつまずくポイント

FSMやBTを学び始めたとき、多くの人が同じ勘違いをします。

ここでは、UnityでNPC AIを設計するときに特につまずきやすいポイントを整理しておきます。

誤解①：FSMは古い設計で、もう使われていない

これはかなり多い誤解です。

確かにFSMだけで複雑なAIをすべて表現しようとすると破綻しますが、
「状態管理」という役割に限定すれば、FSMは今でも非常に有効です。

むしろ、

• ゲーム進行
• キャラクターのライフサイクル
• 大枠のフェーズ管理

といった部分は、FSM以外の方法のほうが分かりづらくなることも多いです。

「FSMがダメ」なのではなく、
FSMにやらせる範囲が広すぎることが問題になります。

---

誤解②：BTを使えば自動的に賢いAIになる

BTを導入した途端にAIが賢くなる、ということはありません。

BTはあくまで、

• 行動の優先順位を整理する
• 失敗時の代替行動を設計しやすくする

ための器です。

中身の行動設計が雑であれば、
ツリーがどれだけ立派でもAIは不自然になります。

特に初心者がやりがちなのが、

• 1つのノードでやりすぎる
• 条件チェックと行動が混ざる

という設計です。

BTでは、

• 条件は条件
• 行動は行動

と役割を小さく分ける意識がとても重要です。

---

誤解③：最初から完璧なAI設計を目指すべき

これもよくある落とし穴です。

実際の開発では、

• 仕様は変わる
• 行動は増える
• 調整も何度も入る

のが当たり前です。

最初からすべてを見越した設計を作ろうとすると、
設計そのものが重くなりすぎて動かなくなります。

大切なのは、

「後から壊れにくい形」を選んでおくこと

---

まとめ：NPC AI設計で一番大切なこと

ここまで、UnityでNPC AIを設計するときに多くの人がつまずくポイントと、 それを回避するための考え方を整理してきました。

改めて要点を振り返ってみましょう。

• if文だけでAIを作ると、行動が増えた瞬間に必ず破綻する
• FSMは「今どんな状態か」を管理するのが得意
• BTは「どう行動するか」「何を優先するか」を決めるのが得意
• 実務・個人開発ではFSM＋BTの役割分担が最も壊れにくい

この記事で一番伝えたかったのは、

「賢いAIを作ること」よりも、「壊れにくいAIを作ること」のほうが重要

という点です。

最初はシンプルな巡回AIでも、 開発が進めば必ず次のような要求が出てきます。

• 警戒行動を追加したい
• 条件によって行動を変えたい
• 失敗したら別の行動を取らせたい

そのときに、

• FSMで状態が整理されている
• BTで行動の優先順位が分離されている

という土台があるだけで、 AIの拡張難易度は大きく変わります。

最初から完璧な設計を目指す必要はありません。 ただし、

「後から育てられる構造」を最初に選んでおく

これだけは、意識しておく価値があります。

次にAIを実装するときは、 ぜひ「この判断はFSM？ それともBT？」と一度立ち止まって考えてみてください。

その積み重ねが、 自然で賢く、そして長く付き合えるNPC AIにつながっていきます 🙂

---

参考文献

• Game Programming Patterns – State
• State Machines in Unity: How and When to Use Them
• Behavior Trees for AI: How They Work
• Behavior Trees for AI: How They Work（Part 2）
• Behavior Trees Versus State Machines
• Choosing the Right AI Architecture
• How to Avoid Spaghetti Code in Game AI
• State Machines and Behavior Trees
• Designing Stealthy AI
• Building Believable AI Characters
• Artificial Intelligence Programming (SIGGRAPH Course Notes)

---

よくある質問（FAQ）