Twitter (X) API のデータ取得:検索から一括エクスポートまで

Twitter (X) API でデータを取得するルートは大きく3つあります。(1) 公式 X API(OAuth 認証+従量課金、月 200 万読み取りキャップ)、(2) DIY スクレイピング(snscrape / Playwright、凍結リスク+メンテ重い)、(3) 第三者データ API(TwitterAPI.io が代表、X-API-Key ヘッダーだけで OAuth 不要、固定レート制限なし、従量課金で約 $0.15 / 1,000 ツイート)。データ取得が目的なら(3)が最もスケールしやすく、本記事ではその実装と他2つとの正直な比較を整理します。
「ツイートを 100 万件まとめて取りたい」「リアルタイムで特定キーワードを監視したい」「フォロワー履歴を時系列で取りたい」——どれも公式 API のコスト・上限と、スクレイピングの凍結リスクの間で詰みやすい用途です。第三者 API はその間隙を埋める設計になっていて、登録から最初のリクエストまで約5分、コストは公式の 約 1/33 で済みます。
本記事では、3つの方法を コスト × 凍結リスク × スケール上限 × セットアップ時間 で比較し、TwitterAPI.io で バルクで取得する Python パイプライン(/twitter/tweet/advanced_search を cursor で分页 + 一回のコスト試算)、リアルタイム取得用の Webhook ルール(/oapi/tweet_filter/add_rule)、そして ボリューム別コスト試算(10K / 100K / 1M / 2M 読み取り/月)を順番に示します。
Twitter (X) API でデータを取得する3つの方法を比較する
結論を先に示します。データ取得が目的なら第三者 X-API-Key 方式が最もスケールしやすい:OAuth 不要、固定レート制限なし、月間上限なし、コスト線形。公式 X API はオフィシャル機能(Ads API・大量投稿・パートナー資格)が必須な時にのみ使い、DIY スクレイピングは小規模 PoC 専用と割り切ります。
公式とのコスト差は 約 33 倍(同じ 100 万件読み取りで公式 $5,000、TwitterAPI.io $150)、200 万件の公式キャップを超える領域では公式は Enterprise(月額 ~$42,000+)に強制されるため、差はさらに広がります。
公式 X API でデータを大量取得する場合の制約
公式 X API でデータを取得する場合、新規開発者は 2026 年の従量課金モデル で課金されます: read 1 件あたり約 $0.005、月間 2,000,000 reads のハードキャップあり。100 万件読めば約 $5,000、キャップに当たれば Enterprise(月 ~$42,000+)に移行する以外ありません。
認証は OAuth 1.0a(API Key / Secret / Access Token / Secret の 4 鍵)または OAuth 2.0(Client ID / Secret)。リクエストごとに署名を組み立てる必要があり、開発者アカウント審査も挟まります(申請から運用まで実務で 1-2 週間)。
取得性能の天井:アプリ単位のレート上限(15 分窓のリクエスト数)+ 月間 2M キャップが二重に効くため、中規模以上(月 100 万件超)のデータ取得には公式は経済合理性がほぼ崩れます。Ads API や本人として大量に投稿する用途が必須でない限り、データ取得には第三者 API のほうが素直です。
TwitterAPI.io でデータを取得する手順(X-API-Key 方式)
TwitterAPI.io は HTTPS + ヘッダー認証だけで動く第三者データ API です。手順は3ステップ。
1. サインイン:twitterapi.io で Google サインイン。$1 の試用クレジット(約 6,000 リクエスト、カード不要)が付与されます。開発者審査はありません。
2. キーをコピー:ダッシュボードから X-API-Key を 1 つ取得。OAuth 4 鍵や Client ID/Secret は不要です。
3. リクエスト:X-API-Key をヘッダーに入れて /twitter/tweet/advanced_search を叩くと、構造化された JSON が返ります(本文・著者・エンゲージメント・投稿時刻など)。next_cursor を次のリクエストの cursor に渡せば分页しながら大量に取得できます。
75 種のエンドポイント(検索 / タイムライン / ユーザー情報 / フォロワー / 返信 / 引用 / リツイート / トレンド / 一般的な書き込み)があり、データ取得に必要な機能は advanced_search(検索)・user/last_tweets(タイムライン)・user/followers_ids(フォロワー)の 3 つでほとんどカバーできます。
大量データを一括取得する Python パイプライン
実運用で使う形に近い形に整えた Python の一括取得パイプラインを下に置きます(requests だけで動きます)。advanced_search を cursor で分页しながら最大 max_pages 件を集め、軽い retry とコスト試算を付けています。
ポイント:① キーは環境変数に置く、② max_pages で必ず上限を切る(クエリが広いと走り過ぎる)、③ バッチ並列は 30-50 req/秒に抑える(サーバ側の安全側保護に当てない)、④ レスポンスをすぐ JSONL / Parquet に書き出して中断耐性を持たせる。
スループット目安:単一プロセスで秒 20-30 リクエスト、1 リクエスト平均 20 件返れば毎秒 400-600 件、1 時間で約 100-200 万件レベルまでスケールできます(Volume × Cost は後述)。
リアルタイム取得は polling ではなく Webhook で受け取る
「特定キーワードのツイートを発生した瞬間に欲しい」用途は、/oapi/tweet_filter/add_rule でルールを登録してから自前の HTTPS エンドポイントにマッチしたツイートを push で受け取るのが正解です。advanced_search を秒数回ループする polling より、レイテンシも費用も圧倒的に効率的です。
ルールには Twitter 検索演算子がそのまま使えます: "YourBrand" OR @yourbrand lang:ja -is:retweet、#AI from:openai、url:github.com など。1 アカウントに複数ルールを登録できるため、ブランド監視 + 競合監視 + キーワード調査を 1 つの Webhook 受信で多重化できます。
受信側は HTTP 200 を返すだけ。ペイロードを Queue(SQS / Redis Streams 等)に押し込んで非同期に処理するパターンが安全です。
ボリューム別コスト試算(月 10K - 5M reads)
公式の従量課金(約 $0.005/read、2M reads/月キャップ)と TwitterAPI.io($0.00015/read、上限なし)を月間読み取り量で並べると次のとおり。
読み取りの全レンジでおおむね 33 倍の差、キャップ越え領域では Enterprise への強制ジャンプが入るためさらに大きくなります。データ取得が目的ならコストの逃げ場は明確です。
# Twitter (X) データを TwitterAPI.io で一括取得するパイプライン
# pip install requests
import os, time, json
import requests
API_KEY = os.environ["TWITTERAPI_KEY"] # 環境変数に置く(コードに直書きしない)
BASE = "https://api.twitterapi.io"
HEADERS = {"X-API-Key": API_KEY}
RATE_PER_CALL = 0.00015 # 約 $0.15 / 1,000 tweets
def _get(url, params, retries=3):
"""GET with simple exponential backoff."""
for attempt in range(retries):
try:
r = requests.get(url, headers=HEADERS, params=params, timeout=30)
r.raise_for_status()
return r.json()
except requests.RequestException:
if attempt == retries - 1:
raise
time.sleep(2 ** attempt)
def bulk_search(query: str, max_pages: int = 50, out_path: str = "tweets.jsonl"):
"""advanced_search を cursor で分页しながら最大 max_pages 件取得し、JSONL に追記する。"""
cursor = None
total = 0
with open(out_path, "a", encoding="utf-8") as f:
for page in range(max_pages):
params = {"query": query, "queryType": "Latest"}
if cursor:
params["cursor"] = cursor
data = _get(f"{BASE}/twitter/tweet/advanced_search", params)
tweets = data.get("tweets", [])
for t in tweets:
f.write(json.dumps(t, ensure_ascii=False) + "\n")
total += len(tweets)
print(f"page {page + 1}: +{len(tweets)} (total {total})")
cursor = data.get("next_cursor")
if not cursor:
break
time.sleep(0.04) # 30-50 req/秒に抑える
return total
if __name__ == "__main__":
q = '"AI エージェント" lang:ja -is:retweet'
n = bulk_search(q, max_pages=10)
cost = n * RATE_PER_CALL
print(f"取得: {n} ツイート / 試算コスト: ${cost:.4f}")
# 例) 200 ツイート -> $0.0300
# 100 万ツイート -> 約 $150(公式の従量課金だと約 $5,000)よくある質問
Twitter (X) からデータを取得する一番速い方法は?
第三者 API の TwitterAPI.io が登録から最初のレスポンスまで約 5 分と最速です。Google サインイン → ダッシュボードで X-API-Key を取得 → X-API-Key ヘッダー付きで /twitter/tweet/advanced_search を curl。OAuth 認証も開発者審査も不要なので、公式の 1-2 週間に対して圧倒的に短いです。
公式 X API ではデータをどれだけ取れますか?
2026 年時点では従量課金(read 1 件あたり約 $0.005)で、月間 2,000,000 reads のハードキャップがあります。100 万件読めば約 $5,000、キャップを超えるには Enterprise(月 ~$42,000+)に移行する以外ありません。中規模以上のデータ収集にはコスト面で厳しくなります。
Twitter のデータ取得は API なしでもできますか?(スクレイピング)
技術的には可能ですが現実的ではありません。snscrape / Playwright はコード上は無料でも、X 側の対スクレイピング対策で IP ブロックや captcha が頻発し、安定運用にはプロキシ群($50-500/月)が必要です。事実上の上限が 1,000 件/日ほどで、量を取りに行くほど運用負荷と凍結リスクが上がります。本記事の本旨は第三者 API のほうが事業として素直、という比較です。
リアルタイムでツイートを取得するには?
TwitterAPI.io の Webhook ルール(/oapi/tweet_filter/add_rule)に検索クエリを登録すれば、マッチしたツイートが自前 HTTPS エンドポイントに push されます。advanced_search を秒数回ループする polling より、レイテンシも費用も大幅に効率的で、ブランド監視や競合監視に向きます。
100 万件のツイートを取得すると費用はどれくらい?
TwitterAPI.io は約 $0.00015/read で、100 万件 = 約 $150。同じ量を公式 X API の従量課金($0.005/read)で読むと約 $5,000、約 33 倍の差です。200 万件を超えると公式はキャップに当たって Enterprise(月 ~$42,000+)に強制されるため、ボリュームが増えるほど差はさらに広がります。
TwitterAPI.io でできない・避けるべき操作はありますか?
DM 送信は提供していません——API 経由の DM は X の対自動化システムで凍結対象になりやすいためです。読み取り(検索・タイムライン・ユーザー情報・フォロワー)と一般的な書き込み(投稿・いいね・リツイート・フォロー)は対応しますが、書き込みは人間ペースに保ってください。
続けて読む
- X (Twitter) API 料金プラン完全ガイド →
- Twitter (X) API の使い方 →
- Twitter (X) API を「認証不要」で使う →
- twitterapi.io 料金・無料クレジット →
- API ドキュメント(エンドポイント一覧)→