「工場の操作盤を、人の代わりにロボットに押させてほしい」
この手の相談で最初にぶつかる壁は、たいてい想像と違うところにあります。カメラでもAIでもなく、ロボットに動きを覚えさせるシミュレーターが、現場に置ける機材では動かない。
NVIDIAの発表会でよく流れる、何百体ものロボットが仮想空間で一斉に訓練している映像。あれを動かしているIsaac Simは、レイトレーシング用のRTコアを積んだGPUを前提にしています。工場に置くような小型のAI端末に、そんなものは載っていません。ではクラウドの大型GPUを借りればいいのか。それをやると、回線が細い日はロボットが止まります。工場の中で完結させたくて始めた話なのに、本末転倒です。
諦めるしかないのか。そう思いながら手を動かしてみたら、抜け道がありました。描画を捨てて、物理計算だけをGPUに任せる。この方針で、手のひらサイズの端末1台に2,048体のロボットアームを同時に訓練させられました。
この記事では、RTコアを持たないエッジ端末1台で、2,048体のロボットアームを並列訓練した方法を解説します。シミュレーターの構成、強化学習にカメラ画像を渡さない設計、並列数ごとの実測スループット、そして「ボタンを押す」動作を成功率66.7%まで引き上げるまでの手順を、実測値とあわせて順に説明します。安全違反（アームが壁・床に接触した回数）は全構成で0%でした。
MuJoCo-Warpを選んだ理由
あの映像で本当に効いているのは何か。写実的な絵ではなく、物理シミュレーションを何千体ぶんも同時に回すことのほうです。訓練しているAIは、そもそも絵を見ていません。なら描画は丸ごと捨てられます。
NVIDIAとDeepMindが共同開発しているMuJoCo-Warpを試したところ、これが手元の端末のCUDAだけで素直に動きました。2,048体の仮想ロボットアームが、1台のエッジ端末の上で一斉に訓練に入ります。Isaac Simは要りませんでした。
| 観点 | Isaac Sim（今回は使えず） | MuJoCo-Warp（採用） |
|---|---|---|
| 必要なGPU | RTコア搭載GPUが必須 | CUDAが動けば可（手元の端末で動作） |
| 写実的な描画 | 得意（映像が作れる） | 捨てた（訓練には要らないと判断） |
| 物理の並列数 | 大規模並列 | 2,048体を1台で並列（8,192体まで確認） |
| 動かす場所 | ワークステーション／クラウド | 現場に置けるエッジ端末1台 |
強化学習にカメラ画像を渡さない設計
もうひとつ効いたのが、強化学習（RL）にカメラ画像を渡さなかったことです。AIが受け取るのは関節の角度と、狙う位置の3D座標だけ。「画面に何が映っているか」を読むのは視覚言語モデル（VLM）とカメラキャリブレーションの仕事、「どう腕を動かすか」がRLの仕事、と切り分けました。
この切り分けで楽になったのは、次の点です。
- きれいな絵を描く必要がなくなった——Isaac Simがなくても訓練が成り立つ
- カメラを替えても学習し直さなくていい——5分のキャリブレーションで済む
- シミュレーターと現実の差が「物理の差」だけになる——見た目を寄せる作業が丸ごと消える
並列数ごとのスループット実測
速度の話。ここは指標の選び方でいくらでも盛れてしまうので、先に決めておきます。物理シミュレーターは1回の制御につき25回の細かい計算を回します。だから「物理サブステップ/秒」と「制御ステップ/秒」では数字が25倍変わる。訓練がどれだけ進むかを見たいなら、後者です。
| 構成 | 制御ステップ/秒 | 物理サブステップ/秒 | CPU比 |
|---|---|---|---|
| CPU（10並列） | 6,242 | 156,055 | 1.0倍（基準） |
| MuJoCo-Warp 2,048体 | 19,383 | 484,582 | 3.1倍 |
| MuJoCo-Warp 8,192体 | 76,152 | 1,903,805 | 12.2倍 |
ただ、この表の12.2倍がそのまま訓練の速さになるわけではありません。方策の更新まで含めた実効速度で測ると、CPUの毎秒1,226ステップに対してGPU並列は毎秒3,477ステップ。およそ2.8倍でした。実時間で言うと、CPUが41分で300万ステップ、GPU並列は144分で3,000万ステップ。物理演算だけが速くなっても、学習側の処理が追いつかないと頭打ちになることが分かりました。
ついでに書いておくと、この訓練中もずっと同じ端末に30GB規模のVLMが載ったままでした。訓練側が余分に食ったGPUメモリは1GBほど。「見る」と「学ぶ」が1台に同居できるのは、現場で完結させたいときにそのまま効いてきます。
数を回した効果は、並べてみると分かりやすい。訓練途中の4段階に、同じ試験を受けさせました。未学習は失敗、300万ステップから先は成功。ボタンの位置も初期のずれも物理も揃えてあるので、この差はまるごと訓練の成果です。
接触判定の不備を修正した
できあがった映像を眺めていて、手が止まりました。ペン先が盤面にめり込んでいる。
最初のシミュレーターは接触の計算を手抜きしていました。ペン先に衝突判定がなく、「面をどれだけ越えたか」をそのまま押し込み量として数えていたのです。シミュレーターの中でしか成立しない動きで、実機で同じことをやれば盤面を壊します。数字は良くても、持っていけない数字でした。
そこでシミュレーターを作り直しました。変更点は次のとおりです。
- 物理ボタンを置いた——直径12mm、盤面から5mm突出、バネのストロークは4mm。満押しでも1mm残るので、ペン先が盤面に届くこと自体が構造上ありえない
- ペン先に衝突判定を入れた——貫通が物理的に不可能になった
- 触れたら即失格のルールを足した——アームやペン先が壁・床に当たった時点で終了。合格条件にも「安全違反0%」を追加
成功の判定も変えました。「面を越えた量」ではなく、ボタンが実際に3mm沈んで、その状態が保たれたかどうかで見ます。
作り直した物理で訓練し直すと、総合成功率は59.5%から48.0%に下がりました。腕が下手になったわけではありません。試験のほうを現実に寄せた結果です。この11.5ポイントは、見栄えのいい数字を実機に持っていける数字に替えるための代金でした。
むしろ、下がった数字より嬉しい結果がありました。安全違反 0.0%。2,048体が数千万回の訓練を重ねるあいだ、「壁と床には触れない」という縛りを最後まで破りませんでした。どの構成で測っても0.0%です。
最終的な成功率と安全違反率
最終的な成績です。合格の条件は着手前に決めてありました。初期ずれ15mm・視覚サーボON・各条件200回試して、総合成功率90%以上、かつ安全違反0%。
| 構成 | 総合 | 押す | 滑らせる | 安全違反 |
|---|---|---|---|---|
| 強化学習のAIだけ | 34.0% | 66.7% | 0.0% | 0.0% |
| 強化学習＋制御器（採用） | 48.0% | 66.7% | 28.6% | 0.0% |
| 合格ライン | 90%以上 | — | — | 0% |
90%には届きませんでした。安全のほうは条件を満たしましたが、成功率が足りません。残りは実機でのキャリブレーションで詰めていきます。
ひとつ補足を。押す動作の合否には「ペン先の傾きを何度まで許すか」という線引きが要ります。今回は40度にしました。勘で決めた数字ではありません。実際にボタンが作動した回のうち、96.6%が40度以内に収まっていたからです（97パーセンタイルが40.2度）。
滑らせる動作は強化学習だけでは解けなかった
成績表をよく見ると、押す動作（66.7%）と滑らせる動作（28.6%）でずいぶん差がついています。しかも強化学習だけに任せた場合、滑らせる動作は0.0%。1回も成功しませんでした。
後から追いかけて分かったのは、記憶がないと解けない種類の動作だったということです。滑らせる動作は「今どこまで滑らせたか」を覚えていないと最後まで持っていけません。ところが今回のAIは、毎回その瞬間に見えているものだけを頼りに動きます。いくら数を回しても、記憶を持たない設計では届かない場所がありました。
そこで、押す動作は強化学習のAIに、滑らせる動作は状態を覚えておける昔ながらの制御プログラムに任せ、指令ごとに振り分けることにしました。総合48.0%はこの組み合わせでの数字です。
分かったこと
ロボットアームの検証として書いてきましたが、AIの導入を検討する立場から見ても、そのまま当てはまる点がありました。
- テスト環境を、現実より甘くも辛くもしない。止まっているはずの対象の座標を毎フレーム±8mm揺らす設定を入れていた時期があり、これは現場に存在しない難問をAIに解かせていました。逆に貫通のように「シミュレーターだけが甘い」箇所もある。ズレは両方向に出ます。
- 一発の成功率だけで判断しない。実際の運用は「押す→カメラで画面が変わったか確かめる→ダメならもう一度」の繰り返しです。一発66.7%でも、3回試せる前提なら計算上96%まで来ます。見るべきなのは単発の精度ではなく、やり直しを含めた到達率のほうです。
- できなかったことを残しておく。今回なら「滑らせる動作が解けなかった」という一行が、次の設計をそのまま決めました。どこで失敗したのか切り分けられていない検証は、次に何も渡せません。
まとめ
この記事では、RTコアを持たないエッジ端末1台で2,048体のロボットアームを並列訓練した方法を解説しました。描画を捨ててMuJoCo-Warpに物理計算だけを任せ、強化学習にはカメラ画像を渡さず関節角度と目標座標だけを渡す構成です。制御ステップ換算で CPU比3.1倍（2,048体並列）、訓練パイプライン全体では2.8倍でした。「ボタンを押す」動作は成功率66.7%、安全違反は全構成で0.0%です。
一方、滑らせる動作は強化学習だけでは0.0%のままで、状態を保持する制御プログラムと組み合わせて28.6%。総合48.0%は、着手前に決めた合格ライン90%に届いていません。残りは実機でのキャリブレーションで詰めます。
Isaac Simが動かない機材で足止めされている場合、まず確認するとよいのは「学習させるAIが本当に画像を必要としているか」です。必要としていないなら、描画を捨てた時点でGPUの要件は一気に下がります。
検証環境：自社のエッジAI検証機（GPU搭載の組み込み向け端末）／ MuJoCo + MuJoCo-Warp ／ 6軸小型ロボットアーム（先端は固定タッチペン）。訓練も推論もVLMの常駐も、すべて同じ1台の上で動かしています。記事中の数字はすべてこの環境での実測値です。