Claude Code で top_p deprecated? まず Opus 4.7 の新しい request rule を確認

Claude Code で top_p deprecated が出たら、まずエラーを出したモデルと送信先を確認し、その組み合わせに不要なサンプリング指定を、実際に送信するリクエストから取り除きます。設定画面で top_p を消しても、ラッパーやアダプタが後から付け足していればエラーは残ります。

Opus 4.7 について、Anthropic の Messages API は非デフォルトの top_p、temperature、top_k を含むリクエストを 400 で拒否し、省略を案内しています。Amazon Bedrock の Opus 4.7 は、この3種類の指定自体をサポートしません。数値を 0 や 1 に変えるより、対象モデルへ送る指定を省くのが明確な対応です。Anthropic のパラメータ廃止案内、Bedrock の Opus 4.7 仕様

以下は、Claude Code から見えるエラーの切り分けと、自分で管理するアダプタの修正手順です。コード例はネットワーク通信をしないリクエスト整形の例であり、実環境での API 呼び出しや復旧を実測したものではありません。

設定を変える前に、どこで失敗したかを確認する

同じ top_p という文字でも、HTTP 400 と SDK の例外では直す場所が違います。エラー全文を手元で確認し、次のように切り分けてください。ログを共有するときは、認証情報、個人情報、入力内容を除きます。

Anthropic は Python SDK v1 以降でサンプリング引数を取り除き、残った呼び出しに TypeError が生じることを文書化しています。これは HTTP 送信前の失敗です。一方、別の SDK では旧モデル用の型に引数が残っていても、Opus 4.7 が受け付けるとは限りません。実際に使用している SDK のバージョンと例外を確認してください。公式の SDK 移行説明

deprecated は、ここではパラメータの廃止を指します。2026年10月6日に確認した公式一覧で Opus 4.7 と Opus 4.6 はいずれも稼働中です。モデルの退役、個別アカウントの利用権限、特定の経路での提供状況を、このエラーだけから判断することはできません。モデルの状態一覧

opus という表示ではなく、実際のモデルと送信経路を見る

調査の基準として、起動している Claude Code のバージョン、利用しているクライアント、送信先の提供元、解決後のモデル ID を控えます。ターミナル版であれば claude --version でバージョンを確認できます。これはインストールや更新を行うコマンドではありません。

opus は固定のモデル ID ではありません。提供元によって対応先が異なり、時間とともに変わります。2026年4月の「API の opus は 4.7、クラウド側は 4.6」という対応表や、当時の v2.1.111 を、現在の全モデルに共通する判断基準として使わないでください。必要な CLI バージョンも、選んだモデルに応じて確認します。Claude Code のモデル設定

モデルの確認には、現在のセッションの選択だけでなく、起動時の --model、ANTHROPIC_MODEL、設定の model、既定モデル指定が関係します。ベース URL を変えるだけでは、モデル ID は自動的にその送信先に合う名前へ変わりません。Bedrock の推論プロファイルや Foundry のデプロイ名など、提供元が求める識別子を確認する必要があります。モデル選択の優先関係と識別子

/model を使って確認・変更する場合にも注意があります。現在の公式文書では、モデル名を直接指定する操作や選択画面の Enter はユーザーの既定値を保存します。選択画面の s はそのセッションだけの変更です。調査のために別モデルへ切り替えるなら、保存範囲も把握してください。セッション中のモデル変更

ここで確認したいのは、「どれかの Opus が動くか」ではなく、失敗した作業で、どの提供元のどのモデルが呼ばれていたかです。Opus 4.7 以外へ送っているなら、以下の 4.7 用の処理を一律に適用せず、そのモデルの仕様を使います。

古い指定を取り除く場所：Messages と Converse は別

自分で管理するリクエスト生成処理では、共通の既定値とモデル別設定を合成した後、送信直前のデータを確認します。早い段階で消しても、後の合成処理が元に戻すことがあるためです。

Converse の topP は大文字の P を使います。ネイティブ形式の top_p を消す処理だけでは、Converse の指定には届きません。また、Converse の共通スキーマに topP が載っていても、すべてのモデルがそれを受け付けるという意味ではありません。Opus 4.7 にはモデル固有の制限を適用します。モデル固有の追加パラメータを別の領域から渡すアダプタも、その送信形式に沿って確認してください。Converse の InferenceConfiguration、Opus 4.7 の制限

例えば、Anthropic Messages API 用の本文は、次のようにサンプリング指定なしで組み立てられます。これは本文の例であり、HTTP ヘッダーや認証を含む実行コードではありません。

{
  "model": "claude-opus-4-7",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "この修正案の問題点を挙げ、必要なテストを説明してください。"
    }
  ]
}

max_tokens は出力上限であり、サンプリング指定の廃止を理由に削除する項目ではありません。上の 1024 は例の上限です。元の作業に必要な上限を維持し、エラー対策として無条件に 64,000 へ増やす必要はありません。Bedrock のネイティブ形式では、本文の anthropic_version など、その経路で必要な項目も残します。上の Messages API の本文を、そのまま全経路へ転用しないでください。Bedrock のネイティブ呼び出し例

自分のアダプタを直す場合の、対象を限定した処理

次の Python は送信処理を含まず、既に組み立てた辞書の指定だけを省きます。実際の送信先とモデルが Opus 4.7 用であると確認できた処理から呼び出す前提です。opus という別名だけで、この分岐を選ばないでください。

from copy import deepcopy

def omit_opus47_sampling(body, request_format):
    result = deepcopy(body)

    if request_format == "native":
        # Messages / Bedrock native: only request-level controls.
        for key in ("top_p", "temperature", "top_k"):
            result.pop(key, None)
    elif request_format == "converse":
        # Converse: retain maxTokens and stopSequences.
        config = result.get("inferenceConfig")
        if config is not None:
            for key in ("topP", "temperature"):
                config.pop(key, None)
    else:
        raise ValueError("Choose the verified request format")

    return result

# Synthetic Converse input: no SDK client or HTTP request.
original = {
    "messages": [{"role": "user", "content": [{"text": "確認してください"}]}],
    "inferenceConfig": {
        "maxTokens": 1024,
        "stopSequences": ["END"],
        "topP": 0.9,
        "temperature": 0.2,
    },
}
cleaned = omit_opus47_sampling(original, "converse")
assert cleaned["inferenceConfig"] == {
    "maxTokens": 1024,
    "stopSequences": ["END"],
}
assert cleaned["messages"] == original["messages"]
assert "topP" in original["inferenceConfig"]

この例は、共通の既定値の合成がすべて終わった位置に置きます。Converse のモデル固有の追加パラメータ領域まで処理する汎用コードではありません。追加領域に旧指定が残る場合は、アダプタが実際に生成する形式を調べて、その指定を作る箇所も修正します。

JSON を再帰的にたどって、top_p や temperature という名前を片端から消す処理は避けます。例えばツールの input_schema.properties.top_p は、ツールが受け取る業務データの項目であり、モデルのサンプリング指定ではありません。メッセージ中の JSON や、利用者が渡した同名の属性もそのまま残します。優先度、停止条件、ツール定義までまとめて消すと、400 がなくなっても元の作業が成立しなくなります。

設定にない top_p が送られるときは、追加された段階を探す

設定ファイルに該当する値が見つからなくても、送信されていないとは限りません。アプリ側の既定値、エージェント別の設定、モデル別オプション、プロバイダ変換、プロキシのどこかで追加されることがあります。自分が管理する処理について、次の順にデータの変化を追います。

1. ユーザー設定を読み終えた時点では、どの指定があるか。
2. 共通設定とモデル別設定を合成した後に、指定が増えていないか。
3. 送信形式への変換後、top_p が topP などへ写されていないか。
4. 実際の送信直前に、対象のサンプリング指定が残っていないか。

比較するのは指定の位置と有無で十分です。認証ヘッダーやプロンプト全文を、調査のために外部へ送る必要はありません。管理できないプロキシの先は、手元の設定だけで「削除済み」と断定せず、その処理を管理する側に確認する範囲です。

実例として、AWS の文書処理サンプルでは、アップロードした設定に指定がなくても、Strands を使うエージェント処理の ConverseStream で top_p 関連のエラーが出たとの報告があります。メンテナーは 2026年5月9日、サンプルの v0.5.10 でモデル判定とパラメータ省略を修正したと説明しています。これはそのサンプルの報告と修正であり、Claude Code 全体に共通する修正版番号ではありません。AWS サンプルの issue #304

OpenCode や独自のエージェントを使っている場合も、Claude Code の設定だけを直して完了とは言えません。OpenCode の公式文書では、モデル側のオプションとエージェント側の上書きを区別しています。実際のクライアントの設定と送信処理を調べてください。これは特定の OpenCode バージョンが top_p を自動挿入するという主張ではありません。OpenCode のモデル設定

復旧の確認は、元の作業が完了するところまで

確認は「リクエストの形」と「作業の結果」に分けます。まず通信を行わない段階で、送信直前のデータから対象指定が省かれ、メッセージ、ツール定義、出力上限、停止条件、対応している優先度の指定などが残っていることを確認します。この確認で分かるのは整形処理の動作までです。

その後、実際の呼び出しを行える環境では、失敗したときと同じモデル、送信先、クライアントの処理で、元の作業をやり直します。API の利用料や権限が関係する場合は、その環境の承認範囲で行ってください。次の点を確認できて初めて、その作業の復旧と判断できます。

• top_p などを理由とするエラーがなくなった。
• 必要なツールが使え、期待していた出力形式や停止条件が保たれた。
• 元の入力に対して、作業の完了条件を満たす結果が得られた。

コード修正なら、単に返答が来たかではなく、必要なファイルの修正やテスト結果まで確認します。ツールを使う処理なら、単純な文章生成に置き換えて成功しても、元のエージェント処理の復旧を証明しません。代表ケースの入力と期待する結果を残すと、後から設定の合成処理が変わった際にも、再発を見つけやすくなります。

別のモデルや別の提供元で動くことを確かめた場合は、代替経路の成功として記録します。元の経路が直ったこととは分けてください。代替モデルを使うなら、ツール、出力形式、品質、応答時間、費用、利用できる機能が元の用途を満たすかも確認が必要です。切り替え先でも、そのモデルと経路固有の仕様を使います。

なお、400 エラーの原因がサンプリングパラメータではなく、assistant メッセージの事前入力（prefill）が使えなくなったことだった場合は、原因も代わりの手順も異なります。そのときは「Claude assistant prefill 400 エラー：非対応モデルと代替手段」を参照してください。

よくある疑問

top_p: 1 や temperature: 0 に変えれば通りますか？

特定の数値を万能な修正値として使うことはできません。Anthropic は Opus 4.7 の非デフォルト値を拒否し、省略を案内しています。Bedrock の Opus 4.7 ではサンプリング指定がサポートされません。null を送ることも、省略とは異なります。SDK に None を渡したときに項目が省かれるのか、JSON の null になるのかは、その SDK のシリアライズを確認する必要があります。Anthropic の案内、Bedrock の仕様

effort は top_p の代わりになりますか？

数値を対応させる代替設定ではありません。output_config.effort は、モデルが回答にかける作業量、丁寧さ、トークンの使い方に影響します。候補トークンの確率を絞る top_p と同じ制御ではなく、出力の完全な一致を保証するものでもありません。400 の修正は旧指定の省略として行い、回答の長さ、必要な根拠、ツールの使用条件などは指示で明確にします。必要なら、そのモデルが対応する effort を元の用途で評価してください。公式の effort 説明

省略したのに、別の 400 エラーになりました。まだ失敗ですか？

新しいエラーの対象を読み直してください。最終リクエストから旧サンプリング指定が消えていれば、その整形は確認できています。ただし、thinking やメッセージ形式など別の不一致が残ることがあり、作業全体の復旧はまだ完了していません。必要な項目まで消して 400 を避けるのではなく、新しいエラーが指す仕様を個別に確認します。

プロバイダを替えると直りました。このままでよいですか？

元の用途を満たすなら、一時的な代替として使う判断はできます。ただし、送信先やモデルを変えた成功は、元の top_p エラーを修正した証拠ではありません。元の経路に戻す予定があるなら、指定を追加していた処理と、同じ作業での確認を残しておきます。