CLAUDE LABEN
SONNET — Claude Sonnet 5がClaude Codeの既定モデルになりました。ネイティブ100万トークンのコンテキストに対応し、8月31日まで導入価格が適用されますCHROME — Claude in Chromeが一般提供となり、ブラウザ上の作業をそのままClaudeに委ねられるようになりましたCOWORK — Cowork(コワーク)がモバイルとWebに広がり、セッションとファイルが端末をまたいで引き継がれます。まずMaxユーザー向けにbeta提供ですDATAVIZ — チャートやダッシュボードの設計を助ける/datavizスキルがClaude Codeに追加されましたAGENTS — バックグラウンド通知・下書きPRの引き継ぎ・フェイルオーバー改善など、エージェントの運用まわりが強化されていますENTERPRISE — Enterprise管理者向けに詳細な管理分析・モデル単位のエンタイトルメント・支出アラートが加わりましたSONNET — Claude Sonnet 5がClaude Codeの既定モデルになりました。ネイティブ100万トークンのコンテキストに対応し、8月31日まで導入価格が適用されますCHROME — Claude in Chromeが一般提供となり、ブラウザ上の作業をそのままClaudeに委ねられるようになりましたCOWORK — Cowork(コワーク)がモバイルとWebに広がり、セッションとファイルが端末をまたいで引き継がれます。まずMaxユーザー向けにbeta提供ですDATAVIZ — チャートやダッシュボードの設計を助ける/datavizスキルがClaude Codeに追加されましたAGENTS — バックグラウンド通知・下書きPRの引き継ぎ・フェイルオーバー改善など、エージェントの運用まわりが強化されていますENTERPRISE — Enterprise管理者向けに詳細な管理分析・モデル単位のエンタイトルメント・支出アラートが加わりました
記事一覧/API & SDK
API & SDK/2026-07-12上級

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

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

Claude43API25SDK4timeout7コスト最適化25

プレミアム記事

夜間バッチのコストが、ある週だけ静かに膨らんでいました。生成した記事数も、要約した件数も先週とほぼ同じなのに、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/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

API & SDK2026-06-22
Claude API の静的キーをやめる — Workload Identity Federation で CI と本番を鍵なしに切り替える
Claude Platform で一般提供が始まった Workload Identity Federation を使い、sk-ant- 形式の静的キーを数分で失効する OIDC トークンへ移行する設計を扱います。GitHub Actions の鍵なし認証、移行手順、トークン更新まで具体的に整理しました。
API & SDK2026-06-22
pause_turn の継続ループに上限を入れる — 無人で長時間サーバーツールを安全に回す
web_search や code execution など長時間サーバーツールを使うと返ってくる pause_turn を、無人運用で安全に継続する設計をまとめました。4種類の stop_reason を1ループで分岐し、継続回数と時間に上限を入れ、セグメントを跨ぐ usage を数える実装まで扱います。
API & SDK2026-06-21
公開したくない社内サービスに Managed Agents を繋ぐ — MCP トンネル設計の勘所
Claude Managed Agents から、インターネットに公開していない社内 MCP サーバーへ安全に接続する設計を扱います。MCP トンネル・自前サンドボックス・認可境界・障害時の縮退まで、実運用で必要な判断を整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →