この記事は Yoshi Yamaguchi、Santiago Díaz、Maud Nalpas、Eiji Kitamura による Google Security Blog の記事 "Uncovering potential threats to your web application by leveraging security reports" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
この記事は Yoshi Yamaguchi、Santiago Díaz、Maud Nalpas、Eiji Kitamura による Google Security Blog の記事 "Uncovering potential threats to your web application by leveraging security reports" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

新たなウェブ標準である Reporting API は、本番ウェブサイトにアクセスするブラウザで発生する問題をレポートする汎用的な仕組みを提供します。受け取るレポートでは、世界中のユーザーのブラウザで発生するセキュリティ違反やまもなく非推奨になる API などの問題が詳しく説明されています。

多くの場合は、HTTP ヘッダーでエンドポイント URL を指定するだけでレポートを収集できます。するとブラウザは、皆さんにとって関心のある問題が含まれたレポートをエンドポイントに自動転送し始めます。ただし、レポートの処理や分析はそれほど簡単ではありません。たとえば、エンドポイントには大量のレポートが送られてくる可能性がありますが、そのすべてが根本的な問題の特定に役立つわけではない場合があります。そのような状況では、問題を抽出して修正するのは非常に困難かもしれません。

このブログ投稿では、Google セキュリティ チームがどのように Reporting API を使って潜在的な問題を検出し、実際の問題を特定しているかを紹介します。また、Google と同じようなアプローチで簡単にレポートの処理や対策ができるように、オープンソースのソリューションも紹介します。


Reporting API の仕組み

本番環境のユーザーのブラウザでしか発生しないエラーもあります。もちろん、皆さんはユーザーのブラウザにアクセスすることはできません。こういったエラーは、ローカルで、あるいは開発中に見かけることはありません。実際のユーザーやネットワーク、デバイスがどのような状態になっているかわからないからです。Reporting API を使えば、ブラウザを直接利用してこういったエラーをモニタリングできます。つまり、ブラウザがエラーをキャッチし、エラーレポートを生成して、指定したエンドポイントに送信してくれます。

レポートの生成と送信の仕組み。

Reporting API でモニタリングできるエラーには、次のようなものがあります。

モニタリングできるすべてのエラータイプについては、ユースケースとレポートタイプをご覧ください。

Reporting API は、HTTP レスポンス ヘッダーで有効化と設定を行います。つまり、ブラウザがレポートを送信するエンドポイントと、モニタリングするエラータイプを HTTP レスポンス ヘッダーで宣言します。ブラウザは、レポートのリストをペイロードとする POST リクエストによって、レポートをエンドポイントに送信します。

設定の例 :

# CSP 違反レポート、Document-Policy 違反レポート、非推奨レポートを受け取る設定の例
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
# CSP 違反と Document-Policy 違反を `main-endpoint` に送信する
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# 非推奨レポートは自動生成され、明示的なエンドポイントは必要ない。常に `default` エンドポイントに送信される

注 : "report-only" モードをサポートするポリシーもあります。このポリシーでは、レポートは送信されますが、実際の制限は適用されません。これは、ポリシーが効果的に機能しているかどうかを判断する際に役立ちます。

Chrome ユーザーは、DevTools の [Application] パネルから、ブラウザが生成するレポートを確認できます。

DevTools の [Application] パネルに表示されるレポートの例。

レポートのエンドポイントのデモでは、生成されたさまざまな違反がサーバーでどのように受信されるかを確認できます。

違反レポートの例

2024 年 3 月時点で、Chrome は Reporting API をサポートしており、Safari は一部をサポートしています。詳細については、ブラウザ サポートの表をご覧ください。


Google のアプローチ

Google は、セキュリティを大規模に向上できるという恩恵を受けています。Content Security Policy、Trusted Types、Fetch Metadata、Cross-Origin Opener Policy といったウェブ プラットフォームによる対策は、さまざまな Google プロダクトや無数の個々のサービスからあらゆる脆弱性を排除するために役立ちます。この点は、こちらのブログ投稿で詳しく説明しています。


セキュリティ ポリシーを大規模に導入する場合、エンジニアリング上の課題の 1 つとなるのが、新しい制限に準拠しておらず、制限が適用された場合に動作しなくなるコードを特定することです。この問題を解決するためによく使われる 4 つのステップがあります。
  1. ポリシーを report-only モード でロールアウトします（CSP report-only モードの例）。こうすると、ブラウザはクライアント側のコードを通常どおり実行するよう指示しつつ、ポリシーが適用された場合に違反となるイベントの情報を収集します。この情報は、レポートのエンドポイントに送信される違反レポートに集約されます。
  2. 違反レポートをトリアージし、ポリシーに準拠していないコードの場所にリンクします。たとえば、危険な API を使っていたり、ユーザーデータとコードが混在するパターンを使っていたりするため、セキュリティ ポリシーに準拠していないコードベースがあるかもしれません。
  3. 特定したコードをリファクタリングして準拠させます。たとえば、危険な API を安全なバージョンに置き換えたり、ユーザー入力をコードと混在させないようにしたりします。こうしたリファクタリングにより、危険なコーディング パターンが減り、コードベースのセキュリティ態勢が向上します。
  4. すべてのコードを特定し、リファクタリングが終わった段階で、report-only モード からポリシーを削除し、完全に適用します。通常のロールアウトでは、手順 1～3 を繰り返し、すべての違反レポートを確実にトリアージします。



Reporting API では、1 つのレポート エンドポイントと、複数のセキュリティ機能を表現する 1 つのスキーマを使ってこのサイクルを実行できます。そのため、ブラウザ、コードパス、ユーザータイプを問わずに、さまざまな機能のレポートを一元的に収集できます。

注 : ポリシーで禁止されているアクションを行おうとすると、違反レポートが生成されます。たとえば、あるページに CSP を設定しているにもかかわらず、CSP で許可されていないスクリプトを読み込もうとする場合です。Reporting API で生成されるレポートのほとんどは違反レポートですが、それがすべてではありません。その他のタイプには、非推奨レポートやクラッシュ レポートなどがあります。詳細については、ユースケースとレポートタイプをご覧ください。

残念ながら、違反レポートのストリームにはノイズが紛れ込むことがよくあります。その場合、準拠していないコードを見つけることが難しくなる可能性があります。たとえば、多くのブラウザ拡張機能、マルウェア、ウィルス対策ソフトウェア、開発ツールのユーザーは、DOM にサードパーティのコードを挿入したり、禁止された API を使ったりしています。挿入されるコードがポリシーに準拠していない場合、コードベースにリンクされていない対策不可能な違反レポートになる可能性があります。そのため、レポートのトリアージが困難になり、すべてのコードを確実に準拠させてから新しいポリシーを適用するのが難しくなります。

Google は長年にわたり、違反レポートを収集して活用し、それをまとめて 根本原因に集約するための多くの技術を開発してきました ここでは、デベロッパーが違反レポートのノイズを除外できる技術の中から、特に役立つ技術の概要を紹介します。


根本原因に注目する

ブラウザのタブが使われている間に、ポリシーに準拠していないコードが何度も実行されることはよくあります。それが発生するたびに、新しい違反レポートが作成され、キューイングされて、レポートのエンドポイントに送信されます。これが起きると、冗長な情報を含む大量のレポートができてしまいます。そこで、違反レポートをクラスタにグループ化することで、個々の違反を意識することなく、根本原因について考えることができます。根本原因の方が理解しやすいので、有効なリファクタリング方法を探す時間を短縮できます。

例を通して、違反がどのようにグループ化されるのかを確認してみましょう。たとえば、インライン JavaScript イベント ハンドラの使用を禁止する report-only の CSP が導入されているとします。違反レポートは、該当するハンドラのすべてのインスタンスについて作成され、次のフィールドが設定されます。

  • blockedURL フィールドには、inline が設定されます。これは違反の種類を表します。
  • scriptSample フィールドには、フィールド内のイベント ハンドラの内容の最初の数バイトが設定されます。
  • documentURL フィールドには、現在のブラウザタブの URL が設定されます。

ほとんどの場合、この 3 つのフィールドで、特定の URL のインライン ハンドラを一意に識別できます。他のフィールドの値が異なる場合でも同様です。こういったことがよく起こるのは、トークンやタイムスタンプなどのランダムな値をページをまたいで使う場合です。前述のようなフィールドの値は、アプリケーションやフレームワークによって微妙に異なる場合があるため、レポート値をあいまい一致させることができれば、手間を省きつつ、違反をクラスタにグループ化して対策につなげることができます。必要に応じて、URL フィールドに既知のプレフィックスがある違反をグループ化することができます。たとえば、URL が chrome-extension、moz-extension、safari-extension で始まるすべての違反をグループ化すると、根本原因がコードベース以外のブラウザ拡張機能である違反を、高い信頼性で特定できます。

独自のグループ化戦略を策定すれば、トリアージが必要な違反報告の数を大幅に減らし、根本原因に注目することができます。通常は、関心のある種類の違反を一意に識別するフィールドを選び、そのフィールドを使って、特に重要な根本原因に優先順位をつけられるようにする必要があります。

 

環境情報を活用する

対策不可能な違反レポートと対策可能な違反レポートを区別するもう 1 つの方法が、環境情報です。このデータは、レポートのエンドポイントへのリクエストには含まれますが、違反レポート自体には含まれません。環境情報からクライアント設定におけるノイズ源を判別できる可能性があるので、トリアージに役立つかもしれません。

  • ユーザー エージェントまたはユーザー エージェント クライアント ヒント : ユーザー エージェントは、対策不可能な違反の大きな兆候です。たとえば、クローラ、ボット、一部のモバイルアプリなどは、サポート対象のブラウザ エンジンとは動作が異なり、カスタムのユーザー エージェントを使っているので、他では起きない違反が発生する可能性があります。それ以外にも、特定のブラウザでのみ発生する違反や、ナイトリー ビルドによる変更や新バージョンのブラウザによって発生する違反もあります。ユーザー エージェント情報がなければ、こういった違反を調査することは非常に困難になります。
  • 信頼できるユーザー : エンドポイントが違反の発生したドキュメントと same-site である場合、Reporting API がレポート エンドポイントに対して行うリクエストに利用可能な Cookie が添付されます。Cookie を取得すると、違反が起きたユーザーの種類を特定する際に役立ちます。対策すべき違反の多くは、会社の従業員やウェブサイト管理者など、信頼できるユーザーによるものであり、これらのユーザーが侵略的な拡張機能をインストールしたり、マルウェアに感染していたりすることはないでしょう。レポート エンドポイントから認証情報を取得できない場合は、まず信頼できるユーザーを対象に report-only ポリシーを設定してみましょう。そうすることで、対策すべき違反の基準を明確にしてから、ポリシーを一般公開することができます。
  • ユニーク ユーザー数 : 一般原則として、典型的な機能やコードパスのユーザーからは、ほぼ同じ違反が生成されるといえます。そのため、少数のユーザーでしか発生していない違反は除外候補とすることができます。つまり、アプリケーションのコードではなく、ユーザーの特定の設定が問題である可能性があるということです。「ユーザー数をカウントする」方法の 1 つは、違反を報告したユニーク IP アドレス数を記録することです。近似カウント アルゴリズムは使いやすく、特定の IP アドレスを追跡せずにこの情報を収集できます。たとえば、HyperLogLog アルゴリズムは、わずか数バイトで、信頼度高く、集合内のおおまかな一意の要素数を数えることができます。

違反をソースコードにマッピングする（高度な内容）

違反のタイプによっては、source_file フィールドまたはそれと同等のフィールドが含まれます。このフィールドは、違反の原因となった JavaScript ファイルを表し、通常は行番号と列番号が付いています。これらの 3 ビットデータは高品質の信号であり、リファクタリングが必要なコードの行を直接指すことができます。

ただし、コンパイルや最小化のために、ブラウザがフェッチしたソースファイルがコードベースに直接マッピングできなくなることもよくあります。その場合は、JavaScript ソースマップを使って、デプロイされたファイルとオーサリングされたファイルの間で行番号と列番号をマッピングするとよいでしょう。すると、違反レポートがソースコードの行に直接変換されるので、非常に対策しやすいレポート グループと根本原因が生成されます。

 

独自のソリューションを確立する

Reporting API は、セキュリティ違反、非推奨の API 呼び出し、ブラウザの介入などのブラウザ側イベントを、イベントごとに指定されたエンドポイントに送信します。ただし、前のセクションで説明したように、そのレポートから実際の問題を抽出するには、データ処理システムが必要です。


幸いなことに、さまざまな方法で必要なアーキテクチャを設定できるようになっており、オープンソースのプロダクトもあります。必要なシステムの基本的な要素は次のとおりです。
  • API エンドポイント : HTTP リクエストを受け取り、JSON 形式でレポートを処理するウェブサーバー
  • ストレージ : 受け取ったレポートやパイプラインで処理したレポートを格納するストレージ サーバー
  • データ パイプライン : ノイズを除去し、必要なメタデータを抽出して集約するパイプライン
  • データ視覚化ツール : 処理したレポートから知見を得るためのツール

以上の各コンポーネントのソリューションは、パブリック クラウド プラットフォーム、SaaS サービス、オープンソース ソフトウェアとして利用できます。詳細については、代替ソリューションのセクションをご覧ください。また、次のセクションでは、サンプル アプリケーションの概要を説明します。

 

サンプル アプリケーション : Reporting API プロセッサ

ブラウザからレポートを受け取る方法と、受け取ったレポートを処理する方法を理解できるように、小さなサンプル アプリケーションを作成しました。このアプリケーションで、ブラウザが送信したレポートからウェブ アプリケーションのセキュリティ問題を抽出するために必要なプロセスを示します。具体的には、以下のプロセスになります。

  • レポートのストレージへの保存
  • ノイズ リダクションとデータ集約
  • 処理済みのレポートデータの可視化
このサンプルでは、Google Cloud を使っていますが、各コンポーネントはお好みのテクノロジーに置き換えることができます。サンプル アプリケーションの概要を次の図に示します。



緑色のボックスは、独自に実装する必要があるコンポーネントです。 フォワーダ（forwarder） はシンプルなウェブサーバーであり、JSON 形式のレポートを受け取り、それを Bigtable 用のスキーマに変換します。 ビームコレクタ（beam-collector） はシンプルな Apache Beam パイプラインであり、ノイズの多いレポートをフィルタリングし、関連するレポートを集約して、CSV ファイルとして保存します。この 2 つのコンポーネントは、Reporting API からのレポートを有効利用するうえで重要な役割を果たしています。


実際に試す

これは実際に実行できるサンプル アプリケーションなので、すべてのコンポーネントを Google Cloud プロジェクトにデプロイし、自分で仕組みを確認することができます。サンプル システムを設定するための詳細な前提条件と手順は、README.md ファイルに記載されています。

 

代替ソリューション

ここで共有したオープンソース ソリューション以外にも、Reporting API を簡単に使えるようにするツールがいくつも用意されています。次のようなものがあります。

  • Sentry や Datadog などのアプリケーション エラー モニタリング プラットフォーム

代替案を選択する際は、価格だけでなく、次の点を考慮するようにしましょう。
  • アプリケーションの URL をサードパーティのレポート収集ツールに渡しても構わないでしょうか？ブラウザが URL から機密情報を取り除いたとしても、機密情報はこのように漏洩する可能性があります。アプリケーションにとってリスクが高すぎると思われる場合は、独自のレポート エンドポイントを運用してください。
  • 収集ツールは、必要なすべてのレポートタイプをサポートしていますか？たとえば、すべてのレポート エンドポイント ソリューションが COOP/COEP 違反レポートをサポートしているわけではありません。

まとめ

この記事では、ウェブ デベロッパーが Reporting API を使ってクライアント側の問題を収集する方法と、収集したレポートから実際の問題を抽出する際の課題について説明しました。また、その課題を解決するために Google がどのようにレポートをフィルタリングして処理しているかを説明し、同様のソリューションを実現する際に利用できるオープンソース プロジェクトを紹介しました。この情報が役立ち、Reporting API を活用するデベロッパーが増え、結果としてウェブサイトの安全性と持続可能性が向上することを願っています。


学習リソース



    Reviewed by Eiji Kitamura - Developer Relations Team

    ☁︎ 基調講演

    生成 AI に関する革新的な取り組みを行う企業の取り組みや、Google Cloud の最新ソリューションをお届けします。DAY1 は、LINEヤフー、星野リゾートなどいち早く生成 AI を活用されている企業が登壇し、ビジネス変革のヒントをお届けします。DAY2 は、開発者目線で Google Cloud が提供する生成 AI のコンセプトや、日本テレビ、ヤマト運輸、トヨタ自動車、三井住友フィナンシャルグループなど、業界をリードする企業がいかに Google Cloud を活用しているか、語ります。

    ☁︎ おすすめセッション

    以下に、一部ご紹介します。当日のライブ配信がないこと、また席数に限りがあるので、気になるものがあれば、イベント登録をした後に、早めにセッション登録いただきますよう、お願いします。


    日本時間 8 月 1 日（木）、2 日（金）に、旗艦イベント Google Cloud Next Tokyo '24 を開催します。待望のセッション情報が公開されました！

    ☁︎ 基調講演

    生成 AI に関する革新的な取り組みを行う企業の取り組みや、Google Cloud の最新ソリューションをお届けします。DAY1 は、LINEヤフー、星野リゾートなどいち早く生成 AI を活用されている企業が登壇し、ビジネス変革のヒントをお届けします。DAY2 は、開発者目線で Google Cloud が提供する生成 AI のコンセプトや、日本テレビ、ヤマト運輸、トヨタ自動車、三井住友フィナンシャルグループなど、業界をリードする企業がいかに Google Cloud を活用しているか、語ります。

    ☁︎ おすすめセッション

    以下に、一部ご紹介します。当日のライブ配信がないこと、また席数に限りがあるので、気になるものがあれば、イベント登録をした後に、早めにセッション登録いただきますよう、お願いします。


    【AI と機械学習】生成 AI Innovation Awards 最優秀賞！AI と人を共進化に導く学習業務活用支援

    ソフトバンク Axross の学習の業務定着化支援機能での Vertex AI など Google Cloud をフル活用したアーキテクチャを紹介します。新機能である協働ノートでの学び、意見を Vertex AI 支援で発散 / 収束させ、組織独自のノウハウ ドキュメント化を促進、知識 / スキルを可視化 / 数値化します。それらデータ活用で人に合わせて支援 AI 自体が進化、AI と人が協調的に進化する AI 時代最適なプラットフォームの提案です。


    【アプリケーション開発】サーバレスでモバイルアプリ開発！ NTTコム「ビジネスdアプリ」のアーキテクチャ

    NTTコミュニケーションズが中小企業向けに開発したモバイルアプリ「ビジネスdアプリ」は社員内製によって開発しています。Google Cloud のサーバレス サービスを徹底的に活用することによって、開発チームはプログラム開発に集中でき、短期間で開発をすることができました。本セッションでは Google Cloud のサーバレス サービスの活用のコツと注意点を解説します。


    【インフラストラクチャ】同時接続数 185 万人を支えたパルワールドのインフラ最前線

    発売 1 か月で総プレイヤー数 2500 万人を記録したパルワールド。大ヒットの裏側で起きた数々のエピソードや危機的事態を乗り切ったノウハウについて紹介します。


    【データ分析】楽天グループの大規模データ分析ツール「Rakuten Analytics」における BigQuery 活用

    「Rakuten Analytics」は、楽天グループの膨大なアクセスログを集約し、アナリストやデータ サイエンティストがデータのポテンシャルを最大限に引き出せるように設計された分析プラットフォームです。BigQuery を活用することによってパフォーマンスが大きく改善され、社内のデータドリブンな文化の実現に大きく前進したストーリーについて解説します。


    【生産性とコラボレーション】Gemini for Google Workspace 最新アップデート

    進化し続ける Gemini for Google Workspace の最新アップデート情報をお届けいたします。業務部門において、どのように利用されているのか？導入におけるメリット、最新機能をご紹介いたします。


    開催概要

    名称 : Google Cloud Next Tokyo '24（略称 Next Tokyo '24）

    日時 : 日本時間 2024 年 8 月 1 日（木） ~ 2 日（金）

    会場 : パシフィコ横浜 ノース

    対象 : 開発者から CEO まで、クラウド テクノロジーを使ったビジネス課題の解決を探求する、すべての方


    - お問い合わせ - 

    Google Cloud Next Tokyo 運営事務局

    E-mail: gc-nexttokyo-info@google.com



    この記事は Google Maps Platform デベロッパー マーケティング担当 Ahsan Ashraf による Google Maps Platform Blog の記事 "Google I/O '24: Introducing Gemini model capabilities for Places API, 3D Maps in the Maps JavaScript API, and open-source React components" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...

    この記事は Google Maps Platform デベロッパー マーケティング担当 Ahsan Ashraf による Google Maps Platform Blog の記事 "Google I/O '24: Introducing Gemini model capabilities for Places API, 3D Maps in the Maps JavaScript API, and open-source React components" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

    編集者注 : この投稿は、Google が毎年開催しているデベロッパー カンファレンスでの Google Maps Platform に関する最新のニュースをお伝えする、Google I/O 2024 シリーズの一部です。JavaScript で Photorealistic 3D Maps を使用して臨場感あふれる地図可視化エクスペリエンスを作り出す方法と、Places API の Gemini モデル機能を使用してエクスペリエンスを構築する方法について、詳しくは、5 月 16 日に実施したセッションに登録してご確認ください。

    20 年ほど前、最初の Google Maps API が世界に向けてリリースされ、ウェブとモバイルにわたる地理空間エクスペリエンスに革命を引き起こしました。それ以来、Google Maps Platform はデベロッパー コミュニティとともに進化し、シンプルな 2D マップから高解像度の衛星画像や、現実的な 3D モデルにまで拡大してきました。マップデータを可能な限り最新の状態に保つ基盤として AI を活用し、AI とコンピュータ ビジョンがそれらのデータをすべて融合させてより没入感のあるエクスペリエンスを実現しています。

    今回は、Google Maps Platform 3D データセットの可能性の限界をさらに押し広げる新機能についてお知らせします。これは、AI をデータ利用の枠を超えて初めてプロダクト領域にまで拡張し、お客様が Google のサービスを活用して容易に構築できるようにするものです。まず、Places API を皮切りに、Gemini モデルの機能を Google Maps Platform に導入していきます。また、Google が長年醸成してきたレンダリング技術を活用して、最も使われている API である Maps JavaScript に Photorealistic 3D Maps を導入します。さらに、オープンソースの React コンポーネント ライブラリのリリースにより、Google Maps Platform を使用した構築がこれまでよりも迅速かつ効率的になります。

    Places API の AI を活用した機能により、ユーザーが最適な場所を見つけやすくする

    Places API 向けの Gemini モデル機能が試験運用版でリリースされ、生成 AI による場所やエリアに関する有益な概要を表示できるようになりました。場所の概要は、レストラン、ショップ、観光スポット、公園などの場所に表示されます。ユーザーが探している場所をすばやく見つけやすくなり、場所のカスタム説明を自分で書く必要がなくなります。エリアの概要は、ある場所から徒歩圏内にあるショッピング施設、レストラン、観光スポットの概要を示して、近くでユーザーができるアクティビティーを把握しやすくします。

    また、より詳しいコンテキストが提供されるため、特定の検索結果が表示される理由をユーザーが理解しやすくなります。AI を利用したコンテキスト検索結果により、「犬を同伴できるカフェ」とユーザーが検索すると、関連した食事スポットのリストが表示されます。さらに、レストランのレビューやレストランを訪れた犬の写真が目立つように表示されます。こうした新機能の詳細については、お知らせのブログをご覧ください。

    ユーザーは、場所の概要によって、レストランを見つけ、選択することがより簡単になります。


    Maps JavaScript API で没入型エクスペリエンスを作り出す

    Maps JavaScript API の Photorealistic 3D Maps の試験運用版リリースは、使い慣れた単一の API を通じて構築される没入型ウェブ エクスペリエンスの新時代をもたらします。デベロッパーは初めて、Google 独自のレンダリング技術を使用して Google の高解像度 3D マップにシームレスにアクセスできるようになります。これにより、デベロッパーの選択肢が増え、使いやすさが向上するため、開発を効率化してエンドユーザーに卓越したエクスペリエンスを確実に提供できます。

    JavaScript の Photorealistic 3D Maps は、ネイティブのウェブ プログラミング言語で 3D データの活用を実現し、デベロッパーがレンダリング ツールを追加することなく魅力的なエクスペリエンスを生み出せるようにします。不動産のバーチャル ツアーを強化する、旅行サイトで世界中の行き先を魅力的に演出する、ハイパーリアルな都市環境を作成するなど、JavaScript の Photorealistic 3D Maps を使用すると、3D の没入型エクスペリエンスをこれまで以上に簡単に構築できます。いずれも、Google の広範囲にわたる対象地域と信頼できるインフラストラクチャによって実現されます。Maps JavaScript API を使用して 3D マッピング エクスペリエンスを構築する方法の詳細については、お知らせのブログをご覧ください。

    こちらの 3D マップを覧ください。以下のインタラクティブな 3D マップを使用して、息をのむようなアマルフィ海岸を探索しましょう。海岸に沿って移動したり、ズームインして名所であるアマルフィ大聖堂を見つけたりしてください。エンドユーザーのために何を実現できるか、想像してみましょう。

    インタラクティブなマップ : JavaScript の Photorealistic 3D Maps を使用して作成されたインタラクティブな 3D マップでアマルフィ海岸を旅することができます

    React コンポーネントを使用して迅速かつ簡単に構築する

    昨年の Google I/O では、デベロッパーがマップをより迅速かつ簡単に構築できるウェブ コンポーネントのリリースを発表しました。今年は React Google Maps Library の公式 1.0 リリースを発表します。これは、React ウェブアプリに Maps JavaScript API コンポーネントを統合するためのライブラリとして Google の協力の元初めて作成されたものです。

    import React from 'react';

    import {createRoot} from 'react-dom/client';

    import {APIProvider, Map} from '@vis.gl/react-google-maps';


    const App = () => (

      <APIProvider apiKey={API_KEY}>

        <Map

          style={{width: '100vw', height: '100vh'}}

          defaultCenter={{lat: 22.54992, lng: 0}}

          defaultZoom={3}

          gestureHandling={'greedy'}

          disableDefaultUI={true}

        />

      </APIProvider>

    );


    const root = createRoot(document.querySelector('#app'));

    root.render(

        <App />

    );


    このライブラリを使用すると、デベロッパーは Maps JavaScript API によって提供されるすべての機能を React アプリケーションに簡単に統合できます。ご利用方法の詳細については、お知らせのブログをご覧ください。


    詳細

    上記の進歩は、マップでできることの限界を押し広げ、デベロッパーが次世代の地理空間サービスを構築できるようにするという Google の取り組みを反映しています。上記の新しいプロダクトや機能の詳細については、Google I/O テクニカル セッションをご覧ください。また、Maps Compose ライブラリに焦点を当てたワークショップが 5 月 16 日から視聴できます。皆様が構築されるサービスを楽しみにしております。

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

    この記事は Justin Donnelly による Chromium Blog の記事 "How Machine Learning improved the Chrome address bar on Windows, Mac and ChromeOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...
    この記事は Justin Donnelly による Chromium Blog の記事 "How Machine Learning improved the Chrome address bar on Windows, Mac and ChromeOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


    Chrome のアドレスバー（オムニボックスとも呼ばれます）は、毎日何十億回も使われているツールで、ウェブを簡単に検索できるようにしています。これを使うと、タブやブックマークをすばやく探すことも、以前にアクセスしたウェブページに戻ることも、情報を検索することもできます。

    最新リリースの Chrome（M124）では、PC 版 Chrome のアドレスバーに機械学習モデルを組み込み、これまで以上に正確かつ適切にウェブページを提案できるようにしました。今後は、このモデルを使って、検索候補の関連性スコアの改善も行いたいと考えています。ここでは、今回の組み込みにつながったいくつかの重要な知見や、新しいモデルに期待されることについて、詳しくお伝えします。

    これまでの経緯

    アドレスバー担当チームのエンジニアリング リードである私にとって、すべてのリリースは特別なものですが、今回のリリースはとりわけ身近で大切なものです。初めて Chrome のアドレスバーに携わったとき、ユーザーに使いやすいと思ってもらうためのアイデアを周りに尋ねました。その 1 番の答えは、「スコアリング システムを改善する」でした。問題は、スコアが悪いことではありませんでした。実際、URL や検索語句を表示するアドレスバーの機能は、魔法のように感じられることがあります。問題は、それに 柔軟性がないことでした。 手作業で作成して調整する方法はうまく機能しましたが、それを改善したり、新しいシナリオに適応させたりするのは困難でした。そのため、スコアリング システムは長い間ほとんど手つかずのままでした。

    その大半の期間、明らかに向かうべき方向となっていたのが、ML でトレーニングしたスコアリング モデルでした。しかし、ここにたどり着くまでに、多くの失敗を重ねることになりました。これほど長い間、この課題を解決できなかったのは、文字通り毎日何十億回も使われている機能の中核となる仕組みを置き換えるのが難しかったためです。ソフトウェア エンジニアリング プロジェクトは、「飛行機を飛ばしながら作る」と表現されることがあります。このプロジェクトは、「世界中のすべての飛行機が飛んでいる間に、すべての座席を交換する」ようなものでした。規模が非常に大きく、変更はすべてのユーザーに直接影響します。

    有能で献身的なこのようなチームの努力がなければ、この野心的な取り組みは不可能でした。途中でぶつかったり、壁を突破しなければならなかったり、予期せぬ問題が発生してペースが落ちることもありましたが、ユーザーのためにどうしても正しい形でこれを行いたいという誠実な気持ちに突き動かされてきました。

    意外な知見

    ML システムで作業する楽しみの 1 つは、個人やチームでは困難または不可能な規模で、 すべての データを考慮したトレーニングを行えることです。そして、それは意外な知見につながる可能性があります。

    このプロジェクトで一番驚いたのは、特定のシグナル、すなわち前回のナビゲーションからの時間のスコアリング曲線を見たときでした。このシグナルで期待されるのは、小さいほど（特定の URL に移動したのが最近であるほど）、関連性スコアが高くなることでした。

    そして実際に、モデルはそのように学習しました。しかし、詳しく見てみると、驚くべきことがわかりました。ナビゲーションからの時間が非常に短い場合（数時間、数日、数週間ではなく、数秒だった場合）、モデルが算出する関連性スコアは、 減少 していたのです。トレーニング データを確認したところ、ユーザーが実際には望んでいない URL に移動し、すぐに Chrome のアドレスバーに戻って、もう一度試すパターンが記録されていることがわかりました。その場合、移動した URL は、ほぼ間違いなく、ユーザーが望んだものでは ありません。そのため、2 回目の試行との関連性スコアは低くなるはずです。

    よく考えてみれば、これは当然のことです。そして、ML でスコアリングを始めていなければ、このシナリオを反映させるために、古いシステムに新しいルールを追加していたはずです。しかし、トレーニング システムは、このパターンを見つけて学習してくれました。その前には、このようなことが起きているとは、誰も想像できませんでした。

    今後について

    この新しい ML モデルを使って、ユーザー エクスペリエンスを向上させる多くの新しい可能性を開くことができると考えています。たとえば、1 日の中の時間帯を区別して関連性を向上させるなど、新たなシグナルを組み込むことができます。モバイル、エンタープライズ、アカデミックといったユーザーごとに、あるいは言語や地域の違いなどに応じて、特定の環境向けの特別なバージョンのモデルをトレーニングすることも模索したいと考えています。

    さらに、ユーザーが Chrome のアドレスバーを操作する方法は、時間の経過とともに変化することがわかっています。そのため、関連性スコアもそれに合わせて変化させる必要があると考えています。新しいスコアリング システムを使えば、これまで以上に新鮮なシグナルを収集し、時間の経過とともに新しいモデルを定期的に再トレーニング、評価、展開することができます。


    Posted by Eiji Kitamura - Developer Relations Team

    この記事は プロダクト マネージャー James Harrison とグループ プロダクト マネージャー Matt Moore による Google Maps Platform Blog の記事 "Provide AI-powered place and area summaries, with Gemini model capabilities for Places API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ...


    この記事は プロダクト マネージャー James Harrison とグループ プロダクト マネージャー Matt Moore による Google Maps Platform Blog の記事 "Provide AI-powered place and area summaries, with Gemini model capabilities for Places API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

    編集者注 : この投稿は、Google が毎年開催しているデベロッパー カンファレンスにおける Google Maps Platform に関する最新ニュースをお伝えする、Google I/O 2024 シリーズの一部です。Places API の Gemini モデル機能を使用したエクスペリエンスの構築方法について詳しくは、5 月 16 日開催のセッションをご覧ください。

    20 年近くにわたり、開発者の皆様は Google のプロダクトを利用して革新的なマップ活用サービスを生み出してきました。このたび Google は、Google Maps Platform に Gemini モデル機能を導入し、開発者の皆様がさらなるイノベーションを推進できるよう支援いたします。最初に導入されるのは Places API です。開発者の皆様は、評価、口コミ、営業時間など、2 億 5,000 万件以上の企業や場所に関する豊富な情報を利用するだけでなく、生成 AI を活用した、場所やエリアに関する有益な要約をご自身のアプリやウェブサイトに表示できるようになります。頻繁に更新されるこれらの要約では、Gemini モデルを使用して、3 億人を超える Google マップ投稿者コミュニティによる場所に関する情報やインサイトを分析しているため、できる限り最新の情報を表示するのに役立ちます。

    Places API のもうひとつのアップデートは、AI を活用したコンテキスト検索結果の向上です。ユーザーがプロダクト内で場所を検索すると、検索に関連する口コミや写真を表示できるようになり、より簡単に場所を比較して意思決定を下せるようになります。これらの機能は現在、試験運用版としてすべての開発者の皆様にご利用いただけます。コンテキスト検索結果は世界中が対象となっていますが、場所とエリアの要約は米国でのみ利用可能で、今後対象国を順次増やしていく予定です。デモを試して、その仕組みをご確認ください

    Gemini モデルを使用した、Places API での場所とエリアの要約

    これらの新機能により、ユーザーはあなたのアプリやウェブサイトで、求めている情報をより素早く簡単に見つけられるようになります。また、より深いインサイトや要約が提供されるという利点もあり、その地点のカスタム説明を自ら書く必要がなくなります。

    場所についての短い要約と長い要約で、ユーザーがその場所を素早く理解できるようにする

    たとえば、レストラン予約アプリで、ユーザーが自分たちのグループにぴったりのレストランを把握できるようにしたいと仮定します。アプリでレストランを検索すると、名物料理やハッピーアワーの情報、お店の雰囲気など、重要なすべての情報がすぐに要約として表示されます。これにより、ユーザーは個々のレストランを詳しく調べなくても、どこに行くかを簡単に決めることができます。

    製品に合わせて要約をカスタマイズできるよう、短い要約（平均約 100 文字）と長い要約（平均約 400 文字）の 2 つの長さの要約を利用できます。レストラン、ショップ、スーパーマーケット、公園、映画館など、さまざまな種類の場所で利用できます。また、今後さらに増える予定です。短い要約は、Gemini モデルを使用することでより頻繁に更新されるようになり、手作業で記述した要約と比較して、これまでよりはるかに多くの米国内の場所で利用できるようになりました。長い要約は、さらに豊富な概要を提供します。レストランのおすすめ料理、雰囲気、サービスの質など、Places API でこれまで利用できた情報よりも多くの詳細情報を含めることができます。

    場所の長い要約を使って、ユーザーが食事をする場所を簡単に決められるよう支援できることを示す架空の例


    エリアの新しい要約で地理的エリアのおすすめスポットを強調

    ときには、ある場所の周辺エリアのおすすめスポットを説明することも有効です。Gemini モデルを使用したエリアの新しい要約により、ユーザーはある場所から徒歩圏内にあるショップ、レストラン、アトラクションの概要を確認できるようになったため、その場所で何をするかを決めやすくなります。たとえば、自動車メーカーは、運転手が充電中に訪れる場所を選べるよう、カフェ、レストラン、店舗など、EV 充電スタンドの近くにある場所の要約を運転手に提供できます。

    EV 充電スタンドの近くにある場所をまとめてエリアの要約で表示している架空の例


    コンテキスト検索結果で関連性の高い口コミや写真を提供

    最後に、AI を活用して多くのコンテキストを含めることで、その検索結果が表示される理由をユーザーが理解しやすくしました。たとえば、地元のレストランを検索できるアプリがある場合、「犬連れ OK のレストラン」と検索すると、関連する食事スポットのリストと一緒に、関連する口コミや口コミの抜粋、レストランを訪れた犬の写真が表示されます。こうした情報は、ユーザーがより多くの情報に基づいて意思決定をするのに役立ち、提供される結果への信頼度が高まります。

    コンテキスト検索結果で関連性の高いクチコミや写真を提供している架空の例


    エリア要約コンテンツの詳細

    新機能の概要をご紹介したので、そのうちの 1 つについて、仕組みやプロジェクトでの使用方法を技術的に詳しく見ていきましょう。

    以下のレスポンス places.AreaSummary オブジェクトは、エリア内にあるおすすめスポットの包括的な概要をユーザーに提供することを目的としています。関連するトピックで場所を分類し、場所ごとに簡単な説明を提供することで、ユーザーがその近くにあるさまざまな選択肢をすばやく把握できるようにします。これは、知らない地域を探索したり、特定の関心（カフェやレストランを探すなど）に基づいて行き先を決めたりする際に特に便利です。

    電気自動車充電スタンドがあるエリアの要約を見ていきましょう。付近のカフェに関するレスポンス データに特に注目します。

    AreaSummary { 

    content_blocks: [ 

    { 

    topic: "概要"

    ...

    }

    { 

    topic: "コーヒー"  // コンテンツ ブロックのテーマ

    content: { 

    text: "Acme Bread は、スープ、サラダ、サンドイッチのほか、コーヒーや焼き菓子も提供しています。Happy Coffee は人気のカフェで、特製ロースト、軽食、クイック サービスを提供しています。Perky Coffee は、コーヒー、紅茶、朝食の専門店で、ファミリー向けの健康的な環境で食事を提供しています。"

    }

    references: { } // コンテンツ ブロックの構成に使用する場所のプレイス ID

    }

    { 

    topic: "レストラン"

    ...

    }

    { 

    topic: "店舗"

    ...

    }

    ]

    }

    AreaSummary オブジェクトには content_blocks というオブジェクトの配列が含まれます。個々のオブジェクトは、エリア内の特定のトピックやカテゴリを表します。類似する場所をグループ化することで、エリアに関する情報を整理します。各ブロックは以下の情報を提供します。

    • トピック : " 概要 "、" コーヒー "、" レストラン "、" 店舗 " といったコンテンツのカテゴリ。
    • コンテンツ : そのカテゴリに含まれる場所の説明。多くの場合、具体的な名前と提供するサービスについて言及します。
    • 参照する場所 : コンテンツで言及した場所を参照するプレイス ID の配列。これは、要約を特定の場所の詳細に関連付けます。

    エリアの要約、場所の要約、コンテキスト検索結果をプロジェクトに追加する方法について詳しくは、ドキュメントをご確認ください。

    実際に API 使ってみるには

    試験運用中は、Places API の Gemini モデルの新機能とコンテキスト検索結果を無料でお試しいただけます。利用を開始して各機能の仕組みを把握するには、デモをご確認ください。また、公開 Issue Tracker でフィードバックや機能リクエストをお送りいただくこともできます。Places API の Gemini モデル機能を使用した地理空間エクスペリエンスの構築方法について詳しくは、I/O セッションをご覧ください。皆様が構築されるサービスを楽しみにしております。

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