Claude Code の /code-review とは——使い方、レベルの選び方、ultra の料金、デメリットと実際に使った結果

Claude Code の /code-review は、いま手元にある差分（コミット前の変更や、上流より先のコミット）を読み、正しさのバグを探して報告するコマンドです。Claude Code に最初から入っている同梱スキル（bundled skill）で、GitHub のアプリを入れなくてもターミナルからそのまま使えます。/review と打っても同じものが動きます。

この記事では、Claude Code の公式ドキュメント（Code Review の「Review a diff locally」節・Find bugs with ultrareview・Commands）と CHANGELOG の原文をもとに、何ができて、レベル（low〜max）と ultra をどう選び、--fix・--comment をどう使うかを整理します。仕様の説明は2026年10月2日時点の原文で確かめたものです。あわせて、このサイトのコードに実際に /code-review high をかけた結果と、使ってみて分かったデメリットを9章・10章にまとめました。

1. /code-review とは——差分のバグを探す同梱スキル

コマンド一覧（Commands）での説明は、「現在の差分、または渡した PR 番号・ブランチ・パスを、正しさのバグについてレビューする」です。続けて「モデルと effort レベルによっては、整理（cleanup）の機会も扱う」とあり、Code Review のページには「正しさのバグと、再利用・単純化・効率化の整理を報告する」と書かれています。主役はあくまでバグ探しで、整理の提案は条件しだいで付いてくる、という位置づけです。

書式は次のとおりです。

/code-review [low|medium|high|xhigh|max|ultra] [--fix] [--comment] [pr#|branch|path]

押さえておきたい性質は4つあります。

• バックグラウンドで動く。レビューは自分の文脈ウィンドウを持つサブエージェントとして走り、会話を埋めません。終わると結果が会話に届きます。
• CLAUDE.md は読むが、REVIEW.md は読まない。REVIEW.md は後述する GitHub App 版の Code Review 用の指示ファイルです。
• /review は別名。原文によると、v2.1.223 より前の /review は GitHub の PR を1回読むだけの別コマンドでした。いまは /code-review と同じものです。
• 前の名前は /simplify。CHANGELOG では v2.1.147 で /simplify が /code-review に改名され、その後 /simplify は「整理だけをしてバグは探さない」別のコマンドとして戻っています。

ターミナルと -p の実行では、結果は返信のテキストとして届きます。デスクトップアプリのように一覧表示を求めるアプリでは、ファイルの場所・1文の要約・correctness などの分類タグが付いた「指摘の一覧」として表示され、あとで Claude が直すと各項目に fixed・skipped・no change needed の印が付きます。

2. 基本の使い方——何をレビューさせるか

作業中のセッションで、引数なしで打つのがいちばん基本の形です。

# 上流より先のコミット＋未コミットの変更をレビュー
/code-review

# レベルを指定してレビュー
/code-review high

# PR 番号を渡して、同僚のプルリクエストをレビュー
/code-review high 1234

# ブランチ範囲を渡す
/code-review main...my-feature

引数なしのときの対象は、原文の言葉で「ブランチの、上流（upstream）より先にあるコミット＋未コミットの変更」です。ブランチにも作業ツリーにも変更が無ければ、報告することがありません。別のものを見せたいときは、次のように対象を渡します。

レベルとフラグの後ろに残った文字は、ultra を付けない限りすべてレビュー対象として扱われます。たとえば /code-review /fix-issue 123 は、/fix-issue を2つ目のスキルとして起動するのではなく、/fix-issue 123 という文字を対象として読みます。

次の場合は、バックグラウンドではなく会話の中（前面）で動きます。前のレビューがまだ走っているときにもう一度打った場合、-p や Agent SDK の非対話モード、環境変数 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS を 1 にした場合（ほかのバックグラウンド機能もまとめて止まります）です。

3. レベルの選び方——low〜max

レベルは「どこまで広く拾うか」と「どれだけ確信のある指摘に絞るか」の引き換えです。原文は、low と medium ではいちばん確信の高い指摘だけを報告するので誤検知が少ない、high から max は範囲を広げ、確信の低い指摘も含みうると説明しています。

どれを選ぶかの目安は、指摘を読む手間をどれだけ払えるかです。作業の合間にさっと確かめたいなら low か medium、マージ前に見落としを減らしたく、誤検知を自分で捨てる余裕があるなら high 以上、という分け方が原文の説明に沿います。レベルが上がるほど使うトークンが増えるのは effort 全般と同じ考え方ですが、レベルごとの所要時間や消費量の数字は公式ドキュメントには載っていません。effort そのものの意味はClaude Code の effort 設定の記事で解説しています。

レベルを省略すると「前回打ったレベル」が使われる

レベルを書かずに打つと、以前に自分で打った low〜max のうち最後のものが使われます。前のセッションで打ったものでも対象で、そのときは Reusing high effort, the level you typed last time のような通知が出ます。細かい決まりは次のとおりです。

• 記憶が更新されるのは、対話の中で /code-review high のように打ったときです。
• -p の非対話実行で渡したレベルは記憶されません。
• ultra は記憶を使わず、記憶も書き換えません。
• 一度もレベルを打ったことがなければ、そのセッションの現在の effort が使われます。

原文には「v2.1.223 より前は、レベルなしの /code-review は常にセッションの effort を使った」とあります。以前の挙動のつもりで省略すると、思ったより高い（または低い）レベルで走ることがあるので、気になるときは毎回レベルを書くのが確実です。

4. --fix と --comment の使い方

--fix は /rewind で戻らないことがある

いちばん注意したいのはここです。原文によると、バックグラウンドで走ったレビューの --fix による編集は、セッションのチェックポイントの外で行われるため、/rewind では元に戻りません。戻したいときは git を使います。前面で走った場合（前のレビューが進行中・-p など）は自分のターンの中で編集するので、/rewind でいつもどおり戻せます。

# --fix の前に、いまの状態をコミットしておくと戻しやすい
git add -A && git commit -m "wip: before code-review --fix"
/code-review medium --fix

# 気に入らなければ、git で取り消す
git diff
git restore .

--fix を付けずにレビューだけさせ、結果を読んでから「1番と3番だけ直して」と頼む使い方もできます。指摘をすべて反映してよいか迷うときは、こちらのほうが安全です。チェックポイントの仕組みはチェックポイントと /rewind の記事で詳しく説明しています。

--comment の投稿先

• GitHub のプルリクエスト：指摘を該当する行へのインラインコメントとして投稿します。
• GitLab のマージリクエスト：GitLab の CLI である glab を通じて、1件のノートとして投稿します（v2.1.257 以降）。glab が入っていなければ、端末に表示するだけになります。

GitLab では MR を URL か !123 の形で渡します。番号やブランチ名だけで MR と見なされるのは、origin が gitlab.com にあるときだけで、自前で運用している GitLab では URL か !123 を使うよう書かれています。なお、GitHub への投稿に gh などの認証が要るかどうかは、2026年10月2日時点の公式ドキュメントには明記されていません。

5. ultra——クラウドの多エージェントレビューと料金

/code-review ultra は、手元ではなく Anthropic のクラウドの sandbox で、複数のレビュー担当エージェントを並列に走らせる深いレビューです。ultrareview という名前の研究プレビューで、使える状態のアカウントでは /ultrareview がその別名になります。公式ドキュメントは、手元の /code-review と比べた利点として次の3つを挙げています。

• 信号が強い：報告する指摘はすべて独立に再現・検証されるので、スタイルの提案ではなく本当のバグに絞られる。
• 範囲が広い：より多くのエージェントが並列に調べ、手元のレビューが見逃す問題も拾う。
• 手元の資源を使わない：クラウドで動くので、その間も端末で別の作業ができる。

料金と無料回数

ultra はプランに含まれる利用枠ではなく、usage credits（追加利用分）から請求される機能です。

• 無料回数：Pro と Max の3回はアカウントごとに1回限りで、補充されません（原文：one-time allotment per account and don't refresh）。
• 1回の費用：無料回数を使い切った後は、変更の大きさに応じて通常 $5〜25 の usage credits（typically $5 to $25）。起動前の確認画面に見積もりが出ます。
• 数え方：クラウドのセッションが始まった時点で1回と数えます。途中で止めたり失敗したりしても無料回数は1回減ります。有料のレビューは、走った分だけの請求です。
• 前提：usage credits を有効にしていないと有料のレビューは起動できません。状態は /usage-credits で確かめられます。usage credits での請求の確認は会話ごとに1回出ます。

「$5〜25」が高いか安いかは、何と比べるかで変わります。low〜max の /code-review と比べると、こちらはプランの枠の中で別料金が無いので、ultra は追加の出費になります。一方、後述する GitHub App 版の Code Review（1回の平均 $15〜25）と比べると、金額の幅は重なっています。ただし Code Review は PR ごとに自動で走る別の仕組みで、数字も「平均」と「通常の幅」で表し方が違うため、単純な比較はできません。

時間・対象・使えない環境

• 所要時間：通常5〜10分（typically takes 5 to 10 minutes）。バックグラウンドで動き、/tasks で様子を見たり止めたりできます。止めると部分的な結果は返りません。
• 対象：引数なしでは現在のブランチと既定のブランチ（default branch）の差分に、未コミット・ステージ済みの変更を加えたものです。手元の /code-review の「上流より先」とは基準が違います。/code-review ultra develop のようにブランチ名を渡すと基準を変えられます。
• PR を見る：/code-review ultra 1234 のように番号を渡すと、手元からは何もアップロードせず、クラウドで PR を直接 clone します。github.com と、接続済みの GitHub Enterprise Server が対象です。
• 上限：ブランチのレビューは既定で変更ファイル500・変更行8,000まで（値は変わりうると明記）。
• 使えない環境：claude.ai アカウントでのログインが必要で、Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry 経由や、ゼロデータ保持の組織では使えません。使えないときの /code-review ultra は、手元のレビューとして動きます。

ブランチのレビューでは手元のリポジトリの状態をまとめてクラウドへ上げます。.env や *.tfvars のような資格情報らしい名前のファイルの未コミットの変更は、クラウドセッションへのアップロードと同じ規則で扱われます。クラウドセッション全般の仕組みはクラウドセッションの記事にまとめています。

PR に結果を投稿する（--post）とスクリプトからの実行

github.com の PR を ultra でレビューしたときは、結果を自分の GitHub アカウントから PR へ1件のコメントとして投稿できます（v2.1.227 以降）。レビューや承認ではない普通のコメントで、既定は投稿しない（--no-post）です。/code-review ultra 1234 --post とすると起動画面で投稿が選ばれた状態になりますが、起動前の確認は出ます。投稿はレビューが終わったときに始まるので、終わるまでセッションを開いたままにしておく必要があります。

CI やスクリプトから使うなら、サブコマンドの claude ultrareview を使います。結果が出るまで待って標準出力に書き出します（--json・--timeout（既定45分）・--post が使える）。claude -p '/code-review ultra' は起動だけして待たずに終わるので結果が得られず、usage credits の請求が要る場面では起動もしません。

# スクリプトから PR 1234 を ultra でレビューし、結果を受け取る
claude ultrareview 1234

# 既定ブランチ以外を基準にする
claude ultrareview origin/main

6. 似た機能との違い

Claude Code の周りには、名前の似たレビューの仕組みがいくつかあります。とくに「Code Review」という名前の GitHub App の機能は、/code-review コマンドと同じページに書かれているので取り違えやすいところです。

• /simplify：4つのエージェントが並列に、既存のヘルパーの再利用・単純化・効率・抽象度が適切かを見て、修正を反映します。正しさのバグは探しません。Code Review のページでも「バグ探しのために /simplify をスクリプトにしていたなら /code-review --fix に切り替える」と案内されています。
• /security-review：現在のブランチと origin の既定ブランチの差分を、インジェクション・認証の問題・データの露出などの脆弱性について調べます。origin のリモートが必要です。
• Code Review（GitHub App）：組織の Owner が有効にすると、PR が開かれたとき・push のたび・@claude review と書いたときに、Anthropic の基盤で複数のエージェントが PR を調べ、行ごとのコメントを付けます。研究プレビューで、Team と Enterprise のみ（ゼロデータ保持の組織は不可）。料金はトークン量に応じ、1回の平均が $15〜25、所要は平均20分で、プランの枠とは別に usage credits から請求されます。REVIEW.md で指摘の基準を調整できます。
• claude-code-action：自分のリポジトリの GitHub Actions のワークフローで Claude Code を動かす仕組みです。公式ドキュメントのレビュー例は、プラグイン版の code-review スキル（/code-review:code-review --comment）を呼んで PR にコメントさせる形になっています。費用は Claude の API 料金（またはサブスクのトークン）と、GitHub Actions の実行時間です。

「どこで、誰の費用で、何を見るか」で分けると整理しやすくなります。手元で自分の差分を見るなら /code-review、マージ前に深く見るなら ultra、チームの PR すべてに自動でかけたいなら GitHub App の Code Review か claude-code-action、という分かれ方です。

7. Claude が自分から起動する場合と、止め方

/code-review は、Claude が自分の判断で起動することがあります。「変更をレビューして」と普通の言葉で頼むと、コマンドを打たなくてもスキルとして動くことがあり、/code-review をプロンプトにしたスケジュール実行のタスクでもレビューが走ります。ただし、スケジュール実行から ultra（クラウドのレビュー）が起動されることはありません。ultra は、自分で /code-review ultra と打ったときにだけ動きます。

Claude とスケジュール実行の両方から起動されないようにし、自分で打つときだけ使えるようにするには、~/.claude/settings.json などの設定ファイルに次を加えます。

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

バックグラウンドで動くレビューはサブエージェントとして動きます。サブエージェントの文脈やモデルの扱いはサブエージェントとエージェントチームの記事で説明しています。

8. どの場面で何を使うか

公式ドキュメントの比較表は、手元の /code-review を「作業しながらの素早い確認」、ultra を「大きな変更をマージする前の確信」に向くとしています。これをふだんの流れに当てはめると、次のようになります。

ultra の無料3回は補充されないので、小さな修正に使うより、影響範囲の広い変更や、手元のレビューで決め手が出なかった変更に取っておくほうが得です。また、脆弱性を重点的に見たいなら /security-review、バグではなくコードの読みやすさを整えたいなら /simplify と、目的で分けるのが原文の説明に沿った使い方です。

9. 実際に使ってみた——このサイトのコードで

2026年10月2日、このサイトで公開したAI 画像判定ツールのコードに、/code-review high をかけました。ブラウザの中だけで画像のメタデータや来歴（C2PA）を読むツールで、対象は画面の処理・読み取りの処理（Web Worker）・コントローラー・画面のテンプレートの4ファイルです。実行したのは Claude Code のデスクトップアプリ（同梱の Claude Code 2.1.284、モデルは Opus 5.5）で、筆者が自分でバグを探して5件を直した直後にかけています。

指摘はどれも「どのファイルの何行目か」「どんな入力で、何が起きるか」の形で返ってきました。筆者はそれを1件ずつ、使っている部品（画像のメタデータを読むライブラリ exifr）のソースコードや、実際に作ったテスト用の画像で確かめ、本物だった9件をすべて直しました。主な中身は次のとおりです。

筆者が自分で探して直した直後でも、別の種類のバグが9件残っていたことになります。とくに「使っている部品がこう動くはず」という思い込みの指摘は、部品のソースまで読まないと気づきにくいものでした。ただし、これは1つのコードに1回かけた結果です。いつも同じ割合で本物が見つかるとは限らず、low・medium・max との比較や、有料の ultra は試していません。

10. デメリットと注意点

使ってみて、また公式ドキュメントを読んで分かった注意点は次の5つです。

• 利用枠を使う——手元のレビューも Claude の通常の利用枠から差し引かれ、レベルを上げるほど多く使う。ultra は、Pro・Max の無料3回を使い切ると（Team・Enterprise は最初から）1回 $5〜25 程度を usage credits で払う。
• 指摘をそのまま信じない——公式も high 以上は確信の低い指摘を含むと書いている。今回は10件中9件が本物だったが、それでも1件ずつ確かめる手間はかかる。
• --fix は /rewind で戻せない——バックグラウンドで直させた変更は git で戻すことになるので、使う前にコミットしておく。
• コードの正しさしか見ない——文章や設定の中身が事実と合っているかまでは見ない。たとえばこのサイトでよく起きる「記事の記述が公式の仕様と違う」は対象外。
• Claude が自分から起動することがある——望まないときは、7章の設定で手動のときだけに絞れる。

筆者の判断としては、新しく書いたプログラムや大きな変更の後に、high で1回かけるのが、手間と利用枠に見合う使い方でした。逆に、文章の修正や設定の小さな変更には向きません。

まとめ

/code-review は、手元の差分や PR を、正しさのバグに絞ってレビューする同梱スキルです。バックグラウンドで動くので作業を止めず、費用は通常の利用枠の中に収まります。レベルは low・medium なら確信の高い指摘だけ、high〜max なら広く拾う代わりに仕分けが要り、省略すると前回打ったレベルが使われます。

直すところまで任せる --fix は便利ですが、バックグラウンドの編集は /rewind で戻らないので、先にコミットしておくのが安全です。もっと深く見たいときの ultra はクラウドで5〜10分ほどかけて検証済みの指摘だけを返し、Pro・Max には1回限りの無料3回、その後は usage credits で1回 $5〜25 程度かかります。名前の似た GitHub App の Code Review や claude-code-action とは、動く場所も費用も別物です。

このサイトのコードに1回かけたところ、筆者が自分で直した直後でも指摘10件のうち9件が本物のバグでした。指摘は1件ずつ確かめる必要がありますが、新しいプログラムや大きな変更の後に1回かける価値は十分にあります。

FAQ

Q. /review と /code-review は何が違いますか？

A. いまは同じものです。/review は /code-review の別名で、同じレベルとフラグを受け付けます。公式ドキュメントによると、v2.1.223 より前の /review は GitHub の PR を1回だけ読む、読み取り専用の別コマンドでした。

Q. /code-review を使うと別に料金がかかりますか？

A. low〜max はかかりません。公式ドキュメントの比較表では、費用は「通常の利用枠に数えられる（counts toward normal usage）」とされています。別料金になるのは ultra で、Pro・Max の無料3回を使った後は usage credits で1回およそ $5〜25 です。

Q. ultra の無料3回は毎月もらえますか？

A. もらえません。公式ドキュメントは、Pro と Max の3回を「アカウントごとに1回限りで、補充されない」と書いています。途中で止めたレビューや失敗したレビューでも1回と数えられます。Team と Enterprise には無料回数がありません。

Q. --fix で変更されたものを元に戻せますか？

A. git で戻します。バックグラウンドで走ったレビューの編集はチェックポイントの外で行われるので、/rewind では戻りません。レビューが前面で走った場合（前のレビューが進行中・-p など）は /rewind で戻せます。迷うなら、--fix の前にコミットしておくのが確実です。

Q. REVIEW.md に書いたルールは /code-review にも効きますか？

A. 効きません。手元の /code-review は CLAUDE.md には従いますが、REVIEW.md は読みません。REVIEW.md は GitHub App 版の Code Review 用の指示ファイルです。手元のレビューにも効かせたいルールは CLAUDE.md に書きます。

出典

• Claude Code 公式ドキュメント：Code Review（「Review a diff locally」節を含む）
• Claude Code 公式ドキュメント：Find bugs with ultrareview
• Claude Code 公式ドキュメント：Commands
• Claude Code 公式ドキュメント：Claude Code GitHub Actions
• Claude Code：CHANGELOG

いずれも2026年10月2日に原文を確認しました。ultrareview は研究プレビューで、機能・料金・提供範囲は変わることがあると公式ドキュメントに明記されています。