Chrome 152 リリースノート

Chrome 152 より、CPU パフォーマンス API が導入されます。この API により、ウェブ アプリケーションはユーザー デバイスの CPU パフォーマンスを特定できるようになります。この API は、ユーザー体験向上を目的としてこの情報を使用するウェブ アプリケーションを対象としています。また、ユーザー デバイスの CPU 負荷や使用率に関する情報を提供し、アプリケーション側で CPU 負荷の変化に応じた処理を行う可能性があるため、Compute Pressure API と組み合わせて使用​​されることも想定されています。

ユーザーは、Chrome ブラウザの[設定] > [パフォーマンス] > [速度] > [CPU のパフォーマンス ティアをオーバーライド]を使用して、報告されたパフォーマンスをオーバーライドできます。管理者は、 CpuPerformanceTierOverrideポリシー（ユーザー設定より優先）を使用して、この動作を制御することもできます。

詳しくは、 CPU Performance API の解説をご覧ください。

Chrome 152 では、macOS にインストールされたプログレッシブ ウェブアプリ（PWA）を対象とした通知アトリビューションが導入されます。macOS に PWA をインストールすると、通知が Google Chrome ではなく PWA 自体に定められるようになります（通知センターでは、PWA 独自の名前とアイコンが使用されます）。

この更新では、ユーザーへの通知の表示方法も変更され、PWA の通知が macOS のネイティブ アプリケーションと統一された形式で表示されるようになります。 WebKitの最新動作に合わせて、次の 2 つの変更が行われます。

• アプリの通知: Chrome で通知の requireInteraction フィールドのサポートが終了します。macOS では、通知を一時的に表示するか永続的に表示するということで、ユーザーがアプリごとに設定できます。
• アプリのバッジ: Badging API でバッジを表示するには、通知権限が必要になります。ユーザーが通知権限を付与しない場合、この API は何も行いません。

Chrome ポリシーを使用して通知権限を制御し、macOS 上の PWA でその動作を維持するには、Chrome のオリジンベースのポリシーNotificationsAllowedForUrlsを使用してポリシー設定を更新する必要があります。また、macOS MDM 設定をデプロイして、該当する PWA の特定のバンドル ID の通知権限を有効にする必要があります。

CSSPseudoElement のサポートは、現在 ::after、::before、および ::marker に対してのみ定義されていますが、いくつかの新しい擬似要素を含むように拡張されています。

::backdrop: ダイアログ内のコンテンツをクリックした際に、背景がクリックされたときにダイアログを閉じるのに便利です。これにより、クリックが発生した場所を特定するための複雑な交差ロジックが不要になります。

::scroll-marker: はクリック統計を収集するために使用できます。

ビュー遷移: ジオメトリを考慮したビュー遷移を有効にします。また、現在アニメーション中の要素の座標を利用して、ビュー遷移の途中で新しい遷移を開始し、突然の視覚的なジャンプを回避することもできます。

相対アルファカラーは、元の色を参照し、アルファチャンネルのみを変更します。アルファチャンネルの意味は、CSS Color 4 § 4.2 色の透明度の表現: <alpha-value> 構文で定義されています。

window-drag CSSプロパティを使用すると、インストール済みのデスクトップWebアプリのUI領域のうち、ドラッグ可能なウィンドウタイトルバー領域として動作するようにWebコンテンツで指定できます。このプロパティを適用すると、その領域上でのユーザーのポインタ操作（クリック＆ドラッグなど）によって、通常のページ操作ではなく、最上位のアプリケーションウィンドウが移動します。これは主に、デスクトップPWAや、Window Controls Overlayなどの機能を使用して、ブラウザが提供するタイトルバーが非表示になっている場合にカスタムタイトルバーとドラッグ可能な領域を実装するアプリで使用されます。

この機能は、既存のapp-region CSS プロパティを標準化して名前を変更し、値の名前をmoveとnoneに変更し、明示的な継承動作を追加します。このプロパティは、インストール済みの Web アプリと Electron ベースのアプリケーションで同じ目的で使用されます。

接続許可リストは、ドキュメントまたはワーカーからFetch APIやその他のWebプラットフォームAPIを介して開始される接続を制限することにより、外部エンドポイントを明示的に制御できるように設計された機能です。

提案されている実装では、HTTPレスポンスヘッダーを介してサーバーから承認済みエンドポイントリストが配信されます。ユーザーエージェントがページに代わって接続を確立する前に、エージェントはこの許可リストに対して宛先を評価します。検証済みのエンドポイントへの接続は許可され、リストのエントリに一致しない接続はブロックされます。

提案の詳細については、こちらをご覧ください： https://github.com/WICG/connection-allowlists

デザインドキュメント： https://docs.google.com/document/d/1B3LERUObjVDAKBNLpdIxbk8LC96rWUn1q8vtP9pPIuA/edit?usp=sharing

実装設計： https://source.chromium.org/chromium/chromium/src/+/main:docs /connection_allowlist_design.md

HTMLのautocorrect属性を使用すると、Web作成者は、<input>、<textarea>、contenteditableホストなどの編集可能な要素内のユーザー入力に自動修正を適用するかどうかを制御できます。この機能により、「autocorrect」属性がWeb作成者に公開されます。

navigator.mediaCapabilities.decodingInfo()で使用されるKeySystemTrackConfigurationディクショナリにencryptionScheme属性を追加します。これにより、Web アプリケーションは特定の暗号化方式 ( 'cenc'や'cbcs'など) がサポートされているかどうかを照会できるようになります。

注：この機能は既にW3C仕様で承認されており、Chromiumの基盤となるバックエンド実装も既に存在します。今回のリリースは、Blink IDLレイヤーのencryptionSchemeプロパティを既存のバックエンドに連携させるためのものです。

OpaqueRange 、 <textarea>やテキストベースの<input>などのフォーム コントロールの値内の有効なテキスト範囲を表すため、開発者は範囲のような API を使用して値テキストを操作できます。

これによりgetBoundingClientRect() 、 getClientRects()などの操作が可能になり、インラインサジェスト、ハイライト、アンカー付きポップオーバーなどのUI機能を実現するCSSカスタムハイライトAPIとの統合も可能になります。値オフセットのみを公開し、 startContainerとendContainer公開しないことでカプセル化が維持され、DOMエンドポイントと内部構造は非公開となります。

サブアプリを使うと、デベロッパーは 1 つの独立したウェブアプリ（ IWA ）のインストールで複数のアプリを作成できます。各サブアプリには、独自の名前、アイコン、OS との機能が統合されています。

サブアプリは、親 IWA とは別の識別情報でデスクトップ シェルフに表示され、ファイルの初期設定など、個別の OS 機能を提供します。これにより、IWA のインストールと更新を単一のプロセスに統合しながら、1 つのソフトウェア パッケージで独立したさまざまな機能をユーザーに提供できます。

サブアプリ API を制御するための 3 つの新しいエンタープライズポリシーをご利用いただけるようになりました。

• DefaultSubAppsWithoutPromptsSettingでは、サブアプリのインストール時にユーザーの許可プロンプトを必要とするかどうか、すべての IWA に対してグローバルに設定します。

• SubAppsWithoutPromptsAllowedForOrigins では、ユーザーの許可プロンプトを表示せずにサブアプリを追加または更新できる IWA URL のリストを指定します。

• SubAppsWithoutPromptsBlockedForOriginsでは、ユーザーの許可プロンプトがある場合にのみサブアプリを追加できる IWA URLのリストを指定します。

フレームなし表示モードでは、独立したウェブアプリ（ IWA ）がブラウザウィンドウ全体を占有できるため、利用可能なワークスペースが最適化されます。標準のウィンドウの枠とタイトルバーを削除することで、デベロッパーは、デバイスにインストールされているアプリのデザインと操作感に一致するブランディングやメニューを備えた独自のユーザーエクスペリエンスを実現できます。

管理者は、ウィンドウ管理に関するポリシーを使用してこの機能を管理できます。

• DefaultWindowManagementSettingでは、すべてのアプリのウィンドウ管理のデフォルトの状態を設定します。以下のポリシーでこのデフォルト設定をオーバーライドできます。
• WindowManagementAllowedForUrlsでは、指定したオリジンの独立したウェブアプリがユーザーの操作なしでフレームなしモードに移行することを許可します。
• WindowManagementBlockedForUrlsでは、指定したオリジンの独立したウェブアプリに対してフレームなしモードをブロックし、Chromeを他の利用可能な表示モードにフォールバックさせます。

不審なサイトに関する警告は、不正のある可能性があるサイトについてユーザーに警告する、 [セーフブラウジング] > [保護強化機能]の新しい機能です。

Chrome 152 では、セーフ ブラウジング保護強化機能を有効にしているユーザーが集まる可能性を示す一方を含むサイトにアクセスすると、スキップ可能なポップアップで警告が表示され、次に実行するにはこれをクリックする必要があります。この警告は、赤色のインタースティシャル警告に加えて表示されます。

管理者は、どなたのSafeBrowsingProtectionLevelポリシーを使用して、このを制御できます。特定のサイトで警告が表示されないように、 SafeBrowsingAllowlistDomainsポリシーに URL を追加します。

計算シェーダー内でサブグループサイズを明示的に設定できる、オプションのGPU機能「subgroup-size-control」を追加します。

この手法は、AIワークロードなど、特定のプラットフォーム上で特定のサブグループサイズを用いたサブグループ演算によって計算シェーダーのパフォーマンスを最適化する必要があるアプリケーションに特に有効です。

getDisplayMedia APIで使用されるDisplayMediaStreamOptions辞書にaudioPreference属性を追加します。

このヒントにより、Webアプリケーションはユーザーエージェントに対し、ビデオと併せて音声共有を優先することを通知できます。これにより、開発者は音声キャプチャに依存するアプリケーションがスムーズに動作することを保証できます。

すべてのブラウザが準拠しているXSLT v1.0は、1999年に標準化されました。その間、XSLTはv2.0やv3.0へと進化して機能が拡張されており、ブラウザに固定されたままの古いバージョンとは別れが進んでいます。の利用はかなり削減しました。ウェブブラウザ内での役割は、JSON や React などの JavaScript ベースのテクノロジーに大きく取り入れられて代われています。

Chromium はこれらの変換処理にlibxsltライブラリを使用していますが、2025 年約 6 か月間、 libxslt のメンテナンスは行われていませんでした。Libxslt は、複雑で古い C コードベースです。この種のコードは、バッファ オーバーフローなどのメモリ安全性の脆弱性がありやすいことで悪名が高く、任意のコード実行を考慮します。クライアント側 XSLT現在、ほとんど使用されていないコアな機能であるため、これらのライブラリは JavaScript エンジンよりもメンテナンスやセキュリティの精査がはるかに少なく削除されています。その場で、信頼できないウェブコンテンツを処理する際の、直接的かつ強力な攻撃対象領域となっています。

このような理由から、Chromium（および他の 2 つのブラウザ エンジン、Gecko と WebKit）では、XSLT が非推奨となり、ウェブプラットフォームから削除される予定です。現在のウェブは、 Blink （Chromium）、 Gecko （Firefox）、 WebKit （Safari）の 3 つの主要なブラウザ エンジンを基盤としています。

詳しくは、 Chrome for Developersの記事をご覧ください。

Chrome 158 以降、安定版リリースで XSLT の機能は停止します。

Reference Targetを使用すると、<label for>、aria-labelledby、popovertarget、commandforなどのID属性をコンポーネントのシャドウDOM内の要素に転送しながら、シャドウの内部状態のカプセル化を維持できます。

シャドウホストが、自身のシャドウツリー内の要素を参照ターゲットとして指定すると、シャドウホストを指すすべてのID参照は、代わりにその参照ターゲット要素に転送されます。

<label for="my-checkbox">チェックボックスの値（クリックしてチェックボックスを切り替える）</label> <custom-checkbox id="my-checkbox"> <template shadowrootmode="open" shadowrootreferencetarget="real-checkbox"> <input id="real-checkbox" type="checkbox"> </template> </custom-checkbox>

参照ターゲットは、上記の例のように宣言的に設定することも、ShadowRootのreferenceTargetプロパティを使用してJavaScriptで設定することもできます。

現在のビューポートにおける推測ルールに関するヒューリスティックでは、開発者が実験を行う余地が全くありません。

この実験的な機能は、そのような制御機能を提供し、開発者がさまざまなヒューリスティックパラメータがデフォルトのものよりも優れた結果をもたらすかどうかを判断できるようにします。

これはあくまで実験目的の機能であり、現状のまま製品版としてリリースする予定はありません。

最新のブラウザは、ユーザーに代わってページ内のメディアを修正することで、ブラウジング体験を向上させる機能を提供できる。生成型AIの登場により、ブラウザがこうした機能を追加する可能性はさらに高まっている。

ユーザーのリクエストによって追加された代替コンテンツが、ページ内の他のコンテンツや機能と一致しない場合があり、ユーザーを混乱させる可能性があります。これを完全に回避することはできませんが、作成者が代替が発生したタイミングを把握できれば、他のコンテンツを非表示にしたり調整したりするなどして、混乱を軽減することができます。

例えば、一般的な商品画像（ジャケットを着たモデルなど）が掲載されているECサイトを閲覧しているユーザーは、自分がその商品を着用している姿を想像したいと思うかもしれません。ユーザーエージェントは、生成AI技術を用いてそのイメージを生成し、モデル画像の代わりに表示します。ページは、モデルの体型や衣服のサイズに関する記述を削除することで、ユーザーエクスペリエンスを向上させます。なぜなら、置き換えられた画像では、これらの記述が正しくない可能性があるからです。

プライベートアグリゲーションAPIは、プライバシーを保護しながら、サイトをまたいだ集計データを測定するための汎用的なメカニズムです。これは元々、サードパーティCookieが存在しない未来を想定して設計されました。

ChromeがサードパーティCookieに関する現行のアプローチを維持すると発表したことを受け、Private Aggregation API（およびPrivate Sandbox機能ステータスページ0に記載されているその他のPrivate Sandbox API）を廃止し、削除する予定です。このAPIはShared Storage APIとProtected Audience APIを介してのみ公開されていますが、これらのAPIも廃止および削除される予定です。したがって、Private Aggregationに関して追加の作業は必要ありません。