Claude Codeのreview effortを指定する — /code-reviewの前回レベル再利用

Claude Codeのレビューで使うeffort(推論レベル)は、/code-reviewの後ろにレベルを付けるだけで指定できます。lowは確度の高い指摘だけを返し、mediumからmaxは網羅を広げるかわりに、確信の弱い指摘も混ざります。レベルを省いた場合は「前回自分が入力したレベル」が使われます。この記憶が別セッションにも及ぶ点が、いちばん見落とされやすい挙動です。

/code-reviewのeffort指定は何を変えるのか

/code-reviewは、ローカルの差分をターミナルで見るレビューコマンドです。ブランチの上流より先にあるコミットと未コミットの変更が既定の対象になり、正しさのバグを返し、モデルとeffortによっては再利用・単純化・効率化の指摘も含みます。

effortを渡すと、この報告の「厳しさ」が変わります。公式の説明は2段階です。

公式の説明が分けているのは、この2つのグループです。mediumからmaxまでは同じ「網羅を広げる」側に並び、各レベルのあいだに指摘の傾向の差は示されていません。指摘の件数そのものは、v2.1.288で入った --max-findings で別に指定できます(Claude Code v2.1.288)。

つまりeffortは「思考の深さ」だけでなく、レビューでは「どこまで指摘を出すか」の閾値として働きます。誤検知に付き合う時間を惜しむ日常の確認はlow、見落としを減らしたいマージ前はmedium以上、という割り振りが自然です。

セッション全体のeffortの仕組みは、Claude Code effortレベルの使い方とClaude effortの使い分けにまとめています。ここで扱うのは、/code-reviewの引数として渡すeffortだけです。指摘の出力形式はReportFindingsツールが決めます。

レベルの書き方と実行例

書式は/code-review <レベル> [フラグ] [対象]です。レベルに続けて--fixや--commentなどのフラグ、そして対象(ファイルパス・PR番号・ブランチ名・main...my-featureのような範囲)を置きます。

/code-review low
/code-review high
/code-review max --fix
/code-review medium 123

最後の例は、mediumでPR 123を対象にする形です。--fixは指摘を作業ツリーに適用するフラグです。--commentは指摘をGitHubのPRにインラインで、GitLabのMRには1件のノートで投稿します(GitLabはglabが必要、v2.1.257以降)。--fixの経緯はv2.1.152のリリースノートにあります。

指摘の件数にも上限があり、--max-findings <n>で件数を、--max-findings allで全件を指定できます(v2.1.288以降)。このフラグもレベルと同じく、入力した値が以降のレビューで再利用され、--max-findings defaultで元に戻ります。

/reviewは/code-reviewの別名です。v2.1.223より前の/reviewは、GitHubのPRを1回の読み取り専用パスで見る別のコマンドでした。

レベルを省くと前回の値が使われる

引数なしの/code-reviewは、直近に自分で打ったlow〜maxのレベルを再利用します。別セッションでも同じです。使われるときは、次のようなnoticeが出ます。

Reusing high effort, the level you typed last time

レベルを変えたいときは、/code-review highのように打ち直します。それ以降の引数なし実行は、打ち直したレベルを使います。

記憶されるのは「/code-reviewに自分で入力したレベル」で、/effortで変えたセッションの値は記憶の対象として挙げられていません。逆に、一度も/code-reviewにレベルを打っていなければ、記憶はなく、セッションの現在のeffortが使われます。

変更が入ったのはv2.1.223です。それより前は、レベルなしの/code-reviewは常にセッションの現在のeffortで動いていました。バージョンを上げた後で「毎回同じ深さになる」と感じたなら、この変更が原因です。

前回レベルが働かない3つの場面

スクリプトからは毎回レベルを明示しておけば、記憶の有無に左右されません。

セッションの/effortとレビューのレベルは別の設定

同じlow〜maxの語彙でも、セッションの/effortと/code-reviewの引数は保存の仕方が違います。混同すると「変えたはずなのに効かない」につながるので、並べておきます。

レベルを一度も打っていない場合は、セッションの現在のeffortが使われます。その既定値は、対応モデルの多くでhigh(組織が既定モデルに既定のeffortを設定している場合は例外)、Opus 5.5とSonnet 5.5はmedium、Opus 4.7はxhighです。つまり、Opus 5.5とSonnet 5.5で引数なしの/code-reviewを打つと、網羅を広げる側のレベルで動きます。

effortの記憶を使った運用の組み立て

記憶の仕組みは、書き方次第で便利にも事故のもとにもなります。実務では次の使い分けが成り立ちます。

注意したいのは、プッシュ前にmaxを試したあと、そのまま日課の/code-reviewを省略形で打ち続けるケースです。次の実行でmaxが再利用され、時間も指摘の数も増えます。実行のたびにnoticeの文言を見て、意図しないレベルが使われていないかを確かめてください。

チームで共有したい判断は、レベルの記憶ではなくCLAUDE.mdに書いておくほうが確実です。レビューはCLAUDE.mdに従って動くためです(REVIEW.mdは読まれません)。たとえば次のように書きます。

## コードレビュー
- プッシュ前は `/code-review high` を実行し、指摘を確認してから push する
- 認証・課金に触れる変更は `/code-review ultra` も併用する

effortの後ろに書いた文字列はどう読まれるか

レベルとフラグの後ろに残った文字列は、ultraの有無で扱いが変わります。

• ultraなし: 残りはすべてレビュー対象のテキストになる。/code-review /fix-issue 123は、/fix-issueを別のスキルとして読み込まず、/fix-issue 123を対象の文字列として扱う
• ultraあり: 1語なら基準ブランチかPR番号として読み、それ以上の文章はレビューに添えるメモになる。/code-review ultra check my auth changesは現在のブランチを見て、指摘をメモに関連づける

後ろに別のコマンドを付けても連鎖しないのは、v2.1.218からの挙動です。それより前は、/code-reviewの後ろのコマンドが別のスキルとして展開されていました。

ultraはeffortの最上位ではない

ultraはmaxの次の段ではなく、クラウドで動く別の経路(ultrareview)を呼ぶ引数です。前回レベルの記憶にも関与しません。/code-review ultra --fixなら、クラウドのレビューが返した指摘を、戻ってきた時点で作業ツリーに適用します。

ultrareviewには前提があります。claude.aiアカウントでの認証が必要で、Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry、ゼロデータ保持を有効にした組織では使えません。使えない環境で/code-review ultraを打つと、セッション内のローカルレビューに切り替わります。「ultraと書いたのにクラウドで動いていない」ときは、この条件を確認します。実行手順と料金はultrareviewの使い方に分けてあります。

スクリプトやCIでは、claude -pとclaude ultrareviewでクラウドレビューの扱いが分かれます。

指摘をCIのログやPRに残したいなら、後者です。--timeout <minutes>の既定は45分で、--jsonを付けると整形前のbugs.jsonがそのまま出ます。v2.1.289で--helpを実行した出力は次のとおりです。

claude ultrareview --help

Usage: claude ultrareview [options] [target]
 
Run a cloud-hosted multi-agent code review of the current branch (or a PR number
/ base branch) and print the findings
 
Options:
  -h, --help           Display help for command
  --json               Print the raw bugs.json payload instead of formatted
                       findings
  --no-post            Do not post the findings to the PR (the default; accepted
                       for parity with the /ultrareview and /code-review ultra
                       flags)
  --post               Post the finished review's findings to the PR as you (PR
                       targets only; one plain comment, not a review)
  --timeout <minutes>  Maximum minutes to wait for the review to finish
                       (default: 45)

--postは、github.comのPRを対象にしたときだけ効きます。レビューが終わった時点で、指摘をPRに1件のコメントとして投稿します(v2.1.227以降)。

スケジュールタスクからは、クラウドレビューは起動しません。/code-reviewを定期実行するなら、ultraを付けずに登録します。

Claudeが自分でレビューを始めることもあります。「変更をレビューして」と自然な文で頼めば、コマンドを打たなくてもスキルが走ります。/code-reviewを手で打つときだけに絞りたい場合は、設定ファイルのskillOverridesで"code-review": "user-invocable-only"を指定すると、Claudeとスケジュールタスクからの起動を止められます。

実行の裏側 — バックグラウンドとサブエージェント数

effortの選択は、レビューの動き方にも関わります。押さえておきたい変更は3つです。

v2.1.274の変更は、モデルによってレビューの分割数が変わることを意味します。モデルを切り替えたあとにレビューの挙動(所要時間やサブエージェントの数)が変わって見えたら、この変更が背景にあります。

実行の場所は、既定ではバックグラウンドです。次の場合は、フォアグラウンドで動きます。

• 前のレビューが終わる前に、もう一度/code-reviewを実行した
• -pやAgent SDKで非対話実行した(発見は応答に含まれる。ただしultraは待たずに起動する)
• 環境変数CLAUDE_CODE_DISABLE_BACKGROUND_TASKSを1にした(ほかのバックグラウンド機能もすべて止まる)

バックグラウンド実行の--fixの編集は、セッションのチェックポイントの外で適用されます。/rewindでは戻せないので、元に戻すときはgitを使います。フォアグラウンドの場合は、/rewindで戻せます。

よくあるつまずき

CIで毎回同じ深さにしたい: 記憶に頼らず、レベルと対象をコマンドに書き切ります。

claude -p "/code-review high main...my-feature"

xhighが効かないモデルがある: Opus 4.6とSonnet 4.6はxhighを持ちません。選べるのはlow・medium・high・maxです。セッション側では、対応していないレベルは指定値以下で最も高いレベルにフォールバックし、xhighはhighとして動きます。

まとめ

maxを試したあとは、/code-review lowなどで打ち直して深さを戻しておくと、省略形の次回実行で意図しないレベルが使われずに済みます。