音声認識から音声合成までの3段で、AI英会話はどこで情報を落としているのか｜仕組みを分解する

「AI英会話の仕組み」を知りたくなるのは、たいてい何かがうまくいかなかったときだ。

話したのに認識されない。

返ってきた英語が、自分の言ったことと微妙にズレている。

こちらが言い終わる前に相手がしゃべり出す。

こうした現象は、どれも「AI英会話」という1つの箱の不具合に見える。

だが中身は1つの箱ではない。役割の違う部品が直列につながったものだ。

どの部品で何が起きているのかが分かれば、いま起きている不具合がどこの話なのかを切り分けられる。

この記事では、その部品を売っている会社が公開している開発者向けドキュメントの記述だけを材料にして、中身を1段ずつ開けていく。

サービスの順位づけはしない。

仕組みの話だけをする。

【結論】AI英会話の仕組みは「音声認識→言語モデル→音声合成」の3段でできている

先に答えを置く。

音声で会話する仕組みを自分で組み立てる開発者向けに、OpenAI は「チェーン型の音声ワークフロー」という作り方を案内している。

そこでは、アプリケーションが管理する段が 1. Speech-to-text 2. The agent workflow itself 3. Text-to-speech の3つだと明記されている（OpenAI｜Voice agents）。

この3段が、そのままAI英会話の骨格になる。

段	部品	入ってくるもの	出ていくもの
①	音声認識（Speech to Text）	あなたの声（波形）	文字列
②	言語モデル（LLM）	①が出した文字列	返事の文字列
③	音声合成（Text to Speech）	②が書いた文字列	あなたが聞く音

ここで効いてくるのは、段と段のあいだを渡っていくものが「文字列」しかないという点だ。

声に乗っていた情報は、①を通った時点でいったん文字に畳まれる。

②はその文字だけを見る。

③はまた文字から音を作り直す。

⇒ AI英会話で「伝わらない」と感じる現象の多くは、性能の問題ではなく、この畳み直しで何が落ちたかの問題だ。

そして3つの部品は、同じ会社の1つの製品ですらない。

マイクロソフトは音声テキスト変換とテキスト読み上げを別々のドキュメントで提供し、グーグルも Cloud Speech-to-Text と Cloud Text-to-Speech を別のサービスとして公開している。

つまりAI英会話のアプリは、別々に売られている部品を買ってきて並べたものである、という前提で見ると中身が読みやすくなる。

AI英会話の仕組み①｜音声認識は、あなたの声を「文字列」に変える工程

1段目は、マイクが拾った波形を英文テキストに置き換える部品だ。

ここには、同じ「音声認識」という名前でも中身の違う呼び出し方がいくつもある。

グーグルの Cloud Speech-to-Text は、認識のやり方を3種類に分けて説明している（Cloud Speech-to-Text overview）。

方式	ドキュメントの説明	会話に向くか
Synchronous recognition	「1分以下」の音声を処理し、全部処理してから結果を返す	向かない（言い終わるまで待つ）
Asynchronous recognition	長時間の処理を開始し、あとから結果を取りに行く。最長 480 minutes	向かない（録音向け）
Streaming recognition	gRPC の双方向ストリームで認識する。provides interim results as audio is captured	◎ これが会話用

会話で使われるのは3番目のストリーミングで、ドキュメントは「results can appear while a user is still speaking」＝ユーザーがまだ話している最中に結果が出ると書いている。

マイクロソフト側も同じ性質を「リアルタイム文字起こし」として挙げ、その中身を「ライブ オーディオ入力の中間結果を含むインスタント文字起こし」と説明している。

画面に出た英文が、しゃべっている途中でくるくる書き換わるのを見たことがあるなら、それが中間結果だ。

ここで重要なのは、中間結果は「まだ確定していない推測」だという点になる。

グーグルのドキュメントは、確定した結果に is_final という印が付くこと、そして信頼度スコアである confidence は「typically provided only for the top hypothesis」＝最上位の仮説にだけ、しかも is_final=true の結果にだけ付く、と明記している。

⇒ 確定前の表示に信頼度は付いていない。

その confidence は「an estimate between 0.0 and 1.0」で、各単語に割り当てられた尤度を集約して計算されると書かれている。

さらに、候補は1つではない。

max_alternatives を1より大きくすると複数の候補が返り、「The first alternative in the response is always the best (most likely) alternative」＝先頭が最有力候補だと決まっている。

⇒ 音声認識は「正解を出す装置」ではなく、順位の付いた候補のうち1位を返す装置だ。

この理解があると、AI英会話で変な単語が表示されたときに「自分の発音が壊滅的だった」と結論せずに済む。

2位以下に正解が並んでいた可能性が、仕様上は常にある。

AI英会話の仕組みで最初に情報が落ちるのは、音が文字になった瞬間

3段のうち、いちばん大きく情報が減るのがこの1段目の出口だ。

①が次の段に渡すのは文字列であって、声そのものではない。

その証拠に、声にしか入っていない情報は別の機能として個別に用意されている。

マイクロソフトの音声テキスト変換のドキュメントには、標準の文字起こしとは別立てで、次のような機能が並んでいる。

• ダイアライゼーション＝「オーディオ録音で異なるスピーカーを区別および分離するプロセス」。最大35人まで識別でき、35を超えるとエラーが返る。
• 言語検出＝「オーディオ入力で話されている言語を自動的に識別」する機能。事前に言語が分からないときや多言語の音声で使う。
• フレーズ リスト＝読み上げられる可能性の高い単語やフレーズをモデルに先に渡しておく機能。「ドメイン固有の用語、固有名詞、または一般的でない単語」の精度を上げるためのものだと書かれている。
• マルチチャネル文字起こし（プレビュー）＝最大2つのオーディオ チャネルを個別に文字起こしし、結果にソース チャネルのタグを付ける。

「誰が話したか」「何語で話したか」がわざわざ別機能になっているという事実が、そのまま「素の文字起こしにはそれが入っていない」ことを示している。

ためらい、言い直し、語尾を上げたか下げたか、声の張り。

これらは文字列になった時点で形を持たない。

入口の条件も効く。

グーグルは録音時のサンプルレートについて「capture audio using a sample rate of 16000 Hz」を推奨し、それより低いと認識精度が損なわれ、それより高くしても音声認識の品質に目立った効果はない（have no appreciable effect on speech recognition quality）と書いている。

そして認識できなかったときの挙動も明文化されている。

結果が空になる（unrecognized speech）主な原因として挙げられているのは、「very poor-quality audio」＝きわめて音質の悪い音声か、「language code, encoding, or sample rate values」＝言語コード・エンコード・サンプルレートの値が渡した音声と合っていないこと、の2つだ。

⇒ 認識されない原因として公式が先に挙げているのは、音質・言語コード・エンコード・サンプルレートの不一致であって、話者の英語力ではない。

AI英会話の仕組み②｜言語モデルは「文字になった後のあなた」しか見ていない

2段目は、①が出した文字列を読んで、返事の文字列を書く部品だ。

チェーン型のワークフローを選ぶ理由として、OpenAI のドキュメントははっきりとこう書いている。

「Inspect or transform intermediate text and replace each component independently」＝途中のテキストを点検・変換でき、各部品を独立に差し替えられる。

同じページには、その使いどころの具体例まで載っている。

文字起こしを保存し（store the transcript）、返答前にポリシー検査をかけ（run policy checks）、社内システムを呼び、そのうえで承認された答えになってから初めて音声を作る（generate speech only after the workflow reaches an approved answer）、という流れだ。

AI英会話に置き換えると、添削・言い換え提案・学習ログといった機能は、この「中間テキストが取り出せる」性質の上に成り立っている。

逆に言えば、2段目が扱えるのは文字列で表現できるものだけになる。

あなたが直してほしいもの	どの段が持っているか	2段目に届くか
語順・時制・冠詞・語彙の選び方	②に文字列として届く	◎ 届く
同じ言い回しばかり使う癖	②に文字列として届く	◎ 届く
母音の長さ・子音の作り方	①で文字に畳まれる	✕ 届かない
抑揚・強勢の置き方	①で文字に畳まれる	✕ 届かない
言い淀み・沈黙の長さ	どの段も文字にしない	✕ 届かない

⇒ 「文法は的確に直してくれるのに、発音の話になると急に雑になる」と感じるのは、2段目の性能ではなく、2段目に音が渡っていないからだ。

発音を採点する機能は、①の側に別の部品として用意されている。

段が違う、というのがここでの要点になる。

AI英会話の仕組み③｜音声合成が「聞く手本」を作り直している

3段目は、②が書いた文字列から音を作る部品だ。

グーグルはこの工程の呼び名を定義している。

「The process of translating text input into audio data is called synthesis」＝テキスト入力を音声データに翻訳する処理が合成であり、その出力が合成音声（synthetic speech）だ。

マイクロソフトのテキスト読み上げは、標準（ニューラル）音声について「100 以上の言語とロケールですぐに使用できる高品質のニューラル音声」と書いている（テキスト読み上げの概要）。

作り方の説明も具体的で、従来の音声合成が抱えていたストレスとイントネーションの制限を越えるために、「韻律予測と音声合成が同時に行われる」と明記されている。

音質の規格も書かれている。

各標準音声モデルは 24 kHz および高忠実度 48 kHz で利用できる、という記述がある。

そして、この段を細かく制御する言語が SSML（音声合成マークアップ言語）だ。

• マイクロソフト側の説明＝SSML で「ピッチの調整、一時停止の追加、発音の改善、話す速度の変更、音量の調整、単一のドキュメントへの複数の音声の割り当て」ができる。
• グーグル側の説明＝Cloud TTS は「speaking rate, pitch, volume, and sample rate hertz」の設定に対応している。
• ただしグーグルは「Cloud TTS does not support all SSML elements for all available languages」＝すべての言語ですべての SSML 要素に対応しているわけではないとも書いている。
• マイクロソフトの口形素（唇・顎・舌の位置のデータ）は「現在、en-US（米国英語）のニューラル音声でのみサポート」と書かれている。

⇒ AI英会話で聞こえてくる「手本の声」は、録音ではなく、その場で生成された音だ。

だから速度や間の取り方は、モデルの気分ではなく設定値で決まっている。

同じ文でも設定が変われば別の読み方になる。

課金の単位も、この段の性格をよく表している。

マイクロソフトは、テキスト読み上げの課金が「正常に処理された各要求の合計文字数」に基づき、そのカウントには文字・数字・スペース・句読点が含まれると書いている。

返事が長いほど3段目のコストが増える構造になっている、ということでもある。

AI英会話の仕組みは1種類ではない｜3段を並べる型と、1つのモデルが音のまま扱う型

ここまで3段の話をしてきたが、じつは「3段に分けない作り方」も公式に用意されている。

OpenAI の Voice agents のページは、音声エージェントの作り方を3つのアーキテクチャに整理した表を載せている。

アーキテクチャ	ドキュメントが挙げる「向いている用途」	選ぶ理由（原文の要旨）
GPT-Live	バックエンドを分けたフルデュプレックスの会話	会話を続けたまま、既存のテキスト処理とそのバックエンドを独立に選べる
Realtime API	音声・推論・ツール利用を1セッションで行う	1つのモデルが音声を解釈し、何をするか決め、音声で返す
Chained voice pipeline	音声とテキストの各段を自分で制御する	中間テキストを点検・変換でき、各部品を独立に差し替えられる

3つのうち Realtime API は「speech-to-speech」、つまり音から音へ直接つなぐ型だ。

この型について OpenAI は「The model works directly with audio」＝モデルが音声を直接扱うと書き、あわせて会話の状態を保持すること（maintains conversation state）とツールを呼べること（can call tools）を挙げている（OpenAI｜Getting started with the Realtime API）。

使うべき場面も明記されている。

「barge-in, low first-audio latency, natural turn taking, and realtime tool use」が要るとき、つまり割り込み・最初の音が出るまでの短さ・自然な話者交代が要るときだ。

同じページには、セッションが「audio turns, tools, interruptions, and handoffs」を扱うとも書かれている。

割り込みが仕様として名前を持っている、というのがこの型の特徴になる。

⇒ 会話の滑らかさを取りに行くと、中間テキストを自由に触る余地は減る。逆に添削や記録を厚くしたければ、段を分けた作りのほうが素直になる。

実際、OpenAI は文字起こしのワークフローについては別のページ（Realtime transcription／File transcription）へ案内しており、会話用の speech-to-speech とは扱いを分けている。

AI英会話のアプリを見比べるときは、「どちらが優れているか」ではなく「このアプリはどちらの型に寄せているか」で見ると、機能の有無に説明がつく。

AI英会話の仕組みで「間」を決めているのは、あなたではなく設定値

会話で最もストレスになるのは、たいてい認識精度ではなく「間」だ。

言い終わっていないのに割り込まれる。

逆に、言い終わったのに沈黙が続く。

この境目を決めているのは、話者交代の検出という独立した機能だ。

OpenAI の Realtime API のドキュメントは、次に読むべき項目として「Voice activity detection: Configure automatic turn detection」＝自動の話者交代検出を設定するを挙げている。

つまり「どこまでを1回の発話とみなすか」は、話し手の英語ではなくアプリ側の設定で決まっている。

通信の経路も間に効く。

同ドキュメントは、セッションが「WebRTC in the browser or WebSocket on the server」で接続されること、ブラウザ側では一時的なクライアント シークレット（ephemeral client secret）をサーバーが発行する流れを説明している。

遅延の測り方についても、Voice agents のページはかなり厳しいことを書いている。

• すべての遅延指標について「observed start and end event」＝観測の開始と終了のイベントを定義せよ、としている。
• 1本の単調なタイムラインを使い、中央値と裾（tail）の両方を報告せよ、としている。
• 「Do not substitute a backend-only timer for end-to-end response time」＝バックエンドだけの時間を、端から端までの応答時間の代わりにするな、と明記している。
• さらに「I’m checking.」のような相づちが早く返ってきても、「An earlier acknowledgment does not show that the requested result arrived sooner」＝求めた結果が早く届いた証拠にはならない、と釘を刺している。

⇒ 体感の速さと、実際に中身のある返事が届くまでの速さは別物として設計されている。

AI英会話の仕組みが分かると、つまずきの原因を段で切り分けられる

ここまでの話を、症状から逆引きできる形に並べ直す。

症状	疑う段	ドキュメント上の根拠
何も認識されず、画面が空のまま	①の入口	音質・言語コード・エンコード・サンプルレートの不一致が代表的な原因だと明記
途中まで正しいのに最後に書き換わる	①の中間結果	確定前の結果が返る仕様。確定は is_final で示される
固有名詞や専門語だけ崩れる	①の語彙	フレーズ リストが「ドメイン固有の用語、固有名詞」向けの機能として存在する
文法は直るのに発音に触れてくれない	②の入力	②に渡るのは文字列だけ。音は①で畳まれる
読み上げが速い・間が変	③の設定	SSML で速度・一時停止・ピッチ・音量を制御する仕様
言い終わる前に割り込まれる	話者交代の検出	自動の turn detection が設定項目として存在する

この切り分けは、使う側が自分でできる範囲を広げてくれる。

仕組みから言える、無理のない使い方は次のとおりだ。

• 認識されないときは、まず入口を疑う。 録音環境とマイク、そして設定されている言語を確認する。公式が原因として先に挙げているのはそこだ。
• 画面の英文は「1位の候補」として読む。 候補は複数あり、先頭が最有力というだけの仕様になっている。
• 発音の話と文法の話を、同じ画面で同時に求めない。 別の段が担当しているので、聞き方を分けたほうが噛み合う。
• 固有名詞を使う練習は、崩れる前提で組む。 語彙を先に教える機能が別に存在するということは、素のままでは弱いということでもある。
• 「自然に聞こえた」を成果の証拠にしない。 Voice agents のページも「A natural-sounding response does not prove」＝自然に聞こえる返答は証明にならない、と書いている。何の証明にならないかというと、ツールが動いたことと、アプリ側の状態が変わったことだ。

評価の観点についても、同ページは入力側の認識を「accents, background noise, language switches, names, and numbers」＝訛り・背景雑音・言語の切り替え・人名・数字にわたってテストせよと書いている。

開発側が「ここは崩れやすい」と自覚して並べている項目が、そのまま使う側のつまずきポイントの一覧になっている。

AI英会話の仕組みに関するよくある質問

Q. AI英会話は、私の発音を直接聞いて返事を考えているのか。 A. 作り方によって変わる。段を分けたチェーン型では 1. Speech-to-text 2. The agent workflow itself 3. Text-to-speech の順に処理されるので、返事を考える段に届くのは文字列だ。一方 Realtime API の speech-to-speech 型は「The model works directly with audio」と書かれており、音声を直接扱う。

Q. なぜ話している途中で英文がくるくる変わるのか。 A. それが仕様だからだ。

ストリーミング認識は「provides interim results as audio is captured」＝取り込みながら中間結果を返す作りで、確定した結果には is_final の印が付く（出典）。

Q. 認識されないのは発音が悪いからか。 A. それ以前の要因が公式に列挙されている。

認識結果が空になる原因として挙がっているのは「very poor-quality audio」と、言語コード・エンコード・サンプルレートが音声と一致していないことだ。

録音は 16000 Hz が推奨で、それより低いと精度が損なわれると書かれている。

Q. AIの声が不自然に感じるのはなぜか。 A. 合成音声は文字列から作り直された音で、速度・ピッチ・一時停止・音量は SSML などの設定値で決まる（出典）。

設定が会話の内容に合っていないと、中身は正しくても不自然に聞こえる。

Q. 話し終わりをAIが待ってくれないのは設定で変わるか。 A. 話者交代の検出は独立した設定項目として存在する。

Realtime API のドキュメントは「Voice activity detection: Configure automatic turn detection」を次に読むべき項目として案内している（出典）。

使う側で変えられるかはアプリの作り次第だが、少なくとも話し手の英語力の問題ではない。

まとめ｜AI英会話の仕組みは3段。どこで落ちたかが分かれば直せる

もう一度、短く整理する。

• 段を分けた作りでは、処理は音声認識 → 言語モデル → 音声合成の順に進む。公式ドキュメントが3段として明記している。
• 段と段のあいだを渡るのは文字列だけ。声にしかない情報は、話者分離や言語検出といった別機能として切り出されている。
• 音声認識は順位の付いた候補の1位を返す装置で、確定前の中間結果も返す。信頼度は0.0〜1.0の推定値だ。
• 音声合成は録音ではなくその場で作られた音。速度・ピッチ・一時停止は設定値で決まる。
• 3段に分けない speech-to-speech 型もあり、そちらは割り込みと話者交代の自然さに寄せた設計になっている。

⇒ 「AIに通じなかった」は、3段のどこかで起きた1つの出来事であって、英語力の総合評価ではない。

どの段で落ちたのかを言えるようになれば、次に何を変えればいいかも言えるようになる。

仕組みを知る価値は、そこにある。

※本記事の一次ソースはすべて2026-09-11に各公式ドキュメントで確認した。

仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。