#Alexa スキルのアカウントリンクをCustomer Profile APIに移行する方法

はじめに

Alexaスキルで、ユーザーごとにカスタマイズされたサービスを提供するには、半年ほど前までアカウントリンクが必須でした。これは、他のWebサービスのアカウントとAlexaスキルをリンクさせることで、WebサービスのAPIを呼び出すことを可能にし、Alexaスキルからの応答をパーソナライズさせる機能です。

[日本語Alexa] Cognito User Pool によるアカウントリンク

2018年8月、新たに"Customer Profile API"(以下、CPA)が発表されました。これは、Alexaユーザーのオプトインによって、ユーザーのAmazonアカウントに登録された氏名、メールアドレス、携帯電話番号のいずれかを取得できるAPIです。

[日本語 #Alexa ] スキルからユーザーの名前やメールアドレス、携帯電話番号が取得できるようになりました

CPAで得られる情報(名前やメールアドレスなど)を取得することでAlexスキルの要件が満たせる場合、Alexaスキルのユーザーにとっては、従来必要であった、Webサービスのアカウントを別途作成する作業が不要となります。よって、CPAによってAlexaスキルの利用を開始するためのハードルを下げることができます。

この場合、以前アカウントリンクでサービスを提供していたAlexaスキルは、バージョンアップ時に実装を変更して審査を通過すれば、次回からはCPAを使った情報取得が可能になります。

しかし、単純にアカウントリンクからCPAに実装を変更してしまうと、それまでアカウントリンクで利用していたユーザーは、再度AlexaアプリでCPAのオプトイン設定を余儀なくされます。

この事態を避け、アカウントリンクを有効化しているユーザーは従来のまま利用し続け、新規のスキルユーザーはCPAでも利用できるようにする方法はないでしょうか。

その方法を、2018年9月に発表されたOptional Account Linkingを使って検討してみます。

アカウントリンクのデフォルトの挙動

デフォルトのアカウントリンクは、スキルの有効化と同時にWebサービスへのサインインを求められます。以下、画面で確認していきます。

1. [有効にする]ボタンを押すと、リンクされたWebサービスのログイン画面にすぐに遷移します。

もし、[有効にする]ボタンを押したあとWebサービスへのログインを行わなかった場合、スキルは有効ですが、リクエストからアクセストークンを取得しても、accessTokenプロパティが含まれていません。

"Optional Account Linking"を有効にする

Alexaスキル開発者側の作業です。

1. Alexa Developer Consoleの[アカウントリンク]で、[ユーザーがアカウントリンクなしでスキルを有効にすることを許可してください]をオンにします。

あるいは、ASK CLIでcreate-account-linkingサブコマンドを利用する場合は、Allow users to enable skill without account linking: (Y/n)にYを入力します。

Alexaスキル開発者側の作業は、いったんは上記のみです。次に、この設定によるユーザー側の画面変更を確認していきます。

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"が最適ですが、同時にスキルを無効化した際の操作について、詳細な説明が必要と思われます。