この記事は Google Play プロダクト マーケティング マネージャー、Lloyd Hightowerによる Google for Developers の記事 " Announcing the Winners of the Gemini API Developer Competition!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


5 月の  I/O で、Google は世界中の開発者のみなさんに Gemini API を活用した革新的なアプリの開発を呼びかけました。世界中の何千もの開発者の皆さんがこの呼びかけに応え、既存のアプリに AI を搭載した機能を追加し、可能性の限界を広げる AI のアプリを開発しました。

そして、みなさんが待ち望んでいた瞬間が訪れました:

Gemini API デベロッパー コンテストの受賞者を紹介します!日本からは 2 名の方が選出されました。

総合的なベスト アプリ : Jayu


AI 搭載のパーソナルアシスタント「Jayu」は、Gemini API とクリエイティブな開発の融合による可能性を実証しています。この革新的なアプリは、ウェブブラウザ、コードエディタ、音楽ストリーミング、ゲームなど、さまざまなアプリと統合されています。Jayu は、視覚情報を解釈することによって、アプリのインターフェースと直接対話してリアルタイムで翻訳する能力を持ち、Gemini API の力とその能力を最大限に引き出すクリエイターの卓越したスキルを同時に示します。Google にとって、Jayu は単なる受賞アプリではなく、AI が生活に統合され、働く未来の一端を垣間見ることができます。

影響力の大きいアプリ & ユーザー評価の高いアプリ : Vite Vere (Real Lives)


Vite Vere は、認知障害を持つ人びとが日常的なタスクをこなすためのパーソナライズされたガイダンスを提供することで、より自立することを支援します。このアプリが Gemini の視覚的理解と巧みなプロンプトを使用して、ユーザーがタスクを完了できるよう段階的な指示を提供することで、自立とスキル開発を促進している点に感銘を受けました。

最もクリエイティブなアプリ : Outdraw AI (日本) 


Outdraw は、創造性と AI のユニークな融合により、AI ならではのゲーム体験を可能にしました。このゲームは、ユーザーは人間には認識できて、AI の視覚理解では認識できない画像を描くという挑戦をユーザーに与えるゲームです。このアプリは、AI をコラボレーションパートナーから挑戦的な対戦相手に変えることで、クリエイティブな取り組みにおける AI の役割を再定義します。これは、AI の最も創造的な使用例の 1 つでした。

最も役立つアプリ & Flutter の最適な用途 : Prospera

Prospera は、革新的な Flutter アプリで、Gemini API を活用してリアルタイムの AI セールスコーチを構築しています。セールス会話の分析と即時のフィードバックやパフォーマンス レポートを提供することで、Prospera は 営業担当者がスキルを向上させることを可能にします。このアプリは、実用的なビジネス課題に対処し、プロとしての成長を促進する Gemini モデルの汎用性を示しています。Prospera の詳細と、アプリの選出理由については、Flutter ブログ (英語) をご覧ください。

ベスト Android アプリ : Gaze Link



Gaze Link は、重度の運動障害と言語障害を発症した筋萎縮性側索硬化症(ALS)の患者の力を引き出す可能性を秘めており、私たちに感銘を与えました。この Android アプリは、眼球追跡技術とGemini API を使用して、介護者の質問を理解し、患者から生成された単一単語に基づいて完全な文章の応答を正確に予測および生成します。Gaze Link の詳細については、Android Developer ブログ (英語) をご覧ください。

Firebase のベスト ユース : Trippy



Trippy は、Firebase と Gemini API を巧みに活用して、パーソナライズされた旅行計画体験を作り出すことで注目を集めました。このアプリは、Gemini の自然言語理解とレコメンド機能を活用して、ユーザーの好みをもとに目的地、アクティビティ、旅程を提案します。Trippy は、AI がどのように旅行計画を強化し、世界を探検するのをよりアクセスしやすく楽しいものにするかを示しています。Trippy の詳細については、Firebase ブログ (英語) をご覧ください。

ベスト ウェブ アプリ : Viddyscribe



ViddyScribe は、視覚障害者の方々がよりアクセスしやすくなるよう、動画に自動的に音声説明を追加するウェブ アプリです。このアプリは、Gemini モデルを使用して文脈的に正確な説明を生成し、視聴体験を妨げることなく動画にシームレスに統合します。ViddyScribe の詳細については、Chrome Developers ブログをご覧ください。

ベスト ゲームアプリ : Pen Apple



Pen Apple は、Gemini Flash モデル を巧みに活用して、ゲームプレイのインタラクションを迅速に解釈して実行するオンライン デッキ構築ゲームです。このゲームは、Gemini の自然言語処理能力を使用して、カードの効果を直接カード名から解釈します。これにより、最小限の開発努力で複雑で創造的なカードが可能になります。私たちは特に、Gemini API がゲームの背景設定、敵、ステージ、さらにはゲームの仕組みに統合される新しいカードの作成にも使用されている点にも感銘を受けました。

ARCore のベスト ユース: Everies (日本)

Everies は、Gemini API と ARCore を活用して、身の周りの物に命を吹き込みます。Gemini の視覚理解と高度なプロンプトを使用して、Everies は物ごとにユニークなスクリプトを作成し、ARCore を使用して顔の特徴を重ね合わせることで、革新的で楽しい方法で物に命を吹き込みます。

Gemini API で未来を構築する

これらのアプリは、さまざまな分野で画期的な問題を解決するための Gemini API の計り知れないな可能性を示しています。Google は、開発者の皆さんが Gemini の能力を活用して、今後さらにインパクトのある革新的なアプリを開発することを期待しています。Gemini を活用した開発を始めるには、Google AI Studio をご覧ください。

Reviewed by Tamao Imura - Developer Marketing Manager, Google Play















アプリ内課金をマネタイズの軸とするモバイルゲームに動画リワード広告を導入する際のコツや注意点は?そして、それを支える 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

この調査の特に重要な結果を以下に示します。
  • スマートフォン ユーザーの 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



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

ユーザーがこの変化する環境をどのように知覚するかを理解するため、実際のモバイルアプリのタップ可能性に影響しうる表現方法について分析しました。具体的には、要素の種類(例: チェックボックス、テキスト ボックスなど)、場所大きさ色文字です。最初に行ったのは、最大 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

think-w-google
参照元: Google/SOASTA Research、2017 å¹´

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

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

Posted by Yoshifumi Yamaguchi - Developer Relations Team

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


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

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

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

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

Posted by Yoshifumi Yamaguchi - Developer Relations Team


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

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

何十億人ものユーザーに受け入れられる製品を構築するためには、ネットワーク接続の制限や断続的な接続、端末の互換性、スクリーンの大きさの違い、高額なデータコスト、すぐなくなるバッテリーといった大きな課題に対処する必要があります。先月の 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

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

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


Posted by Kazunori Sato - Google Cloud Platform




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




モバイル アプリ デベロッパーに必要なデータを集約した 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


ニュース記事を提供しているメディアやコンテンツ提供者が、これまでのモバイル向けのウェブページに加えて、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
  • AMP ページ設置予定の URL に Google のクローラーがアクセスできるようにする
    • robots.txt を確認する
    • 正規版のページのメタタグに nofollow 等がないようにする
  • AMP HTML の仕様にしたがい、AMP ページを作成する
    • Required Markup の項目がすべてあるか確認する
    • Google の検索結果に表示されるためには schema.org に準拠したメタデータの付与が必要
  • validator を用いて AMP ページが正しくマークアップされているかいずれかの方法で確認する
    • URL に #development=1 というフラグメントをつけて Google Chrome の開発者ツールで確認
    • node.js 製の validator をコマンドラインで実行して確認する
  • Structured Data Testing Tool を使ってメタデータが正しく記述されているかを確認する
  • Search Console の AMP レポートツール を使って AMP ページがインデックスされているか確認する
    • Google のクローラー側でエラーを検出した場合はこちらでレポートされるのでよく確認する

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

    Posted by Yoshifumi Yamaguchi - Developer Relations Team


    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


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

    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 デバイスドライバーをインストールする必要があります。



    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 フォーラムにぜひご投稿ください(ただし残念ながら英語のみとなります)。


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