Claude Codeや Claude APIを使っていると、突然こんなメッセージが表示されることがある。「Server is temporarily limiting requests (not your usage limit)」。有料プランを契約しているのに、あるいは今まで普通に動いていたのに、なぜ？という疑問を持つ方は多い。この記事では、このエラーの正確な意味、原因、そして今すぐできる対処法から中長期的な解決策まで、公式ドキュメントと実際の利用者報告をもとに詳しく解説する。
このエラーは「あなたのせい」ではない
まず最も重要なことから伝えよう。このエラーメッセージのカッコ書きに注目してほしい。「(not your usage limit)」とわざわざ書いてある。Anthropicが意図的に付け加えたこの一文は、「あなた個人の使用量が上限に達したわけではない」という意味だ。
技術的な分類では、これはHTTP 529エラー（overloaded_error）と呼ばれる。Anthropicの公式ドキュメントには「The API is temporarily overloaded（APIが一時的に過負荷状態にある）」と定義されている。つまりAnthropicのサーバー全体が混雑しており、すべてのユーザーに対して処理を制限している状態だ。無料プランでも有料プランでも、同じように影響を受ける。
529エラーと429エラーは別物
「Server is temporarily limiting requests」は529エラー（サーバー過負荷）。「あなた自身の使用量が上限に達した」場合は429エラー（rate_limit_error）になる。エラーの種類によって原因も対処法も異なる。
529と429、2種類のエラーを混同しない
Claude利用中に遭遇する「制限」には、大きく2種類がある。それぞれ原因がまったく異なるため、対処法も違う。
| エラーメッセージ | Server is temporarily limiting requests (not your usage limit) | Your account has hit a rate limit |
| 原因 | Anthropicのサーバーが全ユーザー向けに過負荷状態 | あなたのアカウントが割り当て量を超過 |
| 誰のせいか | Anthropicのインフラ側の問題 | あなた自身の使用量超過 |
| retry-afterヘッダー | なし（またはなしに近い） | あり（待機秒数が明示される） |
| 対処法の基本 | 待機してリトライ | retry-afterの秒数待機 or プラン変更 |
| 発生頻度 | 月に数回〜十数回（インフラ状況による） | 使い方によって頻繁にも稀にもなる |
Anthropicの公式ドキュメントには529エラーについてこう記述されている。「APIが全ユーザーにわたって高トラフィックを経験している際に529エラーが発生する可能性がある」。一方で429エラーは「組織の使用量が急激に増加した場合、APIのアクセラレーション制限により発生することがある」とされており、自分のアカウントの問題だ。
529エラーはなぜ起きるのか
Anthropicのサービス監視データによると、ClaudeのAPIは直近90日間の稼働率が約99%。月に1〜数回の割合でインフラ障害や高負荷が発生している。特に以下のタイミングで集中的に発生する傾向がある。
- 新モデルのリリース直後 — Claude Sonnet 4、Claude Opus 4などのリリース時にアクセスが集中する
- 太平洋時間の午前5時〜11時（JST 21時〜3時） — Anthropicが公式に「ピーク時間帯」として認めている時間帯
- 大規模な報道・バイラル直後 — SNSやニュースで話題になった直後に利用者が急増する
- クラウドインフラの障害時 — 過去にはGCP障害に連動して発生した事例もある
記録に残っている主な発生事例を見ると、2025年7月、8月、11月、12月、そして2026年初頭にかけて複数の高負荷インシデントが記録されている。多くは30分〜4時間程度で解消されている。
今すぐできる対処法
529エラーが出たときに最初にやることは、実はシンプルだ。
ステップ1 ステータスページを確認する
status.anthropic.com にアクセスして、現在インシデントが発生していないか確認する。「Investigating」「Identified」「Monitoring」などのステータスが出ていれば、Anthropic側で認識・対応中だ。この場合は待つしかない。RSSフィードも提供されており、好みのRSSリーダーで監視することもできる。
ステップ2 1〜5分待ってからリトライする
ほとんどの529エラーは数分以内に解消する。焦って連続でリクエストを送り続けると、むしろサーバーの負荷をさらに高めることになる。1分待ち、まだ出るなら3分待ち、それでも出るなら5分待つ、という段階的なアプローチが合理的だ。
ステップ3 別のモデルに切り替えてみる
AnthropicはClaudeの各モデルに対して独立したレート制限を設けている。Claude Opus 4が過負荷でも、Claude Sonnet 4やClaude Haiku 4.5は問題なく動いているケースがある。急いでいる場合はモデルを切り替えることで対処できることがある。Claude Codeでは /model コマンドでセッション中にモデルを変更できる。
claude.ai UIでも同じエラーが出る
APIだけでなく、ブラウザのclaude.ai上でも同種のサーバー過負荷エラーが表示されることがある。この場合も対処法は同じで、待機してリトライするしかない。なお、ページのリロードや再ログインでは解消しない。
開発者向け リトライ実装のベストプラクティス
APIを使って自社サービスやワークフローを構築している場合、適切なリトライロジックの実装が重要になる。
公式PythonとTypeScript SDKの挙動の違い
公式PythonSDKは、接続エラー、408、409、429、そして500以上のエラーをデフォルトで2回まで自動リトライする。しかし529エラー（overloaded_error）のリトライ挙動はSDKのバージョンや設定によって異なる。TypeScript SDKでは529を自動リトライしないという報告（GitHub Issue #791）が2025年7月時点で複数あり、手動実装が必要なケースがあった。
529と429では最適なリトライ戦略が異なる点にも注意が必要だ。
- 429エラーのとき — レスポンスの
retry-afterヘッダーを読んで、その秒数を正確に待機する。このヘッダーを無視して短い間隔でリトライしても意味がなく、むしろ制限期間が延びることがある - 529エラーのとき —
retry-afterヘッダーは必ずしも存在しない。指数バックオフ（1秒→2秒→4秒→8秒→16秒→上限30秒）でリトライする。ランダムジッター（乗数0.5〜1.5）を加えると複数クライアントの「雷群れ効果」を防げる - リトライ上限 — 529の連続リトライは最大5〜7回程度を上限とする。60秒以上経過しても解消しない場合はインシデント発生の可能性が高いため、処理を中断してステータスページを確認する
レート制限関連ヘッダーの活用
Anthropic APIのレスポンスには、現在のレート制限状態を示すヘッダーが含まれている。これを読み取ることで、リミットに近づいていることを事前に検知できる。
anthropic-ratelimit-requests-remaining | 現在の期間内の残りリクエスト数 |
anthropic-ratelimit-requests-reset | 制限がリセットされる日時（RFC 3339形式） |
anthropic-ratelimit-input-tokens-remaining | 残りの入力トークン数（ITPM） |
anthropic-ratelimit-output-tokens-remaining | 残りの出力トークン数（OTPM） |
retry-after | 429エラー時にのみ付与。待機すべき秒数 |
「remaining」系のヘッダーが小さい値を示してきたら、リクエストを意図的に間引くことで429エラーを未然に防ぐことができる。
中長期の解決策 ティアアップとPriority Tier
529エラーは一時的なサーバー負荷が原因なので、個人のプランを変えても根本解決にはならない。しかし継続的に発生して業務に支障が出る場合は、Anthropicが提供する上位の仕組みを使う選択肢がある。
API利用の場合 ティアアップで429を防ぐ
APIを通じて利用している場合、頻繁に429エラー（自分の割り当て超過）が出るならティアアップが有効だ。Anthropic APIのティアは累積クレジット購入額によって自動昇格する仕組みになっている。申請は不要で、条件を満たした時点で即時に適用される。
| Tier 1（初期） | $5〜 | 50回/分 | 50万トークン/分 |
| Tier 2 | $40以上 | 1,000回/分 | 200万トークン/分 |
| Tier 3 | $200以上 | 2,000回/分 | 500万トークン/分 |
| Tier 4 | $400以上 | 4,000回/分 | 1,000万トークン/分 |
| 月次請求（法人向け） | 要営業窓口 | 制限なし（要相談） | 制限なし（要相談） |
なお2026年5月のインフラ強化（大規模なGPUクラスター追加）を受けて、Tier 1のOpus上限が従来の3万トークン/分から50万トークン/分へ大幅に引き上げられた。これにより小規模な開発用途ではTier 1でも十分なケースが増えている。
最高優先度での処理 Priority Tier
529エラーを根本的に減らしたい企業向けに、AnthropicはPriority Tier（優先処理枠）を提供している。公式ドキュメントには「このティアのリクエストは他のすべてのリクエストより優先して処理される。これによりピーク時でも『server overloaded』エラーを最小化できる」と明記されている。
- 目標稼働率 — 99.5%（標準ティアのベストエフォートと比較して大幅な改善）
- 仕組み — Priorityキャパシティが満杯の場合は標準ティアに自動フォールバック（サービス断なし）
- 申し込み方法 — Anthropicの営業窓口（
claude.com/contact-sales/priority-tier）経由で、処理したいトークン量と期間（1/3/6/12ヶ月）を選択してコミット - 対象モデル — Claude Mythos Preview以外の全モデルで利用可能
リクエストに service_tier: "auto" を設定する
APIリクエストのパラメータに service_tier: "auto" を指定すると、Priority Tierが利用可能な場合は優先処理され、容量を超えた場合は自動的に標準処理にフォールバックする。Priority Tierと契約済みの場合はこの設定を入れておくことを推奨する。
スループットを上げるプロンプトキャッシュの活用
429エラー（自分の割り当て超過）が頻繁に出る場合、プロンプトキャッシュを活用すると実効スループットを大幅に上げられる。Anthropicの公式仕様によると、キャッシュから読み込まれたトークンは大部分のモデルでITPM（入力トークン/分）の上限にカウントされない。
たとえばシステムプロンプトが毎回5,000トークンある場合、最初のリクエストでキャッシュに登録しておけば、以降のリクエストではその5,000トークン分がITPMから差し引かれる。キャッシュヒット率が80%の場合、実質的なスループットは5倍になる計算だ。同じシステムプロンプトや背景資料を繰り返し使うユースケース（チャットボット、文書分析パイプラインなど）では特に効果が高い。
大量処理には非同期のBatch APIを使う
リアルタイム性が不要なタスク—たとえば大量の文書の一括分析、夜間バッチ処理、評価データセットの生成など—では、AnthropicのMessage Batches APIが有効だ。Batch APIはMessages APIとは独立したレート制限系統を持ち、リアルタイムAPIとリソースを奪い合わない。
- コスト — Messages APIと同じモデルを使って価格が50%オフ
- 処理時間 — 最大24時間（多くは1時間以内に完了）
- 制限 — Tier 1で1バッチあたり最大10万リクエスト、キュー上限も10万
- 用途 — ドキュメント処理、データ拡充、オフライン評価、コンテンツ生成キュー
Batch APIは通信断に強い非同期設計なので、529エラーが出ても処理が失われない。ポーリングで結果を受け取る仕組みのため、業務が止まらない設計になっている。ただし、ゼロデータリテンション（ZDR）には対応していない点に注意が必要だ。
Claude Code特有の症状と対処
Claude Codeを使っている場合、529エラーはエディタやターミナルに「Server is temporarily limiting requests」と表示される。以下のポイントを押さえておくと実際の業務影響を最小化できる。
/clearでコンテキストをリセット — 長いセッションは1ターンあたりのトークン消費が増加する。/clearで新しいセッションを始めると429エラーの回避にも有効/modelでモデルを切り替え — セッション中に/modelコマンドで軽量モデルに切り替えると、別のレート制限プールに移れる- 並列セッションは段階的に増やす — レート制限リセット直後に大量の並列セッションを立ち上げると、加速度制限（アクセラレーション制限）で429になることがある
- エラー継続時は
claude logout→claude login— セッション状態がスタックした場合に有効。認証キャッシュをリセットできる
claude.aiとClaude CodeはUsage制限を共有している
claude.ai（ブラウザ）、Claude Code、Claude Desktopは同じアカウントのUsage枠を共有している。一方で複数を同時に使っていると、どれか一方でも429に達すると全部に影響が出る。
2026年5月のインフラ強化で何が変わったか
2026年5月、AnthropicはSpaceXとの大規模な演算リソース調達契約を締結した（メンフィス・テネシー州にある30万kW超のデータセンター、22万枚以上のNVIDIA GPUを活用）。これに伴い、ClaudeのAPI制限が大幅に引き上げられた。
- Claude CodeのProおよびMaxプランの5時間制限が2倍 — 以前は「なぜこんなに早く上限に達するのか」という声が多かった問題が緩和
- ピーク時間帯のPro・Max制限削減が廃止 — 太平洋時間の朝方に制限が厳しくなる問題が解消
- API Tier 1のOpus ITPM上限が16倍超に — 3万トークン/分から50万トークン/分へ引き上げ
ただし、サーバー全体の過負荷（529）はキャパシティが増えても完全にはなくならない。新機能リリース後の需要急増など、供給が一時的に需要に追いつかない場面では今後も発生しうる。
まとめ エラーの種類を見極めて適切に対処する
「Server is temporarily limiting requests」エラーへの対処は、エラーの種類によって大きく異なる。
| 529エラーが1〜2回だけ出た | status.anthropic.comを確認し、1〜5分待ってリトライ |
| 529エラーが1時間以上継続 | インシデント発生の可能性。ステータスページで公式情報を待つ |
| 429エラーが頻繁に出る | retry-afterヘッダーを守り、ティアアップやプロンプトキャッシュを検討 |
| 業務でSLAが必要 | Anthropic営業窓口へPriority Tierを相談 |
| リアルタイム性不要の大量処理 | Batch APIに切り替えてコスト50%削減＋制限系統を分離 |
「not your usage limit」という一文が示す通り、529エラーはあなたの使い方の問題ではない。焦らず待機することが最も合理的な第一手だ。一方で頻繁に発生して業務に影響が出るなら、Priority Tierへの移行やBatch APIの活用で実質的なサービスレベルを高めることができる。