09-03. ケース 3: PR レビュー支援エージェント
シチュエーション
チームで PR レビューが詰まっている。レビュアーが少ない、あるいはレビューに時間がかかりすぎる。 レビュー観点(セキュリティ・パフォーマンス・テスト網羅性・命名)を 抜けなくチェック したいが、人間レビュアーごとに観点がぶれる。
Before (Claude Code を使わない場合)
- 属人化: ベテランレビュアーは多面的に見るが、新人は見落とす
- 時間: 中規模 PR (差分 500 行) で 30〜60 分/PR
- 疲弊: 同じ観点を毎回手動で確認する負担
- 結果: PR が滞留 → 開発速度低下 → モチベ低下
After (Claude Code を使う場合)
| ステップ | 所要時間 |
|---|---|
claude を起動 + GitHub MCP 接続 |
1 回設定 (5 分) |
> PR #123 をレビューして |
1〜2 分(Claude が PR 取得 → 観点別レビュー) |
| 出力 Markdown を確認 | 5 分 |
| 必要なら GitHub にコメント自動投稿 | 1 分 |
| 人間が最終確認 | 10 分 |
| 合計 | 15〜20 分 (従来 30〜60 分) |
必要な道具立て
| 機能 | 何のために |
|---|---|
| CLAUDE.md | このリポジトリ固有のレビュー観点(社内規約、優先事項)を明記 |
| GitHub MCP サーバー | PR の取得、コメント投稿 |
| Skill: pr-review-checklist | レビュー観点(セキュリティ/パフォーマンス/テスト/命名)を強制 |
| Hook: なし(レビューは読むだけなので不要) | — |
Skill .claude/skills/pr-review-checklist/SKILL.md
---
name: pr-review-checklist
description: GitHub PR をレビューする / レビュー観点を整理する時に使う
---
# PR レビュー チェックリスト
## 必ず 4 観点で分けて出力する
### 🔒 セキュリティ
- [ ] ユーザー入力が SQL/シェル/eval に直接入っていないか
- [ ] 認証チェックが新エンドポイントに入っているか
- [ ] 秘密情報が hard-coded されていないか
- [ ] CSRF / XSS 対策
### ⚡ パフォーマンス
- [ ] N+1 クエリ
- [ ] 大きいループ内の同期 I/O
- [ ] キャッシュの活用余地
- [ ] 大規模データのメモリ消費
### 🧪 テスト
- [ ] 新規ロジックに単体テストあり
- [ ] エッジケース(空・null・境界)を網羅
- [ ] 既存テストが壊れていない
### 📖 可読性 / 設計
- [ ] 命名が意図を表しているか
- [ ] 単一責任原則
- [ ] コメントが「何を」より「なぜ」を説明しているか
- [ ] 変更が必要最小限か(scope creep していないか)
## 出力フォーマット
```markdown
# PR #<番号> Review
## ✅ 良い点
- ...
## 🔴 必須修正 (マージブロック)
- [ファイル名:行番号] ... → 提案
```diff
- old_code
+ new_code
```
## 🟡 改善提案 (任意)
- ...
## 💬 質問
- ...
### CLAUDE.md 追記項目
```markdown
## PR レビューの社内規約
- 全 PR にユニットテスト必須(coverage > 80%)
- DB スキーマ変更は migration 付き必須
- 外部 API 呼び出しはタイムアウト/リトライ設定必須
- ログ出力は logger 経由(print 禁止)
ワークフロー
# 一回だけセットアップ
claude /mcp install github # GitHub MCP サーバー設定
# 各 PR で
claude
> PR #123 をレビューして
→ Claude が: 1. GitHub MCP で PR #123 の差分を取得 2. pr-review-checklist Skill 発火 3. CLAUDE.md の社内規約も参照 4. 4 観点で Markdown レビュー出力
> 出力をそのまま PR にコメントとして投稿して
→ GitHub MCP で gh pr comment 123 --body-file <output>。
CI/CD 連携 (08-05 Headless mode の応用)
GitHub Actions で全 PR に自動レビュー:
name: AI PR Review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: |
curl -fsSL https://claude.com/install.sh | bash
claude --print "差分をセキュリティ/パフォーマンス/テスト/可読性 の 4 観点でレビューして" > review.md
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
- run: gh pr comment ${{ github.event.pull_request.number }} --body-file review.md
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
→ 完全自動化。人間は AI の指摘を確認・取捨選択するだけ。
注意点・限界
- AI レビューは "初期スクリーニング" — 最終承認は必ず人間レビュアー(責任の所在を明確に)
- 誤検知: 「セキュリティ問題あり」と言われても本当か検証必要(ハルシネーション率 5〜10%)
- コンテキスト不足: PR の差分だけ見ているので、リポ全体のアーキテクチャ理解が必要なレビューは弱い → CLAUDE.md でカバー
- コスト: 中規模 PR (500 行) で Sonnet 4.6 ≈ $0.05、月 100 PR で $5 程度
- 倫理・法務観点はカバー外: ライセンス、個人情報、契約事項は人間判断
応用
- コード以外のレビュー: ドキュメント PR、ADR (Architecture Decision Record) のレビュー
- デザインレビュー: アクセシビリティチェックなど(画像入力対応モデルが必要)
- リリースノート自動生成: マージ済 PR から「次のリリース」のノートを Claude に書かせる
このケース後にできるようになること
- チーム業務に AI を組み込む 経験を積める(個人作業から組織作業へ)
- レビュー時間が 半減
- 「AI と人間の役割分担」を意識的に設計できるようになる
関連
- 08-03 Skills — pr-review-checklist Skill の作り方
- 08-05 Agent SDK / Headless —
claude --printの活用 - 第7章 MCP — GitHub MCP の仕組み