待ち時間も会話を止めない音声AI：割り込み・進捗案内・キャンセルの設計

「今月の売上を教えて」。AIは確認すると答えた後、黙ってしまいます。数秒たつと、利用者はもう一度尋ねます。「聞こえていますか？」。その結果、同じ照会が二重に実行され、先に始めた処理の結果が、後の質問を遮って読み上げられることもあります。

音声AIの品質は、声の自然さだけでは決まりません。大切なのは、利用者が話しているときは聞き、待ち時間にはその理由を伝え、実際に終わったことだけを完了と案内する能力です。外国語の練習、顧客対応、業務報告、音声で操作する制作ツールに共通する課題です。

この記事は、2026年10月23日に確認した公式技術文書に基づく設計ガイドです。特定製品の実測レビューでも、動作するアプリを公開した事例でもありません。サムネイルを含む6枚の画像は、説明のために生成した概念図です。実際のサービス画面や性能測定の結果ではありません。

1. 最初の返事と処理の完了は別々に測る

Googleが10月19日に公開したADKガイドでは、時間のかかるツールを実行しながら会話を続ける方法を紹介しています。売上報告のデモでは、最初の発話までの時間が14.4秒から1.2秒に短縮されたと報告しています。ただし、これは提供企業による特定の構成での結果です。照会そのものが同じだけ速く完了したという意味ではなく、裏側の処理時間は別に残ります。

この違いを見落とすと、「すぐに確認します」と素早く言う仕組みを、業務を素早く終わらせる仕組みと混同してしまいます。評価では、利用者の発話終了から、受け付けの案内、実際の進捗を示す証拠、検証済みの最終結果までを分けて記録しましょう。ひとつの数字にまとめないことが重要です。

最初の返事では、何を理解し、何をしようとしているかを伝えます。まだ開始していない照会を実行中と言ったり、計算しているだけで成功を宣言したりしてはいけません。待ち時間を雑談で埋めるより、確認できる状態を一文で伝える方が役立ちます。

2. 会話の流れと処理の流れを分ける

ADKのリアルタイムツール文書は、通常のツール、バックグラウンド実行、中間結果を送るストリーミングツールを区別しています。ツールの実行中に会話が止まる構造は、「親切に話し続けて」というプロンプトだけでは解決しません。実際のイベントと実行経路を設計する必要があります。

実務では、会話を担当する経路が利用者の質問を受け取り、処理を担当する経路が照会・変換・生成を進める、と分けて考えると整理しやすくなります。ここでいう2つの経路は、必ずしも別々の製品や2つのモデルを意味しません。ひとつのアプリでも、会話の状態と処理の状態を別々に管理できます。

以下は、AIZIGOOが提案する最小限の状態管理表です。実装用のAPIスキーマではなく、開発者と企画担当者が共有するための運用上の取り決めです。

利用者が条件を変更したら依頼の版番号を更新し、古い結果を新しい条件への回答として使わないようにします。同じ質問が繰り返されても、既存の処理を確認するのか、新しい処理を作るのかを先に判断します。特に送信や予約など外部の状態を変える操作では、処理IDと重複実行を防ぐキーを結び付けておく方が安全です。

3. 進捗は実際に変化したときだけ伝える

「処理中です」を数秒おきに繰り返しても、信頼が高まるわけではありません。ファイルを開けたのか、照会が終わったのか、結果の検証が残っているのかなど、実際のイベントに結び付いた案内が必要です。進捗率が分からないときは割合を作り上げず、確認済みの段階と、次に状態を確認するタイミングを伝えましょう。

結果をいつ話すかも、別に決める必要があります。ADK文書では、会話の自然な切れ目に伝えるWHEN_IDLE、直ちに反応するINTERRUPT、会話の文脈だけを更新するSILENTを説明しています。対応状況はモデル・SDK・セッション構成ごとに確認が必要で、すべての音声アプリに同じ設定項目があるという意味ではありません。

この表はAIZIGOOの設計提案であり、製品ごとの標準動作を測定・比較したものではありません。自然さとは、絶え間なく話し続けることではなく、必要な瞬間にだけ会話に入ることです。

4. 「ちょっと待って」と「その処理を取り消して」を区別する

会話への割り込みには、異なる意味が含まれます。「ちょっと待って、別の質問があります」は、音声の再生を止めてほしいという意味かもしれません。一方、「報告書の生成を取り消して」は、バックグラウンド処理の中断を求めています。前者に対応しただけで、後者まで完了したと案内してはいけません。

Googleの10月のガイドは、利用者が会話に割り込んでも、実行中のツールは自動では取り消されないと明記しています。ADKのストリーミングツールにおけるstop_streamingなど、別の取消経路が必要です。それでも、すでに外部サーバーへ渡した処理や送信済みの操作まで元に戻るという意味ではないため、アプリ側で結果の状態を再確認しなければなりません。

OpenAI Realtimeの中断・切り詰めに関する文書は、再生されなかった応答と会話履歴を一致させる問題も説明しています。WebRTC・SIPとWebSocketでは責任の分担が異なるので、音声を止めるだけで対応を終えないようにしましょう。利用者が聞いていない説明をすでに聞いたと仮定すると、次の回答がかみ合わなくなります。

実際の設計では、音声の再生状態と業務の処理状態を分けます。範囲があいまいなら、「説明を止めました。照会も中断しますか？」と一度確認できます。取消応答が届いていない場合は、「取り消しました」ではなく、「中断を要求し、状態を確認しています」と伝えます。

5. 流暢な声は権限確認の代わりにならない

「はい、進めてください」という言葉の意味は、直前に何を説明したかで変わります。照会への同意を、メールの送信や予約の確定への承認に広げてはいけません。実際に操作する前に、対象、範囲、金額や受信者など重要な変更内容を示し、その操作に対する確認を得る必要があります。

ADKの安全対策文書では、指示文だけでなく、入力・応答・ツールの各段階に独立した検証を設けることも扱っています。音声はリアルタイムで流れるため、後から文字起こしを調べればすべての発話を事前に防げる、とは考えないでください。特にツールを実行する前に、権限と引数を確認する境界を別に設けましょう。

試験導入は、架空の注文、サンプル文書、読み取り専用の照会から始めるとよいでしょう。録音や文字起こしを保存するか、どう保管するかも利用者に伝え、必要最小限の情報だけを残します。電話の背後から聞こえる声や外部資料の文章を操作指示として扱わないよう、依頼者と処理範囲を確認する手順も用意します。

6. 30分の試験導入：声よりも状態を確かめる

以下は、AIZIGOOが提案する小規模な点検手順です。この記事のために実際の音声APIを呼び出して試験した結果ではなく、公式ベンチマークでもありません。同じ試験を文章として読むだけでは、マイク、発話検出、声が重なった場合の不具合は見つけにくいものです。ADKの音声評価文書も、実際の音声経路と会話全体を確認する重要性を説明しています。

最初の5分で、読み取り専用の処理をひとつ選び、期待する結果を決めます。続く15分で、同じ端末とネットワークを使って以下の状況を繰り返します。最後の10分は、録音の同意を得た会話と処理ログを並べ、不具合の原因を分類します。可能なら同じ台本を韓国語・英語・日本語でそれぞれ試します。ただし、翻訳内容が同じでも、音声の動作まで同じとは限りません。

平均応答時間をひとつ出すよりも、最初の反応と最終完了までの時間の分布、誤って遮られた発話、重複実行、誤った完了案内を別々に記録しましょう。成功した会話1件あたりの費用には、音声処理とモデル呼び出しだけでなく、再試行、外部ツール、人による確認も含めます。試行数が少ない場合は、モデルの順位を発表するより、繰り返し起きる不具合をひとつ直すために使う方が有益です。

優れた音声AIは、必要なときに静かに待てる

自然な会話に必要なのは、最初の一言の速さだけではありません。聞くときと話すときを区別し、条件が変わったら古い回答を手放し、取り消されていない処理を取り消したと言わないことが大切です。最初から万能のアシスタントを目指すより、ひとつの読み取り専用処理を、明確に受け付け、進め、確認できるエージェントから設計してみましょう。

確認した公式資料

• Google Developers：会話を止めない音声エージェントの制作ガイド、2026-10-19
• ADK：リアルタイムエージェントのツール
• ADK：リアルタイムエージェントの安全対策
• ADK：リアルタイムエージェントの評価
• OpenAI：Realtimeの中断と未再生応答の処理

資料の確認日は2026年10月23日です。この記事で扱う開発者向けAPI・ADKの説明を、一般向けアプリの設定と混同しないでください。対応モデル、SDKの版、アカウントの利用資格、データの取り扱い、料金は、導入前に各サービスの最新文書で再確認する必要があります。