--- title: APIバージョン2026-10-21への移行 url: https://platform.claude.com/docs/ja/api/migration-2026-10-21 description: Claude API統合をAPIバージョン2023-06-01から2026-10-21にアップグレードします。インストールするSDKバージョンと、必要なコード変更について説明します。 --- このガイドでは、APIバージョン`2023-06-01`から`2026-10-21`に移行するためのコード変更を一覧で示します。[アップグレード手順](https://platform.claude.com/docs/ja/api/migration-2026-10-21#migration-checklist)では、行うべきことを順番に説明しています。 ## アップグレード手順 SDKを使用している場合、リクエストには、そのSDKのメジャーバージョンがリリースされた時点で最新だったAPIバージョンが使用されます。各言語について示されているバージョンは`2026-10-21`を使用する最初のバージョンなので、それらにアップグレードしてください。SDKを使わずにAPIを呼び出している場合は、`anthropic-version`ヘッダーを`2026-10-21`に設定してください。 `anthropic-version`ヘッダーを`2026-10-21`に設定します： ```bash 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"}] }' ``` `ant` CLIをバージョン2.0.0にアップグレードします。Homebrewコマンドとリリースのダウンロードは変わりません。 Goでは、メジャーバージョン2以降のモジュールのパスはそのバージョンで終わる必要があるため、CLIのモジュールパスは`github.com/anthropics/anthropic-cli/v2`になりました。`go install`でインストールする場合は、パスに`/v2`を追加してください： ```bash # 変更前 go install 'github.com/anthropics/anthropic-cli/cmd/ant@latest' # 変更後 go install 'github.com/anthropics/anthropic-cli/v2/cmd/ant@latest' ``` 古いパスでは、エラーや警告なしに最新のv1リリースが引き続きインストールされます。 `anthropic`パッケージをバージョン2.0.0にアップグレードします。 `@anthropic-ai/sdk`パッケージをバージョン1.0.0にアップグレードします。 `@anthropic-ai/bedrock-sdk`、`@anthropic-ai/vertex-sdk`、`@anthropic-ai/foundry-sdk`、`@anthropic-ai/aws-sdk`、`@anthropic-ai/google-cloud-sdk`のv1には`@anthropic-ai/sdk`のv1が必要であり、それらの以前のバージョンには1未満のバージョンが必要です。これらのいずれかを使用している場合は、同じアップグレードでv1に移行してください。そうしないと、パッケージマネージャーがそのパッケージ用に`@anthropic-ai/sdk`の古いコピーをもう1つインストールします。 `Anthropic`パッケージをバージョン13.0.0にアップグレードします。 Go SDKのバージョン2.0.0にアップグレードします。そのモジュールパスは`github.com/anthropics/anthropic-sdk-go/v2`です。Goモジュールの新しいメジャーバージョンには新しいインポートパスがあるため、`github.com/anthropics/anthropic-sdk-go`、および`github.com/anthropics/anthropic-sdk-go/option`などのそのパッケージの各インポートを、`github.com/anthropics/anthropic-sdk-go/v2`で始まるように変更してください。その後、`go get github.com/anthropics/anthropic-sdk-go/v2`を実行します。 `com.anthropic:anthropic-java`アーティファクトをバージョン3.0.0にアップグレードします。 `composer require "anthropic-ai/sdk"`を実行して、パッケージをバージョン1.0.0にアップグレードします。`composer update`だけでは、現在のバージョン制約の範囲内にとどまります。 `anthropic` gemをバージョン2.0.0にアップグレードします。 Amazon Bedrockでは、`2026-10-21`はClaude 4.7以降のモデルでのみ利用できます。[Claude on Amazon Bedrock（Opus 4.6以前）](https://platform.claude.com/docs/ja/build-with-claude/claude-on-amazon-bedrock-legacy)に記載されている古いモデルをBedrockで呼び出している場合は、現在使用しているSDKバージョンを使い続けるか、APIバージョンを自分で設定している場合は、現在送信しているバージョンを引き続き送信してください。それらの呼び出しを`2026-10-21`に移行するには、まずClaude 4.7以降のモデルに切り替えてください。 アップグレードは、次のステップでの修正と一緒にリリースしてください。 [「breaking changes」（破壊的変更）](https://platform.claude.com/docs/ja/api/migration-2026-10-21#breaking-changes)を確認し、影響を受ける各変更に合わせてコードを更新してください。また、[新しいSDKまたはCLIバージョンで必要なコード変更](https://platform.claude.com/docs/ja/api/migration-2026-10-21#sdk-changes)も行ってください。 リリース前に、`2026-10-21`に対して統合をテストしてください。 ## 破壊的変更 ### Messages API これらの変更は、Messages API（`POST /v1/messages`）へのリクエスト、[トークンカウント](https://platform.claude.com/docs/ja/build-with-claude/token-counting)、および`2026-10-21`で作成された[Message Batch](https://platform.claude.com/docs/ja/build-with-claude/batch-processing)内の各リクエストに適用されます。 #### 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](https://platform.claude.com/docs/ja/manage-claude/analytics-api)からのレスポンスに、名前が変更されたフィールドの古い名前が含まれなくなります。代わりに新しい名前を使用してください。 Admin API： | エンドポイント | 古い名前 | 新しい名前 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------- | ----------------------------------------------------------------------------------------------------------------------------- | | [RBACグループ](https://platform.claude.com/docs/ja/api/beta/organization/rbac_groups/list)：作成、一覧、取得、更新 | `roles` | `role_ids` | | [RBACグループメンバー](https://platform.claude.com/docs/ja/api/beta/organization/rbac_groups/members/list)：一覧と追加、および[メンバーの削除](https://platform.claude.com/docs/ja/api/beta/organization/rbac_groups/members/remove)へのレスポンス | `group_id` | `rbac_group_id` | | [RBACロール](https://platform.claude.com/docs/ja/api/beta/organization/rbac_roles/list)：一覧と取得 | `name` | `display_name` | | [組織](https://platform.claude.com/docs/ja/api/organization/rate_limits/list)および[ワークスペース](https://platform.claude.com/docs/ja/api/organization/workspaces/rate_limits/list)のレート制限：一覧、およびワークスペースのレート制限設定へのレスポンス | `group_type` | `group.type` | | [APIキー](https://platform.claude.com/docs/ja/api/organization/api_keys/list)：一覧、取得、更新 | `workspace_id` | `scope`（値が異なります。[APIキーの`workspace_id`](https://platform.claude.com/docs/ja/api/migration-2026-10-21#api-key-workspace-id)を参照） | Claude Enterprise Analytics API： | エンドポイント | 古い名前 | 新しい名前 | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | --------------------- | | ユーザーごとの[使用量](https://platform.claude.com/docs/ja/api/beta/organization/analytics/user_usage_report/list)および[コスト](https://platform.claude.com/docs/ja/api/beta/organization/analytics/user_cost_report/list)レポート | `actor.email` | `actor.email_address` | | [アクティビティサマリー](https://platform.claude.com/docs/ja/api/beta/organization/analytics/summaries/list) | `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](https://platform.claude.com/docs/ja/api/organization/workspaces/list)を呼び出し、`"Default"`という名前のワークスペースを取得します。 ## SDKとCLIの変更 以前のSDKおよびCLIバージョンは、すべてのリクエストで`anthropic-version: 2023-06-01`を送信していました。[2026-10-21に切り替える](https://platform.claude.com/docs/ja/api/migration-2026-10-21#upgrade)に記載されているバージョンは`2026-10-21`を送信します。[破壊的変更](https://platform.claude.com/docs/ja/api/migration-2026-10-21#breaking-changes)の変更はこれらにも適用されます。削除されたパラメータと古いフィールド名は、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"}`を渡してください。 これは`AnthropicVertex`と`AnthropicBedrock`に適用されます。クライアントまたはリクエストで`anthropic-version`ヘッダーを設定した場合、その値はボディに入ります。 `bedrock-2023-05-31`を送信するには、クライアントまたはリクエストで`anthropic-version`ヘッダーを`"bedrock-2023-05-31"`に設定してください。 これは`AnthropicVertexClient`と`AnthropicBedrockClient`に適用されます。`ClientOptions.ExtraHeaders`を通じて`anthropic-version`ヘッダーを設定した場合、その値はボディに入ります。 `bedrock-2023-05-31`を送信するには、クライアントで`WithOptions`を呼び出し、`ClientOptions.ExtraHeaders`で`anthropic-version`を`bedrock-2023-05-31`に設定してください。 これは`vertex`パッケージと`bedrock`パッケージに適用されます。`option.WithHeader`で`anthropic-version`ヘッダーを設定した場合、その値はボディに入ります。`vertex.DefaultVersion`と`bedrock.DefaultVersion`は削除されました。 `bedrock-2023-05-31`を送信するには、クライアントまたはリクエストに`option.WithHeader("anthropic-version", "bedrock-2023-05-31")`を渡してください。 これは`VertexBackend`と`BedrockBackend`に適用されます。クライアントまたはリクエストで`anthropic-version`ヘッダーを設定した場合、その値はボディに入ります。 `bedrock-2023-05-31`を送信するには、クライアントまたはリクエストで`anthropic-version`ヘッダーを`bedrock-2023-05-31`に設定してください。 これは`Anthropic\Vertex\Client`と`Anthropic\Bedrock\Client`に適用されます。 `bedrock-2023-05-31`を送信するには、`requestOptions`で`'extraBodyParams' => ['anthropic_version' => 'bedrock-2023-05-31']`を渡してください。 これは`Anthropic::VertexClient`と`Anthropic::BedrockClient`に適用されます。`extra_headers`を通じて`anthropic-version`ヘッダーを設定した場合、その値はボディに入ります。`Anthropic::VertexClient::DEFAULT_VERSION`と`Anthropic::BedrockClient::DEFAULT_VERSION`は削除されました。 `bedrock-2023-05-31`を送信するには、`request_options`で`extra_headers: {"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として記述してください： ```python # 変更前 message = MessageParam(role="user", content="Hello") # 変更後 message: MessageParam = {"role": "user", "content": "Hello"} ``` どちらの名前をサブクラス化しても`TypeError`が発生します。`UserMessageParam`など、ロールに対応する型をサブクラス化してください。 残りの変更は型チェックにのみ影響します。`role`が複数のロールを保持しうる変数であるdictは、ユニオン内のどの型にも一致しないため、dictは1つのロールごとに構築してください： ```python # 変更前 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"`でないことを確認してください。 `MessageParam`は1つのインターフェースでした。現在は`UserMessageParam | AssistantMessageParam | SystemMessageParam`であり、`BetaMessageParam`はその3つの型の同様のユニオンです。変更されたのは型のみです。`{ role: "user", content: "Hello, Claude" }`のようにロールを指定したメッセージリテラルは以前と同様に型チェックを通過するため、ほとんどのコードは変更の必要がありません。 system型は他の2つとは異なります。その`content`は文字列またはテキストブロックであり、`beta`ではさらに`tool_addition`ブロックと`tool_removal`ブロックも含まれるため、そこに画像ブロックを置くとコンパイルできなくなります。`beta`では、`clear_at`と`output_config`を持つのはsystem型のみであり、その`content`はオプションです。 任意のロールのメッセージを扱うコードは、コンテンツブロックを置き換えたり追加したりする前、および`clear_at`や`output_config`を読み取る前に、`role`を確認する必要があります： ```typescript // 変更前 const copy: Anthropic.MessageParam = { ...message, content: blocks }; // 変更後 const copy: Anthropic.MessageParam = message.role === "system" ? message : { ...message, content: blocks }; ``` `BetaMessageParam`の`content`は`undefined`になる可能性があります： ```typescript // 変更前 const types = typeof message.content === "string" ? [] : message.content.map((block) => block.type); // 変更後 const types = Array.isArray(message.content) ? message.content.map((block) => block.type) : []; ``` 型`BetaMessageParam["content"]`にも`undefined`が含まれます。userメッセージまたはassistantメッセージのコンテンツには、`BetaMessageContentParam`を使用してください。 インターフェースはユニオンを拡張できず、クラスはユニオンを実装できません。型エイリアスを使用するか、代わりに1つのロールの型を指定してください。 ```typescript // 変更前 interface StoredMessage extends Anthropic.MessageParam { id: string; } // 変更後 type StoredMessage = Anthropic.MessageParam & { id: string }; ``` v12では、`MessageParam`と`BetaMessageParam`は`Role`と`Content`を設定するクラスでした。v13では、それぞれがそのロールに対応する3つのクラスのユニオンになり、`Anthropic.Models.Messages`と`Anthropic.Models.Beta.Messages`の`Role`列挙型はなくなりました。 メッセージを構築するときは、そのロールに対応するクラスを指定し、`Role`を削除してください。各クラスはユニオンに暗黙的に変換されます： ```csharp // 変更前 Messages = [new() { Role = Role.User, Content = "Hello, Claude" }], // 変更後 Messages = [new UserMessageParam { Content = "Hello, Claude" }], ``` `new UserMessageParam("Hello, Claude")`も機能します。 `Content`を保持するクラスも変更されます： * `MessageParamContent`は`MessageContentParam`に、`BetaMessageParamContent`は`BetaMessageContentParam`になりました。 * systemメッセージは独自のコンテンツクラスを持ちます。`SystemMessageParamContent`は文字列または`TextBlockParam`のリストを保持し、`BetaSystemMessageParamContent`は文字列または`SystemMessageContentBlock`のリストを保持します。`List`や`List`はこれに変換されなくなりました。 * `ClearAt`と`OutputConfig`は`BetaSystemMessageParam`にのみ存在します。 メッセージを読み取るとき、ユニオンには引き続き`Role`と`Content`がありますが、それらを設定することはできないため、`with`式はロールに対応するクラスに対して使用します。`Role`は`MessageParamRole`または`BetaMessageParamRole`を保持するようになりました。`BetaSystemMessageParam`では`Content`がオプションであるため、`BetaMessageParam.Content`は`null`になる可能性があります。 ```csharp // 変更前 if (message.Role.Value() == Role.Assistant) { } // 変更後 if (message.Role.Value() == MessageParamRole.Assistant) { } ``` `TryPickUser`、`TryPickAssistant`、`TryPickSystem`、`Switch`、`Match`を使うと、ロールに対応するクラスを取得できます。 v1では、`MessageParam`は`Role`フィールドと`Content`フィールドを持つ1つの構造体でした。v2ではユニオンになり、`OfUser`は`*UserMessageParam`を、`OfAssistant`は`*AssistantMessageParam`を、`OfSystem`は`*SystemMessageParam`を保持します。`BetaMessageParam`も同様に変更されます。SDKは、betaのsystemメッセージにおけるキーの順序を除き、以前と同じJSONを送信します。 `NewUserMessage`、`NewAssistantMessage`、`NewBetaUserMessage`、および`Message`と`BetaMessage`の`ToParam`メソッドは以前と同様に機能するため、これらを使ってメッセージを構築するコードは変更の必要がありません。 構造体リテラルでは、そのロールに対応する型を指定します。各型が独自のロールをマーシャリングするため、`Role`は省略してください： ```go // 変更前 anthropic.MessageParam{ Role: anthropic.MessageParamRoleAssistant, Content: blocks, } // 変更後 anthropic.MessageParam{OfAssistant: &anthropic.AssistantMessageParam{ Content: blocks, }} ``` メッセージを読み取るコードは、どのフィールドが設定されているかを確認します： ```go // 変更前 if message.Role == anthropic.MessageParamRoleUser { blocks = message.Content } // 変更後 if message.OfUser != nil { blocks = message.OfUser.Content } ``` * `MessageParamRole`型と`BetaMessageParamRole`型、およびそれらの定数はなくなりました。`message.GetRole()`は、ロールを`string`として指すポインタを返し、どのフィールドも設定されていない場合は`nil`を返します。 * `ClearAt`と`OutputConfig`は`BetaMessageParam`から`BetaSystemMessageParam`に移動しました。`BetaMessageParamClearAt`型とその定数の名前は、`BetaSystemMessageParamClearAt`で始まるようになりました。 * `SystemMessageParam.Content`は`[]TextBlockParam`です。`BetaSystemMessageParam.Content`は`[]BetaSystemMessageParamContentUnion`であり、`text`、`tool_addition`、`tool_removal`ブロックを保持します。`NewBetaSystemMessage`はその型のブロックを受け取るため、`anthropic.NewBetaTextBlock("Be brief.")`は`anthropic.BetaSystemMessageParamContentUnion{OfText: &anthropic.BetaTextBlockParam{Text: "Be brief."}}`になります。 * `MessageParam`のコピーは、元のものと同じメッセージを指します。`duplicate.OfUser.Content`を設定すると両方が変更されます。v1では`duplicate.Content`を設定してもコピーのみが変更されていました。 * `mcp.ToMessage`は、`user`または`assistant`以外のロールに対して`*mcp.UnsupportedValueError`を返します。v1では任意のロールをメッセージにコピーしていました。 v2では、`MessageParam`は`role`と`content`を持つ単一のクラスでした。v3では3つのクラスのユニオンになり、`MessageParam.Content`はトップレベルの`MessageContentParam`になりました。`BetaMessageParam`も同様に変更され、そのクラスは`Beta`プレフィックスが付いた同じ名前を持ちます。SDKが送信するJSONは、betaのsystemメッセージで`role`が`content`の前に来るようになった点を除き、同じです。 `String`を受け取る`addUserMessage`、`addAssistantMessage`、`addSystemMessage`、`Message`または`MessageParam`を受け取る`addMessage`、および`Message.toParam()`は変更されません。 `MessageParam.builder()`と`toBuilder()`はなくなりました。ロールに対応するファクトリメソッド（`ofUser`、`ofAssistant`、または`ofSystem`）を呼び出してください： ```java // 変更前 MessageParam message = MessageParam.builder() .role(MessageParam.Role.USER) .content("Hello, Claude") .build(); // 変更後 MessageParam message = MessageParam.ofUser("Hello, Claude"); ``` `MessageCreateParams`、`StructuredMessageCreateParams`、`MessageCountTokensParams`、`BatchCreateParams.Request.Params`のビルダーでは、コンテンツブロックのリストを受け取るメソッドの名前が新しくなりました： | v2 | v2 beta | v3 | | ---------------------------------- | --------------------------------------------- | ----------------------------------------- | | `addUserMessageOfBlockParams` | `addUserMessageOfBetaContentBlockParams` | `addUserMessageOfContentBlockParams` | | `addAssistantMessageOfBlockParams` | `addAssistantMessageOfBetaContentBlockParams` | `addAssistantMessageOfContentBlockParams` | | `addSystemMessageOfBlockParams` | `addSystemMessageOfBetaContentBlockParams` | `addSystemMessageOfBlocks` | コンテンツクラスでは、`ofBlockParams`、`blockParams()`、`isBlockParams()`、`asBlockParams()`、およびビジターの`visitBlockParams`において、`BlockParams`（betaでは`BetaContentBlockParams`）が`ContentBlockParams`になります。 systemメッセージは独自のコンテンツクラス`SystemMessageParam.Content`を持ち、`addSystemMessage`はこれを受け取るようになりました。そのブロックは`ContentBlockParam`ではなく`TextBlockParam`です。betaでは`BetaSystemMessageParam.Content.SystemMessageContentBlock`であり、`ofText`、`ofToolAddition`、`ofToolRemoval`を持ちます。 ```java // 変更前 builder.addSystemMessageOfBlockParams(List.of(ContentBlockParam.ofText(textBlock))); // 変更後 builder.addSystemMessageOfBlocks(List.of(textBlock)); ``` メッセージを読み取るとき、`role()`は変更されません。`content()`は`MessageContentParam`を返し、betaでは`Optional`を返します（betaではsystemメッセージがコンテンツを持たない場合があります）。`_role()`、`_content()`、`_additionalProperties()`は、`asUser()`、`asAssistant()`、または`asSystem()`が返すロールに対応するクラスに移動しました。 クラスは`Anthropic\Messages`に、betaのクラスは`Anthropic\Beta\Messages`にあります。配列として記述したメッセージは変更されず、引き続き`'role'`が必要です。 `MessageParam::with()`と`BetaMessageParam::with()`は残っており、`role`に対応するクラスを返します。名前付き引数を使った呼び出しは変更の必要がありません。`role`が最初のパラメータになったため、位置引数による呼び出しでは`content`と`role`を入れ替えるか、`role`を受け取らないロールのクラスで`with()`を呼び出してください。古い順序の引数に対して、PHPは`UnhandledMatchError`（PHPStanは警告しません）をスローするか、`content`がリストであるか`role`が列挙型のケースである場合は`TypeError`をスローします。 ```php // 変更前 MessageParam::with('Hello, Claude', 'user'); // 変更後 UserMessageParam::with('Hello, Claude'); ``` `MessageParam`であるオブジェクトはもう存在しません。`instanceof MessageParam`はfalseになり、パラメータや戻り値の型でそれを指定している箇所ではPHPが`TypeError`をスローします。代わりに3つのクラスを指定してください： ```php // 変更前 function send(MessageParam $message): void {} // 変更後 function send(UserMessageParam|AssistantMessageParam|SystemMessageParam $message): void {} ``` * `MessageParam::fromArray()`と`(new MessageParam)->withContent()`は「Call to undefined method」をスローします。`role`を自動的に設定するロールのクラスでこれらを呼び出してください。 * `withRole()`は文字列のみを受け取るようになりました。`Role`のケースに対してはPHPが`TypeError`をスローします。メッセージに別のロールを与えるには、そのロールのクラスを構築してください。 * `clearAt`と`outputConfig`は`BetaSystemMessageParam`にのみ存在し、`BetaMessageParam::with()`は他の2つのロールではこれらを破棄します。`BetaMessageParam\ClearAt`列挙型は`BetaSystemMessageParam\ClearAt`になりました。 * `MessageParam\Content`は`MessageContentParam`に、`BetaMessageParam\Content`は`BetaMessageContentParam`になりました。それらのPHPStan型も新しい名前になります：`ContentShape`は`MessageContentParamShape`になりました。 * `'role'`が`Role`のケースである配列は引き続き機能しますが、PHPStanがそれを報告するようになりました。文字列で記述してください。 ハッシュとして記述したメッセージは変更されません。 v2では、`Anthropic::MessageParam`は`Anthropic::UserMessageParam`、`Anthropic::AssistantMessageParam`、`Anthropic::SystemMessageParam`のユニオンです。同様に、`Anthropic::Beta::BetaMessageParam`はその3つのクラスのユニオンです。 `Anthropic::MessageParam.new(role: :user, content: "Hello, Claude")`は引き続き機能し、そのロールに対応するクラスのインスタンスを返します。`role:`なしで`Anthropic::UserMessageParam.new(content: "Hello, Claude")`のように、そのクラスを自分で構築することもできます。これらのインスタンスを構築または検査するコードでは、4つの点が変わります： * `MessageParam.new`はキーワード引数のみを受け取るため、ハッシュは`MessageParam.new(**hash)`として渡してください。`role:`がない場合、または3つのロールのいずれでもない場合は`ArgumentError`が発生します。 * `message.is_a?(Anthropic::MessageParam)`は`false`です。`when Anthropic::MessageParam`分岐と`messages.grep(Anthropic::MessageParam)`は引き続き一致します。 * `.new`で構築したインスタンスの`to_h`には`:role`がなく、`message[:role]`は`nil`です。`message.role`は引き続きロールを返します。 * `clear_at`と`output_config`を持つのは`BetaSystemMessageParam`のみです。userメッセージやassistantメッセージでは、これらは`nil`を返していましたが、現在は`NoMethodError`が発生します。 ```ruby # 変更前 typed = messages.select { _1.is_a?(Anthropic::MessageParam) } roles = typed.map { _1[:role] } # 変更後 typed = messages.grep(Anthropic::MessageParam) roles = typed.map(&:role) ``` `Role`列挙型モジュールは残ります。以下の定数は移動しました。`Beta`で始まる名前は`Anthropic::Beta`の下に、その他は`Anthropic`の下にあります： | 削除されたもの | 代わりに使用するもの | | --------------------------- | ----------------------------------------------------------------------------- | | `MessageParam::Content` | `MessageContentParam`、またはsystemメッセージの場合は`SystemMessageParam::Content` | | `BetaMessageParam::Content` | `BetaMessageContentParam`、またはsystemメッセージの場合は`BetaSystemMessageParam::Content` | | `BetaMessageParam::ClearAt` | `BetaSystemMessageParam::ClearAt` | Sorbetで型チェックを行っている場合、`MessageParam::OrHash`はなくなり、型としての`Anthropic::MessageParam`はインスタンスを受け付けなくなりました。3つのクラスには`Anthropic::MessageParam::Variants`を使用してください。各クラスはそれぞれ独自の`OrHash`を持ちます。RBSでは、`Anthropic::MessageParam`として型付けされた値は`role`や`content`を持ちません。`Anthropic::Models::message_param`エイリアスを使用してください。これはメッセージのハッシュ形式でしたが、現在は3つのクラスのユニオンです。betaの名前は`BetaMessageParam::Variants`と`Anthropic::Models::Beta::beta_message_param`です。 ### 単一値の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` を引き続き渡しているコマンドもそのまま動作するため、変更は必要ありません。 v12 では、このような `required` プロパティは `BetaManagedAgentsTextBlockType.Text` のように、メンバーが1つだけのenumを持っていました。そのほぼすべては、`Anthropic.Models.Beta` 配下のクラス（`Agents`、`DeploymentRuns`、`Deployments`、`Dreams`、`Environments`、`MemoryStores`、`Sessions`、`UserProfiles`、`Vaults`）の `Type` プロパティです。v13 では、これらのプロパティは、すでに `TextBlockParam.Type` がそうであったように、コンストラクターが値を設定する `JsonElement` になりました。 `BetaManagedAgentsGlobToolConfigParams.Type` のような省略可能なプロパティは、enumを保持します。そのうち2つのenumは名前が変わりました。 | v12 | v13 | | ------------------------------------------- | ----------------------------------------- | | `BetaManagedAgentsBashToolConfigParamsType` | `Anthropic.Models.Beta.Agents.Type` | | `BetaPackagesType` | `Anthropic.Models.Beta.Environments.Type` | オブジェクトを構築する際は、そのプロパティを削除してください。 ```csharp // 変更前 new BetaManagedAgentsTextBlock { Type = BetaManagedAgentsTextBlockType.Text, Text = "Hello Claude!", }; // 変更後 new BetaManagedAgentsTextBlock { Text = "Hello Claude!" }; ``` 必須プロパティが1つだけ残るクラスには、それを受け取るコンストラクターも追加されるため、`new BetaManagedAgentsTextBlock("Hello Claude!")` も使用できます。必須プロパティが1つも残らないクラスは、`new BetaManagedAgentsAlwaysAllowPolicy()` で構築します。 値を読み取る際は、文字列と比較してください。 ```csharp // 変更前 if (message.Type.Value() == BetaManagedAgentsAgentMessageEventType.AgentMessage) { } // 変更後 if (message.Type.GetString() == "agent.message") { } ``` unionのバリアントを区別するには、引き続き `TryPick*`、`Switch`、`Match` メソッドを使用してください。これらは変更されていません。 このようなenum型とその定数の例としては、`BetaManagedAgentsTextBlockType` と `BetaManagedAgentsTextBlockTypeText` があります。そのほぼすべては、`client.Beta` 配下の構造体（Agents、Deployments、Deployment Runs、Dreams、Environments、Memory Stores、Sessions、User Profiles、Vaults）の `Type` フィールドです。v2 では、これらのフィールドは、すでに `TextBlockParam.Type` がそうであったように、`shared/constant` パッケージの型を使用します。`BetaManagedAgentsBashToolConfigParams.Type` のような省略可能なフィールドは、enumを保持します。 リクエストでは、そのフィールドを削除してください。省略すると、その唯一の値としてマーシャリングされます。 ```go // 変更前 anthropic.BetaManagedAgentsTextBlockParam{ Type: anthropic.BetaManagedAgentsTextBlockTypeText, Text: "Hello Claude!", } // 変更後 anthropic.BetaManagedAgentsTextBlockParam{ Text: "Hello Claude!", } ``` その `Type` だけをフィールドとして持っていた構造体には、`NewBetaManagedAgentsAlwaysAllowPolicyParam()` のようなコンストラクターが追加されました。unionのメンバーとしては、空の構造体へのポインターも使用できます：`OfAlwaysAllow: &anthropic.BetaManagedAgentsAlwaysAllowPolicyParam{}`。 レスポンスでは、文字列と比較してください。 ```go // 変更前 switch event.Type { case string(anthropic.BetaManagedAgentsAgentMessageEventTypeAgentMessage): } // 変更後 switch event.Type { case "agent.message": } ``` 削除された型のいずれかで宣言していた独自の変数、フィールド、パラメーターは、`constant.AgentMessage` のような、そのフィールドの新しい型を使用します。`constant.ValueOf[constant.AgentMessage]()` はその値を返します。 unionのコンストラクターもフィールドに合わせて変更されます。次の5つは `type_` 引数がなくなります。 * `BetaManagedAgentsEventParamsOfUserToolConfirmation` * `BetaManagedAgentsEventParamsOfUserDefineOutcome` * `BetaManagedAgentsDeploymentInitialEventParamsOfUserDefineOutcome` * `BetaManagedAgentsMultiagentRosterEntryParamsOfBetaManagedAgentsAgents` * `BetaManagedAgentsMultiagentRosterEntryParamsOfBetaManagedAgentsAdvisors` 次の4つは他に引数を取らなかったため、削除されました。`BetaManagedAgentsEventParamsUnion{OfUserInterrupt: &anthropic.BetaManagedAgentsUserInterruptEventParams{}}` のように、unionのフィールドに空の構造体へのポインターを設定してください。 * `BetaManagedAgentsEventParamsOfUserInterrupt` * `BetaManagedAgentsMultiagentRosterEntryParamsOfBetaManagedAgentsMultiagentSelfs` * `BetaManagedAgentsCredentialNetworkingParamsOfUnrestricted` * `BetaOutputBehaviorParamOfCreateNew` このようなenumの例としては、唯一のメンバー `TEXT` を持つネストされたクラス `BetaManagedAgentsTextBlock.Type` があります。そのほぼすべては、`com.anthropic.models.beta` 配下のクラス（`agents`、`deploymentruns`、`deployments`、`dreams`、`environments`、`memorystores`、`sessions`、`userprofiles`、`vaults`）の `type` です。v3 では、これらのフィールドは、すでに `TextBlockParam` のものがそうであったように、ビルダーが値を設定する `JsonValue` になりました。`BetaManagedAgentsBashToolConfigParams` の `type` のような省略可能なフィールドは、enumを保持します。 オブジェクトを構築する際は、その呼び出しを削除してください。 ```java // 変更前 BetaManagedAgentsTextBlock block = BetaManagedAgentsTextBlock.builder() .type(BetaManagedAgentsTextBlock.Type.TEXT) .text("Hello Claude!") .build(); // 変更後 BetaManagedAgentsTextBlock block = BetaManagedAgentsTextBlock.builder() .text("Hello Claude!") .build(); ``` 必須フィールドが1つだけ残るクラスには、それを受け取るファクトリーメソッドも追加されるため、`BetaManagedAgentsTextBlock.of("Hello Claude!")` も使用できます。必須フィールドが1つも残らないクラスでは `of(type)` がなくなり、そのunionからも `ofAlwaysAllow(type)` のようなenumを受け取るオーバーロードがなくなります。`BetaManagedAgentsAlwaysAllowPolicy.builder().build()` で構築してください。 値を読み取る際、`type()` は削除されており、`_type()` が `com.anthropic.core.JsonValue` を返します。 ```java // 変更前 if (message.type().equals(BetaManagedAgentsAgentMessageEvent.Type.AGENT_MESSAGE)) {} // 変更後 if (message._type().equals(JsonValue.from("agent.message"))) {} ``` unionのバリアントを区別するには、引き続き `is*()` および `as*()` メソッドとビジターを使用してください。これらは変更されていません。 このようなenumケースの例としては、`Anthropic\Beta\Sessions\Events\ManagedAgentsTextBlock\Type::TEXT` があります。そのほぼすべては、`Anthropic\Beta` 配下のManaged Agentsクラスの `type` です。これらのプロパティは、すでに `Anthropic\Messages\TextBlockParam` の `type` がそうであったように、その唯一の値をデフォルトとする文字列になりました。`Anthropic\Beta\Environments\BetaPackages` の `type` のような省略可能なプロパティは、enumを保持します。 `with()` は `type` を受け取らなくなりました。削除してください。`type:` が残っているとPHPは「Unknown named parameter」をスローし、位置引数による呼び出しでは、それ以降の引数が1つずつ前にずれます。 ```php // 変更前 ManagedAgentsTextBlock::with(text: 'Hello Claude!', type: Type::TEXT); // 変更後 ManagedAgentsTextBlock::with(text: 'Hello Claude!'); ``` enumケースと比較していた箇所では、文字列と比較してください。 ```php // 変更前 $event->type === Type::AGENT_MESSAGE->value; // 変更後 $event->type === 'agent.message'; ``` * `withType()` と `$client->beta->sessions->resources->add()` の `type` 引数は、文字列のみを受け取るようになりました。`add()` ではデフォルトが `'file'` なので、省略できます。 * 配列として記述するリクエストは変更されず、引き続き `'type'` が必要です。 このようなenum定数の例としては、`Anthropic::Beta::Sessions::BetaManagedAgentsTextBlock::Type::TEXT` があります。そのほぼすべては、`Anthropic::Beta` 配下のManaged Agentsクラスの `type` です。v2 では、これらのフィールドは、すでに `Anthropic::TextBlockParam` の `type` がそうであったように、定数として宣言されます。`Anthropic::Beta::BetaManagedAgentsGlobToolConfigParams` の `type` のような省略可能なフィールドは、enumを保持します。 削除された定数は、そのシンボルに置き換えてください。 ```ruby # 変更前 event.type == Anthropic::Beta::Sessions::BetaManagedAgentsAgentMessageEvent::Type::AGENT_MESSAGE # 変更後 event.type == :"agent.message" ``` ハッシュとして記述するリクエストは変更されず、引き続き `type` が必要です。 ```ruby client.beta.sessions.events.send_( session.id, events: [{type: "user.message", content: [{type: "text", text: "Hello Claude!"}]}] ) ``` モデルインスタンスを構築する際、`type:` にはデフォルト値が設定されたため、省略できます：`Anthropic::Beta::Sessions::BetaManagedAgentsTextBlock.new(text: "Hello Claude!")`。`client.beta.sessions.resources.add` の `type:` キーワードについても同様です。 Sorbetで型チェックを行っている場合、これらのモジュールの `Type::OrSymbol` および `Type::TaggedSymbol` エイリアスもあわせて削除されており、フィールドは `Symbol` になります。`OrSymbol` は `String` も許容していたため、`.new(type: "text")` は型チェックを通らなくなりました。キーワードを削除するか、`:text` を渡してください。RBSでは、各クラスの `type_` エイリアスが削除され、フィールドは `:text` のようなリテラルになります。 ### ツールランナーからクライアントサイドのコンパクションが削除されました この変更は、TypeScript と Ruby のSDKに影響します。「tool runner」（ツールランナー）における「client-side compaction」（クライアントサイドのコンパクション）は削除され、サーバーサイドのコンパクションに置き換えられました。サーバーサイドのコンパクションは、クライアントからの追加リクエストではなく、API内部で会話を要約します。 `compactionControl` オプションと `@anthropic-ai/sdk/lib/tools/CompactionControl` モジュールは削除されました。このオプションは v0.129.0 で機能しなくなっており、渡すと `AnthropicError` がスローされていました。パラメーターの型に含まれていないため、TypeScriptは未知のプロパティとして報告します。 トークンのしきい値で自動的にコンパクションを続けるには、次のようにします。 ```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()`](https://github.com/anthropics/anthropic-sdk-typescript/blob/main/helpers.md#compaction) を呼び出してください。 `compaction_control:` オプションは削除されました。このオプションは v1.74.0 で機能しなくなっており、渡すと `ArgumentError` が発生していました。 トークンのしきい値で自動的にコンパクションを続けるには、次のようにします。 ```ruby # 変更前 runner = client.beta.messages.tool_runner( # ... compaction_control: {enabled: true, context_token_threshold: 100_000} ) # 変更後 runner = client.beta.messages.tool_runner( # ... betas: ["compact-2026-01-12"], context_management: { edits: [{type: :compact_20260112, trigger: {type: :input_tokens, value: 100_000}}] } ) ``` 会話をコンパクションするタイミングを自分で決めるには、ランナーで [`#compact_before_next_turn`](https://github.com/anthropics/anthropic-sdk-ruby/blob/main/helpers.md#compact_before_next_turn---compact-the-conversation) を呼び出してください。 トリガーのしきい値は50,000トークン以上である必要があります。その他のオプション（`pause_after_compaction`、カスタムの `instructions`）については、[コンパクション](https://platform.claude.com/docs/ja/build-with-claude/compaction-threshold)を参照してください。 ### Text Completionsが削除されました レガシーのText Completions APIは、TypeScript、Go、Java、Ruby の各SDKとCLIから削除されました。新しいモデルや機能はこれをサポートしていません。代わりに[Messages API](https://platform.claude.com/docs/ja/api/messages)を使用してください。 `ant completions create` コマンドは削除されました。 ```bash # 変更前 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` はストリームには適用されません。 `client.completions` は削除され、あわせて `Completions` リソースクラスと、`Completion`、`CompletionCreateParams`、`CompletionCreateParamsNonStreaming`、`CompletionCreateParamsStreaming` の各型も削除されました。`AnthropicBedrock` にも `completions` プロパティはなくなりました。Text Completionsのプロンプトでのみ使用されていた `HUMAN_PROMPT` および `AI_PROMPT` 定数も、エクスポートとクライアントの静的プロパティの両方から削除されました。 ```typescript // 変更前 const completion = await client.completions.create({ model, max_tokens_to_sample: 1024, prompt: "\n\nHuman: Hello, Claude\n\nAssistant:" }); console.log(completion.completion); // 変更後 const message = await client.messages.create({ model, max_tokens: 1024, messages: [{ role: "user", content: "Hello, Claude" }] }); console.log(message.content); ``` `client.completions.create({ ..., stream: true })` は `client.messages.create({ ..., stream: true })` または `client.messages.stream({ ... })` になります。 `client.Completions` は削除され、あわせて `CompletionService`、`NewCompletionService`、`CompletionNewParams`、`Completion` も削除されました。`aws.Client` にも `Completions` フィールドはなくなりました。`bedrock.DefaultEndpoints` には `/v1/complete` が含まれなくなりました。 ```go // 変更前 completion, err := client.Completions.New(ctx, anthropic.CompletionNewParams{ Model: model, MaxTokensToSample: 1024, Prompt: "\n\nHuman: Hello, Claude\n\nAssistant:", }) fmt.Println(completion.Completion) // 変更後 message, err := client.Messages.New(ctx, anthropic.MessageNewParams{ Model: model, MaxTokens: 1024, Messages: []anthropic.MessageParam{ anthropic.NewUserMessage(anthropic.NewTextBlock("Hello, Claude")), }, }) fmt.Println(message.Content[0].Text) ``` `client.Completions.NewStreaming` は `client.Messages.NewStreaming` になります。 `client.completions()` は `AnthropicClient` と `AnthropicClientAsync` から削除され、あわせて `CompletionService`、`CompletionServiceAsync`、および `com.anthropic.models.completions` パッケージ（`CompletionCreateParams` と `Completion`）も削除されました。 ```java // 変更前 CompletionCreateParams params = CompletionCreateParams.builder() .model(model) .maxTokensToSample(1024) .prompt("\n\nHuman: Hello, Claude\n\nAssistant:") .build(); System.out.println(client.completions().create(params).completion()); // 変更後 MessageCreateParams params = MessageCreateParams.builder() .model(model) .maxTokens(1024) .addUserMessage("Hello, Claude") .build(); client.messages().create(params).content().stream() .flatMap(contentBlock -> contentBlock.text().stream()) .forEach(textBlock -> System.out.println(textBlock.text())); ``` `client.completions().createStreaming` は `client.messages().createStreaming` になります。 `client.completions` は削除され、あわせて `Anthropic::Resources::Completions`、`Anthropic::CompletionCreateParams`、`Anthropic::Completion` も削除されました。`Anthropic::BedrockClient` にも `completions` リーダーはなくなりました。`completions` が `NotImplementedError` を発生させていた `Anthropic::BedrockMantleClient` と `Anthropic::GoogleCloudClient` では、このメソッド自体が存在しなくなりました。 ```ruby # 変更前 completion = client.completions.create( model: model, max_tokens_to_sample: 1024, prompt: "\n\nHuman: Hello, Claude\n\nAssistant:" ) puts(completion.completion) # 変更後 message = client.messages.create( model: model, max_tokens: 1024, messages: [{role: "user", content: "Hello, Claude"}] ) puts(message.content) ``` `client.completions.create_streaming` は `client.messages.stream` になります。 ### ベータ版以外のModelsメソッドから `betas` が削除されました ベータ版以外のModelsメソッドは `betas` (csharp, go: `Betas`; java: `.addBeta()`) を受け取らなくなり、`ant models` コマンドは `--beta` を受け取らなくなりました。ベータヘッダーを送信するには、`client.beta.models` (csharp, go: `client.Beta.Models`; java: `client.beta().models()`; php: `$client->beta->models`) で同じメソッドを呼び出すか、CLIでは `ant beta:models` を使用してください。SDKでは、ベータ版以外のメソッドが `ModelInfo` (ruby: `Anthropic::ModelInfo`) を返すのに対し、これらのメソッドは `BetaModelInfo` (ruby: `Anthropic::Beta::BetaModelInfo`) を返します。 ```bash # 変更前 ant models list --beta "$BETA" # 変更後 ant beta:models list --beta "$BETA" ``` `client.models.retrieve()` と `client.models.list()` は `betas` を受け取らなくなり（渡すと `TypeError` になり、型チェッカーも警告します）、`anthropic.types.ModelListParams` には `betas` キーがなくなりました。 ```python # 変更前 page = client.models.list(betas=[beta]) # 変更後 page = client.beta.models.list(betas=[beta]) ``` `Anthropic.ModelRetrieveParams` と `Anthropic.ModelListParams` には `betas` プロパティがなくなりました。 ```typescript // 変更前 const page = await client.models.list({ betas: [beta] }); // 変更後 const page = await client.beta.models.list({ betas: [beta] }); ``` `Anthropic.Models.Models` の `ModelRetrieveParams` と `ModelListParams` には `Betas` プロパティがなくなりました。`client.Beta.Models` のメソッドは、`Anthropic.Models.Beta.Models` にある同名のクラスを受け取ります。 ```csharp // 変更前 using Anthropic.Models.Models; var page = await client.Models.List(new ModelListParams { Betas = [beta] }); // 変更後 using Anthropic.Models.Beta.Models; var page = await client.Beta.Models.List(new ModelListParams { Betas = [beta] }); ``` `ModelGetParams` と `ModelListParams` には `Betas` フィールドがなくなりました。 ```go // 変更前 page, err := client.Models.List(ctx, anthropic.ModelListParams{ Betas: []anthropic.AnthropicBeta{beta}, }) // 変更後 page, err := client.Beta.Models.List(ctx, anthropic.BetaModelListParams{ Betas: []anthropic.AnthropicBeta{beta}, }) ``` `com.anthropic.models.models` の `ModelRetrieveParams` と `ModelListParams` には `betas()` がなくなり、それらのビルダーには `betas` と `addBeta` がなくなりました。`client.beta().models()` のメソッドは、`com.anthropic.models.beta.models` にある同名のクラスを受け取ります。 ```java // 変更前 import com.anthropic.models.models.ModelListPage; import com.anthropic.models.models.ModelListParams; ModelListPage page = client.models().list(ModelListParams.builder().addBeta(beta).build()); // 変更後 import com.anthropic.models.beta.models.ModelListPage; import com.anthropic.models.beta.models.ModelListParams; ModelListPage page = client.beta().models().list(ModelListParams.builder().addBeta(beta).build()); ``` `$client->models->retrieve()` と `$client->models->list()` は `betas` を受け取らなくなり（渡すと `Error: Unknown named parameter $betas` がスローされます）、`Anthropic\Models\ModelRetrieveParams` と `Anthropic\Models\ModelListParams` には `betas` プロパティがなくなりました。 ```php // 変更前 $page = $client->models->list(betas: [$beta]); // 変更後 $page = $client->beta->models->list(betas: [$beta]); ``` 位置引数で引数を渡している場合、両方のメソッドで `workspaceID` と `requestOptions` がそれぞれ1つ前にずれます。 `client.models.retrieve` と `client.models.list` は `betas:` を受け取らなくなり、`Anthropic::ModelRetrieveParams` と `Anthropic::ModelListParams` には `betas` フィールドがなくなりました。 ```ruby # 変更前 page = client.models.list(betas: [beta]) # 変更後 page = client.beta.models.list(betas: [beta]) ``` `client.models` に `betas:` を渡してもエラーは発生しませんが、`anthropic-beta` ヘッダーは設定されなくなりました。 ### APIキーは `Authorization: Bearer` として送信されます SDKとCLIは、APIキーを `X-Api-Key` ヘッダーではなく `Authorization: Bearer ` として送信します。そのため、`X-Api-Key` を読み取ったり設定したりするプロキシやゲートウェイは `Authorization` を使用するように変更するか、[キーを自分で `X-Api-Key` に入れて送信](https://platform.claude.com/docs/ja/api/migration-2026-10-21#sdk-proxy-x-api-key)してください。Claude APIはどちらのヘッダーのキーも受け付けるため、APIと直接通信するプログラムは変更の必要がありません。 ```text wrap # Before X-Api-Key: # After Authorization: Bearer ``` これは、`ANTHROPIC_API_KEY` のキーと、`--api-key-stdin` にパイプで渡されたキーに適用されます。 `--debug` を指定すると、リクエストログには、これまで `X-Api-Key: ` と表示されていた箇所に `Authorization: Bearer ` と表示されるようになりました。 `Authorization` は、`auth_token` がすでに使用しているヘッダーです。 これは、`Anthropic` と `AsyncAnthropic` の `api_key` 引数および `ANTHROPIC_API_KEY` 環境変数と、`AnthropicAWS` の `api_key` および `ANTHROPIC_AWS_API_KEY` に適用されます。`AnthropicFoundry` は引き続きキーを `x-api-key` として送信し、`AnthropicBedrockMantle` はすでにベアラートークンを送信していました。 `Authorization` は、`authToken` オプションがすでに使用しているヘッダーです。 これは、`apiKey` オプション、`ANTHROPIC_API_KEY` 環境変数、および `@anthropic-ai/aws-sdk` の `apiKey` と `ANTHROPIC_AWS_API_KEY` に適用されます。`@anthropic-ai/foundry-sdk` の `apiKey` は引き続き `X-Api-Key` として送信され、`@anthropic-ai/bedrock-sdk` の `apiKey` はすでにベアラートークンでした。 `x-api-key` リクエストヘッダーからキーを読み取るミドルウェアやカスタムの `fetch` は、代わりに `authorization` を読み取る必要があります。そこではキーは `Bearer `の後に続きます。 `Authorization` は、`AuthToken` がすでに使用しているヘッダーです。 これは、`AnthropicClient` と `ClientOptions` の `ApiKey`、および `ANTHROPIC_API_KEY` 環境変数に適用されます。v13 に依存する `Anthropic.Aws` リリースでは、`AwsClientOptions` の `ApiKey` と `ANTHROPIC_AWS_API_KEY` にも適用されます。`AnthropicFoundryApiKeyCredentials` は引き続きキーを `x-api-key` として送信し、`MantleAwsClientOptions` の `ApiKey` はすでにベアラートークンでした。 これは、`option.WithAPIKey`、`ANTHROPIC_API_KEY` 環境変数、および `aws.ClientConfig` の `APIKey`（または `ANTHROPIC_AWS_API_KEY`）に適用されます。`foundry.ClientConfig` の `APIKey`（または `ANTHROPIC_FOUNDRY_API_KEY`）は引き続き `X-Api-Key` として送信され、`bedrock.MantleClientConfig` の `APIKey` はすでにベアラートークンでした。 `Authorization` は、`authToken` がすでに使用しているヘッダーです。 これは、`AnthropicOkHttpClient`、`AnthropicOkHttpClientAsync`、`AnthropicBackend` の各ビルダーの `apiKey`、`ANTHROPIC_API_KEY` 環境変数、および `anthropic.apiKey` システムプロパティに適用されます。`FoundryBackend` ビルダーの `apiKey` は引き続き `x-api-key` として送信されます。`AwsBackend`、`BedrockBackend`、`BedrockMantleBackend` の各ビルダーの `apiKey` はすでにベアラートークンでした。 インターセプターは、キーを `X-Api-Key` ではなく `Authorization` で受け取るようになりました。 `Authorization` は、`authToken` がすでに使用しているヘッダーです。 これは、`Anthropic\Client` の `apiKey` 引数および `ANTHROPIC_API_KEY` 環境変数と、`Anthropic\Aws\Client` の `apiKey` および `ANTHROPIC_AWS_API_KEY` に適用されます。`Anthropic\Foundry\Client` は引き続きキーを `x-api-key` として送信し、`Anthropic\Bedrock\MantleClient` はすでにベアラートークンを送信していました。 `Authorization` は、`auth_token:` がすでに使用しているヘッダーです。 これは、`Anthropic::Client` の `api_key:` 引数および `ANTHROPIC_API_KEY` 環境変数と、`Anthropic::AWSClient` の `api_key:` および `ANTHROPIC_AWS_API_KEY` に適用されます。`Anthropic::BedrockMantleClient` はすでにベアラートークンを送信していました。 SDKは、別のオリジンへのリダイレクト（同じホスト上での `http` から `https` へのリダイレクトを含む）をたどる際に `Authorization` を削除します。そのような場合、キーも削除されるようになりました。 #### プロキシやゲートウェイが `X-Api-Key` を読み取る場合 `--base-url` または `ANTHROPIC_BASE_URL` によって `ant` が `X-Api-Key` を読み取るプロキシやゲートウェイを指している場合は、`Authorization` からキーを読み取るように変更してください。`ant` には独自のヘッダーを追加するためのフラグや環境変数がないため、`X-Api-Key` を送信することはできません。 HTTPクライアントの `auth` 関数を使って、キーを元のヘッダーに戻してください。この関数は、リトライを含め、クライアントが送信するすべてのリクエストで実行されます。 ```python 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)` の形で受け取ります。 ヘッダーを自分で設定してください。`Authorization: null` を指定すると、キーがそちらにも送信されるのを防げます。 ```typescript const client = new Anthropic({ apiKey, defaultHeaders: { "X-Api-Key": apiKey, Authorization: null } }); ``` プロキシが認証情報を追加し、クライアント側には認証情報がない場合、v0 では `defaultHeaders` で `"X-Api-Key": null` または `Authorization: null` のいずれかを指定してそれを示すことができました。v1 では `Authorization: null` のみを受け付けます。 environmentのワークポーラーとワーカーには独自のキーが与えられるため、それら自身のリクエストには `X-Api-Key` と `Authorization` のデフォルトヘッダーを含めません。 `ExtraHeaders` を使ってヘッダーを自分で設定してください。`ApiKey` と `AuthToken` を `null` に設定すると、`ANTHROPIC_API_KEY` または `ANTHROPIC_AUTH_TOKEN` で見つかった認証情報も送信されなくなります。 ```csharp AnthropicClient client = new( new ClientOptions { ApiKey = null, AuthToken = null, ExtraHeaders = new Dictionary { ["X-Api-Key"] = apiKey }, } ); ``` ヘッダーを自分で設定してください。`option.WithHeaderDel` を使うと、`ANTHROPIC_API_KEY` で見つかったキーも送信されなくなります。 ```go client := anthropic.NewClient( option.WithHeader("X-Api-Key", apiKey), option.WithHeaderDel("Authorization"), ) ``` `environments.WorkPoller` と `environments.EnvironmentWorker` には独自のキーが与えられるため、それら自身のリクエストには手動で設定した `X-Api-Key` を含めません。 `apiKey` を呼び出す代わりに、ヘッダーを自分で設定してください。 ```java AnthropicClient client = AnthropicOkHttpClient.builder() .putHeader("X-Api-Key", apiKey) .build(); ``` ミドルウェアを使って、キーを元のヘッダーに戻してください。 ```php use Anthropic\Client; use Psr\Http\Message\RequestInterface; use Psr\Http\Message\ResponseInterface; $sendXApiKey = fn (RequestInterface $request, callable $next): ResponseInterface => $next( $request->withoutHeader('Authorization')->withHeader('X-Api-Key', $apiKey) ); $client = new Client(apiKey: $apiKey, requestOptions: ['middleware' => [$sendXApiKey]]); ``` この目的でクライアントの `extraHeaders` を使用しないでください。独自の `extraHeaders` を持つリクエストはクライアントのものを置き換えますが、ベータヘッダーを必要とする `$client->beta` 配下のすべてのエンドポイントは独自の `extraHeaders` を持っています。 ミドルウェアを使って、キーを元のヘッダーに戻してください。 ```ruby send_x_api_key = lambda do |req, nxt| next nxt.call(req) unless req.headers["authorization"] == "Bearer #{api_key}" nxt.call(req.with(headers: {**req.headers.except("authorization"), "x-api-key" => api_key})) end client = Anthropic::Client.new(api_key: api_key, middleware: send_x_api_key) ``` 最初の行は、別のオリジンにリダイレクトされたリクエストなど、キーを含まないリクエストには何もしません。 `Anthropic::AWSClient` は `middleware:` 引数を受け取りません。代わりに、各リクエストで `request_options: {middleware: send_x_api_key}` としてミドルウェアを渡してください。 #### リクエストで `X-Api-Key` を設定または削除していた場合 この変更は、Python、TypeScript、Go、PHP、Ruby の各SDKに影響します。 リクエストが認証トークンのみを送信するように `X-Api-Key` を削除していた場合は、そのコードを変更するのではなく削除してください。`Authorization` を削除するとトークンも削除されてしまうためです。[クライアントは1つの認証情報を保持します](https://platform.claude.com/docs/ja/api/migration-2026-10-21#sdk-one-credential)ので、それがトークンであることを確認してください。コードで何も渡さず、`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}"}` を渡してください。 リクエストのオプションにある `headers: { "X-Api-Key": otherKey }` はクライアントのキーを置き換えなくなり、両方のキーが送信されます。1つのリクエストで別のキーを送信するには、``headers: { Authorization: `Bearer $\{otherKey}` }`` を渡してください。 `option.WithHeaderDel("X-Api-Key")` では、リクエストからキーを除外できなくなりました。代わりに `Authorization` を削除してください。 ```go // 変更前 client.Messages.New(ctx, params, option.WithHeaderDel("X-Api-Key")) // 変更後 client.Messages.New(ctx, params, option.WithHeaderDel("Authorization")) ``` `option.WithHeader("X-Api-Key", otherKey)` はクライアントのキーを置き換えなくなり、両方のキーが送信されます。1つのリクエストで別のキーを送信するには、`option.WithAPIKey(otherKey)` を渡してください。 `'extraHeaders' => ['X-Api-Key' => null]` では、リクエストからキーを除外できなくなりました。認証情報なしでリクエストを送信するには、代わりに `Authorization` を `null` に設定するか、クライアント全体に対してこれを行っていた場合はミドルウェアで削除してください。 `'extraHeaders' => ['X-Api-Key' => $otherKey]` はクライアントのキーを置き換えなくなり、両方のキーが送信されます。1つのリクエストで別のキーを送信するには、`Authorization` を `"Bearer {$otherKey}"` に設定してください。 `extra_headers: {"x-api-key" => nil}` では、リクエストからキーを除外できなくなりました。代わりに `"authorization"` を `nil` に設定してください。1つのリクエストで別のキーを送信するには、`"x-api-key"` ではなく `"authorization"` を `"Bearer #{other_key}"` に設定してください。 ### クライアントは1つの認証情報を保持する APIキーと認証トークンが同じヘッダーを共有するようになったため、SDKクライアントは1つの認証情報を保持します。コードで何も渡さない場合は、[認証情報の優先順位](https://platform.claude.com/docs/ja/manage-claude/wif-reference#credential-precedence)の順序に従います。 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は維持されます。 ```python client = Anthropic(api_key=key, auth_token=token) # 変更前: `X-Api-Key: ` と `Authorization: Bearer ` の両方を送信していました # 変更後: `ValueError` を送出します ``` プラットフォームクライアントは独自のルールを維持します。`AnthropicAWS`は`api_key`と並べて`auth_token`を受け取ってもエラーにならず、キーを送信します。 詳細は[`_client.py`](https://github.com/anthropics/anthropic-sdk-python/blob/main/src/anthropic/_client.py)にある`Anthropic.__init__`と`Anthropic.copy`のdocstringを参照してください。 両方を送信することに依存していた場合、たとえばゲートウェイ用のトークンとその背後にあるAPI用のキーを送っていた場合は、トークンを`auth_token`として渡し、`default_headers`で`X-Api-Key`を設定してください。ゲートウェイには、リクエストを転送する前に`Authorization`ヘッダーを削除させてください。Claude APIは1リクエストにつき1つの認証情報を想定しています。 v0では、APIキーと認証トークンの両方を持つクライアントは、それぞれを別々のヘッダーで両方とも送信していました。認証情報は`apiKey`、`authToken`、`credentials`、`config`、`profile`のいずれか1つです。 * **渡すのは最大1つです。** `new Anthropic()`、または1回の`withOptions()`の呼び出しで2つ以上渡すと、`TypeError`がスローされます。`null`と`undefined`は数に含まれません。 * **渡したものだけが使われます。** クライアントは環境やディスク上で別の認証情報を探しません。 * **何も渡さない場合、次のうち最初のものが使われます：** `ANTHROPIC_API_KEY`、`ANTHROPIC_AUTH_TOKEN`、`ANTHROPIC_PROFILE`が指定するプロファイル、ワークロードアイデンティティフェデレーションの変数、ディスク上のアクティブなプロファイル（`active_config`ファイルが指定するもの、なければ`default`）。最初の2つが両方とも設定されている場合、クライアントは警告を1回ログに出力します。v0では、アクティブなプロファイルがフェデレーション変数より先でした。存在しないプロファイルを指定する`ANTHROPIC_PROFILE`はv0ではスキップされていましたが、現在は最初のリクエストで`AnthropicError`がスローされます。引数なしの`loadConfig()`も同じ順序に従い、同じエラーをスローします。 * **`withOptions`は置き換えます。** 渡した認証情報はコピー元のクライアントの認証情報を置き換えるため、`client.withOptions({ authToken })`に`apiKey: null`を並べる必要はなくなりました。 * **プラットフォームクライアントは、そのプラットフォームの認証情報のみを受け取ります。** AWS、Bedrock、Foundryの各クライアントと`AnthropicVertex`は、認証に使用しない認証情報オプションに対して`AnthropicError`をスローします。これは`AnthropicGoogleCloud`がすでに行っていた動作です。AWSとBedrockのクライアントでは、`apiKey: null`でキーがクリアされるようになったため、クライアントはAWS認証情報で署名します。`AnthropicBedrock`はキーを`client.apiKey`に保持します。v0では`client.authToken`に保持していました。 ```typescript // 変更前: APIキーを送信し、`credentials` を無視していました const client = new Anthropic({ apiKey, credentials }); // 変更後: 上の行で TypeError がスローされます const client = new Anthropic({ credentials }); ``` [`ClientOptions`](https://github.com/anthropics/anthropic-sdk-typescript/blob/main/src/client.ts)のドキュメントコメントに各オプションの動作が記載されており、これらのプラットフォームクライアントのコンストラクタのドキュメントコメントには、それぞれが拒否するオプションが列挙されています。 両方を送信することに依存していた場合、たとえばゲートウェイ用のトークンとその背後にあるAPI用のキーを送っていた場合は、`defaultHeaders`で`X-Api-Key`を設定し、`authToken`はそのまま維持してください。ゲートウェイには、リクエストを転送する前に`Authorization`ヘッダーを削除させてください。Claude APIは1リクエストにつき1つの認証情報を想定しています。 v12では、APIキーと認証トークンの両方を持つクライアントは、それぞれを別々のヘッダーで両方とも送信していました。認証情報は`ApiKey`、`AuthToken`、`ClientOptions.Credentials`のいずれか1つです。 * **2つ渡すとエラーになります。** 2つ目を設定すると`ArgumentException`がスローされます。`null`は数に含まれないため、自分で構築した`ClientOptions`の認証情報を入れ替えるには、先に古いものを`null`に設定してください。 * **1つ渡すとそれが使われ、環境は無視されます。** 認証情報の環境変数やディスク上のプロファイルは読み込まれません。同様に、`AnthropicCredentials.Resolve(profile: "name")`は、`ANTHROPIC_API_KEY`または`ANTHROPIC_AUTH_TOKEN`が設定されている場合でも、そのプロファイルの認証情報を返すようになりました。 * **何も渡さない場合、環境内で最初に一致したものが使われます：** `ANTHROPIC_API_KEY`、`ANTHROPIC_AUTH_TOKEN`、`ANTHROPIC_PROFILE`、ワークロードアイデンティティフェデレーションの変数、そしてディスク上のアクティブなプロファイル。空の`ANTHROPIC_API_KEY`または`ANTHROPIC_AUTH_TOKEN`は未設定として扱われます。最初の2つが両方とも設定されている場合、警告がstderrに1回出力されます。クライアントは最初に使用されたときに探索するため、存在しない`ANTHROPIC_PROFILE`は、コンストラクタではなく最初のリクエストでスローされるようになりました。 * **`WithOptions`は置き換えます。** modifierで渡した認証情報は、それがどの種類であってもクライアントの認証情報を置き換えるため、`AuthToken = token`に`ApiKey = null`を並べる必要はなくなりました。何も渡さない場合、modifierが新しい`ClientOptions`を返したとしても、コピーはクライアントの認証情報、`BaseUrl`、`ExtraHeaders`を維持します。 ```csharp // 変更前：両方を送信し、それぞれ個別のヘッダーに設定していました AnthropicClient client = new() { ApiKey = apiKey, AuthToken = token }; // 変更後：上の行で ArgumentException がスローされます AnthropicClient client = new() { AuthToken = token }; ``` 詳細は[`ClientOptions`](https://github.com/anthropics/anthropic-sdk-csharp/blob/main/src/Anthropic/Core/ClientOptions.cs)のこれら3つのプロパティのXMLドキュメントを参照してください。 クラウドプラットフォームクライアントは、構築時の認証情報を維持します。Bedrock、Bedrock Mantle、Foundry、Google Cloud、AWSの各クライアントと`AnthropicVertexClient`は、構築時に認証方法を決定し、そのほとんどが認証に`Authorization`ヘッダーを使用します。v13に依存するこれらのパッケージのリリースは、`WithOptions`で設定した`ApiKey`や`AuthToken`を無視します。`AnthropicAwsClient`で別のキーを使用するには、`AwsClientOptions`に`ApiKey`を指定して新しいクライアントを構築してください。 両方を送信することに依存していた場合、たとえばゲートウェイ用のトークンとその背後にあるAPI用のキーを送っていた場合は、`ExtraHeaders`で`X-Api-Key`を設定し、`AuthToken`はそのまま維持してください。ゲートウェイには、リクエストを転送する前に`Authorization`ヘッダーを削除させてください。Claude APIは1リクエストにつき1つの認証情報を想定しています。 v1では、APIキーと認証トークンの両方を持つクライアントは、それぞれを別々のヘッダーで両方とも送信していました。認証情報は`option.WithAPIKey`、`option.WithAuthToken`、`option.WithConfig`、`option.WithProfile`、`option.WithFederationTokenProvider`のいずれかから取得されます。 * **`anthropic.NewClient`にこれらのうち2つを渡すとエラーになります。** `NewClient`はエラーを返さないため、クライアントが行うすべてのリクエストがそのエラーで失敗します。`NewClient`はすでに`anthropic.DefaultClientOptions()`を適用しているため、その結果を追加で渡さないでください。渡すと、それが環境から見つけた認証情報が、自分で渡したものとして数えられてしまいます。 * **これらのうち1つはそのまま使われます。** 環境やディスク上のプロファイルから認証情報は読み込まれません。v1では、`ANTHROPIC_API_KEY`と`ANTHROPIC_AUTH_TOKEN`が最後の3つより優先されていました。 * **これらを何も渡さない場合、次のうち最初に設定されているものが使われます。** 順序はv1と同じです：`ANTHROPIC_API_KEY`、`ANTHROPIC_AUTH_TOKEN`、`ANTHROPIC_PROFILE`、ワークロードアイデンティティフェデレーションの変数、ディスク上のアクティブなプロファイル。最初の2つが両方とも設定されている場合、SDKは警告を1回ログに出力します。 * **リクエストにこれらのうち1つを指定すると、そのリクエストに限りクライアントの認証情報が置き換えられます。** そのため、`option.WithAuthToken`に`option.WithHeaderDel("X-Api-Key")`を並べる必要はなくなりました。 ```go // 変更前: APIキーが送信され、警告がログに記録されていました client := anthropic.NewClient( option.WithAPIKey(apiKey), option.WithProfile("work"), ) // 変更後: 上記クライアントのリクエストはすべて失敗するため、使用したいものを渡してください client := anthropic.NewClient(option.WithAPIKey(apiKey)) ``` v1が出力していた警告はなくなったため、それを抑制していた`option.WithConfigQuiet`は現在`option.WithConfig`と同じ動作をし、非推奨となりました。 詳細は[`client.go`](https://github.com/anthropics/anthropic-sdk-go/blob/main/client.go)にある`anthropic.NewClient`と`anthropic.DefaultClientOptions`のドキュメントコメントを参照してください。 両方を送信することに依存していた場合、たとえばゲートウェイ用のトークンとその背後にあるAPI用のキーを送っていた場合は、`option.WithHeader`で`X-Api-Key`を設定し、`option.WithAuthToken`はそのまま維持してください。ゲートウェイには、リクエストを転送する前に`Authorization`ヘッダーを削除させてください。Claude APIは1リクエストにつき1つの認証情報を想定しています。 `ANTHROPIC_CUSTOM_HEADERS`と`ANTHROPIC_WEBHOOK_SIGNING_KEY`は、`anthropic.NewClient`が構築するすべてのクライアントに適用されるようになりました。v1では、環境にもディスク上のプロファイルにも認証情報がない場合にのみ読み込まれていました。 v2では、APIキーと認証トークンの両方を持つクライアントは、それぞれを別々のヘッダーで両方とも送信していました。認証情報は、`AnthropicOkHttpClient`、`AnthropicOkHttpClientAsync`、`AnthropicBackend`の各ビルダーにおける`apiKey`、`authToken`、`configurationProvider`のいずれか1つです。 * **設定するのは最大1つです。** 1つのビルダーに2つ設定すると、`build()`はそれらを名指しする`IllegalStateException`をスローします。`null`や空の`Optional`は数に含まれません。 * **設定したものだけが使われます。** 前後どちらで呼び出しても、`fromEnv()`は環境やディスク上のプロファイルから認証情報を取得しません。v2では、`fromEnv()`が見つけたキーやトークンが、追加で、あるいは代わりに送信されることがありました。 * **何も設定しない場合、`fromEnv()`は次のうち最初に見つけたものを使います：** `ANTHROPIC_API_KEY`、`ANTHROPIC_AUTH_TOKEN`、`ANTHROPIC_PROFILE`、ワークロードアイデンティティフェデレーションの変数、ディスク上のアクティブなプロファイル。最初の2つが両方とも設定されている場合、警告が`System.err`に1回出力されます。`anthropic.apiKey`と`anthropic.authToken`のシステムプロパティは環境として扱われます。変数またはシステムプロパティ内の空のキーやトークンは未設定として扱われます。v2では、`fromEnv()`は空の値をキーやトークンとして使用していました。 ```java // 変更前: 両方が送信されていました。v3 では build() が IllegalStateException をスローします AnthropicClient client = AnthropicOkHttpClient.builder() .apiKey(apiKey) .authToken(authToken) .build(); // 変更後 AnthropicClient client = AnthropicOkHttpClient.builder() .apiKey(apiKey) .build(); ``` 詳細はこれらのビルダーの`fromEnv()`のドキュメントを参照してください。 両方を送信することに依存していた場合、たとえばゲートウェイ用のトークンとその背後にあるAPI用のキーを送っていた場合は、両方のヘッダーを自分で設定してください： ```java AnthropicClient client = AnthropicOkHttpClient.builder() .putHeader("Authorization", "Bearer " + gatewayToken) .putHeader("X-Api-Key", apiKey) .build(); ``` ゲートウェイには、リクエストを転送する前に`Authorization`ヘッダーを削除させてください。Claude APIは1リクエストにつき1つの認証情報を想定しています。 以前のバージョンでは、クライアントがAPIキーと認証トークンの両方を持っている場合、それぞれを別々のヘッダーで両方とも送信していました。`Anthropic\Client`は、`apiKey`、`authToken`、`credentials`のいずれかから1つの認証情報を受け取ります： * これらのうち2つ以上を渡すと`\InvalidArgumentException`がスローされます。渡していないとみなされるのは`null`のみです。空文字列は渡したものとみなされるため、`new Client(apiKey: '')`は認証情報を送信しません。 * 1つ渡すとそれが使われ、環境やディスク上のプロファイルから認証情報は読み込まれません。`ANTHROPIC_API_KEY`が設定されている場合、`new Client(authToken: $token)`はトークンを送信します。以前のバージョンでは、環境のキーも一緒に送信していました。 * 何も渡さない場合、次のうち最初に設定されているものが使われます：`ANTHROPIC_API_KEY`、`ANTHROPIC_AUTH_TOKEN`、`ANTHROPIC_PROFILE`が指定するプロファイル、ワークロードアイデンティティフェデレーションの変数、ディスク上のアクティブなプロファイル（`active_config`ファイルが指定するもの、なければ`default`）。以前のバージョンでは、フェデレーション変数よりもアクティブなプロファイルを先に使用し、`active_config`ファイルがない場合はプロファイルを使用しませんでした。また、存在しないプロファイルや無効なプロファイルを指定する`ANTHROPIC_PROFILE`はスキップしていました。その場合、`new Client()`は現在`Anthropic\Core\Exceptions\AnthropicException`をスローします。`ANTHROPIC_API_KEY`と`ANTHROPIC_AUTH_TOKEN`の両方が設定されている場合、クライアントはキーを送信し、その`authToken`プロパティは空になります。そのように構築された最初のクライアントは、`error_log()`で警告も書き込みます。これはプロセスごとに1回で、Webサーバー上ではリクエストごとに1回を意味します：`Anthropic: ANTHROPIC_API_KEY and ANTHROPIC_AUTH_TOKEN are both set. Using ANTHROPIC_API_KEY.` これを止めるには、使用しない変数の設定を解除してください。 ```php // 変更前: キーを X-Api-Key として、トークンを Authorization として送信していました。 // 変更後: "Pass at most one of `apiKey`, `authToken`, or `credentials`. Received `apiKey`, `authToken`." をスローします。 $client = new Client(apiKey: $key, authToken: $token); ``` 両方を送信することに依存していた場合、たとえばゲートウェイ用のトークンとその背後にあるAPI用のキーを送っていた場合は、トークンを`authToken`として渡し、[プロキシまたはゲートウェイが`X-Api-Key`を読み取る場合](https://platform.claude.com/docs/ja/api/migration-2026-10-21#sdk-proxy-x-api-key)にあるようなミドルウェアで、`withoutHeader`の呼び出しを除いて`X-Api-Key`を追加してください。ゲートウェイには、リクエストを転送する前に`Authorization`ヘッダーを削除させてください。Claude APIは1リクエストにつき1つの認証情報を想定しています。 `Anthropic::Client.new`の認証情報引数は`api_key:`、`auth_token:`、`credentials:`、`config:`です。`nil`の引数は渡していないものとみなされます。プラットフォームクライアントは独自のルールを維持します。 * **2つ以上渡した場合：** `Anthropic::Client.new`は`ArgumentError`を発生させます。以前のバージョンでは、`credentials:`と`config:`の組み合わせの場合にのみ例外を発生させ、それ以外の場合はキーがあればキーを、次にトークンを送信していました。 * **1つ渡した場合：** クライアントはそれを使用し、環境やディスク上のプロファイルの認証情報にフォールバックしません。 * **何も渡さない場合：** クライアントは次のうち最初に見つけたものを使用します：`ANTHROPIC_API_KEY`、`ANTHROPIC_AUTH_TOKEN`、`ANTHROPIC_PROFILE`、ワークロードアイデンティティフェデレーションの変数、ディスク上のアクティブなプロファイル。順序は変わっていませんが、`ANTHROPIC_API_KEY`と`ANTHROPIC_AUTH_TOKEN`の両方が設定されている場合、`client.auth_token`は`nil`になりました。空の`ANTHROPIC_API_KEY`または`ANTHROPIC_AUTH_TOKEN`は未設定として扱われるようになりました。以前のバージョンでは、空の`ANTHROPIC_API_KEY`がトークンとそれ以降のすべてを隠していました。 認証情報が渡されず、`ANTHROPIC_API_KEY`と`ANTHROPIC_AUTH_TOKEN`の両方が設定されている場合、SDKは`Kernel#warn`を通じて標準エラーにプロセスごとに1回警告も出力します：`Anthropic: ANTHROPIC_API_KEY and ANTHROPIC_AUTH_TOKEN are both set. Using ANTHROPIC_API_KEY.` これを抑制するには、使用しない変数の設定を解除してください。 ```ruby # 変更前: キーを送信し、トークンは無視していました。 # 変更後: ArgumentError, "Pass at most one of `api_key:`, `auth_token:`, `credentials:`, or `config:`. Received `api_key:`, `auth_token:`." Anthropic::Client.new(api_key: api_key, auth_token: auth_token) # 送信したいものを1つだけ渡してください。 Anthropic::Client.new(api_key: api_key) ``` ### 1つのSDKまたはCLIにおける変更 これらの変更は、それぞれ1つのSDKまたはCLIに影響します。 **`--api-key`と`--auth-token`は削除されました。** コマンドライン上の値はシェル履歴やプロセス一覧で見えてしまうため、`ant`はAPIキーや認証トークンをフラグの値として受け取らなくなりました。両方のフラグはv1.27.0以降、非推奨の警告を出力していました。まだいずれかを渡しているコマンドは`flag provided but not defined`で停止します。 | 削除されたもの | 代わりに使用するもの | | ---------------------- | --------------------------------------------------------- | | `--api-key ` | `ANTHROPIC_API_KEY`、`--api-key-stdin`、または`ant auth login` | | `--auth-token ` | `ANTHROPIC_AUTH_TOKEN`または`--auth-token-stdin` | ```bash # 変更前 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`と出力していました。 **ユニオンの`Type`はenumになりました。** v12では、`ContentBlock.Type`や`RawMessageStreamEvent.Type`などのユニオンクラスの`Type`プロパティは`JsonElement`でした。v13では`ApiEnum`になり、`T`は`ContentBlockType`のように、各バリアントに対応するメンバーを1つずつ持つ新しいenumです。いくつかのユニオンは、`BetaMemoryTool20250818Command.Command`のように、代わりに`Name`や`Command`で区別され、それらのプロパティも同様に変更されます。`TextBlock.Type`のようなバリアントクラスの`Type`は、引き続き`JsonElement`です。 ```csharp // 変更前 if (block.Type.GetString() == "tool_use") { } // 変更後 if (block.Type.Value() == ContentBlockType.ToolUse) { } ``` `block.Type.Raw()`は文字列を返します。このバージョンのSDKにenumメンバーがない文字列も含まれます。 **`IChatClient`はサンプリングオプションを無視します。** `IChatClient`アダプター（`AsIChatClient()`）は、`ChatOptions.Temperature`、`ChatOptions.TopK`、`ChatOptions.TopP`を無視するようになりました。[サンプリングパラメータは削除されました](https://platform.claude.com/docs/ja/api/migration-2026-10-21#sampling-parameters)を参照してください。 **`Optional`を返すようになったゲッター。** `AnthropicBackend`の`apiKey()`と`authToken()`は、`AwsBackend`と`BedrockMantleBackend`の`apiKey()`がすでにそうであったように、`Optional`を返すようになりました。v2ではそれぞれ`String`を返し、バックエンドがその種類の認証情報を持たない場合は`null`でした。 ```java // 変更前 String apiKey = backend.apiKey(); if (apiKey != null) {} // 変更後 Optional apiKey = backend.apiKey(); if (apiKey.isPresent()) {} ``` 以下のゲッターも`Optional`を返すようになりました。v2ではそれぞれ値そのものを返し、値がない場合は`null`でした： * `BedrockBackend`の`apiKey()`と`awsCredentialsProvider()` * `McpResourceFile`の`filename()`と`mimeType()` * `CredentialSource`の`detail()` * `HttpRequest`の`body()` * `FoundryBackend`の`resource()`（以前は`getResource()`） * `RequestOptions`の`responseValidation()`、`timeout()`、`followRedirects()`、`fallbackState()`、`openTelemetry()`（以前は`getResponseValidation()`、`getTimeout()`、`getFollowRedirects()`、`getFallbackState()`、`getOpenTelemetry()`） ```java // 変更前 String filename = file.filename(); if (filename != null) {} String resource = backend.getResource(); // 変更後 Optional filename = file.filename(); if (filename.isPresent()) {} Optional resource = backend.resource(); ``` `FoundryBackend`の`getBaseUrl()`は削除されました。`baseUrl()`を呼び出してください。これはリクエストの送信先URLを返します。それは設定したベースURL、またはリソースから構築されたURLであり、末尾は`/anthropic`です。 `AnthropicBackend`の`getBaseUrl()`も削除されました。同じ値を返す`baseUrl()`を呼び出してください。 **`HttpRequest`にはベースURLが必要です。** インターセプターのテストなどで`HttpRequest`を自分で構築する場合は、そのベースURLを設定してください。設定しないと、`build()`は`IllegalStateException`をスローするようになりました。v2では、`baseUrl()`が`null`のリクエストを返していました。SDKが構築するリクエストにはすでにベースURLがありました。 ```java // 変更前 HttpRequest request = HttpRequest.builder() .method(HttpMethod.GET) .build(); // 変更後 HttpRequest request = HttpRequest.builder() .method(HttpMethod.GET) .baseUrl("https://api.anthropic.com") .build(); ``` `baseUrl()`は引き続き`String`を返し、現在は決して`null`になりません。ビルダーでは、`baseUrl(Optional)`が削除され、`baseUrl(String)`は`null`を受け付けなくなりました。 **インターセプターは`anthropic-version`を参照できます。** クライアントは、インターセプターの実行前にデフォルトの`anthropic-version`ヘッダーを追加するようになりました。v2では、バックエンドがインターセプターの後に追加していました。インターセプターで独自のバージョンを設定する場合は、`putHeader`では2つ目の値が追加されるようになったため、`replaceHeaders`を呼び出してください： ```java // 変更前 request.toBuilder().putHeader("anthropic-version", version).build(); // 変更後 request.toBuilder().replaceHeaders("anthropic-version", version).build(); ``` **渡したenumケースは、その値として読み戻されます。** `with()`や`withAllowedCallers()`などのセッターは、引き続きenumケースまたはその値を受け取ります。以前のバージョンでは、ケースを渡したとおりに保持していました。v1ではケースの値を保持します。これはプロパティの型がすでに宣言しているものです。SDKがレスポンスから構築するオブジェクトは変わらず、SDKが送信するJSONも同じです。プロパティを読み戻してケースと比較している場合、比較は現在falseになり、何もスローされないため、ケースの値と比較してください： ```php $tool = CodeExecutionTool20250825::with(allowedCallers: [AllowedCaller::DIRECT]); // 変更前 in_array(AllowedCaller::DIRECT, $tool->allowedCallers, true); // 変更後 in_array(AllowedCaller::DIRECT->value, $tool->allowedCallers, true); ``` ### ライセンスは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`アーティファクトに適用されます。