【2026年版】Twitter トレンド API：トレンドのトピックを取得する

著者：Sorsa Editorial

2026年7月8日更新：100回分の無料リクエストの開始枠を追加し、現行のリクエスト単位の料金を公式の従量課金のトレンドのレートに対して刷新し、エンドポイントのデフォルトの結果件数と、しばしば空のツイート数のフィールドを再確認しました。

要点： 2026年に API を通じて Twitter（X）のトレンドのトピックを取得するには、WOEID、つまり場所の数値の Where On Earth IDentifier を伴う認証済みの GET リクエストを送ります。公式 X API はこれを有料の層で Bearer トークンを使って GET /2/trends/by/woeid/{woeid} で提供し、世界中のおよそ470のトレンドの場所をカバーします。

Twitter トレンド API は、OAuth、アプリ審査の列、または5桁の契約を意味する必要はありません。代替の Twitter/X API である Sorsa API は、1つの API キーで認証される単一の /trends 呼び出しを通じて、同じ WOEID ベースのトレンドを返します。各トレンドは、すぐに実行できる検索クエリと直接の URL とすでに組み合わされて返り、課金はリクエスト単位でフラットです。1回のトレンド取得は Proプラン（10万リクエストで$199）で約$0.002で、同じ20トレンドを各$0.010で読む公式 API のおよそ$0.20に対してです。レート制限はすべてのプランで一律の毎秒20リクエストで、15分の窓はありません。

トレンドのトピックは、何百万もの人々が今この瞬間に何に注目しているかを示す、オープンウェブ上の数少ないリアルタイムのシグナルの1つです。マーケティングチームはそれらをキャンペーンのタイミングに使い、報道機関は速報を見つけるために使い、クオンツのデスクは早期のシグナルのレイヤーとして扱います。2026年の難しい部分はユースケースであることはめったにありません。データをきれいに取り出すことです。公式の経路が、ほとんどのチュートリアルが認めるよりも断片化していて高価だからです。

本ガイドは、今日実際に利用できるものをカバーします。WOEID ベースの取得がどう動くか、公式 X API v2 のトレンドのエンドポイントがどう振る舞うか（どこで足りないかを含む）、1つの API キーでトレンドを引く方法、そして Python、Node.js、curl の動くコードです。ほとんどの既存のチュートリアルは、いまだに廃止された v1.1 のエンドポイントと Tweepy の OAuth 1.0a のフローを参照しており、それはもはやトレンドには当てはまりません。

目次

1. Twitter トレンド API とは？
2. 2026年にコードで X のトレンドを取得する2つの方法
3. WOEID の仕組み（そしてなぜすべてのトレンド呼び出しがそれを必要とするか）
4. Sorsa API でトレンドのトピックを取得する
5. WOEID リファレンス：主要な国と都市
6. コード例：Python、Node.js、curl
7. より深い分析のためにトレンドと検索を組み合わせる
8. 公式 X トレンドエンドポイントのよくある問題
9. トレンドデータのユースケース
10. レート制限、キャッシュ、ベストプラクティス
11. 実践：報道機関のデスクのためのトレンドポーリング
12. よくある質問
13. 始め方

Twitter トレンド API とは？ {#what-is-the-twitter-trends-api}

Twitter トレンド API は、特定の地理的なエリアについて、X（旧Twitter）で現在トレンドになっているトピックを返す HTTP エンドポイントです。典型的な応答は、1つの場所についてのおよそ20〜50のトピックのランク付けされたリストで、プラットフォームによって数分ごとに再計算されます。この方法でアクセスされるトレンドは、パーソナライズされたものではなく、場所でスコープされます。

その区別は重要です。X のウェブサイトのパーソナライズされたトレンド（「Trends for you」）のビューは、ユーザーがフォローするアカウントとその活動を混ぜ込み、どの API を通じても公開されていません。API が返すのは、X が地域について計算するプラットフォーム全体の、場所でスコープされたリストで、それがまさに分析、監視、そして研究に欲しいものです。

リストは数分ごとに再計算されます。ほぼすべてのワークロードで、各場所を5〜15分ごとに1回ポーリングすれば、リクエストを無駄にせずに新しいエントリーが現れるたびに捕らえます。

2026年にコードで X のトレンドを取得する2つの方法 {#two-ways-to-get-x-trends-through-code-in-2026}

2026年にコードを通じて X のトレンドのトピックを取得する2つの実用的な経路が存在します。有料の層で OAuth 2.0 Bearer トークンで認証される公式 X API v2 のトレンドのエンドポイントと、同じ WOEID ベースのデータを1つの API キーの背後に包むサードパーティの REST API です。両方とも場所でスコープされたトレンドを返します。認証、料金、そして各トレンドオブジェクトが含むもので異なります。

選択肢1：公式 X API v2 のトレンドエンドポイント

X はそのトレンドのエンドポイントを GET /2/trends/by/woeid/{woeid} で公開します。WOEID をパスパラメータとして取り、トレンドオブジェクトのリストを返し、それぞれが trend_name と、trend.fields パラメータを通じてリクエストする省略可能な tweet_count を運びます。完全なリファレンスは X の公式のトレンドのドキュメントにあります。

認証は OAuth 2.0 Bearer トークンで、それは開発者アプリを登録して X API の有料の層に座ることを意味します。2026年にトレンドへの無料のアクセスはなく、プラットフォームは今ではリソース単位で読み取りを課金するため、返されるすべてのトレンドは別々に課金される単位です。その料金がどう働くかのより広い文脈は、2026年の X API 料金となぜ公式 API はそれほど高価かの分解をご覧ください。

トレンドのトピックからその背後の実際の投稿へ行くには、自分の検索クエリを構築し、検索エンドポイントを別々に呼びます。

選択肢2：1キーのトレンドエンドポイント

Sorsa のトレンドエンドポイントは、異なる優先順位を軸に作られています。トレンドデータをパイプラインのまさに次のステップで使えるものにすることです。応答はトレンド名に加えて、事前に構築された検索クエリと直接の URL を含むため、どのクエリ構築のコードも書かずにより深い分析にまっすぐ流れ込めます。

認証は ApiKey ヘッダーの1つの API キーです。OAuth のフロー、アプリの登録、そして開発者のレビューはありません。サインアップし、キーをコピーし、リクエストを送り、最初の100リクエストはクレジットカード不要で無料です。料金はトレンドを含むすべてのエンドポイントでリクエスト単位でフラットなので、1回のトレンドリストの取得は、1回のユーザー検索や1回の検索呼び出しと同じ料金です。

並べて比較：公式 X API のトレンド 対 Sorsa

特にトレンドの取得についての事実の比較で、各選択肢の本物の制限を平たく述べます。

数字から続くパターン：どの実際のポーリングの量でも、リクエスト単位のフラットな課金は、個々のトレンドすべてに支払うよりはるかに安く、1つの API キーが OAuth とアプリ審査のオーバーヘッドを取り除きます。正直な注意点は、どちらの選択肢も過去のトレンドを返さず、Sorsa のエンドポイントは各トレンドにツイート量の数字を付けないことです。次のセクションは両方の扱い方を示し、よくある問題のセクションが、そもそもなぜ公式の tweet_count が信頼できないかをカバーします。

WOEID の仕組み（そしてなぜすべてのトレンド呼び出しがそれを必要とするか） {#how-woeid-works-and-why-every-trends-call-needs-one}

WOEID（Where On Earth IDentifier）は、地理的な場所を一意にラベル付けする数値の ID です。Twitter は2010年頃にトレンドに WOEID を採用し、いまだに使っているため、すべてのトレンド API 呼び出しは、欲しい場所の WOEID を必要とします。世界、国、そして都市のレベルにまたがる、およそ470の有効なトレンドの WOEID があります。

いくつかの例が形を明確にします。

• 1 は世界全体（グローバルトレンド）
• 23424977 はアメリカ合衆国
• 23424975 はイギリス
• 23424900 はメキシコ
• 2459115 はニューヨーク市
• 44418 はロンドン

国レベルの ID は国全体をカバーし、一方町レベルの ID は単一の都市圏をカバーします。すべての国が町レベルのトレンドを持つわけではありません。より小さな市場はしばしば単一の国全体のリストだけを返します。地域ごとに異なる認証をせず、地域ごとの料金もありません。整数を知っていれば、そのトレンドを取得できます。

場所の WOEID を見つける方法

最もよくある市場には、下のリファレンス表を使います。トップの市場を超える何かには、X がサポートするトレンドの場所の完全なリストが、すべての有効なエントリーとともに GitHub の公開の WOEID gist として維持されています。Sorsa API は別々の「利用可能な場所」のエンドポイントを公開しないため、gist が正典のルックアップです。場所がそこになければ、X は API のレベルでその場所のトレンドデータを公表しません。

Sorsa API でトレンドのトピックを取得する {#getting-trending-topics-with-the-sorsa-api}

トレンドのエンドポイントは、単一のクエリパラメータ woeid を取り、トレンドオブジェクトのリストを返します。過去のモードもページネーションもありません。各呼び出しは、リクエストの瞬間の現在のリストを返します。

リクエスト：

GET https://api.sorsa.io/v3/trends?woeid=23424977
Header: ApiKey: YOUR_API_KEY

応答：

{
  "trends": [
    {
      "name": "#FedDecision",
      "query": "%23FedDecision",
      "url": "https://twitter.com/search?q=%23FedDecision"
    },
    {
      "name": "Powell",
      "query": "Powell",
      "url": "https://twitter.com/search?q=Powell"
    },
    {
      "name": "rate cut",
      "query": "%22rate+cut%22",
      "url": "https://twitter.com/search?q=%22rate+cut%22"
    }
  ]
}

各トレンドオブジェクトは3つのフィールドを持ちます。

• name：トレンドのトピックの人間が読めるラベル。これを UI に表示します。
• query：URL エンコードされた検索文字列。トレンドの背後の実際の投稿を取得するために、それを検索エンドポイントに渡します。
• url：X の検索結果ページへの直接のリンク。ダッシュボードやアラートでのクリック可能な参照に有用です。

過去の記録を構築するには、自分のスケジュールでポーリングし、各スナップショットを保存します。場所ごとに10〜15分ごとの実行を時系列のストアに書き込めば、数週間以内に使えるデータセットになります。完全なリクエストと応答の形はトレンドのエンドポイントのリファレンスに文書化され、クイックスタートガイドがキーの取得を案内します。

WOEID リファレンス：主要な国と都市 {#woeid-reference-top-countries-and-cities}

以下の表は、本番で最も頻繁に出てくる WOEID をカバーします。サポートされるすべての場所には、公開の WOEID gist を使います。

グローバル

国

主要都市

より小さな都市や地域の市場には、完全な WOEID gist を使います。

コード例：Python、Node.js、curl {#code-examples-python-nodejs-and-curl}

以下の3つの例はすべて同じエンドポイントを叩き、ApiKey ヘッダーの API キーだけを必要とします。

curl

curl -H "ApiKey: YOUR_API_KEY" \
  "https://api.sorsa.io/v3/trends?woeid=23424977"

Python

import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
headers = {"ApiKey": API_KEY}

# US trends (WOEID 23424977)
resp = requests.get(f"{BASE}/trends", headers=headers, params={"woeid": 23424977})
trends = resp.json()["trends"]

for t in trends[:10]:
    print(t["name"], "->", t["url"])

Node.js

const API_KEY = "YOUR_API_KEY";

async function getTrends(woeid) {
  const res = await fetch(`https://api.sorsa.io/v3/trends?woeid=${woeid}`, {
    headers: { ApiKey: API_KEY },
  });
  const { trends } = await res.json();
  return trends;
}

// US trends
getTrends(23424977).then((trends) => {
  trends.slice(0, 10).forEach((t) => console.log(t.name, t.url));
});

複数の地域を並行してポーリングする

複数の市場を一度に追跡するとき、ループではなくリクエストを並行して発火します。一律の毎秒20リクエストの制限が、ひと握りの地域を些細なものにします。

import asyncio
import aiohttp

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
WOEIDS = {"US": 23424977, "UK": 23424975, "Japan": 23424856, "Brazil": 23424768}

async def fetch_trends(session, name, woeid):
    url = f"{BASE}/trends"
    async with session.get(url, headers={"ApiKey": API_KEY}, params={"woeid": woeid}) as r:
        data = await r.json()
        return name, [t["name"] for t in data["trends"][:10]]

async def main():
    async with aiohttp.ClientSession() as session:
        tasks = [fetch_trends(session, n, w) for n, w in WOEIDS.items()]
        for name, tops in await asyncio.gather(*tasks):
            print(name, tops)

asyncio.run(main())

より深い分析のためにトレンドと検索を組み合わせる {#combining-trends-with-search-for-deeper-analysis}

トレンド名だけでは、あるフレーズが熱いと分かります。価値はその背後の投稿を引くことから来て、事前に構築された query フィールドが、それをクエリ構築の作業ではなく1回の追加の呼び出しに変えます。フィルターを手で作る必要があるときは、検索クエリビルダーが構文を組み立てます。query は URL エンコードされて届くため、プレーンテキストを期待する検索エンドポイントに渡す前にデコードします。

import requests
from urllib.parse import unquote_plus

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
headers = {"ApiKey": API_KEY}

# 1. Get current US trends
trends = requests.get(
    f"{BASE}/trends", headers=headers, params={"woeid": 23424977}
).json()["trends"]

# 2. For the top few trends, pull the posts driving each one
for trend in trends[:5]:
    body = {"query": unquote_plus(trend["query"]), "order": "popular"}
    posts = requests.post(f"{BASE}/search-tweets", headers=headers, json=body).json()["tweets"]
    print(trend["name"], "->", len(posts), "top posts")

ここから、それらの投稿のエンゲージメントでアカウントをランク付けし、感情を分類し、またはウォッチリストに一致する何かを Slack にルーティングできます。検索のステップは Twitter 検索 API ガイドで端から端までカバーされ、常時オンのバージョンがリアルタイム監視の案内で動きます。トレンドの取得と各検索の両方がフラットな単一のリクエストなので、トレンドから投稿へのパイプラインは高頻度でも安いままです。

公式 X トレンドエンドポイントのよくある問題 {#common-issues-with-the-official-x-trends-endpoint}

公式 X トレンドエンドポイントは、しばしば予想より少ないトレンドを返し、デフォルトで場所あたり、より古い v1.1 のエンドポイントが返した50ではなくおよそ20で、プラットフォーム側の問題の間には時折空のリストを返します。その tweet_count フィールドは、trend.fields を通じてリクエストしてもしばしば null で、アクセスは有料の API の層に制限されています。

これらはエッジケースではありません。X 自身の開発者フォーラムで繰り返し現れます。

• 約20トレンドのみ。 v2 で GET /2/trends/by/woeid/{woeid} を呼ぶ開発者はおよそ20項目を受け取ると報告し、一方ドキュメントは v1.1 がかつて返した50を約束しません。特に長いリストが必要なら、そのデフォルトとエンドポイントの結果件数のパラメータの中で作業しなければなりません。
• 空の応答。 プラットフォームのインシデントの間、エンドポイントはすべての WOEID について一度に空白のトレンドのリストを返したことがあります。これは自分のコードではなく上流のデータを反映するため、どの本番のポーラーも空の配列を優雅に扱う必要があります。
• 欠けたツイート量。 tweet_count フィールドはトレンドごとの量を運ぶことを意図していますが、複数の開発者が、trend.fields が正しく設定されていても null を返すと報告します。その数字を信頼できるものとして扱うのは間違いです。
• 有料の層と OAuth のオーバーヘッド。 トレンドはどの無料の層の一部でもなく、すべての呼び出しが登録済みのアプリに結びついた Bearer トークンを必要とし、それが始めるうえで最も遅い部分です。
• v1.1 の道は行き止まり。 より古いチュートリアルは v1.1 の GET trends/place を指しますが、X はそれを廃止しました。それらのガイドからコピーされたコードは動きません。

これが、1キーの代替が存在する実用的な理由です。Sorsa のような代替の Twitter/X API を通じてトレンドを引くことは、OAuth のセットアップとリソース単位の課金を回避し、現在の完全なリストを1リクエストで返し、各トレンドをすぐの検索クエリと組み合わせます。ツイート量のギャップは両方の経路に当てはまり、どちらにとっても正直な答えは同じです。時間の窓にわたってトレンドの検索結果を数えることで量を導くことで、それはプラットフォームが空のままにするフィールドよりも真実に近い尺度です。

トレンドデータのユースケース {#use-cases-for-trend-data}

トレンドデータは、実際のパイプラインの中に座るまで装飾的に見えます。これらが、ほとんどの本番の利用を駆動するパターンです。

リアルタイムのコンテンツマーケティング。 ソーシャルチームは、地域のトレンドを10〜15分ごとに引き、ブランドの声のルールに照らしてスコア付けし、エンゲージするのに安全なものを表面化します。元の Oreo のスーパーボウルの瞬間はこれの手動のバージョンでした。自動化されたバージョンはトレンドのフィードで動きます。

報道機関のアラート。 ニュースデスクは、主要な市場に加えていくつかの隣接するものを見張り、なじみのないトピックがトップ10に入ったときに Slack のアラートを発火し、しばしば通信社に届く前に記事を捕らえます。

トレーディングのシグナル研究。 クオンツチームは、標的の市場のトレンドをきつい間隔で引き、ティッカーとセクターのキーワードに対して相互参照します。トレンドのトピックはときに対応する価格の動きに先行し、それが有用な入力のレイヤーにします。

ローカライズされたキャンペーンの計画。 代理店は、クライアントが運営するすべての市場のトレンドを1日1〜2回引き、どのクリエイティブがどこに出荷されるかを決めます。出力は通常、ライブのシステムではなくシートや BI ダッシュボードです。

ブランドと危機の監視。 地域のトレンドにブランドや製品が突然現れることは、しばしば PR イベントの最も早いシグナルです。トレンドをメンションの追跡と組み合わせると、これを安く信頼できるアラームに変え、ソーシャルリスニングや競合の追跡のワークフローと自然に組み合わさります。

これらのすべてで、トレンドの呼び出しは安い部分です。作業は結果で何をするかで、それがリクエスト単位のフラットな料金が、最初に見えるよりここで重要な理由です。

レート制限、キャッシュ、ベストプラクティス {#rate-limits-caching-and-best-practices}

これを規模で実行するためのいくつかの実用的な注記。

積極的にキャッシュします。 トレンドはせいぜい数分ごとに変わるため、WOEID ごとに結果を5〜10分キャッシュすればほぼすべてのユースケースをカバーし、リクエストの量を桁違いに削ります。TTL 付きの Redis が最も単純な実装です。

レート制限を尊重します。 Sorsa は、/trends を含むすべてのエンドポイントで、API キーあたり一律の毎秒20リクエストを強制します。20地域を30秒ごとにポーリングするのは問題ありません。200地域を毎秒ポーリングするのは問題で、429 Too Many Requests を返します。より高いスループットには、レート制限のページがカスタムの制限をカバーします。

空のリストを扱います。 一部のより小さな WOEID は時折短いまたは空の配列を返します。これは正常で、基礎となる X のデータを反映するため、防御的にコードします。

検索には name ではなく query フィールドを使います。 name は人間が読めますが、エスケープが必要な文字を含むことがあります。query はすでに URL エンコードされ、X が内部で使うものです。検索エンドポイントに渡す前にデコードします。

スケジュールされたポーリングをずらします。 50 WOEID を追跡するとき、50すべてを分の境界で発火しないでください。バーストの負荷を避けるために30秒の窓に広げます。ドキュメントは規模での API の利用を最適化するためのリクエストのパターンもカバーします。

実践：報道機関のデスクのためのトレンドポーリング {#in-practice-trend-polling-for-a-newsroom-desk}

トレンドデータに最も強く頼るチームは、ソーシャルの報道機関とブランド監視のデスクです。協力したおよそ12人のメディア分析グループは、速報を早く捕らえるために8つの市場にわたって地域のトレンドを数分ごとにポーリングしました。

公式 API の従量課金のモデルでは、8つの市場にわたって市場あたり約30トレンドを5分ごとに読むことは速く積み上がります。返される各トレンドが別々に課金されるリソースで、忙しい月はプラットフォームの読み取りの上限に向かって押すからです。同じポーリングをリクエスト単位のフラットなプランに移すことで、それが単一の予測可能な月額の数字に収縮し、リソース単位の会計を完全に取り除きました。1つの場所の取得は、いくつのトレンドが返っても1リクエストとして数えられるからです。節約は巧妙な最適化ではありませんでした。それは、この量ではフラットレートの課金がリソース単位の課金よりはるかに安いことから直接続きます。上の比較表に示したのと同じ、取得あたりおよそ100倍のギャップです。

よくある質問 {#frequently-asked-questions}

X API v2 にトレンドのエンドポイントはある？

はい。X API v2 のトレンドのエンドポイントは GET /2/trends/by/woeid/{woeid} です。WOEID をパスパラメータとして取り、トレンドオブジェクトのリストを返し、trend.fields パラメータを通じて省略可能な tweet_count フィールドをサポートします。認証は OAuth 2.0 Bearer トークンを使い、アクセスは有料の X API の層に限定されます。レガシーの v1.1 の trends/place エンドポイントは廃止されました。

なぜ X トレンドエンドポイントは20トレンドだけか空の応答を返す？

X API v2 のトレンドのエンドポイントは、デフォルトで場所あたり約20トレンドを返し、引退した v1.1 のエンドポイントが返した50より少なく、そのドキュメントは固定の件数を保証しません。プラットフォーム側のインシデントの間には空の配列を返すこともあり、それは自分のリクエストのバグを示すのではなく、すべての WOEID に一度に影響します。本番のポーラーは短いリストと空のリストを優雅に扱うべきです。

無料の Twitter トレンド API はある？

2026年に公式 X API を通じた無料のトレンドのアクセスはありません。トレンドが有料の層の背後に座り、読み取りがリソース単位で課金されるからです。無料のスクレイパーと非公式のエンドポイントは存在しますが、レート制限されて信頼できない傾向があります。低コストでの信頼できるアクセスには、Sorsa のような代替の Twitter/X API が、クレジットカード不要で100回分の無料リクエストで始めさせ、それからフラットなレートで課金するため、1回のトレンドの取得は Proプランでおよそ$0.002かかり、小さなワークロードは月に数ドルで動きます。

公式 X トレンド API と Sorsa の違いは何？

公式 X トレンドエンドポイントは、省略可能でしばしば空のツイート数とともにトレンド名を返し、トレンド読み取りあたりで課金される有料の層で OAuth 2.0 Bearer トークンを必要とします。Sorsa の /trends エンドポイントは、各トレンド名を事前に構築された検索クエリと直接の URL とともに返し、1つの API キーで認証し、リクエストあたりフラットなレートで課金します。トレンドと検索を組み合わせるパイプラインには、すぐに使える query フィールドが、検索の構文を手で構築するステップを取り除きます。

Twitter のトレンドはツイート量や件数を含む？

公式 X トレンドエンドポイントは tweet_count フィールドを公開しますが、開発者は trend.fields を通じてリクエストしても null を返すと報告するため、信頼できません。Sorsa のエンドポイントは各トレンドに量の数字を付けません。どちらの経路でも量を測る最も真実に近い方法は、トレンドのクエリで検索エンドポイントを照会し、固定の時間の窓にわたって結果を数えることです。

特定の都市のトレンドを取得できる？

はい、X がその都市のトレンドをサポートするときは。町レベルの WOEID は、合計でおよそ470のサポートされるトレンドの場所のうち、世界中のほとんどの主要な都市圏をカバーします。より小さな都市は通常専用のリストを持たず、国レベルのデータにフォールバックします。公開の WOEID gist はサポートされるすべての場所をリストし、その中の任意の都市を woeid パラメータとして直接渡せます。

国や都市の WOEID をどう見つける？

よくある市場には、本ガイドのリファレンス表をチェックします。それ以外の何かには、GitHub の公開の WOEID gist が、X がサポートするすべてのトレンドの場所とその数値の ID をリストします。場所がそのリストになければ、X は API のレベルでそれのトレンドデータを公表しないため、照会する WOEID はありません。

過去の Twitter トレンドを取得できる？

どのトレンド API も過去のデータを返しません。公式 X エンドポイントも Sorsa のエンドポイントも現在のリストだけを返します。履歴を構築するには、スケジュールでポーリングし、各スナップショットを保存します。通常は場所ごとに10〜15分ごとに時系列のデータベースに書き込みます。Sorsa はリクエストあたりフラットなレートで課金するため、過去のアーカイブのための頻繁なポーリングは安いままです。

始め方 {#getting-started}

最初のトレンドリストへの最も速い道：

1. Sorsa ダッシュボードでアカウントを作り、API キーをコピーします。待つべき開発者アカウントの承認はありません。
2. https://api.sorsa.io/v3/trends に、ApiKey ヘッダーのキーと、1（世界全体）や 23424977（US）のような WOEID を伴う GET リクエストを送ります。
3. 各トレンドの事前に構築された query フィールドを検索エンドポイントに渡して、トレンドを駆動する実際の投稿を取得します。

すべての新しいアカウントは、始めるための100回分の無料リクエストをクレジットカード不要で含み、有料プランは10,000リクエストで月額$49から始まり、すべての層で一律の毎秒20リクエストです。API は2022年以来50億を超えるリクエストを処理してきました。Sorsa Playgroundでコードを書かずに任意のエンドポイントを試し、完全な API リファレンスを読み、または Twitter API の代替ガイドで選択肢を比較できます。標準のプランを超える量には、チームが営業に相談を通じてカスタムの制限を扱います。

監修：Keksich（Sorsa創業者、マーケター兼X APIリサーチャー）

本ガイドは、代替の Twitter/X API である Sorsa をビルドして運用する Sorsa 自身の実地の作業と、この更新の間に稼働中の /trends エンドポイントを公式のものに対してテストしたことに基づいています。公式のエンドポイントのパス、結果の挙動、そして課金は、X の公式のトレンドのドキュメントと、結果の制限とツイート数のフィールドに関する X の開発者フォーラムのスレッドに対して確認しました。WOEID のカバレッジは公開の WOEID gist に対してチェックしました。両プロバイダーの料金は2026年6月9日時点で現行の数字を反映します。最終確認2026年6月9日。