Claude Codeが黙ってレビューしなくなった。/code-reviewは自分で呼ぶものになった
2026年7月、Claude Codeの/code-reviewとverifyは「Claudeが自分の判断で動く」性質を失った。さらに/code-reviewはバックグラウンドのサブエージェントとして動くようになり、3月に書いた使い方ガイドはもう半分古い。v2.1.215とv2.1.218の変更点を公式ドキュメントで検証し、今の正しい使い方をまとめる。
エンジニアのゆとです。
3月にClaude Code Reviewの使い方記事を書いた。あの記事、実はもう半分古い。7月に入ってから/code-reviewと/verifyの挙動が2段階で変わっていて、しかも変わった方向がちょっと意外だった。
結論から言う。7月19日のv2.1.215で、Claudeが自分の判断で/verifyや/code-reviewを勝手に実行する機能が消えた。3日後のv2.1.218では、/code-review自体がバックグラウンドのサブエージェントとして動くように変わった。「呼ばないと動かない」のに「呼んだら裏で動く」という、一見矛盾するような2つの変更が同じ1週間で重なってる。順番に検証する。
「Claudeが自分で判断してレビューする」が普通だった
まず前提から。/code-reviewと/verifyはプラグインじゃなくて、Claude Codeに最初から入ってる「bundled skill（同梱スキル）」という扱いになってる。3月の記事では/plugin → Marketplace → claude-plugins-official → code-review → Installという手順を書いたけど、これはもう不要。今は入れなくても最初から使える。
で、公式ドキュメントのskillsページにこう書いてある。
Claude invokes some bundled skills automatically when relevant; others, including
/verifyand/code-review, run only when you invoke them, which keeps you in control of when these longer-running checks spend time and tokens. Before v2.1.215, Claude could also run/verifyand/code-reviewon its own.
つまり2026年7月19日より前は、Claudeが「このタスク終わったし、一応レビューしとくか」みたいな判断で、こっちが頼んでもいないのに/code-reviewや/verifyを自分から実行することがあった。これ、正直言われるまで気づいてなかった。僕自身、大きめのタスクを終えた後に「なぜかレビューっぽいことを追加でやってる」瞬間に何度か遭遇してて、あれは偶然でも気のせいでもなく、仕様として組み込まれてた自動判断だったってことになる。
v2.1.215でこの自動判断が消えた。今は明示的に/code-reviewか/verifyと打たない限り、Claudeは自分の判断でレビューやビルド確認を始めない。
なぜ「勝手にやる」をやめたのか
チェンジログの書き方から読み取れる理由は「トークンと時間をこっちの制御下に置く」ため。/code-reviewも/verifyも軽い処理じゃない。/code-reviewは複数のエージェントが並列でdiffと周辺コードを調べて、お互いの発見を検証し合ってから報告する構成になってる。/verifyもアプリをビルドして実際に動かして確認する処理で、テストや型チェックで済ますより重い。
Claudeが「念のためレビューしとこう」と自分で判断して走らせるたびに、こっちが把握してないところでトークンと時間が消費される。特に長時間の自律タスクや、複数セッションを並列で回してる時にこれが起きると、いつの間にか使用量が積み上がる。v2.1.215の変更は「便利さより制御可能性を優先する」という判断だと思う。実際、これは僕の運用実感とも合ってて、自動でレビューが走ってくれるのは一見親切だけど、いつ・なぜ走ったのかが追いづらいのは地味にストレスだった。
/code-reviewがバックグラウンド化した話（v2.1.218）
3日後の7月22日、今度は/code-review単体に変更が入った。公式ドキュメントの該当箇所。
The review runs as a background subagent with its own context window, so it doesn’t fill your conversation. The findings arrive in your conversation when the review completes.
v2.1.218より前は、/code-reviewを打つと自分の会話の中でレビューが進んで、その分コンテキストを消費してた。今はバックグラウンドのサブエージェント（context: fork、background: trueが既定）として切り離された場所で動いて、終わったら結果だけが会話に戻ってくる。レビュー中も普通に別の作業を続けられる。
これに付随して、地味だけど実務に効く変更が2つある。
1つ目、スタックコマンドの解釈が変わった。以前は/code-review /fix-issue 123のように別コマンドを続けて書くと、後半の/fix-issue 123が独立したスキルとして展開されてた。今はそうならず、/fix-issue 123という文字列がそのまま/code-reviewのレビュー対象テキストとして扱われる。地味な違いに見えるけど、コマンドを組み合わせて使ってた人は動作が変わったことに気づかないと混乱する。
2つ目、--fixを付けた時の挙動。バックグラウンドで実行された/code-review --fixの修正は、セッションのチェックポイント管理の外側で適用される。つまり/rewindで戻せない。元に戻したい場合はgitを使う必要がある。フォアグラウンド（自分のターンの中）で実行された場合は今まで通り/rewindで戻せるので、この違いは覚えておいた方がいい。
# バックグラウンドで動く（v2.1.218以降の既定）
/code-review --fix
# → 修正がチェックポイント外で適用される。/rewindでは戻せない、gitで戻す
# 実行中に再度 /code-review を打つとフォアグラウンドで動く
# → 通常のターンとして扱われるので /rewind が効くeffort・—comment・ultraはそのまま使える
挙動が変わったのは「いつ・どこで動くか」の部分で、機能自体は3月時点から大きくは変わってない。おさらいすると、/code-reviewは自分のブランチの未プッシュコミット＋作業中の変更を対象にレビューする。ファイルパス、PR番号、ブランチ名、main...my-featureのような範囲指定も渡せる。
/code-review # 現在のブランチをレビュー
/code-review --fix # 見つかった問題を作業ツリーに直接適用
/code-review --comment # PRにインラインコメントとして投稿
/code-review high # effortを上げて広めに検出（false positiveは増える）
/code-review ultra # クラウドの深掘りレビュー（ultrareview）にエスカレーションultraを付けた時だけ引数の解釈が変わって、単語1つならブランチ名やPR番号として、それ以外の長い文章ならレビューに添える補足メモとして扱われる。/code-review ultra check my auth changesと打てば、現在のブランチをレビューしつつ「認証周りの変更を重点的に見て」という文脈を加味してくれる。
もう1つ覚えておきたいのが、/code-reviewはdisable-model-invocationが設定されてるスキルだということ。これはスケジュールタスクのプロンプトとして登録しても実際のレビューは走らず、Claudeがただのテキストとして読むだけになる、という仕様上の制約。定期実行でレビューを回したい場合はここで詰まるので注意。
実務でどう向き合うか
僕が変えたのは2つ。
1つは、大きめのタスクを終えた後に「レビュー、勝手にやってくれてるかも」という期待を捨てたこと。今は自分で/code-reviewを打つのを、コミット前のルーティンに明示的に組み込んでる。Claude任せにできなくなった分、こっちの手順が1つ増えた形。
もう1つは、--fixをバックグラウンドで走らせた後に「あれ、この修正どうやって戻すんだっけ」と一瞬迷わないように、/rewindじゃなくgitで戻す前提に頭を切り替えたこと。バックグラウンド実行はチェックポイントの外側にいる、というのは意識してないと普通に忘れる類の話だと思う。
正直、自動でレビューが走らなくなったのは不便に感じる場面もある。でも「いつ・どこで何にトークンを使ってるか」が見えやすくなった分、長時間タスクを回す時の安心感は上がった。バックグラウンド化についても、レビュー中に会話が止まらなくなったのは素直にありがたい。3月の記事を読んで「プラグインをインストールする」手順のまま使ってる人がいたら、そこだけは今すぐ直した方がいい。
