2026/04/13
はじめに
Windows 365 Cloud PC上にFirefox(Gecko)のビルド環境を構築し、38万ファイル・約4GBの大規模C++/Rustプロジェクトをリモートでビルドしてみました。
きっかけは、ブラウザエンジンの映像パイプラインを研究目的で調査する必要があったこと。手元のMacでビルドするとファンが全開になり他の作業ができなくなるため、「重いビルドはCloud PCに任せて、手元のMacは快適に保つ」という構成を試しました。結果、32GB RAMのCloud PCはビルド環境として非常に快適で、Azure内ネットワークの恩恵でツールチェーンのダウンロードも高速でした。
当社はMicrosoftパートナーとしてクラウドインフラの構築を支援しており、Cloud PCの業務活用ノウハウを日々蓄積しています。
前提知識: この記事ではSSH接続の基礎知識、Gitの基本操作、C++/Rustのビルドの概要を理解していることを前提としています。
なぜCloud PCをビルド環境にしたのか
- マシンスペックが十分 — Cloud PC(4コア/8スレッド・32GB RAM・512GB SSD)はFirefoxのビルド要件(8GB RAM以上・40GB以上の空き容量)を余裕でクリア
- ローカルマシンの負荷をゼロに — C++の大規模ビルドはCPU・メモリを長時間占有する。Cloud PCに任せれば手元のMacで普通に仕事ができる
- Azure内ネットワークの高速性 — Visual StudioやWindows SDKなどMicrosoft系ツールのダウンロードがAzure内通信で高速。GitHubからのクローンも速い
- 月額固定費に含まれている — 既にWindows 365を契約していれば追加費用なし。Azure VMを別途立てる必要がない
構成図
[Mac(手元)]
|
| SSH接続(Cloudflare Tunnel経由)
v
[Windows 365 Cloud PC]
|-- OS: Windows 11(4C/8T, 32GB RAM, 512GB SSD)
|-- ビルドツール: MozillaBuild + VS Build Tools 2022
|-- コンパイラ: Clang/LLVM 18 + MSVC
|-- 言語: Rust 1.94 + Python 3.12
|
v
[Firefox ビルド成果物]
|-- obj-ff/dist/bin/firefox.exe
やったこと
1. ソースコードのクローン
FirefoxのソースコードはGitHub上のgecko-devリポジトリ(Mozilla公式のGitミラー)から取得できます。全履歴を含めると10GB以上になるため、--depth 1で最新コミットのみをクローンしました。
git clone --depth 1 https://github.com/mozilla/gecko-dev.git C:\firefox-browser
結果、約38万ファイル・3.86GBに収まりました。--depth 1を指定しない場合の約1/3のサイズです。後から全履歴が必要になった場合はgit fetch --unshallowで取得できます。
なお、--depth 1はクローン時間とディスク使用量を節約するだけで、ビルド時間には影響しません。ビルドが使うのは最新のソースコードであり、gitの過去履歴(20年分のコミット)は参照しないためです。git logやgit blameで過去の変更を追いたい場合はフルクローンが必要ですが、ビルドだけが目的なら--depth 1で十分です。
2. ビルドツールのインストール
Firefoxのビルドには以下のツールが必要です。Cloud PCにはPythonとGitのみ入っていたため、残りを追加しました。
| ツール | 用途 | インストール方法 |
|---|---|---|
| Visual Studio Build Tools 2022 | C++コンパイラ・リンカー | 公式インストーラー |
| MozillaBuild | MSYS2ベースのビルド環境 | Mozilla FTP |
| Rust | Geckoの一部はRustで書かれている | rustup |
| LLVM/Clang 18 | Firefoxが要求するC/C++コンパイラ | LLVM GitHub Releases |
| NASM | AV1/VP9等のアセンブラ | NASM公式 |
| cbindgen | Rust ↔ C++バインディング生成 | cargo install cbindgen |
VS Build Toolsのインストールコマンド:
vs_buildtools.exe --quiet --wait --norestart --nocache ^
--add Microsoft.VisualStudio.Workload.VCTools ^
--add Microsoft.VisualStudio.Component.VC.ATL ^
--add Microsoft.VisualStudio.Component.Windows11SDK.22621 ^
--includeRecommended
参考: Building Firefox On Windows – Mozilla Source Docs
3. ビルド設定(.mozconfig)
ソースルートに.mozconfigファイルを作成し、ビルドオプションを指定します。
# .mozconfig
ac_add_options --enable-application=browser
ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --disable-tests
ac_add_options --disable-crashreporter
ac_add_options --disable-updater
ac_add_options --enable-bootstrap=no
ac_add_options --without-wasm-sandboxed-libraries
export CC="C:/LLVM/bin/clang-cl.exe"
export CXX="C:/LLVM/bin/clang-cl.exe"
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff
mk_add_options MOZ_PARALLEL_BUILD=8
--disable-testsや--disable-crashreporterでビルド対象を減らし、MOZ_PARALLEL_BUILD=8で8スレッド並列ビルドを指定しています。
4. ビルドの実行
MozillaBuildのシェルからビルドを実行します。
# MozillaBuildのbashを起動
C:\mozilla-build\msys2\usr\bin\bash.exe --login
# PATHを設定
export PATH="/c/nasm-2.16.03:/c/LLVM/bin:/c/Program Files/Git/cmd:$PATH"
export PATH="/c/Users/cloudadmin/.cargo/bin:$PATH"
# ビルド
cd /c/firefox-browser
./mach build
初回ビルドでは./mach bootstrapが自動的にWindows SDKやツールチェーンの追加コンポーネントをダウンロードします。
configureが完了すると、こんなメッセージが表示されます。
Reticulating splines...
これはMozillaエンジニアが仕込んだイースターエッグです。元ネタは1993年のゲーム「SimCity 2000」のロード画面に表示される偽の処理メッセージ。数学的には「スプライン補間の再計算」という意味ですが、実際にはスプラインの計算は一切行われていません。「configure完了、ここからコンパイルに入りますよ」というタイミングで表示されるジョークです。大規模OSSのソースには、こういった遊び心が随所に見つかります。
5. Firefoxの起動
ビルドが完了すると、以下のパスに実行ファイルが生成されます。
# ビルド成果物から直接起動
./mach run
# または直接実行
obj-ff/dist/bin/firefox.exe
つまったところ
Mozillaのツールチェーンサーバーが504エラー
./mach buildを実行すると、configureフェーズでMozillaのCI用サーバー(firefox-ci-tc.services.mozilla.com)からツールチェーンをダウンロードしようとします。このサーバーが一時的にダウンしていると504エラーでビルドが止まります。
ERROR: HTTPSConnectionPool(host='firefox-ci-tc.services.mozilla.com', port=443):
Max retries exceeded with url: /api/index/v1/task/gecko.cache.level-3.toolchains...
解決策: .mozconfigにac_add_options --enable-bootstrap=noを追加し、ツールチェーンの自動ダウンロードを無効化。代わりにLLVM/ClangをLLVM公式GitHubから手動インストールしました。
msys2環境でPATHが通らない
MozillaBuildのmsys2シェル内では、Windowsにインストールしたツール(Git、Python、Rust等)のPATHが自動的には引き継がれません。
/usr/bin/env: `python3': No such file or directory
解決策: シェル起動後に明示的にPATHを設定する必要があります。.bashrcに書いておくと毎回の手間が省けます。
export PATH="/c/Program Files/Git/cmd:/c/LLVM/bin:$PATH"
export PATH="/c/Program Files/Python313:$PATH"
export PATH="/c/Users/cloudadmin/.cargo/bin:$PATH"
WASMサンドボックスのヘッダーが見つからない
clangでWASM向けコンパイルが実行される際、wasi-sysrootのヘッダーが見つからずエラーになります。
ERROR: Cannot find wasi headers or problem with the wasm compiler.
解決策: 研究・検証用途であればWASMサンドボックスは不要なので、.mozconfigにac_add_options --without-wasm-sandboxed-librariesを追加して無効化しました。
Clang 18ではビルドが通らない
LLVM公式サイトからClang 18.1.8をインストールしてビルドを開始したところ、コンパイルの途中で以下のエラーが発生しました。
Unexpected compiler version, expected Clang 19.0.0 or newer.
VS Build Tools 2022の最新版(MSVC 14.44)のSTLヘッダーが、Clang 19以上を要求するようになっていました。LLVM 18は2024年リリースで当時は最新でしたが、VS 2022のアップデートにより互換性が切れています。
解決策: LLVM公式GitHubからClang 19.1.7をインストールして解決しました。大規模OSSのビルドでは、ツールチェーン間のバージョン互換性に注意が必要です。
ブラウザエンジンを触れると何ができるのか
「ブラウザのソースをビルドできて何が嬉しいの?」という疑問があるかもしれません。実は、ブラウザエンジンのレベルで改修できると、通常のWeb開発では不可能なことが実現できます。
通常のWebアプリケーション開発は、ブラウザが提供するAPIの範囲内で行います。しかしAPIに存在しない機能は使えません。エンジンに直接手を入れれば、その制約を超えられます。
| やりたいこと | 通常のWeb開発 | エンジン改修 |
|---|---|---|
| 画像の高速処理 | Canvas API(JavaScript、低速) | GPU直接処理 |
| ファイルの高速読み書き | File API(制限が多い) | ネイティブI/O |
| ハードウェアアクセス | WebUSB等(制限あり) | 制限なし |
| 独自プロトコル通信 | 不可能 | ネットワークスタックに追加 |
たとえば医療業界向けにDICOM画像をGPUで直接レンダリングする業務用ブラウザや、製造業向けにIoTセンサーと直接通信するブラウザなど、特定業界に特化したカスタムブラウザという選択肢が生まれます。「ブラウザのAPIの範囲内」でしか提案できない会社と、エンジンまで触れる会社では、提案の幅がまったく異なります。
Cloud PCをビルド環境にして感じたこと
良かった点
- 手元のMacが快適なまま — ビルド中もブラウザ・エディタ・Slack等を普通に使える。ファンも回らない
- Microsoft系ツールのダウンロードが速い — VS Build Tools(数GB)のインストールが体感で通常の2〜3倍速い。Azure内のバックボーン通信の恩恵
- SSHで全操作可能 — Cloudflare Tunnel経由でどこからでも接続。RDPよりSSHのほうが快適
- ディスク容量に余裕がある — 512GB SSDで、ソース(4GB)+ ビルド成果物(数十GB)+ツール類を入れても余裕
注意点
- Windows Updateによる再起動 — ビルド中に再起動されると最初からやり直し。アクティブ時間の設定で対策が必要
- セッション切断のリスク — SSH接続が切れてもビルドが継続するよう、
tmuxやscreen(MozillaBuildのmsys2で利用可能)を使うのが安全
ビルド結果
最終的に、以下の結果でビルドが完了しました。
| 項目 | 値 |
|---|---|
| ビルド時間 | 約58分 |
| CPU使用率 | 99%(4コア8スレッド全開) |
| コンパイラ警告 | 370件(サードパーティ含む) |
| エラー | 0件 |
| テスト | 全パス |
| ビルド成果物 | firefox.exe(666KB)+ 関連ファイル群 |
| ディスク使用量(ビルド後) | 約80GB(ソース + obj-ff) |
ビルド中のCPU使用率は常時99%で、8スレッド全てがフル稼働していました。手元のMacで同じことをやったらファンが全開になり他の作業は不可能ですが、Cloud PCなら手元の環境に一切影響を与えません。これがリモートビルド環境の最大のメリットです。
We know it took a while, but your build finally finished successfully!
Mozillaからの粋なメッセージとともに、ビルドは無事完了しました。
まとめ
- Windows 365 Cloud PCは大規模C++/Rustプロジェクトのビルド環境として十分なスペックを持つ
- Azure内ネットワークにより、Microsoft系ツールのダウンロードが特に高速
- 手元のMacの負荷をゼロにできるため、ビルド待ち中も他の作業ができる
- MozillaBuildのPATH設定やMozillaサーバーの障害など、つまりどころはあるが対処可能
- 月額固定のCloud PCを「クラウド上のビルドマシン」として使う発想は、CI/CD環境の構築や大規模OSS開発にも応用できる
クラウド環境構築のご相談
株式会社ビギニングは、Microsoftパートナーとしてクラウドインフラの設計・構築を支援しています。
- Windows 365 Cloud PCの導入・活用設計
- 開発環境のクラウド移行(ビルドサーバー・CI/CD環境)
- Cloudflare Tunnel等を活用したセキュアなリモートアクセス環境
お気軽にご相談ください。