はじめに
Claude Codeを「実装させるツール」として使うだけでは、半分しか活用できていない。
実装後の最大のボトルネックは「コードレビュー待ち」だ。人間のレビュアーを待つ間、次のタスクに移れず、レビューコメントが返ってきたら文脈を思い出すコストがかかる。Claude Codeをレビュアーとして使うと、この流れが変わる。
PR作成前に問題を自分で潰せるようになり、人間のレビュアーは「アーキテクチャと業務ロジック」に集中できる。「Claude Codeで実装してそのままPR」ではなく、「Claude Codeで実装→Claude Codeでレビュー→人間がアーキテクチャ確認」というループが理想の形だ。
レベル1：ローカルセルフレビュー（PR前の品質チェック）
最もシンプルな活用法で、今日からすぐ使える。PR作成前に自分の変更をClaudeにレビューさせるだけだ。
「この変更について厳しく質問して。
テストに合格するまでPRを作らないで」
この一言で、Claudeが「実装者」から「批判的なレビュアー」に役割を変える。エッジケースの指摘、セキュリティ上の懸念の洗い出し、「本当にこのアプローチが最善か」という設計への疑問——実装した直後だからこそ気づきにくい問題を浮かび上がらせてくれる。
差分ベースの検証も効果的だ。
「これが動作することを証明して
（mainとfeatureブランチの動作差分を見せて）」
変更が意図通りに機能し、既存機能に悪影響を与えていないことをClaudeに自己証明させる。人間が手動で差分確認するより速く、見落としが少ない。セキュリティ観点に特化したレビューが必要なときは /security-review コマンドをPR前の最後の安全確認として使う。
レベル2：47点チェックリストによる体系的セルフレビュー
もう一段踏み込むなら、Code Review ProtocolというSkillsファイルを使う方法がある。
# ~/.claude/skills/code-review-protocol.md
以下の47点チェックリストでコードをレビューして：
セキュリティ（優先度：高）
- SQLインジェクション脆弱性
- XSSアタックベクター
- 認証バイパスの可能性
- データ露出リスク
- 依存関係の既知脆弱性
コード品質
- 未使用インポート・デッドコード
- console.log等のデバッグアーティファクト
- マジックナンバー（定数化すべき値）
- 未処理のエッジケース
- エラーハンドリングの完全性
ベストプラクティス
- 命名規約の遵守
- DRY原則違反
- 関数の複雑度
問題を発見した場合は、ファイル名・行番号・問題の説明・修正案を報告して。
実績として、手動レビュー20分→自動2分（90%削減）という効果が出ている。「47行のMarkdown」がレートリミットのないAPIエンドポイントを検出し、本番環境でのDDoSを未然に防いだ事例もある。
レベル3：Claude Code Review Plugin（自動PRレビュー）
⚠️ Team/Enterpriseプラン限定機能：Code Review Pluginは現在Team・Enterpriseプランのリサーチプレビューとして提供されている。個人・Proプランでは利用不可。
Anthropic公式の「Code Review Plugin」を使うと、GitHubのPRが開かれたタイミングで5エージェント並列によるレビューが自動実行される。
PR作成/プッシュ
↓
GitHub Action が /code-review を自動起動
↓
5つの専門エージェントが並列分析（所要時間：平均20分）
│ ① CLAUDE.md準拠チェック
│ ② バグ・ロジックエラー検出
│ ③ gitヒストリーによるコンテキスト分析
│ ④ 過去のPRコメントとの整合性確認
│ ⑤ コードコメントの正確性検証
↓
信頼スコア0-100で採点
↓
80以上の指摘のみをインラインコメントとして投稿
設置はGitHub Actionsのワークフローファイルを1つ追加するだけだ。
# .github/workflows/code-review.yml
name: Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: anthropics/claude-code-action@v1
with:
command: /code-review
anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
パフォーマンスデータ（Anthropic実測値）によると、大型PR（1,000行以上）の84%で指摘あり、平均7.5件の指摘が出る。小型PR（50行以下）では31%・平均0.5件だ。信頼スコア80未満をフィルタリングすることで偽陽性を大幅に削減しており、「AIのレビューはノイズが多い」という不満を解消する設計になっている。
反復レビュー→修正ループの自動化
指摘が出なくなるまで自動でレビュー→修正→再レビューを繰り返す手法も強力だ。
「コードのレビューを実施して。
問題があれば修正して再レビューして。
指摘がなくなるまで最大5回繰り返してOK。
テストが2回連続で失敗したら停止して報告して」
CLAUDE.mdに以下を書いておくと、このループが主要マイルストーン後に自動で発動するようになる。
## コードレビュールール
主要マイルストーン（5ファイル以上の変更・公開API変更・インフラ変更）の後は
必ずcode-reviewスキルを実行し、指摘がなくなるまで反復すること。
コミット・PR作成前の最終確認として必須。
セキュリティレビューへの応用
セキュリティ観点のレビューには /security-review コマンドを使う。Claudeはコードフローを理解した上で、根拠のある指摘のみを報告する「フォースマルチプライヤー」として機能する。セキュリティ特化の詳細な防御手法・CVE情報については別記事「Claude Codeのセキュリティ完全ガイド——プロンプトインジェクション攻撃から守る5層防御の設計」を参照してほしい。
フィードバックループ：品質を2〜3倍にする原則
最後に、レビュー活用の土台になる考え方を一つ共有しておく。CLAUDE.mdに検証コマンドを明記するだけで、実装完了後にClaudeが自動で検証を実行し、テストが通らなければ自律的に修正ループを回す。人間がレビューするのは「動作確認済みのコード」だけになる。Claude Codeチームの実績では、フィードバックループがあると品質が2〜3倍向上するというデータがある。
## Verification
- npm test
- npm run lint
- npm run typecheck
ビフォーアフター
Before（実装のみ、レビューは人間待ち）
Claude Codeで実装してそのままPRを作成し、人間のレビュアーが細かいバグ・セキュリティ問題を指摘する。コンテキストを思い出しながら修正するのに2〜3日かかり、「なんで最初からちゃんとやらなかったの」感が残る。
After（実装→セルフレビュー→PR）
Claude Codeで実装した後、「この変更について厳しく質問して。テストが通るまでPRを作らないで」と一言入れる。Claudeが問題点・エッジケース・セキュリティを自己指摘して修正ループを回し、クリーンな状態でPRを作成する。人間のレビュアーはアーキテクチャ・業務ロジックだけに集中でき、レビュー時間が1/3〜1/5に短縮される。
まとめ：3つのレベルと今日からできること
レベル1（ローカルセルフレビュー）は今日すぐ使える。次のPR前に「この変更について厳しく質問して。テストが通るまでPRを作らないで」を試すだけだ。
レベル2（47点チェックリストSkill）は今週中に ~/.claude/skills/code-review-protocol.md を作成することで実現できる。
レベル3（Code Review Plugin）はTeam/Enterpriseプランのチームが対象だが、PRへの自動コメントという形で開発フローを根本から変える。
「実装して終わり」ではなく「実装してレビューして初めて完了」という習慣が身につくと、PRを出すたびに感じていたあの不安がかなり消える。
コメント