Quantcast
Channel: Google Developers Japan
Viewing all 2204 articles
Browse latest View live

さらに効率的になった Cloud Functions の Realtime Database トリガー

$
0
0
この記事はデベロッパー アドボケート、Doug Stevenson による The Firebase Blog の記事 "Cloud Functions Realtime Database Triggers Are Now More Efficient" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 
 
Cloud Functions for Firebase チームとの仕事で特にやりがいがあるのは、モバイルアプリから Firebase がホストするフル マネージドなバックエンドにロジックを移行するデベロッパーの皆さんをお手伝いできる事です。ロジックはわずか数行の JavaScript コードで組み込むことができ、Realtime Database の内容が変更された際に自動でアクションを実行できます。皆さんが開発するものを見るのは本当に楽しいことです。  
データベースの変更にはさまざまなタイプがありますが、Cloud Next 2017 で Cloud Functionsが最初に発表されたとき、トリガーは 1 つしかありませんでした。このトリガーは onWrite()コールバックを使って指定するもので、どのような変更が行われたのかを判断するのは、コードを書いたエンジニアの責任でした。たとえば、アプリにチャットルームがあり、新しいメッセージが届いた際に Firebase Cloud Messaging を使ってそのチャットルームのユーザーに通知を送ることを考えてみましょう。これを実装するには、次のようなコードを記述します。
 
exports.sendNotification = functions.database
.ref("/messages/{messageId}").onWrite(event => {
const dsnap = event.data // a DeltaSnapshot that describes the write
if (dsnap.exists() && !dsnap.previous.exists()) {
// This is a new message, not a change or a delete.
// Send notifications with FCM...
}
})

ここでの注意点として、イベント オブジェクトの DeltaSnapshotをチェックし、書き込まれたロケーションに新しいデータや以前のデータが存在するかどうかを確認しなければなりません。その理由は、onWrite()は、該当するロケーションに対する すべてのデータの変更に対して呼び出されるからです。これには、メッセージの新規作成、変更、削除が含まれます。しかし、この機能は 新しいメッセージのみを対象とするものです。そのため、書き込みが更新や削除ではないことを確認しなければなりません。更新や削除が発生した場合、この機能は呼び出されてすぐに処理を終えることになります。このように余分な機能が実行されると、そのぶん費用がかさみます。皆さんも、役に立たない処理に対して課金されたくはないはずです。
 
改善された機能 

そこでうれしいお知らせです。Cloud Functions のデータベース トリガーで、この余分なチェックが不要になりました。firebase-functions モジュール バージョン 0.5.9 以降では、新たに 3 種類のデータベース トリガー onCreate()onUpdate()onDelete()を記述できます。これらのトリガーは変更のタイプを認識し、対象となる変更が発生したときにのみ実行されます。したがって、先ほどの機能は次のように書き換えることができます。
exports.sendNotification = functions.database
.ref("/messages/{messageId}").onCreate(event => {
// Send notifications with FCM...
})

同じロケーションのデータが更新されるたびにこの機能が再び呼び出されることを心配する必要はありません。これによって、コードが読みやすくなるだけでなく、運用費用も削減できます。  
なお、onWrite()はなくなったわけではないことに注意してください。このトリガーも引き続き自由に使うことができます。
 
onWrite()onUpdate()の無限ループを防ぐ 

あるロケーションのデータに対して onWrite()を使って追加や変更を行うと、onWrite()で行ったデータの変更によって、もう 1 度 onWrite()が呼ばれることを意識するようにしてください( すべての書き込みが書き込みとして扱われるためです)。
 
次のコードについて考えてみましょう。この機能を使ってメッセージが書き込まれた際に lastUpdated プロパティを更新します。  
exports.lastUpdate = functions.database
.ref("/messages/{messageId}").onWrite(event => {
const msg = event.data.val()
msg.lastUpdated = new Date().getTime()
return event.data.adminRef.set(msg)
})

最初は問題なさそうに思えますが、とても重要な点が抜けています。この機能は呼び出されたロケーションにデータを書き戻しているので、実は もう一度、onWrite()が呼ばれることになります。これが書き込みの無限ループを引き起こすことはおわかりでしょう。そのため、2 回目の呼び出しを防ぐ方法が必要になります。  
 
onUpdate()で機能を実装する場合も同じ問題が起きます。このようなケースの解決策の 1 つとして、既存の lastUpdated の値を確認し、現在日時から 30 秒以内である場合、処理を行わないことが考えられます。そのため、onUpdate()を使ってこの機能を書き直す場合、次のようになります。
exports.lastUpdate = functions.database
.ref("/messages/{messageId}").onUpdate(event => {
const msg = event.data.val()
const now = new Date().getTime()
if (msg.lastUpdated > now - (30*1000)) {
return
}
msg.lastUpdated = now
return event.data.adminRef.set(msg)
})

少しロジックを追加すれば、無限ループを防ぐことができます。  
 
今回紹介した新しいトリガーを利用する場合は、firebase-functions モジュールを 0.5.9 にアップデートしてください。これらのアップデートについての詳しい情報は、こちらのドキュメントをご覧ください。  
 
Reviewed by Takuo Suzuki - Developer Relations Team

Developer Preview 4 を公開、Android O の正式リリースが迫る!

$
0
0
この記事は エンジニアリング部門副社長、Dave Burke による Android Developers Blog の記事 "Developer Preview 4 now available, official Android O coming soon!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


本日(*原文公開当時)、最終調整が行われている Android O プラットフォームの Developer Preview 4 がリリースされました。ぜひ、アプリの準備ができていることをご確認ください。

Android O プラットフォームは今年の夏の終わりごろにユーザーに対して正式にリリースされますが、今回の Developer Preview 4 はその正式リリース前の最後のプレビュー版となります。ぜひこのチャンスを活用してテストを終わらせ、アップデートを公開して、ユーザーが Android O にスムーズに移行できるようにしましょう。

Android ベータ版プログラムに登録している端末には、今後数日で Developer Preview 4 へのアップデートが配布されます。まだ端末を登録していない場合は、Android ベータ版サイトにアクセスして登録し、アップデートを受信してください。

まもなく発表される Android O の正式リリースについての情報にもご期待ください。

今回のアップデートの内容


Developer Preview 4 は、Android O のリリース候補ビルドで、今後予定されている正式リリースに向けた開発やテストに利用できます。Developer Preview 4 には、最終的なシステムの動作、最新のバグ修正や最適化、Developer Preview 3以降で利用できるようになった最終 API(API レベル 26)が含まれています。

Developer Preview 4 の端末システム イメージも、Android 26.0.0 サポート ライブラリの安定版と合わせて本日リリースされています。SDK の増分アップデート、ツール、Android Emulator システム イメージも、数日中に公開される予定です。

また、Android Test Orchestrator、マルチプロセス Espresso などの新機能を含む新しいバージョンの Android Testing Support Libraryも導入されています。詳細は近日中にお伝えしますので、ご期待ください。

Android O でアプリをテストする


本日リリースされた Developer Preview 4 システム イメージを使うと、現在のアプリをほぼ最終版の Android O で適切にテストすることができます。今すぐテストをしておけば、ユーザーが Android O プラットフォームの正式リリースへのアップグレードを始める際に、皆さんが望む動作のアプリを提供できるようになります。

サポートされている端末を Android ベータ版プログラムに登録すると、本日のアップデートが OTA で配信され、Google Play から現在のアプリをインストールしてユーザーフローのテストを行えるようになります。アプリが適切な見栄えで動作し、Android O の動作の変更点に問題なく対応できようにしましょう。特に、バックグラウンド ロケーションの制限通知チャンネル、そしてネットワークセキュリティ識別子に関する変更点に注意してください。

問題を解決できたら、ユーザーが Android O を受信し始めたときにアプリが利用できるように、現在のターゲット レベルでアプリのアップデートを公開します。

Android O の機能と API を使用してアプリを強化する


通常、最新バージョンの Android をインストールしているユーザーは、アプリのダウンロード、コンテンツの消費、購入などをもっとも積極的に行っているユーザーです。同時に、お気に入りのアプリで最新の Android 機能がサポートされることを強く求めるユーザーでもあります。Android O のユーザーは、通知チャンネル通知ドットショートカットの固定ピクチャ イン ピクチャ自動入力などの機能がサポートされることを期待しています。時間とともに Android O にアップグレードするユーザーが増えるにつれて、これらの機能が活躍してアプリのエンゲージメントが高まります。

Android O では、ランチャーに特定のアプリのショートカットを直接固定し、エンゲージメントを高めることが可能。
ユーザーのアプリ利用率を向上させ、直接アプリの中心機能にジャンプできるようにする通知ドット。

Android O の機能でアプリを強化すると、ユーザーのエンゲージメントを高め、新しいインタラクションを提供できます。ユーザーはより多くのことを制御できるようになり、セキュリティも強固になります。さらに、パフォーマンスも向上させることができます。アダプティブ アイコンダウンロード可能フォントTextView の自動リサイズなどの機能を使うと、開発が楽になり、APK サイズも最小化できます。また、ユーザーは電池に多大な関心を寄せているので、バックグラウンドの実行制限を満たすように最適化されたアプリや、その他の O アプリの重要なシステム動作の変更に対応したアプリを見れば喜ぶことでしょう。

新機能や API、それをアプリに組み込む方法については、O Developer Preview サイトにアクセスしてご確認ください。

Android Studio で開発をスピードアップ


Android O 向けにビルドを行う準備ができた方は、Canary チャンネルからダウンロードできる最新版の Android Studio 3.0にアップデートすることをおすすめします。Android Studio 3.0 では、アプリのパフォーマンス プロファイリング ツールの改善、Kotlin プログラミング言語のサポート、Gradle ビルドの最適化が行われています。さらに、Instant AppsXML フォントや Downloadable Fonts 、 Adaptive Icons などで開発も簡単になります。

また、安定版の Android サポート ライブラリ 26.0.0へのアップデートもおすすめします。これは、Google の Maven レポジトリで公開されています。合わせて、近日中に公開される最新の SDK、ツール、エミュレータ システム イメージのアップデートもご利用ください。

プロジェクトの compileSdkVersion を API 26 にアップデートして正式な Android O API でコンパイルすることもできます。また、アプリの targetSdkVersion を API 26 に更新して、Android O に固有の動作の変更をオプトインし、アプリのテストを行うことをおすすめします。Android O でビルドするための環境設定の詳しい手順については、移行ガイドをご覧ください。

アップデートを Google Play に公開する


Google Play では、API 26 でコンパイルしたアプリや、API 26 をターゲットにしたアプリを受け付けています。準備ができ次第、APK のアップデートをアルファ版、ベータ版、または本番チャンネルで公開しましょう。

Android O だけでなく、古いバージョンでもアップデートしたアプリが問題なく動作することを確認しておきましょう。まずは、Google Play のベータ版テスト機能を使って、少人数のユーザーから初期段階でのフィードバックを入手することをおすすめします。その後、段階的にリリースを行います。皆さんのアプリのアップデートを楽しみにしています。

Developer Preview 4 を入手する方法


Developer Preview 4 は、まだインストールしていない方でも簡単に入手することができます。android.com/betaにアクセスして、対象のスマートフォンまたはタブレットをオプトインしてください。通常どおり、このアップデートを手動でダウンロードして端末に書き込むこともできます。O Developer Preview は、Pixel、Pixel XL、Pixel C、Nexus 5X、Nexus 6P、Nexus Player に加え、Android Emulator でも利用いただけます。登録済みの端末は、正式版の Android O がリリースされた際に自動的にアップデートされます。

プレビューのフィードバックをお寄せくださった皆さま、どうもありがとうございます。フィードバックやリクエストは、これからも大歓迎です!



Reviewed by Takeshi Hagikura - Developer Relations Team

Android O のショートカットとウィジェットの新機能

$
0
0
この記事は アソシエイト プロダクト マネージャー インターン、Gloria Liou による Android Developers Blog の記事 "What’s new for shortcuts and widgets in Android O" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 
 
ショートカットとウィジェットを使う理由 
 
Android O で私たちが特に気に入っている機能に、ディープリンクされたアプリのショートカットやウィジェットをランチャーに固定する機能があります。  
 
ショートカットは特定のタスクをすばやく開始するため、ウィジェットはアプリが提供する特定のアクションや情報にすばやくアクセスするためのものです。ユーザーはやるべきことをすばやく終わらせたいと考えています。ショートカットとウィジェットはそれを実現し、コンテンツへのユーザー エンゲージメントを高める手段になります。  
 
ショートカットやウィジェットを固定するには、アプリのアイコンを長押ししてオプションを表示し、項目を選択して任意のロケーションにドラッグ&ドロップします。  


動的/静的なショートカット
ショートカットの固定

アプリの内部からショートカットやウィジェットを追加する


 
アプリの内部からショートカットやウィジェットを追加する新しいフローが API として提供されています。この新しい方法は、モーダル ダイアログを使います。ブロードキャストを使う古い方法はサポートを終了しておりO 端末では動作しません。  
 
さらに、ユーザー インターフェースやユーザー エクスペリエンスも改善されました。古い方法では、ショートカットにアプリのアイコンが表示されなかったので、ショートカットがどのアプリのものかわかりませんでした。ショートカットにアプリのアイコンが表示されるようになったため、アプリが判別しやすくなっただけでなく、不正なソフトウェアからユーザーを保護することにもつながります。





古いショートカット
新しいショートカット


また、ユーザーがショートカットを作成しやすいように、専用のアクティビティを追加することもできるようになっています。このアクティビティには、カスタムのオプションと確認機能を搭載できます。  
 

 
このような新機能や機能強化によって、ユーザーがショートカットやウィジェットを使う可能性は高くなるでしょう。有意義で効果的なアプリとのエンゲージメントが実現できるので、ユーザーも満足し、生産性が向上します。  
 
詳細は、Android Developers サイトのショートカットとウィジェットのページをご覧ください。  
 
Reviewed by Takeshi Hagikura - Developer Relations Team

Nearby Connections 2.0 のご紹介: 完全オフライン、高帯域幅のピアツーピア端末間通信

$
0
0
この記事は プロダクト マネージャー、Ritesh Nayak M による Android Developers Blog の記事 "Announcing Nearby Connections 2.0: fully offline, high bandwidth peer to peer device communication" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


ホテルの部屋に入ったとき、室温がほどよく調整され、BGM にはお気に入りの音楽が流れ、TV では楽しみな番組が録画済みで再生されるのを待っていたらどうでしょうか。また夫婦で一緒に過ごしているとき、スマートフォンのアドレス帳をパートナーのアドレス帳と統合できて、本来は短縮ダイヤルやお気に入り、緊急連絡先に登録しておくべき義母の電話番号をパートナーにまた尋ねるという失態を演じずに済むとしたら、どうでしょうか。さらに、ニューヨークやサンフランシスコなどの都会で、空いている道路や個人駐車場を使うことができ、さらに、所有者が戻ってくるまで、 そのスペースを借りることを交渉できるとしたらどうでしょうか。

こういった状況における共通のテーマは、近くで通信できる人や場所、ものを検知することです。

今年の I/O では、新しい Nearby Connections API についてお話ししました。これは、近くにある完全オフラインの端末間で、P2P 方式によって高帯域幅、低遅延の暗号化データ転送を行うものです。本日(*原文公開当時)は、Google Play サービス 11.0以上を実行しているすべての Android 端末でこの API が利用できるようになったことをお知らせします。

Nearby Connections は、内部的に WiFi、Bluetooth LE、従来型 Bluetooth を利用して近くの端末を検知し、接続を確立します。こういった無線通信は本質的に複雑ですが、それぞれのメリットを利用しつつデメリットを回避することで抽象化を行い、その複雑さを排除しています。この抽象化によって、異なる OS のバージョンや端末間の無線通信に対応する煩雑さを回避できるという明らかなメリットが得られます。さらに、適宜無線通信を切り替えて接続の帯域幅をシームレスに増加させることも、新しい無線通信テクノロジーが利用できるようになった場合、それを利用するように透過的な OTA アップデートを行うことも可能です。いずれの場合も、アプリのコードは一切変更する必要はありません。

この API の中核にあるのは、バイト列、ファイル、データ ストリームを転送できる(Unix のソケットに似た)接続です。この API では、2 つの接続トポロジーがサポートされています。
  • スター型: センターとなる端末が存在し、他の端末がそこにアクセスする 1 対 N 型のトポロジーの構築に便利です。たとえば、オフライン ゲームのホストや、教育用の試験アプリで教師が使う端末などです。
  • クラスタ型: 疎に結合したメッシュ型ネットワークを実現する M 対 N のトポロジーに便利です。たとえば、リアルタイムでコラボレーションを行うプロジェクト グループを臨機応変に作成できる教育用アプリや、オフラインで近くにいる人同士がチャットできるアプリなどです。
この API を作成する過程で、固有のオフライン データ転送のニーズと環境を持つ何社かのパートナーと共同作業を行いました。パートナーがこの API の初期版を使って構築したものを見るのはすばらしいことでした。また、本日のリリースに向けて、各パートナーのフィードバックは非常に価値あるものになりました。以下で、パートナーが構築したおもしろいアプリをいくつか紹介しましょう。
  • The Weather Channelは、データが不足している地域でオンデマンドのメッシュ ネットワークを構築し、緊急の注意報を配信しています。
  • Hotstarは、インターネット接続が不安定または利用できない場所(公共交通機関、飛行機など)でのオフライン メディア共有を実現しています。
  • GameInsightは、Nearby Connections を使って近くにいるプレーヤーを探したり、完全オフラインの状態でゲームを実行したりしています。
  • Android TV では、初期設定を簡素化し、さらに 2 番目の画面を活用するためのリモコンアプリ(Nearby Connections を利用)が作成されています。
現在、この API は一般公開されています。 皆さん皆さんのアプリで Nearby Connections をどう使うのか、早く見たくてしょうがありません。まずは、デベロッパー サイトにアクセスし、サンプルコードを確認してみましょう。質問があれば、遠慮なく Stackoverflow に投稿してください(google-nearbyタグを付けてください)。メーリング リストに登録すると、最新の Android Nearby(およびその他の関連 API)についての情報を得ることができます。


Reviewed by Takuo Suzuki - Developer Relations Team

Motion Stills に Android 版が登場

$
0
0
この記事は Google Research ソフトウェア エンジニア、Karthik Raveendran、Suril Shah による Google Research Blog の記事 "Motion Stills — Now on Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年、iOS アプリMotion Stillsがリリースされました。これは、ライブフォトの手ぶれ補正を行い、ループ GIF や動画として参照、共有できるアプリです。それ以来、Motion Stills は好評を博しており、The VergeMashableによって 2016 年のトップアプリの 1 つに選ばれています。しかし最初のリリース以来、コミュニティからは Motion Stills を Android でも使えるようにしてほしいという要望が絶えませんでした。そこで、皆さんからのフィードバックにお応えして、本日(*原文公開当時)、この技術が Android 5.1 以降の端末で利用できるようになったことをお知らせします。さらに、Android 版にしかない機能も追加されています。
Android 版 Motion Stills: お使いの端末で即座に手ぶれ補正
Android 版の Motion Stillsでは、新たな撮影方式が導入されています。このアプリで撮影すると、素材はすべて即座に変換され、簡単に見たり共有したりできる楽しいショート クリップになります。シングルタップで写真のように短い Motion Still を撮影できるほか、ファスト フォワード(早送り)と呼ばれる新機能を使って少し長めの素材を圧縮することもできます。Android 版の Motion Stills では、撮影した素材の手ぶれ補正ができるだけでなく、トリミング アルゴリズムが改善されているため、ポケットに端末をしまう場面が映り込むことや予期しないカメラの揺れを防ぐこともできます。これらの機能は、すべて撮影時に Android 端末で実行されます。インターネット接続は必要ありません。

新しいストリーミング パイプライン
今回のリリースにあたって、既存の iOS の動画処理パイプラインが再設計され、動画の各フレームを記録しながらストリーミング処理を行うアプローチが採用されています。中間モーション メタデータを計算することにより、撮影された素材に対して即座に補正を行いつつ、シーケンス全体のループの最適化も行います。これらはすべて撮影直後に利用できるので、一切待つことなく新しい GIF を共有できます。
ストリーミング パイプラインにより、撮影結果を即座に生成
Motion Stills ストリームを即座に表示するために、アプリのアルゴリズムでは必要な手ぶれ補正変換を低解像度のテクスチャ マップとして算出し、保存しています。そして、そのテクスチャと GPU を利用し、再生中に手ぶれ補正変換をリアルタイムに適用します。補正済みの新しい動画を書き込むわけではないので、モバイル ハードウェアや電池を酷使することはありません。

ファスト フォワード
ファスト フォワードを使うと、再生速度を上げて長い素材を圧縮し、共有しやすい短めのクリップにすることができます。ファスト フォワードは、上記のパイプラインを利用し、最大で動画の実時間をかけてスマートフォン上で動画を処理します。撮影したあとに再生速度(1 倍から 8 倍)を変えることもできます。これを実現するために、密度を上げた I-フレーム 挿入で動画をエンコードし、効率的なシークや再生ができるようにしています。ファスト フォワード モードでは、他にも最適化を導入しました。たとえば、線形ソルバーで適応型時間ダウンサンプリングを適用し、長時間での手ぶれ補正を行なってシーケンス全体をスムーズにします。
撮影した素材を圧縮し、簡単に共有できるクリップに変換するファスト フォワード
Motion Stills をお試しください
Motion Stills は、短い動画に関連する技術実験を繰り返し行ない、貴重なフィードバックを集めるためのアプリです。ユーザーにとって特に便利で有用な機能は、今後 Google フォトなどの既存製品に組み込まれる可能性もあります。Android 版 Motion Stills は、Google Play ストアからダウンロードできます。対応しているのは、Android 5.1 以降を実行しているスマートフォンです。お気に入りのクリップは、ハッシュタグ #motionstills をつけてソーシャル メディアで共有してください。

謝辞
Motion Stills は、多くの Google 社員の助けがなければ実現できませんでした。特に、手ぶれ補正技術を進化させてくれた Matthias Grundmann、UX およびインタラクション デザイナーの Jacob Zukerman、Ashley Ma、Mark Bowers に感謝いたします。


Reviewed by Hak Matsuda - Developer Relations Team

サニタイザーによる Android のバグ退治

$
0
0
この記事は Android セキュリティ チーム、Dan Austin による Android Developers Blog の記事 "Android Bug Swatting with Sanitizers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android のビルドに利用されているコンパイラ インフラストラクチャである LLVM には、静的および動的な解析を行う複数のコンポーネントが含まれています。Android の解析時に広く使われているコンポーネント群の 1 つにサニタイザーがありますが、中でも代表的なのが、AddressSanitizer、UndefinedBehaviorSanitizer、SanitizerCoverage です。これらのサニタイザーは、開発やテストの際のバグ対応や Android の改善に活用できる compiler-rt に含まれるコンパイラ ベースの診断コンポーネントです。現在 Android で利用できるサニタイザーを使うと、多くの不適切なメモリの利用に関連するバグや、定義されていない動作を検出および診断できます。また、コード カバレッジの指標を提供し、テストスイートができる限り網羅されていることを保証することもできます。

本ブログ投稿では、現在の Android サニタイザー(AddressSanitizer、UndefinedBehaviorSanitizer、SanitizerCoverage)の詳しい内部動作と、これらを Android のビルドシステムでどのように活用できるかについて説明します。

AddressSanitizer


AddressSanitizer(ASan)は、コンパイラ ベースの診断機能で、C/C++ コードのさまざまな種類のメモリエラーをランタイムで検知することができます。Android では、次のような種類のメモリエラーに対するチェックが行われます。
  • 範囲外のヒープ、スタック、グローバルへのアクセス
  • 解放後の利用
  • return 後の利用(ランタイム フラグ ASAN_OPTIONS=detect_stack_use_after_return=1)
  • スコープ外での利用(clang フラグ -fsanitize-address-use-after-scope)
  • 二重解放、無効な解放

Android では、ASan を使ってビルドを完全に診断できますが、asanwrapper を使ってアプリレベルで ASan による診断を行うこともできます。source.android.comで、両方の診断手法について説明しています。

AddressSanitizer は、大まかに分けると 2 つのコンセプトに基づいて構築されています。最初のコンセプトは、メモリの割り当て、解放、利用統計を追跡する情報を活用して、alloca、malloc、free など、あらゆるメモリ関連の関数呼び出しを診断するというものです。これによって、二重解放、スコープ外や return 後、解放後の利用など、無効なメモリの利用に関するバグを検知できます。さらに ASan は、定義されたメモリ領域の範囲外に対する読み取りや書き込みも検知できます。これは、割り当てられたメモリバッファや変数の間を埋める(パディングする)ことによって実現しています。このパディング領域に対して読み取りや書き込みが行われると、ASan はそれを検知してメモリ違反の診断に役立つ情報を出力します。ASan の用語では、このパディング領域は poisoned(毒入り)メモリと呼ばれます。次に示すのは、スタックに割り当てられた変数とそのパディングによる poisoned メモリの例です。
図 1. ASan 化されたスタック変数(8 個の要素を持つ int8_t 配列、uint32_t、16 個の要素を持つ int8_t 配列)の例。右側に示されているのが ASan でコンパイルした後のメモリ レイアウト。各変数の間にパディングが挿入されている。各スタック変数の前後に 32 バイトのパディングが挿入されるが、変数のオブジェクトのサイズが 32 バイトでない場合は、追加で 32 - n バイトのパディングが挿入される(n はオブジェクトのサイズ)。

ASan は、どのバイトが通常のメモリでどのバイトが poisoned メモリであるか、シャドウメモリを使って追跡しています。各バイトの状態は、すべて通常のメモリ(シャドウメモリが 0)、すべて poisoned なメモリ(対応するシャドウバイトの高位ビットがオン)、最初の k バイトが poisoned でないメモリ(シャドウバイトの値が k)のいずれかになります。バイトが poisoned であることをシャドウメモリが示している場合、ASan はプログラムをクラッシュさせ、デバッグに役立つ情報を出力します。これには、コールスタック、シャドウメモリのマップ、メモリ違反の種類、読み込みや書き込みの内容、違反を起こした PC、メモリの内容などが含まれます。
AddressSanitizer: heap-buffer-overflow on address 0xe6146cf3 at pc 0xe86eeb3c bp 0xffe67348 sp 0xffe66f14
WRITE of size 39 at 0xe6146cf3 thread T0
#0 0xe86eeb3b (/system/lib/libclang_rt.asan-arm-android.so+0x64b3b)
#1 0xaddc5d27 (/data/simple_test_fuzzer+0x4d27)
#2 0xaddd08b9 (/data/simple_test_fuzzer+0xf8b9)
#3 0xaddd0a97 (/data/simple_test_fuzzer+0xfa97)
#4 0xaddd0fbb (/data/simple_test_fuzzer+0xffbb)
#5 0xaddd109f (/data/simple_test_fuzzer+0x1009f)
#6 0xaddcbfb9 (/data/simple_test_fuzzer+0xafb9)
#7 0xaddc9ceb (/data/simple_test_fuzzer+0x8ceb)
#8 0xe8655635 (/system/lib/libc.so+0x7a635)
0xe6146cf3 is located 0 bytes to the right of 35-byte region [0xe6146cd0,0xe6146cf3)
allocated by thread T0 here:
#0 0xe87159df (/system/lib/libclang_rt.asan-arm-android.so+0x8b9df)
#1 0xaddc5ca7 (/data/simple_test_fuzzer+0x4ca7)
#2 0xaddd08b9 (/data/simple_test_fuzzer+0xf8b9)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/system/lib/libclang_rt.asan-arm-android.so+0x64b3b)
Shadow bytes around the buggy address:
0x1cc28d40: fa fa 00 00 00 00 07 fa fa fa fd fd fd fd fd fd
0x1cc28d50: fa fa 00 00 00 00 07 fa fa fa fd fd fd fd fd fd
0x1cc28d60: fa fa 00 00 00 00 00 02 fa fa fd fd fd fd fd fd
0x1cc28d70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1cc28d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x1cc28d90: fa fa fa fa fa fa fa fa fa fa 00 00 00 00[03]fa
0x1cc28da0: fa fa 00 00 00 00 07 fa fa fa 00 00 00 00 03 fa
0x1cc28db0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa
0x1cc28dc0: fa fa 00 00 00 00 00 02 fa fa fd fd fd fd fd fd
0x1cc28dd0: fa fa 00 00 00 00 00 02 fa fa fd fd fd fd fd fd
0x1cc28de0: fa fa 00 00 00 00 00 02 fa fa fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb

レポートの各部についての詳しい情報や、さらにユーザーにわかりやすくする方法は、LLVM ウェブサイトGithubに掲載されています。

バグの発見プロセスは非決定的である場合もあります。中でも、特殊な設定下や、ヒープのプライミング、競合状態の利用などの高度な手法を用いた場合にしか生じないバグなどがあげられます。こういったバグの多くはわかりやすいものではなく、実際の根本原因であるメモリ違反とはかけ離れた無数の指示となって表れることがあります。ASan はメモリ関連の関数をすべて診断し、ASan 関連のコールバックを起動させずにアクセスすることができない領域でデータをパディングするので、クラッシュを誘発する破損を待たずとも、発生と同時にメモリ違反を検出できます。これは、バグの発見や根本原因の診断に特に便利です。さらに、ASan はファジングを行う際にとても便利で、Android 向けの多くのファジングツールで活用されています。

UBSan


UndefinedBehaviorSanitizer(UBSan)は、さまざまな種類の定義されていない動作をコンパイル時にチェックします。端末メーカーは、makefile で LOCAL_SANITIZE:=default-ub を指定するか、blueprint ファイルの sanitize ブロックで default-ub: true を指定することによって、UBSan をテストビルドに含めることができます。UBSan は多くの定義されていない動作を検知できますが、Android のビルドシステムで直接サポートされているのは以下のものです。
  • bool
  • integer-divide-by-zero
  • return
  • returns-nonnull-attribute
  • shift-exponent
  • unreachable
  • vla-bound

UBSan の整数オーバーフロー チェックは、Android のビルドシステムでも利用されています。さらに、UBSan は unsigned-integer-overflow もサポートしています。これは厳密には定義されていない動作ではありませんが、このサニタイザーに含まれています。これらを有効にするには、makefile で LOCAL_SANITIZE に signed-integer-overflow、unsigned-integer-overflow、または組み合わせフラグである integer(これを指定すると、signed-integer-overflow、unsigned-integer-overflow、integer-divide-by-zero、shift-base、shift-exponent が有効になります)のいずれかを設定します。blueprint ファイルでは、Misc_undefined に希望のフラグを設定すると有効化できます。これらの UBSan ターゲット、とりわけ unsigned-integer-overflow は、mediaserver コンポーネントの潜在的な整数のオーバフロー脆弱性に対処するために広く使われています。

Android のデフォルト実装では、定義されていない動作が発生するとプログラムを中断します。なお、2016 年 10 月以降、Android の UBSan には、発生した定義されていない動作の種類、ファイル、ソースコードの行数などの情報を含むさらに詳しいエラーを報告してくれるオプションのランタイム ライブラリが付属しています。

このオプションは、Android.mk ファイルでは、次のように指定して有効化します。
LOCAL_SANITIZE:=unsigned-integer-overflow signed-integer-overflow
LOCAL_SANITIZE_DIAG:=unsigned-integer-overflow signed-integer-overflow

また、Android.bp ファイルでは、次のように指定して有効化します。
sanitize: {
misc_undefined: [
"unsigned-integer-overflow",
"signed-integer-overflow",
],
diag: {
misc_undefined: [
"unsigned-integer-overflow",
"signed-integer-overflow",
],
},
},

UBSan ランタイム ライブラリが提供する情報の例を次に示します。
external/icu/icu4c/source/common/ucnv.c:1193:23: runtime error: unsigned integer overflow: 4291925010 + 2147483647 cannot be represented in type 'unsigned int'
external/icu/icu4c/source/common/cstring.c:288:16: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'uint32_t' (aka 'unsigned int')
external/harfbuzz_ng/src/hb-private.hh:894:16: runtime error: unsigned integer overflow: 72 - 55296 cannot be represented in type 'unsigned int'
external/harfbuzz_ng/src/hb-set-private.hh:82:24: runtime error: unsigned integer overflow: 32 - 562949953421312 cannot be represented in type 'unsigned long'
system/keymaster/authorization_set.cpp:500:37: runtime error: unsigned integer overflow: 6843601868186924302 * 24 cannot be represented in type 'unsigned long'

SanitizerCoverage


サニタイザー ツールには、とても単純なコード カバレッジ ツールが組み込まれています。SanitizerCoverage を使うと、呼び出しレベル、基本ブロックレベル、エッジレベルでコード カバレッジを確認できます。これらは、スタンドアロンの診断手法として、あるいは AddressSanitizer や UndefinedBehaviorSanitizer などの他のサニタイザーと組み合わせて利用できます。新機能である guard ベースのカバレッジを利用するには、fsanitize-coverage=trace-pc-guard を設定します。この設定を行うと、コンパイラはすべてのエッジに __sanitizer_cov_trace_pc_guard(&guard_variable) を挿入します。各エッジには、それぞれ uint32_t guard_variable が割り当てられます。さらに、モジュールのコンストラクタ __sanitizer_cov_trace_pc_guard_init(uint32_t* start, uint32_t* stop) も生成されます。__sanitizer_cov_ で始まる関数は、すべてユーザーが提供する必要があります。詳しくは、guard で PC をトレースするに記載された例をご覧ください。

SanitizerCoverage を使うと、制御フローのトレースだけでなく、データフローのトレースも行うことができます。この機能は、fsanitize-coverage=trace-cmp を指定すると有効化でき、すべての switch 文や比較命令を __sanitizer_cov_trace_* 関数で診断して利用します。整数の除算や GEP 命令でも同様の機能を利用でき、それぞれ fsanitize-coverage=trace-div および fsanitize-coverage=trace-gep で有効化します。これは試験運用版のインターフェースで、スレッドセーフではありません。今後変更される可能性はありますが、複数の Android ビルドで利用可能になっています。

カバレッジ サニタイザーのセッションでは、.sancov ファイルと sancov.map ファイルという 2 つのファイルにカバレッジ情報が記録されます。最初のファイルにはプログラム内のすべての診断ポイントが、もう一方のファイルには最初のファイルへのインデックスのシーケンスという形で実行トレースが含まれています。デフォルトで、これらのファイルはカレント ワーキング ディレクトリに格納され、実行された実行可能および共有オブジェクトにつき 1 つのファイルが作成されます。

まとめ


ASan、UBSan、SanitizerCoverage は、LLVM サニタイザーを Android で利用できるようにする取り組みのほんの始まりにすぎません。Android ビルドシステムには、さらに多くの LLVM サニタイザーを組み込む作業が行われています。今回説明したサニタイザーは、コードの健全性やシステムの安定性を維持する仕組みとして利用できます。また、セキュリティ関連のバグの検出や防止のため、Android セキュリティでも利用されています。

Reviewed by Yuichi Araki - Developer Relations Team

Google Cloud INSIDE Games & Apps 開催のお知らせ

$
0
0



この度 Google Cloud では、ゲーム & アプリ業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーの皆さまを対象に、9 月 28 日  ( 木 )  18 : 30 より「 第 1 回 Google Cloud INSIDE Games & Apps 」を開催します。

第 1 部 セッションパートでは、『ゲーム & アプリ開発の裏側』をテーマに、外部ゲストや Google 社員をスピーカーに迎え、近年注目を集める SRE (Site Reliability Engineering) の概念や実践的なお話、Google Cloud Platform を中心としたテクノロジーアップデートをお届けします。第 2 部は、Google 社員や同じ業界で働く参加者と交流を深めていただく懇親会を予定しています。ぜひ、ご参加ください。

《 開催概要 》
  • 名 称:Google Cloud INSIDE Games & Apps
  • 会 期: 2017 年 9 月 28 日  ( 木 )  18 : 30 - 22 : 00
  • 会 場:グーグル本社
   〒106‐­6108 東京都港区六本木6-11-10 六本木ヒルズ森タワー
  • スピーカー
    • 株式会社 メルカリSRE 中島 大一 氏
    • グーグルクラウド SRE アドボケイト ポール ニューソン
    • 調整中
※英語スピーカーに関しては、同時通訳 (英→日)をご提供いたします。
  • プログラム: 無料 (事前登録制)
    • 18 : 30 受付開始
    • 19 : 05 - 19 : 40 セッション1
    • 19 : 40 - 20 : 15 セッション2
    • 20 : 15 - 20 : 50 セッション3
    • 休憩
    • 21 : 15 - 22 : 00 懇親会
  • 主 催: グーグル・クラウド・ジャパン合同会社
  • 定員:200 名

《 お申し込み 》
こちらのリンクからお申し込みください。
※ お申込み締め切り: 2017 年 9 月 19 日 ( 火 ) 15 : 00まで
競合他社様からのお申し込みはお断りさせていただくことがございます
※ ビジネス向けのイベントとなっております。学生の方のご参加はご遠慮ください。
※ お申し込み多数の場合は抽選を行います。参加いただける方には、後日、ご登録されたメールアドレスに参加のご案内をお送りします。



Posted by Takuo Suzuki - Developer Relations Team

Android Things Developer Preview 5

$
0
0
この記事は IoT デベロッパー アドボケート、Wayne Piekarski による Android Developers Blog の記事 "Android Things Developer Preview 5" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日(*原文公開当時)、Android Thingsの Developer Preview 5(DP5)をリリースいたします。これには、まもなく公開される Android O リリースをベースとした大きな変更が含まれています。Android Things は、Android デベロッパーがモノのインターネット(IoT)端末を構築し、シームレスにプロトタイプから製品に展開できるようにするための Google 製プラットフォームです。

Android O


現在、Android O はスマートフォンおよびタブレット向けの Developer Previewが公開されており、DP5 はまもなく公開されるこのリリースがベースとなっています(以前のリリースは、Android N をベースとしたものでした)。これにより、今後 Android Things プラットフォームでサポート ライブラリを利用するアプリケーションを正常に動作させるには、ターゲットを API 26 にする必要があります。

ハードウェアの変更点


デベロッパー キットのドキュメントにあるように、DP5 では新たに NXP SprIoT i.MX6ULデザインがサポートされています。Intel が EdisonJouleといったハードウェアを生産終了することに伴い、これらのプラットフォームはレガシー サポートに移行されています。これらのハードウェアでは最新のプラットフォーム アップデートは提供されなくなりますが、デベロッパーは引き続き Android Things Console から DP4.1 システム イメージにアクセスすることができます。

Android Things の重要な目的は、デベロッパーがシームレスにプロトタイプから本番環境に展開できるようにすることです。Developer Preview の終了後は、プロトタイプのみをターゲットにしたハードウェア プラットフォームと、本番環境に展開できるハードウェア リファレンス デザインが区別される予定です。本番対応のハードウェアは Google のセキュリティ要件を満たし、半導体メーカーによる長期サポートが含まれます。詳しくは、後日改めてお知らせします。

改善点


Android O コードベースへの移行に伴い、Android の新しい API 機能や、Android Things 特有の機能が追加されています。UserDriver API を利用しているデベロッパーの皆さんは、AndroidManifest.xml に新しいパーミッションを追加する必要があります。ドキュメントには、必要になるパーミッションがドライバの種類ごとに詳しく記載されています。DP5 では、Raspberry Pi 3 で OpenGL ES 2.0 や WebView がサポートされるようになりました。これらは、デベロッパーから多くのリクエストが寄せられた機能です。さらに、Raspberry Pi 3 では、使う機能に応じてピンがランタイムで設定される動的ピン多重化も実装されています。

Android Studio


Android Studio で直接 Android Things のサンプルの参照やインポートができるようになりました。[File] > [New] > [Import Samples] を選択して「Things」で検索すると、利用可能なサンプルが表示されます。ボタン、センサー、LED、ディスプレイと連携する方法を説明したものや、Google アシスタントや TensorFlow を実装したものなど、多数のサンプルを取りそろえています。

Android Things Console


先日、Android Things Consoleリリースされました。これは、Android Things 端末への OTA アップデートをサポートする機能を提供するものです。また、コンソールの UX も大幅に改善され、ユーザビリティや機能が向上しています。現在、DP5 は Android Things Console から利用できますが、何も操作を行わない場合、DP5 アップデートが自動的に端末に配信されることはありません。アプリケーションは、DP5 に対応するようにアップデートし、新しいアップデートを作成してコンソール経由で配信する必要があります。

フィードバック


Android Things が Android O にアップデートされたため、プラットフォームには大きな変更が発生しています。バグレポート機能リクエストを送信し、フィードバックをお願いします。質問は、どんなものでもかまいませんので、Stack Overflowにお寄せください。DP5 を使ってみるには、Android Things Consoleからシステム イメージをダウンロードして既存の端末をアップデートします。詳しい変更点は、リリースノートに記載されています。Google+ の Google IoT デベロッパー コミュニティにも参加できます。これは、最新情報を入手したりアイデアを話し合うことができるすばらしいリソースです。自分が構築したすばらしいプロジェクトを共有できる hackster.io コミュニティも、新たに誕生しました!



Reviewed by Takeshi Hagikura - Developer Relations Team

次世代 dex コンパイラのプレビューを公開

$
0
0
この記事はプロダクト マネージャ、James Lau による Android Developers Blog の記事 "Next-generation Dex Compiler Now in Preview" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android デベロッパーの方なら、dex コンパイルが APK をビルドする際の重要なステップであることをご存知でしょう。dex コンパイルは、.class バイトコードを Android ランタイム(古いバージョンの Android では、Dalvik と呼ばれていました)用の .dex バイトコードに変換する処理です。通常、dex コンパイラは、日々のアプリ開発であまり意識することはありませんが、アプリのビルド時間や .dex ファイルのサイズ、ランタイムのパフォーマンスに直接的な影響を与えます。

そのため、dex コンパイラには、重要な改善を行うための投資が続けられています。先日、Android Studio 3.0 ベータ版リリースの一部として、次世代 dex コンパイラである D8 をプレビュー リリースしたことをお知らせします。

現在の DX コンパイラと比較すると、D8 は高速化されているだけでなく .dex ファイルのサイズも小さくなっています。しかも、アプリのランタイム パフォーマンスは同等または向上しています。
* こちらのベンチマーク プロジェクトでテストしています。
* こちらのベンチマーク プロジェクトでテストしています。


試してみるには



プレビュー版の D8 は、Android Studio 3.0 ベータ版以降で利用できます。試してみるには、プロジェクトの gradle.properties ファイル内に以下の内容を設定します。
android.enableD8=true

D8 の正確さやパフォーマンスはさまざまなアプリでテストされており、たいへん有望な結果が出ています。この信頼できる結果を踏まえて、AOSPをビルドする際のデフォルト dex コンパイラを D8 に切り替えています。今のところ既知の問題はありませんが、皆さんのフィードバックをお待ちしています。バグレポートは、こちらのリンクからお送りください。


次のステップ



D8 は、今後数か月間にわたって Android Studio 3.0 リリースでプレビューが行われる予定です。この期間中は、コミュニティから寄せられた重大なバグレポートの対応に集中します。D8 は、Android Studio 3.1 でプレビューを終えてデフォルトの dex コンパイラとなる予定です。そのタイミングで、DX コンパイラは正式にメンテナンス モードに移行し、修正されるのは重大な問題のみとなります。

D8 に加え、Proguard に代わってプログラム全体の圧縮や最適化を行う R8 の作業も進んでいます。R8 プロジェクトはすでにオープンソース化されていますが、Android Gradle プラグインへの組み込みはまだ行われていません。R8 の詳細は、近日中にコミュニティ向けプレビューの準備ができた段階でお知らせします。


ツール デベロッパーの皆さんは、バイトコード ツールの Java 8 対応を



4 月には、desugar を利用した Java 8 言語機能についてお知らせしました。現在、desugar ステップは Java コンパイル(javac)の直後、バイトコードの読み取りまたは書き換えツールの起動前に実行されています。今後数か月のうちに、この desugar ステップは D8 に組み込まれ、パイプラインの後方のステージに移動する予定です。これによってビルド時間全体がさらに短縮され、最適化されたコードが生成されるようになります。この変更により、バイトコードの読み取りまたは書き換えツールは、desugar ステップの前に実行されることになります。そのため、Android 用の .class バイトコードの読み取りまたは書き換えツールを開発している方は、ツールが Java 8 バイトコード形式を扱うことができ、desugar が D8 に組み込まれても問題なく動作を続けられることを確認する必要があります。

Happy dex'ing!



Reviewed by Yuichi Araki - Developer Relations Team

Firebase Performance Monitoring for Android おすすめ活用術その 1: すべてのアクティビティの自動トレース

$
0
0
この記事はデベロッパー アドボケート、Doug Stevenson による The Firebase Blog の記事 "Firebase Performance Monitoring for Android Tip #1: Automatic Traces for All Activities" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。




まだ Firebase Performance Monitoringを試していないという皆さん。多くの Firebase デベロッパーは、この機能を使うと、大量のコードを書かなくても iOS や Android アプリのパフォーマンスの特徴を可視化しています。ただし、自動的に収集されるデータもありますが、さらに詳しい情報を得るには、カスタムのトレースやカウンタを実装する必要があります。トレースは、アプリ内のある過程のパフォーマンス データを集めたレポートです。また、カウンタを使うと、トレースの中にパフォーマンスに関連するイベントを計測できます。今回のパフォーマンスに関するおすすめの活用術では、大量のコードを書かなくても Android アプリに たくさんのトレースを追加する方法を紹介しましょう。

通常の Android アプリは、タスクやデータをユーザーに提示するアクティビティの集まりで構成されています。潜在的なパフォーマンスの問題を追跡する際は、後ほど結果を Firebase Console で確認できるように、アプリ内のすべてのアクティビティをトレースしておくと便利です。しかし、アプリにたくさんのアクティビティがある場合、そのすべてに追跡用のコードを書くのは面倒でしょう。そこで、少しばかりのコードを書いて すべてのアクティビティをトレースできるようにします。

Android では、アプリのすべてのアクティビティのライフサイクルを監視するリスナーが提供されています。このリスナーは、インターフェース ActivityLifecycleCallbacksを実装したもので、Application.registerLifecycleCallbacks()メソッドを使って登録できます。パフォーマンスを計測するには、ライフサイクル メソッド onStart()onStop()に対応する部分でトレースを行うとよいでしょう。アクティビティの「Start」とは、そのアクティビティが画面に表示されることです。また、アクティビティの「Stop」とは、そのアクティビティが見えなくなることです。そのため、この 2 つの場所で実際に動作するアクティビティのトレースを定義するのが適切です。次に示すのは、各アクティビティのトレースを行う ActivityLifecycleCallbacks の最初の実装です。まず、どこからでも簡単にアクセスできるように、クラスをシングルトンにします(何らかの依存性注入を使うこともできるでしょう)。

public class PerfLifecycleCallbacks
implements Application.ActivityLifecycleCallbacks {

private static final PerfLifecycleCallbacks instance =
new PerfLifecycleCallbacks();

private PerfLifecycleCallbacks() {}
public static PerfLifecycleCallbacks getInstance() {
return instance;
}
}

次に、アクティビティでカスタムの項目をトレースできるように、クラスにいくつかのメンバーを追加します。
    private final HashMap<Activity, Trace> traces = new HashMap<>();

@Override
public void onActivityStarted(Activity activity) {
String name = activity.getClass().getSimpleName();
Trace trace = FirebasePerformance.startTrace(name);
traces.put(activity, trace);
}

@Override
public void onActivityStopped(Activity activity) {
Trace trace = traces.remove(activity);
trace.stop();
}


// ...empty implementations of other lifecycle methods...

これで、アクティビティが開始した際にトレースが開始され、停止した際にはトレースも停止するようになります。ここでは、トレースの名前としてアクティビティ オブジェクト クラスの省略名(完全な Java パッケージ名がつかないクラス名)を使っています(注: アクティビティが複数の Java パッケージに分散している場合は、アクティビティのクラス名が一意になるようにしてください)。

さらに、指定したアクティビティ オブジェクトのトレースを返すメソッドも追加しておきましょう。これによって、任意のアクティビティで現在のトレースを取得してカウンタを追加できるようになります。
    @Nullable
public Trace getTrace(Activity activity) {
return traces.get(activity);
}

このクラスは、いずれかのアクティビティが開始する前に登録する必要があります。登録は、ContentProvider で行うとよいでしょう。ContentProvider の動作がよくわからないという方は、Firebase が ContentProvider を使って初期化を行う仕組みをご覧ください。
public class PerfInitContentProvider extends ContentProvider {
@Override
public boolean onCreate() {
context = getContext();
if (context != null) {
Application app = (Application) context.getApplicationContext();
app.registerActivityLifecycleCallbacks(
PerfLifecycleCallbacks.getInstance());
}
}
}

忘れずに ContentProvider をアプリのマニフェストに追加するようにしてください。そうすることによって、アプリのアクティビティより先に ContentProvider が作成されるようになります。

ContentProvider が作成されると、アプリが自動的にすべてのアクティビティのトレースを作成するようになります。トレースにカウンタを追加したい場合は、PerfLifecycleCallbacks シングルトンの getTrace()メソッドに現在のアクティビティ オブジェクトを渡します。次に例を示します。
private Trace trace;

@Override
protected void onCreate(Bundle savedInstanceState) {
trace = PerfLifecycleCallbacks.getInstance().getTrace(this);
// use the trace to tally counters...
}

どのカウンタを記録すべきか、慎重に検討してください。アプリのユーザー エクスペリエンスを改善するうえで判断材料となる情報を集めるようにします。たとえば、キャッシュのメモリ量を調整するために、キャッシュのヒットとミスの比率を記録することができます。他の Firebase Performance Monitoring のおすすめ活用術を知りたい方は、ぜひ Firebase の Twitterをフォローしてください。


Reviewed by Khanh LeViet - Developer Relations Team

Inevitable ja Night イベントレポート「不可避な未来」x「NEXT 5 BILLION」対談 01

$
0
0
6 月 12 日に開催した「Inevitable ja Night - インターネットの次にくるもの」ではさまざまなゲストを交え、Google Cloud といったテクノロジーの進化によってこの先の世界はどう変わっていくのか、VRやARなどの領域で活躍している人材をゲストに議論しました。本稿では、当日にどのような議論が行われたのかを振り返っていきます。

まず、最初のセッション、「不可避な未来」x「NEXT 5 BILLION」では、ジャーナリストの服部桂氏とAGRIBUDDY LIMITED 北浦健伍氏が登場。モデレーターは小島英揮氏。これからの 5 年後、10 年後に起こるであろう「不可避な流れ」について語り合いました。

【スピーカー】
ジャーナリスト 服部桂 氏
AGRIBUDDY LIMITED. CEO 北浦健伍 氏

【モデレーター】
パラレルマーケター・エバンジェリスト 小島英揮 氏


これからやってくる不可避な流れ


小島英揮氏(以下、小島):みなさん、こんばんは。今日は「INEVITABLE ja night」のイベントにお越しいただき、ようこそ。

今日はこの 3 人で、この「不可避な未来とNEXT 5 BILLION」というテーマでお話をしていきたいと思います。後ほど 2 人にも自己紹介していただきます。まず、ちょっと座っていただいて、進めていきたいと思います。

今日は「INEVITABLE」というこのキーワードをずっと使ってるんですけれども。日本語でいうと「不可避な流れ」という文脈で使っています。

どんな流れが不可避なのかを共有します。そして最後にスタートアップを起業されたみなさんのパネルがあるんですけれども、どうやったら彼らのようなことがみなさんもできるのか、そういった道筋をぜひこの対談を通じて得ていただければと思います。




それでは、私のほうから今回の「INEVITABLE ja night」を開催するに至った流れをお話しして、お  2  人と、この不可避な流れについて議論を深めていこうかなと思っております。
簡単に私の自己紹介なんですけれども、小島と申します。25 年ぐらいこの IT 業界でマーケティングをやってまして。直近はクラウドのビジネスに7年ほど携わっていました。



今年から、1 社というよりはこの不可避な流れにたくさんなるべく張っておきたいということで、VR とか決済とか、そういったところのいくつか会社のマーケティングのお手伝いをしている者でございます。

『攻殻機動隊』の世界観がリアルになってきている

今日の Inevitable な流れというところで、イントロダクションというところなんですけれども。世代が合う方がどれぐらいいるかわかりませんが、僕的には今日お話しする VR とかAI とか IoT って、最近実写版もありましたけれども『GHOST IN THE SHELL』『攻殻機動隊』の世界観がすごくリアルになってきてる流れなんじゃないかなと思います。

あの中では、VR のゴーグルや AI、マイクロマシン、センサーみたいなものがごくごく普通に生活の中に入ってきている。いろんなネットワークは非常に進化してるんだけれども、まだ国や民族という器は残っている。非常に今と似たような状況なんじゃないかなと思っています。

「これはアニメの話じゃないか?」と思うかもしれませんが、非常に今ここに近い流れが来てるんじゃないかなと思ってまして。

それでちょっとご説明したいのは、こちらの図です。

(スライドを指して)一番左にあるのはクラウドコンピューティング。ここから端を発して、たぶん今ビッグデータ、モバイルという流れが来てると思います。今日、この先に、AIや VR/AR といった仮想体験、そして人だけじゃなくて物もデータを出してくる IoT の世界が来るという話なんですが。これを技術の流れじゃなくて、エコシステムの流れで捉えていただきたいと思ってるんですよね。



「エコシステムってなにか?」という話なんですけれども。たぶんみなさんはお手元にスマホをお持ちだと思います。このスマホには 2 つの要素があると思っています。

1 つはスペックというんですかね、ハードウェアの性能みたいなところ。これも「テクノロジー」と表現できると思うんですけれども。

いかにスペックが高くても、おそらくみなさん、その中にあるたくさんのエコシステム、……みなさんの中ではいろんなアイコンが見えると思うんですけれども。これがなかったら、このテクノロジーは使わなかったと思います。10 万円もする電話機を、みなさんは買わないと思うんですよね。

なんでみなさんこれを買ってるかというと、このテクノロジーの中で使えるエコシステムがどんどん広がっているからです。

これは Google のデータなんですけれども、昨年 1 年、Google Play だけでダウンロードされているアプリケーションの数は年間で 820 億回。ちょっと天文学的な数字ですよね。
これだけみなさんが使えるものが増えている。そして、これだけ多くの人の生活に関係あるビジネスがスマホを起点に大きくなっているということになると思います。

インターネットの次に来るトレンドは?

クラウドがもたらした「簡単にシステムが作れる」「ストレージがすごく安く使える」が、このモバイル、それから大量のデータを吸い上げるというビッグデータの流れを作ってきたと思うんですけれども。

今日お話しする AI や VR、IoT は、この流れにあるんですよね。

これだけ大量のデータが流れるようになった。それを処理するのにいちいち人がやっていたら大変だろうということで、このAIの流れがあるわけですし。「今のようにテキストとか情報だけじゃなく、体験も伝えられるようなインフラができているよね」ということで、VR や AR も来ている。

そして、データを吸い上げる対象は人だけじゃなくて、センサーからもどんどん吸い上げたい。ビッグデータへどんどん取り込みたいということで、IoT が来ている。

クラウドから始まったエコシステムの積み重ねで、この AI・VR・IoT が来ている。だから、単なるニュースのバズワードじゃなくて、確実なエコシステムの延長として来てるということですね。

今日、何度かこの黄色い本、『〈インターネット〉の次に来るもの〜』をフィーチャーしますけど、ここに書かれているのは、この不可避な流れというところです。

今日触れておきたいのはテクノロジーだけじゃなくて、日本におけるもう 1 つの不可避な流れ。これは人口減少社会というところです。



ちなみにこれ、内閣府のデータを使って私が昨日グラフにしてみたものなんですけれども。2010 年から始まって右肩下がりに人がどんどん減っていく。

ポイントは、購買層がどんどん減っていくんですよね。これがなにかというと、ファクトとしては労働人口・消費人口がどんどん減っていく。このままだと日本の GDP は絶対にシュリンクしていく。これをなんとかしなきゃいけない。

ちなみに今日、会場にいらっしゃってる方の年齢を確認しておきたいんですが。40 代以上の方、どれぐらいいらっしゃいますか?

(会場挙手)

30 代。

(会場挙手)

20 代。ここ一番多くいてほしいんですけど。

(会場挙手)

意外に少ない。10 代。

(会場挙手)

10 代いらっしゃる。

僕はちょっと逃げ切れないんですけれども(笑)。20 代・30 代の方は、この不可避の流れ、テクノロジーのエコシステムと日本のマーケットがシュリンクしていく流れにどう対応するか、すごい大事なことじゃないかなって思います。

「じゃあインバウンドで対応すればいいの?」「それとも世界に出ていけばいいの?」って話になると思うんですけども。今日注目したい1つのトレンドは「NEXT 5 BILLION」ですね。



さっきまでご紹介していたスマホのエコシステムに、まだ取り込まれない人がざっくりいうと50億人ぐらい残っている。このマーケットをどう飛び込んでいくか。これが実は大きなテーマになるんじゃないかなと思います。テクノロジーの不可避な流れと、この「NEXT 5 BILLION」をテーマにお話ができればと思います。

というところで、前フリがだいぶ長くなってしまいましたけれども。このあと服部さん、北浦さんのお2人にそれぞれ、インターネットの次に来るもの、このトレンドのNEXT 5 BILLIONのビジネスを実際やっていらっしゃる立場からお話を聞いていきたいと思います。

最初のVRブームで見た世界は「人工現実感」と呼ばれていた

それでは、お 2 人の簡単な自己紹介ということで、まず服部さんのほうから略歴と「こんなことやってきたよ」をおうかがいしたいと思うんですけれども。まずは、朝日新聞入社なんですよね。



服部桂氏(以下、服部):一応(笑)。

小島:一応、はい。

服部:最初のプレゼンにはどういうわけか「朝日新聞に入りました」って書いてました。

小島:理工学部から朝日新聞。文系みたいな感じですけど。結局、ITの世界にずっと関わっていらっしゃって。この『人工現実感の世界』はVRのことですよね。



服部:そうですね。最初の VR ブームの頃は「ヴァーチャル」って言ってもわからなかったので「人工現実感」って表現していました。

小島:表現も、この頃はまだこなれてない感じがありますよね。あと新聞初のインターネット連載。旧来のメディアとインターネットの融合をずっとテーマにして、かなり早い時期からやっていらっしゃったんですよね。

これ、いくつか写真をお借りしてきたんですけれども。この右側にあるのは「ウエアラブル・シンポジウム 2010」って書いてますけど、やったのは 1998 年。たぶん 2010 年を見越してというやつだと思います。



服部:そうですね。

小島:この女性がかぶってるのが、いかにも昔のウェアラブルな感じがして。

服部:ちょっとレトロな。

小島:レトロですよね。近年のウェアラブル端末とかから見ると、だいぶレトロな感じで(笑)。

服部:でも早かったんですよね。98 年。

小島:そうですね。あと、左にある『人工現実感の世界』は、さっき言った VR 的な世界ということになると思います。

デジタル社会は常に変化している


今日みなさんにお伝えしたいのは、服部さんは 1990 年代からこうやって、その時々のテクノロジーの変遷を、その時点から先を見通すというのをやっていらっしゃっていて。そんな服部さんの目から見ても最近一番ビビッときたものが、この『The Inevitable』というこの本じゃないかなと思うんです。このケビン・ケリーの本は見た時にゾクッときた感じですか?



服部:ケビン・ケリーさんは、有名な『Wired』という雑誌の最初の編集長です。今から25年前ぐらい前ですかね。彼が書いた最近の本が『The Inevitable』。今日の不可避というタイトルですね。



彼はだいたい僕と同じぐらいの世代なんですけれども、「いったいなんなんだろう?」と思って、その本を訳して。Inevitableじゃわからないので、一応『〈インターネット〉の次に来るもの』という日本語の題をつけて。「違うんじゃないか」とか言われましたけど、一応みなさん最近わかっていただいて。

今日もInevitableというイベントなんで、この本の販促会じゃないかなと僕は思って、間違って来ちゃいました(笑)。

小島:オンラインでサーチするとすぐ買えますので、みなさんぜひ。

服部:よろしくお願いします。

小島:この本がおもしろいのは、今まで過去に描かれていた未来予想図って、さっきのウェアラブルみたいな、その時に考えうるテクノロジーで未来の世界を考えてるんですけど。この本って、あまり特定のテクノロジーに触れていないんですよね。「こういうふうになるよ」という流れの話をしてるのがすごく特徴的だなと思ったんです。

服部:今のビジネス書は、「次はなにが当たる」「Googleの次はなんだ」「クラウドサービスってなに?」って書いてありますけど。結局はみんな当たらないわけですよね。なにが来るか。



ただ、ケビン・ケリーさんも私もずっとここ何十年かやってみて。なんか「インターネットなんかビジネスに使えないよね」といったらやっぱり使えたり、「もう全部情報が流れちゃってパッケージがダメだよね」という話はあっという間に現実になってしまって。
一つひとつのものじゃなくて。要するにデジタル社会は常に変化して、流れて、アクセスしていくような、こういう力学で動いていることは間違いないんですよね。

スマホのエコシステムに組み込まれてない人たち


小島:続きまして。NEXT 5 BILLIONで、もう現場に飛び込んでやっていらっしゃる北浦さんです。ちょっと自己紹介をしていただいてもよろしいでしょうか。

北浦健伍氏(以下、北浦):よろしくお願いします。ふだんカンボジアに住んでまして。カンボジアでおもに小規模農家を束ねて、オンライン農協のようなものを作ろうという感じで日々やっています。




小島:AGRIBUDDYという。

北浦:そうですね。AGRIBUDDYですね。たぶん、ここに来た中で一番遠くから来てるはずです。

小島:今朝、羽田に着いたということで。お疲れさまです。
ここでカンボジアを拠点に見てるマーケットというのは、このNEXT 5 BILLIONですよね。

北浦:新興国の小規模農家は約25億人いると言われているんですけれども。この人たちは間違いなくNEXT 5 BILLIONの中の半数を占めている人たちなんです。しかし、やっぱりこの人たちは未だにインターネットにつながっていない人たちなので。

小島:さっきのスマホのエコシステムに組み込まれてない人たちっていうことですね。

北浦:そうです。なので、Googleがなにかを知らない人ですし。Googleから見ても……。

小島:リーチされていない人たち。

北浦:リーチされていない人たち。そこが地球最後のデータ・フロンティアだと思っているので。そこをなんとか僕たちの手で握ってしまいたいなと考えて、今やっています。

「まだ取り込まれていない人々」をデータ収集し、可視化


小島:なるほど。小規模農家の話が出てますけど。ここも少しお話しいただいていいですか?

北浦:新興国の小規模の農家に、我々の胃袋は実はほとんど支えられています。現在で75パーセントぐらい。



ここから日本の人口は、先ほどの不可避な流れで減っていくとなっているですけれども、世界人口は増えていくようになっています。増える分のほとんどは、新興国の農業でサポートしていく流れになっています。

にも関わらず、彼らはみんな貧しい。なので、ここを解決し、彼らとビジネスしていくことができればなと考えてるのが、僕たちのアイデアですね。

小島:「貧しくなるスパイラル」と書いてますけど。



北浦:簡単なイメージだと思うんですけれども。新興国の農家は、みなさんがイメージされるとおり、非常に貧しいです。

農業で食えないから、みんなどんどんと都市に出ていって。要するに出稼ぎですね。そして残ってるのがおじいちゃんおばあちゃんとか、働けない人たちばかりになっている。そういう人たちだとうまく作業ができないので、よりお金が作られない。

しかもその人たち、さっきも言ったように、データに接続されていないので。第三者からその人たちがどういう人たちなのか、まったくわからない。

小島:データで見てる人からすると、いないことになってるような。

北浦:そうなんですよね。なので、いないことになってる人たちはプレイヤーではないという認定をされている。プレイヤーが普通にできるアイテム、例えばお金であるとか、ファイナンスや、今の情報から完全に外にいる。ここで僕たちが彼らのデータを集めることによって、実際にどこでなにが行われているのかをしっかりとやっていきたいなと思っているんです。

確かに一人ひとりの個別の農家は経験とか勘とはあるんですけれども。その蓄積だけなので、その人の中にしかないものになってる。それを外部から観測することができないので、第三者がまったく分析したりできない。僕たちがそれをデータ収集することによって、第三者から見て、彼らのことがよく見えるように可視化していくと考えています。
とくに先ほど言ってるように、経済の世界は、基本的には信用の塊で成り立ってるという。

小島:データがないと信用もされないってことですね。

北浦:信用もされないですね。過去のこともわからないし。過去のことがわからないから未来の予測もできない。であれば、その人を信用するに足るものがなにもないという状態なので、そこを僕たちが作っていきたい。



小島:個々の人というより、まるっとその人たちが全体で信用を今されていない。外されているという?

北浦:そうですね。

小島:そのために、その人たちにデータを紐付けるようなことを今やっていらっしゃるんですよね。

北浦:はい。

小島:ありがとうございます。たぶんそのデータを紐付けるところが、今後の潮流に実はうまくつながってくるんじゃないかなと思っています。

テキストベースで共有できる情報は限られている


このお2人にいろいろ今日聞いていきたいもの。大きく3つの質問として用意しています。
まず1つ目なんですけど。今回、モバイル、ビッグデータ、エコシステムのあとに、AI、VR、IoTってけっこう来るんじゃないかっていうのが、まあこのイベントの大きなテーマなんですけれども。

例えばじゃあ、今までのデジタル経済圏から外れさているマーケットでやっていらっしゃる北浦さん。いきなりこれがやってくるような世界になると、このなかだと一番注目株ってなにかありますか?

北浦:やっぱりVR。

小島:VR?

北浦:はい。僕の中ではAIとかIoTは、仕事を便利にするとは思うんですけど。僕は今、やはり途上国の人々とやっていて一番戸惑っているのは感覚の共有なんですね。



小島:感覚。つまり知識じゃなくて体験とか。

北浦:はい。例えば、カンボジアってご存じのとおり常夏の国で、年がら年中暑いんです。でも、あの人たちにとって寒いと感じるのは、だいたい18度以下なんですよね。18度以下になると「寒い」とか言い出したりするんです。あの人たちにいくら日本の「しびれるような寒さ」とかいっても通じないんですよ。

あとは「きれい」ですよね。カンボジアの人たちは整頓されているものを見たことがないですし、いわゆる美術的な美しさを見たことがない。そんな人たちに「美しい」「きれい」は伝わらない。

小島:カンボジアには「美しい」に相当する言葉は1つしかないって聞いたんですけど。

北浦:そうなんですよ。「saat」って言葉なんですけど。これで「かわいい」「きれい」「清潔」「整頓されている」をすべてまかなっているんですね。

小島:じゃあきれいもそれだし、整頓されている部屋もそれだしみたいな?

北浦:そうなんです。なので、「床が可愛い」とか言ってしまったりするんですけど、彼らにとっては「かわいい」「清潔」の違いがなにかわからない。
ここはやはり実際にきれいな様子を見せるとか一緒に体験するとか。そうすることで初めてお互いに共有できるものが完成する。今までのようにテキストベースの知識を得るところではできないんです。

小島:じゃあ、Webが今までテキストというか知識を共有するものだとしたら、VRは体験とかコンテキストを共有するようなものだという。

北浦:だと、僕は思う。

小島:それに、その方を経済圏に取り込もうと思うと、それがないとちょっと会話にならない?

北浦:ならないですね。

小島:なるほど。ありがとうございます。

AIブームがなかなか成功しなかった理由は「データ不足」


これは服部さんのほうから実はスライドをいただいてきたんですけれども。AI・VR・IoTが1つ渾然一体になってるような絵になっているものです。これ、ちょっと解説していただいてもいいですか。




これちなみに真ん中にあるのはクラウドってことですよね。クラウドをまたいでAIと、それからVR。

服部:なんか、出の音楽があまりに若かったので。みなさんの年齢も40代以降って言われたんだけど、僕、60代以降なので。まあこれからは高齢化社会になるということも含めてちょっとお話ししたいと思っています。

小島:(笑)。

服部:今日、クラウドのお話なので、私がケビン・ケリーさんの本なんかを見て、ちょっと問題を整理しようと思って描いたものなんですけれども。

上のほうからシンギュラリティ、AI、マシンラーニングとかプラットフォームとか書いてありますけれども。なにを言いたいかというと、AIの論議の中で最近言われているのは「昔からAIはありました」「だけど、それが最近ものすごく高速になって、1ヶ月かかっていた計算が1日でできるようになりました」です。

昔は、データがほとんどなかったんですよね。でも今、Googleさんの中には山ほどデータがあります。

この中でも例えられていますが、昔は……ロケットに例えると、最初はペンシルロケットみたいなやつだったんです。でも今はICBMになっちゃった。

そのICBMみたいな大きなオペレーションをやるには、すごく大きな燃料タンクが必要です。まさにビッグデータですね。それもすごく頭がよくて、機敏に動ける。この両方が必要です。

上の方に、どちらかというとAIとマシンラーニングなど、アルゴリズムで動いている部分があり、プラットフォーム以下は Google が言っている Tensor Processing とか、いわゆる Fog Computing がある。

とにかく、下の方からどれだけ大量のデータを自然にたくさん収集できるか。変に考えないで日々の生活そのものをいっぱい入れることで、より大きなデータをより高速に回す。これが、今のトレンドで起きている。

小島:なるほど。私が知る限りAIは今「第3次AIブーム」って日本では言われていて。過去何回か技術的なブレークスルーが来ると思いながら結局フライしなかったのは、燃料足りなかったからなんですよね。データという燃料ってことですかね。

服部:そうですね。だからより大きな、……ちょっと例えは悪いですけどね、おもちゃのロケットからICBMみたいな感じになっていて。ロケットであることには変わりないんですけど、ものすごく大規模になるとできることが変わります。

小島:その燃料が、VRやIoTという体験、センサーから来るような情報がどんどんクラウドで吸い上げられて、今までにない種類の燃料になるような。

服部:ええ。昔は手で打ち込むとかね、いちいちデータを入れるのが大変だったんだけど。VRだと、体験とかいちいち説明しないで動作とか360度で出ちゃう。

小島:これで「寒い」が伝わるし、農作業の仕方も伝わるような。

北浦:結局、この10年ぐらいで、約17億人がスマホを使うようになったんですよね。でも、あとまだ50億人が取り込めていない。なので、データが集まってるとはいえ、やはり17億人ぐらいですから、まだ偏ってはいるんですよね。

とくにその17億人というのは、教育をされていて先進国に住んでいる人たちがメインなので。そうではない人たちのデータが集まってきたときに、今までちょっと違うあっと驚くようなデータというのが、偏ったものがまだあるんです。

小島:まだ見つけられていないタイプのデータってことですよね。

北浦:あると思いますね。

<続きは近日公開>

次回イベント開催のお知らせ
「Inevitable ja Night - インターネットの次にくるもの Presented by Google Cloud」
第2回 AI とビジネスに起こる不可避な流れ

日時 : 11 月 14 日 (火) 19 : 00 - 21 : 00
定員 : 200名
主催 : グーグル合同会社

Posted by Takuo Suzuki - Developer Relations Team

第 2 四半期末の AMP ロードマップのアップデート

$
0
0
この記事は AMP Project プロダクト マネージャー、Vamsee Jasti による Accelerated Mobile Pages Project の記事 "AMP Roadmap update for end of Q2" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

AMP ロードマップがアップデートされました。既存の優先事項の進捗といくつかの新しいプロジェクトが反映されています。以下で主な点について説明します。

フォーマット
AMP のインタラクティブ性を向上させる柔軟なイベント バインディング システムである amp-bindは、現在本番環境で完全に利用できます。この機能が AMP にもたらす能力の全容を把握するには、こちらのブログ投稿をご覧ください。また、Ajax によるフォーム入力の検証サポート(試験運用版ですが、近日中に正式リリースされる予定です。サンプルはこちら)と、amp-bind を使って検索候補の自動表示を行うビルディング ブロックも先日追加されました。

さらに、AMP のエンゲージメントを向上させる一連の機能の開発も進行中です。特に、この四半期には、amp-image-lightboxを改善することを計画しています。これによって、amp-carouselと連携した迫力あるライトボックスを簡単に実装して体験してもらえるようになります。スクロールと連動したアニメーションも、今後数か月の間にリリースされる予定です。これが完成すると、この汎用ソリューションをパララックス状況依存で表示されるヘッダーにも利用できるようになります。このスクロールと連動する新機能は、動画でも利用できます。たとえば、インライン動画がスクロールして画面外に隠れた際に、ビューポートの端に固定して小さく表示することができます。そのため、ユーザーは注目動画を表示しながら、ページ内の他のコンテンツもシームレスに参照できるようになります。


さらに、さまざまな業種のデベロッパーが見栄えのよい AMP ページを作成できるように、まもなく AMP Startの新しいテンプレートが公開されます。コードを直接編集せずに AMP Start ページを設定できるようにする AMP Start テンプレート設定ツールの開発も行われています。

また、インタラクティブ性をさらに向上させるいくつかの長期的な機能の開発にも着手しています。

アナリティクス
第 2 四半期の終わりとともに、amp-analytics で動画アナリティクスをネイティブにサポートするための集中対応が始まっています。この対応は、まず amp-video から行われます。これは現在試験運用版として利用でき、来週には正式版がリリースされます。この機能を使うと、サイトオーナーは再生や一時停止といった動画イベントに関連する動画固有のデータを取得できるようになります。仕様は上のリンクから参照できますので、提案されている仕様がニーズに合うかどうかについてフィードバックをお寄せください。

別の分野では、以前の四半期の作業(amp-analytics を利用してデータを収集できるようにする AMP 拡張機能)が終了しつつあるので、フィルタのサポート作業を近日中に開始する予定です。また、amp-analytics をカスタマイズする方法をさらに追加するさまざまなプロジェクトが計画されています。たとえば、ロードマップには reportWhenなどの機能が記載されています。

広告
サイトオーナーが広告リクエスト情報を拡張し、より適切にターゲットを設定して収益を増加できるようにする作業を進めています。これには、Real Time Config(RTC)と呼ばれる新機能を使います。RTC を使うと、サイトオーナーが Cookie ベースのターゲット情報やそれよりも幅広い対象端末に関連する情報を使って安全かつパフォーマンスよく広告リクエストを拡張できるため、ユーザー エクスペリエンスに悪影響を与えることなく、AMP インベントリであげる収益を増やせるようになります。RTC を使ってすべてのターゲティング ベースのユースケースを実装したいと考えています。Github の Issueへの報告をお待ちしています。

また、AMP ページに表示される競合他社の広告の排除やブロックを行うスポンサー キャンペーンを実現したいという古くからの要望にも対処する作業を進めています。これは、AMP ページのすべての広告リクエストを相互に関連付けることによって実現します。機能の開発はすでに始まっており、近日中に試験運用版がテスト公開される予定です。この機能をテストしてみたい方は、Github でお知らせください。

なお、AMP By Exampleではすでにたくさんの画期的な AMP 広告(例: AMP 形式で作成されたライトボックス広告)が利用できるようになっています。これを変更して無料でキャンペーンに利用することもできます。また、amp-animationの導入に伴い、スクロールと連動したアニメーションを使った広告も簡単に直接販売キャンペーンに組み込めるようになっています。
* * *

作業したりフィードバックを寄せてくださっている AMP 開発コミュニティの方々に感謝いたします。いつものように、問題や機能リクエストがありましたら遠慮なくお知らせください

Inevitable ja Night イベントレポート「不可避な未来」x「NEXT 5 BILLION」対談02

$
0
0
6 月 12 日に開催した「Inevitable ja Night - インターネットの次にくるもの」ではさまざまなゲストを交え、Google Cloud といったテクノロジーの進化によってこの先の世界はどう変わっていくのか、VRやARなどの領域で活躍している人材をゲストに議論しました。本記事は、スピーカーとして、ジャーナリストの服部桂氏とAGRIBUDDY LIMITED 北浦健伍氏、モデレーターは小島英揮氏で行われたInevitable ja Night イベントレポート「不可避な未来」x「NEXT 5 BILLION」対談 01」セッションのレポートの続きになりますので、是非合わせてお読みください。



【スピーカー】
ジャーナリスト 服部桂 氏
AGRIBUDDY LIMITED. CEO 北浦健伍 氏

【モデレーター】
パラレルマーケター・エバンジェリスト 小島英揮 氏
【2記事目】

数十年後、検索回数は飛躍的に伸びる






服部桂氏(以下、服部:クラウドも、僕ら考える規模で考えていると想像を超えてしまうということがあるんじゃないでしょうかね。

そうすると、我々のビジネスモデルといった前提条件を外して考えないといけないようなシンギュラリティの論議がやっぱり出てくるってことですよね。

小島英揮氏(以下、小島):この AI 的なプロセッシングとVR・IoT。これをデータレイヤーと言っていいかもしれないですけど。これはやっぱりつなげていけるのもクラウドというエコシステムがあるからという理解でいいですか。

服部:まさにそのクラウドが優れたアルゴリズムと計算能力とビッグデータをつないでいる。

クラウドという世界最大のコンピューティングプラットフォームであって、高信頼性で、かつ我々の人生が全部入っちゃってるわけですよ。だからもう一生お付き合いしなきゃいけないというかね。もう「これやめますか、人間やめますか?」ぐらい、もう一生のデータが入っちゃっている。

小島:確かに。じゃあこういう感じですよね。

さっき北浦さんが「VR が 1 つで破壊力あるもの」だと。今まで伝えられなかった体験というものを伝えるというのは非常におもしろいけれども、それは独立してるものじゃなくて、VR・IoT も AI も実は 1 つの大きなエコシステムの中にあり、その要がクラウドのエコシステムだというイメージと……。

服部:そうですね。だから、利用できないデータを入れてもダメなんです。素直にいいデータを意識しないで自然にどんどん入れていって、みんなでシェアしていく。より大きいデータが意味があるんだけど、今、頭で考えたり、恣意的にいろんなことをやっていると、データの質が高まらないわけですね。

そのためには VR を使ったり IoT を使ったり。そういった技術をうまく使って、自然にどんどん滞りなくデータを還流してシェアできるということだと思いますね。

小島:かつ、人が判断しない。AI が判断するので、たぶんデータ一つひとつはあまり大したことなくても、数が来るとAIがよろしくいろいろ考えてくれるみたいな世界になるんじゃないか、と。

服部:そうですね。だから、そこらへんの 1 つのインターフェースとして、AI 的なものがあったほうがいいと思うんですよね。今は打ち込むんじゃなくて、言葉で言えば全部データになっていくとか、いろんな翻訳をしてくれるとか。要するに、アシスタントとしていろんなことをどんどん助けてくれるってことですよね。

新興国での スマートフォン の価値は「お金持ちに見える」


小島:そうすると、情報の流れがつながっていないといけないので。それがぐるっと回って今、北浦さんがカンボジアでやっている。今現在はみんながスマホでつながってるわけじゃないけれども、数少ないIT機器を中心に、現地の農家の方といろんなデータをつなぐ流れを今、人の流れを作ってるわけですね。人によって情報の流れを。

北浦健伍氏(以下、北浦):はい。

小島:その情報の流れができていれば、そこに VR や IoT、AI など、そもそもスマホがやってきたときに爆発的に流れる装置ができる。

北浦:まずいったんつながらないと、本当にどうにもならないので。

小島:だから、いきなりスマホだけ渡してもつながらないってことですよね。

北浦:そうなんです。

小島:情報の流通……。

北浦:本当に僕たち最初にカンボジアへ行った時。iPhone 2 台持ってる人とかいるんですけど、「あの人たちはなんで iPhone 買うか」と考えたのですが、それは自分が金持ちだと見せたいからなんですよ。



小島:札束みたいなやつ?

北浦:そうです。だから「写真を送ってよ」って言ったら、写真は送れないっていうわけですよ。「いや、インターネットで送れるじゃない」って言ったら「そんなものにはつながっていない」って。

小島:でも、金はあると。

北浦:はい。

小島:なるほど、なるほど。

北浦:だから、ぜんぜん違うエコシステム。

小島:それを本来の情報とかデータの流れにつないでいくというのが、今の北浦さんのやられている作業ですよね。

北浦:そうですね。はい。

小島:それが1度できれば、このエコシステムが来たときにガッといくということですね。

北浦:はい。

「英語さえ話せれば世界中の人と意思疎通できる」わけではない!


小島:なるほど。わかりました。じゃあ結局 AI・VR・IoT、クラウドをのりにして、不可分なエコシステムだなっていう話になってきたと思うんですけれど。

では、そのマーケットに行こうと決めたところで。日本でやっていくのは実は大変なんじゃないかと僕個人としては思っています。だって、マーケットはシュリンクしているじゃないですか。

今、実際に日本を飛び出しちゃって、それもアメリカじゃなくカンボジアでやっている北浦さんの目から見ると、エンジニアや起業家に求められているものはなんですかね? 技術的なトレンドは、今なんとなくわかったんですけれども。

北浦:日本人のほとんどは、外国でやるなら英語を話さなきゃいけない。逆に言うと、日本はすごく英語信仰が強くて「英語さえ話せれば世界中の人と意思疎通できる」と思っています。

小島:僕らはそう習いました。

北浦:これ、実はまったくそうではなくて。

小島:(笑)。

北浦:確かに英語で意思疎通は……。英語をしゃべれると伝わったような気にはなるんですけど、実はまったく伝わらない。



日本という国は、言葉の外で「こうだよね」「言わなくてもわかるよね」というところがものすごくたくさんある。その中で会話が成り立っている社会なんですね。僕たちもよく言うんですけれど「コピーとってきて問題」というものがありまして。

小島:コピー? コピーってこの紙の?

北浦:そうそう。例えば、日本の会社にいて「ちょっとコピーをとってくれ」と言われたら、絶対にコピーをとって持ってくるじゃないですか。デスクまで。待っていて来なかったら怒るよね、という話なんです。

カンボジアでは「コピーをとってきて」というと、ほとんど持ってこない。「あれ、コピーは?」と言ったら「とりました」と言われる。

小島:(笑)。

北浦:「持ってこいとは言われてない」って話になります。なので、そこは大前提がまったく違う。

小島:じゃあ、どんなに Google Translate が進化しても、それじゃダメだってことですね。

北浦:ダメです。

小島:「コピーをとれ」を翻訳するだけでは伝わらなくて。それを咀嚼して原文にちゃんと「とって、持ってきてください」まで言わなきゃいけない。

北浦:言わなきゃダメなんですね。だから逐一そういう細かいところまで手取り足取りマネジメントしないといけないんですけど。日本ではそこをしなくていいというか「そんなことを言わなきゃならないやつは仕事ができないやつ」という中で生きているじゃないですか。でも世界に目を向けたときは、それを言わなくちゃ伝わらない人が完全にマジョリティ。

小島:そっちのほうが多いんですね。

北浦:多い。圧倒的に多いので、そういう人たちと一緒にやっていくには、彼らが「できないやつ」じゃなくて、自分たちが彼らに合わせていくしかない。

小島:なるほど。例えば日本が縮小して、阿吽の人がどんどん縮小していくなかでビジネスを考えるときには、コミュニケーションとか伝える力がベーシックに求められる。

北浦:そうですね。はい。今後は伝える力とマネジメントする力が一番求められるんじゃないかなって。

テクノロジーで感情を伝える手段を考えなければならない


小島:服部さんから見ると、ジェネレーションギャップで「近頃の若い者は……」みたいなのあるかもしれないですけど。それ以上のギャップかもしれないですよね。

服部:そう思いますけどね、大手の新聞社も新聞を買ってくれないんですね。みんなデジタルで読めるから、ということで。文字に書いてるものはもうみんなお金を払わないんですよ。お金を払ってるのは自分が好きなものとか感情とか。

これから(検索量が)1 兆倍になったときにどう考えるべきかというと、文字がいっぱい増えて、いっぱいページが増えるということじゃない。例えば AI なんかが感情を Google さんが読んで、それに合わせてくれるとか、文字になっている。先ほどの「コピーをとりにいく」を 3D、もしくはロボット使ってやってくれるとか。

それから今、検索できないものありますよね。例えば自分の体の中とか部屋の中とか物とか。まったく我々が考えもしなかったような部分に Google 的な機能で検索できる。
すごくよく言うのは、Google さんが世界をつないで、あとの 5 億人とコラボできるようにする。そういったツールがあって初めて 70 億人がつながる。今の 70 億人はコラボできない、ネットがなきゃ絶対できないんですよね。

だから、そこらへんを目指して。そのために AI を使って、より新しい次の次元を目指していただいてるんじゃないかなという気は僕はしてるんですけどね。

小島:北浦さんの視点からいくと、まず伝える力・伝える能力がすごい大事だし、服部さんの考え方でいくと、今してるところを、サービスとかツールとかテクノロジーでなんとかすると、新しいビジネスになる。

服部:そうですね。だから今言われたような話をさらに新しいITテクノロジーで、コンテキストを伝えるとか、感情を伝えるとか、シェアするというような、我々が今考えているよりもうちょっと一段上のアプリケーションを考えていかない。

それは今から 1 兆倍のデータや、その処理能力があれば、やらないといけないことだと思うんですよね。きっと。

翻訳機能だけでなく「行間を読む機能」


小島:なんか、いろんな前提が変わっちゃう?

服部:そうなんです。

北浦:Google 検索でもそうなんですけど、基本的に文字が読める・理解できる前提じゃないですか。世界のいろんなデータを見ると「識字率が高い」みたいなことが書いてあるんです。でも、あの識字率は「文字が発音できる」なんですよね。だから、地名は読めるし、相手の名前も読めるんですけど、センテンスになると理解しないんです。

小島:単語はわかる?

北浦:単語はわかるんです。だから、「カンボジア」って書いてあるとか「インド」って書いてあるとか「北浦さん」とかはわかるんですけど。「北浦さんがどこどこにいって誰々と会った時にどうしてこうしたから、〇〇」っていう文章になるとわからない。

小島:ものすごい複雑なんでしょうね。それ。

北浦:複雑です。日本人でもそうですけど、「Don’t Go」「Stop」はわかるけど、5 行ぐらいの文章にされると英語読むの苦手な人が多いじゃないですか。あれが自国語のレベルなんですよね。

だから文字ではないものでいかに伝えるかが、NEXT 5 BILLION にはものすごく重要なポイントだと僕は思っています。

小島:すごくリアリティがありますよね。日々、それをカンボジアでリアルに感じていらっしゃる。

北浦:本当に伝わらないんですよ(笑)。

小島:英語が万能では絶対にないということですよね。

北浦:はい。ないですね。

小島:そこを単純にテクノロジーで、翻訳だけではぜんぜんダメで。行間を読む機能とか、そういうのが必要になる。

北浦:そうですね。結局、言葉は頭の中にイメージしてることを、僕たちは便宜上の言葉にして伝えてるだけなんです。でも、この頭の中にあるイメージをいかにそのまま相手に伝えられるかが、やっぱり最も大事になってくるんだろうなと思います。そのあたりが次のテクノロジーの大きなブレークになるんじゃないかな。

「世界を目指すなら、日本の顧客は無視したほうがいい」


小島:わかりました。では、その新しいテクノロジーやコンテキストでビジネスを考えていくとして、すごいレガシーな質問なんですけど。それを始めるために、日本拠点でみなさん始めたほうがいいのか、それともどうせ海外へ行くんだから、初めから出ていってしまったほうがいいのか?



一般的によく聞かれる話だったりするんですけど。これはもう日本を出ていってしまった北浦さんからすると、どう捉えますか?

北浦:顧客がどこにいるのかというところが、最も大事かなと。

小島:どこにいるか。つまり、自分がやりたいサービスとかビジネスのお客さんがいるロケーションはどこですかと?

北浦:はい。例えば、「日本で成功しました」「そこから世界に出ていきます」って言ったとき、そこに大きなハードルがある。それは先ほど言ったように、そもそものバックボーンとか常識が違うからなんですね。

それを最初から僕のように海外でやってしまったときは、ハードルがあるわけで。どこかのタイミングで日本から世界に出るときは、ハードルがあるとは思います。
とはいえ今、日本と世界という考え方をするというのも、今後はどんどん変わっていくのかなと思います。

例えば僕、大阪出身なんですけど。やっぱり大阪の人はなかなか東京に出てこないんですね。彼らが言うには「大阪がいいか、日本がいいか」みたいな話をしちゃうんです。

小島:これの、もうちょっとスケールダウン版。

北浦:もっとスケール小さい版。

小島:日本と世界じゃなくて、大阪か日本か。

北浦:そうなんです。でも、本当はそうじゃなくて「別に大阪でもいいし、最初から日本中でやるんだったら、別に大阪だけにこだわったものを作らなくてもいいじゃない」という感じには思います。

小島:それって、どうせ出ていくんだったら、お客さんと近いところはどこかを見ないといけないし、どうせ最後にそこへ出ていくことを考えたら、初めにそのハードルを超えるのか、1 回体制整えてから超える。でも、どこかで超えなきゃいけない。

北浦:そうなんですね。体制を整えてから超える。これ、実はすごく難しい。

小島:むしろ体制ができちゃったから、超えるのは難しい。

北浦:そこを壊してまた出て行く必要が果たしてあるのかっていう。日本という特殊なマーケットの中でうまくいっているものをわざわざ壊して、違うところでうまくいかすものを持っていかなければならないところがあるので。

もし、日本でうまくいかせることを考えてビジネスをするのであれば、あまりグローバルは逆に考えずに、日本の……。

小島:お客様が日本にいるビジネスということですよね。

北浦:そうですね。逆にいうと、最初から世界に出て考えるのであれば、日本の顧客を無視するぐらいの感覚でやっちゃわないといけない。

小島:どこが自分のマジョリティなのか。そこに合わせるべきだってことですよね。

北浦:はい。

あらゆる既存価値を、国を超えて議論しないと始まらない


小島:一方で、服部さんはいろいろ世界とかトレンドを俯瞰して見ていらっしゃいますけど、国で切るという考え方ってもしかして古いんですかね?

服部:それなんか、20 世紀の質問じゃないですか?

小島:あ、ごめんなさい(笑)。

服部:21 世紀ですよ、今。それは半分冗談ですけれども。みなさんがネットを使い始めて20年ぐらいじゃないですか。メールとか使ってなかったですよね、最初。それから携帯も使ってなくて。

ここ 20 年で生活とかビジネスが変わったと思うんですよ。これから 20 年経ったら、まったく想像もつかないよね。というふうに、覚悟しておいたほうがいいと思うんですよね。
そういう意味では、20 世紀はグローバリズムでは「国を超えて……」と言ってましたけど、今まさにネットの中でやっているのは、もう 1 つの国を超えちゃって、1 つ、Google 国みたいのがあって。これは要するに 30 億人が……。まあ、Facebook だって 10 億人以上いますから。

小島:そうですね。

服部:そういった Google や Facebook といった中でアイデアを共有したり、ものを作ったりしています。だからもう、国というもの自体が事実上……。昔は「なくなるよね」と言っててまだなくなっていないけれど。どちらかというと、Google や Facebook のようなものがもとになって産業ができて、サービスができていくことを真剣に考えないといけないと思うんですね。



これから何十年くらい経って、みなさんが仕事をするときに国とかっていうのを考えいたらもう古いというか。どっちかというと……。

小島:国境というのは、例えば県境と同じぐらい感じであるけれども……。

服部:あるとは思いますけどね。

小島:けれども、ビジネスを規定する線じゃなくなってくるんじゃないかってことですか?

服部:まさにネットのなかで Google のクラウドのなかでの著作権とか知的所有権とか、もう国を超えて論議しないと始まらないわけですよね。

小島:そうですよね。

服部:そういう意味では、これから近代が作ってきた国とかいろんな価値がバンバン壊れちゃってですね。家族も壊れちゃうかもしれないし、男女間の垣根もなくなっちゃうかもしれない。

要するに、我々はこれから 10 倍ぐらいになるイメージじゃなくて、1 兆倍になってですね、まったく違う世界になることを覚悟しておかないいけない。そうじゃないと、あとで「えー、そんなの想定外」みたいな話がいっぱい出てくる。過去 20 年でもいっぱい出てきましたからね。これからもっと出てくるんじゃないかなっていう気がしますね。

小島:これまでの視点で、クライテリアとかエリアを切るんじゃなくて、本質を見たほうがいいってことですね。自分のお客さんがなにか。自分はどこにいくのか。そこで一番近しいところはどこかを選ぶセンサーと、そこと会話するコミュニケーション力が必要。

北浦:そうですね。

日本はパスポートがある点で圧倒的有利


とくに今のところ、国というものがあるなかでは、日本のパスポートってものすごくどこでも行きやすいんですね。

小島:日本人であるということは、このビジネスをやる上で……。

北浦:大きいですね。選べるので。例えば、僕たちが今いるカンボジアの人たちが逆に「日本に来てビジネスします」「ヨーロッパに来てビジネスします」というときにでも、まずパスポートの時点で行けないというハードルがある。もちろんビザは取れるんですけど、パスポートをとるのはめちゃくちゃハードルが高いんですよ。

僕たちは、そのハードルをボーンと飛び越えてしまっている。これは、グローバルで進めていくときに、かなりのシード権のポジションにあるんですね。

これが今後どうなるかわからないわけですね。でも、今のところ、日本のパスポートは世界でも有数、指折りのパスポートなので。これを持ってる時に早く勝負をするべきじゃないかなと思いますね。

小島:今の視点、すごくよくて。中にいるとなかなか気がつかないですけど、外から見ると「こんなにいい通行手形はないよ、ビジネスの」ということですよね。

北浦:そうですね。うちのインド人パートナーも、アメリカへ行くのに、大使館に行って先に 10 万円を払うんですって。

小島:先払い。

北浦:先払いです。これ、ビザもらえなかったら 10 万円なくなるんですよ。
僕たちは別にアメリカでビザと取らなくても「明日から行こう」ってできるでしょ。でも、カンボジア人がアメリカへ行きたいときは、インターネットでまず申込みをして、そこから 1 ヶ月先にようやく大使館に面談に行ける予約ができるんですよ。

そこで初めて面談をして。今のところカンボジア人がビザもらえるのは 3 パーセントです。97 パーセントの人は、カンボジア人、1 万 5,000 円も払って……。

小島:じゃあ、圧倒的に僕らは有利ってことですね。

北浦:有利です。

小島:それを使わない手はない。

北浦:そうなんです。これを使わない手はないと思います。

小島:なるほどね。

Think Big にいけ


「これ使わない手はない」って話をいただきましたけど、最後に 30 秒ずつぐらいでなにかひと言ずつ。ゲームチェンジがやってくるわけですけど、この会場のみなさんに「これからは真摯にやっていくといいよ」みたいな、もしひと言あればいただければと。
まず、北浦さんから。

北浦:Google もそうなんですけど、今までいろんなフロンティアっていうところは完全に欧米企業に押さえられていました。だから、日本企業が世界のフロンティアを取ってきたっていうのは、僕、まったくないと思うんですね。

でも、先ほどの NEXT 5 BILLION に関しましては、まだフロンティアです。今のところは完全にがら空きです。やはりここをどんどんと取りにいくような人たちが日本からもっと出てきほしいなと僕は考えています。

小島:もう「すぐ行け」ということですね。

北浦:はい。

小島:じゃあ、服部さん。

服部:とてもおもしろいセッションだったと思うんですけれども。Inevitable というのは、実は「未来」という意味なんですね。ケビン・ケリーさんはやっぱり「未来」とかいう陳腐な言葉を使いたくなくて。

我々が避けられない未来をどう考えるか。

未来というのは必ず来るんですけれども、想定外が必ずあるわけですよね。でも、それは我々の想像力が不足してるからです。「こんなはずじゃなかった」とか。それで、コンピュータは全部 AI を使って。AlphaGo は名人が考えなかったような手を全部考えてくれる。だから、コンピュータと一緒に協力することによって、我々の未来への想像力のオプションを増やしてあげる。

極端なことを言うとあれですよ、みなさん。日本人とかそういうのじゃなくて、もう 21 世紀は地球人。

だからもうちょっと、どうなるかはわからないですけど、今のスケールとかものの考え方は前提にしなくちゃいけないんだけど、なるべく「そのスケールを超えたらどういうふうに自分の未来がなっていくか」ですね……。

小島:なるほどね。「Think Big にいけ」という感じで。

服部:そういう発想をしてるほうが、想定外とか、「そんなはずじゃなかった」ということがない。そのためにクラウドなんかをどんどん活用するのは、一番人類の平和のためにはいいんじゃないかなと私は思っていますね。

小島:わかりました。ありがとうございます。Think Big ということですよね。

僕からは、これからは大きさじゃなくて速さが武器になる時代だと思います。



もちろん今日ここにいらっしゃってる方は、それを理解してたぶんいらしゃってると思うんですけれども。それが今まで以上に強みになってくる時代になるんじゃないかなと思っています。

速くやれば速く武器を使えて、速くフィードバックを得られる時代になると思うのです。なのでぜひ、今日はみなさんの次のアクションためのヒントをつかんでいただいて、誰よりも速く動くというのをこのイベントを機にやった方が生まれてくると、我々としてもうれしいかなと思います。ありがとうございます。

それでは、まだまだ話していたいんですけれども、お時間になりましたので、こちらのほうで対談のほうは終了とさせていただきます。

今一度、今日のスピーカーのお2人に拍手のほうをお願いしたいと思います。ありがとうございました。

北浦:ありがとうございました。


いかがでしたでしょうか? 今後このようなテーマでの議論を定期的に開催していく予定です。

次回イベント開催のお知らせ
「Inevitable ja Night - インターネットの次にくるもの Presented by Google Cloud」
第2回 AI とビジネスに起こる不可避な流れ

日時 : 11 月 14 日 (火) 19 : 00 - 21 : 00
定員 : 200名
主催 : グーグル合同会社



Posted by Takuo Suzuki - Developer Relations Team

Progressive Web AMP に AMP を組み込む: ShadowReader のご紹介

$
0
0
この記事は AMP デベロッパー アドボケート、Paul Bakaus による Accelerated Mobile Pages Project の記事 "Putting the AMP in Progressive Web AMPs: Meet the ShadowReader" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

AMP と PWA(プログレッシブ ウェブアプリ)の組み合わせについては、今までにもたびたび取り上げてきました読者が AMP ページを見ている間に PWA をプリロードするというのはかなり単純なアイデアですが、別の組み合わせのパターン、すなわち AMP をデータソースとして利用して PWA を強化するというアイデアはあまり理解されていません。

私が担当した先の Google I/O のセッションでは、数分で書けるコードを使って PWA 内で AMP ページをレンダリングできるとお伝えしました。それ自体は間違いありませんが、本番アプリで行う必要があるすべての作業について触れたものではありません。セッションの目的は、まず自分で試してみて、ゼロから本番向けの PWAMP を作ってみることでした。そこで今回は、ShadowReader を紹介します。




以前リリースした単純な React ベースのサンプルアプリとは違い、ShadowReader デモアプリはいわゆる「Vanilla JS」と呼ばれる純粋な JS のみでできており(もちろん AMP は例外です)、The Guardian の実際のフィードと AMP ページを使っています。さらに、アプリの作成に必要な作業をお見せするため、すべてゼロから作られています。スマートフォン(やエミュレータ)を使って実際に https://amp.cardsから動かしてみることもできます。

では、このアプリのどこが特別なのでしょうか。今回は、AMP ページの用語をご存知の方向けに言えば、いわゆる「アプリシェル」をどれほど早く作れるかを紹介しています。このアプリは、記事を表示するためのテンプレート ロジック全体が含まれた巨大アプリとは違い、単純に Guardian の RSS フィードを読み取っています。カードがクリックされた際に既存の AMP ページをインラインでレンダリングする処理は、AMP に委譲しています。これによって、エンジニアリング作業とアプリ自体が信じられないほど軽量になります。他にも、次のような特徴があります。
  • 実際のデータを取得しているので、実際の問題を解決していることになります。 
  • 10kb 未満のサイズ(Guardian Web フォントと AMP を含めても最大 200kb)です。 
  • 体感的なパフォーマンスを向上させるため、スムーズなカード遷移とスケルトン UI を取り入れています。 
  • 完全な URL ベースのナビゲーションと共有がサポートされています。 
デベロッパーの皆さんは、ぜひソースコードをご覧ください。FLIP ベースのアニメーション、遅延読み込みされるカードとシームレスに再接続される記事のビューなど、アプリのそれぞれの機能や要素がどのように構築されているかは、私のブログで紹介しています

ShadowReader は、半分はインスピレーションを与えるため、半分はチュートリアルとして作られています。ぜひ、PWAMPが皆さんのユースケースに応用できるかを評価するためにご利用ください。また、サポートが必要な場合は遠慮なくご連絡ください。現在、PWAMP は大流行中です!


Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

Progressive Web Apps Roadshow Tokyo 2017 を開催します

$
0
0
Google では、2017 年 9 月 22 日(金)に Progressive Web Apps Roadshow Tokyo 2017 を開催します。 本イベントではモバイル Web のユーザー体験を向上させる Progressive Web Apps についてのセッションおよびコードラボを行います。



イベント概要

【イベント名】 Google Developers Summit : Progressive Web Apps
【日程】 2017 年 9 月 22 日(金) 9:30 - 18:00 (開場: 9:00)
【場所】グーグル合同会社
【定員】 200 名


当日のスケジュール

午前の部  9:00 -   9:30    開場
  9:30 - 10:00   キーノート: Progressive Web Apps: What, Why and How
10:00 - 10:45   セッション 1: Service Workers for Instant and Offline Experiences
10:45 - 11:00   セッション 2: Securing the Foundation with HTTPS
11:00 - 11:15    休憩
11:15- 12:00    セッション 3: Deep Engagement: Installable apps and Push Notifications
12:00 - 12:30   セッション 4: Web Payments
12:30 - 13:30   ランチ
 

午後の部 : セッションの後コードラボを開催
13:30 - 14:00  セッション 5: Tooling for Progressive Web Apps : Lighthouse and More
14:00 - 16:00  コードラボ & Mingling with Googlers
16:00 - 16:30  休憩
16:30 - 17:00  セッション 6: AMP and Progressive Web Apps
17:00 - 17:45  Q&A
17:45 - 18:00  クロージング


■申し込み方法

本イベントへの申し込み、詳細につきましてはこちらのサイトをご覧ください。
※ 参加可能な方には 9 月 11日(金)より順次参加証を送付いたします。

Posted by Takuo Suzuki - Developer Relations Team

ARCore: Android スケールの拡張現実

$
0
0
この記事は Dave Burke, VP, Android Engineering による Android Developer Blog の記事 "ARCore: Augmented reality at Android scale" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

20 億台以上の実働デバイスを持つ Android は、世界で最も大きなモバイルプラットフォームです。Google は過去 9 年間にわたり、デベロッパーの製品をあらゆるユーザーに提供するために、豊富なツール、フレームワーク、API を提供してきました。さらに本日、ARCore という新しいソフトウェア開発キット ( SDK ) のプレビューを公開します。ARCore は、既存および将来的に導入される Android スマートフォンに拡張現実の機能を提供します。開発者は、今日からすぐに ARCore SDK を試すことができます。



Google はこの 3 年間、Tango を用いてモバイル ARの基本となる技術を開発してきました。ARCore はその技術に基づいて構築されています。ARCore は特別なハードウェアなしで動作し、 Android のエコシステム全体にスケールすることができます。ARCoreは数百万台を超えるデバイスで動作する予定です。プレビュー期間中は 7.0 Nougat 以上がインストールされた Pixel および Samsung S8で動作します。高い品質と性能水準を目指し、Samsung、Huawei、LG、ASUS などの端末メーカーと協力しています。



ARCore は Java / OpenGL、Unity、Unreal Engine で動作し、次の 3 つの機能をサポートします。
  • モーショントラッキング: ARCore は、スマートフォンのカメラから検出した特徴点や IMU センサーデータを処理することでスマートフォンの位置や向きや姿勢を計測し、オブジェクトの位置を正確に配置できます
  • 水平面の検出: AR オブジェクトは床やテーブルに置くのが一般的です。 ARCore は、モーショントラッキングに使用するのと同じ特徴点を使用して水平面を検出できます
  • 光源の推測: ARCore が周囲の環境光を推測することで、開発者は周囲の環境に合わせてオブジェクトをライティングし、よりオブジェクトをリアルに見せることができます


ARCore の開発にあわせ、開発者が素晴らしい AR 体験を生み出すことができるよう、Google は開発者をサポートするアプリケーションやサービスにも力を入れています。AR アプリケーションを使って誰もが素晴らしい 3D コンテンツを簡単に作成することができるよう、BlocksTilt Brushを開発しました。また、Google I/O で発表したように、 AR体験をテーブルの上だけでなく、より広い世界スケール へと進化させるため、Visual Positioning Service(VPS)にも取り組んでいます。私たちは Web が AR の将来において重要な要素になると考えています。そこで、Web 開発者に向けたプロトタイプのブラウザもリリースします。開発者は、カスタムブラウザを使うことで AR 拡張 Web サイトを作成し、Android / ARCore および iOS / ARKit の両方で実行することができます。

ARCore は AR をあらゆるユーザーへと提供する次なる一歩です。是非、GitHubからご意見をお寄せください。また、新しい AR Experiments ショーケースをご覧いただき、ARCore の可能性を感じてみてください。#ARCore からソーシャルメディア経由で開発した製品を紹介していただければ、みなさんの優れたアイデアを Google からも共有していきます。

Posted by Hak Matsuda - Developer Relations Team

Inevitable ja Night イベントレポート「 IoT、AI、VR の未来を語るディスカッション 01」

$
0
0
6 月 12 日に開催した「Inevitable ja Night - インターネットの次にくるもの」ではさまざまなゲストを交え、Google Cloud といったテクノロジーの進化によってこの先の世界はどう変わっていくのか、VR や AR などの領域で活躍している人材をゲストに議論しました。本稿では、当日にどのような議論が行われたのかを振り返っていきます。

「IoT、AI、VR の未来を語るディスカッション」では、IoT や AI、VR を軸に新たなビジネスを切り開いているソラコム玉川憲氏、ABEJA 岡田陽介氏、InstaVR 芳賀洋行氏が登壇しました。モデレーターは及川卓也氏。今現在、お互いが関わっている領域をどう考えているのか。また、新領域に関わるであろう技術者たちが持つべきビジョンに関してディスカッションが行われました。

【スピーカー】
株式会社ソラコム代表取締役社長 玉川憲 氏
株式会社ABEJA代表取締役社長 CEO兼CTO 岡田陽介 氏
InstaVR株式会社代表取締役社長 芳賀洋行 氏

【モデレーター】
フリーランス Technical Advisor 及川卓也 氏


ソラコムのビジョンは「世界中のヒトとモノをつなげ共鳴する社会へ」


及川卓也氏(以下、及川):では、PART3「IoT、AI、VR の未来を語るディスカッション」ということで、このお三方お招きしまして、お話をしたいと思います。

私の所属ですが、ちょっと紹介しにくいんですけれども(笑)。いろんなスタートアップに技術アドバイスとかプロダクト戦略などアドバイスしております、及川と申します。元Google だったこともあり、今日この役目を依頼されたのかなと思っております。



時間もあれですので、さっそく進めていきたいと思います。まずはこのお 3 方に、5 分という短い時間なんですけれども、みなさまの事業内容や自己紹介。お話しいただくようにお願いしております。

まずは玉川さんからお願いしたいと思います。

玉川憲氏(以下、玉川):みなさん、こんにちは。ソラコムの玉川と申します。ソラコムはIoT向けの通信プラットフォームを提供している会社です。ソラコムってご存じの方はどれぐらいいらっしゃいますか?

(会場挙手)

ああ、全員ですね。ありがとうございます(笑)。

(スライドを見て)こうやって会社概要を見ていただきますと、だいたい資本金が37億円あります。日本にしてはめずらしく、非常にテックスタートアップというんでしょうか。シリコンバレー型の資金調達をガーッとして、一気に成長させるやり方をとっております。

ビジョンとしては「世界中のヒトとモノをつなげ共鳴する社会へ」でやっております。
私自身はもともと研究者、エンジニアあがりです。ソラコムを立ち上げる前は AWS のエバンジェリストをやっておりました。

趣味は技術書を書くことです。毎年こつこつと、趣味で書いております。


「エンジニアリングの力を主体とした会社を作りたい」と立ち上げた


我々はソラコム立ち上げる時に、日本発でグローバルに通用するようなプラットフォームビジネスをやりたいと言っていました。こういった強い思いを持っている。あとはイノベーションで、そしてエンジニアリングの力を主体とした会社を作りたいということで、ほぼエンジニアを集めて立ち上げた経緯があります。



我々は IoT をやっているわけですけれども。もともとの背景としては、クラウドにものすごくデータが集まってきている。そんななかで、モノ、自動車、自販機、家電、そういったところからクラウドにデータを送ろうとすると、「デバイスからクラウドへのセキュアなデータ通信がない」ことに気づいたんですね。

私自身がクラウドをやっていたので。クラウドが出てきたことによって、つまりコンピュータが民主化されてみなさんの手に渡ったことで、ものすごくイノベーティブな Web サービスが世界中で出てきました。

IoT になってそういったものを実現しようとすると「通信の民主化が必要だ」ということで、SORACOM Air というサービスを 2015 年 9 月 30 日に出しました。

これは SIM を提供してるんですけれども。ただの SIM ではなくて、モノに挿すとモバイル通信でつながって、それがクラウドに直結している。そして AWS でも Azure でも Google でも、もしくはオンプレでもインターネットでも接続できる。

つまり我々は、モノと処理基板の通信をセキュアに集中管理できるような仕組みを提供している会社です。こういった Web の上でコントロールできる。もちろん API でもコントロールできる。

おかげさまでたくさんアワードをいただきまして、今 6,000 以上のお客様にお使いいただいています。企業規模を問わず、スタートアップ、中小企業、大企業、さまざまな業界でお使いいただいています。

例えば十勝バスさん。北海道・帯広市のバス会社さんで、位置情報をクラウドにあげて、路線案内アプリを出されていたりしています。楽天 Edy さんの決済端末。楽天 Kobo スタジアムのビールの売り子さんの決済端末で使われています。

JapanTaxi さん。最近、タクシーに乗ると後部座席にタブレットがあって、動画広告が流れると思うんですけれども。そういったもので 4,000 台のタクシーで使っていただいてたり。コマツさん。スマートコンストラクションの仕組みで使っていただいていたりします。
最近発表した事例としては、ダイドーさんの自販機ですね。15 万台の自販機が今後 IoT 化されていくところで使っていただいています。それから、京成電鉄様の100以上の踏切の監視とかですね。

こういったところで SORACOM を使っていただくと、非常にスモールスタートできるということで、1 枚につき月 300 円ぐらいから使えるんですね。


ソフトウェアで実現したバーチャルキャリア


我々が IT ベンチャーがどうやってモノ向け通信を提供してるかというところなんですけれども。

非常にざっくりと仕組みをいうと、携帯通信キャリアさんの基地局だけをお借りして、そこから専用線をクラウドに引く。そのクラウドの上でテレコムのコアネットワークという、パケットの交換とか、課金システム、そういったものを全部作っている。

つまりバーチャルキャリアなんですね。基地局とクラウドを組み合わせて、ソフトウェアで我々が実現したバーチャルキャリアが SORACOM の仕組みです。

大きなパラダイムシフトを提供することができたなと思ってるんですけれども。IoT って、Internet of Things なので、モノとインターネットをつなぐということなんです。でも、我々が思っているのは、クラウドにデータをあげることになるんだと。

これが Inevitable なことでですね……。これまた噛んでしまいましたね。これ、言いにくいんですね、Inevitable。クラウドにデータをあげることは避けられないムーブメント。なので、我々はモノとクラウドを直結するパラダイムシフトを提供していることなのかなと思っています。

ソラコムのサービスは日本から始まったんですけれども。もともとグローバルなプラットフォーム事業を作りたいということで、昨年 30 億円の資金調達をしてグローバル展開を開始しまして。昨年 10 月にアメリカ、そして今年2月にヨーロッパで発売開始。この新しい SIM は 120 ヶ国で使われるようになっています。

ということで、クラウドが出てきてたくさんの Web サービスが生まれたように、我々も「SORACOM が出てきたから、IoT のソリューションサービスがいっぱい出てきた」とみなさんに言っていただけるように貢献していきたいと思っております。ご清聴ありがとうございました。

(会場拍手)

ディープラーニングのビジネスがイノベーションに直結する


及川:玉川さん、ありがとうございました。では、続きまして、岡田さんからお願いします。

岡田陽介氏(以下、岡田):はじめまして。株式会社 ABEJA の岡田と申します。本日は貴重な機会をいただいて本当にありがとうございます。

まず ABEJA という会社は、基本的には AI。とくに……この AI ってかなり一般的な言葉になってしまってるんですけど、AI という大きな枠組みの中にマシンラーニングというものがあります。そのマシンラーニングの中にディープラーニングがあるんですけれども。そのなかで我々はとくにディープラーニングに特化して事業を進めさせていただいているベンチャー企業でございます。

ちなみに、ちょっと玉川さんにやられたので私もやりたいんですけど、ABEJA を知ってたって方、ちょっと手を挙げていただけるとですね。

(会場挙手)

ああ、やっぱりソラコムさんよりは少ないですよね……。まあ、そんなかたちでございますと。



それで簡単に自己紹介なんですけど。私、ちょっと老けて見えるんですけど、実は 28 歳でございまして、しれーっと先ほど 20 代・30 代・40 代のところで、20 代でサッと手を挙げさせていただいてたんですけれども。

もともと小学校 5 年生ぐらいからずっとプログラミングをやってまして、そのあとずっとコンピュータグラフィックスをやってました。そのコンピュータグラフィックスをやっている時に、GPU ですね。だいたい今ディープラーニングと GPU ってもう切り離せないようになってくるんですけれども。そういったものをずっと触っていました。

そのなかで実際に起業してみたり、東京のベンチャー企業に来てみたり。あと、シリコンバレーに行ったりしてるんですけれども。そのシリコンバレーに行ったのがちょうと2011 〜 2012 年ぐらいなんですね。その時がちょうど、Google さんがいわゆる Google Brain Project というのをシリコンバレーでやられていました。

これを見ることはできないんですけど、「こういうのやってるそうなんだ」みたいな。こういった情報を聞いて「これはすごいことが起きたな」と思って。シリコンバレーで遊んでいてはいけないと。なので、日本に戻って起業したというのが、この会社の目的でございます。

なので、我々は本当にずっとイノベーションと向き合ってるんですけれども。当時 2011 年〜 2012 年、私の中でのイノベーションは、本当にディープラーニングみたいなところ。ディープラーニングを使ってなにかビジネスを作っていくことが、イノベーションに直結するんだろうなって思っている。そういうのをやらせていただいたりしておりました。


東大の教授と共同研究なども実施


それで今、日本とシンガポールの 2 拠点でやらせていただいておりまして。けっこうめずらしいのは、弊社もう 10 ヶ国ぐらいにメンバーがいて、かなりグローバルでダイバーシティなオーガナイゼーションになってるというかたちですね。

あと弊社の特徴的なところですね。創業当初から日本トップレベルの先生方と共同研究させていただいているのがすごく大きな強みになっております。東大の國井(尚人)先生とか。東大に初めて情報科学を作りましたという先生と一緒に共同研究もさせていただいています。

あと、弊社のめずらしいところは、先ほど GPU という言葉が出ましたけれども。最近、謎の AI 半導体メーカーでやたらとバズワードになってるいる Nvidia という会社からアジアで初めて出資をいただいております。これが非常に大きなポイントでございます。

アジア初、かつ日本初なので、基本的にフレームワークがなかったんですよね。なので、我々が第 1 事例にならざるをえなくて。そういうのをやらせていただいたりしていました。


ABEJA Platformでエコシステムを作る


そのなかで我々がなにをやっているかというと、基本的には AI みたいなものをクラウド上に突っ込んで作っている会社です。

これですね、もう IoT みたいなかたちで、玉川さん、ソラコムさんがあるおかげで、いろんなセンサーデータからどんどんいろんなデータがクラウドにあがってまいります。それをどんどん吸わせていただいて、いろんなデータを複合してビッグデータを作って、人工知能を作っていきます。

これ、我々が人工知能をエッジ側にズドンと落とすことができるのが特徴的でございまして。クラウドだとGoogleさんとか、敵わない部分が出てくるんですけれども。これはエッジ側にもデプロイできるところが非常に大きいです。

我々、これをすべて司る仕組みとして「ABEJA Platform」を持たせていただいています。
そのなかで、この ABEJA Platform をより多くの方に使っていただくためにプラットフォームのエコシステムを作っておりまして。ここに、実際にIoTのデバイスを作られている会社様やその中の通信。まあ、通信はソラコムさんに入っていただいたりですね。実際に我々の仕組みとインテグレーションしていただく会社さんなど。

あと「そもそも AI でなにしたいんでしたっけ?」をコンサルする会社さん、すでに API を持っている会社さんとも実際に連携をさせていただいています。実際にトレーニングコースもご提供していますね。

我々は、基本的にはプラットフォーム層を作っている会社のイメージになっていまして。基本的に GCP とか立ち上げてクラウドを作れる方は、クラウドを使って基本的にディープラーニングを使えるんだったらどうぞ……なんですけど。ほとんどの方はやっぱり使えないです。なので、そのプラットフォームと、実際にいろんなサービスみたいなものを持たせていただいています。

実際に小売業様とかに提供していますと、(スライドを見て)こういう映像データを送っていただければ、「こういうふうに人が来て、こういうところに滞在してました」「男性、29、28 歳が来てますよ」とかが一発でわかる。そのような仕組みをご提供させていただいています。

これが実際にビジュアライゼーションされたり、アイコンで見れたり。お客様にそれを使っていただいてるというかたちになります。

最後、駆け足になりましたけれども、以上でございます。ありがとうございます。

(会場拍手)


専門家じゃない設計士がVRを作れる環境を提供


及川:どうもありがとうございます。では、最後、芳賀さんお願いいたします。

芳賀洋行氏(以下、芳賀):世界 10,000 社が選ぶ VR アプリ制作ツールの「InstaVR」を提供しております、InstaVR の芳賀と申します。

InstaVR は、Web からの簡単な操作でインターネットの VR 体験を、iOS や Android、Gear VR、Daydream、Oculus、Viveといった、ありとあらゆる VR プラットフォームに配信できるツールを提供しています。

(スライドを見て)例えばこちら、弊社のお客様のスミソニアン博物館様になるんですが。こんなかたちで博物館の中を歩き回ったり、そこに埋め込まれたデータを見るといった体験を、スミソニアンの方の 1 人が作ってるんですね。



作成したのを App Store に出したり、Google Play で配信したり、もしくは自社の Web サイトに埋め込んで幅広く配信するといったことができるツールを提供しております。VR を使うと、ここにいてもスミソニアンを体験できるように、いつでもどこでも体験できる価値があります。

VR は、2025 年には 9.6 兆円の巨大市場に成長します。そしてその約 70 パーセントがゲーム以外の用途に使われるんですね。

ただこれ、けっこう困ってることがありまして。ものすごくお金がかかっちゃってるんですね。これを解決するには、なぜこんなことが起こっているかというと、コンピュータグラフィックスとか習得な困難な技術を持った技術者たちが時間をかけて作っちゃってるんですね。

これを InstaVR が解決して、1 分間で習得して、誰でも分単位で VR アプリを制作できるツールを提供します。

例えば、事例を出してみましょう。日建ハウジングシステム様。こちら以前から VR プレゼンを導入されていました。

こちらでは、VR 制作コスト 99.2 パーセントという劇的な削減に成功しています。今まで 2 〜 3 日かかっていたり数週間かかっていたものを分オーダーで作れる。さらに専門家じゃない設計士がVRを作れる環境を提供します。

ほかにも、弊社のお客様である国連さんから「圧倒的な習得のしやすさ」。さらには「数百時間の開発時間を節約することができます」というお声をいただいております。


誰でも VR 体験ができる……このメリットは?


InstaVR を使うと、誰でも今すぐに、体験をありとあらゆる人へ、いつでもどこでも提供できる。

「これ、なにがうれしいんですか?」というのはあるんですが、例えば海外の旅行代理店にテーマパークを売り込みたい場合。これは体験しないとわからないじゃないですか。(InstaVR だと)体験できるんですね。

(スライドを見て)例えば、弊社のお客様のサンリオエンターテイメント様ですと、このようなかたちで実際のテーマパークの体験を、ヘッドセットに詰め込んで持っていくんですね。そうすると、「なんだ、こんな感じか。これならいけるよね」を体験できたりします。こんなふうに時間と空間を超えられる。

今度は未来に行ってみましょう。例えばこれは弊社のお客様のジェットを開発されている EMBRAER という企業なんですが。こちらですと、注文前に内装などを確認して、セールスツールに使えると。弊社ではさまざまなお客様が、VRをセールス活動に活用されていたりします。

さらに人材採用もしくは訓練に関しても VR は有効です。弊社様のお客様としては USDA、アメリカの農林水産省では人材採用と訓練。海軍様だと空母の訓練に InstaVR を使って作った VR アプリを活用されていたり、そういったことにも使われます。

こちらは若干暗いんですけど、メディア体験として、シリア難民というのを実際に体験して、本当に難民問題を突き詰めて考えるものですね。こちらは CNN 様を擁する Turner 様などがご採用をいただいております。

(スライドを見て)そして VR、親和性の高そうな、このような旅行ですね。Expedia 様をはじめ、ドバイ空港やカタール空港などに、InstaVR を使ったアプリというのが導入されていたりします。

もちろん教育も。教育に関しては、スタンフォード大学様やそれから Pennsylvania University など、さまざまな大学様が実際の大学教育、もしくは幼年教育というかたちで InstaVR を採用して、さまざまな用途に活用されております。


InstaVRの海外売上比率は90パーセント以上


ますます広がる InstaVR の利用シーンというところで、これまで 1 万社・140 ヶ国にご採用いただいています。海外売上比率は 90 パーセントを超えております。売上高もマンスリーマンスリーで成長中でございまして。シリコンバレーのベンチャーキャピタルを含む複数投資家より、シリーズAの資金調達を昨年完了させてきたところでございます。

改めまして、私、芳賀と申します。最後に自己紹介です。10 歳からプログラミングをしてまして、90 年代から VR に関わっておりました。

アメリカの 3DCG 最大手の Autodesk にてソフトウェアエンジニア、GREE にてプロダクトマネージャーをしたあとに、個人で VR を作っていたら 150 万ダウンロードいっちゃいまして。こちらをもとに作ったのが、InstaVR のツールです。

会津大学でコンピュータサイエンス、あとはグロービスで MBA をとっております。本日はよろしくお願いします。

(会場拍手)

及川:ありがとうございます。みなさますばらしく時間管理ができていて、5 分で終わりました。ありがとうございます。

Twitterを見てたら質問があって。「InstaVR だけ会場に知ってる人の知名度アンケートがなかったけど」っていうのが。聞いてもいいですか?

芳賀:あ、お願いします。

及川:はい、InstaVR、ご存じの方?

(会場挙手)

芳賀:あ、けっこう知ってる。

及川:おっ、すごいですね。

芳賀:ありがとうございます。

及川:すばらしい。ということで、3 社のアンケート取れましたので、さっそく進めたいと思います。





<続きは近日公開>
次回イベント開催のお知らせ
「Inevitable ja Night - インターネットの次にくるもの Presented by Google Cloud」
第2回 AI とビジネスに起こる不可避な流れ

日時 : 11 月 14 日 (火) 19 : 00 - 21 : 00
定員 : 200名
主催 : グーグル合同会社

Posted by Takuo Suzuki - Developer Relations Team

Slides API コードラボのご紹介

$
0
0
この記事は G Suite デベロッパー プラットフォーム エンジニア、Timmerman(@granttimmerman)による Google Apps Developer Blog の記事 "Introducing the Slides API Codelab" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年秋、Google Slides API がリリースされました。それ以来、パートナーやデベロッパーなどの皆さんは、プログラムからスライドを生成するアプリやツールを作っています。そういったスライドは、有名な md2googleslidesのように PC でもモバイルでも動作しています。

最近リリースされた Slides API コードラボでは、Google の BigQuery と Slide API を使って 350 万のレポジトリを分析し、「トップ 10 OSS ライセンス」プレゼンテーションを作成する例を取り上げ、順を追って説明しています。これは、Slides API を学習するにはまたとない題材です。特に、ビッグデータ、プレゼンテーションの自動作成、オープンソースに興味がある方におすすめです。
Slides API コードラボのプレビュー

Slides API コードラボ スタートガイド 

コードラボを使ってみるには、レポジトリをクローンします。最初にスクリプトを実行すると、いくつかのステップに分けてプレゼンテーションを作成することがわかります。startディレクトリでサンプルアプリを実行すると、次のような「TODO」が表示されます。
-- Start generating slides. --
TODO: Get Client Secrets
TODO: Authorize
TODO: Get Data from BigQuery
TODO: Create Slides
TODO: Open Slides
-- Finished generating slides. --

GitHub 情報のクエリには、BigQueryですでに公開されているパブリック データセットを使います。BigQuery を使うと、Google のインフラにある大量のデータセットに対して数秒でクエリを実行することができます。BigQuery のパブリック データセットの利用や、独自のデータセットのアップロードは、bigquery.cloud.google.comから行うことができます。このコードラボではオープンソース ライセンスに注目しているので、GitHub のパブリック レポジトリのクエリを実行し、そのライセンスを取得します。
WITH AllLicenses AS (
SELECT * FROM `bigquery-public-data.github_repos.licenses`
)
SELECT
license,
COUNT(*) AS count,
ROUND((COUNT(*) / (SELECT COUNT(*) FROM AllLicenses)) * 100, 2) AS percent
FROM `bigquery-public-data.github_repos.licenses`
GROUP BY license
ORDER BY count DESC
LIMIT 10
GitHub オープンソース ライセンス クエリ
パブリックやプライベートなデータセットは無限にあります。BigQuery でどのようなデータを分析できるか、Google Slides API を使ってどのようなプレゼンテーションを自動生成できるかを想像してみてください。Slides API コードラボの目的は、その両方をすばやく学んでいただくことです。Slides API やこのコードラボに関する問題点、質問は、GitHubまたは Stack Overflowでお尋ねください。

皆さんのアプリのリリースを楽しみにしています。


Reviewed by Eiji Kitamura - Developer Relations Team

Inevitable ja Night イベントレポート「 IoT、AI、VRの未来を語るディスカッション02」

$
0
0
6 月 12 日に開催した「Inevitable ja Night - インターネットの次にくるもの」ではさまざまなゲストを交え、Google Cloud といったテクノロジーの進化によってこの先の世界はどう変わっていくのか、VRやARなどの領域で活躍している人材をゲストに議論しました。本記事は、「IoT、AI、VRの未来を語るディスカッション」でのソラコム玉川憲氏、ABEJA岡田陽介氏、InstaVR芳賀洋行氏とモデレーターの及川卓也氏のセッション記事の第二弾になります。

【スピーカー】
株式会社ソラコム代表取締役社長 玉川憲 氏
株式会社 ABEJA代表取締役社長 CEO 兼 CTO 岡田陽介 氏
InstaVR株式会社代表取締役社長 芳賀洋行 氏

【モデレーター】
フリーランス Technical Advisor 及川卓也 氏


個人より商業向け AI を発展させたい


及川卓也氏(以下、及川):事前にちょっと話してた時に、もう少し起業家に向けてのメッセージにしようかなと思ったんですが。セッションタイトルを改めて見たら「IoT、AI、VR の未来」となっているので、やっぱりちょっと技術者が技術を語るほうがおもしろいということで。そちらの話をいろいろさせていただきたいと思います。

改めてこの IoT、AI、VR について、みなさんにお聞きしたいんですけれども。みなさんはそれぞれ VR 代表、AI 代表、IoT 代表というかたちで出ているので、自分の代表以外のところに対して、どう思っているか。コメントしていっていただきたいなと思うんですけれども。

まずは IoT 代表で(壇上の)右側にいらっしゃるので、……みなさんから見て左ですね。玉川さん、しゃべりたいかもしれないですけど、ちょっと待っていただき。残りの 2 人が、IoT といわれているものに対してどう思っているか、今の自社の事業との絡みはどういうところにあるか。IoT に技術に対して話してほしいんですけれども。どうぞ。

岡田陽介氏(以下、岡田):そうですね、AI から見た IoT なんですけれども。やっぱり AI、とくにディープラーニングをやる上ではもう IoT 必須になってきています。

なぜかというと、今までは人がキーボードをカチカチ打ってデータ入力をして、それを AI に覚えさせるんですけど。そうするとたぶんどんなにタイピングが速い人でも、1 秒間に 5 文字ぐらい打ったら「すごいよね」みたいな感じだと思うんですよね。



IoT ですと、例えば 20 ヘルツとか 30 ヘルツみたいなデータでいくと、1 秒間に 20 〜 30 回というデータが簡単に生成されてあがるようになってくる。これは、やっぱり AI にとって革命。

そうするとデータ量が爆発的に増え始めるので、AI が学習する、賢くする上で一番重要な学習ベースになりえる。そういったところが IoT と AI が密接に関わってる一番大きいところかなと思っています。

及川:なるほど。そのデータを収集するための IoT という切り口ですよね。

もう 1 つ、ちょっと聞きたいんですけれど。今回は Google I/O で、Android にのるTensorFlow Lite というのが出てきて、IoT 側でもエッジコンピュータとして機能するものがあるじゃないですか。それについてはどう思われますか?

岡田:それも非常に我々としてはありだなと思ってまして。いわゆるスマホの中で動く AI はもちろんあると思うんですけど、我々が目指しているのはどちらかというと工場で動く AI とか小売店舗の中で動く AI を目指していたりします。

これはなにが違うかというと、普通のスマホって使うときだけ AI を動かせばよかったりするんです。でも、工場とか小売店って 24 時間 365 日起動してくれなきゃ困るわけですよね。

そうすると、スマホ 1 個だと信頼性が低い。そこに対して、エッジ側と呼ばせていただいているんですけれども、そこに AI を置かせていただく。言ってることはまったく一緒なんですけど、プロセスが違う。

スマホ側はもちろん Google さんがやっちゃうので、我々がやらないところにいこうと。そこで、エッジ側というかたちで店舗だったり工場だったり街だったり、そういうところに AI に適用していきたいイメージですね。

及川:なるほど。ちょっと誘導尋問みたいになっちゃったんですけれども。データ収集、コレクターとして、もしくは実際にそこで演算、AI をやっていくところの両面で IoT に期待しているってことですね。

岡田:はい。


来年に向けて「使い物になる」テクノロジーが出ようとしている


及川:わかりました。じゃあ次、芳賀さん。VR の切り口から IoT を見て。

芳賀洋行氏(以下、芳賀):ありがとうございます。僕、IoT はくわしくなくてですね。今日のプレゼンを聞いて非常によくて。

うちのお客さんでも、工場とかで使われている VR って、ライブのストリーミングビューアーみたいな感じになってきていて。実際にそこに指示を出したりというのも出てくると思うのです。

そうすると、「この機械の調子がどうなっているか」とか、そういう情報をあげるのもそうですし。実際に、いわゆる 360 度カメラを使ってデータをあげるという。ちょっとでかい通信になっちゃうと思うんですけど。それもそんなに……通信量が上げればできると思うので。非常に期待しているところです。

及川:わかりました。今のお 2 人の話を聞いて、もう 1 つ質問したかったんですけど。
IoT 代表で玉川さんに出ていただいているんですけれども、IoT そのものじゃないですよね。IoT を広めるための通信というところじゃないですか。なので、その立場から見ても今後、IoT に対してどう思われるか。あと、2 人の今のご意見を聞いてどう思われるかをお話ししていただいていいですか?

玉川憲氏(以下、玉川):そうですね。IoT の技術といったときに、本当にまだまだ発展途上だなと思っていて。とくに昨年の終わりぐらいから Google Cloud さんをはじめ、ほかのクラウドベンダーを見てても、IoT 系のサービスがダダダーって出てきてるんですね。
まさにここから、今年、そして来年はテクノロジーとしても、IoT におけるモノ向けのクラウドがどうなっていくか。ここがまさに進化していくところなので。

それこそ AI、それから VR というプレイヤーのみなさまから、きちっと使い物になるようなIoTのテクノロジーがまさに出ようとしているところだと思うのです。私自身もプレイヤーとしてどんどんそういったすばらしいテクノロジー・プラットフォームを提供していきたいなと思っています。


人間が発見できなかった最適解をテクノロジーが発見していく


及川:なるほど、わかりました。たぶんここも深掘りしようと思ったら、もっとたくさんしたいと思うんですが。とりあえず次の AI のほうに移ります。

AI 代表である岡田さんは聞き役にいったん回っていただいて、同じように、IoT 側として AI に対して期待するものだとか、あとは今の自社の事業でどういう絡みがありそうかを教えていただいていいですか。

玉川:クラウドが出てきて、クラウド・AI がすごい進んでるなと思ってるんですけど、本当にここから先、なにかすごくおもしろいことが起きるんだろうなと思っていて。



あれですね、AlphaGo なんかは本当に象徴的で。AlphaGo の結果では、50 回分ぐらいの対戦が見せられたんですよね。あれを見た時の専門家の反応が「なんでこうなるかはわからないけど、強い」という感じなんですね。

つまり「人間には理解できないんだけれども、こっちのほうがいい」というような事象が今後いっぱい出てくる。それって「飛行機が飛んでるけど、なんでかわからない」みたいな、なんかそういうことが出てきてるわけです。

ここが進化してくると、もちろん「なんかよくわからないことが起こって怖い」という警戒心なんかもあるかもしれないんですけれども。どんどん人間が発見できなかったような最適解を、ディープラーニング、それから AI が発見していく世の中になってくる。なので、僕は非常に楽しみに思っています。


データをあげれば「これ使えるじゃん!」が出てくる感じ


及川:ソラコムの事業の中で AI を活用している、もしくは活用する可能性はありますか?
玉川:我々は通信部分を提供している会社ですので、今後は……実際は今までもパートナーエコシステムというかたちで、ABEJA さんをはじめ、みなさまとパートナリングさせていただいてるというところがまずあります。

それからソラコム自身がいわゆる通信のセキュアな通信部分を提供しているので、この通信の部分において、今はちょっとくわしくは言えないんですけれども、そういったテクノロジーを適用できるスペースはいっぱいあるなと思っています。

及川:たぶんなにかありますね(笑)。

玉川:はい。

及川:わかりました。だいたい想像つきます。では AI に対して、芳賀さん。

芳賀:すばらしいと思っています。というのは、VR、ヘッドトラッキングのデータなどは弊社も蓄積していまして。こういったものから「どういったものをよく見てるのか」とか、非常に使わせていただきたいですし。



あと、僕はけっこう AI は素人でして。本当に Google さんで検索して一番上に出てきた API を使うみたいな感じで出して「これ使えるじゃん」といって、どんどんデータをあげれば答えが返ってくる感じになってくれるのを心待ちにしております。

というか、もうそんな感じなんですよね。合ってます?

及川:合ってます。

芳賀:合ってますよね。


AI に関する技術はどこまで必要?


及川:これは、先ほど控え室でも話したんですけど、今深掘りしたいなと思ってて。そこらへんから岡田さんに話していただきたいんですけれど。

1 つは今、芳賀さんが言われていたように、Google をはじめ、いろんなところがコグニティブなカタチで API を出しているので、「これを使えばいいじゃん」というところを使っていく。本当に API 利用者という立場。

一方で、いろんなアルゴリズムなりライブラリがあります。これを使う。両方そうなんですけれど、これはけっこう職人的なものが必要じゃないですか。そのパラメーターをどう与えるのか。特徴量の抽出をどうするのか。いろいろあったりします。さらにもっと深いところになると、本当にその部分の研究まで入ってくるところがあるんですよね。

岡田さんの会社はどうアプローチされているのか。AI に対してどう取り組むかを考えている技術者や企業に対して、なにかメッセージがあれば。

岡田:そういった意味ですと、我々の会社は一番上から一番下まで全部やっていますという流れになっています。

基本的には基礎アルゴリズムの開発です。いわゆる、誰も今まで知らなかった AI を研究ベースで作り込むところもやらせていただいていますし、逆に対小売業向けには、完全に誰でも使えるスマホアプリというものもあります。ここまですべてバーティカルでやらせていただいているんですね。

そのなかでよくやらせていただいているのは、プラットフォームの部分です。どうしてかというと、先ほど簡単に話しましたが、Google さんのいわゆる GCP のインスタンス立ち上げ、そこで TensorFlow を使って自分たちでこねこねできる方はそれでいいと思うんです。ただ、そういった方は、ほとんどの業種でそういうことができないと思っているんですよね。

逆に、コグニティブサービスのようなカタチで、完全に「API を叩くだけ」というのは、画像認識問題に関してはけっこう簡単にできたりします。ただ、ほとんどが使えないんですよね。ここでコグニティブサービスを延々と提供していくのは、やっぱり無理なんです。ちょうどその中間にある部分が必要なはずなんですよ。

なので「ここまでカスタマイズしなくていいけど、ちょっとやりたいよね」と、かゆいところに手が届く感じ。ゼロからオンプレで触るのか、AWS を使うのか……言っちゃいましたね。あとは GCP を使うのか。その感覚かなと思っています。
そういう意味だと、我々はAI業界における GCP や AWS といったものを使っていきたいとすごく思っている感じですね。


通信速度が今より速くなったときの展開


及川:わかりました。ちょっと ABEJA の例から外れるのですが。もしかしたら3人にお聞きしてもいいかもしれないんですけれど、やっぱりコグニティブ系サービスを使うのは、めちゃくちゃ簡単じゃないですか。

例えば、画像認識で顔の detection をして、怒ってるのか笑っているのかとかってけっこうな精度でわかったり。先ほどの ABEJA さんでもあったみたいに、性別や年齢はけっこうわかるんです。

それって、いったん画像をアップロードしてストレージに情報を入れるというところがありますよね。静止画ならいいけれども、最近はそれをビデオで Google でもできるようになってるんですよね。そうすると、その大量のものを処理するのかって、時間だったりコストだったりがトレードオフが入ってきて難しくなるなって思うんです。

結局、これにも答えないかもしれないですが。もし自分たちが同じような選択をしなきゃいけない CTO だったとき、どういった適切な技術の選択をされますか? じゃあどうしよう、回答できる人から。

芳賀:一番画像を送ってそうな僕から。初めはすごく軽い気持ちでカジュアルに API を叩いて、動画とかも、めちゃめちゃでかくて長いやつを送っちゃたりしてますよね。



そこで「こんなもんなんだ」と知った上で、モデルとかの特性、それをある程度は理解して「これはこんなコストの上がり方するんだよね」と理解して、「うちで作らないほうがいいよね」となって。うちが作ったらいくらかかるか、だいたいそいったクラウドサービスで見て、「ああ、これはだいたいこのぐらい金額感になるんじゃないか」と予想で入れたりしますね。答えになってますかね?

及川:ほかのお 2 人、なにかアドバイスありますか?

岡田:そういった意味だと、ボトルネックは通信なので。その通信の前になにをするか。あとにするか。それを最初に選ぶのが重要かなと思いました。

逆に言うと、通信線が光ファイバーだったら動画も送れちゃうんですよね。光ファイバーが定常的に入っているようなところなら、それで OK だったりします。ただ、まだ IoT では、LTE や 3G 回線だと遅かったりします。そうなると、データを送るのはつらいよね、といってやめてしまう。

最近よくあるのは、メインの通信は光ファイバー。でもコントロールだけでいわゆる SIM カードを使うということがけっこうあったりしますね。そういった組み合わせを適切な場所に応じて選んでいくカタチかなと思っていますね。一応、我々はすべて提供しています。

及川:なるほど。ちょうどいい流れになったんですけど、やっぱりそこの通信のところという話で、ソラコムもまさにそこをやってると思うんですね。

そうすると今後は AI 的なものが出てきたときに、データの量……。量というのはサイズもそうですし、回数という、頻度というのもどんどん増えてくると思うんですね。そこはどう将来的に技術が発展するか、事業としてどう展開を考えているかだったり。

玉川:通信という観点で見たときに、1 本の線がものすごく速いという話と、あらゆるデバイスがつながるというのと、両方の次元の話があると思うんですね。

我々が今とくに取り組んでいるのは、自動販売機といったもの。それから家電やセンサー、メーターなど、今まで通信でつながれなかったものに対してもっと広げていきたい。どちらかというと、あらゆるものに通信を与える方向で今一生懸命やっています。

一方で Inevitable な流れとしては、通信回線はどんどん速くなり、どんどん安くなっています。結果的に見ても、それが手頃な値段になってくるのはもう避けられない動きです。それを我々も見据えながら、できるだけ手頃な、そして使いやすいカタチで提供していきたいと考えています。


VRで再現すべきは「本質」


及川:なるほど。わかりました。では、最後に VR についてなんですけれども。ちょっと芳賀さんは最初は聞き役になっていただいて、玉川さんと岡田さんに VR というものに関してどんなかたちで将来を考えているか。同じことの繰り返しですけども、今の事業との絡みではなにがあるかを教えてください。

玉川:芳賀さんのプレゼンを初めに見させてもらった時に……僕はもともと 1998 年ぐらいに大学院の研究で VR やってたんですね。なので、ものすごく感慨深いものがあって。
当時、VR をやろうとすると、SGI の Onyx という数千万のマシンを買って、あれをグリグリとやってたわけですが。それがもう本当に民主化されたなと非常に感慨深く思ってまして。すばらしいことだなと思っています。

実はバーチャルリアリティって、先ほど「人工現実感」という日本語が出てたんですけれども。もしくは日本語だと「仮想現実感」という言葉のほうが多いんですよね。



僕、それは間違ってるなと思っていて。バーチャルリアリティの「Virtual」って、英語だと「本質」という意味なんですよね。「なにが本質ですか。その十分な本質を届けられていますか?」がバーチャルリアリティだと思っているので。

それぞれのユースケースにおいて、本質って違うと思うんですよ。だから今、InstaVR さんが提供されている仕組みってすばらしいなと思っていて。あそこにおける本質が表現されていれば、十分にものすごく有用なものとして使えるってことなんだなと思っているんです。

そうなると、今後 VR はどんどんリアルになってくるので、本質が伝えられる領域がどんどん広まってくる。

僕はぜひ実現してほしいなと思っているのが、最近グローバル化しての悩みが「海外出張がしんどい」というものがあります。時差がつらいので、もう本当に私自身の availability zone(クラウドにおけるグローバルのデータセンター拠点)が世界中にあるみたいなかたちにしてほしいなと思っています。

及川:なんか VR とは違う「バーチャルなんとか」かもしれないですね。

玉川:現実感というか、そこに。まあ、テレイグジスタンスみたいなところですかね。


人の視点ではなく「AI の視点で見る VR」


及川:なるほど。わかりました。岡田さん、お願いします。

岡田:まず、私も個人的にもともとコンピュータグラフィックスをやっていた人なので。
私は当時 2008 〜 2009 年くらいに NVIDIA の Quadro を突っ込んで、Autodesk の Maya と RenderMan をゴリゴリ動かしてやるという、……けっこうすごいマニアックな話になっちゃうんですけど。そういったことをやっていたんです(笑)。

そういった意味で、我々が AI や VR に対して思っているのは……。AI を使うときに一番苦労するのは、教師データと呼ばれる、人間のこれまでの知見を集めていく作業が難しかったりするんですよね。

例えば、製造業などもそうなんですが、最終的になにか検品して物を出す時、すごい職人さんがいるんですよね。「どこを見ているんですか?」みたいなものです。なぜか「これはダメ」「これは OK」といった、独特の感覚がすごく多くて。そういったものを VR を使って効果的に学習していくことができるのかなと思っています。

それを一部 AI 化するのは 1 つあると思うんですけれど。そういったものを AI 化しないという話もあります。AI 化してしまった場合、「もう知らないです」という話になっちゃうと非常にまずいことが起きてしまうので。そこは人と、その AI をハイブリッドにして体験する。AIの視点になって、人間が物事を扱う感じですね。そういったことが実現できるかなと思っているんです。

我々としては、このあたりにすごくポテンシャルを感じています。

今までは人の視点を見る VR だったんですけど、逆に言うと私たちは AI の視点で見る VR みたいなところに関して、……それこそゲームチェンジが起こるかなと思っています。


VR デバイスがまだまだ民主的じゃない現実


及川:その話、すごくおもしろいなと思いました。そのいわゆる職人の技を AI 化していくのは……。実は先ほど前のセッションでもあったんですけど、AI って今、第3次ブームって言われているんです。第 2 次ブームの時にちょうど私、社会人になった頃だったんですよ。もうなくなっちゃった、DEC というコンピュータの歴史のはるか彼方に行っちゃった会社があるんですけれども。そこが AI 技術にすごく力を入れていて。

当時は主に推論エンジンなんですよね。そうすると、いわゆる匠の技、職人の技にヒアリングをかけて聞き出してというナレッジエンジニアというタイトルがあり、それを推論エンジン用の言語に置き換えていくことが、AI 化されていったんですよ。

よくあったのが、鉄道のダイヤ。あれって組むのが難しいんです。そこで、すべて自動化するところに使ったんですね。ただ、その時はすべて機械化するというところで終わっちゃったんです。

今の岡田さんの視点はおもしろくて。人にもちゃんと継承していかなきゃいけないところに VR 技術を混ぜてみたほうがいいんじゃないかって話なんですよね。これはとてもおもしろい切り口だなと今、聞いてて思いました。感想ですけど。

今のこの2人の話を受けて、VR の民主化は非常に意味があると思っているし。あと、最初のセッションでも「VR というのは体験の共有だ」と言っているところはまさにそうだと思うわけですね。

ただ、民主化と言ったときに、InstaVR はクリエイター側のほうの民主化をどんどん進めてると思うんですけれども。一方で VR デバイスがまだまだ民主的じゃないっていう現実があったりすると思うんですね。

なので、そこに対してはどう考えるかもちょっと踏まえて、今のお2人のお考え・印象とかに対してご意見あればと思います。

芳賀:ありがとうございます。お 2 人の話で、僕も Onyx 使ってまして。その時に感動した Autodesk の Maya の開発がしたくて Autodesk に入ってですね。実際に Autodesk の Maya の開発してて、非常に感動しております。……わかる人しかわからない話ですね(笑)。


職人芸も VR で本質を捉えられるようにしたい


先ほどのお話を本質的に捉えていて、例えば事業継承や経験の継承では本当に必要だと思っています。高精細の 360 度カメラを作っていくことはできるんです。でも、それでどういった本質がそこに入っているのかを抜かないと、無駄な通信が発生するだけなんですよね。そういったものをぜひやっていただきたいなと思います。

弊社のお客様だと、観覧車を止める訓練を VR でやっている人たちがいるんです。あれ、手で止めていたりするんですよ。危ないと思うんですけど、それが職人芸だったりする。そういったものを意味づけして本質を捉えられるようになっているといいかと思います。
デバイスの供給量ですよね。

まずヘッドセットがありますよね。ヘッドセットに、例えばモバイル端末をつける。ヘッドセットとモバイル端末にデータの通信として 5G が来る。デバイスのほうに H.265 とか HEVC あたりの動画コーデックが入ってくる。そのコーデックをクラウド上で編集できる状態になっている。

それを落としてもつまらないだけの状況になっているのがあった上で、さらにクライアントで快適に動かして、そこのたまったヘッドセットデータのトラッキングデータを、もしかしたらクライアントで処理してからあげてもいいですし。そのままあげるかもしれないですけど。その一連のことができるようになるのは、そんな遠い未来じゃないと思いますね。2020 年ぐらいにはいけると思うので。

今年の終わりぐらいからには、ヘッドセットもある程度「こういうの作ればいいんだ」がわかってきているので。あとはもう時間の問題。それこそInevitableな流れになっていると思います。



<続きは近日公開>
次回イベント開催のお知らせ
「Inevitable ja Night - インターネットの次にくるもの Presented by Google Cloud」
第2回 AI とビジネスに起こる不可避な流れ
日時 : 11 月 14 日 (火) 19 : 00 - 21 : 00
定員 : 200名
主催 : グーグル合同会社


Posted by Takuo Suzuki - Developer Relations Team

Chrome 61 ベータ版:JavaScript モジュール、デスクトップ版 Payment Request API、Web Share API、WebUSB

$
0
0
この記事は「型破りなモジュール使い」、Domenic Denicola による Chromium Blog の記事 "Chrome 61 Beta: JavaScript modules, Payment Request API on desktop, Web Share API, and WebUSB " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 
 
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、Mac、Windows 向けの最新の Chrome ベータ版に適用されます。  
 
JavaScript モジュール 
 
モジュールを使うと、スクリプトの依存性を宣言できます。サードパーティ製ビルドツールでは、必須スクリプトのみをバンドルするためにモジュールを使用するのがすでに一般的です。 今回のリリースでは、JavaScript モジュールが新しい <script type=module>要素でネイティブ サポートされます。 ネイティブ サポートとは、ビルドのステップを経ずに、ブラウザが細かい単位で依存性を並列に取得し、キャッシュを活用してページ間の重複を防ぎ、正しい順序でのスクリプトの実行が保証されることを意味します。  
 
導入にあたっては、JavaScript モジュールの詳細や、モジュールの影響を受ける JavaScript 言語の機能について確認してください。  
 
デスクトップ版 Payment Request API 
 
昨年サポートが発表された Android 版に続き、Windows、Mac、Linux、ChromeOS でも Payment Request APIが利用できるようになります。デベロッパーは、プラットフォームを問わず安全でシームレスな購入手続きを提供できます。導入にあたっては、統合ガイドをご確認ください。  
 
トランザクション全体における PaymentRequest プロセス

 
Web Share API 
 
ユーザーがソーシャル ネットワークで簡単にコンテンツを共有できるようにするには、各ソーシャル サービス用の共有ボタンを手動でサイトに組み込む必要があります。そのため、ユーザーが実際に使っているサービスで共有できないことも多く、ページサイズの肥大化やサードパーティ製コードを含めることによるセキュリティ リスクも発生しています。  
 
Chrome for Android では、新しく navigator.share API が利用できるようになっています。これは、Android ネイティブの共有ダイアログを呼び出すことにより、インストールされている任意のネイティブ アプリで簡単にテキストやリンクを共有できるようにするものです。今後のリリースでは、インストールされているウェブアプリとの共有もできるようになる予定です。  
 
navigator.share API を使うと、Android ネイティブの共有ダイアログ経由でさまざまなネイティブ アプリとコンテンツの共有が可能

 
WebUSB 
 
高レベルのウェブ プラットフォーム API は、キーボード、マウス、プリンター、ゲームパッドなど、ほとんどのハードウェア機器をサポートしています。しかし、特殊な教育、科学、産業用の USB 機器を使う場合は、安全ではない可能性があるドライバやソフトウェアを検索してシステムレベルの権限を使ってインストールする必要があります。  
 
今回、Chrome で WebUSB APIがサポートされました。これにより、ユーザーの同意を得た上で、ウェブアプリが機器と通信できるようになります。各デバイスが提供するすべての機能を利用できますが、ウェブのセキュリティが保証される点は変わりません。  
 
今回のリリースに追加されたその他の機能 
 
  • Android に加えて、PC でも Network Information APIが利用できるようになりました。これを使うと、サイトから基盤となる端末の接続情報にアクセスできます。 
  • 既存の Scroll APIの新しいオプション パラメータ、または scroll-behaviorCSS プロパティを使って、スムーズなスクロールを指定できるようになりました。 
  • プラットフォームで、CSSOM View Smooth Scroll APIを使ってスムーズなネイティブ スクロールを実現できます。これには、scroll-behavior: smooth CSS プロパティまたは window.scrollTo() DOM スクロール メソッドを利用します。JavaScript でこの動作を実装する必要はなくなります。 
  • CSS の色の値は、8 桁および 4 桁の 16 進数を使って #RRGGBBAAおよび #RGBAという形式で指定するようになります。 
  • Visual Viewport APIによって、サイトから相対位置で画面の内容にアクセスできるようになりました。これを使うと、ピンチしてズームなどの複雑な機能を直接的な方法で実現できます。 
  • Device RAM APIを利用できるようになりました。サイトからユーザーの端末の RAM の量を参照できるようになるため、ウェブ アプリケーションの全体的なパフォーマンスを最適化できます。 
  • インストールされたウェブアプリを操作して最初のウェブアプリのスコープ外のサイトに移動する場合、新しいサイトが自動的にカスタム Chrome タブで読み込まれるようになりました。 
  • ネイティブ コントロールを利用している動画の再生中に、ユーザーが動画と一致する向きに端末を回転すると、Chrome が自動的に動画を全画面に拡大するようになりました。 
  • nextHopProtocolResource Timingおよび Navigation Timingで利用できるようになりました。これにより、リソースの取得に利用するネットワーク プロトコルにアクセスできるようになります。 
  • サイトでサードパーティ製埋め込みコンテンツにコンテンツ セキュリティ ポリシーを強制できるようになりました。これには、<iframe>要素に新しく追加された csp属性を使用します。 
  • DOMTokenListインターフェースで replace()がサポートされました。これにより、すべての同じトークンを簡単に新しいものに変更できます。たとえば、有効期限が切れた際に、activeinactiveに変更できます。 
  • 要素の attribute名のリストにアクセスする getAttributeNames()がサポートされました。これにより、attributesコレクションに対して反復処理を行うよりも直接的な仕組みが提供されます。 
  • セキュリティ強化のため、JavaScript ダイアログが開いた際に自動的に全画面を終了するようになります。 
  • サイトから、指定されたオリジンや quota で使用されるディスク スペースの大まかなバイト数にアクセスできるようになりました。これには、Storage APIに新しく追加された navigator.storage.estimate()関数を使用します。 
  • ブラウザのキャッシュ ヒット率を上げるために、URLSearchParamssort()がサポートされました。これは、格納されているすべての名前と値のペアを並び替えて出力します。 
  • URLSearchParamsのコンストラクタが更新され、他の URLSearchParamsインスタンスだけではなく、任意のオブジェクトをパラメータとして渡せるようになりました。 
  • 誤って発行された証明書を気づかずに使ってしまうことがないように、サイトで新しい Expect-CTHTTP ヘッダーが使われるようになりました。これによって、レポートの自動化や Certificate Transparency 要件の強制が可能になります。 
  • Chrome のバックグラウンド タブで、Media Source による動画フレームのデコードが行われなくなりました。 
  • ImageCapture.getPhotoSettings()で、写真の解像度、赤目軽減、フラッシュ モードなどの「ライブでない」カメラ設定を取得できるようになります。
  • サイトは Clear-Site-Dataヘッダーを使って cookie や service worker、キャッシュエントリなどのクライアントサイドデータを削除できるようになります。

 
サポートの終了と相互運用性の改善  
 
  • セキュリティ強化のため、URL に \n<の両方の文字が含まれるリソースはブロックされるようになります。 
  • セキュリティ強化のため、安全でないコンテキストで Presentation APIstart関数がサポートされなくなり、削除されました。 
  • on<event>属性間の一貫性を向上させるため、onwheel属性が Elementから WindowDocumentHTMLElementSVGElementに移動します。 
  • 仕様に準拠し、さらに細かい参照コンテンツのフロー制御を実現するため、Chrome で 3 つの新しい Referrer Policy値である same-originstrict-originstrict-origin-when-cross-originがサポートされました。 
  • 仕様の変更に従い、colSpanの最大値が 8190 から 1000 に下がりました。

 
Reviewed by Eiji Kitamura - Developer Relations Team
Viewing all 2204 articles
Browse latest View live