管理画面で「今月の受注件数推移」や「日別の問い合わせ件数」を表示する際、画面に表示する行数は数十件程度なのに、読み込みに数秒待たされるという経験はないでしょうか。レスポンスのJSONを小さくすれば軽くなると考えて項目を削っても、データベースの負荷や応答時間がほとんど変わらないことがあります。

こうした集計処理のボトルネックについて、2026年10月にGitHubのエンジニアリングブログで興味深い技術解説が公開されました。タイトルは「From 2,500 requests to 24: Rebuilding star history without the stargazers」です。個人データを取得して手元で集計していた従来の方式を見直し、必要な集計値を効率よく取得できるようにAPIそのものを再設計した過程が詳しく報告されています。

個人一覧の制限から始まったスター履歴APIの再設計

見直しのきっかけは、公開データの悪用対策でした。GitHubは先行する告知（Upcoming access restrictions to public API endpoints and UI views）で、スターを付けた人の一覧やウォッチャー一覧の公開APIエンドポイントを、リポジトリの管理者や共同作業者のみに制限する方針を示し、その後制限を実施しました。公開一覧から取得した利用者データが、スパム活動などに悪用されていたためです。

しかしこの変更は、外部のスター履歴可視化ツールにも影響を与えました。従来のツールは、スターを付けた人の一覧APIを繰り返し呼び出して全員の付与日時を取得し、手元で日付順に集計して推移グラフを描画していたためです。APIのアクセスが遮断されたことで、履歴グラフが描けなくなる問題が生じました。

そこでGitHubがツール開発者や保守担当者に聞き取りを行ったところ、彼らが必要としていたのは誰がスターを付けたかという個人情報ではなく、「いつ何件増えたか」という日付と件数の推移（カーブ）だけだったことがわかりました。利用者名が不要であれば、個人一覧を配るのではなく、集計済みの数値を直接返す専用のエンドポイントを新設すれば解決できると考えられたのです。

なぜ「集計してページ分割」では軽くならないのか

集計値を返すエンドポイントを作る際、まず検討されたのは「データベース側で日別・週別にグループ化して集計し、その集計結果をページ分割（LIMITとOFFSET）して返す」という標準的なSQLの方式でした。しかし、この方式ではクエリの実行負荷が下がりませんでした。

一般的なデータベース処理では、まず対象リポジトリに紐づくすべてのスターを検索し、日別や週別にグループ化して集計し、並べ替えた後に、初めてLIMITとOFFSETによって要求されたページ分の件数が切り出されます。画面に返すJSONのサイズは小さくなりますが、データベース内部では事前に全件の走査と集計、ソートが完了しているため、サーバー側の重い処理はそのまま残ってしまうのです。GitHubの説明によれば、人気リポジトリであるreact/reactの全履歴をこの方式で取得しようとした場合、全24回のリクエストのたびに全スターが再処理され、調べる行数は合計で約600万行に達する計算でした。

索引付きの期間条件で先に絞り込むアプローチ

そこで採用されたのが、集計を行う前に「日付の範囲（created_at）」で走査対象を絞り込む設計です。具体的には、リクエストで指定されたページ番号と件数をカレンダーの週単位に変換し、索引（インデックス）が効く作成日時で対象レコードを特定の週だけに絞り込んでから、日別の件数に集計します。

この新方式では、1回のリクエストで最大30週分の日別集計値が返され、ページ番号を増やすことで過去へとさかのぼる仕組みです。GitHubが示したreact/react（スター数約25万件）の全履歴取得の比較例では、従来の一覧取得方式で約2,511回必要だったリクエストが新方式では約24回に減少し、全履歴を通じてデータベースが走査する行数も各スターおおむね1回（約25万1,000行）に抑えられたと説明されています。なお、この数値はGitHubが自身のシステムで示した比較例であり、あらゆる環境での改善率を保証するものではありません。

履歴データが持つ前提と残る制約

この再設計には、設計上の前提と制約も明示されています。まず、GitHubのスター機能の基盤データは「現在スターを付けている人の集合」を記録するものであり、過去の追加や解除をすべて保存するイベントログではありません。ユーザーがスターを取り消すとレコード自体が削除されるため、新APIが返す日別件数も「現在残っているスターの作成日別の集計」であり、取り消された過去の履歴まで完全に再現するものではないという点です。

もう一つの制約は、リクエストごとの「期間」は最大30週に限定されるものの、その期間内の「スター数」には上限がないことです。新製品の発表やSNSでの拡散などで、特定の週にスターが極端に集中した場合、その期間の集計処理は依然として重いクエリになる可能性が残ります。期間で区切る設計を採用しても、データの偏りによる負荷の変動は考慮し続ける必要があります。

国内の業務システム集計へ応用する視点

このGitHubの事例は、顧客管理や受注管理などのWeb業務システムで集計画面を見直す際にも多くの示唆を与えてくれます。

たとえば、月別の受注推移画面を表示するために、受注明細テーブルから顧客情報を含む全レコードをAPIで取得し、フロントエンド側で集計しているケースを考えてみます。データ量が増えるにつれて通信量も画面の処理も重くなりますが、担当者が画面で見たいのが月ごとの件数と合計金額の推移だけであれば、顧客名や個々の商品明細を都度送る必要はありません。

ただし、API側で集計して返すように改修する場合でも、全期間のレコードを集計してから直近1年分を切り出すようなクエリになっていれば、集計や並べ替えの処理対象となる範囲は狭まりません。日付のインデックスを活用し、「過去1年」などの期間条件を集計前に適用して検索行数を狭めているか、実行計画を確認することが重要です。

また、業務データ特有のルールにも注意が必要です。キャンセルされた注文や削除されたデータがテーブルから物理削除される設計の場合、現在残っているデータだけで過去を集計すると、当時の確定件数と食い違う可能性があります。さらに、年末年始やセール期間など特定のタイミングに注文が集中するシステムでは、通常月を基準にした期間設計だけでは十分なパフォーマンスを維持できない場合があります。

既存システムの集計設計やデータ取得の見直し

社内の集計画面やレポート機能の応答が遅くなっている場合、画面の改修だけで解決するのか、APIの返却項目を絞るべきか、それともデータベースのクエリ構造やインデックスまで踏み込んで見直す必要があるのかは、現状の構成によって大きく異なります。

株式会社デノフでは、Webサイト・業務システムの設計・開発・運用保守を提供しており、予約管理、顧客管理、社内ツールなど業務に合わせたシステム開発を手がけています。要件が固まっていない初期の段階から課題の整理を行っており、既存の業務画面やAPIで何が表示され、どの処理で遅延が起きているのかの調査から、改善範囲の絞り込みまで対応が可能です。

日々の業務で「集計画面の読み込みが遅くて業務が滞っている」「APIが返すデータが肥大化していてどこから整理すべきかわからない」といった課題をお持ちの企業様は、具体的な実装や検証の進め方についてデノフへの相談窓口よりお気軽にお問い合わせください。