Claude API 2026-10-21移行ガイド|temperatureで400エラー、SDK更新の落とし穴
「temperatureは、このモデルでは非推奨です」(APIが返すエラーメッセージ「temperature is deprecated for this model」の筆者訳)。
この400エラーが返ってきたとき、多くの開発者が最初に疑うのは自分のコードの別の部分だ。ある研究用リポジトリでは、別プロジェクトから流用したドライバーをAnthropicのAPIに向け直したところ、75回の呼び出しがすべて失敗した。そのissueは、症状が「パラメータの問題ではなく、ドライバー全体の停止に見える」と書いている(出典: automated-researcher issue #740、2026年8月16日、原文は英語、日本語は筆者訳。なおこのissueはClaudeを使った自動実行の中で起票されたもの)。
これまでこの症状は、Claude Opus 4.7以降など一部の新しいモデルだけの話だった。2026年10月21日、Anthropicは約3年ぶりとなるAPIバージョン 2026-10-21 を公開し、この扱いをAPIのルールとして全面に広げた。temperature、top_p、top_kは、値が何であれ、送った時点で400エラーになる。
temperature・top_p・top_kは、回答のばらつき具合を調整する設定値(サンプリングパラメータ)だ。temperatureは0に近いほど毎回似た答えになる。400エラーは「リクエストの書き方が不正」という意味の拒否応答を指す。
自分(電脳狐影)はエンジニアではなくPMだ。APIを使う側のPMとして気になるのは「いつ、何が、勝手に壊れるのか」だ。この記事では、移行で何が変わるのか、誰が今すぐ動くべきか、そして2023-06-01に残る判断基準を整理する。
- Claude APIをSDKや直接のHTTPリクエストで使っている方
temperature: 0で出力を安定させるコードを書いた覚えがある方- Dependabot や Renovate でSDKを自動更新している方
- 自前のプロキシやAPIゲートウェイでAPIキーを扱っている方
- 今日すぐ壊れるわけではない: 旧バージョン2023-06-01は非推奨になっていない。SDKのメジャー更新かヘッダー変更で初めて切り替わる
- 一番多い落とし穴:
temperature/top_p/top_kは送るだけで400エラー。既定値でも不可 - 見落としやすい落とし穴: 新SDKはAPIキーを
Authorization: Bearerで送る。X-Api-Keyを見ているプロキシやログのマスキングは要修正 - 移行の補助: Claude Code v2.1.307の
/claude-api api-version - 筆者の判断: SDKの自動更新はメジャーだけ止め、Sonnet 4.6で温度を下げている処理だけは2023-06-01に残す
- 上司への一言: 「今すぐ止まるリスクは低い。SDKの自動更新を止め、temperature等の使用箇所を棚卸しする」
Claude API 2026-10-21で変わった3つのこと
公式の移行ガイドが挙げる破壊的変更(既存のコードが動かなくなる変更)は、Messages APIに関して3つある(出典: Migrating to API version 2026-10-21)。対象はMessages API本体に加えて、トークン数カウントとMessage Batchesの各リクエストだ。
| 変更 | 2026-10-21での挙動 | 影響を受けるケース |
|---|---|---|
| サンプリングパラメータの削除 | temperature / top_p / top_k を送ると400エラー(既定値でも) | 出力のばらつきを調整していたコード、ラッパーが自動で付けるケース |
| assistantメッセージ内のdocumentブロック | 400エラー。documentはuserメッセージで送る | 会話履歴にPDFなどを差し込む独自実装 |
| userメッセージ内のcitations | 空でない citations を持つtextブロックは400エラー | 引用付きの過去の回答を加工して送り直す実装 |
なお、Claudeが返したweb fetchツールの結果のように、別のブロックの中に入ったdocumentは引き続き受け付けられる。assistantメッセージのcitationsや、documentに付ける "citations": {"enabled": true} の設定も従来どおりだ。
このほか、Admin APIとClaude Enterprise Analytics APIでフィールド名が変わった。たとえばAPIキーの workspace_id はなくなり scope に置き換わる。組織管理のスクリプトを書いている人は、移行ガイドの対応表を一度確認しておきたい。
temperatureで400エラーになる条件と影響はモデルで違う
ここが今回いちばん誤解されやすい。公式の移行ガイドは、パラメータを外したリクエストは temperature 1.0を含む既定値でサンプリングされ、2023-06-01でパラメータを省いた場合と同じだと説明している。
影響は使っているモデルで分かれる。
- Claude Opus 4.7以降など: もともと既定値しか受け付けない。公式リリースノート(2026年5月28日)は、既定値以外を指定するとOpus 4.8でも4.7と同じく400エラーになると書いている。つまり削除しても出力の傾向は変わらない
- Claude Sonnet 4.6など値を変えられるモデル: 出力を安定させるために温度を下げていた場合、その効果がなくなる。移行ガイドは「ほかの設定で置き換えることはできない」と明記している
修正自体は、多くの場合1行消すだけだ(Python SDKの例)。
# 修正前(2026-10-21では400エラー)
client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
temperature=0,
messages=[{"role": "user", "content": "この問い合わせを分類して"}],
)
# 修正後(temperatureの行を削除)
client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": "この問い合わせを分類して"}],
)
PMとしての理解では、要するに「Claude Opus 4.7以降の新しいモデルでは温度をいじる設計がすでに終わっていて、今回それがAPI全体のルールになった」ということだ。新しいモデルで温度を指定して怒られていた人にとっては、ルールが揃っただけの話になる。
一方、Sonnet 4.6で分類や採点を temperature: 0 で回していた人は話が違う。出力のばらつきが増える可能性があるので、移行の前後で同じ評価セット(同じ入力で結果を比べるテスト用データ)を流して差を見ておきたい。どうしても低温度が必要なら、移行ガイドどおり、そのリクエストだけ2023-06-01に残すことになる。
ライブラリが勝手に付けている場合がいちばん厄介
自分のコードに temperature と書いていなくても安心できない。
paperless-gpt(書類管理ツール)のissueでは、ユーザーのSoulplayerが「temperature フィールドが含まれた瞬間に400が返る」と報告している。設定で温度を指定していないのに、内部で使っているライブラリ(langchaingo)が既定値を送っていたのが原因とみられ、後から書き込んだstrackmも「v0.29.0でもまだ起きている」と続けている(出典: paperless-gpt issue #1003、2026年7月〜10月、原文は英語、筆者訳)。これは2026-10-21以前のClaude 5世代での話だが、同じ構造の問題が今後はAPIバージョン単位で起きることになる。
SQL Lens(データベースを扱うMCPサーバー)でも、常に temperature=0.7 を送る実装のせいで、Claude Opus 5.5を指定するとすべての問い合わせが失敗していた。2026年10月21日に起票されたissueでは、温度を「未設定なら送らない」に変え、代わりに effort(推論の深さ)を設定できるようにする修正PRが作られ、issueは同日中にクローズされている(出典: sqllens issue #262)。
DEV Communityの解説記事には、ラッパーライブラリや共通のクライアント生成処理が呼び出し元の変更なしにサンプリングパラメータを差し込むことがあるので、送信するペイロード(APIに送る本文データ)に3つのキーが含まれないことを確かめるテストを書くべきだ、という読者Jessica Williamsのコメントが付いていた(出典: Claude API 2026-10-21: What Breaks and How to Upgrade - DEV Communityへの読者コメント、2026年10月22日、原文は英語、筆者要約)。地味だが、いちばん効く対策だと思う。
SDKのメジャー更新が「切り替えスイッチ」になる
今回の移行は、SDKを使っている人にとっては「バージョンを上げた瞬間」に起きる。公式リリースノート(2026年10月21日)によると、2026-10-21を既定で送るのは次のバージョンだ(出典: Claude Platform Release notes)。
| 言語 / ツール | 2026-10-21を既定で送るバージョン |
|---|---|
| Python SDK | 2.0.0 |
| TypeScript SDK | 1.0.0 |
| C# SDK | 13.0.0 |
| Go SDK | 2.0.0 |
| Java SDK | 3.0.0 |
| PHP SDK | 1.0.0 |
| Ruby SDK | 2.0.0 |
| ant CLI | 2.0.0 |
旧メジャーのSDKは引き続き2023-06-01を送る。SDKを使わずにHTTPで呼んでいる場合は、anthropic-version ヘッダーを 2026-10-21 に変えたときだけ切り替わる。
ここで注意したいのが依存関係の自動更新だ。DependabotやRenovate(依存ライブラリを自動で更新するツール)でメジャー更新まで自動マージする設定にしていると、ある朝、誰もコードを触っていないのに本番で400エラーが出る、ということが起こりうる。PMの立場から見ると、これが今回いちばん現実的な事故のパターンだと考えている。
新SDKにはAPIバージョンと関係のない破壊的変更も入っている。たとえば MessageParam が「user / assistant / system」の役割ごとの型に分かれた。Python SDKでは MessageParam(role="user", content="Hello") のように呼び出すと TypeError になり、辞書で書く必要がある。辞書のリテラルで書いていたコードはそのまま動く。ライセンスもMITからApache 2.0に変わった(出典: Claude Platform Release notes、2026年10月21日)。
ant CLIもメジャー更新の対象
ant CLIは2.0.0で2026-10-21に切り替わる。YAMLでClaude Agentを管理する使い方はこちらで整理した。
APIキーがAuthorization: Bearerで送られる
APIキーを、リクエストのどの欄(ヘッダー)に載せて送るかが変わる。個人的にいちばん見落としやすいと思ったのがこれだ。
新しいSDKとCLIは、APIキーを X-Api-Key ヘッダーではなく Authorization: Bearer <key> で送る。移行ガイドは、X-Api-Key を読んだり付けたりしているプロキシやゲートウェイ、さらに自分のプログラム内のミドルウェア、ログのフィルター、テスト用のスタブも直すよう求めている。Claude API自体はどちらのヘッダーでも受け付ける。
気をつけたいのは「ログのフィルター」の部分だ。ここからは筆者の推測になるが、X-Api-Key だけを伏せ字にするログ設定のままSDKを上げると、今度は Authorization ヘッダーに入ったキーがログに残るかもしれない。エラーは出ないので気づきにくい。APIキーを扱うゲートウェイを自作している人は、移行前にマスキング対象のヘッダーを確認しておきたい。なお、これは一般的な注意喚起であり、個別の環境の安全性を保証するものではない。
移行の手順:Claude Codeに任せる部分と人が見る部分
公式の移行ガイドが示す順番はシンプルだ。
- SDKを上の表のバージョンに上げる(またはヘッダーを
2026-10-21にする) - 破壊的変更とSDKの変更点のうち、自分に関係するものを直す
- 2026-10-21に対してテストしてからリリースする
ガイドは、1と2を一緒にリリースするよう書いている。SDKだけ先に上げると、該当するパラメータやブロックを送っているリクエストが400エラーになりうるためだ(この理由づけは筆者の解釈)。
旧バージョンに残したい処理は、SDKを旧メジャーのまま固定する(Pythonなら anthropic<2.0.0)か、HTTPで直接呼んでいるなら anthropic-version: 2023-06-01 のまま送ればいい。
コードの書き換えは、Claude Code v2.1.307(2026年10月21日)で追加された /claude-api api-version に任せられる(出典: Claude Code changelog)。Claude APIのコードを2026-10-21へ移すためのコマンドだ。ただし、自分ならテストまでは任せきりにしない。前述のとおり、温度の削除は「エラーが消える」だけでなく「出力の性質が変わる」可能性があるので、そこは人が評価結果を見て判断したい。
もう一つ、Amazon Bedrock経由の場合、2026-10-21はClaude 4.7以降のモデルでしか使えない。それより前のモデル(Opus 4.6以前など)をBedrockで呼んでいるなら、今のSDKバージョンのまま据え置くよう移行ガイドは案内している。
- 今のSDKのバージョンを確認する(
pip show anthropic/npm ls @anthropic-ai/sdk) - コード全体を
temperature/top_p/top_kで検索する(ラッパーや設定ファイルも含む) - 送信ペイロードに3つのキーが含まれないことを確認するテストを書く
X-Api-Keyを参照しているプロキシ、ミドルウェア、ログのマスキング、テストスタブを洗い出す- Sonnet 4.6などで温度を下げていた処理は、移行前後で同じ評価セットを流して比較する
- SDKの自動更新でメジャー更新を自動マージしない設定にする
- Bedrockで旧モデルを使っているなら、SDKを据え置く
自分(電脳狐影)の移行判断:今日やること・残すもの
正直に言えば、新バージョンに急いで移る理由は、今のところ大きくない。2023-06-01は非推奨になっておらず、新しいモデルではもともと温度を変えられなかったからだ。
それでも、自分なら次の順で動く。
- 今日やる: 依存関係の自動更新で、Anthropic SDKのメジャー更新だけは自動マージを止める。勝手に切り替わるのがいちばん怖い
- 今週やる: コードとライブラリの設定から
temperatureなどを洗い出す。Opus 4.7以降の新しいモデルしか使っていない処理は、消すだけで済む - 移行するとき: SDK更新と修正を同じリリースにまとめ、
X-Api-Keyまわりを先に直す - 残すもの: Sonnet 4.6で
temperature: 0に頼っている採点や分類の処理は、2023-06-01のまま残し、モデル更新のタイミングで設計ごと見直す
わからない点もある。2023-06-01がいつまで使えるのかについて、2026年10月23日時点で公式の案内は見当たらなかった。非推奨のスケジュールが出たら、そのとき改めて移行計画を立てればいい。
モデル移行でエラーになる項目も合わせて確認
Sonnet 4.5は11月30日に廃止予定。Sonnet 5.5へ移行するときにエラーになる7項目を整理した。APIバージョン移行と同時に進める人向け。
関連記事
- Claude Sonnet 4.5廃止は11月30日|Sonnet 5.5移行でエラーになる7項目
- Claude旧モデル一斉終了|Haiku 3は4月19日廃止、移行しないとAPI停止
- Claude APIの拒否はHTTP 200|stop_reason refusalとfallbacks実践ガイド
- Anthropic公式『ant CLI』徹底ガイド|YAMLでClaude AgentをGitOps運用する
- Claude Opus 4.7 完全ガイド|SWE-bench 87.6%・xhigh effort・/ultrareview
- AnthropicがStainlessを買収へ|OpenAI・GoogleのSDKが競合管理下に
免責事項
- 本記事の情報は2026年10月23日時点のものです。最新の仕様は公式の移行ガイドとリリースノートを参照してください。
- GitHub、DEV Communityからの引用は各投稿者の環境における報告で、筆者が再現検証したものではありません。英語の引用は筆者による翻訳で、意訳を含みます。
- ログのマスキングに関する記述は、公式の移行ガイドの記載をもとにした筆者の推測を含みます。
- 移行作業は公式ドキュメントと自身の環境を確認したうえで行ってください。本記事の情報に基づく変更で生じた損害について、筆者は責任を負いません。
- 本記事はAnthropic社およびその関連会社と提携・提供関係にあるものではなく、内容は筆者独自の見解です。本記事にアフィリエイトリンクは含まれません。
※ 記載の会社名・製品名は各社の商標または登録商標です。