この記事は Google Maps Platform Software Engineer の Jamie McCloskey による Google Cloud Blog の記事 "Announcing new styling and gameplay features on Google Maps Platform" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



魅力ある没入型のリアルワールド ゲームを構築するのは本当大変な作業です。1 年前、ゲーム開発向けの Google Maps Platform を発表し、このチャレンジに向けたプラットフォームを確実に作るため、ゲーム開発者と密に連携してきました。そして、Google Maps と世界をリアルタイムで理解するパワーを活用するということを「位置情報を利用してモバイルゲームを次のレベルに押し上げる」という記事の中で述べさせていただきました。



ゲームがプレイヤーの環境にリアルタイムで適応できた時、そこに何を打ち立てることができるかを想像してみてください。Google Maps Platform を活用すれば、交通量の多い道路がその瞬間に混雑しているかどうか、また夜間の工事のためにいつ通行止めになるのかが分かります。オフィス街が、平日のどの時間帯に人（あるいはプレイヤー）で混雑するのか、また週末のどの時間帯に閑散とするのかも分かります。さらに、プレイヤーが公共の場にいるのか、または私有地にいるのかも知ることができます。レストランや店舗の毎日の営業時間についても分かります。Google Maps Platform によって、ゲームプレイをロケーション（位置）やそのコンテクストに合わせて理解し、適応させることが可能となります。すなわち、あらゆるプレイヤーが、世界のどこにいようとも、最高のゲーム体験を得ることができるのです。


さて、このたび、よりコンテクスチュアルな、魅力の増したゲームプレイを構築するために、Google Maps Platform に新機能を追加しました。 経路探索、土地利用データ、標高に関する機能です。


経路探索は、Google Maps の経路探索アルゴリズムを使い、次のような新たなエクスペリエンスの実現を可能にします。モンスターがプレイヤーを追いかけるように指示する、ドローンを飛ばして供給物資を安全な建物に落とす、未来都市で協力してミッションを遂行するというものです。



土地利用データを使ってゲームプレイをデザインする機能も追加しました。これにより、その位置の土地の表面の種類に関する情報を入手できるようになります。ここで皆さんは、砂漠でサボテンを生長させたり、草原でプレイヤーに昆虫を捕まえさせたり、アライグマを裏通りのごみ収集箱に置いたりすることが可能になります。掃除機を振り回してさまざまな生物、建物などを吸い込む宇宙怪物を作るというのはいかがでしょうか？




また、地形標高の機能も追加しました。これは、平面的な世界で退屈している人にとっては、非常に興味がそそられる機能です。この機能により、丘、山、都市を好みのスタイルに設計し、一層カスタマイズされた位置情報の要素をゲームに組み入れることができます。




素晴らしいものを構築しよう

没入型のリアルワールド ゲームのデザインは、ゲームプレイを現実の世界に単に置くこと以上のことを行うことになります。プレイヤーがそのゲームを体験する上で不可欠な実在する場所を作ることです。プレイヤーが、いつ、どこでプレーし、その時彼らの周囲に何が存在しているのかを把握します。Google Maps のデータと Google のインフラストラクチャによって、ゲームの世界を現実世界に変えるということです。2005 年より、Google は世界の地図を作製してきました。そして、今、現実世界について知っている情報を自身のゲームで生かすことができるのです。


詳しくは、Google Maps Platform に関するウェブサイト g.co/mapsplatform/gaming を閲覧ください。




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

この記事は Pinar Ozlen による The Firebase Blog の記事 "Life of a message from FCM to the device" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Firebase Cloud Messaging（FCM）をお使いなら、さまざまな方法でメッセージを送信できることをご存知でしょう。特定の端末上のアプリをターゲットにすることも、トピック API を使ってたくさんのユーザーをターゲットにすることもできます。FCM の API は、リクエストの処理に失敗するとエラーコードとその説明を返すので、失敗したことがわかります。ただし、それが当てはまるのは、皆さんと FCM バックエンド間のリクエストの一部だけです。では、FCM がメッセージ リクエストを受けると、何が起こるのでしょうか。
この投稿では、Firebase Cloud Messaging のインフラストラクチャと、メッセージが実際に端末に配信される仕組みについて解説します。

メッセージの受け入れ

FCM が API リクエストに対して成功応答を返した場合、これは単に、FCM が端末または端末にメッセージを配信するサービス（例: iOS 端末に配信する場合は Apple Push Notification サービス、Firefox ブラウザに配信する場合は Mozilla Push Service）にメッセージ配信の試行を始めるという意味にすぎません。この試行は、以下のいずれかの条件が満たされるまで繰り返されます。

1. メッセージの有効期限が切れる: メッセージの有効期限は、API を通して設定できます。FCM が再試行する期間は最長 28 日間で、これが既定値になっています。
2. リクエストしたメッセージが別のメッセージで置き換えられる: 折りたたみキーを設定することで、メッセージを新しいバージョンのメッセージで置き換えることができます。その一例として、最新のスコアをユーザーに伝えるスポーツ アプリがあげられます。意味があるのは最新メッセージだけです。
3. 端末が 1 か月以上オンラインになっていない: FCM が端末の接続についての情報を持っており、端末が 1 か月以上オンラインになっていないことがわかっている場合、FCM はメッセージを受け入れますが、実際には配信を試行しません。端末が再びオンラインになると、FCM は保留中のメッセージが削除されたことをアプリに通知します。
   1. Android では、端末が再びオンラインになると、FCM が onDeletedMessages() を呼び出します。
   2. iOS では、アプリが開かれたときに FCM が FIRMessagingMessagesDeletedNotification を呼び出し、保留中のメッセージが削除されたことをアプリに通知します。 注: 保留中のメッセージが有効期間を過ぎた場合、これらの関数が呼ばれることはありません。

メッセージの配信

実際の端末へのメッセージの配信と、FCM が提供できる配信情報の量には、多くの要素が影響しています。

共通の要素

1. 端末がオフラインになっている: 端末がオンラインでない場合、FCM はメッセージを配信できません。オフラインになる端末は多く、二度とオンラインにならない端末もあります。FCM はこのような端末のアプリに送られたメッセージも受け入れを続けますが、端末が再びオンラインにならない限り、メッセージが配信されることはありません。
2. メッセージの優先度: FCM API を使ってメッセージの優先度を高または通常に設定することができます。Android、iOS のどちらのプラットフォームでも、電池を最適化しつつ、設定に応じてメッセージを配信します。

Android の要素

1. Doze モード: FCM は、端末が Doze モードになっている場合、それが解除されるまで優先度が通常のメッセージの配信を控えます。優先度高のメッセージは即座に送信されますが、端末の Android アプリ スタンバイ バケット ポリシーによる制限を受けます（Android P 以降）。
2. アプリ スタンバイ バケット: Android P 以降では、すべてのアプリがアプリ スタンバイ バケットに従います。そのため、メッセージの優先度を高に設定しても、アプリを復帰させるための割り当てが十分でない場合、端末がメッセージの配信を遅らせる場合があります。詳細については、こちらをご覧ください。
3. バックグラウンド制限: Android は、アプリがバックグラウンドで実行されているときは、機能を制限します。アプリを強制的に停止した場合や、アプリがこの制限に従っていない場合、メッセージがアプリに配信されない場合があります。
4. ユーザーによるバックグラウンド制限: FCM は、ユーザーがバックグラウンド制限を設定しているアプリにはメッセージを配信しません。
5. アンインストールされたアプリ: FCM が端末へのメッセージ配信を試みたもののアプリがアンインストールされていた場合、端末はただちにメッセージを破棄し、登録トークンを無効にします。それ以降、その端末にメッセージを送信しようとすると、API のレスポンスは 'NotRegistered' エラーとなります。

注: プロジェクトのメッセージ配信イベントを分析したい場合は、FCM データを BigQuery にエクスポートして分析できます。

iOS の要素

FCM は、iOS 端末に対して次の 2 つの方法でメッセージを送信します。

1. APN チャンネル: 最もよく使われるのは、APN 経由でメッセージを送信する方法です。FCM v1 HTTP API を使ってメッセージ配信をリクエストしている場合や、以前の FCM API を使って表示メッセージを送信している場合は、FCM が APN にアクセスして通知を配信します。APN がメッセージ リクエストを受け入れると、端末に通知を配信するのは APN の役割になります。この場合、FCM 自体は配信情報を収集しません。APN から送信されるメッセージは、他の APN メッセージと同様のメッセージ配信要素の影響を受けることになります。APN 経由の iOS 端末への配信に影響を与える要素の詳細については、こちらをご覧ください。
2. FCM ダイレクト チャンネル: iOS 端末にメッセージを送るもう 1 つの方法は、FCM ダイレクト チャンネルです。以前の FCM API を使ってデータのみのメッセージを送信し、かつ shouldEstablishDirectChannel メソッドでダイレクト チャンネル接続を有効にしている場合、メッセージはダイレクト FCM チャンネル経由で配信されます。アプリがバックグラウンドで動作している、または閉じられている場合、FCM バックエンドはメッセージ キューを使って保留中のメッセージを追跡します。アプリがフォアグラウンドになって再接続されると、チャンネルが自動的にクライアントに保留中のメッセージを送信します。これは、クライアントからの確認応答を受信するまで繰り返されます。 注: iOS で表示用の通知の配信情報にアクセスしたい場合は、FCM Reporting Dashboard を使用できます。このダッシュボードは、Firebase 向け Google アナリティクスのデータ共有機能を使い、Android および iOS の Firebase SDK 経由で表示用の通知の配信情報を収集します。

ウェブの要素

1. Android の制限: Android のブラウザでウェブアプリを実行している場合、「Android の要素」に記載したすべての制限がウェブにも適用されます。
2. プッシュ サービス: Push API 対応のブラウザ上で動作しているウェブアプリにプッシュ通知を配信し、そのブラウザが別のプッシュ サービスを使ってメッセージを配信している場合、FCM はそのプッシュ サービスにメッセージを渡して配信してもらいます。メッセージを渡した後は、メッセージを配信するのはそのプッシュ サービスの役割となります。そのため、プッシュ サービスによっては、別の制限が課される可能性があります。

メッセージの受け入れと配信の詳細については、メッセージの有効期間およびメッセージ配信についてをご覧ください。


Reviewed by Khanh LeViet - Developer Relations Team

この記事は Shan Carter による Google AI Blog の記事 "Exploring Neural Networks with Activation Atlases" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


 投稿者: Google AI ソフトウェア エンジニア、Shan Carter


ニューラル ネットワークは、コンピュータによる画像処理における新しいデファクト スタンダードになりつつあります。写真ライブラリでの自動タグ付けから自律運転システムに至るまで、さまざまな用途に利用されるようになりました。しかし、こうして作られた機械学習システムのふるまいは自動化されたトレーニング プロセスの中で獲得されるため、個々の認識をニューラル ネットワークがどのように実行しているのか、少し謎に包まれた部分もあります。


先日、Google AI と OpenAI は 「Activation Atlas でニューラル ネットワークを探索する」という記事を公開しました。この記事では、画像認識用のニューラル ネットワークが入力された画像の何を「見て」いるのかという問いに答える新しい手法、Activation Atlas（活性化の地図）について説明しています。これは、畳み込みによる画像認識用ニューラルネットワーク（CNN）を可視化する新たな手法です。ネットワークの隠れ層で行われていることを人間が理解できるように表現でき、その全体を見たり、個々の階層を表示したりできます。この手法は、機械が学習した「画像の構成要素」を明らかにします。つまり、それらの組み合わせで複雑な画像表現を構成できる、それ以上分割できない基本要素が得られます。

また今回、Activation Atlas を誰でも試せる Jupyter ノートブックもリリースしました。

画像認識用ニューラルネットワーク Inception V1 の層の 1 つを Activation Atlas で表示した詳細イメージ。ネットワークが画像を分類するために、さまざまに異なる種類の画像検出を適用していことがわかる。たとえば、果物のような構造、ハチの巣状のパターン、織物のような質感など。

次に示す例は、ImageNet データセットでトレーニングした CNN である Inception V1 に対して Activation Atlas を適用したものです。CNN では一般に、画像を受け取ってそれにラベルを付けます。具体的には、事前に決められている「カルボナーラ」「シュノーケル」「フライパン」といった 1,000 種類ほどのラベルをそれぞれの画像に付けておきます。これを行うために、ネットワークは 10 個ほどの層を使って画像データを段階的に評価していきます。それぞれの層は数百個のニューロンから成り、その個々のニューロンは画像のさまざまな部分に反応して活性化します。ある層のあるニューロンは犬の耳に反応したり、入力側の層のあるニューロンはコントラストの強い縦線に反応したりします。

Activation Atlas は、100 万枚の画像からニューラル ネットワークの各層の内部的な活性化状態を集めることで構築されています。この活性化状態は複雑な高次元ベクトルの集まりで表現されています。それを、UMAP でわかりやすい 2 次元のレイアウトに投影します。UMAP は、高次元データからその本質的な構造を取り出すための次元削減の技術です。

これで活性化ベクトルを整理できますが、すべての活性化状態を収集すると一目ではわからないほど膨大な数になるので、それを集約して実際に扱える程度に減らす必要があります。そこで、作成した 2 次元レイアウトの上にグリッドを描画します。グリッド内のそれぞれのセルで、セルの境界内にあるすべての活性化状態の平均を計算し、特徴の視覚化によって個々のセルを表す画像を作成します。

左: ランダムな 100 万個のイメージをネットワークに入力し、画像ごとに空間的な活性化状態を 1 つ、ランダムに収集する。中央: 活性化状態を UMAP に渡し、2 次元まで次元を減らす。その結果をプロットする。似たような活性化状態は互いに近くに配置される。右: グリッドを描画し、セルに対応する活性化状態の平均を計算して、平均化した活性化状態の特徴を反転させる。

下の図は、ニューラル ネットワークのある 1 つの層だけを Activation Atlas で表したものです（先に触れたように画像認識モデルは通常たくさんの層を備えます）。これは、ネットワークがこの層で学習した視覚的概念をすべて網羅する図です。こうした Activation Atlas による可視化の結果はあまりに膨大すぎて、見慣れないうちは意味がわからないかもしれません。このたくさんのさまざまな模様が、画像認識モデルが作り出したさまざまな視覚的抽象化と概念を反映しています。

Inception V1 の多くの層の 1 つ（mixed4c）を Activation Atlas で表現した概要図。ネットワークの中ほどに存在する層を表している。

この付近では、さまざまな種類の葉や植物を検出していることがわかる。

ここでは、さまざまな水域、湖、砂州を検出している。

ここには、さまざまな建物や橋がある。

前述のように、このネットワークには、ほかにもたくさんの層があります。ネットワークの奥に向かうにつれて概念が細分化されていくことを確かめるため、この層の前の層を見てみましょう（それぞれの層は、前の層の活性化を受けて活性化します）。

前の層である mixed4a には、漠然とした「哺乳類」の領域がある。

ネットワークの次の層の mixed4b では、動物と人が分かれ、その間には果物や食べものが現れている。

mixed4c 層では、以上のような概念がさらに細分化され、小さな「半島」状になって区別されている。

層を重ねるごとに全体的な構造が進化していきますが、個々の概念も具体的で複雑なものになっていくことがわかります。3 つの層について、具体的な分類項目である「キャベツ」に関係する領域に注目してみると、それがよくわかります。

左: 最初に近い層。ほかの層に比べると、具体性が低い。中央: 中ほどの層では、明らかに葉のようなイメージだが、種類まではわからない。右: 最後の層では、葉が球状に丸まっているキャベツ特有のイメージになっている。

もう 1 つ、注目すべき現象があります。層を重ねるごとに概念が細かくなっていくだけでなく、古い概念を組み合わせて新しい概念が現れているように見えます。

中ほどの層である mixed4c（左および中央）では、砂と水は別々の概念になっている。「砂州」という分類項目は、その両方と強く結びついている。その後の層である mixed5b（右）と比較すると、2 つの概念が 1 つの活性化状態として融合していると考えられる。

特定の層全体を表す Activation Atlas の特定の領域にズームすることもできますが、ImageNet の 1,000 の分類項目の 1 つに注目し、その特定の層の Activation Atlas を作ることもできます。これを見ると、ネットワークが特定の分類項目に分類する際に、特に頻繁に使っている概念とそれをどう探しているかがわかります。たとえば、「アカギツネ」の例を見てみましょう。

ここから、ネットワークが「アカギツネ」に分類する際に、何に注目しているかがよくわかる。耳がとがっていること、赤い毛で鼻の周りが白くなっていること、背景が森や雪であることがあげられる。

ここでは、さまざまな拡大率や角度の「瓦屋根」を検出している。

「アイベックス」では、角と茶色い毛皮を検出していることがわかる。それだけでなく、アイベックスがいる岩場などの環境も検出している。

瓦屋根の場合と同じく、「チョウセンアザミ」でもさまざまな大きさのチョウセンアザミの画像を検出している。それに加えて、紫色の花を検出している部分もある。チョウセンアザミの花を検出しようとしているものと考えられる。

このような Activation Atlas から、モデル内で細やかな視覚的抽象化が行われていることがわかります。それだけでなく、概念的なレベルの間違いが起きていることがわかる場合もあります。たとえば、「ホホジロザメ」の Activation Atlas を見てみると、水と三角形のひれが出てきます。これは予想どおりですが、野球ボールのようなものがあることもわかります。ここから、このモデルが覚えてしまった「近道」がわかります。つまり、野球ボールの赤い縫い目と、口を開けたホホジロザメを似ているものとして認識しています。

これをテストするため、野球ボールのイメージの一部を貼り付けてみると、モデルは「コククジラ」の特定のイメージを「ホホジロザメ」に分類するようになります。

この Activation Atlas が、機械学習をより身近で解釈しやすくする技術のひとつとして活用されることを期待しています。簡単に試せる Jupyter ノートブックをリリースしましたので、ブラウザで Colab を開き、1 回クリックするだけですぐに実行できます。Activation Atlas は、以前にリリースされたツール Lucid をベースとしており、わかりやすい視覚化を行うさまざまな技術を備えています。


Activation Atlas を使って皆さまが見つけた新しい発見の報告をお待ちしています。


Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

この記事は コーラルチーム Billy Rutledge（ディレクター）、Vikram Tank（プロダクト マネージャー）による Google Developers Blog の記事 "Introducing Coral: Our platform for development with local AI" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


AI はあらゆる人にメリットをもたらします。調査や学習、開発作業を共同で行う場合、特にそれが当てはまります。この目的を実現し、誰でも AI を使った開発ができるようにするため、Google は TensorFlow や AutoML といったツールを開発しています。本日、コーラルが公開ベータ版になり、皆さんがアイデアやプロダクトを構築する方法がさらに広がります。

コーラルは、ローカル AI を搭載したインテリジェントな端末を構築するためのプラットフォームです。


コーラルが提供するのは、簡単にアイデアをプロトタイプから製品へと発展させることができる完全なローカル AI ツールキットです。コーラルには、端末のローカルでニューラル ネットワーク（NN）を作成、トレーニング、実行する際に役立つハードウェア コンポーネント、ソフトウェア ツール、コンテンツが含まれています。私たちはローカルで NN を高速化することに主眼を置いているため、コーラル製品群は優れたニューラル ネットワークのパフォーマンスを発揮でき、プライバシーも強力に保護され、すべてが電力効率のよいパッケージにまとめられています。皆さんがアイデアを市場に出せるように、コーラルのコンポーネントは、高速なプロトタイピングと簡単な生産ラインへのスケーリングができるように設計されています。


最初のハードウェア コンポーネントの特徴は、新しい Edge TPU にあります。これは、Google の設計による小型 ASIC で、低電力端末でも高いパフォーマンスで ML 推論を行えるようになっています。たとえば、MobileNet V2 などの最新のモバイル視覚モデルを、100 fps 以上で電力効率よく実行できます。



コーラル開発ボードは、新しいプロダクトの開発用です。完全に統合されたシステムで、キャリアボードに接続された System on Module（SoM）として設計されています。この SoM は、強力な NXP iMX8M SoC と Google の Edge TPU コプロセッサを組み合わせたものです（Wi-Fi、Bluetooth、RAM、eMMC メモリも含まれています）。コンピュータ ビジョン アプリケーションのプロトタイピングを簡単に行えるように、MIPI インターフェースで開発ボードと接続できるカメラも提供します。


既存の設計に Edge TPU を追加したい場合は、コーラル USB アクセラレータを使うと、USB 2.0 や 3.0 経由でどんな Linux システム（Raspberry Pi ボードも含む）にも簡単に組み込むことができます。PCIe バージョンも近日中に登場する予定で、M.2 または mini-PCIe 拡張スロットにはめ込むことができるようになります。


生産ラインへのスケーリングの準備ができた方のために、開発ボードを元にした SOM と PCIe バージョンのアクセラレータの大量発注も受け付けます。独自のキャリアボードを作ってさらに統合を進めたい方のために、ベースボードの回路図も公開する予定です。
ソフトウェア ツールは、TensorFlow と TensorFlow Lite をベースとしています。TF Lite モデルは、量子化して Google のツールチェーンを使ってコンパイルした上で、Edge TPU で直接実行する必要があります。簡単に試せるように、トレーニングおよびコンパイル済みでコーラルボードですぐに動作させることができる 10 個以上のモデルと、それを再トレーニングするためのソフトウェア ツールを共有しています。


コーラルを使ってネットワーク接続端末を構築したい方は、Google Cloud IoT と組み合わせることができます。Google Cloud IoT は、クラウド サービスと端末上のソフトウェア スタックを組み合わせ、機械学習機能を利用するマネージド エッジ コンピューティングを実現できるようにしたものです。


コーラル製品群は、本日より入手可能です。製品ドキュメント、データシート、サンプルコードは、g.co/coral に掲載されています。今回の公開ベータ版期間中にぜひお試しください。公式リリースの際には、さらに多くの情報を共有できることを楽しみにしています。


Reviewed by Khanh LeViet - Developer Relations Team

この記事は Cloud Blog の記事 "Pi in the sky: Calculating a record-breaking 31.4 trillion digits of Archimedes’ constant on Google Cloud" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Posted by Emma Haruka Iwao - Developer Advocate, Google Cloud

この記事は Medium Blog の記事 "Publishing private apps just got easier" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


イラスト: Virginia Poltrack

この記事は Google Maps Platform Product Manager の Serena Chang による Google Cloud Blog の記事 "Take mobile gaming to the next level with location" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。







位置情報を利用してモバイルゲームを次のレベルに押し上げる




ゲームは、世界と物語の創造にほかなりません。その世界が豊かになればなるほど、リアルにゲームを体感できるのです。最も初期のビデオゲーム（1972 年の Pong を思い出してみてください）は、平面の二次元スクリーンに限られたものでした。しかし、それでも、Pong は素晴らしいゲームであり、私自身、何度も Pong で遊びました（言うまでもなく、その後も、Pong 以外のゲームを楽しんでいます）。今日、詳細なストーリーと没入できる世界観を作ることは、ゲームの基準になっています。すなわち、もっと大規模でリアルな 3D 環境がゲームには期待されているのです。



この変化がゲームの世界で巻き起こったのと同時に、スマートフォン、ビッグデータ、機械学習が、地図を紙の上の平面画像から高度にパーソナライズ化されたリアルなモデルへと進化させました。ゲームと地図、この 2 つの分野が交差する部分こそ、デベロッパーにとって全く新しいゲーム体験を創造する上での好機になると考え、昨年、Google Maps Platform のゲーム向けソリューションを立ち上げたのです。



2018年には 5 つのゲームが Google Maps Platform で立ち上がり、現実世界のゲームについて多くの事を学びました。



位置情報が AR とソーシャルゲームの扉を開く




充実した、ダイナミックでコンテクスチュアルな位置情報によって、ゲーム開発者はソーシャルとAR（拡張現実）のゲーム体験を増強、向上させることができます。昨年の ARCore ゲーム⁽¹⁾のトップ 10 のうち 3 つが、Google Maps Platform を使って制作されました。



位置情報に基づいたソーシャル機能によって、プレイヤーはチームを組めるだけではなく、プレイヤーの位置によって複数プレイヤーのゲームをより充実させることができます。Next Games 社は、The Walking Dead: Our World で、この利点を強く実感したそうです。このゲームは、プレイヤーが「ギルド」と呼ばれるグループを作り、フレアを同じギルドの他のプレイヤーに送ってバーチャルな形で合流し、フレアにまつわるミッションを完了するというものです。



ディレクターの Riku Sumela 氏は、位置情報がプレイヤーのゲームのソーシャル体験に与えるインパクトを次のように語っています。「地理的な位置情報を持っていなければ、ソーシャルに基づく現行システムは機能しません」。事実、毎日ゲームをするアクティブユーザーの 90% はギルドに参加しており、4 分の 3 のプレイヤーが友人とともにゲームを楽しんでいます⁽²⁾。ソーシャル エンゲージメントはとても高いといえるでしょう。



位置情報がプレイヤーのエンゲージメントとリテンションを高める




最近は、年齢や職業に関わらず、多くの人々がゲームを楽しんでいます。朝夕の通勤ラッシュに追われる人、多忙な買い物客、単に日常の生活を送っている人々もいます。モバイルゲームに位置情報を組み込むことにより、開発者はより没入型、パーソナライズされたゲームを開発できるようになります。新しい位置情報を追加することで、それまでとは異なる形でゲームを楽しむことができるのです。






例えば、モンスターをハンティングしているプレイヤーは、歯科医院の近くで歯を剥き出しにしたモンスターを見つけたり、レストランの周辺でお腹をすかせたモンスターを見つけたりできます。Ludia 社の Jurassic World Alive がその実例です。同社の位置情報を利用しない他のゲームと比べた場合、2 倍ものプレイヤーが位置情報を利用したゲームを頻繁に起動することがわかりました。前述の Next Games 社 の The Walking Dead: Our World では、7 日間の定着率が、アメリカのトップ 50 のゲームの平均値と比べて 54% も高かったそうです⁽³⁾。また、ゲームを通じて、プレイヤーのいる現場とプレイヤーがつながると、ゲーム内のエクスペリエンスはさらに没入的なものとなります。結果として、エンゲージメントとリテンションの大幅な増大につながるのです。


位置情報が既存のモバイルゲームに新しい命を吹き込む


Google Maps Platform ゲームソリューションの開発を始める際、一つのアイデアがありました。それは、デベロッパーに対し、まったく新しい現実世界のゲームを開発するためのツールを提供しようということでした。創造力に富んだパートナーによって、その可能性は予想以上に広がっています。現実世界のゲームは、一から作り上げる必要はありません。位置情報のインテリジェンスが既存のゲームに新しい命を吹き込むことを私たちは実感しています。




©︎XFLAG

ミクシィは、モンスターストライク（モンスト）⁽⁴⁾にマップモードを実装しました。 昨年、このゲームはモバイルアプリとして最高の収益を上げました⁽⁵⁾。モンストは既に人気の高いゲームです。ミクシィは位置情報に基づくインゲーム要素を加えて、ユーザーに新たな魅力を提供しました。この結果、モンスポットをプレイしているユーザーは、プレイしていないユーザーと比較して、ユーザー 1 人あたりのゲーム起動数が 30%（1 日あたり）も上昇しました。しかも、この要素を利用したユーザーのうち 50% は、ゲームを 5 日間以上連続でプレイしています。ミクシィの例から学べることは、ゲーム開発者は、位置情報の要素をゲームプレイに組み込み際、自分たちの次のゲームをリリースするまで待つ必要はないということです。位置情報の要素を実装することが、既存のゲームをより強力な新しい局面へと押し上げる可能性があるのです。


位置情報という特性と現実世界型のゲームプレイは、ゲームそのものに対し、単にエクスペリエンスを付加する以上の効果をもたらします。すなわち、ゲームを再定義するものであり、業界内で既に見てきたものを超越する可能性があると考えています。Google Maps Platform を活用して世界のデベロッパーたちと共に開発に励み、現実世界のゲーム エクスペリエンスを生み出すことを楽しみにしています。



ロサンゼルスにある実際の道路の上で人々を走らせたり、ゾンビから生存者を救出したり、プレイヤーの住む地区の未来的な風景の中で戦闘を繰り広げたりと、その舞台設定は実にさまざまです。私たちは、皆さんと一緒にものすごいものを作ることを楽しみにしています。

(1) 出典: Internal Google data
(2) 出典: 2019 Mobile Gamers Study; an online survey conducted by Honest Data, Inc. . n= 2,000 active mobile gamers in the United States, the United Kingdom, Canada, and Australia.
(3) 出典: AppAnnie 2018
(4) “ミクシィ”、“XFLAG”、“モンスターストライク”、“モンスト”、“MONSTER STRIKE”は株式会社ミクシィの商標または、登録商標です。
(5) 出典: Sensor Tower 2018




Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps Solution Architect, Google Maps

この記事は Alex IngermanとKrzys Ostrowskiによる TensorFlow - Medium の記事 "Introducing TensorFlow Federated" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


投稿者: Alex Ingerman（プロダクト マネージャー）、Krzys Ostrowski（リサーチ サイエンティスト）


世界には、30 億台のスマートフォンと、70 億台のネットワーク接続端末が存在していると考えられています。こういったスマートフォンや端末は、絶え間なく新しいデータを生成しています。従来の分析手法や機械学習を使う場合、データを処理して洞察や ML モデルを生み出し、それをプロダクトの改善につなげる前に、データを 1 か所に集めなければなりません。しかし、プライベートなデータを扱う場合や、データを 1 か所に集めるためにコストがかかる場合は、この集中型アプローチが問題になることがあります。そのため、データを生成する端末上でデータ分析や機械学習を実行しつつ、学習した内容を集約できれば、それに越したことはありません。


TensorFlow Federated（TFF）は、分散データに対して機械学習を含めた計算を行わせるための実験的オープンソース フレームワークです。TFF は、フェデレーション ラーニング（FL）と呼ばれるアプローチを使います。これは、参加している多数のクライアントが、データをローカルに保持しつつ共通の ML モデルをトレーニングできるようにする技術です。Google は、フェデレーション ラーニング技術を開発し、モバイル端末でのキーボード入力の予測や端末内検索用の ML モデルに活用しています。TFF はそこで得た経験に基づいて設計されています。TFF によって、すべての TensorFlow ユーザーが、ローカルで分散コンピューティングをシミュレーションする柔軟でオープンなフレームワークを利用できるようになります。

広く知られているイメージ データセットである MNIST を例に、FL と TFF の使い方を説明しましょう。MNIST の元になった NIST データセットには、3,600 人のボランティアによる 81 万の手書きの数字のイメージが含まれています。ここでの目的は、この数字を認識する ML モデルを作ることです。従来型の手法では、データセット全体に対して一気に ML アルゴリズムを適用します。しかし、すべてのデータを 1 か所にまとめることが できない 場合はどうなるでしょうか。たとえば、ボランティアが同意しないため、未加工のデータをセンター サーバーにアップロードできない場合などです。


TFF を使うと、任意の ML モデル アーキテクチャを記述し、各ボランティアのデータを個別にローカルに置いたまま、すべてのデータを使ってそのモデルをトレーニングできます。以下のコードは、TFF の Federated Learning（FL）API を使ってこれを実現する方法を示しています。ここでは、Leaf プロジェクトで処理し、数字をそれぞれのボランティア単位に分割した NIST データセットを使っています。



コードの続きは、フェデレーションによる MNIST 分類チュートリアルをご覧ください。
TFF には、FL API だけでなく、一連の低レベル プリミティブも含まれています。これは、Federated Core（FC）APIと呼ばれています。この API を使うと、分散データセットを扱うさまざまな計算を記述できます。フェデレーション ラーニングによる ML モデルのトレーニングは、フェデレーション計算の一例です。別の例として、分散データに対して ML モデルを評価することがあげられます。


FC API の簡単な例を見てみましょう。温度を測るたくさんのセンサーがあり、それぞれのデータをセンター サーバーにアップロードせずに各センサーの平均温度を計算することを考えてみます。FC API を使うと、ベースとなるデータ（tf.float32）とそのデータが存在する場所（分散クライアント）を指定して、新しいデータ型を記述することができます。

そのうえで、その型に対して、フェデレーション平均関数を指定します。



フェデレーション計算が定義されると、TFF はそれを分散構成で実行できる形式で表現します。TFF の最初のリリースには、ローカルマシン ランタイムとセントラル コーディネータが含まれています。ローカルマシン ランタイムは、各クライアントがローカルでの寄与値を計算するためのもので、データを保持するクライアント全体に対して実行される計算をシミュレーションします。セントラル コーディネータは、すべての寄与値を集約します。しかし、デベロッパーは、フェデレーション計算を入力と出力が異なる場所にある通常の関数と見ることもできます（入力は個々のクライアント、出力はコーディネータ サービス）。

TFF の宣言型モデルを使うと、フェデレーション平均アルゴリズムの亜種を簡単に記述することができます。


TensorFlow Federated は、さらに多くの人がテクノロジーを使えるようにするための 1 歩です。また、オープンかつ柔軟なプラットフォーム上で、コミュニティを巻き込んでフェデレーション ラーニングの研究を進めるための 1 歩でもあります。チュートリアルをご覧いただくと、ブラウザを使ってわずか数クリックで TFF を試してみることができます。ご自分のモデルで既存の FL アルゴリズムを実験したり、新しいフェデレーション データセットやモデルを作成してTFF リポジトリに提供したり、新しい FL アルゴリズムを実装したり、既存の FL アルゴリズムを拡張して新機能を追加するなど、さまざまな方法で貢献することもできます。


将来的には、主要な端末プラットフォームで TFF ランタイムを利用できるようにしたいと考えています。また、フェデレーション ラーニング用の差分プライバシー（TensorFlow Privacyとの統合）や Secure Aggregation など、プライベートなユーザーデータを守るための他のテクノロジーとの統合も考えています。すべてのデベロッパーがフェデレーション技術を使えるよう、コミュニティの皆さんと一丸となって TFF を開発できることがとても楽しみです。


試してみたい方は、https://www.tensorflow.org/federated/ にアクセスし、早速 TFF を使ってみてください！


謝辞
TensorFlow Federated は、チームの協力によって作成されています。多大な貢献を果たしてくださった、Brendan McMahan、Keith Rush、Michael Reneer、Zachary Garrett の皆さんに感謝いたします。


Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

この記事は Carey RadebaughとUlfar Erlingssonによる TensorFlow - Medium の記事 "Introducing TensorFlow Privacy: Learning with Differential Privacy for Training Data" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


投稿者: Carey Radebaugh （プロダクト マネージャー）、 Ulfar Erlingsson （リサーチ サイエンティスト）


本日は、TensorFlow Privacy（GitHub）についてご紹介します。オープンソース ライブラリである TensorFlow Privacy は、デベロッパーがプライバシーに配慮した機械学習モデルを簡単にトレーニングできるようにします。それだけでなく、研究者は TensorFlow Privacy を使って強いプライバシーを保証し、機械学習の水準を高めることができます。


最新の機械学習は、驚くような新技術やユーザー エクスペリエンスを実現するために使われることが増えてきました。その大半は、トレーニングの際に、個人の写真や電子メールといったプライベートなデータから学習しています。トレーニングが完了したとき、機械学習モデルのパラメータには、特定のトレーニング サンプルにまつわる事実ではなく、汎用的なパターンがエンコードされるのが理想です。これを確実に実現しつつ、プライベートなトレーニング データを扱う際に強いプライバシー保証を提供するために、差分プライバシーという理論に基づいた技術を使うことができます。特に、ユーザーのデータを使ってトレーニングを行う場合は、こういった技術によって、モデルが特定のユーザーに関する詳細を学習せず記憶しないという強い数学的保証を提供できます。ディープ ラーニングでは、しきい値やデータ消去などの確立された技術や、TensorFlow Federated による学習などの新しい技術など、他のプライバシー技術による保護と合わせてこの技術を使うことで、さらに保護を強化することができます。

Google は何年にもわたり、差分プライバシーの基礎研究と、最新の機械学習アプリケーション（こちらやこちら、またはこちらの研究論文をご覧ください）を見据えた実用的な差分プライバシー メカニズムの開発（こちらやこちらの例をご覧ください）の両面において、先頭を走り続けています。昨年は、責任ある AI の実践を公開し、責任ある機械学習システムおよびプロダクトを開発するために推奨すべきことを細かくまとめました。また、これが一般公開される前から、外部デベロッパーがこういった実践内容を自分のプロダクトに適用しやすくするための努力も続けています。


この努力が結んだ実の 1 つが、本日お知らせする TensorFlow Privacy と、そのプライバシー メカニズムを詳細に説明したテクニカル ホワイトペーパーの更新版です。
TensorFlow Privacy は、プライバシーの専門家でなく基礎となる数学的知識を使うことができます。標準の TensorFlow メカニズムを使っている方は、モデルのアーキテクチャやトレーニング手続き、処理を変える必要はありません。多くの場合、少しばかりコードを変更し、プライバシーに関係するハイパーパラメータを調整するだけで、トレーニング データのプライバシーを保護するモデルをトレーニングできます。

例: プライバシーを守りつつ言葉を学習する

差分プライバシーを使ったトレーニングの具体的な例として、テキスト列を使って文字レベルの再帰型言語モデルをトレーニングする場合を考えてみましょう。ディープ ラーニングのタスクには、ニューラル ネットワークを使った言語のモデリングが欠かせません。この手法は数え切れないほどのアプリケーションで使われており、その多くはプライベートなデータでトレーニングを行っています。ここでは、同じモデル アーキテクチャと TensorFlow Privacy GitHub リポジトリのサンプル コードを使い、2 つのモデルをトレーニングします。1 つは標準的な手法を、もう 1 つは差分プライバシーを利用します。


どちらのモデルも、標準の Penn Treebank トレーニング データセットにある金融ニュース記事の英語をうまくモデリングできます。しかし、モデルが言葉の分布に関して欠かすことのできない重要な側面を見逃してしまい、その結果 2 つのモデルに微妙な違いが生じたとすれば、差分プライバシー モデルの有用性に疑問が生じます（一方で、トレーニング データのあまりにも些細で細かい特徴をとらえることができなかったとしても、プライベートなモデルの有用性はさほど損なわれないでしょう）。


プライベートなモデルの有用性を確認するため、トレーニング データとテストデータのコーパスに対して 2 つのモデルを実行し、それぞれが許容する文、許容しない文を調べてみましょう。共通の特徴を確認するため、モデリングした文の共通性を計測することで、両方のモデルが同じ重要な言葉を許容するかどうかを調べてみます。この事例では、両方のモデルがトレーニング データの 98% 以上を許容し、高いスコアを出しました（つまり、パープレキシティが低い）。たとえば、次の金融ニュースに対しては、どちらのモデルも高いスコアを出しています。（これは明らかに学習したい分布の中に含まれるので、斜体で記述しています。）

there was little turnover and nothing to stimulate the market

south korea and japan continue to be profitable

merchant banks were stronger across the board

2 つのモデルの違いを確認するために、トレーニング データのうち、スコアが大きく違っている文を調べてみましょう。たとえば、トレーニング データにある次の 3 つの文は、通常の言語モデルではスコアが高く、許容されています。こういった文は、通常のトレーニングの中で記憶されてしまったからです。しかし、差分プライバシー モデルでは、これらの文のスコアはとても低く、許容されていません。（以下の文は、学習したい言葉の分布の外にあるので太字にしています。）

aer banknote berlitz calloway … ssangyong swapo wachter

the naczelnik stands too

my god and i know i am correct and innocent

上の文は、いずれも金融ニュースでは見かけないような内容です。プライバシー保護の観点で見れば、プライベートなものであると考えられます。たとえば、プライベートなデータでトレーニングを行ったモデルでは、このような珍しい文から個人の情報が特定されたり明かされてしまうかもしれません。この 3 つの文のうち最初の文は、でたらめに単語を並べた長文です。これは、技術的な理由でトレーニング データに含められています。2 つ目の文は、一部がポーランド語になっています。3 つ目の文は、自然な英語に見えますが、モデリング対象の金融ニュースの言葉ではありません。以上の例は手作業で選んだものですが、細かく調べていけば、差分プライバシー モデルが許容しないトレーニング データの文は、一般的に金融ニュース記事における通常の言葉の分布の外にあることが確認できます。さらにテストデータを評価すれば、プライベートなモデルとプライベートでないモデルとの質の損失（パープレキシティが 1.13 と 1.19）の原因は、こういったおかしな文であることが確認できます。そのため、名目上のパープレキシティ損失は 6% ほどになっていますが、関心対象の文に対するプライベート モデルのパフォーマンスが落ちる可能性はほとんどありません。


この 2 つのモデルの違いは、明らかにプライベートなモデルがトレーニング データの異質で珍しい文を記憶していない点にあります（少なくとも、違いの一部はこの点にあります）。この効果は、私たちの以前の成果を使って定量化できます。これは、ニューラル ネットワークの意図しない記憶化を計測するもので、意図的にトレーニング データにでたらめな ダミー の文を挿入し、トレーニングを終えたモデルでそのダミーデータの影響を評価することよって実現しています。今回の例では、1 つのでたらめなダミーの文を挿入するだけで十分です。プライベートでないモデルは、そのダミーデータを完全に記憶してしまったからです。一方、差分プライバシーでトレーニングしたモデルは、1 つのダミーデータを挿入しても、それを見分けることはありません。プライバシー モデルは、トレーニング データに同じでたらめな文字列が何度も何度も登場した場合のみ、それを学習します。この点は、あらゆる種類の機械学習モデルに当てはまります（例: 上の MNIST トレーニング データの珍しい数字のサンプルをご覧ください）。モデルのプライバシーに対する数学的に正式な上限がはるかに大きく、理論上何の保証も提供できない場合でも、この点が当てはまることに代わりはありません。

TensorFlow Privacy は、珍しいデータが細かく記憶されるのを防ぐことができます。また、上の図に示すように、2 つの機械学習モデルで、あるサンプル（例: 何らかのユーザーデータ）を使ってトレーニングを行ったかどうかを見分けることはできなくなります。

次のステップと参考文献

GitHub リポジトリからサンプルとチュートリアルをチェックアウトすると、TensorFlow Privacy を使ってみることができます。ここには、MNIST ベンチマーク機械学習タスクで差分プライバシー トレーニングを行う方法についての詳しいチュートリアルが含まれています。従来型の TensorFlow のメカニズム用のチュートリアルと合わせて、TensorFlow 2.0 と Keras を使った新しい eager モードによるチュートリアルも掲載されています。


TensorFlow Privacy を使う場合、重要ないくつかの新しい手順が必要になります。具体的には、勾配を作成し、切り詰め、ノイズ化する方法を制御する 3 つのハイパーパラメータを新しく設定します。トレーニングでは、変更を加えた確率的勾配降下法を使ってモデルを最適化することで、差分プライバシーが確保されます。実際には、トレーニング データのサンプルに起因する複数の勾配の更新を平均化し、それぞれの勾配の更新を特定の最大値ノルムまで切り詰め、最終的な平均値にランダムなガウスのノイズを追加します。この学習方法では、各トレーニング データのサンプルの効果に上限値が設けられることになります。さらに、ノイズを追加することで、どのサンプルもそれ 1 つだけで影響を与えることがなくなります。この 3 つのハイパーパラメータの設定には、職人技が求められるかもしれません。しかし、TensorFlow Privacy リポジトリには、具体的な例に対してどのように値を選択できるかを示したガイドラインも含まれています。


TensorFlow Privacy は、強いプライバシーを保証する機械学習モデルをトレーニングするために、最善の技術のハブとなることを目指して開発されています。関係する皆さんは、ぜひ以下のような形でご参加ください。

• 差分プライバシーと機械学習への応用について、こちらまたはこちらのブログ記事をお読みください。
• 専門家の皆さんは、TensorFlow Privacy を自分の機械学習モデルに適用し、ハイパーパラメータ、モデルの能力やアーキテクチャ、活性化関数などを調整して、プライバシーと実用性のバランスについて実験してみてください。
• 研究者の皆さんは、モデルのパラメータ選択などについてさらに分析を進め、強いプライバシーを保証して現実世界の機械学習の水準を上げることに挑戦してください。
• プルリクエストを送信して、TensorFlow Privacy に貢献してください。
• GitHub の Issue で質問をしたり、コメントや懸念事項を共有してください。

謝辞

TensorFlow Privacy に貢献してくださった Galen Andrew、Nicholas Carlini、Steve Chien、Brendan McMahan、Ilya Mironov、Nicolas Papernot の皆さんに感謝を捧げます。


Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

この記事は Android セキュリティ & プライバシー チーム、Paul Crowley、Eric Biggers による Google Online Security Blog の記事 "Introducing Adiantum: Encryption for the Next Billion Users" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


ストレージを暗号化しておけば、スマートフォンが誰かの手に渡ったとしても、データを守ることができます。Adiantum は、暗号化におけるイノベーションです。暗号化アクセラレーション機能を搭載していない端末でも効率的にストレージを暗号化できるように設計されており、 あらゆる 端末を暗号化できます。


現在の Android では、Advanced Encryption Standard（AES）によるストレージ暗号化が提供されています。新しい Android 端末のほとんどは、ARMv8 Cryptography Extensions による AES 暗号化がハードウェアでサポートされています。しかし、Android はさまざまな端末で実行されています。最新のフラッグシップ スマートフォンやミッドレンジ スマートフォンだけでなく、主に発展途上国で販売されているエントリーレベルの Android Go スマートフォンや、スマートウォッチ、スマート TV などもあります。安価な選択肢を提供するため、端末メーカーがローエンド プロセッサを使うこともあります。たとえば、AES をハードウェアでサポートしていない ARM Cortex-A7 などです。こういった端末では、AES は遅すぎるため、アプリの起動に時間がかかる、端末全般の動作が遅くなるなど、ユーザー エクスペリエンスの低下につながります。そのため、ストレージ暗号化は 2015 年に Android 6.0 以降のほとんどの端末で必須となっているものの、AES パフォーマンスが低い（50 MiB/s 以下の）端末はこの要件が免除されています。私たちは、暗号化は誰でも使えるべきだと考えているため、この点に対応する作業を進めてきました。


HTTPS 暗号化では、この問題は解消されています。ハードウェア アクセラレーションが利用できない場合、ChaCha20 ストリーム暗号化は AES よりもはるかに高速です。一方で、この暗号化はきわめて安全です。高速さの秘訣は、あらゆる CPU がネイティブでサポートしている演算のみ（加算、循環、XOR）を使っている点にあります。そのため Google は、HTTPS インターネット接続を保護するための新しい TLS 暗号スイートとして、2014 年に ChaCha20 と、同じくソフトウェアで高速に処理できる Poly1305 認証を選択しました。ChaCha20-Poly1305 は RFC7539 として標準化されており、AES 命令が搭載されていない端末の HTTPS パフォーマンスを大きく向上させています。


ただし、ディスクとファイルの暗号化には、固有の問題があります。ストレージ デバイス上にあるデータは、「セクタ」に分割されています。現在のセクタの一般的なサイズは、4096 バイトです。ファイルシステムがデバイスにセクタの読み込みまたは書き込みのリクエストを行うと、暗号化レイヤーがそのリクエストをインターセプトし、プレーンテキストと暗号テキストの変換処理を行います。つまり、4096 バイトのプレーンテキストと 4096 バイトの暗号テキストを相互に変換しなければなりません。しかし、RFC7539 を使うと、暗号テキストはプレーンテキストよりもわずかに大きくなります。暗号の nonce とメッセージの整合性情報を格納するために、わずかな領域が必要になるからです。この追加情報を格納する場所をソフトウェアで探すテクニックも存在しますが、効率が落ち、ファイルシステムの設計も大幅に複雑化する可能性があります。


AES でディスクを暗号化する際によく使われるソリューションは、サイズが変わらない XTS モードまたは CBC-ESSIV モードを利用する方式です。現在の Android は、ディスク全体の暗号化には AES-128-CBC-ESSIV を、ファイルベースの暗号化には AES-256-XTS を利用しています。しかし、AES のパフォーマンスが不十分な場合は、ローエンド ARM プロセッサでも十分なパフォーマンスを出せる代替方式として広く普及しているものはありません。


この問題を解決するために、Adiantum という新しい暗号化モードを設計しました。Adiantum を使うと、サイズを変えないモードで ChaCha ストリーム暗号を使えるようになります。これは、HCTR や HCH など、サイズを変えない AES ベースの暗号化として提案されている方式の考え方を取り入れることによって実現しています。ARM Cortex-A7 は、4096 バイトのセクタに対する Adiantum による暗号化と復号化を、1 バイト当たり約 10.6 サイクルで実行できます。これは、AES-256-XTS より約 5 倍高速です。
Adiantum は、XTS や CBC-ESSIV などのモードとは異なり、真のワイドブロック モードを実現しています。つまり、プレーンテキスト内のどのビットを変更しても、暗号テキストのすべてが変更され、判別できなくなります。その逆も同じことが言えます。動作の仕組みは、以下のようになっています。最初に、Poly1305 および別の非常に高速な鍵つきハッシュ関数である NH に基づく鍵つきハッシュ化によって、プレーンテキストのほぼ全体をハッシュ化します。また、「tweak」と呼ばれる値もハッシュ化します。これは、セクタごとに異なる暗号化を行うようにするためのものです。次に、このハッシュを使い、ChaCha 暗号化に使う nonce を生成します。復号化でも暗号化と同じ強度を実現できるように、暗号化の後、再度ハッシュ化を行います。この処理は、暗号化したものを復号化できるように、ファイステル ネットワークという形で構造化されています。16 バイトのブロックに対して AES-256 を 1 回実行する必要もありますが、4096 バイトの入力に比べれば、パフォーマンス的に大きな影響はありません。
ChaCha のような暗号プリミティブは、「ラウンド」として扱われています。このラウンドを繰り返すたびに、スピードと引き替えに安全性が高まります。多種多様な端末で十分高速にディスクを暗号化できるように、一般的に使われている 20 ラウンドの ChaCha ではなく、12 ラウンドの方式を選択しています。ラウンドを繰り返すたびに、攻撃の難易度は大幅に上がります。7 ラウンドの方式は 2008 年に破られており、多くの論文も発表されて攻撃方法も向上していますが、8 ラウンドを破ることができる攻撃方法は今のところ見つかっていません。実は、繰り返すラウンド数と現在破られているラウンド数の比率で見れば、AES-256 よりも ChaCha12 の方が優れています。


Adiantum はまだ生まれたばかりですが、私たちはその安全性に強い自信を持てる立場にあります。私たちの論文では、ChaCha12 と AES-256 が安全であるという前提のもと、Adiantum が優れたセキュリティ特性を持つことを証明しています。ChaCha や AES のような「プリミティブ」から XTS、GCM、Adiantum などの「構造」を作るというのは、暗号の世界では標準的な技法です。プリミティブが安全であるかどうかについては、私たちが説得力のある主張を行えることは多いものの、その証拠を提供することはできません。ただし、プリミティブが安全であれば、そこから作った構造も安全であることは証明できます。NH および Poly1305 ハッシュ関数については、前提とする必要はありません。必要な暗号特性（"ε-almost-∆-universality"）を持っていることが証明されているからです。
Adiantum は、ホウライシダという植物にちなんで名付けられました。ヴィクトリア時代の花言葉では、誠実さと慎みを表す植物とされています。

参考資料

設計の詳細、安全性の証明については、論文 Adiantum: length-preserving encryption for entry-level processors をご覧ください。IACR Transactions on Symmetric Cryptology に掲載されています。この論文は、3 月の Fast Software Encryption カンファレンス（FSE 2019）で発表される予定です。
Adiantum の一般的な実装および ARM に最適化された実装は、Android 共通カーネル v4.9 以降およびメインライン Linux カーネル v5.0 以降で利用できます。リファレンス コード、テストベクトル、ベンチマーク スイートは、https://github.com/google/adiantum で公開されています。
Android 端末メーカーは、AES のパフォーマンスが 50 MiB/秒以下かつ Android Pie を搭載する端末で、ディスク全体またはファイルベースの暗号化に Adiantum を利用することができます。AES がハードウェアでサポートされている場合は、Adiantum よりも AES の方が高速です。AES のパフォーマンスが 50 MiB/s を超える場合は、AES の使用が必須である点は変わりません。Android Q では、Adiantum が Android プラットフォームの一部となる予定です。今後、すべての新しい Android 端末で、許可されているいずれかの暗号化アルゴリズムを使った暗号化が必須となるように、Android Compatibility Definition Document（CDD）を更新する予定です。


謝辞: 本投稿は、Greg Kaiser および Luke Haviland による寄稿に基づいています。Adiantum は、Paul Crowley と Eric Biggers が設計し、Eric Biggers と Greg Kaiser が Android に実装しました。命名は、Danielle Roberts によって行われました。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は デベロッパープログラムマネージャー、Ibrahim Ulukaya による The Firebase Blog の記事 "See how ML Kit and ARKit play together" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



Posted by Hak Matsuda - Developer Relations Team

この記事は Steve Ganemによる The Firebase Blog の記事 "Dynamic audiences in Google Analytics for Firebase" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

元の記事は、Google マーケティング プラットフォーム ブログに投稿されました。

企業がマーケティング予算の最善の投資先を判断するときに決め手となるのが、ウェブとアプリという両方の場所でユーザーの行動を把握することです。多くの場合、ユーザーが最初に触れるのはウェブサイトですが、ほとんどの企業では、ユーザーがより多くの時間を費やすのはアプリでしょう。そのためマーケティング担当者は、アプリ解析によってユーザーに関する洞察を得たうえで、アプリの内部と外部の両方で対策をとる必要があります。
かねてより、私たちのアプリ解析ソリューションである Firebase 向け Google アナリティクスは、イベント、端末の種類などの項目からユーザーリストを作成する機能を提供してきました。しかし、ユーザーの行動は時間とともに変化するので、これらの基準は網羅的ではなく、動的でもありませんでした。
そこで、いくつかの大きなアップデートを行い、ユーザーリストの作成機能を改善しました。これにより、対象となるアプリのユーザーリストを簡単かつ精度よく特定できるようになります。

1. ユーザーリストの動的評価: ユーザーリストは、デフォルトで動的になります。つまり、アナリティクスが即座に基準を満たすユーザーを自動的に追加し、満たさなくなったユーザーを自動的に削除します。リストを設定しておけば何もしなくてもユーザーが加わるので、手間をかけて定期的に再評価を行う必要はなくなります。
2. ユーザーリストからの除外: 除外基準を追加すると、ユーザーリストの精度をさらに高めることができます。たとえば、ショッピング カートに品物を追加した人のうち、購入した人を除外したユーザーのリストを作成することができます。
3. 有効期間: 「直近 30 日間にコンバージョンしたユーザー」というように、ユーザーリストに有効期間も追加できるようになりました。そのため、ユーザーリストやメッセージングを常に最新かつタイムリーに保つことができます。

以上の新しいツールによって、ユーザーリストは今までよりもさらに強力で柔軟、かつ行動につながるものになり、皆さんの分析をアプリのユーザーやその活動に確実に反映できるようになります。私たちは、2019 年も Firebase 向け Google アナリティクスのユーザーリスト作成機能の改善を続け、さらに精度を上げたユーザーリストを作成する方法を提供したいと考えています。

対象のユーザーリストが特定できたら、早速行動を
ユーザーについての理解が深まったら、変化するニーズに応じてユーザーの好みにあった体験を提供することもできます。たとえば、プッシュ通知や Firebase の Remote Config、Google 広告のカスタマイズ広告などが利用できます。

例として、e コマースアプリについて考えてみましょう。前述の高度なユーザーリスト機能を使うと、初めてアプリを使って カートに品物を追加したにもかかわらず、購入はしなかったユーザーのリストを作成することができます。さらに、30 日間でそのような行動をとったユーザーだけを含めることもできます。

このユーザーリストを使うと、アプリで行った操作にぴったりのメッセージを使ってアプローチし、アプリ内宣伝やメール通知、パーソナライズド広告を通して購入を呼びかけることができます。ユーザーがアプリに戻ってきて購入を行ったり、30 日間の期限を過ぎたりすると、ユーザーリストの基準を満たさなくなるため、対象外のマーケティングを実施してユーザー エクスペリエンスに悪影響を及ぼすことはなくなります。

動的ユーザーリストを作成できる機能を活用すれば、ユーザーを今まで以上に精度よく把握できます。ユーザーリストの精度が向上すれば、ユーザーの道のりがよくわかるようになり、自信をもってマーケティング活動に投資できて、よい結果が生まれます。ユーザーに満足してもらうことで、皆さんのアプリも拡大します。

Reviewed by Khanh LeViet - Developer Relations Team

この記事はNadine Sundquistによる Google Ads Developer Blog の記事 "Configure Account-level Call Reporting" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。




Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 73 Beta: Constructable stylesheets, a new RegExp function, and passive mouse events" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Chrome 73 はすでに安定版として公開されています。本記事は Chrome 73 がベータ公開された時点の内容です。

コンストラクタブル スタイルシート

動的なスタイルシートの作成は、<style> 要素の sheet プロパティに直接アタッチすることで、かなり前から実現できました。この手法には、スタイル設定前のコンテンツが一瞬表示される、CSS ルールの重複による肥大化が起きる場合があるなどの問題があります。CSSStyleSheet インターフェースの新しいメソッドを使うと、プログラムからスタイルシートを追加し、従来の手法の問題を解消できます。

コンストラクタブル スタイルシートを利用すると、共有 CSS スタイルを定義し、それを複数の shadow root またはドキュメント オブジェクトに適用できます。この操作を、アドプト（採用）と呼びます。共有スタイルシートを変更すると、それをアドプトしているすべての要素に適用されます。スタイルシートのアドプトは高速です。コンストラクタブル スタイルシートは、さまざまな事例で活用できます。たとえば、コンポーネントをまたいでテーマを共有する、DOM へのインジェクションを行わずにスタイルシートをプリロードする、などが考えられます。

新しい API を使わなくても、replace() メソッドや replaceSync() メソッドを使って命令的にスタイルシートを作成できます。次に例を示します。

const sheet = new CSSStyleSheet();

// replace all styles synchronously:
sheet.replaceSync('a { color: red; }');

// replace all styles, allowing external resources:
sheet.replace('@import url("styles.css")')
    .then(sheet => {
        console.log('Styles loaded successfully');
    })
    .catch(err => {
        console.error('Failed to load:', err);
    });

詳細については、こちらの記事またはサンプルをご覧ください。

String.prototype.matchAll()

String.prototype に、正規表現マッチングを行う新しいメソッドが追加されます。matchAll() 関数を使うと、String.prototype.match() よりも厳密にマッチングできます。この新しい関数について理解するために、まずは次の正規表現コードについて考えてみましょう。

const regex = /t(e)(st(\d?))/g;
const string = 'test1test2';

string.match(regex) を呼び出すと、完全一致のみを含む配列が返されます。この例では、'test1' と 'test2' になります。では、グループのキャプチャはどうなるでしょうか。g フラグを削除すれば、'test1' を対象とした最初のグループを取得することはできます。しかし、残りのグループを取得するには追加のコードを書かなければなりません。それは避けたいところです。

仕様策定者も同じ結論に至ったため、matchAll() が生まれることになり、それが今回 Chrome で実装されています。matchAll() は、前述のような一部の結果のみを返すのではなく、反復処理可能なオブジェクトを返します。また、いくつかの便利なプロパティも含まれています。

このメソッドの詳細については、developers.google.com の記事をご覧ください。Chrome の JavaScript の新機能については、v8.dev をご覧ください。

Passive Mousewheel リスナー

ユーザー エンゲージメントにとって、スクロールの反応は非常に重要です。そのため、Chrome のスクロール処理では、イベントの動作を通じた改善が続けられています。イベント リスナーのベスト プラクティスに、preventDefault() を呼び出さないリスナーは passive として登録する必要がある（addEVentListener() に {passive: true} を渡す）というものがあります。passive でないイベントでは、ブロッキングが発生します。preventDefault() が呼び出された場合、ブラウザはその処理を待たなければならないからです。

不要なブロッキングを行うイベント リスナーはよくあります。そのため、Chrome 56 では、ルート ターゲットに登録された touchstart と touchmove がデフォルトで passive になるように変更しました。これにより、リスナーでブロッキングが起きなくなり、ブラウザは安全にスクロールやズームを実行できるようになります。Chrome 73 以降では、wheel イベント リスナーおよび mousewheel イベント リスナーも同じ動作となります。つまり、次のコードは等価になります。

window.addEventListener("wheel", func);
window.addEventListener("wheel", func, {passive: true} );

変更に関する背景や統計値については、Making wheel scrolling fast by defaultをご覧ください。

Cross-Origin resource policy

Cross-Origin-Resource-Policy レスポンス ヘッダーを使用すると、http サーバーは、返すリソースがクロスオリジンまたはクロスサイトで埋め込まれないようにブラウザに依頼することができます。これは、Cross-Origin Read Blocking（CORB）機能の補助機能で、CORB の対象にならないリソースの保護に特に便利です（CORB で保護できるのは、HTML、XML、JSON のみです）。

現在、Cross-Origin-Resource-Policy は、Spectre 攻撃や侵害されたレンダラーからイメージを守ることができる唯一の方法です。
CSS リダイレクトはクロスオリジン

仕様に準拠するため、（a）ネットワーク エラーにより読み込みに失敗したスタイルシート、（b）クロスオリジンから同じオリジンにリダイレクトされて戻ってきた後に読み込まれたスタイルシートは、クロスオリジンと見なされます。

WebContents が覆い隠されている場合、document.visibilityState を “hidden” に設定

Chromium の WebContents Occlusion 機能のおかげで、Page Visibility API がウェブページの表示状態を厳密に反映するようになります。ページが覆い隠されている場合も同様です。具体的には、ブラウザのタブやウィンドウが 1 つまたは複数のウィンドウに覆われている場合、document.visibilityState の値が “hidden” になります。

現時点で WebContents Occlusion 機能がサポートされているのは、Chrome OS と macOS のみです。Windows のサポートは、現在対応中です。

DOMMatrixReadOnly.scaleNonUniform()

scaleNonUniform() 関数は、現在の行列に対して右側から非均一スケール変換を乗算し、結果の行列を返します。従来の SVGMatrix との互換性を維持するため、再加算が行われています。非均一スケーリングとは、少なくとも 1 つのスケーリング要素が他と異なる変換を指します。非均一スケーリングを使うと、たとえば長方形を正方形や平行四辺形に変換できます。

EME 拡張: HDCP ポリシー チェック

アプリケーションは、最適なユーザー エクスペリエンスを実現する解像度で再生できるように、特定の HDCP ポリシーの強制が可能かを問い合わせることができるようになります。試してみたいデベロッパーの皆さんのために、サンプルが公開されています。

GamePad API: GamepadButton の touched 属性

GamePad API からゲームパッド ボタンの touched 状態を取得できるようになりました。これは、ボタンが押されているかどうかとは別に、指がボタンの上にあるかどうかを示す属性です。

link rel=preload の imagesrcset 属性と imagesizes 属性

<link> 要素が imagesrcset プロパティと imagesizes プロパティをサポートするようになりました。これらは、HTMLImageElement の srcset 属性と sizes 属性に対応するものです。  この機能を使う場合は、<link> 要素に preload キーワードと image キーワードを含める必要があります。次に例を示します。

<link rel="preload" as="image" href="pic400.jpg" imagesizes="100vw"
imagesrcset="pic400.jpg 400w, pic800.jpg 800w, pic1600.jpg 1600w">

暗黙的なルート スクローラー

暗黙的なルート スクローラーを使うと、ビューポートを占めているスクローラー（iframe や div）でドキュメントレベルのスクロール（URL バーの表示や非表示、オーバースクロール時のグロー、回転の防止など）ができるようになります。この機能には API はないので、標準化の過程には含まれません。Chrome は、ページが主に非ドキュメント スクローラーに含まれているかどうかを判断して、ドキュメント スクロール UX をスクローラーに委譲しようと試みます。

これは、以前に提案された rootScrollers API の暗黙版です。

Shadow host の ::part 疑似要素

Chrome の shadow host で ::part() 疑似要素がサポートされました。これにより、shadow host が shadow tree の一部の要素をページの外側に公開して、スタイルの設定に利用できるようになります。

PerformanceObserver.supportedEntryTypes

PerformanceObserver.supportedEntryTypes を使うと、ウェブブラウザで実装されている PerformanceEntry のタイプの特徴を検出できます。たとえば、Chrome でこれを使用すると、次のような内容をコンソールに表示できます。

["longtask", "mark", "measure", "navigation", "paint", "resource"]

WebRTC のアップデート

RTCConfiguration.offerExtmapAllowMixed

RTCConfiguration.offerExtmapAllowMixed() に Boolean 型プロパティが追加され、セッション記述プロトコル（SDP）のオファーにおいて extmap-allow-mixed 属性を有効にできるようになります。

SDP の extmap-allow-mixed 属性は RFC8285 で定義されており、このプロパティを true に設定すると、この属性が SDP オファーに含まれるようになります。SDP の extmap-allow-mixed 属性は Chrome 71 以降でサポートされますが、下位互換性の問題から、この属性はデフォルトで SDP オファーに含まれていませんでした。

このプロパティは、純粋に暫定的なものです。最初はデフォルトでオフになる予定ですが、クライアントによるコードの更新が十分に達成されたら、デフォルトでオンになるように変更したいと考えています。やがて下位互換性が必要なくなり、これを完全に削除できるようになることを期待しています。

RTCRtpReceiver.getParameters()

新しく追加された RTCRtpReceiver.getParameters() メソッドは、RTCRtpReceiver オブジェクトのトラック デコーディング パラメータを返します。これには、通話のネゴシエーションに使われるコーデックや RTP ヘッダーリスト、RTCP 情報、レイヤー数が含まれています。

このメソッドは、RTCRtpSender.getParameters() に似ており、同じような通話情報を提供しますが、対象は受信側になります。通話のパラメータを変えることはできません。

RTCRtpReceiver.getSynchronizationSources()

新しく追加された RTCRtpReceiver.getSynchronizationSources() メソッドは、音声および動画受信者の RTP パケットの直近の再生タイムスタンプを返します。これは、どのストリームがアクティブであるかをリアルタイムに判断する際に便利です。オーディオ メーターや、参加しているストリームのうちアクティブなものを優先して UI に表示したい場合などに利用できます。

RTCRtpContributingSource をインターフェースからディクショナリに変更

仕様では、RTCRtpContributingSource をディクショナリにすることが求められていますが、今まではインターフェースとなっていました。今回の変更で、RTCRtpContributingSource のプロトタイプはなくなり、getContributingSources() を呼び出すごとに新しいオブジェクトのセットが作られるようになります。

Atomics.wake() の名前が Atomics.notify() に変更

Atomics.wake() メソッドの名前が Atomics.notify() に変更されます。これは、Atomics.wait() で停止していた Worker を復帰させるための低レベル関数です。これは、wait と wake という名前が似ていることによる混乱を緩和するための仕様変更に準拠する措置です。

変換リスト補間

Chrome は、行列補間フォールバックが使われるケースを減らすために、CSS 変換処理の方法を改善してきました。補間とは、中間的な変換を行うことを指します。CSS ルールを解釈する際、補間を行うために行列へのフォールバックが必要になる場合があり、それによってウェブ デベロッパーの意図しない視覚効果が引き起こされる可能性があります。この問題を軽減するため、そのような発生状況を減らすように仕様が変更されました。

相互運用性の改善

シャドウのぼかしの半径が仕様に準拠

従来より、Blink では CSS 仕様と Canvas2D 仕様の両方でぼかしの半径の解釈が異なっており、Blink のシャドウは期待される範囲の約半分しか覆っていません。

今回の変更により、仕様で定められているとおり、ガウスのぼかしのシグマがぼかしの半径の 1/2 として計算されるようになります。現在の Blink のシャドウ実装は、FireFox および Safari と一致します。

URL フラグメント識別子のアイソモーフィック デコードの削除

Chrome でフラグメント ID のある URL を開くと、%xx がデコードされてアイソモーフィック デコードが適用され、その後、場合によってデコード結果の ID を持つ要素を探そうとします。たとえば、ユーザーが example.com/#%F8%C0 を開くと、Chrome は以下の処理を行います。

1. ページで id="%F8%C0" の要素を検索する
2. 見つからなかった場合、ページで id="øÀ" の要素を検索する

他のブラウザはこの処理を行っておらず、標準でも定義されていません。バージョン 73 以降では、Chrome もこの処理を実行しなくなります。

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

WebSQL での EXPLAIN および REINDEX のサポートの削除

EXPLAIN の出力は SQLite のバージョンをまたいで安定していることが保証されていないので、デベロッパーはこれを信頼することはできません。REINDEX が役立つのは照合順の定義が変わった場合のみですが、Chrome はビルトインの照合順しか使いません。これらの機能は、両方とも削除されています。

サンドボックス化された iframe での「ドライブバイ ダウンロード」のサポート終了

Chrome では、サンドボックス化された iframe でユーザーの操作なしに行われるダウンロード（「ドライブバイ ダウンロード」）が非推奨となっています。なお、この制限は、サンドボックス属性リストに allow-downloads-without-user-activation キーワードを含めることで解除することもできました。今回の変更により、コンテンツ プロバイダは悪意のあるダウンロードや不正なダウンロードを制限できます。

ダウンロードは、システムにセキュリティ脆弱性をもたらす場合があります。Chrome およびオペレーティング システムでは追加のセキュリティ チェックが行われますが、サンドボックス化された iframe でのダウンロードをブロックすることも、サンドボックスを支える一般的な考え方と一致するものと考えています。セキュリティの懸念は別としても、新しいページを開いたときに自動的にダウンロードが始まったり、クリック後に不自然にダウンロードが始まったりするよりは、同じページでクリックをトリガーとしてダウンロードする方が快適なユーザー エクスペリエンスとなるでしょう。

この機能の削除は、Chrome 74 で行われる予定です。

Reviewed by Eiji Kitamura - Developer Relations Team