Twitter APIのレート制限：X APIのエンドポイント別上限、429エラーの対処法、代替サービス

レート制限とは、一定の時間内に送れるリクエスト数の上限です。公式のX APIでは、エンドポイントごとに15分あたりの上限があり、アプリ単位とユーザートークン単位で別々に数えられます。上限を超えると、ウィンドウがリセットされるまでHTTP 429が返ります。サードパーティAPIも制限を設けていますが、多くはエンドポイントを問わず1秒あたりまたは1分あたりで数えます。

この記事では、よく使われるエンドポイントの公式の上限、ヘッダーと429レスポンスの意味、そして代替サービスが公表している上限を並べて紹介します。内容はすべて2026-10-10に確認しました。代替サービスの一つであるTwittrAPIは当社が運営しているため、その部分はその点を踏まえてお読みください。

X APIのレート制限の仕組み

Xのレート制限のページには、次の3つのルールが書かれています。

• ウィンドウ。 上限は15分ごと、または24時間ごとにリセットされます。そのページの表は、特に断りがなければ15分あたりの上限です。
• エンドポイント単位。 各エンドポイントに独自の上限があります。検索の上限を使い切っても、ユーザー取得の上限には影響しません。
• アプリ単位またはユーザー単位。 アプリ専用のBearerトークンで送ったリクエストはアプリの上限に、ユーザーのOAuth 1.0aまたはOAuth 2.0トークンで送ったリクエストはそのユーザーの上限に数えられます。

Enterpriseの契約では個別の上限が設定されます。

主なエンドポイントの上限

同じページに載っている、15分あたりの上限です。

目立つ点が2つあります。アプリトークンでのユーザー取得は15分あたり300回、つまり1分あたり20回までです。フォロワー一覧はアプリでもユーザーでも同じ300回なので、フォロワー数の多いアカウントを複数取得するには、料金を払えるとしても長い時間がかかります。

レート制限と料金は別のもの

X APIは2026年から従量課金になりました。クレジットを購入し、公式のX API料金ページによると、投稿の取得は1件あたり$0.005、ユーザーの取得は1件あたり$0.010です。レート制限は支払額によって変わりません。残高が多くても、ウィンドウあたりのリクエスト数は増えません。

レート制限とは別に、利用量の上限もあります。従量課金は月次の請求サイクルあたり300万件の投稿取得までで、それを超えるにはEnterpriseが必要です。料金ページには、同じUTC日の中で同じリソースを複数回取得しても課金は1回だけ、という記載もあります。

この2つの上限は組み合わさって効きます。直近検索は1リクエストあたり最大100件の投稿を返すので、1ウィンドウで450リクエストなら最大45,000件、投稿取得の単価で最大$225になります。これを15分ごとに繰り返すと、1日もたたずに300万件の上限に達します。ほかの計算例はX API料金【2026年版】にあります。

ヘッダーと429レスポンス

X APIのレスポンスには、毎回3つのヘッダーが付きます。

上限に達すると、APIはエラーコード88、メッセージ「Rate limit exceeded」とともにHTTP 429を返します。Xが勧める対処は、x-rate-limit-resetを読んでその時刻まで待つことです。リセット時刻がない場合は、指数バックオフを使います。Xの公式サンプルコードは、再試行の前に最低60秒待ちます。

これを行う小さなPythonのヘルパーです。

import random
import time
 
import requests
 
 
def get_with_backoff(url, headers, max_tries=5):
    for attempt in range(max_tries):
        resp = requests.get(url, headers=headers, timeout=30)
        if resp.status_code != 429:
            return resp
 
        reset = resp.headers.get("x-rate-limit-reset")
        retry_after = resp.headers.get("retry-after")
        if reset:
            wait = max(int(reset) - time.time(), 1)
        elif retry_after:
            wait = int(retry_after)
        else:
            wait = min(60 * 2**attempt, 900)
        time.sleep(wait + random.uniform(0, 1))
    raise RuntimeError("still rate limited after retries")

リセット時刻の代わりにRetry-Afterを返すサードパーティAPIにも対応しています。わずかなランダムな待ち時間は、複数のワーカーが同じ瞬間に再試行するのを防ぎます。

代替サービスが公表している上限

公開Xデータ向けのサードパーティAPIは、独自の上限を定めています。多くはエンドポイント別ではなく、アカウント単位で全エンドポイントをまとめて数えます。以下は各社が公表している数値です。

twitterapi.io：アカウントの状態で変わる

twitterapi.ioのQPS制限ページによると、一度も支払っていないアカウントは1秒あたり0.2リクエスト、つまり5秒に1回までです。クレジットを一度購入すると、1秒あたり20リクエストに上がります。サブスクリプションは、下位プランの1秒あたり20から、Businessの1秒あたり500までです。超えるとRetry-Afterヘッダー付きの429が返り、ページによればアカウントはブロックされません。

twitterapi.ioのほかのページには、異なる数値もあります。ドキュメントの概要には、クライアントあたり最大200 QPSという記載があります。当社は専用の制限ページの数値を引用しており、同社に確認することをお勧めします。

SocialData：1分あたり120リクエスト

SocialDataのレート制限ページでは、全エンドポイント共通でユーザーあたり1分に120リクエストとされ、より高い上限はメールで無料で利用できると書かれています。エラーのページには、429は上限超過を意味し、指数バックオフを勧めるとあります。402は残高不足で、レート制限とは別の問題です。

RapidAPI：プランの割り当て量と1分間のウィンドウ

当社を含め、RapidAPIで販売されているAPIには2種類の制限がかかることがあります。RapidAPIのレスポンスヘッダーのドキュメントに説明があります。

• x-ratelimit-requests-limitとx-ratelimit-requests-remainingは、プランの割り当て量を示します。プランに応じて毎日または毎月リセットされます。
• x-ratelimit-limitとx-ratelimit-remainingは、60秒間のウィンドウを示します。使い切ると429が返ります。これらのヘッダーは、APIにそのような制限がある場合のみ表示されます。

割り当て量は支払った分です。1分間のウィンドウは、速く送りすぎたときに429を返す制限です。

TwittrAPI

RapidAPIとJojAPIでは、各プランの上限がマーケットプレイスの掲載ページに表示されます。直接契約のアカウントでは、上限はアカウントごとに異なります。より多いスループットが必要な場合はサポートにお問い合わせください。超えるとHTTP 429が返ります。レート制限のドキュメント（英語）にバックオフの説明があり、公式のPythonとNode.jsのSDKは429を自動で再試行します。直接契約のアカウントは、料金ページで最大で1秒あたり1,000リクエストの上位ティアを自分で追加できます。それ以上はTwittrAPI for teams（英語）をご覧ください。

料金は1回の呼び出しごとの従量課金で、直接契約の料金では1,000回あたり$0.065からです。400、407、408、409、または5xxエラーで失敗した呼び出しは返金されます。

比較

上限を超えないための工夫

429の多くは、いくつかの習慣から生まれます。以下はどのAPIでも役立ちます。

1. 変わらないものはキャッシュする。 プロフィールや古い投稿はほとんど変わりません。保存しておき、スケジュールで取得し直します。
2. バッチ用のエンドポイントを使う。 GET /2/tweetsは複数のIDを受け取り、表の中で取得の上限が最も高くなっています。サードパーティAPIにも同様の一括取得があるものがあります。
3. リクエストを分散させる。 上限を下回る一定のペースは、まとめて送ってから待つ方法より安定します。
4. ヘッダーを読む。 残りが少なくなったら、429を待たずに速度を落とします。
5. 429が出たらいったん引き、再開する。 短い間隔で再試行を繰り返してはいけません。制限の時間が長引きます。

API制限を避けるためにx.comを直接スクレイピングしようと考えている場合、Xにはそちらにも独自の制限があります。Xスクレイピング【2026年版】で、何に当たるのかを説明しています。

よくある質問

X APIのレート制限はいくつですか？

単一の数値はありません。エンドポイントごとに15分のウィンドウあたりの上限があり、アプリ単位とユーザー単位で別々に数えられます。たとえばユーザー名でのユーザー取得は、アプリあたり15分に300回、ユーザーあたり900回まで可能です。

X APIのレート制限はどのくらい続きますか？

現在のウィンドウがリセットされるまでです。エンドポイントにより15分または24時間です。正確な時刻はx-rate-limit-resetヘッダーでわかります。

コード88の429エラーは何を意味しますか？

現在のウィンドウでエンドポイントが許可するより多くのリクエストを送ったという意味です。x-rate-limit-resetの時刻まで待ってから再開してください。

支払いを増やすとX APIのレート制限は上がりますか？

従量課金では上がりません。残高はリクエストの支払いに使われますが、ウィンドウあたりの上限は変わりません。Enterpriseの契約では個別の上限が設定されます。

サードパーティのTwitter APIにもレート制限はありますか？

あります。多くはアカウントごとに1秒または1分あたりで設定されています。twitterapi.io、SocialData、RapidAPIの各プランがそれぞれ公表しています。TwittrAPIのキーの場合は、マーケットプレイスの掲載ページを見るか、直接契約についてサポートにお問い合わせください。価格の比較は最安のTwitter API（2026年）（英語）にあり、当社のAPIは/startから$0.50のテストクレジットで試せます。

出典

• X APIのレート制限（docs.x.com）
• X APIの料金（docs.x.com）
• twitterapi.ioのQPS制限
• twitterapi.ioドキュメントの概要
• SocialDataのレート制限
• SocialDataのエラー
• RapidAPIのレスポンスヘッダー