Claude Opus 4.7 の temperature パラメータエラーは、数値調整ではなく削除で直す

Claude Opus 4.7 が temperature を含む request で 400 を返すなら、まず別の temperature 値を探さないでください。最初にやることは、実際に送信される payload から temperature を削除することです。

同じ扱いが top_p と top_k にも必要です。問題は「どの数値なら通るか」ではなく、「SDK、Bedrock adapter、gateway、IDE plugin、eval harness、retry template のどこが古い sampling フィールドをまだ入れているか」です。

安全な順序は、古いフィールドを削除し、final outbound payload を確認し、必要な制御を prompt、schema、test、または対応 route の effort に移し、同じ route で再試行することです。fallback は、現在の stack がそのフィールドを止められない場合だけです。

まず修復分岐を決める

このエラーは一つの症状に見えて、実際には owner の切り分けです。route を替える前に、どの層がフィールドを追加しているかを決めます。

修復と同時に provider、model family、prompt を全部変えると、何が効いたかわからなくなります。同一路径での検証を先に置いてください。

Opus 4.7 で変わった境界

Anthropic の現在の Opus 4.7 migration guidance では、non-default の temperature、top_p、top_k は 400 の原因になります。推奨される migration は、これらのフィールドを送らないことです。

そのため、temperature: 0 は安全な置き換えではありません。以前のモデルでも、temperature 0 はあらゆる route で同じ出力を保証するスイッチではありませんでした。Opus 4.7 では、それ以前に request shape と model contract を合わせる必要があります。

つまり、temperature の話を「数値の話」から「request field cleanup の話」に変える必要があります。

SDK request を修正する

自分の code に field があるなら、修正は単純です。削除します。

python
message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1200,
    temperature=0.2,
    top_p=0.9,
    messages=[{"role": "user", "content": "Refactor this function."}],
)

修正後：

python
message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1200,
    messages=[{"role": "user", "content": "Refactor this function."}],
)

TypeScript でも同じです。

ts
const response = await anthropic.messages.create({
  model: "claude-opus-4-7",
  max_tokens: 1200,
  messages: [{ role: "user", content: "Summarize the incident." }],
});

修正後は call site ではなく、送信直前の body を見ます。shared helper が default を入れ直す、gateway が OpenAI-style body を変換する、retry が古い template から payload を再構築する、といったことが起きます。

厳密な output が欲しいなら、field ではなく contract を書きます。

text
Return exactly one JSON object with keys "root_cause", "fix", and "verification".
Do not include prose outside the JSON.
If evidence is insufficient, set "root_cause" to "unknown".

hidden injection を探す

日本語の現場では「コードにはないのに API が怒る」という相談が多くなりがちです。その場合、first SDK call だけでは足りません。最後に出る payload を確認します。

見る場所は次です。

• 全モデルに generation defaults を足す SDK wrapper。
• OpenAI-compatible gateway が temperature を Anthropic body にコピーする箇所。
• Bedrock adapter が account defaults を merge する箇所。
• IDE plugin や agent preset の古い model config。
• eval harness が比較用に temperature を固定する設定。
• MODEL_TEMPERATURE などの environment variable。
• retry middleware が stale body から再送する箇所。

log には secret や full prompt を出さず、field name、model ID、route、old fields の有無だけを出せば十分です。

Bedrock と provider route

AWS Bedrock の Claude Opus 4.7 model card でも、temperature、top_p、top_k はサポートされないとされています。つまり Bedrock 経由の失敗も同じ cleanup が必要です。

モデル移行そのものを判断したいなら Claude Opus 4.7 vs Claude Opus 4.6 を見てください。ここでは、選択済みの Opus 4.7 route を動かすことに集中します。

何で置き換えるか

temperature の一対一の後継はありません。昔その field にやらせていた job を分解します。

effort は reasoning と token spend の control です。temperature の名前違いとして扱うと、また別の mismatch を作ります。

検証してから fallback

検証は同一路径で行います。

1. model、provider、prompt、task を変えない。
2. temperature、top_p、top_k を送信経路から削除する。
3. final outbound body を確認する。
4. 一度だけ同じ route で retry する。
5. regression check を入れて旧 preset の復活を防ぐ。

fallback は、今日その stack がどうしても old fields を止められないときだけ使います。古い model route、field stripping gateway、tool version pin は bridge です。長期の答えは payload を現行 contract に合わせることです。

よくある質問

temperature は完全に消えたのですか？

公式の境界は non-default 値です。ただし実装上は field を省略するのが安全です。SDK や gateway が default をどう扱うかは route により変わります。

temperature: 0 は使えますか？

migration fix としては使わないでください。deterministic output が欲しいなら、prompt、schema、test、same-route verification を使います。

effort は temperature の代替ですか？

いいえ。reasoning depth と token spend の control です。style や format は prompt contract で制御します。

Bedrock でも同じですか？

はい。Bedrock の Opus 4.7 route でもこれらの sampling field はサポートされません。adapter の hidden defaults を見てください。

Claude Code の top_p deprecated と同じですか？

根本境界は近いですが、Claude Code では version、route、preset を先に見ます。対応記事は Claude Code Opus 4.7 top_p Deprecated です。

作業ルール

Claude Opus 4.7 が temperature で失敗したら、数値を調整しない。field を削除し、注入元を探し、prompt または effort に制御を移し、同じ route で検証します。