ロボット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より実行コストが高い
実機ベンチ	センサー較正、遅延・ジッタ、電源、接触、摩擦	リリース候補、安全・接触・実環境に関わる変更	実際の機械・電気条件を確認できる	実行時間、設備、人的安全管理が必要
限定環境試験	実環境での安全挙動と運用範囲	実機ベンチ合格後、段階的に実施	現場条件での挙動を確認できる	リスク管理と中止手順が不可欠

実機へ進める出口条件

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