英語で話していて単語が出てこず、つい「えっと、あの、なんだっけ」と日本語がこぼれる。
この日本語まじりの一文を、AI英会話はどう処理しているのか。
多くの人はここで「たぶん無視されている」「たぶん英語として適当に書き起こされている」と想像する。
実際には、そのどちらでもない。
音声認識の手前には言語識別（LID＝Language Identification）という別の部品が立っていて、そこで「この音声は何語か」がまず決められている。
そして、その判定の仕様には、日本語まじりの英語にとって決定的な制約が書かれている。
この記事では、AIの部品を売っている会社の開発者向け公式ドキュメントの記述だけを材料にして、言語が混ざったときに何が起きるのかを分解する。
英語学習の心構えの話はしない。判定の仕組みの話だけをする。
【結論】日本語まじりの英語は「どちらか1つの言語」に寄せて処理される
先に答えを置く。
公式ドキュメントに書かれている仕様を一言でまとめると、こうなる。
言語識別は、1つの発話に1つの言語ラベルを付ける。
Microsoftの 言語識別を実装する には、継続的な言語識別について次の記述がある。
「継続的な LID では、同じ文章内での言語の変更はサポートされていません。たとえば、主にスペイン語を話しているときに、英語の単語を挿入した場合、単語ごとの言語の変更は検出されません」
⇒ 1つの文の中で言語が切り替わっても、単語ごとの切り替えは検出されない。
これは精度の問題ではなく、機能としてサポートされていないという明示だ。
| 話し方 | 言語識別から見た扱い |
|---|---|
| 英語だけで1文 | 英語として1ラベル |
| 日本語だけで1文 | 日本語として1ラベル |
| 1文の中に日本語と英語が混ざる | 単語ごとの切り替えは検出されない |
| 文と文のあいだで言語が変わる | 継続的LIDなら複数言語を識別できる |
つまり日本語まじりを安全に通したいなら、混ぜる場所を「文の中」から「文の境目」へ移すしかない、というのが仕様から出る答えになる。
日本語まじりを判定している部品｜言語識別（LID）は何をしているのか
まず、言語識別という部品の役割を確認する。
Microsoftの公式は、言語識別を「オーディオで読み上げられた言語を、サポートされている言語の一覧と比較して自動的に識別するために使用されます」と説明している。
用途として挙げられているのは2つだ。
- 音声テキスト変換認識＝オーディオ内の言語を識別して文字起こしする。
- 音声翻訳＝オーディオ内の言語を識別して別の言語に翻訳する。
そして同じページには、使う側への注意もはっきり書かれている。
「音声認識では、言語識別の初期待機時間が長くなります。このオプション機能は、必要な場合にのみ含めてください」
⇒ 言語識別は既定でいつも動いている機能ではなく、わざわざ足すオプションだ。
足していないサービスでは、言語は最初から en-US のように固定されている。その場合、日本語まじりの部分は「英語として何か」に押し込まれることになる。
識別と認識は別物だという注意も、公式が明記している。「認識と識別を混同しなようにしてください。言語識別があってもなくても認識は使用できます」という一文だ。
日本語まじりで挙動が割れる分岐点｜開始時LIDと継続的LID
言語識別には2つのモードがあり、日本語まじりの扱いはここで大きく変わる。
| モード | 公式の説明 | 日本語まじりへの効き方 |
|---|---|---|
開始時の LID（AtStart） | オーディオの最初の数秒間で1回、言語を識別する。5秒未満で返される | 最初の数秒で決まった言語が、そのあとずっと続く |
継続的な LID（Continuous） | オーディオの間、複数の言語を識別できる | 文をまたぐ切り替えには追随する。文の中の切り替えは非対応 |
モードは SpeechServiceConnection_LanguageIdMode というプロパティで指定する。
公式は「それがない場合、Speech サービスは既定で開始時の LID になります」と書いている。
⇒ 既定は「最初の数秒で決め打ち」のほうだ。
最初のひとことが「えっと」だったら、そこで日本語と判定される可能性がある、という構造になっている。
また継続的LIDには対応言語（SDK）の制約もある。公式は「継続的な言語識別は、C#、C++、Java（音声テキスト変換のみ）、JavaScript（音声テキスト変換のみ）、およびPythonでのみサポートされます」と注記している。
継続的LIDは継続的認識でのみ使える、という制約も同じページに書かれている。
日本語まじりと候補言語リスト｜挙げられる言語の数には上限がある
言語識別は、何もないところから言語を当てているわけではない。
あらかじめ候補言語のリストを渡す仕様になっている。
公式の記述はこうだ。「AutoDetectSourceLanguageConfig オブジェクトを使用して候補言語を指定します。少なくとも 1 つの候補がオーディオに含まれていると想定しています。開始時点の LID には最大 4 つの言語を含めることができ、継続的 LID には最大 10 の言語を含めることができます」
| モード | 候補言語の上限 |
|---|---|
| 開始時点の LID | 最大 4 言語 |
| 継続的 LID | 最大 10 言語 |
ここで重要なのは、日本語まじりの英語を扱うにはリストに日本語と英語の両方が入っている必要があるということだ。
⇒ 候補が英語だけのサービスでは、日本語まじりの部分に日本語ラベルが付く道がそもそも無い。
さらにロケールの書き方にも制約がある。公式は「ダッシュ（-）区切りで完全なロケールを指定する必要がありますが、言語識別では基本言語ごとに 1 つのロケールのみが使用されます。同じ言語に対して複数のロケール（en-US と en-GB など）を含めないでください」と書いている。
Azure Speech の言語と音声のサポート 側にも「言語識別では、英語やドイツ語などの言語レベルで音声が比較されます。候補リストには、同じ言語のロケールを複数含めないでください」という同趣旨の注意がある。
日本語まじりで起きる強制マッピング｜候補に無い言語でも候補のどれかが返る
ここが、日本語まじりの挙動を理解するうえで最も重要な1文だ。
Microsoftの公式はこう書いている。
「音声サービスは、提供された候補言語がオーディオに含まれていない場合でも、それらのうちの 1 つを返します。たとえば、fr-FR（フランス語）と en-US（英語）が候補として指定されているが、ドイツ語が話されている場合、サービスからは fr-FR または en-US が返されます」
「分かりません」という返り値は無い。候補のどれかが必ず返る。
⇒ 日本語まじりの音声も、候補が英語だけなら英語として何かに書き起こされる。
これが、意味の通らない英単語の羅列が画面に出る現象の仕組み側の説明になる。
認識器の語彙についても関連する記述がある。Google Cloudの Best practices は「The recognizer has a very large vocabulary, however terms and proper names that are out-of-vocabulary will not be recognized.」と書いている。語彙の外にあるものは認識されない、という前提だ。
日本語の単語を英語のモデルに投げるということは、この「語彙の外」に当たりにいく行為でもある。
日本語まじりをGoogleはどう扱うか｜最大3言語と「少ないほど当たる」
同じ問題を、Google Cloudは別の形で仕様化している。
Automatically detect language には、複数言語の指定方法が説明されている。
公式の説明はこうだ。「In a request with multiple languages, Cloud Speech-to-Text attempts to transcribe the audio using the best-fit language from the list of alternates you provided. Cloud Speech-to-Text then labels the transcription results with the predicted language code.」
渡した候補の中から最も適合する1つを選び、その言語コードのラベルを結果に付けるという設計だ。ここでも1つに寄せている。
数の上限も明記されている。
You can list up to three languages for automatic language recognition.＝自動言語認識に挙げられるのは最大3言語。Though you can specify up to three languages, constrain the language list to the bare minimum needed as a best practice. The fewer language codes you specify, the higher the likelihood that Cloud Speech-to-Text successfully selects the correct one.＝候補は必要最小限にする。少ないほど正しく選べる可能性が上がる。You can only use the alternative languages feature with the long, short, and telephony models.＝この機能が使えるモデルは限られている。
⇒ 日本語を候補に足すと、英語の判定そのものが不利になる。これは公式が明示しているトレードオフだ。
公式はさらに、この機能が向く用途を ideal for apps that need to transcribe short statements like voice commands or search と書いている。長い会話向けとは書かれていない。
日本語のロケールコードは Supported languages に ja-JP（Japanese (Japan)）として掲載されている。
日本語まじりとリアルタイム文字起こし｜languages と空の配列
OpenAIのRealtime APIにも、期待される言語を渡す口がある。
Realtime transcription ガイド には、文字起こしの設定として prompt・keywords・languages の3つが説明されている。
公式の一文がそのまま日本語まじりの話につながる。
Add context when the audio contains specialized vocabulary or more than one expected language.
1つ以上の言語が想定される音声では、文脈を足せという指示だ。
| 設定 | 公式の説明 |
|---|---|
prompt | Use prompt to describe the recording or its setting.（録音やその状況を説明する） |
keywords | Use keywords for product names, acronyms, and other literal terms that may appear in the audio. |
languages | Use languages for expected input languages.（想定される入力言語） |
言語コードの形式も明記されている。ISO 639-1（en・es・fr など）、選ばれた ISO 639-3（eng・spa・yue・cmn など）、zh の地域コード（zh-cn など）だ。
そして The Realtime API rejects unsupported or incorrectly formatted language codes. と書かれている。形式が違えば受け付けられない。
判定に自信が持てない場合の挙動も、公式が書いている。When gpt-transcribe can't make a reliable language prediction, languages is an empty array.
信頼できる言語予測ができないときは、言語の配列が空で返る。日本語まじりは、まさにこの「自信が持てない音声」に当たりやすい。
さらに gpt-live-transcribe doesn't return detected-language predictions. とも書かれている。モデルによっては、何語と判定したかが返ってこない。
評価の章には Test with representative microphones, telephony audio, accents, background noise, code-switching, domain vocabulary, and long sessions. という一文があり、code-switching（言語の切り替え）がテスト項目として名指しされている。
日本語まじりが後段に与える影響｜採点と訂正まで揺れる
言語の判定がずれると、被害はその層で止まらない。
音声認識の結果は、そのまま後ろの層へ流れていく。
- 表示テキストの整形＝表示テキストの書式設定 によれば、句読点・大文字化・不要語の除去が自動で適用される。日本語まじりの断片も、この整形を通って形を変える。
- 発音の採点＝発音評価の使用方法 によれば、スクリプト化された評価では発音を参照テキストと比較する。参照テキスト側が想定していない語が混ざれば、比較の前提が崩れる。
- 言語モデルの返事＝文字起こしを材料に返事が作られる。材料が崩れていれば、返事も崩れる。
⇒ 「発音が悪いと言われた」の原因が、実は言語識別のずれだった、という並びがありうる。
公式が明記しているプロソディ評価のロケール制限（en-US のみ）とあわせて考えると、混在した音声に対する採点結果は、そのまま英語力の測定値としては読めない。
採点が急に低く出た日は、話し方ではなく入力に何が混ざっていたかを先に疑ったほうが早い。
日本語まじりを減らすために設定側でできること
作る側が触れる範囲には、公式に書かれた手がいくつもある。
| やりたいこと | 公式に記述のある手 |
|---|---|
| 文をまたぐ切り替えに追随させる | SpeechServiceConnection_LanguageIdMode を Continuous にする |
| 候補言語を絞って精度を上げる | Googleは「候補は必要最小限に。少ないほど正しく選べる可能性が上がる」と明記 |
| 固有名詞や専門語を通す | Googleの word and phrase hints、OpenAIの keywords |
| 状況を伝えて精度を上げる | OpenAIの prompt（録音やその状況の説明） |
| 言語を1つに固定する | 言語識別を足さず、ロケールを固定して認識する |
話す言語そのものを指示文で制御する方法も、Prompting GPT-Live に書かれている。
Speak [language] unless the user asks to switch.
同じページには、指示文を書く言語についての助言もある。Write your prompt in the language you want the model to speak.＝話させたい言語で指示文を書け、という指示だ。
さらに Do not guess the caller's language from their name or location という注意も置かれている。名前や場所から言語を推測するな、ということだ。
keywords についての制約も押さえておきたい。公式は Keywords are hints, not required output. と書いている。ヒントであって、必ずその通りに出力されるわけではない。
日本語まじりを前提にした話し方の組み立て
利用者の側で取れる手も、仕様から素直に導ける。
- 混ぜるなら文の境目で混ぜる。同じ文の中での切り替えは検出されない、と公式が明記している。日本語で言いたいことは、いったん切ってから言う。
- 最初のひとことを英語にする。既定は開始時のLIDで、最初の数秒で1回だけ判定され、5秒未満で返る。出だしが日本語だと、その判定を引きずる。
- 単語が出ないときは日本語で埋めず、英語で言い換える。候補の外にある語は認識されない、という記述がGoogleの推奨事項にある。
- 文字起こしの画面があるなら、混ざった箇所がどう書き起こされたかを見る。そこにそのサービスの候補言語設定が映っている。
- 採点や訂正の結果を読む前に、入力が正しく取れているかを見る。入力が崩れていれば、後段の数字は読む価値が下がる。
どれも「日本語を混ぜるな」という精神論ではなく、1発話に1言語という仕様に合わせるための手だ。
仕様が1つに寄せてくるなら、こちらも1つに寄せて渡すのがいちばん摩擦が少ない。
なお、文と文のあいだで言語が変わる話し方なら、継続的LIDを使っているサービスでは複数言語を識別できる、と公式が書いている。混ぜ方の設計しだいで結果は変わる。
日本語まじりに関するよくある質問
Q. 日本語まじりの文は、混ざった部分だけ日本語として認識されるのか。 A. 継続的LIDについて、公式は「同じ文章内での言語の変更はサポートされていません」「単語ごとの言語の変更は検出されません」と明記している（言語識別を実装する）。単語単位での切り替えは想定されていない。
Q. 日本語まじりだと「認識できませんでした」と出ないのはなぜか。 A. Microsoftの公式は、候補言語がオーディオに含まれていない場合でも候補のうちの1つを返す、と書いている。判定を保留する返り値が仕様に無い。
Q. 日本語まじりに備えて候補に日本語を足せば解決するか。 A. 解決とは言い切れない。Googleは The fewer language codes you specify, the higher the likelihood that Cloud Speech-to-Text successfully selects the correct one. と書いており、候補を増やすこと自体が選択の難易度を上げる（Automatically detect language）。
Q. 日本語まじりを検出しているサービスかどうかを、利用者が見分ける方法はあるか。 A. 文字起こしの画面がある場合、文をまたいで日本語の行が出るなら継続的LIDが動いている可能性がある。ただしモデルによっては判定結果自体が返らない。OpenAIは gpt-live-transcribe doesn't return detected-language predictions. と明記している（Realtime transcription）。
Q. 日本語まじりで発音スコアが落ちるのは実力か。 A. 入力の言語判定がずれれば、後段の比較の前提が崩れる。加えてプロソディ評価は en-US ロケールのみと公式が明記している（発音評価の使用方法）。混在した音声のスコアを、そのまま英語力として読むのは無理がある。
まとめ｜日本語まじりは「判定の外」ではなく「1つに寄せられる」
もう一度整理する。
- 1発話に1言語。継続的LIDでも「同じ文章内での言語の変更はサポートされていません」と公式が明記している。
- 既定は開始時のLID。最初の数秒で1回判定し、5秒未満で返る。出だしの言語が効く。
- 「分かりません」は返らない。候補がオーディオに含まれていなくても、候補のどれかが返る仕様だ。
- 候補を増やすと当たりにくくなる。Googleは最大3言語と上限を置き、必要最小限にすることを推奨している。
- 混ざると後段まで揺れる。整形・採点・返事の全部が、この文字起こしを材料にしている。
⇒ 日本語まじりは無視されているのでも、うまく拾われているのでもない。候補の中のどれか1つへ寄せられている。
だから対処は単純で、混ぜるなら文の境目で混ぜる。そして出だしの数秒を英語で始める。仕様の側に合わせるほうが、結果は安定する。
※本記事の一次ソースはすべて2026-09-16に各公式ドキュメントで確認した。仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。
Comments