Claude Codeコードレビュー — 4つの実行経路の使い分け

Claude Codeにコードレビューを任せる方法は1つではありません。経路は4つあります。ローカルセッションで動かす/code-review、自分で書くGitHub Actionsワークフロー、組織全体にかける管理Code Review機能、そしてクラウドで深く検証するultrareviewです。実行場所とコストの構造がそれぞれ違います。どれか1つを選ぶ話ではなく、変更の重さに応じて重ねて使う組み合わせの話です。

Claude Codeのコードレビューは実行場所で4通りに分かれる

4つの経路は、動く場所とトリガーの持ち方で見分けられます。

チームでのCLAUDE.md規約の作り方や、管理Code Review機能をGitHub Appとして組織にインストールする手順はClaude Codeチーム導入ガイドに譲ります。本稿は、この4経路をいつ選ぶかという使い分けの判断と、そこで言及されていないultrareviewの詳細に絞ります。

ローカルの/code-reviewはどこまで柔軟に呼べるか

/code-reviewは、何も指定しなければブランチのアップストリームより先のコミットと未コミットの変更を対象にします。ファイルパス・PR番号・ブランチ名・main...my-featureのような参照範囲(ref)を渡せば対象を切り替えられます。レビュー基準は通常セッションと同じくCLAUDE.mdに従いますが、REVIEW.mdは読みません(レビュー専用のREVIEW.mdが効くのは管理Code Review機能だけです)。

/code-review --fix

--fixはレビュー後に指摘を作業ツリーへ自動適用し、--commentはPRへインラインコメントとして投稿します。バックグラウンドレビューの--fixはセッションのチェックポイントの外側で編集を適用するため、/rewindでは元に戻せません。取り消したい場合はgitで戻します。レビューは既定でバックグラウンドのサブエージェントとして走るため、会話のコンテキストを圧迫しません。完了すると結果が会話に流れ込みます。フォアグラウンドで動く(自分のターンの中で待たされる)場合が3パターンあります。既にレビューが進行中のときに再実行した場合、-pフラグやAgent SDKで非対話実行した場合、CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1を設定した場合です。

深さはlowからmaxまでのeffort level(レビューの深さ)で調整します。レベルを指定せずに呼ぶと前回タイプしたレベルを再利用し、次に何が使われるかがセッション冒頭に表示されます。-pでの実行やultra引数はこの記憶を更新しません。

v2.1.223以降のClaude Codeは、「変更をレビューして」という自然文からも/code-reviewを自律的に起動できます。/code-reviewをプロンプトにしたスケジュールタスクも同様です。v2.1.215からv2.1.222までの期間は、どの構成でもClaudeが自律的に/code-reviewを起動することはありませんでした。現行版でも、Amazon Bedrock・Google Cloud・Microsoft Foundry経由のセッション、Claude apps gateway経由のセッション、テレメトリを無効化した環境では、明示的にコマンドを打った場合しか起動しません。自律起動そのものを止めたいなら、~/.claude/settings.jsonにskillOverridesでcode-reviewをuser-invocable-onlyに設定します。設定ファイルの他のキーとの兼ね合いはsettings.json完全ガイドを参照してください。

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

自分のGitHub Actionsワークフローで動かす

管理Code Review機能はGitHub Appを組織にインストールする前提です。プロンプト・モデル・トリガーを自分で制御したい場合は、code-reviewプラグインを組み込んだワークフローファイルを自分で書く選択肢があります。次の例は、PRが開かれた・更新された・再オープンされた・レビュー可能になった(ready for review)タイミングで同じレビューを走らせるものです。

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 }}"

管理Code Review機能と中身は同じプラグインです。違うのは、トリガーの条件やモデル指定、レビュー以外のジョブとの組み合わせを自分のワークフローファイルに書ける点です。公開リポジトリでは、フォークからのPRに対してGitHubがシークレットを渡さない制約があります。そのため、このワークフローは同一リポジトリ内のブランチから開かれたPRでしか走りません。フォークPRも含めて全PRをカバーしたいなら、管理Code Review機能のほうが向きます。

組織のPRを自動レビューする管理Code Review機能

管理Code Review機能はTeam / Enterpriseサブスクリプション向けのリサーチプレビューです。Owner権限を持つ管理者がclaude.ai/admin-settings/claude-codeからGitHub Appをインストールします。リポジトリごとに「PR作成時に1回」「pushのたびに」「@claude reviewが来たときだけ」のいずれかを選びます。

複数のエージェントが差分と周辺コードを並行検査し、候補を実際のコード動作と突き合わせて絞り込みます。その上で🔴 Important(マージ前に直すべき)・🟡 Nit(軽微)・🟣 Pre-existing(このPRで持ち込まれていない既存バグ)の3段階でインラインコメントを投稿します。チェック実行は常に中立的な結論で完了し、PRを承認もブロックもしません。マージ判断のゲートに組み込みたい場合は、チェック実行IDをgh api repos/OWNER/REPO/commits/<sha>/check-runsで取得します。出力テキストの末尾にある機械可読なJSONをjqで解析して、重大度別カウントを取り出す実装が必要です。

レビュー基準はCLAUDE.md(通常セッションと共有、新規違反はNit扱い)とREVIEW.md(レビュー専用、全エージェントに最優先で注入されデフォルト基準を上書き)の2ファイルで調整できます。この2ファイルの具体的なチューニング項目はClaude Codeチーム導入ガイドを参照してください。料金は1レビューあたり平均15〜25ドルです。プランの含まれた使用量にはカウントされず、利用クレジット(usage credits)として個別請求されます。

本当に危ういPRだけultrareviewへ上げる

/code-review ultra(利用可能なアカウントでは/ultrareviewという別名でも呼べます)は、ローカルのレビューとは別物です。Claude Code on the webのインフラ上で、変更ブランチかPRをリモートのサンドボックスに送り、複数のレビューエージェントが並行して検証まで行ってから結果を返します。ローカル/code-reviewより重い代わりに、報告される指摘は独立に再現・検証済みという違いがあります。

ultrareviewはリサーチプレビューで、機能・料金・利用可否は変わりうるものとして扱ってください。利用にはclaude.aiアカウントでの認証が必要で、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry経由でClaude Codeを使っている場合や、Zero Data Retentionを有効化した組織では利用できません。利用できない環境で/code-review ultraを呼ぶと、代わりにセッション内でのローカルレビューが走ります。

/code-review ultra 1234

引数なしなら現在のブランチとデフォルトブランチの差分を、ブランチ名を渡せばそのブランチとの差分を対象にします。PR番号を渡せば、そのPRをクローンして直接レビューします。ブランチレビューは既定で最大500ファイル・8,000変更行までという上限があり、超えるとPRモードへの切り替えを促されます。Claude Code v2.1.227以降では、github.comのPRをレビューした場合に--postフラグを使えます。自分のGitHubアカウントから、完成した指摘をPRへ1件のプレーンコメントとして投稿できます(承認やレビューそのものではありません)。

料金はPro・Maxプランに3回分の無料枠があります(アカウントごとの一度きりの割り当てで、リフレッシュしません)。それを使い切ると、利用クレジットとして1回あたりおおよそ5〜25ドルが課金されます。Team・Enterpriseプランには無料枠がありません。CIやスクリプトから非対話で動かすにはclaude ultrareviewサブコマンドを使います。--jsonで生の結果を、--timeout <分>でタイムアウトを、--post/--no-postでPRへの投稿有無を制御できます。レビューは通常5〜10分で完了し、/tasksから進行状況を確認したり途中で止めたりできます。

4つの経路は「軽さ」でなく「検証の強さ」で選ぶ組み合わせになっている

コストだけを見ると、ローカル/code-reviewが最も安く、ultrareviewが最も高いという単純な階段に見えます。ですが実際に変わっているのはコストより先に「指摘の信頼度」です。ローカルレビューはeffort levelを上げても1回の推論で終わります。一方でultrareviewは複数エージェントが候補を実コードで検証してから返すため、誤検知の少なさそのものが違う組み立てになっています。

したがって使い分けの軸は「重いか軽いか」ではありません。「その変更が、検証済みの指摘を待つコストに見合うか」です。日常の差分にはローカル/code-reviewを、フォークPRも含めた全社スクリーニングには管理Code Review機能を使います。そして認証・課金・データ破壊につながる変更のマージ直前にだけultrareviewを充てる、という3層の組み合わせが無理のない使い分けです。自作GitHub Actionsは、この3層のどれかを自分のCIパイプラインの都合(モデル指定、他ジョブとの依存関係)に合わせて作り直したいときの土台として使います。

まとめ

Claude Codeのコードレビューには、ローカル/code-review・自作GitHub Actions・管理Code Review機能・ultrareviewの4経路があります。どれか1つに統一する使い方ではありません。日常の差分確認はローカルで素早く済ませます。組織全体のPRスクリーニングは管理機能かGitHub Actionsで、マージ直前の最終確認だけをultrareviewに上げる、という重ね方が実務での落としどころです。

よくある質問

ultrareviewはGitHub Enterprise Serverでも使えますか

PRモードはgithub.comのリポジトリに加えて、管理者が接続したGitHub Enterprise Serverインスタンスのプルリクエストにも対応します。ブランチレビューはリポジトリ全体をアップロードする方式のため、この制約とは別に扱われます。

GitLabのCIパイプラインでも同じような自動レビューはできますか

管理Code Review機能自体はGitHub App前提でGitHub専用です。自分のCI基盤にClaudeを組み込む選択肢としては、GitHub Actionsに加えてGitLab CI/CDも用意されています。その場合は本稿の「自作ワークフロー」と同じ考え方で、GitLab側のパイプライン定義にレビューのステップを組み込みます。

レビューが失敗・タイムアウトしたらどうなりますか

管理Code Review機能のレビューはベストエフォートで、失敗しても自動では再試行されません。チェック実行のタイトルが「Code review encountered an error」または「Code review timed out」になります。結論は中立のままなので、マージはブロックされません。@claude reviewとコメントすれば、pushのトリガー登録を変えずに再実行できます。

個人開発でもultrareviewを使う価値はありますか

Pro・Maxプランには1アカウントあたり3回の無料枠があるため、個人開発でも認証まわりや課金ロジックの変更など、事故のコストが大きい差分に限って試す価値があります。日常的な差分には、無料枠を使い切らないローカル/code-reviewのほうが向きます。