AI英会話で相槌を打った瞬間に、相手の話が止まった経験があるなら、それは操作ミスではない。
相槌は、いまのAI英会話の土台になっている仕組みのなかで、いちばん誤解されやすい音だからだ。
日本語話者は会話中に「うんうん」「はい」を頻繁に挟む。英語でも uh-huh や yeah を同じ感覚で挟む人は多い。
ところがAI英会話の入口にいるのは、人間ではなく音声区間検出（VAD＝Voice Activity Detection）という部品だ。
この部品は「いま声が出ているか」「どれだけ黙っていたか」を見て、会話の切れ目を機械的に決めている。
つまり相槌は、内容ではなく音の有無として処理される。
この記事では、AIの部品を売っている会社が公開している開発者向けドキュメントの記述だけを材料にして、相槌がどこでどう扱われているのかを1段ずつ開けていく。
文化論やマナーの話はしない。仕組みの話だけをする。
【結論】相槌はAI英会話で「新しい発話の始まり」として拾われる
先に答えを置く。
相槌が会話を壊す原因は、相槌を相槌として扱う層がどこにも無いことにある。
OpenAIのRealtime APIでは、音声区間検出が有効なとき、ユーザーが話し始めた・話し終わったことをイベントとして通知する。
| イベント名 | 公式ドキュメントの説明 |
|---|---|
input_audio_buffer.speech_started | The start of a speech turn（発話ターンの開始） |
input_audio_buffer.speech_stopped | The end of a speech turn（発話ターンの終了） |
出典＝OpenAI Realtime VAD ガイド（Voice activity detection）。
ここに「短い相槌だけは数えない」という分岐は書かれていない。
相槌も、長い一文も、同じ speech_started として流れていく。
だから相槌は、AI側から見れば「あなたが新しく話し始めた」という合図そのものになる。
相槌とは何か｜公式ドキュメントが置いている定義を確認する
まず、相槌という語が開発者向けドキュメントの中にどう存在しているかを押さえる。
英語圏の音声AIの文脈では、相槌は backchannel と呼ばれる。
OpenAIの Prompting GPT-Live には、次のように書かれている。
A backchannel is a short listening sound, such as “mm-hmm.”
つまり相槌＝「聞いているよ」を示す短い音だと、公式が明示的に定義している。
同じページには、アシスタント側の相槌の出し方を指示文で制御する行も置かれている。
Backchannel policy: Use moderate backchannels. Acknowledge naturally without competing with the main response.
ここで分かるのは、相槌が「制御される対象」として設計に組み込まれているのはAIが出す側だけだということだ。
ユーザーが打つ相槌を、相槌として受け取る専用の窓口は、このページには置かれていない。
相槌が最初に引っかかる関所｜サーバーVADは沈黙の長さだけを見ている
相槌の扱いを決めているのは、会話の意味ではなく無音の長さだ。
OpenAIのVADには2つのモードがある。
| モード | 公式の説明（原文の要旨） |
|---|---|
server_vad | Automatically chunks the audio based on periods of silence.（沈黙の長さで音声を自動的に区切る） |
semantic_vad | Chunks the audio when the model believes based on the words said by the user that they have completed their utterance.（話された言葉から発話が終わったと判断したときに区切る） |
そして公式は For sessions and models that support VAD, the default value is server_vad. と書いている（出典＝Voice activity detection）。
既定は「沈黙の長さで切る」ほうだ。
このモードで調整できる値は3つある。
threshold＝起動のしきい値（0〜1）。公式はA higher threshold will require louder audio to activate the modelと書いている。prefix_padding_ms＝VADが音声を検出する前の音声を何ミリ秒ぶん含めるか。silence_duration_ms＝発話の停止を判定するための沈黙の長さ。公式はWith shorter values turns will be detected more quickly.と書いている。
公式が例として載せている設定は threshold: 0.5 / prefix_padding_ms: 300 / silence_duration_ms: 500 だ。
⇒ 相槌のあとに0.5秒黙れば、そこが「発話の終わり」として確定しうる。
日本語話者の相槌は短い。短いからこそ、そのあとの沈黙が早く来る。
ここが、相槌とサーバーVADの相性が悪い一番の理由だ。
相槌がAIの発話を止める仕組み｜相槌は「割り込み」として処理される
相槌がいちばん目立つ形で会話を壊すのは、AIが話している最中に打ったときだ。
OpenAIの Realtime conversations ガイド には、割り込みの処理が明記されている。
Realtime API handles interruptions when VAD is enabled, in that it detects user speech, cancels the ongoing response, and starts a new one.
日本語にすると、VADが有効なとき、ユーザーの発話を検出した時点で進行中の応答をキャンセルし、新しい応答を始めるということだ。
同じページは、クライアント側が踏むべき手順もこう書いている。
- サーバーから新しい
input_audio_buffer.speech_startedが来たことを監視する。進行中のモデル応答は自動的にキャンセルされ、response.cancelledが出る。 - クライアントはその時点で再生中の音声を即座に止める。
conversation.item.truncateを送って、再生されなかった部分を会話から取り除く。
ここで注目すべきは、キャンセルの引き金が speech_started であることだ。
相槌も speech_started を出す。だから相槌はAIの話を止める。
公式は割り込みを異常ではなく正常な機能として書いている。止まるのは壊れているからではなく、そう作られているからだ。
相槌のあとに話が飛ぶ理由｜切り捨て（truncate）で未再生の部分が消える
相槌を打ったあと、AIの説明が途中から無かったことになる現象にも仕様上の理由がある。
割り込みが起きたとき、Realtime APIはまだ再生されていない音声を会話から取り除く。これを公式は truncating と呼んでいる。
送る側はこういうイベントを出す。
| フィールド | 意味 |
|---|---|
type | conversation.item.truncate |
audio_end_ms | どこで切るか。公式の例は 1500（1.5秒後で切る） |
さらに公式は、切り捨てが音声だけでなく文字にも及ぶと書いている。
conversation.item.truncate will cut the audio at a given place and remove the text transcript for the unplayed portion.
⇒ 相槌1回で、AIがこれから言う予定だった説明が会話の履歴ごと消える。
消えた部分はAI自身も覚えていないので、あとから「さっきの続きは」と聞いても再現されるとはかぎらない。
WebRTCやSIP接続では、サーバー側が再生済みの量を把握しているため、この切り捨てを自動で行うとも書かれている（出典＝Interruption and Truncation）。
相槌に強いモード｜セマンティックVADは「言葉の中身」で切れ目を決める
沈黙だけで切らない選択肢も、同じドキュメントに用意されている。
semantic_vad は、意味分類器を使ってユーザーが話し終わったかを判定するモードだ。
公式の説明はこうだ。
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.
具体例として公式が挙げているのが、語尾が ummm... と流れた音声はタイムアウトが長くなるという挙動だ。
そして With this mode, the model is less likely to interrupt the user during a speech-to-speech conversation とも書かれている。
このモードには eagerness という調整値がある。
eagerness | 公式の説明 |
|---|---|
auto | 既定値。medium と同等 |
low | will let the user take their time to speak（ユーザーに時間をかけさせる） |
high | will chunk the audio as soon as possible（できるだけ早く区切る） |
⇒ 相槌を打つ癖がある人にとっては、low 寄りの設計のほうが会話が続きやすい。
ただしこれはアプリを作る側が決める値であって、利用者が画面から触れるとはかぎらない。
同じ「AI英会話」でも、この1行の違いで相槌の通り方が変わる。
相槌が雑音として捨てられる場合｜同時に鳴る声の扱い
相槌は届かないこともある。届かないことにも仕様上の説明がある。
Google CloudのSpeech-to-Textは、推奨事項の一覧の中で同時発話について次のように書いている。
Multiple people talking at the same time, or at different volumes may be interpreted as background noise and ignored.
同時に話している声や、音量の違う声は、背景ノイズと解釈されて無視されることがあるという記述だ（出典＝Cloud Speech-to-Text Best practices）。
同じページには The recognizer is designed to ignore background voices and noise without additional noise-canceling. とも書かれている。
AIの声が出ている最中に打つ相槌は、この「同時に鳴っている音」に当たる。
- マイクは話す人にできるだけ近づける（公式の推奨）。
- ノイズ低減処理は切る。公式は
applying noise-reduction signal processing to the audio before sending it to the service typically reduces recognition accuracyと書いている。 - 自動ゲイン制御（AGC）は使わない。これも公式が明記している。
⇒ 相槌は「拾われて会話を止める」ことも「捨てられて無視される」こともある。
どちらに転ぶかは、環境と設定で変わる。この揺れ自体が、相槌を打つ側から見た分かりにくさの正体だ。
相槌が文字起こしから消える理由｜表示テキストの整形が不要語を落とす
画面に出た英文に自分の相槌が無い、というのも仕様どおりの結果でありうる。
Microsoftの 音声テキスト変換での表示テキストの書式設定 には、「不要な言葉の除去」という機能が説明されている。
公式の説明は「音声には、口ごもりや、単語の重複や、『えーと』や『あー』のようなつなぎ言葉が含まれることがよくあります。音声テキスト変換では、このような不要な言葉を認識し、表示テキストから除去できます」だ。
公式が載せている変換例は次のとおり。
| 認識された音声 | 表示テキスト |
|---|---|
| i uh said that we can go to the uhmm movies | I said that we can go to the movies. |
| its its not that big of uhm a deal | It’s not that big of a deal. |
| umm i think tomorrow should work | I think tomorrow should work. |
つなぎ言葉と繰り返しは、表示テキストの段階で落とされる。
⇒ 相槌に近い短い音は、VADの層では「発話の開始」として強く効き、表示テキストの層では消えることがある。
この非対称が、「言ったのに反映されていない」「言っていないのに止まった」という体験を同時に生む。
相槌のあとの沈黙で接続が切れる｜音声区間タイムアウトという仕組み
相槌だけを打って黙り続けると、セッションそのものが閉じることがある。
Google Cloudの Voice activity events and timeouts には、音声区間のイベントとタイムアウトが説明されている。
イベントは SPEECH_ACTIVITY_START と SPEECH_ACTIVITY_END の2つだ。
タイムアウトについて公式はこう書いている。
Voice activity timeouts must be greater than 500ms and less than 60s.（500ミリ秒より大きく、60秒より小さい範囲で設定する）- Speech begin timeout＝発話が始まらないまま時間が過ぎると、ストリームを自動的に閉じる。
- Speech end timeout＝
SPEECH_ACTIVITY_ENDのあと、さらに発話が検出されないとストリームを自動的に閉じる。
さらに、経過時間の測り方についても Time elapsed is measured by the bytes of audio sent in requests と明記されている。サーバー時刻ではなく、送られた音声の量で数えている。
短く区切って使うモデルもある。Single utterance behavior によると latest_short モデルは発話の終わりを検出した時点で認識を止め、END_OF_SINGLE_UTTERANCE を返してストリームを閉じる。
⇒ 相槌1語だけを発話とみなされてしまうと、そこが「1発話の終わり」になりうる。
相槌を前提に設計する方法｜公式が示している指示文と設定
相槌の問題は、利用者の努力ではなく設定側で吸収できる部分が大きい。
Prompting GPT-Live の Appendix には、間や雑音への反応を抑えるための文例が置かれている。
Keep listening while the user pauses to think.
Do not treat a cough, music, or nearby conversation as a new request.
公式は、この追加を Use this if testing shows the assistant reacts to pauses or unrelated sounds. という条件つきで勧めている。
同じページには、やってはいけない書き方も明示されている。
Do not add a blanket “never speak while the user is speaking” rule alongside it. That can also suppress helpful listening sounds.
「ユーザーが話している間は絶対にしゃべるな」と一律に書くと、役に立つ聞き手の音まで消えるという警告だ。
| 相槌まわりの症状 | 仕様上の対処（公式に記述があるもの） |
|---|---|
| AIが話している最中に止まる | turn_detection.interrupt_response を false にする（Realtime conversations） |
| 少し黙ると勝手に返事が始まる | silence_duration_ms を長くする、または semantic_vad へ切り替える |
| 考えている間に区切られる | eagerness を low にする |
| 完全に自分で区切りたい | turn_detection を null にしてプッシュトゥトークにする |
最後の1つについて、公式は VAD can be disabled by setting turn_detection to null と書き、押しながら話す方式（push to talk）の用途を挙げている（出典＝OpenAI Realtime ガイド）。
⇒ 相槌を打つ癖は直さなくていい。区切り方の設定が合っていないだけ、という場合がある。
相槌と付き合うために利用者側でできること
設定を触れない立場でも、仕組みが分かっていれば取れる手はある。
- AIが話している間は相槌を打たず、言い終わってから返す。割り込み判定の引き金を踏まないための最短手。
- 相槌を打つなら、そのまま本文につなげて一続きで話す。相槌のあとに沈黙を置かないことで
silence_duration_msに届きにくくなる。 - イヤホンやヘッドセットを使い、AIの声を自分のマイクに戻さない。同時発話として扱われる状況を減らせる。
- 文字起こしの画面がある場合は、自分の発話がどこで区切られたかを見る。区切りの位置が、そのサービスのVAD設定を映している。
- 沈黙して考えたいときは、黙るのではなく「let me think」のように声を出し続ける。
semantic_vadは言葉の中身で待ち時間を変える。
どれも「相槌を我慢する」話ではなく、音の切れ目をどこに置くかの話だ。
相槌が悪いのではなく、相槌と沈黙がセットになると切れ目に見える、というのがここまでの内容だ。
会話の技術ではなく、録音の区切り方の技術だと捉えたほうが早い。
相槌に関するよくある質問
Q. 相槌を打つとAIが黙るのは不具合か。 A. 不具合ではない。公式は、VADが有効なときユーザーの発話を検出すると進行中の応答をキャンセルすると明記している（Realtime conversations）。相槌もその「発話」として検出される。
Q. 相槌はどの語なら安全か。 A. 既定の server_vad が見ているのは threshold（音の大きさ）と silence_duration_ms（沈黙の長さ）であって、語そのものではない。語の中身を見るのは semantic_vad のほうで、公式は語尾が ummm... と流れた音声はタイムアウトが長くなる、という例を挙げている。
Q. 相槌が文字起こしに出てこないのはなぜか。 A. 表示テキストの整形機能が、つなぎ言葉や単語の重複を除去することがある。Microsoftは i uh said that… が I said that… になる例を公式に載せている（表示テキストの書式設定）。
Q. 相槌を打っても止まらないAI英会話はあるか。 A. 仕様としては可能だ。turn_detection.interrupt_response を false にする、semantic_vad を使う、turn_detection 自体を null にする、という3つの選択肢が公式ドキュメントに書かれている。どれを採っているかはサービスごとに異なる。
Q. 相槌を打つ練習は無駄になるのか。 A. 音を出す練習としては成立する。ただし相槌が「聞いていることを相手に伝える」役割を果たしているかどうかは、AI側の設計に依存する。公式が相槌（backchannel）を制御対象として書いているのは、あくまでアシスタントが出す側だ（Prompting GPT-Live）。
まとめ｜相槌はAI英会話で「意味」ではなく「音の切れ目」として処理される
もう一度整理する。
- 相槌は公式ドキュメントで backchannel＝短い聞いている音と定義されているが、制御対象になっているのはAIが出す側だけだ。
- 利用者が打つ相槌は
input_audio_buffer.speech_startedとして流れ、新しい発話の開始と同じ扱いになる。 - 既定モードの
server_vadは沈黙の長さで区切る。公式の設定例はsilence_duration_ms: 500で、相槌のあとの短い沈黙が切れ目になりうる。 - 割り込みが起きると、未再生の音声とその部分の文字起こしごと会話から取り除かれる（
conversation.item.truncate）。 - 逃げ道は仕様側にある。
semantic_vad・eagerness: low・interrupt_response: false・turn_detection: nullのいずれも公式に記述がある。
⇒ 相槌をやめる必要はない。相槌のあとに沈黙を置かない、そしてAIが話し終わってから返す。この2点だけで、仕組みの上では衝突がかなり減る。
そして、同じ「AI英会話」という名前でも、VADの設定が違えば相槌の通り方はまったく別物になる。うまくいかないときは、自分の話し方より先にそのサービスの区切り方を疑ったほうが早い。
※本記事の一次ソースはすべて2026-09-16に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments