音声AIの予約変更で、聞き直し・割り込み・保存結果をどう扱うか

「やっぱり別の日に」が、予約処理に間に合うか

音声AIが予約日時を読み上げている途中で、利用者が「やっぱり別の日に」と言ったとする。 AIの声は止まった。しかし、裏で予約を保存する処理は進んでいた。これは設計上の問題を説明する想定例である。発話の割り込みと、業務操作の取り消しは、別々に扱う必要がある。

本稿では予約変更を一つの題材に、音声の入力、会話の訂正、実際の保存をどう結び付けるかを考える。 2026年4月6日までの公開資料を基に、方式の違いと試験の観点を整理する。声の自然さと業務の正確さの両方を、同じ通話で確認するための読み方である。

OpenAIの音声エージェントガイドは、音声を直接入出力するspeech-to-speechと、音声認識・テキストでの推論・音声合成をつなぐ方式を区別している。前者は低遅延の会話、後者は各段階を明示的に制御する構成として説明される。

予約変更でテキストを中間に置けば、認識した日時を確認してから次の処理へ渡す場所を作りやすい。ただし、文字起こし自体が間違う場合はある。テキストが残るだけで、正確さや監査要件を満たすとは言えない。音声を直接扱う方式でも、確定した予約内容を構造化して確認する設計は可能である。

したがって、片方を一律に安全、もう片方を一律に自然と決めるのではなく、同じ予約課題で比べたい。利用者が話し終えてから応答が聞こえるまでの待ち時間と、日時の取り違え、訂正後の保存結果をそれぞれ見る。既存のテキスト処理を再利用したいかどうかも、方式選択の条件になる。

Google Live APIの説明は、発話検出による割り込み時に生成を止める動作と、アプリ側で再生を止め、待機中の音声を消す処理を示している。サーバーの生成が止まっても、端末にたまった音声を流し続ければ、利用者には話し続けているように聞こえる。

ここに予約APIを加えると、もう一つ状態が増える。割り込みを受けた時点で、まだ候補を読み上げているのか、保存要求を送ったのか、保存完了まで確認できたのかを区別する。すでに保存済みなら、新しい日時への変更や取消手順が必要であり、音声を止めても保存は巻き戻らない。

私なら、復唱した候補と利用者が確認した候補を結び付け、訂正が入った時点で古い候補を未確定に戻す。保存要求後の訂正では結果を照合し、処理状況に合う案内を返す。返答を急ぐあまり、保存結果が分からない段階で「変更しました」と言わないことが重要になる。

AWSの2026年2月2日のAmazon Connect発表は、用件、期待する応答、営業時間外などの条件を指定して音声対話をシミュレーションするAPIを説明している。同じ条件を繰り返して分岐を確かめる仕組みとして参考になる。

予約の試験には、言い直し、長めの間、同時発話、数字の聞き違い、APIの遅延、保存直後の切断を含めたい。返答文だけでなく、保存された日時と、利用者が実際に聞いた案内が一致するかを確かめる。シミュレーションに加えて、想定する端末、回線、話者、騒音の条件で音声を通し、再生停止や聞き取りも確認する。

人へ引き継ぐ場合は、聞き取った希望だけでなく、保存済みか、結果不明か、未実行かを渡す。そうすれば、担当者が同じ変更をもう一度行うのを避けやすい。音声モデルの選択と並行して、この通話で何が確定したのかを一貫して扱うことが、予約変更を完了させるための設計課題である。