Serviceと対話するクライアントは、たびたび、競合するオーディオを生成するイベントやディレクティブに遭遇します。Alexaが話している最中にユーザーが質問をしてきたり、楽曲のストリーム再生中にあらかじめ設定されていたアラームが鳴ることがあります。これらの入出力の優先順位付けと処理を制御するルールは、対話モデルと呼ばれます。以下のセクションで取り扱う内容は、次のとおりです。Service(AVS)APIは、きめ細かく細分化されたインターフェースの集まりです。各インターフェースは、それぞれ特定のクライアント機能に対応するディレクティブとイベントで構成されています。ディレクティブは、AVSからクライアントに対して、特定のURLからのオーディオ再生やアラームの設定といった具体的なアクションを実行するよう指示するために送信されるメッセージです。イベントは、クライアントからAVSに送信されるメッセージで、Alexaに対して何かが発生したことを通知するものです。あるイベントには、ユーザーからの音声によるリクエストがあります。APIで公開されている各インターフェースの簡単な説明です。ユーザーの話した音声をクラウドに送信するために使用します。Alexaの話す音声を処理するために使用します。タイマーとアラームの設定と管理に使用します。オーディオ再生の管理と制御に使用します。ボタンの押下やGUIアフォーダンスによって再生キューを操作するために使用します。ミュート/ミュート解除を含む、音量コントロールの管理に使用します。Serviceに提供するために使用します。AVSとクライアントとの対話クライアントとAVSとの間の対話は、以下の2つの方法で開始されます。典型的な対話では、クライアントがAVSに対してイベントを送信します。イベントが処理されると、AVSは、その結果として0以上のディレクティブをクライアントに返します。ユーザーがAlexaに「今、何時?」と聞いたとします。Serviceにストリーミングし、Alexaがイベントを処理したら、クライアントに音声を出力するよう指示するディレクティブが返されます。a.m.」と応答します。クラウドで開始された対話では、クライアントは先行するクライアントイベントがなくてもディレクティブを受信する場合があります。Alexaアプリからクライアントのボリュームを調整するとき、クライアントから直接Alexaに送信されるイベントはありません。Alexaアプリでとられたアクションを解釈し、クライアントがアクションを実行できるよう、クライアントに対してディレクティブを送信します。各イベントは、それぞれ固有のイベントストリーム内でクラウドに送信する必要があります。クラウドからのディレクティブと対応するオーディオ添付ファイルは、同じストリーム内で、または別のダウンチャネルストリーム内でクライアントに返されます。ダウンチャネルは、主にクラウドで開始されたディレクティブをクライアントに配信するために使われるストリームです。Service側からはオープンの半閉鎖状態でオープンのままになります。イベントストリームとダウンチャネルストリームは、転送プロトコルに応じてさまざまな方法で実装できます。これらのストリームをHTTP/2を介して確立する方法についてのガイダンスを提供しています。詳細については、HTTP/2接続の管理を参照してください。AVSに新機能が追加されると、クライアントに新しい、不明なディレクティブが送信される場合があります。コードは、こうした変更にも柔軟に対応し、新しい不明なディレクティブが検知された場合にも中断しないように記述する必要があります(音声リクエストライフサイクルを参照してください)。JSONの処理AVSに新機能が追加されると、ディレクティブのJSONペイロードに、既存のプロパティとの後方互換性を維持しつつ、新しいプロパティが追加される場合があります。そのため、こうした変更に柔軟に対応できるコードを作成する必要があります。JSONのパースを行うコードは、新しい不明なプロパティが検知されても中断しないことが必要です。JSON処理のためのJavaコード例については、AVSサンプルアプリの以下のファイルを参照してください。MessageDeserializer関数を参照してください。FAIL_ON_UNKNOWN_PROPERTIESをFALSEに設定してください。音声リクエストライフサイクルクライアントを設計する際、どの時点においてもアクティブな音声リクエストは1つだけになるようにしてください。そのため、クラウドに送信する各Recognizeイベントに対して、一意のdialogRequestIdを作成し、最新のアクティブなdialogRequestIdをトラッキングすることが必要です。このdialogRequestIdは、Recognizeイベントを後続のディレクティブと関連付けるために使用されます。新しい音声リクエストがユーザーによって開始された場合(Recognizeイベント)、前回アクティブだったdialogRequestIdに関連付けられたすべてのディレクティブは削除される必要があります。イベントがAlexaに送信されると、クライアントによって以下のルールが強制されます。SpeechRecognizer.Recognizeイベントごとに、一意のdialogRequestIdを作成する必要があります。Recognizeイベントのヘッダーに、dialogRequestIdが含まれる必要があります。クラウドに新しいRecognizeイベントを送信するまで、dialogRequestIdがアクティブのまま維持される必要があります。新しいイベントが送信されると、前回アクティブだったdialogRequestIdに関連付けられたすべてのディレクティブは削除される必要があります。ディレクティブをAlexaから受信すると、クライアントによって以下のルールが強制されます。クラウドから送信されたディレクティブのヘッダーにあるdialogRequestIdが、アクティブなdialogRequestIdに一致する場合は、該当するディレクティブを連続して処理する必要がある。dialogRequestIdがないディレクティブは、すぐに実行する必要がある。新しい不明なディレクティブが検知されたときは、クライアントからAlexaにExceptionEncounteredイベントを送信する必要がある。不明なディレクティブを受信してもコードが中断しないようにしてください。Speakディレクティブ(Alexaが読み上げテキストを返したときに発行される)を受信した場合、後続のディレクティブを処理する前に関連するオーディオをすべて再生する必要があります。ディレクティブ処理のためのJavaコード例については、AVSサンプルアプリの以下のファイルを参照してください。dispatch関数を参照してください。クライアントが不明なディレクティブを受信した場合は、AlexaにExceptionEncounteredイベントを送信する必要があります。チャネルクライアントで処理されるオーディオはすべて、チャネルと呼ばれる3つのカテゴリーに分類されます。チャネルには、Dialogチャネル、Alertsチャネル、Contentチャネルがあります。チャネルは、クライアントがオーディオ入力と出力に優先順位を付ける方法を制御するのに使用される概念です。各チャネルは、それぞれ1つ以上のAVSインターフェースに関連付けられます。各チャネルの状態は、アクティブまたは非アクティブに設定できます。SpeechSynthesizerはDialogチャネルに関連付けられます。AlexaがクライアントにSpeakディレクティブを返すと、Dialogチャネルがアクティブになり、Alexaが応答を終了するまでアクティブのまま維持されます。同様に、タイマーが鳴動すると、Alertsチャネルがアクティブになり、タイマーがキャンセルされるまでアクティブのままになります。以下の表は、各チャネルにどのインターフェースがマッピングされるかを示しています。AudioPlayerDialogチャネルは、ユーザーまたはAlexaのどちらかが話しているときにアクティブになります。Alertsチャネルは、タイマーまたはアラームのどちらかが鳴っているときにアクティブになります。Contentチャネルは、クライアントがオーディオストリームなどのメディアを再生しているときにアクティブになります。複数のチャネルが同時にアクティブになることも可能です。ユーザーが楽曲を聞いているときにAlexaに質問をすると、ユーザーまたはAlexaが話している間は、ContentチャネルとDialogチャネルが同時にアクティブになります。チャネルは、フォアグラウンドにもバックグラウンドにもなることができます。どの時点においても、同時にフォアグラウンドになれるのは1つのみです。複数のチャネルがアクティブの場合、以下の優先順位に従う必要があります。Contentの順です。フォアグラウンドにあるチャネルが非アクティブになったら、この優先順位で次のアクティブなチャネルがフォアグラウンドになります。チャネルの対話方法は、以下のルールで制御されます。非アクティブなチャネルは常にバックグラウンドになる。Dialogチャネルがアクティブなときは、常にフォアグラウンドになる。Alertsチャネルは、Dialogチャネルが非アクティブなときにのみフォアグラウンドになる。Contentチャネルは、その他のチャネルが非アクティブなときにのみフォアグラウンドになる。フォアグラウンドにあるチャネルが非アクティブになったら、この優先順位で次のアクティブなチャネルがフォアグラウンドになります。ユーザーにさらに発言を促すRecognizeイベントへの応答としてExpectSpeechディレクティブを受信したときに発生する複数回に及ぶ対話中は、リクエスト/応答シナリオに関連付けられたすべてのディレクティブが処理されるまで、Dialogチャネルがアクティブなまま維持される必要があります。任意のインターフェースのディレクティブを処理する方法は、そのチャネルの状態(アクティブ/非アクティブ、フォアグラウンド/バックグラウンド)によって異なります。Dialogチャネルがフォアグラウンドにあり、アラームが鳴った場合、アラームはDialogチャネルがアクティブな間、短く鳴動する必要があります。アラームが鳴ったときにDialogチャネルが非アクティブな場合は、アラートは長く鳴り続ける必要があります。APIの概要を参照してください。対話モデルのテスト実装したコードが機能することを確認するためのテストを、いくつか紹介します。App][avs-java-sample-app]を使用してテストできます。Alexaに5秒間のタイマーをセットするよう言います。Alexaがタイマーのセットが完了したと通知してきたら、Alexaに天気予報を尋ねます。Alexaが天気予報を読み上げているときは、タイマーはAlexaが読み上げ終わるまで短く鳴動する必要があります。これは、Dialogチャネルがアクティブなためです。Alertsチャネルはバックグラウンドになる必要があります。Alexaの読み上げが完了したら、Alertsはフォアグラウンドになり、ユーザーがタイマーを停止させるまで長く鳴り続ける必要があります。Alexaに1分間のタイマーをセットするよう言います。Alexaがタイマーのセットが完了したと通知してきたら、Alexaにお気に入りの楽曲を再生するよう言います。楽曲の再生が開始され、約1分後にタイマーが鳴る間は楽曲がバックグラウンドに移行する必要があります。これは、Contentチャネルが、その他のチャネルが非アクティブなときにのみフォアグラウンドになるためです。楽曲は、ユーザーがタイマーを停止させるまでバックグラウンドのまま維持され、タイマーが停止された時点で通常の音量に戻るか、または一時停止状態から再開されます。Alexaにお気に入りの楽曲(まだ飽きてなければ、ですが)を再生するよう言います。再生が開始されたら、Alexaに地域のニュースを尋ねます。音声リクエストとAlexaの応答の間ずっと、楽曲はバックグラウンドのままで再生される必要があります。これは、Dialogチャネルがアクティブなときは、常にフォアグラウンドになるためです。Alexaの応答が完了したら、楽曲は通常の音量に戻るか、一時停止状態から再開されます。Contentチャネルがバックグラウンドのときは、オーディオの再生が一時停止状態になるか、音量が小さくなることを意味します。