Amazon Lex

解決する課題

問い合わせ対応や予約受付などを人手のオペレーターだけで回すと、対応時間が限られコストもかさみます。会話ボットを自前で作ろうとすると、自然言語の理解や対話状態の管理、音声認識・合成の連携など、多くの要素を組み合わせる必要があり大変です。Amazon Lex を使うと、こうした会話インターフェースをマネージドサービスとして構築できます。

• ユーザーの発話から意図（やりたいこと）を理解し、必要な情報を聞き出す
• テキストチャットと音声通話の両方に同じ会話ロジックで対応できる
• コールセンター（Amazon Connect）やメッセージング、Web チャットに組み込める

音声認識・合成や自然言語理解の基盤を自分で持たずに、対話設計に集中できる点が中心的な価値です。Amazon Alexa と同じ技術を土台にしています。

主要概念と用語

• ボット: 会話アプリケーション全体を表す単位。1 つ以上の意図をまとめて持つ
• インテント（意図）: ユーザーが達成したい目的。たとえば「ホテルを予約する」「残高を照会する」など。ボットはどのインテントかを判定する
• 発話例（サンプル発話）: そのインテントを引き起こす言い回しの例。これを学習に使い、表現の揺れを吸収する
• スロット: インテントを満たすために必要な情報の項目。たとえば予約なら「日付」「人数」など。値の型（スロットタイプ）を持つ
• スロットタイプ: スロットに入る値の種類。組み込み型（数値・日付など）と、独自に定義するカスタム型がある
• プロンプト: スロットの値が未入力のときにユーザーへ問い返す質問文
• フルフィルメント: インテントに必要な情報がそろった後の実行処理。多くは Lambda 関数で業務ロジックを呼び出す
• NLU（自然言語理解）: 発話からインテントとスロット値を抽出する処理。Lex の中核
• エイリアス／バージョン: ボットを段階的に公開・更新するための仕組み。本番に向ける向き先がエイリアス

仕様・制限・クォータ

• テキストと音声の両方の入力に対応し、音声では内部で音声認識と音声合成（Amazon Polly 相当の読み上げ）を扱える
• 複数の言語・ロケールに対応し、1 つのボットに複数ロケールを設定できる
• 1 つのボットに登録できるインテント数、インテントあたりのスロット数、サンプル発話数などにアカウント単位のクォータがあり、引き上げ申請が可能
• 会話の途中状態（どのスロットまで埋まったか）はセッションとして管理され、セッションには有効期限の概念がある
• フルフィルメントやスロット確認のために Lambda を呼び出すフックを各所に差し込める

具体的な上限値・対応言語・対応チャネルは更新されるため、最新の公式ドキュメントで確認してください。なお現行世代は「Amazon Lex V2」が標準で、API やコンソールの構成が旧世代と異なります。

内部の仕組み

利用者から見ると、発話テキストや音声を渡すと、Lex がインテントとスロットを推定し、不足情報を問い返したり、そろった時点で処理を実行したりする対話エンジンとして扱えます。

• NLU エンジン: サンプル発話から学習したモデルが、入力をいずれかのインテントに分類し、文中からスロット値を抽出する
• 対話管理: まだ埋まっていない必須スロットがあればプロンプトでユーザーに問い返し、すべてそろうとフルフィルメントへ進む。この状態遷移を Lex が自動で管理する
• Lambda フック: 値の検証や外部システム照会、最終的な業務処理のために Lambda を呼び出し、その結果で次の応答を組み立てる
• 音声経路: 音声入力時は音声認識でテキスト化し、同じ NLU・対話管理を通し、応答を音声合成で返す

モデルの学習やスケーリング、基盤の運用はすべて AWS 側が担います。利用者はインテント・スロット・プロンプトという宣言的な定義を用意するだけです。

設計パターン / ベストプラクティス

• インテントは粒度をそろえる: 1 インテント 1 目的を基本にし、似すぎたインテントは誤分類の原因になるため統合や言い回しの整理を行う
• サンプル発話を多様にする: 同じ意図でも言い方は多様なので、口語・敬語・短縮形など幅広い例を登録して認識精度を上げる
• フルフィルメントは Lambda に寄せる: 予約確定や在庫照会などの業務ロジックは Lambda で実装し、ボット定義は会話の流れに専念させる
• エイリアスで安全に更新: 本番チャネルはエイリアス経由で向け、新バージョンを検証してからエイリアスを切り替える
• 想定外への備え: 意図が取れない場合のフォールバック応答や、有人対応への引き継ぎ経路を用意する

運用・監視

• API 呼び出し数や会話の状況は CloudWatch のメトリクス・ログで監視する
• 会話ログ（テキスト・音声）を有効化し、実際の発話を蓄積して認識精度の改善や FAQ の発見に使う
• API 操作の監査証跡は CloudTrail に記録される
• 誤分類が多いインテントは、会話ログを見てサンプル発話を追加し、再ビルドして改善する
• ボットの更新はバージョンを作成し、エイリアスの向き先を切り替える運用にする

コスト

• 課金は基本的に処理したリクエスト数に対する従量制で、テキストリクエストと音声リクエストで単価が異なる傾向がある
• サーバーの常時起動費用は発生せず、会話が発生した分だけ課金される
• 連携する Lambda の実行料金や、会話ログを保存する CloudWatch Logs・S3 などの費用は別途かかる

具体的な単価は変動するため、料金は公式の料金ページで確認してください。少量のテスト会話で検証してから本番のトラフィックを見積もるのが安全です。

セキュリティ

• アクセス制御は IAM で行い、ボットの管理権限と実行時に呼ぶ Lambda などへの権限を最小限に絞る
• 通信は TLS で保護され、会話ログなどの保存データは S3・CloudWatch Logs 側の暗号化（KMS 管理鍵を含む）で保護できる
• 機微情報を扱うスロットは、ログ上でのマスキングや取り扱い方針を検討する
• VPC 内のリソースへフルフィルメントから接続する場合は、Lambda の VPC 設定や適切なネットワーク経路を用意する

Well-Architected の観点

• 運用上の優秀性: マネージドサービスで運用負荷を下げ、会話ログと CloudWatch で継続的に精度を改善できる
• セキュリティ: IAM の最小権限、保存・転送時の暗号化、機微発話の取り扱い方針でユーザー情報を保護する
• コスト最適化: 従量課金のため、不要な会話経路を整理し、Lambda の処理も軽量に保つ
• 信頼性: フォールバックや有人引き継ぎを用意し、Lambda 失敗時の応答も含めて行き止まりのない対話を設計する

試験で問われるポイント

関連サービス・比較

文章を生成する基盤モデルを扱う Amazon Bedrock とは目的が異なるため、混同しやすい点を比較します。

ハンズオン / CLI例

# ボットの一覧を確認（Lex V2 の API）
aws lexv2-models list-bots \
  --query "botSummaries[].{Name:botName,Id:botId,Status:botStatus}"

# テキストでボットに発話を送り、応答を受け取る（実行時 API）
aws lexv2-runtime recognize-text \
  --bot-id BOT_ID \
  --bot-alias-id ALIAS_ID \
  --locale-id ja_JP \
  --session-id demo-session-1 \
  --text "明日のホテルを予約したい"