このページは Cloud Translation API によって翻訳されました。

Chrome 143 ベータ版

Rachel Andrew

公開日: 2025 年 10 月 29 日

特に記載がない限り、これらの変更は Android、ChromeOS、Linux、macOS、Windows 向けの Chrome 143 ベータ版チャンネルリリースに適用されます。これらの機能について詳しくは、提供されているリンクまたは ChromeStatus.com をご覧ください。Chrome 143 ベータ版は、パソコンの場合は Google.com から、Android の場合は Google Play ストアからダウンロードできます。

CSS と UI

CSS アンカーフォールバックコンテナクエリ

この機能では、適用される position-try-fallbacks 値に基づいてアンカー配置要素の子孫をスタイル設定する @container anchored(fallback) が導入されています。

たとえば、このようなクエリを使用して、アンカーとアンカー要素の相対的な位置に基づいて、アンカー要素のテザーやアニメーションのスタイルを設定できます。

例:

#anchored {
 position-try-options: flip-block;
 container-type: anchored;
}

@container anchored(fallback: flip-block) {
  #anchored > .arrow {
    --arrow-rotation: 180deg;
   }
}

詳しくは、Chrome 143 のアンカー付きコンテナクエリでフォールバック位置を検出するをご覧ください。

EditContext: TextFormat `underlineStyle` と `underlineThickness`

Chromium は EditContext API をリリースしましたが、EditContext/textformatupdate_event によって提供される TextFormat オブジェクトが underlineStyle プロパティと underlineThickness プロパティに誤った値を返すバグが含まれていました。Chromium では、None、Solid、Dotted、Dashed、Squiggle、None、Thin、Thick が有効な値です。ただし、EditContext 仕様では、none、solid、dotted、dashed、wavy、none、thin、thick となっています。

ウェブ API

JavaScript DOM API でより多くの文字数を許可

HTML パーサーでは、要素と属性にさまざまな有効な文字と名前を使用することが常に（または長い間）許可されていましたが、同じ要素と属性を作成する JavaScript DOM API はより厳格で、パーサーと一致していません。

この変更により、HTML パーサーに合わせて JavaScript DOM API の検証が緩和されます。

詳細については、github.com/whatwg/dom/issues/849 をご覧ください。

以前に許可されていた要素名と属性名は新しい動作でも有効であるため、この変更によって互換性の問題が発生することはありません。

推測ルール: モバイルの「eager」の積極性の改善

モバイルでは、HTML アンカー要素がビューポートに短時間表示されたときに、'eager' の投機的先読みとプリレンダリングのルールがトリガーされるようになりました。

以前は、プリフェッチとプリレンダリングはできるだけ早く開始されていましたが、これは「immediate」の意欲と同等でした。この更新された動作は、作成者の意図を「中程度」よりも強く、「即時」よりも弱く反映するため、より有用です。

CSS プロパティ font-language-override を実装

この機能では、Chromium で font-language-override CSS プロパティのサポートが導入されます。このプロパティを使用すると、デベロッパーは CSS で 4 文字の言語タグを直接指定して、OpenType グリフの置換に使用されるシステム言語をオーバーライドできます。

これにより、きめ細かいタイポグラフィ制御が可能になり、多言語コンテンツや言語固有のグリフバリアントを含むフォントに便利です。

WebGPU: テクスチャコンポーネントのスワズル

テクスチャコンポーネントスウィズルを使用すると、シェーダーがテクスチャの赤、緑、青、アルファの各チャンネルにアクセスするときに、GPUTextureViews がカラーコンポーネントを再配置または置換できます。

ICU 77（Unicode 16 をサポート）

Unicode サポートライブラリ ICU（International Components for Unicode）がバージョン 74.2 から 77.1 にアップグレードされ、Unicode 16 のサポートが追加され、ロケールデータが更新されました。Intl JavaScript API の特定の形式を想定しているウェブアプリケーションでは、次の 2 つの変更がリスクになる可能性があります。

イタリアのデフォルトの数値形式で、4 桁の数値の 3 桁区切りが省略されるようになりました。たとえば、new Intl.NumberFormat("it").format(1234) は「1.234」ではなく「1234」を返します。古い動作は、Intl.NumberFormat コンストラクタの useGrouping パラメータで実現できます。
一部の英語ロケール（en-AU、en-GB、en-IN など）では、曜日の後にカンマが追加され、「Saturday 30 April 2011」が「Saturday, 30 April 2011」に変更されました。ウェブアプリケーションは、日付の正確な形式に依存しないようにする必要があります。
Intl と RegExp（V8）: 多くの小さな変更。イタリアの数値形式への変更はリスクが最も高く、専用のフラグがあります。
IDNA: このアップグレードにより、一般的に多くのことが可能になり、WPT のテスト結果全体が改善されます。
テキストのセグメンテーション: 最も注目すべき変更点は、word-break: auto-phrase を使用した際の日本語の改行が改善されたことです。これは https://chromestatus.com/feature/5133892532568064 に関連しています。

`insertFromPaste`、`insertFromDrop`、`insertReplacementText` 入力イベントの `DataTransfer` プロパティ

この機能は、入力イベントの dataTransfer プロパティに insertFromPaste、insertFromDrop、insertReplacementText の inputType を入力します。これにより、contenteditable 要素の編集オペレーション中にクリップボードとドラッグ＆ドロップのデータにアクセスできます。

dataTransfer オブジェクトには、beforeinput イベント中に利用可能だったデータと同じデータが含まれています。

この機能は contenteditable 要素にのみ適用されます。フォームコントロール（textarea、input）の場合、動作は変わりません。data プロパティには挿入されたテキストが含まれ、dataTransfer は null のままです。Safari と Firefox はすでにこの機能をサポートしています。Chrome がこの機能を採用することで、ブラウザ間の相互運用性が向上し、ウェブ作成者にとってより一貫性のあるエクスペリエンスが提供されます。

FedCM - IdP からの構造化 JSON レスポンスのサポート

この機能を使用すると、ID プロバイダ（IdP）は id_assertion_endpoint を介して、プレーン文字列ではなく構造化された JSON オブジェクトを証明書利用者（RP）に返すことができます。

この変更により、JSON 文字列を手動でシリアル化して解析する必要がなくなるため、デベロッパーの統合が簡素化されます。より動的で柔軟な認証フローを提供し、RP が複雑なレスポンスを直接解釈して、帯域外の合意なしで OAuth2、OIDC、IndieAuth などのさまざまなプロトコルをサポートできるようにします。

WebTransport アプリケーションプロトコルネゴシエーション

WebTransport アプリケーションプロトコルネゴシエーションを使用すると、WebTransport ハンドシェイク内でウェブアプリケーションによって使用されるプロトコルをネゴシエートできます。

ウェブアプリケーションは、WebTransport オブジェクトを構築する際に、アプリケーションプロトコルのリストを指定できます。これらのプロトコルは、HTTP ヘッダーを介してサーバーに伝達されます。サーバーがこれらのプロトコルのいずれかを選択した場合、レスポンスヘッダー内でそれを示すことができ、その返信は WebTransport オブジェクト内で利用できます。

独立したウェブアプリ向けの Web Smart Card API

独立したウェブアプリ（IWA）でのみ利用できます。この機能により、スマートカード（PC/SC）アプリケーションをウェブプラットフォームに移行できます。これにより、ホストオペレーティングシステムで利用可能な PC/SC 実装（およびカードリーダードライバ）にアクセスできるようになります。

管理者は、次の 2 つの方法でこの API の利用可否を制御できます。

グローバルに - DefaultSmartCardConnectSetting ポリシーを使用する
アプリ単位 - SmartCardConnectAllowedForUrls ポリシーと SmartCardConnectBlockedForUrls ポリシーを使用する

ウェブアプリマニフェスト: アップデート対象を指定、アイコン URL は Cache-Control: immutable

マニフェスト仕様に、アップデート対象に関するアルゴリズムが含まれるようになりました。これにより、アップデートプロセスがより確定的で予測可能になり、デベロッパーは既存のインストールにアップデートを適用するタイミングをより細かく制御できるようになります。また、ユーザーはアップデートを無視するなど、アップデートの処理方法をより自由に選択できるようになります。また、ユーザーエージェントがネットワークリソースの無駄遣いを避けるために実装する「更新チェックスロットル」を削除することもできます。

リソース消費の多い広告の介入: 埋め込みフレームに送信されるレポート

広告介入レポートが、広告フレーム自体に加えて、広告の埋め込みフレームにも送信されるようになりました。埋め込みフレームに送信されるレポートには、広告 iframe の ID と、レポート本文のメッセージフィールド内でアンロードされたフレームのリダイレクト前の URL が含まれます。この変更により、埋め込みコンテキストで問題のある広告プロバイダを特定し、ユーザーエクスペリエンスを損なう広告に対処できるようになります。

進行中のオリジントライアル

Chrome 143 では、次の新しいオリジントライアルにオプトインできます。

Digital Credentials API（発行のサポート）

この機能により、発行ウェブサイト（大学、政府機関、銀行など）は、デジタル認証情報のプロビジョニング（発行）プロセスをユーザーのモバイルウォレットアプリケーションに直接安全に開始できます。Android では、この機能は Android IdentityCredential CredMan システム（Credential Manager）を使用します。パソコンでは、デジタル認証情報の提示のクロスデバイスフローと同様に、CTAP プロトコルを使用したクロスデバイスアプローチが使用されます。

TCP ソケットプールの上限のランダム化

Chrome の接続プールサイズの制限を悪用することで、通常はアクセスできないクロスサイトの状態に関する情報を取得できます。具体的には、ログイン状態、閲覧履歴、さらには Gmail の受信トレイに未読のメッセージがあるかどうかなど、より具体的な情報を（ある程度の統計的な確実性をもって）評価できます。

この問題を軽減するため、TCP ソケットプールの制限方法にランダム化が追加され、監視サイトがこの情報を高い確実性で推測できないようになっています。

非推奨と削除

このバージョンの Chrome では、次のセクションで非推奨と削除が導入されています。計画されている非推奨、現在の非推奨、以前の削除の一覧については、ChromeStatus.com をご覧ください。

この Chrome のリリースでは、2 つの機能のサポートが終了します

Intl Locale Info のゲッターを非推奨にする

Intl Locale Info API は、ステージ 3 の ECMAScript TC39 プロポーザルであり、週のデータ（週の最初の日、週末の開始日、週末の終了日、最初の週の最小日数）や、ロケールで使用されるテキストの向きと時間のサイクルなどのロケール情報を公開することで、Intl.Locale オブジェクトを改善します。

この実装は Chrome 99 でリリースされました。しかし、その後、プロポーザルのステージ 3 で変更が加えられ、いくつかのゲッターが関数に移動されました。非推奨のゲッターを削除し、名前変更された関数をあらためてリリースする必要があります。

XSLT を非推奨にする

XSLT v1.0 は、すべてのブラウザが準拠しているもので、1999 年に標準化されました。その間、XSLT は v2.0 と v3.0 に進化し、機能が追加され、ブラウザに実装されているバージョンとは異なるものになりました。この進歩の欠如と、柔軟で強力な DOM 操作を提供する JavaScript ライブラリとフレームワークの台頭により、クライアントサイドの XSLT の使用は大幅に減少しました。JSON や React などの JavaScript ベースのテクノロジーが、ウェブブラウザ内でのその役割をほぼ完全に置き換えています。

Chromium は libxslt ライブラリを使用してこれらの変換を処理しますが、libxslt は 2025 年に約 6 か月間メンテナンスされていませんでした。Libxslt は複雑で古い C コードベースであり、バッファオーバーフローなどのメモリ安全性の脆弱性の影響を受けやすく、任意のコード実行につながる可能性があります。クライアントサイドの XSLT は現在、ほとんど使用されないニッチな機能であるため、これらのライブラリはコア JavaScript エンジンよりもメンテナンスやセキュリティの精査が少なくなっています。ただし、信頼できないウェブコンテンツを処理するための直接的な攻撃対象領域となります。実際、XSLT は、ブラウザユーザーを危険にさらし続けている最近のいくつかの大規模なセキュリティエクスプロイトの原因となっています。

これらの理由から、Chromium はウェブプラットフォームから XSLT を非推奨にして削除する予定です。WHATWG は XSLT の非推奨化を進めることを決定しました。

サポート終了の詳細と、XSLT を使用している場合の対応については、より安全なブラウザのために XSLT を削除をご覧ください。

Chrome 143 ベータ版 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。