Google Cloud Next（2021 年 10 月 12～14 日）の開催まであと 1 か月を切りました。この無料のフラッグシップ イベントで皆様にお会いできるのを心待ちにしております。イベントの全カタログを公開いたしましたので、ご自身にぴったりのコンテンツをお探しください。エキスパートによるライブ Q＆A をはじめ、ブレイクアウト セッション、没入型のデモ、Google Cloud の実際のユースケースをご覧いただけます。今年は、カスタム再生リストを作成して、視聴するセッションをパーソナライズすることや、見逃さないようにリマインダーやカレンダー通知を設定することもできます。
Next '21 に参加して、クラウドの現在と未来に関する情報を入手しましょう。業界をリードするデータや分析から、最適化、モダナイゼーション、セキュリティ、サステナビリティまで、Google Cloud をさらにオープンかつ高速で、柔軟性と信頼性の高いものにするために、Google が世界最大のプライベート ネットワークをどのように拡張しているかをご覧ください。11 のトラックにわたる 130 以上のセッションは、トラックやカテゴリなどでフィルタしたり、お気に入りのセッションをブックマークして後から視聴したりすることができます。
毎日、Google Cloud CEO の Thomas Kurian や Google Cloud 技術インフラストラクチャ部門シニア バイス プレジデント Urs Hölzle などの業界リーダーによるライブ配信と基調講演をご覧いただけます。一部のセッションをご紹介します。
Google Cloud の Twitter で、クラウドのエキスパートやエグゼクティブが作成した個人的な再生リストを紹介していますのでぜひチェックしてください。また、再生リスト作成ツールを使って、ご自身で作成した再生リストを知り合いや同僚と共有しましょう。
情報を入手し、刺激を受けて、専門知識を広げるために、ぜひご参加ください。今すぐ登録して、あなただけの Next '21 を計画しましょう。
Google は、 スタートアップを対象としたオンライン アクセラレーター プログラム「Google for Startups Accelerator Class 4 」を実施します。2021 年 9 月 16 日（木）より参加スタートアップの応募を開始し、2022 年 2 月 よりプログラムを開始いたします。詳細なスケジュールについては プログラムのウェブサイトをご確認ください。
Google for Startups Accelerator では、SDGsに沿った持続可能な産業化の促進、AIやIoTなどの技術を活用することで、経済発展と社会的課題の解決を実現するスタートアップを支援しています。
過去に日本のアクセラレーター プログラムに参加した Eco-Pork は、養豚とテクノロジーを繋ぐことで、養豚生産者の労働生産性の向上と共に、透明性の高い安心な食糧供給を統合的に支援しています。 また、同じく過去の ヨーロッパのアクセラレーターに参加した mDoc は、慢性疾患のある人々がアプリを通じて治療を受けられるように支援することで、医療と健康の分野に取り組んでいます。
このプログラムは、すでに商品またはサービスを市場に投入し、市場的価値が見込まれ、スケールする将来性があるスタートアップを対象に、これからの成長に備えるためのサポートを提供します。テクノロジーを活用した社会、経済、環境といった様々な分野の問題解決への取り組みを加速し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることを期待しています。
ぜひご応募ください。
Serverless Expeditions がお送りする動画ミニシリーズ Serverless Migration Station は、Google Cloud で実行しているアプリケーションを最新化し、サーバーレス コンピューティング プラットフォームに移行するデベロッパーをサポートすることを目的としています。これまでのエピソードでは、従来の古い App Engine（標準環境）サービスを、Cloud Datastore などの Google Cloud の新しい同等なスタンドアロン機能に移行する方法を紹介しました。今回のエピソードは、App Engine から完全に移行し、アプリをコンテナ化して Cloud Run で実行するという点で少し異なります。
ここ 10 年ほどで、業界がアプリケーションのデプロイ メカニズムとしてコンテナ化に向かっていることに、疑問の余地はほとんどありません。しかし、初期の App Engine デベロッパーは、のちに柔軟な環境が利用できるようになるまで、Docker やコンテナを使うことはできませんでした。現在のデベロッパーは、ますますオープンになっている Google Cloud からさまざまな選択肢を選択できます。Google は App Engine の長期サポートを表明しており、ユーザーにとってアプリのコンテナ化は必須ではないので、この移行は任意です。そのため、主にアプリのデプロイ戦略にコンテナ化を追加し、明示的に Cloud Run への移行を考えているデベロッパー向けの内容になります。
アプリのコンテナ化について考えている方のために、動画ではその主な理由について説明しています。開発言語やバイナリの利用など、従来のサーバーレスの制約を受けることはありません（柔軟性）。コード、依存関係、コンテナのビルドとデプロイの手順が変わらなければ、同じイメージを確実に再作成できます（再現性）。必要に応じて、アプリケーションを他の場所にデプロイしたり、動作していた以前のイメージにロールバックしたりすることができます（再利用性）。さらに、アプリをホストする場所には、さまざまな選択肢があります（移植性）。
従来の App Engine サービスは、バンドルされた一連の独自 API を通して利用します。ご想像どおり、このサービスは Cloud Run では利用できません。そのため、アプリをコンテナ化して Cloud Run で実行するには、その準備が整っている必要があります。これは、Google Cloud の同等なスタンドアロン機能か、他のサードパーティの代替機能に移行された状態を指します。たとえば、最近のエピソードでは、Datastore にアクセスするために、App Engine の ndb を Cloud NDB に移行する方法について説明しています。
このような移行の動画を公開し始めたのは最近のことですが、デベロッパーはすでにコードサンプルや Codelab チュートリアルにアクセスできるようになっており、さまざまな移行が行われています。今回の動画では、従来のサービスから切り離され、Cloud Run でコンテナ化する準備が整った Python 2 と 3 のサンプルアプリを紹介します。Datastore にアクセスする Python 2 App Engine アプリでは Cloud NDB を、Python 3 ユーザーは Cloud Datastore を使うことになるでしょう。これが移行の開始点になります。
ここで行うのは実行プラットフォームの切り替え「だけ」であるため、アプリケーション コード自体は変更しません。必要になる移行は、アプリの設定を App Engine から Cloud Run に変更することだけです。具体的には、app.yaml、appengine_config.py、lib フォルダなどの App Engine アーティファクトは、Cloud Run で使うことはないため、削除します。また、コンテナをビルドするため、Dockerfile を導入します。app.yaml ファイルでこれよりも複雑な設定が行われているアプリでは、Cloud Run で同等の機能を持つ service.yaml ファイルが必要になります。この場合、app.yaml を service.yaml に変換するツールを使うと便利です。ベスト プラクティスに従うなら、.dockerignore ファイルも追加します。
app.yaml
appengine_config.py
lib
Dockerfile
service.yaml
.dockerignore
App Engine と Cloud Functions はアウトソーシングのようなもので、Google Cloud が自動的に gunicorn などのデフォルトの HTTP サーバーを提供します。Cloud Run では、ユーザーがコンテナ イメージを提供してサーバーにバンドルしなければならないので、もう少し自作度が高くなります。この場合、下のスクリーンショットのように、明示的に gunicorn が選択され、既存の requirements.txt に記載された必須パッケージ ファイルの最上部に追加されます。また、最後のステップとして gunicorn を起動してアプリのサービスを開始する Dockerfile も示しています。Python 2 の Dockerfile との唯一の違いは、a）Cloud Datastore ではなく Cloud NDB パッケージ（google-cloud-ndb）が必須である点と、b）Python 2 ベースイメージから始める点です。
gunicorn
requirements.txt
google-cloud-ndb
Python 3 の requirements.txt と Dockerfile
デベロッパーの皆さんに移行手順を説明するため、動作するアプリ（START）から始めて、必要なアップデートをし、最終的に動作するアプリ（FINISH）を完成させます。今回の移行では、Python 2 サンプルアプリの START は Module 2a のコードで、FINISH は Module 4a のコードになります。同じように、Python 3 アプリの START は Module 3b のコードで、FINISH は Module 4b のコードです。このようにすれば、移行がうまくいかなくても、いつでも START にロールバックしたり、自分のソリューションと FINISH を比較したりできます。自分のアプリケーションでこの移行を検討している方には、サンプルアプリで試してから、自分のアプリについて検討することをお勧めします。動画に加えて、順を追ってこのエクササイズについて説明する Codelab もあるので、ガイダンスとしてお使いください。
すべての移行モジュール、動画（公開されている場合）、Codelab チュートリアル、START と FINISH のコードなどは、移行リポジトリにあります。近いうちに、Java 8 などの以前のランタイムについても説明したいと考えているので、ご期待ください。Module 5 でも、引き続き App Engine から Cloud Run への移行について説明しますが、コンテナ、Docker、Dockerfile についての知識がなくても大丈夫です。開発ワークフローを最新化し、コンテナと CI/CD パイプライン作成などのベスト プラクティスを活用することは、常に単純とは限りません。このようなコンテンツが、その方向に進む皆さんのお役に立つことを願っています。
Google は、ウェブでユーザーの個人情報を守るために、アプリやサービスへのログインをデフォルトで安全なものにする取り組みを続けています。先日は、その実現に向けて、Identity API ファミリーの新たな一員である Google Identity Services についてお知らせしました。これは、複数の ID サービスを 1 つのソフトウェア開発キット（SDK）にまとめたものです。今回は、ログイン方法を減らし、ユーザー エクスペリエンスをシンプルにする取り組みの一環として、ウェブアプリ向けに提供していた JavaScript ベースの Google プラットフォーム ライブラリのサポートを 2023 年 3 月 31 日をもって完全に終了することをお知らせします。
サポートの終了は、Google Sign-in JavaScript ライブラリを使っているウェブアプリにのみ影響します。現在のウェブページで Google プラットフォーム ライブラリ（apis.google.com/js/platform.js）を読み込んでいる場合は、影響を受けるので、新しい Sign In With Google クライアント ライブラリに移行する必要があります。
apis.google.com/js/platform.js
アプリやプラットフォームでは、Google プラットフォーム ライブラリを使ってユーザーのログイン認証のみのフロー、データ共有のための認可フロー（ユーザーのカレンダーや写真の共有など）、またはその両方を同時にサポートできます。今回の移行は、認証フローと認可フローの両方が対象になります。
アプリやプラットフォームでは、Google が提供する複数の認証方法と認可方法を使うこともできます。以下は、今回のサポートの終了のお知らせには影響されません。
ユーザーのログインを改善するという継続的な取り組みの一環として、Sign In With Google 用の新たな JavaScript ライブラリをリリースしました。これまでの認証や認可の機能に加えて、ユーザーの視認性や信頼性を向上させ、ログインの手間を減らすことができる新たなユーザー エクスペリエンスも提供します。
新しい JavaScript ライブラリへの移行にはたくさんのメリットがありますが、その一部を紹介します。
ユーザーには次のように表示されます。
詳細は、Google Identity Services のプロダクトのお知らせをご覧ください。
詳しい情報は、デベロッパー サイトに掲載されています。技術サポートを受けたい方は、Stack Overflow で google-signin タグを確認してください。提案やフィードバックは、gis-migration-feedback@google.com にお送りください。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 8 月 26 日の時点で Chrome 94 はベータ版です。
既存のメディア API（HTMLMediaElement、Media Source Extensions、WebAudio、MediaRecorder、WebRTC）は高レベルで、特定の用途に特化しています。低レベルのコーデック API は、遅延の影響を受けやすいゲームのストリーミング、クライアント側のエフェクトやコード変換、ポリフィル対応のメディア コンテナのサポートなど、新たな用途に適しています。JavaScript や WebAssembly によるコーデック実装のように、ネットワークや CPU のコストが増加することはありません。
HTMLMediaElement
WebAudio
MediaRecorder
WebCodecs API は、すでにブラウザに組み込まれているメディア コンポーネントをプログラマーが利用できるようにすることで、このような不足を解消します。具体的には、次のような内容です。
この機能は Chrome 93 でオリジン トライアルを終えており、現在はデフォルトで有効です。詳しくは、WebCodecs による動画処理をご覧ください。
WebGPU API は、ウェブ用の WebGL と WebGL2 グラフィックス API の後継です。「GPU コンピュート」などの最新機能や、GPU ハードウェアへの低オーバヘッド アクセス、パフォーマンスや予測可能性の向上などが導入されています。既存の WebGL インターフェースはイメージの描画用に設計されたもので、かなりの労力をかけなければ他の用途の計算は行えませんでしたが、その点が改善されています。
WebGPU は、Direct3D 12、Metal、Vulkan といった最新のコンピュータ グラフィックス機能を公開し、グラフィックス プロセッシング ユニット（GPU）で行われるレンダリングや計算の操作をします。以前のテクノロジーと比べた場合の WebGPU の利点は以下のとおりです。
この機能は、Chrome 99 での導入を目指して、Chrome 94 からオリジン トライアルが始まります。詳しくは、WebGPU で最新の GPU 機能にアクセスするをご覧ください。
ユーザーの操作に的確に応答し、時間が経っても応答性が低下しないウェブアプリを構築するのは困難です。応答性を阻害する主な原因の 1 つがスクリプトです。インクリメンタル サーチ機能について考えてみてください。この機能を搭載したアプリは、ユーザーの入力に追いつきつつ、結果をフェッチして表示する必要があります。その際、アニメーションなど、ページで起きていることは考慮されませんが、アニメーションはスムーズにレンダリングする必要があります。
通常この問題には、メインスレッドの作業を分割してスケジュールすることで対処できます。具体的には、適切なタイミングで作業を非同期的に実行します。しかし、このアプローチ自体にも問題があります。たとえば、デベロッパーがどのように優先度を設定しようと、メインスレッドでは時間の奪い合いが生じています。メインスレッドはデベロッパーが設定した優先度を認識しないだけでなく、fetch() 操作やガベージ コレクションといったブラウザのタスクも行っているからです。
fetch()
scheduler.postTask() メソッドを使うと、デベロッパーが OS のブラウザのスケジューラで 3 段階の優先度（user-blocking、user-visible、background）を指定してタスク（JavaScript のコールバック）をスケジュールできるようになるので、このスケジュールのジレンマを解消できます。また、動的にタスクをキャンセルしたり、優先度を変更したりできる TaskController インターフェースも公開されます。
scheduler.postTask()
TaskController
この機能は Chrome 93 でオリジン トライアルを終えており、現在の Chrome ではデフォルトで有効です。その他の新しいオリジン トライアルや完了したオリジン トライアルの一覧については、以下のオリジン トライアルのセクションをご覧ください。
このバージョンの Chrome には、以上の項目の他に、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
Chrome では、新しい HTTP ステータス コードである 103 Early Hints のテストが行われています。これは、早い段階でサブリソースをプリロードするためのものです。 <link rel=preload> などの link ヘッダーを含む 103 レスポンスを受け取ると、Chromium は最終的なレスポンスを受け取る前に、指定されたリソースのプリロード（またはプリコネクトやプリフェッチ、あるいはそのすべて）を試みます。ウェブ デベロッパーはこの方法を使って、アプリやサイト、ページを最適化できます。
<link rel=preload>
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
このアップデートにより、CanvasRenderingContext2D オブジェクトと ImageData オブジェクトのデフォルトのカラースペースが sRGB であることが正式に明文化されます。そのため、CanvasRenderingContext2D インターフェースが完全にカラー マネジメントされる（すべての入力が描画キャンバスのカラースペースに変換される）ことが明確になります。これまでは、上記の動作は慣習上のものであり、明文化はされていませんでした。今回のアップデートで、以下の点が変更されます。
CanvasRenderingContext2D
ImageData
現在、CanvasRenderingContext2D で表示されるコンテンツは、sRGB カラースペースに限定されていますが、このカラースペースには最新のディスプレイやカメラほどの機能はありません。今回の機能で、Display P3 カラースペースを使用する CanvasRenderingContext2D オブジェクトを作成できるようになります。さらに、CanvasRenderingContext2D の色の動作に関して、いくつかの曖昧だった点が明確になります。
VirtualKeyboard インターフェースには、仮想キーボードの表示や非表示のタイミングをコントロールするメソッドやプロパティが含まれています。また、仮想キーボードがページのコンテンツを遮ると、仮想キーボードのサイズを含むイベントが発行されます。仮想キーボードは画面に表示されるキーボードで、ハードウェア キーボードが利用できない場合の入力に使います。
VirtualKeyboard
ハードウェア キーボードとは異なり、仮想キーボードは想定される入力に合わせて形状を変えることができます。デベロッパーは、inputmode 属性によって仮想キーボードの表示形状をコントロールできますが、仮想キーボードの表示や非表示のタイミングのコントロールには制限がありました。
inputmode
transform-style: preserve-3d と perspective プロパティが仕様に準拠します。preserve-3d プロパティを使うと、子要素を親の 3D シーンに追加できます。また、perspective プロパティは子要素に透視変換を適用します。この変更が行われる前の Chromium は、両方の効果を DOM ツリーではなく内包するブロック階層に基づいて適用し、変換関連のプロパティがない要素にも効果を拡張できるようになっていました。
Chrome は、flex-basis プロパティと flex 省略記法の値として、キーワード content、min-content、max-content、fit-content をサポートします。content キーワードを使うと、flex-basis と優先されるサイズ プロパティ（width または height）の両方が auto である場合のように、flex のベースサイズがデフォルトのサイズ計算ルールを使用します。flex-basis が auto の場合、メインの軸の長さとして指定された width や height は、すべて無視されます。その他のキーワードは通常と同じで、flex のベースサイズを細かく指定できます。
flex-basis
flex
content
min-content
max-content
fit-content
width
height
auto
これまでは、レスポンシブ レイアウトでコンテナに対して display:flex を追加または削除する場合、個々の項目で値を追加または削除しなければならない場合がありました。content の導入により、それが不要になることもあります。
display:flex
scrollbar-gutter プロパティは、スクロールバーのガター（スクロールバーを表示するために予約されている領域）の有無をコントロールします。これにより、コンテンツが増加した場合にレイアウトが変わることを防ぎつつ、スクロールが不要な場合に余分な領域が表示されないようにすることができます。 スクロールバーの有無自体は、overflow プロパティによって決まる点に注意してください。従来型のスクロールバーを使うかオーバーレイ スクロールバーを使うかを決めるのは、ユーザー エージェントです。デベロッパーは、このプロパティを使うことで、ブラウザが提供するスクロールバーとレイアウトとの相互作用を細かくコントロールできます。
scrollbar-gutter
overflow
この API を使うと、MediaStreamTracks によってローメディアを操作できます。操作できるのは、カメラやマイク、画面キャプチャ、コーデックのデコーダ部分などの出力や、コーデックのデコーダ部分への入力などです。WebCodecs インターフェースを使ってローメディアのフレームを表現し、ストリームを使って公開します。この仕組みは、WebRTC Insertable Streams が RTCPeerConnection からエンコード済みデータを公開する方法と同様です。サンプルのユースケースとして、おかしな帽子、物体のリアルタイム検出や注釈付けがあります。
MediaStreamTracks
Flash が削除されたことで、navigator.plugins と navigator.mimeTypes から何かを返す必要はなくなりました。この API は、主に以下の目的で使われていました。
navigator.plugins
navigator.mimeTypes
この API を使って PDF ビューアのサポートを確認しているサイトもあります。今回の変更により、この配列は PDF ビューア プラグインの標準リストを含む固定のリストを返すようになります。
これによって API が削除または変更されることはありません。2 つの既存 API で固定の配列が返されるようになるだけです。
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.4 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
Chrome がウェブ公開サンプリング プロファイラをサポートし、クライアント JavaScript の実行時間を計測できるようになります。実際のユーザーから JavaScript のプロファイルを収集すると、パフォーマンスの低下が観測された場合のデバッグに役立てることができます。面倒な手動インストルメンテーションをする必要はありません。
このバージョンの Chrome では、以下のサポートの終了機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
サードパーティ コンテキストでの WebSQL が非推奨となります。この機能の削除は、Chrome 97 で行われる予定です。Web SQL Database 標準が最初に提案されたのは 2009 年 4 月で、2010 年 11 月に検討が中止されました。Gecko はこの機能を実装しておらず、WebKit では 2019 年に非推奨となりました。W3C は、代替手段として Web Storage や Indexed Database を推奨しています。
デベロッパーは、WebSQL 自体が非推奨であり、利用率が十分低くなった際に削除される予定であることを想定する必要があります。
サブリソースのプライベート ネットワーク リクエストは、セキュア コンテキストからのみ開始できます。プライベート ネットワーク リクエストとは、パブリック ネットワークで開始され、プライベート ネットワークを対象とするリクエストです。これには、インターネットから イントラネット へのリクエストや、イントラネット ループバックなどが含まれます。
今回の対応は、プライベート ネットワーク アクセスの完全実装に向けた最初の一歩です。ローカル ネットワーク内やユーザーのデバイス上で実行されているサーバーは、ウェブに充実した機能を公開しますが、これは危険な場合もあります。プライベート ネットワーク アクセスで提唱されている一連の変更は、サーバーに外部エンティティとの通信をオプトインさせることで、このようなサーバーへのリクエストによる影響を制限します。
このオプトインが意味を持つためには、クライアントのオリジンが認証されていることをサーバーが確認できなければなりません。これを実現するため、セキュア コンテキストのみに外部リクエストの実行を許可します。
ExtensionFeedItemService
AdGroupExtensionSettingService
CampaignExtensionSettingService
CustomerExtensionSettingService
FeedService
FeedItemService
FeedMappingService
AdGroupFeedService
CampaignFeedService
CustomerFeedService
GoogleAdsService
BatchJobService
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
ウェブバンドルは、複数のリソースをバンドルできるフォーマットを使って大量のリソースを効率的に読み込むための新たなアプローチです。この機能は、以前のリソース バンドルへのアプローチが抱えていた問題に対処します。
一部の 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 に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。
