Core Web Vitals の採用について、ステークホルダーをなかなか説得できなかったり、実際にビジネスに役立つかどうか疑問に思ったりしていませんか？この記事では、すでにユーザーやビジネスに好影響が出ている企業の例を紹介し、Core Web Vitals と重要なビジネス指標にどのような相関関係があるのかをわかりやすく説明します。

動画で見たい方は、Google I/O のこちらのトークをご覧ください（日本語字幕付き）。

Core Web Vitals がユーザーやビジネスにとって重要な理由 #

組織では、ステークホルダーによって優先度が異なる場合があります。Core Web Vitals を導入すると、ユーザー中心の指標の最適化と、その結果としてのビジネスの成長に重点を置くことで、全員で共通の認識を持つことができます。

CWV について考える

Core Web Vitals のスコアを上げるまでの道のりは、サイトのパフォーマンスが現在どの段階にあるか、デザインがどれだけ複雑かによって、サイトごとに異なります。すぐにたやすく取り組めて有意義な結果につながる場合もあれば、複雑なソリューションを実装して困難な問題を解決しなければならない場合もあります。意思決定者は、費やす時間にかかわらず、これをビジネスの成長のための長期的な投資として扱うべきです。高速でシームレスなナビゲーション体験を提供すれば、ユーザーは喜び、忠実なリピーターになります。プロダクト マネージャーにとって、パフォーマンスは新しいプロダクト機能の質と成功を定義する重要な基準です。また、優れたプロダクトを生み出すことや、やりがいのある課題に取り組むことは、デベロッパーの満足度の向上にもつながります。

ランキング シグナルとしての Core Web Vitals は、パフォーマンスに時間をかけて取り組むもう 1 つの動機となりますが、Core Web Vitals を採用すると、ランキングにとどまらず、さまざまな短期的、長期的メリットが得られます。Core Web Vitals を（ランキングに反映される前に）採用したいくつかのグローバル ブランドやローカル ブランドの事例を確認してみましょう。採用の理由は、Core Web Vitals がユーザー エクスペリエンスに注目しているからです。

ケーススタディ #

Vodafone #

Vodafone（イタリア）は、LCP を 31% 改善することで、売上が 8% 増加しました。

売上が 8% 増加

テクニック #

  • 重要な HTML をサーバー側でレンダリング
  • レンダリングをブロックする JavaScript を削減
  • イメージ最適化テクニック
  • ヒーロー イメージのサイズ変更、重要でないリソースの遅延読み込み

重要な教訓 #

  • 結果の有意義性を測定するには A/B テストが最適
  • A/B はサーバー側で行う

iCook #

iCook は、CLS を 15% 改善することで、広告収入が 10% 増加しました。

広告収入の増加を示すグラフ

テクニック #

  • 広告ユニットのサイズ変化を減らして、UI で固定サイズの広告スロットをあらかじめ割り当てる
  • 広告スクリプト読み込みロジックを最適化してヘッダー入札を優先する、重要でない JS の遅延読み込みをする

重要な教訓 #

フィルレートに影響が出る可能性があるが、広告の視認性が上がるにつれて収益が向上する

Tokopedia #

Tokopedia は、LCP を 55% 改善することで、平均セッション時間が 23% 増加しました。

改善前 3.78 秒、改善後 1.72 秒

テクニック #

  • LCP 要素をサーバー側でレンダリング（SSR）
  • LCP 要素のプリロード
  • イメージ最適化（圧縮、WebP、重要でないイメージの遅延読み込み）

重要な教訓 #

  • パフォーマンス モニタリング ダッシュボードを構築し、すべてのチームの進捗と影響を監視
  • さまざまなレンダリング テクニックの実験（例 : LCP 要素を SSR、スクロールせずに見える範囲を SSR、フル クライアント側 レンダリング）

以上のケーススタディから、ベスト プラクティスを採用してすばやく成果を上げることで、大きな効果が得られることがわかります。この点に関する実例を、さらにいくつか紹介します。

GEDI は CLS を 77% 削減することで直帰率が 8% 減少、Lazada は LCP を 3 分の 1 にすることでモバイルのコンバージョン率が 16.9% 増加、GYAO は LCP 約 3 分の 1 にすることでクリックスルー率が 108% 増加

以上の結果は、以下のようなすぐにたやすく行えることを実施した結果です。

イメージ最適化 JavaScript 最適化 広告と動的コンテンツ
WebP 画像形式の利用 サードパーティ JS の遅延読み込み スクロールせずに見える範囲の広告スペースを予約
イメージ CDN の利用 レンダリングをブロックする未使用 JS の削除 動的コンテンツの高さを設定
圧縮 重要でない JS の遅延読み込み
重要でないイメージの遅延読み込み 重要な JS のプリロード
ヒーロー イメージのプリロード
アスペクト比の指定

その他のベスト プラクティスについては、Web Vitals ガイダンスを参照してください。PageSpeed Insights を使うと、ウェブサイトを監査して即座に実用的な推奨事項を確認できます。

ほかにもいくつものグローバル ブランドが Core Web Vitals に投資して、そのメリットを享受しています。

対応を始めるには #

ステップ 1: 測定を始める #

最初に、フィールド ツールを使ってサイトを計測しましょう。Google を含むプロバイダが、さまざまなツールを公開しています。

Google 製ツール #

  • Search Console
  • PageSpeed Insights
  • web-vitals JS
  • Chrome ユーザー エクスペリエンス レポート

サードパーティ製ツール #

  • Cloudflare
  • New Relic
  • Akamai
  • Calibre
  • WebPageTest
  • Blue Triangle
  • Sentry
  • SpeedCurve

皆さんにとって最適なツールを選択してください。もう一歩踏み込んで Google アナリティクス 4 を組み込むことで、Core Web Vitals とビジネス指標の相関関係を確認することもできます。

ステップ 2: ステークホルダーを説得する #

  • Core Web Vitals を採用してユーザー エクスペリエンスを改善することの重要性と、それが企業のビジネス指標に関連していることを、ステークホルダーに説明する
  • 社内で支援者を募り、小規模な実験を始める
  • すべてのチームで Core Web Vitals を改善するために、すべてのステークホルダーで共通の目標を定める

ステップ 3: 以下のヒントを活用して実装を成功に導く #

  • 優先度 : 有意義な結果につなげるため、トラフィックが高いページやコンバージョンへの影響が大きいページを選択する（広告ランディング ページ、コンバージョン ページ、人気のページなど）
  • A/B テスト : レンダリング コストの発生を避けるためにサーバー側でのテストを利用し、最適化したバージョンと最適化していないバージョンの結果を比較する
  • 監視 : 継続的なモニタリングをし、リグレッションを防ぐ

最後になりますが、Google では、パフォーマンスは目的ではなく過程であると考えています。そのため、注目すべき最新のケーススタディを紹介できるように、今後もこの記事を更新する予定です。ビジネスですばらしい成功を収め、この記事で取り上げてほしい事例がある方は、コンテンツの提案をお送りください。


Reviewed by Eiji Kitamura - Developer Relations Team

Google Ads Query Language（GAQL）の新しい改善版インタラクティブ クエリビルダーをリリースします。新しいバージョンはリソース中心型で、FROM 句のリソースを活用して GAQL クエリの作成をサポートします。クエリビルダーには、次の 2 つの方法でアクセスできます。


デベロッパー ドキュメントの [Reports] タブに移動し、ページの左側の [Query Builder] を展開して、リソースを選択します。

または、レポーティング リファレンス ドキュメントで任意のリソースの [Help me build a query] ボタンをクリックします。







ハイライト

ユーザーが新しい検索バーに文字を入力すると、フィールドが動的に絞り込まれます。





このツールは、デベロッパーが Google Ads Query Language を使いながら学習できるように設計されています。クエリビルダーには、動的にヒントが表示されます（フィールドの互換性など）。





プロンプトも表示されます（たとえば、クエリの複数の句にフィールドを追加する際の要件をユーザーに通知するなど）。





新しいクエリビルダーには、クエリを読みやすい形式で表示する "pretty print" モードと、クエリのボックスで直接フィールドを削除したり並び替えたりできる "interactive" モードがあります。





新しいクエリビルダーを使う際は、各ページの右上に表示されている [Send feedback] ボタンをクリックして、遠慮なくフィードバックをお送りください。




ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは [email protected] にご連絡ください。

- Devin Chasanoff（Google Ads API チームを代表して）

Core Web Vitals は、サイトオーナーがウェブサイトのユーザー エクスペリエンスを改善する場所や方法を理解するために役立つ重要な一歩です。Google のページ エクスペリエンス シグナルでも、このような客観的な指標群に注目することを推奨する予定です。これらは、デベロッパーが現在のすばらしいユーザー エクスペリエンスを改善し、維持するために役立つだけではありません。今後もアップデートされていくので、デベロッパーはウェブが満たすべき最新のパフォーマンスについての情報を得ることができます。 

世界中の AMP Project の貢献者のおかげで、サイトオーナーは AMP ページを作成する際に、パフォーマンスに優れた体験の構築に向けて良いスタートを切ることができます。ただし、他の多くのフレームワークと同様に、AMP でもウェブ開発のベスト プラクティスをすべて実装することはできません。このブログ投稿では、AMP ページを確実に最適化するためにデベロッパーが行うべきことについて共有します。この内容は、AMP ページがパブリッシャーのサイトから提供される場合と、AMP キャッシュから提供される場合の両方に適用できます。

AMP ページのパフォーマンスをさらに高め、Core Web Vitals を満たす

AMP の目的は、優れたユーザー エクスペリエンスを簡単に作れるようにすることです。しかし、優れたユーザー エクスペリエンスに不可欠だと AMP チームが確信しているいくつかの開発プラクティスでは、追加の作業が必要になる場合があります。

AMP のトラフィックを理解する

ページの Core Web Vitals 指標は、ウェブページで実際のユーザー インタラクションを測定して算出されます。AMP では、ユーザーがどのようにコンテンツにアクセスしたかによって、パブリッシャーのドメインか AMP キャッシュのどちらかからページが提供されます。多くの場合、AMP へのアクセスの大部分（半分以上）が自分のドメインで発生します。こちらのガイドに従うと、AMP デベロッパーが AMP キャッシュ上とそれ以外での Core Web Vitals 指標を測定できます。

ウェブ開発のベスト プラクティスを導入する

Google の調査によれば、デベロッパーが AMP ページを提供する方法には、まだ最適化の余地があります。主なポイントは以下のとおりです。

  • サーバーの応答時間を改善する : サーバーが遅い、またはエンドユーザーから離れた場所に存在する場合は、ほぼすべてのものが遅くなってしまいます。CDN と同じように、配信は AMP キャッシュによって最適化されますが、ほぼすべての AMP サイトに AMP キャッシュ外のトラフィックが存在します。つまり、優れたユーザー エクスペリエンスを実現するには、高速で応答が速いサーバーが不可欠です。
  • 大きすぎるイメージの使用を控える : サイトでユーザーが期待する速さを実現するには、ユーザーが使っているデバイスのディスプレイよりも大きいイメージは使わないようにします。 
  • フォントによるレイアウトのずれを回避する : レイアウトのずれは、ウェブページの要素が動的に変更され、コンテンツに「ずれ」が発生することによって起こります。ウェブフォントを取得してレンダリングすると、直接的にレイアウトのずれが発生する可能性があります。 現在推奨している方法は、最初のビューポートで利用するすべての重要なフォントについて、フォントのプリロードと font-display: optional を組み合わせることです。このレイアウトのずれはあらゆるウェブページで日常的に起こっているので、標準化団体とともに追加のガイダンスを提供する作業を進めています。
  • data-hero を使ってヒーロー イメージをマークアップする : 多くのウェブページにとって、ヒーロー イメージは重要なパーツです。そのため、ユーザーが期待する速さで読み込む必要があります。<amp-img data-hero src="…"> のようにして data-hero 属性を使ってヒーロー イメージをマークアップすると、AMP Cache と Optimizer がヒーロー イメージを認識して最適化してくれるので、イメージのレンダリング時間が最大 50% 速くなります。

さらに AMP を改善するためのツール

AMP ページで可能な限り充実したユーザー エクスペリエンスを実現するため、すべてのサイトオーナーの皆さんに、ご自身で対応できるさまざまな最適化を追加で実施することを強く推奨します。最も簡単な方法は、最新の AMP Optimizer を使うことです。これにより、AMP の新しいサーバー側最適化をすべて自動で適用できます。また、昨年には、AMP Page Experience Guide（下図）も公開しました。公開以降、アクションにつながるフィードバックが AMP Page Experience Guide にさらに追加され、利便性が高まりました。この取り組みを推進する原動力となっているのは、このツールを使って AMP ページをテストするウェブサイトです。たとえば、カスタム フォントの読み込みに関する推奨事項が表示されるようになったので、LCP と CLS を最適化できます。

AMP Page Experience Guide の結果のスクリーンショット

AMP ページをこれらの基準に適合させるためのアクションにつながる推奨事項が存在しない場合は、お知らせください。直接サポートいたします。次に示すように、リクエストは AMP Page Experience Guide の中から送信できます。または、Github から直接連絡することもできます。

AMP Page Experience Guide から直接 AMP の問題を送信

まとめ

AMP Project は、ユーザー ファーストなオープンウェブを作るというビジョンただ一点に集中しています。AMP Page Experience Guide を使うと、Core Web Vitals に基づく AMP ページのパフォーマンスを確認できます。パブリッシャーのドメインと AMP キャッシュで、推奨された最適化を実施することをお勧めします。

AMP 開発コミュニティや、皆さんのフィードバックに感謝いたします。いつものように、問題や機能リクエストがありましたら遠慮なくお知らせください。


Reviewed by Eiji Kitamura - Developer Relations Team


見えないバグを追いかける

予測できず、再現性がなく、自分のものではなく、実質的に見ることができないバグを見つけるには、どうすればいいのでしょうか。

まずは、シナリオを決めることです。そのために、ユーザーが認識できるジャンクに注目します。そして Chrome が遅いと感じる瞬間をシステム的に突き止める方法として、ジャンクを実際の環境で測定します。

次に、実用性の高いバグレポートを実際の環境で集めます。そのために、Chrome の BackgroundTracing インフラストラクチャを使って Slow Report と呼ぶものを生成しました。匿名で指標を共有することに同意した一部の Canary ユーザーで、特定のシナリオを調査できる循環バッファ トレースを有効にします。すると、注目する指標があらかじめ設定されたしきい値に達したときに、トレース バッファが取得され、匿名化が行われて Google のサーバーにアップロードされます。

このバグレポートは、次のようなものです。


通常は健全なマシンで、AutocompleteController::UpdateResult() の 2 秒のジャンクを chrome://tracing で表示したもの
犯人がわかりました。AutocompleteController を最適化すればいいのですね。いや、違います。まだ理由がわかっていないのです。何の前提も設けないようにしましょう。

BackgroundTracing をスタック サンプルで補足すると、ストールした AutoComplete イベント内で繰り返し起こっているスタックを見つけることができました。
    RegEnumValueW

    RegEnumValueWStub

    base::win::RegistryValueIterator::Read()

    gfx::`anonymous namespace\'::CachedFontLinkSettings::GetLinkedFonts

    gfx::internal::LinkedFontsIterator::GetLinkedFonts()

    gfx::internal::LinkedFontsIterator::NextFont(gfx::Font *)

    gfx::GetFallbackFonts(gfx::Font const &)

    gfx::RenderTextHarfBuzz::ShapeRuns(...)

    gfx::RenderTextHarfBuzz::ItemizeAndShapeText(...)

    gfx::RenderTextHarfBuzz::EnsureLayoutRunList()

    gfx::RenderTextHarfBuzz::EnsureLayout()

    gfx::RenderTextHarfBuzz::GetStringSizeF()

    gfx::RenderTextHarfBuzz::GetStringSize()

    OmniboxTextView::CalculatePreferredSize()

    OmniboxTextView::ReapplyStyling()

    OmniboxTextView::SetText...)

    OmniboxResultView::Invalidate()

    OmniboxResultView::SetMatch(AutocompleteMatch const &)

    OmniboxPopupContentsView::UpdatePopupAppearance()

    OmniboxPopupModel::OnResultChanged()

    OmniboxEditModel::OnCurrentMatchChanged()

    OmniboxController::OnResultChanged(bool)

    AutocompleteController::UpdateResult(bool,bool)

    AutocompleteController::Start(AutocompleteInput const &)

    (...)


なるほど。オートコンプリートが悪いわけではありません。GetFallbackFonts() を最適化すればいいのですね。でも、待ってください。そもそも、いったいどういうわけで GetFallbackFonts() が呼ばれているのでしょうか。

それを突き止める前に、どうすればこれがパフォーマンスのロングテール問題全体の一番の根本原因だとわかるのでしょうか。とにかく、まだ 1 つのトレースしか見ていないのです ...



測定における難問

指標からは、どのくらいのユーザーが影響を受けているか、どの程度悪い状態なのかはわかります。しかし、根本原因がわかるわけではありません。

Slow Report からは、特定のユーザーの問題はわかりますが、どのくらい多くのユーザーが影響を受けているかはわかりません。また、Slow Report トレースのコーパスを検索することはできますが、これには本質的にバイアスがかかっているので、指標と 1 対 1 で対応することは不可能です。たとえば、Chrome はセッション 1 つにつきパフォーマンス悪化の最初の事例だけをレポートし、対象も Canary/Dev チャンネルのユーザーだけなので、起動と母集団の両方のバイアスがかかっています。

これは測定における難問です。ツールが提供するデータの実用性が高いほど、取得できるシナリオは少なくなり、強いバイアスがかかるようになります。深さをとるか、広さをとるかです。

両方を行おうとするツールはその中間にあたります。その場合、大きなデータセットを集計するので、欠陥のある入力に基づく結果を集計してしまうというリスクがあります（たとえば、注目したい部分が循環バッファ トレースから欠落しており、バイアスがかかった集計になるなど）。


そこで、科学的理論に基づき、最もエンジニアリング的でない選択肢を選びました。つまり、大量の Slow Report のトレースを手動で開くという方法です。これは、すでに定量化できている最重要な問題に対して、最も効果的な手法になりました。

たくさんのトレースを開いた結果、そのほとんどに、なんらかの形で前述のフォントの問題が現れていることがわかりました。影響を受けた厳密なユーザー数はわかりませんが、指標に現れていたユーザーの苦しみの主な原因はこれだと確信するには十分でした。




フォールバック フォント

そもそも GetFallbackFonts() が呼ばれる理由は何なのかを追求しました。先ほどの例の呼び出し元は、あるフォントでレンダリングされる Unicode 文字列のピクセル数を求めようとしていました。

その中のサブ文字列に、指定されたフォントではレンダリングできない Unicode ブロック内の文字がある場合、システムが推奨するフォールバック フォントをリクエストするため、GetFallbackFont() が使われます。それに失敗すると、リンクされているフォントをすべて試してレンダリングに最適なものを決めるため GetFallbackFonts() が呼び出されます。この 2 回目のフォールバックは遅くなります。

GetFallbackFont() が失敗することはないはずですが、実際はそこまで単純ではありません。Windows でこれを確実に行う方法は、DirectWrite に照会することです。しかし、DirectWrite は Chrome がまだ Windows XP をサポートしていたころの Windows 7 で追加されたものでした。そのため、両方のバージョンの OS で動作するように、GetFallbackFont() のロジックで確実性が低い試行錯誤的な Uniscribe+GDI を利用せざるを得ませんでした。それでもほとんどの場合はうまく動作したので、のちに Chrome で Windows XP のサポートが削除されたときも、この処理をクリーンアップできることに誰も気づきませんでした。パフォーマンスのロングテールを調査する新しいツールを使うことで、ジャンクの一番の原因（GetFallbackFonts() の不要な呼び出し）が明らかになったのです。

Google はこれを修正し、GetFallbackFonts() の呼び出し回数を 4 分の 1 に削減しました。


まだゼロではないので、前述の AutoComplete の問題は引き続き Slow Report で確認できます。そのため、調査を続けましょう。DirectWrite の GetFallbackFont() の失敗は予期しないものでしたが、Slow Report は匿名化されているので、ユーザーが生成した文字列はアップロードできません。そのため、どのコードポイントが問題を起こしているのかを突き止めるのは難題です。そこでプライバシーのエキスパートとも相談し、個人を特定できる情報が漏洩しないように、Unicode ブロックとテキスト ブロックのスクリプトを HarfBuzz に通すことにしました。


 

絵文字の物語

この新しい記録が利用できるようになるとともに、Slow Report の次の波がやってきました。大半のレポートでは、DirectWrite に Miscellaneous Symbols and Pictographs（その他の記号とピクトグラフ）内のコードポイント（Unicode 文字）のフォントを見つけるようリクエストしたときに、フォントのフォールバックが失敗していました。ローカルでその Unicode ブロックのすべてのコードポイントを試すスクリプトを書いたところ、問題を起こしていたのは何かがすぐにわかりました。U+1F3FB～U+1F3FF は、Unicode 8.0 で追加された修飾子で、別のコードポイントと組み合わせたときのみ意味を持ちます。たとえば、U+1F9D7（🧗）と U+1F3FF を組み合わせると 🧗🏿 となります。U+1F3FF 自体をレンダリングできるフォントはありません。そのため、フォントのフォールバックに正しいフォントを見つけるよう依頼しても、すべてのリンクされているフォントを調べた後にエラーになるのは正しい動作です。グラフこれはブラウザ側の Unicode セグメンテーション ロジックのバグでした。バグによって 2 つのコードポイントが誤って分割されるため、1 つの書記素としてではなく、別々にレンダリングするように DirectWrite にリクエストしていました。

でも、待ってください。Chrome は最新の Unicode をサポートしているのではなかったでしょうか。確かに、ウェブ コンテンツをレンダリングする Blink はサポートしています。しかし、ブラウザ側のロジックは、絵文字を描画することはないので、最新の絵文字（修飾子付きのもの）をサポートするように更新されてはいませんでした。ブラウザの UI（タブバー、ブックマーク バー、アドレスバーなど）が最新化され、Unicode をサポートするようになったのは、2018 年ごろになってからのことです。そのときから、以前のセグメンテーション ロジックが（見えない）問題になっていました。

そのうえ、キャッシュ ロジックはエラー時にキャッシュを行わないようになっていたので、たくさんのフォントがインストールされたユーザーでは、修飾子を自力でレンダリングしようとするたびに大きなジャンクが起きていました。皮肉なことに、このキャッシュは、ブラウザ UI に初めて Unicode サポートが追加されたとき、誤解されたボトルネックに対処するために追加されたものでした。フォント API のレイヤーでとどまるのではなく、フォントのロジックについて下層の実装に迫り続けたことが、主要なパフォーマンスの問題の修正だけでなく、他の絵文字に関する修正にもつながりました。たとえば、🏳️‍🌈 をコードで表すと、U+1F3F3（🏳️）+U+1F308（🌈）となります。分割ロジックを修正するまで、この書記素はブラウザの UI で 🏳️🌈 と誤ってレンダリングされていました。



そして旅は続く …

Google の旅は、さまざまな Chrome のコンポーネントに迫り続けています。しかしそれは、いつも同じ基本戦術に従っています。それは、何の前提も設けないようにして、予想できず、再現できず、自分のものでもないバグを徹底的に追求することです。スタック ランキングの問題は不可能に近いですが（参照 : 測定の難題）、なんらかのツールで見つけたトップ 5 の問題を修正し、ロングテールに注目すれば、実際のユーザーの苦しみの大半に対処できることになります。

Google はこのアプローチによって、ここ 2 年半の間でユーザーの目に見えるジャンクを 10 分の 1 に減らし、狙いを定めた多くの機能でパフォーマンスのロングテールを改善しました。

30 秒間のサンプルにおいて 100 ミリ秒間隔で無応答になった数の 99 パーセンタイル


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

Reviewed by Eiji Kitamura - Developer Relations Team

ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは [email protected] にご連絡ください。

- Ben Karl（Google Ads API チーム）

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

今回、初めてのバーチャルでの Google I/O デベロッパー カンファレンスが開幕されました。このカンファレンスは、Google の各チームからの発表を世界中の開発者に伝え、共有、視聴していただく場です。この記事では、デベロッパー基調講演で発表された Google Maps Platform に関する最新ニュースを要約してお届けします。


WebGL を利用したマップ機能のベータリリース

クラウドベースのマップのスタイル設定の一部として、ベクトル地図を導入しました。今後数週間以内に JavaScript API 経由で一般提供する予定です。これにより、Google マップのウェブ エクスペリエンスでおなじみの WebGL でアクセラレーションされた高パフォーマンスな地図を、初めてウェブアプリでも利用できるようになります。WebGL は低レベルのブラウザ API であり、クライアント デバイス上の GPU の処理能力とレンダリング能力をブラウザが利用できるようにすることで、複雑な 2D と 3D グラフィックスをウェブ上でレンダリング可能にします。

本日 Maps JavaScript API ベータ版の新機能として、傾斜と回転、そして WebGL Overlay View の 2 つをリリースします。これらはいずれも WebGL を利用した機能です。これらの機能の動作を確認するには、WebGL 機能のガイドツアーおよび Ubilabs の皆さんが構築した WebGL 旅行のデモをご覧ください。


チルトと回転これまで、地図の表示方法は真上から基本地図を見る 2 次元ビューに限定されていました。チルトと回転機能を使用すると、読み込み時と実行時の両方で、67.5 度の傾きと 360 度の回転が可能になり、地図のまったく新しいビューをユーザーに提供できるようになります。これは斜め視点からの 3D の建物モデルが初めてウェブアプリで表示できるようになったということでもあります。

チルトと回転機能が、Maps JavaScript API のベータ版で利用可能になりました。

また、キーボードとマウスによる制御が追加され、ユーザーが地図の傾斜と回転を手動で変更できるようにもなっています。これにより、ウェブアプリでまったく新しいレベルのユーザー操作が可能になります。


WebGL Overlay View

チルトと回転を使用して基本地図を 3 次元で制御できることに興味を引かれる方であれば、WebGL Overlay View も気に入っていただけると思います。これはベクトル地図のレンダリングに使用する WebGL レンダリング表現を背景地図の上に直接重ね合わせて操作できるようにようにするという、まったく新しいマッピング エクスペリエンスの構築方法を提供します。

class google.maps.WebglOverlayView {

  onAdd() {}


  onRemove() {}


  onContextRestored(gl) {}


  onDraw(gl, coordinateTransformer) {}


  onContextLost() {}

}

WebGL Overlay View により、初めて 2 次元と 3 次元のオブジェクトを基本地図に直接レンダリングできるようになりました。つまり、レンダリングされたオブジェクトが地図に表示されるだけでなく、オクルージョンとパースペクティブを備えた 3 次元空間で地図の一部としてレンダリングされます。たとえば、こちらの WebGL Overlay View による 3D マーカーの実装をご覧ください。地図が回転するとマーカーが建物に隠れてビューから非表示になり、カメラから離れるにつれてマーカーが小さくなるのを確認頂けると思います。

WebGL Overlay View（ベータ版）で基本地図に直接レンダリング

使用を開始するには、WebGL の Codelab とドキュメントをご参照ください。Google I/O のセッションに参加できなかった場合は、Travis McPhail のセッション Next generation Maps for the web（ウェブ向けの次世代マップ）で詳細をご覧ください。こちらは、オンデマンドで視聴できます。


JavaScript 向けのクラウドベースのマップスタイル設定が一般提供に

2020 年 6 月にクラウドベースのマップスタイル設定機能のベータ版をリリースしました。これは、Google Cloud Console から地図をカスタマイズ、管理、デプロイできる一連の新機能です。この機能には直感的な UI ベースのスタイル エディタが Cloud コンソール上に導入されており、ズームレベルのカスタマイズから商業地域のカスタム スタイル設定まで、地図の外観と動作を細かくカスタマイズできます。さらに、業界別に最適化されたマップスタイルを導入し、地図の作成後すぐに配信できるようにしました。

このたび、クラウドベースのマップスタイル設定を Maps JavaScript API と Maps Static API で正式に一般提供します。お客様のチーム全体でより良い地図を作成できるように、これまでの 11 か月間、コンソール内のエクスペリエンスと全体のパフォーマンスを改善してまいりました。

クラウドベースのマップスタイル設定を使用して地図のカスタマイズや管理を行います

スウェーデンで業界をリードする不動産プラットフォームである Hemnet のプロダクト チームは、クラウドベースのマップスタイル設定に移行することですでにメリットを得ています。Hemnet のプロダクト マネージャーである Magnus Burell 氏は、次のように述べています。「最近、私たちのチームは、お休み中のお客様に喜んでいただくために、不動産地図のスタイルを一時的に変更しました。クラウドベースのマップスタイル設定によって、このアイデアをすばやく簡単に実現できました。さまざまなマップスタイルに繰り返し手を加えてはプレビューするという作業を数分以内で行い、デプロイしなくてもすぐに公開できました。」

Hemnet は復活祭の際に地図のスタイルを変更しました。

クラウドベースのマップスタイル設定をベータ版でお試しいただいている皆様にお礼を申し上げます。他の Google プロダクトにおけるものも含めて、お客様からのフィードバックは一般提供を開始するうえでたいへん貴重です。カスタム地図によって毎日数千万もの新しい地図表現が配信されていることを大変嬉しく思います。

詳しくは、クラウドベースのマップスタイル設定に関する I/O 2021 セッションをご覧ください。また、Maps JavaScript API や Maps Static API のドキュメントもご確認いただけます。VCCP London がクラウドベースのマップスタイル設定を利用して「Cadbury Worldwide Hide」の仮想イースター エッグ ハントを実現した方法も、ぜひご一読ください。


次のステップ

Google は、今回ご紹介した新機能のレンダリングとパフォーマンスの改善に引き続き取り組んでおり、現実世界と同じくらい豊かなエクスペリエンスを生み出す地図の作成に絶えず努めています。そのためにはお客様のご協力が不可欠です。新しい地図機能を改善できるよう、バグレポート、機能リクエスト、フィードバックを公開バグトラッカーからお寄せくださいますよう、お願いいたします。

16 年ほど前に最初の Google Maps API を提供して以来、地図の概念を覆すお客様のあらゆる手法から刺激をいただいてきました。チルトと回転、WebGL Overlay View、クラウドベースのマップスタイル設定は、新世代のマッピング エクスペリエンスの作成を支援する取り組みの最新の成果です。お客様がどのような素晴らしい地図を作成されるのか、拝見するのを楽しみにしています。

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


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


デジタル カンファレンス Google Cloud Day: Digital '21、いよいよ明日から開催します。オンライン開催ではありますが、皆さまにお会いできることを楽しみにしています。もし、まだ登録できていないという方は、ぜひこちらから、事前のご登録をお忘れなく。

☁️ 視聴について
イベントに登録済であれば、どのセッションも視聴可能です。
以下のアイコンにて、配信状況を確認できます。


このアイコンは、リアルタイム配信中であることを意味します。
直近で配信されているセッション情報が、配信日の一番上に表示されています。
セッションによっては、その場で質問をすることが可能です。気になるセッションは、ぜひリアルタイムで視聴してください。


リアルタイム配信終了後は、オンデマンドでの視聴ができるようになります。


☁️ 駆け込み質問 募集中
Cloud 寺子屋では、誰でもお昼の時間に Google Cloud のエキスパートに質問できます。基本的な質問からマニアックな質問までお答えします！お気軽にご参加ください。

☁️ パートナーがご提案するソリューション
Google Cloud Day: Digital '21 を支える 51 社のパートナーのホワイトペーパーやソリューションをダウンロードできるページをこちらでご紹介しています。ぜひ、ご確認ください。


☁️ ハッシュタグについて
視聴中に、気になったことや、新しい学びなどがあれば、ぜひ ハッシュタグ #GoogleCloudDay と以下のソリューションごとのタグを使って、SNS で投稿してください。同じテーマを視聴している皆さんと、情報共有の場ができればと思います。

アプリケーション開発　　　#appdev
データ基盤・分析　　　　　#data
機械学習　　　　　　　　　#ML
インフラストラクチャ　　　#infra
生産性とコラボレーション　#GWS
セキュリティ　　　　　　　#security



————————————————————

お問い合わせ先 : Google Cloud Day: Digital 事務局

[email protected]

————————————————————



Figure 1: IME（例、Gboard)は 漢字の選択肢を表示
Figure 1: IME（例、Gboard)は 漢字の選択肢を表示



入力処理を行う IME アプリには、下記のような情報が保存されています。
  1. IME内のメニュを表示するための一般的な「漢字↔よみがな」の対応情報
  2. ユーザーが選択した変換の履歴に基づいた「漢字↔よみがな」の対応情報
上記の 1 と 2 の情報は、IME のデータベースで管理されます。このデータベースは、ユーザーの入力や IME の人工知能によって、改善されてゆきます。

つまり IME は「推測しにくい」よみがなを、ユーザーの文字入力によって、簡単に取得することができるように作られているのです。また、そのよみがなは、漢字の情報とともにデバイス上でデータベース化されます。

Q：その貴重なデータをアプリケーションと提供する方法はないのでしょうか？
A：はい！この記事を書いているのは日本語を利用する Android アプリ開発者の皆様にそれをご紹介するためです。Gboard で漢字の変換データをアプリと共有する API が利用可能になりました。

Figure 2: 漢字入力とともに、よみがな情報を提供するIME



この Gboard（v10.1 以降）に追加された API は、IME のテキスト出力に、よみがなを span として追加します。この API を利用するアプリケーションは、その出力を拾うことで、高い精度でユーザーの入力した文章に該当するよみがなを推測できるようになります。

よみがな情報を取得するためには、漢字入力の対象となる TextEdit が下記の条件を満たす必要があります：

  • ア）inputType プロパティの値を textPersonName にする。
  • イ）privateImeOptions プロパティの値を com.google.android.inputmethod.latin.requestPhoneticOutput にする。
Android Studio の Layout エディターで見た場合、設定は下記のようになります。

Figure 3: Android Studioのプロパティ設定

次に、TextWatcher を宣言し、入力通知の際、CharSequence から、getSpans() によって該当する TtsSpan を取得します。
public class MainActivity extends AppCompatActivity {

    private class PhoneticRetriever implements TextWatcher {
        // Extracts phonetic metadata from an incoming text blob
        private String getPhoneticMetadata(CharSequence s) {
            String phonetic = null;
            if (s instanceof SpannableStringBuilder) {
                SpannableStringBuilder textAsSpan = (SpannableStringBuilder) s;
                TtsSpan[] allSpans = textAsSpan.getSpans(0, s.length(), TtsSpan.class);
                if (allSpans.length == 1 && allSpans[0].getType().equals(TtsSpan.TYPE_TEXT)) {
                    // log shows where the span is in the text
                    Log.v("PHON",
                            s.toString() + " [" + textAsSpan.length() + "] start:" +
                            textAsSpan.getSpanStart(allSpans[0]) + " end:" +
                            textAsSpan.getSpanEnd(allSpans[0]));
                    phonetic =  allSpans[0].getArgs().getString(TtsSpan.ARG_TEXT);
                    textAsSpan.removeSpan(allSpans[0]); // avoid consuming again
                }
            }
            return phonetic;
        }
        @Override
        public void afterTextChanged(Editable s) {
            String sphonetic = getPhoneticMetadata(s);
            if (sphonetic == null) {
　　　　　　　　　　// no phonetic data
            } else {
                // phonetic data is in sphonetic - use it as you like
            }
        }

        @Override
        public void beforeTextChanged(CharSequence s, int start, int count, int after) {}

        @Override
        public void onTextChanged(CharSequence s, int start, int before, int count) {}
    }
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        EditText etUserInput = (EditText)findViewById(R.id.editTextPhoneticWithOptions );
        etUserInput.addTextChangedListener(new PhoneticRetriever());
    }
}

このサンプルコードでは、afterTextChanged() のコールバックで TtsSpan を取得しています。TtsSpan.ARG_TEXT がよみがなで、getSpanStart() と getSpanEnd() を利用すれば、入力された CharSequence の中で取得したよみがなの位置を取得することができます。

実行可能なコードはこちらのレポジトリをご参照ください。
　→　https://github.com/googlesamples/gboard-dev-samples/tree/main/GetIMEPhoneticName

同じコードを使ったサンプルアプリケーションを Play Store からインストールすることも可能です。
　→　https://play.google.com/store/apps/details?id=com.ragingsamples.getimephoneticname

Google コンタクト アプリ（v3.37 以降）では、連絡先を編集する際、この API を使って漢字名に該当するよみがなが自動入力されます。自動入力の結果が誤っている場合でも、ユーザーは手動でよみがなを直すことができます。

Figure 4: Google コンタクト アプリのよみがな推測

この API を利用して取得したよみがなの使い道はみなさんの作るアプリ次第ですが、いくつか参考になるユースケースをご紹介します：
  • ユーザーの入力した名前から自動的によみがなを推測する。2021 年 5 月現在、この API は 名前にのみ対応しているため、ショッピング アプリや銀行アプリ、カスタム CRM アプリ、 SNS アプリなどで利用することができます。
  • 他の IME が Gboard と同じ API を提供することで、より多くのユーザーによみがなのサポートを提供する。

ほかのユースケースのご提案、名前以外に将来的にサポートして欲しい入力タイプ、改善点などありましたら、ぜひフィードバックをお願いします。


Posted by Alex Gimenez - Technical Solutions Consultant



5 月 18 日から 20 日（日本時間 5 月 19 日から 21 日）に Google I/O 2021 がオンラインで開催されます。

これにあわせて、Google I/O 2021 で発表される内容から、特に日本のデベロッパーの皆さまにお届けしたい話題をご紹介する「I/O Extended for Web developers 2021」を 6 月 8 日に開催します。

当日は、日本の Google 関係者がモデレーターとして、動画の解説、リアルタイムでお寄せいただく質問に回答する場も設けています。

無料のオープンウェビナーとなっておりますので、皆さまお誘い合わせの上、ぜひご参加ください。（事前登録必須です）

開催概要

  • 日時 : 2021 年 6 月 8 日 15:00 〜 17:00
  • 形式 : ウェビナー

タイムテーブル:

  • 15:00 〜 15:05 オープニングのご挨拶

  • 15:00 〜 15:35 Web Vitals の最新情報：（Annie Sullivan & Elizabeth Sweeny）
    • このセッションでは、ツールを活用し、Web Vitals を測定および最適化する方法に関する最新のリサーチ結果を共有致します。
      [ナビゲーター] えーじ & 宍戸俊哉

  • 15:35 〜 16:05 Web のプライバシー強化に向けた準備：（Maud Nalpas）
    • ユーザーはさらなるプライバシーの強化を求めており、Web エコシステムはこの要望に応えるよう進化し、プライバシーはデフォルトになりつつあります。 Web のプライバシー強化に対応するうえで、Web サイトにどのような準備が必要でしょうか。ここでは、何がどのような理由で変わりつつあるか、サードパーティ Cookie の段階的廃止に備える方法、役立つツール、試してみるべき新しい API、ユーザーが使用できる Chrome のコントロールなど、デベロッパーに必要な情報を順番に説明します。
      [ナビゲーター] えーじ & 宍戸俊哉

  • 16:05 〜 16:35 オプトインとしてのセキュリティからデフォルトのセキュリティへ： （えーじ & Camille Lamy）
    • Spectre は、Web のセキュリティ環境に大きな影響を与えました。このセッションでは、Web サイトの安全性と機能性を維持するためのセキュリティ ヘッダーに関するベスト プラクティスについて、お話をさせて頂きます。また、今後予定されている重要な変更や新しいデフォルトについても紹介します。
      [ナビゲーター] えーじ & 宍戸俊哉

  • 16:35 〜 16:55 Q & A
    • イベント配信画面右側に表示されている「質問入力ツールの Slido」を通して随時送っていただいた質問から、「いいね」が多いものを優先して回答させていただきます。
      ※自然検索に関する質問は取り上げない可能性があります。具体的な質問がある場合は #Google検索オフィスアワーやヘルプ コミュニティをご活用ください。

  • 16:55 〜 17:00 クロージングのご挨拶

※登壇者、内容は変更される場合がありますので、最新情報は Web サイトでご確認ください。

参加申し込み


こちらの Web サイトからお申し込みください。ライブ配信やアーカイブの再生・閲覧、当日のQ&A で取り上げるご質問は Web サイトからのみ可能です。当日でも参加登録は可能ですが、事前に登録を完了いただくと、スムーズです。なるべく登録をお済ませの上お待ち下さい。

*参加登録は、参加者（視聴者）お一人ごとにお願いいたします
*参加者人数には制限を設けておりません。
*プログラムの内容は予告なく変更になることがございます


皆さまのご参加をお待ちしております。


Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems