429エラー（Too Many Requests）とは？X（旧Twitter）での原因と対策

HTTPエラー429とは？

HTTP 429 Too Many Requestsは、サーバーがリクエストの回数を制限している（レート制限）という意味です。あなた自身、あなたのIPアドレス、または使っているアプリが、決められた時間内に許可された数を超えるリクエストを送ったためです。 一時的な状態で、サーバーは正常に動いています。今はあなたへの応答を控えているだけです。

このコードは、まさにこうした場面のためにRFC 6585（2012年）で追加されました。レスポンスには、どれくらい待てばよいかを示すRetry-Afterヘッダーが付くことがあります。アクセスが集中するサイトの閲覧中、APIの呼び出し、大量のダウンロード、多くの人が同じIPアドレスを使うVPNの利用中などによく遭遇します。

似たエラーとは意味が違います。401はログインしていない、403はアクセスが許可されていない、そして429はアクセスは許可されているがリクエストが速すぎる、という意味です。

429エラーの表示例

表示されるメッセージは、どこが応答しているかによって変わります。よく検索されるメッセージは次のとおりです。

サーバー側で何かが壊れていることを示す500エラーと違い、429はHTTPの分類ではクライアントエラーです。サーバーは、過剰なリクエストから自分自身を守っているのです。

「request failed with status 429」などアプリに出るメッセージの意味

上の表のほかにも、アプリや開発ツールは429を独自の文言で表示します。表現が違ってもステータスコードが429なら意味は同じで、「決められた回数を超えたので、時間を置いてから再試行してほしい」というサーバーからの応答です。

どのメッセージでも、まず数分待ってから1回だけ再実行し、自動で繰り返し実行している処理があれば止めてください。開発者は、下の「429エラーの解決方法（開発者向け）」の手順でRetry-Afterヘッダーと指数バックオフを実装しましょう。

レート制限の仕組み

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

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

• 固定ウィンドウ方式 — サーバーが一定の時間枠ごとにN件のリクエストを許可します（例：1分間に100リクエスト）。カウンターは固定の間隔でリセットされます。
• スライディングウィンドウ方式 — 固定ウィンドウと似ていますが、時間枠がリクエストごとにスライドします。ウィンドウの境界でのバースト（突発的集中）を防止できます。
• トークンバケット方式 — サーバーが一定の速度で補充されるトークンを割り当てます。リクエストごとにトークンを1つ消費し、トークンがなくなるとリクエストが拒否されます。
• リーキーバケット方式 — バーストの大きさに関係なく、リクエストを一定の速度で処理します。超過分のリクエストはキューに入るか、ドロップされます。

多くのAPIは、レスポンスヘッダーで上限を知らせます。たとえばGitHubの場合はx-ratelimit-limit（1時間あたりの許可リクエスト数）、x-ratelimit-remaining、x-ratelimit-used、x-ratelimit-reset（時間枠がリセットされる時刻、Unix秒）です。同じ目的の標準ヘッダーとしてRateLimitとRateLimit-Policyを提案するIETFのドラフトもあります。

サービスがどのアルゴリズムと時間枠を使っているかがわかれば、上限内に収まるようにクライアントを設計できます。

HTTPエラー429の主な原因

原因は、誰がこのエラーを見ているかによって異なります。

X（旧Twitter）で429エラー・エラーコード429が出たときの対策

X（旧Twitter）で429エラー（エラーコード429）が表示されたら、短時間に読み込みや操作を繰り返したため、Xがリクエストを一時的に制限している状態です。Xヘルプセンター「Xリミットについて」によると、上限に達するとその旨のエラーメッセージが表示され、上限はパソコン・スマートフォン・APIなどすべての端末での操作を合算して数えられます。サードパーティーアプリからのAPIリクエストも1時間単位の上限に含まれるため、1つのアカウントで複数の連携アプリを使っていると早く上限に達します。

Xは、利用が集中する時間帯にこれらの上限を一時的に引き下げることがあるとしています。Xが公開している主な上限と、上限に達したときの再試行の目安は次の表のとおりです。表の下に、今すぐできる対策をまとめました。

• 再読み込みを止める: 更新ボタンや下に引っぱる更新を繰り返すと、そのたびに新しいリクエストとして数えられます。アプリを閉じて時間を置いてください。
• 連携アプリと拡張機能を見直す: 自動更新・自動スクロールの拡張機能や、予約投稿・分析などの連携アプリを止めます。使っていない連携アプリは、Xの設定からアクセス権を取り消しましょう。
• X全体の障害か確認する: 自分だけでなく多くの人が同じ表示になっているなら、X側の障害の可能性があります。サーバーダウンチェックでx.comが応答しているか確認してください。

補足（開発者向け）: X APIのドキュメント（英語）によると、上限はエンドポイントごとに多くが15分または24時間単位で、超えると429とともにエラーコード88（Rate limit exceeded）が返ります。レスポンスヘッダーのx-rate-limit-resetに上限が解除される時刻がUnix時間で入っているので、その時刻まで待ってから再試行してください。

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

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

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

最もシンプルな対処法は、しばらく待つことです。429は一時的なもので、サーバーはあなたを締め出しているのではなく、速度を落とすよう求めています。

待つ時間はサイトの上限によって異なり、1分以内にリセットされるところもあれば、1時間単位や1日単位のところもあります。ページやAPIがRetry-Afterヘッダーを送っていれば、それが正確な待ち時間です。待ったら、ページを1回だけ読み込んでください。

再読み込みを繰り返さないでください。再読み込みのたびに新しいリクエストが送られ、同じ上限にカウントされます。

2. そのサイトのCookieだけを削除する

効果があることはまれですが、セッションCookieごとにリクエスト数を数えるサイトもあります。ほかのサイトからまとめてログアウトしないよう、そのサイトのCookieだけを削除して新しいセッションを始めましょう。

• Chrome / Edge: chrome://settings/content/all（Edgeはedge://settings/content/all）を開き、サイトを検索してそのデータを削除します
• Firefox: アドレスバーの鍵アイコンをクリック →「Cookie とサイトデータを消去...」
• Safari:「Safari」＞「設定」→「プライバシー」→「ウェブサイトデータを管理」→ サイトを選択 →「削除」

削除したら、ブラウザを一度閉じて開き直してからサイトにアクセスしてください。

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

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

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

VPNが必要な場合は、別のサーバーロケーションに切り替えてください。そちらのIPアドレスは、共有している人が少ない可能性があります。

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

一部の拡張機能は、閲覧中のサイトにバックグラウンドでリクエストを送ります。価格トラッカー、SEOツール、自動リロード系の拡張機能のリクエストが積み重なると、レート制限に達することがあります（広告ブロッカーは通常、逆にリクエストを減らします）。

確認するには、ほとんどの拡張機能がオフになるシークレット ウィンドウ（Firefoxではプライベートウィンドウ）でサイトを開いてみてください。シークレット ウィンドウはCookieのない状態で始まるため、ここで429が消えるなら、拡張機能かセッション単位の制限が関係しています。

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

5. IPアドレスを他の人と共有していないか確認する

1つのパブリックIPアドレスを大勢で共有していることはよくあります。会社や学校のネットワーク、携帯電話会社のネットワーク（CGNAT）、VPNサーバーなどです。その人たちのリクエストも、あなたのリクエストと同じ上限にカウントされます。

こうしたネットワークを使っている場合は、自宅の回線やモバイルデータ通信でサイトを開いてみると、共有アドレスが原因かどうかがわかります。上限があなた自身のアドレスにかかっている場合は、ネットワークを切り替えて回避しようとせず、リセットされるまで待ってください。現在のパブリックIPアドレスは自分のIPアドレス確認で確認できます。

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

コードが429を受け取るなら、APIが許可する以上の速さでリクエストを送っています。Retry-Afterを読む、ジッター付きでバックオフする、リクエスト数そのものを減らす、の順で対処しましょう。

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

Exponential Backoff（指数バックオフ）は標準的なリトライ戦略です。429を受け取ってもすぐにリトライせず、待ち時間を毎回2倍にします（1秒、2秒、4秒、8秒…）。さらにランダムな追加の待ち時間であるジッターを加えると、多数のクライアントが同じ瞬間に一斉にリトライするのを防げます。

次のコードは、サーバーが有効なRetry-Afterを送ってきた場合は2つの形式のどちらでも読み取ってそれに従い、そうでなければジッター付きのバックオフで待ち、数回試してもだめなら諦めます（ブラウザから別サイトのAPIを呼ぶ場合、そのAPIがAccess-Control-Expose-HeadersでRetry-Afterを公開していないと読み取れません）。

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

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

サーバーが429とともにRetry-Afterを送ってきたら、それは待つべき時間を正確に示しています。RFC 9110では、秒数とHTTP日時の2つの形式が認められています。

Retry-After: 60 は60秒待つという意味です。Retry-After: Wed, 21 Oct 2026 07:28:00 GMT はその時刻まで待つという意味です。独自のバックオフ処理より先にこのヘッダーを確認してください。待ち時間については、コードよりサーバーのほうが正確に把握しています。

Pythonでは、両方の形式を扱い、無限に再帰せず数回試したら止めるようにします。

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

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);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  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には、上限引き上げの申請フォームや有料プランが用意されています。

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

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

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

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

実際のユーザーが429に遭遇しているなら、まずどの層が応答しているかを突き止めます。CDNやWAF、Webサーバー、アプリケーションのいずれかです。そのうえで、その層の上限を調整しましょう。

nginxではlimit_reqがこの処理を行います。デフォルトでは503を返す点に注意してください。limit_req_status 429;を追加すると、クライアントはサーバーダウンと誤解せず、速度を落とすべきだと判断できます。

# 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/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

burstパラメーターを設定すると、短時間の急増は429にならずに通過します。設定しないと、リクエストの多いごく普通のページ読み込みでも上限に達することがあります。

Apacheには、リクエスト数を制限する標準機能がありません。mod_ratelimitはリクエスト数ではなく帯域幅を制限するもので、サードパーティー製のmod_evasiveは403を返します。429を返したい場合は、リバースプロキシ、WAF、またはアプリケーション側で制限してください。Node.jsのexpress-rate-limitは、デフォルトで429を返します。

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

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

nginxでは、geoとmapで信頼できるアドレスのキーを空にします。nginxはキーが空のリクエストをカウントしません。次の設定は、前の例のlimit_req_zoneの行を置き換えるものです。

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;

検索エンジンのクローラーを誤って制限しないようにしましょう。Googleは429をサーバーエラーとして扱い、クロールの速度を落とします（Google 検索セントラル）。本物のGooglebotやBingbotかどうかは、IPアドレス逆引きで得たホスト名を正引きして確認するか、クローラーが公開しているIPアドレス範囲を除外対象にしてください。

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

Cloudflare、AWS WAF、Sucuriなどのセキュリティサービスを使っている場合、リクエストがサーバーに届く前に、そのサービスのレート制限ルールが応答していることがあります。

Cloudflareでは、レート制限ルールが発動すると訪問者に「Error 1015: You are being rate limited」が表示されます。ダッシュボードのセキュリティルールで該当するルールを見つけてイベントを確認し、閾値を上げるか対象範囲を絞り込んでください。

AWS WAFのレートベースのルールは、IP（または別のキー）ごとのリクエスト数を1分、2分、5分、10分のいずれかの時間枠で数え、上限の最小値は10です。ブロックされたリクエストにはデフォルトで403が返るため、クライアントが速度を落とせるようカスタムレスポンスで429を設定しましょう。

何かを変更する前に、CDNのアナリティクスで実際の訪問者とボットを区別してください。

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

負荷がかかると、安全装置としてレート制限を厳しくするサービスもあります。サーバーのパフォーマンスを改善すれば、上限を安全に引き上げられます。

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

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

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

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

最も重要な違いは、429は意図的かつ一時的なものだという点です。サーバーは、今は応答しないことを自ら選んでいます。5xxの多くはサーバー側で何かが失敗したことを示しますが、503は計画メンテナンスの場合もあり、nginxではレート制限の場合もあります。

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

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

• APIドキュメントを読む — コードを書く前にレート制限を把握しておきましょう。ほとんどのサービスは制限を明確に公開しています。
• 使用状況を監視する — X-RateLimit-Remainingヘッダーを追跡して、制限にどれだけ近づいているか把握しましょう。
• リクエストをバッチ処理する — 個別に呼び出す代わりに、バルクエンドポイントが利用可能であれば活用しましょう。
• リクエストを分散させる — バーストで送信するのではなく、APIコールを時間的に均等に分散させましょう。
• APIキーを使用する — 認証済みリクエストは、匿名リクエストよりも高いレート制限が適用されることが一般的です。
• サーキットブレーカーを実装する — 429が繰り返し発生した場合、クールダウン期間を設けてリクエスト送信を完全に停止しましょう。
• レート制限シミュレーターでテストする — 開発環境で429レスポンスをシミュレートし、エラーハンドリングが正しく機能するか確認しましょう。
• 429レスポンスをログに記録する — レート制限がいつどこで発生するかを追跡し、リクエストパターンを最適化しましょう。