AI英会話でAIが長々と話し始めたとき、こちらが声を出した瞬間に音がぴたりと止まる。あれが割り込みだ。
英語では barge-in と呼ばれ、音声エージェントを作るときの主要な要件として公式ドキュメントに名前が挙がっている。
ただ、あの「ぴたり」は1つの処理ではない。
生成中の返答を止める処理と、まだ再生していない分を会話の記録から削る処理が、2段で走っている。
この2段を分けて見ると、「割り込んだのに話が噛み合わなくなる」現象の理由まで説明がつく。
この記事では、AIの部品を売っている会社の開発者向け公式ドキュメントの記述だけを材料にして、割り込みの中身を開けていく。
サービスの順位づけはしない。仕組みの話だけをする。
【結論】割り込みは「応答のキャンセル」と「未再生分の切り捨て」の2段でできている
先に答えを置く。
OpenAI の Realtime conversations には、割り込みの扱いがこう書かれている。「Realtime API は VAD が有効なときに割り込みを処理する。ユーザーの発話を検出し、進行中の応答をキャンセルし、新しい応答を開始する」。
ここまでが1段目だ。
そして同じ節は、それだけでは足りないと続ける。モデルにはどこで割り込まれたのかを知らせる必要がある、という話だ。
公式はその理由まで書いている。ユーザーが「さっきの最後のところ、何だった？」と聞いたときに自然に続けられるようにするためだ。
| 段 | 処理の名前 | 何が起きるか |
|---|---|---|
| ① | キャンセル | 生成中・再生中の応答を止める |
| ② | トランケーション（truncating） | まだ再生されていない部分を会話から取り除く |
⇒ 割り込みとは「止める」ことではなく、「止めたうえで、聞いていない分を無かったことにする」ことだ。
この②が抜けると、AIは「自分がもう言った」と思っている内容を、あなたは聞いていない状態になる。
割り込みの引き金｜VADが話し始めを検出した瞬間に何が起きるか
割り込みのスイッチを押しているのは、ターン検出（VAD）のイベントだ。
Voice activity detection (VAD) のガイドによると、VADが有効なとき、サーバーは発話の開始と終了を示す2つのイベントを送る。
input_audio_buffer.speech_started＝発話ターンの開始。input_audio_buffer.speech_stopped＝発話ターンの終了。
割り込みの起点になるのは前者だ。
公式の手順書には「クライアントはサーバーからの新しい input_audio_buffer.speech_started イベントを監視する。これはユーザーが話し始めたことを示す。サーバーは進行中のモデル応答を自動的にキャンセルし、response.cancelled イベントが発行される」と書かれている。
つまりAIが黙る理由は、あなたの英語の中身ではなく、マイクに音が乗ったことそのものだ。
この配線は、VADの設定項目にもそのまま現れている。
VADの設定例には interrupt_response という項目があり、公式は「create_response と interrupt_response のフィールドは speech-to-speech の会話でのみ使われる」と注記している。
割り込みの2段目｜トランケーションが会話の記憶を作り直す
公式が truncating と呼んでいる処理が、割り込みの本体に近い。
定義はそのまま書かれている。「モデルの最後の応答のうち、再生されなかった部分を会話から取り除くこと」だ。
送るイベントは conversation.item.truncate で、公式の例は次の3つの値を持っている。
| フィールド | 公式の例 | 意味 |
|---|---|---|
item_id | item_1234 | モデルの最後の応答のアイテムID |
content_index | 0 | 対象のコンテンツ番号 |
audio_end_ms | 1500 | 1.5秒より後の音声を切り捨てる |
ここが重要で、切り落とす位置はミリ秒で指定する。
「どこまで再生されたか」を測っているのは、文の区切りでも意味の区切りでもなく、経過時間だ。
⇒ 割り込みの結果、AIの発言は文の途中でぶつ切りにされた状態で会話に残る。
割り込みの処理は接続方式で分かれる｜WebRTCとWebSocketの違い
同じ割り込みでも、誰が後始末をするかは通信方式で変わる。
公式の説明は明快だ。
| 接続方式 | 出力音声のバッファを持つ側 | 割り込み時の後始末 |
|---|---|---|
| WebRTC・SIP | サーバー | 再生されていない音声をサーバーが自動で切り捨てる |
| WebSocket | クライアント | 再生停止とトランケーションをアプリ側が手でやる |
公式は前者について「サーバーが出力音声のバッファを管理しており、ある時点でどれだけ再生されたかを知っている」と書いている（Realtime API with WebRTC）。
後者では、アプリが次の3手を踏む必要があると手順が示されている。
input_audio_buffer.speech_startedを監視する。- 再生中の音声をただちに止め、どこまで再生したかを記録する。
conversation.item.truncateを送って未再生分を会話から消す。
⇒ 割り込みの手ざわりがアプリごとに違うのは、この後始末をどちらが持っているかの差でも説明がつく。
作り手向けの Realtime API のガイドも、割り込みを含む音声ターンの処理はセッション層が扱うものだとして、barge-in を採用理由の筆頭に挙げている。
割り込みで消えるもの｜音声と文字起こしのずれ
割り込みには、公式ドキュメントが自分で「解けていない」と書いている部分がある。
文字起こし（transcript）の扱いだ。
公式の記述はこうだ。「realtime モデルは文字起こしと音声を正確に対応づけるだけの情報を持っていない。したがって conversation.item.truncate は指定した位置で音声を切り、再生されなかった部分のテキスト文字起こしを削除する」。
そして続けて「これは未再生の音声を取り除く問題は解決するが、切り詰められた文字起こしを提供するものではない」と書かれている。
⇒ 割り込んだ瞬間の「ちょうどそこ」で、音声とテキストがきれいに揃うとは公式自身が言っていない。
AI英会話の画面に表示されるログが、耳で聞いた内容と微妙にずれることがあるのは、この層の話として理解できる。
学習者側の実務的な結論は1つだ。割り込んだ直後の会話ログは、聞いた内容と完全に同じだと決めつけない。
割り込みを起こしにくくする設定｜semantic_vadとeagerness
「AIに割り込まれる」側の話も、同じVADの設定で説明がつく。
VADのガイドは semantic_vad について「このモードでは、speech-to-speech の会話中にモデルがユーザーを遮る可能性が低くなる」と書いている。
理由は、切れ目の判定材料が沈黙の長さではなく発話の中身に変わるからだ。
そして eagerness という項目が、公式の言葉では「モデルがどれだけユーザーを遮りたがるかを制御し、最大待機タイムアウトを調整する方法」として用意されている。
| eagerness | 公式の説明 | 割り込まれやすさ |
|---|---|---|
auto | 既定値で medium と同等 | 中間 |
low | ユーザーが時間をかけて話せるようにする | 遮られにくい |
high | できるだけ早く音声を区切る | 遮られやすい |
⇒ 割り込みの起きやすさは、AIの性格ではなく設定値として存在している。
割り込みを止めたいときの設計｜interrupt_responseとpush-to-talk
自動の割り込みを止める手段も、公式に2つ書かれている。
1つめは、VADは有効のまま自動応答だけを切る方法だ。
公式は「turn_detection.interrupt_response と turn_detection.create_response を false にすると、VADの挙動はすべて保ったまま、新しい応答を自動では作らなくなる」と書いている。
用途としては「モデレーションや入力の検証、RAGのパターンで、応答の遅さと引き換えに入力の制御を取りたい場合」が挙げられている。
2つめは、ターン検出そのものを切る押している間だけ話す方式（push-to-talk）だ。
この方式でも割り込みの後始末は消えず、アプリ側の手順に組み込まれている。
- 進行中の応答があれば
response.cancelを送って止める。 - 再生中の音声があれば即座に止め、
conversation.item.truncateで未再生分を会話から消す。 - WebRTC では
output_audio_buffer.clearを送る。公式はこれが「会話も切り詰める」と書いている。
公式が挙げる push-to-talk の利点のなかに「VADの失敗を避けられる」がある点も、割り込みの話として読める。
割り込みと相づちは別物｜公式が線を引いている場所
英会話の練習でいちばん効いてくるのが、この区別だ。
Prompting voice models のガイドは、割り込みの節でこう書いている。「ユーザーが割り込んだら、アシスタントは答えをやめて聞くべきだ。短い聞いている合図と、ユーザーのターンを奪うことは別物である」。
同じガイドは、相づち（backchannel）のポリシー例も載せている。「Use moderate backchannels. Acknowledge naturally without competing with the main response.」だ。
そのうえで注意書きが付いている。「ユーザーが話している間は決して話すな」という一律の規則をこれと並べて足すな、という指示だ。
理由も書かれている。役に立つ聞いている合図まで抑え込んでしまうからだ。
⇒ 割り込みをゼロにする設計は、公式ガイドが推奨していない方向だ。
なお gpt-live-1 については「聞くことと話すことを同時にでき、割り込みに応答し、バックエンドのエージェントが推論や道具を扱っている間も会話を進められる」と書かれている。
Voice agents のガイドは、この同時に聞いて話す能力を full duplex（全二重）と呼んでいる。
割り込みが止めるのは発話だけ｜裏で走っている仕事は止まらない
公式が名指しで警告している落とし穴がある。
「発話を止めることは、バックエンドの作業を自動的に止めるわけではない」という一文だ。
そして例が続く。「Stop talking（黙って）」と「Cancel my booking（予約を取り消して）」は意味が違う、と。
公式は「ユーザーが要求を変更したり取り消したりした場合、バックエンドがその変更を扱い、何が起きたかを確認しなければならない」と書いている。
⇒ 割り込みは音を止めるスイッチであって、処理を取り消すスイッチではない。
この性質は評価の設計にも出てくる。Voice agents のガイドは、会話のタイミングの評価軸として次を独立に測れと書いている。
- audible response timing（声が返るまでの時間）。
- unwanted silence（不要な沈黙）。
- overlap（発話の重なり）。
- yielding to interruptions（割り込みへの譲り方）。
同じガイドは評価の進め方も3段で示しており、その最終段では「割り込み」と「回復」を含む連続した複数ターンの会話を試すよう書いている。
割り込みに関するよくある質問
Q. 割り込むとAIは何を覚えているのか。 A. 公式の設計では、再生された部分までが会話に残り、未再生の部分は conversation.item.truncate で取り除かれる（出典）。切る位置は audio_end_ms というミリ秒の値で指定される。
Q. 割り込んだのに会話が噛み合わないことがあるのはなぜか。 A. 公式は「realtime モデルは文字起こしと音声を正確に対応づけるだけの情報を持っていない」と書いており、切り詰められた文字起こしは提供されないとも明記している。音声側とテキスト側で残り方が揃わない余地がある。
Q. 相づちを打つだけで会話が止まってしまう。 A. 割り込みの引き金は input_audio_buffer.speech_started、つまり音声の検出だ。server_vad は音の大きさと沈黙の長さを見ているので、短い声かどうかをこの層では区別していない。
Q. 割り込みを完全にオフにできるか。 A. API側には turn_detection.interrupt_response を false にする方法と、turn_detection を null にしてターン検出ごと切る方法がある。ただし画面から触れるかどうかは各サービスの作り次第だ。
Q. 割り込みやすさの違いはサービスの品質差なのか。 A. 公式ドキュメントには silence_duration_ms や eagerness といった調整項目が明示されている。少なくとも一部は設定の差として説明できる範囲にある。
まとめ｜割り込みは「止める」と「無かったことにする」の2段でできている
もう一度整理する。
- 割り込みはVADが有効なときに処理される。ユーザーの発話を検出し、進行中の応答をキャンセルし、新しい応答を始める、と公式に書かれている。
- 2段目のトランケーションが「再生されなかった部分を会話から取り除く」。切る位置は
audio_end_msのミリ秒指定だ。 - 後始末の担当は接続方式で変わる。WebRTC・SIPはサーバーが自動、WebSocketはクライアントが手動。
- 公式は「文字起こしと音声を正確に対応づける情報を持っていない」と自ら書いている。割り込み直後のログは耳で聞いた内容と揃うとは限らない。
- 発話を止めても裏の処理は止まらない。「Stop talking」と「Cancel my booking」は別物だと公式が明記している。
⇒ AI英会話でAIの話を遮るのは、行儀の悪い行為ではなく最初から設計に入っている操作だ。
遮ったあとに会話が少しずれるのも、仕様のうえで説明のつく範囲にある。
※本記事の一次ソースはすべて2026-09-16に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments