Chromeは153から、安定版が2週間ごとに出る。年末年始だけ間隔がのびる予定 ── 表示確認・計測・納品後の確認の予定を組み直して確認する13項目（2026年10月時点）

01 何が起きたか — Chromeは2026年9月8日のChrome 153から、安定版が2週間ごとに出る

公式ブログの告知

Chrome for Developersのブログに、2026年9月8日の日付で、「Fresher features, faster fixes: The two-week release cycle is here」（訳: より新しい機能、より速い修正：2週間のリリースの周期が始まった）という記事が載っている。2026年10月6日に、この記事を開いて読んだ。書き出しの1文は、次のとおりである。

"Earlier this year, we announced our plan to shift Chrome from a four- to a two-week release cycle with the goal of delivering new features, performance improvements, and bug fixes faster."

（訳: 今年の初めに、私たちはChromeのリリースの周期を4週間から2週間に変える計画を発表した。目的は、新機能、性能の改善、不具合の修正を、より速く届けることである。）

記事は、この計画を、デスクトップ・Android・iOSのChrome 153の公開と同じ日に実行に移した、と書いている。ここでいう「リリースの周期」は、安定版（多くの利用者が使う版）が新しく出る間隔のことである。

表に書かれた、立場ごとの変わる点

記事には、何が変わるかを、ウェブ開発者・利用者・企業の管理者の3つの立場に分けた表がある。ウェブ開発者の行は、次のとおりである。

"Features reach Stable every two weeks. Scope per release is smaller, making regression isolation faster."

（訳: 機能は2週間ごとに安定版に届く。1回あたりの範囲は小さくなり、不具合の原因の切り分けが速くなる。）

この2文には、2つの内容がある。1つは、機能が安定版に届く間隔が2週間になること。もう1つは、1回の範囲が小さくなるので、不具合が出たときに、どの変更が原因かを切り分けやすくなることである。後者は、公式ブログが述べている利点であって、サイトの確認が楽になるという意味ではない。確認する回数は、増える側に動く（02章で数える）。

企業向けのExtended Stableは残る

企業の管理者の行には、次の1文がある。

"The Extended Stable channel is available for customers who cannot accommodate a two-week release cycle."

（訳: Extended Stableのチャンネルは、2週間のリリースの周期に対応できない顧客向けに用意されている。）

同じ記事の注意書きは、Extended Stableを使う組織について、セキュリティの修正は毎週の予定で取り込まれ続けるが、大きな機能の更新は8週間ごとに届くと書き、例としてChrome 156とChrome 160を挙げている。続けて、テストの手順について、次の1文を置いている。

"Ensure your test pipelines account for these eight-week milestone boundaries when planning enterprise deployments."

（訳: 企業への展開を計画するときは、テストの手順が、この8週間ごとの区切りを考慮に入れているかを確かめること。）

取引先に、端末の更新を管理している会社があれば、その会社の利用者が見ているChromeの版は、2週間ごとの安定版より古いままのことがある。

154と155の日付

ブログは、公開した9月8日の時点で、Chrome 154のベータはすでに試せると書き、154の安定版は9月22日の予定だと書いている。154のリリースノートは、公開日を次のように書いている。

"Stable release date: September 22nd, 2026"

（訳: 安定版の公開日：2026年9月22日）

155については、2026年9月16日付のベータの記事に、次の1文がある。

"Chrome 155 is in beta as of September 16, 2026."

（訳: Chrome 155は、2026年9月16日からベータになっている。）

Chrome Platform Statusの155のページは、「Scheduled Stable Release October 6, 2026」（訳: 安定版の公開は、2026年10月6日の予定）と表示していて、状態は「Preview」だった。取得した2026年10月6日の午前に、developer.chrome.comの「New in Chrome 155」の記事と、155のリリースノートのページは、どちらも見つからなかった（404）。一方、chromestatus.comの155のページは取得でき（200）、上の表示は、そのページのものである。この記事は、155について「安定版が出た」とは書かず、10月6日の予定と書く。くわしくは07章に書いた。

02 なぜ・背景 — 版の数は2倍になり、1つの版の中身は小さくなる

公式ブログが挙げた理由

記事は、2週間にする理由を、主に3つ書いている。1つ目は、新しい機能、性能の改善、不具合の修正を、より早く届けること。2つ目は、セキュリティである。記事は、AIによる自動の発見ツールと、コミュニティからの不具合の報告で、直すべき件数が増えていて、周期が短いほど、修正の管理が簡単になると書いている。修正が公開のコードに入ってから、利用者の手元に届くまでの間を短くすることで、修正が出たあとの空白の時間（「N-day」と呼ばれる）を小さくする、という説明である。3つ目は、同じ方向に進んでいる他の組織で、記事は、Microsoft、Mozilla、Braveの3つを挙げている。

28日から14日へ ── 日付で並べると、変わった場所が見える

Chromiumの公開ダッシュボード（Chromium Dashboard）には、版ごとのスケジュールを返す仕組みがある。2026年10月6日に、148から161までの版について、安定版の予定日を取得して、前の版との間隔を数えた。

148から152までの間隔は28日で、153から14日に変わっている。予定日はすべて火曜日だった。153以降で目に付くのは、年末年始だけ間隔がのびる予定であることで、159は21日、160は28日である。この表は、公式の文書ではなく公開されているスケジュールの値なので、予定日は変わりうる。

1年に出る版の数は、計算すると2倍になる

1年を365日として、28日おきなら約13本（365÷28≒13.0）、14日おきなら約26本（365÷14≒26.1）になる。これは筆者の計算であって、公式の数字ではない。30日の間には、14日おきの安定版の予定日が2回か3回入る。納品から30日後に、利用者のChromeが納品の日と同じ版である保証は、なくなったと考えたほうがよい。

1つの版の中身は小さくなる

記事は、利用者について、より小さく、より頻繁な機能の更新と、より速いセキュリティの修正を受け取ると書いている。1つの版が持ち込む変更は小さくなるが、サイトに関わる変更が混ざる確率が、版ごとに消えるわけではない。たとえば、2026年9月の154では、iframeの高さを内容に合わせる指定が入り（Chrome 154で、iframeの高さを中身に合わせる指定が入った。ただし親のCSSと子のmetaの2か所が要る ── 自社の埋め込みを「両側を持つもの」と「提供元に頼むもの」に分ける13項目（2026年10月時点））、HTTPのページを開く前の確認が既定で出る（Chrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点））。版が変わるたびに、リリースノートを開く手間が増える。

制作と運用で、効いてくる場面

• 表示の確認：納品前に確認した版と、納品後に利用者が使う版が、すぐにずれる。
• 計測の前後の比較：2つの期間のあいだに、Chromeの版が1回から2回変わる。
• 納品後の確認の約束：30日の保証なら、期間のうちに、安定版が2回か3回出る。
• 来訪者の版の割合：古い版の割合が、2週間ごとに動く。

03 用語 — 安定版、ベータ、Extended Stable、版の番号の言葉を分けて読む

安定版（Stable）

ベータ（Beta）

Extended Stable

メジャーの版の番号（マイルストーン）

04 型別 — 自分の仕事がどの型に当たり、何を、どの順で確かめるか

🅰 自分の仕事は、どの型か

周期の変化が効く場面は、仕事によって違う。次の4つのうち、当てはまるものに印を付ける（複数でもよい）。

• 表示の確認を担当する型（複数のサイトを見る制作・運用）：確認の予定が、ブラウザの新しい版と並ぶ。
• 納品後の保守を請け負う型：保証や点検の期間に、新しい版が何回出るかが関わる。
• 数字の報告を担当する型（アクセス解析・表示速度の計測）：前後の比較に、版の変わり目が混ざる。
• 端末の更新を管理している会社を取引先に持つ型：Extended Stableの8週間の区切りが関わる。

🅱 公式文書が書いていないこと

次のことは、確かめた範囲の公式文書には書かれていない。この記事も、断定しない。

• 2週間の周期が、いつまで続くか。
• 年末年始に、安定版の間隔がのびる予定であること（ブログとリリースノートには、書かれていなかった）。
• Extended Stableの大きな更新の日付の一覧。
• 自社のサイトで、版ごとに不具合がどれだけ起きるか。

この記事が確かめていないこと

筆者は、Chrome 155のベータを手元に入れて、サイトを開く確認をしていない。当サイトの来訪者のChromeの版の割合も、この記事のために集計していない。書いたのは、公式のページの記載と、公開されているスケジュールの値である。

🅲 手順1 — 安定版の予定日を、8週間先まで書く

Chrome Platform Statusのロードマップと、Chromium Dashboardのスケジュールを開き、今日から8週間先までの安定版の予定日を、版の番号とセットで書く。2026年10月6日の時点では、155が10月6日、156が10月20日、157が11月3日、158が11月17日である。予定日は動きうるので、月に1回、開き直す。

🅲 手順2 — ベータで見る日を決める

公式ブログは、開発者に、ベータ版でサイトを試すことを勧めている。

"We encourage all developers to bookmark the Chrome Status Roadmap and test your sites against Chrome Beta channel releases."

（訳: すべての開発者に、Chrome Status Roadmapをブックマークして、ChromeのBetaチャンネルの版で自分のサイトを試すことを勧める。）

Chromium Dashboardの予定では、155のベータは9月16日、安定版は10月6日で、ベータが出てから安定版まで20日ある。156は、ベータが9月30日、安定版が10月20日で、同じく20日である（日付の差は、筆者の計算）。安定版が出る前に、主要な3ページをベータで開く日を、1回ぶん、手帳に入れておく。

🅲 手順3 — 計測の比べ方に、版の変わり目を書く

表示速度やコンバージョンの数字を、2つの期間で比べるとき、期間のあいだにChromeの版が変わっていると、サイト側の変更と、ブラウザ側の変更が、同じ差の中に混ざる。比べる資料の欄外に、期間のあいだにあった安定版の予定日を書いておく。CrUXのINPについて、公式にも原因が分かっていない悪化が続いた話は、CrUXの2026年8月分でもINPの悪化が続き、原因は公式にも分かっていない ── 自社の悪化を全体の傾向と切り分けて確認する13項目（2026年10月時点）に書いた。条件がそろっていない数字を並べた失敗は、同じ条件で測っていなかった ── robots.txtは「24時間キャッシュ」のはずが、測ったら1日13.9件と152.3件。3サイトの数字を並べる前に確認すべきだったことに書いた。

🅲 手順4 — 来訪者のChromeの版を、メジャーの番号ごとに数える

Privacy Sandboxのページは、縮小されたUser-Agentについて、次のように説明している。

"The reduced User-Agent includes the browser's brand and a significant version, where the request came from (desktop or mobile), and the platform."

（訳: 縮小されたUser-Agentには、ブラウザの名前と意味のある版、リクエストの出どころ（デスクトップかモバイルか）、プラットフォームが含まれる。）

同じページの例には「Chrome/98.0.0.0」という文字列がある。つまり、アクセスログのUser-Agentで版を数えるときは、Chrome/のあとの最初の数字がメジャーの番号で、残りは0である。手元のログで数えるなら、grep -o 'Chrome/[0-9]*' access.log | sort | uniq -c | sort -rn | headのような形で、メジャーの番号ごとの行数が出る。一般に知られているとおり、Chromium系の別のブラウザの文字列にも「Chrome/」が含まれるので、Edgeなどの印が付いた行は、別に数えるか、外す。ログの数え方で、HTTPのログだけを見て数を取り違えた話はAIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた、行全体で探して正反対の2つが混ざった話は「AIからの流入60件」を数え直したら、60件ともAIが自分の名前を名乗った文字列だった ── ログを行全体で探すと、正反対の2つが混ざるに書いた。

🅲 手順5 — 納品後の確認の連絡に、版の番号を書く

「Chromeで確認しました」だけでは、2週間後には、何の版だったかが分からない。確認の連絡の文面に、確認に使った版の番号と、確認した日を書く欄を足す。手元のChromeの版は、ブラウザの設定画面の「Chromeについて」で見られる。

🅲 手順6 — 年末年始の間隔を数える

Chromium Dashboardの値では、158が11月17日、159が12月8日、160が2027年1月5日、161が1月19日である。158から159は21日、159から160は28日で、確認の予定を「14日ごと」で組んでいると、この間だけ版の数が合わなくなる。休みの前に確認を済ませ、休み明けの最初の営業日に、同じページを開き直す予定を入れる。

🅲 手順7 — Extended Stableを使う取引先に聞く

取引先がExtended Stableを使っているかは、外からは分からない。聞く質問は1つで、「ブラウザの更新は、2週間ごとの安定版ですか、Extended Stableですか」でよい。Extended Stableの8週間の区切りについて、公式ブログは156と160を例に挙げている。Chromium Dashboardの安定版の予定日で、この2つを数えると、156が10月20日、160が2027年1月5日で、77日（11週間）空く。8週間という書き方と開きがあるが、Extended Stableの更新日が、安定版の予定日と同じとは限らない。筆者は、Extended Stableの更新日そのものを確かめられていない。

05 自分のサイトで確認するチェックリスト

下の13項目は、1項目5分ほどでできる作業である。項目1が手順1、項目2・3が確認の予定の棚卸し、項目4と5が手順2、項目6と7が手順4、項目8が手順3、項目9が納品後の約束、項目10が手順5、項目11が手順6、項目12が手順7、項目13が手順1と2をまとめる作業に対応している。担当するサイトがまだ無い人も、項目1・4・13は、今日から使える。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。

• Chromium Dashboardのスケジュールを開き、今日から8週間先までの安定版の予定日を、版の番号とセットで4つ書く
• 担当しているサイトのうち、表示の確認の予定を持っているものを数え、確認の間隔を、日数で1つずつ書く
• 項目2の予定のうち、「Chromeの新しい版が出たら」と書いてあるものの本数を数えて書く
• 手元のChromeの設定画面で「Chromeについて」を開き、版の番号を書き、ベータ版を入れたパソコンがあるかを、「ある」か「ない」で書く
• 担当サイトの主要な3ページを、ベータ版のChromeで開き、崩れや動かない場所がないかを、1ページずつ「あり」か「なし」で書く
• アクセスログかアナリティクスで、直近7日間のChromeの版を、メジャーの番号ごとに上位3つ書き、割合を書く
• 項目6で書いた3つの番号が、最新の安定版から何版前までに入るかを、数字で書く
• 前後を比べている計測の資料を1つ選び、比べる期間のあいだにあった安定版の予定日の数を、項目1の予定日から数えて書く
• 納品後の確認を約束している案件を1つ選び、その日数を14で割った商を書き、約束の期間に安定版が何回出るかを書く
• 納品後の確認の連絡の文面に、確認に使った版の番号と日付を書く欄があるかを見て、無ければ、足す一文を1つ書く
• 2026年12月8日と2027年1月5日の安定版の予定日の前後7日間に、確認できない日が何日あるかを数えて書く
• Extended Stableを使っているか、取引先3社に聞き、「使っている」「使っていない」「分からない」で書く
• 今日から14日分の確認の予定を、「ベータで見る日」「安定版が出る日」「出た翌日に見る日」に分け、日付を1つずつ書く

チェックリストの使い方

時間が限られているときは、項目1・5・6・13の4つだけでも、「次の安定版はいつか」「ベータで崩れていないか」「来訪者はどの版か」「次の2週間に何をするか」が分かる。項目6と7は、周期が変わっていなくても、使える。来訪者の版が分かれば、確認する版の数を決める材料になる。

06 代替・他の選択肢 — 2週間の周期への合わせ方は、1つではない

追い方を、4つ比べる

どれを選んでも、確認した版の番号と日付を残すことは共通である。2週間ごとに版が変わるので、残さないと、あとから「どの版で確認したか」が分からなくなる。

画面を撮って、前回と見比べる

確認するページが多いときは、当サイトの無料ツール🔧 WEBページのスクリーンショット、表示デバイスの比較をまとめて撮っちゃおツールや、🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールで画面を撮り、前回の画面と見比べられる。どちらも、画面を撮って並べるツールであって、Chromeの版を選ぶツールではない（版を選べるかは、筆者は確かめていない）。

版ごとの変更を、あとから調べる

版ごとの変更は、リリースノートと、「New in Chrome」の記事で調べられる。たとえば、153の廃止予定のAPIはChrome 153のリリースノートで、広告とクッキーに関わるAPI 5つが「廃止予定」になった ── 自社のタグと埋め込みの提供元に確認する14項目（2026年10月時点）、154のHTTPの確認はChrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）で扱った。表示速度の判定の基準は、Core Web VitalsのLCP・INP・CLSは「良好・改善が必要・不良」の3段階で判定される ── 自分のサイトで確認する14項目（2026年9月時点）に書いた。

07 当サイトで確かめたこと

公式のページを、4つ取り直した

2026年10月6日の午前に、次の4つのページを取得して、本文を読んだ。2週間の周期の開始（9月8日付のブログ）、Chrome 154のリリースノート、Chrome 155のベータの記事、Chrome Platform Statusの155のページである。この記事の引用は、取得した本文と1文字ずつ照らして書いた。

周期の日付を、公開データで数えた

Chromium Dashboardのスケジュールから、148〜161の安定版の予定日を取得し、前の版との間隔を計算した。148から152は28日おき、153から158は14日おきで、159は21日、160は28日、161は14日だった。表の予定日は、すべて火曜日だった。

155の安定版は、「出た」と書けない

同じ日の午前11時30分ごろ、次の4つを調べた。ChromeのVersionHistory APIの、Windowsの安定版の一覧には、155.0.8059.26と155.0.8059.12があり、その次が154.0.8037.98だった。一方、Chrome Releasesのブログでデスクトップの最新の安定版の告知は、2026年10月1日付で、154.0.8037.97と154.0.8037.98だった。developer.chrome.comの「New in Chrome 155」の記事と155のリリースノートのページは、404だった（chromestatus.comの155のページは200だった）。さらに、同じブログの2026年10月2日付のExtended Stableの告知は、152.0.7977.152で、このとき安定版は154だった。VersionHistory APIの案内は、このAPIを、Google ChromeとFuchsia Web Engineの版の履歴に、プログラムからアクセスできるものと説明している。一覧に版があることが、すべての利用者に届いたことを意味するのかは、APIの応答からは分からない。Chromium Dashboardの155の欄には、early_stableという項目があり、日付は2026年9月23日だった。この項目が何の配信を指すかは、筆者は公式の説明を見つけられていない。このため、この記事は、155の安定版を10月6日の「予定」と書いた。同じ10月6日に、当サイトのトップページに出る「ブラウザ・OS 最新バージョン」の表を見ると、「Chrome（stable）155.0.8059.26」と出ていたが、この表の出典のリンクはVersionHistory APIで、VersionHistory APIの一覧と同じ種類のデータであり、公式の安定版の告知とは別のものである。

当サイトの来訪者の版は、集計していない

当サイトのアクセスログを開いて、Chromeの版を数える作業は、この記事のためには行っていない。手順4の数え方は、公式のページの説明と、一般的なログの読み方から書いたもので、当サイトのログで試した結果ではない。数えたあとは、合計だけで終わらせず、内訳を割って見る。参照元の95.1%が自分のサイトからの移動だった話は、外部から来た人は19人だけだった ── アクセスログの「参照元」の95.1%は、自分のサイトからの移動だったに書いた。

08 このテーマの、これまで

2週間の周期をめぐる、日付つきの記録

この表に、自社のサイトでの影響は入っていない。影響が出るかどうかは、サイトの作りと来訪者の版による。

当サイトの、関連する過去の記事

• 同じ条件で測っていなかった ── robots.txtは「24時間キャッシュ」のはずが、測ったら1日13.9件と152.3件。3サイトの数字を並べる前に確認すべきだったこと — 3つのサイトの数字を、同じ条件でそろえずに並べた失敗の記録。
• 「AIからの流入60件」を数え直したら、60件ともAIが自分の名前を名乗った文字列だった ── ログを行全体で探すと、正反対の2つが混ざる — ログを行全体で探すと、正反対の2つが混ざった記録。
• AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた — HTTPのログだけを見ていて、数を大きく取り違えた記録。
• 外部から来た人は19人だけだった ── アクセスログの「参照元」の95.1%は、自分のサイトからの移動だった — アクセスログの参照元の大半が、自分のサイトからの移動だった記録。
• 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面が、目当ての画面とは限らなかった記録。