Claudeの多言語性能を言語別データで見る — 低リソース言語ほど落ちる精度差

Claudeの多言語性能はどれくらいなのか

Claudeは英語を基準にした場合、フランス語やドイツ語のような主要言語ではほぼ差がなく、スワヒリ語(Swahili)やヨルバ語(Yoruba)のような低リソース言語では明確に精度が落ちます。公式ベンチマークは英語のスコアを100%とした相対値で14言語を測定しており、上位の欧州言語は97〜98%台に収まる一方、ヨルバ語は79.7%(Sonnet 4.5)まで下がります。

数値は英語版MMLU(Massive Multitask Language Understanding)のテストセットを、専門の人間翻訳者が14言語に翻訳したものをもとにしています。機械翻訳ではなく人手翻訳を使っているのは、デジタル資源の少ない言語ほど翻訳品質のブレが結果を左右しやすいためです。評価はゼロショットのchain-of-thought形式で、モデルに例示を与えずに推論させています。

なぜ低リソース言語ほど精度が落ちるのか

学習データに含まれるテキスト量は言語ごとに大きく偏っています。英語やスペイン語のようにウェブ上のテキスト量が多い言語は、語彙・文法・文脈のパターンをモデルが繰り返し学習できます。一方でスワヒリ語やヨルバ語はデジタル化されたテキストの絶対量が少なく、専門用語や複雑な構文に触れる機会自体が限られます。

もう一つの要因は言語間の知識転移です。Claudeは英語で獲得した推論能力を他言語にある程度転移させますが、転移の効率は言語系統や語順の近さに影響されます。ラテン系のスペイン語・ポルトガル語・イタリア語・フランス語が軒並み97%台に固まっているのは、英語との構造的な距離が近く転移がうまく働くためだと読めます。日本語・韓国語・中国語のような語順の異なる言語は96〜97%台とわずかに下がり、スワヒリ語・ヨルバ語のように学習データも構造も遠い言語でさらに差が開きます。

トークナイザーの効率も見逃せない要素です。英語やラテン系言語は1トークンで表現できる情報量が多く、同じ長さの文章でも消費トークンが少なく済みます。一方でアラビア文字やアフリカ諸語の一部は、同じ意味内容を表すのにより多くのトークンを要する傾向が知られています。トークン数が増えるほどモデルが1回の推論で扱う情報の粒度は細かくなり、長い文脈をまたぐ推論では不利に働きやすくなります。この傾向は公式ベンチマークの数値だけから直接は読み取れませんが、低リソース言語のスコアが軒並み低い背景として一般に指摘される要因です。

SonnetとHaikuで言語別に何が変わるか

表の数値をそのまま並べるだけでは、どの言語でモデルの選び方が重要になるかが見えません。各言語でSonnet 4.5とHaiku 4.5のスコア差(ギャップ)を計算すると、リソースの少ない言語ほどモデル間の差が急激に開く構造が見えます。

スペイン語ではSonnet 4.5とHaiku 4.5の差はわずか1.8ポイントで、コスト最適化のためにHaikuへ切り替えても精度低下はほとんど気にならない水準です。ところがヨルバ語では79.7%対52.7%と27ポイントもの差が開きます。低リソース言語を扱うアプリほど、モデル選択がユーザー体験を左右する比重が大きくなるということです。

コストを優先してHaikuへ寄せる判断は、主要言語向けのアプリでは合理的です。ただし対象言語にスワヒリ語やヨルバ語のような低リソース言語が含まれる場合、Haikuへの切り替えは翻訳や要約の質を大きく落とすリスクを伴います。この場合はSonnetクラスを維持するか、該当言語だけ個別に評価してから判断する選択肢があります。

多言語対応のアプリが複数の言語をまとめて1つのモデルで処理する構成を取っている場合、この非対称性は設計上の盲点になりやすい部分です。ユーザーの大半が英語やスペイン語を使っていて、少数のユーザーがスワヒリ語を使っているようなアプリでは、全体の満足度指標を見ているだけではスワヒリ語ユーザー向けの体験劣化に気づきにくくなります。言語別にモデルを出し分ける構成、あるいは低リソース言語のリクエストだけSonnetクラスへルーティングする構成は、コストと品質のバランスを取る現実的な選択肢の1つです。

多言語アプリでどう設計に落とし込むか

公式ドキュメントは実装上のポイントを3つ挙げています。1つ目は入力・出力言語を明示することです。Claudeは会話から言語を推測できますが、本番アプリでは推測に頼らず明示的に指定したほうが安定します。2つ目はネイティブスクリプトを使うことです。ローマ字転写ではなく、対象言語本来の文字体系でテキストを渡したほうが精度が上がります。3つ目は文化的な文脈への配慮です。翻訳だけでは伝わらないニュアンスがあるため、対象読者の文化圏を意識したプロンプト設計が必要になります。

ベンチマーク表に載っている14言語は代表例にすぎません。公式ドキュメントも「ベンチマークにない言語でも、自社のユースケースに関連する言語では実際にテストしてほしい」と明記しています。次のようなプロンプトで、自社が扱う言語ごとに簡易評価を回してから本番投入するのが手堅いやり方です。

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": "常にヨルバ語で応答してください。ネイティブスクリプトを使ってください。",
    "messages": [{"role": "user", "content": "顧客からの返品依頼にどう対応すべきか教えてください"}]
  }'

対象言語で実際に応答を取得し、翻訳者やネイティブスピーカーにレビューしてもらう工程を挟めば、ベンチマーク表だけでは分からない語彙選択や敬語の適切さまで確認できます。

自社アプリの言語別評価をどう設計するか

公式ベンチマークの14言語は、自社が実際に扱う言語と一致するとは限りません。カスタマーサポートボットが対応する言語や、社内文書の要約対象言語は、ベンチマークにない組み合わせであることのほうが多いはずです。次の4点を押さえると、ベンチマーク表を鵜呑みにせず自社ユースケースに即した判断ができます。

1言語あたりのサンプル数を最低でも数十件は用意することが目安になります。数件のテストだけで「この言語は問題ない」と判断すると、たまたま簡単な入力しか試していないだけという可能性が残ります。次に、日常会話の平易な文だけでなく、専門用語や固有名詞を含む入力も混ぜることが重要です。ベンチマークのMMLUは学術的な多肢選択問題が中心のため、口語表現やスラングへの強さまでは測っていません。さらに、対象言語が敬語や文体の使い分けを持つ言語であれば、フォーマル・カジュアルの両方でテストする価値があります。最後に、自動採点だけに頼らず、可能であればネイティブスピーカーによる人手レビューを一部のサンプルに組み込むと、数値には出ない不自然さを拾えます。

日本語の相対スコアはどこに位置するか

日本語はSonnet 4.5で96.8%、Haiku 4.5で93.5%です。中国語・韓国語とほぼ同じ帯に位置し、欧州の主要言語との差はSonnet 4.5で0.2〜1.4ポイント、Haiku 4.5で0.8〜2.9ポイントにとどまり、スワヒリ語・ヨルバ語のような大きな落ち込みとは一線を画します。日本語ユーザー向けのアプリであれば、モデル選択によって多言語性能が大きく揺らぐ心配は少ないと言えます。

ただし日本語は敬語や文体の使い分けが翻訳・要約の品質に直結する言語です。ベンチマークのスコアが高くても、ビジネス文書向けの丁寧語と日常会話のくだけた表現を混同するようなケースはスコアに表れません。数値上のギャップが小さい言語であっても、実運用ではプロンプトで文体を明示する設計が引き続き必要です。

日本語話者向けのアプリを開発する立場では、このベンチマークは「モデル選択で多言語性能を心配する必要はほぼない」という安心材料として読める一方、「敬語や文体はスコアに現れない領域」という別の課題を意識させる材料でもあります。両者は別の問題であり、片方が解決してももう片方が自動的に解決するわけではありません。

まとめ

Claudeの多言語性能は言語によって一様ではなく、学習データの厚みと言語間の構造的な近さで差が生まれます。欧州の主要言語はSonnetとHaikuの差がほぼ無視できる一方、スワヒリ語・ヨルバ語のような低リソース言語ではモデル選択がそのまま出力品質を左右します。対象言語が主要言語に偏るアプリはコストを優先してHaikuを選んでも実害が小さく、低リソース言語を扱うアプリはSonnetクラスを軸に据えたうえで自社ユースケースでの実測を挟む判断が妥当です。

ベンチマーク表の数値は出発点であって、そこで判断を完結させないことが重要です。対象言語がベンチマークの14言語に含まれない場合、あるいは含まれていても自社のドメイン特有の語彙や文体を扱う場合は、公式ドキュメントが推奨するとおり実際のユースケースでテストを回してから本番投入するのが手堅い進め方です。応答言語を安定させる実装方法はClaudeの応答言語をシステムプロンプトで固定する方法にまとめています。モデル階層そのものの違いはClaudeモデル一覧、API全体の構成はAnthropic API完全ガイドで確認できます。