5-12.現実で失敗する前に仮想空間で学ぶ

Omniverse、Isaac Sim、Sim2Realの世界

第1部：ソフトウェア編

ヒューマノイドロボット主要ソフトウェア2026完全版

AI頭脳・VLA・世界モデル・制御・RoboOpsで見る"ロボットの中身"

評価軸：役割 / 技術難度 / 差別化度 / 商用化度 / 日本企業の参入余地

読む前に

ヒューマノイド開発で最も高価な資源はGPUではなく実機の時間である。転倒すれば壊れ、人と接触すれば危険で、一台を一人が操作して集められる経験量には限界がある。その制約を外すのがシミュレーションである。

2026年、NVIDIA Isaac Sim 6.0、Isaac Lab、OpenUSD、Omniverse、Newtonがロボット開発のシミュレーションスタックを大きく更新した。合成データだけでなくTeleoperation、RL、Software-in-the-Loop、まれな事象検証まで同じ仮想環境へ集まり始めている。

ただし「シミュレーションで100％成功した」は実機100％を意味しない。本稿の主題は仮想空間を現実の代用品として信じることではなく、シミュレーションの誤差を前提に実機へ移せるシステムをどう作るかである。

目次

第1章　シミュレーションは何を代替するのか

第2章　Digital TwinとOpenUSD

第3章　物理エンジン――PhysXとNewton

第4章　センサーシミュレーション

第5章　OmniverseとIsaac Sim

第6章　Isaac Sim 6.0の現在地

第7章　Isaac Lab――ロボット学習基盤

第8章　Domain Randomization

第9章　System Identificationとキャリブレーション

第10章　Sim2Realギャップの正体

第11章　合成Perceptionデータ

第12章　Teleoperationをシミュレーションへ持ち込む

第13章　Newton――次世代物理エンジン

第14章　Software-in-the-LoopとHardware-in-the-Loop

第15章　失敗とまれな事象を仮想で作る

第16章　Sim2Realをどう評価するか

第17章　日本企業の参入余地

第18章　2030年――シミュレーションがロボット開発の本番になる

まず結論

Sim2Realの核心はシミュレーションを完璧にすることではない。現実に存在する不確実性をシミュレーションへ意図的に入れ、モデル誤差に耐えるPolicyとソフトウェアスタックを作ることである。

2026年の重要点はIsaac SimがOpen-source参照フレームワーク化し、Isaac LabがRL／Imitationの学習基盤として整備され、Newtonという新物理バックエンドが加わったことだ。シミュレーションはVisualデモからCI、データ工場、Policy工場へ変わっている。

本稿で扱うのは次の五点である。

• シミュレーションが設計・データ生成・RL・検証で担う役割

• Isaac Sim 6.0、Isaac Lab、OpenUSD、Newtonの関係

• Domain RandomizationとSystem Identificationが必要な理由

• まれな事象とSoftware-in-the-Loopの評価方法

• 日本企業がCAD・CAE・工場Digital Twinをロボット学習資産へ変える道

第1章　シミュレーションは何を代替するのか

ロボットシミュレーションは3Dデモではない。設計検証、Perception用データ生成、RL／Imitation Policy学習、ソフトウェアスタック検証を、実機より安く安全に反復するための開発基盤である。ヒューマノイドでは転倒、衝突、関節破損、人との接触があるため探索を実機だけで行うのは非現実的である。シミュレーションは現実そのものではなく、不完全なモデルからでも壊れないPolicyを作るための装置と考えるべきだ。

代替できないものも明確にしておく必要がある。人の予測不能な動き、設備の経年劣化、材料のロット差、現場の運用習慣。これらは仮想空間で完全には再現できない。したがってシミュレーションの目的は現実の代替ではなく、実機で試す回数を減らし、危険な条件を先に洗い出すことにある。この位置づけを関係者で共有しておかないと、仮想の成功率が独り歩きして期待値がずれる。

投資の順序も実務では重要になる。多くの現場で最初に効くのは、方策学習より結合試験である。ソフトウェアの更新ごとに同じ手順を自動実行し、退行を検出する。この用途なら物理の精度はさほど要らず、既存のCADからでも始められる。方策学習は、その基盤ができた後の段階と考えた方が投資の回収が早い。

実装・評価で見るべきポイント

何をシミュレーションへ移すかを先に決め、実機試験時間が何％減ったかでROIを測る。投資対効果は、削減できた実機試験時間の割合で測る。仮想での成功率は、この計算に使わない。

産業実装上の追加論点として、シミュレーションの導入効果は実機時間削減だけでなく、失敗を何回安全に再現できたかで測れる。まれな失敗の再現性が高いほどDebugサイクルが短くなる。

シミュレーション投資の判断は、削減できる実機時間で行う。同じ工程を実機だけで立ち上げた場合に必要な試行回数と、シミュレーションを挟んだ場合の回数を比較する。ここで見落とされやすいのがアセット作成の工数である。高精度なモデルを作る時間が実機試験の削減量を上回るタスクもある。判断材料として、アセット作成、キャリブレーション、保守の三つを含めた総工数で比較する。## 第2章　Digital TwinとOpenUSD

Digital Twinは見た目のCADではない。関節、質量、慣性、Collision、センサー、Material、コントローラーインターフェースまで含む仮想表現である。Omniverse／Isaac SimはOpenUSDをScene Graphの共通形式として使い、ロボット、棚、床、照明、センサー、Semanticラベルを一つのStageへ載せる。価値は一度作ることではなく、実機変更と同期し続けることにある。

変換の工数も見積もっておく必要がある。設計用のCADは形状の精度が高い一方、面数が多くそのままでは動かない。簡略化、衝突形状の作成、質量特性の付与、可動部の定義が要る。一台分で数日から数週間かかることも珍しくない。実務では、頻繁に使う設備から順に変換し、使わないものは後回しにする。全設備を一度に仮想化しようとする計画は、ほぼ確実に途中で止まる。

加えて、誰が保守するかを決めておく。設計部門が作ったモデルを、ロボット部門が更新できない体制では乖離が進む。共通の形式と保管場所を決め、更新の責任を明示する。

実装・評価で見るべきポイント

ツインのバージョンをFirmwareとハードウェアBOMへ紐付け、質量、慣性、関節限界、カメラExtrinsicの更新責任を明確にする。ツインのバージョンをファームウェアと部品構成表へ紐付ける。質量、慣性、関節限界、カメラの外部パラメータについて、更新の責任者を決めておく。

産業実装上の追加論点として、Digital TwinはアセットOwner不在で陳腐化しやすい。機械設計変更が自動でUSDへ反映されるパイプラインを作らなければ、数か月で現実と乖離する。

Digital Twinの価値は作った瞬間ではなく、実機の変更に追随し続けられるかで決まる。ハンドを交換した、センサーの位置を数ミリ動かした、床材を張り替えた。こうした変更が仮想側へ反映されない運用では、数か月でモデルが現実と乖離する。実務では、機体の設計変更手順の中にシーンの更新を組み込み、変更されなかった場合に警告が出る仕組みまで作る必要がある。## 第3章　物理エンジン――PhysXとNewton

物理エンジンは運動、接触、摩擦、衝突を数値的に解く。Isaac Sim 6.0ではPhysXに加えてNewtonの実験的サポートが入り、同じロボットを複数バックエンドで検証する方向が見えた。エンジンを変えると接触Solverや時間Stepの差で挙動も変わる。複数エンジンで崩れないPolicyはモデル誤差へのRobustnessを持つ可能性がある。

エンジンの選択は、学習の速度にも直結する。並列環境を大量に回す用途では、精度より一環境あたりの計算量が効く。逆に、最終検証では精度を優先する。実務では、学習用と検証用で異なる設定を使い分ける構成が一般的である。ただし設定を分けると差異が生まれるため、どのパラメータを変えたかを記録し、検証で崩れた場合に学習側へ戻せるようにしておく。

接触の扱いは特に注意が要る。時間刻み、反復回数、摩擦モデルの設定で挙動が変わり、同じシーンでも設定次第で成功したり失敗したりする。設定を固定し、変更時には影響範囲を測る運用が必要になる。

実装・評価で見るべきポイント

エンジン名ではなく実機のStep Response、Free Swing、接触Force、Slip Thresholdを再現できるかでキャリブレーションする。エンジンの選定は名称ではなく、実機のステップ応答、自由振動、接触力、滑り始める閾値を再現できるかで判断する。

産業実装上の追加論点として、物理エンジンの差は接触-richタスクで顕著になる。同じ摩擦値でもSolver実装が違えば挙動が変わるため、パラメータ値の一致だけでRealityを判断できない。

物理エンジンを選ぶときは、自社の工程で支配的な物理現象から逆算する。歩行なら足裏と床の接触、精密挿入なら剛体同士の微小な干渉、柔軟物なら変形と自己接触。どれを重視するかでエンジンの得手不得手が分かれる。加えて、複数エンジンで同じ挙動が出るかを検証する運用も有効である。エンジンを替えると崩れるポリシーは、現実の未知条件でも崩れる可能性が高い。## 第4章　センサーシミュレーション

カメラ、深度、LiDAR、IMU、Force/Torqueを理想値で出すだけなら簡単だが、現実のノイズ、遅延、Dropout、モーションBlur、Reflectance Dependenceを再現するのは難しい。Isaac Sim 6.0はカメラとRTX LiDARの描画スケジュールを物理時間へ合わせる機能も強化した。綺麗すぎるシミュレーションで学んだPerceptionは現実で崩れる。

センサーの遅延を模擬しているかは、必ず確認すべき項目である。理想値が即座に返る環境で学習した方策は、実機で位相がずれて振動する。実務では、実機のセンサーからデータが方策へ届くまでの時間を測り、その分布を仮想側へ入れる。加えて、フレーム落ちや通信の詰まりも模擬対象になる。常に一定周期でデータが来る前提の設計は、現場のネットワークでは成立しない。

加えて、複数センサーの時刻同期も再現する。仮想では完璧に揃うが、実機では数ミリ秒ずれる。このずれを学習時に経験させておかないと、実機で融合処理が崩れる。

実装・評価で見るべきポイント

合成センサーログを実機ログと比較し、Histogram、ノイズSpectrum、遅延、Invalid Pixel率を合わせる。合成センサーログと実機ログを、分布、ノイズのスペクトル、遅延、無効画素の割合で突き合わせる。見た目の一致では不十分である。

産業実装上の追加論点として、センサーシミュレーションはAverageノイズより失敗分布が重要である。Dropout、Saturation、Reflection、時間Sync誤差などまれな異常を含めなければ安全試験にならない。

センサーシミュレーションの検証は、理想値との一致ではなく実機との一致で行う。同じシーンを仮想と実機で撮影し、深度誤差、ノイズ特性、遅延の分布を比較する。とくに再現が難しいのは、レンズ汚れ、逆光、蒸気、粉塵といった現場固有の劣化条件である。これらは合成では作りにくいため、実機で収集した劣化データを別途持ち、学習の混合比を管理する設計が現実的である。## 第5章　OmniverseとIsaac Sim

OmniverseはOpenUSD、描画、物理などのライブラリ群であり、Isaac Simはロボットシミュレーション向けに統合したOpen-source参照フレームワークである。CAD、URDF、MJCF、実環境取得をUSDへ変換し、同じシーンを合成データ、Isaac Lab学習、ROS 2検証へ再利用できることが強みになる。

共通基盤を使う判断では、ライセンスと依存関係も確認する。オープンソースの部分と商用の部分が混在しており、配布形態によって条件が変わることがある。とくに、社外へ納品する成果物へ組み込む場合は、事前に法務と確認しておく。技術的に動くことと、商用配布できることは別の問題である。

運用面では、計算資源の確保も課題になる。高精度なレンダリングを伴う環境は、学習と検証を並行させるとGPUが不足する。実務では、用途ごとに必要な資源を見積もり、社内共有か専有かを含めて計画する。

実装・評価で見るべきポイント

CAD→USD変換、ロボットDescription、センサー、Semanticラベル、バージョン管理までパイプライン化する。設計データからシーン形式への変換、ロボット記述、センサー、意味ラベル、版管理までを一連の手順として整備する。

産業実装上の追加論点として、OpenUSDの価値は形式そのものよりアセットInteroperabilityにある。CAD部門、AI部門、工場Digital Twin部門が同じシーンを更新できるGovernanceが必要になる。

共通シーン形式を採用する意義は、同じアセットを複数用途へ再利用できることにある。合成データ生成、方策学習、ミドルウェアの結合試験、営業用のデモ。それぞれ別々に3Dモデルを作っている現場は多く、そこが最も無駄が大きい。導入時には、既存のCADからどの程度自動変換できるか、変換後にどれだけ手作業が要るかを実測してから全社展開の計画を立てる。## 第6章　Isaac Sim 6.0の現在地

Isaac Sim 6.0は2026年6月にGA Documentationが整備され、実験的Newtonサポート、Replicator Functional API中心のSDG、Teleoperation SDG、エピソード記録、モーション生成実験的APIなどが追加された。旧行動/イベントデータ生成からBreaking Changeもあるためバージョン固定が重要である。HeadlessとContainerワークフローの整備によりCIリグレッションへ使いやすくなった。

破壊的変更への対処は、移行の計画として持つ。新しい版に有用な機能が入っても、既存の資産が動かなければ移れない。実務では、移行の可否を判断するための最小構成を用意しておく。代表的なシーン、代表的な方策、代表的な検証手順。これを新版で一度通してみれば、移行の工数がおおよそ見積もれる。この準備がないと、版が古いまま取り残される。

加えて、複数版を並行運用する期間も想定しておく。開発は新版、量産は旧版という状態が数か月続くことは珍しくない。

実装・評価で見るべきポイント

Isaac Sim、Kit、アセット、ドライババージョンを固定し、開発PCではなくCI Containerで同じ試験を再現する。

産業実装上の追加論点として、Isaac Sim 6.0は機能が広い分、拡張依存も増える。量産では必要拡張だけを固定し、更新でAPIやアセット挙動が変わるリスクを管理する。

バージョン固定は、シミュレーションを開発基盤として使う場合の必須要件になる。破壊的変更が入ると、同じシーンが違う結果を出す。学習済みの方策が再現しなくなり、原因の切り分けに時間を取られる。実務では、シミュレータ、物理エンジン、レンダラ、アセット、乱数種をまとめてコミットハッシュで固定し、結果と一緒に保存する。この記録がなければ、半年前の実験を再現できない。## 第7章　Isaac Lab――ロボット学習基盤

Isaac LabはIsaac Sim上のOpen-sourceロボット学習フレームワークで、RLとImitation学習を大規模並列で回すためのタスク、環境、ロボットモデル、学習インターフェースを提供する。GPU並列化、Domain Randomization、センサー描画を学習ループへ組み込める。NVIDIAはIsaac GR00TのFoundation学習フレームワークとしても位置づける。

2026年3月16日のGTCでは、Newton物理エンジン1.0を伴うIsaac Lab 3.0がEarlyアクセスで公開された。同時にNVIDIAは、OmniverseとIsaacのフレームワークを使うロボットが200万台を超えたと述べている（発表ベース）。シミュレーションスタックがResearchツールから産業基盤へ移りつつあることを示す数字である。

学習基盤の評価では、学習の速度より再現性を重視する。同じ設定で同じ結果が出ないと、改善の効果を判定できない。実務では、乱数種を含む全設定を記録し、結果と一緒に保管する。加えて、学習の途中経過を残す。最終的な成功率だけでは、学習が安定していたのか偶然良い点に落ちたのかが分からない。

もう一点、既存の制御則との比較を必ず行う。学習した方策が、既存の手法より本当に優れているのかを同じ条件で測る。この比較を省くと、学習を使うこと自体が目的化する。

実装・評価で見るべきポイント

種、環境Config、アセットバージョン、Reward Weight、Checkpointを一つのExperiment IDで管理する。乱数種、環境設定、アセット版、報酬の重み、学習済みモデルを一つの実験番号で管理する。

産業実装上の追加論点として、Isaac Labでは学習環境をソフトウェアとしてReviewする必要がある。Rewardやランダム化変更はモデルアーキテクチャ変更と同じくらい結果へ影響する。

並列学習の環境を評価するときは、GPU台数あたりの学習速度だけでなく、環境の作りやすさを見る。自社の機体、什器、対象物を持ち込むのにどれだけの工数がかかるか。既存タスクの改変で済むのか、ゼロから書くのか。学習フレームワークの性能差より、この立ち上げ工数の方が実際の開発期間を左右することが多い。試験導入では、自社の1工程を実際に載せてみて測る。## 第8章　Domain Randomization

床摩擦、質量、モーター出力、遅延、照明、テクスチャ、カメラPoseを意図的に揺らし、Policyを一つのシミュレーションモデルへ過学習させないのがDomain Randomizationである。狭すぎればRealを含まず、広すぎれば学習が難しくなる。現場Measurementと製造公差からRangeを作るべきである。

ランダム化には副作用もある。範囲を広げるほど方策は保守的になり、性能の平均は下がる。速く動けるのに、あらゆる条件で失敗しないよう慎重に動く方策ができあがる。実務では、性能と頑健性の交換条件を意識し、用途で範囲を変える。研究用途では広く、特定工程の量産では実際の条件に絞る方が結果が良いことが多い。

加えて、ランダム化した条件のどれが効いたかを分析する。全部を揺らすのではなく、効く要因を特定して重点的に散らす方が学習効率が高い。

実装・評価で見るべきポイント

各Randomizationを一つずつ無効にするAblationを行い、実機成功率への寄与を確認する。効かない要素を残すと学習が遅くなる。

産業実装上の追加論点として、Domain Randomizationは現実を知らずに範囲を決めるとノイズInjectionになる。フリートログや製造公差から分布を更新するClosedループが必要である。

ランダム化の範囲は、想像ではなく実測から決める。床の摩擦係数、部品の質量ばらつき、モーターの個体差、通信遅延の分布。これらは製造公差の資料と現場の測定から得られる。範囲が狭ければ現実を含まず、広すぎれば学習が収束しない。実務では、まず実測値の分布を取り、その外側に安全側の余裕を持たせる。この作業は地味だが、転移成功率への寄与が最も大きい部分である。## 第9章　System Identificationとキャリブレーション

関節摩擦、モータートルク定数、Gearバックラッシュ、遅延、慣性などを実験から推定しシミュレーションへ反映するのがSystem Identificationである。完全な同定より、Policyが敏感なパラメータを優先して合わせる方が実務的である。経年劣化やバッテリーVoltageによる変化もRangeへ含める。

同定の作業は、測定治具の準備から始まる。関節の摩擦を測るには一定速度で回す機構が、慣性を測るには振り子的な運動が要る。この治具を持っているかどうかで、同定の精度と工数が大きく変わる。部品メーカーであれば、出荷時に測定した特性を添付するという提供形態が考えられる。買う側にとっては、自分で測る工数が丸ごと減る。

加えて、同定の結果を機体ごとに管理する。個体差は必ずあり、代表値だけでは説明できない挙動が出る。

実装・評価で見るべきポイント

実機から自動システムIDモーションを実行し、パラメータ更新日と対象Serial Numberを残す。実機で自動の同定動作を実行し、パラメータの更新日と対象機体の個体番号を記録に残す。

産業実装上の追加論点として、System Identificationは全パラメータを完璧に求めると終わらない。実機性能へのSensitivityが高いパラメータを上位から同定する方がコスト効率がよい。

同定作業は、全パラメータを合わせようとせず、方策が敏感なものから優先する。感度解析で、どのパラメータを何％ずらすと成功率が落ちるかを調べ、上位のものだけ精密に測る。加えて、経年変化を範囲として織り込む。新品のモーターと1年使ったモーターでは特性が違う。同定を一度きりの作業とせず、定期的な再測定として運用へ組み込む設計が要る。## 第10章　Sim2Realギャップの正体

Sim2Realギャップは一つではない。Visual、Dynamics、センサー、アクチュエータ、タスク分布、人間の挙動のギャップがある。どのギャップで失敗したか分類しなければ改善策が定まらない。シミュレーション成功率は実機成功率の保証ではなく、実機検証前のFilterである。

実務で効く優先順位も見えてきている。多くの実装はVisualギャップを埋めることに労力を割く。描画品質を上げ、照明をRandomizeする。だが実際に成功率を左右しているのは、物体配置の多様性であることが多い。整然と並べられた合成シーンで学習したモデルは、乱雑に積まれた現実で崩れる。描画品質より先に、配置の分布が現場を含んでいるかを確認する方が費用対効果が高い。

ギャップの評価では、どちらへずれているかも見る。仮想の方が簡単すぎるのか、難しすぎるのか。難しすぎる場合、実機では動くのに仮想で失敗するため、開発が過剰に保守的になる。実務では、双方向のずれを測り、仮想が現実より厳しい部分は緩めることも検討する。ギャップを埋めるとは、必ずしも仮想を厳しくすることではない。

加えて、ギャップの大きさを工程ごとに記録する。同じ機体でも、搬送では小さく精密挿入では大きいといった差が出る。

実装・評価で見るべきポイント

実機の失敗へGap分類Tagを付け、再現できるSimulation ScenarioをRegression Testへ追加する。分類のない失敗記録は改善に使えない。

産業実装上の追加論点として、Sim2Realギャップを一語で扱うと責任分界が曖昧になる。Visual、Dynamics、アクチュエータ、センサー、タスク、人間のどこでギャップが出たかを失敗Taxonomyへ落とすべきである。

ギャップの分類は、失敗のログから機械的に切り分けられる形にしておく。視覚で対象を見失ったのか、把持点は正しいのに滑ったのか、力の制御が効かなかったのか。どの段で崩れたかが分かれば、シミュレーション側で何を直すべきかも決まる。実務では、実機の失敗を録画とセンサーログの両方で残し、同じ初期条件を仮想で再現して比較する手順を定型化しておく。## 第11章　合成Perceptionデータ

ReplicatorはRGB、2D/3D Boundingボックス、Semantic/Instance Segmentation、深度、PointクラウドなどGround Truthを自動生成できる。まれな物体や危険シーンを人手アノテーションなしで増やせる。ただし合成データは量ではなく実機検証改善で評価すべきであり、実機Data少量＋合成大量のMixが現実的である。

合成データの生成では、何を作らないかも決める。全条件を網羅しようとすると計算量が膨らむ。実務では、実機で失敗した条件の周辺を重点的に生成する方が効率が高い。失敗のログから条件を抽出し、その近傍を自動生成する仕組みを組む。この循環ができれば、生成の総量を増やさずに性能を上げられる。

加えて、生成データの検査も必要である。物理的にありえない配置や、ラベルが誤っているデータが混ざると、学習が壊れる。自動検査の基準を先に決めておく。

実装・評価で見るべきポイント

合成／Real別の検証Setを持ち、合成追加がReal精度へ効いたか確認する。合成と実機で別々の検証セットを持ち、合成を追加したときに実機側の精度が上がったかだけを見る。

産業実装上の追加論点として、合成Perceptionデータではラベルが自動生成できる利点が大きいが、描画Artifactもラベルと完全整合してしまう。実機データでの独立検証が不可欠である。

合成Perceptionデータの効果は、実機の検証セットを固定したうえで測る。合成を追加するたびに実機の精度が改善したかだけを見る。合成データ上での性能向上を採用判断に使ってはならない。加えて、どの失敗が減ったかまで対応づける。透明物の検出が改善したのか、暗所での誤検出が減ったのか。効いた事例と効かなかった事例の蓄積が、次の生成方針を決める。## 第12章　Teleoperationをシミュレーションへ持ち込む

Isaac Sim 6.0はTeleoperation合成データGenerationとエピソード記録機能を強化し、シミュレーション状態と操作者入力をMulti-episode形式で保存できる。危険タスクを仮想で教え、一つの実演から物体Poseやシーンを変えたデータへ展開できる。人間とロボットのKinematics差をRetargetingする必要は残る。

仮想での実演には、操作系の設計という別の課題がある。実機のテレオペ装置をそのまま仮想へつなげるのか、専用の入力を使うのか。前者なら操作感が揃うが装置が要り、後者なら手軽だが操作の癖が変わる。実務では、収集したデータをどちらの経路で取ったかを区別できるようにし、混ぜて学習した場合の影響を測る。

加えて、仮想で集めた実演がそのまま実機で通用するかを早期に検証する。ここが通らなければ、収集の効率がどれだけ高くても意味がない。

実装・評価で見るべきポイント

操作者、Device、遅延、成功/失敗、修正回数をMetadataに残す。どの条件で集めた実演かが分からないデータは、後から選別できない。

産業実装上の追加論点として、シミュレーションTeleopは安全だがHaptic Feedbackが弱い。接触-richタスクではシミュレーションで上手い実演が実機で不自然になることがあり、RealデモとのMixが必要になる。

仮想空間での実演収集は、危険な作業や高価な部材を扱う工程で価値が出る。実機なら壊せない対象を、仮想では何度でも失敗できる。一方で、接触の手応えが操作者へ返らないため、力加減を伴う作業の実演品質は落ちる。実務では、位置決めや経路の実演は仮想で、力を伴う仕上げの実演は実機でと使い分ける。収集した実演がどちらの経路かをメタデータに残しておく。## 第13章　Newton――次世代物理エンジン

NewtonはOpen-source、GPU-accelerated、Extensibleな物理エンジンとしてロボット学習向けに開発され、2026年にはBeta／Isaac Sim実験的サポートが進む。意味はPhysXを単純に置き換えることではなく、エンジン-agnosticインターフェースと複数物理バックエンドでPolicyを検証できる方向にある。

新しい基盤を評価する際は、コミュニティの規模も判断材料になる。問題が起きたときに情報があるか、修正がどれだけ速く入るか。技術的な優位があっても、利用者が少なければ実運用の障害を自力で解決することになる。実務では、採用の前に自社の代表的なシーンで一定期間試し、遭遇した問題がどれだけ解決できたかを記録する。

加えて、既存の基盤との併用が可能かを確認する。片方に賭けるのではなく、両方で検証できる構成にしておく方が、長期的な選択肢を残せる。

実装・評価で見るべきポイント

自社ロボットの接触タスクでPhysX/MuJoCoと比較し、実験的APIを安全検証の唯一の根拠にしない。

産業実装上の追加論点として、Newtonのような新エンジンは研究速度を上げる一方、バージョンによる数値差が出やすい。ベンチマークの再現性にはエンジンコミットやSolver Settingの保存が必要である。

新しい物理エンジンを検討する場合、性能よりも移行コストを先に見る。既存のシーン、アセット、ロボットモデル、学習環境がそのまま動くのか、書き換えが要るのか。実験段階の機能を本番の唯一の根拠にはしない。現実的な使い方は、既存エンジンで作った方策を新エンジンでも検証し、両方で崩れないことを確認する二重検証である。移行はその結果を見てから判断する。## 第14章　Software-in-the-LoopとHardware-in-the-Loop

シミュレーションはPolicy学習だけでなくROS 2ノード、プランナ、ミッションマネージャ、Perception、コントローラーをつなぐSoftware-in-the-Loop試験Bedになる。Compute UnitやGatewayを実物へ置き換えるHILではネットワークのタイミングやI/Oを現実に近づけられる。ソフトウェアリリースごとに同じシナリオを自動実行するとスタック間副作用を検出できる。

結合試験を仮想で回す構成では、試験の粒度を設計する。全機能を通す長いシナリオは現実に近いが、失敗の原因を特定しにくい。短い単機能の試験は原因が明確だが、統合時の問題を見逃す。実務では、両方を持ち、短い試験を頻繁に、長いシナリオを定期的に回す構成にする。

加えて、実機の一部を組み込む構成も検討する。計算機や通信機器を実物にすれば、ソフトウェアだけでは再現しない遅延や輻輳を捉えられる。どこまで実物にするかは、過去に起きた不具合の分布から決める。

実装・評価で見るべきポイント

Scenario ID、Software Commit、Simulator Version、Pass／FailをCIへ記録し、Model Updateも同じRelease Gateを通す。

産業実装上の追加論点として、SIL/HILをリリースGateへ入れるとソフトウェア更新の心理的Barrierを下げられる。毎回実機全タスクを人手で確認する運用から脱却できる。

ソフトウェアの結合試験を仮想で回す構成は、リリース頻度が上がるほど効いてくる。同じシナリオを毎回自動実行し、成功率、遅延、安全違反の回帰を検出する。実務で重要なのは、シナリオを増やしすぎないことである。全部を回すと時間がかかり、結局実行されなくなる。頻出する工程と過去に事故が起きた条件に絞り、実行時間を現実的な範囲へ収める設計が続く。## 第15章　失敗とまれな事象を仮想で作る

人が突然横切る、床摩擦が低下する、センサーがFreezeする、ネットワークが100ms遅れる、バッテリーが低下する。実機では起こしたくない失敗こそシミュレーションで作る価値がある。ランダムに壊すだけでなくFMEAやHazard Analysisからシナリオを生成する。

稀な事象の生成では、発生確率も併せて設定する。ありえない条件ばかりを試すと、方策が過剰に保守的になる。実務では、現場の記録から実際の発生頻度を推定し、その頻度で混ぜる。加えて、複数の異常が同時に起きる条件も検討する。単独では対処できても、二つ重なると崩れる設計は珍しくない。

この試験の結果は、安全の説明資料としても使える。どの条件を試し、どう振る舞ったかを一覧にすれば、リスクアセスメントの根拠になる。

実装・評価で見るべきポイント

事故・Near Missを再現シナリオへ変換し、まれな事象CoverageをリリースKPIへ入れる。

産業実装上の追加論点として、まれな事象は生成数よりCoverageが重要である。FMEA項目とシナリオIDを紐付け、未検証Hazardを一覧化できる仕組みが必要になる。

稀な事象のシナリオは、思いつきではなくリスクアセスメントから生成する。危険源の分析で挙がった事象を、そのまま仮想の試験項目へ変換する。人が突然横切る、床の摩擦が落ちる、センサーが固まる、通信が遅れる、電池が減る。この対応づけを文書に残せば、安全の説明資料としても使える。規格が空白の領域では、この文書の厚さが導入の可否を左右する。## 第16章　Sim2Realをどう評価するか

2026年には、評価の場所そのものを移す試みが本格化した。動画生成の世界モデルを、実機の代わりの評価環境として使う方向である。

動機は明快だ。ロボットPolicyの評価は実機を動かすしかない。シーンをリセットし、同じ条件で何度も回し、Checkpoint同士を比較する。台数と人手で上限が決まり、再現性も担保しにくい。ここが基盤モデル開発の最大のBottleneckになっていた。

先行したのはGoogle DeepMindで、2025年12月にVeoを土台にした生成評価システムを公表した。行動条件付けと多視点の一貫性へ最適化し、新しい物体、新しい背景、新しい妨害物を入れたシーンでも政策間の相対的な優劣を正しく予測できたとする。検証は双腕Manipulatorの8 Checkpoint・5タスクについて1,600件超の実機評価と突き合わせて行われた。もう一つの狙いがRed Teamingで、物理的・意味的な安全制約に違反する挙動を、実機でやらせるわけにいかない場面で炙り出す。

2026年7月には数字が揃った。RoboWorldは自己回帰型の動画世界モデルと作業進捗を理解するVLMの採点役を組み合わせ、実機ベンチマークであるRoboArenaの評価を世界モデルの中で再現した。実機Leaderboardとの相関はPearson 0.989、Spearman 0.970。8 Policy分の再現に要した計算はH100で100時間である。実機なら数週間かかる比較が、GPU数日分に置き換わる。

同じ7月、GigaAIと清華大学がこの問いを体系的に検証した。7つの動画世界モデル、4種類の行動表現、32万4,000件を超える世界モデル内ロールアウトと実機実行の対応付け、1万2,000時間超の学習動画である。得られた結論のうち、シミュレーション設計者にとって重要なのは第一点だ。評価器としての質を決めるのは短期的な映像のリアルさではなく、長時間にわたって行動に忠実であり続けるロールアウトの一貫性である。第4章で述べた「綺麗すぎるシミュレーションで学んだPerceptionは現実で崩れる」という原則が、32万件のロールアウトで裏づけられた形になる。

ただし物理エンジンを置き換えるものではない。接触力、摩擦、関節トルクの飽和は映像に映らない。生成された映像の中で「入った」ことは、実機で入ることを意味しない。当面は、Manipulationの粗いScreeningとPerceptionの評価に生成型、精密な接触と歩行に物理エンジンという使い分けが現実的である。日本企業にとっての含意は具体的で、世界モデルを一から作らなくても自社工程の映像で評価用の神経シミュレータを作るという選択肢が現実味を帯びてきた。Policyを差し替えるたびにLineを止めて実機検証する運用は、いずれ持たない。

シミュレーション成功、実機成功率、Transferギャップを同じタスク定義で測る。Dynamicsなら軌跡誤差、接触Force、エネルギー、転倒率、Perceptionなら深度/検出誤差、タスクなら完了率を見る。さらにGPU時間、アセット作成、キャリブレーション工数に対して実機時間をどれだけ削減したかも評価する。

評価の運用では、基準となるタスクを固定し、長期にわたって同じ指標を追う。ソフトウェアも機体も変わっていく中で、比較の軸が動くと改善が測れない。実務では、代表タスクを数個決めて凍結し、それとは別に新しいタスクを追加していく。凍結したタスクの成績が落ちていないかが、退行の検出になる。

加えて、評価の実施頻度も決める。毎日回す軽い試験と、リリース前に回す重い試験を分け、それぞれの実行時間を現実的な範囲へ収める。

実装・評価で見るべきポイント

シミュレーション/Real双方で同じEvaluation Harnessを使い、観測、行動、成功判定を共通化する。仮想と実機で同じ評価の枠組みを使う。観測、行動、成否の判定を共通化しなければ、差そのものが測れない。

産業実装上の追加論点として、Sim2Real評価では成功率だけでなく確信度Intervalを持つ。試行数が少ない実機試験で1回の成功差を大きな改善と解釈しない。

評価では、仮想の成功率と実機の成功率を同じタスク定義で測り、その差そのものを指標として追う。差が縮まっているなら、シミュレーションの改善が効いている。差が縮まらないまま仮想の成功率だけが上がっているなら、仮想世界に過学習している。加えて、削減できた実機時間をGPU時間、アセット作成、キャリブレーションの工数と突き合わせ、投資判断の材料にする。## 第17章　日本企業の参入余地

日本企業は自動車、工作機械、工場設備でCAD、CAE、Digital Twin資産を持つ。課題はロボット学習用のOpenUSD、Semanticラベル、物理パラメータへ変換できていないことだ。SIerは工場をシミュレーション-readyにし、部品メーカーはアクチュエータやセンサーの実測モデルをソフトウェア資産として提供できる。

参入の形としては、三つが考えられる。第一が、設備や部品の仮想モデルを製品として提供すること。第二が、工場を仮想化する統合サービス。第三が、実測した物理パラメータをデータとして売ること。第三は地味だが、他社が容易に真似できない。摩擦、慣性、応答特性を測るには治具と経験が要る。

いずれの形でも、形状だけでなく物理と意味の情報を持つことが差別化になる。CADを変換しただけのモデルは、誰でも作れる。

実装・評価で見るべきポイント

CADを見た目の3Dからシミュレーション-readyアセットへ変換するPilotを作り、アセットライブラリを会社資産にする。設計データを仮想環境で使える形へ変換する試行を一件通し、アセットの蓄積を社内資産として管理する体制を作る。

産業実装上の追加論点として、日本企業のCAD資産はGeometryとして強いが、質量、Material、関節、Semantic情報が欠けることが多い。シミュレーション-ready化は新しいデータ工学市場になる。

日本企業の資産をシミュレーションで使える形へ変えるとき、最初の壁は形式変換ではなく意味情報の欠落である。CADには形状はあっても、質量分布、摩擦、可動範囲、意味ラベルがない。これを補う作業が実務の大半を占める。逆に言えば、この情報を持っている部品メーカーと設備メーカーには、形状と一緒に物理パラメータを提供するという新しい売り方がある。## 第18章　2030年――シミュレーションがロボット開発の本番になる

2030年にはロボットソフトウェアリリースの多くが実機より先に仮想フリートで検証される。フリートログから失敗を抽出し、シナリオを生成し、Policyを再学習し、仮想リグレッションを通して再配備するループがRoboOpsと結び付く。勝つ企業は最高のシミュレータではなくReal→シミュレーション→Train→Validate→配備→ログを最短で回す企業である。

仮想が本番になる将来では、検証の記録が製品の一部になる。どのシナリオを、どのバージョンで、どれだけ回して、どう振る舞ったか。この記録が安全の説明資料であり、不具合が起きたときの調査資料でもある。実務では、この記録を残す仕組みを最初から組み込む。後から遡って作ることはできない。

加えて、記録の保管期間も設計する。製品の寿命が10年なら、検証の記録もその期間参照できる必要がある。形式とストレージの選択がここで効く。

実装・評価で見るべきポイント

シミュレータ単体でなくRoboOps/MLOpsまで含むデータループを設計し、シナリオライブラリと失敗データセットを資産化する。シミュレータ単体ではなく、運用と学習まで含めたデータの循環を設計する。シナリオ集と失敗データを資産として扱う。

産業実装上の追加論点として、2030年には仮想リグレッションがソフトウェアリリースの標準になる。フリートで起きた失敗が翌日にはシナリオ化され、次ビルドで自動再現される速度が競争力になる。

仮想環境が開発の本番になるほど、その環境自体の保守が事業のコストとして表面化する。シーン、物理パラメータ、センサー設定、シナリオを、ソフトウェアと同じようにバージョン管理し、自動検証にかける。この運用を担う人と予算を確保しておかないと、数年で誰も更新しない資産になる。シミュレーションの競争は、作る競争から保守する競争へ移っている。

5軸評価

【役割】★★★★★／設計、データ生成、学習、検証を仮想空間へ移す基盤

【技術難度】★★★★★／物理、描画、アセット、キャリブレーション、分散学習を横断

【差別化度】★★★★★／シナリオライブラリとReal-to-シミュレーションループが企業Moatになる

【商用化度】★★★★☆／工場Digital Twinとロボットシミュレーションは商用、完全Sim2Realは発展中

【日本企業の参入余地】★★★★★／CAD、CAE、工場Digital Twin、部品パラメータを持つ

2026年8月29日時点の確認

NVIDIA Isaac Sim 6.0は2026年6月にGA。Release Notesでは、Physics Timeに同期したCamera／RTX LiDAR Rendering、Experimental Newton Support、Replicator Functional API中心のSynthetic Data Generation、Teleoperation SDG、Episode Recording／Replayなどが追加された。Isaac Simは現在、Omniverse Libraries上に構築されたOpen-source Reference Frameworkとして位置づけられている。

Teleoperation SDGは単なるVR操作Demoではない。isaacsim.replicator.teleopでVR-driven Teleoperationを行い、isaacsim.replicator.episode_recorderでArticulation、Rigid Body、Xform、Simulation Time、Teleop InputなどをMulti-episode HDF5へ記録できる。Stage SnapshotをUSDとして保存し、Episodeを後からReplayしてOffline Synthetic Data Generationへ使える。これにより、人がSimulation内で一度教えた操作を、別のRendering条件やDataset Writerで再利用できる。

Isaac LabはIsaac Sim向けのOpen-source Robot Learning Frameworkで、RL、Imitation Learning、Custom Actuator Model、Multi-GPU／Multi-node Trainingを扱う。NVIDIAはIsaac GR00T PlatformのTraining Frameworkとしても位置づける。

NewtonはIsaac Sim 6.0でExperimental Supportである。PhysXと似たTensor APIやEngine-agnostic Interfaceが用意され、ROS 2 BridgeやOmniGraphとの互換性も進む一方、Production-readyなPhysX完全代替と断定すべき段階ではない。2026年時点では「複数Physics Backendを試し、PolicyのSimulator依存性を検証できる重要な新選択肢」と表現するのが正確である。

Newtonの用途はSimulationだけにとどまらない点も押さえておきたい。NVIDIAのGR00T Whole-Body Controlでは、人間のMotion CaptureをUnitree G1の身体へ写すSOMA RetargeterがNewtonベースのSolverとして実装されている。物理Engineが、学習環境を回すためだけでなく、人間動作をRobot動作へ変換するData Pipelineの一部として使われている。第13回で扱うRetargetingの品質は、こうしたSolverの精度に直接依存する。

Synthetic Dataの対象もPerception画像だけではない。Perception Data Generation、Action／Event Data Generation、Grasping、Mobility、Teleoperation Episodeまで広がり、Simulationは画像生成ToolからData Factory、Training Ground、Regression Test基盤へ変化している。

日本企業にとっては、CADをUSDへ変換すること自体より、Scene、Physics Parameter、Sensor、ScenarioをHardware／Software Versionと同期して保守する能力が差別化要因になる。## 結論

シミュレーションはロボット開発の前座ではない。Policyを学習し、ソフトウェアを壊し、まれな事象を再現し、リリースをGateする本番環境になりつつある。

2026年のIsaac Sim 6.0とIsaac Labはその流れを明確にした。OpenUSDをシーンの共通層とし、PhysX／Newton、Replicator、Teleoperation、ROS 2、RL／Imitationをつなぐ。重要なのはツール名ではなく実機の失敗をシミュレーションシナリオへ戻して再発防止するループである。

日本企業が持つCAD、CAE、設備、部品パラメータは大きな資産である。それをシミュレーション-readyなデータへ変換できればヒューマノイドのソフトウェア競争にも参加できる。

次回予告

第13回　ロボットは人間の動作をどう学ぶのか――テレオペ、動画学習、合成データ、模倣学習

主要公式リンク・参考リンク

• NVIDIA Isaac Sim: https://developer.nvidia.com/isaac/sim/

• Isaac Sim 6.0リリースNotes: https://docs.isaacsim.omniverse.nvidia.com/6.0.0/overview/release_notes.html

• NVIDIA Isaac Lab: https://developer.nvidia.com/isaac/lab

• 合成データGeneration: https://docs.isaacsim.omniverse.nvidia.com/latest/synthetic_data_generation/index.html

• NVIDIA Isaac / Newton: https://developer.nvidia.com/isaac/

• Evaluating Gemini Robotics Policies in a Veo Worldシミュレータ（arXiv:2512.10675）: https://arxiv.org/abs/2512.10675

• RoboWorld（arXiv:2607.01060）: https://arxiv.org/abs/2607.01060

• GigaWorld-1（arXiv:2607.02642）: https://arxiv.org/abs/2607.02642

Isaac Sim 6.0 Teleoperation Synthetic Data Generation
https://docs.isaacsim.omniverse.nvidia.com/latest/synthetic_data_generation/tutorial_replicator_teleop_sdg.html

Isaac Sim 6.0 Newton Physics Backend
https://docs.isaacsim.omniverse.nvidia.com/6.0.0/physics/newton_physics.html

出典対応表

【Isaac Sim 6.0 GA機能、Newton実験的サポート、Teleoperation SDG、エピソード記録機能】NVIDIA Isaac Sim公式Docs／発表ベース

【Isaac LabのRL／Imitation学習、Multi-GPU、Customアクチュエータモデル】NVIDIA公式／発表ベース

【Replicator、Actor/物体SDG、深度/Segmentation/Boundingボックス生成】Isaac Sim Docs／発表ベース

【OpenUSD、SimReadyアセット、Omniverse連携】NVIDIA公式／発表ベース

【Isaac Sim Teleop SDG、Episode Recorder、HDF5記録・Replay】NVIDIA Isaac Sim 6.0公式Docs／発表ベース

【Newton IntegrationはExperimental、対応Workflow・検証Robotに制約】NVIDIA Isaac Sim 6.0公式Docs／発表ベース

ハッシュタグ

#ヒューマノイド #IsaacSim #Omniverse #Sim2Real #DigitalTwin #IsaacLab #Newton #OpenUSD #PhysX #合成データ #DomainRandomization #SystemIdentification #Replicator #ROS2 #世界モデル #神経シミュレータ #CAE #PhysicalAI #ロボットAI #製造業DX