この記事は Google Maps Platform Product Manager の Alicia Sullivan による Google Cloud Blog の記事 "Announcing Advanced Markers: easily create highly customized, faster performance markers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Maps Platform を初めて使用される場合、まずはマップ上にマーカーを置いてみた人も多いのではないでしょうか。多くの場合、それが Google が持つ現実世界の知見を活用し、世界中のあらゆる場所においてユーザー向けの臨場感あふれる便利なマップ エクスペリエンスの構築を実現するための第一歩となったりします。ユースケースや業界の違い、ウェブ向けなのかモバイル向けなのかにかかわらず、多くの場合、マーカーがマップベースのエクスペリエンスの中核となっています。


この記事は Google Maps Platform Product Manager の Alicia Sullivan による Google Cloud Blog の記事 "Announcing Advanced Markers: easily create highly customized, faster performance markers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Maps Platform を初めて使用される場合、まずはマップ上にマーカーを置いてみた人も多いのではないでしょうか。多くの場合、それが Google が持つ現実世界の知見を活用し、世界中のあらゆる場所においてユーザー向けの臨場感あふれる便利なマップ エクスペリエンスの構築を実現するための第一歩となったりします。ユースケースや業界の違い、ウェブ向けなのかモバイル向けなのかにかかわらず、多くの場合、マーカーがマップベースのエクスペリエンスの中核となっています。

デベロッパー コミュニティから数多く寄せられる要望が、簡単に使用できる高度なマーカー機能でした。このたび、Google Maps Platform チームは皆様の要望にお応えすべく、Maps JavaScript API 用の「高度なマーカー」のプレビュー版をリリースいたします。これにより、高度にカスタマイズされ高速に動作するマーカーの作成が可能となり、上質なユーザー エクスペリエンスの提供、ブランドの紹介、時間とリソースの節約が実現します。

主な機能とユースケース

Google マップの赤いピンのカスタマイズ

デフォルトの赤いピンを簡単にカスタマイズする機能は、デベロッパーからの要望が特に多かった機能です。高度なマーカーの新しい「PinView」クラスでは、画像ではないため、デフォルトのピンの色、背景、アイコン、枠線をコードで直接変更できるようになります。

これにより、さまざまなユースケースが可能となります。小売店は店舗の場所を示すマーカーを、ブランドのカラーに合わせて変更することができます。旅行会社はホテル周辺の施設のカラーやアイコンを変更することで、ユーザーに周囲の環境に基づいて理想のホテルを選んでもらいやすくすることが可能です。また、ロジスティクス企業は、リアルタイムで変化する荷物または車両の状況を反映して、マーカーの色を変更することができます。


Google マップの赤いピンをカスタマイズしたり、SVG などの画像を使って独自のマーカーを作成

施設の場所の色やアイコンを変更するモックアップ


荷物の状態や車両の状態に応じてマーカーの色を変えるモックアップ

マーカーをカスタマイズする際には、アイコンや写真といった自身が保有する画像アセットを使用するという選択肢もあります。これにより、PNG や SVG といった HTML の「img」タグでサポートされた画像ファイルを使用することが可能となります。また、CSS を使用して高度なマーカーを動的にスタイル設定およびアニメーション化して、サイズ、不透明度、ポジション、カラーなどを変更することも可能で、これまで以上に簡単に Google マップへ動的なマーカー エクスペリエンスを追加できるようになります。これにより、たとえば、ロゴやその他のブランド アセットを使用して、ブランディングをより周到にマップに組み込むことができるようになります。

SVG 画像を使って構築され、カスタムでアニメーション化されたマーカーの見本のモックアップ


カスタム マーカーで生み出す、コンテキストに沿ったインタラクティブな体験

カスタマイズした高度なマーカーは、カスタムの HTML 要素を使用することでも作成できます。作成したマーカーは、ユーザーとのインタラクションにも対応し、高い柔軟性を持つ CSS のスタイルにも適用させることが可能です。この機能であれば、これまでは複雑なカスタム オーバーレイを使用しなければ構築が難しかった、美しく、魅力的で、インタラクティブなマーカー エクスペリエンスを生み出すことが可能となります。たとえば、不動産会社の場合は、ユーザーの操作に応じて物件の価格を表示するマーカーを作成でき、それにより、物件の住所、面積、寝室や浴室の数といった追加の有益な情報を表示することができます。


不動産会社が HTML 要素を使用したカスタム マーカーを使って物件の価格を表示する場合のサンプル

デモにアクセスして、ここで紹介したユースケースやその他のユースケースをご確認ください。 

向上したマーカーのパフォーマンスとアクセシビリティ

高度なマーカーは従来型のマーカーよりも 66% 読み込みが速く、より素早いパンやズームを提供します1。また、高度なマーカーでは、大量のマーカーに対する高速な読み込みもサポートしています。

高度なマーカーを使用した 500 のマーカーを含む地図の読み込み、パン、ズーム

さらに数多くのユーザー補助機能の改良も行いました。これにより、スクリーン リーダーやキーボードの操作を活用したユーザー向けのプロダクトを作成することが可能になりました。こうした改良により、ユーザーはマーカーをドラッグ&ドロップで移動するという操作をすべてキーボードで行うことができます。マーカーのタイトルはスクリーン リーダーで自動的に取得され、マーカーはユーザー補助ロールにデフォルト設定されます。

高度なマーカーでは、スクリーン リーダーまたはキーボードの操作を利用したプロダクトの作成が可能


高度なマーカーを使ってみる

高度なマーカーは、最近プレビュー リリースされたデータドリブンのスタイル設定と同様に、Maps JavaScript API 用 Dynamic Maps に組み込まれており、Cloud ベースのマップスタイル設定に最新の機能として追加されています。高度なマーカーの使用の開始と追加の機能についての詳細は、こちらのドキュメントと次の動画をご確認ください。

皆様が、高度なマーカーを活用して、マップ エクスペリエンスの基礎的な部分をどのように再検討されるのかを楽しみにしております。


1 高度なマーカーについて、500 のマーカーを配したマップを使って内部でベンチマーク テストを行いました。実際の結果は、高度なマーカーの構成、アプリケーションの実装、ブラウザ、ハードウェアの仕様などを含むさまざまな要因によって変わります。


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


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer

この記事は Google Maps Platform プロダクト マネージャーの Erika Yamasaki による Google Cloud Blog の記事 "Announcing Routes API: the new enhanced version of the Directions and Distance Matrix APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...

この記事は Google Maps Platform プロダクト マネージャーの Erika Yamasaki による Google Cloud Blog の記事 "Announcing Routes API: the new enhanced version of the Directions and Distance Matrix APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Directions API と Distance Matrix API はこの 10 年以上、A 地点から B 地点までの人やものの移動ルートをすばやく効率的に決定できるよう支援してきました。また、Google はここ数年間、運送業界や物流業界の最大手企業と密接に連携し、モビリティ サービスを通じて、カスタマー エクスペリエンスや配送業務の大規模な改善を支援してきました。Google Maps Platform チームは多くのご要望に応えて、これらの高度なルーティング機能の大半を、利用可能な国のすべての Google Maps Platform デベロッパーに提供しています。

今回、新しい Routes API のプレビュー リリースを発表しました。これは、Directions API と Distance Matrix API の拡張バージョンであり、両 API を 1 つのサービスに統合することで、より有益で柔軟なルートをユーザーに提供できるようになります。

新しい Routes API は、ビジネスにおいて重要な役割を果たしている Directions API と Distance Matrix API の基本機能に基づいて構築されています。たとえば、リアルタイムの交通量を包括的に反映する最新のルートや、複数の出発地と目的地を組み合わせた行列計算から算出される距離や到着予定時刻などです。さらに、より有益で柔軟なルートを提供し、到着予想時刻の精度を向上するために、次のような高度な新機能も備えています。

  • 二輪車(オートバイ)用ルート(利用可能な地域
  • ルートの費用をより正確に算出するための通行料金データ(利用可能な地域
  • ルートの各区間のリアルタイムの交通情報
  • 地点に通過地点と停止地点のいずれかを選択可能
  • レイテンシを低減するためのきめ細かいコントロール
  • 環境に優しいルート選択(年内に提供開始予定)

新しい Routes API はすでにご利用いただくことができます。既存の Directions APIDistance Matrix API にも引き続きアクセスできますが、Routes API では機能が追加され、パフォーマンスも強化されています。この新しい API を使用して何ができるのか、詳しく説明していきます。

より有益で柔軟なルートを提供

二輪車(オートバイ)に対応

世界の多くの地域では、配達からライドシェアリング、日常の移動に至るまで、二輪車が最も一般的な交通手段となっています。新しい Routes API では、二輪車向けのルートや距離行列の計算をリクエストでき、有料道路、高速道路、フェリーの回避、自動車が通れない道を通るルートなど、さまざまな要素が考慮されます。(利用可能な地域はこちらでご確認ください)


二輪車(オートバイ)用ルートと通行料金データの例

通行料金の計算

新しい Routes API では、お客様やお客様のユーザーに重大な経済的影響を与える可能性のある新しい重要なデータ、つまり通行料金の計算にもアクセスできるようになりました。方向と距離行列の両方のリクエストにおいて、通行料金の計算をリクエストし、十分な情報に基づいて時間と費用のトレードオフに関する決定を下せるようになりました。通行料金データでは、車両の種類(EV、ハイブリッドなど)や通行券の種類が考慮されて、ルートの費用がより正確に計算されます。(利用可能な地域はこちらでご確認ください)


通行料金データを使ったルートの例

交通量とポリライン機能の改善

交通量は、消費者にとっても企業にとっても、ルーティングの決定に影響を与える最大の要因の 1 つです。新しい Routes API では、ルート計算で現在の交通量と過去の交通量のどちらを考慮するかを指定できます。また、交通量やポリラインの品質と遅延の間のトレードオフをコントロールすることもできます。

さらに、ルートの各区間の交通情報をリクエストすることもできるため、色分けされたポリラインで交通量を表すなど、より充実したエクスペリエンスをユーザーに提供できます。ポリラインの長さに応じたカスタムカラー、ストローク、パターンをサポートする高度なポリライン スタイルを使用して、地図上でルートのスタイルを設定することもできます。


ルート上の各区間のリアルタイムの交通状況の表示例


きめ細かいコントロールで遅延を短縮

新しい Routes API では、アプリのパフォーマンスを向上するための追加オプションが導入されています。Routes API は、既存の Directions API と Distance Matrix API よりさらにパフォーマンスが高く、総合的な精度と遅延の短縮との間のトレードオフを可能にする機能を備えています。フィールド マスキングを使用すると、API レスポンスで返されるフィールド(到着予定時刻、メートル単位の距離、交通状況など)を選択できます。これにより、レスポンスのペイロードのサイズを抑えてレスポンスを簡素化することができ、簡単に処理できるようになります。

よりスマートかつ柔軟な経由地点(ウェイポイント)で到着予想時刻の精度を向上

新しい Routes API では、よりスマートになったウェイポイントにより、到着予想時刻の精度も向上しています。ルート内の経由地点では、その地点を通過するか停止するかの指定ができるようになり、移動時間の計算がより正確になります。トンネルや高速道路など、停車が安全でない場所にユーザーが誘導されるのを回避できるため、これは特に送迎のユースケースに有効です。さらに、道路のどちら側が適切かをウェイポイントに指定したり、経由地点ごとに車両の現在の進行方向や適切な進行方向を指定できるため、送迎などの際に適切なルート案内が行えます。

停車すると危険なトンネル内でドライバーを停車させるルートの例



トンネルから離れた近くの脇道でドライバーを停車させる中間ウェイポイントの代表的な例


Routes API では、距離行列リクエストの出発地と目的地の数を増やし、出発地と目的地の各上限(25 個)を排除しました。最大で合計 625 個の要素が返されるように設定できるため、柔軟性が大幅に向上しています。

近日提供予定 : 環境に優しいルート選択でより持続可能な選択を可能に

今後数か月以内に、開発者向けに環境に優しいルート選択の提供を開始します。これにより、米国エネルギー省の国立再生可能エネルギー研究所の分析情報と欧州環境機関のデータを使用して、燃料消費を抑えるために最適化されたルートを見つけられるようになります。燃料効率の最も良いルートは、リアルタイムの交通量とエンジンの種類に基づいて決まります。環境に優しいルート選択を使用するドライバーは、エンジンの種類(ガソリン、ガス、ディーゼル、ハイブリッド、電気自動車(EV))を選択することで、最適なルートと、燃料やエネルギー効率の正確な見積もりを取得できます。

たとえば、配送業者やライドシェアリング サービスは、1 回の走行、複数回の走行、保有する車両全体の燃料消費量と節約量を測定できるため、ビジネス パフォーマンスを向上させることが可能です。今後数か月以内に、Google マップ上の利用可能な地域で、環境に優しいルート選択のプレビュー版の提供が開始されます。登録して最新情報を受け取ることができます。


環境に優しいルート選択と燃料節約量の見積もりの例

Routes API は現在プレビュー版のみが提供されており、この期間中のご利用に対してユーザーに課金されることはありません。料金の詳細については、Routes API の一般提供開始時にお知らせします。既存の Directions API と Distance Matrix API の価格に変更はなく、料金ページでご確認いただけます。

ユーザー エクスペリエンスの向上を図っている場合も、現実世界に関する Google の情報を基に、ビジネスにおいてより多くの情報に基づいた正確な意思決定を下すことを目指している場合も、これらの API は、さまざまなユースケースを解決するために必要な機能とパフォーマンスを提供するよう構築されています。

まずは、ドキュメント移行ガイドをご覧ください。実際にお試しいただく場合や、詳細を確認したい場合は、ライブデモをご覧ください。

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


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Team 


Google Maps Platform では、デベロッパーの皆様が革新的な地理空間情報を活用したサービス構築が行えるよう、便利な新機能の継続的な開発や提供に努めています。たとえば、一般ユーザーが毎日使用している Google マップの最新のイノベーションを API として提供したり、ご要望の多い機能をプラットフォームに追加しています。このたび、新しい Routes API で「環境に優しいルート選択」の提供を開始することを発表致します。Google マップのユーザーアプリですでに利用することができる環境に優しいルート選択を使用すると、燃料消費を抑えるように最適化されたルートを選択できます。さらに、世界中のデベロッパーから多くの要望が寄せられた、高度なルート選択、地図のカスタマイズ、住所確認などの新機能も発表します。これらの新機能を使用すると、アカウントの登録時や決済時にユーザーの住所を確認したり、より有益で柔軟なルートをドライバーに提供したり、高度にカスタマイズされたマーカーを作成できるため、ユーザー エクスペリエンスが向上し、業務効率が高まります。

より有益かつ柔軟な、環境に優しいルートの提示

Google はここ数年間、運送業界や物流業界の最大手企業と密接に連携し、モビリティ サービスを通じて、カスタマー エクスペリエンスや配送業務の大規模な改善を支援してきました。このたび多数のご要望にお応えして、これらの高度なルート選択機能の多くを、環境に優しいルート選択とともに、利用可能な国のすべての Google Maps Platform デベロッパー向けにリリースいたします。

環境に優しいルート選択で、より一層サステナブルなナビゲーションと、燃料消費を抑えるための最適化を実現

ドライバーが Google マップで環境に優しいルート選択を利用すると、米国エネルギー省の国立再生可能エネルギー研究所の分析情報と欧州環境機関のデータに基づいて、最も燃料効率が良いルートを見つけることができます。リリース以来、削減してきた二酸化炭素排出量は推定で 50 万トン以上にのぼります。これは、燃料自動車 10 万台分の二酸化炭素排出量削減に相当します。年内には、環境に優しいルート選択をデベロッパー向けに提供開始できる見込みです。


この記事は Google Maps Platform グループ プロダクト マネージャーの Shalin Mantri による Google Cloud Blog の記事 "Announcing new routing, address validation and map customization capabilities" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Maps Platform では、デベロッパーの皆様が革新的な地理空間情報を活用したサービス構築が行えるよう、便利な新機能の継続的な開発や提供に努めています。たとえば、一般ユーザーが毎日使用している Google マップの最新のイノベーションを API として提供したり、ご要望の多い機能をプラットフォームに追加しています。このたび、新しい Routes API で「環境に優しいルート選択」の提供を開始することを発表致します。Google マップのユーザーアプリですでに利用することができる環境に優しいルート選択を使用すると、燃料消費を抑えるように最適化されたルートを選択できます。さらに、世界中のデベロッパーから多くの要望が寄せられた、高度なルート選択、地図のカスタマイズ、住所確認などの新機能も発表します。これらの新機能を使用すると、アカウントの登録時や決済時にユーザーの住所を確認したり、より有益で柔軟なルートをドライバーに提供したり、高度にカスタマイズされたマーカーを作成できるため、ユーザー エクスペリエンスが向上し、業務効率が高まります。

より有益かつ柔軟な、環境に優しいルートの提示

Google はここ数年間、運送業界や物流業界の最大手企業と密接に連携し、モビリティ サービスを通じて、カスタマー エクスペリエンスや配送業務の大規模な改善を支援してきました。このたび多数のご要望にお応えして、これらの高度なルート選択機能の多くを、環境に優しいルート選択とともに、利用可能な国のすべての Google Maps Platform デベロッパー向けにリリースいたします。

環境に優しいルート選択で、より一層サステナブルなナビゲーションと、燃料消費を抑えるための最適化を実現

ドライバーが Google マップで環境に優しいルート選択を利用すると、米国エネルギー省の国立再生可能エネルギー研究所の分析情報と欧州環境機関のデータに基づいて、最も燃料効率が良いルートを見つけることができます。リリース以来、削減してきた二酸化炭素排出量は推定で 50 万トン以上にのぼります。これは、燃料自動車 10 万台分の二酸化炭素排出量削減に相当します。年内には、環境に優しいルート選択をデベロッパー向けに提供開始できる見込みです。

これにより、環境に優しいルート選択を有効にするオプションを製品やアプリに組み込んで、燃料消費の節約に貢献できるようになります。エンジンの種類を選択し、リアルタイムの交通情報を有効にすると、環境に優しいルート選択を使用した場合の燃料効率やエネルギー効率を、最も正確に見積もることができます。たとえば、配送業者やライドシェアリング サービスは、燃料消費量と節約量を 1 回の走行、複数回の走行、あるいは保有する車両全体で測定して、業績の向上につなげられます。

環境に優しいルート選択は、Google マップですでに利用可能となっている場所で、数か月以内にプレビュー版の提供が開始されます。登録すると最新情報を受け取ることができます。

環境に優しいルート選択と燃料節約量の見積もりの例を示すサンプル


新しい Routes API でより有益かつ柔軟なルートを提供

今回、さらに、新しい Routes API のプレビュー リリースを発表します。これは、Directions API と Distance Matrix API のパフォーマンスを最適化したバージョンであり、デベロッパーはより有益で柔軟なルートをユーザーに提供できるようになります。

新しい Routes API は、ビジネスにおいて重要な役割を果たしている Directions API と Distance Matrix API の基本機能に基づいて構築されています。たとえば、リアルタイムの交通量を反映する最新のルートや、複数の出発地と目的地を組み合わせた複雑な行列計算から算出される距離や到着予定時刻などの機能です。さらに、より有益で柔軟なルートを提供し、到着予想時刻の精度を向上するために、次のような高度な新機能も備えています。

  • ルートの費用をより正確に算出するための通行料金データ(利用可能な地域

  • ルートのリアルタイムの交通状況の可視化

  • 地点に通過地点と停止地点のいずれかを選択可能

  • レイテンシを低減するためのきめ細かいコントロール

  • 環境に優しいルート選択(年内に提供予定)

新しい Routes API は、プレビュー版で提供を開始しました。この新しい API の機能と利点について詳しくは、プロダクトのブログをご覧ください。

オートバイ用ルートと通行料金データの例を示すサンプル


Address Validation でアカウント登録、決済、配送を改善

住所は、人や場所を見つけるだけではなく、商品を配達し、銀行口座を開設するためにも必要なものです。しかし、無効な住所データは、ビジネスの時間や費用の浪費につながることがあります。最近の調査では、オンライン注文での住所の誤字や脱字は、その大半が住所確認ツールを導入していれば回避できていたことが明らかになっています1。この問題を解決するため、無効な住所入力の検出に役立つ新しい API、Address Validation の提供を開始します。Address Validation は、住所の構成要素の特定、エラーの修正、住所に不足しているデータの補完によって、注文のキャンセル、カスタマー サポート チケットの発行、払い戻しを防ぐためのツールです。これには、グローバルに収集されている Google Maps Platform のプレイスデータ、Google が蓄積している幅広い地域の住所情報、広範囲の住所が網羅されている米国内の郵便データが活用されています。Address Validation を導入すると、アカウント登録や決済がスムーズになるため、ユーザー エクスペリエンスが向上し、ビジネスの時間や費用を節約できます。

Address Validation は、今後数か月以内に一部の市場で一般提供が開始される予定です。登録すると最新情報を受け取ることができます。

Address Validation が住所の構成要素を識別し、住所が存在することを確認

「高度なマーカー」で独自のマーカーを作成

デフォルトの赤いピンをコード内で簡単にカスタマイズする機能と、SVG 要素と HTML 要素を使用してカスタム マーカーを作成する機能は、いずれもデベロッパーからの要望が特に多かった機能です。このたび、このオプションを備えた Maps JavaScript API 用の「高度なマーカー」のプレビュー リリースを発表いたします。 

高度なマーカーを使用すると、Google マップの赤いピンを簡単にカスタマイズできます。デフォルトのピンの色、背景、アイコン、枠線をコードで直接変更でき、画像は必要ありません。SVG を直接的にサポートしているため、ブランドのロゴなどの画像を使用してカスタム マーカーを作成できます。また、CSS を最大限に活用して、ユーザーの操作に反応する HTML 要素を使用したカスタム マーカーを作成できます。たとえば、不動産業の場合は、ユーザーの操作に応じて住宅価格を表示するマーカーを作成できます。高度なマーカーを使うと、作業効率も向上します。読み込みが速くなり、パンやズームがよりスムーズになるうえ、豊富な種類のマーカーを高速で読み込んでお使いいただけます。


カスタム HTML 要素を使用して作成された高度なマーカーのサンプル


高度なマーカーは、最近プレビュー リリースしたデータドリブンのスタイル設定と同様に、Maps JavaScript API 用 Dynamic Maps に組み込まれており、クラウドベースのマップのスタイル設定に最新の機能として追加されています。JavaScript 用の高度なマーカーは、数週間後にプレビュー版の提供が開始される予定です。登録すると最新情報を受け取ることができます。

Google は、デベロッパーの皆様が Google Maps Platform を使用して構築する、現実世界を体現したクリエイティブで革新的な地理空間サービスから、絶えず新しい着想をいただいています。今後も皆様からのフィードバックに耳を傾け、優れた体験を実現するために必要な機能を提供できるよう、尽力してまいります。新しい機能の提供開始に関する最新情報を受け取るには、こちらからご登録ください。皆様が構築されるサービスを楽しみにしております。

1 Baymard: "Have an address validator"(住所確認ツールを利用する)


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


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer 


この記事は シニア テクニカル プログラム マネージャーの Patrick Callahan による Google Cloud Blog の記事 "New Google Maps Platform launch stages and what they mean for you" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーは信頼性と予測可能性を期待しています。そこで Google は、お客様のアプリケーションを支える Google Maps Platform サービスの背景にある信頼度に関するコミットメント情報をみなさんが簡単に特定できるようにしたいと思っています。一貫したリリース ステージは、お客様が使用しているプロダクトや機能の能力、サポート、運用準備状況をお知らせします。このたび、リリースステージを、「試験運用版」、「プレビュー」、「一般提供」に更新しました。これらのリリース ステージの名称は、お客様のニーズに応じていつ新しいプロダクトや機能を試すかを決定する際に役立ちます。

この記事は シニア テクニカル プログラム マネージャーの Patrick Callahan による Google Cloud Blog の記事 "New Google Maps Platform launch stages and what they mean for you" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーは信頼性と予測可能性を期待しています。そこで Google は、お客様のアプリケーションを支える Google Maps Platform サービスの背景にある信頼度に関するコミットメント情報をみなさんが簡単に特定できるようにしたいと思っています。一貫したリリース ステージは、お客様が使用しているプロダクトや機能の能力、サポート、運用準備状況をお知らせします。このたび、リリースステージを、「試験運用版」、「プレビュー」、「一般提供」に更新しました。これらのリリース ステージの名称は、お客様のニーズに応じていつ新しいプロダクトや機能を試すかを決定する際に役立ちます。

米国時間 9 月 24 日より、Google Maps Platform のすべての新機能は「試験運用版」、「プレビュー」、「一般提供」のそれぞれのステージでリリースされます。詳細は、リリース ステージのドキュメントをご覧ください。まず、試験運用版のプロダクトは、プロトタイプに対するお客様からのフィードバックを得ることに重点を置いています。プレビューでは、プロダクトまたは機能のテストと評価ができます。プレビュー リリースでは、本番環境に適用する前にコードの更新や統合テストを行う目的で設定されています。一般提供の状態では、安定したサービスとなっており、本番環境で使用する準備ができた状態で、サービスレベル目標やサービスレベル契約に基づいたサポートを提供します。なお、それぞれのステージで、同様のプロダクトや機能が利用できるとは限りません。国、業種、その他の要因で、制限されたカスタマー グループでのみ利用可能な場合がありますので、あらかじめご確認の上ご利用ください。

この更新が、Google Maps Platform での構築のお役に立てれば幸いです。

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


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer

この記事は Chrome Developers Blog の記事 "Chrome 107 beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
この記事は Chrome Developers Blog の記事 "Chrome 107 beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

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

 CSS grid-template プロパティ補間

CSS グリッドの grid-template-columns プロパティと grid-template-rows プロパティを使うと、行の名前を定義してグリッドの列と行のサイズを追跡できます。Microsoft の貢献者の皆様のおかげで、上記のプロパティで補間がサポートされました。グリッドのレイアウトが複数の状態間をスムーズに遷移できるようになり、アニメーションや遷移が途中で中断することはなくなります。

 プライバシー保護に対応した画面共有制御

Screen Capture API で既存の Media Capture と Streams API に追加機能が導入され、ユーザーが画面やその一部(ウィンドウなど)を選択してメディア ストリームとしてキャプチャできるようになります。このストリームは、記録したり、ネットワークを経由してほかのユーザーと共有したりできます。今回のベータ版では、この API にいくつかの新機能が追加されます。

Screen Capture API の詳細については、MDN ガイドの 画面キャプチャ API の使用をご覧ください。

 DisplayMediaStreamConstraints.selfBrowserSurface

ヒントを使うと、getDisplayMedia() を呼び出す際に、ウェブ アプリケーションがユーザーに提示するタブの一覧から現在のタブを除外するかどうかをブラウザに指示できます。

これにより、ユーザーがアプリを実行しているタブを意図せずに選択し、自分自身がキャプチャされることを防ぎます。そのため、映像がループする現象が起きて、ユーザーが混乱したり、リモートユーザーとの議論が中断されたりすることはなくなります。

 DisplayMediaStreamConstraints.surfaceSwitching

Chrome で画面共有をしているときに、タブ切り替えボタンを表示するかどうかをプログラムで制御するオプションを追加します。このオプションは、navigator.mediaDevices.getDisplayMedia() に渡します。

[Share this tab instead] ボタンを使うと、ユーザーは共有するタブをシームレスに切り替えることができます。ビデオ会議タブを再選択し、ボタンをクリックして再度 getDisplayMedia() を開始したり、多くのタブが表示される一覧から新しいタブを選択したりする必要はありません。すべてのウェブ アプリケーションがこの動作に対応しているわけではないので、この動作は条件に応じて公開されます。

 MediaTrackConstraintSet.displaySurface

getDisplayMedia() を呼び出すと、ブラウザでタブ、ウィンドウ、モニターといったディスプレイ サーフェスを選択する画面がユーザーに提示されます。displaySurface 定数を使ってウェブ アプリケーションからブラウザにヒントを与えると、特定の種類のサーフェスを優先的に提示できます。

以上の機能は、意図しない画面共有を防ぐうえで役立ちます。詳しくはこちらで説明しています。

 Resource Timing のレンダリング ブロック状態

PerfomanceResourceTiming に、リソースのレンダリングのブロック状態を示すフィールドを追加します。現在、デベロッパーが実際にレンダリングのブロックが起きているリソースを知りたい場合、複雑な経験則を使用するしかありません。この新しいフィールドから、これを直接把握できるようになります。

 権限ポリシー オリジンのワイルドカード

この機能により、権限ポリシーでワイルドカードがサポートされます。たとえば、SCHEME://*.HOST:PORT(https://*.foo.com/ など)のような構造です。この場合、有効なオリジンは SCHEME://HOST:PORT(https://foo.com/など)から構築されます。HOST は少なくとも eTLD+1(登録可能なドメイン)である必要があります。つまり、https://*.bar.foo.com/ は指定できますが、https://*.com/ は指定できません。スキーム部とポート部のワイルドカード指定はサポートされません。また、https://*.foo.com/ には https://foo.com/ は含まれません。これまで、権限ポリシーは次のようになっている必要がありました。

permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://cdn1.foo.com" "https://cdn2.foo.com")   

この機能が導入されたことで、次のようにすることができます。

permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://*.foo.com")   

 <form> 要素が rel 属性をサポート

この機能はフォーム要素に rel 属性を追加します。これにより、rel=noopener が指定されているフォーム要素から開くウェブサイトで window.opener が利用できなくなります。また、rel=noreferrer を使ってリファラー ヘッダーが送られることを防ぐこともできます。

 オリジン トライアル

今回のリリースの Chrome には、2 つの新しいオリジン トライアルが含まれています。

 Declarative PendingBeacon API

これはステートフル ビーコン API の 1 つで、ビーコンの送信タイミングをブラウザで制御できるようにします。 ビーコン とは、特定のレスポンスを求めずにバックエンド サーバーに送信するデータの集まりを指します。ユーザーがページを訪問し終わった後にこのデータを送信したいというニーズは多いものの、"send" 呼び出しをする適切なタイミングがありません。この API は、送信処理をブラウザ自身に委譲するので、ページがアンロードされたときやページが非表示になったときのビーコンをサポートでき、デベロッパーがそのタイミングで送信処理を実装する必要はなくなります。

このトライアルは、Chrome 109 まで行われる予定です。トライアルへの登録はこちらから行うことができます

 Permissions-Policy: unload

この機能を使うと、ページで unload イベント ハンドラが実行できなくなります。この機能の目的は、すべての unload ハンドラを削除したサイトで、意図しないハンドラが新しく追加されないようにすることです。この機能はサイトを unload イベント ハンドラを使わないように移行する際に活用でき、BFCache のヒット率改善につながります。

このトライアルは、Chrome 109 まで行われる予定です。トライアルへの登録はこちらから行うことができます

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

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

今回の Chrome のリリースでは、1 つの機能のサポートが終了します。

 Expect-CT

Expect-CT HTTP ヘッダーは、デフォルトで Certificate Transparency が必須化される前に、ウェブサイトがこれをオプトインできるようにします。また、報告機能も提供されるので、デベロッパーが CT の設定ミスを見つけるうえでも役立ちます。

Expect-CT HTTP ヘッダーは、Certificate Transparency(CT)の必須化に向けた移行に役立つように設計されました。具体的には、すべての公開ウェブサイトで CT が必須化される(Chrome により)前に、高価値なウェブサイトが CT の必須化をオプトインしたり、高いセキュリティに対応していることを報告したりできるようにするものでした。ただし、Expect-CT はすでに存在意義を失っています。現在の Chrome では、すべての公開サイトで CT が必須になっているので、すでに Expect-CT は必要ありません。Expect-CT は他のブラウザでも実装されていないので、これを削除しても互換性の問題は発生しません。


この記事は Calder Kitagawa による Chromium Blog の記事 "Speeding up Chrome on Android Startup with Freeze Dried Tabs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Chrome のパフォーマンスを向上するという点では、「これで十分」ということは決してありません。今回の速さと好奇心の投稿では、Android 版 Chrome の起動時間を 20% 以上高速化した方法に迫ります。これは、起動時にタブのインタラクティブなフリーズドライ プレビューを表示することで実現しました。以降では、スクリーンショットでは何が不十分なのか、なぜタブをフリーズドライすることが優れたブラウザにつながるのかについて説明します。

背景と目的

ウェブ コンテンツのレンダリングにはときに重い計算処理が必要で、ネイティブ アプリケーションよりも遅く感じられることがあります。ネットワークから動的にリソースを読み込んだり、JavaScript を実行したり、CSS やフォントなどをレンダリングしたりするには、たくさんの作業が必要です。この問題はモバイル デバイスで特に顕著で、デバイスのメモリが制約となり、Chrome が一度に少数のウェブページしか読み込めないこともよくあります。

この記事は Calder Kitagawa による Chromium Blog の記事 "Speeding up Chrome on Android Startup with Freeze Dried Tabs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Chrome のパフォーマンスを向上するという点では、「これで十分」ということは決してありません。今回の速さと好奇心の投稿では、Android 版 Chrome の起動時間を 20% 以上高速化した方法に迫ります。これは、起動時にタブのインタラクティブなフリーズドライ プレビューを表示することで実現しました。以降では、スクリーンショットでは何が不十分なのか、なぜタブをフリーズドライすることが優れたブラウザにつながるのかについて説明します。

背景と目的

ウェブ コンテンツのレンダリングにはときに重い計算処理が必要で、ネイティブ アプリケーションよりも遅く感じられることがあります。ネットワークから動的にリソースを読み込んだり、JavaScript を実行したり、CSS やフォントなどをレンダリングしたりするには、たくさんの作業が必要です。この問題はモバイル デバイスで特に顕著で、デバイスのメモリが制約となり、Chrome が一度に少数のウェブページしか読み込めないこともよくあります。

ここから生じるのが、必要に迫られた場合(タブ スイッチャーのような一時的な UI や、たくさんのウォームアップ作業が行われる起動時など)に、ウェブ コンテンツを軽量に表現する方法はないかという疑問です。これを行う標準的な手法はスクリーンショットです。スクリーンショットは見た目を正確に表現できるので、ユーザーは何が開いているかを一目で理解できます。しかし、スクリーンショットは最後に表示したものしか表現できず、完全に静的なので、ウェブページよりも制限が強くなります。

この一時的なウェブ コンテンツのイメージがより便利でインタラクティブになり、本物のページが準備できるまで待つ間に利用できるならどうでしょうか。

ケーススタディ : コールド スタート時に高速にウェブ コンテンツを表示する

Android 版 Chrome アプリのコールド スタートは高価で、起動してからウェブページの描画を始めるまでの時間(First Contentful Paint / FCP)の中央値は 3.4 秒です。ページの HTML、CSS、JS、フォントを処理するにはたくさんの作業が必要なので、他のアプリと比べると遅く感じられるかもしれません。

しかし、起動時にインタラクティブなページのスナップショットを表示できたとしたらどうでしょうか。

このスナップショットを、フリーズドライ タブと呼びます。これは実際のウェブページからさまざまな機能を取り除いたものですが、十分な内容とインタラクティブ性を持ち合わせているため、静的なスクリーンショットよりも有用です。スクリーンショットに欠けていた重要な要素は、リンクを開いたり、ページのコンテンツをスクロールしてビューポート外の内容(iframe も含む)を見たりする機能です。

フリーズドライ タブは、このすべての機能に加えて、ほかの機能も実現できます。実際のウェブページよりも速く起動し、完全なページが準備できるまでの間にもコンテンツを利用できるように、十分な機能を提供します。ページが読み込まれると、自動的かつシームレスにそのページに切り替わります。

テストの結果、フリーズドライ タブを使うことで、起動してからページのすべてのコンテンツを描画するまでの時間の中央値が 2.8 秒まで短縮できました(通常の描画を始める場合に比べて最大 20% 高速)。すべてのコンテンツが表示され、ほとんどの場合、レイアウトのずれも起こらないので、一層速く感じられます。

フリーズドライ タブによる起動時間の分散の変化

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


フリーズドライ タブの詳細

ウェブページをフリーズドライするため、ページの視覚的な状態を一連のベクター グラフィックとしてキャプチャします。その際に、すべてのハイパーリンクも取得します。後に、そのベクター グラフィックを単純にラスタライズし、軽量な形で「再構築」(再生)します。これにより、完全なウェブページ(ビューポートの外側のコンテンツも含む)を表示するレンダリング コストを省きつつ、ハイパーリンクをサポートできます。

この形式には、スクリーンショットよりも多くのメリットがありますが、ウェブページのすべての機能が利用できるわけではありません。そのため、私たちは、実際のページを読み込むには少し時間がかかるときに、スクリーンショットよりもインタラクティブな表示をしたい場合は、この形式で一時的な表示をするのが最適な方法であると考えています。

*Android P を実行する Pixel 2 XL をエミュレーションした推定値。

1 ユーティリティ プロセスは 30 MB のオーバーヘッド(最大平均 10 MB のコンテンツと 20 MB のビットマップ)


技術開発における主な課題

この技術を構築できたことは、興味深くやりがいのある経験でした。特に難しいのは、iframe のコンテンツを集約すること、サブフレームのスクロールをサポートすること、すべてのジオメトリを扱うことです。

しかし、最も興味深い挑戦はパフォーマンスでした。

キャプチャ

ページをキャプチャするときにコンテンツを保存するのは単純な作業です。CSS でスタイル設定した DOM のジオメトリは簡単にベクター グラフィックに変換でき、ベクター グラフィックは小さくて、保存が簡単です。

ページのイメージをこの形式で保存するのも単純ですが、高解像度のイメージはサイズが大きくて(0.1~10 MB)圧縮も O(100 ms) と遅く、MB 単位のメモリのオーバーヘッドもかかります。そのため、イメージをそのままデフォルトのエンコードで保存するのが通例ですが、イメージが大きくなると対応できない場合があります。

フォントは、内包する各グリフの描画方法を記述したファイルです。中国語のように文字の種類が多い言語や、絵文字のようにイメージで構成されている場合、フォント ファイルのサイズは特に大きくなります。英語フォントは 1 つあたり 100 kB 程度のものが多いですが、絵文字のフォントは簡単に数 MB に達します。ページには複数のフォントが埋め込まれていることが多く、そういったフォントはローカル システムに保存されないため、キャプチャするデータの一部として保存しなければなりません。初期テストでは、見た目を完全に再現できるように、ページで使われているすべてのフォントを保存しようとしました。しかし、この方法で保存すると、ページによっては 100 MB ほどのサイズになることがありました。パフォーマンスとストレージの観点から考えて、これは受け入れられません。

この難題を克服するため、フォントのサブセット化に注目しました。サブセット化とは、フォント ファイルからすべての未使用グリフを取り除くことです。これにより、ページに必要なフォントのみがデータに残ります。すると、100 MB だったページはわずか 400 kB(元のサイズの 1% 未満)になりました。


再生

もう 1 つの難題は、再生のパフォーマンスを妥当な範囲に保つことでした。ベクター グラフィックを表示するには、ラスタライズしてビットマップにしなければなりません。しかし、現在のスマートフォンの画面は 1 ピクセルあたり 32 ビットなので、コンテンツのビューポート 1 つでも容易に 10 MB を超えてしまいます。このビットマップのメモリ オーバーヘッドを減らすため、ユーザーがスクロールする際に動的にビットマップを生成するようにしました。

もう少し詳しく説明しましょう。ページのコンテンツは、ビューポートよりも小さなタイルに分割します。そして、ビューポートに現在含まれるすべてのタイルのビットマップを生成するとともに、スムーズなスクロールを実現するため、ビューポートの周囲にあるタイルをプリフェッチします。ビューポート外のビットマップを実際に表示するまで圧縮する実験をしたところ、10 MB からわずか 100 kB ほどまでメモリを節約できる可能性があることがわかりました。しかし、さらにパフォーマンス データを収集したところ、圧縮によって CPU に追加のオーバーヘッドがかかるため、ブラウザのジャンクや [FID] などが大幅に増加することがわかりました。そこで、この動作は削除し、タイルを小さくしてビューポート外のビットマップを積極的に破棄できるようにしました。

まとめ

フリーズドライ タブは、スクリーンショットに替わるものとして魅力的な選択肢です。一時的な表示や、すぐにウェブ コンテンツを準備できず、それが利用できるようになるまで待つ時間が長い場合には特に有効です。また、スクリーンショットよりも再現性に優れているほか、リンクやスクロールなど、ウェブページと同じように動作する便利なユーザー操作も可能です。

現在、Android 版の Chrome で使われているフリーズドライ タブによって、コールド スタートで 20% という体感可能な高速化が実現されています。この技術を他の場所で使うことも検討しています。



Posted by Eiji Kitamura - Developer Relations Team

今回、コミュニティ主催のイベントでは、 サーバーレス、コンテナ を中心としたラボを扱います。本プログラム参加者は、Google Cloud Skills Boost (以下、Skills Boost )を 30 日間無料で利用できます。


プログラム 概要

  • プログラム期間 : 2022 年 10 月 12 日 ~ 11 月 9 日
  • オンボーディング セッション : 2022 年 10 月 26 日(水)15:00 - 16:00
    (アーカイブでも視聴可能)※

  • お申し込み : https://cloudonair.withgoogle.com/events/try-together-1012

  • 対象 : Google Cloud を学びたい大学生以上の方

  • 費用 : 無料

  • 実施方法 : オンライン

2022 年 6 月に実施いたしましたプログラムが大変好評でしたため、第 2 弾の実施が決定いたしました。本プログラムは、学習ツール「Google Cloud Skills Boost」を使って Google Cloud をコミュニティと一緒に学ぶ、無料のプログラムです。

今回、コミュニティ主催のイベントでは、 サーバーレス、コンテナ を中心としたラボを扱います。本プログラム参加者は、Google Cloud Skills Boost (以下、Skills Boost )を 30 日間無料で利用できます。


プログラム 概要

  • プログラム期間 : 2022 年 10 月 12 日 ~ 11 月 9 日
  • オンボーディング セッション : 2022 年 10 月 26 日(水)15:00 - 16:00
    (アーカイブでも視聴可能)※

  • お申し込み : https://cloudonair.withgoogle.com/events/try-together-1012

  • 対象 : Google Cloud を学びたい大学生以上の方

  • 費用 : 無料

  • 実施方法 : オンライン


※ Skills Boost を初めてご利用いただく方にもご安心いただけるように、オンボーディング セッションとして Skills Boost 使い方説明 をオンラインで実施します。(本セッションは、アーカイブでもご覧いただけます。セッションに参加できなくても、プログラムに参加して学習することは可能です)

Skills Boost スキルバッジ獲得者特典

  1. スキルバッジを獲得した先着 1000 名様に、Google Cloud 特製トートバックをプレゼント
  2. スキルバッジを獲得した先着 200 名様に、Google Cloud 特製トートバックと PC 保護ケースをプレゼント

Google Cloud Innovators メンバー向け追加オファー

Innovators メンバーの方、もしくは期間中に Innovators メンバーにご登録いただき、本プログラムでスキルバッジを 1 つ以上獲得された方には、上記プレゼントに加え、認定資格バウチャー 1 回分(日本語試験のみ)をプレゼントいたします!

コミュニティやグループを主催する方、チューターとして参加を希望する方

こちらからご登録ください。また、本プログラムにも必ずご登録ください。

コミュニティ主催の勉強会は随時情報を更新していきます。

これから Google Cloud を学びたい方は、ぜひご参加ください。

お申し込みはこちらからお願いします。


同僚や知り合いの方にぜひシェアしてください。

#みんなで学ぼうGoogleCloud