LOG87R2R2R2026/3/12

UnityとPythonで作るロボット設計工程はAIに置き換わる｜それでも手で作る意味

UnityでPickAndPlaceの実装をした。

ロボットアームがコーヒーカップに接近し、つかみ、指定の場所に置く。たったそれだけの動作だ。でもその「たったそれだけ」の中に、接近フェーズ・把持フェーズ・設置フェーズという3つの段階があり、それぞれにスクリプトがあり、VCSチェックインがあり、確認がある。

把持の方法はFixedJoint。つかんだ瞬間にジョイントを動的に生成し、置いた瞬間に破棄する。距離が0.05メートル以下になったら把持判定、という小さなルールひとつで、ロボットは「カップをつかんだ」という事実を得る。

物理的な接触と、コードの上の判定は、別物だ。でもロボットにとっては同じことになる。

そのギャップが、おもしろい。

調べていて、気づいたことがあった

作業の合間に、最近の論文を読んでいた。

Cornell大学のDRAWER（CVPR 2025）と、UCバークレーのReal2Render2Real（CoRL 2025）。どちらも「現実からシミュレーションへ」というパイプラインを扱っている。Pixels to Motorsでやっていることと、構造的には同じ方向だ。

読んでいて、あることに気づいた。

これらの研究では、3Dスキャンという工程が存在しない。

スマートフォンで撮った、ごくふつうの動画。それを直接、シミュレーション環境の生成に使っている。いまiPhoneと3Dpressoを使って時間をかけてやっている3Dモデルを作るという作業が、パイプラインの中に登場しない。

最初はへえと思った。次の瞬間、ああ、そうかと思った。

そう。いま自分がやっているこの工程は、いずれ消えるかもしれない。

消えることを悲観していない。むしろ、そっちに向かっているなら正しい方向だと思う。

Pixels to Motorsの目標は、精度の高い3Dモデルを作ることじゃない。「iPhoneで撮ったものが、ロボットを動かす」という体験が成立することだ。

3Dスキャンはそのための手段だった。いまはまだ必要な工程だから、丁寧にやっている。でもその工程がなくなるなら、体験はもっとシンプルになる。撮る。動く。それだけになる。

精度はあとからお金で解決できる。体験の設計は、今やる。

これはPixels to Motorsを始めたときから変わらないコアな哲学だ。工程が消えることは、哲学が正しかったことの証明になる。

"ロボティクスの民主化"という言葉は、よくハードウェアのコストと結びつけて語られる。安いロボットが出れば、みんなが使えるようになる、という話だ。

でもぼくは少し違う見方をしている。

本当のハードルは、価格じゃなくて経路の長さだと思う。「こういう動作をしてほしい」という人間の意図から、「ロボットがその動作をする」という現実までの間にある、工程の数だ。

CADを覚える。モーションキャプチャのスタジオを借りる。物理シミュレーションのパラメータを調整する。そのひとつひとつが、ロボットを「使える人」と「使えない人」を分ける壁になっている。

動画を撮る。ロボットが動く。

その間にある工程がゼロになったとき、ロボットは本当に誰のものにもなれる。工場じゃなくて、キッチンに入れる。施設じゃなくて、自宅に来られる。

UXデザイナーがロボット開発をやっているのは、そこに向かいたいからだ。インターフェースを消すことで問題を解くのが、UXの仕事だから。