声が止まった後に、予約はどうなったか

音声AIが予約の候補を読み上げている途中で、利用者が「やっぱり別の日に」と言う。 AIの声は止まったが、裏では最初の日時を保存する処理が進んでいた。 もう一度希望を伝えると、別の変更要求も送られる。 これは設計を考える想定例である。 利用者が知りたいのは、AIが割り込みに反応したかだけでなく、結局どの日で予約されたかだ。

本稿は2026年4月6日までのOpenAI、Google、Microsoft、AWSの公表資料を、予約変更の通話から読む。 声の自然さ、応答を待つ時間、訂正、外部処理、電話接続、引き継ぎを一つの仕事として比較する。 各社のデモや評価結果を、この予約業務の成功率へ読み替えるものではない。

私の判断は、音声AIを、利用者が希望を伝え直しても、聞いた案内と実際の結果が一致するところまで評価する、というものだ。 滑らかな声や速い返答には価値がある。 その価値を仕事へつなぐには、会話の途中で何を確認し、処理がどこまで進み、人へ何を渡すかを決める必要がある。

音声を直接扱うか、文字を経由するか

音声認識で文字にし、テキストの処理を経て音声合成へ渡す方式は、各段階をつないで構成する。 OpenAIの2025年3月の音声モデル発表は、既存のテキスト型エージェントへ音声認識と音声合成を加える使い方を示す。 予約の文章処理がすでにあるなら、それを再利用する道になる。 認識した日時を次へ渡す前に確認する場所も作れる。

一方、同社の2025年8月のRealtime APIの一般提供は、単一モデルが音声を直接処理し生成する構成を説明する。 同社は、遅延を減らし、声の微妙な表現を保つ利点を挙げる。 ただし、どちらを使っても予約内容の確認は必要であり、文字が残るだけで正確さを保証できない。 音声を直接扱う方式でも、候補を明確な項目へ整理して確認する設計はできる。

統合APIという名称も、内部がすべて同じ方式であることを意味しない。 Microsoftの4月6日時点のVoice Live文書は、音声、推論、音声合成を一つの入口へまとめ、音声を直接扱うモデルと、音声認識・合成を組み合わせるテキストモデルの両方を示す。 開発者が接続する入口と、会話を処理する内部の方式を分けて比較したい。

方式の選択では、既存処理を再利用したいか、認識した語を途中で検査したいか、応答の抑揚をどこまで指定したいかを確かめる。 その上で同じ予約課題を通し、応答が聞こえるまでの時間、日時の誤り、訂正後の保存を比べる。 方式名だけから、一方が常に安全、一方が常に自然と決めることはできない。

速く答える前に、話し終わりを扱う

Googleは3月26日にGemini 3.1 Flash Liveを発表した。 開発者向けのLive APIではプレビューとして提供し、音声の調子の理解や、割り込み・ためらいを含む指示への対応を改善したと説明する。 モデルの改善は比較材料になるが、実際の予約変更を完了した率の測定ではない。 利用者向けアプリでの提供と、開発者向けAPIの条件も分けて読む必要がある。

予約日時を「来週の……木曜日」と言う間に、短い沈黙が入ることがある。 発話を検出する仕組みがその間を終了と扱えば、利用者が続ける前に返答してしまう。 反対に、長く待ち過ぎると、聞こえているか不安になる。 想定例では、発話終了を待つ長さだけでなく、どこで聞き直すかも会話の設計に入る。

「聞き取れました」という応答は、日時を確定したこととは違う。 私なら、月日、時間、対象の予約を復唱し、曖昧な部分だけを聞き直す。 全情報を毎回言い直してもらう方法では、認識の誤りを直すたびに利用者の負担が増える。 応答速度は、会話が正しい条件へ戻るまでの時間と一緒に見たい。

生成を止め、再生を止め、処理結果を確かめる

4月6日時点のGoogle GenAI SDKの定義は、モデルへの割り込みを受けた場合、リアルタイムに再生しているクライアントが音声を止め、待機中の音声を空にする手掛かりを示す。 サーバーが生成をやめても、端末側に残った音声を流し続ければ、利用者にはAIが話し続けているように聞こえる。 生成終了と、相手に聞こえた音声の終了を同一視できない。

同じ定義には、指定したツール呼び出しを取り消す通知もある。 副作用があればクライアントが元に戻すことを試み得る、という記述であり、保存された予約が自動的に戻る保証ではない。 まだ送っていない変更案と、送信済みの保存要求と、保存完了を別に扱う理由になる。

Microsoftの同時点のVoice Liveの関数呼び出し例も、アプリケーションが引数を受け、外部処理を行い、対応する呼び出しへ結果を返す構成を示す。 音声会話の便利な入口があっても、業務の結果をつなぐ処理は残る。 本稿でこれらのコードを実行したわけではなく、予約の取消を検証した例でもない。

想定通話では、訂正が入ったら古い候補の読み上げを止め、どの予約案への確認だったかを更新する。 保存要求が送られた後なら、その結果を照合してから次の変更へ進む。 遅れて届いた古い結果を新しい希望への成功として読まず、結果が不明な段階では「変更しました」と言わない。 利用者が理解できる案内と、実行側の記録をそろえる部分が必要だ。

一つの訂正を、四つの状態で追う

希望と確認

希望日時、対象の予約、確認した候補を結び付ける。言い直しが入ったら、古い候補への確認を新しい候補へ使い回さない。

聞こえている音

生成中、再生待ち、再生中、停止を区別する。音声を生成した記録だけから、利用者が案内を最後まで聞いたとは決めない。

実際の保存

変更前、要求送信後、保存済み、結果不明を分ける。保存済みなら、次の変更や取消が必要かを業務の規則で判断する。

次の担当への引き継ぎ

希望に加え、どこまで処理したか、何が不明かを渡す。人が同じ操作を重ねたり、説明を最初から求めたりしないための情報を残す。

これは予約変更を説明する本稿の整理だ。 四つの製品やエージェントを導入する要件ではない。 日時を案内するだけの通話と、保存を伴う通話では、必要な確認が違う。 業務を持たない短い音声応答へ、すべての状態を一律に追加する提案でもない。

また、会話中に返答できることと、ツールの結果が出たことは違う。 OpenAIのRealtime発表は、長い関数呼び出しの結果を待ちながら会話を続ける機能を説明する。 想定例なら「空き枠を確認しています」と話すことはできても、確認前に空き枠や変更の成功を断定してはいけない。 待つ理由を伝える応答にも、結果との整合が要る。

電話の入口と、使える声を別に比較する

同じ音声モデルを使っても、ブラウザーのマイクと電話回線では、入力や接続の条件が異なる。 OpenAIのRealtime一般提供には、SIPによる電話網や構内電話設備への接続が含まれる。 接続できることは業務完了率の証明ではないが、利用者が新しいアプリを開かず電話で依頼する経路を設計できる。

Amazon Connectの3月の更新も、音声の種類を分けて読む必要がある。 3月17日の発表は生成音声合成の声と地域を拡張し、3月18日の発表は音声から音声へ応答する機能をロンドン地域へ広げ、新しい声を追加した。 音声合成で使える地域や声を、別の会話方式でもすべて使えると考えてはいけない。

日本語の予約窓口なら、選んだモデル、入力言語、出力の声、提供地域、実際の電話経路をそろえて確認する。 多言語対応という説明だけから、住所、日時、英数字の聞き取りが各言語で同じ精度になるとは言えない。 声や回線を変えるときも、同じ訂正や復唱が成立するかを試したい。

再接続と、人へ渡すときの説明を残す

長い通話や切断後の再接続には、会話を続けるための状態が要る。 Google GenAI SDKは、再開用の情報と、その時点で再開可能かを示す定義を持つ。 ツールの実行や生成中などには再開できない場合があり、以前の情報で戻すと一部が失われ得るとも説明する。 すべての時点を同じ条件で復元できるとは考えられない。

予約変更で切断した場合、会話の続きへ戻れたことを理由に保存要求をもう一度送らない。 業務側の記録から、送った要求と現在の予約を照合する。 利用者には「変更済み」「まだ実行していない」「結果を確認中」を、確認できた範囲で伝える。 再接続の仕組みと予約の重複防止は、別々に実装して結び付ける必要がある。

人へ引き継ぐなら、希望日時、確認できた内容、未解決の点、保存の状態を短く渡す。 全文の文字起こしを渡すだけでは、担当者が処理済みかを探し直すことになる。 逆に要約だけで日時や対象の予約が抜ければ、利用者がもう一度説明する。 引き継ぎに必要な情報を残し、記録を見られる範囲と保存期間も業務に合わせて決めたい。

滑らかに話すことから、利用者本人であることや、変更する権限を推定しない。 その確認は予約業務の手続きで扱う。 音声AIで受付を進める価値は、人へ回す件数の少なさだけでなく、回した後に利用者と担当者が続きから進めることにもある。

分岐の試験と、実際に聞こえる音の試験

AWSの2月2日のAmazon Connect発表は、用件、期待する応答、営業時間外や待ち行列などの条件を指定して音声対話をシミュレーションするAPIを示す。 変更時に同じ試験を繰り返し、開発・公開の手順へ組み込める仕組みだ。 会話の分岐を確認する根拠になるが、実端末や回線での聞き取りを確かめた証拠ではない。

予約の試験では、長い間、言い直し、同時発話、数字の聞き違い、APIの遅延、保存直後の切断を含める。 返答文だけでなく、利用者が実際に聞いた案内と、保存された日時が一致したかを見る。 想定する端末、話者、回線、騒音でも音声を通し、停止の遅れや聞き直しを確認する。 音声が一度きれいに出たことだけでは、この通話の成功を判定できない。

方式を比較するなら、同じ依頼と音声条件で、応答開始までの時間、誤った日時、訂正の回数、予約結果、人への引き継ぎ後の修正を記録する。 平均の応答速度に加え、遅い応答や、速く誤って処理したケースを分ける。 プロンプト、モデル、声、接続経路を変えたら影響するケースを再確認する。 これは本稿の試験案であり、各社を実測した順位ではない。

利用者が、何が済んだか分かる通話へ

音声を使う利点は、画面へ入力し直さず、その場で希望を伝え、言い直せることにある。 その利点を保つには、訂正を受けた後の案内と処理を同じ希望へ合わせたい。 声を止める機能、会話を続ける機能、予約を保存する処理をつなぐ設計が、利用者の不安や説明のやり直しに関わる。

まず予約変更のような一つの業務で、通常の通話と訂正・切断を通し、聞いた案内と実際の結果を確かめる。 声の滑らかさと待ち時間を評価しながら、必要な確認や引き継ぎを省かない。 利用者が「何が済み、何がまだか」を理解できるところまでを、音声エージェントの完成条件にしたい。