effortを変えてもthinkingの深さが変わらないときの原因切り分け
effortはadaptive modeでの主レバーで、extended-thinking専用モデルではbudget_tokensが深さを決める。Opus 4.5だけeffortとbudgetが併用できる例外を含めて切り分ける。
effortを上げても思考が深くならない理由
effort を high や xhigh に上げたのに、thinkingブロックの長さも呼び出し頻度も変わらない。これはバグではなく、モデルがどちらのthinkingモードで動いているかで起きる正常な分岐です。effortが思考の深さを左右する主レバーになるのはadaptive modeのときだけで、extended thinkingしか持たないモデルでは深さを決めるのは budget_tokens です。
原因切り分けの手順は単純です。まず対象モデルが adaptive と extended のどちらのthinkingをサポートしているかを確認し、次にどちらのパラメータで深さを制御するモデルなのかを判断します。
adaptive modeとextended thinkingでレバーが違う
Claudeのthinking機構には2つの世代があります。
- adaptive mode(
thinking: {type: "adaptive"}): Claude Fable 5.1 / Mythos 5.1 / Fable 5 / Mythos 5 / Opus 5 / Opus 4.8 / Opus 4.7 / Sonnet 5など新しい世代の既定モード。thinkingを行うかどうか、どこまで深く考えるかをモデル自身が判断し、effortはその判断の強さを調整する主レバーとして働きます - extended thinking(
thinking: {type: "enabled", budget_tokens: N}): Opus 4.5 / Haiku 4.5 / Sonnet 4.5などが対応する旧世代の手動モード。深さはbudget_tokensで明示的に指定したトークン数の上限そのものが決めます
つまり effort を変えても反応しないモデルの多くは、そもそもextended thinkingでしか動いておらず、深さの制御パラメータが違うのです。
| モデル世代の分類 | 深さを決めるパラメータ | effortの扱い |
|---|---|---|
| adaptive onlyのモデル(Fable/Mythos系、Opus 5、Sonnet 5等) | 深さを決めるパラメータeffort | effortの扱い主レバー |
| extended onlyのモデル(Sonnet 4.5、Haiku 4.5) | 深さを決めるパラメータbudget_tokens | effortの扱い効かない(パラメータとして存在しない) |
| 両対応のモデル(Opus 4.6、Sonnet 4.6、Mythos Preview) | 深さを決めるパラメータ使うモードによる | effortの扱いadaptiveを選べばeffortが効く |
| Opus 4.5(例外) | 深さを決めるパラメータbudget_tokens + effort | effortの扱い併用可能(下記) |
Opus 4.5だけの例外 — effortとbudgetの併用
extended thinkingしか使えないモデルの大半は effort パラメータ自体を受け付けません。ところが唯一の例外として、Claude Opus 4.5はextended-thinking専用モデルでありながらeffortにも対応しており、両方を同時に設定できます。公式ドキュメントは役割を明確に分けており、thinkingの深さそのものを決めるのは引き続きbudget_tokensで、effortは応答全体の作り込み方(思考以外の出力の作り込み)を左右すると説明しています。深さを変えたいならbudget_tokensを、応答の作り込み度合いを変えたいならeffortを、という使い分けです。
Opus 4.5で「effortを上げたのに思考が深くならない」と感じる場合は、そもそもeffortが担っている役割が深さではないことが原因です。深さを変えたいならbudget_tokensを直接動かします。budget_tokensには「1,024トークン以上」「max_tokens未満」という制約があるため、budget_tokensを上げても深さが変わらないと感じる場合は、上限そのものが小さすぎるか、max_tokensとの兼ね合いで実質的な余地が残っていないかも合わせて確認します。
切り分けの実践手順
- モデルの対応モードを確認する。thinking-troubleshootingのモデル別表で
Adaptive only/Extended only/ 両対応のどれかを見る - リクエストの
thinking.typeを確認する。"adaptive"を明示していない、あるいはコード側が古い"enabled"のままになっていないか - extended onlyのモデルなら
budget_tokensを直接動かす。effortを送っても無視されるか400エラーになる場合がある(モデルによって挙動が異なるため、まず400が出ていないかログを確認する) - Opus 4.5だけは両方を確認する。深さの不満なら
budget_tokens、応答の作り込みの不満ならeffortと、変えるパラメータを目的別に分ける
curl https://api.anthropic.com/v1/messages \
--header "x-api-key: $ANTHROPIC_API_KEY" \
--header "anthropic-version: 2023-06-01" \
--header "content-type: application/json" \
--data '{
"model": "claude-opus-4-5",
"max_tokens": 4096,
"thinking": {"type": "enabled", "budget_tokens": 8000},
"output_config": {"effort": "high"},
"messages": [{"role": "user", "content": "..."}]
}'上の例はOpus 4.5でbudget_tokensとeffortを併用する形です。他のextended-thinking専用モデルにこの構成をそのまま送ると、effort の指定自体が無視されるか拒否されます。
400エラーが出ているかどうかも見る
effortの変更が反応しない場合、レスポンス自体は成功していても、実は別のリクエストが400エラーで拒否され続けていて、フォールバック処理が古い設定のまま動いているだけということがあります。Opus 5では thinking: {type: "disabled"} を effort: "xhigh" や "max" と組み合わせると400エラーになるなど、モデルによってはeffortの値とthinkingの状態の組み合わせ自体が拒否される条件があります。ログでステータスコードとエラーメッセージを確認し、成功しているリクエストのeffort値が本当に意図した値になっているかを疑うのが最初のステップです。
よくある誤診断
- SDKのデフォルト値が古いままで、effortを明示していると思い込んでいる: ラッパー層がeffortパラメータを渡していない、または固定値で上書きしている
- adaptive/extendedの切り替え自体を忘れている: モデルを新しい世代に切り替えたのに
thinking.typeの指定が旧来の"enabled"+budget_tokensのままで、実質的にeffortが効かないモードで動き続けている - effortを変えたつもりでキャッシュされた古いレスポンスを見ている: プロンプトキャッシュが効いている場合、直前と全く同じ入力・同じeffortであれば当然出力も似通う。effortを変えた回のレスポンスかどうかをリクエストIDで確認する
- モデルの既定値と混同している: 一部のモデルはeffortを明示しなくても既定でthinkingがオンになっており、effortを追加しても既定からの変化量が小さく見える
adaptive modeでは「深さゼロ」も正常な結果
adaptive modeを使っているのにthinkingブロックが全く出ない、あるいは短いままというケースも「effortが効いていない」と誤診されがちです。adaptive modeはリクエストごとに、考える必要があるかどうかをモデル自身が判断するため、単純な問いには意図的にthinkingを省略します。この場合はeffortを上げるより、システムプロンプト側で考える範囲を明示的に指示するほうが効きます。
effortの値そのものの意味とlow〜maxの使い分けはClaude effortとは、拡張思考のトークン予算を固定運用する方法はMAX_THINKING_TOKENSとは、thinking blockの取り扱いを誤ってエラーになるケースはthinking block mismatchエラーの原因で扱っています。逆にthinkingの設定を変えていないのにキャッシュヒット率が落ちた場合は、thinking設定を変えるとプロンプトキャッシュのヒット率が下がる理由が別の切り分けの入り口になります。
Opus 4.6 / Sonnet 4.6はadaptiveへ切り替えないとeffortが効かない
「対応するモード」はモデルの新旧で綺麗に二分されているわけではなく、世代の境目にあるモデルは両対応になっている点にも注意が必要です。Claude Opus 4.6とSonnet 4.6はadaptiveとextended(非推奨扱い)の両方を受け付けるため、リクエストのどこかで古いコードがextended thinkingの形式(type: "enabled" + budget_tokens)を送り続けている場合、動作はしますが非推奨のまま埋もれてしまい、effort を追加しても反応しません。この場合はコードを thinking: {type: "adaptive"} へ切り替えるのが根本的な対処です。
Claude Mythos Previewのように両方のモードを持つモデルでも、"disabled" だけは拒否されるといったモデル固有の制約が残っています。effortが効かない原因を「モデルの世代」だけで判断せず、実際に送っているリクエストの thinking.type の値まで戻って確認することが、誤診断を避ける近道です。
effortの値を頻繁に切り替える実装では、深さの変化を確認する前に、そもそもリクエストごとに effort の値が意図通りログへ記録されているかをまず確かめておくと、以降の切り分けが速くなります。
まとめ
effortを変えても深さが変わらないときは、まずモデルがadaptive modeかextended thinkingかを確認します。adaptive modeでは effort が主レバーですが、extended-thinking専用モデルでは budget_tokens が深さを直接決め、effort は多くの場合パラメータとして機能しません。唯一Opus 4.5だけは両方を受け付けますが、深さを担うのはbudget_tokensでeffortは応答全体の作り込みを担う、という役割分担です。モデルの対応モードと、目的に合ったパラメータを表で確認してから動かすのが最短の切り分けです。