- 公開日
音声AIへの割り込みでは、話を聞くための音声停止と、予約などの中止を分けて受け付けます。予約などの外部操作がある場合は、まだ始めていない処理、実行中の要求、確定済みの結果を別に扱います。声が止まったことや「了解しました」という返事だけで、予約を取り消せたとは案内できません。
音声の停止にも複数の段階がある
利用者が話し始めたことを検出する仕組みをVAD（Voice Activity Detection、音声区間検出）と呼びます。話し始めを捉えることと、「説明だけを止めたい」「予約自体をやめたい」という意味の判断は別です。周囲の声や短い相づちも含め、実際に何を入力として受けたかを確かめる必要があります。
モデルが音声の生成をやめても、すでに端末へ届いた音声が再生待ちなら、声が続くことがあります。また、生成された内容と実際に利用者が聞いた範囲がずれると、次の応答が未再生の説明を聞いた前提で進むおそれがあります。生成、再生、会話履歴を対応付けるのは、この食い違いを扱うためです。
| 対象 | 停止・修正で確かめること | それだけでは分からないこと |
|---|---|---|
| モデルの応答生成 | 対象の応答が生成中か、中断したか | 端末の再生待ち音声が消えたか |
| 音声の再生 | 実際に再生を止め、待機音声をどう扱ったか | 利用者がどこまで意味を理解したか |
| 会話履歴 | 未再生部分を聞いた前提にしない処理ができたか | 外部システムの操作結果 |
| 予約の実行 | 要求が未送信か、処理中か、確定したか | 取消要求が受理され、取消まで完了したか |
これらは設計上の確認対象です。音声を消す操作を予約の取消と同じ状態名で表示すると、利用者も運用担当者も、どの処理が終わったのか見分けにくくなります。
Realtime APIでは通信方式と設定を固定して読む
OpenAIのRealtime conversationsは、割り込み時に未再生部分を会話から取り除くtruncation（切り詰め）と、アプリ側で行う関数実行を別に説明しています。したがって、音声の中断を下流の予約取消と同一視しないことは、この実行境界から導く運用上の判断です。
ここでは、Voice activity detection (VAD)が説明する音声会話（speech-to-speech）でVADを有効にし、turn_detection内のinterrupt_responseで自動割り込みを使う構成を考えます。2026年10月28日に確認したRealtime conversationsのガイドでは、VADが有効なときにAPIが割り込みを扱い、未再生音声の処理は通信方式で次のように分かれています。
- WebRTC／SIPでは、サーバーが出力音声のバッファを管理し、利用者の割り込みに応じて未再生部分を自動的に切り詰めます。
- WebSocketでは、クライアントが再生を管理します。割り込み時には再生を止め、再生済みの位置を把握して、未再生部分の切り詰めを扱います。
interrupt_responseとcreate_responseをfalseにすると、VADは使ったまま自動の応答を止める構成になるため、上の説明とは別に扱います。また、文字起こしだけのセッションでは、VADは音声の区切り方を決めるもので、これらの設定は使われません。
同APIで明示的に制御する場合、response.cancelは応答生成の取消、conversation.item.truncateは以前のアシスタント音声を再生位置に合わせる処理です。output_audio_buffer.clearはWebRTC／SIP専用で、現行応答の生成を止めるresponse.cancelに続けるとAPI参照は説明しています。VADを無効にする方式でも、生成と再生の担当を確認します。これらのイベント名は予約サービスへの取消要求ではありません。実装時は利用するAPI・SDK・設定を固定し、音声処理と業務処理を別々に照合します。
「取消を受け付けた時点」を定義する
運用では、利用者が発話した時点、発話を検出した時点、取消の意図をアプリが受け付けた時点、予約サービスが要求を受けた時点を区別します。利用者が発話し始めた瞬間には、取消の意味がまだ認識されていなかったり、接続先で確定処理が進んでいたりするためです。
本稿の設計例では、取消らしい入力や明示的な停止操作を受けたら、新しい確定要求を一時的に保留します。対象を特定できた後、未送信なら確定を中止し、送信済みならその要求を照会します。予約を戻すための取消が別途必要な場合は、対象、費用、取消可能な範囲と許可を確認します。発話の意味を確かめている間に、止めたい処理を新たに始めないための区切りです。
この保留と確定要求の送信が競合しないよう、実行側で両者の順序を管理します。音声認識の文字列が後から到着したからといって、すでに受けた停止状態を忘れて確定へ進めない設計にします。複数の端末やサーバーの時計を使う場合は、時刻だけで前後関係を断定せず、同じ要求に結び付く受付記録と状態遷移も照合します。
MCP（Model Context Protocol、AIとツール等をつなぐ通信規約）を経由する場合も、Cancellationが示す取消の遅着や取消不能の可能性は残ります。この資料は2026-07-28のMCP仕様であり、音声APIそのものの取消仕様ではありません。両者を接続しただけで予約が取り消せるとは考えず、予約サービスの受付条件を確認します。
架空の音声予約で、確認中と確定処理中を比べる
以下は未実行の架空例です。利用者は、試験用の会議室Bを2026年10月20日の14時から15時まで予約しようとしています。実在の予約サービスには接続せず、仮の予約台帳と画面を使う前提です。仮のサービスは要求IDで処理状態を照会でき、確定後の取消は別の操作として記録するとします。
予約対象、利用者、取消の発話「その予約、やめてください」は固定し、承認の有無と確定要求がどこまで進んだかを変えます。
| 場面 | 発話を受けたときの画面と実行記録 | 期待する次の処理と案内 |
|---|---|---|
| 内容を確認中 | 「会議室B、14時〜15時。この内容で確定しますか」。確定要求は未送信 | 説明音声を止め、対象の確定を中止する。未送信を照合できたら「予約は確定していません」と伝える |
| 承認後、確定処理中 | 先に承認を受けて要求を送信済み。画面は「確定処理中」 | 新しい確定要求を出さず、元の要求を照会する。「中止を受け付けました。予約の状態を確認しています」と伝える |
| 予約が確定済み | 台帳に対象予約が存在し、確定結果を取得済み | 予約自体の取消条件と許可を確かめ、別の取消処理へ進む。完了確認まで「取消済み」と言わない |
確認中の画面表示だけを見て、未送信と推測してはいけません。画面更新が遅れる場合を考え、実行窓口の記録とも照合します。反対に、AIが「予約します」と話し始めたことだけで、接続先が確定したとも判断しません。
原音との対照も設計に含めます。たとえば、架空の試験音声の内容が「その予約、やめてください」なのに、認識テキストが「その予約、進めてください」となったケースを用意します。評価者は許可された試験音声と転記を照合し、画面の予約対象と要求IDも確認します。本文はその認識誤りが実製品で発生したと報告するものではありません。
実運用で毎回正しい原音の転記が別に手元にあるとは限りません。そのため、音声以外の停止ボタンや、対象を表示して訂正できる手段を用意します。取消対象や言葉が不明なら、新しい確定要求を保留して短く聞き返します。音声を保存する場合は、許可と保持条件の範囲内で必要な部分だけを扱い、予約内容や認証情報を無制限に記録しません。
結果不明のまま、取消完了とは言わない
確定処理中に取消を受けたケースでは、まず元の予約要求と予約台帳の状態を突き合わせます。未確定のまま処理終了を確認できれば、その範囲を伝えます。確定済みなら、取消要求の結果を別に追います。取消が拒否された場合は、予約が残っていることと、接続先が示した理由を伝え、人が判断できるようにします。
取消要求への応答を受け取れず、状態照会でも結果を確かめられない場合の案内は、「取消の依頼は受け付けましたが、予約が取り消されたかは未確認です」とします。元の確定と取消のどちらが不明なのかを分け、確認担当と次の確認方法を示します。切断で通話が終わっても、未確認の予約を完了扱いにする理由にはなりません。確認を継続する担当と、利用者へ結果を返す許可済みの経路を決めておきます。
応答不着は処理失敗と同義ではありません。AWSのMaking retries safe with idempotent APIsが扱うように、再送で副作用が重複する場合を考えます。要求の追跡IDと、同じ操作を重ねても重複適用しない冪等性の契約は別です。照会や重複防止を確認できないなら、同じ予約を新たに作り直して確かめることは避け、人へ引き継ぎます。結果不明時の照会と再試行の設計はタイムアウトした外部操作を照会し、二重実行を避けて再試行する、エージェント全体へキャンセルが伝わらない場合の切り分けはエージェントのキャンセルが効かないとき、伝達・停止・残る変更を確かめるで扱っています。
再開時も、聞き返しへの回答だけで古い確定処理を自動再開しません。対象日時、現在の予約状態、利用者が今望む処理、必要な承認を合わせます。停止後に利用者が別の時間帯を指定した場合は、元の要求の結果不明を解消しないまま別予約を作ると、両方が残る可能性があります。
音声と予約を別々に評価する
許可済みの模擬評価では、同じ予約に対し、確認中、送信直前、処理中、確定後の割り込みを用意します。発話検出と認識内容、生成の停止、再生済み位置と履歴、確定・取消の台帳、利用者への案内を別々に照合します。正常な予約が一件だけ確定するケースも確認し、すべてを止めることを合格条件にしないようにします。
音声が止まっても未承認の要求が出れば実行制御の不合格、状態を確認できないのに取消完了と案内すれば結果表示の不合格です。観測できない項目は未確認として残します。割り込みの検出を敏感にしすぎれば意図しない保留が増えるため、停止の速さだけで方式を選ばず、誤った停止と訂正手段、確認にかかる負担も見ます。ここでの評価観点は設計例であり、実音声や予約APIによる試験結果ではありません。
出典・参考資料
- OpenAI「Realtime conversations」（確認日：2026年10月28日）
- OpenAI「Voice activity detection (VAD)」（確認日：2026年10月28日）
- OpenAI API Reference「Realtime client events」（確認日：2026年10月28日）
- Model Context Protocol「Cancellation」（確認日：2026年10月28日）
- Amazon Builders’ Library / AWS「Making retries safe with idempotent APIs」（確認日：2026年10月28日）
