HTTPエラー429 Too Many Requestsの原因と解決方法

HTTPエラー429とは？

HTTPエラー429は、Too Many Requests（リクエスト過多）を意味するクライアントエラーステータスコードです。一定時間内に大量のリクエストを送信したため、サーバーが一時的にリクエストの処理を拒否している状態です。

このエラーはRFC 6585で定義されており、HTTPのレート制限メカニズムの一部です。API連携を行う開発者が最も頻繁に遭遇するエラーの一つですが、一般ユーザーがWebサイト閲覧中に目にすることもあります。

429ステータスコードは他の4xxエラーとは性質が異なります。403エラーはアクセス権限がないことを、401エラーは認証されていないことを意味します。429エラーの場合、認証情報には問題ありません — 単にリクエストの送信速度が速すぎるだけです。

サーバーが429レスポンスを返す際、次のリクエストまでの待機時間を示すRetry-Afterヘッダーが含まれていることがあります。

429エラーの表示例

429エラーは、ブラウザ、アプリケーション、APIクライアントによって表示が異なります。よく目にするメッセージの例を以下に示します。

500エラーがサーバー側の問題を示すのとは異なり、429はクライアント側のエラーです。サーバー自体は正常に動作しており、大量のリクエストから自身を守るために意図的にリクエストを拒否しています。

レート制限の仕組み

レート制限（レートリミット）とは、一定の時間枠内にクライアントが送信できるリクエスト数を制御するサーバー側の技術です。制限を超えると、サーバーはHTTP 429を返します。

代表的なレート制限アルゴリズムは以下の通りです。

• 固定ウィンドウ方式 — サーバーが一定の時間枠ごとにN件のリクエストを許可します（例：1分間に100リクエスト）。カウンターは固定の間隔でリセットされます。

• スライディングウィンドウ方式 — 固定ウィンドウと似ていますが、時間枠がリクエストごとにスライドします。ウィンドウの境界でのバースト（突発的集中）を防止できます。

• トークンバケット方式 — サーバーが一定の速度で補充されるトークンを割り当てます。リクエストごとにトークンを1つ消費し、トークンがなくなるとリクエストが拒否されます。

• リーキーバケット方式 — バーストの大きさに関係なく、リクエストを一定の速度で処理します。超過分のリクエストはキューに入るか、ドロップされます。

多くのAPIは、レスポンスヘッダーを通じてレート制限の情報を通知します。よく使われるヘッダーにはX-RateLimit-Limit（許可される最大リクエスト数）、X-RateLimit-Remaining（現在のウィンドウ内の残りリクエスト数）、X-RateLimit-Reset（ウィンドウがリセットされる時刻）があります。

サービスがどのアルゴリズムを使用しているかを理解することで、制限内に収まるようクライアントを設計し、429エラーを回避できます。

HTTPエラー429の主な原因

429エラーはさまざまな状況で発生します。以下に主な原因を、影響を受ける対象別にまとめました。

429エラーの解決方法（訪問者向け）

Webサイト閲覧中に429エラーが表示された場合の対処法を紹介します。最も簡単な方法から順に試してみてください。

1. しばらく待ってから再試行する

最もシンプルな対処法は、しばらく待つことです。429エラーは一時的なもので、サーバーは永久にブロックしているのではなく、速度を落とすよう求めています。

30秒～数分間待ってから再度アクセスしてください。ほとんどのレート制限は1～5分以内にリセットされます。それでも429が表示される場合は、さらに長く待ちましょう。サービスによっては1時間単位や1日単位の制限を設けていることもあります。

ページを繰り返しリロードしないでください。リロードするたびにリクエストが送信され、レート制限の期間が延長される可能性があります。

2. ブラウザのキャッシュとCookieを削除する

キャッシュデータやCookieがレート制限のトリガーになることがあります。以下の手順で削除してみましょう。

• Chrome: Ctrl+Shift+Delete（Windows）またはCmd+Shift+Delete（Mac）→「Cookieと他のサイトデータ」と「キャッシュされた画像とファイル」を選択 →「データを削除」をクリック

• Firefox: Ctrl+Shift+Delete →「キャッシュ」と「Cookie」を選択 →「今すぐ消去」をクリック

• Edge: Ctrl+Shift+Delete →「Cookieおよびその他のサイトデータ」と「キャッシュされた画像とファイル」にチェック →「今すぐクリア」をクリック

• Safari: Safari → 設定 → プライバシー → Webサイトデータを管理 → すべてを削除

削除後、ブラウザを一度閉じて再起動してからサイトにアクセスしてください。

3. VPNやプロキシを切断する

VPNやプロキシを使用している場合、数百人のユーザーとIPアドレスを共有している可能性があります。すべてのユーザーの合計リクエスト数がサーバーの制限を超えると、そのIPを使っている全員がレート制限の対象になります。

VPNを切断し、通常のインターネット接続でサイトにアクセスしてみてください。429エラーが解消されれば、VPNのIPアドレスが原因です。

VPNが必要な場合は、別のサーバーロケーションに切り替えて新しいIPアドレスを取得してみてください。

4. ブラウザ拡張機能を無効にする

一部のブラウザ拡張機能は、ユーザーが気づかないうちにバックグラウンドでリクエストを送信しています。広告ブロッカー、価格比較ツール、SEO拡張機能、自動リロードプラグインなどは、レート制限を発動させる追加リクエストを生成する場合があります。

まずシークレットウィンドウ（プライベートウィンドウ）でサイトを開いてみてください（ほとんどの拡張機能がデフォルトで無効化されます）。429エラーが消えれば、拡張機能のいずれかが原因です。

原因を特定するには、拡張機能を1つずつ無効にしてテストしてください。Chromeの場合、chrome://extensions/ にアクセスして個別にオフに切り替えます。

5. 別のネットワークを試す

上記の方法で解決しない場合、サーバーがあなたのIPアドレスを個別にレート制限している可能性があります。以下を試してみてください。

Wi-Fiからモバイルデータ通信に切り替えてください（異なるIPアドレスが割り当てられます）。別のネットワーク環境からサイトにアクセスしてみてください。企業や学校のネットワークを使用している場合は、自宅から試してみましょう。大規模ネットワークでは単一のパブリックIPを共有しています。

IPアドレスが変わったかどうかは、当サイトのWhat Is My IPツールで確認できます。

429エラーの解決方法（開発者向け）

APIを呼び出すアプリケーションを開発していて429エラーが発生する場合、コードがリクエストを送信する速度が速すぎることを意味します。以下の方法で適切に対処しましょう。

1. Exponential Backoff（指数バックオフ）を実装する

Exponential Backoff（指数バックオフ）は、業界標準のリトライ戦略です。429を受信した直後にリトライするのではなく、リトライ間隔を段階的に延長していきます。

1回目のリトライ：1秒待機。2回目：2秒待機。3回目：4秒待機。4回目：8秒待機。以降も同様に倍増させます。

以下はJavaScriptでの基本的な実装例です。

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url, options);
    
    if (response.status !== 429) return response;
    
    // Check Retry-After header first
    const retryAfter = response.headers.get('Retry-After');
    const delay = retryAfter
      ? parseInt(retryAfter) * 1000
      : Math.pow(2, attempt) * 1000; // Exponential backoff
    
    console.log(`Rate limited. Retrying in ${delay / 1000}s...`);
    await new Promise(resolve => setTimeout(resolve, delay));
  }
  throw new Error('Max retries exceeded');
}

複数のクライアントが同時にリトライするのを防ぐため、待機時間にジッター（ランダムな変動）を加えましょう。遅延の計算を Math.pow(2, attempt) * 1000 + Math.random() * 1000 に置き換えてください。

2. Retry-Afterヘッダーを確認する

サーバーが429レスポンスを返す際、Retry-Afterヘッダーが含まれていることがよくあります。このヘッダーは、次のリクエストまでに待つべき正確な時間を示します。値は秒数またはHTTP日時形式のいずれかです。

Retry-After: 60 は60秒待つことを意味します。Retry-After: Thu, 06 Mar 2026 12:00:00 GMT はその指定時刻まで待つことを意味します。

独自のバックオフロジックを適用する前に、必ずこのヘッダーを確認してください。待機時間について、あなたのコードよりもサーバーの方が正確に把握しています。

import requests
import time

def make_request(url):
    response = requests.get(url)
    
    if response.status_code == 429:
        retry_after = response.headers.get('Retry-After', '5')
        wait_time = int(retry_after)
        print(f"Rate limited. Waiting {wait_time} seconds...")
        time.sleep(wait_time)
        return make_request(url)  # Retry after waiting
    
    return response

3. APIレスポンスをキャッシュする

アプリケーションが同じAPIを何度も呼び出している場合、毎回APIにアクセスする代わりにレスポンスをキャッシュしましょう。これによりリクエスト数を大幅に削減できます。

頻繁にアクセスするデータには、インメモリキャッシュ（RedisやシンプルなMap）を使用してください。データの更新頻度に合わせて、適切なTTL（有効期限）を設定しましょう。

例えば、ドメインのDNSレコードを確認する場合、通常は次の5分間で結果が変わることはありません — キャッシュすべきです。

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) {
    return cached.data;
  }
  
  const response = await fetch(url);
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. ポーリングの代わりにWebhookを使う

APIを定期的にポーリングして変更を確認している場合（例：注文ステータスを10秒ごとにチェック）、サービスが対応していればWebhookに切り替えましょう。

Webhookを使えば、変更が発生したときにサーバーからアプリケーションに通知が送られます。定期的なポーリングが不要になるため、APIコール数を1時間あたり数千件からわずか数件に削減できます。

最新のAPI（Stripe、GitHub、Twilio、Shopifyなど）のほとんどはWebhookに対応しています。各APIのドキュメントでWebhookの設定方法を確認してください。

5. レート制限の引き上げをリクエストする

正当な理由でより多くのAPIコールが必要な場合は、サービス提供者に連絡しましょう。多くのAPIでは、有料プランや認証済みアプリケーションに対して、より高いレート制限を提供しています。

引き上げをリクエストする際は、ユースケースを説明し、予想されるリクエスト量の見積もりを提示してください。Google API、Twitter API、GitHub APIなどは、レート制限引き上げの申請プロセスを用意しています。

一部のAPIは、1回のリクエストで複数のリソースを取得できるバルクエンドポイントも提供しており、合計コール数の削減に役立ちます。

429エラーの解決方法（サイト管理者向け）

訪問者やAPI利用者が429エラーに遭遇している場合、問題はサーバーの設定にあります。以下の方法で診断と修正を行いましょう。

1. レート制限の閾値を調整する

正規ユーザーが429エラーに遭遇している場合、レート制限が厳しすぎる可能性があります。設定を見直して調整しましょう。

Nginxの場合、レート制限モジュール（ngx_http_limit_req_module）でリクエストレートを制御します。

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Allow bursts of 20, no delay for first 10
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

burstパラメーターが重要です。これにより、短期間のトラフィック急増時に429を発動させずに済みます。このパラメーターがないと、通常の閲覧パターンでもレート制限に引っかかる可能性があります。

Apacheの場合はmod_ratelimitまたはmod_evasiveを使用します。Node.jsの場合はexpress-rate-limitなどのパッケージを利用してください。

2. 信頼できるIPをホワイトリストに登録する

特定のクライアント（監視サービス、決済プロバイダー、自社のマイクロサービスなど）がレート制限に引っかかっている場合、それらのIPアドレスをホワイトリストに登録しましょう。

Nginxでは、mapディレクティブを使って信頼できるIPのレート制限をバイパスできます。

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

検索エンジンボット（Googlebot、Bingbotなど）がレート制限に引っかかっている場合もホワイトリストに登録してください。これらをブロックするとSEOに悪影響を及ぼします。ボットの正当性はリバースDNS検索で確認できます。

3. WAFとCDNの設定を確認する

Cloudflare、AWS WAF、Sucuriなどのセキュリティサービスを使用している場合、429エラーの原因はオリジンサーバーではなく、それらのレート制限ルールである可能性があります。

Cloudflareの場合、セキュリティ → WAF → レート制限ルール を確認してください。どのルールが発動しているかを確認し、閾値を調整できます。Cloudflareの「I'm Under Attack」モードは特に厳しい設定になっています。

AWS WAFの場合、Web ACLルールでレートベースルールを確認してください。最低閾値は5分間に100リクエストです。トラフィック量に対して適切な値かどうか確認しましょう。

レート制限の閾値を調整する前に、CDNのアナリティクスで正規トラフィックとボットトラフィックを区別して分析してください。

4. サーバーのパフォーマンスを最適化する

サーバーが負荷に耐えられず、安全装置としてレート制限が作動している場合に429エラーが発生することがあります。サーバーのパフォーマンスを改善すれば、レート制限の閾値を安全に引き上げることができます。

主な最適化項目は以下の通りです。バックエンドの負荷を軽減するためにレスポンスキャッシュを有効にする、静的アセットにCDNを使用する、Redisやmemcachedを使ってデータベースクエリのキャッシュを追加する、データベース接続にコネクションプーリングを実装する、トラフィック量に応じてロードバランシングで水平スケーリングを行う。

当サイトのHTTPヘッダーツールを使って、キャッシュヘッダーが正しく設定されているか確認できます。

429と他のHTTPエラーとの違い

429エラーは他のHTTPステータスコードと混同しやすいため、以下に違いを整理します。

最も重要な違いは、429は一時的かつ意図的なものであるということです。サーバーは正常に動作しており、自身を保護するために意図的にリクエストを拒否しています。5xxエラーの場合は、実際に何かが壊れている状態です。

429エラーを未然に防ぐ方法

予防は治療に勝ります。429エラーを事前に防ぐためのベストプラクティスを紹介します。

• APIドキュメントを読む — コードを書く前にレート制限を把握しておきましょう。ほとんどのサービスは制限を明確に公開しています。

• 使用状況を監視する — X-RateLimit-Remainingヘッダーを追跡して、制限にどれだけ近づいているか把握しましょう。

• リクエストをバッチ処理する — 個別に呼び出す代わりに、バルクエンドポイントが利用可能であれば活用しましょう。

• リクエストを分散させる — バーストで送信するのではなく、APIコールを時間的に均等に分散させましょう。

• APIキーを使用する — 認証済みリクエストは、匿名リクエストよりも高いレート制限が適用されることが一般的です。

• サーキットブレーカーを実装する — 429が繰り返し発生した場合、クールダウン期間を設けてリクエスト送信を完全に停止しましょう。

• レート制限シミュレーターでテストする — 開発環境で429レスポンスをシミュレートし、エラーハンドリングが正しく機能するか確認しましょう。

• 429レスポンスをログに記録する — レート制限がいつどこで発生するかを追跡し、リクエストパターンを最適化しましょう。