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

adaptive thinkingを設定しているのに、レスポンスによってはthinkingブロックが1つも入っていないことがあります。多くの場合、設定漏れやエラーではありません。Claudeが「考えるまでもない」と判断したターンで起きる正常な挙動です。ただし、モデルによっては最初から思考がオフのため、すべてのターンで出ないこともあります。どちらに当たるかの切り分けと、頻度の上げ方を順に見ます。

まず、一部のターンだけ出ないのか、毎回出ないのか

症状の出方で原因が分かれます。最初にここを決めると、以後の対処が絞れます。

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

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

Claude Opus 5.5・Opus 5・Sonnet 5.5・Sonnet 5・Fable 5.1・Mythos 5.1などは、思考が既定でオンです。Fable 5.1・Mythos 5.1・Fable 5・Mythos 5・Opus 5.5・Mythos Previewは「常時オン」でもあり、disabledを送ると400エラーになります。ここで言う常時オンは、思考の機能を切れないという意味です。すべてのリクエストでブロックが生成されることの保証ではありません。

ブロックそのものが無いのか、中身が空なのかも区別が要ります。displayが"omitted"のモデルでは、ブロックは返るもののthinkingフィールドが空文字になります。この場合はsignatureだけが入っており、ブロックは存在します。空文字になる原因と直し方はthinkingのdisplay: summarizedとは — フィールドが空文字になる理由にあります。

ツールループでは「最初のリクエスト」に思考が集まる

エージェントのようにツールを呼ぶ構成では、思考の出方に偏りがあります。ユーザーの新しい入力を受けた直後の最初のリクエストに、推論の大半が集まります。ツール結果を処理するだけの後続リクエストは、effortがxhighやmaxでも思考を省けます。

つまり、ツール呼び出しが5回続いた会話で、ブロックが最初の1回にしか付いていなくても異常ではありません。ツール呼び出しの合間の思考(interleaved thinking)は、adaptive thinkingなら追加のベータヘッダーなしで有効になります。ただし毎回挟まるわけではなく、ツール結果を処理するだけのリクエストでは省かれることがあります。

会話が長くなるほど、1リクエストあたりの思考は減る傾向もあります。長い会話の途中からブロックが減っても、この傾向の範囲に収まる場合があります。設定が壊れたと決めつける前に、会話の長さも見ます。

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

effortは、adaptive thinkingで思考の頻度と深さを動かす主要なレバーです。レベルごとに、Claudeが思考に傾く度合いの既定値が変わります。

どのレベルでも、思考するかどうかはリクエストごとにClaudeが決めます。ブロックの出現を保証するレベルはありません。 maxでも、前の節のツール結果だけを処理するリクエストでは省かれます。

既定のeffortはモデルで違います。多くのモデルはhighですが、Claude Opus 5.5はmediumです。Opus 5.5でeffortを指定していないなら、簡単なターンで思考が省かれる頻度は、highが既定のモデルより高めになります。effortを既定値と同じ値に明示しても、省略した場合と同じ挙動です。

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

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

頻度を上げたいときは、まずeffortを1段階引き上げるのが最初の選択肢です。5段階の意味と設定場所はClaude effortとは — low〜maxの使い分け方にまとまっています。モデルごとに使えるレベルも違い、xhighはMythos Previewなどでは使えません。

効かない場合もあります。effortが思考の頻度を動かすのは、あくまでadaptiveモードです。enabledとbudget_tokensだけを受け付ける旧モデルでは、思考の深さはbudget_tokensで決まります。Opus 4.5はその中で唯一effortに対応し、effortと思考予算が組み合わさって働きます。Mythos Previewは思考が既定でオンで、enabledによる拡張思考も受け付けます。

プロンプトで思考を促す

effortを調整しても狙った頻度にならないときは、システムプロンプトやユーザーメッセージで直接誘導できます。順序は、まず既定のバランスに合ったeffortを決め、それでも足りないときだけプロンプトを足すことです。

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

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.」を添えれば抑えられます。計画を立てるステップには前者、単純な確認ステップには後者を自動で付ける、といった使い分けが可能です。

プロンプトによる誘導は、言い回しに敏感です。狙った挙動が出ないときは、より直接的な言い方に変えて試します。本番に入れる前に、誘導ありとなしで次の4点を同じ入力で比べておくと安全です。

• thinkingブロックの出現率
• 出力トークン量
• レイテンシ
• 回答の品質

思考を減らす方向の誘導は、推論が効くタスクの品質を落とす可能性があります。こちらを使うときは、effortの引き下げを先に試します。

effortとプロンプト誘導のどちらを選ぶか

頻度を変えたいターンが全体の一部かどうかで、選び分けが変わります。キャッシュへの影響も違います。

会話ごとにthinkingの設定とeffortを決めて固定し、ターン単位の調整はメッセージ側の一言で行う、という分担になります。thinkingのモードを切り替えたりbudget_tokensを変えたりしても、同じようにキャッシュが無効になります。

目的別のレバーの選び方

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

disabledはモデルごとに扱いが違います。Opus 5はhigh以下のeffortでだけ受け付け、xhighやmaxとの組み合わせは400エラーです。Sonnet 5.5はdisabledを常に拒否し、代わりにbetween_toolsをhigh以下で使います。Opus 5でdisabledにすると、ツールが多い構成でツール呼び出しが本文にテキストとして漏れたり、内部のXMLタグが出たりすることがあります。コスト目的なら、思考を切らずにeffortを下げるほうが無難です。

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

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

effortは固定の思考トークン予算ではなく、挙動を誘導するソフトな信号です。そのため、上げてもブロックが確実に付くとは限りません。思考量を直接制限するのはmax_tokensで、thinkingと応答テキストを合わせた出力全体の上限です。

effortをhigh以上にすると、思考にトークンを使い切って、stop_reason: "max_tokens"で応答が途中で終わることがあります。対処は、max_tokensを引き上げるか、effortを下げて思考の分を減らすかのどちらかです。頻度を上げようとeffortを上げた途端に応答が途切れる、という副作用は、この上限の組み方で防げます。

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

不正にはなりません。adaptive thinkingでは、アシスタントのターンがthinkingブロックから始まる必要はありません。Claudeが思考しなかったターンは、そのまま有効な履歴として扱われます。

• 思考なしで始まった会話を、あとから再開できる
• 別のthinking設定で始まった会話を、履歴を書き換えずに続けられる
• 複数の経路から組み立てた履歴に、先頭のブロックを補う必要がない

ただし、これは検証の話です。ブロックが実際にあるときは、これまでどおり改変せずに送り返します。改変すると400エラーになり、原因と直し方は「thinking blocks cannot be modified」400エラーの原因と直し方に載っています。

よくあるつまずき

• ブロックの有無をロジックの分岐条件にする: 「ブロックがあれば複雑な処理、なければ簡単な処理」という前提でクライアントを組むと、effortやモデルの変更で分岐が崩れます。分岐はブロックの有無ではなく、レスポンスの内容そのもので作ります
• モデルを切り替えたらブロックが消えた: 思考が既定でオフのモデルへ切り替えると、thinkingを送らない限り1つも返りません。移行時は、切り替え先の既定を先に確かめます
• effortを上げたのに変わらない: budget_tokens方式のモデルでeffortだけを動かしても、思考の深さは変わりません。この場合はbudget_tokensを調整します
• Opus 5.5で簡単なターンが思考なしになる: 既定のeffortがmediumのためです。意図した挙動でなければhighを明示します

まとめ

毎回出ないなら設定とモデルの既定を見直し、一部のターンだけならadaptive thinkingの正常な挙動として、effortを上げて頻度を調整します。どのレベルでも出現は保証されないので、クライアント側はブロックの有無に依存せず、レスポンスの中身で処理するのが確実です。