Claude Codeを「コードを書かせる相手」としてだけ使っていませんか。実はもう一つ強力な使い方があります。コードレビュー役です。
- 一人開発で、自分のコードを誰もレビューしてくれない
- レビューを頼みたいが、相手の時間を取るのが申し訳ない
- セルフレビューはしているが、自分の見落としは自分では気づけない
- レビュー観点（セキュリティ・テスト漏れ・エラーハンドリング）を毎回網羅できる自信がない
こういうときにClaude Codeをレビュー役に回すと、**書く前・書いた後の両方で「もう一つの目」**が手に入ります。この記事では、レビュー運用の具体的なやり方をまとめます。
前提: レビューは「観点を渡す」と質が上がる
ただ「このコードをレビューして」と頼むと、当たり障りのない一般論が返ってきがちです。レビューの質は観点を明示することで大きく変わります。
公式ドキュメントでも、レビュー用スキルの例として次のような観点が挙げられています。
レビューで見るべき観点（例）
├─ コードの構成・構造
├─ エラーハンドリング
├─ セキュリティ上の懸念
└─ テストのカバレッジ
つまり「何を見てほしいか」を先に渡すのがコツです。次のように頼むと、漠然としたレビューが具体的になります。
この変更をレビューして。特に次の観点で見て:
① エラーハンドリングの漏れ
② 入力値のバリデーション不足
③ テストが必要なのに無い箇所
それぞれ「どのファイルの何行目が問題か」と「なぜ問題か」を
セットで指摘して
使い方1: 差分（diff）に絞ってレビューさせる
レビューで一番効くのが**「変更した部分だけ」に絞る**ことです。プロジェクト全体を読ませると、消費も増え、論点もぼやけます。
変更内容に集中させるには、未コミットの差分を見せるのが手軽です。
git diff の内容をレビューして。
変更した箇所だけに集中して、追加・修正したコードに
バグや見落としがないか確認して。既存コードの一般論は不要
公式ドキュメントには「未コミットの変更を要約し、リスクを洗い出す」スキルの例があり、フロントマター内で !git diff HEAD`` のように差分を取り込んでから、リスク（エラーハンドリング漏れ・ハードコードされた値・更新が必要なテスト）を指摘させる構成が示されています。これを真似て、差分を渡して観点付きでレビューさせるのが基本形です。
使い方2: 「書く前」のレビュー（設計レビュー）
レビューはコードが出来てからだけのものではありません。実装に入る前に方針をレビューさせると、手戻りを根本から減らせます。
ユーザー登録機能を実装したい。まだコードは書かないで。
まず実装方針を箇条書きで出して、その方針自体の問題点
（セキュリティ・拡張性・既存設計との整合）を自分で指摘して。
それを見てからGOを出す
「作る前にツッコミも自分で出させる」と、明らかな設計ミスを着手前に潰せます。書いてからレビューするより、ずっと安いコストで直せます。
使い方3: レビュー役と実装役を分ける
同じ会話の中で「書いた本人がそのまま自己採点する」と、どうしても甘くなりがちです。より厳しく見たいときは、レビューを別の文脈でやらせると効果的です。
この差分を、初めてこのコードを見るレビュアーとして厳しく見て。
「自分が書いたもの」という前提は捨てて、
受け入れられない点・質問したい点を遠慮なく挙げて
「書いた人」ではなく「初見のレビュアー」という立場を明示するだけでも、指摘の鋭さが変わります。実装で長く続いた会話は一度 /clear してから、差分だけ渡してレビューさせると、より客観的な目になります。
使い方4: 指摘を「直す」までつなげる
レビューは指摘して終わりではもったいないです。指摘 → 修正 → 再レビュー、まで回すと一周します。ただし一気に全部直させないのがコツです。
さっき挙げた指摘のうち、①と②だけ先に直して。
③（設計に関わる指摘）は影響範囲が大きいので、
直す前にどう直すか方針を出して。確認してから着手して
軽微な指摘はまとめて直し、設計に関わる重い指摘は方針確認を挟む。この線引きをすると、レビューの結果を安全に反映できます。
レビュー運用の型（まとめ）
| ステップ | やること | コツ |
|---|---|---|
| 1. 設計レビュー | 着手前に方針を出させ、問題点も自分で指摘させる | 書く前に潰す |
| 2. 差分レビュー |
git diff に絞り、観点を渡してレビュー |
変更箇所だけに集中 |
| 3. 客観レビュー | 「初見のレビュアー」として厳しく見させる |
/clear して立場を変える |
| 4. 反映 | 軽微はまとめて修正、重いものは方針確認を挟む | 一気に全部直させない |
注意点 — レビューは「補助の目」であって最終責任ではない
便利な一方で、Claude Codeのレビューは万能ではありません。
- 指摘が常に正しいとは限らない。的外れな指摘も混じる
- ドメイン固有の業務ルールや、明文化されていない前提は見抜けないことがある
- 「問題なし」と返ってきても、それは安全の保証ではない
レビューはあくまで見落としを減らすための補助です。最終的な判断と責任は人間側にある、という前提で使うと、過信による事故を避けられます。観点を渡してセルフレビューの精度を底上げする、くらいの距離感がちょうどよいです。
まとめ
- Claude Codeは「書く相手」だけでなく「レビュー役」としても使える
- レビューは観点を明示すると質が上がる（エラーハンドリング・セキュリティ・テスト漏れなど）
- 差分（
git diff）に絞り、着手前の設計レビューも組み合わせると手戻りが減る - 指摘は軽微・重いを分けて反映する。最終責任は人間側に置く
まずは**「git diff を観点付きでレビューさせる」**ところから始めてみてください。一人開発でも「もう一つの目」が入るだけで、見落としの体感がかなり変わります。
補足: レビュー観点を仕組み化する無料リポジトリ
レビュー観点や開発の進め方は、CLAUDE.md やスキルに型として書いておくと、毎回ゼロから指示せずに済みます。私が使っているスキルを無料で公開しています。
無料スターター（GitHub・CC BY 4.0）:
https://github.com/noguso245-jpg/claude-code-skills-starter
CLAUDE.md設計・計画ファースト開発（PIV）・AIコミット戦略・アジャイルなプロンプト設計の4本のスキルが日本語・英語で入っています。計画ファースト開発（PIV）は「着手前のレビュー」の考え方と相性がよいので、設計レビューを習慣化する土台に使えます。まずは無料リポジトリから試してみてください。
最新のTipsはXでも発信しています: @k___n___t_1125