2026年7月更新:フラットレートのコストを1,000件あたりのレートで捉え直し、100回分の無料リクエストの開始オプションを追加し、公式 X API の2026年の読み取り料金を刷新しました。
要点: Twitter メンション API は、ハンドルをタグ付けする公開の投稿を、エンゲージメント指標と作者プロフィールとともに構造化された JSON として返します。公式 X API は
GET /2/users/{id}/mentionsを公開し、投稿読み取り単位で課金され、OAuth と数値のユーザー ID を必要とします。サードパーティ API は、1つのキーと組み込みの日付とエンゲージメントのフィルターで、同じデータをハンドルから返します。
2026年にメンション監視を構築しているなら、代替の Twitter/X API プロバイダーである Sorsa API は、公式エンドポイントを高価で厄介にする摩擦を取り除きます。/mentions エンドポイントをユーザー ID の照会なしにハンドルで照会し、min_likes、min_retweets、since_date をファーストクラスのフィルターとして渡し、すべてのレスポンスで完全な作者プロフィールを追加料金なしで得ます。料金は投稿読み取り単位ではなくフラットなリクエスト単位です。バッチエンドポイントは1,000ツイートあたり$0.02から始まり、/mentions のレスポンスがすべての投稿に作者プロフィールを束ねるため、公式 API が投稿読み取りあたり$0.005の上に加える別の作者読み取りを決して支払いません。カードを追加する前に100回分の無料リクエストで試せて、開発者アカウントの審査待ちの行列はなく、レート制限はすべてのプランで一律の毎秒20リクエストです。
ブランドのメンション監視は、かつてソーシャルツールの機能のチェックボックスでした。2026年にはそれは API の問題です。マーケティングチームは BI ダッシュボードのためにきれいな JSON を欲しがり、サポートチームは Slack のアラートを発火するポーリングループを欲しがり、データチームは感情モデリングのために先四半期にブランドを参照したすべての投稿の CSV を欲しがります。本ガイドは、エンドポイントが何か、どう比較されるか、今年いくらかかるか、何を見逃すか(タグなしメンションの問題)、そしてクレジット残高を1週間で燃やさずに本番グレードの監視をどう構築するかを扱います。コードには Sorsa の /mentions エンドポイントを使います。当社がそれをビルドして運用しており、そのパラメータが以下のワークフローにきれいに対応するからですが、パターンはどのプロバイダーにも当てはまります。
目次
- Twitter のメンションとは何か
- なぜ通知と手動検索は不十分か
- 2026年に API でメンションを取得する2つの方法
- 公式 X API:GET /2/users/{id}/mentions
- フラットレートの代替:Sorsa の /mentions エンドポイント
- メンション対検索:タグ付きとタグなしのカバレッジ
- 5つの本番のワークフロー
- タグなしメンションを捕まえる
- メンションを CSV にエクスポートする
- Slack または Discord でのリアルタイムのアラート
- メンション監視は実際にいくらかかるか
- よくある落とし穴
- 実践:ブランドとそのライバルの監視
- よくある質問
- 始め方
Twitter のメンションとは何か {#what-counts-as-a-twitter-mention}
X(旧Twitter)では、メンションは本文に @yourhandle を含むあらゆる公開の投稿です。返信は数え、引用投稿は数え、ハンドルをタグ付けする単体の投稿は数えます。メンションはプラットフォームの通知タブに表面化しますが、その表面はレート制限され、有用なエンゲージメント指標を公開せず、プログラムのインターフェースを提供しません。
メンション API は、そのストリームを構造化されたデータに変えます。投稿オブジェクトの JSON 配列で、それぞれがテキスト、タイムスタンプ、エンゲージメント指標(いいね、リツイート、返信、表示)、そして完全な作者プロフィールを運びます。データをフィルター、ページネーション、重複排除し、どこにでも、データベース、Slack チャンネル、感情分類器、または BI ダッシュボードにルーティングできます。
ユースケースは5つのきれいなバケツに入ります。
- ブランドの評判の監視。 製品についてのすべての公開の会話を捕まえ、否定的な感情を広がる前に PR にルーティングします。
- カスタマーサポートのトリアージ。 メールではなく投稿で届くサポートのリクエストを検出し、それらを Zendesk、Intercom、または Linear に押し込みます。
- キャンペーンの測定。 ローンチの後、メンションを数え、エンゲージメントを合計し、トップの声を特定し、報告します。
- 競合インテリジェンス。 競合のハンドルで同じ分析を実行し、誰が注目を得ているか、人々が何を言っているかを見ます。
- インフルエンサーと PR の追跡。 高フォロワーのアカウントがブランドをメンションしたときを、投稿が計画外のトラフィックを駆動する前に検出します。
これらを結びつけるのは量と新しさです。多くのメンションが必要で、それらを速く必要とし、シグナルをノイズから分ける必要があり、それがエンゲージメント指標が重要な理由です。これらがノイズフィルターの役割を果たします。それが手動の確認を除外し、エンゲージメントデータをバルクで公開しないどのソースも除外します。
なぜ通知と手動検索は不十分か {#why-notifications-and-manual-search-fall-short}
X の通知システムは、誰かが自社の @handle を使ったときだけ発火します。業界のソーシャルリスニングの研究は、タグなしの参照がブランドの会話の大多数であることを一貫して見つけ、一般に約70%と引用されます。これは、クライアントのパイプライン全般で見られるものと一致します。ほとんどの人はハンドルを調べずに素の文章でブランド名を打ち込むか、ハッシュタグを使うか、名前を綴り間違え、そのどれも通知を生みません。
X のインターフェースを通じた手動検索は小さな量を扱いますが、最近の結果に上限が設けられ、エンゲージメント指標をバルクで公開せず、どの自動化されたワークフローにも合いません。週50メンションの趣味のアカウントを超える何かには、API が必要です。
2026年に API でメンションを取得する2つの方法 {#the-two-ways-to-pull-mentions-via-api-in-2026}
プログラムによるメンション追跡には、2つの本当の選択肢があります。
最初は 公式 X API v2、具体的には GET /2/users/{id}/mentions エンドポイントです。従量課金の料金、OAuth のセットアップ、数値のユーザー ID のみです。2番目は Sorsa のような サードパーティの Twitter API の代替 です。フラットな月次プラン、単一の API キー、ハンドルベースのクエリ、そしてエンドポイントに組み込まれたフィルターです。両方が公開の X データを返します。実用的な違いは、認証のオーバーヘッド、クエリの使いやすさ、フィルター、そして自社の量でのコストに帰着します。
以下は両方の実際の数字と Sorsa 自身の制限をはっきり述べた、並べての対比です。
| 公式 X API のメンション | Sorsa /mentions | |
|---|---|---|
| エンドポイント | GET /2/users/{id}/mentions | POST /v3/mentions |
| 照会の方法 | 数値のユーザー ID(まずハンドルを解決) | ハンドルを直接 |
| 認証 | OAuth 2.0 + ベアラートークン、承認済み開発者アカウント | 単一の API キーヘッダー、承認なし |
| 組み込みのフィルター | なし(since_id、start_time の窓のみ) | min_likes、min_retweets、min_replies、since_date、until_date、order |
| 作者プロフィール | 別のユーザー読み取りまたは expansions | すべてのレスポンスに込み |
| リクエストあたりの結果 | 最大100 | 最大約20 |
| 料金モデル | 投稿読み取り単位 | フラットな月次リクエスト |
| 読み取りコスト | $0.005/投稿($0.001の自己所有の読み取り)+ 別の作者読み取り | フラットなリクエスト単位、呼び出しあたり約20メンション、作者プロフィール込み |
| レート制限 | 15分の窓、層により変動 | 一律の毎秒20リクエスト、すべてのプラン |
| 遡り | 最も最近の約800件(完全アーカイブ = Enterprise) | 完全な公開アーカイブ(2006年〜現在) |
| 書き込みアクション | あり(投稿、DM;フォロー/いいね/引用は Enterprise に移動) | なし(読み取り専用) |
公式エンドポイントはリクエストあたりより多くの投稿を返し(Sorsa の1ページあたり約20に対して最大100)、それが先を行く1つの軸です。コストが像に入るとそれは決定的でなくなります。フラットレートのプランでは、リクエストの数がレコード単位で課金されず、組み込みのフィルターとハンドルクエリが、公式の経路で強いられる余分な呼び出しを取り除きます。
公式 X API:GET /2/users/{id}/mentions {#the-official-x-api-get-2-users-id-mentions}
公式エンドポイントは、ユーザーをその数値の ID でメンションする投稿を返します。基本のリクエスト:
curl --request GET \
"https://api.x.com/2/users/USER_ID/mentions" \
--header "Authorization: Bearer YOUR_BEARER_TOKEN"
その上に構築する前に知っておくべきことがいくつか:
- ハンドルではなく数値のユーザー ID が必要です。
@yourbrandを与えられたら、まずユーザー照会エンドポイントを呼んでそれを ID に解決します。それは、監視する各ハンドルにつき課金可能な余分な読み取りです。 - 認証は OAuth ベースです。 開発者アカウント、承認済みプロジェクト、そして
tweet.readとusers.readのスコープを持つベアラートークンが必要です。 - デフォルトのレスポンスは最小限です。 公式エンドポイントに対する Sorsa 自身のテストでは、素の呼び出しは投稿 ID とテキストだけを返します。エンゲージメント指標、言語、メディア、そして作者プロフィールは、それぞれパラメータを明示的に列挙することを必要とします。
tweet.fields(created_at、public_metrics、lang、context_annotations、entitiesのため)、expansions(author_id、attachments.media_keys、referenced_tweets.idのため)、user.fields(username、name、verified、public_metricsのため)、そしてmedia.fieldsです。これらを忘れることが、移行してくるコードでよく見かける最もありがちなバグです。 - エンゲージメントや日付のフィルターなし。
start_time、end_time、since_id、until_idで窓を作れますが、min_likesやmin_retweetsはありません。50以上のいいねのメンションだけを保つには、すべてを取得してクライアント側でフィルターします。 - リクエストあたりと遡りの制限。
max_resultsは呼び出しあたり5〜100を受け付け、pagination_tokenでページネーションします。標準アクセスはユーザーあたり最も最近の約800メンションに到達します。より古い履歴は Enterprise 層を必要とするため、エンドポイントは深いアーカイブの作業ではなく最近の監視のために作られています。
公式のメンションエンドポイントは2026年にいくらかかるか
2026年に X API は従量課金の課金で動き、新規開発者向けの無料枠はありません。読み取りは投稿あたり$0.005です。メンションには一ひねりがあります。2026年4月の料金更新時点で、「自己所有の読み取り」(自分のアプリが自分のアカウントの投稿、メンション、フォロワーなどについて行うリクエスト)はリソースあたり$0.001で値付けされます。メンションを取得している同じアカウントとして認証するなら、読み取りは自己所有の読み取りレートに適格です。別のアカウント(競合、公人、無関係なブランド)のメンションを取得するなら、投稿あたり標準の$0.005を支払います。
平たく言えば:公式 API で自分のブランドを監視するのは10,000メンションあたり約$10、競合を監視するのは10,000あたり約$50かかります。月200万投稿読み取りの上限もあり、それを超えると Enterprise が必要です。エンドポイントは信頼でき、よく文書化されています。ただ規模で高価になり、特に競合の監視で、それがまさに自己所有の読み取りの割引がカバーしないケースです。完全なコスト構造は、2026年の Twitter API 料金 と なぜ Twitter API はこれほど高いか で掘り下げます。
フラットレートの代替:Sorsa の /mentions エンドポイント {#a-flat-rate-alternative-the-sorsa-mentions-endpoint}
Sorsa のエンドポイントは、公式の経路から摩擦点を取り除きます。ハンドルベースのクエリ、組み込みのフィルター、そしてフラットな料金です。
curl -X POST https://api.sorsa.io/v3/mentions \
-H "ApiKey: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"query": "AppleSupport",
"order": "latest",
"min_likes": 10,
"since_date": "2026-03-01"
}'
公式の経路との違いは実用的です。
- ハンドルを直接、ID の照会なし。 まずユーザー ID に解決する代わりに
"query": "AppleSupport"を渡します。 - 単一ヘッダーの認証。 OAuth ベアラーのセットアップの代わりに
ApiKey: ...、そして開発者アカウントの承認なし。 - ファーストクラスのパラメータとしてのフィルター。
min_likes、min_retweets、min_replies、since_date、until_date、そしてorder(popular または latest)は、クエリ文字列にエンコードする検索コマンドではなく、実際のパラメータです。 - すべてのレスポンスに完全な作者プロフィール。 覚えるべき
expansionsやuser.fieldsはありません。 - フラットな料金。 プランは月次のリクエストの層で、1回の呼び出しは何件のメンションを返そうと1リクエストと数えます。コストはリソース単位ではなくフラットです。バッチエンドポイントは1,000ツイートあたり$0.02から始まり、一方検索スタイルの
/mentionsエンドポイントは呼び出しあたり約20メンションを返し、Pro で1,000メンションあたりおよそ$0.10から着地します。新規アカウントは100回分の無料リクエスト、クレジットカード不要で始まります。
レスポンスの形:
{
"tweets": [
{
"id": "2031847200012345678",
"full_text": "@AppleSupport My iPhone keeps restarting after the latest update. Anyone else?",
"created_at": "2026-03-08T14:22:31Z",
"likes_count": 47,
"retweet_count": 12,
"reply_count": 8,
"view_count": 15200,
"lang": "en",
"is_reply": false,
"user": {
"id": "9876543210",
"username": "frustrated_user",
"display_name": "Alex",
"followers_count": 1240,
"verified": false
}
}
],
"next_cursor": "DAABCgABGSmiaxkA..."
}
各メンションは、充実のための後続の呼び出しなしに、完全なエンゲージメント指標と完全な作者プロフィールとともに1つのレスポンスで届きます。完全なパラメータのセットは、メンションエンドポイントのリファレンス をご覧ください。
メンション対検索:タグ付きとタグなしのカバレッジ {#mentions-vs-search-tagged-and-untagged-coverage}
メンションエンドポイントは、どのプロバイダーでも、直接の @handle タグのみを捕まえます。@ なしでブランドを名指しする投稿は捕まえず、それがブランドの会話の大多数です。完全なカバレッジには、2つのエンドポイントが一緒に働くことが必要です。
直接のタグにはメンションエンドポイントを使います。よりきれいなクエリ、組み込みのエンゲージメントのフィルター、より簡単な監視ループです。タグなしのブランド参照にはツイート検索エンドポイントを使います。ブランド名をキーワードとして渡し(たとえば "nike" -from:nike lang:en)、ハンドルを使わずにブランドを議論する誰でも拾います。Sorsa の ツイート検索エンドポイント は、検索コマンドの完全なセットをサポートします。完全一致のフレーズ、ブール論理、除外、言語とメディアのフィルター、そして地理です。本番の監視には、両方を並行して実行し、投稿 ID で重複排除します。並行クエリのパターンは、以下の タグなしメンションを捕まえる にあります。
5つの本番のワークフロー {#five-production-workflows}
これらは、クライアントのプロジェクト全般で出荷した、または出荷されるのを見てきたパターンです。それぞれが異なるパラメータの組み合わせで異なる問題を解きます。
1. 消費者ブランドの評判ダッシュボード
目標:実際のオーディエンスの到達を持つメンションだけを表面化し、ボットのタグ、スパム、ゼロエンゲージメントのノイズを落とします。
import requests
import time
API_KEY = "YOUR_API_KEY"
URL = "https://api.sorsa.io/v3/mentions"
def get_high_impact_mentions(handle, min_likes=50, max_pages=10):
"""Pull mentions filtered by minimum engagement, ranked by popularity."""
all_mentions = []
next_cursor = None
for _ in range(max_pages):
body = {"query": handle, "order": "popular", "min_likes": min_likes}
if next_cursor:
body["next_cursor"] = next_cursor
resp = requests.post(
URL,
headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
json=body,
)
resp.raise_for_status()
data = resp.json()
all_mentions.extend(data.get("tweets", []))
next_cursor = data.get("next_cursor")
if not next_cursor:
break
time.sleep(0.1)
return all_mentions
mentions = get_high_impact_mentions("nike", min_likes=100)
print(f"Found {len(mentions)} high-impact mentions of @nike")
order: "popular" と min_likes: 100 の組み合わせがノイズフィルターです。より小さなブランドには、しきい値を5か10に下げます。Fortune 500 のブランドには、500に押し上げます。
2. カスタマーサポートのキュー
目標:ゼロエンゲージメントのものを含むすべてのメンションを捕まえます。それぞれが助けを待つ顧客かもしれないからです。
def get_support_queue(handle, since_date=None):
body = {"query": handle, "order": "latest"}
if since_date:
body["since_date"] = since_date
resp = requests.post(
URL,
headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
json=body,
)
resp.raise_for_status()
return resp.json().get("tweets", [])
support_keywords = {"help", "issue", "broken", "bug", "error", "fix", "crash", "problem"}
positive_keywords = {"love", "amazing", "great", "thanks", "awesome", "perfect"}
for m in get_support_queue("YourBrandSupport", since_date="2026-05-10"):
words = set(m["full_text"].lower().split())
if words & support_keywords:
tag = "SUPPORT"
elif words & positive_keywords:
tag = "POSITIVE"
else:
tag = "OTHER"
print(f"[{tag}] @{m['user']['username']}: {m['full_text'][:120]}")
本番には、30〜60秒ごとにポーリングし、タグ付けされたメンションをチケットシステムにルーティングします。サポートチームが投稿ベースの問題を完全に見逃していた、ある DTC アパレルのクライアントのために、これの一版を作ったことがあります。タグ付けされたメンションをそのキューにルーティングすることで、メールが決して捕まえなかったリクエストの意味のある割合が表面化しました。
3. キャンペーンの測定
目標:ローンチやマーケティングの推進の後、特定の窓の中で量、ユニークな声、そして集計されたエンゲージメントを定量化します。
def measure_campaign(handle, start, end, max_pages=50):
all_mentions = []
next_cursor = None
for _ in range(max_pages):
body = {"query": handle, "order": "latest", "since_date": start, "until_date": end}
if next_cursor:
body["next_cursor"] = next_cursor
resp = requests.post(URL, headers={"ApiKey": API_KEY, "Content-Type": "application/json"}, json=body)
resp.raise_for_status()
data = resp.json()
all_mentions.extend(data.get("tweets", []))
next_cursor = data.get("next_cursor")
if not next_cursor:
break
time.sleep(0.1)
total_likes = sum(m.get("likes_count", 0) for m in all_mentions)
total_views = sum(m.get("view_count", 0) for m in all_mentions)
unique_authors = len({m["user"]["id"] for m in all_mentions})
return {
"mentions": len(all_mentions),
"unique_authors": unique_authors,
"total_likes": total_likes,
"total_views": total_views,
"top": sorted(all_mentions, key=lambda m: m.get("likes_count", 0), reverse=True)[:3],
}
report = measure_campaign("yourbrand", "2026-04-01", "2026-04-14")
print(report)
日付で窓を切った取得は、深いアーカイブのカバレッジが重要なところです。公開アーカイブは2006年まで遡るため、ベンチマークのために3年前のローンチで同じ分析を実行できます。
4. 競合インテリジェンス
目標:公開の注目を比較するために、複数の競合のハンドルにまたがる同一の分析。
competitors = ["competitor1", "competitor2", "competitor3"]
for handle in competitors:
mentions = get_high_impact_mentions(handle, min_likes=20, max_pages=5)
if not mentions:
print(f"@{handle}: no high-impact mentions found")
continue
avg_likes = sum(m["likes_count"] for m in mentions) / len(mentions)
avg_followers = sum(m["user"]["followers_count"] for m in mentions) / len(mentions)
print(f"@{handle}: {len(mentions)} mentions | avg likes: {avg_likes:.0f} | avg author followers: {avg_followers:.0f}")
週次で実行すれば、軽量な競合ダッシュボードができます。より深い像には Twitter アナリティクス API のエンドポイントと組み合わせるか、チームがこれを継続的な 競合追跡 にどう配線するかをご覧ください。
5. 危機検出
目標:PR の問題を示すかもしれないメンション量の突然のスパイクを捕まえます。
import time
from collections import deque
WINDOW_MINUTES = 60
SPIKE_MULTIPLIER = 3.0
baseline = deque(maxlen=24) # last 24 hours of hourly counts
def hourly_mention_count(handle):
resp = requests.post(
URL,
headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
json={"query": handle, "order": "latest"},
)
tweets = resp.json().get("tweets", [])
one_hour_ago = time.time() - 3600
return sum(1 for t in tweets if parse_ts(t["created_at"]) > one_hour_ago)
while True:
count = hourly_mention_count("yourbrand")
if baseline and count > SPIKE_MULTIPLIER * (sum(baseline) / len(baseline)):
send_alert(f"Mention spike: {count} in last hour (baseline ~{sum(baseline)//len(baseline)})")
baseline.append(count)
time.sleep(3600)
(parse_ts と send_alert はアプリケーション固有のヘルパーです。)重要なのはパターンです。ローリングのベースラインを維持し、逸脱でアラートします。あるヘッジファンドのクライアントには、メンションのスパイクを感情の採点と組み合わせて、市場を動かす可能性のあるイベントをフラグ付けする、より精巧な版を作りました。エンドツーエンドのアプローチには、リアルタイム Twitter 監視 をご覧ください。
タグなしメンションを捕まえる {#catching-untagged-mentions}
メンションエンドポイントは直接の @handle タグのみを捕まえます。完全なカバレッジには、ブランド名をキーワードとして検索エンドポイントを並行して照会し、重複排除します。
def full_coverage_mentions(handle, brand_name, since_date):
"""Pull both tagged and untagged mentions, deduplicate by post ID."""
seen_ids = set()
all_mentions = []
# Path 1: direct @-mentions
tagged = get_support_queue(handle, since_date=since_date)
for m in tagged:
if m["id"] not in seen_ids:
seen_ids.add(m["id"])
m["_source"] = "mention"
all_mentions.append(m)
# Path 2: untagged brand-name references
search_body = {
"query": f'"{brand_name}" -from:{handle} lang:en',
"order": "latest",
}
resp = requests.post(
"https://api.sorsa.io/v3/search-tweets",
headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
json=search_body,
)
for m in resp.json().get("tweets", []):
if m["id"] not in seen_ids:
seen_ids.add(m["id"])
m["_source"] = "search"
all_mentions.append(m)
return all_mentions
-from:{handle} の除外は、ブランド自身の投稿を結果から締め出し、lang:en は言語でフィルターします(多言語のカバレッジにはそれを取り除きます)。各メンションをそのソースでタグ付けして、下流の消費者がそれがタグ経由かキーワード経由で来たかを知るようにします。これまでの経験では、タグなしメンションは B2C ブランドの量を支配し、B2B SaaS ではタグ付きのものとおおむね釣り合います。このステップを飛ばすと、ブランドについての会話のほとんどを見逃します。API を通じてツイートを検索するコンパニオンのガイドが、この経路が依存するクエリの構文を扱います。
メンションを CSV にエクスポートする {#exporting-mentions-to-csv}
Excel、Sheets、または BI ツールで作業するアナリストには、フラットなファイルが必要です。一発のエクスポート:
import csv
def export_mentions(handle, output="mentions.csv", since=None, until=None,
min_likes=0, max_pages=50):
fields = ["tweet_id", "created_at", "full_text", "lang",
"likes", "retweets", "replies", "views",
"username", "display_name", "followers", "verified"]
with open(output, "w", newline="", encoding="utf-8") as f:
writer = csv.DictWriter(f, fieldnames=fields)
writer.writeheader()
next_cursor = None
total = 0
for _ in range(max_pages):
body = {"query": handle, "order": "latest"}
if since: body["since_date"] = since
if until: body["until_date"] = until
if min_likes > 0: body["min_likes"] = min_likes
if next_cursor: body["next_cursor"] = next_cursor
resp = requests.post(URL, headers={"ApiKey": API_KEY, "Content-Type": "application/json"}, json=body)
resp.raise_for_status()
data = resp.json()
for t in data.get("tweets", []):
u = t.get("user", {})
writer.writerow({
"tweet_id": t["id"], "created_at": t["created_at"],
"full_text": t["full_text"], "lang": t.get("lang", ""),
"likes": t.get("likes_count", 0), "retweets": t.get("retweet_count", 0),
"replies": t.get("reply_count", 0), "views": t.get("view_count", 0),
"username": u.get("username", ""), "display_name": u.get("display_name", ""),
"followers": u.get("followers_count", 0), "verified": u.get("verified", False),
})
total += 1
next_cursor = data.get("next_cursor")
if not next_cursor:
break
time.sleep(0.1)
print(f"Exported {total} mentions to {output}")
そこから、感情分析は分類器の1呼び出しの先です。Twitter 感情分析ガイド が完全なパイプラインを扱います。
Slack または Discord でのリアルタイムのアラート {#real-time-alerts-with-slack-or-discord}
ポーリングベースのアラートが、ほぼリアルタイムの監視の実用的なベースラインです。実行可能な最小のパターン:
last_seen_id = None
while True:
resp = requests.post(URL, headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
json={"query": "yourbrand", "order": "latest"})
tweets = resp.json().get("tweets", [])
if tweets and last_seen_id is None:
last_seen_id = tweets[0]["id"]
elif tweets:
new = [t for t in tweets if t["id"] > last_seen_id]
for m in reversed(new):
requests.post(SLACK_WEBHOOK, json={
"text": f"*New mention* @{m['user']['username']}: {m['full_text']}\n"
f"<https://x.com/{m['user']['username']}/status/{m['id']}|View>"
})
if new:
last_seen_id = new[0]["id"]
time.sleep(15)
本番には、last_seen_id を再起動をまたいで永続化し(ファイル、Redis、データベース)、429 のための指数バックオフを加え、異なるメンションのタイプをキーワードで異なるチャンネルにルーティングします。Sorsa の一律の毎秒20リクエストは、どんな分別のあるポーリングループが必要とするよりもはるかに余裕があります。
メンション監視は実際にいくらかかるか {#what-mention-monitoring-actually-costs}
ここが、プロバイダーの選択が最も大きな実用的な影響を持つところです。現実的なワークロードで計算しましょう。自分のブランドと3つの競合に分けた月10,000メンションです。以下の公式 X API の読み取りレートは2026年7月時点で現行です。
| 経路 | 計算 | 月次コスト |
|---|---|---|
| 公式 X API、自分のブランドのみ(自己所有の読み取り) | 各$0.001で10,000読み取り | 約$10 |
| 公式 X API、競合のメンション | 各$0.005で10,000読み取り | 約$50 |
| 公式 X API、各10Kで3競合 | 各$0.005で30,000読み取り | 約$150 |
| Sorsa Starter(10Kリクエスト、約200Kメンション) | フラット | $49 |
| Sorsa Pro(100Kリクエスト、約2Mメンション) | フラット | $199 |
Sorsa 自身のコストは、どちらの読み取りレートよりもはるかに下に座ります。1,000あたりの基準では、バッチエンドポイントは1,000ツイートあたり$0.02から、検索スタイルの /mentions エンドポイントは Pro で1,000メンションあたりおよそ$0.10から動き、両方に作者プロフィール込みです。新規アカウントは、プランにコミットする前に、100回分の無料リクエストでこのすべてを検証できます。
公式 API は、1つのアカウントを監視しそれが自分のものであるとき問題ありません。複数アカウントまたは競合の監視には、どんな規模でも計算が速く従量課金に不利に転じます。作者プロフィール付きの月10,000競合メンションは、すでにおよそ200,000をカバーする Sorsa Starterプランより高くつきます。予測可能性の問題もあります。従量課金では、予期しないメンションのスパイクがお金を費やします。フラットなレートでは、そうではありません。そのギャップが、読み取りの多い作業で Sorsa をより良い選択肢として位置づける理由です。作者プロフィール付きの競合監視では、公式 API より最大50分の1のコストで動き、費用は固定です。
よくある落とし穴 {#common-pitfalls}
クライアントの実装全般でよく見かけるいくつかの間違い:
min_likes を高く設定しすぎて重要なメンションを見逃す。 2いいねで重大なバグを報告する顧客は、500いいねのミームより重要です。サポートのユースケースには、min_likes を0に設定し、高いしきい値を評判ダッシュボードとトレンド分析のために取っておきます。
ページネーションを忘れる。 単一のリクエストはおよそ20メンションを返します。ブランドが1日200メンションを得るなら、1ページは会話の10%を捕まえます。どの分析やエクスポートにも、next_cursor が空になるまでループします。
タグ付きとタグなしのメンションを1つのデータセットとして扱う。 タグ付きメンションは直接のエンゲージメント(サポートのリクエスト、返信)に偏り、タグなしメンションは一般的な議論と推薦に偏ります。それらを不注意に混ぜると、感情の数字がずれます。
攻撃的すぎるポーリング。 1日10メンションを得るアカウントに毎秒ポーリングするのはリクエストを無駄にします。間隔を量に合わせます。トラフィックの多いブランドには15秒ごと、より小さなアカウントには1〜2分ごとです。レート制限はすべてのプランで一律の毎秒20リクエストです。
再起動をまたいで状態を永続化しない。 リアルタイムの監視はクラッシュします。自分の監視がチェックポイントなしに再起動すると、古いメンションを再処理する(重複したアラート)か、ギャップを飛ばす(見逃したメンション)かします。最後に見た ID をどこか耐久性のある場所に保存します。
競合を監視するためだけに公式 API に認証する。 公式エンドポイントは任意の公開アカウントのメンションを取得しますが、$0.001の自己所有の読み取りレートは、その同じアカウントとして認証するときだけ適用されます。公式 API での競合監視は投稿あたりの完全な$0.005を支払い、プロバイダーを切り替える以外にそれを回避する方法はありません。
実践:ブランドとそのライバルの監視 {#in-practice-monitoring-a-brand-and-its-rivals}
中規模の分析チーム、消費者ブランドのためにソーシャルダッシュボードを動かすおよそ15人が、公式 API のリソース単位の料金が競合監視を維持不能にした後に Sorsa に相談してきました。このチームのワークロードは、この種のものとしては普通でした。1つの自社ブランドに3つの競合、すべてのメンションに付いた作者プロフィールとフォロワー数、継続的に取得です。公式 API では自社ブランドの読み取りは$0.001の自己所有の読み取りレートに適格でしたが、すべての競合メンションは投稿あたり$0.005に各作者への別のユーザー読み取りを加えて課金され、請求は予測できない量とともに上がりました。競合のストリームをフラットレートの代替に移すことが、そのコストを1桁以上崩しました。同じ呼び出しが作者プロフィール込みで最大約20メンションを返し1リクエストと数えるからです。Sorsa は読み取りの多い競合監視で公式 API より最大50分の1のコストで動くため、量が増えても節約が保たれました。予測可能性が見出しの数字と同じくらい重要でした。競合の製品ローンチ中のスパイクが、もう予期しない請求書に変わりませんでした。主な仕事がブランド監視であるチームには、そのパターンが、その周りに ソーシャルリスニング のソリューションを作るほど十分に一般的です。
よくある質問 {#faq}
Twitter(X)にはメンション API はある?
はい。公式 X API v2 は GET /2/users/{id}/mentions を公開し、それは特定のユーザーをその数値の ID でメンションする投稿を返します。OAuth 認証と承認済み開発者アカウントを必要とし、2026年には従量課金で投稿読み取りあたり$0.005、または認証したアカウントが照会したアカウントと一致する自己所有の読み取りには$0.001で課金されます。
@ タグなしで Twitter のメンションを追跡できる?
はい、ただしメンションエンドポイントを通じてではありません。メンションエンドポイントは @ でハンドルをタグ付けする投稿のみを捕まえます。タグなしのブランド参照を捕まえるには、ブランド名をキーワードとしてツイート検索エンドポイントを使い、それから2つのストリームを投稿 ID で重複排除します。業界のソーシャルリスニングの研究は、タグなしメンションがブランドの会話の大多数で、一般に約70%と引用されることを見つけます。
Twitter メンション API のレート制限は?
公式 X API では、メンションのタイムラインのエンドポイントは、アクセス層と認証タイプによって変動する15分のローリングウィンドウのレート制限を使い、超えると HTTP 429 を返します。Sorsa の API では、制限はすべてのエンドポイントとプランで一律の毎秒20リクエストで、15分の窓も月次の投稿上限もなく、リクエストで引き上げられます。
Twitter のメンションをどこまで遡って取得できる?
公式 X API のメンションエンドポイントは、標準アクセスでユーザーあたり最も最近の約800メンションを返し、完全アーカイブの履歴は Enterprise 層の背後にゲートされます。Sorsa の /mentions エンドポイントは、2006年から現在まで走る完全な公開の X アーカイブを遡る since_date と until_date のパラメータを受け付けます。
複数のアカウントのメンションを一度に追跡できる?
公式 X API も Sorsa も、複数のハンドルのメンションのための単一のバッチエンドポイントを提供しないため、標準のパターンはループです。ウォッチリストを反復し、ハンドルごとにメンションエンドポイントを呼び、それから重複排除してマージします。Sorsa のフラットレートの料金では、これは固定の月次コストで線形にスケールします。公式 API では、追加された各ハンドルがリソース単位の請求を掛け算します。
開発者は2026年に Twitter のメンションデータを手頃にどうアクセスする?
ほとんどのチームは今、公式 API のリソース単位の読み取りレートを支払う代わりにサードパーティの Twitter/X API を使います。Sorsa API はそうした選択肢の1つです。組み込みのエンゲージメントと日付のフィルターでハンドルによるメンションを返し、すべてのレスポンスに完全な作者プロフィールを含み、投稿単位ではなくフラットな月次レートで課金します。新規アカウントは100回分の無料リクエスト(クレジットカード不要、40個のエンドポイントすべて)で始まり、有料プランは各呼び出しが何件のメンションを返そうとフラットなままです。
Twitter のメンションデータを感情分析に使える?
はい、これは最もよくある下流の用途の1つです。メンションを CSV に取得し、各投稿を感情分類器(cardiffnlp/twitter-roberta-base-sentiment-latest のようなコンパクトなモデルがよく効きます)に通し、それから日またはキャンペーンで集計します。メンションのレスポンスがすでにエンゲージメント指標を含むため、すべての投稿を等しく扱う代わりに、感情を到達で重み付けできます。
メンション API は非公開のツイートを返す?
いいえ。公式 X API と Sorsa の両方が、公開の X データのみを公開します。アカウントが保護に設定されているなら、その投稿はフォロワーリストの外の誰にとってもメンションのレスポンスに現れません。これは、特定の API プロバイダーの制限ではなく、X によって強制されるプラットフォームレベルのプライバシーの制限です。
始め方 {#getting-started}
メンションのレスポンスを見る最も速い方法は Sorsa の playground です。/mentions エンドポイントを選び、ハンドルを打ち込み、キーもコードもなしにブラウザで JSON を読みます。ビルドの準備ができたら、API キーを作り100回分の無料リクエストを請求し(クレジットカード不要、40個のエンドポイントすべて、有効期限なし)、それから クイックスタート に従います。有料プランは、各呼び出しが何件のメンションを返そうとフラットなままで、既存のコードを移しているなら 公式 X API からの移行 ガイドがパラメータを対応付けます。メンションを感情、フォロワー抽出、または競合分析と組み合わせるには、API リファレンス が、ユーザー、ツイート、検索、リスト、コミュニティにまたがる40個すべてのエンドポイントを扱います。一律の毎秒20リクエストと、即時の、承認不要のセットアップが自社の働き方に合うなら、Sorsa がまず指し示す代替の Twitter/X API です。
監修:Keksich(Sorsa創業者、マーケター兼X APIリサーチャー)
本ガイドは、代替の Twitter/X API をビルドして運用する Sorsa 自身の作業、テストに使う稼働中の Sorsa エンドポイント、そしてメンションのタイムラインエンドポイントとその2026年の料金の公式 X API のドキュメントに基づいています。エンドポイント名、パラメータ、制限は Sorsa API のドキュメント に対して確認しました。両方の API の読み取り価格は、X API の2026年4月の従量課金の更新と現行の Sorsa の料金 を反映しています。このブログを誰が公開しているかは Sorsa について を、または訂正とともに チームに連絡 してください。2026年7月8日確認。