Claude Code でいちばん役に立つ使い方のひとつが、自分が触った差分をその場でレビューしてもらうことです。
書いた本人は「何をしたか」を知っているので、抜けや危うさに気づきにくいものです。そこで Claude Code に、変更したファイルだけを読ませて「この差分の気になる点を挙げて」と頼む。これだけで、ロジックの穴、説明不足、不要な変更、うっかり混ぜた雑修正がかなり見つかります。
エンジニアならコードレビューの補助に、非エンジニアなら文書や整理作業のセルフチェックに向いています。たとえば、契約書のドラフトで言い回しがぶれていないか、フォルダ整理で同じファイルを二重に残していないか、Markdown の文章で見出し構造が崩れていないか。人間の目だと見落としやすいところを、差分ベースで拾わせる使い方です。
まずは、変更したあとにそのままレビューさせます。大げさな設定は要りません。作業対象のディレクトリにいる状態で、普通に「レビューして」と依頼します。
この変更内容をレビューしてください。
特に次を見てください。
- 仕様や意図から外れていないか
- 不要な変更や巻き込みがないか
- 文章やコメントの説明不足がないか
- 直したつもりで壊している箇所がないか
気になった点は、重要度の高い順に挙げてください。
修正案があれば、理由つきで示してください。
コードなら、もう少し踏み込んでこう頼むと効きます。
直近の変更差分をレビューしてください。
観点は以下です。
- バグの可能性
- 例外やエッジケース
- 可読性
- 既存の振る舞いとの不整合
- テストが足りない箇所
「問題なし」で終わる場合でも、気になりそうな点を1つは挙げてください。
ここで大事なのは、「何を見てほしいか」を先に言うことです。
ただ「レビューして」だけだと、Claude Code は広く浅く見ることがあります。逆に、観点を絞ると返答がかなり実用的になります。たとえば文書なら「論理の飛躍」「表現の重複」「読み手が誤解しそうな箇所」、ファイル整理なら「同名ファイルの混在」「削除してよいが残っている候補」「命名のゆれ」に寄せるとよいです。
差分レビューでいちばんありがたいのは、自分では“変更したこと”に意識が向いていて、“変更しなかった部分”を見落とすところを突いてくれる点です。
たとえばコードなら、関数を直したのに呼び出し側の前提が変わっていないか。文書なら、ある段落を整えた結果、用語の定義が前の章とずれていないか。整理作業なら、不要ファイルを消したつもりで、必要なテンプレートまで巻き込んでいないか。こういう事故は、本人の頭の中ではつながっていても、差分の外側にあることが多いです。
依頼文に「差分の外側に波及がないかも見てください」と入れると、レビューの質が上がります。
この変更差分を見て、差分そのものだけでなく、
周辺ファイルや既存の前提に波及しないかも確認してください。
特に、
- 参照先の変更漏れ
- 説明と実装の不一致
- 似た処理との整合性
- 片付けたつもりで残る不要物
を見てください。
レビューを頼むときは、「褒める」より「突っ込ませる」ほうが実用的です。
人はレビューを受けると、つい「良かった点も教えて」と言いたくなりますが、まず欲しいのは危ない部分です。Claude Code に対しても、最初から「気になる点だけ列挙して」と言ったほうが、ノイズが減ります。
この差分のダメ出しだけしてください。
良い点の説明は不要です。
修正が必要そうな点、曖昧な点、将来の保守で困りそうな点だけ挙げてください。
この頼み方は、文章のレビューでもかなり使えます。
たとえば社内文書や提案書の下書きなら、次のように振ると便利です。
この文書のレビューをしてください。
読み手が誤解しそうな表現、前提知識が必要な箇所、言い切りが強すぎる箇所を中心に見てください。
文体の好みではなく、実務上の誤読リスクを優先してください。
つまずきやすいのは、レビュー対象が広すぎることです。
「このフォルダ全体を見て」と丸投げすると、関係ないファイルまで広く触れてしまい、返答がぼやけます。変更したファイルや、今回の作業に関係する範囲を明示したほうが、レビューの密度が上がります。特に大量のファイル整理や文書移動をしたときは、対象を「この案件フォルダのうち、今日触ったもの」に絞るだけでも違います。
もうひとつ、**“正解を探させる”のではなく“違和感を出させる”**ほうが向いています。
レビューは採点ではありません。Claude Code に完璧な合否判定を求めると外します。むしろ「ここ、ちょっと変では？」を拾わせる使い方が向いています。差分レビューの価値は、正しさの断定より、目を向けるべき箇所の発見にあります。
それから、レビューの返答が浅いときは、最初の依頼にこう足すと改善しやすいです。
表面的なコメントではなく、実際に問題になりそうな点を優先してください。
必要なら、関連する箇所をたどって確認してください。
少し進んだ使い方としては、レビューの観点を作業の種類に合わせて変えることです。
コード修正なら「仕様・例外・テスト」、文章修正なら「論理・用語・読み手の誤解」、ファイル整理なら「重複・不要・命名の一貫性」といった具合です。毎回同じ文言を使う必要はありません。むしろ、その場の作業に合わせて1行足すほうが強いです。
たとえば、重複ファイルの整理をしたあとなら、こう頼めます。
このフォルダ整理の結果をレビューしてください。
- 同じ中身の重複が残っていないか
- 名前はわかりやすいか
- 消してはいけないものを誤って除外していないか
- 今後探しにくくなる構成になっていないか
見た目の整いより、実務で迷わないかを重視してください。
文書作成なら、レビューの最後に「直し方」まで求めると、そのまま手戻りを減らせます。
この下書きをレビューして、修正が必要な箇所は
- どこが問題か
- どう直すとよいか
をセットで挙げてください。
できれば、文面を1〜2案に言い換えてください。
最後に覚えておくと便利なのは、自分の差分をレビューさせる行為は、外部レビューの代わりではなく、提出前の予行演習だということです。
人に見せる前に、機械相手に突っ込みを入れさせる。これだけで、説明不足や雑な変更がかなり減ります。特に一人で作業を進める場面では、これがあるかないかで後戻りの量が変わります。
レビュー依頼は短くても機能しますが、実用上は「観点を絞る」「気になる点だけ出させる」「波及も見る」の3つを入れると安定します。Claude Code に差分を見せるたび、この癖をつけておくと、コードでも文書でも、仕上がりがだいぶ変わります。