AI英会話に話しかけたとき、こちらがまだ言い終わっていないのに認識が終わってしまうことがある。
その裏側には、どこで認識を打ち切るかという設定が必ず入っている。
その設定のひとつが単一発話（single utterance）だ。
これは「音を細かく区切る」話ではなく、「認識リクエストそのものを終わらせる」話である。
ひとつの発話が終わったと判定された瞬間に、認識が止まり、接続が閉じる。
この記事では、グーグルとOpenAIが公開している開発者向けドキュメントの記述だけを材料にして、単一発話というモードが何を変えているのかを分解する。
サービスの順位づけはしない。仕組みの話だけをする。
【結論】AI英会話の単一発話モードは、1回の発話が終わった時点で認識ごと打ち切る設定だ
先に答えを置く。
グーグルの Single utterance behavior には、latest_short モデルを使った認識リクエストでは「発話が終わったと検出した時点で認識を止める」（原文＝once it detects an utterance has finished）と書かれている。
止めたあと、END_OF_SINGLE_UTTERANCE という種類のイベントを返し、そのあとに文字起こしの結果を返す。
| 比べるもの | 単一発話モード | ふつうの連続認識 |
|---|---|---|
| 認識が終わるきっかけ | 1回の発話が終わったこと | こちらが接続を閉じること |
| 終わったあとの接続 | 自動的に閉じる | 開いたまま |
| 返ってくる合図 | END_OF_SINGLE_UTTERANCE | 区切りごとの結果 |
| 向いている入力 | 短い一言・音声コマンド | 長い独白・ディクテーション |
⇒ 単一発話は「速さを買う代わりに、続きを捨てる」設定である。
AI英会話のアプリで「言い直しの途中で切られた」と感じる場面があるとすれば、この層の設計が効いている可能性がある。
AI英会話の単一発話は latest_short というモデルの上で動く
単一発話はスイッチではなく、モデルの選択によって決まる。
公式ドキュメントは「Cloud Speech-to-Text は、単一の発話からなる音声を認識するために latest_short モデルを提供する」と書いている。
そして用途として名指しされているのは、長い独白やディクテーションではなく、ユーザーが単発の音声コマンドを出すアプリケーションだ。
つまり、この設定は最初から「会話を延々と受け止める」ためのものとして作られていない。
latest_shortは認識の設定であるRecognizerに紐づけて選ぶ。- モデルを選んだ時点で、打ち切りの挙動がついてくる。
- あとから「今回だけ長く聞いて」と切り替える性質のものではない。
AI英会話を作る側から見ると、これは入口の設計思想の選択に近い。
AI英会話が返す END_OF_SINGLE_UTTERANCE は何の合図なのか
END_OF_SINGLE_UTTERANCE は、文字起こしの本体ではなく「もう聞くのをやめた」という通知だ。
公式ドキュメントの記述の順番が、そのまま処理の順番になっている。
- ①発話が終わったと検出する。
- ②
END_OF_SINGLE_UTTERANCEという種類の音声アクティビティ イベントを返す。 - ③そのあとに文字起こしの結果を返す。
アプリ側は、②を受け取った時点で「マイクの録音表示を消す」「返事を待つ表示に切り替える」といった見た目の処理に入れる。
つまりこのイベントは、AI英会話の画面が切り替わるタイミングを決めている部品でもある。
AI英会話でストリームが勝手に閉じるのは、単一発話のときだ
ここが実際の使い勝手にいちばん効く。
公式ドキュメントは、latest_short の Recognizer を StreamingRecognize リクエストに選んだ場合、発話が終わったあとにストリームを自動的に閉じる（原文＝close the stream automatically）と明記している。
閉じる主体はこちらではなく、サービス側だ。
だから「言い終わったつもりがなかった」としても、判定が下れば続きは同じ接続では届かない。
| 状態 | 誰が接続を閉じるか | 続きを話したらどうなるか |
|---|---|---|
| 単一発話モード | サービス側 | その接続では拾われない |
| 通常のストリーミング | アプリ側 | 同じ接続で続けて拾われる |
「もう一度言い直す」を前提にするなら、接続を張り直す設計が要る。
AI英会話で単一発話と音声アクティビティ イベントを同時に使うとどうなるか
両方を有効にしたときの挙動も、公式ドキュメントに書かれている。
まず、音声アクティビティ イベントは StreamingRecognize の gRPC リクエストでのみ使える機能で、streaming_features の enable_voice_activity_events を true にすると受け取れる。
単一発話と併用した場合、音声の開始と終了のイベントは引き続き返ると書かれている。
ただしタイムアウトの扱いだけが非対称になる。
| 設定できるタイムアウト | 単一発話モードでの扱い | 公式の理由 |
|---|---|---|
| 発話の開始を待つタイムアウト | そのまま適用される | 話し始めないまま終わる状況は依然あり得るため |
| 発話の終了を待つタイムアウト | 適用されない | 発話が終わり次第ストリームが閉じるため |
終了側のタイムアウトが無効になるのは、機能がぶつかっているからではなく、出番が来る前に接続が閉じるからだ。
なお、このタイムアウトの値は voice_activity_timeout で設定し、500ミリ秒より大きく、60秒より小さいという範囲が公式に定められている。開始側と終了側は独立して設定できる。
もうひとつ、時間の数え方にも注意書きがある。経過時間はサーバの時計ではなくリクエストで送られた音声のバイト数で測られており、1リクエストあたりの音声チャンクのサイズ上限は 15360 バイトと明記されている。
AI英会話の認識リクエストは3種類あり、単一発話が効くのはそのうち1つだ
単一発話の話は、認識の3つの型のうち「ストリーミング」の上でしか意味を持たない。
グーグルの Speech-to-Text の基本では、認識の方法が3つに整理されている。
| 方法 | 扱える長さ | 結果の返り方 |
|---|---|---|
| 同期認識 | 1分以下の音声データ | すべて処理してから返す |
| 非同期認識 | 最長480分まで | 長時間実行オペレーションとして後で取りに行く |
| ストリーミング認識（gRPCのみ） | マイクなどのライブ音声 | 話している最中から途中結果が出る |
公式ドキュメントは、ストリーミング認識について「ユーザーがまだ話している最中に結果が表示され得る」と書いている。
AI英会話が「話しながら文字が出る」体験になっているのは、この型を使っているからだ。
そして単一発話は、その途中結果の連なりをどこで打ち止めにするかを決めている。
AI英会話の単一発話は、沈黙で区切る設定とは層が違う
よく混同されるが、この2つは別の場所にあるつまみだ。
OpenAIの Realtime API のドキュメントでは、音声をどこで区切るかの設定は session.audio.input.turn_detection に置かれている。
そこで決まるのは音声の塊の切り方であって、接続そのものの寿命ではない。
- 区切りの設定＝送られてくる音を、どの単位の塊にまとめるか。
- 単一発話の設定＝そのリクエスト自体を、いつ終わらせるか。
- 前者は会話が続く前提。後者は1往復で終わる前提。
この違いを押さえておくと、アプリの挙動がどちらの層の設計なのかを切り分けられる。
AI英会話で単一発話モードが向く場面と、向かない場面
向き不向きは、公式が名指ししている用途からそのまま読める。
| 場面 | 単一発話モードとの相性 | 理由 |
|---|---|---|
| 単語や短文をひとつ読み上げる練習 | 合う | 公式が「単発の音声コマンド」を用途に挙げている |
| 質問に一言で答えるドリル | 合う | 1往復で完結し、待ち時間が短くなる |
| 言いよどみながら文を組み立てる練習 | 合いにくい | 途中で終わりと判定されると接続が閉じる |
| 長い説明やプレゼンの練習 | 合いにくい | 公式が「長い独白やディクテーションとは対照的」と書いている |
重要なのは、どちらが優れているかではなく、練習の型と設定の型が合っているかだ。
言いよどみを含んだ発話をそのまま受け止めてほしいなら、打ち切り前提のモードは相性がよくない。
逆に、単語や定型文を大量に回すなら、接続が自動で閉じる分だけ手数が減る。
AI英会話に単一発話を組み込む前に確認しておくこと
公式ドキュメントの冒頭には、見落としやすい但し書きが置かれている。
単一発話の挙動を説明したページは Preview の表示が付いており、Pre-GA Offerings Terms の対象で、「as is」で提供されサポートが限定される場合があると書かれている。
ページの最終更新日は 2026-09-09 UTC と記載されている。
- 仕様が動く前提で、挙動を自分のアプリで確かめる余地を残しておく。
- ストリームが閉じたあとの再接続を、あらかじめ設計に入れておく。
- 終了側のタイムアウトに頼った設計にしない。
また、音声の送り方そのものも認識の安定に効く。
グーグルの ベスト プラクティスでは、ストリーミングのフレームサイズについて「どんなサイズでも受け付けるが、大きいフレームは効率がよい代わりに遅延が増える」とし、100ミリ秒のフレームサイズが遅延と効率の折り合いとして推奨されている。
先に触れたとおりタイムアウトは送信バイト数で測られるので、極端に大きな塊を送る設計はここにも響く。
AI英会話の単一発話に関するよくある質問
Q. 言い終わる前に切られるのは、こちらの発音が悪いからか。 A. 発音の良し悪しとは別の層の話だ。単一発話モードでは、発話が終わったと検出された時点で認識が止まりストリームが閉じると公式に書かれている。切れ方の設計がそうなっている可能性がある。
Q. 切られたあとに続きを話したら、その分は届くのか。 A. 公式ドキュメントは StreamingRecognize のストリームが自動的に閉じると書いている。閉じた接続には続きは乗らないので、アプリが張り直しているかどうかで決まる。
Q. 沈黙の長さを設定すれば、切られなくなるのか。 A. 単一発話モードでは、発話終了側のタイムアウトは適用されないと公式に書かれている。開始側のタイムアウトは引き続き適用される。
Q. タイムアウトはどこまで伸ばせるのか。 A. 音声アクティビティのタイムアウトは「500ミリ秒より大きく、60秒より小さい」と公式に定められている。開始側と終了側は独立して設定できる。
Q. 長い文を練習したいときはどうすればいいか。 A. 用途として公式が挙げているのは単発の音声コマンドであり、長い独白やディクテーションはその対照として書かれている。長文を扱うなら、打ち切りのないストリーミング認識や、最長480分まで扱える非同期認識の側が想定されている。
まとめ｜AI英会話の単一発話モードは「打ち切る場所」を決める設定だ
もう一度整理する。
- 単一発話は
latest_shortモデルの挙動で、発話が終わった時点で認識を止めると公式に書かれている。 - 止めたあとに
END_OF_SINGLE_UTTERANCEを返し、続けて文字起こしの結果を返す。 StreamingRecognizeでは、発話の終了後にストリームが自動的に閉じる。- 音声アクティビティ イベントは併用でき、開始側のタイムアウトは効き、終了側は適用されない。
- 用途として公式が挙げているのは単発の音声コマンドで、長い独白やディクテーションはその対照に置かれている。
⇒ 「切られた」と感じたとき、原因を自分の英語だけに求める必要はない。
どこで打ち切るかは、使う側ではなく作る側が選んだ設定として先に決まっている。
※本記事の一次ソースは、各公式ドキュメントを2026-09-16および2026-09-18に取得した生テキストで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments