[go: nahoru, domu]

レッドオーシャンと言われ出してから久しい国内モバイルゲーム市場。キャラクターやアイテムなどを排出するガチャに頼り切ったマネタイズが頭打ちになりがちな中で、既存のアプリ内課金に加え動画リワード広告を組み合わせる新たな手法が注目を集めています。まだ成功しているタイトルも多くない中、『ヴァルキリーコネクト』などを手掛けるエイチームは、国内の既存売上を減らすことなく、海外でも着実に売り上げを伸ばしているといいます。


アプリ内課金をマネタイズの軸とするモバイルゲームに動画リワード広告を導入する際のコツや注意点は?そして、それを支える Google AdMob(以下、AdMob)のメリット、魅力はどこにあるのでしょうか?全世界で累計 2100 万ダウンロードを突破している『ヴァルキリーコネクト』をはじめとするモバイルゲームの開発・運営を手がけるエイチームでモバイルゲーム全般のマーケティング戦略を担う河野光志氏に話をうかがいました。


AdMob とは?


AdMob は、Google が提供するモバイルアプリを収益化するための広告サービス。Android のみならず、iOS にも導入可能で、同社がもつ世界最大規模の広告ネットワークをベースに多種多様な広告と潤沢な在庫でアプリの収益化を後押ししてくれます。現在 Android アプリのトップ 1,000 タイトルのうち導入率は 81%、広告主の数も 100 万以上(世界トップの広告主のうち 97%が出稿)と、良質なネットワークを形成しています。


広告の収益管理となると煩雑な業務や高度な知識を求められるイメージもありますが、Google はいかにマネタイズを容易にし、本質的にゲームやアプリの開発にパブリッシャーやデベロッパーが専念できるかを念頭にサービスを設計しています。アプリ内広告のオープンビディングやアプリ内課金とハイブリッドで活用するための予測機能なども備えているほか、国別で自動最適化も可能になっており、まさに Google だからこそ提供できるハイクオリティな広告サービスといえるでしょう。


日本の開発者が海外市場を見据えるべき理由と AdMob が持つ強み
 -- AdMob でハイブリッドなマネタイズを実現したという『ヴァルキリーコネクト』(以下、ヴァルコネ)ですが改めてどのような作品か教えてください。

河野 本作は北欧神話をモチーフにしたハイファンタジー RPG で、2020 年の 4 月に 4 周年を迎え、直近では全世界で 2,100 万 DL を突破した長期運営タイトルです。種族や属性などを加味しながらパーティーを編成し、基本的には自動で進行する準オートバトルを通してキャラクターを育成しつつ物語も楽しみ、他のユーザーとマルチプレイで強力なボスと戦う... という今となってはスタンダードになったスタイルのゲームです。

 -- 国内動画リワード広告市場は年々右肩上がりの急成長を続けており、2018 年に 170 億円相当とされた規模は、2022 年には約 380 億円規模まで拡大すると予測されていますが、『ヴァルコネ』のように国内のモバイルゲームに導入されている例はまだ多くないと感じています。マネタイズに動画リワード広告を取り入れたきっかけはどのようなものでしたか。

河野 『ヴァルコネ』は国内展開だけでなく海外展開にも注力しており、新規ユーザーの流入はまだまだ伸び続けています。

一般論としてモバイルゲームは運営が長期になるほど新規ユーザーの獲得が困難になり、広告で獲得したユーザーに課金してもらって ROAS(Return On Advertising Spend)を回収する、というモデルに無理が生じてくるんですね。また、いわゆる "石"(ガチャを回すための課金アイテム)などの直販は、海外より国内の方が圧倒的に多くなっています。

 -- ユーザー 1 人あたりの課金額は、日本が圧倒的に高いとされていますね。

河野 ですので、国内海外を問わず、無課金ユーザーの方のプレイも動画リワード広告で課金転化できればと考えたのがきっかけです。また、モバイルゲーム市場は国内でも海外デベロッパーやパブリッシャーによるヒット作が増えてきていますので弊社は元々海外にも積極的にチャレンジしていこうという姿勢でいました。海外では動画リワード広告とアプリ内課金のハイブリッド手法は徐々に成功事例もでてきていたので、これはエイチームとしてもチャレンジすべきだろうと判断したのが 2018 年頃のことですね。

 -- とはいえ、同様のサービスを提供する企業は多くいます。導入するにあたり、AdMob を選んだ理由はどこにあったのでしょう?

河野 他の広告プラットフォームもいくつか検討しましたが、海外向けの広告在庫が圧倒的に多いというのが理由のひとつです。ウォーターフォール型の実装がされているので、高い eCPM(effective Cost Per Mille)を出しやすく運用しやすいというのも大きな魅力でした。


また、フィルター機能の使いやすさもチームのメンバーからは好評でした。ある動画広告を見たユーザーの方たちから「こういう動画は不適切ではないのか」とお問い合わせをいただくこともあるのですが、AdMob ならキーワードや画像で広告を検索し、手早く配信を止められます。優れた検索機能のおかげでこちらは工数を抑えられますし、ユーザーのみなさんのストレスもいち早く軽減できます。


 -- そうした事例も含め、広告のチューニングにかけている工数はどの程度なのでしょうか。

河野 弊社の場合は兼任で 2 名ですね。AdMob 自体が、自動化できるところは極力自動化してデベロッパーを開発に専念しやすくするというコンセプトですので、今後もこの工数が大きく増えることはないのかなと。


 -- AdMob による動画リワード広告を導入して、収益はどのように変わりましたか。

河野 『ヴァルコネ』や『ユニゾンリーグ』では、動画広告を見ることで回せるようになる "動画ガチャ"を実装しています。当初はよかれと思ってガチャ限定のキャラが排出されるようにしていたのですがこれが逆効果で、ユーザーの多くが直販の "石" の購入を控えてしまうようになり、収益が落ちてしまいました。

その後方針を変更し、キャラクターを強化するための素材などが出るようにしてからは収益は戻っています。すでに運営しているゲームに組み込む場合は、実装の仕方をよく考える必要があると痛感したエピソードですね。

 -- 動画広告導入によるユーザーからの反応はいかがでしたか。結構反発もある気もします。

河野 ゲーム側から強制的に広告を見せることはなく、動画ガチャを回そうとして初めて目にするものですので UX を損なうこともなく、"素材やアイテムをより多くもらえる手段のひとつ"として受け入れられていると感じます。

同業の方は「他のモバイルゲームの広告なんて見せたら、ユーザーが流出してそっちに移ってしまうのではないか」と懸念されるかもしれませんが、導入したことで DAU が大きく減ったということもないですね。私見ですが、モバイルゲームを 1 本だけ遊ぶユーザーはむしろ少ないのではと思いますので、広告を見て他のゲームを始めたとしても、こちらのプレイも続けてくれているのかなと。

 -- 『少女☆歌劇 レヴュースタァライト -Re LIVE-』の海外版では、広告ソースがリアルタイムに入札できる Open Bidding を取り入れているとうかがいました。

河野 導入前と導入後で、効果は大きく変化しており手応えを感じています。




広告の設定やタイミングを Google のチームが手厚くサポート


――そして、2020 年 6 月にリリースされた『初音ミク -TAP WONDER-』(以下、ミクたぷ)では、リリース当初から動画リワード広告が導入されていました。


河野 『ミクたぷ』は、タップするだけの簡単操作で誰でも気軽に楽しめる、バーチャル・シンガー「初音ミク」の新作スマートフォン ゲームです。ゲーム中の楽曲やミクが着るコスチュームの一部はユーザー応募によるもので、ユーザーのみなさんといっしょに盛り上げていくというのがコンセプトです。

今までに挙げたタイトルでの結果から確かな手ごたえを感じましたので、『ミクたぷ』はアプリ内課金と動画リワード広告による収益の割合を 6:4 くらいまで持っていきたいという前提で設計しています。設計に際しては開発段階から Google さんにもご協力いただけて、広告を出すのはどういうタイミングがいいのか、何分後がいいのか、何回出せばいいのかなど、事細かに相談させていただいてチューニングしました。特に海外での成功事例なども最新情報を共有してもらえるのがありがたかったですね。

具体的には、前述した動画ガチャに加え、ホーム画面で時おり流れてくる星をタップすると動画広告を見られるなど、ゲームの根底の部分にも組み込んでいます。

 -- 当初からゲームの設計に組み込むことで、開発チームもそれまで以上に広告の導入に深く携わっているかと思いますが、開発側のモチベーションはいかがでしたか。

河野 開発当初からアプリ内課金と動画リワード広告の収益を合算した数字を売り上げ目標としていたので、むしろサービス開始後に導入したタイトルよりもプロデューサーの熱意や関心が高いと感じますね。

また、ユーザーにとってみても、動画広告を見ているのといないのとではキャラクターの成長速度に違いが出るとなると、それが導線になりますので、広告を見るという行為をゲームサイクルに自然な形で取り入れられているのではと思います。

ミクたぷ』の動画リワード広告は Google さんの手厚いサポートのおかげもあり、問題やトラブルはほとんど発生せず好調に推移しています。

 -- 最初からハイブリッドでいくとなるとゲームのシステムやレベルデザインから LTV の考え方まで、これまでのお作法からは変化がありそうですね。

河野 そうですね。やはり何日プレイしたら、毎日動画リワード広告からボーナスを得る人とまったく得ない人でどれくらい差が出るか、といったこれまでにない指標も頭に入れながらレベルデザインを考える必要があります。どれだけユーザーに長く遊んでもらえるかということが重要なので、そのあたりのチューニングは大事になってきますね。

また、これまではいかにイベントを適切なタイミングでやって、限定のキャラを見せてユーザーを課金させるかというのがオーソドックスな手法でしたし、LTV を計測するときもいかに課金をしてもらうか、ということでしか測れませんでした。しかしハイブリッドなマネタイズモデルを導入することで、必ずしもアプリ内課金をしてもらう必要がなくなるわけです。

今、アプリ内のイベントにもチュートリアルクリアや課金といったポイントだけでなく、動画ガチャという地点も追加しています。長期タイトルだと前述のとおりなかなか新規ユーザーの獲得というジャッジを今の KPI ではしづらいのですが、動画リワード広告の収益も LTV として考えると、まだまだ新規にアプローチできるという判断もできると思いますし、どうしても既存ユーザーに目が行きがちな戦略も大きく変わってくるかもしれません。今後数値を整理しながら新しい施策に組み込めるようにしていきたいですね。

 -- 動画リワード広告とモバイルゲームという組み合わせを聞くとハイパーカジュアルゲームが思い浮かびますが、国内でゲームアプリとしてはメジャーであるアプリ内課金を軸にしたゲームでも大きな可能性があることがわかりました。

河野 繰り返しになってしまう部分もありますが、国内モバイルゲーム市場は、課金アイテムの直販によるマネタイズが主流ですが、海外勢はそもそもガチャがないアプリも少なくありません。

海外を見据えるなら、日本と比べたときの海外ユーザーの課金率の低さを補うためにも動画リワード広告の導入は必須といえます。ただ、私も先ほど失敗談をお話ししたように、どこにどのような広告を入れて、ユーザーにどのような報酬を与えるべきかという手法はゲームによってまちまちです。その点、AdMob はジャンルに応じたプレイブックが用意されているほか、こちらからの相談にも手厚くサポートしてもらえます。海外に出たいけどマネタイズが不安という方には、ぜひこうしたマネタイズ手法があることも頭に入れてチャレンジしてほしいです。

さまざまな SSP(Supply Side Platform)を連携できるのも欠かせない魅力のひとつですね。広告の在庫量や管理のしやすさも含め、モバイルゲームのマネタイズと生き残りを改めて考えるうえで AdMob は外せない選択肢となるのではと思います。


河野氏も語るように、ガチャを回すためのアプリ内課金だけに頼らない新たなマネタイズ手法を模索する必要がある昨今のモバイルゲーム市場。まだ国内市場も元気があるとはいえ、やはり更なるパイを求め海外に進出しようとするパブリッシャーやデベロッパーも少なくないはずです。

とはいえ、その設計や運用工数を考えると、どうしても二の足を踏んでしまう方も少なくないでしょう。新しいマネタイズにチャレンジしたい、海外でも収益性を高めたい、でもリソースは限られている... 尽きない悩みの中で AdMob は有力な選択肢としてあげられるのではないでしょうか。

収益性の高さはもちろん、チームによるサポートや、広告を適用したいゲームのジャンルに応じたプレイブックが用意されているほか、デベロッパーが少しでもクリエイティブに専念できるようにとの思いから機械学習などを生かした自動化ツールも導入されています。事実エイチームでも運用人数はマーケティング チームの一部でまかなえているということで、「とりあえず AdMob をいれておこう」という判断も間違いではないかもしれません。

すでにアプリ内課金と動画リワード広告によるハイブリッドなマネタイズ事例も国内外多数あるということで、興味のある方はぜひ導入を考えてみてはいかがでしょうか。


 

Posted by Google AdMob Japan

この記事は Google AMP Project マーケティング リード、Alex Durán による The AMP Blog の記事 "Users Prefer Tappable Stories On The Mobile Web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


タップ可能なストーリーは、ユーザーがコンテンツを閲覧する重要な方法の 1 つになっています。実際、週に 1 回はモバイル コンテンツを閲覧するというユーザーの 60% が、ソーシャル メディアでタップ可能なストーリーを毎日閲覧しています。 タップ可能なストーリー とは、モバイル端末でのインタラクティブなコンテンツで、ユーザーがイメージ、動画、テキストなどの全画面の視覚表現を操作できるものを表します。しかし、この人気のあるフォーマットは、限られたクローズなプラットフォームでしか動作しないのが一般的です。タップ可能なストーリーを使ってユーザーに革新的なコンテンツを提供することで、サイト運営者はメリットを得られます。提供できるのは、サイト運営者のソーシャル プラットフォーム上だけではありません。AMP ストーリーを使えば、モバイルサイト上でも提供することができます。

サイト運営者が AMP ストーリーを使うメリットを深く理解できるように、Google は一流のグローバル リサーチおよび顧問会社である Forrester Consulting に委託し、モバイルウェブのユーザーはどの程度タップ可能なストーリーを求めているのかを評価してもらいました。この調査は、「Publishers: Capture The Mobile Web Opportunity With Tappable Content」(サイト運営者: タップ可能なコンテンツでモバイルウェブのチャンスをつかむ)と題されたもので、2019 年 9 月に実施されました。




Forrester はこの分析にあたって、週に 1 回以上モバイル端末でサイト運営者のコンテンツを閲覧する 18 歳から 65 歳までの 2,062 名の米国のオンライン ユーザーを対象に、オンライン アンケートを実施しました。また、同じユーザーを対象に、22 のリモート無制限ユーザーテストを行いました。どちらの調査でも、モバイルウェブにある実際のタップ可能なストーリーの例と、同等のスクロール式の記事を参加者に操作してもらいました。この調査により、回答者の 64% がスクロール式の記事よりもタップ可能なモバイルウェブ ストーリー形式を好むことが判明しました。




64% の回答者がスクロール式の記事よりもタップ可能なモバイルウェブ ストーリーを好む。
出典: Forrester Consulting が Google に代わって 2019 年 7 月に実施した委託調査
この調査の特に重要な結果を以下に示します。
  • スマートフォン ユーザーの 74% が、少なくとも週に 1 回ソーシャル ストーリーを読むか閲覧します。ソーシャル ストーリーを閲覧したいという需要は、自分のストーリーを共有したいという需要を上回っています。サイト運営者には、自身のモバイルサイトでこの需要と供給のギャップを埋めるチャンスがあります。これにより、広告収入や豊かなデータ分析を実現できる可能性があります。 
  • 84% のユーザーが、タップ可能なストーリーは期待どおりあるいは期待以上の操作性であると感じています。さらに、スクロール式の記事に比べて、タップ可能なストーリーの操作方法が魅力的と感じる割合は 1.4 倍にのぼりました。 
  • 75% 以上のユーザーは、最もよく読むコンテンツ カテゴリのタップ可能なストーリーに何らかの興味を示しています。調査データから、ユーザーが非常に興味を持っているのは、以下のカテゴリの最新のライフスタイル コンテンツであることもわかりました。
    • DIY / ハウツー
    • 家庭 / 料理
    • スポーツ




DIY / ハウツー、家庭 / 料理、スポーツなどの最新のライフスタイル コンテンツは、タップ可能なストーリーの入口として最適。
出典: Forrester Consulting が Google に代わって 2019 年 7 月に実施した委託調査

Forrester の調査からわかるように、親しみやすいタップ可能なストーリー形式はサイト運営者がユーザーを獲得するまたとないチャンスです。AMP ストーリーなら、この形式をオープンウェブで実現し、サイト運営者は 1 つのエコシステムに縛られることなくコンテンツを制御できます。AMP ストーリーを支えているテクノロジーはまだ比較的新しいものですが、デベロッパーはいくつかの方法で使ってみることができます。

調査の全文はこちらから参照できます。ほかにはない魅力的なウェブ形式を使って、サイト運営者やコンテンツ制作者が既存の読者や新たなユーザーにアピールするチャンスについて詳しく説明されています。AMP ストーリー形式はウェブページとしてオンライン上に存在するため、検索インデックスへの登録が可能です。また、オープンウェブの一部なので、誰でも自分のサイトで試してみることができます。AMP ストーリーの広告オプションはまだ登場したばかりですが、私たちはこの領域を広げることに注力しています。サイト運営者がこのモバイル ファーストのフォーマットを使い、高度な視覚表現を駆使したタップ可能なストーリーとして情報を提供してくれることを楽しみにしています。

投稿者: Google AMP Project マーケティング リード、Alex Durán


Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Yang Li による Google AI Blog の記事 "Using Deep Learning to Improve Usability on Mobile Devices" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



モバイルのインターフェースで最もよく使われるジェスチャーはタップです。アプリの起動からテキストの入力まで、あらゆる種類の操作を呼び出すために使われます。従来の PC のグラフィック ユーザー インターフェースでは、クリック可能な要素(例: ボタン)のスタイルはある程度決まっていました。しかし、モバイルのインターフェースには実に多様なスタイルがあるので、タップできる要素とタップできない要素を見分けるのは難しくなっています。その難しさは、間違ったアフォーダンス(例: ボタンと間違われるような表現)や機能の見つけにくさにつながり、さらにはユーザーの不満や不安、間違いにつながる可能性があります。インターフェースのデザイナーは、これを避けるために調査したり、視覚的な意味合いを調べるためのテストを行ったりして、インターフェース上の項目がタップできるかどうかをわかりやすくしようとしています。しかし、そのような調査には時間がかかり、そこで判明した事実も特定のアプリやインターフェースのデザインに限定されます。


私たちの CHI'19 の論文「Modeling Mobile Interface Tappability Using Crowdsourcing and Deep Learning」(クラウドソーシングとディープ ラーニングを使ってモバイル インターフェースのタップ可能性をモデリングする)では、モバイル インターフェースのユーザビリティを大規模にモデリングするアプローチについて紹介しています。まず、さまざまなモバイルアプリの UI 要素を調査し、ユーザーがタップできると感じるかどうかを測定する作業をクラウドソーシングしました。モデルによる予測は、最大 90% のレベルでユーザーグループの予測と一致しました。この結果は、費用も時間もかかるユーザーによるテストを行わなくても、機械学習モデルを使ってデザイン内のインターフェース要素の感覚的なタップ可能性を効率的に推定できることを示しています。




ディープ ラーニングでタップ可能性を予測する
多くの場合、デザイナーはインターフェースが操作できることを表すために、要素の色や立体感などの視覚特性を使います。青字で下線の付いたリンクはその一例です。こういったよく使われる表現は便利ですが、特定のデザインの中で利用した場合、常にわかりやすいものになるとは限りません。さらに、デザインのトレンドの進化とともに、従来からの表現方法も常に変化し刷新されるので、不確実さや間違いの原因になる可能性もあります。

ユーザーがこの変化する環境をどのように知覚するかを理解するため、実際のモバイルアプリのタップ可能性に影響しうる表現方法について分析しました。具体的には、要素の種類(例: チェックボックス、テキスト ボックスなど)、場所大きさ文字です。最初に行ったのは、最大 3,500 個のアプリから抽出した最大 2 万個の重複しないインターフェース要素について、タップできると感じるかどうかをクラウドソーシングのボランティアにラベル付けしてもらうことでした。テキスト ボックスを除けば、ユーザーは種類による表現をほぼ確実にタップできるものと考えました。場所による表現とは、要素の画面上の場所のことです。この情報は、モバイルアプリの一般的なレイアウト デザインから得ることができます。下の図をご覧ください。
場所ごとにタップできる要素とタップできない要素の精度を表したヒートマップ。赤くなるほど精度が高い。要素をタップできないとラベル付けしたユーザーの精度は、インターフェースの上中央に近づくほど上がる。要素をタップできるとラベル付けしたユーザーの精度は、インターフェースの下中央に近づくほど上がる。
要素の大きさによる影響はかなり少ないものの、タップできない大きな要素があると混乱を生む可能性があることがわかりました。ユーザーは、が明るく文字数が少ないほどタップできる要素ととらえる傾向を示しましたが、文字の意味合いもタップできるかどうかの判断に大きな影響を与えていました。

これらのラベルを利用して、簡単なディープ ニューラル ネットワークをトレーニングしました。このネットワークは、ユーザーがインターフェース要素をタップできると感じるかタップできないと感じるかの可能性を予測するものです。このモデルは、インターフェースのある要素に対して、画面上の要素の空間的状況(場所)、要素の意味や機能(文字種類)、見た目(大きさやピクセルの生データ)などのさまざまな特徴を使います。ニューラル ネットワーク モデルは、ピクセルの生データから特徴を抽出するために畳み込みニューラル ネットワーク(CNN)を利用し、テキストの内容や要素の特性を表現するために要素の意味について学習させた埋め込み(embedding)を使います。その後、これらの特徴を組み合わせたものを全結合ネットワーク層に入力し、その出力として、要素がタップできるかを表す二値分類を生成します。



モデルの評価
このモデルを使うと、各インターフェース要素がタップできるかどうかについて、デベロッパーやデザイナーが指定した実際の(または意図した)要素の状態が、ユーザーの感覚(モデルの予測結果)とずれている部分を自動的に診断できます。次の例では、モデルは 73% の確率でユーザーが "Followers" や "Following" などのラベルをタップできると考えると予測しています。しかし実際は、これらのインターフェース要素はタップできるようにプログラムされていません。


人間のユーザーと比べた際のモデルの動作について、とりわけ人間の判断があいまいになる場合について理解するため、2,000 個の重複しないインターフェース要素がタップできると感じるかどうかをクラウドソーシングで 290 人のボランティアにラベル付けしてもらい、もう 1 つの独立したデータセットを作成しました。ここでは、1 つの要素を、5 人のユーザーがそれぞれラベル付けしました。その結果、サンプルの 40% 以上の要素に異なるラベルが付いたことがわかりました。次の図に示すように、この不確定性の部分でも、モデルと人間の感覚はかなり一致しています。
同じデータセットの各要素について、モデルが予測したタップできる可能性(Y 軸)と、人間のユーザーによるラベルの一致度合い(X 軸)でプロットした散布図。
要素がタップできるかどうかについてユーザーの意見が一致している場合、モデルも明確な答えを出す傾向にあります。つまり、ユーザーがタップできると判断したものは 1 に近い確率を、タップできないと判断したものは 0 に近い確率を出すことが多くなっています。人間の意見が一致していない要素(X 軸の真ん中に近いもの)は、モデルの判断も不確かになります。全体では、タップできる UI 要素を特定することにおいて、モデルは人間の感覚にかなり近い精度を実現できました。具体的には、平均の精度は 90.2% で、再現率は 87.0% でした。


タップ可能性の予測は、ユーザー インターフェースのユーザビリティの問題を解決するために機械学習を使ってできることの一例に過ぎません。インタラクションのデザインやユーザー エクスペリエンスの研究には、多くの難題があります。ディープ ラーニングのモデルは、ユーザー エクスペリエンスに関する大規模で多様なデータセットを精製し、インタラクションの動作について科学的な理解を進める手段を提供してくれます。


謝辞
この研究は、Google の夏季インターンである Amanda Swangson 氏と、ディープ ラーニングおよびヒューマン コンピュータ インタラクションのリサーチ サイエンティストである Yang Li 氏が共同で行いました。


Reviewed by Hak Matsuda - Developer Relations 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


[この記事は Nick Zukoski、ソフトウェア エンジニアによる Google Webmaster Central Blog の記事 "AMP your content: A preview of AMP'ed results in Search" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

2016 年にもかかわらず、モバイルでのウェブの閲覧は依然としてとても遅く、ユーザーは速くページを読み込めないというだけで閲覧を諦めてしまうという事実は信じがたいものがあります。私たち、そして多くのウェブ業界の人間にとって、何かしらの変化が必要であることは明らかでした。これこそ、私たちがモバイル ウェブの体験を改善するために Accelerated Mobile Pages というオープンソース プロジェクトを主導してきた理由です。

半年ほど前に、モバイル用の Google 検索の結果のページ内にある「トップニュース」枠内で AMP 対応ページの表示を始め、多くの方々に AMP ページを体験していただいています。それ以来、世界的に信じられないほど多くのサイトが AMP を適用し、ニュース サイトだけでなく、e コマース、エンタメ、旅行、レシピなどの様々な業界でも適用されてきました。今日まで、1 億 5000 万以上の AMP ドキュメントが Google のインデックスに存在しており、毎週 400 万の新規の AMP ドキュメントが追加されています。この結果を受けて、本日、Google は「トップニュース」枠だけでなく、全検索結果に対して AMP のサポートを拡大し、その開発者プレビューを公開いたします。

混乱を避けるために説明しますが、これはサイトの検索ランキングを変更するものではありません。メディアやコンテンツ提供者による AMP の適用事例が増え、私たちもユーザーの皆様により簡単にこの表示が速いウェブ体験にアクセスしてもらえるようにしたいと考えていました。開発者プレビューでは、AMP 版があるページの検索結果には のラベルが表示されます。このラベルが付いた結果をタップすると、対応する AMP ページが AMP ビューア内に表示されます。


開発者プレビューでの AMP ページの表示


g.co/ampdemo にアクセスして、みなさんの端末で試してみましょう。開発者プレビューにアクセスし、実際に「フレンチトースト レシピ」といったクエリや好きな曲の歌詞を検索すると、AMP ページでどれほど素早いモバイル ウェブ体験が可能になるかを実感できることと思います。AMP プロジェクトの公式サイトにある 「関係者一覧」 のページをご覧いただけば、どのようなサイトがすでに AMP 対応をしているかを垣間見ることができます。

日本でも、アメーバ、楽天、リクルート、朝日新聞、産経新聞、日刊スポーツ、毎日新聞、株式会社イード、マイナビニュース、BLOGOS をはじめとする多くのサイトが AMP のページを提供しています。

ユーザー、開発者、サイト運営者のみなさまからより多くのフィードバックを得て、今年の後半にはより広い範囲で私たちがより良い検索体験を提供できるよう、まずはプレビューとしてこの機能を公開します。また「AMP 化」に興味があるみなさまが AMP ページの実装方法を学び、その AMP ページがプレビュー上でどのように表示されるか確認する時間を十分に確保したいとも考えています。そして、AMP ページを作るだけでなく、多くの方々に AMP プロジェクトに参加や貢献していただければ幸いです。

みなさんと一緒にウェブの高速化をしながら、多くのフィードバックが寄せられることを楽しみにしています。また、いつものように、質問はウェブマスター フォーラムまでお寄せください。

Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Sam Dutton、Ankur Kotwal、デベロッパー アドボケート、Liz Yepsen、プログラム マネージャーによる Android Developer Blog の記事 "Building for Billions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]


「充電してください」「ネットワーク接続がありません」「このリソースの再生に十分な帯域がありません」

こういった警告は、世界中の多くのスマートフォンに表示されています。

何十億人ものユーザーに受け入れられる製品を構築するためには、ネットワーク接続の制限や断続的な接続、端末の互換性、スクリーンの大きさの違い、高額なデータコスト、すぐなくなるバッテリーといった大きな課題に対処する必要があります。先月の Google I/O では、developers.google.com/billions や関連する Android やウェブのリソースを公開しました。それに続き、本日(訳注:原文公開日)は Android およびウェブについてのビデオ プレゼンテーションを公開いたします。

こういったベスト プラクティスは、ネットワーク接続、データプラン、端末にかかわらず優れたパフォーマンスを提供することによって、何十億人ものユーザーに受け入れられることを目指すものです。g.co/dev/billions には、次のような役立つ内容が記載されています。

低速環境、中速環境、オフライン環境間のシームレスな遷移

ユーザーがある場所から別の場所に移動すると、高速な無線環境から断続的にしかつながらない環境に変わったり、データにかかるコストが跳ね上がったりします。データの保存、リクエストのキューへの格納、イメージ処理の最適化、完全オフライン状態でのコア機能の実行などによって、このような遷移に対応します。

適切な状況で適切なコンテンツを提供する

ユーザーがどこでどうやってコンテンツを参照しているのか、常にその状況を意識してください。ビューポートの大きさが変わっても問題なく機能するテキストやメディアの選択、短いテキストの維持(移動中のスクロール)、コンテンツの邪魔にならないシンプルな UI の提供、冗長なコンテンツの削除などは、すべてアプリの品質に対する 認識 の向上に貢献します。それとともにデータ転送量を減らすなど、実際のパフォーマンス向上を図ります。このような対策を済ませたうえでローカリゼーション オプションを提供すると、新たなユーザー層の取り込みやリピート率の向上につなげることができます。

モバイル ハードウェア向けの最適化

できる限り広いマーケットにアプリやウェブ コンテンツを提供し、それらが問題なく利用されるように、すべての主要な OS のバージョンをカバーします。さらに、対象マーケットの仮想端末や実際の端末でテストするというベスト プラクティスにも従います。ネイティブ Android アプリには、必要となる最小限の SDK と、対象 SDK を適切に設定します。さらに、低価格の携帯端末は RAM のサイズが小さいことも意識します。そのため、アプリのメモリ使用量が適切になるよう調整し、バックグラウンドでの動作も最小限にとどめます。APK サイズの最小化についての詳しい情報は、こちらのMedium の投稿をご覧ください。ウェブでは、JavaScript の CPU 使用量を最適化し、ラスター画像によるレンダリングを控え、リソースのリクエストを最小限にとどめます。詳しい情報は、こちらをご覧ください。

バッテリー消費量の削減

一般的に、携帯端末の価格が安いと、バッテリーの寿命も短くなります。ユーザーはバッテリー消費レベルに敏感で、バッテリーの消費が激しいと、アプリがアンインストールされやすくなったり、サイトが閲覧されなくなったりします。ベンチマーク テストを行って他のページやアプリとバッテリー消費量を比較するか、Battery Historian などのツールを使って、長時間動き続けてバッテリーを消費するプロセスをなくします。

データの集約利用

何を作る場合でも、データの集約利用は、ロード要件の理解、インタラクションに必要なデータ量の削減、ユーザーがすばやく目的の場所にたどり着くためのナビゲーションの効率化という 3 段階の簡単なステップで実現できます。ユーザーのためにデータ集約を行う(ネイティブ アプリでは、ネットワークの使用方法を設定する機能を提供することもできます)ことによって、プリペイド プランのユーザーやデータ利用料に制限のある契約のユーザーなど、データの利用に敏感なユーザーをつなぎとめることができます。また、「無制限」プランのユーザーであっても、ローミングを行ったり、予期せぬ費用が適用されたりすると、通信費が高額になる可能性もあります。

ネットワークにつながりにくい状況や低価格端末に対して、もう一歩踏み込んだ検討を行うか、成功につながる展開策を考えてみてください。よいアイデアは、ぜひ Google+ に投稿してください。



Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Pete Warden、ソフトウェア エンジニアによる Google Developers Blog の記事 "TensorFlow v0.9 now available with improved mobile support" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

TensorFlow の開発を始めた際の最優先事項は、モバイル端末のサポートでした。Translate や Maps、Google アプリのような Google のモバイルアプリは、端末上で実行されるニューラル ネットワークを使用したアプリです。私たちは、オープンソース TensorFlow の最も重要な部分はモバイルだと考えています。

TensorFlow は、リリース当初から Android で利用できました。加えて本日(*原文公開当時)、TensorFlow v0.9 は iOS でも利用できるようになり、 Raspberry Pi のサポートと新しいコンパイル オプションも追加されました。

iOS で TensorFlow をビルドするために、クロスコンパイル処理を行ういくつかのスクリプトを作成しています。そのうちの makefile は、常に利用できるわけではない Bazel を使わずに TensorFlow をビルドする際に役立ちます。
以上のことは、最新の TensorFlow ディストリビューションにすべて含まれています。詳しくは、モバイル TensorFlow ガイドや iOS サンプルAndroid サンプルのドキュメントをご覧ください。モバイル用サンプルでは、ImageNet Inception v1 classifier を使用して画像を分類することができます。
現在のモバイル用サンプルはほんの触りに過ぎません。皆様のサポートや貢献をお待ちしています。ソーシャル メディアの投稿に #tensorflow タグをつけて、皆様のプロジェクトを共有してください。

TensorFlow 0.9.0 リリースノートの完全版は、こちらからご覧いただけます。


Posted by Kazunori Sato - Google Cloud Platform

先日の I/O で発表された 統合アプリプラットフォーム Firebase の機能は、下記のとおり 15 あります。本日は、先日ご紹介した 7 機能に続き、残りの 8 機能についてご紹介します。




Firebase Crash Reporting は アプリ の クラッシュ 情報を収集し、ダッシュボードに表示します( 1 分 56 秒)。


広告収入を生み出す AdMobと Firebase を連携して使うことができます( 2 分 12 秒)。


アプリでファイルを保存して共有できるようにする Firebase Storage のご紹介です( 1 分 23 秒)。


Firebase Realtime Database は、リアルタイムのデータの同期やオフライン時のサポートを可能にします( 1 分 55 秒)。


Firebase Hosting は、フロントエンドウェブアプリ向けの静的ウェブホスティングプロバイダです( 1 分 22 秒)。


Firebase と Google AdWords の連携により、アプリを多数のユーザーに対し効果的に宣伝できます( 1 分 39 秒)。


Firebase Authentication により、ユーザーもデベロッパーも認証を簡単に行えます( 1 分 40 秒)。


Google 検索と連携された Firebase App Indexing は、ユーザーの再エンゲージを可能にします( 1 分 50 秒)。


字幕は、動画右下の設定アイコン(歯車状のアイコン)から「Subtitles/CC」を開き、「Japanese」を選択することで日本語に変更できます。


これらの紹介動画や新しい Firebase のサイトを見て、新しい Firebase について学んでください。

Posted by Khanh LeViet - Developer Relations Team

5 月 18 日からの 3 日間で行われた  I/O 2016 において、私たちは Firebase の拡張を発表し、本ブログでも新機能についてお伝えしました。皆様にもっと Firebase を知ってもらうため、統合アプリ プラットフォームとは何なのか、そして何ができるのかを紹介した日本語字幕付き動画を用意しました。今日は、15 の機能の何があるかの概要と、個別の 7 機能についてご紹介します。

Firebase は、モバイル アプリを成功させるために必要なすべてのツールをそろえている統合プラットフォームです。まずは、機能全般を紹介した動画( 2 分 34 秒)をご覧ください。




モバイル アプリ デベロッパーに必要なデータを集約した Firebase Analytics のご紹介です( 3 分 32 秒)。


ユーザーへのメッセージ送信を容易にするのが Firebase Cloud Messaging です( 1 分 04 秒)。


Firebase Remote Config は、アプリを動的にすばやく更新し、大幅な変更の前には方向性が正しいかをテスト、ユーザーごとにサービスをカスタマイズするといったことを可能にします( 3 分 28 秒)。


思い通りに機能してくれるディープリンクが Firebase Dynamic Links です( 3 分 04 秒)。

Firebase Notifications は、ユーザーへのお知らせの送信や管理を容易にし、Analytics とも連携できます( 54 秒)。


Firebase Invite は Android と iOS に対応し、ユーザーがアプリのコンテンツや紹介コードを紹介したり送ったりすることを容易にします( 3 分 02 秒)。


Firebase Test Lab for Android により、さまざまな Android 端末でアプリを簡単にテストできます( 2 分 35 秒)。


字幕は、動画右下の設定アイコン(歯車状のアイコン)から「Subtitles/CC」を開き、「Japanese」を選択することで日本語に変更できます。


これらの紹介動画や新しい Firebase のサイトを見て、新しい Firebase について学んでください。

Posted by Khanh LeViet - Developer Relations Team

モバイル端末からインターネットを利用する機会は増えつづけており、  Google 検索もモバイル端末からの利用がデスクトップからよりも多くなってきています。一方、現在のモバイル インターネットは、特にスピードの面において、必要な情報を求めるユーザーの期待に応え切れていないという現実があります。この状況を改善するため Google は業界各社の協力のもと、昨年 10 月にオープンソース プロジェクトである Accelerated Mobile Pages (AMP) プロジェクトを発足しました。

以来、モバイル インターネットの向上という共通課題のもとに、多くの企業が AMP プロジェクトに参加し、新たな AMP カスタムタグや AMP ページの公開を含む進化が続いています。そして本日より、Google は AMP ウェブページをモバイル検索に導入いたします。日本の対応パートナーは日々増えておりますが、本日の時点で、朝日新聞、映画.com、zakzak、THE PAGE、産経ニュース、SankeiBiz、SANSPO.COM、シネマトゥディ、日刊スポーツ、BLOGOS、毎日新聞、マイナビニュース、レスポンスの 13 メディアが対応しています。これにより、日本語の主要記事においても素早くアクセスと高速表示が可能となりました。

これらの AMP 対応されたページはどのように Google 検索に表示され、どうして瞬時にモバイルブラウザで表示されるのでしょうか。次の図で説明します。


ニュース記事を提供しているメディアやコンテンツ提供者が、これまでのモバイル向けのウェブページに加えて、AMP HTML に準拠したウェブページを公開すると、Google のクローラーが AMP ページをキャッシュします。キャッシュされたコンテンツが検索クエリに関連が深いと判断された場合、検索結果にはキャッシュされたページの URL がリンクされます。検索結果に表示されたキャッシュ済みの AMP ページにユーザーがアクセスする場合には、キャッシュ済みのためコンテンツの取得までの時間が短く、また広告やアナリティクスといったタグは遅延読込されるため、記事の表示が瞬時に行われます。

すでに先日のブログポストで AMP ページの実装方法をご紹介しましたが、再度簡単に AMP ページの実装手順をご紹介します。なお AMP の仕様はまだ策定が進んでいる途中ですので、新規に対応される場合には常に GitHub にある最新の情報をご確認されることをおすすめします。

  1. AMP ページと正規版のページの URL の対応を検討する
    • 正規版の URL にパスを追加する 例) https://foo.com/article/amp/index.html
    • ファイル名に文字を追加する 例) https://foo.com/article/index.amp.html
    • URL パラメータを追加する 例) https://foo.com/article/index.html?amp
  2. AMP ページ設置予定の URL に Google のクローラーがアクセスできるようにする
    • robots.txt を確認する
    • 正規版のページのメタタグに nofollow 等がないようにする
  3. AMP HTML の仕様にしたがい、AMP ページを作成する
    • Required Markup の項目がすべてあるか確認する
    • Google の検索結果に表示されるためには schema.org に準拠したメタデータの付与が必要
  4. validator を用いて AMP ページが正しくマークアップされているかいずれかの方法で確認する
    • URL に #development=1 というフラグメントをつけて Google Chrome の開発者ツールで確認
    • node.js 製の validator をコマンドラインで実行して確認する
  5. Structured Data Testing Tool を使ってメタデータが正しく記述されているかを確認する
  6. Search Console の AMP レポートツール を使って AMP ページがインデックスされているか確認する
    • Google のクローラー側でエラーを検出した場合はこちらでレポートされるのでよく確認する

AMP プロジェクトはオープンソース プロジェクトであり、いまも多くの方々から多くの新機能や改善点がソースコードや Issue Tracker を通じて実装・提案され、随時取り入れられています。ぜひ Google 検索で AMP のスピードを体感してみてください。皆様の AMP プロジェクトへの参加と AMP ページのご対応を楽しみにお待ちしております!

Posted by Yoshifumi Yamaguchi - Developer Relations Team

Posted by 小久保浩大郎 Brand Studio Team

Google のミッションは世界中のあらゆる情報を整理し、あらゆる人が、使う言語に関わらず簡単にアクセスできるようにすることです。これを推し進めるべく、Google はアドビとのパートナーシップのもと、無料で高品質な Pan-CJK (中国語、日本語、韓国語)フォントファミリー「Noto Sans CJK」をリリースしました。


Noto Sans CJK は、繁体字中国語、簡体字中国語、日本語、韓国語を完全にカバーするグリフのバリエーションを備えています。また、それぞれの言語圏における文字の好みや特徴をとらえながら、伝統とモダンの両方のスタイルをバランスよくデザインに反映しています。

クセがなく大きさが揃ったひらがな・カタカナは、ラップトップ、スマートフォン、タブレットなどの様々なデバイスのユーザーインターフェースとしても使いやすく、また伝統的な文字の優美さを受け継いだ形はウェブコンテンツや電子書籍などの長文を読むのにも適しています。他、どのような用途でも使える汎用性を考慮した書体となっています。

Noto Sans CJK は Thin, Light, DemiLight, Regular, Medium, Bold, Black の7種類のウェイト(太さ)を用意しています。これらのウェイトは従来の Noto ファミリーのフォントや Android の標準フォントである Roboto と組み合わせて使用でき、日本語フォントには珍しい非常に細いウェイトからダイナミックな太字まで、注意深く設定されています。


繁体字中国語、簡体字中国語、日本語、韓国語をすべてサポートするには、数万種類もの文字をデザインする必要があります。中には同じ文字でありながら、各国でそれぞれ微妙に違った字形のバリエーションが必要になるものもあります。

ご存知のように、漢字は日本独自の文字ではありません。元々は古代中国で生まれた一つの文字であるにもかかわらず、様々な地域の言語文化の中で独自の進化を果たし、現在では、繁体字中国語、簡体字中国語、日本語、韓国語の中で使われています。そのため、例えば同じ「骨」という文字でも、下に示すように各言語でそれぞれ違ったデザインになってます。Noto Sans CJK はこのような各言語における漢字のバリエーションもサポートしています。


(左から) 簡体字中国語、繁体字中国語、日本語、韓国語、それぞれの言語における「骨」の字

さらに、日本では人名や土地の名称に異体字が使われることがありますが、Noto Sans CJK は Adobe-Japan1-6 グリフ集合に含まれる漢字をカバーしているため、珍しい表記の苗字なども本来の文字で表示できます。



漢字のほか、日本語のひらがな・カタカナ、韓国語のハングルもサポートし、すべてスタイルを合わせてあるため、同時に使用しても統一感を損なうことはありません。

Google とアドビは共同でこの高品質な CJK フォントの開発に取り組みました。Google はこのフォントを Noto Sans CJK として新たに Noto ファミリーに加え、アドビは Source Han Sans として Adobe Source ファミリーに加えます。アドビはタイプフェイスデザインの著作権を保持しますが、フォントは Apache License, version 2.0 のもとにリリースされますので、どなたでも自由にお使いいただけます。

このパートナーシップにあたり、Google は全体のディレクション、要求仕様の策定、各国でのテストリソースや専門家によるアドバイスの提供などを行いました。アドビは、デザインおよびフォント関連の技術、各国用書体を含む定評ある書体デザインの経験、そして大規模な工程の管理とオートメーション技術をもってプロジェクトを推進しました。さらに、プロジェクトの規模によるリソースと各国の書体の専門知識の必要性から、Changzhou SinoType Technology、イワタ、そして Sandoll Communication の 3 社のトップ書体メーカーの協力を得ています。

Noto ファミリーの目的は世界中のすべての言語をサポートすることです。新たに Noto Sans CJK が加わったことで、様々なデバイスを利用するすべての方に美しいタイポグラフィをお届けするというミッションを、さらに一歩、大きく進めることができました。Noto フォントのウェブサイトからダウンロードしてぜひご利用ください。

関連リンク
Google Developers Blog

Posted by 北村英志 Developer Relations Team

[この記事は Software Engineer の Pavel Feldman が The Chromium Blog に投稿した記事、Chrome DevTools for Mobile: Emulate and Screencast を元に、北村が加筆・再構成しています]

モダンなウェブアプリはモバイルデバイス上でも完璧にレンダリングされ、実行されることが期待されています。これはレスポンシブデザインや 60 fps での動作、接続性が開発早期に考慮される必要があることを意味します。我々は Chrome Beta の Android 版デスクトップ版 にて、改良された viewport エミュレーション、設定不要でスクリーンキャスト機能を備えた リモートデバッグ機能 を追加することで、モバイルウェブアプリの開発とデバッグをさらに手軽にしました。

アプリをデザインする際、どのスクリーンでもきれいに見せたいとお思いではないですか? 新しい DevTools では、開発環境から離れることなく様々な人気のデバイススクリーンを試すことができるようになりました。Console の Emulation タブ (*1) からデバイスを選択するだけで、最適な viewport の数値が設定されます。この機能では正確な結果を得るため、モバイル版 Chrome と同じ viewport 値でページを実行することができます。もちろん、スクリーンレゾリューション(screen resolution)、タッチエミュレーション(touch emulation)、デバイスピクセルレシオ(device pixel ratio)、ユーザーエージェント(user agent)、センサー等、各パラメータごとに細かく設定することも可能です。


実際のデバイスにおけるパフォーマンスを計測したい場合はどうでしょう?

ChromeOS を含む Chrome Beta で、USB で接続されたデバイスの検知がネイティブでサポートされるようになりました。「ツール」 > 「デバイスを検証」メニューを選択するか、about:inspect を開いてください。設定は必要ありません。これまでのように adb コマンドラインツールを使ったり、拡張機能を入れる必要もありません。(*2)

USB で接続されている間、デバイスから DevTools に画面全体のスクリーンキャストを送信することが可能です。スクリーンキャストが利用可能な場合、Elements タブの横に専用のアイコンが表示されます。


キーボードやマウスのイベントも DevTools からデバイスに送信されるため、アプリのテスト中にデバイスに触れる必要もありません。




これら モバイルエミュレーションUSB デバッグ機能、スクリーンキャストによって、DevTools を使った開発や調査、デバッグはさらに手軽になることでしょう。Chrome Dev Summit 2013 で行われた Paul Irish のセッション動画 でこれらの機能のデモをご覧頂くことができます。

*1: DevTools の Settings > Overrides で 'Show Emulation' をチェックする必要があります。
*2: Windows ユーザーの方は USB デバイスドライバーをインストールする必要があります。

Posted by 佐藤一憲 / Solutions Architect, Cloud Solutions Team

[この記事は Mobile Backend Starter のプロダクト マネージャー、Brad Abrams が Cloud Platform BlogAndroid Developers Blog に投稿した記事、Get your Android Application Cloud-Powered with the Mobile Backend Starter を元に、佐藤が加筆・再構成しています]

いまどきのモバイル アプリケーション開発では「クラウドとの連携」が欠かすことができません。とはいっても、データベース アクセスやユーザー認証といった定番の機能を利用するためだけに毎回サーバーを自分で立てたりサーバー側のコードをひと通り書いたり自分で運用したりするのはちょっと面倒ですよね。モバイル アプリ用のバックエンドをクリックひとつで準備できて、運用もラクちんなクラウド環境があったらいいな...と思いませんか?

先日の Google I/O 2013 でのセッション From Nothing to Nirvana in Minutes: Cloud Backend for Your Android Application では、まさにそうしたニーズに応えるツール Mobile Backend Starter が公開されました。



Mobile Backend Starter は、Google が提供する PaaS(Platform as a Service)である Google App Engine 上で動作するモバイル アプリ用バックエンドを、クリックひとつでアップロードできます。手間をかけてサーバー環境をセットアップしたりサーバー側プログラムをコーディングしたりといった作業は一切不要。以下の豊富なバックエンド機能を Android 向けアプリから直接利用できます。


  • Datastore によるデータ保存と検索
    • Google の他の主要サービスと同じレベルのきわめて高いスケーラビリティと可用性を備えるデータ ストア、App Engine Datastore に対して、Android 向けアプリから直接データの保存や検索が可能です。もしあなたのアプリが大ヒットして膨大な量のデータやアクセスが集中したとしても難なくさばけます。また、すべてのデータは常に複数のデータ センターにコピーされ、もしもの障害時にもサービスが停止したりデータが失われる可能性はわずかです。
  • Android 向けアプリへのプッシュ通知と Pub/Sub メッセージング
    • Google Cloud Messaging を利用したプッシュ通知をサポートしており、Android デバイス間での 1:1 や 1:n のメッセージングやブロードキャスト配信を簡単に実装できます。ソーシャル アプリや掲示板、チャット、ゲーム、グループ コラボレーション等のアプリを容易に実現できます。
  • Continuous Query によるリアクティブなユーザー エクスペリエンス
    • Continuous Query、すなわちデータの更新を常時監視して変化を検知し、クエリを自動再実行するメカニズムをサポートします。例えば、掲示板アプリにおいて書き込み内容を取得するクエリを実行すると、掲示板に誰かが書き込むたびに同じクエリが自動的に再実行され、数秒のうちにユーザー インタフェースが更新されます。もうユーザーに「リロード」ボタンを何度も押させたりポーリングを行う必要はありません。この機能の実装には App Engine の Prospective Search API が利用されています。
  • Google アカウント認証とアクセス制御
    • Android デバイスで使用されている Google アカウント情報が自動的にバックエンド側に渡され、個々のデータにアクセスしたユーザー ID の取得やアクセス制御などのセキュリティ機能がごく簡単に利用できます。
  • 無償で始められて運用管理も楽ちん
  • オープン ソースで公開、バックエンドの機能拡張も容易
    • すべてのソース コードがオープン ソースとして GitHub リポジトリで公開されており、必要に応じてバックエンド側のコードやロジックを追加・変更して App Engine 上にアップロードして運用できます。

Mobile Backend Starter を使ってみよう

Mobile Backend Starter の使い方は簡単です。以下では、Mobile Backend Starter を使いはじめるまでのステップを簡単に紹介します。なお、手順の詳細については Getting Started ドキュメントを参照してください。

まずは http://cloud.google.com/console を開き、CREATE PROJECT ボタンをクリックして 新しいプロジェクトを作成します。つづいて、画面上に表示されるサンプルコードから Mobile Backend App を選択して Deploy ボタンをクリックすると、Mobile Backend が App Engine にアップロードされます。





次に Setting ボタンをクリックし、認証設定を Open にセットして保存します。



これでバックエンドが Android 向けアプリからアクセス可能になりました。最後に、ひな形となる Android クライアントをダウンロードし、Eclipse で開きます。Consts.java というファイル上の PROJECT_ID に作成したプロジェクト ID を記入します。



この Android クライアントに含まれるサンプルである Guestbook アプリを起動すると、バックエンドとアクセスできていることを確認できます。



Mobile Backend Starter のドキュメント ページでは、さらに Google Cloud Messaging を利用した Continuous Query や、Google アカウントによる認証処理やユーザー情報取得をテストする手順が記載されていますので合わせてご覧ください。

Mobile Backend Starter のプログラミング

Eclipse 上で Guestbook アプリのソース コードを眺めれば、Mobile Backend Starter のプログラミングがいかに簡単か解るはずです。例えば Guestbook アプリでは、以下のような数行のコードでゲストブックに新しいメッセージを追加しています。サーバー側コードの記述や事前のテーブル定義が不要なだけでなく、Android 開発につきものの AsyncTask の記述(非同期ネットワーク通信)、AccountPicker(Google アカウントの選択)まわりの記述、サーバー側のユーザー認証まわりのコーディングなどをすべて省略できます。
CloudEntity newPost = new CloudEntity("Guestbook");
newPost.put("message", <...the entered text...>);
getCloudBackend().insert(newPost, null);

また以下のコードでは、Guestbook テーブルに対して Continuous Query を実行しています。Continuous Query とは、サーバー側に保存されたデータの変化を捉えてクエリを継続的に実行する新しいメカニズムです。
CloudQuery cq = new CloudQuery("Guestbook");
cq.setScope(Scope.FUTURE_AND_PAST);
List<CloudEntity> results = cloudBackendAsync.list(cq, handler);

ここで、Scope.FUTURE_AND_PAST とは過去と未来の両方のデータに対して検索を行うという意味の指定です。具体的には、ゲストブックの過去の書き込み内容を検索するだけでなく、新しい書き込みがあるたびに瞬時に検索が再実行され、イベント ハンドラが呼び出されてユーザー インタフェースが更新されます。ユーザーにリロードボタンを何度も押させたりポーリングしたりしなくてもつねに最新の情報を表示でき、かつネットワークアクセスの回数を大幅に減らしてバッテリー消費を低く抑えられます。本来、こうしたサーバー プッシュ機能を利用するには Google Cloud Messaging のプログラミングが必要となりますが、Continuous Query を使えば一行の Scope 指定だけでサーバー プッシュ機能を利用できます。

いかがでしょうか。Mobile Backend Starter ではほんのわずかな作業でモバイル アプリ用のバックエンド環境を準備でき、かつ簡単な Android プログラミングだけでインタラクティブ性の高い豊富なバックエンド機能をすぐに利用できることが理解いただけたかと思います。なお、近日中には詳細なプログラミング マニュアルも公開される予定です。Mobile Backend Starter についてのご質問や、こう使ったよ、といったレポートなどありましたら、Stack Overflow の Cloud Endpoints フォーラムにぜひご投稿ください(ただし残念ながら英語のみとなります)。

Posted by 山崎富美 Developer Relations Team

[本記事は、モバイルウェブパフォーマンスチームの Matt Welsh、Ben Greenstein、Michael Piatek が 5 月 1 日 に Google Developers Blog に投稿した 「SPDY performance on mobile networks」という記事を元に、翻訳したものです。詳しくは元記事をご覧ください。 - 山崎] 

SPDY とは、HTTP の代替技術であり、HTTP に関連する多くのオーバーヘッドを取り除くことによって、ウェブページの伝送速度を向上することを目的として設計されました。SPDY は、速度に関して、HTTP を上回るよう、いくつかの最適化をおこなっています。 これまでに多くの支持を得ており、Chrome、Firefox、Amazon Silk で SPDY は実装されており、Google によって広く展開されてきました。さらに、Apache では、SPDY サポートとして、mod_spdy モジュールが開発されました。

さて、SPDY と HTTP の性能を人気のあるウェブサイトで比べてみました。ここでは、Samsung 製の Android OS 搭載端末 Galaxy Nexus を使い、最新かつ SPDY 対応のブラウザ(Chrome for Android)で、実際のウェブサイト(31 個の人気ドメインの 77 個のページ)にアクセスしました。

その結果、HTTP に比べて、SPDY では、これらのサイトからの平均ページ読み込み時間が 23% も改善されることが明らかになりました。つまり、SPDY は、HTTP の 1.3 倍のスピードアップということになります。3G や 4G のモバイルネットワーク上で SPDY パフォーマンスを向上させるためには、これから多くのことが必要ですが、この結果はスタート地点としては将来有望といえるでしょう。

次のグラフは、HTTP と SPDY について、測定した 77 ページそれぞれのページ読み込み時間(単位:ミリ秒)を表したものです。 グラフが示すように、1 つのケースを除き、SPDY の方が読み込み時間が短く、中には 50% 近くも短くなったケースもあります。


測定方法と結果に関する詳細は、こちらの記事をご覧ください。



[3D モードのモバイル Google マップについて、プロダクトマネージャーの牧田信弘から寄稿してもらいました。この記事は Google Japan Blog とのクロスポストです。-山崎]


モバイル Google マップは、米国で 5 年以上前に誕生し、日本では 2007 年にサービスを開始しましたが、これまでに全世界で1 億人以上の方にお使いいただいています。この5年間に、大小、様々な機能追加と共に日々進化を続けてきたモバイル Google マップですが、このたび、新しい地図の描画方法を採用し、静的な 2D の地図から、ダイナミックな動きのある 3D の地図へと生まれ変わりました。



地図を傾け3Dモードで様々なビルを表示(左)コンパスモードで自分の位置方角を確認(右)

新しい描画方法を取り入れたことで、モバイル Google マップには、さまざまな便利な機能が追加されました。

3D モード:
  • 地図を傾ける:2本の指で地図を下にドラッグすると、ビルが3D で立ち上がります。
  • 地図を回す:2本の指で地図を回し、立体表示されたビルの裏側も簡単にチェックできます。
  • スムーズなズームイン/アウト:二本の指を閉じたり開いたりすることで、簡単に見たい場所にズームイン/アウトできます。

コンパスモード:
  • 現在地が表示されている状態で、画面右上のコンパスをもう一度タップすると3D モードであなたの向いている方角を上に表示します。


3D モードは東京や大阪などの大都市では目印になるビルを確認できるので非常に便利ですし、コンパスモードは、ビルや地下鉄の駅から外に出た時に、素早く自分の位置と向きを確認できるので、迷わず目的地に向かうことができます。



モバイル Google マップ 5.0 はアンドロイドマーケットよりダウンロードいただけます。なお、3Dモードは、アンドロイド 2.0 以上を搭載するモバイルデバイスでご利用いただけます。ぜひ、ご利用いただき、ご意見・ご感想をヘルプフォーラムまでお寄せください。