3年ぶりの「版」が、温度のつまみを取り外した──Claude APIが 2026-10-21 で temperature/top_p/top_k を廃し、SDKを一斉に世代交代させた

Anthropic が Claude API に、2023-06-01 以来はじめてとなる新しいバージョン「2026-10-21」を追加しました。目玉は機能追加ではなく「削除」です。これまで出力のばらつきを調整してきた3つのサンプリング用パラメータ temperature / top_p / top_k が、新バージョンでは受け付けられなくなりました。あわせて主要8言語のSDKが同時にメジャーバージョンを上げ、Claude Code にも移行用コマンドが加わっています。開発者にとっては「細かな挙動制御の手段がひとつ減る」変更であり、既存アプリの前提を見直す必要が出てきます。

送るだけで 400 になる、3つのつまみ

新バージョン 2026-10-21 では、Messages API・トークンカウント用エンドポイント・Message Batches のいずれに対しても、以下のパラメータを含むリクエストがエラー（HTTP 400）で弾かれます。注意したいのは、既定値と同じ値を入れていても拒否される点です。「とりあえず付けていた」コードはそのまま動きません。

• temperature（出力の多様性を上下させるつまみ）
• top_p（確率の上位からどこまで候補に含めるか）
• top_k（候補トークン数の上限）

サンプリング系以外にも、メッセージ構造の検証が厳しくなりました。assistant（モデル側）メッセージに document ブロックを直接置くことや、user メッセージ内のテキストブロックや検索結果ブロックに citation 配列を付けることも 400 を返します。document は user 側へ移す必要があります。

では出力はどう振る舞うのか

パラメータを指定しない場合、リクエストは組み込みの既定値で処理されます。既定の temperature は 1.0 相当です。Claude 4.7 のような新しめのモデルは、もともとこの既定でサンプリングしていたため挙動は従来と変わりません。一方で、Claude Sonnet 4.6 のように temperature を下げて使っていたモデルでは、その設定が効かなくなります。Anthropic は代替の設定を用意していないため、「低めの temperature で安定させる」運用は新バージョンでは取れません。

SDKが横並びでメジャー更新、認証方式も変わる

この版の追加に合わせ、公式SDKが一斉にメジャーバージョンを上げ、既定の API バージョンを 2026-10-21 に切り替えました。バージョン番号は言語ごとにばらついているため、更新時は番号の飛びに驚かないようにしておきたいところです。

型定義からは削除された3パラメータが取り除かれ、認証ヘッダも X-Api-Key 方式から Authorization: Bearer 方式へ変わりました。ライセンスも Apache 2.0 へ切り替わっています。SDKを上げる＝新バージョンに乗る、という関係になっているため、依存更新のタイミングがそのまま移行のタイミングになります。

旧版は残る。急がされない移行の道

救いは、旧バージョン 2023-06-01 が非推奨にはなっておらず、これまで通り動き続けることです。直接 API を叩く場合は anthropic-version: 2026-10-21 ヘッダで明示的に新版を選ぶ形で、旧世代のSDKメジャーは引き続き旧版を指し続けます。つまり「SDKを上げない限り、いきなり壊れる」ことはありません。

移行を助ける仕組みも用意されました。Claude Code の v2.1.307 には、手元のコードを新 API バージョンへ寄せる /claude-api api-version コマンドが追加されています。同リリースでは、権限ルールや自動モード・フック・サンドボックスがツール呼び出しを止めた／差し戻した事象を記録する OpenTelemetry イベント safety_event や、接続断時に HTTP MCP のツール呼び出しが二重送信される不具合の修正（再送は読み取り専用・冪等なツールに限定）も入りました。

便利さの裏で、消える「決定論」

この変更には、見落とせない負の面も指摘されています。temperature を下げて出力を安定させる手法は、テストの再現性確保や、構造化データ抽出・分類のように「毎回同じ答えを返してほしい」用途で広く使われてきました。新バージョンにはその代替がないため、再現性を重視するアプリは当面 2023-06-01 に留まらざるを得ないという見方が出ています。「細かい制御はモデル側の既定に任せる」という方向性は、運用を単純にする一方で、これまで開発者が握っていた調整レバーをひとつ手放すことでもあります。自分のユースケースが「既定の temperature 1.0 で許容できるか」を、移行前に見極めておくのが安全です。

ビジネスと開発フローへの含意

今回の動きは、単発のパラメータ削除というより、Anthropic が API のバージョン運用そのものを変えたことの表れです。これまで3年以上ひとつの版で通してきたのを改め、今後はより頻繁に日付つきバージョンを出していくとしています。狙いは、新モデルの投入前に「ここが区切り」という移行の境界をあらかじめ示し、破壊的変更を決まったスケジュールで織り込めるようにすることです。

開発・運用側への実務的な示唆は次の3点に整理できます。

• 依存を上げる前に版を確認する: SDKのメジャー更新は新 API バージョンへの移行とセット。CIやアプリが temperature 等を送っていないか棚卸ししておく。
• 再現性が要るなら版を固定する: 決定論的な出力が必要な処理は、当面 2023-06-01 にピン留めする判断もあり得る。
• バージョン追随を運用に組み込む: 今後は版が頻繁に出る前提で、移行を定期作業として設計に織り込む。

「モデルの細かな挙動は提供側の既定に委ね、アプリは版の切り替えに追随する」という世界観が、少しずつ標準になりつつあります。自分たちが握っていた制御のどれを手放せて、どれは手放せないのか。その線引きを、移行計画の最初の論点に据えておきたいところです。

参照: AlphaSignal「Anthropic Rewrites Claude API After 3 Years, Removing Temperature Controls」 / DEV Community「Claude API 2026-10-21: What Breaks and How to Upgrade」 / Claude Code 公式チェンジログ（v2.1.307） / Classmethod「Claude Code v2.1.307 Major Updates」