[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

この記事は Dave Burke、エンジニアリング部門副社長による Android Developers Blog の記事 "O-MG, the Developer Preview of Android O is here! " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


2008 年に始まってから、Android プロジェクトはアプリのデベロッパー、端末メーカー、そしてユーザーの皆さんという活発なエコシステムからすばらしいフィードバックをいただいています。最近は、早い段階でパートナーに対して広く成果を共有できるように、エンジニアリング プロセスの改善に積極的に取り組んでいます。

先日、次期 OS である Android O の最初の Developer Preview が公開されたことをお知らせします。いつものことですが、これはまだ初期段階なので、今後も多くの機能や安定化、パフォーマンス改善が行われる予定です。しかし、Android O は本日からご利用になれます :)

今後数か月間にわたり、アップデート版の Developer Preview がリリースされる予定です。さらに、5 月の Google I/O では、Android に関わるあらゆることを詳しく取り上げる予定です。それまでの間に新しい OS でアプリをテストし、試用した新機能のフィードバックをお寄せください。

O の新機能


Android O には、アプリで利用できるたくさんの新機能や API が導入されています。ここでは、最初の Developer Preview で試すことができるいくつかの機能を紹介します。

バックグラウンドの制限事項: これは Nougat から開発が始まった機能です。Android O では、ユーザーの電池消費量削減と端末のインタラクティブ性能の改善に主眼が置かれています。これを実現するために、アプリがバックグラウンドで行えることが自動的に制限されます。この制限は主に、暗黙的ブロードキャスト、バックグラウンド サービス、位置情報のアップデートの 3 つに適用されます。これによって、ユーザーの端末や電池に最低限の影響しか与えないアプリを作りやすくなります。バックグラウンドの制限事項は、Android における大きな変更点になります。そのため、すべてのデベロッパーがこの点について熟知しておく必要があります。詳細については、バックグラウンド実行の制限とバックグラウンド位置情報の制限のドキュメントをご覧ください。

通知チャンネル: Android O には、通知チャンネルも導入されています。これは、アプリで通知コンテンツのカテゴリを定義できるようにする新機能です。デベロッパーがチャンネルを使うと、さまざまな種類の通知をユーザーが細かく制御できるようになります。たとえば、ユーザーはアプリごとではなく、チャンネルごとに通知をブロックしたり、通知の動作を変更したりできます。

通知チャンネルによってカテゴリごとにアプリの通知を管理

Android O には、新たな通知の視覚効果やグループ化も追加されているため、メッセージの着信時や通知シェードの確認時に何が起きているかがわかりやすくなっています。

Autofill API: Android ユーザーは、さまざまなパスワード マネージャを使ってログイン情報などの繰り返し入力する必要がある情報を自動入力しています。この機能によって、簡単に新しいアプリの設定や取引ができます。今回、自動入力がプラットフォームでサポートされ、エコシステム全体でこのような作業がさらに簡単になります。ユーザーは、キーボード アプリを選ぶのと同じようにして、自動入力アプリを選択できます。自動入力アプリは、住所、ユーザー名、パスワードなどのユーザーデータを安全に保管します。また、自動入力に対応させたいアプリで Autofill サービスを実装するための新しい API が追加されています。

ハンドセット用 PIP と新しいウィンドウ機能: スマートフォンとタブレットでピクチャ イン ピクチャ（PIP）表示が可能になるため、ユーザーは動画を見ながらチャットに応答したり、車を手配したりすることができます。PiP モードがサポートされているシステムのアプリは、再開または一時停止の状態から PiP モードを開始できます。PiP モードでは、アスペクト比や一連のカスタム操作（再生 / 一時停止など）が可能です。他に、アプリでシステムのアラート ウィンドウの代わりに使える新しいアプリ オーバーレイ ウィンドウや、リモート ディスプレイでアクティビティを起動できるマルチディスプレイ サポートなどのウィンドウ機能も追加されています。

XML フォント リソース: フォントは、リソースタイプとして Android O で完全にサポートされるようになります。XML レイアウトでフォントを使えるようになるほか、フォント ファイルとスタイルやウェイトを宣言することによって XML でフォント ファミリーを定義することもできるようになります。

アダプティブ アイコン: 端末の UI との一貫性を向上するため、アダプティブ アイコンを作成できるようになります。これは、端末が選ぶマスクを使って、システムごとに異なる形のアイコンを表示する機能です。さらに、アイコンとのインタラクションがアニメーションで表示されます。アダプティブ アイコンは、ランチャー、ショートカット、設定、共有ダイアログ、オーバービュー画面で利用できます。

端末モデルごとに異なる図形を表示するアダプティブ アイコン

広色域アプリ: Android のイメージング アプリのデベロッパーは、広色域ディスプレイを搭載した新しい端末の機能を活用できるようになります。広色域イメージを表示するアプリは、マニフェストに（アクティビティごとに）フラグを設定し、埋め込み広色域プロファイル（AdobeRGB、Pro Photo RGB、DCI-P3 など）を使ってビットマップを読み込む必要があります。

ネットワーク接続: オーディオの再現性を極限まで高めるため、Android O では LDAC コーデックなどの高品質 Bluetooth オーディオ コーデックがサポートされています。さらに、Wi-Fi Aware などの新しい Wi-Fi 機能も追加されています。これは、かつて Neighbor Awareness Networking（NAN）と呼ばれていた機能です。この機能によって、インターネット アクセス ポイントがなくても、適切なハードウェアを搭載した端末のアプリであれば、Wi-Fi 経由で近くの端末を検出して通信できるようになります。Google は Wi-Fi Aware テクノロジーを可能な限り多くの端末に導入するために、ハードウェア パートナーと連携して作業を進めています。

ConnectionService API は拡張されて Telecom フレームワークになっており、サードパーティの通話アプリのシステム UI との統合や、別のオーディオ アプリとのシームレスな連携が可能になっています。たとえば通話アプリは、車のヘッドユニットなど、さまざまな種類の UI で通話の表示や制御が可能です。

キーボード ナビゲーション: Chrome OS などの大きなフォーム ファクタでの Google Play アプリの登場と合わせて、これらのアプリで使われているキーボード ナビゲーションが復活します。Android O では、デベロッパーとエンドユーザーの双方に役立ち、信頼性が高く予測しやすい「矢印」や「タブ」のナビゲーション モデルの構築を目指しています。

プロ品質のオーディオを実現する AAudio API: AAudio は、高パフォーマンス、低レイテンシ オーディオを必要とするアプリに特化して設計された新たなネイティブ API です。AAudio を使用するアプリは、ストリームを使ってデータを読み書きします。今回の Developer Preview では、フィードバックをいただくために、この新しい API の初期バージョンをリリースします。

WebView の機能強化: Android Nougat では、オプションで WebView のマルチプロセス モードが導入されました。これは、ウェブ コンテンツの制御を独立したプロセスで行うものでした。Android O では、アプリのセキュリティと安定性を向上させるために、デフォルトでマルチプロセス モードを有効にし、アプリでエラーとクラッシュを制御するための API を追加します。また、その他のセキュリティ対策として、アプリの WebView オブジェクトで Google セーフ ブラウジングによる URL の確認が行えるようになっています。

Java 8 言語 API とランタイム最適化: 新しい java.time API などのいくつかの新しい Java 言語 API が Android でサポートされます。さらに、Android ランタイムが高速化されており、アプリのベンチマークによっては、最大 2 倍早くなっています。

パートナーによるプラットフォームへの貢献: ハードウェア メーカーや半導体関連のパートナーも、Android プラットフォームの O リリースに関連する修正や機能追加を行っています。たとえば、Sony は LDAC コーデックなどの 30 以上の機能拡張や、Android O の 250 のバグの修正に貢献しています。

対応を開始するためのシンプルな数ステップ


まず、ユーザーがシームレスに Android O に移行できるようにアプリの互換性対応を行います。端末のシステム イメージかエミュレータのシステム イメージをダウンロードして現在のアプリをインストールし、テストします。アプリは正しく表示、実行され、動作の変更点に問題なく対処できている必要があります。必要なアップデートを終えた後は、アプリのプラットフォームのターゲットを変更せず、すぐに Google Play で公開することをおすすめします。

Android O を使用してビルドする


準備ができたら、アプリで活用できる機能について学習するため、O について詳しく理解します。プレビュー タイムライン、動作の変更点、新しい API、サポートされるリソースなどの詳細を O Developer Preview サイトでご確認ください。

バックグラウンドの制限事項やその他の変更点にどのようにアプリを対応させるか、計画を立てます。通知チャンネル、PIP、アダプティブ アイコン、XML フォント リソース、TextView の自動サイズ変更や、その他の新機能を試してみてください。Android O の新しい API を簡単に試せるように、Android O API リファレンスと合わせて API の差分レポートがオンラインで公開されています。

最新の Canary 版 Android Studio 2.4 には、Android O を試してみるための新機能が追加されています。O プレビュー SDK は Android Studio 内でダウンロードとセットアップが可能です。Layout Editor を使って Android O の XML フォント リソースやTextView の自動サイズ変更をお試しください。今後の Android O のサポートにもご期待ください。

アルファ版の 26.0.0 サポート ライブラリも試用できるようになっています。このバージョンでは、たくさんの新しい API が追加されており、minSdkversion も 14 に上がっています。詳細は、リリースノートをご覧ください。

プレビューのアップデート


O Developer Preview には、アップデートされた SDK のほか、公式 Android Emulator、Nexus 5X、Nexus 6P、Nexus Player、Pixel、Pixel XL、Pixel C の各端末でテストするためのシステム イメージが含まれています。ウェアラブル向けにビルドする場合は、Android O で Android Wear 2.0 をテストするためのエミュレータを使うことができます。

プレビュー システム イメージと SDK は、O Developer Preview の期間中、定期的にアップデートされる予定です。このプレビューの第 1 弾リリースは、デベロッパーのみを対象としています。日常的な使用やユーザーの使用を想定したものではありません。そのため、手動でのダウンロードと書き込みでのみ利用できます。ダウンロードと手順は、こちらをご覧ください。

完成に近づいたら、ユーザーも招待してテストしていただく予定です。その際には、Android ベータ版への登録もオープンしますので、ご期待ください。なお、現在のところ、Android ベータ版では、Android O は利用できない点に注意してください。

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


いつものように、皆さんのフィードバックは重要です。お気づきの点はぜひお知らせください。早めにお知らせいただければより多くのフィードバックを反映できます。問題を見つけた場合は、こちらから報告をお願いします。今までよりも安定した Issue Tracker ツールに移行しています。このツールは、製品開発時に Google 内部でもバグの追跡や機能リクエストに使われています。その使いやすさをぜひ実感してみてください。



Posted by Yuichi Araki - Developer Relations Team

この記事は Mike McDonald、プロダクト マネージャーによる The Firebase Blog の記事 "Multiplying the Power of Firebase Storage" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Mike McDonald

Mike McDonald
Product Manager


Firebase Storage は、安全で堅牢かつ拡張可能なファイル ストレージです。うれしいことに、Google I/O 2016 で最初にリリースされて以来、デベロッパーの皆さんにモバイルアプリで多く活用されています。バケットを作成したデベロッパーはすでに数十万人に達しており、日々数億回の写真、動画、オーディオなどのリッチメディアのリクエストに対応しています。

しかし、Firebase Storage はまだ完成しているわけではありません。アプリのコンテンツを簡単かつ高速に格納、共有できるようにするには、まだいくつかの機能が必要です。

プロジェクトで複数のバケットを使用する

I/O '16 でのリリース以降、Firebase プロジェクトにつき 1 つのバケットしか持つことはできず、バケットも米国にしかありませんでした。Google Cloud Next '17 での発表と合わせて、Blaze 料金プランが選択されている Firebase プロジェクトでは、Google Cloud Storage がサポートしている任意の地域とストレージ クラスのバケットを作成できるようになりました。その結果、次のような強力なユースケースにも対応できます。
  • データの種類（例: ユーザーデータとデベロッパー データ）に応じて論理的にデータを分割する 
  • ユーザーに近い場所にデータを格納することで、パフォーマンスの最適化やコンプライアンス規制に対応する 
  • 頻繁にアクセスしないデータ（例: バックアップ）を別のストレージ クラスに格納し、費用を削減する
Firebase コンソールでは、新しいバケットを簡単に作成できます。場所とストレージ クラスを選択して、覚えやすい名前を付けるだけです！



プロジェクトに既存のバケットをリンクする

すべての Firebase プロジェクトは Google Cloud Platform プロジェクトでもあります。そのため、Firebase SDK for Cloud Storage では、既存の Cloud Storage バケットを直接かつ簡単に使用できます。そのためコストの高いデータ移行を行わなくても、モバイルアプリやウェブアプリからバケット内のデータにアクセスできます。既存のアプリに Firebase を導入するアプリにとって、便利な機能です。

既存のバケットを Firebase にリンクする操作は、新しいバケットの作成よりも簡単です。インポートしたいバケットを選択し、アクセスを許可するようにセキュリティ ルールを設定するだけで、アプリからバケットを利用できるようになります。




Google Cloud Functions との統合

Google Cloud Next '17 では、Cloud Functions for Firebase も発表されました。これによって、デベロッパーはクラウドまたは Firebase 機能で発生したイベントに応答するコードを書けるようになります。Cloud Storage for Firebase はこの機能との親和性が高く、ストレージ バケットに対するファイルのアップロードや変更、削除をトリガーにしてコードを実行できます。この強力なメカニズムを使うと、デベロッパーはデータ ストレージの上に新しい機能を簡単に作成できます。たとえば、 イメージ変換、サムネイル生成、Google Cloud Vision API を使ったイメージの無害化、メタデータの抽出などを自動で行うことが可能です。従来は、これらのタスクを実現するにはカスタム バックエンドを維持する必要がありましたが、コマンドライン 1 つでコードをデプロイできる Cloud Functions を使って簡単に自動化できるようになりました。

機能はそのままに、名称が変更

新機能の追加や Cloud Storage との統合に伴い、Firebase Storage は Cloud Storage for Firebase として生まれ変わったことをお知らせします。ここで特に強調しておきたいのは、Firebase Storage は Google Cloud Storage であり、Firebase を使用すれば、Google のインフラのスケールとパフォーマンスを最大限に活用した、モバイルやウェブのデベロッパーに最適な SDK を簡単に使用できるという事実です。

既存の Firebase SDK for Cloud Storage は、iOS、Android、JavaScript、C++、Unity で引き続き利用でき、データが Snapchat、Spotify、Google フォトなどを支えているインフラに格納されます。そして、Cloud Functions や自分のサーバーからデータにアクセスしたい場合には、いつでも Cloud Storage サーバー SDK を使ってアクセスできます。

この拡張された Cloud Storage for Firebase は、きっと皆さんに気に入っていただけるはずです。今後、これを活用してアプリを作成される際には、ぜひ Twitter、Facebook、Slack、Google Group のいずれかで状況をお知らせください。皆さんのアプリのリリースを楽しみにしています。


Posted by Khanh LeViet - Developer Relations Team

この記事は Brendan Lim、プロダクト マネージャー による The Firebase Blog の記事 "Introducing Cloud Functions for Firebase" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Brendan Lim


Brendan Lim
Product Manager
Firebase は、アプリの大半はクライアント コードで構築できるという前提で開発されています。多くの場合、その方が簡単で高速だからです。しかし、中にはサーバーのコードが必要な場合もあります。たとえば、信頼されたコードの実行、サードパーティ API の認証、電池を消耗する重い操作の実行などです。こういった例では、自前でサーバーを用意する必要がありました。しかし、それも今日までのことです。

本日（*原文公開当時）は、Cloud Functions for Firebase のベータ版がリリースされたことをお知らせします。これは、JavaScript を記述して Google のクラウド インフラにデプロイすると、Firebase エコシステム全体で発生する各種イベントをトリガーにコードを実行できる機能です。この機能については、Firebase のリリース以降、もっとも多くのリクエストが寄せられていました。Cloud Functions を使って Firebase 機能を拡張し、相互に接続することで、Firebase はさらに強力になり、デベロッパーはサーバーのことを考えずに一層アプリに集中できるようになります。

Cloud Functions は、モバイルアプリの構築に役立つ柔軟なツールです。今回リリースされたこの機能では多くのタスクを実装することができます。そのうちいくつかを紹介しましょう。
 Firebase Analytics と組み合わせると、特定のコンバージョン イベントが発生した際に、コードを呼び出すことができます。これによって、クライアントのコードをアップデートしなくても、モバイルアプリの拡大や定着に関するワークフローを自動化する機能を作成できます。
Firebase Authentication と組み合わせると、ユーザーの新規登録や削除が発生した際に、コードを呼び出すことができます。
Firebase Realtime Database と組み合わせると、データベースの特定のパスでデータが作成、更新、削除された際に、コードを呼び出すことができます。
Cloud Storage と組み合わせると、特定のストレージ バケットに対する書き込み、更新、削除があった際に、コードを呼び出すことができます。
HTTP エンドポイントと組み合わせると、ウェブフックとして使える URL を Cloud Function に提供できます。独自の一意で安全な URL に対してリクエストが発行された際に、コードが実行されます。
今後、さらに多くの機能の統合を予定しています。

「Cloud Functions for Firebase のアーリーテストを行いましたが、あまりに簡単に Realtime Database からデータをエクスポートして別のサービスと連携させることができるので、驚きました」
- Sony のマスター アーキテクト、Erling Mårtensson 氏

Firebase SDK とツール
Google Cloud Functions を土台として作られている Cloud Functions for Firebase は、Firebase デベロッパーに最大級の満足度を提供します。Cloud Functions は、安全なマネージド Node.js 環境で実行される単一目的の JavaScript 関数です。Firebase SDK for Cloud Functions では、イベントソース（Firebase Realtime Database での特定の場所への書き込みなど）を選択し、それに一致したイベントが発生するたびに実行される関数を実装できる API が提供されています。SDK では、コード補完と初期段階での構文エラーの検出に対応した TypeScript も使うことができます。
SDK は Firebase CLI とも連携して動作し、シームレスな関数のデプロイを実現しています。この密接な統合によって、1 つのコマンドですべての関数をデプロイできます。
価格設定 Cloud Functions は、無料枠も含めたすべての Firebase の料金プランで利用できます。無料枠を使って、他の Firebase 製品との統合を簡単に試していただくことができます。Blaze プランでは、従量制の課金となります。Blaze プランのお客様には、月単位での Cloud Functions の無料枠も設定されています。

「Cloud Functions for Firebase では、アプリが成長してもスケーリングについて心配することなく、バックエンドのメンテナンスやアップグレードにもさほど費用がかかりません。そのおかげで、（今のところ）私しか社員がいない会社を作ることができました。これはもう奇跡のようなものです」

- Wuu 創立者/CEO、Paul Budnitz 氏

今すぐ Cloud Function を作成してデプロイしてみる
Cloud Function を使ってみるのは簡単です。初めての Cloud Function の設定については、コードラボで手順をご覧ください。詳細については、完全なドキュメントをご覧いただくこともできます。
皆さんのアプリのリリースを楽しみにしています。


Posted by Khanh LeViet - Developer Relations Team

この記事は Alexander Timin、ソフトウェア エンジニア兼節電担当による Chromium Blog の記事 "Reducing power consumption for background tabs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

効率的な電源消費は、スピードの重要な要素であり、Chrome の重要な柱の 1 つでもあります。電池の寿命を延ばすには、Chrome でユーザーに見えない部分の電源消費量を最低限にとどめる必要があります。その中には、PC 版の Chrome の電源消費量の 3 分の 1 を占めるバックグラウンド タブも含まれています。バージョン 57 以降の Chrome では、大量に電源を消費しているバックグラウンド タブに対するタイマー イベントの発行数を抑えることにより、個々のバックグラウンド タブの電源消費量を抑えています。

Chrome は、長年にわたり、タブのパフォーマンスを制限することによるユーザー エクスペリエンスの改善に重点的に取り組んできました。多くのブラウザと同様、Chrome もバックグラウンドでのタイマーを 1 秒に 1 回だけに制限しています。Chrome 57 では、新しいスロットリングポリシーに従い、アプリケーションがバックグラウンドで大量の CPU を消費している場合の平均 CPU 負荷がコアの 1% となるようにタイマーを遅延させます。オーディオを再生しているタブ、WebSocket や WebRTC などのリアルタイム接続を維持しているタブは、この影響を受けません。

このスロットリングメカニズムによって、バックグラウンド タブの負荷が 25% 軽減されています。長期的には、バックグラウンドでの動作は Service Worker 用の新しい API で行い、バックグラウンド タブは完全に停止させることが理想的です。Chrome はこの理想に向かって、現在デベロッパーが構築できる使い心地を維持しながら、ユーザーの電池の寿命を延ばせるように取り組んでいきます。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Zhenyao Mo、ソフトウェア エンジニアによる Chromium Blog の記事 "Faster 3D rendering with WebGL 2.0" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

WebGL JavaScript API は、ハードウェア アクセラレーションによる 3D グラフィックをウェブの世界にもたらします。Chrome 56 では WebGL 2.0 がサポートされます。API は大幅にアップグレードされ、さまざまなグラフィックの新機能や、高度なレンダリング技術が追加されています。現在、WebGL 2.0 は最新のグラフィック ハードウェアを搭載した Windows、macOS、Linux の Chrome ユーザーが利用できます。近日中に Android にも対応する予定です。


Screen Shot 2017-03-15 at 3.12.13 PM.png
WebGL 2.0 トランスフォーム フィードバック デモ（ライブリンク、Github レポジトリ）

WebGL 1.0 は 6 年前に初めて Chrome で導入され、ウェブ 開発者はプラグインを使わずに没入感のあるグラフィックを作成できるようになりました。たとえば、リアルタイムでワールドカップのプレイをリミックスしたり、ニュース記事でロック クライミングのルートを視覚化したりできるようになりました。WebGL 2.0 では、リアルタイム レンダリングの高速化、新たなタイプのテクスチャとシェーダー、ビデオメモリの消費量の削減などが導入されており、3D ウェブ アプリケーションをさらに簡単に構築できるようになっています。遅延シェーディング、トーン マッピング、ボリューム効果、パーティクル効果などのテクニックも効率的に実装されています。 新しい API は、WebGL にモバイルゲームでよく使われているグラフィック プラットフォームである OpenGL ES 3.0 に匹敵する機能をもたらしています。

新しいレンダリング機能に加えて、WebGL 2.0 ではテストスイートへの準拠が大幅に向上しています。テストケースは 34 万件以上あり、さまざまなウェブブラウザが確実に互換性のあるグラフィック プラットフォームを提供できます。Chrome は複数の GPU ベンダーのすべてのデスクトップ プラットフォームで、これらのテストケースに 100% 合格しています。そのため、WebGL 2.0 実装には安定性と一貫性があることが保証されています。

WebGL 2.0 を使ってみるには、WebGL 2.0 サンプルパックをご覧ください。これには、小さな自己完結型の最新 API 機能サンプルも含まれています。実際に動作する WebGL 2.0 は、After the Flood1 でもご覧いただけます。これは、PlayCanvas と Mozilla が共同で作成したインタラクティブ デモです。OpenGL ES 3.1 のサポートや、Vulkan、Metal、DirectX 12 といった新しい明示的グラフィック インターフェースをサポートした低レベルウェブ グラフィック API など、今後のグラフィック機能に関するニュースについては、本サイトのお知らせにご期待ください。

[1] お使いのマシンでこのデモを含む WebGL 2.0 コンテンツが実行できない場合、グラフィック ハードウェアまたはドライバのアップデートが必要かもしれません。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Bernhard Grill、Megan Ruthven、Xin Zhao、セキュリティ ソフトウェア エンジニアによる Android Developers Blog の記事 "Detecting and eliminating Chamois, a fraud botnet on Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は、さまざまな端末や環境のユーザーを保護するための努力を続けています。その一環として、潜在的に有害なアプリ（PHA）からのユーザーの保護があります。この取り組みにより、Google のエコシステムを狙ったさまざまな種類の脅威を観察する機会があります。 たとえば、セキュリティ チームは最近、Chamois と名付けた新たな PHA ファミリーを検出し、広告および Android システムのユーザーをその脅威から保護しています。

Chamois は、以下のような機能を持つ Android の PHA ファミリーです。
  • 広告内に誤解を招くグラフィックを表示するポップアップを悪用した無効なトラフィックの生成 
  • バックグラウンドで自動的にアプリをインストールすることによる作為的なアプリのプロモーション  
  • プレミアム テキスト メッセージの送信による電話詐欺   
  • 追加プラグインのダウンロードと実行

広告エコシステムの妨害

Chamois は、通常の広告トラフィックの品質評価を行っている際に発見されました。Chamois に基づく悪意のあるアプリを分析したところ、いくつかの方法を使って検知を避け、誤解を招くグラフィックを表示させて広告をクリックさせようとしていることがわかりました。その結果、SMS 詐欺を行う別のアプリがダウンロードされることがあります。そのため、有害なアプリへの対策方法を使って Chamois アプリ ファミリーをブロックし、広告システムを操作しようとしていた攻撃者を排除しました。

以前にもこのような広告詐欺アプリに対応したことがあったため、広告主や Android ユーザーを守るための処置を迅速に行うことができました。悪意のあるアプリは端末のアプリ一覧には表示されないので、ほとんどのユーザーは迷惑なアプリを見ることもアンインストールすることもできません。そのため、ユーザーが PHA を発見して削除するために役立つ有害なアプリへの対策方法がとても重要になります。

Chamois の仕組み

Chamois は、現在 Android で知られている PHA ファミリーの中でも最大級のもので、複数のチャンネルで配布されています。私たちが知る限り、Google が最初に Chamois を正式に検知してトラッキングしました。
Chamois には、以下のような他にはない多数の特徴があります。
  • 多段ペイロード: Chamois のコードは、次の図に示すように、それぞれ異なるファイル形式を利用して 4 段階で実行されます。

このような多段階にまたがるプロセスを持っているので、悪意のある部分にたどりつく前にそれぞれの層をはがしてゆく必要が生じ、この種のアプリをただちに PHA として特定するのが難しくなっています。しかし、Google のパイプラインはこういったシナリオに適切に対処できるよう設計されているので、このようなトリックに欺かれることはありません。
  • 自己防衛: Chamois は難読化や分析回避技術を使って検知を避けようとしていますが、Google のシステムはそれに対抗して適切にアプリを検知します。
  • 暗号化されたカスタム ストレージ: このファミリーは、設定ファイルや追加コードに暗号化されたカスタム ファイル ストレージを使うため、PHA を詳しく把握するためには、細かい分析が必要になります。
  • サイズ: セキュリティ チームは、プロのデベロッパーによるものと思われる 10 万行以上の洗練されたコードを分析しました。APK のサイズがかなり大きいことから、Chamois を詳細に把握できるまでにしばらく時間がかかりました。

PHA に対抗する Google のアプローチ

アプリの確認は、PHA であると判断されたアプリがダウンロードされたときに警告を行うことによって、ユーザーを既知の PHA から守り、そのようなアプリがすでにインストールされている場合は、それをアンインストールできるようにします。また、アプリの確認は Android エコシステムの状態を監視し、異常が見つかるとその調査を行います。さらに、端末の動作を分析して、未知の PHA の検出をサポートします。たとえば、Chamois がダウンロードしたアプリの多くは、DOI スコアラーで高いランクが付けられています。私たちは、Herole の脅威からユーザーを守ることができるように、アプリの確認のルールを設定しています。
Google は今後も、Android やその広告システムの不正対策技術に大規模な投資を続けていきます。Chamois のような PHA に対抗するために水面下で働いている多くのチームは私たちの誇りです。

本記事が、ますます複雑化している Android ボットネットに対する洞察の一助となれば幸いです。Google の PHA への対抗策についての知識をさらに深めれば、ユーザー、端末、広告システムの脅威を減らすことにつながります。詳しくは、まもなく公開される「2016 年 Android セキュリティ総括」レポートをご覧ください。



Posted by Takeshi Hagikura - Developer Relations Team

2017 年 4 月 4 日（火）、Chrome Tech Talk Night #10 を開催します。今回はプログレッシブ ウェブアプリ ("Progressive Web Apps") の名付け親でもある Alex Russell をはじめ、Jake Archibald、Surma の来日に合わせ、Service Worker や HTTP/2 に関するイベントを行います。


  • Surma: "HTTP/2" 😂
  • Jake Archibald: Streams and Service Workers
  • Alex Russell: Real World PWA Performance
なお、今回のイベントに通訳は付きません。すべての講演は英語であることを予めご了承の上ご参加下さい。

イベント概要

名称：Chrome Tech Talk Night #10
日時：2017 年 4 月 4 日（火） 19:00 - 21:00 （受付 18:30 〜 19:30）
　　　※ 終了後、懇親会（軽食付き）を行う予定です。
場所：グーグル株式会社 六本木オフィス
　　　東京都港区六本木 6-10-1 六本木ヒルズ 森タワー
会費：無料
定員：100 名
主催：グーグル合同会社
ハッシュタグ： #chromejp

申し込み方法

参加を希望される方は以下のフォームよりお申込みをお願いします。
https://goo.gl/forms/1zLTK5sg8509ti7E3

プログラム

18:30 受付開始
19:00 - 21:00 セッション
21:00 - 22:00 懇親会

内容は変更になる可能性がございます。予めご了承ください。
皆様のご参加をお待ちしております。


Posted by Eiji Kitamura - Developer Relations Team

この記事は James Lau、プロダクト マネージャによる Android Developers Blog の記事 "Future of Java 8 Language Feature Support on Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
 Google は、いつも正しいことをしようとしています。ときにそれは計画の変更を意味することもあります。私たちは、Android デベロッパー コミュニティが Java 8 言語機能のサポートについて気にしていることを認識しており、そのサポート方法を変更する予定です。

このたび、Java 8 言語機能のサポートが現在の javac と dx ツールセットに直接追加されることとなり、Jack ツールチェーンのサポートは終了することが決まりました。この新しい方向性によって、Java クラスファイル形式に依存する既存のツールやプラグインは今後も継続して動作します。今後、Java 8 言語機能は Android ビルドシステムでネイティブにサポートされる予定です。この機能は、今後数週間のうちに Android Studio の一部として公開される予定ですが、この決定を早めに皆さんにお伝えしたいと思います。

当初、私たちは、Jack ツールチェーン経由での Java 8 サポートの追加をテストしていました。しかしやがて、アノテーション プロセッサやバイトコード アナライザ、それによって影響を受ける部分の書き直しを検討したとき、コミュニティにとって Jack への切り替えコストが高すぎることがわかりました。Jack ツールチェーンを試してすばらしいフィードバックをお送りくださった皆様、どうもありがとうございました。Jack による Java 8 コードのビルドは、新しいサポートがリリースされるまで継続して利用できます。Jack からの移行は、作業不要か軽微な作業で済む予定です。

この新しい計画によって道がスムーズになり、誰もが Android で Java 8 言語機能を使うメリットを感じられるようになることを願っています。Android Studio で新たなサポートがリリースされる際には、詳細をお知らせいたします。



Posted by Yuichi Araki - Developer Relations Team

この記事は David Bieber、Google Brain ソフトウェア エンジニアによる Google Developers Blog の記事 "Introducing Python Fire, a library for automatically generating command line interfaces" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

元の記事は Google オープンソース ブログに投稿されました。

今回は、Python Fire のオープンソース化についてお知らせします。Python Fire は、あらゆる Python コードからコマンドライン インターフェース（CLI）を生成します。Python プログラムから Fire 関数を呼び出すだけで、自動的にそのプログラムが CLI に変換されます。このライブラリは、「pip install fire」を実行することで pypi からインストールできます。ソースは GitHub で公開されています。

Python Fire は、自動的にコードを CLI に変換しますので、CLI を定義するコードを書く必要がありません。引数の定義も、ヘルプ情報の設定も、コードの実行方法を定義するメイン関数も不要です。単にメイン モジュールから「Fire」関数を呼び出せば、後のことは Python Fire が行ってくれます。Python Fire は、インスペクションを利用して、クラス、オブジェクト、ディクショナリ、関数、モジュール全体など、指定された Python オブジェクトをコマンドライン インターフェースに変換します。変換後の CLI には、タブ補完機能やドキュメントも付属しており、コードが変更された場合はそれに応じて CLI も更新されます。

簡単な実例を見てみましょう。
#!/usr/bin/env python
import fire
class Example(object):
 def hello(self, name='world'):
   """Says hello to the specified name."""
   return 'Hello {name}!'.format(name=name)
def main():
 fire.Fire(Example)
if __name__ == '__main__':
 main()

Fire 関数の実行により、コマンドが実行されます。Fire を呼び出すだけで、Example クラスをコマンドライン ユーティリティのように使えるようになります。

 $ ./example.py hello
Hello world!
$ ./example.py hello David
Hello David!
$ ./example.py hello --name=Google
Hello Google!


もちろん、このモジュールは通常の Python ライブラリとして使うこともできるので、Bash と Python の両方からまったく同じコードを使うことができます。Python ライブラリを書いている際に Python Fire を使うと、コマンドラインから対象ライブラリの一部を実行して簡単に実験できるようになるので、メインメソッドやクライアントをアップデートする必要がなくなります。また、ライブラリを変更すると、それに応じてコマンドライン ツールも更新されます。

Google のエンジニアは、Python Fire を使って Python ライブラリからコマンドライン ツールを生成しています。たとえば、Fire と Python Imaging Library（PIL）を使って構築したイメージ操作ツールがあります。Google Brain では、Fire で構築した実験管理ツールが使われており、Python からでも Bash からでも同じように実験を管理できるようになっています。

Fire によって生成される CLI はインタラクティブモードにも対応しています。CLI に「--interactive」フラグをつけて実行するとコマンドの結果とともに IPython の REPL が起動し、その他の便利な定義済み変数をすぐに使用できます。詳細および Fire が提供するその他の便利な機能については、Python Fire のドキュメントをご覧ください。

強力でシンプル、かつ汎用性の高い Python Fire が皆さんのプロジェクトに役立つライブラリになることを期待しています。

Posted by Ian Lewis, Developer Advocate, Google Cloud

この記事は James Tamplin、プロダクト マネージャーによる The Firebase Blog の記事 "Working Closer with Google Cloud Platform" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

James Tamplin


James Tamplin
Product Manager


昨年の Google I/O では、Firebase が拡張されて Google のモバイルアプリ開発プラットフォームになりました。それ以来、すばらしいデベロッパー コミュニティによって 100 万件以上の Firebase プロジェクトが作成されています。

これほど多くの方の信頼を得てご利用いただいていることは、私たちにとって大きな喜びです。Firebase はアプリの作成と拡大をサポートする完全なスイート製品ですが、現在すぐに使える機能以上のものを必要としているアプリがあることも認識しています。そこで今回、スタートアップから大規模なエンタープライズまでの要求の厳しいアプリに対応するため、Firebase の Google Cloud Platform（GCP）とのより密な連携を実現しました。

製品の統合

すでに Firebase は GCP と同じアカウントと課金システムを利用しているため、Firebase サービスを GCP プロジェクトに接続したり、その逆が可能です。この組み合わせによって、たとえば Firebase Analytics のイベントデータをそのまま BigQuery にエクスポートしてアドホックな分析を行うなどの強力な連携が実現します。

さらに本日（*原文公開当時）より、他の製品の連携も可能になりました。そのひとつが、サーバーレスでアプリ機能の拡張を実現する Cloud Functions for Firebase です。これは本日ベータ版として公開されたイベントドリブン型のサーバレスコンピューティング環境 Cloud Functions と Firebase によるインフラの共有を実現するもので、Cloud と Firebase それぞれの各種機能の呼び出しやリソースにアクセスできます。詳しくは Firebase ブログと Cloud ブログのお知らせをご覧ください。

次に、Firebase Storage と Cloud Storage の連携を強化しました。Firebase Storage は 10 か月前にリリースされた機能で、端末と Cloud Storage の間で直接ファイルのアップロードやダウンロードを簡単に行えます。今までの Firebase Storage には、ファイルを格納するためのバケットが 1 つあるだけでした。本日より、この 2 つの製品は完全に連携するようになり、地域やストレージ クラスを問わず、どの Cloud Storage バケットでも自由に使用できます。かつ、すべての操作を Firebase SDK から直接実行できます。この連携に伴い、製品の名称も Cloud Storage for Firebase に変更されます。詳しくはブログ投稿をご覧ください。

Firebase は、今後も iOS、ウェブ、Android の各 SDK を使用した、クライアントから GCP インフラへの直接アクセスを提供する予定です。さらなる製品の統合にご期待ください。

利用規約の改定

また今回、GCP の利用規約を拡大し、いくつかの Firebase 製品を対象としました。これにより Firebase と Cloud を合わせて簡単に評価できるようになります。新しい規約に含まれる製品は、Authentication、Hosting、Storage、Functions、Test Lab です。改定された利用規約は近日中に適用が開始されます。

全体像

Firebase は、Google の主力ビジネスである AdMob や AdWords などの広告ソリューションから、Firebase Analytics として提供される本格的な分析機能に至るまで、Google のトップクラスの各種サービスをモバイルに集約したものです。さらに Google Cloud Platform を組み合わせることで、Google がおよそ 20 年にわたって世界規模のコンピューティング インフラを運用する中で培ってきた知識を活用できます。

使いやすさに優れた Firebase と、幅広い領域をカバーする GCP インフラを組み合わせ、ソフトウェアスタックの上から下までを網羅するサービスを提供します。例えばスタートアップ企業では、Firebase の利便性を活かしてマーケットに速やかに参入し、さらにそのままフル機能を備えたパブリック クラウドへとスケールアップできます。すでに GCP でビジネスを運営し、モバイルアプリの導入を考える皆さんも、Firebase のモバイル機能のメリットが得られます。

Firebase と Google Cloud Platform を組み合わせた皆さんのアプリが今後数多くリリースされることを楽しみにしています。

Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

[この記事は David Besbris、Google 検索担当副社長兼 Google AMP Project リーダーによる Accelerated Mobile Pages Project の記事 "AMP grows its footprint" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 ]

現在、ニュースサイトでの AMP ファミリーの利用が国際的に拡大しており、アジア太平洋地域最大の検索エンジンが、10 億人以上の対象端末に向けて新しく AMP ページの配信を始める予定です。

これは、ニューヨークで行われた初めての AMP デベロッパー カンファレンスの初日に、中国の検索市場の約 90% を占める Baidu と Sogou によって発表されました。さらに、Yahoo Japan も検索結果に AMP ページを組み込むことを発表しており、日本で 1 日あたり 5,800 万人のユーザーが AMP を利用できるようになります。

このオープンソース プロジェクトは、誰もがモバイルウェブを快適に使えるようにするという共通の目的のもと、数社のサイトオーナーやテクノロジー企業が集結して 2015 年 10 月に始まりました。今回、これらの主要な配信プラットフォームが加わることは、プロジェクトにとって大きな一歩となります。

Bing や Pinterest、さらに Google や LinkedIn といった多彩な企業が AMP をサポートしています。その数は拡大を続けており、今回、Baidu、Sogou、Yahoo Japan が加わります。AMP 対応の記事は、未対応の記事と比べて滞在時間が 10% 増加しています。ニュース フィードにとって、滞在時間はもっとも重要な指標です。 サイトオーナーやウェブサイトにとっての AMP の価値は、それぞれのプラットフォームをまったくカスタマイズする必要がなく、一度 AMP ページを作れば、サポートされるすべてのプラットフォームで動作を続けることです。AMP の採用が拡大していることこそ、その価値を実証するものです。

あらゆる主要な CMS システムが積極的に AMP をサポートしているので、AMP ページの構築は今までになく簡単になっています。 これからの 2 日間（訳註：記事公開当時はAMP Conf 2017の当日でした）で、Relay Media や Postlight などのいくつかのテクノロジー インテグレータ企業の話を聞くことができます。ソリューションをゼロから構築したり、数日から数週間という規模で既存のウェブ アーカイブを移行する場合に役立つでしょう。

このエコシステム全体によって、社内のテクノロジー リソースが常に利用できるとは限らない小規模なサイトオーナーやウェブサイトでも、簡単に AMP ページを作成、発行できます。 たとえば、すでに数多くのサイトを AMP 化し、今後数週間でさらに 3 億以上のブログの移行を検討している Tumblr の例があげられます。

ニュース関連のサイトオーナーの多くは、継続的に新しい AMP ページを作成していますが、世界中の e コマース、旅行、レシピなどの多様なウェブサイトでも AMP の採用が進んでおり、日々新しいサイトが追加されています。 e コマース企業の中でいち早く本番環境に AMP を導入したのが eBay です。eBay は、カンファレンスでデベロッパーを対象に、AMP に賭けた理由、その活用術や利用のコツ、その途上で生まれた新たな指標などについて説明する予定です。 同様に、インド有数の小売企業 SnapDeal も AMP を全面的に採用し、1 日当たりの注文数が 52% 増加しています。

AMP では、サイトオーナーやウェブサイト向けに多くの収益化オプションも提供されています。これには、ネイティブ広告からアナリティクス トラッキング、さらに最近 Cloudflare が開始した AMP 広告の検証と最適化サービスまで、さまざまなものがあります。

さらに私たちは、AMP フレームワークを広告にも適用し、広告の高速化、軽量化、セキュリティ強化も行っています。 最近 AMP ファミリーに加わったばかりのネイティブ広告仲介業者 Triplelift は、AMP 広告を使って、従来よりも 3 倍軽く、6 倍高速に読み込める広告を配信しています。さらに、AMP 広告は視認性もはるかに優れており、CTR と eCPM が 13% 改善しています。その他のケーススタディは、こちらからご覧ください。

今回初めて行われる AMP カンファレンスの中核にあるのは、コミュニティです。 GitHub では 1 万人近くのデベロッパーが開発にあたっており、数百人がバグを報告し、さまざまな企業の 300 人以上のユーザーがコードに貢献しています。 その誰もが AMP を改善する役割の一翼を担っています。これは、協調作業を行うことによって、AMP があらゆる可能性に応えるモバイルウェブを実現できることを実証するものです。

このイベントが、今後も継続していくことを願っています。 実際に足を運べない方もご安心ください。こちらから、ライブ ストリーミングをご覧いただくことができます。



（訳註：AMP Conf 2017における発表の録画はYouTubeの公式チャンネルに公開されています。）

Posted by Yoshifumi Yamaguchi - Developer Relations Team

この記事は Danielle Chang、広告トラフィック品質管理チームによる の記事 "Understanding account suspensions due to invalid traffic" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日の投稿では、無効なトラフィックが原因で AdMob アカウントが停止される問題について説明します。

無効なトラフィックによる問題が発生するアカウントの傾向として、次の 2 種類のパブリッシャーのアカウントが挙げられます。1 つ目は、意図せずに無効なトラフィックをアカウントに送信したパブリッシャーです。一般的には、本番の広告でテストを行った可能性が考えられます。これについては、Google のポリシーとプロセスの透過性が向上したことによって、意図しない違反が減り、パブリッシャーがルールに従いやすくなることを期待しています。2 つ目は、意図的にルールを無視し、作為的に広告収入を増加させようとしてさまざまな無効なトラフィックの問題を発生させているパブリッシャーです。私たちはパブリッシャー、広告主、ユーザーのために、ポリシーに従ったエコシステムを維持すべく努力しています。ルールに従っていただくことは、ビジネスの拡大をお手伝いする上で不可欠です。

アカウントの停止については、多くの質問をいただいています。アカウントを良好な状態に保つためのプロセスやステップに関するよくある質問について説明します。

無効なトラフィックとは何ですか？
無効なトラフィックには、広告主の費用やパブリッシャーの収益を作為的に増加させる可能性があるすべてのクリック数や表示回数が含まれます。無効なトラフィックは、意図的に作られた不正なトラフィックと意図しないクリックの両方を指します。

Google 広告のクリックは純粋にユーザーの関心によるものでなければならず、作為的にクリック数や表示回数を上げようとするあらゆる行為はプログラム ポリシーによって固く禁じられています。広告主やユーザーを保護するため、高いレベルで無効なトラフィックが検出されたアカウントは、停止または無効化される場合があります。

アカウントの停止とは何ですか？
無効なトラフィックが原因でアカウントが停止されると、すべてのコンテンツに対して一定期間（もっとも頻繁に発生するのは 30 日間）広告の提供が停止されます。これには、すべてのウェブサイト、YouTube チャンネル、モバイルアプリが含まれます。妥当な場合はアカウントから収益が差し引かれ、広告主への払い戻しが行われます。アカウントでそれ以上コンプライアンスの問題が発生していない場合は、一定期間が過ぎると、アカウントは自動的に再有効化されます。

アカウントが停止された場合でも、アカウントはまだ有効です。アカウントの停止はアカウントの無効化とは異なることに注意してください。無効なトラフィックが原因でアカウントが無効化されると、そのアカウントでは広告を配信できなくなり、Google 広告ソリューションによる収益化はできなくなります。アカウントの停止と同様に、妥当な場合はアカウントから収益が差し引かれ、広告主への払い戻しが行われます。

無効なトラフィックが原因で停止されたアカウントや無効化されたアカウントについての詳細は、ヘルプセンターをご覧ください。

なぜ私のアカウントは停止されたのですか？
ポリシー違反の監視と合わせて、作為的に広告主の費用やサイトオーナーの収益を上げるものではないかを判断するため、すべてのクリック数や表示回数は分析されています。アカウントで無効なトラフィックが発生していると判断された場合、アカウントは停止または無効化されます。無効なトラフィックが検知された場合、アカウントから収益が差し引かれ、広告主への払い戻しが行われる可能性があります。

アカウントが停止される主な理由は、次のとおりです。
  • 自分のアプリの広告をクリックした場合: 手動を含め、パブリッシャーが自分の広告をクリックしたり、他の方法で表示回数やクリック数を作為的に増加させたりすることは禁止されています。自分の広告をクリックしてテストすることは、許可されていません。AdMob 広告の配置を行う場合は、テスト広告（Android、iOS で利用可能）を利用して無効なトラフィックを発生させないようにします。
  • 1 人以上のユーザーが何度も広告をクリックした場合: 友人、家族、同僚、一般ユーザーなどに広告のクリックを依頼してはいけません。これには、アプリのユーザーに対する協力依頼、広告をクリックしたユーザーへの報償、このような行為に対する第三者への金銭の提供などが含まれます。

アカウントの停止についての詳細は、関連する AdMob メールをご覧いただくことをおすすめします。

停止期間中は何をすればよいですか？
アカウントの停止中の時間を使って無効なトラフィックの発生源を調査し、疑わしいトラフィックを特定してブロックし、クリーンなトラフィックが保証されるように対策を講じます。アプリのトラフィックを把握、監視、評価するには、Firebase Analytics がおすすめです。これは無効なトラフィックの発生源の特定にも役立つでしょう。

無効なトラフィックが原因で停止されたアカウントについての詳細は、ヘルプセンターをご覧ください。

アカウントの停止に対して異議を申し立てるにはどうすればよいですか？
現在のところ、アカウントの停止に対して異議を申し立てることはできません。

この期間にトラフィックの発生源を調査し、今後無効なトラフィックが発生しないようにしてください。アカウントでそれ以上コンプライアンスの問題が発生していない場合、停止期間が経過すると、アカウントは自動的に復旧します。

無効なトラフィックに対する異議申し立てフォームは使用しないでください。このフォームは、無効化されたアカウント用であるため、対応不可を知らせるメールが届きます。

このプロセスやコミュニケーションを改善するためにフィードバックを送りたい場合は、停止されたパブリッシャー用のフィードバック フォームをご利用ください。

アカウントはいつ再有効化されますか？
アカウントでそれ以上コンプライアンスの問題が発生していない場合、一定期間（多くの場合 30 日間）が過ぎると、アカウントは自動的に再有効化されます。

アカウントの再有効化以降も無効なトラフィックを生成し続けるとどうなりますか？
アカウントの再有効化以降も無効なトラフィックが発生し、広告エコシステムにとって価値の低いトラフィックが続く場合、アカウントが無効化される場合があります。

無効なトラフィックが原因で停止されたアカウントについての詳細は、ヘルプセンターをご覧ください。停止が解除されたら、適切な状態で AdMob ネットワークに復帰していただくことをお待ちしています。


Posted by Rikako Katayama - AdMob Team

この記事は Zac Campbell、AdMob パブリッシャー品質チームによる の記事 "Preloading Interstitial Ads" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日は、AdMob ポリシーに準拠しつつ AdMob インタースティシャル広告フォーマットを使う方法について考えてみましょう。「誤ったクリックを誘発するレイアウト - インタースティシャル広告」というようなポリシー メッセージを受け取ったことがある方や、指定したタイミングでインタースティシャル広告をうまく表示させられないという方は、ぜひ本投稿のベスト プラクティスをお読みください。

誤ったクリックを誘発するアプリのレイアウトは、サイトオーナーに関わるポリシーの問題の中でも特によく起こる問題の 1 つです。モバイルアプリでインタースティシャル広告を実装する場合、ユーザーが操作を選んでから広告が表示されるまで、わずかな遅延が発生する場合があります。次に示すのは、遅延の関係で 2 番目のページが読み込まれてから意図せずインタースティシャル広告が表示される例です。この遅延は、インタースティシャル広告をリクエストする際の携帯通信会社による通信の待ち時間などで発生する場合があります。

携帯通信会社による通信の待ち時間が引き起こすインタースティシャル広告の遅延

インタースティシャル広告をプリロードしておくと、ユーザーに広告を表示されるまでの待ち時間がなくなります。
修正した例は次のようになります。ユーザーが移動ボタンをクリックすると、その操作を行った際に即座にインタースティシャル広告が表示されます。ユーザーがインタースティシャル広告を閉じると、次に読み込まれたページが表示されます。

操作が行われると同時にインタースティシャル広告を表示できるようにプリロード

インタースティシャル広告のプリロード方法の詳細は、Android および iOS アプリのデベロッパー向け AdMob インタースティシャル広告デベロッパー ガイドをご覧ください。

こういった広告を適切に実装することは、ユーザー、広告主、そしてデベロッパーの皆さんすべてのためになります。AdMob ポリシーは、優れたユーザー エクスペリエンスを生み出すためのものです。AdMob インタースティシャル広告についてのその他の推奨事項やベスト プラクティスは、公式のベスト プラクティス動画をご覧ください。



Twitter や LinkedIn、Google+ でお届けする AdMob の最新情報もご覧ください。


Posted by Rikako Katayama - AdMob Team

[この記事は Daniel An、Google モバイル部門のグローバル プロダクト リーダーによる Accelerated Mobile Pages Project の記事 "New Industry Benchmarks for Mobile Page Speed – Accelerated Mobile Pages Project" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

以下は、Google モバイル部門のグローバル プロダクト リーダー、Daniel An による Think with Google の記事からの抜粋です。

最近の分析結果によると、モバイルのランディング ページが完全に読み込まれるまでの平均時間は 22 秒です。しかし、読み込みに 3 秒以上かかるページからは 53% のモバイルサイト訪問者が離れています。これは大きな問題です。

買い物客が高速なモバイルページを期待していることは疑いようもありません。時間がかかりすぎると、買い物客はカートに入れた商品を放棄してサイトを離れていきます。現在は、あらゆる業界において、体感速度の速いウェブサイトをデザインすることが急務となっています。金融機関のサイトで料金を支払ったり、バカンスのレビューを確認したり、商品の紹介記事を読む際、ユーザーはクリックして即座に反応が返ってくるサイトを期待しています。

しかし、ウェブのトラフィックの半分以上はモバイルからのものであるにもかかわらず、モバイルのコンバージョン率はデスクトップよりも低くなっていることが私たちのデータから判明しています。つまり、スピードは収益に直結しているのです。

私たちが行った調査から驚くべき事実が明らかになりました。スクロールせずに見える範囲のコンテンツが表示されるまでに 7 秒近くかかり、見えない部分も含めたすべてのコンテンツが読み込まれるまでに 10 秒以上かかるページが調査したページのうち 70% もあったのです。

最近、私たちは直帰率とコンバージョン データを大量に使って、ある深層ニューラル ネットワーク（人間の脳や神経システムをモデルにしたコンピュータ システム）のトレーニングを行いました。このニューラル ネットの予測精度は 90% に達していて、このシステムの予測では、ページの読み込み時間が 1 秒から 7 秒に増えると、モバイルサイト訪問者の直帰率が 113% 増加するという結果が出ています。同様に、ページの要素（テキスト、タイトル、イメージ）の数が 400 から 6,000 に増えると、コンバージョン率が 95% 低下することも明らかになっています。
think-w-google
参照元: Google/SOASTA Research、2017 年

本研究の詳細については、Think with Google で完全版の記事をご覧ください。

AMP Project を活用すれば、端末や配布プラットフォームを問わず、一貫して高速で美しく、パフォーマンスも高いウェブサイトや広告を作成することができで、これらの指標の改善に役立てることができます。詳しくは、AMPproject.org をご覧ください。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Vamsee Jasti、AMP Project プロダクト マネージャーによる Accelerated Mobile Pages Project の記事 "Grow Your Business with Ads on AMP – Accelerated Mobile Pages Project" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

 ビジネスにはどれ 1 つとして同じものはありませんが、現在のモバイル主導社会におけるすべてのビジネスに共通するのは、あらゆる端末で高速なユーザー エクスペリエンスを保証する必要があることです。拡大を続ける AMP エコシステムが非常に重要なものであると私たちが確信しているのはそのためです。今までよりも高速、安全で優れたオープンウェブを目指して協調するサイトオーナー、広告主、テクノロジー プラットフォームなどの多様なコミュニティを 1 つにまとめるのが AMP なのです。現在 AMP をサポートしているテクノロジー プラットフォームは 100 以上に及びます。あらゆる端末で高速なユーザー エクスペリエンスを提供することの重要性が広く認識されるにつれて、その数はさらに増え続けています。

私たちはまた、広告も多くのウェブビジネスにとって重要であることを認識しています。AMP コミュニティの多くのメンバーが、AMP ページを最大限に収益化する方法を知りたいと考えています。そこで本日は、AMP で広告を提供するためのガイドを共有したいと思います。このガイドは、各社それぞれの方法で AMP の導入を成功につなげることができるよう、さまざまなサイトオーナーのベスト プラクティスをまとめたものです。

そのようなサイトオーナーの代表として Hearst Communications が挙げられます。Hearst は現在までに 100 万以上の AMP ページを公開しており、その数は現在も増え続けています。その結果、Elle、Cosmopolitan、Chron.com など、さまざまな事業部門が運営するサイトで、視認性、広告のエンゲージメント率、ユーザーのトラフィックが大幅に向上しています。

Hearst の AMP は、ガイドで推奨されている多くのベスト プラクティスを実装したものです。Hearst は自社のビジネスニーズに合わせて AMP を有効に活用できるように、以下のステップで導入を進めました。

まず、実績ある収益化戦略を継承して AMP 非対応ページを AMP 対応ページに移行しました。次に、その戦略を AMP 向けに最適化し、その結果をもとに改善するということを繰り返しました。

さらに、Hearst は収益化の取り組みを補完するものとして 10 社以上の広告テクノロジー パートナーやアナリティクス パートナーのソリューションを導入しました。これらの成果と AMP ならではのスピードが相乗効果を生み出し、Hearst の AMP ページでは広告の視認性が 29%、CTR が 45% 増加しました。

通常のウェブページと同じく、AMP ページも単に公開するだけで成功が保証されるわけではありせん。ビジネスニーズやパートナーとの関係を十分に考慮して AMP を最適化することが重要になります。AMP のエコシステムは拡大を続けており、私たちもモバイルウェブを総合的に改善する取り組みを日々続けています。皆さんの成功事例を目の当たりにできることを楽しみにしています。

こちらの AMP ガイドに掲載されている広告を参考に、モバイルウェブのビジネスを拡大するために他のサイトオーナーがどのように AMP を活用しているかをご覧ください。

Hearst での AMP へのアプローチの詳細については、こちらから完全版の事例紹介をご覧ください。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

この記事は Google XLA チームおよび TensorFlow チームによる Google Developers Blog の記事 "XLA - TensorFlow, compiled" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

TensorFlow の設計目標であり、その大きなメリットのひとつが「柔軟性」です。TensorFlow は柔軟で拡張可能なシステムを目指して設計されており、任意のデータフロー グラフを定義して、それらのグラフをCPU や GPU などのさまざまな計算デバイスに分散させ、効率的に実行できるようになっています。

しかし多くの場合、柔軟性とパフォーマンスはトレードオフの関係にあります。TensorFlow はあらゆる種類のデータフロー グラフを定義できる手段を提供すべく設計されています。その一方で、個々の演算を個別に最適化しているため、すべてのグラフを効率的に実行するのは容易ではありません。ユーザーが必要とする演算の効率的な実装がすでに存在する場合や、全体と比べて個々の演算の負荷が高い場合は、特に問題はありません。しかしそうでない場合、ユーザーは低レベル演算を組み立てて必要な演算を合成する必要があり、場合によってはあまり効率的ではないケースもありました。

そこで Google では、TensorFlow コンパイラ XLA（Accelerated Linear Algebra）を開発しました。XLA は、ユーザーが作成した TensorFlow グラフを JIT コンパイル技術により実行時に分析します。ランタイムにおける実際の次元や型に応じて特化したグラフをを生成し、複数の演算をまとめて、CPU や GPU、カスタム アクセラレータ（Google の TPU など）などで効率的に実行できるバイナリコードを生成します。

合成可能な演算をまとめてパフォーマンスを改善

例として、tf.nn.softmax 演算を考えてみましょう。この演算では、パラメータの softmax 活性化が次のように計算されます。


softmax は、TensorFlow のプリミティブ演算（指数演算、リダクション演算、要素ごとの除算など）を合成して実装できます。

softmax = exp(logits) / reduce_sum(exp(logits), dim)
この計算には、余分なデータの移動や、実際には使われない結果の演算が行われるため、遅くなる可能性があります。さらに GPU のようなコプロセッサでは、こうした個別の演算により複数のカーネル起動が発生し、さらに演算が遅くなることもあります。

XLA はいわば TensorFlow における「隠し味」のようなコンパイラで、TensorFlow によるプリミティブ演算の合成を自動的に最適化します。XLA で強化された TensorFlow は、ランタイムのパフォーマンスを犠牲にすることなく柔軟性を維持しています。これは、グラフをランタイムで分析し、演算をまとめ、合成されたサブグラフに対して効率的なバイナリコードを生成して実現しています。

たとえば、前述の softmax を分解して計算する実装を XLA で最適化すると、手作業で最適化した合成演算と同じくらい高速になります。

さらに、XLA は TensorFlow の演算のサブグラフ全体を受け取って、最低限の数のカーネル起動しか必要としない効率的なループにまとめます。次に例を示します。




このグラフの演算の多くは、要素ごとのループにまとめて 1 個にすることができます。たとえば、matmul の結果に含まれる 1 個の要素を bias ベクトルの 1 個の要素に加算する場合を考えてみましょう。この加算の結果は 1 個の要素になり、（ReLU で）0 と比較することができます。この比較結果に対して指数演算を行い、すべての入力の指数の合計で除算すると、softmax の出力が得られます。しかし実際には matmul、加算、ReLU 用の一時的な配列をメモリに作成する必要はありません。

s[j] = softmax[j](ReLU(bias[j] + matmul_result[j]))

このようにしてまとめた実装では、不要なメモリ割り当てを行わずに、1 個にまとめられた要素ごとのループ内で最終結果を計算できます。さらに高度なシナリオでは、このような演算が行列の乗算にまとめられることもあります。

TensorFlow の柔軟性を維持しつつ、パフォーマンスへの懸念を払拭

チーム内でベンチマーク テストを行ったところ、XLA は従来の TensorFlow に比べて NVIDIA GPU 上で最大 50% のスピードアップを実現できました。事前の予想どおり、もっとも大きな高速化が達成されたのは、要素ごとの演算が長く続くモデルです。このようなモデルはより効率的なループにまとめられます。ただし XLA はまだ試験運用版であり、ベンチマークによってはスピードが低下する可能性もあります。



Chris Leary と Todd Wang による TensorFlow Developer Summit の講演では、TensorFlow で XLA、JIT、AOT などのコンパイル技術を活用し、実行時間を最低限に抑えつつ計算リソースを最大限に活用する方法が説明されています。

徹底した特化処理による実行サイズの削減

XLA は、パフォーマンスの改善だけでなく、実行サイズの削減機能も提供しているため、限られたメモリしか搭載されていない環境（モバイル端末など）向けの TensorFlow モデルにも有用です。tfcompile は、XLA を活用して事前コンパイル（AOT）を行うためのツールです。グラフ全体が XLA にコンパイルされた後、グラフ内の演算を実装するコンパクトなバイナリコードが生成されます。ランタイムを最小限にとどめる機能をこのスキームに組み合わせることで、バイナリのサイズを大幅に削減できます。

たとえば、android-arm で 3 層、60 ノード幅の LSTM スタック モデルを作成したところ、オリジナルの TF モデルのサイズは 2.6 MB（ランタイム 1 MB + グラフ 1.6 MB）でしたが、これを XLA でコンパイルすると 600 KB まで縮小されました。

高解像度イメージを表示するには、こちらをクリックしてください。


このサイズ削減は、静的コンパイルによるモデルの完全な特化によって実現されています。個々のモデルを実行する際には、TensorFlow ランタイムの処理能力と柔軟性をフルに維持する必要はありません。ユーザーが実際のグラフの実装で使いたい演算のみがバイナリコードにコンパイルされるからです。もっとも、XLA の CPU バックエンドが生成するコードのパフォーマンスはまだまだベストとは言えず、今後も引き続き改善していく予定です。

異なるバックエンドや装置のサポート

TensorFlow グラフを新たな種類の計算デバイスで実行するには、新しいデバイス用にすべての TensorFlow 演算（カーネル）を再実装する必要があります。デバイスによっては、これに膨大な作業が必要となります。

XLA では、カスタム バックエンドを追加することで簡単に新しいデバイスをサポートできます。TensorFlow は XLA をターゲットにできるので、新しいデバイスのバックエンドを XLA に追加すれば、そのデバイスで TensorFlow グラフを実行できます。前述のとおり、XLA は複雑な演算をプリミティブ演算に分解するため、XLA の演算はプリミティブ演算のみとなります。そのため、新しいデバイスのサポートに必要な作業ははるかに少なくなります。XLA にカスタム バックエンドを追加するプロセスの詳細は、こちらのページに記載されています。ちなみに Google 社内では、TPU をターゲットにするため、XLA のこのメカニズムを活用しています。

まとめと今後の展望

まだ開発の初期段階の XLA ですが、ユースケースによっては非常に大きな効果を発揮でき、TensorFlow が今後この技術から大きなメリットを得られることは明らかです。そこでGoogle では、XLA を TensorFlow の GitHub リポジトリ で先行リリースすることを決定しました。今後は開発者コミュニティからの開発支援も受けつつ、TensorFlow をさまざまな計算デバイス向けに最適化し、ランタイムとモデルを新しい種類のハードウェアで実行するための便利な基盤を提供していきたいと考えています。




Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

ストーブの前に座っている猫に触って火傷しました。
さて、Android 版 Google 日本語入力をアップデートしたことをお知らせします。

ダウンロード辞書の提供

Windows / macOS / ChromeOS 版で使われているフルサイズの辞書（約44 MB）を Android 版でも利用することができるようになりました。「単語リストのアップデートを有効にする」の設定をすると、電源に接続されかつ Wi-Fi が利用可能になったときにフルサイズ辞書がダウンロードされ利用可能になります。

ダウンロードした辞書を削除するには、設定を再度無効化します。



絵文字キーを追加

絵文字キーボードに直接アクセスするためのキーを新設しました。それに伴い、絵文字 / 記号キーボードの振る舞いをわかりやすいものにしました。

Android Wear 2.0 のサポート

先日発表された Android Wear 2.0 に対応しました。お手持ちの Android Wear 機器で、手書きと音声認識に加えソフトウェアキーボードでも日本語を入力できるようになります。



これからも、Google 日本語入力をよりよくしようと、チーム一同で開発を進めていきます。お気づきの点がありましたら、ぜひプロダクト フォーラムからお知らせください。みなさんのフィードバックがなによりの励みになります。


Posted by 松崎 剛士 （Software Engineer）

[この記事は Eric Lindley、プロジェクト マネージャーによる Accelerated Mobile Pages Project の記事 "Better galleries and forms in AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

ここしばらくの間に、AMP ライブラリに対していくつか細かな修正を行いました。これは細かいことではありますが、優れたユーザー エクスペリエンスを構築する上で大きな差を生むものです。

1 つ目の変更点は、新しい JavaScript メソッド（goToSlide）がサポートされ、ユーザーのタップやクリックで <amp-carousel> を特定のスライドに進めることができるようになったことです。これは、イメージ ギャラリーにおける UX の大幅な改善につながります。2 つ目の変更点は、<amp-selector> を使ってフォームにイメージ サムネイルを簡単に組み込めるようになったことです。これらは多くのデベロッパーにとってとても役立つ機能になると思われ、イメージを多用した報道や e コマースの商品ページといった形でユーザーに魅力的なコンテンツを提供することが可能になります。

goToSlide メソッドの使用: サムネイル付きカルーセル

これまで、<amp-carousel> ではイメージ ギャラリーのいくつかの重要な操作パターンがサポートされていませんでした。ユーザーはカルーセル内にあるイメージの数をどうすれば知ることができるでしょうか。カルーセル内に 8 つあるうち 5 番目のイメージに直接ジャンプしたい場合は、どうすればよいでしょうか。矢印アイコンに気づかない場合や、ページ内でアイコンが隠れている場合、ユーザーはカルーセルがスワイプ可能であることにどのようにして気づくでしょうか。

多くのデベロッパーやデザイナーは、ユーザーにイメージ サムネイルを提供することで、この問題を解決しています。サムネイルをタップした際に、指定したスライドまで自動的にカルーセルを進めるようにするのです。



goToSlide メソッドを使うと、この機能を AMP でも実現できます。ユーザーのタップ時にこのメソッドを呼び出すと、カルーセルを特定のスライドに進めることができます。

実装例 
<!-- Primary Carousel -->
<amp-carousel id="carousel-with-preview"
width="400"
height="300"
layout="responsive"
type="slides">
<amp-img src="https://example.com/path/to?image=10"
width="400"
height="300"
layout="responsive"
alt="a sample image"></amp-img>
<amp-img src="https://example.com/path/to?image=11"
width="400"
height="300"
layout="responsive"
alt="a sample image"></amp-img>
</amp-carousel>

<!-- Carousel thumbnails -->
<div class="carousel-preview">
<button on="tap:carousel-with-preview.goToSlide(index=0)">
<amp-img src="https://example.com/path/to?image=10"
width="60"
height="40"
layout="responsive"
alt="a sample image"></amp-img>
</button>
<button on="tap:carousel-with-preview.goToSlide(index=1)">
<amp-img src="https://example.com/path/to?image=11"
width="60"
height="40"
layout="responsive"
alt="a sample image"></amp-img>
</button>
</div>


たくさんのイメージがある場合は、スクロールできる小さなカルーセルにサムネイルを入れることもできます。

実装サンプルについては AMP by Example をご覧ください


このパターンは、ウェブの至る所で使われています。e コマースサイトの商品ページでは特に便利な機能です。

<amp-selector> の使用: フォーム+イメージ サムネイル
先ほどの 2 つの例は、ストーリーや臨場感のある体験にイメージが重要な役割を果たすユースケースに注目したものでしたが、ユーザーがフォームに値を入力するために選択肢を選ぶときにもイメージが役立つことがあります。<amp-selector> を使用すると、このようなマークアップを簡単に行え、意味合いに一貫性を持たせることができます。これにより、ユーザーはその状況における各選択肢の意味を理解しやすくなり、情報が伝わりやすく、魅力的で目的を達成しやすいサイトを実現できます。

実装サンプルについては AMP by Example をご覧ください 


試してみる
<amp-selector> と goToSlide メソッドを試してみるには、ドキュメント（goToSlide、<amp-selector>）を参照するか、AMP By Example（goToSlide、<amp-selector>）の実例をご覧ください。うまくできたことや、うまくできなかったことなどのフィードバックは、AMP GitHub レポジトリにお寄せください。皆様からのフィードバックをお待ちしています。



Posted by Yoshifumi Yamaguchi - Developer Relations Team