Claudeは日本語と英語プロンプトで出力の長さに差が出るか

同じ内容のタスクを日本語と英語で5パターン用意し、Claudeに実行させて編集部が比較しました。5パターンすべてで正答は日本語・英語とも一致しましたが、出力の文字数は日本語のほうが長くなる傾向が出ています。体感速度の差として語られがちな現象の正体は、言語そのものの処理能力差ではなく、出力トークン数の違いにある可能性が高いという結論です。

「日本語は遅い」という体感の正体を分解する

Claudeの応答速度に関する体感は、実測したwall-clock時間そのものではなく、出力の長さから来ていることが多い、というのがこの検証の見立てです。Anthropicの用語集は、レイテンシ(latency)を「プロンプト送信から出力を受け取るまでの遅延」、TTFT(Time to First Token)を「最初のトークンが生成されるまでの時間」と定義しています。どちらも影響要因としてモデルサイズ・ハードウェア・ネットワーク状況・プロンプトの複雑さを挙げていますが、プロンプトの言語そのものは要因として明記されていません。

一方で、自己回帰(autoregressive)方式の言語モデルは、出力を1トークンずつ順番に生成する仕組みです。出力トークン数が多いほど生成ステップが増え、他の条件が同じなら生成完了までの時間は長くなります。この性質はClaudeに限らず主要な大規模言語モデル全般に共通する技術的な特性です。つまり「日本語のほうが遅く感じる」という体感があるとすれば、その有力な説明候補は言語処理そのものの違いではなく、日本語のほうが同じ内容を伝えるのに必要なトークン数が多くなりやすいという、Claudeの日本語トークン消費が英語より多い理由で扱われている現象です。

検証方法 — 同一タスクを5パターン、日英で実行

要約・分類・コード生成・概念説明・キャッチコピー作成の5タスクを用意し、それぞれ日本語版と英語版のプロンプトで内容が完全に一致するよう作成しました。Claudeに両方を実行させ、①正答かどうか②出力の文字数③文体・冗長さの3点を編集部が比較しています。

タスクは意図的に、日常業務で使われそうな粒度に揃えました。学術的なベンチマークではなく、実務でよくある依頼に近い形にしています。プロンプトは編集部が日本語で作成したのち、意味が変わらないよう注意しながら英語に書き起こす方式を取りました。逆(英語が先)ではなく日本語を先に用意したのは、日本語ユーザーが実際にプロンプトを書く順序に近づけるためです。

比較の粒度は、①内容が事実として正しいか(分類・コード生成では機械的に検証可能)②説明・創作タスクでは編集部が読んで妥当と判断できるか、の2種類に分けています。定量的な採点基準を設けず、あくまで「実務で使い物になる出力かどうか」という定性的な判断に留めている点は、この検証の限界として明記しておきます。

5タスクの結果 — 正答率は同じ、出力の長さは日本語が長い

5タスクすべてで、日本語版・英語版とも正答でした。精度面での差は今回確認できませんでした。一方、出力の文字数(英語は単語数を目安に換算)は、5タスク中4タスクで日本語のほうが長くなりました。

分類タスクのように出力そのものが短い場合は言語による差がほぼ消え、説明や創作のように出力の自由度が高いタスクほど、日本語のほうが説明を補足したり候補を複数出したりする傾向が出ました。これは丁寧さや読みやすさを優先する日本語の文章慣習が反映された結果だと考えられますが、1回の実行による観察であり、毎回同じ傾向になるとは限りません。

なぜ概念説明で日本語のほうが長くなったか

「冪等性を3文で説明してください」という同一の指示に対し、英語版は定義・具体例・補足という3文構成を厳密に守りました。日本語版も3文構成自体は守りましたが、1文あたりの情報量がやや多く、結果として文字数は英語版より多くなっています。文の数という制約は両言語で守られた一方、文の長さという制約は明示していなかったため、この差が出た形です。

この結果は、プロンプトで「〜文で」と文の数を指定しても、文字数や情報量までは制御できないことを示しています。出力の長さを厳密にそろえたい場合は、文の数ではなく文字数の上限を明示するほうが確実です。

コード生成タスクは言語差がほぼ出ない

配列の重複除去関数を書かせるタスクでは、生成されたコード本体は日本語プロンプト・英語プロンプトでほぼ同一でした。差が出たのはコードに添えた説明文の部分だけです。プログラミング言語の構文自体は自然言語のプロンプト言語に依存しないため、コード生成タスクは日英差がもっとも小さいタスク種別だと言えそうです。

これは実務上、重要な示唆です。コーディング支援用途でClaudeを使う場合、プロンプトを日本語で書くか英語で書くかによる速度・精度への影響は、他のタスク種別より小さいと考えてよさそうです。変数名やコメントを日本語にするか英語にするかは好みの問題であり、生成されるロジックそのものの正しさには今回の検証の範囲では影響していません。

一方で、コメントを日本語で書かせた場合、コメント文自体の文字数は英語コメントより長くなる傾向がありました。「重複を除去する」という英語コメント(// remove duplicates)に対応する日本語コメントは、丁寧な言い回しにすると「配列内の重複した要素を除去します」のように文字数が増えがちです。コードの可読性を優先するなら簡潔な体言止め(「重複除去」)を使う、という選択肢もあります。

そもそも日本語の処理性能そのものに差はあるのか

ここまでの検証は自前の5タスクによる観察ですが、公式ドキュメントも近い見方を示しています。Anthropicのマルチリンガル対応に関するドキュメントは、Claudeが標準的なUnicode文字を使う世界の大半の言語で入力の処理と出力の生成に対応しているとしたうえで、言語によって性能には差があるものの、広く使われている言語では特に高い能力を維持するとしています。日本語は英語と並んで利用者数の多い言語のひとつであり、今回の検証で5タスクとも正答率に差が出なかった背景には、この「広く使われている言語ほど高い性能を維持する」という公式の位置づけが関係していそうです。

同ドキュメントはまた、Claudeが会話の文脈から応答言語を自動的に推測できるとしつつも、実務での用途では入力・出力の言語を明示的に指定したほうが安定した挙動が得られるとし、ネイティブスピーカーが話すような自然な言い回し(idiomatic speech)を使うようプロンプトで指示する方法も紹介しています。出力が冗長になりがちな日本語のケースでは、この「自然な言い回しで」という指示を加えることで、丁寧語の重複や説明の水増しが抑えられる余地があります。ただし、この効果自体は今回の5タスク検証では確認しておらず、公式ガイドが示す一般的な推奨事項という位置づけにとどまります。

出力の長さを制御するプロンプト設計

体感速度を左右する要因が出力トークン数だとすれば、対処法は言語を変えることではなく出力の長さそのものを制御することです。もっとも確実なのは、文字数や項目数を数値で明示する指定です。「3文で」より「150字以内で」、「簡潔に」より「箇条書き3項目、各20字以内で」のように、曖昧な形容詞を数値の制約に置き換えると、日英を問わず出力長のブレが小さくなります。

API側で機械的に長さを打ち切りたい場合は、max_tokensパラメーターで出力の上限そのものを制御する方法もあります。ただしmax_tokensは「そこで強制的に打ち切る」設定であり、文の途中で切れる可能性がある点には注意が必要です。

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": 200,
    "messages": [{"role": "user", "content": "冪等性について150字以内で説明してください"}]
  }'

プロンプトでの数値指定とmax_tokensは役割が異なります。前者は「自然に短くまとめさせる」指定、後者は「そこで機械的に打ち切る」指定です。応答の質を保ったまま短くしたい場合はプロンプト側の数値指定を優先し、max_tokensは事故防止の安全弁として設定するのが実務的な使い分けです。

実務でどう受け止めればよいか

今回の検証で確認できたのは、①正答率は日英で同等だったこと②説明・創作系のタスクでは日本語出力がやや長くなる傾向があったこと、の2点です。応答速度そのものを気にする場面では、プロンプトの言語を変えるより、出力の長さを明示的に制限する(文字数上限を指定する、箇条書きの項目数を指定する)ほうが効果が見込めます。

正確な日本語の精度そのもの(公式ベンチマークでの相対スコアや他社モデルとの比較)はClaudeの日本語精度を公式データとベンチマークで読むで扱っています。本記事はその補足として、同一タスクでの日英比較という切り口に絞りました。Claudeの応答言語を安定させたい場合は、Claudeの応答言語をシステムプロンプトで固定する方法も参考になります。

まとめ

同一タスク5パターンを日本語・英語で実行した結果、正答率に差は出ませんでした。出力の長さは説明・創作系のタスクで日本語がやや長くなる傾向があり、これが体感速度の差につながっている可能性があります。実際のwall-clock時間は計測しておらず、正確な数値が必要な場合は自分のワークロードでの実測が必要です。応答速度を制御したい場合は、プロンプト言語よりも出力の長さそのものを明示的に指定するほうが実務的な対処になります。