X APIの料金はいくら？従量課金の単価と月額の目安

X APIの料金を調べていると、「Basicは月200ドル」という情報と「1件0.005ドル」という情報が同時に出てきて、結局いくらなのか分からなくなりますよね。これは古い料金体系と新しい料金体系が検索結果に混在しているためです。いまのX APIは従量課金（Pay-Per-Use）が標準で、使った分だけクレジットから引かれる仕組みになっています。この記事では公式の単価をそのまま一覧にしたうえで、SNS運用担当者が自分のアカウントを自動化したら月いくらになるのかを、タスク単位で試算していきます。なお円換算は1ドル＝150円での概算です。

X APIの料金はいま、どういう仕組みになっているの？

まず全体像を押さえてください。いまのX APIは、前払いでクレジットを購入し、APIを呼び出すたびに操作ごとの単価が引かれていく方式です。月額固定で「◯円払えば使い放題」ではなく、電気やガスのメーターに近い考え方になりました。

そのため予算の立て方も変わります。以前は「どのプランを契約するか」を決めれば終わりでしたが、いまは「何の操作を1日何回行うか」を数えないと金額が出ません。逆に言えば、小さな自動化しかしないなら月数百円で収まります。ここが従量課金に変わった最大のメリットです。

月額プランから従量課金に変わったのはいつ？

従量課金が標準になったのは2026年2月です。それ以前はFree・Basic・Pro・Enterpriseという階段状のプランがあり、無料枠を超えた瞬間に月200ドルへ跳ね上がる構造でした。この「中間がない」点が、個人開発者や小規模な社内ツールにとって長年のネックだったわけです。

いまは最低購入額の範囲でクレジットを買い、使い切ったら足す形になります。検索上位の解説記事の中には、いまだにFree・Basic・Proを現行プランとして紹介しているものがありますが、それを前提に予算を組むと実態と大きくずれます。料金を試算するときは、必ず単価表ベースで計算してください。

読み取りと書き込みで課金の数え方はどう違うの？

課金は大きく「読み取り（Reads）」と「書き込み（Writes）」に分かれます。読み取りは取得したデータの件数で数えます。投稿を100件取得すれば100件分、ユーザー情報を10件取得すれば10件分です。リクエストの回数ではなく、返ってきたオブジェクトの数で課金される点が重要です。

一方の書き込みは、操作1回ごとに課金されます。投稿を1本作れば1回分、DMを1通送れば1回分です。書き込みは単価が読み取りより高めに設定されていますが、そもそも回数が少ないので、総額に効いてくるのはたいてい読み取りのほうです。コストを下げたいなら、まず読み取り件数から見直すのが鉄則です。

BasicやProのプランはもう契約できないの？

Basic（月200ドル）とPro（月5,000ドル）は旧モデルで、新規の申し込みは終了しています。既存の契約者が継続している状態なので、これから使い始める人が選べる選択肢ではありません。「X API Basicの料金は月200ドル」という記述を見かけたら、それは2026年2月より前の情報だと判断してください。

大規模にデータを扱う場合の受け皿としてEnterpriseは残っています。従量課金プランには月300万件という投稿読み取りの上限があり、それを超える規模ならEnterpriseでの個別契約になります。逆に言えば、月300万件に届かない範囲であれば、ほぼすべての用途が従量課金でカバーできます。

無料で使える枠はまだあるの？

「X API 無料」で探している方が一番知りたいのはここでしょう。恒常的な無料枠に頼る設計はもう成り立ちません。ただし初回だけ無料クレジットが用意されています。初めてカードを登録して初回購入をすると20ドル、さらに初回の自動チャージと同額（最大50ドル）が付き、合計で最大70ドル分です。

この無料クレジットには条件が2つあります。付与から3か月で失効すること、そして購入分のクレジットより先に消費されることです。つまり「とりあえず多めに買って、無料分は後で使おう」という持ち方はできません。最初の3か月で試作と検証をやりきる前提でスケジュールを組むのが正解です。

操作ごとの単価はいくら？

ここからが本題の単価表です。数字そのものは公式ドキュメントに掲載されているものをそのまま載せます。自分がやりたい処理がどの行に当たるかを確認しながら読んでください。

見るポイントは、単価の絶対値ではなく「1か月に何回それを行うか」との掛け算です。0.200ドルは一見高く見えますが月10回なら2ドルですし、0.001ドルでも月10万件読めば100ドルになります。単価と頻度はセットで考えます。

投稿・DM・フォローなど書き込みの単価

書き込み系の単価は次のとおりです。自動投稿やDM配信を組む場合はこの表が基準になります。

注目してほしいのはURL付きPostだけが0.200ドルで、通常投稿の約13倍になっている点です。リンク付きの投稿を自動化で毎日流す設計は、ここだけで費用が跳ね上がります。この回避策は後半の節で具体的に書きます。

投稿・ユーザー・フォロワーなど読み取りの単価

読み取り系の単価は次のとおりです。取得した件数ぶんだけ加算されます。

読み取りの月額は次の式で見積もります。

たとえば他人の投稿を1日100件取得するなら、0.005×100×30で月15ドル、約2,250円です。フォロワー一覧のように件数が一気に膨らむデータは0.010ドルと単価も高いので、全件取得をループで回す設計は真っ先に見直してください。

URL付き投稿だけが高いのはなぜ気をつけたらいい？

URL付きPostの0.200ドルは、1本あたり約30円です。毎日1本リンク付きで自動投稿すると、それだけで月6ドル（約900円）になります。1日3本なら月18ドル（約2,700円）です。投稿本数が増えるほど効いてくるので、リンクの扱いは最初にルール化しておくべきです。

実務的な対策は2つあります。ひとつは本文にリンクを置かず、リンクだけをリプライとしてぶら下げる構成に変えること。もうひとつは、リンク付き投稿を週2〜3本までと決め、それ以外は本文だけで完結させることです。リンクをリプライに分ける運用はタイムライン上の見え方にも影響するので、Twitter（ツイッター）の自動投稿をする方法の記事で触れている投稿設計とあわせて検討すると判断しやすくなります。

Webhookで届くイベントにも料金がかかるの？

かかります。Webhookで配信されるイベントも、受け取った時点で該当するデータ種別の読み取りとして数えられます。DM Eventなら0.010ドル、投稿に関するイベントなら0.005ドルという具合です。「こちらから取りに行っていないから無料」とはなりません。

ここで事故が起きやすいのは、フィルタ条件を広く設定したまま運用を始めてしまうケースです。話題のキーワードを購読してしまうと、1日で数万件のイベントが流れ込み、想定の数十倍の請求になります。Webhookを使うなら、購読条件を絞ったうえで、後述する月ごとの支出上限を必ず併用してください。

自分のアカウントを分析するなら、なぜOwned Readsが安いの？

SNS運用担当者にとって一番おいしい仕組みがOwned Readsです。自分のアカウントに属するデータを、自分のアプリから読む場合は1件0.001ドル、つまり1,000件で1ドルになります。通常の投稿読み取り0.005ドルの5分の1、ユーザー読み取り0.010ドルの10分の1です。

自社アカウントの運用改善が目的なら、必要なデータのほとんどは自分のものです。他人のタイムラインを広く集める必要はありません。この前提に立つだけで、月額は一桁変わります。

Owned Readsの対象になるデータはどれ？

対象は、自分の投稿、自分宛のメンション、自分が押したいいね、自分のブックマーク、自分のフォロワー、自分がフォローしている相手、自分が作ったリストなどです。要するに「自分のアカウントに紐づく一覧」はほぼ含まれると考えてください。

注意点は、同じエンドポイントでも対象が他人のアカウントになれば通常単価に戻ることです。たとえば競合アカウントの投稿一覧を取得すれば、それは0.005ドル/件の読み取りです。コード上は似た処理でも請求額が5倍違うので、自分のデータを読む処理と他人のデータを読む処理は、集計も分けて記録しておくと管理が楽になります。

他人のデータを読む場合とどれくらい差が出るの？

具体的な差を表にします。1か月あたりの件数で比較します。

件数が増えるほど差は広がります。月10万件という規模はエゴサーチを本格的に回せばすぐ到達する数字なので、「自分のデータで代替できないか」を設計段階で必ず一度は検討してください。

自社アカウントのダッシュボードを作ると月いくら？

自社アカウント1つぶんの運用ダッシュボードを想定してみます。毎日、直近30件の自分の投稿とその指標を取得し、メンションを20件拾い、プロフィール情報を1回取得する構成です。投稿とメンションはOwned Readsなので、(30＋20)×0.001×30日で1.5ドル、プロフィール取得が0.010×30日で0.3ドル。合計で月1.8ドル、約270円です。

月270円で自社アカウントの数値を毎日自動記録できるなら、開発工数さえ確保できれば十分に見合います。ただし「指標を集めること」と「次の投稿を決めること」は別の作業です。取得した数字をどう読むかはXアナリティクスの見方｜数字から次の投稿を決める分析手順で整理しているので、ダッシュボードの設計前に目を通しておくと項目選びで迷いません。自前で組む時間がない場合は、KAMITTERのような分析ツールに任せて、API費用と開発工数の両方を外に出す選択もあります。

SNS運用を自動化したら月いくらかかるの？

ここからは、実際の運用タスク単位で金額を出します。開発者向けの解説記事ではあまり見かけない切り口ですが、担当者が稟議を通すときに必要なのはこの形のはずです。

前提は、自社アカウント1つ、1日あたりの件数は小規模な企業アカウントの平均的な水準としています。自分の運用に合わせて件数だけ差し替えてください。

毎日1本の予約投稿だけなら

リンクなしの通常投稿を毎日1本、自動で流す場合です。Post作成は0.015ドルなので、0.015×30で月0.45ドル、約68円になります。1日3本に増やしても月1.35ドル、約203円です。投稿するだけなら料金はほぼ無視できる水準だと言い切れます。

問題になるのは、ここにリンクが入る場合です。同じ毎日1本でもURL付きなら0.200×30で月6ドル、約900円。本数が増えれば差はさらに開きます。

リンクを含む告知が多いアカウントほど、本文とリプライの分離が効きます。

自分の投稿の反応を毎日記録するなら

直近30件の自分の投稿を毎日取得して、インプレッションやエンゲージメントを記録する構成です。Owned Readsなので0.001×30件×30日で月0.9ドル、約135円になります。1日1回の取得であれば、この程度に収まります。

記録した数値から改善を判断するときは、エンゲージメント率を使うのが基本です。次の式で求めます。

この指標を投稿ごとに毎日蓄積しておくと、曜日や時間帯の傾向が数か月で見えてきます。APIで取る価値があるのは、画面上では遡れなくなる過去データを自分の手元に残せる点です。

エゴサーチとメンション監視を回すなら

ここが一番費用のかかるパートです。自社名での検索は他人の投稿を読むことになるので0.005ドル/件。1日50件ヒットするなら0.005×50×30で月7.5ドル、約1,125円です。1日200件なら月30ドル、約4,500円まで上がります。

一方、自分宛のメンション監視はOwned Readsなので0.001ドル/件。1日20件なら月0.6ドル、約90円で済みます。費用を抑えたいなら、@付きで届くものはメンション監視、@なしの言及だけを検索で拾う、と役割を分けるのが有効です。検索のクエリ精度がそのまま取得件数＝費用になるので、Twitter(X)の検索コマンド一覧を参考に、除外条件まで作り込んでからAPIに載せてください。

フォロワー推移を毎日記録するなら

やりがちな失敗が、フォロワー一覧を毎日全件取得することです。フォロワーが1万人いる場合、Owned Readsでも0.001×10,000で1日10ドル、月300ドル（約45,000円）になります。推移のグラフを描きたいだけなら、この取り方は明確に無駄です。

フォロワー数だけが欲しいなら、自分のユーザー情報を1日1回取得すれば足ります。User読み取りの0.010ドル×30日で月0.3ドル、約45円です。誰が増えて誰が減ったかまで追いたい場合だけ、週1回や月1回に絞って一覧を取得してください。なお取得した数値と画面表示がずれることもあるので、その前提はTwitterでフォロワーが正しく表示されない理由と対処法で押さえておくと、データの不一致で慌てずに済みます。

旧Basicの月200ドルと比べて得なのはどこまで？

ここまでの試算をまとめます。リンクなしの運用一式なら、次の表のとおりです。

月10ドル弱、約1,500円です。旧Basicの月200ドルと比べれば20分の1。損益分岐で言えば、投稿読み取りだけなら月4万件、Owned Readsなら月20万件を超えたあたりで200ドルに届きます。1アカウントの運用自動化でその水準に達することはまずないので、従量課金のほうが有利だと断言できます。

請求で驚かないために、どの細かいルールを押さえればいいの？

従量課金で怖いのは、単価そのものより「思ったより回数が多かった」という事態です。Xの従量課金にはコストを抑える仕組みと、逆に知らないと損する落とし穴の両方が用意されています。

ここで紹介する4つは、どれも公式ドキュメントに書かれているルールですが、通しで説明している日本語記事はほとんどありません。実装前に必ず確認してください。

同じデータを1日に何度読んでも1回分になる重複排除

同じリソースは、UTCの1日（24時間）の中では2回目以降が課金されません。日本時間だと毎日9時に区切りが切り替わります。つまり同じ投稿を朝10時と夜22時に取得しても、課金は1件分です。

これを使えば、1日の中で何度もポーリングする設計でも費用は膨らみません。ただし公式はこれを「ソフトな保証」と位置づけていて、障害時などは例外もあるとしています。重複排除を前提に極端な回数のリクエストを投げる設計は避け、あくまで「数回の取得で二重課金されない」程度の安心材料として扱うのが適切です。

自動チャージが止まる条件と5分ルール

自動チャージは、残高が設定したしきい値を下回ったときに、指定額を自動で補充する機能です。ここに制約が2つあります。発動は5分に1回までであることと、残高が0以下になっている場合は自動チャージが動かないことです。

後者が特に重要です。急激に消費が進んで残高がマイナスまで振り切れると、自動チャージは作動せず、手動で補充するまでリクエストが止まります。深夜に止まって朝まで気づかない、という事態を避けるには、しきい値を低く設定しすぎないことです。1日あたりの想定消費額の3〜5日分をしきい値にしておくと、5分ルールに引っかかっても残高が0を割る前に補充が追いつきます。

支出上限はどう設定すればいいの？

月ごとの支出上限を設定できます。上限に達すると、次の請求サイクルまでAPIの利用が停止します。安全装置として、運用開始時は必ず設定してください。

設定額の決め方はシンプルです。試算した月額の2倍を上限にします。前述の試算なら月9.75ドルなので、上限は20ドル。これならバグで無限ループが発生しても、損害は20ドルで止まります。慣れてきて実績値が安定したら、実績の1.5倍まで下げて構いません。上限に達したら止まる仕様なので、業務上止まると困る処理がある場合は、停止時にアラートが飛ぶようにしておきます。

無料クレジットが3か月で消える点に気をつける

無料クレジットは、初回購入時の20ドルと、初回の自動チャージと同額（最大50ドル）の合計で最大70ドルです。これは付与から3か月で失効します。さらに、購入したクレジットより先に無料分が消費される順序になっています。

この仕様を踏まえると、最初にやるべきは「3か月以内に検証を終える計画を立てる」ことです。アカウント登録だけ先に済ませて半年後に開発を始めると、無料分はすでに消えています。逆に、開発着手のタイミングでカード登録と初回購入を行えば、70ドル分＝Owned Readsなら7万件の読み取りをテストに充てられます。あわせて、購入額に応じて最大20%分のxAI APIクレジットが付く特典もあるので、生成AIと組み合わせる予定があるなら購入タイミングをそろえると無駄がありません。

料金を抑えるには、どこから手をつければいいの？

ここまでの内容を、実際の削減アクションに落とし込みます。効果の大きい順に並べました。手をつける順番を間違えなければ、たいていの運用は月数ドルの世界に収まります。

共通する考え方は「取りに行く件数を減らす」です。単価交渉はできませんが、件数は設計でいくらでも減らせます。

リンクは本文に入れずリプライに分ける

URL付きPostの0.200ドルは、書き込み系で突出して高い単価です。本文にリンクを入れず、投稿後にリプライとしてリンクを追加する形にすれば、通常投稿0.015ドル＋リプライ分の投稿料金になります。リプライ自体にURLが含まれる場合はそちらが0.200ドルになるため、削減になるのは「リンク付き投稿の本数自体を減らす」場合です。

現実的なルールとしては、リンク付き投稿は週2〜3本までと決めてしまうことをおすすめします。月に換算して10本なら2ドル、約300円です。残りの投稿はリンクなしのテキストで組み立て、プロフィール欄や固定投稿に導線を集約します。この設計はコストだけでなく、投稿単位の反応を素直に比較できるという副次的なメリットもあります。

読み取りは日本時間9時の切り替えを意識してまとめる

重複排除のリセットは日本時間の朝9時です。この性質を使うと、バッチの実行時刻を設計できます。たとえば日次集計を朝9時直前に回せば、その日のウィンドウで取得したデータを無駄なく1回分として扱えます。

逆にまずいのは、9時をまたぐ形で同じデータを2回取得する構成です。8時55分と9時05分に同じ投稿一覧を取得すると、それぞれ別の日として課金されます。定時バッチを組むときは、9時前後30分を避けた時刻に設定しておくと事故が起きません。細かい話ですが、取得件数が多いほど効いてきます。

検索は取得件数を絞って回す

エゴサーチ系の費用は、ヒット件数にそのまま比例します。クエリが甘いと、関係ない投稿まで課金対象として取得してしまいます。除外キーワード、言語指定、リツイート除外、期間指定を組み合わせて、ヒット数を必要最小限に絞ってください。

加えて、1回のリクエストで取得する最大件数（max_results）も必ず指定します。デフォルト任せにすると想定より多く返ってきます。「1日あたり何件まで取得するか」を上限として実装に組み込み、超えたらその日は打ち切る、という防御も入れておくと、話題が急に伸びた日に請求が跳ねるのを防げます。

自分のデータで済む集計はOwned Readsに寄せる

最後がこれです。自社アカウントの改善が目的なら、必要なデータの大半は自分のものです。自分の投稿、メンション、フォロワー、リスト。これらはすべて0.001ドルで読めます。

他人のデータが必要になるのは、競合分析と市場の話題把握の2つだけです。この2つを「月1回のレポート用に、期間を区切って取得する」運用に変えれば、日次で回す必要はなくなります。日次で回すものはOwned Reads、月次で回すものは通常読み取り、と明確に線を引いてください。これだけで月額は半分以下になります。

料金以外に、API利用で気をつけることは？

費用の話ばかりしてきましたが、実は止められる原因の多くは料金ではありません。規約と上限です。ここを外すと、クレジットが残っていてもアプリごと使えなくなります。

お金を払えば何をしてもいいわけではない、という当たり前の前提を、設計の段階で共有しておいてください。

自動いいね・自動フォローは料金より規約で止まる

User Interactionの単価は0.015ドルなので、フォローを1日100件行っても月45ドル程度です。しかしこの運用は、開発者規約と自動化に関するルールに抵触します。大量の自動フォロー・自動いいね・自動フォロー解除は、アプリの権限停止やアカウントの制限につながる行為です。

費用が出せるかどうかではなく、やってよいかどうかで判断してください。実際、一括操作を続けたアカウントはフォロー系の動作そのものが制限されることがあります。制限がかかったときの挙動についてはなぜ？Twitterでフォローができない時の原因と対処方法にまとめているので、自動化を検討する前に一度読んでおくと、どこまでが許容範囲かの感覚がつかめます。APIで自動化してよいのは、自分の投稿、自分宛の反応の収集、自分のデータの集計です。

月300万件の読み取り上限を超えるとどうなる？

従量課金プランには、月300万件という投稿読み取りの上限があります。これを超える規模のデータ取得が必要な場合は、Enterpriseでの契約に移行します。従量課金のまま上限を突破することはできません。

月300万件は、1日あたり10万件の投稿を取得し続ける規模です。企業アカウントの運用分析でここに届くことはありません。到達するのは、業界全体のソーシャルリスニングや研究用途のデータ収集です。自社運用の自動化を考えている段階では、上限を気にする必要はないと考えて構いません。

APIを自分で組むのとツールを使うのはどちらがいい？

判断基準をはっきり書きます。社内にPythonやNode.jsを書ける人がいて、かつ既存ツールにない独自の集計軸が必要なら自作。そうでなければツールです。月額1,500円のAPI費用と、開発・保守に使う人件費を比べると、ほとんどのケースで後者のほうが大きくなります。

加えてX APIは仕様変更が起きる領域で、料金体系も2026年2月に大きく変わりました。自作するということは、その変更に追従する担当者を社内に置き続けるということです。「データを自社DBに貯めたい」「複数アカウントを横断して独自指標を出したい」という明確な目的があるときだけ自作を選び、通常の運用分析はツールに任せるのが、工数と費用の両面で合理的です。消えた投稿の記録を残したいといった特殊な要件がある場合は、消されたツイートを見る方法で紹介している手段とAPIのどちらが目的に合うかを比較してから決めてください。

X APIの料金でよくある疑問にはどう答えればいいの？

最後に、実際に問い合わせの多い3点をまとめます。どれも運用開始前に知っておくと安心できる内容です。

細かい点ですが、ここを押さえておくと「請求が来てから慌てる」という事態を避けられます。

クレジットの残高や使った金額はどこで見ればいいの？

開発者ポータルのダッシュボードで、残高と消費状況を確認できます。従量課金は前払い方式なので、クレジット残高が実質的な予算そのものです。週に1回は残高を見る習慣をつけてください。

おすすめは、自分のアプリ側でも消費額を記録しておくことです。どのエンドポイントで何件取得したかをログに残し、単価を掛けて日次の推定コストを出します。ポータルの数字と突き合わせれば、想定外の消費がどの処理から出ているかをすぐ特定できます。この仕組みを最初に作っておくと、後から機能を増やすときの判断が速くなります。

残高がマイナスになったらどうなるの？

残高はわずかにマイナスになることがあり、その状態ではクレジットを補充するまでリクエストが通りません。そして前述のとおり、残高が0以下では自動チャージが作動しないため、手動での補充が必要になります。

対策は3つです。自動チャージのしきい値を余裕のある額にする、支出上限を設定して暴走を防ぐ、残高が一定を下回ったらSlackなどに通知する。この3つを入れておけば、気づかないうちに止まっていたという状況はほぼ起きません。特に業務のワークフローに組み込んでいる場合は、通知の設定を省略しないでください。

個人の趣味の開発でも使っていいの？

使えます。従量課金になったことで、むしろ個人開発との相性は良くなりました。以前は無料枠を超えた瞬間に月200ドルという断崖がありましたが、いまは使った分だけです。月数百円で動く小さなボットや分析スクリプトが現実的な選択肢になりました。

ただし個人利用でも開発者規約は同じように適用されます。自動フォローやスパム的な自動リプライは、個人だから許されるということはありません。自分のアカウントのデータを扱う、自分で投稿するものを自動化する、この範囲に収めておけば問題は起きません。まずは無料クレジットの70ドル分で小さく動かし、月額の実績値を掴んでから本格的に組み立てる。この順序が一番失敗しにくい進め方です。