◉CLAUDE LABEN
●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました
記事一覧/API & SDK
⬡ API & SDK/2026-07-12上級

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

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

Claude50API27SDK4timeout8コスト最適化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/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

⬡ API & SDK2026-07-24
メモリストアの棚卸しが半分しか返らない — path_prefix セグメント一致への移行
agent-memory-2026-07-22 で memories.list が変わりました。順序固定・depth 厳格化・path_prefix のセグメント一致。件数が音もなく半減した実例と、破壊的変更に耐える棚卸し層、呼び出し箇所を ast で洗い出す方法、depth=1 再帰の走査コストの実測をまとめます。
⬡ API & SDK2026-03-15
Claude APIでAIチャットボットを実装する — ストリーミング・会話履歴・コスト最適化まで
Claude API でチャットボットを最小構成から組み上げた記録です。会話履歴の管理、ストリーミング、FastAPI での公開、履歴のコスト最適化、LINE・Telegram・Discord への接続、PII マスキングまで動くコードで扱います。リトライは待ち方を手元で計測し、ジッタと retry-after を入れた形に作り直しました。
⬡ API & SDK2026-08-01
会話の途中でツールを差し替える — プロンプトキャッシュを守るツールレジストリの設計
ターン間でツールを追加・削除できるようになった一方、ツール定義はキャッシュプレフィックスの最前列にあります。12種類の変更を指紋で実測し、安定コアと揮発テールに分けるレジストリ設計とガード実装をまとめました。