Claude Code のコードレビューには、ローカルで差分を見る /code-review コマンドと、GitHub のプルリクエストを自動でレビューする Code Review の2つがあります。使える条件も課金も違うので、この記事では両方を切り分けたうえで、設定・結果の読み方・REVIEW.md による調整・料金を説明します。
2つのコードレビュー
Claude Code のコードレビューには、性格の違う2つの入口があります。混同しやすいので先に切り分けます。
- ローカルの
/code-reviewコマンド: いま作業しているセッションから、自分の差分をその場でレビューします。GitHub App のインストールは不要で、どのプランでも使えます。 - GitHub PR の自動レビュー（Code Review）: プルリクエストを Anthropic 側のインフラで解析し、問題を見つけた行にインラインコメントとして投稿します。リサーチプレビューで、Team / Enterprise の契約が対象です。Zero Data Retention を有効にしている組織では利用できません。
自前の CI で Claude を動かしたい場合は、この管理サービスではなく GitHub Actions や GitLab CI/CD を使います。セルフホストの GitHub なら GitHub Enterprise Server 向けの手順があります。
ローカルで差分をレビューする
作業中のセッションでコマンドを実行するだけです。
/code-review対象は、現在のブランチが上流より進んでいるコミットと、未コミットの変更です。つまりブランチか作業ツリーに変更が無いと、報告するものがありません。別のものを見たいときは、ファイルパス・PR番号・ブランチ名・main...my-feature のような ref の範囲を引数で渡します。
フラグは2つあります。
--fix: レビューの後、指摘を作業ツリーに適用します。--comment: 指摘を PR のインラインコメントとして投稿します。
レビューは自分のコンテキストウィンドウを持つバックグラウンドのサブエージェントとして走るので、会話が埋まりません。結果は完了時に会話へ届きます。前のレビューがまだ動いているうちにもう一度実行した場合や、-p の非対話モード、CLAUDE_CODE_DISABLE_BACKGROUND_TASKS を 1 にしている場合は、フォアグラウンドで実行されます。
報告の量は効力（effort）で調整できます。low と medium では確信度の高い指摘だけが出るので誤検知が減り、high 以上は網を広く張る代わりに確信の薄いものも混じります。指定しなければセッションの現在の効力が使われます。
注意点として、バックグラウンドのレビューが --fix で入れた編集は、セッションのチェックポイントの外側で行われます。/rewind では戻せないので、取り消したいときは git を使ってください。また、ローカルのレビューはセッションと同じように CLAUDE.md に従いますが、後述の REVIEW.md は読みません。
GitHub PR の自動レビュー
組織の Owner が一度だけ有効化し、対象リポジトリを選びます。GitHub App のインストールでは、Contents・Issues・Pull requests の読み書き権限が要求されます。Code Review 自体が使うのは contents の読み取りと pull requests の書き込みで、広めの権限は後から GitHub Actions を有効にする場合に備えたものです。
セットアップ後、リポジトリごとにレビューを走らせるタイミングを選べます。
| 設定 | いつ走るか |
|---|---|
| Once after PR creation | PR が開かれた、または ready for review になったときに1回 |
| After every push | PR ブランチへの push のたび。直した指摘のスレッドを自動で解決する |
| Manual | PR に @claude review とコメントしたときだけ |
手動のトリガーは、リポジトリの設定に関係なくいつでも使えます。
| コメント | 動作 |
|---|---|
@claude review | 1回だけレビューする。以後の push は購読しない |
@claude review always | レビューし、以後の push でも走るよう購読する |
@claude review once | @claude review と同じ |
ここは 2026年7月の変更で挙動が変わった箇所です。それ以前は @claude review が push を購読していました。従来の動作が欲しい場合は always を付けてください。
コメントを効かせるには、差分の行に対するインラインコメントではなくトップレベルのPRコメントとして投稿し、コマンドを行頭に置き、once や always を同じ行に書く必要があります。リポジトリへの owner / member / collaborator のアクセス権と、PR が open であることも条件です。自動トリガーと違い、手動トリガーは draft の PR でも走ります。
深刻度と結果の読み方
指摘には3段階の深刻度が付きます。Important はマージ前に直すべきバグ、Nit は直す価値はあるがブロックしない軽微な問題、Pre-existing はこの PR が入れたものではないがコードベースに存在するバグです。それぞれに展開できる推論の説明が付き、なぜ指摘したのか・どう検証したのかを読めます。
既定では、Code Review は正しさに的を絞ります。本番を壊すバグを見つけるためのもので、書式の好みやテストの不足は対象外です。
各レビューコメントには、あらかじめ賛成・反対のリアクションが付いた状態で届きます。役に立ったか、外していたかをワンクリックで評価でき、その集計はレビュアーの調整に使われます。リアクションは再レビューを起こしませんし、PR も変えません。インラインコメントに返信しても Claude は応答しません。指摘に対応するには、コードを直して push します。
インラインコメントとは別に、Claude Code Review というチェックランが CI のチェックと並んで作られます。Details を開くと全指摘が深刻度順の表で見られ、Files changed タブでは該当行にアノテーションとして出ます。チェックランは常に neutral で終わるので、ブランチ保護でマージがブロックされることはありません。
指摘の件数でマージを止めたい場合は、チェックランの出力を自分の CI から読みます。Details の最後の行が機械可読なコメントになっているので、gh と jq で取り出せます。
gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
--jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'返ってくるのは {"normal": 2, "nit": 1, "pre_existing": 0} のような深刻度ごとの件数で、normal が Important の数です。ここが 0 でなければ、マージ前に直すべきバグが1件以上あるということになります。
チェックランのタイトルが「問題を見つけた」と言っているのにインラインコメントが見当たらない場合は、チェックランの Details、Files changed のアノテーション、レビュー本文の Additional findings の3か所を見てください。レビュー中に push すると、指摘が現在の差分に存在しない行を指してしまい、インラインで出せなくなることがあります。
REVIEW.md でレビューを調整する
Code Review はリポジトリの2つのファイルを読みます。効き方が違います。
CLAUDE.md: レビューに限らず Claude Code 全体で使われるプロジェクトの指示。Code Review はこれをプロジェクトの文脈として読み、新しく入った違反を Nit として指摘します。ディレクトリ階層のどの階層にあるものも読まれるので、サブディレクトリのCLAUDE.mdのルールはそのパスの下だけに効きます。REVIEW.md: レビュー専用の指示。レビューのパイプラインのすべてのエージェントのシステムプロンプトに、最優先の指示ブロックとして直接差し込まれます。既定のレビュー方針より優先されます。
REVIEW.md はそのまま貼り付けられるため、@ によるインポート構文は展開されず、参照したファイルも読み込まれません。守らせたいルールはファイルの中に直接書いてください。
実際に効きやすいのは次の型です。
- 深刻度の再定義: 既定の目盛りは本番コード向けです。ドキュメントのリポジトリや試作なら Important の定義を狭めるべきですし、逆に
CLAUDE.md違反を Nit ではなく Important に上げることもできます。 - Nit の量の上限: 「Nit は1レビューにつき最大5件、残りは要約で件数だけ触れる」のような上限を置くと、レビューが行動可能な量に収まります。
- 除外ルール: 生成コード、ロックファイル、ベンダーの依存、機械が作ったブランチ、lint や spellcheck のように CI が既に見ているもの。完全に除外するほどではない場所は「
scripts/では、ほぼ確実かつ深刻なときだけ報告する」のように基準を上げます。 - 検証の基準: 「挙動に関する主張には、命名からの推測ではなくソースの
file:lineを引くこと」のように証拠を要求すると、著者の往復を無駄にする誤検知が減ります。 - 再レビュー時の収束: 「初回レビュー以降は新しい Nit を出さず、Important だけ報告する」と書いておくと、1行の修正が体裁の話で7周目に達するのを防げます。
長さには代償があります。長い REVIEW.md は、一番効かせたいルールを薄めます。レビューの挙動を変える指示だけを置き、一般的なプロジェクトの文脈は CLAUDE.md に残してください。
料金と注意点
GitHub PR の Code Review はトークン使用量に応じた課金で、1回あたり平均 15〜25 ドルです。PR の大きさ、コードベースの複雑さ、検証が要る指摘の数で変わります。この費用は使用クレジットとして別建てで請求され、プランに含まれる使用量は消費しません。1回のレビューは平均20分で完了します。
トリガーの選び方がそのまま総額に効きます。push のたびに走らせれば push の回数だけ倍になり、Manual なら誰かがコメントするまで走りません。月間の上限を設けたい場合は、管理設定の使用量のページで Claude Code Review サービスの上限を設定します。上限に達すると、レビューを飛ばした旨のコメントが PR に1件投稿され、次の請求期間の開始時か、管理者が上限を上げた時点で再開します。
レビューの実行はベストエフォートです。失敗してもマージはブロックされませんが、自動で再試行もされません。内部エラーや時間切れで終わった場合は、PR に @claude review とコメントして走らせ直してください。GitHub の Checks タブの Re-run ボタンでは Code Review は再実行されません。