Threads をスクレイピングする方法（2026年版・API と Python）

2026年に Threads を最速でスクレイピングする方法は、公開プロフィール・投稿・返信をきれいな JSON として返す構造化 API です。Python とヘッドレスブラウザを使って自作することも依然として可能ですが、Threads は JavaScript なしでは何もレンダリングせず、自作スクレイピングを機能させる一連の細かい工夫 — セッション Cookie、カーソルベースのページネーション、リトライとバックオフ — は、まさにマネージド API が取り除くべきメンテナンス負荷そのものです。このガイドでは3つのアプローチすべてを扱います。それぞれ何が取得でき、どこで壊れるか、そして法的な基礎知識です。

なぜ Threads をスクレイピングするのか？

Threads はブランドや製品に関する公開の会話が交わされる実質的な場所になっており、繰り返し発生するタスクがいくつかあります。

• ソーシャルリスニング — 公開の投稿や返信の中でブランド、製品、競合の言及を追跡する。
• センチメント・キャンペーン追跡 — ローンチやキャンペーンへの反応をほぼリアルタイムで測定する。
• 競合モニタリング — 競合の投稿頻度、エンゲージメント、フォロワー増加を観察する。
• トレンド・ハッシュタグ調査 — キーワードやトピックに一致する投稿を取得し、何が注目を集めているかを把握する。

Threads のスクレイピングは合法ですか？

Meta の Automated Data Collection Terms は、「自動化された手段（当社の事前の許可なし）」でプラットフォームからデータを収集することを明示的に禁止しており、robots.txt の順守を求めています。書面上は、収集する内容にかかわらず、Threads のスクレイピングは利用規約違反となります。

しかし判例法は、ログアウト状態で公開データにアクセスする場合 についてこの規約の強制力を狭めています。Meta v. Bright Data（北カリフォルニア地区連邦地裁、2024年1月）では、裁判所は Bright Data に有利な略式判決を下し、Meta の利用規約はログイン済みのアカウント保有者のみを拘束するものであり、アカウントを持たずに公開ページをスクレイピングする者にまで広げて適用することはできないと判断しました。Meta は残りの請求を取り下げ、控訴もしませんでした。これは hiQ Labs v. LinkedIn と同じ論理に従っています。ログインしなくても閲覧できるデータをスクレイピングすることは CFAA の下での「不正アクセス」には当たりません。ただし、hiQ 自身はその後、契約法および州法上の請求で敗訴し、LinkedIn のスクレイピングを永久に差し止められています。

まとめると、公開かつログアウト状態の Threads コンテンツのスクレイピングは連邦のコンピュータ不正行為に関する法的リスクにはなりませんが、それでも利用規約違反であり、Meta はスクレイピング業者を直接訴えてきた実績があります。公開データのみを収集し、ログインの壁を絶対に迂回せず、ユーザー名・プロフィール・投稿本文は GDPR/CCPA の下で個人データとして扱ってください。全体像については ウェブスクレイピングは2026年に合法ですか？ をご覧ください。

選択肢1：Python での自作（そしてなぜ壊れるのか）

Threads.net は JavaScript なしではレンダリングされません。静的な HTML フォールバックが存在しないため、単純な requests.get() は空のシェルを返すだけです。実際のデータはレンダリングされたページ上の <script type="application/json" data-sjs> タグ内に JSON として埋め込まれており、単純なパーサーではなくヘッドレスブラウザ + JSON 抽出が必要になります。

from playwright.sync_api import sync_playwright
import json, re

def get_threads_profile(username):
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()
        page.goto(f"https://www.threads.net/@{username}")
        page.wait_for_load_state("networkidle")
        html = page.content()
        browser.close()

    # Data lives inside embedded JSON blobs, not the visible DOM
    match = re.search(r'<script type="application/json" data-sjs>(.*?)</script>', html)
    if not match:
        raise ValueError("Could not locate embedded profile JSON")
    return json.loads(match.group(1))

実運用で壊れる理由：

• JS なし、データなし。 プロフィール、フォロワー数、投稿など、あらゆるフィールドがデプロイのたびに変化する、ネストされた未文書化の JSON 構造の中にあります。
• 検索とディスカバリーにはセッションが必要です。 キーワード検索はモバイルアプリからか、ログインした状態でしか機能しません。ログアウト状態の Python スクリプトはそこにまったく到達できません。
• ページネーションはカーソルベースで不透明です。 さらに投稿や返信を読み込むには、単純な page=2 ではなく内部のカーソルトークンを引き継ぐ必要があります。
• レート制限が 403 を引き起こします。 バックオフなしで継続的にリクエストを送ると block され、IP ベースの制限がセッションごとに適用されます。
• Instagram や TikTok よりは軽いですが、皆無ではありません。 Threads の Bot 対策の姿勢は現在、Meta の兄弟プラットフォームほど積極的ではありませんが、これは有用な参考情報であって、この状態が続く保証ではありません。

選択肢2：ノーコードツール

クリック操作だけで使えるスクレイパーやブラウザ拡張機能は、1回限りのエクスポート用に Threads のプロフィールや短い投稿リストを取得できます。単発のレポートには十分ですが、パイプラインとしては機能しません。スケジューリングもなく、最初のバッチ以降のページネーションもなく、依存している JSON 構造は予告なく変化します。

選択肢3：構造化された Threads API

マネージド API はヘッドレスブラウザによるレンダリング、JSON 抽出、ページネーション処理を吸収し、壊れやすいスクレイプの代わりに正規化されたデータを返します。

curl -G "https://api.crawlora.net/api/v1/threads/profile/zuck" \
  -H "x-api-key: $CRAWLORA_API_KEY"

import requests

resp = requests.get(
    "https://api.crawlora.net/api/v1/threads/profile/zuck",
    headers={"x-api-key": "YOUR_API_KEY"},
)
profile = resp.json()["data"]
print(profile["name"], profile["followers_count"], profile["threads_count"])

レスポンス例（フィールドは説明用の例です — 完全なスキーマはドキュメントで確認してください）：

{
  "data": {
    "username": "zuck",
    "name": "Mark Zuckerberg",
    "url": "https://www.threads.net/@zuck",
    "biography": "Building the future.",
    "followers_count": 12500000,
    "threads_count": 842,
    "avatar_url": "https://scontent.cdninstagram.com/..."
  }
}

プロフィールの最近の投稿、単一の投稿の詳細、その返信、キーワード検索のいずれを取得する場合も、すべて同じ構造に従います。

curl -G "https://api.crawlora.net/api/v1/threads/profile/zuck/posts" \
  -H "x-api-key: $CRAWLORA_API_KEY" \
  --data-urlencode "cursor="

resp = requests.get(
    "https://api.crawlora.net/api/v1/threads/search",
    headers={"x-api-key": "YOUR_API_KEY"},
    params={"q": "web scraping"},
)
for post in resp.json()["data"]["items"]:
    print(post["author"]["username"], post["like_count"], post["text"])

posts/search/replies のいずれのレスポンスも、id、code、url、text、author.{id,name,username}、created_at、エンゲージメント数（like_count、reply_count、repost_count、quote_count）、メディア URL を含む items[] を返し、さらにページネーション用の has_more/next_cursor を返します。プロフィールのフィードを辿る場合も検索結果を辿る場合も、同じスキーマです。

どのアプローチを使うべきか？

収集できるもの

• プロフィールデータ — ユーザー名、表示名、プロフィール、フォロワー数、投稿数、アバター
• 投稿コンテンツ — テキスト、メディア URL、タイムスタンプ、投稿者
• エンゲージメント指標 — いいね、返信、リポスト、引用
• 返信とスレッド — 特定の投稿に対する返信チェーン全体
• 検索結果 — キーワードやトピックに一致する投稿

制約とよくある課題

• DIY モードではセッションなしでの任意キーワード検索ができません。 検索は、ログイン状態を最初に要求される機能のひとつです。
• レート制限は IP/セッション単位で適用されます。 継続的な取得にはバックオフとローテーションが必要です。
• 内部の JSON スキーマは文書化されておらず、安定していません。 Meta はデプロイのたびに変更ログなしで構造を作り替えることがあります。
• 公開データのみが対象です。 非公開アカウントや非公開コンテンツは、ここで紹介したどのアプローチでも対象外であり、対象外のままであるべきです。

この機能が役立つ場面

Threads のデータは、他のソーシャルプラットフォームと同じワークフローを支えます。クロスプラットフォームのセンチメント分析には Reddit と組み合わせ、より広範なソーシャルリスニングには X/Twitter と組み合わせてください。利用可能な全エンドポイントについては、Threads API の完全なリファレンスをご覧ください。

出典

さっそく始める

Playground で Threads のエンドポイントをテストし、API ドキュメント で完全なスキーマを読み、料金ページ でクレジット費用を確認してください。関連するソーシャルデータのガイドとして、Reddit をスクレイピングする方法、Twitter/X をスクレイピングする方法、ウェブスクレイピングは2026年に合法ですか？ もご覧ください。

How-to-scrape ガイドシリーズの一部です — 私たちがカバーする全プラットフォームを1か所にまとめています。