カスタムスキルのテストとデバッグ
このドキュメントでは、カスタムスキルのテストの推奨事項について説明します。
スキルを有効にしてテストする方法の詳細については、スキルのテストを参照してください。
一般的なテストの推奨事項
- 呼び出し名をテストします。言いやすく、Alexaが常に認識できる名前であることを確認します。Alexaがたびたび認識に失敗する場合は、変更することを検討してください。呼び出し名の詳細については、カスタムスキルの呼び出し名を決定するを参照してください。
-
音声インターフェースの異なるサンプル発話をすべてテストします。
注：テストの実行中、新しくサンプル発話を追加しなければならないことがよくあります。新しく追加したサンプル発話は、テスト可能になるまでに少し時間がかかることがあります。特に、呼び出し名を含む発話（「アレクサ、<呼び出し名>で双子座の運勢を調べて」など）はその可能性が高いです。
-
異なるスロット値や微妙に違うフレーズを使ったサンプル発話のバリエーションをテストします。よく似たサンプル発話には特に注意を払ってください。
-
サービスがAlexaから送信された異なる種類のリクエストに対して適切に応答することを確認します。
LaunchRequestIntentRequestSessionEndedRequest
-
サンプル発話とそのフレーズのバリエーションからすべてのインテントが正しくトリガーされることを確認します。インテントとサンプル発話の定義の詳細については、以下を参照してください。
- スキルに視覚的な対話やタッチによる対話が含まれる場合、正しい表示が行われること、各タッチ対話により目的のインテントが呼び出されることを確認します。
- Amazon Alexaアプリでスキルの詳細ページ（スキルオプション内）を確認します。アイコン、説明、サンプルフレーズなどのフィールドが、Alexaに追加している機能をユーザーが理解できるような有効な情報を提供していることを確認します。
- テスト中に他のユーザーを観察できる場合は、各インテントを呼び出すためにユーザーが使用したフレーズを記録し、その情報をもとにサンプル発話を更新してください。
- 特に、開発者ポータルで入力したサンプルフレーズをテストします。これらは新しいユーザーが最初に試すフレーズなので、正しく動作することを確認してください。
スキルの認定申請前に実施する必要のあるテストの詳細については、カスタムスキルの認定要件を参照してください。
ユーザーエラー対策にスロットをテストする
スロット値を含むインテントの場合、値の欠落や正しくない値など、さまざまな組み合わせをテストします。AMAZON.DATE、AMAZON.NUMBER、AMAZON.DURATIONなどのビルトインスロットタイプを使っている場合、ユーザーが言ったこれらのスロットに対応する言葉が指定されたデータ型に変換されない場合にもコードが適切に応答することを確認します。
たとえば、ユーザーが言った2つの数字を足すスキルに、2つのAMAZON.NUMBERスロットと以下のようなサンプル発話を定義したインテントがあるとします。
NumberAddIntent {xValue}と{yValue}を足すといくつ
xValueとyValueのスロットに数字以外の単語を指定してこのフレーズをテストし、サービスが適切な応答（ユーザーにデバイスが数値データを聞き取れなかったことを知らせる応答など）を返すことを確認します。
同様に、スロットが固定の値セットからの値を常に含む場合、ユーザーの提供したスロット値がこのセットになくてもサービスが適切に応答することを確認します。たとえば、「十二星座占い」はSignスロットに有効な星座名を想定します。Signスロットにどの星座にも当てはまらない値が含まれる場合に、ユーザーにわかりやすいエラーメッセージをサービスが提供することを確認します。
想定外の入力とダイアログのエラーへの応答に関する推奨事項は、Alexaデザインガイドのエラーを参照してください。
テストにAmazon Alexaアプリを使用する
Amazon Alexaアプリは、Fire OS、Android、iOS、またはウェブブラウザで使用できるコンパニオンアプリ（http://alexa.amazon.com/）です。このアプリには、テストに有効な以下の2つのツールがあります。
- 1つ目は、ホームページ「カード」です。これらは通常、Alexaスキルからの音声応答に加えて画面表示でユーザーに応答を提供するためのものです。たとえば、ユーザーがAlexaに天気予報を聞いた場合、詳細な予報はカードに表示されます。
- 2つ目は、Alexaの履歴です。これにより、Alexaとのすべての音声対話が記録されます。正しいインテントがトリガーされたかどうかは関係ありません。そのため、履歴はAlexaが発話をどう解釈したかを正確に確認し、音声インターフェースの問題を追跡するのに有効です。
デバイスを登録したのと同じアカウントを使ってAmazon Alexaアプリにログインする必要があります。
- Fire OSデバイスの場合、Amazon Alexaアプリはデバイスが登録されたのと同じAmazonアカウントで自動的にログインします。
- iOS、Amazon以外のAndroidデバイス、ウェブブラウザの場合、アプリの初回起動時にログインプロンプトが表示されます。アカウントを切り替えるには、設定、ログアウトをクリックします。
Amazon Alexaアプリカード
カードを確認するには、Amazon Alexaアプリを開いて、メインメニューを開きます。メニューから、アクティビティに移動します。
サービスで返すホームページカードは自由にカスタマイズできます。開発の初期段階では、LaunchRequestとIntentRequestのすべてのリクエストからこれらのカードを送り返すこともできます。基本的なデバッグ情報（トリガーされたインテントの名前など）を含めることで、サービスがどのように動作しているか確認するのに役立ちます。その後、エンドユーザー向けのサービス準備が進むにつれ、通常のエンドユーザーエクスペリエンスにより関連の深いカードを返すこともできます。
開発者が管理するカードに加え、Alexaはサービスとの通信エラーの応答カードも返します。よくあるエラーの一部を紹介します（すべてではありません）。
| エラーカード | 考えられる原因 |
|---|---|
| 予期しない通信の問題 | Alexaがリクエスト送信のためにサービスに接続できない場合に発生します。多くの理由が考えられます。 開発者ポータルのコンフィギュレーションで指定したエンドポイントが正しくありません。 ウェブサービスがオンラインではありません。 エンドポイントがポート443でのトラフィックを受け入れるよう設定されていません。 |
| SSLハンドシェイクの失敗 | SSLが正しく設定されていない場合に発生します。たとえば、自己署名証明書を使用しており、エンドポイントで提示した証明書の公開鍵が開発者ポータルのコンフィギュレーションで指定した鍵に一致しない場合、このエラーが発生します。 |
| プロトコル違反 | サービスの応答が仕様に準拠していない場合に発生します。たいていはコードのエラーが原因です。たとえば、サービスが未処理の例外をスローして終了した場合は、Alexaが受信した応答が正しくないことが考えられます。 |
| ホスト名検証の失敗 | 証明書のDNS.1設定で指定したドメイン名がエンドポイントのドメイン名と一致しない場合に発生します。 証明書のコンフィギュレーションファイルで指定したドメイン名と完全に一致することを確認します。プロトコル（ https://）や後ろのスラッシュを含めないようにしてください。たとえば、サービスのエンドポイントが https://wiseguy.mywebserver.com/wiseguyの場合、証明書のDNS.1にはwiseguy.mywebserver.comを入力します。 |
| SSLハンドシェイク開始中の認識できない名前 | 古いバージョンのApache HTTP Serverを使ってウェブサービスをホスティングし、そのサーバーがServerNameやServerAliasを使って設定されていない場合に発生します。解決するには、2.4.10以降のバージョンにアップグレードするか、サーバーのコンフィギュレーションファイルに ServerNameまたはServerAliasを追加します。 |
Amazon Alexaアプリの履歴
Amazon Alexaアプリでは、ユーザーの対話の完全な履歴も取得できます。履歴の各項目には、ユーザーの話した内容がテキストに変換されて表示されます。
履歴を確認するには、Amazon Alexaアプリを開いて、メインメニューを開きます。メニューから、設定＞Alexaアカウント＞履歴に移動します。
サービスが想定どおりに応答しない場合、話した内容がどのようにテキストに変換されたかを確認すると便利です。たとえば以下のような場合です。
- Alexaが呼び出し名を誤って理解したため、サービスがリクエストを受信できなかった場合
- サービスに送信されたインテントが想定と違った場合
- 正しいインテントが送信されたが、スロットデータが想定外だった場合
- Alexaがユーザーのコマンドを誤って理解したため、サービスにインテントが送信されなかった場合
テストとデバッグのためのその他のツール
ログファイルもテストに有効です。特に、サービスが応答を送信できない問題を検知するのに役立ちます。