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
