AI英会話で聞き取れない原因を6つに切り分ける。発音を疑う前に潰す設定と録音条件

AI英会話で自分の英語が聞き取れない、という状態に入ると、原因の候補が1つしか浮かばなくなる。

「自分の発音が悪いからだ」というやつだ。

ところが、音声認識の部品を売っている会社の開発者向けドキュメントを読むと、認識が落ちる条件は発音以外にいくつも並んでいる。

ロケールの指定、言語の自動判定、音の形式、サンプリングレート、マイクの位置、雑音処理のかけすぎ、語彙、無音の長さ。

どれも、あなたの口の動かし方とはまったく関係のないところで精度を下げる。

だから「聞き取れない＝発音が悪い」は、切り分けを飛ばした結論になる。

この記事では、原因の候補を上から順に潰していく手順を、公式ドキュメントに書いてある記述だけを材料にして組み立てる。

サービスの順位づけはしない。仕組みの話だけをする。

【結論】AI英会話が聞き取れないときは、発音より先に潰す原因が6つある

先に順番を置く。

音声認識は、あなたの声が届くまでに何段も通過している。どこか1段で落ちていれば、その先は全部おかしくなる。

順番	疑うもの	その場でできる判定
①	ロケール（どの英語で聞いているか）	設定画面で en-US 系かどうかを見る
②	言語の自動判定	日本語が混ざった直後に崩れないか
③	音の形式・サンプリングレート	Bluetooth通話用マイクを外して試す
④	マイクの位置と雑音処理	口元に近づける／ノイズ除去を切る
⑤	語彙（固有名詞・専門語）	その単語だけ毎回違う語に化けるか
⑥	無音と間の取り方	話し出しの前後に半秒の間を置く
⑦	発音そのもの	①〜⑥を潰してから、はじめて疑う

⇒ 発音は最後だ。 最初に疑うものではない。

理由は単純で、①〜⑥のほうが公式ドキュメントに「精度が落ちる」と明記されているからだ。書いてあるものから順に潰すほうが早い。

以下、1段ずつ開けていく。

AI英会話が聞き取れない原因①｜英語のロケールが自分の英語と合っていない

英語の音声認識は、1つではない。

マイクロソフトの言語サポート一覧を見ると、音声テキスト変換の英語だけで en-AU en-CA en-GB en-GH en-HK en-IE en-IN en-KE en-NG en-NZ en-PH en-SG en-TZ en-US en-ZA の15のロケールに分かれている（Azure AI Speech の言語サポート）。

ロケールが違えば、想定している母音の並びも、想定している語彙も違う。

同じ音を出しても、どのロケールで聞いているかによって、返ってくる文字列が変わる。

グーグルの公式ドキュメントも、この点を「設定の正確さ」の問題として書いている。

• リクエストの設定が、送っている音声を正確に記述しているかを確認すること。
• 正しい sampleRateHertz、正しい encoding、そして正しい language_codes と model を使っている認識器を使うことが、いちばん正確な文字起こしにつながると書かれている（Cloud Speech-to-Text の Best practices）。

⇒ 言語コードは「英語」ではなく「どの英語か」まで指定するものだ。

アプリ側に「アメリカ英語／イギリス英語」の切り替えがあるなら、そこが language_codes に当たる。自分が練習している英語と、そこの設定がずれていないかを最初に見る。

AI英会話が聞き取れない原因②｜言語の自動判定が別の言語に張り付いている

ここは、日本語話者がいちばん引っかかりやすい場所だ。

多くのアプリは、話された言語を自動で判定する仕組み（言語識別＝LID）を持っている。

この仕組みには、公式ドキュメントに書かれたはっきりした制約がある（Azure AI Speech の言語識別）。

仕様	ドキュメントの記述	あなたに起きること
候補言語の上限	開始時のLIDは最大4つ、継続的なLIDは最大10の言語	候補に入っていない話し方は選ばれない
候補外でも返す	候補言語がオーディオに含まれていない場合でも「それらのうちの1つを返します」	間違った言語でも、間違ったまま文字起こしされる
判定のタイミング	開始時のLIDは「オーディオの最初の数秒間で1回」判定し、5秒未満で返される	最初のひと言でその後が決まる
文中の切り替え	継続的なLIDでも「同じ文章内での言語の変更はサポートされていません」	英文に日本語の単語を挟むと崩れる
同一言語の複数ロケール	「同じ言語に対して複数のロケール（en-US と en-GB など）を含めないでください」	米英を同時に指定する設計はそもそも想定外

⇒ 「候補外の言語でも、候補の中から無理に1つ選んで返す」という挙動が、いちばん厄介だ。

エラーが出ないので、設定ミスなのか発音の問題なのかが画面から判別できない。

そして最初の数秒で判定が確定するという点も効いてくる。話し始めに「えーと」と日本語の間投詞を入れる癖があると、その数秒がそのまま判定材料になる。

• 話し始めを英語で始める。 最初の数秒が判定に使われると公式が書いている。
• 1文の中に日本語を混ぜない。 文中の言語切り替えはサポート外だと明記されている。
• 自動判定を切れるなら切って、英語に固定する。 判定そのものを消せば、判定ミスも消える。

AI英会話が聞き取れない原因③｜音の形式とサンプリングレートで落ちている

ここは発音とまったく関係がないのに、精度を大きく削る。

グーグルの Best practices には、推奨と回避が表の形で並んでいる。

項目	公式の推奨	避けるべきこと
サンプリングレート	「16,000 Hz or higher」で録る	低いレートは精度を下げうる。ただし再サンプリングは避ける
コーデック	ロスレスの FLAC または LINEAR16	mp3・mp4・m4a・μ-law・a-law などの非可逆は精度を下げうる
帯域が足りないとき	AMR_WB → OGG_OPUS の優先順で	それ以外の非可逆を安易に使う
フレームサイズ	100ミリ秒が遅延と効率の折り合いとして推奨	大きすぎるフレームは遅延になる

特に注意したいのが「避けるべきなのは低いレートではなく、再サンプリング」という書き方だ。

公式は、電話音声の native rate が一般に 8000 Hz であり、その場合は 8000 Hz のまま送るべきだと書いている。無理に引き上げても情報は増えない。

⇒ 「良い音にしよう」として途中で変換をかけると、かえって落ちる。

エンコーディング側のドキュメントは、この理屈をもっと踏み込んで説明している（Cloud Speech-to-Text の音声エンコーディング解説）。

• 音楽用のCDは 44,100 Hz だが、音声の再構成には 16000 Hz のほうが適切だと書かれている。
• API がサポートするロスレスは FLAC と LINEAR16 の2つ。ファイルサイズや通信量が重要なら FLAC を使うよう勧めている。
• MULAW は 8ビットのPCM符号化で、振幅を対数的に変調する。結果としてダイナミックレンジが狭くなる。16ビットの LINEAR16 のほうが優れていると明記されている。
• 非可逆圧縮で落ちたデータは、人間の耳には分からなくても「音声認識エンジンにとっては精度を大きく損ないうる」と書かれている。

実用に落とすと、Bluetoothヘッドセットの通話モードがここに当たる。

公式ドキュメントは、電話の世界の数字を明示している。Best practices は「電話では native rate が一般に 8000 Hz」と書き、エンコーディングのページは「ほとんどの電話機器は8ビットのビット深度を使う」と書いている。

つまり通話用の経路を通った音は、音楽用の音より細い前提で扱われている。同じ声でも、有線マイクや端末内蔵マイクに変えた瞬間に結果が変わることがあるのは、この段の差だ。

⇒ 声を変える前に、まず経路を変えて試す。 これは1分でできる切り分けになる。

AI英会話が聞き取れない原因④｜マイクの位置と、やりすぎた雑音対策

ここは、良かれと思ってやった対策が裏目に出る場所だ。

グーグルの Best practices は、認識器の設計思想をこう書いている。

認識器は、追加のノイズキャンセルなしで背景の声や雑音を無視するように設計されている。

そのうえで、前処理についてはっきり警告している。音声をサービスに送る前にノイズ除去の信号処理をかけると、認識精度はふつう下がる、と。

Best results の節に並んでいる指示は、次のとおりだ。

• マイクは話す人にできるだけ近づける。 背景音があるときは特に。
• 音割れ（audio clipping）を避ける。
• 自動ゲインコントロール（AGC）は使わない。
• ノイズリダクション処理はすべて無効にする。
• サンプル音声を自分で聴いてみる。歪みや想定外の雑音がなく、クリアに聞こえるべきだ。

⇒ 「ノイズキャンセリング強」で練習していたなら、それ自体が原因になりうる。

もう1つ、同じ表に書かれている重要な行がある。複数の人が同時に、あるいは違う音量で話している場合、背景ノイズと解釈されて無視されることがあるという記述だ。

テレビがついている部屋、家族の話し声がする部屋、カフェ。どれも「自分の声が無視される」条件に当てはまる。

マイクロソフト側の記述も、同じ方向を向いている。カスタム音声のデータ要件を説明するページには、音量が小さかったり邪魔な背景ノイズが入っていたりするオーディオは役に立たないとあり、サンプルを集める前にマイクと信号処理ハードウェアのアップグレードを常に検討するよう書かれている（トレーニングとテストのデータセット）。

AI英会話が聞き取れない原因⑤｜固有名詞と専門語彙は、そもそも辞書の外にある

この原因は、発音をいくら直しても解消しない。

グーグルの Best practices には、語彙の限界がそのまま書いてある。認識器は非常に大きな語彙を持つが、語彙の外にある用語や固有名詞は認識されない、と。

だから同じドキュメントは、単語・語句のヒントを使って語彙に名前や用語を足し、特定の語の精度を上げることを推奨している。

この「ヒント」の中身は、モデルアダプテーションのドキュメントに詳しい（Cloud Speech-to-Text の model adaptation）。

• モデルアダプテーションは既定では効果が比較的小さい。とくに1単語のフレーズでは小さいと明記されている。
• そこで boost という重みづけがある。値は0より大きい浮動小数で、実用上の上限は20とされている。
• ドキュメントが挙げる例は “fair” と “fare” だ。boost を使わなければ、この2語は同じ確率で認識される。
• boost を上げると取りこぼしは減るが、音声に無かった語が文字起こしに出てくる方向の誤りは増えうるとも書かれている。

⇒ “fair” と “fare” のような同音に近い組は、発音の問題ではなく確率の問題として扱われている。

マイクロソフト側にも、同じ性質の記述がある。専門用語や造語は発音が独特になることがあり、単語をより小さく分割して発音できれば認識できるという説明だ。

挙げられている例が分かりやすい。Xbox を認識させるために「エックス ボックス」と発音する、というものだ。

ただし同じ段落は、この方法で全体的な精度が向上するわけではないとも釘を刺している。効くのは、そのキーワードの認識に対してだけだ。

OpenAI 側は、これを利用者が渡せるパラメータとして整理している（OpenAI Speech to text ガイド）。

パラメータ	ドキュメントの用途
prompt	録音についての「構造化されていない文脈」を渡す
keywords	ドメイン固有の用語の文字起こしを改善する
languages	想定される入力言語を渡す

なお whisper-1 については、プロンプトに224トークンの上限があること、そして推奨モデルほど制御が効かないことが明記されている。

⇒ 自分の名前・勤務先・業界用語が毎回化けるのは、発音の失敗ではなく語彙の外にあるということだ。

AI英会話が聞き取れない原因⑥｜無音と間、そして同時に話す声

最後の非発音要因が、時間の使い方だ。

マイクロソフトのデータ要件のページには、録音の前後の無音についての具体的な指示がある。

可能であれば、各サンプルファイルの音声の前後に少なくとも0.5秒の無音部分を含める、というものだ。

つまり話し出しと言い終わりに、半秒ぶんの余白が要るという設計になっている。

録音ボタンを押した瞬間に話し始めて、言い終わった瞬間に止める使い方は、この余白を削っている。

• 話し始める前にひと呼吸置く。 冒頭の音が切れると、その単語ごと落ちる。
• 言い終わってからすぐ止めない。 語尾の子音は短く弱いので、真っ先に削れる。
• 途中の長すぎる沈黙は避ける。 区切りとして扱われる余地を作らない。

この「間」は、採点側でも見られている。

発音評価の FluencyScore は「音声がネイティブ スピーカーによる単語間のサイレント区切りの使用にどの程度近づくか」を示す指標だと定義されている（Azure AI Speech 発音評価）。

⇒ 無音は「何も無い時間」ではなく、評価対象のデータだ。

そして前述のとおり、複数の人が同時に話していると背景ノイズとして無視されうる。家族と同じ部屋で、相手の返事に自分の声をかぶせて練習する形は、この条件に当たる。

AI英会話が聞き取れないときの切り分け手順（上から順に潰す）

ここまでの記述を、そのまま手順に並べ替える。

手順	やること	これで直ったら原因は
1	同じ1文を3回、同じ条件で言う	毎回違う結果なら入力側、毎回同じなら設定か発音
2	言語設定を英語に固定する（自動判定を切る）	言語識別（原因②）
3	ロケールを練習中の英語に合わせる	ロケール（原因①）
4	Bluetoothを外し、有線または内蔵マイクにする	音の形式・レート（原因③）
5	ノイズ除去とAGCを切り、口元にマイクを寄せる	前処理と位置（原因④）
6	静かな部屋で、ひとりで話す	同時発話の無視（原因④⑥）
7	話し出しと言い終わりに半秒の間を置く	無音の欠落（原因⑥）
8	化ける単語を一般語に置き換えて言う	語彙の外（原因⑤）
9	ここまで全部やっても同じ語で落ちる	はじめて発音を疑う段

⇒ 1つずつしか変えない。 同時に2つ変えると、どれが効いたのか分からなくなる。

手順1を最初に置いているのには理由がある。再現性があるかどうかで、原因の性質が分かれるからだ。

毎回きれいに同じ誤変換が返ってくるなら、それは揺らぎではない。設定か、語彙か、あなたの音のどれかが一貫して同じ結果を作っている。

逆に、同じ文を言っているのに毎回違う語に化けるなら、入力の質が安定していない。マイク・雑音・距離のどれかだ。

AI英会話が聞き取れない状態を「発音のせい」と確定できる条件

切り分けの終点を決めておく。

次の条件がそろったとき、はじめて「音の側に原因がある」と言える。

• 言語とロケールが、練習中の英語に固定されている。
• マイク経路を2種類以上試して、結果が変わらない。
• 静かな部屋で、ひとりで、口元にマイクを寄せて話している。
• ノイズ除去とAGCが切ってある。
• 化ける単語が固有名詞や専門語ではなく、ごく一般的な語である。
• 同じ誤変換が、何度やっても同じ形で返ってくる。

⇒ ここまで来て落ち続ける単語だけが、発音練習の対象になる。

そして、その段に来たときに使える材料も、公式ドキュメント側にある。

カスタム音声のドキュメントには、音声を使ったトレーニングは、人間にとっても聞き取りにくい音声の場合に最大のメリットが得られるという記述がある。逆に言えば、人が聞けば分かる程度の音なら、多くの場合は音そのものよりテキスト側の材料で改善するという整理になっている。

同じページには、米国英語のような使用の多い言語では、基本モデルで既に優れた認識結果が得られるとも書かれている。

⇒ 英語は、認識器がいちばん鍛えられている言語のひとつだ。 それでも通らないなら、通らない理由は具体的なはずだ、と考えるほうが筋がいい。

AI英会話が聞き取れないときによくある質問

Q. AIが聞き取れないのは、やっぱり発音が悪いということか。 A. そう確定できるのは、言語・ロケール・マイク経路・雑音処理・語彙をすべて潰したあとだ。公式ドキュメントには、非可逆コーデック・過剰なノイズ除去・同時発話・語彙外の固有名詞が精度を下げると明記されている。どれも発音とは別の原因だ。

Q. ノイズキャンセリング付きのイヤホンを使えば認識は良くなるか。 A. グーグルの Best practices は逆のことを書いている。サービスに送る前にノイズ除去の信号処理をかけると認識精度はふつう下がり、ノイズリダクション処理はすべて無効にするよう指示されている。認識器はもともと雑音を無視する設計だと説明されている。

Q. 英語の中に日本語の単語を混ぜたら崩れた。これは仕様か。 A. 言語識別のドキュメントに「同じ文章内での言語の変更はサポートされていません」と明記されている。主にスペイン語を話しているときに英語の単語を挿入しても、単語ごとの言語変更は検出されないという例まで書かれている。

Q. 自分の名前や会社名だけが毎回化ける。 A. 語彙の外にある固有名詞は認識されないと公式に書かれている。対策としては、単語を小さく分けて発音する方法（Xbox を「エックス ボックス」と発音する例が挙げられている）や、ヒント・キーワードとして語を渡す方法がドキュメント上で示されている。ただし前者は全体の精度を上げるものではないと但し書きがある。

Q. マイクの録音品質はどこまで上げればいいか。 A. グーグルは16,000 Hz以上での収録とロスレスコーデックを推奨している。一方で、元が8000 Hzならそのまま送るべきで、再サンプリングは避けるようにとも書かれている。上げることより、途中で変換しないことのほうが重視されている。

Q. 録音した音声を送るタイプの練習で、どんな形式が無難か。 A. マイクロソフトのカスタム音声のデータ要件では、ファイル形式は RIFF（WAV）、サンプルレートは 8,000 Hz または 16,000 Hz、チャンネルは1（モノラル）、サンプル形式は PCM・16ビットと指定されている。これは学習用データの要件だが、認識器が想定している音の形を知る目安になる。

まとめ｜AI英会話が聞き取れないのは、発音だけの問題ではない

もう一度、要点を整理する。

• 英語の音声認識は1つではない。 マイクロソフトの言語サポートでは英語だけで15のロケールに分かれている。どの英語で聞いているかが合っていないと、同じ音でも結果が変わる。
• 言語の自動判定は、候補外の言語でも候補の中から1つ返す。 判定は最初の数秒で確定し、文中の言語切り替えはサポートされていない。
• 音の形式で落ちる。 非可逆コーデックは精度を下げうるとされ、ロスレスは FLAC と LINEAR16 の2つだけだ。再サンプリングは避けるよう明記されている。
• 雑音対策のかけすぎが逆効果になる。 ノイズリダクションは無効に、AGCは使わない、マイクは口元へ、と公式が指示している。
• 語彙の外は認識されない。 固有名詞や専門語が化けるのは発音の失敗ではなく、辞書とヒントの問題として扱われている。

⇒ 「聞き取れない」は1つの症状で、原因は少なくとも6系統ある。 上から順に潰していけば、発音の練習に取りかかるべきかどうかが、感覚ではなく手順で決まる。

切り分けをせずに発音だけを直そうとすると、直っていないものを直そうとして時間を使うことになる。そこがいちばんもったいない。

※本記事の一次ソースはすべて2026-09-12に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。