[この記事は Jason Douglas、Actions on Google 担当 PM ディレクターによる Google Developers Blog の記事 "Start building Actions on Google" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Assistant は、ナレッジグラフから自然言語処理に至るまで、長年積み上げてきたテクノロジーや知能を統合したものです。Assistant を効果的に活用するには、ユーザーの生活の中でさまざまなアプリやサービスをつなげることが必要になります。そのためには、デベロッパーが Google Assistant を通して多種多様なサービスをユーザーに提供するためのエコシステムを構築することがとても重要だと考えています。

10 月には、Google Assistant のデベロッパー プラットフォームである Actions on Google のプレビュー版を公開しました。Actions on Google を使うと、Assistant に独自のサービスを追加できるため、Assistant のユーザー体験をさらに向上させることができます。本日（*原文公開当時）より、Google ホームの会話アクションが開発できるようになりました。さらに、プラットフォームへのフィードバックを行う事が可能な、アーリーアクセスパートナーへの申し込みフォームも公開しました。

Google Home の会話アクション

会話アクションを活用すると、ユーザーに情報、サービス、サポートを提供できます。特徴的な部分としては、会話アクションを通じて本当に Assistant と会話ができることです。ユーザーには特殊な技術や、アプリをインストールする必要もありません。ただ話しかければよいだけです。現在、デベロッパーを対象に、何が実現可能かを説明する 2 つのサンプルが提供されています。「Ok Google, talk to Number Genie」と話しかけると、数当てゲームができます。または、「Ok Google, talk to Eliza」と話しかけると、1960 年代の傑作 AI と会話できます。


デベロッパー向けの Actions on Google ウェブサイトにアクセスすると、すぐに開発を始めることができます。スムーズで直感的な開発を実現するため、Google は会話インタラクション開発ツールの API.AI や Gupshup、アナリティクス ツールの DashBot や VoiceLabs、コンサルティング会社の Assist、Notify.IO、Witlingo、Spoken Layer など、さまざまな開発パートナーと連携してきました。また、一連のサンプルや音声ユーザー インターフェース（VUI）リソースも作成しています。今後数週間でリリースされる予定のアーリーアクセス パートナーによる統合アプリを試すこともできます。

Wayne Piekarski による会話アクションの紹介

近日公開: Pixel や Allo 向けのアクション、購入や予約への対応

この取り組みはまだ始まったばかりで、みなさんが開発される Google Assistant 向けアプリを見るのを楽しみにしています。今後も、プラットフォーム機能の追加は継続され、Pixel スマートフォンや Google Allo など、各種アシスタントで利用できる統合アプリを作れるようになります。購入や予約にも対応するだけでなく、業界を問わず、複雑なアシスタントとも連携していく予定です。今後公開されるこのような機能を利用してアクションを作ってみたいデベロッパーのみなさんは、ぜひアーリーアクセス パートナー プログラムに登録してください。ともにこのプラットフォームの将来を作り上げてゆきましょう。
さまざまな開発を試して、Actions on Google を使ってみた感想をお聞かせください。最新情報を入手するには、ニュースレターに登録し、Google+ コミュニティに参加してください。StackOverflow での質問には、「actions-on-google」タグをご利用ください。


Posted by Takuo Suzuki - Developer Relations Team

[この記事は Inside AdMob の記事 "The No-Nonsense Guide to Native Ads is now available in Spanish and Japanese" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

最近公開されたネイティブ実践ガイドにフィードバックをお寄せいただき、ありがとうございます。このたび、スペイン語版と日本語版のガイドが公開されました。

スペイン語と日本語のデベロッパー コミュニティの皆さんがネイティブ広告を実装する際に、この e ブックをご活用頂ければと思います。ネイティブ広告は、ユーザー エクスペリエンスを維持しつつ効率的な収益化を実現する広告フォーマットで、アプリ内のコンテンツに調和する外観や操作性を備えています。2018 年には、ネイティブ広告への投資額が 210 億ドルまで拡大するとみられており、アプリのオーナーにとって、ユーザー エクスペリエンスを向上させつつ新しい収益源を得る絶好の機会と言えます。

このガイドでは、次のことを学習できます。

• ネイティブ広告のよりよい実装に役立つデザイン原理 
• ネイティブ広告を実装するための実用的な推奨事項、ベスト プラクティス、サンプル 
• ネイティブ広告で A/B テストを適切に設定し、テストを始める方法 
• AdMob を利用してネイティブ広告を実装する方法 

早速、スペイン語版や日本語版の無償のネイティブ広告実践ガイドをダウンロードし、アプリでネイティブ広告を実装する実用的な推奨事項やベスト プラクティスについて学習しましょう。

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


Posted by Rikako Katayama - AdMob Team

[この記事は Jocelyn Becker、Android トレーニング担当シニア プログラム マネージャーによる Android Developers Blog の記事 "Updated Udacity Android course prepares students for the Associate Android Developer Certification" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

先日、Udacity コースの中でも特に人気の高い Developing Android Apps（Android アプリ開発）コースがアップデートされ、デベロッパーの皆さんが、より高品質なアプリをコースを学習する事を通じて開発できるようになりました。すでに 50 万人以上のデベロッパーがこのコースを受講し、Android アプリの開発方法を学んでいます。今回、そのコースのアップデートを行いました。

Google と Udacity が協力してコースのアップデートを行い、新しく Constraint Layout エディタや Firebase Job Dispatcher の使用方法など、Android や Android Studio の最新の変更点をカバーしました。このコースでは、Android 7.0（Nougat）で旧版との下位互換性を維持した Android アプリを構築するベスト プラクティスを学ぶことができます。学習はご自分のペースで進めることができます。

少し難しいレッスンもあるというフィードバックをいただきましたので、レッスンを再構成し、コースを進めながら作成する小規模のアプリを追加しました。そのため、コース全体で取り扱う統合アプリとして Sunshine 天気情報アプリを完成させるだけでなく、各レッスンごとにアプリを作成してそのレッスンのコンセプトを習得できる内容になっています。

ContentProvider の構築方法を学ぶ際は、To Do アプリを構築してタスクを追加します。


コースには、Google の Android エキスパートである Dan Galpin や Reto Meier、Udacity の Lyla Fujiwara が登場します。さらに、Google と Udacity から新たな講師も迎えています。
早速、https://www.udacity.com/course/ud851 で学習を始めてみてください。


Developing Android Apps コースと Associate Android Developer Certification 試験を組み合わせたパッケージ

アップデートされたコースでは、Associate Android Developer Certification（アソシエイト Android デベロッパー認定）試験に出題される内容も学習できます。Udacity は、アップデートされた Developing Android Apps コースと Associate Android Developer Certification 試験のバウチャーを組み合わせたパッケージも提供しています。試験に合格すれば Associate Android Developer Certification 資格を取得できるので、初心者レベルの Android デベロッパーが一般的に実行するタスクを十分こなせることを資格を通じてアピールする事も可能です。https://www.udacity.com/course/nd818 から Udacity の Fast Track に登録し、Associate Android Developer Certification 試験を受ける準備を始めましょう。





Posted by Takuo Suzuki - Developer Relations Team

[この記事は Eric Deily、デフォルトのカウボーイによる Chromium Blog の記事 "Roll-out plan for HTML5 by Default" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

4 か月前、安全で電力効率の良いブラウジングを実現するために、HTML5 のデフォルト化を進めていることをお知らせしました。念のために確認しておくと、この変更は、ユーザーが特定のサイトで Flash コンテンツを使用することを明示した場合を除き、Adobe Flash Player を無効化するものです。将来的には、Flash を実行するすべてのウェブサイトでユーザーのパーミッションが必要になります。移行はゆるやかに進められるため、すべてのユーザーやサイトがすぐに影響を受けることはありません。HTML5 のデフォルト化とそれに関連してユーザーにパーミッションを求める操作は、以下のように徐々に導入されます。

この機能は、今後数か月をかけて反映されます。HTML5 のデフォルト化は、今後数日中に Chrome 55 安定版の 1% のユーザーと、Chrome 56 ベータ版の 50% のユーザーで有効になります。2 月の Chrome 56 安定版では、すべてのユーザーに対して有効になる予定です。

1 月より、ユーザーがそれまでアクセスしたことのないサイトでは、サイトごとに Flash を実行するかどうかの確認が表示されます。過度に確認が表示されるのを避けるため、今後、サイト エンゲージメント指標を使用して制限を強化する予定です。この指標は、ブラウジング操作に基づきユーザーがサイトでどの程度操作を行っているかを示すヒューリスティックです。10 月には、すべてのサイトで Flash の実行にユーザーのパーミッションが必要になる予定です。

サイト エンゲージメント指標の特定のしきい値など、詳細については、Flash ロードマップ ページをご覧ください。Flash サイトのテスト方法に関するデベロッパー向けの推奨事項も、このサイトに掲載されています。Flash から HTML5 へのサイトの移行が進めば、この変更による影響はなくなり、ウェブ全体が高速化されて安全になり、電力効率も良くなります。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は Vincent Scheib、Web Bluetooth "歯科矯正医" による Chromium Blog の記事 "Chrome 56 Beta: “Not Secure” warning, Web Bluetooth, and CSS position: sticky" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、Mac、Windows 向けの最新の Chrome ベータ版に適用されます。

パスワードやクレジット カード情報を含む HTTP ページの「Not Secure」警告

ユーザーが安全にブラウジングできるように、Chrome はアドレスバーのアイコンに接続の安全性を表示しています。今までの Chrome では、HTTP 接続が安全でないことが明示的に表示されていませんでした。しかし、Chrome バージョン 56 より、パスワードやクレジット カードの情報を収集する HTTP ページは安全でないことが明示されます。これは、すべての HTTP サイトを安全でないものと明示する長期計画の一環です。この機能は、今後数週間で徐々に反映されます。

安全性に問題があると表示されないようにするには、サイトで HTTPS を使ってトラフィックを保護し、一般的なセキュリティ ガイドラインに従う必要があります。


HTTP 接続を行っているサイトで URL バーに表示される Chrome の「Not Secure」警告

Web Bluetooth

 ウェブサイト上で Web Bluetooth API を使った Bluetooth Low Energy（BLE）端末とのやりとりができるようになりました。この機能は、Android、 Chrome OS、Mac が対象です。Web Bluetooth API は、GATT プロトコルを使用します。このプロトコルを使うと、ウェブ デベロッパーは数行の JavaScript を書くだけでプリンターや LED ディスプレイなどの Bluetooth 端末に接続できます。Web Bluetooth と Physical Web ビーコンを組み合わせると、付近の端末を検出、操作できます。まずは、GitHub のサンプルやデモをご覧ください。


ウェブ経由で BLE 対応の心拍数モニターに接続している Android 端末（ソース）

CSS の position: sticky 対応

Chrome で要素を配置する新しい方法として、CSS の position: sticky がサポートされます。position: sticky が指定された要素は相対的に配置されますが、ユーザーが特定の位置までスクロールすると、position: fixed になります。



従来、通常どおりスクロールしてビューポートの一番上までくるとそこに固定されるコンテンツのヘッダーを作る場合、スクロール イベントをリッスンして指定されたしきい値で要素の position を relative から fixed に切り替える必要がありました。この方法では、要素を同期させるのが難しく、なめらかな動きは実現できませんでした。今後は、要素の position に sticky を指定するだけで、この効果を実現できます。

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

• Android の新しい Remote Playback API では、サイトがスマート TV やスピーカーの HTMLMediaElement の開始や再生の制御ができるようになりました。
• Android でオリジン トライアルとして WebVR API が利用できるようになり、デベロッパーがウェブ上でバーチャル リアリティを実現できるようになりました。
• デスクトップ プラットフォームで WebGL 2.0 API がデフォルトで有効になり、<canvas> 要素で OpenGL ES 3.0 レベルのレンダリング機能が利用できるようになりました。
• サイトでユーザーによる有効なインタラクションが発生していない場合、navigator.plugins と navigator.mimetypes で Adobe Flash のサポートがアドバタイズされなくなりました。ただし、ユーザーはサイト単位で Flash を再有効化できます。
• サイトで Image Capture オリジン トライアルを使って写真の撮影やズームなどのカメラの設定を試せるようになりました。
• ビューポートより上にあるコンテンツが変更された際に、Chrome はビューポートのコンテンツが動かないように自動的にスクロール位置を調整するようになります。ただし、CSS の overflow-anchor プロパティが設定されている場合を除きます。
• Notifications API で image プロパティを設定すると、サイトからの通知にイメージを含めることができるようになりました。
• Payment Request API に requestPayerName や JSON のシリアライズなど、いくつかの新機能が追加されました。
• モバイルで URL バーの表示 / 非表示を切り替えても、vh などのビューポート単位でサイズが指定された最初から内包されているブロックまたは要素のサイズが変わらなくなりました。
• 512 MB 以上のメモリとシステム辞書を搭載している Android 端末では、デフォルトで <input type="text"> などのテキスト入力要素のスペルチェックが有効になりました。
• すべてのプラットフォームで、UI 内のコンテンツをフィットさせるために使われる標準フォント ファミリーが標準化され、名前が system-ui に変更されました。
• 新しく追加された Referrer-Policy HTTP ヘッダーを指定したサイトは、ユーザーのセッション ID やその他の個人情報を漏洩させることなく、指定の URL にサイトのトラフィックを転送できます。
• KeyboardEvent.isComposing() を使うと、サイトで直接キーボード イベントを監視しなくても、ユーザーが直近の KeyboardEvents に基づくキーボード入力を行っているかどうかを判断できます。
• セルラー ネットワークに接続されている場合、Chrome for Android では metadata に動画のデフォルトの preload 属性が設定され、他のモバイル ブラウザと同様にプレビュー イメージと時間情報が表示されるようになりました。
• Chrome が TLS 1.3 をサポートするようになりました。ドラフト 18 ベースの 1-RTT も含まれます。
• サイトで ImageBitmapRenderingContext を使い、メモリ消費と ImageBitmap 形式でのピクセル データのレンダリングのオーバーヘッドを減らせるようになります。
• CSS の touch-action プロパティで pinch-zoom を使用すると、サイトでピンチ操作に応答できるようになります。
• ConstantSourceNode は、AudioParam とミキシングされた一定の出力を生成する新しいオーディオ ソースノードです。
• Web Audio の ChannelSplitterNode インターフェースで、2 つの新しい読み取り専用属性が使えるようになります。channelCount は、createChannelSplitter() の numberOfOutputs によって定義されます。
• PannerNode.rolloffFactor は、ソースがリスナーから離れる際のボリュームの減衰率を表現する PannerNode の距離モデルの公称範囲に固定されるようになります。
• ページが現在フォアグラウンドにない場合、window.prompt() で親タブにフォーカスが移らなくなりました。
• Windows での動作に合わせるため、Mac の Chrome 拡張機能は Chrome Settings Overrides API でデフォルトの検索、スタートアップ、ホームページ設定を上書きするようになりました。 
• FLAC のサポートが <audio> タグと decodeAudioData() の FLAC とOgg コンテナ内で有効化されました。
• WebAudio API のオーディオコーデックサポートを拡張し、decodeAudioData() で OPUS の利用が可能になりました。

サポートの終了予定と相互運用性の改善

• speedOfSound、dopplerFactor、setVelocity など、サポートを終了した Doppler API は WebAudio API に含まれなくなりました。
• 標準に準拠するため、RTCPeerConnection が RTCConfiguration パラメータとしてiceTransports だけでなく iceTransportPolicy も受け取れるようになりました。
• RTCPeerConnection が webkit 接頭辞なしに利用できるようになりました。webkitRTCPeerConnection も利用できます。
• 空白以外の Unicode 制御文字は、無視されるのではなく、仕様に従って描画されます。
• Content Security Policy 2 から reflected-xss ディレクティブが削除されています。これは X-XSS-Protection ヘッダーの単なるラッパーであり、何の追加機能も提供していないためです。
• MediaStreamTrack.getSources() メソッドのサポートが削除され、MediaDevices.enumerateDevices() に置き換えられました。
• CSP の referrer ディレクティブはサポートが終了し、新しい Referrer-Policy ヘッダーに置き換えられました。
• ShadowDOM の slotchange イベントは、slot の assignedSlot でバブリングされますが、再発行はされなくなりました。
• レガシー CBC モード ECDSA 暗号化スイートの ECDHE_ECDSA_WITH_AES_128_CBC_SHA と ECDHE_ECDSA_WITH_AES_256_CBC_SHA は削除され、ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 などの最新の暗号化に置き換えられました。
• SHA-1 と SHA-512 の ECDSA は削除されました。これは、SHA-1 への依存性を削除し、TLS 1.3 の新しい ECDSA ハンドリングと整合性をとるためです。
• Chrome では、touchstart や touchmove などのタッチ スクロール入力時にポップアップを表示できなくなりました。
• サイトは、type="python" などの無効な type または language 属性を持つスクリプトの取得を開始しなくなりました。ただし、link preload を使った宣言的な取得による場合は除きます。
• MIDIMessageEvent.receivedTime がサポート終了となり、Event.timeStamp に置き換えられました。これは、Event.timeStamp がエポック時刻の代わりに高精度のモノトニック時刻をサポートするようになったためです。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Doug Stevenson、Developer Advocate による The Firebase Blog の記事 "Firebase Crash Reporting Full Release" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Firebase Crash Reporting は、Google I/O 2016 でベータ版が公開されてから、急速に採用が拡大しています。Firebase Crash Reporting はこれまでに数億回のエラーを検出し、デベロッパーが優れたユーザー エクスペリエンスを実現するために役立っています。このたび正式に公開された Firebase Crash Reporting にはさまざまな新機能や機能強化が搭載されているため、iOS や Android のモバイルアプリのユーザーに影響を与えるクラッシュをより適切に診断し、対応できるようになります。この投稿では新機能を紹介しますので、ぜひご確認ください。

問題解決

とても多く寄せられたリクエストとして、ダッシュボードでエラークラスタを「クローズ」する機能があります。これは、その問題が修正済みで、次のリリースでは同じ種類のクラッシュは発生しないはずだということを識別するための機能です。将来のバージョンでクラッシュが再発した場合、クラッシュ クラスタが同じ状況に対して自動的に再オープンされます。



報告にかかる時間の短縮

クラッシュが報告されてコンソールに表示されるまでに約 20 分かかっていましたが、その時間が大幅に短縮され、1 分以内に表示されるようになりました。この改善のほか、メール アラートにより、エラー発生時の診断能力の向上が期待できます。

メール アラート

Firebase プロジェクトにアクセスできるデベロッパーは、新しいエラークラスタが検出されたり、クローズされたエラーが再発した場合に、メール アラートを受信するように設定できます。この情報を元にしてすばやくエラーに優先順位を付けて対応し、ユーザーへの影響を最小限に抑えることができます。



クラッシュログのアナリティクス イベント

クラッシュログに Firebase Analytics のイベントが追加されるようになりました。これによって、アプリがクラッシュに至った状況がわかりやすくなっています。詳しい状況が追加されたため、収益や重要なコンバージョン イベントにクラッシュがどのように影響するのかも確認できます。



モバイル フレンドリーなコンソール

モバイル端末でも使いやすいように、Crash Reporting のコンソールが改善されています。新たにレスポンシブ デザインが導入され、デスクトップ パソコンのそばにいなくても、簡単にアプリの状態をチェックできます。



Android SDK の互換性

Android SDK の最初のリリースには、Application クラスを宣言している一部のアプリでうまく動作しないという制限がありました。その制限が解消され、Firebase Crash Reporting はすべての Android アプリで問題なく動作するようになりました。

iOS の Swift サポートのアップデート

Swift 2 および 3 で書かれたアプリのシンボルが表示されるようにアップデートされています。

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

Firebase Crash Reporting を試した方は、ぜひ感想をお聞かせください。Crash Reporting などの Firebase 機能について質問がある方は、firebase-talk フォーラムを利用できます。プログラミングに関する質問は、Stack Overflow に firebase タグを付けてお問い合わせください。


Posted by Khanh LeViet - Developer Relations Team

[この記事は Wesley Chun（@wescpy）、G Suite デベロッパー アドボケートによる G Suite Developers Blog の記事 "Modifying email signatures with the Gmail API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

今年、Gmail API チームは、新しい設定機能を導入しました。本日（*原文公開当時）は、API を使って Gmail ユーザー設定をアップデートする方法をデベロッパーの皆さんに紹介しながら、その機能を説明します。

プライベートでも仕事でも、メールは依然として中心的なコミュニケーション手段であり続けています。メールの署名は簡単な自己紹介や名刺のような役割を果たしており、皆さんの個性を輝かせることができる場所でもあります。毎回 Gmail の設定インターフェースを使うのではなく、好きなときに自動的に署名を変更できたらすばらしいと思いませんか？最新の動画で取り上げているのは、まさにそのことです。


すでにアプリで Gmail API サービス エンドポイントを作成しており、それが変数 GMAIL に格納されているとしましょう。署名を変更したいメールアドレス YOUR_EMAIL と、新しい署名のテキストがあります。その場合、API から変更を行うのはとても簡単で、Python で次のようにして GMAIL.users().settings().sendAs().patch() メソッドを呼び出します。

signature = {'signature': '"I heart cats."  ~anonymous'}
GMAIL.users().settings().sendAs().patch(userId='me',
        sendAsEmail=YOUR_EMAIL, body=signature).execute()

上記のリクエストや動画で使われているコードサンプルの詳細については、さらに詳しく説明している投稿をご覧ください。API から変更できる設定は、メールの署名の他にも、フィルタ、転送（アドレスと自動転送）、外部メールへのアクセスを制御するための IMAP と POP の設定、不在通知などがあります。なお、API からはすべての G Suite Gmail アカウントのほとんどの設定にアクセスできますが、「エイリアスで送信」の変更や転送など、いくつかの重要な操作は、ドメインレベルの権限を持つユーザーに限られています。

設定ではなく、メールスレッドやメッセージに Gmail API からアクセスしてみたいデベロッパーの皆さんは、こちらの動画をご覧ください。ある件数以上のメッセージがあるスレッドを検索する方法、つまりメーリング リストで頻繁に議論されたトピックを探す方法を説明しています。 皆さん のユースケースにかかわらず、Gmail API の詳細は デベロッパー ドキュメントでご覧いただけます。API を初めて使う方は、まず概要ページをお読みください。進むべき方向がわかるはずです。

忘れずに Google Developers チャンネルを購読し、G Suite Dev Show 動画シリーズの他のエピソードもご確認ください。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Alex Fan、モバイル パートナーシップ事業開発エグゼクティブによる Inside AdMob の記事 "How Using Firebase Can Help You Earn More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

皆さんはデベロッパーとしてすばらしいアプリを構築していますか？アプリやユーザーの分析を強化して、ユーザー エクスペリエンスを損なわずに収益化したいとは思いませんか？そうお考えなら、ぜひお読みください。

先ほどの 2 つの問いへの答えは同時に実現できます。しかも、そのためのソリューションは既に存在しています。Firebase です。Firebase は、アプリの構築、ユーザーベースの理解と拡大、そして収益の増加につながる AdMob との連携をサポートします。



アプリの開発

Firebase では、アプリの開発をサポートする Realtime Database、Authentication、Cloud Messaging、Storage、Hosting、Crash Reporting が提供されています。もうインフラのことを心配する必要はありません。優れたアプリを構築することだけを考え、インフラの運用は Firebase にお任せください。

ユーザーの分析

Firebase の中核をなすのは、モバイルアプリに特化した 100% 無償のアナリティクス ソリューションです。最大 500 種類のイベントを無制限に報告できるので、ユーザーがアプリの中で何をしているのか、どのようにアプリを活用しているのか、アプリの何を一番気に入っているのかなど、さまざまな角度から正確に測定できます。このデータを活用すれば、アプリの最高の機能を掘り下げて維持しつつ、新たなニーズに対処するための改善に注力できます。

ユーザーの拡大

Firebase の強力なユーザー拡大機能によって、アプリを公開してからもユーザーを増加させ、ユーザーエンゲージメントを向上させることができます。Firebase Notifications コンソールを使うと、ユーザーのエンゲージメントを向上させたり、マーケティング キャンペーンを行ったり、Firebase Analytics のオーディエンスを対象にメッセージを送信したりできます。Dynamic Links は、まったく新しいユーザーでも長期間にわたるアプリのユーザーでも、アプリのインストール プロセスによって中断されることなくユーザーを関連コンテンツに導くことができます。さらに、Firebase Invites 機能もあります。これは、すぐにアプリをお勧めしたり共有するソリューションで、既存ユーザーはメールや SMS を通して簡単にアプリやアプリ内コンテンツを共有することができます。また、Firebase は AdWords 経由でのアプリインストールをトラックし、Firebase Analytics ダッシュボードにLTVをレポートします。特定のユーザー グループのエンゲージメントを上げるために、AdWords で Firebase のオーディエンスを使うこともできます。たとえば、AdWords でアプリ内イベントをコンバージョンとして定義し、自動的にユニバーサル アプリ キャンペーンなどの広告を最適化することができます。

製品の収益化

AdMob by Google と Firebase を組み合わせると、Firebase Analytics を活用してアプリを収益化できます。この 2 つの製品を組み合わせて使用状況データを細かく分析すると、その結果からユーザー エクスペリエンスを最適化することができ、アプリの収益化につながります。ユーザーがあるレベルを超えられない場合は、リワード動画広告を使ってサポートしましょう。1 日中コンテンツを見て回っているユーザーには、ネイティブ エクスプレス広告を使ってクールなアプリをお勧めしましょう。一部のヘビーなアプリ内課金ユーザーに広告を表示したくない場合は、Firebase でセグメントを作成し、広告の表示対象から除外しましょう。



詳しい情報

詳しくは上の動画をご覧ください。モバイル広告デベロッパー リレーションズの Andrew Brogden とデベロッパー アドボケートの David East が、AdMob と Firebase を組み合わせて利用するメリットや、Android プロジェクトと iOS プロジェクトで両方の SDK を設定する方法について説明しています。

Firebase と AdMob の真の力を探求してみませんか？Firebase アカウントと AdMob アカウントを登録し、2 つのアカウントをリンクさせてください。

Firebase に関する次回のブログは来週投稿する予定です。ユーザーの行動（Firebase のおかげで細かい分析が可能になっています）を分析して 5 つ星のレビューを増やす方法についてさらに深く掘り下げますので、ご期待ください。

次の投稿までの間、Twitter や LinkedIn、Google+ でお届けする AdMob no情報をご覧ください。


Posted by Rikako Katayama - AdMob Team

[この記事は Andrew Hayden、Google Play ソフトウェア エンジニアによる Android Developers Blog の記事 "Saving Data: Reducing the size of App Updates by 65%" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Android ユーザーは、Google Play で数百億のアプリやゲームをダウンロードしています。また、デベロッパーは頻繁にアプリをアップデートして、ユーザーにすばらしいコンテンツを提供したり、セキュリティを改善したり、ユーザー エクスペリエンス全般を向上させたりしています。こういったアップデートでは、多くのデータをダウンロードする必要があります。しかしユーザーは、端末で消費したデータ量を気にしています。Google は今年、bsdiff アルゴリズム（Colin Percival 氏が開発）の利用開始を発表しました。bsdiff の利用によって、アプリの完全な APK のサイズと比べると、アップデートのサイズを平均 47% 減らすことができました。

本日（*原文公開当時）は、さらにアップデートのサイズを削減する新たなアプローチをお知らせします。それは、ファイルごとのパッチ適用です。ファイルごとのパッチ適用によるアプリのアップデートでは、完全なアプリよりも平均 65% 小さくなり、場合によっては 90% 以上小さくなることもあります。

以前のアプローチと比較すると、なんと 1 日あたり最大 6 ペタバイトのユーザーデータを節約できることになります。

この方法では、アプリの新しいバージョンを入手する際に、Google Play から端末にアプリの旧版と新版との 差分 を記述したパッチが送信されます。

たとえば、まもなく出版される本の著者が 1 文だけ変更したいとします。全文を送り直すよりも、編集者にその変更内容を伝える方がはるかに簡単です。同じように、パッチを使うと APK 全体をダウンロードするよりもはるかにサイズが小さくなり、ダウンロード時間も短縮されます。

ファイルごとのパッチ適用で使われるテクニック

Android アプリは APK としてパッケージ化されています。APK は、特殊なルールに基づいた ZIP ファイルです。ZIP ファイル（と APK）の中にあるほとんどのコンテンツは、Deflate と呼ばれるテクノロジーを使って圧縮されています。Deflate はデータの圧縮には優れていますが、元の（圧縮されていない）コンテンツの変更点を特定するのが非常に難しくなるという欠点もあります。元のコンテンツをわずかに変更しただけでも（本の中の 1 語だけ変更するように）、Deflate が出力する圧縮データは まったく異なるものに見える場合があります。 元の コンテンツの差分を作るのは簡単でも、 圧縮された コンテンツの差分を作るのはとても難しいため、パッチは非効率になってしまいます。

左側の圧縮されていないテキストを 1 文字変更しただけで、右側の圧縮されたテキストがどのくらい変わるかをご覧ください。

そのため、ファイルごとのパッチは、圧縮されていないデータで検出された差分に基づきます。パッチの生成にあたって、まず古いファイルと新しいファイルの両方を解凍し、差分を計算します（ここでは、まだ bsdiff を利用しています）。次に、パッチを適用するため、古いファイルを解凍して圧縮されていないコンテンツに差分を適用し、新しいファイルを再圧縮します。その際に、端末上の APK が Play Store 上の APK とバイト単位で完全に一致していることを確認する必要があります（この理由については、APK 署名スキーマ v2 をご覧ください）。

新しいファイルの再圧縮には、2 つの問題があります。1 つ目の問題は、Deflate の設定によって Deflate の出力が色々と変わることです。そもそも、圧縮の際にどのような設定が使われたのかはわかりません。2 つ目は、Deflate には多くのバージョンが存在しており、ユーザーの端末上にある Deflate が適切なバージョンか確認する必要があります。

幸運にも、Play Store のアプリを分析したところ、Play Store のほぼすべての Deflate コンテンツで、zlib（もっとも普及している Deflate ライブラリ）に基づいた、互換性がある最近のバージョンの Deflate が使われていることがわかりました。さらに、実質的に使われている設定は、デフォルト（level=6）と最大（level=9）の圧縮設定だけでした。

以上のことを踏まえると、元々の Deflate 設定を検出して再現できると言えます。つまり、データを解凍し、パッチを適用してデータを再圧縮し、元々アップロードされたものと まったく同じバイト列 を作ることができます。

ただしこの方式には、端末側で必要な処理能力が高くなるという欠点もあります。最近（たとえば、2015 年以降）の端末では、再圧縮には 1 メガバイトあたり 1 秒少しかかり、古い端末や能力が低い端末はさらに時間がかかります。現時点の分析によると、平均で、パッチのサイズが半分になるとパッチの適用（再圧縮を含めたファイルごとのパッチ適用）にかかる時間は倍になります。

今のところ、この新しいパッチ テクノロジーの利用は自動アップデートのみに制限しています。これは通常、夜間にスマートフォンが電源に接続され、ユーザーが使用していない可能性が高いときにバックグラウンドで行われるアップデートです。これによって、ユーザーが手動でアプリをアップデートする際に、いつもより長く待たなければならないという事態を回避しています。

ファイルごとのパッチ適用の効率性

以下に、すでにファイルごとのパッチ適用を使っているアプリのアップデートの例を示します。
免責事項: 現在、ファイルごとのパッチはバックグラウンドでのみ利用されており、インタラクティブなアップデートには利用されていないため、手動で「アップデート」を押した際に表示されるパッチサイズとは異なる場合があります。

データを節約してユーザー（そしてデベロッパー）をハッピーに

以上の変更は、10 億人以上の Android ユーザー コミュニティが、最小限のデータ量でアプリの定期アップデートを行えるように設計されています。一番の長所は、デベロッパーは何もする必要がないことです。このアップデートのサイズ削減は、無償で行われます。

技術的な詳細など、ファイルごとのパッチ適用についてさらに詳しく知りたい方は、Archive Patcher GitHub プロジェクトをご覧ください。ソースコードを含む情報を閲覧できます。ファイルごとのパッチ適用は、完全なオープンソースです。

APK サイズをさらに削減したいデベロッパーの方は、APK サイズ削減のための一般的な推奨事項もご覧ください。


Posted by Khanh LeViet - Developer Relations Team

[この記事は John Coiner、ソフトウェア エンジニアによる Google Developers Blog の記事 "AMP Cache Updates" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

本日（*原文公開当時）は、Google AMP Cache のドメイン スキームの変更についてお知らせします。まもなく、AMP サイトのコンテンツは、Google AMP Cache の https://cdn.ampproject.org の各サイトのサブドメインから配信されるようになります。この変更で、Google AMP Cache から配信されるコンテンツがウェブの基本的なセキュリティ モデルである HTML5 オリジンによる保護を受けられるようになります。

ほとんどの AMP ドキュメントのサイトオーナーは、すぐに何かを変更する必要はありません。ただし、このセキュリティ強化のメリットを得るには、すべての AMP サイトオーナーが、新しい Google AMP Cache URL スキームに対応するように CORS 実装をアップデートすることが推奨されます。Google AMP Cache は既存の URL のサポートを継続しますが、将来的に既存の URL は新しい URL スキームにリダイレクトされるようになります。

Google AMP Cache でサブドメイン名が生成される仕組み

文字数制限や技術仕様上の問題がなければ、Google AMP Cache はサイトオーナーのドメインによく似た、人間が判読可能なサブドメインを生成します。

可能であれば、Google AMP Cache は、最初に AMP ドキュメント ドメインを IDN（punycode）から UTF-8 に変換してサブドメインを作成します。すべての「-」（ハイフン）は「--」（ハイフン 2 つ）に、すべての「.」（ドット）は「-」（ハイフン）に置換されます。たとえば、pub.com は pub-com.cdn.ampproject.org に変換されます。技術的な制限によって人間が判読可能なサブドメインが生成できない場合、一方向ハッシュを使用します。

リモート エンドポイントがあるホストやサービス プロバイダで必要になるアップデート

以上の変更によって、CORS エンドポイントは新しいオリジンからリクエストを受けることになります。そのため、次のアップデートが必要になります。

• 新しいサブドメインからのリクエストを受け入れるように拡張する: 現在、https://cdn.ampproject.org とサイトオーナー自身のオリジンからの CORS リクエストのみを受け入れているサイトでは、システムをアップデートして https://[pub-com].cdn.ampproject.org と https://cdn.ampproject.org、そして AMP サイトオーナー自身のオリジンからのリクエストを受け入れる必要があります。
• 受け入れるリクエストを絞り込み、セキュリティを強化する: 現在、AMP 仕様に記述されているように https://*.ampproject.org からの CORS リクエストを受け入れているサイトでは、受け入れるリクエストを絞り込んでセキュリティを改善するために、https://[pub-com].cdn.ampproject.org と https://cdn.ampproject.org、そして AMP サイトオーナー自身のオリジンからのリクエストを受け入れる必要があります。今後は https://*.ampproject.org をサポートする必要はありません。
• 広告やアナリティクスなどのテクノロジー プロバイダで新しいサブドメイン パターンをサポートする: CORS エンドポイントのあるアナリティクスや広告のベンダーなどのサービス プロバイダのシステムでも、自身のホストに加えて Google AMP Cache サブドメイン（ https://ampbyexample-com.cdn.ampproject.org など）からのリクエストを受け入れるようにする必要があります。

Google AMP Cache URL の取得

Google AMP Cache からの AMP ドキュメントを表示するプラットフォームでは、そのまま Google AMP Cache URL API を利用して Google AMP Cache URL を取得するとよいでしょう。Google AMP Cache URL API は 2017 年の第 1 四半期にアップデートされ、サブドメインを含む新しいキャッシュ URL スキームを返すようになる予定です。

各サイトに対して生成される Google AMP Cache サブドメインは、ampbyexample.com にあるインタラクティブ ツールから確認できます。

タイミング

Google 検索では、できるだけ早く新しい URL スキームの利用を開始し、サイトの互換性を注視する計画です。さらに、スムーズに移行を進めるために、影響を受ける方のサポートを行うとともに、リリース前にデベロッパーが利用できるテスト用のサンドボックスを作成する予定です。


Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Wesley Chun（@wescpy）、G Suite デベロッパー アドボケートによる G Suite Developers Blog の記事 "Generating slides from spreadsheet data" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

先日、G Suite チームは Google Slides API を初めて発表し、新たな可能性を打ち出しました。たとえば、スプレッドシートやデータベース内に すでに存在する データを 元に プログラムでプレゼンテーションやスライド コンテンツを生成できるようになります。この API のどこがすばらしいのかというと、プレゼンテーションにおけるメリットの 1 つは、データベースやスプレッドシートのデータを取り出して、視覚的にわかりやすいスライドを作成できることです。そのようなデータを反映した情報を、経営陣や潜在顧客に伝えたい場合に便利です。

本日ご紹介する DevByte 動画では、Sheets API と Slides API の両方を使った簡単なアプリケーションで、各 API の使い方を説明しています。サンプルアプリでは、まず Sheets API を使って、必要なすべてのデータをスプレッドシートから読み込んでいます。次に、Slides API で新しいスライドを作成し、そのスライドにスプレッドシートのデータを 設定 しています。


スライドは、API リクエストを送信して操作できます。Google Sheets API と同じく、リクエストは JSON ペイロード形式で送信します。次に示すのは、スライドに表を作り、スプレッドシートからグラフをインポートする擬似 JavaScript コードです。リクエストを行う際は、このような配列を作成します。
];
少なくとも 1 つのリクエストを格納した変数（ここでは、上の例に合わせてrequestsとします）があり、その中にスプレッドシートのsheetID と chartID、さらにプレゼンテーション ページのslideID が含まれているものとします。これを API に渡し、presentations().batchUpdate() コマンドを 1 回呼び出します。この処理は、API のサービス エンドポイントが SLIDES である場合、Python で次のように書くことができます。
       body=requests).execute()
表の作成はとても単純です。グラフの作成では、魔法のような機能を使うことができます。その 1 つが、linkingMode です。これに「LINKED」という値を設定しておくと、スプレッドシートのデータが変更された際に（スプレッドシート内のグラフが変わる場合）プレゼンテーションのスライドでもグラフが更新され、最新のイメージが表示されます。この更新は、API またはスライドのユーザー インターフェースによって行われます。linkingMode の値に「NOT_LINKED_IMAGE」を選択すると、データに応じて変更されることのない、旧来の静的なイメージになります。この機能の詳細については、グラフの作成に関するドキュメントや、両方の値を使った API リクエストの動作を紹介した動画をご覧ください。

動画で取り上げたコードサンプルの 全容 については、さらに詳しく取り上げている投稿をご覧ください。両方の API を駆使したアプリの登場を楽しみにしています。

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Dave Burke、エンジニアリング担当 VP による Android Developers Blog の記事 "Welcoming Android 7.1.1 Nougat" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

先週、Nougat のアップデートを公開しました。Pixel および Pixel XL 端末と、サポート対象となるすべての Nexus 端末向けの Android 7.1.1 です。また、端末メーカーが最新版の Android を入手できるように、Android 7.1.1 のソースコードが Android Open Source Project（AOSP）に登録されます。

Android 7.1.1 がユーザーに向けて公式にリリースされるこのタイミングで、ぜひアプリの対応を行ってください。

Android 7.1.1 の機能

Android 7.1.1 は、Pixel および Pixel XL 端末ですでに利用できるようになっている機能を土台として、ユーザー向けのさまざまな新機能の追加や、基盤となる Android 7.1 プラットフォーム（API レベル 25）に対する最適化やバグの修正が行われている増分リリースです。

デベロッパー機能の詳細については、アプリ ショートカット、円形アイコン リソース、イメージ キーボードのサポートなどをご覧ください。デベロッパー機能の完全なリストは、こちらで確認できます。API レベル 25 の詳細については、API の差分と API リファレンスをご覧ください。

Android 7.0 Nougat の主な動作変更の詳細やデベロッパー機能など、すべての Nougat デベロッパー リソースの概要はこちらから参照できます。

ユーザー端末にも順次展開

Android 7.1.1 は本日より公開され、今後数週間ですべての対象端末で利用できるようになる予定です。Pixel および Pixel XL 端末に加え、Nexus 5X、Nexus 6P、Nexus 6、Nexus 9、Nexus Player、Pixel C、General Mobile 4G（Android One）の各端末に、Over-the-air（OTA）アップデートが配信されます。Android ベータ版プログラムに登録している端末にも、この最終版が配信されます。通常どおり、このアップデートを手動でダウンロードして端末に書き込むこともできます。

また、数か月後にパートナーの端末メーカーが自社の端末を Android 7.1.1 にアップデートできるよう、その準備も進めています。

アプリを確実に対応させる

この機会にアプリの互換性をテストし、円形アイコンやアプリ ショートカットなどを追加して Android 7.1.1 でのアプリの外観を最適化してください。アプリは API 25 でコンパイルすることをお勧めします。できれば、ターゲットも API 25 に設定します。詳細については、最近の投稿をご覧ください。

最終版プラットフォームでは、Android Studio のプラットフォーム ツールやビルドツール、API レベル 25 エミュレータ システム イメージもアップデートされています。最新版のサポート ライブラリ（25.0.1）もリリースされ、API レベル 25 以前を実行している端末に、イメージ キーボードのサポート、ボトム ナビゲーションなどの機能を追加できます。

Pixel および Nexus 端末の最終テストをサポートするため、Nexus Images ページでダウンロード可能なファクトリー イメージや OTA イメージも提供しています。テスト対象端末を拡大するため、ぜひ Firebase Test Lab for Android を活用し、クラウドでテストを実行してください。12 月末までテストが無料になります。

最終テストの終了後には、Google Play Developer Console でアプリをアルファ版、ベータ版、さらに製品版のチャンネルに公開できます。

次のステップ

Developer Preview ビルドに対して報告されたバグのうち、未対応のものについてはまもなく対応が完了する予定ですが、フィードバックは今後も大歓迎です。Preview Tracker に記録した問題がまだ解消されていないという方は、AOSP Issue Tracker で Android 7.1 に対して新しく問題を送信してください。デベロッパー コミュニティでも、引き続きフィードバックや質問をお寄せいただけます。

8 月にお知らせしたように Android Nougat は定期メンテナンス サイクルに移っており、次の増分アップデートに向けた微調整やバグの修正作業もすでに始まっています。現在、対象端末をお持ちで Android ベータ版プログラムに登録している場合、その端末は次の Android Nougat リリースのプレビュー アップデートが利用可能になり次第、自動的に受信します。アップデートを自動で受信したくない場合は、ベータ版サイトで端末を登録解除してください。

デベロッパー プレビューに参加いただき、どうもありがとうございます。アンケートに回答し、今年のプレビューが皆さんのニーズをどの程度満たしていたかをお知らせください。いただいたフィードバックは、将来のリリース計画に反映いたします。



Posted by Yuichi Araki - Developer Relations Team

[この記事は Derek Murray、ソフトウェア エンジニアによる Google Developers Blog の記事 "TensorFlow 0.12 adds support for Windows" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

本日（*原文公開当時）、TensorFlow の Windows 暫定サポートをリリースしました。


Windows での TensorFlow のネイティブ サポートは、TensorFlow をオープンソース化した後、最初に寄せられたリクエストの 1 つでした。Windows ユーザーの中には、Docker コンテナで TensorFlow を実行している方もいます。しかし私たちはそれよりもっと完全に近い、たとえば GPU のサポートも含む機能を提供したいと考えていました。

今回の TensorFlow r0.12 のリリースに合わせて、Windows 7、10、Server 2016 向けのネイティブ TensorFlow パッケージを提供いたします。このリリースでは、CUDA 8 対応の GPU で TensorFlow トレーニングを高速化できます。

この最新リリースは、PyPI の pip パッケージ として公開されていますので、次のコマンド 1 つで TensorFlow をインストールできます。

     C:\> pip install tensorflow

GPU サポートは、次のコマンドでインストールできます。

     C:\> pip install tensorflow-gpu

Windows サポートの詳細を含む r0.12 の新機能の詳細については、リリースノートをご覧ください。

多くの方に TF を最高速でご利用いただけるようになりました。今後のリリース情報をいち早く受け取れるように、ぜひ Twitter で @tensorflow をフォローしてください。

謝辞

このリリースは、たくさんの方の貢献によって実現できました。とりわけ、Windows のサポートに大きく貢献してくださった Microsoft の Guenther Schmuelling 氏と Vit Stepanovs 氏に感謝いたします。


Posted by Kazunori Sato - Google Cloud Platform