この記事は Google Maps Platform Blog の記事 " How two developers reached new heights with Google Maps Platform" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

編集者より: この投稿は、カスタムのストリートビュー画像と Google Maps Platform を使用して構築されたドイツ最高峰ツークシュピッツェ山の山頂までのバーチャル ツアーを提供している Web サイト Zugspitze360.com の共同制作者 David Schmidta 氏によるものです。

兄のフィルと私は写真を撮るのが好きです。写真撮影のテクニックと想像力の両方を発揮できることに、いつも魅了されています。私たちは仕事では Web テクノロジーを専門としているため、ストリートビューと 360 度写真に関心を持つようになったのはごく自然なことでした。熱意と好奇心もあって、私たちは仕事の合間にあちこちで 360 度写真を撮影しオンラインに投稿していました。ある日、兄がドイツ最高峰ツークシュピッツェ山の登山を記録するというアイデアを思い付きました。


兄と私は過去にツークシュピッツェ山の山頂まで登ったことはありますが、兄のアイデアを実現するために何が必要なのかはすぐには明確になりませんでした。およそ 1 万フィートの山頂にたどり着くのは簡単ではありません。登山を記録するのに必要な撮影機材すべてを携えた状態では、特にそうです。距離 にして 6 マイル、高度 6,500 フィートだけでも十分なのに、山頂までには Höllentalklamm 渓谷や Höllentalferner 氷河などの険しい地帯もあります。しかし、兄はこの一見不可能に思える偉業を、私と一緒に達成したいと言いました。に私の同意を取り付けました。

ドイツ最高峰のマップ化の計画

計画段階で、解決困難な多くのことに直面しました。登山をバーチャル化するには、どの程度の数のパノラマ写真が必要なのか。これらの写真すべてを撮影するには、どの程度の時間が必要なのか。休憩や充電はどこで行うのか。最終的に誰もが使える Web アプリを作ることは最初から明白で、その方法はすでにわかっていました。

さらに検討を重ね、天候に恵まれることも期待し、十分な自信を持ってこの試みを開始しました。カメラや三脚、GPS デバイス、必要なすべての登山用品を携え、休むことなく徐々に登山の様子を記録しました。多くの登山者が通り過ぎていきましたが、「この二人は一体何をやってるんだ」と思ったことでしょう。



山で 2 週間過ごした後、数千フィートの高さを登って疲労困憊した状態で、この骨の折れる冒険をやり遂げたという、達成感に浸る間もなく、数ギガバイトの画像を携えて帰宅の途につきました。しかし、画像を確認したところ、画像をオンラインにアップロードする作業は、画像を撮るのと同じぐらいに大掛かりな作業であることが判明しました。兄は何週間もかけて 1 つ 1 つの画像をつなぎ合わせる作業をおこない、その間、私はパノラマ写真をオンラインにアップロードするのに最適な方法を調べていました。

Google Maps Platform による ZUGSPITZE 360° の実現

これまでの経験から、Google Maps Platform が、360 度写真のホスティングを含め、有益かつ強力な一連の API を提供していることは理解していました。今回のプロジェクトでは、画像の量とサイズが膨大なため、大容量データをコスト効率よくホスティングする必要がありました。

パノラマ写真をアップロードするために、まずはストリートビュー アプリを使用した後で、Street View Publish API を使用しました。この方法で、バイナリ データだけでなく、パノラマ写真の実際の緯度・経度やパノラマ写真の相関関係などのメタデータも転送することができました。
カスタム構築のフロントエンドでは、Google Maps Platform の Maps Javascript API を使用してパノラマ写真を取得、表示しています。これは、通常のストリートビュー画像の表示に慣れているからです。Maps Javascript API では、このような操作方法を解説したとても詳しいドキュメントが公開されています。アップロードしたパノラマ写真のmatching ID を把握するため、情報を抽出するちょっとしたヘルパーツールをいくつか作成しました。さまざまなパノラマ写真をユーザーがナビゲートできるだけでなく、あらかじめ定めたツアーの見所にもユーザーがジャンプできるようにすることを目的としていました。


パノラマ写真とその正確な位置を照合する作業も難しいことに気付きました。険しい崖や狭い渓谷があるため、GPS の記録は必ずしも正確ではありません。期待される正確な位置というよりも、むしろクモの巣のような状態のときもありました。パノラマ写真をマップ内の対応する位置に配置し、さらに実際に歩いた経路を残すためのデータが必要でした。これを行うために Roads API を使用しました。Roads API によって、記録した GPS 座標を最も近い既知の道にスナップすることができました。また、より正確なものになるように、手作業でいくつか修正を加えました。
ZUGSPITZE 360° では、ツアー以外に小道や見所に関する情報も提供しており、追加の写真や該当する場所までの所要時間、距離などの詳細情報も合わせて示しています。また、ツークシュピッツェ山が登山口からどの程度離れているか、登山を開始できる起点に行くには出発点からどの経路をとるかを示したマップなど、登山を計画する場合に、登山前の検討や準備に役立つ貴重な推奨事項も多数掲載しています。これを行うのに、Directions API が役立ちました。

最後になりますが、登山者が自身の期待を共有できるようにしたいと考えていました。そこで、Street View Static API を使用して、ツアーの共有リンクに各パノラマビューを共有可能な形式で含めました。


Google Maps Platform のおかげで、自分たちの構想を実現することができました。最初は単純なアイデアだったものが、あらゆる人々を支援する複雑なプロジェクトに発展しました。このプロジェクトを実際に利用する人がどれほどいるのか、見当もつきませんでした。当然ながら、最も顕著な利用者は、テクノロジーや写真撮影というバックグラウンドが似ている、同じ志を持つ人々ですが、それ以外の多くの人々からもコメントが寄せられています。山頂に上ることを夢見て、家族を Höllentalangerhütte（山小屋）に連れて行った父親がいます。どのような用具が必要かもわからない登山初心者もいます。登山ルートを把握しており、プロジェクトを利用してフォロワーに危険な箇所を示している熱烈な登山家や登山指導者もいます。数十年前にこの山を登ったが、年齢や健康上の理由からこのルートを登れなくなった人から寄せられたコメントは最も心動かされるものでした。

私たちは本当に多くのことを学びました。膨大な労力を要するからと、開発をあきらめなくて良かったです。ZUGSPITZE 360° が熱烈な登山者に価値あるサービスを提供し続けることを心から願っています。

Google Maps Platform の詳細については、こちらの Web サイトを参照してください。

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカルアカウントマネージャ

この記事は、Google の Engineering Director である Andrew Lookingbill と Product Management Director の Ethan Russell による Google Maps Platform Blog の記事 " Beyond the Map: How we build the maps that power your apps and business" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

編集者より: この投稿は、Andrew Lookingbill と Ethan Russell によるものです。Googler 歴が長い 2 人の目標は、世界をマッピングして、世界中からアクセス可能な便利な地図を作ることです。絶え間なく進化する世界に適した地図を Google がどのように構築しているのか詳しく紹介していきます。デベロッパーには、革新的なユーザーエクスペリエンスを提供するために必要となるデータを、企業には、企業活動を最適化するのに役立つ位置情報ベースの知見を合わせてお伝えします。今回は、マッピングの基礎の紹介です。

十億以上の人々が Google マップを使って世界各地を探索しています。数百万ものアプリ、エクスペリエンスが Google のデータを使って構築されており、幅広いユーザー層やユースケースに対応したマップを Google はどのように構築しているのかという質問を受けることが多くなりました。その答えは、10 年以上にわたる基礎作りと、最新かつ正確なデータおよび知見を求めるユーザーの期待に対応できるようテクノロジーを改良することへの強いこだわりにあります。

画像への初期投資

Google は、Google マップと Google Maps Platform （旧称 Google Maps APIs）を発表して、わずか数年後にストリートビューを発表しました。一般ユーザーにとって、ストリートビューは自宅にいながら全世界をバーチャルに探索するのに役立ちます。Google はこの豊富な画像データセットを企業が利用できるようにしています。企業は自身が所有するアプリで実世界のコンテキストを提供することができます。たとえば、Trulia のような不動産サイトでは、Web サイトとアプリを使用して住宅購入予定者が近隣をバーチャルに探索して、好きな場所を見つけることをサポートをします。

このストリートビューによって後々のマッピングプロセス基盤ができました。Google の機械学習テクノロジーの進展と、87 か国、1,700 億を超えるストリートビュー画像により、これらの画像から自動的に情報を抽出し、顧客向けに道路名や住所、会社名などのデータを常に最新の状態にしておくことが可能です。「一枚の絵は千の言葉に値する」と言いますが、高解像度のパノラマ画像は 100 万の言葉に匹敵します。そのため、最高品質の画像や知見を顧客に提供できるよう、Google では高解像度のセンサーなどを装備した最新のトレッカー（英語）など、独自のハードウェアを開発しています。

信頼できる機関との提携

Google のプラットフォームを使ってミッションクリティカルなアプリ開発を検討している企業にとって、信頼できる最新情報の提供は不可欠です。そのため、Google では、米国地質調査所、メキシコの国立統計地理情報院（INEGI）、その他の自治体や宅地造成業者など世界中の 1,000 以上の信頼できるデータソースを使用しています。


実際の人々、実際のインサイト

データと画像は、地図作成の重要な要素です。ただし、データと画像は静的であるため、必要とされる特定の場所のコンテキストが必ずしも得られるわけではありません。通りのどこにいるかをコンテキスト化するのにストリートビューが役立つと考えるのであれば、レストランやコーヒーショップなどの特定の場所をコンテキスト化するのにユーザー作成コンテンツが役立つと考えるでしょう。熱烈なローカルガイド コミュニティ、アクティブな Google ユーザー、および Google マイビジネスを使用している事業主のおかげで、Google には道路閉鎖から特定の場所の雰囲気や新規ビジネスなどにいたるまで、ユーザーから毎日 2,000 万件もの情報が寄せられています。そして、情報が正確であることが十分確信できる場合にのみ、これらの情報を公開しています。

Google では、世界中の 1 億 5,000 万を超える場所に関してデータセットを構築することが可能になっており、Places API を通じてこのデータセットをデベロッパーに提供しています。Places API は、場所の名前、住所、評価、クチコミ、連絡先情報、営業時間、雰囲気に関する豊富なデータを備えています。このデータを使うことで、ユーザーはただ単にレストランを見つけるだけでなく、ベジタリアン向けのメニューがあり子供にも適したレストランを見つけることも可能です。

機械学習による革新速度と成長の維持 

ここまでで紹介したプロセスを経て、Google は信頼できる有益な地図を作成しています。しかし、もう一つスピードという大きな課題も存在します。Google のお客様が迅速に行動して革新を遂げる、その原動力となるためには、Google もかつてないほど迅速に世界を地図化する必要があります。世界各地で急速に変化が進む中、新しい情報を地図や製品にすばやく取り込まなければなりません。世界を地図化する速度を加速し、高い精度を維持しながら地図作成プロセスを自動化するよう、Google では機械学習に目を向けています。

Google が「曖昧な建物」と呼んでいる問題を機械学習でどのように解決したのか、例を挙げて説明します。Google では、画像の一部が建物かどうかを推測するアルゴリズムの課題に悩んでいました。これを解決するため、データ運用チームと協力し、一般的な建物の外形を手作業でトレースしました。現時点では、これが最善の解決策となっています。ただし、世界中の一般的な建物の外形すべてを手作業でトレースするには膨大な時間が必要です。そこで、一般的な建物の外形をトレースした後、この情報を使用し、どのような外形の建物が実際に存在する傾向にあるのか、および画像のどの部分が建物の境界や外形に対応するのかを機械学習しました。この方法によって、過去 10 年間に地図化した建物と同数の建物を 1 年間で地図化することができました。結果、Google が顧客と共有している地図が大幅に改善されています。


ストリート名がない場合の対応

ストリートビュー画像からの情報抽出については、前述したとおりです。Google は、機械学習とストリートビュー画像を併用することで、世界中のほぼすべての場所で家の番地を自動的に特定することができます。また、これは、世界で 220 を超える国や地域のマッピングを大幅に進展させるのに役立っています。

ただし、すべての家に実際に番地があるとは限りません。そのため、Google マップと Google Maps Platform では plus code をサポートしています。plus code は番地と同じように機能します。これにより、世界中の誰もが、友人や配送サービスと共有したりメールの送受信に使用したりできる住所を持つことが可能です。plus code はオープンソースであるため、どのデベロッパーでも入手、使用でき、Places API や Geocoding API にも組み込まれています。

これらの地域の地図化を支援し、すべての人々に住所を付与し、Google の API 製品にアクセスできるようにすることで、企業や地方自治体が地域社会に向けたサービスを向上でき、ロケーションベースの新しいエコシステムを成長させる機会も増大します。plus code の使用については、こちらにお問い合わせください。

長期にわたる取り組み

Google で 10 年余りを過ごした今でも（2 人合わせると 25 年）、実際の世界の変化に遅れをとらずついていく地図作成にワクワクして取り組んでいます。世界が変化するにつれ、人々を支援するためだけでなく、ビジネスの原動力となり、企業活動、業界、さらには世界をも変革するロケーションベースのツールを提供するために、Google は常に技術革新を行っています。

次回は、さまざまな地域での地図作成の課題に目を向け、これらの課題を克服するのに画像がいかに役立っているのか、これが企業やデベロッパーにとって何を意味するのかについて説明します。Google Maps Platform の詳細については、Google の Web サイトを参照してください。

本投稿に寄与したカスタマー エンジニアリング部門グローバルリードの Dave McClusky に感謝の意を表します。

Posted by 丸山 智康 (Tomoyasu Maruyama)  - Google Maps テクニカルアカウントマネージャ

Google Cloud Japan は 9 月 3 日 （火）、開発エンジニア、インフラエンジニア、運用エンジニア向けに「Google Cloud Kubernetes Day」を開催いたします。

実際に Kubernetes 環境でアプリやサービスの開発を実践されている先進的な企業を迎え、それぞれのアプリケーションのモダナイゼーションや、Kubernetes の事例についてお話しいただきます。
また、深い専門知識をもつ Google Cloud のエンジニアが、Google Kubernetes Engine (GKE) をはじめとした Google Cloud Platform を利用し、どのようにアプリやサービスのコンテナ化を行うのか、開発、運用の実際について解説します。

セミナー終了後は同会場にて懇親会を開催いたします。
ぜひ、Google Cloud Kubernetes Day にご参加ください。

申し込みはこちら
https://goo.gle/k8sdaybg


Posted by Takuo Suzuki - Developer Relations Team

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

第 10 回目となる今回は、「事業戦略と IT の融合：テクノロジー企業化への不可避な流れ」がテーマです。あらゆる業種、業態の企業において、事業戦略と IT の融合が一層求められています。そんな中で、どのような組織やリーダーシップが必要なのか、リーダーが注目するテクノロジーやエコシステムは何なのか？ について、掘り下げていきます。
Google からは、ワークトランスフォーメーションについて、先日行われた Cloud Next ‘19 in Tokyo で発表された製品・サービスや活用事例を中心にお話します。
講演会後には恒例の交流会も行います。参加者様同士の交流はもちろん、日頃の業務の課題や悩みについても、ご相談 / 共有いただける良い機会となります。

本テーマにご関心のある方々のご参加をお待ちしています。

【開催概要】
イベント名 : INEVITABLE ja night - “インターネットの次にくるもの”
　　　　　　第 10 回 事業戦略と IT の融合：テクノロジー企業化への不可避な流れ
日程 : 2019 年 9 月 17 日（火） 19:00 〜 21:00（開場 18:30 より）
会場 : グーグル合同会社
定員 : 200 名
ハッシュタグ : #inevitableja

プログラム :
INEVITABLE 対談　
　スピーカー：
　　小野 和俊 氏　株式会社クレディセゾン　取締役
　　辻 裕里 氏　　株式会社SUBARU　IT戦略本部情報企画部担当部長
　　長谷川 秀樹 氏　株式会社メルカリ　CIO
　聞き手：
　　小島 英揮 氏、Still Day One合同会社 代表社員 パラレルマーケター・エバンジェリスト

ゲスト講演：
　　辻村 孝嗣 氏　株式会社BoxJapan エンタープライズ営業1部 シニアエンタープライズアカウントエグゼクティブ

Google テクノロジーアップデート：
　　小林 直史 グーグル・クラウド・ジャパン合同会社 カスタマーエンジニア

申し込みサイト：https://goo.gle/2Z9hqRg

多数のご参加をお待ちしております。
Posted by Takuo Suzuki - Developer Relations Team

先日の投稿でお知らせしました通り、Google は Machine Learning （機械学習） の専門的な知識を持たない方向けにトレーニングを無料で提供するプログラム「ML Study Jams vol.3」を 2019 年 8 月 20 日（火）から 9 月 15 日（日）の期間中に開催します。





本日は、今回の ML Study Jams 期間中に使用する受講コースを決定いたしましたので、ご連絡いたします。

初心者向け

1) How Google does Machine Learning
2) Launching into Machine Learning


中級者向け

1) End-to-End Machine Learning with TensorFlow on GCP
2) Google Cloud Platform Big Data and Machine Learning Fundamentals

すでに以前の ML Study Jams で Machine Learning の基礎を学んだ方でも、新たな中級者向けコースで Machine Learning について学ぶことができます。




本プログラムは、オンライン学習プラットフォーム、Coursera 上にある Machine Learning 関連のコードラボを利用して行います。


今回のプログラムでは、チーム単位で参加しチーム毎に開催する形式となります。受講する仲間がいない方については、地域ごとのチームマッチングもサポートする予定です。チームがまだ決まっていない方も、登録してみてください。

この記事は Stan Grinberg による Google Ads Developer Blog の記事 "Campaign IDs and Budget IDs as 64-bit in Google Ads" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Florina Muntenescu による Android Developers - Medium の記事 "Collections and sequences in Kotlin" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

コレクションを使った処理は一般的で、Kotlin の標準ライブラリにもたくさんの便利なユーティリティ関数が準備されています。さらに、評価方法の違いによる 2 つの方法でコレクションを処理できます。すなわち、Collection を使うと積極的処理を、Sequence を使うと遅延処理を行うことができます。この記事では、この 2 つの違いに加え、どの場合にどちらを使うべきか、またそれぞれのパフォーマンスへの影響について説明します。

コレクションとシーケンス

積極的評価と遅延評価の違いは、コレクションに対する変換が実行される タイミング にあります。
コレクションは 積極的 に評価されます。つまり、各操作は呼び出されたときに実行され、その結果が新しいコレクションに格納されます。コレクションに対する変換は、インライン関数です。例として、map がどのように実装されているかを見てみると、新しい ArrayList を作成するインライン関数であることがわかります。

public inline fun <T, R> Iterable<T>.map(transform: (T) -> R): List<R> {
  return mapTo(ArrayList<R>(collectionSizeOrDefault(10)), transform)
}

シーケンスは 遅延 評価されます。シーケンスには、中間操作と末端操作の 2 とおりの操作があります。中間操作は即時実行されず、単に格納されるだけです。末端操作が呼び出されると、各要素に対して順番に中間操作が呼び出され、最後に末端操作が適用されます。中間操作（map、distinct、groupBy など）は別のシーケンスを返しますが、末端操作（first、toList、count など）はシーケンスを返しません。
シーケンスは集合内のアイテムへの参照は保持していません。シーケンスは元となるコレクションのイテレータから作られ、実行する必要があるすべての中間操作への参照を保持しています。
コレクションに対する変換とは異なり、シーケンスの中間操作による変換はインライン関数ではありません。インライン関数は格納することができませんが、シーケンスは変換処理を格納しなければなりません。map などの中間操作がどのように実装されているかを見てみると、新しい Sequence インスタンスの中に変換関数が格納されていることがわかります。

public fun <T, R> Sequence<T>.map(transform: (T) -> R): Sequence<R>{      
   return TransformingSequence(this, transform)
}

first などの末端操作は、述部条件に該当するまで、シーケンスの要素に対して反復処理を行います。

public inline fun <T> Sequence<T>.first(predicate: (T) -> Boolean): T {
   for (element in this) if (predicate(element)) return element
   throw NoSuchElementException(“Sequence contains no element matching the predicate.”)
}

TransformingSequence（上の map で使われています）などのシーケンスの実装方法を見てみると、シーケンスのイテレータから next が呼ばれたタイミングで、格納されている変換も適用されていることがわかります。

internal class TransformingIndexedSequence<T, R> 
constructor(private val sequence: Sequence<T>, private val transformer: (Int, T) -> R) : Sequence<R> {

override fun iterator(): Iterator<R> = object : Iterator<R> {
   …
   override fun next(): R {
     return transformer(checkIndexOverflow(index++), iterator.next())
   }
   …
}

Kotlin 標準ライブラリでは、使っているのがコレクションかシーケンスかによらず、両方に対して find、filter、groupBy などの非常に幅広いオペレーションが提供されています。そのため、独自の操作を実装する前に、オペレーションを確認するようにしましょう。

コレクションとシーケンス

さまざまな図形を表すオブジェクトのリストがあるとします。それらの図形を黄色にした上で、最初に登場する正方形を探す場合を考えてみましょう。

コレクションとシーケンスにそれぞれの操作が適用される方法とタイミングを確認します。

コレクション

• map の呼び出し — 新しい ArrayList が作成されます。最初のコレクションにあるすべてのアイテムに対して反復処理を行い、元のオブジェクトをコピーして色を変えることにより、変換を行います。次に、その結果を新しいリストに追加します。
• first の呼び出し — 最初の正方形が見つかるまで、各アイテムの反復処理を行います。

シーケンス

• asSequence — 元となるコレクションのイテレータからシーケンスが作成されます。
• map の呼び出し — シーケンスが実行しなければならない操作リストに変換が追加されますが、操作自体は実行されません。
• first の呼び出し — これは末端操作なので、コレクションの各要素に対してすべての中間操作が呼び出されます。最初のコレクションに対して反復処理を行い、各アイテムに map と first をこの順番で適用します。2 つ目の要素で first の条件が満たされるので、コレクションの残りの要素に対して map が適用されることはありません。

シーケンスを使う場合、中間コレクションは作成されません。アイテムが 1 つずつ評価されるので、map は入力の一部に対してのみ実行されます。

パフォーマンス

変換の順番

大事なのは変換の順番です。この点は、コレクションとシーケンスのどちらを使うかにはよりません。先ほどの例は map 変換の結果ではないので、map を実行した後に first を実行する必要はありません。ビジネス ロジックの順番を逆転させ、コレクションに対して first を呼び出してからその結果を変換する場合でも、作成されるのは新しいオブジェクトである黄色い正方形 1 つだけです。シーケンスを使う場合は 2 つの新しいオブジェクトを作ることは避け、コレクションを使う場合はリスト全体を作ることを避けます。

シーケンスを使うと、末端操作によって処理を切り上げることができる可能性があり、中間操作は遅延評価されるので、コレクションを使う場合に比べて不要な操作を省略できる可能性があります。変換の順番と変換同士の依存性について、常に確認するようにしましょう。

大きなデータセットをインライン化することによる影響

コレクション操作はインライン関数を使用しています。そのため、操作のバイトコードと、それに渡されるラムダ式のバイトコードがインライン化されます。シーケンスはインライン関数を使わないので、操作のたびに新しい Function オブジェクトが作成されます。
コレクションではすべての変換に対して新しいリストが作成されますが、シーケンスでは変換関数への参照が保持されるだけです。
1 つか 2 つの操作がある小さなコレクションを処理する場合、この違いによって大きな影響が生じることはありません。そのため、コレクションを使っても問題はないはずです。しかし、中間コレクションの作成を伴う大きなリストの処理は、大きな負荷となる可能性があります。そのような場合は、シーケンスを使うようにします。
残念ながら、コレクションやオペレーション チェーンのサイズがコレクションやシーケンスのパフォーマンスに与える影響について調査したベンチマークはないようです。
コレクションはデータを積極的に評価しますが、シーケンスは遅延評価します。データのサイズに応じて、最適なものを選ぶようにしましょう。小さなリストにはコレクションを、大きなリストにはシーケンスを使い、変換の順序に注意するようにしてください。

Reviewed by Yuichi Araki - Developer Relations Team

Google は Machine Learning （機械学習） の専門的な知識を持たない方向けにトレーニングを無料で提供するプログラム「ML Study Jams vol.3」を 2019 年 8 月 20 日（火）から 9 月 15 日（日）の期間中に開催します。




本プログラムは、オンライン学習プラットフォーム、Coursera 上にある Machine Learning 関連のコードラボを利用して行います。

今回のプログラムでは、チーム単位で参加しチーム毎に開催する形式となります。

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



Android Q ベータ版 5 が先日リリースされました。ベータ版 5 は、Android Q ベータ版として最終リリース版のシステム動作にかなり近いものになっています。デベロッパー API は、前回のアップデートで既に最終版になっています。そのため、アプリの互換性をテストして準備ができていることを確かめるには、今が絶好のタイミングです！

Pixel 端末をお持ちの方は、こちらで登録するとベータ版 5 を入手できます。登録済みで、Pixel 端末でベータ版 4 を受信している場合は、ベータ版 5 へのアップデートを自動的に取得できます。Android Q ベータ版プログラムに参加しているパートナーも、今後数週間で端末をベータ版 5 にアップデートする予定です。

Android Q ベータ版を使ってみたい方は、developer.android.com/preview をご覧ください。

この記事は デベロッパー アドボケート、Oscar Rodriguez による Android Developers Blog の記事 "Advanced in-app billing: handling alternative purchase flows" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


アプリやゲームを設計して開発するにつれ、収益化をどうするかが考え始めるときがあるでしょう。
Google Play でプロダクトを販売して収益化すると決めたら、販売するアイテムを表示するストア画面を作り、Google Play Billing Library を使ってユーザーが購入するダイアログを表示することになるでしょう。
ドキュメントや Billing Library TrivialDrive サンプルには詳しい説明が掲載されていますが、一般的なフローは次のようになります。

1. UI スレッドから launchBillingFlow() メソッドを呼び出し、Google Play 購入ダイアログを表示します。
2. 購入が成功すると、Google Play によって onPurchasesUpdated() メソッドが呼ばれ、購入オペレーションの結果が渡されます。
3. アプリにサーバーがある場合、サーバーから購入を検証することを強くお勧めします。これには、Subscriptions and In-App Purchases API を使います。
4. 消費可能アイテムは consumeAsync() で、消費不可アイテムは acknowledgePurchase() で購入を承諾します。
5. 最後に、アプリ内で購入したアイテムを付与します。

まだ Google Play Billing AIDL API を使い続けているアプリでも、同じタスクを実行できます。なお、AIDL API は非推奨となっているので、できるだけ早く Google Play Billing Library に移行することを強くお勧めします。
AIDL API でも、フローはほぼ同じです。

1. getBuyIntent() リクエストまたは getBuyIntentExtraParams() リクエストを送って購入するアイテムを指定し、続いて startIntentSenderForResult() を呼び出して Google Play 購入ダイアログを表示します。
2. 購入ダイアログが閉じられると、Google Play によって onActivityResult() メソッドに応答の Intent が送られます。ここで、購入が成功したかどうかを確認できます。
3. アプリにサーバーがある場合、サーバーから購入を検証することを強くお勧めします。これには、Subscriptions and In-App Purchases API を使います。
4. 購入が成功した場合、getPurchases() メソッドを呼び出して、まだ消費されていない所有アイテムの一覧を取得します。消費可能アイテムの場合は、consumePurchase() メソッドを呼び出して再購入できるようにします。
5. 最後に、アプリ内で購入したアイテムを付与します。

ただし、以上のフローを実装しただけでは、すべてのタイプの購入を正しく処理することはできません。このフローで正しく購入を処理できないのは、主に 2 つの場合です。
1 つ目は、購入フローが完了する前に中断された場合です。たとえば、アプリがクラッシュした、ユーザーがアプリを強制終了させた、インターネット接続が失われた、などが考えられます。いずれにしても、Google Play で支払いの処理が終わっているにもかかわらず、ユーザーにアイテムが提供されていない状況に陥る可能性があります。この場合、アイテムは中途半端な状態です。Google Play はアイテムを消費するまで再購入が認められませんが、アプリやゲームでは前述のフロー以外でアイテムが消費されることはないからです。
2 つ目は、別の購入フローによって発生します。別の購入フローとは、アプリ内プロモーション、最近発表されたアプリ外サブスクリプション サーフェス、サブスクリプション用プロモーション コード、Google と連携したその他のプロモーションなどを指します。この場合、ユーザーは Play ストアアプリで直接アイテムを入手しますが、その間、対象のアプリやゲームは一時停止されているか実行されていない状態にあります。または、対象のアプリがインストールされていない可能性もあります。
このような場合に備えて、Google Play Billing Library と Google Play Billing AIDL API には、承諾または消費されていない購入を検知できる仕組みが組み込まれています。
Google Play Billing API を使っている場合、次のようにします。

1. アプリの onResume() コールバックで queryPurchases() メソッドを呼び出し、アイテムのリストを取得します。これを使って承諾していないアイテムを検知することができます。
2. アプリにサーバーがある場合、サーバーから購入を検証することを強くお勧めします。これには、Subscriptions and In-App Purchases API を使います。
3. 承諾されていない所有アイテムがある場合は、消費可能アイテムには consumeAsync() を、消費不可アイテムには acknowledgePurchase() を使って購入を承諾します。
4. 購入したアイテムをアプリ内で付与します。

Google Play Billing AIDL API では、次のようにします。

1. アプリの onResume() コールバックで getPurchases() メソッドを呼び出し、まだ消費されていない所有アイテムの一覧を取得します。
2. アプリにサーバーがある場合、サーバーから購入を検証することを強くお勧めします。これには、Subscriptions and In-App Purchases API を使います。
3. 消費可能アイテムの場合は、consumePurchase() メソッドを呼び出して再購入できるようにします。
4. 最後に、アプリ内で購入したアイテムを付与します。

どちらの場合でも、この方法で消費されていないアイテムを検知して処理する場合は、ユーザーはアプリやゲームがそのアイテムについて通知してくれることを期待します。ダイアログやメッセージ ボックス、通知を表示し、アイテムが入手できたことをユーザーにお知らせすることをお勧めします。
アプリの onResume() コールバックは、プロセスが開始した場合に加え、フォアグラウンドになった場合にも呼ばれる点に注意してください。アプリやゲームが一時停止する前にどのような画面が表示されていたかにはよりません。たとえば、ホーム画面、ストア画面、ゲーム画面があるゲームでは、すべての画面から onResume() が呼ばれる可能性があります。最適なユーザー エクスペリエンスを実現するために、onResume() が呼ばれた際に表示されている画面に関係なく、承諾または消費していないアイテムを処理できるようにすることをお勧めします。優れたユーザー エクスペリエンスを提供するには、それぞれの画面でこの処理を徹底的にテストすることが欠かせません。
最後に、アプリで処理しなければならないもう 1 つのケースが存在します。それは、Play ストアアプリでアイテムを入手した際に、マルチウィンドウ モードで Play ストアアプリと対象のアプリの両方が見えている場合です。
Google Play Billing Library でこれをサポートするには、次のようにします。

1. 保留になっている新しいアイテムがあることをアプリに通知するため、Google Play によって onPurchasesUpdated() メソッドが呼ばれます。
2. アプリにサーバーがある場合、サーバーから購入を検証することを強くお勧めします。これには、Subscriptions and In-App Purchases API を使います。
3. 消費可能アイテムは consumeAsync() で、消費不可アイテムは acknowledgePurchase() で購入を承諾します。
4. 最後に、アプリ内で購入したアイテムを付与します。

Google Play Billing AIDL API では、次のようにします。

1. アプリの onResume() コールバックで PurchasesUpdatedListener を登録し、com.android.vending.billing.PURCHASES_UPDATED インテントを受け取れるようにします。また、アプリの onPause() コールバックでリスナーの登録を解除します。
2. アプリにサーバーがある場合、サーバーから購入を検証することを強くお勧めします。これには、Subscriptions and In-App Purchases API を使います。
3. 保留になっている新しいアイテムがあることをアプリに通知するため、Google Play によってリスナーが呼ばれます。リスナーで getPurchases() メソッドを呼び出し、まだ消費されていない所有アイテムの一覧を取得します。消費可能アイテムの場合は、consumePurchase() メソッドを呼び出して再購入できるようにします。
4. 最後に、アプリ内で購入したアイテムを付与します。

先ほどと同じように、ダイアログやメッセージ ボックス、通知を表示し、アイテムが入手できたことをユーザーにお知らせしましょう。
以上の手順に従えば、アプリやゲームは購入フローの中断や別の購入フローに確実に対処できるようになります。

Reviewed by Yuichi Araki - Developer Relations Team