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