こちらはHubble Advent Calendar 2025の11日目の記事です。
はじめに
株式会社Hubbleでバックエンドエンジニアを担当している @tnaoki です。
日々開発を進めていると、コードレビューで交わされるコメントにはチームの考え方や改善ポイントがよく表れます。特によく話題になる内容は、実装の段階で意識できれば避けられることも多く、傾向を知っておくだけで開発がよりスムーズになります。
Hubbleでは、命名や設計、クエリ方針などのレビュー観点をドキュメントとして整理しています。Pull Requestのレビューを他のメンバーに依頼する前のセルフレビューでは、Cursorにこのドキュメントを参照してチェックしてもらうフローも取り入れています。
とはいえ、Cursorによるコードレビューだけで十分というわけではなく、実際のコードレビューでは追加で指摘が入ることも多くあります。そこで今回、どんな観点の指摘が多いのかをあらためて可視化してみることにしました。
概要
Hubbleのサーバーサイドリポジトリを対象に、直近200件のPRからレビューコメントを収集し、その傾向を分析しました。
集計対象は「最初のレビューコメント」のみで、コメントに対する返信は除外しています。
また、以下のようなPRやコメントも対象外としています。
- リリース用のPRなど、ブランチ運用上のマージPR
- 「LGTM」などの承認コメント
- PR作成者がレビュワー向けに追加した補足コメント
集計手順
- GitHub CLIをセットアップし、PR情報を取得可能な状態にする
- 直近200件のPRを取得
- 各PRのレビューコメントを収集し、1つのCSVに集約
- Cursorを使い、事前に用意した8カテゴリへ分類し可視化
なお、分類時に使用したプロンプトはごく簡単なもので、
CSVとカテゴリ一覧を渡し、「8つのカテゴリにコメントを分類してください」
という程度のシンプルな指示で行いました。
結果
直近200件のPRから抽出した339件のレビューコメントを8つのカテゴリに分類したところ、以下のような結果になりました。
| カテゴリ | コメント数 |
|---|---|
| 可読性・実装スタイル（命名含む） | 91 |
| 仕様・ドメイン整合性 | 77 |
| テスト | 72 |
| 設計・構造（アーキテクチャ） | 39 |
| その他 | 23 |
| バリデーション・エラーハンドリング | 21 |
| パフォーマンス | 11 |
| ログ・運用 | 5 |
特に多かったのは以下の3カテゴリで、合計すると全体の約7割を占めています。
- 可読性・実装スタイル（命名含む）
- 仕様・ドメイン整合性
- テスト
この結果から、コードが「動けばよい」ではなく、
読みやすさ・仕様との整合性・テストの質 といった、将来的な保守性や信頼性につながる観点にレビューが多く寄っていることが分かりました。
続くカテゴリとしては、
- 設計・アーキテクチャ
- その他
- バリデーション・エラーハンドリング
が中程度のボリュームで見られました。
一方で、
- パフォーマンス
- ログ／運用
に関するコメントは比較的少なく、これはPRの種類や単位ごとの実装内容を考えると自然な結果とも言えます。
テストに関連するコメントでは、単に「テストを書いているか」を確認するだけでなく、
- 境界値・異常系のテスト漏れ
- 必要以上にモックしない書き方
- テストコードの読みやすさ・書き方の統一
といった テストそのものの質に踏み込んだ指摘 が多かったのが印象的でした。
また、「その他」に分類されたコメントには、実装者への感謝や学びの共有、あるいはレビュイー自身が気づいた点をメモとして残したものなど、コードの指摘というより、コミュニケーション目的のコメントが多く含まれていました。
総じて、今回の分類からは、
- 可読性
- 仕様の正しさ
- テストの充実度
といった、長く安全に運用できるコードを書くための観点が重視されているレビュー文化 が見て取れました。
カテゴリ分類時にハマった点
今回レビューコメントをカテゴリに分類してみて、意外と悩まされたのが
レビューコメントは「分類される前提で書かれていない」 という点でした。
当たり前ではありますが、レビューコメントは本来「そのPRの背景を把握している相手」に向けて書かれるものです。分析しやすいように構造化されているわけではなく、文脈や前後関係を前提とした書き方も多く含まれています。
例えば、
- 「変更前のままでも良さそう」
- 「こっちも同様」
- 「このPRのここ（リンク）と同じ問題です」
といったコメントは、そのPR全体の状況を知っていないと意図が読み取りづらく、
コメント単体ではカテゴリ分けが難しいケースもありました。
LLMに渡して分類する場合でも同様で、コメントだけでは判断できず、どうしても「その他」に分類されがちな課題がありました。
本来であれば、Cursorに分類してもらう際にGitHub MCP経由でコメントが参照しているコードを取得し、その行付近の文脈も含めて渡すことで、より精度の高い分類ができた可能性があります。
とはいえ、今回のデータではこうした「文脈依存のコメント」はそこまで多くなかったため、必要な部分は手動で確認しつつ、最終的な分類を調整する形で対応しました。
まとめ
今回は、Hubble のサーバーサイドリポジトリにおける直近200件のPull Requestを対象に、レビューコメントの傾向をざっくり可視化してみました。
分類の結果、特に多かったのは
- 可読性・実装スタイル
- 仕様・ドメイン整合性
- テスト
の3つで、全体の約7割を占めていました。
どれも「正しく動く」だけでなく、長く運用できるコードを書くための観点であり、
日々のレビュー文化がそのまま表れた結果だと言えます。
今回のようにレビューコメントの傾向をパターンとして整理してみると、「繰り返し指摘されている観点」や「コードレビューで特に見落としやすいポイント」が浮かび上がります。
こうした観点をコードレビュー用のドキュメントに追加したり、既存の指針を見直したりする際の材料にもなり、セルフレビューの精度向上や、コードの質の底上げにもつながりそう だと感じました。
今後も、定期的に傾向を振り返ったり、観点をアップデートしていくことで、
よりレビューしやすく、より実装しやすい開発環境づくりにつなげていければと思います。
明日は @horin0211 さんです！