DEVELOPMENT NOTE / 2026.10.25
カメラは、時刻を渡すと絵が返る「関数」になった。
箱庭ラボでは、シミュレーションの中を写すカメラ「箱庭カメラ」を作っています。その記録を 4 回に分けて紹介します。第 1 回は、なぜ箱庭にカメラが要ったのか、そして作ってみて何に気づいたのか、です。
足りなかったもの：カメラ
前のシリーズ「箱庭シナリオPRO」では、道路（OpenDRIVE）とシナリオ（OpenSCENARIO）を流せるようにしました。実在の街の道路で、割り込みや右折のシナリオを、何度でも同じ結果で回せます。
でも、カメラがありませんでした。いまの自動運転の AI、特に E2E（エンド・ツー・エンド）と呼ばれる作りは、カメラの映像を見て、そのまま操作を決めます。シナリオがあっても、AI に見せる映像がなければ、その AI を走らせて確かめる（閉ループで評価する）ことができません。箱庭にとって、カメラは欠けたピースでした。
作るべきか、迷った
正直に言うと、最初は作るつもりがありませんでした。カメラのシミュレーションには、もうプレイヤーがいます。オープンソースなら CARLA、商用なら dSPACE の AURELION や rFpro のような専門の製品です。写実的な絵を作る競争は、ニューラルレンダリングのような新しい技術の方向にも進んでいます。箱庭がそこに入るのは、筋が悪い。
それでも、箱庭の中で気軽に使えるカメラがないことは、これから箱庭ラボで何かを試すたびに、足かせになります。そこで、狙いを絞りました。写実性で勝負するのではなく、同じシナリオを何度回しても、同じ時刻の世界を写せるカメラ。簡単でいい。でも、決定論的であること。
決め手は、箱庭の時刻同期
決定論的なカメラに要るのは、「いつの世界を写したのか」が正確に決まることです。ここで、箱庭のコア技術である時刻同期が効きます。箱庭は、別々に動くシミュレータ（車の物理、シナリオ、人など）を、1 つの時計で進めます。
描画には Godot を選びました。箱庭には既にブラウザの 3D ビューアがありますが、ブラウザ越しでは通信のオーバーヘッドが足かせになります。Godot はオープンソースで、ライセンス（MIT）も扱いやすい。そして箱庭は既に Godot と共有メモリでつながっていたので（箱庭Godot）、1 ms の刻みで時刻を合わせるのも難しくありませんでした。
気づき：フレームレートで合わせなくていい
作り始めたときは、ゲームエンジンのフレームレートを、シミュレーションの時刻にどう合わせるかを考えていました。毎フレーム、シミュレーションと足並みをそろえる。そうしないと、絵と世界がずれる、と。
でも、動かしてみて気づきました。そもそも、合わせる必要がない。「箱庭の時刻 t の、この位置と向きの絵をください」と頼み、その時刻の世界を描いて返してもらえれば、それで決定論的になるのです。カメラは、時刻と姿勢を渡すと絵が返る、関数になりました。
- カメラは世界を持たない：車の位置、信号の色、人の関節の角度。世界の状態は、それぞれのシミュレータが箱庭のデータ（PDU）に書き続けています。カメラは頼まれた瞬間にそれを読み、再現して描くだけです。
- 止まるのは、撮る瞬間だけ：絵を頼むと、描き終わるまで、シミュレーション全体が時刻 t で待ちます。箱庭の時刻同期で全員が t で止まるので、カメラが読む世界は t のまま動きません。絵を頼まないあいだは、物理は描画を待たずに進みます。
- 世界が分かれていても、同じ時刻の絵になる：車は MuJoCo、信号と対向車は OpenSCENARIO、人は人のシミュレーション。動かしている仕組みが別々でも、1 つの時計の同じ時刻を写します。
絵はゲームエンジン、深さと意味は物理エンジン
カメラが関数になったことで、もう一つできるようになったことがあります。1 台のカメラを、2 つのエンジンで撮ることです。
- 色の絵（RGB）はゲームエンジンの Godot：光、天気、レンズ。見た目を作るのは、ゲームエンジンの得意分野です。
- 深さ（デプス）と、物体の意味（セマンティック）は物理エンジンの MuJoCo：どこまで何 m あるか、写っているのが道路か車か。答えは、シミュレーションが計算に使っている形そのものから取ります。
どちらにも「時刻 t、この位置と向き」を渡すので、2 つの絵は同じ瞬間の同じ世界を写します。同じ形から描くので、物体の境目もそろいます。別々のエンジンなので、そろうかどうかは測って確かめました。今回の受入テストの場面で、色の絵で見える境目と塗り分けの境目のずれを測ると、中央値 0 画素、9 割が 1 画素以内でした（測り方は第 4 回で）。カメラは、ゲームエンジンと物理エンジンの両方でできている。これも、カメラを関数にしたから組めた形です。
ほかにもあるのか、調べてみた
「こんなの、ほかにないのでは」と思いました。でも、調べてみると、近い考え方はちゃんとありました。
- CARLA の同期モード：固定の時間刻みで、サーバーがクライアントの合図を待って進めば、センサーの結果を再現できます。ただし、世界と物理を持っているのは描画するエンジン（Unreal Engine）自身です。
- AirSim：シミュレーションを止めて、撮って、再開する。状態と絵をそろえる使い方が、公式に勧められています。
- RoboVerse：物理は MuJoCo、描画は Isaac Sim。物理を 1 歩進めるたびに、その状態を描画に流し込みます。「真実は物理、描画は再現するだけ」という考え方は、箱庭とよく似ています。
- ArmarX（カールスルーエ工科大学のロボット基盤）：動いている Godot に、カメラの位置からの描画を頼んで、絵を受け取ります。
- 商用の製品：dSPACE AURELION、rFpro、VTD などは、物理と同期したセンサーのシミュレーションを製品として持っています。
なので、「世界で初めて」とは言いません。箱庭の違いは、組み合わせです。描画が世界を持たず、頼まれたときに、箱庭のデータから引いてくる（毎回押し込まれるのではない）。世界がいくつのシミュレータに分かれていても、箱庭の 1 つの時計でそろう。それを、Godot と共有メモリという軽くて開いた部品でやっている。そして、どこまでできているかを、数字で示す（第 4 回）。
このシリーズ
- カメラを「関数」にした ― なぜ箱庭にカメラが要ったのか（この記事）
- 作ってみた ― スキーマの拡張、コアのバグで半日、新しいサービス
- 真実はシミュレーションの中に ― カメラは、撮影の瞬間を読んで写すだけ
- CARLA と比べてみた ― 同じ場所、同じ条件で測った
次回は、作ってみた話です。最初の半日は、カメラではなく、箱庭のコアのバグと戦っていました。
※ 箱庭カメラは開発中です。製品としての提供範囲・時期は未定です。シミュレーションの画像は、実際のカメラの映像や、それを使うソフトウェアの性能・安全性を保証しません。
※ Godot は MIT ライセンスのオープンソースです。OpenDRIVE・OpenSCENARIO は ASAM e.V. の標準規格です。CARLA、AirSim、RoboVerse、ArmarX、dSPACE AURELION、rFpro、VTD は、それぞれの開発元・権利者のものです。3D 都市モデルは PLATEAU を使っています。