adaptive thinking blockが出ない理由 — 一部のターンで起きる正常な挙動

adaptive thinkingを設定しているのに、レスポンスによってはthinkingブロックが1つも入っていないことがあります。設定漏れやエラーではなく、Claudeが「考えるまでもない」と判断したときに起きる正常な挙動です。原因の切り分け方と、頻度をコントロールする方法をまとめます。

thinkingブロックが出たり出なかったりする理由

adaptive thinkingは、リクエストごとに固定量の思考をするモードではありません。Claudeがその都度のリクエストの難しさを判断し、直接答えられるほど簡単だと判断したときは思考そのものをスキップします。同じ会話・同じthinking設定のまま送っていても、質問の内容によってthinkingブロックが付くターンと付かないターンが混在するのはこのためです。

これはthinking.typeを"adaptive"にしているモデルに共通する挙動で、思考が既定でオン(常時オン含む)のモデルでも変わりません。「常時オン」が指すのは思考の機能自体が無効化できないという意味であって、すべてのリクエストで必ずthinkingブロックが生成されることを保証するものではない点に注意します。

設定ミスとの見分け方

thinkingブロックが出ない原因は大きく2つに分かれます。

すべてのターンで一貫してthinkingブロックが出ない場合は、モデルがadaptiveをサポートしているか、リクエストのthinking.typeが意図した値になっているかを先に確認します。一部のターンだけ出ない場合は、以下のeffort調整が対象になります。

effortを上げて頻度を制御する

effortはadaptive thinkingにおける主要な制御レバーです。レベルごとに、Claudeがどれだけ思考に傾くかの既定値が変わります。

effortはthinkingオブジェクトの中ではなく、output_config.effortに指定します。

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [{ "role": "user", "content": "..." }]
}

lowやmediumのように低いeffortでは、簡単と判断される基準がゆるくなり、thinkingブロックが付かないターンが増えます。thinkingブロックの出現頻度を上げたい場合は、まずeffortを1段階引き上げるのが最初の選択肢です。effort全体の5段階の意味と設定場所はClaude effortとは — low〜maxの使い分け方に、モデルごとに使えるレベルの一覧はeffortページの対応表にまとまっています。

プロンプトで思考を促す

effortを調整しても狙った頻度にならない場合、システムプロンプトやユーザーメッセージ側で直接誘導する方法があります。公式ドキュメントは次の2段構えを推奨しています。

1. ワークロードの既定バランスに合ったeffortレベルをまず設定する
2. それでも狙った挙動にならない場合だけ、プロンプトでの誘導を追加する

システムプロンプトで思考を減らしたいときの例です。

Extended thinking adds latency and should only be used when it
will meaningfully improve answer quality, typically for problems
that require multistep reasoning. When in doubt, respond directly.

逆に思考を増やしたいときは、次のような一言を加えます。

This task involves multistep reasoning. Think carefully before responding.

システムプロンプト全体を書き換えずに、特定のユーザーメッセージだけで思考を誘導することもできます。「Please think hard before responding.」をメッセージ末尾に添えればそのターンだけ思考を促し、「Answer directly without deliberating.」を添えれば抑制できます。エージェントの実行基盤で、計画を立てるステップでは前者を、単純な確認ステップでは後者を自動的に付け加える、という使い分けが可能です。

プロンプトによる誘導は文言の言い回しに敏感で、狙った挙動が出ないこともあります。本番投入前に、誘導ありと誘導なしでthinkingブロックの出現率・出力トークン量・レイテンシ・回答品質を比較しておくことが推奨されています。思考を減らす方向の誘導は、推論の恩恵を受けるタスクの品質を落とす可能性があるため、まずはeffortの引き下げを優先し、プロンプトでの誘導は補助的に使います。

目的別のレバーの選び方

thinkingまわりには複数の設定があり、どれを触るべきかは目的で決まります。

effortは「adaptive」という値を取りません。adaptiveはthinking.type側のモード名であり、effortのレベル名ではないため、この2つのパラメーターを混同しないようにします。

effortはトークン予算そのものではない

effortを上げてもthinkingブロックが確実に付くわけではない理由の一つは、effortが固定の思考トークン予算を設定するパラメーターではなく、挙動を誘導するソフトな信号だからです。思考量を直接制限する仕組みはmax_tokensで、これはthinkingと応答テキストを合わせた出力全体の上限です。effortをhigh以上にすると、Claudeが思考に多くのトークンを使い切ってしまい、stop_reason: "max_tokens"で応答が途中で終わることがあります。この場合の対処は、max_tokensを引き上げるか、effortを下げて思考に使う分を減らすかのどちらかです。トークン量を厳密に予測できない前提でmax_tokensを組むと、effortを引き上げた途端に応答が途切れる副作用が出ることがあります。

thinkingブロックのないターンは会話履歴として不正になるか

なりません。adaptive thinkingではアシスタントターンが必ずthinkingブロックから始まる必要はなく、Claudeが思考しなかったターンはそのままの形で有効な履歴として扱われます。異なるthinking設定で始まった会話を再開する場合や、複数の経路から組み立てた会話履歴を扱う場合でも、各アシスタントターンの先頭にthinkingブロックを補って辻褄を合わせる必要はありません。この緩和はあくまで検証の話であり、thinkingブロックが実際にある場合はこれまで通り改変せずに送り返します。

effortを変えるとキャッシュに影響する

effortの値はプロンプトに実際に描画されるため、リクエスト間でeffortを変更するとプロンプトキャッシュのブレークポイントが無効になります。この点は、モデルごとの固定思考予算だった旧budget_tokensパラメーターと同じ挙動です。ただしeffortをモデルの既定値と明示的に同じ値に設定するのは、省略した場合と同等に扱われるためキャッシュを壊しません。thinkingブロックの出現頻度を試行錯誤で調整する際は、この点も踏まえて比較します。

よくあるつまずき

• ツール呼び出しだけの短いターンで頻発する: 定型的な値を渡すだけのツール呼び出しは「簡単」と判断されやすく、thinkingブロックが付かない典型例です。ツール呼び出し自体の是非を思考させたい場合はeffortを上げて様子を見ます
• 会話が進むにつれて頻度が変わる: 同じ会話でも文脈が積み上がるとリクエストの複雑さの評価が変わり、序盤は思考なし・終盤は思考ありのように偏ることがあります
• thinkingブロックの有無をロジックの分岐条件にしてしまう: 「thinkingブロックがあれば複雑な処理、なければ簡単な処理」という前提でクライアント側のロジックを組むと、effortの変更やモデルの挙動変化で分岐が崩れます。thinkingブロックの有無ではなく、レスポンスの内容そのもので分岐条件を作ります

よくある質問

プロンプトでの誘導とeffortはどちらを先に試すべきか

effortが先です。effortはモデルが持つ調整用のパラメーターで、その効果は計測・比較しやすいのに対し、プロンプトによる誘導は言い回しに敏感で、狙った通りに効くとは限りません。公式ドキュメントも「effortをまず合わせ、それでも足りないときだけプロンプトを追加する」という順序を推奨しています。プロンプトでの誘導を追加した後も、本番投入前に誘導あり・なしでthinkingブロックの出現率と回答品質を比較しておくと、狙った効果が出ているかを確認できます。

interleaved thinking(ツール呼び出しの合間の思考)にもこの挙動は当てはまるか

当てはまります。adaptive thinkingを使っていれば、ツール呼び出しの合間の思考(interleaved thinking)は追加設定なしで自動的に有効になりますが、これも「必ず毎回入る」ものではなく、Claudeがそのツール結果を受けて考える価値があると判断したときだけ生成されます。ツール呼び出しが連続しても、間の思考ブロックが必ずしも挟まらないのはこのためです。ベータヘッダーやツール定義側の追加設定は不要で、連続するツール呼び出し自体はinterleaved thinkingの有無にかかわらず成立します。

まとめ

一部のターンでthinkingブロックが出ないのは、adaptive thinkingがリクエストの難易度を判断して簡単な場合に思考をスキップする正常な挙動です。すべてのターンで一貫して出ないなら設定側の確認が先で、一部のターンだけの場合はeffortを上げることで頻度を調整します。クライアント側の実装は、thinkingブロックの有無を前提にした分岐を作らず、レスポンスの中身そのものを見て処理すれば、この挙動が実害になることはありません。同じthinkingブロックまわりでも症状が異なるので、切り分けの参考にしてください。thinkingフィールドの中身が空文字で返る別の現象についてはthinkingのdisplay: summarizedとは — フィールドが空文字になる理由を、ツール結果送信時の400エラーは「thinking blocks cannot be modified」400エラーの原因と直し方を参照してください。