GitHub はもうスター履歴を教えてくれません — だから自分で記録し始めました

簡単に見えた質問

「直近3ヶ月でスターを1万個以上獲得した GitHub リポジトリはあるか?」

一文の質問です。ところが答えを求めてみると、これは性質のまったく違う二つの質問が重なったものでした。片方は30秒で解け、もう片方は答える手段そのものが存在しませんでした。

簡単な方: 新しく作られたリポジトリ

「直近3ヶ月に作成された、スター1万個以上のリポジトリ」は GitHub 検索 API の一行で済みます。

created:>2026-06-09 stars:>=10000

本日時点の答えは24件。首位は8月13日に作成され21万スターを超えた deepseek-ai/deepseek-harness です。リストは圧倒的に AI エージェント・ハーネス系で占められています。

ここで一つ注目に値する事実があります。この検索 API は認証なしでブラウザから直接呼び出せます。

HTTP/2 200
access-control-allow-origin: *
x-ratelimit-limit: 10
x-ratelimit-resource: search

CORS が開いており、毎分10回の制限は訪問者の IP 単位です。サーバーを挟んでプロキシするとサイト全体で毎分10回を分け合いますが、ブラウザから直接呼べば訪問者ごとに10回ずつ持てます。この形の問題では、バックエンドを持たないことが手抜きではなくより良い設計になります。

難しい方: 既存のリポジトリがどれだけ伸びたか

問題は二つ目の解釈です。「作成時期を問わず、直近3ヶ月でスターが1万個増えたリポジトリ」— これは検索 API から出てきません。GitHub 検索は現在のスター数しか知らず、3ヶ月前の数は知りません。

かつては迂回路がありました。stargazers エンドポイントに特定の Accept ヘッダーを付けると、誰がいつスターを押したかのタイムスタンプが返り、最終ページから二分探索すれば任意の期間の境界を見つけられました。

現在のそのリクエストがこれです。

GET /repos/facebook/react/stargazers
Accept: application/vnd.github.star+json

HTTP/2 404

facebook/react です。タイプミスでも権限の問題でもありません。周辺をいくつか叩くとパターンが見えます。

エンドポイント	応答
/repos/{o}/{r}/stargazers	404
/repos/{o}/{r}/subscribers	404
/repos/{o}/{r}/forks	200
/repos/{o}/{r}/contributors	200
/user/starred (自分)	200、starred_at 付き

フォークもコントリビューターも健在で、自分が押したスターも見えます。失われたのは具体的に他人のリポジトリを誰がスター・ウォッチしたかを列挙する能力です。プライバシーの変更としては筋が通っていますが、スター履歴を計算していたあらゆるツールの土台も同時に消えました。

二つ目の迂回路も枯れています

次の候補は公開イベントフィードです。GitHub の公開イベントストリームでは WatchEvent 一つがスター一つで、GH Archive がこれを時間単位で保存しています。期間別の成長ランキングを作っていたサービスの多くはここに依存していました。

同じ時刻の1時間分を3つの年から取得して数えました。

日付	全イベント	WatchEvent (スター)
2025-06-09	137,566	4,394
2026-06-09	156,305	730
2026-09-08	83,301	213

1年で5%水準に、現在は1%を下回りました。全体のイベント数は崩れていないのに、スターイベントだけが消えている点が重要です。

まさにこのデータからランキングを作っていた OSSInsight の API は、今こう答えます。

{
  "status": "unavailable",
  "unavailable_since": "2026-03-01",
  "reason": "our capture of those events fell to roughly 0.3% of baseline,
             so the ordering would be noise"
}

結論: 過去は誰も返してくれません

つまり、**過ぎた期間のスター増加数は、今日利用できるどの方法でも遡って得ることはできません。**残る選択肢は一つだけ — 今日から自分で記録することです。

そしてこの選択肢には、先送りが恒久的な損失になるという性質があります。1日遅らせれば履歴が1日遅れ、飛ばした日は二度と埋まりません。

だから作りました。

GitHub スタートラッカー

無料、ログインなし、アカウントもトークンも不要です。

新規リポジトリタブはリアルタイムです。期間(1・3・6・12ヶ月)と最低スター数を選んでボタンを押すと、ブラウザが GitHub 検索 API を直接呼びます。同じ条件を再度尋ねると10分間キャッシュから答えるので、ボタンを連打しても自分のレート制限を使い切りません。

急上昇タブは1日1回取得するスナップショットから計算します。新しいリポジトリ(1年以内の作成・スター1,000以上)と既存の大型リポジトリ(スター2万以上)、約1,900件のスター数を毎日記録し、7・30・90日の増加数をランキングにします。

設計上の二点

**正直な期間。**収集は今日始まったので、明日は1日分、来週は1週間分しかありません。ここで「直近90日」タブが9日分のデータで作った順位を90日の結果のように見せれば、それは嘘です。そこで各期間は自分が実際に何日分に基づくかを持ち歩き、足りなければ画面にそう書きます。期間の途中で収集対象になったリポジトリにも印を付けます — その増加数は実測ではなく上限値だからです。

**データとデプロイの分離。**コレクターは GitHub Actions で毎日動き、結果をリポジトリにコミットします。ところが Actions の既定トークンで作られたコミットは他のワークフローを起動しません。つまりデータをコミットしてもサイトは再ビルドされません。

この制約は回避せず、利用しました。ページはデプロイ済みのサイトではなく raw.githubusercontent.com からデータを直接読みます。CORS が開いていてキャッシュは5分なので、コレクターのコミットは再ビルドなしで5分以内に反映されます。データパイプラインとサイトのデプロイが完全に分離され、サイトを毎日ビルドし直す理由もなくなります。

現在の状態

最初のスナップショット — リポジトリ1,913件、60KB — が本日入りました。だから今日の急上昇タブは空です。比較対象がまだないからです。明日の2回目のスナップショットで7日の期間が開き、90日の期間は12月に埋まります。

今すぐ使ってみる →