PR レビューこそ LLM に置き換えるべきだ：人間レビューを「オプション」にする時代の実装指針

結論から書くと、PR レビューはコーディング規約・セキュリティ・テスト網羅性チェックなど機械的な観点では LLM のほうが速く・正確で・遠慮なく指摘できます。人間レビューは「組織の長期方針」「設計判断」「文化継承」の3点に集中させて、それ以外は LLM に任せるのが現代的なフローです。

この記事では、なぜ「LLM-first」に切り替えるべきか、3つの実装パターン（SaaS（Software as a Service） / 自前 / 社内ホスト）の比較、プロンプト設計のコツ、よくある反論への返答までまとめます。

1. 人間レビューが遅くなる構造的な理由

「レビューが遅い」は怠慢ではなく 構造的な必然 です。複数の独立した要因が重なって、結果として 24 時間超えが常態化します。

• レビュアーの作業が止まる: 集中していたタスクを中断するコスト（コンテキスト切替で 10〜20 分が一般的に言われる）が乗る。だから後回しにされる
• 依頼者が「相手の時間を奪う」と気が引ける: 結果として PR を大きく溜めがち → 1 PR あたり変更量が増えてレビューがさらに重くなる 悪循環
• タイムゾーン差: グローバル開発では 1 往復で 24 時間
• レビュー品質のばらつき: 同じコードでも疲れた金曜の夕方と月曜朝で精度が違う
• 「指摘ゼロ」は心理的に書きにくい: 何か書かないと申し訳ない → 些末な指摘の応酬が増える
• 全 diff を熟読しない: 時間制約で「主要箇所だけ読む」が暗黙の標準。本人もそれを自覚していない

2. LLM レビューの構造的な強み

上記の「構造的な必然」を、LLM はそもそも持ちません。

「人間レビューを完全に廃止すべき」とは言っていません。表の下 3 行が示す通り、人間にしかできない領域は確実にあります。問題は「全 PR を人間レビュー必須」という現状の運用であって、機械的観点を LLM に肩代わりさせて、人間は本当に必要な PR にだけ集中する のが本記事の主張です。

3. LLM-first レビューの 3 つの実装パターン

A. SaaS — 「とりあえず明日から始める」最短ルート

• CodeRabbit: PR コメント形式で詳細レビュー、サマリも生成。日本語対応。OSS は無料
• Greptile: コードベース全体をインデックス化してレビュー、依存関係への影響まで指摘
• Cursor Bugbot: バグ検出に特化、信頼度の高い指摘だけ出す傾向
• GitHub Copilot Code Review: GitHub ネイティブで設定が最少、Enterprise プランに含まれる

B. 自前実装 — Claude + GitHub Actions

プロンプトを社内コーディング規約に最適化したい場合、また SaaS の指摘が一般論的すぎる場合は、GitHub Actions で自前実装するのが現実解です。

name: Claude PR Reviewon:  pull_request:    types: [opened, synchronize]
jobs:  review:    runs-on: ubuntu-latest    permissions:      pull-requests: write      contents: read    steps:      - uses: actions/checkout@v4        with:          fetch-depth: 0
      - name: Get diff        id: diff        run: |          git diff origin/${{ github.base_ref }}...HEAD > /tmp/pr.diff          # 巨大 diff はトリミング (Claude 200k token 制限対策)          head -c 500000 /tmp/pr.diff > /tmp/pr.diff.trimmed          echo "diff<<EOF" >> $GITHUB_OUTPUT          cat /tmp/pr.diff.trimmed >> $GITHUB_OUTPUT          echo "EOF" >> $GITHUB_OUTPUT
      - name: Claude review        id: review        uses: anthropics/claude-action@v1        with:          api_key: ${{ secrets.ANTHROPIC_API_KEY }}          prompt: |            あなたは熟練のコードレビュアーです。以下の PR diff をレビューしてください。
            ## 弊社のコーディング規約 (要約)            - TypeScript strict、any 禁止            - 関数 1 つあたり 50 行以内、超える場合は分割            - エラーメッセージは WHAT/WHY/HOW の 3 層で書く            - DB アクセスは Repository 層を経由、ハンドラから直接呼ばない            - テストは Happy Path / 認可 / バリデーション / 境界値の 4 観点最低限
            ## レビュー観点 (この順で重要)            1. ロジック誤り・エッジケース未考慮            2. セキュリティ脆弱性 (XSS / SQLi / 認証漏れ / 権限チェック漏れ)            3. 規約違反 (上記の規約に抵触している箇所)            4. テスト不足 (新規ロジックにテストがない / エラーケース未網羅)            5. 命名・可読性
            ## 出力形式            - 重要度を **Critical / Major / Minor / Nit** で必ず分類            - 各指摘に **ファイル名:行番号** を必ず添える            - **「なぜ問題か」と「どう直すか」を 1〜2 行で書く**            - 問題が無い箇所は言及しない (positive なノイズを増やさない)            - 全体を 5 件以内に絞る (情報過多を避ける)
            ${{ steps.diff.outputs.diff }}
      - name: Post comment        uses: peter-evans/create-or-update-comment@v4        with:          issue-number: ${{ github.event.pull_request.number }}          body: |            ## 🤖 Claude review
            ${{ steps.review.outputs.response }}
            <sub>このコメントは LLM が生成しました。設計判断・意図に関わる箇所は人間レビュアーの判断を優先してください。</sub>

C. 社内ホスト — diff を社外に出せない場合

• AWS Bedrock の Claude: VPC 内で完結、データは Anthropic に送られない契約
• Azure OpenAI: Microsoft の SOC 2（Service Organization Control 2） / ISO 認証範囲内で利用可
• 自社 GPU の OSS LLM (Llama 3.x / Qwen 等): 機密度が極めて高い領域。レビュー精度は商用 LLM より一段落ちることを織り込む

4. プロンプト設計：ノイズを減らす 5 つのコツ

1. 1社内規約をプロンプトに埋込む: 「TypeScript strict」「any 禁止」「関数 50 行以内」など具体的に。LLM の素の傾向を上書きする
2. 2指摘の重要度分類を強制する: Critical / Major / Minor / Nit。これがないと「全部同じ強さで指摘」になり、依頼者がノイズに埋もれる
3. 3ファイル名:行番号を必ず添えさせる: GitHub の UI（User Interface） で該当行にジャンプできる。これがないと検証コストが上がる
4. 4「問題のない箇所には言及しない」と明示: positive なノイズ (「この関数は綺麗です」等) を抑制
5. 5指摘件数の上限を切る: 「全体で 5 件以内」「Critical のみ」など。LLM は放っておくと 30 件出してくる

5. LLM レビューだけにするリスクと対策

「全 PR を LLM だけに任せる」と必ず事故が起きます。リスクを認識した上で、人間レビュー必須ゾーン を CODEOWNERS で残すのが現実解です。

6. CODEOWNERS で「人間レビュー必須ゾーン」を切る

全 PR で人間レビュー必須 をやめて、重要度分岐 に切り替える。CODEOWNERS の活用例:

# デフォルト：人間レビュー任意（LLM レビューは別 workflow で必須）# このファイルに記載のないパスは、LLM レビューだけで merge 可能
# アーキテクトの目を必ず通すゾーン/src/core/                     @arch-team/src/auth/                     @arch-team @security-team/infra/                        @platform-team/.github/workflows/            @platform-team
# DB マイグレーションは慎重に/db/migrations/                @data-team @arch-team/dbt/models/marts/             @data-team
# セキュリティ関連/src/lib/crypto/               @security-team/src/lib/auth/                 @security-team
# 例外: 規約・README 等の文書だけの変更は LLM レビューも不要*.md                           # owner なし → LLM レビューもスキップする workflow 条件分岐へ

GitHub の branch protection rule で「CODEOWNERS approval required」を有効化すると、上記パス変更時のみ人間レビューが必須になります。それ以外のパスは LLM レビュー必須 + テストグリーン だけで merge 可能。

7. 段階的な移行ロードマップ

1. 1Step 1 (Week 1-2): LLM レビューを 任意 で導入。現状の人間レビューに 追加 する形。指摘の S/N 比を 1 ヶ月観察
2. 2Step 2 (Month 2): 「Minor / Nit は LLM 完結 OK、Major / Critical は人間も見る」 ルールに移行。応答時間が大きく改善するはず
3. 3Step 3 (Month 3-4): CODEOWNERS で人間レビュー必須ゾーン を確定。それ以外は LLM 必須 + テスト + 自己レビュー で merge 可能に
4. 4Step 4 (Month 5-6): DORA Lead Time の改善を測定 (EP.09)。経営層に「PR レビュー LLM 化により Lead Time が大きく改善した」と数字で報告
5. 5継続: プロンプト改善、SaaS と自前のハイブリッド、社内モデルへの拡張など、組織の成熟度に合わせて深掘り

8. よくある反論への返答

Q1. 「コードレビューは設計の議論の場でもある。LLM ではそれが失われる」

設計の議論は PR レビューの場ですべきではない、というのが本記事の立場です。設計議論は PR を書く 前 に RFC / Design Doc / 簡易な GitHub Discussion で行い、PR レビューは「設計が合意された前提でその実装をチェックする」段階に絞る。設計議論を PR レビューでやろうとするから時間がかかる、とも言えます。LLM 化は設計議論の場を奪うのではなく、設計議論を別フェーズに切り出す圧力になります。

Q2. 「新人教育の場が失われる」

全 PR を人間レビューする = 新人教育、ではない。実際には 新人の PR を見る時間が無くて雑にスタンプを押している のが多くのチームの現実。月 1 のペアレビュー会、新人 PR は CODEOWNERS で先輩 1 名アサイン、設計判断のレビューは人間 といった形で、教育を必要な場所に集中させた方が質が上がる。

Q3. 「LLM のレビュー精度が信用できない」

人間レビューの精度を測ったことはありますか？ 多くの組織で人間レビューの「指摘の S/N 比」「重要バグの検出率」は計測されていません。LLM レビューは少なくとも すべての指摘がログに残るので測定可能 です。測定可能な仕組みのほうが改善できる、というのは Engineering Dashboards シリーズ全体の主張でもあります (EP.01 参照)。

Q4. 「LLM が見落とすバグが怖い」

人間も見落とします。むしろ「人間がレビューしたからもう大丈夫」という心理が、テスト不足・自己レビュー不足の温床になっています。LLM レビュー + 自己レビュー + 必須テスト + 主要パスの人間レビュー という多層防御の方が、結果的に検出率は上がります。

Q5. 「コストがかかる」

Claude や GPT への 1 PR あたりの API コストは、現在の価格水準で 数円〜数十円 程度が目安です (PR サイズによる)。これに対して 人間レビュアーの時給 × レビュー時間 は数千円〜1 万円超。コストで言えば LLM の方が 2 〜 3 桁安い ことが多い。SaaS でも 1 シート月 $10〜30 程度。

Q6. 「ベンダーロックインが心配」

プロンプトを リポジトリに置いて、モデル抽象化レイヤーを挟む だけで Claude / OpenAI / Gemini のどれにでも切替可能。SaaS を使う場合も「プロンプトを `.coderabbit.yaml` 等で管理して、最悪自前に切替できる」状態を維持しておけば実害は少ない。

9. 効果測定：ダッシュボードに載せる指標

「LLM-first レビューに切り替えた」効果を測るには、以下を時系列で記録します。Engineering Dashboard (EP.10) に追加すれば、移行前後の効果を経営層に説明できます。

10. 関連記事と次の話

• EP.02 GitHub API で PR・レビュー活動を集計 — レビュー応答時間の実装
• EP.03 Claude / Anthropic API の usage 集計 — LLM レビューのコスト把握
• EP.09 DORA 4 metrics + AI 活用度 — Lead Time 改善の測定
• EP.10 1 枚の Engineering Dashboard 設計 — 効果測定の統合
• Claude Code 受託開発記 — AI ネイティブ開発の現場

「LLM-first レビュー」は移行プロジェクトとしてはサイズが大きく、CODEOWNERS 設計・プロンプト改訂・効果測定までやり切るには 3〜6 ヶ月かかります。ふくふくでは Engineering Dashboard 構築と並走で支援する形を取っています。読者リアクションに応じて、各ツール (CodeRabbit / Greptile 等) の比較深掘り、業界別の運用パターン、社内 LLM ホストの実装ガイドなど、続編を追加していきます。