DEVELOPMENT NOTE / 2026.10.19

同じ道路、同じ台数、同じPCで。何度回しても同じ結果で。

シリーズ最終回は、いちばん大変だった回です。ここまで作ってきたものを、自動運転のシミュレータとして広く使われているCARLAと、同じ条件で比べました。

夕方の思いつき

レインボーブリッジまで走った日の夕方、「この成果を、なんとか形にしたい」と思いました。そこで思いついたのが、CARLAの地図（Town）で、同じ走行試験をして比べられるんじゃないかということ。第3回で、CARLAのTown04はすでに読み込めるようにしていました（最初は組み立てに49分かかった、あの地図です）。

比べ方は、こう決めました。

• 同じ場所：Town04の高速道路。車を並べ、目標25 m/sで、車線変更なしで35秒走る
• 同じ計算機：同じWindows PC。どちらも画面を出さない
• 同じ物理の刻み：どちらも2 ms × 5 = 10 msごとに進める
• 同じ車：CARLA側は箱庭に近い車種を選び、質量約1,200 kg、タイヤ半径0.31 m、路面摩擦の相当条件をそろえる。車体寸法・軸距や制御方式には差が残る
• 比べる値：RTF（シミュレーションの時間 ÷ かかった実時間）。1より大きければ実時間より速い

夜通し、流しっぱなし

台数を1台から160台まで変えて、それぞれ何回も流します。夜12時ごろにテストを流して、夜中にスマホから様子を見たら……止まっていた。流し直し。それ以来、続けられなくなった実行は、理由を出してすぐ終わるようにしました。朝まで黙って止まっていた、が一番つらいので。

決定論に、こだわり出した

速さを比べるなら、比べている結果そのものが毎回同じでなければ意味がありません。箱庭は、物理や運転を別々のプロセスで動かす分散シミュレーションなので、CPUの混み具合で、互いの進み方が少しずつずれます。ここから、何度回しても、CPUがどれだけ混んでいても、同じ結果になることにこだわり出しました。

• ロックステップ（ガウス・ザイデル型）：運転の指令がそろってから車の物理を進め、運転の側は車の状態を待つ。CPUの負荷に関係なく、位置がビット単位で一致するようになった
• 車の物理を複数のプロセスに分ける：台数が増えたら、車の物理を4つのプロセスで並列に計算する
• パイプライン（Jacobi型）：車の物理を進めている間に、運転の側が次の指令を計算する。指令が1ステップ遅れる代わりに、さらに速くなる。これもビット単位で一致

第1回の最後に「残る壁」として書いた「何度回しても同じ結果に」の答えは、この夜に生まれました。

ついでに、たくさん直した

計測を回すと、これまで気づかなかった不具合や遅さが、次々に出てきました。

• 異常終了したあと、共有メモリのロックが残って次が起動できない → 箱庭のコアに、止まったら確実に止まる仕組みと、後始末の手順を入れた
• Windowsで、古いコアの部品（DLL）が残っていた → 起動のときに断るようにした
• Windowsの車の物理が、古いMuJoCoで動いていて3倍遅かった → 版が違えば起動のときに断るようにした
• 時刻を進めるしくみ（コンダクター）が、必要のないときもロックを取っていた → 切り替わりのときだけにした
• 街のモデルの動かない部品を、まとめて計算するようにした（Town04の速さが、Mac（MacBook Pro、Apple M2 Pro、メモリ32 GB）で1.69 → 4.85）
• 起動のときの決め打ちの待ち時間を外した

結果

20台の走行比較（動画）：同じTown04の道路で、計算にかかる時間の違いを並べて示しました。動画は1回の実行例で、表は複数回の計測結果です。

車の台数	CARLAのRTF	箱庭のRTF	箱庭 ÷ CARLA	箱庭の構成
1	4.372	16.355	3.74倍	1プロセス
5	2.635	4.168	1.58倍	1プロセス
10	2.212	4.109	1.86倍	4プロセス・パイプライン
20	1.394	2.339	1.68倍	4プロセス・パイプライン
40	0.859	1.211	1.41倍	4プロセス・パイプライン
80	0.505	0.675	1.34倍	4プロセス・パイプライン
128	0.337	0.400	1.19倍	4プロセス・パイプライン
160	0.283	0.318	1.12倍	4プロセス・パイプライン

• 速さ：どの台数でも、箱庭がCARLAより速く回りました。台数が少ないほど差が大きく、160台では約1.1倍です
• メモリ：CARLAは走行中の最大で14.5〜15.1 GB、箱庭は185 MB（1台）〜649 MB（160台）。箱庭はCARLAの約1/23〜1/80で、GPUを使わずに動きます
• 起動：地図の読み込みまで、CARLAは26〜29秒、箱庭は8〜15秒
• 再現性：同じ条件で5回走らせ、同じ車・同じ時刻の位置を比べました。箱庭は、すべての台数・構成で5回の位置がビット単位で完全に一致しました（プロセスを4つに分けても同じ）。CARLAも、すべての台数で5回の位置が一致しました

正直に書いておくこと

• 描画なしの比較です。CARLAの強みである高品質な描画やセンサーのシミュレーションは、比べていません
• 物理エンジンが違います。質量・タイヤ半径・摩擦は合わせましたが、車体寸法と軸距は違い、動きが完全に同じになるわけではありません
• 運転の仕方が違います。CARLAはTraffic Manager、箱庭はesminiとシナリオのリンクです。分岐での経路の選び方が違うので、車の通る道は一致していません
• 速さの値は、箱庭の性能改善後のものです。前の車の探し方とデータの変換の一部を、性能改善のために直しました。直す前と、すべての車の軌跡が完全に一致することを確かめています（データの変換の直しは暫定のものです）
• メモリの値は、改善前の最終テストのものです。改善後の計測では、計算ライブラリの作業領域がメモリを多めに見せていたため、使っていません
• CARLAの1〜40台は、同じ日の朝に測ったものです。80・128・160台は、最終テストの最後に同じPCで測りました
• 1台のPC、1つの地図での結果です。ほかのPC・地図・台数で同じ比になるとは限りません

計測環境：ノートPC（MouseComputer S4I7G60SRDDC）、Windows 11 Pro（26H2、ビルド26300）。CPU：Intel Core Ultra 7 155H（16コア：Pコア6・Eコア8・低電力Eコア2、論理プロセッサ22）。メモリ：64 GB（DDR5-5600）。GPU：NVIDIA GeForce RTX 4060 Laptop GPU（VRAM 8 GB）。SSD：NVMe 1 TB。電源プランは高パフォーマンスで、計測中は重い処理を止めました。どちらもWSLを使わず、ネイティブのWindowsで動かしています。

ソフトと設定：CARLA 0.9.16（画面を出さない設定、同期モード、1ステップ10 msを2 ms × 5のサブステップで計算）。箱庭はMuJoCo 3.16.0、すべてロックステップ。Pythonはどちらも3.12。各条件でウォームアップ1回のあと5回測り、その中央値です。

おわりに

標準規格とOSSの上に道路とシナリオを組み立て（第1回）、高速道路を走る車を作り（第2回）、見本の道路を全部物理で走らせ（第3回）、実在の街の道路とレインボーブリッジを走らせ（第4回）、最後にCARLAと比べました。ここまで、ほぼ4日間の出来事です。

この夜に生まれた「何度回しても同じ結果になる同期のしくみ」は、シナリオだけでなく箱庭のどの分散シミュレーションにも効くので、箱庭のコア機能として取り込む予定です。箱庭シナリオPROは、ここから条件を変えたシナリオを繰り返し回し、記録し、比べる段階に入ります。

※ 箱庭シナリオPROは開発中です。製品としての提供範囲・時期は未定です。シミュレーション結果は、実際の車両の走行性能・安全性を保証しません。
※ CARLAはオープンソースの自動運転シミュレータです。Town04はCARLAの地図です。本記事の数値は、上の条件での箱庭ラボの計測結果です。

関連：第1回 ／ 第2回 ／ 第3回 ／ 第4回 ／ Urban Mobility

← Now Buildingに戻る