GitHub、スター履歴を2511回から24回で取得

GitHubエンジニアリスク

新APIの要点

最大30週の日次スター数
個人情報を含まない集計

負荷削減の設計

集計前の期間絞り込み
React履歴は24リクエスト

残る制約

高密度な週の処理負荷
削除済みスターの非反映
詳細を読む

GitHubは2026年10月14日、リポジトリのスター推移を個人情報なしで取得できる新APIの設計を公表しました。1回で最大30週間の日次件数を返し、期間を先に絞ってから集計することで、人気リポジトリのデータベース負荷と、旧APIを悪用したスパムやフィッシング向けの個人情報収集リスクを同時に抑えます。

旧APIは「誰がスターを付けたか」を最大100人ずつ返す設計で、時系列分析には全ページの取得が必要でした。約25万1000スターのreact/reactでは約2511回のリクエストが必要で、ページ処理の不具合により毎回全件数も数えていました。アクセス制限前の1週間には遅い集計が約3万7000件、平均約3秒に達し、1000件超がデータベース保護機構で中断されました。

GitHubはまず、公開スター・ウォッチャー一覧へのアクセスを管理者と共同作業者に制限し、個人情報の一括収集を封じました。一方、影響を受けたStar Historyなどの開発者と協議し、利用者が必要なのは氏名ではなく、リリースや告知前後の関心を測る件数と日付だと整理しました。

新APIはpageとper_pageをカレンダー週のcreated_at範囲へ変換し、索引で対象期間を絞った後に日別集計します。この集計前の絞り込みにより、react/reactの全履歴は約24回で取得でき、単純な集計方式の約600万行ではなく、約25万1000件をほぼ1度ずつ調べる構造になりました。

ただし、元データは現在スターしている利用者の記録で、解除済みスターは残らず、カレンダー境界やスターが集中した週は精度・負荷上の制約になります。GitHubは関連画面もキャッシュ済み件数へ切り替え、週数百件あった遅いクエリをゼロにしました。API設計では、返却量を減らすだけでなく、利用目的に沿って集計前に処理対象を制限できているかが要点です。