話し始めたらAIが止まり、古い音声を再生しない仕組みは？
まず図全体の流れを見て、細部は「原寸で読む」を開いて確認してください。原寸の図は横にスクロールできます。正常な流れの次に、失敗時の分岐を追いましょう。
音声を追加すると時間の意味が変わる
テキストでは多少待ってから回答を読むこともできます。音声では沈黙や話しかぶりが会話の一部になります。必要なのは音声を送る接続だけでなく、誰のターンか、いつ発話が終わったか、割り込まれた回答をどう止めるかという制御です。この章は特定製品のインターフェース仕様ではなく、学習用の概念設計を示します。
二つの基本構成があります。連鎖型はSTT（音声認識）で文字にし、LLMで回答を作り、TTS（音声合成）で読み上げます。speech-to-speech型は音声を入力し音声を出力するモデルを中心にします。後者でも、ツールや権限、会話状態を管理するアプリ側の責任は残ります。
原寸で読む（横にスクロール）
図は論理的な責任の比較です。直接処理モデルの内部構造を断定するものではありません。連鎖型は各段階を観測・置換しやすい一方、誤認識と段階間の待ちが積み重なります。直接処理は声の調子などを扱える可能性があるが、監査に使う文字記録の位置づけを別途決める必要があります。
メディアと制御を分ける
WebRTCは音声などのメディアを運ぶ仕組みを提供します。接続条件の交換であるシグナリングは、別のHTTPやWebSocket経路などで設計します。SDPはメディアの条件を記述し、ICEは接続候補を集めて到達可能な経路を選びます。STUNは外部から見えるアドレスの発見を助け、直接つながらない場合にはTURN中継が必要になることがあります。WebRTCの接続ガイドに接続とシグナリングの役割が説明されています。
ブラウザーと音声サーバーが接続する場合も、WebRTCという名称だけで「サーバー不要」にはなりません。中継利用率、帯域、パケット損失、端末のマイク権限を確認します。アプリケーションサーバーは会話の権限を検証し、接続先が対応するなら短命で用途を限定した資格情報を発行します。長期のサービス秘密鍵をブラウザーへ渡してはいけません。
| 経路・状態 | 主な責任 | 所有者の例 |
|---|---|---|
| 音声メディア | 音声フレームの送受信 | ブラウザーと音声接続先 |
| ターン制御 | 発話開始・終端・取り消し | 会話コーディネーター |
| ツール実行 | 認可と副作用の確定 | バックエンド |
| 会話記録 | 確定した出来事の保存 | 永続ストア |
ターンを状態機械として考える
VADは声の有無を推定する仕組みであり、意味的に話し終えたことを保証しません。短い間を終了とみなすと発話を分断し、長く待つと返事が遅れます。無音時間、明示的な送信操作、モデルの推定など、どこでターンを確定するかを決めます。
原寸で読む（横にスクロール）
listening → end_detected → generating → speakingを基本に、各状態から取り消しや失敗へ移れるようにします。生成にはgeneration IDを付けます。利用者が割り込んだら新しい世代へ進み、旧世代の生成停止を要求し、端末の再生キューを消します。停止要求が間に合わず到着した古い音声も世代IDで捨てます。サーバーの停止だけでは、すでに端末で待機している音声は止まりません。
取り消せるものと戻せないもの
原寸で読む（横にスクロール）
話すのを止めても、すでに実行した送金や予約は元に戻りません。音声の割り込みと業務操作の取り消しを同じイベントで扱わず、操作ごとの状態・重複防止キー・確認を持ちます。ツール設計の境界は音声でも変わりません。
音声接続が落ちたら、新しい接続で再認証し、会話と実行の状態を照会します。古い音声を先頭から流すかは体験設計で決めます。たとえば確定テキストを表示して「続けますか」と案内できます。ネットワーク障害のたびに外部操作まで再実行してはいけません。マイク利用不可の場合にも、明確な説明とテキスト入力への導線を用意します。
遅延を段階ごとに測る
「応答が1秒」だけでは原因がわかりません。利用者の発話終端から最初の可聴音までを、終端判定待ち、アップロード、認識、生成、合成、配信、再生待ちに分けます。連鎖型の仮の予算を順に200、50、150、250、150、50、50ミリ秒とすれば合計900ミリ秒です。これは計算例であり実測値ではありません。段階が重なって動く構成では、単純な合計と実際の経過時間は異なります。
中央値だけでなくp95、誤った割り込み、発話切れ、再生停止までの時間を端末条件ごとに確認します。記録も区別します。STTが認識した文字、モデルが生成した文字、実際に再生した音声の内容は一致するとは限りません。何を監査上の記録とするかを明記し、録音の保存・同意・削除も設計に含めます。
設計例と練習
最初は連鎖型で各段階の時間を測り、会話コーディネーターがターンとgeneration IDを持つ構成にします。バックエンドで資格情報とツール認可を管理し、音声データの経路とは分けます。直接処理へ変える場合も、ターンの契約と外部操作の所有者を維持します。
練習と解答
利用者が割り込んだ後、前の回答の音声が遅れて届きました。停止要求をもう一度送るだけでよいでしょうか。解答は、現在のgeneration IDと照合して破棄し、既存の再生キューも消すことです。さらに「予約が完了した直後」の割り込みなら、予約をなかったことにせず、実行記録を確認して確定済みの事実を伝えます。
押さえたいポイント
音声の輸送、ターン管理、生成の取り消し、外部操作の確定を分けて設計する。
出典・さらに読む
- WebRTC: Peer connections内容の確認日: 2026-10-23
- MDN: WebRTC API内容の確認日: 2026-10-23
学習と設計検討のための概念的な構成例です。稼働中のKumyuの実装を表す図ではありません。