Claude Sonnet 5でtemperature/top_p/top_kが400エラーになる理由

Claude Sonnet 4.6からの移行を進めているなら、他の破壊的変更に気を取られてこのエラーを見落としがちです。ここでは対処法だけでなく、なぜ廃止されたのかという設計上の理由まで押さえておきます。

Claude Sonnet 5で何が変わったか

Claude Sonnet 5に対して temperature・top_p・top_k のいずれかを既定値以外の値で指定すると、リクエストは400エラーで拒否されます。Claude Sonnet 4.6までは通っていた設定なので、既存コードをそのまま流用すると一律で失敗します。

この制約はSonnetクラスのモデルとしては初めての仕様ですが、Sonnet 5だけの特殊事情ではありません。公式ドキュメントの制限一覧では、Claude Opus 5・Claude Opus 4.8・Claude Opus 4.7でもtemperature・top_p・top_kを既定値以外に設定すると同様に400エラーになると明記されています。隣接するClaude Haiku 4.5では temperature と top_p は使えるものの同時には指定できない、という中間的な扱いのままです。モデルごとに扱いが違うため、移行時は対象モデルを確認したうえでパラメータの有無を切り替える必要があります。

さらに、この制約は「Claude Sonnet 4.6以前なら常に自由」というわけでもありません。従来モデルでは拡張思考(thinking)が有効なときに限って制約がかかっており、temperature と top_k はthinkingと併用できず、top_p は0.95〜1.0の範囲のみ許可される、という条件付きの扱いでした。thinkingの有無に関わらず一律で拒否されるようになった点が、Claude Sonnet 5世代での変更点です。

なぜ廃止されたのか

Claude Sonnet 5ではアダプティブシンキングが既定で有効になっており、出力の多様性や口調のコントロールは effort パラメータとシステムプロンプトの指示で行う設計に変わりました。サンプリングパラメータによる温度調整は、この新しい制御方式と役割が重複するため受け付けなくなっています。移行時に必要な対応はシンプルで、temperature / top_p / top_k をリクエストから取り除き、代わりにプロンプトで文体や出力の幅を指示することです。

再現性のためのtemperature: 0も対象になる

見落としやすいのが、この制約が「既定値以外」全般に及ぶ点です。ランダム性を出すために temperature を上げる使い方だけでなく、逆に出力を安定させる目的で temperature: 0 を指定する評価パイプラインやテストコードも対象になります。テストの再現性のために temperature: 0 を渡していた既存の評価基盤は、Claude Sonnet 5への切り替えでそのまま400エラーになるため、移行チェックの対象から漏らさないようにします。出力の安定性を求める場合は、temperature に頼らずプロンプト側で出力形式やフォーマットを厳密に指定する設計に置き換えます。

リクエストボディのBefore / After

サンプリングパラメータを使っていたリクエストは、パラメータを削除してプロンプトに指示を移すだけで動くようになります。

{
  "model": "claude-sonnet-4-6",
  "max_tokens": 1024,
  "temperature": 0.9,
  "messages": [{ "role": "user", "content": "Propose a color palette." }]
}

{
  "model": "claude-sonnet-5",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Propose a color palette. Suggest 3 distinct directions before picking one."
    }
  ]
}

temperature を渡す代わりに、プロンプトの中で「複数案を出してから選ぶ」ことを明示している点が変更の要点です。

400エラーの見分け方

このエラーはHTTPステータス400で拒否されます。Claude APIの400エラーは「リクエストの形式や内容に問題がある」場合全般に使われ、専用のエラーコードが割り当てられているわけではありません。したがって、コード側でリクエストの400エラーを検出したときは、パラメータの過不足や値の妥当性など他の原因とあわせて切り分ける必要があります。まず疑うべきはリクエストボディに temperature / top_p / top_k が既定値以外で含まれていないかどうかです。

デザインバリエーションを出したいときの回避策

temperature が使えなくなって最も影響が大きいのは、デザイン案や文章のバリエーションを複数出させる用途です。従来は同じプロンプトを temperature を上げて複数回投げることで異なる案を得る手法が使われていました。Claude Sonnet 5ではこの手が使えません。

公式が推奨する代替策は、1回のリクエストの中でモデル自身に複数の方向性を提案させ、そこから選ばせるプロンプト設計です。生成前に選択肢を出させることで、temperature に頼らずに実行ごとの多様性を確保できます。

Before building, propose 4 distinct visual directions tailored to this brief
(each as: bg hex / accent hex / typeface, plus a one-line rationale).
Ask the user to pick one, then implement only that direction.

具体的な配色・書体・レイアウトの方向性を4つ提案させ、ユーザーが選んだ1つだけを実装させる流れです。方向性ごとに具体的な仕様(色コード・書体名・レイアウトの数値)まで書かせて選ばせる設計のほうが、実行のたびに安定して違う結果を得られます。

生成結果が「AI慣れ」した見た目になるのを防ぐ

サンプリングパラメータで多様性を作れなくなった結果、Claude Sonnet 5はデザイン系の依頼で一貫した既定スタイルに寄りやすくなります。「その色は使わないで」「もっとシンプルに」のような否定形の指示だけでは、モデルは別の固定パターンへ移るだけで根本的な解決になりません。公式はシステムプロンプトに具体的な禁止事項を明記する方法を挙げています。

NEVER use generic AI-generated aesthetics like overused font families
(Inter, Roboto, Arial, system fonts), cliched color schemes (particularly
purple gradients on white or dark backgrounds), predictable layouts and
component patterns, and cookie-cutter design that lacks context-specific
character. Use unique fonts, cohesive colors and themes, and animations
for effects and micro-interactions.

この指示文は、前述の「4つの方向性を提案させる」プロンプトと組み合わせて使うとより効果的です。方向性を複数出させたうえで、それぞれが没個性なパターンに寄らないよう具体的な禁止事項を添える、という2段構成になります。

サンプリングパラメータ以外の破壊的変更も同時に確認する

Claude Sonnet 4.6からの移行では、サンプリングパラメータの廃止以外にも次の変更が同時に効いてきます。移行作業のついでに合わせて確認しておくと手戻りが減ります。

• アダプティブシンキングが既定で有効: thinking フィールドを指定しないリクエストも思考ブロックを返すようになる。位置でコンテンツブロックを読んでいるコードは type で判定する実装に直す必要がある
• 手動の拡張思考(thinking: {type: "enabled", budget_tokens: N})は廃止: Claude Sonnet 4.6で非推奨だったこの指定は、Claude Sonnet 5では400エラーになる。effortパラメータでの制御に置き換える
• 新しいトークナイザーを採用: 同じテキストでもトークン数がおよそ30%増える。Claude Sonnet 4.6向けに調整していた max_tokens の値は、出力が途中で切れる原因になりうるため見直しが必要

コードレビュー用途で使っている場合の注意

temperature: 0 は、コードレビューを自動化するハーネスの決定性を保つ目的でもよく使われてきました。Claude Sonnet 5に切り替える際は、この値も含めてパラメータを取り除く必要がありますが、それとは別にレビューハーネスそのものの挙動にも注意が必要です。Claude Sonnet 5は「重要な指摘だけ報告して」「保守的に」といった指示をこれまでのモデルより忠実に守る傾向があり、調査の深さは変わらなくても、基準に満たないと判断した指摘を報告しないことがあります。これは能力の後退ではなく、指示への忠実さが上がった結果です。

再現性を保ったままカバレッジを落としたくない場合は、発見の段階では確信度が低い指摘や重要度の低い指摘も含めてすべて報告させ、絞り込みは別の後段ステップに任せる設計に変えると改善します。

Report every issue you find, including ones you are uncertain about or
consider low-severity. Do not filter for importance or confidence at
this stage. For each finding, include your confidence level and an
estimated severity so a downstream filter can rank them.

既存コードの移行チェックリスト

• リクエストボディから temperature / top_p / top_k を削除する(既定値を明示的に渡している場合も対象)
• 出力の多様性が必要な箇所は「複数案を提案してから選ばせる」プロンプトに置き換える
• 文体・トーンの調整はシステムプロンプトの指示文に移す(例: Use a warm, collaborative tone.)
• Claude Haiku 4.5と混在運用する場合は、モデルごとにパラメータの可否が異なる点をリクエスト組み立てロジックに反映する

出力の深さはeffortで調整する

出力の深さやコストを調整したい場合、Claude Sonnet 5ではeffortパラメータが対応する役割を担います。サンプリングパラメータが「出力のランダム性」を制御していたのに対し、effortは「思考にどれだけトークンを使うか」を制御するもので、目的が異なる点に注意が必要です。ランダム性の代替はプロンプト設計、思考の深さの調整はeffortという役割分担で移行するのが整理しやすい考え方です。

Claude Sonnet 5は指定したeffortの範囲を厳密に守る傾向があり、特に low / medium では指示された範囲を超えて踏み込んだ検討をしません。複雑なタスクで浅い出力になっていると感じたら、プロンプトで工夫するよりも先にeffortを上げるほうが素直な対処です。

よくある質問

Claude Opus 5でも同じ制約はありますか

はい。公式ドキュメントの制限一覧には、Claude Opus 5・Claude Opus 4.8・Claude Opus 4.7でもtemperature・top_p・top_kを既定値以外に指定すると同じく400エラーになると明記されています。Haiku系は同一覧に記載がなく、Claude Haiku 4.5はtemperatureとtop_pのどちらか一方のみ指定できるという別の扱いのままです。

まとめ

Claude Sonnet 5では temperature / top_p / top_k を既定値以外に指定すると400エラーになり、この制約はSonnetクラスでは初めての仕様です。既存のリクエストからパラメータを取り除いたうえで、デザインバリエーションが必要な場面では「複数の方向性を提案させてから選ばせる」プロンプトに置き換えます。移行時の他の破壊的変更(アダプティブシンキングの既定有効化・トークナイザー変更)を含めた全体像はClaudeモデル一覧、Sonnet 5自体の登場経緯はClaude Sonnet 5が登場で扱っています。