Blueskyのスクレイピング方法【2026年版】（API & Python）

Bluesky はこのシリーズの中で最もオープンなプラットフォームであり、はっきり言っておく価値があります。動いている基盤の AT Protocol はゼロ認証での公開データ読み取りのために設計されており、ここには突破すべき鍵のかかったドアは存在しません。Bluesky 自身の開発者ドキュメントも、公開 AppView とネットワークのファイアホースはどちらも公開データに対して認証を必要としないことを確認していますし、Bluesky の利用規約にはスクレイピングや自動アクセスに関する制限が一切含まれていません。このガイドではプロトコル自身のオープンなアクセス方法、ノーコードツール、そして構造化 API を取り上げますが、ここでの API の価値は何かを「解錠」することではない、と正直に述べておきます。

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

Bluesky の公開フィード、フォロワーグラフ、スレッドは、いくつかの繰り返し発生するユースケースを支えています。

• ソーシャルリスニングとトレンド追跡 — ブランド、トピック、あるいはハッシュタグに相当するキーワードが Bluesky 上でほぼリアルタイムにどれだけ話題になっているかを把握できます。
• クリエイター・アカウントリサーチ — アウトリーチや競合リサーチのために、ハンドルのプロフィール、投稿履歴、フォロワー／フォロー数を取得できます。
• 会話・スレッド分析 — 投稿の完全な返信ツリーを読んで、特定の会話がどのように展開したかを把握できます。
• クロスプラットフォームでの比較 — Bluesky の動向をX/TwitterやThreadsのデータと組み合わせて、あるストーリーやアカウントが実際にどこで反響を得ているかを確認できます。
• トレンドトピックのモニタリング — 自分でキーワードリストを維持しなくても、プラットフォーム全体で何が話題になっているかを追跡できます。

Bluesky をスクレイピングするのは合法か？

Bluesky の利用規約（最終更新2025年8月14日）には、スクレイピング、robots、データマイニング、自動アクセスに関する制限が含まれていません——文書全体を検索しても、これらの用語に該当する条項は一切見つかりません。これはこのシリーズで扱うほとんどのプラットフォームとは明確に異なる点です。多くのプラットフォームでは Conditions of Use や Automated Data Collection Terms のページで、ボットやクローラーが明示的に禁止されています。Bluesky 自身の開発者ドキュメントはさらに踏み込んでおり、API Hosts and Auth guide には「Bluesky の Lexicon エンドポイントの多くは公開されており、認証を必要としない」とはっきり書かれており、ネットワークのファイアホースも「認証を必要としない」とされています。スタックの一部——リファレンスクライアントや、プロトコルのコアコードの多く——も、利用規約の Open Source Software セクションに従って MIT および Apache のオープンソースライセンスで公開されています。

とはいえ、これは何をしてもいいという白紙委任ではありません。公開されているものだけを収集し（非公開アカウントや DM は決して対象になりません）、該当する場合は GDPR／CCPA のもとでハンドル、自己紹介文、投稿テキストを個人データとして扱い、Bluesky のレート制限ガイドが述べているように、AppView の制限は「寛大」ではあっても実在するものであり、継続的な乱用はスロットリングの対象になり得ます。より詳しい全体像についてはウェブスクレイピングは合法かを参照してください。

選択肢1: AT Protocol を直接使う（そして実際に必要になる作業）

Bluesky の公開データ読み取りには認証が不要なため、AppView に対して普通の HTTP リクエストを直接送るだけで済みます——キーもセッションもログインも要りません。

curl "https://public.api.bsky.app/xrpc/app.bsky.feed.getAuthorFeed?actor=bsky.app&limit=5"

これはプロトコル自身のオープンなアクセスが設計通りに機能している例です——app.bsky.feed.getAuthorFeed は実在する、ドキュメント化された Lexicon エンドポイントであり、いかなる認証情報もなしに実際の投稿データを返します。したがって、このシリーズのほぼすべての他のガイドとは異なり、ここでの障害はアンチボット対策やログインの壁ではありません——公開データに関して、そもそもそうしたものは存在しないのです。実際の作業が発生するのは、単発のルックアップを超えたところからです。

• 正規化された JSON ではなく、生の AT Protocol レコード。 各 Lexicon エンドポイントは、それぞれ独自のスキーマ（app.bsky.feed.post、app.bsky.actor.profile など）に沿ったレコードを返し、ネストされた at:// URI、CID、DID を含みます。下流で使えるデータにするには、これらを自分で解決してフラット化する必要があります。
• DID の解決はそれ自体が一つのサブシステムです。 すべてのアカウントとレコードは、安定したユーザー名ではなく、分散識別子（DID）でキー付けされています。ハンドルは変更され得るため、実運用のパイプラインでは、検索したハンドルをそのまま保存するのではなく、DID とハンドルの対応関係を解決してキャッシュする必要があります。
• ファイアホースこそが本当のインフラ投資です。 1アカウントずつではなく、ネットワーク全体のすべての公開投稿が欲しい場合は、com.atproto.sync.subscribeRepos——CBOR エンコードされたリポジトリ更新の WebSocket ストリーム——か、より軽量な JSON 版の Jetstream を消費することになります。そしてそのコンシューマーを、カーソル追跡、再接続ロジック、CBOR／MST のデコードとともに継続的に稼働させる必要があります。
• このプラットフォームだけのために、1つのプロトコル、1つのメンタルモデルが必要になります。 すでに Reddit、TikTok、Instagram、X、Threads を1つのスキーマに正規化しているパイプラインにとって、AT Protocol のレコード／Lexicon／DID モデルは、それらの隣に組み込むにはまったく異なる形をしています——オープンではあるものの、他のどこから取得しているデータとも同じ形ではありません。

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

Bluesky のエクスポート用に、マーケットプレイスのスクレイパーアクターやブラウザ拡張機能も存在しますが、基盤となる API がすでにオープンでキー不要である以上、そのほとんどは上で説明した同じ公開 AppView エンドポイントの薄いラッパーに過ぎません。単発のプロフィール取得やスプレッドシートへのエクスポートには十分ですが、実際のギャップ——プラットフォーム横断での正規化されたフィールドや、メンテナンスされたファイアホースのコンシューマー——を解決するわけではなく、その点は AppView を直接呼び出すのと変わりません。

選択肢3: 構造化された Bluesky API（Crawlora経由）

他のソーシャルプラットフォームと並べて、Bluesky を1つの正規化された形で扱いたい場合——1つの API キー、1つの JSON スキーマ、稼働させるファイアホースのインフラなし——Bluesky スクレイピング API がそれを提供します。プロフィールを取得してみましょう。

curl "https://api.crawlora.net/api/v1/bluesky/profile?actor=bsky.app" \
  -H "x-api-key: $CRAWLORA_API_KEY"

{
  "code": 200,
  "msg": "OK",
  "data": {
    "did": "did:plc:z72i7hdynmk6r22z27h6tvur",
    "handle": "bsky.app",
    "display_name": "Bluesky",
    "description": "official Bluesky account",
    "avatar_url": "https://cdn.bsky.app/img/avatar/plain/did:plc:z72i7hdynmk6r22z27h6tvur/...",
    "banner_url": "https://cdn.bsky.app/img/banner/plain/did:plc:z72i7hdynmk6r22z27h6tvur/...",
    "followers_count": 34416262,
    "follows_count": 11,
    "posts_count": 804,
    "created_at": "2023-04-12T04:53:57.057Z",
    "indexed_at": "2025-10-27T21:05:26.152Z"
  }
}

続いて、アカウントのフィードとプラットフォームのトレンドトピックを Python で取得します（実際のフィールドです——ドキュメントを確認してください）。

import requests
h = {"x-api-key": "YOUR_API_KEY"}
base = "https://api.crawlora.net/api/v1/bluesky"

profile = requests.get(f"{base}/profile", headers=h, params={"actor": "bsky.app"}).json()["data"]

feed = requests.get(f"{base}/author-feed", headers=h, params={"actor": "bsky.app", "limit": 25}).json()["data"]
for post in feed["posts"]:
    print(post["author"]["handle"], post["like_count"], post["text"])

trending = requests.get(f"{base}/trending-topics", headers=h).json()["data"]["topics"]

author-feed returns each post as normalized JSON — no at:// parsing, no CID handling:

{
  "data": {
    "posts": [
      {
        "uri": "at://did:plc:z72i7hdynmk6r22z27h6tvur/app.bsky.feed.post/3l6oveex3ii2l",
        "url": "https://bsky.app/profile/bsky.app/post/3l6oveex3ii2l",
        "author": { "did": "did:plc:z72i7hdynmk6r22z27h6tvur", "handle": "bsky.app", "display_name": "Bluesky" },
        "text": "Welcome to Bluesky!",
        "created_at": "2024-10-17T07:06:51.491Z",
        "reply_count": 8545,
        "repost_count": 9534,
        "like_count": 63579,
        "quote_count": 705
      }
    ],
    "cursor": "1234567890::bafyabc"
  }
}

trending-topics は API キー以外のパラメータを必要とせず、そのまま表示できるフラットなリストを返します。

{
  "data": {
    "topics": [
      { "topic": "Big Brother 28", "link": "/profile/trending.bsky.app/feed/821933789" },
      { "topic": "NFL Preseason", "link": "/profile/trending.bsky.app/feed/821883116" }
    ],
    "suggested": [
      { "topic": "Popular with Friends", "link": "/profile/bsky.app/feed/with-friends" }
    ]
  }
}

/bluesky/search-actors（パラメータ q）はキーワードでアカウントを検索し、/bluesky/followers と /bluesky/follows はアクターのソーシャルグラフを cursor ベースのページネーションで返し、/bluesky/post-thread（パラメータ uri）は投稿とその完全なネストされた返信ツリーを返します。投稿またはプロフィールごとに1行を保存し、スケジュールを組んで再実行しましょう。

収集できるもの

公開されている Bluesky のデータです。キーワードによるアカウント検索、完全なプロフィール（ハンドル、DID、表示名、説明、アバター／バナー、フォロワー／フォロー／投稿数、作成・インデックス日時）、アカウントの投稿フィード（テキスト、エンゲージメント数、言語、タイムスタンプ）、フォロワー・フォローのリスト、投稿の完全なネストされた返信スレッド、そしてプラットフォーム全体のトレンドトピックです。

制約とよくある課題

• ここでの価値はアクセスではなく利便性です。 公開データはすでに AT Protocol 自体を通じてオープンになっています——構造化 API が節約してくれるのは、正規化とファイアホースのインフラであり、鍵のかかったドアではありません。
• その道を選ぶなら、Firehose／Jetstream は本当のインフラ投資になります。 ネットワーク全体のストリームを直接消費するということは、単発のスクリプトではなく、カーソル追跡と CBOR／MST デコードを備えた永続的な WebSocket コンシューマーを稼働させることを意味します。
• 固定されたユーザー名ではなく DID。 ハンドルは変更され得ます。永続的な識別子は DID であり、実運用のパイプラインでは両方を解決して保存すべきです。
• カーソルベースのページネーション。 フィード、フォロワー、フォローはいずれも、ページ番号ではなく不透明な cursor 値を使ってページングされます。
• 公開データのみ。 非公開アカウント、DM、ログインの壁の背後にあるものは、ここで紹介したどのアプローチでも対象外であり、今後もそうあるべきです。

どこで使われるか

• ソーシャルリスニングダッシュボード — 公開投稿全体にわたるブランドやトピックへの言及を、ほぼリアルタイムで追跡します。
• クリエイターリサーチ — アウトリーチやパートナーシップの審査のために、プロフィールと投稿履歴を照会します。
• 会話分析 — バイラルになった投稿の完全な返信ツリーを取得し、スレッドがどのように展開したかを把握します。
• クロスプラットフォームでのモニタリング — Bluesky の動向をX/TwitterやThreadsのデータと組み合わせ、1つのソーシャルリスニングパイプラインにまとめます。

出典

収集を始める

まずは無料でお試しください: 任意の公開 URL を無料ウェブスクレイパーに通すか、アンチボットチェッカーでサイトがボットをブロックするかどうかを確認できます。サインアップ不要です。

プロフィール、author-feed、検索の各エンドポイントをプレイグラウンドで試し、API ドキュメントでスキーマを確認し、料金をご覧ください。Bluesky は最新のメジャーなオープンソーシャルネットワークで何が起きているかを教えてくれます。老舗のX/Twitterのデータと、Meta の新規参入であるThreadsのデータを組み合わせれば、「ある会話で実際にどの X 代替サービスが勝ったのか」という全体像を、1つの正規化されたスキーマの中で把握できます。同じ会話がより長文でコミュニティによってモデレートされた場でどう展開するかについては、Redditのスクレイピング方法が、あるトピックが最初に現れることが多いスレッドをカバーします。あわせてウェブスクレイピング API の選び方とウェブスクレイピングは合法かもご覧ください。