Lex V2 (ja-JP・電話8kHz音声) で発話終了からASR確定まで約2秒かかる — 短縮方法はあるか

質問1: これは仕様（想定内)か

断定できる公式ドキュメントは見当たりませんでしたが、アーキテクチャ的にみて構造的な制約である可能性が高いです。

RecognizeUtteranceの内部処理は、音声（8kHz PCM）→Lex内蔵STT→テキスト→NLU→インテントマッチという直列パイプラインになっています。

つまりLexの音声認識エンジンは、発話終了を検知してから発話全体をバッファとして後処理するアーキテクチャであり、リアルタイムストリーミングでインクリメンタルに確定していく方式ではないと考えられます。これは、発話が長いほど確定が遅くなるという実測結果（1.4秒発話→1.6秒、2.2秒発話→2.4〜3.0秒）と整合的です。

ただし、AWS公式ドキュメントに「ja-JP/8kHz/Neuralでの想定レイテンシ範囲」を明記した記述は見つかりませんでした。この点は推測の域を出ないため、確実な仕様として断定はできません。

質問2: 確定時間を短縮できる設定はあるか

現在の設定調整だけでの大幅な短縮は期待しにくいです。 検証されたA/Bテスト（UseSlotValuesAsCustomVocabulary除去）で有意差が出なかった点からも、スロット構成・語彙側のチューニングでは限界がある可能性が高いです。

質問3: 発話長比例の遅延を一定に抑える方法

根本的な解決には、Lex内蔵STTをバイパスするアーキテクチャ変更が必要になる可能性が高いです。

Lexにvia RecognizeUtteranceで音声を送ると、内部でLex内蔵STT→テキスト→NLUという流れになりますが、この内蔵STTを使わず、音声を先にAmazon Transcribeでストリーミング処理し、テキスト化した結果をLexのRecognizeText（NLUのみ）に渡すという構成が提案されています。

【現状のパス】 Caller Audio → Lex RecognizeUtterance （内蔵STT + NLU、まとめて後処理）

【改善パス】 Caller Audio → Amazon Transcribe Streaming （逐次・インクリメンタルにテキスト化） → Lex RecognizeText（NLUのみ）

Transcribe Streamingは音声を受信しながら継続的に部分認識結果を返すため、発話終了時点で「ほぼ確定済みのテキスト」が既に用意されており、Lexに渡すのはNLU処理のみで済みます。これにより、発話長に比例して確定時間が伸びる問題を軽減できる可能性があります。

推奨する次のアクション: AWSサポートケースの起票（優先度高）

今回のような「内部処理の挙動そのもの」に関する質問は、公開ドキュメントでは確認できない領域のため、既に取得済みの実測データ（発話長と確定時間の相関、RecognizeUtterance単体再現データ）を添えてAWSサポートに問い合わせるのが最も確実です。