ひとことで言うと
ユーザーの発話から「やりたいこと（インテント）」を分類し、実行に必要な「パラメータ（スロット）」が埋まるまで聞き返す、ASR と NLU を組み合わせた対話エンジンです。スロットが全部埋まって初めて、Lambda によるフルフィルメントに進みます。
要するに、窓口の申請書です。職員はまず「どの申請ですか」（インテント分類）を決め、次に空欄を1つずつ埋めさせる（スロットの聴取）。全部埋まるまで受理しません。FM との違いはここで、Lex は「必要な項目が揃った」ことを構造として保証します——雑談は上手くなくても、注文数量を聞き忘れることがない。
なぜ生まれたか
会話UIを自前で組むと、ASR と NLU のモデルを持つこと自体が壁でした。Lex はそこを SLU（Speech Language Understanding） としてまとめて提供し、開発者が書くのは「インテント名・サンプル発話・スロット定義」だけにしました。
生成AI時代の位置づけはもう一段ずれています。FM は会話が上手い代わりに、必要な項目を必ず集めることも、同じ入力に同じ経路を通ることも保証しません。Lex は逆に、経路が決定的な代わりに柔軟性が低い。そこで AWS は Lex 側に Bedrock を差し込んで、枠は Lex・言語理解と自由回答は FM という組み合わせを用意しました。
| 層 | 決定的な部分（Lex 本体） | 生成AIで補う部分 |
|---|---|---|
| ボット構築 | インテント・スロット・サンプル発話を手で定義 | descriptive bot builder（自然言語の説明からインテントとスロット型を生成）／sample utterance generation |
| 実行時の理解 | サンプル発話に基づく NLU | Assisted NLU（LLM で分類とスロット解決を改善。ただし設定済みのインテントとスロットの範囲内）／assisted slot resolution |
| 回答 | インテントごとの応答と Lambda フルフィルメント | AMAZON.QnAIntent（ナレッジストアを検索して回答）／BedrockAgentIntent |
| 会話フロー | 条件分岐（2022年8月17日以降に作成したボットで、Lambda を書かずに構成可能） | Intent Disambiguation（曖昧な入力の解消） |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| 意図の分類とパラメータ収集 | インテント＋スロット＋サンプル発話。実行は Lambda フルフィルメント | D1・D2 |
| 自由回答（FAQ）の追加 | AMAZON.QnAIntent を追加し、OpenSearch Service / Kendra インデックス / Bedrock ナレッジベースのいずれかを繋ぐ | D1 |
| Bedrock エージェントの呼び出し | BedrockAgentIntent でエージェントを会話に組み込む | D2 |
| 曖昧な発話の扱い | NLU 信頼度スコアと AMAZON.FallbackIntent。ダイアログコードフックで代替インテントに切り替える | D2 |
| コンタクトセンター統合 | Amazon Connect との連携。Comprehend・Kendra・Lambda とも統合 | D2 |
| チャネル配信 | Slack・Microsoft Teams・WhatsApp・Facebook Messenger・自前 Web アプリ | D2 |
| バージョン運用 | バージョン（不変のスナップショット）とエイリアス（バージョンへのポインタ）。クライアントはエイリアスを参照 | D2 |
| 可用性 | Multi-Region Replication（MRR） でボットを複数リージョンに展開 | D2 |
試験でどう問われるか
Lex が主役の設問は多くありません。「会話アプリを作れ」という要件に対して、FM に直接喋らせる案と、Lex を前段に置く案のどちらを選ぶかという形で出ます。決め手は「決定的であることが要件に書いてあるか」です。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| FM 単体か、Lex を挟むか | 収集すべき項目が決まっている／同じ入力に同じ経路を通す必要がある／基幹システムを叩く前に必須パラメータを確定させたい → Lex のインテント＋スロット | 「FM のプロンプトで必須項目を全部聞くよう指示する」（指示は保証にならない） |
| Lex か Bedrock エージェントか | タスクが列挙できるなら Lex。ツールを動的に選んで多段推論が要るならエージェント側 | 会話UIという語だけで Lex を選ぶ（自由回答中心なら AMAZON.QnAIntent かエージェント） |
| 既存の Lex ボットに社内文書の FAQ を足したい | AMAZON.QnAIntent を追加し、Bedrock ナレッジベース等を接続 | インテントを FAQ の数だけ手作りする案／全体を FM に置き換える案（既存の決定的なフローまで壊れる） |
| ボットが発話を取り違える | NLU 信頼度スコアを見て設計する。閾値は nluIntentConfidenceThreshold（CreateBotLocale / UpdateBotLocale） | 「サンプル発話を増やすだけ」で閾値と Fallback の設計に触れない案 |
| 曖昧な2候補をどう捌くか | ダイアログコードフックの Lambda で alternativeIntents（最大4件）とスコアを見て、ConfirmIntent か ElicitSlot を返す | AMAZON.FallbackIntent のスコアで判断する（Fallback には信頼度スコアが出ない） |
| 学習データが少なくて精度が出ない | Assisted NLU（LLM で分類とスロット解決を改善）を有効化。設定済みのインテントとスロットの範囲内で効く | Assisted NLU が「定義していないインテントも答えてくれる」と読む選択肢 |
| 本番を止めずにボットを更新したい | 新しいバージョンを発行し、エイリアスの向き先を差し替える | クライアント側にバージョン番号を直書きして更新する案 |
AMAZON.QnAIntent の発火条件が引っかけになります。この組み込みインテントは、発話が他のどのインテントにも分類されなかったときに起動します。さらに、スロット値を聴取している最中の外れた発話では起動しません。「注文フローの途中で『そういえば送料は？』と聞かれたら QnAIntent が答える」という選択肢は誤りです。
実務でどう使うか
- 信頼度スコアは絶対値として使えません。 公式が「比較のための値であり、Lex の改善に伴って変わりうる」と明記しています。0.75 という数字をコードに焼くのではなく、候補間の差（0.95 対 0.65 なら明確、0.75 対 0.72 なら曖昧）で判断する設計にします
AMAZON.FallbackIntentは必ず存在します。 自分で作らなくても各ボットに含まれ、全候補が閾値未満のときにトップとして返ります。このときAMAZON.KendraSearchIntentを構成していれば、それも併せて返りますinterpretationsに入るのは最尤インテント＋代替最大4件です。Lambda 側ではcurrentIntentとalternativeIntents（nluIntentConfidenceScore付き）として渡ってきます。クライアント側から会話のインテントを差し替えたいときはPutSessionを使います- 生成AI機能はロケール単位で有効化し、機能ごとに使う FM を選びます（
generativeAISettingsのdescriptiveBotBuilder/slotResolutionImprovement/sampleUtteranceGenerationにそれぞれmodelArn）。ボット全体で一括、ではありません - 生成AI機能は Bedrock 課金が別に乗ります。 Lex 自体はリクエスト課金（テキストまたは音声リクエスト）で、そこに Bedrock 側の料金が加算されます
- 言語（ロケール）は互いに独立です。 閾値も生成AI設定もロケールごと。多言語ボットで「日本語だけ精度が出ない」ときに、英語ロケールの設定を見ても答えは出ません
ロケールごとに独立している、の実害: 生成AI機能の有効化も nluIntentConfidenceThreshold もロケール単位です。多言語ボットで英語ロケールだけ Assisted NLU を入れて満足すると、日本語ロケールは素の NLU のまま動き続けます。設定は言語の数だけ確認します。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Bedrock エージェント | Lex は列挙したインテントを確実に捌く。エージェントはツールを選んで多段で推論する。「必ずこの項目を集める」が要件なら Lex |
| Amazon Connect | Connect はコンタクトセンターの基盤（電話・ルーティング）。Lex はその中で会話を理解する部品。置き換え関係ではない |
| Amazon Kendra | Kendra は検索。Lex は対話の制御。FAQ を答えさせたいときは AMAZON.QnAIntent の背後に Kendra や Bedrock ナレッジベースを置く |
| Amazon Comprehend | Comprehend は文書に対するバッチ的な NLP（実体・感情・PII）。Lex は会話のターンを回す。試験で「意図認識」の語が出たら会話文脈かどうかを見る |
| Amazon Polly / Transcribe | Lex は ASR と NLU を内包する。単に音声を文字にしたいだけなら Transcribe、読み上げだけなら Polly |
| Amazon Q Business | Q Business は社内データに対する既製のアシスタント。Lex は自分で対話設計を書く部品 |
想起チェック
Q1. 「FM に会話させる」案ではなく Lex を選ばせる、シナリオ中のキーワードは？
必須項目を必ず収集する／同じ入力に同じ経路を通すという決定性の要求です。プロンプトで「必ず聞け」と指示しても保証にはならず、スロットの充足という構造で担保するのが Lex の役割です。
Q2. 既存の Lex ボットに社内文書ベースの自由回答を足したい。何を追加しますか。
AMAZON.QnAIntent です。OpenSearch Service・Kendra インデックス・Bedrock ナレッジベースのいずれかを繋ぎ、Bedrock のモデルで回答させます。FAQ の数だけインテントを作る必要はありません。
Q3. 2つのインテントのスコアが 0.75 と 0.72 で拮抗しています。どこで捌きますか。
ダイアログコードフックの Lambda です。alternativeIntents（最大4件）とスコアを見て、ConfirmIntent で確認するか ElicitSlot で聞き直します。スコアは比較値なので、絶対値の閾値を焼き込む設計にはしません。
Q4. スロット値を聴取している最中に、無関係な質問が来ました。`AMAZON.QnAIntent` は答えますか。
答えません。 QnAIntent が起動するのは、発話がどのインテントにも分類されなかったときだけで、スロット聴取中の外れた発話では起動しないと公式が明記しています。