月: 2026年9月

Googleが今年3月に告知していたChromeのリリース間隔の変更が、いよいよ実際の運用に入る。9月8日に安定版として公開されるChrome 153から、新しい版が2週間ごとに届く体制へ切り替わる。2021年から続いてきた4週間ごとの更新サイクルが、ここで半分の長さになる計算だ。

変わるのはベータ版と安定版で、デスクトップ、Android、iOSのすべてが対象になる。開発者が先行して動作を試すDevとCanaryのチャンネルには変更がない。Googleの説明によると、更新が頻繁になる代わりに一回あたりの変更範囲が小さくなるため、公開後に問題が出たときの切り分けがしやすくなるとされている。2023年に導入した週次のセキュリティ更新や、安定版を少し早めに配る仕組みと同じ流れの延長にある調整だという。実際、旧来の予定ではChrome 153の安定版公開は9月22日、次のChrome 154は10月20日だったが、新しい予定ではそれぞれ9月8日と9月22日に前倒しされている。

検証のリズムが変わる

制作の現場でまず効いてくるのは、動作確認のタイミングだろう。ベータ版は安定版の3週間前に出るとされているので、これまで月に一度まとめて追っていたリリースノートの確認は、間隔を詰めて拾う形に変わる。Googleも、サイトやアプリに影響しそうな変更を早めにつかむためにベータ版での検証を勧めている。追いかける先としては、機能の予定が並ぶChrome Statusのロードマップや、ベータ公開のたびに出る解説記事あたりが現実的なところだ。不具合の報告を受けたときに「どの版で試したか」を残しておく習慣も、以前より意味を持つようになりそうだ。ブラウザの版が違うだけで再現しない、という話は今後さらに起きやすくなる。

バージョン番号の刻みが速くなる点も、地味に効いてくる。ユーザーエージェントの数字を条件にした古い分岐や、特定のバージョンを前提にした社内の検証手順書が残っていれば、この機会に洗い出しておきたい。一方で、企業向けに用意されているExtended Stableは8週間のサイクルのまま据え置かれ、Chromebookについても専用の検証を経てから配信する形は変わらないとされている。管理された端末を配っている組織では、更新の速い一般の環境と、ゆっくり進む環境が並走することになる。取引先の社内向け画面やイントラのシステムを預かっているなら、どちらの前提で作られているかを一度確認しておくと、後で食い違いが出にくい。

直前のChrome 152は8月25日の公開で、旧サイクル最後の版になった。日々の制作がいきなり立ち行かなくなる種類の変更ではないが、ブラウザの機能が使えるようになる時期は全体として早まっていく。中小企業のサイトを預かる立場としては、新機能を先回りして追うより、確認の頻度を少し上げておくくらいの構えがちょうどよさそうだ。少人数で回している制作の現場ほど、更新の速さそのものより、気づける仕組みを持っているかどうかで差が出る。

ブラウザに入っている開発者ツールは、毎日のように開いているわりに、更新内容を追いかける機会の少ない道具です。Chrome 152 に含まれた開発者ツールの更新には、通信の調査まわりを中心に、現場の手数をそのまま減らすものがいくつか入っていました。派手な新機能ではありませんが、知っているかどうかで不具合を追うときの段取りが変わります。

通信を作り直さずに送り直せる

ネットワークパネルの右クリックにあった Replay XHR という項目が Resend に変わりました。名前が変わっただけではなく、対象が XHR に限られなくなり、取得できる通信全般を送り直せるようになっています。標準の通信は fetch の呼び出しに変換されたうえで再送され、その通信がどの実行文脈から出たのか、コンソールのどこが発端だったのかも表示されます。フォーム送信やAPIの応答がおかしいときに、画面の操作を最初からやり直さずに再現できる場面が増えます。

一覧の見え方も整理されました。通信の連番を示す列が先頭に固定され、あとから特定の通信を指し示しやすくなっています。フィルタ欄にドメインやホスト名、ポート番号を入れたときに、同じサイト内の通信が正しく絞り込まれるようになった点も地味に効きます。ペイロードのタブには Base64、16進数、UTF-8 という復号方法の切り替えが加わり、バイナリや圧縮された送信内容の中身も読めるようになりました。クエリやフォームの値は、はじめから復号された状態で表示されます。

先読みの扱いも分かりやすくなりました。その通信が投機的な先読みによって始まったものかどうかを示す列が追加され、右クリックからは、そのまま HTML に貼れる先読み用の link 要素の記述をコピーできます。Early Hints は発信元の列にまとめられました。表示速度の改善を頼まれたときに、いま何が先読みされているかを一覧で確かめられるのは便利です。

要素パネルがカスタム要素と入れ子のCSSに追いついた

ハイフンを含む独自のタグや、組み込み要素を拡張した書き方をしている要素には、DOM ツリー上に目印のバッジが付くようになりました。ブロックエディタやフレームワークが吐き出したマークアップを読むときに、素の HTML との区別が一目で付きます。

入れ子で書かれた CSS の親セレクタにカーソルを合わせると、該当する要素がページ上で強調され、スタイルタブの絞り込みにも反応するようになりました。入れ子の宣言に対する詳細度の説明も出ます。擬似要素まわりも改善され、DOM ツリーで before や after を選ぶと、コンソールの直前選択の変数にその擬似要素が入るので、そのまま JavaScript から確かめられます。text-wrap の値の候補表示や、画像の値を取るプロパティの補完も加わりました。ボックスモデルの図も、スクロールバーが出ている要素の内容領域を正しく計算するようになっています。

調べた結果を外に持ち出しやすくなった

コンソールで表として出力した内容を、Markdown か CSV の形式でそのままクリップボードに写せるようになりました。調査結果を社内の共有ドキュメントや課題管理に貼るまでの手間が減ります。デバッガで停止中にカーソルを合わせて式を評価する動作についても、新しいオブジェクトの生成や動的な読み込み、削除などを含む式は評価されないよう守りが入りました。調べているつもりが状態を書き換えてしまう事故を防ぐ変更です。

アクセシビリティまわりの改善も入っています。アクセシビリティツリーのノードや、その配下のまとまりをテキストとしてコピーできるようになり、要素パネルとアクセシビリティツリーの行き来も右クリックからできるようになりました。暗い配色のときに検索結果の強調が見えにくかった問題も直っています。画像の遅延読み込みを指定しているのに幅と高さの指定がない場合には、警告が出るようになりました。遅延読み込みだけ入れて寸法を書き忘れ、読み込み中に表示がずれるというのはよくある型なので、指摘してもらえるのは助かります。

そのほか、ファイルを開くときに手元の作業ディレクトリのファイルが上位に来るようになった点、保存データの削除まわりの設定が一箇所にまとまった点、回線速度の制限について既定の設定と自作の設定が別の欄に分かれた点なども、細かいながら毎日の操作に効いてきます。

更新の届く間隔そのものも短くなる

こうした改善の届き方も変わります。Chrome は9月8日の安定版から、これまで4週間だった更新の間隔を2週間に縮めます。1回あたりの変更の幅は小さくなる見込みですが、開発者ツールの項目名や場所が以前より短い周期で動くことになります。すぐに追随できない管理環境向けには、8週間ごとの Extended Stable がこれまでどおり用意されます。

中小企業のサイトを預かる保守作業では、不具合の再現と確認にかかる時間がそのまま作業量に響きます。使い慣れた道具ほど更新内容を見落としやすいので、手が空いたときに一度、いつも使っているパネルを開いて何が変わったかを眺めておくと、次に慌てる場面で効いてきます。

ブラウザがカメラやマイクの利用を尋ねてくる、あの小さなダイアログ。長らくJavaScript側の都合で表示されるものでした。ページを開いた瞬間に出てしまったり、一度「許可しない」を押すと二度と出てこなくなったりと、扱いにくさは制作の現場なら心当たりがあると思います。Chromeはこの役目をHTMLの要素そのものに移す作業を進めていて、8月下旬に公開された次期版のベータ告知に、映像専用の camera と音声専用の microphone というタグが並びました。

この一連の取り組みはCapability Elementsと呼ばれていて、先に位置情報を扱う要素が入り、続いてカメラとマイクをまとめて扱う usermedia が少し前の版で使えるようになっています。書き方はタグを置いて中にボタンを入れるだけ。解像度やエコーキャンセルといった希望は、利用者が触る前に専用のメソッドで伝えておきます。ストリームが取れたらイベントが飛んでくるので、成功と失敗のコールバックを自分で組み立てる手間がほとんどありません。ブラウザが単なる許可の門番ではなく、同意の取得からストリームの受け渡しまでを仲介する役に回った、という整理です。今回追加される2つは、映像だけ、音声だけを求める場面に絞った軽い版という位置づけになります。

断られたあとに戻れる道をつくる

この作りが効いてくるのは、実は最初の許可よりも、断られたあとの立て直しの場面です。試験導入の段階で集まった数字が公開されていて、一度拒否した利用者が改めて許可にたどり着ける割合は、従来のダイアログでは10%程度だったものが、新しい要素では65%を超えたという報告があります。別の事業者では取得エラーが約47%減り、また別のサービスでは「マイクが動かない」という声が17%減ったとされています。ブラウザ側の部品を押したという確かな合図があるぶん、自動的な抑制に引っかからず、設定画面の奥まで潜らなくても復帰できる導線が用意されるためです。

その代わり、見た目の自由度はかなり絞られています。文字と背景のコントラストは一定以上が求められ、透明度を下げて見えにくくすることもできません。幅や高さ、文字サイズには上限と下限があり、負のマージンで覆い隠すのも不可、変形は平行移動と縦横比を保った拡大縮小までです。利用者をだます置き方を封じるための線引きで、ブラウザが責任を持つ部品である以上は妥当な制約だと感じます。状態に応じた装飾は用意されていて、許可が下りてストリームが流れている状態を擬似クラスで拾えます。

未対応のブラウザでは、このタグは未知の要素として扱われ、中身がそのまま表示されます。つまり中に従来どおりのボタンを置いておけば、対応していない環境では既存の呼び出しに落とす、という書き分けができます。オンラインの相談窓口や、申し込みフォームで書類を撮って送ってもらう画面など、中小企業のサイトでもカメラを使う場面は少しずつ増えました。今のところChromeが先行して進めている段階ですが、権限まわりの面倒がスクリプトからブラウザ側へ寄っていく流れは、頭の片隅に置いておくと後々効いてきそうです。

ブラウザの拡張機能は、制作の現場で地味に効いてくる道具です。見出し構造の確認、色のコントラスト比の測定、通信内容の観察、テスト用のデータ差し替え。どれも本体の開発者ツールでできることではありますが、ワンクリックで呼び出せる拡張をいくつか常駐させている人は多いはずです。

その拡張機能の古い土台が、2026年8月31日にChromeウェブストアから完全に取り下げられました。長く予告されてきた移行の、最後の一段です。同じ週にはChrome 152の安定版で、別の系統の機能もひとつ静かに削除されています。予告された終わりが実際に来たとき、現場には何が残るのか。今回はそのあたりを整理してみます。

動かなくなった時期と、消えた時期は別

まず順番を整理しておくと、8月31日に起きたのは「急に動かなくなった」ではありません。Chromeの拡張機能の旧仕様は、2025年7月24日のChrome 138の時点で、すべての利用者、すべての配布チャンネルで無効化が完了しています。利用者が設定から手動で戻すこともできなくなりました。企業向けにはポリシーによる猶予が残っていましたが、それもChrome 139で撤去され、そのバージョンに上がった環境では一斉に効かなくなっています。

今回のできごとは、その先の段階です。ストアに残っていた旧仕様の拡張の掲載そのものが消え、更新の配信も、ストアからの再インストールもできなくなりました。Chromeの公式ドキュメントによると、Chrome 138以前で止めてある環境に入っているものはインストール済みの状態で残るものの、そこへ更新が届くことはないとされています。動作の停止が一年以上前、掲載の消滅が今回という、二段構えの終わり方になりました。

この二段構えは、利用者から見ると分かりにくい部分でもあります。無効化が進んだ時期には、拡張の管理画面に警告が出て、止まった拡張の代わりになるものがストアで案内される流れが用意されていました。案内する先そのものが今回なくなったので、これから同じ状況に出会った人は、自力で代替を探すことになります。制作側が顧客の環境を触るときには、この差を頭に入れておいたほうが説明しやすいはずです。

四年半かけて刻まれてきた予告

この移行は、ある朝いきなり通告されたものではありませんでした。公開されている支援終了の年表をたどると、ストアが新規の公開および限定公開の拡張の受け付けを止めたのが2022年1月、非公開の拡張についても止めたのが同年6月です。そこから二年ほど間があき、2024年6月に先行チャンネルで警告バナーの表示が始まり、旧仕様のまま残っていた注目枠のバッジが外されました。

2024年10月には安定版でも無効化が始まり、2025年3月末には既定で無効、ただし利用者が戻せる状態になります。同年7月にその戻す余地もなくなり、そして今回の掲載削除です。足かけ四年半、告知から実行までの期間としてはかなり長いほうだと思います。それでも最後の日には「もう入れ直せない」という形で影響が出るところが、この種の予告の難しいところです。

移行の途中で埋められていった機能の差

移行が長引いた理由のひとつは、新しい仕様で従来と同じことができるのか、という点が最初から解決していたわけではなかったからです。移行開始時の告知によると、この期間にユーザースクリプトの仕組みや、背景処理からDOMを扱うための画面外ドキュメントが追加され、通信の絞り込みに使うルールの上限も、あらかじめ同梱できる分が33万件、動的に足せる分がさらに3万件まで引き上げられています。

あわせて、ルール一覧の安全な更新であれば審査を数分で通す仕組みや、配信した版を巻き戻す機能も用意されました。同じ告知の時点で、活発に保守されている拡張の85%以上が新仕様に移っており、広く使われている通信の絞り込み系の拡張にも新仕様版が用意されていたと説明されています。外部の仕様変更に自分たちの実装を合わせていくとき、何が足りないかを出し合いながら進んだ例として読める部分があります。

移行を進めた側の説明では、新しい仕様の狙いは既存の機能を守りながら、安全性やプライバシー、動作の軽さ、そして信頼性を全体として底上げすることに置かれていました。実装者からの意見を受けて仕様を足していった、という経緯も添えられています。仕様の側が動かないまま期限だけが迫る形にはならなかったので、四年半という長さは、待たされた時間というより、埋め合わせに使われた時間と見るほうが実態に近そうです。

同じ週にもうひとつ外されたもの

8月25日に安定版となったChrome 152のリリースノートには、削除の項目がひとつだけ載っています。三者間のCookieについて現行の方針を維持するという発表を受けて、集計系のAPIが関連する一連の仕組みとあわせて廃止された、という内容です。長く議論されてきた計測手法の置き換えが、静かに畳まれた形になります。

多くの中小企業サイトでは、これに直接ぶつかることはないはずです。ただ、広告や効果測定のタグを入れたまま担当者が代わっている、というサイトは珍しくありません。自社で計測まわりの実装を抱えている場合は、リリースノートのこの行が自分たちに関係するかどうか、一度だけ確かめておくと安心だと思います。

手元の道具立てをどう見直すか

制作会社の側で今回の件が効いてくるのは、検証の手順に拡張機能を組み込んでいる場合です。旧仕様の拡張はもう入手できないので、検証用の端末を作り直したときに同じ環境を再現できません。手順書に拡張の名前が書いてあるなら、それが今も入手できるものかどうかを確かめて、置き換えるか、本体の開発者ツールでの手順に書き直しておくのが現実的です。

もうひとつ、古いChromeのまま固定してある検証端末に旧仕様の拡張が残っている場合は、そこに更新が届かない点を意識しておきたいところです。拡張は閲覧中のページの内容に触れる立場にあるので、直らないまま置いておく前提の道具としては扱いにくくなります。日常的に使う端末と、意図的に古い環境を保つ端末は、分けておくほうが落ち着きます。

顧客の環境について聞かれたときの答え方も、少し整理しておくとよさそうです。古い拡張が動かないという相談は、ブラウザ側の不具合ではなく、予定どおりの廃止によるものです。代わりのものを探すか、その作業を本体の機能で置き換えるか、という話に切り替えるだけで済みます。原因が分かっている変更は、伝え方さえ決めておけば手間の少ない部類に入ります。

予告を受け取る置き場所を決めておく

こうした変更を追いかけるコツは、情報を広く集めることよりも、見に行く場所を決めておくことにあります。ブラウザの各版のリリースノートには、追加された機能と並んで廃止と削除の項目が置かれています。拡張機能まわりの変更点も専用のページにまとまっていて、たとえばChrome 153では、URLの公開接尾辞を問い合わせるAPIの追加や、拡張のアイコンを既定でツールバーに固定する実験が告知されています。追加も削除も、同じ場所に同じ調子で並びます。

削除には猶予が用意されることもあります。Chrome 152では、ブラウザ側で行う変換処理の廃止に向けて、移行期間を確保するための試験参加の枠が始まりました。廃止の予告と、猶予の受け取り方が同じページに書かれているので、月に一度そこを開く習慣さえあれば、慌てる場面はかなり減ります。年表の最後の一行が自分の手元に届く前に気づけるかどうかは、結局のところ見に行く回数で決まります。