自分の書いたものを自分でレビューするのは無理があります。書いた直後は、書いた理由のほうが頭に残っているからです。
Claude Codeの /code-review は手元の差分をレビューさせるコマンドです。これがv2.1.218から裏で走る形に変わり、使い勝手が変わったのでまとめます。
バージョンで挙動が変わる話が多いので、先に自分の環境を確認しておいてください。
claude --version
会話が埋まらなくなった
以前は、レビューが自分の会話の中で実行されていました。結果と、途中で読んだファイルの内容が全部同じ会話に積まれる。長い差分をレビューさせると、それだけで文脈が埋まっていました。
v2.1.218からは、レビューが独立した文脈を持つサブエージェントとして裏で動きます。サブエージェントは、Claude Codeが作業を手分けするために呼び出す下請けのことです。レビューが読み込んだものは向こうの文脈に入り、こちらには結果だけが返ります。
つまり投げたあと自分の作業を続けられ、終わったタイミングで結果が現れます。
何もつけずに打つと何が対象になるか
/code-review だけで打つと、いまのブランチ(作業の枝分かれ単位)が上流より進んでいる分のコミットと、まだコミットしていない変更が対象になります。上流とは、GitHubなどに置いてある共有側の状態です。まだ何も変えていない状態で打つと、見るものがありません。
対象は指定もできます。ファイルのパス、プルリクエスト(変更を取り込んでほしいという申請)の番号、ブランチ名、あるいは main...my-feature のような範囲。最後のものは「mainから枝分かれしたあとに my-feature 側で入った変更だけ」という指定です。私はブランチ名を渡す使い方が多く、他人の作業ブランチを読むときに便利でした。
フラグは2つ。--fix は見つかった点を作業ツリー(いま手元で編集しているファイルそのもの)に適用し、--comment は該当する行に紐づくコメントとしてプルリクエストへ投稿します。
直された内容が /rewind で戻らない
ここが今回いちばん引っかかった点です。
裏で走るレビューが --fix で直した内容は、セッションのチェックポイントの外で適用されます。チェックポイントは /rewind で巻き戻すための記録ですが、サブエージェントの編集は含まれません。
つまり --fix の結果を取り消したいとき、/rewind では戻りません。gitで戻すことになります。まず git diff で何が変わったかを見て、戻したいファイルを指定するのが安全です。
git restore <ファイル名>
git restore . とすると、いまいるフォルダ以下の変更をまとめて捨てられます。ただしコミット対象に選んである変更や、新しく作られたファイルはこれでは戻りません。私は最初これを知らずに /rewind を打ち、何も戻らないので混乱しました。裏で走るとは、そういう副作用も含むということでした。
手前で走らせた場合は別で、通常どおり /rewind で戻せます。
裏ではなく手前で走る条件
既定は裏ですが、手前で走る場合もあります。
前のレビューが終わらないうちに もう一度打った場合。-p フラグを使う対話なしの実行。それと CLAUDE_CODE_DISABLE_BACKGROUND_TASKS を 1 にしている場合です。最後のものは裏で走る機能をすべて止める環境変数なので、意図せず設定していると「裏で走らない」結果になります。確かめ方はこうです。
echo $CLAUDE_CODE_DISABLE_BACKGROUND_TASKS
何も出なければ、少なくともシェル側では設定されていません。~/.claude/settings.json の env に書いている場合はこの方法では出ないので、そちらも見てください。
もう1つ、定時実行の対象にはできません。 自分で呼ぶ前提のコマンドなので、定時実行の指示文に書いてもただの文字として読まれます。
effortで件数と確信度が変わる
レビューの深さは effort という設定で変えられます。コマンドのあとに続けて書きます。
/code-review high
low と medium では確信度の高い指摘だけが返り、high 以上になると網を広く張って、確信の薄いものも含むようになります。
細かく見てほしいときは高く、誤検知に付き合いたくないときは低く。私は普段 medium で回し、リリース前だけ上げています。指定しなければセッションの設定を引き継ぎます。
読むファイルの範囲に癖がある
レビューは通常のセッションと同じように CLAUDE.md を読みます。プロジェクトの決まりごとをClaudeに読ませるファイルで、ここに書けばそれに沿って指摘してくれます。
一方で、REVIEW.md は読みません。 GitHubのプルリクエストを自動レビューする機能のほうで使うファイルなので、手元の /code-review は対象外です。手元に効かせたいルールは CLAUDE.md 側に書きます。
CLAUDE.md の書き方そのものは、こちらにまとめています。
クラウドの深いレビューに引き上げる
/code-review ultra を打つと、クラウド側の深いレビューに切り替わります。
対象の範囲が変わる点だけ押さえてください。こちらは現在のブランチをリポジトリの既定ブランチと比べる形で、コミットしていない変更とコミット対象に選んである変更も見ます。またclaude.aiのアカウント認証が必要で、Amazon BedrockやGoogle CloudのAgent Platform、Microsoft Foundry経由では使えず、データを保持しない設定の組織も対象外です。使えない環境で打つと手元のレビューが走ります。
クラウド側の中身はこちらにまとめています。
名前が変わってきた経緯
古い手順書を見ていると /simplify という名前が出てきます。v2.1.147より前は、このコマンドがその名前で、しかも既定で修正を適用していました。
現在の /simplify は別物です。v2.1.154から、バグ探しをせず整理だけを行うレビューになりました。もし /simplify をバグ探しの目的で手順書に書いていたら、/code-review --fix に置き換える必要があります。
なお当メディアには /review を扱った古い記事もあります。いまバグ探しに使うのは /code-review です。
裏で走るようになったこと自体は地味に見えますが、投げてから待たなくていいのは使うと差が大きいところでした。長い差分こそレビューさせたいのに、長いほど文脈を食うので避けていた。その理由がなくなりました。





