Claude APIを業務システムに組み込んでいると、ある日突然 429 rate_limit_error というエラーに遭遇することがあります。本記事では、Anthropic公式ドキュメントの情報をもとに、レート制限の仕組みと429エラーの原因、そしてすぐに実践できる具体的な対処法を整理します。
Claude APIの429エラーとは
Claude APIでは、不正利用の防止とサービス容量の管理のため、組織（Organization）単位でAPIの使用量に上限が設けられています。この上限を超えると、APIは429エラー（rate_limit_error）を返します。
エラーレスポンスにはどのレート制限を超えたかを示す情報と、次にリクエストできるまでの待機秒数を示す retry-after ヘッダーが含まれます。まずはこのエラーを闇雲に再試行するのではなく、原因を正しく切り分けることが重要です。
レート制限の仕組み（RPM・ITPM・OTPM）
Messages APIのレート制限は、モデルごとに以下の3つの指標で管理されています。
- RPM（Requests Per Minute）：1分あたりの最大リクエスト数
- ITPM（Input Tokens Per Minute）：1分あたりの最大入力トークン数
- OTPM（Output Tokens Per Minute）：1分あたりの最大出力トークン数
このいずれかの上限に達すると429エラーが発生します。
使用量ティア（Usage Tier）による違い
組織は利用実績とアカウントの状態に応じて、Start・Build・Scale・Customという使用量ティアに自動的に振り分けられます。新規組織や利用実績の少ない組織は、標準よりも低い制限からスタートし、利用実績を積むことで自動的に上位ティアへ移行します。
例えば、StartティアのClaude Sonnet 5は1分あたり1,000リクエスト・入力200万トークン・出力40万トークンが上限です（2026年8月時点）。現在の組織のティアと制限は、Claude Consoleの「Limits」ページでいつでも確認できます。
トークンバケットアルゴリズムとキャッシュ対応ITPM
Claude APIのレート制限は「トークンバケットアルゴリズム」で管理されており、容量は一定間隔でリセットされるのではなく、上限まで継続的に補充されていく仕組みです。そのため、短時間にリクエストが集中すると、平均的には制限内でも429エラーが発生することがあります。
また、実務上とても重要なポイントとして、多くのAPIプロバイダーはキャッシュの有無にかかわらず全トークンを合算した「TPM」で制限しますが、ほとんどのClaudeモデルでは、キャッシュされていない入力トークンのみがITPMレート制限にカウントされます。例えば200万ITPMの制限でキャッシュヒット率が80%であれば、実質的に1分あたり合計1,000万トークン（非キャッシュ200万＋キャッシュ800万）を処理できる計算になります。
429エラーの原因を切り分ける
レスポンスヘッダーで原因を特定する
APIレスポンスには、現在のレート制限の状態を示すヘッダーが含まれています。特に以下のヘッダーを確認することで、RPM・ITPM・OTPMのどれが制限に達したのかを把握できます。
| ヘッダー | 内容 |
|---|---|
retry-after | 再試行可能になるまでの待機秒数 |
anthropic-ratelimit-requests-remaining | 残りリクエスト数 |
anthropic-ratelimit-input-tokens-remaining | 残り入力トークン数 |
anthropic-ratelimit-output-tokens-remaining | 残り出力トークン数 |
アクセラレーション制限にも注意
組織の使用量が急激に増加した場合、通常のRPM・ITPM・OTPMの範囲内であっても、「アクセラレーション制限」により429エラーが発生することがあります。これを避けるには、トラフィックを急激に増やすのではなく、徐々にランプアップし、一貫した利用パターンを維持することが推奨されています。
429エラーへの具体的な対処法
1. 指数バックオフ（Exponential Backoff）を実装する
最も基本的かつ効果的な対処法は、クライアント側で指数バックオフを実装することです。実は公式SDKは接続エラーやレート制限、5xxサーバーエラーなどの一時的な障害に対して、デフォルトで2回まで指数バックオフによる自動再試行を行います。retry-after ヘッダーが存在する場合はその値に従って待機します。
より細かく制御したい場合は、以下のように自前でリトライ処理を実装することも可能です。
import time
import anthropic
client = anthropic.Anthropic()
def call_with_backoff(**kwargs):
max_retries = 5
for attempt in range(max_retries):
try:
return client.messages.create(**kwargs)
except anthropic.RateLimitError as e:
wait = float(e.response.headers.get("retry-after", 2 ** attempt))
print(f"レート制限に到達。{wait}秒待機して再試行します（{attempt + 1}回目）")
time.sleep(wait)
raise RuntimeError("リトライ上限に達しました")
message = call_with_backoff(
model="claude-sonnet-5",
max_tokens=1024,
messages=[{"role": "user", "content": "こんにちは"}],
)大規模なシステムでは、SDKの max_retries オプションで再試行回数を調整するだけでも十分な場合が多く、まずはデフォルトの挙動を把握した上で必要に応じてカスタマイズするのがおすすめです。
2. プロンプトキャッシングでITPMを節約する
システムプロンプトや大きなコンテキストドキュメント、ツール定義、会話履歴など、繰り返し利用するコンテンツはプロンプトキャッシングの対象にすることで、実効スループットを大きく引き上げられます。キャッシュされたトークンはITPM制限にカウントされないため、レート制限そのものを引き上げなくても、実際に処理できる総トークン量を増やせます。Claude Consoleの「Usage」ページでキャッシュヒット率を監視しながら、キャッシュ戦略を最適化するとよいでしょう。
3. Message Batches APIをリアルタイム処理以外に活用する
即時応答が不要なバッチ処理（大量データの一括分類・要約など）には、Message Batches APIの利用を検討しましょう。Messages APIとは別のレート制限プールが用意されており、数千件規模のリクエストをまとめて処理キューに投入できます。
4. リクエストをキューイング・分散させる
複数のワーカーやジョブから同時にAPIを呼び出す構成では、リクエストキューを設けて処理を平準化することが有効です。加えて、OTPM（出力トークン）のレート制限は実際に生成されたトークン数のみでカウントされ、max_tokens パラメータの値自体は制限計算に影響しません。そのため、必要以上に max_tokens を絞る必要はなく、余裕を持った値を設定しても問題ありません。
5. レート制限の引き上げをリクエストする
上記の対策を行ってもなお制限に達してしまう場合は、Claude Consoleの「Limits」ページから「Request rate limit increase」を利用してレート制限の引き上げを申請できます。緊急性が高い場合は、Anthropicサポートに直接問い合わせることも可能です。
Claude Codeで「レート制限に達しました」と表示された場合
Claude Codeを利用している開発者向けには、コンテキストが肥大化するとレート制限に到達しやすくなるため、/clear コマンドで会話履歴をリセットする習慣が、コストゼロ・設定不要の対処法として公式に推奨されています。API経由での実装と異なり、Claude Codeの利用上限はプランやセッションの状況によっても変動するため、頻発する場合は利用状況を定期的に確認しておくと安心です。
まとめ
Claude APIの429エラーは、RPM・ITPM・OTPMのいずれかの上限超過、またはアクセラレーション制限が主な原因です。対処法としては、指数バックオフの実装、プロンプトキャッシングによるITPM節約、Message Batches APIの活用、リクエストの平準化、そして必要に応じたレート制限引き上げの申請が挙げられます。まずはレスポンスヘッダーで原因を切り分け、自社の利用パターンに合った対策を組み合わせることが、安定したAPI運用への近道です。
