Claude Adaptive Thinking実践ガイド — budget_tokensからの移行と4段階effort制御で実現するコスト最適な推論戦略
Adaptive Thinkingとは — Extended Thinkingの何が変わったのか
Claude Opus 4.6およびSonnet 4.6のリリースにより、Extended Thinkingの制御方法が根本的に変わった。従来のbudget_tokensによる固定トークン予算方式は非推奨(deprecated)となり、Claudeが自律的に思考量を判断する「Adaptive Thinking」が新たな推奨方式となっている。
従来のExtended Thinking(budget_tokens方式)の課題
これまでのExtended Thinkingは、thinking.type: 'enabled'とbudget_tokensを組み合わせて使う方式だった。開発者が「何トークンまで思考に使ってよいか」を明示的に指定する必要があり、タスクの難度に対して予算が少なすぎれば推論品質が下がり、多すぎればコストとレイテンシが無駄に増える。適切な値を見積もるのは難しく、タスクごとにチューニングが必要だった。
Adaptive Thinkingの仕組み:Claudeが思考量を自律判断
Adaptive Thinkingでは、thinking.type: 'adaptive'を指定するだけでよい。Claudeがリクエストの複雑さを自ら評価し、思考の要否と量を動的に決定する。単純な質問には思考をスキップし、複雑な推論が必要な場面では十分な思考を行う。
さらに重要な点として、Adaptive Thinkingを有効にするとInterleaved Thinking(ツールコール間の思考)が自動的に有効化される。エージェントワークフローにおいて、ツールの実行結果を受けて次のアクションを考える、という自然な推論フローが追加設定なしで実現できる。
また、Adaptive ThinkingはGA(一般提供)機能であり、betaヘッダーは不要。client.beta.messages.createではなくclient.messages.createで利用できる。
対応モデルはClaude Opus 4.6(claude-opus-4-6)とClaude Sonnet 4.6(claude-sonnet-4-6)のみ。旧モデルでは引き続きbudget_tokens方式を使う必要がある。
以下に、3つのモードの比較を示す。
from anthropic import Anthropic
client = Anthropic()
# 1. Adaptive Thinking(推奨)
response = client.messages.create(
model="claude-opus-4-6",
max_tokens=16000,
thinking={
"type": "adaptive", # Claudeが思考量を自律判断
},
output_config={
"effort": "high", # 思考の深さをガイド
},
messages=[{"role": "user", "content": "この関数のバグを特定してください"}],
)
# 2. Manual Extended Thinking(非推奨・将来削除予定)
response = client.messages.create(
model="claude-opus-4-6",
max_tokens=16000,
thinking={
"type": "enabled",
"budget_tokens": 10000, # 固定トークン予算
},
messages=[{"role": "user", "content": "この関数のバグを特定してください"}],
)
# 3. Thinking無効(思考なし)
response = client.messages.create(
model="claude-opus-4-6",
max_tokens=16000,
messages=[{"role": "user", "content": "こんにちは"}],
)
5分でできる移行 — budget_tokensからAdaptive Thinkingへ
Before/After: コード変更は最小限
移行に必要なコード変更は驚くほど少ない。正直、最初にドキュメントを読んだときは「これだけ?」と拍子抜けした。
Before(Opus 4.5 + budget_tokens + beta):
response = client.beta.messages.create(
model="claude-opus-4-5-20250415",
max_tokens=16000,
betas=["interleaved-thinking-2025-05-14"],
thinking={
"type": "enabled",
"budget_tokens": 10000,
},
messages=[{"role": "user", "content": prompt}],
)
After(Opus 4.6 + adaptive + effort):
response = client.messages.create(
model="claude-opus-4-6",
max_tokens=16000,
thinking={
"type": "adaptive",
},
output_config={
"effort": "high",
},
messages=[{"role": "user", "content": prompt}],
)
移行チェックリスト
変更すべきポイントを整理する。
thinking.type:'enabled'→'adaptive'に変更budget_tokens: 削除(adaptive では不要)output_config.effort: 追加(low/medium/high/max)- APIコール:
client.beta.messages.create→client.messages.create - betaヘッダー削除:
effort-2025-11-24、interleaved-thinking-2025-05-14、fine-grained-tool-streaming-2025-05-14はすべて不要に
注意すべき破壊的変更が2つある。
- Opus 4.6ではassistant messageのprefill(先頭テキスト指定)が400エラーになる。出力形式を制御したい場合は
output_config.formatまたはstructured outputsを使う - Sonnet 4.6はadaptiveとmanual(budget_tokens)の両方をサポートする。ただしmanualモードでInterleaved Thinkingを使う場合は、依然として
interleaved-thinkingのbetaヘッダーが必要
4段階effort制御の使い分け戦略
各effortレベルの挙動と推奨ユースケース
output_config.effortは、Claudeの思考の深さを制御するパラメータだ。厳密なトークン予算ではなく「行動シグナル」として機能する。
| effort | 挙動 | 推奨ユースケース |
|---|---|---|
low | 思考をスキップ、ツールコールも最小化 | 分類、ルックアップ、高スループット処理 |
medium | 適度な思考。簡単なクエリでは思考スキップも | エージェントタスクのバランス型、チャット |
high(デフォルト) | ほぼ常に思考する | 複雑な推論、コーディング、エージェントタスク |
max | 思考深度に制約なし。Opus 4.6専用 | 最高精度が求められる分析、数学的証明 |
重要なポイントとして、effortは思考だけでなくテキスト応答やツールコールのトークン消費にも影響する。lowを指定すると、応答全体がコンパクトになる傾向がある。
また、低effortでも十分に難しい問題では思考が発生する(ただし高effortより量は少ない)。あくまでガイダンスであり、強制的な制約ではない。
effortがツールコールに与える影響
Sonnet 4.6はデフォルトのeffortがhighだが、公式ドキュメントではエージェント用途ではmedium、チャット用途ではlowを推奨開始点としている。明示的にeffortを設定しないと、予想外にレイテンシが増加する可能性がある点は覚えておきたい。
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
// ユースケースに応じてeffortを動的に選択
function getEffortForTask(taskType: string): "low" | "medium" | "high" | "max" {
switch (taskType) {
case "classification":
case "lookup":
return "low";
case "chat":
case "code_generation":
return "medium";
case "complex_reasoning":
case "agent":
return "high";
case "critical_analysis":
return "max"; // Opus 4.6専用
default:
return "high";
}
}
const effort = getEffortForTask("code_generation");
const response = await client.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 8000,
thinking: { type: "adaptive" },
output_config: { effort },
messages: [{ role: "user", content: "FizzBuzzを実装してください" }],
});
実装パターン:エージェントワークフローでの動的effort切り替え
タスク難度に応じたeffort動的選択
Adaptive Thinkingがエージェントワークフローに最適な理由は、Interleaved Thinkingが自動有効化される点にある。ツールを実行し、その結果を受けて次のアクションを考え、また別のツールを呼ぶ——この一連の流れの中で、各ステップにおいてeffortを動的に変えることができる。
例えば、情報収集フェーズはlowで高速に回し、分析フェーズはhighでじっくり考えさせ、最終判断はmaxで最高精度を出す、という使い分けが実現できる。
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
type Phase = "gather" | "analyze" | "decide";
function getEffortForPhase(phase: Phase, model: string) {
const effortMap: Record<Phase, "low" | "medium" | "high" | "max"> = {
gather: "low", // 情報収集は高速に
analyze: "high", // 分析はじっくり
decide: model === "claude-opus-4-6" ? "max" : "high", // 最終判断は最高精度
};
return effortMap[phase];
}
async function agentStep(
phase: Phase,
messages: Anthropic.Messages.MessageParam[],
tools: Anthropic.Messages.Tool[],
) {
const model = "claude-opus-4-6";
const effort = getEffortForPhase(phase, model);
const response = await client.messages.create({
model,
max_tokens: 16000,
thinking: { type: "adaptive" },
output_config: { effort },
tools,
messages,
});
// stop_reasonに応じたハンドリング
if (response.stop_reason === "max_tokens") {
console.warn("max_tokens到達: max_tokensを増やすかeffortを下げてください");
}
return response;
}
ストリーミング対応
ストリーミングではthinking_deltaイベントでthinkingブロックが逐次配信される。adaptive/manual両方で同じストリーミングAPIが使える。
const stream = await client.messages.stream({
model: "claude-opus-4-6",
max_tokens: 16000,
thinking: { type: "adaptive" },
output_config: { effort: "high" },
messages: [{ role: "user", content: "複雑なアルゴリズムを設計してください" }],
});
for await (const event of stream) {
if (event.type === "content_block_delta") {
if (event.delta.type === "thinking_delta") {
process.stdout.write(`[thinking] ${event.delta.thinking}`);
} else if (event.delta.type === "text_delta") {
process.stdout.write(event.delta.text);
}
}
}
なお、プロンプトキャッシュについても把握しておくべきだ。adaptive同士の連続リクエストではキャッシュブレークポイントが維持される。しかし、adaptive↔enabled/disabled間で切り替えるとメッセージキャッシュが破棄される(system promptとtool definitionsのキャッシュは維持)。モード切り替えを頻繁に行うとキャッシュ効率が落ちるため、一貫してadaptiveを使うのが望ましい。
ハマりポイントと注意事項
課金・コスト面の落とし穴
Summarized Thinkingに注意が必要だ。Claude 4モデルでは、思考内容がサマリとして返される。しかし、課金は完全な思考トークン数に基づく。レスポンスに表示されるサマリのトークン数と、実際の請求額が一致しない。usage情報のcache_creation_input_tokensやinput_tokensを必ず確認すること。
signatureフィールドも忘れてはならない。思考ブロックには暗号化されたsignatureが含まれる。ツール使用時にthinkingブロックをassistantメッセージとして返送する場合、受け取ったsignatureをそのまま含める必要がある。
モデル別の機能差に注意
maxeffortはOpus 4.6専用。Sonnet 4.6で指定するとエラーが返る。モデルを動的に切り替えるコードでは、effortの上限チェックが必須- Opus 4.6のmanualモード(budget_tokens)ではInterleaved Thinkingが使えない。エージェントワークフローでツールコール間の思考が必要なら、adaptiveモード一択
- Sonnet 4.5以前のモデルではAdaptive Thinkingは使えない。budget_tokens方式で運用を続ける必要がある
// stop_reason別のエラーハンドリング
function handleResponse(response: Anthropic.Messages.Message) {
switch (response.stop_reason) {
case "end_turn":
// 正常完了
break;
case "max_tokens":
// 出力がmax_tokensに到達。max_tokensを増やすかeffortを下げる
console.warn("出力が途中で切れています。max_tokensの増加を検討してください");
break;
case "refusal":
// 安全性フィルターによる拒否
console.error("リクエストが拒否されました");
break;
case "tool_use":
// ツールコール。ツールを実行して結果を返す
break;
}
// model_context_window_exceededはAPIエラーとして返る(stop_reasonではない)
}
個人的には、Summarized Thinkingによる課金の不透明さが一番の注意点だと感じている。開発中はusageフィールドをログに出力して、実際のトークン消費を把握する習慣をつけておきたい。
まとめ:タスク別の推奨設定早見表
| ユースケース | thinking.type | effort | 対応モデル |
|---|---|---|---|
| チャット / Q&A | adaptive | low | Opus 4.6, Sonnet 4.6 |
| コード生成 / エージェント | adaptive | medium(Sonnet)/ high(Opus) | Opus 4.6, Sonnet 4.6 |
| 複雑な推論・数学 | adaptive | high | Opus 4.6, Sonnet 4.6 |
| 最高精度の分析 | adaptive | max | Opus 4.6のみ |
| 予測可能なレイテンシ重視 | enabled + budget_tokens | — | 全モデル |
| 旧モデル(Sonnet 4.5以前) | enabled + budget_tokens | — | 旧モデル |
Adaptive Thinkingへの移行は、コード変更自体は最小限だ。thinking.typeを'adaptive'に変え、budget_tokensを削除し、output_config.effortを追加する——それだけで完了する。しかし、思考制御のパラダイムは「固定予算の手動制御」から「Claudeの自律判断 + effortによるガイダンス」へと根本的に変わっている。
特にエージェントワークフローでは、Interleaved Thinkingの自動有効化とeffortの動的切り替えが大きなメリットとなる。タスクの性質に応じてeffortレベルを使い分けることで、コストとレイテンシを最適化しながら推論品質を維持できる。
budget_tokensは当面動作するが、将来のモデルリリースで削除が予定されている。新規開発ではAdaptive Thinkingを採用し、既存コードも早めに移行しておくことを推奨する。
