この記事は Android プロダクト マネージャー、Edward Cunningham による Android Developers Blog の記事 "Improving app security and performance on Google Play for years to come" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Play は、毎年何十億ものアプリのインストールやアップデートを支えています。あらゆるユーザーが適切な体験を通してお気に入りのアプリやゲームを見つけてインストールできるように、私たちは妥協することなくセキュリティやパフォーマンスに注力しています。本日は、Android デベロッパーの皆さんに、この目的を達成するための 3 つの変更点についてお知らせします。また、各変更の理由と、長期的に見てこの変更が Android 端末の安全性とパフォーマンスの向上にどのように役立つのかについても説明します。

• 2018 年の後半より、Play では、新しいアプリやアプリのアップデートは最新の Android API レベルをターゲットに指定することが義務づけられます。これが必須となるのは、新規アプリは 2018 年 8 月、既存アプリのアップデートは 2018 年 11 月です。これによって、セキュリティとパフォーマンスが最適化された最新の API でアプリがビルドされることが保証されます。
  
• 2019 年 8 月に、Play ではネイティブ ライブラリを含む新しいアプリとアプリのアップデートは、32 ビット版に加えて 64 ビット版を提供することが義務づけられます。
  
• さらに、2018 年初めに、アプリが本物であることを確認するための小規模なセキュリティ メタデータを各 APK に追加する作業が始まります。この変更に対しては、特にアクションは必要ありません。

私たちは、デベロッパー エコシステムに深く感謝しており、この早い段階での事前予告が皆さんのアプリのリリースに役立つことを願っています。今後も、皆さんの準備をサポートするため、重要な日付が近づいてきた際にお知らせやデベロッパー リソースの共有を行ってまいります。

2018 年後半からのターゲット API レベル要件

API の動作の変更により、Android のセキュリティやプライバシー保護が強化されます。これは、デベロッパーがアプリを保護したり、ユーザーを不正なソフトウェアから守る上で役立ちます。最近バージョンのプラットフォームでは、次のような変更点があります。

• bindService() での暗黙的インテントのサポート終了（Android 5.0）
  
• 実行時パーミッション（Android 6.0）
  
• 保護された接続において、デフォルトでユーザーが追加した CA を信頼しない（Android 7.0）
  
• ユーザーが明示的に同意しないと、アプリはユーザー アカウントにアクセスできない（Android 8.0）

こういった変更の多くは、新しい API の動作をサポートすることを targetSdkVersion マニフェスト属性で明示的に宣言したアプリにのみ適用されます。たとえば、実行時パーミッションを通してアプリがアクセスできる個人情報（連絡先や位置情報など）をユーザーが完全に制御できるのは、targetSdkVersion が 23（Android 6.0 の API レベル）以降のアプリのみです。同様に、最新リリースには、アプリが意図せずに電池やメモリなどのリソースを使いすぎることを防ぐユーザー エクスペリエンスの改善も含まれています。バックグラウンド実行の制限は、この種の改善の代表的な例です。

ユーザーにできる限り最高の Android 体験を提供するため、Google Play Console のアプリのターゲットに最新の API レベルを指定することが義務づけられます。

• 2018 年 8 月: 新しいアプリで、ターゲット API レベル 26（Android 8.0）以降が必須になります。
  
• 2018 年 11 月: 既存のアプリのアップデートで、ターゲット API レベル 26 以降が必須になります。
  
• 2019 年以降: 毎年、targetSdkVersion の要件が上がります。Android の各デザート リリースの後 1 年以内に、新しいアプリとアプリのアップデートは、対応する API レベル以降にターゲットを指定することが義務づけられます。

この変更はアップデートを行っていない既存のアプリには影響しません。また、デベロッパーが任意の minSdkVersion を使用できる点は変わらないので、古いバージョンの Android 向けにアプリをビルドできる点も変わりません。デベロッパーの皆さんには、現実的に可能な範囲で下位互換性を提供することをお勧めします。今後のバージョンの Android でも、最新の API レベルをターゲットに指定しておらず、パフォーマンスやセキュリティに悪影響を及ぼすアプリは制限を受けることになります。私たちは、積極的にアプリのエコシステムにおける断片化を減らし、安全でパフォーマンスのよいアプリを確実に提供できるようにしたいと考えています。さらに、デベロッパーの皆さんが事前に計画を立てることができるように、早い段階から多くの通知を行う予定です。

今年は、今までの Android でもっとも安全でパフォーマンスのよい Android Oreo がリリースされました。また、最新リリースが早く端末に行き渡るように、Project Treble も導入されています。ぜひ本日より、Android 8.1 Oreo をターゲットにしたアプリの構築を始めてください。

2019 年の 64 ビットサポート要件

64 ビット アーキテクチャ プラットフォームのサポートは、Android 5.0 で導入されました。現在、オンラインに接続している 40% 以上の Android 端末で 64 ビットがサポートされていますが、32 ビットとの互換性はまだ維持されています。通常、ネイティブ ライブラリを利用するアプリでは、64 ビットのコードは追加のレジスタや新しい命令を使えるため、大幅にパフォーマンスが高くなります。

64 ビットのコードのみをサポートする今後の Android 端末に備えるため、Play Console における新しいアプリとアプリのアップデートは、32 ビットをサポートしていない端末でも実行できるようにすることが義務づけられます。32 ビット ライブラリを含むアプリは、64 ビット版のものも含める必要があります。これは、同じ APK の中に配置しても、公開している複数の APK の 1 つとしてでも構いません。ネイティブ コードを含まないアプリには影響ありません。

この変更は、2019 年 8 月から適用されます。まだ 64 ビットをサポートしていないデベロッパーが十分な時間を使って移行計画を立てられるように、本日事前予告を行っています。今後、Android での 64 ビット ネイティブ ライブラリのパフォーマンス上のメリットについて深く掘り下げた記事を投稿する予定なので、ぜひご注目ください。NDK についての詳細は、CPU とアーキテクチャ ガイドをご覧ください。

2018 年初頭のセキュリティ メタデータ

来年、Google Play によって公式に配布されていることを確認するための小規模なセキュリティ メタデータを各 APK に追加する作業が始まります。物理製品を購入すると、その製品が本物であることを証明する公式のラベルやバッジがついていることがあります。今回 APK に追加されるメタデータは、Android アプリが本物であることを証明する Play のバッジのようなものです。

デベロッパーやユーザーは、特にアクションを行う必要はありません。Play の最大 APK サイズは、この小さなメタデータの追加を考慮して調整されます。このデータは APK 署名ブロックに挿入されるので、アプリの機能が変わることはありません。このメタデータによって、Play のモバイルアプリのエコシステムの整合性が向上します。またデベロッパーにとっては今後新たな配布機会が得られ、アプリを最新に保つユーザーが増えることにもつながります。

今後の予定

2017 年は、Google Play で拡大や成功を成し遂げたデベロッパーにとってすばらしい年でした。私たちは、アプリの質やビジネスの業績の向上に役立てていただけるように、さまざまな機能（I/O 2017 や Playtime で発表された内容など）についての作業を懸命に行っています。こういった機能や今後のアップデートによって、2018 年以降も Android や Play のエコシステムが繁栄し続けることを願っています。

このブログ投稿はどのくらい役に立ちましたか？

★ ★ ★ ★ ★


Reviewed by Hak Matsuda - Developer Relations Team

この記事は デベロッパー アドボケート、Fred Chung による Android Developers Blog の記事 "Tuning your apps and games for long screen devices" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ここ数か月、端末メーカーが画面のアスペクト比が 16:9 よりも大きい端末を発売する傾向が高まっています。そういった端末の多くでは画面の角も丸くなっています。これは、Android エコシステムの広がりと豊富な選択肢を表すものです。Pixel 2 XL や Huawei Mate 10 Pro は、数ある例の 2 つに過ぎません。このような画面の特徴を活用すると、とても没入感のある体験をユーザーに提供できます。その一方で、ユーザーは、新しい端末にちゃんと対応していないアプリやゲームがあることにも気づいています。そのため、デベロッパーにとっては、こういった画面デザインに向けた最適化を行うことが重要になります。Android OS ではこれに関連するサポートが提供されていますので、ご紹介します。

アスペクト比が大きい画面に向けた最適化

標準 UI ウィジェットを使っているほとんどのアプリは、こういった端末でもそのまま動作します。Android のドキュメントには、複数の画面サイズでアプリを柔軟に動作させるためのテクニックが詳しく記述されています。しかし、カスタム UI を搭載した一部のゲームやアプリでは、アスペクト比についての不適切な前提が原因で問題が発生する場合があります。ここでは、デベロッパーがよく直面する一般的な問題を紹介しますので、皆さんに関連する問題に注意してください。

• 一部の画面の端が切れる。この場合、影響を受けるグラフィックや UI 要素が完全に表示されません。
• タップする場所と UI 要素（ボタンなど）がずれている。ユーザーは、操作できるように見える UI 要素に戸惑う可能性があります。
• 角が丸くなっている端末の全画面モードで、角の近くにある UI 要素が表示可能部分の外にはみ出ている。売買アプリで「購入」ボタンの一部が表示されていなかったらどうなるでしょうか。マテリアル デザイン ガイドラインに従い、レイアウトには 16dp の余白を空けることを推奨します。

レスポンシブ UI を使うのが適切ではない状況にある方は、 最後の手段として、 サポートする最大アスペクト比を明示的に宣言することができます。それよりアスペクト比が大きい端末では、レターボックスでパディングされた互換モードでアプリが表示されます。端末モデルによっては、ユーザーが強制的に全画面の互換モードでアプリを表示できるようになっているものもありますので、そのようなシナリオについても忘れずにテストを行うようにしてください。

ターゲット API レベル 26 以降: android:maxAspectRatio 属性を利用します。

ターゲット API レベル 25 以前: android.max_aspect メタデータを利用します。 最大アスペクト比の値は、アクティビティが resizableActivity をサポートしていない場合に限り有効な点に注意してください。 詳細については、ドキュメントをご覧ください。

宣言されている最大アスペクト比が端末の画面よりも小さい場合、システムのレターボックスが挿入される

複数 アクティビティの利用を勘案する

アスペクト比が大きい端末では、ユーザーの生産性を上げるマルチウィンドウが利用しやすくなっています。Android 7.0 以降のプラットフォームがサポートされている端末では、マルチウィンドウを実装したり、アクティビティ間でデータのドラッグ＆ドロップを利用する標準的な方法が提供されています。詳しくは、ドキュメントをご覧ください。

テストは非常に重要です。高アスペクト比の端末が手元にない方は、ハードウェア プロパティで適切な画面サイズや解像度を設定したエミュレータを使ってテストしてください。詳しい説明は、エミュレータのドキュメントに掲載されています。

多くのアプリがすでに高アスペクト比の端末に対応しています。いくつかの手順を踏むだけで、そういった端末の長所をフル活用したアプリやゲームを作ることができます！



Reviewed by Yuichi Araki - Developer Relations Team

Google Cloud に代表されるクラウド技術の進化が引き起こすその先の世界を、機械学習、VR / AR、IoT などの領域で活躍されているスタートアップの方々と一緒に議論するイベント「INEVITABLE ja night」。

第 3 回目は「クラウドとモバイルが加速するキャッシュレス社会への不可避な流れ」がテーマです。講演会後には恒例の交流会も行います。参加者様同士の交流はもちろん、日頃の業務の課題や悩みについても、ご相談／共有いただける良い機会です。

キャッシュレス化に関するテクノロジーやビジネスにご興味のあるビジネス企画者、スタートアップ企業の方々のご参加をお待ちしています。


【開催概要】
イベント名 : INEVITABLE ja night - “インターネットの次にくるもの”
第 3 回 クラウドとモバイルが加速するキャッシュレス社会への不可避な流れ

日程 : 2018 年 2 月 16 日（金） 19:00 〜 21:00（開場 18:30 より）
会場 : グーグル合同会社
定員 : 200 名
ハッシュタグ : #inevitableja


プログラムの詳細や参加の申し込み手続きは 1 月上旬開始を予定しています。メールアドレスをご登録いただいた方には、情報更新の際にお知らせをお送りします。ご登録方法は事前登録サイトをご覧ください。


皆様のご参加をお待ちしております。



Posted by Takuo Suzuki - Developer Relations Team

この記事はエンジニアリング部門副社長、Dave Burke による Android Developers Blog の記事 "Final preview of Android 8.1 now available" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


先月、Android 8.1 デベロッパー プレビューのアップデートが公開されました。今月に入ってすでに一般ユーザー向けに公式リリースされています。Android 8.1 では、Oreo プラットフォームに Android Go（メモリが 1GB 以下の端末）の最適化、端末上の人工知能を加速させる新しい Neural Networks API など、いくつかの的を絞った機能拡張が追加されます。また、ユーザーやデベロッパーのフィードバックにお応えし、いくつかの小さな Oreo の機能拡張も含めています。

12 月の公式リリースでは、サポート対象となる世界中のすべての Pixel および Nexus 端末に Android 8.1 が提供されました。対象端末には、Pixel 2 と Pixel 2 XL、Pixel、Pixel XL、Pixel C、Nexus 5X、Nexus 6P が含まれます。

今回のアップデートの内容

今回のプレビュー アップデートには、公式 API（API レベル 27）、最新の最適化やバグの修正、2017 年 11 月のセキュリティ パッチ アップデートなど、Pixel および Nexus 端末向けの最終版とほぼ同じ Android 8.1 システム イメージが含まれています。このイメージは、互換性テストや、Neural Networks API などの機能をはじめとする Android 8.1 の新機能を使った開発に利用できます。

Neural Networks API は、TensorFlow Lite や Caffe2 などの端末内機械学習フレームワーク計算や推論を高速化します。TensorFlow Lite は、Google のモバイル用クロスプラットフォーム ML ライブラリで、現在、デベロッパー向けに公開されています。ダウンロードやドキュメントは、TensorFlow Lite オープンソース レポジトリをご覧ください。TensorFlow Lite は、Neural Networks API を使ってモバイル端末上で MobileNets、Inception v3、Smart Reply などのモデルを効率的に実行します。

さらに、Pixel 2 ユーザーは、端末で Android 8.1 アップデートを行うと、新しいデベロッパー オプションから Google 初のイメージ処理および ML 用カスタム デザイン コプロセッサである Pixel Visual Core を利用できるようになります。これが有効になると、Android Camera API を利用するアプリで Pixel Visual Core を使って HDR+ ショットを撮影できるようになります。詳しくは、リリースノートをご覧ください。

アプリの準備

Android 8.1 はすでに正式にリリースされています。既存のアプリのテストをすぐに始めることが重要です。

Pixel や Nexus 端末をお持ちでない方は、テスト用の Android 8.1 エミュレータを設定できます。問題を発見した場合は、修正して、アプリのプラットフォームのターゲットを変更せず、すぐに Google Play のアプリをアップデートしてください。

準備ができたら、Android 8.1 の新機能と API を活用してみましょう。詳しくは、デベロッパー プレビュー サイト、API 27 差分レポート、最新の API リファレンスをご覧ください。

Android Studio で開発をスピードアップ

Android 8.1 でビルドする場合、安定版チャンネルで入手できる Android Studio 3.0 にアップデートすることをおすすめします。Android Studio 3.0 では、新しいアプリのパフォーマンス プロファイリング ツール、Kotlin プログラミング言語のサポート、Gradle ビルドの最適化が行われているので、Instant Apps、XML フォントやダウンロード可能フォント、アダプティブ アイコンなどの Android Oreo の機能の開発も簡単になります。

また、Android サポート ライブラリ 27.0.0 へのアップデートもおすすめします。これは、Google の Maven レポジトリで公開されています。新機能の詳細については、バージョン情報をご覧ください。

アップデートを Google Play に公開する

Google Play では、API 27 でコンパイルしたアプリや、API 27 をターゲットにしたアプリを受け付けています。準備ができ次第、APK のアップデートをアルファ版、ベータ版、または本番チャンネルで公開しましょう。

Android 8.1 だけでなく、それ以前のバージョンでも問題なく動作するように、Google Play のベータ版テスト機能を使って、少人数のユーザーを対象にアルファテストを行うことをおすすめします。その後、規模を広げてオープンベータ版テストを行います。アップデートをリリースする準備ができた際には、本番チャンネルで段階的ロールアウトを利用することもできます。皆さんのアプリのアップデートを楽しみにしています。

フィードバックをお待ちしています

いつものように、皆さんのフィードバックは重要です。どしどしお寄せください！Android プラットフォームの問題、アプリの互換性の問題、サードパーティ製の SDK やツールの問題を報告できるさまざまなホットリストが利用できます。Neural Networks API の問題専用のホットリストもできました。

今後も Android デベロッパー コミュニティ、または Android ベータ版コミュニティを通じてフィードバックをお寄せください。



Reviewed by Yuichi Araki - Developer Relations Team

この記事は AIY Projects ディレクター、Billy Rutledge による Google Developers Blog の記事 "Introducing the AIY Vision Kit: Add computer vision to your maker projects" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

AIY Voice Kit をリリースしてから、私たちはモノ作りコミュニティから寄せられるたくさんのすばらしい作品に感動し続けています。本日は、AIY チームから、次期プロジェクトについてお知らせします。手頃でカスタマイズ可能なインテリジェント カメラ、AIY Vision Kit です。

Voice Kit と同様、Vision Kit も簡単に組み立て Raspberry Pi コンピュータに接続できます。ユーザーのフィードバックをもとに、この新しいキットは小型の Raspberry Pi Zero W コンピュータで動作するよう設計されています。視覚アルゴリズムをデバイス上で実行するので、クラウドに接続する必要がありません。

見るだけでなく、知覚できるインテリジェントな端末を構築する

キットには、VisionBonnet、段ボール製の外殻、アーケード スタイルの RGB ボタン、ピエゾ スピーカー、マクロ / ワイド レンズキット、フレックス ケーブル、絶縁体、三脚固定用ナット、接続部品が含まれています。


VisionBonnet は、Raspberry Pi Zero W 用アクセサリー ボードで、ニューラル ネットワークを実行できる低電力視覚処理ユニット Intel® Movidius™ MA2450 が使われています。これにより、イメージをただ感知するのではなく、視覚認識が利用できるのです。毎秒最大 30 フレームのスピードで実行でき、リアルタイムに近いパフォーマンスを実現します。


ソフトウェア イメージとともにバンドルされているのは、次の 3 つのニューラル ネットワーク モデルです。

• 1000 個ほどの一般的な物体を認識できる MobileNets に基づいたモデル
• イメージ内の顔を検知するだけでなく、「悲しい」から「笑い」までの「喜び度」で表情を数値評価することもできる顔検知モデル
• 猫、犬、人を区別するという重要なタスクのためのモデル

独自のモデルを使うことを考えている方のために、オリジナルの TensorFlow コードとコンパイラも付属しています。新しいモデルを使って（またはトレーニングして）、Intel® Movidius™ MA2450 で実行させましょう。

キットを拡張し、現実世界の問題を解決する

AIY Vision Kit は思いどおりにカスタマイズできます。

• 独自の製品を試作する場合、Vision Kit と the Raspberry Pi Zero W なら、どんな小さなケースにも収まります。
• カメラの動作を変更したい場合は、Python API を使って新しいソフトウェアを記述すれば、RGB ボタンの色、ピエゾ素子による通知音、GPIO ピンをカスタマイズできます。
• ライトやボタン、サーボを追加したい場合は、4 つの GPIO 拡張ピンを使って独自のハードウェアを接続できます。

次のようなおもしろい課題を解決するために使っていただけることを期待しています。

• 「ホットドッグかどうか」（またはその他の食品）を検出する
• 誰かがドアから入ってきたら、音楽を鳴らす
• 車が私道を出た際にテキスト メッセージを送信する
• 犬が家に戻りたがっているときに犬用のドアを開ける

入手する準備はできていますか

AIY Vision Kit は 12 月に発売される予定ですが、本日（*原文公開当時）より Micro Center でオンライン先行販売が行われています。

*** AIY Vision Kit には、Raspberry Pi Zero W、Raspberry Pi Camera V2 およびマイクロ SD カードが必要です。これらは別途購入する必要があります。

フィードバックをお待ちしています

私たちは、皆さんからの情報をお待ちしています。ソーシャル メディアで #AIYProjects ハッシュタグをつけて、キットの改善案や皆さんが作っているものを共有してください。AIY Vision Kit を使ってあらゆる種類のクリエイティブな端末を作っていただけることを期待しています。



Reviewed by Takuo Suzuki - Developer Relations Team

この記事は プロダクト マネージャー、Jason St. Pierre による The Firebase Blog の記事 "Announcing Firebase Crashlytics Beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Fabric が Firebase チームに合流してから、私たちの共同ミッションは、このすばらしいプラットフォームを統合して最高の機能を提供することです。本日（*原文公開当時）は、Firebase Crashlytics のベータ版がリリースされ、そのミッションが大きな節目を迎えたことをお知らせします。

Firebase Crashlytics は、強力なリアルタイム クラッシュ レポート ツールで、アプリの品質を損なう安定性に関する問題のトラッキングや優先順位付け、修正をサポートしてくれます。今回のリリースで、Firebase デベロッパーは最高水準の障害レポート ソリューションにアクセスできるようになり、慣れ親しんでいるその他すべての Firebase 製品とともに、1 つの統合コンソールで使うことができます。今後、Firebase のプライマリ障害レポートは Crashlytics になります。そのため、既に Firebase Crash Reporting を使っている方は、Crash Reporting ダッシュボードのバナーをクリックしてすぐにアップグレードすることをお勧めします。新しい Firebase デベロッパーの皆さんも、g.co/firebase/optin にアクセスして Crashlytics を使い始めましょう。

ここでは、アップグレードの内容について説明します。ここで説明するメリットや機能によって、Crashlytics はすべてのモバイルアプリ デベロッパーにとって欠かせないツールになります。

トラブルシューティングの高速化

Crashlytics では、安定性に関するもっとも重要な情報が最初に表示されます。クラッシュ情報は、スタック トレースの類似性に基づいてグループ化され、影響がハイライト表示されます。リアルタイムのクラッシュ データでトレンドを確認したり、バージョンでフィルタリングして一番気になるリリースに注目することも簡単です。問題の概要ページと詳細ページは、問題の解決にかかる時間を短縮するという最終目標に基づいて設計されています。

概要ページには、クラッシュを経験していないユーザーの比率がわかりやすく表示されているので、どのビルドで安定性が改善されているかを判断できます。

さらに、重要度バッジにも気づくはずです。これらのバッジがハイライト表示されているのは、その問題について、他にはない重要な情報が得られるという印です。たとえば、ある問題が特定の端末や OS、または「脱獄」したスマートフォンでのみ起きている場合、重要度バッジはそれを教えてくれます。

こういった知見を活用すれば、一目で問題を効率的に選別し、緊急の問題にすばやく対応できるようになります。脱獄した端末でばかり起きている問題は、無視することもできます。また、まずは最新の OS のリリースによって発生している問題の修正に集中することもできます。重要度バッジは、トラブルシューティングの時間に関して賢い選択をする手助けをしてくれます。

カスタムのキーとログ

Crashlytics のログやキーを分析すると、クラッシュが発生した理由や何がクラッシュにつながったのかについて、追加情報や状況を把握することができます。

具体的には、ログを使うと、クラッシュの直前のユーザーの行動について詳細情報を収集できます（ユーザーがダウンロード画面に移動した、ダウンロード ボタンを押したなど）。また、ログはユーザーのアクションについての詳細情報を得るためにも使うことができます（イメージのダウンロード サイズなど）。ログを使うと、クラッシュ前のイベントをタイムラインで確認できます。クラッシュが発生した際には、ログの内容が取得されてクラッシュに添付されるので、すばやくデバッグするために役立ちます。

また、状況によっては、操作の順番と同じくらいユーザーのアプリの最後の状態を知ることが重要になる場合もあります。キーとは、何かの既知の最後の値を記録するキー・バリューです。これは、ユーザーがアプリを操作するたびに上書きされます。たとえば、キーを使うと、ユーザーがゲームアプリの中で終えた最後のレベルや、カスタム設定の最新の設定など、デバッグに関係しそうな情報であれば、何でもトラッキングできます。

ログとキーは、セッションのメタデータから手がかりを見つけ、ユーザーの操作を繰り返してバグを再現するための重要な方法です。

リアルタイム アラート

安定性の問題は、いつ発生するかわかりません。皆さんがワークステーションから離れているときに起きることもあるでしょう。Crashlytics ダッシュボードでは、新しい問題がリアルタイムに表示されて優先度がつけられるだけでなく、新しい問題が起きたときやリグレッションが起きたとき、そして問題の影響が突然大きくなったときにメールで通知してくれます。私たちが皆さんの後ろで守っているので、安心してその場を離れ、コーヒーを飲みながら休憩することができます。最近リリースしたアプリで何かうまくいかないことが起きると、Crashlytics が警告してくれるので、重要なクラッシュを見逃すことはありません。

Firebase Crashlytics + Cloud Functions for Firebase

多くの強力な Crashlytics 機能が Firebase に追加されただけでなく、さらに 1 歩踏み出し、Crashlytics とプラットフォームの他のパーツと統合する作業も始まっています。Crashlytics データを Cloud Functions for Firebase をトリガーするイベントソースとして使えるようになったので、トラブルシューティングのプロセスをカスタマイズし、効率化できるようになりました。この統合によってワークフローを自動化し、重要なアプリのフロー（購入フローなど）に影響する問題を直接チームのエンジニアや Slack チャンネルに送ることも可能になります。これによって、緊急の問題の確実な監視や、適切かつ迅速なエスカレーションが可能になります。



さらに、再設計された Firebase console のさまざまな部分に安定性データが表示されるため、安定性について詳しく把握するためにあちこちのページを開く必要はなくなります。Crashlytics データは、プロジェクトの概要ページや Google Analytics for Firebase ダッシュボード、そしてもちろん最新リリースのセクションにも表示されます。

今後も期待のアップデートが続きます

今回の Crashlytics のベータ版リリースは、Fabric と Firebase の最高の機能を組み合わせる作業のほんの始まりにすぎません。お客様は、既にこれらのプラットフォームを合わせて使い始めており、すばらしい成果をあげています。打ち合わせなど、最適な日時を見つける手助けをしてくれる Doodle アプリの例をご覧ください。Doodle は、アプリを Crashlytics と Remote Config を使って再設計し、維持率とリピート率を上昇させました。





今後は、初めての方も既存のユーザーも、Firebase Crashlytics をご利用ください。Crashlytics は、Firebase のプライマリ障害レポートになっています。 新しく Firebase を使う方は、g.co/firebase/optin にアクセスして Crashlytics を始めることができます。また、 既に Crash Reporting を使っている方は、ダッシュボードのバナーをクリックしてください。Crashlytics の機能強化は今後も続きます。皆さんからのフィードバックが待ちきれません。

Fabric で Crashlytics を使っていた方は、そのままで大丈夫です。まだ移行する必要はありません。Firebase Crashlytics が Fabric アプリにもたらすメリットについて、近日中にすばらしいニュースをお伝えする予定です。



Reviewed by Khanh LeViet - Developer Relations Team

この記事はデベロッパー アドボケート、Todd Kerpelman による The Firebase Blog の記事 "Announcing Better A/B Testing with Firebase" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Firebase の A/B テスト改善のお知らせ

ほとんどのアプリのデベロッパーは、アプリの長期的な成功において、小さな変更が大きな違いを生むことを知っています。多くの場合、「購入」ボタンの表現、サインアップ フローで表示されるダイアログの順番、ゲームの特定のレベルの難易度といった細部に注意を向けるところから、トップチャートに掲載されるアプリと勢いを失うアプリとの差が生まれます。

しかし、正しい変更を行ったかどうかは、どうすればわかるのでしょうか。もちろん、経験に基づいて推測したり、友人に聞いたり、グループで討論したりすることもできるでしょう。しかし多くの場合、アプリの変更に対するユーザーの反応を知るもっともよい方法は、単にその変更を試してみて、自分の目で確認することです。A/B テストはこの考えに基づいています。この機能を使うと、無作為に選択されたユーザーに対して 2 つ（またはそれ以上）のバージョンのアプリを同時にリリースし、実際にどちらのバージョンでより望ましい結果が得られるかを確認できます。

Firebase Remote Config では、「無作為のパーセンタイル」条件を使って単純な A/B テストを実行できましたが、今回はさらにそれが進化し、Firebase にまったく新しい実験レイヤーが追加されています。これは、Remote Config と通知を使った仕組みで、高度な A/B テストをすばやく簡単に設定して評価できるようにするものです。その仕組みを簡単に紹介しましょう。

新しい A/B テスト機能を理解する

新しい A/B テスト機能を使うと、Remote Config で管理している任意の値の組み合わせを使って A/B テストを作成できます。A/B テストを設定すると、さまざまな実験の挙動を定義できます。まずは、実験に参加するユーザーの数……

実行するバリアントの数や、各バリアントでのアプリの挙動……

さらに、実験の目標を定義できます。

目標は実験ごとに違うかもしれません。そのため、A/B テストはさまざまな一般的な成果に対応できるようになっています。たとえば、アプリの合計収益や維持率の増加、クラッシュ数の減少などを指定できます。また、アプリ内チュートリアルの終了など、Google Analytics for Firebase で計測している任意のイベントの発生回数の増加も指定できます。

A/B テストを定義すると、Firebase は無作為に選択した対象端末のユーザーに対して異なるバリエーションのアプリを配信します。Firebase は長期にわたってユーザーの行動を計測し、先ほど定義した目標に応じた成果が出たと思われる場合、通知してくれます。Firebase の A/B テストは、無料で使えるウェブサイトのテストおよびパーソナライズ製品である Google オプティマイズで使われているのと同じベイズの統計モデルを使って結果を計測しています。

A/B テストでオンボーディングを改善する: 事例紹介

先日、生活習慣の改善をサポートするアプリである Fabulous は、Firebase の A/B テストを使ってアプリのオンボーディング フローを改善しました。ユーザーが最初にアプリを起動すると、習慣として行うべき内容が表示され、よい習慣を作る方法が文字で説明されたあと、簡単なルーチンを行ってみることが提案されます。Fabulous チームは、このオンボーディング プロセスからいくつかのステップを省けば、プロセスを完了できるユーザーが増えるかもしれないと考えました。

典型的なユーザーが初めて Fabulous を使う際に表示される画面

そこで A/B テストを実施して、ユーザーごとに、文字を表示しない、簡単なルーチンを実行するよう提案する部分を表示しない、その両方を表示しない、のいずれかになるようにしました。そして、オンボーディング プロセスから両方の手順を省くと、オンボーディング フローを完了するユーザーが 7% 増加することがわかりました。さらに重要なのは、オンボーディングの手順が短くなっても、アプリの維持率にマイナスの影響がない点を確認できたことです。

Notifications のテストとの組み合わせ

Firebase Notifications コンソールを使うと、アプリの通知メッセージで A/B テストを行うこともできます。いくつかの異なる通知メッセージを試し、どれを使った場合にその通知からアプリを開くユーザーが増えるかを確認できます。また、どのメッセージを使えば、購入などのアプリ内で意図した操作を行ってくれるユーザーが増えるかも確認できます。

スタートガイド

A/B テストは、本日（*原文公開当時）よりすべての Firebase デベロッパーがベータ版として利用できます。ぜひ試してみたいという方は、アプリが Remote Config または Firebase Cloud Messaging を使うようになっており、ライブラリを最新かつ最高のバージョンにアップデートしていることを確認してください。A/B テストの詳細は、いつでもドキュメントで確認できます。または、私たちが制作している動画シリーズ、プロの A/B テストをご覧ください。

そして Firebase Console を開き、アプリの改善を始めましょう。実験は一度に 1 つずつ行うようにしてください！



Reviewed by Khanh LeViet - Developer Relations Team

この記事は デベロッパー アドボケート、Oscar Rodriguez による Android Developers Blog の記事 "10 things you might be doing wrong when using the SafetyNet Attestation API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

SafetyNet Attestation API は、アプリを実行する Android 環境のセキュリティや互換性の評価に便利です。2015 年 3 月に導入されてから、多くのデベロッパーがこれを Android アプリに組み込み、アプリを実行する端末の整合性や互換性の情報に基づいて判断をしています。

その間も SafetyNet Attestation API は進化を続け、導入数も安定して伸び続けています。ただし、セキュリティや不正使用対策関連 API の例に漏れず、不安定なシステムの開発につながる一般的な落とし穴が多くあることも事実です。ときには、セキュリティの誤認に陥ってしまうこともあるかもしれません。

この記事では、SafetyNet Attestation API を組み込む際にありがちな間違いについて説明します。

1. API キーを取得していない

他の多くの Google API と同じように、SafetyNet Attestation API の実行には API キーが必要です。さらに、SafetyNet Attestation API は API キーごとにクォータ（利用上限）が割り当てられています。このクォータは引き上げることができますが、その前にまずは API キーが必要です。

API キーの取得は無料で簡単に行うことができます。API キーを取得しない理由はありませんので、まだ取得していない方は、すぐに API キーを取得してください。

2. 最新版の API を使っていない

SafetyNet Attestation API は進化を続けており、それとともにいくつかのインターフェースの変更も行われています。直近では、Google Play Services 11.0.0 のリリースに伴って SafetyNet API 全体が改訂され、さらに簡単で効率的なインターフェースが提供されるようになっています。新しい API では、サポート終了となった SafetyNetApi に代わって SafetyNetClient を使います最新版の API を使うように実装を更新してください。

Google Play Services の最新版はほとんどの端末にインストールされているはずですが、Google Play Services がインストールされていない端末や最新版になっていない端末で SafetyNet Attestation API を使うと、アプリが無応答になったりクラッシュしたりする場合があります。これを防ぐには、API を使う前にインストールされている Google Play Services のバージョンを確認してください。

3. 誤って nonce を使用している

SafetyNet Attestation API では、各 API 呼び出しをユニークに識別するため、nonce を設定することができます。この機能を使うと、悪意のあるユーザーによって、不合格した結果の代わりに合格した結果が再利用されるのを防ぐことができます（この攻撃手法は、 リプレイ アタックとも呼ばれています）。

nonce を作る適切な方法の 1 つは、暗号論的擬似乱数生成器（CSPRNG）を使ってサーバー上で大きなランダム値（16 バイト以上）を作ることです。SafetyNet Attestation API から返されるレスポンスには設定された nonce が含まれているので、返された nonce がリクエストに含めたものと一致することを確認してください。

4. サーバー上でレスポンスを確認していない

SafetyNet Attestation API は、アプリを実行している端末の状態に関する有用な情報を提供してくれます。ただし、こういった情報を利用するロジックを端末側（クライアント側）だけで実装している場合、攻撃者はアプリを改変してすべてのチェックを回避できてしまいます。

この状況を避けるために、API の結果を検証するロジックやそれに基づくアクションを実施するロジックを、ご自身の管理下にある（信頼できる）サーバー上で実行するようにしてください。

5. テスト専用の検証サービスを本番環境で使用している

SafetyNet Attestation API の開発やテストを簡単にするために、Google は単純な HTTPS リクエストで API のレスポンスに含まれているデジタル署名を確認できるオンライン検証サービスを提供しています。

このサービスは便利に思えるかもしれませんが、これはテスト目的に限定して設計されているため、低いクォータ（利用上限）が設定してあり、これを引き上げることはできません。本番運用のためには、Google のサーバーに依存しない形で、ご自身のサーバー上にデジタル署名検証ロジックを実装してください。署名検証機能は、ほとんどの JWT ライブラリで提供されており、Java と C# の実装のサンプ ルコードを公開しています。今後、他の言語のサンプルコードも提供する予定です。

6. nonce、タイムスタンプ、APK 名、ハッシュを確認していない

SafetyNet Attestation API を互換性と整合性を確認する方法としてご存知の人も多いと思います。値としては ctsProfileMatch と basicIntegrity を返します。この 2 つの値は有用ですが、API のレスポンスにはそれ以外にも重要な値が含まれていますので、忘れずにチェックしましょう。

前述のように、nonce を使ってレスポンスがリクエストと一致しているかを確認することができます。また、timestampMs を使ってリクエストからレスポンスまでの経過時間を確認することができます。リクエストから数時間または数日してから返ってくるようなレスポンスは、疑わしいものである可能性があります。

また、apkPackageName を使って API を呼び出した APK 名を確認することができます。Google Play に登録した APK ファイルのハッシュ値、その署名のハッシュ値を、API を呼び出したアプリの apkDigestSha256 値、apkCertificateDigestSha256 値と比較することで、インストールされているアプリの整合性を確認することができます。

この API のレスポンス全体が信頼できるかどうかは、ctsProfileMatch と basicIntegrity の結果にもよることを忘れないようにしましょう。basicIntegrity が false（不合格）の端末では、SafetyNet Attestation API のレスポンスの他の項目が偽装されている可能性も考えられます。

7. ctsProfileMatch と basicIntegrity の違いを理解していない

初期の SafetyNet Attestation API では、端末の整合性をデベロッパーが検証するために提供していたのは basicIntegrity 値だけでした。その後 API の進化とともに、より厳密な検証が行えるように ctsProfileMatch 値もあわせて提供するようになりました。

広い意味では、basicIntegrity は端末とその端末で利用できる各 API との全体的な整合性についての情報を提供します。ルート化端末、エミュレータ、仮想端末、API フックなどの改ざんが検知された端末では、basicIntegrity が false（不合格）になります。

一方、ctsProfileMatch は、端末の互換性に関するさらに厳密な情報を提供するものです。Google の互換性認証を受けており、改変されていない端末の場合にだけ、ctsProfileMatch が true（合格）になります。例えば下記のような端末では、 ctsProfileMatch が false（不合格）になります。

• basicIntegrity が false（不合格）の端末
• ブートローダーがアンロックされている端末
• カスタム システム イメージ（カスタム ROM）が搭載されている端末
• メーカーが Google の互換性認証を申請していない、あるいはそれに合格していない端末
• Android Open Source Program のソースファイルから直接にビルドしたシステム イメージが搭載されている端末
• ベータ版またはデベロッパー プレビュー プログラムで配布されたシステム イメージが搭載されている端末（Android ベータ プログラムを含む）

8. API を使用するタイミングに関する戦略を立てていない

SafetyNet Attestation API は、リクエストが行われた瞬間の端末の状態のスナップショットを提供するものです。あるタイミングでの検証に合格したからといって、過去に常に合格していたとは限らず、また未来に必ず合格するとも限りません。

SafetyNet Attestation API の検証は単なるスポット チェックであるため、API 呼び出しのタイミングについて、適切な戦略を立てる必要があります。アプリ内購入の直前、定期的に数日ごと、アプリが起動した直後、端末の再起動を検知したときなど、あなたのアプリにとって適切な戦略で API を呼び出しましょう。

なお、SafetyNet Attestation API を使用しすぎると CPU、電池消費、ネットワーク通信に大きな負荷をかけてしまいます。想定しているユースケースに必要な最低限の API 呼び出しをする戦略を立てることをお勧めします。

9. SafetyNet Attestation API の結果だけで不正を判断している

アプリを不正から守るために必要なシグナルはすべて SafetyNet Attestation API が提供してくれると考え、そのシグナルだけを使って不正対策システムを構築してしまうことはあまり適切とは言えません。

SafetyNet Attestation API は、端末の状態に関するシグナルは検出できますが、ユーザーの意図を検出することはできません。不正対策を検討するには、端末の状態だけを見るのではなく、ユーザーの意図を検知するよう努力しましょう。不正ユーザーの意図を正確に検知するには、アクセスログや行動パターンなど、他の情報を含めて考える必要があります。SafetyNet Attestation API 検証が不合格という理由だけでユーザーをすぐにブロックしてしまわない方がよいでしょう。ネットワーク接続の問題、クォータ（利用上限）の問題、その他の一時的な問題など、検証が不合格になる原因には他にもたくさんの可能性があります。

言い換えれば、SafetyNet Attestation API の検証で不合格となったすべてのユーザーが不正をしているとは限りません。また、すべての不正ユーザーがこの API で不合格になるとも限りません。この API の検証結果だけでユーザーをブロックするしないの判断をすると、検証に合格している不正ユーザーを見逃してしまう可能性があり、検証に不合格になっている正当な優良顧客をブロックしてしまう可能性もあることに注意しましょう。

10. クオータの監視や管理を行っていない

前述のように、SafetyNet Attestation API にはクォータ（利用上限）が存在します。デフォルトのクォータは、API キー 1 つごとに 1 日当たり 10,000 リクエストです。ほとんどの開発、テスト、初期のリリースでは、このクォータは十分と考えられますが、アプリが人気になると、デフォルトのクォータでは不足してしまう可能性があります。

知らない間にクォータを超えてしまい API エラーが起こるのを防ぐために、API の使用量を監視し、クォータを超える前に警告してくれるシステムを構築しておきましょう。また、クォータ超過が原因で API エラーが起きた時、すべてのユーザーをブロックしてしまわないように注意しましょう。

クォータ超過が予想される場合は、こちらのフォームを送信して一時的または長期的にクォータを引き上げるようリクエストすることができます。このリクエスト送信や追加クォータは無料でご利用いただけます。

Reviewed by Oscar Rodríguez - Developer Relations Team

この記事は Toyota Motor Europe ソーシャル ビジネス マネージャー、Christophe Hardy による Maps API Blog の記事 "With Google Maps APIs, Toyota Europe keeps teen drivers safe and sound" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

編集者のメモ: この記事は、Toyota Motor Europe のソーシャル ビジネス マネージャー、Christophe Hardy 氏によるものです。Toyota Motor Europe がどのように Google Maps API を使って Android アプリを構築し、10 代のドライバーの安全を守っているかを説明します。

10 代の若者にとって、自動車の運転免許を初めて手にすることはとても嬉しいことです。しかし、親にとっては心配の種がひとつ増えることを意味します。なぜなら、ハンドルを握っている我が子が安全運転をしているかどうかがわからないからです。

ある調査によると、16～19 歳の少年が自動車衝突事故を起こすリスクは他の年代よりも高く、その 2 大原因はスピード違反と運転中のスマートフォンの利用です。そこで、自動車事故を減らす取り組みとして、Toyota は、Molamil や MapsPeople と協力し、ヨーロッパの 10 代のドライバーに向けた Android アプリ Safe and Sound を開発しました。このアプリは手軽ですが効果的に制限速度や交通ルールに集中できるように若いドライバーをサポートします。また、Toyota の自動車に乗っていない人でも使うことができます。

Safe and Sound は、スピードの出し過ぎや音楽によって運転中に気が散ってしまうことへの対抗策です。親子がそれぞれアプリをダウンロードし、設定を行います。このアプリは Spotify と同期しており、Google Maps Roads API を使って子供の運転中の行動を監視します。スピード違反を検知すると、Safe and Sound は子供が聴いている音楽を親が選んだ Spotify のプレイリストに切り替えます。プレイリストを元に戻すことはできません。多くの場合、親と子供が聴く音楽の趣味は一致しないものです。10 代の若者にとって、フォーク バラードや 70 年代のソフトロックを聞かされることほど格好悪いことはありません（友人が同乗していればなおさら決まりの悪い思いをすることでしょう）。親のプレイリストがオフになり、子供のプレイリストに戻るのは、制限速度内で運転している場合だけです。

さらに、このアプリは運転中に気が散るような操作を防げることもできます。車が時速 9 マイル（約 14 キロメートル）以上で動いていることを検知すると、アプリは、ソーシャル メディアの通知、テキストメッセージの着信や発信、通話をブロックする「マナー」モードに切り替わります。また、こうした状況で子供がスマートフォンをタップしたことを検知すると、スマートフォンから手を離すまで親の Spotify プレイリストを再生し続けます。そして運転を終えると、制限速度を超過した回数やスマートフォンにタップした回数が親に通知されます。親はアプリのリンクをタップして Google マップで子供が運転した経路を表示することもできます。

Google マップは、Safe and Sound を構築する理想的なプラットフォームでした。道路の制限速度を含め、正確で最新かつ包括的なマップデータを提供してくれます。ドキュメントも充実しているので、Google Maps Roads API は簡単に使うことができます。さらに、数百万ユーザーに対応できるスケーラビリティも持ち合わせています。これは、ヨーロッパにアプリを展開していく上でとても重要になります。

現在は、英語版の Safe and Sound がヨーロッパ全体で利用できます。近日中に、スペインでスペイン語版を、ベルギーでオランダ語版とフランス語版をリリースし、別の言語へのローカライズも進める予定です。

Tokyota Motor Europe は、Safe and Sound が 10 代のドライバーへ安全運転を啓蒙し、親に安心を提供できるものになることを期待しています。ヨットロック（Yacht Rock）の名曲のプレイリストにこれ以上の使い方はありません。


Reviewed by 丸山 智康 (Tomoyasu Maruyama) - Google Customer Engineer Lead, Japan and APAC

この記事は IoT デベロッパー アドボケート、Wayne Piekarski による Android Developers Blog の記事 "Android Things Developer Preview 6" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

たくさんの新機能とバグの修正を含む Android Things の次期リリース Developer Preview 6（DP6）が登場しました。Android Things は、Android デベロッパーがモノのインターネット（IoT）端末を構築するための Google 製プラットフォームです。これを使うと、動画やオーディオの処理や TensorFlow による端末上機械学習などの強力なアプリケーションをサポートする IoT 端末を構築できます。新機能の詳細については、リリースノートをご覧ください。ここでは、DP6 の主な新機能をご紹介します。

IoT ランチャー

DP6 には、新しい IoT ランチャーが含まれており、タッチ スクリーンや USB 入力デバイスを使って、端末の現在の状態を確認したり設定を変更したりできます。WiFi の設定、ビルド ID の確認、アップデートのチェックといった設定が対話的に行えるようになり、簡単に使い始めることができます。このランチャーは、デベロッパーが IOT_LAUNCHER Activity を提供していない場合に表示されます。

グラフィック高速化のデフォルト

Android Things は、CPU ベースで OpenGL ES API を実装したオープンソースの SwiftShader ライブラリを使用しています。これにより、GPU ハードウェアが搭載されていないものも含め、すべてのプラットフォーム共通で OpenGL をサポートできます。ただし、ほとんどのシンプルな 2D UI は、OpenGL エミュレーションを使わずに直接フレームバッファに描画する方が高速にレンダリングできます。そこで、DP6 では、デフォルトで OpenGL レンダリングが無効になり、ほとんどのアプリでもっとも高速な UI が実行されるようになります。3D レンダリング、WebView、TextureView などで OpenGL のサポートが必要な場合は、ドキュメントに従い、次のように AndroidManifest.xml で明示的に有効化してください。

<activity

    ...
    android:hardwareAccelerated="true">

API 27 と Google Play Services

DP6 は、API レベル 27 が搭載された最新の Android 8.1 Developer Preview がベースになっています。標準 Android サンプルのほとんどは、DP6 で動作します。たとえば、Camera2 API と TextureView を使っている Camera2Basic サンプルは、NXP と Raspberry Pi ベースの端末の両方で動作します（hardwareAccelerated フラグを true にする必要があります）。Google Play Services は、SDK バージョン 11.6 をサポートするようにアップデートされており、最新機能がすべてサポートされています。

コマンドライン書き込みツール

デベロッパーの皆さんから、fastboot を使ってボードに書き込んだり設定したりする作業は非効率的な場合があるという声が寄せられました。そのため、Android Things Console から簡単に端末イメージを書き込む新しい方法が提供されています。手動で fastboot と adb コマンドを使う代わりに、新しいインタラクティブ コマンドライン android-things-setup-utility を利用できます。このツールを使うと、はるかに簡単に Android Things を使い始めることができ、ダウンロードや書き込みの処理を自動化できます。

Android Things Console のアップデート

DP6 では、今後の製品版リリースに使われる新しいパーティション スキームが導入されています。この新しいパーティション レイアウトのため、既存の DP5.1 以前の端末は無線（OTA）システムによるアップデートはできません。デベロッパーは、Android Things Console を開いて新しい DP6 ビルドをダウンロードして書き込む必要があります。DP6 機能に合わせて Console の UI も変更され、DP6 をベースとした新しいビルドのみ作成できます。それよりも古い既存ビルドは、ダウンロードはできますが OTA アップデートはサポートされません。デベロッパーの皆さんには、すべての作業を DP6 に移行することを推奨します。

GPIO ピンの名前

起動時に表示されるインタラクティブ IoT ランチャーに、I/O ピン出力セクションが含まれるようになります。ここでは、すべてのピンのラベルを確認することができます。i.MX7 で使われるピンの名前は変更されましたが、この新しい命名規則を使う場合、コードをアップデートする必要があります。完全なピンの名前のリストについては、i.MX7 ドキュメントをご覧ください。

設定および端末アップデート用 API

ローカル端末の設定や端末のアップデートを制御できる新しい API が Android Things に追加されています。UpdateManager を使うと、デベロッパーはアップデートや再起動を行えるタイミングを制御できるので、ユーザーが必要なときに確実に端末を使えるようになります。DeviceManager は、ファクトリー リセット、再起動、端末の言語/地域を管理します。画面を管理する ScreenManager、時計やタイムゾーンを管理する  TimeManager など、設定を行う API も提供されます。

周辺機器用のコマンドライン ツール

adb シェル経由で Peripheral API にアクセスできるコマンドライン ツール pio も提供されます。デベロッパーは、adb シェルから、GPIO, PWM, UART, I2C, SPI や今後のインターフェースを対話的にテストできます。これは、デバッグや自動テストに便利です。

フィードバック

DP6 では、プラットフォームに重大な変更や改善が加えられています。バグレポートや機能リクエストを送信し、フィードバックをお願いします。質問は、どんなものでもかまいませんので、Stack Overflow にお寄せください。DP6 を使ってみるには、Android Things Console からシステム イメージをダウンロードして既存の端末に書き込むか、android-things-setup-utility を利用します。詳しい変更点は、リリースノートに記載されています。Google+ の Google IoT デベロッパー コミュニティにも参加できます。これは、最新情報を入手したりアイデアを話し合うことができるすばらしいリソースです。自分が構築したすばらしいプロジェクトを共有できる hackster.io コミュニティも、新たに誕生しました。皆さんが Android Things で作るアプリを楽しみにしています！


Reviewed by Takeshi Hagikura - Developer Relations Team

この記事は Google Expander チーム科学研究者、Sujith Ravi による Google Research Blog の記事 "On-Device Conversational Modeling with TensorFlow Lite" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年初め、スマート メッセージング向けの「端末上」の機械学習テクノロジーを搭載した Android Wear 2.0 がリリースされました。これによって以前から Gmail、Inbox、Allo で利用できた Smart Reply などのクラウドベースのテクノロジーが、初めて任意のアプリから直接利用できるようになります。これは、サードパーティー製のメッセージング アプリでも利用でき、クラウドに接続する必要もありません。そのため、外出中に着信したチャット メッセージに直接スマートウォッチから応答することができます。

本日は、モバイルおよび埋め込み端末向けの TensorFlow の軽量ソリューションである TensorFlow Lite についてお知らせします。このフレームワークは、少ないメモリ、高パフォーマンス、低レイテンシで機械学習モデルの推論を行えるように最適化されています。ライブラリの一部として、TensorFlow Lite を活用した自然言語アプリの例となる端末上会話モデルとデモアプリもリリースしています。その目的は、デベロッパーやリサーチャーが端末での推論を活用して簡単に新しい人工知能機能を構築できるようにすることです。このモデルは、効率的な推論によって、入力される会話のチャット メッセージに対して応答を提案するもので、チャットアプリに簡単に組み込んで端末上での会話体験を改善できるようにするものです。

今回リリースした端末上会話モデルは、ジョイント最適化フレームワークに基づいてコンパクトなニューラル ネットワーク（やその他の機械学習モデル）をトレーニングする新しい ML アーキテクチャを利用しています。これは、当初 ProjectionNet: Learning Efficient On-Device Deep Networks Using Neural Projections として発表されたものです。このアーキテクチャは、任意の入力をコンパクトなビットベクター表現に変換する効率的な「プロジェクション」処理を行ない、計算能力やメモリが限られたモバイル端末でも効率的に実行できます。この操作では、似たような入力が近傍のベクターにプロジェクションされ、プロジェクション処理によって密にも疎にもなります。たとえば、「やあ、調子はどう？」と「調子はどうだい、相棒？」という 2 つのメッセージは、同じようなベクター表現に投影される可能性があります。

この考え方を使うと、計算能力やメモリをあまり使わずに、会話モデルでこういった効率的な操作を組み合わせることができます。私たちは、コンパクトなプロジェクション・モデル（前述）とトレーナー モデルという 2 種類のモデルを同時にトレーニングする ML フレームワークを使い、エンドツーエンドで端末上モデルをトレーニングしました。この 2 つのモデルは、同時にトレーニングが行われます。その際に、プロジェクションモデルはトレーナー モデルから学習します。トレーナーは、大きく複雑な ML アーキテクチャでモデリングされているいわばエキスパートです。一方のプロジェクションモデルは、エキスパートから学習する学生のようなものです。トレーニングの際には、量子化や蒸留処理などのテクニックも利用して、対象機能の圧縮や一部の選択的最適化を行うこともできます。トレーニングが終われば、端末で直接小さなプロジェクションモデルを使って推論を行うことができます。
トレーニング済みのプロジェクションモデルは、モバイル プラットフォームで高速に推論を行えるように最適化された一連の TensorFlow Lite 命令にコンパイルされ、端末で直接実行されます。TensorFlow Lite の端末上会話モデルの推論グラフを以下に示します。

TensorFlow Lite を使った端末上会話モデルの実行

今回リリースされたオープンソースの会話モデル（コードも公開されています）は、前述の結合 ML アーキテクチャを使ってエンドツーエンドでトレーニングしたものです。また、今回のリリースにはデモアプリも含まれているので、モバイル端末でのワンタッチ スマート応答を簡単にダウンロードして試してみることができます。このアーキテクチャでは、アプリのニーズに応じて、モデルのサイズや予測品質を簡単に設定できます。このモデルがうまく対応できるサンプル メッセージの一覧は、こちらから参照してください。このシステムは、一定の応答を提案するようにフォールバックすることもできます。その場合、チャットの会話でよく見られる一般的な応答目的から学習し、その結果をコンパイルした一定のセットが使われます。なお、ベースとなるモデルは、Google のアプリで Smart Reply の応答に使われているものとは異なります¹。

会話モデルの先へ
興味深いことに、前述の ML アーキテクチャでは、ベースとなるモデルを柔軟に選択できます。私たちは、異なる機械学習アプローチと互換性のあるアーキテクチャも設計しています。たとえば、TensorFlow のディープ ラーニングと組み合わせて使う場合であれば、ベースとなるモデルとして軽量ニューラル ネットワーク（ProjectionNet）を学習させつつ、ニューラル ネットワークではなくグラフ フレームワークを使って別のアーキテクチャ（ProjectionGraph）のモデルを表現することができます。

結合フレームワークは、別の ML モデリング アーキテクチャで他のタスクの端末上軽量モデルをトレーニングする際に使うこともできます。たとえば、私たちは、ある ProjectionNet アーキテクチャを派生させています。これは、トレーナー モデルとして複雑なフィードフォワードや再帰アーキテクチャ（LSTM など）を使い、動的プロジェクション操作やいくつかの狭い完全結合レイヤーで構成される単純なプロジェクションアーキテクチャを組み合わせたものです。アーキテクチャ全体は、TensorFlow の誤差逆伝播を使ってエンドツーエンドでトレーニングします。それが完了すると、コンパクトな ProjectionNet を直接推論に利用できるようになります。この手法を使って、モデルのサイズを大幅に削減した（最大で数桁の削減）小さな ProjectionNet モデルをうまくトレーニングすることができました。また、複数の画像や言語の分類タスクにおける精度に関するパフォーマンスも高いものでした（いくつかの例をこちらに示します）。同じように、半教師付きの設定で、グラフ学習フレームワークを使って別の軽量モデルをトレーニングしました。

端末上モデルのトレーニングに使った ML アーキテクチャ: ディープ ラーニングを使ってトレーニングした ProjectionNet（左）と、グラフ学習を使ってトレーニングした ProjectionGraph（右）

今後も、アップデートされたオープンソースの TensorFlow Lite モデルの改善とリリースを継続する予定です。今回リリースされたモデル（今後のモデルも同様）は、以上のような ML アーキテクチャを使って学習したものです。このようなモデルは、多くの自然言語やコンピュータ ビジョンのアプリに再利用されたり、人工知能を活用するために既存のアプリに組み込まれるものと考えています。機械学習や自然言語処理のコミュニティがこういった機能を使って開発を行い、まだ私たちが認識していない新しい問題やユースケースに対応できることを期待しています。

謝辞
この作業には、Yicheng Fan と Gaurav Nemade が大きく貢献してくれました。TensorFlow チームの Rajat Monga、Andre Hentz、Andrew Selle、Sarah Sirajuddin、Anitha Vijayakumar に感謝を捧げます。また、Robin Dua、Patrick McGregor、Andrei Broder、Andrew Tomkins および Google Expander チームにも感謝いたします。

---

1 リリースされた端末上モデルは、スマートフォンやウェアラブルでの小規模かつ低レイテンシな用途に最適となるようにトレーニングされています。一方、Google アプリの Smart Reply 予測は、規模が大きい複雑なモデルで生成されています。実稼働しているシステムでは、不適切なコンテンツを検知するようにトレーニングされた複数の分類器を使っており、ユーザー エクスペリエンスや品質レベルが最適になるようなフィルタリングやチューニングが適用されています。オープンソースの TensorFlow Lite 版を使っているデベロッパーも、末端のアプリではこのような慣習に従うことをお勧めします。^↩



Reviewed by Hak Matsuda - Developer Relations Team

この記事は プロダクト マネージャー、John Shriver-Blake による The Firebase Blog の記事 "Updates to the Firebase console" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年、Fabric が Firebase に合流したとともに、私たちは共通のミッションに向かって 1 つになりました。そのミッションとは、皆さんのようなデベロッパーがすばらしいユーザー エクスペリエンスを構築することに集中できるよう、アプリ開発ライフサイクル全体にわたる日常的な問題を解決するプラットフォームを提供することです。

Fabric が優れていた点は数多くありますが、その中にコンソールとダッシュボードがあります。そこで私たちは協力し合い、Fabric と Firebase の最高の部分を合体させるため、ここ数か月間懸命に取り組んできました。本日は、Firebase コンソールのいくつかのうれしい改善点についてお知らせします。

ナビゲーション デザインの変更

私たちはまず、皆さんのチームの作業内容を正確に反映するようにナビゲーション デザインを変更するところから始めました。そして、Firebase 製品をDevelop、Stability、Analytics、Grow という 4 つのグループに分けました。これは、Firebase プラットフォームの製品の増加に伴い、ナビゲーションしやすいように分類しただけなので、皆さんが使ってきた製品はすべて Firebase コンソール上に表示されています。

新しいプロジェクト ホーム

さらに、Firebase コンソールのプロジェクト ホーム画面では、いくつかの重要な指標を中心に据えました。現在は、Firebase で最初にプロジェクトを開くと、4 つの主要な指標が表示されます。30 日間クラッシュしていないユーザーの比率、30 日間のクラッシュ数、1 日当たりのアクティブ ユーザー数、月間のアクティブ ユーザー数が、トレンドの時間経過がわかるグラフ形式で表示されます。調査結果から、デベロッパーはこれら 4 つの指標のいずれかを探すために多くの時間をかけていることがわかりました。そのため、プロジェクト ホームのランディング ページから簡単にアクセスできるようにしました。

最新リリース

Fabric コンソールで重宝されるもう 1 つの機能が [Latest Release] セクションです。このダッシュボードには、直近にリリースしたアプリから得られるもっとも重要な分析がすべて掲載されており、何がうまくいっており、何にロールバックが必要かを表すスナップショットをすばやく取得できます。そのためこのセクションを、新しくなった Firebase コンソールに移植しました。ナビゲーション バーの [Analytics] セクションからご覧ください。

Analytics ダッシュボードのアップデート

本日より、Analytics ダッシュボードは、わかりやすい質問の下にシンプルなカードが並ぶ形になります。「DAU」や「コホート分析の維持率」といった専門用語でデータを整理すると、ナビゲーションは難しくなります。そこで、「ユーザーがよく利用しているのはどの場所ですか？」「どのくらいのユーザーが定着していますか？」といったアプリについての質問を使ってダッシュボードを再構成しました。調査によると、ユーザーの 90% がこのデザインの方が気に入っていると答えています。皆さんにも便利だと思っていただけることを期待しています。

リアルタイム情報

Fabric を使う友人たちから学び、皆さんからお聞きしたもう 1 つのことは、リアルタイムで情報を得ることが非常に重要だということです。新しくリリースしたアプリのトラッキングであろうと、バグの修正状況のモニタリングであろうと、アプリで何が起こっているのかをリアルタイムで理解する必要があります。そうすれば、その情報に応じて変更したり、作業に優先度をつけることができます。

これをサポートするために、クラッシュとアクティブ ユーザーについてのリアルタイム データを追加しています。これらのデータは、新しい Analytics ダッシュボードとコンソールの [Latest Release] セクションにカードとして表示されます。今回ご紹介したことは最初のステップに過ぎません。今後は、Firebase コンソールの他の部分にもリアルタイム データを表示する予定です。

いつものように、フィードバックや質問は https://firebase.google.com/support/ にお寄せください。ぜひ活用してみてください。

Reviewed by Khanh LeViet - Developer Relations Team

この記事は プロダクト、マネージャー、Dru Knox による Chromium Blog の記事 "Building unified documentation for the web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 ブラウザは常に新しい方向を探求しています。各ブラウザがそれぞれに実験を繰り返すことで、ウェブは新しいユースケースを満たすように進化してきました。一方、ウェブの変化に追いつくのは難しくなりつつあります。ブラウザの機能や API を記したドキュメントは、各ブラウザによってメンテナンスされていますが、クロスブラウザなドキュメントは分断されがちです。Chrome の最優先事項の 1 つは、開発者のみなさんがあらゆるブラウザで動作するサイトを簡単に開発できるようにすることです。その中でも、ドキュメントの簡素化は重要な位置を占めます。

本日（*原文公開当時）、ウェブのドキュメントは統合に向けた大きな一歩を踏み出しました。Mozilla Developer Network（MDN）Web Docs は、新しい製品諮問委員会を発表しました。その創立メンバーは、Mozilla、Google、Microsoft、Samsung など、ウェブ標準および開発コミュニティのメンバーです。この製品諮問委員会は、MDN のウェブ ドキュメントが進むべき方向について、レビューおよびフィードバックを実施します。

ここ数年で、Chrome はウェブ ドキュメント関連の作業を MDN に移行してきました。これにより、Mozilla などの多くのオープンソース制作者と連携してドキュメント関連の作業ができるようになりました。製品諮問委員会は、MDN をウェブ上でもっとも新しく質の高い包括的なドキュメント ソースにするためのさらなる一歩となります。この動きは、ウェブの構築全般を簡単にするという私たちの目標とも一致しています。その取り組みの一環として、私たちはウェブの相互運用性テストにもリソースを投入しています。これにより、ブラウザがテストを共有して機能の互換性を比較できるようになります。また、ブラウザ 開発者が実装間でバグや API の欠落を見つける際に役立つ新たなインフラストラクチャの構築も進行中です。

ウェブ API の一元化されたドキュメント ソースである MDN Web Docs をご確認ください。また、ウェブをさらに開発が簡単なプラットフォームにするための取り込みに関する情報にもご注目ください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は [プロダクト マネージャー、Brad Abramsによる Google Developers Blog の記事 "Help users find, interact & re-engage with your app on the Google Assistant" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーは毎日、Google アシスタントやアプリを活用して用事を片付ける方法を新たに発見しています。本日は、ユーザーによるアプリの検索、インタラクション、リピート率向上を簡単にするための一連の新機能についてお知らせします。

ユーザーにアプリを見つけてもらいやすくする

Google アシスタントの国際化サポートやアップデートが進むにつれて、ユーザーはアプリを見つけやすくなっています。

• アプリ ディレクトリのアップデート: スマートフォンのアシスタントのアプリ ディレクトリに、 新しいアプリ や 人気のアプリ を紹介するセクションが追加されています。これらの動的セクションは、常に変化、進化します。そのため、Google アシスタントや Actions on Google が利用できるすべての言語/地域で、皆さんのアプリをユーザーに見つけてもらえるチャンスが増えます。また、ディレクトリの検索ボックスにオートコンプリートが導入されたので、ユーザーがアプリの名前を思い出せなくても、入力する際に補完してくれます。
• 新しいサブカテゴリ: アプリ ディレクトリにサブカテゴリが作成されたため、「フード、ドリンク」などのカテゴリをクリックすると、「フードを注文」や「メニュー表示」などのサブカテゴリでさらにアプリが絞り込まれます。アプリの説明とサンプル呼び出しを使って、ユーザーの自然検索クエリから新しいタスクベースのサブカテゴリにマッピングしています。分類ラベルもアプリを見つけやすいように更新され、さまざまな機能に応じて、関連するすべてのサブカテゴリでアプリが表示されるようになっています。この変更によって、アプリのすべての機能をユーザーに伝えられるようになり、アプリを見つけてもらう新たな可能性が生まれます。詳細は、こちらをご覧ください。
  

• 暗黙的検出: 暗黙的検出とは、ユーザーがコンテキスト依存クエリを使ってアプリに接続した状況を示します（例: 「自転車の修理を予約」）。この場合、ユーザーはアプリの名前を指定しません。今回、アプリの暗黙的検出を改善するために、コンソールに新しい検出セクションが作成されています。これによって、たとえユーザーがアプリの名前を思い出せなくても、アプリを起動する正確な操作呼び出しフレーズを作成できるようになります。詳細は、こちらをご覧ください。
• 家族向けアプリのバッジ: Google アシスタントで、家族向けであることを示す「For Families」バッジが新しくリリースされます。これは、すべての世代で問題なく利用できるアプリを見つけやすくすることが目的です。Apps for Families プログラムのすべての既存アプリには、自動的にバッジが追加されます。アプリで「For Families」バッジの認証を得る方法については、こちらをご覧ください。
  

• 国際サポート: 本日より、スペイン語（アメリカ、メキシコ、スペイン）、イタリア語、ポルトガル語（ブラジル）、英語（インド）のアプリを開発できるようになったので、ユーザーはさらに多くの言語でアプリを見つけることができます。また、イギリスのデベロッパーは、取引機能を持つアプリを開発できるようになっています。Actions on Google での多言語サポートの方法については、国際化についての動画をご覧ください。
  

さらにインタラクティブなユーザー エクスペリエンスを作成する

ユーザーがアプリを簡単に見つけられるだけでなく、アプリに話しかけると魅力的で有意義な体験ができることも同じくらい重要です。そのために、いくつかの新機能がリリースされています。

• スピーカーからスマートフォンへの転送: Google ホームなどの音声起動スピーカーからアシスタントを起動し、それをユーザーのスマートフォンに転送する機能を開発できる新しい API がリリースされています。スマートフォンに地図を送ったり、スマートフォンで取引を完了させたい方は、下の例を確認し、こちらをクリックして詳細をご覧ください。
  

• パーソナライズされたアプリの開発: ユーザーの体験をさらにパーソナライズするために、選択した情報やプリファレンスをアプリに記憶させることができるようになりました。詳細については、こちらを参照してください。
• SSML の改善: 先日、新しい SSML オーディオ デザインが可能になったウェブ シミュレータのアップデートが公開されました。自然で質の高い会話を作成するために、<prosody>、<emphasis>、<audio> などの新しくサポートされた SSML タグを使えるようになります。新しいタグ <par> も近日中に利用できるようになります。これは、ユーザーがアプリと会話している間に BGM や環境音を再生して、ムードや贅沢さを演出できるようにするものです。この機能を簡単に使えるように、サウンド ライブラリに 1,000 以上のサウンドが追加されています。こちらから、いくつかの新機能を紹介する簡単な SSML オーディオの実験をお聞きください。
• イベントのキャンセル: 現在は、ユーザーが会話の最後に「キャンセル」と言っても、アプリが礼儀正しいお別れのメッセージで答えることはありません。今後は、ウェブフックで最後の 1 つのリクエストを取得できるようになり、フルフィルメント ロジックをクリーンアップしつつ、終了する前にユーザーに応答できるようになります。
• 会話でのアカウントのリンク: 今までは、インタラクションの開始時にアプリにアカウントをリンクさせなければならず、ユーザーがアカウントのリンクを行うべきかどうかを判断することはできませんでした。アップデートされた AskForSignIn API を使うと、もっとも適切なタイミングでアカウントとアプリをリンクすることをユーザーに促すことができます。

ユーザーのリピート率を向上させる

ユーザーにアプリの再利用を促す機能がいくつか追加されているので、お試しください。これらの機能は、テストを始められるように今週デベロッパー向けに公開され、ユーザーにも近日中に公開されます。

• 日次アップデート: アプリを使うすばらしい体験を終えた後、ユーザーは毎日アプリから同じ内容の通知を受けたいと感じるかもしれません。これを実現するために、日次アップデートの登録をユーザーに促す提案チップが追加されました。日次アップデートを設定するには、下の例のように、コンソールの検出セクションを開いてください。
  

• プッシュ通知: アプリからユーザーに非同期アップデートを通知する新しいプッシュ通知 API がリリースされています。ストック オプションを売る最高のタイミングを探しているデイトレーダーや、新しい靴を買うためにバーゲン情報を知りたい倹約家の買い物客には、こういったアラートがスマートフォンにシステム通知として表示されます（後ほど、Google ホームなどの音声起動スピーカー上のアシスタントにも通知されます）。
• ディレクトリ アナリティクス: モバイル ディレクトリでユーザーとアプリとのインタラクションを詳しく分析してユーザー エクスペリエンスの改善を続けられるように、コンソールのアナリティクス ツールが改善されています。アプリの評価やページビューの数とともに、アプリのディレクトリ リストから始めた会話の数について情報を見つけることができます。

すばらしいですね！たくさんのことを紹介してきましたが、これでも準備しているアップデートについて簡単に概要をお伝えしたにすぎません。皆さんがこういったツールを使い、新しくクリエイティブな方法で Google アシスタントの可能性をどう引き出すのか、楽しみです。

Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

この記事は プロダクト マネージャー、Ryan Schoen による Chromium Blog の記事 "Expanding user protections on the web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は TensorFlow チーム による Google Developers Blog の記事 "Announcing TensorFlow r1.4" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

TensorFlow リリース 1.4 が公開されました。今回は、大きく変更されています。ここでは、たくさんのすばらしい新機能を紹介します。皆さんに気に入っていただけることを期待しています。

Keras

1.4 では、Keras が tf.contrib.keras を卒業し、コア パッケージ tf.keras に移行されました。Keras は、非常に人気のある機械学習フレームワークで、最小限の時間で、アイデアを実際に動く実装へと変えることができる高レベル API で構成されています。Keras は、Estimator API などの他の TensorFlow の中核機能にスムーズに組み込むことができます。tf.keras.estimator.model_to_estimator 関数を呼び出すと、実際に任意の Keras モデルから Estimator を直接構築できます。Keras が TensorFlow コアの一部となったので、本番環境のワークフローでも安心して利用いただくことができます。

Keras を使ってみたい方は、以下をお読みください。

• 簡単な導入
• Keras Sequential モデル API ガイド
• Keras Functional モデル API ガイド

Estimator を使ってみたい方は、以下をお読みください。

• TensorFlow の Estimator と Dataset を紹介したブログ投稿

Dataset

Dataset API が（tf.contrib.data を卒業し）コアパッケージ tf.data に移行されました。Dataset API のバージョン 1.4 では、Python ジェネレータがサポートされています。以下の理由から、TensorFlow モデルの入力パイプラインを作成する場合には Dataset API を使うことを強く推奨します。

• Dataset API には、古い API（feed_dict やキューベースのパイプライン）よりも多くの機能があります。
• Dataset API はパフォーマンスが改善されています。
• Dataset API の方が簡潔で簡単に利用できます。

私たちの開発では今後、古い API よりも Dataset API に主眼が置かれます。

Dataset を使ってみたい方は、以下をお読みください。

• TensorFlow の Estimator と Dataset を紹介したブログ投稿
• TensorFlow プログラマー ガイドのデータのインポートの章
• Dataset API を紹介したフォロー用プレゼンテーション（メモ付き）

Estimator の分散トレーニングと分散評価

リリース 1.4 には、Estimator モデルのトレーニング、評価、エクスポートを簡単に行うユーティリティ関数 tf.estimator.train_and_evaluate も導入されています。この関数を使うと、トレーニングや評価の分散実行が可能になります。ローカル実行も引き続きサポートされています。

その他の機能強化

今回お知らせした機能に加えて、1.4 には多くの追加機能が導入されています。詳しくは、リリースノートをご覧ください。

TensorFlow 1.4 のインストール

TensorFlow リリース 1.4 は、標準の pip インストールを使って入手できます。

# Note: the following command will overwrite any existing TensorFlow
# installation.
$ pip install --ignore-installed --upgrade tensorflow
# Use pip for Python 2.7
# Use pip3 instead of pip for Python 3.x

tensorflow.org のドキュメントも 1.4 にアップデートされています。

TensorFlow の拡張は、コントリビュータの皆さんに支えられています。TensorFlow の開発に貢献してくださった皆さん、本当にありがとうございました。ぜひコミュニティに参加し、GitHub のソースコードを発展させてコントリビュータの仲間入りをしてください。または、Stack Overflow の質問への回答にご協力ください。

今回のリリースの各機能を活用いただけることを楽しみにしています。

TensorFlow のコーディングをお楽しみください。


Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

この記事は プロジェクト マネージャー、Eric Mauskopf による Google Developers Blog の記事 "Resonance Audio: Multi-platform spatial audio at scale" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


人間は音によって、自分を取り巻く環境を理解し、他の人とコミュニケーションしたり、周りで何が起こっているのかを把握しています。忙しい都会の道を歩いているときでも、満員の音楽コンサートの最中でも、さまざまな方向からやってくる無数の音を聞くことができます。そのため、AR、VR、ゲーム、あるいは 360 度動画では、本当にそこにいるように感じられる高度な没入感を作り出すために、高音質のサウンドが必要になります。本日（*原文公開当時）、Resonance Audio と呼ばれる新しい空間オーディオ SDK がリリースされました。これは、Google の VR Audio SDK のテクノロジーに基づいており、モバイル プラットフォーム、PC プラットフォームを問わず、幅広く動作します。


Daydream および SteamVR 用の Audio Factory VR アプリで空間オーディオを体験

モバイルから PC まで対応したパフォーマンス

パフォーマンスに影響を与えることなく、VR、AR、ゲーム、動画の体験に質の高いダイナミックなオーディオ環境を提供するのはなかなか困難です。通常、オーディオに割り当てられる CPU リソースは少なく、モバイルでは特にそうです。そのため、複雑な環境を作る際に同時に利用できる高品質 3D 音源の数には制限があります。この SDK は、高次アンビソニックに基づく高度に最適化されたデジタル信号処理アルゴリズムを使い、モバイルでも音質に妥協することなく、数百個の同時 3D 音源を立体化します。さらに、Unity には、環境の音響特性と厳密に一致する非常にリアルなリバーブ効果を事前計算する新機能が追加されています。これによって、再生中の CPU 使用率を大幅に削減できます。
Unity で音響マテリアルを大聖堂に割り当て、ジオメトリベースのリバーブを使用

デベロッパーやサウンド デザイナーのためのマルチプラットフォーム サポート

お気に入りのオーディオ ミドルウェアやサウンド デザインツールにオーディオ ソリューションがシームレスに統合されていることはとても重要です。Resonance Audio は広く普及しているゲームエンジン、オーディオ エンジン、デジタル オーディオ ワークステーション（DAW）向けのクロスプラットフォーム SDK がリリースされています。それによってワークフローを効率化できるため、没入感のあるオーディオの作成に集中できます。この SDK は、Android、iOS、Windows、MacOS、Linux の各プラットフォームで動作し、Unity、Unreal Engine、FMOD、Wwise、DAW に統合できます。さらに、C/C++、Java、Objective-C、ウェブ用のネイティブ API も提供されています。マルチプラットフォームがサポートされているので、いったんサウンドをデザインすれば、一貫性のあるサウンドを含むプロジェクトを主要なモバイルおよび PC プラットフォームに対して簡単にデプロイできます。YouTube 動画や Resonance Audio SDK で開発したアプリ向けの空間オーディオを正確にモニタリングできる新しい DAW プラグインも作成されています。これを使えば、サウンド デザイナーは時間を節約できます。ウェブ デベロッパーは、Resonance Audio Web SDK を入手できます。これは、Web Audio API 経由で利用でき、主要なウェブブラウザ上で動作するオープンソースの SDK です。

YouTube 360 度動画や SDK で開発したアプリ用のオーディオをモニタリングするサウンド デザイナー向け DAW プラグイン

最新機能で複雑なサウンド環境をモデリング

Resonance Audio では、複雑なサウンド環境を正確にモデリングする強力なツールが提供されているので、基本的な立体音響化以上のことが可能です。この SDK を使うと、デベロッパーは音源から音波が伝播する方向を制御できます。たとえば、ギタリストの後ろに立っている場合、正面に立っている場合よりも音を小さくすることができます。さらに、ギターの方向を向くと、背中を向けているときよりも音を大きくすることができます。


SDK を使ってアコースティック ギターの音波の指向性を制御


また、音源がリスナーの頭に近づいた際に自動的に近接効果を適用する機能も実装しています。これによって、音源が耳に近い場合でも、距離を正確に認識できるようになります。さらに、音源の幅を指定して音源を拡散させることもできます。これによって、空間上の小さな 1 点から発される音から、音の壁までを再現できるようになります。さらに、Unity 内で直接サウンド デザインを立体的に録音してファイルに保存し、ゲームエンジンから YouTube 動画まで、アンビソニック サウンドフィールド再生がサポートされている場所ならどこでも利用できるようにするアンビソニック録音ツールもリリースされました。

最新の空間オーディオ テクノロジーを使って没入感のある質の高い音響環境を作ってみたい方は、デベロッパー サイトで Resonance Audio のドキュメントをご覧ください。ご感想は、GitHub からお知らせください。また、ソーシャル メディアで #ResonanceAudio を付けて皆さんの作品を共有してください。優れた作品については、私たちからもシェアいたします。

Reviewed by Hak Matsuda - Developer Relations Team