ロボットのタスク実行アーキテクチャ：行動木・状態機械・プランナーの選択基準

ロボットのタスク実行では、分岐を増やすほど設計方式の選択が難しくなる点が気になった。

結論

再利用性と検証性を両立しやすいのは、三つの方式から一つを選ぶ構成ではなく、責務を分ける階層型のハイブリッド構成である。タスクの分解と手順の再生成をプランナー、実行・リトライ・回復を行動木、安全モードとノードのライフサイクルを状態機械に担当させる。

ただし、常にプランナーを導入する必要はない。固定された状態と安全制約が中心なら状態機械、共通スキルの組み合わせと失敗復帰が中心なら行動木、目標・資源・物体状態に応じて手順を動的に変えるならプランナーを優先する。選定では、再利用単位と検証対象を先に定義し、各層の契約を明示することが判断の軸になる。

なぜ方式の分担が必要か

サービスロボットのタスクには、環境に応じた分岐、並行実行、タイムアウト、キャンセル、リトライ、回復、安全モードへの移行が同時に現れる。これらを一つの巨大な状態機械に詰め込むと、タスク種類や例外、再試行条件の増加に伴って状態と遷移の組み合わせが増え、保守と網羅検証の負担が大きくなり得る。

一方、行動木だけで高位のタスク選択まで表現すると、資源や環境の変化に応じた手順の再生成を、多数の分岐として作り込むことになる。プランナーも万能ではない。記号モデルと実世界の状態推定が一致しなければ、生成された計画の妥当性を保てないからである。三方式は競合する実装形式というより、異なる抽象化として比較する方が適切だ。

三つの方式の基本

状態機械は、状態と遷移を明示的に列挙するモデルである。許可された遷移、到達可能性、モードごとの不変条件を検証計画に落とし込みやすい。ドアの開閉、充電、緊急停止、手動介入、ナビゲーションの有効・無効など、相互排他的で有限個の運用モードに向く。Statechartsのように階層、直交並行性、履歴を備えた拡張もある。

行動木は、複合ノードを階層的に組み合わせて実行フローを表す。Sequenceは順番に処理し、Fallbackは代替経路を扱い、Decoratorは条件や実行規則を付加する。ノードはSuccess、Failure、Runningなどの結果を返す。サブツリーやノードプラグインを単位に、ナビゲーション、認識、把持、回復処理などの実行パターンを分割し、再利用できる。

タスクプランナーは、目標に至る手順をモデルから生成する。PDDL系では、ドメインと問題を分離し、アクションの前提条件と効果を記述する。PDDL 2.1では、時間制約、持続アクション、数値フルエントも扱える。目標、利用可能な資源、物体状態、作業順序が変わるタスクで、手順を再生成しやすい。

内部の仕組みと責務分担

ハイブリッド構成では、まずプランナーが「何を、どの順序で達成するか」を決める。次に、計画の各ステップを行動木のアクションやスキルへ対応付ける。行動木は実行中の失敗を検知し、Fallback、リトライ、タイムアウト、キャンセルなどを扱う。必要なら実行結果をもとに、プランナーへ再計画を要求する。

状態機械は、細かな作業手順ではなく、システム全体の運用モードを管理する。安全停止や手動介入中は行動木の実行を許可せず、条件が整った場合だけ再開させる、といった境界を明示できる。ROS 2のmanaged nodeも、Unconfigured、Inactive、Activeなどのライフサイクル状態と遷移を定義し、ノードの設定、起動、停止、クリーンアップを状態機械として管理する。

flowchart TD
  G["目標・物体状態・利用可能な資源"] --> P["タスクプランナー\nドメイン・問題・アクションから手順を生成"]
  P --> T["計画されたタスク手順"]
  T --> B["行動木\n実行・リトライ・Fallback・タイムアウト・キャンセル"]
  B --> N["再利用可能なスキル\nナビゲーション・認識・把持"]
  N --> R["実機上の実行"]
  R --> M["実行結果・状態推定"]
  M --> B
  M -. "計画が不成立または状態が変化" .-> P

  S["安全・運用モードの状態機械\n安全停止・手動介入・充電など"] -->|"実行可否を制御"| B
  S -->|"モード遷移と不変条件"| R
  L["ノードのライフサイクル状態\n設定・起動・停止・クリーンアップ"] --> S

  classDef planner fill:#dbeafe,stroke:#2563eb,color:#111827;
  classDef bt fill:#dcfce7,stroke:#16a34a,color:#111827;
  classDef state fill:#ffedd5,stroke:#ea580c,color:#111827;
  class P,T planner;
  class B,N,R,M bt;
  class S,L state;

選択肢の比較

ROS 2での利用場面

ROS 2では、Nav2のBT NavigatorがBehavior Treeでナビゲーションタスクを実行し、XMLで記述されたツリーとBTノードのプラグインを利用する構成を提供している。行動木を実行オーケストレーション層に置く実例として捉えられる。

PlanSys2は、ROS 2上でPDDLに基づくドメイン管理、問題管理、プラン生成、計画実行を分離するアーキテクチャを説明している。ここでは、プランナーのアクションと、実機で実行するスキルの対応関係が設計上の境界になる。

行動木の再利用性は自動的には得られない。ノードの入出力、開始前提、成功・失敗の意味、キャンセル方法、タイムアウト、再実行時に残る副作用を契約として定義する必要がある。状態機械では許可遷移と不変条件、プランナーではアクションの前提条件・効果と状態推定の対応を確認する。

制約と失敗しやすい点

状態機械は検証しやすい一方、タスク全体の唯一の表現にすると、例外や並行実行の追加で遷移が膨らみやすい。Statechartsの階層化や並行性は複雑さを緩和するが、すべてのタスクを単一の状態機械で扱えるとは限らない。

プランナーについては、古典的なPDDL系モデルが実世界の不確実性、部分観測、アクション失敗を直接扱える範囲に限界がある。計画を低レベル制御へそのまま渡すのではなく、行動木などの実行監視層でスキルに変換し、失敗時の回復と再計画を別途設計する必要がある。

また、ROS 2やNav2のプラグインAPI、既定の行動木、ライフサイクル対応はディストリビューションやパッケージのバージョンで異なり得る。ROS 2 Jazzyの資料を別の環境へ適用する場合は、対象バージョンのドキュメントを確認したい。

採用判断の手順

1. 安全モードを列挙する。 停止、手動介入、充電など、遷移を制限すべき有限モードを状態機械の対象にする。
2. 共通スキルを分解する。 移動、認識、把持、回復などを、行動木のサブツリーやノードとして定義する。
3. 手順の変動要因を確認する。 固定フローなら状態機械または行動木で足りる可能性がある。目標、資源、物体状態で順序が変わるならプランナーを検討する。
4. 契約ごとに検証する。 ノードの副作用、遷移の網羅性、アクションモデルと実世界の状態推定の対応を、層ごとに確認する。

まとめ

固定された安全モードには状態機械、再利用可能な実行と回復には行動木、動的な目標や資源に基づく手順生成にはプランナーが適している。両立を狙うなら、プランナー・行動木・状態機械を階層化し、計画・実行・安全モードの責務を分離するのが有力な出発点になる。

方式そのものが保守性や安全性を自動的に保証するわけではない。状態、ノード、アクション、外部副作用を契約として定義し、各層に限定した検証範囲を設定することが構成選択の成否を左右する。

参考情報

• Behavior Trees in Robotics and AI: An Introduction
• BT Navigator - Nav2 documentation for ROS 2 Jazzy
• Managed nodes - ROS 2 Jazzy documentation
• PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains
• Statecharts: A visual formalism for complex systems
• PlanSys2 architecture

三方式を優劣だけでなく、責務と検証範囲の違いとして捉えることが設計の出発点になる。

AI利用に関する注記

本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。