【2026年版】X（Twitter）API の投稿制限：1日あたりのツイート数

Q: ツイート削除の X API レート制限は？

DELETE /2/tweets/:id を通じたツイートの削除は、ユーザーあたり15分ごとに50リクエストに上限が設けられ、バッチ削除のエンドポイントはありません。そのペースでは、1,000ツイートをクリアするのに、20の窓にわたって実時間でおよそ5時間かかります。大きなクリーンアップのジョブは、より速くリトライするのではなく、バッチ間に待機状態を組み込むことで成功します。その一時停止は設計どおりに働く API だからです。

Q: X API を通じてリンク付きのツイートを投稿できて、いくらかかる？

はい、ただし URL を含む投稿は、2026年4月20日の価格改定時点で従量課金で各 $0.20 で課金され、プレーンテキストの投稿の $0.015 に対して13倍を超えるコストです。ニュースレターのリンク、ブログ投稿、またはアフィリエイト URL を量で自動公開するワークフローは速く高価になるため、URL のプレミアムは、リンクの多い投稿の自動化を出荷する前に、どのコストモデルにも属します。

著者：Sorsa Editorial

2026年7月11日更新：確認された未認証アカウントの上限（X の制限ページで2026年5月中旬以降、1日あたり50件のオリジナル投稿と200件の返信）を記載し、未公開の Premium の1日あたりの数字を削除し、ペース配分の制限を X の文書化された30分ごとのサブ制限として捉え直しました。

要点： X API の書き込みエンドポイントは、ユーザーあたり15分ごとに100投稿、アプリあたり24時間ごとに10,000投稿を許可します。それとは別に、X アカウントは API と手動の投稿を合わせて数えるプラットフォーム全体の上限を持ちます。2026年5月以降、未認証アカウントは1日あたり50件のオリジナル投稿と200件の返信で、このアカウント上限がほとんどの自動化を最初に止めます。

2026年に X API を通じて投稿すると、1つではなく3つの別々の天井にぶつかり、それらは独立に強制されます。API エンドポイントには自身のアプリ単位・ユーザー単位のレート制限があります。投稿元の X（旧Twitter）アカウントには、投稿がスクリプトから来ようとモバイルアプリから来ようと適用されるプラットフォーム全体の1日あたりの上限があります。そして従量課金では、作成されるすべての投稿が課金され、同じアカウントの読み取り側には月間200万投稿読み取りのハードキャップが座っています。3つのどれもがエラーを返し得て、それが、「私のコードはレート制限に全然近くない」が、X を自動化する開発者からの最もよくある、そして最も紛らわしい不満の1つである理由です。

本ガイドは、X 自身のドキュメントに対して確認した現行の数字とともに、3つの層すべてを扱います。当社は公開の X データを読むための代替の Twitter/X API である Sorsa API をビルドして運用しているため、投稿そのものは Sorsa の担当領域ではありません。書き込みは公式 API に属し、これらはそこで付き合う制限です。力になれるのは、ほとんどの投稿ワークフローのもう半分、読み取りの部分です。投稿が公開されたことの確認、そのエンゲージメントの取得、または公開後のメンションの監視で、以下のセクションが関連するところでそれを示します。ここの投稿の数字は、公式 X API が現在与えるものです。

最終確認：2026年7月6日、X の公式のレート制限とアカウント制限のドキュメントに対して。

X API の投稿制限の仕組み
X API で1日あたり何ツイート投稿できる？
返信、削除、ダイレクトメッセージのレート制限
いいね、フォロー、リポストは？
X API の無料枠は2026年に投稿を許可する？
ほとんどの自動化を止める30分ごとのペース配分
投稿制限に当たったとき何が起こるか
制限を引っかけずに規模で投稿する方法
よくある質問

X API の投稿制限の仕組み {#how-x-api-posting-limits-work}

X は2026年に、投稿を3つの独立した層で強制します。書き込みエンドポイントの API レート制限、X アカウント自身のアカウントレベルの1日あたりの上限、そして作成されるすべての投稿を計測する従量課金の課金です。リクエストはそのどれに対しても失敗し得て、それぞれが異なるシグナルを返します。

最初の層は API レート制限です。書き込みエンドポイント（POST /2/tweets）は、ユーザーあたり15分ごとに100投稿、アプリあたり24時間ごとに10,000投稿を許可します。これらは、固定の時刻からではなく最初のリクエストから始まるローリングウィンドウで、1つを破ると HTTP 429 を返します。

2番目の層はアカウント上限です。すべての X アカウントは、ウェブ、モバイル、API を合わせて適用されるプラットフォーム全体の投稿制限に縛られます。X 自身の制限ドキュメントは、これらの1日あたりの上限が「ウェブ、モバイル、電話、API を含むすべてのデバイスから」のアクションを数えると明記しているため、自動化された投稿と手打ちの投稿は同じ1日あたりの予算から引かれます。これはほとんどのガイドが見落とす層で、実際にボットを止めるのはたいていこれです。

3番目の層は課金です。X が2026年2月に従量課金に移って以来、作成される各投稿はお金がかかり（プレーンな投稿で$0.015、2026年4月20日の価格改定時点で URL を含む投稿で$0.20）、アカウントは読み取り側に月間200万投稿読み取りの別のハードキャップを持ちます。投稿のレート制限の内側に快適に収まりながら、なお読み取りでブロックされることもあれば、リンクの多い公開ワークフローが速く高価になるのを見ることもあります。URL のプレミアムと重複排除の窓を含む完全なアクション単位のコスト像は、2026年版 X API 料金の内訳にあります。

実用的な要点：API レート制限が投稿の拘束的な制約であることはめったにありません。ほとんど常にアカウント上限がそうです。

X API で1日あたり何ツイート投稿できる？ {#how-many-tweets-can-you-post-per-day-via-the-x-api}

API だけを通じて、1人の認証済みユーザーは15分ごとに最大100ツイートを投稿でき、1つのアプリは全ユーザー合わせて24時間ごとに最大10,000を投稿できます。しかしそれらの投稿が来る X アカウントは、プラットフォームレベルで別に上限が設けられ、そのアカウント上限は API の天井より低く、たいてい自動化を止めるものです。

2つの層が1つのアカウントでどう積み重なるかは次のとおりです。

層	制限	窓	適用先
API ユーザー単位（`POST /2/tweets`）	100投稿	15分	各認証済みユーザートークン
API アプリ単位（`POST /2/tweets`）	10,000投稿	24時間	アプリ全体、全ユーザー合算
アカウント上限、未認証	50投稿 + 200返信	24時間	X アカウント、API と手動を合算
アカウントのペース配分サブ制限	未公開	30分ごと	X アカウント、任意のソース

2026年5月中旬以降、X 自身の制限ページは未認証アカウントを1日あたり50件のオリジナル投稿と200件の返信に制限し、これは長年の2,400からの急な削減で、その1日あたりの予算を、X が間隔の数字を公開しない30分ごとのサブ制限に分割します。リポストと引用投稿は50にカウントされると広く報告されていますが、X はそれをはっきりとは確認しておらず、ヘルプページはところどころで依然として古い2,400の数字に言及しており、それが、矛盾する数字がガイド全体で出回る理由です。認証済み（Premium）アカウントはこれらの公開された上限を免除されます。X はそれらに対する数字を述べていないため、Premium アカウントでは上の API 書き込み制限が実用的な天井になります。

罠は API 制限を中心に設計することです。開発者は「15分ごとに100投稿」（ユーザーあたり1日ほぼ9,600）を読んでそれ向けにビルドし、するとボットは、アカウントレベルの上限とその30分ごとのペース配分が先に拘束するため、はるかに早く止まります。自動化を動かす未認証アカウントには、1日50投稿が実際の天井で、API の窓ではありません。

この層状の挙動は読み取り側にも現れ、そこでは15分の窓とアプリ単位対ユーザー単位のプールが、ほとんどの収集パイプラインの429 を引き起こします。それらの読み取り制限は、コンパニオンの X API レート制限リファレンスでエンドポイントごとに扱っています。

返信、削除、ダイレクトメッセージのレート制限 {#rate-limits-for-replies-deletes-and-direct-messages}

トップレベルのツイートの投稿、返信の投稿、ツイートの削除、そしてダイレクトメッセージの送信は、それぞれ X API 上で別々の書き込み制限の下で動きます。返信はオリジナル投稿と同じ POST /2/tweets エンドポイントと制限を使いますが、削除と DM の送信はより厳しく、自身の窓によって統治されます。

アクション	エンドポイント	ユーザー単位	アプリ単位	窓
ツイートまたは返信の投稿	`POST /2/tweets`	100	10,000	15分（ユーザー）、24時間（アプリ）
ツイートの削除	`DELETE /2/tweets/:id`	50	非対応	15分
ダイレクトメッセージの送信	`POST /2/dm_conversations/.../messages`	15/15分 + 1,440/24時間	1,440	15分と24時間
ダイレクトメッセージの読み取り	`GET /2/dm_events`	15	非対応	15分

削除は、クリーンアップのジョブを動かす人々を驚かせるものです。ユーザーあたり15分ごとに50削除では、1,000件の古いツイートをクリアするのに、20の窓にわたってペース配分され、実時間でおよそ5時間かかり、それを速めるバッチ削除のエンドポイントはありません。大きなタイムラインを一掃するツールは、より速くリトライすることではなく、待機状態を設計に組み込むことで成功します。

返信は API 制限の上に自身のアカウントレベルの上限を持ちます。未認証アカウントには、X の制限ページがその返信の上限を1日あたり200に設定し、50件のオリジナル投稿の予算とは別なので、メンションに答えるボットは、オリジナル投稿の予算が手つかずのまま返信の枠を使い果たし得ます。

ダイレクトメッセージは意図的に遅いです。ユーザーあたり15分ごとに15送信に24時間あたり1,440の天井、そして1アカウントあたり1日約500 DM と広く引用されるプラットフォームレベルの上限では、自動化されたメッセージングは設計上すぐに壁に当たります。これらの書き込みアクションのどれにも読み取り専用の相当物はありません。たとえば DM 履歴の読み取りも15分ごとに15リクエストにゲートされているため、DM の多いワークフローは両端で制約されます。

いいね、フォロー、リポストは？ {#what-about-likes-follows-and-reposts}

アカウントのフォロー、投稿へのいいね、引用投稿は、2026年にアクセス層が変わりました。2026年4月20日から、X はこれらのエンゲージメントの書き込みアクションをセルフサーブの従量課金から外し、Enterprise 限定にしたため、プログラムでいいね・フォロー・引用投稿する自動化は、今は標準の開発者アプリではなく Enterprise 契約を必要とします。投稿とダイレクトメッセージは従量課金に留まりました。

その変更の前、これらのアクションの公開された API 制限は厳しいものでした。いいねとフォローはユーザーあたり15分ごとにおよそ50で動き、追加の24時間の天井があり、リポストは同様のペースでした。それらの数字はセルフサーブのユーザーには今や意味をなしません。エンドポイントが完全に Enterprise アクセスの背後にゲートされているからです。

アカウントレベルでは、フォローは投稿とは別に上限が設けられたままです。未認証アカウントは1日あたり約400フォロー、Premium アカウントはおよそ1,000と広く報告されており、X はフォロー・アンフォローの循環パターンを見張っていて、1日の数が破られていなくても制限を引っかけます。いいねには公に文書化されたアカウント制限はありませんが、攻撃的な自動いいねは確実に挙動のスロットリングを引き起こします。

ワークフローがプログラムによるエンゲージメントの書き込みに依存するなら、公式 API の Enterprise 層が準拠する経路で、書き込みアクションに読み取り専用の代替はありません。読み取り API がカバーするのは測定の側です。いいねやフォローの代わりに、誰がエンゲージしたかを読みます。キャンペーンのツイートをリポストまたは返信したアカウントの取得は読み取り操作で、リポスト者と返信者の照会のようなエンドポイントで扱われ、それがそのデータ収集を、いかなるユーザーアカウントからも完全に外します。

X API の無料枠は2026年に投稿を許可する？ {#does-the-x-api-free-tier-let-you-post-in-2026}

2026年に新規開発者向けの一般的な無料の X API 層はありません。X は従量課金が2026年2月に始まったとき単体の無料枠を廃止したため、新規アカウントは1ツイートを投稿する前にクレジットを買わなければなりません。2026年に X API がそもそも無料かには、新規登録には1つの答えがあります。無料ではありません。

まだレガシーの無料枠のアプリを持っている人には、投稿の枠は設計上つねに最小限でした。レガシーの無料枠は書き込み専用で24時間の窓で計測され、文書化された POST /2/tweets の枠はアプリ全体で共有される24時間あたり17リクエストでした（一部の情報源は、古い v1.1 の経路に適用されたより高い月次の数字を引用しており、それがガイド全体で見る17対50の混乱の元です）。いずれにせよ、それは投稿の連携をテストするためのスタブで、決して量で運用するためのものではなく、投稿読み取りアクセスをゼロ付与しました。

つまり無料枠は規模での投稿を決してサポートせず、新規開発者にはもう存在しません。実際にテストする必要があるのが投稿ではなく X データの読み取りなら、サードパーティのアクセスが実用的な無料の経路です。すべての新規 Sorsa アカウントは、1回限り・クレジットカード不要・有効期限なしの100回分の無料リクエストで始まります。それらは、有料プランと同じフラットレートで40個すべての読み取りエンドポイントをカバーし、バッチエンドポイントを通じては、何かを支払う前に最大10,000ツイートまたは20,000プロフィールに十分です。それは読み取りの連携を検証する実際のワークロードで、ほとんどのプロバイダーが配る小さな試用クレジットをはるかに超えます。

ほとんどの自動化を止める30分ごとのペース配分 {#the-semi-hourly-pacing-that-stops-most-automations}

最も多くの投稿の自動化を捕まえる制限は、見出しの1日あたりの数字だけではありません。X は各アカウントの1日あたりの投稿予算を、より小さな30分ごとのサブ制限に分割し、それを1日あたりの上限の上にアカウントレベルで、API レート制限とは独立に強制し、間隔の数字を公開しません。ライブツイートする人、スレッドを流す人、返信ボットは、このペース配分を絶えず、ときには1日の天井が視野に入る前に引っかけます。

とても引っかけやすい理由は、予算が小さく共有されているからです。未認証アカウントには1日あたり50件のオリジナル投稿と200件の返信で、リポストと引用投稿は同じプールから引くと広く報告されており、すべてがサブ間隔でペース配分されます。メンションの急増に答えるボットや、きついループでツイートごとに投稿されるスレッドは、1分未満で1つの間隔の枠を使い果たし、それからリセットまで止まり得ます。

その上に層をなす、2つ目の、より静かなブロッカーがあります。重複検出です。X は、およそ24〜48時間の範囲内に公開された同一またはほぼ同一のテキストの投稿を拒否し、エラーコード187 を返します。同じメッセージを再利用する自動化は、常緑の投稿や複数アカウントのセットアップでよくあるもので、どのレート制限にも全然近くないときでもこれを引っかけます。修正は些細で、1文字か句読点1つを変えるだけで重複チェックをクリアしますが、それはワークフローに組み込まれていなければなりません。

書き込みをペース配分する実用的なルール：1日あたりの上限に対してバーストするのではなく、投稿を1日にわたって広げます。返信とスレッドのセグメントを、間に意図的な間隔を置いて10〜15のバッチでキューに入れ、再利用するテキストを変えます。1日あたりの数字だけに合わせて設計するのは、まさに自動化が実行の途中で止まる原因です。

投稿制限に当たったとき何が起こるか {#what-happens-when-you-hit-a-posting-limit}

API レート制限を超えると、X はエラーコード88 とともに HTTP 429 を返します。

json

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

レスポンスは依然としてレート制限ヘッダーを運び、それが重要な部分です。x-rate-limit-reset は窓が再び開くときの Unix タイムスタンプなので、書き込みワーカーは固定の間隔を盲目的にスリープする必要は決してありません。アカウントレベルの上限の突破と重複の拒否は異なって現れます。アカウント上限は429 ではなく403 か投稿制限の通知を返す傾向があり、重複はエラー187 を返すため、よく作られた投稿ツールは、すべての失敗をレート制限として扱うのではなく、3つを区別します。

書き込みの経路のためのリセットを意識したリトライはこう見えます。

python

import time
import requests

def post_tweet_with_retry(text, headers, max_retries=3):
    url = "https://api.x.com/2/tweets"
    for attempt in range(max_retries):
        response = requests.post(url, headers=headers, json={"text": text})

        if response.status_code != 429:
            return response

        reset = int(response.headers.get("x-rate-limit-reset", 0))
        wait_seconds = max(reset - int(time.time()), 1)
        print(f"Rate limited. Waiting {wait_seconds}s until the window resets.")
        time.sleep(wait_seconds + 1)  # +1s buffer

    raise Exception("Rate limit retries exhausted")

注意すべきことが2つあります。第一に、429 で即座にリトライしないでください。きついリトライループは、アプリ専用の認証で他のエンドポイントにまたがる残りの予算を燃やすからです。第二に、各書き込みの前に x-rate-limit-remaining を確認し、それが1桁に落ちたら、ハードストップを待つのではなく減速します。バルクの投稿や削除のループでは、1つの未処理の429 が、コードが気づく前に一連の失敗にカスケードし得ます。

制限を引っかけずに規模で投稿する方法 {#how-to-post-at-scale-without-tripping-limits}

X API を通じて実際の投稿量を通すのは、1日あたりの天井についてというより、30分の窓とアカウント上限の下でのペース配分についてです。これらが実際に結果を変える手です。

1日あたりの上限だけでなく、30分ごとのサブ制限にペースを合わせる。 X は1日あたりの予算を、未公開の数字を持つ30分ごとの間隔に分割するため、バーストする代わりに、返信とスレッドのセグメントを10〜15のグループに間隔を置いてまとめます。このペース配分が、ほぼすべての自動化にとって最初に拘束するものです。
大量の公開には認証済み（Premium）アカウントを使う。 1日50投稿と200返信の上限は未認証アカウントにのみ適用されます。X の制限ページは認証済みアカウントを免除し、それらに対する数字を公開しないため、API 書き込み制限が実際の境界になります。
重複検出をクリアするために再利用するテキストを変える。 エラー187 は24〜48時間の範囲内のほぼ同一の投稿を拒否します。常緑または複数アカウントの投稿では、言い回しを回すか、ユニークな要素を付け加えます。
コストモデルの中で URL のプレミアムを見張る。 リンクを含む投稿は、プレーンな投稿の$0.015に対して$0.20で課金され、13倍を超えるコストなので、リンクの多い公開ワークフローは速く実際のお金にぶつかり得ます。その跳ね上がりの背後の計算は、なぜ X API はこれほど高くなるのかの考察にあります。
書き込みのキューを読み取りのキューから分ける。 投稿と読み取りは異なる制限から、そして従量課金では異なる上限から引きます（月間200万投稿読み取りの上限は、いかなる書き込み予算とも別です）。キューを独立に保つことは、読み取りのバックログがスケジュールされた投稿をブロックできず、その逆もできないことを意味します。

その最後の点が、ほとんどの本番の投稿セットアップが2つのプロバイダーに分かれる先で、それが下の実用的なパターンにまっすぐつながります。

投稿対読み取り：どの仕事にどの API か {#posting-versus-reading-which-api-for-which-job}

ほとんどの実際の X ワークフローは両方を行い、その2つの半分は2026年に異なるインフラに属します。X への書き込み（投稿、返信、DM の送信）は、上の制限の下で、ユーザー認証されたトークンで公式 API 上で動かなければならないファーストパーティのアクションです。X を量で読むこと（投稿が公開されたことの確認、そのエンゲージメントの取得、メンションの監視、タイムラインの収集）は、公式のリソース単位の料金とエンドポイント別の窓が高価で厄介になるところで、フラットレートの読み取り API がよりきれいに合うところです。

自動化された投稿、返信、DM： 公式 X API、従量課金または Enterprise で。書き込みに準拠する読み取り専用の代替はありません。
プログラムによるいいね、フォロー、引用投稿： 公式 X API の Enterprise 層で。これらは2026年4月20日にセルフサーブを離れたためです。
投稿が公開されたことの確認、エンゲージメントの取得、メンションの監視、バルクの読み取り： Sorsa のような読み取りに焦点を当てた代替で、エンドポイント別の窓なしの一律の毎秒20リクエストで、バッチベースで1,000ツイートあたり$0.02からの読み取りです。

正直な分割ははっきり述べる価値があります。X に書き込む必要があるなら、それは公式 API の領分で、ここの何もそれを変えません。同じワークフローの読み取りの多い半分には、フラットで予測しやすい読み取り API が15分の窓とリソース単位の課金を取り除きます。読み取りだけを移すのはよくある最初のステップで、公式 API からの移行の経路が、書き込み側に触れずにそれを行うことを扱っています。

実践：投稿制限を受け続けたエージェンシー

クライアント向けにスケジュールされた投稿を動かすソーシャルエージェンシー（十数人ほど）が、説明できない投稿制限に当たり続けていました。同社のスケジューラーは API の「15分ごとに100」の数字を中心に設計されていましたが、クライアントのアカウントはキャンペーンの途中でロックされ続けました。原因はアカウント層でした。未認証のクライアントアカウントは、API 制限が問題になるずっと前にプラットフォームの1日あたりの上限とその30分ごとのペース配分に当たっており、リポストは静かに同じ予算にカウントされていました。

書き込みの修正は移行ではなく運用でした。大量のアカウントを Premium に移し、30分ごとのサブ制限の下で投稿をペース配分し、エラー187 を引っかけるのをやめるために再利用のコピーを変えました。書き込みの経路は、属する公式 API に留まりました。移ったのは読み取りの多いレポート層で、投稿が公開されたことの確認とクライアントのダッシュボード向けの投稿ごとのエンゲージメントの取得で、それが静かに月間200万読み取りの上限に向かって燃えていました。フラットなリクエスト単位の料金では、その読み取りの作業は公式のリソース単位のモデルより読み取りあたり最大50分の1のコストで動き、ペース配分が修正されると投稿制限が晴れる一方で、レポートの請求は月数百ドル台に落ちました。

よくある質問 {#faq}

2026年に X API で1日あたり何ツイート投稿できる？

X API の書き込みエンドポイントは、ユーザーあたり15分ごとに100投稿、アプリあたり24時間ごとに10,000投稿を許可します。拘束的な制限はたいていアカウント上限です。2026年5月以降、未認証アカウントは1日あたり50件のオリジナル投稿と200件の返信に、30分ごとのサブ制限でペース配分されて抑えられ、一方認証済み（Premium）アカウントはこれらの公開された上限を免除されます。

ツイート削除の X API レート制限は？

DELETE /2/tweets/:id を通じたツイートの削除は、ユーザーあたり15分ごとに50リクエストに上限が設けられ、バッチ削除のエンドポイントはありません。そのペースでは、1,000ツイートをクリアするのに、20の窓にわたって実時間でおよそ5時間かかります。大きなクリーンアップのジョブは、より速くリトライするのではなく、バッチ間に待機状態を組み込むことで成功します。その一時停止は設計どおりに働く API だからです。

X API を通じてリンク付きのツイートを投稿できて、いくらかかる？

はい、ただし URL を含む投稿は、2026年4月20日の価格改定時点で従量課金で各$0.20で課金され、プレーンテキストの投稿の$0.015に対して13倍を超えるコストです。ニュースレターのリンク、ブログ投稿、またはアフィリエイト URL を量で自動公開するワークフローは速く高価になるため、URL のプレミアムは、リンクの多い投稿の自動化を出荷する前に、どのコストモデルにも属します。

X API の無料枠は2026年に投稿を許可する？

新規開発者向けの一般的な無料枠は存在しません。X は従量課金が2026年2月に始まったときそれを廃止したため、新規アカウントは投稿の前にクレジットを買わなければなりません。レガシーの無料枠は書き込み専用で、アプリ全体で24時間あたり約17投稿しか許可せず、読み取りアクセスはゼロでした。代わりに読み取りをテストするには、Sorsa API がサインアップ時に100回分の無料リクエストを、クレジットカード不要で、40個のエンドポイントすべてをカバーして含みます。

投稿レート制限の下にいるのに、なぜ429 エラーが出る？

429 は API の窓が超えられたことを意味しますが、投稿の失敗はしばしば異なる層から来ます。アカウントレベルの1日あたりの上限（未認証アカウントには1日50件のオリジナル投稿と200件の返信）は API と手動の投稿を合わせて数え、たいてい API 制限の前に拘束し、通常は403 か制限の通知を返します。ほぼ同一の重複テキストはエラー187 を返します。すべての失敗をレート制限として扱うのではなく、3つを区別してください。

開発者はこれらの制限に当たらずにどう高い読み取りスループットを得る？

投稿は公式 API に留まりますが、読み取りの多い作業は、エンドポイント別の窓を避けるためにフラットレートの代替に移ります。たとえば Sorsa API は、40個すべての読み取りエンドポイントを、すべてのプランで毎秒20リクエストで、バッチベースで1,000ツイートあたり$0.02から、月額$49からのプランで提供します。読み取りの規模では、それは公式のリソース単位の料金より読み取りあたり最大50分の1のコストになります。

始め方 {#getting-started}

投稿ワークフローも X データを読まなければならない（投稿が公開されたことの確認、レポート用のエンゲージメントの取得、または公開後のメンションの監視）なら、その読み取り側こそ、公式のエンドポイント別の窓とリソース単位の課金が最も痛むところで、フラットレートの読み取り API がよりきれいに合うところです。違いを感じる最も速い方法は、自分でいくつかの呼び出しを実行することです。インタラクティブな API playground は、キーもサインアップもなしにブラウザで稼働中のエンドポイントを実行するため、まずレスポンスの形を確認できます。ビルドの準備ができたら、Sorsa API のクイックスタートが数分で1つの API キーで認証させ、すべての新規アカウントは100回分の無料リクエスト（1回限り・クレジットカード不要・有効期限なし、40個のエンドポイントすべて、最大10,000ツイートまたは20,000プロフィールに十分）を含み、フラットな料金プランはバッチベースで1,000ツイートあたり$0.02から、月額$49から、管理すべきエンドポイント別の窓なしの毎秒20リクエストで動きます。X への書き込みは公式 API に留まります。読み取りの半分はそうである必要はありません。

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

本ガイドのまとめ方：API の書き込みと削除の制限、429 のボディ、エンドポイントのパスは X の公式のレート制限の表から直接読み、アカウントレベルの投稿上限は X の制限ドキュメントから読み、両方とも2026年7月11日に再確認しました。これらの数字はさほど予告なく変わり、X 自身のヘルプページはところどころで依然として古い2,400の数字に言及しており、それが矛盾する1日あたりの上限の数字が出回る理由なので、ここに述べた50投稿と200返信の上限は現行の制限ページから取っています。投稿ペースと重複検出の戦術、429 の回復コード、そして3層の枠組みは、読み取りに焦点を当てた Twitter/X API を運用する当チーム自身の作業と、当チームが扱う読み取りパイプラインの移行、上の匿名化されたエージェンシーの事例（詳細は統合し、識別につながるものを取り除いています）から来ています。料金の数字は、Sorsa の別個の X API 料金のカバレッジから要約しています。だれが運営し、どう連絡するかは Sorsa についてをご覧ください。ここの統計、情報源、クライアントの成果はどれも捏造されていません。