Claude Codeにコードレビューとテスト作成を任せる — /code-reviewの使い方と観点の渡し方

書く速さに、確かめる速さが追いつかない

AIに書かせると、1回の変更量が一気に増えます。その結果、人が目で差分を読む工程がいちばんの渋滞ポイントになります。研修先でも「書くのは速くなったが、本当に正しいのか分からない」という相談が増えています。

かといって、書いた会話の中で「問題ないですか」と聞くだけでは足りません。同じ文脈で書いた側は、自分の置いた前提を疑いにくいからです。人のチームでも、書いた本人とは別の人がレビューするのと同じ理屈です。

Claude Codeには、この「別の目」を用意する仕組みが標準で入っています。それが /code-review です。レビューは専用のコンテキストを持つサブエージェントとして裏で走るため、書いた会話の流れに引きずられにくく、会話の文脈も埋めません。

/code-reviewの基本 — 打つだけで今の差分を見てもらう

引数なしで /code-review を実行すると、作業中のブランチでまだ上流へ送っていないコミットと、未コミットの変更をまとめてレビューします。/review は同じコマンドの別名です。終わると、指摘が会話に届きます。

公式ドキュメントによると、主に見るのは動作を壊す不具合（correctness bugs）です。モデルとエフォートによっては、既存部品の再利用・簡素化・効率についての指摘も加わります。書式の好みを並べる道具ではありません。

ブランチ名や main...my-feature のような範囲も対象に指定できます。「何をレビューするか」を引数で切り替えられるので、自分の作業中の差分にも、同僚のプルリクエストにも同じコマンドで使えます。

エフォートで「確実さ」と「網羅」を選ぶ

レビューの深さは low・medium・high・xhigh・max で指定します。low は確信度の高い指摘だけを出すため、誤検知が少なくなります。medium から max に上げるほど、見る範囲が広がります。

注意したいのは、レベルを省略すると前回自分で打ったレベルが再利用される点です。別のセッションでも引き継がれます。一度 max を打つと、以降の /code-review も max で走るので、使用量が気になる場合は意識して打ち直してください。

--fixを使う前に、コミットしておく

--fix を付けると、レビューの指摘がそのまま作業中のファイルへ反映されます。便利ですが、裏で走ったレビューの修正は会話のチェックポイントの外で行われるため、/rewind では元に戻せません。戻すときはgitを使います。

そこで、--fix の前に一度コミットしておくのが安全です。こうしておけば、レビューが何を直したかがそのまま差分として見え、納得できない修正だけを戻せます。

似た名前の /simplify は役割が違います。/simplify は重複や冗長さを整理して修正まで行うコマンドで、不具合探しはしません。不具合を見つけたいときは /code-review を使う、と覚えておけば迷いません。

自社のレビュー観点はCLAUDE.mdで渡す

/code-review は、通常のセッションと同じくCLAUDE.mdの内容に従います。つまり「この会社のコードで必ず見てほしいこと」をCLAUDE.mdに書いておけば、毎回のレビューに観点として効きます。書き方の基本はCLAUDE.mdの書き方を参照してください。

## レビューで必ず確認すること
- 顧客の氏名・メールアドレスをログやエラーメッセージに出していないか
- 金額の計算で端数処理（切り捨て・四捨五入）が仕様どおりか
- 外部サービスのAPIキーをコードに直接書いていないか
- 新しく追加した処理に、対応するテストがあるか

観点は「〜に気をつける」ではなく「〜していないか」と確認できる形で書くと、指摘の精度が上がります。後述するGitHub連携のCode Reviewが読む REVIEW.md は、ローカルの /code-review では読まれない点も押さえておいてください。

テストは「ケースの一覧」から先に作らせる

レビューが「書かれたもの」を確かめる作業なら、テストは「満たすべき条件」を先に決めておく作業です。いきなりテストコードを書かせるより、先に日本語のケース一覧を出させて人が確認するほうが、抜けを早く見つけられます。

1. 1仕様（何を入れたら何が返るべきか）を伝え、テストケースを日本語の一覧で出させる
2. 2人が一覧を読み、業務上の例外や抜けているケースを足す
3. 3確定した一覧をもとにテストコードを書かせ、実行させる
4. 4失敗したテストを見ながら実装を直させ、全件通るまで回す

請求書の金額を計算する関数 calcInvoice のテストケースを、まず日本語の一覧で出してください。
正常系に加えて、境界値（0円・上限額）、異常系（マイナス・未入力）、
税率が切り替わる日付をまたぐケースを必ず含めてください。
この段階ではテストコードは書かないでください。

テストを通すことが目標になると、実装ではなくテストの側を書き換えて合格させてしまうことがあります。「テストを変更する場合は、理由を先に報告してから」と一言添えておくと防げます。完了条件そのものを判定させる仕組みは/goalの記事で解説しています。

チームで回すなら、GitHub連携のCode Review

Team・Enterpriseプラン向けには、GitHubのプルリクエストを自動でレビューするCode Reviewが研究プレビューとして提供されています。組織のOwnerが管理画面で有効にし、Claude GitHub Appを入れると使えます。

複数のエージェントが変更を並行して調べ、指摘を該当行へのコメントとして投稿します。指摘には重要度が付きますが、プルリクエストを承認もブロックもしないため、既存のレビューの流れはそのまま残ります。観点の調整には CLAUDE.md と REVIEW.md を使います。

「pushのたび」はpush回数だけ費用が積み上がるので、最初は「手動」か「作成時に1回」で始めるのが無難です。月の上限額は管理画面で設定できます。使用クレジットの仕組みはTeamプランの追加利用の記事で解説しています。

現場が内製したツールこそ、レビューを1回挟む

非エンジニアが業務ツールを作れるようになると、今度は中身を確かめる人がいないことが弱点になります。作った本人も、コードを読んで正しさを判断するのは難しいからです。

ここで /code-review を1回挟むだけでも、誰の目も通っていない状態からは一段引き上げられます。指摘の意味が分からなければ「この指摘を直さないと、業務で何が起きるか」と聞き返してください。直すかどうかの判断材料が日本語で返ってきます。

ただし、レビューが通ったことは業務の仕様どおりに動く保証ではありません。最後は、実際の業務データに近い入力で動かして確かめる工程を残してください。

つまずきやすい3点と対処

どれも、道具の性能より使う順番と置き場所で解決できるものです。レビューとテストを型として決めておくと、担当者が代わっても同じ品質で回り続けます。

研修・導入支援では、レビューの型まで一緒に作ります

AIに書かせる量が増えるほど、確かめる仕組みを先に決めておくことが効いてきます。レビュー観点の言語化は、社内の暗黙のルールを棚卸しする作業でもあります。

AI OrchestraのClaude Code研修・導入支援では、CLAUDE.mdへのレビュー観点の書き出しから、テストの進め方、GitHub連携の運用設計まで伴走しています。書く速さに確かめる工程が追いついていないという企業様は、お気軽にご相談ください。