CodeCraft Lab

PRレビューをClaude Codeで効率化する

PRのレビュー依頼から修正提案の適用まで、一連のワークフローを解説します

ふつう11分で読了
コードレビューPRワークフロー

はじめに

PRレビューは品質を維持する上で欠かせないプロセスですが、時間がかかりがちです。特に大きな差分のPRをレビューするのは大変ですし、レビュー待ちで開発が止まることもあります。

Claude Codeには、ローカルでの差分レビューからGitHub PR上でのレビューまで、コードレビューを効率化する機能が揃っています。このレシピでは、日常のレビューワークフロー全体をカバーします。

2つのレビュー方法

Claude Codeには2つのレビュー方法があります。ローカルの差分をレビューする /code-review コマンドと、GitHub PRをレビューする /review コマンド(gh CLI連携)です。用途に応じて使い分けましょう。

手順

ローカルの変更を自分でレビューする(/code-review)

PRを出す前に、まず自分の変更をClaude Codeにチェックしてもらいましょう。/code-review コマンドを実行すると、現在のブランチの差分を分析してバグや改善点を指摘してくれます。

/code-review

デフォルトでは、アップストリームブランチからの差分と未コミットの変更が対象になります。特定のファイルやブランチを指定することもできます。

# 特定のファイルだけレビュー
/code-review src/services/userService.ts
 
# mainブランチとの差分をレビュー
/code-review main...HEAD

問題が見つかった場合、修正まで任せることもできます。

/code-review --fix
PRを出す前のセルフチェックに

/code-review をPR作成前のルーティンに組み込むと、レビュアーの負荷を減らせます。明らかなバグやスタイル違反は事前に潰しておきましょう。

レビュー観点を指定する

デフォルトのレビューは正確性(バグの検出)に焦点を当てています。特定の観点でチェックしたい場合は、プロンプトで直接依頼しましょう。

セキュリティ観点のレビュー:

この差分をセキュリティの観点でレビューして。
特にSQLインジェクション、XSS、認証・認可の不備、
機密情報の漏洩リスクを重点的にチェックして

パフォーマンス観点のレビュー:

この差分をパフォーマンスの観点でレビューして。
N+1クエリ、不要な再レンダリング、メモリリーク、
大量データ処理のスケーラビリティを確認して

可読性観点のレビュー:

この差分を可読性の観点でレビューして。
命名の適切さ、関数の長さ、コメントの過不足、
責務の分離ができているかを確認して

複数の観点を組み合わせることもできます。

GitHub PRをレビューする(gh CLI連携)

他のメンバーが出したPRをClaude Codeでレビューするには、gh CLIと組み合わせて使います。

まず、PRの内容を確認しましょう。

gh pr view 123 の内容を確認して、変更内容を要約して

次に、PRの差分をレビューします。

gh pr diff 123 を取得して、以下の観点でレビューして:
- ロジックのバグ
- エッジケースの見落とし
- テストの網羅性

PR番号を指定する代わりに、/review スキルを使う方法もあります。

/review 123

レビューコメントを生成して投稿する

レビュー結果をGitHub上にコメントとして残したい場合は、/code-review --comment を使います。

/code-review --comment

これにより、問題が見つかった行にインラインコメントとしてレビュー結果が投稿されます。

投稿前に確認を

--comment オプションはGitHub上にコメントを直接投稿します。内容を事前に確認したい場合は、まず --comment なしで実行して結果を確認してから、改めて --comment 付きで実行しましょう。

レビュー指摘を修正する

自分のPRにレビューコメントが付いた場合、Claude Codeに修正を依頼できます。

gh pr view 123 のレビューコメントを確認して、指摘事項を修正して

または、具体的なコメントを引用して依頼します。

PRのレビューで「この関数にエラーハンドリングが不足している」と
指摘されている。該当箇所を確認して修正して。修正後にテストも追加して

実践例: PRレビューの一連のフロー

実際の開発フローに沿って、Claude Codeを使ったレビューの流れを紹介します。

PRを出す側のフロー

# 1. 変更を完了した後、セルフレビュー
/code-review
 
# 2. 指摘があれば修正を適用
/code-review --fix
 
# 3. テストを実行して問題ないか確認
npm run test を実行して
 
# 4. PRを作成
この変更でPRを作成して。
タイトルと説明は変更内容に基づいて日本語で書いて

PRをレビューする側のフロー

# 1. PRの概要を把握する
gh pr view 456 の内容と変更ファイル一覧を教えて
 
# 2. 差分をレビューする
gh pr diff 456 をセキュリティとロジックの観点でレビューして
 
# 3. 気になる点があればコメントを投稿
以下の内容でPR 456にレビューコメントを投稿して:
- src/api/handler.ts:42 入力のサニタイズが不足しています
- src/api/handler.ts:78 エラー時のレスポンスにスタックトレースが含まれる可能性があります

応用テクニック

REVIEW.mdでレビュー基準をカスタマイズする

プロジェクトのルートに REVIEW.md を配置すると、Claude Codeのコードレビューの判断基準をカスタマイズできます。

# レビュー指示
 
## Importantの基準
以下に該当する場合のみImportant(修正必須)とする:
- データの不整合を引き起こすロジックエラー
- セキュリティ脆弱性(SQLインジェクション、XSS、認証バイパス等)
- 本番環境でクラッシュする可能性のあるバグ
 
## レビュー対象外
- フォーマットやスタイルの指摘(CI/リンターに任せる)
- `src/gen/` 以下の自動生成コード
- *.lock ファイル
 
## リポジトリ固有のチェック
- 新しいAPIエンドポイントには統合テストがあること
- ログにメールアドレスやユーザーIDを含めないこと

サブエージェントで多角的にレビューする

1つのレビューで複数の観点をカバーしたい場合、サブエージェントを使って並行レビューを実行できます。

サブエージェントを使って、この差分を以下の3つの観点でそれぞれレビューして:
1. セキュリティ(認証・認可、入力検証、機密情報)
2. パフォーマンス(クエリ効率、メモリ使用量)
3. テスト(カバレッジ、エッジケース)
 
それぞれの観点で見つかった問題を報告して

サブエージェントは独立したコンテキストで動作するため、メインの会話を圧迫せずに深いレビューができます。

gh CLIの便利なコマンド

PRレビューの際に gh CLIで使えるコマンドをいくつか紹介します。

# PRの一覧を取得
gh pr list
 
# PRの差分を表示
gh pr diff 123
 
# PRのレビューコメントを取得
gh api repos/OWNER/REPO/pulls/123/comments
 
# PRにレビューコメントを投稿
gh pr review 123 --comment --body "全体的にLGTMです"
 
# PRのチェックステータスを確認
gh pr checks 123

Claude Codeはこれらのコマンドを直接実行できるので、「PR 123のチェックが通っているか確認して」のように自然言語で依頼するだけで済みます。

定期的なレビュー自動化

チームで未レビューのPRが溜まりがちな場合、Claude Codeのスケジュール機能を使って定期的なレビューを自動化できます。

/schedule を使って、毎朝9時にオープンなPRをレビューするルーチンを作って。
レビュー結果はPRにコメントとして投稿して
自動化の範囲に注意

自動レビューはあくまで補助です。重要な設計判断やビジネスロジックの妥当性は、人間のレビュアーが確認する必要があります。Claude Codeの自動レビューで「明らかなバグ」を事前に潰し、人間のレビュアーがより重要なポイントに集中できるようにするのが理想的な使い方です。

まとめ

  • PRを出す前に /code-review でセルフチェックすると、レビュアーの負荷を減らせる
  • /code-review --fix で指摘事項の修正まで自動化できる
  • レビュー観点(セキュリティ、パフォーマンス、可読性等)を明示すると精度が上がる
  • gh CLIとの連携で、GitHub上のPRレビューもClaude Code内で完結する
  • REVIEW.md でレビュー基準をカスタマイズすれば、プロジェクト固有のルールも反映できる
  • 自動レビューは人間のレビューを置き換えるものではなく、補助として使う