Google Workspace がチーム コラボレーションの未来を再定義し、Google Chat のルームは Spaces へと進化している中で、現在のチャットルームですでに利用できる Webhook は、ユーザーが作業するチャットルームに直接非同期メッセージを提供できる便利な機能です。Chat の Webhook は、使いやすい機能で、Google Chat API を使ってユーザーと同期的に通信する専用のアプリケーションである Chatbot と違い、ボットではないアプリケーションで Google Chat への非同期メッセージングを実現します。この投稿では、Chat での Webhook の使い方について説明し、Google 内部で実際に使っているユースケースを紹介します。

Google Chat で Webhook を使う事例

Google Chat では、さまざまな目的でルーム（現在は Spaces）を作成して使用することができます。セールス サポートやカスタマー サービスといったトピックなど、テーマに沿ったルームもあれば、特定の部門や全社での会話のように、もう少し汎用的なルームもあります。しかし、こういったユースケースは、すべて人間の活動が中心になっています。そのため、これらへの依存が高まれば高まるほど、お互いのコミュニケーションにとって重要な方法になります。

Webhook を利用すると、他のシステムやアプリケーションから、ルームや会話のテーマに沿った最新の情報を導入できます。そのため、ルームのレベルが飛躍的に向上します。たとえば、セールス サポートのルームで Webhook を使うと、商談がまとまったタイミングや RFP の締め切りが近づいたタイミングで CRM システムからアラートをユーザーに通知できます。カスタマー サービスのルームで Webhook を使うと、リクエストに対して緊急のアラートを投稿し、チーム全体の注目を集めることができます。汎用的なルームで Webhook を使うと、部門のユーザーに今後の締め切りについて通知したり、株式市場の取引時間終了時に会社の株価を全社員に広く共有したりできます。Webhook を使うと、状況を問わず、効率的かつリアルタイムにデータや情報を提供できます。

Google での実際のユースケース

Google には、G Workspace Community という名前のチャットルームがあり、質問やプロダクト全体の最新ニュースを取得したい Google 社員同士や、Google Workspace のカスタマー チームとの交流に使われています。ご想像どおり、このルームは広く使われており、毎日たくさんの投稿や回答が行われています。特によく議論されるのは、リリースのタイミングに関する情報や、ロードマップでのステータスなど、新機能に関するトピックです。

Google では、Workspace の新機能が公開されるときに全員に周知できるように、Google Workspace Updates ブログの公開フィードも作成しています。G Workspace Community の全メンバーが Updates ブログも購読し、リリースされるすべての機能について最新情報を受け取れていると想定するのは論理的かもしれません。しかし実際は、G Workspace Community チャットルームが主要なリソースになっており、Google 社員はそこで Google Workspace の最新情報を取得しています。そのため、チャットルームにリリースについての質問を投稿する前にブログをチェックしてもらう代わりに、Google Workspace Community ルームに Google Workspace Updates フィードを持ち込むことにしました。これは、Google Chat の Webhook を使って簡単に実現できます。そして現在は、誰もが Google Workspace から簡単にすべての最新情報を取得できるようになっています。

Google Workspace Updates「ボット」の紹介

Updates ブログで Workspace の新機能についての投稿が公開されると、Google Workspace Updates「ボット」（内部的には、作成者の Justin Wexler にちなんで Google Wexbot と呼ばれています）がチャットルームに新しいスレッドを追加し、そこに投稿のタイトルとメイン コンテンツの最初の 250 文字を送信します。これにより、ルームのメンバーは新機能についてすばやく把握できるだけでなく、ブログの内容についてすぐに議論を始めることもできます。メンバーは、機能リリースについて質問したりコメントを追加したりできるので、はるかに高度なコラボレーション体験が実現します。また、[READ MORE] をクリックするだけで Updates ブログの全文を読むこともできます。

Webhook + Apps Script = 魔法

このような最新情報をタイムリーに受け取るコミュニティのメンバーにとって、この「ボット」は魔法のように思えるかもしれません。実際には、これは魔法でも従来型のチャットボットでもありません。そのため、Chat の UI でこれを「ボット」と呼ぶのは正しい表現ではありません。実は、Google Updates「ボット」は単純な Google Apps Script アプリケーションです。このアプリケーションは、新しい投稿の RSS フィードを解析し、Webhook 経由で非同期的にルームに送信します。

Apps Script は、一定の間隔で実行できるトリガー（すなわち cron ジョブ）を提供するので、このユースケースに適しています。この仕組みを利用して Updates ブログの新しい投稿をチェックし、投稿のフィード XML を解析し、UrlFetchApp を呼び出して待機している Webhook に Chat Card 形式で結果を返します。

Google Workspace Updates「ボット」の内部実装では、1 時間に 1 回 Apps Script トリガーが実行され、Update ブログの新しい投稿をチェックしています。さらに、プロジェクト自体がさほどコード量が多くない 1 つの Apps Script プロジェクト ファイルになっており、チャットルームの設定も簡単なうえ、実質的にメンテナンスの手間もかかりません。Justin がオリジナル バージョンを作るためにかけた時間は、たった数日でした。しかし、ユーザーにとっての価値は明らかだったため、作者にちなんだ名前が付けられることになったのです ;)

Google Workspace Updates「ボット」（通称 Wexbot）を自分のチャットルームに追加する

自分の Google Workspace Updates「ボット」を追加してみたい方や、他のユースケースを実現するために Apps Script を使って Webhook 経由で Google Chat に非同期メッセージを送る方法を知りたい方のために、GitHub でプロジェクトを公開しています。ぜひ確認して、実装してみてください。

Google Chat Updates Bot Project - GitHub

README | Apps Script Code.js

その他のリソース

Google Workspace の Chatbot や Webhook の詳細については、以下のリソースをご覧ください。

• Google Chat API
• 新しいボットの作成
• 着信 Webhook の使用
• Node や Python による着信 Webhook
• Chatbot 用の GWAO Card Builder

Google Workspace デベロッパー ニュースレターへの登録もお忘れなく！

Google は日々、デフォルトで安全で、設計上プライベートなプロダクトを構築することを通して、ユーザーが自分のデータを管理できるようにすることに注力しています。しかし、一般的なオンラインのセキュリティ脆弱性は、Google のプロダクト以外の部分、すなわちオンライン アカウントに不適切なパスワードでログインすることによって生じています。データ漏洩によって毎日膨大な数のパスワードが漏れ出し、ユーザーの個人情報が危険にさらされています。Google が最優先しているのは、オンラインのユーザーの安全を守ることです。そこで私たちは、個人情報を安全に保つための新しいツールや機能の開発に継続的に取り組んでいます。

この度（元記事公開当時）、Google Identity Services という新しい一連の Identity API をリリースします。これは、複数の ID サービスを 1 つのソフトウェア開発キット（SDK）にまとめたものです。この SDK には、Google でログインするためのボタンや、簡単に利用できる新しい認証プロンプトである One Tap が含まれています。Google でログインと One Tap は、パートナーのウェブサイトやアプリにログインするのにパスワードではなく、安全なトークンを利用します。

この取り組みは、プライバシーやセキュリティを損なわない ID ソリューションを提供することを目的として始まりました。そして今回、それが実現できました。新しい Google Identity Services は、業界トップクラスの Google のセキュリティと、簡単なログインによる究極の利便性を組み合わせることで、ユーザーを安全に保ちつつ、新しいユーザーの獲得やリピーターのシームレスなログインを促進する体験を提供します。

利用できる新機能

One Tap は、先回り型のシームレスなログイン プロンプトで、ユーザーがウェブサイトやアプリを使ってパーソナライズされたコンテンツに安全にアクセスする際に役立ちます。従来のログインボタンとは異なり、One Tap はどんなページからでもプロンプトを表示できます。そのため、ユーザーをランディング ページにリダイレクトする必要はなく、ユーザーのナビゲーションの意図が妨げられることはありません。One Tap プロンプトは、ウェブサイトでは右上から下に向かって、モバイル デバイスでは下から上に向かってスライドして表示されます。ユーザーは、1 回タップするだけでログインや登録をすることができ、認証情報を覚えたり、パスワードを作成したりする必要はありません。パートナーは、この認証ソリューションを使って大きな成果を上げています。劇的に手間が少なくなることで、ウェブサイトやアプリでのユーザーのログイン率や登録率が増加しました。 

モバイル デバイスで下から表示される One Tap プロンプト

Google Identity Services プロダクトは、クリック ジャッキングやピクセル トラッキングなどの脆弱性、その他の脅威からの保護も考慮されています。そのため、ユーザーは安心してウェブサイトやアプリを利用できます。すべての Google アカウントには、強固な不正利用対策や不正防止システムが適用されています。そのため、Google Identity Services を使うことで、重複アカウントや不正アカウントによるリスクを軽減でき、サポートの負荷も減少します。

さらに、Google でログインするためのボタンの改善版をロールアウトし、リピーターに対してユーザー固有の詳細情報を表示するようにしました。これにより、選択されるユーザー アカウントが表示されるようになります。Google でログインするボタンでは、ウェブ全体での UI/UX の整合性も向上しており、プラットフォーム全体で信頼性とセキュリティを向上することができます。

ユーザー固有の情報を含めた Google でログインするボタンを青と白の背景で表示

Reddit のウェブサイトの右上に表示される One Tap プロンプト

使ってみるには

Google は、デベロッパーの実装プロセスを簡単にし、最低限のコードで実現できるように懸命に作業を進めています。ぜひこの新しい API スイートを使い、ビジネスの成長にお役立てください。新しい Google Identity Services の実装を始めるには、デベロッパー サイトで技術ドキュメントをご覧ください。技術サポートを受けたい方は、Stack Overflow で google-signin タグをチェックしてください。

特に記載のない限り、下記の変更は Android、Android WebView、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 7 月 29 日の時点で Chrome 93 はベータ版です。

オリジン トライアル

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

新しいオリジン トライアル

Cross-Origin-Embedder-Policy: credentialless

credentialless キーワードを使って、Cookie やクライアント証明書などの認証情報を省略したクロスオリジン no-CORS リクエストが可能になりました。COEP: require-corp と同じように、クロスオリジン分離も有効化できます。

SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。現在は COEP: require-corp が存在し、クロスオリジン分離の有効化に利用されています。これは確実に機能しますが、すべてのサブリソースで明示的にオプトインしなければならないので、大規模な導入は難しいことがわかっています。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト（Google Earth、一般的なソーシャル メディア、フォーラムなど）では、依存関係の問題が発生します。

マルチスクリーン ウィンドウの配置

Multi-Screen Window Placement API を使えば、マシンに接続された任意のディスプレイへのウィンドウの配置、その配置の保存、任意のディスプレイでのウィンドウの全画面表示が可能です。プレゼンテーション アプリでこの API を使うと、ある画面にスライドを、別の画面に発表者用のノートを表示できます。アートや音楽の制作アプリでは、2 つ目の画面にパレットを配置できます。また、レストランなら、座席側にタッチスクリーン メニューを、従業員側に別のウィンドウを表示できます。この API は、最初のオリジン トライアルでのデベロッパーからのフィードバックに基づいて形状や人間工学が改善され、2 回目のオリジン トライアルに入ります。

インストールされたデスクトップ版ウェブアプリ向けのウィンドウ コントロール オーバーレイ

ウィンドウ コントロール オーバーレイは、ウィンドウ全体を覆うようにアプリのクライアント領域を拡張します。この領域には、タイトルバー、ウィンドウのコントロール ボタン（閉じる、最大化/復元、最小化）も含まれます。ウェブアプリのデベロッパーは、ウィンドウ コントロール オーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされたデスクトップ版ウェブアプリを OS のアプリのように見せることができます。詳しくは、PWA のタイトルバーのウィンドウ コントロール オーバーレイをカスタマイズするをご覧ください。

URL ハンドラとしての PWA

URL ハンドラとしての PWA を使うと、music.example.com のようなアプリが、自分自身を https://music.example.com、https://*.music.example.com、https://🎵.example.com といったパターンに一致する URL のハンドラとして登録できます。これにより、インスタント メッセンジャー アプリケーションやメール クライアントなどの PWA の外部からのリンクが、ブラウザのタブではなく、インストールした PWA で開くようになります。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

ウェブバンドルによるサブリソースの読み込み

ウェブバンドルは、複数のリソースをバンドルできるフォーマットを使って大量のリソースを効率的に読み込むための新たなアプローチです。この機能は、以前のリソース バンドルへのアプローチが抱えていた問題に対処します。

一部の JavaScript バンドラの出力は、HTTP キャッシュをうまく扱うことができず、設定が難しくなる場合もあります。バンドルされた JavaScript でも、すべてのバイトがダウンロードされるまで実行を待つ必要があります。複数のサブリソースを読み込む場合、ストリーミングと並列化を使用するのが理想ですが、これは 1 つの JavaScript ファイルでは実現できません。JavaScript モジュールでは、決定的実行の関係で、リソースツリー全体がダウンロードされるのを待ってから実行する必要があります。

WebXR Plane Detection API

WebXR アプリケーションで、ユーザーの環境に存在する平面のデータを取得できるようになります。これにより、拡張現実アプリケーションでさらに臨場感の高い体験を実現できます。この機能がない場合、デベロッパーは getUserMedia()（navigator と MediaDevices で利用可能）のデータに対して独自のコンピュータ ビジョン アルゴリズムを実行してユーザーの環境に存在する平面を検知するしかありませんでした。そのため、このようなソリューションでは、ネイティブの拡張現実機能に匹敵する質や精度を実現したり、ワールド スケールをサポートしたりすることはできませんでした。

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

AbortSignal.abort() 静的メソッド

静的メソッドである AbortSignal.abort() は、すでに中止された AbortSignal オブジェクトを新しく作成します。これは Promise.reject() と同じような考え方で、デベロッパーの人間工学を改善します。

ウェブ デベロッパーは、中止された AbortSignal オブジェクトをさまざまな目的に役立てることができます。これを使って、作業をしないように JavaScript API に指示します。現在、すでに中止された AbortSignal オブジェクトを作るには、複数行のコードが必要です。AbortSignal.abort() を使うと、次の 1 行で作成できます。

return AbortSignal.abort();

CSS Flexbox: alignment キーワードが start、end、self-start、self-end、left、right をサポート

flexbox と flex 項目が位置ベースの alignment キーワードに従うようになります。これまでの flexbox は、center、flex-start、flex-end のみに従っていました。追加された alignment キーワード（start、end、self-start、self-end、left、right）を使うと、flex 項目の位置をさまざまな書き込みモードや flex フローに簡単に合わせることができます。

これらの追加キーワードがない場合、書き込みモード、テキストの方向、flex の逆方向プロパティ（flex-direction: row-reverse、flex-direction:column-reverse、align-content: wrap-reverse）を変えるたびに、キーワードの値を変更する必要があります。今回実装されたキーワードを使うと、alignment を一度設定するだけで済みます。

Error.cause プロパティ

Error() コンストラクタが cause という新しいオプション プロパティをサポートし、これはプロパティとしてエラーに割り当てられます。これにより、エラーを条件でラップするという不必要で複雑な作業をすることなく、エラーをチェーンさせることができます。

meta name=theme-color が media HTML 属性を反映

meta[name="theme-color"] で meta 要素の "media" 属性が反映されます。これにより、ウェブ デベロッパーがメディア クエリに基づいてサイトのテーマカラーを調整できるようになります（ダークモードとライトモードなど）。最初に一致したものが選択されます。

HTMLMediaElement.controlsList の noplaybackrate

HTMLMediaElement.controlsList プロパティが noplaybackrate をサポートします。これにより、ブラウザが公開する再生速度のコントロールをウェブサイトで有効化または無効化できるようになります。ブラウザ ベンダーが再生速度のコントロールをメディア コントロールに追加したことで、デベロッパーはこの新しいコントロールの表示を制御する方法が得られます。新しいプロパティは、HTMLMediaElement.controlsList のサンプルの noplaybackrate で試すことができます。

Sec-CH-Prefers-Color-Scheme Client-Hint ヘッダー

CSS ユーザー プリファレンス メディア機能の prefers-color-scheme は、ページで提供する必要がある CSS の量とページ読み込み時のユーザー エクスペリエンスに大きな影響を与える可能性があります。新しい Sec-CH-Prefers-Color-Scheme Client-Hint ヘッダーを使うと、サイトのリクエスト時にオプションでユーザー プリファレンスを取得できるので、サーバーは適切な CSS をインラインで提供できます。そのため、一瞬だけ適切でないカラーテーマが表示されることを回避できます。

User-Agent Client-Hint API のアップデート

このバージョンの Chrome には、User-Agent Client-Hint API に 4 つの新機能と変更点が追加されています。

• Sec-CH-UA-Bitness: ユーザー エージェントが動作するプラットフォーム アーキテクチャのビットネスに関する情報をサーバーに提供するためのリクエスト ヘッダーです。ビットネスとは、特定のシステムが評価できる基本値を構成するビットの数を表します。
  
• Sec-CH-UA-Platform を低エントロピー ヒントに変更 : Sec-CH-UA-Platform は、ユーザー エージェントが動作するプラットフォームに関する情報をサーバーに提供するためのリクエスト ヘッダーです。
  
• 低エントロピー ヒントを UADataValues.getHighEntropyValues() に追加 : ヒントが高エントロピーから低エントロピーに移動した場合、それに依存するコードの将来性が保証されます。

• NavigatorUAData.toJSON() メソッドの改善 : このメソッドが便利なデータを返すようになります。

低エントロピー ヒントとは、あまり多くの情報を公開しないヒントや、他の方法で簡単に検出できるため現実的に隠蔽するのは難しい情報を提供するヒントです。Client-Hint においては、関連するオリジンがリクエストしたかどうかにかかわらず、また関連するフレームがファースト パーティかサード パーティかにかかわらず、すべてのリクエストで利用できるヒントを指します。

WebOTP API: クロスデバイスのサポート

デスクトップ向け Chrome と Android Chrome の両方が同じ Google アカウントにログインしている場合、PC でも WebOTP API がサポートされます。WebOPT API は、プログラムによってオリジン宛ての特定の形式の SMS メッセージからワンタイム コードを読み取る機能を提供するため、ログイン時のユーザーの手間を減らすことができます。これまで、この機能は SMS がサポートされるモバイル デバイスのみで利用できました。

JavaScript

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

Object.hasOwn

新しい Boolean 型のプロパティである Object.hasOwn は、使いやすい静的メソッド バージョンの Object.prototype.hasOwnProperty を提供します。

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

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

ポート 989 と 990 のブロック

ポート 989 と 990 による HTTP、HTTPS、FTP サーバーへの接続が失敗するようになります。これらのポートは FTPS プロトコルで使われていますが、FTPS は Chrome では実装されていません。ただし、悪意のあるウェブページが FTPS サーバーに対して、綿密に作成された HTTPS リクエストを使ったクロスプロトコル攻撃を仕掛ける可能性があります。これは、ALPACA 攻撃の緩和策になります。

TLS から 3DES を削除

Chrome で、TLS_RSA_WITH_3DES_EDE_CBC_SHA 暗号スイートのサポートが削除されます。TLS_RSA_WITH_3DES_EDE_CBC_SHA は、SSL 2.0 と SSL 3.0 時代の遺物です。トランスポート レイヤー セキュリティ（TLS）での 3DES は、Sweet32 攻撃に対して脆弱です。これは CBC 暗号スイートであるため、Lucky Thirteen 攻撃に対しても脆弱です。TLS では、最初の代替案である AES 暗号スイートが 19 年ほど前に公開された RFC3268 によって定義され、その後も何度かの反復が行われています。

WebAssembly のクロスオリジン モジュール共有

エージェント クラスタが長期的にオリジンにスコープできるように、クロスオリジンでありながら同一サイト環境であるサイト間での WebAssembly モジュール共有が非推奨となります。これは WebAssembly の仕様変更に従ったもので、プラットフォームにも影響します。

この記事は Google マップ、Google Maps Platform プロダクト マネージャー Alicia Sullivan による Google Cloud Blog の記事 " New Cloud-based maps styling features provide more options, control, and flexibility to enhance your user experience" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年の Google I/O にて、Google は Maps JavaScript API 向けクラウドベースのマップスタイル設定の一般提供を発表しました。この度 Google は、クラウドベースのマップスタイル設定の新機能を発表いたします。この新機能は選択肢の幅を広げ、制御性を高め、ユーザーに優れたエクスペリエンスを提供します。その新機能とは、ランドマークとビルディング フットプリント（建物の外形情報）の 2 つです。ウェブ版とアプリ版の一般向け Google マップをご利用の方はこれらの機能をすでにご存知かもしれません。また、業界別に最適化された地図スタイルの新バージョンもリリースします。新しいバージョンではより細やかな設定が設定できるようになると同時に柔軟性が向上し、優れたエクスペリエンスを実現します。それでは詳細を見てみましょう。

ランドマークの表示によりすばやく現在地を把握することが可能に

ウェブ版とアプリ版の一般向け Google マップをご利用の方は、主要なスポットが強調表示されていることにお気づきかもしれません。このランドマークは、ユーザーが自身の現在地を確認し、探索中または訪問中の都市でどのように移動すればよいかを決定するための目印として役立ちます。

サンパウロ（左）とローマ（右）のランドマーク

このたび、クラウドベースのマップスタイル設定を使用して地図を作成することで、一般向け Google マップと同じエクスペリエンスをユーザーに提供できるようになりました。この機能は、ニューヨーク、ドバイ、パリ、ムンバイ、シンガポールなど、世界中の 100 の都市で利用可能です。地図にランドマークを表示するには、Cloud Console にログインし、スタイル エディタで [Points of interest] の機能タイプに移動して、[Marker Style] で [Illustrated] を選択します。

ビルディング フットプリントへの切り替えで地図機能をシンプルに

場合によっては、シンプルな地図のほうが便利なときもあります。高い建物が密集している都市では、高い建物を 3D で表示するとユーザーにはわかりづらくなる場合があります。そのため、建物の 3D 表示の他に、スタイル エディタのオプションとしてビルディング フットプリント機能を追加しました。ビルディング フットプリントにより、基本的な地図のバランスや構成が大きく変更されるため、建物が 3D 表示された複雑な地図を必要としないユースケースにも対応できます。

ビルディング フットプリント

スタイル エディタのメニューで [Landscape] から [Human-made] を選択し、ビルディング フットプリントを有効にした地図。

業界別に最適化された地図のスタイルでは、ランドマークとビルディング フットプリントに加えて詳細なストリート マップも使用可能

Google は今年の 1 月、旅行、不動産、小売、ロジスティクス業界向けに最適化された地図のスタイルの提供を開始しました。これによりお客様は、クラウドベースのマップスタイル設定を通じて、事前設定されたスタイル付き地図が利用できるようになりました。ランドマークは業界別に最適化されたすべてのスタイル付き地図で使用でき、ビルディング フットプリントは旅行業界向けのスタイル付き地図のみで使用できます。業界別に最適化されたスタイル付き地図をすでに利用している場合、それらの新機能は地図に自動で適用されるため、追加操作は不要です。この変更を無効にしたい場合は、スタイル エディタで機能をオフにします。

また、業界別に最適化された地図のスタイルに限定されますが、詳細なストリート マップが利用可能になります。この機能は、2020 年 8 月に Google I/O で発表したウェブ版とアプリ版の一般向け Google マップの新しい機能ですでにご覧になっているかもしれません。詳細なストリート マップは、現在サンフランシスコ、ニューヨーク、ロンドン、東京で使用できますが、2021 年の終わりまでに新たに 50 都市をサポートをする予定です。

詳細なストリート マップは、業界別に最適化された地図の全スタイルでデフォルトで有効になります。この表示設定は、新たに作成された設定メニューから必要に応じて変更できます。将来的に、すべてのクラウドベースのマップスタイル設定に、詳細なストリート マップ機能を完全導入できるようこの取り組みを続けています。

ランドマークとビルディング フットプリントおよび業界別に最適化された地図のスタイルの新バージョンは、Google Cloud Console 内のクラウドベースのマップスタイル設定からご利用いただけます。利用料金は Google Maps Platform の料金に含まれています。ランドマーク、ビルディング フットプリント、業界別に最適化された地図スタイルの使用方法については、開発者ドキュメントをご参照ください。また、クラウドベースのマップスタイル設定を開始するには、JavaScript のドキュメントをご覧ください。

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

Chrome のサイト分離により、悪意のあるウェブサイトが他のウェブサイトからデータを盗みにくくなる、重要なセキュリティ保護機能です。サイト分離は、Windows、Mac、Linux、Chrome OS ですべてのウェブサイトを他のサイトから保護し、ウェブサイトよりも権限が高い拡張機能とプロセスが共有されないことも保証します。Chrome 92 では、この機能をさらに拡張し、拡張機能が相互にプロセスを共有できないようにする予定です。これにより、既存の拡張機能の動作を一切妨げることなく、悪意のある拡張機能に対する保護が強化されます。

一方で、現在の Android のサイト分離は、パフォーマンスのオーバーヘッドを低く保つため、高価値サイトのみを保護しています。今回は、サイト分離の 2 つの改善についてお知らせします。これにより、Android ユーザーのサイト保護の対象となるサイトが増加します。Chrome 92 以降、ユーザーがサードパーティ プロバイダ経由でログインするサイトや、Cross-Origin-Opener-Policy ヘッダーが設定されているサイトに、サイト分離が適用されます。

Android のサイト分離の継続的な目標は、リソースの制約があるデバイスで、ユーザー エクスペリエンスを低下することなくセキュリティ層を追加することです。ほとんどの Android デバイスにとって、 すべての サイトでサイト分離をすると、コストがかかりすぎる点は変わりません。そのため、保護を追加することで最もメリットを得られるサイトを優先するように経験則を改善することを戦略としています。現在のところ、Chrome はユーザーがパスワードを入力してログインするサイトを分離しています。しかし、多くのサイトが、サードパーティのサイト（たとえば、「Google でログイン」を提供するサイト）を使って、パスワードを入力しなくても認証できるようになっています。ほとんどの場合、これは業界標準の OAuth プロトコルで実現されています。Chrome 92 以降のサイト分離は、一般的な OAuth のインタラクションを認識し、OAuth ベースのログインを利用するサイトを保護します。そのため、ユーザーがどのように認証をしても、データは安全です。

さらに Chrome は、新しい Cross-Origin-Opener-Policy（COOP）レスポンス ヘッダーに基づいてサイト分離をトリガーするようになります。このヘッダーは Chrome 83 以降でサポートされ、セキュリティを考慮したウェブサイトの運営者が、特定の HTML ドキュメントで新しいブラウジング コンテキスト グループをリクエストできるようにします。これにより、信頼できないオリジンからドキュメントが切り離されるので、攻撃者はサイトのトップレベル ウィンドウを参照したり操作したりできなくなります。このヘッダーは、SharedArrayBuffer などの充実した API を使う際に必要なヘッダーの 1 つでもあります。Chrome 92 以降のサイト分離では、ドキュメントの COOP ヘッダーがデフォルト以外の値だった場合、ドキュメントのサイトに機密データが含まれる可能性があるものとして扱い、サイト分離を開始します。そのため、Android でサイト分離によって確実にサイトを保護したいサイト運営者は、サイトで COOP ヘッダーを指定することでそれを実現できます。

これまでと同様、Chrome は新しく分離されたサイトをデバイスのローカルに保存します。ユーザーが閲覧履歴などのサイトデータを削除すると、そのリストもクリアされます。また、Chrome は、COOP によって分離されるサイトに一定の制限を課し、リストを最近使われたサイトのみに集中させ、リストが大きくなりすぎるのを防ぎ、悪用されないように保護しています（COOP サイトがリストに追加される前にそのサイトでのユーザー インタラクションを必須とするなど）。今後も、この新しいサイト分離モードには、最低 RAM しきい値（現在は 2 GB）を設けます。以上の点を踏まえたサイト分離の新たな改善では、Chrome の全般的なメモリ使用量やパフォーマンスに大きな影響を与えることなく、ユーザーの機密データを扱うたくさんのサイトに保護を追加できることがデータによりわかっています。

Android のサイト分離におけるこれらの改善に伴い、Android で Spectre に対応するための V8 ランタイム対策の無効化も行うことにしました。この対策は、サイト分離よりも効果が低く、パフォーマンスのコストがかかります。デスクトップ プラットフォームでは Chrome 70 以降でこの対策は無効化されており、今回の対応によって Android もそれと同等になります。Spectre からデータを保護したいサイトでは、COOP ヘッダーを設定することを検討してください。それによってサイト分離が行われます。

Android デバイスで完全な保護を実現したいユーザーは、chrome://flags/#enable-site-per-process から手動でサイト分離をオプトインすることもできます。これにより、すべてのウェブサイトが分離されるようになりますが、メモリの消費量は増加します。