2026年7月更新:100回分の無料リクエストの開始オプションを追加し、リストの料金を1,000プロフィールあたりのレートを軸に捉え直し、公式 X API の比較を再構築しました。X コミュニティの利用可能性を再確認しました。
要点 X リストは、それ自身のタイムラインを持つ、最大5,000アカウントの公開でキュレーションされたグループです。リスト API は、すべてのメンバー、すべての購読者、そしてそれらのメンバーからの結合されたツイートのフィードを単一の呼び出しで返します。1つのリストをポーリングすることが各アカウントのポーリングを置き換え、50アカウントのウォッチリストでリクエストの量をおよそ50分の1に削ります。
X(旧Twitter)のリストは、プラットフォーム上で最も活用されていないデータソースの1つです。よく維持されたリストは手でキュレーションされた名簿です。アナリストのフィンテックの創業者のセット、ジャーナリストの戦争記者のセット、取引所の暗号資産の KOL のセットです。誰かがすでにオーディエンスの調査をしていて、その結果のリストは単一のオブジェクトとして照会可能です。
そのワークフローの背後のエンドポイントは、かつては公式 X API にのみ住んでいました。OAuth 2.0、月間の投稿読み取りの枠、そして継続的な監視にスケールしない料金に慣れているなら、それは使えるものです。代替の Twitter/X API である Sorsa API は、1つの ApiKey ヘッダーの背後で3つのエンドポイントを通じてリストを公開します。OAuth なし、アプリのレビューなし、そしてすべてのプランで一律の毎秒20リクエストです。/list-members がリクエストあたり最大200のプロフィールを返すため、リストの抽出はフラットなプランで1,000プロフィールあたり$0.01から始まり、以下のパターンは規模でも安いままです。戦略的なポイント(何を照会するか、いつリストが生のポーリングに勝つか、コストをどう考えるか)は一般的で、コードはそのまま実行できるプレーンな Python です。
目次
- X リストとは、そこから何を引けるか?
- なぜ各アカウントではなくリストをポーリングするか?
- 3つのリストのエンドポイント
- リスト API は何を返すか?
- 監視を超えて X リストは何に役立つか?
- X コミュニティに関する注記
- Twitter リスト API 対公式 X API
- 監視できるリストのセットアップ方法
- コード:Python でリストのデータを引く
- 実際にこれがどう見えるか
- 始め方
- よくある質問
X リストとは、そこから何を引けるか? {#what-is-an-x-list-and-what-can-you-pull-from-it}
X リストは、そのメンバーからの投稿だけを表示するそれ自身のタイムラインを持つ、最大5,000アカウントの公開または非公開のコレクションです。誰でも1つ作れ、アクセスのある誰でもそれを購読できます。API を通じて、公開リストから2つの異なるオーディエンスを抽出できます。そのメンバーとその購読者です。
その2つのグループは異なることを示し、両方とも抽出可能です。
- メンバー はリスト上のアカウントです。キュレーターが追跡する価値があると考えた人たちです。
- 購読者(リストのフォロワー) は、それを読むためにリストをフォローすることを選んだユーザーです。その人たちは積極的にそのトピックにオプトインしました。
非公開リストは、公式でもサードパーティでも、どの API を通じても到達不可能です。以下のすべては、リストが公開で、ログアウトしたブラウザで開いたときに解決すると仮定します。
なぜ各アカウントではなくリストをポーリングするか? {#why-poll-a-list-instead-of-each-account}
リストをポーリングすることは、多くのアカウント単位のリクエストを1つに畳みます。リストがキュレーションだけでなくエンジニアリングに重要な理由は、リクエストの量です。
50アカウント、たとえばフィンテックのセクターのウォッチリストを追跡し、それぞれを10秒ごとにポーリングするとします。それはサイクルあたり50リクエスト、1日に8,640サイクル、そして1日に432,000リクエスト、月におよそ1,300万です。どのプロバイダーのどのプランも、それのために作られていません。
同じ50アカウントのリストを作り、代わりに単一のツイートのフィードをポーリングします。同じ10秒の間隔でサイクルあたり1リクエストは、1日に8,640リクエスト、月に約259,000です。同じ投稿を、しばしばより低いレイテンシーで捕らえます。リストのタイムラインが X 側で積極的にキャッシュされるからです。
| アプローチ | サイクルあたりのリクエスト | 1日あたり(10秒ポーリング) | 月あたり(10秒ポーリング) |
|---|---|---|---|
| アカウント単位のタイムライン取得、50アカウント | 50 | 432,000 | 約13,000,000 |
| 単一のリストのフィード呼び出し | 1 | 8,640 | 約259,000 |
1回のリストの呼び出しが50回のアカウント単位の呼び出しを置き換え、ウォッチリストとともにスケールする50分の1への削減です。200アカウントのリストは200分の1への削減です。
実際には10秒の頻度が必要なことはめったにありません。1つのリストを30秒ごとにポーリングすることは月に約86,000リクエストで、10万リクエストで$199の Sorsa の Proプランの快適に内側に座ります。これは、Twitter と X でのソーシャルリスニングを実行する顧客とともにセットアップする リアルタイム監視のパイプラインで支配的なパターンです。
3つのリストのエンドポイント {#the-three-list-endpoints}
Sorsa は3つのリストのエンドポイントを公開し、すべて next_cursor を通じてページ分割されます。カーソルが null または不在で返ってきたら、終わりに達しています。
| エンドポイント | 返すもの | リクエストあたり | 最適な用途 |
|---|---|---|---|
GET /v3/list-members | メンバーのプロフィール | 最大200 | オーディエンスの抽出、リストの監査 |
GET /v3/list-followers | リストの購読者 | 最大200 | トピックに関心のある人を発見 |
GET /v3/list-tweets | メンバーからの結合されたフィード | 最大20 | 監視、コンテンツと感情の分析 |
オーディエンスの調査には、/list-followers がしばしば /list-members より有用です。メンバーはキュレーターが選んだ人たちで、一方購読者は自分をそのトピックに関心があると特定しました。各アカウント自身のフォロワーとフォロー中のグラフも必要なら、それはここのリストのエンドポイントではなく フォロワーとフォロー中のリストのエンドポイントがカバーする別の仕事です。
リスト API は何を返すか? {#what-does-the-list-api-return}
リストのエンドポイントは、ネストされた作者のプロフィールに別の課金なしできれいな JSON を返します。/list-members と /list-followers は、完全なプロフィールのオブジェクトの users の配列に next_cursor を加えて返します。/list-tweets は tweets の配列に next_cursor を加えて返し、すべてのツイートが追加コストなしでその完全な作者のプロフィールをインラインで運びます。
これらが各メンバーまたは購読者のプロフィールのオブジェクトの主要なフィールドです。
| フィールド | 型 | 意味 |
|---|---|---|
id | string | 安定した数値のユーザー ID |
username | string | @ なしのハンドル |
display_name | string | プロフィールの表示名 |
description | string | 自己紹介のテキスト |
location | string | プロフィールの所在地 |
followers_count | integer | フォロワーの数 |
followings_count | integer | ユーザーがフォローするアカウント |
tweets_count | integer | 投稿の合計 |
verified | boolean | 認証済みのバッジ |
protected | boolean | 非公開のアカウント |
created_at | string | アカウントの作成日(ISO 8601) |
bio_urls | array | 自己紹介にある URL |
/list-tweets の応答の各ツイートは、テキスト、指標、そして作者を運びます。主要なフィールド:
| フィールド | 型 | 意味 |
|---|---|---|
id | string | ツイート ID |
full_text | string | 完全な投稿のテキスト |
created_at | string | 公開日(ISO 8601) |
lang | string | 検出された言語のコード |
likes_count | integer | いいね |
retweet_count | integer | リツイート |
reply_count | integer | 返信 |
quote_count | integer | 引用の投稿 |
view_count | integer | 表示回数 |
is_reply | boolean | 投稿が返信かどうか |
is_quote_status | boolean | 別の投稿を引用するかどうか |
user | object | 完全な作者のプロフィール(上と同じフィールド) |
entities | array | 添付されたメディアとリンク |
切り詰められた /list-tweets の応答はこのように見えます。
{
"tweets": [
{
"id": "1782368585664626774",
"full_text": "Shipping the new pricing today.",
"created_at": "2026-05-18T10:30:00Z",
"lang": "en",
"likes_count": 200,
"retweet_count": 50,
"reply_count": 10,
"view_count": 10000,
"is_reply": false,
"is_quote_status": false,
"user": {
"id": "44196397",
"username": "founder",
"display_name": "A Founder",
"followers_count": 100000,
"verified": true,
"created_at": "2009-06-02T20:12:29Z"
},
"entities": []
}
],
"next_cursor": "DAABCgAB..."
}
作者のプロフィールがすべてのツイートに埋め込まれているため、単一のリストのフィードの呼び出しが、2回目の検索なしとプロフィール単位の課金なしで、コンテンツとその背後の人々の両方を返します。完全なフィールドの定義は リストとコミュニティのドキュメントにあります。
監視を超えて X リストは何に役立つか? {#what-are-x-lists-good-for-beyond-monitoring}
リアルタイムの監視を超えて、リストはそうでなければはるかに多くの作業がかかるいくつかの研究のパターンをサポートします。
ニッチの専門家の発見。 ジャーナリストとアナリストは「AI Safety Researchers」や「DeFi Founders」のような名前のリストをキュレーションします。メンバーの名簿は専門家が精査したショートリストです。一度引き、フォロワー数または最近のエンゲージメントで並べれば、数分でアウトリーチのターゲットのリストができます。
オーディエンスの重複分析。 同じニッチの2つの競合するリストのメンバーを引きます。交差はコンセンサスの選択を示し、差は各キュレーターの盲点を示します。競合分析をゼロから実行するより速いです。
セクターの感情。 100アカウントの業界リストのフィードを毎日引き、テキストを任意の感情モデルに通し、移動平均をプロットします。まずアカウントの発見をせずにシグナルが得られます。
オーディエンスの継承。 尊敬されるキュレーターが維持する業界リストの購読者を引きます。これらはトピックにオプトインした人たちで、汎用のフォロワーのスクレイプより Twitter で見込みのあるリードを見つけるためのはるかにきれいな出発点です。
X コミュニティに関する注記 {#a-note-on-x-communities}
X コミュニティはトピックベースのオプトインのグループです。メンバーが参加を選ぶため、名簿はキュレーターの選択ではなく強い関心のシグナルになります。Sorsa はそれらを /community-members、/community-tweets、そして /community-search-tweets を通じて公開し、すべてリストのエンドポイントと同じページネーションのパターンに従う POST エンドポイントです。
ここでは状態の注記が重要です。X は2026年4月に、アカウントの0.4%未満の利用とプラットフォームのスパムの不釣り合いな割合を挙げて、コミュニティを引退させるつもりだと発表し、TechCrunch が報じたように、当初の期限の延長とともにでした。それ以来タイムラインは動き、2026年6月時点でコミュニティとコミュニティのエンドポイントは依然としてデータを返します。この機能はリスクありとして扱います。持続的な何かを構築するなら、削除の予定のないリストの上に構築します。今コミュニティを抽出する必要があるなら、パターンは以下のリストのコードと同一で、community_id または community_link で POST を使います。
Twitter リスト API 対公式 X API {#twitter-list-api-vs-the-official-x-api}
公式 X API はリストのエンドポイントを公開しています。どちらを使うかは主に、どれだけの量が必要か、そしてどれだけの OAuth を維持する意思があるかに依存します。Sorsa API は当社の製品で、以下の比較は X の開発者ドキュメントと X API 料金の分解で確認できる数字を使います。コミットする前に任意のプロバイダーを自分のワークロードに対してテストしてください。
| Sorsa API | 公式 X API | |
|---|---|---|
| 課金モデル | リクエスト単位でフラット(1呼び出し = 1リクエスト) | 取得したリソース単位、従量課金 |
| 呼び出しあたりのリストのプロフィール | 単一のリクエストで最大200 | 返されるプロフィール単位で課金 |
| 読み取りの重いリストの取得のコスト | 1,000プロフィールあたり$0.01から | リソース単位で課金、量とともに上昇 |
| リストのフィードの作者のプロフィール | 無料で含まれる | 別のユーザー読み取りとして課金 |
| セットアップ | 1つの API キー、数分で準備完了 | ファーストパーティのオンボーディング |
| 書き込みアクセス | なし(読み取り専用) | 投稿と DM が利用可能 |
| コミュニティのエンドポイント | はい(リスクあり、上の注記参照) | 利用可能 |
コアの違いは課金の単位です。Sorsa は、いくつのプロフィールやツイートが返っても呼び出しごとに1リクエストを課金するため、リストのページの最大200のプロフィールとリストのフィードに埋め込まれた作者のプロフィールは追加で何もかかりません。公式 X API はそれらのそれぞれを別々のリソースの読み取りとして課金し、それが継続的なリストの監視を積み上げるものです。読み取りの重いリストのワークロードでは、Sorsa は最大50分の1のコストで動作します。レート制限の分解が、なぜ継続的なポーリングが2つのモデルが最も分岐するところかをカバーします。
結論:
- 読み取りの重いリストの抽出と監視: Sorsa。リクエスト単位のフラットな料金に加えて呼び出しあたり最大200のプロフィールが継続的なポーリングを安く保ち、1つの API キーで始めるのに十分です。
- 投稿、DM、広告 API、またはフィルターされたストリーミング: 公式 X API。それらは Sorsa が提供しないファーストパーティの書き込みとストリームの能力だからです。
監視できるリストのセットアップ方法 {#how-to-set-up-a-list-you-can-monitor}
存在するリストからしかデータを引けず、この点についてのすべての API は読み取り専用です。監視できるリストをセットアップするには、X の web インターフェースで一度それをします。
- x.com/lists に行き、「新しいリストを作成」を選びます。
- リストを公開にマークします。非公開リストは誰によっても API アクセスできません。
- 最大5,000アカウントを追加します。ハンドルを貼り付け、検索し、または一括でインポートできます。
- URL から数値のリスト ID をコピーします。
https://x.com/i/lists/1234567890では、ID は1234567890です。 - レイテンシーの予算が許す任意の間隔で、その ID に対してリストのフィードをポーリングします。
リストは、照会可能であるために自分のものである必要はありません。他の誰かの公開リストがすでに対象のトピックをカバーしているなら、その URL から ID をつかみます。非公開の監視のパイプラインを構築していて、追跡するアカウントをメインの身元の下で見えるようにしたくないなら、汎用の名前で別のアカウントの下にリストを作ります。API が到達できるよう公開のままですが、実際のハンドルには結びつきません。
コード:Python でリストのデータを引く {#code-pulling-list-data-in-python}
例は requests を伴うプレーンな Python を使います。SDK なし、認証のダンスなし。Python 3.9 以降と環境変数の API キーを仮定します。すべてのページ分割されたエンドポイントは next_cursor を返し、それが null または欠けているとき、完了です。
import os
import time
import requests
API_KEY = os.environ["SORSA_API_KEY"]
BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": API_KEY}
リストのメンバーを抽出する
def get_list_members(list_id, max_pages=50):
"""Fetch member profiles from a public X List. Up to 200 per page."""
members, cursor = [], None
for _ in range(max_pages):
params = {"list_id": list_id}
if cursor:
params["next_cursor"] = cursor
r = requests.get(f"{BASE}/list-members", headers=HEADERS, params=params, timeout=30)
r.raise_for_status()
data = r.json()
members.extend(data.get("users", []))
cursor = data.get("next_cursor")
if not cursor:
break
time.sleep(0.1)
return members
members = get_list_members("1234567890")
print(f"Pulled {len(members)} members")
for m in members[:5]:
bio = (m.get("description") or "")[:60]
print(f"@{m['username']} ({m['followers_count']:,} followers): {bio}")
完全に埋まった5,000メンバーのリストは、エンドポイントが呼び出しあたり最大200のプロフィールを返すため、抽出するのにおよそ25リクエストかかります。
リストの購読者を抽出する
購読者(リスト上のメンバーではなく、それを読むためにリストをフォローする人たち)は list_link パラメータを使い、それは完全な URL または単に数値の ID を受け付けます。
def get_list_followers(list_link, max_pages=50):
"""Users who subscribe to a public X List."""
followers, cursor = [], None
for _ in range(max_pages):
params = {"list_link": list_link}
if cursor:
params["next_cursor"] = cursor
r = requests.get(f"{BASE}/list-followers", headers=HEADERS, params=params, timeout=30)
r.raise_for_status()
data = r.json()
followers.extend(data.get("users", []))
cursor = data.get("next_cursor")
if not cursor:
break
time.sleep(0.1)
return followers
subs = get_list_followers("https://x.com/i/lists/1234567890")
print(f"{len(subs)} accounts subscribe to this List")
リストからツイートを引く
これが監視のエンドポイントです。呼び出しあたり約20ツイート、すべてのメンバーにわたって時系列で並べられます。
def get_list_tweets(list_id, max_pages=10):
"""Recent tweets from all members of a List, combined feed."""
tweets, cursor = [], None
for _ in range(max_pages):
params = {"list_id": list_id}
if cursor:
params["next_cursor"] = cursor
r = requests.get(f"{BASE}/list-tweets", headers=HEADERS, params=params, timeout=30)
r.raise_for_status()
data = r.json()
tweets.extend(data.get("tweets", []))
cursor = data.get("next_cursor")
if not cursor:
break
time.sleep(0.1)
return tweets
feed = get_list_tweets("1234567890", max_pages=20)
print(f"Collected {len(feed)} tweets")
for t in feed[:5]:
likes = t.get("likes_count", 0)
print(f"@{t['user']['username']} ({likes} likes): {t['full_text'][:80]}")
継続的な監視には、レイテンシーの予算に合う任意の間隔で、cron または asyncio のループでこれを実行します。30〜60秒ごとのポーリングは、トレーディングのシグナルに満たないすべてに十分です。
CSV にエクスポートする
import csv
def export_users_to_csv(users, path):
fields = ["id", "username", "display_name", "description",
"followers_count", "tweets_count", "verified", "location"]
with open(path, "w", newline="", encoding="utf-8") as f:
writer = csv.DictWriter(f, fieldnames=fields)
writer.writeheader()
for u in users:
writer.writerow({
"id": u.get("id", ""),
"username": u.get("username", ""),
"display_name": u.get("display_name", ""),
"description": (u.get("description") or "").replace("\n", " "),
"followers_count": u.get("followers_count", 0),
"tweets_count": u.get("tweets_count", 0),
"verified": u.get("verified", False),
"location": u.get("location", ""),
})
print(f"Wrote {len(users)} rows to {path}")
export_users_to_csv(get_list_members("1234567890"), "members.csv")
同じパターンが購読者にも動きます。ツイートには、フィールドのリストを id、full_text、created_at、likes_count、retweet_count、そして user のユーザー名に入れ替えます。
リトライとレート制限の処理
スケジュールで実行する何もが最小限のエラー処理を必要とします。Sorsa のフラットなレート制限は毎秒20リクエストです。それを超えると429を得ます。バックオフしてリトライします。
def request_with_retry(method, url, max_attempts=5, **kwargs):
for attempt in range(max_attempts):
r = requests.request(method, url, **kwargs)
if r.status_code == 429:
time.sleep(2 ** attempt)
continue
if r.status_code >= 500:
time.sleep(1 + attempt)
continue
r.raise_for_status()
return r
raise RuntimeError(f"Failed after {max_attempts} attempts: {url}")
上の任意の関数で requests.get の代わりにこれを落とします。長時間実行のジョブには、ページの間でカーソルをログして、作業をやり直さずに失敗時に再開できるようにします。より多くのパターンは API 利用の最適化にあります。
実際にこれがどう見えるか {#what-this-looks-like-in-practice}
協力した小さな分析チーム、トレーディングデスクのためにシグナルを構築する約10人は、およそ120の暗号資産の KOL を各アカウントを個別にポーリングして監視していました。アカウント単位のアプローチは、公式 API で高価で、反応が遅い両方でした。同じアカウントを単一の公開リストに移し、1つのフィードをポーリングすることで、サイクルあたり120回のアカウント単位の取得を1つに置き換え、リクエストの量を120分の1に削り、集約されたサードパーティの感情のトラッカーを待つより、変わるトーンの早い読みをこのチームに与えました。データのコストは、公式 API から切り替えるときにどの読み取りの重いチームも見る一般的なパターンに従いました。同じカバレッジで最大50分の1のコストです。決め手はトリックではなく構造的でした。120のタイムラインではなく1つのリストのフィードです。
始め方 {#getting-started}
Sorsa のダッシュボードから API キーをつかみ、X ですでにフォローしているリストにそれを向ければ、数分以内に構造化されたデータを収集しています。すべての新しいキーは、1回限りでクレジットカード不要の100回分の無料リクエストを含み、コミットする前に最大20,000のリストのメンバーのプロフィールを引くか監視のループを実行するのに十分です。API プレイグラウンドが、まずコードを書かずにすべてのエンドポイントをテストさせ、フラットな 料金プランでのリストの抽出は1,000プロフィールあたり$0.01から始まり、すべての層で同じ毎秒20リクエストです。公式 X API から移行していてエンドポイントごとの対応付けが欲しいなら、移行ガイドが同等物を案内します。
よくある質問 {#faq}
非公開の X リストからメンバーを抽出できる?
いいえ。非公開の X リストは、公式でもサードパーティでも、どの API を通じてもアクセスできません。リストは公開でなければならず、その URL はログアウトしたブラウザで開いたときに解決しなければなりません。非公開のリストのデータを引けると主張する者は、間違っているか、ログインしたアカウントを悪用するつもりです。本ガイドで記述するすべては、公開のリストを仮定します。
抽出できる X リストの最大のサイズは?
X はリストを5,000メンバーで上限とします。Sorsa の list-members エンドポイントはリクエストあたり最大200のプロフィールでページ分割するため、完全な5,000メンバーのリストは端から端まで抽出するのにおよそ25呼び出しかかります。5,000メンバーのプラットフォームの制限自体を超える隠れた上限はありません。
URL からリスト ID をどう見つける?
X のリストの URL は https://x.com/i/lists/1234567890 のように見え、末尾の数値がリスト ID です。一部のより古い URL は x.com/username/lists/slug の形を使います。そのリンクを開くと数値のバージョンにリダイレクトし、結果の URL の数字が API に渡す ID です。
X コミュニティは API を通じてまだ動く?
2026年6月時点で、はい。X は2026年4月に、低い利用と高いスパムを挙げてコミュニティを引退させるつもりだと発表し、当初発表された締め切りはそれ以来動きましたが、この機能とコミュニティのエンドポイントは依然としてデータを返します。コミュニティをリスクありとして扱い、削除の予定のないリストの上に持続的な監視を構築します。
リストをポーリングすることはアカウントごとに一度 API を呼ぶより効率的?
はい、そしてこれがリストがエンジニアリングに重要な主な理由です。1つの公開リストを構築し、単一のツイートのフィードをポーリングすることが、サイクルごとにアカウントごとの1リクエストを置き換えます。Sorsa での50アカウントのウォッチリストには、それは各アカウントを別々にポーリングするよりおよそ50分の1のリクエストで、節約はリスト上のアカウントの数とともにスケールします。
最近のものだけでなく、リストから過去のツイートを取得できる?
リストのツイートのフィードは、そのメンバーの最近の結合されたタイムラインを、そのタイムラインが利用可能な限り遡って返します。特定のアカウントの深い履歴には、代わりにそのアカウント自身のタイムラインを引きます。Sorsa では user-tweets エンドポイントが3,200ツイートの上限なしでアカウントの最も初期の投稿まで遡ってページ分割します。リストは監視のため、アカウント単位の取得はアーカイブのためです。
リストのデータを引くのは公式 X API と比べていくらかかる?
Sorsa は、いくつのプロフィールやツイートが返っても API 呼び出しごとにフラットな1リクエストを課金するため、リストの抽出はフラットなプランで1,000プロフィールあたり$0.01から始まり、すべての新しいキーはまず試すための100回分の無料リクエストを含みます。公式 X API は従量課金の下で取得したリソース単位で課金するため、多くのユーザーとツイートを返す単一のリストの読み取りはレコード単位で課金されます。読み取りの重いリストのワークロードでは、Sorsa は最大50分の1のコストで動作します。
古い Twitter v1.1 時代のリスト ID はまだ動く?
はい、リストがまだ公開で web で読み込む限り。Twitter v1.1 の時代に作られたリスト ID は、現行の X プラットフォームと Sorsa のようなサードパーティ API で有効なままです。Twitter から X へのリブランドは、既存のリスト ID を無効にしたり、その数値の形式を変えたりしませんでした。
監修:Keksich(Sorsa創業者、マーケター兼X APIリサーチャー)
本ガイドは、Sorsa のリストとコミュニティのエンドポイントを運用する当チームの実地の作業、稼働中の Sorsa API v3 のドキュメント、そして X 自身の開発者ドキュメントに基づいています。X コミュニティの引退のタイムラインは TechCrunch に典拠します。コミュニティの利用可能性は X で直接チェックしました。料金とレート制限の比較は、2026年の X API 料金ガイドと公式の X 開発者の料金のページに対して再確認しました。最終確認2026年7月6日。