AI英会話の画面に出てくる日本語訳や字幕は、あなたが話した言葉そのものではない。
それはいくつかの部品を順番に通ったあとの、加工ずみの出力だ。
だから「訳が変だ」と感じたとき、原因は翻訳だけにあるとはかぎらない。
手前の段で音が別の単語に化けていれば、そのあとの訳は、化けた単語を忠実に訳しただけになる。
この記事では、AIの部品を売っている会社が公開している開発者向けドキュメントの記述だけを材料にして、翻訳表示と字幕表示が何をしているのかを段ごとに開けていく。
そのうえで、翻訳が画面に出ていることが学習側にどんな副作用を持つのかまで書く。
サービスの順位づけはしない。仕組みの話だけをする。
【結論】AI英会話の翻訳は「音→テキスト→訳文」の段を踏んだ結果であって、原文ではない
先に答えを置く。
音声翻訳は、音をいきなり別の言語の音に変える魔法ではない。
マイクロソフトの音声翻訳のドキュメントは、この機能を「音声ストリームのリアルタイムの多言語音声変換と音声テキスト変換をサポートします」と説明したうえで、返ってくるものをこう書いている。「音声の検出中には中間トランスクリプションと翻訳結果が返され、最終的な結果は、合成された音声に変換することができます」（音声翻訳とは何か｜Microsoft Learn・2026-09-11取得）。
ここに、翻訳表示の構造がそのまま出ている。
| 段 | やっていること | 画面に出るもの |
|---|---|---|
| ① | 音を英文テキストに起こす（音声テキスト変換） | 英語の字幕 |
| ② | 起こしたテキストを別の言語のテキストに訳す | 日本語の訳 |
| ③ | 訳したテキストを音声に合成する（任意） | 読み上げ音声 |
⇒ ②の入力は、あなたの声ではなく①の出力だ。
この一点を押さえるだけで、翻訳表示にまつわる不満のほとんどが説明できるようになる。
訳がおかしいとき、真っ先に疑うべきは訳ではなく、その手前の書き起こしのほうだ。
同じドキュメントには、課金の説明のなかにも段構造がはっきり出ている。「音声翻訳サービスはリアルタイムで動作し、中間の音声結果が中間の翻訳結果を生成するために翻訳されることに注意してください。したがって、実際の翻訳量は、入力オーディオのトークンよりも大きくなります」とあり、各ターゲット言語について「音声からテキストへの文字起こしと、テキスト翻訳に対して課金されます」と書かれている。
⇒ 提供側から見ても、これは1つの処理ではなく2つの処理の積み上げとして扱われている。
AI英会話の翻訳が持つ3つの形｜標準・ライブ通訳・複数言語同時
ひとくちに音声翻訳と言っても、公式ドキュメントは形を分けて書いている。
マイクロソフトの音声翻訳の概要は、主な機能を「リアルタイム音声翻訳」「ライブ インタープリター」「複数のターゲット言語への翻訳」の3つとして並べている。
- リアルタイム音声翻訳（標準）＝「指定したソース言語で入力オーディオ ストリームを送信し、指定したターゲット言語で翻訳されたテキスト、合成音声、またはその両方を返す」形。入り口で言語を指定するのが前提になっている。
- ライブ インタープリター＝「入力言語を設定しなくても、話されている言語を継続的に識別し、話者のスタイルとトーンを維持する自然な音声で低待機時間の音声読み上げ翻訳を提供します」と書かれている形。「再起動せずに、同じセッションで複数の音声言語を処理します」という言語の切り替えにも触れている。
- 複数のターゲット言語への翻訳＝「入力言語を 2 つのターゲット言語に直接翻訳する機能」。それ以上が必要なら別のリソースや別の翻訳サービスが要る、と明記されている。
学習者として知っておく価値があるのは、ライブ インタープリターに付いている制限のほうだ。
高度な機能の一覧のなかに、「ターゲット言語での文字起こし。ソース言語の文字起こしはまだ使用できません。」という1行がある。
⇒ この形では、訳のほうは出るが、話された英語そのものの書き起こしは出ない。
英語学習の観点では、これは決定的な差になる。
自分の英語がどう聞き取られたかを確認できるのは①の出力であって、②の出力ではないからだ。
訳しか出ない画面では、発音が通じたかどうかの手がかりが残らない。
AI英会話の字幕が途中で書き換わるのはなぜか｜部分的な結果と最終結果は別物
字幕を見ていると、いま出た単語が数秒後に別の単語に差し替わることがある。
これは不具合ではなく、仕様として文書化された挙動だ。
マイクロソフトのキャプション付けのドキュメントは、こう書いている。「発話がまだ認識されている間に、音声認識の結果が変化する可能性があります。部分的な結果は、それぞれの Recognizing イベントで返されます。各単語が処理されると、音声サービスによって新しいコンテキストで発話が再評価され、最適な結果が返されます。新しい結果が前の結果と同じであるとは限りません。」（音声認識を用いたキャプション付け｜Microsoft Learn・2026-09-11取得）
そして「発話の完全で最終的な文字起こしは、Recognized イベントで返されます」と続く。
同じドキュメントには、実際に書き換わる例まで載っている。
しきい値を設定していない状態では welcome to applied math がいったん出たあとで mathematics になり、course 2 が course 201 になる、という認識シーケンスが示されている。
⇒ 途中の字幕は「現時点での最有力候補」であって、確定した文ではない。
この区別は、部品を売っている各社がそろって同じ形で持っている。
| 提供元 | 途中の結果 | 確定した結果 |
|---|---|---|
| Microsoft（Speech SDK） | Recognizing イベント＝「部分的な結果」 | Recognized イベント＝「完全で最終的な文字起こし」 |
| Google（Cloud Speech-to-Text） | ストリーミングの interim results | is_final が付いた結果 |
| OpenAI（Realtime transcription） | input_audio_transcription.delta | input_audio_transcription.completed |
グーグルのドキュメントは、ストリーミング認識について「Streaming recognition provides interim results as audio is captured. For example, results can appear while a user is still speaking.」（ストリーミング認識は音声を取り込みながら途中結果を返す。たとえばユーザーがまだ話している最中に結果が現れることがある）と書いている（Cloud Speech-to-Text overview｜Google Cloud・2026-09-11取得）。
同じページには、確からしさを示す confidence について「This field is typically provided only for the top hypothesis and only for results where is_final=true」（このフィールドは通常、最上位の候補に対して、かつ is_final=true の結果に対してのみ提供される）という記述もある。
⇒ 途中結果には、そもそも確からしさの数値すら付いていない。
OpenAI のリアルタイム文字起こしのガイドも、運用時の注意として「Decide how your UI should revise partial text when later deltas correct earlier text.」（あとから来る差分が前のテキストを訂正したとき、画面上の途中テキストをどう書き換えるかを決めておくこと）と明記している（Realtime transcription｜OpenAI・2026-09-11取得）。
訂正が起きることは、作る側では最初から織り込みずみの前提になっている。
AI英会話の翻訳に遅れが出る理由｜待ち時間と正確さは交換になっている
字幕や訳が「一拍遅れて出る」のも、性能不足ではなく設計上の取引の結果だ。
キャプション付けのドキュメントは、この取引をそのまま言葉にしている。
「リアルタイムのキャプション付けには、待ち時間と精度に関するトレードオフがあります。各 Recognizing イベントのテキストをできるだけ早く表示できます。一方、ある程度の待ち時間を受け入れることができる場合は、Recognized イベントのテキストを表示することで、キャプションの精度を向上させることができます。」
OpenAI 側も同じことを、設定の説明として書いている。
「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.」（ストリーミング文字起こしは待ち時間と書き起こし品質を交換する。遅延設定を小さくすると途中テキストが早く出る。大きくするとモデルはテキストを出す前により多くの音声文脈を得られ、単語誤り率を改善しうる）
同じガイドには、遅延の段階として minimal low medium high xhigh の5つが並べられ、low は「low-latency live captions」（低遅延のライブ字幕）向け、high は「when accuracy matters more than immediate display」（即時表示より正確さが重要なとき）向けと説明されている。
| 優先するもの | 画面で起きること | 学習側の向き不向き |
|---|---|---|
| 速さ | 途中結果が早く出る。書き換わりが多い | 会話のテンポは保てるが、字幕を読む目が忙しくなる |
| 正確さ | 確定してから出る。表示が遅れる | あとから読み返す用途に向く |
⇒ 「訳が遅い」と「訳が揺れる」は、同じつまみの両端にある。
片方を直すと、もう片方が必ず悪くなる関係になっている。
そして翻訳が挟まる場合は、この遅れがもう一段積まれる。
音声翻訳のドキュメントが書いているとおり、中間の音声結果もいったん翻訳されてから中間の翻訳結果になるからだ。
AI英会話の字幕の「揺らぎ」は設定で減らせる｜安定した部分的結果という中間地点
速さか正確さかの二択ではなく、公式には中間地点が用意されている。
キャプション付けのドキュメントは、それを「”安定した部分的な結果” と呼ばれる中間地点もあります」と紹介している。
具体的な仕組みも公開されている。「返す Recognizing イベントの数を減らして正確さを上げるよう、音声サービスに要求できます。これは、SpeechServiceResponse_StablePartialResultThreshold プロパティを 0 と 2147483647 の間の値に設定することによって行います。設定する値は、音声サービスが Recognizing イベントを返す前に単語を認識する必要がある回数です。」
そのうえで「より安定した部分的結果を要求すると、”揺らぎ” つまりテキストの変化は減りますが、信頼度の高い結果を待つ待機時間が長くなる可能性があります」と、代償まで書いてある。
しきい値を 5 に設定した例では、さきほどの認識シーケンスが welcome to → welcome to applied → welcome to applied mathematics と進み、「単語は変更または撤回されません」と説明されている。
⇒ 揺らぎは、確定していない候補を早く見せているから起きる。
つまり、字幕がちらつくアプリは「速さ側に振っている」というだけのことだ。
もう1つ、字幕を読むときに知っておくべき仕様がある。
同じドキュメントに、「部分的な結果の句読点は使用できません。」という注記がある。
⇒ 途中の字幕に句読点が無いのは、あなたの話し方が平板だからではない。
句読点は確定側で付く。だから途中の字幕を見て「文の切れ目が分からない」と感じるのは、仕様どおりの見え方になる。
AI英会話の字幕に出る英文は、話した音のままではない｜表示テキストの整形
ここは、翻訳より手前でいちばん誤解されている部分だ。
確定した字幕は、認識された音の並びをそのまま並べたものではない。
マイクロソフトの表示テキストの書式設定のドキュメントは、音声テキスト変換が「文字起こしされたテキストを明確で読みやすくするために、一連の書式設定機能」を持つと書き、その中身を4つに分けて説明している（音声テキスト変換での表示テキストの書式設定｜Microsoft Learn・2026-09-11取得）。
| 機能 | 認識された音声 | 表示テキスト |
|---|---|---|
| 逆テキスト正規化（ITN） | that will cost nine hundred dollars | That will cost $900. |
| 大文字化 | i want to visit new york city | I want to visit New York City. |
| 不要な言葉の除去 | umm i think tomorrow should work | I think tomorrow should work. |
| 句読点 | we can go to the mall park or beach | We can go to the mall, park, or beach. |
とくに効くのが「不要な言葉の除去」だ。
ドキュメントは「音声には、口ごもりや、単語の重複や、”えーと” や “あー” のようなつなぎ言葉が含まれることがよくあります。音声テキスト変換では、このような不要な言葉を認識し、表示テキストから除去できます」と書いている。
⇒ 画面の英文は、あなたの発話より整って見える。
言い直しやつなぎ言葉が消えた文を見て「自分はきれいに話せている」と判断するのは、仕組みのうえでは早い。
また ITN については「音声テキスト変換サービスがこのプロセスを完了し、これは構成できません」とあり、利用者側で切ることは想定されていない。
そして、この整形ずみのテキストが翻訳の入力になる。訳文は、整形の結果まで込みで作られている。
AI英会話の翻訳は「入力は方言まで、出力は言語まで」｜指定の粒度が違う
入り口と出口で、言語の指定のしかたが揃っていない。
マイクロソフトの言語サポート一覧の音声翻訳の節には、翻訳元と翻訳ターゲットで別々の指定方法が書かれている（Azure Speech の言語と音声のサポート｜Microsoft Learn・2026-09-11取得）。
| ドキュメントの記述 | 意味 | |
|---|---|---|
| 翻訳元言語 | 「入力音声認識の言語を設定するには、完全なロケールをダッシュ (-) 区切り記号で指定します」。jv-ID と wuu-CN を除くすべての言語がサポートされ、指定しない場合の既定は en-US | 方言まで区別する |
| 翻訳ターゲット言語 | 「翻訳ターゲット言語を設定するには、通常、ロケールダッシュ (-) 区切り記号の前にある言語コードのみを指定します。たとえば、es の代わりにスペイン語 (スペイン) の es-ES を使用します」。指定しない場合の既定は en | 言語までしか区別しない |
⇒ 聞き取る側は米国英語と英国英語を分けるのに、訳を出す側は「英語」でひとまとめになる。
同じ節のテキスト言語の表を数えると、翻訳先として並んでいる言語は91件ある（英語は en・2026-09-11取得）。
数は多いが、粒度は粗い。ここが実感とのズレを生む。
もう1つ、翻訳の向きに強い制約が付いている実例がある。
OpenAI の文字起こしガイドは、翻訳用のエンドポイントについて「To translate a completed audio recording into English, use /v1/audio/translations with whisper-1. Unlike transcription, which preserves the recording’s original language, this endpoint returns English text.」と書き、さらに「This endpoint supports translation into English only.」（このエンドポイントは英語への翻訳のみをサポートする）と明記している（File transcription｜OpenAI・2026-09-11取得）。
⇒ 「英語→日本語」と「日本語→英語」は、同じ機能の裏表ではない。
どちら向きが使えるかは、アプリが何を呼んでいるかで変わる。
AI英会話で翻訳が挟まると学習側に起きること｜英語のまま処理する回数が減る
ここまでは仕様の話だった。ここからは、その仕様が学習にどう効くかを整理する。
翻訳表示は、理解を助ける。それは間違いない。
ただし、画面に訳が出ている状態は、英語を英語のまま処理する機会をその都度1回ずつ差し引いていることでもある。
仕組みの側から言えるのは、そこまでだ。効果の大小を断定する材料は、部品のドキュメントには無い。
そのうえで、翻訳表示に特有の副作用として、仕様から具体的に指摘できるものが3つある。
- 誤りの原因が見えなくなる。 訳だけを見ていると、おかしな訳が「訳の失敗」なのか「手前の書き起こしの失敗」なのか区別できない。ライブ インタープリターのようにソース言語の文字起こしが出ない形では、区別する材料そのものが画面に無い。
- 自分の発話を実際より整った形で記憶する。 表示テキストは ITN・大文字化・不要な言葉の除去・句読点付けを通っている。つなぎ言葉や言い直しは消えたあとの姿で画面に残る。
- 訳を読む時間が、聞く時間を食う。 字幕は待ち時間と精度の取引の上に出ている。正確さ側に振られていれば、訳が出るころには相手は次の文に入っている。
⇒ 翻訳表示は「理解の補助」としては強く、「自分の英語の点検」には向いていない。
点検に向いているのは、②の訳ではなく①の書き起こしのほうだ。
自分が言ったつもりの英文と、画面に出た英文を並べる。ここに差があれば、それが音の問題として残る。
訳文は、その差を隠してしまう。手前で別の単語に化けていても、訳は化けた単語を自然な日本語にしてくれるからだ。
AI英会話の翻訳・字幕まわりで精度を上げる手立て（仕様に書いてあるものだけ）
手前の段の精度が上がれば、訳の精度も一緒に上がる。順番はいつもそうなっている。
公式ドキュメントに書かれている手立ては、主に次のものだ。
- フレーズ リスト。 キャプション付けのドキュメントは「音声認識を開始する直前に提供する語句のリスト」と定義し、「フレーズ リストにフレーズを追加すると、その重要性が増加するため、認識される可能性が高くなります」と書いている。例として挙がっているのは名前・地理的な場所・同音異義語・業界や組織に固有の単語や略語だ。
- 言語識別。 「オーディオの言語が変化する可能性がある場合は、継続的な言語識別を使用します」とあり、「最大 10 個の候補言語を指定します」と数まで書かれている。
- カスタム モデル。 「状況によっては、カスタム モデルをトレーニングすることが、精度を高める最善の方法と考えられます」と書かれている。音声テキスト変換の概要も Custom Speech を「特定のドメインおよび条件に対して精度を強化したモデル」として挙げている（音声テキスト変換とは｜Microsoft Learn・2026-09-11取得）。
- 遅延設定の見直し。 OpenAI のガイドは「The exact delay in milliseconds can vary by model configuration, so benchmark with representative audio instead of assuming a fixed timing per level.」として、実際の音声で測ることを勧めている。
学習者が触れる画面に、これらのつまみが出ていることはまずない。
だから利用者側でできるのは、つまみを回すことではなく「どちら側に振られているかを読むこと」になる。
字幕がちらつくなら速さ側、遅れて出るなら正確さ側だ。
もう1つ、キャプション付けのドキュメントには、使う側への配慮として「キャプションが自動サービスによって生成されることを対象ユーザーに知らせます」という項目が挙がっている。
⇒ 字幕は自動生成物であるという前提が、提供側の推奨事項として明文化されている。
AI英会話の翻訳に関するよくある質問
Q. 訳がおかしいとき、翻訳のせいなのか。 A. 分けて考える必要がある。音声翻訳は音を直接訳すのではなく、いったんテキストに起こしてから訳す段を踏む。手前で別の単語に起こされていれば、訳はその単語を忠実に訳す。まず英語側の書き起こしが出るなら、そこを見るのが先になる。
Q. 字幕が途中で書き換わるのは不具合か。 A. 仕様だ。公式ドキュメントは「発話がまだ認識されている間に、音声認識の結果が変化する可能性があります」と書いており、welcome to applied math が mathematics に変わる例まで載せている（出典）。
Q. 途中の字幕に句読点が無いのはなぜか。 A. 「部分的な結果の句読点は使用できません。」と明記されている。句読点は確定側の結果に付く。
Q. 訳を消して英語だけで練習したほうがいいのか。 A. どちらが伸びるかを断定できる材料は、部品のドキュメントには無い。言えるのは構造の話だけだ。訳が出ている画面では英語のまま処理する回数がその分だけ減り、自分の英語がどう聞き取られたかを点検する材料は訳ではなく英語側の書き起こしに残る。
Q. 日本語から英語への翻訳と、英語から日本語への翻訳は同じ性能か。 A. 同じとはかぎらない。OpenAI の翻訳エンドポイントは「This endpoint supports translation into English only.」と英語への一方向に限定されている。マイクロソフト側は翻訳元を完全なロケールで、ターゲットを言語コードのみで指定する形になっており、入り口と出口で粒度そのものが違う。
Q. 同時に何か国語にも訳せるのか。 A. マイクロソフトの音声翻訳は「入力言語を 2 つのターゲット言語に直接翻訳する機能」を提供していると書かれている。それ以上を出すには別のリソースか別の翻訳サービスが要ると明記されている。
まとめ｜AI英会話の翻訳は理解の補助には効き、英語の点検には向かない
もう一度整理する。
- 音声翻訳は音→テキスト→訳文の段を踏む。訳の入力は声ではなく書き起こしなので、訳の不自然さは手前の段が原因のことがある。
- 字幕が書き換わるのは仕様。部分的な結果（
Recognizing）と最終結果（Recognized）は別物で、途中結果には句読点も付かない。 - 遅れと揺らぎは同じつまみの両端。公式ドキュメントは待ち時間と精度のトレードオフを明記し、中間地点として「安定した部分的な結果」を用意している。
- 画面の英文は整形ずみ。ITN・大文字化・不要な言葉の除去・句読点付けを通っているので、実際の発話より整って見える。
- 翻訳表示は理解を助けるが、自分の英語を点検する材料にはならない。点検に使えるのは訳ではなく英語側の書き起こしのほうだ。
⇒ 訳を見るか消すかを決める前に、いま自分は「意味を取りたい」のか「音を点検したい」のかを分けるほうが早い。
目的が分かれていれば、翻訳表示は敵にも味方にもなる。
※本記事の一次ソースはすべて2026-09-11に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments