BTとif-thenシステムの相違点とその応用

人工知能技術 機械学習技術 自然言語処理技術 人工知能アルゴリズム ICT技術 デジタルトランスフォーメーション 人工生命 推論技術 知識工学 本ブログのナビ オートマトンと状態遷移と自動計画
BT(Behavior Tree)とif-thenシステムの相違点

BTはエージェントが「今どう動くべきか？」を、木（ツリー）構造で決める方法であり、ざっくり言うと、「もし〇〇なら△△する、ダメなら□□する…」をツリーの形でスッキリ整理する仕組みとなる。

この説明だけだと、単純なif-then(ルールベース)システムと何が違うのかがわかりずらい。

if-thenシステムは、単純な「もし〜なら〜する」というルール(条件→結果)をフラットに並べたルールリストであるのに対して、BTはツリー構造を使い、行動や条件を階層的に組み合わせ、全体の流れや優先順位を直感的に理解しやすく、複雑な制御も整理したものであると言える。

例えばif-thenでは以下のようにネスト構造にして見た目がツリーのような形にできるが

if 未知エリアが見つかったなら
    if 他のエージェントが近くにいるなら
        役割を分担して探索する
    else
        自分で探索する
else
    if 学習モデルの信頼度が低いなら
        過去のデータポイントを再確認する
    else
        他のエージェントを支援する

このような単純なif-then構造をそのまま適用すると、次のような具体的な問題が発生する。

  • ネスト構造の深さによる可読性の悪化: 条件が複数組み合わさると、コードのネストがどんどん深くなり、右に右にズレていくため、全体の構造が非常に見づらくなる。今回の例でも、「未知エリアの発見」「他エージェントの位置確認」「学習モデルの信頼度判定」などが連続し、4階層以上の深いネストが発生する。これにより、開発者がコードの意図や流れを把握しにくくなり、バグの温床になる。
  • 条件組み合わせの爆発的増加: if-then構造では、すべての条件の組み合わせごとに個別の分岐処理を書く必要がある。たとえば、「未知エリアの有無」「エージェントの位置」「学習モデルの信頼度」「自身のリソース状況」などが増えると、これらの全パターンを考慮した分岐を網羅しなければならず、コード量が膨大になり、これが組み合わせ爆発と呼ばれる問題に繋がる。
  • 行動ロジックの差し替えが困難: 特定のパターンを別の処理に差し替えたい場合、if-then構造ではその行動がネストの深い場所に埋め込まれていることが多く、探し出して正確に修正するのが非常に手間となる。今回の例で言えば、「リスク低減探索」という行動部分だけを別のロジックに置き換えたい場合、複数階層を遡りながら、慎重にコードを修正する必要があり、ミスが起こりやすくなる。
  • 学習モデル進化への柔軟対応が難しい: 機械学習を取り入れたシステムでは、学習モデルの進化や出力仕様の変更が頻繁に起こる。たとえば、新たに「信頼度の中間域」を導入したり、出力形式が複雑化した場合、既存のif-then構造全体を見直して、条件判定のロジックを大幅に書き換えなければならず、その結果、学習モデルの改善がシステム全体の破綻リスクにつながり、柔軟な発展が阻害される。

これをBTにすると以下のように記述することができる。

Root
├─ Sequence（未知エリア→行動選択）
│   ├─ Selector
│   │   ├─ Sequence（味方近い→信頼度高→協力高精度収集）
│   │   ├─ Sequence（味方近い→信頼度低→協力リスク低減）
│   │   ├─ Sequence（リソース十分→単独詳細探索）
│   │   └─ 単独概要把握
├─ Selector
│   ├─ Sequence（信頼度低→データ再確認）
│   └─ 他エージェント支援

このような形にすることで、以下のように制御を改善することができる。

  • 条件と行動の階層が明確:「未知エリア判定」「エージェント位置確認」「信頼度チェック」をそれぞれ独立したノードとして階層整理でき、全体構造が視覚的に把握しやすくなる

  • 部分ツリー単位の簡単な差し替え:「リスク低減探索」や「協力データ収集」といった行動ツリーだけを個別に差し替えられ、全体ロジックを崩さずに行動パターンの変更・追加が可能

  • 条件組み合わせの自然な構造化: ネスト深度が固定化され、条件の組み合わせがツリー構造の中に自然に表現されるため、条件数が増えてもコードの見通しが保たれる

  • 学習モデルの進化への柔軟対応: 信頼度判定や学習モデルの出力形式が変わった場合でも、該当するConditionノード部分だけを修正すればよく、全体ツリーには影響を与えにくい

  • 協調・個別行動の切り替えが容易: 「味方と協力する」か「単独で行動する」かをツリー分岐として明確に分けられ、エージェントごとの差別化や役割変更が簡単

  • 視覚的な行動フローの整理: BTの構造をそのままフローチャートやDSLに落とし込めるため、実装者だけでなく設計者やチームメンバーも理解しやすい

以上をまとめると、複雑な状況判断・協調行動・学習組み込みというシステムを想定した時、BTを採用することで：

  • 行動の整理・再利用性

  • 組み合わせ爆発の抑制

  • 学習結果や知識推論の柔軟な統合

  • 視覚的な全体設計の把握

が可能となり、システム全体の柔軟性・保守性・拡張性が大幅に向上するということが言える。

python実装での比較

以下に、BTシステムとif-thenシステムのPython実装を比較してみる。

class Agent:
    def __init__(self, model_confidence, teammate_nearby, unknown_area_detected):
        self.model_confidence = model_confidence
        self.teammate_nearby = teammate_nearby
        self.unknown_area_detected = unknown_area_detected

    def act(self):
        if self.unknown_area_detected:
            if self.teammate_nearby:
                if self.model_confidence > 0.7:
                    print("協力して詳細探索")
                else:
                    print("協力してリスク低減探索")
            else:
                print("単独で探索")
        else:
            print("巡回する")

# 実行例
agent = Agent(model_confidence=0.8, teammate_nearby=True, unknown_area_detected=True)
agent.act()

このコードでは、以下のような形でエージェントの行動判断ロジックをシンプルに表現している。

  • Agent クラスは、エージェントの状態として「モデルの信頼度」「仲間が近くにいるか」「未知エリアを検知したか」の3つの情報を受け取り、それを内部に保持するクラスとなっている。
  • act() メソッドは、エージェントの状況に応じて行動を決め、未知エリアを検出した場合、仲間が近くにいればモデルの信頼度によって「協力して詳細探索」または「協力してリスク低減探索」を行い、仲間がいなければ「単独で探索」します。未知エリアがなければ「巡回する」と判断している。

一方でBTを用いると以下のようなコードになる。

# 基本ノードクラス
class Node:
    def run(self):
        raise NotImplementedError

class Sequence(Node):
    def __init__(self, children):
        self.children = children

    def run(self):
        for child in self.children:
            if not child.run():
                return False
        return True

class Selector(Node):
    def __init__(self, children):
        self.children = children

    def run(self):
        for child in self.children:
            if child.run():
                return True
        return False

class Condition(Node):
    def __init__(self, func):
        self.func = func

    def run(self):
        return self.func()

class Action(Node):
    def __init__(self, func):
        self.func = func

    def run(self):
        self.func()
        return True

# エージェントとBT構築
class Agent:
    def __init__(self, model_confidence, teammate_nearby, unknown_area_detected):
        self.model_confidence = model_confidence
        self.teammate_nearby = teammate_nearby
        self.unknown_area_detected = unknown_area_detected
        self.build_bt()

    def build_bt(self):
        self.bt = Selector([
            Sequence([
                Condition(lambda: self.unknown_area_detected),
                Selector([
                    Sequence([
                        Condition(lambda: self.teammate_nearby),
                        Condition(lambda: self.model_confidence > 0.7),
                        Action(lambda: print("協力して詳細探索"))
                    ]),
                    Sequence([
                        Condition(lambda: self.teammate_nearby),
                        Action(lambda: print("協力してリスク低減探索"))
                    ]),
                    Action(lambda: print("単独で探索"))
                ])
            ]),
            Action(lambda: print("巡回する"))
        ])

    def act(self):
        self.bt.run()

# 実行例
agent = Agent(model_confidence=0.8, teammate_nearby=True, unknown_area_detected=True)
agent.act()

このコードでは、以下のような形で動作を表現している。

  • Node クラスは、すべてのノードの共通の親クラスで、run() メソッドを持っており、具体的な動作は各子クラスで run() を実装する基盤だけを定義する枠組み。
  • Sequence ノードは、子ノードを順番に実行し、1つでも失敗（False）なら全体も失敗する。すべて成功した場合だけ True を返す。
  • Selector ノードは、子ノードを順番に実行し、1つでも成功（True）なら全体も成功する。すべて失敗した場合だけ False を返す。
  • Condition ノードは、指定した関数を実行して条件を判定し、その結果（True または False）を返す。
  • Action ノードは、指定された行動を実行し、実行後は常に True を返す。
  • Agent クラスは、エージェントの状態を持ち、初期化時にビヘイビアツリー（BT）を構築する。
  • Agent内のBT構造は、まず unknown_area_detected が True なら、仲間や信頼度の条件に応じて探索行動を選び、unknown_area_detected が False の場合は「巡回する」行動を実行する。
  • 状況に応じて、エージェントが「協力して詳細探索」「リスク低減探索」「単独探索」「巡回」のいずれかを判断して実行する

BTの方がコード量も多く一見複雑に見えるが、全ての構成要素がクラス化されることで、ノード単位で階層的に整理でき、条件や行動を独立したノードとして分離できることで条件の管理が容易にできるようになっている。

またそのような特徴から、部分ツリーを差し替え・追加可能となり、柔軟性・拡張性が向上するとともに、ConditionやActionノード単位で再利用可能という特徴を持つことができる。

このようにif-thenシステムが持つ、条件が複雑だとネストが深く混乱しやすいという課題に対して、複雑でも構造が明確で見通しが良いシステムを提供することが可能となる。

具体的な適用事例

BTは、環境や内部状態に応じて柔軟に行動を切り替えられるため、複雑なシステム制御に広く利用されている。以下に具体的な適用事例について述べる。

① ゲームAI

具体例：敵キャラクターの行動制御、仲間NPCの協力行動

内容：プレイヤーが近づいたら「攻撃」、体力が減ったら「回避」、敵がいなければ「巡回」

ポイント： 状況ごとに「攻撃」「回避」「巡回」などを柔軟に切り替える

② ロボット制御・自律移動

具体例：掃除ロボット、自律配送ロボット

内容：ゴミを見つけたら「吸い取る」、バッテリーが少なくなったら「充電ステーションへ戻る」、部屋のマッピングが未完なら「探索する」

ポイント：環境状況に応じて最適な行動を構造化して切り替える

③ ドローン・探索システム

具体例：災害救助用ドローン、複数台ドローンの協調探索

内容：未知エリアを検出したら「詳細調査」、仲間が近くにいるなら「協力探索」、危険検出なら「安全区域に退避」

ポイント：状況と協調要素を整理し、効率的な探索を実現

④ 複数エージェント協調システム

具体例：防災・警備ロボット群、仮想空間内のマルチエージェント

内容：共有データを元に「個別探索」または「協力行動」を選択、緊急事態なら「全員で対応」

ポイント：個体ごとにBTを持たせつつ、協調制御を実現

このようにBTは、ゲーム開発やロボット制御、さらには軍事・防衛分野でも広く活用されています。たとえば、UnityやUnreal Engine では多くのゲームAIがBTベースで構築され、キャラクターの複雑な行動制御が実現されており、ROS（ロボットOS） においても、探索・障害物回避などの制御をBTプラグインを用いて柔軟に実装され、さらに、軍事や防衛システム では、複数のドローンやロボットが協調しながら複雑な任務を遂行する場面で、BTの柔軟な行動制御が活用されている。

参考図書

書籍

無料リソース・公式ドキュメント

コメント

タイトルとURLをコピーしました