【2026年版】X API レート制限：全エンドポイントの上限一覧と429対処法

著者：Sorsa Editorial

2026年7月31日更新：X API v2 の全エンドポイントカテゴリ（約100エンドポイント）を網羅する完全リファレンスとして再構成し、2026年7月末に X の公式レート制限表と突き合わせて再確認しました。メディア・ブックマーク・スペース・トレンド・ストリーミング・Webhook の上限を追加し、無料枠のセクションを拡充したうえで、2026年4月の Enterprise 限定化と2026年5月のアカウント上限引き下げも最新の内容に更新しています。

要点： X API v2 のレート制限はエンドポイントごとに設定され、アプリ単位（ベアラートークン）とユーザー単位（OAuth）の2つのプールに分かれ、15分または24時間の窓でリセットされます。最近の検索はユーザーあたり15分あたり300リクエスト、投稿は100リクエストです。いずれかの上限を超えると HTTP 429 が返り、x-rate-limit-reset ヘッダーに窓が再び開く時刻が示されます。

リクエストを止める仕組みは、実のところ3つあります。しかも、返ってくるエラーはどれもよく似ています。1つ目は、開発者アプリにかかる X API のエンドポイント別レート制限。2つ目は、投稿元の X アカウントにかかるアカウントレベルの上限で、未認証アカウントでは1日50投稿まで下がっています。3つ目は、従量課金の残高にかかる月間200万投稿読み取りの使用量上限で、これが前の2つの上に重ねてかかります。どれか1つに当たっただけで処理は完全に止まります。「レート制限にはまったく届いていないはずなのに」という相談がこれほど多く、しかも紛らわしいのはこのためです。

本ガイドでは、この3つの層すべてを最新の数字とともに解説します。まずはエンドポイント別の完全な表からです。Sorsa API は代替の Twitter/X API で、Sorsa は当社の製品です。自社のパイプラインでも、引き受けている移行案件でも、これらの制限とそれが生む429には毎日向き合っています。Sorsa をそうした制限のない設計で作ったのも、そのためです。全エンドポイントで一律の毎秒20リクエスト、15分の窓もアプリ単位とユーザー単位の使い分けもなく、読み取りはバッチエンドポイントで1,000ツイートあたり$0.02からです。公式の従量課金では1,000投稿読み取りあたり$5.00かかります。登録時に100回分の無料リクエストが付くので、そのまま試せます。以下の数字は、公式 X API を使ううえで今まさに向き合うことになる値です。記事の後半では、2つのモデルを並べて比較します。

最終確認：2026年7月31日、X の公式レート制限ドキュメントおよびアカウント制限ドキュメントと突き合わせ。

よく調べられる上限の早見表 {#the-limits-people-look-up-most}

特定の数字を1つ確認したいだけであれば、おそらくこの表に載っています。詳細はこの後すべて扱います。

目次

• X API のレート制限の仕組み
• X API レート制限の全表：エンドポイント別
• X API の投稿レート制限：API 上限とアカウント上限
• 2026年の X API 無料枠の制限
• 1日に実際どれだけツイートを取得できるか
• 標準と Enterprise のレート制限の違い
• レート制限に当たったとき（429）に起こること
• レート制限に引っかからないための対策
• よくある質問

X API のレート制限の仕組み {#how-x-api-rate-limits-work}

X API v2 のレート制限はエンドポイントごとに設定されており、全体をまとめた単一の数字はありません。多くのエンドポイントは15分のローリングウィンドウでリセットされます。投稿やメディアアップロードなど一部は24時間の窓を使い、ストリーミングやアーカイブ系の一部には毎秒単位の上限も加わります。窓は固定の時刻ではなく、そのエンドポイントへの最初のリクエストから始まります。つまり「15分あたり300」とは、任意の15分間に300リクエストという意味です。

アプリ単位とユーザー単位の制限

各エンドポイントは、最大2つの独立したプールを個別に管理しています。

アプリ単位の制限 は、ベアラートークン（アプリ専用認証）で認証したときに適用されます。アプリケーションが送るリクエストは、どのユーザーがきっかけであっても、すべて1つの共有プールから消費されます。1万人のユーザーが同時にバックエンドへリクエストを送っても、全員が同じアプリ単位のバケットを使うことになります。

ユーザー単位の制限 は、OAuth 1.0a または OAuth 2.0 のユーザートークンで認証したときに適用されます。認証済みユーザーごとに別々のバケットが割り当てられます。ユーザーが100人いれば、それぞれが最近の検索用に15分あたり300リクエストを持ちます。

両方のプールを持つエンドポイントもあれば、片方だけのものもあります。以下の表の「n/a」は、その認証方式がその呼び出しに対応していないことを示します。

レスポンスヘッダーから制限を読み取る

X API のレスポンスには、現在の状況を正確に伝える3つのヘッダーが必ず含まれます。

x-rate-limit-limit: 900
x-rate-limit-remaining: 847
x-rate-limit-reset: 1705420800

x-rate-limit-limit は現在の窓の上限、x-rate-limit-remaining は残り回数です。x-rate-limit-reset は窓がリセットされる時刻を表す Unix タイムスタンプです。このタイムスタンプをパースして現在時刻を引けば、あと何秒待てばよいかが正確に分かります。当て推量は一切必要ありません。

レート制限・使用量上限・アカウント制限の違い

この区別は、どの数字よりも多くの開発者をつまずかせます。3つの層を並べると次のようになります。

X が2026年初頭に従量課金へ移行して以降、取得したリソースはすべて費用として計上され、標準アカウントには月間200万投稿読み取りというハードな上限がかかります。15分のレート制限には十分余裕があっても、月間の上限を使い切ってブロックされることは起こり得ます。コスト面（アクション単位の価格、24時間の重複排除の窓、2026年4月20日の変更内容）については、X API 料金の詳細解説 をご覧ください。

もう1点区別しておきます。アプリでスクロールしたり投稿したりしている最中に「レート制限を超えました」と表示された一般ユーザーの場合、それは開発者向け API ではなくプラットフォーム側の上限です。こちらは X の「レート制限を超えました」の意味と対処法 で別途扱っています。以下はすべて、API を呼び出す開発者向けの内容です。

X API レート制限の全表：エンドポイント別 {#x-api-rate-limit-tables-every-endpoint}

X の公式ドキュメントには現在、十数カテゴリにわたる約100のエンドポイントが掲載されています。以下の表はそのすべてを、X 内部の製品分類ではなく「何をしたいか」で並べ替えて収録したものです。数字はすべて X の公式レート制限表から読み取り、2026年7月31日に再確認しています。特に断りがない限り、上限は15分あたりの値です。

検索とツイート照会のレート制限

検索は上限がまったく異なる2つのエンドポイントに分かれるため、詳しく見ておく価値があります。最近の検索はユーザーあたり15分あたり300リクエストを許容しますが、遡れるのは7日前までです。それでも API で実行するツイート検索 の大半はこの範囲で足ります。完全アーカイブ検索は2006年まで遡れる代わりに毎秒1リクエストに制限されるため、短時間にまとめて送ることができません。過去データの深さが必要なら、この毎秒1というハードな上限を前提に設計することになります。その範囲でうまく回す方法は、過去の Twitter データを取得する ガイドで扱っています。

タイムラインとメンションのレート制限

投稿・削除・メディアのレート制限

投稿の自動化で効いてくる数字は2つです。いずれもユーザーあたり15分あたりの値で、投稿が100件、削除が50件。どちらも API 側の上限であり、実際には後述のアカウントレベルの上限が先に効くのが普通です。

エンゲージメント照会のレート制限（いいね・リツイート・引用）

エンゲージメント照会はすべて15分あたり75で統一されており、API の読み取り系では最も厳しい部類の上限です。バズった投稿を誰がリツイートし、誰がいいねしたかを洗い出す作業では、あっという間に使い切ります。

エンゲージメント書き込みのレート制限（2026年4月以降 Enterprise 限定）

2026年4月20日より、X はフォロー・いいね・引用投稿をセルフサーブの全プランから削除しました。上記の上限は X の表には残っていますが、実際に適用されるのは Enterprise 契約の場合だけです。投稿とダイレクトメッセージは従量課金でも引き続き利用できます。

ユーザー照会とフォロワーのレート制限

フォロワーとフォロー中のエンドポイントは、どちらのプールでも15分あたり300という同じ上限を共有します。1ページ1,000件なので、フォロワー100万人のアカウントをページネーションで取り切るには16〜17回分の窓、経過時間にしておよそ4時間かかります。フォロワーとフォロー中の一覧を取得する 処理を大規模に回すことが業務の中心なら、このペース配分こそ設計上の制約になります。

ダイレクトメッセージのレート制限

ユーザーあたり15分あたり15回の読み取りでは、DM を多用するワークフローはほぼ即座に上限に達します。送信側の24時間上限も含め、この領域の自動化は設計上あえて遅くしてあります。

リストのレート制限

リストのツイートとリストメンバーは15分あたり900で、API の読み取り系では最も余裕のある部類に入ります。リストが監視用の代替手段として今も人気なのは、こうした背景があるからです。

スペース・トレンド・コミュニティ・アナリティクス・ニュースのレート制限

ブックマーク・ブロック・ミュートのレート制限

ストリーミングと Webhook のレート制限

ストリーミング系のエンドポイントはアプリ専用認証のみです。押さえておきたい考え方は、上限が管理するのは接続試行とルール変更の回数であって、配信されるデータ量ではないという点です。安定したストリーム接続を1本張るほうが、どんなポーリングループよりも有利になります。

コンプライアンスと利用状況のレート制限

X API の投稿レート制限：API 上限とアカウント上限 {#x-api-posting-rate-limits-api-caps-vs-account-caps}

2026年の X は、投稿を2つの別々の層で制限しています。そして実際に処理を止めるのは、ほとんどの場合 API 側の層ではありません。

API の書き込みエンドポイント（/2/tweets）は、ユーザーあたり15分あたり100投稿、アプリあたり24時間あたり10,000投稿を許容します。これとは別に、投稿元の X アカウントには、ウェブ・モバイル・API に等しく適用されるアカウントレベルの上限がかかります。2026年5月、この上限は未認証アカウント向けに、長年据え置かれていた2,400件から1日オリジナル投稿50件・返信200件へと引き下げられました。

ここに落とし穴があります。開発者は API 側の制限（15分あたり100は寛容に見え、ユーザーあたり1日で9,600件近く）を読んでそれを前提に設計し、いざ動かすとボットは50投稿で止まります。API 側の制限は、最初から拘束条件ではなかったわけです。

• 未認証アカウント＋API の自動化： 1日オリジナル投稿50件というアカウント上限が、API の窓が問題になるはるか手前で効きます。返信は別枠で1日200件が上限です。リポストと引用も同じ50件に算入されると広く報告されていますが、X 自身は明言していません。
• 認証済みまたは Premium アカウント＋API の自動化： アカウントレベルの上限が高くなる（正確な数字を X は公開していません）ため、API の書き込み制限が実質的な上限になります。
• アプリ規模での運用： 認証済みユーザーを多数抱えていても、アプリあたり24時間あたり10,000投稿は、大量配信にとって越えられない壁です。

X のアカウント制限ドキュメントは、これらの上限がウェブ・モバイル・API を含むすべてのデバイスからのアクションを合算すると明記しています。つまり、スクリプトからの投稿と手元のスマートフォンからの投稿は、同じ1日分の枠を分け合います。自動化の対象になりやすいアカウントレベルの上限は次のとおりです。

認証済みプランの上限、30分ごとのサブ間隔、2026年5月の変更点など、アカウント側の全体像は専用ガイドの X の投稿制限と1日あたりの投稿上限 で扱っています。

投稿は、読み取り専用の代替サービスがどうにもできない唯一の領域でもあります。Sorsa のようなプロバイダーは X データを大規模に読み取るために作られており、書き込みには対応していません。自動投稿が目的であれば、公式 API の書き込みエンドポイントは避けられず、ここに挙げた上限と付き合うことになります。

2026年の X API 無料枠の制限 {#x-api-free-tier-limits-in-2026}

2026年時点で、新規開発者が使える一般的な 無料の X API 枠 は存在しません。単体の無料枠は、2026年2月に従量課金が始まった時点で廃止されました。新規アカウントは、1回目の呼び出しの前にクレジットを購入する必要があります。今も残る唯一の無料アクセスは、指定された公共性の高いアプリに限られた、審査つきの狭いプログラムだけです。

旧来の無料枠と比べたい場合のために触れておくと、そのレート制限は設計上つねに厳しいものでした。

• 書き込み専用。 投稿の読み取りは一切できませんでした。タイムラインも検索もツイート照会も対象外です。
• 24時間あたり17リクエスト。 投稿エンドポイントで、アプリ単位とユーザー単位を合わせた値です。X が宣伝していた「月1,500投稿」という数字とは裏腹に、実際には月およそ500投稿にしかなりません。
• 24時間の窓。 有料アクセスで使われる、より扱いやすい15分の窓ではありませんでした。

要するに、無料枠には X データを読み取るための実用的なレート制限がもとから存在せず、今では新規登録の選択肢からも消えました。読み取りを無料で試す現実的な道筋は、サードパーティのアクセスを経由するものです。新規の Sorsa アカウントはすべて100回分の無料リクエストから始まります。初回のみ、クレジットカード不要・有効期限なしです。この枠は有料プランと同じ一律の毎秒20リクエストで40個のエンドポイントすべてに使え、バッチエンドポイント経由なら、費用が発生する前に最大10,000ツイートまたは20,000プロフィールを取得できます。公式のアクセスとキーの現在の仕組みについては、2026年に X API キーを取得する方法 の手順解説をご覧ください。

1日に実際どれだけツイートを取得できるか {#how-many-tweets-can-you-actually-pull-per-day}

レート制限の数字だけを見ても、分かることは多くありません。重要なのはスループット、つまり1日に現実的に何件のツイート・プロフィール・フォロワーレコードを集められるかです。ユーザー単位の認証を前提に、代表的なシナリオで計算してみます。

ツイート検索（最近）

• レート制限：15分あたり300リクエスト＝1時間あたり1,200＝1日あたり28,800
• リクエストあたりの最大件数：100
• 理論上の上限：1日あたり2,880,000ツイート

一見すると余裕がありますが、従量課金の課金上限は月間200万投稿読み取りです。検索を回し続ければ、1日もかからずに月の枠を使い切ります。ここでのボトルネックはレート制限ではなく、月間の上限です。

ユーザータイムライン

• レート制限：15分あたり900リクエスト＝1時間あたり3,600
• リクエストあたりの件数：約20（変動あり）
• 理論上の上限：1アカウントあたり1時間で約72,000ツイート

個別のタイムラインを集める用途では、レート制限が制約になることはほとんどありません。実際に効いてくるのは、そのアカウントが何件投稿しているかです。

フォロワー

• レート制限：15分あたり300リクエスト＝1時間あたり1,200
• 1ページあたりの最大件数：1,000
• 理論上の上限：1時間あたり1,200,000フォロワーレコード

X は1ページあたり最大1,000フォロワーを返すため、読み取り系のなかではスループットが高い部類に入ります。比較として、Sorsa の定額モデルではフォロワーエンドポイントが1リクエストあたり最大200プロフィールを返し、15分の窓はなく、一律の毎秒20リクエストだけがかかります。計算するとおよそ毎秒4,000プロフィール、1時間あたり約1,440万件です。フォロワーグラフが大きくなるほど、この差は急速に開きます。

ボトルネックの正体（まとめ）

ある程度の規模で読み取り中心の処理を回す場合、先に当たるのはレート制限ではなく月間の課金上限です。レート制限が実務上のボトルネックになるのは主に、書き込みと、1つの窓あたり75件という厳しい上限のエンゲージメント照会、そしてアプリ専用認証で高い並行度を出すパイプラインです。

標準と Enterprise のレート制限の違い {#standard-vs-enterprise-rate-limits}

ここまでは標準（従量課金）のレート制限の話です。Enterprise はまったく別の世界になります。Enterprise の顧客は X の営業チームと直接カスタムの上限を交渉します。詳細は非公開ですが、おおまかな輪郭は知られています。

• エンドポイント別のカスタム上限。標準よりはるかに高いのが一般的
• 月間の使用量上限の引き上げ、または撤廃（200万投稿読み取りの上限がなくなる場合もある）
• 2026年4月にセルフサーブから外れたエンゲージメント書き込み（フォロー・いいね・引用投稿）
• より高い並行度での完全アーカイブ検索、加えてカスタム上限での Activity API と Webhook のアクセス

Enterprise の最低価格は、これまで月額$42,000前後からとされてきました。従量課金への移行に伴って変わっている可能性もあります。承認のハードルは高く、導入までに数週間かかることもあります。

Enterprise が本当に必要なケース

Enterprise が向くのは、X データを自社顧客に再販する大規模な SaaS プラットフォーム、リアルタイムのモデルを運用する金融企業、そして月に数百万件の投稿を処理する研究グループです。月間200万投稿読み取りを超える読み取りと、書き込みアクセスの両方が必要なら、公式 API では Enterprise しか道がありません。

Enterprise の価格を払わずに読み取り処理で高いスループットを出したいチームにとって、まさにここがサードパーティのプロバイダーが埋めているギャップであり、Sorsa を置いた場所でもあります。一律の毎秒20リクエスト は月額$49の Starter を含む全プランに適用され、エンドポイント別の表も、管理すべき15分の窓もありません。大量利用の場合は 営業に相談 から上限の引き上げも可能です。正直に言えばトレードオフもあり、Sorsa は読み取り専用です。投稿も DM も、いいねやフォローの書き込みもできません。1回の読み取り単価がとにかく最安であることだけが条件で、信頼性は自分で組み立てられるというなら、もっと素っ気ない選択肢もあります。定額で、頼れる完全な読み取りアクセスが欲しいのであれば、Sorsa はまさにその用途に向けて作られています。分野全体の比較は、X API の代替サービス の総まとめをご覧ください。

読み取り中心のワークロードに絞ると、2つのモデルは次のように並びます。

公式の従量課金では1,000投稿読み取りあたり$5.00かかるのに対し、Sorsa のバッチエンドポイントなら1,000ツイートあたり$0.02から、通常の検索をページネーションで回す場合でも Proプランで1,000件あたり$0.10前後に収まります。読み取り中心の収集では、1回の読み取りあたり最大50分の1のコストになり、エンドポイント別の窓も完全になくなります。公式 API を使い続ける理由は書き込みです。投稿、DM の送信、いいねを伴う処理は、Sorsa が設計上読み取り専用である以上、引き続き公式 API で動かす必要があります。実務でいちばんよく見るのは、書き込みは公式 API に残し、重い読み取りだけを定額の代替に移すやり方です。この切り替えをきれいに進める手順は、移行ガイド で扱っています。

レート制限に当たったとき（429）に起こること {#what-happens-when-you-hit-a-rate-limit-429}

レート制限を超えると、X は次のボディとともに HTTP 429 を返します。

{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded"
  }]
}

重要なのは、このレスポンスにもレート制限ヘッダーが含まれている点です。x-rate-limit-reset が窓の再開時刻を正確に示すため、決め打ちの時間を当てずっぽうで待つ必要はありません。

適切なリトライ戦略

素朴なやり方は、一律15分スリープしてからリトライするというものです。動きはしますが、時間を無駄にします。より良いのは、リセットのタイムスタンプを読み取り、窓が実際に必要とする分だけ待つ方法です。

import time
import requests

def request_with_rate_limit_handling(url, headers, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)

        if response.status_code != 429:
            return response

        reset_timestamp = int(response.headers.get("x-rate-limit-reset", 0))
        wait_seconds = max(reset_timestamp - int(time.time()), 1)
        print(f"Rate limited. Waiting {wait_seconds}s until window resets.")
        time.sleep(wait_seconds + 1)  # 1秒の余裕を追加

    raise Exception("Rate limit retries exhausted")

注意すべき点をいくつか挙げます。

すぐにリトライしない。 遅延を入れないリトライループは、（アプリレベルの認証では）他のエンドポイント分の残りリクエストまで消費し、さらに強いスロットリングを招くことがあります。

一括処理のパイプラインで429を無視しない。 詰めて回している収集ループでは、1つの429が、コードが気づく前に数百件のリクエスト失敗につながることがあります。各リクエストの前に x-rate-limit-remaining を確認し、10〜20を下回ったら一時停止します。

残りリクエスト数をログに残す。 レート制限まわりを調べるとき、x-rate-limit-remaining の時系列ログほど役に立つ材料はありません。どの呼び出しパターンが枠を食い潰しているかがはっきり分かります。

3つの層のどれに当たったかを確かめる。 レート制限ヘッダーがゼロ近くまで減った状態の429なら、エンドポイントの窓です。窓がリセットされても解除されないブロックは、たいてい月間の使用量上限かアカウントレベルの上限で、指数バックオフをどれだけ重ねても解決しません。

レート制限に引っかからないための対策 {#how-to-stay-under-rate-limits}

定番のアドバイス（「レスポンスをキャッシュする」「指数バックオフを使う」）は間違いではありませんが、それだけでは足りません。ここでは、実際に手がけたパイプライン移行から得られた、計算の前提そのものを変える打ち手を挙げます。

1. 個別照会ではなくバッチエンドポイントを使う

/2/tweets エンドポイントは1回のリクエストで最大100件のツイート ID を受け付けます。1リクエストでレート制限の消費も1回、返ってくるのは100件のツイートです。代わりに /2/tweets/:id を100回個別に呼ぶと、より厳しい上限から100回分を消費します（バッチの15分あたり3,500に対し、個別は15分あたり450）。最大100件のユーザー名または ID を受け取る /2/users にも同じ理屈が当てはまります。

サードパーティの API はバッチ処理をさらに推し進めています。一括ツイート取得エンドポイント は1リクエストで100件のツイート URL または ID を、バッチプロフィール照会 は100件のプロフィールを受け付け、いずれもクォータからは1リクエストとしてカウントされます。リクエスト量を減らすその他の工夫は、API 利用の最適化 のメモにまとめています。

2. ポーリングではなくストリーミングを使う

/2/tweets/search/recent を30秒ごとにポーリングすると、その1エンドポイントだけで1日2,880リクエストになります。X のフィルタードストリームは、条件に一致したツイートを1本の永続接続でリアルタイムに送ってきます。接続は1本、一致する投稿は毎秒最大250件です。難点は15分あたり50回の接続試行と、同時にアクティブにできる接続が1本だけという点ですが、キーワードやアカウントの監視ならポーリングより明らかに有利です。詳しくは X（Twitter）リアルタイム監視 のガイドで扱っています。

3. ユーザープロフィールを積極的にキャッシュする

ユーザープロフィールの変化は緩やかです。表示名、プロフィール文、フォロワー数が動くのは分単位ではなく日単位です。アプリがツイートと併せてユーザーデータを取得しているなら、プロフィールは12〜24時間の TTL でキャッシュし、ヒットしたら呼び出しを省きます。エンゲージメント指標はもっと速く動くため、分析用途では1〜6時間の TTL が妥当です。リアルタイムのダッシュボードだけは、都度呼び出す以外に良い代替がありません。

4. ヘッダーを監視して先回りで速度を落とす

429が出てから減速するのでは遅すぎます。すべてのレスポンスで x-rate-limit-remaining を追跡し、ソフトなしきい値を設けます。上限のおよそ10%を下回ったら、壁に当たる前に速度を落とします。

remaining = int(response.headers.get("x-rate-limit-remaining", 100))
if remaining < 30:   # ソフトなしきい値
    time.sleep(2)    # 完全に止まる前に緩やかに減速

5. 認証方式をまたいで分散させる

アプリ単位とユーザー単位の制限は独立したプールです。ベアラートークンと OAuth ユーザートークンの両方で認証すれば、両対応のエンドポイントでは事実上2つのバケットを使えます。ツイート照会はアプリあたり15分あたり3,500かつユーザーあたり15分あたり5,000を許容するため、両方を使えば15分あたり8,500になります。これはアーキテクチャがデュアル認証に対応している場合にのみ有効です。サーバー側なら難しくありませんが、クライアントだけで完結するアプリではまず不可能です。

実際のクォータを消費する前に知っておきたいツールがもう1つあります。X は2025年12月にセルフホスト型の API プレイグラウンドを公開しました。v2 のエンドポイントをローカルで再現し、レート制限のシミュレーションにも対応しているため、実リクエストを1件も使わずにバックオフやヘッダー処理を検証できます。

実例：429に当たり続けた fintech 分析チーム {#in-practice-a-fintech-analytics-team-that-kept-hitting-429s}

小規模な fintech 分析チーム（エンジニア8人ほど）から、X データのパイプラインが止まり続けるという相談がありました。同チームは市場を動かす投稿を捕まえるために最近の検索を30秒ループでポーリングし、そこから投稿者ごとのプロフィール照会へ展開していました。そして、なぜ「15分あたり300」という上限のもとで収集の途中に429が出続けるのか、原因がつかめない状態でした。原因はよくあるものでした。アプリ専用認証だったため、プロフィール照会も検索もすべて同じアプリ単位のプールから引いており、ポーリングの頻度だけでその大半を使い切っていたのです。

まだ必要としていた書き込みまで公式 API から移したわけではありません。読み取り中心の収集を定額モデルへ移し、ポーリングをイベント駆動の収集に切り替えました。公式 API のリソース単位の料金では、この読み取り量は安価な従量課金と$42,000の Enterprise 契約のあいだの、扱いづらいゾーンに入っていました。Sorsa の定額プランはこの量なら公式 API に比べて1回の読み取りあたり最大50分の1のコストで済むため、請求の読み取り側は月数百ドル台まで下がりました。エンドポイント別の窓がなくなった時点で、429も出なくなりました。書き込みの経路は、本来あるべき公式 API にそのまま残しています。

よくある質問 {#faq}

X API のレート制限はユーザー単位かアプリ単位か？

エンドポイントと認証方式によって、どちらもあり得ます。ベアラートークン（アプリ専用）認証ではアプリ単位の制限が使われ、アプリケーションから送るリクエストはすべて1つのプールを共有します。OAuth のユーザートークン認証ではユーザー単位の制限が使われ、認証済みユーザーごとに独立したバケットが割り当てられます。多くのエンドポイントはアプリ単位とユーザー単位の両方の数字を公開しており、片方だけのものもあります。どちらが適用されるかは、X の公式レート制限表にエンドポイントごとに記載されています。

X API で投稿するときのレート制限は？

API の書き込みエンドポイント（/2/tweets）は、ユーザーあたり15分あたり100投稿、アプリあたり24時間あたり10,000投稿を許容し、削除はユーザーあたり15分あたり50件が上限です。実際に先に効くのはアカウントレベルの上限で、未認証の X アカウントは API・ウェブ・モバイルを合わせて1日にオリジナル投稿50件、返信200件までに制限されます。

X API 検索のレート制限は？

最近の検索（/2/tweets/search/recent）は、アプリあたり15分あたり450リクエスト、ユーザーあたり15分あたり300リクエストを許容し、1回あたり最大100件を返します。クエリは512文字までです。完全アーカイブ検索（/2/tweets/search/all）は毎秒1リクエストで、15分あたりの上限は300、1回の呼び出しで最大500件を返し、2006年まで遡れて、有料プラン限定です。

X API のレート制限の窓はどれくらい続くか？

X API v2 のほとんどのエンドポイントは15分のローリングウィンドウを使います。投稿エンドポイント（アプリあたり24時間あたり10,000）、メディアアップロード、いくつかの DM 上限などは24時間の窓を使い、ストリーミングとアーカイブ系の一部には毎秒単位の上限も加わります。窓は固定の時刻ではなく、そのエンドポイントへの最初のリクエストから始まります。

X API には2026年に使えるレート制限の無料枠があるか？

ありません。X は2026年2月に単体の無料枠を廃止し、新規開発者は無料の枠がない従量課金から始めることになります。旧来の無料枠は書き込み専用で、投稿エンドポイントは24時間あたり17リクエストが上限、投稿の読み取りは一切できなかったため、X データを大規模に読み取る用途はもとから想定されていませんでした。現在の唯一の無料アクセスは、指定された公共性の高いアプリに限られた審査つきのプログラムです。費用をかけずに読み取りを試すなら、Sorsa API は登録時に100回分の無料リクエストを含みます。初回のみ、クレジットカード不要・有効期限なしで、40個のエンドポイントすべてで使えます。

X のアカウント制限は API のレート制限と同じか？

いいえ、別々の仕組みです。API のレート制限は、開発者アプリが各エンドポイントをどれだけ速く呼べるかを決めます（たとえばユーザーあたり15分あたり100投稿）。アカウント制限は、X アカウントがプラットフォーム上で何をできるかを決めます（たとえば未認証アカウントなら1日オリジナル投稿50件）。重要なのは、アカウント制限が API 経由のアクションも数える点です。自動投稿と手動投稿は、1日分の同じ枠を分け合います。

Enterprise なしで X API のレート制限を引き上げられるか？

公式 API ではできません。標準のレート制限は固定で、引き上げられるのは Enterprise 契約の場合だけです。取れる回避策は、バッチ処理（1リクエストあたりのデータ量を増やす）、ストリーミング（ポーリングを避ける）、そしてアプリ認証とユーザー認証にまたがるリクエストの分散です。公式 API の外に目を向けると、読み取りに特化したサードパーティのプロバイダーは、エンドポイント別の窓ではなく毎秒単位の一律制限を1つだけ設けているのが一般的で、依頼すれば引き上げにも応じます。

開発者は Enterprise 契約なしでどう高い読み取りスループットを得ているか？

多くは、読み取り中心の処理を、エンドポイント別の窓ではなく一律のレート制限を持つ Twitter/X API の代替へ移しています。たとえば Sorsa API は、40個の読み取りエンドポイントすべてを全プランで毎秒20リクエストで処理し、バッチエンドポイントなら1,000ツイートあたり$0.02から、プランは月額$49から利用できます。読み取りの規模では、公式 API のリソース単位の料金と比べて1投稿読み取りあたり最大50分の1のコストになり、収集パイプラインで429の大半を招く15分の窓とアプリ単位・ユーザー単位の分割もなくなります。

始め方 {#getting-started}

ここまで見てきたエンドポイント別の窓と429から抜け出したいのであれば、違いを最短で体感する方法は、自分で何回か呼び出してみることです。インタラクティブなプレイグラウンド は、キーも登録も不要でブラウザから稼働中のエンドポイントを実行できるため、何かを決める前にレスポンスの形を確認できます。実装に進む段階になったら、Sorsa API のクイックスタート を使えば数分で APIキー1つの認証まで進められます。新規アカウントにはもれなく100回分の無料リクエストが付きます。初回のみ、クレジットカード不要・有効期限なしで、40個のエンドポイントすべてで有効です。バッチエンドポイント経由なら最大10,000ツイートまたは20,000プロフィールに足ります。それを超えたら、料金プラン はバッチエンドポイントで1,000ツイートあたり$0.02から、月額$49からのプランで、上で触れた一律の毎秒20リクエストが適用されます。アプリ審査も、OAuth の煩雑な手順も、頭に入れておくレート制限の表もありません。

監修：Keksich（Sorsa創業者、マーケター兼X APIリサーチャー）

本ガイドのまとめ方：ここに載せたエンドポイントの数字はすべて X の公式レート制限表から直接読み取り、アカウントレベルの上限は X の制限ドキュメントから取っています。どちらも2026年7月31日に再確認しました。これらの数字はさほど予告なく変わるためです（X は2026年5月というつい最近に未認証アカウントの1日の投稿上限を2,400件から50件へ削り、2026年4月にはエンゲージメント書き込みを Enterprise 限定へ移しました）。スループットの計算、429からの復帰コード、「どの制限が先に当たるか」という整理は、代替の Twitter/X API を開発・運用してきた自チームの経験と、チームが手がける読み取りパイプラインの移行案件、そして上の匿名化した fintech の事例（詳細は統合し、識別につながる情報は取り除いています）に基づいています。料金と使用量上限に関する記述は、別記事の X API 料金の解説を要約したものです。運営者と連絡先については Sorsa について をご覧ください。ここに挙げた統計・情報源・顧客の成果に、捏造されたものは1つもありません。