【2026年版】X（Twitter）スクレイピングの方法：ツール・コード・費用

著者：Sorsa Editorial

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

2026年7月31日更新：オープンソースライブラリの状況を GitHub と PyPI で再確認しました（twscrape、Scweet、Tweety は動作。snscrape、Twint、ntscraper は停止。Twikit は本家のリリースが現在動かず、コミュニティのフォークで運用されています）。X の従量課金 API 料金と2026年1月の利用規約も同じ月に再確認しました。

要点： 2026年に公開の X（旧Twitter）データを取得する手段は3つです。ヘッドレスブラウザを動かして X 内部の GraphQL レスポンスを捕まえる、メンテナンスの続くオープンソースライブラリをログイン済みアカウントで動かす、URL をマネージドのスクレイピングサービスに渡す、のいずれかになります。どれも住宅用プロキシが必要で、ほとんどはアカウントも要り、X がゲストトークンと GraphQL 識別子をローテーションする2〜4週間ごとに例外なく壊れます。読み取り専用のデータ API なら、その手間を丸ごと省いて同じデータを JSON で受け取れます。

「Twitter スクレイピング」で検索する人の多くは、実はスクレイパーを欲しがっているわけではありません。欲しいのはデータです。この2つは別の問題です。目的はあくまでデータであり、スクレイパーのほうは、住宅用プロキシと、BAN される使い捨てアカウントと、数週間おきに X をリバースエンジニアリングし直す作業を、ずっと抱え続けることを意味します。

読み取り専用の Twitter/X データ API である Sorsa API は当社が開発・運営しているので、この節は中立ではありません。それでもトレードオフははっきり書く価値があります。スクレイパーが苦労して取り出すのと同じプロフィール、ツイート、検索結果、フォロワーが、1回の REST 呼び出しできれいな JSON として返ってくるからです。プロキシもログインも保守も要りません。料金はバッチエンドポイントで1,000ツイートあたり$0.02、1,000プロフィールあたり$0.01からです。読み取り処理では、公式X APIと比べて最大50分の1のコストで、全プラン一律で毎秒20リクエストを保ちます。申請も審査待ちの行列もなく、最初の呼び出しまで約3分で到達できます。100回分の無料リクエストはクレジットカード不要・有効期限なしで使えます。

それでもスクレイパーを自分で作りたい、制御を握りたい、学習したい、あるいはワークフローが本当にそれを必要とする、という場合のために、本ガイドでは現時点の正直な内容をまとめます。実際に手が届くデータの範囲、動作する Python コード、生きているツールと死んでいるツール、本当にかかる費用、そして法的な一線がどこにあるかです。

目次

• 2026年でも Twitter はスクレイピングできるか？
• 取得できるデータと、手の届かないデータ
• Twitter のスクレイピングは合法か？
• X.com の内部構造
• 方法1：ヘッドレスブラウザによるスクレイピング（コード付き）
• 方法2：オープンソースの Python ライブラリ
• 方法3：AI 支援のスクレイピング
• 方法4：マネージドスクレイピングサービス
• スクレイピング対象のツイート・プロフィール URL の見つけ方
• スクレイピングの実際のコスト
• 方法5：読み取り専用のデータ API（スクレイピングなし）
• どの方法を選ぶべきか？
• よくある質問
• 本ガイドの検証方法

2026年でも Twitter はスクレイピングできるか？ {#can-you-still-scrape-twitter-in-2026}

できます。公開の Twitter データは2026年も公式 API なしで取得できますが、簡単な経路はすべて閉じました。難しくなった理由は3つあり、本ガイドの残りは実質そのすべてを迂回する方法の話です。

第一に、X が匿名のゲストアクセスを締め上げました。かつての無料スタックを葬ったのは、この1つの変更です。第二に、公式 API が従量課金へ移り、読み取りの無料枠が消えました。「API を使えばいい」は、最初のリクエストから費用が発生する話になりました。第三に、公開ページ全体でボット対策が強化されました。動くスクレイパーであっても、住宅用プロキシと慎重なペース配分がなければ生き残れません。

それでも見返りは本物です。X は今も、生きた世論を最も豊富に集められる場所の1つです。だからこそ各チームは、ブランドの言及モニタリング、感情分析、競合分析、リード獲得、トレンド検出、機械学習データセットの構築のためにスクレイピングを続けます。難易度の高さこそ、この種のガイドが存在する理由です。作業の中心はもはや HTML のパースではなく、まず防御を突破することにあります。

取得できるデータと、手の届かないデータ {#what-data-can-you-scrape-and-what-is-off-limits}

コードを書き始める前に、壁がどこにあるかを把握しておきます。ログイン済みのセッションがなくても、公開プロフィール、個々のツイートとそこに表示されるリプライ、埋め込みメディアのメタデータには届きます。ログインの内側にあるもの、非公開アカウント、DM、フォロワー一覧の全体、検索結果の全件は、実在のアカウントでスクレイピングしない限り手が届かず、その方法には凍結のリスクが伴います。

匿名アクセスには、より緩やかな形の制限もあります。リプライは浅い階層までしかたどれず、ゲスト閲覧のレート制限が長いタイムラインを最後まで読ませてくれません。過去ログの全体を取るにはスクロールの自動化を重ねる必要があり、それでもゲストのタイムライン上限にぶつかります。スクレイピングなしで履歴が欲しい場合、データ API なら検索経由で2006年まで遡るツイートを返せますし、匿名のスクレイパーには触れないフォロワー一覧とフォロー一覧も取得できます。

本ガイドの残りが扱うのは、公開かつ未認証の範囲だけです。法的に最も安全な線であり、アカウントを BAN されずに済む線でもあります。

Twitter のスクレイピングは合法か？ {#is-it-legal-to-scrape-twitter}

公開の Twitter データのスクレイピングは、はっきり見解が割れる領域にあります。米国の裁判所は概ねこれを保護してきた一方、X 自身の利用規約はきっぱり禁止しています。両方が同時に成り立っており、どちらが効いてくるかは、刑事法上のリスクを気にするのか、契約上のリスクを気にするのかで変わります。

判例の側では、天秤は公開データに傾いています。2022年、第9巡回区は、公開されている情報のスクレイピングがコンピュータ詐欺および濫用防止法に違反しないと認めました。hiQ 対 LinkedIn の一連の判例が最もよく引用されます。X 自身もこれを正面から争い、敗れています。連邦裁判所は2024年5月に X Corp. 対 Bright Data を却下し、スクレイパーに対する X の主張は大部分が専占されていると判断しました。X が Center for Countering Digital Hate に対して起こした訴訟も、憲法修正第1条を理由に却下されています。真に公開されたデータへのアクセスは、CFAA 上の犯罪にはあたりません。

契約の側では、X の規約のほうが厳しい制約になります。2026年1月15日発効の現行規約は、事前の書面による同意なしに「いかなる形式でも、いかなる目的でも」クローリングやスクレイピングを行うことを禁じています。さらに損害賠償額の予定条項が置かれました。規約に違反して24時間の間に1,000,000件を超える投稿を要求・閲覧・アクセスした者は、100万投稿あたり$15,000（EU・EFTA・英国では同額のユーロ建て）を支払うことに同意する、という内容です。2026年の更新では「コンテンツ」の定義が AI のプロンプトと出力を含むよう改められ、ジェイルブレイクやプロンプトインジェクションを狙った悪用条項が加わり、裁判地はテキサス州、集団訴訟の放棄も定められました。規約違反は犯罪ではなく契約の問題ですが、X はアカウントを凍結し、IP をブロックし、規模の大きい相手にはこの条項を持ち出せます。

公開データのスクレイピングを弁明できる範囲に保つルールは3つです。公開データだけを取得し、非公開アカウント、DM、ログインの内側にあるものには手を出さないこと。ため込まないこと、つまり取得したデータは用途に必要な期間だけ保持すること。そしてレート制限を尊重すること。サーバーに過負荷をかけたところから、法的リスクは具体的になります。EU の読者にはもう1層あります。公開の投稿にも個人データが含まれ得るため、保存や処理を行う時点で GDPR が適用されます。以上は情報提供であり、法的助言ではありません。機微なデータや大量のデータを扱う用途なら、弁護士に相談してください。

X.com の内部構造 {#how-xcom-works-under-the-hood}

X のアーキテクチャがわかると、どのスクレイパーもいずれ壊れる理由が見えてきます。他のサイトをスクレイピングした経験があっても、X の防御は別次元で、その理由は偶発的なものではなく構造的なものです。

X は React のシングルページアプリケーションです。プロフィールやツイートの URL を開くと、サーバーが返すのはほぼ空の HTML の殻です。そこから JavaScript がバックエンドにゲストトークンを要求し、GraphQL クエリを発行して実データを取得し、ブラウザがそれを描画します。最初の HTML には有用なものがほとんど入っていないため、単純に取得してパースするだけのスクレイピングでは何も得られません。この設計が、X に3つの関所を与えています。

ゲストトークンは、すべての GraphQL 呼び出しに必要な一時的な認証情報です。アクセス元の IP に紐づき、数時間で期限が切れ、発行のされ方は数週間ごとに変わります。X がトークンの発行方式を変えると、古い方式に依存するスクレイパーは即座に止まります。無料のライブラリ群を葬ったのは、まさにこの仕組みです。いずれも、もはや存在しない匿名アクセスの経路を前提にしていました。

GraphQL の操作 ID（doc_ids） は、X の JavaScript バンドルに埋め込まれた識別子で、どの操作を実行するかをバックエンドに伝えます。プロフィールの取得、ツイートの検索、タイムラインの読み込みは、それぞれ別の ID を必要とします。X はこれを2〜4週間ごとにローテーションするため、一度に8〜12個を追跡することになります。ドキュメントは存在しないので、圧縮された JavaScript からリバースエンジニアリングし、2週間後にまた同じ作業をします。ブラウザで動かすスクレイパーなら、ページ自身に現行の doc_ids を要求させることで、この手間を回避できます。

レート制限と検出が3つ目の層です。X はゲストセッションに対し、IP あたりおよそ1時間300リクエストを課します。データセンターの IP は1〜2リクエストでフラグが立ちます。TLS フィンガープリンティングは、ネットワークスタックが本物を完璧には模倣できていないヘッドレスブラウザを捕らえ、クッキーの検証は疑わしいセッションのパターンにフラグを立てます。使っているアカウントにフラグが立った場合は、無料のシャドウバン確認ツールが数秒で判定します。

これらの防御は止まっていません。次の表は、X が何をいつ変えたかの記録です。1年前のスクレイピングガイドですら、すでに死んだツールを指し示してしまう理由がここにあります。

要するに、X は安定した相手ではありません。防御側の変更をおよそ2〜4週間ごとに投入してくるため、スクレイパーを持つ以上、追随の作業は終わりません。

方法1：ヘッドレスブラウザによるスクレイピング（コード付き） {#method-1-headless-browser-scraping-with-code}

自作でいちばんよく採られるのは、実物のブラウザを自動操作して X のページを読み込み、データを運ぶ GraphQL レスポンスを傍受するやり方です。X が想定するとおりの JavaScript がそのまま走るため、ページ自身が現行の doc_ids を要求し、人間が見るときと同じようにデータが描画されます。操作 ID を手作業で追いかける必要はありません。

以下は、背後で走る TweetResultByRestId の呼び出しを捕まえて1件のツイートを取得する、Playwright を使った最小限の Python の例です。

from playwright.sync_api import sync_playwright
import json

def scrape_tweet(url: str) -> dict:
    xhr_calls = []

    def capture_response(response):
        if response.request.resource_type == "xhr":
            xhr_calls.append(response)

    with sync_playwright() as pw:
        browser = pw.chromium.launch(headless=True)
        page = browser.new_page()
        page.on("response", capture_response)
        page.goto(url)
        page.wait_for_selector("[data-testid='tweet']", timeout=15000)

        for xhr in xhr_calls:
            if "TweetResultByRestId" in xhr.url:
                data = xhr.json()
                return data["data"]["tweetResult"]["result"]

    return {}

tweet = scrape_tweet("https://x.com/elonmusk/status/1234567890")
print(json.dumps(tweet, indent=2))

このスクリプトは Chromium を起動してツイートのページへ移動し、描画を待ってから、背後の XHR 呼び出しの中からツイートデータを運ぶものを絞り込みます。得られるのは完全なツイートオブジェクトです。本文、タイムスタンプ、エンゲージメント数、メディアの URL、投稿者のプロフィールが入っています。ツイートの各項目は legacy キーの下に入れ子になっているため、本番では生のツリーをそのまま保存せず、必要なもの（本文、created_at、favorite_count、retweet_count、reply_count、view_count）だけをフラットに整形します。

同じパターンは、XHR の URL で別の操作を拾えば他の範囲にも使えます。プロフィールなら UserByScreenName、ユーザーのタイムラインなら UserTweets、検索なら SearchTimeline です（ただし検索にはログイン済みのセッションが必要です）。プロフィールの場合は、ツイートのセレクタではなく UserByScreenName の到着を待ち、そのレスポンスからユーザーオブジェクトを読み取ります。

取得できるもの： 公開プロフィール、個々のツイート、表示されるリプライ、引用（引用リポスト）、埋め込みメディア。要するに、公開インターフェースに出ているものはひととおり取れます。

ログインなしでは取得できないもの： 非公開アカウント、DM、フォロワー一覧の全体、検索結果や長いタイムラインの全件。認証してスクレイピングすれば届きますが、BAN のリスクを負います。

動かし続けるのに必要なもの。 データセンターの IP はほぼ即座にブロックされるため、住宅用プロキシは譲れません。1ギガバイトあたり$1〜$3、量に応じて月額$50〜$200を見込みます。フィンガープリントの偽装、現実的なビューポートのサイズ、人間らしくばらつかせた待ち時間に加えて、セッション途中で切れるトークンや、doc_ids のローテーション時に空の結果を返す GraphQL エンドポイントへのリトライ処理も要ります。この構成は今日は動きますが、X の次の更新から2〜4週間以内に壊れるので、維持に月10〜15時間を見ておいてください。

方法2：オープンソースの Python ライブラリ {#method-2-open-source-python-libraries}

ゼロから組む代わりに、X の内部 API をラップしたライブラリを使う手もあります。活発にメンテナンスされて現在も動くもの、広く勧められているのに死んでいるもの、そしてかつての定番で本家が壊れているものが混在しています。2026年7月に GitHub と PyPI で再確認した、正直な全体像は次のとおりです。

この表の肝は状況の列で、その中身は入れ替わり続けます。Twikit は非同期で、ドキュメントが整い、コミュニティも最大だったため長らく第一候補でしたが、PyPI で公開されているリリースが X の2026年の webpack 変更とトランザクション ID の変更で壊れ、利用者は twikit のインポート名をそのまま保つメンテナンス済みフォークへ移りました。いまだに pip install twikit で問題なく動くと書いているチュートリアルを見かけたら、まず日付と未解決の issue を確認してください。今日の読み取り専用のデータ収集で、より確実なのは twscrape です。

twscrape はまさにこの用途のために作られています。トークンかクッキーで認証し、セッションをローカルのデータベースに保持し、複数アカウントのローテーションを内蔵しているため、リクエストをアカウントのプールに分散させ、単一アカウントの構成より速くレート制限を抜けていきます。CLI での検索例は twscrape search "from:xdevelopers lang:en" --limit=20 と短く、Python API もこれに対応します。知っておくべきトレードオフは、非同期のみであること、設計上読み取り専用であること、再開機能がないため、数日がかりの大量取得には自前のチェックポイント処理が要ることです。

墓場（時間を無駄にしないために）

チュートリアルがこれらを現行の解決策として勧めていたら、その記事の日付を見れば理由がわかります。X のスクレイピング事情は入れ替わりが速く、動作する側の表に日付を打っているのはそのためです。前の四半期に動いたライブラリが、今四半期には死んでいることがあります。

動作するライブラリに共通する落とし穴

動作する側の表にあるライブラリは、いずれもログイン済みの X アカウントを必要とし、それには代償が伴います。X は自動化された挙動を示すアカウントを凍結し、新規のスクレイピング用アカウントの本人確認も厳しくなったため、個人アカウントは絶対に使わないでください。実用的な量をさばくには専用アカウントを複数とローテーションの仕組みが要り、住宅用プロキシも依然として必要です。そして活発にメンテナンスされているライブラリでさえ X の更新で壊れ、そのときはメンテナーの対応を待つか、誰かがフォークするのを待つことになります。

方法3：AI 支援のスクレイピング {#method-3-ai-assisted-scraping}

AI 支援のスクレイピングは、壊れやすい CSS セレクタを、ページを読んで指示どおりの内容を抜き出す言語モデルに置き換えます。オープンソースで最も知られているのは ScrapeGraphAI です。「各ツイートの本文、投稿者、いいね数を取得して」といったプロンプトを書くと、構造のほうをモデルが割り出す Python ライブラリで、X がレイアウトを変えても、名前の変わった要素で止まる代わりに適応し直します。

これは保守の問題に対する本物の答えであり、トレードオフも本物です。モデルもページに到達しなければならないので、プロキシ、アカウント、ボット対策の要件は他の方法とまったく同じで、そのどれも LLM（大規模言語モデル）は解決しません。加えて、抽出のたびにトークンを消費するため、コストとレイテンシが増え、固定のパーサーより出力が決定論的でなくなります。向くのは試作と、頻繁に変わるレイアウトです。逆に、レコードあたりのコストを見通しながら安価に大量収集を繰り返す用途には向きません。予測可能なコストと保守ゼロが目標なら、構造化されたデータ API のほうが、AI スクレイピングが目指しているものをきれいな形で実現します。

方法4：マネージドスクレイピングサービス {#method-4-managed-scraping-services}

マネージドサービスは、スクレイピングのインフラを代わりに運用します。クエリか URL を送ると構造化データが返り、プロキシのローテーション、トークンの管理、ボット対策の回避はサービス側の仕事です。比較対象になる名前は Bright Data、Apify、Scrapfly で、Scweet も小さな無料枠付きのホスト版を Apify 上で提供しています。利点は、保守するコードも管理するプロキシもないことです。難点は、規模が大きくなったときのコストとベンダー依存です。サービス側のスクレイパーが壊れれば修正を待つことになり、料金モデルもツイート単位、計算単位、プロキシトラフィックのギガバイト単位とばらばらで、表示価格からレコードあたりの実コストを比べるのは容易ではありません。

これは独立した比較に値するほど大きな判断です。マネージドの各選択肢について、1,000件あたりの実コスト、信頼性、隠れコストを知りたい場合は、Twitter スクレイピングツール比較をご覧ください。

スクレイピング対象のツイート・プロフィール URL の見つけ方 {#how-to-find-tweet-and-profile-urls-to-scrape}

ここまでのどの方法にも対象が要ります。取得したい個々のツイートとプロフィールの URL です。X 自身の検索はログインの内側にあるため、現実的な回避策は Google になります。公開ツイートはインデックスされているので、site: 検索がアカウントなしで対象リストを作る最短ルートになることも少なくありません。

よく使うパターンは3つです。site:x.com inurl:status <キーワード> は、あるトピックについての個々のツイートを拾います。site:x.com <名前> は、人物やブランドのプロフィールページを見つけます。Google の期間指定を併用すれば、新しい投稿に絞り込めます。正直な注意点は1つ、Google のインデックスはリアルタイムの X から数時間〜数日遅れることです。速報性のある内容には向きませんが、スクレイピング対象のプロフィールや投稿のリストを組み立てる用途なら十分に使えます。静的なリストではなくリアルタイムの発見が必要なら、まさにそこがクロールよりクエリ検索の勝つ場面で、ツイート検索APIなら条件に合うツイートを直接返します。

スクレイピングの実際のコスト {#what-scraping-actually-costs}

ほとんどのチュートリアルは、ツールの表示価格を挙げてそこで終わります。X をスクレイピングする実際のコストは、ツールの料金に住宅用プロキシ、開発者の工数、そして壊れるたびに発生する費用を足したものです。各ルートの全体像は次のとおりです。

決め手になる行は保守です。開発者の工数はこの一覧で最も高価な項目ですが、X が初めて doc_ids をローテーションし、金曜日にパイプラインが沈黙するまで表に出てきません。これまで関わってきたチームは、自作の X スクレイパーを生かし続けるのに日常的に月10〜15時間を使い、その上にプロキシ代が乗っていました。規模感としては、ブラウザ自動操作で10,000件のツイートを取るとおよそ50〜100リクエストと、数ドル分の住宅用プロキシのトラフィックがかかります。しかもこれは工数を数える前の話です。無料のツールは、自分の時間に値段をつけた瞬間に無料ではなくなります。

方法5：読み取り専用のデータ API（スクレイピングなし） {#method-5-a-read-only-data-api-no-scraping}

ここまで読んだ方への正直な要点は、X のスクレイピングは可能でも時間・費用・継続的な労力の面で高くつくこと、そして多くの用途ではそもそもスクレイピングが要らないことです。読み取り専用の X データ API は、同じ情報をプレーンな REST エンドポイントで返します。プロフィール、ツイート、検索、フォロワー、エンゲージメント、コミュニティのデータが、すべてきれいな JSON として、ヘッダーに API キーを1つ入れるだけで返り、プロキシもゲストトークンも doc_ids もありません。

Sorsa の API でプロフィールを照会すると、こうなります。

curl -H "ApiKey: YOUR_KEY" \
  "https://api.sorsa.io/v3/info?username=elonmusk"

これで完全なプロフィールオブジェクトが1行で返ります。ID、ユーザー名、表示名、プロフィール文、フォロワー数とフォロー数、ツイート数、認証バッジの有無、画像、作成日です。先ほどの20行以上の Playwright と、その例には出てすらいないプロキシの設定、トークンの管理、リトライ処理と比べてみてください。

Sorsa では、ユーザー、ツイート、検索、フォロワー、確認系、コミュニティ、リスト、トレンドという8つのカテゴリにわたる40個のエンドポイントを、エンドポイントごとの時間枠なしの一律で毎秒20リクエストという条件で提供しています。料金はバッチエンドポイントで1,000ツイートあたり$0.02、1,000プロフィールあたり$0.01からです。/info-batch（最大100プロフィール）や /tweet-info-bulk（最大100ツイート）のような呼び出しは、それぞれ1リクエストとしてカウントされます。100回分の無料リクエストはクレジットカード不要で使え、プレイグラウンドならコードなしで任意のエンドポイントを試せます。3分のクイックスタートなら、承認を待たずに最初の呼び出しが動きます。公式X APIから移る場合は、移行ガイドがエンドポイント単位の対応関係を示します。

トレードオフははっきり書いておきます。API は読み取り専用なので、投稿・いいね・フォローはできず、自前のコードではなくプロバイダーに依存することになります。動き続けることが前提の読み取り中心の用途では、たいていそこが利点になります。

実例：壊れなくなった監視パイプライン

中規模のフィンテック分析チームから、数百の金融アカウントと競合アカウントを対象にしたリアルタイム監視を自作の Playwright スクレイパーで回している状態で、相談がありました。動いているうちは問題なかったのですが、X が doc_ids をローテーションするたびにパイプラインは沈黙し、エンジニアが1日を費やして新しい識別子をリバースエンジニアリングし直し、プロキシを入れ替えていました。開発者の工数と住宅用プロキシを合わせると、日常業務として扱っていたデータの実際の月額コストは$2,000を超えていました。

同チームは読み取り側をデータ API に移し、本当に自分たちの資産である部分だけを作り続けることにしました。X が向こう側で何を変えても同じ REST 呼び出しが毎日同じ JSON を返すため、継続的なエンジニアリングの消耗はゼロになり、支出もプロキシと工数の合計のごく一部まで下がりました。コストが下がったのは、プロキシ込みのアカウント単位のスクレイピングから、フラットなリクエスト単価の課金へ切り替えたことの構造的な結果です。保守が減ったのは、単にスクレイパーの運用をやめたからにすぎません。クライアント名と監視対象を挙げると双方が特定されかねないため、この事例は匿名にしています。

どの方法を選ぶべきか？ {#which-method-should-you-use}

万能の勝者はいません。正しい選択は、扱う量、予算、そしてどれだけの停止時間を許容できるかで決まります。

ヘッドレスブラウザが向くのは、抽出を細かく制御したい場合、スキルとしてスクレイピングを学んでいる場合、あるいはワークフローが本当に個別仕様で既存のツールが合わない場合です。オープンソースライブラリは、自作より速く始めたく、アカウント凍結のリスクと保守を受け入れられる場合に使います。マネージドスクレイパーは、インフラを外に出したく、コストより稼働の安定を重視する場合です。読み取り専用のデータ API は、読み取りを確実に回したい場合、毎週の故障に耐えられない場合、あるいは X データの上に製品を出す場合に選びます。そして投稿、DM、フォローなど書き込みを伴うものは、公式X APIのままにしてください。スクレイパーも読み取り API も書き込み操作を安全には行えず、広告データやコンプライアンスデータについても同じことが言えます。

プロバイダーをもっと広く見たい場合はTwitter API 代替サービス比較のガイドを、公式 API が今いくらかかるかはX API 料金の詳細を、無料枠が生き残ったかどうかが気になる場合は2026年に X API は無料かをご覧ください。

よくある質問 {#faq}

2026年でも Twitter はスクレイピングできる？

はい、公開の Twitter データは2026年も公式 API なしで取得できますが、簡単な経路はもうありません。匿名アクセスに依存していた無料のライブラリは死に、ゲスト閲覧にはレート制限がかかり、X は内部のゲストトークンと GraphQL 識別子を2〜4週間ごとにローテーションします。今日通用する方法は、ヘッドレスブラウザの自動操作、ログイン済みアカウントで動かすメンテナンス継続中のオープンソースライブラリ、マネージドのスクレイパー、または読み取り専用のデータ API です。

ログインせずに Twitter をスクレイピングできる？

できますが、制限は重いです。認証なしの場合、ヘッドレスブラウザによるスクレイピングで届くのは公開プロフィールと個々のツイートまでで、検索の全件、タイムラインの全体、深いスレッド、フォロワー一覧は制限されるかブロックされます。完全なデータアクセスを提供するオープンソースライブラリは、いずれもアカウントの認証情報かセッショントークンを必要とし、それが完全なデータを開く鍵になります。

2026年に Twitter をスクレイピングする最良のツールは？

用途によります。大量の読み取り専用のデータ収集なら、複数アカウントのローテーションを内蔵した twscrape が、メンテナンスの続くライブラリの中で最も確実です。Scweet と Tweety も動作します。Twikit は本家のリリースが X の2026年の変更で現在動かず、コミュニティのフォークで動いているため、頼る前に状況を確認してください。プロキシも BAN されるアカウントもない保守ゼロのアクセスなら、Sorsa のような読み取り専用のデータ API が同じデータを REST エンドポイントで返します。1,000ツイートあたり$0.02から、最初の100回分の無料リクエスト付きです。

Python で Twitter をスクレイピングできる？

はい、Python が最も一般的な言語です。Playwright でヘッドレスブラウザを動かして X の GraphQL レスポンスを捕まえるか、ライブラリを使う方法があります。複数アカウントでのデータ収集なら twscrape、クッキー＋GraphQL 方式なら Scweet、軽量な取得なら Tweety です。Tweepy もありますが、これはスクレイピングではなく公式の有料 API のラッパーです。スクレイパーより API のほうが合うなら、X（Twitter）API Python ガイドが REST での進め方を案内します。

Twitter のスクレイピングは合法？

真に公開されたデータのスクレイピングは、米国では概ね合法とされています。公開ウェブのデータへのアクセスはコンピュータ詐欺および濫用防止法に違反しない、と裁判所が判断してきたためです。ただし X の利用規約には違反し得ます。これは犯罪ではなく契約の問題ですが、アカウントや IP の BAN につながります。非公開データへのアクセスは CFAA の一線を越えます。EU では、保存または処理する公開の投稿に個人データが含まれる場合に GDPR が適用されます。以上は情報提供であり、法的助言ではありません。

公式 X API にはまだ無料枠がある？

ありません。X は無料枠を廃止し、新規開発者向けに従量課金の料金へ移行しました。前払いでクレジットを購入し、リソース単位で支払います。投稿の読み取りが約$0.005、ユーザープロフィールが$0.010、投稿の作成が$0.015で、標準アカウントでは投稿読み取りに月間200万件の上限があります。姉妹ガイドのX API は無料かが、現行の選択肢を扱っています。

X はどのくらいの頻度でスクレイパーを壊す？

平均して2〜4週間ごとです。よくある引き金は、ゲストトークンの発行方式の変更、GraphQL の操作 ID のローテーション、そして新しいボット対策の検出層です。自作でもライブラリベースでも、どのスクレイパーも動き続けるには定期的な更新が必要で、この継続的な保守こそがスクレイピングという方法の最大の隠れコストです。

本ガイドの検証方法 {#how-we-verified-this-guide}

本ガイドは、X データ API を運用し X のライブエンドポイントに対してテストしてきた Sorsa 自身の作業と、各ツールの現状を新たに調べ直した結果に基づいています。今回の改訂では、オープンソースのライブラリを GitHub と PyPI で直接再確認し、何がメンテナンスされているかを確かめました（twscrape、Scweet、Tweety は2026年も活発。snscrape、Twint、ntscraper は停止。Twikit は本家のリリースが壊れており、コミュニティのフォークで動いています）。あわせて、2026年1月15日発効の X の利用規約をスクレイピングと損害賠償額の予定の文言について読み、判例の節では第9巡回区の CFAA 判決に関する EFF の要約を用いました。Sorsa 自身の API の料金は Sorsa のドキュメントに拠ります。X の利用規約と公式 X API の料金は2026年7月に再確認し、オープンソースライブラリの整理も同じ月にテストしました。ライブラリもプラットフォームの規約も変化が速いので、時間に左右される情報は、頼る前に出典で確認し直してください。