effortを変えてもthinkingの深さが変わらないときの原因切り分け

effortを上げても思考が深くならない理由

effort を high や xhigh に上げたのに、thinkingブロックの長さも呼び出し頻度も変わらない。これはバグではなく、モデルがどちらのthinkingモードで動いているかで起きる分岐です。effortが思考の深さを左右する主レバーになるのはadaptive modeのときだけで、extended thinkingしか持たないモデルでは深さを決めるのは budget_tokens です。

thinkingとeffortは何が違うか

thinking は、thinkingブロックで考えてから答えるかどうかとそのモードを決めるパラメータです。effort は、応答全体にかける労力を決めます。adaptive modeでは、この労力に思考の頻度と深さも含まれます。

だから「effortを上げれば必ず長く考える」とは限りません。thinkingがオフなら思考そのものが出ず、extendedのみのモデルでは budget_tokens が深さを握ります。adaptive はthinkingのモード名で、effortの値としては渡せません。

見た目の変化が乏しいだけで、実際には思考トークンが動いているケースもあります。原因は大きく3系統に分かれます。モデルのモードが違う、thinking自体がオフになっている、思考の中身が見えない設定になっている、の3つです。

自分のモデルはどの行にいるか

Claudeのthinkingには2つの世代があります。adaptive mode(thinking: {type: "adaptive"})はモデル自身が「考えるか、どこまで深く考えるか」を判断し、effort がその判断の強さを調整します。extended thinking(thinking: {type: "enabled", budget_tokens: N})は旧世代の手動モードで、深さは budget_tokens で決まります。

公式の対応表を、effortの効き方の観点で組み直すと次のとおりです。

effortの対応モデル一覧にSonnet 4.5とHaiku 4.5は入っていません。extended-thinking専用モデルのうちeffortに対応するのはOpus 4.5だけです。

切り分けの手順

手順1の実測は、レスポンスのJSONから該当フィールドを抜くだけで済みます。

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-5-5",
        "max_tokens": 8192,
        "output_config": {"effort": "high"},
        "messages": [{"role": "user", "content": "..."}]
    }' | jq '.usage | {output_tokens, thinking: .output_tokens_details.thinking_tokens}'

effort を low と max に替えて同じ入力で2回流し、thinking の値が動くかを見ます。thinking_tokens は課金される出力トークンの内訳で、常に output_tokens 以下です。

思考の文章が空でも、思考していないとは限らない

Fable 5.1 / Mythos 5.1 / Fable 5 / Mythos 5 / Opus 5.5 / Opus 5 / Sonnet 5.5 / Sonnet 5 / Haiku 5.5 / Opus 4.8 / Opus 4.7 / Mythos Previewでは、display の既定が "omitted" です。thinkingブロックは返りますが、thinking フィールドは空文字で、signature だけが入ります。

Opus 4.6とSonnet 4.6以前のモデルは既定が "summarized" なので、同じコードでモデルだけ新しい世代へ替えると、思考の文章が突然消えたように見えます。読める要約が必要なら thinking: {"type": "adaptive", "display": "summarized"} を指定します。空のブロックも思考自体は完了していて、課金も要約ありのときと同じです。

Opus 4.5だけの例外 — effortとbudgetの併用

extended thinkingしか使えないモデルの中で、Claude Opus 4.5だけがeffortにも対応し、両方を同時に設定できます。ただし役割は分かれています。

budget_tokens には「1,024トークン以上」「max_tokens 未満」という制約があります。budgetを上げても変わらないなら、上限が小さすぎるか、max_tokens との兼ね合いで余地が残っていない可能性があります。interleaved thinkingを使う場合に限り、budgetが max_tokens を超えることも許されます。また、予算は「目標」であって厳密な上限ではなく、Claudeは予算を使い切る前に考え終えることがあります。

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-20251101",
        "max_tokens": 16000,
        "thinking": {"type": "enabled", "budget_tokens": 8000},
        "output_config": {"effort": "high"},
        "messages": [{"role": "user", "content": "..."}]
    }'

Sonnet 4.5とHaiku 4.5では、動かすのは budget_tokens だけです。

thinkingがオフのまま、effortだけ変えている

Opus 4.8とOpus 4.7、Opus 4.6、Sonnet 4.6は、thinking を指定しない限りthinkingがオフです。この状態でeffortを替えても、効くのは応答全体の分量や丁寧さで、thinkingブロックは増えません。thinking: {type: "adaptive"} を足して初めて、effortが思考の頻度と深さの調整に使われます。

旧コードの type: "enabled" が残っている場合は、モデルで挙動が割れます。

• Opus 4.6 / Sonnet 4.6: enabled と budget_tokens は非推奨ですが、リクエストは成功します。深さを決めているのは budget_tokens のままです。根本の対処は thinking: {type: "adaptive"} への切り替えです
• Claude 4.7以降のモデル: enabled は400で拒否され、「thinking.type.adaptive と output_config.effort を使え」という趣旨のメッセージが返ります。黙って効かなくなるのではなく、エラーとして表に出ます

budget_tokens からadaptiveへ移すと、挙動そのものが変わります。固定budgetでは毎回考えますが、adaptiveでは簡単な入力で思考を省き、低いeffortほど省きやすくなります。移行直後に「思考が減った」と感じるのは、この差が原因のことがあります。

Mythos Previewは両モードに対応する一方、"disabled" だけは拒否されます。モデルの世代から判断せず、実際に送っている thinking.type の値まで戻って見るのが誤診を避ける近道です。

adaptive modeでは思考ゼロも正常な結果

adaptive modeでは、リクエストごとに考える必要があるかどうかをモデルが判断します。単純な問いではthinkingブロックが出ないのは正常で、display の設定にも左右されません。

effortのどの水準でも、すべてのリクエストで思考が保証されるわけではありません。ツールを使うループでは、ユーザー入力の直後の最初のリクエストに思考が集中しやすく、ツール結果を処理するだけの後続リクエストは xhigh や max でも思考を省くことがあります。会話が長くなるほど、1回あたりの思考は減る傾向があります。

max_tokens が小さいと、深さの差が出る前に頭打ちになります。max_tokens は思考と応答テキストを合わせた出力の上限で、high 以上では大きめに取ります。stop_reason が max_tokens で返っているなら、effortを下げるか、上限を上げます。

もっと考えさせたいときの手は2つです。effortを上げるか、システムプロンプトで考える範囲を指示します。effortは較正されたレバーなので、先に試す側に置かれています。

400エラーになるeffortとthinkingの組み合わせ

成功したレスポンスだけを見ていると、特定の組み合わせが400で弾かれていることに気づきません。effortとthinkingの状態の組み合わせで拒否されるのは次のケースです。

Sonnet 5.5の400メッセージは「thinking is disabled」と表現します。between_tools には最初の思考がなく、メッセージ上は「無効」扱いになるためです。xhigh や max で動かすなら、thinking を省くかadaptiveを指定します。

誤診断になりやすい3つのパターン

effortの値そのものの意味とlow〜maxの使い分けはClaude effortとは、拡張思考のトークン予算を固定運用する方法はMAX_THINKING_TOKENSとは、thinking blockの取り扱いを誤ってエラーになるケースはthinking block mismatchエラーの原因で扱っています。

thinkingの設定を変えていないのにキャッシュヒット率が落ちた場合は、thinking設定を変えるとプロンプトキャッシュのヒット率が下がる理由が入口になります。

まとめ

effortが効かないときは、見た目の文章ではなく thinking_tokens の実数で判断します。数字が動くなら思考は深くなっています。動かないなら、まず thinking.type と既定のオン・オフを疑い、それでも説明がつかないときにモデルの行へ戻ります。