budget_tokens を設定して Claude の拡張思考を使うことを学んだ方に、うれしいかもしれないし、がっかりするかもしれない知らせがあります。Opus 4.7、4.8、そして Fable 5 では、そのパラメータが廃止されました。それらのどれかに thinking: {type: "enabled", budget_tokens: 8000} を送ると 400 エラーが返ります。「モデルに固定のトークン枠を渡して考えさせる」というモデル全体が、より優れた 2 つの新しいコントロールに置き換えられました。最初はとまどうかもしれませんが、実際に何が変わったのか、そして新しいシステムをどう扱うかを説明します。
旧モデルとその廃止理由
budget_tokens による拡張思考はハードな上限でした。「N トークンまで考えること」と指定すると、モデルは回答する前にスクラッチパッドで最大 N トークン分の推論を行います。機能はしていましたが、不格好でした。タスクごとにバジェットを推測しなければならず、モデルが自分で「この簡単な質問にはほとんど思考が不要で、この難しい問題には多くの思考が必要だ」と判断することができませんでした。モデルの仕事を人間がやっていたわけです。
適応的思考：モデルがどれだけ考えるかを決める
代替は thinking: {type: "adaptive"} です。適応的思考が有効な場合、モデルはリクエストごとにどれだけ考えるか・いつ考えるかを自律的に決定します。ツール呼び出しの間に自動的に思考を挟む動作も含まれており、beta ヘッダーは不要です。調整するバジェットもありません。簡単な検索には素早い回答が、多段階の推論問題には深い思考が割り当てられます。モデルが自己調整するのです。
誰もがはまるポイントが一つあります。Opus 4.7 と 4.8 では、適応的思考はデフォルトでオフです。thinking フィールドを省略すると、モデルは思考なしで動作します。有効にするには thinking: {type: "adaptive"} を明示的に設定する必要があります。（Fable 5 は例外で、思考が常にオンになっており、明示的に disabled を指定すると実際に 400 が返ります。）
Effort：全体としてどれだけ頑張るか
2 番目のコントロールは effort で、思考とは別の軸です。トップレベルではなく output_config の中に設定します。
output_config: {effort: "high"}
レベルは low、medium、high、xhigh、max です。デフォルトは high です。Effort は思考の深さと全体的なトークン消費量の両方を一緒に制御します。Effort が低いほど、ツール呼び出しが少なくなって統合され、前置きが少なく、確認も簡潔になります。高いほど、より多くの探索、より多くの検証、より徹底した処理が行われます。
実際に使って得た実践的な推奨事項を以下に示します。
xhighはコーディングとエージェント作業のスイートスポットで、Claude Code のデフォルト値でもあります。highは知性が求められる作業に対する最低限のレベルです。mediumとlowはルーティン作業や遅延に敏感な作業、サブエージェント、シンプルな分類に適しています。maxは正確さがコストより重要で、上限のために費用を払う覚悟がある場合に使います。
直感に反する発見があります。Opus 4.8 では、反射的に effort を xhigh まで上げないでください。旧モデルより知性の上限が高いため、high で十分なことが多く、エージェント作業では最初に effort を高くすることでトータルコストが下がる場合があります。モデルがより良く計画してターン数が減るからです。関係は単調ではありません。自分の評価データで medium、high、xhigh をスイープして測定してみてください。余分な熟考が純粋な無駄だったタスクで medium が xhigh に並ぶケースを実際に見てきました。
思考出力の微妙な点：午後を無駄にしかねない落とし穴
モデルが行う思考と、あなたが見る思考は別物です。Opus 4.7、4.8、Fable 5 では、思考ブロックはレスポンスストリームに引き続き現れますが、そのテキストはデフォルトで空です。display のデフォルトは "omitted" です。推論は行われ、同じように課金されます。テキストが返ってこないだけです。
4.6 から移行してユーザーに推論をストリーミングしていた場合、「思考」UI が突然何も表示しなくなり、出力前に長い静止状態があるように見えます。修正は一つのパラメータだけです。
thinking: {type: "adaptive", display: "summarized"}
これで推論の読みやすいサマリーが得られます。ブロックのフィールド名はまだ thinking であることに注意してください。レスポンスハンドラをリネームしに行かないでください。データはオプトインするまで空なだけです。そして、これらのモデルでは生の思考の連鎖はいずれにせよ返されません。summarized が得られる最大限です。
タスクバジェット：ループ全体を制限する新しい方法
エージェントループ向けにもう一つのレバーがあります（beta 版）。task_budget です。これは死から復活した旧 budget_tokens ではありません。別物です。タスクバジェットは、エージェントループ全体（思考＋ツール呼び出し＋出力）にどれだけのトークンがあるかをモデルに伝え、モデルはカウントダウンを見ながら突然切断される代わりにきちんと終えられるようにペースを調整します。
output_config: {effort: "high", task_budget: {type: "tokens", total: 64000}}
beta ヘッダー task-budgets-2026-03-13 が必要で、最低は 20,000 トークン、大きな max_tokens はタイムアウトのリスクがあるためストリーミングを使うべきです。重要な違い：max_tokens はモデルが知らない、ハードで強制される、レスポンスごとの上限です。task_budget はモデルが知っており計画を立てる根拠にできる、ソフトで累積的なループ全体の指針です。task_budget を使ってモデルを自己調整させ、max_tokens をハードな最終安全網として使いましょう。
私が今実際にこれらを設定する方法
チャットや分類のエンドポイント：サポートされている場合は adaptive オフまたは thinking: {type: "disabled"}、effort: "low"、小さな max_tokens。安価で高速。
コーディングエージェント：thinking: {type: "adaptive"}、effort: "xhigh"、余裕のあるストリーミング max_tokens、長い自律ループなら task_budget も追加。
正確さを重視する一発勝負の難しい推論タスク：adaptive オン、effort: "high" を試して max もテスト、display: "summarized" でどのように答えにたどり着いたかを監査できるように。
すべてがつながる思考モデル：適応的思考はいつ・どれだけ推論するか、effort は全体としてどれだけ頑張るか、タスクバジェットは仕事全体にどれだけ使うか。3 つのノブ、3 つの問い。トークン枠を推測するのをやめて、モデルが今得意とすること、すなわち自分で決めることをやらせましょう。