支払いアプリを開発しているデベロッパーの方は、Android でネイティブ支払いハンドラとして連携させる方法Payment Handler API を通してウェブベースの支払いハンドラとして連携させる方法に記載されているチュートリアルをご覧ください。


Chrome のウェブ支払いの実装についてフィードバックがある方は、[email protected] からご連絡ください。ウェブ支払い API の仕様に関するフィードバックがある方は、W3C Web Payments Working Group までご連絡ください。


Reviewed by Eiji Kitamura - Developer Relations Team


Google Play l Indie Games Festival 2020  に多数ご応募いただきありがとうございました。
厳正なる審査により以下の 20 作品が選出されました。入賞されたみなさま、おめでとうございます!

Google Play Indie Games Festival 2020 トップ 20 : 

※(五十音順、敬称略)




ぜひトップ 20 作品をダウンロードして、あなたのお気に入りのゲームを見つけてみてください。各ゲームの感想や応援コメントを投稿される際はハッシュタグ #IndieGamesFestival をご活用ください。

※オンラインによる トップ 20 へのユーザー投票は、本年は実施しません。

Google Play | Indie Games Festival 2020 ファイナルイベントについて:


更新:ファイナルイベントは、参加いただく皆さまと関係者の安全を最優先として検討を重ねた結果、一般公開での開催は見送ることといたしました。これにともなう審査員と賞品についての変更は後日改めてご案内します。今後、一般公開のイベントはございませんが、審査員が、トップ 20 作品に選出されたデベロッパーの皆さまによるプレゼンテーション、質疑応答や試遊などを通し、厳正なる審査を行い、結果を発表します。ご案内までもうしばらくお待ち下さい。


皆さまが安心してご参加いただけることを最優先とし、4 月 25 日(土)に予定していたファイナルイベントの開催を延期いたします。

ファイナルイベントでは、トップ 20 作品に選出されたデベロッパーのプレゼンテーションや試遊などを元に、審査員がトップ 3 を選出する予定となっています。今後のスケジュール等、決まり次第、ウェブサイトならびに本ブログでお知らせします。 Twitter : #IndieGamesFestival 


Posted by Hidenori Fujii - Google Play Developer Marketing APAC



この記事では、位置情報データと様々な知見を用いてビジネスを支援するために、Google がどのように画像を使って世界各地をマッピングする際の課題を克服しているかについて説明します。

Google が画像や信頼のおける第三者機関から提供されるデータ、機械学習、ローカルガイドなどのコミュニティーから寄せられる情報を融合し、変化し続ける世界を継続的に地図化していることを以前ご紹介しました。しかし、信頼のおけるデータソースなど、前述の主な要素のうちの 1 つが欠けている場合はどう対処しているのでしょうか?また、従来の地図作成手法では対応が難しい、急成長する都市の場合はどうすれば良いでしょうか? 道路が狭く、ストリートビューの車が進入できず、地図データの収集ができない場合はどうすれば良いでしょうか? 世界を地図化するという終わりのない試みの中で、Google はマッピングに関する数多くの困難に直面してきました。その解決にあたって 1 つ変わらないことは、常に画像が解決策の基盤にある、ということです。

画像を用いて、成長する都市をマッピングする

世界の一部の地域では、未だに基本の道路や建物が地図化されていません。基本的なマッピングのための情報を得るのに地方政府や組織といった信頼のおける機関のデータソースが参照できないためです。そのような状況では、文字通り草の根的に地図を作成することになり、マッピングのための情報を抽出できるような画像を入手することから開始します。Google が使用する画像には、大きく分けて以下の 2 種類あります。

衛星や飛行機から撮影した空撮画像には、道路や建物が写っています。一方、道路目線で撮った画像からは、道路の名称、道路標識、建物の番号、企業の名称などの情報が得られます。以前の記事では、画像から自動的に情報を抽出して利用者のために地図データを更新するのに、機械学習を活用していると述べました。このことが、ナイジェリアのラゴスの地図を大幅に改善するための基礎としてどう役立ったか、また、Google Maps Platform を使う現地企業にとって、それが何を意味するかを見てみましょう。

地域の必要な画像を収集した後、ほんの数ヶ月で、機械学習に基づく複数のパイプラインを用いて、地図の主な構成要素を迅速に更新することができました(従来のマッピングプロセスでは、はるかに長い期間がかかっていました)。Google は、次の 3 つのディープラーニングに基づく方法に注目しました : 建物の輪郭線を描く、家屋の数を特定する、企業の場所を認識する。建物を構成する画素単位の細部に頼るばかりではなく、空撮画像から分かる建物の形状についての大まかな特性も考慮に入れるよう訓練されたモデルを使って、建物の詳細な輪郭線を描き出しました。

建物の番号と企業を特定するために、こちらの論文で議論されている継続的作業に基づいて、検出、分類、抽出という 3 つの部分で構成されるアプローチを取りました。これら 2 つのアルゴリズムは、高解像度のストリートビュー画像を入力情報として受けとります。6 自由度でこれらの画像を正確に再現して配置できることが、住宅または企業のポジションを完全なものにするために不可欠でした。その結果、約 1 年(2017 年から 2018 年にかけて)で、ラゴスにおける Google マップのデータ品質を、制作に長い年月を費やした他の国々の地図と同水準になるまで改善することができました。

2012 年から 2018 年にかけての、ナイジェリアのラゴスで地図に登録された建物数(ピンク)と POI(緑)を改善

多くの人々にとって、企業やその他の場所を見つけようとする際に、間違った住所になっていることは小さな困りごとでしかないかもしれません。しかし企業主にとって、これは事業機会の喪失を意味します。 また、ラゴスで献血者からの血液を病院の患者に届けるビジネスを手がけるライフバンクにとっては、生死に関わる問題になり得ます。2016 年、創立者のテミエ ギワ・トゥボサンは、Google Maps Platform を使って、ラゴス全域の 52 の血液銀行と提携して、血液保管所の位置が分かる地図をベースとしたオンライン システムを立ち上げました。このシステムを使って、医師は必要な血液型を入力し、地図にアクセスして配達経路を直ちに割り出すことができます。

ライフバンクのアプリ、ナイジェリアのラゴスで血液銀行、医師、運転手をつなぐ

ライフバンクができる前は、適合した血液を見つけて患者に輸血するまでに数時間、場合によっては数日かかることもありました。しかしライフバンクは、最初の要求から最終的な配達に至るまでの、血液輸送に要する時間をわずか 45 分に短縮して、状況は一変しました。チームは 5,800 名の献血者を登録、15,000 点以上の輸血用血液を 300 以上の病院に輸送して、4,000 人以上の命を救いました。テミエにとって、正確なマッピング情報にアクセスできることは、母国ナイジェリアにおける血液危機を解決するための重要な要因だったのです。

ストリートビュー用三輪バイクで狭い道をマッピング


インドネシアのような国では、自動車は通れないが、同国で普及している二輪車なら通行できる狭い道路があります。Google マップにバイク用の経路案内を導入し、ライドシェアで使う顧客用に二輪車用のナビゲーション ソリューションを提供するために、狭い道路の地図も作成する必要がありましたが、当時の Google のストリートビュー車は大きすぎました。そこで、乗務員の安全と現地の法規制を考慮して車輛を選んだ結果、トレッカーを三輪バイクに取り付ける方法で、狭い道路のマッピングを開始しました。

インドネシアで狭い道のマッピングに使われた「ストリートビュー三輪バイク」 

自動車が通行できない地区や、交通量の少ない辺鄙な場所でのマッピング プロジェクトでも、三輪バイクによって地図作成が可能となり、規模も拡張して行えるようになりました。そのため、インドネシアで二輪車向けの経路案内サービスを展開するのに必要な、狭い道路の道路目線からの画像を収集し、地域の地図の質を向上することが可能となりました。インドネシアでのサービス開始後、他の 21 か国でも二輪車向けの経路案内サービスを提供してきました。

以上のように、画像は Google の地図の基礎であり、世界各地での地図作成に関わる問題を解決しています。しかし、今回の記事は、画像に関して Google が解決した中の、ほんのいくつかの課題について述べたにすぎません。画像は、現実世界を理解するための素晴らしいリソースであり、Google は、たとえ地図作成が困難な地域であっても、個人に新たな発見をもたらし、企業がサービスを立ち上げ拡大することを支援するために画像を収集し活用する多くの創造的な方法を持っています。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカル アカウントマネージャ


このたび、初の本格的リリースとなる、Google Maps Android Utility Library のバージョン 1.0(オープンソース)が入手可能となりました。Maven から最新バージョンをダウンロードいただけます。

Maps Android Utility Library は 2013 年に、Maps SDK for Android に含まれていなかった追加機能を提供するためのプロジェクトとしてスタートしました。SDK を肥大化させないために、これらの機能は SDK 本体には含めず、追加のライブラリとして提供する方針でした。Maps SDK for Android は現状でも、マーカー表示、グラウンドオーバーレイ、地図上に図形を描画する機能など、数種類のカスタマイズ用オプションを提供しています。Maps Android Utility Library では、今後、長期的にアプリの要件が変わっても、これらの機能をさらに拡張することができます。

例えば、このユーティリティ ライブラリを使えば、地図上におけるマーカーのクラスタ化やカスタマイズ、ヒートマップ作成などが行えます。



ライブラリが提供する全機能のリストは、こちらのドキュメントをご覧ください。

バージョン 1.0 の新しい機能


バージョン 0.6.2 のリリース以降、Google は今回のマイルストンまでに全部で 57 の課題とプルリクエストを解決し、ライブラリの改良に努めてきました。安定性の問題にも取り組み、KML レイヤーのいくつかのバグも修正しました。今回のバージョン 1.0 で新たにできるようになったことは、例えば以下のことです :
  • 地図上に複数のレイヤーを表示し、インタラクティブに使用する
  • クラスター内のアイテムを更新する
  • KMZ のデータタイプを処理する
本バージョンには前バージョンから大幅に変更された部分がありますので、アップデートする前に、変更履歴を必ずご確認ください。

今後について


Android 向け開発のための主要プログラミング言語として Kotlin を利用する開発者が増えています。そこで、現在、このライブラリのために Kotlin と親和性のある拡張機能(KTX 拡張機能) を開発中です。これらの拡張機能が使用可能となると、Maps API 上で、簡潔で自然な Kotlin 言語を使ってコーディングすることができるようになります。特に気に入っている Kotlin の使いやすい機能が、ネームドパラメータと初期値を使用できるという点です。例えば、Java 言語で GeoJsonLayer のインスタンスを作成すると以下のようになります :

  GeoJsonLayer layer = new GeoJsonLayer(
    map,
    geoJsonFile,
    null,
    polygonManager,
    null,
    groundOverlayManager
);


上の短いコード群を読むだけでは、2 つの null が何を表しているのかを推測するのが困難です。Kotlin の拡張機能を使えば、同じコードを以下のように書けます :

  val layer = GeoJsonLayer(
    map = map,
    geoJsonFile = geoJsonFile,
    polygonManager = polygonManager,
    groundOverlayManager = groundOverlayManager
)


これは、Kotlin のほんの手始めに過ぎません。本リリース以降は、オープンに開発をしていく予定です。進捗状況はこちらでご確認ください。さらに、プルリクエストをお送りいただければ幸いです。

フィードバックをお待ちしています


バージョン 1.0 は、このライブラリを実際に使用して、問題点や改善して欲しい点を指摘していただいた開発者の皆さんの意見を参考に開発されました。彼らのおかげで今回のリリースが可能になりました。 ライブラリを使用して、問題点を見つけた場合、あるいは、機能追加に関するご提案については、問題を報告するにご記入の上、送信されるか、プルリクエストをお送りください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカル アカウントマネージャ



Google Cloud では 2020 年 4 月 27 日(月)、ゲーム業界で活躍するインフラ エンジニア、サーバーアプリケーション エンジニア、テクニカル リーダーを対象に「第 10 回 Google Cloud INSIDE Games & Apps Online」を開催します。

第 10 回目は ”GKE&Cloud Spanner 勉強会 応用編 ” をテーマに、GKE や Cloud Spanner を導入済みの、ゲーム業界で活躍するデベロッパーを対象に開催します。

* 本イベントは、新型コロナウイルス感染症の発生状況を鑑み、オンライン開催を予定しています。

開催概要
  • 名 称:第 10 回 Google Cloud INSIDE Games & Apps Online
  • 会 期: 2020 年 4 月 27 日 (月)  18 : 00 - 20 : 35 
  • 主 催: グーグル・クラウド・ジャパン合同会社
  • プログラム
    • 18:00–18:05 オープニング
    • 18:05–18:50 セッション 1: GKE に飛んでくるトラフィックを自由自在に操る力
    • 18:55–19:40 セッション 2 : Google Cloud Game Servers 徹底入門
    • 19:45–20:30 セッション 3 : アプリ開発者、DB 管理者視点での Cloud Spanner 活用方法
    • 20:30–20:35 クロージング
詳細・参加申し込み:https://goo.gle/2xzPPNc


※ 競合他社様からのお申し込みはお断りさせていただくことがございます。
※ ビジネス向けのイベントとなっております。学生の方のご参加はご遠慮いただいております。
※ お申し込み多数の場合は抽選をする予定です。参加可否については後日ご登録いただいたメールアドレスまでご案内をお送りさせいだきます。




Posted by Takuo Suzuki - Developer Relations Team


多くの地理的な情報を使いやすい形式で表示したい場合、多くの方は地図を使用するでしょう。しかし、その地図は一目で全体像を伝達することができ、ユーザーにもっと探索したいという気持ちにするような分かりやすいものでなければなりません。

密集した何百ものマーカー(ポイントデータ)がマップを分かりにくくしている場合もあります。この記事では、JavaScript の Marker Clusterer ライブラリを使用して、マーカーが重複することなく全体として同じ情報を伝える方法をご紹介します。また、皆さんのプロジェクトで、マーカークラスタリングを調整する方法をより理解できるように、どのように機能するかについてもご紹介します。

マーカークラスタリングが必要な理由  

オーストラリアとニュージーランドにプロットされた一群のマーカーを見てみましょう。


それぞれのマーカーには便利なラベルが付いていますが、その多くが密集しており、マーカーが重なってしまっています。マーカーは 25 か所もないのですが、あまりに距離が近いため、マップ上で重なることなく表示することができません。

このように表示されていると、表示しようとしているすべての重要な情報をユーザーは理解できないかもしれません。そこでマーカークラスタリングの出番です。シンプルなオープンソース ライブラリでマップ コードを少し変更することで、マーカークラスタリングを追加してユーザー エクスペリエンスを大きく改善することができます。


マーカークラスタリング は、視覚的にマーカーを統合するのに便利なツールで、マップ上の近接するマーカーを組み合わせてクラスタ化することで、見る人がマップ全体を理解しやすくなります。クラスタはひとつのアイコンとしてマップ上に表示されます。

マーカークラスタリングを有効にするには


数行の JavaScript のコードを加えるだけでマップ上にクラスタを追加することができます。ここでは web マップを中心に説明しますが、Google Maps Platform の Maps SDK for AndroidMaps SDK for iOS にもよく似たユーティリティがあります。はじめに、マーカー クラスタを作成するために、クラスタ化されていないマーカーを作成する方法を見てみましょう。マップ上に典型的なマーカーを追加する場合、コードは次のようになります。

const pos1 = {lat: -33.727111, lng: 150.371124};
const marker1 = new google.maps.Marker({position: pos1, map: map});
const pos2 = {lat: -33.718234, lng: 150.363181};
const marker2 = new google.maps.Marker({position: pos2, map: map});


数十以上のマーカーがある場合、マーカーごとに変数を作成することはまずはしないでしょう。しかし、クラスタリングの動作を確認するのであればこの 2 つのマーカーだけで十分です。

マーカークラスタリングを有効にするために、マップ コードに 以下の 2 つ追加する必要があります。まず、MarkerClusterer ライブラリを読み込みます。商用目的で使うのであれば、GitHub からソースコードをダウンロードして自社のサーバー上で JavaScript をホストしてください。今回のデモでは、Google Maps Platform ドキュメント サイトから読み込みます。

 <script src="https://developers.google.com/maps/documentation/javascript/examples/markerclusterer/markerclusterer.js">


次に、マップとマーカーをクラスタリング ライブラリに渡し、マーカー変数の下に次のコードを追加します。

  // すべてのマーカーの配列を作る
const markers = [marker1, marker2]; 

// 追加するクラスターアイコンへのパスを定義する (1.png, 2.png, ...)
const imagePath = "https://developers.google.com/maps/documentation/javascript/examples/markerclusterer/m";

// マップとマーカーに対してクラスター化を有効にする
const markerClusterer = new MarkerClusterer(map, markers, {imagePath: imagePath});


繰り返しますが、商用で使う場合は、自社のサーバーでクラスタ画像をホストする必要があります。この例では、最小のクラスタだけが必要なので、m1.png を読み込みます。

MarkerClusterer のインスタンスを作成する場合、マップの変数、マーカーの配列と、画像パスを渡します。その情報から、MarkerClusterer ライブラリは、クラスタに含まれているポイントの数を数えてクラスタ アイコンに変換し表示します。


クラスタ アイコンをクリックするとマップが 2 つのマーカーが見えるレベルまで拡大されます。


いくつかのレベルでズームアウトすると、クラスタ アイコンは、2 つのマーカーが重なるレベルで元の場所に戻ります。


より多くのポイントを対象とした例については、マーカークラスタリング ガイドをご覧ください。または、マーカークラスタリングが機能する方法とご自身のプロジェクトのために調整できるオプションについての詳細をご覧ください。

マーカークラスタリングはどのように動くのか

マーカークラスタリング ライブラリは GitHub のオープンソース マップ ユーティリティの一部です。すべてのコードにアクセスでき、必要に応じて変更することもできます。アルゴリズムが機能する高度な方法を見てみましょう。

はじめに、アルゴリズムはマップをグリッドに分割します。それぞれのグリッドのセクションはデフォルトの 60x60 ピクセルです。上述の密集したマーカーの例を使うと、次のように見えるでしょう。


実際は、マーカーに基づくので、グリッドは上記のとおりではありません。一つ目のマーカーは最初のセクターの中央になります。セクター内にある次のマーカーは、そのセクターのクラスタに追加されます。クラスタの中央はそのすべてのマーカーの平均に基づいてアップデートされます。1 つのマーカーが複数のクラスタに含まれる可能性がある場合、マーカーの座標間の距離に基づいていちばん近いクラスタに追加されます。

デフォルトの設定とアルゴリズムはほとんどのユースケースに対応しますが、コードは完全にオープン ソースなので、必要に応じてどのようにでも変更できます。

マーカー クラスタをカスタマイズ

マーカー クラスタの見た目と機能を調整する方法はたくさんあります。その多くは基本となるライブラリを編集する必要はありません。その代わり、クラスタを作成する時に設定できるオプションがいくつかあります。

クラスタ化されたマップを作成する最も簡単な方法は、独自のアイコンを使うことです。単純なクラスタリングの例では、imagePath オプションを使いました。クラスタ ライブラリは、1 から 5 までの番号をパスの末尾に追加し、そのあとにファイルの拡張子が続きます。この拡張子のデフォルトは .png です。imageExtension オプションで別のファイルの種類を使用することができます。マップ上では透明なアイコンが最適に見えることを覚えておいてください。

デフォルトでは、2 つのマーカーがあれば 1 つのクラスタを作成できます。この設定を変更するために、minimumClusterSize オプションを使用することができます。マーカーの数を増やすことで重複しますが、いくつまで重複させるかという限界点を設定することができます。

次に、マーカー クラスタ ライブラリを試す他のオプションをご紹介します。
例えば、次のようにクラスタ ライブラリへの呼び出しをすることで、上記のすべてのオプションを一度に使用することができます。

  // オプションの定義
const clusterOptions = {
  imagePath: "https://developers.google.com/maps/documentation/javascript/examples/markerclusterer/m",
  gridSize: 30,
  zoomOnClick: false,
  maxZoom: 10,
};

// マーカーを管理する Marker Clusterer を追加する
const markerClusterer = new MarkerClusterer(map, markers, clusterOptions);

// クラスターが生成されたあとにスタイルを変更する
const styles = markerClusterer.getStyles();
for (let i=0; i<styles.length; i++) {
  styles[i].textColor = "red";
  styles[i].textSize = 18;
}


上記のオプションをオーストラリアとニュージーランドの例に適用すると、次のようなマップになります。

2 つのことに気づきましたか。より小さなグリッド サイズのため、クラスタの数が増え、数字が赤く、かなり大きくなっています。

クラスタをクリックしても拡大しませんが、手動で拡大することができます。主にマーカーが重なる可能性が低くなるようにグリッドサイズを調整しているため、それぞれのマーカーは以前よりも高速に表示されます。レベル 10(マップはレベル 3 から始まります)まで拡大すると、マーカーがどれだけ近接していてもすべて表示されます。

ここまで、マーカーが密集しているマップからすっきりとクラスタ化されたマップまでをご紹介してきました。この新しい知識を使って、ユーザーに多くのマーカーを表示するマップのより良いエクスペリエンスを提供してください。マーカー クラスタ ライブラリのコードから、さらに多くのカスタマイズの方法を見つけることができます。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカル アカウントマネージャ
Share on Twitter Share on Facebook

Titan Security Key が 10 か国で入手可能に

セキュリティ キーは、公開鍵暗号化を使って ID とログインページの URL を検証するので、たとえ攻撃者がユーザー名やパスワードを知っていたとしても、皆さんのアカウントにアクセスすることはできません。ログインの検証を試みるその他の 2 要素認証(2FA)手法とは異なり、セキュリティ キーは FIDO 標準をサポートしています。FIDO 標準は、自動ボット、大量フィッシング攻撃、標的型フィッシング攻撃に対する最強の保護を提供します。

標的型攻撃に狙われる可能性が高いユーザー(例: 政治キャンペーン チーム、活動家、ジャーナリスト、IT 管理者、重役)には、Titan Security Key を入手して高度な保護プログラム(APP)に登録することを強くお勧めします。アメリカの連邦政治キャンペーン チームに参加している方は、Defending Digital Campaigns を通して無料で Titan Security Key をリクエストでき、APP への登録サポートも受けることができます。一部の国では、企業からの一括注文にも対応しています。

Titan Security Key は、個人用や仕事用の Google アカウント1PasswordBitbucketBitfinexCoinbaseDropboxFacebookGitHubSalesforceStripeTwitter など、FIDO セキュリティ キーによる 2FA をサポートしているすべてのサイトで使うことができます。


Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

Chrome 81 では、ウェブに 2 つの新しい没入型機能が追加されます。どちらの機能も拡張現実をサポートするために設計されています。今回は、Chrome 79 で初めて有効化された WebXR Device API で拡張現実がサポートされます。さらに、現実世界の視野に物体を配置するための API である WebXR Hit Test API のサポートも追加されます。

既にこの新しい API を使ってバーチャル リアリティを作成している方なら、AR を使うために学習しなければならないことはほとんどありません。というのも、幅広い没入型体験を想定した仕様になっているからです。アプリケーションのフローは、どの程度の拡張や仮想化を行うかによらず同一です。単に、物体を作成する際に設定およびリクエストするプロパティが異なるだけです。

WebXR Hit Test API を使うと、現実世界と連動した没入型体験を実現できます。具体的には、カメラの視野を通した現実世界の点に仮想の物体を配置できます。左のイメージは、その例を示した Immersive Web Working Group によるサンプルアプリです。隙間の空いた青い円は、Hit Test API から返された点を示しています。画面をタップすると、そこにヒマワリが配置されます。この新しい API は、ヒットテストの位置と検知された点の向きの両方を取得します。イメージからは、床と壁の両方にヒマワリが配置されていることがわかります。

WebXR Device API をまったく使ったことがない方は、過去の記事、ウェブにバーチャル リアリティがやってくるウェブにバーチャル リアリティがやってくるパート II をご覧ください。WebXR セッションに入ってフレームループを作成する方法をよくご存知の方は、Web AR に関する新しい記事をご覧ください。また、WebXR Hit Test API に関する記事もご覧ください。

オリジン トライアル

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

PointerLock unadjustedMovement

PointerLock を使う際に、スクリプトから未調整かつ無加速のマウス移動データをリクエストできるようになります。unadjustedMovement を true に設定すると、ポインタを移動する際に、基盤となるプラットフォームによるマウスの加速度などの修正が影響しなくなります。

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

長いタスクの buffered フラグ

Chrome 81 では、PerformanceObserver の buffered フラグが更新され、長いタスクがサポートされます。この機能では特に、早い段階で PerformanceObserver を登録したアプリやページで、長いタスクを早い段階で検知する方法が提供されます。

CSS の image-orientation プロパティ

Chrome はデフォルトで、優先するイメージの向きを EXIF メタデータから判断します。デベロッパーは、image-orientation プロパティを設定してこの動作をオーバーライドすることができます。

CSS の色調整: color-scheme

サイトで新しいメタタグと CSS プロパティを使うと、UI 要素をレンダリングする際に、優先カラーパターンに従うようにオプトインできます。これは、フォーム コントロールやスクロールバーなどのデフォルト カラーや、CSS のシステムカラーに使われている値などに適用されます。Chrome 81 では、初期の色と背景色のみに影響します。

grid-template-rows および grid-template-columns の解決された値から暗黙的トラックを除外

grid-template-rows および grid-template-columns解決された値から暗黙的トラックが除外されます。以前は、暗黙的か明示的かを問わず、すべてのトラックが含まれていました。

HTMLAnchorElement の hrefTranslate 属性

HTMLAnchorElement hrefTranslate 属性が追加され、href のリンク先サイトを開いた場合に翻訳を行うユーザー エージェントの翻訳エンジンに関するヒントをページに表示する機能が提供されます。

IntersectionObserver ドキュメント ルート

IntersectionObserver() コンストラクタに 'root' 引数として Document を渡せるようになります。これにより、ドキュメントのスクロールするビューポートとの交差を計算できるようになります。これは主に、iframe 内で実行されるオブザーバーを対象としています。以前は、iframe ドキュメントのスクロールするビューポートとの交差を測定する方法はありませんでした。

フォーム コントロールの最新化

Chrome バージョン 81 では、Windows、ChromeOS、Linux のフォーム コントロールの外見を最新化し、アクセシビリティとタッチのサポートを改善します。(Mac と Android も近日中にサポートする予定です。)これにより、カスタムのフォーム コントロールを構築する必要性が減少します。この変更は、Microsoft と Google の連携による成果です。詳しくは、先日の CDS でのトークまたは MS のブログ投稿をご覧ください。コントロールを詳しく確認したい方は、こちらのページで、変更されるすべての要素のサンプルを見ることができます。

onwebkit{animation,transition}XX ハンドラを GlobalEventHandlers に移行

これまで、onwebkit{animation,transition}XX というプレフィックスのついたハンドラは、Chrome の Window オブジェクトでしか利用できませんでした。仕様で要求されているように、これらは HTMLElementDocument に適用されます。この修正により、Chrome が Gecko および Webkit と一致することになります。

注: この変更の目的は、既存のウェブページでの相互運用性の改善です。これらのハンドラは古いので、新しいページではプレフィックスのないバージョンを使用するようにしてください。

メディア セッションの再生位置状態

メディア セッションにトラッキング再生位置状態のサポートが追加されました。再生位置状態とは、再生速度、長さ、現在の再生時間の組み合わせです。ブラウザでこれを使うと、UI に位置を表示することができます。また、シークを追加することによって、シークやスクラブもサポートできます。コードサンプルとデモは、こちらのサンプルをご覧ください。

SubmitEvent

Chrome が SubmitEvent タイプをサポートします。これは、フォームの送信時にディスパッチされる Event のサブタイプです。SubmitEvent には submitter プロパティがあります。これは、入力データ、formaction 属性、formenctype 属性、formmethod 属性、formtarget 属性などの submitter ボタンの属性を参照しています。

現在、アプリケーションは onsubmitpreventDefault() を呼び出すことで、独自のフォーム送信を行っています。このアプローチには、送信のトリガーとなったボタンが受信イベントに含まれないという制限があります。

WebAudio: ConvolverNode.channelCount と channelCountMode

ConvolverNode で、channelCount に 1 または 2 を設定できるようになりますchannelCountMode には、"explicit" または "clamped-max" を設定できます。これまでは、channelCount を 1 にすること、モードを "explicit" にすることは許可されていませんでした。

このリリースでは、ConvolverNode 機能を一部拡張し、デベロッパーが希望の動作を選択できるようにもしています。希望のミキシングを行うために GainNode を追加する必要はなくなります。

WebRTC

RTCPeerConnection.onicecandidateerror イベントの変更

candidateerror イベントで、hostCandidate に代わって明示的なアドレスとポートが追加されます

RTCDataChannel の onclosing イベント

RTCDataChannel オブジェクトに onclosing イベントが追加されます。このイベントは、相手側がチャンネルのクローズを開始したことをデータ チャンネルのユーザーに伝えます。ユーザー エージェントは、キューが空になるまでキューからの読み取りを継続します(キューが空でない場合)が、それ以上データが送信されることはありません。

共有ワーカー コンストラクタの WorkerOptions

共有ワーカー コンストラクタの第 2 引数に、WorkerOptions オブジェクトが追加されます。これまでの第 2 引数であるワーカーの名前を含む文字列も引き続きサポートされます。

WritableStream.close()

WritableStream オブジェクトに、ストリームがロック解除されている場合にクローズを行う close() メソッドが追加されます。これは、ライターを取得し、そのライターを使ってストリームをクローズし、再度ストリームのロックを解除する操作と直接的に等価です。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 8.1 が組み込まれます。具体的には、以下の変更点が含まれます。最新の変更点のリストをすべて確認したい方は、V8 リリースノートをご覧ください。

Intl.DisplayNames()

Intl.DisplayNames() オブジェクトを使うと、アプリやスクリプトから言語、スクリプト、通貨コード、日付項目やシンボルに一般的に使用される名前について、ローカライズされた名前を取得できます。これにより、アプリサイズの縮小(それによりレイテンシも改善)、国際化 UI コンポーネントを構築する手間の軽減、翻訳のコスト削減、ウェブ全体での一貫性の高い翻訳が可能になります。

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

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

Payment Handler での "basic-card" サポートの終了と削除

このバージョンの Chrome では、iOS Chrome で Payment Request API 用の basic-card polyfill が削除されます。その結果、iOS Chrome で Payment Request API が一時的に無効になります。詳細については、iOS の支払いリクエストを再考するをご覧ください。

BasicCardRequest から supportedType 項目を削除

"basic-card" 支払い方法で "supportedTypes":[type] パラメータを指定すると、そのリクエスト タイプのカードのみを表示します。リクエスト タイプは、"credit"、"debit""prepaid" のいずれかです。

カードタイプ パラメータは仕様から削除されており、今回 Chrome からも削除されます。理由は、カードタイプを正確に判断するのは難しいためです。ブラウザのカードタイプ フィルタは信頼できないので、現在の販売者は PSP にカードタイプを問い合わせる必要があります。

Firefox では、バージョン 65 で "supportedTypes" が削除されました。

<discard> 要素の削除

Chrome 81 では、<discard> 要素が削除されます。これは Chromium のみで実装されているため、相互運用できません。ほとんどのユースケースで、この要素は 'display' プロパティのアニメーションと removal(JavaScript)コールバック/イベント ハンドラの組み合わせに置き換えることができます。

TLS 1.0 と TLS 1.1 の削除

このバージョンの Chrome では、TLS 1.0 と TLS 1.1 が削除されます。TLS(Transport Layer Security)は HTTPS の安全性を保証するプロトコルで、ほぼ 20 年前に作成された TLS 1.0 や、その前身の SSL までさかのぼることができる長い歴史があります。TLS 1.0 と 1.1 には、どちらもたくさんの脆弱性があります。
以上の問題を回避するには、TLS 1.2 をサポートする必要があります。TLS ワーキング グループは、TLS 1.0 と 1.1 を非推奨としています。Chrome では、2019 年初めのバージョン 72 でこれらの機能が非推奨になっています。

TLS 1.3 ダウングレード対策のバイパス

TLS 1.3 には、ダウングレード保護を強化する対策を行った後方互換性が含まれています。しかし、昨年 TLS 1.3 を公開したとき、一部の TLS 終端プロキシとの互換性がないことから、この対策を部分的に無効化する必要がありました。現在の Chrome には、既知のルートにつながる証明書用の強化策が実装されていますが、未知のルートにつながる証明書はバイパスできてしまいます。この強化策は、すべての接続で有効化する予定です。

ダウングレード保護により、互換性のために維持しているさまざまな以前のオプションがセキュリティに与える影響を軽減することができます。つまり、ユーザーの接続は安全になり、セキュリティ脆弱性が発見された際の対応の緊急度は下がります。(これにより、将来的に侵害されるユーザーのサイトの数は少なくなります。)これは RFC 8446 とも一致しています。

Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook