---
title: コードレビュー指摘300件を3ヶ月分類したら効いていたのは2種類だけだった ─ Bug/Spec死守・残り4種類はPRから外す
tags:  #コードレビュー #ハーネスエンジニアリング #aiコードレビュー #開発生産性 #メトリクス #conventionalcomments  
author: [井本 賢](https://image.docswell.com/user/kenimo49)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GJ5M3ZVMJ4.jpg?width=480
description: 私は3ヶ月で300件のレビュー指摘を全部直した。PRが nit: で埋まり、AIレビューを増やしたら疲れがピークに達した。指摘を6カテゴリ×3指標で採点し直したら、効いていたのは Bug と Spec の2種類だけだった。残り4種類(Style / Naming / Refactor / Architecture)は、廃止・自動化・PR前に潰す のどれかへ場所替えする。本スライドは元記事の要点を12枚で俯瞰する teaser 版。ヒートマップ、Bug/Spec の複利例、はてブで挙がった論点への応答、自チーム50件で試す3ステップまで。  ▼元記事(Zenn・無料) https://zenn.dev/kenimo49/articles/code-review-300-comments-2-effective-categories  ▼Zenn Book「AIコードレビューを仕組み化する技術 -- hooks・AI・人間の3層モデル」(¥1,000) https://zenn.dev/kenimo49/books/harness-code-review  ▼Kindle版(¥1,500) https://www.amazon.co.jp/dp/B0GHT7FQ7G  著者: ken imoto / kenimoto.dev
published: July 06, 26
canonical: https://image.docswell.com/s/kenimo49/KWRLEY-code-review-300-comments
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GJ5M3ZVMJ4.jpg)

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

# Page. 2

![Page Image](https://bcdn.docswell.com/page/LE3W69D9E5.jpg)

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

# Page. 3

![Page Image](https://bcdn.docswell.com/page/8EDKVGP87G.jpg)

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

# Page. 4

![Page Image](https://bcdn.docswell.com/page/V7PKV3NWJ8.jpg)

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

# Page. 5

![Page Image](https://bcdn.docswell.com/page/2JVVZ4K9JQ.jpg)

同じ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

# Page. 6

![Page Image](https://bcdn.docswell.com/page/5EGL41Q4JL.jpg)

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

# Page. 7

![Page Image](https://bcdn.docswell.com/page/4JQYGDKR7P.jpg)

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

# Page. 8

![Page Image](https://bcdn.docswell.com/page/K74W5ZPQE1.jpg)

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

# Page. 9

![Page Image](https://bcdn.docswell.com/page/LJ1YWR9LEG.jpg)

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

# Page. 10

![Page Image](https://bcdn.docswell.com/page/GJWG61QQ72.jpg)

はてブで挙がった論点への応答
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

# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EZLYPW373.jpg)

自チームの直近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

# Page. 12

![Page Image](https://bcdn.docswell.com/page/Y76WDMGZ7V.jpg)

続きは、この本に。
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