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

日本語と英語で出力の長さに差が出るかを示す、公式の言語別データはありません。差が出るとすれば、同じ内容を表すのに必要なトークン数が言語で変わる点を通してです。公式の多言語ページが示すのは正答率の相対値だけで、速度や出力の長さを言語別に比べた数値ではありません。日本語で応答が遅い、長いという体感は、言語そのものの処理能力の差とは分けて考えるほうが筋が通ります。遅さに効く要因は、モデルの大きさ、ハードウェア、ネットワーク、プロンプトと応答の複雑さ、そして生成するトークンの量です。

「遅い」は2つの時間に分かれる

体感の遅さは、最初の文字が出るまでの待ち時間と、全文が出終わるまでの時間に分かれます。Anthropicの用語集は、レイテンシ(latency)をプロンプトを送ってから出力を受け取るまでの遅延と定義しています。TTFT(Time to First Token)は、最初のトークンが生成されるまでの時間です。

公式のレイテンシ短縮ガイドは、モデルが処理して生成するトークンが少ないほど応答は速くなる、という立場です。ここで言語が関わるのは、同じ内容を表すのに必要なトークン数が言語で変わる点です。

公式の言語別データが示すのは「精度」で、速度ではない

公式の多言語ページには、英語を100%とした言語別の相対スコアがあります。MMLU(多分野の知識を問う試験)の英語版を、プロの翻訳者が14言語に訳したテストで、拡張思考(extended thinking)を使って測った値です。

日本語は中国語(簡体字)の96.9%、韓国語の96.7%と同じ帯にあります。Haiku 4.5のほうが英語との差が大きく、表全体でも96.4%から52.7%まで開きます。日本語はどちらのモデルでも、この幅の上寄りに位置します。英語との差が小さい言語群に入っているので、日本語だから精度が落ちる、という前提で設計する根拠にはなりません。

ただし、この表は正答率の相対値です。応答時間も出力の長さも載っていません。表に載っているのはSonnet 4.5とHaiku 4.5の2モデルで、後続のモデルの値は同じ形では示されていません。

モデル廃止表では、claude-sonnet-4-5-20250929 は2026年9月30日に非推奨(Deprecated)となり、退役は2026年11月30日です。代替には claude-sonnet-5-5 が挙がっています。claude-haiku-4-5-20251001 は現役で、退役は2026年10月15日より早くはならないとされています。日本語の精度そのものはClaudeの日本語精度を公式データとベンチマークで読むとClaudeの多言語性能を言語別データで見るに詳しくあります。

言語差が効くとしたら、通り道はトークン数

用語集によると、Claudeのトークンは英語の約3.5文字に相当しますが、正確な文字数は言語によって変わります。日本語の1文字あたりのトークン数は英語と同じ物差しでは測れないため、文字数からトークン数を見積もるときは言語差に注意が要ります。

トークン数はモデル世代でも変わります。Claude 4.7以降のモデルは新しいトークナイザーを使っていて、同じ入力テキストでも旧世代より約30%多くトークンが出ます。これは言語の差ではなく世代の差で、増え方は内容とワークロードの形で変わります。

トークンカウントのエンドポイントは、渡した model のトークナイザーで数えます。手元の日本語プロンプトでの増え方は、同じリクエストを現行モデルと移行先モデルで2回数えれば分かります。課金も新しい数え方に基づくので、4.7より前のモデルで測った値を、コストやコンテキストに収まるかの見積もりに流用しないのが公式の注意です。

この仕様は日本語だけの話ではなく、日本語・英語のどちらでもトークン数は文書ごとに変わるため、手元の文書で測るしかありません。測り方はClaudeの日本語トークン消費が英語より多い理由にまとめてあります。

入力側は送る前に数えられます。トークンカウントのエンドポイントは、システムプロンプトやツール定義を含む、メッセージ作成と同じ形の入力を受け付けます。数えた値は見積もりで、実際の入力トークン数と少しずれることがあります。数えた値にはシステム最適化のためにAnthropicが自動で加えるトークンが含まれることがありますが、その分は課金されません。サーバーツールやMCPコネクタ、url や file を指定した画像・文書は数えられず、invalid_request_error になります。手順はcount_tokensで送信前にトークン数を数える方法にあります。

出力側は事前に数えられません。応答を実際に返させて、レスポンスの usage.output_tokens で確かめます。日本語と英語で同じ依頼を数回ずつ流し、この値を比べれば、自分の用途での出力の差が数字で分かります。

出力を短くする指定は「文字数」より「文の数」

出力の長さを抑える手段として、ありがちな助言は文字数の上限を書くことです。レイテンシ短縮ガイドは逆の見方を示しています。LLMは単語ではなくトークンで数えるため、正確な単語数や語数の上限を求めるより、段落数や文数の上限を求めるほうが効果的だという説明です。

日本語は単語の切れ目が見えにくいので、文字数で縛るより文の数や箇条書きの項目数で縛るほうが、この説明に沿います。

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-haiku-4-5",
    "max_tokens": 300,
    "messages": [{"role": "user", "content": "冪等性を3文で説明してください"}]
  }'

この例は、文の数で長さを縛り、max_tokens を安全弁に置いた形です。応答の stop_reason が max_tokens なら上限で切れた応答、end_turn なら自然に終わった応答です。

速度が最優先の場面では、モデル選びも効きます。レイテンシ短縮ガイドでは、速度重視の用途に最速のClaude Haiku 4.5が挙がっています。温度(temperature)を下げると、出力が絞られて短くなることがあるとも書かれています。

プロンプトの書き方では、冗長さを言語のせいにせず、依頼の曖昧さを先に疑います。「簡潔に」だけでは長さの基準が読み手ごとに違うため、「3文で」「各項目は1文で」のように、数えられる単位で指定します。ただし短くする工夫は、まず制約なしで目的の品質が出るプロンプトを作ってから足す順番が前提です。レイテンシ短縮ガイドも、早い段階で速度を詰めると本来の性能が見えなくなる、と注意しています。品質の基準を先に決め、そのあとで長さと速度を調整します。日本語と英語のどちらで書くかは、この順番のあとで比べても遅くありません。

応答言語は明示して指定する

公式の多言語ページは、Claudeが会話から応答言語を推測するものの、本番用途では対象言語を明示するよう勧めています。置き場所として最も確実なのはシステムプロンプトで、会話の全ターンにわたって指示が安定します。設定の書き方はClaudeの応答言語をシステムプロンプトで固定する方法で扱っています。

流暢さを上げる方法として、同ページはネイティブスピーカーのような自然な言い回し(idiomatic speech)で書くよう頼む案も挙げています。このほかに、文字はローマ字化せずネイティブの文字で送ること、翻訳を超えた文化的な文脈に配慮することも、同ページが挙げるベストプラクティスです。

拡張思考を使うと、見えない出力が時間を食う

画面に出る文章が短くても、応答が遅いことがあります。拡張思考(extended thinking)を有効にすると、内部の推論に使ったトークンも出力として課金され、max_tokens の枠に含まれます。内訳はレスポンスの usage.output_tokens_details.thinking_tokens で確認できます。ストリーミング中は、最後の message_delta イベントにだけこの内訳が出ます。

思考の予算(budget_tokens)は目標値で、厳密な上限ではありません。実際の使用量はタスクで変わり、予算を使い切る前に推論を終えることもあります。厳密な天井になるのは max_tokens です。budget_tokens は max_tokens 未満でなければならず、最終的な回答の分の余白を残す必要があります。

なお、budget_tokens を指定する拡張思考は、Claude 4.7以降のモデルでは400エラーで拒否されます。モデル一覧でも、Claude Opus 4.6とClaude Sonnet 4.6では非推奨、それ以降のモデルでは受け付けないとされています。現行のClaude Sonnet 5.5などではadaptive thinkingを使い、思考の深さはeffortで調整します。思考分もレスポンスの output_tokens に含まれます。

日本語と英語で体感が違うと感じたとき、見えている文章の長さだけを比べると、思考側の差を見落とします。言語別スコアの表が拡張思考つきで測られている点も、同じ文脈で押さえておきたい条件です。

max_tokens で切れた応答は、続きを書かせて継ぎ足せます。ストップ理由の解説には、stop_reason が max_tokens のあいだは、そこまでの応答をアシスタントのメッセージとして渡し、続きを頼む手順が載っています。上限を低く置く場合は、この継ぎ足しを組み込むかどうかも決めておきます。

計測のしかた — 言語差か長さ差かを自分で切り分ける

日本語と英語の差が、言語から来るのか出力の長さから来るのかは、次の3つを分けて記録すると見分けられます。

• 最初の文字が出るまでの時間(ストリーミングで、リクエスト送信から最初のテキストが届くまでを測る)
• 全文が出終わるまでの時間
• usage.output_tokens、拡張思考を使う場合は thinking_tokens、応答の文字数

全文の時間が長いのに出力トークンも多いなら、長さが原因です。出力トークンが同程度で時間だけ違うなら、ネットワークやハードウェアなど、言語以外の要因が混ざっています。用語集もネットワーク状況やハードウェアをレイテンシの要因に挙げています。

最初の文字が出るまでの時間が長いときは、入力の長さを先に疑います。この場合は、プロンプトキャッシュで再送コストを抑える手もあります。仕組みはAnthropic APIのPrompt Cachingを理解するにまとまっています。

全体の速さが日本語で足りないときは、言語を英語に切り替える前に、モデルの格を下げる選択肢もあります。速度重視のHaiku 4.5を選ぶなら、先の表にある日本語の相対スコアが許容できるかを、自分のタスクの評価データで確かめます。

まとめ

日本語が遅く感じたら、言語の処理能力を疑う前に、usage.output_tokens と思考トークンで出力の量を見ます。出力が同程度なら言語以外の要因、多ければ依頼文の長さ指定の見直し、という順で切り分けられます。