AIコードレビューを仕組み化する ― hooks・AI・人間の3層モデル

ハーネス × コードレビュー AIコードレビューを 仕組み化する hooks・AI・人間の3層モデル ken imoto エンジニア / Propel-lab そのレビュー、本当に人がやる必要があるのか。 AIコードレビューを “仕組み化する技術” レビュー工数を60%削減した実践設計 K E N I M O T O AI時代のコードレビュー設計、決定版 AIコードレビュー kenimoto.dev

｜レビューが疲弊している 「インデントが2スペースじゃない」に学びはない。指摘する側も される側も疲れる。 毎週月曜、フォーマット指摘 に 30分 「import順を直して」を書 き続ける ――設計の議論はそこにな い 両方が疲弊した結果、レビュー自体が放置され る。 PRが3日開きっぱなし。誰もコメントしない。Approveだけ押して マージ。これが多くのチームの現実です。 ドキュメントは読まれず、勉強会は忘れられる。お願いは忘れ れ、ルールは破られる。 AIコードレビュー 02 kenimoto.dev

｜なぜ皿洗いに時間を使うのか 機械にできる仕事を人間が抱え込んでいるから、レビューが回らな い。 フォーマット指摘に時間を使うのは、 料理人が皿洗いに時間を使うようなもの。 皿洗い機 自動ゲート スーシェフ AIレビュー ヘッドシェフ 人間レビュー AIコードレビュー 03 kenimoto.dev

｜レビューの3層モデル すべてを人間がやろうとするから疲れる。機械・AI・人間で分業す る。 第1層 自動ゲート hooks / CI・秒単位 機械的に判断できるものは PRに到達させない > 第2層 AIレビュー CodeRabbit / Copilot・分単 位 パターンで検出できるものは AIに任せる > 第3層 人間レビュー チームメンバー・時間単位 判断が必要なものだけ人間 がやる 下から上へ — 速度は落ちるが、判断の質は上がる AIコードレビュー 04 kenimoto.dev

｜「ほぼ毎回」vs「例外なく毎回」 CLAUDE.mdに書くのと、hooksで強制するのは別物。第1層はここ を埋める。 お願い（AGENTS.mdに記載） 80-90% ほぼ毎回。でも10回に1回、壊れたコー ドが通る → 強制（pre-commit / CI） 100% 例外なく毎回。守らないと進めない仕組 みにする 90%の遵守率＝月100PRなら10本が検査なしで本番へ AIコードレビュー 05 kenimoto.dev

｜第1層 — hooksとCIで強制するゲート 機械的チェックを段階で配置する。空港の保安検査と入国審査の2 段構え。 pre-commit 5秒以内に保つ フォーマッター リンター 型チェック > pre-push ゆるい制約 単体テスト コミットは通すが プッシュは止める > CI (GitHub Actions) セーフティネット E2E / ビルド確認 セキュリティスキャン hooks迂回の最終防衛 husky + lint-stagedで変更ファイルだけをチェック — 家全体でなく汚れた部屋だけ掃除する AIコードレビュー 06 kenimoto.dev

｜第2層 — AIに一次レビューを任せる N+1、SQLインジェクション、未使用変数。パターンで拾えるもの はAIが拾う。 CodeRabbit LLM分析 + 40以上の静的解析のデュアルレイヤ ー。 .coderabbit.yamlでパス別の方針とprofile (chill / assertive) を設定 Copilot / Claude PR全体のサマリーと意図の説明が得意。 両方を併用し、検出漏れを下げる保険にする AIは優秀なインターン — 良い仕事をするが、最終判断はシニアがする AIコードレビュー 07 kenimoto.dev

｜第3層 — 人間は設計と方向性だけ 「動くか」ではなく「ここにあるべきか」。機械に判断できない仕 事に絞る。 設計判断 このロジックはこのレイヤーに 属すべきか。既存の抽象化を活 かせているか ビジネスロジック 仕様を正しく実装しているか。 エッジケースは正しい挙動か 方向性の編集 このパターンを増やしたいか、 減らしたいか。どんな未来に進 むか 3層が機能すると、Approveの重みが変わる — 「読んだ」から「方向性に合意した」へ AIコードレビュー 08 kenimoto.dev

｜誰が何を見るか 境界が明確だと、各層が自分の仕事に集中できる。 問題の種類 第1層 自動 第2層 AI 第3層 人間 フォーマット / リンター / 型 ○ テスト失敗 ○ N+1 / セキュリティ脆弱性 ○ 命名の改善 ○ 設計判断 / ビジネスロジック ○ 方向性の編集 ○ AIコードレビュー 09 kenimoto.dev

｜フィードバックループで進化する レビューは情報生成プロセス。得た知見を捨てず、AGENTS.mdに 還元する。 PRをレビュー > 増やす / 減らす 方針が決まる > AGENTS.mdの 方針を更新 > AIが新方針で コードを書く 繰り返す指摘は review-patterns.jsonl に蓄積し月次集計 — 翌月、同じ問題が減れば 成功 AIコードレビュー 10 kenimoto.dev

｜レビューを「仕組み」にする お願いは忘れられ、ルールは破られる。でも仕組みは動き続け る。 信号機を設置したら、警察官が本来の仕事に戻れた。 レビューも同じ — 機械に任せ、人間は判断に集中す る。 機械的チェックはhooksで 「例外なく毎回」強制する AIが一次レビュー、人間は 設計と方向性だけ見る 知見をAGENTS.mdに還元 し、仕組み自体を進化させ る AIコードレビュー 11 kenimoto.dev

全体像は、この本に。 Zenn Book zenn.dev/kenimo49/books/harness- code-review Kindle amazon.co.jp/dp/B0GHT7FQ7G hooks・AI・人間の3層モデルと、仕組みが進化し続けるレビュー設計 を実装例つきで。 kenimoto.dev そのレビュー、本当に人がやる必要があるのか。 AIコードレビューを “仕組み化する技術” レビュー工数を60%削減した実践設計 K E N I M O T O AI時代のコードレビュー設計、決定版 AIコードレビュー 12 kenimoto.dev