サポート終了通知: 2025 年 9 月 15 日、 AWS は Amazon Lex V1 のサポートを終了します。 V1 2025 年 9 月 15 日を過ぎると、Amazon Lex V1 コンソールまたは Amazon Lex V1 リソースにはアクセスできなくなります。Amazon Lex V2 を使用している場合は、代わりに [Amazon Lex V2 ガイド](https://docs.aws.amazon.com/lexv2/latest/dg/what-is.html)を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Lex: 仕組み
Amazon Lex を使用すると、Amazon Alexa に採用されているのと同じテクノロジーを利用し、音声またはテキストのインターフェイスを使用するアプリケーションを構築できるようになります。Amazon Lex を使用する際に実行する一般的な手順を以下に示します。
1. ボットを作成し、サポート対象となる 1 つ以上のインテントを使用してそれを設定します。ボットがユーザーの目的 (インテント) を理解すること、そしてユーザーとの会話から情報を引き出し、ユーザーのインテントを達成できるように設定します。
1. ボットをテストします。Amazon Lex コンソールで提供されているテストウィンドウクライアントを使用できます。
1. バージョンを発行してエイリアスを作成します。
1. ボットをデプロイします。ボットは、モバイルアプリケーションなどのプラットフォームまたはメッセージングプラットフォーム (Facebook Messenger など) にデプロイできます。
開始する前に、以下の Amazon Lex の主要概念と用語を理解してください。
+ **ボット** – ボットは、ピザの注文、ホテルの予約、花の注文などの自動化されたタスクを実行します。Amazon Lex のボットでは、自動音声認識 (ASR) 機能と自然言語理解 (NLU) 機能を使用しています。各ボットは、アカウント内で一意の名前を持つ必要があります。
Amazon Lex ボットは、テキストまたは音声のユーザー入力を理解し、自然言語で会話できます。Lambda 関数を作成してコードフックとしてインテント設定に追加することで、ユーザーデータの検証とフルフィルメントタスクを実行できます。
+ **インテント** – インテントは、ユーザーが実行したいアクションを表します。1 つ以上の関連するインテントをサポートするには、ボットを作成します。例えば、ピザと飲み物を注文するボットを作成できます。各インテントでは、以下の必要な情報を指定します。
+ **インテント名** – インテントのわかりやすい名前。例えば、**OrderPizza**。インテント名は アカウント内で一意でなければなりません。
+ **サンプル発話** – ユーザーがインテントを伝える方法。例: ユーザーが「ピザの注文をお願いします」や「ピザを注文します」と言った場合。
+ **インテントを達成する方法** – 必要な情報をユーザーが指定した後に、そのインテントを達成する方法 (例: 最寄りのピザ店に注文する)。インテントを達成する方法として Lambda 関数を作成することが推奨されます。
オプションとして、Amazon Lex からクライアントアプリケーションに単に情報を返して目的を達成するように、インテントを設定することもできます。
Amazon Lex はまた、ピザの注文などのカスタムインテントを使用できるだけでなく、組み込みインテントを使用してボットを迅速にセットアップすることもできます。詳細については、「[組み込みのインテントとスロットタイプ](howitworks-builtins.md)」を参照してください。
+ **スロット** – インテントでは 0 個以上のスロット (パラメータ) を使用します。インテント設定の一部としてスロットを追加します。実行時に、Amazon Lex は特定のスロット値を指定するようにユーザーに求めます。Amazon Lex がインテントを達成するには、ユーザーがすべての*必須*スロットの値を指定する必要があります。
例えば、`OrderPizza` インテントではピザのサイズ、クラストタイプ、ピザの枚数などが必須スロットです。これらのスロットはインテント設定で追加します。スロットごとに、スロットタイプとプロンプトを指定します。プロンプトは、ユーザーからデータを引き出すために Amazon Lex からクライアントに送信されます。ユーザーは「ラージサイズのピザにしてください」や「スモールサイズにします」などの追加の言葉を含めたスロット値で応答できます。Amazon Lex はまだ意図したスロット値を理解できます。
+ **スロットタイプ ** – 各スロットにはタイプがあります。カスタムスロットタイプを作成するか、組み込みスロットタイプを使用できます。各スロットタイプの名前は、アカウント内で一意でなければなりません。例えば、`OrderPizza` インテントでは以下のスロットタイプを作成して使用できます。
+ Size – 列挙値は `Small`、`Medium`、`Large` です。
+ Crust – 列挙値は `Thick`、`Thin` です。
Amazon Lex はまた、組み込みスロットタイプも用意されています。例えば、`AMAZON.NUMBER` はピザの注文数に使用できる組み込みスロットタイプです。詳細については、「[組み込みのインテントとスロットタイプ](howitworks-builtins.md)」を参照してください。
Amazon Lex が利用可能な AWS リージョンの一覧については「*Amazon Web Services General Reference*」(Amazon Web Services 全般のリファレンス) の「[AWS Regions and Endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#lex_region)」(AWS リージョンおよびエンドポイント) を参照してください。
ここで示している各トピックで、さらに詳しく学習できます。それらを順に確認した後に、「[Amazon Lex の開始方法](getting-started.md)」に進むことをお勧めします。
**Topics**
+ [Amazon Lex でサポートされている言語](how-it-works-language.md)
+ [プログラミングモデル](programming-model.md)
+ [メッセージの管理](howitworks-manage-prompts.md)
+ [会話コンテキストの管理](context-mgmt.md)
+ [信頼スコアの使用](confidence-scores.md)
+ [会話ログ](conversation-logs.md)
+ [Amazon Lex API を使用したセッションの管理](how-session-api.md)
+ [ボットのデプロイメントオプション](chatbot-service.md)
+ [組み込みのインテントとスロットタイプ](howitworks-builtins.md)
+ [カスタムスロットタイプ](howitworks-custom-slots.md)
+ [スロットの難読化](how-obfuscate.md)
+ [センチメント分析](sentiment-analysis.md)
+ [Amazon Lex リソースのタグ付け](how-it-works-tags.md)
# Amazon Lex でサポートされている言語
Amazon Lex V1 は、さまざまな言語とロケールをサポートしています。次の表に、サポートされている言語とサポートされる機能を示します。
Amazon Lex V2 はその他の言語もサポートしています。「[Amazon Lex V2 でサポートされている言語](https://docs.aws.amazon.com/lexv2/latest/dg/how-languages.html)」を参照してください。
## サポートされている言語とロケール
Amazon Lex V1 では、次の言語とロケールがサポートされています。
| コード | 言語とロケール |
| --- | --- |
| de-DE | ドイツ語 (ドイツ) |
| en-AU | 英語 (オーストラリア) |
| en-GB | 英語 (英国) |
| en-IN | 英語 (インド) |
| en-US | 英語 (米国) |
| es-419 | スペイン語 (南米) |
| es-ES | スペイン語 (スペイン) |
| es-US | スペイン語 (米国) |
| fr-CA | フランス語 (カナダ) |
| fr-FR | フランス語 (フランス) |
| it-IT | イタリア語 (イタリア) |
| ja-JP | 日本語 (日本) |
| ko-KR | 韓国語 (韓国) |
## Amazon Lex の機能でサポートされている言語とロケール
Amazon Lex のすべての機能は、次の表に示す以外のすべての言語とロケールでサポートされています。
| 機能 | サポートされている言語とロケール |
| --- | --- |
| [インテントコンテキストの設定](context-mgmt-active-context.md) | 英語 (米国) (en-US) |
# プログラミングモデル
*ボット*は、Amazon Lex のプライマリリソースタイプです。Amazon Lex には、他のリソースタイプとして、*インテント*、*スロットタイプ*、*エイリアス*、*ボットチャンネル関連付け*があります。
ボットを作成するには、Amazon Lex コンソールまたはモデル構築 API を使用します。コンソールのグラフィカルユーザーインターフェイスでは、アプリケーションの本番稼働準備が整ったボットを構築できます。必要に応じて、 AWS CLI または独自のカスタムプログラムを通じてモデル構築 API を使用してボットを作成できます。
作成したボットは、[サポートされているプラットフォーム](https://docs.aws.amazon.com/lex/latest/dg/chatbot-service.html)のいずれかにデプロイします。または、独自のアプリケーションに統合します。ユーザーがボットとやり取りする場合、クライアントアプリケーションは Amazon Lex ランタイム API を使用してボットにリクエストを送信します。例えば、ユーザーが「ピザを注文したい」と言うと、クライアントはランタイム API オペレーションのいずれかを使用して Amazon Lex にこの入力を送信します。ユーザーは、入力を音声またはテキストで提供できます。
インテントでは、Lambda 関数を作成して使用することもできます。これらの Lambda 関数コードフックを使用して、初期化、ユーザー入力の検証、インテントの達成などのランタイムアクティビティを実行できます。ここで示している各セクションで、さらに詳しく学習できます。
**Topics**
+ [モデル構築 API オペレーション](#programming-model-build-time-api)
+ [ランタイム API オペレーション](#programming-model-runtime-api)
+ [コードフックとしての Lambda 関数](#prog-model-lambda)
## モデル構築 API オペレーション
ボット、インテント、スロットタイプをプログラムで作成するには、モデル構築 API オペレーションを使用します。ボットのリソースの管理、更新、削除にもモデル構築 API を使用できます。モデル構築 API オペレーションには以下が含まれます。
+ [PutBot](API_PutBot.md)、[PutBotAlias](API_PutBotAlias.md)、[PutIntent](API_PutIntent.md)、[PutSlotType](API_PutSlotType.md): それぞれ、ボット、ボットのエイリアス、インテント、スロットタイプを作成して更新します。
+ [CreateBotVersion](API_CreateBotVersion.md)、[CreateIntentVersion](API_CreateIntentVersion.md)、[CreateSlotTypeVersion](API_CreateSlotTypeVersion.md): それぞれ、ボット、インテント、スロットタイプのバージョンを作成して発行します。
+ [GetBot](API_GetBot.md)、[GetBots](API_GetBots.md): それぞれ、作成した特定のボット、複数のボットのリストを取得します。
+ [GetIntent](API_GetIntent.md)、[GetIntents](API_GetIntents.md): それぞれ、作成した特定のインテント、複数のインテントのリストを取得します。
+ [GetSlotType](API_GetSlotType.md)、[GetSlotTypes](API_GetSlotTypes.md): それぞれ、作成した特定のスロットタイプ、複数のスロットタイプのリストを取得します。
+ [GetBuiltinIntent](API_GetBuiltinIntent.md)、[GetBuiltinIntents](API_GetBuiltinIntents.md)、[GetBuiltinSlotTypes](API_GetBuiltinSlotTypes.md): それぞれ、ボットで使用できる特定の Amazon Lex 組み込みインテント、複数の Amazon Lex 組み込みインテントのリスト、複数の組み込みスロットタイプのリストを取得します。
+ [GetBotChannelAssociation](API_GetBotChannelAssociation.md)、[GetBotChannelAssociations](API_GetBotChannelAssociations.md): それぞれ、ボットと特定のメッセージングプラットフォームの関連付け、ボットと複数のメッセージングプラットフォームの関連付けを取得します。
+ [DeleteBot](API_DeleteBot.md)、[DeleteBotAlias](API_DeleteBotAlias.md)、[DeleteBotChannelAssociation](API_DeleteBotChannelAssociation.md)、[DeleteIntent](API_DeleteIntent.md)、[DeleteSlotType](API_DeleteSlotType.md): アカウントから不要なリソースを削除します。
モデル構築 API では、Amazon Lex リソースを管理するためのカスタムツールを作成できます。例えば、ボット、インテント、スロットタイプごとのバージョン数は 100 に制限されています。モデル構築 API を使用すると、ボットが制限に近づいたときに、古いバージョン自動的に削除するツールを構築できます。
リソースの更新が一度に 1 つのオペレーションでのみ実行されるように、Amazon Lex ではチェックサムを使用します。`Put` API オペレーション ([PutBot](API_PutBot.md)、[PutBotAlias](API_PutBotAlias.md)、[PutIntent](API_PutIntent.md)、または [PutSlotType](API_PutSlotType.md)) を使用してリソースを更新する場合は、リソースの最新のチェックサムをリクエストで渡す必要があります。2 つのツールで同時にリソースを更新しようとすると、両方から同じ最新のチェックサムが提供されます。最初に Amazon Lex に到達するリクエストは、リソースの最新のチェックサムと一致します。2 番目のリクエストが到着するまでには、チェックサムが異なっています。2 番目のツールは、`PreconditionFailedException` 例外を受け取り、更新は終了します。
`Get` オペレーション ([GetBot](API_GetBot.md)、[GetIntent](API_GetIntent.md)、[GetSlotType](API_GetSlotType.md)) には結果整合性があります。いずれかの `Put` オペレーションを使用してリソースを作成または変更した直後に `Get` オペレーションを使用すると、その更新は返されない場合があります。`Get` オペレーションは、前回の更新を返した後で再度リソースが変更されるまでの間に、必ず今回の更新されたリソースを返します。更新されたリソースが返されたかどうかは、チェックサムを調べて確認できます。
## ランタイム API オペレーション
クライアントアプリケーションは、以下のランタイム API オペレーションを使用して Amazon Lex と通信します。
+ [PostContent](API_runtime_PostContent.md) – 音声またはテキストの入力を受け取り、インテント情報とユーザーに伝えるテキストまたは音声のメッセージを返します。現在、Amazon Lex は以下の音声形式をサポートしています。
入力音声形式 – LPCM および Opus
出力音声形式 – MPEG、OGG、および PCM
`PostContent` オペレーションは 8 kHz と 16 kHz のオーディオ入力をサポートしています。エンドユーザーが電話で Amazon Lex と話す形式のアプリケーション (自動化されたコールセンターなど) は、8 kHz のオーディオを直接渡すことができます。
+ [PostText](API_runtime_PostText.md) – テキストを入力として受け取り、インテント情報とユーザーに伝えるテキストメッセージを返します。
クライアントアプリケーションは、ランタイム API を使用して特定の Amazon Lex ボットを呼び出し、発話 ( ユーザーによるテキストまたは音声の入力) を処理します。例えば、ユーザーが「ピザをください」と言ったとします。クライアントは、Amazon Lex のランタイム API オペレーションのいずれかを使用して、このユーザー入力をボットに送信します。Amazon Lex は、ユーザー入力から、ボットに定義されている `OrderPizza` インテントに関するリクエストであることを認識します。Amazon Lex は、ユーザーとの会話から必要な情報 (ピザのサイズ、トッピング、枚数など) をスロットデータとして集めます。ユーザーがすべての必要なスロットデータを指定すると、Amazon Lex はインテント設定に応じ Lambda 関数のコードフックを呼び出してインテントを達成するか、インテントデータをクライアントに返します。
ボットで音声入力を使用している場合は、[PostContent](API_runtime_PostContent.md) オペレーションを使用します。例えば、自動化されたコールセンターアプリケーションでは音声を Amazon Lex ボットに送信することができるので、エージェントが顧客の問い合わせに対応する必要がありません。電話から Amazon Lex に音声を直接送信するには、8 kHz オーディオ形式を使用できます。
Amazon Lex コンソールのテストウィンドウでは、[PostContent](API_runtime_PostContent.md) API を使用してテキストおよび音声のリクエストを Amazon Lex に送信します。このテストウィンドウは「[Amazon Lex の開始方法](getting-started.md)」の演習で使用します。
## コードフックとしての Lambda 関数
Lambda 関数をコードフックとして呼び出すように Amazon Lex ボットを設定できます。コードフックは複数の目的で使用できます。
+ ユーザーとのやり取りをカスタマイズする - 例えば、Joe からピザのトッピングの種類を尋ねられたときに、Joe の好みに関する過去の知識に基づいてトッピングのサブセットを表示できます。
+ ユーザーの入力を検証する - Jen が営業時間外に花の受け取りを希望しているとします。Jen が入力した時間を検証して、適切なレスポンスを送信できます。
+ ユーザーのインテントを達成する - Joe からピザの注文に必要なすべての情報を得た後で、Amazon Lex は Lambda 関数を呼び出して最寄りのピザ店に注文できます。
インテントを設定する際に、以下の場所で Lambda 関数をコードフックとして指定します。
+ 初期化/検証用のダイアログのコードフック – この Lambda 関数はユーザー入力ごとに呼び出されます (Amazon Lex がユーザーのインテントを理解しているものとします)。
+ フルフィルメントコードフック – この Lambda 関数は、インテントを達成するために必要なすべてのスロットデータがユーザーから提供された後で呼び出されます。
次のスクリーンショットに示すように、インテントを選択して Amazon Lex コンソールでコードフックを設定します。
![\[Lambda 関数のコードフックを示す Amazon Lex コンソール。\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/how-works-10.png)
コードフックは、[PutIntent](API_PutIntent.md) オペレーションの `dialogCodeHook` フィールドおよび `fulfillmentActivity` フィールドでも設定できます。
1 つの Lambda 関数で、初期化、検証、およびフルフィルメントを実行できます。Lambda 関数が受信するイベントデータには、呼び出し元をダイアログまたはフルフィルメントのコードフックとして識別するフィールドがあります。この情報を使用して、コードの該当部分を実行できます。
Lambda 関数では、複雑なダイアログ間をナビゲートできるボットを構築できます。Amazon Lex に特定のアクションを実行するように指示するには、Lambda 関数のレスポンスの `dialogAction` フィールドを使用します。例えば、必須ではないスロット値をユーザーから取得するよう Amazon Lex に指示するには、`ElicitSlot` ダイアログアクションを使用します。明確化プロンプトが定義されている場合、`ElicitIntent` ダイアログアクションを使用して、ユーザーが前のインテントを終了したときに、別のインテントを引き出すことができます。
詳細については、「[Lambda 関数を使用する](using-lambda.md)」を参照してください。
# メッセージの管理
**Topics**
+ [メッセージのタイプ](#msg-prompts-msg-types)
+ [メッセージの設定のコンテキスト](#msg-prompts-context-for-msgs)
+ [サポートされているメッセージ形式](#msg-prompts-formats)
+ [メッセージグループ](#message-groups)
+ [レスポンスカード](#msg-prompts-resp-card)
ボットを作成する際に、クライアントに送信したい明確メッセージや情報メッセージを設定できます。次の例を考えます。
+ 次の明確化プロンプトをボットに設定できます。
```
I don't understand. What would you like to do?
```
Amazon Lex は、ユーザーのインテントを理解できない場合に、このメッセージをクライアントに送信します。
+ `OrderPizza` というインテントをサポートするボットを作成するとします。ピザの注文では、ピザのサイズ、トッピング、クラストタイプなどの情報を指定するようにユーザーに求めます。以下のプロンプトを設定することもできます。
```
What size pizza do you want?
What toppings do you want?
Do you want thick or thin crust?
```
Amazon Lex はユーザーのインテントがピザの注文であると判断すると、これらのメッセージをクライアントに送信してユーザーから情報を取得します。
このセクションでは、ボットの設定でユーザーのやり取りをデザインする方法について説明します。
## メッセージのタイプ
メッセージはプロンプトまたはステートメントにすることができます。
+ 通常、*プロンプト*は質問でユーザーからのレスポンスを想定します。
+ *ステートメント*は情報を表示します。これはレスポンスを想定していません。
メッセージには、スロット、セッション属性、リクエスト属性への参照を含めることができます。実行時に、Amazon Lex は、これらの参照を実際の値で置き換えます。
設定されたスロット値を参照するには、次の構文を使用します。
```
{SlotName}
```
セッション属性を参照するには、次の構文を使用します。
```
[SessionAttributeName]
```
リクエスト属性を参照するには、以下の構文を使用します。
```
((RequestAttributeName))
```
メッセージには、スロット値、セッション属性、リクエスト属性を含めることができます。
例えば、次のメッセージをボットの OrderPizza インテントに設定したとします。
```
"Hey [FirstName], your {PizzaTopping} pizza will arrive in [DeliveryTime] minutes."
```
このメッセージでは、スロット (`PizzaTopping`) とセッション属性 (`FirstName` と `DeliveryTime`) の両方が参照されています。実行時に、Amazon Lex はこれらのプレースホルダを値に置き換えて、次のメッセージをクライアントに返します。
```
"Hey John, your cheese pizza will arrive in 30 minutes."
```
メッセージに角括弧 ([]) または中括弧 (\$1\$1) を入れるには、バックスラッシュ (\$1) のエスケープ文字を使用します。例えば、次のメッセージには中括弧と角括弧が含まれています。
```
\{Text\} \[Text\]
```
クライアントアプリケーションに返されたテキストは次のようになります。
```
{Text} [Text]
```
セッション属性の詳細については、ランタイム API オペレーションの「[PostText](API_runtime_PostText.md)」および「[PostContent](API_runtime_PostContent.md)」を参照してください。例については、[旅行を予約する](ex-book-trip.md)を参照してください。
Lambda 関数は、メッセージを生成して Amazon Lex に返し、ユーザーに送信することもできます。インテントの設定時に Lambda 関数を追加すると、メッセージを動的に作成できます。ボットの設定時にメッセージを指定すると、Lambda 関数でプロンプトを構築する必要がなくなります。
## メッセージの設定のコンテキスト
ボットを作成する場合、ボットの明確化プロンプト、スロット値のプロンプト、インテントからのメッセージなど、異なるコンテキストでメッセージを作成することができます。Amazon Lex は各コンテキストで適切なメッセージを選択してユーザーに戻します。各コンテキストにメッセージのグループを指定することができます。この場合、Amazon Lex はグループから 1 つのメッセージをランダムに選択します。メッセージの形式を指定したり、メッセージをグループにまとめることもできます。詳細については、「[サポートされているメッセージ形式](#msg-prompts-formats)」を参照してください。
インテントと関連付けている Lambda 関数がある場合は、構築時に設定したメッセージをどれでも上書きできます。ただし、こうしたメッセージを使用する上で Lambda 関数は必須ではありません。
### ボットメッセージ
ボットに明確化プロンプトおよびセッション終了メッセージを設定できます。実行時にユーザーのインテントを理解できない場合、Amazon Lex は明確化プロンプト**を使用します。Amazon Lex がセッション終了メッセージを送信する前に、説明を要求する回数を設定できます。次の画像のように、Amazon Lex コンソールの **[エラー処理]** セクションでボットレベルのメッセージを設定できます。
![\[コンソールのエディタタブにあるエラー処理セクション。説明を求めるプロンプトとハングアップフレーズを指定できます。\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/how-works-20.png)
API で `clarificationPrompt` と `abortStatement` フィールドを設定してメッセージを設定します。このフィールドは [PutBot](API_PutBot.md) オペレーションにあります。
インテントで Lambda 関数を使用する場合は、Lambda 関数がユーザーのインテントを尋ねるために Amazon Lex に向けたレスポンスを戻す場合があります。Lambda 関数がそうしたメッセージを提供しない場合は、Amazon Lex が明確化プロンプトを使用します。
### スロットプロンプト
インテントの必須スロットのそれぞれに少なくとも 1 つのプロンプトメッセージを指定する必要があります。実行時に、Amazon Lex はこれらのメッセージのいずれかを使用して、スロットの値を指定することをユーザーに求めます。次は、`cityName` スロットに対する有効なプロンプトの例です。
```
Which city would you like to fly to?
```
コンソールを使用して各スロットの 1 つまたは複数のプロンプトを設定できます。プロンプトのグループは、[PutIntent](API_PutIntent.md) オペレーションを使用して作成することもできます。詳細については、「[メッセージグループ](#message-groups)」を参照してください。
### レスポンス
コンソールで [**Responses (レスポンス)**] セクションを使用し、ボットに動的で柔軟性の高い会話を構築します。レスポンスに 1 つ以上のメッセージグループを作成することができます。実行時に、Amazon Lex は各メッセージグループからメッセージを 1 つ選択することでレスポンスを構築します。メッセージグループの詳細については、「[メッセージグループ](#message-groups)」を参照してください。
例えば、最初のメッセージグループに「初めまして」、「こんにちは」、「ようこそ」といったように異なる応答メッセージを含めることができます。2 番目のメッセージグループには「私は予約ボットです」や「これは予約ボットです」といった異なる紹介メッセージを含めることもできます。3 番目のメッセージグループでは「レンタカーとホテルの予約をお手伝いします」、「レンタカーやホテルを予約することができます」、「レンタカーやホテルの予約をお手伝いできます」といったボットの通信機能を利用することができます。
Lex は各メッセージグループのメッセージを使用して、会話のレスポンスを動的に構築します。例えば、1 つのやり取りを以下に示します。
![\[ボットとの会話の 1 つの例\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/default-response-10b.png)
もう 1 つの例としては、次のようなものがあります。
![\[ボットとの会話の別の例\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/default-response-20c.png)
どちらの場合も、ユーザーは `BookCar` や `BookHotel` などで新しいインテントを使用して応答することができます。
レスポンスでフォローアップの質問をするようにボットをセットアップできます。例えば、前述のインタラクションでは「レンタカーやホテルの予約をお手伝いしましょうか?」、「今すぐ予約を入れますか?」、「他にお手伝いできることはありますか?」といった質問を追加して 4 番目のメッセージを作成することもできます。レスポンスとして「いいえ」が含まれるメッセージには、フォローアップのプロンプトを作成できます。次の画像に例を示します。
![\[ボットとの会話でのフォローアッププロンプト\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/default-response-25a.png)
フォローアップのプロンプトを作成するには [**Wait for user reply**] を選択します。次に、メッセージを入力またはユーザーが「いいえ」と回答した場合に送信する複数のメッセージを入力します。フォローアップのプロンプトとして使用するレスポンスを作成する場合は、回答が「いいえ」だった場合に適切なステートメントを特定する必要があります。例については、次の画像を参照してください。
![\[ユーザーが「いいえ」と言ったときのメッセージ設定。\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/default-response-30b.png)
API を使用してインテントに応答を追加するには、`PutIntent` オペレーションを使用します。レスポンスを特定するには [`conclusionStatement`] フィールドを `PutIntent` リクエストで設定します。フォローアップのプロンプトを設定するには、[`followUpPrompt`] フィールドを設定します。これにはユーザーが「いいえ」と回答した場合に送信するステートメントを含めてください。[`conclusionStatement`] フィールドと [`followUpPrompt`] フィールドの両方を同じインテントで設定することはできません。
## サポートされているメッセージ形式
[PostText](API_runtime_PostText.md) オペレーションを使用する場合、または [PostContent](API_runtime_PostContent.md) オペレーションを使用する場合に `Accept` ヘッダーを `text/plain;charset=utf8` に設定している場合、Amazon Lex は次の形式でメッセージをサポートします。
+ `PlainText` - メッセージには UTF-8 形式テキストが含まれています。
+ `SSML` - メッセージには音声出力のテキスト形式が含まれています。
+ `CustomPayload` - メッセージにはクライアント向けに作成したカスタム形式が含まれています。アプリケーションのニーズを満たすようにペイロードを定義することができます。
+ `Composite` - メッセージは各メッセージグループから 1 つずつ取り出したメッセージを集約したものです。メッセージグループの詳細については、「[メッセージグループ](#message-groups)」を参照してください。
デフォルトでは、Amazon Lex が特定のプロンプトに定義されているメッセージのうち 1 つを返します。例えば、スロット値を引き出すために 5 つのメッセージを定義した場合、Amazon Lex はランダムにいずれかのメッセージを選びクライアントに返します。
Amazon Lex がランタイムリクエストでクライアントに指定のメッセージタイプを返すには、`x-amzn-lex:accept-content-types` リクエストパラメータを設定します。レスポンスはリクエストされたタイプに制限されます。指定したタイプのメッセージが複数ある場合は、Amazon Lex がランダムに 1 つ返します。`x-amz-lex:accept-content-types` ヘッダーの詳細については、「[レスポンスタイプの設定](context-mgmt-request-attribs.md#special-response)」を参照してください。
## メッセージグループ
*メッセージグループ* は特定のプロンプトに対する一連の適切なレスポンスです。ボットで会話のレスポンスを動的に構築する場合は、メッセージグループを使用します。Amazon Lex がクライアントアプリケーションにレスポンスを返すと、各グループからメッセージを 1 つランダムに選択します。各レスポンスで最大 5 件のメッセージを作成できます。各グループには最大 5 件のメッセージを含めることができます。コンソールでメッセージグループを作成する例については「[レスポンス](#msg-prompts-response)」を参照してください。
メッセージグループを作成するには、コンソールを使用するか、[PutBot](API_PutBot.md)、[PutIntent](API_PutIntent.md)、または [PutSlotType](API_PutSlotType.md) オペレーションを使用して、メッセージにグループ数を割り当てることができます。メッセージグループを作成しない場合やメッセージグループを 1 つだけ作成した場合、Amazon Lex は `Message` フィールドでメッセージを 1 件送信します。コンソールでメッセージグループを複数作成した場合、または [PutIntent](API_PutIntent.md) オペレーションを使用してインテントを作成または更新したメッセージグループを複数作成した場合に限り、クライアントアプリケーションはレスポンスで複数のメッセージを受け取ります。
Amazon Lex がグループからメッセージを送信すると、レスポンスの `Message` フィールドにはメッセージを含むエスケープした JSON オブジェクトがあります。次の例は複数のメッセージを含む [`Message`] フィールドのコンテンツを示しています。
**注記**
このファイルは、読みやすいようにフォーマットされています。レスポンスに改行 (CR) は含まれていません。
```
{\"messages\":[
{\"type\":\"PlainText\",\"group\":0,\"value\":\"Plain text\"},
{\"type\":\"SSML\",\"group\":1,\"value\":\"SSML text\"},
{\"type\":\"CustomPayload\",\"group\":2,\"value\":\"Custom payload\"}
]}
```
メッセージの形式を設定できます。形式は次のいずれかになります。
+ プレーンテキスト—UTF-8 形式テキストのメッセージです。
+ SSML—音声合成マークアップ言語 (SSML) のメッセージです。
+ CustomPayload—指定したカスタム警視のメッセージです。
`PostContent` と `PostText` オペレーションが [`Message`] フィールドで返すメッセージの形式を管理するには、`x-amz-lex:accept-content-types` リクエストの属性を設定します。例えば次のようにヘッダーを設定すると、レスポンスでプレーンテキストと SSML メッセージのみを受信するようになります。
```
x-amz-lex:accept-content-types: PlainText,SSML
```
特定のメッセージ形式をリクエストし、メッセージグループにその形式のメッセージが含まれていない場合は `NoUsableMessageException` 例外を受信します。メッセージグループを使用してタイプ別にメッセージをグループ化する場合は、`x-amz-lex:accept-content-types` ヘッダーを使用しないでください。
`x-amz-lex:accept-content-types` ヘッダーの詳細については、「[レスポンスタイプの設定](context-mgmt-request-attribs.md#special-response)」を参照してください。
## レスポンスカード
**注記**
レスポンスカードは Amazon Connect チャットでは機能しません。ただし、同様の機能については、「[対話型メッセージをチャットに追加する](https://docs.aws.amazon.com/connect/latest/adminguide/interactive-messages.html)」を参照してください。
*レスポンスカード*にはプロンプトに対する適切なレスポンスの一連が含まれています。レスポンスカードを使用すると、ユーザーとのやり取りが簡素化され、テキストのやり取りで入力ミスが減り、ボットの精度が向上します。Amazon Lex からクライアントアプリケーションに送信される各プロンプトに対して、レスポンスカードを送信できます。レスポンスカードは、Facebook Messenger、Slack、Twilio、および独自のクライアントアプリケーションで使用できます。
例えば、タクシーアプリケーションで、レスポンスカードに「自宅」のオプションを設定し、その値としてユーザーの自宅の住所を設定できます。このオプションをユーザーが選択すると、Amazon Lex では入力テキストとして住所全体を受け取ります。次の画像を参照してください。
![\[レスポンスカードの例。\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/resp-console-5.png)
レスポンスカードは以下のプロンプトに対して定義できます。
+ 結論ステートメント
+ 確認プロンプト
+ フォローアッププロンプト
+ 拒否ステートメント
+ スロットタイプ発話
プロンプトごとに 1 つレスポンスカードのみ定義できます。
レスポンスカードは、インテントを作成するときに設定します。コンソールまたは [PutIntent](API_PutIntent.md) オペレーションを使用して静的レスポンスカードを構築時に定義できます。または、Lambda 関数でランタイムに動的レスポンスを定義できます。静的レスポンスカードと動的レスポンスカードの両方を定義すると、動的レスポンスカードが優先されます。
Amazon Lex は、クライアントが理解する形式でレスポンスカードを送信します。レスポンスカードは、Facebook Messenger、Slack、Twilio に応じて変換されます。その他のクライアントの場合、Amazon Lex は [PostText](API_runtime_PostText.md) レスポンスで JSON 構造を送信します。例えば、クライアントが Facebook Messenger である場合、Amazon Lex はレスポンスカードを一般テンプレートに変換します。Facebook Messenger の一般テンプレートの詳細については、Facebook ウェブサイトの「[一般テンプレート](https://developers.facebook.com/docs/messenger-platform/send-api-reference/generic-template)」を参照してください。JSON 構造の例については、「[レスポンスカードの動的な生成](#msg-prompts-resp-card-dynamic)」を参照してください。
レスポンスカードは、[PostText](API_runtime_PostText.md) オペレーションでのみ使用できます。レスポンスカードを [PostContent](API_runtime_PostContent.md) オペレーションで使用することはできません。
### 静的レスポンスカードの定義
静的レスポンスカードは、インテントの作成時に [PutBot](API_PutBot.md) オペレーションまたは Amazon Lex コンソールで定義します。静的レスポンスカードはインテントと同時に定義されます。静的レスポンスカードはレスポンスが固定されているときに使用します。例えば、風味のスロットがあるインテントのボットを作成するとします。風味のスロットを定義する場合、次のコンソールのスクリーンショットに示すようなプロンプトを指定します。
![\[コンソールのインテントエディタ。\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/resp-console-10a.png)
プロンプトを定義する場合は、必要に応じてレスポンスカードを関連付け、[PutBot](API_PutBot.md) オペレーションまたは Amazon Lex コンソール (次の例を参照) で詳細を定義できます。
![\[レスポンスカードエディタを示すコンソール。\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/resp-console-20a.png)
ここで、ボットを Facebook Messenger と統合したとします。ユーザーは、次の図に示すように、ボタンをクリックして風味を選択できます。
![\[Facebook Messenger でのレスポンスカード。\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/resp-fb-exampleA.png)
レスポンスカードのコンテンツをカスタマイズするには、セッション属性を参照できます。実行時に、Amazon Lex は、このリファレンスをセッション属性の該当する値に置き換えます。詳細については、「[セッション属性の設定](context-mgmt-session-attribs.md)」を参照してください。例については、[レスポンスカードの使用](ex-resp-card.md)を参照してください。
### レスポンスカードの動的な生成
レスポンスカードをランタイムに動的に生成するには、インテントで初期化および検証の Lambda 関数を使用します。動的レスポンスカードは、Lambda 関数でレスポンスがランタイムに確定される場合に使用します。Lambda 関数は、ユーザー入力に応答してレスポンスカードを生成し、それをレスポンスの `dialogAction` セクションで返します。詳細については、「[レスポンスの形式](lambda-input-response-format.md#using-lambda-response-format)」を参照してください。
Lambda 関数内の `responseCard` エレメントを示す部分は以下のとおりです。これにより、前のセクションで示したようなユーザーエクスペリエンスが生成されます。
```
responseCard: {
"version": 1,
"contentType": "application/vnd.amazonaws.card.generic",
"genericAttachments": [
{
"title": "What Flavor?",
"subtitle": "What flavor do you want?",
"imageUrl": "Link to image",
"attachmentLinkUrl": "Link to attachment",
"buttons": [
{
"text": "Lemon",
"value": "lemon"
},
{
"text": "Raspberry",
"value": "raspberry"
},
{
"text": "Plain",
"value": "plain"
}
]
}
]
}
```
例については、[予約のスケジュール](ex1-sch-appt.md)を参照してください。
# 会話コンテキストの管理
*会話コンテキスト*は、インテントを達成するためにユーザー、アプリケーション、または Lambda 関数から Amazon Lex ボットに提供される情報です。会話コンテキストには、ユーザーが提供するスロットデータ、クライアントアプリケーションによって設定されるリクエスト属性、クライアントアプリケーションと Lambda 関数で作成するセッション属性が含まれます。
**Topics**
+ [インテントコンテキストの設定](context-mgmt-active-context.md)
+ [デフォルトのスロット値を使用する](context-mgmt-default.md)
+ [セッション属性の設定](context-mgmt-session-attribs.md)
+ [リクエスト属性の設定](context-mgmt-request-attribs.md)
+ [セッションタイムアウトの設定](context-mgmt-session-timeout.md)
+ [インテント間での情報の共有](context-mgmt-cross-intent.md)
+ [複雑な属性の設定](context-mgmt-complex-attributes.md)
# インテントコンテキストの設定
Amazon Lex は*コンテキスト*に基づいてインテントをトリガーすることができます。*コンテキスト*は、ボットを定義するときにインテントに関連付けることができる状態変数です。
コンソールを使用して、または [PutIntent](API_PutIntent.md) オペレーションを使用してインテントを作成するときに、インテント用のコンテキストを設定します。英語 (US) (en-US) ロケールで、[PutBot](API_PutBot.md) オペレーションでボットを作成した際に、`enableModelImprovements` パラメータを `true` に設定した場合のみ、コンテクストを使用することができます。
コンテキストには、出力コンテキストと出力コンテキストの 2 種類の関係があります。*出力コンテキスト*は、関連するインテントが満たされたときにアクティブになります。出力コンテキストは、[PostText](API_runtime_PostText.md) オペレーション、または [PostContent](API_runtime_PostContent.md) オペレーションの応答でアプリケーションに返され、現在のセッションに設定されます。コンテキストがアクティブになった後、コンテキストが定義されたときに設定されたターン数または時間制限の間、アクティブなままになります。
*入力コンテキスト*は、インテントを認識するための条件を指定します。会話中にインテントを認識できるのは、その入力コンテキストがすべてアクティブになっているときだけです。入力コンテクストがないインテントは、常に認識の対象となります。
Amazon Lex は、出力コンテキストでインテントを満たすことによってアクティブになったコンテキストのライフサイクルを自動的に管理します。また、`PostContent` オペレーション、または `PostText` のオペレーションの呼び出しでアクティブなコンテキストを設定することができます。
また、インテントの Lambda 関数を使用して会話のコンテキストを設定することができます。Amazon Lex からの出力コンテキストは、Lambda 関数の入力イベントに送信されます。Lambda 関数は、そのレスポンスでコンテキストを送信することができます。詳細については、「[Lambda 関数の入力イベントとレスポンスの形式](lambda-input-response-format.md)」を参照してください。
例えば、レンタカーを予約するインテントがあり「book\$1car\$1fulfilled」という出力コンテキストを返すよう設定されているとします。インテントが達成すると、Amazon Lex は出力コンテキスト変数「book\$1car\$1fulfilled」を設定します。「book\$1car\$1filded」はアクティブなコンテキストであるため、ユーザーの発話がそのインテントを誘発する試みとして認識される限り、「book\$1car\$1filded」コンテキストを入力コンテキストとして設定したインテントが認識対象として考慮されます。これは、領収書のメール送信や予約の変更など、車を予約した後にのみ意味を持つインテントに使用できます。
## 出力コンテキスト
Amazon Lex は、インテントが実行されたときに、インテントの出力コンテキストをアクティブにします。出力コンテキストを使用して、現在のインテントをフォローアップできるインテントを制御できます。
各コンテキストは、セッションで保持されるパラメータのリストを持っています。パラメータは、履行されたインテントのスロット値です。これらのパラメータを使用して、他のインテントのスロット値を事前に入力することができます。詳細については、「[デフォルトのスロット値を使用する](context-mgmt-default.md)」を参照してください。
出力コンテキストは、コンソールまたは [PutIntent](API_PutIntent.md) オペレーションでインテントを作成するときに設定します。1 つのインテントに複数の出力コンテキストを設定することができます。インテントが実行されると、すべての出力コンテキストがアクティブになり、[PostText](API_runtime_PostText.md) または [PostContent](API_runtime_PostContent.md) 応答で返されます。
次に、コンソールを使用してインテントに出力コンテキストを割り当てる方法を示します。
![\[order_complete というラベルの付いた出力タグには、5 ターン、つまり 90 秒の有効期間があります。\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/context-output.png)
出力コンテキストを定義するときは、そのコンテキストの*有効期限 (TTL)*、つまり Amazon Lex からの応答に含まれる時間の長さまたはターン数も定義します。ある*順番*は、アプリケーションから Amazon Lex への 1 つのリクエストです。ターン数または時間が経過すると、コンテキストはアクティブでなくなります。
アプリケーションは必要に応じて、出力コンテキストを使用することができます。例えば、アプリケーションは出力コンテキストを次のように使用できます。
+ コンテキストに基づき、アプリケーションの動作を変更します。例えば、旅行アプリケーションでは、コンテキストの「book\$1car\$1filled」に対して「rental\$1hotel\$1filded」とは異なるアクションを設定することができます。
+ 出力コンテキストを、次の発話の入力コンテキストとして Amazon Lex に返します。Amazon Lex がその発話をインテントを誘発する試みと認識した場合、そのコンテキストを使用して、返されるインテントを指定されたコンテキストを持つものに限定します。
## コンテキストを入力する
入力コンテキストを設定することで、会話の中でインテントが認識されるポイントを限定することができます。入力コンテキストがないインテントは、常に認識対象となります。
インテントが応答する入力コンテキストは、コンソールまたは `PutIntent` オペレーションを使用して設定します。インテントは複数の入力コンテキストを持つことができます。次に、コンソールを使用してインテントに入力コンテキストを割り当てる方法を示します。
![\[order_complete というラベルの付いた入力タグ。\]](http://docs.aws.amazon.com/ja_jp/lex/latest/dg/images/context-input.png)
複数の入力コンテキストを持つインテントでは、インテントをトリガーするには、すべてのコンテキストがアクティブである必要があります。[PostText](API_runtime_PostText.md) オペレーション、[PostContent](API_runtime_PostContent.md) オペレーション、または [PutSession](API_runtime_PutSession.md) のオペレーションを呼び出すと、入力コンテキストを設定することができます。
インテント内のスロットは、現在アクティブなコンテキストからデフォルト値を取るように設定することができます。デフォルト値は、Amazon Lex が新しいインテントを認識するが、スロット値を受信しない場合に使用されます。スロットを定義する際に、コンテキスト名とスロット名を `#context-name.parameter-name` という形で指定します。詳細については、「[デフォルトのスロット値を使用する](context-mgmt-default.md)」を参照してください。
# デフォルトのスロット値を使用する
デフォルト値を使用する場合、ユーザーの入力によってスロットが提供されない場合に、新しいインテントで入力されるスロット値のソースを指定します。このソースは、以前のダイアログ、リクエスト、またはセッション属性、またはビルド時に設定した固定値にすることができます。
デフォルト値のソースとして、以下のものを使用することができます。
+ 以前のダイアログ(コンテキスト) - \$1context-name.parameter-name
+ セッション属性 - [attribute-name]
+ リクエスト属性 -
+ 固定値 - 前の値と一致しない値
[PutIntent](API_PutIntent.md) オペレーションでインテントにスロットを追加する場合、デフォルト値のリストを追加することができます。デフォルト値は、記載されている順序に沿って使用されます。例えば、次のような定義のスロットを持つインテントがあるとします。
```
"slots": [
{
"name": "reservation-start-date",
"defaultValueSpec": {
"defaultValueList": [
{
"defaultValue": "#book-car-fulfilled.startDate"
},
{
"defaultValue": "[reservationStartDate]"
}
]
},
Other slot configuration settings
}
]
```
インテントが認識されると、「reservation-start-date」という名前のスロットは、その値が以下のいずれかに設定されます。
1. 「book-car-fulfilled」コンテキストがアクティブな場合、「startDate」パラメータの値はデフォルト値として使用されます。
1. 「book-car-fulfilled」コンテキストがアクティブでない場合、または「startDate」パラメータが設定されていない場合、「reservationStartDate」セッション属性の値がデフォルト値として使用されます。
1. もし最初の 2 つのデフォルト値のどちらも使用されない場合、スロットにはデフォルト値がなく、Amazon Lex は通常通り値を誘発します。
スロットにデフォルト値が使われている場合、そのスロットが必要であっても誘発されることはありません。
# セッション属性の設定
*セッション属性*には、セッション中にボットとクライアントアプリケーションの間でやり取りされるアプリケーション固有の情報が含まれます。Amazon Lex は、ボットに設定されたすべての Lambda 関数にセッション属性を渡します。Lambda 関数でセッション属性が追加または更新されると、Amazon Lex からクライアントアプリケーションに新しい情報が返されます。例:
+ [演習 1: 設計図を使用して Amazon Lex ボットを作成する (コンソール)](gs-bp.md) で、サンプルボットは `price` セッション属性を使用して花の価格を保持しています。Lambda 関数は、注文された花の種類に基づいて、この属性を設定します。詳細については、「[ステップ 5 (オプション): 情報フローの詳細を確認する (コンソール)](gs-bp-details-after-lambda.md)」を参照してください。
+ [旅行を予約する](ex-book-trip.md) で、サンプルボットは `currentReservation` セッション属性を使用して、会話中のスロットタイプデータのコピーを保持し、ホテルやレンタカーを予約します。詳細については、「[情報フローの詳細](book-trip-detail-flow.md)」を参照してください。
ボットの初期化、プロンプトやレスポンスカードのカスタマイズには、Lambda 関数のセッション属性を使用します。例:
+ 初期化 - ピザの注文ボットにおいて、[PostContent](API_runtime_PostContent.md) オペレーションまたは [PostText](API_runtime_PostText.md) オペレーションへの最初の呼び出しで、クライアントアプリケーションはユーザーの場所をセッション属性として渡します。例えば、 `"Location": "111 Maple Street"`。Lambda 関数は、この情報に基づいて最寄りのピザ屋を見つけ、注文を行います。
+ プロンプトのカスタマイズ - セッション属性を参照するようにプロンプトとレスポンスカードを設定します。例: 「[FirstName] 様、トッピングは何になさいますか?」 ユーザーの名前をセッション属性 (`{"FirstName": "Jo"}`) として渡すと、Amazon Lex はプレースホルダをその名前に置き換えます。次に、カスタマイズしたプロンプトをユーザーに送信します:「Jo 様、トッピングは何になさいますか?」
セッション属性は、セッションの期間にわたって保持されます。Amazon Lex では、セッションが終わるまで、セッション属性を暗号化されたデータストアに保存します。クライアントは、[PostContent](API_runtime_PostContent.md) オペレーションまたは [PostText](API_runtime_PostText.md) オペレーションを呼び出し、`sessionAttributes` フィールドに値を設定することで、リクエストのセッション属性を作成できます。Lambda 関数は、レスポンスのセッション属性を作成できます。クライアントまたは Lambda 関数でセッション属性を作成すると、クライアントアプリケーションで Amazon Lex へのリクエストに `sessionAttribute` フィールドを指定しない場合に、いつでも保存された属性値が使用されます。
例えば、2 つのセッション属性 `{"x": "1", "y": "2"}` があるとします。クライアントが `PostContent` オペレーションまたは `PostText` オペレーションを呼び出すときに `sessionAttributes` フィールドを指定しない場合、Amazon Lex は保存されたセッション属性 (`{"x": 1, "y": 2}`) を使用して Lambda 関数を呼び出します。Lambda 関数からセッション属性が返されない場合、Amazon Lex は保存されたセッション属性をクライアントアプリケーションに返します。
クライアントアプリケーションまたは Lambda 関数のいずれかがセッション属性を渡すと、Amazon Lex は保存されたセッション属性を更新します。既存の値 ` {"x": 2}` などを渡すと、保存された値が更新されます。新しい一連のセッション属性 (`{"z": 3}` など) を渡すと、既存の値は削除され、新しい値のみが保持されます。空のマップ `{}` を渡すと、保存された値が消去されます。
セッション属性を Amazon Lex に送信するには、属性の文字列間マップを作成します。セッション属性のマッピング方法を以下に示します。
```
{
"attributeName": "attributeValue",
"attributeName": "attributeValue"
}
```
`PostText` オペレーションの場合は、次に示すように、[`sessionAttributes`] フィールドを使用してリクエストの本文にマップを挿入します。
```
"sessionAttributes": {
"attributeName": "attributeValue",
"attributeName": "attributeValue"
}
```
`PostContent` オペレーションの場合は、マップを base64 エンコードし、それを `x-amz-lex-session-attributes` ヘッダーとして送信します。
バイナリまたは構造化されたデータをセッション属性で送信する場合は、最初にデータを単純な文字列に変換する必要があります。詳細については、「[複雑な属性の設定](context-mgmt-complex-attributes.md)」を参照してください。
# リクエスト属性の設定
*リクエスト属性*は、リクエスト固有の情報を示し、現在のリクエストにのみ適用されます。クライアントアプリケーションは、この情報を Amazon Lex に送信します。セッション全体を通しては保持する必要がない情報は、リクエスト属性を使用して渡します。リクエスト属性は、独自に作成することも、事前定義されたものを使用することもできます。リクエスト属性を送信するには、[PostContent](API_runtime_PostContent.md) の `x-amz-lex-request-attributes` ヘッダーを使用するか、[PostText](API_runtime_PostText.md) リクエストの `requestAttributes` フィールドを使用します。セッション属性とは異なり、リクエスト属性は複数のリクエストにわたって保持されないため、`PostContent` レスポンスや `PostText` レスポンスで返されることはありません。
**注記**
複数のリクエストにわたって保持される情報を送信するには、セッション属性を使用します。
名前空間 `x-amz-lex:` は、事前定義されたリクエスト属性用に予約されています。リクエスト属性をプレフィックス `x-amz-lex:` で作成しないでください。
## 事前定義されたリクエスト属性の設定
Amazon Lex には、ボットに送信される情報の処理方法を管理するための事前定義されたリクエスト属性があります。事前定義されたリクエスト属性は、セッション全体にわたって保持されないため、リクエストごとに属性を送信する必要があります。すべての事前定義された属性は `x-amz-lex:` 名前空間にあります。
Amazon Lex には、以下の定義済み属性に加えて、メッセージングプラットフォーム用の定義済み属性が用意されています。これらの属性のリストについては、「[メッセージングプラットフォームで Amazon Lex ボットをデプロイする](example1.md)」を参照してください。
### レスポンスタイプの設定
異なる機能を持つクライアントアプリケーションが 2 つある場合は、レスポンスのメッセージ形式の制限が必要な場合もあります。例えば、ウェブクライアントに送信するメッセージをプレーンテキストに制限し、モバイルクライアントではプレーンテキストと音声合成マークアップ言語 (SSML) の両方を使用できるようにしたいといった場合も考えられます。[PostContent](API_runtime_PostContent.md) と [PostText](API_runtime_PostText.md) オペレーションが返すメッセージの形式を設定するには、`x-amz-lex:accept-content-types"` リクエストの属性を使用します。
次のメッセージタイプを任意に組み合わせて属性を設定することができます。
+ `PlainText` - メッセージには UTF-8 形式テキストが含まれています。
+ `SSML` - メッセージには音声出力のテキスト形式が含まれています。
+ `CustomPayload` - メッセージにはクライアント向けに作成したカスタム形式が含まれています。アプリケーションのニーズを満たすようにペイロードを定義することができます。
Amazon Lex はレスポンスの [`Message`] フィールドで指定したタイプを使用するメッセージのみを返します。カンマで区切れば複数の値を設定できます。メッセージグループを使用している場合は、各メッセージグループで少なくとも 1 つ指定したタイプのメッセージが含まれている必要があります。それ以外の場合は、`NoUsableMessageException` エラーが発生します。詳細については、「[メッセージグループ](howitworks-manage-prompts.md#message-groups)」を参照してください。
**注記**
`x-amz-lex:accept-content-types` リクエストの属性は、HTML 本文のコンテンツには影響しません。`PostText` オペレーションのレスポンスの内容は常に UTF-8 形式テキストです。`PostContent` オペレーションレスポンスの本文には、リクエストの `Accept` ヘッダーで設定した形式のデータが含まれています。
### 優先タイムゾーンの設定
ユーザーのタイムゾーンを基準として日付を解決するようにタイムゾーンを設定するには、`x-amz-lex:time-zone` リクエスト属性を使用します。`x-amz-lex:time-zone` 属性にタイムゾーンを指定しないと、ボットで使用しているリージョンに応じたデフォルトのタイムゾーンが使用されます。
| リージョン | デフォルトのタイムゾーン |
| --- | --- |
| 米国東部 (バージニア北部) | America/New\$1York |
| 米国西部 (オレゴン) | America/Los\$1Angeles |
| アジアパシフィック (シンガポール) | Asia/Singapore |
| アジアパシフィック (シドニー) | Australia/Sydney |
| アジアパシフィック (東京) | Asia/Tokyo |
| 欧州 (フランクフルト) | Europe/Berlin |
| 欧州 (アイルランド) | Europe/Dublin |
| 欧州 (ロンドン) | Europe/London |
例えば、「何日にパッケージを配達しましょうか?」というプロンプトに対して、ユーザーがレスポンスで `tomorrow` と回答した場合、パッケージを配達する実際の*日付*は、ユーザーのタイムゾーンによって異なります。例えば、ニューヨークの 9 月 16 日 01:00 時は、ロサンゼルスの 9 月 15 日 22:00 時です。米国東部（バージニア北部 リージョンにいる人物が、デフォルトタイムゾーンを使用してパッケージの配達日を「明日」に指定した場合、パッケージは 16 日ではなく、17 日に配達されます。`x-amz-lex:time-zone` リクエスト属性を `America/Los_Angeles` に設定すると、パッケージは 16 日に配達されます。
属性は、IANA (Internet Assigned Number Authority) のタイムゾーン名のいずれかに設定できます。タイムゾーン名のリストについては Wikipedia の「[List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)」をご覧ください。
## ユーザー定義のリクエスト属性の設定
*ユーザー定義のリクエスト属性*は各リクエストでボットに送信するデータです。この情報を送信するには、`PostContent` リクエストの `amz-lex-request-attributes` ヘッダーを使用するか、`PostText` リクエストの `requestAttributes` フィールドを使用します。
リクエスト属性を Amazon Lex に送信するには、属性の文字列間マップを作成します。リクエスト属性のマッピング方法を以下に示します。
```
{
"attributeName": "attributeValue",
"attributeName": "attributeValue"
}
```
`PostText` オペレーションの場合は、次に示すように、[`requestAttributes`] フィールドを使用してリクエストの本文にマップを挿入します。
```
"requestAttributes": {
"attributeName": "attributeValue",
"attributeName": "attributeValue"
}
```
`PostContent` オペレーションの場合は、マップを base64 エンコードし、それを `x-amz-lex-request-attributes` ヘッダーとして送信します。
バイナリまたは構造化されたデータをリクエスト属性で送信する場合は、最初にデータを単純な文字列に変換する必要があります。詳細については、「[複雑な属性の設定](context-mgmt-complex-attributes.md)」を参照してください。
# セッションタイムアウトの設定
会話セッションが終了するまで、Amazon Lex はコンテキスト情報 (スロットデータとセッション属性) を保持します。ボットのセッションの長さを制御するには、セッションタイムアウトを設定します。デフォルトでは、セッションの所要時間は 5 分ですが、0〜1,440 分 (24 時間) の間で任意の所要時間を指定できます。
例えば、`ShoeOrdering` や `OrderShoes` などのインテントをサポートする `GetOrderStatus` ボットを作成したとします。Amazon Lex は、ユーザーのインテントが靴の注文であることを検出すると、スロットデータを求めます。例えば、靴のサイズ、色、ブランドなどを求めます。ユーザーがスロットデータの一部のみを指定して靴の購入を完了しない場合、Amazon Lex はセッションが終わるまで、すべての指定されたスロットデータとセッション属性を記憶します。ユーザーは、セッションの有効期限が切れる前にセッションに戻った場合、残りのスロットデータを指定して購入を完了できます。
セッションタイムアウトは、ボットの作成時に Amazon Lex コンソールで設定します。AWS Command Line Interface (AWS CLI) または API では、[PutBot](API_PutBot.md) オペレーションを使用してボットを作成または更新するときに、[[idleSessionTTLInSeconds]](https://docs.aws.amazon.com/lex/latest/dg/API_PutBot.html#lex-PutBot-request-idleSessionTTLInSeconds) フィールドを設定してタイムアウトを設定します。
# インテント間での情報の共有
Amazon Lex では、インテント間で情報を共有できます。インテント間で共有するには、セッション属性を使用します。
例えば、`ShoeOrdering` ボットのユーザーが靴の注文を開始したとします。ボットは、ユーザーと会話することで靴のサイズ、色、ブランドなどのスロットデータを集めます。ユーザーが注文を行うと、その注文を処理する Lambda 関数では、注文番号を含む `orderNumber` セッション属性を設定します。注文のステータスを取得するために、ユーザーは `GetOrderStatus` インテントを使用します。ボットは、ユーザーに発注番号や注文日などのスロットデータを求めます。ボットは、必要な情報を入手すると、注文のステータスを返します。
ユーザーが同じセッション中にインテントを変更すると予想される場合は、最新の注文のステータスを返すようにボットを設計できます。ユーザーに対して注文情報を再度求める代わりに、`orderNumber` セッション属性を使用してインテント間で情報を共有し、`GetOrderStatus` インテントを達成できます。ボットでは、そのためにユーザーの最後の注文のステータスを返します。
クロスインテント情報共有の例については、「[旅行を予約する](ex-book-trip.md)」を参照してください。
# 複雑な属性の設定
セッション属性およびリクエスト属性は、属性と値の文字列間マップです。多くの場合、文字列マップを使用してクライアントアプリケーションとボットの間で属性値を転送できます。ただし、場合によっては、文字列マップに容易に変換できないバイナリデータや複雑な構造の転送が必要になることもあります。例えば、次の JSON オブジェクトは米国の最も人口が多い 3 つの都市の配列を示しています。
```
{
"cities": [
{
"city": {
"name": "New York",
"state": "New York",
"pop": "8537673"
}
},
{
"city": {
"name": "Los Angeles",
"state": "California",
"pop": "3976322"
}
},
{
"city": {
"name": "Chicago",
"state": "Illinois",
"pop": "2704958"
}
}
]
}
```
このデータの配列は、文字列間マップに適切に変換されません。このような場合は、オブジェクトを単純な文字列に変換し、その文字列を [PostContent](API_runtime_PostContent.md) オペレーションと [PostText](API_runtime_PostText.md) オペレーションを使用してボットに送信できます。
例えば、JavaScript を使用している場合は、`JSON.stringify` オペレーションを使用してオブジェクトを JSON に変換し、`JSON.parse` オペレーションを使用して JSON テキストを JavaScript オブジェクトに変換します。
```
// To convert an object to a string.
var jsonString = JSON.stringify(object, null, 2);
// To convert a string to an object.
var obj = JSON.parse(JSON string);
```
セッション属性を `PostContent` オペレーションで送信するには、次の JavaScript コードに示すように、セッション属性を base64 エンコードしてからリクエストヘッダーに追加する必要があります。
```
var encodedAttributes = new Buffer(attributeString).toString("base64");
```
バイナリデータを `PostContent` オペレーションと `PostText` オペレーションに送信する場合は、最初にバイナリデータを base64 エンコードされた文字列に変換し、次にその文字列をセッション属性の値として送信します。
```
"sessionAttributes" : {
"binaryData": "base64 encoded data"
}
```
# 信頼スコアの使用
ユーザーが発話を行うと、Amazon Lex は自然言語理解 (NLU) を使用してユーザーの要求を理解し、適切なインテントを返します。デフォルトでは、Amazon Lex は、ボットによって定義された最も可能性の高いインテントを返します。
場合によっては、Amazon Lex が最も可能性の高いインテントを判断するのが困難なことがあります。例えば、ユーザーが曖昧な発話をした場合や、似たようなインテントが2つある場合などです。適切なインテントを決定するために、代替えインテントのリストで、ドメイン知識と*信頼性スコア*を組み合わせることができます。信頼スコアは、Amazon Lex が提供する評価で、インテントが正しいインテントであるという確信度を示します。
代替えインテントの 2 つのインテントの差を判断するには、信頼度スコアを比較します。例えば、あるインテントの信頼スコアが 0.95 で、別のインテントのスコアが0.65の場合、最初のインテントはおそらく正しいでしょう。ただし、あるインテントのスコアが 0.75 で、別のインテントのスコアが 0.72 の場合、2 つのインテントの間には曖昧さがあり、アプリケーションでドメインナレッジを使用して識別できます。
また、信頼度スコアを使用して、インテントの発話に対する変更がボットの動作に違いをもたらすかどうかを判断するテストアプリケーションを作成することもできます。例えば、一連の発話を使用してボットのインテントの信頼度スコアを取得し、新しい発話でインテントを更新することができます。その後、信頼スコアをチェックして、改善があったかどうかを確認することができます。
Amazon Lex が返す信頼スコアは、比較のための値です。絶対的なスコアとして信頼するべきではありません。この値は、Amazon Lex の改善に基づいて変更される場合があります。
信頼度スコアを使用した場合、Amazon Lex は、各応答において、最も可能性の高いインテントと、最大 4 つの代替インテントを、それぞれの関連スコアとともに返します。すべての信頼度スコアがしきい値よりも小さい場合、Amazon Lex は `AMAZON.FallbackIntent`、`AMAZON.KendraSearchIntent`、またはその両方 (設定されている場合) を含みます。デフォルトのしきい値を使用することもできますし、独自のしきい値を設定することもできます。
次のJSONコードは、[PostText](API_runtime_PostText.md) オペレーションのレスポンスに含まれる `alternativeIntents` フィールドを示しています。
```
"alternativeIntents": [
{
"intentName": "string",
"nluIntentConfidence": {
"score": number
},
"slots": {
"string" : "string"
}
}
],
```
ボットを作成または更新するときにしきい値を設定します。API または Amazon Lex コンソールのいずれかを使用できます。以下にリストされているリージョンでは、精度の向上と信頼度スコアを有効にするためにオプトインする必要があります。コンソールでは、**「詳細オプション」**(Advanced Options) セクションで [信頼スコア] (confidence scores) を選択します。API を使用して、[PutBot](API_PutBot.md) オペレーションを呼び出す際に `enableModelImprovements` パラメータを設定します。
+ 米国東部 (バージニア北部) (us-east-1)
+ 米国西部 (オレゴン) (us-west-2)
+ アジアパシフィック (シドニー) (ap-southeast-2)
+ 欧州 (アイルランド) (eu-west-1)
その他の地域では、精度の向上と信頼性スコアのサポートがデフォルトで利用できます。
信頼度しきい値を変更するには、コンソールで設定するか、[PutBot](API_PutBot.md) オペレーションで設定します。しきい値は 1.00 から 0.00 の間の数値である必要があります。
コンソールを使用するには、ボットの作成時または更新時に信頼度のしきい値を設定します。
**ボットの作成時に信頼度しきい値を設定するには (コンソール)**
+ **[Create your bot]** (ボットの作成) で、**[Confidence score threshold]** (信頼度スコアのしきい値) フィールドに値を入力します。
**信頼性のしきい値を更新するには (コンソール)**
1. ボットの一覧から、エクスポートするボットを選択します。
1. **[Settings]** (設定) タブを選択します。
1. 左側のナビゲーションペインで **[General]** (全般) を選択します。
1. **[Confidence score threshold]** (信頼スコアのしきい値) フィールドの値を更新します。
**信頼度しきい値 (SDK) を設定または更新するには**
+ [PutBot](API_PutBot.md) のオペレーションの `nluIntentConfidenceThreshold` のパラメータを設定します。次の JSON コードは、パラメータが設定されていることを示しています。
```
"nluIntentConfidenceThreshold": 0.75,
```
## セッションの管理
Amazon Lex がユーザーとの会話で使用するインテントを変更するには、ダイアログコードフックの Lambda 関数からの応答を使用するか、カスタムアプリケーションでセッション管理 API を使用します。
### Lambda 関数を使用する
Lambda 関数を使用する場合、Amazon Lex は関数への入力を含む JSON 構造で呼び出します。JSON 構造は、Amazon Lex がユーザーの発話の最も可能性の高いインテントとして特定したインテントを含む、`currentIntent` と呼ばれるフィールドを含んでいます。JSON 構造は、ユーザーのインテントを満たす可能性のある最大 4 つの追加インテントを含む `alternativeIntents` フィールドも含んでいます。各インテントには、Amazon Lex がそのインテントに割り当てた信頼度スコアを含む `nluIntentConfidenceScore` というフィールドが含まれます。
別のインテントを使用するには、Lambda 関数の `ConfirmIntent` または `ElicitSlot` ダイアログアクションで指定します。
詳細については、「[Lambda 関数を使用する](using-lambda.md)」を参照してください。
### セッション管理 API を使用する
現在のインテントと異なるインテントを使用するには、[PutSession](API_runtime_PutSession.md) オペレーションを使用します。例えば、Amazon Lex が選択したインテントよりも、最初の選択肢が望ましいと判断した場合、`PutSession` オペレーションを使用してインテントを変更し、ユーザーが次に対話するインテントが選択したものになるようにすることが可能です。
詳細については、「[Amazon Lex API を使用したセッションの管理](how-session-api.md)」を参照してください。
# 会話ログ
*会話ログ*を有効にして、ボットとのやりとりを保存します。これらのログを使用して、ボットのパフォーマンスを確認し、会話に関する問題のトラブルシューティングを行うことができます。[PostText](API_runtime_PostText.md) オペレーションのテキストをログに記録できます。[PostContent](API_runtime_PostContent.md) オペレーションのテキストとオーディオの両方を記録できます。会話ログを有効にすると、ユーザーとボットとの会話の詳細ビューが表示されます。
例えば、ボットとのセッションにはセッション ID があります。この ID を使用して、ユーザー発話および対応するボットの応答を含む会話の文字起こしを取得できます。また、発話のインテント名やスロット値などのメタデータも取得します。
**注記**
児童オンラインプライバシー保護法 (COPPA) の対象となるボットでは、会話ログを使用することはできません。
会話ログは、エイリアスに対して設定されます。各エイリアスで、テキストログとオーディオログに対して異なる設定を使用できます。テキストログ、オーディオログ、またはその両方をエイリアスごとに有効にできます。テキストログでは、テキスト入力、オーディオ入力の書き起こし、および関連するメタデータが CloudWatch Logs に保存されます。オーディオログは、Amazon S3 にオーディオ入力を保存します。 AWS KMS カスタマー管理の CMKs を使用して、テキストログとオーディオログの暗号化を有効にできます。
ログ記録を設定するには、コンソールまたは [PutBotAlias](API_PutBotAlias.md) オペレーションを使用します。ボットの `$LATEST` エイリアス、または Amazon Lex コンソールで利用可能なテストボットの会話をログに記録することはできません。エイリアスの会話ログを有効にすると、[PostContent](API_runtime_PostContent.md)、またはそのエイリアスの [PostText](API_runtime_PostText.md) オペレーションが、設定された CloudWatch Logs ロググループまたは S3 バケット内のテキストまたは音声発話をログに記録します。
**Topics**
+ [会話ログの IAM ポリシー](conversation-logs-policies.md)
+ [会話ログの設定](conversation-logs-configure.md)
+ [会話ログの暗号化](conversation-logs-encrypting.md)
+ [Amazon CloudWatch Logs のテキストログの表示](conversation-logs-cw.md)
+ [Amazon S3 のオーディオログへのアクセス](conversation-logs-s3.md)
+ [CloudWatch メトリクスを使用した会話ログのステータスのモニタリング](conversation-logs-monitoring.md)
# 会話ログの IAM ポリシー
選択したログ記録のタイプに応じて、Amazon Lex には、ログを保存するために Amazon CloudWatch Logs と Amazon Simple Storage Service (S3) バケットを使用するアクセス許可が必要です。Amazon Lex がこれらのリソースにアクセスできるようにするには、 AWS Identity and Access Management ロールとアクセス許可を作成する必要があります。
## 会話ログ用の IAM ロールとポリシーの作成
会話ログを有効にするには、CloudWatch Logs および Amazon S3 の書き込み権限を付与する必要があります。S3 オブジェクトのオブジェクト暗号化を有効にする場合は、オブジェクトの暗号化に使用される AWS KMS キーへのアクセス許可を付与する必要があります。
IAM AWS マネジメントコンソール、IAM API、または を使用して AWS Command Line Interface 、ロールとポリシーを作成できます。これらの手順では AWS CLI 、 を使用してロールとポリシーを作成します。コンソールを使用しての ポリシーの作成の詳細については、*「AWS Identity and Access Management User Guide」*(AWS Identity and Access Management ユーザーガイド) の[「Creating policies on the JSON tab」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor)(JSON タブでポリシーを作成する) を参照してください。
**注記**
次のコードは、Linux と MacOS 用にフォーマットされています。Windows の場合、Linux 行連結記号 (\$1) をキャレット (^) に置き換えます。
**会話ログの IAM ロールを作成するには**
1. **LexConversationLogsAssumeRolePolicyDocument.json** という現在のディレクトリにドキュメントを作成し、次のコードを追加して保存します。このポリシードキュメントは、信頼されたエンティティとしてロールに Amazon Lex を追加します。これにより、Lex は、会話ログ用に設定されたリソースにログを配信するロールを引き受けることができます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lex.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. で AWS CLI、次のコマンドを実行して、会話ログの IAM ロールを作成します。
```
aws iam create-role \
--role-name role-name \
--assume-role-policy-document file://LexConversationLogsAssumeRolePolicyDocument.json
```
次に、Amazon Lex が CloudWatch Logs に書き込むことができるロールにポリシーを作成し、アタッチします。
**会話テキストを CloudWatch Logs にログ記録するための IAM ポリシーを作成するには**
1. **LexConversationLogsCloudWatchLogsPolicy.json** という現在のディレクトリにドキュメントを作成し、次の IAM ポリシーを追加して保存します。
1. で AWS CLI、CloudWatch Logs ロググループに書き込みアクセス許可を付与する IAM ポリシーを作成します。
```
aws iam create-policy \
--policy-name cloudwatch-policy-name \
--policy-document file://LexConversationLogsCloudWatchLogsPolicy.json
```
1. 会話ログ用に作成した IAM ロールにポリシーをアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::account-id:policy/cloudwatch-policy-name \
--role-name role-name
```
オーディオを S3 バケットにログ記録する場合は、Amazon Lex がバケットに書き込むことを可能にするポリシーを作成します。
**S3 バケットへのオーディオログ記録のための IAM ポリシーを作成するには**
1. **LexConversationLogsS3Policy.json** という現在のディレクトリにドキュメントを作成し、次のポリシーを追加して保存します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}
```
------
1. で AWS CLI、S3 バケットへの書き込みアクセス許可を付与する IAM ポリシーを作成します。
```
aws iam create-policy \
--policy-name s3-policy-name \
--policy-document file://LexConversationLogsS3Policy.json
```
1. 会話ログ用に作成したロールにポリシーをアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::account-id:policy/s3-policy-name \
--role-name role-name
```
## IAM ロールを渡すアクセス許可の付与
コンソール、、 AWS Command Line Interfaceまたは AWS SDK を使用して会話ログに使用する IAM ロールを指定する場合、会話ログ IAM ロールを指定するユーザーには、ロールを Amazon Lex に渡すアクセス許可が必要です。ユーザーが Amazon Lex サービスにロールを渡すには、ユーザー、ロール、またはグループに `PassRole` アクセス許可を付与する必要があります。
次のポリシーは、ユーザー、ロール、またはグループに付与するアクセス許可を定義します。`iam:AssociatedResourceArn` 条件キーと `iam:PassedToService` 条件キーを使用して、アクセス許可の範囲を制限できます。詳細については、[「 ユーザーガイド」の AWS 「 サービスにロールを渡すアクセス許可をユーザーに付与](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)する」および[「IAM および AWS STS 条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html)」を参照してください。 *AWS Identity and Access Management *
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/role-name",
"Condition": {
"StringEquals": {
"iam:PassedToService": "lex.amazonaws.com"
},
"StringLike": {
"iam:AssociatedResourceARN": "arn:aws:lex:region:123456789012:bot:bot-name:bot-alias"
}
}
}
]
}
```
------
# 会話ログの設定
会話ログを有効または無効にするには、コンソールまたは `PutBotAlias` オペレーションの `conversationLogs` フィールドを使用します。オーディオログ、テキストログ、またはその両方をオンまたはオフにできます。新しいボットセッションでログ記録が開始されます。ログ設定への変更は、アクティブなセッションでは反映されません。
テキストログを保存するには、 AWS アカウントで Amazon CloudWatch Logs ロググループを使用します。任意の有効なロググループを使用できます。ロググループは、Amazon Lex ボットと同じリージョンに存在する必要があります。CloudWatch Logs ロググループの詳細については、*「Amazon CloudWatch Logs User Guide」*(Amazon CloudWatch Logs ユーザーガイド) の[「Working with Log Groups and Log Streams」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)(ロググループとログストリームの使用) を参照してください。
オーディオログを保存するには、 AWS アカウントで Amazon S3 バケットを使用します。任意の有効な S3 バケットを使用できます。バケットは Amazon Lex ボットと同じリージョンにある必要があります。S3 バケットの作成の詳細については、*「Amazon Simple Storage Service Getting Started Guide」*(Amazon Simple Storage Service 入門ガイド) の[「Create a Bucket」](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html)(バケットの作成) を参照してください。
設定済みのロググループまたはバケットへの Amazon Lex による書き込みを有効にするポリシーのある IAM ロールを指定する必要があります。詳細については、「[会話ログ用の IAM ロールとポリシーの作成](conversation-logs-policies.md#conversation-logs-role-and-policy)」を参照してください。
を使用してサービスにリンクされたロールを作成する場合は AWS Command Line Interface、次のように `custom-suffix`オプションを使用してロールにカスタムサフィックスを追加する必要があります。
```
aws iam create-service-linked-role \
--aws-service-name lex.amazon.aws.com \
--custom-suffix suffix
```
会話ログを有効にするために使用する IAM ロールには、`iam:PassRole` アクセス許可が必要です。以下のポリシーをロールにアタッチする必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/role"
}
]
}
```
------
## 会話ログの有効化
**コンソールを使用してログを有効にするには**
1. Amazon Lex コンソール ([https://console.aws.amazon.com/lex](https://console.aws.amazon.com/lex)) を開きます。
1. リストからボットを選択します。
1. **[Settings]** (設定) タブを選択し、左側のメニューから **[Conversation logs]** (会話ログ) を選択します。
1. エイリアスのリストで、会話ログを設定するエイリアスの設定アイコンを選択します。
1. テキスト、オーディオ、またはその両方をログに記録するかどうかを選択します。
1. テキストログの場合は、Amazon CloudWatch Logs のロググループ名を入力します。
1. オーディオのログ記録の場合は、S3 バケット情報を入力します。
1. オプション。オーディオログを暗号化するには、暗号化に使用する AWS KMS キーを選択します。
1. 必要な権限を持つ IAM ロールを選択します。
1. **[Save]** (保存) を選択して、会話のログ記録を開始します。
**API を使用してテキストログを有効にするには**
1. `conversationLogs` フィールドの `logSettings` メンバーのエントリを使用して [PutBotAlias](API_PutBotAlias.md) オペレーションを呼び出す
+ `destination` メンバーを `CLOUDWATCH_LOGS` に設定する
+ `logType` メンバーを `TEXT` に設定する
+ ログの送信先である CloudWatch Logs ロググループの Amazon リソースネーム (ARN) に `resourceArn` メンバーを設定する
1. `conversationLogs` フィールドの `iamRoleArn` メンバーを、指定したリソースで会話ログを有効にするために必要なアクセス権限を持つ IAM ロールの Amazon リソースネーム (ARN) に設定します。
**API を使用してオーディオログを有効にするには**
1. `conversationLogs` フィールドの `logSettings` メンバーのエントリを使用して [PutBotAlias](API_PutBotAlias.md) オペレーションを呼び出す
+ `destination` メンバーを `S3` に設定する
+ `logType` メンバーを `AUDIO` に設定する
+ `resourceArn` メンバーをオーディオログが保存されている Amazon S3 バケットの ARN に設定する
+ オプション。特定の AWS KMS キーを使用してオーディオログを暗号化するには、暗号化に使用されるキーの ARN `kmsKeyArn`のメンバーを設定します。
1. `conversationLogs` フィールドの `iamRoleArn` メンバーを、指定したリソースで会話ログを有効にするために必要なアクセス権限を持つ IAM ロールのAmazon リソースネーム (ARN) に設定します。
## 会話ログの無効化
**コンソールを使用してログをオフにするには**
1. Amazon Lex コンソール ([https://console.aws.amazon.com/lex](https://console.aws.amazon.com/lex)) を開きます。
1. リストからボットを選択します。
1. **[Settings]** (設定) タブを選択し、左側のメニューから **[Conversation logs]** (会話ログ) を選択します。
1. エイリアスのリストで、会話ログを設定するエイリアスの設定アイコンを選択します。
1. ログ記録をオフにするには、テキスト、オーディオ、またはその両方からチェックを外します。
1. 会話のログ記録を停止するには、[**Save**] (保存) を選択します。
**API を使用してログをオフにするには**
+ `conversationLogs` フィールドを使用しないで `PutBotAlias` オペレーションを呼び出します。
**API を使用してテキストログを無効にするには**
+
+ オーディオをログ記録する場合
+ `AUDIO` の `logSettings` エントリのみを使用して [PutBotAlias](API_PutBotAlias.md) オペレーションを呼び出します。
+ `PutBotAlias` オペレーションの呼び出しには、`TEXT` の `logSettings` エントリを含めることはできません。
+ オーディオをログ記録しない場合
+ `conversationLogs` フィールドを使用しないで [PutBotAlias](API_PutBotAlias.md) オペレーションを呼び出します。
**API を使用してオーディオログをオフにするには**
+
+ テキストをログ記録する場合
+ `TEXT` の `logSettings` エントリのみを使用して [PutBotAlias](API_PutBotAlias.md) オペレーションを呼び出します。
+ `PutBotAlias` オペレーションの呼び出しには、`AUDIO` の `logSettings` エントリを含めることはできません。
+ テキストをログ記録していない場合
+ `conversationLogs` フィールドを使用しないで [PutBotAlias](API_PutBotAlias.md) オペレーションを呼び出します。
# 会話ログの暗号化
暗号化を使用すると、会話ログの内容を保護できます。テキストログとオーディオログの場合、 AWS KMS カスタマー管理の CMKs を使用して CloudWatch Logs ロググループと S3 バケット内のデータを暗号化できます。
**注記**
Amazon Lex は、シンメトリック CMKのみをサポートします。非対称 CMK を使用して、データを暗号化することはできません。
Amazon Lex がテキストログに使用する CloudWatch Logs ロググループの AWS KMS キーを使用して暗号化を有効にします。ログ設定で AWS KMS キーを指定して、ロググループの AWS KMS 暗号化を有効にすることはできません。詳しくは、*Amazon CloudWatch Logs ユーザーガイド*の「[AWS KMSを使用して CloudWatch Logs のログデータを暗号化する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)」を参照してください。
オーディオログの場合、S3 バケットでデフォルトの暗号化を使用するか、 AWS KMS キーを指定してオーディオオブジェクトを暗号化します。S3 バケットがデフォルトの暗号化を使用している場合でも、オーディオオブジェクトを暗号化するために別の AWS KMS キーを指定できます。詳細については、*Amazon Simple Storage Service 開発者ガイド*の「[S3 バケットの Amazon S3 デフォルト暗号化](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html)」を参照してください。
オーディオログの暗号化を選択した場合、Amazon Lex には アクセス AWS KMS 許可が必要です。会話ログに使用する IAM ロールに追加のポリシーをアタッチする必要があります。S3 バケットでデフォルトの暗号化を使用する場合、ポリシーはそのバケットに設定された AWS KMS キーへのアクセスを許可する必要があります。オーディオログ設定で AWS KMS キーを指定する場合、 はそのキーへのアクセスを許可する必要があります。
会話ログのロールを作成していない場合は、「[会話ログの IAM ポリシー](conversation-logs-policies.md)」を参照してください。
**オーディオログの暗号化に AWS KMS キーを使用するための IAM ポリシーを作成するには**
1. **LexConversationLogsKMSPolicy.json** という現在のディレクトリにドキュメントを作成し、次のポリシーを追加して保存します。
1. で AWS CLI、オーディオログの暗号化に AWS KMS キーを使用するアクセス許可を付与する IAM ポリシーを作成します。
```
aws iam create-policy \
--policy-name kms-policy-name \
--policy-document file://LexConversationLogsKMSPolicy.json
```
1. 会話ログ用に作成したロールにポリシーをアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::account-id:policy/kms-policy-name \
--role-name role-name
```
# Amazon CloudWatch Logs のテキストログの表示
Amazon Lex では、Amazon CloudWatch Logs で会話のテキストログが保存されます。ログを表示するには、CloudWatch Logs コンソールまたは API を使用します。詳細については、「*Amazon CloudWatch Logs ユーザーガイド*」の「[フィルターパターンを使用したログデータの検索](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SearchDataFilterPattern.html)」と「[CloudWatch Logs インサイトクエリ構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)」を参照してください。
**Amazon Lex コンソールを使用してログを表示するには**
1. Amazon Lex コンソール ([https://console.aws.amazon.com/lex](https://console.aws.amazon.com/lex)) を開きます。
1. リストからボットを選択します。
1. [**Settings**] (設定) タブを選択し、左側のメニューから [**Conversation logs**] (会話ログ) を選択します。
1. **[Text logs]** (テキストログ) の下のリンクを選択して、エイリアスのログを CloudWatch コンソールに表示します。
CloudWatch コンソールまたは API を使用してログエントリを表示することもできます。ログエントリを見つけるには、エイリアスに対して設定したロググループに移動します。Amazon Lex コンソールでログのログストリームプレフィックスを見つけるか、[GetBotAlias](API_GetBotAlias.md) オペレーションを使用します。
ユーザー発話のログエントリは、複数のログストリームにあります。会話内の発話には、指定されたプレフィックスを持つログストリームの 1 つにエントリがあります。ログストリームのエントリには、次の情報が含まれます。
```
{
"messageVersion": "1.0",
"botName": "bot name",
"botAlias": "bot alias",
"botVersion": "bot version",
"inputTranscript": "text used to process the request",
"botResponse": "response from the bot",
"intent": "matched intent",
"nluIntentConfidence": "number",
"slots": {
"slot name": "slot value",
"slot name": null,
"slot name": "slot value"
...
},
"alternativeIntents": [
{
"name": "intent name",
"nluIntentConfidence": "number",
"slots": {
"slot name": slot value,
"slot name": null,
"slot name": slot value
...
}
},
{
"name": "intent name",
"nluIntentConfidence": number,
"slots": {}
}
],
"developerOverride": "true" | "false",
"missedUtterance": true | false,
"inputDialogMode": "Text" | "Speech",
"requestId": "request ID",
"s3PathForAudio": "S3 path to audio file",
"userId": "user ID",
"sessionId": "session ID",
"sentimentResponse": {
"sentimentScore": "{Positive: number, Negative: number, Neutral: number, Mixed: number}",
"sentimentLabel": "Positive" | "Negative" | "Neutral" | "Mixed"
},
"slotToElicit": "slot name",
"dialogState": "ElicitIntent" | "ConfirmIntent" | "ElicitSlot" | "Fulfilled" | "ReadyForFulfillment" | "Failed",
"responseCard": {
"genericAttachments": [
...
],
"contentType": "application/vnd.amazonaws.card.generic",
"version": 1
},
"locale": "locale",
"timestamp": "ISO 8601 UTC timestamp",
"kendraResponse": {
"totalNumberOfResults": number,
"resultItems": [
{
"id": "query ID",
"type": "DOCUMENT" | "QUESTION_ANSWER" | "ANSWER",
"additionalAttributes": [
{
...
}
],
"documentId": "document ID",
"documentTitle": {
"text": "title",
"highlights": null
},
"documentExcerpt": {
"text": "text",
"highlights": [
{
"beginOffset": number,
"endOffset": number,
"topAnswer": true | false
}
]
},
"documentURI": "URI",
"documentAttributes": []
}
],
"facetResults": [],
"sdkResponseMetadata": {
"requestId": "request ID"
},
"sdkHttpMetadata": {
"httpHeaders": {
"Content-Length": "number",
"Content-Type": "application/x-amz-json-1.1",
"Date": "date and time",
"x-amzn-RequestId": "request ID"
},
"httpStatusCode": 200
},
"queryId": "query ID"
},
"sessionAttributes": {
"attribute name": "attribute value"
...
},
"requestAttributes": {
"attribute name": "attribute value"
...
}
}
```
ログエントリの内容は、トランザクションの結果、およびボットとリクエストの設定によって異なります。
+ `missedUtterance` フィールドが `true` の場合、`intent`、`slots`、および `slotToElicit` フィールドはエントリに表示されません。
+ オーディオログが無効になっている場合、または `inputDialogMode` フィールドが `Text` の場合、`s3PathForAudio` フィールドは表示されません。
+ `responseCard` フィールドは、ボットの応答カードを定義した場合にのみ表示されます。
+ `requestAttributes` マップは、リクエストでリクエスト属性を指定した場合にのみ表示されます。
+ この `kendraResponse` フィールドが存在するのは、`AMAZON.KendraSearchIntent` Amazon Kendra インデックスを検索するリクエストを作成したときのみです。
+ ボットの Lambda 関数で代替インテントが指定されている場合、この `developerOverride` フィールドは true です。
+ `sessionAttributes` マップは、リクエストでセッション属性を指定した場合にのみ表示されます。
+ `sentimentResponse` マップは、センチメント値を返すようにボットを設定した場合のみ表示されます。
**注記**
入力形式は変わる場合があり、この変更は対応する `messageVersion` に反映されないことがあります。新しいフィールドが追加されても、コードでエラーがスローされないようにします。
Amazon Lex の CloudWatch Logs への書き込みを有効にするロールとポリシーが必要です。詳細については、「[会話ログの IAM ポリシー](conversation-logs-policies.md)」を参照してください。
# Amazon S3 のオーディオログへのアクセス
Amazon Lex は、会話のオーディオログを S3 バケットに保存します。
**コンソールを使用してオーディオログにアクセスするには**
1. Amazon Lex コンソール ([https://console.aws.amazon.com/lex](https://console.aws.amazon.com/lex)) を開きます。
1. リストからボットを選択します。
1. [**Settings**] (設定) タブを選択し、左側のメニューから [**Conversation logs**] (会話ログ) を選択します。
1. **[Audio logs]** (オーディオログ) の下のリンクを選択して、Amazon S3 コンソールでエイリアスのログにアクセスします。
Amazon S3 コンソールまたは API を使用してオーディオログにアクセスすることもできます。オーディオファイルの S3 オブジェクトキープレフィックスは、Amazon Lex コンソールまたは `GetBotAlias` オペレーションレスポンスの `resourcePrefix` フィールドに表示されます。
# CloudWatch メトリクスを使用した会話ログのステータスのモニタリング
会話ログの配信メトリクスをモニタリングするために Amazon CloudWatch を使用します。メトリクスにアラームを設定して、ログに問題が発生した場合にその問題を認識できます。
Amazon Lex は、会話ログ用の `AWS/Lex` 名前空間に 4 つのメトリクスを提供します。
+ `ConversationLogsAudioDeliverySuccess`
+ `ConversationLogsAudioDeliveryFailure`
+ `ConversationLogsTextDeliverySuccess`
+ `ConversationLogsTextDeliveryFailure`
詳細については、「[会話ログの CloudWatch メトリクス](monitoring-aws-lex-cloudwatch.md#cloudwatch-metrics-for-logging)」を参照してください。
成功のメトリクスは、Amazon Lex がオーディオログまたはテキストログを送信先に正常に書き込んだことを示しています。
失敗のメトリクスは、Amazon Lex が指定された送信先にオーディオログまたはテキストログを配信できなかったことを示しています。通常、これは設定エラーです。失敗のメトリクスがゼロを超える場合は、次の点を確認してください。
+ Amazon Lex が IAM ロールの信頼されたエンティティであることを確認します。
+ テキストログ記録の場合は、CloudWatch Logs ロググループが存在することを確認します。オーディオログ記録の場合は、S3 バケットが存在することを確認します。
+ Amazon Lex が CloudWatch Logs ロググループまたは S3 バケットにアクセスするために使用する IAM ロールに、ロググループまたはバケットに対する書き込み権限があることを確認します。
+ S3 バケットが Amazon Lex ボットと同じリージョンに存在し、アカウントに属していることを確認します。
+ S3 暗号化に AWS KMS キーを使用している場合は、Amazon Lex がキーを使用することを妨げるポリシーがないことを確認し、指定した IAM ロールに必要な AWS KMS アクセス許可があることを確認してください。詳細については、「[会話ログの IAM ポリシー](conversation-logs-policies.md)」を参照してください。
# Amazon Lex API を使用したセッションの管理
ユーザーがボットとの会話を開始すると、Amazon Lex により*セッション*が作成されます。アプリケーションと Amazon Lex 間で交換される情報は、会話のセッション状態を構成します。リクエストを行うと、セッションはボット名と指定したユーザー識別子の組み合わせによって識別されます。ユーザー識別子の詳細については、[PostContent](API_runtime_PostContent.md) または [PostText](API_runtime_PostText.md) オペレーションの「`userId`」フィールドを参照してください。
セッションオペレーションからのレスポンスには、ユーザーとの特定のセッションを識別する一意のセッション識別子が含まれます。この識別子はテスト中やボットのトラブルシューティングに使用できます。
アプリケーションとボット間で送信されるセッション状態を変更できます。例えば、セッションに関するカスタム情報を含むセッション属性を作成および変更できます。また、次の発話を解釈するダイアログコンテキストを設定することで、会話のフローを変更できます。
セッション状態を更新する方法は 2 つあります。最初の方法は、会話の各ターンの後に呼び出される `PostContent` または `PostText` オペレーションで Lambda 関数を使用することです。詳細については、「[Lambda 関数を使用する](using-lambda.md)」を参照してください。もう 1 つの方法は、アプリケーションでセッション状態を変更する Amazon Lex ランタイム API を使用することです。
Amazon Lex ランタイム API は、ボットとの会話のセッション情報を管理できるオペレーションを提供します。これらのオペレーションは [PutSession](API_runtime_PutSession.md)、[GetSession](API_runtime_GetSession.md)、[DeleteSession](API_runtime_DeleteSession.md) です。これらのオペレーションを使用して、ボットとのユーザーセッションの状態に関する情報を取得し、その状態をきめ細かく制御します。
セッションの現在の状態を取得するには、`GetSession` オペレーションを使用します。このオペレーションは、ユーザーとのダイアログの状態、設定されているセッション属性、ユーザーが操作した最後の 3 つのインテントのスロット値など、セッションの現在の状態を返します。
`PutSession` オペレーションにより、現在のセッション状態を直接操作できます。ボットによって次に実行されるダイアログアクションのタイプを設定できます。これにより、ボットとの会話のフローを制御できます。ダイアログアクションの `type` フィールドを `Delegate` に設定して、Amazon Lex にボットの次のアクションを決定させます。
`PutSession` オペレーションを使用して、ボットとの新しいセッションを作成し、ボットが開始されるインテントを設定できます。`PutSession` オペレーションを使用して、あるインテントから別のインテントに変更することもできます。セッションの作成時またはインテントの変更時に、スロット値やセッション属性などのセッション状態を設定することもできます。新しいインテントが終了したら、前のインテントを再開するオプションがあります。`GetSession` オペレーションを使用して、前のインテントのダイアログ状態を Amazon Lex から取得し、その情報を使用してインテントのダイアログ状態を設定できます。
`PutSession` オペレーションからのレスポンスには、`PostContent` オペレーションと同じ情報が含まれます。`PostContent` オペレーションからのレスポンスの場合と同様に、この情報を使用して、ユーザーに次の情報を求めることができます。
`DeleteSession` オペレーションを使用して既存のセッションを削除し、新しいセッションからやり直します。例えば、ボットをテストするときは、`DeleteSession` オペレーションを使用してボットからテストセッションを削除できます。
セッションオペレーションはフルフィルメント Lambda 関数と連携します。例えば、Lambda 関数がフルフィルメント状態として `Failed` を返す場合、`PutSession` オペレーションを使用してダイアログアクションタイプを `close` に設定し、`fulfillmentState` を `ReadyForFulfillment` に設定して、フルフィルメントステップを再試行できます。
セッションオペレーションでは以下のことが可能です。
+ ユーザーを待たずにボットに会話を開始させる。
+ 会話中にインテントを切り替える。
+ 前のインテントに戻る。
+ 操作の途中で会話を開始または再開する。
+ スロット値を検証し、無効であればボットに値の再入力を求めさせる。
これらのそれぞれについて、以下で詳しく説明します。
## インテントの切り替え
`PutSession` オペレーションを使用して、あるインテントから別のインテントに切り替えることができます。このオペレーションを使用して、前のインテントに戻ることもできます。`PutSession` オペレーションを使用して、新しいインテントのセッション属性またはスロット値を設定できます。
+ `PutSession` 操作を呼び出します。インテント名を新しいインテントの名前に設定し、ダイアログアクションを `Delegate` に設定します。新しいインテントに必要なスロット値またはセッション属性を設定することもできます。
+ Amazon Lex は、新しいインテントを使用してユーザーとの会話を開始します。
## 前のインテントの再開
前のインテントを再開するには、`GetSession` オペレーションを使用してインテントの要約を取得してから、`PutSession` オペレーションを使用してインテントを前のダイアログ状態に設定します。
+ `GetSession` 操作を呼び出します。このオペレーションからのレスポンスには、ユーザーが操作した最後の 3 つのインテントのダイアログ状態の要約が含まれます。
+ インテントの要約からの情報を使用して、`PutSession` オペレーションを呼び出します。これにより、ユーザーは会話内の同じ場所で前のインテントに戻ります。
場合によっては、ユーザーのボットとの会話を再開する必要があります。例えば、カスタマーサービスボットを作成したとします。アプリケーションは、ユーザーがカスタマーサービス担当者と話す必要があると判断します。ユーザーと話した後、担当者は収集した情報を使用して会話をボットに戻すことができます。
セッションを再開するには、以下のような手順を使用します。
+ アプリケーションは、ユーザーがカスタマーサービス担当者と話す必要があると判断します。
+ `GetSession` オペレーションを使用して、インテントの現在のダイアログ状態を取得します。
+ カスタマーサービス担当者はユーザーと話し、問題を解決します。
+ `PutSession` オペレーションを使用して、インテントのダイアログ状態を設定します。さらに、スロット値やセッション属性の設定、インテントの変更を行う場合もあります。
+ ボットはユーザーとの会話を再開します。
`PutSession` オペレーションの `checkpointLabel` パラメータを使用してインテントにラベルを付け、後で検索することができます。例えば、顧客に情報を求めるボットは、顧客が情報を収集している間に `Waiting` インテントに入ることがあります。ボットは、現在のインテントのチェックポイントラベルを作成し、`Waiting` インテントを開始します。顧客が戻ると、ボットはチェックポイントラベルを使用して以前のインテントを見つけ、元に戻すことができます。
インテントは、`GetSession` オペレーションによって返される `recentIntentSummaryView` 構造体に存在する必要があります。`GetSession` オペレーションリクエストでチェックポイントラベルを指定すると、そのチェックポイントラベルを持つ最大 3 つのインテントが返されます。
+ `GetSession` オペレーションを使用して、セッションの現在の状態を取得します。
+ `PutSession` オペレーションを使用して、最後のインテントにチェックポイントラベルを追加します。必要に応じて、この `PutSession` 呼び出しを使用して別のインテントに切り替えることができます。
+ ラベル付けされたインテントに戻るときは、`GetSession` オペレーションを呼び出して最近のインテントリストを返します。`checkpointLabelFilter` パラメータを使用し、指定したチェックポイントラベルを持つインテントのみを Amazon Lex で返すことができます。
## 新しいセッションの開始
ボットにユーザーとの会話を開始させる場合は、`PutSession` オペレーションを使用できます。
+ スロットのない挨拶のインテントと、ユーザーにインテントの指定を求める結びのメッセージを作成します。例えば、「ご注文は何になさいますか? 飲み物になさいますか、ピザになさいますか」とします。
+ `PutSession` 操作を呼び出します。インテント名を挨拶のインテントの名前に設定し、ダイアログアクションを `Delegate` に設定します。
+ Amazon Lex は、ユーザーとの会話を開始する挨拶のインテントのプロンプトで応答します。
## スロット値の検証
クライアントアプリケーションを使用して、ボットへのレスポンスを検証できます。レスポンスが有効でない場合、`PutSession` オペレーションを使用してユーザーから新しいレスポンスを取得できます。例えば、花の注文ボットがチューリップ、バラ、ユリのみを販売できるとします。ユーザーがカーネーションを注文すると、アプリケーションは以下のことができます。
+ `PostText` または `PostContent` レスポンスから返されたスロット値を調べます。
+ スロット値が無効な場合は、`PutSession` オペレーションを呼び出します。アプリケーションはスロット値をクリアし、`slotToElicit` フィールドを設定して、`dialogAction.type` 値を `elicitSlot` に設定する必要があります。オプションで、Amazon Lex によってスロット値の誘発に使用されるメッセージを変更する場合は、`message` および `messageFormat` フィールドを設定できます。
# ボットのデプロイメントオプション
現在、Amazon Lex では以下のボットのデプロイメントオプションが用意されています。
+ [AWS Mobile SDK](https://aws.amazon.com/mobile/sdk/) – AWS Mobile SDK を使用すると、Amazon Lex と通信するモバイルアプリケーションを構築できます。
+ Facebook Messenger – Facebook Messenger ページと Amazon Lex ボットを統合すると、エンドユーザーは Facebook でボットと通信できます。現在の実装では、この統合でサポートされるのはテキスト入力メッセージのみです。
+ Slack – Amazon Lex ボットを Slack メッセージングアプリケーションと統合できます。
+ Twilio – Amazon Lex ボットを Twilio Simple Messaging Service (SMS) と統合できます。
例については「[Amazon Lex ボットのデプロイ](examples.md)」を参照してください。
# 組み込みのインテントとスロットタイプ
Amazon Lex では、Alexa に標準で組み込まれているインテントおよびスロットタイプを使用してボットを簡単に作成できます。
**Topics**
+ [組み込みインテント](howitworks-builtins-intents.md)
+ [組み込みスロットタイプ](howitworks-builtins-slots.md)
# 組み込みインテント
一般的なアクションに対しては、標準の組み込みインテントライブラリを使用できます。組み込みインテントからインテントを作成するには、コンソールで組み込みインテントを選択し、新しい名前を付けます。新しいインテントは、サンプル発話など、元のインテントの設定を継承します。
現在の実装では、以下の操作は実行できません。
+ 元のインテントのサンプル発話を追加または削除する
+ 組み込みインテントのスロットを設定する
**ボットに組み込みインテントを追加するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. 組み込みインテントを追加するボットを選択します。
1. ナビゲーションペインで、[**インテント**] の横のプラス (\$1) を選択します。
1. [**インテントの追加**] で、[**既存のインテントの検索**] を選択します。
1. **[Search intents]** (インテントの検索) ボックスに、ボットに追加する組み込みインテントの名前を入力します。
1. **[Copy built-in intent]** (組み込みインテントのコピー) で、インテントに名前を付け、**[Add]** (追加) を選択します。
1. インテントエディタを使用して、ボットに必要なインテントを構成します。
**Topics**
+ [AMAZON.CancelIntent](built-in-intent-cancel.md)
+ [AMAZON.FallbackIntent](built-in-intent-fallback.md)
+ [AMAZON.HelpIntent](built-in-intent-help.md)
+ [AMAZON.KendraSearchIntent](built-in-intent-kendra-search.md)
+ [AMAZON.PauseIntent](built-in-intent-pause.md)
+ [AMAZON.RepeatIntent](built-in-intent-repeat.md)
+ [AMAZON.ResumeIntent](built-in-intent-resume.md)
+ [AMAZON.StartOverIntent](built-in-intent-start-over.md)
+ [AMAZON.StopIntent](built-in-intent-stop.md)
**注記**
英語 (米国) (en-US) ロケールの場合、Amazon Lex は Alexa 標準の組み込みインテントからのインテントをサポートしています。組み込みインテントの一覧については、「[Alexa Skills Kit](https://developer.amazon.com/docs/custom-skills/standard-built-in-intents.html)」の「*Standard Built-in Intents*」を参照してください。
Amazon Lex では、以下のインテントはサポートされません。
`AMAZON.YesIntent`
`AMAZON.NoIntent`
「[Alexa Skills Kit](https://developer.amazon.com/docs/custom-skills/built-in-intent-library.html)」の「*Built-in Intent Library*」のインテント
# AMAZON.CancelIntent
ユーザーが現在の対話をキャンセルしたいことを示す単語やフレーズに応答します。アプリケーションはこのインテントを使用して、ユーザーとの対話を終了する前に、スロットタイプの値やその他の属性を削除できます。
一般的な発話:
+ キャンセル
+ 気にしないで
+ 忘れて
# AMAZON.FallbackIntent
ユーザーがインテントに入力した内容がボットの想定通りでない場合、Amazon Lex が*フォールバックインテント*を呼び出すように設定できます。例えば、ユーザー入力「I'd to order candy」が `OrderFlowers` ボットのインテントと一致しない場合、Amazon Lex はフォールバックインテントを呼び出してレスポンスを処理します。
組み込みの `AMAZON.FallbackIntent` インテントタイプをボットに追加することで、フォールバックインテントを追加します。インテントを指定するには、[PutBot](API_PutBot.md) オペレーションを使用するか、コンソールの組み込みインテントのリストからインテントを選択します。
フォールバックインテントを呼び出すには、2 つのステップを使用します。最初のステップでは、フォールバックインテントはユーザーからの入力に基づいてマッチングされます。フォールバックインテントが一致した場合、ボットの動作は、プロンプトに設定された再試行回数によって異なります。例えば、インテントを決定する最大試行回数が 2 の場合、ボットはフォールバックインテントを呼び出す前に、ボットの明確化プロンプトを 2 回返します。
Amazon Lex は、次のような状況でフォールバックインテントを一致させます。
+ インテントへのユーザーの入力が、ボットが想定する入力と一致しません
+ オーディオ入力がノイズであるか、テキスト入力が単語として認識されません。
+ ユーザーの入力があいまいで、Amazon Lex が呼び出すインテントを判断できません。
フォールバックインテントは、次の場合に呼び出されます。
+ 会話の開始時に明確化のための試行回数を設定した後で、ボットがインテントとしてユーザー入力を認識しない場合。
+ 設定された試行回数後に、インテントがユーザー入力をスロット値として認識しない場合。
+ 設定された試行回数後に、インテントが確認プロンプトへの応答としてユーザー入力を認識しない場合。
フォールバックインテントは以下と使用できます。
+ フルフィルメント Lambda 関数
+ 結論ステートメント
+ フォローアッププロンプト
フォールバックインテントに以下を追加することはできません。
+ 発話
+ Slots
+ 初期化および検証 Lambda 関数
+ 確認プロンプト
ボットに対して中止ステートメントとフォールバックインテントの両方を設定している場合、Amazon Lex はフォールバックインテントを使用します。ボットに中止ステートメントが必要な場合は、フォールバックインテントのフルフィルメント関数を使用して、中止ステートメントと同じ動作を提供できます。詳細については、「`abortStatement` オペレーション」の「[PutBot](API_PutBot.md) パラメータ」を参照してください。
## 明確化プロンプトの使用
ボットに明確化プロンプトを指定する場合、プロンプトはユーザーから有効なインテントを求めるために使用されます。明確化プロンプトは、設定した回数だけ繰り返されます。その後、フォールバックインテントが呼び出されます。
ボットの作成時に明確化プロンプトを設定せず、ユーザーが有効なインテントで会話を開始しない場合、Amazon Lex は直ちにフォールバックインテントを呼び出します。
明確化プロンプトなしでフォールバックインテントを使用すると、Amazon Lex は次の状況下ではフォールバックを呼び出しません。
+ ユーザーがフォローアッププロンプトに応答しても、インテントを提供しない場合。例えば、「今日は他に何か好きですか？」というフォローアッププロンプトに応答して、 とすると、ユーザーは「はい」と言います。Amazon Lex には、ユーザーからインテントを取得するための明確化プロンプトがないため、400 Bad Request 例外が返されます。
+ AWS Lambda 関数を使用する場合、`ElicitIntent`ダイアログタイプを返します。Amazon Lex には、ユーザーからインテントを取得するための明確化プロンプトがないため、400 Bad Request 例外が返されます。
+ `PutSession` オペレーションを使用するときは、`ElicitIntent` ダイアログタイプを送信します。Amazon Lex には、ユーザーからインテントを取得するための明確化プロンプトがないため、400 Bad Request 例外が返されます。
## フォールバックインテントでの Lambda 関数の使用
フォールバックインテントが呼び出されると、レスポンスは [PutIntent](API_PutIntent.md) オペレーションに対する `fulfillmentActivity` パラメータの設定によって異なります。ボットは、次のいずれかを実行します。
+ クライアントアプリケーションにインテント情報を返します。
+ フルフィルメント Lambda 関数を呼び出します。セッションに設定されたセッション変数を使用して関数を呼び出します。
フォールバックインテントが呼び出されたときのレスポンスの設定の詳細については、「`fulfillmentActivity` オペレーション」の「[PutIntent](API_PutIntent.md) パラメータ」を参照してください。
フォールバックインテントでフルフィルメント Lambda 関数を使用する場合、この関数を使用して、別のインテントを呼び出す、またはコールバック番号の収集やカスタマーサービス担当者とのセッションの開始など、ユーザーとの何らかの通信を行うことができます。
フルフィルメント関数で他のインテントに実行できる任意のアクションをフォールバックインテント Lambda 関数で実行できます。を使用してフルフィルメント関数を作成する方法の詳細については AWS Lambda、「」を参照してください[Lambda 関数を使用する](using-lambda.md)。
フォールバックインテントは、同じセッションで複数回呼び出すことができます。例えば、Lambda 関数で `ElicitIntent` ダイアログアクションを使用して、ユーザーに別のインテントの入力を求めるとします。設定された試行回数の後に Amazon Lex がユーザーのインテントを推測できない場合、フォールバックインテントを再度呼び出します。また、試行回数設定後にユーザーが有効なスロット値で応答しない場合に、フォールバックインテントを呼び出します。
セッション変数を使用して、フォールバックインテントが呼び出された回数を追跡するように Lambda 関数を設定できます。Lambda 関数で設定したしきい値を超えて呼び出された場合、Lambda 関数は別のアクションを実行できます。セッション変数の詳細については、「[セッション属性の設定](context-mgmt-session-attribs.md)」を参照してください。
# AMAZON.HelpIntent
ボットとのやりとり中にユーザーが助けを必要としていることを示す単語やフレーズに応答します。このインテントが呼び出されると、Lambda 関数またはアプリケーションを設定して、ボットの機能に関する情報を提供したり、ヘルプの領域に関するフォローアップ質問をしたり、インタラクションを人間のエージェントに渡すことができます。
一般的な発話:
+ help
+ 助けて
+ 助けてくれますか
# AMAZON.KendraSearchIntent
Amazon Kendra でインデックス付けしたドキュメントを検索するには、`AMAZON.KendraSearchIntent` インテントを使用します。Amazon Lex がユーザーとの会話の次のアクションを決定できない場合、検索インテントをトリガーします。
`AMAZON.KendraSearchIntent` は、英語 (米国) (en-US)、および米国東部 (バージニア北部)、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) の各リージョンでのみ利用できます。
Amazon Kendra は、PDF ドキュメントや Microsoft Word ファイルなどの自然言語ドキュメントにインデックス付けする機械学習ベースの検索サービスです。インデックス付けされたドキュメントを検索し、質問に対して以下のタイプのレスポンスを返すことができます。
+ 回答
+ 質問への回答になる可能性がある FAQ のエントリ
+ 質問に関連するドキュメント
`AMAZON.KendraSearchIntent` の使用例については、「[例: Amazon Kendra インデックスを使用する FAQ ボットを作成する](faq-bot-kendra-search.md)」を参照してください。
ボットに `AMAZON.KendraSearchIntent` インテントを設定した場合、Amazon Lex は、スロットまたはインテントのユーザー発話を判別できないときは常に、そのインテントを呼び出します。例えば、ボットが「ピザのトッピング」というスロットタイプのレスポンスを引き出し、ユーザーが「ピザって何?」と言った場合、Amazon Lex は `AMAZON.KendraSearchIntent` を呼び出してその質問を処理します。Amazon Kendra からのレスポンスがない場合、会話はボットで設定されたとおりに進みます。
同じボットで `AMAZON.KendraSearchIntent` と `AMAZON.FallbackIntent` の両方を使用する場合、Amazon Lex は以下のようにインテントを使用します。
1. Amazon Lex は `AMAZON.KendraSearchIntent` を呼び出します。インテントは Amazon Kendra `Query` オペレーションを呼び出します。
1. Amazon Kendra がレスポンスを返す場合、Amazon Lex はユーザーに結果を表示します。
1. Amazon Kendra からのレスポンスがない場合、Amazon Lex はユーザーに再度プロンプトを表示します。以下のアクションは、ユーザーからのレスポンスによって異なります。
+ ユーザーからのレスポンスに、スロット値の入力やインテントの確認など、Amazon Lex が認識する発話が含まれている場合、ユーザーとの会話はボットで設定されたとおりに進みます。
+ ユーザーからのレスポンスに Amazon Lex が認識する発話が含まれていない場合、Amazon Lex は `Query` オペレーションを再度呼び出します。
1. 設定された再試行回数の後にレスポンスがない場合、Amazon Lex は `AMAZON.FallbackIntent` を呼び出し、ユーザーとの会話を終了します。
`AMAZON.KendraSearchIntent` を使用して Amazon Kendra へのリクエストを作成するには、3 つの方法があります。
+ 検索インテントからリクエストを作成します。Amazon Lex では、ユーザーの発話を検索文字列として Amazon Kendra を呼び出します。インテントを作成するときに、Amazon Kendra が返すレスポンスの数を制限するクエリフィルタ文字列を定義できます。Amazon Lex は、クエリリクエストでフィルターを使用します。
+ ダイアログ Lambda 関数を使用して、追加のクエリパラメータをリクエストに追加します。Amazon Kendra クエリパラメータを含む `kendraQueryFilterString` フィールドを `delegate` ダイアログアクションに追加します。Lambda 関数を使用してクエリパラメータをリクエストに追加すると、それらのパラメータは、インテントを作成したときに定義したクエリフィルタよりも優先されます。
+ ダイアログ Lambda 関数を使用して、新しいクエリを作成します。Amazon Lex によって送信される完全な Amazon Kendra クエリリクエストを作成できます。`delegate` ダイアログアクションの `kendraQueryRequestPayload` フィールドでクエリを指定します。`kendraQueryRequestPayload` フィールドは `kendraQueryFilterString` フィールドよりも優先されます。
ボットを作成するときに `queryFilterString` パラメータを指定したり、ダイアログ Lambda 関数で `delegate` アクションを呼び出すときに `kendraQueryFilterString` フィールドを指定したりするには、Amazon Kendra クエリの属性フィルターとして使用する文字列を指定します。文字列が有効な属性フィルターでないと、実行時に `InvalidBotConfigException` 例外が発生します。属性ドキュメントの詳細については、*「Amazon Kendra Developer Guide」*(Amazon Kendra デベロッパーガイド) の[「Using document attributes to filter queries」](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering)(ドキュメント属性を使用してクエリをフィルタリングする) を参照してください。
Amazon Lex が Amazon Kendra に送信するクエリを制御するには、ダイアログ Lambda 関数の `kendraQueryRequestPayload` フィールドでクエリを指定できます。クエリが有効でない場合、Amazon Lex は `InvalidLambdaResponseException` の例外を返します。詳細については、*「Amazon Kendra Developer Guide」*(Amazon Kendra デベロッパーガイド) の [「Query operation」](https://docs.aws.amazon.com/kendra/latest/dg/API_Query.html) (クエリオペレーション) を参照してください。
`AMAZON.KendraSearchIntent` の使用方法の例については、「[例: Amazon Kendra インデックスを使用する FAQ ボットを作成する](faq-bot-kendra-search.md)」を参照してください。
## Amazon Kendra 検索の IAM ポリシー
`AMAZON.KendraSearchIntent` インテントを使用するには、Amazon Lex が Amazon Kendra イン`Query`テントを呼び出すアクセス許可を持つランタイムロールを引き受けることができる AWS Identity and Access Management (IAM) ポリシーを提供するロールを使用する必要があります。使用する IAM 設定は、Amazon Lex コンソール`AMAZON.KendraSearchIntent`を使用するか、AWS SDK または AWS Command Line Interface () を使用するかによって異なりますAWS CLI。コンソールを使用する場合、Amazon Lex サービスにリンクされたロールに Amazon Kendra を呼び出すアクセス許可を追加するか、Amazon Kendra `Query` オペレーションを呼び出すための専用のロールを使用するかを選択できます。 AWS CLI または SDK を使用してインテントを作成する場合は、 `Query`オペレーションの呼び出し専用のロールを使用する必要があります。
### アクセス許可のアタッチ
コンソールを使用して、Amazon Kendra `Query` オペレーションに対するアクセス許可をデフォルトの Amazon Lex サービスにリンクされたロールにアタッチできます。サービスにリンクされたロールにアクセス許可をアタッチする場合は、Amazon Kendra インデックスに接続するための専用のランタイムロールを作成して管理する必要はありません。
Amazon Lex コンソールへのアクセスに使用するユーザー、ロール、またはグループには、ロールポリシーを管理するアクセス許可が必要です。以下の IAM ポリシーをコンソールのアクセスロールにアタッチします。これらのアクセス許可を付与すると、既存のサービスにリンクされたロールポリシーを変更するアクセス許可がロールに付与されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:GetRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/lex.amazonaws.com/AWSServiceRoleForLexBots"
},
{
"Effect": "Allow",
"Action": "iam:ListRoles",
"Resource": "*"
}
]
}
```
------
### ロールの指定
コンソール、 AWS CLI、または API を使用して、Amazon Kendra `Query`オペレーションを呼び出すときに使用するランタイムロールを指定できます。
ランタイムロールの指定に使用するユーザー、ロール、またはグループには、`iam:PassRole` アクセス許可が必要です。以下のポリシーでは、このアクセス許可を定義しています。`iam:AssociatedResourceArn` および `iam:PassedToService` 条件コンテキストキーを使用して、アクセス許可の範囲をさらに制限できます。詳細については、「 *AWS Identity and Access Management ユーザーガイド*」の[「IAM および AWS STS 条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/role"
}
]
}
```
------
Amazon Lex が Amazon Kendra の呼び出しに使用する必要があるランタイムロールには、`kendra:Query` アクセス許可が必要です。Amazon Kendra `Query` オペレーションを呼び出すアクセス許可に既存の IAM ロールを使用する場合、そのロールには以下のポリシーがアタッチされている必要があります。
IAM コンソール、IAM API、または AWS CLI を使用して、ポリシーを作成し、ロールにアタッチすることができます。以下の手順では、AWS CLI を使用してロールとポリシーを作成します。
**注記**
次のコードは、Linux と MacOS 用にフォーマットされています。Windows の場合、Linux 行連結記号 (\$1) をキャレット (^) に置き換えます。
**Query オペレーションのアクセス許可をロールに追加するには**
1. 現在のディレクトリに **KendraQueryPolicy.json** という名前でドキュメントを作成し、以下のコードを追加して保存します。
1. で AWS CLI、次のコマンドを実行して、Amazon Kendra `Query`オペレーションを実行するための IAM ポリシーを作成します。
```
aws iam create-policy \
--policy-name query-policy-name \
--policy-document file://KendraQueryPolicy.json
```
1. `Query` オペレーションの呼び出しに使用している IAM ロールに、そのポリシーをアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::account-id:policy/query-policy-name
--role-name role-name
```
Amazon Lex サービスにリンクされたロールを更新するか、ボット用に `AMAZON.KendraSearchIntent` を作成したときに作成したロールを使用するかを選択できます。以下の手順は、使用する IAM ロールを選択する方法を示しています。
**AMAZON.KendraSearchIntent のランタイムロールを指定するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. `AMAZON.KendraSearchIntent` を追加するボットを選択します。
1. [**インテント**] の横のプラス (\$1) を選択します。
1. [**インテントの追加**] で、[**既存のインテントの検索**] を選択します。
1. [**インテントの検索**] に「**AMAZON.KendraSearchIntent**」と入力し、[**追加**] を選択します。
1. [**組み込みインテントのコピー**] にインテントの名前 (「**KendraSearchIntent**」など) を入力し、[**追加**] を選択します。
1. [**Amazon Kendra クエリ**] セクションを開きます。
1. [**IAM ロール**] で、以下のいずれかのオプションを選択します。
+ ボットが Amazon Kendra インデックスをクエリできるように Amazon Lex サービスにリンクされたロールを更新するには、**[Add Amazon Kendra permissions]** (Amazon Kendra アクセス許可の追加) を選択します。
+ Amazon Kendra `Query` オペレーションを呼び出すアクセス許可を持つロールを使用するには、**[Use an existing role]** (既存のロールを使用) を選択します。
## フィルタとしてのリクエスト属性とセッション属性の使用
Amazon Kendra から現在の会話に関連するアイテムへのレスポンスをフィルター処理するには、ボットの作成時に `queryFilterString` パラメータを追加して、セッション属性とリクエスト属性をフィルターとして使用します。インテントを作成するときに属性のプレースホルダーを指定します。それにより、Amazon Lex V2 が Amazon Kendra を呼び出す前にプレースホルダーを値に置き換えます。リクエスト属性の詳細については、「[リクエスト属性の設定](context-mgmt-request-attribs.md)」を参照してください。セッション属性の詳細については、「[セッション属性の設定](context-mgmt-session-attribs.md)」を参照してください。
以下に示しているのは、string to filter というリクエスト属性を使用して Amazon Kendra クエリをフィルター処理する `queryFilterString` パラメータの例です。
```
"{"equalsTo": {"key": "City", "value": {"stringValue": "Seattle"}}}"
```
以下に示しているのは、`"SourceURI"` というセッション属性を使用して Amazon Kendra クエリをフィルター処理する `queryFilterString` パラメータの例です。
```
"{"equalsTo": {"key": "SourceURI","value": {"stringValue": "[FileURL]"}}}"
```
以下に示しているのは、`"DepartmentName"` というリクエスト属性を使用して Amazon Kendra クエリをフィルター処理する `queryFilterString` パラメータの例です。
```
"{"equalsTo": {"key": "Department","value": {"stringValue": "((DepartmentName))"}}}"
```
`AMAZON.KendraSearchInteng` フィルターは Amazon Kendra 検索フィルターと同じ形式を使用します。詳細については、[*Amazon Kendra デベロッパーガイド*] の [[ドキュメント属性を使用して検索結果をフィルターする](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering)] を参照してください。
`AMAZON.KendraSearchIntent` で使用されるクエリフィルタ文字列は、各フィルターの最初の文字には小文字を使用する必要があります。例えば、次は `AMAZON.KendraSearchIntent` の有効なクエリフィルターです。
```
{
"andAllFilters": [
{
"equalsTo": {
"key": "City",
"value": {
"stringValue": "Seattle"
}
}
},
{
"equalsTo": {
"key": "State",
"value": {
"stringValue": "Washington"
}
}
}
]
}
```
## 検索レスポンスの使用
Amazon Kendra は、インテントの `conclusion` ステートメントでの検索に対するレスポンスを返します。フルフィルメント Lambda 関数が結論メッセージを生成しない限り、インテントには `conclusion` ステートメントが必要です。
Amazon Kendra には 4 タイプのレスポンスがあります。
+ `x-amz-lex:kendra-search-response-question_answer-question-` - 検索に一致する FAQ からの質問。
+ `x-amz-lex:kendra-search-response-question_answer-answer-` - 検索に一致する FAQ からの回答。
+ `x-amz-lex:kendra-search-response-document-` - 発話のテキストに関連するインデックス内のドキュメントからの抜粋。
+ `x-amz-lex:kendra-search-response-document-link-` - 発話のテキストに関連するインデックス内のドキュメントからの抜粋。
+ `x-amz-lex:kendra-search-response-answer-` - 質問への回答があるインデックス内のドキュメントからの抜粋。
レスポンスは `request` 属性で返されます。各属性には、最大 5 つのレスポンスがあり 1～5 の番号が付けられます。レスポンスの詳細については、[*Amazon Kendra デベロッパーガイド*] の [[レスポンスのタイプ](https://docs.aws.amazon.com/kendra/latest/dg/response-types.html)] を参照してください。
`conclusion` ステートメントには、1 つ以上のメッセージグループが必要です。各メッセージグループには、1 つ以上のメッセージが含まれます。各メッセージには、Amazon Kendra からのレスポンスでリクエスト属性によって置き換えられる 1 つ以上のプレースホルダー変数を含めることができます。メッセージ内のすべての変数がランタイムレスポンスのリクエスト属性値で置き換えられるメッセージグループには、1 つ以上のメッセージが必要です。プレースホルダー変数のないメッセージグループには、1 つのメッセージが必要です。リクエスト属性は二重かっこ (( )) で囲みます。以下のメッセージグループのメッセージは Amazon Kendra からのレスポンスに一致します。
+ 「FAQ の質問 ((x-amz-lex:kendra-search-response-question\$1answer-question-1)) を見つけました。回答は ((x-amz-lex:kendra-search-response-question\$1answer -answer-1)) です」
+ 「参考になるドキュメント ((x-amz-lex:kendra-search-response-document-1)) からの抜粋を見つけました」
+ 「質問への回答はおそらく ((x-amz-lex:kendra-search-response-answer-1)) です」
## Lambda 関数を使用したリクエストとレスポンスの管理
`AMAZON.KendraSearchIntent` インテントでは、ダイアログコードフックとフルフィルメントコードフックを使用して、Amazon Kendra へのリクエストとレスポンスを管理できます。Amazon Kendra に送信するクエリを変更する場合はダイアログコードフック Lambda 関数を使用し、レスポンスを変更する場合はフルフィルメントコードフック Lambda 関数を使用します。
### ダイアログコードフックを使用したクエリの作成
ダイアログコードフックを使用して、Amazon Kendra に送信するクエリを作成できます。ダイアログコードフックを使用するかどうかはオプションです。ダイアログコードフックを指定しない場合、Amazon Lex によってユーザー発話からクエリが作成され、`queryFilterString` が使用されます (インテントの設定時に指定した場合)。
ダイアログコードフックレスポンスで 2 つのフィールドを使用して、Amazon Kendra へのリクエストを変更できます。
+ `kendraQueryFilterString` - この文字列を使用して、Amazon Kendra リクエストの属性フィルタを指定します。インデックスで定義されたインデックスフィールドのいずれかを使用して、クエリをフィルタ処理できます。フィルター文字列の構造については、*「Amazon Kendra Developer Guide」*(Amazon Kendra デベロッパーガイド) の[「Using document attributes to filter queries」](https://docs.aws.amazon.com/kendra/latest/dg/filtering.html#search-filtering)(ドキュメント属性を使用してクエリをフィルタリングする) を参照してください。指定したフィルタ文字列が有効でないと、`InvalidLambdaResponseException` 例外が発生します。`kendraQueryFilterString` 文字列は、インテント用に設定された `queryFilterString` で指定されたクエリ文字列を上書きします。
+ `kendraQueryRequestPayload` - この文字列を使用して、Amazon Kendra クエリを指定します。クエリでは、Amazon Kendra の任意の機能を使用できます。有効なクエリを指定しないと、`InvalidLambdaResponseException` 例外が発生します。これらの制限の詳細については、*「Amazon Kendra Developer Guide」*(Amazon Kendra デベロッパーガイド) の[「Query」](https://docs.aws.amazon.com/kendra/latest/dg/API_Query.html)(クエリ) を参照してください。
フィルターまたはクエリ文字列を作成したら、レスポンスの `dialogAction` フィールドを `delegate` に設定してAmazon Lex にレスポンスを送信します。Amazon Lex は、クエリを Amazon Kendra に送信し、クエリレスポンスをフルフィルメントコードフックに返します。
### レスポンスでのフルフィルメントコードフックの使用
Amazon Lex がクエリを Amazon Kendra に送信すると、クエリレスポンスが `AMAZON.KendraSearchIntent` フルフィルメント Lambda 関数に返されます。コードフックへの入力イベントには、Amazon Kendra からの完全なレスポンスが含まれます。クエリデータは、Amazon Kendra `Query` オペレーションによって返されるものと同じ構造になります。詳細については、[*Amazon Kendra デベロッパーガイド*] の [[クエリレスポンス構文](https://docs.aws.amazon.com/kendra/latest/dg/API_Query.html#API_Query_ResponseSyntax)] を参照してください。
フルフィルメントコードフックはオプションです。フルフィルメントコードフックがない場合、またはレスポンスでメッセージを返さない場合、Amazon Lex はレスポンスに `conclusion` ステートメントを使用します。
# 例: Amazon Kendra インデックスを使用する FAQ ボットを作成する
この例では、Amazon Kendra インデックスを使用してユーザーの質問への回答を返す Amazon Lex ボットを作成します。FAQ ボットはユーザーのダイアログを管理します。`AMAZON.KendraSearchIntent` インテントを使用して、インデックスをクエリし、ユーザーにレスポンスを返します。ボットを作成するには、以下の操作を行います。
1. 顧客と対話して回答を返すボットを作成します。
1. カスタムインテントを作成します。ボットには、少なくとも 1 つのインテントと 1 つの発話が必要です。このインテントはボットのビルドに使用されるだけで、それ以外には使用されません。
1. ボットに `KendraSearchIntent` インテントを追加し、Amazon Kendra インデックスで使用されるように設定します。
1. ボットをテストするには、Amazon Kendra インデックス内のドキュメントに回答がある質問をします。
この例を使用する前に、Amazon Kendra インデックスを作成する必要があります。詳細については、*「Amazon Kendra Developer Guide」*(Amazon Kendra デベロッパーガイド) の[「Getting started with an S3 bucket (console)」](https://docs.aws.amazon.com/kendra/latest/dg/gs-console.html)(S3 バケットの使用を開始する (コンソール)) を参照してください。
**FAQ ボットを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. ナビゲーションペインで、[**ボット**] を選択します。
1. **[作成]** を選択します。
1. **[Custom bot]** (カスタムボット) を選択します。以下のようにボットを設定します。
+ **[Bot name]** (ボット名) - ボットには、**KendraTestBot** などの目的を示す名前を付けます。
+ **[Output voice]** (音声出力) - **[None]** (なし) を選択します。
+ **[Session timeout]** (セッションタイムアウト) -「**5**」と入力します。
+ **[Sentiment analysis]** (センチメント分析) - **[No]** (いいえ) を選択します。
+ **[COPPA**] - **[No]** (いいえ) を選択します。
+ **[User utterance storage]** (ユーザー発話の保存) - **[Do not store]** (保存しない) を選択します。
1. **[作成]** を選択します。
ボットを正常にビルドするには、1 つ以上のインテントと 1 つ以上のサンプル発話を作成する必要があります。このインテントは Amazon Lex ボットのビルドに必要ですが、FAQ のレスポンスには使用されません。このインテントの発話は、顧客が尋ねるどの質問にも適用されないようにしてください。
**必要なインテントを作成するには**
1. [**ボットの開始方法**] ページで、[**インテントの作成**] を選択します。
1. [**インテントの追加**] で、[**インテントの作成**] を選択します。
1. [**インテントの作成**] ダイアログボックスで、インテントに「**RequiredIntent**」などの名前を付けます。
1. [**サンプル発話**] に「**Required utterance**」などの発話を入力します。
1. [**インテントの保存**] を選択します。
次は、Amazon Kendra インデックスを検索するインテント、および返すレスポンスメッセージを作成します。
**AMAZON.KendraSearchIntent インテントとレスポンスメッセージを作成するには**
1. ナビゲーションペインで、[**インテント**] の横のプラス (\$1) を選択します。
1. [**インテントの追加**] で、[**既存のインテントの検索**] を選択します。
1. **[Search intents]** (インテントの検索) ボックスに **AMAZON.KendraSearchIntent** と入力し、リストからそのインテントを選択します。
1. [**組み込みインテントのコピー**] で、インテントに「**KendraSearchIntent**」などの名前を付け、[**追加**] を選択します。
1. インテントエディタで、[**Amazon Kendra クエリ**] を選択してクエリオプションを開きます。
1. [**Amazon Kendra インデックス**] メニューから、検索するインデックスを選択します。
1. [**レスポンス**] セクションで、以下の 3 つのメッセージを追加します。
```
I found a FAQ question for you: ((x-amz-lex:kendra-search-response-question_answer-question-1)) and the answer is ((x-amz-lex:kendra-search-response-question_answer-answer-1)).
I found an excerpt from a helpful document: ((x-amz-lex:kendra-search-response-document-1)).
I think the answer to your questions is ((x-amz-lex:kendra-search-response-answer-1)).
```
1. [**インテントの保存**] を選択してから、[**ビルド**] を選択してボットをビルドします。
最後に、コンソールテストウィンドウを使用して、ボットからのレスポンスをテストします。質問は、インデックスがサポートするドメインにあることが必要です。
**FAQ ボットをテストするには**
1. コンソールテストウィンドウで、インデックスに対する質問を入力します。
1. テストウィンドウのレスポンスセクションで、回答を確認します。
1. 別の質問のためにテストウィンドウをリセットするには、[**チャットの履歴をクリア**] を選択します。
# AMAZON.PauseIntent
ユーザーがボットとの対話を一時停止して、後で再開できるようにするための単語やフレーズに応答します。Lambda関数やアプリケーションでは、セッション変数にインテントデータを保存したり、現在のインテントを再開する際に [GetSession](API_runtime_GetSession.md) オペレーションでインテントデータを取得したりする必要があります。
一般的な発話:
+ 一時停止
+ 一時停止します
# AMAZON.RepeatIntent
ユーザーが前のメッセージを繰り返すことができる単語やフレーズに応答します。お客様のアプリケーションでは、Lambda関数を使用して前回のインテント情報をセッション変数に保存するか、[GetSession](API_runtime_GetSession.md) オペレーションを使用して前回のインテント情報を取得する必要があります。
一般的な発話:
+ 繰り返し
+ もう一回言う
+ 繰り返す
# AMAZON.ResumeIntent
単語や語句に応答して、ユーザーが以前一時停止したインテントを再開できるようにします。Lambda 関数またはアプリケーションは、前のインテントを再開するために必要な情報を管理する必要があります。
一般的な発話:
+ 再開する
+ 継続する
+ 続ける
# AMAZON.StartOverIntent
ユーザーが現在のインテントの処理を停止し、最初からやり直しを有効にする単語やフレーズに応答します。Lambda 関数または `PutSession` オペレーションを使用して、最初のスロット値を再び取得できます。
一般的な発話:
+ 最初からやり直す
+ 再起動
+ 再開
# AMAZON.StopIntent
ユーザーが現在のインテントの処理を停止し、ボットとの対話を終了したいことを示す単語やフレーズに応答します。Lambda 関数またはアプリケーションは、既存の属性とスロットタイプの値をクリアしてから、対話を終了する必要があります。
一般的な発話:
+ 停止
+ オフ
+ 黙って
# 組み込みスロットタイプ
Amazon Lex では、スロット内のデータの認識と処理方法を定義する組み込みスロットタイプがサポートされています。これらのスロットタイプはインテントで作成できます。これにより、よく使用されるスロットデータの列挙値 (日付、時刻、場所など) を作成する必要がなくなります。組み込みスロットタイプにはバージョンがありません。
| スロットタイプ | 短い説明 | サポート対象ロケール |
| --- | --- | --- |
| [AMAZON.Airport](built-in-slot-airport.md) | 空港を表す単語を認識します。 | すべてのロケール |
| [AMAZON.AlphaNumeric](built-in-slot-alphanumeric.md) | 文字と数字で構成される単語を認識します。 | 韓国語 (ko-KR) を除くすべてのロケール |
| [AMAZON.City](built-in-slot-city.md) | 都市を表す単語を認識します。 | すべてのロケール |
| [AMAZON.Country](built-in-slot-country.md) | 国を表す単語を認識します。 | すべてのロケール |
| [AMAZON.DATE](built-in-slot-date.md) | 日付を表す単語を認識し、標準形式に変換します。 | すべてのロケール |
| [AMAZON.DURATION](built-in-slot-duration.md) | 継続時間を表す単語を認識し、標準形式に変換します。 | すべてのロケール |
| [AMAZON.EmailAddress](built-in-slot-email.md) | E メールアドレスを表す単語を認識して、標準の E メールアドレスに変換 | すべてのロケール |
| [AMAZON.FirstName](built-in-slot-first-name.md) | 名を表す単語を認識します。 | すべてのロケール |
| [AMAZON.LastName](built-in-slot-last-name.md) | 名を表す単語を認識します。 | すべてのロケール |
| [AMAZON.NUMBER](built-in-slot-number.md) | 数語を認識し、数字に変換します。 | すべてのロケール |
| [AMAZON.Percentage](built-in-slot-percent.md) | パーセンテージを表す単語を認識して、数値とパーセント記号 (%) に変換 | すべてのロケール |
| [AMAZON.PhoneNumber](built-in-slot-phone.md) | 電話番号を表す単語を認識して、数値の文字列に変換 | すべてのロケール |
| [AMAZON.SpeedUnit](built-in-slot-speed.md) | 速度の単位を表す単語を認識して、標準の略語に変換 | 英語 (米国) (en-US) |
| [AMAZON.State](built-in-slot-state.md) | 州を表す単語を認識します。 | すべてのロケール |
| [AMAZON.StreetName](built-in-slot-street-name.md) | 区画の名前を表す単語を認識します。 | 英語 (米国) (en-US) を除くすべてのロケール |
| [AMAZON.TIME](built-in-slot-time.md) | 時間を示す単語を時間形式に変換します。 | すべてのロケール |
| [AMAZON.WeightUnit](built-in-slot-weight.md) | 重量の単位を表す単語を認識して、標準の略語に変換 | 英語 (米国) (en-US) |
**注記**
英語 (米国) (en-US) ロケールの場合、Amazon Lex はAlexaスキルキットのスロットタイプをサポートしています。使用可能な組み込みスロットタイプの一覧については、Alexa スキルキットのドキュメントの「[スロットタイプリファレンス](https://developer.amazon.com/docs/custom-skills/slot-type-reference.html)」を参照してください。
Amazon Lex では、`AMAZON.LITERAL` または `AMAZON.SearchQuery` 組み込みスロットタイプをサポートしていません。
# AMAZON.Airport
空港の一覧を示します。以下に例を示します。
+ ジョン・F・ケネディ国際空港
+ メルボルン空港
# AMAZON.AlphaNumeric
文字と数字で構成される文字列 (**APQ123** など) を認識します。
このスロットタイプは、韓国語 (ko-KR) ロケールでは使用できません。
以下を含む文字列には、`AMAZON.AlphaNumeric` スロットタイプを使用できます。
+ 英字 (**ABC** など)
+ 数値 (**123** など)
+ 英数字の組み合わせ (**ABC123** など)
スロットに入力された値を検証するために、`AMAZON.AlphaNumeric` スロットタイプに正規表現を追加できます。例えば、正規表現を使用して次のことを検証できます。
+ イギリスまたはカナダの郵便番号
+ 運転免許証番号
+ 車両識別番号
標準の正規表現を使用します。Amazon Lex は、正規表現で以下の文字をサポートします。
+ A～Z、a～z
+ 0-9
Amazon Lex はまた、正規表現で Unicode 文字をサポートします。その形式は `\uUnicode` です。Unicode 文字を表すには、4 桁の数字を使用します。例えば、`[\u0041-\u005A]` は [A-Z] と同じです。
次の正規表現演算子はサポートされていません。
+ 無限リピーター: \$1、\$1、または 上限のない \$1x,\$1
+ ワイルドカード (.)
正規表現の最大長は 300 文字です。正規表現を使用する AMAZON.AlphaNumeric スロットタイプに保存される文字列の最大長は 30 文字です。
正規表現の例を次に示します。
+ **APQ123** または **APQ1** などの英数字の文字列: `[A-Z]{3}[0-9]{1,3}` またはより制約がある `[A-DP-T]{3} [1-5]{1,3}`
+ 米国国際プライオリティー郵便の形式 (**CP123456789US** など): `CP[0-9]{9}US`
+ 銀行ルーティング番号 (**123456789** など): `[0-9]{9}`
スロットタイプの正規表現を設定するには、コンソールまたは [PutSlotType](API_PutSlotType.md) オペレーションを使用します。スロットタイプを保存するときに、正規表現が検証されます。正規表現が有効でない場合、Amazon Lex はエラーメッセージを返します。
スロットタイプで正規表現を使用するときに、Amazon Lex はそのタイプのスロットへの入力を正規表現と照合します。入力が式と一致する場合、値はスロットに対して受け入れられます。入力が一致しない場合、Amazon Lex は入力を繰り返すようユーザーに要求します。
# AMAZON.City
ローカルおよび世界の都市のリストを提供します。スロットタイプは、都市名の共通のバリエーションを認識します。Amazon Lex はバリエーションから正式名称に変換されません。
例:
+ ニューヨーク
+ レイキャビク
+ 東京
+ ヴェルサイユ
# AMAZON.Country
世界の国の名前。例:
+ オーストラリア
+ ドイツ
+ 日本
+ アメリカ
+ ウルグアイ
# AMAZON.DATE
日付を表す単語を日付形式に変換します。
日付は ISO-8601 の日付形式でインテントに提供されます。スロットでインテントが受け取る日付は、ユーザーが発した特定のフレーズによって異なります。
+ 「今日」、「今」、「11 月 25 日」など、特定の日付にマップされる発話は、完全な日付に変換されます `2020-11-25`。デフォルトでは、[*現在または以降*] の日付になります。
+ 「今週」や「来週」など、特定の週に対応する発話は、その週の 1 日目の日付に変換されます。ISO-8601 形式では、週は月曜日に始まり、日曜日に終了します。例えば、今日が 2020-11-25 の場合、「来週」は `2020-11-30` に変換されます。
+ 「来月」などの特定の日付ではなく、月にマップされる発話は、その月の最終日に変換されます。例えば、今日が2020-11-25 の場合、「来月」は `2020-12-31` に変換されます。
+ 「来年」など、特定の月や日ではなく、年にマップされる発話は、翌年の最終日に変換されます。例えば、今日が2020-11-25 の場合、「来年」は `2021-12-31` に変換されます。
# AMAZON.DURATION
期間を示す単語を数値の期間に変換します。
期間は、[[ISO-8601 期間形式](https://en.wikipedia.org/wiki/ISO_8601#Durations)] に基づいた形式 `PnYnMnWnDTnHnMnS` に変換されます。`P` は期間であることを示し、`n` は数値で、次の大文字 `n` は、特定の日付または時刻の要素です。例えば、`P3D` は、3 日を意味します。`T` は、残りの値が日付要素ではなく時間要素を表していることを示すために使用されます。
例:
+ 「10 分」: `PT10M`
+ 「5 時間」: `PT5H`
+ 「3 日間」: `P3D`
+ 「45 秒」：`PT45S`
+ 「8 週間」: `P8W`
+ 「7 年間」: `P7Y`
+ 「5 時間 10 分」: `PT5H10M`
+ 「2 年 3 時間 10 分」：`P2YT3H10M`
# AMAZON.EmailAddress
username@domain としての E メールアドレスを表す単語を認識します。アドレスのユーザー名には、特殊文字のアンダースコア (\$1)、ハイフン (-)、ピリオド (.)、プラス記号 (\$1) を含めることができます。
# AMAZON.FirstName
よく使われる名前。このスロットタイプは、正式な名前と非公式のニックネームの両方を認識します。インテントに送信される名前は、ユーザーが送信した値です。Amazon Lex はニックネームから正式名に変換しません。
名前が似ているがスペルが異なる場合、Amazon Lex からインテントに共通フォームが送信されます。
英語 (米国) (en-US) ロケールのスロット名 AMAZON.US\$1First\$1Name を使用してください。
例:
+ エミリー
+ ジョン
+ ソフィー
# AMAZON.LastName
一般的に使用される姓。同じ名前のスペルが異なる場合、Amazon Lex からインテントに共通フォームが送信されます。
英語 (米国) (en-US) ロケールのスロット名 AMAZON.US\$1Last\$1Name を使用してください。
例:
+ ブロスキー
+ ダッシャー
+ エバース
+ パレス
+ ウェルト
# AMAZON.NUMBER
数値を表す単語や数値を少数を含む数値に変換します。次の表は、`AMAZON.NUMBER` スロットタイプでの数値語の変換方法を示しています。
| Input | 応答 |
| --- | --- |
| one hundred twenty three point four five | 123.45 |
| one hundred twenty three dot four five | 123.45 |
| point four two | 0.42 |
| point forty two | 0.42 |
| 232.998 | 232.998 |
| 50 | 50 |
# AMAZON.Percentage
パーセンテージを表す単語と記号を数値とパーセント記号 (%) に変換します。
パーセント記号や単語「percent」を使わずに数値を入力すると、スロット値は数値に設定されます。次の表は、`AMAZON.Percentage` スロットタイプでのパーセンテージの変換方法を示しています。
| Input | 応答 |
| --- | --- |
| 50 percent | 50% |
| 0.4 パーセント | 0.4% |
| 23.5% | 23.5% |
| 25 パーセント | 25% |
# AMAZON.PhoneNumber
電話番号を表す数値や単語を、次に示すように、区切り文字を使用しない文字列形式に変換します。
| 型 | 説明 | Input | 結果 |
| --- | --- | --- | --- |
| 先頭にプラス記号 (\$1) が付いた国際番号 | 先頭にプラス記号が付いた 11 桁の番号 | \$161 7 4445 1061 \$11 (509) 555-1212 | `+61744431061` `+15095551212` |
| 先頭にプラス記号 (\$1) がない国際番号 | 先頭にプラス記号がない 11 桁の番号 | 1 (509) 555-1212 61 7 4445 1061 | `15095551212` `61744451061` |
| 国内番号 | 国番号がない 10 桁の番号 | (03) 5115 4444 (509) 555-1212 | `0351154444` `5095551212` |
| ローカル番号 | 国番号や市外局番がない 7 桁の電話番号 | 555-1212 | 5551212 |
# AMAZON.SpeedUnit
速度の単位を表す単語を、対応する略語に変換します。例えば、「miles per hour」は `mph` に変換されます。
スロットタイプは、英語 (英国) (en-GB) ロケールのみで使用できます。
次の例は、`AMAZON.SpeedUnit` スロットタイプでの速度単位の変換方法を示しています。
| 速度の単位 | 略語 |
| --- | --- |
| miles per hour、mph、MPH、m/h | mph |
| kilometers per hour、km per hour、kmph、KMPH、km/h | kmph |
| meters per second、mps、MPS、m/s | mps |
| nautical miles per hour、knots、knot | knot |
# AMAZON.State
国内の地理的および政治的地域の名前。
例:
+ バイエルン州
+ 福島県
+ 太平洋北西部
+ クイーンズランド
+ ウェールズ
# AMAZON.StreetName
一般的な住所内の通りの名前。これには通りの名前だけが含まれ、番地は含まれません。
スロットタイプは、英語 (英国) (en-GB) ロケールのみで使用できます。
例:
+ キャンベラアベニュー
+ フロントストリート
+ マーケットロード
# AMAZON.TIME
時刻を表す単語を時刻値に変換します。あいまいな時間の解決を含みます。ユーザーがあいまいな時刻を入力すると、Amazon Lex は Lambda イベントの `slotDetails` 属性を使用して、あいまいな時刻の解決を Lambda 関数に渡します。例えば、ボットからユーザーに配達時間を尋ねたときにユーザーが「10 時」と答えると、この時刻はあいまいです。午前 10:00 なのか午後 10:00 なのかが不明です。この場合、`slots` マップの値は `null` となり、`slotDetails` エンティティに 2 つの可能な時刻の解決が含まれます。Amazon Lex は Lambda 関数に次のように入力します。
```
"slots": {
"deliveryTime": null
},
"slotDetails": {
"deliveryTime": {
"resolutions": [
{
"value": "10:00"
},
{
"value": "22:00"
}
]
}
}
```
ユーザーからあいまいではない時刻が返されると、Amazon Lex は Lambda イベントの `slots` 属性で時刻を Lambda 関数に送信し、`slotDetails` 属性は空になります。例えば、ユーザーが配達時間を求めるプロンプトに対して「10:00 PM」と返答すると、Amazon Lex は Lambda 関数に次のように入力します。
```
"slots": {
"deliveryTime": "22:00"
}
```
Amazon Lex から Lambda 関数に送信されるデータの詳細については、「[入力イベントの形式](lambda-input-response-format.md#using-lambda-input-event-format)」を参照してください。
# AMAZON.WeightUnit
重量の単位を表す単語を対応する略語に変換します。例えば、「kilogram」は `kg` に変換されます。
スロットタイプは、英語 (英国) (en-GB) ロケールのみで使用できます。
以下の例は、`AMAZON.WeightUnit` スロットタイプでの重量単位の変換方法を示しています。
| 重量の単位 | 略語 |
| --- | --- |
| kilograms、kilos、kgs、KGS | kg |
| grams、gms、gm、GMS、g | g |
| milligrams、mg、mgs | mg |
| pounds、lbs、LBS | lbs |
| ounces、oz、OZ | oz |
| tonne、ton、t | t |
| kiloton、kt | kt |
# カスタムスロットタイプ
インテントごとに、ユーザーのリクエストの達成に必要な情報を示すパラメータを指定できます。これらのパラメータ (スロット) にはタイプがあります。*スロットタイプ*は、スロット値を認識するように機械学習モデルをトレーニングするために Amazon Lex で使用する値のリストです。例えば、「`Genres.`」というスロットタイプを定義できます。このスロットタイプの各値は、ジャンル名を示す「comedy」、「adventure」、「documentary」などです。スロットタイプ値にはシノニムを定義できます。例えば、「comedy」値のシノニムとして「funny」や「humorous」を定義できます。
スロット値に解決される候補を制限するようにスロットタイプを設定できます。スロット値は列挙値として使用されます。ユーザーが入力した値は、スロット値のいずれかまたはシノニムと一致した場合にのみ、スロット値として解決されます。シノニムは、対応するスロット値に解決されます。例えば、ユーザーが「funny」と入力した場合、これはスロット値「comedy」に解決されます。
また、値を拡張するようにスロットタイプを設定することもできます。スロット値はトレーニングデータとして使用され、スロットはスロット値やシノニムに類似している場合に、ユーザーが指定した値に解決されます。これがデフォルトの動作です。
Amazon Lex には、スロットの解決の候補リストが保持されています。リスト内のエントリごとに、Amazon Lex でスロットの追加候補として認識された*解決値*があります。解決値は、スロット値と一致させるための最適な方法です。リストには最大 5 つの値が含まれます。
ユーザーが入力した値がシノニムである場合、解決値のリストの最初のエントリはスロットタイプ値になります。例えば、ユーザーが「funny」と入力すると、`slots` フィールドに「funny」が入り、`slotDetails` フィールドの最初のエントリが「comedy」になります。[PutSlotType](API_PutSlotType.md) オペレーションを使用してスロットタイプを作成または更新するときに、スロット値が解決リストの最初の値になるように、`valueSelectionStrategy` を設定できます。
Lambda 関数を使用している場合は、関数への入力イベントに `slotDetails` という解決リストが含まれています。次の例は、Lambda 関数への入力のスロットとスロット詳細のセクションを示しています。
```
"slots": {
"MovieGenre": "funny";
},
"slotDetails": {
"Movie": {
"resolutions": [
"value": "comedy"
]
}
}
```
スロットタイプごとに、最大 10,000 個の値とシノニムを定義できます。各ボットには、合計 50,000 個のスロットタイプ値とシノニムを含めることができます。例えば、5,000 の値と 5,000 のシノニムを含む 5 個のスロットタイプを使用するか、2,500 の値と 2,500 のシノニムを含む 10 個のスロットタイプを使用できます。これらの制限を超えると、[PutBot](API_PutBot.md) オペレーションを呼び出したときに `LimitExceededException` が返されます。
# スロットの難読化
Amazon Lex では、スロットの内容を難読化または非表示にして、コンテンツが表示されないようにすることができます。スロット値としてキャプチャされた機密データを保護するために、スロットの難読化を有効にして、会話ログのためにこれらの値をマスクできます。
スロット値を難読化することを選択した場合、Amazon Lex はスロット値を会話ログ内のスロットの名前に置き換えます。`full_name` と呼ばれるスロットの場合、スロットの値は次のように難読化されます。
```
Before obfuscation:
My name is John Stiles
After obfuscation:
My name is {full_name}
```
発話に括弧文字 (\$1\$1) が含まれている場合、Amazon Lex は括弧文字を 2 つのバックスラッシュ (\$1\$1) でエスケープします。例えば、テキスト `{John Stiles}` は次のように難読化されます。
```
Before obfuscation:
My name is {John Stiles}
After obfuscation:
My name is \\{{full_name}\\}
```
スロット値は会話ログで難読化されます。スロット値は、`PostContent` および `PostText` オペレーションからのレスポンスでも使用できます。スロット値は、検証およびフルフィルメント Lambda 関数で使用できます。プロンプトまたはレスポンスでスロット値を使用している場合、これらのスロット値は会話ログで難読化されません。
会話の最初のターンで、発話のスロットとスロットの値を認識すると、Amazon Lex はスロット値を難読化します。スロット値が認識されない場合、Amazon Lex は発話を難読化しません。
2 回目以降のターンでは、Amazon Lex は引き出すスロットを認識し、スロット値を難読化する必要があるかどうかを認識します。Amazon Lex がスロット値を認識すると、値は難読化されます。Amazon Lex が値を認識しない場合、発話全体が難読化されます。認識されなかった発話のスロット値は難読化されません。
Amazon Lex はまた、リクエスト属性またはセッション属性に保存するスロット値を難読化しません。難読化する必要があるスロット値を属性として保存する場合は、値を暗号化するか、難読化する必要があります。
Amazon Lex はオーディオのスロット値を難読化しません。これは、オーディオの書き起こしのスロット値を難読化します。
ボット内のすべてのスロットを難読化する必要はありません。どのスロットを難読化するかは、コンソールまたは Amazon Lex API を使用して選択できます。コンソールのスロットの設定で [**Slot obfuscation**] (スロットの難読化) を選択します。API を使用している場合は、[PutIntent](API_PutIntent.md) オペレーションを呼び出すときに、スロットの `obfuscationSetting` フィールドを `DEFAULT_OBFUSCATION` に設定します。
# センチメント分析
センチメント分析を使用して、ユーザー発話で表現されるセンチメントを判断できます。センチメント情報を使用して、会話フローを管理したり、コール後の分析を実行できます。例えば、ユーザーのセンチメントがネガティブな場合、会話をヒューマンエージェントに引き渡すフローを作成できます。
Amazon Lex は、Amazon Comprehend と統合して、ユーザーのセンチメントを検出します。Amazon Comprehend からの応答は、テキストの全体的なセンチメントがポジティブ、中立、ネガティブ、または混合のいずれであるかを示します。応答には、ユーザー発話における最も可能性の高いセンチメントおよびセンチメントカテゴリごとのスコアが含まれます。スコアはセンチメントが正しく検出された可能性を表します。
コンソールまたは Amazon Lex API を使用して、ボットのセンチメント分析を有効にします。Amazon Lex コンソールで、ボットの**[設定]** タブを選択し、**[Sentiment Analysis]** (センチメント分析) オプションを **[はい]** に設定します。API を使用している場合は、`detectSentiment` フィールドを `true` に設定して [PutBot](API_PutBot.md) オペレーションを呼び出します。
センチメント分析を有効にしている場合、[PostContent](API_runtime_PostContent.md) および [PostText](API_runtime_PostText.md) オペレーションは、ボットの応答で `sentimentResponse` という名前のフィールドを他のメタデータとともに返します。`sentimentResponse` フィールドには、センチメント分析の結果を含む `SentimentLabel` および `SentimentScore` の 2 つのフィールドがあります。Lambda 関数を使用している場合、`sentimentResponse` フィールドは関数に送信されるイベントデータに含まれます。
以下に、`PostText` または `PostContent` 応答の一部として返される `sentimentResponse` フィールドの例を示します。`SentimentScore` フィールドは、レスポンスのスコアを含む文字列です。
```
{
"SentimentScore":
"{
Mixed: 0.030585512690246105,
Positive: 0.94992071056365967,
Neutral: 0.0141543131828308,
Negative: 0.00893945890665054
}",
"SentimentLabel": "POSITIVE"
}
```
Amazon Lex は自動的に Amazon Comprehend を呼び出し、ボットによって処理されるすべての発話のセンチメントを判断します。センチメント分析を有効にすると、Amazon Comprehend のサービス利用規約および契約に同意したことになります。Amazon Comprehend の料金の詳細については、[「Amazon Comprehend Pricing」](https://aws.amazon.com/comprehend/pricing/)(Amazon Comprehend の料金) を参照してください。
Amazon Comprehend のセンチメント分析の仕組みについては、[「Amazon Comprehend Developer Guide」](https://docs.aws.amazon.com/comprehend/latest/dg/how-sentiment.html)(Amazon Comprehend デベロッパーガイド) の*「Determine the Sentiment」*(センチメントを決定する) を参照してください。
# Amazon Lex リソースのタグ付け
Amazon Lex ボット、ボットエイリアス、ボットチャンネルを管理しやすくするために、各リソースにメタデータを*タグ*として割り当てることができます。タグは、 AWS リソースに割り当てるラベルです。各タグは、キーと値から構成されます。
タグを使用すると、AWS リソースを目的、所有者、アプリケーションなどさまざまな方法で分類することができます。タグを使用すると、次のことができます。
+ AWS リソースを特定して整理します。多くの AWS リソースはタグ付けをサポートしているため、異なるサービスのリソースに同じタグを割り当てて、リソースが関連していることを示すことができます。例えば、ボットとボットが使用する Lambda 関数に同じタグを付けることができます。
+ コストの割り当て。 AWS Billing and Cost Management ダッシュボードでタグをアクティブ化します。 はタグ AWS を使用してコストを分類し、毎月のコスト配分レポートを配信します。Amazon Lex では、`$LATEST` エイリアス以外のエイリアスに固有のタグを使用して、エイリアスごとにコストを割り当てることができます。Amazon Lex ボットのタグを使用して、`$LATEST` エイリアスのコストを割り当てます。詳細については、[「AWS Billing and Cost Management ユーザーガイド」](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)の*「コスト配分タグの使用」*(Use Cost Allocation Tags) を参照してください。
+ リソースへのアクセス制御。Amazon Lex へのタグを使用して、Amazon Lex リソースへのアクセスを制御するポリシーを作成することができます。これらのポリシーを IAM ロールまたはユーザーにアタッチして、タグベースのアクセスコントロールを有効にできます。詳細については、「[Amazon Lex での ABAC](security_iam_service-with-iam.md#security_iam_service-with-iam-tags)」を参照してください。リソースのタグに基づいてリソースへのアクセスを制限するためのアイデンティティベースポリシーの例を表示するには、「[タグを使用したリソースへのアクセス](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-tag)」を参照してください。
タグは、 AWS マネジメントコンソール、、 AWS Command Line Interfaceまたは Amazon Lex API を使用して操作できます。
## リソースのタグ付け
Amazon Lex コンソールを使用している場合は、作成時にリソースにタグを付けることも、後でタグを追加することもできます。コンソールを使用して、既存のタグを更新または削除することもできます。
AWS CLI または Amazon Lex API を使用している場合は、次のオペレーションを使用してリソースのタグを管理します。
+ [ListTagsForResource](API_ListTagsForResource.md) - リソースに関連付けられたタグを表示します。
+ [PutBot](API_PutBot.md) および [PutBotAlias](API_PutBotAlias.md) - ボットまたはボットエイリアスを作成するときにタグを適用します。
+ [TagResource](API_TagResource.md) - 既存のリソースにタグを追加および変更します。
+ [UntagResource](API_UntagResource.md) - リソースからタグを削除します
Amazon Lex の以下のリソースがタグ付けをサポートしています。
+ ボット - 次のような Amazon リソースネーム (ARN) を使用します。
+ `arn:${partition}:lex:${region}:${account}:bot:${bot-name}`
+ ボットエイリアス - 次のような ARN を使用します。
+ `arn:${partition}:lex:${region}:${account}:bot:${bot-name}:${bot-alias}`
+ ボットチャンネル - 次のような ARN を使用します。
+ `arn:${partition}:lex:${region}:${account}:bot-channel:${bot-name}:${bot-alias}:${channel-name}`
## タグの制限
Amazon Lex リソースのタグには、以下の基本的な制限が適用されます。
+ タグの最大数 - 50
+ キーの最大長 - 128 文字
+ 最大値の長さ - 256 文字
+ キーと値の有効な文字 – a-z、A-Z、0-9、スペース、および特殊文字 (\$1 . : / = \$1 - @)
+ キーと値は大文字と小文字が区別されます。
+ `aws:` をキーのプレフィックスとしてを使用しないでください。AWS 用に予約済みです。
# リソースのタグ付け (コンソール)
コンソールを使用して、ボット、ボットエイリアス、またはボットチャンネルリソースのタグを管理できます。リソースの作成時にタグを追加することも、既存のリソースからタグを追加、変更、または削除することもできます。
**ボットの作成時にタグを追加するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. [**Create**] を選択して、新しいボットを作成します。
1. [**Create your bot**] ページの下部にある [**Tags**] を選択します。
1. [**Add tag**] を選択し、ボットに 1 つ以上のタグを追加します。最大 50 個のタグを追加できます。
**ボットエイリアスの作成時にタグを追加するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. ボットエイリアスを追加するボットを選択します。
1. **[設定]** を選択します。
1. エイリアス名を追加し、ボットのバージョンを選択して、[**Add tags**] を選択します。
1. [**Add tag**] を選択し、ボットエイリアスに 1 つ以上のタグを追加します。最大 50 個のタグを追加できます。
**ボットチャンネルの作成時にタグを追加するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. ボットチャンネルを追加するボットを選択します。
1. [**Channels**] を選択し、追加するチャンネルを選択します。
1. ボットチャンネルの詳細を追加し、[**Tags**] を選択します。
1. [**Add tag**] を選択し、ボットチャンネルに 1 つ以上のタグを追加します。最大 50 個のタグを追加できます。
**ボットをインポートするときにタグを追加するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. [**アクション**] を選択してから、[**インポート**] を選択します。
1. ボットをインポートするための zip ファイルを選択します。
1. [**Tags**] を選択し、[**Add tag**] を選択して、ボットに 1 つ以上のタグを追加します。最大 50 個のタグを追加できます。
**既存のボットのタグを追加、削除、または変更するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. 左側のメニューから [**Bots**] を選択し、変更するボットを選択します。
1. [**Settings**] を選択し、左側のメニューから [**General**] を選択します。
1. [**Tags**] を選択し、ボットのタグを追加、変更、または削除します。
**ボットエイリアスのタグを追加、削除、または変更するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. 左側のメニューから [**Bots**] を選択し、変更するボットを選択します。
1. [**Settings**] を選択し、左側のメニューから [**Aliases**] を選択します。
1. 変更するエイリアスの [**Manage tags**] を選択し、ボットエイリアスのタグを追加、変更、または削除します。
**既存のボットチャンネルでタグを追加、削除、または変更するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。
1. 左側のメニューから [**Bots**] を選択し、変更するボットを選択します。
1. [**Channels**] を選択します。
1. [**Tags**] を選択し、ボットチャンネルのタグを追加、変更、または削除します。
# リソースのタグ付け (AWS CLI)
を使用して AWS CLI 、ボット、ボットエイリアス、またはボットチャネルリソースのタグを管理できます。ボットまたはボットエイリアスの作成時にタグを追加したり、ボット、ボットエイリアス、ボットチャンネルからタグを追加、変更、または削除したりできます。
すべての例は、Linux および macOS 用にフォーマットされています。Windows でコマンドを使用するには、Linux の継続文字 (\$1) をキャレット (^) に置き換えます。
**ボットの作成時にタグを追加するには**
+ 次の省略`put-bot` AWS CLI コマンドは、ボットの作成時にタグを追加するために使用する必要があるパラメータを示しています。実際にボットを作成するには、他のパラメータを指定する必要があります。詳細については、「[ステップ 4: ご利用開始にあたって (AWS CLI)](gs-cli.md)」を参照してください。
```
aws lex-models put-bot \
--tags '[{"key": "key1", "value": "value1"}, \
{"key": "key2", "value": "value2"}]'
```
**ボットエイリアスの作成時にタグを追加するには**
+ 次の省略`put-bot-alias` AWS CLI コマンドは、ボットエイリアスの作成時にタグを追加するために使用する必要があるパラメータを示しています。実際にボットエイリアスを作成するには、他のパラメータを指定する必要があります。詳細については、「[演習 5: エイリアスを作成する (AWS CLI)](gs-cli-create-alias.md)」を参照してください。
```
aws lex-models put-bot \
--tags '[{"key": "key1", "value": "value1"}, \
{"key": "key2", "value": "value2"}]"
```
**リソースのタグを一覧表示するには**
+ `list-tags-for-resource` AWS CLI コマンドを使用して、ボット、ボットエイリアス、ボットチャネルに関連付けられたリソースを表示します。
```
aws lex-models list-tags-for-resource \
--resource-arn bot, bot alias, or bot channel ARN
```
**リソースのタグを追加または変更するには**
+ `tag-resource` AWS CLI コマンドを使用して、ボット、ボットエイリアス、またはボットチャネルを追加または変更します。
```
aws lex-models tag-resource \
--resource-arn bot, bot alias, or bot channel ARN \
--tags '[{"key": "key1", "value": "value1"}, \
{"key": "key2", "value": "value2"}]'
```
**リソースからタグを削除する**
+ `untag-resource` AWS CLI コマンドを使用して、ボット、ボットエイリアス、またはボットチャネルからタグを削除します。
```
aws lex-models untag-resource \
--resource-arn bot, bot alias, or bot channel ARN \
--tag-keys '["key1", "key2"]'
```