ロボットの失敗からの復旧設計：リトライ・再計画・人への引き継ぎを使い分ける

Wed, 23 Sep 2026 13:35:31 +0900

ロボットの失敗時に、単純な再試行が安全とは限らない点に着目しました。

先に結論

ロボットのタスク実行失敗は、すべて同じ動作を繰り返して解決するものではありません。失敗した原因、現在の状態を信頼できるか、再実行で副作用が生じるか、危険度がどの程度かを評価し、対応を分岐させます。

一時的な通信断やタイムアウトで、安全条件と状態が維持されているなら、回数や時間の上限を設けたリトライが候補です。障害物、物体姿勢、把持状態、マップ、位置推定などの前提が変化した、または不確実になった場合は、再観測と状態推定の更新を含む再計画を優先します。衝突、挟まれ、落下、過大な力、センサーやアクチュエータの異常、状態不明、反復失敗では、安全状態へ移行して人に引き継ぎます。

なぜ実行中の復旧設計が必要か

自律ロボットは、計画を一度生成して最後まで実行するだけでは運用できません。実行中には、観測された世界と計画が仮定した状態に差異が生じます。その差異や失敗を監視し、回復または再計画につなげる実行管理が必要です。計画、実行、監視、再計画を循環させる構成は、自律ロボットのdeliberationでも整理されています。

ここで扱うのは、ノードの起動や停止だけではなく、把持や搬送などのタスクが途中で失敗したとき、次に何をするかを決める上位の復旧ポリシーです。

前提となる用語

リトライは、同じタスクまたは局所動作を再実行することです。リカバリ動作は、再試行の前に待機、後退、再配置などの処置を行うことを指します。Nav2の行動木には、主タスクの失敗後にリカバリを実行し、主タスクへ戻るRecoveryNodeや、複数のリカバリ動作を順番に試す構成があります。

再計画は、最新の観測や状態推定を使って、目標までの手順や制約を組み直すことです。人への引き継ぎは、単に通知して停止することではありません。安全状態への移行、診断情報の提示、人の介入確認、再検証、明示的な再開承認までを含む状態遷移として設計します。

内部の仕組み

実装では、タスク実行器と安全監視を分離します。実行器は成功、失敗、フィードバック、観測結果をタスクオーケストレータへ返します。オーケストレータは失敗分類と状態信頼性を評価し、リトライ、再計画、停止を選択します。状態推定器は対象物や環境の最新状態を更新し、計画器はその結果を制約として使います。安全監視は、タスク側の再試行判断とは別に、危険時の停止要求を担います。

ROS 2のActionは、長時間実行される目標について、目標、フィードバック、結果、キャンセルを扱う通信方式です。実行監視や停止要求の受け渡しに利用できます。一方、ROS 2 Managed Nodeのライフサイクルは、未構成、非アクティブ、アクティブ、終了済みなどの状態と、設定、起動、停止、クリーンアップ、エラー処理の遷移を明示します。これらは、停止後の再初期化や再アクティベーションを、暗黙の再開と区別する基盤になります。

行動木では、BehaviorTree.CPPのRetryやRetryUntilSuccessfulのようなデコレータで、子ノードの失敗時の再実行や回数制御を表現できます。ただし、Retryノードは再実行機構であって、安全に再実行できる条件を自動的に定義するものではありません。

flowchart TD
  A["タスク実行中"] --> B["失敗を検出"]
  B --> C{"危険な兆候または安全機能の作動があるか"}
  C -->|"はい"| H["安全状態へ移行"]
  C -->|"いいえ"| D["現在の状態と安全条件を確認"]
  D --> E{"状態を信頼できるか"}
  E -->|"いいえ"| H
  E -->|"はい"| F{"原因は一時的で再実行は安全か"}
  F -->|"はい"| G["上限付きリトライ"]
  G --> I{"回数・時間・試行予算内か"}
  I -->|"はい"| J["状態を再確認して再実行"]
  J --> A
  I -->|"いいえ"| H
  F -->|"いいえ、前提が変化または不確実"| K["再観測と状態推定の更新"]
  K --> L["制約を反映して再計画"]
  L --> M{"更新後の計画は安全条件を満たすか"}
  M -->|"はい"| N["計画を検証して再開"]
  N --> A
  M -->|"いいえ"| H
  H --> O["失敗情報・観測・試行履歴を提示"]
  O --> P["人への引き継ぎ"]
  P --> Q["介入完了後にロボット・環境・対象物を再検証"]
  Q --> R{"明示的な再開承認と再検証に成功したか"}
  R -->|"はい"| S["検証済みチェックポイントから再開"]
  R -->|"いいえ"| T["タスクを中止"]

失敗原因、状態の信頼性、安全条件、試行予算に基づいて、リトライ・再計画・人への引き継ぎを選択する復旧フロー。

3つの復旧手段の比較

手段	適用条件	必要な確認	主な停止条件	再開条件
リトライ	原因が一時的で、状態と安全条件を確認できる	対象物、ロボット、周囲の状態	回数・時間・総試行予算の超過、副作用の兆候	状態を再確認し、同じ処理が安全に実行可能
再計画	前提条件が変化、または状態が不確実	再観測、状態推定、制約の更新	新しい計画でも安全条件を満たせない	更新後の計画と環境状態を検証
人への引き継ぎ	危険、状態不明、ハードウェア異常、反復失敗	失敗コード、観測データ、試行履歴	人の介入がない、再検証に失敗	介入完了、ロボット・環境・対象物の再検証、明示承認

リトライを設計する条件

リトライは、失敗原因が一時的である場合に限定します。通信タイムアウトのように、対象物やロボットの状態が変わっておらず、安全に再確認できるなら候補になります。ただし、回数、待機時間、バックオフ、総試行予算をあらかじめ設けます。Nav2のRecoveryNodeにも再試行回数を設定する構成がありますが、適切な回数や安全条件はタスクごとに決める必要があります。