X (Twitter) API 制限の完全ガイド — レート制限・月間 2M cap・回避方法
X (旧Twitter) API の「制限」は実は 3 層の異なる仕組み が同時に動いています:per-endpoint レート制限(15分単位の上限)、月間ハードキャップ(月 2,000,000 Post reads)、アカウントレベルの利用制限(2023年の閲覧制限騒動の原因)。多くの JA SERP 記事はこの 3 層を混在させてしまい、ユーザーが「自分の状況がどの層に当たっているか」分からないまま放置するケースが多発しています。
この記事では docs.x.com の公式仕様に基づいて、13 個の主要 endpoint のレート制限表(per-15min app 認証 / user 認証)、月間 2M Post reads ハードキャップ の挙動、HTTP 429 と 403 の正確な使い分け(429 は "15分レート OR 月キャップ exceeded"、403 は scope/権限不足)、そして 回避方法 3 つ(24時間重複排除を活用した cache 設計、Owned Reads $0.001 単価、第三者 API twitterapi.io への切替)まで実装に直結する具体的な情報を提供します。
JA SERP の競合記事(camtsuku / note / chiebukuro / nojima 等)は「VPN 切替で IP を変える」「proxy 旋転」といった 2026年現在は通用しない古い対策 を未だに掲載していますが、X は behavioral fingerprinting を採用しているため、IP だけ変えても他の signal (TLS 指紋・cookie 履歴・タイミング) が継続している限り検出されます。技術的に正しい回避策はこの記事の Section 4 で扱います。
X API 制限とは — 3 層構造を理解する
X API の「制限」と一言で言っても、実際には 3 つの異なる仕組み が同時に動いています。これを混在させて議論してしまうと、解決策がまったく違う方向に向かいます。順番に区別していきましょう。
第 1 層 — per-endpoint レート制限 (rate limit)。 エンドポイント別に 15 分単位の上限が定義されています。例えば /2/tweets の read は app 認証で 3,500 リクエスト/15分、user 認証で 5,000 リクエスト/15分。/2/users は app 300 / user 900 と、endpoint ごとに数字が違います。これは「短期間にどれだけリクエストを連発できるか」の上限で、超えると HTTP 429 が返ります。15 分待つ(または x-rate-limit-reset header の Unix timestamp まで待つ)と自動で解除されます。
第 2 層 — 月間ハードキャップ (monthly cap)。 Post reads は 月 2,000,000 リクエスト/月 が上限で、これを超えると 公式 API では翌月 1 日まで取得不可能 になります(2026 年 4 月 16 日以降明確化)。これも HTTP 429 で返るため、「429 = 15 分レート」とは限らず、月キャップ到達もあり得る ことに注意。区別の方法は x-rate-limit-reset header の reset 時刻が「15 分以内」か「月末まで」かでチェックします。
第 3 層 — アカウントレベルの利用制限 (account-level limit)。 これは API 経由でない通常閲覧にも適用される制限で、特定アカウントの行動パターン(短時間の大量 follow / unfollow、自動化された投稿等)が検知された場合に、X 全体での閲覧・投稿・API 利用が制限されます。2023 年の "閲覧制限" 騒動 はこれが massive スケールで発動した事例。これは Day 4 ページ「スパムと判断された場合の解除方法」(/ja/blog/x-spam-kaijo)で詳しく扱います。
3 層を区別する重要性。 検索する人の多くは(1) の レート制限 か(2) の 月キャップ に当たっています。VPN 切替やプロキシ旋転は(3) のアカウント問題には少し効くかもしれませんが、(1) (2) には完全に無効です。正しい区別から正しい対策が始まります。
重要(v2 で訂正): 従来「Basic 月 10K reads / Pro 月 1M reads」という per-tier の月間上限がありましたが、2026 年 4 月 16 日以降、月額プランは legacy 扱い となりました。新規ユーザーは pay-per-use がデフォルトで、月間制限は per-endpoint レート制限 + 月 2M Post reads cap の組み合わせとなっています。古い記事の per-tier 月額制限の話は現在のユーザーには適用されません。
現在の per-endpoint レート制限 — docs.x.com 最新仕様
docs.x.com の rate-limits ページから抽出した、主要 13 endpoint の 15 分単位上限 です(app 認証 = Bearer Token、user 認証 = OAuth tokens で異なる):
Read 系 endpoint (取得):
| Endpoint | App 認証 | User 認証 |
|---|---|---|
/2/tweets (read) | 3,500 / 15min | 5,000 / 15min |
/2/tweets/:id | 450 / 15min | 900 / 15min |
/2/tweets/search/recent | 450 / 15min | 300 / 15min |
/2/users | 300 / 15min | 900 / 15min |
/2/users/by | 300 / 15min | 900 / 15min |
/2/users/by/username/:username | 300 / 15min | 900 / 15min |
/2/users/:id | 300 / 15min | 900 / 15min |
/2/users/:id/tweets | 10,000 / 15min | 900 / 15min |
/2/spaces | 300 / 15min | 300 / 15min |
/2/spaces/search | 300 / 15min | 300 / 15min |
/2/lists/:id | 75 / 15min | 75 / 15min |
/2/lists/:id/tweets | 900 / 15min | 900 / 15min |
Write 系 endpoint (作成):
| Endpoint | App 認証 | User 認証 |
|---|---|---|
/2/tweets (POST, 作成) | 10,000 / 24時間 | 100 / 15min |
重要な観察 (3つ):
(1) app 認証 vs user 認証で 2-3 倍違うことがある。 例えば /2/users/:id/tweets は app 認証 10,000/15min vs user 認証 900/15min と 10 倍以上の差。app 認証(Bearer Token)で叩ける場合は app を使うのが圧倒的に効率的。
(2) Lists 系が一番厳しい。 /2/lists/:id は app/user 共に 75/15min — 1 秒に 1 リクエスト以下しか叩けない。Lists ヘビーな use case は最初から twitterapi.io を検討するべき。
(3) Post 作成は 24 時間ベースでも制限あり。 /2/tweets POST は app 認証で 10,000/24hrs(15 分単位ではない、日次)。自動投稿ボットは「毎日 10,000 リクエストを 24 時間に分散」する設計が必要。
月間ハードキャップ (pay-per-use プラン):
- Post reads: 2,000,000 / 月 ← この上限を超えると公式では翌月 1 日まで取得不可
- Spending limits: user-configurable(払う金額のキャップ)
- 24時間重複排除: 同 post を 1 日内に複数 query しても 1 回のみ計上
Rate limits and billing are separate — docs.x.com 明記の重要なルール。レート制限に達しなくても料金は発生し、料金キャップに達しなくてもレート制限は発生し得ます。両者は独立した仕組み。
「API呼び出しの回数制限を超えました」エラー — HTTP 429 と 403 の区別
この画面を見ると焦りますが、HTTP ステータスコードによって原因と対処が大きく違います。最新の docs.x.com 仕様では:
HTTP 429 (Too Many Requests) — 統一エラー (v2 で重要訂正):
docs.x.com の最新仕様では、429 は 「レート制限超過 OR 月間 cap 到達」を統一して カバーします。つまり 429 が出たら 2 つのケースが考えられます。区別は x-rate-limit-reset header の Unix timestamp で行います。
ケース A: 15分レート制限超過 (一時的)
- 例: /2/tweets read を 1 分で 5,000 リクエスト発射 → 4,000 リクエスト以降 429 が返る
- x-rate-limit-reset header: 15 分以内 の Unix timestamp
- 対処: 15 分待ち、または exponential backoff (30秒 → 1分 → 5分)。リセット時刻まで待つのが最も効率的
- 根本対策: cache 設計を見直し、リクエストを 15 分間に分散
ケース B: 月間 2M Post reads キャップ到達 (致命的)
- 例: 月初から大量 read で月の 20 日めに 2M 到達 → 月末まで完全停止
- x-rate-limit-reset header: 月末まで の Unix timestamp(または header なし)
- 対処: 公式では翌月 1 日まで取得不可 ❌
- 解決策: 第三者 API (twitterapi.io) に切替 → 月間キャップなし、即時復帰
HTTP 403 (Forbidden) — 認証はあるが権限がない:
これは 「rate limit ではない」。HTTP 403 のレスポンス body には特殊な error code が入る場合があります(例:{"errors":[{"code":226,"message":"..."}]} ← 「自動的なものと判断」の場合)。原因と対処:
- API key の scope に対象 endpoint が含まれていない → API key を再発行 + 適切な scope 付与
- enroll プランで利用不可能な endpoint を呼んだ → Enterprise 契約(contact-sales)または twitterapi.io 切替
- Following / Likes / Quote-Posts は self-serve プランから除外 (2026-04-16〜) → 公式では Enterprise 契約専用、twitterapi.io なら可
- アカウントレベルでロックされている (HTTP 403 + body code 226) → Day 4 ページ「スパムと判断された場合」(/ja/blog/x-spam-kaijo)で扱う解除手順を実行
ステータスコードで切り分けるフローチャート:
```
HTTP 429 受け取った
↓ x-rate-limit-reset header をチェック
├─ < 15分後 → ケース A (レート制限) → 待つ + backoff
└─ 月末 / なし → ケース B (月間 cap) → twitterapi.io 切替
HTTP 403 受け取った
↓ レスポンス body の error code をチェック
├─ code: 226 → アカウントレベル問題 → Day 4 解除手順
├─ scope 不足 → API key 再発行 + 適切な scope 付与
└─ プラン不可 → twitterapi.io 切替 or Enterprise 契約
```
重要な誤解:HTTP 226 は HTTP status code ではない。 RFC 3229 で定義される HTTP 226 "IM Used" は delta encoding 用で、spam/bot detection とは無関係。X API の 226 は レスポンス body 内の error code(HTTP wrapper は 403 Forbidden)です。dev community でこの混乱が頻発するので、レスポンス確認時は HTTP status と body code を別々に ログするのが推奨です。
X API 制限を回避する 3 つのアプローチ
ここから実装に直結する話。3 層構造を理解した上で、それぞれに対する対策は異なります。
アプローチ 1: 24 時間重複排除を活用した cache 設計
公式仕様で 同じ post を 1 日内に複数 query しても 1 リクエスト分のみ計上 されます(docs.x.com post-cap 明記)。自分のアプリで「同じ post の閲覧 / 共有 / 分析」が複数回発生する場合、1 日 cache を入れるだけで実質コストとレート両方を N 倍削減できます。
実装例: Redis に 24 時間 TTL で post id をキーにキャッシュ。同じ post を再 query 時はキャッシュから返す。これだけで:(a) 月キャップ 2M Post reads に到達しにくくなる(同 post 複数回でカウント 1)、(b) 15 分レート制限にもヒットしにくくなる(キャッシュヒットでネットワーク request 自体が減る)。レート制限ケース A の根本対策にも有効です。
アプローチ 2: Owned Reads $0.001 を活用 + 自社アカウントを使う
「自分の dev app と自分のアカウントの data」を読む場合は Owned Reads $0.001/リクエスト (一般 read $0.005 の 1/5)。ただし月 2M Post reads cap は Owned Reads でも適用される ので、cap 回避にはならない点に注意 — Owned Reads はあくまでコスト削減策。
自社運営の bot アカウントから自社アカウント分析を行うユースケースは、この単価を必ず活用すべき(設定によっては年間で数十万円の差)。実装は API call 時に user_id を自社認証ユーザーと一致させるだけ — 内部で自動的に Owned Reads 単価が適用されます。
アプローチ 3: 第三者 API (twitterapi.io) を使う
15 分レート制限なし — リクエスト集中スパイクに柔軟対応。月間ハードキャップなし — 公式 2M cap を超える月 5M / 月 10M も対応可能。1 リクエスト $0.00015 — 公式一般 read ($0.005) の 約 1/33 のコスト。X 公式 API と互換性のある endpoint 設計のため、移行コストも低い(Python なら 2 行の置換)。
選択ガイド:
| 直面している制限 | おすすめ対策 |
|---|---|
| 15 分レート制限頻発 | アプローチ 1 (cache 設計) + アプローチ 3 (twitterapi.io 切替) |
| 月 2M cap が見えてきた | アプローチ 3 (twitterapi.io 必須) |
| Following / Likes が必要 | アプローチ 3 (twitterapi.io 一択、公式 self-serve から除外済み) |
| 自社運営 bot の自己読み | アプローチ 2 (Owned Reads + cache) |
| 中規模 SaaS で長期持続 | アプローチ 3 (97% コスト削減 + cap なし) |
proxy 旋転は効果がない理由(JA 古い記事の誤解):
JA SERP の多くの記事は「レジデンシャルプロキシで IP を変えれば突破できる」と主張しますが、これは 2026 年現在通用しません。X は behavioral fingerprinting を採用しており、ブラウザ / クライアント / API 行動パターンも見ている ため、IP だけ変えても TLS フィンガープリント、header の順序、cookie 履歴、リクエストタイミング が同じであれば検出されます。根本対策は API 側の使い方を見直すか、構造的に第三者 API に切り替えるかの 2 択(これは Day 4 ページでも詳述)。
twitterapi.io で X API の制限から構造的に解放される
twitterapi.io は X 公式 API と互換性を持ちつつ、15 分レート制限・月間キャップ・self-serve 除外の 3 つの制限から開放された第三者 API です。"取得制限の構造" 自体を取り去る という意味で、技術的・経営的に長期持続する選択肢。
主な特徴:
- 15 分レート制限なし — リクエストを 1 秒で 10,000 投げても問題なし
- 月 2M Post reads cap なし — 月 5M、月 10M も対応可能
- Following / Likes / Quote-Posts も取得可能 — 公式 self-serve から除外された endpoint も使える
- 月額固定費ゼロ — 実使用分のみ
- 1 リクエスト $0.00015 — 公式一般 read の 約 1/33(約 ¥0.024)
- X 公式 API と同じ endpoint 設計 — 移行コスト低
- 日本のクレジットカード・請求書対応、消費税対応の領収書発行
月別コスト + 制限の対比表:
| 使用量 (月) | X 公式 (pay-per-use) | twitterapi.io | 削減率 |
|---|---|---|---|
| 月 100,000 reads | $500 (¥79,565) | $15 (¥2,387) | 97% |
| 月 500,000 reads | $2,500 (¥397,825) | $75 (¥11,935) | 97% |
| 月 2,000,000 reads (cap 上限) | $10,000 (¥1,591,300) | $300 (¥47,739) | 97% |
| 月 5,000,000 reads | 取得不可 ✗ | $750 (¥119,348) | – |
移行は 2 行の置換: 認証 header を Bearer Token から X-API-Key に、endpoint base URL を api.x.com/2/ から api.twitterapi.io/twitter/ に。それだけで /twitter/user/info、/twitter/user/last_tweets、/twitter/tweet/advanced_search 等の互換 endpoint が使えます。
(CTA: [twitterapi.io 料金詳細はこちら →](/ja/blog/x-api-ryokin) + [アカウント作成 (無料 + $10 voucher 同等) →](/sign-up) + [X API 互換 endpoint ドキュメント →](https://docs.twitterapi.io))
実装例: Python migration コード
公式 X API から twitterapi.io に切り替える最小限のコード例。/2/users/by/username/:username を /twitter/user/info に置換する形で、認証 header と base URL の 2 か所だけ変えれば動きます。レート制限 + 月間 cap から解放される最小投資の移行パスです。
import os
import time
import requests
API_KEY = os.environ["TWITTERAPI_IO_KEY"]
# === Helper: rate-limit-aware GET (公式 X API 用) ===
def get_official(url, headers, max_retries=5):
for attempt in range(max_retries):
r = requests.get(url, headers=headers, timeout=30)
if r.status_code == 429:
# 公式 X API のレート制限超過。x-rate-limit-reset で待ち時間を判定
reset = int(r.headers.get("x-rate-limit-reset", "0"))
wait = max(reset - int(time.time()), 30)
if wait > 60 * 60: # 1時間以上待つ → 月間 cap の可能性
raise RuntimeError(
"X API 月間 cap 到達の可能性 — twitterapi.io 移行を検討してください"
)
print(f" 429 — {wait}秒待ち (15分レート制限)")
time.sleep(wait)
continue
r.raise_for_status()
return r.json()
raise RuntimeError("max retries exceeded")
# === 移行前 (公式 X API): 15分レート制限 + 月間 2M cap に毎月ヒット ===
# x_headers = {"Authorization": f"Bearer {X_BEARER_TOKEN}"}
# user = get_official(
# "https://api.x.com/2/users/by/username/elonmusk",
# x_headers,
# )
# === 移行後 (twitterapi.io): 15分レート制限なし + 月間 cap なし ===
headers = {"X-API-Key": API_KEY}
r = requests.get(
"https://api.twitterapi.io/twitter/user/info",
params={"userName": "elonmusk"},
headers=headers,
timeout=30,
)
r.raise_for_status()
user = r.json()
print(f"@{user['data']['userName']}: followers {user['data']['followers']:,}")
# === 大量データ取得もレート制限気にせず一気に ===
# `/twitter/user/last_tweets` は cursor-based pagination、ループで全件取得可能
results = []
cursor = None
while True:
params = {"userName": "nasa"}
if cursor:
params["cursor"] = cursor
r = requests.get(
"https://api.twitterapi.io/twitter/user/last_tweets",
params=params,
headers=headers,
timeout=30,
)
r.raise_for_status()
body = r.json()
results.extend(body["data"]["tweets"])
if not body.get("has_next_page"):
break
cursor = body.get("next_cursor")
print(f"取得完了: {len(results):,} tweets — 公式 API なら月キャップ計算が必要、twitterapi.io ならそのまま")
よくある質問
TwitterのAPI取得の制限は？
X API の取得 (read) 制限は per-endpoint per-15min 単位 で管理されています。例えば /2/tweets read は app 認証で 3,500 リクエスト/15分、user 認証で 5,000 リクエスト/15分。/2/users は app 300 / user 900、/2/tweets/search/recent は app 450 / user 300。さらに pay-per-use プランには 月間 2,000,000 Post reads ハードキャップ があります。従来の月額プラン (Basic / Pro / Enterprise) は 2026年4月16日以降 legacy 扱いとなり、新規ユーザーは pay-per-use がデフォルトです。
なぜTwitterのAPIが制限されたのか？
主な理由は3つ:(1) スパム / bot による大規模 API 利用の抑制、(2) X 社のデータ販売を持続可能な収益源とする、(3) AI 学習データへの大量無料アクセス制限。Elon Musk による買収以降、X は API データを商業価値の高いアセットとして位置づけ、料金プランの段階的見直しを進めてきました。Following / Likes / Quote-Posts も 2026年4月16日に self-serve プランから除外され、Enterprise 契約専用になりました。
API制限はいつ解除されますか？
15分レート制限は 15分待てば自動でリセット されます。HTTP レスポンスの x-rate-limit-reset ヘッダー (Unix timestamp) でリセット時刻を確認できます。月間 2M Post reads キャップは 翌月1日にリセット。短期解決には exponential backoff (30秒 → 1分 → 5分 → 15分)、長期解決には pay-per-use の cache 設計見直しか、第三者 API (twitterapi.io) への切替が現実的です。
「API呼び出しの回数制限を超えました」と表示されるのはなぜ？
docs.x.com の最新仕様では HTTP 429 が「レート制限超過 OR 月間 cap 到達」を統一してカバー しています。x-rate-limit-reset ヘッダーをチェックして、15分以内なら 15分レート制限(待てば解決)、月末までなら月間 2M Post reads キャップ到達(月末まで完全停止)です。後者の場合、公式 API では翌月まで取得不可能なので、即時復帰したいなら twitterapi.io のような第三者 API への切替が現実的です。なお HTTP 403 はレート制限ではなく権限不足エラーで、API key scope の確認、または body 内の error code(226 = アカウントレベル問題)を確認します。
X API の制限を回避する一番安い方法は？
第三者 API の twitterapi.io が最もコスパ良好 です。1リクエスト $0.00015 で、公式一般 read ($0.005) の 約 1/33 のコスト。月額固定費もなく、15分レート制限も月 2M Post reads キャップもありません。Following / Likes / Quote-Posts なども取得できる(公式 self-serve からは除外)。X 公式 API と互換性のある endpoint 設計のため、移行コストも低めです。個人開発から月500万リクエストの大規模 SaaS まで広くカバーできます。
VPN や residential proxy で X API の制限を回避できますか？
現在の X は IP だけで判断していません。2023年以前は IP が重要 signal でしたが、買収以降は behavioral fingerprinting(TLS フィンガープリント・header の順序・cookie 履歴・タイミング・アクセスパターン)に大きくシフトしています。VPN や proxy で IP だけ変えても、他の 6 次元の signal が同じであれば検出されます。古い JA 記事の "proxy 旋転で突破" という解説は 2026 年現在通用しないので、根本対策は API 側の使い方を見直すか、構造的に第三者 API に切り替えるかの 2 択 です。
X API の月間 cap は何が原因で、回避する方法は？
月間 2,000,000 Post reads cap は X の pay-per-use プランのハードキャップで、X 社が「無制限読み取り」を制度的に抑止するために設けたもの。回避方法は基本的に2つ:(1) 24時間重複排除を活用する cache 設計(同 post を 1 日内に複数 query しても 1 リクエストで計上 → 実質キャップ消費を N 倍削減)、(2) twitterapi.io への切替(月間 cap なし、月 5M / 10M も対応可能)。中規模 SaaS で月 100K-500K reads クラスなら (1) を試し、月 1M+ なら (2) が現実的です。
Following / Likes / Quote-Posts が取得できないのはなぜ？
2026 年 4 月 16 日に、X API の self-serve プランから Following / Likes / Quote-Posts の取得 endpoint が除外 されました(docs.x.com changelog 明記)。これらの endpoint は現在 Enterprise 契約専用 で、contact-sales 経由で月数千ドル〜の契約をしないと公式では使えません。twitterapi.io 経由なら通常の単価($0.005-$0.010 級ではなく $0.00015)で取得可能 なので、これらの endpoint が必要なら twitterapi.io が事実上の選択肢になります。
HTTP 226 は何のエラーですか？
HTTP 226 は X API の HTTP status code ではありません。RFC 3229 で定義される HTTP 226 "IM Used" は delta encoding 用で、spam/bot detection とは無関係。X API における 226 は レスポンス body 内の error code({"errors":[{"code":226,"message":"This request looks like it might be automated..."}]})で、HTTP wrapper は 403 Forbidden です。アカウントレベルで "自動化された行動" と判断された場合に返ります。解除手順は別ページ /ja/blog/x-spam-kaijo で扱います。
app 認証と user 認証で制限が違うのはなぜ？
X API は 2 種類の認証方式を提供しており、レート制限の挙動が異なります。app 認証 (Bearer Token) はアプリ全体の上限を共有する形で、/2/users/:id/tweets のように大量取得向けに 10,000/15min と高めに設定。user 認証 (OAuth tokens) はユーザー単位の上限で、/2/tweets read を 5,000/15min と app より高くしますが、ユーザー数が多い場合は user 認証の方が総量で有利。設計指針:大量取得 = app 認証、ユーザー操作 = user 認証 が基本です。