Firefox、9月からメジャー更新を2週間ごとに：155で実験開始

Mozillaは、Firefoxのデスクトップ版とAndroid版について、メジャーリリースの間隔を現在の4週間から2週間へ短縮する実験を2026年9月に始める。最初の対象となるFirefox 155は、従来予定の9月15日から9月1日へ2週間前倒しされる。2020年から続いた4週間周期を半分にする節目だ。

ただし、開発期間そのものを半分にする計画ではない。Mozillaは、完成していない機能を急いで出さず、必要な検証時間を取ると明記した。変わるのは、準備が整った変更を安定版へ運ぶ「列車」の本数である。公開機会を増やしながら品質を保てるかを測り、結果に応じて日程を調整する。

9月1日のFirefox 155から隔週へ

Mozillaの公開リリースカレンダーには、移行前後の日付がすでに反映されている。Firefox 153から154までは28日空くが、154から155は14日だ。その後も少なくともFirefox 160まで、隔週の火曜日に安定版を出す予定である。

Firefox 155の当初予定日は9月15日だった。したがって今回の変更は、将来の番号を増やしたという話ではなく、すでに組まれていた公開日を前へ動かすものだ。Mozillaのリリース管理責任者Sylvestre Ledruは、この取り組みを「実験」と説明している。準備済みの変更をユーザーへ届ける機会を増やし、公開日程を予測しやすくするとともに、通常の経路を外れて修正を前倒しする「アップリフト」への圧力を減らすことが狙いである。

対象として明記されたのはデスクトップ版とAndroid版だ。iOS版は告知に含まれていない。また、2週間周期をいつまで続けるか、どの指標で継続を判断するかも公表されていない。Firefox 155は恒久移行の初回ではなく、運用データを集める起点になる。

週次の小更新と隔週のメジャー更新

Firefoxには、今回の実験に先立って週次の更新機会が設けられている。MozillaはFirefox 151から、デスクトップ版とAndroid版に週次の「ドットリリース」を組み込んだ。メジャー版を出した翌週以降に、承認済みの修正やアップリフトを届ける機会を毎週設ける運用である。

ドットリリースは、準備できた変更がある場合にリリース管理側が実施する。必要がなければ見送れる。一方、Firefox 155以降の隔週日程は、NightlyからBeta、安定版へコードを進めるメジャー版の定期便を増やす。修正を例外的に現在の版へ移すよりも、次の版を待つ方が短くなるため、アップリフトの判断を減らしやすい。

公開範囲を段階的に広げる仕組みも残る。MozillaはFirefox 152から、メジャー版を初日に安定版ユーザーの25％へ配り、その状態を2日間維持してから、問題がなければ100％へ広げる方式に改めた。更新周期を短くしても、初期の利用状況や安定性を確かめる時間は確保する設計だ。

4週間分の変更を2本のリリースへ分ければ、1回あたりの変更量は平均的には小さくなる。ただし、各機能の完成日は揃わない。大きな機能が複数の周期をまたぐこともある。ユーザーが受け取るのは「半分の時間で作ったFirefox」ではなく、完成した変更を載せる機会が増えたFirefoxである。

Edge、Firefox、Chromeが12日間に集中

2026年秋には、Microsoft Edge、Firefox、Google Chromeの安定版が相次いで2週間周期へ移る。Edgeが8月27日、Firefoxが9月1日、Chromeが9月8日に新日程を始める。最初の移行が12日間に集中し、3製品のリリース日程がほぼ同時に変わる。

Googleは、Chrome 153からBetaとStableを2週間ごとに出す。対象はデスクトップ、Android、iOSで、DevとCanaryは変更しない。企業向けExtended Stableも8週間周期を維持する。MicrosoftもEdge 152からStableを隔週にするが、Extended Stableは4回に1回のメジャー版を受け取り、8週間の間隔を保つ。

3社に共通するのは、消費者向け安定版の列車を増やしながら、管理された端末には遅い経路を残す考え方だ。相違点は対象範囲にある。ChromeはiOSを含む全プラットフォームを明記したのに対し、Firefoxの告知はデスクトップとAndroidに限られる。Firefox ESRについても、今回の告知本文は運用変更を説明していない。

企業はESRと公開カレンダーを分けて読む

Firefoxを組織で配布する管理者には、更新の「回数」と「内容」を分けて見る必要がある。通常版はメジャー版ごとに新機能やUI変更、プライバシー・セキュリティの挙動変更を取り込む。そのため、社内Webアプリや拡張機能との互換性を確かめる機会も4週間ごとから2週間ごとへ増える。Betaを使う先行検証グループの価値は、これまでより高まる。

ESRは別の設計だ。Mozillaの管理者向け文書では、新しいESRの基礎版を年1回公開し、その間のポイント版には主にセキュリティ更新を載せる。UIや機能の変更は次の年次ESRまで入らない。このため、安定した画面や挙動を優先する組織が、通常版と同じ頻度で機能検証を繰り返す必要はない。

一方、更新直後の公式文書には過渡期が見える。7月10日時点の管理者向けページは、通常版を「4週間ごと」と説明したままだ。ところが公開カレンダーでは、Firefox 155と同じ9月1日にESR 153.2、9月15日に153.3、9月29日に153.4を並べている。少なくとも現在の日程では、ESRの機能投入は年1回のまま、セキュリティを中心とするポイント版の機会が2週間ごとに置かれる。

この差は、告知から移行までに管理文書を更新する必要があることを示している。現行文書では、新旧ESRを3リリース周期、最低12週間にわたって並行サポートする。2週間周期になっても最低12週間を維持するのか、周期数を数え直すのかは今回の告知にない。ポイント版の配布方針や企業向け検証手順と合わせて、Mozillaの更新を待つ必要がある。

Mozillaは実験を監視して必要なら調整するとしている。Firefox 155以降も隔週日程が維持され、安定性を損なわずに例外的なアップリフトを減らせるか。9月からの数回のリリースが、その判断材料になる。