GitHubのStar履歴APIが復活、ユーザー名を出さず成長曲線を取得

GitHubは2026年9月4日、リポジトリのStar履歴を集計値で取得するREST APIを公開した。GitHubの公式Changelog によると、新エンドポイントはStarした個人の情報を公開せず、時刻情報を伴う過去のStar件数を返す。制限によって止まっていた成長曲線の生成を、個人単位の一覧なしで再開できる。

取得先はGET /repos/{owner}/{repo}/stargazers/historyだ。レスポンスはユーザーごとのレコードではなく、週の開始時刻、週間件数、7日分の日別件数で構成される。旧stargazers APIを使うツールは、週単位のページング、並べ替え、日別配列の展開に合わせて集計処理を置き換える必要がある。

新APIが返すのは人物ではなく期間別の件数

従来のStar推移ツールは、stargazers一覧から各ユーザーのStar日時を取得し、時系列に並べて曲線を作っていた。このレスポンスにはユーザー名、アバター、プロフィールへの参照など、件数の推移を描く目的には不要な個人単位の情報も含まれる。新APIは人物の一覧を返さず、期間ごとの追加件数だけで履歴を表す。

GitHub REST APIの公式仕様 では、履歴の各要素を「week」「total」「days」で返すと定めている。「week」は週の開始を示すUnix時刻、「total」はその週に作成されたStarの数、「days」は日曜から始まる7要素の配列だ。Starが付かなかった週にもゼロが入るため、ページ間の空白期間を推測で補完する必要はない。

週と日の境界はUTCに一致するとは限らない。Unix時刻を先にUTCの日付へ丸めるのではなく、APIが返した「week」を起点に「days」を順番に展開し、表示段階で必要なタイムゾーンへ変換する方が境界を保ちやすい。

curlで取得し、作成週までページをたどる

公開リポジトリの情報は認証なしでも取得できる。最小構成はcurl -L -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2026-03-10" "https://api.github.com/repos/OWNER/REPO/stargazers/history?per_page=30&page=1"となる。非公開リポジトリを対象にする場合は、Metadataのread権限を持つ対応トークンをAuthorizationヘッダーへ追加する。

「per_page」の上限は30件、つまり30週で、「page」の上限は100だ。レスポンスは最新週から古い週へ並び、次のページほどリポジトリの作成週へ近づく。必要なリクエスト数は現在のStar数ではなく、主にリポジトリが存在した週数で決まる。

実装ではLinkヘッダーの「next」がなくなるまでページを取得する。ページと各ページ内の週はいずれも新しい順なので、連結後は「week」を基準に古い順へ並べ替える。正確な全期間の累積曲線を作るには、表示対象が最近の期間だけでも、基準値を得るため作成週まで取得しなければならない。

週別レスポンスから日別曲線を復元する

日別系列は、最も古い週から「days」を走査し、その日の追加件数を累積値へ加えて作る。各日について「日付」「当日の追加件数」「その時点までの累積追加数」を保持すれば、そのまま描画用の系列になる。「days」の合計を同じ週の「total」と照合すると、配列の欠落や展開順の誤りを検出できる。

この累積値は、履歴APIが返すStar作成件数の合計であり、現在有効なStar数とは別の指標だ。現在値はGET /repos/{owner}/{repo}/stargazers/countで取得でき、後からStarを外したユーザーはこの件数に含まれない。履歴の終点と現在値に差があっても、過去の系列を比例補正すると実在しない変化を加えることになるため、両者は分けて保持する。

変換処理は次の順序にすると責務を分離しやすい。

1. 全ページを取得し、「week」で古い順に並べる。
2. 各週の「days」を0番目の日曜から6番目の土曜まで展開する。
3. 日別件数を順番に加算し、日次の累積系列を作る。
4. 各週で「days」の合計と「total」を照合する。
5. 現在の有効Star数を表示する場合は、countエンドポイントの値を別指標として保持する。

旧stargazers処理の置換点

移行の中心は、レコードの単位とページングの終了条件だ。旧処理にある「1レコードは1人」「starred_atを日付へ変換」「Star数が多いほどページが増える」という前提を外す。新処理では「1レコードは1週」「daysから日次レコードを展開」「作成週まで過去へ移動」が基本になる。

Star History運営者の移行報告 では、過去2カ月に壊れたチャートが新APIへの切り替えで再び動作し、旧方式にあった4万Starでの取得上限も解消したとしている。同サービスは、最新週が先頭に来ること、空の週にもゼロが入ること、1ページが最大30週であることを実装上の要点に挙げた。一方、各週に通算値がないため、任意時点の正確な累積値には作成週までの全ページが必要だという制約も残る。

移行時の確認項目は次の通りだ。

• ユーザー名、ユーザーID、プロフィールURLを入力にする処理を削除する。
• 「starred_at」の並べ替えを、「week」と「days」の展開処理へ置き換える。
• 最新順のレスポンスを、描画前に古い順へ並べ直す。
• 最大30週単位のページングを、Star件数ではなく経過週数として扱う。
• 取得済みの古い週を保存し、更新時は新しいページを中心に取得できる構成を検討する。
• 時間単位の発生時刻は復元できないため、グラフの最小粒度を日単位に変更する。

復活した範囲と残る制約

復活したのは、公開リポジトリで「いつ、何件のStarが作成されたか」を日単位まで追う用途だ。「誰がStarしたか」を列挙する機能が一般公開に戻ったわけではない。ユーザー単位のイベント、プロフィール属性、時間単位の発生時刻を必要とする機能は、集計レスポンスだけでは再現できない。

新エンドポイント、現在件数用エンドポイント、ページング上限は公式仕様に掲載され、Star Historyも実運用への移行を完了している。ただし、週ごとの通算値は提供されていない。仕様が変わらない限り、完全な成長曲線の初回生成には、作成週までの取得、日別配列の展開、累積値の計算が必要になる。