Chrome が2週間ごとのリリースへ - Chrome 153 からの新サイクルと Web 開発・QA・企業IT への影響

Google Chrome のメジャーバージョンが、2週間に1回出るようになりました。2026年9月8日に Stable 版となった Chrome 153 から、Stable と Beta のリリース間隔がそれまでの4週間から2週間へ短縮されています。続く Chrome 154 も2週間後の9月22日に Stable へ昇格しました。

この記事では、Chrome for Developers ブログの公式アナウンス、Chromium Dashboard のスケジュール、Chrome Enterprise のヘルプを一次ソースに、何が変わったのか、なぜ変えたのか、Web 開発者・QA・企業の IT 管理者は何をすればよいのかを整理します。

NOTE

本記事は2026年9月26日時点の情報です。Chrome 155 以降の日付は Chromium Dashboard 上の予定であり、ビルド状況などにより変わる可能性があります。

何が変わったのか（要点）

公式アナウンスと企業向けヘルプから読み取れる要点は次のとおりです。

Stable と Beta が2週間サイクルに。Chrome 153（2026年9月8日）から適用。デスクトップ、Android、iOS のすべてが対象
Dev と Canary は変更なし
Extended Stable は8週間サイクルを維持。Chrome 152 の次は Chrome 156、その次は Chrome 160 と、4つおきのマイルストーンを採用する
Extended Stable には週次でセキュリティ修正が提供される
Beta は Stable の約3週間前に出る（Chromium Dashboard の予定日から確認）

1回あたりのリリースに含まれる変更は小さくなり、そのぶん回数が倍になる、というのが基本的な構図です。

変更の経緯と公式の理由

2021年: 6週間から4週間へ

Chrome は2021年3月4日の Chromium ブログで、Chrome 94（2021年第3四半期）から4週間ごとのマイルストーンへ移行すると発表しました。このとき同時に、企業管理者や Chromium を組み込む製品向けに、8週間ごとにマイルストーンが更新される Extended Stable が新設されています。当時の発表では、Extended Stable のセキュリティ更新は2週間ごととされていました（現在の企業向けヘルプでは週次）。

2026年: 4週間から2週間へ

今回の2週間化は、2026年3月3日公開の Chrome for Developers ブログ「Get features faster with Chrome's two-week release cycle」で予告され、2026年9月8日の「Fresher features, faster fixes: The two-week release cycle is here」で開始が告知されました。

公式が挙げている理由は、大きく2つです。

新機能・修正をより早く届けるため。公式ブログは、開発者とユーザーが最新のパフォーマンス改善、修正、新機能にすぐアクセスできるようにすることを目的に挙げています。また、1回のリリースの範囲が小さくなることで、影響を抑えつつリリース後の不具合調査もしやすくなるとしています
セキュリティ修正の「N-day」期間を縮めるため。AI による自動的な脆弱性発見ツールやコミュニティからの報告でパッチの量が増えるなか、リリースサイクルを短くすることでセキュリティ修正の管理が容易になり、公開コードベースに修正が入ってからユーザーに届くまでの時間を短く保てる、という説明です

なお公式ブログは、Chrome が2023年から週次のセキュリティ更新を始めている点にも触れています。つまり「セキュリティ修正だけなら以前から週1回届いていたが、機能を含むマイルストーン単位の更新も2週間に詰める」という変更です。

スケジュール（Chrome 152 から Chrome 160）

Chromium Dashboard のスケジュール（chromiumdash.appspot.com/schedule）から、Beta の最早公開日、Early Stable、Stable の日付を抜き出すと次のとおりです。Chrome 153 と 154 は Stable 公開済み、155 以降は予定です。

バージョン	Beta（最早）	Early Stable	Stable	備考
Chrome 152	2026-07-29	2026-08-12	2026-08-25	4週間サイクル最後の版。Extended Stable 対象
Chrome 153	2026-08-19	2026-08-26	2026-09-08	2週間サイクルの初回
Chrome 154	2026-09-02	2026-09-09	2026-09-22	9月22日に Stable 昇格を確認
Chrome 155	2026-09-16	2026-09-23	2026-10-06	予定
Chrome 156	2026-09-30	2026-10-07	2026-10-20	予定。Extended Stable 対象
Chrome 157	2026-10-14	2026-10-21	2026-11-03	予定
Chrome 158	2026-10-28	2026-11-04	2026-11-17	予定
Chrome 159	2026-11-11	2026-11-18	2026-12-08	予定。前の版から3週間
Chrome 160	2026-12-02	2026-12-09	2027-01-05	予定。年末年始を挟み4週間。Extended Stable 対象

表から分かるとおり、年末年始のように間隔が2週間より空く時期もあります。「常にきっちり2週間」ではなく、日付はダッシュボードで都度確認するのが確実です。

Chrome 154 の Stable 昇格は、Chrome Releases ブログの「Stable Channel Update for Desktop」（2026年9月22日）で確認できます。この更新には108件のセキュリティ修正が含まれていると記載されています。

チャネルごとの違い

チャネル	更新間隔	主な用途
Canary	変更なし	最先端のビルドで早期に検証
Dev	変更なし	開発中の機能を試す
Beta	2週間ごと（Stable の約3週間前）	次期 Stable 相当での互換性確認
Stable	2週間ごと	一般ユーザー向け
Extended Stable	8週間ごと（週次でセキュリティ修正）	企業や Chromium 組み込み製品向け

企業向けヘルプの説明によると、各マイルストーンの最初の2週間は Stable と Extended Stable が同じ内容で、残りの6週間は Extended Stable 側にセキュリティ修正のみが週次で入ります。例として、Extended Stable が Chrome 152 に8週間とどまる間に Stable は 153、154、155 と進み、Chrome 156 で両者が再び揃う、という図が示されています。

Edge など Chromium 系ブラウザへの波及

Microsoft Edge は Chrome より先に2週間サイクルへ移行しています。Microsoft Learn の「Microsoft Edge release schedule」には、Stable チャネルのバージョン152から2週間のメジャーリリースサイクルに移行し、管理された環境向けに8週間サイクルの Extended Stable を用意すると明記されています。

Edge 152: Stable 2026-08-27（Extended Stable も同日）
Edge 153: Stable 2026-09-11
Edge 154: Stable 2026-09-24 の週（予定）
Edge 156: Stable と Extended Stable がともに 2026-10-22 の週（予定）

同ページには「Beta と Stable のメジャーリリースのトリガーは、対応する Chromium のリリースである」とも書かれており、Edge の番号は Chrome と同じマイルストーン番号で数日遅れて追従する形です。

Chrome の開始告知ブログでは、Edge のほかに Firefox や Brave も短いリリースサイクルを採用していると触れていますが、Firefox と Brave については本記事では各プロジェクトの一次ソースを確認していません（未確認）。そのほかの Chromium 系ブラウザ（Vivaldi、Opera など）の対応も未確認です。

Web 開発者への影響

新機能が Stable に届くペースが上がる

公式の開始告知は、Web 開発者向けの変化を「機能が2週間ごとに Stable に届き、1回あたりの範囲が小さくなるため、回帰の切り分けが速くなる」とまとめています。新しい CSS や Web API が Chrome Stable に載るタイミングが細かく刻まれるため、「次の Chrome で使えるようになる」機能の追跡頻度も上がります。

たとえば CSS 2026 のブラウザネイティブ機能や View Transitions API のように段階的に機能が拡張されていく分野では、Chrome のどのバージョンで何が入ったかを確認する機会が増えます。公式ブログは、Chrome Status の Roadmap（chromestatus.com/roadmap）をブックマークし、Chrome Beta でサイトをテストすることを推奨しています。

機能フラグと Origin Trial

2週間化にあわせて、機能フラグの運用や Origin Trial の仕組み、Blink の Intent to Ship などのプロセスが変わるかどうかは、今回確認した公式アナウンスには記載がありませんでした（未確認）。

注意したいのは、Origin Trial の期間などをマイルストーン番号で把握している場合です。同じ「3マイルストーン」でも、4週間サイクルなら約12週間、2週間サイクルなら約6週間と、実時間が半分になります。実際に各トライアルの期間がどう設定されるかは個別の Chrome Status のエントリで確認してください（ここは本記事の推測を含みます）。

Baseline と Browserslist

Web Baseline の考え方は、主要ブラウザ（コアブラウザセット）すべてで使えるようになった時点を起点にしています。Browserslist の README でも、baseline widely available は「コアブラウザセットで少なくとも30か月相互運用可能になっている機能」と説明されています。この定義は月数ベースなので、Chrome 単体のリリース間隔が変わっても判定の考え方自体は変わりません。

一方、バージョン数で指定するクエリは影響を受けます。Browserslist の last 2 Chrome versions は「Chrome の直近2バージョン」を意味するため、4週間サイクルでは約8週間分をカバーしていたものが、2週間サイクルでは約4週間分になります。

last 2 versions のようなバージョン数ベースの指定は、カバー期間が短くなる
期間やシェア、Baseline ベースの指定（baseline widely available など）は、リリース間隔の影響を受けにくい

社内のブラウザサポートポリシーを「最新2バージョン」で書いている場合は、実時間でどの程度の範囲を想定しているのかを見直すきっかけになります。

QA・テストへの影響

Playwright などの E2E テスト

Playwright のドキュメントには、Playwright の各バージョンは特定のバージョンのブラウザバイナリを必要とし、リリースごとにサポートするブラウザのバージョンを更新すると書かれています。また、ブランド版の Google Chrome や Microsoft Edge を channel 指定で使う場合、現行の Playwright はこれらの Stable と Beta チャネルをサポートするとしています。

Chrome のメジャー更新が2週間ごとになることで、Playwright 同梱の Chromium と、ユーザーが実際に使っている Chrome Stable とのバージョン差が開きやすくなる可能性があります（Playwright 側のリリース頻度との兼ね合いで、ここは推測です）。対策としては次のような構成が考えられます。

通常の CI は Playwright 同梱の Chromium で安定して回す
定期ジョブで channel: 'chrome' と channel: 'chrome-beta' のプロジェクトを追加し、実ブラウザの Stable と次期 Beta でも回す
Playwright 本体の更新を依存関係の自動更新（Renovate や Dependabot など）で追従しやすくしておく

テスト基盤の組み方は Vitest と Playwright のモダンテスト入門でも整理しています。

回帰の切り分け

1回あたりの変更が小さくなるのは、切り分けの面では利点です。どの Chrome バージョンから挙動が変わったのかを特定できれば、そのリリースに含まれる変更は以前より少ないはずです。逆に言えば、バグ報告やログにChrome のフルバージョン番号を必ず残す運用がより重要になります。

企業 IT への影響

企業向けヘルプ（Chrome Enterprise のサポートページ）は、2週間サイクルに追従できない組織向けの選択肢として Extended Stable を案内しています。ポイントは次のとおりです。

チャネルは TargetChannel ポリシーで管理できる
Windows には Extended Stable 用の MSI インストーラがあり、Mac は PKG / DMG で配布される
全台に展開する前に、少数の端末で Extended Stable を試すことを Google は推奨している
セキュリティ面では、複雑な変更やセキュリティを高める大きな機能は Stable チャネルにしか入らない場合があり、2週間サイクルの Stable が最も安全な選択肢とされている

つまり「更新の手間を減らしたいから Extended Stable」という判断は、セキュリティ面での小さくないトレードオフを伴います。Edge も同様に Extended Stable を用意しているため、Chrome と Edge を併用している組織では、両方のチャネル方針を揃えて検討するのが現実的です。

実務での対応チェックリスト

Web 開発・QA:

Chromium Dashboard と Chrome Status Roadmap をブックマークし、Stable 日付を都度確認する
Chrome Beta（または channel: 'chrome-beta'）でのテストを定期ジョブに組み込む
バグ報告テンプレートやエラーログに Chrome のフルバージョンを含める
Browserslist の last N versions 系の指定が、実時間でどの範囲を想定しているか見直す
Origin Trial を使っている場合、終了マイルストーンの日付をダッシュボードで換算し直す
Playwright など E2E ツールの更新を自動化し、同梱ブラウザのバージョン差を把握する

企業 IT:

Stable（2週間）と Extended Stable（8週間）のどちらを標準にするか、セキュリティとのトレードオフを踏まえて決める
TargetChannel ポリシーでチャネルを明示的に管理する
業務アプリの検証を、パイロット端末グループで Beta または Early Stable の段階から回す
Edge を併用している場合、Edge 側のチャネル方針（Edge 152 から2週間化済み）も揃えて見直す

まとめ

Chrome は Chrome 153（2026年9月8日）から、Stable と Beta のメジャーリリースを2週間ごとに切り替えた
Dev と Canary は変更なし。Extended Stable は8週間サイクル（152、156、160）を維持し、週次でセキュリティ修正が入る
公式の理由は、新機能と修正を早く届けることと、セキュリティ修正の N-day 期間を縮めること
Edge は Edge 152（2026年8月27日）から先行して2週間サイクルへ移行済み
Web 開発者は Beta でのテスト、バージョン数ベースのサポート指定の見直し、バージョン番号の記録を習慣にしたい

リリースの粒度が細かくなったぶん、1回ごとの変化は小さくなります。新しいブラウザ機能の追い方については、Chrome の Declarative Partial Updates のように、実験フラグの段階から追いかけた記事もあわせて参考にしてください。

Chrome が2週間ごとのリリースへ - Chrome 153 からの新サイクルと Web 開発・QA・企業IT への影響

何が変わったのか（要点）