この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
Alexaスキルで、ユーザーごとにカスタマイズされたサービスを提供するには、半年ほど前までアカウントリンクが必須でした。これは、他のWebサービスのアカウントとAlexaスキルをリンクさせることで、WebサービスのAPIを呼び出すことを可能にし、Alexaスキルからの応答をパーソナライズさせる機能です。
2018年8月、新たに"Customer Profile API"(以下、CPA)が発表されました。これは、Alexaユーザーのオプトインによって、ユーザーのAmazonアカウントに登録された氏名、メールアドレス、携帯電話番号のいずれかを取得できるAPIです。
CPAで得られる情報(名前やメールアドレスなど)を取得することでAlexスキルの要件が満たせる場合、Alexaスキルのユーザーにとっては、従来必要であった、Webサービスのアカウントを別途作成する作業が不要となります。よって、CPAによってAlexaスキルの利用を開始するためのハードルを下げることができます。
この場合、以前アカウントリンクでサービスを提供していたAlexaスキルは、バージョンアップ時に実装を変更して審査を通過すれば、次回からはCPAを使った情報取得が可能になります。
しかし、単純にアカウントリンクからCPAに実装を変更してしまうと、それまでアカウントリンクで利用していたユーザーは、再度AlexaアプリでCPAのオプトイン設定を余儀なくされます。
この事態を避け、アカウントリンクを有効化しているユーザーは従来のまま利用し続け、新規のスキルユーザーはCPAでも利用できるようにする方法はないでしょうか。
その方法を、2018年9月に発表されたOptional Account Linkingを使って検討してみます。
アカウントリンクのデフォルトの挙動
デフォルトのアカウントリンクは、スキルの有効化と同時にWebサービスへのサインインを求められます。以下、画面で確認していきます。
1. アカウントリンクをデフォルト値に設定したスキルの一覧画面での表示。[アカウントのリンクが必要です]と記述があります。
2. アカウントリンクをデフォルト値に設定したスキルの詳細画面。[有効にする]ボタンの近くに[アカウントのリンクが必要です]と記述があります。
- [有効にする]ボタンを押すと、リンクされたWebサービスのログイン画面にすぐに遷移します。
もし、[有効にする]ボタンを押したあとWebサービスへのログインを行わなかった場合、スキルは有効ですが、リクエストからアクセストークンを取得しても、accessTokenプロパティが含まれていません。
"Optional Account Linking"を有効にする
Alexaスキル開発者側の作業です。
- Alexa Developer Consoleの[アカウントリンク]で、[ユーザーがアカウントリンクなしでスキルを有効にすることを許可してください]をオンにします。
あるいは、ASK CLIでcreate-account-linkingサブコマンドを利用する場合は、Allow users to enable skill without account linking: (Y/n)にYを入力します。
Alexaスキル開発者側の作業は、いったんは上記のみです。次に、この設定によるユーザー側の画面変更を確認していきます。
2. "Optional Account Linking"を設定したスキルの一覧画面での表示。[アカウントリンク可能]に変わっています。
3. "Optional Account Linking"を設定したスキルの詳細画面。[有効にする]ボタンの近くのメッセージも[アカウントリンク可能]に変わっています。
4. ユーザー側のスキル詳細画面では、[有効にする]ボタンをクリックすると、単にスキルが有効化されるのみで、特にアカウントリンクの画面には遷移しません。
4. [設定]ボタンをクリックすると、[アカウントをリンク]というリンクが表示され、これをクリックすると、Webサービスのサインイン画面に遷移します。
Alexaユーザーの状態を整理して課題を検討する
以上で、アカウントリンクを必須からオプションに変更することができました。CPAの設定は、 "Optional Account Linking"の設定の如何に関わらず、以前の記事の方法で有効化できます。
ここまでの議論を踏まえ、Alexaスキルのユーザーの状態についてロジックの観点から整理してみます。
- アカウントをリンクしているか否かの判断
- スキルに送信されるリクエストにcontext.System.user.accessTokenが含まれるか否か
- CPAでの情報取得を許可しているか否かの判断
- スキルに送信されるリクエストにcontext.System.apiAccessTokenが含まれるか否か
- スキルをASK SDK v2 for Node.jsで構築している場合は、メソッドの呼び出しがエラーになるか否か
次に、トークンの観点からAlexaスキルのユーザーの状態について整理してみます。
- context.System.user.accessTokenが含まれる
- アカウントリンクしているユーザー
- context.System.apiAccessTokenが含まれる
- CPAでの情報取得を許可しているユーザー
- context.System.user.accessTokenもcontext.System.apiAccessTokenも含まれない
- Alexaスキルを初めて有効化したユーザー
- アカウントリンクしていたユーザーがスキルを無効化した
- CPAでの情報取得を許可していたユーザーが許可を取り消した
- context.System.user.accessTokenもcontext.System.apiAccessTokenも含まれる
- 判断が難しいところですが、アカウントリンクを優先すべきかと考えます
ここから分かることがあります。当初、従来からスキルを利用していたユーザーが、CPAへの移行に伴って再設定を行うことがないように検討を進めてきた "Optional Account Linking"ですが、ユーザーがスキルを無効化した後に有効化し、アカウントリンクもCPAも許可していない状態では、無効化以前の状態(アカウントをリンクしていたのか、CPAのみを許可していたのか)が把握できないことです。そのため、音声で適切なアドバイスができず、「新規の場合は...、以前アカウントリンクされていた場合は...、されていなかった場合は...」のような音声案内をせざるを得ません。
従来からアカウントリンクを利用していたユーザーにとっては、バージョンアップ以降に再びアカウントをリンクする場合、以前とはアカウントリンクのUIが異なっていますので、その点について説明が必要と考えられます。
また、従来アカウントリンクを利用していて、なんらかの理由でCPAのみを利用するよう設定を変更するユーザーの場合、アカウントリンク時にWebサービス等に登録していたメールアドレスや電話番号と、CPAで取得できるメールアドレスまたは電話番号が異なることで、弊害が出る可能性も考えられます。
さらに、アカウントリンクを利用せず、CPAのみ許可していたユーザーにとっても、アカウントをリンクするUIは同じく表示されますので、いわば「入り口が2つある」状態となります。この点についても、説明が必要と考えられます。
まとめ
Alexaスキルで取得するユーザー情報を、アカウントリンクからCPAに実装変更した場合に、それまでアカウントリンクで利用していたユーザーが再度AlexaアプリでCPAのオプトイン設定を行うことなく、従来のままスキルを利用し続け、新規のスキルユーザーはCPAでも利用できるようにする方法を検討しました。
それには"Optional Account Linking"が最適ですが、同時にスキルを無効化した際の操作について、詳細な説明が必要と思われます。
3
