無料相談する

カテゴリー / 使い方の基本

Claude Codeのコードレビュー｜/code-reviewの使い方と3つの方法

NO WAVE公開 更新 読了目安 13分

この記事の目次

Claude Codeのコードレビューは、どのプランでもセッション内で /code-review と打てば始められます。レビュー対象を指定しなければ、今いるブランチの変更と未コミットの変更が対象です。大きな変更をより深く見たいときはクラウドで動く /code-review ultra（ultrareview）、GitHubのプルリクエストを毎回自動でレビューさせたい組織にはTeam / Enterprise向けの管理サービス「Code Review」があります。作業中は /code-review、大きな変更のマージ前だけultrareviewを足すのが、公式ドキュメントの使い分けに沿ったレビュー方法です。以下は2026年10月19日に照合した code.claude.com の公式ドキュメントにもとづきます。

Claude Codeのコードレビューは3つのうちどれを使えばいいのか？

公式の比較（Code Reviewの概要）を、判断に必要な列に絞ると次のとおりです。

手段 始め方 動く場所 使える人 費用の扱い
/code-review 自分でコマンドを打つ 自分のセッション どのプランでも 通常のプラン使用量またはAPI課金
ultrareview /code-review ultra と打つ クラウドのサンドボックス claude.aiアカウントでのログインが必要 Pro / Maxは無料3回、その後はusage credits
Code Review PRの作成・push、または @claude review Anthropicのインフラ Team / EnterpriseでOwnerが有効化した組織 usage creditsでトークン課金

公式の比較表では、/code-review の所要時間は数秒から数分、ultrareviewは通常15〜25分です。ultrareviewは指摘を1件ずつ独立に再現・検証するため、スタイルの提案より実際のバグに絞られます。公式は /code-review を作業中の素早いフィードバックに、ultrareviewを大きな変更のマージ前に使うよう案内しています。

ほかに、GitHub ActionsやGitLab CI/CDで自前のCIに組み込む方法と、サブエージェントやスキルで自作のレビュアーを作る方法もあります。CIはGitHub Actions連携ガイドとGitLab CI/CD連携ガイド、自作はサブエージェントの使い方で扱っています。プラン別の費用は料金プラン解説にまとめています。

/code-reviewはどう使うのか？

/code-review は、作業中のセッションのプロンプトに打つコマンドです。Claudeはブランチの変更から正しさに関わるバグを探し、実行結果を会話に返します（公式: /code-review）。モデルとeffortによっては、再利用・簡素化・効率化の提案も含まれます。

/code-review

レビューは独自のコンテキストを持つバックグラウンドのサブエージェントで動くので、会話の文脈を圧迫せず、待つ間も作業を続けられます。指摘が届いたら、直してほしいものをClaudeに頼みます。なお /review は /code-review の別名です。v2.1.223より前の /review はPRを読み取り専用で見る別のコマンドだったので、古い解説とは挙動が違います。

対象は引数で指定する

対象を書かなければ、upstreamより先のコミットと未コミットの変更が対象です。upstreamが無ければ main か直前のコミットと比べます。

レビューしたいもの 入力
直近15コミット /code-review HEAD~15..HEAD
ブランチ同士の差 /code-review main...my-feature
1つのコミット /code-review abc1234^..abc1234
番号で指定したPR /code-review 1234
ファイルやディレクトリ /code-review src/auth

よく使うオプション

  • --fix: レビュー後に指摘を作業ツリーへ反映させます。編集はパーミッションモードを通ります
  • --comment: 指摘をGitHubのPRにはインラインコメント、GitLabのマージリクエストには1件のノートとして投稿します
  • --max-findings <n>: 報告件数の上限を変えます（all で全件）。指摘一覧ツール経由の通常上限は32件で、v2.1.288以降が必要です

バックグラウンドで動く --fix の編集はセッションのチェックポイントの外で行われるため、/rewind で戻らないファイルが残ります。その分はgitで戻します。手順はgit運用ガイド、モードの違いはパーミッションモードの解説を参照してください。

effortで誤検知と網羅性を調整する

/code-review high のようにeffortを渡せます。low は確信度の高い指摘だけを返すので誤検知が少なく、medium から max は見る範囲を広げます。レベルを書かなければ前回打ったレベルを再利用し、一度も打っていなければセッションの現在のeffortを使います。指摘が多すぎるなら low、取りこぼしが気になるなら高いレベルに切り替えます。

レビュー基準は自分のプロジェクトに合わせられるのか？

合わせられます。ただし /code-review と管理サービスのCode Reviewでは読むファイルが違い、ここを取り違えると「書いたルールが効かない」状態になります（公式: レビューのカスタマイズ）。

ファイル /code-review Code Review（管理サービス）
CLAUDE.md 読む（-p の非対話実行でも） 読む。違反した変更は指摘になる
REVIEW.md 読まない 読む。レビュー専用の指示

/code-review は同梱スキルなので、書き換える SKILL.md はありません。公式の方針は、両方に効かせたい指示は CLAUDE.md、PRレビュー専用の指示は REVIEW.md に分けることです。CLAUDE.md の書き方はCLAUDE.mdの書き方ガイドで解説しています。

REVIEW.md はリポジトリ直下に置く自由形式のMarkdownで、公式は次の用途を挙げています。

  • 重大度の付け方を直す: ドキュメントや試作のリポジトリで、何をImportantにするかを定義し直す
  • Nitを減らす: 「Nitは1回のレビューで5件まで」のように上限を決める
  • 見なくてよいものを外す: 生成コード、ロックファイル、CIが検査済みのlintや書式
  • 誤った指摘を減らす: 「挙動の主張には命名からの推測ではなく file:line を引用する」のように根拠を求める

REVIEW.md はPR自身の変更からは読まれず、baseブランチか既定ブランチのものが読まれます。変更はマージしてから効きます。重大度の引き下げ・除外・Nitの上限は、保護された既定ブランチ上のファイルを読んだときに守られるので、先にブランチ保護を設定します。

出てきた指摘はどう読み、どう扱えばいいのか？

管理サービスのCode Reviewは、指摘に3段階の重大度を付けます（公式: PRでの指摘の読み方）。

印 重大度 意味
🔴 Important マージ前に直すべきバグ
🟡 Nit 直す価値はあるがマージを止めない小さな問題
🟣 Pre-existing 元からあるバグで、このPRが持ち込んだものではない

理由が記録された指摘には折りたたまれた「Why this was flagged」があり、開くと指摘の理由とどう検証したかを読めます。

指摘への応じ方は3通りです。

  • 却下する: GitHub上でスレッドをresolveします。返信だけでは却下になりません
  • 直す: 修正してpushします。次のレビューが直ったと判断すると、スレッドをresolveします
  • 反論する: 返信します。返信でレビューは始まらず、次のレビューが返信を読みます。同種の指摘が繰り返すなら REVIEW.md にルールを足すのが公式の勧める対処です

指摘ゼロは「問題なし」の証明ではない

公式は、Code Reviewがバグや脆弱性を見落とす可能性があり、指摘が無くてもエラーが無い・安全だという意味ではないと明記しています。レビューは差分と周辺のコードを読むだけで、ビルドや実行はしません。既定では本番を壊すバグに絞っており、書式の好みやテスト不足は対象外です。動作確認は別に必要で、公式は隣接コマンドとしてアプリを動かして確かめる /verify を挙げています。Code Reviewは承認もブロックもしないので、マージの判断はチームに残ります。

チームのPRを自動でレビューするには何を準備するのか？

管理サービスのCode Reviewの条件は次のとおりです（公式: Code Reviewのセットアップ）。

  • プラン: TeamまたはEnterprise
  • コードの置き場所: GitHub（GitHub Enterprise Serverを含む）
  • 使えない組織: Zero Data RetentionやHIPAA構成の組織。顧客管理の暗号鍵（CMEK）を使う組織も現時点では対象外
  • 有効化: Claude組織のOwnerがclaude.aiの Admin settings > Claude Code でオンにし、Claude GitHub Appを入れてリポジトリを選ぶ。ワークフローファイルは不要

リポジトリごとの Review runs は、PRの作成・再オープン・レビュー準備完了への変更時（Once after PR creation）、pushごと（After every push）、コメントで頼んだときだけ（Manual）の3択です。追加したリポジトリの初期値はAfter every pushで、pushの回数だけ費用が増えます。費用はusage creditsでトークン課金され、開発者ではなく組織に請求されます。深さはQuick・Standard（既定）・Deepの3段階です。

PRに @claude review とコメントすると1回、@claude review always なら以後のpushごとにもレビューします。新しいトップレベルのコメントであること、コマンドが先頭にあること、書いた人にwrite・maintain・adminのいずれかの権限があること、PRがopenであることが条件です。ドラフトとフォークからのPRは自動レビューされないので、コメントで頼みます。GitHub Actionをinteractive modeかつ既定の @claude トリガーで動かしていると @claude review でActionも起動するため、Action側の trigger_phrase を変えて分けます。

Importantがあるときだけマージを止めたい場合

「Claude Code Review」のcheck runは失敗で終わらないので、必須チェックにしてもImportantの有無でマージを止めることはできません。止めたい場合は、公式の手順どおり自前のCIでcheck runの詳細の最終行を読みます。大文字の部分と <commit-sha> は自分の値に置き換えます。

gh api repos/OWNER/REPO/commits/<commit-sha>/check-runs --jq '.check_runs[] | {id, name}'
gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

出力の normal がImportantの件数で、0より大きければジョブを失敗させます。最終行が無いときはゼロ件ではなく「判定なし」として扱います。失敗やタイムアウトしたレビューには、この行がありません。

レビューが動かない、指摘が見当たらないときは何を確認するのか？

/code-review では、次の3点をまず確認します。

  • ルールが効かない: REVIEW.md に書いていれば CLAUDE.md に移す
  • GitLabに投稿されない: glab CLIの有無と、Claude Codeがv2.1.257以降か。自己管理のGitLabではマージリクエストをURLか !123 で渡す
  • ultrareviewがクラウドで動かない: APIキーだけでログインしていれば /login でclaude.aiに認証する。Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry経由、Zero Data RetentionやHIPAA構成の組織ではローカルのレビューに切り替わる

管理サービスのCode Reviewでは、PRの「Claude Code Review」check runのタイトルで状況を判断します（公式: Code Reviewのトラブルシューティング）。

check runの状態 対処
queued / in progress 完了まで待つ
skipped (no new changes) 必要なら @claude review
failed / timed out @claude review か、check runのRe-run（フォークからのPRを除く）
declined 要約に予算や上限の記載があれば管理者に依頼
check run自体が無い @claude review をコメントし、出なければ下を確認

コメントしても始まらないときは、そのリポジトリでCode Reviewがオンか、コメントが条件を満たすか、write以上の権限があるか、予算が残っているかを確認します。予算切れなら「⚠️ Code review skipped」で始まるコメントが付きます。👀のリアクションは開始の確認にならないので、check runの有無で判断します。指摘があるのにインラインに見当たらないときは、check runの Details、Files changed の注記、レビュー本文の Additional findings を見ます。

公式で変わりうる点

ultrareviewは研究プレビューで、機能・料金・提供範囲は変わりうると公式（Ultrareview）に書かれています。無料3回、1回あたり通常5〜25ドル程度、ブランチレビューの差分上限500変更ファイル・8,000変更行（既定値）は2026年10月19日時点の記述です。実行前の確認ダイアログで、対象範囲・残りの無料回数・費用の見積もりを確認できます。

CONTINUE THE SESSION

関連記事