【2026年版】Twitter のレート制限超過：原因と対処法

著者：Sorsa Editorial

2026年7月11日更新：現行の X API のリソース単位の読み取り価格と月200万投稿読み取りの上限を X の料金ドキュメントに対して確認し、加えて無料と Premium のアカウントの広く報告された2026年のアプリ内の読み取り上限を反映しました。

要点： Twitter/X の「レート制限超過」は、現在の窓が許すより多くのリクエストをしたことを意味し、そのアクションが短くブロックされます。通常のユーザーは、速くスクロール、更新、またはフォローすることでそれを引き起こします。開発者は HTTP 429 とエラーコード88 を見ます。最も速い対処法は、止めて窓のリセットを待つことです。

「レート制限超過」という言葉は、2つの完全に異なる問題を指し、対処法はどちらを持っているかによります。メッセージがアプリをスクロールまたは更新しているときに現れたなら、アカウントのプラットフォームレベルの上限に当たりました。それがスクリプトやサーバーログに HTTP 429 として現れたなら、X API のエンドポイント別のレート制限に当たりました。本ガイドは両方を、それらをどう見分けるかから始めて扱います。

開発者には、同じ429 が現れ続ける理由は、しばしば3つの別々の制限がすべてそれを返すからです。エンドポイント別の15分の窓、X アカウント自身の上限、そして月次の使用量の天井です。当社は代替の Twitter/X API である Sorsa API を運用しているため、これらの制限とそれが生む429 には、自身のパイプラインでも、扱っている読み取りの多い移行全体でも、毎日当たります。それがまた、Sorsa を窓のモデルなしに作った理由でもあります。すべてのエンドポイントで一律の毎秒20リクエストの制限、15分のリセットもやりくりすべきアプリ単位対ユーザー単位の分割もなく、公式のリソース単位の料金よりはるかに安く動く読み取りです。以下の数字は、今 X（旧Twitter）で付き合っているもので、さらに下では2つのモデルを並べます。

最終確認：2026年7月11日、X のレート制限と料金のドキュメントに対して。

目次

• レート制限超過：アプリ内のメッセージ対 API の429
• X の閲覧中にブロックされた：原因とどれくらい続くか
• Twitter/X API の429：HTTP ステータスとエラーコード88
• どの制限に当たった？429 の背後の3つの層
• 即時の対処法：リセットヘッダーを読んでバックオフする
• Twitter API のレート制限を避ける方法
• 有料プランはレート制限を取り除く？
• 実践：429 で止まり続けたソーシャルリスニングチーム
• よくある質問

レート制限超過：アプリ内のメッセージ対 API の429 {#rate-limit-exceeded-the-in-app-message-vs-the-api-429}

同じ3語が、2つの無関係な故障を記述します。1つは通常の X アカウントへのプラットフォームのブロックで、アプリまたはウェブサイトに表示されます。もう1つは X API を呼ぶプログラムに返される HTTP 429 です。それらは異なる原因、異なるリセットの挙動、そして異なる対処法を持つため、最初のステップは症状を正しい列に一致させることです。

通常のユーザーで開発者 API に決して触れないなら、最初の2行だけが当てはまり、対処法はほぼつねに止めて待つことです。API に対して構築しているなら、429 はコードで読んで応答できるシグナルで、そこが本ガイドのほとんどが焦点を当てるところです。2つのシステムは別々に強制されます。通常のアカウントと開発者アプリは異なる予算から引くため、一方で問題ないことが、もう一方での安全を保証しません。

X の閲覧中にブロックされた：原因とどれくらい続くか {#blocked-while-browsing-x-causes-and-how-long-it-lasts}

メッセージが X を通常に使っているときに現れたなら、API 制限ではなく、アカウントに結びついたプラットフォームレベルの上限を越えました。X は、自動化を遅らせインフラを保護するために、これらの上限を読み取り、投稿、フォロー、いいね、メッセージングに適用します。ブロックは一時的で、窓がリセットするといったん自分でクリアされます。

通常のユーザーにとって最もよくある引き金は、2023年7月に導入され、緩和された形で2026年にもまだアクティブな1日の読み取り上限です。X は正確な数字を公式に公開しませんが、アカウントのテスト全般で一貫して報告される数字は、未認証の無料アカウントで1日およそ1,000投稿、認証済みの Premium アカウントで約10,000、そして1か月未満の真新しい未認証アカウントで約500です。スクロールで通り過ぎるすべての投稿は、タップしないものでさえ、読み取りと数えるため、メディアの豊富なフィードを重くスクロールすることが、通常それを引っかけるものです。

他のアカウントのアクションは、それぞれの上限を持ちます。速すぎるフォローとアンフォロー（およそ1時間に数十が問題の始まるところ）、連射のいいね、多くのダイレクトメッセージの送信、または1時間にひと握りを超えるアカウントのメール変更は、それぞれ同じメッセージを生み得ます。アカウントに接続されたサードパーティアプリは、バックグラウンドで API 呼び出しをし、同じ予算からも引くため、スケジューラー、分析ツール、フォロワートラッカーが一度に動くと、自分では何もしていなくてもそれを枯渇させ得ます。

どれくらい続くかは、どの上限に当たったかによります。

• ほとんどの窓ベースのブロックは、ローリングウィンドウが過ぎると 15〜60分 でクリアされます。
• 読み取り制限を含む1日の上限は、UTC の深夜 にリセットされます。
• 繰り返しの違反は、フラグ付けされたアカウントで制限を 24〜72時間 に延ばし得ます。

対処法はシンプルで、ほとんどはきれいに待つことについてです。更新をやめてください。すべてのリトライがクールダウンを延ばし得るからです。アプリやタブを閉じ、30分離れます。サードパーティのクライアントを使うなら、それらすべてからログアウトします。そのバックグラウンドの呼び出しが実際の原因かもしれないからです。プラットフォーム全体のインシデントがレート制限として誤報告されている場合に備えて、Downdetector や X 自身のステータスの更新を確認します。ブロックが何時間も続くなら、ログアウトし、クッキーをクリアし、ログインし直すことがときに役立ちます。アクションとアカウントのタイプ別のアカウントレベルの上限の完全な内訳は、X アカウントと API のレート制限 のリファレンスが、それぞれを現行の数字で列挙します。

Twitter/X API の429：HTTP ステータスとエラーコード88 {#the-twitterx-api-429-http-status-and-error-code-88}

開発者 API では、「レート制限超過」は HTTP 429 のレスポンスとして届きます。それは、現在の窓の中でエンドポイントの制限が許すより多くのリクエストを送ったことを意味し、窓がリセットするまで次の呼び出しが拒否されます。429 はトランスポート層のシグナルです。X はレスポンスボディにアプリケーション層の識別子も返します。

正確な形は、どのクライアントと API バージョンを呼んでいるかによりますが、これらはすべて同じイベントを記述します。

• 素のステータス行： HTTP 429 Too Many Requests。
• X v1.1 スタイルのボディ： {"errors":[{"code":88,"message":"Rate limit exceeded"}]}、コード88 はこのエラーの X の正典の識別子です。
• X v2 スタイルのボディ： {"title":"Too Many Requests","detail":"Too Many Requests","type":"about:blank","status":429}。
• Tweepy： tweepy.errors.TooManyRequests を投げ、呼び出しの周りの汎用の例外ハンドラーがそれを捕まえます。
• 自分のアプリの背後： フロントエンドはしばしば生の429 を汎用の「読み込めません」のメッセージに置き換えるため、実際のエラーはサーバーログにしか現れません。

429 のステータスまたはコード88 を確認したら、包装は重要でなく、同じ対処法が適用されます。重要なのは、実際にどの制限を越えたかを突き止めることです。現行の X API では3つの異なる制限がそれぞれ429 を返し得て、対処法がそれぞれ異なるからです。エラーが読み取りの間ではなく特にログインのフローの間に発火するなら、それはレート制限ではまったくなく、自動化対策のチェックかもしれません。それは別途、「このリクエストは自動化されているように見えます」のメッセージ のガイドで扱います。

どの制限に当たった？429 の背後の3つの層 {#which-limit-did-you-hit-the-three-layers-behind-a-429}

X API 上の単一の429 は、3つの別々のシステムから来得て、「レート制限には全然近くないはずだ」がこれほどよくある不満なのは、人々が1つの層を確認して他の2つを見逃すからです。レスポンスヘッダーを読むことが、どれが原因で止まったかを教えます。

層1：エンドポイント別のレート制限。 すべての X API v2 のエンドポイントは、ローリングの15分の窓（いくつかは24時間の窓を使う）で自身の上限を持ち、2つの独立したプールで追跡されます。ベアラートークン認証のアプリ単位の制限と、OAuth ユーザートークンのユーザー単位の制限です。たとえば最近の検索は、ユーザーあたり15分ごとに300リクエストを許可します。1万人のユーザーがアプリ専用のバックエンドに当たると、全員が1つの共有のアプリ単位のプールから支出するため、単一のユーザーが個人の制限を超えていなくてもアプリがスロットルされ得ます。これが x-rate-limit-* ヘッダーが記述する層です。

層2：X アカウント自身の上限。 開発者 API の制限とは別に、アプリの背後の X アカウントは、ウェブ、モバイル、API を合わせてアクションを数えるプラットフォーム全体の上限に縛られます。API を通じて投稿する自動化は、電話からの手動の投稿と同じ1日あたりの予算から引きます。ワークフローが公開データを読むだけでなくアカウントに対して動作するなら、アカウント上限が、エンドポイント別の予算にまだ余地があるのに429 を生み得ます。

層3：月次の使用量上限。 X が2026年に従量課金の料金に移って以来、標準アカウントは月200万投稿読み取りのハードな天井を持ちます。すべての15分の窓の内側に快適に収まりながら、月次の上限が使い果たされたためにブロックされることもあり得ます。レート制限はどれだけ速く呼ぶかを制御します。使用量上限は請求サイクルあたりどれだけ消費するかを制御します。それらは別々に追跡され強制されます。

数秒でそれらを見分ける方法はこうです。

読み取りの多い作業には、レート制限ではなく月次の上限が通常先に当たるものです。エンドポイント別の窓が実際のボトルネックになるのは主に、書き込みと、アプリ専用認証での高並行のパイプラインです。プールごとの完全なエンドポイント別の数字は、X API レート制限リファレンス に、200万上限のコスト側は X API 料金の内訳 にあります。

即時の対処法：リセットヘッダーを読んでバックオフする {#the-immediate-fix-read-the-reset-header-and-back-off}

層1のレート制限から抜け出す最も速い方法は、盲目的な固定の間隔ではなく、窓が必要とするのと正確に同じだけ待つことです。429 自体を含むすべての X API レスポンスは、自分がどこに立っているかを教える3つのヘッダーを運びます。

x-rate-limit-limit: 900
x-rate-limit-remaining: 12
x-rate-limit-reset: 1783779300

x-rate-limit-limit は現在の窓の天井です。x-rate-limit-remaining は残りです。x-rate-limit-reset は窓が再び開くときの Unix タイムスタンプです。そのタイムスタンプから現在時刻を引けば、何秒待つべきかを正確に知ります。推測は一切ありません。

素朴な回復は一律の15分をスリープしてリトライします。それは動きますが時間を無駄にします。より良いパターンは、リセットのタイムスタンプを読み、その分だけ待ち、ヘッダーが欠けているなら指数バックオフにフォールバックします。

import time
import requests

def request_with_backoff(url, headers, params=None, max_retries=5):
    delay = 1
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers, params=params, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response

        reset = response.headers.get("x-rate-limit-reset")
        if reset:
            wait = max(int(reset) - int(time.time()), 1)
        else:
            wait = delay          # no header: exponential backoff
            delay *= 2
        print(f"429 hit, waiting {wait}s (attempt {attempt + 1}/{max_retries})")
        time.sleep(wait + 1)      # small buffer past the reset

    raise RuntimeError("Rate limit retries exhausted")

コードより2つのルールが重要です。即座にリトライしないでください。きついリトライループは、（アプリ専用認証で）他のエンドポイントにまたがる残りの予算を燃やし、より重いスロットリングを引き起こし得るからです。そしてバルクのパイプラインで429 を無視しないでください。収集ループの中の1つの429 は、コードが反応する前に数百の失敗したリクエストを意味し得るため、各呼び出しの前に x-rate-limit-remaining を確認し、それが制限のおよそ10〜20%を下回ったら一時停止します。x-rate-limit-remaining の時系列ログは、どの呼び出しパターンが予算を枯渇させているかをデバッグしているとき、最も有用な単一の成果物です。

Twitter API のレート制限を避ける方法 {#how-to-avoid-twitter-api-rate-limits}

バックオフは現在の窓を切り抜けさせます。壁の外に留まることは、データの単位あたりより少ないリクエストを支出することについてです。これらが、扱ってきた読み取りパイプラインの移行から引き出した、実際に計算を変える手です。

単一の照会をループする代わりにバッチする。 X のバッチツイートエンドポイントは1回の呼び出しで最大100件のツイート ID を、そのユーザーエンドポイントは最大100件のユーザー名または ID を取り、それぞれがより厳しいものからの100回の別々の消費ではなく、より高いバッチ制限に対する1リクエストです。サードパーティ API はこれをさらに推し進めます。バルクツイートエンドポイント はリクエストあたり100件のツイート URL または ID を、バッチプロフィール照会 は100件のプロフィールを取り、それぞれが枠からの1リクエストと数えます。

ゆっくり動くデータをキャッシュする。 プロフィールのメタデータ、フォロワー数、そしてハンドルから ID への解決は、秒ではなく日で変わります。それらを12〜24時間の TTL でキャッシュし、キャッシュヒットで呼び出しを飛ばします。エンゲージメント指標はより速く動くため、分析には1〜6時間の TTL が妥当なバランスです。

カーソルでページネーションし、再取得しない。 元のクエリを再実行するのではなく、レスポンスのカーソルを使って次のページを取得します。検索を再実行すると、すでに支払ったのと同じコンテンツを検索します。

できるところでポーリングをストリーミングに入れ替える。 最近の検索を30秒ごとにポーリングするのは、1つのエンドポイントへ1日2,880リクエストです。X のフィルタードストリームは代わりに、一致する投稿を単一の永続的な接続で押し出します。ストリーミングのないプロバイダーには、フラットな毎秒の制限での速いポーリングがほとんどのリアルタイムのニーズをカバーします。トレードオフは リアルタイム Twitter 監視 のガイドで詳しく扱っています。

認証プールにまたがって分割する。 アプリ単位とユーザー単位の制限は独立しているため、ベアラートークンと OAuth ユーザートークンの両方で認証すると、両方をサポートするエンドポイントに2つのバケツを得ます。これはサーバー側でのみ役立ち、クライアントのみのアプリでは通常不可能です。

読み取りの多い作業で壁に当たり続けるなら、構造的な対処法は、窓のモデルを完全に離れることです。フラットなレート制限は、収集パイプラインでほとんどの429 を引き起こす15分のリセットとアプリ単位対ユーザー単位の分割を取り除きます。Sorsa は、40個すべての読み取りエンドポイントを、すべてのプランで 一律の毎秒20リクエスト で提供し、制限は大量のユースケースには 営業に相談 を通じて引き上げられます。

有料プランはレート制限を取り除く？ {#does-a-paid-plan-remove-the-rate-limit}

いいえ。公式 X API では、アップグレードは天井を上げます。取り除きません。すべての層が依然としてエンドポイント別にスロットルし、Enterprise 契約（歴史的に月約$42,000から）は、無制限の経路ではなく、より高い窓と取り払われた使用量上限を交渉します。X でレート制限を取り除くセルフサーブのプランはありません。

読み取りで壁に当たり続けるなら、2つの構造的な経路が存在します。1つは、より高い天井のために X にもっと支払うことで、それでも窓のモデルと月200万投稿読み取りの上限の中に留まります。もう1つは、固定の窓の上に作られていないサードパーティ API を通じて公開の X データを読むことで、コストがハードなリセットの崖ではなく取得するものに応じてスケールします。完全な分野の比較は、Twitter API の代替 の概要をご覧ください。

読み取りのワークロードには特に、2つのモデルはこう並びます。

1つの Sorsa リクエストは最大100ツイートまたは最大200プロフィールを返し、そこが1,000あたりの数字が来るところです。読み取りの多い収集には、それは公式のリソース単位の料金より読み取りあたり最大50分の1のコストになり、15分の窓は完全に消えます。正直なトレードオフは、Sorsa が読み取り専用であることです。投稿、DM の送信、いいねをするものは依然として公式 API で動きます。それが書き込みの準拠する経路だからです。よく見るパターンは、書き込みを X に保ち、重い読み取りをフラットレートのプロバイダーに移すことで、移行ガイド がそれを案内します。

他のサードパーティ API も X の窓の上限を取り除きますが、ほとんどはフラットではなく計測された従量課金です。たとえば TwitterAPI.io は、1,000ツイートあたりおよそ$0.15、1,000プロフィールあたり約$0.18を課金します（2026年7月確認）。計測された料金は固定窓の429 を殺しますが、請求は依然として量に応じてスケールし、前もって固定されていません。Sorsa のフラットなプランは、月次のコストを予測しやすく保ち、読み取りあたりより安く、バッチエンドポイントで1,000ツイートあたり$0.02から着地します。

実践：429 で止まり続けたソーシャルリスニングチーム {#in-practice-a-social-listening-team-that-kept-stalling-on-429s}

中規模のソーシャルリスニングツール（およそ十数人のエンジニア）が、X の収集が実行の途中で止まり続けた後に Sorsa に相談してきました。このチームは自社の顧客のためにブランドメンションを捕まえるために最近の検索をきついループでポーリングし、それから作者ごとのプロフィール照会にファンアウトしており、なぜ「15分ごとに300」の制限が429 を生み続けるのか理解できませんでした。原因はいつものものでした。アプリ専用認証は、すべての検索とすべてのプロフィール照会が同じアプリ単位のプールから引くことを意味し、ポーリングのペースだけで、ファンアウトが始まる前にそのほとんどを支出していました。

書き込むものについては、このチームを公式 API から移しはしませんでした。読み取りの多い収集をフラットレートのモデルに移し、ポーリングをイベント駆動の収集に切り替えただけです。リソース単位の料金では、その読み取り量は、安い従量課金と$42,000の Enterprise 契約の間の厄介なゾーンに座っていました。読み取りの請求は90%以上下がり、15分の窓とアプリ単位対ユーザー単位の分割が視界から消えると429 は消えました。このチームが動かす種類の継続的なブランドメンションの追跡こそ、ソーシャルリスニングのソリューション が作られたものです。

よくある質問 {#faq}

なぜ Twitter は「レート制限超過」と言う？

Twitter/X は、設定された時間の窓の中で上限が許すより多くのリクエストをすると「レート制限超過」を表示し、窓がリセットするまでアクションをブロックします。通常のユーザーには、引き金はたいてい速すぎる読み取り、スクロール、フォロー、またはいいねです。開発者にはそれは API からの HTTP 429 で、エンドポイントの窓ごとの制限、アカウント上限、または月次の使用量の天井が越えられました。

Twitter のレート制限はどれくらい続く？

ほとんどの Twitter/X のレート制限は短いです。スクロールや速いアクションからのアプリ内のブロックは、ローリングウィンドウが過ぎると通常15〜60分でクリアし、1日の上限は UTC の深夜にリセットします。API では、正確なリセット時刻が x-rate-limit-reset レスポンスヘッダーに Unix タイムスタンプとしてあり、通常15分先です。アカウントでの繰り返しの違反は、制限を24〜72時間に延ばし得ます。

Twitter API のレート制限をどう避ける？

データの単位あたりより少ないリクエストを支出します。単一の照会をループする代わりに1回の呼び出しで最大100項目を返すバッチエンドポイントを使い、プロフィールのようなゆっくり動くデータを数時間キャッシュし、クエリを再実行するのではなくカーソルでページネーションし、きついポーリングループよりストリーミングか速いポーリングを好みます。読み取りの多い作業の構造的な対処法は、X の15分の窓の代わりにフラットな毎秒のレート制限です。

有料プランは Twitter のレート制限を取り除く？

いいえ。公式 X API のプランをアップグレードすると天井が上がりますが、レート制限は決して取り除かれず、Enterprise を含むすべての層が依然として月200万投稿読み取りの上限の下でエンドポイント別にスロットルします。Sorsa API のような読み取り専用の代替は、窓のモデルをすべてのプランで一律の毎秒20リクエスト、バッチエンドポイントで1,000ツイートあたり$0.02から、で置き換え、それが429 を上げるのではなく取り除きます。

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

エンドポイントと認証によって、両方です。ベアラートークン認証はアプリ単位の制限を使い、そこではアプリケーションからのすべてのリクエストが1つのプールを共有するため、単一のユーザーが制限を超えていなくてもアプリがスロットルされ得ます。OAuth ユーザートークン認証はユーザー単位の制限を使い、そこでは各認証済みユーザーが独立したバケツを得ます。多くのエンドポイントが両方の数字を公開します。

ほとんどリクエストをしていないのに、なぜレート制限される？

たいてい3つのうちの1つです。上限はユーザー単位だけでなくアプリ単位でもあるため、自分のユーザーが集合的にアプリ全体の制限を超えています。または、呼んだエンドポイントが予想よりきつい制限を持つため、見出しの数字ではなくその特定の数字を確認します。またはバックグラウンドのプロセス、忘れられたスクリプト、または月次の使用量上限が実際の原因です。すべての呼び出しで x-rate-limit-remaining をログに記録することが、それを見えるようにします。

始め方 {#getting-started}

上の429 と15分の窓が、抜け出そうとしている問題なら、違いを感じる最も速い方法は、自分でいくつかの呼び出しを実行することです。インタラクティブな playground は、キーもサインアップもなしにブラウザで稼働中のエンドポイントを実行するため、何かにコミットする前にレスポンスの形を確認できます。ビルドの準備ができたら、Sorsa API のクイックスタート がヘッダーの中の単一の API キーで認証させ、すべての新規アカウントは100回分の無料リクエストで始まります。1回限り、クレジットカード不要・有効期限なしで、40個すべてのエンドポイントで有効、バッチエンドポイントを通じて最大10,000ツイートまたは20,000プロフィールに十分です。それを超えると、料金 はバッチエンドポイントで1,000ツイートあたり$0.02から、一律の毎秒20リクエストで月額$49からのプランで動きます。アプリ審査も、OAuth のハンドシェイクも、頭に留めておくべきレート制限の表もありません。

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

本ガイドのまとめ方：429 の形式、x-rate-limit-* ヘッダー、そしてエンドポイント別の窓の挙動は X の公式のレート制限のドキュメントに対して、アプリ内の読み取り上限は X の公開された制限のガイダンスと現行のアカウントのテストに対して、すべて2026年7月11日に確認しました。これらの数字はさほど予告なくシフトするからです。3層の診断、リセットを意識した回復のコード、そしてスループットの枠組みは、代替の Twitter/X API を運用する Sorsa 自身の作業と、当チームが扱う読み取りパイプラインの移行、上の匿名化されたソーシャルリスニングの事例（詳細は統合し、識別につながるものを取り除いています）から来ています。料金と使用量上限の数字は、別個の X API 料金のカバレッジから要約しています。競合の価格は2026年7月にソースで確認しました。運営元と連絡先は Sorsa について をご覧ください。ここの統計、情報源、クライアントの成果はどれも捏造されていません。