「PRが溜まっていく一方で、自分のコードを書く時間が取れない」「レビュー観点が人によってバラバラで、結局リリース後にバグが出る」。マネージャー層から、こうした相談が増えています。
レビューの遅延は、開発スピードと品質の両方を蝕みます。とはいえ、単純に「AIに全部レビューさせる」では、肝心の設計レビューや業務文脈の確認が抜け落ちてしまいます。本記事では、Claude Code をPRの一次レビュー担当として組み込み、人レビューが本質判断に集中できる導線の作り方を整理します。
一次レビューと最終レビューを分ける、という発想
まず押さえたいのは、「レビューを丸ごとAIに任せる」ではなく、観点を分担するという考え方です。
レビューには大きく2層あります。
- 一次レビュー（定型観点）：命名・null安全・例外処理・テスト有無・規約違反など、チェックリストで機械的に判定できるもの
- 最終レビュー（文脈判断）：業務要件との整合、設計方針との一貫性、影響範囲の見立て、レビュアーの責任範囲
Claude Code に任せるのは前者、人が引き受けるのは後者です。この線引きを明確にしないまま導入すると、「AIがOKを出したから人は見ない」という事故か、「結局二度手間で時間が増えた」という反発のどちらかが起きます。
「人とAIで責任の境界を引く」という設計思想は、PMがClaude Codeを使うときに守るべき3つのルールで扱った原則と地続きです。レビューでも同じく、責任の置き場所を最初に決めるところから始めます。
Claude Code を一次レビューに組み込む4ステップ
実装の流れはシンプルです。
1. レビュー観点をチェックリスト化する
まず、いまチームで暗黙に行っているレビュー観点を棚卸しします。「テストが書かれているか」「ログ出力に個人情報が含まれていないか」「マジックナンバーが残っていないか」など、判定基準が一意に決まる項目だけを抽出してください。
抽出した観点は、.claude/commands/pr-review.md のようなスラッシュコマンド、または CLAUDE.md のレビューセクションにまとめます。プロジェクト固有の規約（例：日付は ISO 8601、エラーは独自例外クラスを使う）も、ここに集約しておくとブレません。
.claude/commands/pr-review.md のサンプルです。
---
description: "PRの一次レビューを実行する（定型観点のチェック）"
---
渡された差分を以下のチェックリストでレビューし、
問題があれば `ファイル名:行番号 | 重要度 | 指摘内容` の形式で出力すること。
重要度は must / should / nits の3段階。
## チェックリスト
- [ ] テストが存在する（新規機能は少なくとも1テスト）
- [ ] テストが通る（CIパスを確認）
- [ ] `console.log` ・デバッグ用コードが残っていない
- [ ] マジックナンバー・ハードコード文字列が残っていない
- [ ] ログ出力に個人情報・機密情報が含まれていない
- [ ] 命名規則（camelCase / kebab-case等）がプロジェクト標準と一致している
- [ ] 例外処理が変更履歴中、エラーは独自例外クラスを通す
- [ ] 外部API・データベースへの新規接続があればレビューコメントで明記する
## 最終判断しないこと
- 業務要件との整合性（これは人間が判断する）
- アーキテクチャ方針との一貫性（同上）2. 差分を渡してレビューさせる
Claude Code に PR の差分（git diff main...HEAD）と、ステップ1のチェックリストを渡します。出力フォーマットは「ファイル名・行番号・指摘内容・重要度（must / should / nits）」の4列で固定するのがおすすめです。
重要度を3段階で出させると、最終レビュアーが must だけ確実に潰す 運用に切り替えられます。
3. PRコメントとして自動投稿する
GitHub Actions などから Claude Code を叩き、結果を PR コメントに自動投稿する導線を作ります。レビュアーは PR を開いた瞬間、すでに一次レビューが終わっている状態でレビューを始められます。
# .github/workflows/ai-pr-review.yml
name: AI First Review
on:
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: Generate diff
run: |
git diff origin/${{ github.base_ref }}...HEAD > /tmp/pr.diff
- name: Run Claude Code review
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
claude --print \
--context "$(cat .claude/commands/pr-review.md)" \
"$(cat /tmp/pr.diff)" \
> /tmp/review-result.md
- name: Post review comment
uses: actions/github-script@v7
with:
script: |
const fs = require('fs');
const body = fs.readFileSync('/tmp/review-result.md', 'utf8');
github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
body: `## 🤖 AI 一次レビュー\n\n${body}\n\n---\n_人間レビュアーは業務要件と設計観点を確認してください_`
});この workflow は ANTHROPIC_API_KEY を GitHub Secrets に登録することで動きます。
このとき、人がレビューを開始する前に必ず一次レビューが回り終わっていることが重要です。タイミングがずれると、人とAIが同じ指摘を二重で書く混乱が起きます。
4. 人レビューは「設計と業務文脈」だけ見る
一次レビューが終わった PR で、人レビュアーが見るのは「業務要件と合っているか」「アーキテクチャ方針からズレていないか」「他チームへの影響はないか」の3点に絞ります。
定型観点は AI が拾い切っているので、レビュアーの集中力が温存され、本当に止めるべき PR を確実に止められるようになります。
レビュー文化を壊さないための運用ルール
導入時に必ず決めておきたいルールが3つあります。
ひとつ目は、AIの指摘を鵜呑みにしないことです。Claude Code の指摘も、誤検知や文脈外しは普通に起きます。レビュアーは「AIの指摘 → 妥当性を判断 → 採否を明記」のステップを踏んでください。レビュー観点そのものをAIで補強する考え方は、AI生成コードのレビュー観点 4つの視点で扱った「人が見るべき観点」と組み合わせると強力です。
ふたつ目は、指摘ログをチームで共有します。AIが頻繁に指摘するパターンは、コーディング規約や CI ルールに昇格させます。レビューが「学習する仕組み」に変わります。
みっつ目は、段階的に導入しましょう。いきなり全リポジトリに広げず、小さなチーム・低リスクなリポジトリから始めます。導入の進め方は Claude Codeのチーム導入を3段階で設計する も参考にしてください。
まとめ：レビュー時間ではなく、レビューの質を取り戻す
Claude Code を一次レビューに組み込むと、レビュー時間が単に短くなるだけではありません。人レビュアーが「設計と業務文脈」という、本来人にしかできない判断に集中できるようになります。
- 一次レビュー（定型）と最終レビュー（文脈）を分ける
- チェックリスト → 差分投入 → 自動投稿 → 人レビューの4ステップで導線化
- 鵜呑み禁止・指摘の規約化・段階導入の3ルールで文化を壊さない
レビューが詰まる現場ほど、最初の一歩は「観点の棚卸し」から始めてください。何を機械に任せ、何を人が握るかを言語化すること自体が、チームのレビュー文化を強くします。
AIで品質ゲートを設計し、レビュー文化と AI の分担を体系的に学びたい方は、テックエイドの講座「AIエンジニアリング実践（AIX-101 / AIX-102）」をご覧ください。Claude Code を含む AI ツールを、現場の品質プロセスにどう組み込むかを実装レベルで解説しています。