Google Workspace がチーム コラボレーションの未来を再定義し、Google Chat のルームは Spaces へと進化している中で、現在のチャットルームですでに利用できる Webhook は、ユーザーが作業するチャットルームに直接非同期メッセージを提供できる便利な機能です。Chat の Webhook は、使いやすい機能で、Google Chat API を使ってユーザーと同期的に通信する専用のアプリケーションである Chatbot と違い、ボットではないアプリケーションで Google Chat への非同期メッセージングを実現します。この投稿では、Chat での Webhook の使い方について説明し、Google 内部で実際に使っているユースケースを紹介します。
Google Chat では、さまざまな目的でルーム（現在は Spaces）を作成して使用することができます。セールス サポートやカスタマー サービスといったトピックなど、テーマに沿ったルームもあれば、特定の部門や全社での会話のように、もう少し汎用的なルームもあります。しかし、こういったユースケースは、すべて人間の活動が中心になっています。そのため、これらへの依存が高まれば高まるほど、お互いのコミュニケーションにとって重要な方法になります。
Webhook を利用すると、他のシステムやアプリケーションから、ルームや会話のテーマに沿った最新の情報を導入できます。そのため、ルームのレベルが飛躍的に向上します。たとえば、セールス サポートのルームで Webhook を使うと、商談がまとまったタイミングや RFP の締め切りが近づいたタイミングで CRM システムからアラートをユーザーに通知できます。カスタマー サービスのルームで Webhook を使うと、リクエストに対して緊急のアラートを投稿し、チーム全体の注目を集めることができます。汎用的なルームで Webhook を使うと、部門のユーザーに今後の締め切りについて通知したり、株式市場の取引時間終了時に会社の株価を全社員に広く共有したりできます。Webhook を使うと、状況を問わず、効率的かつリアルタイムにデータや情報を提供できます。
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 から簡単にすべての最新情報を取得できるようになっています。
Updates ブログで Workspace の新機能についての投稿が公開されると、Google Workspace Updates「ボット」（内部的には、作成者の Justin Wexler にちなんで Google Wexbot と呼ばれています）がチャットルームに新しいスレッドを追加し、そこに投稿のタイトルとメイン コンテンツの最初の 250 文字を送信します。これにより、ルームのメンバーは新機能についてすばやく把握できるだけでなく、ブログの内容についてすぐに議論を始めることもできます。メンバーは、機能リリースについて質問したりコメントを追加したりできるので、はるかに高度なコラボレーション体験が実現します。また、[READ MORE] をクリックするだけで Updates ブログの全文を読むこともできます。
このような最新情報をタイムリーに受け取るコミュニティのメンバーにとって、この「ボット」は魔法のように思えるかもしれません。実際には、これは魔法でも従来型のチャットボットでもありません。そのため、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「ボット」を追加してみたい方や、他のユースケースを実現するために Apps Script を使って Webhook 経由で Google Chat に非同期メッセージを送る方法を知りたい方のために、GitHub でプロジェクトを公開しています。ぜひ確認して、実装してみてください。
Google Chat Updates Bot Project - GitHub
README | Apps Script Code.js
Google Workspace の Chatbot や Webhook の詳細については、以下のリソースをご覧ください。
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 回タップするだけでログインや登録をすることができ、認証情報を覚えたり、パスワードを作成したりする必要はありません。パートナーは、この認証ソリューションを使って大きな成果を上げています。劇的に手間が少なくなることで、ウェブサイトやアプリでのユーザーのログイン率や登録率が増加しました。
Google Identity Services プロダクトは、クリック ジャッキングやピクセル トラッキングなどの脆弱性、その他の脅威からの保護も考慮されています。そのため、ユーザーは安心してウェブサイトやアプリを利用できます。すべての Google アカウントには、強固な不正利用対策や不正防止システムが適用されています。そのため、Google Identity Services を使うことで、重複アカウントや不正アカウントによるリスクを軽減でき、サポートの負荷も減少します。
さらに、Google でログインするためのボタンの改善版をロールアウトし、リピーターに対してユーザー固有の詳細情報を表示するようにしました。これにより、選択されるユーザー アカウントが表示されるようになります。Google でログインするボタンでは、ウェブ全体での UI/UX の整合性も向上しており、プラットフォーム全体で信頼性とセキュリティを向上することができます。
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 オリジン トライアル デベロッパー コンソールをご覧ください。
credentialless キーワードを使って、Cookie やクライアント証明書などの認証情報を省略したクロスオリジン no-CORS リクエストが可能になりました。COEP: require-corp と同じように、クロスオリジン分離も有効化できます。
credentialless
COEP: require-corp
SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。現在は COEP: require-corp が存在し、クロスオリジン分離の有効化に利用されています。これは確実に機能しますが、すべてのサブリソースで明示的にオプトインしなければならないので、大規模な導入は難しいことがわかっています。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト（Google Earth、一般的なソーシャル メディア、フォーラムなど）では、依存関係の問題が発生します。
SharedArrayBuffer
Multi-Screen Window Placement API を使えば、マシンに接続された任意のディスプレイへのウィンドウの配置、その配置の保存、任意のディスプレイでのウィンドウの全画面表示が可能です。プレゼンテーション アプリでこの API を使うと、ある画面にスライドを、別の画面に発表者用のノートを表示できます。アートや音楽の制作アプリでは、2 つ目の画面にパレットを配置できます。また、レストランなら、座席側にタッチスクリーン メニューを、従業員側に別のウィンドウを表示できます。この API は、最初のオリジン トライアルでのデベロッパーからのフィードバックに基づいて形状や人間工学が改善され、2 回目のオリジン トライアルに入ります。
ウィンドウ コントロール オーバーレイは、ウィンドウ全体を覆うようにアプリのクライアント領域を拡張します。この領域には、タイトルバー、ウィンドウのコントロール ボタン（閉じる、最大化/復元、最小化）も含まれます。ウェブアプリのデベロッパーは、ウィンドウ コントロール オーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされたデスクトップ版ウェブアプリを OS のアプリのように見せることができます。詳しくは、PWA のタイトルバーのウィンドウ コントロール オーバーレイをカスタマイズするをご覧ください。
URL ハンドラとしての PWA を使うと、music.example.com のようなアプリが、自分自身を https://music.example.com、https://*.music.example.com、https://🎵.example.com といったパターンに一致する URL のハンドラとして登録できます。これにより、インスタント メッセンジャー アプリケーションやメール クライアントなどの PWA の外部からのリンクが、ブラウザのタブではなく、インストールした PWA で開くようになります。
music.example.com
https://music.example.com
https://*.music.example.com
https://🎵.example.com
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
ウェブバンドルは、複数のリソースをバンドルできるフォーマットを使って大量のリソースを効率的に読み込むための新たなアプローチです。この機能は、以前のリソース バンドルへのアプローチが抱えていた問題に対処します。
一部の JavaScript バンドラの出力は、HTTP キャッシュをうまく扱うことができず、設定が難しくなる場合もあります。バンドルされた JavaScript でも、すべてのバイトがダウンロードされるまで実行を待つ必要があります。複数のサブリソースを読み込む場合、ストリーミングと並列化を使用するのが理想ですが、これは 1 つの JavaScript ファイルでは実現できません。JavaScript モジュールでは、決定的実行の関係で、リソースツリー全体がダウンロードされるのを待ってから実行する必要があります。
WebXR アプリケーションで、ユーザーの環境に存在する平面のデータを取得できるようになります。これにより、拡張現実アプリケーションでさらに臨場感の高い体験を実現できます。この機能がない場合、デベロッパーは getUserMedia()（navigator と MediaDevices で利用可能）のデータに対して独自のコンピュータ ビジョン アルゴリズムを実行してユーザーの環境に存在する平面を検知するしかありませんでした。そのため、このようなソリューションでは、ネイティブの拡張現実機能に匹敵する質や精度を実現したり、ワールド スケールをサポートしたりすることはできませんでした。
getUserMedia()
navigator
MediaDevices
静的メソッドである AbortSignal.abort() は、すでに中止された AbortSignal オブジェクトを新しく作成します。これは Promise.reject() と同じような考え方で、デベロッパーの人間工学を改善します。
AbortSignal.abort()
AbortSignal
Promise.reject()
ウェブ デベロッパーは、中止された AbortSignal オブジェクトをさまざまな目的に役立てることができます。これを使って、作業をしないように JavaScript API に指示します。現在、すでに中止された AbortSignal オブジェクトを作るには、複数行のコードが必要です。AbortSignal.abort() を使うと、次の 1 行で作成できます。 return AbortSignal.abort();
return AbortSignal.abort();
flexbox と flex 項目が位置ベースの alignment キーワードに従うようになります。これまでの flexbox は、center、flex-start、flex-end のみに従っていました。追加された alignment キーワード（start、end、self-start、self-end、left、right）を使うと、flex 項目の位置をさまざまな書き込みモードや flex フローに簡単に合わせることができます。
center
flex-start
flex-end
start
end
self-start
self-end
left
right
これらの追加キーワードがない場合、書き込みモード、テキストの方向、flex の逆方向プロパティ（flex-direction: row-reverse、flex-direction:column-reverse、align-content: wrap-reverse）を変えるたびに、キーワードの値を変更する必要があります。今回実装されたキーワードを使うと、alignment を一度設定するだけで済みます。
flex-direction: row-reverse
flex-direction:column-reverse
align-content: wrap-reverse
Error() コンストラクタが cause という新しいオプション プロパティをサポートし、これはプロパティとしてエラーに割り当てられます。これにより、エラーを条件でラップするという不必要で複雑な作業をすることなく、エラーをチェーンさせることができます。
Error()
meta[name="theme-color"] で meta 要素の "media" 属性が反映されます。これにより、ウェブ デベロッパーがメディア クエリに基づいてサイトのテーマカラーを調整できるようになります（ダークモードとライトモードなど）。最初に一致したものが選択されます。
meta[name="theme-color"]
HTMLMediaElement.controlsList プロパティが noplaybackrate をサポートします。これにより、ブラウザが公開する再生速度のコントロールをウェブサイトで有効化または無効化できるようになります。ブラウザ ベンダーが再生速度のコントロールをメディア コントロールに追加したことで、デベロッパーはこの新しいコントロールの表示を制御する方法が得られます。新しいプロパティは、HTMLMediaElement.controlsList のサンプルの noplaybackrate で試すことができます。
noplaybackrate
HTMLMediaElement.controlsList
CSS ユーザー プリファレンス メディア機能の prefers-color-scheme は、ページで提供する必要がある CSS の量とページ読み込み時のユーザー エクスペリエンスに大きな影響を与える可能性があります。新しい Sec-CH-Prefers-Color-Scheme Client-Hint ヘッダーを使うと、サイトのリクエスト時にオプションでユーザー プリファレンスを取得できるので、サーバーは適切な CSS をインラインで提供できます。そのため、一瞬だけ適切でないカラーテーマが表示されることを回避できます。
prefers-color-scheme
Sec-CH-Prefers-Color-Scheme
このバージョンの Chrome には、User-Agent Client-Hint API に 4 つの新機能と変更点が追加されています。
Sec-CH-UA-Platform
低エントロピー ヒントとは、あまり多くの情報を公開しないヒントや、他の方法で簡単に検出できるため現実的に隠蔽するのは難しい情報を提供するヒントです。Client-Hint においては、関連するオリジンがリクエストしたかどうかにかかわらず、また関連するフレームがファースト パーティかサード パーティかにかかわらず、すべてのリクエストで利用できるヒントを指します。
デスクトップ向け Chrome と Android Chrome の両方が同じ Google アカウントにログインしている場合、PC でも WebOTP API がサポートされます。WebOPT API は、プログラムによってオリジン宛ての特定の形式の SMS メッセージからワンタイム コードを読み取る機能を提供するため、ログイン時のユーザーの手間を減らすことができます。これまで、この機能は SMS がサポートされるモバイル デバイスのみで利用できました。
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.3 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
新しい Boolean 型のプロパティである Object.hasOwn は、使いやすい静的メソッド バージョンの Object.prototype.hasOwnProperty を提供します。
Object.hasOwn
Object.prototype.hasOwnProperty
このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
ポート 989 と 990 による HTTP、HTTPS、FTP サーバーへの接続が失敗するようになります。これらのポートは FTPS プロトコルで使われていますが、FTPS は Chrome では実装されていません。ただし、悪意のあるウェブページが FTPS サーバーに対して、綿密に作成された HTTPS リクエストを使ったクロスプロトコル攻撃を仕掛ける可能性があります。これは、ALPACA 攻撃の緩和策になります。
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 の仕様変更に従ったもので、プラットフォームにも影響します。
この記事は 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] を選択します。
ビルディングフットプリント面の塗りつぶしと線幅も、それぞれ多様なカラーテーマで設定できます。ビルディング フットプリントを有効にするには、スタイル エディタで [Buildings] に移動し、[Building Style] で [Footprints] を選択します。
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 から手動でサイト分離をオプトインすることもできます。これにより、すべてのウェブサイトが分離されるようになりますが、メモリの消費量は増加します。
この記事は Product Manager, Google Maps Platform の Yaron Fidler と Product Manager, Google Maps Transportation の Johann Lau による Google Maps Platform Blog の記事 "Elevate customer and driver experiences with improved accuracy, reliability, and travel modes" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
昨年、Google は新たにオンデマンド配車および配達ソリューションをリリースしました。このサービスは、企業のオペレーション改善を助けることに加え、予約から配車・配達までのカスタマージャーニーを、ドライバーとお客様双方にとって変革することを目的としています。オンデマンド配車と配達において、時間はきわめて重要です。ユーザーが配車の予約やフード デリバリーの注文をする際には、シームレスなエクスペリエンスとリアルタイムの情報更新が求められます。現在 Google は、位置情報、時刻、距離の精度、並びにバイクルートのデータ品質の改善に注力しています。
位置情報の精度はお客様の業務の基盤です。モバイル デバイスからの位置はさまざまな理由から途切れることがあり、ドライバーの位置情報が滞ったり、断続的になることがあります。
インド国内の e コマース プラットフォームである Dunzo は、注文追跡機能を Google Maps Platform のオンデマンド配車および配達ソリューションに統合することでサポートへの問い合わせを 90% 減らすことができました。導入が簡単なこのソリューションの効果はすぐに現れ、Dunzo のバイク配達パートナー各社は、随時更新される位置情報を同期して滞りと途切れの発生を抑え、良質なユーザー エクスペリエンスを提供できるようになりました。
Dunzo は地図表示の精度を上げてカスタマー エクスペリエンスを向上。
車両の位置情報の信頼性が高いと、配車時のマッチングの質も向上します。つまり、配車を決定するために最適な判断ができる可能性が高くなるということです。これにより、ユーザーの待ち時間を低減でき、ドライバーの満足度が高くなり、キャンセルが減りました。
多くの地域では、道路空間に余裕があるとは言い難く、自動車の保有には非常に高い費用がかかるため、バイクが主な移動手段となる場合もあります。バイク用のマップには、独自の経路案内、到着予定時刻、ナビゲーション機能が必要です。バイクの経路案内と到着予定時刻の推定精度の向上により、Gojek は、Wi-Fi がつながりにくい地域や、マップ上に存在しない道路がある地域でも、サービス全体の質を向上することができました。
ジャカルタにおけるバイクルート（左側）と自動車ルート（右側）の違い。 バイクは狭い道路を活用できるため、おすすめのバイクルートは 自動車ルートよりも短くなる。
最近では、バイクに特化してトレーニングされた新しい機械学習モデルの開発により、到着予定時刻の結果がさらに向上しました。こうしたモデルを使い、さまざまな地域やシナリオで生じる多様な混雑状況と交通の流れを処理しています。
到着予定時刻の精度は世界全体で、一般の運転者に対しては最大 8%、オンデマンド配車と配達の到着予定時刻の精度は最大 6% 改善しました。移動や注文の状況をリアルタイムに把握するのがユーザーにとって当たり前になったオンデマンド型経済においては、こうした改善がユーザー エクスペリエンスを大幅に向上します。
Google はこれからもお客様の要望とニーズに寄り添い、自動車とバイクの両面から、オンデマンド配車と配達サービスに革新をもたらしていきます。配車と配達の最適化において、一般ユーザー、ドライバー、フリート オペレーターすべてにとってシームレスなエクスペリエンスを構築することにより、お客様の成功に全力を尽くしています。
Google Cloud を代表するこのイベントは、今年は Google Cloud のようにオープンで柔軟性に富んだ内容となっており、最適な参加方法を自由にお選びいただけます。参加者一人ひとりがいっそう自分に合った体験ができるように、Next ’21 はカスタマイズ可能なデジタル アドベンチャーとして構成されています。
期間中は毎日、ライブ配信と基調講演をお届けして最新のリリースを紹介し、お客様とパートナーが Google Cloud や Google Workspace を使用して今日最大のビジネス課題に取り組む方法を共有いたします。参加者はこの 3 日間、ご自身の興味やスケジュールに合わせてオンラインでのインタラクティブな体験に参加したり、オンデマンドのセッションに参加したりすることができます。また、世界各国の視聴者向けのセッションやプログラムもご用意しています。
エキスパートによるリアルタイムの Q&A やブレイクアウト セッションから、Google の最新技術を活用した臨場感のあるデモや実際のアプリケーションまで、さまざまな企画を楽しめる Next ’21 を、情報を集めたり、刺激を受けたり、専門知識を広げたりするための場としてぜひご活用ください。今すぐ登録して、あなただけの Next ’21 を計画しましょう。
誰もが気軽にこのイベントを体験できるよう、今年の Google Cloud Next は無料とすることにいたしました。10 月 12 日の開催に向けて、イベントの最新情報、興味や関心に基づいた主要なセッション、Google Cloud コミュニティと交流できる特別な機会といった情報をこれから順次ご案内いたします。
ぜひ Google Cloud Next にご参加ください。
総じて、今回の変更により、Chrome のレンダラー プロセスとユーティリティ プロセスが使用する合計 CPU 時間を約 1.2% 削減できました。
お申込み受付中 : https://goo.gle/OCS_gcbg
名 称 Open Cloud Summit 日 程 9 月 14 日（火）～ 9 月 16 日（木）14:00 - 18:30 （Cloud Study Jam ハンズオン は 9 月 17 日（金） 14:00-17:00 に開催）対 象 開発エンジニア、インフラエンジニア、運用エンジニア参加費 無料（事前登録制）登 録 https://goo.gle/OCS_gcbg
