Amazon Connect AIエージェントのオーケストレーションとセルフサービスタイプで、無音時の挙動を比べてみた

はじめに

Amazon Connect AIエージェントのセルフサービスを電話チャネルで使う場合、ユーザーが無言のまま待っていたり、声が小さくて認識されなかったりしたとき、AIがどう振る舞うのか気になっていました。

今回は、オーケストレーションタイプとセルフサービスタイプで、発話が入らなかった場合にどのような挙動になるのかを確認してみました。

先に結論を書くと、オーケストレーションタイプでは無音が AI エージェント側のイベントとして扱われ、再度の問いかけが行われました。
一方でセルフサービスタイプでは、Lex 側では無音判定が発生していても、それが AI エージェント側のイベントとして処理されず、顧客が実際に発話するまで AI からの再案内は行われませんでした。

前提条件

今回の確認では、以下の前提で試しています。

• オーケストレーションタイプとセルフサービスタイプ、どちらも基本的にはデフォルトの AI プロンプトを利用（セルフサービスタイプは日本語で確認しやすいよう調整）
• 電話チャネルで動作確認

比較したかったのは業務ロジックではなく、発話がない場合に AI がどう振る舞うかなので、できるだけシンプルな構成にしています。

先に結論

Lex の音声タイムアウトについて

電話チャネルで無音時の挙動を見るうえで押さえておきたいのが、Lex の x-amz-lex:audio:start-timeout-ms です。

x-amz-lex:audio:start-timeout-ms:<intentName>:<slotName>
ボットが顧客は話さないと見なすまでの待ち時間
デフォルト = 4,000 ミリ秒 (4 秒)
https://docs.aws.amazon.com/ja_jp/lexv2/latest/dg/session-attribs-speech.html#voice-input-time-out

今回の確認では、Lex の音声タイムアウト自体はセルフサービスタイプでも発生していました。つまり、両タイプの違いは「Lex が無音を検知するかどうか」ではなく、「その無音検知が AI エージェントの会話イベントとして扱われるかどうか」にあります。

この待ち時間は、[顧客の入力を取得する] ブロックのセッション属性で調整できます。

ユーザーが少し考えてから話すことが多い業務では、必要に応じてこの待ち時間を長めに設定してもよいでしょう。

オーケストレーションタイプで無音時の挙動を確認

実際の流れ

今回のログでは、最初の案内のあと無音が続いた際に、AI エージェントが繰り返し話しかけていました。

1. [AI] 最初の案内を実施
2. [ユーザー] 無音
3. [AI] 「何かお困りのことはございますか」と再案内
4. [ユーザー] 無音
5. [AI] 別の表現で再度問いかけ

デフォルトでは x-amz-lex:audio:start-timeout-ms が 4 秒のため、約 4 秒間無音が続くと AI エージェントから再案内される挙動になります。厳密には処理時間や応答生成時間もあるため、ログ上の間隔がぴったり 4 秒になるわけではありませんが、挙動としてはそのように見て問題ありません。

ログを確認すると空入力がイベントになっていた

Lex ログを見ると、無音時でも inputTranscript は空文字、missedUtterance=true で記録されていました。

"inputTranscript":"","missedUtterance":true

AI エージェント側のログでは、内部的に <EMPTY_USER_INPUT> として扱われていました。

"user"
"<EMPTY_USER_INPUT>"

そのうえで AI エージェントから BOT 応答が返っており、実際のログには以下のような内容が残っていました。

こんにちは。本日はどのようなご用件でしょうか。お手伝いできることがございましたら、お気軽にお申し付けください。

続く無音でも、同様に BOT が再案内していました。

何かお困りのことはございますか。ご質問やご不明な点がございましたら、どうぞお聞かせください。

お手伝いできることがございましたら、いつでもお声がけください。ご質問やご相談がございますでしょうか。

セルフサービスタイプで無音時の挙動を確認

実際の流れ

セルフサービスタイプでは、無音が続いても AI エージェントからの働きかけは行われませんでした。

1. [AI] 最初の案内を実施
2. [ユーザー] 無音
3. [ユーザー] 無音（AI エージェントからの問いかけはない）
4. [ユーザー] 「こんにちは」と発話
5. [AI] 「こんにちは！本日はどのようなご用件でしょうか？」と応答

顧客が実際に話すまで、AI エージェント側の会話処理は進んでいませんでした。

ログを確認すると発話があるまで AI 側の処理が走っていなかった

実際のログでは、顧客が「こんにちは」と発話するまでの約1分間、TRANSCRIPT_SELF_SERVICE_MESSAGE イベントは一件も記録されていませんでした。セッション開始のイベントのみが記録されており、その後は無音が続いていました。

event_type: TRANSCRIPT_CREATE_SESSION  ← セッション開始
（約1分間、イベントなし）
event_type: TRANSCRIPT_SELF_SERVICE_MESSAGE  ← [CUSTOMER] こんにちは

また、このとき AI に渡された会話履歴を確認すると、無音のターンが以下のように積み上がっていました。

[AGENT] ...
[CUSTOMER] 
[AGENT] ...
[CUSTOMER] 
[AGENT] ...
[CUSTOMER] 
（以降、同様のやり取りが繰り返し）
[CUSTOMER] こんにちは

Lex 側では NoInput が繰り返し発生し、その都度空の [CUSTOMER] ターンが会話履歴に追加されていました。しかし、それらはいずれも TRANSCRIPT_SELF_SERVICE_MESSAGE イベントとして記録されておらず、顧客への応答にもなっていませんでした。ユーザーからすると、話しかけても反応がなく「繋がっているのかわからない」状態に見えやすい挙動です。

声が小さくて認識されなかった場合

ユーザーが実際には発話していても、声が小さいなどの理由で認識されなかった場合、挙動としては無音時と同じように扱われます。

実際に確認したところ、小さい声で「はい」と伝えた場合、音声ファイル上ではユーザーの「はい」が聞こえている一方で、ログ上ではその発話が認識されず、Lex 側では NoInput が続いていました。セルフサービスタイプでは、この NoInput も AI エージェント側のイベントとして処理されないため、発話したつもりでも AI からの反応がない状態が続きます。

そのため、実運用上は「無音」と「小さすぎて認識されなかった発話」はほぼ同じ観点で考えてよさそうです。

まとめ

Amazon Connect AIエージェントのオーケストレーションタイプとセルフサービスタイプで、無音時の挙動を確認してみました。

Lex 側の無音判定自体はどちらでも発生していました。ただし、オーケストレーションタイプではその無音が AI エージェント側のイベントとして扱われ、AI から再案内が行われました。セルフサービスタイプでは無音イベントが AI エージェント側の会話として処理されず、顧客が実際に発話するまで再案内は行われません。

また、ユーザーの声が小さくて認識されなかったケースも、挙動としては無音時と同じように扱われます。

電話チャネルでセルフサービスを安定運用したい場合は、無音時の再案内を行えるオーケストレーションタイプの方が扱いやすいと感じました。あわせて、x-amz-lex:audio:start-timeout-ms を [顧客の入力を取得する] ブロックのセッション属性で調整できる点も、実運用時のチューニングに役立ちそうです。