Claude Sonnet 5のtemperatureとtop_p・top_kが400になる理由(5.5も同じ)

結論から言うと、Claude Sonnet 5.5とSonnet 5ではtemperatureを1.0以外にすると400になります。top_kはどんな値でも400です。top_pも0.99未満で400になり、1や、temperatureと一緒に入れた場合も400になると書かれたドキュメントがあります。確実なのは3つのフィールドをリクエストから消すことです。

Sonnet 4.6から切り替えた途端に、同じコードが400で返るようになったとします。そのとき疑う場所は、リクエストボディの temperature・top_p・top_k です。他の破壊的変更に気を取られて見落としやすく、評価基盤やテストコードに埋もれていることもあります。

ここでは、どの値が通りどの値が落ちるかの境目、再現性目的の temperature: 0 の扱い、そして多様性を出す代わりのプロンプトを順に見ます。

400が返ったとき、最初に確認する場所

HTTPステータスは400で、エラーの種類は invalid_request_error です。これは「リクエストの形式や内容に問題がある」場合全般に使われる分類で、このエラー専用のコードがあるわけではありません。

レスポンスはJSONで、最上位の error オブジェクトに type と message が入り、request_id も付きます。形は次のとおりです(公式の例は not_found_error ですが、構造は400でも同じです)。

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "(エラーの説明文)"
  },
  "request_id": "req_..."
}

message の実際の文言は、公式ドキュメントには原文が載っていません。文言の一致で判定するコードは書かず、type が invalid_request_error のときにリクエストボディを見直す、という切り分けが確実です。サポートに問い合わせるときは request_id を添えます。

400の原因はサンプリングパラメータだけではありません。移行直後のコードなら、次の順で疑うと早く片づきます。

• temperature / top_p / top_k が既定値以外で入っていないか
• thinking: {type: "enabled", budget_tokens: N} が残っていないか
• Sonnet 5.5へ移る場合は tool_choice に any や tool を指定していないか

どの値なら通り、どの値が落ちるか

「既定値以外」と言っても、3つのパラメータで事情が少しずつ違います。APIリファレンスの記述を並べると、次のようになります。

top_p については、公式の記述が割れています。APIリファレンスは0.99以上を通すと書く一方、thinkingのドキュメントは「既定値が0.99なので top_p: 1 も400になる」と説明しています。top_p: 1.0 を渡しているコードは、通る前提にせず消すのが安全です。

注意したいのは top_k です。temperature と top_p には後方互換のために受け付ける値がありますが、top_k は値の大小にかかわらず拒否されます。たとえば top_k: 40 のような、昔の設定ファイルに残っている値でも落ちます。

APIリファレンスは、これらを「Claude Opus 4.6より後に出たモデル」の挙動として書いています。一方、thinkingのドキュメントは、Sonnet 5以降のモデルを名指しして「既定値以外は、thinkingの有無にかかわらず毎回400」と説明しています。実務では「Sonnet 5以降は3つとも消す」と決めておけば、値の境目を覚える必要はありません。

モデルごとの扱いの違い

この制約はSonnetクラスではSonnet 5が初めてで、Sonnet 5.5にも引き継がれました。Sonnetに限った話でもありません。thinkingのドキュメントの制限一覧には、同じ扱いのモデルが並びます。Fable 5.1・Fable 5・Mythos 5.1・Mythos 5・Mythos Preview・Opus 5.5・Opus 5・Opus 4.8・Opus 4.7です。

Sonnet 4.6以前のモデルは、拡張思考(thinking)が有効なときだけ制約がかかっていました。temperature と top_k はthinkingと併用できず、top_p は0.95〜1.0の範囲に限られます。thinkingの有無にかかわらず一律で拒否されるのが、Sonnet 5世代の変更点です。

Haiku 4.5と混在運用する場合は、モデルごとにパラメータの可否が違います。リクエストを組み立てる側で、モデルIDに応じてフィールドを足し引きする分岐が要ります。Haiku 4.5では temperature と top_p を両方入れると400になるため、どちらか一方だけを渡します。

代わりに何で制御するのか

Sonnet 5ではアダプティブシンキングが既定で有効になりました。出力の幅や口調は、effort パラメータとシステムプロンプトの指示で制御する設計です。廃止の理由そのものは、参照した公式ドキュメントに書かれていません。

APIリファレンスでは、3つとも「Deprecated(非推奨)」の扱いで、新しいモデルは受け付けないと書かれています。移行で必要な対応は単純で、3つのフィールドをリクエストから取り除き、文体や出力の幅はプロンプトで指示することです。

temperature: 0の評価基盤は漏れなく洗い出す

見落としやすいのが、制約が「既定値以外」全般に及ぶ点です。ランダム性を出すために temperature を上げる使い方だけでなく、出力を安定させるための temperature: 0 も対象になります。

テストの再現性を狙って temperature: 0 を渡していた評価基盤は、Sonnet 5へ切り替えた瞬間に全ケースが400になります。棚卸しの対象は次のような場所です。

• 評価スクリプトやスナップショットテストの共通設定
• SDKのラッパーに埋め込まれたデフォルト引数
• 環境変数やYAMLから読み込まれるモデル設定

ここで再現性の考え方も改めます。APIリファレンスには、temperature が0.0でも結果は完全には決定的にならない、と書かれています。temperature: 0 は「ほぼ同じ出力」に寄せる手段であって、同一性の保証ではありませんでした。

出力の安定性が欲しいときは、temperature に頼らず、プロンプト側で出力形式を厳密に指定します。JSONのキー名を固定する、選択肢を列挙して一つ選ばせる、といった設計です。テストの判定も、完全一致ではなく構造や必須項目の検査に寄せると、モデル更新に強くなります。

リクエストボディの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 を渡す代わりに、プロンプトの中で「複数案を出してから選ぶ」ことを明示している点が変更の要です。

既存コードを移行する手順

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

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

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

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慣れ」した見た目になるのを防ぐ

自由度の高いデザイン依頼では、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段構成です。

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

temperature: 0 は、コードレビューを自動化するハーネスの決定性を保つ目的でもよく使われてきました。Sonnet 5へ切り替えるときは、この値も含めてパラメータを取り除きます。加えて、ハーネスの挙動にも注意が必要です。

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.

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

Sonnet 4.6からの移行では、サンプリングパラメータの廃止以外にも次の変更が同時に効きます。同じ作業の中で確認すると手戻りが減ります。

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

Sonnet 5.5へ進む場合は、さらに強制ツール選択(tool_choice の any と tool)も400になります。Sonnet 5.5の移行ガイドは、400を返す設定を5つ並べています。サンプリングパラメータ、thinking予算、アシスタントのprefill、強制ツール選択、thinking: {"type": "disabled"} です。

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

出力の深さやコストを調整したいときは、Sonnet 5ではeffortパラメータが受け皿になります。サンプリングパラメータが出力のランダム性を決めていたのに対し、effortは思考にどれだけトークンを使うかを決めます。目的が違うので、移行先も分けて考えます。

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

Sonnet 5.5ではeffortの水準が再較正されており、既定はAPIでhigh、Claude Codeでmediumです。エージェント系の用途はmediumから試し、Sonnet 5で決めた値を持ち越さずに測り直します。

まとめ

top_k は何を入れても落ち、temperature: 0 の評価基盤は移行チェックの最優先項目になります。移行時の他の変更を含めた全体像はClaudeモデル一覧にあります。Sonnet 5自体の登場経緯はClaude Sonnet 5が登場が詳しいです。