コードレビュー指摘300件を3ヶ月分類したら効いていたのは2種類だけだった ─ Bug/Spec死守・残り4種類はPRから外す

CODE REVIEW ROI — 300 COMMENTS × 3 MONTHS 効いていたのは 2種類だけだった コードレビュー指摘300件を6カテゴリで 分類・採点した3ヶ月の集計 ken imoto エンジニア / Propel-lab AIコードレビューを “仕組み化する技術” レビュー工数を60%削減した実践設計 そのレビュー、本当に人がやる必要があるのか。 K.E.N. IMOTO AI時代のコードレビュー設計、決定版 コードレビューROI 300件検証 kenimoto.dev

300件全部直したら、開発が止まった PRが nit: で埋まり、AIレビューを増やしたら人間側の疲れがピ ークに達した。 3ヶ月・PR 62本・レビュー指摘300件。 「本当に効いたのは何件か」を数えた。 自分のレビューが信用できなくなった。指摘の量が価値と比例していない疑いがあった。1 件1件を後追いで採点して、初めて分布が見えた。 コードレビューROI 300件検証 02 kenimoto.dev

6カテゴリ×3指標で採点する Conventional Commentsのラベルを写像して、指摘1件ずつを後 追いで採点した。 6カテゴリ(指摘の角度) Style インデント・書式 Naming 命名の一貫性 Refactor 整理・DRY Architecture 層・責務の置き場 Bug null・境界・競合 Spec 仕様との整合 3指標(寄与の測り方) 品質寄与 0/1/2 速度寄与 -2 ~ +2 3ヶ月後 0 or 1 欠陥相関 サンプル n=300(単一プロジェクト) 採点者 私一人・事後採点 コードレビューROI 300件検証 03 kenimoto.dev

6カテゴリ勾配ヒートマップ 色が濃いほど寄与が高い。淡い列は「効きが薄い」指標。 件数(N) 品質寄与 速度寄与 3ヶ月後 欠陥相関 Style 96 0.4 -0.8 0.04 Naming 58 0.7 -0.3 0.07 Refactor 47 0.6 -1.1 0.12 Architecture 31 1.6 -0.4 0.18 Bug 42 1.9 +1.2 0.51 Spec 26 1.7 +0.9 0.43 寄与: 低 ■高 コードレビューROI 300件検証 04 kenimoto.dev

同じ1件でも、効きめは1桁違う Bug指摘の欠陥相関 0.51、Style指摘の欠陥相関 0.04。 Bug 1件がその後の本番欠陥を止める確率は、Style 1件と比べ て—— 13倍 BugとSpecの2種類だけが、3指標すべてで濃かった。 残り4種類(Style / Naming / Refactor / Architecture)は、寄与の薄い列が必ず1つ以上ある。 コードレビューROI 300件検証 05 kenimoto.dev

nit: が多いレビューほど、欠陥が増える Style指摘の自己相関ではなく、他カテゴリの欠陥検出感度が落ち ていた。 STEP 1 1つのPRに nit: が30件つく → STEP 2 レビュアーの 認知容量が枯れる → STEP 3 Bug候補への 検出感度が下がる Trisha Gee(Oracle)の「Style nitpicking too much」を、300件のデータで裏打ちした 形。 Google Engineering Practices の「見るべき順」も Design → Functionality → Complexity → Tests → Naming → Comments → Style の順で、Styleは最後。 コードレビューROI 300件検証 06 kenimoto.dev

Bug: 1指摘で本番障害1件を消す nit: 30件分のレビュー時間を、たった1件のBug指摘のROIが超え る。 PR #142 での実例。1指摘で1件の本番障害を未然に防いだ。 issue: ここ、空配列が来たときに無限ループします 3ヶ月後の再発 0件 CSVインポート機能の本番障害を防 止 投入時間 約90秒 1件のコメントを書く時間 同時間で書けるNIT: 約30件 nit: 30件の総効果 < issue: 1件 コードレビューROI 300件検証 07 kenimoto.dev

Spec: 1件の質問が、複利で効く 「この挙動は仕様書のどこに?」がAGENTS.mdに書き足され、次 の20件のPRに波及する。 Spec指摘はコードを直接修正しない。それでも欠陥相関 0.43。 理由は、質問がチームの共通理解の更新に効くから。 1. QUESTION question: タイムゾーン処理は サーバー側基準でいいですか? → 2. RULE AGENTS.mdに1行追加 「全タイムスタンプは UTC保存・JST表示」 → 3. RIPPLE 次の20件のPRに 波及する前提が 共有される その後3ヶ月、タイムゾーン関連バグ 5件 → 0件 コードレビューROI 300件検証 08 kenimoto.dev

4カテゴリはPRレビューの場から外す Style / Naming / Refactor / Architecture は「廃止」「自動化」「事 前に潰す」のどれかへ。 指摘カテゴリ PRレビューの代わりに置く場所 Style → Prettier / Biome / Ruff で強制(pre-commit フック) Naming → AGENTS.mdに命名規則、CodeRabbit に自動指摘させる Refactor → 別PRの refactor: タスクへ。同PRで指摘しない Architecture → PR提出前の設計レビューで潰す(pre-PR 会話 or 設計ドキュメント) レビュー時間 -42%、Bug / Spec の指摘密度はむしろ上がった コードレビューROI 300件検証 09 kenimoto.dev

はてブで挙がった論点への応答 B!ホットエントリで議論された3点、記事内の主張と補強を並べ る。 RE: Refactor/Arch. 「Refactor と Architecture は PRレビューでは遅すぎる、はその通 り」 だからPR提出前の設計レビューへ場所替える。Architectureの速度寄与は -0.4、目の前の PRを3日遅らせるコストは短期に毒。 RE: linter 自動化 「linter で自動化できる指摘に 時間使うのはリソースの無駄」 Style は機械が判定できる時点で人間が触ると負け。Prettier / Biome / Ruff を pre-commit に置いて、レビュー欄から追放するのが本記事の結論。 RE: 大PR疑い 「大きめのプルリクな感じがして 嫌な予感もする」 n=300 / PR 62本 = 平均 4.8 件/PR。大PRではなく、指摘密度そのものが飽和していた。カテ ゴリ場所替え後は密度が下がり、Bug/Spec比率が上がった。 コードレビューROI 300件検証 10 kenimoto.dev

自チームの直近50件で、2週間で試せる 50件の指摘があれば仮の結論は出る。実装は重くない。 STAGE 1 50件を 6カテゴリに分類 直近PRから指摘50件を取り出し、 Style / Naming / Refactor / Architecture / Bug / Spec に割り当 てる。 所要 10分 STAGE 2 3指標で採点 品質寄与(0/1/2)、速度寄与(-2~ +2)、3ヶ月後欠陥相関(0/1)。過去 PRから採点すれば3ヶ月分のbug報 告と突き合わせられる。 所要 30分 STAGE 3 価値の低いカテゴリを 場所替え ROIが低い2~4カテゴリを、自動化 (hooks) / 規則化(AGENTS.md) / 前 出し(設計レビュー)のどれかに移 す。 所要 半日 2週間で issue: と question: の比率が上がっていれば成功 コードレビューROI 300件検証 11 kenimoto.dev

続きは、この本に。 hooks × AI × 人間の3層モデルを実装例 で。 Zenn Book ¥1,000 zenn.dev/kenimo49/books/harness-code-revie w Kindle ¥1,500 amazon.co.jp/dp/B0GHT7FQ7G 元記事 zenn.dev/kenimo49/articles/code-review-300-c omments-2-effective-categories hooksで機械的チェックを強制し、CodeRabbit / Copilot / Claudeに一次レビューを任 せ、人間は設計判断だけに集中する —— その3層をNext.js + TypeScriptの実装例で解 説。 ken imoto - kenimoto.dev AIコードレビューを “仕組み化する技術” レビュー工数を60%削減した実践設計 そのレビュー、本当に人がやる必要があるのか。 K.E.N. IMOTO AI時代のコードレビュー設計、決定版 コードレビューROI 300件検証 12 kenimoto.dev