Claude Sonnet 5でmax_tokensが途中で切れる問題の対処法
Sonnet 4.6用のmax_tokensをそのまま流用すると、Sonnet 5では出力が途中で切れます。原因と、effortとmax_tokensの調整方法をまとめます。
Claude Sonnet 4.6からmax_tokensを持ち越すと出力が切れる
Claude Sonnet 4.6で動いていたコードをそのままClaude Sonnet 5に向けると、レスポンスが完成する前に止まることがあります。stop_reasonが"max_tokens"になり、本文の途中で文章が切れているのが典型症状です。原因はコードの不具合ではなく、max_tokensの値がSonnet 5の挙動に対して小さすぎることにあります。
公式ドキュメントは、Sonnet 5でhigh・xhigh・maxのいずれかのeffortを使う場合、max_tokensに思考とツール呼び出し分の余白を残すよう明記しています。長いタスクではアダプティブシンキング(モデルが自分で考える深さを決める仕組み)が予算の大部分を使い切り、予算が窮屈だと出力のほとんどが思考で埋まり、最後に答えが尻切れで終わってstop_reason: "max_tokens"になります。max_tokensを引き上げるか、effortをmediumへ下げれば解消します。
この症状が起きやすいのは、Sonnet 4.6時代に思考なしで運用していたワークフローです。Sonnet 5はアダプティブシンキングが既定でオンになるため、同じリクエストでもSonnet 4.6では発生しなかった思考トークンの消費が新たに乗ります。max_tokensは思考と応答本文の合計にかかる厳格な上限で、Anthropicは移行時にこの値を見直すよう繰り返し注意喚起しています。
Sonnet 4.6とSonnet 5でmax_tokensの前提が変わった3点
max_tokensが足りなくなる背景は1つではなく、3つの変更が重なって効いています。
| 変更点 | Sonnet 4.6 | Sonnet 5 |
|---|---|---|
| アダプティブシンキング | Sonnet 4.6明示的にオンにしない限り無効 | Sonnet 5既定でオン(thinking未指定でも思考する) |
| 手動のthinking設定 | Sonnet 4.6budget_tokensで予算を指定できた | Sonnet 5廃止・400エラー(effortで代替) |
| トークナイザー | Sonnet 4.6旧トークナイザー | Sonnet 5新トークナイザー(同じ文章で約30%多いトークン数) |
1つ目は、思考なしを前提にサイジングしたmax_tokensが、思考トークン分だけ目減りする点です。2つ目は、thinking: {type: "enabled", budget_tokens: N}を指定していたコードがそのまま400エラーになる点です。Sonnet 5では手動のthinking設定自体が廃止されているため、この呼び出し方を続けているアプリケーションはエラーで気づきます。3つ目が本記事の主題であるmax_tokensの目減りに直接効きます。新トークナイザーは入力だけでなく出力トークンの数え方にも及び、モデルが同じ内容を書いても、Sonnet 5では消費するトークン数がSonnet 4.6より多くなります。新トークナイザー自体の仕組みと入力側への影響はClaudeの新トークナイザーでトークン数が30%増える仕組みと対処にまとめているので、count_tokensでの入力見積もりのずれを扱いたい場合はそちらを参照してください。
3つの変更のうち、思考トークンの消費と新トークナイザーの増分は方向が同じで、重なると効果が積み上がります。同じ思考の分量でも、新トークナイザーのぶん多くトークンを消費し、その消費がSonnet 4.6時代に決めたmax_tokensの枠を先に食いつぶします。結果として、応答本文に残る枠が想定より早く尽きます。
high・xhighのeffortほど余白を大きく残す理由
effortパラメーターは、モデルの知性とトークン消費のバランスを調整する仕組みで、Sonnet 5では既定値がhighです。Sonnet 4.6と同じ既定値ですが、Sonnet 5はeffortの指示を厳格に守るため、lowやmediumでは求められた範囲だけに作業を絞り、highやxhighでは複雑なタスクに応じて思考量が伸びます。
| effort | 想定用途 | max_tokensへの影響 |
|---|---|---|
max | 想定用途トークン消費の制約なしで最大性能を出したいとき | max_tokensへの影響思考量が最も伸びやすく、余白を大きく取る必要がある |
xhigh | 想定用途難しいコーディング・エージェントタスク | max_tokensへの影響公式が最初に推奨する高難度用の設定。思考が長引きやすい |
high(既定) | 想定用途大半のユースケース | max_tokensへの影響標準的な余白で足りることが多いが、長いタスクでは油断できない |
medium | 想定用途コスト重視で知性を多少落としても構わないとき | max_tokensへの影響思考が浅くなる分、max_tokens不足のリスクは下がる |
low | 想定用途レイテンシ重視の短いタスク | max_tokensへの影響思考をほぼ使わないため、max_tokens不足はまず起きない |
xhighやmaxを使う場面は、コード生成やエージェント的なツール呼び出しを伴う長いタスクが中心です。長いタスクほど思考が予算を多く使うため、まさにmax_tokensが尽きやすい条件と重なります。逆にlowやmediumで運用しているワークフローでは、この症状はそもそも起きにくいので、max_tokens不足に遭遇したらまずeffortの設定を確認するのが早道です。
Sonnet 5とSonnet 4.6でeffortの強さの目安を揃えるなら、Sonnet 5のmediumがSonnet 4.6のhigh相当、Sonnet 5のhighがSonnet 4.6のmax相当という大まかな対応が示されています。ベンチマークで比較する際は、effortの名前ではなく実際に観測される思考の長さで揃えるのが公式の推奨です。effortの基本的な使い分けはClaude effortとは、Claude Code上での切り替え方はClaude Code effortレベルの使い方と設定で扱っています。
max_tokens不足の見分け方と直し方
症状の切り分けはstop_reasonを見るところから始まります。レスポンスのstop_reasonが"max_tokens"で、かつテキストブロックが不自然な位置で終わっている、あるいは思考ブロックだけが長く続いて本文がほとんど無い場合、max_tokens不足がほぼ確定です。
# usageとstop_reasonだけを抜き出して確認する
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"max_tokens": 16000,
"thinking": {"type": "adaptive"},
"messages": [{"role":"user","content":"'"$PROMPT"'"}]
}' | jq '{stop_reason, usage}'直し方は2つあり、どちらか単独でも組み合わせでも構いません。effortを下げる場合は、リクエストのoutput_configにeffortを指定します。
# xhigh運用でmax_tokens不足が出たときにeffortをmediumへ落として比較する
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"max_tokens": 16000,
"output_config": {"effort": "medium"},
"messages": [{"role":"user","content":"'"$PROMPT"'"}]
}' | jq '{stop_reason, usage}'max_tokensを引き上げる: Sonnet 5の出力上限は128kトークンで、Sonnet 4.6と変わっていません。Sonnet 4.6でぎりぎりに詰めていた値は、その枠内で余裕を持って引き上げられます- effortを下げる:
xhighやmaxで運用していて思考が長引いている場合、mediumへ落とすと思考の消費量が減り、同じmax_tokensでも収まりやすくなります
思考トークンはusage.output_tokensに含まれて課金対象になり、max_tokensの枠も消費します。これは表示上「非表示のthinking」であっても変わらないため、display設定をomittedにしていてもmax_tokensの消費量自体は減りません。予算を減らしたいなら、表示設定ではなくeffortを調整します。
なお、応答内で「これまでに分かったこと」や「次に何をするか」を短く述べる進捗更新ブロックは、Claude Fable 5.1・Claude Mythos 5.1・Claude Fable 5に限った機能です。Sonnet 5では返ってこないため、Sonnet 5の出力を前提にインターフェースを設計する場合はこの挙動をあてにする必要はありません。
移行時にmax_tokensだけ見直せば済むとは限らない
max_tokensの見直しは、Sonnet 5への移行チェックリストの1項目に過ぎません。アダプティブシンキングが既定でオンになったことで、Sonnet 4.6時代に思考なしで運用していたワークフロー全体を見直す必要があります。手動のthinking設定(budget_tokens指定)を使っていたコードは400エラーになるため、effortパラメーターへの置き換えが避けられません。サンプリングパラメーター(temperature・top_p・top_k)を既定値以外に設定しているコードも同様に400エラーになります。
サンプリングパラメーターの400エラーはmax_tokens不足とは別の症状ですが、同じ移行作業の中で同時に見つかることが多いエラーです。temperature・top_p・top_kを既定値以外に固定していたコードは、Sonnet 5では呼び出し自体が拒否されます。アダプティブシンキングの挙動を細かく制御したい場合、こうしたサンプリングパラメーターではなくeffortとプロンプト側のガイダンスで調整する形に置き換える必要があります。
料金面では、Sonnet 5は100万トークンあたり入力$2・出力$10で、Sonnet 4.6の入力$3・出力$15より単価そのものは下がっています。ただし単価が下がったからといって、1リクエストあたりの実コストが単純に下がるとは限りません。新トークナイザーで消費トークン数自体が増えるため、単価の低下分がトークン数の増分で相殺され、結果として実質コストがほぼ変わらないケースも起こり得ます。max_tokensの余白を広げる調整は、この意味でもコスト試算とセットで確認しておく価値があります。
新トークナイザーの影響はmax_tokensだけにとどまりません。同じ入力でもトークン消費が増えるため、コスト試算やコンテキストウィンドウの残量計算も同時にずれます。Anthropic API全体のモデル選択や料金体系はAnthropic API完全ガイドにまとめているので、Sonnet 5への移行を単発のmax_tokens調整で終わらせず、周辺の見積もりも合わせて確認するのが安全です。
トークン数の増分は入力内容によって変わるため、公式が示す約30%という数字を目安に据えつつ、実際に自分のワークロードでmax_tokensを使い切っていないかをusageレスポンスで確認する運用が確実です。1回のリクエストだけで判断せず、コード生成が多いプロンプトと自然文中心のプロンプトの両方でstop_reasonを見ておくと、どのワークロードで余白が足りなくなりやすいかが見えてきます。
まとめ
Claude Sonnet 5でmax_tokensが途中で切れる主な原因は、アダプティブシンキングが既定でオンになったこと、手動のthinking予算指定が廃止されてeffortに一本化されたこと、新トークナイザーが出力トークンの消費も押し上げることの3つが重なるためです。high・xhigh・maxのeffortで長いタスクを回すときほど思考がmax_tokensの枠を大きく使うため、Sonnet 4.6時代の値をそのまま持ち越さず、128kトークンの上限内で余白を引き上げるか、effortをmedium側へ落として調整します。stop_reasonが"max_tokens"かどうかをまず確認し、症状が出たワークロードから優先的に見直すのが実務的な進め方です。