著者：Sorsa Editorial

2026年7月更新：100回分の無料リクエストの開始オプションを追加し、Sorsa の料金を1,000プロフィールあたりのレートで捉え直し、公式 X API のコストを現行のリソース単位のレートカードに刷新しました。

要点： Twitter/X フォロワー API は、ユーザーをフォローするアカウントと、そのユーザーがフォローするアカウントを取得します。公式 X API は GET /2/users/:id/followers と GET /2/users/:id/following を公開し、完全なプロフィールメタデータを持つページネーションされたユーザーオブジェクトを返します。各エンドポイントは返されたユーザーオブジェクト単位で課金するため、フォロワーリストのコストはアカウントのサイズに応じてスケールします。

X（旧Twitter）からフォロワーリストを意味のある規模で取得しようとしたことがあるなら、2つの壁の1つに当たっているでしょう。ウェブ UI が数百プロフィールの後に静かに読み込みを止めるか、公式 X API にサインアップして「100,000フォロワーを取得」が4桁ドルの請求書を意味し得ると気づくかです。どちらも、人々が実際にフォロワーデータを必要とする仕事、つまり競合インテリジェンス、リード生成、インフルエンサー発見、学術研究、キャンペーン検証には使えません。

これは開発者向けの案内です。エンドポイント、認証モデル、本番のパターンです。まだツールを選んでおらず、API アクセスをブラウザ拡張、自前のスクレイパー、X のネイティブのデータエクスポートと比較検討したいなら、Twitter フォロワーを抽出する方法の比較 がまずそれらのトレードオフを扱います。本ガイドの残りは、API の経路に落ち着いたことを前提とします。

代替の Twitter/X API プロバイダーである Sorsa API は、公式エンドポイントと同じデータを異なるコスト構造で扱います。その /followers と /follows のエンドポイントは、単一の ApiKey ヘッダーの背後で、リクエストあたり最大200件の完全なユーザープロフィールを返し、アプリ審査なしで一律の毎秒20リクエストで動き、ユーザーオブジェクト単位ではなくリクエスト単位で課金します。その最後の違いが、規模でのフォロワーデータの全ストーリーで、以下のセクションが、公式エンドポイント、料金の計算、そしてコピー＆ペーストできる Python と JavaScript とともに、なぜかを詳しく扱います。

目次

  1. Twitter フォロワー API が返すもの
  2. 2026年に公式 X API はフォロワーにいくらかかる？
  3. リソース単位対リクエスト単位の課金
  4. Sorsa のフォロワーとフォロー中のエンドポイント
  5. フォロワーの1ページを取得する
  6. 完全なフォロワーリストをページネーションする
  7. 規模で重要な本番のパターン
  8. なぜ /verified-followers が別のエンドポイントとして存在するのか
  9. つまずかせるエッジケース
  10. 公式 X API がまだ意味をなすとき
  11. よくある質問
  12. 始め方

Twitter フォロワー API が返すもの {#what-the-twitter-followers-api-returns}

Twitter/X フォロワー API は、ページネーションされたユーザーオブジェクトのリストを、フォロワー1人につき1つ返し、各オブジェクトはハンドルだけでなくそのフォロワーの完全なプロフィールを運びます。1回のフォロワーリクエストは、実際には、関係のフィルターを適用したバルクのプロフィール照会です。各フォロワーについて、通常は直接のプロフィール照会から得るのと同じフィールドを得ます。

  • 安定した数値のユーザー ID と現在のハンドル
  • 表示名、プロフィール文、プロフィール画像 URL、バナー URL
  • フォロワー数、フォロー数、ツイート数
  • アカウント作成日
  • 所在地の文字列（自由記述、検証なし）
  • 認証状態（Blue、Gold、Gray）
  • 保護／非公開のフラグ
  • プロフィール文の中の URL
  • ピン留めツイートの ID

その豊かさは見た目以上に重要です。1回のフォロワーリストのリクエストで、ハンドルを集めるだけでなく、2回目のプロフィール照会なしにオーディエンスを見極め、セグメント化し、またはフィルターするのに必要なデータを得ます。

公式 X API はこれを2つのエンドポイントに分けます。

エンドポイント返すもの
GET /2/users/:id/followers指定したユーザーをフォローするユーザー
GET /2/users/:id/following指定したユーザーがフォローするユーザー

Sorsa は同じペアを GET /v3/followers と GET /v3/follows として、加えて認証済みアカウントのみを返す3つ目のユーティリティエンドポイント GET /v3/verified-followers として公開します（それがなぜ存在するかは下でさらに）。

2026年に公式 X API はフォロワーにいくらかかる？ {#how-much-does-the-official-x-api-cost-for-followers-in-2026}

X API の従量課金モデルの下では、フォロワーとフォロー中の読み取りは、返されたユーザーオブジェクト単位で、自分のものでない任意のアカウントについてリソースあたり$0.010で課金されます。100,000アカウントのフォロワーリストは100,000の課金可能なリソースで、ページネーションにどれだけ少ないリクエストを使おうと、およそ$1,000です。これはほとんどの古いガイドが見落とす細部です。それらが2026年の料金変更の前に書かれたからです。

モデルは2つのステップで到着しました。X は2026年2月に新規開発者のデフォルトとして従量課金に移りました。無料枠も、固定の Basic や Pro のサブスクリプションもなく、ただ開発者コンソールで買い呼び出し単位で課金されるクレジットです。それから2026年4月20日、X は「自己所有の読み取り」（自分のアカウントのデータのリクエスト）をリソースあたり$0.001に削り、一方他のアカウントの読み取りは標準レートに留まりました。X の開発者コミュニティによると、リソース単位で課金されます。各$0.010で1,000フォロワーを持つユーザーアカウントは、リクエスト単位ではなく返されたユーザーオブジェクト単位で課金され、$10になります。

これが「自己所有の読み取り」の落とし穴です。自分の開発者アカウントのフォロワーリストの取得は今や安いです。競合、インフルエンサー、またはリードソースのフォロワーの取得は、ユーザーオブジェクト単位で課金される標準の非所有の読み取りです。X が投稿読み取りに適用する月200万の上限は、純粋にリソース単位で課金されるフォロワー読み取りを統治しません。

アカウントサイズ公式 X API（非所有の読み取り、$0.010/リソース）Sorsa API（Pro）
1,000フォロワー$10.00約$0.01
10,000フォロワー$100.00約$0.10
100,000フォロワー$1,000.00約$1.00
1,000,000フォロワー$10,000.00約$10.00

開示：Sorsa API は当社の製品です。公式 API の数字は X の公開された料金を使っており、そこでは非所有の読み取りが返されたリソース単位で、自己所有の読み取りがリソースあたり$0.001で課金され、2026年6月時点で現行のリソースあたり$0.010のユーザー読み取りレートです。正確なコストは、超過の扱いや交渉された契約で変わり得ます。コミットする前に、実際のワークロードに対してどのプロバイダーもテストすることをお勧めします。

リソース単位対リクエスト単位の課金 {#per-resource-vs-per-request-billing}

リソース単位とリクエスト単位の課金の違いこそ、見出しのレートではなく、フォロワーデータのコストを決めるものです。公式 X API はレスポンスの中のすべてのユーザーオブジェクトを別々の課金可能なリソースとして数えるため、1,000フォロワーを返す1リクエストは、1,000回の個別の照会と同じコストです。Sorsa のようなフラットレートの API は、その中に何人のユーザーが返ってこようと、リクエスト全体を月次の枠に対する1単位として数えます。

フォロワーの抽出には、フォロワーエンドポイントが呼び出しあたり多くのオブジェクトを返すため、このギャップが速く複利で効きます。公式 API では、100,000フォロワーのリストは各$0.010で100,000リソースです。Sorsa では、同じリストは月次の枠に対しておよそ500リクエスト（リクエストあたり200プロフィール）で、Proプランでおよそ$1.00です。データの形は同じで、支払う単位が違います。

これが、フォロワーデータのためにそもそもサードパーティの Twitter API 市場が存在する構造的な理由です。公式 API は、自分のアカウントだけを読むときはよく値付けされています。それ以外のすべてには、リソース単位の課金が不利に働き、リクエスト単位のモデルがコストを下げるレバーです。プロバイダーをまたいだ完全な内訳は、Twitter API 料金ガイド をご覧ください。

Sorsa のフォロワーとフォロー中のエンドポイント {#the-sorsa-follower-and-following-endpoints}

Sorsa のフォロワーエンドポイントは、単一の ApiKey ヘッダーで認証される3つの GET リクエストで、OAuth フローも、アプリ審査も、ベアラートークンのローテーションもありません。完全な フォロワーとフォロー中のドキュメント が、レスポンススキーマとページネーションの挙動を詳しく扱っています。短い版：

  • GET /v3/followers は、指定したユーザーをフォローするアカウントを返します。
  • GET /v3/follows は、指定したユーザーがフォローしているアカウントを返します。
  • GET /v3/verified-followers は、/followers と同じ形を返しますが、Blue、Gold、Gray の認証済みアカウントのみです。

3つのユーザー識別子の1つをクエリパラメータとして、加えて任意のページネーションカーソルを渡します。

パラメータ説明
username@ なしのハンドル、たとえば stripe
user_id数値のユーザー ID、たとえば 44196397
user_link完全なプロフィール URL、たとえば https://x.com/stripe
next_cursor前のレスポンスが返す任意のページネーションカーソル

各ページは最大200件のユーザーオブジェクトを返し、利用可能なリクエストあたりの収量の最も高いものの1つです。公式 X API は各呼び出しを1,000件のユーザーオブジェクトに制限しますが、そのすべてに課金します。Sorsa はリクエストあたり200件を返し、バッチ全体を枠に対する1リクエストと数えます。

フォロワーの1ページを取得する {#fetching-one-page-of-followers}

/followers エンドポイントに対する最小の動く呼び出しは、ユーザー名と API キーを持つ1回の HTTP GET です。1リクエスト、1レスポンス、認証の煩雑な手順なし。

cURL

bash
curl "https://api.sorsa.io/v3/followers?username=stripe" \
  -H "ApiKey: YOUR_API_KEY"

Python

python
import requests

resp = requests.get(
    "https://api.sorsa.io/v3/followers",
    headers={"ApiKey": "YOUR_API_KEY"},
    params={"username": "stripe"},
)
for user in resp.json().get("users", []):
    print(f"@{user['username']} - {user.get('description', '')[:80]}")

JavaScript（Node.js またはブラウザ）

javascript
const resp = await fetch(
  "https://api.sorsa.io/v3/followers?username=stripe",
  { headers: { "ApiKey": "YOUR_API_KEY" } }
);
const { users } = await resp.json();
users.forEach((u) =>
  console.log(`@${u.username} - ${u.description?.slice(0, 80) ?? ""}`)
);

代わりにユーザーがフォローしているアカウントを取得するには、/followers を /follows に入れ替えます。パラメータの形とレスポンスの構造は同一です。コードを書く前にレスポンスを見たいなら、Recent Followers ツール が任意の公開アカウントの直近20フォロワーをブラウザで描画し、API Playground が1行も書かずに任意のエンドポイントを呼ばせます。

完全なフォロワーリストをページネーションする {#paginating-through-a-complete-follower-list}

最初のページを超えてフォロワーリストを取得するには、各レスポンスで返される next_cursor の値を使ってページを進み、それが null または存在なしで返ってくるまで次のリクエストで戻します。Sorsa では1リクエストが最大200ユーザーを返すため、完全なリストはそれらのページ上のループです。

以下は Python での完全な、本番の形のループです。ページネーション、レート制限、そして暴走した抽出が静かに枠を枯渇させないためのハードなページ上限を扱います。

python
import requests
import time

API_KEY = "YOUR_API_KEY"

def get_all_followers(username, max_pages=100):
    """Fetch the complete follower list of a public account."""
    all_users = []
    cursor = None

    for page in range(max_pages):
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor

        resp = requests.get(
            "https://api.sorsa.io/v3/followers",
            headers={"ApiKey": API_KEY},
            params=params,
            timeout=30,
        )
        resp.raise_for_status()
        data = resp.json()

        users = data.get("users", [])
        all_users.extend(users)
        print(f"Page {page + 1}: {len(users)} followers (total: {len(all_users)})")

        cursor = data.get("next_cursor")
        if not cursor:
            print("Reached end of list.")
            break

        # Sorsa's rate limit is 20 req/s. 50ms between calls is safe.
        time.sleep(0.05)

    return all_users


followers = get_all_followers("stripe", max_pages=100)
print(f"\nTotal followers collected: {len(followers)}")

毎秒20リクエストのレート制限では、これは実時間の毎秒およそ4,000フォロワーになります。100,000フォロワーのアカウントは約25秒かかります。100万フォロワーのアカウントは約4分かかります。同じカーソルのパターンが、API 上の他のすべてのページネーションされるエンドポイントに適用されます。

フォロー中のリストには、/followers を /follows に入れ替えます。それ以外はすべて同一のままです。両方を扱う統一のヘルパー：

python
def get_user_graph(username, endpoint, max_pages=100):
    """endpoint should be 'followers' or 'follows'."""
    all_users = []
    cursor = None
    for _ in range(max_pages):
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor
        data = requests.get(
            f"https://api.sorsa.io/v3/{endpoint}",
            headers={"ApiKey": API_KEY},
            params=params,
            timeout=30,
        ).json()
        all_users.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            break
        time.sleep(0.05)
    return all_users

規模で重要な本番のパターン {#production-patterns-that-matter-at-scale}

きれいなループはノートブックで動きます。実際のパイプライン（cron ジョブ、複数アカウントの一掃、下流の充実）の中でフォロワーの抽出を動かすと、別の一連の問題が表面化します。これらが、基本のループが動いたら手を伸ばすパターンです。

429 レスポンスをきれいに扱う

Sorsa は、毎秒20リクエストの制限を超えると 429 Too Many Requests を返します。修正は短いです。1秒待ってリトライします。制限に当たるペナルティも、歩き下るトークンバケツもありません。差し込みのラッパー：

python
import time
import requests

def get_with_retry(url, params, headers, max_retries=5):
    for attempt in range(max_retries):
        resp = requests.get(url, params=params, headers=headers, timeout=30)
        if resp.status_code == 429:
            # Rate limited. Back off and retry.
            time.sleep(1.0 + attempt * 0.5)
            continue
        if resp.status_code >= 500:
            # Transient server error. Exponential backoff.
            time.sleep(2 ** attempt)
            continue
        resp.raise_for_status()
        return resp.json()
    raise RuntimeError(f"Failed after {max_retries} retries")

ループがすでに呼び出しの間に50ミリ秒スリープするなら、429 はめったに見ません。それらは主に、アカウントをまたいで並列化するときに現れます。レート制限のドキュメント が、何が枠にカウントされるかを正確に記述します。

長時間実行のジョブには username の代わりに user_id を使う

ユーザー名は変わります。数値の user_id は変わりません。同じアカウントのフォロワーを毎週再抽出するジョブをスケジュールするなら、各ユーザー名を一度 user_id に解決して保存します。そうでなければ、対象が自身を改名すると静かにパイプラインを壊し、ログは明らかな原因なしに「user not found」と言います。

python
def resolve_user_id(username):
    resp = requests.get(
        f"https://api.sorsa.io/v3/username-to-id/{username}",
        headers={"ApiKey": API_KEY},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()["id"]

ID 変換のエンドポイント が完全なセットを扱います。ユーザー名から ID、ID から現在のユーザー名、そしてプロフィール URL から ID です。ID を保存し、表示に必要なときだけユーザー名に解決し戻します。

1つのアカウントの中ではなく、アカウントをまたいで並列化する

ページネーションカーソルは設計上シーケンシャルです。各レスポンスが次のカーソルを渡すため、まずページ1から6を取得せずにページ7を取得できません。単一のアカウントの抽出の中に高速化はありません。

アカウントをまたぐのは別です。20の競合からフォロワーを取得するには、毎秒20リクエストの制限に対してその20の抽出を並行して動かします。非同期の Python で：

python
import asyncio
import aiohttp

async def fetch_page(session, url, params):
    async with session.get(url, params=params, headers={"ApiKey": API_KEY}) as r:
        return await r.json()

async def extract_one(session, username):
    users = []
    cursor = None
    while True:
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor
        data = await fetch_page(session, "https://api.sorsa.io/v3/followers", params)
        users.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            return username, users
        await asyncio.sleep(0.05)

async def extract_many(usernames):
    async with aiohttp.ClientSession() as session:
        tasks = [extract_one(session, u) for u in usernames]
        return dict(await asyncio.gather(*tasks))

results = asyncio.run(extract_many(["stripe", "vercel", "supabase", "render"]))

並行度を、レート制限をリクエストあたりのレイテンシで割った値に制限します。毎秒20リクエストとリクエストあたりおよそ150ミリ秒では、3〜4の並行の抽出が天井を飽和させます。

レスポンスデータを扱う

各ユーザーオブジェクトは完全なプロフィールを運ぶため、ほとんどの下流の処理は追加の API 呼び出しを必要としません。形について知っておく価値のあることがいくつか：

  • id フィールドは、数値に見えても整数ではなく文字列です。Twitter のユーザー ID は、一部の言語がネイティブに扱う64ビット符号付き整数の範囲を超えるため、API はそれらを文字列としてシリアライズします。ツールが64ビット値を安全に扱わない限り、int にキャストしないでください。
  • created_at フィールドは ISO 8601（たとえば 2009-06-02T20:12:29Z）なので、直接パースします。datetime.fromisoformat(created_at.replace("Z", "+00:00")) です。カスタムのフォーマット文字列は要りません。
  • description（プロフィール文）は、改行、絵文字、あらゆる種類の unicode を含み得ます。CSV や、UTF-8 をきれいに扱わないパイプラインに書く前にサニタイズします。
  • location フィールドは、検証された地理フィールドではなく、自由記述のユーザー入力の文字列です。信頼できる国のデータには、オーディエンス地理のワークフローが /about エンドポイントを使って X が各アカウントに付ける国のタグを取得し、国別にフォロワーを分析するガイド が完全な内訳を案内します。

オーディエンスのより深い分析には、Twitter フォロワーを抽出する方法の比較が、リードの見極めのためのプロフィール文キーワードでのフィルターと、複数の競合をフォローするアカウントの発見を案内します。生のリストを CRM の準備が整ったシートに変えるには、X データを Google スプレッドシートにエクスポートする をご覧ください。同じリストを偽物または非アクティブなアカウントについて採点するには、偽フォロワーの監査ガイド が扱います。本記事は API の仕組みに留まります。

なぜ /verified-followers が別のエンドポイントとして存在するのか {#why-verified-followers-exists-as-a-separate-endpoint}

クライアント側で認証によってフォロワーをフィルターするのは些細（u.get("verified") is True）なので、専用の /verified-followers エンドポイントは2つの実用的な理由でその居場所を得ます。第一に、認証済みユーザーが小さな少数派である数百万フォロワーのアカウントでは、リスト全体を歩いて認証済みアカウントだけを引き出すのはリクエストと時間を無駄にします。エンドポイントは、/followers と同じ順序で、認証済みのサブセットのみを返します。第二に、「著名なオーディエンス」のフィルターは、PR、ジャーナリズム、投資家の調査、インフルエンサーマーケティングで、1回の呼び出しの価値があるほど一般的です。

bash
curl "https://api.sorsa.io/v3/verified-followers?username=stripe" \
  -H "ApiKey: YOUR_API_KEY"

レスポンスとページネーションの挙動は /followers と同一です。完全なスキーマは 認証済みフォロワー API リファレンス をご覧ください。

つまずかせるエッジケース {#edge-cases-that-will-trip-you-up}

きれいな API でさえ、フォロワーデータには、パイプラインを出荷する前に知っておく価値のあるいくつかの癖があります。以下の4つが、チームが本番で当たる驚きのほとんどを占めます。

保護されたアカウントはエラーを返します。 対象がツイートを非公開に設定している（protected フラグが true）なら、そのフォロワーとフォロー中のリストは承認されたフォロワーの外の誰にもアクセスできず、エンドポイントは部分的な結果ではなくエラーを返します。多くのアカウントにまたがってスクリプトを組んでいるなら、抽出の前に /info エンドポイントでプロフィールの protected フラグを確認します。

フォロワー数と抽出可能なリストは正確には一致しません。 プロフィールの followers_count は、X が維持するリアルタイムのカウンターです。API を通じて歩くリストは、停止されたアカウント、無効化されたユーザー、そして最近アンフォローしたがまだカウンターからフラッシュされていないアカウントのために、わずかに小さく返ってくることがあります。大きなアカウントでは数%のずれを見込み、followers_count に対する厳密な等価チェックを書かないでください。

プロフィールデータは現在のもので、過去のものではありません。 各ユーザーオブジェクトは、フォローが起きたときの状態ではなく、今存在するプロフィールを反映します。誰かが2019年に Stripe をフォローし、その後自身を改名したなら、抽出の中の username は新しいハンドルです。数値の id は安定です。ハンドルはそうではありません。

順序はおおむね逆時系列です。 /followers と /follows はどちらも X が提供する順序で結果を返し、一般に新しいフォローが先なので、最初のページが最も最近獲得したフォロワーを保持します。X はこの順序に公式にコミットしていないため、それが永遠に固定されることに依存するロジックを組まないでください。ただし実際には一貫して保たれています。

公式 X API がまだ意味をなすとき {#when-the-official-x-api-still-makes-sense}

公式 X API は2つの特定のケースで正しい選択です。自分のアカウントのデータの読み取りと、書き込まなければならない任意のワークフローです。自分のフォロワーの読み取りは2026年4月20日に$0.001の自己所有の読み取りレートで安くなったため、個人のダッシュボードとアカウント管理のツールには、OAuth ユーザーコンテキスト認証を持つ公式の GET /2/users/:id/followers が妥当に合います。書き込みアクション（投稿、いいね、フォロー）は公式 API のみで、読み取りに焦点を当てたプロバイダーが扱うものではありません。

任意のサードパーティのアカウント、つまりほぼすべての商用アプリケーションにとって現実的なケースには、計算が変わります。リソース単位のコストは自己所有の読み取りと比べておよそ10倍上がり、OAuth 2.0 が認証フローに摩擦を加え、レート制限は15分の窓で強制され、超えると429 を返し、それはもっと支払っても上がりません。料金変更後に公式 API から移るチームには、Sorsa の移行ドキュメントがエンドポイントごとの対応付けを扱います。

決定木は短いです。

  1. 自分のアカウントのデータだけを読む？ 公式 X API で問題ありません。安く、データは正典です。
  2. 他のアカウントのデータを読む？ 代替の Twitter/X API がよりよく合います。コストのギャップは、より詳しく見る必要のないほど大きいです。
  3. 投稿、いいね、フォローが必要？ 公式 X API のみ。書き込みアクションは、Sorsa のような読み取り専用のプロバイダーの範囲外です。

実践 {#in-practice}

fintech の X アカウントにまたがって感情を追跡するあるクオンツファンドのために、フォロワー抽出のジョブを作り直したことがあります。このファンドは、それぞれ平均80,000フォロワーの、約50の中堅の競合アカウントのフォロワーリスト、合計でおよそ400万ユーザーオブジェクトを必要としました。公式 API の非所有の読み取りレートでは、その1回限りの取得は$40,000近くに値付けされました。フラットレートのサードパーティ API での同じジョブは、およそ$40の枠になり、同一のデータの形で、午後の内に動きました。要因は割引ではなく構造的です。公式 API は返すすべてのユーザーオブジェクトに課金し、一方リクエスト単位の API は呼び出しに課金し、その中に200プロフィールを返します。数百万のオーディエンスには、最初の10,000〜20,000フォロワー（50〜100リクエスト）をサンプリングするのが通常、最近のオーディエンスを代表し、完全な尾を歩く支払いを避けます。

よくある質問 {#faq}

Twitter フォロワー API とは？

Twitter フォロワー API は、Twitter/X ユーザーをフォローするアカウントと、同じエンドポイントのファミリーで、そのユーザーがフォローするアカウントをプログラムで取得するエンドポイントのセットです。公式版は GET /2/users/:id/followers と GET /2/users/:id/following です。Sorsa のようなサードパーティのプロバイダーは、OAuth とリソース単位の課金の代わりに、単一の API キーとリクエスト単位の課金を通じて同じデータを公開します。

API を通じて Twitter のフォロー中リストをどう取得する？

フォロー中のリスト（ユーザーをフォローするアカウントではなく、ユーザーがフォローするアカウント）を取得するには、フォロワーのエンドポイントではなく「フォロー中」のエンドポイントを呼びます。公式 API ではそれは GET /2/users/:id/following、Sorsa では GET /v3/follows で、フォロワーエンドポイントと同じパラメータと1ページ200件のページネーションです。フォロー中のリストは通常フォロワーリストより小さく、アカウントが誰を追うことを選ぶかを示すため、しばしばより多くを明かします。

2026年に公式 X API はフォロワーデータにいくらかかる？

2026年4月20日の更新後、X は「自己所有の読み取り」（自分のデータ）にリソースあたり$0.001、他のアカウントのデータに標準の非所有の読み取りレート、リソースあたり$0.010を課金します。請求はリクエスト単位ではなく、返されたユーザーオブジェクト単位で計算されます。非所有の読み取りで100,000アカウントのフォロワーリストはおよそ$1,000です。

リソース単位とリクエスト単位の課金の違いは？

リソース単位の課金は、レスポンスの中のすべてのユーザーオブジェクトを別々の課金として数えるため、1,000フォロワーを返す1回の公式 API のリクエストは、1,000回の個別の照会と同じコストです。Sorsa が使うリクエスト単位の課金は、何人のユーザーが返ってこようとリクエスト全体を月次の枠に対する1単位として数えます。各呼び出しが最大200ユーザーを返すフォロワーリストには、それは200個に支払うか1個に支払うかの違いです。

API 呼び出しで user_id と username のどちらを使うべき？

その場限りのクエリと探索には username を使います。2回以上動くコードには user_id を使います。アカウントが自身を改名するとユーザー名は変わります。数値の ID はアカウントの寿命の間安定です。スケジュールされたジョブには、ユーザー名を一度 username-to-id エンドポイントで user_id に解決し、それを保存し、それ以降は user_id を渡します。

429 のレート制限のレスポンスをどう扱う？

1秒スリープしてリトライします。Sorsa の毎秒20リクエストの制限には、当たるペナルティはありません。429 を得て、待ち、次のリクエストが動きます。トークンバケツも、15分の窓も、エンドポイント別のサブ制限もありません。429 と5xx のレスポンスを短いバックオフで捕まえる軽いリトライのラッパーが、本番に十分です。

なぜ抽出した数がプロフィールの followers_count と一致しない？

followers_count の値は X が維持するリアルタイムのカウンターなので、抽出可能なリストはわずかに小さく返ってくることがあります。停止されたアカウント、無効化されたユーザー、そして最近アンフォローしたがカウンターからフラッシュされていない人々が、すべてずれを生みます。大きなアカウントでは数%の差を見込みます。これはコードのバグではなくプラットフォームの挙動なので、厳密な等価チェックを避けます。

フォロワーデータはどれくらい新鮮？

ユーザーオブジェクトはリクエストの瞬間に存在するプロフィールを反映するため、数、プロフィール文、プロフィール画像、認証状態は現在のものです。フォローの関係は、通常 X 上で起きてから数秒から数分以内に反映されます。ストリーミングに近いものには、リアルタイム監視 のパターンが、新しいフォロワーとメンションをきつい間隔で検出する方法を扱います。

始め方 {#getting-started}

自分のアカウントまたは任意の公開アカウントに対してこれを試すには：

  1. 概要ダッシュボード で API キーにサインアップします。すべての新規キーは100回分の無料リクエストを含みます。1回限り、クレジットカード不要・有効期限なしで、40個すべてのエンドポイントで有効です。フォロワーエンドポイントでは、それは何かを支払う前に最大20,000プロフィールです。
  2. 上の cURL または Python の例を、ハンドルを username パラメータとして実行します。
  3. ノーコードのプレビューには、API Playground を開いてブラウザで /followers を直接呼びます。
  4. Sorsa のフォロワーデータは1,000プロフィールあたり$0.01から動作します。1リクエストがフラットなリクエスト単位のレートで最大200件の完全なプロフィールを返すからです。量の計画は 料金ページ で立てます。Starter で1,000プロフィールあたり$0.02から、Pro と Enterprise で1,000プロフィールあたり$0.01から、すべてのプランが一律の毎秒20リクエストで動きます。

完全なコード、エンドポイントのリファレンス、ページネーションのパターンは、フォロワーとフォロー中のドキュメントにあります。API 以外の抽出（ブラウザ拡張、自前のスクレイパー、手動の X データエクスポート）は、本ガイドの冒頭でリンクした方法の比較をご覧ください。サードパーティの Twitter データ API 市場が2026年に全体として公式 X API とどう比較されるかは、Twitter API の代替の内訳 をご覧ください。

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

本ガイドのまとめ方：エンドポイント、コード、パターンは、Sorsa の Twitter/X API をビルドして運用し、稼働中の公開アカウントに対してフォロワー抽出を動かす Sorsa 自身の作業から来ています。公式 API のコストとモデルは、X の公開された開発者向けの料金と、X の開発者リソースに文書化されたレート制限の挙動に対して確認しました。最終確認2026年7月。