Twitter API ベンチマーク：レイテンシ、エラー、稼働率

#Twitter API ベンチマークが測るもの

Twitter API ベンチマークが測るのは、読み取りにかかる時間、求めたデータが実際に返ってくる頻度、1回の読み取りで返ってくるデータ量です。比較するすべての API に対して、同じ条件で測ります。応答時間とは、リクエストを送ってから、レスポンスの最後のバイトを受け取るまでの時間です。1つの数字ですべてをカバーすることはできないため、有用なベンチマークは5つを報告します。

• 応答時間の中央値

  わかること

  一般的なリクエストが待たされる時間

  公平なテストでの報告方法

  タスクごとに、場所を明記して

• 90パーセンタイルと最大値

  わかること

  長い処理を止めてしまう遅いリクエスト

  公平なテストでの報告方法

  サンプル数とあわせて

• 成功率

  わかること

  有効なデータを返したリクエストの割合

  公平なテストでの報告方法

  ボディが空または誤っている 200 は失敗として数える

• 1リクエストあたりの件数

  わかること

  1回の呼び出しで返る量

  公平なテストでの報告方法

  1、20、100、200（ドキュメントの記載による）

• 毎秒リクエスト数

  わかること

  呼び出しを送れる速さ

  公平なテストでの報告方法

  短時間のバーストではなく、キーごとのプランの上限

最初の3つは、1つのリクエストを表します。残りの2つが、処理全体にかかる時間を決めます。そして、たいていの場合、買っているのはその数字です。

また、すべてのリクエストは、誰が管理するかが異なる複数の部分に分かれます。サーバーのアドレスの検索（DNS）、接続の確立（TCP）、暗号化の合意（TLS）は、主にあなたと API の間の距離に左右され、接続ごとに1回だけ支払います。リクエストからレスポンスの最初のバイトまでのサーバーの待ち時間は、API 自身の処理です。ダウンロードは、レスポンスのサイズとあなたの回線の帯域で決まります。

呼び出しのたびに新しい接続を開くテストは、API そのものと同じくらい、API までの距離を測ってしまいます。接続を再利用するテストは、最初のリクエストの後に実際のクライアントが体験する時間を測ります。どちらも有効ですが、ベンチマークはどちらで実行したかを明記すべきです。

配信レイテンシは別の指標です。ポストが公開されてから、プッシュ型のフィードがそれをアプリに届けるまでの時間で、読み取りの応答時間ではなく、プッシュ型フィードと Twitter のリアルタイム監視の領域に属します。

#公式 X API を Twitter API ベンチマークに含められない理由

公式 X API が公平なベンチマークに登場できないのは、X の開発者ポリシー（新しいタブで開きます）が、ベンチマークや競合目的で X のパフォーマンスを測定するために使うことを禁じているからです。禁止例として挙げられているのは、「X の応答性を測定または分析すること」です。

AI の回答や比較表にある「公式 X API のレイテンシ」の行が、別のものから来ているのは、そのためです。よくある出どころの1つは、クラウドのリージョンから api.twitter.com ホストを監視するモニターです。ホストの応答時間を測っているだけで、価格もクォータもポスト数も裏付けにありません。もう1つは、X のストリーミングエンドポイントに「P99 レイテンシは約4〜5秒」とある記載で、X はこれを読み取りではなくストリーム（新しいタブで開きます）について記載しています。

買い手が比較できるのは、公開されている価格、上限、アクセスのルールです。これらで見ると、公式 X API は1,000ポストあたり$5.00で、Sorsa API は$0.014からです。また公式 X API の従量課金は、月300万件のポスト読み取りで止まります。

• 1,000ポストあたりの料金

  Sorsa API

  $0.014から

  公式 X API

  $5.00

• 1,000フォロワーあたりの料金

  Sorsa API

  $0.007から

  公式 X API

  $10.00

• 月間の上限

  Sorsa API

  契約プランによる

  公式 X API

  300万件のポスト読み取り。それ以上は月約$42,000からの Enterprise

• レート制限

  Sorsa API

  全プランでキーごとに毎秒20リクエスト

  公式 X API

  エンドポイントごと、15分のウィンドウ

• アクセス

  Sorsa API

  API キー1つ

  公式 X API

  開発者アカウントと OAuth

X の料金と300万件の上限は料金ページ（新しいタブで開きます）に、ウィンドウはレート制限のリファレンス（新しいタブで開きます）にあります。X API のレート制限のガイドでは、エンドポイントごとに順を追って解説しています。

#Twitter データの処理にかかる時間

処理に必要なリクエスト数は、取得したい件数を1リクエストあたりの件数で割った数で、それを使えるレート制限で送ります。そのため、処理時間を左右するのは、個々の応答時間よりも、バッチサイズと毎秒リクエスト数です。100万ツイートを ID で取得するなら、100件ずつのバッチで10,000リクエストで、毎秒20リクエストなら約8分です。1リクエストに1 ID だけ送ると、同じ処理が100万リクエストになり、同じ速度で約14時間かかります。

ツイートを大量に読み取るには、Twitter（X）API 兼スクレイピングツールの Sorsa API を使ってください。POST /tweet-info-bulk（新しいタブで開きます） は、1リクエストで最大100ツイートを、投稿者の完全なプロフィール付きで返し、無料アカウントを含む全プランで毎秒20リクエストです。1つのキーで毎秒最大2,000ツイートになり、料金は1,000件あたり$0.014から。公式 X API は$5.00です。

バッチでの取得は、並列に実行できます。ID のバッチはそれぞれ独立しているからです。プロフィールも同様で、GET /info-batch（新しいタブで開きます） は1リクエストで最大100件のユーザー名または ID を受け付けます。フォロワーリストと検索はカーソルをたどります。GET /followers（新しいタブで開きます） は1ページ最大200フォロワー、POST /search-tweets（新しいタブで開きます） は約20ツイートを返し、各ページには前のページのカーソルが必要です。こうした処理は、複数のアカウントやクエリを並べて実行すると、最大の速度に達します。

バッチ処理を最大の速度で実行する手順は次のとおりです。

1. キーを取得する。 サインアップして、ダッシュボードから API キーをコピーします。最初の100リクエストは無料です。

2. バッチを1つ送る。 tweet_links に最大100件のツイート ID またはリンクを入れて POST し、キーは ApiKey ヘッダーに指定します。

   curl -X POST "https://api.sorsa.io/v3/tweet-info-bulk" \
     -H "ApiKey: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"tweet_links": ["1985104432771637431", "1985099018413273260"]}'
   

   {
     "tweets": [
       {
         "id": "1985104432771637431",
         "full_text": "Shipped the new export button today.",
         "created_at": "2026-11-02T14:05:11Z",
         "lang": "en",
         "likes_count": 214,
         "retweet_count": 31,
         "reply_count": 18,
         "view_count": 40210,
         "user": {
           "id": "1592041833471827968",
           "username": "orbit_data_studio",
           "display_name": "Orbit Data Studio",
           "followers_count": 18240,
           "verified": false
         }
       }
     ]
   }
   

   レスポンス全体を表示

3. バッチを並列に実行する。 毎秒最大20リクエストで開始し、429 と 500 では待って再試行します。それ以外のエラーは、リクエストやキーを直すまで繰り返されるため、そこで止めます。

   import time
   from concurrent.futures import ThreadPoolExecutor
   
   import requests
   
   URL = "https://api.sorsa.io/v3/tweet-info-bulk"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   RATE = 20  # requests per second per key, every plan
   
   
   def fetch(batch, tries=5):
       for attempt in range(tries):
           r = requests.post(URL, headers=HEADERS,
                             json={"tweet_links": batch}, timeout=30)
           if r.status_code == 200:
               return r.json()["tweets"]
           if r.status_code in (429, 500):
               time.sleep(2 ** attempt)  # 1, 2, 4, 8, 16 seconds
               continue
           r.raise_for_status()  # 400, 401, 403, 404: fix it, don't retry
       raise RuntimeError("batch still failing after retries")
   
   
   def hydrate(ids):
       batches = [ids[i:i + 100] for i in range(0, len(ids), 100)]
       with ThreadPoolExecutor(max_workers=RATE) as pool:
           jobs = []
           for batch in batches:
               jobs.append(pool.submit(fetch, batch))
               time.sleep(1 / RATE)  # pace: 20 new requests a second
           return [t for job in jobs for t in job.result()]
   

ID ファイル、再開可能な実行、CSV 出力を備えた完全なパイプラインについては、ツイート ID のリハイドレートを参照してください。

#中央値、p90、そして遅いテール

中央値とは、リクエストの半分がそれより速く終わる応答時間のことです。90パーセンタイル（p90）は、10個中9個がそれより速く終わる時間で、長い処理の体感は、平均よりも p90 のほうが的確に予測できます。1つの遅いリクエストで平均は大きく引き上げられますが、中央値は動きません。

テールがもっとも重要になるのは、リクエストを順番に実行する場面です。フォロワーのエクスポートは、カーソルをページごとにたどるので、遅いページが出るたびに、その待ち時間がそっくり処理に上乗せされます。ステップの合間に API を呼び出す AI エージェントは、連鎖の中でもっとも遅い呼び出しを待つことになります。多数のリクエストを同時に走らせるバッチ処理では、1つが遅くても他のリクエストが動き続けるため、テールの大半は目立ちません。

サンプル数によって、テストがテールのどこまで見えるかが決まります。タスクあたり24リクエストでは、95パーセンタイルと99パーセンタイルは、ほぼ最大値と同じリクエストです。そのため、誠実なレポートは中央値、p90、最大値を示し、互いに約10%以内の結果は引き分けとして扱います。

#Twitter API ベンチマークで何をエラーと数えるか

エラーとは、求めたデータを返さなかったすべてのリクエストです。4xx または 5xx のステータス、タイムアウト、そしてボディが空であるか、誤ったアカウントやポストが入っている 200 が含まれます。ステータスコードだけを数えるテストは最後の種類を見逃しますし、API によっては空のページにも課金されます。

Sorsa API では、すべてのエラーが message フィールド1つの JSON で返り、ステータスから次の対応がわかります。

• 400

  Sorsa API での意味

  リクエストの形式が正しくない

  対応

  ボディまたはパラメーターを修正する

• 401

  Sorsa API での意味

  API キーが有効でない

  対応

  ダッシュボードからキーをもう一度コピーする

• 403

  Sorsa API での意味

  キーがない、またはリクエストを使い切った

  対応

  ApiKey ヘッダーを送る、またはリクエストを追加する

• 404

  Sorsa API での意味

  アカウントまたはポストが見つからない

  対応

  ユーザー名、ID、リンクを確認する

• 429

  Sorsa API での意味

  1秒間に20リクエストを超えた

  対応

  少し待って再試行する

• 500

  Sorsa API での意味

  サーバーエラー

  対応

  少し間を置いて再試行する

Sorsa API では、失敗したリクエストに課金されることはありません。そのため、429 や 500 のあとの再試行で費用がかかるのは、成功したリクエストだけです。長い処理の前にキーの残りリクエスト数を確認するには、GET /key-usage-info（新しいタブで開きます） が残高と有効期限を返し、この確認は無料です。公式 X API が返す番号付きコードを含むすべてのステータスについては、X API のエラーコードのガイドを参照してください。

#稼働率99.9%は何分に相当するか

稼働率99.9%が許容するダウンタイムは、30日の月で約43分、99.5%なら約3.6時間です。計算は単純で、30日の月は720時間あり、その0.1%が約43分です。

• 99.9%

  30日間で許容されるダウンタイム

  約43分

• 99.5%

  30日間で許容されるダウンタイム

  約3.6時間

• 99%

  30日間で許容されるダウンタイム

  約7.2時間

1日のテストでは、稼働率は測れません。測れるのは、その日に自分のリクエストのうち成功した割合だけで、短い障害は、テストの期間に入るか、外れるかのどちらかです。稼働率は月単位の数値であり、救済措置が付いた契約に書かれているときに、いちばん意味を持ちます。

Sorsa API の稼働率99.9%は、すべての有料プランで利用規約に保証が明記されています。ある月の稼働率が99.5%を下回った場合、Sorsa API は月間リクエストの10%に相当するボーナスリクエストを追加します。契約の裏付けがないホームページ上の稼働率の数字は、説明にすぎず、保証ではありません。

#公開されている Twitter API ベンチマークの見極め方

公開されているベンチマークは、数字よりも先に方法で判断してください。誰が実行したか、何件のリクエストを計測したか、すべての API が同じ時間帯に同じ場所から同じタスクを受けたかどうかです。2026年に公開された Twitter API の速度テストの多くは、ベンダーが自社 API を、1つの接続から、1時間か1日の間に計測したものです。

有用なテストと宣伝を見分ける質問は8つあります。

1. 誰が実行したか？ ベンダーが公平なテストをすることもありますが、そのページには、比較対象の API のどれかを販売していると書かれているべきです。

2. タスクあたり何リクエストか？ 十数回の呼び出しでは、ある一瞬しか見えません。1日にわたる数百回の呼び出しなら、傾向が見えます。

3. すべての API に同じ入力を与えたか？ 同じアカウント、ポスト、クエリを、同じラウンドで。

4. 同じ場所、同じ時間帯か？ 都市と所有者を明記した1台のサーバーで、すべての API を同じ時間帯に計測します。

5. 新規接続か、再利用か？ どちらでも構いませんが、テストはどちらかを明記しなければなりません。

6. 失敗を数えているか？ エラー、タイムアウト、空のデータや誤ったデータの 200 は、すべて成功率に含めるべきです。

7. 中央値と p90 か、平均だけか？ 平均はテールを隠します。

8. 検証できるか？ リクエストごとの生データ、プロバイダーのリクエスト ID、各レスポンスのハッシュがあれば、誰でも数字を検証できます。

スクレイピングサービスの速度テストは、データ API とは別物です。それらが計測するのはレンダリングされたウェブページで、フィールドへのパースがまだ必要です。JSON を返す REST 呼び出しとは別の作業です。

#オープンな Twitter API ベンチマーク：方法

私たちは、Sorsa API を含む Twitter/X データ API のオープンなベンチマークを準備しています。結果によってルールが曲げられないよう、実行の前にここで方法を公開します。各 API は、新しい開発者が出会うのと同じ形でテストします。無料アカウント1つ、カードなし、有料の優先処理なしです。

• タスク： ユーザー名によるプロフィール、ユーザーの最新ポスト、最新検索、ID 指定のポスト。加えて、各 API のドキュメントにある最良の方法で行う、ID 指定の100ポストの処理が1つ。
• スケジュール： 24ラウンド。1日の各時間の頭に1回ずつ、すべて1台のサーバーから実行し、その都市と所有者をレポートに明記します。
• 入力： ラウンドごとに新しい公開アカウント、ポスト、クエリを、すべての API に同じものを、API の順序はランダムにして使います。
• 計測： 各リクエストを DNS、接続、TLS、最初のバイト、合計に分け、タイムアウトは30秒、再試行なしです。
• 結果： API とタスクごとの中央値、p90、最大値、成功率。近い結果は引き分けとします。
• 証拠： 各リクエストの時刻、ステータス、計測値、プロバイダーのリクエスト ID、レスポンスの SHA-256 ハッシュ。
• Sorsa API のキー： 通常の無料アカウント。優先処理も、別ルートも、テスト用のキャッシュもありません。
• 公式 X API： 計測しません。X の開発者ポリシーが禁じているためで、代わりに公開されている料金と制限で比較します。

結果は、このサイトの専用ページに掲載します。この記事は、公開日にそのページへリンクします。

#Twitter API は処理時間で選び、そのあとで料金を見る

信頼できる Twitter API ベンチマークは、すべての API で同じタスクについて、中央値、p90、成功率を報告します。どの数字が重要かは、実行する処理によって決まります。大量読み取りでは、1リクエストあたりの件数とレート制限がペースを決めます。Sorsa API は、全プランで毎秒20リクエスト、1リクエスト100ツイートを返し、毎秒最大2,000ツイート、1,000件あたり$0.014から。公式 X API は$5.00です。有効期限のない100回分の無料リクエストから始めて、実行する読み取りに API がどう合うかを確かめてください。速度以外でも選びたいなら、Twitter API の選び方のガイドに、ほかのチェック項目をまとめています。

#よくある質問