[go: up one dir, main page]

開発者の皆さま、いかがお過ごしですか?今年のゴールデンウィークは思うように外出できないという方がほとんどだと思います。そこで、Google はこの期間に、自宅で勉強できるコンテンツをご用意しました。


Machine Learning (機械学習) の専門的な知識を持たない方向けにトレーニングを無料で提供するプログラム「ML Study Jams Vol.4」を、今日 4 月 29 日(水・祝)から 5 月 24 日(日)まで開催します。




本プログラムは、オンライン学習プラットフォーム、QWIKLABS 上にある Machine Learning 関連のコードラボを利用して行います。


対象コース

初級

※QWIKLABS のハンズオンは GCP の知識があることが前提となるため、GCP の初級コースも対象としています。

中級


上級



さらに高いレベルにチャレンジされたいという方は、今年開設された TensorFlow デベロッパー認定試験に向けた勉強を始めることもできます。(認定制度については、こちらのブログや、tensorflow.org/certificate をご覧ください。 )


認定試験は、オンライン学習サービス Coursera にある、こちらの 4 つのコースが試験の出題範囲となっています。試験は、英語で問題を読み、設問に答えたり、コードを書いたりする必要があります。


Google は、受験者がチューターに質問できるコミュニケーション チャンネルを用意し、受験したい方を応援します。詳細は後日ブログで発表しますので、お楽しみにお待ちください。



ML Study Jams Vol.4 の流れ


1. 特設ページ「Start your learning journey with Google Cloud today」から参加登録する
※ 英語のみのページです
※ Training platform は「Qwiklabs」を選択してください
※ 本ページでの登録期限は 2020 年 5 月 31 日 23:59(米国太平洋標準時 夏時間)に延長されました
2. 登録後、送られてきたメールに記されたリンクから QWIKLABS に登録

3. ML Study Jams のページで「参加登録」を行う

4. QWIKLABS で対象ハンズオンを受講する

5. ML Study Jams の Slack に参加し、情報交換する

6. 対象ハンズオンを 2020 年 5 月 24 日(日)までに 4 つ以上修了し、ML Study Jams 事務局に申請すると記念品がもらえる
※ ML Study Jams に参加登録しなくとも、「Start your learning journey with Google Cloud today」に登録すれば無料で QWIKLABS を受講できます。
 ※ ML Study Jams Slack への参加方法は登録いただいた方にメールでご案内します

つまずいている点や分からない点がある方は、ML Study Jams の Slack や、5 月上旬開催のもくもく会イベント(オンライン)に参加して、チューターに質問することができます。


対象・参加条件

  • Machine Learning (機械学習) に興味を持っているがまだ使ったことがない方
  • 他のクラウド サービスを使っていて、GCP を比較してみたいデベロッパーの方
  • 新しいスキルを身につけたり、Machine Learning (機械学習)を学びたい方

プレゼント


ML Study Jams Vol.4 に参加し、規定の条件を満たした方にプレゼントをお送りします。




※プレゼントの発送は日本国内のみとなります。
※プレゼントの発送は 6 月上旬 ~ 7 月中旬を予定しています。
※プレゼントは写真とは異なる場合があります。
※詳しくは ML Study Jams のページをご覧ください


本プログラムのお申し込み


本プログラムへのご参加は、こちらの ML Study Jams ページよりお申し込みをお願いします。
皆様のご参加をお待ちしております。



Posted by Takuo Suzuki - Developer Relations Team

この記事は Joe Medley による Chromium Blog の記事 "Chrome 83 Beta: Cross-site Scripting Protection, Improved Form Controls, and Safe Cross-origin Resource Sharing" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2020 年 4 月 16 日の時点で Chrome 83 はベータ版です。

DOM 操作のための Trusted Types

DOM ベースのクロスサイト スクリプティング(DOM XSS)は、ウェブ セキュリティにおいて特によく見られる脆弱性です。意図せずにアプリケーションに含まれている可能性もあります。新しいテクノロジーである Trusted Types は、デフォルトで DOM XSS 脆弱性のないアプリケーションを書いてメンテナンスする上で役立ちます。Trusted Types は、危険な API を保護することでこれを実現します。

Element.innerHTML などのプロパティについて考えてみましょう。このプロパティによって、サイトで有害な HTML 操作が行われてしまう可能性があります。Trusted Types を使うと、スクリプトでこのプロパティが使われたときにエラーがスローされます。これを行うには、新しいコンテンツ セキュリティ ポリシーを設定します。次に例を示します。


Content-Security-Policy: require-trusted-types-for 'script';
report-uri //my-csp-endpoint.example


Trusted Types について詳しくは、Trusted Types で DOM ベースのクロスサイト スクリプティング脆弱性を防ぐをご覧ください。

フォーム コントロールの改善

HTML フォームのコントロールは、多くのインタラクティブなウェブを支える柱です。デベロッパーが簡単に使えるだけでなく、ユーザー補助機能も組み込まれており、ユーザーも使い慣れています。しかし、フォーム コントロールのスタイルは非常に一貫性のないものになっています。最初期のフォーム コントロールは、オペレーティング システムの表示と一致していましたが、その後のコントロールには、作られた当時に人気のあったデザイン スタイルが用いられています。この一貫性のなさのため、デベロッパーは余分な時間とコードを費やして開発する必要がありました。

昨年 1 年間、Chrome と Edge が協力し、HTML フォーム コントロールの外見と機能の改善に取り組みました。これには、コントロールやその他のインタラクティブ要素のフォーカス状態を認識しやすくすることも含まれています。下のイメージは、Chrome のいくつかのコントロールの旧バージョンと新バージョンを示しています。

旧バージョン:


新バージョン:

新しいフォーム コントロールは、既に Microsoft Edge に導入されており、Chrome 83 でも利用できるようになりました。詳しくは、Microsoft の記事 Microsoft Edge と Chromium のフォーム コントロールを改善するか、Chromium ブログの投稿フォーム コントロールとフォーカスのアップデートをご覧ください。

新しいクロスオリジン ポリシー

ウェブ API の中には、Spectre などのサイドチャネル攻撃のリスクを高めるものもあります。このリスクを緩和するため、ブラウザは cross-origin isolated と呼ばれるオプトインベースの分離環境を提供します。これを実現するのが、2 つの新しい HTTP ヘッダーである Cross-Origin-Embedder-PolicyCross-Origin-Opener-Policy です。この 2 つのヘッダーがある場合、将来的にウェブページで以下の特権機能を安全に使うことができるようになります。
  • Performance.measureMemory()
  • JS Self-Profiling API
cross-origin isolated 状態では、document.domain の変更も禁止されます。


詳しくは、COOP と COEP を使ってウェブサイトを「cross-origin isolated」にするをご覧ください。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、オリジン トライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。

ネイティブ ファイル システム

新しいオリジン トライアルである Native File System API は、Chrome 83 から Chrome 85 で行われる予定です。この API を使うと、ユーザーのローカル端末上のファイルを操作するウェブアプリを実現できます。たとえば、IDE、写真や動画のエディタ、テキスト エディタなどが考えられます。ユーザーがアクセス権を与えると、アプリは API を使ってユーザーの端末にあるファイルやフォルダを直接読み取ったり保存したりできるようになります。この処理は、プラットフォーム独自のファイルを開くまたはファイルを保存するダイアログ ボックスを通して行われます。詳しくは、Native File System API: 簡単にローカル ファイルにアクセスするをご覧ください。

Performance.measureMemory()

新しい Performance.measureMemory() 関数は、ウェブページのメモリの使用状況を見積ることで、本番環境のウェブアプリやウェブページのメモリの使用状況を測定します。以下のようなユースケースが考えられます。
  • メモリの使用状況とユーザー指標との相関関係を分析する
  • メモリのリグレッションを検知する
  • A/B テストで機能のリリースを評価する
  • メモリを最適化する
現在、ウェブ デベロッパーは非標準の performance.memory API を使うしかありません。これはページ読み込みの 20% を使用します。詳しくは、performance.measureMemory() でウェブページの合計メモリ使用量をモニタリングするをご覧ください。

優先度付きの Scheduler.postTask()

Scheduler.postTask() メソッドを使うと、ネイティブ ブラウザのスケジューラによるタスク(JavaScript コールバック)のスケジューリングが可能です。その際に、user-blockinguser-visiblebackground という 3 段階の優先度レベルが利用できます。さらに、TaskController オブジェクトが公開されるので、そこから動的にタスクをキャンセルしたり優先度を変更したりできます。

WebRTC Insertable Streams

WebRTC Insertable Streams API を使うと、WebRTC の MediaStreamTrack のエンコードおよびデコードの際にカスタムのデータ処理を行うことができます。利用例の 1 つとして、ピア接続間で中間サーバーを通して送信されるデータのエンドツーエンドの暗号化があげられます。Insertable Streams を使うには、RTCPeerConnection インターフェースの新しいパラメータのいずれか 1 つを追加します。今回のリリースにおけるその他の WebRTC のアップデートは、次のセクションに記載されています。

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

ARIA アノテーション

新しい ARIA アノテーションによって、スクリーン リーダーが意味を持つコメント、サジェスチョン、テキストのハイライト表示(<mark> と同じ)にアクセスできるようになります。また、関連情報と要素を意味的につなげて、説明、定義、脚注、コメントを他の要素と結びつけることができます。
これまで、アノテーションはライブ リージョン ハックを使わなければ実現できませんでした。この方法はセマンティクスほど信頼できず、目が不自由な方向けの表示としては不十分でした。そのため、スクリーン リーダーはオンライン ワード プロセッサとの連携機能を十分にサポートできませんでした。

'-webkit-appearance' CSS プロパティの 'auto' キーワード

-webkit-appearance CSS プロパティに新しく auto キーワードが追加されました。このキーワードは、対象要素のデフォルトの外見を表します。これは将来の完全に標準化された appearance プロパティによる、非標準の -webkit-appearance プロパティの置き換えに向けた一歩です。

Barcode Detection API

Chrome が Barcode Detection API をサポートします。この API は、スクリプトで提供されたイメージ内にあるバーコードを検出してデコードする Shape Detection API の一部です。イメージは、<image><video><canvas> の各タグなど、任意の種類のイメージ バッファ ソースから取得できます。これまで、ウェブページでバーコードを検出するには、大きなサードパーティ製ライブラリを含める必要がありました。この API は、Google Play Services がインストールされた端末でのみ利用できます。認定外の端末では利用できません。Barcode Detection API の詳細や、その他の Shape Detection API については、Shape Detection API: 1 枚の写真には 1000 の単語、顔、バーコードの価値があるをご覧ください。

CSS contain-intrinsic-size

contain-intrinsic-size プロパティを使うと、contain: size が適用された場合に使われるプレースホルダのサイズを指定できます。contain-intrinsic-size を指定すると、その要素のレイアウトは、このプロパティで指定された固定サイズの子要素が 1 つあるかのように振る舞います。ただし、明示的に幅や高さが指定されている場合は除きます。

このプロパティは、まだ利用できない、またはまだレンダリングされていないサブツリー コンテンツのプレースホルダのサイズ指定を行うために導入されました。これまでは、要素自体のサイズを変更する以外にこれを行う方法はありませんでしたが、この方法はコンテナ内の要素のレイアウト方法に影響するため、好ましくありません。サンプルは、WICG で公開されています

CSS の色調整: color-scheme メタタグ

現在は、多くのオペレーティング システムに「ダークモード」プリファレンスが搭載されています。既にウェブページをダークテーマに変換するオプションを提供しているブラウザもあります。prefers-color-scheme メディアクエリを使うと、制作者が独自のダークテーマをサポートし、構築したエクスペリエンスを完全に制御できるようになります。このメタタグでは、サイトでダークテーマの完全サポートを明示的にオプトインできます。これにより、ブラウザは別のユーザー エージェント シートを読み込み、変換は適用しなくなります。詳しくは、color-scheme CSS プロパティと対応するメタタグでダークモードのデフォルト スタイルを改善するをご覧ください。

<button> の display:inline-grid/grid/inline-flex/flex

display のキーワードである inline-gridgridinline-flexflex が、align プロパティが適用されている <button> 要素に対して機能するようになります。(デモ

Shared Worker の ES モジュール('module' タイプ オプション)

Shared Worker の JavaScript がモジュールをサポートするようになります。コンストラクタの type 属性に module タイプを設定すると、Worker のスクリプトが ES モジュールとして読み込まれ、Worker のコンテキストで import 文が利用できるようになります。この機能を使うと、組み合わせ可能なプログラムを簡単に書けるようになり、ページや Worker 間でプログラムを共有しやすくなります。詳しくは、「モジュール Worker でウェブをスレッド化する」のShared Worker に関する部分をご覧ください。

font-display: optional の改善

Chrome で font-display の動作方法がいくつか変更されます。
  • font-displayoptional に設定しても、再レイアウトが発生しなくなります。
  • ウェブフォントを十分高速に読み込める場合にフォールバック レンダリングを行わなくてもいいように、フォントのプリロードは(すべての font-display 値について)レンダリングをわずかにブロックできるようになります。
この結果、font-display: optional とプリロードの両方が使われている場合、フォントの交換によるレイアウトの切り替えが起こらなくなります。詳しくは、オプショナル フォントのプリロードによってレイアウトの切り替えと非表示テキストのフラッシュ(FOIT)を防ぐをご覧ください。

IndexedDB のトランザクション耐久性の緩和

IDBDatabase.transaction() にオプション引数 durability を渡せるようになります。
これにより、データのストレージへのフラッシュを制御し、明示的に耐久性とパフォーマンスをトレードオフできるようになります。これまでは、IndexedDB のトランザクションを書き込んだ場合、Firefox はフラッシュを行いませんでしたが、Chrome は行っていました。これにより、データが OS の中間キャッシュでなく端末のディスクに書き込まれることが保証されるので、耐久性が増加します。残念ながら、この機能はパフォーマンスに大きく影響します。
有効なオプションは、"default""strict""relaxed" です。"default" オプションは、ユーザー エージェントが提供する現在のデフォルトの動作に従うことを表します。次に例を示します。現在の値は、IDBTransaction.durability を使って読み取ることができます。

const iDBTransaction = database.transaction(
  [ "storeName" ],
  "readwrite",
  {
    durability: "relaxed"
  }
);


レンダリングエンジン外の CORS

レンダリングエンジン外の CORS(Out-Of-Renderer Cross-Origin Resource Sharing、OOR-CORS)は、ネットワーク アクセスを調査する新しい CORS 実装です。Chrome のこれまでの CORS 実装は、Blink のコア部分、XHR および Fetch API のみが利用でき、アプリケーションの他の部分では簡易実装が使われていました。そのため、いくつかの内部モジュールが発行する HTTP リクエストを CORS で点検することはできませんでした。新しい実装は、この欠点に対応しています。

<input type=time> の範囲の逆転

Chrome で、typetime である <input> 要素の範囲の逆転がサポートされます。これにより、0 時をまたぐ時間の入力を表現できるようになります。範囲の逆転とは、最大が最小より小さいことを指します。この場合、input 要素は最小よりも小さいか最大よりも大きい値を許可しますが、その間の値は許可しません。この機能は、長い間仕様に掲載されていましたが、Chrome では実装されていませんでした。

"JIS-B5" および "JIS-B4" @page のサポート

Chrome が @page ルールで次の 2 つのページサイズをサポートします。この 2 つは、どちらも CSS Paged Media Module Level 3 仕様に記載されています。
  • "JIS-B5": 幅 182 mm 、高さ 257 mm
  • "JIS-B4": 幅 257 mm 、高さ 364 mm
この機能により、Chrome は標準のこのセクションの実装をすべて完了したことになります。

@supports selector() 機能クエリ関数

新しい @supports 関数は、CSS セレクタの機能検知を提供します。ウェブ制作者は、実際にセレクタに一致するスタイルルールの指定を適用する前に、この機能を使って UA がセレクタをサポートしているかどうかを照会できます。次に例を示します。

@supports selector(::before) {
  div { background: green };
}

WebRTC

オリジン トライアルに記載した項目に加え、以下のウェブ RTC 機能が Chrome に追加されます。

RTCPeerConnection.canTrickleIceCandidates

canTrickleIceCandidates boolean プロパティは、リモートピアが候補のトリックルを扱えるかどうかを示します。この機能は、SDP セッション記述の情報を公開します。

RTCRtpEncodingParameters.maxFramerate

このエンコード パラメータを使うと、送信前に動画レイヤーのフレームレートを制限できます。新しいフレームレートは RTCRtpSender.setParameters() を使って設定します。新しい設定は、現在のピクチャが完了した後に適用されます。この設定は、RTCRtpEncodingParameters.maxFramerate で読み出すことができます。maxFramerate を 0 に設定すると、次のフレームで動画がフリーズします。

RTCRtpSendParameters.degradationPreference

RTCRtpSendParametersdegradationPreference という新しい属性が追加されます。これを使うと、帯域幅や CPU などの制約により、設定されたフレームレートや解像度でエンコードできない場合に、どのように質を低下させるかを制御できます。たとえば、画面共有アプリのユーザーは、アニメーションよりも画面の読みやすさを優先したいでしょう。ビデオ会議のユーザーは、高解像度よりもスムーズなフレームレートを好むはずです。degradationPreference に設定できる値は、"maintain-framerate""maintain-resolution""balanced" です。

WebXR DOM オーバーレイ

DOM オーバーレイは、ハンドヘルド端末のイマーシブ AR 機能です。この機能を使うと、2 次元ページ コンテンツをインタラクティブな透過レイヤーとして WebXR コンテンツやカメライメージの上に表示できます。そのため、DOM を使って WebXR エクスペリエンスのユーザー インターフェースを作れるようになります。VR では、インライン セッションは必然的に DOM の中になります。一方、AR にはインライン モードはありません。一部のユースケースでは、これが特に重要になります。この機能を試したい方は、Chrome 83 で 2 つサンプルのどちらかをご利用ください。現在、この機能は ARCore ベースのハンドヘルド端末でのみ利用できます。

JavaScript

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

Intl.DateTimeFormat の fractionalSecondDigits オプション

Chrome 83 の Intl.DateTimeFormat オブジェクトに fractionalSecondDigits プロパティが追加され、秒の端数の表示形式を制御できるようになります。ECMAScript の Date オブジェクトは、ミリ秒の精度で時間情報を保存します。この情報を出力しなければならないウェブ デベロッパーもいます。このプロパティの値は 0 から 3 の間の整数で、DateTimeFormat が出力する小数点以下の桁数を表します。

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

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

サンドボックス化された iframe でのダウンロードの拒否

Chrome では、サンドボックス化された iframe でダウンロードが許可されなくなります。ただし、この制限は、サンドボックス属性リストの 'allow-downloads' キーワードを使って解除できます。今回の変更により、コンテンツ プロバイダは悪意のあるダウンロードや不正なダウンロードを制限できます。ダウンロードは、システムにセキュリティ脆弱性をもたらす場合があります。Chrome およびオペレーティング システムでは追加のセキュリティ チェックが行われますが、サンドボックス化された iframe でのダウンロードをブロックすることも、サンドボックスの目的と一致するものと考えています。

Reviewed by Eiji Kitamura - Developer Relations Team


この記事は Mike Pegg(Head of developer relations, Google Maps Platform) による Google Maps Platform Blog の記事 "Supporting not-for-profit COVID-19 response efforts with Google Maps Platform credits" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

新型コロナウイルス感染症(COVID-19)の影響が拡大し続ける中、人々を勇気づけようとする取り組みがデベロッパー コミュニティによって行われています。こうした取り組みをサポートするため、Google は、非営利のプロジェクトにて公開予定の COVID-19 関連のウェブサイトやモバイルアプリに対して、Google Maps Platform クレジットの申請に対する手続きを迅速化しました。非営利活動をするデベロッパーや非営利団体がこの取組みを通じてクレジットの利用を申請すると、資格要件を満たすサイトであるかなど Google 担当者が審査します。その地域にとって有効で求められるサービスの提供を早急に開始しようとしているデベロッパーの皆様、こちらのデベロッパー リソースハブにアクセスして詳細をご確認ください。

開始手順

  1. デベロッパー リソースサイトで資格要件について詳細をご確認ください。信頼できる情報源(例:米国疾病予防管理センター (CDC)、世界保健機関 (WHO)、国や地方の保健機関)から正規のサービスを提供したり、情報を提供するウェブサイトやアプリが対象となります。 
  2. Google Cloud Platform のアカウントを作成します。 
  3. プログラムのクレジット管理には、請求先アカウントが必要となりますので、請求先アカウントを設定してください。 
  4. 申請書を提出します。 
  5. 使用したい Google Maps Platform API や SDK を有効にします。 
  6. Google Maps Platform の利用に際し、認証で使用する API キーを作成します。 
設定手順と要件に関するすべての情報は、こちらをご確認いただくか、Google Maps Platform の YouTube チャンネル動画をご覧ください。

緊急時対応のユースケースで使用できる API と SDK

Google Maps Platform に含まれるすべての API と SDK は、緊急時対応や救済プロジェクトで有効ですが、関連性のあるユースケースで使用できる API や SDK を素早く特定できるように早見表をまとめました。

ユースケース : 検査所などの場所を地図上に表示したい 

ウェブ用 :
モバイル用 :
ユースケース : 通常の営業時間とは異なる店舗の営業時間帯を知りたい顧客に向けて、店舗情報を地図上に表示したい
ユースケース : 信頼できる情報源のデータに基づき、回復症例をヒートマップ(色分けした地図)で表示したい
ウェブ用 :
モバイル用 :
ユースケース : 300 以上の信頼できる情報元から医療または公益の大規模なデータセットを視覚化したい
ウェブ用 :
ユースケース : 最寄りの地域医療センターなどの場所を検索できるようにしたい
ウェブ用 :
モバイル用 :
ユースケース : 非営利の病院が医療サービスを提供できるように支援したり、患者を最寄りの検査所へ行けるよう案内したい
ウェブ用 :
モバイル用 :

開発の際に技術的な質問がある場合は、テクニカル ドキュメントStackOverflow をご確認いただくか、サポートページからご連絡ください。繰り返しになりますが、デベロッパー リソースハブのサイトから Google Maps Platfrom のクレジットを申請してください。 

COVID-19 に対する Google Maps Platform コミュニティの活動については、今後も継続して発信していく予定です。Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカル アカウントマネージャ


COVID-19 感染拡大の影響で、お客様のビジネスを取り巻く環境が急激に変化しています。Google Cloud は、今まで通り、皆さまのビジネスを支えるパートナーとして、最適なソリューションを提案し続け、サポートしていきたいと考えています。


そこで Google Cloud は、今、皆さまが直面するビジネス課題を解決するためのヒントを提供する Google Cloud Day: Digital を開催します。


本イベントはデジタル カンファレンスです。
6 月 9 日(火) - 11 日(木) に全コンテンツ、オンラインでのライブ配信を行います。

  1. Google Cloud のビジョンおよびサポート内容をお伝えするオープニング セッション
  2. さまざまなビジネス課題を解決する具体的なソリューションを紹介するブレイクアウト セッション
  3. Google Cloud 製品を実際に使用しゲーム形式で楽しみながら学べるハンズオン


ブレイクアウト セッションのライブ配信中は、Google Cloud のエキスパートがあなたの質問にライブでお答えする予定です。また、6 月 30 日 (火) まで、自由にコンテンツをご視聴いただけます。


セッションやハンズオンなど、実践型の演習を含めた様々なコンテンツを通して、皆様のビジネスをサポートする実践的アイディアが見つかることを願っています。


配信を視聴いただくには、こちらからご登録ください。


開催概要


日程:
2020 年 6 月 9 日 (火) - 11 日 (木) ライブ配信
2020 年 6 月 9 日 (火) - 30 日 (火) 開催
(Google カレンダーに予定を入れる場合は、こちら



対象:
開発者、ビジネスの意思決定者やリーダー


ライブ配信スケジュール:
6 月 9 日 (火)
  • オープニング セッション / 11:00 〜 12:10
  • ブレイクアウト セッション / 12:30 〜 18:10
  • ハンズオン プログラム / 12:30 〜 15:30

6 月 10 日 (水)、6 月 11 日 (木)
  • ブレイクアウト セッション / 10:00 〜 16:50
  • ハンズオン プログラム / 10:00 〜 16:40
(※時間は変更になる場合がございます。)



ハッシュタグ:
#GoogleCloudDay



————————————————————

お問い合わせ先:Google Cloud Day: Digital 事務局

google-cloudday-tokyo-office@google.com



————————————————————

この記事は The TensorFlow Blog の記事 "Face and hand tracking in the browser with MediaPipe and TensorFlow.js" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
投稿者: Google ソフトウェア エンジニア、Ann Yuan、Andrey Vakunov

本日は、2 つの新しいパッケージ facemeshhandpose のリリースについてお知らせします。それぞれ、顔の重要なランドマークと、手をトラッキングするパッケージです。このリリースは、Google Research の MediaPipe チーム、TensorFlow.js チームとの共同作業です。

facemesh パッケージ
handpose パッケージ

実際にブラウザでデモを試す

facemesh パッケージは、イメージ内の顔の境界線とランドマークを検出します。handpose パッケージは、手に対して同じことを行います。これらのパッケージは小さく高速で、完全にブラウザの中だけで実行されます。データがユーザーの端末の外に出ることはないので、ユーザーのプライバシーを保護できます。こちらのリンクから、すぐに試すことができます。
これらのパッケージは、MediaPipe の一部としても利用できます。MediaPipe は、マルチモーダル認識パイプラインを構築するためのライブラリです。
リアルタイムで顔や手をトラッキングすることで、新しいタイプのインタラクションが実現することを願っています。たとえば、顔のパーツの位置は表情を分類する上での基本情報になります。また、手のトラッキングはジェスチャー認識の第一段階です。このような機能を持つアプリケーションが、どのようにウェブのインタラクションやアクセシビリティの限界を広げるのかを見るのが楽しみです。

詳しい仕組み: facemesh


facemesh パッケージは、イメージや動画ストリームから顔面のジオメトリを 3D で大まかに推論します。入力として必要なのは 1 つのカメラだけで、深度センサーは不要です。このジオメトリによって、唇や顔の輪郭などの細かい部分も含め、顔の中の目、鼻、唇などのパーツを特定します。この情報は、表情の分類といった下流のタスクで使うことができます(ただし、個人の識別には利用できません)。さまざまなデータセットに対してモデルがどのように実行されるかの詳細は、モデルカードをご覧ください。このパッケージは、MediaPipe 経由でも利用できます。

パフォーマンスの特徴

facemesh は最大 3 MB の重みのみを含む軽量パッケージで、各種モバイル端末でリアルタイム推論を行うのに最適です。テストする際には、TensorFlow.js では数種類のバックエンドから選択できる機能を提供している点にご注意ください。たとえば、WebGL や、低スペックの GPU を搭載した端末に適した XNNPACK と WebAssembly(WASM)を使うことができます。下の表は、数種類の端末と TensorFlow.js バックエンドごとにパッケージのパフォーマンスを示しています。数種類の端末と TensorFlow.js バックエンドごとにパッケージのパフォーマンスを示す表

インストール

facemesh パッケージは、2 つの方法でインストールできます。
  1. NPM を使う場合:
    import * as facemesh from '@tensorflow-models/facemesh;
  2. script タグを使う場合:
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs-core"></script>
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs-converter"></script>
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow-models/facemesh"></script>

使用方法

パッケージをインストールしたら、モデルの重みを読み込み、イメージを渡すだけで、顔のランドマークの検知を始めることができます。
// Load the MediaPipe facemesh model assets.
const model = await facemesh.load();
 
// Pass in a video stream to the model to obtain 
// an array of detected faces from the MediaPipe graph.
const video = document.querySelector("video");
const faces = await model.estimateFaces(video);
 
// Each face object contains a `scaledMesh` property,
// which is an array of 468 landmarks.
faces.forEach(face => console.log(face.scaledMesh));
estimateFaces の入力には、動画、静的イメージ、さらには node.js パイプラインで使用する ImageData インターフェースを指定できます。facemesh は、入力された顔(複数可能)の予測オブジェクトを含む配列を返します。この配列には、それぞれの顔の情報が含まれます(例: 信頼度、その顔の 468 個のランドマークの位置)。次に予測オブジェクトのサンプルを示します。
{
    faceInViewConfidence: 1,
    boundingBox: {
        topLeft: [232.28, 145.26], // [x, y]
        bottomRight: [449.75, 308.36],
    },
    mesh: [
        [92.07, 119.49, -17.54], // [x, y, z]
        [91.97, 102.52, -30.54],
        ...
    ],
    scaledMesh: [
        [322.32, 297.58, -17.54],
        [322.18, 263.95, -30.54]
    ],
    annotations: {
        silhouette: [
            [326.19, 124.72, -3.82],
            [351.06, 126.30, -3.00],
            ...
        ],
        ...
    }
}
API の詳細については、README をご覧ください。

詳しい仕組み: handpose

handpose パッケージは、入力されたイメージまたは動画ストリームから手を検知し、それぞれの手の特徴の位置を示す 21 個の 3 次元ランドマークを返します。このランドマークには、それぞれの指の関節や手のひらの位置も含まれます。このモデルは、2019 年 8 月に MediaPipe と通してリリースしました。モデルの詳しいアーキテクチャについては、リリースに合わせて公開されたブログ投稿をご覧ください。さまざまなデータセットに対して handpose がどのように実行されるかの詳細は、モデルカードをご覧ください。このパッケージは、MediaPipe 経由でも利用できます。

パフォーマンスの特徴

handpose は最大 12 MB の重みを含む比較的軽量なパッケージで、リアルタイム推論に適しています。下の表は、数種類の端末ごとにパッケージのパフォーマンスを示しています。数種類の端末でのパッケージのパフォーマンスを示した表

インストール

handpose パッケージは、2 つの方法でインストールできます。
  1. NPM を使う場合:
    import * as handtrack from '@tensorflow-models/handpose;
  2. script タグを使う場合:
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs-core"></script>
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs-converter"></script>
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow-models/handpose"></script>

使用方法

パッケージをインストールしたら、モデルの重みを読み込み、イメージを渡すだけで、手のランドマークのトラッキングを始めることができます。
// Load the MediaPipe handpose model assets.
const model = await handpose.load();
 
// Pass in a video stream to the model to obtain 
// a prediction from the MediaPipe graph.
const video = document.querySelector("video");
const hands = await model.estimateHands(video);
 
// Each hand object contains a `landmarks` property,
// which is an array of 21 3-D landmarks.
hands.forEach(hand => console.log(hand.landmarks));
facemesh と同じく、estimateHands には動画、静的イメージ、ImageData インターフェースを入力できます。すると、入力された手の詳細を表すオブジェクトの配列が返されます。次に予測オブジェクトのサンプルを示します。
{
    handInViewConfidence: 1,
    boundingBox: {
        topLeft: [162.91, -17.42], // [x, y]
        bottomRight: [548.56, 368.23],
    },
    landmarks: [
        [472.52, 298.59, 0.00], // [x, y, z]
        [412.80, 315.64, -6.18],
        ...
    ],
    annotations: {
        indexFinger: [
            [412.80, 315.64, -6.18],
            [350.02, 298.38, -7.14],
            ...
        ],
        ...
    }
}
API の詳細については、README をご覧ください。

今後に向けて

facemesh と handpose は今後も改善を続ける予定です。近いうちに、複数の手をトラッキングする機能もサポートしたいと考えています。さらに、特にモバイル端末において、常にモデルの高速化に取り組んでいます。ここ数か月間の開発で、facemesh と handpose のパフォーマンスは大幅に向上しました。この傾向は今後も続くと確信しています。MediaPipe チームはさらに効率を上げたモデル アーキテクチャの開発に取り組んでおり、TensorFlow.js チームは推論を高速化する方法(演算の統合など)を常に調査しています。推論が高速になれば、リアルタイム パイプラインのモデルを大きくして、精度を上げることができます。

次のステップ

謝辞

パッケージのオリジナル実装を快く共有してくださった MediaPipe チームに感謝いたします。MediaPipe は、基盤となるモデルの開発とトレーニング、すべてを統合する後処理グラフの設計を行いました。

Reviewed by Khanh LeViet - Developer Relations Team

この記事は Jeffrey Jose による The AMP Blog の記事 "Adobe Experience Cloud Extends AMP Support" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Adobe は、サイト運営者や広告主などのお客様のために、Adobe Experience Cloud アプリケーションに AMP サポートをシームレスに組み込む作業を続けています。以下では、Adobe Experience Manager、Adobe Campaign、Adobe Analytics で最近行われた統合の概要をお伝えします。

Adobe Experience Manager(AEM)

Adobe は先日、お客様が新たな方法でシームレスかつユーザーファーストなモバイル体験を提供できるように、Adobe Experience Manager コア コンポーネントの AMP サポートを発表しました。Adobe Experience Manager で構築した AMP 対応サイトは、効率的で見つけやすく、モバイルユーザーに最適な体験を提供します。Github で PR をご覧ください。
新たな互換性が加わり、1 つのコードセットを作るだけで、HTML と、モバイルに最適化されたインスタンスの両方を提供できます。個別のコンテンツやコードを書く必要はありません。さらに、AMP のオープンなソースコードは Adobe Experience Manager のコミュニティでも利用できるので、個々のサイトのニーズに合ったカスタム コンポーネントを構築できます。
Adobe Experience Manager コンポーネントが AMP を出力可能になることで、2 つのオープンソースの取り組みが 1 つになり、モバイル コンテンツのエコシステムを強化して、比類なきモバイル体験を生み出します。このすばらしい作業を行ったのは、Adobe Experience Manager のパートナーである Bounteous です。詳細は、こちらの記事をご覧ください。

Adobe Campaign

もう 1 つの画期的な取り組みとして、Adobe は Adobe Experience Cloud の一部である Adobe Campaign Classic が AMP for Email に対応したことを発表しました。この機能を利用すると、Adobe Campaign Classic から送信できるダイナミックで魅力的なメールの中で、AMP コンポーネントを使えるようになります。
Adobe Campaign Classic が AMP for Email に対応したことで、マーケティング担当者はメールの中で直接的にイノベーションを発揮し、ユーザー エンゲージメントの向上を図れるようになります。この新機能によって、お客様はメールから一切離れることなく、フィードバックを残したり、予約を入れたり、投票に参加したりできます。
ユーザーはメールの受信トレイでとても多くの時間を使っています。Adobe は、日々送られている 2900 億通以上のメールの中で、ひときわ注目を集める方法をお客様に提供します。Adobe Campaign Classic の AMP for Email 対応の詳細については、Adobe ブログをご覧ください。

Adobe Analytics 

Adobe Analytics は、AMP Linker を組み込むことで、AMP ページとのシームレスな統合を果たしています。AMP の新機能である AMP Linker を使うと、AMP キャッシュの外に出るリンクの URL パラメータに AMP クライアント ID などのパラメータが追加されるので、ユーザーのセッションを維持できます。Adobe Analytics は、このパラメータを参照し、それをファーストパーティ Cookie として書き込みます。
AMP Linker と Adobe Analytics を統合できるようになったことで、AMP ページと非 AMP ページの間でユーザーのセッションを維持できるようになります。Adobe Analytics の AMP サポートの詳細については、こちらをご覧ください。
さらに詳しい情報や Adobe の最新情報については、2020 年 3 月 31 日に開催された Adobe 初のデジタル サミット Adobe Summit をご確認ください。
投稿者: Google、AMP Project、プロダクト マネージャー、Jeffrey Jose

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は The TensorFlow Blog の記事 "TensorFlow Lite Core ML delegate enables faster inference on iPhones and iPads" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
投稿者: ソフトウェア エンジニア、Tei Jeong、Karim Nosseir



TensorFlow Lite では、モデルの推論の一部または全部を GPU、DSP、NPU などのアクセラレータに委譲し、モバイルでの推論を効率化することができます。Android で選択できるデリゲートには、NNAPIGPU、そして最近追加された Hexagon があります。しかしこれまで、Apple のモバイル端末である iPhone や iPad では、GPU デリゲートしか選択できませんでした。

Apple が自社の機械学習フレームワークである Core ML と Neural Engine(Apple の Bionic SoC のニューラル プロセッシング ユニット(NPU))をリリースしたとき、TensorFlow Lite から Apple のハードウェアを利用できるようになりました。

Google の Edge TPU や Apple の Neural Engine のようなニューラル プロセッシング ユニット(NPU)は、機械学習アプリケーションを高速化するために設計された専用のハードウェア アクセラレータです。このようなチップは、モバイル端末やエッジデバイスでのモデルの推論をスピードアップするために設計されており、消費電力も CPU や GPU で推論を行う場合より少なくなります。

本日は、新しい TensorFlow Lite のデリゲートについてお知らせします。このデリゲートは、Apple の Core ML API を活用し、Neural Engine が搭載された iPhone や iPad で浮動小数点モデルを高速に実行します。MobileNet や Inception V3 などのモデルでは、最大で 14 倍のパフォーマンスが向上することが確認できます(詳細下記)。
TFLite Core
図 1: 実行時のデリゲートの仕組みを示した概念図。グラフのサポートされている部分はアクセラレータが実行するが、その他の命令は TensorFlow Lite カーネル経由で CPU が実行する。

サポートされる端末

このデリゲートは、iOS バージョン 12 以降(iPadOS を含む)の iOS 端末で動作します。ただし、真のパフォーマンスのメリットを得るには、Apple A12 SoC 以降を搭載した端末(iPhone XS など)で実行する必要があります。それよりも古い iPhone でパフォーマンスを向上させたい場合は、TensorFlow Lite GPU デリゲートを利用してください。

サポートされるモデル

この初回リリースでは、32 ビット浮動小数点モデルがサポートされます。サポートされるモデルには、画像分類、物体検知、オブジェクト セグメンテーション、姿勢推定モデルなどが含まれますが、それに限りません。このデリゲートは、畳み込み演算など、たくさんの重い計算命令をサポートしていますが、一定の制約がある命令もあります。実行時に委譲を行う前に制約がチェックされ、サポートされていない命令は自動的に CPU にフォールバックされます。すべての命令リストとそれぞれの制限(存在する場合)については、デリゲートのドキュメントをご覧ください。

パフォーマンスへの影響

このデリゲートについて、2 つの一般的な浮動小数モデルである MobileNet V2 と Inception V3 でテストを行いました。ベンチマークを行ったのは iPhone 8+(A11 SoC)、iPhone XS(A12 SoC)、iPhone 11 Pro(A13 SoC)で、CPU のみ(デリゲートなし)、GPU、Core ML デリゲートという 3 つのデリゲート オプションをテストしました。前述のように、アクセラレーションによってパフォーマンスが向上するのは A12 SoC 以降のモデルです。しかし、iPhone 8+ ではサードパーティが Neural Engine を利用できないので、小さなモデルで Core ML デリゲートを使用してもパフォーマンスが向上することはありません。大きなモデルのパフォーマンスは、GPU デリゲートと同等です。

モデルの推論にかかる時間に加え、起動時間も測定しました。スピードアップは起動時間の増加とのトレードオフである点に注意してください。Core ML デリゲートでは、モデルのサイズに伴って起動時間が増加します。たとえば、MobileNet のような小さなモデルの起動時間は 200-400 ミリ秒でした。一方で、Inception V3 のような大きなモデルの起動時間は、2-4 秒になりました。現在、この起動時間を短縮するための作業を行っています。このデリゲートは、バイナリサイズにも影響を与えます。Core ML デリゲートを使うと、バイナリサイズが最大 1 MB 増加する可能性があります。

モデル


  • MobileNet V2(1.0、224、浮動小数) [ダウンロード] : イメージ分類
    • 小さなモデル。グラフ全体を Core ML で実行。
  • Inception V3 [ダウンロード] : イメージ分類
    • 大きなモデル。グラフ全体を Core ML で実行。

端末

  • iPhone 8+(Apple A11、iOS 13.2.3)
  • iPhone XS(Apple A12、iOS 13.2.3)
  • iPhone 11 Pro(Apple A13、iOS 13.2.3)

MobileNet V2 での処理時間とスピードアップの程度

図 2: MobileNet V2 での処理時間とスピードアップの程度。すべてのバージョンで浮動小数点モデルを使用。CPU Baseline は 2 スレッド TensorFlow Lite カーネルを示す。
* GPU: Core ML は推論に CPU と GPU を使用。NPU: Core ML は推論に CPU と GPU、さらに NPU(Neural Engine)を使用。

Inception V3 での処理時間とスピードアップの程度

図 3: Inception V3 での処理時間とスピードアップの程度。すべてのバージョンで浮動小数点モデルを使用。CPU Baseline は 2 スレッド TensorFlow Lite カーネルを示す。
* GPU: Core ML は推論に CPU と GPU を使用。NPU: Core ML は推論に CPU と GPU、さらに NPU(Neural Engine)を使用。

使ってみたい方へ

必要な処理は、新しいデリゲートのインスタンスを使って TensorFlow Lite の Interpreter を呼び出すことだけです。詳しい説明は、完全版のドキュメントをご覧ください。推論の際には、Swift API(下の例)か C++ API(ドキュメントに記載)を使って TensorFlow Lite デリゲートを呼び出すことができます。

Swift の例

このデリゲートを一般的な Swift アプリケーションから呼び出す方法を示します。必要な処理は、新しい Core ML デリゲートを作成してオリジナルの interpreter の初期化コードに渡すことだけです。
let coreMLDelegate = CoreMLDelegate()
let interpreter = try Interpreter(modelPath: modelPath,
                                  delegates: [coreMLDelegate])

今後の作業

今後の数か月間で既存のデリゲートを改善し、対応する命令を増やしてさらなる最適化を行う予定です。ロードマップでは、トレーニング後に float16 量子化を行ったモデルのサポートを予定しています。これにより、わずかな精度と引き替えにサイズが約半分になるので、モデルを高速化できます。
ロードマップでは、トレーニング後の重みの量子化(ダイナミック量子化とも呼ばれます)もサポートする予定です。

フィードバック

これは、デベロッパーの皆さんから寄せられた共通の機能リクエストでした。この機能をリリースすることができてうれしく思います。皆さんのご感想をお待ちしています。直接ユースケースを共有するか、Twitter でハッシュタグ #TFLite と #PoweredByTF を付けてお知らせください。バグや問題は、GitHub から送信できます。

謝辞

Tei Jeong、Karim Nosseir、Sachin Joglekar、Jared Duke、Wei Wei、Khanh LeViet に感謝します。
注: Core ML、Neural Engine、および Bionic SoCs(A12、A13)は Apple Inc のプロダクトです。

Reviewed by Khanh LeViet - Developer Relations Team

この記事は Justin Schuh - Chrome エンジニアリング ディレクターによる Chromium Blog の記事 "Temporarily rolling back SameSite Cookie Changes" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


 2 月の Chrome 80 安定版リリースから、デフォルトで安全なサードパーティ Cookie 処理の適用が始まりました。これは、ウェブ全体でプライバシーとセキュリティを改善するために私たちが継続している作業の一環です。この変更は、2 月以降徐々にロールアウトされていますが、私たちは状況を細かくモニタリングし、エコシステムへの影響を評価しています。これには、Cookie が適切にラベル付けされるように個々のウェブサイトやサービスにあらかじめ通知することも含まれています。

しかし、COVID-19 が世界的に甚大な影響を与えている状況を踏まえ、本日(元記事公開当時)より、SameSite Cookie のラベル付けの適用を一時的にロールバックいたします。ほとんどのウェブ エコシステムはこの変更への対応が完了しておりますが、この期間の毎日の生活に欠かせない銀行、オンライン食品店、政府のサービス、ヘルスケアなどのサービスをウェブサイトが安定して確実に提供できるようにすることを優先します。このロールバックが行われても、組織やユーザー、サイトには何の悪影響もありません。

この変更に対応してくださったサイトや個々のデベロッパーの皆さんの作業は認識しています。また、この決断について知らせてくださったウェブ エコシステムからのフィードバックに感謝いたします。適用を再開するのは夏ごろになる見込みです。その際には、このブログや SameSite アップデート ページで事前にお知らせいたします。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は The TensorFlow Blog の記事 "Higher accuracy on vision models with EfficientNet-Lite" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
投稿者: ソフトウェア エンジニア、Renjie Liu


2019 年 5 月、Google は EfficientNet と呼ばれる一連の画像分類モデルをリリースしました。このモデルでは最高水準の精度を実現し、計算とパラメータを桁違いに削減できました。エッジデバイスで EfficientNet を実行できれば、計算リソースが限られているモバイルや IoT で新たな用途への扉を開くことができます。

本日は、 EfficientNet-LiteGitHubTFHub)についてお知らせします。EfficientNet-Lite は、モバイルの CPU や GPU、そして EdgeTPU で動作するように設計されており、TensorFlow Lite を使って実行します。EfficientNet-Lite は、EfficientNet のパワーをエッジデバイスに提供します。ユーザーは、低レイテンシ/小モデルサイズのオプション(EfficientNet-Lite0)から高精度オプション(EfficientNet-Lite4)まで、5 種類の中から選ぶことができます。その中で最も大きく、整数のみに量子化された EfficientNet-Lite4 は、Pixel 4 の CPU でリアルタイム(例: 1 イメージあたり 30ms)に動作しながら、ImageNet のトップ 1 で 80.4% の精度を実現します。次の図は、量子化した EfficientNet-Lite モデルと、同様に量子化したバージョンのいくつかの有名な画像分類モデルでパフォーマンスを比較した結果です。
図: 整数のみに量子化したモデルを Pixel 4 のCPU で 4 スレッドを使って実行

課題: 量子化と異種ハードウェア

エッジデバイス特有の性質により、いくつかの課題が生じます。

量子化: 浮動小数点のサポートが限られているエッジデバイスが多いため、量子化が広く用いられています。しかし、それには量子化に対応した複雑なトレーニング手続きが必要です。それがないと、トレーニング後の量子化モデルの精度が下がります。

ありがたいことに、私たちのツールキットに含まれる TensorFlow Lite トレーニング後量子化ワークフローを活用し、精度の低下を最小限に抑えてモデルを量子化することができました。

異種ハードウェア: モバイル GPU/EdgeTPU など、幅広いアクセラレータで同じモデルを実行するのは難しいことです。多くの場合、ハードウェアの特殊性から、こういったアクセラレータは限られたオペレーションでしかパフォーマンスを発揮しません。EfficientNet のオペレーションの中には、特定のアクセラレータでうまくサポートされないものがあることがわかりました。

この異種ハードウェア問題に対応するため、次のような簡単な修正によってオリジナルの EfficientNet を調整しました。
  • うまくサポートされていない squeeze-and-excitation ネットワークを削除しました。
  • すべての Swish 活性化関数を RELU6 に置き換えました。これにより、トレーニング後の量子化の質が大幅に改善しました(後述)。
  • スケーリングしたモデルのサイズと計算を減らすため、モデルをスケールアップする際のステムとヘッドを修正しました。

TensorFlow Model Optimization Toolkit によるトレーニング後の量子化

TensorFlow Model Optimization Toolkit のおかげで、簡単にモデルを量子化することができました。トレーニング後に整数のみに量子化することによって、多くの精度を失うこともありませんでした(詳細については、こちらのリンクをご覧ください)。その結果、モデルのサイズは 4 分の 1、推論速度は 2 倍になりました。
次に示すのは、精度とレイテンシについて、EfficientNet-Lite0 浮動小数モデルと、それを量子化したバージョンを比較した結果です。
* Pixel 4 の CPU で 4 スレッドを使ったベンチマーク
さらに、トレーニング後の量子化に関して、いくつかの経験を共有したいと思います。最初にトレーニング後の量子化を試したとき、精度が大幅に低下したことがわかりました。ImageNet データセットでのトップ 1 の精度が 75% から 46% に下がりました。
この問題の原因は、量子化後の出力範囲が広すぎたことだと判明しました。量子化は基本的に、浮動小数点値を int8 バケットに収まるようにアフィン変換することで行います。
量子化の図
今回の場合は、次に示すように、出力されるテンソルの範囲が -168 から 204 でした。 これは、精度が大きく失われた可能性があることを示しています。広範囲の浮動小数テンソルを int8 の範囲のバケットに収めるのは難しいからです。
この問題に対処するため、Swish 活性化関数を「範囲が限定された」活性化関数(relu6)に置き換えました。relu6 は、出力を [0, 6] に限定します。この変更後、ImageNet に対する量子化モデルのトップ 1 精度は、浮動小数点の基準値 75.1% に対して、74.4% まで回復しました。

皆さんのデータセットで EfficientNet-Lite をお試しください

皆さんのデータで EfficientNet-Lite のパワーを活用しましょう。TensorFlow Lite Model Maker を使うことをお勧めします。このツールを使うと、ユーザーの入力データを使って既存の TensorFlow モデルに転移学習を適用し、結果のモデルを TensorFlow Lite 形式にエクスポートすることができます。
TensorFlow Lite Model Maker は、MobileNetV2 や全種類の EfficientNet-Lite など、複数のモデル アーキテクチャをサポートしています。わずか 5 行のコードで EfficientNet-Lite0 画像分類モデルを構築する例を紹介します。
# Load your custom dataset
data = ImageClassifierDataLoader.from_folder(flower_path)
train_data, test_data = data.split(0.9)

# Customize the pre-trained TensorFlow model
model = image_classifier.create(train_data, model_spec=efficienetnet_lite0_spec)

# Evaluate the model
loss, accuracy = model.evaluate(test_data)

# Export as TensorFlow Lite model.
model.export('image_classifier.tflite', 'image_labels.txt')
花分類 notebook でライブラリを試してみてください。model_spec パラメータを変更すると、異なるモデルに簡単に切り替えることができます。tf_flowers のような小さなデータセットでは、5 エポックのトレーニングを数分行うだけで、最大 92% の精度を実現できます。エポックやデータを増やしてトレーニングするか、モデル全体を細かくチューニングすることで、さらに精度を改善できます。
次に、このモデルを使ってモバイルアプリを作ってみましょう。まず、Image Classification サンプルから着手します。このモバイルアプリは、EfficientNet-Lite で構築されており、すぐに実行することができます。アプリは Gradle タスクを使い、ImageNet データセットで事前トレーニングを行った EfficientNet-Lite モデルを assets フォルダーに自動ダウンロードします。Model Maker で作ったカスタムモデルを試したい場合は、assets フォルダーのモデルを置き換えます。
スクリーンショットからわかるように、EfficientNet-Lite モデルはリアルタイムに推論を実行します(30 fps 以上)。

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

リファレンス アプリをビルドし、いろいろ試してみましょう(手順)。また、TensorFlow Hub の EfficientNet-Lite を試し、TensorFlow Lite Model Maker を使って自分のタスク用にカスタマイズしてみましょう。TensorFlow Lite の詳細は、tensorflow.org/lite で学ぶことができます。 TensorFlow モデル最適化を試し、tfhub.dev で他の TensorFlow Lite モデルを探してみてください。

謝辞

Renjie Liu、Xunkai Zhang、Tian Lin、Yuqi Li、Mingxing Tan、Khanh LeViet、Chao Mei、Amy Jang、Luiz GUStavo Martins‎、Yunlu Li、Suharsh Sivakumar‎、Raziel Alvarez、Lawrence Chan、Jess Kim、Mike Liang、Shuangfeng Li、Sarah Sirajuddin

参考文献

[1] EfficientNet: Rethinking Model Scaling for Convolutional Neural Networks: https://arxiv.org/abs/1905.11946

Reviewed by Khanh LeViet - Developer Relations Team

この記事は The TensorFlow Blog の記事 "Exploring helpful uses for BERT in your browser with Tensorflow.js" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

投稿者: Philip Bayer(クリエイティブ テクノロジスト)、Ping Yu(ソフトウェア エンジニア)、Jason Mayes(デベロッパー アドボケート)


現在、言語で BERT を活用する方法について、たくさんのエキサイティングな研究が行われています。そこで、BERT をさらに身近な場所、つまり皆さんのウェブブラウザで使えるようにしたらどうなるだろうか、どんな活用法が生まれるだろうか、という疑問が浮かびました。

ウェブで Google に「自由の女神の高さはどれくらい?」といった質問をし、答え(93 メートル)を得るのは簡単です。しかし、ニュース記事、研究論文、ブログ投稿など、特定のコンテンツに関することを自然言語で尋ねる簡単な方法はありません。ブラウザのページ内検索機能(CTRL + F)を使うことはできますが、直接的なワード マッチングに頼ることになります。探したい言葉ではなく、質問を入力すればページで答えがハイライトされる方が簡単ではないでしょうか。

このアイデアについて考えるため、任意のウェブページについて質問できる MobileBERT Q&A モデルを使った Chrome 拡張機能のプロトタイプを作成しました。この拡張機能は、TensorFlow.js を使ってページの内容を元に回答を返します。モデルは完全に端末のブラウザ セッション内で動作するので、サーバーにデータが送られることはなく、プライバシーを維持できます。

まだ初期の実験段階ですが、このブログ投稿では、オープンソースの TensorFlow.js BERT モデルを使ってこのようなアプリケーションを構築する方法を説明するため、得られた知見を共有したいと思います。求めていた答えを得られた例や、期待はずれだった例について考えることは有益で、それによって可能性と、現時点での制約の両方を垣間見ることができました。こういった例に触れることで、誰もがこの議論に参加し、言語処理に機械学習をどう役立てることができるかというアイデアにつながることを期待しています。
Chrome 拡張機能で記事について質問すると、回答が得られる。

得られた知見

以下に、有益な答えが得られることがわかった結果の一部を示します。
  • カニについての記事 — 質問: “How do they move?”(どうやって移動しますか?)回答: “Crabs typically walk sideways”(カニは通常、横方向に移動します)
  • ヘッドランプの製品ページ — 質問: “Can it get wet?”(濡らしても大丈夫ですか?)回答: “submersion in up to 1m of water for 30min”(水深 1 メートルの水に 30 分までの水没)
  • 車のレビュー — 質問: “Gas mileage”(燃費) 回答: “19 miles per gallon in the city”(都市で 1 ガロンあたり 19 マイル)
  • 木製のビルについての記事: — 質問: “How tall is it”(どのくらいの高さですか) 回答: “280 feet in height”(高さ 280 フィート)
  • ラザニアのレシピ — 質問: “How long in the oven”(どのくらいの時間オーブンに入れますか) 回答: “25 minutes”(25 分)
モデルが期待どおりの回答を返さなかった例について考えるのも、興味深いことです。いくつかの例を示します。
  • こちらの製品ページ — “What is the pitcher made of?”(容器は何でできていますか?)と尋ねると、“BPA-free polycarbonate pitcher”(BPA フリーのポリカーボネート製容器)という回答ではなく、“Ice mode pulses at staggered intervals to uniformly crush a pitcher of ice in seconds”(アイスモードでは、時間を少しずつずらして振動させることで、数秒で容器内の氷を均等に砕きます)を返します。
  • こちらの記事 — “Were the sharks real?”(サメは本物でしたか?)と尋ねると、“sharks! sharks”(サメだ!サメ)というテキストが返されます。しかし、これに関連する質問 “How did the sharks work?”(サメはうまく動きましたか?)をすると、もう少し役に立つ回答 “mechanical sharks often malfunctioned”(機械仕掛けのサメは故障することが多かった)が得られます。

機械学習モデルの仕組み

MobileBERT Q&A モデルを使うと、ユーザーの自然言語による質問に回答するシステムを構築できます。このモデルは、SQuAD 1.1(Stanford Question Answering Dataset)で細かくチューニングされた事前トレーニング済み BERT モデルを使って作成されています。これは、事前トレーニング言語表現の新しい手法で、実にさまざまな自然言語処理(NLP)タスクで最高水準の結果を得ることができます。うれしいことに、このモデルが TensorFlow.js で皆さん独自の用途に利用できるようになったことをお知らせします。MobileBERT モデルはコンパクトな BERT の一種で、リソースが限られた端末にもデプロイできます。
このモデルは、文書と質問を入力として受け取り、文中のセグメントで質問の回答である可能性が最も高いものを返します。TensorFlow.js を使っているので、すべての処理はクライアント側のウェブブラウザで行われます。つまり、プライバシーは守られ、分析対象となるウェブサイトのテキストがサーバーに送られて分類に使われることは一切ありません。

TensorFlow.js BERT API

モデルはとても簡単に使うことができます。次のコード スニペットをご覧ください。
<!-- Load TensorFlow.js. This is required to use the qna model. -->
<script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs"> </script>
<!-- Load the qna model. -->
<script src="https://cdn.jsdelivr.net/npm/@tensorflow-models/qna"> </script>

<!-- Place your code in the script tag below. You can also use an external .js file -->
<script>
  // Notice there is no 'import' statement. 'qna' and 'tf' is
  // available on the index-page because of the script tag above.
  // Load the model.
  qna.load().then(model => {
    model.findAnswers(question, passage).then(answers => {
      console.log('Answers: ', answers);
    });
  });
</script>
このように、最初の 2 行で、ホストされているスクリプトから TensorFlow.js ライブラリと Q&A(質問と回答)モデルを読み込み、Q&A 検索を行えるようになります。これは 1 回呼び出せば十分です。モデルはメモリに保持されている間、読み込まれた状態が維持されます。findAnswers() は、何度でも呼び出すことができます。その際に、2 つの文字列を渡します。1 つ目は尋ねたい質問、2 つ目は検索対象となるテキスト(ページのテキストなど)です。すると、次の構造を持つ結果オブジェクトが返されます。
[
  {
    text: string,
    score: number,
    startIndex: number,
    endIndex: number
  }
]
取得できるのは、質問に対する答えとして最もあてはまる文書の一部と、その正しさの信頼度を表すスコアを含むオブジェクトの配列です。さらに、回答テキストがコンテキスト文字列の中のどこにあるかを簡単に特定できるように、回答テキストのインデックスも取得できます。これだけです!このデータを使って、見つけたテキストをハイライト表示したり、見栄えのいい形で結果を返したりなど、どんなクリエイティブなアイデアでも実装できます。
モデルを試してみたい方には朗報ですが、現在、MobileBERT Q&A モデルはオープンソース化され、こちらの Github リポジトリで公開されています。自慢したいものができたら、ソーシャル メディアで #MadeWithTFJS を使って TensorFlow.js チームにお知らせください。皆さんが作ったものをぜひ見てみたいと思っています。

Reviewed by Khanh LeViet - Developer Relations Team

この記事は Diana García Ríos による Google Play Apps & Games - Medium の記事 "Best practices for your in-app products in the current context" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。





現在の状況を踏まえた Google Play 定期購入とアプリ内プロダクトのベスト プラクティス


新型コロナウイルス感染症(COVID-19) によって引き起こされたこのような困難な状況の中、Google Play チームは、たくさんの皆さまから、アプリのデベロッパーとしてどのようにユーザーをサポートし、事業を継続していくべきかお問い合わせをいただいています。誰もがなんらかの影響を受けている中、とりわけ早急な対応を迫られているのは、次の 2 つに該当する皆さまだと考えています。

  • この困難な時期に特に役立つコンテンツやサービスを提供されている皆さま
  • 新型コロナウイルス感染症(COVID-19) によって事業に悪影響を受けてしまっている皆さま

医療、健康管理、オンライン学習、瞑想、福祉のアプリなどを通じ、価格を割り引いてでも重要なコンテンツやサービスを提供することで貢献している方がいらっしゃいます。また、多くの方が不要不急の外出ができない状況を鑑み、エンターテイメントや教育素材を安価に提供したいとお申し出くださる方がいらっしゃいます。同時に、スポーツリーグ、イベントやチケット関連のビジネス、マッチングアプリなど、事業の継続に影響が出ているという方もいらっしゃいます。


開発・運営されているアプリがこのようなカテゴリに当てはまる皆さんに向けて、アプリ内プロダクトや定期購入機能をこの状況に合わせて調整する際のベスト プラクティスをまとめました。必要な変更をする上で、この情報が役に立つことを願っています。


ベスト プラクティス

コンテンツやサービスを提供しているアプリのベスト プラクティス
サービスの割引を検討している場合、いくつかオプションがあります。どのような対応をするべきかは、プロダクトの種類や対象とするユーザーによって異なります。

  • すでに定期購入しているユーザーに対しては、提供するサービスが影響を受けてしまう期間に限って部分返金または全額返金をしたり、完全なサービスを再開できるまで課金を延期することができます。
  • 新しく定期購入するユーザーに対しては、プロモーション、無料試用、お試し価格を提供できます。その後、皆さんやユーザーにとって都合のよいタイミングで、更新価格を再調整できます。
  • ワンタイム購入ができるアプリでは、プロモーションを作成したり、一時的に価格を変更することができます。
  • 有償のアプリでは、最大 8 日間のセールを設定できます。


事業に悪影響を受けてしまっているアプリのベスト プラクティス


現時点では、アプリで販売している通常のデジタル商品を提供できないことがあるかもしれません。この状況に対応し、ユーザーに寄り添ったサービスを提供するために、価格の調整を検討することをお勧めします。

  • 定期購入の場合、サービスが完全に復旧するまで課金を延期することができます。長期間の定期購入の場合、サービスが影響を受ける期間に応じて部分返金をすることができます。
  • 提供できる別のオプションとして、定期購入の一時停止があります。このような対応を取ることを決めた場合、後ほどアップグレード特典の提供や課金の延期、部分返金をすることによって、ユーザーに再開を促すことができます。
  • ワンタイム購入有償アプリの場合は、部分返金または全額返金をすることをご検討ください。
  • また定期購入のアプリを変更し、ワンタイム購入が可能な新しいコンテンツの提供へ切り替えたデベロッパーもいらっしゃいます。一例として、ライブイベントの視聴サービスから、インタビューや録画コンテンツを提供する形式に変更されました。

例に上げた価格調整オプションでは皆さまが検討、直面されている状況に対応できない、または不十分だと思われる方は、ご要望をお知らせください

機能の詳細と実装方法


Google Play で提供している課金機能についてさらに詳しく説明します。

課金の延期

Google Play Developer APIPurchases.subscriptions:defer を使うと、定期購入しているユーザーに対して次の課金日を延期できます。該当するユーザーは引き続きすべてのコンテンツにアクセスできますが、延期期間中は課金されません。定期購入の更新日も、新しい日付を反映して更新されます。

課金の延期をすると、バンドルやスペシャル オファーの一部として、ユーザーへ無償アクセスを提供できます。たとえば、紙の雑誌を購読しているユーザーは、無償でウェブ コンテンツを参照できるように変更できます。また、ユーザーに無償アクセスを提供することもできます。

API の呼び出し 1 回につき、最短で 1 日、最長で 1 年課金を延期することができます。新しい課金日になる前に再度 API を呼び出すと、さらに課金を延期することができます。この対応を取る場合は、メールやアプリ内で課金日の変更を通知することをお勧めします。定期購入だけでなく、無料試用ユーザーにも同様に通知することをお勧めします。

値下げ

Google Play Console で、アプリの定期購入やワンタイム購入の価格を調整できます。アプリ内プロダクトは、Google Play Developer API でも変更できます。現在の価格要件は、ヘルプセンターに記載されています


初回の価格は、新しく定期購入するユーザーや、すでに定期購入しているユーザーが定期購入の更新をする際に適用されます。そのため、通常時ではプロモーションの手段として変更すべきでなく、お試し価格や無料試用プロモーションを使用します。しかし、現在の状況では、定期購入をしているすべてのユーザーに特別価格を提供することも、一時的な解決策として適切かもしれません。いずれの方法もプロモーション機能を活用するとユーザーのエンゲージメントを高めることができます。以下に、それぞれの機能と使用方法をまとめます。


無料試用を使うと、一定の日数で、見込み客に有償の定期購入を無償で提供することができます。定期購入価格やお試し価格を課金する前に無料試用を提供することで、コンバージョンを高めることができます。現在の不安定な状況を踏まえ、多くのデベロッパーが無料試用期間を延長しています。無料試用の提供は、サービスの利用を停止したユーザーに再開してもらうためにも有効です。


お試し価格を使うと、一定の日数または課金の期間中、見込み客の定期購入価格を割り引くことができます。定期購入価格を課金する前にお試し価格を提供することで、コンバージョンを高めることができます。こちらも、離脱ユーザーの再開促進として活用することができます。


初期設定では、無料試用もお試し価格もユーザー 1 人につき 1 アプリにつき 1 回だけ使うことができます。しかし、Play Console でこの制限を緩和し、1 つの定期購入につき 1 回に変更することができます。


アプリ内購入と有償アプリについては、1 つのアプリにつき 4 半期あたり 最大 500 個のプロモーション コードを適用できます。アプリ 1 つにつき、最大で 10,000 個のサブスクリプション コードを利用できます。プロモーション コードを使うには、アプリへの組み込みが必要です

全額返金または部分返金

Play Console のウェブサイトまたはアプリを使うと、皆さんのアプリでユーザーが購入したアイテムについて、注文の確認、返金の実行、定期購入のキャンセルの管理をすることができます。部分返金は、Play Console のウェブサイトからユーザー単位で実行できます。全額返金は、Play Console アプリや Play Console ウェブサイト、または Google Play Developer API を使ったプログラムから Purchases.subscriptions:refund を呼び出すことで実行できます。

定期購入の一時停止

これを有効にすると、ユーザーは Google Play 定期購入センターまたは定期購入キャンセル フローで定期購入の「一時停止」を選べるようになります。一時停止は、現在の課金期間が終了した後に反映されます。一時停止期間が終了するか、ユーザーが手動で定期購入を再開すると、課金が再開されます。


定期購入の一時停止をするには、以下の対応が必要です。

  • アカウントの一時停止を実装する
  • Play Console で一時停止を有効化する
  • 一時停止ステータスを認識する
  • ユーザーに支払いの失敗に関するアプリ内メッセージやメール メッセージを送っている場合は、定期購入の一時停止を参照するように変更する

定期購入の一時停止は、リアルタイム デベロッパー通知(RTDN)を設定しなくても有効化できますが、その場合、ユーザーが定期購入を一時停止または再開した際にバックエンドと同期をとるのが難しくなります(例 : クロスプラットフォーム権限管理など)。アプリからのディープリンクを提供すると、一時停止中のユーザーが Play Store アプリの定期購入センターを簡単に開けるようになります。

リアルタイム デベロッパー通知(RTDN)
RTDN は、定期購入ユーザーの状態が変化した際(例: 定期購入の実行、キャンセル、一時停止)に、サーバーにインスタント通知を送信する機能です。この通知を受け取ったときに、適切なメッセージを使って定期購入ユーザーに連絡することもできます。たとえば、定期購入ユーザーがキャンセルした場合、「現在、通常サービスの提供が困難な状態です。ぜひサービスの再利用をお願いしたいので、定期購入価格を 50% 割り引きます」といったメッセージを送って再開を促せます。

RTDN は、定期購入の実行や更新などのイベントを含め、すべての定期購入イベントを正確に記録し保存するためにご利用ください。リアルタイム トラッキングを使うと、個々の定期購入ユーザーの無料試用の登録有無など、Google Play Console では利用できない細かい点まで把握できるので、収益レポートの改善にも役立ちます。

ディープリンクによる課金の再開
先行きの見えない状況のため、Google Play で定期購入をキャンセルするユーザーもいるかもしれません。その場合、デベロッパーの皆さんは、カスタマーサービス リクエストへの応答の中で Google Play Developer API の Purchases.subscriptions:cancel を呼び出すと、定期購入をキャンセルできます。注 : 通常、この API は、ユーザーが [My Orders] ページから返金をリクエストした場合に利用します。詳しくは、定期購入費用の返金をご覧ください。


ユーザーが定期購入をキャンセルしても、現在の課金サイクルが終わるまではコンテンツにアクセスできます。課金サイクルが終了した時点で、アクセスは無効になります。なお、必ずアプリから Play Store アプリの定期購入の管理ページに簡単にアクセスできるように、ディープリンクを提供する必要があります。これにより、ユーザーは再開を含めた定期購入ステータスをいつでも管理できるようになります(こちらのサンプルコードをご覧ください)。


ここでご紹介した機能が、この困難な時期に皆さんのユーザーやビジネスをサポートするためにお役に立つことを願っています。Google は、皆さんがユーザーとさらに良い関係を築き上げ、予期しない事態にも対応できるようなプラットフォーム作りを目指しています。もし皆さんのアプリが、ここで触れていないような影響を新型コロナウイルス感染症(COVID-19) によって受けている場合も、可能な限りお手伝いしたいと考えています。その場合は、こちらからご連絡ください


感想をお聞かせください

現在の状況を踏まえて、定期購入やアプリ内プロダクトに対する別の方法を考えている方は、#AskPlayDev を付けて Twitter でお知らせください。Google Play で成功するためのニュースやヒントを定期的にご紹介している @GooglePlayDev でご回答します。


Reviewed by Hidenori Fujii - Google Play Developer Marketing APAC


Google Cloud は、インターネットサービス業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーの皆様に向けて、"Google Cloud INSIDE Digital" をオンラインで開催します。

業界をリードする方々や、深い専門知識をもつ Google 社員が、注目インターネットサービスの開発の裏側や、Google Cloud Platform を中心としたテクノロジーアップデートをお届けします。この Google Cloud INSIDE Digital をきっかけに新しいサービスやプロダクトが生まれるような会に参加者の皆様と共に育てて行きたいと考えています。今回は、"先進的な企業におけるデータ利活用" をテーマにお送りします。

開催概要
名 称 : Google Cloud INSIDE Digital
日 時 : 2020 年 5 月 14 日(木)  18 : 00 - 20 : 15
主 催: グーグル・クラウド・ジャパン合同会社

参加申し込み


https://goo.gle/34hDwBw

上記リンクからお申し込みください。

※ 競合他社様、パートナー企業様からのお申し込みはお断りさせていただくことがございます。
※ 報道関係者のご参加はお断りさせていただきます。 
※ ビジネス向けのイベントとなっております。学生の方のご参加はご遠慮ください。
※ 参加いただける方には、後日、ご登録されたメールアドレスに参加のご案内をお送りします。


Posted by Takuo Suzuki - Developer Relations Team