概要

メルカリは C2C E コマースのアプリを提供しており、月間アクティブ ユーザー（MAU）1500 万人を超えるお客様にご利用いただいています。メルカリアプリでは、さまざまな機械学習を使用した機能を提供しています。


本記事では、TensorFlow Lite を使用し、機械学習モデルの計算をモバイル端末上で行っている機能についてご紹介します。

図 1 メルカリロゴ



メルカリアプリでは、お客様に商品を出品していただくという特性上、出品商品のタイトルや詳細情報をお客様に記入していただく必要があります。この入力作業は、初めて出品されるお客様や多くの商品を出品されるお客様にとって、面倒に感じられることがあります。そこでメルカリでは、本や DVD などのエンタメ カテゴリやコスメカテゴリの商品に対して、バーコード出品という機能を提供しています。

これは、バーコードを読み取ることで、タイトルや商品詳細が自動で入力され、出品時の手間を大幅に軽減することができます。さらにこの機能をご利用いただくことで、お客様の出品されたアイテムと、メルカリが持つカタログデータと紐づくことで、検索などを改善することができます。

バーコード出品は、すでに多くのお客様にご利用いただいていますが、さらに多くのお客様にご利用いただきたいと考えています。特に新規のお客様や、バーコード出品をご存じないお客様にも、自然にバーコード出品をご利用いただくために、メルカリの AI チームでは、バーコード出品をサジェストする機能を開発しました。これは、お客様が商品を撮影した際に、その商品が、本や DVD と判断されたら、すぐさまバーコード出品のサジェストをする、というものです。

この機能の中では、TensorFlow を使用して構築した Deep Learning モデルを組み込み、TensorFlow lite によって、モバイル端末上で推論しています。

モデルの構築

今回実装する機能は、撮影された画像が本かどうかを推定する画像分類タスクとなるので、CNN を使用したモデルを利用しました。モデルの評価基準として、分類精度はもちろんですが、モバイル端末に組み込むため、モデルサイズと UX を損なわないために、推論速度も重要となります。

これらの条件を最も満たす Mobilenet v3 を選択しました。データセットとして、メルカリの出品画像数 100 万枚をラベル付けしたデータセットを使用します。学習は、ImageNet で学習したモデルをベースに、メルカリのデータで FineTuning をします。

TensorFlow を使用してモデルを構築し、GCP 上の TPU を利用することで、大きなバッチサイズで高速に学習することが可能になり、多くの検証をすることができました。TensorFlow では、Estimator を使うことで CPU/GPU/TPU の切り替えを容易に行うことができます。

モデルの最適化

端末にモデルをダウンロードするので、モデルの重みを int8 に量子化することで、モデルのファイル サイズを削減することを考えます。その際、通常通り学習したモデルを量子化すると 32bit の float の重みを無理に 8bit に落とし込むため、精度が下がってしまうことがあります。

Mobilenet v3 を、通常通りメルカリのデータセットで学習したモデルを量子化した場合、Accuracy が、5% ポイントほど下がってしまいました。

そのため、モデル構造をチューニングするとともに、量子化されることを前提にモデルを学習する quantization-aware training をします。さらに ExponentialMovingAverage の導入、MobileNetv3 のモデルに depthwise convolution を追加するといったモデルのチューニングを行いました。ただし、モデルをチューニングする際に、モデルのファイル サイズと推論速度が目標値に収まるように注意しなくてはいけません。

最終的には、モデルのチューニングの結果精度が 6% ポイントほど向上し、quantization-aware training を導入することで、量子化後も精度を落とすことなく、モデルのサイズを 75% 以上削減することができました。



図 2 モデルチューニング結果

モバイルアプリへの組み込み

メルカリアプリは Android、iOS 両方で提供されているため、クロス プラットフォームのサポートが必要になります。TensorFlow Lite の C++ API を使い、抽象化レイヤを作ることで、Android、iOS の両方で簡単にモデルの推論を呼び出すことができます。

作成した画像分類モデルを組み込んで、バーコード出品のサジェスト機能を作成しました。最初に作成したデザインを図 3 に示します。

バーコード出品機能を利用せずに本や DVD を撮影した場合、動画のようにバーコード出品をサジェストするポップアップが表示されます。このポップアップをタップすることで、バーコード出品の画面に移動することができるようになっています。

この画面は、ユーザーが出品商品の撮影をしている画面であり、ユーザーは続けて写真をとったりタイトルの入力など、次の動作を考えているはずです。そのため、この写真の撮影途中で数秒間待たされたりすると、UX を大きく損なうことが予想されます。画像をサーバーに送信して推論結果を取得すると、通信状況にもよりますが、1 秒以上かかることも少なくありません。それに対し、TensorFlow Lite を使用して端末上で推論すると、安定して 30ms 程度で推論することができます。そのため、動画のように UX を損なわなず、自然なサジェストをすることができます。




図 3 初期デザイン


結果分析と改善

昨年 12 月にこちらの機能をリリースしましたが、実際には機能からバーコード出品につながったお客様は、想定より少ない結果となっていました。

そのため、我々はユーザーのログからいくつか仮説をたて、UI の改善を行いました。

例えば、ポップアップが表示されたユーザーがタップをした割合が低いことなどから、以下の仮説が考えられます。

  • モデルの精度が十分でなく、本以外のものにも反応してしまっている
  • ユーザーとのインタラクションが不十分である

今回モデルの Precision は 90% 近くあるため、まずはモデルの精度以上に、ユーザーとのインタラクションに問題があると考えました。

複数の AB テストをし、以下のようにデザインを改善しました。改善点は次のポイントです。

  • ポップアップの時間を長くする
  • バーコード出品の利点が伝わるように、メッセージを変更する
  • タップ可能なことが伝わるように、ボタン風のデザインに変更する



図 4 改善後デザイン



この結果、ポップアップ表示後、タップしてくれるお客様の割合は倍以上になり、バーコード出品の新規利用割合を、6% 以上増加することができました。

このように、AI 機能をアプリに組み込む際には、モデルの精度以外という、他の要因によっても意図しない結果になることが多く起こるため、機能をリリースした後にも継続的に分析をし、さまざまな観点から改善を行う必要があります。

このように、メルカリでは、Edge-AI を含めた AI を使った機能開発を加速させていくとともに、お客様の UX を継続的に改善していく取り組みをしています。



Posted by Khanh LeViet - Developer Relations Team


サミュエル フリック氏は The Elements of User Onboarding の著者であり、自身が主宰するウェブサイト User Onboard でさまざまな人気アプリのオンボーディング プロセスの teardowns (分解)分析を公開している UX デザイナーです。

同氏はユーザー オンボーディングを、ユーザーが日々の生活にプロダクトをうまく採り入れる可能性を高める機会のことだと定義しており、同氏のモットーは、ユーザーが使い始めるところからデザインを始める、というシンプルなものと定義しています。

定着率を高め、解約を減らし、人々にアプリの利用と長期間にわたる定期購入を促すために、ユーザー オンボーディングでどのような施策がとれるかについて、サミュエル氏の見解を伺いました。

数々のアプリをレビューする際に気付いた、ユーザー オンボーディングに最もありがちな間違いとは何ですか？


私が外部からプロダクトを評価するときは、どの人も単純に「間違い」を犯しているとは言わないようにしています。これはワークフローのコンバージョン数にアクセスできない状態では、何がどのような結果をもたらしているのかを把握することが難しい（もしくは不可能）なためです。

しかしながら、チームと直接仕事をする場合によく目にする間違いの 1 つに、すぐにオンボーディングの「インターフェース」に過剰に投資しようとする傾向があるということがあります。たとえば、それ自体に独自の価値がないツールチップ を紹介するフローやアプリを紹介する動画を、プロダクトに貼り付けることが挙げられます。

ユーザー オンボーディングの重要性に気付き、自身のプロダクトのオンボーディングを改善しようとするデベロッパーが増えているのは喜ばしいことですが、元から壊れているインターフェースに「さらに多くのインターフェース」を追加しようとするのは、すでに辛すぎるチリソースに香辛料をさらに足すようなものです。

インタラクション キューの追加は、より多くのユーザーにより多くの作業を求めることになりますが、本当に重要なのはユーザーに最初にしてもらうべき作業を見つけ出すことです。

ユーザーに最初は写真をアップロードしてもらうべきでしょうか、最初はチーム メンバーを招待してもらうべきでしょうか、それともまったく別のことをしてもらうべきでしょうか。それを調べる方法は数多くあり、その上時間もかかります。でも一度調べてしまえば、極めてしっかりした根拠に基づいて自信をもって構築を進めることができます。

優れたオンボーディング体験のデザインにおいて必要な最初の手順は何ですか？


上記と同様、最初の手順には、長期間の定着率に直接関係するユーザー アクションを把握することが含まれている必要があります。これにはさまざまな方法でアプローチできます。たとえば、すでにプロダクトを利用しているユーザーの行動の定量分析や、最初にプロダクトがユーザーの生活にどのように適合するかを把握するために用いられる定性調査のセッションなどがあります。

いずれにせよ、ユーザーがプロダクトから何を得ようとしているか（そして、そのようなユーザーのエネルギーに対してプロダクトをどう位置づければ利益を最大化できるか）を把握することが最も重要です。

いずれの種類の調査でも私が最初によく行う方法の 1 つは、ライフサイクル メールを利用することです。多くの場合、ライフサイクル メールは企業のリソースの縄張り意識が最も低い領域のひとつなので、実験的なマインドセットを持ってアプローチすれば、有用なデータを極めて簡単に得ることができます。

ライフサイクル メールとオンボーディング 体験は、それぞれどのような場合に適していますか？


私はライフサイクル メールをオンボーディング 体験全体の重要な一部分と考えているので、初めから自分の中でこの両者を分けることは困難です。

どちらの場合も、デベロッパーは、現実世界の進歩に向けての過程でユーザーが行う一連の重要な活動を特定し、その過程の各段階で体系的にユーザーをサポートする必要があります。最初のセッションだけでユーザーがサポートされることはまずありません。そのため、この長いゲームの随所にアプリ内のオンボーディング UX とライフサイクル メールでの取り組みを計画することが、すべての人にとっての最善の策となります。

理想はあなたのプロダクトがひとつひとつのサインアップを価値あるものにするためにカスタムの経路を作り、両者がうまく機能することです。

アプリ内のオンボーディングで必ず表示すべき主な情報や手順は何ですか？


オンボーディング 体験において「必ず」表示すべきものがあるとは言えません。特に、これはサインアップ手順に関して当てはまります。プロダクトがサインアップ手順や説明を一切必要としない形で位置づけられていることが理想です。

付け加えるとしたら、コンテキストは有用です。デベロッパーの求めるアクティビティに労力を注ぐことでユーザーにどのような利点があるか、ということにフォーカスすることをおすすめします。

たとえば、ユーザーに電話番号の入力を求める場合、単に「電話番号を入力してください」と伝える以外にユーザーのやる気を起こさせる方法は数多くあります。「友だちがあなたを見つけられるよう」とか「あなたのアカウントを保護するために」といった簡単な理由を付け加えるだけで、ユーザーが進んで同意してくれるようになります。

デベロッパーはオンボーディング 体験において購入を促すべきですか？


デベロッパーが購入を促すべき状況とは、該当する購入がユーザーと明らかに関連性がある場合です。そうした状況は使用開始から数分以内に生じることもあれば、1 か月以上にわたって生じない可能性もあります。

この考え方は、訪れたユーザーがどのような状態でも登録に進み、喜んで購入する（または、より多くの時間を調査にに使う）ユーザーになるまでの過程において、必要な各段階でユーザーをサポートするシステムの構築に多く活用されています。

ユーザーが喜んで購入する状態というのは、支払うお金と比較して受け取るものの価値のほうが高い、とユーザーが確信したときのことを指します。そのような状態で訪れるユーザーはほとんどいないと思われるため、ユーザーをそのような状態に変えることがプロダクトのクリエイターの仕事です。

著名な投資家であるクリス サッカの言葉を借りれば、「価値を求める前に価値を創出しろ」ということです。

解約を減らすための一番のおすすめの方法は何ですか？


上記と同じような回答になりますが、ユーザーが絶え間なく価値を得られるようにすることです。

 顧客ビジネスで成功を収めている世界中のチームは、自分たちの顧客を観察し、活動が低調になっている顧客を特定し、そうした顧客が解約に至る前に介入して対処できるようにしています。デベロッパーは自身のプロダクトを、同じ取り組みを「大規模に」行うものとみなすことができます。

実際に私は、デザイン プロセス全体を開始する際に、まず全員（プロダクト チームとユーザー）の関心をユーザーの受け取る価値に向けさせ、プロダクト体験のあらゆる面でユーザーの受け取る価値を明確にすることがよくあります。これにより、プロダクトに触れるすべての人の主な関心を「ユーザーの受け取る価値」に引き寄せることができます。

注意深く進めれば、解約するユーザーによって失う利益の額よりも、既存ユーザーが（アップグレードや紹介などを通じて）もたらす利益の額のほうが多い「net negative churn (ネット ネガティブ チャーン)」の状態を目指すことさえ可能です。実現すれば素晴らしいことであり、高品質なユーザー オンボーディングはその重要な第一歩となります。

厳格なペイウォールを持つ定期購入アプリにおいて、まだ喜んでお金を出す状態になっていないオンボーディング中のユーザーがいるとしたら、どのように考えるべきですか？


教育することです。

ユーザーは、自身の生活で何らかの有意義な進歩を成し遂げるためにあなたのアプリを訪れていますが、「あなたのプロダクトを利用する」ことは、その目的を達成するための数ある方法のひとつに過ぎません。

たとえば、あなたのプロダクトが「チームの共同作業アプリ」であれば、人々との間でブランドへの親近感（「顧客関係」など）を生み出せるあらゆる方法を検討するとよいでしょう。具体的には、適切なプロジェクト管理の方法についての学習コース、効果的なリソースのスケジューリングに関するブログ投稿、時間を記録するための公開ツールなどを提供することが考えられます。

ユーザーが今すぐ利用し始めなくても、その方向に少しずつ向かっている可能性があります。その間は、そのようなユーザーにとって役に立つ別の方法を探してみましょう。そうすれば、ユーザーの顧客マインドセットは確立されているも同然です。

成功すれば、マーケティング、オンボーディング、プロダクト デザインを隔てる境界線ははっきりしないものになります。 極めて望ましい状態と言えるでしょう。


定着率と解約率の改善について詳しく知りたいデベロッパーの方は、「定期購入ビジネスの未来を確かなものに (英語)」および「定期購入を解約したユーザーを引き止めるには(英語)」をご覧ください。また、UX を重視したゲームデザインにおけるインサイトを紹介した「ユーザーのことを考えてゲームを開発するには(英語)」も併せてご覧ください。

Reviewed by Kei Kawabata - Application Solution Consultant, Google Play

来たる 12 月 7 日、「World Usability Day Tokyo」を開催することが決定しました。国内外の専門家と交流できる貴重な機会です。開発者、デザイナー、起業家の皆さま、ご興味のある方はぜひご参加ください。

開催概要
日時：2017 å¹´ 12 月 7 日（木）　13:00 - 19:10 （開場  12:30 より）
会場 : グーグル合同会社
定員 : 100 名
ハッシュタグ : #gdewud2017
参加登録 : 事前登録制。こちらのページからご登録ください。
　　　　（※後日、参加いただける方には参加証を送ります。）
プログラム：
　13:00 - 13:20　Welcome Talk
　13:20 - 14:05　How to build an app when usability is our first objective?
                          Joël Schillio, UX / Product Designer
　14:05 - 14:50　Emotions in Motion
                          Alon Chitayat, Sr. UX and Motion Designer, Google
　14:50 - 15:05　Break
　15:05 - 15:50　Seamless Video Ad Experiences
                          Paolo Malabuyo, User Experience Director, Google Video Ads, Google
　15:50 - 16:35　PWA: A fully immersive user experience on the web
                          Abdelrahman Omran, Software Architect at Rinvex
　16:35 - 16:50　Break
　16:50 - 17:35　Creating influence as a designer
                           Niyati Gupta, Interaction Designer, Google
　17:35 - 18:20　調整中
　18:20 - 18:25　Break
　18:25 - 18:55　Panel Discussion
　18:55 - 19:10　Closing

　※プログラムは変更となる場合があります。


Posted by Takuo Suzuki - Developer Relations Team


ウェブ vs ネイティブ

同じ機能を提供するアプリケーションでも、スマートフォン上のブラウザで動作するのか、それとも単体のソフトウェアとして動作するのかは、大きなテーマとしてここ数年議論されてきました。

デスクトップでは、ブラウザだけで様々なことがこなせるのはもう当たり前です。Chrome OS のように、ブラウザそのものを OS にしてしまうくらいの発展を、ウェブ技術は遂げてきた結果と言えます。

それではモバイルではどうでしょうか？



これは Flurry が行った調査結果です。

アメリカのスマートフォン ユーザーが使用時間の実に 80% 以上をネイティブ アプリケーションに費やし、それに比べるとウェブの利用時間はごく僅かであることがわかります。利用時間だけを基準にすれば、議論の余地もなくネイティブ アプリケーションの圧勝に見えます。

一体なぜなのでしょう？

私が個人的に立てた仮説はこうです。

デスクトップは広大な海、スマートフォンは小さな宇宙

デスクトップでアプリケーションを使う際、ユーザーは通常、キーボードとマウスを使います。デスクトップの世界では、キーボードやマウスさえ使いこなせれば、広大なインターネットという海の中から、自分が欲しい情報やサービスを自在に探し当てることができます。

それに対しスマートフォンでは、指先 1 つで様々なことをこなさなければなりません。ソフトウェア キーボードで文字を打つだけでもちょっとした作業なため、検索するのも楽な作業ではありません。使いたい機能がワンタップですぐに立ち上がるとしたら、どれほど楽でしょう？

つまり、キーボードとマウスでの操作が想定されたデスクトップから、タッチでの操作が想定されたスマートフォンへの最適化がネイティブ プラットフォームの方が早く進んだためではないか、という仮説です。

それでは、ウェブをよりモバイル フレンドリーにしていくために、我々ができることはなんでしょうか？Chrome がブラウザとして提供できる新しい機能、みなさんが開発者として実装できる新しい機能を
  • エクスペリエンス
  • スピードとオフライン
  • エンゲージメント
という 3 つのパートに分けてご紹介していきます。

エクスペリエンス

ウェブとネイティブを比較した際、最も大きく異なるのはそのアクセス方法です。

ウェブでは最初のアクセスの際、検索やリンクを辿ることでサービスに到達します。ネイティブではマーケットプレイスでインストールすることにより、サービスに到達します。

それでは二回目以降はどうでしょうか？ウェブでは、ブックマークしていない限り、検索やリンクをもう一度辿る必要があります。ブックマークしていたところで、フォルダ構造を辿るなどするため、最低でも数タップが必要です。逆にネイティブの場合、インストール済みのアプリケーションはホーム画面にあるため、アイコンを一度タップするだけで済みます。

インストールのハードルが高いとはいえ、リピートしてもらうことを考えれば、スマートフォンにおいて、ネイティブアプリのようなアクセス方法が理想的なのは明らかですね。ウェブでこれを実現することはできないものでしょうか？

ホーム画面に追加

既に Chrome で利用できる機能に「ホーム画面に追加」というものがあります。これを選択することで、ウェブサイトのブックマークがホーム画面に追加され、ユーザーはワンタップでブラウザを開き、アクセスできるようになります。
さらに、もう一工夫加えることで、これをよりネイティブに近いエクスペリエンスにすることができます。そこで登場するのが Web Manifest です。

manifest.json
{
  "name": "Kinlan's Amazing Application ++",
  "short_name": "Kinlan's Amaze App",
  "icons": [
    {
      "src": "launcher-icon-3x.png",
      "sizes": "144x144",
      "type": "image/png"
    }
  ],
  "start_url": "index.html",
  "display": "standalone"
}

index.html
<link rel="manifest" href="/manifest.json">

Web Manifest は JSON で記述されたウェブサイトのメタ データで、サーバー上に配置したものを HTML から link[rel="manifest"] で参照することにより効力を発揮します。上記の例ではアプリの正式名称（name）、ホーム画面に追加された際のショートネーム （short_name）、アイコンの指定（icons）（画面サイズに応じて複数指定可能）、アイコンをタップした際に開く URL（start_url）、表示モード（display）、を指定しています。この Web Manifest により、ウェブサイトをホーム画面に追加した際の挙動を、よりモバイル フレンドリーなものへと変えることができるのです。

参考 URL はこちら：

フルスクリーン

Web Manifest の display を standalone とすることで、ホーム画面のアイコンから起動した際に URL バーを隠し、よりネイティブ アプリに近い見た目にすることもできます。

インストール バナー

実はここまでのエクスペリエンスは、iOS の Safari でも同様のことが随分昔からできていました。とはいえ、ホーム画面にアイコンを追加してもらうには、ユーザーの能動的なアクションが必要で、最低でも 2 回のタップを伴うため、決してよく使われる機能ではありません。ホーム画面に追加することを促すバナーをページ上に表示しているサイトも珍しくはありません。

そこで Chrome では、M42 からこの「ホーム画面に追加」をブラウザが自動的に促してくれる機能を追加しました。


Chrome にこのバナーを表示させるためには、いくつかの条件があります。
  • ユーザーがウェブサイトを 1 週間以内に 2 回訪問
  • Web Manifest が存在する
  • Service Worker を使っている
  • HTTPS でサーブされている
※ これらの条件はあくまで現時点のものであり、今後変更される可能性があることにご注意ください。

参考 URL:

テーマカラー

Chrome では meta[name="theme-color"] を使うことで URL バーの色を変更することができます。色は hex のカラー コードを content 属性で指定します。

<meta name="theme-color" content="#db5945">

さらに Android 5.0 以降であれば、最近利用したアプリ一覧を表示した際の表示もここで指定した色で表示されるようになります。

参考 URL はこちら：

スピード・オフライン

ウェブ アプリも、ネイティブ アプリのようにリソースをローカルに持たせることで、起動速度を向上することができます。作り方によってはオフラインでも動作させることができるはずです。

ご存知のとおり、これはウェブにとって初めての試みではありません。Application Cache はこれを実現しようとした最初の標準仕様でしたが、様々な問題点が指摘されるなど、現在も広く使われている機能とは言えません。

そこで代替技術として現在注目を浴びているのが、Service Worker です。

Service Worker とは

Service Worker はオフライン技術を可能にするためだけのものではありません。Service Worker とは、ひとことで言うならこうです：

ユーザーに見えるウェブページの裏側で動かせるイベント駆動の JavaScript 環境

ウェブページで Service Worker を登録することで、様々なイベントを受け取れるようになり、それに伴い任意の動作をバックグラウンドで行えるようになります。例えば
  • ウェブページのリクエストを横取りして、ローカル プロキシのように動作。
  • ウェブページが開いていなくても、イベントを受け取り、スクリプトを実行。

Service Worker バックグラウンドで動作すると言っても、常時動いているわけではありません。イベント駆動になっていますので、各種イベントが発生するのに伴い、様々な短い処理を行うことができます。想定されているユースケースは様々です：
  • ローカル プロキシ
  • オフライン キャッシュ
  • プッシュ通知
  • バックグラウンド同期
  • ジオ フェンシング
fetch イベントを使うと、ドキュメントから発生したあらゆるリクエストをイベントとして受け取り、ローカル プロキシとして動作させることができます。これを使えば、例えば次のようなこともできます：
  • 画面サイズを元に動的に URL を書き換えることで、レスポンシブにサイズの異なる画像を取得する
  • クエリに応じてテスト用のスタブ データを返す
  • JavaScript の依存関係を動的に解決し、必要なリソースを CDN などから取ってくる（ハッカソンで出たアイディア）
なお、Service Worker は非常に強力な機能のため、HTTPS でのみ動作可能（デバッグのため localhost は例外）である点に注意してください。

サンプル コード

コードを見るのが何よりもイメージが湧きやすいと思いますので、簡単な例を示します。

navigator.serviceWorker.register('/sw.js')
  .then(function(registration) {
      // Success!
  }).catch(function(error) {
      // Error...
  });

このコードでは、index.html に存在する JavaScript から Service Worker を登録しています。
登録が成功すると、以後ブラウザのバックグラウンドで Service Worker の JavaScript（この場合 sw.js）が動き続けることになります。

Cache API

この Service Worker 上で fetch イベントを取り、ブラウザからサーバーにリクエストが発行される度に、あらかじめキャッシュしてあるリソースを返すことで、ウェブサイトを高速にしたり、オフラインで利用できるようすることができます。

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request).then(function(response) {
      return response || fetch(event.request);
    })
  );
});

このコード例では、リクエストに対し、あらかじめキャッシュしてあるリソースをそのまま返しています。ページの本体である index.html ですらオフラインで動作できるのが Service Worker の強力な点です。


なお、Service Worker によるキャッシュ機能はウェブページそのものとは切り離されているため、非対応ブラウザで実行しても、単純に Service Worker 部が動作しないだけで、ページ自体には問題が発生しにくいという特徴があります。ブラウザ互換性をあまり気にしなくても、対応ブラウザにだけ付加的にメリットを提供できるのも ServiceWorker の魅力の一つです。

参考 URL:

エンゲージメント

モバイルプラットフォームでサービスを提供する方たちがウェブではなくネイティブを選ぶ理由のひとつに、プッシュ通知が挙げられます。メールでは見逃される可能性のあるメッセージを、肌身離さず持っている携帯電話の一等地とも言える場所に届けられるのですから、モバイルのプッシュ通知は大変強力です。
では、これがウェブで実現できたらどうでしょう？それを可能にするのが Service Worker を使ったプッシュ通知機能です。

こちらのデモでは "Enable Push Notifications" のスイッチを入れると同時に、パーミッションを求めるダイアログが表示され、許可をするとそれ以降プッシュ通知を受信することが可能になります。自分で "SEND A PUSH TO GCM VIA XHR" をクリックして動作を確認してみてください。

仕組みはこうです：
  1. ユーザーがサービスにアクセスし、サイトの最新情報を購読するボタンをクリック
  2. 許可を得るダイアログが表示され、ユーザーが許可します。
  3. 仕様上は HTTP Push と呼ばれるプロトコルを使って、サーバーからプッシュが行われます。
  4. しかし、接続するサーバーが多くなればなるほど、張らなければならないコネクション数が多くなってしまうため、Chrome では Android で既に使われている Google Cloud Messaging というサービスを利用することで、コネクションを束ねます。
  5. これにより、端末に必要なコネクションは GCM とのみとなり、サーバーは GCM サーバーに HTTP POST を使ってメッセージを送信するだけで、プッシュが可能になります。
Chrome では現状このような実装になっていますが、Service Worker はオープンスタンダードですので、将来的に Chrome もそれに合わせた挙動になるよう変更されていく予定です。

購読時のサンプル コード：

navigator.serviceWorker.ready().then(function(sw) {
  sw.pushManager.subscribe().then(function(sub) {
    // After permission is granted
    sub.subscriptionId; // registration Id
    sub.endpoint;       // GCM URL
  });
});

ウェブサイトがプッシュ通知の購読を行います。その際、ユーザーに同意を求め、許可された場合のみ、GCM と通信を行い、subscription id を取得します。そしてその subscription id をサーバーに送ります。

プッシュ受信時のサンプル コード：

self.addEventListener('push', function(event) {
  event.waitUntil(
    self.registration.showNotification(title, {
      body: body,
      icon: icon,
      tag:  tag
    }
  });
});

サーバーはその subscription id を使って GCM に Post メッセージを送ることで、プッシュ通知を行います。
Service Worker はプッシュ通知をイベントで受け取り、Notifications API を使って通知を表示します。

参考 URL:

Chrome におけるプッシュ通知の現時点での制約

Chrome のバージョン 42 からプッシュ通知が使えると書きましたが、この段階では未実装機能の制約がとても多いのが現状です。ネイティブアプリ並みのプッシュ通知を行いたい場合は、もうしばらく待つ必要があります。
  • Push メッセージにデータを乗せられない
  • Push されたら通知を出さなければならない
  • Notification にデータを乗せられない
とはいえ、プッシュ通知は大変強力な機能ですので、実際に試し、来るべき未来に備えることをオススメします。

SSL について

既にお気付きの方も多いと思いますが、Service Worker の強力な機能の多くは、ウェブサイトが HTTPS であることを前提としています。
HTTPS は、暗号化や証明書といった用途だけでなく、「ホーム画面に追加」のおおすすめや、Service Worker を使うこと、プッシュ通知を使うなどする際に、必須条件になっています。
  • 「ホーム画面に追加」のおすすめ
  • Service Worker
  • プッシュ通知
  • 暗号化
  • 証明書
この機会にサイト全体を HTTPS にすることをぜひご検討ください。

まとめ

Web Manifest と theme-color を使うことで、あなたのモバイル ウェブサイトは今すぐエクスペリエンスを向上することができます。また、Service Worker の Cache API を使えば、既存の機能を損なうことなく、スピードの改善・オフライン対応することができます。将来に備え、HTTPS やプッシュ通知の導入もご検討ください。

Posted by Eiji Kitamura - Developer Relations Team