Claude Code のレビューコマンドは /code-review、/review <pr>、/code-review ultra の3系統。名前が似ているのに、走る場所も料金も待ち時間も違います。公式ドキュメントに “How ultrareview compares to /code-review and /review” という比較表があるので、そこを起点に整理しました。
3つのレビューコマンドは何が違うか
公式の比較表を日本語に置き換えたものが下です。
/code-review | /review <pr> | /code-review ultra | |
|---|---|---|---|
| 対象 | 手元の作業差分 | GitHub の PR | 作業差分または PR |
| 実行場所 | ローカルセッション | ローカルセッション | クラウドサンドボックス |
| 深さ | effort 引数でスケール | セッションの effort で単一パス | エージェントのフリート + 独立検証 |
| 所要時間 | 数秒〜数分 | 数秒〜数分 | およそ5〜10分 |
| 料金 | 通常の使用量 | 通常の使用量 | 無料枠の後は1回 $5〜$20 |
| 向く場面 | 書きながらの素早い確認 | 他人の PR を approve する前 | 大きめの変更のマージ前 |
ultra だけ性質が違う
上2つはローカルの1エージェントが1パスで差分を読むもの。/code-review ultra はリモートサンドボックスでレビュアーエージェントのフリートを起動し、報告される検出結果はすべて独立に再現・検証されます。スタイル指摘ではなく実バグに寄る、というのが公式の説明。ローカルのターミナルは占有されません。
/simplify と /security-review の居場所
/simplify は v2.1.147 より前、今の /code-review そのものの名前でした。v2.1.154 から役割が分かれ、現在の /simplify はバグを探さずクリーンアップだけを当てます。バグ探し目的で /simplify をスクリプトに埋めているなら /code-review --fix に置き換えが要ります。/security-review は差分を脆弱性の観点だけで見るコマンドで、こちらは分岐していません。
/code-review をローカルで回す
/code-review # セッションの effort で作業差分をレビュー
/code-review high # 広めに拾う
/code-review max --fix # 最大範囲 + 検出結果を作業ツリーに適用
/code-review low src/auth/session.ts # ファイル単位
/code-review main...my-feature # ref range 指定検出結果はファイル位置と理由が付いた形で返ります。
Found 2 issues
🔴 src/auth/session.ts:142
Token refresh races with logout, leaving stale sessions active
🟡 src/auth/session.ts:88
parseExpiry silently returns 0 on malformed inputeffort レベルで指摘の量が変わる
引数の指定は low|medium|high|xhigh|max|ultra。低いほど件数は少なく確度が高い、high から max はカバレッジが広がる代わりに確証の薄い指摘も混ざります。引数を省いた場合はセッションの現在の effort。/effort を上げた状態で打つと、黙って深くなります。effort そのものの挙動はClaude Code ultrathinkとeffortレベルで思考の深さを制御するで別途整理しました。
v2.1.206 で、Opus 4.8 の全 effort レベルにおける /code-review の検出品質が改善されています。
レビュー対象の既定スコープ
引数なしの /code-review が見るのは、ブランチが upstream より先に進んでいるコミット + 作業ツリーの未コミット変更。ここが ultra と食い違います。ultra は現在ブランチとリポジトリのデフォルトブランチの差分 + 未コミット・ステージ済み変更で、upstream の設定を見ません。
upstream が別ブランチに向いている worktree だと、同じ変更のつもりで打った2つのコマンドが別の差分を読みます。意図した範囲を固定したいなら main...my-feature の ref range 形式を渡すのが確実。この形式は「my-feature から main への PR に含まれるコミット差分」を、upstream の設定に関係なくレビューします。
–fix と –comment
--fix: レビュー後、検出結果を作業ツリーに適用する--comment: 検出結果を GitHub PR のインラインコメントとして投稿する
/code-review ultra --fix も通ります。クラウドでの深いレビューを走らせ、結果がセッションに戻ってきた時点で作業ツリーに当てる動きです。
/review <pr> を使う場面
役割は名前より狭く、GitHub の PR を単一パスで読み取り専用レビューするだけ。手元の差分は見ません。他人の PR に approve を押す前、自分の目の前に一度通しておく用途です。
自分が書いた差分に対しては /code-review のほうが素直。対象が「手元」か「PR」かで選べば迷いません。
ultra の料金と無料枠の消え方
ultra はプラン込みの使用量ではなく使用クレジットから引かれます。公式の “Pricing and free runs” にある表がこれ。
| プラン | 無料実行 | 無料枠の後 |
|---|---|---|
| Pro | 3回 | 使用クレジットで課金 |
| Max | 3回 | 使用クレジットで課金 |
| Team / Enterprise | なし | 使用クレジットで課金 |
この3回はアカウントごとの一度きりの配布で、リフレッシュしません。しかもクラウドセッションが始まった時点で1回とカウントされます。途中で止めたレビューも、完走せず失敗したレビューも、無料枠を1つ消費します。有料実行のほうは走った分だけの課金なので、そこは対称ではありません。
使用クレジットが有効でないアカウントでは、有料の ultra は起動自体がブロックされ、課金設定へのリンクが出ます。現在の設定は /usage-credits で確認可。プラン制限側の内訳は Claude Code /usage—使用量と制限の内訳をスキル単位で確認する のほうで見られます。
走らせている間
ultra はバックグラウンドタスク。セッションは使い続けられますし、ターミナルを閉じても構いません。/tasks で実行中・完了済みのレビューを一覧、詳細を開く、進行中のものを止める、まで可能。ただし停止するとクラウドセッションはアーカイブされ、部分的な検出結果は返りません。途中で止めるくらいなら、最初から打たないほうが無料枠は減りません。
起動前には確認ダイアログが出ます。レビュー範囲（ブランチレビュー時はファイル数と行数）、残りの無料実行回数、推定コスト。Claude が自分の判断で ultra を開始することはありません。
REVIEW.md でレビューの当たりを決める
GitHub App 版の Code Review が読むのは、リポジトリの2ファイル。CLAUDE.md と REVIEW.mdです。効き方の強さが違うので、混ぜると事故ります。
CLAUDE.md との優先度の違い
CLAUDE.md: 全タスク共通のプロジェクト指示。Code Review はこれをプロジェクト文脈として読み、新しく持ち込まれた違反を nit として報告する。逆方向にも効き、PR がCLAUDE.mdの記述を古くする変更なら「ドキュメントの更新が要る」と指摘してくるREVIEW.md: レビュー専用。レビューパイプラインの全エージェントのシステムプロンプトに、最優先の指示ブロックとして直接注入される。既定のレビューガイダンスより優先される
REVIEW.md はそのまま貼り付けられる点に注意。@ import 構文は展開されず、参照したファイルはプロンプトに読み込まれません。効かせたいルールはファイル本体に直接書く必要があります。CLAUDE.md の書き分けは Claude CodeとGitHub Actionsでコードレビューを自動化する手順 の設計とも噛み合います。
Nit の洪水を上限で止める
既定の重要度は本番コード向けのキャリブレーション。ドキュメントリポジトリや設定リポジトリに当てると、🟡 Nit が延々と積まれます。散文と設定ファイルは、磨こうと思えば無限に磨けるので。手元の設定リポジトリで初回 @claude review を打ったとき、Nit が20件超で本命の指摘が埋もれました。上限を書いてからは読める量に収まっています。
# Review instructions
## What Important means here
Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.
## Cap the nits
Report at most five Nits per review. If you found more, say "plus N
similar items" in the summary instead of posting them inline.
## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules結果として、インラインコメントは最大5件 + サマリに残件数、という形に落ちます。
再レビューを収束させる
push ごとにレビューが走る設定だと、1行の修正が7周目に届きます。REVIEW.md に収束ルールを1行書けば止まります。
after the first review, suppress new nits and post Important findings only
同じ発想で調整できるものが他にもあります。
- 検証バー: 「挙動の主張には
file:lineの引用が要る。命名からの推測は不可」と書くと、著者に往復1回を強いる誤検出が減る - スキップ規則: 生成コード・ロックファイル・vendored 依存・機械生成ブランチ。全部消すほどではないパスは「
scripts/では、ほぼ確実かつ深刻な場合のみ報告」のようにバーを上げる - リポジトリ固有チェック: 「新しい API ルートには結合テストが要る」。最優先で注入されるので、長い
CLAUDE.mdに同じことを書くより確実に効く - サマリの形: 冒頭に
2 factual, 4 styleのような集計行を要求する
長さにはコストがあります。REVIEW.md が長いほど、一番効かせたいルールが薄まる。挙動を変える指示だけを置き、一般的なプロジェクト文脈は CLAUDE.md に残すのが公式の推奨です。
claude ultrareview を CI から呼ぶ
インタラクティブセッションなしで同じレビューを起動するサブコマンドがあります。公式の “Run ultrareview non-interactively” に対応。
claude ultrareview # 現在ブランチ vs デフォルトブランチ
claude ultrareview 1234 # PR 番号
claude ultrareview origin/main # ベースブランチ指定リモートのレビュー完了までブロックし、検出結果を stdout に出し、成功で 0、失敗で 1 を返します。
終了コードとタイムアウト
0: レビュー完了（検出結果の有無に関わらず）1: 起動失敗、クラウドセッションのエラー、タイムアウト130: Ctrl-C による中断
0 が「バグなし」を意味しない点が要注意。バグが出ても完走すれば 0 です。ゲートにするなら stdout をパースします。フラグは2つ。
--json: 整形済みの検出結果ではなく生のbugs.jsonペイロードを出力--timeout <minutes>: 完了待ちの上限。既定30分
進捗メッセージとライブセッション URL は stderr に出るので、stdout はパース可能なまま保たれます。Ctrl-C でサブコマンドを抜けてもリモートのレビューは走り続けるので、stderr に出た URL をブラウザで追えます。
GitHub App 版のチェックランを読む
Team / Enterprise 向けの Code Review を入れている場合、チェックランの最終行が機械可読なコメントになっています。
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 の件数です。チェックランは常に neutral で完了するのでブランチ保護でマージを止めません。止めたいなら、この JSON を自前の CI で読んで判定します。
打つ前に確認する制約
認証とプラットフォーム
ultra は Claude Code on the web の基盤で走るため、Claude.ai アカウントでの認証が必須。API キーだけでサインインしているなら /login からやり直しが要ります。そして次の環境では使えません。
- Amazon Bedrock
- Google Cloud の Agent Platform
- Microsoft Foundry
- Zero Data Retention を有効にした組織
バンドルできないリポジトリ
ブランチレビューでは、リポジトリの状態をバンドルしてリモートサンドボックスにアップロードします。大きすぎるとバンドルできず、PR モードを促されます。ブランチを push してドラフト PR を開き、/code-review ultra <PR番号> へ切り替える流れ。PR モードならサンドボックスがホストから直接 clone するので、ローカルの容量は関係ありません。
逆に PR の差分が大きすぎる場合は、レビュー作業が走る前にスコープのヒント付きで拒否されます。レビュー作業が走る前に止まるので、課金は発生しません。PR モードが効くのは github.com と、Owner が Claude Code に接続した GitHub Enterprise Server のインスタンスです。
まとめ
- 対象が「手元の差分」なら
/code-review、「他人の PR」なら/review <pr>。ここで迷わない /code-reviewの既定スコープは upstream 基準、ultraはデフォルトブランチ基準。食い違うならmain...my-featureで固定する- effort は低いほど少数高確度、
high〜maxは広く拾って不確実なものも混ざる。省略時はセッションの effort が効く - ultra の無料枠は Pro / Max で一度きりの3回。停止・失敗でも1回消える
- Nit が多すぎるなら
REVIEW.mdに上限と収束ルールを書く。CLAUDE.mdより強く効く claude ultrareviewの終了コード0は「完走」であって「バグなし」ではない。ゲートにするなら--jsonをパースする- Bedrock / Vertex / Foundry / ZDR 組織では ultra は使えない