タグ: Google

表示速度の指標であるCore Web Vitalsには、長いあいだ測りきれない領域がありました。ページ全体を読み直さず、JavaScriptで中身だけを入れ替えて画面を切り替えるサイト、いわゆるシングルページアプリケーション(SPA)の二枚目以降の画面です。10月13日に公開されたChrome UX Report(CrUX)の9月分データで、この領域を含めた実験的な指標が加わりました。ブラウザ、開発ツール、計測ライブラリ、公開データの四つがそろって動いた形なので、何が変わったのかを順に整理してみます。

読み直さない画面遷移はなぜ測れなかったのか

通常のウェブサイトでは、リンクを押すとサーバーから新しいHTMLを受け取り、ブラウザはそこを新しいページの始まりとして扱います。これをハードナビゲーションと呼びます。一方、ReactやVue、Angularなどで作られたSPAは、最初に一枚のHTMLとアプリ全体のコードを読み込み、その後はHistory APIでアドレスバーのURLだけを書き換えながら画面を差し替えます。こちらはソフトナビゲーションと呼ばれます。

見た目は新しいページに移ったように見えても、ブラウザから見れば同じページの中で表示が変わっただけです。そのためCore Web Vitalsは事実上、最初の読み込みだけを表し、その後の操作で起きたことは最初に開いたURLの成績にまとめて計上されるか、そもそも測られていませんでした。DebugBearの解説によると、何を画面遷移とみなすかはフレームワークごとに考え方が違い、URLを書き換える時機も中身を読み込む順番もまちまちだったことが、標準的な計測を難しくしていたとされています。

Chromeがソフトナビゲーションとみなす条件

この問題に対してChromeは、各フレームワークのルーターに入り込むのではなく、ブラウザ側の判定ルールで見分ける方法を選びました。利用者の操作がきっかけでURLが書き換わり、その結果として画面の表示が変わった場合に、それをソフトナビゲーションとして扱います。2026年8月に出たChrome 151で、この判定とCore Web Vitalsの計測が正式に入りました。

条件を絞っているぶん、作る側が画面遷移のつもりでも数えられない場面が出てきます。たとえば一定時間でアプリが自動的に別の画面へ切り替わるような処理は、利用者の操作が起点になっていないため対象外です。仕様はW3Cの標準化の手前の段階にあたるWICGで草案として扱われており、実装が出たことで仕様が固まったわけではない点も押さえておきたいところです。現時点で実装しているのはChromium系だけで、SafariとFirefoxでは測れません。

指標ごとに変わる数字の意味

ソフトナビゲーションが検出されると、各指標の集計はそこで区切られ、新しい画面の分として測り直されます。サーバーとのやり取りが発生しないため、最初の1バイトまでの時間(TTFB)は常に0になります。最大の要素が描画されるまでの時間(LCP)は直前の画面の描画を含まず、画面の差し替えで大きな要素が新たに現れたときだけ正の値になります。レイアウトのずれ(CLS)と操作への反応(INP)も、直前の遷移以降に起きたものだけを数えます。一回の滞在をまるごと表していた成績が、画面ごとの小さな単位に分かれるわけです。

開発ツールと計測ライブラリはどこまで対応したか

Chromeの開発者向けツール(DevTools)では、Chrome 152でPerformanceパネルのリアルタイム計測とトレース表示がソフトナビゲーションに対応し、Chrome 153と154では分析結果をまとめるInsightsにも対応が広がりました。公式ブログはこれで計測から分析までが一通りつながったと説明しています。タイムライン上ではソフトナビゲーション由来の項目にアスタリスクが付き、Nav*やLCP*のように表示されるので、通常の読み込みと見分けがつきます。

実際の利用者のデータを集める側では、Googleが公開しているweb-vitalsライブラリに、別系統で開発されていた対応が本体へ取り込まれました。各計測関数にオプションを一つ渡すだけで、画面ごとの値が報告されるようになります。

import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(console.log, { reportSoftNavs: true });
onINP(console.log, { reportSoftNavs: true });
onCLS(console.log, { reportSoftNavs: true });

このオプションを付けなければ、従来どおり最初の読み込みの分だけが報告されます。自社の計測をCrUXの数字と突き合わせたいときは付けない、画面ごとの体感を詳しく追いたいときは付ける、という使い分けになります。

CrUXの実験的な指標で何がわかったか

今回のCrUXでは、LCP、INP、CLSのそれぞれにソフトナビゲーションを含めた実験的な版が追加され、BigQueryのデータセットとCrUXのAPIの両方から取得できるようになりました。サイトごとの影響を確かめられるよう、可視化ツールのCrUX Visも更新されています。

公開された集計を見ると、従来の基準で三つの指標すべてが良好だったオリジンは55.9%でした。ソフトナビゲーションを含めて数え直すと、この割合は59.5%に上がります。指標別では、LCPが良好なオリジンが68.3%から72.1%へ、CLSが81.7%から85.1%へ、INPが85.4%から87.4%へと、いずれも上向いています。最初の読み込みで重いコードをまとめて受け取るSPAは、その後の軽い画面切り替えが評価に入っていなかったぶん、実際の体感より厳しく見えていたことがうかがえます。

注意したいのは、これがあくまで実験的な版として別に用意されたデータだという点です。従来のCore Web Vitalsの数字は、引き続き最初の読み込みを基準にしたものとして公開されています。DebugBearの解説も、検索の観点では当面は最初の読み込みを重視し、利用者のためにはその後の画面遷移も速く保つべきだと整理しています。

WordPressや一般的な企業サイトへの影響

中小企業のコーポレートサイトや、WordPressのテーマで組んだ一般的なサイトの多くは、リンクのたびにHTMLを読み直すつくりです。こうしたサイトは、そもそも従来の計測で全ページがきちんと測られていたので、今回の変更で数字が大きく動くことは考えにくいでしょう。

影響が出やすいのは、WordPressを管理画面として使い、表側をReactなどの別アプリで作る構成や、ページの切り替えをなめらかに見せるためにJavaScriptで中身だけを差し替える仕組みを入れたサイトです。こうしたサイトでは、これまで最初の一枚の成績で全体が語られていました。画面ごとに数字が分かれると、どの画面への移動で表示が遅れているのか、どの操作で反応が鈍っているのかを個別に追えるようになります。逆に言えば、最初の読み込みの重さに隠れていた特定画面の問題が表に出てくる可能性もあります。

計測の仕組みが変わったことで、これまでSPAの採用をためらう理由の一つだった「表示速度の評価が見えにくい」という点は、少しずつ解消に向かっています。ただしSafariとFirefoxでは測れないため、スマートフォンの利用者が多いサイトでは、iPhoneでの体感を別の方法で確かめる必要は残ります。

制作の現場でいま確かめておきたいこと

まず、自分たちが担当しているサイトが読み直し型なのか、中身の差し替え型なのかを把握しておくことです。テーマやプラグインの中に画面遷移を差し替える機能が含まれている場合もあるので、DevToolsのPerformanceパネルで記録し、Nav*の表示が出るかどうかを見れば判断の材料になります。

差し替え型のサイトであれば、CrUX Visで実験的な指標と従来の指標の差を見比べておくと、今後の評価の変化に備えられます。自前で計測している場合は、web-vitalsライブラリのオプションを付けた計測を別枠で取り、CrUXと合わせる計測と分けて管理しておくと混乱しにくくなります。また、利用者の操作を起点にしない自動の画面切り替えは数えられないことを踏まえ、計測したい画面遷移がきちんとリンクやボタンの操作から始まっているかも確認しておきたいところです。

私たちRESONIXも、読み直し型と差し替え型の両方のサイトに関わってきましたが、差し替え型の表示速度は手元の感覚に頼る部分が大きかったのが正直なところです。仕様はまだ草案で、実装もChromium系に限られますが、測れなかったものが測れるようになる流れははっきりしてきました。数字が正式な評価に組み込まれる前に、手元のサイトで一度眺めておくだけでも、次の改修の判断材料が一つ増えるはずです。

ページを開いたら広告ばかりで本文が見えない。そんな経験は誰にでもありますが、これまでは「多い気がする」という感覚で語られることがほとんどでした。Chromeの開発チームは9月15日、実際のユーザーの閲覧データを集めた Chrome User Experience Report(CrUX)に、広告の量と負担を表す指標を新しく加えたと発表しました。

加わったのは4つの指標です。画面内に見えている広告の平均数を数える「Ad Count」、画面の面積のうち広告が占める割合をスクロール中も含めて平均した「Ad Density」、そして広告のスクリプトや素材の読み込みと実行にかかった処理時間を示す「Ad Weight: CPU」と、通信量を示す「Ad Weight: Network」です。どの部分が広告かは、Chromeが持っている広告検出の仕組みで判定されます。

数値は既存のCrUXと同じく、実際のユーザーから集めた直近28日間の平均として公開されます。対象はWindows、macOS、Android、ChromeOS、Linux版のChromeで、iOS版のChromeやアプリ内のWebView、ほかのChromium系ブラウザは含まれません。いずれも「実験的」と明記されていて、今後名前や中身が変わる可能性があるとされています。

評価の基準ではなく見える化の道具

注意したいのは、これらがCore Web Vitalsの仲間ではないという点です。発表では、Core Web Vitalsから着想を得たものの、その一部ではなく、良い・悪いの目安となる基準値も設けていないと説明されています。主な使い手として想定されているのは広告主や広告配信の事業者で、広告枠の価値を判断する材料にしてほしいという位置づけです。検索順位に直接つながる話として受け取る必要はなさそうです。

一方で、制作の現場にとっても使い道はあります。9月下旬に公開されたChrome DevToolsの更新では、Applicationパネルに広告用の区画が加わり、この4指標をまとめて見られるようになりました。CPUと通信量を広告の要素ごとに分けて確認でき、メインフレームで動いている広告スクリプトの一覧や、ページ上の広告を強調表示する切り替えも用意されています。手元のブラウザで、どの広告がどれだけ重いのかを具体的に確かめられるわけです。

中小企業のサイトでも、アクセス解析のタグに加えて広告配信やリターゲティングのタグを複数入れているケースは珍しくありません。表示が遅いと感じたときに、原因が自社の作りなのか外部の広告なのかを切り分けるのは意外と手間がかかります。数値として見えるようになったことで、広告を入れるかどうか、どこまで載せるかを、感覚ではなく材料をもとに話し合えるようになるのではないでしょうか。データは今後1か月ほどで集まる範囲が広がるとのことなので、自社サイトや担当サイトがどう表示されるか、一度のぞいてみる価値はありそうです。

Chrome for Developersのブログで、9月16日にベータ版となったChrome 155の変更点がまとめられました。CSSの新しい指定やJavaScriptのモジュール読み込みの改善など項目は多いのですが、画像を扱う制作者として目が留まったのは、JPEG XL(image/jxl)の画像を読み込んで表示する機能がBlink(Chromeの描画エンジン)に加わったことです。

JPEG XLは国際規格ISO/IEC 18181として標準化された画像形式です。紹介記事によると、読み込みの途中から段階的に絵を見せられるプログレッシブ表示に対応しており、体感の表示速度を上げやすいとされています。加えて、広い色域やHDR、高いビット深度、アニメーションも扱えます。写真を多く載せるサイトや、色の再現にこだわる商品写真などとは相性のよい特徴がそろっています。回線の細い環境で大きな写真を見せるとき、最後まで読み込まれるまで空白が続くのか、粗い絵が先に出て徐々に鮮明になるのかでは、見ている人の印象がかなり違います。

中身の実装にも注目したい

今回の対応では、デコード(画像データを表示できる形に戻す処理)に、Rustで書かれたjxl-rsというデコーダーが使われています。記事ではこれを「メモリ安全な純Rust製のデコーダー」と説明しています。画像の読み込み処理は外から届いたデータをそのまま解析する部分なので、昔から脆弱性の温床になりやすい場所でした。新しい形式を受け入れるにあたって、安全性を意識した実装を選んだという点は、ブラウザ側の姿勢として心強く感じます。

とはいえ、今の段階はあくまでベータ版での対応です。正式版にいつ届くか、ほかのブラウザでどこまで使えるかは、それぞれの状況を確かめる必要があります。すぐにサイトの画像をJPEG XLへ置き換えるというより、<picture>要素で対応ブラウザにだけJPEG XLを渡し、それ以外にはWebPやJPEGを返す、という段階的な使い方が現実的でしょう。この書き方なら、対応していないブラウザで画像が欠けることもありません。

ちなみに同じベータ版には、ほかにも制作者に関係する変更が並んでいます。コンテナの先頭や末尾の子要素の余白を切り落とせるCSSのmargin-trimや、読み込みに失敗したJavaScriptのモジュールをあらためて読み込み直せるようにする変更などです。画像の話と合わせて、不安定な回線でも崩れにくいページを作るための部品が少しずつそろってきている印象です。

中小企業のサイトでは、画像の書き出し形式を一度決めたら何年も見直さないことが珍しくありません。WordPressのメディアライブラリや画像最適化プラグインがこの形式をどう扱うかも、今後の動きを見ていきたいところです。私たちも、写真の多い案件から少しずつ試しながら、表示の速さと画質のバランスを確かめていくつもりです。

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