CLAUDE LABEN
RELEASE — Claude Code v2.1.243 が8月25日に公開されました。使用量・モデル・ログイン・信頼性にまたがる広い改善が入っていますUSAGE — /usage にループごとの内訳が追加されました。実行回数・総トークン・1回あたりのトークン・最終実行が並ぶため、饒舌になっている /loop タスクを特定できますSETTINGS — modelPicker で /model の一覧を独自の順序とラベルに差し替えられます。promptCacheTtl と subagentPromptCacheTtl でキャッシュの保持時間も分けられますLOGIN — API キーの発行を許可していない組織向けに、Anthropic Console アカウントでのキーレスサインインが /login に追加されましたPERFORMANCE — ネイティブ配布物が zstd 圧縮となり Linux x64 で約340MBから約75MBへ縮みました。セッションあたりのメモリも概ね40〜60MB下がっていますFIX — v2.1.245 が glibc 2.44 を採用したディストリビューションでの起動クラッシュを修正しました。Arch Linux・CachyOS・Fedora Rawhide が対象ですRELEASE — Claude Code v2.1.243 が8月25日に公開されました。使用量・モデル・ログイン・信頼性にまたがる広い改善が入っていますUSAGE — /usage にループごとの内訳が追加されました。実行回数・総トークン・1回あたりのトークン・最終実行が並ぶため、饒舌になっている /loop タスクを特定できますSETTINGS — modelPicker で /model の一覧を独自の順序とラベルに差し替えられます。promptCacheTtl と subagentPromptCacheTtl でキャッシュの保持時間も分けられますLOGIN — API キーの発行を許可していない組織向けに、Anthropic Console アカウントでのキーレスサインインが /login に追加されましたPERFORMANCE — ネイティブ配布物が zstd 圧縮となり Linux x64 で約340MBから約75MBへ縮みました。セッションあたりのメモリも概ね40〜60MB下がっていますFIX — v2.1.245 が glibc 2.44 を採用したディストリビューションでの起動クラッシュを修正しました。Arch Linux・CachyOS・Fedora Rawhide が対象です
記事一覧/API & SDK
API & SDK/2026-07-12上級

非ストリーミングの長い応答が10分の壁で黙って二重課金されていた — SDK既定のタイムアウトと自動リトライを設計し直す

Anthropic SDK の既定タイムアウト10分と自動リトライ2回が、長い非ストリーミング応答を裏で二重に走らせて課金することがあります。発生の仕組みと、ストリーミング切替・明示的な timeout/max_retries・ローカル台帳で止める実装を、実測値とともにまとめました。

Claude47API27SDK4timeout8コスト最適化26

プレミアム記事

夜間バッチのコストが、ある週だけ静かに膨らんでいました。生成した記事数も、要約した件数も先週とほぼ同じなのに、api-sdk の請求だけが伸びている。原因を掴むのに半日かかりました。犯人は、あるはずのないところにいたのです。

max_tokens を 16,000 まで上げた要約タスクを、私は素直に非ストリーミングで書いていました。client.messages.create(...) を呼んで、返ってきたテキストを受け取るだけの、ごく普通のコードです。ところがこの生成、混雑した時間帯だと稀に9〜11分かかることがありました。そして Anthropic SDK の既定のリクエストタイムアウトは、ちょうど10分です。

10分を1秒でも超えると、SDK 側の読み取りタイムアウトが発火します。すると SDK は「一時的な失敗」と判断し、既定の自動リトライ(最大2回)で同じ要求をもう一度投げます。ここに落とし穴がありました。最初の要求はサーバー側でまだ生成を続けており、完了すれば出力トークン分は課金される。 そこへリトライが独立した2本目の要求として走る。私が受け取る応答は1つでも、課金は2回分。これが「静かに膨らんだ請求」の正体でした。

以下では、その仕組みを SDK の挙動レベルまで分解し、二重課金を根本から止めるための3つの設計変更を、実際に夜間バッチへ入れたコードとともにたどっていきます。個人開発で複数サイトの処理を無人で回している方ほど、気づかないまま払い続けている類の出費だと思います。

既定値を読み違えると、無人運用で牙をむく

まず、SDK が黙って持っている既定値を正確に押さえます。Anthropic の Python SDK では、クライアント生成時に次の2つが既定で効いています。

設定既定値無人運用での意味
timeout10分(600秒)長い生成が10分を超えると読み取りタイムアウトが発火する
max_retries2回タイムアウトを含む一時エラーで、同じ要求を最大2回まで自動再送する

自動リトライ自体は正しい機能です。429(レート制限)や 5xx、接続断のような「もう一度投げれば通る」エラーには、指数バックオフ付きの再送がよく効きます。問題は、読み取りタイムアウトが「もう一度投げれば通る」エラーではないことです。

タイムアウトは、あくまでクライアント側が待つのをやめた合図にすぎません。サーバーはこちらの都合を知らず、粛々と生成を続けています。Messages API の課金は、生成された出力トークンに対して発生します。つまり最初の要求は、こちらが受け取らなくても完走すれば課金される。そこへリトライが2本目を走らせれば、同じ内容の生成に二重の料金を払うことになります。

Anthropic SDK は、この危険を認識しています。max_tokens を大きくした非ストリーミング要求に対しては、SDK が「この要求は10分を超える可能性がある」旨の警告を出し、ストリーミングの利用を推奨します。私はこの警告を、恥ずかしながら長いあいだログの中で見過ごしていました。警告は正しかったのです。

なぜタイムアウトのリトライだけが特別に危ないのか

一時エラーのリトライが安全なケースと、危険なケースを分けて考えると、設計の勘所が見えてきます。

失敗の種類サーバー側の状態リトライの安全性
429 / 529(過負荷)要求は受理されず処理されていない安全。再送すれば1回分だけ課金
接続確立の失敗要求がサーバーに届いていない安全。まだ何も生成されていない
読み取りタイムアウト要求は処理中、生成が続いている可能性大危険。完走すれば二重課金

ポイントは、Messages API の単発リクエストには、Stripe のような冪等キー(同じキーの再送を1回として扱う仕組み)が用意されていないことです。私たちがローカルで「これは再送だ」と管理しない限り、サーバーから見た2本の要求は完全に別物です。だからこそ、タイムアウトが絡む再送は、SDK に丸投げしてはいけないのです。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
SDK既定の10分タイムアウトと自動リトライ2回が、非ストリーミングの長い応答を裏で二重に走らせて課金する仕組みを分解します
ストリーミング切替・明示的な timeout と max_retries・ローカル台帳による冪等な記録で二重課金を止める実装コード
夜間バッチで二重課金の発生率を約2%から0%に落とした設定値と、その検証手順
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥2,480 の永久アクセス
メンバーシップを見る →

関連記事

API & SDK2026-07-24
メモリストアの棚卸しが半分しか返らない — path_prefix セグメント一致への移行
agent-memory-2026-07-22 で memories.list が変わりました。順序固定・depth 厳格化・path_prefix のセグメント一致。件数が静かに半減した実例と、破壊的変更に耐える棚卸し層、depth=1 再帰の走査コストの実測をまとめます。
API & SDK2026-07-14
ユーザーに届くAI生成の短文を、公開前に二段ゲートで止める
アプリでユーザーに届くAI生成の短文を、決定的ルール層とClaude分類層の二段ゲートで公開前に検査する設計です。fail-closedを芯に据えた判定統合、生成時に検疫して配信時は取り出すだけの構成、生成数で効くコスト設計、人間のサンプリング体制まで実装コード付きで整理しました。
API & SDK2026-06-22
Claude API の静的キーをやめる — Workload Identity Federation で CI と本番を鍵なしに切り替える
Claude Platform で一般提供が始まった Workload Identity Federation を使い、sk-ant- 形式の静的キーを数分で失効する OIDC トークンへ移行する設計を扱います。GitHub Actions の鍵なし認証、移行手順、トークン更新まで具体的に整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →