Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin Chain SAFU CryptoTax DeFAI AGI Claude Me Claude Skill Claude Design Claude Cowork
独立メディア
いかなるプロジェクトとも無提携
Claudeスキルを学んで、すべてをもっとうまくやろう
claudeskill-me.com
最新
/compact実行後、ClaudeがSkillを使わなくなった?故障ではなく、自動的に復元しないよう設計されている  ·  Claude CodeはAGENTS.mdをサポートしたが、ネット上の記事の半分は古いルールを説明している——CLAUDE.local.mdが静かに機能を無効化する  ·  Hookに「blocking error」と表示されたのに、ファイルは変更されている?PostToolUseとPreToolUseの「ブロック」は同じ意味ではない  ·  Auto Modeを設定したから安全?権限モードとサンドボックス境界は全く別の防御層で、混同すると事故につながる  ·  Messages APIに「オンデマンド圧縮」ベータ機能が追加:システム任せではなく開発者が圧縮のタイミングを決定  ·  Claude CoworkとChatが正式統合、Claude DocsとClaude Slidesを同時発表
用語解説 · Prompt Engineering

Extended Thinking

拡張思考
Prompt Engineering intermediate

30秒バージョン · 忙しい方へ
Claudeが本回答の前に行う内部推論。思考するかどうか、どれだけ深く思考するかはモデルがリクエストごとに判断し、現行版はeffortパラメータが分配を導く。旧版のbudget_tokensのような固定上限ではない。
詳しく読む +
01 · これは何?

拡張思考は実際に何をしていて、通常の返答とどう違うのですか?

拡張思考とは、Claudeが最終的な返答を生成する前に内部推論を一段行う仕組みだ。公式ドキュメントはこの過程を「自己評価」と表現している——モデルはまず、この特定のリクエストが本当に追加の推論を必要とするかどうかを判断する。不要だと判断すれば、その回答のターンには思考ブロックが一切含まれないこともある。必要だと判断すれば、思考プロセスを展開し、それに基づいて最終的な答えを生成する。

通常の返答との最大の違いは「毎回必ず発生するかどうか」だ。拡張思考は毎ターン必ず起動する機能ではなく、リクエストの複雑さに応じて動的に決定される。同じ対話の中で、前のターンには思考ブロックがあったのに、次のターンで簡単な質問をしたら全く無かった、ということもある。この深さの変動は設計上想定された挙動であり、不安定さや異常ではない。

02 · なぜ存在する?

旧版の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レベルを変更することも同様にキャッシュポイントを無効にすることで、この代償は新しいパラメータに変わったからといって消えてはいない。

03 · 意思決定にどう影響する?

自分のアプリケーションではどのeffortレベルを選ぶべきですか?

公式ドキュメントが示す具体的な対応は次の通りだ:maxは最大量・最深度の思考で、思考の長さに制約がない。xhighはhighよりも積極的かつ深く思考する。highはほとんどのモデルのデフォルト値で、思考から利益を得られるほとんどのリクエストで起動する。mediumはClaude Opus 5.5のデフォルト値で、中程度の思考強度を持ち、簡単な問い合わせはそのままスキップする場合がある。lowは思考量を最小限に抑え、応答速度を優先する。

実務上の選択ロジックはタスクの性質次第だ。シンプルで、高速応答が必要で、大量の繰り返し呼び出しが行われる場面にはlow、あるいは特に設定せずモデルのデフォルト値に任せるのが適している。複数ステップの推論、コードのデバッグ、複雑な分析といったタスクには、high以上に引き上げる方が通常は見返りが大きい。本当に注意すべきなのはコスト管理のもう半分だ——max_tokensこそが総出力(思考+返答)のハード上限であり、effortはその上限のうちどの程度の割合を思考に配分するかを決めるだけだ。両方のパラメータを一緒に設定して初めて全体像が完成する。

04 · どうすればいい?

拡張思考のトークンはどう課金され、画面に表示される思考内容は実際に課金される量と一致しますか?

完全には一致しない。課金はusage.output_tokens_details.thinking_tokensフィールドに記録された完全な思考トークン数に基づいており、この数値は通常の出力トークンとして一緒に課金される。しかし、実際に画面に表示される思考内容は要約処理されたバージョンである可能性があり、モデルの内部推論過程を逐語的に示しているわけではない。つまり、画面で見える思考テキストの長さから、そのリクエストが実際にいくらかかったかを直接推定することはできない。本当に見るべきなのは返されるthinking_tokensの数値だ。

このギャップはコスト管理において重要だ。表示されている思考内容の長さだけで支出を判断すると、実際のコストを過小評価しやすい。完全な内部推論は、画面に表示される要約よりもかなり長く実行されている可能性があるからだ。

出典:Effort - Claude Platform Docs、Steering thinking and cost - Claude Platform Docs
具体例 +

公式ドキュメントの課金例は具体的だ:あるリクエストから返されるusageにはinput_tokens: 25、output_tokens: 348と表示され、output_tokens_details.thinking_tokensには312が記録されている——つまりこの348個の出力トークンのうち、312個は実際には思考プロセスによって消費されたものであり、残りのわずか36トークンだけが実際にユーザーに表示される返答内容だ。課金上は348トークンすべてが出力トークンとしてまとめて計算され、思考と返答に分けて別々の価格設定がされているわけではない。

よくある誤解 +
✕ 誤解 1
× 誤解:effortをmaxに設定すれば、毎回のリクエストで完全な思考プロセスが必ず起動することが保証される、実際は:effortは配分の方向を示すソフトガイダンスであり、ハードな保証ではない。モデルはそのリクエストが本当に思考を必要とするかどうかを自分で判断し続ける。maxに設定することの意味は「思考する場合は最も深く、最も長く思考できる」ということであり、「毎回必ず思考する」ことではない
✕ 誤解 2
× 誤解:画面に表示される思考内容の長さから、そのリクエストの実際のコストを推定できる、実際は:表示される思考内容は要約されたバージョンである可能性があり、実際の課金根拠は返される thinking_tokens の数値だ。両者は必ずしも一致せず、表示の長さだけで判断すると実際のコストを過小評価しやすい
The Missing Link +
直接的な影響

拡張思考は、本当に複数ステップの推論を必要とするタスクにおいて、回答の質を明確に向上させることができ、effortのソフトガイダンスは旧来のハード上限よりも柔軟で、タスクの種類ごとにトークン数を細かく調整する必要がない。代償は、思考プロセス自体が出力トークンの課金対象になることと、effortレベルを変更するとプロンプトキャッシュのキャッシュポイントが無効になることだ。高頻度・低遅延が求められるアプリケーションにとっては、このキャッシュ無効化のコストを別途評価する必要がある。

質問する
10文字以上入力してください
関連トピック
Fable 5.1のキャッシュ読み取りが75%値下げ——実際の節約額は請求額に占めるキャッシュの割合で決まる
Claude Me
Anthropicが示す25%から45%というのは、都合の良い数字を選べる範囲ではなく、同じ公式がキャッシュ割合の違いによって算出する2つの端点にすぎない。
#prompt-caching
エージェントがすぐ忘れる?問題はコンテキストウィンドウが小さいことではなく、そこに詰め込みすぎていることだ
AI Agent Bible
企業のAI導入における失敗の約65%はコンテキストドリフトとメモリ喪失が原因で、モデルの能力不足ではない——ウィンドウを大きくしても「詰め込みすぎ」という問題は解決しない。
#prompt-caching
Claude CodeにPreModelSwitch/PostModelSwitchフックが追加:モデル切り替えがついに検知・記録できるように
Claude Me
自動フォールバックとセッション復元はPreModelSwitchを経由しない——つまり、どれだけ完璧な検知ルールを書いても、2つのシナリオは事後に記録することしかできず、事前に捕まえる術はない。
#prompt-caching
Claude Codeの請求額はなぜ増えるのか:同じタスクでトークンコストを半分にする3つの習慣
Claude Me
トークン節約の要点は質問を減らすことではなく、毎回のラウンドでもう不要な古いデータを引きずらないことだ。
#prompt-caching