◉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-03-29中級

Claude API の 429 エラーを 6 サイト同時運用で観測して書き直した本番リトライの実装

Claude API で立て続けに 429 が出るとき、現場で本当に効くのは Retry-After だけに頼らないリトライ設計です。6 サイトの自動投稿パイプラインで観測した発生分布、ジッター付き指数バックオフ・トークンバケット・冪等性キーの実装、Batch API への切り替え判断基準までを実体験ベースでまとめました。

Claude API127rate limit4294retry6production87

✦ プレミアム記事

夕方、6 サイト分のコンテンツを順番に Claude API へ投げているスケジュールタスクから「429 Too Many Requests」が立て続けに返ってきて、その日の自動投稿が半分しか終わらないという日が、個人開発を続けるなかで何度かありました。私はコンテンツサイトを 6 つ並列で運用していて、記事生成・整合性チェック・SEO レポートと、API を一日中叩き続けています。加えて自作アプリの運用でも、レポート集計や画像分類で Claude API を継続的に使っています。

「公式の指数バックオフ実装をコピーしてもなぜか 429 が止まらない」という相談を何度も受けるなかで、自分のパイプラインで稼働しているコードと、観測してきたメトリクスを整理しました。Retry-After ヘッダーだけを信じて書いた最初の実装はすぐに破綻しました。ヘッダーの値が実態より短い場面、Retry-After が返ってこない場面、リトライ全体が同期して集中バーストになる場面があり、それぞれ別の手当てが必要でした。

Claude API の 429 が出る 3 つの軸を一度に握る

Claude API のレート制限は 3 つの独立した軸で同時に効きます。1 軸でも上限を超えると 429 が返ります。

  • RPM — 1 分あたりのリクエスト数
  • TPM — 1 分あたりの入出力トークン数(入力プロンプト + max_tokens を含む)
  • TPD — 1 日あたりの累計トークン数

私が最初にハマったのは TPM です。RPM だけ見て「1 秒 1 リクエストなら問題ないはず」と決め打ちしていたのですが、長文の MDX 生成では 1 リクエストで 8,000 〜 12,000 トークン使うこともあり、結果的に TPM 側で詰まっていました。プランごとの上限値はダッシュボードで確認できますが、運用側の感覚値としては「RPM の半分以上の頻度で叩く場合は、ほぼ TPM 側で先に詰まる」と覚えておくと安全です。

レスポンスヘッダには次の情報が常に返ります。

RateLimit-Limit-Requests: 50
RateLimit-Limit-Tokens: 90000
RateLimit-Remaining-Requests: 35
RateLimit-Remaining-Tokens: 72000
RateLimit-Reset-Requests: 2026-03-29T22:05:00Z
RateLimit-Reset-Tokens: 2026-03-29T22:05:00Z
Retry-After: 15

Retry-After は秒、*-Reset-* は ISO8601 の絶対時刻で返ってきます。後述しますが、この 2 つの間に微妙なズレが出る瞬間があり、ここを設計で吸収する必要があります。

6 サイト並行運用で観測した 429 の発生分布

私の環境で過去 90 日間に Claude API へ投げたリクエストのうち、429 が返った割合と内訳を整理しました。サンプル母集団はおよそ 18 万リクエストです。

  • 全体の 429 発生率: 約 0.42%(修正前は約 4.1%)
  • RPM 起因: 全 429 のうち約 12%
  • TPM 起因: 全 429 のうち約 71%
  • 単発の overloaded 同居 429: 約 17%
  • Retry-After 中央値: 8 秒、95 パーセンタイル値: 38 秒
  • リトライ 1 回目で復帰: 約 78%、3 回以内で復帰: 約 96%

「修正前 4.1%」というのは、最初に書いた「Retry-After をそのまま sleep してリトライ」というナイーブ実装の数字で、これは見るに堪えない値でした。後述するジッター + トークンバケットを入れてから 10 分の 1 程度まで下がっています。

時間帯で見ると、日本時間の 02:00〜04:00 と 11:00〜15:00 に発生が偏ります。スケジュールタスクが集中している時間帯と一致するため、ここはオフピーク分散をかけるとさらに改善できる余地があります。

✦

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

この記事の続きを読む

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

この記事で得られること
✦6 サイト並行運用で観測した 429 の発生分布と Retry-After ヘッダーの遅延同期問題
✦ジッター付き指数バックオフ・冪等性キー・トークンバケットの動作する完全実装(Python と TypeScript)
✦リクエスト効率化と Batch API 切り替えで 429 発生率を 1/10 に下げるための具体的な判断基準
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

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

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

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

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

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

関連記事

⬡ API & SDK2026-04-24
Claude API を Python で本番運用する — レート制限・リトライ・タイムアウトの設計
Claude API を本番サービスに組み込むなら、429・503・Read timeout とどう付き合うかが品質を決めます。私が実運用で落ち着いたリトライとタイムアウトの設計方針を、コード込みで整理しました。
⬡ API & SDK2026-03-27
Claude API プロダクション耐障害設計パターン — モデルルーティング・サーキットブレーカー・フォールバック戦略の実装ガイド
Claude APIを本番運用で支える耐障害設計の実装パターン。サーキットブレーカー、モデルルーティング、フォールバックチェーン、リトライ戦略、ディザスタリカバリをTypeScriptの実装コードと、運用で気づいた注意点を添えて整理しました。
⬡ API & SDK2026-10-14
retry-after が 120 秒の 429 を受けると、Anthropic SDK の自動リトライは 120 秒待とうとしました
Anthropic SDK の自動リトライを模擬サーバーで12通り確かめました。既定は2回まで、retry-after は上限なしで従い、上限到達の429は待っても通りません。待ち時間と総時間に上限を持つ呼び出し口のコードと実測ログを載せます。