Xの開発者プラットフォームは、現在サブスクリプション階層ではなくリクエスト単位でAPIの料金を設定しています。投稿作成は呼び出しごとに課金され、POST /2/tweetsはユーザーあたり15分間で100リクエスト、アプリあたり24時間で10,000リクエストに制限されています。直接連携を構築するかどうかを判断しているなら、この2つの事実がアーキテクチャの大半を決めます。
X APIの実際の料金は？
公式の料金ページでは、名前付きプランではなくクレジット方式が説明されています。クレジットを購入し、支出上限を設定し、呼び出しごとに残高から差し引かれます。
| 操作 | 表示されている料金 |
|---|---|
| 投稿作成 | リクエストあたり$0.015 |
| URLを含む投稿 | リクエストあたり$0.200 |
| 投稿（サモン） | リクエストあたり$0.010 |
| DMおよびユーザーとのやり取り | リクエストあたり$0.015 |
| やり取りの削除 | リクエストあたり$0.010 |
| 読み取り：投稿 | リソースあたり$0.005 |
| 読み取り：ユーザー、DM、フォロー中/フォロワー | リソースあたり$0.010 |
| 読み取り：いいね、ミュート、ブロック | リソースあたり$0.001 |
| 自分自身のデータの読み取り | リソースあたり$0.001 |
単価そのものより重要な点が2つあります。URLを含む投稿は通常の投稿の13倍以上の料金がかかり、リンクを日常的に投稿する用途では無視できないコスト項目になります。また、従量課金プランは月間の請求サイクルごとに投稿の読み取りが300万件に制限されており、読み取りの多いプロダクトはクレジットをいくら購入しても超えられない上限に達します。
リソースはUTCの24時間ウィンドウ内で重複排除されるため、同じリソースを1日に2回リクエストしても課金は1回分です。
注： ここに示す数値は2026年9月時点でdocs.x.com/x-api/getting-started/pricingに照らして確認したものです。プラットフォーム側は予告なくこれらを変更します。
確認できなかったこと。 月間投稿上限のある旧来のFree、Basic、Proといった階層は、ネット上で広く言及されています。しかし、それらを一覧にした公式ページを見つけることはできませんでした。現在の料金ページと紹介ページでは、名前付き階層のない従量課金制が説明されており、階層のURLは404を返します。私たちは第三者の数字を再掲することはしません。ご自身のアカウントに適用される料金は開発者コンソールで確認してください。
X APIで投稿できること、できないこと
POST /2/tweetsは、text、任意でmedia.media_ids、reply、poll、geo、reply_settings、およびmade_with_aiやpaid_partnershipといった一部のフラグを受け取ります。
メディアはこの呼び出しには含まれません。分割アップロード用のエンドポイントで別途アップロードし、得られたmedia_idを渡します。1つの投稿には最大4枚の写真、1つのアニメーションGIF、または1本の動画を添付できます。
導入前に知っておくべき制約は以下の通りです。
quote_tweet_idはEnterprise限定です。 引用投稿は一般エンドポイントでは利用できません。- 動画の上限は投稿するアプリではなく、投稿するアカウントに依存します。 標準アカウントは20分・8GBまでですが、X Premiumおよび認証済みアカウントは125分・16GBまでです。アップローダー側は、投稿先ユーザーによって決まる上限であるため、両方に対応する必要があります。
- 投票には制約があります。 選択肢は2〜4個、期間は5分から10,080分の間です。
- 作成リファレンスには文字数制限の記載がありません。 このページからは確認できませんでした。実際にプロダクトが強制する制限についてはX文字数制限の記事を参照してください。
注： ここに示す数値は2026年9月時点でdocs.x.com/x-api/posts/creation-of-a-postに照らして確認したものです。プラットフォーム側は予告なくこれらを変更します。
認証モデルを平易に言うと？
モードは2つあり、投稿ができるのはそのうち1つだけです。
アプリ専用ベアラートークン。 アプリケーションを表す単一の認証情報です。公開データの読み取りは可能ですが、投稿はできません。投稿対象となるユーザーが存在しないためです。
OAuth 2.0 認可コード（PKCE付き）、ユーザーコンテキスト。 ユーザーはXの認可画面に送られ、コードを持って戻ってきて、それをアクセストークンと交換します。投稿にはtweet.writeスコープに加えてtweet.readとusers.readが必要です。アクセストークンの期限が切れた後も投稿を続けたい場合は、認可時にoffline.accessをリクエストする必要があり、これによってリフレッシュトークンが発行されます。
最後の点でつまずく人が多いです。offline.accessは認可ごとのオプトインです。これを省略すると、すべてのユーザーがインタラクティブに再認可する必要があり、午前3時に投稿するスケジューラにとっては致命的です。ドキュメントにはアクセストークンの有効期間が明記されていないため、短命なものとして扱い、先回りしてリフレッシュしてください。
投稿のレート制限は？
| エンドポイント | ユーザーあたり | アプリあたり |
|---|---|---|
POST /2/tweets | 15分間で100回 | 24時間で10,000回 |
すべてのレスポンスにはx-rate-limit-limit、x-rate-limit-remaining、x-rate-limit-reset（Unixタイムスタンプ）が含まれます。自分でカウントするより、これらを読み取るべきです。再試行が発生した瞬間に、自分のカウンターとXのカウンターはずれてしまいます。
ドキュメントには、レート制限と課金は別問題であると明記されています。レート制限内に収まっていても支出の上限にはならず、支出上限を設定しても429エラーは防げません。両方の制御が必要です。
注： ここに示す数値は2026年9月時点でdocs.x.com/x-api/fundamentals/rate-limitsに照らして確認したものです。プラットフォーム側は予告なくこれらを変更します。
実際に3週間かかるのは何か
投稿呼び出しそのものではありません。それは午後の作業で終わります。
トークンのリフレッシュ。 offline.accessのリクエスト、リフレッシュトークンの暗号化保存、ローテーションの処理、リフレッシュに失敗したユーザーの再接続経路。これは単なる関数ではなく、独自の失敗モードを持つバックグラウンド処理です。
分割メディアアップロード。 INIT、APPEND、FINALIZEを行い、メディアIDを投稿で使える状態になるまで処理状況をポーリングする必要があります。動画のトランスコードは失敗することがあり、しかもアップロードが200を返した後で失敗します。
アカウントごとの動画上限。 20分か125分かは、投稿先のアカウントによって分岐する実行時のロジックであり、アプリの認証情報だけでは判断できません。
コストの管理。 リクエスト単位の料金体系では、誰かが支出を顧客に紐づける必要があり、そうしなければURLの割増料金を請求書で初めて知ることになります。
単なる待機ではない429対応。 ユーザーごとのウィンドウは15分です。単純な再試行ループは、1件のレート制限投稿をワーカーの停止に変えてしまいます。
まとめ
- 料金は従量課金制のクレジットです。投稿作成はリクエストあたり$0.015、URL付き投稿は$0.200です。
- 従量課金プランの読み取りは、月間請求サイクルごとに300万件が上限です。
POST /2/tweetsはユーザーあたり15分間で100回、アプリあたり24時間で10,000回まで許可されます。- 投稿には
tweet.writeを伴うOAuth 2.0 PKCEユーザーコンテキストが必要で、リフレッシュトークンが欲しい場合はoffline.accessも必要です。 - メディアは別途アップロードします。写真4枚、GIF1つ、または動画1本まで。引用投稿はEnterprise限定です。
- 名前付きのFree/Basic/Proプランは、2026年9月時点で公式ページから確認できませんでした。
プラットフォームごとに繰り返すのではなく、一度で済ませる
上記の作業は現実のものであり、Xに固有の形をしています。LinkedInは異なるスコープを持つ2つの別アプリが必要です。TikTokはContent Posting APIの監査を通過する必要があります。Threadsはコンテナ作成後に公開するという手順を踏み、トークンリフレッシュのサイクルは60日です。どれも他へは流用できません。
BulkPublishは、Facebook、Instagram、TikTok、YouTube、X、Bluesky、Threads、Pinterest、LinkedIn、Google Business Profile、Mastodon、Discord、Telegram、Tumblr、Snapchatの15のプラットフォームに対して、1つのREST APIを提供します。1つの認証モデル、1つのメディアパイプライン、1つの投稿オブジェクトで、プラットフォームごとのトークンリフレッシュや非同期のステータスポーリングはその裏側で処理されます。開発者ドキュメントとREST APIリファレンスにエンドポイントの詳細があります。