Claude Codeのコードレビュー｜変更範囲を決めて指摘を確かめ、採否を決める

Claude Codeのコードレビューは、作業中のセッションで/code-reviewを実行して受けます。対象を指定しなければ、今のブランチの変更を調べ、コードの誤りを会話の中に報告します。プランを問わず使えます。

ただし、指摘が出ただけでは作業は終わりません。この記事では、レビューする範囲を決め、指摘を自分の手元で再現し、採用するかを決めて、修正の後にもう一度確かめるまでの流れを説明します。GitHubのプルリクエスト（PR）を受ける時の選び方も、途中で整理します。

この記事は、2026年11月3日に確認したAnthropicの公式資料をもとに、編集部が手順をまとめたものです。再現と採否の手順、記録表、在庫計算の話は、編集部の提案と説明用の架空の例です。公式の手順ではなく、編集部が/code-reviewを実行して実測した結果や、実案件で検証した結果でもありません。

コードレビューは/code-reviewで始める

手順は短く、Claude Codeの入力欄で次のコマンドを実行するだけです。/reviewは同じコマンドの別名です。v2.1.223より前の/reviewは別のコマンドだったので、古い手順書を読む時は版を確かめます。

/code-review

公式資料（英語）によると、レビューは自分の文脈を持つサブエージェント（裏で動く別のClaude）が担当します。会話を埋めないので、その間も作業を続けられて、終わると指摘が会話に届きます。利用量は、セッションの他の作業と同じようにプランの枠やAPIの料金へ計上されます。

調べる中心は、コードの正しさに関する誤りです。モデルと労力の設定によっては、重複や単純化、効率の改善点も含まれます。公式のベストプラクティス（英語）は、書いた時の会話を見ていない別のサブエージェントが見るので、コードを書いた時の理由に引っ張られにくいと説明しています。

コードレビューの範囲を先に固定する

最初に決めるのは、どの変更を見てもらうかです。範囲があいまいだと、指摘が今回の変更によるものなのか判断できません。対象は、コマンドの後ろに書きます。

何も指定しないと、上流のブランチより先に進んでいるコミットと、未コミットの変更が対象です。上流がないブランチでは、mainか直前のコミットと比べます。つまり、ブランチの状態によって範囲が変わります。そこで編集部は、次の順で範囲を固定することを勧めます。

1. git statusで、関係のない未コミットの変更が混ざっていないかを確かめます。
2. 見てほしい変更をコミットします。
3. /code-review main...my-featureのように範囲を明示して実行し、その入力を記録に残します。

範囲を書き残しておくと、修正の後に同じ範囲でやり直せます。比較も正確になります。

コードレビューの指摘を再現して確かめる

届いた指摘は、自分の手元で確かめるまでは仮説として扱うことを勧めます。公式資料のultrareviewの比較は、報告される指摘の独立した再現と検証をultrareview側の特徴として挙げています。手元の/code-reviewの深さは労力（effort）の設定で変わり、lowなら誤検知が減ると説明されています。どちらにしても、公式資料が示しているのはレビューの仕組みであり、自分の案件で指摘が正しいかは別に確かめる必要があります。

公式のベストプラクティスにも、問題を探すよう頼まれたレビュー担当は必ず何かを見つけるものであり、すべて直すと余計な抽象化や起こり得ない場合のテストが増える、という注意があります。そこで編集部は、指摘ごとに記録を残してから判断する方法を提案します。

指摘ごとに、次の項目を書いて判断します。次の表の右端は、説明のために作った架空の例です。

再現はClaudeに手伝ってもらえます。修正と分けて頼むのが要点です。先に直してしまうと、指摘が正しかったのかを確かめられなくなります。次の依頼文は編集部の例です。

src/stock/reserve.ts:42 の指摘について、コードはまだ直さずに、
再現するテストだけ書いて実行してください。
失敗すれば再現、通れば再現しなかったと報告してください。

同時に動く処理のように、テストが通っても再現しなかったと言い切れない指摘は、判定を保留にして条件を整理します。画面を動かさないと分からない変更には、/verifyも使えます。アプリをビルドして実行し、結果を観察するコマンドです。

コードレビューの指摘を採用するか決める

再現の結果と影響の大きさで、扱いを決めます。次の基準は編集部の提案です。チームの決まりがあれば、そちらを優先してください。

同じ種類の的外れな指摘が続く時は、プロジェクトの決まりをCLAUDE.mdに書きます。/code-reviewはCLAUDE.mdに従います。REVIEW.mdは読みません。こちらは、次に説明するGitHub向けのサービスの設定です。

修正の後にコードレビューをやり直す

採用した指摘だけを直す時は、どの指摘を直すかを挙げてClaudeに頼みます。--fixは、レビューの後で指摘を作業ツリーへ反映するよう頼むフラグです。選ばずに反映してかまわない時だけ使うのがよいでしょう。編集は、どちらの場合も権限モードの確認を通ります。

/code-review --fix main...my-feature

--fixを使う時は、先に変更をコミットしておくと戻しやすくなります。公式資料によると、裏で動くレビューの編集はセッションのチェックポイントの外にあります。/rewindで戻るのは、その会話でClaudeが既に編集していたファイルだけで、ほかのファイルへの編集はgitで戻します。一方、環境変数CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1を設定した場合などレビューが前面で動く時は、自分のターンの編集なので、通常どおり/rewindで戻せます。

修正が終わったら、次の順で確かめます。

1. 再現に使ったテストを実行し、失敗から成功へ変わったことを確かめます。
2. 関係するテスト全体を実行し、他を壊していないことを確かめます。
3. 修正をコミットしてから、記録した範囲で/code-reviewをもう一度実行し、修正で増えた問題がないかを見ます。公式資料が未コミットの変更を含むと書いているのは、対象を省いた/code-reviewです。コミットせずに見たい時は対象を省けますが、見る範囲が変わる点に注意します。
4. 記録表の判定と結果を更新します。

テストで確かめられない変更には、/verifyを使えます。テストと/verifyはどちらも動きを見る手段で、再度のレビューは修正で増えた問題を探す手段です。役割が違うので、片方で済ませないようにします。Desktopアプリのように指摘の一覧を表示する環境では、報告し直した指摘にfixed、skipped、no change neededの印が付きます。

PRのコードレビューを受ける方法を選ぶ

PRを見てもらいたい時は、まず手元で/code-review 1234のように番号を指定します。--commentを付けると、GitHubのPRに行ごとのコメントとして、GitLabのマージリクエストにはまとめのノートとして投稿します。投稿の前に指摘の内容を見たい時は、付けずに実行します。

チーム全体で常に回す時は、別の手段があります。公式の比較（英語）をもとにまとめると、次のとおりです。

Code Reviewは、PRを承認せず、マージも止めません。指摘は重要度つきの行コメントで届き、チェックの結果も失敗にはならないので、マージの判断はチームに残ります。ただし、ブランチ保護で会話の解決を必須にしているリポジトリでは、未解決の指摘への対応が要ります。公式資料は、指摘がないことはコードに誤りや脆弱性がないという意味ではないとも明記しています。この注意は手元のレビューでも同じように受け止めるとよいでしょう。

採否の記録の残し方も変わります。Code Reviewの指摘を修正せずに消すには、GitHubでスレッドを解決します。返信だけでは消えず、返信は次のレビューで読まれます。料金は費用の公式資料（英語）で確かめてください。

ultrareview（英語）はクラウドで動く深いレビューで、research preview（試験提供）です。無料枠と料金は変わる可能性があるので、実行前の確認画面と公式資料で確かめてください。

コードレビューの指摘が多すぎる時の調整

指摘が多くて再現が追いつかない時は、労力の設定を下げます。lowは確信の高い指摘に絞るので、記録を取る手間も減ります。指定を省くと前回入力した設定を再利用するので、結果の量が変わった時は表示される通知で今の設定を確かめます。lowと入力すると、以後のレビューの既定として記憶される点にも注意します。引数の全体は公式資料（英語）にあります。

/code-review low main...my-feature

一般的なバグではなく計画との違いを見てほしい時は、公式資料にある次の形で頼む方法もあります。skip styleを外さないよう、公式資料も注意しています。

use a subagent to review the rate limiter diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style

コードレビューが思った通りに動かない時

まとめ：コードレビューは範囲、再現、採否の順に進める

Claude Codeのコードレビューは、範囲を明示して/code-reviewを実行し、指摘を再現してから、採用するものだけを直します。修正の後は同じ範囲でもう一度確かめ、判断の理由を残します。よく使うコマンドはスラッシュコマンドの記事に、Claude Code全体の使い方はClaude Codeとはの記事にまとめています。

AIのレビューをチームの開発に組み込む時は、誰が採否を決め、どこに記録するかを先に決めておくと、指摘が放置されにくくなります。業務に合わせた運用づくりは、PLaiのAI社員導入支援でも相談できます。