比較 June 13, 2026

Xの2026年API料金改定:従量課金はDMと@メンション受信に何を意味するのか — UnifyPort

今年初めてX APIに登録した人は、2025年には存在しなかった壁にぶつかったはずだ——無料枠が存在しない。Xは2026年2月、開発者向けAPIを従量課金モデルに移行し、月額0ドルから5,000ドルまでの固定プランを廃止した。新規開発者はAPIを1回呼び出す前にクレジットをチャージする必要があり、「とりあえず無料で数回試す」という選択肢はなくなった。

X上でDMや@メンションを受信したいだけのチーム——投稿や分析ではなく、受信側だけが目的のチーム——にとって、これは意思決定の前提を根本から変える。以前は「どの固定プランがうちの量に合うか」だったが、今は「受信するメッセージ1件ごとに、ずっと続く課金が発生する」という話になる。

何が変わったのか、しかも2度変わった

2026年2月の改定で基本路線が決まった:1回の呼び出しごとに課金し、読み取りと書き込みは別料金、利用量の上限はない——呼び出した分だけ課金される。そして4月20日、Xは予告なしに料金をさらに改定した。自分のアカウントのデータ——自分の投稿、フォロワー、そしてDM——の読み取りは1リソースあたり0.001ドルへと大幅に下がり、当初の従量課金料金の5分の1になった。一方で、標準の書き込みリクエストは1回0.010ドルから0.015ドルに上がった。

DM・@メンションの受信パイプラインにとって、これは2つの課金メーターが同時に動いていることを意味する:

受信DM・@メンションの読み取り——4月の改定後、自分のリソースの読み取りは1件0.001ドルと比較的安価
返信の送信——書き込みリクエストとなり、現在は1回0.015ドル

0.001ドルという数字は小さく見えるが、実際にサポート業務を行うチームの日常で計算すると話が変わる。1日に数百件のDM・@メンションを処理する小規模チームでは、返信が必要なメッセージ1件ごとに読み取り料金と書き込み料金の両方が発生する——さらに、XのAPIでDMを「受信する」という行為は基本的に新着の有無をポーリングして確認することであり、プッシュ型のwebhookではない点も無視できない。ポーリングの頻度は実際のメッセージ量とは無関係に読み取りコストをさらに増幅させる。

利用量が少なければ、これらはさほど問題にならない——今年初めの料金分析でも、軽い利用なら月数ドル程度だと指摘されていた。しかし、これは「毎月固定額を払えば、あとは考えなくていい」とは根本的に異なるコスト構造だ。顧客からのメッセージ量が変動するたびに——新製品の発表、バズった@メンション、サポートの積み残し——その変動が読み取り・返信・ポーリングの回数として、そのまま請求額に反映される。

視点を変える:メッセージを受信するのに「APIを呼ぶ」必要は本来ない

見落としやすいのはここだ:上記のコスト構造はX公式APIの特性であり、「Xでメッセージを受信する」こと自体の特性ではない。本当に必要なのが「誰かが自社アカウントにDMや@メンションを送ってきたら、バックエンドがすぐに把握し、返信できる」ということだけなら、その要件自体は読み取りごと・書き込みごとにXへ料金を払うことを必然的には要求しない。

これがUnifyPortのX向け非公式インバウンドインターフェースが埋めるギャップだ。バックエンドがXのAPIをポーリングする(=読み取りごとに課金される)のではなく、UnifyPortがXアカウントに直接接続し、受信した動きをそのままwebhookへプッシュする——読み取り回数のカウントも、ポーリングループも、プラットフォーム側のメッセージ単位の課金も発生しない。

日本のチームにとっては、Xだけがチャネルというケースは少ないだろう。サポートや問い合わせの主軸はLINEであることが多く、XのDM・@メンションはその補助チャネルという位置づけが一般的だ。だからこそ、X単体の従量課金を気にするより、LINEを含む全チャネルを同じ正規化されたwebhookに乗せてしまう方が、運用上はずっとシンプルになる。

実際の接続イメージ

XアカウントをUnifyPortに接続するには、UnifyPort Exporter拡張機能で説明されているのと同じセッションベースのフローを使う。provider: "twitter"、auth_mode: "session" でアカウントレコードを作成し、すでにログイン済みのアカウントのセッションをエクスポートして、ランタイムを起動する。

POST /v1/accounts
Content-Type: application/json

{
  "provider": "twitter",
  "auth_mode": "session"
}

これ以降、このアカウントに届くDMと@メンションはすべて message.received イベントとしてwebhookへ届く——WhatsApp、Telegram、LINE、TikTok、Zaloと共通の正規化フォーマットだ:

{
  "event": "message.received",
  "account_id": "acct_8Q2vK",
  "provider": "twitter",
  "from": "user_3f9c1a",
  "text": "Hey, do you ship to the EU?",
  "timestamp": 1749427200,
  "message_id": "x_msg_7c1f9d"
}

返信も他のチャネルと同じ POST /v1/messages で、account_id と from で宛先を指定する。DMを先に「読み取る」ステップは不要で、イベント自体に必要な情報がすべて含まれており、メッセージ量やポーリング頻度に応じた課金も一切ない。

X (Twitter) ──► UnifyPort ──► message.received ──► あなたのwebhook
                    ▲                                    │
                    │                                    ▼
              POST /v1/messages ◄──────────── あなたの返信ロジック

すべての配信は設定した signing_secret を使ってHMAC-SHA256で署名されるため、検証ロジックは他のチャネルとまったく同じコードパスになる。

実際にどう判断すべきか

Xの利用量が本当に少なく——週に数件のDM程度で、他に自動化していない——のであれば、4月改定後の1件0.001ドルという読み取り料金は十分に安く、公式APIで問題ない。別の接続を構築する手間をかける価値はないだろう。

しかし、Xが複数のインバウンドチャネルのうちの1つであり、特に利用量が予測しづらい場合——投稿がバズった、サポートが一時的に集中した、新製品を発表した——読み取り・書き込みの従量課金モデルは「注目度が上がる」ことを直接「請求額が増える」ことに変換してしまう。これは本来あるべきインセンティブの方向とは逆だ。UnifyPortの統合webhook経由でXを接続すれば、他のチャネルと同じ統一された、課金メーターのない基盤に乗せられる——同じ message.received イベント、同じ返信エンドポイント、追加の計測層なし。