Alexa でユーザー発話全文を取得する際に必要な妥協

(English version of this article is here)

cheerio-the-bear.hatenablog.com

意味のない適当な発話例 'a' や同義語 'a a' を登録したカスタムスロットタイプを利用することが、Alexa のスキルでユーザーの発話の全文を取得する方法としては妥当な選択肢ではないか、みたいなことを前回の記事（下記）で書きました。しかし、その方法にも幾つか妥協しないといけない点があります。

cheerio-the-bear.hatenablog.com

問題 1. そんな適当な発話例にもマッチしてしまう
問題 2. 標準ビルトインインテントが邪魔をする
Issue 3. Display インターフェースも事実上使えなくなる

問題 1. そんな適当な発話例にもマッチしてしまう

カスタムスロットタイプに登録した発話例、"a" とか "a a" ですよ（下のスクリーンショットの通り）？Alexa スキルとの通常のやり取りでユーザーがそんな発話をするはずがないのですが、ときどきこれに「完全に一致した」と判断してくれます。

f:id:cheerio-the-bear:20190126183719p:plain — Custome slot type with sample utterance 'a' and its synonim 'a a'

そんなときにスロットを覗いても 'a a' なんてのが入っててくれるので、使いものになりません。ステータスを確認して 'ER_SUCCESS_MATCH' だった場合には、もうユーザーの実際の発話内容を得る術はなく、適当にごまかすしかありません。

    handle(handlerInput) {
        let utterance = handlerInput.requestEnvelope.request.intent.slots.utterance;

        if (utterance.resolutions && utterance.resolutions
                && utterance.resolutions.resolutionsPerAuthority
                && utterance.resolutions.resolutionsPerAuthority[0].status.code
                === 'ER_SUCCESS_MATCH') {
            // Unfortunately the user utterance was undexpectedly matched
            // with the meaningless synonim.

問題 2. 標準ビルトインインテントが邪魔をする

これはカスタムスロットタイプを使う方法をとった場合に限定される話ではありませんが、ユーザーの発話全文を取得するシーンを持つスキルを開発する場合には、標準ビルトインインテントには注意が必要そうです。

自分が作ったスキルでは、スキルを立ち上げた直後にユーザーに "Yes" もしくは "No" の判断をさせる必要があり、AMAZON.YesIntent と AMAZON.NoIntent を利用することにしました。これにより、ユーザーの自由発話の内容を取得するために用意した自前のカスタムスロットでは以降ずっと "Yes" や "No" を受け取れないことはもちろんのこと、それらの類語についても AMAZON.YesIntent や AMAZON.NoIntent に消費されるようになります。

例えば、ユーザーによる発話 'good' は、AMAZON.YesIntent によって消費されます。実際にユーザーがどのように発話したのかという情報は AMAZON.YesIntent には含まれないため、それが 'Yes' だったのか 'Good" だったのかを知る方法はありません。

Issue 3. Display インターフェースも事実上使えなくなる

画面のある端末上にもそれらしいメッセージを表示するべく、Display インターフェースを利用するコードは書いたんです。しかし、書いたコードは残したままにしてありますが、Display インターフェースそのものを無効化してしまいました。作っているスキルでユーザーの発話の全文を取得する必要がある場合には、やむを得ないことであるものと理解しています。

f:id:cheerio-the-bear:20190129210914p:plain — The display interface unavailable

Display インターフェースの無効化せざるを得ない理由は、前項の問題と同じです。同インターフェースを有効化すると、下のスクリーンショットのように多くの標準ビルトインインテントが自動的に追加されてしまいます。それにより、"more" や "next" や "page up" はもちろんのこと、それらの同義語たちも標準ビルトインインテントに消費されてしまうことになります。ユーザーの発話 "more" を AMAZON.MoreIntent として受け取りたくないなら、Display インターフェースを無効化する以外にそれを回避する方法はないように見えます。