拡張思考は実際に何をしていて、通常の返答とどう違うのですか?
拡張思考とは、Claudeが最終的な返答を生成する前に内部推論を一段行う仕組みだ。公式ドキュメントはこの過程を「自己評価」と表現している——モデルはまず、この特定のリクエストが本当に追加の推論を必要とするかどうかを判断する。不要だと判断すれば、その回答のターンには思考ブロックが一切含まれないこともある。必要だと判断すれば、思考プロセスを展開し、それに基づいて最終的な答えを生成する。
通常の返答との最大の違いは「毎回必ず発生するかどうか」だ。拡張思考は毎ターン必ず起動する機能ではなく、リクエストの複雑さに応じて動的に決定される。同じ対話の中で、前のターンには思考ブロックがあったのに、次のターンで簡単な質問をしたら全く無かった、ということもある。この深さの変動は設計上想定された挙動であり、不安定さや異常ではない。
旧版のbudget_tokensと現行のeffortパラメータ、実際の違いは何ですか?
budget_tokensは旧世代のモデルで使われていた設定方式で、手動管理だ。思考プロセスが使えるトークン数の上限を直接指定する、ハードリミットになっている。公式ドキュメントも、リクエスト間でbudget_tokensの値を変更するとプロンプトキャッシュのキャッシュポイントが無効になると特に注意している。
effortパラメータは現行モデルが採用している方式で、output_config.effortに設定し、low、medium、high、xhigh、maxの5段階を提供する。budget_tokensとの根本的な違いは、effortが「ソフトガイダンス」であり、モデルにおおよそどの方向にリソースを配分すべきかを伝えるだけで、ハードコードされた上限ではないことだ——maxに設定しても、毎回のリクエストで思考が必ず起動するわけではなく、lowに設定しても、本当に複雑なリクエストに遭遇すればモデルは思考が必要だと判断する可能性がある。budget_tokensと同じ点は、effortレベルを変更することも同様にキャッシュポイントを無効にすることで、この代償は新しいパラメータに変わったからといって消えてはいない。
自分のアプリケーションではどのeffortレベルを選ぶべきですか?
公式ドキュメントが示す具体的な対応は次の通りだ:maxは最大量・最深度の思考で、思考の長さに制約がない。xhighはhighよりも積極的かつ深く思考する。highはほとんどのモデルのデフォルト値で、思考から利益を得られるほとんどのリクエストで起動する。mediumはClaude Opus 5.5のデフォルト値で、中程度の思考強度を持ち、簡単な問い合わせはそのままスキップする場合がある。lowは思考量を最小限に抑え、応答速度を優先する。
実務上の選択ロジックはタスクの性質次第だ。シンプルで、高速応答が必要で、大量の繰り返し呼び出しが行われる場面にはlow、あるいは特に設定せずモデルのデフォルト値に任せるのが適している。複数ステップの推論、コードのデバッグ、複雑な分析といったタスクには、high以上に引き上げる方が通常は見返りが大きい。本当に注意すべきなのはコスト管理のもう半分だ——max_tokensこそが総出力(思考+返答)のハード上限であり、effortはその上限のうちどの程度の割合を思考に配分するかを決めるだけだ。両方のパラメータを一緒に設定して初めて全体像が完成する。
拡張思考のトークンはどう課金され、画面に表示される思考内容は実際に課金される量と一致しますか?
完全には一致しない。課金はusage.output_tokens_details.thinking_tokensフィールドに記録された完全な思考トークン数に基づいており、この数値は通常の出力トークンとして一緒に課金される。しかし、実際に画面に表示される思考内容は要約処理されたバージョンである可能性があり、モデルの内部推論過程を逐語的に示しているわけではない。つまり、画面で見える思考テキストの長さから、そのリクエストが実際にいくらかかったかを直接推定することはできない。本当に見るべきなのは返されるthinking_tokensの数値だ。
このギャップはコスト管理において重要だ。表示されている思考内容の長さだけで支出を判断すると、実際のコストを過小評価しやすい。完全な内部推論は、画面に表示される要約よりもかなり長く実行されている可能性があるからだ。
公式ドキュメントの課金例は具体的だ:あるリクエストから返されるusageにはinput_tokens: 25、output_tokens: 348と表示され、output_tokens_details.thinking_tokensには312が記録されている——つまりこの348個の出力トークンのうち、312個は実際には思考プロセスによって消費されたものであり、残りのわずか36トークンだけが実際にユーザーに表示される返答内容だ。課金上は348トークンすべてが出力トークンとしてまとめて計算され、思考と返答に分けて別々の価格設定がされているわけではない。
拡張思考は、本当に複数ステップの推論を必要とするタスクにおいて、回答の質を明確に向上させることができ、effortのソフトガイダンスは旧来のハード上限よりも柔軟で、タスクの種類ごとにトークン数を細かく調整する必要がない。代償は、思考プロセス自体が出力トークンの課金対象になることと、effortレベルを変更するとプロンプトキャッシュのキャッシュポイントが無効になることだ。高頻度・低遅延が求められるアプリケーションにとっては、このキャッシュ無効化のコストを別途評価する必要がある。