WindowsでCARLA 0.9.16導入時にBoostで詰まる原因と解決策まとめ：UE4をビルドせずに動かす方法とupdate.batの20GBの正体

CARLA 0.9.16をWindowsに入れようとすると、依存関係の代表格であるBoostの導入でエラーに遭遇しがちです。さらに「Unreal Engineをビルドしないとだめなのか」「リリースZIPにあるCarlaUE4.exeを使ってUE4_ROOTを設定すれば回避できるのか」「update.batが20GBも落としてくるのは何なのか」と、疑問が一気に増えます。

この記事では、Windows環境で起こりやすいBoostインストール失敗の典型パターンと、最短で前に進むための実務的な手順、そしてUE4を“ビルドしない”運用がどこまで成立するのか、update.batがダウンロードする巨大データの中身を、導入の流れに沿って整理します。

WindowsでCARLA 0.9.16導入時にBoostで詰まる原因と解決策まとめ：UE4をビルドせずに動かす方法とupdate.batの20GBの正体

まず押さえる：CARLA（Windows）でBoostが失敗しやすい理由

Boost自体は有名なC++ライブラリ集ですが、Windowsでは「ビルドツールチェーン」との整合がシビアです。CARLA 0.9.16導入で躓きやすい根本原因はだいたい次のどれかに収束します。

Visual Studio（MSVC）のバージョン不一致（想定ツールセットと違う）
64bit/32bitやx64ターゲットの混在
Boostの入れ方が“ヘッダだけ”で終わっていて、必要なライブラリがビルドされていない
Python、CMake、Windows SDKの組み合わせが中途半端
既存のBoost環境変数（BOOST_ROOT等）が古い/別バージョンを指している

特にWindowsは、同じ「Boostを入れた」でも、vcpkgで入れたのか、公式配布を展開したのか、b2でビルドしたのかで状態が全く変わります。CARLA側のビルドスクリプトは「ある前提」を置いていることが多く、その前提から外れるとエラーが発生します。

解決の近道：Boostは“統一された方法”で入れる

結論から言うと、Boost絡みのエラーは「ツールチェーンと依存関係の導入方法を揃える」だけで解消することが多いです。以下のどちらかに寄せるのが安全です。

方式A：vcpkgでBoostを導入し、CMake/ビルド環境を揃える（おすすめ）

Windowsで最も再現性が高いのがこの方式です。ポイントは「Visual StudioのDeveloper PowerShell」など、MSVC環境が正しく有効なシェルで作業すること。

Visual Studio（C++開発環境、Windows SDK含む）を導入
vcpkgをセットアップ
Boostをvcpkgで導入（必要ならboost-filesystem等も含めて）
CMakeにvcpkgのtoolchainを渡して依存関係解決を固定化

この形にすると、Boostのビルド（MSVC向けの生成）もvcpkg側が面倒を見てくれます。「Boostは入っているのに見つからない」「リンクが通らない」の類が激減します。

方式B：Boost公式配布を使うなら“b2でMSVC向けにビルド”までやる

zipを展開して終わり、だと「ヘッダはあるけどlibがない」状態になりやすいです。CARLA側がリンクを要求しているケースでは即死します。

bootstrap.bat を実行
b2 で toolset=msvc、address-model=64 などを明示してビルド
BOOST_ROOTやLIBパスが古いBoostを指していないか確認

この方式は自由度が高い一方、環境差が出やすく、導入手順に慣れていないとハマりやすいです。

エラー切り分けの実務ポイント（スクショがなくても効くチェック）

質問文では「スナップショットがある」とのことでしたが、画像がなくても有効なチェックがあります。

Visual StudioのバージョンとC++ワークロードが入っているか
「MSVC v14.x」「Windows 10/11 SDK」「CMake tools」周りが欠けると、Boost以前にコンパイルが成立しません。
作業シェルが正しいか
普通のcmdやPowerShellだと環境変数が足りず、b2やCMakeがMSVCを見つけられないことがあります。
Visual Studio付属の「x64 Native Tools Command Prompt」系を使うと事故が減ります。
古いBOOST_ROOT/Pathが残っていないか
以前入れたBoostが残っていて、意図しない場所を参照していると「見つかるけど違う」になりやすいです。
一度、関連環境変数を整理してからやるのが安全です。
x64で統一されているか
Pythonだけ32bit、Boostだけ64bit、みたいな混在はリンクエラーの温床です。
CARLAを動かす前提では基本x64で揃えるのが無難です。

Unreal Engineをビルドせずに、リリースZIPのCarlaUE4.exeを使う方法はアリか？

「UE4のビルドにはアカウント作成が必要で面倒。リリースZIPにはCarlaUE4.exeがある。UE4_ROOTをそこに向ければいいのでは？」という発想は自然で、用途によってはアリです。ただし、期待して良い範囲と、ダメな範囲があります。

うまくいきやすいケース

**CARLAを“使うだけ”（シミュレータを起動して走らせる）**が主目的
サーバ（CarlaUE4.exe）を起動し、Python APIで操作するだけ
UE4側のソース改造や再ビルドが不要

この場合、配布物に含まれるCarlaUE4.exeが動くなら、UE4をローカルで丸ごとビルドしなくても前に進めることがあります。

うまくいかない・破綻しやすいケース

UE4プロジェクト（CarlaUE4）を改造したい／プラグインを変えたい
エンジン側をいじって再コンパイルが必要
CARLA本体（クライアント/サーバ）をソースからビルドし、UE4側とも整合させたい

この場合、結局UE4の開発環境が必要になりがちです。配布物は「実行に必要なものが入っている」一方で、「開発に必要なものが揃っている」とは限りません。

UE4_ROOTを設定する際の注意

UE4_ROOTは「そのパスにUE4のルートがある前提」で参照されることがあります。CarlaUE4.exeがあるディレクトリを指すだけでは、スクリプトが期待する構造（Engineやツール類）と合わず、ビルド工程で破綻することもあります。
目的が「起動して使うだけ」なら、UE4_ROOTよりも「配布されたサーババイナリをそのまま動かす」運用に寄せた方が安定します。

update.batが20GBダウンロードする理由：中身は何？

update.batが巨大なのは、CARLAが単なるコードだけでなく、シミュレータとして必要なアセットと依存物が非常に多いからです。一般的に、次のようなものが含まれます。

マップ、建物、道路、標識、植生などの3Dアセット
テクスチャ、マテリアル、シェーダ関連
センサーや車両モデルなどのコンテンツ
サブモジュールや外部依存の取得
場合によっては、ビルド・実行に必要な追加バイナリ一式

「シミュレータを動かす」にはコードだけでは足りず、UE側が読み込むデータ（コンテンツ）が必須です。update.batは、その不足分をまとめて揃える役割を持ちます。容量が大きいのは異常ではなく、むしろ「これがないと起動しても世界が成立しない」という性質のものだと考えると理解が早いです。

最短で前に進むためのおすすめ手順（目的別）

ここまでを踏まえて、目的別の最短ルートをまとめます。

1) とにかくCARLA 0.9.16をWindowsで動かしたい

リリースの配布物（CarlaUE4.exeを含む）を優先
update.batでコンテンツを揃える
Python API側の環境だけ整える
このルートはBoostでのソースビルド地獄を回避しやすいです。

2) CARLAを改造したい／ソースからビルドしたい

Visual Studio環境を固定（x64、SDK、CMake）
Boostはvcpkgで導入して再現性を上げる
UE4は開発用に必要になる前提で計画する
このルートでは、Boostエラーは「環境の揃え方」で勝負が決まります。

まとめ：Boostで詰まったら“導入方式の統一”が最優先、20GBは正常

WindowsでCARLA 0.9.16を入れる際のBoostエラーは、個別のメッセージに反応するより先に「Visual Studio（MSVC）と依存関係の導入方法を揃える」だけで解消することが多いです。Boostをバラバラの方法で入れたり、x64/32bitが混在したり、古い環境変数が残っているとハマります。

また、UE4のビルドを避けて配布物のCarlaUE4.exeを使う方針は、目的が「起動して使うだけ」なら成立しやすい一方、開発・改造が絡むと限界が来ます。update.batの20GBは、シミュレータの“世界そのもの”を構成するコンテンツ一式だと捉えると納得しやすいはずです。

この整理を踏まえて進めれば、Boostで足踏みする時間を大幅に減らし、CARLAの本題であるシミュレーション開発に集中できます。