コードレビューと ultrareview

Claude Code には、コードのバグを探す方法が3つあります。Team・Enterprise 向けに GitHub の pull request を自動でレビューする Code Review、手元の端末で差分を見る /code-review、クラウドで複数のエージェントが検証する ultrareview（/code-review ultra）です。

• Code Review：PR のコード行に重要度つきのインラインコメントを付ける、管理されたサービスです（研究プレビュー）
• /code-review：GitHub App を入れずに、端末で差分をレビューします。--fix で指摘を適用し、--comment で PR やマージリクエストへ投稿できます
• ultrareview：クラウドのサンドボックスで、報告前に各指摘を再現して検証します（研究プレビュー）
• 指摘の方針は、リポジトリの CLAUDE.md と REVIEW.md で調整できます
• セキュリティの脆弱性に絞った検査はセキュリティの検査にあります

自分の CI で Claude を動かしたいときは、GitHub ActionsかGitLab CI/CDを見てください。

Code Review（GitHub の PR の自動レビュー）#

Code Review は、GitHub の pull request を分析し、問題を見つけたコード行へのインラインコメントとして指摘を投稿します。専門化した複数のエージェントが、変更を、コードベース全体の文脈の中で調べ、論理エラー・セキュリティの脆弱性・壊れたエッジケース・見えにくい退行を探します。指摘には重要度が付き、PR を承認も阻止もしないので、既存のレビューの流れはそのままです。

レビューの仕組み#

Owner が組織で Code Review を有効にすると、リポジトリの設定に応じて、PR を開いたとき・push のたび・手動で求めたときにレビューが走ります。@claude review とコメントすると、どのモードでも PR のレビューが始まります。

レビューが走ると、複数のエージェントが Anthropic のインフラ上で、差分と周辺のコードを並列に分析します。各エージェントは別の種類の問題を探し、その後の検証の段階が、候補を実際のコードの挙動に照らして、誤検出を除きます。結果は重複を除いて重要度で並べられ、問題のあった行へのインラインコメントとして投稿され、レビュー本文に要約が付きます。問題がなければ、GitHub のチェック実行に問題が見つからなかったと表示します。短い確認のコメントを付けることもあります。コストは PR の大きさと複雑さで変わり、完了までは平均20分です。Owner は分析ダッシュボードで、レビューの活動と支出を見られます。

重要度#

指摘には、折りたたまれた「Why this was flagged」の節があり、展開すると、Claude がその問題を指摘した理由と、どう検証したかが読めます。

指摘への評価と返信#

Claude のレビューコメントには、👍 と 👎 があらかじめ付いて届くので、GitHub の画面で1クリックで評価できます。役に立った指摘は 👍、間違い・ノイズなら 👎 を押します。Anthropic は PR のマージ後にリアクションの数を集め、レビュアーの調整に使います。リアクションは再レビューを起こさず、PR の何も変えません。インラインコメントへの返信は、Claude の応答も PR の更新も促しません。指摘に対応するには、コードを直して push します。PR が push 起点のレビューに登録されていれば、問題が直ったとき、次の実行がスレッドを解決します。push せずに新しいレビューを求めるには、PR のトップレベルのコメントとして @claude review とコメントします。コードを変えずに指摘を却下するには、そのスレッドを解決します（返信では却下になりません）。

チェック実行の出力#

インラインのレビューコメントのほかに、各レビューは、CI のチェックと並ぶ「Claude Code Review」のチェック実行を埋めます。「Details」のリンクを展開すると、全指摘の要約が重要度順に1か所で見られます。

各指摘は、「Files changed」タブにも、該当の diff の行に直接付く注釈として出ます。Important は赤の印、Nit は黄の警告、既存のバグは灰色の通知で描かれます。注釈と重要度の表は、インラインのレビューコメントとは別にチェック実行へ書かれるので、動いた行へのインラインコメントを GitHub が拒否しても残ります。チェック実行は常に neutral の結論で完了するので、ブランチ保護のルールでマージを止めることはありません。Code Review の指摘でマージを制限したいときは、自分の CI で、チェック実行の出力から重要度の内訳を読みます。Details の文字の最後の行は、gh と jq で解析できる機械可読のコメントです。チェック実行 ID は、gh api repos/OWNER/REPO/commits/<commit-sha>/check-runs --jq '.check_runs[] | {id, name}' でそのコミットのチェック実行を一覧し、Claude Code Review の id を取ります。OWNER・REPO・CHECK_RUN_ID は、リポジトリの所有者・リポジトリ名・その ID に置き換えます。

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

これは、重要度ごとの件数を持つ JSON オブジェクト（例：{"normal": 2, "nit": 1, "pre_existing": 0}）を返します。normal のキーが Important の件数で、0 でなければ、マージ前に直す価値のあるバグが1つ以上見つかっています。

Code Review が調べること#

既定では、Code Review は正しさに絞ります。本番を壊すバグを探し、書式の好みやテストの網羅の不足は探しません。調べる範囲は、リポジトリへ案内のファイルを加えて広げられます。

Code Review を設定する#

Owner が、組織で1回 Code Review を有効にし、含めるリポジトリを選びます。

1. Claude Code の管理設定を開く：claude.ai/admin-settings/claude-code で Code Review の節を見つける。Claude の組織の Owner か Primary Owner の役割と、GitHub の組織に GitHub App をインストールする権限が要る
2. 「Setup」をクリックする：GitHub App のインストールの流れが始まる
3. Claude GitHub App をインストールする：画面に従い、レビューしたいリポジトリを持つ GitHub の組織を選び、アプリがアクセスできるリポジトリを選び、求められる権限を承認する。PR をレビューするため、Claude はアプリの読み取りアクセスでリポジトリの内容を読み、pull request とチェックへの書き込みアクセスで、コメントとチェック実行を投稿する。インストール時には、GitHub Actions など、ほかの Claude の機能と共有する、より広い権限の組を許可する（GitHub Actionsに全権限の一覧がある）
4. リポジトリを選ぶ：Code Review を有効にするリポジトリを選ぶ。リポジトリが見えなければ、インストール時に Claude GitHub App へそのリポジトリへのアクセスを与えたかを確かめる。あとからリポジトリを足せる
5. リポジトリごとにレビューの引き金を決める：設定の後、Code Review の節にリポジトリが表で出る。リポジトリごとに、「Review Behavior」のドロップダウンで、レビューがいつ走るかを選ぶ

どれを選んでも、フォークからの pull request は、誰かが @claude review とコメントしたときだけレビューします。push のたびのレビューは、最も多くのレビューが走り、コストも最大です。Manual は、アクセスの多いリポジトリで、特定の PR だけレビューに入れたいとき、または自分の PR を準備が整ってからレビューし始めたいときに役立ちます。リポジトリの表には、最近の活動に基づく、リポジトリごとの1レビューあたりの平均コストも出ます。行の操作メニューで、リポジトリごとに Code Review をオン・オフするか、リポジトリを外せます。

セットアップを確かめるには、テストの PR を開きます。自動の引き金を選んだなら、数分以内に「Claude Code Review」というチェック実行が現れます。Manual なら、PR に @claude review とコメントして最初のレビューを始めます。チェック実行が現れないときは、リポジトリが管理設定に載っていることと、Claude GitHub App がそこへアクセスできることを確かめます。

手動でレビューを起動する#

コメントのコマンドは、求めに応じてレビューを始めます。リポジトリの引き金の設定に関わらず動くので、Manual モードで特定の PR をレビューに入れる、ほかのモードで、すぐ再レビューを得る、といった使い方ができます。

以後の push のたびに新しいレビューを始めたいとき（Manual モードのリポジトリの優先度の高い PR など）は、@claude review always を使います。素のコマンドは PR を登録しないので、後の push がレビューを起こすかを変えずに、1回だけセカンドオピニオンを求められます。

これらのコマンドがレビューを起こす条件は次のとおりです。

• diff の行へのインラインコメントではなく、PR のトップレベルのコメントとして投稿する
• コマンドをコメントの先頭に置き、once や always はコマンドの残りと同じ行に書く
• リポジトリへの write・maintain・admin の権限が要る
• PR が open である

リポジトリが組織のもので、その組織でのメンバーシップが非公開（GitHub の既定）だと、GitHub は Claude にあなたをメンバーと伝えません。Claude がコメントに 👀 で反応しても、チームや組織の基本権限で write アクセスがあっても、リポジトリに直接コラボレーターとして追加されていない限り、レビューを始めません。直すには、組織のメンバーシップを公開にするか、リポジトリの管理者にコラボレーターとして追加してもらいます。自動の引き金と違い、手動の引き金はドラフトの PR でも動きます（明示の求めは、ドラフトかどうかに関わらず今レビューしたい意思を示すため）。その PR ですでにレビューが走っていれば、求めは進行中のレビューが完了するまでキューで待ちます。進み具合は PR のチェック実行で見られます。

フォークからの PR のレビュー#

Claude は、リポジトリの「Review Behavior」の設定に関わらず、フォークからの pull request を自動ではレビューしません。始めるには、pull request に @claude review とコメントします。コメントのコマンドの条件は同じで、要る write アクセスは、フォークでなくベースのリポジトリへのものです。フォークの pull request の再レビューには、新しい @claude review のコメントを投稿します。@claude review always も使えますが、pull request を以後の push のレビューには登録しません。コメントのコマンド以外に、フォークの pull request のレビューを始めるものはありません。

• チェック実行の「Re-run」をクリックしても、レビューは始まらない
• 新しいコミットを push しても、「After every push」のリポジトリでも、レビューは始まらない

レビューをカスタマイズする#

Code Review は、何を指摘するかの案内として、リポジトリの2つのファイルを読みます。レビューへの効き方の強さが違います。

• CLAUDE.md：レビューだけでなく、Claude Code のすべての作業が使う共有のプロジェクトの指示。Code Review はプロジェクトの文脈として読み、新しく入った違反を Nit として指摘する
• REVIEW.md：レビュー専用の指示。指摘を見つけて検証するエージェントに渡され、順位付けと報告をするエージェントが参照する。チームが何を指摘してほしいか、どの重要度か、指摘をどう報告するかを書く

CLAUDE.md#

Code Review は、リポジトリの CLAUDE.md を読み、新しく入った違反を Nit レベルの指摘として扱います。これは双方向で、PR が CLAUDE.md の記述を古くするコードの変更をしたら、Claude はドキュメントの更新も要ると指摘します。Claude は、ディレクトリ階層のあらゆるレベルの CLAUDE.md を読むので、サブディレクトリの CLAUDE.md の規則は、そのパスの下のファイルにだけ適用されます。CLAUDE.md の仕組みはCLAUDE.md とメモリを参照してください。一般の Claude Code のセッションには適用したくないレビュー専用の案内は、代わりに REVIEW.md を使います。

REVIEW.md#

REVIEW.md は、リポジトリのルートに置いて、Code Review をそのリポジトリに合わせるファイルです。レビューの流れの中で、指摘を見つけて検証するエージェントは、この内容を、Code Review の既定のレビューの案内と並べて、リポジトリのレビュー指示として受け取ります。指摘を順位付けして報告するエージェントも、重要度を決めてレビューを書く前に参照します。強制したい規則は REVIEW.md に直接書きます。

REVIEW.md は自由形式の Markdown で、レビューの指示として書けるものは何でも範囲内です。実際に効果の大きい型は次のとおりです。

• 重要度：🔴 Important の意味をリポジトリに合わせて定義し直す。既定の調整は本番コード向けなので、ドキュメントのリポジトリ・設定のリポジトリ・試作は、ずっと狭い定義がよいことがある。どの種類の指摘が Important で、どれが Nit どまりかを明示する。逆向きに上げることもでき、たとえば CLAUDE.md の違反を、既定の Nit でなく Important として扱う
• Nit の量：1回のレビューが投稿する 🟡 Nit のコメントの数に上限を付ける。文章や設定のファイルは、いつまでも磨ける。「Nit は最大5件まで、残りは要約に件数として書く」のような上限が、レビューを実行可能に保つ
• 飛ばす規則：Claude が指摘を出さないパス・ブランチのパターン・指摘のカテゴリを並べる。よくある候補は、生成コード・ロックファイル・ベンダーの依存・機械が書いたブランチと、lint やスペルチェックのように CI がすでに強制するもの。多少のレビューは要るが厳密には要らないパスは、飛ばさず、基準を上げる（「scripts/ では、ほぼ確実で重大なときだけ報告する」）
• リポジトリ固有のチェック：毎回の PR で指摘させたい規則を足す（「新しい API ルートには結合テストが要る」）。REVIEW.md は指摘と検証のエージェントのすべてに直接届くので、長い CLAUDE.md の中の同じ規則より確実に効く
• 検証の基準：ある種類の指摘を投稿する前に、証拠を求める（「挙動の主張には、命名からの推測でなく、ソースの file:line の引用が要る」）。作者に往復の手間をかけさせる誤検出を減らせる
• 再レビューの収束：すでにレビュー済みの PR で、Claude がどう振る舞うかを伝える。「最初のレビューの後は、新しい Nit を抑え、Important の指摘だけを出す」という規則が、1行の修正が、書式だけで7回目のラウンドへ進むのを止める
• 要約の形：レビュー本文を 2 factual, 4 style のような1行の集計で始め、事実の問題がなければ「no factual issues」を先頭に置くよう求める。作者は、詳細の前に、作業の形を知りたい

次の REVIEW.md は、バックエンドのサービス向けに重要度を調整し、Nit に上限を付け、生成ファイルを飛ばし、リポジトリ固有のチェックを足します。

# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Cap the nits

Report at most five Nits per review. If you found more, say "plus N
similar items" in the summary instead of posting them inline. If
everything you found is a Nit, lead the summary with "No blocking
issues."

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant

使用状況を見る#

claude.ai/analytics/code-review で、組織全体の Code Review の活動が見られます。ダッシュボードには次が出ます。

ダッシュボードのコストの数字は、活動を見るための推定です。請求書と同じ正確な支出は、Anthropic の請求を見ます。

料金#

Code Review はトークンの使用量で課金されます。1レビューの平均コストは15〜25ドルで、PR の大きさ・コードベースの複雑さ・検証が要る問題の数で変わります。Code Review の使用は、使用量クレジット（usage credits）で別に請求され、プランに含まれる使用量には数えられません。選ぶレビューの引き金が、総コストに影響します。

• Once after PR creation：PR ごとに1回走る
• After every push：push のたびに走り、コストが push の回数だけ増える
• Manual：開いたときや push ではレビューがなく、誰かが求めたレビューからだけコストが発生する

Once after PR creation か Manual モードでは、@claude review always とコメントすると PR が push 起点のレビューに入り、そのコメント以降は push ごとに追加のコストが発生します。After every push モードでは、push がすでにレビューを起こすので、この登録は push あたりのコストを変えません。@claude review は、以後の push に登録せず、1回のレビューを走らせます。フォークの pull request は、誰かが @claude review とコメントしたときだけレビューされるので、どのモードでも push ごとのコストは発生しません。

組織が他の Claude Code の機能で Amazon Bedrock や Google Cloud の Agent Platform を使っていても、コストは Anthropic の請求に出ます。Code Review の月ごとの支出の上限は、claude.ai/admin-settings/usage で、Claude Code Review のサービスの上限を設定します。支出は、分析の週ごとのコストのグラフか、管理設定のリポジトリごとの平均コストの列で見ます。

トラブルシューティング#

レビューの実行はベストエフォートで、失敗した実行が PR を阻止することはありません。Code Review は、中断された一部のレビューを自分で再試行します。この節は、自分でレビューを再実行する方法と、チェック実行が報告する問題が見つからないときの探し場所です。

• 失敗した、またはタイムアウトしたレビューを再実行する：レビューが失敗した、または制限時間を超えると、チェック実行は「Code review failed」や「Code review timed out」のようなタイトルで完了します。結論は neutral のままなので、マージは止まりません。チェック実行の要約が、そのコミットの新しいレビューが自動でキューに入ったと書いていない限り、自分でレビューを再実行します。PR に @claude review とコメントすると、PR を以後の push に登録せず、新しいレビューが始まります。PR がフォークからのものでなければ、GitHub の Checks タブで「Claude Code Review」のチェックの「Re-run」をクリックしても再実行でき、これも PR を登録せず新しいレビューを始めます
• レビューが走らず、PR に予算のメッセージが出る：組織の Code Review の月ごとの支出の上限に達した、または使用量クレジットの残高を使い切ると、Code Review はレビューを飛ばし、PR にコメントを1つ投稿します。コメントとチェックランのカードの両方が、原因と、管理者が直す管理ページのリンクを示します
  • 支出の上限に達した：次の請求期間の初めに、または管理者が claude.ai/admin-settings/usage で上限を上げるとすぐ、レビューが再開する
  • 使用量クレジットを使い切った：管理者が claude.ai/admin-settings/usage で使用量クレジットを足すと、レビューが再開する
• インラインコメントとして出ない指摘を探す：チェック実行のタイトルが問題を見つけたと言うのに、diff にインラインのレビューコメントがないときは、指摘が出るほかの場所を見ます。チェック実行の Details（Checks タブの Claude Code Review のチェックの横の「Details」。インラインコメントが受理されたかに関わらず、重要度の表がすべての指摘をファイル・行・要約で並べる）、Files changed の注釈（「Files changed」タブで、指摘がレビューコメントとは別に diff の行に付く注釈として出る）、レビュー本文（レビューの実行中に push すると、指摘の一部が、現在の diff にもうない行を指すことがあり、それらはインラインコメントではなく、レビュー本文の「Additional findings」の見出しの下に出る）

手元の差分をレビューする#

/code-review コマンドは、GitHub App を入れずに、端末で差分をレビューします。正しさのバグを報告します。モデルと effort レベルによっては、再利用・単純化・効率の整理の余地もレビューします。/review は /code-review の別名です（v2.1.223 より前は、GitHub の pull request を対象に1回の読み取り専用のレビューを行う別のコマンドでした）。

1. /code-review を実行する：作業しているセッションからコマンドを実行する。ブランチの上流より先のコミットと、コミット前の変更をレビューするので、ブランチか作業ツリーに作業がないと、報告するものがない。別のものをレビューするには、対象を渡す（ファイルのパス・PR 番号・ブランチ名・main...my-feature のような ref の範囲）
2. 作業を続ける：レビューは、独自のコンテキストの窓を持つバックグラウンドのサブエージェントとして走るので、会話を埋めない。レビューが完了すると、指摘が会話に届く
3. 指摘に対応する：レビューが見つけたものを直すよう Claude に頼む。--fix か --comment を渡していれば、レビューが指摘をすでに適用、または投稿している

/code-review

フラグも加えられます。

GitLab のマージリクエストへの --comment では、Claude Code は GitLab の glab CLI で指摘を投稿します（v2.1.257 以降）。glab が入っていないときは、Claude が指摘を端末に出力します。マージリクエストは URL か !123 の形で渡します。Claude Code は、素の番号やブランチ名を、チェックアウトの origin が gitlab.com にあるときだけマージリクエストとして扱います。セルフマネージドの GitLab では、URL か !123 の形で渡します。

Claude が指摘を、返信の中のテキストとして報告するのは、次の2つの実行で、ホストアプリが指摘のリストを求めていても同じです。

• 端末のセッション：/code-review がレビューをフォークしたサブエージェントとして動かす
• テキストか JSON の出力の -p の実行

指摘のリストを求めるホストアプリ（デスクトップアプリなど）では、Claude は代わりに ReportFindings ツールでレビューの指摘を報告します。Claude Code はそれを指摘のリストとして描き、各項目はファイルの場所・1文の要約・correctness のようなカテゴリのタグ（指摘に付いているとき）を示します。ホストの求めは、すべての effort レベルで適用され、v2.1.218 以降が必要です。セッションの後で Claude が報告された指摘を直すと、再び報告し、Claude Code は更新された指摘のリストの各項目に、修正済み・見送り・変更不要の印を付けます。

レビューが読む・編集するもの#

レビューは、ほかの Claude Code のセッションと同じく CLAUDE.md に従いますが、REVIEW.md は読みません。バックグラウンドのレビューは、--fix の編集を、セッションのチェックポイントの外で適用するので、/rewind では取り消せません（git で戻します）。レビューがフォアグラウンドで走るときは、自分のターンの間に作業ツリーを編集するので、/rewind がその編集を通常どおり復元します。チェックポイントの詳細はチェックポイントと巻き戻しにあります。

effort と引数を調整する#

effort レベルを渡して、網羅と確信のどちらを取るかを調整します。low と medium では、いちばん確信のある指摘だけを報告するので、誤検出が少なくなります。high から max は網羅を広げ、レビューがそれほど確信していない指摘も含むことがあります。レベルを入力しないと、レビューは、以前のセッションのものでも、最後に入力した low から max のレベルを再利用し、Claude Code は Reusing high effort, the level you typed last time のような通知を出します。後の実行が再利用するレベルを変えるには、/code-review high のようにレベルを入力します（非対話の -p の実行で渡したレベルは更新しません）。ultra は、記憶したレベルを更新も使用もしません。レベルを入力したことがなければ、レビューはセッションの現在の effort を使います（v2.1.223 より前は、レベルなしの /code-review は常にセッションの現在の effort を使っていました）。effort レベルとフラグの後の、行の残りは、2通りに読まれます。

• ultra なし：残りはすべてレビューの対象になり、別のコマンド名で始まっていても同じ。/code-review /fix-issue 123 は、/fix-issue を2つ目の重ねたスキルとして読み込まず、/fix-issue 123 を対象のテキストとしてレビューする（v2.1.218 より前は、/code-review の後に重ねたコマンドが、独立したスキルとして展開された）
• ultra あり：Claude Code は、1語をベースのブランチか PR 番号として読み、ブランチや PR を指さない長めのテキストを、レビューに付くメモに変える。/code-review ultra check my auth changes は現在のブランチをレビューし、Claude が指摘をメモに関連づける

フォアグラウンドで動かす#

レビューは既定でバックグラウンドで動きます（v2.1.218 より前は、会話の中で動いていました）。次のような場合は、代わりにフォアグラウンドで動きます。

• 前のレビューがまだ進行中に、もう一度 /code-review を実行した
• -p フラグや Agent SDK の非対話モードで実行した。Claude Code はレビューを待ち、指摘を応答に含める（ただし ultra は、待たずにクラウドレビューを起動する）
• CLAUDE_CODE_DISABLE_BACKGROUND_TASKS を 1 にした（ほかのバックグラウンドタスクの機能もすべて切れる）

Claude にレビューを始めさせる#

Claude は /code-review を自分で始められます。変更をレビューするよう普通の言葉で頼むと、コマンドを打たなくてもスキルを動かせ、/code-review をプロンプトにした定期実行のタスクも、レビューを実行します。定期実行のタスクはクラウドレビューを起動しないので、ultra の引数なしの /code-review を定期実行にします（定期実行は定期実行と /loopを参照）。Claude と定期実行のタスクがレビューを始めないようにしつつ、自分で打つ /code-review は使えるままにするには、~/.claude/settings.json などの設定ファイルに skillOverrides の項目を加えます。

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

v2.1.246 より前は、Claude が /code-review を自分で始めるのは、Anthropic から取得するフィーチャーフラグが有効にしたセッションだけでした。フィーチャーフラグを取得しないセッションでは、/code-review は自分で打ったときだけ動き、定期実行の /code-review は、プレーンテキストとして Claude に届きました。

ultrareview へ上げる#

/code-review ultra --fix は、クラウドでより深い ultrareview を動かし、指摘がセッションへ戻ったときに、作業ツリーへ適用します。ultrareview は独自の範囲を使います：現在のブランチとリポジトリのデフォルトブランチの比較に、作業ツリーのコミット前とステージ済みの変更を加えたものです。.env や *.tfvars のように、認証情報や鍵のような名前のファイルのコミット前の変更は、ローカルのリポジトリをクラウドセッションへアップロードする規則に従います。別のベースと比べるには、/code-review ultra develop のようにブランチ名を渡します。対象が github.com の pull request なら、完了した指摘を、自分の GitHub アカウントからのコメントとして PR へ投稿できます（v2.1.227 以降）。

スクリプトや CI のジョブからクラウドレビューを動かすには、指摘を待って標準出力に出す claude ultrareview サブコマンドを使います。

このコマンドは、v2.1.147 より前は /simplify という名前で、既定で修正を適用していました。/simplify は今、バグを探さず修正を適用する、整理だけの別のレビューを動かします。バグ探しに /simplify をスクリプトにしていたなら、/code-review --fix に切り替えます。コマンドの全体はスラッシュコマンド一覧を参照してください。

ultrareview（クラウドの深いレビュー）#

ultrareview は、Anthropic のインフラ上のクラウドセッションとして動く、深いコードレビューです。/code-review ultra を実行すると、Claude Code が、クラウドのサンドボックスでレビュアーのエージェントの群れを起動し、ブランチや pull request のバグを探します。手元の /code-review と比べると、次の点が違います。

• 高い精度：報告されるすべての指摘が、独立に再現されて検証されるので、結果は、スタイルの提案ではなく本物のバグに絞られる
• 広い網羅：より大きなレビュアーのエージェントの群れが、変更を並列に探すので、手元のレビューが見逃しうる問題が出る
• 手元のリソースを使わない：レビューは完全にクラウドのサンドボックスで走るので、動いている間、端末はほかの作業のために空いている

ultrareview は、Anthropic のインフラ上のクラウドセッションとして動くので、claude.ai のアカウントでの認証が要ります。API キーだけでサインインしているなら、先に /login で claude.ai で認証します。

CLI から ultrareview を動かす#

どの git リポジトリからでも、レビューを始められます。

/code-review ultra

引数なしでは、現在のブランチとデフォルトブランチの差分（コミット前とステージ済みの変更を含む）をレビューします。ブランチのレビューでは、Claude Code がリポジトリの状態を束ねて、ローカルのリポジトリをクラウドセッションへアップロードするときの規則（クラウド（Web）で使う）に従って、クラウドのサンドボックスへアップロードします。その規則は、サイズの上限・チェックアウトの要件・.env や *.tfvars のような認証情報や鍵の名前のファイルに未コミットの変更があるときの扱いを定めています。pull request をレビューするときは、手元から何もアップロードしません。起動の前に、Claude Code が確認ダイアログを出し、レビューの範囲・残りの無料枠・推定コストを示します（ブランチのレビューでは、範囲にファイルと行の数も含まれる）。確認すると、レビューはバックグラウンドで続き、その間もセッションを使い続けられます。このコマンドは /code-review ultra で自分が呼んだときだけ動き、Claude が自分で ultrareview を始めることはありません。

別のベースと比べる#

デフォルトブランチ以外のベースと比べるには、ブランチ名を渡します。次の例は、現在のブランチを develop と比べます。

/code-review ultra develop

ベースのブランチは、手元のクローンになくても構いません。Claude Code が origin から取得します。名前に打ち間違いがあると、Claude Code はエラーの中で、いちばん近いブランチ名を示します。コミット ID やタグもベースにでき、その場合は、そのコミット以降のブランチの変更をレビューします。

pull request をレビューする#

ローカルのブランチでなく GitHub の pull request をレビューするには、PR の番号を渡します。

/code-review ultra 1234

コマンドは、#1234・PR 1234・貼り付けた PR の URL も受け付けます（貼り付けた URL は、現在のディレクトリのリポジトリを指す必要がある）。PR モードでは、クラウドのサンドボックスは、手元の作業ツリーを束ねる代わりに、ホストから pull request を直接クローンします。PR モードは、github.com のリポジトリと、Owner が Claude Code に接続した GitHub Enterprise Server のインスタンスで動きます。github.com のリポジトリでは、サンドボックスは、Claude アカウントに接続した GitHub アカウントでクローンするので、そのアカウントが PR のリポジトリを読める必要があります。/web-setup を実行して、GitHub CLI のログインを Claude アカウントへ接続します。

指摘を pull request へ投稿する#

v2.1.227 以降で github.com の pull request をレビューするとき、完了した指摘を、自分の GitHub アカウントからの1つのプレーンなコメントとして PR へ投稿させられます。コメントはレビューでも承認でもなく、「Generated by Claude Code」の注記で終わります。ブランチや GitHub Enterprise Server の pull request をレビューするときは、Claude Code は指摘をセッションにだけ表示します。Claude Code は、その実行で選ばない限り投稿せず、--no-post が既定です。投稿は実行ごとに選びます。

• 対話：起動ダイアログで「Run and post the findings to the PR as me」を選ぶ。/code-review ultra 1234 --post のようにコマンドに --post を足すと、その選択が事前選択され、起動前に確認も入る
• 非対話：claude ultrareview サブコマンドを --post で実行する。フラグ付きでサブコマンドを実行することが投稿への同意なので、確認なしで投稿する。claude -p '/code-review ultra' の実行では、指摘が届く前に Claude Code が終了するので、何も投稿しない。サブコマンドを使う

Claude Code は手元から投稿しません。レビューのセッション ID を Anthropic の API へ送り、API が、保存されているレビューの指摘を、Claude に接続した GitHub アカウント経由でコメントとして投稿します。投稿には、レビュー自体と同じ claude.ai のサインインが要り、サードパーティのプロバイダーや CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を設定したときは使えません。対話セッションでは、指摘が届いたときに Claude Code が投稿を始めるので、レビューが終わるまでセッションを開いたままにします。Claude Code は投稿の選択をそのセッションの中にだけ保ちます。レビューが終わる前にセッションが終わると、後で会話を再開しても、何も投稿しません。投稿が終わると、Claude が結果を伝えます。

• Posted：Claude がコメントへのリンクを示す
• Already posted：同じレビューの以前の投稿が、すでに PR にコメントを入れているので、Claude は再投稿せず、pull request へのリンクを示す
• Failed：Claude が理由を伝え、指摘は端末に残るので、手で投稿できる

普通の言葉で依頼を渡す#

v2.1.218 以降では、取り組んでいることを普通の言葉で説明することもできます。

/code-review ultra check my auth changes

レビューの範囲は、引数なしと同じ、現在のブランチです。Claude はテキストをメモとして保ち、起動ダイアログに示し、指摘が届いたとき、それに関連づけます。Claude Code がテキストをメモとして扱うのは、1語より長く、ブランチ名でも PR の参照でもないときだけです。1語はブランチ名か PR の参照として読むので、打ち間違えたブランチ名は、メモつきで起動せず、「別のベースと比べる」のいちばん近いブランチのエラーになります。check PR 123 again のように、PR の参照とほかの語を組み合わせると、Claude Code はどちらも起動せず、その PR をレビューするなら PR 番号だけで、現在のブランチをレビューするなら参照なしで、もう一度実行するよう求めます。

差分の上限とフォールバック#

ultrareview は、レビューの作業が走る前に差分を確かめ、そのままではレビューできないときに伝えます。

• 差分が大きすぎる：ブランチのレビューは、既定で最大500の変更ファイルと8,000の変更行を含められる。正確な値は変わることがあり、拒否のメッセージが、有効な値・差分の大きさ・変更行がいちばん多いファイルを挙げる。大きすぎる pull request も、同じように拒否し、ファイルと行の数は挙げるが、ファイルごとの内訳は出さない
• レビューするものがない：ベースとの差分が空のとき、ultrareview は拒否し、比べたブランチかコミットと、いまの場合（コミット前の変更なしでベースのブランチ自身にいる、コミットがすべてすでにベースに含まれるブランチ、など）を示す。その場合の逃げ道（作業のあるブランチへ切り替える、手元の編集をステージかコミットする、別のベースを渡す、など）も示す
• 最初のコミット：リポジトリの最初のコミットには比べる以前のものがないので、ultrareview は、起動ダイアログで確認した後、その中のすべてのファイルをレビューする。追跡されていないファイルがあると、代わりに拒否し、レビューしたいものを git add するよう伝える。同じ大きさの上限が適用される。最初のコミットが丸ごとレビューされるのは、その確認の後だけなので、claude ultrareview サブコマンドと claude -p は、それを拒否し、対話セッションへ誘導する。v2.1.277 以降
• マージベースがない：ブランチがベースのブランチと履歴を共有しない、またはリポジトリに比べるベースのブランチがないとき、ultrareview は、リポジトリの追跡されているすべてのファイルをレビューする。このフォールバックには完全なクローンが要り、同じ大きさの上限が適用される。起動ダイアログで確認するか、自分で claude ultrareview サブコマンドを実行したときだけ起動する。claude -p など、どちらも起きない場面では、ultrareview は拒否し、レビューがすべてのファイルに及ぶことを伝えて、対話セッションへ誘導する。FETCH_HEAD をチェックアウトして作った detached HEAD のように、ブランチやほかの ref がないチェックアウトでは、Claude Code はレビューを拒否し、先にブランチを作るよう提案する

料金と無料枠#

ultrareview は、プランに含まれる使用量ではなく、使用量クレジットで請求される、プレミアム機能です。

• 無料枠：Pro と Max の3回は、アカウントごとに1回だけの割り当てで、更新されない
• 1レビューあたりのコスト：無料枠を使い切った後は、変更の大きさにより、通常5〜25ドルの使用量クレジット。各実行の前に起動ダイアログが示す推定と一致する
• 実行に数えられるとき：クラウドセッションが始まったとき。途中で止めた、または完了しなかったレビューも無料の1回を使い、有料のレビューは、動いた分だけ請求される

無料枠のほかでは、ultrareview は常に使用量クレジットで請求されるので、有料のレビューを起動するには、アカウントか組織で使用量クレジットを有効にしておく必要があります。使用量クレジットが有効でないと、Claude Code は起動を止めます。自分のアカウントの課金を管理できるなら、Claude Code が、使用量クレジットを有効にできる課金設定へのリンクを示します。

/usage-credits を実行して、使用量クレジットの設定を確かめる・変えることもできます。使用量クレジットの請求の確認は、会話ごとに1回求められます。/clear などで新しい会話を始めると、次の有料のレビューのときに、もう一度確認が出ます。コストの扱いはコストを抑えるを参照してください。

動いているレビューを追う#

レビューは、通常5〜10分かかります。バックグラウンドタスクとして動くので、セッションで作業を続ける、ほかのコマンドを始める、のどちらもできます。指摘を pull request へ投稿する選択をしたなら、レビューが終わるまでセッションを開いたままにします（先にセッションが終わると、Claude Code は何も投稿しません）。/tasks で、実行中と完了したレビューを見る、レビューの詳細を開く、進行中のレビューを止める、ができます。レビューを止めると、Claude Code はクラウドセッションをアーカイブし、途中の指摘は返しません。Claude は、レビューが止まった、またはセッションが見つからなかったとも伝えます。

• レビューのクラウドセッションが、レビューが終わる前に claude.ai で止められた、またはアーカイブされたとき：Claude は止まったと伝える
• レビューのクラウドセッションが削除された、または起動してから別の Claude のアカウントや組織にサインインしたとき：Claude は、セッションが見つからないと伝える
• アカウントを切り替えたとき：レビューは、始めたアカウントのもとで終わる可能性がある。まだ動いているなら、そのアカウントでサインインし直し、claude --resume で会話を再開して、再びアタッチする

レビューが終わると、Claude Code は検証された指摘を、セッションに通知として示します。各指摘にはファイルの場所と問題の説明が付くので、直接 Claude に直すよう頼めます。

ultrareview を非対話で動かす#

claude ultrareview サブコマンドで、対話セッションなしに、CI やスクリプトから ultrareview を始められます。サブコマンドは /code-review ultra と同じレビューを起動し、リモートのレビューが終わるまでブロックして、指摘を標準出力に出します。

claude ultrareview
claude ultrareview 1234
claude ultrareview origin/main

引数なしでは、現在のブランチとデフォルトブランチの差分をレビューし、マージベースがないときは、/code-review ultra と同じ全体のフォールバックを使います。PR 番号で pull request を、ベースのブランチでそれとの比較をレビューします。ベースのブランチの扱いは、対話のコマンドと同じです。サブコマンドを実行すると、全体のフォールバックと、請求と規約のプロンプトに同意したことになり、入力を待たずに実行が始まります。自分で実行することが、同意と数えられます。Bash ツールなどを通して Claude がサブコマンドを実行する場合は、Claude Code は全体のレビューを拒否します。

claude -p '/code-review ultra' では指摘が得られないので、スクリプトでは claude ultrareview を使います。-p の実行はクラウドレビューを起動して、待たずに終了します。レビューが使用量クレジットを請求するときは、-p の実行は起動せずに止まります。v2.1.218 より前は、非対話のセッションの /code-review ultra はローカルのレビューを動かしていました。claude ultrareview は進捗のメッセージを stderr に出すので、stdout は解析できる形のままです。出力・タイムアウト・指摘の投稿は、次のフラグで制御します。

claude ultrareview の実行には、/code-review ultra と同じ認証と使用量クレジットの設定が要ります。サブコマンドは、3つの終了コードのどれかで終わります。

指摘が届く前にサブコマンドが終わると、指摘は端末に届きません。レビューはクラウドで動き続けていることがあります。サブコマンドをもう一度実行すると、そのレビューを再開せず新しいレビューが始まり、それは無料枠を使うか使用量クレジットで請求されます。--post を付けると、サブコマンドは、指摘を出力した直後に投稿を始め、リンクを stderr に出力します。実行が失敗した・止められた・タイムアウトしたときは、投稿しません。レビューは完了したがコメントが投稿されなかったときは、Claude Code が理由を stderr に出力し、指摘は stdout に残るので、手で投稿できます。GitHub の pull request の自動レビューには、リポジトリに直接つながる Code Review が、CLI の手順なしに、指摘をインラインの PR コメントとして投稿します。

/code-review と ultrareview の比べ#

どちらもコードを調べますが、作業の流れの中で使う段階が違います。

作業中の素早いフィードバックや、承認する前に同僚の pull request をレビューするには、PR 番号を渡して /code-review を使います。手元のレビューが見逃しうる問題を拾う深い確認がほしい、大きな変更のマージの前には、/code-review ultra を使います。クラウドセッションの仕組みはクラウド（Web）で使うにあります。