[日本語Alexa] スキルで利用可能な各種IDの一意性調査

0 リプレイスについて

Alexaは、昨年(2017年)11月に日本語対応となりました。ここDevelopers.IOでは、英語でしか利用できない頃から色々Blogに書いてきたのですが、更新された情報も含めて日本語で利用するAlexaについて纏め直してみたいと思います。

この記事は、下記の記事のリプレイス版です。
Amazon AlexaのSkillにおける、applicationId,userId,deviceIdの一意性の調査

1 はじめに

Alexaのスキル開発では、よりユーザーフレンドリーなものを追求すれば、特定の条件で処理を分けたくなるのは、当然のように発生するニーズでしょう。

例えば、スキル起動時のウエルカムメッセージを、初めてスキルを起動する場合と、2回目以降で変えるような事は考えられないでしょうか。

「ようこそマルバルスキルへ! このスキルは、△△△なときに■■■と話し掛けることで✕✕✕することが出来ます! また、□□□もできます・・・」などのように、初めて起動した時に、スキルの主要な機能を紹介するのは、ユーザーにとって有益だと思います。しかし、丁寧な紹介は、丁寧であるほど2回め以降、ユーザーにうるさく聞こてしまうでしょう。

そこで、2回目以降の起動時は、「こんにちは!」とか「お久しぶりです!」だけにしてしまいます。詳細なスキルの説明は「ヘルプ」などを要求した時にだけ発話するようにするのです。

このような処理を実装した場合、結論から言ってしまうと、スキルを呼び出したユーザーを特定するuserIdを使用します。スキル実行時に、そのuserIdを記憶しておき、同じuserIdでアクセスされた時に、2回目以降の起動として処理するのです。

今回は、userIdに加えて、applicationId及び、deviceIdが、どのような条件で変化し、固有の識別子として利用可能であるかを確認してみましたので、紹介させて下さい。

また、特定の条件で、この値が変化してしまうこともあるので、その注意点についても纏めておきたいと思います。

2 IDの取得

下記は、AlexaからSkillに対して送られるリクエストJSONです。

今回の調査の対象したのは、Context.Systemの中にある、applicationIduserId及び、deviceIdの3つです。

{
    "version": "1.0",
    "session": {
        "new": true,
        "sessionId": "amzn1.echo-api.session.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "application": {
            "applicationId": "amzn1.ask.skill.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
        },
        "user": {
            "userId": "amzn1.ask.account.XXXXXXXXXXXXXXXXXXXXXXXXX"
        }
    },
    "context": {
        "AudioPlayer": {
            "playerActivity": "FINISHED"
        },
        "System": {
            "application": {
                "applicationId": "amzn1.ask.skill.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
            },
            "user": {
                "userId": "amzn1.ask.account.XXXXXXXXXXXXXXXXXXXXXXXXX"
            },
            "device": {
                "deviceId": "amzn1.ask.device.XXXXXXXXXXXXXXXXXXXXXXXXX",
                "supportedInterfaces": {
                    "AudioPlayer": {}
                }
            },
            "apiEndpoint": "https://api.fe.amazonalexa.com",
            "apiAccessToken": "XXXXXXXXXXXXXXXXXXXXXXXXX"
        }
    },
    "request": {
        "type": "LaunchRequest",
        "requestId": "amzn1.echo-api.request.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "timestamp": "2018-01-08T12:49:45Z",
        "locale": "ja-JP"
    }
}

3 調査の方法

実施した調査の方法は、下記のとおりです。

  • 端末(Echo)、アカウント(Amazonアカウント)、スキルをそれぞれ2つずつ用意
  • 上記をマトリックス図に展開して、IDの値が同一になる条件を確認

非公開のスキルは、開発者アカウントでしか有効にできないため、Skill Beta Testingを使用して、開発者アカウント以外でもテストできるようにしました。

4 調査の結果

そして、結果は以下のとおりです。

applicationId

スキル毎にユニーク

userId

スキル+アカウント毎にユニーク

deviceId

スキル+アカウント+デバイス毎にユニーク

なお、この値は、デバイスを再起動したり、アカウント登録をやり直しても、変化しませんでした。

5 特記事項

上記の調査結果までは、特に気に留めるところはありませんが、試験中に下記の動作を確認しましたので、特記事項としてまとめさせて頂きました。

(1) スキルの再登録

スキルの利用は、AlexaアプリからEnable/Disableが可能ですが、利用していたスキルを一旦Disableにして、再びEnableに戻した場合、userId及び、deviceIdが変化します。

元々、この2つのIdは、スキルの同一性が影響していますが、同じスキルでも、一旦、Disableされると、別のスキルとして扱われるという事です。

ユーザーから見れば、アプリを削除して、まっさらな状態にできるのと同じ動作なので歓迎される動作かもしれません。逆に、開発側から見ると、一旦Disableされると、同一ユーザを識別する方法は無いとも言えます。

(2) Echosim.ioでの利用

Amazon Ecoのシュミレータとして提供されている Echosim.ioですが、こちらは、Amazonのアカウントでログインして使用するようになっています。

004

しかし、Echosim.ioでログインすると、同アカウントで利用しているスキルが、一旦 Disable/Enableされたように、識別値が変わってしまう事を確認しました。

userIdやdeviceIdを識別に利用しているスキルを開発中に、同シュミレーターを使用する場合は、注意が必要だと思います。

6 最後に

今回は、applicationIduserId及び、deviceIdの一意性に関する調査を纏めてみました。

もしかすると、ユーザに豊かな体験を提供するためには、これらのIdをうまく活用することは、非常に重要かも知れません。

7 参考リンク


Alexaクライアント「Friendly Voice Assistant」をリリースしました
Amazon Alexa用のクライアントをiOSで作ってみた
[日本語Alexa] 日本語スキルを公開しました。審査提出から公開まで 〜あなたの味方〜
[日本語Alexa] Alexa Skills Kit for Node.js はじめの一歩
[日本語Alexa] Alexa Skills Kit for Node.js 次の一歩(データ保存)