コードレビューを6段階にしたら、AIと人間の分業が見えた

AIコードレビュー AIと人間の境界線を引く コードレビューを6段階に分ける ken imoto エンジニア / Propel-lab AIコードレビューを “仕組み化する技術” レビュー工数を60%削減した実践設計 KEN IMOTO AI時代のコードレビュー設計、決定版 AIコードレビュー kenimoto.dev

3つのバグを通した CodeRabbit も Copilot も指摘せず、私も「AIが見たから大丈夫」 とApproveを押した。 BUG 01 エッジケースの 判定漏れ BUG 02 空配列の 扱いミス BUG 03 外部APIの リトライ条件のずれ 気づいたのはリリースの3日後。怖かったのは「自分のレビュー判断が信用できなくなった」感覚だっ た。 AIコードレビュー 02 kenimoto.dev

3層モデルでは粒度が粗い 3層だとLogic層に全責任が押しつけられる。6段階に切り直すと境 界が見えた。 3層モデル 設計図 誰が何を見るか 大きな構造の分業 6段階 設計図の寸法 境界はどこで切れるか もう一段細かい解像度 AIコードレビュー 03 kenimoto.dev

6段階の定義 下に行くほどAI比率が段階的に下がる。 1 Format AI 100% / 人 0% 2 Lint AI 100% / 人 0% 3 Style AI 90% / 人 10% 4 Logic AI 60% / 人 40% 5 Design AI 30% / 人 70% 6 Architecture AI 0% / 人 100% AIコードレビュー 04 kenimoto.dev

AIが降りるのではない 問題の性質が変わっていくのだ、と捉えると整理しやすい。 STAGE 1 - Format 正解がある インデント、改行、セミコロン。機械的に一意 に決まる。 STAGE 6 - Architecture 正解がない システム境界、データフロー。未来予想であっ て正解ではない。 下に行くほど正解が一意でなくなる。だからAIの出る幕が段階的に減っていく。 AIコードレビュー 05 kenimoto.dev

段階1-2: Format / Lint 「PRにすら到達させない層」。人間の判断は1ミリも要らない。 Format AI 100% 見た目の規約。 壊れても動く。 pre-commit hook / Prettier Lint AI 100% 意味の規約。 壊れたら動かない。 ESLint / Ruff / mypy / tsc この2段階を分けて hooks で固め、毎週30分の指摘時間を構造的にゼロにした。 AIコードレビュー 06 kenimoto.dev

段階3: Style(90% AI / 10% 人間) 命名・分割粒度・可読性。CodeRabbitとCopilotが得意だが完全自 動化はできない。 90% AIが指摘を出す CodeRabbit / Copilot が候補を提示。 10% 人間が最終承認 「この提案は採用、これは却下」を判断。却下理由を 一行残すと次のAI精度が上がる。 getUserData を fetchUser に変えるべきかはコードベース全体の命名規則を見ないと決まらない。 AIコードレビュー 07 kenimoto.dev

段階4: Logic - 一番危ない場所 バグ検出精度のベンチマーク。半分以上は見逃すと思っておくのが 安全。 48% Macroscope 46% CodeRabbit 42% Cursor BugBot 24% Greptile 私が通した3バグは全部「仕様書由来のエッジケース」。仕様を見ないAIは、コードベース内の整合性し か見られない。 AIコードレビュー 08 kenimoto.dev

境界の引き方が逆になりがち 「AIが問題なしと言った」は、人間がスキップする理由にならな い。 AIが指摘した部分はAIに任せ、 AIが指摘しなかった部分こそ人間が念入りに見る。 AIコメントが多いPR 人間レビューは短く済む。 AIコメントがゼロのPR 仕様書を開いて30分かけて読む価値がある。 AIコードレビュー 09 kenimoto.dev

段階5-6: Design / Architecture ここはAIの出る幕が一気に減る。方向性の判断は人間の領域。 Design AI 30% / 人間 70% 責務分割・API境界・依存の向き。AIはパターンを 増やすか減らすかを判断できない。効くのは2人ペ アレビュー。 Architecture AI 0% / 人間 100% 判断は「正解」ではなく「未来予想」。PRの前に ADRを書き、テックリードが30分議論する設計会 議。 AIコードレビュー 10 kenimoto.dev

チーム導入のステップ いきなり6段階を全部入れると挫折する。現実的な順序がある。 1 Stage 1-2 を hooks で固める 1日で終わる。即日効果が出る。 2 Stage 3 に CodeRabbit / Copilot 契約があれば無料。1週間慣らす。 3 Stage 4 のための仕様書整備 一番時間がかかる。仕様由来のエッジケースを明文化。 4 Stage 5-6 はチーム文化に ペアレビューとADR。仕組み化より習慣化。 AIコードレビュー 11 kenimoto.dev

6段階の土台にある3層モデルを、 仕組み化の全体像として体系化。 Zenn Book ¥1,000 zenn.dev/kenimo49/books/harness-code-review Kindle amazon.co.jp/dp/B0GHT7FQ7G 『AIコードレビューを仕組み化する技術』全15章。hooks・AI・人間の 3層モデルを実装レベルで解説。 kenimoto.dev AIコードレビュー 12 AIコードレビューを “仕組み化する技術” レビュー工数を60%削減した実践設計 KEN IMOTO AI時代のコードレビュー設計、決定版 kenimoto.dev