LLMが突然英語で返してくる「言語混乱」はなぜ起きるのか

日本語で質問したのに英語で返ってくる「言語混乱」とは

ChatGPTやClaudeに日本語で質問したはずなのに、返答の途中から突然英語が混ざってきた経験はないでしょうか。あるいは、韓国語でプロンプトを送ったら全文英語で返ってきた、というケースも報告されています。これは「言語混乱（Language Confusion）」と呼ばれる現象で、多言語対応を謳うLLMが抱える構造的な問題のひとつです。

Understanding and Mitigating Language Confusion in LLMs（Cohere研究チーム, 2023）は、この問題を初めて体系的に定義した論文です。同論文によれば、言語混乱には大きく3種類あります。

ユーザーが日本語で質問したのに回答全体が英語になってしまう「全体混乱」、日本語と英語が段落や行ごとに切り替わる「行レベル混乱」、そして文章の大部分は日本語でも特定の単語やフレーズだけ英語になる「局所混乱」です。

一見すると「局所混乱」は軽微に思えますが、実際にはこれが最も検出しにくく、ユーザー体験をじわじわ損なうことが多いと研究では指摘されています。「なんとなく読みにくい」と感じる原因がこれだったりします。

Evaluating LLMs’ Language Confusion in Code-switching（Oh et al., 2024）では、英語と韓国語が混在する入力に対して主要なLLMを評価した結果、言語混乱は「一部のモデルで起きる稀な問題」ではなく「ほぼすべてのモデルで発生する課題」だと報告されています。問題は、どのモデルがどの程度深刻かという度合いの差です。

では、そもそもなぜ言語混乱は起きるのでしょうか。その答えは、モデルの訓練プロセスの深いところにあります。

言語混乱が起きる3つの原因：訓練データ・RLHF・トークナイザー

言語混乱は単一の原因で起きるわけではありません。モデルの訓練プロセスを3つの層に分けて見ると、それぞれに問題の種が潜んでいます。

まず訓練データの不均衡です。GPT系やLLaMAなどの主要モデルが学習するCommon Crawlをはじめとするウェブデータは、英語が全体の60〜70%を占めると推定されています。モデルはこのデータから「英語で出力するほど損失が下がりやすい」というパターンを自然に学習してしまいます。日本語や韓国語のような低リソース言語（学習データが少ない言語）で質問を受けると、モデルの内部では英語で回答するほうが「確率が高い」状態になっているため、言語が引っ張られるのです。

次に影響するのがRLHF（Reinforcement Learning from Human Feedback）の偏りです。RLHFとは、人間の評価者がモデルの出力にフィードバックを与え、良い回答を強化する学習手法です。この評価者も英語話者に偏りがちで、英語で書かれた回答のほうが高評価を受けやすい傾向があります。結果として、「日本語で質問されても英語で答えるほうが報酬が高い」という学習が積み重なる場合があります。A survey of multilingual large language models（ScienceDirect, 2024）でも、アライメントデータの言語的偏りが多言語モデルの公平性に大きく影響すると指摘されています。

3つ目はトークナイザーの表現格差です。英語向けに設計されたBPEトークナイザーでは、英語は単語単位でトークンに切られるのに対し、日本語や韓国語は1文字ずつに細切れになるケースが多くあります。これはモデルの内部表現において、日本語や韓国語の「言語としてのまとまり」が英語より弱くなることを意味します。まとまりが弱い言語は、英語という強い引力に引き寄せられやすくなります。

この3つが重なることで、言語混乱は「バグ」ではなく「訓練の帰結」として生じます。特定の言語で書かれた回答を一貫して生成する能力は、意図的に作り込まなければ自然には身につかないのです。

Controlling Language Confusion in Multilingual LLMs（Lee et al., ACL 2025）は、この問題を軽減するためにORPO（Odds Ratio Preference Optimization）を用いた手法を提案しています。言語が混乱した出力に対してより高い損失ペナルティを与えることで、一貫した言語生成を学習させるアプローチです。

CodexとGLMはなぜ特にひどいのか：コード文脈の過学習

言語混乱はすべてのモデルで起きる問題ですが、特定のモデルで症状が重くなる理由があります。その代表がOpenAIのCodexとTsinghua大学が開発したGLM（General Language Model）系のモデルです。

CodexはGitHub Copilotの基盤となったモデルで、GPT-3をGitHubのコードリポジトリで追加学習させて作られました。ここに問題の種があります。GitHubに公開されているコードは、変数名・関数名・コメント・ドキュメント・コミットメッセージにいたるまで、英語が圧倒的に多数を占めています。Codexはこの「コードの世界では英語があらゆるコンテキストを占める」という環境を大量に学習した結果、「何かを考えるときは英語を使う」という強い傾向を内部に形成してしまいました。

結果として、日本語で「このコードを説明してください」と尋ねても、Codexはコードを解析する際に英語の内部表現を使い、そのまま英語で出力してしまいます。コーディングタスクという文脈が英語応答を強くトリガーするのです。コーディング能力と会話の言語を分離して学習させる設計になっていなかったことが、言語混乱を特に深刻にした根本原因と考えられます。

GLM系モデル（ChatGLMなど）の問題は少し異なります。ChatGLMは中国語と英語のバイリンガルモデルとして設計されており、この2言語では高い性能を発揮します。しかしその裏返しとして、日本語・韓国語・アラビア語などの第三言語が入力されると、モデルは中国語か英語のどちらで返すべきか迷い、両方が混ざった出力や、どちらか一方に引き寄せられた出力をしてしまいます。バイリンガルに特化したモデルが持つ、第三言語への弱さと言えます。

Programming Language Confusion: When Code LLMs Can’t Keep their Languages Straightの研究では、コード生成専門モデルであるStarCoderとCodeLlamaが10のLLMの中で最も高い言語混乱率を示したと報告されています。コード能力を特化して高めたモデルほど、自然言語の言語一貫性が犠牲になるというトレードオフが実際に観測されています。

CodexもGLMも、得意なことに深く最適化した結果、多言語対応という観点での設計が後回しになった、という点では同じ構図をたどっています。

Claudeはなぜ言語混乱が少ないのか：タスク言語と会話言語の分離

CodexやGLMが言語混乱に苦しむ中で、同じくコーディングが得意なClaudeが言語混乱を比較的起こしにくいのはなぜでしょうか。ここに、モデル設計の哲学の違いが見えてきます。

ACL 2026のクロスターン言語切り替え研究では、複数のモデルが「ユーザーが会話途中で言語を切り替えた場合」にどう反応するかを測定しています。GPT-5は98.6%の確率でユーザーの言語切り替えに追従します。一方、Claude Opus 4.5の追従率は7.7%と極端に低く、会話の最初に使われた言語を維持し続けます。同様の「文脈固定」傾向はCommand R+にも見られますが、タスク精度はClaudeが上回っています。

このClaudeの挙動は「context-anchoring（コンテキスト固定）」と呼ばれています。一見すると言語の追従が苦手なように見えますが、これは欠点ではなく、一貫性を優先する設計上の選択です。会話の文脈を保持して応答するという方針が、言語の安定にもつながっています。

背景にあるのはAnthropicのConstitutional AI（憲法的AI）という訓練アプローチです。Constitutional AIでは、モデルが従うべき原則のリスト（「憲法」）に基づいてAI自身がフィードバックを行います。この憲法の中に「ユーザーが使用している言語で応答する」という原則が含まれていると考えられており、それが英語優先のバイアスを意識的に打ち消す役割を果たしています。

重要なのは、Claudeが「タスクの言語」と「会話の言語」を切り離して扱っているという点です。Codexは「コードを書く＝英語の世界」というコンテキストに引っ張られて英語で返答してしまいます。しかしClaudeは、コードそのものは英語で書かれていても、コードについての説明をユーザーが日本語で求めているなら日本語で返す、という区別ができています。

これは偶然ではなく、訓練データの選定とアライメントプロセスにおいて「タスク遂行の言語」と「対話の言語」を明確に分離するよう設計されているからだと推測されます。コーディングが得意なモデルが必ずしも言語混乱を起こすわけではないという事実は、この問題が「コード学習量の問題」ではなく「設計の問題」であることを示しています。

言語混乱に対処するプロンプト技法と今後の研究動向

ここまで言語混乱の原因とモデルごとの差異を見てきました。最後に、ユーザーとして今日から実践できる対処法と、研究の方向性を紹介します。

手軽に試せる方法のひとつは、プロンプトに言語を明示的に指定することです。「以下の質問に日本語で回答してください」という一文をシステムプロンプトや質問の冒頭に加えるだけで、言語混乱の発生率を下げられることが複数の研究で確認されています。特にCodexやGLM系を使う場合、この一文が効果的です。Claudeのドキュメントでも「ターゲット言語を明示的に指定することで信頼性が向上する」と案内されています。

もうひとつはfew-shot prompting（数例提示）です。「日本語で質問→日本語で回答」という例を1〜2件、プロンプトの冒頭に含めることで、モデルが応答言語を判断しやすくなります。モデルを追加学習させるのではなく、入力の工夫だけで対処できる点が利点です。

より根本的な解決策として、研究では主に2つのアプローチが進んでいます。ひとつはORPO（Odds Ratio Preference Optimization）の活用です。言語が混乱した出力に対してより大きなペナルティを与えることで、一貫した言語生成を強化します。ACL 2025の研究では、ORPOによるファインチューニングが3つのアライメント手法の中で最も効果的だったと報告されています。

もうひとつは多言語の指示データを使ったSFT（Supervised Fine-Tuning）です。日本語・韓国語・アラビア語などの指示データを増やしてモデルを再学習させることで、低リソース言語での言語一貫性が向上します。From English-Centric to Effective Bilingual（Kiulian et al., ACL 2025）は、英語中心のLLMを対象言語とのバイリンガルモデルに効率よく改良する手法を提案しています。

言語混乱はLLMの多言語化が進む中で、今後ますます重要な評価基準になっていくでしょう。モデルを選ぶ際に「多言語対応」を謳っているかどうかだけでなく、「言語混乱への対処がどのように設計されているか」まで確認する視点が必要になってくるかもしれません。少なくとも、今使っているモデルで言語混乱が起きたとき、それが偶然のバグではなく設計の帰結だと知っていることは、より賢いモデルの使い方につながるはずです。