差分をそのまま見せて「レビューして」と投げるだけでは甘い。だいたい見落とされる。Claude Code にやらせたいのは、単なる読み上げではなく、変更の穴を突かせることだ。
この使い方が効くのは、コード修正だけではない。設定ファイルの整理、文章の推敲、不要ファイル削除の前後確認、README の手直しみたいな作業でも同じだ。自分では「まあこんなもんか」で流しがちな差分に、第三者の目を入れる。しかも人間に頼む前に、まず機械に荒く突っ込ませる。これだけで手戻りが減る。
最初にやることは単純だ。変更したファイルを見せて、目的と合わせてレビューさせる。雑に「見て」では弱い。何を重点的に見てほしいかを言う。
claude
この差分をレビューしてほしい。
目的は「検索しやすいようにファイル名を整理すること」だ。
次の観点で厳しめに見てください。
- 変更の意図と結果がずれていないか
- 例外ケースを壊していないか
- 命名が一貫しているか
- 余計な変更が混じっていないか
- もっと安全で単純なやり方があるか
指摘は重要度順に並べてください。
「問題なし」で終わらせず、気になる点があれば必ず挙げてください。
この頼み方の肝は、単に「レビューして」ではなく、レビューの目線を決め打ちすることだ。Claude Code は、何を探すべきかが曖昧だと、きれいな要約を返して終わりやすい。要約は便利だが、それで満足すると危ない。見たいのは要約ではなく、穴だ。
コード相手なら、差分をそのまま渡すより、まずファイル単位で見せる方が扱いやすい場面がある。特に変更が多いときは、全部を一気に見せると話がぼやける。筆者は一度、設定ファイルの修正と文書の整形をまとめて投げて、指摘が散らかったことがある。レビュー対象が混ざると、どこが本丸か見えなくなる。小分けにして、1 回ごとの目的を絞る方が強い。
この変更をレビューしてほしい。対象は src/config.yml だけ。
見てほしいのは次の点だ。
- 設定値の意味が変わっていないか
- 既存の運用手順を壊していないか
- 不要な差分が混ざっていないか
もし修正が必要なら、どこをどう直すべきか具体的に書いてください。
文章やファイル整理でも使い方は同じだ。たとえば、長文の説明文を直したあとにこう聞く。
この文章の変更点をレビューしてほしい。
読者は非エンジニアで、操作ミスを減らしたい人だ。
次を重点的に見てください。
- 余計に難しくなっていないか
- 手順の順序が自然か
- 前提知識を置きすぎていないか
- 読んだ人が実際に手を動かせるか
曖昧な表現や、後で誤解されそうな箇所は容赦なく指摘してほしい。
ここで効くのは「容赦なく」と言い切ることだ。遠慮したレビュー依頼は、だいたい遠慮した返答になる。こちらがほしいのは、気持ちのいい賛辞ではない。手戻りを減らすためのツッコミだ。
レビューを強くするコツは、観点を増やしすぎないことでもある。全部盛りにすると、見た目は立派でも中身は浅くなる。おすすめは、次のどれかに絞るやり方だ。
ひとつは安全性だ。削除や上書きが入る変更、ファイル整理、リネーム、置換の確認に向いている。たとえば不要ファイルを消す前に、「消してよい根拠がないもの」を洗い出させる。
この削除案をレビューしてほしい。
本当に消してよいか、危ないものを優先して指摘してほしい。
特に次を見てください。
- 再生成できないファイルが混ざっていないか
- 他の設定や手順がこのファイルに依存していないか
- いま消すと後で困るものがないか
もうひとつは一貫性だ。命名、見出し、ディレクトリ構成、表記ゆれの確認に向く。人間は一部だけ直して満足しがちだが、機械に見るとまだらなズレが見つかる。
変更後の命名と構成をレビューしてほしい。
次のルールに合っているか確認して。
- 同じ種類のものは同じ命名規則にする
- 似た役割のファイルは同じ階層に置く
- 例外があるなら理由を明示する
ルールから外れている箇所があれば、候補も含めて指摘してほしい。
ここで注意したいのは、Claude Code の返答をそのまま信じ切らないことだ。これは大事だ。レビューはあくまでレビューであって、正解判定機ではない。特に、外部仕様やプロジェクト独自の慣習に依存する変更は、文脈が足りないと外す。だから、必要なら関連ファイルも一緒に見せる。変更ファイルだけでは判断しにくいときがあるからだ。
筆者は最初、差分だけを渡して「これで通るか」を判定させようとして失敗した。結果は悪くないのだが、足りなかった。レビューが甘くなるというより、前提が見えないせいで指摘がズレる。たとえば、ある文言を短くした変更でも、周辺の文書に同じ表現が残っているなら、そこまで見ないと意味がない。差分単体ではなく、必要な範囲を含める。ここをケチると精度が落ちる。
もうひとつ、よくある失敗が「感想レビュー」だ。たとえば、
この変更どう思う？
これでは弱い。返ってくるのは、なんとなくの感想か、無難なまとめだ。欲しいのは、判断材料になる指摘である。だから、採点基準を入れる。
この変更をレビューして、次の観点で判定してほしい。
- 目的に対して十分か
- 無駄な変更がないか
- 後で保守しやすいか
- 既存の運用を壊しそうな点がないか
各指摘に、重要度を「高・中・低」で付けてください。
この「重要度を付ける」が地味に効く。指摘が多いだけでは、結局どれから直すか迷うからだ。レビューは量より順序だ。先に潰すべきものが見えるだけで、作業の流れが変わる。
実務では、レビューを一発で終わらせない方がいい。最初のレビューで粗く突っ込みを入れさせ、直したあとにもう一度見せる。二段階にすると、初回で見落とした穴が減る。特に文章や整理作業では、1 回目で構造、2 回目で表現を見分けると効率がいい。
まず構造面だけレビューして。
そのあと、問題がなければ表現の冗長さだけ見てほしい。
この分け方は、差分が大きいときほど効く。いきなり細部の表記を詰めると、肝心のロジックや構成の破綻を見逃す。逆に、まず大きな欠陥を落としてから細部を見ると、手戻りが少ない。
最後に、レビュー依頼でやってはいけないことをはっきり書いておく。変更内容を隠して「当ててみて」とやるのは無駄だ。レビューに必要なのは推理ではなく検査だ。隠すほど精度は落ちる。目的、変更範囲、気にしてほしい点、この3つを渡す。これだけで返答の質がかなり変わる。
Claude Code に差分をツッコませるのは、派手な使い方ではないが、かなり堅い。人間の目だけだと流しがちな変更を、ひと呼吸置いて見直せる。コードでも文書でも、ファイル整理でも同じだ。まずは「何を怖がっているのか」を書いて投げる。そこからレビューが働く。