【Amazon Lex #6】Amazon Connectを活用してLexの文字起こし精度を向上させてみる

Posted at 2026-04-08

はじめに

こんばんは、mirukyです。
Amazon Lex シリーズ最終回（第6回）です。

ここまでの5回で、Amazon Lexの基本概念から始まり、ボット構築、Lambda連携、Connect統合、そして音声認識精度の向上テクニックまでを一通り解説してきました。

最終回の今回は、Amazon Connectの機能を活用して、Lexの文字起こし精度をさらに向上させることをテーマにします。#5で紹介した個々のテクニックを組み合わせ、Connectの音声処理パイプライン全体を最適化することで、実運用レベルの音声ボットを構築します。

出典：Amazon Lex V2 のランタイムヒント - AWS

Connectの音声処理パイプラインと精度への影響
Runtime Hints APIによる動的な音声認識ヒント
セッション属性を活用した文脈の引き継ぎ
コンタクトフローの音声設定最適化
Contact Lensを活用した文字起こし分析
テクニックの組み合わせ：実運用アーキテクチャ
おわりに

1. Connectの音声処理パイプラインと精度への影響

1-1. 音声がテキストになるまでの流れ

Amazon Connect経由でLexボットを利用する場合、音声は以下の順序で処理されます。

①発信者が電話で発話します。この段階では話速・音量・周囲ノイズが精度に影響します。
↓
②Connectが8kHz音声として受信し、サンプリングレートやコーデックが精度を左右します。
↓
③「顧客の入力を取得する」ブロックがLexに音声を送信します。ここではタイムアウトやDTMFなどのブロック設定が影響します。
↓
④Lex ASR（自動音声認識）が音声をテキストに変換する段階では、カスタムボキャブラリーや言語モデルが認識精度を決定します。
↓
⑤Lex NLU（自然言語理解）がインテントとスロットを抽出します。サンプル発話やスロットタイプの設計が精度に直結します。
↓
⑥Lambda（コードフック）が結果を処理し、信頼度スコアの活用やバリデーションによって最終的な応答品質を担保します。

1-2. 各ステップで適用できるテクニック

ステップ	適用テクニック	解説セクション
②	音声設定の最適化	4
③	DTMF併用（#5で解説済み）	-
④	Runtime Hints API、カスタムボキャブラリー	2, 5
⑤	アシスト付きNLU、アシスト付きスロット解決	5
⑥	セッション属性による文脈引き継ぎ	3
全体	Contact Lensによる分析と改善	5

2. Runtime Hints APIによる動的な音声認識ヒント

2-1. Runtime Hints APIとは

Runtime Hints APIは、会話の途中でASRに対して「次に認識すべき語句のヒント」を動的に提供する機能です。#5で解説したカスタムボキャブラリーが静的（事前定義） なのに対し、Runtime Hintsは動的（リアルタイム） に認識精度を向上できます。

比較項目	カスタムボキャブラリー	Runtime Hints API
設定タイミング	ビルド時（事前定義）	実行時（動的）
更新方法	ファイルのアップロード＋ビルド	API呼び出し
対象	ボット全体に共通の語句	個々のセッションに固有の語句
ユースケース	業界用語、ブランド名	顧客名、過去の注文番号

2-2. Lambda関数でのRuntime Hints設定

Lambda関数（コードフック）から、レスポンスにsessionState.runtimeHintsを含めることでヒントを設定できます。

import json

def lambda_handler(event, context):
    """Runtime Hintsを設定するLambda関数"""

    intent_name = event["sessionState"]["intent"]["name"]
    session_attributes = event["sessionState"].get("sessionAttributes", {})

    # 顧客IDから過去の注文番号をDBで検索した想定
    recent_order_ids = ["ORD-001", "ORD-042", "ORD-108"]

    # Runtime Hintsの構築
    runtime_hints = {
        "slotHints": {
            intent_name: {
                "OrderId": {
                    "runtimeHintValues": [
                        {"phrase": order_id} for order_id in recent_order_ids
                    ]
                }
            }
        }
    }

    return {
        "sessionState": {
            "dialogAction": {
                "type": "ElicitSlot",
                "slotToElicit": "OrderId"
            },
            "intent": event["sessionState"]["intent"],
            "sessionAttributes": session_attributes,
            "runtimeHints": runtime_hints  # ここでヒントを設定
        },
        "messages": [
            {
                "contentType": "PlainText",
                "content": "ご注文番号をお教えください。"
            }
        ]
    }

2-3. Connect + Lambda + Runtime Hintsの連携フロー

顧客がConnectに電話をかける
コンタクトフローで 「顧客の入力を取得する」 ブロックがLexボットを呼び出す
LexのDialogコードフック（Lambda）が起動
Lambdaが顧客情報をDBから取得し、関連する語句のRuntime Hintsを設定
Lexがヒントを参考にASR精度を向上させた状態でスロット値を収集
Fulfillmentコードフック（Lambda）が注文状況を回答

Runtime Hints APIが特に効果を発揮するケース

ケース	ヒントとして提供する情報
リピーターの注文確認	過去の注文番号
会員制サービス	会員番号、登録名
予約システム	予約番号、施設名
社内ヘルプデスク	社員名、部署名

ユーザーごとに異なる値をヒントとして提供することで、「その人が言いそうな値」をASRが優先的に認識するようになります。

3. セッション属性を活用した文脈の引き継ぎ

3-1. セッション属性とは

セッション属性は、Lexの会話セッション中にキーバリュー形式でデータを保持する仕組みです。Connect側（コンタクトフロー）とLex側（Lambda）の双方からアクセスできます。

3-2. Connectコンタクト属性との連携

Connectのコンタクト属性をLexのセッション属性として渡すには、「顧客の入力を取得する」ブロックで明示的にセッション属性を設定する必要があります。コンタクト属性が自動的にセッション属性へ引き継がれるわけではない点に注意してください。

コンタクトフローでの設定

「コンタクト属性の設定」ブロックでコンタクト属性を準備します。
「顧客の入力を取得する」ブロックのセッション属性セクションで、Lexに渡したい値を追加します。

送信先の種類	キー	値
ユーザー定義	`customerTier`	`premium`
ユーザー定義	`callerPhoneNumber`	システム属性「顧客の電話番号」

3-3. Lambda関数でのセッション属性活用

def lambda_handler(event, context):
    """セッション属性を活用したインテリジェントな応答"""

    session_attributes = event["sessionState"].get("sessionAttributes", {})

    # Connectから渡された顧客情報
    customer_tier = session_attributes.get("customerTier", "standard")
    caller_phone = session_attributes.get("callerPhoneNumber", "")

    # 電話番号から顧客情報をDB検索
    customer = lookup_customer_by_phone(caller_phone)

    if customer:
        # 顧客の過去注文番号をRuntime Hintsとして設定
        recent_orders = customer.get("recentOrders", [])

        # セッション属性に顧客名を保存（後続の会話で利用）
        session_attributes["customerName"] = customer["name"]
        session_attributes["customerId"] = customer["id"]

        runtime_hints = build_runtime_hints(
            event["sessionState"]["intent"]["name"],
            recent_orders
        )

        greeting = f'{customer["name"]}様、お電話ありがとうございます。'
    else:
        runtime_hints = {}
        greeting = "お電話ありがとうございます。"

    # 顧客ランクに応じた対応分岐
    if customer_tier == "premium":
        greeting += "プレミアム会員のお客様ですね。"

    return {
        "sessionState": {
            "dialogAction": {
                "type": "ElicitSlot",
                "slotToElicit": "OrderId"
            },
            "intent": event["sessionState"]["intent"],
            "sessionAttributes": session_attributes,
            "runtimeHints": runtime_hints
        },
        "messages": [
            {
                "contentType": "PlainText",
                "content": f"{greeting}ご注文番号をお教えください。"
            }
        ]
    }


def lookup_customer_by_phone(phone_number):
    """電話番号から顧客情報を検索（簡略化）"""
    customers = {
        "+819012345678": {
            "name": "田中",
            "id": "C-001",
            "recentOrders": ["ORD-001", "ORD-042"]
        }
    }
    return customers.get(phone_number)


def build_runtime_hints(intent_name, order_ids):
    """Runtime Hints構造体を構築"""
    if not order_ids:
        return {}
    return {
        "slotHints": {
            intent_name: {
                "OrderId": {
                    "runtimeHintValues": [
                        {"phrase": oid} for oid in order_ids
                    ]
                }
            }
        }
    }

セッション属性 → Runtime Hintsの活用パターン

Connectがコンタクト属性（電話番号など）をLexのセッション属性に渡す
Lambda（Dialogコードフック）がセッション属性から電話番号を取得
DBから顧客の過去データ（注文番号、商品名など）を取得
取得した値をRuntime Hintsとして設定
ASRがその顧客に関連する値を優先的に認識

これにより、顧客ごとにパーソナライズされた音声認識が実現します。

4. コンタクトフローの音声設定最適化

4-1. 音声の設定ブロック

コンタクトフローの 「音声の設定」 ブロックで、テキスト読み上げの設定を最適化することで、ユーザーの発話品質（≒聞き取りやすさ）を間接的に改善できます。

設定項目	推奨値	理由
言語	日本語（日本）	日本語の音声認識と整合
音声	Kazuha	日本語の女性音声
その他の設定	ニューラル発話スタイル	スタンダートよりも高品質

4-2. プロンプトの設計による精度向上

ボットの発話（プロンプト）を工夫することで、ユーザーの応答パターンを認識しやすい形に誘導できます。

設計方針	悪い例	良い例
具体的に指示する	「何かお手伝いしますか？」	「注文の確認、返品、お問い合わせの中から選んでください。」
フォーマットを指定する	「注文番号をどうぞ」	「注文番号を、ORDハイフンの後の3桁の数字でお教えください。」
選択肢を限定する	「どうされますか？」	「確認する場合は『はい』、やり直す場合は『いいえ』とお答えください。」

発話の長さに注意
長すぎるプロンプトは途中で遮られる（バージイン）可能性があります。1つのプロンプトは30〜50文字程度を目安にし、必要な情報を簡潔に伝えましょう。

4-3. SSMLの活用

前回（#4）でも触れましたが、SSML（Speech Synthesis Markup Language）でプロンプトの読み上げを細かく制御できます。

<speak>
  注文番号は
  <say-as interpret-as="spell-out">ORD</say-as>
  <break time="300ms"/>
  ハイフン
  <break time="300ms"/>
  <say-as interpret-as="digits">001</say-as>
  ですね。
  <break time="500ms"/>
  お調べします。
</speak>

「プロンプトの再生」ブロックなどに設定できます。

スペルアウトやポーズの挿入により、復唱した内容がユーザーに正確に伝わるため、確認ステップの信頼性が向上します。

5. Contact Lensを活用した文字起こし分析

Contact Lens の利用にはクォータ引き上げ申請が必要な場合があります
新規の Amazon Connect インスタンスでは、Contact Lens 関連のサービスクォータ（同時リアルタイム通話分析数、同時自動インタラクション分析ジョブ数など）がデフォルトで低く設定されています。Service Quotas コンソールから引き上げ申請が可能ですが、 承認までに数日から最長3週間かかる ケースがあります。検証目的で Contact Lens をすぐに試したい場合は、事前にクォータ申請を済ませておくことをおすすめします。

5-1. Contact Lensとは

Contact Lens for Amazon Connectは、通話内容をリアルタイムで文字起こし・分析する機能です。Lexボットとの会話だけでなく、オペレーターとの通話もカバーします。

機能	説明
リアルタイム文字起こし	通話中にリアルタイムで音声をテキスト化
感情分析	顧客の感情（ポジティブ/ネガティブ/ニュートラル）を検出
キーワード検出	指定したキーワード（例：「解約」「苦情」）の出現を監視
通話要約	生成AIによる通話内容の自動要約

5-2. Contact Lensの有効化

Amazon Connectコンソールでインスタンス設定を開く
「Contact Lens統合」 セクションを有効化
コンタクトフローの 「記録と分析の動作を設定」 ブロックで Contact Lens を有効にする

設定項目	推奨値
音声分析	リアルタイム分析を有効化
文字起こし言語	日本語（ja-JP）
感情分析	有効化
機密データのマスキング	ユースケースに応じて有効化

5-3. Lexの音声認識改善にContact Lensを活用する方法

Contact Lens自体はASR精度を直接向上させるものではありませんが、ASR結果の分析と改善サイクルに非常に有用です。

分析内容	改善アクション
誤認識が多い単語の特定	カスタムボキャブラリーに追加
FallbackIntentへの遷移率	サンプル発話の追加・インテント設計の見直し
スロット値の誤認識パターン	カスタムスロットタイプのシノニム追加
ユーザーが繰り返している箇所	プロンプトの改善、DTMF入力の追加
顧客がネガティブな感情を示す箇所	UXの改善、早期のオペレーター転送

改善サイクルのベストプラクティス

Contact Lensのダッシュボードで週次の音声認識品質レポートを確認
誤認識の多い語句をカスタムボキャブラリーに反映
新しい発話パターンをサンプル発話に追加
ビルドしてテスト → デプロイ
翌週のレポートで改善を確認

データに基づいた継続的な改善が、音声ボットの品質を最も確実に向上させます。

6. テクニックの組み合わせ：実運用アーキテクチャ

6-1. 最終的なアーキテクチャ全体像

本シリーズで構築してきた音声ボットの全体像を整理します。

全体の処理フローは以下の通りです。

① Amazon Connect（音声入力の受付）

音声設定（Kazuha）でコンタクト属性を設定し、顧客の入力を取得
Contact Lensがリアルタイム文字起こし・分析を実行

② Amazon Lex V2（ASR + NLU）

カスタムボキャブラリー（静的ヒント）によるインテント認識 + スロット抽出
Runtime Hints（動的ヒント）によるアシスト付きNLU + アシスト付きスロット解決

③ AWS Lambda（コードフック）

信頼度スコアチェック、セッション属性管理、DB参照 + 応答生成

段階的な導入がおすすめ
すべてのテクニックを一度に導入する必要はありません。まずは初期構築フェーズのテクニックを適用してボットをリリースし、Contact Lensの分析結果を見ながら精度改善フェーズ → 高度な最適化フェーズへと進むのが現実的です。

6-2. Connect + Lex音声ボットの運用チェックリスト

実運用に入る前に確認すべき項目をチェックリストとして整理します。

カテゴリ	チェック項目
インテント設計	サンプル発話は各インテントに20個以上あるか
スロット設計	値が限定的なスロットにカスタムスロットタイプを使っているか
音声認識	カスタムボキャブラリーで固有名詞を登録したか
音声認識	英数字入力にDTMFの選択肢を用意したか
エラー処理	信頼度スコアが低い場合の再確認フローがあるか
エラー処理	FallbackIntentに有人転送のロジックがあるか
プロンプト	ボットの発話は具体的で、ユーザーの応答を誘導しているか
テスト	複数の話者で電話テストを実施したか
モニタリング	会話ログ（CloudWatch / S3）が有効になっているか
モニタリング	Contact Lensが有効化されているか

7. おわりに

ここまでお読みいただきありがとうございます。
全6回にわたるAmazon Lexシリーズをここで終了とします。

Amazon LexはASR・NLU・LLMを組み合わせた高度な会話AIプラットフォームです。AWSの他のサービス（Connect、Lambda、Bedrock、Contact Lens）と連携させることで、実運用レベルの音声ボットを構築できます。

今回のシリーズが、みなさんの音声ボット開発の参考になれば幸いです。

ではまた、お会いしましょう。

参考リンク

Amazon Lex V2 公式ドキュメント

Amazon Connect 公式ドキュメント

Amazon Lex シリーズ記事

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up