Claude Code /code-reviewの使い方と料金｜ultrareviewとの違い

Claude Codeのレビューコマンドは、2026年8月6日のv2.1.223で /code-review に整理された。ただし実務で効くのは「どれを打つか」より「どのレベルで打つか」のほうだ。

Express製の小さなメモアプリに、わざと9個の欠陥を仕込む。バグ3件、整理すべき箇所3件、セキュリティ脆弱性3件。そのうえでレビューコマンドを片っ端から走らせたら何が起きるか。ふくだ氏がv2.1.206で試した結果はこうだった。/code-review high は9個すべてを検出した。medium は8個。ところが xhigh と max は、検出数が増えないまま時間だけが3〜6倍に伸び、max は約23分かかった（出典: Zenn「Claude Codeレビュー系コマンドの使い分け」 ふくだ氏、2026年7月13日公開・7月21日更新）。

効き目はどこかで頭打ちになる。それを知らずに一番重いレベルを回し続けると、時間とトークンだけが溶けていく。

Claude Code v2.1.223で/reviewが/code-reviewに統合された

整理されたのは2点だ。

1つ目、/review が /code-review のエイリアス（別名）になった。これは単なる名前の付け替えではない。v2.1.223より前の /review は、GitHubプルリクエスト（PR）を1パスで読み取り専用レビューする別コマンドだった（出典: Claude Code公式チェンジログ v2.1.223、Code Reviewドキュメント）。同じコマンドを打っても返ってくるものが変わっている。CIスクリプトやチーム内のドキュメントに /review を書いている場合は、一度挙動を確認しておいたほうがいい。

2つ目、effortレベルが記憶されるようになった。effortとは、AIがどれだけ時間と計算を使って探すかの強度設定で、low から max まで5段階ある。レベルを打たずに /code-review だけ実行すると、前回自分が打ったレベルを再利用し、Reusing high effort, the level you typed last time のような通知が出る。過去のセッションで打ったレベルも引き継がれる。v2.1.223より前は、レベル未指定なら常にセッションの現在effortが使われていた（出典: Code Reviewドキュメント）。

例外が2つある。一度もレベルを打ったことがなければ、従来どおりセッションの現在effortが使われる。また非対話モード（-p フラグ）で渡したレベルは記憶を更新しない。ultra はこの記憶を更新もしないし利用もしない、独立した扱いだ。

地味だが実務では効く変更だ。「毎回 high と打つのを忘れて軽いレビューになっていた」という事故が減る。逆に「一度 max と打ったことを忘れて、以後ずっと重いレビューが走る」という逆方向の事故も起きうる。

なお /ultrareview から /code-review ultra への表記の移行は、v2.1.223の変更内容には含まれていない。それ以前のバージョンで進んでいた整理だ。公式ドキュメントの現在の記述は「コマンドは /code-review ultra です。ultrareviewが利用可能なアカウントでは /ultrareview はエイリアスです」となっている（出典: ultrareviewドキュメント）。

/code-review・ultra・GitHub連携版の違いを比較表で整理

Claude Codeの「レビュー」には、料金体系も対象プランも違う3つの層がある。ここを混ぜて理解していると、料金の話が噛み合わなくなる。

	ローカル /code-review	/code-review ultra	GitHub連携 Code Review
料金	通常の利用量にカウント	無料枠後は1回5〜25ドル	1レビュー平均15〜25ドル
利用条件	どのプランでも	claude.aiアカウント認証が必要	Team・Enterprise（研究プレビュー）
結果の届き方	セッション内に通知	セッション内に通知	PRへのインラインコメント
実行場所	自分のセッション内	Anthropicのクラウドサンドボックス	Anthropicのインフラ
所要時間	数秒〜数分	おおむね5〜10分	平均20分
起動方法	スラッシュコマンド	スラッシュコマンド	PR作成・push・@claude review

（出典: ultrareviewドキュメント、Code Reviewドキュメント。金額はいずれも米ドル建て・税別）

3行目が重要だ。GitHub連携版だけがPRに自動でコメントを付ける。上2つは自分のターミナルに結果が返ってくるだけで、GitHub Appのインストールは不要だ。「AIレビューは高い」という話の多くは4列目のことを指している。ひとりで開発しているなら、まず2列目で足りる。

プラン・環境別に何が使えるか

プラン／環境	ローカル /code-review	ultra	GitHub連携
Pro	◯	◯（無料3回→課金）	×
Max	◯	◯（無料3回→課金）	×
Team・Enterprise	◯	◯（無料枠なし）	◯（Ownerが有効化）
APIキーのみで認証	◯	×（claude.ai認証が必要）	×
Bedrock / Google Cloud Agent Platform / Microsoft Foundry経由	◯	×（ローカルレビューにフォールバック）	×
Zero Data Retention有効の組織	◯	×	×

（出典: ultrareviewドキュメント、Code Reviewドキュメント）

ローカルの /code-review は既定でバックグラウンドのサブエージェントとして走る。独立したコンテキストウィンドウを持つので、レビューの出力で自分の会話が埋まらない。

• --fix: 指摘をそのまま手元の作業ツリーに適用する
• --comment: GitHubのPRに行単位のインラインコメントとして投稿する
• レビュー範囲: ファイルパス／PR番号／ブランチ名／main...my-feature（mainから分岐して以降の差分だけを見る書き方）

/code-reviewのeffortレベルの選び方｜検証ではhighで頭打ち

公式ドキュメントの説明はこうだ。low と medium は自信のある指摘だけを報告するので誤検知が少ない。high から max は網羅性が広がる代わりに、確度の低い指摘も混じる（出典: Code Reviewドキュメント）。

冒頭のふくだ氏の検証は、この説明とちょうど噛み合う。high で9個全件の検出に届き、medium が1件取りこぼしたのは「自信のある指摘だけ」という設計どおりだ。逆に xhigh 以上で検出数が増えなかったのは、9個という規模のコードでは網を広げる余地がもう残っていなかったということになる。

ただし同氏の計測には続きがある。検出できた数と、最終レポートに載った数は別だ。high は9個検出して最終レポートは8件、xhigh は9個検出して6件、max だけが9個検出して9件すべてを報告した。網羅性の点では max がわずかに上回っている。「検出できても報告に残るとは限らない」という挙動は覚えておいたほうがいい。なおこの検出率の差は変更規模に依存するため、数千行のマージ前まで同じ傾向とは限らない。検証は統合前のv2.1.206時点のものである点も踏まえておきたい。

同氏はほかにも実務的な落とし穴を挙げている。

• /security-review は仕込んだ脆弱性3件を正しく全部拾ったが、バグと整理項目は0件だった。「対象外」として明示的に除外する仕様で、専門家ではあっても万能ではない
• 統合前の /review はコミット済みの変更しか見ないため、未コミットの2件を取りこぼして9個中7件の検出にとどまった
• Haiku 4.5ではマルチエージェントのレビューが完走しないことが多く、effortレベルの指定にも公式には対応していない
• /code-review ultra は9個すべてに加え、同氏が仕込んだ覚えのない実在のバグ1件を約15分で検出した

別の検証も傾向が近い。tandago氏はレースコンディション、SQLインジェクション、アクセス制御の不備、個人情報のログ出力、null参照、非同期処理の問題という6種類の欠陥を仕込んだコードで試し、/code-review が7件（うちクリティカル3件）を指摘したと報告している。/security-review は前者が拾わなかった認可の不備とプライバシー面を拾い、2つを合わせて6種類すべてに到達した。同氏の結論も、人間による確認は何らかの形で必要だという点に落ち着いている（出典: note「Claude Codeのレビューコマンドを試す」 tandago氏、2026年6月13日）。

2つの検証に共通しているのは、単一コマンドで全部を賄おうとすると穴が空きうるという点だ。いずれも意図的に欠陥を埋め込んだ小規模コードでの結果であり、検出率は対象や規模によって変わる。とはいえバグ検出と脆弱性検出を別の網で見る方針は、追加コストが低いわりに合理的だ。

effortレベルを上げれば必ず品質が上がるわけではないという話は、レビュー以外の用途でも報告されている。

/code-review ultraの料金と無料枠｜課金は起動した時点で始まる

/code-review ultra はクラウドで動く。ローカルのレビューとの違いとして公式が挙げているのは、報告される指摘がすべて独立に再現・検証されること、より大きなエージェント群が並列で探索すること、ローカルのリソースを使わないことの3点だ（出典: ultrareviewドキュメント）。5月に登場したときの位置づけから、機能の狙いは変わっていない。

無料枠は1回限りで、月次補充されない

プラン	無料枠	無料枠後
Pro	1回限りの3回	usage creditsで課金
Max	1回限りの3回	usage creditsで課金
Team・Enterprise	なし	usage creditsで課金

（出典: ultrareviewドキュメント）

無料枠は月ごとに補充されない。アカウントごとに1回限りの配布だ。

さらに公式ドキュメント自身が「無料枠を使い切ったあと、または無料枠の提供期間が終了したあと」という書き方をしている。第三者の解説記事には「無料枠の提供期間は2026年5月5日で終了した」とする記述もある。表に無料枠が載っていても、自分のアカウントで実際に使えるとは限らない。起動前の確認ダイアログにレビュー範囲・残りの無料回数・推定コストが表示されるので、そこで確認するのが確実だ。

課金の起点にも注意がいる。公式ドキュメントは「クラウドセッションが開始した時点で1回とカウントする。途中で止めたレビューや完了しなかったレビューも無料枠を消費する。有料実行は走った分だけ課金される」と明記している（出典: ultrareviewドキュメント）。「様子を見て途中で止めればタダ」は成立しない。

金額の感覚をつかんでおくと、1回5〜25ドルは仮に1ドル150円で換算するとおよそ750〜3,750円になる。為替は変動するので目安でしかないが、「コーヒー1杯」ではなく「ランチ数回分」の価格帯だと捉えておくのが安全だ。

自分のコードはどこに渡るのか

受託開発や社内規程のある環境では、コマンドの選定より先にこちらが問題になる。

利用できない環境とフォールバック

ultraはclaude.aiアカウントでの認証を必要とする。APIキーのみでログインしている場合は使えない。Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry経由では利用できず、Zero Data Retentionを有効にした組織でも使えない。この条件に当たると /code-review ultra は黙って落ちるのではなく、ローカルレビューにフォールバック（代替動作へ切り替え）する（出典: ultrareviewドキュメント）。エンタープライズ経由で使っている人が「ultraを回したつもりでローカルレビューだった」となりうる箇所だ。

diffのサイズ上限もある。ブランチレビューは既定で変更ファイル500件・変更行8,000行まで。超えると拒否され、ファイル数と行数、変更行の多いファイルが表示される。リポジトリが大きすぎてバンドルできない場合は、ドラフトPRを作って /code-review ultra <PR番号> で回すようにと案内される（出典: ultrareviewドキュメント）。

GitHub連携版Code Reviewの料金｜チーム人数で損益が変わる

3列目のGitHub連携版は、2026年3月9日に登場した管理サービスだ。研究プレビュー段階のため、仕様・価格は変更されうる。詳細はClaude Code Review完全ガイドにまとめてあるので、ここでは金額の判断に絞る。

複数のエージェントが並列でdiffと周辺コードを解析し、検証ステップで誤検知を落としてから、該当行にインラインコメントを投稿する。指摘は🔴Important（マージ前に直すべきバグ）、🟡Nit（軽微）、🟣Pre-existing（このPRが持ち込んだのではない既存バグ）の3段階で色分けされる。チェックランの結論は常に neutral なので、ブランチ保護でマージがブロックされることはない（出典: Code Reviewドキュメント）。

Anthropic社内データが示す検出率

1,000行を超える大きなPRの84%に問題が見つかり、平均7.5件の指摘があった。50行未満の小さなPRでは31%、平均0.5件。エンジニアが誤りと判定した指摘は1%未満。導入後、実質的なレビューコメントが付いたPRの割合は16%から54%に増えたという（出典: Anthropic公式ブログ「Code Review for Claude Code」 2026年3月9日、The Register 同日、InfoQ）。

数字は良い。問題は金額だ。1レビュー平均15〜25ドル（米ドル建て・税別）という水準に対して、開発者からの反発は公開直後から出ている。1日10PRを開けるチームなら月4,500〜7,500ドルという試算が流通した（出典: buildfastwithai「Is Claude Code Review Worth $15–25 Per PR?」 2026年3月23日）。一方、10人チーム・月60PRを前提にした月額比較では、GitHub連携版が1,200〜1,500ドル、/code-review ultra が600〜1,200ドル、サブエージェントを自前で組む方式なら200〜500ドル程度という整理もある（出典: Shareuhack）。

2つの数字が3〜5倍違うのは、前提のPR本数が違うからだ。前者は月200PR超、後者は月60PRを見込んでいる。要するに PR本数 × 1レビュー単価 でしかないので、自分のチームの月間PR数に15〜25ドルを掛けるのが一番早い。なおこれらはいずれも第三者による試算値で、算出条件や税の扱いを筆者が検証したものではない。実際の請求額は利用状況によって変わる。

トリガー設定がコストを決める

コストの罠として繰り返し指摘されているのが、リポジトリごとに選ぶトリガー設定だ。「After every push」を選ぶと、pushのたびにレビューが走る。修正を細かくpushする習慣のチームでは、1つのPRでレビューが何度も回ることになる。公式ドキュメントも「毎pushでのレビューは最も多くのレビューを走らせ、最もコストがかかる」と明記している（出典: Code Reviewドキュメント）。Manualにして @claude review で明示的に呼ぶほうが、金額のコントロールは効く。

支出上限はclaude.aiの管理設定でCode Reviewサービスに対して月額キャップを設定できる。上限に達するとレビューはスキップされ、PRにその旨のコメントが1件だけ投稿される。導入するなら、有効化と同じ日にキャップも決めておいたほうがいい。

REVIEW.mdで指摘内容を制御する

何を指摘させるかは REVIEW.md でかなり細かく制御できる。リポジトリのルートに置くと、レビューパイプライン内の全エージェントのシステムプロンプトに最優先ブロックとして注入される。「Nitは1レビュー5件まで」「生成ファイルとlockファイルは対象外」「新しいAPIルートには結合テストを必須にする」といった指示が書ける。CLAUDE.md の内容も読まれるが、そちらの違反はNit扱いに落ちる。強制力が違う。

ただし REVIEW.md が効くのはGitHub連携版だけだ。ローカルの /code-review は CLAUDE.md は読むが REVIEW.md は読まない（出典: Code Reviewドキュメント）。

自分ならこう使う

PMとしてClaude Codeを日常的に回している立場から、判断を書いておく。

まず、GitHub連携版は当面入れない。ひとりで書いてひとりでマージしている規模で、1PRあたり15〜25ドルは合わない。この金額が成立するのは、レビュアーの人件費と事故コストがそれを上回るチームだ。「3〜4PR/日を超えるチームなら計算は合う」という整理（出典: buildfastwithai）には同意する。逆に言えば、それ未満なら合わない。

ローカルの /code-review は high を既定にする。ふくだ氏の検証で high が検出数の頭打ちの位置だったこと、v2.1.223でレベルが記憶されるようになったことの2つが理由だ。一度 /code-review high と打っておけば、以後は /code-review だけで済む。max を常用する理由は、少なくとも小〜中規模の変更では見当たらない。報告の網羅性で max がわずかに上回るとはいえ、23分と4分の差を埋めるほどではない。

ultra は「壊れたら自分では気づけない場所」にだけ使う。認証まわり、DBマイグレーション、課金処理だ。障害時の影響が大きい箇所であれば、1回5〜25ドル（米ドル建て・税別）は許容できる範囲だと考えている。ただしレビューを通しても見落としは起こりうるので、コストの正当化は各自の障害コスト見積もりに依る。Ultracodeがリリース2日後に170万トークンを焼いた件と同じ構図で、クラウドに投げる機能はコストの見積もりが手元で立たない。usage creditsをオンにするなら、支出上限もセットで設定するのが前提だ。

そして、/code-review と /security-review は分けて回す。2つの独立した検証がどちらも「片方だけでは穴が空く」という結果を出している以上、1コマンドで済ませたい気持ちは捨てたほうがいい。

もうひとつ、時期的な注意を書いておく。8月14日からauto modeがPro・Max・Teamの既定になる。承認プロンプトが減る分だけ、コードが人間の目を通らずに積み上がる量は増える。レビューコマンドの整備は、その変更とセットで考えるべき話だ。承認の関所を1つ外すなら、マージ前の関所は1つ増やしておきたい。

チーム導入を検討する立場なら、判断材料は3点で足りる。1つ目、GitHub連携版は1PRあたり平均15〜25ドルでTeam・Enterprise限定。判断は「月間PR数 × 20ドル」がレビュー工数の削減分を下回るかどうかに尽きる。2つ目、まず追加コストゼロで試すなら各自のローカル /code-review で足りる。GitHub Appの導入も管理者承認も要らない。3つ目、クラウドにコードを出せない組織は ultra とGitHub連携版が対象外になるため、ローカル版だけの運用になる。

---

関連記事

• Claude Code Review完全ガイド｜マルチエージェントが人間の見逃すバグを自動検出
• Claude Code 5月アップデート｜/ultrareview・/recap・プッシュ通知完全ガイド
• Claude Code auto modeが8月14日デフォルト化｜manualに戻す設定
• Ultracodeで170万トークンが消えた: Claude Code最新機能の実際のリスク
• Claude Code /rewind徹底解説｜チェックポイントで壊れたコードを一発で戻す

---

本記事の情報は2026年8月11日時点のものです。Claude Codeは頻繁にアップデートされるため、最新の仕様は公式チェンジログ、Code Reviewドキュメント、ultrareviewドキュメントを参照してください。記載の金額のうち公式ドキュメント由来のものは米ドル建て・税別表記であり、別途消費税等が加算される場合があります。第三者の試算値については算出条件・税の扱いを筆者が検証したものではありません。円換算は仮の為替レートによる目安であり、実際のレートは変動します。ultrareviewおよびGitHub連携版のCode Reviewはいずれも研究プレビュー扱いのため、機能・価格・提供範囲が変更される可能性があります。引用した検証結果はふくだ氏・tandago氏・Anthropic・各媒体が公表した内容を引用したものであり、筆者が独立に再現検証したものではありません。英語ソースからの引用は筆者による翻訳で、意訳を含みます。本記事の情報に基づく設定変更や課金の発生について、筆者は責任を負いません。実行前に必ず公式ドキュメントと起動ダイアログの表示を確認してください。

※ 記載の会社名・製品名は各社の商標または登録商標です。