Claude Code でコードレビューする5つの手法と、レビューに使うモデルの選び方

はじめに

Claude Code には、コードレビューのための仕組みがいくつも用意されています。手元の差分をその場で見てもらう /code-review、クラウドで複数のエージェントが検証まで行う ultrareview、GitHub の PR を自動でレビューする Code Review、自分で組む GitHub Actions やサブエージェントなどです。

選択肢が多いぶん、「どれを使えばいいのか」「レビューにはどのモデルを使うべきか」で迷いやすくなります。本記事では、次の2点を整理します。

1. Claude Code でコードレビューする手法と、それぞれの使いどころ
2. レビューに使うモデル(Fable / Opus / Sonnet / Haiku)と effort の選び方

本記事の内容は、2026年11月時点の Claude Code 公式ドキュメント に基づいています。Claude Code は更新が速く、コマンドの挙動や料金は変わることがあります。使う前に公式ドキュメントも確認してください。

手法の全体像

まず、手法を一覧で比較します。

手法	どこで動くか	主な用途	費用	利用条件
/code-review(ローカル)	自分のセッション	実装中のすばやいフィードバック	通常の利用枠/API 課金	全プラン
ultrareview(/code-review ultra)	Anthropic のクラウド	マージ前の深いレビュー	無料枠の後、1回 約$5〜25	claude.ai アカウント
Code Review(マネージド)	Anthropic のクラウド	組織の全 PR を自動レビュー	1回 平均$15〜25	Team / Enterprise(リサーチプレビュー)
GitHub Actions	自分の CI	プロンプト・モデル・トリガーを自分で制御	API 課金 + Actions 分	API キー or サブスク
カスタムサブエージェント	自分のセッション	チーム独自の観点でのレビュー	通常の利用枠/API 課金	全プラン

使い分けの目安は次のとおりです。

• 書きながら確認したい → /code-review
• 大きな変更をマージする前に念入りに見たい → ultrareview
• チームの PR を全部自動で見てほしい → Code Review(または GitHub Actions)
• 独自のルールで見てほしい → カスタムサブエージェント、CLAUDE.md / REVIEW.md

以下、順番に見ていきます。

手法1: ローカルで /code-review を実行する

最も手軽なのが /code-review です(/review はその別名です)。Claude Code のセッションで実行すると、ブランチの変更からバグを探して報告してくれます。

/code-review

引数なしの場合は、上流ブランチより先に進んでいるコミットと、未コミットの変更が対象です。上流ブランチがない場合は main と比較します。

レビュー対象を指定する

対象	入力
現在のブランチと未コミットの変更	/code-review
直近15コミット	/code-review HEAD~15..HEAD
ブランチ同士の比較	/code-review main...my-feature
特定のコミット	/code-review abc1234^..abc1234
PR 番号	/code-review 1234
ファイル・ディレクトリ	/code-review src/auth

よく使うフラグ

フラグ	内容
--fix	レビュー後、指摘を作業ツリーに反映する
--comment	指摘を GitHub の PR にインラインコメントとして投稿する(GitLab の MR には1件のノートとして投稿)
--max-findings <n> / all	報告する指摘の上限を変える

たとえば、Android アプリの feature/login ブランチを develop と比べてレビューし、そのまま修正まで任せる場合は次のようになります。

/code-review --fix develop...feature/login

effort でレビューの深さを変える

/code-review には effort(推論の深さ)を指定できます。

/code-review low     # 確信度の高い指摘だけ。誤検知が少ない
/code-review high    # 範囲を広げる。確信度の低い指摘も含まれうる

公式ドキュメントによると、low では確信度の高い指摘だけを報告するため誤検知が少なく、high から max では範囲を広げます。medium の扱いは、ドキュメントのページによって「確信度の高い指摘だけ」側と「範囲を広げる」側の両方の記述があり、はっきりしません。一度入力した effort は、次回以降も(別のセッションでも)引き継がれます。

知っておきたい挙動

• バックグラウンドで動く: レビューは独立したコンテキストを持つサブエージェントとして動くため、会話を圧迫しません。終わると結果が会話に届きます
• CLAUDE.md に従う: プロジェクトのルールは CLAUDE.md に書けば、レビューにも反映されます。ただし、後述の REVIEW.md は読みません
• --fix の修正は /rewind で戻せない場合がある: バックグラウンドのレビューが行った修正は、セッションのチェックポイントの外で行われます。元に戻すときは git を使ってください。--fix の前にコミットしておくと安心です
• 頼めば自動で走る: 「変更をレビューして」と普通に頼んでも、Claude が /code-review を起動することがあります

手法2: ultrareview で念入りにレビューする

/code-review ultra を実行すると、クラウドで複数のレビュー用エージェントが並行して変更を調べ、指摘を1件ずつ再現・検証したうえで報告してくれます(リサーチプレビューです。利用できる場合は /ultrareview も別名として使えます)。

/code-review ultra            # 現在のブランチを既定ブランチと比較
/code-review ultra develop    # develop と比較
/code-review ultra 1234       # PR #1234 をレビュー
/code-review ultra check my auth changes   # 気にしている点をメモとして添える

ローカルの /code-review との違いは次のとおりです。

	/code-review	/code-review ultra
実行場所	自分のセッション	クラウドのサンドボックス
深さ	effort で調整	複数エージェント + 独立した検証
所要時間	数秒〜数分	約5〜10分
費用	通常の利用枠	無料枠の後、1回 約$5〜25(usage credits)
向いている場面	実装中のすばやい確認	大きな変更のマージ前

料金と利用条件

• Pro / Max プランには、アカウントごとに1回限りの無料枠が3回あります。それ以降は usage credits で課金されます
• 実行前に、対象範囲と見積もり費用の確認ダイアログが出ます
• claude.ai アカウントでのログインが必要です。Amazon Bedrock などのクラウドプロバイダー経由や、Zero Data Retention を有効にした組織では使えません(その場合はローカルのレビューになります)
• ブランチをレビューする場合は、リポジトリの状態がクラウドにアップロードされます。PR 番号を指定した場合は、手元からは何もアップロードされず、クラウド側で PR を clone します

CI から実行する

スクリプトや CI からは claude ultrareview サブコマンドを使います。レビューが終わるまで待って、結果を標準出力に出します。

claude ultrareview 1234 --json --timeout 30

claude -p '/code-review ultra' はレビューを起動するだけで結果を待たないため、CI では claude ultrareview を使ってください。

手法3: Code Review で PR を自動レビューする

Code Review は、GitHub の PR を Anthropic のインフラ上で自動レビューするマネージドサービスです。Team / Enterprise プラン向けのリサーチプレビューで、組織の Owner が有効化します。

仕組み

• 複数のエージェントが、差分と周辺のコードを並行して調べます。エージェントごとに担当する問題の種類が異なります
• 検証ステップで実際のコードの振る舞いと照らし合わせ、誤検知を除きます
• 結果は重複を除いて重大度順に並べ、該当行へのインラインコメントとして投稿されます
• PR の承認やブロックはしません。チェックは常に neutral で完了します

マーク	重大度	意味
🔴	Important	マージ前に直すべきバグ
🟡	Nit	直したほうがよいが、ブロックしない軽微な問題
🟣	Pre-existing	この PR で入ったものではない、既存のバグ

トリガー

リポジトリごとに、「PR 作成後に1回」「push のたび」「手動」から選べます。手動の場合は、PR のトップレベルのコメントで呼び出します。

コメント	動作
@claude review	1回だけレビューする
@claude review always	レビューし、以降の push でも毎回レビューする

費用

1回のレビューは平均$15〜25で、PR の大きさや複雑さで変わります。プランの利用枠とは別に usage credits で課金され、管理画面で月の上限を設定できます。「push のたび」は最も費用がかかるので、まず「PR 作成後に1回」か「手動」から始めるのがおすすめです。

REVIEW.md でレビューの観点を調整する

リポジトリのルートに REVIEW.md を置くと、レビュー専用の指示を与えられます。CLAUDE.md の違反は既定では Nit 扱いですが、REVIEW.md は指摘の検出・検証を担うエージェントに直接渡るため、効きやすいと公式ドキュメントで説明されています。

Android プロジェクトなら、たとえば次のように書けます(内容は一例です)。

# Review instructions

## Important とするもの
- 動作を壊す、データを漏らす、ロールバックを妨げるもの
- メインスレッドでの I/O、ネットワーク、DB アクセス
- Activity / Context のリーク、ライフサイクルを無視したコルーチンや Flow の購読
- ログや例外メッセージへの個人情報、トークンの出力
スタイル、命名、リファクタリングの提案は Nit までとする。

## Nit の上限
Nit は1回のレビューで5件まで。それ以上は要約に件数だけ書く。

## 指摘しないもの
- detekt / ktlint / Android Lint が検出するもの
- 生成コード(`build/` 配下、`*.pb.kt` など)

## 必ず確認するもの
- 新しい API 呼び出しが、共通の通信ラッパー経由になっているか
- ViewModel から公開する状態が `StateFlow` で、外部から変更できないか

長く書くほど大事なルールが薄まるので、レビューの挙動を変える指示だけに絞るのがコツです。一般的なプロジェクトの説明は CLAUDE.md に書きます。

ローカルの /code-review は REVIEW.md を読みません。手元でも同じ観点を使いたい場合は、CLAUDE.md に書くか、手法5のサブエージェントを使います。

手法4: GitHub Actions で自分でレビューを組む

自分の CI で、プロンプト・モデル・トリガーを細かく制御したい場合は、anthropics/claude-code-action を使います。Claude Code で /install-github-app を実行すると、GitHub App のインストールからシークレットの登録、ワークフローの PR 作成までを案内してくれます。

公式ドキュメントのレビュー用ワークフローに、モデルの指定を加えた例です。

name: Code Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: |
            --model claude-sonnet-5-5
            --allowedTools "mcp__github_inline_comment__create_inline_comment"

ポイントは次のとおりです。

• --comment: これがないと、指摘は PR に投稿されず、ワークフローのログにだけ残ります
• --allowedTools: インラインコメントを投稿するためのツールを、claude_args で明示的に許可する必要があります
• --model: 省略すると Claude Code の既定モデルが使われます。CI ではバージョンを固定するため、sonnet などのエイリアスではなく claude-sonnet-5-5 のような正式なモデル ID を指定するのがおすすめです(エイリアスは新しいモデルが出ると自動で切り替わります)
• --max-turns: 費用の暴走を防ぐために、claude_args で上限を設定できます

上の YAML のうち、--model の行は筆者が追加したものです。それ以外は公式ドキュメントの例のとおりです。私はこのワークフローを実際に動かしてはいません。

手法5: レビュー専用のサブエージェントを作る

チーム独自の観点でレビューしたい場合や、実装とレビューでモデルを分けたい場合は、カスタムサブエージェントを作ります。.claude/agents/ に Markdown ファイルを置くだけです。

---
name: android-reviewer
description: Kotlin / Android の変更をレビューする。実装が一区切りついたときに使う
tools: Read, Glob, Grep, Bash
model: opus
effort: high
---

あなたは Android アプリのシニアレビュアーです。
`git diff` で変更を確認し、次の観点でレビューしてください。

- コルーチンのスコープとキャンセル(GlobalScope の使用、viewModelScope 外での起動)
- Flow の購読とライフサイクル(collectAsStateWithLifecycle / repeatOnLifecycle の使用)
- Compose の再コンポジション(不安定な引数、remember の欠落)
- メインスレッドでの重い処理
- 個人情報やトークンのログ出力

指摘はそれぞれ「ファイル:行」「何が問題か」「どう直すか」の形で、
重大なものから順に書いてください。確信が持てないものは、その旨を明記してください。

frontmatter の model には、sonnet / opus / haiku / fable のエイリアス、claude-opus-5-5 のような正式な ID、または親と同じモデルを使う inherit を指定できます。effort も指定できます。tools を読み取り系に絞れば、レビュアーがコードを書き換えることもありません(上の例では git diff のために Bash を許可しています。完全に読み取り専用にしたい場合は外してください)。

使うときは、「android-reviewer でレビューして」と頼むだけです。

補足: /security-review

セキュリティに特化したレビューとして、/security-review もあります。SQL インジェクション、XSS、認証・認可の不備、安全でないデータの扱い、依存関係の既知の脆弱性などを調べます(サポート記事)。GitHub Action 版(anthropics/claude-code-security-review)もあります。

レビューにはどのモデルを使うべきか

ここからが本題の後半です。

選べるモデル

Claude Code で選べる主なモデルと、API の料金です(2026年11月時点。Anthropic API の場合)。

エイリアス	モデル	入力 / 出力(100万トークンあたり)	公式の推奨用途
fable	Claude Fable 5.1	$10 / $50	最も難しく長時間かかる、曖昧なタスク
opus	Claude Opus 5.5	$4 / $20	複雑な推論、アーキテクチャ
sonnet	Claude Sonnet 5.5	$2 / $10	日常のコーディング、実装
haiku	Claude Haiku 5.5	$0.10 / $0.50(※)	単純で速いタスク

※ Haiku 5.5 は、プロンプトが10万トークンを超えると $0.50 / $2.50 になります。大きな差分やリポジトリ全体を読ませるレビューでは、この境界を超えやすい点に注意してください。

補足です。

• エイリアスの中身は、利用環境で変わります。たとえば Amazon Bedrock や Google Cloud では、sonnet が Sonnet 4.5 を指します(Anthropic API では Sonnet 5.5)。正確なモデルを使いたい場合は、正式なモデル ID を指定してください
• 既定のモデルは、Pro / Max / Team / Enterprise や Anthropic API では Opus 5.5 です
• Fable はどのプランでも既定ではなく、usage credits で課金される場合があります。また、安全のための分類器がリクエストを検知すると(サイバーセキュリティや生物学の分野が多い)、自動で別のモデルに切り替わります。セキュリティレビューでは、Fable を指定しても別のモデルで実行されることがある点に注意してください

モデルの切り替え方

/model sonnet          # セッション中に切り替え
/effort high           # effort を変更

claude --model opus --effort high   # 起動時に指定

サブエージェントは、既定では親の会話のモデルを引き継ぎます。前述のとおり、frontmatter の model で個別に指定できます。

effort も合わせて考える

レビューの質は、モデルだけでなく effort でも変わります。Opus 5.5 / Sonnet 5.5 / Haiku 5.5 の effort の既定値は medium で、low / medium / high / xhigh / max から選べます。

公式ドキュメントの目安では、high は「検証が重要、またはエッジケースが起きやすい場合(バグ修正など)」、max は「難しい問題をじっくり任せたい場合(考えすぎることもあるので、広く使う前に試す)」とされています。

/code-review の場合は、前述のとおり effort で誤検知の少なさと網羅性のどちらを重視するかが変わります。

判断材料になるデータ

レビュー用途でのモデル比較として、AI コードレビューサービスの CodeRabbit が公開している評価があります(CodeRabbit のブログ)。実在の OSS の PR から作った、既知のバグを含む難しめの13ケースでの結果です。

構成	既知のバグの検出	指摘の的中率
Sonnet 5.5(thinking あり)	6/13(46.2%)	41.2%
Opus 5.5(標準)	8/13(61.5%)	66.7%
Opus 5.5(Max)	10/13(76.9%)	52.0%

CodeRabbit は、Sonnet 5.5 を「メインのレビューに使える初めての Sonnet」と評価しつつ、難しいケースでは Opus 5.5 が上で、見逃しのコストが高い場面では Opus の費用に見合うと結論づけています。

ただし、ケース数が13件と少なく、自社製品を持つベンダーによる評価です。あくまで傾向を見るための参考にしてください。Opus 5.5 を Max にすると、検出数は増えましたが的中率は下がっており、「深く考えるほど指摘が増え、ノイズも増える」傾向が読み取れます。

場面別のおすすめ

以上を踏まえた、筆者のおすすめです。公式の推奨ではなく、上記の情報をもとにした筆者の考えです。

場面	おすすめ	理由
実装中の差分チェック	sonnet + /code-review(effort は既定の medium)	速くて安い。何度も回す用途に向く
誤検知を減らしたい日常の確認	sonnet + /code-review low	確信度の高い指摘だけに絞れる
PR のマージ前	opus + /code-review high	見逃しのコストが高い場面では、Opus の検出力に見合う
認証、決済、並行処理、データ移行など重大な変更	/code-review ultra(ultrareview)	複数エージェントで、指摘を1件ずつ検証してくれる
設計全体を見直したい、原因不明の不具合を追う	fable	公式の推奨用途に合う。費用が高いので必要なときだけ使う
CI での自動レビュー	claude-sonnet-5-5 を ID で固定	回数が多いので費用を抑える。ID 固定で挙動を安定させる
書式やドキュメントのチェックなど定型的な確認	haiku	安い。ただしバグ探しには向かない

最初は Sonnet 5.5 で日常的に回し、重要な PR だけ Opus 5.5 か ultrareview に上げる、という二段構えから始めるのがおすすめです。

実装とレビューでモデルを分ける

筆者のおすすめとして、実装と同じ会話・同じ視点でレビューさせないことも挙げておきます。

• /code-review は独立したコンテキストのサブエージェントで動くため、実装中の会話の思い込みを引き継ぎにくい作りになっています
• さらに一歩進めて、手法5のサブエージェントで model: opus を指定すれば、「Sonnet で実装し、Opus でレビューする」といった分担ができます

なお、opusplan というエイリアス(計画モードでは Opus、実行時は Sonnet)もありますが、これは計画と実装を分けるためのもので、レビュー用の設定ではありません。

運用上の注意

• AI のレビューは、人のレビューの代わりではありません: Code Review は PR を承認もブロックもしない設計で、公式のサポート記事でも、既存のセキュリティ対策や人によるレビューを補うものと位置づけられています
• 費用の上限を決めておく: ultrareview と Code Review は usage credits で課金されます。Code Review は管理画面で月の上限を設定できます。GitHub Actions では --max-turns やワークフローのタイムアウトを設定してください
• コードの送信先を確認する: ultrareview や Code Review では、コードが Anthropic のクラウドで処理されます。社内のルールで外部送信が制限されている場合は、事前に確認してください
• --fix の前にコミットする: バックグラウンドのレビューが行った修正は、/rewind で戻せない場合があります

まとめ

• Claude Code のレビュー手法は、主に5つあります。実装中は /code-review、マージ前の重要な変更は ultrareview、チームの PR は Code Review か GitHub Actions、独自の観点はサブエージェントと使い分けます
• ルールは、全体で使うものを CLAUDE.md に、Code Review 専用のものを REVIEW.md に書きます。ローカルの /code-review は REVIEW.md を読みません
• モデルは、日常は Sonnet 5.5、見逃せない PR は Opus 5.5 か ultrareview、設計レベルの難題は Fable 5.1 が目安です。Haiku はバグ探しより定型的な確認に向きます
• モデルと合わせて effort も調整します。/code-review では、low で誤検知を減らし、high 以上で網羅性を上げます
• CI ではエイリアスではなく正式なモデル ID で固定し、費用の上限を設定しておきます

参考

• Review locally with /code-review - Claude Code Docs
• Find bugs with ultrareview - Claude Code Docs
• Code Review - Claude Code Docs
• Claude Code GitHub Actions - Claude Code Docs
• Subagents - Claude Code Docs
• Model configuration - Claude Code Docs
• Pricing - Claude Platform Docs
• Automated Security Reviews in Claude Code - Claude Help Center
• Sonnet 5.5 vs Opus 5.5 Code Review Benchmarks - CodeRabbit