使っているモデルがすでにカスタムTemperature値を受け付けないなら、Temperatureという概念自体がもう完全に時代遅れで理解する必要はないということですか？
いいえ、そうではない。あるモデルレベルでパラメータが調整不可になったとしても、そのメカニズム自体を理解しておく価値は依然として二つの理由で存在する。第一に、すべてのモデルが同時にこのパラメータを無効化したわけではない——異なるモデル間を切り替える場合（例えば特定の場面で古いモデルを使うなど）、Temperatureが依然として機能するケースに遭遇することもある。第二に、「単語選択のランダム性」と「推論の深さ」が独立した二つの次元であると理解しておくことで、実際に直面している問題をより正確に表現できるようになる——出力に変化が乏しいと気づいたときに、Effortを上げれば解決すると誤解しないで済む。それは実際にはTemperature（あるいは新しいモデルではプロンプト自体の言葉遣い）が扱うべき領域だからだ。
Effortはlow、medium、highのような明確な段階名を持ちますが、Temperatureは連続値です。この違い自体は重要ですか？
この違いは、ある程度、それぞれのパラメータが誰のために設計されているかを反映している。Temperatureは連続値（通常0から1）として、より基盤にあるサンプリングメカニズムに近いパラメータであり、ユーザー自身が異なる値がもたらす違いを実験して体感する必要がある。Effortが連続値の代わりに名前付きの段階を使うのは、ある意味で「このタスクにどれだけの思考を費やすべきか」という判断を、人が日常的に物事を考える方法により近い言葉に翻訳していると言える——「highが何トークン分の思考予算に対応するか」を知る必要はなく、そのタスクが「明白」なのか「複数のトレードオフを伴う」のかを判断するだけでよい。
これは前述の傾向とも一致する。Effortの設計目標は、比較的抽象的なサンプリングパラメータの制御を、より直感的な段階的言語に置き換えることであり、ユーザーが基盤の確率分布を理解しなくても合理的な選択ができるようにすることだった。
Effortを上げると、Temperatureを上げたときのように出力が「よりランダム」で予測不能になりますか？
ならない。これこそ二つが最も混同されやすいが、実際にはまったく逆の効果を持つポイントだ。Temperatureを上げると、出力のランダム性と変化の度合いが確かに増加する。しかしEffortを上げると、通常は「正確性」と「カバーされる詳細さ」の面で出力がより一貫し、より安定する。Claudeがより多くの推論ステップを費やして異なるアプローチを検証・比較するため、かえってエッジケースを見落としにくくなるからだ。高いEffortと低いTemperatureの組み合わせが、正確性が求められる場面（コード生成など）でよく使われるのは、まさにこの二つの次元の効果が衝突せず、むしろ補完し合う関係にあるからだ。一方は思考をより周到にする役割を担い、もう一方は最終的な単語選択をより収束させる役割を担う。
私は普段ClaudeCodeでコーディングにしか使っておらず、APIには触れません。この話は実際に役立ちますか？
役立つのは判断のロジックであり、操作インターフェース自体ではない。ClaudeCodeユーザーは確かにTemperatureパラメータにアクセスできないが、Effortは日常的にすでに使っているもの（/effortコマンドで段階を切り替える）だ。「Effortが調整するのは思考の深さである」というメンタルモデルを理解しておくことで、いつ引き上げるべきかをより正確に判断できるようになる——例えば複数ファイルにまたがり、アーキテクチャ上のトレードオフを判断する必要があるリファクタリングタスクに直面し、Claudeが提案した方針が明らかなエッジケースを見落としていることに気づいた場合、正しい対処はEffortを上げることであり、要件を書き直したり、モデルが十分賢くないと嘆いたりすることではない。
逆に、気づいた問題が「同じリファクタリングタスクを2回頼むと、コードのスタイルが大きく異なり一貫性がない」というものであれば、それは実はEffortとは無関係だ。この場合むしろ確認すべきは、プロンプトやプロジェクト設定にコードスタイルの規約が明確に定義されているかどうかであり、そもそも手が届かないTemperatureパラメータを調整することではない。
Temperatureを扱う記事とEffortを扱う記事を並べて読むと、両者を同じものだと混同しやすい——どちらも「Claudeの出力方法を調整するダイヤル」と説明されることが多いからだ。しかしこの二つのパラメータは実際にはまったく異なるメカニズムを制御しており、しかも片方は新しいモデルではすでに静かに機能しなくなっている。もしメンタルモデルが旧バージョンのままだと、気づきにくい落とし穴にはまりやすい。
Temperatureは、Claudeが各トークン（単語や単語の断片）を生成する際に、確率分布からどれだけランダムに結果を選ぶかに影響する。0に設定すると、Claudeは常に確率が最も高い選択肢を選び、同じ入力に対して非常に一貫した、ほぼ決定論的な出力を生成する。1（ほとんどのモデルのデフォルト値かつ上限）に設定すると、Claudeは確率の低い選択肢もより積極的に選ぶようになり、出力にはより変化が生まれ、予想外の方向に進みやすくなる。このメカニズムはClaudeが「どれだけ深く考えるか」とはまったく関係がない——Temperatureが0であっても、Claudeは浅く、十分に推論されていない答えを出すことがある。Temperatureが管理しているのは単語選択時のランダム性だけであり、思考の徹底度ではないからだ。
Effortはまったく異なる次元のパラメータだ。これは、Claudeが最終的な答えを出す前に、問題を分析するためにどれだけの推論（thinking）予算を投じるかを決める。低いEffortでは、Claudeは訓練済みのパターンマッチングに頼って直接答えを出す傾向が強く、深い段階的推論を省略する——答えが明白で深く考える必要のないタスクに適している。高いEffortでは、Claudeはより多くの内部推論ステップを費やして問題を分解し、複数の可能なアプローチを比較検討する——複数のシステムが絡み合い、トレードオフの判断が必要な複雑なタスクに適している。この次元が支配するのは「どれだけ考えを尽くしたか」であり、最終的な単語選択が高確率寄りか低確率寄りかとはまったく別の問題だ。
これらは独立した二つの次元であるため、理論上は4つの極端な組み合わせが可能だ：低Effort・低Temperature（速く保守的で一貫した答え）、高Effort・低Temperature（徹底的な推論の後、最も確信度の高い結論を安定して選ぶ——コード生成など正確性が重要な場面でよく使われる組み合わせ）、低Effort・高Temperature（あまり熟考せず、単語選択だけが自由奔放）、高Effort・高Temperature（徹底的に推論しつつ、最終的な単語選択には意味のあるランダム性を残す——創造性を必要としつつも無秩序にはしたくないタスクに適する）。実務上は、ほとんどのタスクで調整が必要なのはどちらか一方の次元だけであり、両方を同時に大きく動かすケースは比較的まれだ。
ここに、この二つのパラメータを学んでいる人にとって特に誤解を招きやすいポイントがある：Claude Opus 4.7以降、デフォルト以外のTemperature値を渡すと直接APIエラー（400エラー）が返る。つまり、これらの新しいモデルでは、Temperatureは実質的にパラメータとして取り除かれており、もはや自由に調整できるダイヤルではない。この変化の背景には、Anthropicが「思考の深さ」の制御をEffortとthinkingパラメータに徐々に集約させ、比較的抽象的なサンプリングパラメータを、「このタスクをどれだけ深く考えるべきか」により直接対応する語彙に置き換えているという文脈がある。
もし参照しているチュートリアルが古い記事や旧バージョンのモデル向けに書かれたもので、「出力をより安定させるためにTemperatureを調整する」といった助言が書かれている場合、新しいモデルではそもそもその通りにできない可能性がある。これこそ、EffortとTemperatureを「同じものの新旧の呼び方」としてではなく、二つの異なる次元として理解することが、ある設定がなぜ効いていないように見えるのかを正しく診断できるかどうかに直接影響する理由だ。
主にclaude.aiのウェブインターフェースでチャットしている場合、あるいはClaudeCodeというターミナルツールを使っている場合、Temperatureはそもそも直接調整できるインターフェース上の項目ではなかった——どちらの画面にも数値化されたTemperatureスライダーは表示されておらず、プラットフォームは固定のデフォルト値で動作する。対照的に、EffortはClaudeCode内でコマンドを通じて直接切り替えられる（例えば/effortに続けてレベル名を入力する）——これこそ、ほとんどの一般ユーザーが実際にはTemperatureよりもEffortとやり取りする機会がはるかに多い理由であり、Temperatureは主にAPI開発の文脈に存在するものだ。
次に「Claudeの出力を調整したい」と思ったときは、まず自分に問いかけよう：解決したいのは「答えが十分に深く考えられておらず、考慮すべき点を見落としている」ことか、それとも「出力が硬直的で、毎回同じで、変化に乏しい」ことか？前者はEffortを調整すべきであり、後者になって初めてTemperatureの出番になる。もし新しいモデルをAPI経由で呼び出しているなら、そのモデルがそもそもカスタムTemperature値を受け付けるかどうかを先に確認し、すでに無効化されたパラメータに対して繰り返しデバッグする時間を無駄にしないようにしよう。