ROS 2とIsaac GymのSim-to-Real実装：実機転移を成功させる3つの定量的KPIと計測手法

画面の中のロボットは優雅にタスクをこなしているのに、その学習済みモデルを実機にデプロイした瞬間、まるで痙攣（けいれん）したように激しく振動し始める。

ロボティクスエンジニアであれば、誰もが一度はこの経験をしたことがあるかもしれません。シミュレーション環境、特にNVIDIA Isaac Gymのような超高速な並列シミュレータを使っていると、数分で数年分の学習データが溜まり、画面上のスコアはみるみる上昇します。しかし、その「高いスコア」が実機での動作を保証するわけではありません。

多くのプロジェクトがPoC（概念実証）から抜け出せない最大の要因は、このSimulation-to-Real（Sim-to-Real）における「成功」の定義が曖昧だからです。「なんとなく動いた」レベルで実機テストに進み、原因不明の振動や暴走に対処するために、闇雲なパラメータ調整（パラメータ・チューニング）に時間を費やしていませんか？

強化学習を用いた自律制御システムの開発においては、理論と実機の間に深い溝が存在することがあります。そこで重要となるのは、「感覚的な調整」から「定量的な指標に基づくエンジニアリング」への移行です。

本記事では、ROS 2とIsaac Gymを連携させたシステムにおいて、開発フェーズを確実に移行させるための判断基準となる「3つの核心的KPI」と、その計測手法について掘り下げていきます。シミュレーションの数値を鵜呑みにせず、実機で価値を生むための「現実的なものさし」を手に入れましょう。

なぜ「動いた」だけでは不十分なのか：Sim-to-Realにおける成功の再定義

シミュレータ上でロボットが歩行や把持（グラスピング）に成功したとき、私たちはつい「完成した」と錯覚しがちです。しかし、ビジネスとしてのロボット開発において、それはスタートラインに過ぎません。ここではまず、なぜ従来の「エピソード報酬」だけの評価では不十分なのか、その技術的背景とプロジェクトへの影響を整理します。

シミュレーションのスコアと実機パフォーマンスの非相関性

強化学習において、エージェント（ロボット）は報酬関数（Reward Function）を最大化するように行動を学習します。シミュレーション空間は、物理法則がある程度簡略化された理想的な世界です。摩擦係数、剛性、接触時の反発などは近似値で計算されており、センサーノイズもガウス分布などで人工的に付与されたものに過ぎません。

この環境で「スコアが高い」ということは、「そのシミュレータの物理エンジンの癖（くせ）に最適化した」ということを意味します。これが実機におけるパフォーマンスと相関しないどころか、逆相関することさえあります。これを「Reality Gap（リアリティギャップ）」と呼びますが、問題はこのギャップが「動かしてみるまで分からない」という定性的な扱いをされている点です。

例えば、シミュレータでは無限のトルクを一瞬で出せても、実機のモーターには応答遅れや熱による制限があります。シミュレータ特有の挙動を利用して高得点を叩き出す「過学習」状態のモデルを実機に載せれば、ハードウェアを破損させるリスクさえあります。

技術的負債になる「過学習」のリスク

「とりあえず実機で動くようにパラメータを調整しよう」。この判断が、後々大きな技術的負債となる可能性があります。シミュレーションモデルと実機モデルの乖離（かいり）を埋めないまま、実機側のPIDゲインや強化学習の出力フィルタを場当たり的にいじると、何が成功の要因なのかが追跡できなくなります。

結果として、タスクの内容が変わったり、ロボットのハードウェア構成が少し変わったりしただけで、またゼロから調整をやり直すことになります。これはR&D（研究開発）フェーズでは許されても、製品開発フェーズでは致命的なコスト増大を招きます。

意思決定のための定量的基準の必要性

プロジェクトマネージャーや技術リードが下すべき判断は、「今のモデルで実証実験に進んでよいか？」あるいは「シミュレーション環境自体を見直すべきか？」という点です。これを判断するためには、「なんとなく良さそう」ではなく、「Sim-to-Realの転移率がXX%に達したため、実機テストへ移行する」と言える客観的な指標が必要です。

次章では、この判断を支える具体的な3つのKPIを定義します。

ROS 2 × Isaac Gym 連携における3つの核心的成功指標（KPI）

ROS 2の実時間性と、Isaac Gymの高速シミュレーションを連携させる際、ボトルネックになりやすいのは「通信」と「同期」です。ここでは、モデルの賢さだけでなく、システム全体の健全性を測るための3つの指標を提案します。

指標1：Sim-to-Real Transfer Rate（転移成功率）

最もシンプルかつ強力な指標です。シミュレーション上でのタスク成功率に対し、実機でどれだけその性能を維持できたかを比率で表します。

定義式：

Transfer Rate = (実機でのタスク成功率 / シミュレーションでのタスク成功率) × 100

例えば、シミュレーションで100回中95回成功（95%）し、実機で100回中60回成功（60%）した場合、転移率は約63%となります。

この指標のポイントは、「シミュレーションでの成功率を100%にすること」を目指すのではなく、「転移率を100%に近づけること」を目指す点にあります。シミュレーションでの成功率が80%でも、実機で78%出せるモデル（転移率97.5%）の方が、シミュレーションで99%だが実機で50%しか出ないモデル（転移率50.5%）よりも、実用化に近いと言えます。これは「ロバスト性（堅牢性）」の証明になるからです。

指標2：Action Latency Jitter（推論・通信遅延のゆらぎ）

ROS 2を採用する最大のメリットは通信のリアルタイム性ですが、Pythonベースの強化学習モデル（PyTorchなど）を組み込むと、ガベージコレクションやGPU転送待ちによって予期せぬ遅延が発生します。

ここで重要なのは、平均遅延（Average Latency）よりも遅延のゆらぎ（Jitter）です。制御周期が100Hz（10ms）のシステムにおいて、普段は8msで推論が終わるが、たまに25msかかる場合、その瞬間にロボットは制御不能になる可能性があります。

計測対象：

• センサーデータ取得から推論完了までの時間
• 推論結果がアクチュエータ指令として届くまでの時間

この「最大遅延」と「遅延の標準偏差」をKPIとし、制御周期内に収まっている割合（Deadline Miss Ratio）を厳しく監視する必要があります。

指標3：System Resource Efficiency（リソース効率と同期精度）

Isaac GymはGPU上で物理演算と強化学習を完結させることで高速化を実現していますが、ROS 2とのブリッジ部分でCPUメモリへのコピーが発生すると、そこがボトルネックになります。

評価項目：

• Real-time Factor（実時間係数）：シミュレーション速度と実時間の比率。Sim-to-Real検証時は、意図的に1.0（等速）に制限し、その状態でのCPU/GPU負荷を測定します。
• 同期ズレ：ROS 2のタイムスタンプとシミュレータのステップ進行の乖離。

特に、複数のカメラ画像やLiDAR点群を扱う場合、データのタイムスタンプが揃っていないと、ロボットは「過去の景色を見ながら現在の体勢で動く」ことになり、予測不可能な挙動を引き起こします。

指標の設定と計測環境の構築手法

定義したKPIを実際に測定するためには、正確な計測環境が必要です。ROS 2のエコシステムを活用した具体的な実装アプローチを紹介します。

ベースラインの設定：従来の制御理論（PID等）との比較

強化学習モデルを評価する前に、比較対象（ベースライン）が必要です。もし可能であれば、古典的なPID制御やMPC（モデル予測制御）で同じタスクを行わせ、その時のスコアや遅延を計測してください。

「強化学習を使えば魔法のように良くなる」わけではありません。ベースラインと比較して、処理負荷がどれくらい増え、その対価としてどれくらいタスク成功率が上がったのか。このROI（費用対効果）が見えないと、高価なGPUを搭載したロボットを量産する説得力が生まれません。

ROS 2トピックのタイムスタンプを用いた遅延計測の実装

遅延計測には、ROS 2のメッセージヘッダーに含まれる stamp フィールドを活用します。

1. センサーノード：データ取得時刻を header.stamp に記録。
2. 推論ノード：受信したデータの header.stamp と、推論完了時の現在時刻の差分を計算。

さらに詳細な解析には、ros2_tracing や LTTng といったツールを使用します。これにより、DDS（Data Distribution Service）層での通信遅延なのか、ユーザーコード（Pythonスクリプト）内での処理遅延なのかを切り分けることができます。

# シンプルなトピック遅延の確認例
ros2 topic delay /robot_joint_states

上記のようなコマンドラインツールも有用ですが、開発中はカスタムの診断ノード（Diagnostics Node）を走らせ、常にレイテンシのヒストグラムを可視化しておくことを推奨します。TensorBoard等に「推論時間」だけでなく「End-to-End遅延」をプロットするようにしましょう。

ドメインランダム化のパラメータ範囲とロバスト性の相関分析

Isaac Gymの強力な機能である「Domain Randomization（ドメインランダム化）」の設定も、定量的に管理します。

• 摩擦係数：±10% 〜 ±50%
• 質量：±5% 〜 ±20%
• 外乱ノイズの強さ

これらのランダム化の範囲（Range）を横軸に、実機での成功率（Transfer Rate）を縦軸に取ったグラフを作成します。範囲を広げすぎると学習が収束しなくなり、狭すぎると実機で通用しません。この「スイートスポット」を見つける作業が重要です。

指標に基づく意思決定：チューニングか、モデル再設計か

計測データが集まったら、次に行うべきは具体的なアクションの決定です。数値が目標に届かなかった場合、どこに手を入れるべきか。その判断フローを整理します。

転移成功率が低い場合のチェックリスト

実機でのTransfer Rate（転移成功率）が低い、例えば50%を下回るようなケースでは、以下の順序で原因を切り分けていきます。

1. 物理モデルの不一致：URDFやSDFファイルに定義した慣性モーメント、重心位置は実機と正確に合致しているでしょうか。ケーブルの重さや関節の摩擦といった微細な要素が見落とされているケースは珍しくありません。
2. アクチュエータモデルの不備：モーターのバックラッシュ（遊び）やデッドゾーンを含めたモデル化ができているか確認します。Isaac Gym標準のシンプルなPD制御だけでなく、より詳細なアクチュエータダイナミクスの追加を検討してください。
3. 観測情報の差異：実機のセンサーから得られるノイズ特性が、学習時に想定したノイズの範囲を逸脱していないか検証します。

これらの問題に直面した場合、取るべきアクションは学習時のハイパーパラメータ調整ではなく、「シミュレーション環境の物理的な修正」または「ドメインランダム化の強化」となります。

通信遅延が許容範囲を超えた場合のアーキテクチャ見直し

Action Latency Jitter（制御遅延の揺らぎ）が大きく、目標とする制御周期を維持できない場合、小手先のパラメータ調整では根本的な解決に至りません。システム全体のアーキテクチャを抜本的に見直す段階にきています。

• 推論エンジンの変更と最適化：PyTorchのモデルをそのまま実行するのではなく、ONNX RuntimeやTensorRTに変換してC++ノードで推論させるアプローチが王道です。ただし、モデル変換の際はツールの仕様変更に注意を払うべきです。
  • ONNXエクスポートの最新動向：PyTorchからのエクスポート時、古いバージョン（opset_version 17未満）は自動拒否される傾向にあるため、opset_version=18 以上の指定が現在の推奨手順としてコミュニティで報告されています。また、TensorRTとの互換性を高めるため、エクスポート時のパラメータに dynamo=False を追加する手法も有効な選択肢となります。
  • エッジ最適化の活用：NPUやGPUを活用したハイブリッド実行を強化するため、Oliveなどの最適化ツールを併用することで、エッジデバイスでの推論速度を劇的に向上させることが期待できます。
  • 移行時の注意点：推論エンジンや変換ツールの仕様は急速に進化しています。TensorRTの最新機能やONNXの正確なサポート状況については、実装前に必ずNVIDIAやONNXの公式ドキュメント、および最新のリリースノートを確認するようにしてください。
• 通信頻度の見直し：本当に1kHzでの制御が必須でしょうか。タスクによっては50Hzや100Hzでも十分なパフォーマンスを発揮する場合があります。観測（Observation）の頻度を意図的に下げ、アクション間の滑らかさは低レベルコントローラの補間処理に任せる構成への変更も有効な手段です。
• ノード構成の統合：プロセス間通信のオーバーヘッドを極限まで削るため、センサー処理と推論モジュールを同一プロセス（コンポーネント）内で実行し、メモリコピーのコストを排除します。

業界ベンチマークとの比較によるGo/No-Go判断

最終的に、開発したモデルを実際の製品や運用フェーズに投入するかどうかの判断基準（Quality Gate）を明確に定めます。

• 安全性：意図しない衝突や転倒の発生確率が、あらかじめ定めた許容値以下に収まっているか。
• 再現性：同じタスクを10回連続で実行し、すべて成功させることができるか。
• 環境変化への耐性：照明条件の変化や床の材質の違いなど、未知の外乱が加わってもTransfer Rateを80%以上の高水準で維持できるか。

これらの厳格な基準をクリアできない場合は、勇気を持って「No-Go（見送り）」の判断を下し、課題を整理した上で基礎研究フェーズへ戻る決断も求められます。

事例から学ぶ：測定の落とし穴と成功パターンの相関

最後に、数値管理を徹底していても陥りやすい落とし穴と、成功プロジェクトに共通するパターンを紹介します。

見せかけの高スコア：Reward Hackingの検知

四脚歩行ロボットの開発事例を挙げます。「前に進むこと」に高い報酬を与えた結果、ロボットは「激しく振動しながら、その振動の反動で少しずつ滑って前に進む」という奇妙な動作を学習しました。スコア上は「高速移動」として評価されましたが、実機ではモーターが過熱し、数分で停止しました。

KPIダッシュボードには、報酬だけでなく「エネルギー消費量（トルクの二乗和）」や「関節加速度の滑らかさ」も表示しておくべきです。人間が見て「不自然だ」と感じる動きは、数値上でもエネルギー効率が悪かったり、ジッターが大きかったりするものです。

長期間運用におけるモデルの安定性評価

短時間のデモでは成功しても、1時間連続稼働させると徐々に姿勢が崩れていくケースがあります。これは、リカレントニューラルネットワーク（LSTM/GRU）などの内部状態を持つモデルや、積分誤差が蓄積する場合に起こります。

成功パターンを持つチームは、「長時間耐久テスト（Endurance Test）」をシミュレーションと実機の両方で実施していることが多いです。シミュレーション上で数時間の連続稼働を早回しで検証し、メモリリークや状態発散がないかを確認してから実機に投入します。

開発チームと経営層で共有すべきダッシュボードの構成

技術的な指標（遅延ms、損失関数など）はエンジニアには有用ですが、経営層やクライアントには伝わりません。これらを「ビジネス指標」に翻訳して共有することが重要です。

• Transfer Rate → 「実戦配備の信頼度」
• Latency Jitter → 「動作の安定性リスク」
• System Efficiency → 「ハードウェアコストの削減余地」

このように可視化されたダッシュボードがあれば、追加の計算リソースへの投資や、開発期間の延長が必要な場合も、納得感を持って合意形成を図ることができます。

まとめ：不確実性を管理し、確実な成果へ

Sim-to-Realの成功は、魔法のようなアルゴリズムひとつで達成されるものではありません。地味ですが、現実とのギャップを直視し、一つひとつのパラメータを定量的に評価・改善していくプロセスの積み重ねです。

今回紹介した3つのKPI——転移成功率、遅延のゆらぎ、リソース効率——を軸に据えることで、開発チームは「なぜ動かないのか」という迷宮から抜け出し、「どうすれば目標値に達するか」という建設的な議論ができるようになります。

ROS 2とIsaac Gymの複雑な連携設定や、可視化ダッシュボードの構築に時間を割く必要はありません。あなたが注力すべきは、ロボットにどのような価値あるタスクをさせるかという、本質的な設計です。