4つのポイントでわかるBaaSのユーザーアカウントの仕組み

さっそく次の4つのポイントを順に追いながら、BaaSの基本的なユーザーアカウントの仕組みを見ていきましょう。

• ・匿名ユーザーによるログイン
• ・SNSアカウントによるログイン
• ・アカウント作成時の認証方法
• ・アカウントのスコープ

Point1 : 匿名ユーザーによるログイン

BaaS内に登録する情報の多くは、情報の所有者を示すユーザーIDやそれに準じるID（複数のユーザーIDが所属するグループIDのようなものなど）に紐づく形で登録するでしょう。 ユーザーへ情報を表示する時には、リクエストしているユーザーのユーザーIDとBaaS内の情報の所有者を示すIDを比較してアクセスコントロールします。

しかしアプリによっては事前のアカウント登録が不必要なものもあります。 例えば、ゲスト利用のようにユーザーは区別したいけどユーザー情報の登録はいらない場合です。 この場合は匿名ユーザーやアノニマスユーザーと呼ばれる機能を確認しましょう。 ほとんどのBaaSではユーザー名/パスワードを空欄のまま登録したり、任意のユーザー名／パスワードを自動生成して登録する等の方法で、ユーザーにアカウントを意識させることなくアプリ側でユーザーIDを区別できます。

Point2 : SNSアカウントによるログイン

アカウント作成時のユーザー離脱はアプリ開発者共通の課題です。 ユーザーがスマートフォンアプリを使い始めるには、まずストアでアプリを検索してダウンロードをしなくてはなりません。 そのうえアプリを起動した直後にたくさんの入力フォームが並んだアカウント登録画面を見たら・・・私ならそっとそのアプリを閉じてしまいます。

この課題を解決するひとつの方法として、アプリにSNSアカウントを利用したログイン機能をつけることをオススメします。 OpenID ConnectやOAuthを使ってSNSに登録されているユーザー情報を取得しアカウント登録を簡単にすることができます。 ほとんどのBaaSがTwitterやFacebookなどの著名なSNSアカウントでのログインをサポートしています。

Point3 : アカウント作成時の認証方法

アカウント作成画面でIDやパスワードを決定して登録した後に、さらにメールに記載されているURLクリックをしてはじめてアカウント登録が完了する・・・というフローはみなさん1度は経験されたことがあるでしょう。 このようにメール等を利用してユーザーの身元を確認する認証処理は一般的で、BaaSでも利用することができます。

アカウント作成時に認証を行う目的は2つあります。 1つはユーザーがユーザー自身の意志で登録していることを確認する為です。 例えばメール認証の場合は、友人のメールアドレスを使って友人になりすます行為を防止しています。

2つめは有効な連絡先を確保する為です。 ネイティブアプリはPush通知機能を使ってユーザーに情報を通知することもできますが、ケースによってはPush通知よりもメールやSMSで連絡をする方が適していることもあります。

一般的なアカウント作成時の認証方法は以下3つです。

• ・認証なし
• ・メール認証
• ・SMS認証

(1)認証なし

アカウントのIDにメアドや電話番号を使う必要がなく、複アカ（一人のユーザーが別の人格を装って作成する 複数のアカウント）の作成も容認できる場合は「認証なし」でいいでしょう。 アカウント作成時のユーザー離脱率を下げるのにもとても効果的です。 ただし故意に大量のアカウントを作成される場合もあるので注意が必要です。 プログラムで機械的にアカウントを作成するbotを防止するために、CAPTCHAを使うことを検討しなければならないケースもあります。

(2)メール認証

複アカの作成をある程度抑えたい場合や、ユーザーにメールで連絡を行いたい場合は「メール認証」がおすすめです。 ネイティブアプリだけではなくPC等の他デバイスでもサービス提供を行いたい場合にも有効です。

多くのBaaSがメール認証機能を提供しています。 メールを自動的に送ってくれることも便利ですが、メール認証時のWeb画面やWebサーバを用意しなくてよいのもとても助かりますね。 Web画面のデザインをカスタマイズすることもできます。

(3)SMS認証

メール認証よりも複アカの作成を抑えたい場合には「SMS認証」が適しています。 SMSは電話番号宛に送れるショートメッセージです。 SMSで任意の番号や文字列を送り、それをアプリに用意した入力フォームに入力してもらうことで認証を行います。 メールに比べて電話番号は1人あたりの所有数が少ない（通常1?2個）のため、複アカ防止に効果的です。 1人1回だけ特典を受けられるような機能を提供したい場合や、複アカによるチート行為でゲームバランスが崩れてしまう可能性がある場合などに有効です。

国産BaaSの1つであるKii CloudはSMS認証機能を提供しています。 Parseはそれ自体ではSMS認証を提供していませんが、Twilioを利用する等して実装することが可能です。^1 ミクシィグループのノハナ社が提供している人気のフォトアルバムアプリ「ノハナ(nohana)」は、Parse + Twilioの組み合わせでSMS認証を実現しています。

Point4 : アカウントのスコープ

最後にあなたのアプリに必要なアカウントのスコープも確認しておきましょう。 アカウントのスコープとはアカウントが有効な範囲、つまりIDを共通して使う範囲という意味で利用しています。 アプリ毎に専用のユーザーIDを発行すればよい場合もありますが、複数のアプリで共通のユーザーIDを使いたい場合もあります。 例えば、楽天IDは楽天市場だけでなく楽天トラベルや楽天ブックス等の楽天グループ内サービスで共通して利用でき、広いスコープになっています。

BaaSが提供するアカウントのスコープは以下の３つに分類できます。

(1)各アプリ毎に独立

まずは各アプリ毎に独立したユーザーのアカウントを提供する仕組みです。 例えばあるBaaS上でA社がアプリ1とアプリ2を提供しているとします。私がこのアプリ1とアプリ2を両方利用した場合にそれぞれ別の値のユーザーIDになります。 現在はParseをはじめとするほぼすべてのBaaSがこの方式を提供しています。

アプリ毎にアカウントやそれに紐づくユーザーデータのスコープが限定されているのは、ユーザーにとっては一番わかりやすいアカウント体系でしょう。 しかし複数のアプリをリリースしているような会社の場合、例えば全アプリを通して特定ユーザーの利用状況を分析することができない等のデメリットがあります。

(2)特定BaaSを利用する全アプリで共通

次に特定BaaSを利用する全アプリで共通のユーザーIDを提供する仕組みです。 BaaSユーザーIDと表現すればよいでしょうか。 ユーザーはBaaSを利用するためのユーザーIDを作成し、そのBaaSを利用して作成されるアプリはすべてこのユーザーIDを使用します。 例えばあるBaaS上でA社がアプリ1とアプリ2、B社がアプリ3を提供しているとします。 私がこれらのアプリを利用する場合、私は1つのユーザーIDですべてのアプリを利用できます。 現在は日本で最初にBaaS提供を始めたappiariesがこの方式を提供しています。

ユーザーは最初にこのBaaS（を利用するアプリ）を使用する時のみアカウント作成をすればよいため、後発のアプリはアカウント作成時のユーザー離脱の心配がありません。 しかしBaaSはアプリのバックエンドを支える陰の存在なので、アプリのユーザーからはBaaS存在が見えにくいものです。そのためユーザーにとってはアカウントのスコープがわかりにくいでしょう。 またアプリの種類（例えばまじめなアプリとエロアプリ！）によって連携するSNSアカウントを使い分けにくいのもデメリットです。

(3)アプリ提供会社毎に共通

最後にアプリ提供会社毎に共通のユーザーIDを提供する仕組みです。 例えばあるBaaS上でA社がアプリ1とアプリ2、B社がアプリ3を提供しているとします。 私がこれらのアプリを利用する場合、私はA社用のユーザーIDとB社用のユーザーIDの2つを作成して利用します。 この方式ならば先程挙げた楽天のアプリのようなケースにも対応できます。 個人的にはこの方式にニーズがあるのではないかと思っていますが、残念ながら現在のところこの方式を採用しているBaaSはなさそうです。 ミクシィは社内用BaaSでこの方式を実装しています。^2 複数のアプリをリリースしているような会社の場合に、全アプリを通して特定ユーザーの利用状況を分析したり、アプリを超えてPush通知を使った友人からの招待機能を使えるなどのメリットがあります。

まとめ

いかがでしたでしょうか？ 今回はアプリ開発時に意識するべきユーザーアカウントの仕組みの4つのポイントを挙げながら、BaaSの基本的なユーザーアカウントの仕組みをご紹介しました。

本連載は今回が最後ですが３回の間にもいくつかの新しいBaaSの提供が発表されました。 今後も新しいBaaSが増えたり、各社新規機能を追加したりと大きな動きが予想されます。 ぜひ今後もBaaSをウォッチしてあなたのアプリ開発に生かしてください。

※Fb=Facebook、Tw=Twitter、Li=LinkedIn、Sf=Salesforce.com