Claude Code が Opus 4.7 で top_p deprecated を返したとき、最初にやるべきことは provider を切り替えることでも、Claude Code 自体が壊れたと決めつけることでもありません。変わったのは Opus 4.7 の request contract です。Anthropic は現在、非デフォルトの top_p、temperature、top_k を含む request を 400 で拒否します。つまり本当の仕事は「Claude Code がなぜ壊れたか」を考えることではなく、「どの layer がまだ古い sampling params を送っているか」を見つけることです。
最も安全で速い順番は route-first です。まず Claude Code のバージョンを確認し、次に backend route を確認し、そのあと wrapper、plugin、proxy、config のどこかが古い fields を注入していないかを見ます。そこまで確認してから、同じ path で同じ task をやり直してください。version、route、cleanup を終えてもなお stack がその fields を止められないときだけ、一時的な fallback が現実的になります。
ここで一つ、最初に固定しておくべき current fact があります。2026 年 4 月 17 日時点で再確認した Claude Code docs では、Opus 4.7 に Claude Code v2.1.111+ が必要です。さらに opus という alias はどの backend でも同じ意味ではありません。Anthropic API では opus は Opus 4.7 を指しますが、Bedrock、Vertex、Foundry では Opus 4.7 を明示しない限り Opus 4.6 のままというケースが残ります。
この種の error で時間を失うのは、解決策がないからではなく、最初に間違った枝へ入るからです。下の route board は、その分岐判断を最小コストで済ませるためのものです。
まず分岐を選ぶ: どの path で止まっているか
top_p deprecated は一点の error に見えて、実際にはどの枝にいるかを先に見極める問題です。先に答えるべき問いは「Opus 4.7 の全変更点は何か」ではなく、「いま version の問題なのか、route の問題なのか、外側の cleanup の問題なのか」です。
| いま見えているもの | 最初に疑うべき owner | 最も安全な最初の一手 | 同じ path で何を確認するか | いつ fallback を考えるか |
|---|---|---|---|---|
Claude Code が v2.1.111 より古い、またはローカル path が古い install を指している | first-party client version または local install drift | 先に Claude Code を更新し、実際に新しい binary を起動しているか確認 | update 後に同じ task を同じ path で再実行 | current version でも同じ deprecated-parameter error が残る |
opus に切り替えたつもりだが backend route が違う | Anthropic API と Bedrock / Vertex / Foundry の alias difference | 先に opus がその route で本当に Opus 4.7 を指しているか確認 | correction または pin の後、同じ path で再実行 | route を確認しても error が変わらない |
wrapper、plugin、proxy、config がまだ top_p / temperature / top_k を注入している | outer request-shaping layer | 古い fields を値変更ではなく削除する | cleaned request shape で同じ path を再実行 | その stack が今日どうしても fields を止められない |
| すぐには stack を直せないが workflow を戻したい | compatibility lag outside the first-party path | version、route、cleanup を済ませたあとだけ bridge を使う | fallback が同じ task を戻しているか確認 | fallback 自体が別の contract mismatch を生む |
この表の価値は「全部の可能性を広く並べること」ではありません。最小の change で最大の signal を得る順番を強制することです。多くの読者が時間を失うのは、fix が見つからないからではなく、provider や route を早く変えすぎて元の path の検証可能性を失うからです。
Opus 4.7 で何が変わり、なぜ top_p が 400 になるのか
Anthropic の migration guide はこの点をかなり明確に書いています。Opus 4.7 では非デフォルトの top_p、temperature、top_k が 400 を返し、最も安全な migration path はそれらを request から省略することです。ここで重要なのは「deprecated warning が増えた」のではなく、「request validation boundary が変わった」という点です。
この違いを見落とすと、読者はすぐに「もっと安全な値を入れればよいのでは」と考えます。しかし今の correct move は、古い knob を別の数値で延命することではありません。そもそも送らないことです。request path にそれらの fields が残っている限り、model contract と request shape はまだ衝突しています。
また、Opus 4.7 は制御の重心を sampling params から prompt quality や effort のような現在の surface へ移しています。ここで必要なのは古い knobs を懐かしむことではなく、今の model family が受け取る control surface に path を合わせ直すことです。
Claude Code 自体が古い、または supported route にいない場合
2026 年 4 月 17 日時点の Claude Code docs では、Opus 4.7 に Claude Code v2.1.111+ が必要です。したがって version check は最初に置くべきです。first-party client が support window の外にいるなら、その先の wrapper や alias diagnosis はすべてぼやけます。
実際の確認は短くて十分です。
- いま起動している Claude Code の version を確認する。
v2.1.111より古いなら update し、shell から呼ばれている binary path を見直す。- update のあとで provider や env vars を同時にいじらず、同じ task を同じ path で再実行する。
この三つ目が特に重要です。update と route change を同時にやると、current first-party client が直したのか、別の path に逃げたのかが分からなくなります。
もし実際の root cause が stale install や old binary path だったなら、続きは Claude Code install guide の方が合っています。このページは exact deprecated-parameter recovery に集中したままにした方が読者のためです。
provider / alias route が思っているものと違う場合
ここを曖昧にすると diagnosis が壊れます。Claude Code の current docs は、すべての backend に同じ story を当てていません。Anthropic API では opus はもう Opus 4.7 です。一方で Bedrock、Vertex、Foundry は、明示的に 4.7 を pin しないと opus が 4.6 のままということがあります。
つまり、二人の読者がどちらも「opus に切り替えた」と言っていても、同じ contract を見ているとは限りません。一人は本当に 4.7 にいて deprecated-parameter rule に当たっている。もう一人はまだ 4.6 にいて、実際には別の mismatch を追っている。ここを分けずに body cleanup に入ると、読者は間違った branch を修理し始めます。
安全な読み方はこうです。
- Anthropic API path なら、先に alias failure を疑うより outer layer を疑う。
- Bedrock、Vertex、Foundry なら、
opusを変えただけで本当に 4.7 かを確認する。 - provider panel や wrapper があるなら、UI label ではなく actual target route を確認する。
この section の目的は paranoia ではありません。wrong contract を修理しないための最小限の branch correction です。
wrapper、plugin、config が古い sampling params を送っている場合
version と route が確認できたあとで最も可能性が高いのはこの branch です。current Claude Code support があること自体は、「なぜ同じ path がまだ top_p deprecated を出すのか」の答えにはなりません。答えが outer layer にあることはかなり多いです。
最初に見たい場所はだいたい決まっています。
- Claude Code の外側に置いた local scripts
- provider adapters
- proxy middleware
- 古い examples から残った config fragments
ここで最も堅い fix は、値を調整することではなく fields を削除することです。temperature: 1 を入れて延命するより、omission の方が安全です。Anthropic の migration guidance もその方向に寄っています。
もし fields を消したあとでも output behavior の制御が必要なら、より明確な prompt と current effort に制御を移してください。目標は古い knobs を温存することではなく、request path を current model contract に戻すことです。
もし読者の本当の job が「4.7 と 4.6 のどちらに乗るべきか」まで広がっているなら、Claude Opus 4.7 vs Claude Opus 4.6 へ誘導した方がよいです。このページは path recovery のためのページです。
fix をどう検証し、いつ fallback が妥当になるか
same-path verification はこのページの境界線です。何を直したとしても、verification は同じ task、同じ backend、同じ path に戻るべきです。別 provider、別 model family、別 wrapper chain で動いたことは、元の path の recovery を証明しません。
verification loop は短くてよいです。
- backend と task をそのままにする。
- request を実際に送る layer から deprecated fields を消す。
- 同じ path で一度だけ再実行する。
- cleaned config を残して再発を防ぐ。
fallback は禁じられていません。ただし出てくる順番が遅くあるべきです。次の条件がそろってからです。
- Claude Code は current support window 内にある。
- backend route は確認済み。
- cleanup branch で何を消すべきか分かっている。
- それでも stack が今日その fields を止められない。
このとき fallback は temporary bridge になります。たとえば古い model path を一時的に維持する、あるいは compatibility layer で rejected fields を剥がす、といった形です。ですが main fix ではありません。長期的に正しい状態は、request path を Opus 4.7 の current contract にそろえることです。
もし本当の exact 400 break が sampling params ではなく assistant-prefill removal だったなら、Claude Opus prefill error fix の方が近い sibling です。どちらも old request shape と new contract の衝突ですが、原因と replacement workflow は同じではありません。
Frequently Asked Questions
top_p deprecated は Claude Code 自体の bug ですか？
単純には言えません。Claude Code は読者が見て検索する symptom surface です。hard break 自体は Opus 4.7 の request validation にあります。current Claude Code support は存在しており、本当の問いはどの layer が古い fields をまだ送っているかです。
なぜ opus は backend によって意味が違うのですか？
current alias mapping が backend ごとに違うからです。Anthropic API では opus は Opus 4.7 ですが、Bedrock、Vertex、Foundry では explicit pin がないとまだ 4.6 のことがあります。だから route verification が body cleanup より先に来ます。
temperature や top_p を安全な値に変えて残せませんか？
いまの安全な move は削除です。Anthropic の Opus 4.7 guidance は、別の数値で延命するより omission を勧めています。
旧 sampling controls の代わりに何を使えばよいですか？
より明確な prompting と、サポートされる範囲での effort です。古い sampling surface を再構成するのではなく、current model family が期待する制御面を使います。
fallback はいつ妥当ですか？
version、route、cleanup を確認しても stack が fields を止められないときだけです。temporary bridge にはなりえますが、最初の一手ではありません。
The Working Rule
Claude Code が Opus 4.7 で top_p deprecated を返したら、それを provider shopping の合図ではなく、request contract mismatch として扱ってください。先に version、次に route、その後で old fields を remove し、同じ path を verify する。それでも stack が止められないなら、その時だけ fallback を使います。