Claude APIのバージョン 2026-10-21 は、Anthropicが2026年10月21日に公開した新しいAPIバージョンです。2023-06-01 から約3年ぶりの更新で、temperature・top_p・top_k を送ると既定値でも400エラーになります。同じ日にPython SDK 2.0.0やTypeScript SDK 1.0.0など7言語のSDKとCLIがメジャー更新され、APIキーの送り方も Authorization: Bearer に変わりました。この記事では公式の移行ガイドをもとに、壊れる箇所の洗い出し方、書き換えコード、Amazon Bedrock経由で上げられない条件、移行を見送る判断までを実装者向けに整理しました。
まとめ:Claude API 2026-10-21移行で先に直す箇所と移行を急がない構成
最初に確認するのは、リクエストに temperature・top_p・top_k を入れている箇所です。2026-10-21ではこの3つを送った時点で400になり、代わりの設定もありません。低い temperature で出力のぶれを抑えていた処理は、パラメータを外すか、その処理だけ2023-06-01に残すかを決めます。
SDKを新しいメジャー版に上げると、送信するAPIバージョンは自動で2026-10-21に変わります。APIキーのヘッダーも X-Api-Key から Authorization: Bearer に移るので、自前の中継サーバーやログのマスク処理はSDKより先に直す必要があります。
急がなくてよいのは、Amazon BedrockでClaude Opus 4.6以前のモデルを呼んでいる構成です。Bedrockでは2026-10-21がClaude 4.7以降のモデルでしか使えません。旧バージョンの提供終了日は、2026年10月24日時点の公式ドキュメントに書かれていない状態です。期限に追われる移行ではないため、テストを済ませてから切り替えれば足ります。
2026-10-21で変わる範囲:Messages APIの400と管理APIと対応SDK
Claude APIは、リクエストごとに anthropic-version ヘッダーでAPIバージョンを指定する方式です。バージョン履歴のページには、2023-01-01(初版)と2023-06-01に続く3つ目の版として2026-10-21が載っています。同じ版の中では既存の入力・出力パラメータが保たれるため、破壊的変更が起きるのは版を切り替えたときだけです。
Messages APIで400になる3種類のリクエストと影響を受ける書き方
Messages API(POST /v1/messages)では、次の3種類が400エラーになります。トークン数の計測と、2026-10-21で作ったMessage Batchの各リクエストも同じ扱いです。
| 400になる送り方 | 2026-10-21での直し方 |
|---|---|
| temperature等の3種を送る | 3つとも外す(既定値でも400) |
| assistant側にdocumentを置く | 文書はuser側で送る |
| user側にcitationsを付ける | citationsを外して送る |
件数が多くなりやすいのは1行目です。会話履歴を保存して再送する設計では2行目と3行目も効くため、再送前の整形処理を見直してください。Web fetchツールの結果のように別ブロックの中に入った文書と、assistant側の citations は引き続き受け付けられます。
Admin APIとAnalytics APIで名前が変わる応答項目7つ
管理系のAPIでは、改名された項目の旧名が応答から消えます。集計を自動化していると、読み取り側が空値のまま動き続けかねません。
| 対象 | 旧名 | 新名 |
|---|---|---|
| RBACグループ | roles |
role_ids |
| RBACグループのメンバー | group_id |
rbac_group_id |
| RBACロール | name |
display_name |
| レート制限 | group_type |
group.type |
| APIキー | workspace_id |
scope |
| ユーザー別の利用量・費用 | actor.email |
actor.email_address |
| アクティビティサマリー | summaries |
data |
APIキーの workspace_id は意味も変わりました。2023-06-01ではDefault Workspaceに紐づくキーが null でしたが、2026-10-21では scope.workspace_id に実際のIDが入ります。null をDefault Workspaceと見なしていたコードは、ワークスペース一覧を include_default=true で取得し、名前が "Default" のIDと比べる形に書き換えます。
2026-10-21を送るSDKの対応版一覧とPython・TypeScriptの公開日
SDKは、メジャー版を出した時点のAPIバージョンを送ります。2026-10-21を送るのは次の版からです。
| 言語・ツール | パッケージ | 最初の対応版 |
|---|---|---|
| Python | anthropic | 2.0.0 |
| TypeScript | @anthropic-ai/sdk | 1.0.0 |
| C# | Anthropic | 13.0.0 |
| Go | anthropic-sdk-go v2 | 2.0.0 |
| Java | anthropic-java | 3.0.0 |
| PHP | anthropic-ai/sdk | 1.0.0 |
| Ruby | anthropic | 2.0.0 |
| CLI | ant | 2.0.0 |
PyPIでは2.0.0が10月21日に出て23日に2.3.0まで進み、npmの最新も24日時点で1.3.0です。1系の最終版(Pythonは1.17.0)は2023-06-01を送り続けるので、SDKの版を固定しているシステムは何も変わりません。新しい版からライセンスがMITからApache License 2.0に変わった点は、依存ライブラリのライセンス台帳を持つ組織だけが対応すれば済みます。料金体系とAPIキーの取得手順はAnthropic API(Claude API)の料金とAPIキー取得方法で扱っています。
作業1:temperature・top_p・top_kを外して400エラーを止める書き換え
移行で最も件数が多くなりやすいのが、サンプリングパラメータの削除です。送った時点で値に関係なく400になります。
既定値のtemperature=1.0でも400になる仕様と出力が変わるモデル
移行ガイドによると、3つのパラメータを外したリクエストは temperature 1.0を含む既定値でサンプリングされます。2023-06-01でパラメータを送らなかった場合と同じ結果です。Claude 4.7以降のように、もともと既定値しか受け付けないモデルは挙動が変わりません。
出力が変わるのは、既定以外の値を受け付けるモデルで値を下げていた処理です。移行ガイドはClaude Sonnet 4.6を例に挙げ、出力をそろえるために下げていた temperature の効果は失われ、代わりの設定もないと明記しています。Sonnet 5.5での扱いはClaude Sonnet 5.5の破壊的変更5点、Haiku 5.5での扱いはClaude Haiku 5.5の移行手順にもまとめました。
洗い出しはリポジトリ全体の検索から始めます。設定ファイルや環境変数で値を渡している場合もあるため、コードだけでなく設定の置き場所も対象です。
# サンプリングパラメータを送っている箇所を洗い出す(設定ファイルも含める)
grep -rnE "temperature|top_p|top_k" --include="*.py" --include="*.ts" --include="*.json" --include="*.yaml" .
# Python:2026-10-21では3つとも外す
# 変更前
resp = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
temperature=0.2,
messages=[{"role": "user", "content": prompt}],
)
# 変更後
resp = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": prompt}],
)
SDKの新しいメジャー版には3つの引数自体がありません。外し忘れはAPIに届く前に型チェックや実行時エラーで見つかるため、テストを流せば漏れは残りにくい作りです。
出力のぶれを抑えていた処理を2023-06-01に残す判断基準
分類や抽出のように、毎回同じ答えを返す前提の処理は注意が要ります。temperature を0付近に下げてSonnet 4.6などで動かしていた場合、パラメータを外すだけで判定結果が揺れるかもしれません。
基準は単純です。既定以外の値に依存するリクエストは、検証が済むまで2023-06-01に残します。移行ガイドも、外すか、そのリクエストを2023-06-01に残すかの二択を示しています。SDKはメジャー版ごとに送るバージョンが決まっているので、SDK経由の呼び出しを残すなら、その処理を持つサービスだけSDKを1系に固定するのが確実です。ただし残すのは時間稼ぎにすぎず、出力をJSONスキーマで固定する、選択肢から選ばせる、といったプロンプト側の作りに移すのが本来の解決になります。
作業2:SDKのメジャー更新で変わる型・認証ヘッダー・資格情報の扱い
SDKを上げると、送信内容とは別にコードの書き方にも破壊的変更が入ります。新しい版の使い方はPython SDKのリポジトリとTypeScript SDKのリポジトリでも確認できます。
MessageParamがuser・assistant・systemの3型に分かれる変更
これまで1つだった MessageParam は、UserMessageParam・AssistantMessageParam・SystemMessageParam の合併型になりました。送信されるJSONは変わりません。
Pythonでは、辞書で書いたメッセージはそのまま動きます。壊れるのは型を関数として呼ぶ書き方で、2.0.0では TypeError です。TypeScriptでは、合併型を extends で継承したインターフェースがコンパイルできなくなるため、type StoredMessage = Anthropic.MessageParam & { id: string } のような型エイリアスに書き換えます。
# Python 2.0.0:型を呼び出す書き方は TypeError になる
# 変更前
message = MessageParam(role="user", content="Hello")
# 変更後(辞書で書き、注釈で型を付ける)
message: MessageParam = {"role": "user", "content": "Hello"}
APIキーがAuthorization: Bearerで送られる変更と中継サーバーの修正
新しいSDKとCLIは、APIキーを Authorization: Bearer ヘッダーで送ります。Claude API本体はどちらのヘッダーも受け付けるため、SDKから直接APIを呼ぶ構成では何も起きません。
問題になるのは、SDKとAPIの間に社内の中継サーバー(APIゲートウェイやプロキシ)を置いた構成です。X-Api-Key を読んで利用者の判別や利用量の記録をしている中継は、SDKを上げた瞬間にキーを見つけられなくなります。中継側を Authorization も読めるように直すのが本筋で、それまでの間はPython SDK側でキーを旧ヘッダーに戻す手もあります。
# Python 2.x:中継サーバーが X-Api-Key しか読めない間の回避策(移行ガイド掲載の方法)
import httpx2
from anthropic import Anthropic, DefaultHttpxClient
api_key = "..." # 実運用では環境変数から読む
def send_x_api_key(request: httpx2.Request) -> httpx2.Request:
if request.headers.get("Authorization") == f"Bearer {api_key}":
del request.headers["Authorization"]
request.headers["X-Api-Key"] = api_key
return request
client = Anthropic(api_key=api_key, http_client=DefaultHttpxClient(auth=send_x_api_key))
見落としやすいのはログのマスク処理です。X-Api-Key だけを伏せ字にする設定のままだと、Authorization ヘッダーのキーがログに平文で残ります。中継サーバー、アプリのミドルウェア、テスト用のスタブの3か所は、SDKを上げる前に点検しておきます。
api_keyとauth_tokenの同時指定がエラーになる1クライアント1資格情報
APIキーと認証トークンが同じヘッダーを使うようになったため、1つのクライアントが持てる資格情報は1つだけです。Pythonで api_key と auth_token を両方渡すと ValueError になります。1系では両方を別々のヘッダーで送っていました。
コードで何も渡さない場合、環境変数は ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN の順に見られ、最初に見つかった1つだけが使われます。両方が設定されていると、警告を1回出したうえでAPIキーを使う仕様です。
Go・C#・Java・PHP・Ruby・CLIで個別に壊れる箇所と直し方
Goはモジュールパスが github.com/anthropics/anthropic-sdk-go/v2 に変わり、Go 1.25以上が必須になりました。importを書き換えない限り2.0.0には上がりません。CLIも同じ仕組みで、移行ガイドによると go install のパスに /v2 を足さないと、エラーも警告も出ないまま1系の最新版が入り続けます。
C#・Java・PHP・Rubyは MessageParam の組み立て方が言語ごとに変わり、Javaなら MessageParam.ofUser(...) を使う形です。CLIは --api-key と --auth-token フラグが削除されたため、環境変数か --api-key-stdin で渡します。
作業3:Amazon Bedrockと旧機能の利用で2026-10-21に上げられない条件
呼び出し経路によっては2026-10-21に上げられません。SDKを上げる前に経路とモデルを確かめます。
BedrockではClaude 4.7以降に限られる2026-10-21の提供範囲
2026-10-21はClaude API、Claude Platform on AWS、Google Cloud、Microsoft Foundryで使えます。一方Amazon Bedrockでは、Claude 4.7以降のモデルにしか提供されません。Opus 4.6以前のBedrock向けページに載っているモデルを呼んでいるなら、移行ガイドの指示どおり今のSDKの版に留まります。
SDKのBedrock向けクライアントを使っている場合、SDKを上げるとBedrock向けの送信も2026-10-21に変わります。先にモデルをClaude 4.7以降へ切り替え、そのあとでSDKを上げる順番です。4.7世代の仕様はClaude Opus 4.7の性能と料金で確認できます。Sonnet 4.5のAPI廃止のように提供終了が近いモデルなら、モデル更新とAPIバージョン更新を1回の作業にまとめます。
TS・Rubyのcompaction削除とText Completionsの廃止
TypeScriptとRubyのSDKでは、ツールランナーのクライアント側compaction(会話履歴の要約)が削除されました。TypeScriptの compactionControl は、サーバー側のcompactionを使う context_management の指定に置き換えます。発動のしきい値は5万トークン以上が条件です。
// TypeScript 1.0.0:クライアント側compactionをサーバー側に置き換える
const runner = client.beta.messages.toolRunner({
// ...
betas: ["compact-2026-01-12"],
context_management: {
edits: [{ type: "compact_20260112", trigger: { type: "input_tokens", value: 100_000 } }],
},
});
旧式のText Completions APIも、TypeScript・Go・Java・RubyのSDKとCLIから削除されました。Messages APIへの書き換えが済んでいない処理が残っていれば、SDKより先に片付けます。
同時に出たuser profilesと組織Webhookを移行作業に含める判断
10月20〜21日の公式リリースノートには、エンドユーザーを識別する仕組みも載りました。Claudeを組み込んだサービスを外部に提供している場合は、移行と同時に検討します。
user profilesで利用者ごとに制限の範囲を切り分ける仕組み
user profilesの公式ドキュメントによると、利用者ごとに POST /v1/user_profiles でプロファイルを作り、返ってきた uprof_ で始まるIDを各リクエストの anthropic-user-profile-id ヘッダーに付けます。安全分類器が不正利用を検知したとき、制限や利用停止を組織全体ではなく、そのプロファイルだけに掛けられる仕組みです。プロファイル自体に料金はかかりません。
# Python:API再販先の企業ごとに user profile を作る(自社サービスの利用者なら access_type を省略=application)
import anthropic
client = anthropic.Anthropic()
profile = client.user_profiles.create(
name="Example Corp",
access_type="passthrough",
external_user_details={"reference_id": "tenant-0001", "country": "JP"},
)
print(profile.id) # uprof_ で始まるIDを自社DBに保存し、以後のリクエストに付ける
この作成APIは冪等ではなく、同じ reference_id で呼んでも毎回新しいプロファイルができます。利用者の登録処理で1回だけ呼び、IDを保存する設計にしてください。Amazon BedrockとGoogle管理のGoogle Cloudには /v1/user_profiles がありません。
制限・解除を通知する組織Webhookは、ベータヘッダー webhooks-2026-10-07 が必要な申請制のため移行計画に含めません。当面は enforcement_status でプロファイル一覧を絞り込み、定期的に確かめれば足ります。
移行の順番と見送り判断:本番を止めずに2026-10-21へ切り替える手順
順番を誤ると、APIは正常でも中継サーバーやログが壊れます。作業順に並べ直すと次のとおりです。
中継サーバーの修正からSDK本体の更新まで5段階で進める切り替え順序
- 中継サーバー・ミドルウェア・ログのマスク処理を、
X-Api-KeyとAuthorizationの両方に対応させて先に本番へ出す - リポジトリ全体から
temperature・top_p・top_kを洗い出し、外すものと2023-06-01に残すものを分ける - Bedrock経由の呼び出しを洗い出し、Claude 4.6以前のモデルは4.7以降に切り替えるか、SDKの版を固定する
- SDKを新しいメジャー版に上げ、型エラーと
ValueErrorをテストで潰す(Goはimportパスも置換) - 保存済みの会話履歴を再送するテストを流し、
documentとcitationsの400が出ないことを確かめてから本番に出す
手順1と手順4は別のリリースに分けます。同時に出すと、障害時に中継側とSDK側のどちらが原因か切り分けにくくなります。
今すぐ上げない3つの構成とSDKを上げるだけで済む構成の判断条件
次の構成は、2026-10-21への移行を後回しにします。Bedrockで4.6以前のモデルを使い続ける予定がある構成は、そもそも上げられません。低い temperature に依存した判定処理があり、プロンプトの作り直しが済んでいない構成も見送りです。社外の中継サービスを経由していて、Authorization ヘッダーへの対応状況を確認できない場合も同じ判断になります。
逆に、Claude APIを直接呼び、モデルが4.7以降で、サンプリングパラメータを使っていないシステムは、SDKを上げるだけで作業がほぼ終わります。2.0.0から2.3.0まで3日で版が進んだように、修正は新しいメジャー版の側に入っていきます。こうした構成は早めに上げたほうが後の追従が楽です。
複数のサービスからClaude APIを呼んでいて、中継やパラメータ指定の所在を把握しきれていない場合は、呼び出し経路の棚卸しから始めることになります。API連携部分の設計や改修を外部に相談したい場合は、API開発・システム連携のページをご覧ください。
よくある質問
Claude APIの2026-10-21への移行について、実装の現場で出やすい質問をまとめました。
2023-06-01はいつまで使えますか?
2026年10月24日時点で、公式のバージョン履歴にも移行ガイドにも、2023-06-01の提供終了日は書かれていません。移行ガイドは既定以外の temperature に依存するリクエストを2023-06-01に残す選択肢を示しており、当面は併用できる前提で計画して問題ありません。ただしSDKの1系に固定し続けると、1系の最終版より後に出た修正は受け取れなくなります。APIの変更はリリースノートに日付順で載るので、定期的に確認してください。
SDKを上げずにAPIバージョンだけ2026-10-21にできますか?
HTTPで直接呼んでいる場合は、anthropic-version ヘッダーを 2026-10-21 に変えれば移行できます。対応が要るのはMessages APIと管理系APIの破壊的変更だけで、SDKの型変更は関係ありません。SDKを使っているなら、対応する版へ上げる手順で進めてください。
temperatureを外すと出力の品質は下がりますか?
Claude 4.7以降のモデルは既定値しか受け付けないため変わりません。差が出うるのは、Sonnet 4.6などで低い temperature を指定していた分類・抽出のような判定系の処理です。移行前後で同じ入力を流し、結果を比べてから切り替えてください。
Python SDKの1系から2系へ上げると何が壊れますか?
辞書でメッセージを書き、APIキーだけを渡している素直なコードなら、ほとんど変更なしで動きます。壊れやすいのは、サンプリング引数を渡している箇所、型を関数として呼んでいる箇所、キーとトークンを同時に渡している箇所の3つです。中継サーバーを使っている場合は、認証ヘッダーの変更もあわせて確認してください。
ライセンスがApache 2.0になると何か手続きが必要ですか?
コードの変更は不要で、旧版はMIT Licenseのまま残ります。必要なのは、依存ライブラリのライセンス台帳を持つ組織での記載変更だけです。Javaでは com.anthropic の全成果物が対象で、TypeScriptのBedrock・Vertex向けパッケージはそれぞれの1.0.0でライセンスが切り替わります。
関連記事
- Anthropic API(Claude API)の料金とAPIキー取得方法:APIの料金体系、APIキーの取得手順、漏えい時の無効化手順を確認できます。
- Claude Haiku 5.5とは?Haiku 4.5からの移行手順:既定以外のtemperatureが400になるモデルへ移るときの書き換えを扱っています。
- Claude Sonnet 4.5とは?2026年11月30日のAPI廃止とSonnet 5.5への移行手順:モデルの提供終了とAPIバージョン更新を同時に進める場合の前提を確認できます。
- Claude Agent SDK(旧Claude Code SDK)とは?使い方・移行・料金を解説:Messages APIのSDKとは別に、エージェント向けSDKの使い方と移行を扱っています。