※本ページにはプロモーション(広告)が含まれています
【2026年最新版】Claude APIのレート制限エラー(429/529)が出る原因と対処法【完全ガイド】
「Claude APIを呼び出すと429エラーや529エラーが返ってくる」「rate_limit_errorやoverloaded_errorが頻発して困っている」——Anthropic Claude APIを活用した開発では、レート制限エラーは避けて通れない課題です。本記事では、エラーの仕組みから実装レベルの対処法まで、わかりやすく解説します。
この記事でわかること
- Claude APIの429(rate_limit_error)と529(overloaded_error)の違い
- TPM・RPM・TPDという3種類のレート制限の仕組み
- ティア(Tier1〜Tier5)別の制限値一覧
- 指数バックオフを使ったリトライ実装方法(Pythonサンプルコード付き)
- プロンプトキャッシュでトークン使用量を削減する方法
- 制限に達した場合のモデル切り替え戦略

エラーの種類と意味を理解する
HTTP 429: rate_limit_error(レート制限)
429エラーは、一定時間内に許可されたリクエスト数またはトークン数の上限を超えた場合に返ってきます。レスポンスボディには以下のような内容が含まれます。
{
"type": "error",
"error": {
"type": "rate_limit_error",
"message": "Number of request tokens has exceeded your per-minute rate limit..."
}
}
429エラーは一時的なものです。制限は時間単位・日単位でリセットされるため、適切な待機とリトライで解決できます。
HTTP 529: overloaded_error(サーバー過負荷)
529エラーはAnthropicのAPIサーバーが一時的に高負荷状態にあることを示します。これはユーザー側のリクエスト量とは無関係に発生する場合があり、数秒〜数分待機してからリトライすることで解決することがほとんどです。
レート制限の3種類(TPM・RPM・TPD)
制限の種類と説明
| 略語 | 正式名称 | 説明 | リセット周期 |
|---|---|---|---|
| TPM | Tokens Per Minute | 1分あたりの入出力トークン合計数 | 1分ごと |
| RPM | Requests Per Minute | 1分あたりのAPIリクエスト数 | 1分ごと |
| TPD | Tokens Per Day | 1日あたりの入出力トークン合計数 | 24時間ごと(UTC) |
ティア別制限値(claude-3-5-sonnet参考値)
| ティア | 条件 | RPM | TPM | TPD |
|---|---|---|---|---|
| Tier 1 | $5以上チャージ | 50 | 40,000 | 1,000,000 |
| Tier 2 | $40以上使用かつ7日以上 | 1,000 | 80,000 | 2,500,000 |
| Tier 3 | $200以上使用かつ14日以上 | 2,000 | 160,000 | 5,000,000 |
| Tier 4 | $400以上使用かつ14日以上 | 4,000 | 400,000 | 10,000,000 |
| Tier 5 | $4,000以上使用かつ1ヶ月以上 | 4,000+ | 800,000+ | 50,000,000+ |
※ 制限値はモデルやAnthropicの方針変更により変わることがあります。最新値はconsole.anthropic.comのダッシュボードで確認してください。

対処法1: 指数バックオフによるリトライ実装
レート制限エラーへの最も重要な対処法は、指数バックオフ(Exponential Backoff)を使ったリトライ実装です。エラーが出るたびに待機時間を2倍にしていくことで、サーバー負荷を増やさずに再試行できます。
Pythonサンプルコード(指数バックオフ)
import anthropic
import time
import random
client = anthropic.Anthropic()
def call_claude_with_retry(
messages,
model="claude-3-5-sonnet-20241022",
max_retries=5,
base_delay=1.0
):
"""指数バックオフでClaudeAPIを呼び出す"""
for attempt in range(max_retries):
try:
response = client.messages.create(
model=model,
max_tokens=1024,
messages=messages
)
return response
except anthropic.RateLimitError as e:
if attempt == max_retries - 1:
raise
# ジッター付き指数バックオフ
delay = base_delay * (2 ** attempt) + random.uniform(0, 1)
print(f"レート制限エラー。{delay:.1f}秒後にリトライ({attempt+1}/{max_retries})")
time.sleep(delay)
except anthropic.APIStatusError as e:
if e.status_code == 529: # overloaded
delay = base_delay * (2 ** attempt)
print(f"サーバー過負荷。{delay:.1f}秒後にリトライ")
time.sleep(delay)
else:
raise
重要なポイント:ジッター(Jitter)の追加
複数のクライアントが同時にリトライする「Thundering Herd問題」を避けるため、待機時間にランダムなジッター(乱数)を加えることが重要です。上記コードのrandom.uniform(0, 1)がその役割を果たしています。
Retry-Afterヘッダーの活用
429エラーのレスポンスヘッダーにはretry-afterが含まれる場合があります。この値(秒数)を優先的に使用することで、不必要な長待機を避けられます。
except anthropic.RateLimitError as e:
retry_after = e.response.headers.get("retry-after")
if retry_after:
wait_time = float(retry_after)
else:
wait_time = base_delay * (2 ** attempt)
time.sleep(wait_time)
対処法2: プロンプトキャッシュでTPMを削減
Anthropicのプロンプトキャッシュ(Prompt Caching)機能を使うと、同じシステムプロンプトや長い文書を繰り返し送信する際のトークン消費を最大90%削減できます。キャッシュされたトークンはTPMカウントへの影響も小さくなります。
プロンプトキャッシュの使い方(Python)
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=1024,
system=[
{
"type": "text",
"text": "あなたは優秀なアシスタントです。以下の長文ドキュメントを参照して回答してください。\n\n" + long_document,
"cache_control": {"type": "ephemeral"} # キャッシュを有効化
}
],
messages=[{"role": "user", "content": "この文書の要点は?"}]
)
キャッシュはモデル・パラメーター・プロンプトが完全一致する場合に適用されます。同じシステムプロンプトを使い回す場合に特に効果的です。

対処法3: モデルの切り替えによる負荷分散
claude-3-5-sonnetなどの上位モデルがレート制限に達した場合、より軽量なモデル(claude-3-haiku)に切り替えることで、同じTPM制限内で多くのリクエストを処理できます。
モデル別トークン効率の比較
| モデル | 速度 | コスト(入力/1Mトークン) | 推奨用途 |
|---|---|---|---|
| claude-3-5-sonnet | 速い | $3.00 | 複雑な推論・コード生成 |
| claude-3-haiku | 非常に速い | $0.25 | 分類・要約・シンプルなQ&A |
| claude-3-opus | やや遅い | $15.00 | 最高品質が必要なタスク |
対処法4: バッチAPIでTPD制限を回避
AnthropicのMessage Batches APIを使うと、リクエストをバッチ形式でまとめて送信できます。バッチAPIは通常のAPIより制限が緩く、コストも50%オフです。リアルタイム応答が不要なタスク(大量のテキスト分類・要約など)に最適です。
# バッチリクエストの作成
batch = client.messages.batches.create(
requests=[
{
"custom_id": f"req_{i}",
"params": {
"model": "claude-3-haiku-20240307",
"max_tokens": 256,
"messages": [{"role": "user", "content": text}]
}
}
for i, text in enumerate(texts)
]
)
print(f"Batch ID: {batch.id}")
対処法5: ティアアップグレードを申請する
現在のティアの制限が事業要件に対して恒久的に不足している場合は、Anthropicに制限引き上げ(Rate Limit Increase)を申請できます。
- console.anthropic.comにログイン
- 「Settings」→「Limits」画面を開く
- 「Request Limit Increase」ボタンをクリック
- 用途・月間リクエスト数の見込みなどを記入して送信
Tier 1〜4は自動的に使用実績によってアップグレードされますが、Tier 5相当の大規模利用はAnthropicとの個別契約が必要です。
この記事に関連するおすすめ商品
Python AIエンジニアリング入門書
約2,500円〜
APIリトライ・非同期処理・レート制限対応の実践的な解説書
高性能開発用ノートPC(最新モデル)
約120,000円〜
AI・機械学習開発に最適な高メモリ・高速CPU搭載モデル
LLMアプリ開発実践ガイド
約3,000円〜
Claude・GPT・Gemini APIを使ったプロダクション開発の指南書
※ 価格は変動します。最新価格はリンク先でご確認ください
よくある質問(FAQ)
Q1. 429エラーと529エラーはどう違いますか?
429(rate_limit_error)は自分のAPIキーが制限に達したことを示します。一方、529(overloaded_error)はAnthropicのサーバー全体が混雑しているサービス側の問題です。429は制限リセットまで待つ必要があり、529は数秒〜数分待ってリトライすれば解決することがほとんどです。
Q2. どのくらい待てば429エラーが解消しますか?
TPMおよびRPM制限は1分単位でリセットされます。TPD制限はUTC 0:00(日本時間 午前9時)にリセットされます。レスポンスヘッダーのx-ratelimit-reset-tokensやx-ratelimit-reset-requestsに次のリセット時刻が含まれているので参照してください。
Q3. 現在の制限使用状況をリアルタイムで確認できますか?
はい、APIレスポンスのヘッダーに現在の使用量が含まれます。x-ratelimit-remaining-requests(残りリクエスト数)、x-ratelimit-remaining-tokens(残りトークン数)を確認してください。Anthropicコンソール(console.anthropic.com)でもダッシュボードから使用量を確認できます。
Q4. 並列リクエストを大量に送るとどうなりますか?
RPM制限に達すると429が返ります。並列処理を行う場合はセマフォ(Semaphore)で同時実行数を制限するか、asyncioと組み合わせてスロットリングを実装することを推奨します。目安として、Tier 1(RPM 50)の場合は同時実行を5〜10程度に抑えてください。
Q5. プロンプトキャッシュはどのモデルで使えますか?
プロンプトキャッシュ(cache_control: ephemeral)は、claude-3-5-sonnet・claude-3-haiku・claude-3-opusなど主要モデルで利用できます。キャッシュは最低1,024トークン以上のブロックに対して有効で、キャッシュヒット時の入力コストは通常の10%になります。
Q6. ティアを上げるにはどうすればよいですか?
Tier 1〜4は使用額と使用期間の条件を満たすと自動的に昇格します。例えばTier 2への昇格条件は「$40以上使用かつ7日以上」です。Anthropicコンソールの「Settings → Limits」で現在のティアと昇格条件を確認できます。より高い制限が早急に必要な場合は、同ページから申請も可能です。
Q7. Node.js(JavaScript)でも同様のリトライ実装はできますか?
はい、Anthropic公式のNode.js SDKも同様のエラー型(RateLimitError)を提供しています。try/catchでキャッチしてsetTimeoutで待機するパターン、またはaxios-retryなどのライブラリを活用してください。基本的な指数バックオフのロジックはPythonと同様です。
Q8. max_tokensを減らすとTPMの節約になりますか?
はい、max_tokensパラメーターはレスポンスの最大トークン数を制限します。実際のTPMカウントは入力トークン+実際の出力トークン数で計算されるため、短い出力で十分なタスクではmax_tokensを小さく設定することでTPMを節約できます。
まとめ
Claude APIのレート制限エラー(429/529)への対処は、「指数バックオフリトライの実装」「プロンプトキャッシュによるTPM削減」「軽量モデルへの切り替え」「バッチAPIの活用」「ティアアップグレード申請」の5段階で考えることが重要です。
まずは指数バックオフ+ジッターのリトライ実装を最初に行い、それでも頻繁にエラーが出る場合はプロンプトキャッシュの導入やバッチAPIへの移行を検討してください。長期的にはティアアップグレードで根本的な解決を図ることをおすすめします。
minto.tech スマホ(Android/iPhone)・PC(Mac/Windows)の便利情報をお届け! 月間アクセス160万PV!スマートフォン、タブレット、パソコン、地デジに関する素朴な疑問や、困ったこと、ノウハウ、コツなどが満載のお助け記事サイトはこちら!