Google は、2 月 21 日より、社会課題をテクノロジーで解決に導くスタートアップを対象とした 3 か月集中型のプログラム 「Google for Startups Accelerator Class 4」を実施します。 このプログラムは Google による技術、組織運営など幅広い分野にわたるトレーニングや個別のメンターシップを提供し、参加企業のさらなる成長を支援します。昨年 9 月 より募集を開始し、多くの素晴らしい目標を持ったスタートアップにご応募を頂き、厳正な選考の結果、本プログラムに下記 8 社のスタートアップが参加します。

参加企業一覧（アルファベット順）

CogSmart : 頭部 MRI 画像などを利用した脳健康測定、BrainSuite プログラムを通じて、「認知症にならない健康脳づくり」「生涯健康脳」の社会的な普及を目指しているヘルスケア サービス (Healthcare / Brain)

Hubble : 契約書の管理・共有をスマートにするリーガルテック SaaS (Legal Tech)

Latona : IoT やエッジコンピューティングの技術を使ったビジネス プラットフォームを開発し、企業に提供することで、ワークプロセスの自動化・生産性の向上を目指しているサービス (AI, ML) 

NearMe : タクシーをシェアしてお得にドアツードア移動できる「相乗り」サービス。NearMe（ニアミー）は、独自の AI によりルーティングを最適化したスマートシャトルなどを展開し、リアルタイムの位置情報を活用して地域活性化に貢献する “瞬間マッチング” プラットフォーム作りを目指している。(Mobility as a Service, Sharing Economy)

PocketMarche : 全国の農家・漁師と直接やり取りしながら旬の食材を購入できる産直アプリ。生産者や地域と継続してつながるふるさと納税サービス。(EC, Marketplace)

Study Valley : 来年度から必修化される探究学習を効率的に行えるようにし、また社会との接点を創出する学習プラットフォーム (Ed Tech)

Tutorial : PC 端末にインストールせず、いつでもどこでも利用できる、クラウド型 RPA Robotic Crowd を提供 (Robotics)

unerry : 月 200 億件超の位置情報ビッグデータを扱う AI プラットフォームを開発・運営 (Geo Location AI)

​​今後の流れ

今後 3 か月に渡って、社会課題解決に特化したセッションをはじめ、機械学習などのテクノロジーに関するセッション、世界の外部メンターや Google 社員によるオンライン メンタリングなどを提供していきます。

プログラムについての詳細は、Google for Startups のページをご参照ください。

背景

ネイティブ ウィンドウ オクルージョンの計算

オクルージョンの計算タイミングの決定

オクルージョンの計算をし続けると、Chrome のパフォーマンスが低下することになるので、それは避けたいことです。つまり、ウィンドウが表示対象またはオクルージョン対象になるタイミングを検知する必要があります。ありがたいことに Windows では、ウィンドウの移動、リサイズ、最大化、最小化などのさまざまなシステム イベントをトラッキングできます。オクルージョン計算スレッドは、これらのイベントを追跡したいことを Windows に伝えます。そしてイベントが通知されると、イベントを精査して新たにオクルージョン計算を行うかどうかを決定します。非常に短い時間内に複数のイベントを受け取る可能性があるため、オクルージョンの計算は 16 ミリ秒に 1 回を超える頻度では行いません。この時間は、フレームレートが 1 秒あたり 60 フレーム（fps）である場合に 1 フレームが表示される時間に対応します。

リッスンするイベントは、ウィンドウのアクティブ化や非アクティブ化、ウィンドウの移動やリサイズ、ユーザーの画面ロックやロック解除、モニターの電源オフなどです。オクルージョンの計算は必要以上に行いたくありませんが、ウィンドウが表示されるイベントを見逃すわけにはいきません。見逃してしまうと、ウェブ コンテンツが表示されるはずの場所が白くなってしまうからです。これは絶妙なバランスです [3]。

リッスンするイベントは、Chrome ウィンドウがオクルージョンされるかどうかに関わるものです。たとえば、マウスを動かすとたくさんのイベントが発生し、カーソルも点滅するたびにイベントを発行しています。そういったイベントはウィンドウ オブジェクトとは関係ないので、無視します。また、ツールチップの表示によってオクルージョンの計算がトリガーされることはないので、大半のポップアップ ウィンドウのイベントも無視します。

オクルージョン スレッドは、さまざまな Windows イベントを検知したいことを Windows に伝えます。UI スレッドは、主要な状態変化（モニターの電源オフ、ユーザーによる画面ロック）が発生した場合にそれを検知したいことを Windows に伝えます。

結果

この機能は、効果を測定する実験と合わせて開発され、2020 年 10 月に M86 リリースの一部としてすべての Chrome Windows ユーザーにロールアウトされました。指標から、この機能をオンにした場合にパフォーマンスが大幅に改善されることがわかります。

• 起動時間が 8.5% から 25.8% 短縮
• GPU メモリ使用量を 3.1% 削減
• レンダラー全体の描画フレーム数を 20.4% 削減
• レンダラーのクラッシュが発生したクライアントが 4.5% 減少
• First Input Delay（初回入力までの遅延時間）が 3.0% 向上
• First Contentful Paint（視覚コンテンツの初期表示時間）と Largest Contentful Paint（最大視覚コンテンツの表示時間）が 6.7% 向上

起動時間と初回入力までの遅延時間が改善したのは、Chrome が起動時に 2 つ以上の全画面ウィンドウを復元する場合、いずれかのウィンドウがオクルージョンされる可能性が高いためです。Chrome はそのウィンドウに関する大半の作業を省略できるので、より重要なフォアグラウンド ウィンドウのためにリソースを節約できます。

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

AMP コミュニティから特に多く寄せられている要望の 1 つは、AMP の高パフォーマンスなコンポーネントを AMP 以外のページでも利用できるようにすることです。この度、Bento コンポーネントの第 1 ラウンドが完全リリースされたことをお知らせします。Bento コンポーネントは、高パフォーマンス、高ユーザー エクスペリエンスのコンポーネントで、ウェブ デベロッパーがページに機能を追加して優れたユーザー エクスペリエンスを実現する際に、直面する現実的な問題を解消できるようになっています。ぜひ試してみて、フィードバックをお送りください。Bento の詳細は、新しい Bento ブログで確認できます。

あらゆる場所で AMP コンポーネントを使う

AMP Project の目的は、常にユーザーファーストな体験を作れるようにデベロッパーをサポートすることです。この価値提案の中核にあるのは、高パフォーマンスでユーザー中心の AMP コンポーネントです。そこに Bento が加わり、これまで AMP でしか使えなかった高パフォーマンスな Web Component をお気に入りのフレームワークや CMS で使えるようになります。

たとえば、非 AMP ページにカルーセルを追加するなど、1 度限りのケースに Bento コンポーネントを使うことができます。また、AMP に注目し、徐々にページを有効な AMP に変換しようと考えているデベロッパーにも便利です。 

Bento と AMP の今後の方向性 

AMP は今後も、すぐに使えるソリューションをウェブサイトに提供し、ウェブページで優れたユーザー エクスペリエンスを実現し続けます。また、AMP Project では、AMP 形式のサポートと強化を継続します。同時に、ウェブサイトのパブリッシャーには、AMP と互換性のないサイトで機能を使いたいというニーズもあることも理解しています。そういったパブリッシャーは、サイトで Bento コンポーネントを使い、他の機能に妥協することなく、具体的な UX の課題に対処できるようになります。 

私たちが思い描いているのは、パブリッシャーが自由に AMP を活用して優れたユーザー エクスペリエンスを実現したり、Bento を使って個々のパフォーマンスの問題に対処したり、AMP や Bento の助けを借りることなくページ エクスペリエンスの目標を達成したりできる未来です。 

今すぐ Bento をお試しください！

Bento コンポーネントを試してみたい方は、スタートガイドをご覧ください。チームは、GitHub や Slack チャンネルからフィードバックを送ることを推奨しています。フィードバックは大歓迎です。ぜひご協力ください。質問や問題がある方も、遠慮なくご連絡ください。

この記事は Developer Programs Engineer の Christopher Arriola による Google Cloud Blog の記事 "Announcing version 6.0 of the Maps and Places SDKs for iOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

12 月 1 日（米国時間）、Maps SDK for iOS と Places SDK for iOS の新しいバージョンをリリースいたしました。バージョン 6.0 では、サポート対象の iOS のバージョンが iOS 12 からとなり、Apple M1 マシン上で iOS 14 以降のシミュレータを使用して開発する際に必要なバイナリを含む XCFramework のプレビュー サポートを提供し、デベロッパーの開発速度向上を実現します。また、このバージョンには、デベロッパーの皆様からのリクエストに基づいて、マーカーを地図に追加した際のアニメーション動作に関する新機能も追加しています。

マーカーのフェードイン アニメーション

バージョン 6.0 では、マーカーをマップに追加した際の表示をアニメーション化できるように、kGMSMarkerAnimationFadeIn という新しい GMSMarkerAnimation タイプが導入されました。

これを使用するには、マーカーをマップに追加する前に、マーカーの appearAnimation プロパティを設定します。
Swift

 let position = CLLocationCoordinate2D(latitude: -33.86, longitude: 151.2)

let marker = GMSMarker(position: position)

marker.appearAnimation = .fadeIn

Objective-C

 CLLocationCoordinate2D position = CLLocationCoordinate2DMake(-33.86, 151.2);

GMSMarker *marker = [GMSMarker markerwithPosition:position];

marker.appearAnimation = kGMSMarkerAnimationFadeIn;

XCFramework のサポート

従来、Maps SDK for iOS と Places SDK for iOS は、アプリの開発とリリースに必要なアーキテクチャを含む単一の .framework ファイルとして配布されていました。しかし、Apple M1 マシンを使用する場合、新しいバリアントである arm64 シミュレータに対応させるため、SDK を新しい XCFramework 形式に再パッケージ化する必要がありました。

Apple M1 マシンで以前のバージョンの SDK の使用を試みたことがある方は、以下のエラーに見覚えがあるはずです。

ld: building for iOS Simulator, but linking in object file built for iOS, file '[...]/GoogleMaps/Frameworks/GoogleMaps.framework/GoogleMaps for architecture arm64

Maps SDK for iOS と Places SDK for iOS のバージョン 6.0 のリリースでは、XCFramework のプレビュー サポートを提供し、Apple M1 マシンで発生していた上記のエラーを解消しています。プレビュー サポートの使用方法について詳しくは、Maps と Places のスタートガイドをご覧ください。

Maps SDK と Places SDK の XCFramework バージョンはベータ版のため、これらのバージョンは開発目的でのみ使用し、アプリをリリースする際には .framework バージョンを使用することをおすすめします。今後の SDK では、XCFramework のサポートを一般提供する予定です。

バージョン 6.0 をインストールしサンプルを確認する

CocoaPods や Carthage を使用して Maps SDK for iOS と Places SDK for iOS のバージョン 6.0 をインストールできるようになりました。SDK の XCFramework プレビュー版をインストールする場合は、[Installing the XCFramework] タブをご覧ください。サポートする iOS バージョンは iOS 12 からとなるため、バージョン 6.0 を使用して開発するには Xcode 12 以降を使用する必要があります。iOS 11 のサポートは現在中止していますが、Maps SDK for iOS と Places SDK for iOS の古いバージョンを指定することで、引き続きご利用いただけます。

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

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。

3 桁のバージョン番号に対する準備

来年には、Chrome でバージョン 100 がリリースされます。つまり、Chrome のユーザー エージェント文字列で報告されるバージョン番号の桁が増えます。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されています。chrome://flags/#force-major-version-to-100 と呼ばれるこの新しいフラグは、Chrome 96 以降で利用できます。詳細については、Chrome の User-Agent 文字列のメジャー バージョンを強制的に 100 にするをご覧ください。 

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

details 要素の自動展開

閉じられた details 要素に対する検索やリンクができるようになります。また、こういった非表示の要素は、find-in-page や ScrollToTextFragment のタイミング、あるいは要素のフラグメント ナビゲーションが使われたときに、自動的に展開されます。

レスポンス ヘッダーによる専用ワーカーへの Content-Security-Policy の提供

専用ワーカーが Content Security Policy の影響を受けるようになります。これまで、Chrome は、オーナーのドキュメントの Content Security Policy を誤って適用していました。

CSS

font-synthesis プロパティ

font-synthesis CSS プロパティは、フォント ファミリーに斜体、太字、小型英大文字のフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。font-synthesis プロパティがない場合、必要なバリエーションのフォント ファミリーがないウェブページで、不自然な形状のフォントになる可能性があります。

transform: perspective(none)

perspective() 関数の引数として、値 'none' がサポートされます。その場合、関数は無限大の引数を渡された場合のように動作します。これにより、perspective() 関数が関係しているアニメーションのエンドポイントの片方が単位行列であるアニメーションが簡単になります（場合によっては、実現可能になります）。

Keyboard API の Feature Policy

Chrome は、Feature Policy の許可リストで新しく keyboard-map 値をサポートします。Keyboard.getLayoutMap() を使うと、英語やフランス語など、異なるキーボード レイアウトで押されたキーを特定できます。このメソッドは、iframe 要素では利用できません。また、Keyboard API を利用できなかった一部のウェブアプリ（Excel、Word、PowerPoint）のアーキテクチャで、このメソッドが利用できるようになります。

HTMLScriptElement.supports() メソッド

HTMLScriptElement.supports() メソッドは、script 要素を利用する新機能を統一的な方法で検出します。現在のところ、HTMLScriptElement の type 属性で利用できる種類を簡単に判定する方法はありません。

フォーム送信時の遅い段階での改行正規化

フォーム エントリの改行が Gecko や WebKit と同じように正規化されるようになります。これにより、Gecko と WebKit は改行を遅い段階で正規化するにもかかわらず、Chrome は早い段階で正規化するという、長期にわたって存在していた相互運用性の問題が解決します。Chrome 97 以降では、早い段階での正規化が削除され、遅い段階での正規化がすべてのエンコーディング タイプに拡張されます。

既存の Client Hint 名の標準化

Chrome 97 は、Sec-CH- プレフィックスを付けて Client Hint 名を標準化します。影響を受ける Client Hint は、dpr、width、viewport-width、device-memory、rtt、downlink、ect です。Chrome では、以上のヒントの既存バージョンのサポートも継続されます。しかし、ウェブ デベロッパーは、今後のサポートの終了や削除に向けた準備をする必要があります。

WebTransport

WebTransport は、ウェブのセキュリティ モデルの制約を受けるクライアントがリモート サーバーと通信する際に、安全な多重化転送を可能にするプロトコル フレームワークです。

現在、ウェブ アプリケーション デベロッパーがリモート サーバーと双方向通信をする場合、WebSockets と RTCDataChannel という 2 つの API を使うことができます。WebSockets は TCP ベースなので、すべての TCP の欠点（ヘッドオブライン ブロッキング、信頼できないデータ転送の未サポート）を引き継ぐことになり、レイテンシが重要なアプリケーションには適しません。RTCDataChannel は Stream Control Transmission Protocol（SCTP）ベースなので、そのような欠点はありません。しかし、ピアツーピアで使うことを念頭に置いて設計されているので、クライアントサーバー設定で使われることはほとんどありません。WebTransport は、信頼できないデータと信頼できるデータの両方の双方向通信をサポートするクライアントサーバー API で、UDP 的なデータグラムによるキャンセル可能なストリームを利用します。WebTransport の呼び出しは DevTools の [Network] パネルで確認できます。[Type] 列を見ると、このプロトコルが使われていることがわかります。

詳しくは、WebTransport の試験運用をご覧ください。

JavaScript

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

Array と TypedArray の findLast() と findLastIndex()

Array と TypedArray が findLast() と fileLastIndex() 静的メソッドをサポートします。この 2 つの関数は find() と findIndex() と同じですが、配列の最初からではなく最後から検索します。

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

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

WebRTC での SDES 鍵交換の削除

2013 年以降、WebRTC の SDES 鍵交換メカニズムは、関連する IETF 標準で使用禁止と宣言されています。IETF は、SDES 仕様を過去のものと宣言しています。近年では、Chrome での使用も大幅に減少しました。そのため、Chrome 97 で削除されます。

サードパーティ コンテキストでの WebSQL の削除

サードパーティ コンテキストでの WebSQL が削除されます。Web SQL Database 標準が最初に提案されたのは 2009 年 4 月で、2010 年 11 月に検討が中止されました。Gecko はこの機能を実装しておらず、WebKit では 2019 年に非推奨となりました。W3C は、代替手段として Web Storage や Indexed Database を推奨しています。

SDP Plan B の削除

WebRTC でセッションを確立するために使われる Session Description Protocol（SDP）は、Chromium では 2 種類の方言 Unified Plan と Plan B によって実装されています。Plan B はクロスブラウザの互換性がないため、削除されます。