Feed
FeedItem
CampaignFeed
AdGroupFeed
AdGroupAd
call_view
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。（2021 年 1 月 28 日に Chrome 89 がベータ版としてリリースされた時点の情報です）
ヒューマン インターフェース デバイス（HID）には、新しすぎる、古すぎる、あまりにも一般的でないなどの理由で、システムのデバイス ドライバからアクセスできないロングテールなものがあります。WebHID API は、デバイス固有のロジックを JavaScript で実装する方法を提供することで、この問題を解決します。
ヒューマン インターフェース デバイスは、人間からの入力を受け取ったり、人間に対して出力を提供したりします。デバイスには、キーボード、ポインティング デバイス（マウス、タッチスクリーンなど）、ゲームパッドなどがあります。
たとえば、ゲームパッドのサポートにおいては、一般的でない HID デバイスにアクセスできないのは特に苦痛です。ゲームパッドの入出力はうまく標準化されておらず、多くの場合、ウェブブラウザに特定のデバイス向けのカスタム ロジックが必要となります。これはサステナブルでなく、古いデバイスや一般的でないデバイスといったロングテールがサポートされないことになります。
WebHID のオリジン トライアルは終了し、PC 向けの Chrome 89 でデフォルトで有効になります。使用方法については、一般的でない HID デバイスに接続するで確認できます。ウェブのヒューマン インターフェース デバイス : いくつかの簡単な例のデモもご覧ください。
NFC とは少量のデータを転送する近距離無線通信のことで、通常は専用の NFC デバイスとリーダー間の通信に使用します。建物に入るためにバッジをスキャンしたことがある方なら、NFC を使っているかもしれません。
Web NFC を利用すると、ウェブアプリから NFC タグの読み書きができます。これにより、博物館で展示情報を提供する、在庫を管理する、カンファレンスのバッジに情報を登録するなど、ウェブでさまざまな新しいユースケースを実現できるようになります。Web NFC は、Android 版の Chrome 89 でデフォルトで有効になります。
Chrome Dev Summit での Web NFC カードのデモ
NFC の読み書きは簡単なオペレーションで行うことができます。ペイロードの構築や解釈にいくつかの命令が必要になりますが、複雑ではありません。うれしいことに、ウェブで NFC デバイスと連携するという記事もありますので、ぜひご覧ください。実際に試してみることができるいくつかのサンプルもあります。次のようなイメージです。
NFC タグに文字列を書き込む :
if ("NDEFReader" in window) { const ndef = new NDEFReader(); await ndef.write("Hello world!"); }
NFC タグのメッセージをスキャンする :
if ("NDEFReader" in window) { const ndef = new NDEFReader(); await ndef.scan(); ndef.onreading = ({ message }) => { console.log(`Records read from a NFC tag: ${message.records.length}`); }; }
シリアルポートは、データをバイト単位で送受信できる双方向通信インターフェースです。Web Serial API は、この機能をウェブサイトで実現し、マイクロコントローラや 3D プリンタなどのデバイスを制御できるようにします。
教育、趣味、工業の分野では、すでにウェブページから周辺機器を制御しています。その場合、デバイスの制御にはアダプターやドライバのインストールが必要です。Web Serial API は、ウェブサイトと周辺機器の直接通信を可能にすることで、ユーザー エクスペリエンスを改善します。
Web Serial API のオリジン トライアルが終了し、PC で有効になります。GitHub でデモが公開されています。使用方法については、シリアルポートの読み書きを行うをご覧ください。
デベロッパーは、ユーザーがソーシャル ネットワークで簡単にコンテンツを共有できるようにするため、各ソーシャル サービス用の共有ボタンを手動でサイトに組み込んでいます。このため、ユーザーが実際に使っているサービスで共有できないことが多く、ページサイズの肥大化やサードパーティ製コードによるセキュリティ リスクも発生しています。受信側では、共有ターゲットとして登録して他のアプリからの共有を受け取ることができるのは、プラットフォームのアプリのみです。
Android 版の Chrome では、Chrome 61 から 75 の間でこれらの機能の追加を始めました。Chrome 89 では、ウェブ共有が Windows と ChromeOS でも利用できるようになります。ただし、共有ターゲットとしての登録は ChromeOS のみでサポートされます。これらのプラットフォームでは、PC のサイトで navigator.share() を使うと、共有ダイアログ ボックスを開くことができます。また、ウェブアプリ マニフェストのエントリを追加すると、PWA を共有ターゲットにすることができます。
navigator.share()
ウェブ共有についての情報は、Web Share API で OS の共有 UI を組み込むをご覧ください。PWA を共有ターゲットにすることについての詳しい情報は、Web Share Target API で共有データを受け取るをご覧ください。
このバージョンの Chrome には、新しいオリジン トライアルはありません。現在のオリジン トライアルに登録するには、オリジン トライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。
Chrome が AVIF コンテンツのデコードをネイティブにサポートします。Android と WebView は既存の AV1 デコーダを利用します（PC 版でのサポートは、Chrome 85 で追加されました）。AVIF は次世代の画像フォーマットで、Alliance for Open Media が標準化しています。AVIF のサポートには、主に 3 つの目的があります。
新しい Reporting API は、Cross-Origin Opener Policy (COOP) のデプロイに役立ちます。この API は、COOP が強制される際の違反の報告に加え、COOP の報告のみのモードも提供します。COOP の報告のみのモードは COOP を強制しませんが、COOP を強制していれば発生していた潜在的な違反を報告します。デベロッパーは、Chrome DevTools で Reporting API が有効になっているかを確認できます。
ウェブアプリ マニフェストに display_override フィールドが新しく追加されます。これにより、デベロッパーが display フィールドのフォールバック チェーンを明示的に指定できるようになります。次の例では、"minimal-ui" を "standalone" にフォールバックする指定をしています。
display_override
display
"minimal-ui"
"standalone"
{ "display": "standalone", "display_override": ["minimal-ui"], }
この API は、高度なユースケースと表示モードを想定したもので、機能は限られています。詳しくは、Chrome Status のエントリをご覧ください。
Chrome は、他の ReadableStream 関連のクラスと同じように、グローバル オブジェクトで ReadableStreamDefaultController インターフェースを公開します。これにより、インスタンスをストリームのコンストラクタの内部で作成しなければならないという、これまでの制限がなくなります。
ReadableStreamDefaultController
この機能により、ウェブページのメモリ使用量を見積もる performance.measureUserAgentSpecificMemory() 関数が追加されます。このメソッドは COOP/COEP の制限を受けるので、これを使うにはウェブサイトがクロスオリジン分離されている必要があります。
performance.measureUserAgentSpecificMemory()
現在のウェブ標準に準拠するため、Chrome はすべての data: URL を潜在的に信頼できるものとして扱います。 これは、認証や機密性に関して最低限の基準しか満たされていない場合でも、ある機能を有効化するためには、URL が安全かどうかを評価しなければならないことがあるためです。ウェブ標準は、それを実現するために「潜在的に信頼できる URL」の定義を使いますが、最新版の Secure Contexts 仕様では、そこに "data" スキームの URL が含まれています。これまでの Blink は、いくつかの data: URL のみを潜在的に信頼できるものとして扱っていました。
ストリーム API では、データ ストリームの作成、構成、使用のためのユビキタスで相互運用可能なプリミティブが提供されます。Chrome は、バイトを表すストリームで拡張バージョンの読み取り可能ストリームをサポートし、バイトを効率的に扱います。具体的には、コピーの回数を最低限にとどめます。
バイト ストリームは、Bring Your Own Buffer（BYOB）のリーダーを取得できます。デフォルトの実装では、ウェブソケットの場合は文字列や配列バッファなどのさまざまな種類の出力を指定できますが、バイト ストリームではバイト出力が保証されます。さらに、BYOB リーダーを扱えることで、安定性のメリットももたらされます。バッファがデタッチされれば、同じバッファに 2 回書き込まれないことが保証され、競合状態を回避できるためです。BYOB リーダーではバッファが再利用されるため、読み取りのたびにガベージ コレクションを行う必要もありません。
Chrome の SVG 要素で 'filter' プロパティの完全な構文が利用できるようになります。これまでは、1 つの url() 参照しかサポートされませんでした。これにより、blur()、sepia()、grayscale() などのフィルタ関数を SVG 要素と非 SVG 要素の両方に適用できるようになります。また、'filter' のプラットフォーム サポートの均一性が増し、一部の「定型」エフェクトを適用しやすくなります。この機能がないときは、grayscale() や blur() といった基本的なフィルタを使う場合でも、SVG の完全な <filter> 要素定義を使う必要がありました。
'filter'
url()
blur()
sepia()
grayscale()
<filter>
Chrome で Web Authentication API に関連する 2 つの新機能がサポートされます。AuthenticatorSelectionCriteria.residentKey プロパティは、ウェブ認証のクレデンシャル登録において、クライアント側で検出可能なクレデンシャルを作成するかどうかを指定します。
AuthenticatorSelectionCriteria.residentKey
Web Authentication の credProps エクステンションは、作成したクレデンシャルがクライアント側で検出可能（discoverable）かどうかをリライング パーティに示します。「クライアント側で検出可能なクレデンシャル」とは、WebAuthn API リクエストでリライング パーティがクレデンシャル ID を提供することなくチャレンジを行えるタイプの WebAuthn クレデンシャルです。ブラウザは、指定された認証器（外部セキュリティ キーか組み込みのもの）からのすべての検出可能なクレデンシャル（discoverable credentials）のリストを表示し、ユーザーがログインに使うものを選択できるようにします。
credProps
scroll-to-text フラグメントにデフォルトのユーザー エージェントのハイライトとは違うスタイルを設定できるようにするため、ハイライト疑似要素を追加します。
scroll-to-text
フロー関連の角丸プロパティで、物理プロパティではなく論理マッピングを使って角を制御できるようになります。これにより、ページの向きや表記の方向によって異なる角丸の半径を設定することも可能になります。また、Chrome が CSS Logical Properties and Values 仕様に準拠することになります。以下の論理プロパティが追加されました。
border-start-start-radius
border-start-end-radius
border-end-start-radius
border-end-end-radius
forced-colors メディア機能は、ページでユーザーが選択した限定カラーパレットをユーザー エージェントが強制しているかどうかを検出します。
forced-colors
forced-color-adjust プロパティを使うと、強制カラーモードから特定の要素を除外し、CSS で完全にカラーを制御する状態に戻すことができます。
forced-color-adjust
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 8.9 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
Chrome では、JavaScript モジュールのトップレベルで await キーワードが許可されるようになりました。これにより、モジュールの読み込み処理に非同期呼び出しをシームレスに統合できるようになります。現在のところ、この機能はモジュールを async 関数でラップすることで実現していますが、これにより複雑さを依存モジュール側にとどめつつ、実装の詳細を公開しています。
await
クロスオリジン画像の向きの判定に常に EXIF 情報が利用されるようになります。つまり、CSS で image-orientation: none を設定しても、安全でないオリジンの画像には反映されなくなります。この仕様変更に関する議論は、CSS ワーキング グループ ドラフトに記載されています。
image-orientation: none
このバージョンの Chrome では、以下のサポートの終了および機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
<link rel=prerender> から発行されるレガシーなプレフィックス付きイベント（webkitprerenderstart、webkitprerenderstop、webkitprerenderload、webkitprerenderdomcontentloaded）が Chrome から削除されます。
<link rel=prerender>
webkitprerenderstart
webkitprerenderstop
webkitprerenderload
webkitprerenderdomcontentloaded
ウィンドウを noopener で開いた場合、Chrome はオープン元の sessionStorage を複製しなくなります。代わりに、空の sessionStorage 名前空間が開始されます。これにより、Chrome が HTML 仕様に準拠します。
sessionStorage
CampaignError.HEC_AGREEMENT_REQUIRED
Customers with Housing, Employment, or Credit ads must accept updated personalized ads policy to continue creating campaigns
CampaignError.UNKNOWN
CampaignService.OperationAccessDenied
ReportDefinitionError.INVALID_FIELD_NAME_FOR_REPORT
AdsApp.report
ConversionAdjustment
ConversionAdjustmentLagBucket
ConversionAttributionEventType
ConversionCategoryName
ConversionLagBucket
ConversionTrackerId
ConversionTypeName
AllConversionRate
ConversionRate
CostPerAllConversion
CostPerConversion
CostPerCurrentModelAttributedConversion
ReportDefinitionService.getReportFields
exclusiveFields
パスワードはオンライン情報の保護に役立ちます。パスワードを安全に保つことが何よりも重要なのはそのためです。しかし、ショッピングやエンターテイメントから個人の金融取引まで、さまざまなウェブサイトで数十個（場合によっては数百個）のパスワードを扱うとなれば、常に新しいアカウントの設定や管理に追われているように感じます。もちろん、アカウントごとに強固で一意なパスワードを設定することがベスト プラクティスではありますが、それらすべてを記憶しておくのは難しいことかもしれません。そこで、皆さんをサポートするため、Chrome にパスワード マネージャーを設けています。
スマートフォンやコンピュータ、タブレットでウェブをブラウズするとき、Chrome なら、1 クリックでパスワードを作成、記憶、自動入力できます。サイトにログインした後、パスワードが侵害されていた場合は警告が表示されます。また、Chrome の設定から常に自分でチェックすることもできます。そして、うれしいお知らせがあります。新しいアップデートにより、パスワードをさらに細かく管理できるようになりました。
脆弱なパスワードを簡単に修正
皆さんもきっと、急いで新しいログインを設定したくて、単純な「ペットの名前」のようなパスワードを設定してしまったことがあるはずです。しかし、脆弱なパスワードはセキュリティのリスクとなるので、避けるべきです。Chrome 88 では、シンプルなチェックで脆弱なパスワードを見つけて、簡単に対応できるようになります。
パスワードをチェックするには、プロフィール画像の下にある鍵アイコンをクリックするか、アドレスバーに chrome://settings/passwords と入力する
Chrome には、ウェブサイトにログインする際に保存済みのパスワードの更新を促す機能がすでに組み込まれています。しかし、1 か所で複数のユーザー名とパスワードを簡単にアップデートできれば便利だと思う方もいるでしょう。そこで、PC 版と iOS 版の Chrome 88 より、Chrome の設定からすべてのパスワードをすばやく簡単に管理できるようにします（Chrome の Android アプリも近日中に対応予定）。
2020 年の改善に続いて
今回の新たなアップデートは、昨年行われたたくさんの改善が土台になっており、そのすべてが、オンラインの安全性を向上させ、ウェブのブラウズをさらに簡単にするために貢献しています。
パスワードを安全に保つため、ぜひ新しいアップデートを利用しましょう。2021 年もすばらしいパスワード機能が登場する予定なので、ご期待ください。
AMP コミュニティから特に多く寄せられている要望の 1 つは、高パフォーマンスな AMP コンポーネントを AMP 以外のページでも利用できるようにすることです。AMP Project はこの要望に対処するため、2 年にわたって Bento AMP と呼ばれる取り組みを懸命に進めてきました。その具体的な目的は、完全な AMP ランタイムを使わなくても、AMP コンポーネントがもたらすパフォーマンスとユーザー エクスペリエンスのメリットを活用できるようにすることです。今日のデベロッパー プレビューのリリースにより、その実現に向けて 1 歩前進したことをお知らせします。Bento コンポーネントを試してみたい方は、スタートガイドをご覧ください。
AMP Project の目的は、常にユーザー ファーストな体験を作れるようにデベロッパーをサポートすることにあります。この価値提案の中核にあるのは、高パフォーマンスでユーザー中心の AMP コンポーネントです。今回、Bento AMP によって、必要な場所で AMP コンポーネントを使えるようになります。お気に入りのフレームワークや CMS と AMP コンポーネントを組み合わせることができるのです。
たとえば、カルーセルを AMP 以外のページに追加する、有効な AMP を作成する過程で AMP コンポーネントをテストするなど、1 回限りのケースで Bento コンポーネントを使うことができます。Bento AMP プロジェクトの最新の進捗状況は、GitHub のワーキング グループで確認できます。または、AMP の次の展開をご覧ください。
現在のリリースは、いくつかのスタンドアロン AMP コンポーネントのデベロッパー プレビューです。その目的は、今回の実装の技術的な成否に関するフィードバックを集めることです。現在の Bento AMP コンポーネントにはまだ AMP ランタイムが必要ですが、コンポーネントはページが「有効な AMP」でなくても動作します。つまり、ページにスタンドアロン AMP コンポーネントをインポートし、必要に応じて他のカスタム JavaScript と連携できます。
始めるにあたっては、まずこちらのガイドをお読みください。今回のデベロッパー プレビューの期間中は、以下の Bento コンポーネントを試験運用版として利用できます。
なお、これはデベロッパー プレビューなので、AMP ページで Bento コンポーネントを利用すると、ページは有効でなくなります。この点は、正式版をリリースする際には対応したいと考えています。デベロッパーの皆さんからフィードバックを集めるため、これら最初の Bento AMP コンポーネントを提供できるのはうれしいことですが、Bento コンポーネントのデベロッパー プレビュー期間中に AMP エクスペリエンスをデプロイする場合は、最新の本番バージョンの AMP コンポーネントを使って有効な AMP ページを作成することをお勧めします。
将来的には、完全版をリリースして Bento コンポーネントをすべての HTML ドキュメントで利用できるようにする予定です。それにより、高パフォーマンスなコンポーネントを使ってすばらしいページ エクスペリエンスを作成できるようになります。そのための変更は今年中に行う予定なので、ご期待ください。
その次は、React バージョンの Bento コンポーネントを npm パッケージとして公開することも計画しています。これにより、React アプリが Bento AMP コンポーネントをさらに簡単に使えるようになります。
Bento AMP コンポーネントを試してみたい方は、スタートガイドをご覧ください。AMP チームは、GitHub や Slack チャンネルからフィードバックを送ることを推奨しています。フィードバックは大歓迎です。ぜひご協力ください。質問や問題がある方も、遠慮なくご連絡ください。
投稿者 : Naina Raisinghani（AMP Project、プロダクト マネージャー）
