柔軟性を持たせる
スキルに柔軟性があるということは、想定されるどのような状況でも、スキルがユーザーの発話を理解して適切に処理できるようデザインされていることを意味します。ここでは、ユーザーとの会話が想定とは異なる展開をした場合に、スキルにうまく対応させる方法をいくつかご紹介します。
パターンと事例
さまざまな発話をインテントに一致させる
インテントとは、ユーザーがスキルにしてほしいことを表すものです。たとえば、スキルが旅行の計画を手伝うことや、何かの状態を確認すること、冗談を言うこと、もしかしたらモンスターを攻撃することがあるかもしれません。
あるインテントに対して、開発者が想定したとおりの文言をユーザーが言うとは限りません。ユーザーは「旅行の計画を立てて」と言うこともあるでしょうし、「休みにハワイに行きたい」と言う可能性もあります。 ユーザーのさまざまな発話に対応できるよう、ユーザーが言いそうな文、フレーズ、言葉を想定し、幅広く用意しておきます。
次の例は、ユーザーの「旅行を計画して」というインテントに相応するサンプル発話です。
- 「旅行に行きたい」
- 「旅に出ようかな」
- 「旅行プランを立てて」
- 「休みを取りたい」
過剰な応答に対応する
過剰な応答とは、Alexaが1つの応答を求めているのに対し、ユーザーが1つ以上の答えを言うことです。過剰な応答には、スキルが正しく対応するために必要な情報やインテントが含まれている場合があります。 この場合、すべての答えを先にもらって、多くの質問をする必要がなくなったと前向きに考えましょう。たとえば、過剰な応答はユーザーが旅行の予約をするときに起こることがあります。
良い例
ユーザー： 「次の金曜日に神戸を出発して、札幌でハイキングする｣
Alexa： 「わかりました。神戸発札幌行のフライト、午前10時発、午後2時発、午後4時発のうち、どれを予約しますか？」
ユーザー： 「午前10時」
悪い例
ユーザー： 「次の金曜日に神戸を出発して、札幌でハイキングする｣
Alexa： 「目的地はどこですか？」
ユーザー： 「札幌って言ったんだけど」
Alexa： 「わかりました。 いつ出発しますか？」
ユーザー： 「ハイキングに行きたいんだ」
Alexa： 「札幌のウォーキングツアーを予約しますか？」
ユーザー： 「いや、ハイキングがしたいんだ。…もういいよ」
詳細を求める
ユーザーは、不完全なコマンドやリクエストでAlexaにアクションを求めることがよくあります。そのような場合は、インテントを正しく理解するため、Alexaが一部の情報を聞き直したり、追加の情報を求めたりする必要があります。
良い例
ユーザー： 「茅ヶ崎海岸付近にウィンドサーフィンしに行きたい｣
Alexa： 「出発予定日はいつですか？」
悪い例
ユーザー： 「茅ヶ崎海岸付近にウィンドサーフィンしに行きたい｣
Alexa： 「茅ヶ崎カフェですか？」
ユーザー： 「え？ いや、神奈川の茅ヶ崎海岸だよ」
Alexa：「『え？いや、神奈川の茅ヶ崎』は住所ではありません」
訂正を受け入れる
ユーザーの発話をAlexaが誤って認識した場合や、話した後で気が変わった場合に、ユーザーが内容を訂正することがあります。たとえば、ユーザーは「いや」とか「そうではなくて」と言った後に、正しい内容を話します。これらの訂正を適切に処理するようにしてください。たとえば、予約の場所が間違っていて、ユーザーが変更したがっているとします。
エラーに適切に対応する
音声と言語が認識されるしくみは複雑なので、ユーザーには失敗した理由やエラーが発生した理由がわかりません。一方、スマートフォンやウェブアプリといった視覚インターフェースでは、ユーザーは明確に定義された視覚要素（ボタン、メニュー、編集ボックスなど）があるので、何ができるのか、または何が間違っていたのかがはっきりわかります。音声のやり取りではそうはいかないので、独創性を発揮して対処する必要があります。Alexaは応答を聞き取れなかったり、理解できなかったりした場合、情報を再びリクエストします。これにより、ユーザーは、Alexaが話の筋を理解できなくなる前に問題の修正を試みることができます。Alexaがユーザーの言うことを聞き取れなかった、または正確に理解できなかったことだけを告げるエラーメッセージは避けてください。たとえば「聞き取れませんでした」などです。 このようなメッセージでは、ユーザーはエラーの原因となったフレーズを単に繰り返すだけです。代わりに、操作に役立つ情報を追加して、できるだけ指示を明確にします。
次の例の場合、Alexaがユーザーのリクエストを理解できのは、それがスキルのパラメーターの範囲外であるのが原因です。そのため、エラーメッセージでは、Alexaができることのヒントをユーザーに提示します。
良い例
Alexa： 「デザートのレシピを見つけるお手伝いをします。何を作りたいですか？」
ユーザー： 「夕飯にラザニアを作りたい」
Alexa： 「私が見つけられるのは、クッキー、ケーキ、お菓子といったデザートです。夕食に添えたいデザートはありますか？」
悪い例
Alexa： 「デザートのレシピを見つけるお手伝いをします。何を作りたいですか？」
ユーザー： 「夕飯にラザニアを作りたい」
Alexa： 「すみません。理解できませんでした。何を作りますか？」
Alexaが理解できない場合のデザイン
Alexaがユーザーの言ったことを聞き取れても理解できない場合、そのことを率直に伝えて、会話を再開させてください。わかりやすい質問をすることでユーザーは次に何ができるかを理解します。するとユーザーが操作や応答に迷うことはなくります。スキルのロジック処理とエンティティ解決の詳細については、こちらを参照してください。
Alexaが理解できても対応できない場合のデザイン
サポートしていない機能をユーザーが利用しようとした場合、「それについてはまだお手伝いできません」といった返答で、その機能はまだ利用できないことをユーザーに伝えてください。ただし、今後その技術またはサービスが利用可能になることを約束しないでください。開発者は開発者コンソールで発話を追跡することで、ユーザーがある機能をリクエストしたかどうかを把握でき、スキルに対してどの機能を優先して開発すべきか知ることができます。たとえば、ユーザーが旅行の計画中にレンタカーを希望したとします。
ユーザーが応答しないときに再プロンプトを出す
ユーザーがAlexaに応答しない場合、Alexaは元のプロンプトを少し変えて再プロンプトを出します。ユーザーがAlexaの質問内容を理解できていない可能性もあるので、より具体的に聞いてみてもよいでしょう。
コンテキストに合ったヘルプを提供する
ユーザーがヘルプを求めたときは、直前の会話を補足するようなプロンプトを出します。たとえば、ピザを注文しようとしているユーザーが、注文を確定する前に、ピザ店がガーリックノットを販売しているかどうかをたずねてきたとします。まずその質問に回答してから、元のピザの注文を確定してください。 会話をデザインする際は、ヘルプがあまり必要にならないようにデザインしてください。たとえば、ユーザーがタクシーを呼ぶスキルを使用していて、場所の変更などのアクションを実行する方法が分からないとします。
休止の追加およびSSMLによる音声パターンのカスタマイズの詳細については、こちらを参照してください。