AI英会話アプリで英語を話していると、まだ言い終わっていないのに画面に文字が出てくることがある。
しかも、その文字は一度出たあとで書き換わる。
これを不具合だと思っている人がいるが、そうではない。
音声認識のストリーミングという方式が、設計どおりに動いている姿だ。
この方式には、速く出すか正確に出すかという取引が最初から組み込まれている。
この記事では、AIの部品を売っている会社の開発者向け公式ドキュメントだけを材料にして、ストリーミングが何をしていて、何を捨てているのかを分解する。
サービスの順位づけやおすすめはしない。仕組みの話だけをする。
【結論】ストリーミングはAI英会話で「待たせない」ための方式だ
先に答えを置く。
ストリーミングは、音声を全部受け取ってから処理するのではなく、届いた端から処理して、途中経過を返し続けるやり方だ。
グーグルのCloud Speech-to-Text basics は、認識のやり方を3つに整理している。
| 方式 | 公式の説明 | 扱える長さ | 途中経過 |
|---|---|---|---|
| Synchronous recognition | 音声を送り、すべて処理してから結果を返す | 1分以下 | 出ない |
| Asynchronous recognition | 長時間処理を開始し、結果を定期的に取りに行く | 最大480分 | 出ない |
| Streaming recognition | 双方向ストリームの中で認識する（gRPCのみ） | ライブ音声 | 出る |
公式はストリーミングの目的をはっきり書いている。「Streaming requests are designed for real-time recognition purposes, such as capturing live audio from a microphone.」＝マイクからのライブ音声のような、リアルタイム認識のために設計されている、というものだ。
さらに「results can appear while a user is still speaking」＝利用者がまだ話している最中に結果が現れうる、とまで明記されている。
⇒ 話している途中で文字が出るのは、仕様どおりの動きだ。
ストリーミングが返すのは2種類のテキスト｜途中経過と確定
ストリーミングの結果は、1種類ではない。
グーグルは、途中経過を interim results（中間結果）と呼び、確定した結果には is_final という印が付くと説明している。
「For streaming responses, all results marked as is_final appear in contiguous order.」＝確定印の付いた結果は連続した順序で現れる、と書かれている。
OpenAIのRealtime transcription は、同じ構造をイベント名で表している。
| 種類 | OpenAIのイベント | 中身の例 | 画面での見え方 |
|---|---|---|---|
| 途中経過 | ...input_audio_transcription.delta | "delta": "Hello," | 薄い字で出て、書き換わる |
| 確定 | ...input_audio_transcription.completed | "transcript": "Hello, how are you?" | 濃い字で固まる |
公式は「returns transcript deltas as speech arrives and a final transcript when your application commits each audio turn」＝音声が届くにつれて差分を返し、アプリがそのターンを確定したときに最終の文字起こしを返す、と説明している。
⇒ 「Hello,」という途中経過が、最終的に「Hello, how are you?」になる。これが公式ドキュメントに載っている実際の例だ。
マイクロソフトの音声テキスト変換も、リアルタイム文字起こしを「ライブ オーディオ入力の中間結果を含むインスタント文字起こし」と定義している。
3社とも、途中経過を返すことを機能の中心に据えているということだ。
ストリーミングで文字が書き換わる理由｜AI英会話の画面が揺れる仕組み
途中経過は「その時点までの音だけで出した暫定の答え」だ。
だから後から音が届けば、前に出した文字が書き換わる。
OpenAIのRealtime transcription は、この書き換えを設計上の論点として本番前チェックリストに入れている。
「Decide how your UI should revise partial text when later deltas correct earlier text.」＝後から来た差分が前のテキストを直したとき、画面をどう書き換えるかを決めておけ、というものだ。
- 途中経過をそのまま見せる設計＝速いが、文字が揺れる。
- 確定だけ見せる設計＝揺れないが、話し終わるまで何も出ない。
- 薄い字と濃い字で分ける設計＝揺れる範囲を利用者に示す。
⇒ AI英会話アプリごとに文字の出方が違うのは、認識エンジンの差ではなく、この設計判断の差でありうる。
もうひとつ、公式は順序についても注意を書いている。
「Ordering between completion events from different speech turns isn’t guaranteed.」＝別々の発話ターンから来た完了イベントの順序は保証されない。
そのため item_id を使って対応づけろ、と指示されている。
早口で立て続けに話したときにログの並びが乱れることがあるのは、この保証の無さに由来する。
ストリーミングは速さと正確さの取引になっている｜遅延の5段階
ここがストリーミングの核心だ。
OpenAIのRealtime transcription は、「Tune latency and accuracy」という節で、こう言い切っている。
「Streaming transcription trades latency for transcript quality.」＝ストリーミングの文字起こしは、待ち時間と文字起こしの品質を取引する。
そして理由まで書かれている。「Higher delay settings give the model more audio context before emitting text and can improve word error rate.」＝遅延を大きくするとテキストを出す前により多くの音声文脈が得られ、単語誤り率が改善しうる、というものだ。
公式が挙げている出発点は5段階ある。
| 設定値 | 公式が挙げる用途 | AI英会話での意味 |
|---|---|---|
minimal | もっとも待ち時間に敏感なやりとり | 即応するが、書き換えが増える |
low | 低遅延のライブ字幕 | 会話しながら字幕を見る用途 |
medium | 待ち時間と精度の釣り合い | 標準的な会話練習 |
high | 即時表示より精度が大事なとき | 発話のログを正確に残したいとき |
xhigh | 文脈のために最大の遅延を許容できるとき | リアルタイム性を捨てる用途 |
ただし公式は、段階ごとのミリ秒を決め打ちするなとも書いている。
「The exact delay in milliseconds can vary by model configuration, so benchmark with representative audio instead of assuming a fixed timing per level.」＝実際の遅延は構成によって変わるので、代表的な音声で実測せよ。
⇒ 「このアプリは反応が遅い」と感じたとき、原因はモデルの性能ではなく、この設定の置き方かもしれない。
ストリーミングが省いているもの｜タイムスタンプ・話者ラベル・確信度
速さを取った代わりに、落ちている情報がある。
OpenAIのRealtime transcription は、専用の節を立ててこう明記している。
「gpt-live-transcribe doesn’t return word-level timestamps, speaker labels, or transcription confidence scores.」＝単語ごとのタイムスタンプ、話者ラベル、文字起こしの確信度スコアを返さない。
公式は、タイムスタンプや話者ラベルが要るなら、対応しているファイル文字起こしのモデルを使うか、アプリ側で代替手段を用意しろと書いている。
- 単語ごとのタイムスタンプが無い＝「この単語で詰まった」を秒単位で示す機能は、この方式だけでは作れない。
- 話者ラベルが無い＝自分とAIの声を機械的に区別する情報は付いてこない。
- 確信度スコアが無い＝「自信のない箇所」を色分けする機能も、この方式だけでは作れない。
確信度については、グーグル側にもっと踏み込んだ記述がある。
Cloud Speech-to-Text は confidence を0.0から1.0の推定値と定義したうえで、「典型的には最上位の仮説かつ is_final=true の結果にだけ提供される」と書いている。
さらに強い注意が付いている。「Don’t include confidence as a required field in your code. It may not be set in any of the results, and it may not be accurate.」＝必須項目として扱うな、値が入らないこともあるし、正確でないこともある。
同じページは、珍しい単語は正しく認識されても低い値が付くことがある、という例まで挙げている。
⇒ 認識の「自信度」を学習者への評価に使うのは、公式の書きぶりから見て筋が良くない。
ストリーミングに文脈を足す｜キーワードと言語の指定
ストリーミングの途中でも、認識のヒントは足せる。
OpenAIのRealtime transcription は、専門語や複数言語が混じる音声のために、セッション中に設定を変える session.update を使えると書いている。
| 項目 | 公式の説明 | 英語学習での使いどころ |
|---|---|---|
prompt | 録音の内容や状況を説明する | 「ビジネス会議のロールプレイ」と伝える |
keywords | 製品名・略語など、音声に出そうな字面の語 | 教材に出る固有名詞や略語を登録する |
languages | 入力として想定される言語 | 英語と日本語が混ざる前提を伝える |
delay | 待ち時間と精度の釣り合い | 上の5段階から選ぶ |
ただし、キーワードは命令ではない。
公式は「Keywords are hints, not required output.」＝キーワードはヒントであって、必ず出力されるものではない、と明記している。
書式の制約もある。1つのキーワードは1行に収め、山かっこや改行を含めてはいけない、含めるとセッション更新が拒否される、とされている。
言語コードについても、ISO 639-1（en や fr など）、一部のISO 639-3、地域つきの zh ロケールが使えると列挙されている。
対応していない形式や誤った形式のコードは、APIが拒否すると書かれている。
なお、話した言語を推定して返すかどうかはモデルによって違う。
公式は gpt-transcribe の完了イベントには検出言語が含まれ、信頼できる推定ができないときは空の配列になると書いている。一方 gpt-live-transcribe は検出言語の推定を返さない、とも明記されている。
ストリーミングとターンの区切り｜どこで1回分が確定するのか
途中経過が確定に変わるきっかけは、自動と手動の2通りある。
OpenAIのRealtime transcription が載せている設定例では、turn_detection を null にして自動のターン検出を切っている。
この場合、音声を input_audio_buffer.append で送り続け、終わらせたいところで input_audio_buffer.commit を送る、という手順になる。
公式は、サーバー側に区切りを検出させたいなら音声活動検出（VAD）を設定しろと書いている。
- 手動の確定＝アプリのボタンを押したときに1回分が締まる。区切りが予測しやすい。
- 自動の確定＝沈黙などから機械が区切りを判断する。ボタンは要らないが、考えている沈黙で切られうる。
- どちらでも、途中経過は同じように流れてくる。
⇒ 「押しながら話す」タイプと「黙っていると勝手に進む」タイプの差は、ここで決まっている。
接続の仕方も公式が2つ挙げている。サーバー側の音声パイプラインにはWebSocket、ブラウザの音声にはWebRTCだ。
グーグル側では、ストリーミング認識はgRPCの双方向ストリームでのみ提供されると明記されている。
ストリーミングの質をAI英会話で見極めるときに見るところ
公式ドキュメントには、評価のしかたまで書かれている。
OpenAIのRealtime transcription は、合成音声だけで設定を決めるなと釘を刺したうえで、テストすべき条件を列挙している。
代表的なマイク、電話音声、さまざまな訛り、背景雑音、言語の切り替え、専門語彙、長いセッション、の7つだ。
この一覧は、そのまま学習者の試用チェックリストになる。
| 公式が挙げるテスト条件 | 自分で試すなら |
|---|---|
| 代表的なマイク | いつも使うイヤホンとPC内蔵マイクの両方で話す |
| 背景雑音 | 静かな部屋と、生活音のある部屋で同じ文を言う |
| 言語の切り替え | 英語の途中に日本語を1語混ぜてみる |
| 専門語彙 | 教材の固有名詞を言ってみる |
| 長いセッション | 短い会話ではなく、続けて話してみる |
公式の本番前チェックリストには、単語誤り率とは別に「空の文字起こし・途中で切れた文字起こし・遅れた文字起こし」を分けて追え、という項目もある。
⇒ 「認識が悪い」とひとくくりにせず、何も出ないのか、途中で切れるのか、遅れて出るのかを分けて見るのが公式の作法だ。
評価用データに数字・日付・メールアドレス・製品名・専門語を入れろ、という指示もある。
英語学習でいえば、日付や数字を英語で言う練習は、認識がいちばん崩れやすいところだということになる。
ストリーミングについてのよくある質問
Q. 話している途中で文字が出るのは正常か。 A. 正常だ。グーグルの公式が「results can appear while a user is still speaking」と書いている。中間結果を返すことがこの方式の設計目的そのものだ。
Q. 出た文字が後から書き換わるのはなぜか。 A. 途中経過はその時点までの音だけで出した暫定の答えだからだ。OpenAIの公式は、後から来た差分が前のテキストを直したときに画面をどう書き換えるかを決めておけ、と本番前チェックリストに入れている（出典）。
Q. 反応を速くすれば認識も良くなるのか。 A. 逆になる。公式が「Streaming transcription trades latency for transcript quality.」と書いており、遅延を大きくするほど音声の文脈が増えて単語誤り率が改善しうる、とされている。
Q. 「この単語で詰まった」を秒単位で出す機能は作れるか。 A. この方式だけでは作れない。gpt-live-transcribe は単語ごとのタイムスタンプを返さないと公式が明記しており、必要ならファイル文字起こしのモデルか、アプリ側の代替手段が要るとされている。
Q. 認識の確信度は学習の指標になるか。 A. 向いていない。グーグルの公式が「必須項目として扱うな、値が入らないこともあるし、正確でないこともある」と明記している。珍しい単語は正しく認識されても低い値が付きうる、という例も載っている（出典）。
Q. 教材の固有名詞を登録すれば必ず認識されるのか。 A. されるとは限らない。OpenAIの公式が「Keywords are hints, not required output.」と書いている。ヒントであって、出力の保証ではない。
まとめ｜ストリーミングは速さを買って、情報を手放す方式だ
もう一度整理する。
- 認識のやり方は公式で3つに分かれ、途中経過を返すのはストリーミングだけだ。ライブ音声のために設計されている。
- 返ってくるのは途中経過と確定の2種類。書き換わるのは仕様であり、不具合ではない。
- 速さと正確さは取引関係にある。公式は遅延の出発点を5段階示し、実測で決めろと書いている。
- 速さの代償として、単語ごとのタイムスタンプ・話者ラベル・確信度スコアが返らないと公式が明記している。
- キーワードや言語の指定でヒントは足せるが、キーワードは出力の保証ではない。
⇒ AI英会話の「反応の速さ」と「文字起こしの正確さ」は、同時に最大化できるものではない。
会話のテンポを取るアプリと、ログの正確さを取るアプリがあるのは、性能差ではなく設計判断の差として読める。
自分が練習したいのがテンポなのか、言えた内容の正確な記録なのかで、合う設計は変わる。
※本記事の一次ソースはすべて2026-09-16に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments