AIREITERAnthropic Python SDK 1.0は、2026年8月20日にPyPIで公開された。普段どおりにAPIを呼んでいるだけなら、多くのコードはそのまま動くはずだ。ただし、本当に警戒すべき変更は表からは見えにくい。HTTP層がhttpxからhttpx2へ切り替わったため、httpxをパッチしているトレーシング、APM、テストモックは止まらずに動き続けながら、SDKリクエストだけを1件も記録しなくなる可能性がある。アップグレード後にテストが通ったとしても、それだけで安心はできない。
8月19日に3リリース、その翌日にv1.0
anthropicのPyPIリリース履歴を見ると、移行のタイミングは明確だ。2026年8月19日に0.123.0、0.124.0、0.125.0が公開され、翌8月20日には標準的なTrusted Publishingリリースとして1.0.0が続いた。
公式リリースノートで案内されている主な変更は、次のとおり。
- HTTP層が
httpxから、メンテナンスされているAPI互換フォークのhttpx2へ移行。 - Python 3.10以降が必須。対応classifierには3.10から3.14までが並ぶ。
- 長く非推奨だった機能を削除。レガシーText Completions API、Messagesメソッドの
temperature、top_p、top_k、ツールランナーのクライアント側compaction_controlが対象になる。 AnthropicBedrockはAWSリージョン未設定時、従来のようにus-east-1を暗黙に使わず、エラーを送出する。
GitHubのv1.0.0タグでは「httpx2へのアップグレードといくつかの小規模な破壊的変更」と説明されている。リリースノートでは見落としやすいが、parse、stream、tool_runnerヘルパーに付いていたベータ警告もなくなった。1.0となりベータ扱いも外れたことで、AnthropicはこのAPI面を安定版として扱う姿勢を示している。
httpxからhttpx2へ：影響を受けるコード
素のクライアント生成しかしていないなら、実質的な変更はない。一方でHTTP層に触れているコードでは、対応が必要になる。
境目になるのは、クライアントへ何を渡しているかだ。数値は従来どおり使える。たとえばAnthropic(timeout=30.0)の挙動は変わらない。しかしオブジェクトは別だ。通常のhttpx.Clientをhttp_client=に渡すと、最初のリクエスト時ではなくクライアント生成時にTypeErrorが発生する。カスタムクライアント、timeout、transportはhttpx2で組み立て直す必要があり、httpx.Timeoutオブジェクトはanthropic.Timeoutまたはhttpx2.Timeoutに置き換える。
# 0.x
client = Anthropic(http_client=httpx.Client(proxy="http://proxy:8080"))
# 1.0
client = Anthropic(http_client=DefaultHttpxClient(proxy="http://proxy:8080"))DefaultHttpxClientとDefaultAsyncHttpxClientは、名前も挙動も変わっていない。SDK推奨のtimeout、コネクションプール、リダイレクト設定を維持したまま、内部でhttpx2を使うようになっただけだ。platform devx engineerの@cjav_devによる告知でも、まず読むべき資料として公式MIGRATION.mdが案内されている。ここには全変更点のbefore／after例が掲載されている。
この移行には前例がある。OpenAI Python SDKのhttpx2移行ガイドも、同じフォーク、同様のDefaultHttpx2Clientヘルパーパターン、respx互換性に関する同種の注意点を扱っている。すでにopenaiの移行を済ませたチームなら、その手順をほぼそのまま流用できる。
v1.0で削除されたAPIと代替手段
| v1.0で削除 | 代替手段 |
|---|---|
client.completions.create()（Text Completions） | client.messages.create() |
HUMAN_PROMPT / AI_PROMPT定数 | Messages形式のコンテンツブロック |
メソッドシグネチャ上のtemperature、top_p、top_k | サーバー側で受け付けるレガシーモデルではextra_body={"temperature": ...} |
messages.parse(stream=True) | messages.stream(...) |
tool_runner(compaction_control=...) | サーバー側のcompaction設定 |
anthropic.Transport、anthropic.ProxiesTypesエイリアス | httpx2のtransport型 |
低レベルrequestメソッドのbody= | content= |
beta APIのoutput_formatスキーマdict | output_config={"format": ...}（構造化出力ヘルパーは引き続きoutput_format=MyModelを受け付ける） |
isinstance(stream, anthropic.Stream)によるチェック | 具体的なMessageStream型を確認 |
補足は2点ある。Pydantic v1とv2はどちらも引き続きサポートされるため、モデルクラスについては問題ない。また、ヘッダーのマージは大文字・小文字を区別しなくなった。異なる表記で同じヘッダーを二度設定していた場合は挙動が変わるが、このケースではエラーにならない。
raw response利用時だけ注意したい非同期APIの変更
非同期まわりの変更範囲は狭いが、.with_raw_responseを使っている場合は厄介だ。非同期クライアントではparse()、read()、text()、json()にawaitが必要になった。同期クライアントでは.textと.contentがプロパティからメソッドに変わっている。どちらもimport時には失敗しない。同期側は属性エラーとして明確に止まるが、非同期側はawaitせず、実行されないcoroutineを受け取ったまま見逃す可能性がある。
例外内のrequest／responseオブジェクトやraw resultも、現在はhttpx2型になっている。属性アクセスの大半は同じように機能するものの、isinstance(x, httpx.Response)による判定や型アノテーションは更新が必要だ。この種の差分はpyrightやmypyで検出できる。
最も危険なのは、見えない移行失敗
変更履歴では一文で済まされがちだが、監視ダッシュボードにとっては見過ごせない問題がある。Anthropicの移行ガイドによれば、httpxをパッチしてHTTP通信を監視・モックしているOpenTelemetry、Sentry、respx、pytest-httpx、vcrpyなどは、アップグレード後も動作を続けながらSDKリクエストを見逃すことがある。これらのツールはimportでき、実行もされ、レポートも出す。ただ、パッチ対象のライブラリをSDKが通らなくなったため、通信を観測できなくなる。インターセプトが実行されたことを検証していないモックテストでは、通信がモックへ届かず何も失敗しないまま、空振りで成功することさえある。
回避策はhttpx2.alias_httpx()だ。アプリケーションまたはテストの起動処理で、できる限り早く呼び出す。Python SDKドキュメントでは、httpxをimportする前に実行するよう指定されている。これによりhttpx2がhttpx名でエイリアスされ、パッチ型ツールを継続利用できる。ただし移行ガイドは、ライブラリコード内での呼び出しを避けるよう警告している。呼ぶべき場所はアプリケーションのエントリーポイントだけだ。
「起動が正常でも、AI呼び出しのトレースやモックが生きている証拠にはならない。」— @MarMarLabs、リリース翌日の投稿
この投稿は全文を読む価値がある。まず確認すべき移行テストとして、この見えない失敗を挙げている。アップグレード後、トレース対象の呼び出し1件とモック対象の呼び出し1件が、実際に記録されることを意図的に確かめるべきだという。スレッドでは、httpx2への手作業移行が必要なカスタムtransport、Python 3.10未満のCIイメージでinstall時に壊れる問題も、静かなリスクとして指摘されている。
修正なしで動き続けるコード
多くのコードベースにとって、率直な答えは「何もしなくてよい」だ。カスタムクライアント、transport、timeoutオブジェクトを組み立てていなければ、HTTP移行の影響は受けない。具体的に変わらないものは以下のとおり。
- 通常のパラメータで呼ぶ
client.messages.create(...)。リクエストもレスポンスモデルも同じ。 - 数値のtimeout指定とSDKのデフォルト。接続エラー、408、409、429、5xxに対する指数バックオフ付き2回のリトライ、デフォルト10分のtimeoutは変わらない。
base_urlによるルーティング。SDKをゲートウェイやAIReiter's Claude API endpointのようなAPI互換リレーへ向けていても、v1.0でその層は変わらない。変わったのはURLではなくクライアントだ。- Pydantic v1／v2のモデル、SSEストリーミングヘルパー、ファイルアップロードのインターフェース。
ただし、Python 3.10以上という条件だけは絶対だ。「安全」とした項目も、まずこの要件を満たしていることが前提になる。
コードレビューで通しやすい移行手順
- まだ移行できないなら、先に意図して固定する。
anthropic>=0.125,<1としておけば、作業日程を組むまでv1.0への移行を保留できる。 - コードベース全体で
import httpxとhttpx.をgrepする。SDK周辺にある一致箇所は、すべて移行対象だ。 - Claude Codeで
/claude-api upgrade pythonを実行する。@cjav_devのリリース告知でも推奨されているコマンドで、プロジェクト内で必要となる変更のdiffを生成できる。 - カスタムクライアント、transport、timeoutを
httpx2またはDefaultHttpxClientヘルパーで作り直す。 httpxをパッチするものがあれば、アプリケーションのエントリーポイントにhttpx2.alias_httpx()を追加する。- pyrightまたはmypyを実行する。httpx2への型変更は、アノテーションや
isinstanceのエラーとして現れる。 - CIでは、テストスイートごとにトレース済みリクエスト1件とモック済みリクエスト1件を検証する。起動ログが緑でも証拠にはならない。
Anthropic Python SDK v1.0 FAQ
Anthropic Python SDKは本当にv1になった？ まだ0.x？
v1はすでに存在する。anthropic 1.0.0は2026年8月20日にPyPIで公開され、前日の0.125.0に続いてGitHubでもv1.0.0としてタグ付けされた。PyPIのプロジェクトページでは現在、0.xユーザーにv1移行ガイドを案内している。
v1.0以降でtemperature、top_p、top_kを渡すには？
これらはメソッドシグネチャから削除された。サーバー側ではまだ受け付けるレガシーモデルに対しては、extra_body={"temperature": 0.7}を渡せる。ただし、現行モデルはデフォルト以外のサンプリング値に対して400を返す。これはSDKの変更ではなく、モデル側で行われた変更だ。
respx、pytest-httpx、vcrpyのテストは引き続き動く？
SDKのデフォルトクライアントに対しては動かず、しかもエラーにもならない。何もマッチしなくなる。テスト起動時に、httpxのimportより先にhttpx2.alias_httpx()を呼ぶか、モックをhttpx2.MockTransportへ移す必要がある。従来のhttpxだけをパッチするrespxリリースでは、SDK通信をインターセプトできない。
/claude-api upgrade pythonは何をするコマンド？
これはClaude Codeのコマンドで、Anthropic devx engineer @cjav_devの告知でも推奨されている。anthropic 0.xを使うプロジェクトをスキャンし、import、timeoutオブジェクト、raw response呼び出しなどの移行diffを生成する。トレースバックを見てから問題を探すのではなく、変更をレビューできるようにするためのものだ。
0.125で固定するか、1.0へ進むか
ここに一律の正解はない。実際のトレードオフを見て判断したい。1.0未満に留まれば、既存のモック、トレーサー、カスタムtransportを一切変えずに済む。しかし、安定版前のSDKを使い続けることになり、バージョニングポリシー上はマイナーリリースで後方互換性のない変更もあり得る。また依存している非推奨機能、たとえばcompletionsやサンプリングパラメータは、すでに正式に不要なものと位置付けられている。1.0へ進めば、HTTP層を今フル監査する代わりに、ベータではない安定したAPI面を得られる。判断材料は、自分たちが所有するHTTP層のコード量だ。素のAnthropic()を1回呼ぶだけのサービスなら移行は簡単だが、カスタムtransportとrespxテスト群を持つプラットフォームなら、リリース前に見えない失敗の検証を済ませるべきだ。
関連記事：同じ週にベータを終了したSkills API、そして8月10日に恒久化されたSonnet 5の料金。いずれもClaude Platformリリースが続いた時期の話題だ。