APIバージョン2026-10-21への移行
Claude API統合をAPIバージョン2023-06-01から2026-10-21にアップグレードします。インストールするSDKバージョンと、必要なコード変更について説明します。
このガイドでは、APIバージョン2023-06-01から2026-10-21に移行するためのコード変更を一覧で示します。アップグレード手順では、行うべきことを順番に説明しています。
アップグレード手順
2026-10-21に切り替える
SDKを使用している場合、リクエストには、そのSDKのメジャーバージョンがリリースされた時点で最新だったAPIバージョンが使用されます。各言語について示されているバージョンは
2026-10-21を使用する最初のバージョンなので、それらにアップグレードしてください。SDKを使わずにAPIを呼び出している場合は、anthropic-versionヘッダーを2026-10-21に設定してください。anthropicパッケージをバージョン2.0.0にアップグレードします。アップグレードは、次のステップでの修正と一緒にリリースしてください。
破壊的変更に合わせてコードを更新する
「breaking changes」(破壊的変更)を確認し、影響を受ける各変更に合わせてコードを更新してください。また、新しいSDKまたはCLIバージョンで必要なコード変更も行ってください。
2026-10-21に対してテストする
リリース前に、
2026-10-21に対して統合をテストしてください。
破壊的変更
Messages API
これらの変更は、Messages API(POST /v1/messages)へのリクエスト、トークンカウント、および2026-10-21で作成されたMessage Batch内の各リクエストに適用されます。
assistantメッセージ内のdocumentブロックはエラーを返す
assistantメッセージ内にdocumentブロックを直接送信している場合に影響します。
2026-10-21では、assistantメッセージ内にdocumentブロックを直接配置したリクエストは400エラーを返します。代わりに、ドキュメントはuserメッセージで送信してください。Claudeが返したweb fetchツールの結果など、別のブロック内にネストされたドキュメントは引き続き受け付けられます。
userメッセージ内のcitationsはエラーを返す
userメッセージ内のtextブロック(search_resultブロック内を含む)でcitationsを送信している場合に影響します。
2026-10-21では、userメッセージ内で空でないcitations配列を持つtextブロックを送信するリクエストは400エラーを返します。それらのブロックからcitationsを削除してください。送り返すClaudeの以前の応答など、assistantメッセージ内のtextブロックのcitationsは引き続き受け付けられます。また、ドキュメントや検索結果に対する"citations": {"enabled": true}設定も引き続き受け付けられます。
サンプリングパラメータの削除
Messagesリクエストまたは Message Batchリクエストでtemperature、top_p、またはtop_kを送信している場合に影響します。
2026-10-21では、temperature、top_p、またはtop_kを送信するリクエストは、パラメータのデフォルト値であっても400エラーを返します。
リクエストからこれら3つのパラメータを削除してください。
最新のメジャーバージョンでは、SDKとCLIにこれら3つのパラメータはなくなりました。
これらのパラメータがない場合、リクエストはtemperatureの1.0を含むデフォルト値でサンプリングされます。これは、これらを省略した2023-06-01のリクエストと同じです。Claude 4.7以降のモデルなど、すでにデフォルト値のみを受け付けるモデルは、以前と同様にサンプリングします。Claude Sonnet 4.6など、他の値を受け付けるモデルでは、より一貫した出力を得るためにtemperatureを下げていたリクエストはその効果を失います。これに代わる設定はありません。リクエストがデフォルト以外の値に依存している場合は、パラメータの送信をやめるか、そのリクエストを2023-06-01のままにしてください。
Admin APIとClaude Enterprise Analytics API
コードが以下の表にあるAdmin APIまたはClaude Enterprise Analytics APIのレスポンスフィールドを読み取っている場合に影響します。
2026-10-21では、Admin APIおよびClaude Enterprise Analytics APIからのレスポンスに、名前が変更されたフィールドの古い名前が含まれなくなります。代わりに新しい名前を使用してください。
Admin API:
| エンドポイント | 古い名前 | 新しい名前 |
|---|---|---|
| RBACグループ:作成、一覧、取得、更新 | roles | role_ids |
| RBACグループメンバー:一覧と追加、およびメンバーの削除へのレスポンス | group_id | rbac_group_id |
| RBACロール:一覧と取得 | name | display_name |
| 組織およびワークスペースのレート制限:一覧、およびワークスペースのレート制限設定へのレスポンス | group_type | group.type |
| APIキー:一覧、取得、更新 | workspace_id | scope(値が異なります。APIキーのworkspace_idを参照) |
Claude Enterprise Analytics API:
| エンドポイント | 古い名前 | 新しい名前 |
|---|---|---|
| ユーザーごとの使用量およびコストレポート | actor.email | actor.email_address |
| アクティビティサマリー | summaries | data |
レート制限一覧エンドポイントのgroup_typeクエリパラメータと、APIキー一覧エンドポイントのworkspace_idフィルターは変更されていません。
APIキーのworkspace_id
コードがAPIキーのworkspace_idを読み取っている場合に影響します。
2023-06-01では、APIキーのworkspace_idは、キーがバインドされているワークスペースのIDです。Default Workspaceにバインドされたキー、および1つのワークスペースにバインドされていないキー(全ワークスペースキー)の場合はnullになります。
2026-10-21では、workspace_idは削除されます。代わりにscopeを読み取ってください。Default Workspaceを含むワークスペースにバインドされたキーの場合、scope.workspace_idはそのワークスペースの実際のIDです。全ワークスペースキーのscopeは{"type": "organization"}で、workspace_idはありません。
コードでnullのworkspace_idをDefault Workspaceとして扱っていた場合は、代わりにscope.workspace_idをDefault WorkspaceのIDと比較してください。そのIDを確認するには、include_default=trueを指定してList Workspacesを呼び出し、"Default"という名前のワークスペースを取得します。
SDKとCLIの変更
以前のSDKおよびCLIバージョンは、すべてのリクエストでanthropic-version: 2023-06-01を送信していました。2026-10-21に切り替えるに記載されているバージョンは2026-10-21を送信します。破壊的変更の変更はこれらにも適用されます。削除されたパラメータと古いフィールド名は、SDKの型、およびCLIのフラグと出力からもなくなっています。
Amazon BedrockとGoogle CloudでのAPIバージョン
Google Cloud's Agent Platform用のSDKクライアントは、バージョンをヘッダーではなくリクエストボディで指定します。以前のバージョンがvertex-2023-10-16を送信していたところでanthropic_version: 2026-10-21を送信し、anthropic-versionヘッダーは送信しません。
Amazon Bedrockクライアントも同様です。以前のバージョンがbedrock-2023-05-31を送信していたところでanthropic_version: 2026-10-21を送信し、anthropic-versionヘッダーは送信しません。Claude Opus 4.7より古いモデルは、Bedrock上でAPIバージョン2026-10-21をまだサポートしておらず、それを指定したリクエストは400エラーになる可能性があります。それらのモデルを使用している場合は、当面は以前のSDKバージョンを使い続けるか、アップグレードしたうえでbedrock-2023-05-31を自分で送信してください。
これはAnthropicVertex、AsyncAnthropicVertex、AnthropicBedrock、AsyncAnthropicBedrockに適用されます。
bedrock-2023-05-31を送信するには、各リクエストでextra_body={"anthropic_version": "bedrock-2023-05-31"}を渡してください。
MessageParamはロールごとに1つの型を持つユニオンになった
以前のバージョンでは、MessageParamはすべてのロールに共通の1つの型でした。現在は各ロールが独自の型を持ちます:UserMessageParam、AssistantMessageParam、SystemMessageParamです。BetaMessageParamも同様に、BetaUserMessageParam、BetaAssistantMessageParam、BetaSystemMessageParamに分割されています。SDKが送信するリクエストのフィールドと値は以前と同じです。
{"role": "user", "content": "Hello"}のようにdictリテラルとして記述されたメッセージは、変更の必要はありません。
v1では、anthropic.types.MessageParamは1つのTypedDictでした。v2では3つの型のユニオンであり、anthropic.types.beta.BetaMessageParamはその3つの型のユニオンです。どちらの名前も、list[MessageParam]のようなアノテーションでは引き続き機能します。
どちらの名前も、呼び出すとTypeErrorが発生するようになり、型チェッカーもそれを指摘します。メッセージはdictとして記述してください:
# 変更前
message = MessageParam(role="user", content="Hello")
# 変更後
message: MessageParam = {"role": "user", "content": "Hello"}どちらの名前をサブクラス化してもTypeErrorが発生します。UserMessageParamなど、ロールに対応する型をサブクラス化してください。
残りの変更は型チェックにのみ影響します。roleが複数のロールを保持しうる変数であるdictは、ユニオン内のどの型にも一致しないため、dictは1つのロールごとに構築してください:
# 変更前
def to_message(role: Literal["user", "assistant"], text: str) -> MessageParam:
return {"role": role, "content": text}
# 変更後
def to_message(role: Literal["user", "assistant"], text: str) -> MessageParam:
if role == "user":
return {"role": "user", "content": text}
return {"role": "assistant", "content": text}さらに2つの変更がBetaMessageParamにのみ適用されます:
clear_atとoutput_configはBetaSystemMessageParamのキーであるため、userメッセージやassistantメッセージはこれらを持つことができません。BetaSystemMessageParamではcontentがオプションであるため、pyrightはmessage["content"]を報告します。message.get("content")で読み取るか、先にmessage["role"]が"system"でないことを確認してください。
単一値のenumは定数になりました
この変更は、C#、Go、Java、PHP、Ruby の各SDKと、1つのCLIフラグに影響します。以前のバージョンでは、1つの値しか取れない必須フィールドは、メンバーが1つだけの独自のenum型を持っていました。これらのフィールドは定数になり、enum型は削除されました。SDKが送受信するJSONは変わりません。
ant beta:sessions:resources add では --type が省略可能になりました。そこで --type が取れる値は file だけなので、v2 が自動的に送信します。--type file を引き続き渡しているコマンドもそのまま動作するため、変更は必要ありません。
ツールランナーからクライアントサイドのコンパクションが削除されました
この変更は、TypeScript と Ruby のSDKに影響します。「tool runner」(ツールランナー)における「client-side compaction」(クライアントサイドのコンパクション)は削除され、サーバーサイドのコンパクションに置き換えられました。サーバーサイドのコンパクションは、クライアントからの追加リクエストではなく、API内部で会話を要約します。
compactionControl オプションと @anthropic-ai/sdk/lib/tools/CompactionControl モジュールは削除されました。このオプションは v0.129.0 で機能しなくなっており、渡すと AnthropicError がスローされていました。パラメーターの型に含まれていないため、TypeScriptは未知のプロパティとして報告します。
トークンのしきい値で自動的にコンパクションを続けるには、次のようにします。
// 変更前
const runner = client.beta.messages.toolRunner({
// ...
compactionControl: { enabled: true, contextTokenThreshold: 100_000 }
});
// 変更後
const runner = client.beta.messages.toolRunner({
// ...
betas: ["compact-2026-01-12"],
context_management: {
edits: [{ type: "compact_20260112", trigger: { type: "input_tokens", value: 100_000 } }]
}
});会話をコンパクションするタイミングを自分で決めるには、runner.compactBeforeNextTurn() を呼び出してください。
トリガーのしきい値は50,000トークン以上である必要があります。その他のオプション(pause_after_compaction、カスタムの instructions)については、コンパクションを参照してください。
Text Completionsが削除されました
レガシーのText Completions APIは、TypeScript、Go、Java、Ruby の各SDKとCLIから削除されました。新しいモデルや機能はこれをサポートしていません。代わりにMessages APIを使用してください。
ant completions create コマンドは削除されました。
# 変更前
ant completions create \
--model "$MODEL" \
--max-tokens-to-sample 1024 \
--prompt $'\n\nHuman: Hello, Claude\n\nAssistant:'
# 変更後
ant messages create \
--model "$MODEL" \
--max-tokens 1024 \
--message '{role: user, content: "Hello, Claude"}'応答テキストは completion フィールドから content.0.text に移動したため、--transform completion を渡していたスクリプトは、代わりに --transform content.0.text を渡してください。
ant messages create も --stream を受け取りますが、そのイベントは別の形式です。テキストは content_block_delta イベントの delta.text で届くため、--transform content.0.text はストリームには適用されません。
ベータ版以外のModelsメソッドから betas が削除されました
ベータ版以外のModelsメソッドは betas を受け取らなくなり、ant models コマンドは --beta を受け取らなくなりました。ベータヘッダーを送信するには、client.beta.models で同じメソッドを呼び出すか、CLIでは ant beta:models を使用してください。SDKでは、ベータ版以外のメソッドが ModelInfo を返すのに対し、これらのメソッドは BetaModelInfo を返します。
client.models.retrieve() と client.models.list() は betas を受け取らなくなり(渡すと TypeError になり、型チェッカーも警告します)、anthropic.types.ModelListParams には betas キーがなくなりました。
# 変更前
page = client.models.list(betas=[beta])
# 変更後
page = client.beta.models.list(betas=[beta])APIキーは Authorization: Bearer として送信されます
SDKとCLIは、APIキーを X-Api-Key ヘッダーではなく Authorization: Bearer <key> として送信します。そのため、X-Api-Key を読み取ったり設定したりするプロキシやゲートウェイは Authorization を使用するように変更するか、キーを自分で X-Api-Key に入れて送信してください。Claude APIはどちらのヘッダーのキーも受け付けるため、APIと直接通信するプログラムは変更の必要がありません。
# Before
X-Api-Key: <key>
# After
Authorization: Bearer <key>Authorization は、auth_token がすでに使用しているヘッダーです。
これは、Anthropic と AsyncAnthropic の api_key 引数および ANTHROPIC_API_KEY 環境変数と、AnthropicAWS の api_key および ANTHROPIC_AWS_API_KEY に適用されます。AnthropicFoundry は引き続きキーを x-api-key として送信し、AnthropicBedrockMantle はすでにベアラートークンを送信していました。
プロキシやゲートウェイが X-Api-Key を読み取る場合
HTTPクライアントの auth 関数を使って、キーを元のヘッダーに戻してください。この関数は、リトライを含め、クライアントが送信するすべてのリクエストで実行されます。
import httpx2
from anthropic import Anthropic, DefaultHttpxClient
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))AsyncAnthropic も同じ関数を http_client=DefaultAsyncHttpxClient(auth=send_x_api_key) の形で受け取ります。
リクエストで X-Api-Key を設定または削除していた場合
この変更は、Python、TypeScript、Go、PHP、Ruby の各SDKに影響します。
リクエストが認証トークンのみを送信するように X-Api-Key を削除していた場合は、そのコードを変更するのではなく削除してください。Authorization を削除するとトークンも削除されてしまうためです。クライアントは1つの認証情報を保持しますので、それがトークンであることを確認してください。コードで何も渡さず、ANTHROPIC_API_KEY と ANTHROPIC_AUTH_TOKEN の両方が設定されている場合、クライアントはキーを使用します。
リクエストからキーを除外するために extra_headers={"X-Api-Key": omit} を渡すコードは、その効果がなくなりました。代わりに extra_headers={"Authorization": omit} を渡してください。
extra_headers={"X-Api-Key": other_key} はクライアントのキーを置き換えなくなり、両方のキーが送信されます。1つのリクエストで別のキーを送信するには、extra_headers={"Authorization": f"Bearer {other_key}"} を渡してください。
クライアントは1つの認証情報を保持する
APIキーと認証トークンが同じヘッダーを共有するようになったため、SDKクライアントは1つの認証情報を保持します。コードで何も渡さない場合は、認証情報の優先順位の順序に従います。
v1では、クライアントがAPIキーと認証トークンの両方を持っている場合、それぞれを別々のヘッダーで両方とも送信していました。認証情報はapi_key、auth_token、credentials、config、profileのいずれか1つです。
- 渡すのは最大1つです。 コンストラクタ、または1回の
copy()やwith_options()の呼び出しで2つ以上渡すと、ValueErrorが発生します。Noneは数に含まれません。v1ではTypeErrorが発生し、それもcredentials、config、profileのうち2つを渡した場合のみでした。 - 渡したものだけが使われます。 v1と同様に、クライアントは環境やディスク上で別の認証情報を探しません。
- 何も渡さない場合、次のうち最初に設定されているものだけが使われます:
ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_PROFILEが指定するプロファイル、ワークロードアイデンティティフェデレーションの変数、ディスク上のアクティブなプロファイル(active_configファイルが指定するもの、なければdefault)。最初の2つが両方とも設定されている場合、クライアントは警告を1回ログに出力します。v1では、ANTHROPIC_CONFIG_DIRが設定されているかactive_configファイルが存在する場合、フェデレーション変数よりもアクティブなプロファイルを優先していました。引き続きそれを使用するには、ANTHROPIC_PROFILEを設定してください。 copy()とwith_options()は置き換えます。 渡した認証情報は、どちらがどの種類であっても、クライアント自身の認証情報を置き換えます。古い認証情報のconfigまたはprofileに由来するベースURLとヘッダーはそれとともに破棄され、新しい認証情報のものが使われます。自分で渡したベースURLは維持されます。
client = Anthropic(api_key=key, auth_token=token)
# 変更前: `X-Api-Key: <key>` と `Authorization: Bearer <token>` の両方を送信していました
# 変更後: `ValueError` を送出しますプラットフォームクライアントは独自のルールを維持します。AnthropicAWSはapi_keyと並べてauth_tokenを受け取ってもエラーにならず、キーを送信します。
詳細は_client.pyにあるAnthropic.__init__とAnthropic.copyのdocstringを参照してください。
両方を送信することに依存していた場合、たとえばゲートウェイ用のトークンとその背後にあるAPI用のキーを送っていた場合は、トークンをauth_tokenとして渡し、default_headersでX-Api-Keyを設定してください。ゲートウェイには、リクエストを転送する前にAuthorizationヘッダーを削除させてください。Claude APIは1リクエストにつき1つの認証情報を想定しています。
1つのSDKまたはCLIにおける変更
これらの変更は、それぞれ1つのSDKまたはCLIに影響します。
--api-keyと--auth-tokenは削除されました。 コマンドライン上の値はシェル履歴やプロセス一覧で見えてしまうため、antはAPIキーや認証トークンをフラグの値として受け取らなくなりました。両方のフラグはv1.27.0以降、非推奨の警告を出力していました。まだいずれかを渡しているコマンドはflag provided but not definedで停止します。
| 削除されたもの | 代わりに使用するもの |
|---|---|
--api-key <key> | ANTHROPIC_API_KEY、--api-key-stdin、またはant auth login |
--auth-token <token> | ANTHROPIC_AUTH_TOKENまたは--auth-token-stdin |
# 変更前
ant --api-key "$KEY" models list
# 変更後(環境変数から取得)
export ANTHROPIC_API_KEY="$KEY"
ant models list
# 変更後(シークレットマネージャーから取得)
op read op://vault/anthropic/api-key | ant --api-key-stdin models list--api-key-stdinと--auth-token-stdinは標準入力をすべて読み取るため、これらのいずれかを使用するコマンドはリクエストボディをフラグから取得します。
ant auth status、ant applyの初回実行時のプロンプト、および複数の認証ソースに関する注記では、これらの認証情報をANTHROPIC_API_KEYおよびANTHROPIC_AUTH_TOKENと呼ぶようになりました。以前は--api-key / ANTHROPIC_API_KEYおよび--auth-token / ANTHROPIC_AUTH_TOKENと出力していました。
ライセンスはApache 2.0です
これらのバージョン以降、SDKとCLIはApache License, Version 2.0の下でライセンスされます。以前のバージョンは引き続きMIT Licenseの下にあります。コードの変更は必要ありません。依存関係のライセンスを追跡している場合は、それらのエントリを更新してください。
- TypeScript: プラットフォームパッケージ(
@anthropic-ai/bedrock-sdk、@anthropic-ai/vertex-sdk、@anthropic-ai/foundry-sdk、@anthropic-ai/aws-sdk、@anthropic-ai/google-cloud-sdk)は、それぞれの1.0.0リリースでライセンスが変更されます。 - C#: その他のパッケージ(
Anthropic.Bedrock、Anthropic.Vertex、Anthropic.Foundry、Anthropic.Aws、Anthropic.GoogleCloud、Anthropic.Mcp)は、それぞれの1.0.0リリースでライセンスが変更されます。 - Java: この変更はすべての
com.anthropicアーティファクトに適用されます。
Was this page helpful?