/claude-api api-versionでAPIバージョンを2026-10-21へ上げる手順

Claude Codeの同梱スキル /claude-api に、サブコマンド api-version が加わりました。Claude APIのコードを新しいAPIバージョン 2026-10-21 に合わせて直し、そのうえでリクエストをそのバージョンへ切り替えるコマンドです。必要なのはClaude Code v2.1.307以降です。

コマンドを打つだけで済む作業ではありません。2026-10-21 には、送ると400になるパラメーターの削除やSDKのメジャーバージョン更新が含まれます。この記事では、実行前の確認、実行の流れ、差分の読み方、切り替え後の検証を順に並べます。

/claude-api api-versionは何をするコマンドか

スキルのドキュメントでは、api-version を「Claude APIのコードを新しいAPIバージョンに合わせて更新し、そのうえでリクエストをそのバージョンへ切り替える」ものと説明しています。ほかのサブコマンドとの違いは、動かす対象です。

upgrade の手順はPython SDKをv0.xからv1へ移行する記事に書いています。api-version の対象になる 2026-10-21 では、移行ガイドが示すPythonの対象版は anthropic 2.0.0です。v1に上げた後に、もう一度メジャーバージョンを上げる流れになります。

ドキュメントに載っている説明は上の一文だけで、コマンドの内部手順や、どのファイルを書き換えるかの記載はありません。そのため、実行後は差分を自分で読む前提で進めます。

実行前に確認する3つの条件

Claude Codeのバージョンはv2.1.307以降か

api-version はv2.1.307で加わったサブコマンドです。それより古い版では使えません。

claude --version

Amazon Bedrockで古いモデルを呼んでいないか

2026-10-21 をAmazon Bedrockで使えるのは、Claude 4.7以降のモデルです。Claude Opus 4.6以前のモデルをBedrockで呼んでいる呼び出しは、今のSDK版か今のバージョン指定のまま残します。そのモデルを 2026-10-21 に移すには、先にClaude 4.7以降のモデルへ切り替えます。

Claude API、Claude Platform on AWS、Microsoft Foundry、Google Cloudの各経路では、2026-10-21 を使えます。

temperatureなどを固定で渡していないか

2026-10-21 では、temperature、top_p、top_k を送るリクエストが、どのモデルでも400になります。既定値と同じ値を渡していても同じです。実行前に、手元のコードで使っている箇所を数えておくと、差分の確認が速くなります。

grep -rnE "temperature|top_p|top_k" --include="*.py" --include="*.ts" .

実行して差分を読む手順

/claude-api api-version

コマンドの後に、次のように確認を頼む使い方も考えられます。以下は筆者が組んだ依頼文の例で、公式の例ではありません。

今の差分に、temperature・top_p・top_k の送信が残っていないか
全ファイルで確認して。Bedrock経由で旧モデルを呼ぶ箇所は
SDKを上げず、どのファイルかを一覧にして。

差分で確認する6つの変更点

移行ガイドが挙げる破壊的変更のうち、アプリのコードに関係しやすいものを表にしました。

リクエストの中身に関わる上の3行は、移行ガイドでMessages API、トークンカウント、Message Batchの各リクエストに適用されると説明されています。Messages APIを使わないコードは影響を受けません。

documentブロックには例外があります。Claudeが返したWeb fetchツールの結果のように、別のブロックの中に入れ子になったdocumentは、今までどおり受け付けられます。また、assistantメッセージにあるtextブロックの citations、つまりClaudeの前の返答をそのまま送り返すケースも、今までどおりです。

Admin APIとClaude Enterprise Analytics APIには、別にフィールド名の変更があります。たとえばRBACグループの roles は role_ids になり、APIキーの workspace_id は scope.workspace_id で読みます。管理系のAPIを呼ぶスクリプトを持っているなら、こちらも確認の対象です。

temperatureに頼っていたリクエストはどうするか

temperature を外すと、リクエストは既定値で動きます。temperature の既定は1.0で、2023-06-01 でパラメーターを省略した場合と同じです。

非既定値に頼るリクエストが残る場合の選択肢は2つです。パラメーターを送らないか、そのリクエストだけ 2023-06-01 に置いておくかです。Sonnet 5の400がどう見えるかはClaude Sonnet 5のtemperatureが400になる理由に書いています。

SDKのバージョンを上げる

SDKを使っている場合、リクエストのAPIバージョンは、そのSDKのメジャーバージョンが出た時点の最新で決まります。2026-10-21 を送る最初のバージョンへ上げる必要があります。

罠になりやすい点を、言語別に挙げます。

• TypeScript: @anthropic-ai/bedrock-sdk や @anthropic-ai/vertex-sdk など5つのプラットフォーム用パッケージは、同じタイミングで1.0.0へ上げます。揃えないと、パッケージマネージャーが古い @anthropic-ai/sdk を2つ目として入れます。
• Go: メジャーバージョン2からはモジュールパスの末尾に /v2 が付き、importの書き換えが全ファイルに及びます。CLIを go install で入れている場合も、パスに /v2 を足します。旧パスは、エラーも警告もなくv1の最新を入れ続けます。
• PHP: composer update だけでは、今の版の制約の範囲に留まります。composer require "anthropic-ai/sdk" で上げます。

curlなどSDKを使わない場合は、anthropic-version ヘッダーを 2026-10-21 にします。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2026-10-21" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }'

ヘッダーの役割はanthropic-versionヘッダーの解説にまとめてあります。

SDKを上げるとAPIキーの送り方が変わる

新しいSDKとCLIは、APIキーを X-Api-Key ではなく Authorization: Bearer <key> で送ります。Claude APIはどちらのヘッダーでもキーを受け付けるので、API自体は動き続けます。壊れるのは、X-Api-Key を読む側です。

• 社内のプロキシやゲートウェイ
• ログのフィルター
• テストのスタブ

こうした箇所で X-Api-Key を前提にしていないか確認します。自分でキーを X-Api-Key に載せ直す方法も、移行ガイドに言語別の例があります。

SDKのクライアントは、認証情報を1つしか持たなくなりました。Pythonでは api_key と auth_token を同時に渡すと ValueError になります。ゲートウェイ用のトークンとAPI用のキーを両方送っていた構成は、移行ガイドの該当節の手順で組み直します。

切り替え後に確認すること

コマンドの実行後は、テストに加えて、古い書き方が残っていないかを機械的に探します。次のコマンドは筆者が組んだ確認の例です。

# 400になる3パラメーターの残り
grep -rnE "temperature|top_p|top_k" src/
# X-Api-Keyを前提にした処理の残り
grep -rniE "x-api-key" src/ infra/
# 削除されたTypeScript SDKのtool runnerオプション
grep -rn "compactionControl" src/

compactionControl を探す理由は、TypeScriptとRubyのSDKでクライアント側のcompactionがtool runnerから削除されたためです。サーバー側のcompactionへ移す手順は移行ガイドにあります。

リクエストが400で返ってきたら、まず3つのパラメーターと、user メッセージの citations を疑います。

つまずきやすい点

• コマンドが 2026-10-21 に切り替える範囲と、Bedrockの旧モデルの範囲がぶつかる。呼び出し先のモデルを先に洗い出す
• Goはimportパスの書き換え、PHPは composer require と、言語ごとに上げ方が異なる
• temperature を外した結果、出力のばらつきが増えたように見える。Claude 4.7より前のモデルでは設定の効果が消えるため、挙動の変化は想定内
• SDKのライセンスはApache 2.0に変わった。コードの変更は不要だが、依存のライセンスを管理しているなら記載を更新する

まとめ

/claude-api api-version は書き換えの起点で、完了を保証するものではありません。差分を移行ガイドの変更点と突き合わせ、Bedrockの旧モデルを除外し、temperature に頼る呼び出しを個別に判断するところまでが、人の作業です。

先に決めておくと迷わないのは次の1点です。temperature を非既定値で使っているリクエストがあるなら、外すのか、2023-06-01 に残すのかを、実行の前にリクエスト単位で決めておきます。リリースの手順や他のサブコマンドとの関係は、v2.1.307のリリースノートが併せて参考になります。