特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 1 月 10 日の時点で Chrome 98 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。 

COLRv1 カラー グラデーション ベクター フォント

このバージョンの Chrome は、新しく追加されたフォント形式として COLRv1 カラー グラデーション ベクター フォントをサポートします。カラーフォントのグリフには複数の色が含まれています。例として、絵文字や国旗、多色文字などが挙げられます。

COLRv1 は COLRv0 フォント形式が進化したもので、ウェブでのカラーフォントの普及を目的としています。COLRv1 フォントは、グラデーション、座標変換、合成などのさまざまな視覚表現に対応しながらも、フォントのサイズはとても小さくなっています。また、COLRv1 フォントは OpenType のバリエーションもサポートしています。フォントのサイズがとても小さいのは、内部形状の再利用とコンパクトなフォント形式定義、効率的な圧縮によるものです。

次のイメージは、Noto Color Emoji の例を示しています。これはビットマップ フォントでは約 9 MB ですが、COLRv1 ベクター フォントでは 1.85 MB しかありません（WOFF2 圧縮後）。

明瞭な COLRv1 ベクター フォント（左）と、ビットマップ フォント（右）の比較。 WOFF2 圧縮後のビットマップ フォントと  COLRv1 フォントとしての Noto Emoji のフォントサイズ。

詳細については、Chrome 98 の COLRv1 カラー グラデーション ベクター フォントをご覧ください。

3 桁のバージョン番号に対する準備

今年中に Chrome のバージョン 100 がリリースされ、ユーザー エージェント文字列で報告されるバージョン番号の桁数が増える予定です。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されました。この新しいフラグ chrome://flags/#force-major-version-to-100 は、Chrome 96 以降で利用できます。詳細については、Chrome の User-Agent 文字列のメジャー バージョンを強制的に 100 にするをご覧ください。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

リージョン キャプチャ

リージョン キャプチャは、自分でキャプチャした動画トラックをクロップするための API です。現在、アプリケーションは、preferCurrentTab の指定の有無にかかわらず、getDisplayMedia() を使ってアプリケーション自体が実行されているタブをキャプチャできます。その際、（通常はリモートに共有する前に）結果の動画トラックをクロップし、コンテンツの一部を削除する場合があります。

今回のリリースに追加されたその他の機能

contain-intrinsic-size に auto キーワードを追加

contain-intrinsic-size に auto キーワードのサポートが追加され、ウェブサイトで最後に記憶した要素のサイズ（存在する場合）が利用できるようになります。これにより、content-visibility: auto が指定された要素よりもユーザー エクスペリエンスが向上します。この機能がない場合、ウェブ デベロッパーは要素がレンダリングされるサイズを推定しなければなりません。この機能と content-visibility: auto を併用すると、要素が飛び回る可能性があります。

AudioContext.outputLatency

新しい AudioContext.outputLatency プロパティは、オーディオ出力のレイテンシを秒単位で推定します。厳密に言えば、これはユーザー エージェントがホストシステムにバッファリングをリクエストした時間から、オーディオ出力デバイスがバッファ内の最初のサンプルを処理した時間までの間隔です。スピーカーやヘッドフォンなど、音響シグナルを生成するデバイスの場合、後者の時間はサンプルのサウンドが生成された時間です。Firefox では、すでにこの機能が実装されています。

CSS の色調整 : color-scheme の 'only' キーワード

color-scheme の仕様に再追加された only キーワードが Chrome でサポートされるようになりました。これにより、特定の単一要素で color-scheme を無効化できるようになります。たとえば、強制的なダーク化を無効化できます。いくつかの例で使い方を示します。

div { color-scheme: light }

これは、div 要素の color-scheme を強制的にダーク以外にします。

div { color-scheme: only light }

これは、上の例と同じく、要素の color-scheme をライトに保ち、ユーザー エージェントによる強制ダーク化を無効にします。

document.adoptedStyleSheets の変更が可能に

仕様に従い、document.adoptedStyleSheets プロパティの変更が可能になります。これにより、push() や pop() などの操作ができるようになります。これまでの adoptedStyleSheets の実装は扱いにくく、たとえばシートを追加する場合、配列全体を代入し直さなければなりませんでした。

document.adoptedStyleSheets = [...adoptedStyleSheets, newSheet];

新しい実装では、同じ操作を次のように行うことができます。

document.adoptedStyleSheets.push(newSheet);

ハイ ダイナミック レンジ カラーのメディアクエリ

Chrome で CSS メディアクエリ 'dynamic-range' と 'video-dynamic-range' がサポートされ、現在のディスプレイ デバイスの HDR サポート状況を検出できるようになります。有効な値は、'standard' と 'high' です。このクエリを使うと、ページで CSS ルールを切り替えたり、Window.matchMedia() を使って変更に対応したりできます。

ポップアップ、タブ、ウィンドウのための新たな window.open() の動作

仕様の更新に伴い、このバージョンの Chrome では window.open() で新しいウィンドウやタブを開くかどうかを指定できるようになります。次の例に新しい構文を示します。1 つ目は、ポップアップ ウィンドウを開きます。2 つ目は、新しいタブまたはウィンドウを開きます。

const popup = window.open('_blank','','popup=1');

const tab = window.open('_blank','','popup=0');

また、window.statusbar.visible が正しい値を返すようになります。具体的には、ポップアップでは false を、タブやウィンドウでは true を返します。

Private Network Access なサブリソースに Preflight リクエスト

サブリソースに対するプライベート ネットワーク リクエストの前に CORS Preflight リクエストが送られ、対象サーバーから明示的なパーミッションを求めるようになります。プライベート ネットワーク リクエストとは、パブリックなウェブサイトからプライベート IP アドレスや localhost へのリクエスト、またはプライベートなウェブサイト（イントラネットなど）から localhost へのリクエストを指します。プリフライト リクエストを送ることで、ルーターなどのプライベート ネットワーク デバイスに対する Cross-Site Request Forgery (CSRF) 攻撃のリスクを緩和できます。多くの場合、プライベート ネットワーク デバイスはこのような脅威から保護されていません。

window と worker の structuredClone() メソッド

window と worker が、オブジェクトをディープコピーする structuredClone() メソッドをサポートします。ディープコピーでは、オブジェクトのプロパティがコピーされますが、その際に別のオブジェクトへの参照を見つけると、自身を再帰的に呼び出してそのオブジェクトもコピーします。これにより、2 つのコードで意図せずにオブジェクトが共有され、知らない間にお互いの状態を変更してしまうことがなくなります。ディープコピーの説明や使い方については、structuredClone による JavaScript のディープコピーをご覧ください。

WebAuthn minPinLength 拡張機能

Chrome で、Web Authentication を通して CTAP 2.1 minPinLength 拡張機能が公開されるようになります。これにより、あらかじめセキュリティ キーが構成されているサイトで、認証システムに設定された最小 PIN 長を知ることができるようになります。

インストールした PC ウェブアプリ向けのウィンドウ コントロール オーバーレイ

インストールした PC ウェブアプリでウィンドウ コントロール オーバーレイが有効になっている場合、アプリのクライアント領域が拡張され、タイトルバー領域を含むウィンドウ全体を覆います。そのため、ウィンドウ コントロール ボタン（閉じる、最大化 / 復元、最小化）はクライアント領域の上に重なって表示されます。ウェブ デベロッパーは、ウィンドウ コントロール オーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされた PC ウェブアプリを OS のアプリのように見せることができます。

WritableStream コントローラーの AbortSignal

WritableStreamDefaultController が signal プロパティをサポートします。このプロパティは、必要に応じて WritableStream 操作を停止できる AbortSignal のインスタンスを返します。ストリーム API では、データ ストリームの作成、構成、使用のためのユビキタスで相互運用可能なプリミティブが提供されます。この変更により、ライターからのリクエストがあったときに、下層のシンクが継続中の書き込み操作を即座に中断したりクローズしたりできるようになります。これまでは、writer.abort() が呼び出されても、時間がかかる書き込み操作が完了してからでないとストリームを中断できませんでした。この変更により、書き込みを即座に中断できるようになります。この機能は、JavaScript で作成したストリームだけでなく、プラットフォームが提供する WebTransport などのストリームでも利用できます。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

WebRTC での SDES 鍵交換の削除

2013 年以降、WebRTC の SDES 鍵交換メカニズムは、関連する IETF 標準で使用禁止と宣言されています。昨年には、Chrome での使用も大幅に減少しました。SDES が削除されるのは、これがセキュリティの問題になっているためです。Javascript にセッションキーが公開されるので、ネゴシエーションの交換にアクセスできるエンティティや Javascript を侵害できるエンティティが、その接続で送信されるメディアを復号化できることになります。

現在、Google Ads API と AdWords API で、SimulationModificationMethod = DEFAULT の広告グループのシミュレーション計算方法を変更する作業を行っています。

変更事項

優先されるキーワードの入札単価がある広告グループに対しては、広告グループのデフォルト入札単価のさまざまな値ごとに異なる推定トラフィックを提供します。現在は、優先される入札単価があるすべてのキーワードが、この推定値から除外されます。そのため、推定トラフィックが予想より少なくなります。

2022 年 1 月 17 日の週より、広告グループのシミュレーション計算方法を変更し、デフォルト入札を使っているキーワードと、優先される入札があるキーワードの両方の推定を含めるようにしました。さらに、シミュレーションにおいて、広告グループのデフォルト入札のみが変わり、優先されるキーワード入札はすべて同じであると仮定します。この内容は、Google Ads API の AdGroupSimulationService サービスに含まれる GetAdGroupSimulation メソッドや、AdWords API の DataService サービスに含まれる getAdGroupBidLandscape メソッドや queryAdGroupBidLandscape メソッドが返すシミュレーションに影響する可能性があります。

必要な対応

この機能をお使いの方は、上記のメソッドが返す結果が変わってもコードが引き続き機能することを確認することをお勧めします。

質問がある方は、Google Ads API フォーラムでお知らせください。

お知らせ : Google Ads（AdWords）API のフィードバックをお送りください。2021 AdWords API と Google Ads API 年次アンケートへの回答をお願いします。

Google は、2 月 21 日より、社会課題をテクノロジーで解決に導くスタートアップを対象とした 3 か月集中型のプログラム 「Google for Startups Accelerator Class 4」を実施します。 このプログラムは Google による技術、組織運営など幅広い分野にわたるトレーニングや個別のメンターシップを提供し、参加企業のさらなる成長を支援します。昨年 9 月 より募集を開始し、多くの素晴らしい目標を持ったスタートアップにご応募を頂き、厳正な選考の結果、本プログラムに下記 8 社のスタートアップが参加します。

参加企業一覧（アルファベット順）

CogSmart : 頭部 MRI 画像などを利用した脳健康測定、BrainSuite プログラムを通じて、「認知症にならない健康脳づくり」「生涯健康脳」の社会的な普及を目指しているヘルスケア サービス (Healthcare / Brain)

Hubble : 契約書の管理・共有をスマートにするリーガルテック SaaS (Legal Tech)

Latona : IoT やエッジコンピューティングの技術を使ったビジネス プラットフォームを開発し、企業に提供することで、ワークプロセスの自動化・生産性の向上を目指しているサービス (AI, ML) 

NearMe : タクシーをシェアしてお得にドアツードア移動できる「相乗り」サービス。NearMe（ニアミー）は、独自の AI によりルーティングを最適化したスマートシャトルなどを展開し、リアルタイムの位置情報を活用して地域活性化に貢献する “瞬間マッチング” プラットフォーム作りを目指している。(Mobility as a Service, Sharing Economy)

PocketMarche : 全国の農家・漁師と直接やり取りしながら旬の食材を購入できる産直アプリ。生産者や地域と継続してつながるふるさと納税サービス。(EC, Marketplace)

Study Valley : 来年度から必修化される探究学習を効率的に行えるようにし、また社会との接点を創出する学習プラットフォーム (Ed Tech)

Tutorial : PC 端末にインストールせず、いつでもどこでも利用できる、クラウド型 RPA Robotic Crowd を提供 (Robotics)

unerry : 月 200 億件超の位置情報ビッグデータを扱う AI プラットフォームを開発・運営 (Geo Location AI)

​​今後の流れ

今後 3 か月に渡って、社会課題解決に特化したセッションをはじめ、機械学習などのテクノロジーに関するセッション、世界の外部メンターや Google 社員によるオンライン メンタリングなどを提供していきます。

プログラムについての詳細は、Google for Startups のページをご参照ください。

背景

ネイティブ ウィンドウ オクルージョンの計算

オクルージョンの計算タイミングの決定

オクルージョンの計算をし続けると、Chrome のパフォーマンスが低下することになるので、それは避けたいことです。つまり、ウィンドウが表示対象またはオクルージョン対象になるタイミングを検知する必要があります。ありがたいことに Windows では、ウィンドウの移動、リサイズ、最大化、最小化などのさまざまなシステム イベントをトラッキングできます。オクルージョン計算スレッドは、これらのイベントを追跡したいことを Windows に伝えます。そしてイベントが通知されると、イベントを精査して新たにオクルージョン計算を行うかどうかを決定します。非常に短い時間内に複数のイベントを受け取る可能性があるため、オクルージョンの計算は 16 ミリ秒に 1 回を超える頻度では行いません。この時間は、フレームレートが 1 秒あたり 60 フレーム（fps）である場合に 1 フレームが表示される時間に対応します。

リッスンするイベントは、ウィンドウのアクティブ化や非アクティブ化、ウィンドウの移動やリサイズ、ユーザーの画面ロックやロック解除、モニターの電源オフなどです。オクルージョンの計算は必要以上に行いたくありませんが、ウィンドウが表示されるイベントを見逃すわけにはいきません。見逃してしまうと、ウェブ コンテンツが表示されるはずの場所が白くなってしまうからです。これは絶妙なバランスです [3]。

リッスンするイベントは、Chrome ウィンドウがオクルージョンされるかどうかに関わるものです。たとえば、マウスを動かすとたくさんのイベントが発生し、カーソルも点滅するたびにイベントを発行しています。そういったイベントはウィンドウ オブジェクトとは関係ないので、無視します。また、ツールチップの表示によってオクルージョンの計算がトリガーされることはないので、大半のポップアップ ウィンドウのイベントも無視します。

オクルージョン スレッドは、さまざまな Windows イベントを検知したいことを Windows に伝えます。UI スレッドは、主要な状態変化（モニターの電源オフ、ユーザーによる画面ロック）が発生した場合にそれを検知したいことを Windows に伝えます。

結果

この機能は、効果を測定する実験と合わせて開発され、2020 年 10 月に M86 リリースの一部としてすべての Chrome Windows ユーザーにロールアウトされました。指標から、この機能をオンにした場合にパフォーマンスが大幅に改善されることがわかります。

• 起動時間が 8.5% から 25.8% 短縮
• GPU メモリ使用量を 3.1% 削減
• レンダラー全体の描画フレーム数を 20.4% 削減
• レンダラーのクラッシュが発生したクライアントが 4.5% 減少
• First Input Delay（初回入力までの遅延時間）が 3.0% 向上
• First Contentful Paint（視覚コンテンツの初期表示時間）と Largest Contentful Paint（最大視覚コンテンツの表示時間）が 6.7% 向上

起動時間と初回入力までの遅延時間が改善したのは、Chrome が起動時に 2 つ以上の全画面ウィンドウを復元する場合、いずれかのウィンドウがオクルージョンされる可能性が高いためです。Chrome はそのウィンドウに関する大半の作業を省略できるので、より重要なフォアグラウンド ウィンドウのためにリソースを節約できます。

すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ。