0:00 0:00
記事
Claude Codeをコードレビューに使う方法と人間が見るべきポイント：/review・/security-review・Writer/Reviewerパターン
Claude Codeでコードレビューを効率化する方法を、/review、/security-review、別セッションでのWriter/Reviewerパターン、cloud版/ultrareviewまで整理します。AIレビューが得意な領域・苦手な領域を分け、人間が必ず読むべき5観点（設計判断・セキュリティ・UX・性能・依存追加）を提示します。
結論：Claude Codeのレビューは「機械的な指摘の一次フィルタ」、設計判断は人間がやる
Claude Codeには組み込みの/reviewと/security-reviewがあり、加えて別セッションでのWriter/Reviewerパターンやcloud版/ultrareviewまで揃っています。これらはレビュー速度を大きく上げてくれる一方、**「設計判断」「事業判断」「UX判断」「セキュリティの最終判断」**は今でも人間がやる領域です。
公式Best Practicesも、**「fresh contextを使って書いた本人ではない別Claudeにレビューさせる」**ことを推奨しており、書いたClaudeに自分のコードをレビューさせるバイアスを避ける設計を強調しています。
本記事では、用途別に4つの使い分けと、AIレビューを「機械的な指摘の一次フィルタ」として運用するためのチェックリストを示します。
/review：ローカルセッションでPR差分をレビュー/security-review：脆弱性に絞った差分レビュー- Writer/Reviewerパターン：書いたセッションとは別のセッションでレビュー
/ultrareview：cloud sandboxで複数エージェントが深掘り
PR運用の前段はClaude Codeで安全にコミットとPRを作るワークフロー、レビュー対象になるテスト自体の質はClaude Codeにテストコードを生成させる依頼文と注意点、リファクタ系PRのレビュー観点はClaude Codeで既存コードを壊さずリファクタリングする依頼文に詳しいので、本記事はレビュー側の役割分担にフォーカスします。
1. /review：ローカルでPR差分をざっとレビュー
/reviewは、現在のセッションでPR（または現在の差分）をローカルにレビューするコマンドです。公式コマンドリファレンスでは「Review a pull request locally in your current session」と説明されています。
使い方
claude セッション内で次のように打ちます。
/review 1234引数を省略するとカレントブランチの差分を見ます。番号でPRを指定する場合はgh CLIが使える環境が前提です。
何を見てくれるか
- 明らかなバグや論理ミス
- 命名・構造の一貫性
- テストとの整合
- TODO・コメント残し
何を見てくれないか（人間がやる）
- そのPRが本当に必要かという事業判断
- ユーザー体験・アクセシビリティの最終判断
- 既存アーキテクチャを壊していないかの設計判断
- 将来的な拡張性・メンテ容易性
/reviewは「書き終えた本人がもう一度差分を眺めるためのコ・パイロット」と捉えるのが安全です。レビュー結果を全部修正させる前に、人間が指摘の妥当性を1件ずつ確認してください。
2. /security-review：脆弱性に絞った差分レビュー
/security-reviewは、現在のブランチの差分をセキュリティ観点に絞ってレビューします。injection・認証・データ漏えいなどを見ます。
/security-reviewこのコマンドの強みは、観点が絞られていることです。汎用レビューは指摘がどうしても薄く広くなりますが、/security-reviewは次のような観点に集中します。
- SQLインジェクション・コマンドインジェクション
- XSS、CSRF、クリックジャッキング
- 認証・認可の欠落、トークンの取り扱い
- 秘密情報の混入（APIキー、
.envの追跡） - 入力検証・サニタイズ漏れ
ただし、これも最終判定はしません。たとえば「ここは認証必須では？」と指摘してきた箇所が、実は別レイヤーで認証済みということもあります。**指摘ごとに「該当する／しない／要追加対策」**を人間がラベル付けする運用にしてください。
秘密情報チェックは多重防御で
/security-reviewは便利ですが、これだけに依存しないでください。秘密情報の混入対策は、Claude Codeで安全にコミットとPRを作るワークフローで書いた多重防御が基本です。
CLAUDE.mdの禁止事項に「.envを読まない・書かない・コピーしない」を明記.gitignoreで.env*を除外- gitleaksやtrufflehogなどをCIに組み込む
- 万一コミットされたら鍵をローテート（履歴削除より優先）
3. Writer/Reviewerパターン：別セッションで読ませる
Best Practicesはfresh contextでのレビューを強調しています。同じセッションで書いてもらってからレビューさせると、Claudeは自分の判断を肯定するバイアスがかかります。
別セッションで読ませる手順
書いたセッションは終了するか、別ターミナルで新しいclaudeを立ち上げます。
claude --from-pr 1234 --from-prを使うと、PRの差分・コメント・関連ファイルをfresh contextに読み込ませた状態で起動できます。gh pr checkout済みのブランチでも同様に動きます。
Reviewer向けの依頼文テンプレ
## 役割
あなたは別セッションのReviewerです。書いたClaudeとは独立に判断してください。
## 対象
@PR_DIFF を読み、変更全体を次の観点でレビュー
## 観点（必ず全て見る）
1. 設計: 既存のレイヤー境界・命名規則との整合
2. テスト: 観点（正常系・境界値・異常系）の網羅、トートロジーになっていないか
3. セキュリティ: 入力検証、認可、秘密情報の混入
4. パフォーマンス: N+1、無駄な再レンダー、大きなループ
5. 依存追加: package.json/Cargo.toml の差分があれば、必要性とライセンス
## 出力
- 観点ごとに [Critical / Should / Nit] のラベルでコメント
- Critical = マージブロッカー、Should = 改善要、Nit = 任意
## 禁止事項
- 「LGTM」だけで終わらせない（必ず観点ごとにコメント）
- 推測で危険性を煽らない（再現できない懸念は Nit に下げる）
- このセッションで実装を変更しない（Reviewerは指摘のみ）ポイントは**「Reviewerは実装を変更しない」**を禁止事項に書くことです。書く権限を渡すと、Reviewerが勝手に直してしまい、レビューと修正が同セッションで混ざります。
Writer/Reviewerループは2往復まで
Reviewerの指摘をWriterセッションに渡し、修正させます。ただし2往復で打ち切るのがコツです。3往復目になると、両セッションがお互いの判断を肯定しあって膠着します。3往復目が必要そうなら、いったん人間が読み、設計上の決定を1つだけ下してから再開してください。
4. /ultrareview：cloud sandboxの深掘りレビュー
/ultrareviewは、cloud sandbox内で複数エージェントによる深掘りレビューを実行します。公式コマンドリファレンスでは「Run a deep, multi-agent code review in a cloud sandbox」と説明されており、Pro・Maxプランで2026年5月5日まで無料3回付き、その後は追加利用枠の対象になります。
ローカル/reviewとの違いは次のとおりです。
| 項目 | /review（ローカル） | /ultrareview（cloud） |
|---|---|---|
| 実行場所 | 現在のセッション | クラウドsandbox |
| エージェント数 | 1 | 複数（並列） |
| 深さ | 速いが浅め | 深いが時間がかかる |
| コスト | 無料（通常使用枠） | プランの追加利用枠を消費する場合あり |
| 使いどころ | 日常PR | リリース前PR・大きな設計変更 |
/ultrareviewは呼ばれた時点で課金枠を消費しうるため、AIに勝手に走らせる仕組みは作らないほうが安全です。人間がトリガーする運用にとどめます。
AIレビューが得意なこと／苦手なこと
レビュー対象を仕分けることで、人間の負荷が下がります。
| 観点 | AIが得意 | 人間が必ずやる |
|---|---|---|
| タイポ・命名揺れ | ◎ | △ |
| 既存パターンとの不整合 | ○（CLAUDE.mdがあれば） | ○ |
| 単純なバグ・null安全 | ◎ | △ |
| エッジケース・境界値 | ○（観点を渡せば） | ○ |
| 既知の脆弱性パターン | ○ | ○ |
| アーキテクチャ判断 | ✕ | ◎ |
| 事業要件との整合 | ✕ | ◎ |
| UX・アクセシビリティの最終判断 | △ | ◎ |
| 新規依存の妥当性（ライセンス・運用負荷） | △ | ◎ |
| 長期的な保守性 | △ | ◎ |
下半分の「人間が必ずやる」5観点は、AIがそれらしい意見を返してくれてしまうので、レビュー結果を機械的にコピペする運用は避けてください。
人間が必ず読むべき5観点チェックリスト
PRをマージする前に、人間がgit diffを読みながら次を確認します。
- 設計判断：このレイヤーで持つべき責務か。既存のドメイン境界を越えていないか
- セキュリティ最終判断：
/security-reviewの指摘ごとに「該当する／しない／追加対策」を判定したか - UX判断：エラー文言、空状態、ローディング、アクセシビリティ（コントラスト・キーボード操作）を確認したか
- 性能判断：本番データ量で実行したらどれくらいか（N+1、大きなループ、巨大JSONのパース）
- 依存追加：
package.json等に新しい依存が増えていないか。あればライセンス・更新頻度・代替候補を確認したか
サブエージェントに似た観点を渡して並列レビューさせるパターンは、Claude Codeのサブエージェントとは？使いどころと注意点で扱った設計と相性が良いです。
レビュー結果を反映する手順
AIレビューの結果を全部受け入れない・全部捨てない、の中間が理想です。
- 3分類する：Critical（必ず直す）／Should（直す方がよい）／Nit（任意）
- Criticalだけまずまとめて修正依頼：
- 1つのコミット = 1つの観点に分ける
- レビュー指摘の引用を依頼文に含める
- Shouldは別コミット・別PRにしてもよい：マージブロッカーにしない
- Nitは記録だけ残す：
NOTES.mdやdocs/tech-debt.mdに追記し、後日まとめて対応
修正依頼の例：
## 目的
@PR_REVIEW.md の Critical セクションの指摘を順に直す。
## やること
1. 指摘1: <引用> → 修正方針を1行で書いてから直す
2. 指摘2: <引用> → 修正方針を1行で書いてから直す
3. 各指摘ごとにコミットを分ける（1コミット = 1意図）
## 禁止事項
- ShouldとNitには触らない（別タスク）
- 指摘範囲外のリファクタを足さない
- テストの期待値を変えない
## 完了条件
- `npm test` 全体 Green
- `git log --oneline` で指摘ごとに別コミットになっているやってはいけないアンチパターン
- AIレビュー結果を全件Approve：マージブロッカーが指摘の中に紛れる
- AIレビュー結果を全件却下：価値ある指摘まで捨てる
- 書いたセッションでレビューさせる：自己肯定バイアスが入る。fresh sessionで読ませる
/security-reviewだけでセキュリティ完了とみなす：CI（gitleaks等）と二重化する/ultrareviewを毎PRで走らせる：枠を消費する。リリース前や大きな設計変更時に絞る- AIにApprove権限を渡す：マージ判断は必ず人間
依頼前の30秒チェックリスト
- レビューは書いたセッションとは別で立ち上げたか（または
--from-prでfresh contextを作ったか） - レビュー観点を5つ全部渡したか（設計／テスト／セキュリティ／性能／依存）
- Critical / Should / Nitでラベル付けする指示を入れたか
- Reviewerに「実装変更禁止」を渡したか
- **
/security-review**を別途走らせる予定があるか（脆弱性は専用観点で見る）
ここまで揃えれば、Claude Codeのレビューは「人間が読む前のノイズを減らすフィルタ」として機能します。逆に、これらが抜けると、「LGTM」が並ぶだけで何も保証されないレビューが増えます。レビューの目的は、AIに承認をもらうことではなく、人間がリリース判断を下すための材料を増やすことだ、という出発点を毎回確認してください。
次に読む
- Claude Codeで安全にコミットとPRを作るワークフロー — レビュー前段のPR運用と秘密情報チェック
- Claude Codeにテストコードを生成させる依頼文と注意点 — レビュー対象となるテスト自体の質
- Claude Codeで既存コードを壊さずリファクタリングする依頼文 — リファクタPRに特化したレビュー観点
