X API（旧Twitter API）の料金と使い方｜従量課金の単価・無料クレジット・レート制限【2026年10月】

X API（旧Twitter API）は、2026年2月6日から月額プランを持たない従量課金（Pay-Per-Use）が標準の入り口になりました。料金はPost読み取り1件0.005ドル、URLを含む投稿1回0.200ドルといったリソース単位の単価で決まり、10月2日からは新規の支払いアカウントに最大70ドルの無料クレジットも付きます。この記事では、2026年10月19日時点の公式ドキュメントをもとに、単価表、無料で試せる範囲、旧Basic・Proプランの扱い、セルフサーブでできない操作、認証の選び方、公式SDK（XDK）のコード、429対策、請求の上限設定までを順に解説します。

まとめ｜X APIの料金と始め方の要点（2026年10月19日時点）

• 公式のpricingページに載っている料金は従量課金だけです。クレジットを前払いし、読み取りは返ってきたリソースの件数、書き込みはリクエスト回数で差し引かれます。月額200ドルのBasicと5,000ドルのProは、developer.x.comでは「旧モデル」の扱いです。
• 主な単価は、Post読み取り0.005ドル、ユーザー・フォロワー・DMの読み取り0.010ドル、投稿0.015ドル、URL付き投稿0.200ドルです。自分のアプリが自分のデータを読む「Owned Reads」は0.001ドルまで下がります。
• Free枠はありません。代わりに、最初のカードで初回購入すると20ドル、初回の自動チャージが成功するとその額（上限50ドル）の無料クレジットが付きます。有効期限は付与から3か月です。
• 同じリソースは24時間（UTCの1日、日本時間9時に切り替わり）の中で何度読んでも1回分の課金です。
• セルフサーブでは、フォロー・いいね・引用ポストをAPIから実行できず、返信は元投稿の作者に@メンションか引用で呼ばれた場合だけ通ります。Bot用途はここで可否が決まります。
• 着手前に、Developer Consoleで支出上限を必ず設定してください。上限に達すると次の請求サイクルまでリクエストが止まります。

X APIの料金体系｜2026年2月の従量課金移行とBasic・Proの扱い

料金の前提は2026年に2回変わっています。日本語の解説には、2月以前のプラン表や4月以前の単価が残っているものが多いため、まず現在の体系を確定させます。

Pay-Per-Useと旧プラン（月額200ドル・5,000ドル）の違い

X APIの変更履歴（changelog）によると、Pay-Per-Useの正式提供は2026年2月6日です。同日の発表では、新しいDeveloper Console（console.x.com）、公式SDKのXDK、テスト用のPlaygroundが案内されています（Playground自体の公開は2025年12月23日）。この発表では「Basic and Pro plans remain available」と書かれ、既存の契約者はPay-Per-Useへ切り替えることもできるとされています。

一方、developer.x.comの料金比較は、固定月額料金（200ドルまたは5,000ドル）、プランごとのレート制限、オブジェクトの月間取得上限を「旧モデル」の欠点として並べています。公式のpricingページに載っているのも従量課金の単価表だけです。

2月の発表では、旧Freeの最近の利用者に10ドルのバウチャーを1回配り、公益性の高いアプリ（Public Utility Apps）には無料のアクセスを続けるとしています。既存のBasic・Pro契約がある場合は、請求の形態をConsoleで確かめてから見積もってください。

無料で使えるか｜Free廃止後に残った最大70ドルの無料クレジット

「X APIは無料で使えるか」への答えは、Free枠は無いが、条件を満たせば最大70ドル分を無料で使える、です。無料クレジットの公式ページは2つの特典を定めています。

• カード登録の特典（20ドル）：アカウントに初めて登録したクレジットカードかデビットカードで、初回のクレジット購入を終えると付与されます。2026年10月13日の改定で、カードを登録しただけでは付かなくなりました。プリペイドカードは対象外です。
• 自動チャージの特典（最大50ドル）：初回の自動チャージが実際に決済されたとき、その額と同じ無料クレジットが付きます。自動チャージの最低額は5ドルで、100ドル以上をチャージしても特典は50ドルで頭打ちです。

どちらもアカウントごと・カードごとに1回限りで、付与から3か月で失効します。購入したクレジットより先に消費される点も押さえておいてください。公式ページは「rolling out（順次展開中）」と書いており、まだ有効になっていないアカウントでは何も付与されません。

無料分を受け取るには、まず最初の対象カードで初回のクレジット購入を終えます。自動チャージの特典も受け取るなら最低額の5ドルで設定し、残高がしきい値を下回って初回の自動決済が成功するのを待ちます。両方を満たせば、購入額に加えて20ドルと5ドルの無料クレジットが付きます。自動チャージ額を50ドルにして初回の自動決済が成功すれば、カード登録の特典と合わせて無料分は最大の70ドルになります。

従量課金の単価表｜Post読み取り0.005ドルとURL付き投稿0.200ドル

読み取りはレスポンスに含まれたリソース1件ごと、書き込みは1リクエストごとに課金されます。1回の検索で100件のPostが返れば、100件分の0.5ドルです。

読み取り12種の単価と1万件あたりの金額

読み取り単価では、ユーザー・DMイベント・フォロー／フォロワーの0.010ドルが最高額です。他社アカウントのフォロワー1万人を毎日取り直すと、月30回で3,000ドルになります。差分だけを取るか、取得を週1回に落とすかを最初に決めてください（週1回なら月4〜5回で400〜500ドル）。

書き込みでURL付き投稿だけ13.3倍になる単価の内訳

URL付き投稿の0.200ドルは、2026年4月20日の改定で入った単価です。それまでの投稿は0.010ドルでした。そのため、「1投稿0.01ドル」と書いた記事の数字で稟議を通すと、URL付き投稿では実額の20分の1で見積もることになります。ブログ更新やリリース情報の自動投稿はURLを含むのが普通なので、1日100件なら月600ドル、1日10件でも月60ドルを前提にしてください。

Owned Readsと24時間UTCの重複除外で課金が減る条件

課金を下げる仕組みは2つあります。1つ目のOwned Readsは、開発者アプリの所有者本人として認証し、/2/users/{id}/tweets・/followers・/bookmarksなど12のエンドポイントで自分のIDを指定したときに、1件0.001ドルになる単価です。自社アカウントのフォロワー1万人を毎日読むなら、月3,000ドルではなく300ドルで済みます。

2つ目は重複除外です。pricingページは、課金済みのリソースをUTCの同じ日のうちにもう一度取得しても追加課金しないと定めています。日本時間では毎朝9時に切り替わります。公式は「soft guarantee」と書いており、障害時などに除外されない場合がある点は見込んでおいてください。同じ監視クエリを1時間ごとに回す設計でも、同じ日に重なったPostは1回分しか数えられません。

X APIクレジットの購入額に応じて、xAI APIのクレジットも還元されます。請求サイクル内の累計購入額が200ドル以上で10%、500ドル以上で15%、1,000ドル以上で20%で、率は累計額全体に掛かり、すでに受け取った分との差額が付与されます。同じサイクルで500ドル分を購入すると、還元の総額は75ドル分です。受け取るには、Consoleの設定でxAIのチームを連携しておく必要があります。

X APIでできること・できないこと｜セルフサーブの制限3点

従量課金を含むセルフサーブには、Enterpriseには無い機能制限があります。単価より先に、作りたいものがこの制限に当たらないかを確認してください。

2026年4月20日にAPIから外れたフォロー・いいね・引用ポスト

4月の改定を告知したchangelogには、「Following, Likes, and Quote-Posts via the API have been removed from all self-serve tiers.」とあります。投稿作成のリファレンスにも、quote_tweet_idによる引用ポストはEnterpriseプランが必要で、Pay-Per-Useでは使えないと明記されています。フォローの自動化や、いいね・引用で反応するBotは、セルフサーブでは作れません。

セルフサーブの返信許可条件とcashtagの個数制限

2026年2月23日から、APIでの返信は、元投稿の作者が返信する側のアカウントを@メンションしたか、そのアカウントの投稿を引用した場合だけ受け付けられます。投稿管理の統合ガイドは、条件を満たさない返信を拒否すると定め、APIで作る投稿の $TICKER 形式のcashtagを1投稿1個までに制限しています。キーワードを拾って自動で返信するBotは、セルフサーブでは成立しません。

Filtered Streamの利用上限｜Pay-Per-Useの1接続・1,000ルール

リアルタイム収集のFiltered Streamは、「Pay-Per-Useでは使えない」と書かれた解説がありますが、Filtered Streamの公式ページの表ではPay-per-useで使えます。上限はルール1,000本、ルール長1,024文字、同時接続1本です。意味で一致させる embedding: 演算子だけはEnterpriseのEmbedding tierが必要です。なお、2026年5月4日の検索インデックス移行でリポストが返らなくなったのは検索・件数集計エンドポイントのキーワード検索で、Filtered Streamには変更がありません。

X APIの始め方｜console.x.comでのクレジット購入からBearer Token取得まで

開発者アカウントの作成から最初のリクエストまでは、次の順で進めます。

1. console.x.comにXアカウントでサインインし、開発者アカウントとアプリを作成する
2. Billingで支出上限（Spending limit）を設定する。上限は請求サイクル単位で、到達すると次のサイクルまでリクエストが止まる
3. クレジットを購入する。最初に登録したカードで購入すると、無料クレジットの20ドルが付く
4. アプリの画面でBearer Tokenを控える。投稿などユーザーとして操作する場合は、OAuth 2.0のClient IDとコールバックURLも設定する
5. 次章のcurlでユーザー情報を取得し、疎通を確認する

認証方式の選び方｜Bearer TokenとOAuth 2.0 PKCEの使い分け

判断の軸は「誰として操作するか」の1点です。公開データを読むだけならアプリ単位のBearer Token、ユーザーの代わりに投稿・DM・非公開データの参照をするならOAuth 2.0のユーザーアクセストークンを使います。Authorizationヘッダーの書式そのものはBearer Token（ベアラートークン）とは？読み方・Authorization: Bearerの書き方とJWTとの違いで整理しています。

アプリ専用Bearer Tokenの適用範囲と403になる操作

ユーザー検索、Post検索、ユーザー名からの情報取得といった公開データは、Bearer Tokenだけで取得できます。ただし、自分の情報を返す /2/users/me や投稿の POST /2/tweets はユーザー文脈が必須です。Bearer Tokenで呼ぶと、403と「Authenticating with OAuth 2.0 Application-Only is forbidden for this endpoint」というエラーが返ります。

投稿に必要な3スコープとアクセストークン2時間の寿命

投稿作成のリファレンスが求めるスコープは tweet.read・tweet.write・users.read の3つです。tweet.write だけでは失敗します。OAuth 2.0 Authorization Code Flow with PKCEの公式リファレンスによると、認可コードはユーザーの承認から30秒以内にトークンへ交換する必要があります。発行されるアクセストークンの有効期間は2時間で、リフレッシュトークンは offline.access スコープを付けたときだけ発行されます。常駐の投稿ジョブなら offline.access を加え、期限切れの前に更新する経路を作ってください。

code_challenge_method は S256 と plain を受け付けます。plain では、認可リクエストの code_challenge まで盗み見られると認可コードの横取りを防げないため、S256 を使います。code_verifier はリクエストごとに乱数から作り、固定文字列にしないでください。フロー全体の流れは認可コードフローとは？認可リクエストからトークン交換までの実装手順と検証設計を解説、更新の設計はリフレッシュトークンとは？トークンローテーションの仕組みと更新フロー・寿命設計を実装者向けに解説が詳しいです。

OAuth 1.0aのトークンを再認可なしでOAuth 2.0へ移す手順

2026年9月21日から、OAuth 1.0aで認可済みのユーザーを、同意画面を出さずにOAuth 2.0へ移せます。保存済みのOAuth 1.0aアクセストークンとシークレットを、grant_type=urn:ietf:params:oauth:grant-type:token-exchange で POST /2/oauth2/token に送ると、OAuth 2.0のアクセストークンとリフレッシュトークンが返ります。スコープはユーザーが元々許可した権限から決まり、offline.access は必ず含まれます（トークン交換の公式ガイド）。

X APIの使い方｜curlと公式XDKによるユーザー取得・検索・投稿の実装例

ベースURLは公式ドキュメントの表記どおり https://api.x.com/2/ にします。2026年10月19日に、api.x.com と旧ホストの api.twitter.com へ無効なトークンで同じリクエストを送ったところ、どちらもHTTP 401と同じエラー本文（application/problem+json）を返しました。旧ホストも応答していますが、新しく書くコードは api.x.com に合わせ、ホスト名は設定値に出しておいてください。

curlでユーザー情報を取得する最小リクエスト

公式の最初のリクエスト手順と同じ、ユーザー名から情報を引く例です。ユーザー読み取り1件として0.010ドルかかります。

export BEARER_TOKEN="Developer Consoleで控えたトークン"
curl "https://api.x.com/2/users/by/username/xdevelopers?user.fields=created_at,public_metrics" \
  -H "Authorization: Bearer $BEARER_TOKEN"

本体はレスポンスの data に入ります。user.fields を付けないと、id・name・username の3項目しか返りません。

公式XDK（xdk 0.10.6）の検索コードと取得件数の上限設定

Python版XDKは pip install xdk で入り、2026年10月19日時点の最新は0.10.6（Python 3.8以上）です。search_recent はページを順に返すイテレーターなので、件数の上限をコード側で掛けておくと、クエリの書き間違いで数万件を読むことを防げます。読み終えてから上限と比べると次のページの最大100件分だけ超えるため、次のページを取る前に残りの枠と比べます。

import os
from xdk import Client

client = Client(
    bearer_token=os.environ["BEARER_TOKEN"],
    base_url=os.environ.get("X_API_BASE_URL", "https://api.x.com"),
)

MAX_POSTS = 200          # このジョブで読んでよいPost数の上限
PRICE_POST_READ = 0.005  # Posts: Read の単価（ドル）
if MAX_POSTS < 100:
    raise ValueError("この例のMAX_POSTSは100以上に設定してください")

read = 0
for page in client.posts.search_recent(query="api", max_results=100):
    posts = page.data or []
    read += len(posts)
    if MAX_POSTS - read < 100:  # 次のページで上限を超えうるなら止める
        break

print(f"読んだPost: {read}件 / 概算 {read * PRICE_POST_READ:.3f}ドル")

max_results を大きくしてもリクエスト回数が減るだけで、返った件数分の課金は変わりません。この検索処理で費用を下げるには、クエリや取得頻度を絞って新たに課金される件数を減らします。取得の目的が自分の投稿やフォロワーの参照で満たせるなら、Owned Readsの対象エンドポイントに変えると単価も下がります。一般のキーワード検索はOwned Readsの対象外です。

XDKの投稿コードとURLの有無による単価差

投稿はユーザーアクセストークンで行います。本文は text か media.media_ids のどちらかが必要です。

import os
from xdk import Client
from xdk.posts.models import CreateRequest

client = Client(
    access_token=os.environ["USER_ACCESS_TOKEN"],
    base_url=os.environ.get("X_API_BASE_URL", "https://api.x.com"),
)
if "localhost" in client.base_url:
    client.session.headers["X-Auth-Method"] = "oauth2user"  # Playground専用

res = client.posts.create(body=CreateRequest(text="デプロイが完了しました"))
print(res.data.id, res.data.text)

この投稿は0.015ドルですが、text に https:// で始まるリンクを1本入れると、同じ1リクエストが0.200ドルになります。コード上の違いは文字列の中身だけなので、投稿テンプレートにURLが入るかどうかをコードレビューの確認項目にしてください。

課金せずに試す｜X API Playgroundでのローカル検証と3つの実測結果

X公式のX API Playgroundは、X API v2を模したローカルサーバーです。本物のAPIを呼ばないので、クレジットもレート制限も消費しません。Go 1.21以上を用意し、インストール先（go env GOPATH の下の bin）をPATHに追加してから、次の2行で起動します。

go install github.com/xdevplatform/playground/cmd/playground@latest
playground start --port 18980

先ほどのコードは、環境変数 X_API_BASE_URL=http://localhost:18980 を渡すとPlaygroundに向きます。投稿コードには、Playgroundでユーザー文脈を指定するヘッダーの1行を入れてあります。トークンは test で通り、Playgroundは /api/accounts/0/cost で概算費用を返します。2026年10月19日にv1.2.1で実行した結果は次のとおりです。

• 重複除外は再現される：上の検索コードを2回続けて実行すると、どちらも54件を読みましたが、費用は54件分の0.27ドルのままでした。公式の24時間UTC窓の重複除外と一致します。
• 認証の取り違えは403で再現される：Bearer Token扱いのまま POST /2/tweets を呼ぶと、本番と同じ「Application-Only is forbidden」の403が返りました。ユーザー文脈で試すときは、ヘッダー X-Auth-Method: oauth2user を足します（Playground専用の指定です）。
• 投稿の費用は本番より安く出る：URLなしとURL付きの投稿を1回ずつ送ると、どちらも旧単価の0.01ドルで計上され、合計0.02ドルでした。本番の単価なら0.215ドルです。今回確認したPost検索の費用は公式単価と一致しましたが、他の読み取り操作までは確認していません。見積もりは操作ごとの公式単価で計算し、Playgroundの費用表示は補助として扱ってください。

レート制限と429対策｜x-rate-limit-resetまで待つ再試行

主要エンドポイントの上限｜15分ウィンドウと投稿1万件／24時間

レート制限の公式表では、ウィンドウは主に15分か24時間です。Bearer Tokenならアプリ単位、ユーザートークンならユーザー単位で数えます。

マルチテナントのサービスでBearer Tokenに寄せると、全顧客が1つのアプリ枠を取り合います。同じ設計の論点はFigma APIの使い方｜APIキー発行・レート制限の実数・Variables REST APIの条件【2026年10月】でも扱っています。

残り回数を見て手前で止める再試行コード

レスポンスヘッダーの x-rate-limit-limit（上限）、x-rate-limit-remaining（残り）、x-rate-limit-reset（リセット時刻のUnix秒）を読みます。次のコードは、残りが0になったら次に呼んでよい時刻を呼び出し側へ返し、429を受けたらリセット時刻か指数バックオフの長いほうだけ待って再試行します。待ち時間が max_wait（既定900秒＝15分ウィンドウ）を超えるときは、待たずに例外で処理を保留し、reset以降のジョブ再実行に回します。

import os
import time
import requests

BASE_URL = os.environ.get("X_API_BASE_URL", "https://api.x.com")

class RateLimitDeferred(Exception):
    """待機が長すぎるので、reset 以降にジョブを再実行させる"""
    def __init__(self, reset):
        super().__init__(f"reset={reset} 以降に再実行してください")
        self.reset = reset

def get_with_rate_limit(path, token, params=None, max_retry=5, max_wait=900):
    """戻り値は (JSON, 次に呼んでよいUnix秒)。待ち時間が max_wait を超えたら保留する"""
    headers = {"Authorization": f"Bearer {token}"}
    for attempt in range(max_retry):
        res = requests.get(f"{BASE_URL}{path}", headers=headers, params=params, timeout=10)
        remaining = res.headers.get("x-rate-limit-remaining")
        reset = int(res.headers.get("x-rate-limit-reset", 0))
        if res.status_code == 429:
            wait = max(reset - int(time.time()), 2 ** attempt)
            if wait > max_wait:
                raise RateLimitDeferred(reset)
            time.sleep(wait)
            continue
        res.raise_for_status()
        next_at = reset if remaining == "0" else 0
        return res.json(), next_at
    raise RuntimeError("rate limit: 再試行の上限に達しました")

# 呼び出し側：残りが0になったら reset の1秒後まで待ってから次へ進む
data, next_at = get_with_rate_limit(f"/2/tweets/{os.environ['POST_ID']}", os.environ["BEARER_TOKEN"])
if next_at:
    time.sleep(max(next_at - time.time(), 0) + 1)

本番では取得できる投稿のIDを環境変数 POST_ID に入れます。Playgroundで GET /2/tweets/102 の上限を10秒に3回へ絞り、POST_ID=102 で5回続けて呼ぶと、3回目で残り0になり、約11秒待ってから4回目と5回目が200で返りました。resetちょうどまでしか待たない版では、秒の端数で窓が戻りきらず429を受けたため、1秒の余裕を足しています。先に枠を使い切ってから max_wait=60 で呼ぶと、Playgroundは429とともに900秒先のresetを返し、関数は再試行せずに RateLimitDeferred を送出しました。固定1秒の待機で再試行し続ける実装は、枠が戻るまで無効なリクエストを積み上げるだけです。

コスト暴発を止める設計｜支出上限・自動チャージ・使用量API

従量課金で一番大きな事故は、バグやリトライのループで請求が伸び続けることです。

支出上限と、自動チャージの5分に1回という安全装置

支出上限は、請求サイクルごとに使える最大額です。予算超過を許容できない業務では上限を外さず、止まったときの手動処理や代替経路のほうを用意してください。

自動チャージは、残高がしきい値を下回ったときに設定額を補充します。pricingページによると、補充は5分に1回までで、残高が0以下のあいだは動きません。そのため、5分以内に1回分の補充を使い切るような急な消費では、自動チャージを有効にしていても「out of credits」が出ます。運用の目安は、支出上限を承認済みの月額予算以内、自動チャージ額をピーク時5分間の消費を上回る額に置き、補充が1日に何度も起きたら通知することです。

/2/usage/tweetsと/2/usage/creditsによる消費数・残高の監視

Usageエンドポイントは、日別のPost消費数（/2/usage/tweets）と、Pay-Per-Useのクレジット残高（/2/usage/credits、米ドル）を返します。

curl "https://api.x.com/2/usage/tweets" -H "Authorization: Bearer $BEARER_TOKEN"
curl "https://api.x.com/2/usage/credits" -H "Authorization: Bearer $BEARER_TOKEN"

1日1回これを取り、前日比が想定の2倍を超えたら通知する、という監視を締め処理より前に置いてください。月300万件の上限に月末で当たると、その時点で収集が止まるからです。

月額を件数から逆算する3パターンの試算

費用を決めているのは機能の多さではなく、単価の高いリソースを何件読むかです。上の試算は重複除外を考えない最大値で、同じPostを同じ日に読み直す設計ならこれより下がります。見積もりや社内システムとの連携部分の設計から相談したい場合は、API開発・システム連携で受けています。

X APIを使わない判断｜埋め込みで足りる要件と月300万件の天井

着手前に次の2点で切り分けると、APIを使わずに済む要件が見つかります。

表示用途での公式埋め込み（publish.x.com）の選択

自社サイトに投稿やタイムラインを並べたいだけなら、APIは要りません。Postの表示要件は、埋め込みポストと埋め込みタイムライン（publish.x.com）の利用を強く推奨しています。OAuthなしで最新のデータを取得でき、写真・動画・編集済み投稿も正しく表示されます。APIで取得して自前で描画すると、課金・トークン管理・レート制限・表示要件への準拠がすべて自社の保守になります。APIを選ぶのは、データを分析基盤やCRMへ渡す、条件で通知する、社内システムから投稿するといった、公式の埋め込みでは満たせない要件があるときです。

月300万件の上限とEnterpriseへ移る目安

Pay-Per-Useで読めるPostは、請求サイクルあたり300万件までです。単価0.005ドルを掛けると月15,000ドルで、ここに近づいたらEnterpriseの見積もりを取る段階です。開発者契約もセルフサーブを、試作や初期開発、利用者数が限られたアプリ向けと位置付けています。目安として、月の請求が1,000ドルを超え始めたら、差分取得、取得頻度の引き下げ、Owned Readsへの寄せ替えで減らせる余地を先に潰し、それでも300万件に迫る場合はEnterpriseを検討してください。また件数にかかわらず、開発者契約が定めるセルフサーブの利用範囲を超える使い方では、Enterpriseへの申請または契約が必要です。取得したデータの読み方はXアルゴリズム最新（2026年10月）：おすすめの仕組みと重み一覧、口コミ分析システムの作り方が前提知識になります。

よくある質問

X APIは無料で使えますか？

Free枠はありません。ただし、最初のカードで初回のクレジット購入をすると20ドル、初回の自動チャージが成功するとその額（上限50ドル）の無料クレジットが付き、合計で最大70ドル分を無料で使えます。無料クレジットは付与から3か月で失効し、購入したクレジットより先に消費されます。特典は順次展開中のため、Consoleの「Billing」→「Credits」で付与されたかを確認してください。

X APIの料金は月いくらからですか？

月額の基本料はありません。前払いしたクレジットから使った分だけ差し引かれます。Post読み取りなら1,000件で5ドル、URLなしの投稿なら100回で1.5ドル、URL付きの投稿なら100回で20ドルです。月額200ドルのBasicや5,000ドルのProは、developer.x.comでは旧モデルの扱いで、公式のpricingページに載っているのは従量課金の単価だけです。

XのAPIキーとは何ですか？

Developer Consoleでアプリを作ると発行される、アプリを識別する認証情報（API KeyとSecret）です。公式の認証ページは、API Keys、アプリ専用のApp-only Access Token（いわゆるBearer Token）、ユーザーのAccess Tokenを別のものとして扱っています。公開データの読み取りにはApp-only Access Tokenを、投稿やDMのようにユーザーとして操作するにはOAuth 2.0（PKCE）で取得したユーザーアクセストークンを使います。どちらも Authorization: Bearer で送るため、ヘッダーの形式だけでは区別できません。漏れるとアプリのクレジットを他人に使われる点は共通です。

Twitter APIとX APIは別物ですか？

同じサービスの名称変更です。公式ドキュメントはX APIの表記に統一され、ベースURLも api.x.com で書かれています。ただし旧v1.1とv2はエンドポイントもレスポンスの構造も違うため、古い記事のv1.1のコードはそのままでは動きません。新しく書くならv2のリファレンスと公式XDKから始めてください。

1回のリクエストで100件取得すると、課金は1件分ですか？

読み取りはリソース単位の課金なので、100件返れば100件分です。Post読み取りなら0.005ドル×100件で0.5ドルです。ただし、同じPostをUTCの同じ日のうちにもう一度取得した分は課金されません。書き込みはリクエスト単位の課金で、呼び出し回数がそのまま金額になります。

関連記事

• Bearer Token（ベアラートークン）とは？読み方・Authorization: Bearerの書き方とJWTとの違い
• 認可コードフローとは？認可リクエストからトークン交換までの実装手順と検証設計を解説
• Instagram Graph APIとは？料金・できること・使い方を2026年10月の仕様で解説
• Xアルゴリズム最新（2026年10月）：おすすめの仕組みと重み一覧、口コミ分析システムの作り方