• はじめに
• 情報のありか
• ビルド環境の用意
  • ハードウェア
  • ビルドツール
  • ソースコード置き場の作成
  • MozillaBuildの環境設定
• 英語版NightlyのArtifact Modeビルドを作成する
  • リポジトリーのclone
  • ビルドの初期設定
  • ビルドの実施
  • インストーラーの作成
• 英語版Nightlyのフルビルドを作成する
  • フルビルドへの切り替え
  • ビルドオプションの指定
  • フルビルドの実施
• 日本語版Firefox ESR140のフルビルドを作成する
  • Firefox ESR用ブランチへの切り替え
  • Firefox ESR140のフルビルド
  • 日本語化とインストーラーの作成
• トラブルシューティング
  • コードに変更を加えた後に、ビルドが失敗するようになった場合
  • ビルド対象のブランチを切り替えた後に、ビルドが失敗するようになった場合
  • 以前にMozillaBuildでFirefoxをビルドしたことがある環境で、ビルドが失敗する場合
• まとめ

結城です。

このブログではこれまで、2015年と2017年にWindowsでのFirefoxの独自ビルドの作成方法をご紹介しました。

本稿執筆時点では、既定のバージョン管理システムがMercurialからGitに移行していたり、MozillaBuildやブートストラップスクリプトによる自動初期化の仕組みが進歩していたりして、また状況が変わっています。 この記事では、2026年1月現在においてWindows用のNightlyおよびFirefox ESR140の独自ビルドを作成する手順をご紹介します。

はじめに

この記事では話を簡単にするために、Firefoxの動作の解析のためにログ出力を増やしたり、Firefoxの不具合を修正するためのパッチの有効性を実際の動作で確認したりといった、開発や検証を目的とする場合を想定することにします。 また、Firefoxの法人向けサポートサービスを提供している当社においては、Firefox ESR版の運用時に遭遇したトラブルについて、原因調査や回避策の検討のためにデバッグ用ビルドを顧客環境で実行して頂く場合があるため、最終的にはその範囲にも言及します。

この記事では以下の3段階に分けて、それぞれのビルド手順を順番に解説していきます。

1. 英語版Nightly Artifact Modeビルド（HTML/XML、JavaScript、CSSなどで実装されている箇所の変更の検証、または、それらの箇所へのログ出力追加による詳細なデバッグ用）
2. 英語版Nightly フルビルド（C++、Rustなどで実装されている箇所の変更の検証、または、それらの箇所へのログ出力追加による詳細なデバッグ用）
3. 日本語版Firefox ESR140 フルビルド（日本語版を常用している顧客の環境でのデバッグ用）

情報のありか

Firefoxのビルドに関する情報は、本稿執筆時点ではFirefox Source DocsというサイトのGetting Set Up To Work On The Firefox Codebaseというセクションから辿ることができます。 Windowsでのビルドなら、Building Firefox On Windowsを見ることになります¹。

基本的には、このオフィシャルの情報のとおりにやればつつがなくFirefoxをビルドできます。 本記事では、オフィシャルの情報ではカバーされていない部分を補完しつつ、過去のやり方を踏襲してはいけない（すると却ってドハマリする）事への注意事項を併せて説明していきます。

ビルド環境の用意

ハードウェア

Firefoxのビルドにあたっては、ストレージとRAMに十分な余裕があることが望ましいです。 上記ページでは最低条件が以下のように示されています。

• CPU：特に指定無し
• RAM：最低4GB、推奨8GB以上
• ストレージの空き領域：最低40GB以上

本記事の執筆にあたっては、以下の2環境を使用しました。

• デスクトップPC
  • OS：Windows 11 Pro 25H2
  • CPU：Intel Core i5-10400 2.90GHz CPU
  • RAM：48GB
  • ストレージ：USB接続したM.2の500GB SSD（ほぼすべて空き領域、全体を開発ドライブに設定）
• ラップトップPC
  • OS：Windows 11 Pro 25H2
  • CPU：Intel Core i5-8250U 1.60GHz CPU
  • RAM：16GB
  • ストレージ：USB接続の1TB SSD（空き領域約400GB以上）、うち70GBを開発ドライブに設定

実際のビルド手順の説明でも述べますが、Artifact Modeではないフルビルドを行うには充分な量のRAMが必要です。 使用したデスクトップPCでは、他の作業を行っている状態でもRAMの空きが20GB以上あり、片手間でも問題無く規定の設定のフルビルドを完遂できました。 他方、ラップトップPCではWindows起動時点でRAMの空きが10～12GBほどで、規定の設定でフルビルドを試行すると途中でどうしてもOut of memory（メモリー不足）のエラーが発生して失敗してしまい、フルビルドを完遂するにはビルドオプションで最適化を無効にする必要がありました。 RAM搭載量が不充分なPCしか手元に無い場合は注意してください。

ビルドツール

Firefoxのビルド作業は、多数のUnix系のツールに依存します。 WindowsでFirefoxをビルドするには、必須ツール類の詰め合わせパックであるMozillaBuildを使います。 リンク先から最新版のインストーラーをダウンロードし、インストールしておいて下さい。

MozillaBuildはMinGWのコマンド操作環境を提供します。 インストール完了後に C:\mozilla-build\start-shell.bat をダブルクリックするとコンソールを起動できますが、Windows Terminalを使っている場合、設定を編集して新規タブの選択肢にMozillaBuildを追加しておくのがおすすめです。 筆者は「MozillaBuild」の表示名で登録しています。

本稿執筆時点のMozillaBuildの最新版は、バージョン4.2です。 MozillaBuildは随時更新され不具合が修正されていますが、自動更新はされないため、FirefoxがメジャーバージョンアップしたときなどのタイミングでMozillaBuild自体を更新して最新の状態を保つとよいでしょう。

MozillaBuildを更新すると依存ツールが新たに同梱されるようになることがありますが、古いバージョンのMozillaBuildでのビルド過程で自動ダウンロードされた依存ツールの古いバージョンが残留していると、それらが原因となってビルドに失敗することがあります。 MozillaBuildの更新時は、MozillaBuildだけでなく、以前のビルド時に自動的にダウンロード・保存された依存ソフトウェア類の置き場所（~/.mozbuild、~/.cargo、~/.rustup）も一旦すべて消去し、MozillaBuildをクリーンインストールしてから、後述する ./mach bootstrap を用いて依存ソフトウェア類も再インストールすることを強くお勧めします。

ソースコード置き場の作成

MozillaBuildのインストールが完了したら、start-shell.bat を実行してシェルを起動し、Firefoxのソースコードの置き場所を作成します。

Firefoxのビルド中は深い階層のファイルが頻出するため、パスの最大文字数の制約に抵触しやすくなります。 そのため通常は、C:\mozilla-source のように浅い階層にソースコードリポジトリーを置くことが推奨されています。 MozillaBuildのシェルで操作する場合は以下の要領です。

$ mkdir /c/mozilla-source
$ cd /c/mozilla-source

Windows 11では、開発ドライブ（Dev Drive）をソースコード置き場に利用することで若干のビルド時間短縮が見込めます。 ストレージに充分な空き領域がある場合、50～100GB程度を開発ドライブ用パーティションに分割して使うとよいでしょう。 筆者の場合、前述のラップトップPCでは外付けSSDに70GBほど確保して開発ドライブ用パーティションとし、ドライブ文字「F」を割り当てた上で、以下の要領でソースコード置き場を作成しました。

$ mkdir /f/mozilla-source
$ cd /f/mozilla-source

本記事では、ソースコード置き場を開発ドライブ上の F:\mozilla-source （MozillaBuildの環境でのパスは /f/mozilla-source）にしたものとして説明していきます。

Firefoxのソースコード内に含まれるファイルや、ビルドして作られるファイルの中には、ウィルス対策ソフトウェアのリアルタイム検出機能で危険なファイルと（誤）判定されてしまう物があります。 従来は、それらのファイルが意図せず削除されてしまわないようにするために、ソースコード置き場をウィルス対策ソフトウェアの監視対象外に設定する²必要がありました。 本稿執筆時点では、この手順はブートストラップスクリプトで自動化されているため、手動での設定は原則として不要です。

MozillaBuildの環境設定

MozillaBuildでのビルド作業時に躓きやすい点として、ホームディレクトリーのパスにひらがな・カタカナ・漢字・半角スペースなどが含まれているとビルドに失敗するという問題があります。 MozillaBuildのシェル（Bash）は、Windowsのホームディレクトリーを HOME として起動します。 Windowsのセットアップ時に特に注意せずに本名でWindowsのアカウントを作成して、ホームディレクトリーが C:\Users\結城 洋志 のように非ASCII文字を含むパスになったままの状態だと、Firefoxのビルドは行えません。

Windowsのアカウントを作り直したくない場合は、環境変数を使って前述のソースコード置き場をホームディレクトリーに再設定するのが回避策としてお勧めです。 C:\Users\（ユーザー名）\.bash_profile の位置にテキストファイルを作成し、以下のように記述してください。

export HOME=/f/mozilla-source
# こちらはWindows形式のため、バックスラッシュはエスケープのため二重にする。
export USERPROFILE=F:\\mozilla-source

また、Gitのコミットメッセージの入力などに使われる既定のテキストエディターは初期状態ではnanoになっていますが、ここは使い慣れたエディターを使いたい所でしょう。 環境変数を設定すれば、使い慣れたWindowsアプリを既定のテキストエディターに使うこともできます。 例えばVisual Studio Codeであれば .bash_profile で以下の要領で設定します³。

export EDITOR='sh -c "\"C:\Users\(ユーザー名)\AppData\Local\Programs\Microsoft VS Code\Code.exe\" \"$1\"" > /dev/null 2>&1'
# git commit などで自動起動されるエディターはEDITORではなくVISUALの指定が参照される。
export VISUAL='sh -c "\"C:\Users\(ユーザー名)\AppData\Local\Programs\Microsoft VS Code\Code.exe\" \"$1\"" > /dev/null 2>&1'

ちなみに、ソースコードを編集して保存したときに自動的にlintを実行するなど、Firefoxの開発にVSCodeを使う場合のお勧めの設定も案内されています。 VSCode使いの方は、そちらも併せて参照して下さい。

筆者は以下のように設定して、MozillaBuildに同梱されているvimを既定のテキストエディターにしています。

export EDITOR=/usr/bin/vim
export VISUAL=/usr/bin/vim

また、筆者は他にも、利便性向上のため以下の設定も使用しています。

# 複数のMozillaBuildのシェルを並行して使用したときに、Bashのコマンド履歴が共有されるようにする。
function share_history {
  history -a
  tac ~/.bash_history | awk '!a[$0]++' | tac > ~/.bash_history.tmp
  [ -f ~/.bash_history.tmp ] &&
    mv ~/.bash_history{.tmp,} &&
    history -c &&
    history -r
}
PROMPT_COMMAND='share_history'
shopt -u histappend

# コマンド履歴の保持件数を多くする。
export HISTSIZE=9999

英語版NightlyのArtifact Modeビルドを作成する

まずは手始めに、簡易ビルドである「Artifact Modeビルド」から試してみます。

Firefoxは「C++やRustなどで開発されている基盤層」と「JavaScript・XML/HTML・CSSで開発されているGUI層」で構成されています。 基盤層についてMozilla公式のビルド済みバイナリーをダウンロードしてきてそのまま使用することで、ビルド時間や使用するRAMなどを節約するのが、Artifact Modeです。 Artifact Modeのビルドは日本語化はできませんが、GUI層のソースコードを変更して動作を検証する程度であれば充分に有用です。

リポジトリーのclone

初回のビルド時は、Mozillaが用意しているブートストラップ用のPythonスクリプトを使います。 MozillaBuildのシェルを起動し、事前に用意したソースコード置き場に移動して、ブートストラップスクリプトをダウンロードおよび実行します。

$ cd /f/mozilla-source/
$ wget https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py
$ python3 bootstrap.py

スクリプトを実行すると、Firefox公式のGitリポジトリーのclone先を訊ねられます⁴。 何も入力しないでそのままEnterキーを押せば、ソースコード置き場に firefox というディレクトリー名でcloneされます。

以前は、「Firefox ESRをビルドするなら別リポジトリーの releases/mozilla-esrXXX をcloneしなくてはいけない」といったリポジトリーの使い分けが必要でしたが、本稿執筆時点では、Firefoxのリポジトリーは基本的にこれ1つだけを見れば良いようになっています。 通常リリース版もESR版もこのリポジトリーのブランチになっているため、clone後に手動で git switch esr140 などとするだけでビルド対象を切り替えられます⁵。

Firefoxのリポジトリーは歴史的経緯もあって巨大なので、cloneにはかなり時間がかかります。 ネットワークの不調やディスクの不調など何らかのトラブルでclone操作が中断されてしまった場合は、もう一度ブートストラップスクリプトの実行からやり直してください。

ビルドの初期設定

ブートストラップスクリプトでのcloneが完了すると、用済みになったブートストラップスクリプトを削除するかどうか尋ねられた後、続けて初期設定処理が実行されます。 作業を中断した場合も、cloneされたリポジトリーに cd してから ./mach bootstrap を実行すれば、このステップからやり直すことができます。

$ cd /f/mozilla-source/firefox
$ ./mach bootstrap

初期設定では、まず最初にビルドの種類を選択します。 以下のように選択肢が表示されますが、今回はArtifact Modeを使用するので、そのままEnterキーを押すか、1 を入力してEnterキーを押して先に進みます。

Please choose the version of Firefox you want to build (see note above):
  1. Firefox for Desktop Artifact Mode [default]
  2. Firefox for Desktop
  3. GeckoView/Firefox for Android Artifact Mode
  4. GeckoView/Firefox for Android
  5. SpiderMonkey JavaScript engine
Your choice: 1

Windows 11で開発ドライブを使用できるにもかかわらず使用していない場合は、この時点で開発ドライブの使用を推奨する確認のメッセージが表示されます。 開発ドライブを用意できる場合は、ここでCtrl-Cで処理を中断し、ソースコード置き場を開発ドライブ上のディレクトリーに変更して ./mach bootstrap を再実行します。 開発ドライブに切り替えずに作業を継続する場合は、Enterキーを押して先に進みます。

次に、「Would you like to run a few configuration steps to ensure Git is optimally configured? (Yn):」と、GitをFirefoxの開発向けに設定するかどうかを訊ねられます。 MozillaBuildの環境は原則としてFirefoxの開発にしか使用しないので、Enterキーを押して（Yesを選択して）先に進みます。

次に「Will you be submitting commits to Mozilla? (Yn):」と、コミットをMozillaに送信する機会があるかどうかを訊ねられます。 これはMozillaのリポジトリーへの書き込み権限がある開発者（いわゆるコミッター）向けの話なので、権限が無い一般の開発者は n の入力後にEnterキーを押して（Noを選択して）先に進みます。

次に「Would you like to enable build system telemetry? (Yn):」と、ビルドシステムの統計情報の収集に協力するかどうかを訊ねられます。 継続的に使用するビルド環境であれば、Enterキーを押して（Yesを選択して）先に進みます。 実験的なビルド環境であれば、 n の入力後にEnterキーを押して（Noを選択して）先に進みます。

以上でビルドの準備は完了です。 この過程で、ビルドに必要なツール類が ~/.mozbuild 配下へ自動的にインストールされます。 初期設定の過程でMozillaBuildの環境の状態に影響が及んでいる場合があるため、一旦MozillaBuildのコンソールを閉じて、もう一度開き直してから先に進みます。

ビルドの実施

ここまでの準備が終わっていれば、もうビルドを開始できます。 cloneされたリポジトリーに cd して ./mach build を実行すると、ビルド作業が始まります。 初期設定の段階でインストールされなかった依存ツール類や、Artifact Mode用の基盤層のバイナリーは、このビルド過程で必要に応じて ~/.mozbuild 、~/.cargo、~/.rustup などに自動的にダウンロードされます。

$ cd /f/mozilla-source/firefox
$ ./mach build

筆者の検証時には、デスクトップPCではビルド完了までに2分弱、ラップトップPCではビルド完了までに約5分を要しました。 ビルドが無事に成功すると、以下のようなメッセージが最後に出力されます。

...
 4:51.94 Your build was successful!
To take your build for a test drive, run: |mach run|
For more information on what to do now, see https://firefox-source-docs.mozilla.org/setup/contributing_code.html

ここで、./mach runと実行すると、ビルドされたバイナリー（Nightly英語版）を起動できます。 この時、ユーザープロファイルは普段使いのFirefoxの物ではなく、このビルド用の物が使われるので、普段の環境が壊れる心配はありません。

$ ./mach run

ビルドされたNightlyが無事に起動すれば、ここまでの手順は成功です。

インストーラーの作成

自分でビルドしたFirefoxを別のPCで実行したい場合、別のPCに持って行くためのパッケージがある方が便利です。 ./mach package を実行すると、zipアーカイブとインストーラーの実行ファイルが obj-x86_64-pc-windows-msvc\dist に作成されます。

$ ./mach package

この手順で作成したインストーラーは電子署名が付いていないため、他のPCで実行すると警告が表示される点に注意してください。

英語版Nightlyのフルビルドを作成する

Artifact Modeビルドでは、デバッグログ出力を増やそうとして基盤層の部分のソースコードを編集しても、基盤層のビルドはスキップされるため、実際の動作には反映されません。 基盤層まで含めてビルドするには、Artifact Modeを無効化しフルビルドを行う必要があります。 また、後述しますが、ローカライズ版のFirefoxもフルビルドから作成する必要があります。

フルビルドへの切り替え

Artifact Modeからフルビルドに切り替えるには、./mach bootstrap を再実行します。

$ cd /f/mozilla-source/firefox
$ ./mach bootstrap

ビルドの種類を選択する選択肢が表示されたら、今度は 2 を入力してからEnterキーを押します。

Please choose the version of Firefox you want to build (see note above):
  1. Firefox for Desktop Artifact Mode [default]
  2. Firefox for Desktop
  3. GeckoView/Firefox for Android Artifact Mode
  4. GeckoView/Firefox for Android
  5. SpiderMonkey JavaScript engine
Your choice: 2

すると、先程のArtifact Modeの初期化処理では不要だったMicrosoft Visual C++のコンパイラーやWindows SDKなどがインストールされます。

初期設定が完了したら、次に、ビルドオプションの設定が記述されたテキストファイルの mozconfig（F:\mozilla-source\firefox\mozconfig）⁶を編集します。 この時点のmozconfigは、以下のようになっているはずです。

# Automatically download and use compiled C++ components:
ac_add_options --enable-artifact-builds

これはArtifact Modeビルドの初期設定処理が自動生成した物で、この2行目の --enable-artifact-builds がArtifact Modeのスイッチになっています。 フルビルドへ切り替えるために、このオプションの行の先頭に#を追加して、行をコメントアウトします。

# Automatically download and use compiled C++ components:
#ac_add_options --enable-artifact-builds

ビルドの種類を切り替えた後は、リポジトリー内で ./mach clobber を実行し、Artifact Modeでビルドされたファイルを消去しておきます。

ビルドオプションの指定

フルビルドでは、Configuring Build Optionsに列挙されているビルドオプションをすべて使用できます。 ビルドオプションを明示的に指定しなかった場合は、既定値に基づいて「Firefoxを最適化ありでビルドする」動作になり、先のArtifact Modeでのビルドも、この既定値に「Artifact Modeを有効にする」指定が加わった状態でのビルドとなっています。

先に述べたとおり、フルビルドは規定の設定では作業中に大量のRAMを使用します。 中でも特に影響が大きいのが最適化の有無で、最適化ありのフルビルドを行うにはRAMの空きは10GB程度では足りず、20GB程度は必要なようです RAMの搭載量が不足しているPCでフルビルドを行わなくてはならない場合は、 mozconfig に以下の記述を追加して最適化を無効にしてください。

# 最適化を無効化
ac_add_options --disable-optimize

「不具合の原因調査のためにビルドしてみたものの、ビルドオプション無指定の独自ビルドだと現象が再現しない」という場合、ビルドオプションの違いが影響している可能性があります。 なるべく公式のビルドに近い状態にしたい場合は、最適化を有効にした（先の最適化無効のオプションを記述しない）状態で以下のオプションも追加します。

ac_add_options --enable-js-shell
ac_add_options --enable-rust-simd

こういった特別な事情が無いのであれば、検証・調査目的のビルドに関しては、ビルドオプションは無指定で問題ありません。

フルビルドの実施

ビルドの開始手順はArtifact Modeと同様です。 リポジトリーに cd して ./mach build を実行すると、ビルド作業が始まります。

$ cd /f/mozilla-source/firefox
$ ./mach build

Artifact Modeのビルドに比べると、フルビルドは時間がかかります。 筆者の検証時には、デスクトップPCでは最適化ありでビルド完了までに約1時間、ラップトップPCでは最適化無しでもビルド完了までに3時間40分を要しました。

ビルドが完了したら、./mach run を実行して、Nightlyが無事に起動することを確認します。

フルビルドの場合も、./mach package でインストーラーやzipファイルを作成できます。 ビルドの後に続けてインストーラー作成まで終わらせたい場合は、以下のようにします。

$ ./mach build && ./mach package

日本語版Firefox ESR140のフルビルドを作成する

Nightlyのフルビルドがうまくいったら、次はFirefox ESR140をビルドしてみます。 ここでは、Firefox ESR140運用中のトラブルの原因調査のために、顧客環境で試してもらいやすい形式の「日本語版のFirefox ESR140の独自ビルドのインストーラー」を作成する手順を示します。

英語版以外の言語リソースを伴った状態のFirefoxのビルド手順は、Localized Buildsに記載があります。 以下は、筆者の環境での検証結果に基づいて補足を加えた説明となります。

Firefox ESR用ブランチへの切り替え

前述したとおり、ブートストラップスクリプトでcloneされたFirefoxのGitリポジトリーは、NightlyだけでなくESRのブランチも含んでいます。 リポジトリーに cd して git switch esr140 とすれば、ESR140のブランチに切り替えることができます。 すでにNightlyをビルドした後でブランチを切り替えたら、./mach clobber を実行して、ビルド済みのファイルが無いクリーンな状態に戻すのを忘れないようにしましょう。

$ cd /f/mozilla-source/firefox
$ git switch esr140
$ ./mach clobber

Firefoxのリポジトリーは巨大なため、ブランチの切り替えだけでもそれなりの時間を要することに注意してください。 筆者はNightlyへの障害報告とESR版を用いた調査の両方を行う都合上、両者のブランチを都度切り替えていると時間がかかり過ぎるため、ローカルリポジトリー自体を2つ用意して、それぞれをmainブランチとesr140ブランチとして運用しています。

ブランチのHEADは、次のリリースに向けての作業が進行している状態になっています。 Firefox ESR140.6.0のように特定のバージョンをビルドするには、タグに基づいてそのリビジョンに切り替える必要があります。 Firefox ESR140のリリース版のリビジョンのタグを列挙するなら、以下の要領です。

$ git tags --list | grep -E "FIREFOX_140.+esr_RELEASE"
FIREFOX_140_0esr_RELEASE
FIREFOX_140_1_0esr_RELEASE
FIREFOX_140_2_0esr_RELEASE
FIREFOX_140_3_0esr_RELEASE
FIREFOX_140_4_0esr_RELEASE
FIREFOX_140_5_0esr_RELEASE
FIREFOX_140_6_0esr_RELEASE

今回はFirefox 140.6.0をビルドするため、タグ名は FIREFOX_140_6_0esr_RELEASE です。 git checkout でタグ名を指定し、このリビジョンに切り替えます。

$ git checkout FIREFOX_140_6_0esr_RELEASE

Firefox ESR140のフルビルド

ビルドしようとしているESR版よりも新しいバージョンのFirefoxをビルドしたことがある環境では、ツールセットの新しいバージョンがあるせいで、古いバージョンのツールセットを要求するESR版をビルドできない場合があります。 筆者の場合は ~/.mozbuild/ にキャッシュされた windows-rs が新しすぎることが原因でESR140をビルドできませんでした。

1つのビルド環境上で、以前にビルドしたバージョンとは離れたバージョンのFirefoxをビルドするときは、安全のため、rm -rf ~/.mozbuild/* ~/.cargo/* ~/.rustup/* のようにして自動インストールされたツールセットを削除し、./mach bootstrap を再実行して（この時、ビルドの種類はArtifact Modeの 1 ではなく、通常ビルドの 2 を選択することを忘れないでください）、ESR140のビルド環境を改めて整え直しておいてください。

$ rm -rf ~/.mozbuild/* ~/.cargo/* ~/.rustup/*
$ cd /f/mozilla-source/firefox
$ ./mach bootstrap

初期設定が完了したら、Firefox ESR140をフルビルドします。 ./mach build と ./mach package を実行して、英語版のインストーラーおよびその構成ファイル類を作成します。

$ ./mach build && ./mach package

日本語化とインストーラーの作成

英語版インストーラーの作成まで終わったら、./mach build installers-ja を実行します⁷。 すると、ビルドシステムが言語リソースのリポジトリーを自動的にcloneし、適切なリビジョンをチェックアウトして、ビルド済みの英語版インストーラーの構成ファイルと組み合わせて日本語版Firefox ESR140のインストーラーを作成してくれます。 作成されたインストーラーは obj-x86_64-pc-windows-msvc\dist に置かれます。

$ cd /f/mozilla-source/firefox
$ ./mach installers-ja

先に紹介したLocalized Buildsの手順では、ローカライズ済みインストーラーは ./mach build installers-(言語コード)_(地域コード) で作成するように書かれていますが、日本語のロケールは現在のバージョンのFirefoxでは、地域コードを含まない ja を指定する必要があります。 ./mach build installers-ja_JP とした場合、該当するロケールが存在しないため、実際にできあがるのは英語版のインストーラーとなります。

トラブルシューティング

コードに変更を加えた後に、ビルドが失敗するようになった場合

一度ビルドした後で、コードに変更を加えたりビルド設定を変えたりしてから再度 ./mach build を実行したときに、エラーでビルドが止まることが度々あります。

このような場合の原因は様々な物が考えられるのですが、筆者の経験上は、前回のビルド結果が半端に影響を与えてビルドの妨げになっている場合が多いようです。 ./mach clobberを実行して、前回のビルドで作られた作業ファイルなどを消去すると、もう一度まっさらな状態からのビルドし直しとなり、詰まりが解消される事が多いです。

$ ./mach clobber

ビルド対象のブランチを切り替えた後に、ビルドが失敗するようになった場合

前述しましたが、「ビルド対象のブランチをNightlyからESRに切り替えた」というようにビルド対象のFirefoxのバージョンが大きく変わった場合は、ツールセットのバージョンが合わないことがビルド失敗の原因になり得ます。 このような場合は安全のため、自動インストールされたツールセットを削除し、./mach bootstrap を再実行してから再ビルドしてください。

$ rm -rf ~/.mozbuild/* ~/.cargo/* ~/.rustup/*
$ ./mach bootstrap

~/.mozbuild の中にあるファイルが使用中であると表示されてフォルダーを削除できない場合、watchman というファイル監視ツールのプロセスが原因となっていることがあります。 Ctrl-Shift-Escでタスクマネージャーを起動して、「詳細」から watchman.exe という項目（カラムを追加してファイルのフルパスを見ると、上記のフォルダー配下にあることが分かります）を探して強制終了すると、ロックが解除されフォルダーを削除できるようになります。

以前にMozillaBuildでFirefoxをビルドしたことがある環境で、ビルドが失敗する場合

ブランチを切り替えた場合以外にも、過去にFirefox ESR128をビルドした環境でFirefox ESR140をビルドするといった具合に、ビルド対象のFirefoxのバージョンが大きく変わると、ツールセットのバージョンが合わないためにビルドが失敗する可能性があります。 このような場合も、前項と同様に自動インストールされたツールセットを削除し、./mach bootstrap を再実行してからビルドしてください。

まとめ

以上、Windows版Firefox Nightlyの英語版およびFirefox ESR140日本語版を調査・検証目的でビルドするための手順の2026年1月時点での状況を解説しました。

かつてはMozillaBuildを用いてもなお色々な手順が必要だったFirefoxのビルドですが、今ではかなり自動化の整備が進み、本稿執筆時点ではもうほとんど手作業は不要となっています。 ちょっとしたパッチの検証やデバッグログを用いた詳細な動作の調査などであればスムーズに始められ、Firefoxの開発自体に参加するハードルも大きく引き下げられていると言えます。 JavaScriptでの開発を日常的に行っている方は、これを切り口として、GUIをWeb技術で実装したブラウザーであるFirefoxのソースを読んでいじって壊してみて、普段は縁遠く感じている「デスクトップアプリの内側」に踏み込んでみてはいかがでしょうか？

株式会社クリアコードは、FirefoxやThunderbirdの法人運用において生じた様々な問題について、ソースコードレベルの調査も含めたサポートを行うサービスを有償でご提供しています。 FirefoxやThunderbirdの運用で何かお困りの企業の運用担当者さまは、お問い合わせフォームよりお問い合わせ下さい。

ツイートする

フォローする