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 ブログの全文を読むこともできます。

Google Workspace 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 Workspace デベロッパー ニュースレターへの登録もお忘れなく！


Reviewed by Eiji Kitamura - Developer Relations Team

計画サイクルをより明確にするために、今後のバージョンの Google Ads API について、2022 年のリリースと提供終了の暫定スケジュールをお知らせします。以下の日付は単なる想定であり、今後変更される可能性があることにご注意ください。また、リリースの追加や削除、メジャー版とマイナー版の切り替えが発生する可能性もあります。最新情報は、リリースノートやサポートの終了スケジュールでご確認ください。

注 : AdWords API は、2022 年 4 月に提供を終了する予定です。Google 広告アカウントの管理を続けるには、それまでにすべてのリクエストを Google Ads API に移行してください。
バージョン 計画されているリリースの
種類 * 		プロジェクトのリリース * プロジェクトの提供終了 *
v7 メジャー 2021 年 4 月 28 日（リリース済み） 2022 年 1 月 / 2 月
v8 メジャー 2021 年 6 月 9 日（リリース済み） 2022 年 3 月 / 4 月
v8_1 マイナー 2021 年 8 月 2022 年 3 月 / 4 月
v9 メジャー 2021 年 10 月 2022 年 6 月 / 7 月
v10 メジャー 2022 年 2 月 / 3 月 2022 年 10 月 / 11 月
v10_1 マイナー 2022 年 4 月 / 5 月 2022 年 10 月 / 11 月
v11 メジャー 2022 年 6 月 / 7 月 2023 年 3 月 / 4 月
v11_1 マイナー 2022 年 8 月 / 9 月 2023 年 3 月 / 4 月
v12 メジャー 2022 年 10 月 / 11 月 2023 年 6 月 / 7 月
* 想定であり、変更される可能性があります

さらに詳しく知りたい方へ

以下のリソースは、開発の計画を立てるうえで役立ちます。 ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。


- Google Ads API プロダクト マネージャー、David Stevens

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 の仕様変更に従ったもので、プラットフォームにも影響します。


Reviewed by Eiji Kitamura - Developer Relations Team


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

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

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

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

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


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

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

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

ビルディングフットプリント面の塗りつぶしと線幅も、それぞれ多様なカラーテーマで設定できます。ビルディング フットプリントを有効にするには、スタイル エディタで [Buildings] に移動し、[Building Style] で [Footprints] を選択します。

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


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

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

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


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

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

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



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

 
こういった検証可能なデータ構造を使えば、動作自体に検証可能性と透明性が組み込まれた要素を利用して、新たな種類のソフトウェアを構築できます。これは型強制に対する新たな形での防御になり、既存のエコシステムや新しいエコシステムにアカウンタビリティが導入されるとともに、規制機関、消費者、パートナーに対するコンプライアンスの実証も簡単になります。

証明書の透明性は、検証可能なデータ構造の大規模な利用例の 1 つであり、ブロックチェーンを利用せずに、インターネットの中核インフラストラクチャを保護する方法です。私たちはこのパターンを使い、ウェブを破壊することなく、あらゆる人が利用する既存システムに透明性とアカウンタビリティを導入することができました。
 
残念なことに、検証可能なデータ構造とそれに関連するパターンの機能はあるものの、デベロッパーがスケーラブルな実稼働品質のシステムを設計、開発、デプロイするうえで利用できるリソースは多くありません。

このギャップに対処するため、Google が証明書の透明性の構築に使ったプラットフォームを汎用化し、他の種類の問題にも応用できるようにしました。このインフラストラクチャは、何年にもわたってこのエコシステムの一部として使われているので、よく理解されており、実稼働システムに安心してデプロイできます。
そのため、このプラットフォームは、医療、金融サービス、サプライ チェーンなどの領域のソリューションで活用されています。さらにこのパターンを応用し、Google のプロダクトやサービスの他の問題にも、透明性とアカウンタビリティの特性を適用しています。

その実現に向けて、2019 年にこのプラットフォームを使い、Go Checksum Database によって Go 言語のエコシステムにサプライ チェーンの整合性を導入しました。このシステムにより、デベロッパーは、Go のエコシステムをサポートするパッケージ管理システムが、意図的、恣意的、偶発的に誤ったコードを公開しても、それが見逃されることはないという確証を得ることができます。Go ビルドの再現性によって、ソース リポジトリにあるものがパッケージ管理システムにあるものと一致するという保証を得られるので、これは特に有力です。このソリューションは、ソース リポジトリからコンパイルされた最終アーティファクトまで、一貫して検証可能なチェーンを提供します。

このパターンのもう 1 つの活用例が、最近発表された Sigstore という Linux Foundation とのパートナーシップです。このプロジェクトは、オープンソース エコシステムへのサプライ チェーン攻撃が増え続けていることへの対応です。

サプライ チェーン攻撃が成立するのは、チェーンのリンク部分に弱点があるからです。ビルドシステム、ソースコード管理ツール、アーティファクト リポジトリなどのコンポーネントは、すべて重要な実稼働環境なので、それ相応に扱う必要があります。そのためには、まず、チェーン全体の出所を検証できるようにする必要があり、Sigstore の目的はこれを実現することです。

現在、私たちは、このパターンとツールを使って、デバイスのファームウェアで、ハードウェアによって強制されるサプライ チェーンの整合性を実現する作業をしています。これにより、ファームウェアのサプライ チェーンに透明性とアカウンタビリティが導入されるので、私たちが日々利用するスマートフォンなどのデバイスに対するサプライ チェーン攻撃が減るものと期待しています。

以上のすべての例で、検証可能なデータ構造を使い、サプライ チェーンでアーティファクトの整合性を保証しています。これにより、顧客、監査者、内部セキュリティ チームは、サプライ チェーンのすべての関係者がそれぞれの責任を果たしていることを確信できます。これは、サプライ チェーンの利用者の信頼を得るうえで役立ち、発覚する可能性が増えるため内部関係者による立場の悪用を阻止できます。また、アカウンタビリティが導入され、関連システムが継続的にコンプライアンス義務を果たせるようになります。

このパターンを使う場合、最も重要なタスクは、どのデータを記録するかを定義することです。そこで、分類とモデリングのフレームワークを作成しました。これは、以上で説明したシステムに検証可能性を組み込む際の設計に役立ちました。ご活用いただければ幸いです。
検証可能なデータ構造の詳細については、transparency.dev ウェブサイトや、皆さん独自のアプリケーションで使っていただけるようにまとめたツールやガイダンスをご覧ください。


この記事は 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 は、位置情報、時刻、距離の精度、並びにバイクルートのデータ品質の改善に注力しています。

機械学習により位置情報の精度を向上

位置情報の精度はお客様の業務の基盤です。モバイル デバイスからの位置はさまざまな理由から途切れることがあり、ドライバーの位置情報が滞ったり、断続的になることがあります。

最近、Google のフリート管理プロダクトにおいて、特定の管理車両で使用するために、複数の位置情報に関する信号を取り入れ、その中から最も信頼性の高い位置情報を決定する手法を開発しました。その手法により、以下のような劇的な改善が見られました。
  • 位置情報の長い「滞り」がほぼなくなりました。車両の「滞り」とは、車両が動いていると考えられるものの測定された位置情報が元の位置から動いていない場合を指します。
  • 位置情報に関する信号が断絶するのを 52～86% 削減しました。この「断絶」とは車両の位置が急に、大きく移動したように見えることです。移動した距離と比較して車両の速度が現実的ではない場合に、「断絶」が発生したと判断されます。
  • 断絶された平均的な距離も 44～86% 削減しました。「断絶された距離」とは、「位置情報の断絶」が発生したと判断された場合の、2 つの連続した地点間の距離を表します。

インド国内の e コマース プラットフォームである Dunzo は、注文追跡機能を Google Maps Platform のオンデマンド配車および配達ソリューションに統合することでサポートへの問い合わせを 90% 減らすことができました。導入が簡単なこのソリューションの効果はすぐに現れ、Dunzo のバイク配達パートナー各社は、随時更新される位置情報を同期して滞りと途切れの発生を抑え、良質なユーザー エクスペリエンスを提供できるようになりました。


Dunzo は地図表示の精度を上げてカスタマー エクスペリエンスを向上。

車両の位置情報の信頼性が高いと、配車時のマッチングの質も向上します。つまり、配車を決定するために最適な判断ができる可能性が高くなるということです。これにより、ユーザーの待ち時間を低減でき、ドライバーの満足度が高くなり、キャンセルが減りました。


バイクルートにおける到着予定時刻の精度向上

多くの地域では、道路空間に余裕があるとは言い難く、自動車の保有には非常に高い費用がかかるため、バイクが主な移動手段となる場合もあります。バイク用のマップには、独自の経路案内、到着予定時刻、ナビゲーション機能が必要です。バイクの経路案内と到着予定時刻の推定精度の向上により、Gojek は、Wi-Fi がつながりにくい地域や、マップ上に存在しない道路がある地域でも、サービス全体の質を向上することができました。


ジャカルタにおけるバイクルート（左側）と自動車ルート（右側）の違い。 バイクは狭い道路を活用できるため、おすすめのバイクルートは 自動車ルートよりも短くなる。

最近では、バイクに特化してトレーニングされた新しい機械学習モデルの開発により、到着予定時刻の結果がさらに向上しました。こうしたモデルを使い、さまざまな地域やシナリオで生じる多様な混雑状況と交通の流れを処理しています。

到着予定時刻の精度は世界全体で、一般の運転者に対しては最大 8%、オンデマンド配車と配達の到着予定時刻の精度は最大 6% 改善しました。移動や注文の状況をリアルタイムに把握するのがユーザーにとって当たり前になったオンデマンド型経済においては、こうした改善がユーザー エクスペリエンスを大幅に向上します。

Google はこれからもお客様の要望とニーズに寄り添い、自動車とバイクの両面から、オンデマンド配車と配達サービスに革新をもたらしていきます。配車と配達の最適化において、一般ユーザー、ドライバー、フリート オペレーターすべてにとってシームレスなエクスペリエンスを構築することにより、お客様の成功に全力を尽くしています。

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



※この投稿は米国時間 2021 年 7 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

2021 年 10 月 12 日から 14 日に開催される Google Cloud Next の登録の受付が開始されました。

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 にご参加ください。



- Google Cloud, Chief Marketing Officer, Alison Wagonfeld





ウェブをブラウジングする Chrome ユーザーの安全を確保することは、Chrome にとって非常に重要です。実際、セキュリティは 4 つの基本原則の 1 つであり続けています。ときに、セキュリティのためにパフォーマンスが犠牲になることがあります。パフォーマンスの探求シリーズの次の投稿では、オンラインのユーザーの安全を確保するフィッシング検知アルゴリズムをどのように改善したかについてお伝えします。ここで紹介する改善によって、現在のフィッシング検知は 50 倍高速になり、電池使用量も少なくなっています。

フィッシング検知

Chrome は新しいページに移動するたびに、ページの一連のシグナルがフィッシング サイトのシグナルと一致するかどうかを評価します。これを行うため、アクセスしたページのカラー プロファイル（ページで表示される色の範囲と頻度）と、通常のページのカラー プロファイルを比較しています。たとえば以下のイメージでは、ほとんどがオレンジ色で、緑と少しばかりの紫が含まれていることがわかります。





サイトが既知のフィッシング サイトと一致した場合、Chrome は警告をし、個人情報を保護して認証情報が漏れることを防ぎます。


フィッシングの試みが検知された場合に表示される画面

プライバシーを守るため、Chrome のセーフ ブラウジング モードは、デフォルトでブラウザ外にイメージを送信することはありません。これはプライバシーにとってはよいことですが、マシンはイメージを分析する作業をすべて自力で行わなければならないことになります。

多くの場合、イメージ処理は重いワークロードになる可能性があります。イメージの分析には、一般的に「ピクセルループ」と呼ばれる処理をし、各ピクセルを評価する必要があるからです。最新のモニターの中には最大で 1400 万ピクセルを超えるものもあります。そのため、各ピクセルで単純な操作をするだけでも、積もり積もってかなりの CPU 使用量になります。フィッシング検知で各ピクセルに対してするのは、基本色を数える操作です。

この操作は、次のようになります。この数は、ハッシュマップと呼ばれる連想データ構造に格納されます。各ピクセルについて RGB のカラー値を抽出し、その数を色ごとに 1 つずつ、3 つの異なるハッシュマップのいずれかに格納します。





効率の改善

ハッシュマップに 1 つの項目を追加するのは高速ですが、この操作は何百万ものピクセルに対して行う必要があります。分析の質が損なわれないように、ピクセルの数を減らすことは避けますが、計算自体は改善できます。

次のようにパイプラインを改善します。
  • このコードでは、3 つのハッシュマップで RGB チャンネルを追跡するのではなく、ハッシュマップを 1 つだけ使って色ごとにインデックスを管理します。これで、数える回数が 3 分の 1 になります。
  • 連続したピクセルは、ハッシュマップで数える前に合計します。これにより、均一な背景色のサイトでは、ハッシュマップのオーバーヘッドがほぼゼロになります。
その結果、色を数える操作は次のようになります。ハッシュマップの操作が大幅に減っていることに注意してください。





高速化の成果

Chrome M92 以降のイメージベースのフィッシング分類は、50 パーセンタイルで最大 50 倍高速に、99 パーセンタイルで 2.5 倍高速に実行されます。平均で、ユーザーがフィッシング分類結果を取得するまでの時間は 1.8 秒から 100 ミリ秒に短縮されます。

これにより、Chrome を使ううえで 2 つのメリットがあります。1 つ目かつ最大のメリットは、同じ作業をするために消費する CPU 時間が減り、総合的なパフォーマンスが向上することです。CPU 時間が減れば、電池の消耗もファンが回る時間も少なくなります。
2 つ目は、結果を早く取得できるため、Chrome が警告を早く表示できることです。この最適化により、処理に 5 秒以上かかるリクエストの割合が 16.25% から 1.6% 未満に下がりました。この速度の改善により、特に悪意のあるサイトでパスワードの入力を防ぐという点で、セキュリティに大きな違いが生まれます。 

総じて、今回の変更により、Chrome のレンダラー プロセスとユーティリティ プロセスが使用する合計 CPU 時間を約 1.2% 削減できました。

Chrome の規模では、わずかなアルゴリズムの改善であっても、全体では膨大なエネルギー効率の向上になります。つまり、何世紀分にも相当する CPU 時間を節約できます。

今後もさまざまなパフォーマンスの改善についてお知らせしますので、ご期待ください。

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

Reviewed by Eiji Kitamura - Developer Relations Team


9 月 14 日（火）から 4 日間にわたり Open Cloud Summit を開催いたします。
アプリを高速に開発、改善することが重要な時代になってきています。Kubernetes やサーバーレス プラットフォームを利用した、モダンなシステム構築や開発、最新の運用管理について、わかりやすくお伝えします。
そして、お客様セッションでは、デンソー、日本経済新聞社、日本総合研究所、ビザスク、ブレインパッド、みんなの銀行にご登壇いただき、現場目線での Google Cloud 活用事例をお話しいただきます。

最終日の 17 日（金）には Open Cloud Summit で取り上げられる内容に合わせたハンズオンを Qwiklabs を用いてエンジニアの解説付きで開催いたします。

ご登録いただいた方から抽選で 100 名様に Google Cloud オリジナルのサニタイザー ケースをプレゼントいたします。
ぜひ、この機会にご登録ください。


お申込み受付中 : 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



ピックアップ セッション

■  Anthos & GKE は何を解決するのか ~ その価値を最大化する  3 つのヒント ~
　 中丸 良
　 Google Cloud　アプリケーション モダナイゼーション スペシャリスト

■ Cloud Ops で踏み出す Cloud Run 本番運用への第一歩
　 岩成 祐樹 
 　Google Cloud　カスタマー エンジニア

■ Apigee で作るオープン API エコノミー
　 関谷 和愛 
　 Google Cloud　Apigee カスタマーエンジニアリング Japan リード