ほとんどの開発者は Claude Code をコードを書くために使います。体系的にコードをレビューするために使っている人は少ない — そして使っている人たちは、レビュー専用ツールよりも良い結果を得る傾向があります。なぜなら、チームの基準に正確に合わせてレビュー動作を設定できるからです。
Claude Code を構造化されたコードレビュアーにする実践ワークフローを解説します。
アドホックなレビュー依頼のコア問題
「このコードをレビューして」と Claude Code に会話で頼むと、毎回一貫性のない出力になります。深さも、フォーカスも、構造も毎回異なります。今日は SQL インジェクションを捕捉して、明日は見逃すかもしれない。カジュアルなレビューには良いですが、信頼できる品質ゲートを構築するには使えません。
解決策はレビューモードを決定論的にすることです: Claude Code が何をチェックするか、どの順序で、どの形式で、を正確に定義します。
レビュースキルのセットアップ
.claude/skills/review.md を作成します。
# コードレビュー
呼び出されたら、提供または説明された変更の体系的なコードレビューを実施する。
## レビューチェックリスト
各カテゴリを順番に確認する。「問題なさそう」というだけでカテゴリをスキップしない — 明示的にチェックする。
### 1. セキュリティ
- 入力バリデーション: すべてのユーザー提供データは使用前にバリデーションされているか？
- SQL/NoSQL インジェクション: クエリはパラメータ化されているか、ORM を適切に使用しているか？
- 認証: 新しいエンドポイントは認証が必要か？強制されているか？
- 認可: コードは認証済みユーザーが特定のリソースへの権限を持つかをチェックしているか？
- シークレット: 認証情報・APIキー・トークンがハードコードされていないか？
- CORS: 新しい CORS ヘッダーが導入されているか？適切か？
### 2. データ整合性
- Null/undefined: null になりうる値はアクセス前に処理されているか？
- 型強制: 予期しない値を生成する可能性のある暗黙の変換はないか？
- 境界条件: 空配列・ゼロ・負の数・最大整数で何が起きるか？
- 並行アクセス: 2つのリクエストが競合すると状態が破損しうるか？
### 3. パフォーマンス
- N+1 クエリ: ループ内にデータベースクエリが含まれていないか？
- インデックス不足: 新しい WHERE 句はインデックスでカバーされているか？
- 無制限操作: 任意の量のデータを返すループやクエリがないか？
- キャッシュ: この結果はキャッシュすべきか？既存のキャッシュは正しく無効化されているか？
### 4. エラーハンドリング
- すべての失敗パスが処理されているか？予期せずスローすることはないか？
- エラーはデバッグに十分なコンテキストとともにログされているか？
- ユーザー向けのエラーメッセージは安全か（スタックトレースなし・内部パスなし）？
### 5. コード品質
- 単一責任: 各関数は1つのことをしているか？
- 命名: 変数と関数は何をするかを説明しているか？
- 重複: このロジックは他に重複しているか？
- デッドコード: 未使用のコードパスを導入していないか？
### 6. テスト
- 新しい動作はテストでカバーされているか？
- エッジケースはテストされているか（空・null・境界値）？
- テストは動作をテストしているか、実装をテストしているか？
## 出力フォーマット
レビューを以下の構造にする:
**Critical**（マージ前に必ず修正）:
- [可能な場合はファイル:行番号参照付きの具体的な問題]
**Warning**（修正すべき、オーナーの判断でマージ可）:
- [具体的な問題]
**Suggestion**（任意の改善点）:
- [具体的な改善点]
**Looks Good**:
- [うまくできていた点を1行で]
カテゴリに問題がない場合は「問題なし」と記載する — サイレントにカテゴリをスキップしない。コードの変更を見るときに /review で呼び出します。
PR レビューワークフロー
完全なプルリクエストをレビューする場合:
# 差分を取得
git diff main...HEAD
# Claude Code に渡す
claude "$(git diff main...HEAD)" /reviewまたは Claude Code に PR の詳細を自分で取得させる場合:
# gh CLI を使用
claude "PR #123 をレビューして。差分はこちら: $(gh pr diff 123)" /review大きな PR の場合はファイルごとに分割します。
# 変更されたファイルを1つずつレビュー
for file in $(git diff main...HEAD --name-only); do
echo "=== $file ===" && git diff main...HEAD -- "$file"
done | claude - /reviewCLAUDE.md でのレビューモード設定
Roo Code を使っている場合は専用のレビューモードを作成できます。Claude Code の場合は CLAUDE.md のセクションでレビュー動作を区別できます。
## コードレビューモード
コードを書くのではなくレビューするよう依頼された場合、以下の制約に従う:
- 明示的に求められない限り、代替コードを書かない。問題を特定して説明する。
- 修正を提案する場合は「提案された修正:」というプレフィックスのコードブロックで示す — レビュー内にインラインで書かない。
- 具体的に: 「認証ロジックのどこか」ではなく「47行目」と書く。
- セキュリティの脆弱性・データ損失・本番でのシステム停止を引き起こしうる場合のみ Critical とマークする。
- 出力フォーマット: Critical / Warning / Suggestion / Looks Good のセクション形式。これは実際に差を生みます。これがないと Claude Code はレビューの途中で関数全体を書き直す傾向があり、実際の発見が見えにくくなります。
セキュリティフォーカスのレビュープロンプト
セキュリティ特化のレビューには、一般的なレビューではなく的を絞ったプロンプトを使います。
以下のコードのセキュリティのみのレビューを実施してください。以下のみに集中:
- インジェクション脆弱性（SQL・コマンド・LDAP・XPath）
- 認証・認可のギャップ
- 安全でないデシリアライゼーション
- センシティブデータの露出
- レートリミットや資源枯渇ベクターの欠如
- 依存関係の脆弱性（既知の CVE を持つライブラリインポートにフラグを立てる）
コード品質・命名・パフォーマンスにはコメントしない。セキュリティクリティカルなコードパスでは、複合レビューよりもこちらが効果的です — セキュリティの発見がスタイルコメントに埋もれません。
CLAUDE.md 自体をレビューする
あまり使われていないパターン: Claude Code を使って自分のルールファイルをレビューする。
CLAUDE.md を以下の観点でレビューしてください:
1. 矛盾: 互いに衝突するルール
2. 曖昧さ: 複数の解釈ができるルール
3. カバレッジ不足: 対処されていない明白なシナリオ
4. トークン効率: 意味を失わずに簡潔に記述できるルール
5. 実施可能性: Claude Code が実際に従えないルール（持っていない知識が必要なもの）四半期ごとにこれを実行してください。ルールファイルはゴミを蓄積し、内部矛盾を生み、もはや存在しないプロジェクトバージョンのために意味があったルールを抱え込みます。
自動レビューフック
Claude Code のフックシステムにレビューを接続してコミット時に自動実行できます。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Bash(git commit *)",
"hooks": [
{
"type": "command",
"command": "echo 'コミット前にステージされた変更に対して /review を実行してください'"
}
]
}
]
}
}これはリマインダーフックであり、ブロッキングフックではありません。ブロッキングレビューフック（コミットをブロックする終了コード2）は可能ですが、慎重なスコーピングが必要です — Claude Code が考えている間、すべてのコミットをブロックしてほしくはありません。
CI では、claude /review --output=github を呼び出してPRコメントとして出力を投稿する GitHub Actions ステップの方が良いパターンです。レビューが PR スレッドにあると可視化されてアクションを取りやすくなります。
Claude Code によるレビュー文化の構築
目標は人間のレビューを置き換えることではありません。Claude Code は人間とは異なるものを捕捉します — メカニカルなチェック（null安全、入力バリデーション、欠落したエラーハンドリング）には人間より一貫性があり、システム的な判断（これはシステム全体に対して正しい抽象化か？）には信頼性が低い。
Claude Code レビューを使う場面:
- セキュリティとデータ整合性のチェック
- 人間のレビューを依頼する前の最初のパスレビュー
- PR を開く前の自分のコードのチェック
- チームの知識が限られているドメインのコードのレビュー
人間のレビューのために残す場面:
- アーキテクチャ上の決定
- 抽象化がシステム全体に合っているかの評価
- コードベース全体を知ることが必要な横断的な懸念
- レビュアーがコードに含まれていないビジネスコンテキストを必要とするもの
Claude Code がメカニカルを担当し、人間が判断を担当する組み合わせ — これが両者単独よりも良い成果をもたらします。