コード差分を表す抽象的なグラフ。緑と赤のバーが並び、虫眼鏡のシルエットが重なる構図

Article

Claude Codeをコードレビューに使う方法と人間が見るべきポイント：/review・/security-review・Writer/Reviewerパターン

Claude Codeでコードレビューを効率化する方法を、/review、/security-review、別セッションでのWriter/Reviewerパターン、cloud版/ultrareviewまで整理します。AIレビューが得意な領域・苦手な領域を分け、人間が必ず読むべき5観点（設計判断・セキュリティ・UX・性能・依存追加）を提示します。

This article is not published in this language yet, so the Japanese version is shown instead.

結論：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に承認をもらうことではなく、人間がリリース判断を下すための材料を増やすことだ、という出発点を毎回確認してください。