PRレビューが追いつかない問題への現実解 — crit でのセルフレビューと AI コードレビューエージェント

ボトルネックはコードを書く側からレビューする側へ

Claude Code や Codex のようなコーディングエージェントが普及して、コードを「書く」コストは劇的に下がった。 その結果、チームのボトルネックははっきりとレビューする側に移った。 エージェントが30分で作った1,500行のPRを、人間が30分でレビューできるはずがない。 出す側は楽になったのに、受ける側の負荷は増える——この非対称が2026年のコードレビューの前提条件だ。

しかも負荷は「他人のPRを見る」だけではない。エージェントに書かせたコードを自分でレビューしてからPRに出すセルフレビューも、 GitHub の Files changed タブを何度もスクロールする苦行になりがちだ。 本記事では、この2種類のレビュー負荷を減らすソリューションを、マージ前（ローカル）とPR上（リモート）の2層に分けて整理する。

flowchart LR
    A[エージェントが<br/>コードを生成] --> B[ローカル層<br/>crit でセルフレビュー<br/>マージ前に修正ループ]
    B --> C[PR を開く]
    C --> D[PR 層<br/>AIレビュアーが一次レビュー<br/>Greptile / CodeRabbit / Copilot]
    D --> E[人間のレビュー<br/>設計判断・仕様の妥当性に集中]
    E --> F[マージ]

    style B fill:#1e3a8a,stroke:#3b82f6,color:#fff
    style D fill:#5b21b6,stroke:#8b5cf6,color:#fff
    style E fill:#14532d,stroke:#22c55e,color:#fff

crit — エージェントと人間の間に「レビューUI」を挟む

crit は Tomasz Tomczyk 氏が公開している MIT ライセンスの OSS で、Go 製の単一バイナリがローカルで完結するレビューツールだ。 発想はシンプルで、「エージェントにとってプランもコードもただのテキストだが、人間にとってプランのレビューと動くアプリのレビューは別の活動だ」という問題意識から、 出力の種類ごとに適したレビューUIをブラウザ上に提供する。

GitHub の PR と同じように、行番号をクリックして単一行に、ドラッグして範囲にコメントを残せる。 仕組みの核心は、コメントが構造化されたレビューファイル（~/.crit/reviews/ 配下の JSON）に書き出されることだ。 ファイルを読めてコマンドを実行できるエージェントなら何でも連携でき、Claude Code のほか Cursor・Copilot・Codex・Aider など十数種の統合が用意されている。

「レビューが終わるまでエージェントを待たせる」ループ

Claude Code 統合では /crit スラッシュコマンドがレビューループ全体を自動化する。 エージェントが crit をバックグラウンドで起動し、人間が Finish Review を押すまでブロックして待つ。 レビューが終わるとコメントを読み、1件ずつ修正して crit comment --reply-to で返信し、承認されるまでこのラウンドを繰り返す。

sequenceDiagram
    participant A as エージェント
    participant C as crit（ローカル）
    participant H as 人間

    A->>C: crit を起動（プラン or diff）
    C->>H: ブラウザでレビューUIを開く
    Note over A: Finish Review まで<br/>ブロックして待機
    H->>C: インラインコメントを残す
    H->>C: Finish Review
    C->>A: レビューファイルを返す
    A->>A: コメントを1件ずつ修正
    A->>C: 修正内容を返信
    C->>H: ライブリロードで差分表示
    H->>C: 承認 or 次のラウンド

特徴的なのが ExitPlanMode のフックだ。Claude Code がプランモードを抜けようとした瞬間をフックでインターセプトし、プランを crit に送って行単位のレビューにかける。ユーザーが承認するまでプランモードを抜けられないため、「プランを流し読みで承認してしまい、実装が始まってから方向違いに気づく」という高くつく失敗をゲートで防げる。 逆方向の連携もあり、レビュー用のサブエージェントを並列に起動して複数の観点からレビューを分散させ、人間はどの指摘を採用するかの判断に専念する使い方もできる。

大きな diff とチームレビューへの拡張

セルフレビューの最大の苦痛は「大きな diff をどこから読めばいいか分からない」ことだ。 crit の story モード（crit story）は、エージェントに diff の「あらすじ」を書かせる機能で、 プロローグ（何が・なぜ変わったか）と、ルーティング・永続化・テストといったテーマ別の章立てで変更ハンクをグループ化して見せる。 ドキュメントが「これは explainer であって reviewer ではない」と明言している通り、指摘はせず、diff を読む前の地図だけを提供する。

crit                    # ブランチの diff を自動検出してレビュー
crit plan.md            # プランのレビュー
crit story              # 大きな diff に章立ての「あらすじ」を生成
crit push               # コメントを GitHub PR にレビューとして投稿
crit pull 42            # PR #42 のコメントをローカルに取り込む
crit share plan.md      # レビューを公開URLで共有（第三者の非同期レビュー）

さらに crit push / crit pull で GitHub PR とコメントを双方向同期できるため、 「ローカルでエージェントと詰め切ってから、そのレビュー履歴ごと PR に載せる」という流れが作れる。 Share 機能を使えば、インストール不要の公開URLで同僚に非同期レビューを頼むこともできる。

PR 上で動く AI レビュアー — Greptile・CodeRabbit・Copilot code review

もう1つの層が、PR が開かれた瞬間に機械が一次レビューを済ませるアプローチだ。 代表格を並べると、設計思想の違いは「diff だけを見るか、コードベース全体を見るか」に集約される。

Greptile の公式ドキュメントは「インストールするとコードベース全体のグラフ——すべての関数・クラス・依存関係——を構築し、 完全なコンテキストで every pull request をレビューする」と明言しており、「この diff は正しく見えるが、別ファイルの前提を壊している」という、diff 単体では原理的に見つからない類のバグ検出を差別化点にしている。 なお各ツールの検出率や誤検出数を比較するベンチマーク記事は複数あるが、条件がまちまちで数値の幅も大きいため、本記事では確認が取れた一次情報のみに絞っている。

最大の課題はノイズ — 「79%が nit」問題

AI レビュアーを導入したチームがほぼ必ずぶつかるのがノイズ問題だ。 Greptile 自身が公開している分析が率直で参考になる。自社ボットが生成したコメントを分類したところ、「良い」コメントは約19%にとどまり、約2%は事実誤認、そして約79%は「技術的には正しいが、対応する価値のない nit」だった。 正しい指摘であってもノイズはノイズで、開発者は数回スルーした時点でボットのコメント全体を読み飛ばすようになる。

興味深いのは改善の方法論だ。まず品質指標として、主観的な評価ではなくaddress rate（開発者が後続コミットで実際に対応したコメントの割合）を採用した。 そのうえで、チームごとに👍/👎されたコメントのベクトル埋め込みを保存し、 新しく生成したコメントを過去の評価との類似度でフィルタする方式を導入した。 結果、address rate は導入から2週間で19%から55%超へ、約3倍に改善した。

実務での組み合わせ方

2つの層は競合ではなく直列に使う。判断基準は「その指摘は誰に向いているか」だ。 エージェントの出力の方向修正はローカル層（crit）、機械的に検出できるバグや規約違反は PR 層（AI レビュアー）、 そして人間のレビューは設計判断と仕様の妥当性だけに絞る。

• PR を開く前：エージェントの成果物は crit でセルフレビューし、修正ループをローカルで回し切る。プランは実装前に /crit でレビューし、方向違いの実装を未然に止める
• 大きな変更：crit story で章立ての地図を作ってから diff を読む。レビュー依頼時にこの「あらすじ」を PR 説明文に転用すれば、他者レビューの立ち上がりも速くなる
• PR 上：AI レビュアーに一次レビューをさせ、nit・規約・明らかなバグを人間の前に処理する。👍/👎を必ず付けてチーム向けに調教する
• 人間のレビュー：「このアプローチでよいか」「仕様の解釈は正しいか」「運用に耐えるか」——機械が答えを持たない問いに集中する

まとめ

• コーディングエージェントの普及で、ボトルネックは「書く」から「レビューする」へ移った。対策はマージ前のローカル層と PR 上のリモート層の2層で考える
• crit はローカル完結の単一バイナリで、プラン・diff・稼働中アプリ・HTML をインラインコメントでレビューし、構造化されたレビューファイル経由でエージェントに修正指示を返す。ExitPlanMode フックでプラン承認をゲート化でき、story モード・GitHub PR 同期・共有URLで他者レビューにも広がる
• Greptile はコードベース全体のグラフを構築して約3分でレビューし、👍/👎から2〜3週間でチームに適応する。CodeRabbit や Copilot code review は diff 中心で導入が手軽
• AI レビュアーの弱点はノイズ。「良い」コメント約19%・nit 約79%という分析があり、address rate を指標にベクトル埋め込みでフィルタした事例では2週間で19%→55%超に改善した。導入後のフィードバック運用が価値を決める