AI英会話の遅延が起きる理由を分解した。返事が遅い・かぶる・切られるの3症状を仕様から追う

公開日 2026年9月12日(土) 11:38更新日更新なし

「AI英会話遅延」と調べている人が本当に知りたいのは、何秒かかるかではなく、なぜその「間」が生まれるのかだ。

返事が返ってくるまでが妙に長い。

こちらがまだ言い終わっていないのに、相手が話しはじめてかぶる。

逆に、言い終わったのに数秒だまったままになる。

この3つは別々の不具合に見えるが、出どころは同じ1か所にある。

あなたの声が「どんな部品を、どの順番で、いくつ通っているか」だ。

この記事では、AIの音声部品を売っている会社の開発者向け公式ドキュメントに実際に書かれている記述だけを材料にして、その中身を1つずつ開けていく。

サービスの順位づけはしない。仕組みの話だけをする。

TOC

【結論】AI英会話の遅延は、声が「何段の部品」を通るかで決まる

先に答えを置く。

音声で会話するAIの作り方は、大きく分けて何種類もあるわけではない。OpenAI の Voice agents ガイドは、冒頭で「The key design choice is how speech connects to reasoning and tools」＝設計の要は、音声を思考と道具にどうつなぐかだと書き、3つの構成を表で並べている。

構成	公式の説明（原文）	日本語で言うと
GPT-Live	Full-duplex conversations with a separate backend	聞くのと話すのを同時にやる。考える処理は別の後ろ側に投げる
Realtime API	Speech, reasoning, and tool use in one session	音声の解釈・判断・返答を1つのセッションで完結させる
Chained voice pipeline	Control over each speech and text stage	音声認識→処理→音声合成を自分で3段つなぎにする

この3つは「速さ」と「途中を見られるか」を交換している。

1つのモデルが音声のまま受けて音声のまま返す形（speech-to-speech）は、途中にテキストの段がない。

3段つなぎ（chained）は、途中のテキストを読んだり書き換えたりできるかわりに、段が増えた分だけ待ち時間が積み上がる。

⇒ AI英会話の遅延は、モデルの賢さではなく、この構成の選び方でほぼ決まる。

そして「かぶる／切られる」のほうは、別の部品が担当している。あなたが話し終わったかどうかを判定する、ターン検出という部品だ。

AI英会話の遅延を作っている待ち時間は、1つではなく4つある

「反応が遅い」と感じたとき、実際には4つの別々の時計が動いている。

Voice agents ガイドの「Measure latency」の節は、この点をはっきり書いている。

「Time to first audible response, time to delegation, interruption yield, backend completion, and verified task completion measure different boundaries.」＝最初の音が出るまで・処理を投げるまで・割り込みに譲るまで・後ろ側の処理が終わるまで・用事が本当に片づくまでは、それぞれ別の境界を測っているという意味だ。

話し終わったと判定されるまで＝言い終わったのに沈黙が続く。担当はターン検出（VAD）。
最初の音が出るまで＝「えっ、聞こえてる？」と不安になる時間。担当はモデル本体と接続。
役に立つ答えが出るまで＝相づちは返るが中身が来ない。担当は後ろ側の処理と道具の呼び出し。
再生されるまで＝音がぶつ切れる・遅れて届く。担当はアプリ側の音声バッファと再生。

この分解がなぜ大事かというと、同じ「3秒待たされた」でも、直せる場所がまったく違うからだ。

公式ガイドはさらに、測り方の注意まで書いている。

「Use one monotonic timeline and report the eligible population, median, and tail latency.」＝1本の時間軸で測り、中央値だけでなく裾（遅かったほう）も出す。
「Do not substitute a backend-only timer for end-to-end response time.」＝裏側だけの計測を、端から端までの応答時間の代わりにしない。
「Measure the first useful spoken answer separately from an acknowledgment such as “I’m checking.”」＝「確認しますね」のような相づちと、本当の答えは別々に測る。

3つ目は、AI英会話を使う側にもそのまま効く指摘だ。すぐ何か言い返してくるアプリが「速い」とはかぎらない。

AI英会話の遅延①｜1モデル直結（speech-to-speech）と全二重が省いているもの

いちばん間が短くなりやすいのが、この形だ。

OpenAI の Getting started with the Realtime API は、この構成を「The model works directly with audio, maintains conversation state, and can call tools」＝モデルが音声を直接あつかい、会話の状態を保ち、道具も呼べると説明している。

そして、どういうときにこれを選ぶかも明記されている。

「This is the best starting point for voice agents that need barge-in, low first-audio latency, natural turn taking, and realtime tool use.」＝割り込み（barge-in）、最初の音までの短さ、自然な話者交替が要るならここから始めろ、という書き方だ。

注目すべきは、この一文に「遅延」と「割り込み」と「ターンの受け渡し」が同じ列に並んでいることだ。

公式ドキュメント自身が、この3つを同じ設計の裏表として扱っている。

なぜ速いのかは、Managing conversations のほうに理由が書いてある。「voice-to-voice interaction with the model, without an intermediate text-to-speech or speech-to-text step. This enables lower latency for voice interfaces」＝途中の音声合成・音声認識の段を挟まないので、遅延が下がる。

さらに同じ文は、速さ以外の副産物も挙げている。「gives the model more data to work with around the tone and inflection of voice input」＝声の調子や抑揚という情報が、テキストに潰されずにモデルまで届く。

⇒ 1モデル直結は「速い」だけでなく、あなたの言い方そのものを材料にできる構成だということになる。

同じ「途中の段を減らす」方向に、もう一段進んだ構成もある。

人間の会話は、相手が話し終わるまで黙って待つ形にはなっていない。

Voice agents ガイドには、聞くことと話すことを同時にやる構成が載っている。

「GPT-Live can listen and speak at the same time, a capability called full duplex.」＝同時に聞いて話せる能力を full duplex（全二重）と呼ぶ。

この構成では、重い処理は別の後ろ側に投げられる。「The live model handles the spoken interaction and delegates reasoning and tool use to a separate backend.」

その結果どうなるかも1行で書かれている。「Users can keep talking while backend work runs.」＝後ろで処理が走っているあいだも、利用者は話し続けられる。

これは「待ち時間を短くする」のではなく、「待ち時間を沈黙にしない」という解き方だ。

会話が途切れないかどうかは、処理の速さだけでは決まらない。

公式が評価項目に「unwanted silence」（望まない沈黙）と「overlap」（重なり）を別々に並べているのも、この2つが違う現象だからだ。

評価の観点は「Conversational timing」としてまとめられており、「audible response timing, unwanted silence, overlap, and yielding to interruptions」＝音が出るまでの時間・望まない沈黙・重なり・割り込みに譲れるかを測るよう書かれている。

AI英会話の遅延②｜3段つなぎ（chained）はどこで時間を使っているのか

もう一方の構成は、はっきり3段に分かれている。

Voice agents ガイドの「Build a chained voice workflow」は、アプリが管理する段を番号で並べている。

Speech-to-text＝あなたの声を文字にする段。
The agent workflow itself＝文字を読んで、何を返すか決める段。
Text-to-speech＝決まった文を声にする段。

3つの段は直列なので、待ち時間は足し算になる。

それでもこの形が選ばれるのは、途中が見えるからだ。

公式は用途をこう書いている。「Use the chained path when you want to inspect or transform text between speech recognition, your agent, and speech generation.」＝途中のテキストを点検したり書き換えたりしたいときに使う道だ。

具体例も添えられている。「you might store the transcript, run policy checks before the text agent responds, call internal systems, then generate speech only after the workflow reaches an approved answer」＝文字起こしを保存し、方針チェックを通し、社内システムを呼び、承認された答えになってからはじめて声にする。

観点	1モデル直結（speech-to-speech）	3段つなぎ（chained）
間の短さ	短くしやすい（中間段を挟まない）	段の数だけ積み上がる
途中のテキスト	会話の中で扱う	各段で点検・書き換えできる
部品の差し替え	セッション単位	「replace each component independently」＝段ごとに交換できる
割り込みの扱い	セッションが担当する	アプリ側で作り込む必要がある

⇒ 学習アプリで「返答は速いが安全網が薄い」ものと「反応は一拍遅いが内容が安定している」ものがあるのは、この設計の分岐と無関係ではない。ただし、どのサービスがどちらを採っているかは公開されていないかぎり分からないので、ここでは断定しない。

AI英会話で「まだ話してるのに切られる」の正体は、ターン検出の設定値

ここがいちばん体感に直結する部分だ。

あなたが話し終わったかどうかは、人間のように「察して」いるわけではない。

OpenAI の Voice activity detection (VAD) ガイドは、VAD を「automatically detect when the user has started or stopped speaking」＝利用者が話しはじめた／話し終わったのを自動で見つける機能と定義している。

そして speech-to-speech のセッションでは「It is enabled by default」＝既定で有効だと書かれている。

検出されると、サーバーから input_audio_buffer.speech_started（発話の開始）と input_audio_buffer.speech_stopped（発話の終了）という合図が飛ぶ。

つまり「切られた」と感じた瞬間、機械の中では「この人はもう話し終わった」という判定イベントが1つ発生している。

既定のモードは server_vad で、公式は「Automatically chunks the audio based on periods of silence」＝沈黙の長さで音声を区切ると説明している。

調整できる数値は3つある。

項目	公式の説明（原文の要点）	ずれると何が起きるか
`threshold`	Activation threshold (0 to 1)。「A higher threshold will require louder audio to activate」＝高いほど大きな声が要る	低すぎると生活音で反応する。高すぎると小声が拾われない
`prefix_padding_ms`	「Amount of audio (in milliseconds) to include before the VAD detected speech」＝検出前の音をどれだけ含めるか	短いと語頭が欠けて、別の単語として文字になる
`silence_duration_ms`	「Duration of silence (in milliseconds) to detect speech stop. With shorter values turns will be detected more quickly.」＝沈黙が何ミリ秒続いたら終わりと見なすか	短いと言葉を探す一瞬で切られる。長いと言い終わっても沈黙が続く

3つ目が、AI英会話の遅延と「途中で切られる」を同時に説明してしまう。

沈黙の待ち時間を短くすれば反応は速くなるが、そのぶん考えながら話す学習者は途中で区切られる。

長くすれば最後まで聞いてもらえるが、言い終わってからの沈黙が伸びる。

⇒ 「速さ」と「最後まで聞いてもらえること」は、同じ1つのつまみの両端にある。どちらも最良にする設定は、この仕組みのうえでは存在しない。

なお、公式ガイドに載っている設定例は threshold が 0.5、prefix_padding_ms が 300、silence_duration_ms が 500 という値だ（あくまで「example VAD configuration」として示されたもので、これが唯一の正解値だとは書かれていない）。

AI英会話の「間」を賢くする semantic_vad と eagerness という考え方

沈黙の長さだけで区切るのをやめる、というモードもある。

VAD ガイドはもう1つのモード semantic_vad を、「Chunks the audio when the model believes based on the words said by the user that they have completed their utterance」＝言われた言葉の中身から、発話が完了したとモデルが判断したところで区切ると説明している。

仕組みは確率だ。「This classifier scores the input audio based on the probability that the user is done speaking. When the probability is low, the model will wait for a timeout, whereas when it is high, there is no need to wait.」

＝話し終わった確率が低ければ待ち、高ければ待たない。

公式が挙げている例が分かりやすい。「For example, user audio that trails off with an “ummm…” would result in a longer timeout than a definitive statement.」＝「えーっと…」と尻すぼみになった音声は、言い切った文よりも長く待ってもらえる。

英語学習者にとって、これは決定的な差だ。

単語が出てこなくて詰まるのは、学習者の会話では日常的に起きる。

沈黙の長さだけで判定する方式なら、その詰まりは「話し終わり」と区別できない。

公式も「With this mode, the model is less likely to interrupt the user」＝このモードでは、モデルが利用者をさえぎりにくくなると書いている。

さらに eagerness（せっかちさ）という設定で、待ちの上限そのものを動かせる。

auto＝既定値。公式いわく「equivalent to medium」。
low＝「will let the user take their time to speak」＝ゆっくり話させる。
high＝「will chunk the audio as soon as possible」＝できるだけ早く区切る。

⇒ アプリ側が high 寄りに振れば会話はテンポよく進み、low 寄りに振れば間は伸びるが最後まで話せる。AI英会話の「相性」と呼ばれているものの一部は、このつまみの位置の話だ。

AI英会話で声がかぶる・割り込めないときに、裏で起きていること

AIが長々と話しているのをさえぎれない、というのも遅延の一種だ。

Managing conversations の「Interruption and Truncation」の節が、この処理を正面から扱っている。

「Realtime API handles interruptions when VAD is enabled, in that it detects user speech, cancels the ongoing response, and starts a new one.」＝VADが有効なら、利用者の発話を検出した時点で進行中の返答を打ち切り、新しい返答を始める。

ただし、ここで厄介な問題が起きる。

AIは自分が用意した返答を最後まで「言ったつもり」でいるのに、あなたは途中までしか聞いていない。

だから、まだ再生されていない部分を会話の記録から消す処理が要る。これを公式は truncating（切り詰め）と呼んでいる。

誰がそれをやるかは、つなぎ方で変わる。

WebRTC・SIP でつないでいる場合＝「the server manages a buffer of output audio, and thus knows how much audio has been played」。サーバーが再生済みの量を把握しているので、未再生分は自動で切り詰められる。
WebSocket でつないでいる場合＝「the client manages audio playback, and thus must stop playback and handle truncation」。アプリ側が再生を止め、conversation.item.truncate を自分で送らなければならない。

切り詰めの合図には、どこまで再生したかをミリ秒で入れる。公式の例は "audio_end_ms": 1500＝1.5秒のところで切るという指定だ。

この処理が甘いと、「さっき言ってたやつ、もう一回」と聞いたときにAIの話がかみ合わなくなる。

公式は、文字起こし側の限界も正直に書いている。

「The realtime model doesn’t have enough information to precisely align transcript and audio」＝音声と文字起こしを正確に対応づけるだけの情報がモデル側にないので、切り詰めは音声を切って未再生部分の文字を落とすところまでしかできない。

また、割り込みを自動で起こすかどうかは interrupt_response、返答を自動で作るかどうかは create_response という設定で切り替えられる。両方 false にすれば、VADの検出は残したまま返答のタイミングをアプリが握れる。

公式はそのトレードオフもはっきり書いている。「you’re comfortable trading a bit more latency in the interaction for control over inputs」＝入力を管理するために、少しの遅延を引き受けるという交換だ。

AI英会話の遅延と、字幕が出るまでの遅延は別物（delay の5段階）

画面に英文が出るのが遅い、というのはまた別の話だ。

自分が話した内容がテキストで表示されるタイプのアプリでは、文字起こし側の遅延が別に効いてくる。

Realtime transcription ガイドには、この関係が1行で書かれている。

「Streaming transcription trades latency for transcript quality.」＝逐次の文字起こしは、遅延と精度を交換している。

続けてこうある。「Lower delay settings can produce earlier partial text. Higher delay settings give the model more audio context before emitting text and can improve word error rate.」＝待ちを短くすれば早く途中の文字が出る。待ちを長くすれば文脈が増えて誤り率が下がりうる。

つまり「すぐ出るが直る字幕」と「遅いが正しい字幕」は、設定1つの裏表だ。

公式が示している delay の目安は5段階ある。

設定値	公式の説明（原文）	向いている場面
`minimal`	for the most latency-sensitive interactions	とにかく間を詰めたいとき
`low`	for low-latency live captions	会話中の字幕
`medium`	for a balanced latency/accuracy tradeoff	速さと正確さの折衷
`high`	when accuracy matters more than immediate display	あとで読み返す記録
`xhigh`	when your workflow can tolerate the most delay for more context	正確さを最優先する処理

大事なのは、公式がミリ秒を書いていないことだ。

「The exact delay in milliseconds can vary by model configuration, so benchmark with representative audio instead of assuming a fixed timing per level.」＝実際の遅延はモデルの設定で変わるので、段階ごとに固定の秒数を仮定せず、自分の音声で測れと書かれている。

⇒ 「このアプリは何秒」と一律に語れないのは、部品の側がそもそも秒数を約束していないからだ。

もう1つ、体感に効く仕様がある。文字起こしは途中経過（delta）と確定（completed）の2種類の合図で届き、公式は「Ordering between completion events from different speech turns isn’t guaranteed.」＝別のターンどうしで確定の到着順は保証されないと明記している。

画面の英文が一度出てから書き換わるのは、多くの場合こうした逐次表示の性質であって、故障ではない。公式も本番前の確認事項として「Decide how your UI should revise partial text when later deltas correct earlier text.」＝あとから来た文字が前の文字を直すとき、画面をどう書き換えるか決めておけと書いている。

AI英会話の遅延を自分で比べるときに、公式の測り方から借りられること

アプリを比べるとき、感覚でやると必ずぶれる。

公式ガイドの評価手順は開発者向けだが、考え方はそのまま使える。

まず、条件を固定しろと書かれている。「Keep the caller, model configuration, tools, and transport consistent when comparing changes.」＝比べるときは、話し手も設定も接続もそろえる。

そして、変えるのは一度に1つだけだ。「Change one factor at a time and repeat the same scenarios.」

利用者の立場に置き換えると、やることは3つになる。

同じ英文を、同じ言い方で、同じ環境で言う。マイクも部屋も変えない（公式も microphones、background noise を変数として挙げている）。
途中で詰まる言い方も必ず試す。言いよどみへの強さは、区切り方の設計そのものを映す。
相づちではなく、中身のある返事が来るまでを見る。公式が相づちと本答を分けて測れと書いているのと同じ理由だ。

公式は段階的な試し方も「Crawl, Walk, and Run」として示している。合成音声での単発→人の録音での単発→多ターンの連続会話、という順で複雑さを上げる形だ。

最後に、機械の数字だけで決めるなとも書かれている。

「Complement automated scores with human listening to assess pronunciation, naturalness, and whether the conversation feels appropriately paced.」＝会話のテンポが適切に感じられるかは、人が聞いて判断する。

⇒ 「なんとなく話しにくい」というあなたの感覚は、公式の評価手順のなかでも正式な判定材料として扱われている。気のせいとして切り捨てなくていい。

AI英会話の遅延に関するよくある質問

検索されやすい疑問を、公式ドキュメントの記述だけで答える。

Q. 通信が速ければ遅延は消えるか。 A. 消えない。公式は最初の音までの時間、後ろ側の処理が終わるまで、用事が片づくまでを「different boundaries」＝別々の境界だと書いている。回線は接続の立ち上がりに効くが、話し終わりの判定待ちや処理時間は別の場所にある。

Q. 言い終わる前に返事がかぶるのは、こちらの発音が悪いからか。 A. 発音ではなく区切り方の設計が主因になりうる。server_vad は沈黙の長さで区切る方式で、silence_duration_ms が短いほど「turns will be detected more quickly」＝早く区切られると公式に書かれている。

Q. 詰まって黙るとすぐ話を取られる。対策はあるか。 A. アプリ側に semantic_vad のような方式が使われていれば、言いよどみは長めに待たれる。公式は「ummm…」で尻すぼみになった音声のほうが、言い切った文よりタイムアウトが長くなると明記している。ただし利用者側から方式を選べるかはアプリしだいだ。

Q. 表示される英文があとから書き換わるのは不具合か。 A. 逐次表示の仕様として説明されている。文字起こしは delta（途中）と completed（確定）に分かれ、公式は「あとから来た delta が前の文字を直すとき、UIをどう書き換えるか決めておけ」と本番前チェックに載せている。

Q. 遅延の少ないAI英会話を選べば、英語は速く身につくか。 A. そこは分けて考えるべきだ。公式ドキュメントが扱っているのは会話のテンポと応答時間であって、学習効果の話は書かれていない。遅延が小さいと発話の回数を増やしやすいのは確かだが、身につくかどうかを遅延だけで語ることはできない。

まとめ｜AI英会話の遅延は「性能の限界」ではなく「設計の選択」の結果

もう一度、短く整理する。

音声AIの構成は大きく1モデル直結・3段つなぎ・全二重に分かれ、公式は「Speech, reasoning, and tool use in one session」など役割の違いで並べている。段が増えるほど待ち時間は積み上がる。
遅延は1つではなく4つの別々の時計（話し終わり判定・最初の音・役に立つ答え・再生）でできている。直す場所もそれぞれ違う。
「まだ話してるのに切られる」の主因はターン検出。silence_duration_ms を短くすれば速くなり、そのぶん言いよどみに弱くなる。
割り込みは途中で止めて記録を切り詰める処理とセットで、WebRTC ならサーバー側、WebSocket ならアプリ側が担当すると公式が書き分けている。
字幕の遅れは会話の遅れとは別物で、delay は minimal から xhigh まで5段階。公式はミリ秒を約束せず「自分の音声で測れ」と書いている。