Claude Codeでコードレビューを自動化する使い方と注意点
Claude Codeのコードレビューを自動化したいけれど、`/code-review` が「何をどこまで見てくれているのか」がよくわからない。そんな方向けに、対象の指定、effortレベルの選び方、着目点の伝え方、`–fix` 前の注意点を公式ドキュメントをもとに整理しました。
【連載⑦】レビューをClaudeに依頼する方法では「PR運用フローの中のレビュー」を書きました。今回は`/code-review` 単体の使いこなしに絞っています。
※本記事の仕様は、公式ドキュメント（code.claude.com/docs/en/code-review）を2026年9月27日に確認した内容です。バージョンによって挙動が違う可能性があります。
結論：Claude Codeのコードレビュー自動化は「対象」と「effort」を決めるのが先
`/code-review` をうまく使うコツは、次の2つを先に決めることです。
1. 何をレビューさせるか（対象）
2. どこまで疑ってもらうか（effortレベル）
これを決めずに打つと、「思っていた範囲と違う」「指摘が多すぎる・少なすぎる」といったズレが起きやすくなります。
なお、ここでいう「自動化」は半自動です。指摘を採用するか、マージしてよいかを判断するのは人間です。
/code-reviewでできること（2026年9月時点）
公式ドキュメントによると、`/code-review` はdiff（変更差分）を対象に、次の2種類の指摘を出すコマンドです。
- 正確性のバグ（動作がおかしくなる箇所）
- 再利用・簡略化・効率化の観点でのクリーンアップ提案
`/review` は `/code-review` の別名（エイリアス）として扱われています。
レビュー対象の指定方法
何も指定しないと、基本的には現在のブランチでアップストリーム（リモート側の追跡ブランチ）より先に進んでいるコミットと、まだコミットしていない変更がレビュー対象になります。未設定時は別の比較範囲が使われる場合があります。変更がなければ指摘も出ません。
別のものをレビューしたい場合は、対象を後ろに書きます。
/code-review src/utils.js
/code-review 123
/code-review feature-login
/code-review main...feature-login
/code-review high main...feature-login
上から順に「ファイルパス」「PR番号」「ブランチ名」「範囲指定（mainから分かれたあとにfeature-login側で加えた変更）」、最後がeffortと対象を組み合わせた例です。名前はご自身の環境に合わせて読み替えてください。
基本はバックグラウンドで動く
レビューは通常、バックグラウンドのサブエージェントとして実行されるため、会話の文脈を圧迫しにくくなっています。レビュー中も別の作業を続けられ、終わると結果が会話に届きます（実行環境によっては会話内で動く場合もあります）。
effortレベルの選び方
`/code-review high` のようにeffortレベルを付けられます。公式ドキュメントの説明を要約すると、次のような違いです。
| レベル | 特徴 | 向いている場面（私の考え） |
|---|---|---|
| low / medium | 自信のある指摘だけを報告。誤検知が少ない | 小さな修正、まず全体感をつかみたいとき |
| high / xhigh / max | 網羅性が上がる。確信度の低い指摘も混ざる | 大事な変更、マージ前の最終確認 |
これとは別に `ultra` があります。こちらはeffortの延長ではなく、コードをクラウドに送って複数エージェントで深くレビューする別系統の機能です。
地味に大事なのが、レベルを省略すると「前回打ったレベル」が再利用される点です。以前 `max` で打っていたら、次に何も付けずに打っても `max` 相当で走ります。「今日はやけに指摘が多いな」と思ったら、前回のレベルが残っていないか確認してみてください。
`ultra` はclaude.aiアカウントでの認証が必要で、状況によっては追加の利用枠（有料）を使う確認が出ます。リポジトリの内容がクラウドに送られるので、仕事のコードでは社内ルールを先に確認してください。私はまだ `ultra` を試せていません。
何に着目してもらうかを伝えるコツ
`/code-review` はプロジェクトの `CLAUDE.md` に従って動くので、命名規則などのルールを CLAUDE.md に書いておくと、それを踏まえたレビューになりやすいです。
一方、GitHub上の管理型「Code Review」で使う `REVIEW.md` は、ローカルの `/code-review` では読まれません。混同しやすいポイントです。
その回だけ重点的に見てほしい観点は、次のようにコマンド名と一緒にチャット欄で自然文で添えるのが伝えやすい方法です。
読者がそのまま使えるプロンプト例
Claude Codeのチャット欄に貼って使ってください。ブランチ名や観点はご自身の内容に書き換えます。
組み込みの /code-review を、effortは high、対象は main...feature-login で起動し、次の条件でコードレビューしてください。
目的: マージ前に、バグと読みにくい箇所を洗い出したいです。
対象範囲: main...feature-login の差分のみ。それ以外のファイルは対象外です。
重点的に見てほしい観点:
- 入力が空・想定外の値のときに落ちないか
- 同じ処理が複数箇所に重複していないか
- CLAUDE.md に書いた命名ルールから外れていないか
出力形式:
- 可能であれば「バグ」「改善提案」「参考意見」に分けて、重要度の高い順に並べてください
- 各指摘にファイル名と行番号を付けてください
実行前確認:
- 今回はレビューのみです。ファイルの編集・上書き・削除、commit、push、reset、ブランチ切り替え、依存関係や設定の変更、PRへのコメント投稿など外部への送信は行わないでください
- 修正は別の依頼で行います。その際は対象ファイル一覧、差分、影響範囲、戻し方を先に表示し、私が確認してから実行してください
不明点は推測せず、確認事項として列挙してください。
ポイントは「参考意見」という分類を用意することです。すぐ直すべきバグと分けておくと、どれから直すか判断しやすくなります。
–fix と –comment を使う前に知っておきたいこと
影響が大きいフラグが2つあります。
- `–fix`：レビューで見つかった指摘を作業ツリーに適用する
- `–comment`：指摘をGitHubのPRにインラインコメントとして投稿する（GitLabでは一般コメントとして投稿。ここではGitHubの場合で説明します）
特に `–fix` は注意が必要です。公式ドキュメントによると、バックグラウンドのレビューによる `–fix` の編集はチェックポイントの外で行われるため、`/rewind` では戻せず、gitで戻す必要があります。
そこで `–fix` を使うときは、次の手順をおすすめします。
1. `git status` で未コミットの変更がないことを確認する（変更を消すのではなく、必要なら先にコミットしておく）
2. `–fix` 実行後に `git status` と `git diff` で、変わったファイルと中身を必ず確認する（新しく作られたファイルがないかも見る）
3. 納得できない変更があれば、自分で強い取り消しコマンドを打たず、Claude Codeに「どのファイルをどう戻すか一覧と差分を見せて、私が確認してから戻して」と頼む
`–comment` はPRに書き込むため、他のメンバーの目にも触れます。まずはフラグなしで結果を確認してから使うのが安心です。
正直に書くと、私はまだ `–fix` を試せていません。まずはレビューのみで指摘の質に慣れてから使ってみる予定です。
「定期的な自動レビュー」はできるのか
公式ドキュメントでは、スケジュールタスクのプロンプトに `/code-review` を指定して定期実行できると書かれています（ただし `ultra` はスケジュールからは起動されません）。スケジュールタスクの基本はClaude Codeのスケジュールタスクの記事にまとめています。
また、Team・Enterpriseプラン向けには、PRを開くたびにGitHub上で自動レビューする管理型の「Code Review」（リサーチプレビュー）もあります。こちらは通常のプラン利用枠とは別の課金で、公式ドキュメントでは1回あたり平均15〜25ドル程度とされています（2026年9月27日確認）。個人ならローカルの `/code-review` から始めるのが現実的です。
まだわからないこと
effortレベルごとに指摘の数や質がどれくらい変わるのか、「AIが書いたコードを同じAIがレビューする」ことで盲点が残らないかは、まだ比較・検証できていません。試せたら追記します。
まとめ
- Claude Codeのコードレビュー自動化は、「対象」と「effortレベル」を先に決めるのがコツ
- 対象はファイルパス・PR番号・ブランチ名・範囲指定で変えられる
- effortを省略すると前回のレベルが再利用されるので注意
- 着目点は `CLAUDE.md` とチャットでの自然文の依頼で伝える（`REVIEW.md` はローカルでは読まれない）
- `–fix` の編集は `/rewind` で戻せないため、gitで戻せる状態にしてから使う
PRの流れの中でレビューをどう位置づけるかは、【連載⑦】レビューをClaudeに依頼する方法もあわせて読んでみてください。
