【NEW TOOL】Chrome の更新が2週間ごとに — 「動いているから触らない」が終わる

Google は 2026 年 9 月 8 日の Chrome 153 公開をもって、メジャー更新の間隔を 4 週間から 2 週間へ短縮した。対象はデスクトップ、Android、iOS の各版で、企業向けの Extended Stable だけが 8 週間の間隔を維持する。業務システムの実行環境がブラウザに寄った会社にとって、これは情シスの作業カレンダーの話ではなく、検証と展開のサイクルが更新の速度に追いつくかという経営の設計問題になる。

何が変わったか — 4 週間から 2 週間へ

Google が今回の変更を予告したのは 2026 年 3 月で、実施は Chrome 153 の安定版リリースからと明示されていた。予告どおり 9 月 8 日に切り替わり、デスクトップ、Android、iOS が同時に新しい間隔へ移った。Dev と Canary の各チャンネルは今回の変更の対象外とされている。

変わらない部分もある。Google が 2023 年から続けている週次のセキュリティ更新は継続する。そしてエンタープライズ管理者や Chromium を組み込んで製品を作る事業者に向けた Extended Stable は、これまでどおり 8 週間の間隔で提供される。管理下の端末に配る仕組みについては、Google 自身が「新しいブラウザのサイクルに合わせて調整中で、詳細は追って共有する」と述べている段階にある。

つまり選択肢は二つに整理された。速く受け取って攻撃可能な期間を短くするか、遅く受け取って検証の時間を確保するか。Google は前者を推奨する立場だが、どちらを選ぶかは各社の運用体制に依存する。

なぜ速くするのか — 「直っているのに配れていない期間」

理由として挙げられているのは N-day の縮小である。脆弱性が公になってから修正が実際に端末へ届くまでの間隔を指す言葉で、この間は「修正は存在するのに、自分の端末はまだ穴が開いたまま」という状態が続く。攻撃者は公開された修正内容を読んで攻撃手法を組み立てられるため、この期間は防御側にとって一方的に不利な時間になる。

AI ツールによる自動的な脆弱性探索と、コミュニティからの報告が増えたことで、修正すべき件数そのものが増えた。件数が増えたまま配布の間隔が変わらなければ、一回の更新に詰め込まれる修正が膨らみ、待たされる時間も長くなる。間隔を半分にすれば一回あたりの変更の幅が小さくなり、不具合が出たときの切り分けも軽くなる、というのが Google の説明である。

この加速は今回が初めてではない。Chrome は 2021 年に 6 週間から 4 週間へ移しており、今回はその二段目にあたる。そして Mozilla、Microsoft、Brave も同様の間隔へ移行している。ブラウザ業界全体が同じ方向へ動いていると見てよい。

日本企業への含意 — 検証カレンダーが破綻する会社が出る

影響が出るのは、社内の業務アプリを Chrome 上で動かしていて、かつ更新のたびに動作確認をしている会社である。基幹システムの Web 画面、勤怠、経費精算、受発注、いずれもブラウザが実行環境になっている。これまで 4 週間の間隔を前提に検証チームの工数を組んでいたなら、同じやり方では単純に倍の負荷がかかる。

ここで多くの現場が取る対応は「検証を薄くする」か「更新を止める」のどちらかになりやすい。だが更新を止める判断は、N-day を自社で意図的に伸ばす判断と同じである。Extended Stable の 8 週間はその選択を公式に用意した受け皿だが、これも「遅く受け取る代わりに、脆弱性に晒される期間を長く許容する」という取引であることは変わらない。無償で時間が手に入るわけではない。

現実的な落としどころは、全部を毎回検証するのをやめ、業務が止まると困る画面を絞って自動で確認する形へ寄せることだろう。手作業の回帰テストを 2 週間ごとに回せる会社はほとんどない。逆に言えば、この変更は「どの業務画面が止まると事業が止まるか」を経営として一度も定義していない会社に、その定義を迫る出来事でもある。

SYNCON の視点 — ブラウザは設備であって、備品ではない

多くの会社でブラウザは「入っているもの」であって、管理対象として名前が挙がることは少ない。だが業務アプリの大半がブラウザ上で動くようになった以上、これは机や椅子のような備品ではなく、工場の生産設備に近い。設備であれば、点検の頻度と停止時のリスクを経営が把握しているはずだ。ブラウザについて同じ問いに答えられる会社は多くない。

今回の変更が突きつけているのは、更新の速度そのものではなく、自社の検証能力の上限である。間隔が倍になったときに回らなくなるなら、それは元々ぎりぎりだったということで、次に何かが速くなったときも同じことが起きる。来週の経営会議で問うべきは「Chrome の更新にどう対応するか」ではなく、「ブラウザ更新で業務が止まったとき、それに気づくまでに何時間かかる体制になっているか」ではないか。

要点まとめ

• Chrome のメジャー更新間隔が 4 週間から 2 週間へ短縮された。開始は Chrome 153、デスクトップ・Android・iOS が対象
• 企業向けの Extended Stable は 8 週間の間隔を維持。週次のセキュリティ更新も継続する
• 狙いは N-day、つまり脆弱性の公開から修正が届くまでの間隔を詰めること
• AI による自動探索で修正件数が増え、従来の間隔では一回の更新が重くなりすぎていた
• Chrome は 2021 年に 6 週間から 4 週間へ移しており、今回が二度目の加速。Mozilla、Microsoft、Brave も同じ間隔へ動いている
• 経営が決めるべきは、検証工数を増やすか、対象を絞って自動化するか、Extended Stable で時間を買うかの選択

情報ソース:
・TechCrunch「Chrome is now shipping updates every 2 weeks as AI changes the security landscape」(2026 年 9 月 8 日)
・Chrome for Developers Blog「Get features faster with Chrome’s two-week release cycle」
・SecurityWeek「Google Plans Two-Week Release Schedule for Chrome」(2026 年 3 月 4 日)