GitHub のリポジトリ・ユーザー・トレンドをスクレイピングする方法【2026年版】(API と Python)

2026 年に GitHub をスクレイピングする最速の方法は、公式 API の毎時クォータを使い切ったり github.com のクライアントレンダリングされたページをパースしたりする代わりに、正規化された JSON（リポジトリ・ユーザー・組織・コントリビューター・スターゲイザー・言語の内訳・リリース・トレンド）を返す構造化 API を呼び出すことです。GitHub はこのシリーズの中で珍しく、本当に有能な公式 API を持っています。そのため本当の問いは、レート制限がスクレイピングをより良い選択にするのはいつか です。本ガイドでは 3 つのアプローチすべて、それぞれが何を返すか、どこで破綻するか、そして法律の基本を解説します。

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

公開されている GitHub のデータは、開発者・採用・市場の作業カテゴリ全体を支えています。

• 開発者ソーシングと採用 — 言語・所在地・コントリビューション履歴でユーザーを見つけてランク付けします。
• オープンソースの依存関係と競合の追跡 — 依存している、あるいは競合しているプロジェクトのスター・フォーク・リリース・コントリビューターの入れ替わりを見張ります。
• 技術トレンドと市場調査 — トレンドのリポジトリと言語を追跡し、エコシステムがどこへ向かっているかを把握します。
• デベロッパーリレーションとアウトリーチ — 関連プロジェクトのメンテナーやスターゲイザーの的を絞ったリストを作成します。
• AI / LLM パイプライン — リポジトリのメタデータ・README・リリースノートを検索・分析のワークフローに投入します。

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

選択肢 1: Python での自作（そしてなぜ破綻するか）

多くの自作は、requests（または PyGithub）を通じた公式 REST API から始まります。

import requests

h = {"Authorization": "Bearer YOUR_GH_TOKEN", "Accept": "application/vnd.github+json"}
repo = requests.get("https://api.github.com/repos/torvalds/linux", headers=h).json()
contributors = requests.get("https://api.github.com/repos/torvalds/linux/contributors",
                            headers=h, params={"per_page": 100}).json()

小規模な取得では動きますが、その後こう壁にぶつかります。

• レート制限のクォータ。 未認証のリクエストは IP あたり 60/時に制限され、トークンを使うと core が 5,000/時に上がります。1,000 のリポジトリをそれぞれ約 5 回の呼び出し（詳細・コントリビューター・言語・リリース・スターゲイザー）で分析すると、毎時クォータ全体を 1 回のスキャンで使い切ります。
• 検索はより厳しく、上限がある。 Search API は ~30 リクエスト/分で動作し、1 クエリあたり最大 1,000 件しか返しません — そのため、いくら多く存在しても最初の 1,000 件を超えてページングすることはできません。
• セカンダリのレート制限。 バースト的あるいは並行なリクエストは 403 と Retry-After を伴う不正検知の制限に引っかかるため、バックオフと慎重な並行処理が必要です。
• HTML のパースはもっと悪い。 github.com で requests + BeautifulSoup に切り替えると、クライアントサイドレンダリングと頻繁なレイアウトのずれに直面し、それでも同じアンチボット防御に引っかかります。

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

ビジュアル抽出ツールやマーケットプレイスの「GitHub」アクターは CSV/JSON をエクスポートし、単発の取得には向いていますが、フィールドが予測可能なプロダクト内のパイプラインでは扱いづらく、同じレート制限とページングの上限を引き継ぎます。

選択肢 3: 構造化された GitHub API

繰り返し行うワークフローには、構造化された GitHub API が、管理すべきトークンのやりくりやバックオフなしで、正規化された JSON を返します。検索してから、情報を付加します。

curl "https://api.crawlora.net/api/v1/github/search/repositories?q=web+scraping&sort=stars" \
  -H "x-api-key: $CRAWLORA_API_KEY"

Python の場合 — リポジトリは owner/repo で、ユーザーは login で指定します。

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

# 1) Search repositories (paginated: page / per_page)
hits = requests.get(f"{base}/github/search/repositories", headers=h,
                    params={"q": "web scraping", "sort": "stars", "per_page": 50}).json()["data"]

# 2) Full detail for one repo
repo = requests.get(f"{base}/github/repo/torvalds/linux", headers=h).json()["data"]

検索は合計件数とページングされた項目を返します（フィールドは説明用です。ドキュメントを確認してください）。

{
  "code": 200,
  "msg": "OK",
  "data": {
    "total_count": 18742,
    "items": [
      { "full_name": "torvalds/linux", "owner": "torvalds", "language": "C", "stars": 180000, "forks": 53000, "topics": ["kernel", "linux"], "license": "GPL-2.0" }
    ]
  }
}

同じキーで、コントリビューター・スターゲイザー・言語・リリース・ユーザー・トレンドにも届きます。

contributors = requests.get(f"{base}/github/repo/torvalds/linux/contributors", headers=h,
                            params={"per_page": 100}).json()["data"]   # login, contributions
langs = requests.get(f"{base}/github/repo/torvalds/linux/languages", headers=h).json()["data"]  # bytes per language
user = requests.get(f"{base}/github/user/torvalds", headers=h).json()["data"]                    # name, company, followers
trending = requests.get(f"{base}/github/trending", headers=h,
                        params={"language": "python", "since": "daily"}).json()["data"]          # stars_today

page/per_page を渡してコントリビューターとスターゲイザーをたどり、トレンドには language/since を使い、リポジトリまたはユーザー 1 件につき 1 行を保存し、スケジュールに沿って再取得することで、スター・リリース・コントリビューターの入れ替わりの推移を追跡できます。

収集できるもの

• リポジトリ — name、full_name、owner、description、language、topics、stars、forks、watchers、open_issues、license、default_branch、pushed_at。
• リポジトリグラフ — contributors（login、contributions）、stargazers、forks、言語のバイト内訳、releases（tag_name、name、published_at、author）。
• 検索 — リポジトリとユーザー。それぞれ total_count とページングされた項目を伴います。
• ユーザーと組織 — プロフィール（login、name、company、location、blog、followers、public_repos、social_accounts）、ユーザーまたは組織の公開リポジトリ、ユーザーの最近の公開イベントとピン留めされたリポジトリ。
• トレンド — トレンドのリポジトリ（stars_today 付き）とトレンドの開発者。言語と期間の窓で絞り込めます。

すべてが公開されている GitHub のデータです。公開された事実に基づくフィールドにとどめてください。

制約とよくある課題

• 公式 API のレート制限が本当のボトルネック。 未認証で 60/時、トークンありで 5,000/時、検索は ~30/分で 1,000 件に制限されます — 構造化 API は、スロットリングとトークン管理を 1 つのキーの背後で吸収します。
• 検索は 1,000 件で頭打ち。 どのエンドポイントも、クエリの最初の 1,000 件を超えてページングしません。クエリを（言語・スター・日付で）絞り込んで、大きな結果集合をシャーディングしてください。
• 一部のリストは切り詰められる。 GitHub はコントリビューターや類似のリストに上限を設けているため、非常に大きなリポジトリではすべてのコントリビューターは返りません — 上限を織り込んで計画してください。
• プロフィールには個人データが含まれる。 名前・会社・所在地・リンクされたソーシャルアカウントは GDPR/CCPA のもとで個人データです — 適法な根拠のもとで、公開された事実に基づくフィールドを収集してください。

どこで使われるか

• 開発者ソーシング — 採用やデベロッパーリレーションのために、言語・所在地・コントリビューション履歴でユーザーをランク付けします。
• 企業・技術のエンリッチメント — 組織のリポジトリ・言語・リリースのペースを把握します。企業データのエンリッチメントのユースケースを参照してください。
• OSS トレンドの追跡 — トレンドのリポジトリと言語を見張り、エコシステムがどこへ向かっているかを見極めます。

出典

収集を始める

まず無料で試す: 任意の公開 URL を Free Web Scraper で実行するか、Anti-Bot Checker でサイトがボットをブロックするかどうかを確認できます。サインアップは不要です。

エンドポイントを Playground でテストし、API ドキュメントでスキーマを確認し、料金を確認してください。ウェブスクレイピング API の選び方とウェブスクレイピングは合法かも参照してください。