回帰テスト on Physical AI Hub

ロボットAIの検証パイプライン：シミュレーションからHIL・実機試験へ移す方法

Sat, 05 Sep 2026 09:21:36 +0900

実機を使わずに検証できる範囲を広げるほど、実機でしか分からない差分を見落とさない設計が重要になります。

先に結論

ロボットAIの検証は、シミュレーション、Hardware-in-the-Loop（HIL）、管理された実機試験の順に段階化するのが基本です。シミュレーションで大量のシナリオを反復し、HILで実時間性やI/O、ドライバ、計算負荷を確認し、その後に実機でセンサー較正、接触、電源、通信、安全挙動を検証します。

ただし、これは一方向に進む固定工程ではありません。変更がハードウェアや安全機能に関係する場合はHILや実機試験を前倒しし、失敗時にはシミュレーションやソフトウェア統合テストへ戻るフィードバックループを設けます。判断の軸は、変更のリスク、実機との差分、再現性、安全要求です。

なぜ三つの段階を分けるのか

実機だけで全テストを行うと、設備を占有し、再現性のある大量試験や並列実行が難しくなります。一方、シミュレーションだけでは、実機の遅延やジッタ、センサーの較正状態、機械的な接触・摩擦、電源状態、通信障害を十分に再現できません。

そこで、検証対象を分解します。ソフトウェアの論理や制御方策はシミュレーションで広く確認し、実際の制御ハードウェアとリアルタイムの入出力はHILで確認します。最後に、シミュレーションモデルで表現しにくい物理条件と安全挙動を、管理された実機環境で確認します。

用語と役割

**SIL（Software-in-the-Loop）**は、制御ソフトウェアや複数ノードの統合を、シミュレーション環境で検証する段階です。ROS 2のlaunch_testingのように、複数ノードを起動してプロセス間の相互作用を検証する方法は、CIで実行するソフトウェア統合テストに利用できます。

シミュレーションでは、物理条件、環境、センサー入力を変化させ、再現可能なシナリオを大量に実行します。視覚・環境パラメータを変えるドメインランダム化や、質量、摩擦、遅延などを変えるダイナミクスランダム化は、シミュレーションと現実の差に対するロバスト性を高める手法です。ただし、これらは実機性能や安全性を保証するものではありません。

HILは、少なくとも制御ソフトウェアまたは対象ハードウェアを実機側で動かし、プラント、センサー、アクチュエータなどの一部をシミュレータで置き換える構成です。実際の制御ハードウェアとリアルタイムシミュレーションを接続するため、実時間性、通信、I/O、ドライバ、計算資源を、実機投入前に検証できます。資料によってHILの範囲は異なり、実フライトコントローラを中心に指す場合と、制御ECU、I/O、リアルタイムのプラントモデルを含む全体を指す場合があります。

推奨する検証フロー

変更を起点に、まず高速な単体テストとSILスモークテストを実行します。ここでは、プルリクエストやコミット単位で、制御ロジック、ノード間連携、代表的な異常処理を確認します。次に、広いシナリオ集合を使ったSIL回帰を、夜間または定期的に実行します。環境やセンサー入力を変えたケースを含めることで、単一の正常系だけでは見つけにくい問題を調べられます。

そのうえで、実時間性やハードウェア依存コード、通信プロトコル、センサー・アクチュエータI/O、故障処理、計算資源に影響する変更をHILへ送ります。HILでは、シミュレータからセンサー入力を与え、実際の制御ハードウェアから出力を取り出し、タイミング、通信、I/O、故障注入への応答を確認します。

HILを通過した変更、またはセンサー較正、接触、安全機能、電源、実環境の通信に関係する変更は、実機ベンチへ進めます。安全に関わる試験では、通常の機能回帰とは別のテストスイートとして管理し、保護機構、中止手順、低速・低エネルギー条件、段階的な運用範囲の拡大を紐付けます。

flowchart LR
  A["コミット・変更"] --> B["単体テスト"]
  B --> C["SILスモーク"]
  C --> D["SIL回帰\n大量シナリオ"]
  D --> E["HIL\n実時間性・通信・I/O・故障処理"]
  E --> F["実機ベンチ\n較正・接触・電源・安全挙動"]
  F --> G["限定環境試験\n段階的な運用範囲"]
  B -. "失敗・修正" .-> H["修正・再テスト"]
  C -. "失敗・修正" .-> H
  D -. "失敗・修正" .-> H
  E -. "失敗・修正" .-> H
  F -. "失敗・修正" .-> H
  H --> A
  A -. "変更リスクに応じて前倒し" .-> E
  A -. "安全・接触・実環境に関係" .-> F

検証はSIL、HIL、実機試験へ段階的に進めるが、失敗時やリスクの高い変更時には前段階へ戻るフィードバックループを設けます。

段階ごとの使い分け

段階	主な検証対象	推奨トリガー	強み	主な制約
SILスモーク	制御ロジック、ノード連携、基本的な異常処理	コミット、プルリクエスト	高速、反復可能、CIに組み込みやすい	実機のI/O、遅延、接触を確認できない
SIL回帰	多様な環境・物理条件・センサー入力	夜間、定期実行、リリース前	大量シナリオを低コストで実行できる	モデル誤差が結果に影響する
HIL	実時間性、通信、ドライバ、I/O、計算負荷、故障処理	ハードウェア依存変更、定期実行、リリース前	実制御ハードウェアを含めて再現性を保てる	設備構築が必要で、SILより実行コストが高い
実機ベンチ	センサー較正、遅延・ジッタ、電源、接触、摩擦	リリース候補、安全・接触・実環境に関わる変更	実際の機械・電気条件を確認できる	実行時間、設備、人的安全管理が必要
限定環境試験	実環境での安全挙動と運用範囲	実機ベンチ合格後、段階的に実施	現場条件での挙動を確認できる	リスク管理と中止手順が不可欠

実機へ進める出口条件

実機試験への移行条件は、単一の性能値で決めるのではなく、検証目的ごとに定義します。少なくとも次の項目を記録します。

ロボット失敗ログの活用設計：再学習と回帰テストへつなぐデータループ

Sat, 15 Aug 2026 09:17:15 +0900

失敗ログを保存するだけで、次のモデルやテストへ自然に生かせるのかが気になるテーマです。

先に結論

ロボットの失敗ログを活用する中核は、件数を増やすことではなく、どの条件で何が起きたかを追跡できる形にし、同じ失敗を再学習用データと回帰テストへ分岐させることです。改変しない生ログを起点に、エピソード、失敗イベント、失敗パターン、データセット、テストケースをIDで結びます。

候補モデルの評価では、固定ホールドアウトや失敗リプレイ、シミュレーション、必要に応じた実機試験をゲートの例として用います。ただし、どこまで試験すればよいか、自動昇格を許すかは、対象タスクと安全要求に応じて決める必要があります。

なぜデータループが必要か

多くの実機システムでは、失敗時にセンサ入力、ロボット状態、制御指令、環境条件、方策やソフトウェアの版が関係します。必要な信号や版情報を欠くと、原因の切り分けや再現が難しくなり得ます。また、同じシーンのログを大量に追加しても、未見条件を評価できるとは限りません。

そのため、失敗ログは単なるデバッグ記録ではなく、検出、確認、パターン化、選別、評価へ渡す入力として設計します。失敗事例を再学習に使う場合も、効果は失敗ラベル、負例の扱い、学習目的によって変わるため、改善を保証するものとして扱ってはいけません。

前提となるデータ層

ROS 2のrosbag2は、トピックデータの記録と再生を行う仕組みです。センサ、状態、指令を時系列で保存し、後から再生する基盤に利用できます。MCAPはスキーマ、チャネル、メッセージ、メタデータ、添付データなどを持つ時系列データ形式です。

一方、RLDSはエピソードとステップの階層でデータを表し、観測、行動、報酬、終了状態などを扱います。rosbag2やMCAPが主に保存・再生を担うのに対し、RLDSは学習・評価向けの論理表現です。両者を同一スキーマとみなさず、正規化処理で変換します。

層	役割	主な情報
生ログ	原記録の保存・再生	rosbag2またはMCAP、時刻、スキーマ
エピソード	学習・評価単位への正規化	episode_id、観測、行動、終了状態
失敗イベント	失敗区間の記録	event_id、時間窓、検出器、重大度、確認者
失敗パターン	類似失敗の集約	pattern_id、再現条件、代表例
データ・テスト	改善サイクルへの反映	dataset version、テストケース、結果

episode_id、event_id、pattern_id、policy_version、software_version、hardware_idで各層を相互参照し、データと処理の版を管理します。DVCのように、データをGitのコードやメタデータと対応付ける仕組みも利用できます。データセットの動機、構成、収集方法、前処理、用途、制約は、Datasheets for Datasetsの考え方に沿って記録すると判断を追跡しやすくなります。

失敗をパターンへ変換する流れ

最初に、停止理由、安全イベント、タイムアウト、タスク判定など、確認可能なルールで失敗候補を抽出します。失敗した瞬間だけでなく、成功・失敗境界の前後を含む時間窓を切り出し、センサ、行動、環境条件、モデルとソフトウェアの版を付与します。次に、人手で失敗の有無と種類を確認します。

確認済みの事例は、特徴量や埋め込みで類似例を集約し、共通する再現条件を調べます。学習中の正解率、信頼度、予測の変動を使い、典型的・曖昧・困難なデータ例を分析するDataset Cartographyの考え方も診断材料になります。ただし、これはロボットの物理的な重大度や安全リスクを直接測るものではありません。

flowchart LR
  A["生ログを変更せずに収集\nrosbag2 / MCAP"] --> B["エピソードへ正規化\n時刻・モデル・ソフトウェア・ハードウェアの版を付与"]
  B --> C["ルールベースで失敗候補を抽出"]
  C --> D["時間窓・環境条件・センサ・行動を付与"]
  D --> E["人手で失敗の有無と種類を確認"]
  E --> F["類似事例をクラスタリング\n失敗パターンへ集約"]
  F --> G["重大度・未見性・不確実性・代表性・テスト状況で優先順位付け"]
  G --> H["版管理された学習データセット"]
  G --> I["回帰テストケース\n元ログ・再現条件・期待動作・閾値"]
  H --> J["候補モデルを学習"]
  J --> K["固定ホールドアウトと失敗リプレイで評価"]
  I --> K
  K --> L["シミュレーションまたは実機の安全評価"]
  L --> M["段階導入"]
  M --> N["導入後の監視"]
  N --> A
  E -. "未確認・追加確認" .-> D

失敗ログをパターンへ集約し、再学習と回帰テストに分岐させて、導入後の新しいログを再び収集する閉ループを示します。

失敗パターンには、元ログへの参照、再現条件、期待する動作、許容閾値、乱数seedまたは環境固定条件を持たせます。「未確認」「確認済み」「再学習投入」「テスト化」「解消」「再発」といった状態を管理すれば、改善サイクルのどこにあるかを追跡できます。